1.

GENERALITI DESPRE BAZE DE DATE

1.1. Introducere Baza de date este un ansamblu structurat de date coerente, fr

redondan inutil, astfel nct acestea pot fi prelucrate eficient de mai muli utilizatori ntr-un mod concurent. Baza de date este o colecie de date persistente, care sunt folosite de ctre sistemele de aplicaii ale unei anumite ntreprinderi. Datele din baza de date persist deoarece, dup ce au fost acceptate de ctre sistemul de gestiune pentru introducerea n baza de date, ele pot fi terse din baz numai printr-o cerere explicit adresat sistemului de gestiune. Aici, termenul de ntreprindere este un cuvnt generic, utilizat pentru a desemna orice organizaie independent, de natur tehnic, comercial, tiinific sau de alt tip. ntreprinderea poate fi, de exemplu, un spital, o banc, o facultate, o fabric, un aeroport etc. Fiecare ntreprindere are regulile proprii de funcionare i conine o mulime de date referitoare la modul su de operare. Datele din baza de date pot fi att integrate, ct i partajate. Noiunea de integrat se refer la faptul c baza de date poate fi considerat ca o unificare a mai multor fiiere, iar prin partajare se nelege c baza de date poate fi partajat concurent ntre diferii utilizatori. Un sistem de gestiune a bazelor de date (SGBD Data Base Management System) este un produs software care asigur interaciunea cu o baz de date, permind definirea, consultarea i actualizarea datelor din baza de date. Toate cererile de acces la baza de date sunt tratate i controlate de ctre SGBD. Organizarea datelor n baze de date constituie o form de centralizare a acestora. Aceasta implic existena unui administrator al bazei de date (DBA Data Base Administrator) care este o persoan sau un grup de persoane ce rspund de ansamblul activitilor (analiz, proiectare, implementare, exploatare, ntreinere etc.) legate de baza de date. Atribuiile unui administrator pot fi grupate n patru mari categorii: atribuii de proiectare, atribuii administrative, atribuii operative i atribuii de coordonare. Concepte ale bazelor de date relaionale n aceast parte se face o prezentare general a conceptelor bazelor de date relaionale. O baz de date relaional este o colecie de informaii interrelaionate gestionate ca o singur unitate.

A ceast definiie este foarte larg, deoarece exist mari diferene ntre concepiile diferiilor productori care pun la dispoziie sisteme de baze de date. De exemplu, Oracle Corporation definete o baz de date ca fiind o colecie de fiiere fizice gestionate de o singur instan (copie) a produsului software pentru baze de date, n timp ce Microsoft definete o baz de date SQL Server ca fiind o colecie de date i alte obiecte. Un obiect al bazei de date este o structur de date denumit, stocat n baz de date, cum ar fi un tabel, o vizualizare sau un index. Exist mari diferene ntre implementrile furnizorilor de baze de date. n majoritatea sistemelor de baze de date, datele sunt stocate n mai multe fiiere fizice, dar n Microsoft Access toate obiectele bazei de date, mpreun cu datele care aparin unei baze de date sunt stocate ntr-un singur fiier fizic.(Un fiier este o colecie de nregistrri nrudite stocate ca o singur untiate de sistemul de operare al calculatorului.) Totui, unul dintre principalele avantaje ale bazelor de date relaionale este faptul c detaliile de implementare fizic sunt separate de definiiile logice ale obiectelor bazei de date, astfel nct majoritatea utilizatorilor bazei de date nu au nevoie s tie unde (i cum) sunt stocate obiectele bazei de date n sistemul de fiiere al calculatorului. Sistem de gestionare a bazei de date (DBMS sau SGBD) Un sistem de gestionare a bazei de date (DBMS database management system) este un produs software furnizat de productorul bazei de date. Produse software precum Microsoft Access, Microsoft SQL Server, Oracle Database,Sybase, DB2,INGRES, MySQL i Postgre SQL fac parte din categoria DBMS sau, mai corect, DBMS relaionale (RDBMS). RDBMS-urile sunt cunoscute i sub numele de SGBD-uri. Ambele prescurtri vor fi folosite n acest expunere. Sistemul DBMS pune la dispoziie toate serviciile de baz necesare pentru organizarea i ntreinerea bazei de date, inclusiv urmtoarele: - Transferarea datelor n i din fiierele fizice de date, n funcie de cerine. - Gestionarea accesului concurenial la date al mai multor utilizatori, inclusiv prevenirea conflictelor care ar putea fi cauzate de actualizrile simultane. - Gestionarea tranzaciilor, astfel nct toate modificrile fcute asupra bazei de date printr-o tranzacie s fie executate ca o singur unitate. Cu alte cuvinte, dac tranzacia reuete, toate

O baz de date relaional este o baz de date care respect modelul relaional, dezvoltat de Dr.E.F.Codd. Modelul relaional prezint datele sub forma familiarelor tabele bidimensionale, similar cu o foaie de calcul tabelar. Spre deosebire de o foaie de calcul tabelar, nu este obligatoriu ca datele s fie stocate ntr-o form tabelar, iar modelul permite i combinarea tabelelor (crearea uniunilor (joining), n terminologia relaional) pentru formarea vizualizarilor, care sunt prezentate tot ca tabele bidimensionale. Flexibilitatea extraordinar a bazelor de date relaionale este dat de posibilitatea de a folosi tabelele independent sau n combinaii, fr nici o ierarhie sau secven predefinit n care trebuie s se fac accesul la date.

Ce este o baz de date relaional ?

modificrile efectuate de tranzacie sunt nregistrate n baz de date; dac tranzacia eueaz, nici una dintre modificri nu este nregistrat n baz de date.Totui, reinei ca unele sisteme RDBMS nu asigur suportul pentru tranzacii. - Accept un limbaj de interogare, care reprezint sistemul de comenzi folosit de utilizator pentru a obine date din baz de date. SQL este principalul limbaj folosit pentru sistemele DBMS relaionale. - Funcii pentru salvarea bazei de date i pentru refacerea bazei de date n urma erorilor. - Mecanisme de securitate pentru mpiedicarea accesului neautorizat la date i modificarea acestora.

ca o baz de date (metabaz de date), contine date despre date, furnizeaz descrierea tuturor obiectelor unei baze de date, starea acestor obiecte, diversele constrngeri de securitate i de integritate etc. Dicionarul poate fi interogat, la fel, ca orice alt baz de date.

Dicionarul datelor (catalog de sistem), structurat i administrat

1.2. Gestiunea bazelor de date

Un sistem de baze de date presupune urmtoarele componente principale, care definesc arhitectura acestuia: baza de date propriu-zis n care se memoreaz datele; sistemul de gestiune a bazei de date, care realizeaz gestionarea i prelucrarea complex a datelor; un dicionar al bazei de date (metabaza de date), ce conine informaii despre date, structura acestora, statistici, documentaie; mijloace hardware (comune sau specializate); reglementri administrative destinate bunei funcionri a sistemului; personalul implicat (utilizatori finali, administratorul datelor, administratorul bazei de date, proiectani, programatori de aplicaii). Se pot identifica patru categorii de persoane implicate n mediul bazelor de date: administratorii de date i baze de date, proiectanii (designeri) de baze de date, programatorii de aplicaii, utilizatorii finali. Administratorul de date (DA) este un manager, nu un tehnician, ce: decide care date trebuie stocate n baza de date; stabilete regulile de ntreinere i de tratare a acestor date dup ce sunt stocate. De exemplu, o regul ar putea fi aceea prin care se stabilesc pentru utilizatori privilegii asupra informaiilor din baza de date, cu alte cuvinte o anumit politic de securitate a datelor. Administratorul bazei de date (DBA) este responsabil cu implementarea deciziilor administratorului de date i cu controlul general al sistemului, la nivel tehnic. El este un profesionist n domeniul IT, care: creeaz baza de date real; implementeaz elementele tehnice de control; este responsabil cu asigurarea funcionrii sistemului la performane adecvate, cu monitorizarea performanelor; furnizeaz diverse servicii tehnice etc. Proiectanii de baze de date pot acoperi att aspectul fizic, ct i cel logic al concepiei. Proiectantul de baze de date care abordeaz direcia logic trebuie s posede o cunoatere complet i amnunit a modelului real de proiectat i a regulilor de funcionare ale acestuia. Practic, acesta proiecteaz

conceptual baza de date, iar modelul creat este independent de programele de aplicaii, de limbajele de programare. De asemenea, va proiecta logic baza de date, proiectare care este ndreptat spre un anumit model de date (relaional, orientat obiect, ierarhic etc.). Proiectantul de baze de date fizice preia modelul logic de date i stabilete cum va fi realizat fizic. Acesta trebuie s cunoasc funcionalitile SGBD-ului, avantajele i dezavantajele fiecrei alternative corespunztoare unei implementri. Practic, se face transpunerea modelului logic ntr-un set de tabele supuse unor constrngeri, se selecteaz structuri de stocare i metode de acces specifice, astfel nct s se asigure performane, se iau msuri privind securitatea datelor. Utilizatorii finali sunt cei care acceseaz interactiv baza de date. Aceasta a fost proiectat, implementat, ntreinut pentru a satisface necesitile informaionale ale clienilor. Utilizatorii finali pot fi utilizatori simpli, care nu cunosc nimic despre baza de date, despre SGBD, dar acceseaz baza prin intermediul unor programe de aplicaie. n general, aceast clas de utilizatori alege anumite opiuni din meniul aplicaiei. Exist utilizatori finali sofisticai, care sunt familiarizai cu structura bazei de date. Ei pot utiliza limbaje speciale pentru a exploata posibilitile oferite de baza de date. Programatori de aplicaii sunt responsabili de scrierea programelor aplicaie ce confer funcionalitatea cerut de utilizatorii finali. Programele pot fi scrise n diferite limbaje de programare (C++, PL/SQL, Java etc.). asigurarea unei redundane minime n date; furnizarea n timp util a informaiilor solicitate (timpul de rspuns la o interogare); asigurarea unor costuri minime n prelucrarea i ntreinerea informaiei; capacitatea de a satisface, cu aceleai date, necesiti informaionale ale unui numr mare de utilizatori, posibilitatea de adaptare la cerine noi, rspunsuri la interogri neprevzute iniial (flexibilitate); exploatarea simultan a datelor de ctre mai muli utilizatori (sincronizare); asigurarea securitii datelor prin mecanisme de protecie mpotriva accesului neautorizat (confidenialitate);

Cerine minimale care se impun unei baze de date:

nglobarea unor faciliti destinate validrii datelor i recuperrii lor n cazul unor deteriorri accidentale, garantarea (att ct este posibil) c datele din baza de date sunt corecte (integritate); posibilitatea de valorificare a eforturilor anterioare i anticiparea nevoilor viitoare (compatibilitate i expandabilitate); permisivitatea, prin ierarhizarea datelor dup criteriul frecvenei acceselor, a unor reorganizri (eventual dinamice) care sporesc performanele bazei. n cadrul unei baze de date putem vorbi de patru niveluri de abstractizare i de percepie a datelor: intern, conceptual, logic i extern. Datele exist doar la nivel fizic, iar celelalte trei niveluri reprezint virtualizri ale acestora. Nivelul fizic (intern) este descris de schema fizic a datelor (bit, octet, adres); Nivelul conceptual este descris de schema conceptual a datelor (articol, nregistrare, zon) i reprezint viziunea programatorilor de sistem asupra datelor; Nivelul logic este descris de una din schemele logice posibile ale datelor i reprezint viziunea programatorului de aplicaie asupra datelor; Nivelul virtual (extern) reprezint viziunea utilizatorului final asupra datelor. Independena datelor cuprinde dou aspecte fundamentale: o modificare a structurii fizice nu va afecta aplicaia i reciproc, modificri ale aplicaiei vor lsa nealterat structura fizic de date. Independena fizic: posibilitatea modificrii schemei fizice a datelor fr ca aceasta s implice modificarea schemei conceptuale, a schemei logice i a programelor de aplicaie. Este vorba despre imunitatea programelor de aplicaie fa de modificrile modului n care datele sunt stocate fizic i accesate. Independena logic: posibilitatea modificrii schemei conceptuale a datelor fr ca aceasta s implice modificarea schemei logice i a programelor de aplicaie. Prin independena logic a datelor se urmrete a se crea fiecrui utilizator iluzia c este singurul beneficiar al unor date pe care, n realitate, le folosete n comun cu ali utilizatori. Independen fa de strategiile de acces permite programului s precizeze data pe care dorete s o acceseze, dar nu modul cum acceseaz aceast dat. SGBD-ul va stabili drumul optim de acces la date.

n limbajele de programare uzuale declaraiile i instruciunile executabile aparin aceluiai limbaj. n lumea bazelor de date, funciile de declarare i de prelucrare a datelor sunt realizate cu ajutorul unor limbaje diferite, numite limbaje pentru baze de date. Limbaje pentru definirea datelor (DDL Data Description Language). Descrierea concret a unui DDL este specific fiecrui sistem de gestiune, dar funciile principale sunt aceleai. La nivel conceptual, DDL realizeaz definirea entitilor i a atributelor acestora, sunt precizate relaiile dintre date i strategiile de acces la ele, sunt stabilite criterii difereniate de confidenialitate i de validare automat a datelor utilizate. Limbaje pentru prelucrarea datelor (DML Data Manipulation Language). Operaiile executate n cadrul unei baze de date presupun existena unui limbaj specializat, n care comenzile se exprim prin fraze ce descriu aciuni asupra bazei. n general, o comand are urmtoarea structur: operaia (calcul aritmetic sau logic, editare, extragere, deschidere-nchidere, adugare, tergere, cutare, reactualizare etc.), criterii de selecie, mod de acces (secvenial, indexat etc.), format de editare. Exist limbaje DML procedurale, care specific cum se obine rezultatul unei comenzi DML i limbaje neprocedurale, care descriu doar datele ce vor fi obinute i nu modalitatea de obinere a acestora. Limbaje pentru controlul datelor (DCL Data Control Language). Controlul unei baze de date se refer la asigurarea confidenialitii i integritii datelor, la salvarea informaiei n cazul unor defeciuni, la obinerea unor performane, la rezolvarea unor probleme de concuren. Limbajele universale nu se utilizeaz frecvent pentru gestionarea unei baze de date, dar exist aceast posibilitate. De exemplu, sistemul Oracle este dotat cu precompilatoare (C, Pascal, ADA, Cobol, PL/1, Fortran) care ajut la incorporarea de instruciuni SQL sau blocuri PL/SQL n programe scrise n alte limbaje, de nivel nalt, numite limbaje gazd. Sistemul de gestiune a bazelor de date interacioneaz cu programele de aplicaie ale utilizatorului i cu baza de date, oferind o mulime de faciliti. Realizarea optim a acestor faciliti este asigurat de obiectivele fundamentale ale unui sistem de gestiune. Cteva dintre aceste obiective vor fi enumerate n continuare. Independena fizic. Obiectivul esenial este acela de a permite realizarea independenei structurilor de stocare n raport cu

structurile de date din lumea real. Se definete mulimea de date indiferent de forma acesteia din lumea real, innd seama doar de a realiza un acces simplu la date i de a obine anumite performane. Independena logic. Grupul de lucru care exploateaz baza de date poate s utilizeze diferite informaii de baz (nu aceleai), pentru ai construi entiti i relaii. Fiecare grup de lucru poate s cunoasc doar o parte a semanticii datelor, s vad doar o submulime a datelor i numai sub forma n care le dorete. Aceast independen asigur imunitatea schemelor externe fa de modificrile fcute n schema conceptual. Prelucrarea datelor de ctre neinformaticieni. Neinformaticienii vd datele independent de implementarea lor i pot exploata aceste date prin intermediul unui sistem de meniuri oferit de aplicaia pe care o exploateaz. Administrarea centralizat a datelor. Administrarea datelor presupune definirea structurii datelor i a modului de stocare a acestora. Administrarea este n general centralizat i permite o organizare coerent i eficace a informaiei. Coerena datelor. Informaia trebuie s satisfac constrngeri statice sau dinamice, locale sau generale. Neredundana datelor. Fiecare aplicaie posed datele sale proprii i aceasta conduce la numeroase dubluri. De asemenea, organizarea nejudicioas a relaiilor poate s genereze redundan n date. Administrarea coerent a datelor trebuie s asigure neduplicarea fizic a datelor. Totui, nu sunt excluse nici cazurile n care, pentru a realiza performane referitoare la timpul de acces la date i rspuns la solicitrile utilizatorilor, s se accepte o anumit redundan a datelor. Partajabilitatea datelor. Aceasta permite ca aplicaiile s partajeze datele din baza de date n timp i simultan. O aplicaie poate folosi date ca i cum ar fi singura care le utilizeaz, fr a ti c alt aplicaie, concurent, le poate modifica. Securitatea i confidenialitatea datelor. Datele trebuie protejate de un acces neautorizat sau ru intenionat. Exist mecanisme care permit identificarea i autentificarea utilizatorilor i exist proceduri de acces autorizat care depind de date i de utilizator. Sistemul de gestiune trebuie s asigure securitatea fizic i logic a informaiei i s garanteze c numai utilizatorii autorizai pot efectua operaii corecte asupra bazei de date.

Sistemele de gestiune a bazelor de date au, din nefericire, i dezavantaje dintre care se remarc: complexitatea i dimensiunea sistemelor pot s creasc considerabil, datorit necesitii extinderii funcionalitilor sistemului; costul, care variaz n funcie de mediu i funcionalitatea oferit, la care se adug cheltuieli periodice de ntreinere; costuri adiionale pentru elemente de hardware; costul conversiei aplicaiilor existente, necesar pentru ca acestea s poat funciona n noua configuraie hardware i software; impactul unei defeciuni asupra aplicaiilor, bazei de date sau sistemului de gestiune. complexitate variabil, iar nivelul real de funcionalitate difer de la produs la produs. n orice moment apar noi necesiti, care cer o nou funcionalitate, astfel nct aceasta nu va putea deveni niciodat static. n general, un SGBD trebuie s includ cel puin cinci clase de module: programe de gestiune a bazei de date (PGBD), care realizeaz accesul fizic la date ca urmare a unei comenzi; module pentru tratarea limbajului de definire a datelor, ce permit traducerea unor informaii (care realizeaz descrierea datelor, a legturilor logice dintre acestea i a constrngerilor la care sunt supuse), n obiecte ce pot fi apoi exploatate n manier procedural sau neprocedural; module pentru tratarea limbajului de prelucrare a datelor (interpretativ, compilativ, generare de programe), care permit utilizatorilor inserarea, tergerea, reactualizarea sau consultarea informaiei dintr-o baz de date; module utilitare, care asigur ntreinerea, prelucrarea, exploatarea corect i uoar a bazei de date; module de control, care permit controlul programelor de aplicaie, asigurarea confidenialitii i integritii datelor, rezolvarea unor probleme de concuren, recuperarea informaiei n cazul unor avarii sau defeciuni hardware sau software etc.

Structura unui sistem de gestiune a bazelor de date este de

10

Modulele PGBD asigur accesul fizic la date ca urmare a unei comenzi. Cum lucreaz aceste module? gsesc descrierea datelor implicate n comand; identific datele i tipul acestora; identific informaii ce permit accesul la structurile fizice de stocare (fiiere, volume etc.); verific dac datele sunt disponibile; extrag datele, fac conversiile, plaseaz datele n spaiul de memorie al utilizatorului; transmit informaii de control necesare execuiei comenzii, n spaiul de memorie al utilizatorului; transfer controlul programului de aplicaie. Prin urmare, din punct de vedere conceptual: utilizatorul lanseaz o cerere de acces; SGBD-ul accept cererea i o analizeaz; SGBD-ul inspecteaz pe rnd, schema intern corespunzatoare utilizatorului, schema conceptual, definiia structurii de stocare i corespondenele corespunztoare; SGBD-ul execut operaiile necesare n baza de date stocat.

1.3. Arhitectura sistemelor de gestiune a bazelor de date

Asigurarea independenei fizice i logice a datelor impune adoptarea unei arhitecturi de baze de date organizat pe trei niveluri: nivelul intern (baza de date fizic); nivelul conceptual (modelul conceptual, schema conceptual); nivelul extern (modelul extern, subschema, vizualizarea). Nivelul central este nivelul conceptual. Acesta corespunde structurii canonice a datelor ce caracterizeaz procesul de modelat, adic structura semantic a datelor fr implementarea pe calculator. Schema conceptual permite definirea tipurilor de date ce caracterizeaz proprietile elementare ale entitilor, definirea tipurilor de date compuse care permit regruparea atributelor pentru a descrie entitile modelului i legturile ntre aceste entiti, definirea regulilor pe care trebuie s le respecte datele etc. Nivelul intern corespunde structurii interne de stocare a datelor. Schema intern permite descrierea datelor unei baze sub forma n care sunt

11

stocate n memoria calculatorului. Sunt definite fiierele care conin aceste date, articolele din fiiere, drumurile de acces la aceste articole etc. La nivel conceptual sau intern, schemele descriu o baz de date. La nivel extern schemele descriu doar o parte din date care prezint interes pentru un utilizator sau un grup de utilizatori. Schema extern reprezint o descriere a unei pri a bazei de date ce corespunde viziunii unui program sau unui utilizator. Modelul extern folosit este dependent de limbajul utilizat pentru prelucrarea bazei de date. Schema extern permite asigurarea unei securiti a datelor. Un grup de lucru va accesa doar datele descrise n schema sa extern, iar restul datelor sunt protejate mpotriva accesului neautorizat sau ru intenionat. Pentru o baz de date particular exist o singur schem intern, o singur schem conceptual, dar exist mai multe scheme externe. n afar de aceste trei niveluri, arhitectura presupune i anumite corespondene dintre acestea: corespondena conceptual-intern definete relaia dintre nivelul conceptual i baza de date stocat, specificnd modul n care nregistrrile i cmpurile conceptuale sunt reprezentate la nivel intern; corespondena extern-conceptual definete relaia dintre o anumit vizualizare extern i nivelul (vizualizarea) conceptual, reprezentnd cheia independenei logice de date; corespondena extern-extern permite definirea unor vizualizri externe n funcie de altele, fr a necesita o definiie explicit a corespondenei cu nivelul conceptual. Arhitectura funcional de referin propus de grupul de lucru ANSI/X3/SPARC este axat pe dicionarul datelor i cuprinde dou pri: prima, permite descrierea datelor (compoziia dicionarului datelor); a doua, permite prelucrarea datelor (interogarea i reactualizarea bazei de date). n fiecare parte se regsesc cele trei niveluri: intern, conceptual i extern. Acestea nu sunt neaprat distincte pentru orice SGBD. Interfeele numerotate din figura 1.1, ce descriu arhitectura de referin a unui SGBD, corespund urmtoarelor transformri: a) Limbaj de descriere a datelor conceptuale, format surs permite administratorului ntreprinderii s defineasc schema conceptual, format surs.

12

Limbaj de descriere a datelor conceptuale, format obiect se obine din compilarea celui precedent i permite aranjarea schemei obiect n dicionarul datelor. c) Limbaj de descriere a datelor conceptuale, format editare permite administratorilor aplicaiilor i a bazelor s consulte schema conceptual pentru a defini reguli de coresponden. d) Limbaje de descriere a datelor externe, format surs permit administratorilor aplicaiilor s defineasc scheme externe corespunznd schemei conceptuale. Deoarece sistemele de gestiune pot suporta mai multe modele externe, pot exista mai multe limbaje de descriere a datelor externe. e) Limbaje de descriere a datelor externe, format obiect corespund formelor compilate ale celor precedente i permit aranjarea schemelor externe (obiect) n dicionarul datelor. f) Limbaj de descriere a datelor interne, format surs permite administratorului bazei de date s defineasc schema intern i regulile de coresponden cu schema conceptual. g) Limbaj de descriere a datelor interne, format obiect corespunde formei compilate a celui precedent i permite aranjarea schemei interne (obiect) n dicionarul datelor. h) Limbaje de prelucrare a datelor externe, format surs permit programatorilor de aplicaii sau utilizatorilor neinformaticieni s manipuleze date externe (view). i) Limbaje de prelucrare a datelor externe, format obiect corespund formelor compilate ale celor precedente. j) Limbaj de prelucrare a datelor conceptuale, format obiect produs de procesorul de transformare extern/ conceptual pentru a manipula datele externe. k) Limbaj de prelucrare a datelor interne, format obiect produs de procesorul de transformare conceptual/intern pentru a gestiona datele interne. l) Limbaj de stocare a datelor, format obiect corespunde interfeei cu sistemul de stocare a datelor. m) Interfaa cu memoria secundar permite efectuarea de intrri/ieiri n/din unitatea de memorie secundar. n) Interfaa de acces la dicionarul datelor permite diverselor procesoare de transformare s acceseze scheme obiect i reguli de coresponden.
b)

13

Procesoarele din figura 1.1 au urmtoarele funcii: procesorul schemei conceptuale compileaz schema conceptual i dac nu sunt erori depune schema compilat n dicionarul datelor; procesorul schemei externe compileaz schemele externe i regulile de coresponden extern i dac nu sunt erori aranjeaz schema compilat i regulile de coresponden n dicionarul datelor; procesorul schemei interne are rol similar pentru schema intern; procesorul de transformare extern/conceptual transform manipulrile externe n manipulri conceptuale i invers, datele conceptuale n date externe; procesorul de transformare conceptual/intern transform manipulrile conceptuale n manipulri interne i invers, datele interne n date conceptuale; procesorul de transformare intern/stocare transform manipulrile interne n primitive ale sistemului de stocare i invers, elibereaz datele stocate ntr-un format corespunztor schemei interne.

14
administrator ntreprindere

a DESCRIERE h PRELUCRARE
administratorul bazei de date

procesor schema conceptual

administratorul aplicaiilor

b f

procesor schema intern

dicionarul datelor

e
procesor schema extern

procesor intern/ alocare

procesor conceptual/ intern

procesor extern/ conceptual

l
sistem de alocare

i
program aplicaii extern

h m
programator aplicaie

utilizatori

memorii secundare

Fig. 1.1. Arhitectura de referin a unui SGBD. Gardarin a propus o arhitectur funcional apropiat de arhitectura sistemelor de gestiune actuale care are la baz doar dou niveluri: schema, care corespunde integrrii schemelor interne i conceptuale; vizualizarea, care este o schem extern.

15

Sistemul de gestiune gestioneaz un dicionar de date care este alimentat prin comenzi de definire a schemei i prin comenzi de definire a vizualizrilor. Aceste comenzi, precum i cererile de prelucrare sunt analizate i tratate de un procesor numit analizor. Analizorul realizeaz analiza sintactic i semantic a cererii i o traduce n format intern. O cerere n format intern care face referin la o vizualizare este tradus n una sau mai multe cereri care fac referin la obiecte ce exist n baza de date (modificarea cererilor). n cadrul acestei arhitecturi exist un procesor, numit translator, care realizeaz modificarea cererilor, asigur controlul drepturilor de acces i controlul integritii n cazul reactualizrilor. Componenta cheie a sistemului de gestiune este procesorul optimizor care elaboreaz un plan de acces optim pentru a trata cererea. Acest procesor descompune cererea n operaii de acces elementare i alege o ordine de execuie optimal. De asemenea, evalueaz costul planului de acces naintea execuiei sale. Planul de acces ales i elaborat de optimizor este executat de un procesor numit executor. La acest nivel este gestionat controlul concurenei.

1.4. Evoluia bazelor de date

Istoria bazelor de date i a sistemelor de gestiune a bazelor de date poate fi rezumat n trei generaii: sisteme ierarhice i reea, sisteme relaionale, sisteme avansate (orientate obiect, relaionale orientate obiect, deductive, distribuite, multimedia, multibaze, active, temporale, decizionale, magazii de date etc.). Baze de date ierarhice i reea Pentru modelele ierarhice i reea, datele sunt reprezentate la nivel de articol prin legturi ierarhice (arbore) sau de tip graf. Slaba independen fizic a datelor complic administrarea i prelucrarea acestora. Limbajul de prelucrare a datelor impune programatorului s specifice drumurile de acces la date.

Baze de date relaionale A doua generaie de SGBD-uri este legat de apariia modelelor relaionale (1970), care trateaz entitile ca nite relaii. Piaa actual de baze de date este acoperit n majoritate de sisteme relaionale. Bazele de date relaionale sunt caracterizate de: structuri de date simple, intuitive, inexistena pointerilor vizibili pentru utilizator, constrngeri de integritate, operatori aplicai relaiilor care permit definirea, cutarea i reactualizarea datelor. Dezvoltarea unei aplicaii riguroase utilizand o baz de date relaionale necesit cunoaterea a trei niveluri de instrumente, eterogene din punct de vedere conceptual: nivelul instrumentelor grafice (interfaa); nivelul aplicaie, cu limbajele sale de dezvoltare; nivelul SGBD, cu standardul SQL (Structured Query Language) ce permite definirea, prelucrarea i controlul bazei de date. Baze de date orientate obiect Bazele de date relaionale nu folosesc ns obiecte complexe i dinamice, nu realizeaz gestiunea datelor distribuite i nici gestiunea cunotinelor. A treia generaie de SGBD-uri, sistemele avansate, ncearc s depeasc aceste limite ale sistemului relaional. Suportul obiectelor complexe i dinamice i prelucrarea acestora este dificil pentru sistemele relaionale, deoarece tipul datelor este limitat la cteva domenii alfanumerice, iar structura datelor este simpl. Sistemele relaionale nu modeleaz obiecte complexe ca grafuri, liste etc. Un obiect complex poate s fie descompus n relaii, dar apar dificulti att la descompunerea, ct i la refacerea acestuia prin compunere. De asemenea, limbajele modelului relaional permit prelucrarea cu dificultate a obiectelor complexe. Un sistem relaional nu suport obiecte dinamice care incorporeaz att partea de date (informaii) efective, ct i o parte relativ la tratarea acestora. mbinarea tehnicii limbajelor orientate obiect cu a bazelor de date a permis realizarea bazelor de date orientate obiect. Acestea permit organizarea coerent a obiectelor partajate ntre utilizatori concureni. Sistemele de gestiune de baze de date orientate obiect (SGBDOO) prezint o serie de avantaje:

16

17

realizeaz o modelare superioar a informaiei, furnizeaz posibiliti superioare de deducie (ierarhie de clase, motenire), permit luarea n considerare a aspectelor dinamice i integrarea descrierii structurale i comportamentale, asigur mbuntirea interfeei cu utilizatorul. Cu toate avantajele incontestabile oferite de SGBDOO-uri, impunerea lor pe piaa bazelor de date nu a fost uoar. Cteva motivaii a acestei situaii: absena unei fundamentri teoretice face imposibil definirea unui SGBDOO de referin; gestiunea obiectelor complexe este mai dificil dect accesul la relaii prin cereri SQL; utilizatorii au investit sume uriae n sistemele relaionale i nu le pot abandona cu uurin. Trecerea la noua tehnologie orientat obiect implic investiii mari i nu pstreaz aproape nimic din vechile soluii. Baze de date relaionale orientate obiect Simplitatea modelului relaional, combinat cu puterea tehnologiei orientate obiect a generat un domeniu nou i promitor n lumea bazelor de date, i anume bazele de date relaionale orientate obiect. Construcia unui sistem de gestiune de baze de date relaionale orientate obiect (SGBDROO) trebuie s porneasc de la cele existente. Aceasta se poate realiza n dou moduri: dezvoltnd un sistem relaional prin adugarea caracteristicilor obiectuale necesare sau pornind de la un sistem orientat obiect i adugnd caracteristicile relaionale. Baze de date deductive O relaie este o mulime de nregistrri ce reprezint fapte. Cunotinele sunt aseriuni generale i abstracte asupra faptelor. Cunotinele permit s raionezi, ceea ce permite deducerea de noi fapte, plecnd de la fapte cunoscute. Un SGBD relaional suport o form limitat de cunotine, i anume constrngerile de integritate, iar restul trebuie integrate n programele de aplicaie. Aceasta genereaz probleme deoarece cunotinele trebuie codificate n programe i apare imposibilitatea de a partaja cunotine ntre utilizatori. Totul se complic dac exist un volum mare de fapte.

18

Bazele de date deductive, utiliznd programarea logic, gestioneaz cunotine relativ la baze de date care, n general, sunt relaionale. Bazele de date deductive permit deducerea de noi informaii, plecnd de la informaiile stocate n baza de date. Un SGBD deductiv posed: un limbaj de definire a datelor care permite definirea structurii predicatelor sub form de relaii i constrngeri de integritate asociate; un limbaj de prelucrare a datelor care permite efectuarea reactualizrilor asupra datelor i formularea unor cereri; un limbaj de reguli de deducie care permite ca, plecnd cu predicatele definite anterior, s se specifice cum pot fi construite predicate derivate.

Baze de date distribuite Un sistem distribuit este un ansamblu de maini ce sunt interconectate printr-o reea de comunicaie i utilizate ntr-un scop global. Administrarea i prelucrarea datelor distribuite, situate pe diferite calculatoare i exploatate de sisteme eterogene este obiectivul fundamental al bazelor de date distribuite. Bazele de date distribuite sunt sisteme de baze de date cooperante care rezid pe maini diferite, n locuri diferite. Aceast mulime de baze de date este exploatat de utilizator ca i cum ar fi o singur baz de date. Programul de aplicaie care exploateaz o baz de date distribuite poate avea acces la date rezidente pe mai multe maini, fr ca programatorul s cunoasc localizarea datelor. Modelul relaional a rmas instrumentul principal prin care se realizeaz prelucrarea datelor distribuite. Cteva dintre argumentele pentru a justifica aceast afirmaie sunt: bazele relaionale ofer flexibilitate de descompunere n vederea distribuirii; operatorii relaionali pot fi folosii pentru combinaii dinamice ale informaiilor descentralizate; limbajele sistemelor relaionale sunt concise i asigur o economie considerabil a transmiterii datelor. Ele fac posibil, pentru un nod oarecare al reelei, s analizeze intenia unei tranzacii, s o descompun rapid n componente ce pot fi realizate local i componente ce pot fi transportate altor noduri.

19

Calculatoare i maini baze de date Soluia pentru a descentraliza prelucrarea datelor, n scopul evitrii saturrii memoriei i a procesoarelor calculatorului central, a fost apariia calculatoarelor baze de date i a mainilor baze de date. Descentralizarea presupune transferarea unei pri din funciile unui SGBD ctre un calculator periferic (calculator backend) adic deplasarea algoritmilor de cutare i a celor de actualizare a datelor mai aproape de memoria secundar. Acest calculator periferic permite utilizarea optim a resurselor i realizarea paralelismului n tratarea cererilor de informaii. Calculatorul periferic poate fi un calculator clasic, dar cu un software specific de SGBD (calculator baz de date) sau poate fi o main cu hardware specializat n gestiunea bazelor de date (main baz de date). Mainile baze de date sunt nzestrate cu arhitecturi paralele special adaptate pentru gestionarea unui volum mare de date. Tratarea paralel a cererilor permite reducerea timpului total de execuie a acestora. O execuie n paralel solicit, fie descompunerea unui program n module, care pot fi executate n paralel (descompunere funcional), fie descompunerea datelor n subgrupe, astfel nct toate procesoarele s execute acelai lucru, dar pe date diferite. Performanele tratrii paralele depind de modul n care sunt efectuate descompunerile. Multibaze de date Diferite departamente ale unei organizaii mai mari pot folosi diferite sisteme de gestiune. Cu toate c fiecare sistem este dezvoltat pentru a satisface nevoile propriului su departament, informaiile cu care lucreaz pot fi utile i altor departamente. De aceea, pentru ca organizaia s funcioneze bine, trebuie s existe o modalitate global da a vedea datele din fiecare sistem. Exist dou caracteristici ale unor astfel de sisteme care fac acceasarea datelor n acest mediu integrat greoaie, uneori chiar imposibil: autonomie fiecare SGBD are o autonomie complet, ceea ce nseamn c fiecare manager are control deplin asupra sistemului; eterogenitate sistemele pot opera pe diferite platforme, cu diferite modele de date i limbajele de interogare. Una dintre soluiile folosite pentru a depi dificultile ntmpinate n respectarea autonomiei i a eterogenitii este utilizarea sistemelor multibaze de date.

20

Un sistem multibaze de date (SMB) este alctuit din mai multe sisteme de baze de date privite integrat, n care se construiesc una sau mai multe scheme globale pe baza schemelor fiecrei baze de date componente, astfel nct s se poat realiza accesul uniform i integrat la fiecare din bazele de date componente. Fiecare schem global este construit pe baza unui model particular de date. De exemplu, se poate construi o schem global ce are la baz modelul relaional pentru utilizatorii care sunt familiarizai cu acest model, dar se poate construi o schem global bazat pe modelul orientat obiect pentru utilizatorii bazelor de date orientate obiect. Pentru o schem global dat, un sistem multibaze de date const din sistemele componente mpreun cu un sistem front-end, care suport un singur model de date i un singur limbaj de interogare. Principalele sarcini ale sistemului front-end sunt gestionarea schemei globale i procesarea cererilor globale. Un avantaj major al acestui model, fa de altele, este faptul c o singur interogare poate accesa date din mai multe baze de date ntr-un mod integrat, fr s afecteze nici o aplicaie care este scris utiliznd una dintre bazele de date componente. Baze de date cu suport decizional Sistemele informatice, n particular bazele de date, au ajuns la maturitate. Marile companii au acumulat o mare cantitate de informaii din domeniul lor de activitate, pe care le pstreaz n tabele istorice i sunt nefolositoare sistemelor operaionale ale companiei, care funcioneaz cu date curente. Analizate, aceste date ar putea oferi informaii despre tendine i evoluii care ar putea interesa compania. Pentru a putea analiza aceste mari cantiti de date este nevoie de tehnologii i instrumente speciale. Ideea de a analiza colecii de date provenind din sistemele operaionale ale companiei sau din surse externe pentru a le folosi ca suport n procesul de decizie nu aparine ultimului deceniu, dar baze de date care s funcioneze eficient dup aceste criterii au fost studiate i implementate n ultimii ani. Principalul scop al acestor baze de date a fost de a ntmpina nevoile sistemelor operaionale, a cror natur este inerent tranzacional. Sistemele tranzacionale sunt interesate, n primul rnd, s controleze la un moment dat o singur tranzacie. De exemplu, ntr-un sistem bancar, atunci cnd clientul face un depozit, sistemul operaional bancar este responsabil de a nregistra tranzacia ntr-un tabel al tranzaciilor i de a crete nivelul curent al contului clientului, stocat n alt tabel.

21

Un sistem operaional tipic opereaz cu evenimente predefinite i, datorit naturii lor, necesit acces rapid la date. Uzual, fiecare tranzacie opereaz cu cantiti mici de date. De-a lungul timpului, nevoile sistemelor operaionale nu se schimb mult. Aplicaia care nregistreaz tranzacia, ca i cea care controleaz accesul utilizatorului la informaie (partea de raportare a sistemului bancar), nu se modific prea mult. n acest tip de sistem, informaia necesar n momentul n care un client iniiaz o tranzacie trebuie sa fie actual. nainte ca o banc s aprobe un mprumut este nevoie s se asigure de situaia financiar stabil a clientului n acel moment, i nu cu un an nainte. n ultimii ani s-au pus la punct principii i tehnologii noi care s serveasc procesului de analiz i administrare a datelor. O baz de date optimizat n acest scop definete o Data Warehouse (magazie de date), iar principiul pe care l urmeaz este cunoscut sub numele de procesare analitic (OLAP On Line Analytical Processing). Spre deosebire de acesta, principiul pe care se bazeaz sistemele tranzacionale a fost numit procesare tranzacional (OLTP On Line Transactional Processing). Aplicaiile unei Data Warehouse trebuie s ofere rspunsuri unor ntrebri de tipul: Care zi din sptmn este cea mai aglomerat? Ce clieni, cu care avem relaii intense, nu au beneficiat de reduceri de preuri?. O caracteristic a bazelor de date analitice este c interogrile la care acestea trebuie s rspund sunt ad-hoc, nu sunt predefinite, iar baza de date trebuie optimizat astfel nct s fie capabil s rspund la orice fel de ntrebare care poate implica mai multe tabele. n aceast abordare, organele generale de decizie necesit accesul la toate datele organizaiei, oriunde s-ar afla acestea. Pentru o analiz corespunztoare a organizaiei, afacerilor, cerinelor, tendinelor este necesar nu numai accesarea valorilor curente din baza de date, ci i a datelor istorice. Prin urmare, pentru a facilita acest tip specific de analiz a informaiei a fost creat magazia de date, care conine informaii extrase din diverse surse, ntreinute de diverse uniti operative, mpreun cu istoricul i rezumatul tranzaciilor. Sursele de date pentru o magazie cuprind: date operaionale, pstrate n baze de date ierarhice, de prima generaie; date departamentale, pstrate n sisteme de fiiere patentate;

22

date cu caracter personal, pstrate pe staii de lucru i servere personale; sisteme externe (baze de date comerciale, Internet etc.) Data warehouse este o colecie de date: orientate spre subiect (principalele subiecte ale modelului sunt clienii, produsele, vnzrile, n loc de domeniile de activitate), nevolatile (datele nu sunt reactualizate, nlocuite n timp real, ci sunt adugate ca un supliment al bazei), integrate (transpunerea datelor provenite din diverse surse de informaii se face ntr-un format consistent), variabile n timp (concentrarea depozitului de date se face asupra schimbrilor care au loc n timp).
Administrator Depozit de date META-FLUX Sursa 1 Date operationale Utilitare cereri, rapoarte

Metadate Date cu nivel mare de agregare Administrator incarcare date Administrator cereri FLUX Date cu nivel EXTERN mic de agregare FLUX ASCENDENT Date detaliate SGBD

FLUX INTERN

Utilitare OLAP

Utilitare Data mining

Sursa n Date operationale

Administrator Depozit de date Utilitare pentru accesul utilizatorilor finali

Arhive/ date backup

FLUX DESCENDENT

Fig 1.2. Arhitectura unui depozit de date nmagazinarea datelor se concentreaz asupra gestionrii a cinci fluxuri de informaii:

23

fluxul intern, care reprezint procesele asociate extragerii i ncrcrii datelor din fiierele surs n magazia de date; fluxul ascendent, care reprezint procesele asociate adugrii de valoare datelor din magazie, cu ajutorul mpachetrii i distribuirii; fluxul descendent, care reprezint procesele asociate arhivrii, salvrii, refacerii datelor din magazie; fluxul extern, care reprezint procesele asociate punerii la dispoziie a datelor pentru utilizatorii finali; meta-fluxul, care reprezint procesele asociate gestionrii metadatelor (date despre date). n arhitectura depozitului de date intervin cteva componente specifice acestei structuri. Administratorul pentru ncrcarea datelor (componenta front-end) realizeaz toate operaiile asociate cu obinerea (extragerea) i ncrcarea datelor operaionale ntr-un depozit de date. Administratorul depozitului de date realizeaz toate operaiile legate de administrarea datelor din depozit. Operaiile realizate de componenta de administrare a depozitului de date includ: analiza datelor pentru a asigura consistena acestora; transformarea i mutarea datelor surs din structurile temporare de stocare n tabelele depozitului de date; crearea de indeci i vizualizri asupra tabelelor de baz; generarea denormalizrii (dac este necesar); generarea agregrilor; crearea arhivelor i a backup-urilor. Administratorul cererilor (componenta back-end) realizeaz toate operaiile legate de administrarea cererilor utilizator. Aceast component este construit folosind utilitarele de acces la date disponibile utilizatorilor finali, utilitarele de monitorizare a depozitului de date, facilitile oferite de sistemul de baze de date i programele personalizate. n zona ce include date agregate sunt stocate toate agregrile predefinite de date, pe diferite niveluri. Scopul, meninerii acestora, este de a mri performana cererilor care necesit agregri. Datele agregate sunt actualizate permanent, pe msur ce sunt ncrcate noi informaii n depozit. Scopul principal al depozitelor de date este de a oferi informaii necesare utilizatorilor pentru luarea deciziilor strategice de marketing. Aceti utilizatori interacioneaz cu depozitul de date prin diferite utilitare de acces (utilitare pentru rapoarte i cereri,

24

utilitare pentru dezvoltarea aplicaiilor, utilitare pentru procesarea analitic on-line (OLAP), utilitare data mining) etc. Instrumentele de acces pentru utilizatorii finali ai magaziilor de date: prelucrarea analitic on-line; extensiile limbajului SQL; instrumentele de extragere a datelor. Prelucrarea analitic on-line (OLAP) reprezint sinteza, analiza i consolidarea dinamic a unor volume mari de date multidimensionale. Serverele de baze de date OLAP utilizeaz structuri multidimensionale pentru stocarea datelor i a relaiilor dintre date. Aceste structuri pot fi vizualizate prin cuburi de date i cuburi n cadrul cuburilor etc. Fiecare latur a cubului reprezint o dimensiune. Serverele de baze de date OLAP multidimensionale accept operaiile analitice uzuale: consolidarea (gruparea), parcurgerea n jos (inversul consolidrii), tranarea, tierea. OLAP necesit o modalitate de agregare a datelor conform mai multor grupri diferite, n numr foarte mare, iar utilizatorii trebuie s le aib n vedere pe toate. Instrumentele OLAP presupun organizarea informaiei ntr-un model multidimensional care este susinut de o baz de date: multidimensional (MOLAP), n care datele sunt stocate conceptual n celulele unui tablou multidimensional; relaional (ROLAP), proiectat pentru a permite interogri multidimensionale. n acest context, a devenit o necesitate extinderea limbajului SQL prin operaii puternice, necesare pentru rezolvarea noului tip de abordare. Au fost introduse noi funcii numerice (limita inferioar, limita superioar etc.), noi funcii statistice (distribuie, distribuie invers, corelaie etc.), noi operatori de agregare, extensii ale clauzei GROUP BY etc. De exemplu, RISQL (Red Brick Intelligent SQL), proiectat pentru analitii din domeniul afacerilor, permite: ordonare dup rang (pe diferite niveluri - de exemplu, gruparea filialelor n trei categorii pe baza venitului generat n anul precedent), partajarea pieei, compararea anului curent cu cel precedent etc. O alt problem esenial este extragerea datelor i utilizarea acestora pentru luarea de decizii cruciale n domeniul afacerilor. Descoperirea unor noi corelaii, tipare, tendine, prin extragerea unor cantiti mari de date folosind strategia inteligenei artificiale este una din modalitile de rezolvare. Extragerea datelor presupune capacitatea de a construi modele mai degrab previzibile, dect retrospective. Modelarea predictiv utilizeaz

25

informaii pentru a forma un model al caracteristicilor importante ale unui fenomen. Tehnicile asociate operaiilor fundamentale de extragere sunt: modelarea predictiv (clasificarea cu ajutorul unei reele neurale sau al unei inducii de tip arbore i previziunea valorilor, utiliznd tehnici de regresie); segmentarea bazei de date (comasarea demografic i comasarea neural care se deosebesc prin metodele uilizate pentru a calcula distana dintre nregistrri, prin intrrile de date permise); analiza legturilor (descoperirea asocierilor, descoperirea tiparelor, descoperirea secvenelor de timp similare); detectarea deviaiilor (statistici i vizualizri pentru identificarea mprtierii datelor, utiliznd tehnici moderne de vizualizare grafic). n aceast clas pot fi considerate, de exemplu, detectarea fraudelor privind utilizarea crilor de credit, preteniile de despgubire ale asigurailor etc. n concluzie, spre deosebire de un sistem OLTP, Data Warehouse este o baz de date a crei structur este proiectat pentru a facilita analiza datelor. Un sistem de suport decizional urmrete, n primul rnd, obinerea de informaii din baza de date, n timp ce unul OLTP urmrete introducerea de informaii n baza de date. Datorit acestor diferene, structura optim a unei Data Warehouse este radical diferit de cea a unui sistem OLTP. Depozitele de date i sistemele OLTP sunt supuse unor cerine diferite, dintre care cele mai semnificative se refer la operaii, actualizarea datelor, proiectare, operaii tipice i date istorice. Operaii. Depozitele sunt create pentru a permite interogri ad hoc. Ele trebuie s fie suficient de flexibile pentru a putea rspunde interogrilor spontane ale utilizatorilor. Sistemele OLTP suport numai operaii predefinite. Aplicaiile pot fi optimizate sau create special numai pentru acele operaii. Actualizarea datelor. Utilizatorii finali ai unui depozit de date nu fac n mod direct actualizri ale depozitului. n sistemele OLTP, utilizatorii realizeaz, de obicei, n mod individual procedurile de modificare a bazei de date. n acest fel, baza de date OLTP este ntotdeauna la zi i reflect starea curent a fiecrei tranzacii. Proiectare. Depozitele de date folosesc, n mod uzual, scheme denormalizate, n timp ce sistemele OLTP folosesc scheme normalizate pentru a optimiza performanele operaiilor.

26

Operaii tipice. O simpl interogare a depozitului de date poate scana mii sau chiar milioane de nregistrri (de exemplu, cererea Care sunt vnzrile totale ctre toi clienii din luna trecut?), n timp ce o operaie tipic OLTP acceseaz doar o parte mai mic din nregistrri. Date istorice. Depozitele de date stocheaz datele pe o perioad lung de timp, luni sau ani. Acest lucru ofer suport pentru analiza istoric a informaiei. Sistemele OLTP rein date istorice att timp ct este necesar pentru a ndeplini cu succes cerinele tranzaciilor curente. Sistemele OLTP Pstreaz date curente Data Warehouse Pstreaz date istorice Stocheaz date detaliate, agregate uor Stocheaz date detaliate sau puternic Datele sunt dinamice Datele sunt n mare msur statice Prelucrare ad-hoc, nestructurat i Prelucrare repetitiv euristic Nivel nalt de transfer al Nivel mediu sau sczut de transfer al tranzaciilor tranzaciilor Tipar de utilizare previzibil Tipar de utilizare imprevizibil Conduse prin tranzacii Susin deciziile de zi cu zi Deservesc un numr mare de utilizatori Orientate spre aplicaii Conduse prin analiz Susin deciziile strategice Deservesc un numr relativ redus de utilizatori din administraie Orientate spre subiect

Fig. 1.3. OLTP versus Data Warehouse O baz de date OLAP poate fi relaional, dar datorit naturii ei orientate spre dimensiuni, au fost dezvoltate pentru gestionarea acestor baze de date construcii multidimensionale, mai potrivite pentru o raportare flexibil. Spre deosebire de bazele de date relaionale, structura unei baze de date multidimensionale nu implic tabele, linii i coloane, ci obiecte de urmtoarele tipuri: variabile, dimensiuni, niveluri, ierarhii, atribute. Data Warehouse, care cuprinde de obicei informaii despre o ntreag companie, poate fi submprit n baze de date departamentale, numite rafturi de date (Data Marts). De exemplu, poate exista un Data

27

Mart al departamentului financiar, un altul al departamentului vnzri i un altul pentru departamentul marketing. Construcia unei astfel de baze de date poate fi abordat n dou moduri. O prim abordare este de a construi mai nti un schelet al bazei de date la care se lipesc ulterior rafturile de date. Aceasta necesit o analiz prealabil a ntregului i o delimitare a blocurilor componente. Ea cere un timp mai lung de dezvoltare, dar rezultatul este o baz de date unitar. A doua metod este de a construi mai nti rafturi specifice, efortul constnd, n acest caz, n asocierea acestora. Aceast soluie ofer mai rapid, aplicaii funcionale utilizatorilor, dar au de suferit unitatea i portabilitatea aplicaiilor finale. Utilizatorii trebuie s-i schimbe optica asupra bazelor de date pentru a fi capabili s foloseasc puterea i flexibilitatea instrumentelor analitice de care dispun. Instrumentele OLAP au evoluat ca o modalitate de a rezolva interogrile complicate necesare procesului de analiz a datelor. Combinaia ntre bazele de date multidimensionale i instrumentele analitice prietenoase face uoar analiza, sinteza i consolidarea datelor. n ultimii ani, marii productori de sisteme de gestiune a bazelor de date relaionale, precum Oracle, au introdus n produsele lor construcii care s faciliteze accesul la datele din sistemele fundamentale pentru luarea de decizii. Astfel, noile versiuni de SGBD-uri ale firmelor mari prevd o modalitate mai inteligent de a realiza operaia de compunere ntre dou sau mai multe tabele, metode de indexare noi, potrivite pentru marile cantiti de date statice cu care opereaz sistemele Data Warehouse, capacitatea de a detecta i optimiza interogri de un tip special, posibilitatea de a folosi mai multe procesoare pentru a rezolva o interogare. Un sistem Data Warehouse are un efect fundamental asupra utilizatorilor. Ei pot manevra mult mai flexibil sistemul, au posibiliti elevate pentru interogarea datelor, dar ei trebuie s tie cum s prelucreze i s vizualizeze datele i cum s le foloseasc n procesul de decizie. Un efort ce trebuie fcut pentru construirea unui sistem de suport pentru decizii (DSS Decision Support System) const n procesul de descoperire a informaiilor utile din baza de date. Acest proces, numit Data Mining sau Knowledge Discovery in Databases (KDD), proceseaz mari cantiti de date, a cror corelare nu este neaprat evident, n vederea descoperirii de tendine i tipare.

28

1.5. Arhitecturi multi-user pentru sisteme de gestiune a bazelor de date

Arhitecturile uzuale care sunt utilizate pentru implementarea sistemelor de gestiune a bazelor de date multi-user sunt: teleprocesarea, arhitectura fiier-server arhitectura client-server. Teleprocesarea este arhitectura tradiional, ce cuprinde un calculator cu o singur unitate CPU i un numar de terminale care sunt incapabile s funcioneze singure. Terminalele trimit mesaje la programele aplicaie ale utilizatorilor, care la rndul lor, utilizeaz serviciile SGBD. Aceast arhitectur a plasat o greutate teribil asupra calculatorului central, care pe lng rularea programelor de aplicaii i ale SGBD-ului, mai trebuie s preia i din munca terminalelor (de exemplu, formatarea datelor pentru afiarea pe ecran). Arhitectura fiier-server, presupune deja c procesarea este distribuit n reea (de obicei o reea local LAN). Arhitectura cuprinde fiierele cerute de aplicaii i SGBD-ul. Aplicaiile i funciile SGBD sunt executate pe fiecare staie de lucru, solicitnd cnd este nevoie fiiere de pe server-ul de fiiere. Dintre dezavantaje se remarc: existena unui trafic intens pe reea; necesitatea unei copii complete a SGBD-ului pe fiecare staie de lucru; acelai fiier poate fi accesat de mai multe SGBD-uri, ceea ce implic un control complex al integritii, simultaneitii, reconstituirii. Arhitectura client-server se refer la modul n care interacioneaz componentele software pentru a forma un sistem. Exist un proces client, care necesit resurse i un proces server, care ofer resurse. n arhitectura client-server, clientul (front end) emite, prin intermediul reelei locale, o cerere SQL care este executat pe server (backend); acesta trimite ca rspuns ansamblul nregistrrilor rezultat. ntr-o astfel de interaciune mainile sunt eterogene, iar protocoalele de reea pot fi distincte. n contextul bazelor de date, client-ul: administreaz interfaa cu utilizatorul i logica aplicaiei; accept i verific sintaxa intrrilor utilizatorilor; proceseaz aplicaiile; genereaz cerinele pentru baza de date i le trimite server-ului;

29

transmite rspunsul napoi la utilizator. n contextul bazelor de date, server-ul: primete i proceseaz cerinele clienilor pentru baza de date; verific autorizarea; garanteaz respectarea constrngerilor de integritate; efectueaz procesarea interogare-reactualizare i trimite clientului rspunsul; realizeaz optimizarea interogrilor; asigur controlul concurenei dintre mai multi clieni care se ignor (mecanisme de blocare); intreine dictionarul datelor; ofer acces simultan la baza de date; asigur robusteea n cazul defeciunilor; ofer controlul reconstituirii etc. Arhitectura tradiional client-server pe dou etaje (straturi) presupune: client-ul responsabil, n primul rand, de prezentarea datelor ctre client; server-ul responsabil, n primul rand, de furnizarea serviciilor ctre client. Arhitectura client-server pe trei etaje presupune trei straturi, fiecare fiind rulat, potenial, pe o platform diferit. stratul (client) format din interfaa cu utilizatorul, care este rulat pe calculatorul utilizatorului final; stratul (server de aplicaie), ce manevreaz logica aplicaiilor i prelucrrii datelor, i care poate servi mai muli clieni (conectare la celelalte dou straturi se face prin reele locale LAN sau de mare suprafa WAN); stratul (server-ul de baze de date), care se ocup cu validarea datelor i accesarea bazei de date (stocheaz date necesare stratului din mijloc). Arhitectura se potrivete natural mediului Web. Un browser Web acionnd drept client i un server Web fiind server de aplicaie. Middleware este un strat, evident software, ntre aplicaia postului client i server-ul de baze de date, constituit dintr-o interfa de programare a aplicaiilor (API - Application Programming Interface) i un protocol de reea.

30

API descrie tipul de interaciune dintre o aplicaie client i un server la distan, via un protocol de comunicaie i de formatare a datelor. Scopul existenei interfeei de programare a aplicaiilor este de a oferi o interfa unic mai multor server-e de baze de date. Este convenabil ca sistemele de baze de date s fie considerate ca fiind formate dintr-un server (sistemul SGBD nsi) i un set de clieni (aplicaiile). Frecvent, clienii i server-ul pot fi rulate pe calculatoare diferite, realizndu-se un tip simplu de procesare distribuit. n general, fiecare server poate deservi mai multi clieni, iar fiecare client poate accesa mai multe server-e. Dac sistemul ofer transparen total (fiecare client se poate comporta ca i cum ar comunica cu un singur server, de pe un singur calculator) atunci este vorba despre un sistem de baze de date distribuite.

1.6. Tehnologia Web i sistemele SGBD

Internet = o colecie mondial de reele de calculatoare. Intranet = un sit Web sau un grup de sit-uri care aparin unei organizaii, accesibil numai pentru membrii acesteia. Extranet = o reea intranet care este parial accesibil utilizatorilor externi autorizai. Reea Web (World Wide Web) = un sistem bazat pe hipermedii care pune la dispoziie un mijloc simplu, de tip indicare-clic de rsfoire a informaiilor pe Internet, folosind hiperlegturile. HTTP = protocolul utilizat pentru a transfera pagini Web prin intermediul Internetului. HTML = limbajul de formatare a documentelor utilizat n proiectarea majoritii paginilor Web. Adresa URL = ir de caractere alfanumerice care reprezint adresa unei resurse pe Internet i modul n care trebuie accesat resursa. Interfaa de poart comun (CGI) = definete modul n care scripturile comunic cu server-ul Web. Este tehnica de baz de integrare a bazelor de date n reeaua Web. n mediul Web funcioneaz modelul three tier format din: un strat de interfa cu utilizatorul (client), un strat de logic a afacerii i prelucrare a datelor (server de aplicaii), un sistem SGBD (server de baze de date) distribuit pe calculatoare diferite. Avantajele reelei Web ca platform de baze de date: avantagele SGBD;

31

simplitate; independena de platform; interfaa grafic cu utilizatorul; acces transparent n reea; standardizare (HTML standard de facto). Arhitectura de calcul n reea a sistemului Oracle (NCA Network Computing Architecture) se axeaz n principal pe furnizarea extensibilitii pentru mediile distribuite. Arhitectura este construit pe baza tehnologiei CORBA pentru manipularea obiectelor. Este o structur three tier care se bazeaz pe utilizarea de: cartue de software care permit utilizatorilor s adauge funcionaliti individuale n aplicaii (cartuele pot fi construite n Java, C/C++, Visual Basic, SQL i pot fi conectate la oricare din cele 3 straturi); protocoale deschise i interfee standardizate care permit comunicarea ntre cartue (distribuite ntr-o reea) prin intermediul unui program magistral (ICX); clieni extensibili, server-e de aplicaie, server-e de baze de date; dezvoltarea i administrarea integrat a cartuelor. Un cartus utilizeaza un limbaj de definire a interfetelor (IDL) pentru a putea fi identificat de alte obiecte intr-un sistem distribuit. De exemplu, PL/SQL este un astfel de cartus. Arhitectura cu mai multe niveluri (multitier) conine urmtoarele elemente: unul sau mai muli client-i care iniiaz operaii; unul sau mai multe server-e de aplicaii care execut pri ale operaiilor; un server de baze de date care stocheaz datele folosite de operaii. Client-ul, care poate fi un browser Web sau un proces user, iniiaz o cerere pentru a executa o operaie referitoare la informaiile stocate n baza de date. Conectarea la server-ul bazei de date se face printr-unul sau mai multe server-e de aplicaii. Server-ul de aplicaii constituie interfaa dintre client-i i server-ul bazei de date, asigurnd accesul la informaii. De asemenea, el include un nivel adiional pentru securitate. Server-ul de aplicaii i asum identitatea client-ului, atunci cnd execut, pe server-ul de baze de date, operaiile solicitate de acesta. Arhitectura multitier permite folosirea unui server de aplicaii pentru

Arhitectura multitier a sistemului Oracle9i

acreditarea client-ului, conectarea la server-ul de baze de date i execuia operaiilor iniiate de client. Privilegiile server-ului de aplicaii sunt limitate pentru a preveni execuia operaiilor nedorite sau inutile n timpul unei operaii client. Server-ul de baze de date pune la dispoziia server-ului de aplicaii informaiile necesare pentru soluionarea operaiilor lansate de ctre client. De asemenea, acesta face distincia ntre operaiile pe care server-ul de aplicaii le cere n favoarea client-ului i cele pe care le solicit n nume propriu.

32

Oracle9i Developer Suite

HTTP

Clienti HTTP Nivel 1

Oracle9i Application Server Nivel 2

Oracle9i Database Nivel 3

Fig. 1.4. Arhitectura three-tier a sistemului Oracle9i

2 MODELAREA ENTITATE - RELAIE

Proiectarea bazelor de da te orientate ob iect MODEL AREA BAZELO R D E DAT E

2.1. Preliminarii
Un model este o reprezentare a obiectelor i evenimentelor lumii reale i a asocierilor dintre ele. De fapt, el reprezint o abstracie asupra aspectelor semnificative ale unei ntreprinderi, ale unui sistem real, ignornd proprietile accidentale. Modelul este cel pe care utilizatorii trebuie s-l cunoasc; implementarea unui model este cea pe care utilizatorii nu este necesar s o cunoasc. Diferena dintre model i implementare este, de fapt, un caz special i important al deosebirii uzuale dintre logic i fizic. Modelele se impun prin sintaxa i prin semantica lor i, din acest punct de vedere, exist trei tipuri fundamentale de modele: modele care descriu aspectele statice ale procesului modelat; modele care descriu aspectele dinamice ale procesului modelat; modele care descriu aspectele funcionale ale procesului modelat. Un model de date reprezint o colecie integrat de concepte necesare descrierii: datelor, relaiilor dintre ele, constrngerilor existente asupra datelor sistemului real analizat. Modelarea unei baze de date permite trecerea de la percepia unor fapte din lumea real la reprezentarea lor prin date. Modelul de date trebuie s reflecte fidel fenomene ale lumii reale, s urmreasc evoluia acestei lumi i comunicarea dintre fenomenele lumii reale. Modelul trebuie s asigure conceptele de baz care permit proiectantului bazei de date i utilizatorilor s comunice, fr ambiguiti, cunotinele lor privind funcionarea i organizarea modelului real analizat. Prin urmare, un model de date trebuie s reprezinte datele i s le fac nelese. n esen, modelul de date are trei componente: o mulime de reguli conform crora sunt construite bazele de date (partea structural); o mulime de operaii permise asupra datelor, care sunt utilizate pentru reactualizarea sau regsirea datelor (partea de prelucrare); o mulime de reguli de integritate, care asigur coerena datelor. Abordarea general a problemei modelrii semantice a datelor se face n patru etape.

58

PROIECTAREA BAZELOR DE DATE

Se identific o mulime de concepte semantice care sunt utile n descrierea lumii reale. Se presupune c lumea real (modelul real analizat) este format din entiti care au anumite proprieti, c fiecare entitate are o identitate, c exist legturi, corelaii ntre entiti. Conceptul de corelaie, ca i cel de entitate, este util, n mod intuitiv, la descrierea modelului. Se caut o mulime de obiecte formale, simbolice care sunt utilizate pentru reprezentarea conceptelor semantice anterioare. Se dau reguli de integritate formale i generale (constrngeri) care s reflecte restriciile la care este supus modelul. Se definete o mulime de operatori formali prin care pot fi prelucrate i analizate obiectele formale.

2.2. Modelul entitate-relaie Una dintre cele mai cunoscute abordri ale modelrii semantice (cu siguran una dintre cele mai utilizate) este cea bazat pe modelul entitaterelaie (E/R). Acesta a fost introdus de ctre Peter.P. Chen n 1976 i rafinat de atunci n diverse moduri de ctre acesta i de muli ali cercettori, ca un model de date conceptual, pentru a uura proiectarea bazelor de date. Pentru reprezentarea grafic a modelului sunt utilizate diagramele E/R, care sunt modele neformalizate pentru reprezentarea unui model, unui sistem din lumea real. Diagramele E/R constituie o tehnic de reprezentare a structurii logice a bazei de date, ntr-o manier grafic. Aceste diagrame ofer un mijloc simplu i inteligibil de comunicare a caracteristicilor importante ale designului unei anumite baze de date. Diagrama E/R este un model de date conceptual de nivel nalt, independent de platforma hardware utilizat i de tipul SGBD-ului. Modelul este constituit din concepte care descriu structura bazei de date i tranzaciile de regsire sau reactualzare asociate. Popularitatea modelului E/R ca modalitate de abordare a proiectrii bazelor de date poate fi atribuit n principal tehnicii de realizare a diagramelor E/R. Aceast tehnic, ca i modelul E/R nsui, a evoluat de-a lungul timpului datorit noilor problematici care au aprut n proiectarea bazelor de date. Baza de date poate fi definit ca o mulime de date ce modeleaz un sistem real. Acest sistem este format din obiecte legate ntre ele. Modelul E/R mparte elementele unui sistem real n dou categorii: entiti i relaii (legturi, asocieri) ntre aceste entiti. Entitiile i legturile au anumite caracteristici, numite atribute. Nu trebuie confundat conceptul de relaie, n sensul de asociere, care intervine n definirea diagramei E/R cu conceptul de relaie care este specific modelului relaional.

Modelarea entitate-relaie

59

Studiu de caz Exemplele din acest capitol se refer la proiectarea unui model de date ce furnizeaz informaii despre prezentri de mod, evenimente care reprezint momente importante n lumea caselor de mod. Vom prezenta modelul de date, restriciile pe care trebuie s le respecte i vom ncerca, ntr-o manier didactic, s construim diagrama E/R corespunztoare. Vom considera, n abordarea iniial, anumite situaii care nu sunt optime, n sensul c pot genera redundan, anomalii la reactualizri sau nu permit rezolvarea anumitor interogri asupra modelului. Vom ncerca s artm care sunt deficienele modelului, situaiile care le-au generat i cum pot fi corectate (parial sau total) anomaliile respective. Modelul de date va gestiona informaii legate de organizarea i funcionarea prezentrilor de mod. Exist firme organizatoare care se ocup de buna desfurare a acestor prezentri. O firm organizatoare poate fi contactat prin angajai specializai pe diferite domenii (financiar, social, publicitate, securitate, sisteme de iluminare, coregrafie, sisteme de sonorizare, cazare, primiri/plecri aeroport etc.). Firme specializate sunt angajate pentru soluionarea problemelor legate de securitate, publicitate, asigurri, iar restul problemelor sunt rezolvate cu salariaii proprii ai caselor de mod i a firmei organizatoare. Modalitile de securitate, asigurri, publicitate proprii caselor de mod, modelelor sau ageniilor de modele nu intr n proiectarea modelului. Prezentrile pot fi sponsorizate, considerndu-se doar informaiile referitoare la persoane (fizice sau juridice) care au contribuit efectiv la finanarea prezentrilor de mod. Mai exact, nu sunt inclui sponsorii posibili. La aceste evenimente particip case de mod, care prezint vestimentaii concepute de creatorii casei respective. Creatorii pot fi cei care concep vestimentaia (designeri) sau cei care o realizeaz efectiv, incluznd croitori, lucrtori care se ocup cu broderia sau cu realizarea diverselor accesorii. n cadrul prezentrii de mod, vestimentaiile sunt purtate de manechine care aparin anumitor agenii de modele. Casele de mod angajeaz modele care s le prezinte vestimentaiile cu prilejul acestor evenimente. Modelul de date prezint i un istoric al activitii manechinelor (n cadrul diverselor agenii). Casele de mod angajeaz pentru o prezentare stiliti care se ocup cu machiajul i coafura modelelor. De asemenea, modelul analizeaz informaii legate de localizarea i accesarea firmelor de publicitate, a persoanelor de contact din firmele organizatoare, a caselor de mod, a ageniilor i a modelelor, a sponsorilor, a societilor de asigurare i a firmelor care asigur securitatea evenimentelor. Modelul de date respect anumite restricii de funcionare. Casele de mod pot fi organizatori de prezentri. Chiar dac o cas de mod este organizator, ea apeleaz la serviciile unei firme specializate n organizarea unor astfel de evenimente.

60

PROIECTAREA BAZELOR DE DATE

Un model sau un stilist este angajat (temporar) pentru o prezentare, de o singur cas de mod. O cas de mod poate angaja mai multe modele i mai muli stiliti pentru o prezentare. Orice prezentare de mod are un organizator unic, care poate apela la serviciile altor instituii specializate (securitate, asigurri, publicitate). Pentru organizator s-a considerat un singur cont n/din care se pot face plile. O cas de mod poate avea mai muli designeri, dar un designer poate lucra pentru o singur cas de mod. Pentru contactarea unei persoane fizice sau juridice s-a considerat cte un singur numr de telefon fix, telefon mobil, fax i o singur adres de mail. Pentru localizarea unei persoane fizice sau juridice s-a considerat o singur adres de baz. Sunt luai n considerare doar angajaii firmei de paz i protecie care particip efectiv la asigurarea securitii prezentrilor de mod. Creatorii de accesorii pot fi angajai permaneni ai unei case de mod. Dac pentru anumite vestimentaii sunt necesare accesorii create de specialiti care nu aparin casei de mod, acetia vor fi considerai angajai special pentru evenimentul respectiv. S-a considerat c proprietarul unei case de mod fie este unic, fie, dac sunt mai muli, va fi considerat drept proprietar cel care deine numrul maxim de aciuni. Entitate Entitatea este un obiect sau un concept, care este semnificativ pentru modelul real analizat. O entitate poate fi dependent (slab), existena sa depinznd de alt entitate sau independent (tare), caz n care ea nu depinde de existena altei entiti. Entitatea poate fi persoan, loc, concept, activitate etc. Prin urmare, ea poate fi un obiect cu existen fizic, real sau poate fi un obiect cu existen conceptual, abstract. Pentru o analiz didactic a problematicii abordate, construirea diagramelor E/R, se vor considera i aspecte ale modelului real analizat, care nu apar n diagrama final. Pentru modelul de date referitor la prezentrile de mod, structurile PUBLICITATE, ORGANIZATOR, PERS_CONTACT, PREZENTARE, SPONSOR, FIRMA_PUB, CASA_MODA, CREATOR, VESTIMENTATIE, MODEL, ACCESORIU, LOCALIZARE, AGENTIE, ISTORIC, FIRMA_SEC, ANGAJAT_SEC,SOCIETATE_ASIG, ANGAJAT_TEMP, INFO_CONTACT, LOCATIE reprezint entiti. Observaii Entitile devin tabele n modelele relaionale. n general, entitile se scriu cu litere mari.

Modelarea entitate-relaie

61

Entitile sunt substantive, dar nu orice substantiv este o entitate. Trebuie ignorate substantivele nerelevante. Cheia primar identific unic o entitate i face distincie ntre valori diferite ale entitii. Aceasta trebuie s fie unic i cunoscut la orice moment. Cheia primar trebuie s fie controlat de administratorul bazei, s nu conin informaii descriptive, s fie simpl, fr ambiguiti, s fie stabil, s fie familiar utilizatorului astfel nct acesta s o poat folosi cu uurin. Pentru fiecare entitate este obligatoriu s se dea o descriere detaliat. Nu pot exista, n aceeai diagram, dou entiti cu acelai nume, sau o aceeai entitate cu nume diferite. Vom prezenta entitile modelului de date, dnd o descriere complet a fiecreia. De asemenea, pentru fiecare entitate se va preciza cheia primar. Toate entitile care vor fi prezentate sunt independente, cu excepia entitilor dependente ACCESORIU, ISTORIC i a subentitii MODEL. ORGANIZATOR = firm (persoan juridic) specializat, care se ocup cu organizarea i buna desfurare a unei prezentri de mod. Ea poate apela la societi specializate pentru rezolvarea problemelor ce apar n organizarea prezentrii de mod sau poate oferi servicii proprii pentru desfurarea optim a evenimentului. Cheia primar a entitii este cod_organizator. PERS_CONTACT = persoan fizic, aparinnd firmei organizatoare, care este responsabil cu un anumit domeniu de activitate specific organizrii prezentrii de mod. Ea poate fi contactat pentru diversele probleme care privesc prezentarea, fiind punctul de legtur dintre direciile din firma organizatoare i cele din societile externe, care se ocup efectiv cu realizarea tuturor problemelor ce apar n organizarea evenimentului. Atributul cod_pers_contact reprezint cheia primar a entitii. SPONSOR = persoan fizic sau juridic ce contribuie financiar sau n alt manier la desfurarea prezentrii de mod. Cheia primar a acestei entiti este cod_sponsor. FIRMA_PUB = persoan juridic ce asigur publicitatea evenimentului. Firma organizatoare poate apela la mai multe firme de publicitate. Cheia primar a acestei entiti este cod_firma_pub. PUBLICITATE = activitatea efectiv de publicitate asigurat de o firm de publicitate. Firmele de publicitate asigur diferite modaliti de realizare a publicitii (pres, televiziune, radio etc.). Cheia primar a acestei entiti este cod_publicitate. FIRMA_SEC = persoan juridic ce asigur securitatea prezentrii de mod. Se consider c o singur firm asigur securitatea evenimentului. Cheia primar a acestei entiti este cod_firma_sec.

62

PROIECTAREA BAZELOR DE DATE

ANGAJAT_SEC = persoan fizic, angajat a unei firme de securitate, care particip efectiv la asigurarea serviciilor de paz i protecie a prezentrilor de mod. Cheia primar a acestei entiti este cod_angajat. SOC_ASIG = persoan juridic responsabil de asigurarea (din punctul de vedere al societii organizatoare) tuturor activitilor pe care le implic prezentarea de mod. Se consider c firma organizatoare apeleaz la o singur societate de asigurri. Modelul de date nu ia n considerare asigurrile fcute de ageniile de modele pentru angajatele sale, asigurrile ncheiate chiar de ctre modele sau asigurrile contractate de casele de mod. Cheia primar a acestei entiti este cod_soc_asig. PREZENTARE = evenimentul efectiv al prezentrii de mod. Modelul de date consider doar prezentri de mod semnificative din lumea caselor de mod. Cheia primar a acestei entiti este cod_prezentare. CASA_MODA = persoan juridic a crei activitate const n crearea de vestimentaii i accesorii pentru aceste vestimentaii. Cheia primar a entitii este cod_casa_moda. CREATOR = persoan fizic, angajat (permanent sau special) a unei case de mod, care creeaz efectiv vestimentaiile sau accesoriile acestora prezentate n cadrul evenimentului respectiv. Cheia primar a entitii este cod_creator. VESTIMENTATIE = vestimentaia conceput i realizat de creatorii unei case de mod. Cheia primar a entitii este cod_vestimentatie. ACCESORIU = entitate dependent de VESTIMENTATIE, care conine informaii referitoare la accesoriile unei anumite vestimentaii. Cheia primar a entitii este compus din cod_accesoriu i cod_ vestimentatie. ANGAJAT_TEMP = persoan fizic, angajat temporar pentru o anumit prezentare de ctre o cas de mod, fie pentru realizarea machiajului i a coafurii modelelor care vor prezenta vestimentaii n cadrul prezentrii (stilist), fie pentru a purta creaiile acesteia la prezentarea respectiv (model). Cheia primar a entitii este cod_angajat_temp. MODEL = subentitate a entitii ANGAJAT_TEMP, ce conine informaii specifice manechinelor. Cheia primar a entitii este cod_angajat_temp. AGENTIE = agenia de modele care se ocup cu gestionarea activitilor (participare la prezentri de mod, contracte pentru reclama diverselor produse etc.) modelelor sale. Cheia primar a entitii este cod_agentie. ISTORIC = entitate dependent de MODEL, care conine istoricul angajrilor unui model la diferite agenii. Cheia primar a entitii este compus din cod_model i data_angajare. LOCALIZARE = identific localizarea unei persoane fizice (sponsor, persoan de contact, model, creator, stilist), juridice (firm de publicitate, securitate, asigurri, organizator, cas de mod, agenie de modele) sau eveniment (prezentare de mod). Cheia primar a entitii este cod_localizare.

Modelarea entitate-relaie

63

LOCATIE = entitate care identific locaia n care se desfoar o anumit prezentare de mod. Cheia primar a entitii este cod_locatie. INFO_CONTACT = identific modalitatea de contact a unei persoane fizice (sponsor, persoan de contact, angajat temporar, creator) sau juridice (firm de publicitate, securitate, asigurri, organizator, cas de mod, agenie de modele). Cheia primar a entitii este cod_info_contact. Relaie Relaia (asocierea) este o comunicare ntre dou sau mai multe entiti. O valoare a unei relaii este o comunicare ntre valorile entitilor pe care le leag. Relaia exprim un raport care exist ntre aceste entiti. Gradul unei relaii este dat de numrul de entiti participante ntr-o relaie (de exemplu, relaie binar, ternar, cvadrupl, n-ar). Existena unei relaii este subordonat existenei entitilor pe care le leag. ntre dou entiti pot exista mai multe relaii. O relaie n care aceeai entitate particip mai mult dect o dat n diferite roluri definete o relaie recursiv. Uneori, aceste relaii sunt numite unare. Observaii n modelul relaional, relaiile devin tabele speciale sau coloane speciale care refer chei primare. Relaiile sunt verbe, dar nu orice verb este o relaie. Pentru fiecare relaie este important s se dea o descriere detaliat. n aceeai diagram pot exista relaii diferite cu acelai nume. n acest caz, ele sunt difereniate de ctre entitile care sunt asociate prin relaia respectiv. Pentru fiecare relaie trebuie stabilit cardinalitatea (maxim i minim) relaiei, adic numrul de tupluri ce aparin relaiei. Asupra entitilor participante ntr-o relaie pot fi impuse constrngeri care trebuie s reflecte restriciile care exist n lumea real asupra relaiilor. O clas de constrngeri, numite constrngeri de cardinalitate, este definit de numrul de nregistrri posibile pentru fiecare entitate participant (raport de cardinalitate). Cel mai ntlnit tip de relaii este cel binar, iar n acest caz rapoartele de cardinalitate sunt, n general, one-to-one (1:1), one-to-many (1:n) sau many-to-many (m:n). De exemplu, n modelul analizat este definit relaia organizeaza care leag entitile ORGANIZATOR i PREZENTARE, relaie care poate fi scris sub forma ORGANIZATOR_organizeaza_PREZENTARE, pentru a percepe mai uor asocierile existente. Relaia are cardinalitatea minim 1:1 i cardinalitatea maxim 1:n. Vom prezenta relaiile modelului de date, dnd o descriere complet a fiecreia. De fapt, denumirile acestor legturi sunt sugestive, reflectnd

64

PROIECTAREA BAZELOR DE DATE

coninutul acestora i entitile pe care le leag. Pentru fiecare relaie se va preciza cardinalitatea minim i maxim. FIRMA_PUB_face_PUBLICITATE = relaie care leag entitile FIRMA_PUB i PUBLICITATE, reflectnd legtura dintre acestea (ce publicitate face o anumit firm de publicitate). Ea are cardinalitatea minim 1:1 (o firm de publicitate trebuie s realizeze cel puin o publicitate i o publicitate trebuie fcut de cel puin o firm de publicitate) i cardinalitatea maxim 1:n (o firm de publicitate poate asigura mai multe publiciti, iar o publicitate poate fi fcut de o singur firm specializat). PUBLICITATE_se_face_PREZENTARE = relaie care leag entitile PUBLICITATE i PREZENTARE, reflectnd legtura dintre acestea (pentru o prezentare, ce publicitate se face). Relaia are cardinalitatea minim 1:1 i cardinalitatea maxim 1:n. ORGANIZATOR_are_PERS_CONTACT = relaie dintre ORGANIZATOR i PERS_CONTACT, reflectnd legtura dintre acestea (ce persoane din firma organizatoare pot fi contactate pentru soluionarea diverselor probleme). Ea are cardinalitatea minim 1:1 i cardinalitatea maxim 1:n. FIRMA_SEC_are_ANGAJAT_SEC = relaie dintre entitile FIRMA_SEC i ANGAJAT_SEC, reflectnd legtura dintre acestea (ce angajai, implicai n aciunea de paz a prezentrilor de mod, au firmele de securitate). Ea are cardinalitatea minim 1:1 i cardinalitatea maxim 1:n. ANGAJAT_SEC_paza_PREZENTARE = relaie de tip many-to-many dintre entitatea PREZENTARE i ANGAJAT_SEC, reflectnd legtura dintre acestea (ce angajai ai firmei de securitate asigur buna desfurare a prezentrilor de mod). Ea are cardinalitatea minim 1:1 i cardinalitatea maxim m:n. SOC_ASIG_asigura_PREZENTARE = relaie dintre entitatea PREZENTARE i SOC_ASIG, reflectnd legtura dintre acestea (ce societate este angajat pentru asigurarea diverselor aspecte din cadrul prezentrii de mod). Ea are cardinalitatea minim 1:1 i cardinalitatea maxim 1:n. CASA_MODA_participa_PREZENTARE = relaie de tip many-to-many dintre entitile CASA_MODA i PREZENTARE (ce case de mod particip la prezentri). Ea arat i dac respectivele case particip, sau nu, ca organizator la prezentari. Relaia are cardinalitatea minim 1:1 i cardinalitatea maxim m:n. CASA_MODA_lucreaza_CREATOR = relaie dintre entitile CASA_MODA i CREATOR (la ce case de mod lucreaz creatorii). Relaia are cardinalitatea minim 1:1 i cardinalitatea maxim 1:n. CREATOR_creeaza_VESTIMENTATIE = relaie dintre entitile CREATOR i VESTIMENTATIE (ce creatori realizeaz vestimentaiile). Relaia are cardinalitatea minim 1:0 i cardinalitatea maxim1:n.

Modelarea entitate-relaie

65

VESTIMENTATIE_are_ACCESORIU = relaie dintre entitile ACCESORIU i VESTIMENTATIE (ce accesorii au vestimentaiile). Relaia are cardinalitatea minim 1:0 i cardinalitatea maxim 1:n. MODEL_prezint_VESTIMENTATIE = relaie ce leag entitile MODEL i VESTIMENTATIE (ce vestimentaii au fost purtate de modele). Relaia are cardinalitatea minim 1:1 i cardinalitatea maxim 1:n. CREATOR_face_ACCESORIU = relaie ce leag entitile CREATOR i ACCESORIU (ce creatori au realizat accesoriile). Relaia are cardinalitatea minim 1:0 i cardinalitatea maxim 1:n. PREZENTARE_prezinta_VESTIMENTATIE = relaie care leag entitile PREZENTARE i VESTIMENTATIE (ce vestimentaii au fost prezentate la evenimentele de mod). Relaia are cardinalitatea minim 1:1 i cardinalitatea maxim 1:n. PREZENTARE_are_LOCATIE = relaie ce leag entitile PREZENTARE i LOCATIE (ce prezentri de mod se desfoar ntr-o locaie). Deoarece ntr-o locaie pot s fie mai multe prezentri, relaia are cardinalitatea minim 1:1 i cardinalitatea maxim n:1. MODEL_lucreaza_AGENTIE = relaie dintre entitile MODEL i AGENTIE (la ce agenie este angajat un model). Relaia are cardinalitatea minim 1:1 i cardinalitatea maxim n:1. MODEL_are_ISTORIC = relaie dintre entitile MODEL i ISTORIC (istoricul activitii unui model, prin diferite agentii). Relaia are cardinaliatea minim 1:0 i cardinalitatea maxim 1:n. ISTORIC_refera_AGENTIE = relaie ce leag entitile ISTORIC i AGENTIE (la ce agenie se refer fiecare nregistrare din istoricul unui model). Relaia are cardinalitatea minim 1:1 i cardinalitatea maxim 1:n. SPONSOR_finanteaza_PREZENTARE = relaie de tip many-to-many dintre entitile SPONSOR i PREZENTARE, reflectnd legtura dintre acestea (ce sponsori finaneaz prezentrile de mod). Relaia are cardinalitatea minim 0:1 i cardinalitatea maxim m:n. PERS_CONTACT_are_LOCALIZARE = relaie ce leag entitile LOCALIZARE i PERS_CONTACT (localizarea unei persoane de contact). innd cont de restriciile impuse modelului, relaia are cardinalitatea minim 1:1 i cea maxim 1:1. O astfel de relaie este definit i pentru entitile FIRMA_PUB, FIRMA_SEC, PREZENTARE, ORGANIZATOR, CASA_MODA, SPONSOR, ANGAJAT_TEMP, SOC_ASIG, CREATOR, LOCATIE i AGENTIE, care sunt legate de entitatea LOCALIZARE, permind astfel localizarea tuturor structurilor modelului. PERS_CONTACT_are_INFO_CONTACT = relaie care leag INFO_CONTACT i PERS_CONTACT (modalitatea de accesare a unei persoane de contact). innd cont de restriciile impuse modelului, relaia are cardinalitatea minim 1:1 i cea maxim 1:1. O astfel de relaie este definit i

66

pentru entitile FIRMA_PUB, FIRMA_SEC, ORGANIZATOR, CASA_MODA, SPONSOR, ANGAJAT_TEMP, SOC_ASIG, CREATOR, LOCATIE i AGENTIE, care sunt legate de entitatea INFO_CONTACT, permind astfel accesarea tuturor structurilor modelului. ANGAJAT_TEMP_primeste_la_PREZENTARE_de_la_CASA_MODA = relaie de tip 3 ce leag entitile ANGAJAT_TEMP, PREZENTARE i CASA_MODA, reflectnd cine a fost angajat temporar, de ce cas de mod, pentru ce prezentare. Denumirea acestei relaii va fi primeste. Atribut Atributul este o proprietate descriptiv a unei entiti sau a unei relaii. De exemplu, numele unei case de mod este un atribut al entitii CASA_MODA, iar data la care o cas de mod particip la o prezentare este un atribut al relaiei particip ce leag entitile PREZENTARE i CASA_MODA. Atributele pot fi simple (de exemplu, suma cu care este pltit un model de ctre o cas de mod pentru o prezentare), compuse (de exemplu, adresa unei firme de publicitate), cu valori multiple (de exemplu, numerele de telefon ale unei persoane de contact), derivate (de exemplu, vrsta unei persoane se obine din data naterii). Observaii Trebuie fcut distincia ntre atribut care uzual devine coloan n modelele relaionale i valoarea acestuia, care devine valoare n coloane. Atributele sunt substantive, dar nu orice substantiv este atribut. Fiecrui atribut trebuie s i se dea o descriere complet n specificaiile modelului (exemple, contraexemple, caracteristici). Pentru fiecare atribut trebuie specificat numele, tipul fizic (integer, float, char etc.), valori posibile, valori implicite, reguli de validare, constrngeri, tipuri compuse. n continuare vor fi prezentate, parial, atributele entitilor i relaiilor dnd o descriere a fiecruia, a caracteristicilor i a constrngerilor pe care trebuie s le ndeplineasc. Semnificaia unor atribute a cror denumire nu este semnificativ sau care include mai multe caracteristici dect denumirea va fi comentat pe parcursul lucrrii. Entitatea independent ANGAJAT_TEMP are ca atribute: cod_angajat_temp = variabil de tip ntreg, de lungime maxim 5, care reprezint codul unui angajat temporar. nume = variabil de tip caracter, de lungime maxim 25, care reprezint numele angajatului. prenume = variabil de tip caracter, de lungime maxim 25, care reprezint prenumele angajatului. data_nastere = variabil de tip dat calendaristic, care reprezint data naterii angajatului respectiv. sex = variabil de tip caracter, lund valorile m sau f, de lungime 1, care reprezint sexul angajatului.

PROIECTAREA BAZELOR DE DATE

Modelarea entitate-relaie

67

nationalitate = variabil de tip caracter, de lungime maxim 12, care reprezint naionalitatea unui angajat temporar. cod_localizare = variabil de tip ntreg, de lungime maxim 5, care reprezint codul localizrii angajatului. Atributul trebuie s corespund la o valoare a cheii primare din tabelul LOCALIZARE. cod_info_acces = variabil de tip caracter, de lungime maxim 5, care reprezint codul informaiei de acces pentru angajatul respectiv. Atributul trebuie s corespund la o valoare a cheii primare din tabelul INFO_CONTACT. tip = variabil de tip caracter, de lungime 10, care reprezint funcia pentru care a fost angajat persoana respectiv. De exemplu, poate s fie model, stilist sau eventual poate lua alte valori. Subentitatea MODEL are ca atribute: cod_angajat_temp = variabil de tip ntreg, de lungime maxim 5, care reprezint codul modelului. cod_agentie = variabil de tip ntreg, de lungime maxim 5, care reprezint codul ageniei la care este angajat n prezent modelul. Atributul trebuie s corespund la o valoare a cheii primare din tabelul AGENTIE. inaltime = variabil de tip numeric, de lungime 3, care reprezint nlimea modelului n centimetri. nr_pantof = variabil de tip numeric (real), care reprezint numrul pe care l poart la pantof modelul respectiv. info = variabil de tip text, care include informaii speciale despre model (dimensiuni, greutate, preferine, elemente confideniale, palmares etc.). Entitatea PUBLICITATE are atributele: cod_publicitate, cod_firma_pub, cod_prezentare, tip, nume, suma, observatii. Atributul tip poate lua valorile radio, televiziune, presa, panouri publicitare etc. Atributul nume este legat de atributul tip n sensul c poate reprezenta numele postului de radio, al celui de televiziune, al publicaiei care face publicitatea. Entitatea FIRMA_PUB are atributele: cod_firma_pub, nume, info, director, observatii, nume_pers_contact, cod_localizare, cod_info_acces. Entitatea ORGANIZATOR are atributele: cod_organizator, denumire, banca, cont, informatii, cod_localizare, cod_info_acces. Entitatea PERS_CONTACT are atributele: cod_pers_contact, cod_organizator, nume, prenume, directie, cod_localizare, cod_info_acces. Entitatea PREZENTARE are atributele: cod_prezentare, denumire, data_start, data_final, cod_organizator, cod_soc_asig, cod_locatie. Entitatea SPONSOR are atributele: cod_sponsor, tip, nume, info, cod_localizare, cod_info_acces. Atributul tip poate lua valorile persoana fizic sau persoana juridic. n primul caz, atributul nume va reprezenta numele i prenumele persoanei fizice, iar n cel de al doilea caz, va reprezenta numele societii.

68

PROIECTAREA BAZELOR DE DATE

Entitatea CASA_MODA are atributele: cod_casa_moda, nume, cifra_afaceri, proprietar, director, istoric, data_creare, cod_localizare, cod_info_acces. Entitatea CREATOR are atributele: cod_creator, nume, prenume, data_nastere, data_angajare, cod_casa_moda, tip, mod_angajare, info, cod_localizare, cod_info_acces. Atributul tip poate lua valorile designer, croitor, broder, creator_accesorii. Atributul mod_angajare poate lua valorile permanent sau special. Entitatea VESTIMENTATIE are atributele: cod_vestimentatie, denumire, valoare, descriere, cod_creator, cod_model, cod_prezentare. Entitatea ACCESORIU are atributele: cod_vestimentatie, cod_accesoriu, tip, descriere, valoare, cod creator. Entitatea AGENTIE are atributele: cod_agentie, nume, data_creare, director, cifra_afaceri, info, cod_localizare, cod_info_acces. Entitatea ISTORIC are atributele: cod_model, data_angajare, data_final, cod_agentie, conditii. Entitatea LOCALIZARE are atributele: cod_localizare, adresa, cod_postal, oras, tara. Entitatea LOCATIE are atributele: cod_locatie, denumire, tip, capacitate, cod_localizare, cod_info_acces. Atributul tip reprezint tipul locaiei respective i poate lua valorile: hotel, esplanad, teatru, mall etc. Entitatea INFO_CONTACT are atributele: cod_info_contact, telefon_mobil, mail, telefon_fix, fax. Entitatea FIRMA_SEC are atributele: cod_firma_sec, nume_firma, tip_servicii, director, observatii, cod_localizare, cod_info_acces. Entitatea ANGAJAT_SEC are atributele cod_angajat, nume, prenume, data_nastere, specializare, nivel, observatii, cod_localizare, cod_firma_sec, cod_info_acces. Entitatea SOC_ASIG are atributele: cod_soc_asig, conditii, suma, director, observatii, nume_pers_contact_firma, cod_localizare, cod_info_acces. Relaia CASA_MODA_participa_PREZENTARE are ca atribute: cod_prezentare = variabil de tip ntreg, de lungime maxim 5, care reprezint codul prezentrii. Atributul trebuie s corespund la o valoare a cheii primare din tabelul PREZENTARE. cod_casa_moda = variabil de tip ntreg, de lungime maxim 5, care reprezint codul casei de mod. Atributul trebuie s corespund la o valoare a cheii primare din tabelul CASA_MODA. tip = variabil de tip caracter, de lungime maxim 15, care reprezint modalitatea n care o cas de mod particip la o prezentare, n sensul c poate fi organizator sau neorganizator.

Modelarea entitate-relaie

69

data = variabil de tip dat calendaristic reprezentnd ziua n care defileaz modelele casei de mod. Atributul nu este multiplu, deoarece s-a presupus c defilarea unei case de mod are loc ntr-o singur zi. Relaia SPONSOR_finanteaza_PREZENTARE are ca atribute: cod_sponsor, cod_prezentare, data_emitere, suma, banca, cont_emitent, cod_ordin_plata. Relaia ANGAJAT_SEC_paza_PREZENTARE are atributele: cod_angajat, cod_prezentare, tip_paza, dotare, observaii. Relaia ANGAJAT_TEMP_primeste_la_PREZENTARE_de_la_CASA_MODA are ca atribute: cod_angajat_temp, cod_casa_moda, cod_prezentare suma, data_achitare, cont, banca. Nu s-au introdus atributele cont i banca la entitatea ANGAJAT_TEMP, deoarece modelul de date nu-i propune s furnizeze informaii complete referitoare la toate conturile i bncile modelelor, stilitilor etc. Se consider doar banca i contul n care casa de mod depune bani pentru prezentarea la care acetia au fost angajai. 2.3. Diagrama entitate- relaie Pentru proiectarea diagramei entitate-relaie au fost stabilite anumite reguli (care nu sunt unice): entitile sunt reprezentate prin dreptunghiuri; relaiile dintre entiti sunt reprezentate prin arce neorientate; atributele care reprezint chei primare trebuie subliniate sau marcate prin simbolul #, plasat la sfritul numelui acestor atribute; cardinalitatea minim este indicat n paranteze, iar cardinalitatea maxim se scrie fr paranteze; nu este necesar s fie specificate, n cadrul diagramei, toate atributele. Vom comenta cteva cazuri speciale de entiti, relaii, atribute i modul lor de reprezentare n cadrul diagramei entitate-relaie. Dependena. Exist entiti, numite entiti dependente care nu pot exista n mod independent. De exemplu, se observ c entitatea ACCESORIU depinde de VESTIMENTATIE, iar LOCATIE depinde de entitatea PREZENTARE. Cheia primar a unei entiti dependente include cheia primar a sursei (cod_vestimentatie) i cel puin o descriere a entitii (cod_accesoriu). Entitatea dependent se deseneaz prin dreptunghiuri cu linii mai subiri. Motenirea atributelor. O subentitate (subclas) este o submulime a unei alte entiti, numit superentitate (superclas). De exemplu, ANGAJAT_TEMP este o superentitate pentru MODEL, iar MODEL este o subentitate pentru ANGAJAT_TEMP. Subentitatea se deseneaz prin dreptunghiuri incluse n superentitate. Exist o relaie

70

PROIECTAREA BAZELOR DE DATE

ntre o subentitate i o superentitate, numit ISA, care are cardinalitatea maxim 1:1 i minim 1:0. Cheile primare, atributele i relaiile unei superentiti sunt valabile pentru orice subentitate. Afirmaia reciproc este fals. De exemplu, un informatician, considerat ca subentitate a entitii PERS_CONTACT, poate avea ca atribute limbajele de programare cunoscute i nivelul de cunoatere a acestora, dar aceste atribute nu sunt semnificative pentru o persoan de contact care coordoneaz asigurarea securitii prezentrii de mod. Cheia primar a subentitii INFORMATICIAN este cod_pers_contact, care este cheia primar a superentitii PERS_CONTACT. Specializare. Dup valorile unor atribute clasificatoare se pot determina clase. Un grup de subentiti reciproc exclusive definete o clas. Clasele se aliniaz n desen vertical. De exemplu, pentru entitatea PUBLICITATE, dup valorile atributului tip, pot fi definite subentitile PANOURI_PUBLICITARE, PRESA, TELEVIZIUNE, RADIO, fiecare avnd atributele sale proprii. Generalizare. Din entiti similare care au mai multe atribute comune se pot crea superentiti. Aceste superentiti conin atributele comune, iar atributele speciale sunt asignate la subentiti. Pentru noile superentiti se introduc chei primare artificiale. De exemplu, din entitile FIRMA_PUB, FIRMA_SEC i SOC_ASIG se poate crea superentitatea FIRMA avnd drept atribute: cod_firma (cheie primar artificial), informaii de accesare, informaii de localizare, director, observatii. ntr-o diagram E/R se pot defini relaii recursive. De exemplu, poate fi definit relaia PERS_CONTACT_supervizeaza_PERS_CONTACT. Unele relaii sunt relative la dou entiti i le numim de tip 2, iar dac relaiile implic mai mult de dou entiti, le vom numi de tip 3. Trei relaii de tip 2 sunt diferite de o relaie de tip 3. Rupnd o relaie de tip 3 n trei relaii de tip 2, poate s apar informaie incorect. Trebuie excluse din model relaiile indirecte pentru c ele pot conduce la redundan n baza de date. Atributele derivabile trebuie eliminate i introduse expresii prin care aceste atribute pot fi calculate. Uneori apare o incertitudine referitoare la faptul c o anumit informaie poate fi considerat o relaie sau un atribut. O relaie poate fi reprezentat ca un atribut, sau putem folosi relaii n loc de atribute. Dac un atribut al unei entiti reprezint cheia primar a unei alte entiti, atunci el refer o relaie. Uneori este greu de stabilit dac informaia analizat reprezint o entitate sau o relaie. Dac exist o incertitudine, se cerceteaz cheia primar. Dac aceast cheie combin cheile primare a dou entiti, atunci se definete o relaie. Cheia primar a relaiei organizeaza

Modelarea entitate-relaie

71

combin atributele cod_organizator i cod_prezentare, care reprezint cheile primare ale entitilor ORGANIZATOR i PREZENTARE. Prin urmare, ORGANIZATOR_organizeaza_PREZENTARE va defini o relaie i nu o entitate. Un atribut indirect este inoportun. El nu descrie real relaia sau entitatea. Prin urmare, atributele indirecte trebuie reasignate. De fapt, un atribut indirect este un caz special de relaie indirect care trebuie eliminat pentru c introduce redundan n date. Exist atribute opionale, a cror valoare este uneori necunoscut, alteori neaplicabil. Aceste atribute trebuie introduse la subentiti. Algoritmul pentru proiectarea diagramei E/R cuprinde urmtoarele etape: 1. identificarea entitilor din cadrul sistemului analizat; 2. identificarea relaiilor (asocierilor) dintre entiti i stabilirea cardinalitii; 3. identificarea atributelor aferente entitilor i asocierilor dintre entiti; 4. stabilirea atributelor de identificare a entitilor, adic stabilirea cheilor. Relaiile reflect legturi naturale care exist ntre componentele sistemului. Aceeai realitate poate fi ns perceput diferit de ctre diveri analiti pentru un acelai sistem, putnd fi obinute modele structurale distincte. O diagram E/R pentru modelul comentat n aceast seciune este reprezentat n figura 2.1. Diagrama este corect, dar este optimizabil. Construirea diagramei conceptuale, obinerea schemelor relaionale i normalizarea acestora vor genera un model relaional care va elimina anumite clase de anomalii ce pot s apar n proiectarea modelului de date. Deficiene ale modelului E/R n proiectarea unui model de date pot aprea diverse probleme datorit unei interpretri eronate a sensului unei relaii. Aceste probleme sunt denumite capcane de conectare. Unele dintre aceste capcane pot s nu fie semnificative pentru modelul particular considerat, n timp ce altele cer restructurarea modelului. Exist dou clase importante de capcane: de ntrerupere i n evantai. O capcan de ntrerupere poate s apar acolo unde modelul sugereaz existena unei relaii ntre entiti, dar nu exist o cale ntre anumite apariii ale entitilor. Aceast capcan poate s apar acolo unde exist o relaie cu participare parial (0 la cardinalitatea minim), care face parte din calea dintre entitile ce sunt legate. O capcan n evantai poate s apar acolo unde modelul ia n considerare o relaie ntre entiti, dar calea dintre anumite apariii ale entitilor este ambigu. Aceste capcane apar cnd dou sau mai multe relaii one_to_many provin din aceeai entitate.

72

PROIECTAREA BAZELOR DE DATE

FIRMA_PUB 1 face M(1) M(1) PUBLICITATE

INFO_CONTACT 1 are 1 are M(1) PERS_CONTACT ORGANIZATOR 1 1 M(1) are 1 organizeaza LOCALIZARE se_face

LOCATIE 1 are are M(1) M(1) M(1) M(1) paza M(1) 1 M(1) finanteaza M(0) ANGAJAT SEC PREZENTARE SPONSOR M(1) 1 M(1) SOC ASIG 1 asigura participa

FIRMA SEC 1

M(1) CASA_MODA prezinta 1 lucreaza M(1) 1 CREATOR 1

primeste

ANGAJAT_TEMP MODEL 1(0) ISA M(1) 1 1 lucreaza_la M(1) are 1 AGENTIE 1 refera 1

creeaza prezinta face M(1) M(0) VESTIMENTATIE 1 are M(0) M(0) ACCESORIU

M(0) ISTORIC M(1)

Fig. 2.1. Diagrama E/R. Practic, aceste capcane genereaz situaiile n care, aa cum a fost proiectat modelul de date, el nu poate s rspund la anumite interogri. De exemplu, pentru a afla pentru ce prezentare de mod a fost creat o anumit vestimentaie, a fost necesar introducerea unei legturi ntre entitile PREZENTARE i VESTIMENTATIE, care ns a generat redundan n modelul de date. Modelul E/R extins Conceptele de baz ale modelrii entitate-relaie nu sunt suficiente pentru a reprezenta cerinele aplicaiilor actuale, care sunt mult mai complexe. Au fost propuse, n acest sens, mai multe modele de date semantice. Modelul E/R susinut cu concepte semantice adiionale definete modelul E/R extins (EER).

Modelarea entitate-relaie

73

Acesta include toate conceptele modelului original, mpreun cu conceptele adiionale de specializare, generalizare i categorie. Aceste noi concepte au fost deja nominalizate n acest capitol. Superclasa (superentitatea) este o entitate care include subclase (subentiti) distincte, ce trebuie reprezentate n modelul de date. Subclasa are un rol distinct i, evident, este membr a unei superclase. O subclas, fiind o entitate, poate s posede propriile subclase. O entitate mpreun cu subclasele ei, subclasele acestora i aa mai departe definete o ierarhie de tip (ierarhie de specializare). De exemplu, ANGAJAT_TEMP reprezint o superclas pentru entitatea MODEL. Specializarea este procesul de maximizare a diferenelor dintre membrii unei entiti, prin identificarea caracteristicilor distinctive ale acestora. Specializarea constituie o abordare de sus n jos n definirea unei mulimi de superclase i a subclaselor lor. Pot exista diverse specializri ale aceleiai entiti, bazate pe diferite caracteristici de difereniere. Dac subclasele unei specializri sunt disjuncte, atunci o entitate poate fi membr doar a unei subclase a acesteia (constrngere de disjuncie). O specializare cu participare total specific faptul c fiecare entitate din superclas trebuie s fie membr a unei subclase din specializare (constrngere de participare). De exemplu, specializarea contractelor de angajare poate fi cu participare total dac fiecare angajat din PERS_CONTACT este fie angajat cu contract permanent cu norm ntreag, fie cu contract temporar cu norm incomplet. O specializare cu participare parial specific faptul c nu este necesar ca o entitate s aparin vreunei subclase a acesteia. De exemplu, exist salariai n PERS_CONTACT care nu aparin niciunei subentiti ale acesteia. Generalizarea este procesul de minimizare a diferenelor dintre entiti, prin identificarea caracteristicilor comune ale acestora. Generalizarea reprezint o abordare de jos n sus, care are ca rezultat identificarea unei superclase generalizate din subclasele iniiale. Orice relaie superclas/subclas (inclusiv cele ale unei subclase partajate) dintr-o ierarhie de specializare/generalizare are o singur superclas. Totui, anumite situaii necesit modelarea unei relaii superclas/subclas cu mai mult dect o superclas distinct. n acest caz, subclasa definete o categorie. Categoria este procesul de modelare a unei singure subclase, cu o relaie care implic mai mult dect o singur superclas distinct.

2.4. Modelare orientat pe obiecte cu UML Un limbaj de modelare reprezint o modalitate de a comunica despre un sistem i de a exprima diversele modele produse n cadrul procesului de analiz i dezvoltare a sistemului. Limbajul furnizeaz o notaie care permite reprezentarea unui design.

74

PROIECTAREA BAZELOR DE DATE

Limbajul este format dintr-un set de concepte, principii i reguli de utilizare a acestora, cu scopul de a reprezenta modelele produse n diferite etape de dezvoltare a sistemului. Fr un limbaj de modelare, este dificil colaborarea i comunicarea dintre membrii echipei pe parcursul proiectrii sistemului. Ca orice limbaj, un limbaj de modelare are o sintax i o semantic, iar pentru semantica modelului trebuie aleas sintaxa cea mai expresiv. De cele mai multe ori, un limbaj de modelare este un limbaj grafic (diagramatic). Dac pentru utilizatori, limbajele de modelare uureaz munca de realizare a sistemelor software, pentru realizatorii acestora sarcinile sunt multiple i dificile. Pentru ca un limbaj de modelare s se impun, el trebuie s asigure o bun specificare a conceptelor sale i a modului de reprezentare a acestora. n acest scop, limbajele trebuie s asigure suport pentru modelatori, n vederea rafinrii treptate a soluiei i a captrii semanticii procesului. The Unified Modeling Language (UML) este, aa cum semnific i numele, un limbaj vizual de modelare i de comunicare despre sistem. UML nu este un limbaj de programare, deoarece nu dispune de ntreg sprijinul semantic i vizual pentru a defini un astfel de limbaj. nlocui limbajele de programare. UML este un limbaj pentru modelarea orientat pe obiecte, cu suport pentru modelare vizual, funcionnd ca o modalitate de a comunica i de a exprima cunotine. UML este un limbaj grafic de modelare pentru specificarea, vizualizarea, construcia i documentarea componentelor unui sistem software (pentru ntreprinderi, telecomunicaii, sisteme bancare i financiare, transporturi etc.) sau pentru modelarea organizaional a unor sisteme non-software (din justiie, medicin, afaceri etc.). UML nu este un limbaj de programare, dar modelele exprimate n UML pot fi implementate uor n limbaje de programare orientate pe obiecte (C++, Java, C#) sau n baze de date relaionale. Este posibil nu numai generarea codului dintr-un model UML, dar i ingineria invers, constnd n construirea dintr-un cod dat a unui model UML. UML este un limbaj de modelare pentru documentare, deoarece permite realizarea tuturor documentelor necesare nelegerii modelului i diagramelor utilizate pe tot parcursul ciclului de via al unui proces de realizare a unui sistem. Documentele componentelor sistemului conin specificarea cerinelor, arhitecturii i proiectrii sistemului; elaborarea codului surs, planuri de dezvoltare i de management al proiectului. n concluzie, UML nu este un limbaj de programare vizual, dar este un model de limbaj de modelare vizual; nu este o metodologie, dar este o notaie pentru aceasta; nu este un proces, dar ofer suport complet pentru construcia i dezvoltarea acestuia. Este important de menionat c UML este un limbaj de modelare, i nu o metod. Majoritatea metodelor conin att un limbaj de modelare, ct i un proces. Limbajul de modelare furnizeaz, dup cum am mai subliniat, doar notaia pentru reprezentarea unui design. Procesul cuprinde, ns, paii care trebuie s fie urmai pentru a realiza un design.

Modelarea entitate-relaie

75

UML cuprinde tehnici specifice mai multor metode de dezvoltare (proiectare) i este suficient de logic, de expresiv pentru a putea fi utilizat mpreun cu orice metod sau proces de dezvoltare. Ca orice limbaj, UML are sintaxa i semantica sa. Cu ajutorul alfabetului i al cuvintelor limbajului, se pot scrie propoziii (fragmente din diagrame) despre subiectul de analizat. Propoziiile se pot grupa n paragrafe (diagrame UML). Paragrafele, la rndul lor, se pot grupa n seciuni (moduri de vizualizare) i, n final, seciunile se pot organiza n documente. Documentele UML sunt modelele sistemului. Sintaxa limbajului UML implic diagrame, n timp ce semantica lui se bazeaz pe paradigma orientrii pe obiecte. Din punct de vedere al modelrii orientate pe obiecte, entitile (conceptele) se numesc clase, iar relaiile dintre ele se numesc asocieri. Diagrama este o reprezentare grafic a unei mulimi de elemente, de obicei folosindu-se forme geometrice pentru a reprezenta entiti i linii pentru a reprezenta asocieri. n UML, diagrama este o proiecie a sistemului, reprezentnd o parte a sistemului sau chiar ntregul sistem dintr-un anumit punct de vedere. Acelai element poate aprea n toate diagramele, n cteva diagrame sau n nicio diagram. UML conine 9 tipuri de diagrame, fiecare reflectnd una sau mai multe dintre cele 5 tipuri de vizualizri posibile asupra unui sistem software. Diagrama claselor descrie structura unui sistem n general. n componena ei intr clase, stereotipuri i relaiile dintre acestea. Diagrama obiectelor descrie structura unui sistem la un anumit moment. Acest tip de diagram este o variant a diagramei claselor care, n locul unei clase, prezint mai multe instane ale ei, fiind format din obiecte i legturi dintre ele. Diagrama cazurilor de utilizare descrie funcionalitatea unui sistem, prezentnd actorii externi, cazurile de utilizare identificate numai din punct de vedere al actorilor (comportamentul sistemului, aa cum este perceput de utilizatorii lui), precum i relaiile dintre actori i cazurile de utilizare. Un actor poate fi orice sau oricine interacioneaz cu sistemul (trimite sau recepioneaz mesaje de la sistem sau schimb informaii cu acesta). Actorul are un rol n cadrul unui sistem, nu este un utilizator individual al acestuia i, din acest motiv, el este o entitate (o clas), nu o instan. Un caz de utilizare este iniiat mereu de un actor i furnizeaz o valoare actorului. Diagrama componentelor (diagrama de implementare) descrie structura fizic a codului n termenii componentelor de cod i relaiilor dintre acestea. Diagrama de desfurare (de exploatare) indic arhitectura fizic pe care este implementat sistemul, calculatoarele, nodurile sistemului i conexiunile dintre ele.

76

PROIECTAREA BAZELOR DE DATE

Diagrama secvenelor este o diagram de interaciune, care prezint colaborarea dinamic dintre un numr de obiecte, punnd accentul pe secvenele de mesaje trimise ntre acestea pe msura scurgerii timpului. Diagrama de colaborare este tot o diagram de interaciune, dar care, pe lng interaciunea dintre obiecte (schimbul de mesaje), prezint obiectele i legturile dintre ele. Diagrama de stare descrie ciclul de via al unui element (al obiectelor, subsistemelor i sistemelor), prin specificarea strilor n care se gsete elementul i a evenimentelor care i modific starea. Diagrama de activitate prezint activitile i responsabilitile elementelor sistemului, fiind utilizat pentru modelarea funciilor sistemului. Ea are ca elemente constitutive stri de aciune i mesaje care vor fi trimise sau recepionate ca parte a aciunii realizate. n UML, diagramele fac parte din dou categorii. Diagrame dinamice sau comportamentale descriu comportamentul i interaciunile dintre diverse entiti ale sistemului informatic. Din aceast categorie, fac parte diagramele de secven, colaborare, stare i activitate. Diagrame statice sau structurale - descriu structura, responsabilitile sistemului informatic, componentele executabile ale sistemului, locaiile fizice de execuie i nodurile de stocare a datelor. Din aceast categorie, fac parte diagramele claselor, obiectelor, cazurilor de utilizare, componentelor i diagramele de exploatare. Pe lng structura static i comportamentul dinamic, pentru caracterizarea complet a unui sistem este necesar i funcionalitatea acestuia, care poate fi analizat folosind diagramele cazurilor de utilizare. Din punct de vedere al modelrii sistemelor orientate pe obiecte din perspectiva UML, aspectele statice sunt: clasele i relaiile dintre clase, interfeele, topologia hardware necesar execuiei aplicaiei. Seciunile UML sau modurile de vizualizare sunt grupuri de diagrame care se adreseaz unei anumite mulimi de entiti. Toate diagramele UML pot fi organizate n vizualizri. Fiecare vizualizare este descris folosind un numr de diagrame ce conin informaii referitoare la un anumit aspect particular al sistemului. Exist 5 tipuri importante de vizualizri asupra unui sistem software. Modul de vizualizare structural (logic) al arhitecturii unui sistem se refer la cerinele funcionale ale acestuia, adic prezint serviciile furnizate de sistem utilizatorilor si. Vizualizarea logic trateaz din interior sistemul i descrie att structura intern a acestuia, format din clase, obiecte i relaii, ct i colaborrile, legturile care apar n urma schimbului de mesaje ntre obiecte, pentru a realiza funcionalitatea dorit. Notaia UML este dedicat, n mare parte, reprezentrii

Modelarea entitate-relaie

77

arhitecturii logice (clase, asocieri, obiecte, legturi, generalizri, polimorfism, pachete etc.) Modul de vizualizare a componentelor sistemului (implementare) se concentreaz pe descrierea componentelor care implementeaz sistemul, dependenele care exist ntre ele, resursele alocate acestora, precum i rezolvarea unor probleme legate de reutilizarea, portabilitatea codului i informaii administrative. Modul de vizualizare a cazurilor de utilizare surprinde funcionalitatea sistemului, aa cum este ea perceput de actorii externi care interacioneaz cu sistemul, precum i de utilizatorii acestuia, de diferii membri ai echipei realizatoare sau de ctre alte sisteme. n componena acestui mod intr diagramele cazurilor de utilizare pentru descrierea static a aspectului funcional i ocazional. Se pot folosi i diagrame de activitate pentru a ncapsula latura dinamic a funcionalitii. Modul de vizualizare comportamental este util pentru gestionarea eficient a resurselor, pentru execuii paralele i tratri asincrone ale unor evenimente din sistem, precum i pentru rezolvarea unor probleme legate de comunicare i sincronizare. Modul de vizualizare a desfurrii (mediu) se refer la desfurarea fizic a sistemului, indicnd ce calculatoare i ce tipuri de noduri vor fi folosite pentru implementarea sistemului, cum sunt acestea conectate, precum i ce procese se vor executa n fiecare nod.

UML ofer, pe lng elementele de baz, i unele faciliti care permit organizarea i extinderea diagramelor. Aceste faciliti pot fi simple notaii sau pot fi elemente de extindere a limbajului UML. Dintre facilitile cele mai importante se remarc pachetele, notele, stereotipurile i proprietile. Pachetul reprezint un mecanism de grupare a elementelor de modelare. n UML, un pachet definete un mecanism de organizare a elementelor n grupuri legate semantic. Nota cuprinde ipotezele i deciziile aplicate n timpul analizei i al proiectrii. Notele sunt corespondentul comentariilor din limbajele de programare. Stereotipul este un concept introdus n UML, care permite extinderea elementelor de baz pentru a crea noi elemente. Un stereotip reprezint un neles specific asociat unui element. Proprietatea este un element de extindere UML, care lrgete proprietile i semantica unui element UML. Modelarea unui sistem privete modelarea aspectelor sale funcionale, statice i dinamice. Pentru ca un sistem s aib succes, n primul rnd trebuie ca cerinele sistemului s fie exprimate ntr-o manier care s permit o uoar nelegere, indiferent de nivelul de pregtire informatic a celor implicai n

78

PROIECTAREA BAZELOR DE DATE

proiect, iar n al doilea rnd trebuie ca membrii echipei de dezvoltare s poat asimila cu uurin modificrile care apar pe parcurs n cerine. Aceste condiii sunt rezolvate n diagrama cazurilor de utilizare, care are rolul de a reprezenta n form grafic funcionalitile pe care trebuie s le ndeplineasc sistemul n faza sa final. Pentru crearea modelului cazurilor de utilizare, trebuie identificai actorii, cazurile de utilizare, relaiile dintre actori i relaiile dintre cazurile de utilizare. Realizarea acestor faze presupune discuii ntre utilizatori i analitii de sistem. Cazul de utilizare poate fi privit ca un instrument de stimulare a posibililor utilizatori n exprimarea propriilor puncte de vedere. Adeseori, utilizatorii tiu mai multe dect pot s explice i nu le este uor s se pronune clar cum vor folosi sistemul. Cazurile de utilizare ajut la ndeprtarea acestui impediment. Discuiile iniiale trebuie s duc la descoperirea actorilor i a cazurilor de utilizare care descriu cerinele funcionale n termeni generali i care pot stabili frontierele domeniului studiat. Urmtoarele discuii au ca scop nelegerea, n detaliu, a domeniului studiat, ceea ce duce la evitarea introducerii unor cazuri de utilizare, care ar ngreuna procesul de analiz. Un caz de utilizare este o descriere a unei funcionaliti pe care o ofer sistemul, o colecie de scenarii referitoare la utilizarea unui sistem. Un scenariu descrie o succesiune de evenimente introduse de un actor, care poate fi o persoan, un dispozitiv hardware sau chiar trecerea timpului. Deci, actorii sunt entitile care iniiaz o secven de evenimente (un scenariu). Rezultatul secvenei de evenimente trebuie s fie concretizat n ceva utilizabil de ctre actorul ce a iniiat secvena sau de ctre alt actor. Diagrama cazurilor de utilizare are ca elemente de modelare actorii, cazurile de utilizare, relaiile dintre cazurile de utilizare. Detaliile despre fiecare caz de utilizare pot fi date n documente text sau pot fi folosite tehnici noi, de modelare dinamic, de exemplu diagramele de activitate sau diagramele de interaciune, pentru a specifica secvenele de pai ale cazului de utilizare. Construirea unei diagrame a cazurilor de utilizare are drept obiective: s capteze i s descrie cerinele funcionale ale sistemului, cerine rezultate n urma discuiilor purtate de clieni i/sau utilizatori ai sistemului cu dezvoltatorii acestuia; s ofere o descriere clar i consistent a ceea ce va trebui s fac sistemul, adic folosirea modelului pentru comunicarea cerinelor tuturor persoanelor implicate n construirea sistemului, i s constituie un punct de plecare pentru alte activiti (design, testare i implementare); s constituie o baz pentru realizarea textelor de verificare, ce decid dac funcionalitatea final concord cu cerinele iniiale ale sistemului;

Modelarea entitate-relaie

79

s permit transformarea cerinelor funcionale n viitoare clase i operaii. Diagramele UML pot fi desenate i administrate utiliznd un utilitar CASE (Computer Edit Software Engineering). Aceste utilitare sunt deosebit de utile n cazul unor diagrame complexe. Totui, dac diagrama este prea complicat, atunci este necesar partiionarea ei n mai multe diagrame sau reprezentarea la un nivel superior de abstractizare. Exemple de utilitare CASE care permit realizarea diagramelor UML sunt reprezentate de: Microsoft Office Visio, IBM Rational Rose Professional Data Modeler, Altova UModel, Borland Together, Visual Paradigm for UML, ArgoUML etc. Interesul pentru suportul modelrii bazelor de date cu ajutorul UML a condus la crearea unor profile specifice. Un profil constituie o propunere a unei comuniti i regrupeaz o mulime de elemente UML care se aplic unui context particular i care conserv metamodelul UML. IBM Rational Rose include un astfel de profil adaptat bazelor de date. Exist o diferen ntre un model (de exemplu, modelul conceptual de date) i un formalism (n care este descris un model). Astfel, putem vorbi despre modelarea conceptual a datelor urmnd formalismul entitate-relaie sau formalismul UML. Notaia exprim doar aspectul referitor la reprezentare. Pe lng formalismul entitate-relaie, considerat standardul de facto pentru modelarea datelor, o opiune alternativ este oferit de ctre UML. Acesta include primitive pentru modelarea datelor, iniial concepute pentru reprezentarea structurii claselor unei aplicaii orientate obiect, dar care pot fi folosite pentru specificarea modelului de date al domeniului unei aplicaii. n particular, diagramele de clase UML pot fi utilizate ca alternativ la diagramele entitate-relaie. Diferena major dintre o diagram de clase UML i o diagram entitaterelaie este reprezentat de diferena dintre o clas i o entitate: o clas este o generalizare a noiunii de entitate, care permite proiectantului s specifice nu numai atribute, ci i funcii (numite metode) aplicabile instanelor clasei. Astfel, aceast diferen face ca UML s fie mai general dect modelul entitate-relaie, iar proiectantul poate exploata diagramele de clase UML pentru a realiza aceeai specificaie pe care o poate obine cu ajutorul modelului entitate-relaie.

80

PROIECTAREA BAZELOR DE DATE

Fig. 2.2. Diagrama de clase corespunztoare unei restricii a modelului. Diagramele de clase UML au mai multe caracteristici dect diagramele entitate-relaie, cum ar fi posibilitatea de a specifica reguli de derivare pentru atribute i relaii utiliznd limbajul OCL (Object Constraint Language). Pentru exemplificarea utilizrii formalismului UML, vom considera o restricie a modelului utilizat pe parcursul acestei lucrri i vom construi diagrama de clase corespunztoare. Construcia diagramei a fost realizat cu ajutorul programului Microsoft Visio i este prezentat n figura 2.2 . Din motive de spaiu, a fost redus numrul de atribute precizate pentru fiecare clas din cadrul diagramei.

Modelarea entitate-relaie

81

Prezentm cteva observaii referitoare la construcia acestui model utiliznd o diagram de clase UML. Unele observaii au caracter general, amintind anumite noiuni UML necesare nelegerii construciei modelului. Tabelul urmtor stabilete echivalenele dintre formalismele modelului entitate-relaie i al notaiei UML: Entitate-relaie Tip entitate Asociere (relaie) Entitate Cardinalitate Model date conceptual UML Clas Asociere (relaie) Obiect Multiplicitate de Diagram de clase

Descrierea claselor n UML se divide n trei compartimente care conin respectiv numele clasei, atributele acesteia i signatura metodelor clasei. n cazul reprezentrii unui model relaional de date nu exist metode, deci al treilea compartiment este vid. Cardinalitile din modelul entitate-relaie propus de Chen i multiplicitile din formalismul UML sunt poziionate identic pe axa de reprezentare a relaiei. Asocierile dispun de anumite caracteristici, dintre care se remarc: nume, roluri, clase de asociere. Numele unei asocieri este dat de o form verbal activ sau pasiv. Acest nume este plasat n mijlocul liniei reprezentnd relaia respectiv. De exemplu, asocierea organizeaza dintre clasele Organizator i Prezentare este reprezentat n diagrama de clase prin acest nume plasat pe linia care conecteaz cele dou clase. Numele asocierii poate fi nsoit de un triunghi ndreptat ctre clasa desemnat de forma verbal, cu scopul de a indica sensul de citire a relaiei. De exemplu, n cazul asocierii creeaza se precizeaz c relaia se citete dinspre clasa Creator ctre clasa Vestimentatie. Extremitatea unei asocieri poate indica un rol. Acesta descrie modul n care clasele sunt percepute prin intermediul relaiei respective. Un rol este n general desemnat printr-o form nominal sau verbal. De exemplu, asocierea lucreaza dintre clasele Casa_moda i Creator este reprezentat att prin nume, ct i prin rolurile angajat i firma. n UML, asocierile one to one (1:1) au multiplicitatea 0..1 sau 1 la fiecare extremitate; asocierile one to many (1:N) au multiplicitatea * sau 1..* la o extremitate i 0..1 sau 1 la cealalt extremitate; asocierile many to many (N:N) au multiplicitatea * sau 1..* la fiecare extremitate.

82

PROIECTAREA BAZELOR DE DATE

O asociere many to many cu atribute este reprezentat n UML printr-o clas de asociere. Aceasta conine atributele asocierii i este conectat printr-o linie punctat la linia reprezentnd relaia. De exemplu, asocierii dintre clasele Sponsor i Prezentare i este ataat clasa de asociere Finanteaza. ntre clasele Angajat_temp i Model exist o asociere de generalizare, corespunztoare relaiei ISA (is a). Generalizarea este reprezentat printr-o sgeat, al crei vrf este un triunghi gol, dinspre subclas ctre superclas. ntre clasele Vestimentatie i Accesoriu exist o relaie de agregare compus. Agregarea reprezint n UML o asociere care nu este simetric i pentru care o extremitate are un rol predominant fa de cealalt. Aceast asociere privete un singur rol al su. Agregarea aparine mai degrab etapei de concepie detaliat dect celei de modelare. Astfel, ea se va traduce la nivelul codului SQL prin declanatori sau constrngeri. Exist dou forme de agregare: compus i partajat. Compunerea exprim o relaie de apartenen mai puternic, aprnd atunci cnd relaia este de tipul compune sau face parte din. Reprezentarea compunerii se face prin intermediul unui romb plin, poziionat lng clasa care reprezint ntregul. Multiplicitatea extremitii agregat nu poate depi 1. Agregarea partajat presupune c un obiect poate face parte din mai multe agregate, iar ntregul se poate modifica n timp.O astfel de relaie se reprezint prin intermediul unui romb gol, poziionat lng clasa care reprezint ntregul. Relaiile de grade strict mai mari dect 2 sunt reprezentate n UML cu ajutorul unui romb (ca n figura 2.2) sau prin intermediul unei clase cu stereotip. Stereotipurile constituie un mecanism de extensibilitate al UML. Ele permit extinderea vocabularului UML astfel nct s poat fi definite noi elemente ale modelului, derivate din cele existente dar cu proprieti specifice domeniului problemei. Reprezentarea grafic a unui stereotip se face prin plasarea numelui su, ncadrat ntre caracterele << i >> deasupra numelui unui alt element. n exemplul considerat, asocierea primeste este ternar, constituind totodat o clas de asociere. Reprezentarea acestei relaii de gradul 3 prin intermediul unei clase cu stereotip are forma indicat n figura 2.3.

Modelarea entitate-relaie

83

Fig. 2.3. Asociere UML de tipul 3 cu stereotip.

Diagrame entitate-relaie
Diagrama E/R model neformalizat pentru reprezentarea unui sistem din lumea real. Este un model de date conceptual de nivel nalt dezvoltat de Chen (1976) pentru a facilita proiectarea bazelor de date. Modelul de date conceptual este independent de: tipul SGBD-ului; platforma hardware utilizata. Modelul conceptual este constituit din concepte care descriu: structura bazei de date; tranzactii de regasire si reactualizare asociate. semnificativ pentru ceea ce modelm.
DEPARTAMENT SARCINA lucreaza_in conduce apartine_la SALARIAT atasat_la PROIECT

Entitate: persoan, loc, concept, activitate, eveniment care este

Observaii: Entitile devin tabele n modelele relaionale. n general, entitile se scriu cu litere mari. Entitile sunt substantive, dar nu orice substantiv este o entitate. Pentru fiecare entitate este obligatoriu s se dea o descriere detaliat. Nu pot exista, n aceeai diagram, dou entiti cu acelai nume, sau o aceeai entitate cu nume diferite. Cheia primar este un identificator unic n cadrul entitii, fcnd distincie ntre valori diferite ale acesteia.

Cheia primar: trebuie s fie unic i cunoscut la orice moment; trebuie s fie controlat de administratorul bazei; trebuie s nu conin informaii descriptive, s fie simpl, fr ambiguiti; s fie stabil; s fie familiar utilizatorului. Existena unei relaii este subordonat existenei entitilor pe care le leag. Gradul (tipul) unei relatii este dat de numarul entitatilor participante la relatia respectiva. Observaii: n modelul relaional, relaiile devin tabele speciale sau coloane speciale care refer chei primare. Relaiile sunt verbe, dar nu orice verb este o relaie.

Relaie (asociere): o comunicare ntre dou sau mai multe entiti.

Pentru fiecare relaie este important s se dea o descriere detaliat. n aceeai diagram pot exista relaii diferite cu acelai nume. n acest caz, le difereniaz entitile care sunt asociate prin relaia respectiv. Pentru fiecare relaie trebuie stabilit cardinalitatea (maxim i minim) relaiei, adic numrul de tupluri ce aparin relaiei. Se pot afla cardinalitatile cu verbele : poate (cardinalitate maxim) trebuie (cardinalitate minima)

Exemplu: Ci salariai pot lucra ntr-un departament? Muli! n cte departamente poate lucra un salariat? In cel mult unul! Relaia SALARIAT_lucreaza_in_DEPARTAMENT are cardinalitatea maxim many-one (n:1). Exemplu: Ci salariai trebuie s conduc un departament? Cel puin unul! Cte departamente trebuie s conduc un salariat? Zero! Relaia SALARIAT_conduce_DEPARTAMENT are cardinalitatea minim one-zero (1:0).

Atribut: proprietate descriptiv a unei entiti sau a unei relaii.

Atributele pot fi simple, compuse, cu valori multiple, derivate. Observaii: Trebuie fcut distincia ntre tipul atributului (devine coloan n modelele relaionale) i valoarea acestuia (devine valoare n coloane). Atributele sunt substantive, dar nu orice substantiv este atribut. Fiecrui atribut trebuie s i se dea o descriere complet (exemple, contraexemple, caracteristici). Pentru fiecare atribut trebuie specificat numele, tipul fizic (integer, float, char etc.), valori posibile, valori implicite, reguli de validare, tipuri compuse.

Pentru proiectarea diagramei entitate-relaie au fost stabilite anumite reguli (nu sunt unice): 1. entitile sunt reprezentate prin dreptunghiuri; 2. relaiile dintre entiti sunt reprezentate prin arce neorientate; 3. atributele care reprezint chei primare trebuie subliniate sau marcate prin simbolul #, plasat la sfritul numelui acestor atribute; 4. cardinalitatea minim este indicat n paranteze, iar cardinalitatea maxim se scrie fr paranteze; 5. nu trebuie specificate toate atributele.

SALARIAT cod_salariat nume prenume sex salariu

1 M(0)

M(0)

atasat_la data_initiala functia

M(0)

PROIECT nr_proiect descriere buget_alocat

1

conduce
1(0)

lucreaza_in
1

apartine_la

DEPARTAMENT cod_departament nume nr_cladire

SARCINA nr_proiect nr_sarcina data_inceperii stare

Diagrama E/R.

Cazuri speciale de entiti, relaii, atribute i modul lor de reprezentare n cadrul diagramei entitate-relaie.
1.

Entitate dependent nu poate exista n mod independent (SARCINA depinde de PROIECT). Cheia primar a unei entiti dependente include cheia primar a sursei (nr_proiect) i cel puin o descriere a entitii (nr_sarcina). Entitatea dependent se deseneaz prin dreptunghiuri cu linii mai subiri. Motenirea atributelor. Subentitate (subclas) submulime a unei alte entiti, numit superentitate (superclas) (SALARIAT < > PROGRAMATOR). Subentitatea se deseneaz prin dreptunghiuri incluse n superentitate. Exist o relaie ntre o subentitate i o superentitate, numit ISA, care are cardinalitatea maxim 1:1 i minim 1:0. Cheile primare, atributele i relaiile unei superentiti sunt valabile pentru orice subentitate. Afirmaia reciproc este fals. Generalizare. Din entiti similare care au mai multe atribute comune se pot crea superentiti. Aceste superentiti conin atributele comune, iar atributele speciale sunt asignate la subentiti. Pentru noile superentiti se introduc chei primare artificiale. Specializare. Dup valorile unor atribute clasificatoare se pot determina clase. Un grup de subentiti reciproc exclusive definete o clas. Clasele se aliniaz n desen vertical. ntr-o diagram E/R se pot defini relaii recursive. Unele relaii sunt relative la dou entiti i le numim de tip 2, iar dac relaiile implic mai mult de dou entiti, le vom numi de tip 3. Trei relaii de tip 2 sunt diferite de o relaie de tip 3. Rupnd o relaie de tip 3 n trei relaii de tip 2, pot aprea informaii incorecte. Trebuie excluse din model relaiile indirecte deoarece ele pot conduce la redundan n baza de date. Atributele derivabile trebuie eliminate i introduse expresii prin care aceste atribute pot fi calculate. Relaie sau atribut? Dac un atribut al unei entiti reprezint cheia primar a unei alte entiti, atunci el refer o relaie (cod_departament n tabelul SALARIAT). Entitate sau relaie? Se cerceteaz cheia primar. Dac aceasta combin cheile primare a dou entiti, atunci este vorba de o relaie. (cheia primar a relaiei asociat_la combin cod_salariat cu nr_proiect, prin urmare, SALARIAT_asociat la_PROIECT va defini o relaie i nu o entitate).

2.

3.

4.

5. 6.

7.

8.

9.

10.

11.

Un atribut indirect este inoportun. El nu descrie real relaia sau entitatea. Prin urmare, atributele indirecte trebuie reasignate. De fapt, un atribut indirect este un caz special de relaie indirect care trebuie eliminat pentru c introduce redundan n date (numrul cldirii n care lucreaz un salariat este un atribut al entitii DEPARTAMENT i nu este o caracteristic a entitii SALARIAT). Exist atribute opionale, a cror valoare este uneori necunoscut, alteori neaplicabil. Aceste atribute trebuie introduse la subentiti (comisionul pentru deplasare i zona de lucru sunt atribute specifice unui agent teritorial i trebuie introduse la subentitatea AGENT_TERITORIAL). Algoritmul pentru proiectarea diagramei entitate-relaie: 1. identificarea entitilor din cadrul sistemului analizat; 2. identificarea relaiilor dintre entiti i stabilirea cardinalitii; 3. identificarea atributelor aferente entitilor i asocierilor dintre entiti; 4. stabilirea atributelor de identificare a entitilor (stabilirea cheilor).
SALARIAT cod_salariat nume
ISA 1 1(0)

12.

job_cod AGENT_TERITORIAL zona comision PROGRAMATOR limbaj nivel

M(0) atasat_la data_initiala functia

PROIECT nr_proiect descriere M(0) buget_alocat

1

ISA 1 1(0)

apartine_la 1(0) M(1)

1 conduce 1(0)

M(0) lucreaza_in 1

1(0)

casatorit

SARCINA nr_proiect nr_sarcina data_inceperii stare

DEPARTAMENT cod_departament nume nr_cladire

Diagrama E/R.

Modelul EER (modelul E/R extins) = Diagrama E/R + concepte aditionale (subclas, superclas, motenire, specializare, generalizare).

Gestiunea activitilor de mprumut dintr-o bibliotec

S-a presupus (restrictiv) c ntr-o zi un cititor nu poate mprumuta, de mai multe ori, aceeai carte. Modelul prezint anomalii (de exemplu, cheia primar de la entitatea carte)! A fost gndit n aceast manier cu scop pur didactic. Entitile i relaiile care intervin n acest model sunt urmtoarele: 1. CARTE (entitate independent) orice carte care se gsete n inventarul bibliotecii. Cheia primar este atributul codel. 2. CITITOR (entitate independent) orice cititor care poate mprumuta cri. Cheia primar este atributul codec. 3. DOMENIU (entitate independenta) domeniul cruia i aparine o carte. Cheia primar este atributul coded. 4. IMPRUMUTA relaie avnd cardinalitatea m:m care leag entitile CITITOR i CARTE. 5. APARTINE relaie care leag atributele CARTE i DOMENIU. Relaia are cardinalitatea maxim m:1, iar cardinalitatea minim 1:1.

CARTE codel# titlu autor pret nrex

M(1) imprumuta

M(0)

CITITOR codec# nume dep

M(0) apartine

DOMENIU coded# intdom

Gestiunea activitilor de editare dintr-o editur

Se analizeaza activitatea dintr-o editur referitoare la culegerea textelor, realizarea elementelor grafice, machetarea unor publicaii.

SALARIAT cod_salariat# tip nume job

ISA 1 1(0)

M(1) scrie

M(0)

FRAME nr_publicatie# nr_capitol# nr_frame#

M(0) include 1

GRAFICIAN tip

ISA 1 1(0)

TEHNOREDACTOR tip_editor

M(0)

1 realizeaz

CAPITOL nr_publicatie# nr_capitol#

M(1) cuprinde 1

ISA 1 1(0)

REDACTOR_SEF experienta

M(0) coordoneaza

PUBLICATIE nr_publicatie# stil limba

Gestiunea activitilor unei firme de construcii

Baza de date construit prin acest model, furnizeaz informaii legate de obiective de execuie, investitori, executani, antiere, contracte etc. necesare unui manager al unei firme de construcii

8
SANTIER nr_santier# specialitate sef
1 executa

CONTRACTANT cod_contractant# adresa telefon cont banca tip_contractant

executa

M(0)

SUBANTREPENOR nume nume_adm functie_adm

1 ISA 1(0)

LUCRARE
M( cod_obiectiv# 1) cod_lucrare#

adresa
M(1)

INVESTITOR tip_investitor PERS_FIZICA nume prenume bi

investeste_in 1

necesita 1

ISA 1 ISA 1(0)

OBIECTIV_ INVESTITIE M(1) cod_obiectiv# denumire adresa

1 atasat_la

ISA

PERS_JURIDICA tip_juridic nume functie

1

1 incheie

CONTRACT nr_contract# M(1) tip_contract data_avans

Tabelele din cursurile Oracle Education. Tabelele emp, dept, salgrade modeleaz gestiunea salariailor unei firme. Tabelul emp(empno#, ename, job, mgr, hiredate, sal, com, deptno) conine informaii despre salariaii unei firme. Pentru fiecare salariat sunt definite urmtoarele atribute: empno: codul salariatului; ename: numele salariatului; job: funcia; mgr: codul efului; hiredate: data angajrii; sal: salariul; com: comisionul; deptno: codul departamentului n care lucreaz. Tabelul dept (deptno#, dname, loc) conine informaii despre departamentele n care lucreaz salariaii. Atributele sale reprezint: deptno: codul departamentului; dname: numele departamentului; loc: localitatea unde funcioneaz departamentul. Tabelul salgrade(grade#, losal, hisal) conine informaii despre grilele de salarizare. Atributele tabelului au urmtoarea semnificaie: grade: codul grilei de salarizare; losal: limita inferioar a grilei de salarizare; hisal: limita superioar a grilei de salarizare.

Ordonarea informaiilor cu privire la descoperirile de monede antice din Romania

PUNCT
petrecut_in

EVENIMENT

gasita_in

ARTICOL

publicata

MONEDA

stantata_cu

STANTA

inclusa_in

pastrata_la

TEZAUR

MUZEU

STANA (nr_stan, mprat emitent, valoare nominal, an emitere, monetria, legenda de pe avers, legenda de pe revers) == > atribute ale entitii STANTA Completai cardinalitatea!

Evidena colilor de oferi din Romania

SCOALA
cod_scoala#

CLIENT
cod_client#

INSTRUCTOR
cod_instructor#

EXAMEN
cod_examen#

MASINA
cod_masina#

EXAMINATOR
cod_examinator#

Completai relaiile (lucreaza_la, conduce, sustine, asista, instruieste) dintre entiti i specificai cardinalitatea!

10

Campionatele de fotbal ale diferitelor ri

ECHIPA
Cod_echipa# Nume Oras 2 joaca M(1) sustine M(1)

SPONSOR
Cod_sponsor# Nume

M(1)

MECI
Tara# Nr_etapa# Cod_meci#

M(1) apartine_de 1

ETAPA
Tara Nr_etapa M(1) atasata_la 1

CAMPIONAT
Tara#

11

Modelul relaional
Modelul relaional a fost conceput i dezvoltat de E.F. Codd. El este un model formal de organizare conceptual a datelor, destinat reprezentrii legturilor dintre date, bazat pe teoria matematic a relaiilor. Modelul relaional este alctuit numai din relaii i prin urmare, orice interogare asupra bazei de date este tot o relaie. Caliti: este simplu; riguros din punct de vedere matematic; nu este orientat spre sistemul de calcul. prezentarea datelor n tabele supuse anumitor operaii de tip proiecie, selecie, reuniune, compunere, intersecie etc. un sistem de baze de date ce suport un limbaj de tip SQL Structured Query Language; un sistem de baze de date care respect principiile modelului relaional introdus de E.F. Codd. Modaliti pentru definirea unui SGBD relaional:

Caracteristicile unui model relaional: structura relaional a datelor; operatorii modelului relaional; regulile de integritate care guverneaz folosirea cheilor n model.

Aceste trei elemente corespund celor trei componente ale ingineriei software: informaie, proces, integritate.

Structura datelor
Definirea noiunilor de domeniu, relaie, schem relaional, valoare null i tabel vizualizare (view). Conceptele utilizate pentru a descrie formal, uzual sau fizic elementele de baz ale organizrii datelor sunt date n urmtorul tabel: Formal relaie tuplu atribut domeniu Uzual tablou linie coloan tip de dat Fizic fiier nregistrare cmp tip de dat

12

Domeniu mulime de valori care poate fi definit fie enumernd elementele componente, fie definind o proprietate distinctiv a domeniului valorilor. Fie D1, D2, ..., Dn domenii finite, nu neaprat disjuncte. Produsul cartezian D1 D2 ... Dn al domeniilor D1, D2, ..., Dn este definit de mulimea tuplurilor (V1, V2, ..., Vn), unde V1 D1, V2 D2, ..., Vn Dn. Numrul n definete aritatea tuplului. O relaie R pe mulimile D1, D2, ..., Dn este o submulime a produsului cartezian D1 D2 ... Dn, deci este o mulime de tupluri. Caracteristicile unei relaii comentat curs! Caracteristicile unei relatii: are o denumire unica; fiecare celula contine o valoare atomica; fiecare atribut are nume unic; toate valorile unui atribut apartin aceluiasi domeniu; ordinea atributelor nu are importanta; nu exista dubluri ale tuplurilor; teoretic, ordinea tuplurilor nu are importanta. Definirea unei relaii se refer la mulimi care variaz n timp. Pentru a caracteriza o relaie este necesar existena un element invariant n timp: structura relaiei (schema relaional). Mulimea numelor atributelor corespunztoare unei relaii R definete schema relaional a relaiei respective. Vom nota schema relaional prin R(A1, A2, ..., An). Exemplu! Putem reprezenta o relaie printr-un tabel bidimensional n care fiecare linie corespunde unui tuplu i fiecare coloan corespunde unui domeniu din produsul cartezian. O coloan corespunde de fapt unui atribut. Numrul atributelor definete gradul (aritatea) relaiei, iar numrul de tupluri din relaie definete cardinalitatea relaiei. Exemplu (crearea unui tabel n SQL): CREATE TABLE salariat cod_salariat nume prenume sex salariu sot job_cod cod_departament ( SMALLINT, VARCHAR(25), VARCHAR(20), CHAR(1), INTEGER, SMALLINT, VARCHAR(6), SMALLINT );

13

Cnd se insereaz tupluri ntr-o relaie, de multe ori un atribut este necunoscut sau neaplicabil. Pentru a reprezenta acest atribut a fost introdus o valoare convenional n relaie, i anume valoarea null. Tabelul vizualizare (view, filtru, relaie virtual, vedere) constituie un filtru relativ la unul sau mai multe tabele, care conine numai informaia necesar unei anumite abordri sau aplicaii. Vizualizarea este virtual deoarece datele pe care le conine nu sunt n realitate memorate ntr-o baz de date. Este memorat numai definiia vizualizrii. Vizualizarea nu este definit explicit, ca relaiile de baz, prin mulimea tuplurilor componente, ci implicit, pe baza altor relaii prin intermediul unor expresii relaionale. Stabilirea efectiv a tuplurilor care compun vizualizarea se realizeaz prin evaluarea expresiei atunci cnd utilizatorul se refer la acest tabel. Exemplu (crearea unei vizualizri n SQL): CREATE VIEW programator(nume,departament) AS SELECT nume,cod_departament FROM salariat WHERE job_cod=programator;

de date trebuie s le satisfac.

Reguli de integritate aseriuni pe care datele coninute n baza

Trebuie fcut distincia ntre: regulile structurale inerente modelrii datelor; regulile de funcionare specifice unei aplicaii particulare.

Exist trei tipuri de constrngeri structurale (de cheie, de referin, de entitate) ce constituie mulimea minimal de reguli de integritate pe care trebuie s le respecte un SGBD relaional. Restriciile de integritate minimale sunt definite n raport cu noiunea de cheie a unei relaii. O mulime minimal de atribute ale cror valori identific unic un tuplu ntr-o relaie reprezint o cheie pentru relaia respectiv. Fiecare relaie are cel puin o cheie. Una dintre cheile candidat va fi aleas pentru a identifica efectiv tupluri i ea va primi numele de cheie primar. Cheia primar nu poate fi reactualizat. Atributele care reprezint cheia primar sunt fie subliniate, fie urmate de semnul #. O cheie identific linii i este diferit de un index care localizeaz liniile. O cheie secundar este folosit ca index pentru a accesa tupluri. Un grup de atribute din cadrul unei relaii care conine o cheie a relaiei poart numele de supercheie.

14

Fie schemele relaionale R1(P1, S1) i R2(S1, S2), unde P1 este cheie primar pentru R1, S1 este cheie secundar pentru R1, iar S1 este cheie primar pentru R2. n acest caz, vom spune c S1 este cheie extern (cheie strin) pentru R1. Modelul relaional respect trei reguli de integritate structural. Regula 1 unicitatea cheii. Cheia primar trebuie s fie unic i minimal.

Regula 2 integritatea entitii. Atributele cheii primare trebuie s fie diferite de valoarea null. Regula 3 integritatea referirii. O cheie extern trebuie s fie ori null n ntregime, ori s corespund unei valori a cheii primare asociate.

Proiectarea modelului relaional (exemple curs!)

Transformarea entitilor

Entitile independente devin tabele independente. Cheia primar nu conine chei externe. Entitile dependente devin tabele dependente. Cheia primar a entitilor dependente conine cheia primar a entitii de care depinde (cheie extern) plus unul sau mai multe atribute adiionale. Subentitile devin subtabele. Cheia extern se refer la supertabel, iar cheia primar este aceast cheie extern (cheia primar a subentitii PROGRAMATOR este cod_salariat care este o cheie extern).

Transformarea relaiilor

Relaiile 1:1 i 1:n devin chei externe. Relaia conduce devine coloan n tabelul DEPARTAMENT, iar relaia lucreaza_in devine coloan n tabelul SALARIAT. Simbolul indic plasamentul cheii externe, iar simbolul exprim faptul c aceast cheie extern este coninut n cheia primar. Relaia 1:1 plaseaz cheia extern n tabelul cu mai puine linii. Relaia m:n devine un tabel special, numit tabel asociativ, care are dou chei externe pentru cele dou tabele asociate. Cheia primar este compunerea acestor dou chei externe plus eventuale coloane adiionale. Tabelul se deseneaz punctat.

15

Relaiile de tip trei devin tabele asociative. Cheia primar este compunerea a trei chei externe plus eventuale coloane adiionale.

Transformarea atributelor

Un atribut singular devine o coloan. Atributele multiple devin tabele dependendente ce conin cheia primar a entitii i atributul multiplu. Cheia primar este o cheie extern, plus una sau mai multe coloane adiionale. Entitile devin tabele, iar atributele lor devin coloane n aceste tabele. Ce devin atributele relaiilor? Pentru relaii 1:1 i 1:n, atributele relaiilor vor aparine tabelului care conine cheia extern, iar pentru relaii m:n i de tipul trei, atributele vor fi plasate n tabelele asociative. SALARIAT
cod_salariat#

PROIECT
nr_proiect#

conduce

lucreaza_in

apartine_la

DEPARTAMENT
cod_departament#

SARCINA
nr_proiect# nr_sarcina#

SALARIAT
cod_salariat#

atasat_la
cod_salariat# nr_proiect#

PROIECT
nr_proiect#

TELEFON SALARIAT
cod_salariat# cod_salariat# nr_telefon#

Cele patru tipuri de tabele (independente, dependente, subtabele i asociative) se deosebesc prin structura cheii primare.

16

Tabel Independent Subtabel Dependent Asociativ

Reprezint entitate independent subentitate entitate dependent atribute multiple relaie m:n relaii de tip 3

Cheie primar nu conine chei externe o cheie extern o cheie extern i una sau mai multe coloane adiionale dou sau mai multe chei externe i (opional) coloane adiionale

Diagrama conceptual pentru proiectarea modelului relaional comentat a fost construit din diagrama E/R prin adugarea tabelelor asociative i prin marcarea cheilor externe.

SALARIAT cod_salariat# salariu nume sex

job_cod AGENT_TERITORIAL zona comision PROGRAMATOR limbaj nivel ATASAT_LA cod_salariat# nr_proiect# functie

PROIECT nr_proiect# descriere buget_alocat

apartine_la

conduce

lucreaza_in

casatorit

DEPARTAMENT cod_departament# nume nr_cladire

TELFON cod_salariat# nr_telefon#

SARCINA nr_proiect# nr_sarcina# data_inceperii stare

Schemele relaionale corespunztoare acestei diagrame conceptuale sunt urmtoarele: SALARIAT(cod_salariat#, nume, prenume, sex, job_cod, cod_sot, forma_plata, nr_depart);

17

DEPARTAMENT(cod_departament#, nume, numar_cladire, cod_sal); ATASAT_LA(cod_salariat#, nr_proiect#, functia); PROIECT(nr_proiect#, descriere, buget_alocat); SARCINA(nr_proiect#, nr_sarcina, data_inceperii, stare); AGENT_TERITORIAL(cod_salariat#, zona, comision); PROGRAMATOR(cod_salariat#, limbaj, nivel); TELEFON(cod_salariat#, nr_telefon#).

Gestiunea activitilor unei firme de construcii

CONTRACTANT(cod_contractant#, tip_contractant); adresa, telefon, cont, banca,

SUBANTREPRENOR(cod_contractant#, nume, nr_reg_comert, nume_adm, functie_adm); INVESTITOR(cod_contractant#, tip_investitor); PERS_FIZICA(cod_contractant#, nume, prenume, bi); PERS_JURIDICA(cod_contractant#, tip_juridic, nume, reprez_legal, functie); CONTRACT(nr_contract#, tip_contract, data_incheiere, garantie, val_investitie, durate_executie, cont, banca, perioada, avans, data_avans, cod_contractant); SANTIER(nr_santier#, specialitate, sef); OBIECTIV_INVESTITIE(cod_obiectiv#, denumire, adresa, adc, nr_cert_urb, nr_aut_constr, nr_contract, cod_contractant); LUCRARE(cod_lucrare#, cod_obiectiv#, tip_lucrare, nume, data_inc, data_sf, nr_santier, cod_contractant);

18

CONTRACTANT cod_contractant# adresa telefon cont banca

tip_contractant SUBANTREPENOR nume nume_adm funcie_adm LUCRARE cod_lucrare# cod_obiectiv# executa ANTIER nr_antier# specialitate ef

executa

necesita

INVESTITOR tip_investitor

OBIECTIV_INVESTITIE cod_obiectiv# denumire adresa

investeste_in

PERS_FIZICA nume prenume bi

atasat_la

CONTRACT PERS_JURIDICA tip_juridic nume functie nr_contract# tip_contract data_avans

incheie

19

Gestiunea activitilor de editare dintr-o editur

SALARIAT cod_salariat# nume job GRAFICIAN tip TEHNOREDACTOR tip_editor REDACTOR_SEF experienta coordoneaza TELEFON cod_salariat# nr_telefon# LIMBA cod_salariat# limba_cun# PUBLICATIE nr_publicatie# stil REALIZEAZA cod_salariat# nr_publicatie# nr_capitol# nr_frame# FRAME nr_publicatie# nr_capitol# nr_frame# tip include scrie CAPITOL nr_publicatie# nr_capitol# dimensiune cuprinde

SALARIAT(cod_salariat#, nume, prenume, vechime, salariu, job); GRAFICIAN(cod_salariat#, tip); TEHNOREDACTOR(cod_salariat#, tip_platforma, tip_editor, viteza); REDACTOR_SEF(cod_salariat#, experienta); LIMBA(cod_salariat#, limba_cunos#); TELEFON(cod_salariat#, nr_telefon#); REALIZEAZA(cod_salariat#, nr_frame#, nr_publicatie#, nr_capitol#, data_inc, data_lim); FRAME(nr_frame#, nr_publicatie#, nr_capitol#, tip, dim, format); CAPITOL(nr_publicatie#, nr_capitol#, dimensiune, cod_salariat); PUBLICATIE(nr_publicatie#, stil, beneficiar, autor, cod_salariat, cost, titlu, limba).

20

Algebra relaional
Limbajul de definire a datelor (LDD) precizeaz entitile, relaiile dintre ele, atributele, structura atributelor, cheile, constrngerile, prin urmare definete structura obiectelor bazei de date (schema bazei). Limbajul de prelucrare a datelor (LMD) dintr-o baz de date relaionale cuprinde aspecte referitoare la introducerea, eliminarea, modificarea i cutarea datelor. Introducerea datelor permite adugarea de tupluri la o relaie. Tuplurile pot fi introduse de utilizator sau pot fi obinute din alte relaii existente n baza de date. Eliminarea datelor permite tergerea tuplurilor ce satisfac condiii date. Modificarea datelor permite reactualizarea tuplurilor ce satisfac condiii date cu noi valori ale atributelor sau cu rezultate ale unor operaii aritmetice efectuate asupra unor valori existente. Cutarea datelor permite gsirea tuplurilor sau a unor pri ale tuplurilor ce satisfac condiii date.

Modelul relaional ofer dou mulimi de operatori pe relaii: algebra relaional (filtrele se obin aplicnd operatori specializai asupra uneia sau mai multor relaii din cadrul bazei relaionale); calculul relaional (filtrele se obin cu ajutorul unor formule logice pe care tuplurile rezultatului trebuie s le satisfac). Algebra relaional a fost introdus de E.F. Codd ca o mulime de operaii formale acionnd asupra unor relaii i avnd ca rezultat alte relaii. Baza teoretic pentru limbajele de interogare relaionale o constituie operatorii introdui de Codd pentru prelucrarea relaiilor. Operatorii modelului relaional definesc operaiile care se pot efectua asupra relaiilor n scopul realizrii funciilor de prelucrare asupra BD. Operatorii sunt numai pentru citire (nu actualizeaza operanzi)!!! Scopul fundamental al algebrei relationale este de a permite scrierea expresiilor relationale. Expresiile servesc ca o reprezentare de nivel superior, simbolic, a inteniilor utilizatorului i pot fi supuse unei diversiti de reguli de transformare (optimizare). Relaiile sunt nchise fa de algebra relaional (operanzii i

21

rezultatele sunt relaii ieirea unei operaii poate deveni intrare pentru alta) posibilitatea imbricrii expresiilor n algebra relaional). Operatorii algebrei relaionale sunt: operatori tradiionali pe mulimi (UNION, INTERSECT, PRODUCT, DIFFERENCE); operatori relaionali speciali (PROJECT, SELECT, JOIN, DIVISION).

Calculul relaional reprezint o adaptare a calculului predicatelor la domeniul bazelor de date relaionale. Ideea de baz este de a identifica o relaie cu un predicat. Pe baza unor predicate iniiale, prin aplicarea unor operatori ai calculului cu predicate (conjuncia, disjuncia, negaia, cuantificatorul existenial i cel universal) se pot defini noi relaii. Calculul relaional poate s fie orientat pe tupluri sau orientat pe domenii. Echivalena dintre algebra relaional i calculul relaional a fost demonstrat de J.D.Ullman. Aceast echivalen arat c orice relaie posibil de definit n algebra relaional poate fi definit i n cadrul calcului relaional, i reciproc. Operatorii (unari sau binari) algebrei relaionale realizeaz urmtoarele funcii: SELECT (selecie) extrage tupluri ce satisfac o condiie specificat; PROJECT (proiecie) extrage atributele specificate; DIFFERENCE (diferen) extrage tupluri care apar ntr-o relaie, dar nu apar n cealalt; PRODUCT (produs cartezian) genereaz toate perechile posibile de tupluri, primul element al perechii fiind luat din prima relaie, iar cel deal doilea element din cealalt relaie; UNION (reuniune) reunete dou relaii; INTERSECT (intersecie) extrage tupluri care apar n ambele relaii; DIVISION (diviziune) extrage valorile atributelor dintr-o relaie, care apar n toate valorile atributelor din cealalt relaie; JOIN (compunere) extrage tupluri din mai multe relaii corelate: NATURAL JOIN (compunere natural) combin tupluri din dou relaii, cu condiia ca atributele comune s aib valori identice; SEMI-JOIN (semi-compunere) selecteaz tupluri ce aparin unei singure relaii, care sunt corelate cu tupluri din cea de a doua relaie;

22

-JOIN (-compunere) combin tupluri din dou relaii (nu neaparat corelate), cu condiia ca valorile atributelor specificate s satisfac o anumit condiie; OUTER JOIN (compunere extern) combin tupluri din dou relaii, astfel nct condiiile de corelare s fie satisfcute. Tuplurile din orice relaie care nu satisfac aceste condiii sunt completate cu valori null. Pentru operatorii UNION, INTERSECT i DIFFERENCE, se presupune c sunt aplicai numai la relaii avnd aceeai aritate, iar ordinea (nu numele) atributelor este aceeai.

Operatorul PROJECT
Proiecia este o operaie unar care elimin anumite atribute ale unei relaii producnd o submulime pe vertical a acesteia. Suprimarea unor atribute poate avea ca efect apariia unor tupluri duplicate, care trebuie eliminate. Prin proiecie se construiete dintr-o relaie R, o nou relaie: a) tergnd din R atributele care nu sunt menionate n parametrii proieciei; b) eliminnd dublurile care apar dup tergere. Pentru a reprezenta operatorul proiecie sunt utilizate diferite notaii: A1, ..., Am (R) R[A1, ..., Am] unde A1, A2, ..., Am sunt parametrii proieciei relativ la relaia R. Exemplu. S se obin o list ce conine numele, prenumele i sexul angajailor. 1. Proiecie n algebra relaional: Rezultat = PROJECT(SALARIAT, nume, prenume, sex)
2.

PROJECT (R, A1, ..., Am)

Proiecie cu dubluri n SQL: nume, prenume, sex salariat; DISTINCT nume, prenume, sex salariat;

SELECT FROM
3.

Proiecie fr dubluri n SQL:

SELECT FROM

23

Operatorul SELECT
Selecia (restrictia) este o operaie unar care produce o submulime pe orizontal a unei relaii R. Aceast submulime se obine prin extragerea tuplurilor din R care satisfac o condiie specificat. Sunt utilizate diferite notaii: condiie(R) SELECT(R, condiie) R[condiie] RESTRICT(R, condiie).

Exemplu. S se obin informaii complete despre angajaii de sex masculin.

1.

Selecie n algebra relaional: Selecie n SQL: * salariat sex = m;

Rezultat = SELECT(SALARIAT, sex = m)

2.

SELECT FROM WHERE

Operatorul UNION
Reuniunea a dou relaii R i S este mulimea tuplurilor aparinnd fie lui R, fie lui S, fie ambelor relaii. Sunt utilizate notaiile: RS UNION(R, S) OR(R, S) APPEND(R, S). Exemplu. S se obin lista cu numele persoanelor fizice i a subantreprenorilor. SELECT FROM UNION SELECT FROM nume subantreprenor nume pers_fizica;

24

Operatorul DIFFERENCE
Diferena a dou relaii R i S este mulimea tuplurilor care aparin lui R, dar nu aparin lui S. Diferena este o operaie binar necomutativ care permite obinerea tuplurilor ce apar numai ntr-o relaie. Sunt utilizate diferite notaii: RS DIFFERENCE(R, S) REMOVE(R, S) MINUS(R, S). Exemplu. S se obin lista cu numrul contractului, tipul contractului, valoarea investiiei i durata lucrrii pentru contractele de subantrepriz pentru care valoarea investiiei nu depete 60000$.
1. Diferen n algebra relaional:

R=PROJECT(SELECT(CONTRACT, tip_contract=T), nr_contract, tip_contract, val_investitie, durata_lucrare); S=PROJECT(SELECT(CONTRACT, val_investitie > 60000), nr_contract, tip_contract, val_investitie, durata_lucrare); Rezultat = DIFFERENCE(R, S)
2. Diferena n SQL:

SELECT

FROM WHERE MINUS SELECT nr_contract,tip_contract, val_investitie,durata_lucrare FROM contract WHERE val_investitie>60000; Evident diferena se poate referi la tabele diferite! Implementai cererea prin care se listeaz toate oraele n care se afl o filial, dar nici o proprietate.

nr_contract,tip_contract, val_investitie,durata_lucrare contract tip_contract

Operatorul INTERSECT
Intersecia a dou relaii R i S este mulimea tuplurilor care aparin i lui R i lui S. Operatorul INTERSECT este un operator binar, comutativ, derivat:

25

R S = R (R S) R S = S (S R). Sunt utilizate diferite notaii: INTERSECT(R, S) RS AND(R, S). n anumite dialecte SQL exist operator special (INTERSECT), care realizeaz aceast operaie. Operatorii INTERSECT i DIFFERENCE pot fi simulai n SQL (n cadrul comenzii SELECT) cu ajutorul opiunilor EXISTS, NOT EXISTS, IN, != ANY. Exemplu. Utiliznd tabelele agent_teritorial i programator s se obin lista codurilor salariailor care sunt programatori, dar care lucreaz i ca ageni teritoriali.
1.

Intersecie n algebra relaional:

R = PROJECT(AGENT_TERITORIAL, cod_salariat); S = PROJECT(PROGRAMATOR, cod_salariat), Rezultat = INTERSECT(R, S).

2.

Intersecie n SQL:

SELECT cod_salariat FROM agent_teritorial INTERSECT SELECT cod_salariat FROM programator;

3.

Simularea interseciei n SQL:

SELECT cod_salariat FROM programator p WHERE EXISTS (SELECT cod_salariat FROM agent_teritorial a WHERE p.cod_salariat=a.cod_salariat);

Operatorul PRODUCT
Fie R i S relaii de aritate m, respectiv n. Produsul cartezian al lui R cu S este mulimea tuplurilor de aritate m + n unde primele m componente formeaz un tuplu n R, iar ultimele n componente formeaz un tuplu n S. Sunt utilizate diferite notaii:

26

RS PRODUCT(R, S) TIMES(R, S). Exemplu. S se obin lista tuturor posibilitilor de investiie n diverse obiective de ctre o firm care este persoan juridic.
1.

Produs cartezian n algebra relaional:

R = PROJECT(PERS_JURIDICA, nume, cod_contractant); S = PROJECT(OBIECTIV_INVESTITIE, denumire); Rezultat = PRODUCT(R, S).

2.

Produs cartezian n SQL: cod_contractant, nume, denumire obiectiv_investitie, pers_juridica;

SELECT FROM

Operatorul DIVISION
Diviziunea este o operaie binar care definete o relaie ce conine valorile atributelor dintr-o relaie care apar n toate valorile atributelor din cealalt relaie. Sunt utilizate diferite notaii: DIVIDE(R, S) DIVISION(R, S) R S. Diviziunea conine acele tupluri de dimensiune n m la care, adugnd orice tuplu din S, se obine un tuplu din R. Operatorul diviziune poate fi exprimat formal astfel: R(n) S(m) = {t(n-m) s S, (t, s) R} unde n > m i S . Operatorul DIVISION este legat de cuantificatorul universal () care nu exist n SQL. Cuantificatorul universal poate fi ns simulat cu ajutorul cuantificatorului existenial () utiliznd relaia: x P(x) x P(x). Prin urmare, operatorul DIVISION poate fi exprimat n SQL prin succesiunea a doi operatori NOT EXISTS. Exemplu. S se obin codurile salariailor ataai tuturor proiectelor pentru care s-a alocat un buget egal cu 1000.
1.

Diviziune n algebra relaional:

27

R = PROJECT(ATASAT_LA, cod_salariat, nr_proiect); S = PROJECT(SELECT(PROIECT, buget = 1000), nr_proiect); Rezultat = DIVISION(R, S).
2.

Diviziune n SQL:

SELECT UNIQUE cod_salariat FROM atasat_la sx WHERE NOT EXISTS (SELECT * FROM proiect pp WHERE proiect.buget=1000 AND NOT EXISTS (SELECT * FROM atasat_la bb WHERE pp.nr_proiect=bb.nr_proiect AND bb.cod_salariat=sx.cod_salariat));
3.

Simularea diviziunii cu ajutorul funciei COUNT:

SELECT cod_salariat FROM atasat_la WHERE nr_proiect IN (SELECT nr_proiect FROM proiect WHERE buget=1000) GROUP BY cod_salariat HAVING COUNT(nr_proiect)= (SELECT COUNT(*) FROM proiect WHERE buget=1000);

Operatorul JOIN
Operatorul de compunere (uniune) permite regsirea informaiei din mai multe relaii corelate. Operatorul combin produsul cartezian, selecia i proiecia. Operatorul de compunere natural (NATURAL JOIN) combin tupluri din dou relaii R i S, cu condiia ca atributele comune s aib valori identice. Algoritmul care realizeaz compunerea natural este urmtorul:
1.

Operatorul NATURAL JOIN

se calculeaz produsul cartezian R S;

28

2.

3.

pentru fiecare atribut comun A care definete o coloan n R i o coloan n S, se selecteaz din R S tuplurile ale cror valori coincid n coloanele R.A i S.A (atributul R.A reprezint numele coloanei din R S corespunztoare coloanei A din R); pentru fiecare astfel de atribut A se proiecteaz coloana S.A, iar coloana R.A se va numi A. JOIN(R, S) = i1,...,im (R.A1 = S.A1) ... (R.Ak = S.Ak)(R S),

Operatorul NATURAL JOIN poate fi exprimat formal astfel: unde A1, ..., Ak sunt atributele comune lui R i S, iar i1, ..., im reprezint lista componentelor din R S (pstrnd ordinea iniial) din care au fost eliminate componentele S.A1, ..., S.Ak. Exemplu. S se obin informaii complete despre angajai i departamentele n care lucreaz.
1.

Operatorul de compunere natural n algebra relaional: Operatorul de compunere natural n SQL: * salariat, departament nr_depart = cod_departament;

Rezultat = JOIN(SALARIAT, DEPARTAMENT).

2.

SELECT FROM WHERE

Operatorul -JOIN
Operatorul -JOIN combin tupluri din dou relaii (nu neaprat corelate) cu condiia ca valorile atributelor specificate s satisfac o anumit condiie specificat explicit n cadrul operaiei. Operatorul -JOIN este un operator derivat, fiind o combinaie de produs scalar i selecie: JOIN(R, S, condiie) = condiie (R S) Exemplu. S se afieze pentru fiecare salariat, codul acestuia i grila sa de salarizare. SELECT empno, level FROM salgrade, emp WHERE sal BETWEEN losal AND hisal; Exemplu. S se obin informaii despre contractani (codul i banca) i obiectivele de investiie asociate acestora (denumire, numr certificat de urbanizare) cu condiia ca obiectivele s nu fie la aceeai adres ca i contractanii.

29

1.

Operatorul -JOIN n algebra relaional:

R = PROJECT(CONTRACTANT, cod_contractant, banca); S = PROJECT(OBIECTIV_INVESTITIE, denumire, nr_cert_urb); Rezultat = JOIN(R, S, OBIECTIV_INVESTITIE.adresa <> CONTRACTANT.adresa).
2.

Opratorul -JOIN n SQL: cod_contractant,banca, nr_cert_urb, denumire contractant a,obiectiv_investitie b b.adresa <> a.adresa;

SELECT FROM WHERE

Operatorul SEMI-JOIN
Operatorul SEMI-JOIN conserv atributele unei singure relaii participante la compunere i este utilizat cnd nu sunt necesare toate atributele compunerii. Operatorul este asimetric. Tupluri ale relaiei R care particip n compunerea (natural sau -JOIN) dintre relaiile R i S. SEMI-JOIN este un operator derivat, fiind o combinaie de proiecie i compunere natural sau proiecie i -JOIN: SEMIJOIN(R, S) = M (JOIN(R, S)) SEMIJOIN(R, S, condiie) = M (JOIN(R, S, condiie)), unde am notat prin M atributele relaiei R. Exemplu. S se obin informaii referitoare la persoanele fizice (nume, buletin) care investesc n obiective cu caracter recreativ.
1.

Operatorul SEMI-JOIN n algebra relaional:

R = SELECT(OBIECTIV_INVESTITIE, denumire = cabana OR denumire = casa de vacanta) S = JOIN(PERS_FIZICA, R) Rezultat = PROJECT(S, nume, buletin).
2.

Operatorul SEMI-JOIN n SQL: nume,bi pers_fizica a,obiectiv_investitie b a.cod_contractant = b.cod_contractant (denumire=cabana)OR (denumire= casa de vacanta);

SELECT FROM WHERE AND

30

Operatorul OUTER JOIN

Operaia de compunere extern combin tupluri din dou relaii pentru care sunt satisfcute condiiile de corelare. n cazul aplicrii operatorului JOIN se pot pierde tupluri, atunci cnd exist un tuplu n una din relaii pentru care nu exist nici un tuplu n cealalt relaie, astfel nct s fie satisfcut relaia de corelare. Operatorul elimin acest inconvenient prin atribuirea valorii null valorilor atributelor care exist ntr-un tuplu din una dintre relaiile de intrare, dar care nu exist i n cea de-a doua relaie. Practic, se realizeaz compunerea a dou relaii R i S la care se adaug tupluri din R i S, care nu sunt coninute n compunere, completate cu valori null pentru atributele care lipsesc. Compunerea extern poate fi: LEFT, RIGHT, FULL. De exemplu, OUTER JOIN LEFT reprezint compunerea n care tuplurile din R, care nu au valori similare n coloanele comune cu relaia S, sunt de asemenea incluse n relaia rezultat. Exemplu. S se obin informaii referitoare la persoanele fizice care sunt investitori (chiar dac nu au investit n obiective industriale) i la obiectivele de investiie industriale (chiar i cele care nu sunt construite de persoane fizice). R = SELECT(OBIECTIV_INVESTITIE, denumire = 'industrial') Rezultat = OUTERJOIN(PERS_FIZICA, R). Operatorii algebrei relaionale pot fi reprezentai grafic cu ajutorul unor simboluri speciale. curs! Operaii adiionale: complement, despicare, nchidere tranzitiv. Funcii asociate: MIN, MAX, COUNT, AVG, SUM, VAR, STD etc.

31

Evaluarea i optimizarea interogrilor

Procesarea interogrilor
O expresie a algebrei relaionale este constituit din relaii legate prin operaii din algebra relaional. O expresie se poate reprezenta grafic cu ajutorul unui arbore, numit arbore algebric, n care nodurile corespund operatorilor din cadrul expresiei respective. Evaluarea unei expresii presupune efectuarea prelucrrilor indicate de operatorii din expresie n ordinea apariiilor sau n ordinea fixat prin paranteze. Rezultatul evalurii unei expresii este o relaie derivat din relaiile menionate ca operanzi n cadrul expresiei. Dou expresii sunt echivalente, dac n urma evalurii lor se obine ca rezultat aceeai relaie. Exemple referitoare la moduri echivalente de exprimare a unei cereri (vor fi rezolvate la curs!). 1. Informaii despre salariaii care nu contribuie la machetarea nici unei publicaii, dar au retribuia mai mare dect o valoare dat. 2. Codul i numele subantreprenorilor care au realizat lucrri specializate la obiective case de vacan sau cabane. 3. Codurile i telefoanele investitorilor, valoarea si durata de execuie a investitiilor a caror valoare este ntre dou limite specificate. 4. Perioada de desfurare i preul ofertelor care ncep dup 1 ianuarie 2003 i sunt: sejururi la munte; excursii n care autocarele sunt conduse de oferi angajai dup 1 mai 1987 i supravegheate de ghizi ce cunosc limba englez care au fcut specializare n Suedia. n majoritatea sistemelor de gestiune, i n special n cele relaionale, interfaa cu utilizatorul este de tip neprocedural. Utilizatorul definete datele pe care dorete s le vizualizeze fr a da algoritmii de acces. Sistemul trebuie s converteasc cererea utilizatorului: ntr-o cerere optimal; n proceduri de acces optimal la datele fizice. Garantarea absolut a performanelor optime pentru procesorul limbajului relaional este imposibil. Corect ar fi utilizarea cuvntului ameliorare n locul cuvntului optimizare.

32

Evaluarea unei interogri se efectueaz n trei etape.

Analiza cererii presupune studierea sintactic i semantic a cererii pentru a verifica corectitudinea sa i a simplifica criteriul de cutare. Ordonanarea presupune descompunerea cererii ntr-o mulime de operaii elementare i determinarea unei ordini optimale a acestor operaii. Operaiile sunt, n general, cele ale algebrei relaionale. La sfritul etapei se obine un plan de execuie pentru cerere. Execuia presupune efectuarea (paralel i/sau secvenial) operaiilor elementare furnizate de planul de execuie pentru a obine rezultatul cererii.

Presupunem c utilizatorul transmite sistemului de gestiune o cerere exprimat prin ordine SQL. Pentru a rspunde cererii, SGBD-ul trebuie s neleag cererea utilizatorului. Cererea trebuie s fie corect sintactic, datele trebuie s fie disponibile utilizatorului i trebuie localizate analiznd diferite drumuri de acces la ele. Aceste funcii sunt realizate de SGBD cu ajutorul a dou module funcionale care comunic permanent:

analizorul cererilor, care asigur verificarea sintactic i semantic a cererii, localizarea datelor implicate n cerere (gsirea adresei blocurilor ce conin datele), furnizarea planului de execuie. administratorul datelor (executorul), care execut efectiv cererea (primete planurile de execuie furnizate de modulul de optimizare i le execut). Execuia presupune cutarea blocurilor ce conin datele i transferul blocurilor n memoria cache.

Ideea general: cerere arbore algebric (nu este unic) plan de executie optimizare Un plan de execuie implic o secven de pai pentru evaluarea cererii (n mod obinuit, fiecare pas din planul de execuie corespunde unei operaii relaionale) precum i metoda care va fi folosit pentru evaluarea operaiei. De obicei, pentru o operaie relaional dat, exist mai multe metode ce pot fi folosite pentru evaluarea acesteia. Dou planuri de execuie diferite care au ntotdeauna acelai rezultat se numesc echivalente. Planuri de execuie echivalente pot avea diferite costuri. Scopul optimizrii cererilor este de a gsi, printre diversele planuri de execuie echivalente, pe acela de cost minim. ntr-un sistem centralizat, costul evalurii unei cereri este suma a dou componente, costul I/O (transferuri de date) i costul CPU (verificare de condiii, operaii join etc.).

33

Ordinea de execuie a operaiilor

O interogare const dintr-un numr de operaii. Ordinea n care se efectueaz operaiile are un rol important n evaluarea costului necesar realizrii interogrii. Exist dou modaliti de abordare pentru a determina ordinea de execuie a operaiilor: algebric; bazat pe estimarea costului. Ambele folosesc o mulime de reguli care permit transformarea unui plan de execuie (reprezentat ca o expresie scris n termenii algebrei relaionale) n altul, echivalent. Optimizarea cererilor bazat pe algebra relaional se realizeaz n dou etape: se exprim cererile sub forma unor expresii algebrice relaionale; se aplic acestor expresii transformri algebrice care conduc la expresii echivalente, dar care vor fi executate mai eficient. Procesul de transformare a cererilor se realizeaz conform unei strategii de optimizare care poate s fie: independent de modul de memorare a datelor (strategie general); dependent de modul de memorare (strategie specific unui anumit SGBD).

Proprietile operatorilor algebrei relaionale

Proprietatea 1. Comutativitatea operaiilor de join i produs cartezian: JOIN(R1, R2) = JOIN(R2, R1) R1 R2 = R2 R1 Proprietatea 2. Asociativitatea operaiilor de join i produs cartezian: JOIN(JOIN(R1, R2), R3) = JOIN(R1, JOIN(R2, R3)) (R1 R2) R3 = R1 (R2 R3) Proprietatea 3. Compunerea proieciilor: A1,...,Am (B1,...,Bn (R)) = A1,...,Am (R), unde {A1, A2,...,Am } {B1, B2,...,Bn}. Proprietatea 4. Compunerea seleciilor: cond1 (cond2 (R)) = cond1cond2 (R) = cond2 (cond1 (R)), unde am notat prin cond condiia dup care se face selecia.

34

Proprietatea 5. Comutarea seleciei cu proiecia: A1,...,Am (cond (R)) = cond (A1,...,Am (R)), unde condiia dup care se face selecia implic numai atributele A1,...,Am. Dac condiia implic i atributele B1,...,Bn, care nu aparin mulimii {A1,...,Am}, atunci: A1,...,Am (cond (R)) = A1,...,Am (cond (A1,...,Am,B1,...,Bn (R))) Proprietatea 6. Comutarea seleciei cu produsul cartezian: Dac toate atributele menionate n condiia dup care se face selecia sunt atribute ale relaiei R1, atunci: cond (R1 R2) = cond (R1) R2 Dac condiia este de forma cond1cond2 i dac cond1 implic numai atribute din R1, iar cond2 implic numai atribute din R2, atunci cond (R1 R2) = cond1 (R1) cond2 (R2) Dac cond1 implic numai atribute din R1, iar cond2 implic atribute att din R1 ct i din R2, atunci: cond (R1 R2) = cond2 (cond1 (R1) R2) Proprietatea 7. Comutarea seleciei cu reuniunea: cond (R1 R2) = cond (R1) cond (R2) Proprietatea 8. Comutarea seleciei cu diferena: cond (R1 R2) = cond (R1) cond (R2) Proprietatea 9. Comutarea proieciei cu reuniunea: A1,...,Am (R1 R2) = A1,...,Am (R1) A1,...,Am (R2) Proprietatea 10. Comutarea proieciei cu produsul cartezian: Dac A1,...,Am este o list de atribute ce apar n schemele relaionale R1 i R2 i dac lista este format din atribute aparinnd lui R1 (notate prin B1,...,Bn) i din atribute aparinnd lui R2 (notate prin C1,...,Ck) atunci: A1,...,Am (R1 R2) = B1,...,Bn (R1) C1,...,Ck (R2) Proprietatea 11. Compunerea proieciei cu operaia join: Dac A1,...,Am este o list de atribute ce apar n schemele relaionale R1 i R2 i dac lista este format din atribute aparinnd lui R1 (notate prin B1,...,Bn) i din atribute aparinnd lui R2 (notate prin C1,...,Ck) atunci: A1,...,Am (JOIN(R1,R2,D)) = A1,...,Am (JOIN(D,B1,...,Bn(R1), D,C1,...,Ck(R2),D), unde am notat prin JOIN(R1, R2, D) operaia de compunere natural ntre R1 i R2 dup atributul comun D.

35

Proprietatea 12. Compunerea seleciei cu operaia join: cond (JOIN (R1, R2, D)) = cond (JOIN (D,A (R1), D,A (R2), D)), unde A reprezint atributele care apar n condiia dup care se face selecia.

Reguli de optimizare frecvent folosite:

Regula de optimizare 1. Seleciile se execut ct mai devreme posibil. Motivaia acestei reguli este c seleciile reduc substanial dimensiunea relaiilor. Regula de transformare 4 poate fi folosit pentru a separa dou sau mai multe selecii n selecii individuale care pot fi distribuite join-ului sau produsului cartezian folosind comutarea seleciei cu join-ul. Regula de optimizare 2. Produsurile carteziene se nlocuiesc cu joinuri, ori de cte ori este posibil. Un produs cartezian ntre dou relaii este de obicei mult mai scump (ca i cost) dect un join ntre cele dou relaii, deoarece primul genereaz concatenarea tuplurilor n mod exhaustiv i poate genera un rezultat foarte mare. Aceast transformare se poate realiza folosind legtura dintre produs cartezian, join i selecie. Regula de optimizare 3. Dac sunt mai multe join-uri atunci cel care se execut primul este cel mai restrictiv. Un join este mai restrictiv dect altul dac produce o relaie mai mic. Se poate determina care join este mai restrictiv pe baza factorului de selectivitate sau cu ajutorul informaiilor statistice. Algebric, acest lucru se poate realiza folosind regula de transformare 2. Regula de optimizare 4. Proieciile se execut la nceput pentru a ndeprta atributele nefolositoare. Dac un atribut al unei relaii nu este folosit n operaiile ulterioare atunci trebuie ndeprtat. n felul acesta se va folosi o relaie mai mic n operaiile ulterioare. Aceasta se poate realiza folosind comutarea proieciei cu join-ul. Exemple curs!!!

36

Regulile lui Codd

Caracteristici ale modelului relaional: nu exist tupluri identice; ordinea liniilor i a coloanelor este arbitrar; articolele unui domeniu sunt omogene; fiecare coloan definete un domeniu distinct i nu se poate repeta n cadrul aceleiai relaii; toate valorile unui domeniu corespunztoare tuturor cazurilor nu mai pot fi descompuse n alte valori (sunt atomice). Avantajele modelului relaional: fundamentare matematic riguroas; independen fizic a datelor; posibilitatea filtrrilor; existena unor structuri de date simple; realizarea unei redundane minime; suplee n comunicarea cu utilizatorul neinformatician. Ca limite ale modelului relaional putem meniona: rmne totui redundan, ocup spaiu, apar fenomene de inconsisten, nu exist mecanisme pentru tratarea optim a cererilor recursive, nu lucreaz cu obiecte complexe, nu exist mijloace perfecionate pentru exprimarea constrngerilor de integritate, nu realizeaz gestiunea totala a datelor distribuite, nu realizeaz gestiunea cunotinelor. n anul 1985, E.F. Codd a publicat un set de 13 reguli n raport cu care un sistem de gestiune a bazelor de date poate fi apreciat ca relaional. Nici un sistem de gestiune a bazelor de date pus n vnzare pe piaa comercial nu respect absolut toate regulile definite de Codd, dar acest lucru nu mpiedic etichetarea acestor sisteme drept relaionale.

37

Nu trebuie apreciat un SGBD ca fiind relaional sau nu, ci msura n care acesta este relaional, deci numrul regulilor lui Codd pe care le respect. Regula 1 regula gestionrii datelor. Un SGBD relaional trebuie s fie capabil s gestioneze o baz de date numai prin posibilitile sale relaionale. Regula 2 regula reprezentrii informaiei. ntr-o baz de date relaional, informaia este reprezentat la nivel logic sub forma unor tabele ce poart numele de relaii. Regula 3 regula accesului garantat la date. Fiecare valoare dintr-o baz de date relaional trebuie s poat fi adresat n mod logic printr-o combinaie format din numele relaiei, valoarea cheii primare i numele atributului. Regula 4 regula reprezentrii informaiei necunoscute. Un sistem relaional trebuie s permit utilizatorului definirea unui tip de date numit null pentru reprezentarea unei informaii necunoscute la momentul respectiv. Regula 5 regula dicionarelor de date. Asupra descrierii bazelor de date (informaii relative la relaii, vizualizri, indeci etc.) trebuie s se poat aplica aceleai operaii ca i asupra datelor din baza de date. Regula 6 regula limbajului de interogare. Trebuie s existe cel puin un limbaj pentru prelucrarea bazei de date. Regula 7 regula de actualizare a vizualizrii. Un SGBD trebuie s poat determina dac o vizualizare poate fi actualizat i s stocheze rezultatul interogrii ntr-un dicionar de tipul unui catalog de sistem. Regula 8 regula limbajului de nivel nalt. Regulile de prelucrare asupra unei relaii luat ca ntreg sunt valabile att pentru operaiile de regsire a datelor, ct i asupra operaiilor de inserare, actualizare i tergere a datelor. Regula 9 regula independenei fizice a datelor: Programele de aplicaie i activitile utilizatorilor nu depind de modul de depunere a datelor sau de modul de acces la date. Regula 10 regula independenei logice a datelor. Programele de aplicaie trebuie s fie transparente la modificrile de orice tip efectuate asupra datelor. Regula 11 regula independenei datelor din punct de vedere al integritii. Regulile de integritate trebuie s fie definite ntr-un sublimbaj relaional, nu n programul de aplicaie.

38

Regula 12 regula independenei datelor din punct de vedere al distribuirii. Distribuirea datelor pe mai multe calculatoare dintr-o reea de comunicaii de date, nu trebuie s afecteze programele de aplicaie. Regula 13 regula versiunii procedurale a unui SGBD. Orice component procedural a unui SGBD trebuie s respecte aceleai restricii de integritate ca i componenta relaional. Deoarece regulile lui Codd sunt prea severe pentru a fi respectate de un SGBD operaional, s-au formulat criterii minimale de definire a unui sistem de gestiune relaional. Un SGBD este minimal relaional dac: toate datele din cadrul bazei sunt reprezentate prin valori n tabele; nu exist pointeri observabili de ctre utilizator; sistemul suport operatorii relaionali de proiecie, selecie i compunere natural, fr limitri impuse din considerente interne. Un SGBD este complet relaional dac este minimal relaional i satisface n plus condiiile: sistemul suport restriciile de integritate de baz (unicitatea cheii primare, constrngerile refereniale, integritatea entitii). sistemul suport toate operaiile de baz ale algebrei relaionale.

NORMALIZAREA RELAIILOR
n procesul modelrii unei baze de date relaionale, o etap important o reprezint normalizarea relaiilor conceptuale (Codd, 1972), adic obinerea de relaii molecularefr a pierde nimic din informaie pentru a elimina: redundana; anomaliile reactualizrii informaiilor. Tehnica normalizrii permite obinerea unei scheme conceptuale rafinate printr-un proces de ameliorare progresiv a unei scheme conceptuale iniiale a bazei de date relaionale. Dup fiecare etap de ameliorare, relaiile bazei de date ating un anumit grad de perfeciune, deci se afl ntr-o anumit form normal. Trecerea unei relaii dintr-o form normal n alta, presupune eliminarea unei anumit tip de dependene nedorite, care sunt transformate n dependene admisibile, adic dependene care nu provoac anomalii.

39

Procesul de ameliorare a schemei conceptuale trebuie: s garanteze conservarea datelor, adic n schema conceptual final trebuie s figureze toate datele din cadrul schemei iniiale; s garanteze conservarea dependenelor dintre date, adic n schema final fiecare dependen trebuie s aib determinantul i determinatul n schema aceleiai relaii; s reprezinte o descompunere minimal a relaiilor iniiale, adic nici una din relaiile care compun schema final nu trebuie s fie coninut ntr-o alt relaie din aceast schem.

Exist dou metode pentru a modela baze de date relaionale fr anomalii sau pierderi de informaie. Schema descompunerii pleac de la o schem relaional universal ce conine toate atributele BD. Schema se descompune prin proiecii succesive n subrelaii. Descompunerea se oprete cnd continuarea ei ar duce la pierderi de informaie. Algoritmii de descompunere se bazeaz, n general, pe descrierea formal a dependenei dintre atribute. Schema sintezei pleac de la o mulime de atribute independente. Utiliznd proprieti de semantic i legturi ntre atribute se pot compune noi relaii, astfel nct, acestea s nu sufere de anumite anomalii. Algoritmii se bazeaz, n general, pe teoria grafurilor pentru a reprezenta legtura ntre atribute.

Dependene funcionale
O relaie universal este o relaie ce grupeaz toate atributele care modeleaz sistemul real cercetat. Fie E, mulimea dependenelor considerate de proiectantul bazei pentru o schem relaional sau pentru o relaie universal. Plecnd de la o mulime de proprieti formale ale dependenelor, proprieti considerate drept reguli de deducie (axiome), poate fi obinut mulimea maximal de dependene asociate lui E. Aceast mulime definete nchiderea lui E. Fie E mulimea dependenelor unei relaii i p1, p2, ..., pr, r 1, proprieti formale ale acestor dependene. Dac exist o mulime E, astfel nct orice dependen a mulimii E este derivabil din E prin aplicarea proprietilor p1, p2, ..., pr, atunci mulimea E definete acoperirea lui E pentru proprietile p1, p2, ..., pr. E este o acoperire minimal pentru E, dac nu exist nici o submulime proprie, nevid a lui E care s fie o acoperire pentru E.

40

Evident, E i E au nchideri identice, deci dispun de acelai potenial informaional! Fie R(A1, A2, ..., An) o schem relaional i fie X, Y submulimi de atribute ale lui R. X determin funcional Y sau Y depinde funcional (FD) de X, dac pentru orice relaie r (valoare curent a lui R) nu exist dou tupluri care s aib aceleai valori pentru atributele lui X i s aib valori diferite pentru cel puin un atribut din Y. Cu alte cuvinte, o valoare a lui X, determin unic o valoare a lui Y. Notaia utilizat pentru desemnarea dependenei funcionale este X Y. X este numit determinant, iar Y este numit determinat (sau dependent). Dependena funcional X Y este trivial dac Y X. Comparnd toate submulimile de atribute ale unei relaii i determinnd legturile dintre ele, se pot obine toate dependenele funcionale pe care o relaie le satisface. Aceast abordare nu este eficient, consumnd mult timp. Exist posibilitatea ca, tiind anumite dependene funcionale i utiliznd reguli de deducie, s fie obinute toate dependenele funcionale. Fie X, Y, Z, W mulimi de atribute ale unei scheme relaionale R i fie urmtoarele axiome: Ax1 reflexivitate. X X. Mai general, dac Y X, atunci X Y. Ax2 creterea determinantului. Pot fi considerate urmtoarele formulri echivalente pentru aceast axiom.
1. 2. 3. 4.

Dac X Y i X Z, atunci Z Y. Dac X Y i W Z, atunci X Z Y W. Dac X Y atunci X Z Y Z. Dac X Y atunci X Z Y.

Ax3 tranzitivitate. Dac X Y i Y Z, atunci X Z. O mulime de axiome este complet dac i numai dac plecnd de la o mulime de dependene E se pot obine toate dependenele nchiderii lui E, utiliznd axiomele mulimii. O mulime de axiome este nchis dac i numai dac plecnd de la o mulime de dependene E, nu poate fi dedus cu ajutorul axiomelor o dependen care nu aparine nchiderii lui E. (nu obin altele!) Ullman a demonstrat c axiomele Ax1 Ax3, numite axiomele lui Amstrong, reprezint o mulime nchis i complet de axiome. Consecina

41

acestui rezultat este c nchiderea lui E reprezint mulimea dependenelor deduse din E, prin aplicarea axiomelor lui Amstrong!!! Nu toate dependenele funcionale sunt folositoare pentru modelarea relaional. O dependen funcional X Y se numete dependen funcional total (FT), dac i numai dac nu exist nici o submulime proprie X X, astfel nct X Y. Dac exist o submulime proprie X X, astfel nct X Y, atunci dependena funcional X Y este parial. n axioma Ax2, dependena Z Y este o dependen funcional parial. n cazul dependenei funcionale totale, axiomele lui Amstrong se reduc la o axiom unic i anume pseudo-tranzitivitatea: dac X Y i W Y Z, atunci W X Z. Aceast axiom este o regul de deducie complet pentru total dependene: pseudo-tranzitivitatea implic tranzitivitatea (W = ); reflexivitatea nu poate fi utilizat pentru a obine dependene totale; reflexivitatea i pseudo-tranzitivitatea implic creterea.

Dac F este o mulime de dependene funcionale totale, atunci nchiderea pseudo-tranzitiv F+ a acestei mulimi este reuniunea mulimilor dependenelor funcionale totale care pot fi obinute din F folosind axioma de pseudo-tranzitivitate. Dou mulimi de dependene funcionale totale sunt echivalente dac au nchideri pseudo-tranzitive identice. Pentru a modela scheme relaionale se consider mulimi minimale de dependene funcionale totale, capabile s genereze toate nchiderile pseudo-tranzitive. Aceste mulimi definesc acoperiri minimale. O mulime de dependene funcionale totale F* asociat unei mulimi de atribute A definete o acoperire minimal dac satisface urmtoarele proprieti: nici o dependen funcional din F* nu este redundant; toate dependenele funcionale totale ntre submulimi ale lui A sunt n nchiderea pseudo-tranzitiv a lui F*. Orice mulime de dependene totale are cel puin o acoperire minimal. Alegerea acoperirii minimale este punctul de start n modelarea schemelor relaionale.

42

Dependenele funcionale ntre atributele bazei pot fi reprezentate grafic. Fie A = {A1, A2, ..., An} o mulime de atribute i fie o mulime de dependene funcionale {Xi Aj}, unde Xi este o submulime a lui A. Graful dependenelor funcionale este un graf direcionat bipartit, definit astfel: 1. pentru fiecare atribut Aj exist un singur nod avnd eticheta Aj;
2. 3.

pentru fiecare dependen funcional de forma Ai Aj, exist un arc de la Ai la Aj; pentru fiecare dependen funcional de forma Xi Aj, unde mulimea Xi este definit de Xi = {Ai1, ..., Aip} cu p > 1, exist un nod auxiliar etichetat prin Xi i o mulime de arce plecnd de la Ai1, ..., Aip pentru a obine pe Xi i printr-un arc adiional de la Xi la Aj. Nodurile Xi se reprezint prin dreptunghiuri.

Exemplu: 1. Graful dependenelor funcionale pentru schema relaional CONSUMATOR_DE_VIN(W#, localitate, varsta, calitate, regiune, tara, D#, nume, data, cantitate) i acoperirea minimal.
localitate W# calitate varsta regiune tara data D# nume localitate W# calitate varsta cantitate

43

regiune tara data D# nume cantitate

2. Graful dependenelor funcionale pentru schema relaional OBIECTIV_INVESTITIE. Dependentele sunt deduse din regulile impuse de beneficiar!
aria_construita denumire nr_certificat_urbanizare cod_obiectiv# adresa nr_contract nr_aut_construtie cod_contractant

Necesitatea normalizrii
Anomaliile care apar n lucrul cu baza de date se produc datorit dependenelor care exist ntre datele din cadrul relaiilor bazei de date. Dependenele sunt plasate greit n tabele!!! Avion A# 1 2 3 4 5 6 nume AIRBUS AIRBUS AIRBUS CAR B707 B707 capacitate 250 250 250 100 150 150 localitate PARIS PARIS LONDRA PARIS LONDRA LONDRA

Constrngere: toate avioanele cu acelai nume au aceeai capacitate. Datorit dependenei introduse pot exista: anomalii la inserare, modificare sau tergere, redundan n date, probleme de reconexiune.

44

1. 2.

Redundan logic. Cuplul (AIRBUS, 250) apare de trei ori. Anomalie la inserie. S-a cumprat un B727 cu 150 locuri. El poate fi inserat n relaia AVION doar dac se definete o nou valoare pentru cheia primar. Anomalie la tergere. Dac este tears nregistrarea pentru care A# este 4, atunci se pierde informaia c un avion CAR are capacitatea 100. Anomalie la modificare. Dac se modific capacitatea lui B707 de la 150 la 170, atunci costul modificrii este mare pentru a modifica toate nregistrrile, iar dac se modific doar o nregistrare atunci constrngerea nu va mai fi verificat. Problema reconexiunii. Considerm schemele relaionale: AVION1 = PROJECT(AVION, A#, nume) AVION22 = PROJECT(AVION, nume, capacitate, localitate) AVION3 = JOIN(AVION1, AVION2). Se observ c schema AVION3 este diferit de AVION. Apare un tuplu nou: (3, AIRBUS, 250, PARIS).

3.

4.

5.

Anomaliile au aprut datorit dependenei funcionale (constrngerii) introduse anterior!!! Normalizarea are drept scop: suprimarea redundanei logice, evitarea anomaliilor la reactualizare, rezolvarea problemei reconexiunii.

Exist o teorie matematic a normalizrii al crei autor este E.F. Codd. Soluia: construirea unor tabele standard (forme normale). Normalizarea este procesul reversibil de transformare a unei relaii, n relaii de structur mai simpl. Procesul este reversibil n sensul c nici o informaie nu este pierdut n timpul transformrii. O relaie este ntr-o form normal particular dac ea satisface o mulime specificat de constrngeri. Procesul normalizrii se realizeaz plecnd de la o relaie universal ce conine toate atributele sistemului de modelat, plus o mulime de anomalii. Orice form normal se obine aplicnd o schem de descompunere. Exist dou tipuri de descompuneri. Descompuneri ce conserv dependenele. Aceast descompunere presupune desfacerea relaiei R n proieciile R1, R2, ..., Rk, astfel nct dependenele lui R sunt echivalente (au

45

nchideri pseudo-tranzitive identice) cu reuniunea dependenelor lui R1, R2, ..., Rk. Descompuneri fr pierderi de informaie (L-join). Aceast descompunere presupune desfacerea relaiei R ntr-o mulime de proiecii R1, R2, ..., Rj, astfel nct pentru orice realizare a lui R este adevrat relaia: R = JOIN(B1 (R), B2 (R), ...,Bj (R)) unde, pentru 1 k j, Bk reprezint mulimea atributelor corespunztoare proieciei Rk (Rk = Bk (R)). Prin urmare, relaia iniial poate fi reconstruit considernd compunerea natural a relaiilor obinute prin descompunere. Formele normale sunt obinute prin descompuneri fr pierderi de informaie. O descompunere fr pierdere de informaie, utilizat n procesul normalizrii, este dat de regula Casey-Delobel: Fie R(A) o schem relaional i fie , , o partiie a lui A. Presupunem c determin funcional pe . Atunci: R(A) = JOIN((R), (R)). mulimea atributelor care intervin n dependenele funcionale; reprezint reuniunea determinantului cu restul atributelor lui A.
Relatia universala FN1 FN2 FN3 BCNF FN4 FN5

Pentru exemplul analizat anterior: = {nume}, = {capacitate}, = {A#, localitate}. Aplicnd Casey-Delobel se obin schemele: AVION1(nume#, capacitate) AVION2)A#, nume, localitate).

46

Se observ c anomaliile comentate au disprut! AVION1 Nume AIRBUS CAR B707 Capacitate 150 100 150

AVION2 A# Nume 1 AIRBUS 2 AIRBUS 3 AIRBUS 4 CAR 5 B707 6 B707

Localitate PARIS PARIS LONDRA PARIS LONDRA LONDRA

Forma normal (FN1)

O relaie este n prima form normal dac fiecrui atribut care o compune i corespunde o valoare indivizibil (atomic). Exemplu: variante pentru a implementa FN1 pentru tabelul MASINA:
Persoana Eu Tu El noi Varianta 1 Persoana Eu Eu Eu Tu El El Noi Noi Noi Noi Vehicul R25 W14 R21 205 R5 305 BX 305 R12 R25 Vehicul R25 - W14 - R21 205 R5 - 305 BX - 305 - R12 - R25

47

Varianta 2 Persoana Eu Tu El Noi Prima R25 205 R5 BX 305 305 R12 R25 Doi W14 Trei R21 Patru

Varianta 3 (4 tabele) Masina 31 (similar se definesc Masina_32, Masina_33, Masina_34).. Persoana Eu Tu El Noi Masina_34 Persoana Noi Vehicul R25 Vehicul R25 205 R5 BX

Forma normal 2 (FN2)

O relaie R este n a doua form normal dac i numai dac: relaia R este n FN1; fiecare atribut care nu este cheie (nu particip la cheia primar) este dependent de ntreaga cheie primar.
Job_cod Programator Programator Programator Vanzator Inginer Nr_proiect# P1 P2 P3 P3 P3 Functia Supervizor Cercetator Auxiliar Supervizor Supervizor Suma 60 25 10 60 60

atasat_la Cod_salariat# S1 S1 S1 S3 S5 atasat_2a Cod_salariat# S1 S1 S1 S3 Nr_proiect# P1 P2 P3 P3 Functia Supervizor Cercetator Auxiliar Supervizor Suma 60 25 10 60

48

S5 atasat_2b Cod_salariat# S1 S3 S5

P3

Supervizor

60

Job_cod Programator Vanzator Inginer

A doua condiie exprim necesitatea total dependenei de cheia primar. Aceast form normal interzice manifestarea unor dependene funcionale pariale n cadrul relaiei R!!! Pentru a obine o relaie FN2 se poate aplica regula Casey-Delobel. Fie relaia R(K1, K2, X, Y), unde K1 i K2 definesc cheia primar, iar X i Y sunt mulimi de atribute, astfel nct K1 X. Din cauza dependenei funcionale K1 X care arat c R nu este n FN2, se nlocuiete R (fr pierdere de informaie) prin dou proiecii R1(K1, K2, Y) i R2(K1, X).
K1 K2

Exemplu. Presupunem c un antier poate executa mai multe lucrri de baz i c o lucrare poate fi executat de mai multe antiere. LUCRARE(cod_obiectiv#, cod_lucrare#, nume); SANTIER(nr_santier#, specialitate, sef); EXECUTA(cod_obiectiv#, cod_lucrare#, nr_santier#, descriere, functie, conducator, data_inceput, data_sfarsit). Pentru relaia EXECUTA sunt evidente dependenele: {cod_obiectiv#, cod_lucrare#} {data_inceput, data_sfarsit}, {cod_obiectiv#, cod_lucrare#, nr_santier#} {descriere, functie, conducator}.

49

Relaia EXECUTA este n FN1, dar nu este n FN2 deoarece atributele data_inceput i data_sfarsit nu depind de numrul antierului, deci nu depind de ntreaga cheie primar. Pentru a obine o relaie n FN2 se aplic regula Casey Delobel i relaia EXECUTA se desface n: EXECUTA_1(cod_obiectiv#, cod_lucrare#, nr_santier#, descriere, functie, conducator) EXECUTA_2(cod_obiectiv#, cod_lucrare#, data_inceput, data_sfarsit).

Forma normal 3 (FN3)

relaia R este n FN2;

Intuitiv, o relaie R este n a treia form normal dac i numai dac: fiecare atribut care nu este cheie (nu particip la o cheie) depinde direct de cheia primar.

Fie R o relaie, X o submulime de atribute ale lui R i A un atribut al relaiei R. A este dependent tranzitiv de X dac exist Y astfel nct X Y i Y A (A nu aparine lui Y i Y nu determin pe X). X nu este dependent funcional de Y sau A! De exemplu, dac K1, K2, K3 A1 i dac K1, K2, A1 A2, atunci K1, K2, K3 K1, K2, A1 i K1, K2, A1 A2. Prin urmare, A2 este dependent tranzitiv de K1, K2, K3. Formal, o relaie R este n a treia form normal dac i numai dac: relaia R este n FN2; fiecare atribut care nu este cheie (nu particip la o cheie) nu este dependent tranzitiv de nici o cheie a lui R.

O relaie este n FN3 dac i numai dac fiecare atribut (coloan) care nu este cheie, depinde de cheie, de ntreaga cheie i numai de cheie. Pentru a obine o relaie FN3 se poate aplica regula Casey-Delobel. Fie relaia R(K, X1, X2, X3), unde atributul X2 depinde tranzitiv de K, iar K este cheia primar a lui R. Presupunem c K X1 X2. Din cauza dependenei funcionale X1 X2 care arat c R nu este n FN3, se nlocuiete R (fr pierdere de informaie) prin dou proiecii R1(K, X1, X3) i R2(X1, X2). K X1 X3 X2

50

Exemplu: Tabelul atasat_2a nu este in FN3. De ce?

atasat_3a Cod_salariat# S1 S1 S1 S3 S5 atasat_3b Functia Supervizor Cercetator Auxiliar Suma 60 25 10 Nr_proiect# P1 P2 P3 P3 P3 Functia Supervizor Cercetator Auxiliar Supervizor Supervizor

Exemplu. n tabelul EXECUTA1(cod_obiectiv#, cod_lucrare#, nr_santier#, descriere, functie, conducator) continu s existe redundan n date. Atributul conducator depinde indirect de cheia primar prin intermediul atributului functie. ntre atributele relaiei exist dependenele: {cod_obiectiv#, cod_lucrare#, nr_santier#} {descriere}, {cod_obiectiv#, cod_lucrare#, nr_santier#} {functie} {conducator}. Pentru a aduce relaia EXECUTA_1 n FN3 se aplic regula CaseyDelobel. Relaia se desface, prin eliminarea dependenelor funcionale tranzitive, n proieciile: EXECUTA11(cod_obiectiv#, cod_lucrare#, nr_santier#, descriere, functie) EXECUTA12(functie, conducator).

Schema de sintez pentru obinerea lui FN3

Algoritmul de sintez construiete o acoperire minimal F a dependenelor funcionale totale. Se elimin atributele i dependenele funcionale redundante. Mulimea F este partiionat n grupuri Fi, astfel nct n fiecare grup Fi sunt dependene funcionale care au acelai membru stng i nu exist dou grupuri avnd acelai membru stng. Fiecare grup Fi produce o schem FN3. Algoritmul realizeaz o descompunere ce conserv dependenele. Algoritm SNF3 (aducerea unei relaii n FN3 prin utilizarea unei scheme de sintez):

51

1. 2.

3.

4.

5.

6.

Se determin F o acoperire minimal a lui E (mulimea dependenelor funcionale). Se descompune mulimea F n grupuri notate Fi, astfel nct n cadrul fiecrui grup s existe dependene funcionale avnd aceeai parte stng. Se determin perechile de chei echivalente (X, Y) n raport cu F (dou mulimi de atribute X, Y sunt chei echivalente dac n mulimea de dependene E exist att dependena X Y, ct i dependenta Y X). Pentru fiecare pereche de chei echivalente: se identific grupurile Fi i Fj care conin dependenele funcionale cu partea stng X i respectiv Y; se formeaz un nou grup de dependene Fi j, care va conine dependenele funcionale avnd membrul stng (X, Y); se elimin grupurile Fi i Fj, iar locul lor va fi luat de grupul Fi j. Se determin o acoperire minimal a lui F, care va include toate dependenele X Y, unde X i Y sunt chei echivalente (celelalte dependene sunt redundante). Se construiesc relaii FN3 (cte o relaie pentru fiecare grup de dependene funcionale).

Se observ c algoritmul solicit determinarea unei acoperiri minimale (algoritmii EAR i EDF); determinarea nchiderii (A + ) unei mulimi de atribute A n raport cu mulimea de dependene funcionale E (algoritm AIDF). Determinarea acoperirii minimale presupune eliminarea atributelor i dependenelor redundante. Acoperirea minimal nu este unic i depinde de ordinea n care sunt eliminate aceste atribute i dependene redundante. Algoritm EAR (elimin atributele redundante din determinantul dependenelor funcionale) Pentru fiecare dependen funcional din E i pentru fiecare atribut din partea stng a unei dependene funcionale: Pas1. Se elimin atributul considerat. Pas2. Se calculeaz nchiderea prii stngi reduse. Pas3. Dac nchiderea conine toate atributele din determinantul dependenei, atunci atributul eliminat la pasul 1 este redundant i rmne eliminat. n caz contrar, atributul nu este redundant i se reintroduce n partea stng a dependenei funcionale.

52

Algoritm EDF (elimin dependenele funcionale redundante din E) Pentru fiecare dependen funcional X Y din E: Pas1. Se elimin dependena din E. Pas2. Se calculeaz nchiderea X + , n raport cu mulimea redus de dependene. Pas3. Dac Y este inclus n X + , atunci dependena X Y este redundant i rmne eliminat. n caz contrar, se reintroduce n E. Algoritm AIDF (determin nchiderea lui A) Pas1. Se caut dac exist n E dependene X Y pentru care determinantul X este o submulime a lui A, iar determinatul Y nu este inclus n A. Pas2. Pentru fiecare astfel de dependen funcional se adaug mulimii A atributele care constituie determinatul dependenei. Pas3. Dac nu mai exist dependene funcionale de tipul de la pasul 1, atunci A + = A. Exemplu: Fie dependenele funcionale: f1: F N; f2: F P; f3: P, F, N U; f6: C T; f7: N F. F4: P C; f5: P T;

Pas1 (suprimarea atributelor redundante). Atributul A i este redundant n dependena funcional A 1 , A 2 , A i , A n Z, dac dependena funcional A1 , A 2 , A i 1 , A i + 1 A n Z poate fi generat plecnd de la mulimea iniial de dependene (E) i de la axiomele considerate. f1: F N; f3: P, F, N U sau N, P, F U; Aplicnd axioma de pseudotranzitivitate se obine: F, P, F U P, F U Pas2 (suprimarea dependenelor funcionale redundante). Dependena funcional f este redundant n E dac E + = (E - f) + , unde E + reprezint nchiderea lui E. Se observ c f5 este redundant (poate fi obinut din f4 i f6). La sfritul etapei se obine: f1: F N; f2: F P; f3: P, F U; P este redundant =>F-->U

53

f4: P C; f6: C T;

f7: N F.

Pas3 (gruparea dependenelor avnd acelai membru stng). F1 = {f1, f2, f3}; F2 = {f4}; F3 = {f6}; F4 = {f7} Pas4 (regruparea mulimilor F i si F j dac exist dependene de forma X Y i Y X, unde X reprezinta partea stanga a dependenei lui F i i Y este partea stng a dependenei lui F j . Din F1 i F4 se obine: G1 = {f1, f2, f3, f7}; G2 = {f4}; G3 = {f6}. Pas5 (generarea relaiilor FN3). R1(F#, N, P, U); R2(P#, C); R3(C#, T). De remarcat: R1 nu este in BCNF! De ce? Exista dependenta N -->F. Exerciiu: Presupunem c o parte din activitiile de pe un aeroport sunt caracterizate de atributele: A -- numr zbor; B -- tip avion; C -- aeroport plecare; D -- aeroport sosire; E -- linia aerian; F -- ora plecrii; G -- capacitate; H -- numr locuri rezervate; I -- data; J -- tarif; K -- prestaii la bord. ntre aceste atribute exist legturi exprimate prin dependenele: A BEFG ACDI H CD J CDF K BG CF ABE AC D ABD C EG B

54

Aplicnd algoritmul de sintez se obin relaiile: R1(B#, G) R2(E#, G#, B) R3(A#, B, E, F) R4(C#, D#, J) R5(A#, C#, I#, H) R6(A, C, D, F, K) n care cheile primare pot s fie oricare dintre: AD sau AC sau CF. ncercai s justificai acest rezultat!!!

Forma normal Boyce-Codd (BCNF)

Determinantul este un atribut sau o mulime de atribute neredundante, care constituie un identificator unic pentru alt atribut sau alt mulime de atribute ale unei relaii date. Intuitiv, o relaie R este n forma normal Boyce-Codd dac i numai dac fiecare determinant este o cheie candidat. Formal, o relaie R este n forma normal Boyce-Codd dac i numai dac pentru orice dependen funcional total X A, X este o cheie (candidat) a lui R. Regula Casey Delobel pentru R(K1#, K2#, X) presupunnd c exist dependena: X K2. R1(K1#, X) i R2(X#, K2)
K1 K2

Exemplu: ADRESA(cod_parsoana#, telefon#, adresa)

cod_persoana

adresa

55

telefon

n dependena adresa telefon se observ c determinantul nu este o cheie candidat. Relaia ADRESA se desface n: ADRESA_1(cod_persoana#, adresa); ADRESA_2(adresa#, telefon). Relaiile sunt n BCNF, se conserv datele, dar nu se conserv dependenele (s-a pierdut cod_persoana, telefon adresa). Exemplu: Relaia INVESTESTE_IN leag entitile INVESTITOR i OBIECTIV_INVESTITIE. Ea are schema relaional: INVESTESTE_IN(cod_contractant#, cod_obiectiv#, nr_contract, cota_parte). ntre atributele relaiei exist dependenele: {cod_contractant#, cod_obiectiv#} {nr_contract, cota_parte}, {nr_contract} {cod_obiectiv}. Se aplic regula Casey-Delobel i se aduce relaia n BCNF. INVESTESTE_IN_1(cod_obiectiv, nr_contract#); INVESTESTE_IN_2(cod_contractant#, nr_contract, cota_parte). Pentru ca o relaie s fie adus n BCNF nu trebuie n mod obligatoriu s fie n FN3. Se pot aduce n BCNF i relaii aflate n FN1 sau FN2. Acest lucru este posibil ntruct dependenele funcionale pariale i cele tranzitive sunt tot dependene noncheie, adic dependene ai cror determinani nu sunt chei candidat. Presupunem c R este o relaie ce conine atributele A. Algoritm TFBCNF (aducerea unei relaii R din FN1 n BCNF) 1. Dac relaia conine cel mult dou atribute, atunci R este n BCNF i algoritmul s-a terminat. 2. Dac relaia conine mai mult de dou atribute, se consider toate perechile (X, Y) de atribute distincte din A. + 3. Se determin A1 , nchiderea mulimii A1 = A {X, Y}. + 4. Dac pentru orice pereche (X, Y), X A1 atunci relaia R este n BCNF i algoritmul s-a terminat. 5. n caz contrar (pentru cel puin o pereche (X, Y), X aparine lui A1+), relaia R nu este n BCNF.

56

6.

Se reduce progresiv schema relaiei i se reia algoritmul, exploatnd relaia redus. Orice relaie obinut prin reducerea lui R i care este n BCNF se consider ca fcnd parte din descompunerea lui R n procesul aducerii sale n BCNF.

Forma normal 4 (FN4)

FN4 elimin redundanele datorate relaiilor m:n, adic datorate dependenei multiple. Intuitiv, o relaie R este n a patra form normal dac i numai dac relaia este n BCNF i nu conine relaii m:n independente. Fie R o relaie definit pe o mulime de atribute A = {A1, A2, ..., An} i fie X, Y, Z A. Se spune c X multidetermin pe Z sau c Z este multidependent de X : dac pentru fiecare valoare a lui Z n R exist numai o valoare pentru perechea (X, Y); dac valoarea lui Z depinde numai de valoarea lui X. Acest tip de dependen, numit i multivaloare sau multidependen (MVD) se noteaz prin X Z. Intuitiv, multidependena reprezint situaia n care valoarea unui atribut (sau a unei mulimi de atribute) determin o mulime de valori a altui atribut (sau mulimi de atribute)!!! Multidependena X Y poate fi gndit ca o regul de deducie: dac tuplurile <x, y, z> i <x, y, z> sunt n relaie la un moment r, atunci la momentul r sunt n relaie i tuplurile <x, y, z> i <x, y, z>.
x y z

x x x

y' y y'

z' z' z

Orice dependen funcional este o multidependen. Afirmaia invers nu este adevrat. Dac X Y (FD), atunci pentru oricare dou

57

tupluri <x, y, z> i <x, y, z>, se obine y = y. Prin urmare n relaie apar tuplurile <x, y, z> i <x, y, z> i deci X Y (MVD). Fie W, V, X, Y i Z submulimi de atribute ale unei scheme relaionale R. Fiind dat o mulime T de multidependene exist o mulime complet de axiome (Ax1Ax8) care permit obinerea tuturor multidependenelor ce se pot deduce din mulimea T: Ax1. Dac Y X, atunci X Y. Ax2. Dac X Y, atunci X Z Y Z. Ax3. Dac X Y i Y Z, atunci X Z. Ax4. Dac X Y, atunci X R {X Y}. Ax5. Dac X Y i V W, atunci W X V Y. Ax6. Dac X Y i Y Z, atunci X (Z Y). Ax7. Dac X Y, atunci X Y. Ax8. Dac X Y, Z W, W Y i Y Z = , atunci X W. O multidependen elementar este o multidependen care are pri stngi i drepte minimale (nu exist X X i Y Y a.i. X Y). Formal, relaia R este n a patra form normal dac i numai dac: R este n BCNF; orice dependen multivaloare este o dependen funcional. O relaie BCNF este n FN4 dac pentru orice multidependen elementar de forma X Y, X este o supercheie a lui R. Aducerea relaiilor n FN4 presupune eliminarea dependenelor multivaloare atunci cnd sunt mai mult de una n cadrul unei relaii. Regula de descompunere n relaii FN4. Fie R(X, Y, Z) o schem relaional care nu este n FN4 i fie X Y o multidependen elementar care nu este de forma CHEIE atribut. Aceast relaie este descompus prin proiecie n dou relaii: R = JOIN(XY(R), XZ(R)). Aplicnd recursiv aceast regul, se obin relaii FN4. Exemplu. Fie relaia INVESTITIE(cod_contractant#, denumire, telefon) i presupunem c un investitor poate avea mai multe numere de telefon i c poate investi n mai multe obiective. ntre atributele relaiei exist multidependenele: cod_contractant# denumire; cod_contractant# telefon.

58

Relaia INVESTITIE este n BCNF. Pentru a aduce relaia n FN4 o vom descompune prin proiecie n dou relaii: INVESTITIE_1(cod_contractant#, denumire), INVESTITIE_2(cod_contractant#, telefon). INVESTITIE = JOIN(INVESTITIE_1, INVESTITIE_2).

Forma normal 5 (FN5)

FN5 i propune eliminarea redundanelor care apar n relaii m:n dependente. n general, aceste relaii nu pot fi descompuse. S-a artat c o relaie de tip 3 este diferit de trei relaii de tip 2. Exist totui o excepie, i anume, dac relaia este ciclic Intuitiv, o relaie R este n forma normal 5 dac i numai dac: 1. relaia este n FN4; 2. nu conine dependene ciclice. Dependena funcional i multidependena permit descompunerea prin proiecie, fr pierdere de informaie, a unei relaii n dou relaii. Regulile de descompunere (FN1 FN4) nu dau toate descompunerile posibile prin proiecie ale unei relaii. Exist relaii care nu pot fi descompuse n dou relaii dar pot fi descompuse n trei, patru sau mai multe relaii fr a pierde informaii. Pentru a obine descompuneri L-join n trei sau mai multe relaii, s-a introdus conceptul de join-dependen sau dependen la compunere (JD). Fie {R1, R2, ..., Rp} o mulime de scheme relaionale care nu sunt disjuncte i a cror reuniune este R. R satisface join-dependena *{R1, R2, ..., Rp} dac la fiecare moment al lui R are loc egalitatea: R = JOIN(1(R), 2(R), ..., p(R)) unde k reprezint mulimea atributelor corespunztoare lui Rk(1 k p). Join-dependena *{R1, R2, ..., Rp} are loc n R, dac R1, R2, ..., Rp este o descompunere L-join a lui R. Pentru p = 2 se regsete multidependena. O join-dependen *{R1, R2, ..., Rp} n care una dintre Ri este chiar R, definete o join-dependen trivial. Join-dependena generalizeaz multidependena. ntr-adevr, multidependena X Y n relaia R(X, Y, Z) (deci i X Z), corespunde join-dependenei *{X Y, X Z}. Invers, join-dependena *{R1, R2} corespunde multidependenei R1 R2 R1 (R1 R2).

59

Formal, o relaie R este n FN5 dac i numai dac orice joindependen *{R1, R2, ..., Rp} care are loc n R fie este trivial, fie conine o supercheie a lui R (adic, o anumit component Ri este o supercheie a lui R). Cu alte cuvinte, o relaie R este n FN5 dac orice join-dependen definit pe R este implicat de cheile candidat ale lui R. ntre mulimile de atribute X, Y i Z din cadrul relaiei R exist o joindependen dac exist multidependene ntre fiecare dintre perechile de mulimi (X, Y), (Y, Z) i (X, Z). Aducerea n FN5 prin eliminarea join dependenelor! Exemplu. Fie schema R(furnizor, cod_consumabil, cantitate, pret). Reguli: un furnizor produce mai multe consumabile; nu toi furnizorii produc aceleai consumabile; preul unui consumabil de la un furnizor este variabil i nu depinde de cantitate.
Cod_consumabil 1 1 1 2 Cantitate 500 100 500 500 Pret 100 80 100 100

Furnizor F1 F2 F2 F2

Relaia este n FN4, dar exist redundan n date. Relaia se descompune prin proiecie n: R1(furnizor#, cod_consumabil#) R2(furnizor#, cantitate, pret) R3(cod_consumabil#, cantitate, pret). S-au eliminat redundanele: (F2,1) pentru R1; (F2, 500, 100) pentru R2; (1, 500, 100) pentru R3. Se observ c: JOIN(R1, R2) R; JOIN(R1, R3) R; JOIN(R3, R2) R; JOIN(R1, R2, R3) = JOIN(R1, JOIN(R2, R3)) = R

60

Exist join dependena: *{R1(furnizor, cod_consumabil), R3(cod_consumabil, cantitate, pret)} R2(furnizor, cantitate, pret),

Exemplu. Fie schema relaional: EXECUTANT(nr_santier#, cod_obiectiv#, cod_lucrare#, data_inceput, data_sfarsit). Un antier poate executa mai multe lucrri referitoare la acelai obiectiv sau poate executa o lucrare pentru un obiectiv n intervale de timp distincte. Se presupune c mai multe antiere pot executa aceeai lucrare, n acelai interval de timp sau n intervale de timp distincte. Relaia, datorit dependenelor formulate anterior, nu este n FN5. Ea se poate desface prin proiecie n trei relaii: EX1(nr_santier#, cod_obiectiv#, cod_lucrare#); EX2(nr_santier#, data_inceput, data_sfarsit); EX3(cod_obiectiv#, cod_lucrare#, data_inceput, data_sfarsit). Sunt evidente relaiile: EXECUTANT JOIN(EX1, EX2), EXECUTANT JOIN(EX1, EX3), EXECUTANT JOIN(EX2, EX3), EXECUTANT = JOIN(JOIN(EX1, EX2), EX3).

Concluzii:
1.

FN1 FN2 elimin redundanele datorate dependenei netotale a atributelor care nu particip la o cheie, fa de cheile lui R. Se suprim dependenele funcionale care nu sunt totale. FN2 FN3 elimin redundanele datorate dependenei tranzitive. Se suprim dependenele funcionale tranzitive. FN3 BCNF elimin redundanele datorate dependenei funcionale. Se suprim dependenele n care partea stng nu este o supercheie. BCNF FN4 elimin redundanele datorate multidependenei. Se suprim toate multidependenele care nu sunt i dependene funcionale.

2.

3.

4.

61

5.

FN4 FN5 elimin redundanele datorate dependentei. ciclice. Se suprim toate join-dependenele care nu sunt implicate de o cheie. BCNF, FN4 i FN5 corespund la regula c orice determinant este o cheie, dar de fiecare dat dependena cu care se definete determinantul este alta i anume dependena funcional, multidependena sau join-dependena). Descompunerea unei relaii FN2 n FN3 conserv datele i dependenele, pe cnd descompunerea unei relaii FN3 n BCNF i, respectiv, a unei relaii BCNF n FN4 conserv doar datele.

6.

7.

Cateva observaii i concluzii PROIECTAREA BAZELOR DE DATE

referitoare

la

reprezentrii conceptuale a bazei de date, care include identificarea tipurilor importante de entiti, relaii, atribute. 1) identificarea tipurilor de entiti (E); 2) identificarea tipurilor de relaii (R); 3) identificarea i asocierea atributelor (A) cu tipurile de E sau R; 4) determinarea domeniilor atributelor; 5) determinarea atributelor chei candidat i chei primare; 6) specializarea i generalizarea tipurilor de entiti; 7) desenarea diagramei E/R;

Proiectarea conceptual a bazei de date -- construirea

8) revizuirea modelului de date conceptual local, mpreun cu utilizatorul, pentru a garanta c modelul este o reprezentare corect a punctului de vedere al utilizatorului asupra sistemului real analizat.

conceptuale n structura logic a BD, care include proiectarea relaiilor.

Proiectarea logic a bazei de date -- transpunerea reprezentrii

1) transpunerea modelului conceptual local n modelul de date logic local:

62

eliminarea relaiilor M:N (nlocuirea prin relaii de tip 1:M sau prin tabele asociative); eliminarea relaiilor complexe (nlocuirea prin relaii de tip 1:M); eliminarea relaiilor recursive (nlocuirea prin relaii dependente); eliminarea atributelor multiple (nlocuirea prin relaii dependente; reexaminarea relaiilor 1:1 (sunt ntr-adevr 2 relaii distincte?); eliminarea relaiilor redundante.

2) extragerea relaiilor din modelul de date logic local pentru a reprezenta entitile i relaiile (legturile); 3) normalizarea relaiilor; 4) validarea modelului conform tranzaciilor utilizatorului pentru a garanta c acesta accept i rezolv operaiile cerute de ctre model (se verific faptul c modelul furnizeaz toate informaiile cerute de fiecare tranzacie i se reprezint schematic calea urmat de fiecare tranzacie, direct n diagrama E/R); 5) desenarea diagramei conceptuale; 6) definirea constrngerilor de integritate; 7) revizuirea modelului de date conceptual local, mpreun cu utilizatorii; 8) construirea i validarea modelului de date logic global prin combinarea modelelor locale: mbinarea modelelor locale (revizuirea E, R, A, CP, CE, constrngeri, revizuirea denumirilor, cutarea entitilor i relaiilor care lipsesc, reactualizarea documentaiei); normalizarea modelului; validarea modelului conform tranzaciilor utilizatorului; verificarea n vederea dezvoltrii ulterioare; desenarea diagramei conceptuale finale; revizuirea modelului de date conceptual global, mpreun cu utilizatorii. Modaliti pentru asigurarea integritii refeniale!!! Se specific constrngeri de existen care definesc condiiile n care o cheie candidat sau o cheie extern poate fi inserat, tears sau reactualizat.

63

Exemplu: DOMENIU_contine_CARTE (1:M) 1) Inserare n relaia "copil" (carte) - se verific dac domeniul crii inserate este null sau corespunde unui domeniu existent. 2) tergerea n relaia "copil" (fr probleme). 3) Reactualizarea n relaia "copil" (similar cazului 1). 4) Inserarea n relaia "printe" (domeniu) se face fr probleme. 5) Reactualizarea cheii primare n relaia "printe" (dac exist o apariie n tabelul "copil" care face referin la vechea valoare a cheii, atunci se pierde integritatea refenial). Se pot aplica strategii pentru a asigura integritatea refenial (vezi 6). 6) tergerea unei apariii din relaia "printe" (se pierde integritatea referenial dac se terge un domeniu de carte, dar exist cel puin o carte din domeniul respectiv). Exist 5 strategii care pot fi luate n considerare. NO ACTION (nici o aciune)- nu se poate terge un domeniu dac exist o carte n domeniul respectiv; CASCADE - se terge domeniul i automat se terg toate crile din domeniu .a.m.d.; SET NULL - se terge domeniul, iar toate criile din domeniul respectiv vor avea codul domeniului setat null; SET DEFAULT - setare la o valoare prestabilit; NO CHECK - cnd este ters un domeniu de carte, nu se face nimic pentru a garanta c integritatea refenial este meninut (nici o verificare). Proiectarea fizic a bazei de date -- implementarea fizic a structurii logice ntr-o capacitate de stocare secundar corespunztoare SGBD-ului int. Se descriu structurile de stocare i metodele de acces utilizate pentru realizarea unui acces eficient la date. 1) Transformarea relaiilor extrase din modelul de date logic global ntr-o form care s poat fi implementat n SGBD-ul relaional int (LDD). 2) Proiectarea (definirea) constrngerilor sistemului real modelat n SGBD-ul int (CONSTRAINT, declanatori). 3) Proiectarea reprezentrii fizice - determinarea organizrii fiierelor i a metodelor de acces (indeci) care vor fi utilizate pentru a stoca relaiile de baz (modul n care relaiile i tuplurile vor fi pstrate n cadrul capacitii de stocare secundare).

64

4) Introducerea unei redundane controlate (denormalizarea). 5) Estimarea necesarului de spaiu pe disc cerut de baza de date. 6) Proiectarea mecanismelor de securitate: proiectarea vizualizrilor (VIEW); proiectarea regulilor de acces la relaiile de baz i la vizualizri (privilegii, role-uri). 7) Monitorizarea nentrerupt i reglarea sistemului operaional pentru obinerea unor performane maxime (micorarea configuraiei hardware, timpi de rspuns mai sczui, transfer eficient etc.). Comentm pasul 4 referitor la considerarea introducerii unei redundane controlate (denormalizare). NU exist reguli fixe!!! Pasul 4 presupune: considerarea datelor derivate (calculate); considerarea dublrii atributelor i gruprii relaiilor. Considerarea datelor derivate De exemplu, n relaia PROPRIETATE_DE INCHIRIAT apare drept cmp, codul persoanei care a tranzacionat nchirierea. Prin urmare, s-ar putea calcula pentru fiecare angajat, cte proprieti a nchiriat SAU se poate introduce n tabelul PERSONAL, un cmp calculat (derivat) ce conine numrul proprietilor nchiriate de acesta. Considerarea dublrii atributelor i gruprii relaiilor Dublarea atributelor sau gruparea relaiilor are ca scop reducerea numrului de join-uri necesare pentru efectuarea unei interogri. FILIALA (nr_fil#, strada, zona, oras, codpostal, tel, fax) Relaia nu este n FN3 deoarece codpostal determin funcional atributele zona i oras. Aplic FN3 i se obine: FIL(nr_fil#, strada, codpostal, tel, fax COD_P(zona, oras, codpostal#) Nu este convenabil, deoarece rareori vom accesa adresa filialei, fr informaii referitoare la zona i ora. Prin urmare, preferm FN2. Vom analiza cteva situaii concrete de denormalizare. combinarea relaiilor de tip 1:1 dublarea atributelor care nu sunt chei n relaii 1:M

65

SELECT FROM WHERE

p.*, ptr.nume proprietate_de_inchiriat p, proprietar ptr p.nrptr=ptr.nrptr AND nrfil='S3';

Atributul nrptr este codul proprietarului. Dac se va dubla atributul nume din relaia proprietate_de_inchiriat, atunci interogarea devine: SELECT FROM WHERE p.* proprietate_de_inchiriat p nrfil='S3';

Avantaje sau dejavantaje ?!? Depinde de problemele care pot aprea. tabele de referin (tabele de cutare) Acestea conin, de obicei, un cod i o descriere. De exemplu se poate defini un tabel cutare "printe" pentru tipul de proprietate i modifica tabelul proprietate_de_inchiriat ("copil") astfel: TIP_PROPRIETATE(tip, descriere) PROPRIETATE_DE_INCHIRIAT(nrpte, strada, zona, oras, coppostal, tipul, nrcamere, chirie, nrptr, nrfiliala, nrpersonal) Avantaje: dac este modificat descrierea, atunci se va modifica o singur dat, n tabelul de cutare; se reduce dimensiunea relaiei "copil"; dublarea atributelor cheii externe ntr-o relaie de tip 1:M pentru simplificarea join-urilor S se enumere proprietarii de proprieti de nchiriat dintr-o filial. SELECT FROM WHERE ptr.nume proprietate_de_inchiriat p, proprietar ptr p.nrptr=ptr.nrptr AND p.nrfil='S3';

Dac se dubleaz cheia extern nrfiliala n relaia PROPRIETAR, adic se introduce o relaie direct ntre FILIALA i PERSONAL, atunci cererea devine: SELECT FROM WHERE p.nume proprietar p nrfil='S3';

ATENIE! Sunt necesare constrngeri suplimentare asupra cheilor externe. De exemplu, dac un proprietar ar nchiria prin mai multe filiale (atribut multiplu), atunci modificrile nu mai sunt valabile. De remarcat c singurul motiv pentru care relaia proprietate_de_inchiriat conine atributul nrfiliala const n faptul c este

66

posibil ca o proprietate s nu aib alocat un membru de personal, mai ales la nceput, cnd este preluat iniial de ctre agenie. Dublarea atributelor n relaiile de tip M:N, pentru reducerea join-urilor. Presupunem c relaia M:N dintre chirias i proprietate_de_inchiriat a fost descompus prin introducerea relaiei intermediare VIZITARE. Care sunt chiriaii care au vizitat proprieti, dar mai au de fcut comentarii asupra uneia dintre ele? Personalul de la agenie are nevoie de atributul strada atunci cnd vorbete cu chiriaii. SELECT
FROM

p.strada, c.*, v.data

chirias c, vizitare v, proprietate_de_inchiriat p

WHERE v.nrpte = p.nrpte AND c.nrch = v.nrch AND comentarii IS NULL; Atributul nrpte este codul proprietii, iar nrch este codul chiriaului. Dac se introduce atributul strada n relaia VIZITARE, atunci cererea devine: SELECT FROM WHERE v.strada, c.*, v.data chirias c, vizitare v c.nrch = v.nrch AND comentarii IS NULL;

Comentm pasul 3! Proiectarea reprezentrii fizice Scopul este de a stoca datele n mod eficient. Pentru msurarea eficienei poate fi analizat: capacitatea de stocare pe disc; timpul de rspuns; transferul de tranzacii (numrul de tranzacii care pot fi efectuate ntr-un anumit interval de timp). Pentru mbuntirea performanelor trebuie ca proiectantul s cunoasc cum interacioneaz cele 4 componente hardware (memoria principal, CPU, discul I/O, reeaua) i modul cum acestea afecteaz performanele sistemului. Principiile de baz ale distribuirii datelor pe unitile de disc: fiierele sistemului de operare s fie separate de cele ale BD; fiierele principale ale BD s fie separate de fiierele de indexare; fiierul jurnalului de recuperare s fie separat de restul BD. n aceast etap se face i analizarea tranzaciilor, adic cunoaterea funcionalitii acestora i analizarea celor mai importante dintre acestea.

67

Pentru fiecare tranzacie trebuie detrminat: frecvena estimat cu care va fi rulat; relaiile i atributele accesate; tipul de acces (inserare, interogare, tergere sau rectualizare); atributele care apar n predicate (condiii); atributele care apar n join-uri; constrngerile de timp impuse tranzaciilor.

Limbaje pentru prelucrarea datelor relaionale

Unul dintre cele mai mari merite ale modelului relaional este c prin intermediul multiplelor sale limbaje de interogare (neprocedurale) permite utilizatorului, chiar i neinformatician, s indice rezultatul care l intereseaz, fr a preciza modul n care este obinut acest rezultat. O relaie poate fi definit ca o mulime, sau ca un predicat. Conform dualitii definiiei unei relaii, limbajele de prelucrare a datelor relaionale pot fi grupate n: limbaje algebrice - bazate pe teoria mulimilor (SEQUEL, SQL); limbaje predicative - fondate pe calculul predicatelor.

Limbajele predicative pot fi: orientate pe tupluri (QUEL, ALPHA); orientate pe domenii (pot fi non-grafice (ILL, FQL) sau grafice). Limbajele grafice pot fi: cu variabile domeniu explicite (QBE); fr variabile domeniu explicite (LAGRIF, CUPID, VGQF).

SQL este limbajul standard de descriere a datelor i acces la informaiile din baza de date. SQL nu este un limbaj unic (cu excepia standardului care este puin utilizat), existnd peste o 100 de dialecte. Au fost concepute i dezvoltate diferite versiuni ale standardului SQL de ctre

68

ANSI, IBM, Microsoft, Borland, etc. Din pcate, lipsa unui standard unic SQL are drept consecine creterea costurilor programelor de gestiune a bazelor de date i ngreunarea ntreinerii arhitecturilor client/server. Un grup de specialiti n baze de date s-au reunit sub numele SAG (SQL Access Group) cu scopul de a construi un limbaj SQL comun i de a realiza pentru fiecare dialect un program de conversie din dialect n SQL, i invers. Rezultatul a fost c n: 1992, Microsoft a lansat ODBC (Open Database Connectivity) care este o mulime de primitive bazate pe activitatea lui SAG; 1994 Borland a lansat IDAPI (Integrated Database Application Programming Interface) care este o bibliotec de funcii SQL ce se pot integra ntr-un program gazd.

Limbaje algebrice
n abordarea algebric, o relaie este considerat ca o mulime de tupluri, iar o baz de date este considerat ca o mulime de relaii pe care sunt definii operatorii algebrici. Exist dou tipuri de operatori algebrici: mulime (intersecie, reuniune, diferen, produs cartezian) i relaionali (proiecie, selecie, diviziune, compunere). Operatorii selecie, proiecie, produs cartezian, reuniune i diferen sunt ireductibili i sunt considerai drept operatori de baz, iar operatorii intersecie, diviziune i compunere pot fi dedui din operatorii anteriori i sunt considerai operatori derivai. Operatorii limbajului algebric permit exprimarea unor cereri nerecursive. Dac cererea este recursiv este necesar un operator special i anume nchiderea tranzitiv a unei relaii. limbaj algebric definit pentru prototipul relaional SYSTEMR. Operaia fundamental a limbajului este SELECT, care are forma general clasic. Operatorii clasici UNION, INTERSECTION, DIFFERENCE i INCLUSION sunt implementai n limbaj. SEQUEL este singurul limbaj relaional care are integrat nchiderea tranzitiv. Limbajul permite reactualizri asupra bazelor (UPDATE, INSERT, DELETE) i calculul unor funcii elementare (COUNT, SUM, AVG, MAX, MIN). Conceptul de partiionare a fost de asemenea introdus n SEQUEL i realizat cu ajutorul clauzelor GROUP BY i HAVING. O extensie comercial a acestui limbaj, adoptat de aproape toate SGBD i considerat drept standard n prelucrarea datelor relaionale, este SQL.

SEQUEL (Structured English as a Query Language) este un

69

Limbaje predicative
Limbajele predicative se bazeaz pe calculul predicatelor. Cererile sunt exprimate sub forma unor mulimi de tupluri sau valori pentru care se specific, sub forma unor predicate, proprietile pe care trebuie s le ndeplineasc.

QUEL este un limbaj predicativ orientat pe tupluri, utilizat de

sistemul INGRES. Limbajul QUEL poate fi utilizat independent sau inclus n limbajul de programare C. Limbajul este caracterizat de: declararea unei variabile tuplu pentru fiecare relaie (prin RANGE), absena cuantificatorilor n expresii, utilizarea unor operatori speciali pe mulimi, integrarea operaiilor aritmetice. Exemplu. S se listeze numele cititorilor care au mprumutat cri scrise de Cioran. RANGE OF a IS carte RANGE OF b IS cititor RANGE OF v IS imprumuta RETRIEVE b.nume WHERE (b.codec = v.codec) AND (v.codel = a.codel) AND (a.autor = Cioran) Limbajul accept comenzi de inserare (APPEND), reactualizare (REPLACE), suprimare (DELETE), precum i funcii de calcul (MAX, MIN, SUM, COUNT, AVG). Cuantificatorul existenial este reprezentat implicit prin declaraia RANGE, iar cuantificatorul universal este simulat cu ajutorul funciei COUNT. Exemplu. S se listeze numele cititorilor care au mprumutat toate crile din bibliotec scrise de Cioran. RANGE OF a IS carte RANGE OF b IS cititor RANGE OF v IS imprumuta RETRIEVE b.nume WHERE COUNT (v.codel WHERE (b.codec=v.codec)

70

AND (a.codel=v.codel) AND (a.autor=Cioran)) = COUNT (a.codel WHERE (a.autor=Cioran)) domenii. Limbajul dispune de primitive de programare grafic a cererilor de date i a fost conceput pentru utilizatorii neiniiai. Utilizatorii, pentru a manipula datele, completeaz o mulime de cmpuri predefinite pe un ecran special. Exemplu. S se obin titlurile crilor scrise de Cioran, din care exist n bibliotec mai mult de 10 exemplare.

QBE (Query By Example) este un limbaj predicativ orientat pe

Carte Codel

Titlu P.X

Autor 'Cioran'

Pret

Nrex >10

Coded

Dac utilizatorul dorete i tiprirea, atunci indic rezultatul care l intereseaz sub forma unei variabile domeniu (notat n acest exemplu prin X) prefixat de P (print). Dac condiia care apare n interogare este complex sau se dorete simplificarea scrierii unei cereri, se poate utiliza o caset special (box condition) n care se introduce condiia. n limbaj sunt admise funciile COUNT, MAX, MIN, AVG, SUM, iar pentru eliminarea dublurilor a fost introdus operatorul UNIQUE. Exemplu. S se obin pentru fiecare autor, preul celei mai scumpe cri i numrul exemplarelor scrise de acesta, care s gsesc n bibliotec (tabelul sortat!!!). Carte Codel Titlu Autor GROUP BY Pret MAX Nrex SUM Coded

n QBE exist posibilitatea de a crea o nou relaie care poate fi o schem virtual care reflect modificrile din relaiile de baz sau o imagine n care modificrile nu sunt stocate. Exemplu. Codurile crilor scrise de Popa sau care au titlul Geometrie.

71

Algebric: R1 = SELECT(carte, autor = 'Popa') R2 = SELECT(carte, titlu = Geometrie') R3 = R1 R2 Rezultat = PROJECT (R3, codel) SEQUEL: SELECT FROM WHERE OR QBE: Codel Titlu Autor Pret Nrex Coded P.X 'Popa' P.Y 'Geometrie' Exemplu. Numele cititorilor care au mprumutat cel putin o carte scrisa de Cioran. Algebric: R1 = PROJECT(cititor, codec, nume) R2 = SELECT(carte, autor = 'Cioran') R3 = PROJECT(R2, codel) R4 = PROJECT(imprumuta, codel, codec) R5 = JOIN(R4, R3, codel) R6 = JOIN(R5, R1, codec) Rezultat = PROJECT(R6, nume) QBE: Cititor Codec Y Codel Z Codec Y Autor 'Cioran' Nume P.X Dataim Dep Carte codel carte autor = Popa titlu = Geometrie

Imprumuta

Datares

Dataef

Carte Codel Titlu Z SEQUEL: SELECT FROM WHERE

Pret

Nrex

Coded

nume cititor codec IS IN

72

SELECT codec FROM imprumuta WHERE codel IS IN SELECT codel FROM carte WHERE autor = Cioran

Utilizarea limbajelor de prelucrare a datelor relaionale n contextul limbajelor de programare

Dou abordri: integrarea, extensia. Integrarea LMD-ului ntr-un limbaj de programare. Se consider limbajul de prelucrare independent de limbajul de programare i exist construcii speciale care permit utilizarea acestuia n limbajul gazd. De exemplu, comenzile SQL pot fi integrate n limbajul PL/1. Ele sunt prefixate de caracterul $ pentru a le distinge de comenzile PL/1. Pentru a realiza integrarea, este necesar fie o precompilare a cererilor, fie o interpretare la execuie. Precompilatoarele actuale acoper majoritatea limbajelor semnificative existente. Alegerea unui precompilator particular depinde de domeniul aplicaiei. Extensia limbajului de programare cu un LMD Se consider un limbaj de programare i se realizeaz extensii ale acestuia cu clauze specifice limbajelor de prelucrare a datelor. Un exemplu tipic este extensia PASCAL/R care permite definirea unui nou tip de date, i anume tipul RELATION. De exemplu, relaia carte este definit: TYPE car = RECORD codel: TEXTE; titlu: TEXTE; autor: TEXTE; nrex: INTEGER; pret: INTEGER; coded: TEXTE END; abc = RELATION OF car; VAR carte: abc;

73

Exemplu. S se obin o relaie avnd numele rezultat, ce conine toate crile scrise de Cioran care au preul mai mare de 150000. VAR rezultat: abc; BEGIN rezultat:=[]; FOR EACH x IN carte DO IF(x.autor = Cioran) AND (x.pret >= 150000) THEN rezultat:=rezultat + [x] END; Relaia rezultat poate fi construit i direct prin atribuirea: rezultat := [EACH (x) IN carte: (x.autor = Cioran) AND (x.pret >= 150000)];

PROIECTAREA BAZELOR DE DATE RELAIONALE

3.1. Preliminarii Modelul relaional a fost conceput i dezvoltat de E.F. Codd. El este un model formal de organizare conceptual a datelor, destinat reprezentrii legturilor dintre date, bazat pe teoria matematic a relaiilor. Este modelul cel mai accesibil pentru utilizatorul bazei de date deoarece structura sa fizic este aceeai cu cea a datelor care trebuie prelucrate. n general, datele se prezint sub forma unor tabele (relaii) n care liniile constituie nregistrri, iar coloanele sunt atribute ce caracterizeaz aceste nregistrri. Obiectivele modelului relaional, considerate de ctre E.F. Codd, sunt urmtoarele: s permit un grad nalt de independen a datelor; s furnizeze baze solide pentru tratarea semanticii, coerenei i problemelor de redundan a datelor; s permit dezvoltarea limbajelor de prelucrare a datelor. Spre deosebire de modelul ierarhic i reea unde apar dou elemente, i anume tipul entitii i relaiile dintre dou entiti, modelul relaional este alctuit numai din relaii i prin urmare, orice interogare asupra bazei de date este tot o relaie. Modelul relaional a fost definit cu o deosebit rigoare matematic, furniznd un mijloc performant de studiu al proprietilor logice ale unui sistem de baze de date. Referitor la partea de prelucrare a datelor, modelul relaional este orientat spre mulimi, n timp ce modelele ierarhic i reea sunt orientate spre fiiere. Pentru modelele ierarhic i reea, programatorul trebuie s proiecteze programe care s acceseze baza de date, nregistrare cu nregistrare, utiliznd legturi fizice ntre nregistrri. Modelul relaional a permis introducerea unor limbaje neprocedurale de prelucrare a datelor. Modelul relaional nu este orientat spre sistemul de calcul, deci modelul nu include regulile, structurile i operaiile referitoare la implementarea fizic a unui sistem de baze de date. De fapt, unul dintre obiectivele modelului este acela de a face o distincie ntre aspectele fizice i logice ale unei baze de date (independena datelor).

Modelul relaional, dei are unele imperfeciuni, a fost adoptat n ultimele decenii de majoritatea programatorilor din domeniu, tocmai datorit acestor trei caliti: este simplu, riguros din punct de vedere matematic i nu este orientat spre sistemul de calcul. Definirea unui SGBD relaional impune analizarea caracteristicilor pe care trebuie s le prezinte un model de date pentru a fi considerat relaional. Exist diferite modaliti pentru a defini acest concept: prezentarea datelor n tabele supuse anumitor operaii de tip proiecie, selecie, reuniune, compunere, intersecie etc. (definiie simpl); un sistem de baze de date ce suport un limbaj de tip SQL Structured Query Language (definiie practic); un sistem de baze de date care respect principiile modelului relaional introdus de E.F. Codd (definiia folosit cel mai frecvent). E.F. Codd a publicat un set de 13 reguli, numite reguli de fidelitate, n raport cu care un SGBD poate fi apreciat ca relaional. Ulterior, cele 13 reguli de fidelitate ale lui Codd au fost extinse la un numr de 100. Trebuie remarcat c nu exist un SGBD care respect toate regulile definite de Codd. Nu trebuie s apreciem un SGBD ca fiind relaional sau nu, ci msura n care acesta este relaional, deci numrul regulilor de fidelitate pe care le respect.

3.2. Caracterisicile modelului relaional Dintre principalele caracteristici ale modelului relaional se remarc: nu exist tupluri identice; ordinea liniilor i a coloanelor este arbitrar; articolele unui domeniu sunt omogene; fiecare coloan definete un domeniu distinct i nu se poate repeta n cadrul aceleiai relaii; toate valorile unui domeniu corespunztoare tuturor cazurilor nu mai pot fi descompuse n alte valori (sunt atomice). Comparativ cu celelalte modele de date, modelul relaional are avantaje remarcabile dintre care se remarc: fundamentarea matematic riguroas, independena fizic a datelor, posibilitatea filtrrilor,
2

 existena unor structuri de date simple, minimizarea redundanei, supleea n comunicarea cu utilizatorul neinformatician etc. Ca limite ale modelului relaional pot fi menionate: rmne totui redundan, ocup spaiu, apar fenomene de inconsisten, nu exist mecanisme pentru tratarea optim a cererilor recursive, nu lucreaz cu obiecte complexe, nu exist mijloace perfecionate pentru exprimarea constrngerilor de integritate, nu realizeaz gestiunea cunotinelor etc. Un model relaional este caracterizat de trei elemente: structura relaional a datelor (caracteristica structural), operatorii modelului relaional (caracteristica de asigurare a prelucrrii), regulile de integritate care guverneaz folosirea cheilor n model (caracteristica de asigurare a integritii). Aceste trei elemente corespund celor trei componente ale ingineriei software: informaie, proces, integritate. 3.2.1. Structura datelor Conceptelor descrise formal drept relaie, tuplu sau atribut, le corespund uzual denumirile tabel, linie sau coloan, iar fizic fiier, nregistrare sau cmp. Un domeniu este o mulime de valori care se poate defini fie enumernd elementele componente, fie specificnd o proprietate distinctiv a valorilor. Domeniului i corespunde, att uzual ct i fizic, conceptul de tip de date. Un tip de date este o mulime de valori, i anume mulimea tuturor valorilor care satisfac o anumit constrngere a tipului. Un tip de date poate fi definit de ctre sistem sau de ctre utilizator. De asemenea, fiecare tip are asociat un set de operatori care pot fi aplicai valorilor tipului respectiv. Tipurile constrng operaiile prin faptul c este necesar ca operanzii unei operaii s fie de tipurile definite pentru operaia respectiv.

Tipurile pot fi orict de simple sau de complexe. Se pot distinge tipuri de date ale cror valori sunt numere, iruri, date calendaristice, nregistrri audio sau video, hri, puncte geometrice etc. Orice tip de date este scalar (atomic, ncapsulat) sau nescalar. Tipul nescalar are componente vizibile utilizatorului i direct accesibile. Trebuie fcut distincia ntre un tip i reprezentarea sa fizic, deoarece tipurile sunt legate de model, iar reprezentarea fizic este un aspect legat de implementare. Fie D1, D2, ..., Dn domenii finite, nu neaprat disjuncte. Produsul cartezian D1 D2 ... Dn al domeniilor D1, D2, ..., Dn este definit de mulimea tuplurilor (V1, V2, ..., Vn), unde V1 D1, V2 D2, ..., Vn Dn. Numrul n definete aritatea tuplului. O relaie R pe mulimile D1, D2, ..., Dn este o submulime a produsului cartezian D1 D2 ... Dn, deci este o mulime de tupluri. Exist un alt mod de a defini relaia, i anume ca o mulime finit de funcii. Asociem fiecrui domeniu Di un atribut Ai i definim relaia R = {f1, f2, ..., fm}, unde fi : {A1, A2, ..., An} D1 D2 ... Dn i fi(Aj) Dj pentru orice valori ale lui i i j. n aceast definiie nu mai este restricionat ordinea. Definirea unei relaii ca o mulime de tupluri sau ca o mulime de funcii se refer la mulimi care variaz n timp (se adaug, se terg sau se modific elemente). Pentru a caracteriza o relaie este necesar existena unui element invariant n timp, iar acest invariant este dat de structura relaiei (schema relaional). Mulimea numelor atributelor corespunztoare unei relaii R definete schema relaional a relaiei respective. Vom nota schema relaional prin R(A1, A2, ..., An). De exemplu, pentru modelul de date analizat n aceast lucrare, VESTIMENTATIE(cod_vestimentatie, cod_designer, cod_model, cod_prezentare, denumire, valoare, descriere) reprezint o schem relaional. Putem reprezenta o relaie printr-un tabel bidimensional n care fiecare linie corespunde unui tuplu i fiecare coloan corespunde unui domeniu din produsul cartezian. O coloan corespunde unui atribut. Numrul atributelor definete gradul relaiei, iar numrul de tupluri din relaie definete cardinalitatea relaiei. Bazele de date relaionale sunt percepute de ctre utilizatori ca o mulime de tabele. Tabelul reprezint structura logic dintr-un sistem relaional, nu structura fizic. La nivel fizic, sistemul poate stoca datele n diferite moduri, folosind fiiere secveniale, indexri, nlnuiri de pointeri etc., cu condiia s poat realiza corespondena dintre reprezentarea stocat i tabelele de la nivelul logic.

Bazele de date relaionale respect principiul informaiei (principiul reprezentrii uniforme), care afirm c ntregul coninut informaional al bazei este reprezentat ntr-un mod unic, i anume, ca valori explicite ale celulelor unui tabel. Aceast modalitate de reprezentare este singura disponibil, la nivel logic, ntr-un sistem relaional. Cnd se insereaz tupluri ntr-o relaie, de multe ori valoarea unui atribut este necunoscut sau nu este aplicabil tuplului respectiv. Pentru a reprezenta valoarea acestui atribut a fost introdus o valoare convenional n relaie, i anume null. De fapt, null nu reprezint o valoare, ci absena uneia. Un null nu este acelai lucru cu o valoare numeric egal cu zero sau cu un ir de caractere vid. Zerourile i spaiile libere (irul vid) sunt valori, pe cnd null semnific absena unei valori. Prin urmare, null trebuie tratat n mod diferit fa de alte valori i trebuie neles c termenul valoare nul este depreciativ. Evident, este necesar o aritmetic i o logic (polivalent) nou (fig.3.1) care s cuprind acest element. De exemplu, ce valoare are 10 > null ? Rspunsul este null. n general, rezultatul operaiilor aritmetice sau logice este null cnd unul din operanzi este null. Prin urmare, null = null are valoarea null, iar null este null. ntroducerea null-urilor n modelul relaional constituie o problem controversat, dei Codd trateaz null ca parte integrant a modelului. Alii consider aceast abordare greit i prematur. Trebuie remarcat c nu toate sistemele relaionale accept null-urile. AND T F Null T T F F F F Null Null F Null OR T F T T T F T F Null T Null

Null F

Null T

Null Null

Fig. 3.1. Tabele de adevr pentru operatorii AND i OR Tabelul vizualizare (view, filtru, relaie virtual, vedere) constituie un filtru asupra tabelului iniial, care conine numai informaia necesar unei anumite abordri sau aplicaii. De fapt, vizualizarea este o expresie relaional creia i se atribuie un nume.
5

Dac baza de date conine tabele reale depuse pe disc, o vizualizare este virtual deoarece datele pe care le conine nu sunt n realitate memorate ntr-o baz de date. Este memorat numai definiia vizualizrii. Vizualizarea nu este definit explicit, ca relaiile de baz, prin mulimea tuplurilor componente, ci implicit, pe baza altor relaii obinute prin intermediul unor expresii relaionale. Stabilirea efectiv a tuplurilor care compun vizualizarea se realizeaz prin evaluarea expresiei atunci cnd utilizatorul se refer la acest tabel. Utilizarea vizualizrilor este avantajoas, deoarece: asigur securitatea tabelului iniial (care este protejat de tergeri, modificri etc.) prin capacitatea de a ascunde datele; permit vizualizarea simultan a acelorai date de ctre diveri utilizatori; sunt concise, punnd la dispoziie capaciti macro; asigur independena logic fa de date (imunitatea programelor de aplicaie fa de modificrile din structura logic a bazei de date). Exist totui limitri n utilizarea acestor tabele, n special legate de problema reactualizrii. De exemplu, coloanele calculate nu pot fi reactualizate. De asemenea, inserarea, reactualizarea i tergerea nu sunt, n general, recomandate i sunt permise numai cu anumite restricii care sunt specifice fiecrui SGBD. De exemplu, Oracle9i rezolv problema dificil a reactualizrii vizualizrilor, n anumite situaii, utiliznd o clas special de declanatoare (TRIGGER de tip INSTEAD OF). 3.2.2. Reguli de integritate Regulile de integritate sunt aseriuni pe care datele coninute n baza de date trebuie s le satisfac. Trebuie fcut distincia ntre regulile structurale care sunt inerente modelrii datelor i regulile de funcionare (comportament) care sunt specifice unei aplicaii particulare. Exist trei tipuri de constrngeri structurale (de cheie, de referin, de entitate) ce constituie mulimea minimal de reguli de integritate pe care trebuie s le respecte un SGBD relaional. Restriciile de integritate minimale sunt definite n raport cu noiunea de cheie a unei relaii. O mulime minimal de atribute ale cror valori identific unic un tuplu ntr-o relaie reprezint o cheie pentru relaia respectiv.

Prin urmare, o cheie a unei relaii R este o mulime K de atribute, astfel nct: (1) pentru orice dou tupluri t1, t2 ale lui R t1(K) t2(K); (2) nu exist nicio submulime proprie a lui K avnd proprietatea (1). Fiecare relaie are cel puin o cheie. Dac exist diferite chei posibile, ele se numesc chei candidat. Una dintre cheile candidat va fi aleas pentru a identifica efectiv tupluri i ea va primi numele de cheie primar. Cheia primar nu poate fi reactualizat. Restul cheilor candidat vor purta numele de chei alternative sau secundare. Atributele care reprezint cheia primar pot fi subliniate sau urmate de semnul #. O cheie identific linii i este diferit de un index care localizeaz liniile. O cheie secundar este folosit ca index pentru a accesa tupluri. Un grup de atribute din cadrul unei relaii care conine o cheie a relaiei poart numele de supercheie. Fie schemele relaionale R1(P1, S1) i R2(S1, S2), unde P1 este cheie primar pentru R1, S1 este cheie secundar pentru R1, iar S1 este cheie primar pentru R2. n acest caz, vom spune c S1 este cheie extern (cheie strin) pentru relaia R1. De exemplu, cod_casa_moda este cheie extern pentru relaia CREATOR i este cheie primar pentru relaia CASA_MODA. Cheia primar poate conine cheia extern. De exemplu, relaia ACCESORIU are cheia primar format din atributele cod_accesoriu i cod_vestimentatie, iar atributul cod_vestimentatie fiind cheie primar n relaia VESTIMENTATIE, devine cheie extern n relaia ACCESORIU. Modelul relaional respect trei reguli de integritate structural.

Regula 1 unicitatea cheii. Cheia primar trebuie s fie unic i minimal. Regula 2 integritatea entitii. Atributele cheii primare trebuie s fie diferite de null. Regula 3 integritatea referirii. O cheie extern trebuie s fie ori null n ntregime, ori s corespund unei valori a cheii primare asociate.

Uneori constrngerile de integritate sunt implementate procedural, folosind o clas de proceduri (declanatori) precompilate, stocate mpreun cu baza de date i invocate automat ori de cte ori are loc un anumit eveniment. Aceste proceduri nu reprezint o modalitate recomandat de implementare a constrngerilor de integritate deoarece, fiind proceduri, sunt

mai dificil de optimizat de ctre sistem i, de asemenea, sunt executate doar atunci cnd apare evenimentul specificat (declanator). Declanatorii trebuie utilizai cu precauie, sau deloc, dac exist o modalitate alternativ de rezolvare a problemei respective. Ei pot crea probleme practice datorit fenomenului declanatori n cascad (lan de declanatori). De asemenea, dac acelai eveniment determin pornirea mai multor declanatori diferii, atunci ordinea n care pornesc poate fi important sau poate fi chiar nedefinit. Exist posibilitatea ca un declanator s se declaneze singur, recursiv. Dac sunt disponibile, soluiile declarative sunt de preferat celor procedurale. 3.2.3. Operatorii modelului relaional Operatorii modelului relaional definesc operaiile care se pot efectua asupra relaiilor n scopul realizrii funciilor de prelucrare asupra bazei de date. Modelul relaional ofer dou mulimi de operatori pe relaii, i anume: algebra relaional i calculul relaional. La rndul su, calculul relaional este de dou tipuri: orientat pe tupluri sau orientat pe domenii. Operatorii algebrei relaionale sunt fie operatori tradiionali pe mulimi (UNION, INTERSECT, PRODUCT, DIFFERENCE), fie operatori relaionali speciali (PROJECT, SELECT, JOIN, DIVISION). Aceti operatori vor fi analizai n seciunea 3.4. Calculul relaional reprezint o adaptare a calculului predicatelor la domeniul bazelor de date relaionale. Ideea de baz este de a identifica o relaie cu un predicat. Pe baza unor predicate iniiale, prin aplicarea unor operatori ai calculului cu predicate (conjuncia, disjuncia, negaia, cuantificatorul existenial i cel universal) se pot defini noi relaii. Variabilele care apar n construciile calculului relaional orientat pe domenii sunt variabile definite asupra domeniilor, iar cele care apar n construciile calculului relaional orientat pe tupluri sunt variabile definite asupra relaiilor, adic valorile acestora reprezint tupluri. Echivalena dintre algebra relaional i calculul relaional a fost demonstrat de J.D.Ullman. Aceast echivalen arat c orice relaie posibil de definit n algebra relaional poate fi definit i n cadrul calcului relaional, i reciproc.

3.3. Proiectarea modelului relaional Problema proiectrii bazelor de date poate fi enunat n urmtoarea manier: fiind dat un volum de informaii care trebuie reprezentat ntr-o baz de date, cum se poate alege o structur logic adecvat pentru acesta? Proiectarea bazelor de date este mai mult o art, dect o tiin. Exist cteva principii tiinifice care pot fi invocate pentru a rezolva problema, dar exist multe aspecte legate de proiectare pe care aceste principii nu le abordeaz i evident, nu le rezolv. Teoreticienii i practicienii au propus metodologii de proiectare mai mult sau mai puin riguroase, dar gsirea proiectrii logice optime rmne o problem complex i dificil. Pot exista criterii obiective care s favorizeze o abordare n raport cu celelalte. n capitolul 2 s-a prezentat o abordare (proiectarea modelului E/R) care are meritul c este frecvent utilizat n practic. n practic, se ncearc obinerea unei scheme conceptuale corecte, adic realizarea proiectrii logice abstracte independent de hardware, de sistemul de operare, de SGBD, de limbaj, de utilizator etc. Este important att obinerea structurilor de date corecte, ct i realizarea integritii datelor. De asemenea, trebuie ca designul s fie robust, n sensul c nu va fi invalidat prin ivirea unor noi cerine ale aplicaiei, care nu au fost prevzute n momentul proiectrii iniiale. Pentru rafinarea proiectrii modelului de date, pentru obinerea schemei conceptuale a bazei de date relaionale, se pleac de la o form de modelare semantic special a datelor, mai precis de la diagrama E/R. Ideea general este de a reprezenta entitile i legturile dintre acestea sub forma unor tabele speciale (relaii). Vor fi prezentate 9 reguli care arat maniera n care se transform entitile, relaiile i atributele acestora, n vederea obinerii schemei conceptuale. Ca formalism, n diagrama conceptual, simbolul indic plasamentul cheii externe. Dac simbolul este subliniat (), se exprim i faptul c respectiva cheie extern este coninut n cheia primar.

3.3.1. Transformarea entitilor

Entitile independente devin tabele independente. Cheia primar nu conine chei externe. De exemplu, entitatea independent PREZENTARE genereaz un tabel independent pentru care atributul cod_prezentare reprezint cheia primar. Entitile dependente devin tabele dependente. Cheia primar a entitilor dependente conine cheia primar a entitii de care depinde (cheie extern) plus unul sau mai multe atribute adiionale. De exemplu, cheia primar a entitii dependente ACCESORIU este format din atributul cod_vestimentatie, care reprezint cheia primar a entitii de care depinde (VESTIMENTATIE), plus atributul adiional cod_accesoriu. Subentitile devin subtabele. Cheia extern se refer la supertabel, iar cheia primar este aceast cheie extern. De exemplu, cheia primar a subentitii MODEL este cod_angajat care este o cheie extern (cheie primar a entitii ANGAJAT_TEMP). 3.3.2. Transformarea relaiilor

Relaiile 1:1 i 1:n devin chei externe. De exemplu, relaia creeaza (CREATOR_creeaza_VESTIMENTATIE) devine coloan n tabelul VESTIMENTATIE. Atributul cod_creator, care este cheie primar n tabelul CREATOR, va fi cheie extern n tabelul VESTIMENTATIE. Relaia 1:1 plaseaz cheia extern n tabelul cu mai puine linii. Relaia m:n devine un tabel special, numit tabel asociativ, care are dou chei externe pentru cele dou tabele asociate. Cheia primar este compunerea acestor dou chei externe plus eventuale coloane adiionale. Un tabel asociativ se deseneaz punctat. De exemplu, relaia participa (CASA_MODA_participa_PREZENTARE), care este de tip m:n, devine tabel asociativ avnd cheia primar format din atributele cod_casa_moda i cod_prezentare. Relaiile de tip trei devin tot tabele asociative. De exemplu, relaia primeste ce leag entitile ANGAJAT_TEMP, PREZENTARE i CASA_MODA, devine tabel asociativ. Cheia primar a tabelului este compunerea a trei chei externe: cod_angajat, cod_casa_moda
10

i cod_prezentare. Practic, n acest caz, este preferabil s fie introdus o cheie primar artificial.

3.3.3. Transformarea atributelor

Un atribut singular devine o coloan. Atributele multiple devin tabele dependendente ce conin cheia primar a entitii i atributul multiplu. Cheia primar este format dintr-o cheie extern, plus una sau mai multe coloane adiionale. De exemplu, o persoan de contact poate cunoate mai multe limbi strine. n acest caz, atributul limba_cunoscuta este multiplu i va genera tabelul dependent LIMBA. Entitile devin tabele, iar atributele lor devin coloane n aceste tabele. Ce devin atributele relaiilor? Pentru relaii 1:1 i 1:n, atributele relaiilor vor aparine tabelului care conine cheia extern, iar pentru relaii m:n i de tipul trei, atributele vor fi plasate n tabelele asociative. Cheie primar nu conine chei externe o cheie extern o cheie extern i una sau mai multe coloane adiionale dou sau mai multe chei externe i (opional) coloane adiionale

Tabel Reprezint Independent entitate independent Subtabel subentitate entitate dependent Dependent Atribut multiplu relaie m:n Asociativ relaie de tip 3

Fig. 3.2. Clasificarea tabelelor

11

LIMBA FIRMA_PUB face PUBLICITATE organizeaza FIRMA_SEC are ANGAJAT_SEC se_face LOCATIE are PAZA ORGANIZATOR are

INFO CONTACT cunoaste are

PERS CONTACT are LOCALIZARE

PREZENTARE

FINANTEAZA

SPONSOR

SOC ASIG

asigura

PARTICIPA

CASA MODA prezinta lucreaza

PRIMESTE
ANGAJAT_TEMP

CREATOR creeaza prezinta face

MODEL

lucreaza_la are AGENTIE refera ISTORIC

VESTIMENTATIE
are

ACCESORIU

Fig. 3.3. Diagrama conceptual.

12

Cele patru tipuri de tabele (independente, dependente, subtabele i asociative) se deosebesc prin structura cheii primare (figura 3.2.). n figura 3.3 este prezentat diagrama conceptual pentru proiectarea modelului relaional comentat. Ea a fost construit din diagrama E/R prin adugarea tabelelor asociative i prin marcarea cheilor externe. n continuare va fi prezentat modalitatea efectiv de trecere de la diagrama entitate-relaie la diagrama conceptual pentru modelul de date real analizat n capitolul 2. Entitile independente PERS_CONTACT, ORGANIZATOR, PREZENTARE, PUBLICITATE, SPONSOR, FIRMA_PUB, CASA_MODA, CREATOR, ANGAJAT_TEMP, ACCESORIU, LOCALIZARE, FIRMA_SEC, ANGAJAT_SEC, SOCIETATE_ASIG, INFO_CONTACT, AGENTIE, LOCATIE devin tabele independente. Cheile primare ale fiecrei entiti au fost specificate n capitolul 2. Entitile dependente ISTORIC i ACCESORIU, care intervin n model, devin tabele dependente, iar cheile primare au fost specificate n capitolul 2. Subentitatea MODEL devine subtabel, avnd aceeai cheie primar cu superentitatea ANGAJAT_TEMP, adic atributul cod_angajat. Relaiile de tip one-to-one i one-to-many devin chei externe. Relaia PERS_CONTACT_are_LOCALIZARE devine cheie extern n tabelul PERS_CONTACT. Dac restricia c o persoan de contact are o singur localizare este eliminat, atunci cardinalitatea relaiei devine 1:n, iar atributul cod_pers_contact devine cheie extern n tabelul LOCALIZARE. Toate comentariile anterioare rmn valabile i pentru entitile FIRMA_PUB, FIRMA_SEC, PREZENTARE, ORGANIZATOR, CASA_MODA, SPONSOR, SOC_ASIG, CREATOR, LOCATIE, ANGAJAT_TEMP i AGENTIE, care sunt legate de entitatea LOCALIZARE, permind astfel localizarea tuturor structurilor modelului. Relaia PERS_CONTACT_are_INFO_CONTACT devine cheie extern n tabelul PERS_CONTACT. Dac restricia c pentru o persoan de contact exist o singur posibilitate de contactare este eliminat, atunci cardinalitatea relaiei devine 1:n, iar atributul cod_pers_contact devine cheie extern n tabelul INFO_CONTACT. Toate comentariile anterioare rmn valabile i pentru entitile FIRMA_PUB, FIRMA_SEC, ANGAJAT_TEMP, PREZENTARE, ORGANIZATOR, CASA_MODA, SPONSOR, SOC_ASIG, CREATOR, LOCATIE i AGENTIE, care sunt legate de entitatea INFO_CONTACT, permind astfel accesarea tuturor structurilor modelului.
13

Relaia FIRMA_PUB_face_PUBLICITATE devine cheie extern n tabelul PUBLICITATE. Relaia PUBLICITATE_se_face_pentru_PREZENTARE devine cheie extern n tabelul PUBLICITATE. Relaia ORGANIZATOR_are_PERS_CONTACT devine cheie extern n tabelul PERS_CONTACT. Relaia FIRMA_SEC_are_ANGAJAT_SEC devine cheie extern n tabelul ANGAJAT_SEC. Relaia SOC_ASIG_asigura_PREZENTARE devine cheie extern n tabelul PREZENTARE. Relaia CASA_MODA_lucreaza_CREATOR devine cheie extern n tabelul CREATOR. Relaia CREATOR_creeaza_VESTIMENTATIE devine cheie extern n tabelul VESTIMENTATIE. Relaia VESTIMENTATIE_are_ACCESORIU devine cheie extern n tabelul ACCESORIU. Relaia MODEL_prezint_VESTIMENTATIE devine cheie extern n tabelul VESTIMENTATIE. Relaia CREATOR_face_ACCESORIU devine cheie extern n tabelul ACCESORIU. Relaia PREZENTARE_prezinta_VESTIMENTATIE devine cheie extern n tabelul VESTIMENTATIE. Relaia PREZENTARE_are_LOCATIE devine cheie extern n PREZENTARE. Relaia MODEL_lucreaza_AGENTIE devine cheie extern n tabelul MODEL. Relaia MODEL_are_ISTORIC devine cheie extern n tabelul ISTORIC. Relaia ISTORIC_refera_AGENTIE devine cheie extern n tabelul ISTORIC. Relaiile de tip many-to-many devin tabele asociative, avnd dou chei externe pentru cele dou tabele asociate. Relaia ANGAJAT_SEC_paza_PREZENTARE devine tabel asociativ (PAZA). SPONSOR_finanteaza_PREZENTARE devine tabel asociativ (FINANTEAZA). CASA_MODA_participa_PREZENTARE devine tabel asociativ (PARTICIPA). Relaiile de tipul trei (adic cele care leag cel puin trei entiti) devin tabele asociative, avnd chei externe pentru fiecare dintre tabelele asociate.

14

Relaia primeste, care leag entitile ANGAJAT_TEMP, PREZENTARE i CASA_MODA, devine tabel asociativ (PRIMESTE). n acest caz, s-a considerat o cheie primar artificial (atributul cod_primeste). Tabelul asociativ are drept chei externe atributele: cod_angajat, cod_casa_moda i cod_prezentare. Atributele multiple devin tabele dependendente ce conin cheia primar a entitii i atributul multiplu. Atributul limba_cunoscuta este multiplu (relativ la entitatea PERS_CONTACT) i va genera tabelul dependent LIMBA. Acesta va avea drept cheie primar atributele cod_pers_contact i limba_cunoscuta. Tabelul mai conine trei atribute ce reprezint nivelul de cunoatere (scris, citit, vorbit) a limbii. Atributele entitilor devin coloane n tabelele corespunztoare. Pentru relaii 1:1 i 1:n, atributele relaiilor vor aparine tabelului care conine cheia extern, iar pentru relaii m:n i de tipul trei, atributele vor fi plasate n tabelele asociative. Tabelul asociativ PRIMESTE va avea ca atribute, pe lng cele ce constituie cheia primar, suma, data_achitare, cont, banca. Schemele relaionale corespunztoare diagramei conceptuale din figura 3.3. sunt urmtoarele: MODEL(cod_angajat#, cod_agentie, inaltime, nr_pantof, info) ANGAJAT_TEMP(cod_angajat#, nume, prenume, data_nastere, nationalitate, sex, cod_localizare, cod_info_acces, tip) PUBLICITATE(cod_publicitate#, cod_firma_pub, cod_prezentare, tip, nume, suma, observatii) FIRMA_PUB(cod_firma_pub#, nume, info, director, observatii, cod_localizare, nume_pers_contact, cod_info_acces) ORGANIZATOR(cod_organizator#, denumire, banca, cont, cod_info_acces, informatii, cod_localizare) PERS_CONTACT(cod_pers_contact#, cod_organizator, nume, prenume, directie, cod_localizare, cod_info_acces) PREZENTARE(cod_prezentare#, denumire, data_start, data_final, cod_soc_asig, cod_organizator, cod_locatie) LOCATIE(cod_locatie#, denumire, tip, cod_localizare, cod_info_acces, capacitate) SPONSOR(cod_sponsor#, tip, nume, info, cod_localizare, cod_info_acces)
15

CASA_MODA(cod_casa_moda#, nume, cifra_afaceri, proprietar, director, istoric, data_creare, cod_localizare, cod_info_acces) CREATOR(cod_creator#, nume, prenume, data_nastere, data_angajare, tip, mod_angajare, info, cod_casa_moda, cod_localizare, cod_info_acces) VESTIMENTATIE(cod_vestimentatie#, denumire, valoare, descriere, cod_creator, cod_model, cod_prezentare) ACCESORIU(cod_vestimentatie#, cod_accesoriu#, cod_creator, descriere, tip, valoare) AGENTIE(cod_agentie#, nume, data_creare, director, cifra_afaceri, info, cod_localizare, cod_info_acces) ISTORIC(cod_model#, data_angajare#, data_final, cod_agentie, conditii) LOCALIZARE(cod_localizare#, adresa, cod_postal, oras, tara) INFO_CONTACT(cod_info_acces#, telefon_fix, telefon_mobil, mail, fax) FIRMA_SEC(cod_firma_sec#, nume_firma, tip_servicii, director, cod_localizare, cod_info_acces, observatii) ANGAJAT_SEC(cod_angajat#, nume, prenume, data_nastere, specializare, nivel, observatii, cod_info_acces, cod_firma_sec) PAZA(cod_angajat#, cod_prezentare#, tip_paza, dotare, observatii) SOC_ASIG(cod_soc_asig#, conditii, suma, director, observatii, cod_localizare, nume_pers_contact_firma, cod_info_acces) PARTICIPA(cod_prezentare#, cod_casa_moda#, tip, data) FINANTEAZA(cod_sponsor#, cod_prezentare#, suma, banca, cont_emitent, data_emitere, cod_ordin_plata) PRIMESTE(cod_primeste#, cod_angajat, cod_prezentare, cod_casa_moda, data_achitare, suma, cont, banca) LIMBA(cod_pers_contact#, niv_vorbit) limba_cunoscuta#, niv_scris, niv_citit,

16

3.4. Regulile lui Codd Un SGBD relaional ndeplinete funciile unui SGBD, dar cu anumite particulariti care decurg din concepia de organizare a datelor, respectiv din modelul relaional. Fiecare SGBD relaional implementeaz modelul relaional ntr-o manier proprie, care l difereniaz de restul sistemelor relaionale. Caracterizarea unui SGBD relaional se poate realiza la nivelul clasei sistemelor relaionale, n sensul caracterizrii globale, unitare n raport cu celelalte tipuri de SGBD-uri, sau la nivelul SGBD-ului relaional individual n sensul caracterizrii particularitilor sale, n raport cu alte SGBD-uri relaionale. Realizarea funciilor SGBD-urilor relaionale se face cu ajutorul unor mecanisme de lucru specifice, care le separ de sistemele nerelaionale. Dintre mecanismele de lucru de care dispune un SGBD relaional se pot meniona: un limbaj relaional pentru descrierea datelor la nivel fizic, logic i conceptual; un limbaj relaional pentru prelucrarea datelor; mecanisme pentru controlul integritii semantice a datelor; mecanisme pentru optimizarea cererilor de date; mecanisme pentru asigurarea coerenei datelor; utilitare pentru generarea de rapoarte, pentru generarea de aplicaii, pentru generarea unor statistici referitoare la starea i activitatea bazei de date etc. n anul 1985, E.F. Codd a publicat un set de 13 reguli n raport cu care un sistem de gestiune a bazelor de date poate fi apreciat ca relaional. Niciun sistem de gestiune a bazelor de date pus n vnzare pe piaa comercial nu respect absolut toate regulile definite de Codd, dar acest lucru nu mpiedic etichetarea acestor sisteme drept relaionale. Nu trebuie apreciat un SGBD ca fiind relaional sau nu, ci msura n care acesta este relaional, deci numrul regulilor lui Codd pe care le respect. Regulile lui Codd au fost i sunt cauza multor controverse. Unii le consider doar un exerciiu academic, alii pretind c produsele lor satisfac majoritatea regulilor. De fapt, discuiile n jurul acestor reguli au generat o cunoatere mai bun a caracteristicilor eseniale ale unui SGBD relaional, att din punctul de vedere al utilizatorilor, ct i din cel al productorilor de software.

17

Regulile pot fi organizate n urmtoarele cinci domenii de funcionalitate: reguli fundamentale, reguli structurale, reguli de integritate, reguli de prelucrare a datelor i reguli privind independena datelor. Regula 1 regula gestionrii datelor. Un SGBD relaional trebuie s fie capabil s gestioneze o baz de date prin posibilitile sale relaionale. Practic, nicio implementare curent de SGBD nu respect aceast regul, deoarece implementrile conin att caracteristici relaionale ct i nerelaionale. Regula 2 regula reprezentrii informaiei. ntr-o baz de date relaional, informaia este reprezentat la nivel logic sub forma unor tabele ce poart numele de relaii. Este regula cea mai important i conform lui Codd, un SGBD care nu respect aceast regul, nu poate fi considerat relaional. Chiar i meta-datele, coninute n catalogul de sistem, trebuie s fie stocate ca relaii. Regula 3 regula accesului garantat la date. Fiecare valoare dintr-o baz de date relaional trebuie s poat fi adresat n mod logic printr-o combinaie format din numele relaiei, valoarea cheii primare i numele atributului. Regula 4 regula reprezentrii informaiei necunoscute. Un sistem relaional trebuie s permit utilizatorului definirea unui tip de date numit null pentru reprezentarea unei informaii necunoscute la momentul respectiv. ntr-un SGBD relaional trebuie s putem face diferena ntre valoarea zero, un ir vid de caractere i o valoare necunoscut. Regula 5 regula dicionarelor de date. Asupra descrierii bazelor de date (informaii relative la relaii, vizualizri, indeci etc.) trebuie s se poat aplica aceleai operaii ca i asupra datelor din baza de date. Descrierea bazei de date este reprezentat la nivel logic sub forma unor tabele care pot fi accesate n acelai mod ca i datele efective. Prin urmare exist un singur limbaj de prelucrare att a meta-datelor, ct i a datelor. Regula 6 regula limbajului de interogare. Trebuie s existe cel puin un limbaj pentru prelucrarea bazei de date. n general, toate implementrile SQL respect aceast regul. Limbajul permite utilizatorilor s defineasc relaii i vizualizri, s prelucreze datele interactiv sau prin intermediul programului, s regseasc informaia i s o poat actualiza, s verifice i s corecteze datele de intrare, s implementeze constrngeri, s stabileasc limite pentru tranzacii etc. Regula 7 regula de actualizare a vizualizrii. Un SGBD trebuie s poat determina dac o vizualizare poate fi actualizat i s stocheze rezultatul interogrii, ce definete vizualizarea, ntr-un dicionar de tipul
18

unui catalog de sistem. Trebuie s existe un mecanism prin care s se poat determina dac anumite vizualizri pot fi actualizate sau nu. Regula stabilete c toate vizualizrile care sunt teoretic reactualizabile pot fi reactualizate i de ctre sistemul de gestiune. Nu au fost nc descoperite condiiile pentru identificarea tuturor vizualizrilor care pot fi teoretic reactualizate. Regula 8 regula limbajului de nivel nalt. Capacitatea de tratare a unei relaii de baz sau a unei vizualizri ca pe un singur operand se aplic att pentru operaiile de regsire a datelor, ct i asupra operaiilor de inserare, actualizare i tergere a datelor. Un SGBD relaional nu trebuie s oblige utilizatorul s caute ntr-o relaie, tuplu cu tuplu, pentru a regsi informaia dorit. Operaiile de prelucrare a datelor pot s fie aplicate att n mod interactiv ct i prin program, ntr-un limbaj gazd. Regula 9 regula independenei fizice a datelor. Programele de aplicaie i activitile utilizatorilor nu depind de modul de depunere a datelor sau de modul de acces la date. ntr-un SGBD relaional trebuie s se separe aspectul fizic al datelor (stocare sau acces la date) de aspectul logic al datelor. Regula 10 regula independenei logice a datelor. Programele de aplicaie trebuie s fie transparente la modificrile de orice tip efectuate asupra datelor. Orice modificare efectuat asupra unei relaii nu trebuie s afecteze operaiile de prelucrare a datelor. Regula 11 regula independenei datelor din punct de vedere al integritii. Regulile de integritate trebuie s fie definite ntr-un sublimbaj relaional de date, nu n programul de aplicaie. SQL permite definirea de restricii privind integritatea datelor i stocarea lor n catalogul de sistem. Cu ct sunt mai multe constrngeri de integritate care pot fi ntreinute mai degrab de ctre SGBD, dect n cadrul fiecrui program aplicaie, cu att garantarea calitii datelor este mai bun. Regula 12 regula independenei datelor din punct de vedere al distribuirii. Distribuirea datelor pe mai multe calculatoare dintr-o reea de comunicaii de date nu trebuie s afecteze programele de aplicaie. ANSISQL nu menioneaz regula n specificaiile sale, deoarece este destul de greu de respectat. De observat c regula nu cere ca SGBD-ul s accepte o baz de date distribuite pentru a fi relaional, dar stabilete c limbajul de interogare va rmne acelai atunci cnd se va introduce aceast capacitate, iar datele vor fi distribuite.

19

Regula 13 regula versiunii procedurale a unui SGBD. Orice component procedural a unui SGBD trebuie s respecte aceleai restricii de integritate ca i componenta relaional. De exemplu, dac n partea de prelucrare a datelor a limbajului relaional valoarea dintr-o coloan este de tipul not null, orice alt metod procedural de accesare a acestei coloane nu trebuie s permit introducerea unui null n aceast coloan. Prin urmare, regulile de integritate exprimate ntr-un limbaj relaional de un anumit nivel nu pot fi distruse de un limbaj de nivel inferior. Deoarece regulile lui Codd sunt prea severe pentru a fi respectate de un SGBD operaional, s-au formulat criterii minimale de definire a unui SGBD relaional. Un SGBD este minimal relaional dac: toate datele din cadrul bazei sunt reprezentate prin valori n tabele; nu exist pointeri observabili de ctre utilizator; sistemul suport operatorii relaionali de proiecie, selecie i compunere natural, fr limitri impuse din considerente interne. Un SGBD este complet relaional dac este minimal relaional i satisface n plus condiiile: sistemul suport restriciile de integritate de baz (unicitatea cheii primare, constrngerile refereniale, integritatea entitii); sistemul suport toate operaiile de baza ale algebrei relaionale.

20

4. NORMALIZAREA RELAIILOR
4.1. Preliminarii
n procesul modelrii unei baze de date relaionale, o etap important o reprezint normalizarea relaiilor conceptuale. Aceasta presupune obinerea de relaii moleculare, fr a pierde nimic din informaie, avnd scopul de a elimina redundana i anomaliile reactualizrii informaiilor. Tehnica normalizrii permite determinarea unei scheme conceptuale rafinate, printr-un proces de ameliorare progresiv a unei scheme conceptuale iniiale a bazei de date relaionale. Dup fiecare etap de ameliorare, relaiile bazei de date ating un anumit grad de perfeciune, deci se afl ntr-o anumit form normal. Trecerea unei relaii dintr-o form normal n alta presupune eliminarea unui anumit tip de dependene nedorite, care sunt transformate n dependene admisibile, adic dependene care nu provoac anomalii. Procesul de ameliorare progresiv a schemei conceptuale trebuie s satisfac urmtoarele cerine: s garanteze conservarea datelor, adic n schema conceptual final trebuie s figureze toate datele din cadrul schemei iniiale; s garanteze conservarea dependenelor dintre date, adic n schema final fiecare dependen trebuie s aib determinantul i determinatul n schema aceleiai relaii; s reprezinte o descompunere minimal a relaiilor iniiale, adic nici una din relaiile care compun schema final nu trebuie s fie coninut ntr-o alt relaie din aceast schem. Exist dou metode pentru a modela baze de date relaionale fr anomalii sau pierderi de informaie. Schema descompunerii pleac de la o schem relaional universal care conine toate atributele bazei de date. Schema se descompune prin proiecii succesive n subrelaii. Descompunerea se oprete atunci cnd continuarea ei ar duce la pierderi de informaie. Algoritmii de descompunere se bazeaz, n general, pe descrierea formal a dependenei dintre atribute. Schema sintezei pleac de la o mulime de atribute independente. Utiliznd proprieti de semantic i legturi ntre atribute se pot compune noi relaii, astfel nct acestea s nu sufere de anumite anomalii pe care dorim s le evitm. Algoritmii de sintez se bazeaz n general pe teoria grafurilor pentru a reprezenta legturile ntre atribute.
21

4.2. Dependene funcionale Unul dintre conceptele principale asociate normalizrii este cel de dependen funcional, care descrie formalizat legturile dintre atribute. Dependena funcional este o proprietate a semanticii atributelor dintr-o relaie. Semantica indic modul n care sunt legate atributele i specific dependenele dintre ele. Atunci cnd exist o dependen funcional, ea este specificat ca o constrngere ntre atribute. O relaie universal este o relaie ce grupeaz toate atributele care modeleaz sistemul real cercetat. Fie E, mulimea dependenelor considerate de proiectantul bazei pentru o schem relaional sau pentru o relaie universal. Plecnd de la o mulime de proprieti formale ale dependenelor, proprieti considerate drept reguli de deducie (axiome), poate fi obinut mulimea maximal de dependene asociate lui E. Aceast mulime definete nchiderea lui E. Fie R(A1, A2, ..., An) o schem relaional i fie X, Y submulimi de atribute ale lui R. X determin funcional Y sau Y depinde funcional (FD) de X, dac pentru orice relaie r (valoare curent a lui R) nu exist dou tupluri care s aib aceleai valori pentru atributele lui X i s aib valori diferite pentru cel puin un atribut din Y. Cu alte cuvinte, o valoare a lui X determin unic o valoare a lui Y. Notaia utilizat pentru desemnarea dependenei funcionale este X Y. Altfel spus: Definitie: Fie R un tabel relational si X si Y dou submultimi de coloane ale lui R. Spunem c X determin functional pe Y sau c Y depinde functional de X dac nu exist dou rnduri n tabelul R care s aib aceleasi valori pentru coloanele din X si s aib valori diferite pentru coloanele din Y. Dependena funcional X Y reprezint o constrngere aplicat tuplurilor relaiei R, n sensul c oricare dou tupluri din R care au aceeai valoare pentru X trebuie s ia aceeai valoare i pentru Y. Dac pentru fiecare valoare a lui X exist cel mult o valoare a lui Y, spunem c X este determinant iar Y este determinat. Comparnd toate submulimile de atribute ale unei relaii i determinnd legturile dintre ele, se pot obine toate dependenele funcionale pe care o relaie le satisface. Aceast abordare nu este eficient, consumnd mult timp. Exist posibilitatea ca, tiind anumite dependene funcionale i utiliznd reguli de deducie, s fie obinute toate dependenele funcionale.
22

Fie X, Y, Z, W mulimi de atribute ale unei scheme relaionale R i fie urmtoarele reguli de inferen (axiome) prin care noi dependene funcionale pot fi deduse din cele date: Ax1 reflexivitate. X X. Mai general, dac Y X, atunci X Y. Ax2 creterea determinantului. Pot fi considerate trei formulri echivalente pentru aceast axiom. 1. Dac X Y i X Z, atunci Z Y. 2. Dac X Y i W Z, atunci X Z Y W. 3. Dac X Y atunci X Z Y Z. Ax3 tranzitivitate. Dac X Y i Y Z, atunci X Z. 4.3. Necesitatea normalizrii Anomaliile care apar n lucrul cu baze de date se produc datorit dependenelor care exist ntre datele din cadrul relaiilor bazei. Aceste anomalii fac extrem de dificil lucrul cu baza de date. Aceste anomalii vor fi comentate cu ajutorul unui exemplu. Se consider o vizualizare (VP) asupra schemei relaionale PREZENTARE ce conine doar atributele cod_prezentare#, denumire, luna_start, cod_organizator. Aceste atribute reprezint pentru fiecare prezentare de mod: codul acesteia, denumirea, luna n care ncepe prezentarea i codul organizatorului. Se consider constrngerea: toate prezentrile de mod cu acelai nume ncep n aceeai lun. cod_prezentar e 1 2 3 4 5 denumire primavara primavara primavara iarna toamna luna_start mai mai mai martie august cod_organizato r 11 37 11 32 11

Fig. 4.1. Vizualizarea VP Datorit dependenei introduse pot exista: anomalii la inserare, modificare sau tergere, redundan n date, probleme de reconexiune. 1. Redundan logic. Cuplul (primavara, mai) apare de trei ori.

23

2.

3.

4.

Anomalie la inserie. Dac se dorete includerea unei prezentri de mod, care va incepe n luna aprilie i va avea denumirea veselie, atunci perechea (veselie, aprilie) poate fi inserat n relaia VP doar dac se definete o nou valoare pentru cheia primar. Anomalie la tergere. Dac este tears nregistrarea pentru care codul prezentrii are valoarea 4, atunci se pierde informaia c prezentarea avnd denumirea iarna a nceput n luna martie. Anomalie la modificare. Dac se modific luna de nceput a prezentrii primavara de la mai la februarie, atunci costul modificrii este mare pentru a modifica toate nregistrrile, iar dac se modific doar o nregistrare atunci constrngerea nu va mai fi verificat.

Anomaliile au aprut datorit dependenei funcionale (constrngerii) introduse anterior. Normalizarea are drept scop: suprimarea redundanei logice, evitarea anomaliilor la reactualizare, rezolvarea problemei reconexiunii. Exist o teorie matematic a normalizrii al crei autor este E.F. Codd. Soluia lui E.F. Codd este construirea unor tabele standard (forme normale). Normalizarea este procesul reversibil de transformare a unei relaii, n relaii de structur mai simpl. Procesul este reversibil n sensul c nicio informaie nu este pierdut n timpul transformrii. O relaie este ntr-o form normal particular dac ea satisface o mulime specificat de constrngeri. Procesul normalizrii se realizeaz plecnd de la o relaie universal ce conine toate atributele sistemului de modelat, plus o mulime de anomalii. Orice form normal se obine aplicnd o schem de descompunere. 4.4. Forme normale Formele normale ale relaiilor din baze de date relaionale sunt definite n raport cu anomaliile care pot aprea n lucrul cu aceste relaii, deci n funcie de dependenele nedorite care se manifest n cadrul relaiilor. Pe msur ce relaia este transformat n forme superioare, devine din ce n ce mai restrictiv ca format i mai puin expus anomaliilor la reactualizare. Altfel spus: Definitie: Normalizarea reprezint procesul de descompunere a unui tabel relational n mai multe tabele care satisfac anumite reguli si care stocheaz aceleasi date ca si tabelul initial astfel nct s fie eliminate redundanta n date si anomaliile la actualizare.

24

Prima form normal (FN1) O relaie este n prima form normal dac fiecrui atribut care o compune i corespunde o valoare indivizibil (atomic). n plus, un tuplu nu trebuie s conin atribute sau grupuri de atribute repetitive. Aceast form figureaz ca cerin minimal n majoritatea sistemelor relaionale. Algoritm AFN1 (aducerea unei relaii n FN1 prin eliminarea atributelor compuse i a celor repetitive) 1. Se introduc n relaie, n locul atributelor compuse, componentele acestora. 2. Se plaseaz grupurile de atribute repetitive, fiecare n cte o nou relaie. 3. Se introduce n schema fiecrei noi relaii de la pasul 2 cheia primar a relaiei din care a fost extras atributul repetitiv. 4. Se stabilete cheia primar a fiecrei noi relaii create la pasul 2. Aceasta este compus din cheia introdus la pasul 3, precum i din atribute proprii ale acestor noi relaii. Forma normal 2 (FN2) O relaie R este n a doua form normal dac i numai dac: relaia R este n FN1; fiecare atribut care nu este cheie (nu particip la cheia primar) este dependent de ntreaga cheie primar. A doua condiie exprim necesitatea dependenei totale de cheia primar. Aceast form normal interzice manifestarea unor dependene funcionale pariale n cadrul relaiei R. Pentru a obine o relaie FN2 se poate aplica regula Casey-Delobel. Fie relaia R(K1, K2, X, Y), unde K1 i K2 definesc cheia primar, iar X i Y sunt mulimi de atribute, astfel nct K1 X. Din cauza dependenei funcionale K1 X care arat c R nu este n FN2, se nlocuiete R (fr pierdere de informaie) prin dou proiecii R1(K1, K2, Y) i R2(K1, X). Caracterul reversibil al normalizrii Prin caracter reversibil al normalizrii se ntelege faptul c descompunerea se face fr pierdere de informatie, adic tabelul initial poate fi reconstituit prin compunerea natural, pe atribute comune, a tabelelor rezultate.
25

Pentru un tabel R care se descompune prin proiectie n mai multe tabele: R1, R2, Rn, conditia de descompunere fr pierdere de informatie presupune ca n urma operatiei de compunere natural a tabelelor R1, R2, Rn s se obtin tabelul R. Regula Casey-Delobel (caz particular de descompunere fr pierdere de informatie): Fie un tabel R(X, Y, Z) care se descompune prin proiectie n tabelele R1(X, Y) si R2(X, Z) unde prin X notm setul de coloane comune ale tabelelor R1 si R2, iar prin Y si Z, coloanele specifice lui R1, respectiv R2. Conditia de descompunere fr pierdere de informatie presupune ca tabelul R s fie obtinut prin compunerea natural a tabelelor R1 si R2. n SQL: SELECT R1.X, R1.Y, R2.Z FROM R1, R2 WHERE R1.X = R2.X Algoritm AFN2 (aducerea unei relaii n FN2 prin eliminarea dependenelor funcionale pariale din cadrul unor relaii aflate n FN1) 1. Pentru fiecare dependen funcional parial se creeaz o nou relaie avnd schema format din determinantul i determinatul acestei dependene. 2. Se elimin din cadrul relaiei iniiale atributele care formeaz determinatul dependenei pariale. 3. Dac n relaia iniial exist mai multe dependene pariale cu acelai determinant, pentru acestea se creeaz o singur relaie cu schema format din determinant (luat o singur dat) i din determinaii dependenelor considerate. 4. Se determin cheia primar a fiecrei noi relaii create. Aceasta va conine atributele din determinantul dependenei funcionale pariale care au stat la baza constituirii relaiei. 5. Dac noile relaii create conin dependene pariale, atunci se face transfer la pasul 1, altfel procesul de aducere la FN2 s-a terminat.

26

Exemplu Fie schema relaional PARTICIPA (cod_prezentare#, cod_casa_moda#, tip, data, data_start, data_final, denumire) Pentru relaia PARTICIPA sunt adevrate dependenele: {cod_prezentare} {data_start, data_final, denumire} {cod_prezentare, cod_casa_moda} {data, tip} Relaia PARTICIPA este n FN1, dar nu este n FN2 deoarece atributele data_start, data_final i denumire nu depind de codul casei de mod, deci nu depind de ntreaga cheie primar. Pentru a obine o relaie n FN2 se aplic regula Casey Delobel i relaia PARTICIPA se proiecteaz n dou relaii: PARTI1(cod_prezentare#, data_start, data_final, denumire) PARTI2(cod_prezentare#, cod_casa_moda#, data, tip). Not (reamintim C2): Entitatea PREZENTARE are atributele: cod_prezentare, denumire, data_start, data_final, cod_organizator, cod_soc_asig, cod_locatie. Entitatea CASA_MODA are atributele: cod_casa_moda, nume, cifra_afaceri, proprietar, director, istoric, data_creare, cod_localizare, cod_info_acces. Atribute ale relatiei PARTICIPA tip = variabil de tip caracter, de lungime maxim 15, care reprezint modalitatea n care o cas de mod particip la o prezentare, n sensul c poate fi organizator sau neorganizator. data = variabil de tip dat calendaristic reprezentnd ziua n care defileaz modelele casei de mod. Atributul nu este multiplu, deoarece s-a presupus c defilarea unei case de mod are loc ntr-o singur zi. Alt Exemplu: Fie tabelul VANZARI care se foloseste la nregistrarea tranzactiilor unui magazin ce vinde articole la comand. VANZARI (cod_client#, cod_comanda#, cod_articol#, nume_client, nr_telefon, data, nume_articol, cost_articol, cantitate) A1 C1 P1 Popescu 415355 08.10.04 camasa 400000 2 A1 C1 P3 Popescu 415355 08.10.04 tricou 200000 1
27

A2 C2 P1 Ionescu 596322 09.10.04 camasa 400000 3 A2 C2 P3 Ionescu 596322 C2 09.10.04 tricou 200000 2 A2 C2 P2 Ionescu 596322 09.10.04 pantaloni 800000 1 A1 C3 P3 Popescu 415355 10.10.04 tricou 200000 3 A3 C4 P1 Marinescu 546229 C4 10.10.04 P1 camasa 400000 1 Tabelul de mai sus prezint urmtoarele deficiente: a) redundante n date: - informatia (P1, camasa, 400000) este specificata de 3 ori - informatia (A1, Popescu, 415355) este specificata de 3 ori - informatia (A2, Ionescu, 196322) este specificata de 3 ori - s. a. m. d. b) anomalii la actualizare: - anomalie la insertie Dac magazinul achizitioneaz un nou articol (P4, pantofi, 980000) informatia nu poate fi introdus n tabel (un nou tuplu) pentru c s-ar introduce o valoare Null n cheia primar (cod_comanda). - anomalie la stergere Dac este anulat articolul P2 n cadrul comenzii C2 se pierde informatia referitoare la numele si costul articolului respectiv. - anomalie la modificare Dac se modific numrul de telefon al unui client, modificarea trebuie facut n toate tuplurile (liniile) unde apare numele acelui client. n tabelul VANZARI exist urmtoarele dependente functionale n care determinantul nu este cheie a tabelului: (cod_articol) (nume_articol, cost_articol) (cod_comanda) (data, cod_client, nume_client, nr_telefon) (cod_client) (nume_client, nr_telefon) Pentru a obine o relaie n FN2 se aplic regula Casey Delobel i relaia VANZARI se proiecteaz n trei relaii: VANZARI1(cod_articol# nume_articol, cost_articol) VANZARI2(cod_comanda#, data, cod_client, nume_client, nr_telefon) VANZARI3(cod_client #, nume_client, nr_telefon)

28

Forma normal 3 (FN3) Intuitiv, o relaie R este n a treia form normal dac i numai dac: relaia R este n FN2; fiecare atribut care nu este cheie (nu particip la o cheie) depinde direct de cheia primar. Fie R o relaie, X o submulime de atribute ale lui R i A un atribut al relaiei R. A este dependent tranzitiv de X dac exist Y astfel nct X Y i Y A (unde A nu aparine lui Y i Y nu determin pe X). De exemplu, dac au loc dependenele K1, K2, K3 A1 i K1, K2, A1 A2, atunci K1, K2, K3 K1, K2, A1 i K1, K2, A1 A2. Prin urmare, A2 este dependent tranzitiv de K1, K2, K3. Formal, o relaie R este n a treia form normal dac i numai dac: relaia R este n FN2; fiecare atribut care nu este cheie (nu particip la o cheie) nu este dependent tranzitiv de nicio cheie a lui R. A doua condiie interzice utilizarea dependenelor funcionale tranzitive n cadrul relaiei R. Prin urmare, o relaie este n FN3 dac i numai dac fiecare atribut care nu este cheie depinde de cheie, de ntreaga cheie i numai de cheie. Pentru a obine o relaie FN3 se poate aplica regula de descompunere Casey-Delobel. Fie relaia R(K, X1, X2, X3), unde atributul X2 depinde tranzitiv de K, iar K este cheia primar a lui R. Presupunem c K X1 X2. Din cauza dependenei funcionale X1 X2 care arat c R nu este n FN3, se nlocuiete R (fr pierdere de informaie) prin dou proiecii R1(K, X1, X3) i R2(X1, X2). Dependena tranzitiv poate fi mai complex. Fie K1 o parte a cheii K. Tranzitivitatea poate fi de forma K Y X2 unde Y = {K1, X1}. n acest caz, R poate fi descompus n R1(K, X1, X3) i R2(K1, X1, X2). Algoritm AFN3 (aducerea unei relaii FN2 n FN3 prin eliminarea dependenelor funcionale tranzitive) 1. Pentru fiecare dependen funcional tranzitiv se transfer atributele implicate n dependena tranzitiv ntr-o nou relaie. 2. Se determin cheia primar a fiecrei noi relaii create la pasul 1. 3. Se introduc n relaia iniial, n locul atributelor transferate, cheile primare determinate la pasul 2.
29

4.

Se reanalizeaz relaia iniial. Dac n cadrul ei exist noi dependene tranzitive, atunci se face transfer la pasul 1, altfel procesul de aducere la FN3 s-a terminat.

Exemplu Fie schema relaional PREZENT(cod_prezentare#, data_start, data_final, denumire, cod_locatie, capacitate, cod_info_acces). Pentru relaia PREZENT sunt adevrate dependenele: {cod_prezentare} {data_start, data_final, denumire, cod_locatie} {cod_locatie} {capacitate, cod_info_acces} Relaia PREZENT este n FN2, dar nu este n FN3 deoarece atributele capacitate, cod_info_acces depind indirect de cheia primar, prin intermediul atributului cod_locatie. Pentru a obine o relaie n FN3 se aplic regula Casey-Delobel i relaia PREZENT se proiecteaz n dou relaii, prin eliminarea dependenelor funcionale tranzitive. PREZENT1(cod_prezentare#, data_start, data_final, denumire, cod_locatie) PREZENT2(cod_locatie#, capacitate, cod_info_acces) Forma normal Boyce-Codd (BCNF) Determinantul este un atribut sau o mulime de atribute neredundante, care constituie un identificator unic pentru alt atribut sau alt mulime de atribute ale unei relaii date. Intuitiv, o relaie R este n forma normal Boyce-Codd dac i numai dac fiecare determinant este o cheie candidat. Formal, o relaie R este n forma normal Boyce-Codd dac i numai dac pentru orice dependen funcional total X A, X este o cheie a lui R. Algoritm ABCNF (aducerea unei relaii FN3 n BCNF prin eliminarea dependenelor funcionale ai cror determinani nu sunt chei candidat) 1. Dac relaia conine unul sau cel mult dou atribute, atunci nu pot exista dependene noncheie i deci relaia este n BCNF. 2. Dac relaia conine mai mult de dou atribute, se caut dac ea conine dependene noncheie. Dac nu exist astfel de dependene, relaia este n BCNF. 3. Pentru fiecare dependen noncheie X Y se creeaz dou relaii. Una dintre ele va avea schema format din atributele {X, Y}, iar
30

4.

cealalt va avea schema format din toate atributele relaiei iniiale, mai puin Y. Se reiau paii 1, 2, 3 pentru relaiile obinute la pasul 3.

Exemplu Se consider relaia FINANTEAZA1, ce leag entitile PREZENTARE i SPONSOR. Ea are cardinalitatea many to many i va genera un tabel asociativ. Se presupune c acest tabel are schema relaional: FINANTEAZA1(cod_prezentare#, cod_sponsor#, nume_prezentare, cod_ordin_plata). Pentru exemplul analizat se presupune c numele prezentrilor sunt unice. Prin urmare, n orice moment fiecare prezentare are un cod unic i un nume unic. Cheile candidat sunt {cod_prezentare, cod_sponsor}, respectiv {nume_prezentare, cod_sponsor}. ntre atributele relaiei exist dependenele: {cod_prezentare, cod_sponsor} {cod_ordin_plata} {cod_prezentare} {nume_prezentare} Tabelul nu este n BCNF deoarece conine doi determinani, cod_prezentare i nume_prezentare, care nu sunt chei candidat pentru tabelul respectiv. Ambele atribute sunt determinani deoarece fiecare l determin pe cellalt. Soluia problemei const n divizarea relaiei n dou proiecii conform tehnicii Casey-Delobel. PREZENTARE(cod_prezentare#, nume_prezentare) FINANTEAZA(cod_prezentare#, cod_sponsor#, cod_ordin_plata) Forma normal 4 (FN4) Dac BCNF elimin redundanele datorate relaiilor singulare, FN4 elimin redundanele datorate relaiilor m:n, adic datorate dependenei multiple. Intuitiv, o relaie R este n a patra form normal dac i numai dac relaia este n BCNF i nu conine relaii m:n independente. Exemplu Fie schema relaional PERS_CONTACT(cod_pers#, limba_cunoscuta, nr_telefon). Se presupune c o persoan de contact poate cunoate mai multe limbi strine i poate avea mai multe numere de telefon. ntre atributele relaiei exist multidependenele:
31

cod_pers# limba_cunoscuta cod_pers# nr_telefon. Pentru a aduce relaia PERS_CONTACT (care este n BCNF) n FN4, aceasta se va diviza n dou proiecii : PERS_CONTACT1(cod_pers#, limba_cunoscuta) PERS_CONTACT1(cod_pers#, nr_telefon). Forma normal 5 (FN5) Semnificaia lui FN5 este mai mult academic, ea aprnd rar n practic. A cincea form normal i propune eliminarea redundanelor care apar n relaii m:n dependente. n general, aceste relaii nu pot fi descompuse. S-a artat c o relaie de tip 3 este diferit de trei relaii de tip 2. Exist totui o excepie, i anume, dac relaia este ciclic. Intuitiv, o relaie R este n forma normal 5 dac i numai dac: 1. relaia este n FN4; 2. nu conine dependene ciclice. Exemplu Se consider o relaie ce conine informaii despre creatori, vestimentaiile create de acetia i accesoriile corespunztoare. Se consider schema relaional CREARE(cod_vestimentatie#, cod_creator#, cod_accesoriu#). Se presupune c fiecare creator poate crea una sau mai multe vestimentaii. Fiecare vestimentaie poate fi creat de unul sau mai muli creatori. Similar, fiecare creator este responsabil de crearea unuia sau a mai multor accesorii, iar fiecare accesoriu este creat de unul sau mai muli creatori. Fiecare accesoriu apare n una sau mai multe vestimentaii, iar fiecrei vestimentaii i se ataeaz unul sau mai multe accesorii. Mai mult chiar, dac creatorul C creeaz vestimentaia V, iar accesoriul A este ataat lui V, iar C este este responsabil de A, atunci C creeaz accesoriul A pentru vestimentaia V. innd seama de constrngerile impuse modelului se obin dependenele: {cod_vestimentatie#, cod_creator#} {cod_accesoriu} {cod_vestimentatie#, cod_accesoriu#} {cod_creator} {cod_accesoriu#, cod_creator#} {cod_vestimentatie}. Datorit dependenelor formulate anterior, relaia nu este n FN5. Ea se poate rupe prin proiecie n trei relaii: CREARE1(cod_vestimentatie#, cod_creator#)
32

CREARE2(cod_vestimentatie#, cod_accesoriu#) CREARE3(cod_creator#, cod_accesoriu#). n acest caz, sunt evidente relaiile: CREARE JOIN(CREARE1, CREARE2) CREARE JOIN(CREARE1, CREARE3) CREARE JOIN(CREARE2, CREARE3) CREARE = JOIN(JOIN(CREARE1, CREARE2), CREARE3). Concluzii: 1. FN1 FN2 elimin redundanele datorate dependenei netotale a atributelor care nu particip la o cheie, fa de cheile lui R. Se suprim dependenele funcionale care nu sunt totale. 2. FN2 FN3 elimin redundanele datorate dependenei tranzitive. Se suprim dependenele funcionale tranzitive. 3. FN3 BCNF elimin redundanele datorate dependenei funcionale. Se suprim dependenele n care partea stng nu este o supercheie. 4. BCNF FN4 elimin redundanele datorate multidependenei. Se suprim toate multidependenele care nu sunt i dependene funcionale. 5. FN4 FN5 elimin redundanele datorate dependenei ciclice. Se suprim toate join-dependenele care nu sunt implicate de o cheie. 6. BCNF, FN4 i FN5 corespund la regula c orice determinant este o cheie, dar de fiecare dat dependena cu care se definete determinantul este alta i anume dependena funcional, multidependena sau join-dependena. 7. Descompunerea unei relaii FN2 n FN3 conserv datele i dependenele, pe cnd descompunerea unei relaii FN3 n BCNF i, respectiv, a unei relaii BCNF n FN4 conserv doar datele.

33

Partea a II-a. LIMBAJUL SQL

n aceast tema: se prezint conceptele limbajului SQL n 5 lecii, dup cum urmeaz: INTRODUCERE. Concepte SQL LECIA 1. Limbajul de definire a datelor - DDL LECIA 2. Limbajul de interogare a datelor - DQL LECIA 3. Combinarea datelor din mai multe tabele Uniuni LECIA 4. Limbajul de manipulare a datelor DML LECIA 5. Limbajul de control al datelor DCL Introducere. Concepte SQL SQL a devenit limbajul universal pentru bazele de date relaionale i este acceptat de aproape toate sistemele SGBD moderne. Fr ndoial, acceptarea pe scar larg este rezultatul timpului i eforturilor depuse pentru dezvoltarea caracteristicilor limbajului i a standardelor, crescnd nivelul de portabilitate a codului SQL ntre diferitele produseSGBD. Ce este SQL? SQL (Structured Query Language -limbaj structurat de interogare) este un limbaj standard folosit pentru crearea, actualizarea i regsirea informaiilor stocate n baze de date prin intermediul sistemelor de gestionare a bazelor de date ( SGBD-uri). Numele limbajului poate fi pronunat pe litere (es-q-el) sau la fel ca i cuvntul englezesc sequel". O interogare (query) este o simpl cerere transmis ctre baza de date, la care aceasta rspunde ntr-o anumit form. SQL este limbajul folosit cel mai frecvent pentru interogarea bazelor de date. SQL este considerat un limbaj neprocedural sau declarativ, ceea ce nseamn c-i spunei calculatorului ce rezultate vrei, far s-i spunei cum s le obin. De exemplu, dac vrei s obinei media numerelor de pe o coloan, folosii funcia AVG. Nu este nevoie s numrai valorile din coloan i s mprii suma acestora la numrul obinut - procesorul limbajului SQL din SGBD se ocup de toate aceste lucruri n locul dumneavoastr. Este important s nelegi c SQL nu este un limbaj procedural, ca C, Pascal, Basic, FORTRAN, COBOL sau Ada. Un limbaj procedural folosete o serie de instruciuni executate secvenial. De asemenea, limbajele procedurale includ instruciuni care pot modifica secvena de

execuie, prin ramificarea la alte poriuni ale procedurii sau prin parcurgerea ciclic a unui set de instruciuni din procedur. Muli productori de sisteme SGBD ofer extensii procedurale ale limbajului SQL de baz, cum ar fi Oracle PL/SQL (Procedural Language/SQL) sau Microsoft Transact-SQL, dar reinei c acestea sunt extensii SQL care formeaz noi limbaje - codul SQL pe care-1 conin rmne neprocedural. De asemenea, SQL nu trebuie confundat cu limbajele orientate spre obiecte, precum Java i C++. Simplu spus, SQL este un limbaj neprocedural pentru gestionarea i ntreinerea bazelor de date relaionale, nu un limbaj potrivit pentru programarea general a aplicaiilor, cum ar fi sistemele de prelucrare a comenzilor sau a plilor. SQL este deseori folosit n combinaie cu limbajele procedurale sau orientate spre obiecte menionate anterior pentru a manipula stocarea i extragerea datelor, folosind instruciuni din limbajul de programare cu destinaie general pentru alte sarcini de programare, precum prezentarea datelor pe o pagin web sau furnizarea rspunsurilor la informaiile introduse de utilizatori de la tastatur sau mouse. Atunci cnd este necesar interacionarea cu baza de date, instruciunile din limbajul procedural formeaz instruciunea SQL, o transmit ctre SGBD n vederea prelucrrii, primesc rezultatele returnate de SGBD i le prelucreaz ntr-un mod corespunztor. Folosind SQL putei transforma ntrebri obinuite :Din ce oras sunt studentii notri? n instruciuni pe care le nelege soft-ul pentru baze de date: SELECT oras FROM studenti. SQL se poate folosi nu numai pentru interogare, dar i pentru a aduga, a modifica sau a terge nregistrri din bazele de date. Majoritatea SGBD -urilor populare, ca de exemplu Microsoft Accsess, Oracle i MySQL , asigur suport pentru SQL, chiar dac acest nivel de suport difer de la produs la produs. Conectarea la baza de date Atunci cnd folosii limbajul SQL pe un calculator personal, cu o copie personal a unui sistem SGBD, precum Microsoft Access sau Oracle Personal Edition, toate componentele bazei de date ruleaz pe acelai sistem de calcul. Totui, acest aranjament nu este potrivit pentru bazele de date care trebuie s fie folosite n comun de mai muli utilizatori. Ca urmare, sunt mult mai frecvent ntlnite situaiile n care baza de date este instalat ntr-un aranjament client/server. ntr-un aranjament client/server:

 Sistemul ruleaz pe un server, care este un sistem de calcul partajat. Pentru scopurile acestei definiii, un sistem mainframe poate fi considerat un server de dimensiuni mari. Fiierele care compun baza de date din punct de vedere fizic sunt stocate pe discuri conectate la serverul de baze de date. Utilizatorii care au acces la baza de date folosesc staii de lucru, numite clieni. Clientul trebuie s aib o conexiune de reea la baza de date, care poate fi o reea privat, instalat acas sau la birou, ori o reea public, precum Internet. Componentele software furnizate de productorul SGBD ruleaz pe staiile de lucru alte clienilor pentru a oferi utilizatorilor posibilitatea s introduc instruciuni SQL, s le transmit sistemului SGBD n vederea prelucrrii i s vad rezultatele returnate de DBMS. n general, acest software se numete client SQL. Reinei c nimic nu v oprete s instalai clientul SQL pe acelai calculator cu sistemul SGBD. De fapt, muli dezvoltatori care utilizeaz sisteme SGBD precum MySQL, Microsoft SQL Server i Oracle fac n mod obinuit acest lucru, deoarece este foarte convenabil s aib ntregul mediu de dezvoltare pe un singur calculator, cum ar fi un laptop. Totui, n momentul n care este necesar accesul partajat al mai multor utilizatori, este mult mai convenabil i mai eficient s avei o singur copie a sistemului SGBD pe un server partajat i s avei numai clientul SQL instalat pe staia de lucru a fiecrui client. n funcie de interfaa cu utilizatorul de pe staia de lucru client, clienii SQL sunt clasificai n trei categorii: n linia de comand, grafici i bazai pe web. O interfa n linia de comand se bazeaz exclusiv pe intrri i ieiri de tip text, cu comenzile introduse de la tastatur i rspunsurile afiate ca mesaje de tip text. Principalul avantaj al interfeelor n linia de comand este c pot fi rulate pe aproape orice sistem de operare. De exemplu, clientul SQL*Plus rulat ntr-o fereastr de comand Microsoft Windows.

O interfa grafic cu utilizatorul (GUI - Graphical User Interface) ruleaz sub un tip oarecare de sistem bazat pe ferestre, cum ar fi : X Window System, Mac OS sau Microsoft Windows, i afieaz datele sau opiunile comenzilor folosind elemente grafice, precum pictograme, butoane i casete de dialog. n figura de mai jos se prezint clientul SQL*Plus(unul din clienii SQL furnizai de ORACLErulat ca aplicaie GUI sub Microsoft Windows.

O interfa bazat pe web ruleaz pe serverul de baze de date, folosind un browser web de pe staia de lucru client pentru a interaciona cu utilizatorul bazei de date. Din punct de vedere tehnic, un client SQL bazat pe web nici nu este o aplicaie client, deoarece nu exist nici o component software specific productorului SGBD rulat pe staia de lucru a clientului. Totui, aproape ntotdeauna exist componente furnizate de productorul SGBD care sunt descrcate n fundal de browser-ul web pentru a asista n procesul de reprezentare grafic a formularelor web folosite pentru introducerea instruciunilor SQL i afiarea rezultatelor. Tabelul urmtor prezint clieni SQL oferii de diferii productori SGBD. n aceast curs nu prezentm toate detaliile referitoare la fiecare client SQL pe care ai putea s-1 folosii, aa c v rog s consultai documentaia productorului SGBD pentru informaii despre instalarea i utilizarea clienilor SQL disponibile pentru sistemul SGBD pe care-1 folosii

Productor

SGBD

Client SQL

Descriere
Microsoft Access este o baz de date de uz personal, cu clientul SQL integrat n

Microsoft

Access

Nu exist DBMS, toate fiind rulate local pe staia de lucru a utilizatorului. Client SQL care ruleaz ca aplicaie n

Microsoft

SQL Server

iSQL

linia de comand ntr-un nucleu de comenzi Microsoft Windows.

Microsoft

SQL Server Query Analyzer

Client SQL care ruleaz ca aplicaie Microsoft Windows. Client SQL care ruleaz ca

aplicaie n linia de comand sub MySQL MySQL MySQL diferite sisteme de operare, inclusiv Microsoft Windows, Linux, Mac OS X i diferite implementri Unix. Client Oracle Oracle iSQL*Plus SQL bazat pe web -

acceptat n versiunile Oracle 9i si mai noi. Client SQL care ruleaz ca

aplicaie Microsoft Windows sau ca aplicaie n linia de comand Oracle Oracle SQL*Plus sub diferite sisteme de operare, inclusiv Linux, Microsoft Mac OS X, Windows, diferite

implementri Unix i altele. Client Oracle Oracle SQL Worksheet nlocuit de iSQL*Plus n Oracle 10g.
Clientul SQL care ruleaz ca aplicaie n linia de comand ntr-un nucleu de comenzi Sybase Sybase iSQL Microsoft Windows.

SQL

scris

Java

disponibil n Oracle 8i i 9i, dar

Asemnrile cu Microsoft SQL Server nu sunt ntmpltoare primele

versiuni Microsoft SQL Server erau bazate pe sistemul SGBDSybase.

Un scurt istoric al limbajului SQL Ctre sfritul anilor '70, un grup de cercettori de la IBM au dezvoltat o baz de date relaional, numit System/R, bazat pe lucrrile Dr. E. F. Codd. n System/R a fost inclus un limbaj, numit SEQUEL (Structured English Query Language), pentru manipularea i extragerea datelor. Acronimul SEQUEL" a fost ulterior condensat n abrevierea SQL", atunci cnd s-a descoperit c SEQUEL" era marc nregistrat a companiei Hawker-Siddeley Aircraft din Marea Britanie. Dei IBM a creat prima implementare SQL, dou alte produse, cu nume diferite pentru limbajele de interogare, au fost lansate pe pia ca primele produse pentru baze de date relaionale, Oracle, furnizat de Relational Software, i INGRES, furnizat de Relational Technology. IBM a lansat n 1982 produsul SQL/DS, cu limbajul de interogare numit acum SQL (Structured Query Language). Dac programarea structurat era expresia la mod n anii '80, cuvntul structured" din SQL nu avea nici o legtur cu programarea structurat, deoarece SQL nu este un limbaj de programare procedural. Comitetele de standardizare a limbajului SQL au fost formate de ANSI (American National Standards Institute) n 1986 i ISO (International Organization for Standardization) n 1987. Din fericire, comitetele create de cele dou organizaii au colaborat pentru dezvoltarea unui standard SQL comun, la nivel mondial. Doi ani mai trziu, au fost publicate primele specificaii ale standardului, numite SQL-89. Dup trei ani, specificaiile originale au fost extinse, sub forma standardului SQL92, care avea aproximativ 600 de pagini. A treia generaie a fost numit SQL-99 sau SQL3. Cele mai multe produse SGBD sunt construite pe baza standardului SQL-92 (numit acum SQL2). SQL3 include multe caracteristici obiectuale, necesare pentru folosirea limbajului SQL cu o baz de date relaional orientat spre obiecte, precum i extensii de limbaj care fac din SQL un limbaj de programare complet (adugnd cicluri, ramificri i construcii de comutare, de tip case). Cea mai recent generaie, numit SQL:2003, introduce caracteristici legate de XML i alte mbuntiri. Aceste standarde nu sunt gratuite. Standardul SQL:2003 poate fi cumprat de la ISO (www.iso.org) sau ANSI (webstore.ansi.org). Pentru cei care au un buget mai restrns, este disponibil o versiune apropiat de cea final la Whitemarsh Information Systems Corporation (www.wiscorp.com/SQLStandards.html). Aproape toi furnizorii au adugat extensii la dialectul" SQL propriu, n parte deoarece doreau s diferenieze produsele proprii i n parte deoarece cerinele pieei i forau s implementeze caracteristici nainte a aprea standarde pentru acestea. Un astfel de exemplu este acceptarea tipurilor de date TIMESTAMP i DATE. Datele calendaristici sunt foarte importante
6

pentru prelucrarea datelor comerciale, dar dezvoltatorii produselor SGBD originale erau academicieni i oameni de tiin, nu specialiti n prelucrri comerciale, aa c aceast cerin nu a fost anticipat. Ca rezultat, primele dialecte SQL nu asigurau un suport special pentru datele calendaristice. Pe msur ce au aprut produsele comerciale, furnizorii au rspuns cererilor lansate de clienii importani i au adugat n grab suportul pentru date calendaristice. Din nefericire, din cauza grabei fiecare a fcut-o n felul propriu. Codul SQL este foarte compatibil i portabil ntre produsele diferiilor furnizori, dar sistemele complete de baze de date pot fi rareori transferate far anumite ajustri. SQL a sistemului Oracle este o extensie a normei SQL89 i o implementare a normei SQL92. Convenii de sintax SQL Aceast seciune prezint conveniile generale de sintax folosite pentru construia instruciunilor SQL. Totui, reinei c exist o mulime de extensii i variaii ntre diferiii productori. Pentru simplitate, termenul implementare este folosit pentru referirea fiecrei versiuni SQL a fiecrui productor (cu alte cuvinte, Oracle 9i, Oracle 10g, Microsoft SQL Server 7, Microsoft SQL Server 2000 i Microsoft SQL Server 2005 conin implementri diferite ale limbajului SQL). Conveniile de sintax SQL sunt mai uor de neles folosind un exemplu simplu. Instruciunea de mai jos returneaz valorile Movie ID i Movie Title pentru toate filmele din magazinul de produse video pentru care categoria MPAA este PG": SELECT FILM_ID, TITLU_FILM FROM FILM WHERE MPAA_RATING_COD = 'PG'; Conveniile de baz sunt urmtoarele: Fiecare instruciune ncepe cu o comand, de obicei sub forma unui singur cuvnt, care aproape ntotdeauna este un verb (n limba englez) care descrie o aciune. n acest exemplu, instruciunea ncepe cu comanda SELECT, care este descris n detaliu n lecia 3. Fiecare instruciune se termin cu un delimitator, care este, de obicei, un caracter punct i virgul (;). Unele implementri permit schimbarea delimitatorului cu un alt caracter. Mai mult, unele implementri, cum ar fi cea din Oracle, nu execut o instruciune SQL creia-i lipsete delimitatorul de sfrit, n timp ce alte implementri consider acest delimitator opional. Instruciunile sunt construite ntr-o manier similar cu propoziiile din limba englez, cu unul sau mai multe spaii pentru
7

separarea elementelor de limbaj. Un element de limbaj, asemntor cu un cuvnt dintr-o propoziie, poate fi un cuvnt cheie (SELECT, FROM, WHERE), numele unui obiect al bazei de date (FILM, FILM_ID, TITLU_FILM), un operator (=) sau o constant ('PG') care apare ntr-o instruciune. Instruciunile sunt scrise ntr-o form liber, ceea ce nseamn c nu exist reguli stricte privind poziia elementelor de limbaj pe o linie sau locul n care se poate face trecerea la o linie nou. Totui, n general nu este o idee bun s mprii un element de limbaj pe mai multe linii. Din punct de vedere logic, instruciunea de mai jos este identic cu cea prezentat la nceputul acestei seciuni, dar nu este la fel de uor de citit i de neles: SELECT FILM_ID, TITLU_FILM FROM FILM WHERE MPAA_RATING_COD ='PG'; Instruciunile sunt organizate ntr-o serie de clauze i, de obicei, clauzele trebuie s apar ntr-o anumit ordine atunci cnd sunt folosite (multe clauze sunt opionale). n exemplul nostru, exist trei clauze, fiecare ncepnd cu un cuvnt cheie (SELECT, FROM, WHERE). Elementele de limbaj SQL pot fi scrise cu litere mari, cu litere mici sau n combinaii. Totui, n majoritatea implementrilor i n conformitate cu standardele ANSI/ISO, toate minusculele sunt transformate n majuscule n vederea prelucrrii. Aceasta nu nseamn c datele nu pot conine litere mici, ci c numele obiectelor din baza de date (tabele, coloane etc.) i comenzile trebuie s fie scrise cu litere mari. Excepii notabile sunt Microsoft SQL Server i Sybase, care permit modul de lucru cu diferenierea literelor mari de cele mici, caz n care numele de obiecte scrise diferit sunt tratate ca nume diferite. n MySQL, diferenierea literelor mari de cele mici n numele obiectelor este legat de capacitatea sistemului de operare de a face aceast difereniere. Virgulele sunt folosite pentru separarea articolelor dintr-o list. n exemplul nostru, numele a dou coloane sunt specificate ntr-o list separat prin virgule (FILM_ID, TITLU_FILM). Spaiile care urmeaz dup virgule sunt opionale - putei aduga orice numr de spaii, inclusiv zero. irurile de caractere care apar n instruciunile SQL trebuie s fie ncadrate cu apostrofuri (unele implementri SQL permit i folosirea ghilimelelor). Constantele numerice nu sunt niciodat ncadrate cu apostrofuri. Dac n irul de caractere trebuie s apar un caracter apostrof, sunt inserate dou apostrofuri unul lng cellalt. De exemplu, dac vrei s gsii n baza de date un film numit Sophie's Choice, vei scrie clauza WHERE astfel: WHERE TITLU_FILM = 'Sophie''s Choice'
8

 Numele obiectelor bazei de date sunt formate folosind numai litere, cifre i liniue de subliniere. Caracterul underscore (liniua de subliniere) este folosit, de obicei, ca separator ntre cuvinte, pentru mbuntirea lizibilitii. Aa cum am menionat anterior, unele implementri permit folosirea numelor care fac diferena ntre literele mari i cele mici, cum ar fi PersonMiddleName, un stil numit deseori scriere de tip cmil", dar acest stil nu este recomandabil dac dorii ca instruciunile SQL s fie portabile pe alte implementri. n definitiv, un nume precum PERSONMIDDLENAME" nu este foarte uor de citit. In fiecare implementare SQL este definit un set de cuvinte rezervate, care sunt cuvinte cu o semnificaie specific pentru procesorul SQL al sistemului SGBD i, care urmare, nu trebuie folosite ntr-un alt context - de exemplu ca nume pentru obiectele bazei de date. Scopul acestei restricii este de a evita interpretarea greit a instruciunilor SQL de ctre SGBD. Aa cum probabil bnuii, lista cuvintelor rezervate difer semnificativ de la o implementare SQL la alta, aa c este bine s consultai documentaia implementrii pe care o folosii pentru a v familiariza cu aceste cuvinte. Un comentariu pe o singur linie ncepe cu dou liniue de desprire (--). Cele dou liniue se pot afla la nceputul unei linii, ceea ce nseamn c ntreaga linie este considerat comentariu, sau oriunde n cadrul liniei, caz n care restul liniei, pn la sfrit, este considerat comentariu. De exemplu: -- Acesta este un comentariu pe o singur linie n SQL. Un comentariu pe mai multe linii ncepe cu combinaia dintre o diagonal la dreapta (slash) i un asterisc (/*) i continu pn la ntlnirea combinaiei invers (*/). Avei grij s terminai corect comentariile, altfel multe linii SQL pe care le-ai scris vor fi tratate de ctre SGBD ca i cum ar fi comentarii. Iat un exemplu de comentariu pe mai multe linii: /* Acesta este un comentariu pe mai multe linii. Continu pn la ntlnirea combinaiei de caractere care marcheaz sfritul comentariului. */ Sistemul impune anumite restricii asupra identificatorilor. Numele unui obiect nu poate depi 30 de caractere, cu excepia numelui bazei de date care este limitat la 8 caractere i a numelui legturii unei baze care poate ajunge la 128 caractere. Nu se face distincie ntre litere mici i litere mari. Numele trebuie s nceap printr-un caracter alfabetic i nu poate fi un cuvnt cheie rezervat; poate s conin literele mari i mici ale alfabetului englez, cifrele 0 - 9 i caracterele $, _, #.
9

Un utilizator nu trebuie s defineasc dou obiecte cu acelai nume. n general este bine ca numele unui obiect s fie descriptiv i fr prescurtri excesive.

Categorii de instruciuni SQL

Instruciunile SQL sunt mprite n categorii, dup funciile pe care le ndeplinesc. Unii experi consider aceste categorii ca fiind limbaje separate sau sublimbaje. Totui, n SQL acestea au aceeai sintax de baz i respect aceleai reguli, aa c eu le consider categorii de instruciuni din acelai limbaj. Categoriile de instruciuni, descrise n seciunile urmtoare, sunt: Limbajul de definire a datelor (DDL sau LDD Data Definition Language) Limbajul de interogare a datelor (DQL-Data Query Language) Limbajul de manipulare a datelor (DML sau LMD - Data Manipulation Language) Limbajul pentru controlul datelor (DCL sau LCDData Control Language) Comenzile pentru controlul tranzaciilor (Transaction Control Commands)

Limbajul de definire a datelor (DDL)

Limbajul de definire a datelor (DDL - Data Definition Language) include instruciuni SQL care permit utilizatorului bazei de date s creeze i s modifice structura obiectelor bazei de date, cum ar fi tabele, vizualizri i indexuri. Instruciunile SQL care folosesc comenzile CREATE, ALTER i DROP sunt considerate parte a DDL. Este important s nelegei c instruciunile DDL afecteaz containerele care stocheaz datele n baza de date, nu datele propriu-zise. Ca urmare, exist instruciuni DDL pentru crearea, tergerea i modificarea tabelelor, dar nici una dintre aceste instruciuni nu ofer posibilitatea de a crea sau modifica rnduri de date din tabelele respective. Instruciunile LDD au efect imediat asupra bazei de date i nregistreaz informaia n dicionarul datelor. De asemenea, LDD contine instructiunile RENAME, TRUNCATE si COMMENT.

10

Limbajul de interogare a datelor (DQL) Limbajul de interogare a datelor (DQL - Data Query Language) include instruciuni SQL care permit obinerea datelor din baza de date. Dei reprezint o parte foarte important a limbajului SQL, DQL este format din instruciuni care folosesc o singur comand: SELECT. Unii furnizori i autori clasific instruciunile DQL i DML n aceeai categorie. Limbajul de manipulare a datelor (DML) Limbajul de manipulare a datelor (DML - Data Manipulation Language) include instruciuni SQL care permit utilizatorului bazei de date s adauge date n baza de date (sub forma rndurilor din tabele), s tearg date i s modifice datele existente n baza de date. Instruciunile SQL care folosesc comenzile INSERT, UPDATE i DELETE sunt considerate parte a DML. Limbajul pentru controlul datelor (DCL) Limbajul pentru controlul datelor (DCL Data Control Language) include instruciuni SQL care permit administratorilor s controleze accesul la datele din baza de date i folosirea diferitelor privilegii ale sistemului DBMS, cum ar fi privilegiul de oprire i pornire a bazei de date. Instruciunile SQL care folosesc comenzile GRANT si ALTER sunt considerate parte a DCL. Comenzile pentru controlul tranzaciilor O tranzacie n baza de date este un set de comenzi pe care utilizatorul bazei de date vrea sa le trateze ca pe o unitate funcionala de tip totul sau nimic, ntelegnd prin aceasta c intreaga tranzactie trebuie sa reuseasca sau sa esueze. Comenzile pentru cotrolul tranzaciilor (Transaction Control Commands ) nu respect cu exactitate sintaxa instruciunilor SQL , dar afecteaza puternic comportamentul instructiuunilor SQL incluse n tranzacii.

Lecia 1:Limbajul de definire a datelor

La nivel logic, o baz de date Oracle este alctuit din scheme. O schem este o mulime de structuri logice de date, numite obiecte. Ea aparine unui utilizator al bazei de date i poart numele su.

11

Specificarea bazelor de date i a obiectelor care le compun se realizeaz prin intermediul limbajului de definire a datelor (DDL). Definirea unui obiect presupune crearea, modificarea i suprimarea sa. Limbajul de definire a datelor cuprinde instruciunile SQL care permit realizarea acestor operaii (CREATE, ALTER, DROP). Instruciunile DDL au efect imediat asupra bazei de date i nregistreaz informaia n dicionarul datelor. De asemenea, DDL contine instructiunile RENAME, TRUNCATE si COMMENT. n cadrul unei scheme se pot defini obiecte de tip: tabel (table), vizualizare (view), vizualizare materializat (materialized view), secven (sequence), index (index), sinonim (synonym), grupare (cluster), procedur (procedure) i funcie (function) stocat, declanator (trigger), pachet stocat (package), legtur a bazei de date (database link), dimensiune (dimension) etc. Se vor prezenta n definirea i gestionarea Instruciunile CREATE, limbajului SQL numit Definition Language). continuare instruciunile SQL folosite pentru obiectelor dintr-o baz de date relaional. ALTER i DROP formeaz o categorie a limbaj de definire a datelor (DDL Data

Se prezint DDL naintea DQL, DML deoarece trebuiesc create obiectele bazei de date nainte de a insera date n baza de date. Convenii de sintax Instruciunile SQL DDL au mai multe opiuni dect alte instruciuni SQL. Urmtoarele convenii sunt pentru a prezenta sintaxa instruciunilor DDL: Cuvintele cheie i cuvintele rezervate din SQL sunt scrise cu majuscule, cum ar fi CREATE TABLE. Informaiile pe care ar trebui s fie furnizate la scrierea instruciunilor sunt scrise cu italic, cum ar fi nume_coloan. Elementele opionale sunt ncadrate n paranteze ptrate, cum ar fi [WITH TIME ZONE]. Opiunile dintr-o list de elemente posibile sunt separate de o bar vertical (simbolul logic pentru sau"), cum ar fi TABLE | VIEW | INDEX. Se pot ntlni uneori ca list de elemente opionale, cum ar fi [NULL | NOT NULL]. Elementele de grup care sunt explicate sau analizate ulterior pe componente (de obicei dup descrierea unui tip principal de instruciune) sunt ncadrate de caracterele mai mic dect" i

12

mai mare dect", cum ar fi <specificaii_pentru_coloan>. Un element care se poate repeta este urmat de trei puncte, cum ar fi. [,<restricie_pentru_tabel>...]. Toate celelalte simboluri, n special virgulele i parantezele, fac parte din sintaxa SQL obligatorie i, ca urmare, trebuie s fie incluse aa cum sunt scrise aici.

Tipuri de date
O coloan este cea mai mic unitate denumit care poate fi referit ntr-o baz de date relaional. Fiecare, coloan trebuie s aib asociate un nume unic i un tip de date. Un tip de date este o categorie pentru formatul folosit de o anumit coloan. Tipurile de date asigur cteva avantaje importante: Restricionarea, datelor din coloana respectiv la caracterele care au sens pentru tipul de date specificat. Asigurarea unor comportamente utile pentru utilizatorul datelor. De exemplu, dac se scade un numr dintr-un alt numr, se obine ca rezultat un numr; dar dac se scade o dat dintr-o alt dat, se obine ca rezultat diferena n zile dintre cele dou date calendaristice. Creterea eficienei sistemului SGBD la stocarea datelor din coloane. SQL accept trei categorii de tipuri de date: tipuri predefinite, tipuri construite i tipuri definite de utilizator. Tipurile de date predefinite sunt cele furnizate de ctre productor ca parte nativ a sistemului SGBD(vor fi tratate n continuare). Tipurile de date construite, cunoscute i ca tipuri de colecii, conin matrice sau seturi de tipuri de date predefinite, n scopul reprezentrii n SGBD a construciilor de date orientate spre obiect. Tipurile de date definite de utilizator permit utilizatorului bazei de date s defineasc propriile tipuri de date, adaptate unor scopuri specifice. Ultimele dou tipuri de date nu vor fi tratate , fiind prea complicate pentru inteniile cursului. Tipuri de date predefinite din standardul SQL:2003 Majoritatea implementrilorSQL accept cea mai mare parte parte

13

a tipurilor de date definite de standardul SQL:2003. Avem urmtoarele clase de tipuri: Tipuri de date pentru caractere, tipuri de date numerice, tipuri de date temporale i tipuri de date pentru obiecte mari. Tipuri de date pentru caractere Tipurile de date pentru caractere conin iruri de caractere, adic litere, cifre i alte simboluri permise de sistemul de calcul pe care se afl baza de date. Tipurile de date stardard pentru caractere sunt: Caracter cu lungime fix - Un ir de caractere cu lungime finit. Sintaxa SQL este: CHARACTER(lungime) | CHAR(lungime) Exemplu: CNP CHAR(13) Caracter naional - Acest tip de date poate fi folosit pentru traducerea irurilor de caractere n diferite limbi. Sintaxa SQL este: NATIONAL CHARACTER(lungime) | NCHAR(lungime) Exemplu: TITLU_FILM NCHAR(50) Caracter variabil - Un ir de caractere cu lungime variabil, specificnd lungimea maxim a irurilor de caractere stocate. Sintaxa SQL este: CHARACTER VARYING(lungime_maxim) | VARCHAR(lungime_maxim) Exemplu: NUME_CLIENT VARCHAR(125) Caracter naional variabil O variant a tipului de date pentru iruri de caractere cu lungime variabil, stocata ntr-un set de caractere al unei anumite limbi. Sintaxa SQL este: NATIONAL CHARACTER VARYING(lungime_maxim) | NVARCHAR (lungime_maxim) Exemplu: TITLU_FILM NVARCHAR(100) Tipuri de date numerice

14

Acestea sunt utile mai ales pentru atributele folosite n calcule. Toate tipurile numerice au o precizie (un numr de cifre). De asemenea unele tipuri numerice au i o scal (numrul de cifre aflate n dreapta punctului zecimal). Tipurile ntregi i tipurile numerice care include o scal sunt numite tipuri numerice exacte, n timp ce numerele reale care nu include o scal (numerele cu virgul mobil) sunt numite numerice aproximative. Tipurile numerice standard sunt: Numeric - Un tip numeric exact care include o precizie i o scal. Sintaxa SQL este: NUMERIC (precizie, scal) Exemplu: PLATA_PE_ORA_ANGAJAT NUMERIC(5,2) Zecimal - Un tip numeric exact care include o precizie i o scal. Diferena fa de Numeric, const n faptul c precizia este mai mare , avnd scopul de a permite maparea tipului peste un tip al al platformei pe care ruleaz SGBD. Sintaxa SQL este: DECIMAL(precizie, scal) Exemplu: PLATA_PE_ORA_ANGAJAT DECIMAL(5,2) ntreg - Un tip numeric exact care include numai precizia, scris INTEGER sau INT. Numerele ntregi nu au cifre zecimale, aa c scala nu este necesar, deoarece este ntotdeauna zero. Sintaxa SQL este: INTEGER (precizie) | INT (precizie) Exemplu: ID_CONT_CLIENT INTEGER ntreg mic - O variant a tipului INTEGER, scris SMALLINT, care stocheaz numere mai mici i, ca urmare, ocup mai puin spaiu. Sintaxa SQL este: SMALLINT (precizie) Exemplu: ID_CONT_CLIENT SMALLINT ntreg mare - O variant a tipului INTEGER, scris BIGINT, care stochez numere mai mari i ocup mai mult spaiu. Sintaxa SQL este: BIGINT (precizie) Exemplu: ID_CONT_CLIENT BIGINT Numr n virgul mobil - Un tip numeric aproximativ, cu precizia mai mare sau egal cu precizia specificat. Specificarea
15

preciziei este opional. Este scris FLOAT. Sintaxa SQL este: FLOAT (precizie) Exemple: RATA_DOBANDA FLOAT(16) RATA_DOBANDA FLOAT Numr real - Un tip numeric aproximativ, cu precizie definit de implementare. Sintaxa SQL este: REAL Exemplu: RATA_DOBANDA REAL Numr real cu precizie dubl - Un tip numeric aproximativ, cu precizie definit de implementare, dar mai mare sau egal cu precizia definit pentru tipul REAL. Sintaxa SQL este: DOUBLE PRECISION | DOUBLE Exemplu: RATA_DOBANDA DOUBLE PRECISION

Tipuri de date temporale (tipuri pentru date i ore)

Aceste tipuri stocheaz date care msoar timpul, ntr-un mod oarecare. Tipurile de date temporale conin urmtoarele componente, numite de standard, cmpuri (fields) : Numele cmpului (cuvnt cheie SQL) YEAR MONTH DAY HOUR MINUTE SECOND TIMEZONE_HOUR TIMEZONE_MINUTE Definiie Anul calendaristic, pe dou sau patru cifre Luna din an Ziua din lun Ora din zi Minutul din or Secunda din minut Valoarea orei cu diferena de fus orar Valoarea minutului cu diferena de fus orar

Cmpurile TIMEZONE_HOUR i TIMEZONE_MINUTE sunt incluse n toate tipurile de date temporale pentru care este specificat cuvntul cheie WITH TIMEZONE.

16

Tipurile de date temporale sunt: Data - O dat calendaristic, incluznd cmpurile YEAR, MONTH i DAY. Sintaxa SQL este: DATE [WITH TIMEZONE] Exemplu: DATA_NASTERE DATE Ora - Un tip de date pentru or, incluznd cmpurile HOUR, MINUTE i SECOND. Sintaxa SQL este: TIME [WITH TIMEZONE] Exemplu: TIMPUL_DEMARARE TIME Marc temporal - Un tip de date combinat pentru dat i or, incluznd cmpurile YEAR, MONTH, DAY, HOUR, MINUTE i SECOND. Sintaxa SQL este: TIMESTAMP [WITH TIMEZONE] Exemplu: DATA_TIMP_ NASTERE TIMESTAMP Interval - Un interval de timp, incluznd cmpurile specificate printr-un calificator de interval (internal qualifier), care reprezint precizia intervalului. Sintaxa SQL este: INTERVAL cmp_de_start TO cmp_de_sfrit|INTERVAL cmp Exemple: DURATA_PROIECT INTERVAL YEAR TO DAY TIMP_LUCRU INTERVAL HOUR TO MINUTE ZILE_VACANTA INTERVAL DAY Tipuri de date pentru obiecte mari- LONG Obiectele mari permit stocarea unor date care depesc cu mult posibilitile de stocare ale tipurilor de date prezentate pn acum, ajungnd deseori la dimensiuni de civa megaoctei. Deoarece manipularea obiectelor mari este un subiect avansat, care nu vace obiectul cursului, se vor prezenta aceste tipuri fr sintaxa lor. Obiect mare pentru caractere - Un obiect mare pentru caractere, scris n SQL sub foma CLOB. Obiect mare pentru caractere, n format naional - Un obiect mare pentru caractere, stocat ntr-o anumit limb, scris n SQL sub forma NLOB. Obiect mare binar - Un obiect mare care conine date binare, cum ar fi o imagine sau o secven sonor, scris n SQL sub forma BLOB.
17

Exist restricii referitoare la folosirea tipului de date LONG. ntr-un tabel poate s fie o singur coloan de tip LONG. Nu pot fi comparate dou iruri de caractere de tip LONG. O coloan de tip LONG nu poate fi parametru ntr-o procedur. O funcie nu poate ntoarce ca rezultat o valoare de tip LONG. O coloan de tip LONG nu poate fi folosit n clauzele WHERE, ORDER BY, GROUP BY, CONNECT. Operatorii sau funciile Oracle nu pot fi folosii n SQL pentru a modifica coloane de tip LONG. O coloan de tip LONG nu poate fi indexat. Un alt tip de date Exist un tip standard de date care nu este ncadrat n nici una dintre categoriile prezentate anterior: Boolean - Stocheaz o valoare logic adevrat sau fals. Sintaxa SQL este: BOOLEAN Exemplu: CLIENT_PREFERAT BOOLEAN

Extensii pentru tipuri de date i diferene fa de standard

Microsoft Access Microsoft Access este baza de date care respect n cea mai mic msur standardul, din toate sistemelm SGBD frecvent folosite. Tipurile de date acceptate de Microsoft Access sunt: Text - Echivalent cu tipul de date standard VARCHAR. Poate stoca pn la 255 de caractere. Memo - Conine iruri cu cel mult 65535 de caractere, dar este definit fr specificarea unei dimensiuni. Number - Echivalent cu tipul de date standard NUMERIC, dar precizia i scala sunt stabilite folosind meniul derulant Field Size (Mrimea cmpului). Numerele ntregi pot fi definite alegnd valoarea zero (0) pentru parametrul Decimal Places (Poziii zecimale). Date/Time - Aproximativ echivalent cu tipul de date standard TIMESTAMP, dar poate stoca orice date i or valide ntre anii 100 i 9999.

18

 Currency - Un tip de date numeric echivalent cu tipul NUMERIC (19,4), adic un numr cu 15 cifre n stnga punctului zecimal i cel mult 4 cifre n dreapta punctului zecimal. AutoNumber - Un cmp pe 4 sau 16 octei (n funcie de valoarea Field Size) incrementat automat cu o unitate de fiecare dat cnd n tabel este inserat un nou rnd. Yes/No - Aproximativ echivalent cu tipul de date standard BOOLEAN. Totui, Microsoft Access permite ca acest tip de date s fie formatat ca Yes/No, On/Off sau True/False. OLE Object - Similar cu tipul de date standard BLOB, acest tip de date permite stocarea unui obiect Microsoft OLE cu dimensiunea maxim de 1GB (gigaoctet). Hyperlink Un tip de date specializat care poate conine o adres web din Internet. Lookup wizard - Un tip de date specializat care creeaz o legtur ntre o coloan din tabelul curent i coninutul unei coloane dintrun alt tabel. Acest tip de date poate fi folosit pentru legarea dinamic a tabelelor la crearea formularelor n Microsoft Access.

Oracle
Oracle SQL accept urmtoarele tipuri de date standard: BLOB -Obiecte binare mari, cu dimensiunea maxim de (4GB-1) x (dimensiunea unui bloc din baza de date). CHAR - iruri de caractere cu lungime fix, coninnd cel mult 2000 de octei. CLOB - Obiecte de tip caracter mari, cu dimensiunea maxim de (4GB- 1) x (dimensiunea unui bloc din baza de date). DATE - Funcioneaz ca tipul standard de date DATE, dar din punct de vedere tehnic seamn mai mult cu tipul DATETIME, deoarece poate stoca att data, ct i ora. Accept date de la 1 ianuarie 4712 .e.n. la 31 decembrie 9999 e.n. Opional, poate fi inclus i ora, n ore, minute i secunde. Dac partea opional este omis, este stocat cu valoarea zero, echivalent cu miezul nopii. DECIMAL - Implementat ca NUMBER(precizie,scal). DOUBLE PRECISION - Implementat ca NUMBER. FLOAT - Implementat ca NUMBER. INTEGER - Implementat ca NUMBER(38).

19

 INTERVAL - Un interval de timp, dar sunt acceptate din standard numai variantele INTERVAL YEAR TO MONTH i INTERVAL DAY TO SECOND. NCHAR - iruri de caractere cu lungime fix ntr-o limb naional, cu dimensiunea maxim de 2000 de octei. NCLOB - iruri de caractere cu lungime fix ntr-o limb naional, cu dimensiunea maxim de (4GB-1) x (dimensiunea unui bloc din baza de date). NUMERIC - Implementat NUMBER(precizie,scal). NVARCHAR - Date de tip caracter cu lungime variabil ntr-o limb naional, cu dimensiunea maxim de 4000 de octei . REAL - Implementat ca NUMBER. SMALLINT - Implementat ca NUMBER(38). TIMESTAMP - Data i ora n ani, luni, zile, ore, minute i secunde. VARCHAR - Date de tip caracter cu lungime variabil, coninnd cel mult 4000 de caractere. Oracle ofer urmtoarele extensii la tipurile de date standard: BFILE - O valoare de localizare a unui fiier binar de dimensiuni mari, stocat n afara bazei de date. LONG - Date de tip caracter cu lungime variabil, cu dimensiunea maxim de 2GB. LONG RAW - Date binare, cu dimensiunea maxim de 2GB. NUMBER - Date numerice, cu cel mult 38 de cifre. Poate stoca valori ntregi sau n virgul mobil. NVARCHAR2 - Identic cu NVARCHAR. RAW - Date binare, cu dimensiunea maxim de 2000 de octeli. ROWID - ir de caractere codat Base 64*, reprezentnd adresa unic a unui rnd n tabelul din care face parte. UROWID - ir de caractere codat Base 64, reprezentnd adresa logic a unui rnd ntr-un tabel indexat. VARCHAR2 - Identic cu VARCHAR, dar Oracle recomand folosirea folosirea acestui tip n loc de VARCHAR, deoarece Oracle e posibil s schimbe la un moment dat implementarea tipului VARCHAR. Precizari si exemple Pentru memorarea datelor numerice, tipurile cele mai frecvent folosite sunt: NUMBER, INTEGER, FLOAT, DECIMAL.

20

Pentru memorarea irurilor de caractere, cele mai frecvent tipuri de date utilizate sunt: CHAR, NCHAR, VARCHAR2 , NVARCHAR2 i LONG. Informaii relative la timp sau dat calendaristic se obin utiliznd tipul DATE. Pentru fiecare dat de tip DATE sunt depuse: secolul, anul, luna, ziua, ora, minutul, secunda. Pentru o coloan de tip DATE sistemul rezerv 7 bytes, indiferent dac se memoreaz doar timpul, sau doar data calendaristic. Formatul implicit al datei se definete cu ajutorul parametrului de iniializare NLS_DATE_FORMAT. n general, acest parametru este setat la forma DD-MON-YY. Dac nu este specificat timpul, timpul implicit este 12:00:00. Oracle9i introduce noi tipuri de date pentru timp: TIMESTAMP(precizie_fraciuni_secund) cuprinde valori pentru anul, luna i ziua unei date calendaristice, dar i valori pentru or, minut, secund INTERVAL YEAR (precizie_an) TO MONTH stocheaz o perioad de timp specificat n ani i luni, unde precizie_an reprezint numrul de cifre din cmpul YEAR. INTERVAL DAY (zi) TO SECOND (prec_frac_sec) stocheaz o perioad de timp reprezentat n zile, ore, minute i secunde. Exemple S se creeze un tabel cu trei coloane, inceput, durata_1, durata_2. Coloana inceput va cuprinde valori ce reprezint momente de timp, inclusiv fraciunile de secund corespunztoare. Valorile coloanei durata_1 vor fi intervale de timp specificate n numr de zile, ore, minute i secunde. Coloana durata_3 va conine intervale de timp precizate n numr de ani i luni. S se insereze o nregistrare n acest tabel. CREATE TABLE TIMP ( inceput TIMESTAMP, durata_1 INTERVAL DAY(2) TO SECOND(3), durata_2 INTERVAL YEAR TO MONTH ); Exemple date inserate 1. INSERT INTO timp
21

VALUES (TIMESTAMP '2009-10-31 09:26:50.30', INTERVAL '23 7:44:22' DAY TO SECOND, INTERVAL '19-02' YEAR TO MONTH);

Ex. 2 INSERT INTO timp VALUES (TIMESTAMP '2010-02-20 09:20:40.20', INTERVAL '23 7:44:22' DAY TO SECOND, INTERVAL '200-02' YEAR TO MONTH);

INTERVAL '200-02' da eroare, deoarece implicit precizia pentru an este 2, iar 200 are 3 digiti Ex.3 INSERT INTO timp VALUES (TIMESTAMP '2010-01-25 09:26:50.30', INTERVAL '23 7:44:22' DAY TO SECOND, INTERVAL '20-100' YEAR TO MONTH);

22

INTERVAL '20-100' eroare, deoarece 100 de luni adauga ani Ex.4 INSERT INTO timp VALUES (TIMESTAMP '2010-01-25 09:26:50.30', INTERVAL '23 2:2:2' DAY TO SECOND, INTERVAL '20-10' YEAR TO MONTH);

Ex.5 INSERT INTO timp VALUES (TIMESTAMP '2010-01-25 09:26:50.30', INTERVAL '23 2:2:2' DAY TO SECOND, INTERVAL '20-12' YEAR TO MONTH);

INTERVAL '20-12' eroare deoarece 12 luni fac un an si depasesc intervalul de 20 ani Ex.6
23

INSERT INTO timp VALUES (TIMESTAMP '2010-01-25 09:26:50.30', INTERVAL '23 2:2:2' DAY TO SECOND, INTERVAL 120 MONTH); Se observ ca executnd instructiunea: SELECT * from timp ; Ca durata_2 are valoarea 10;

Ex.7 INSERT INTO timp VALUES (TIMESTAMP '2010-01-25 09:26:50.30', INTERVAL '360' SECOND, INTERVAL 144 YEAR);

24

Se observa c inregistrarea introdusa are : Durata_1 este de 6 min(360 sec) si Durata_2 de 12 ani(144 de zile) Ex.8 INSERT INTO timp VALUES (TIMESTAMP '2010-01-25 09:00:00.30', INTERVAL '20' DAY(2), INTERVAL 10 YEAR);

Se observa c inregistrarea introdusa are : Durata_1 de 20 zile si 0 secunde( fiind un INTERVAL DAY TO SECOND) si Durata_2 este 10 ani si 0 luni (fiind un INTERVAL YEAR TO MONTH)

25

Exemplu CREATE TABLE exemplu (durata INTERVAL YEAR(3) TO MONTH); INSERT INTO exemplu VALUES (INTERVAL '120' MONTH); SELECT TO_CHAR(SYSDATE+durata, 'DD-monFROM exemplu; YYYY')

Exemplu CREATE TABLE noi_carti (codel NUMBER, start_data TIMESTAMP); INSERT INTO noi_carti VALUES (1,TIMESTAMP '2009-10-31 09:26:50.30'); SELECT codel ,start_data FROM noi_carti;

INSERT INTO noi_carti VALUES (5, timestamp '12-02-08 0:0:0');

26

Pentru informatii de tip TIMESTAMP, numarul maxim de digiti pentru fractiuni de secunda este 9, implicit este 6. Rezultatele cererii: 1 31-OCT-09 09.26.50.300000 AM 5 08-FEB-12 12.00.00.000000 AM Pentru informatii de tip DATE, formatul implicit ar fi fost MON-RR Valori valide pentru date calendaristice De la -4712 la 9999 (cu excepia YEAR anului 0). MONTH De la 01 la 12. De la 01 la 31 (limitat de valorile cmpurilor MONTH i YEAR, DAY corespunztor regulilor calendarului curent). HOUR De la 00 la 23. MINUTE De la 00 la 59. De la 00 la 59.9(n), unde 9(n) SECOND este precizia fraciunilor de secund. De la 12 la 13 (prevede TIMEZONE_HOUR schimbrile datorate trecerilor la ora de var sau iarn). TIMEZONE_MINU De la 00 la 59. TE Cmp DD-

Valori valide pentru intervale Orice valoare ntreag. De la 0 la 11. Orice valoare ntreag. De la 0 la 23. De la 0 la 59. De la 0 la 59.9(n), unde 9(n) este precizia fraciunilor de secund. Nu se aplic. Nu se aplic.

Sistemul Oracle permite construcia de expresii folosind valori de tip dat calendaristic i interval. Operaiile care pot fi utilizate n aceste expresii i tipul rezultatelor obinute sunt urmtoarele: Data + Interval, Data Interval, Interval + Data, iar rezultatul este de tip dat calendaristic; Data Data, Interval + Interval, Interval Interval, Interval * Number, Number * Interval, Interval / Number, iar rezultatul este de tip interval.

27

Modele de format
Un model de format este un literal caracter care descrie formatul valorilor de tip DATE sau NUMBER stocate ntr-un ir de caractere. Atunci cnd se convertete un ir de caractere ntr-o dat calendaristic sau ntr-un numr, modelul de format indic sistemului cum s interpreteze irul respectiv. n instruciunile SQL se poate folosi un model de format ca argument al funciilor TO_CHAR i TO_DATE. n felul acesta se poate specifica formatul folosit de sistemul Oracle pentru a returna sau a stoca o valoare n/din baza de date. Un model de format nu schimb reprezentarea intern a valorii n baza de date. O parte dintre elementele cel mai frecvent ntlnite ale unui format de tip numeric sunt sintetizate n tabelul urmtor. Element Exemplu Descriere
, (virgul) 9,999 Plaseaz o virgul n poziia specificat. ntr-un model de format numeric pot fi precizate mai multe virgule, dar o virgul nu poate aprea n partea dreapt a punctului zecimal. Plaseaz un punct zecimal n poziia specificat. ntr-un format numeric, se poate specifica cel mult un punct zecimal. Include semnul $ n faa unei valori. Plaseaz zerouri n faa sau la sfritul valorii. ntoarce valoarea cu numrul specificat de cifre. Valoarea va avea un spaiu, respectiv un minus n fa dac este pozitiv, respectiv negativ. Plaseaz n poziia specificat simbolul ISO pentru monede(valoarea curent a parametrului NLS_ISO_CURRENCY). Plaseaz n poziia specificat caracterul zecimal, care este valoarea curent a parametrului NLS_NUMERIC_CHARACTER. Valoarea implicit este punctul. Se poate specifica cel mult un caracter zecimal ntr-un model de format numeric. Returneaz o valoare folosind notaia tiinific. ntoarce n poziia specificat simbolul monedei locale (valoarea curent a parametrului NLS_CURRENCY). Plaseaz semnul minus la sfritul valorilor negative i un spaiu la sfritul celor pozitive. Acest element poate fi specificat numai pe ultima poziie a modelului de format numeric. Plaseaz semnele plus sau minus la nceputul sau la sfritul valorii. Acest element poate aprea doar pe prima

. (punct) $ 0 9

99.99 $9999 0999; 9990 9999

C999

99D99

EEEE L

9.9EEEE L999

MI

9999MI

S9999; 9999S

28

sau ultima poziie a modelului de format numeric.

Modelele de format pentru date calendaristice pot fi utilizate n cadrul urmtoarelor funcii de conversie: TO_DATE, pentru a converti o valoare de tip caracter, care este ntr-un alt format dect cel implicit, ntr-o valoare de tip DATE; TO_CHAR, pentru a converti o valoare de tip DATE, care este ntr-un alt format dect cel implicit, ntr-un ir de caractere. SYSDATE, pentru aflarea datei curente. De exemplu SELECT SYSDATE FROM dual; Un model de format pentru date calendaristice este alctuit dintrunul sau mai multe elemente specifice. Scrierea cu litere mari sau mici a cuvintelor, abrevierilor sau a numeralelor romane este respectat n elementul de format corespunztor. De exemplu, modelul de format DAY produce cuvinte cu majuscule, cum ar fi FRIDAY, iar Day i day au ca rezultat Friday, respectiv friday. ntr-un model de format pentru date calendaristice se pot preciza semne de punctuaie i literale caracter, incluse ntre ghilimele. Toate aceste caractere apar n valoarea returnat pe locul specificat n modelul de format.
Element AD sau A.D. BC sau B.C. D DAY DD DDD DY FF HH sau HH12 HH24 MI MM MON Explicaie Indicatorul AD (Anno Domini) cu sau fr puncte. Indicatorul BC (Before Christ) cu sau fr puncte. Numrul zilei din sptmn (1-7). Duminica este considerat prima zi a sptmnii. Numele zilei completat cu spaii, pn la lungimea de 9 caractere. Numrul zilei din lun (1-31). Numrul zilei din an (1-366). Numele zilei din sptmn, printr-o abreviere de 3 litere. Fraciunile de secund. Ora din zi (1-12). Ora din zi (0-23). Minutele din or (0-59). Luna din an (01-12). Numele lunii, printr-o abreviere de 3 litere.

29

MONTH RM RR RRRR SS SSSSS TZH TZM Y,YYY YYYY sau SYYYY YYY, YY sau Y

Numele lunii completat cu spaii, pn la lungimea de 9 litere. Luna n cifre romane (I-XII). Anul cel mai apropiat de data curent. Accept intrarea att cu 2, ct i cu 4 cifre. Dac anul de intrare se d cu 2 cifre, furnizeaz acelai lucru ca i formatul RR. Secundele din minut (0-59). Secundele trecute de la miezul noptii (0-86399). Ora regiunii. Minutul regiunii. Anul scris cu virgul dup prima cifr. Anul cu 4 cifre. Ultimele cifre ale anului.

YEAR sau SYEAR Anul n litere (S prefixeaz anii i.Hr. cu semnul minus).

Modificatorii FM i FX pot fi utilizai n modelele de format din cadrul funciei TO_CHAR, controlnd completarea cu spaii i verificarea exact a formatelor. Un modificator poate s apar ntr-un model de format de mai multe ori. n acest caz, efectele sale sunt active pentru poriunea din model care ncepe la prima apariie i apoi dezactivate pentru poriunea din model care urmeaz celei de-a doua apariii .a.m.d. Modificatorul FM (Fill Mode) suprim completarea cu spaii n valoarea returnat de funcia TO_CHAR, iar FX (Format eXact) impune corespondena exact dintre argumentul de tip caracter i modelul de format precizat pentru data calendaristic respectiv. Exemplu: SELECT nume, TO_CHAR(data_ang,Month FMDD,YYYY) angajare FROM angajati WHERE TO_CHAR(data_ang, YYYY)=2009; Nume Pop Ene Angajare January 21,2009 October 10,2009

Exemplu SELECT nume, TO_CHAR(data_ang, DDTH of Month YYYY) angajare FROM angajati WHERE TO_CHAR(data_ang, YYYY)=2009;

30

Nume Pop Ene

Angajare 21st of January 2009 10TH of October 2009

Exemplu SELECT TO_CHAR(data_ang, fmDDspth Month.Year) angajare FROM angajati WHERE id_ang=100; Angajare Twenty_NineTH July, Two Thousand Nine Exemplu SELECT sesiune incepe pe || TO_DATE(20-09-2010,DD-MMYYYY) from dual; Sesiunea incepe pe 20-09-2010 (Afieaz formatul standard pentru dat) Valoarea null, reprezentnd lipsa datelor, nu este egal sau diferit de nici o alt valoare, inclusiv null. Totui, exist dou situaii n care sistemul Oracle consider dou valori null ca fiind egale: la evaluarea funciei DECODE i dac valorile null apar n chei compuse. Dou chei compuse care conin valori null sunt considerate identice dac toate componentele diferite de null sunt egale. Pseudocoloane

O pseudocoloan se comport ca i o coloan a unui tabel, dar nu este stocat efectiv ntr-un tabel. Se pot face interogri asupra pseudocoloanelor, dar nu se pot insera, actualiza sau terge valorile acestora. LEVEL returneaz nivelul liniilor rezultat ale unei cereri ierarhice. CURRVAL i NEXTVAL sunt pseudocoloane utile n lucrul cu secvene i sunt tratate n seciunea corespunztoare acestora. ROWID returneaz adresa unei linii din baza de date, furniznd modul cel mai rapid de a accesa linia respectiv. n sistemul Oracle, valorile acestei pseudocoloane conin urmtoarele informaii necesare pentru a localiza o linie: numrul obiectului, blocul de date, fiierul de date, linia n cadrul blocului de date. Valorile pseudocoloanei ROWID sunt de tipul ROWID sau UROWID. ROWNUM returneaz numrul de ordine al liniilor rezultate n

31

urma execuiei unei cereri. Pseudocoloana poate fi utilizat pentru a limita numrul de linii returnate. Dac este folosit clauza ORDER BY ntr-o subcerere, iar condiia n care apare ROWNUM este plasat n cererea de nivel superior, atunci condiia va fi aplicat dup ordonarea liniilor. Exemplu: S se afieze informaii despre operele de art avnd cele mai mici 10 coduri. SELECT * FROM (SELECT * FROM opera ORDER BY WHERE ROWNUM < 11;

cod_opera)

Instruciuni DDL (Data Definition Language) Instruciunile DDL (Data Definition Language) definesc obiectele bazei de date, dar nu insereaz i nu actualizeaz date n obiectele respective. n SQL, exist trei comenzi de baz pentru instruciunile DDL: CREATE - Creeaz n baza de date un nou obiect, de tipul specificat n instruciune : CREATE DATABASE, CREATE TABLE, CREATE INDEX i CREATE VIEW. ALTER - Modific definiia unui obiect existent n baza de date, de tipul specificat n instruciune : ALTER TABLE, ALTER DATABASE, ALTER SYSTEM, ALTER USER, ALTER SESSION. D R O P - terge (distruge) un obiect existent n baza de date, de tipul specificat n instruciune. Instruciunea CREATE DATABASE Definirea unei baze de date difer destul de mult de la o implementare la alta. Sintaxa general pentru instruciunea CREATE DATABASE este: CREATE DATABASE nume bazadedate [opiuni_specifice _productorul] n Oracle, instruciunea CREATE USER creaz n baza de date o schem, cere este aproximativ echivalent cu o baz de date.
32

Standardul SQL prevede i o instruciune CREATE SCHEMA, care permite crearea unor grupuri de obiecte din baza de date, pentru simplificarea administrrii.
FM IL F M IL _ID F M O _G N IL _C D E M A O _R T G PA _C D A IN FM UE IL _N M R T IL R T H E A _P E _V S R T IL R T V E A _P E _D D A _P O U N RDS P K F1 K F2 K

MA _R T G P A A IN M A _C D A IN P A O _R T G M A _D S R R _V R T P A E C IE E A S E

P K

FM E IL _G N F M O _G N IL _C D E F M E C IE E E IL _D S R R _G N

P K

F M IM A IL _L B F M IL _ID C D IM A O _L B P ,F 1 KK P ,F 2 KK

F M O II IL _C P F M IL _ID N M R O IE U A _C P D T _C M A A E AA U P R R D T _V N A E AA A Z R F R A _M D O M T E IA

P ,F 1 KK P K

F M C IR R IL _IN H IE E F M IL _ID P ,F 1 KK N M R O IE U A _C P P ,F 1 KK T A Z C IE R N A T _ID P ,F 2 KK D T _IN O R E E AA T A C R C S _IN H IE E O T C IR R C S _IN A Z R _S U IE D R O T T R IE E A _P R E E D T _R T R A E AA E U N R

L B IM A C D IM A O _L B N M _L B U E IM A P K C IE T O T L N _C N C IE T O T L N _C N _ID P K C IE T O D D L N _H L _IN D T _IN C IS AA S R D T _T R IN T AA E M A C IE T E O IT U A L N _D P Z _S M C R _C E IT A O A _IN IC A D R D _L _D S R D C P _IN H IE E E M _IN IC O IL C IR R _P R IS D C IE T R N A T L N _T A Z C IE T A Z C IE R N A T _ID C IE T O T L N _C N _ID A G JA _P R O N _ID NA T ES AA T A Z C IE A A R N A T _D T V N A I_T X AZR AA P K F1 K

C IE T O _P R O N L N _C D E S A A C IE T O T L N _C N _ID P R O N _ID ES AA

P ,F 1 KK P ,F 2 KK

P RO N ES AA P R O N _ID ES AA P R O N _P E U E E S AA RNM P R O N _N M _M O IU E S A A U E IJL C P R O N _N M ES AA U E P R O N _A R S _1 E S A A DEA P R O N _A R S _2 E S A A DEA P R O N _A R S _O A E S A A DEA R S P R O N _A R S _JU E _P O E S A A D EA DT R V P R O N _A R S _C D O T L E S A A D E A O _P S A P R O N _A R S _T R E S A A DEA AA P R O N _T L F N E S A A E EO N S E E AA A T R _D T M A T _D T O R E AA

P K

A G JA NA T P R O N _ID ES AA S P R IS R E S A A U E V O _P R O N _ID A G JA _T X _ID NA T AA A G JA _JO _C T G R N A T B A E O IE A G JA _R T _P _O A N A T AA E R A G JA E A A N A R _D T IN H E E A A C ID R _D T

P ,F 1 KK

33

Exemplu de Diagrama conceptual Exemplele din lucrare se refer la un model de gestiune a operelor de art dintr-un muzeu. Diagrama entitate-relaie (E/R) corespunztoare modelului analizat este prezentat n figura 2.1. Schemele relaionale corespunztoare diagramei conceptuale sunt: OPERA(cod_opera#, tip, titlu, cod_artist, data_crearii, data_achizitiei, valoare, cod_galerie, cod_sala, material, stil, dim1, dim2, stare); GALERIE(cod_galerie#, nume_galerie, nume_cladire, adresa); SALA(cod_sala#, cod_galerie#, nume_sala, suprafata); SECURITATE(cod_opera#, sistem#, descriere, valoare, data_inst, firma, executant); POLITA_ASIG(cod_opera, cod_polita#, descriere, firma, valoare, semnat_contract); SPECIALIST(cod_specialist#, nume, prenume, experienta, autorizatie, tip, loc); ARTIST(cod_artist#, nume, prenume, an_nastere, an_moarte, nationalitate, observatii); SURSA_BIBLIO(cod_sursa#, tip, titlu); ARTICOL(cod_sursa#, nume_revista, nr_revista, data, pag_revista); CARTE(cod_sursa#, an, editura, ISBN); AUTOR(cod_autor#, nume, prenume, descriere, job, adresa); EXPOZITIE(cod_expo#, nume_expo, tip); STUDIAZA(cod_opera#, cod_specialist#, data#, operatia, metode, rezultat, plata); MENTIONATA_IN(cod_opera#, cod_sursa#, pagina#); FIGUREAZA_IN(cod_opera#, cod_expo#, cond_speciale, localitate, data_inceput); EDITATA_DE(cod_sursa#, cod_autor#); ORGANIZATA_DE(cod_organizator#, cod_expozitie#); ORGANIZATOR(cod_organizator#, nume, tip_organizator, adresa). Numele atributelor corespunztoare relaiilor menionate sunt sugestive, astfel nct semnificaia lor este evident. Se pot face urmtoarele precizri: cmpul tip din tabelul opera este un ir de caractere ce reprezint categoria n care se ncadreaz opera de art respectiv (pictur, sculptur, grafic, tapiserie etc.);

34

 material este un cmp de tip ir de caractere, ale crui valori specific materialul din care a fost conceput opera de art (hrtie, pnz, bronz, aram, piatr etc.); stil este un atribut de tip ir de caractere ce precizeaz stilul n care se ncadreaz opera de art respectiv (clasic, renascentist, contemporan, impresionist etc.); dim1, dim2 sunt coloane numerice care specific dimensiunile operei; stare este un atribut de tip ir de caractere care precizeaz starea fizic a operei de art respective (medie, bun, foarte bun etc.); cmpul tip din tabelul specialist precizeaz calificarea unui specialist (expert, restaurator, evaluator etc.); loc reprezint ara care a emis autorizaia corespunztoare unui specialist; operatia specific aciunea la care este supus opera de art (lipire, retuare, curare etc.); atributul metode specific procedeele utilizate n realizarea operaiei (infraroii, ultrasunete, raze X etc.); cmpul rezultat reine informaii asupra expertizei efectuate (dac opera de art este un fals, nivelul restaurrii etc.); cmpul tip din tabelul sursa_biblio precizeaz categoria publicaiei n care apar referine la opera de art respectiv (articol, studiu, monografie etc.); cmpul job specific profesia autorului unei surse bibliografice (profesor, expert, artist, jurnalist etc.); atributul observatii conine informaii referitoare la artiti (pseudonim, curentul artistic de care aparin etc.); cmpul tip din tabelul expozitie precizeaz categoria din care face parte o expoziie (fix, itinerant, temporar etc.).

35

GALERIE cod_galerie #

inclusa_in

M(1)

SALA cod_sala# cod_galerie#

1 cuprinsa_in

SECURITATE
protejata_prin M(0)

M(1)

cod_opera# sistem#

ARTIST cod_artist#

creata_de

M(1)

OPERA
1 asigurata_de M(0)

cod_opera#
M(1) M(1) mentionata_in M(1) studiaza

POLITA_ASIG cod_polita#

M(0) M(0)

SURSA_BIBLIO cod_sursa# tip

SPECIALIST cod_specialist#

ARTICOL

figureaza_in

CARTE

M(0)

EXPOZITIE
M(1) editata_de

M(1)

organizata_de

M(1)

ORGANIZATOR cod_organizator#

cod_expo#

M(1)

AUTOR cod_autor #

Figura 2.1. Diagrama E/R a modelului de gestiune a operelor de art dintr-un muzeu

36

Asupra modelului considerat sunt definite anumite restricii. Conform acestora, o oper de art poate: avea fie un singur autor, fie autor necunoscut; avea mai multe sisteme de securitate instalate; fi asigurat la mai multe firme; fi menionat n aceeai surs bibliografic, la pagini diferite.

Instruciunea CREATE TABLE CREATE TABLE este una din instruciunile fundamentale din SQL. Modelul relaional cere ca toate datele stocate s fie ancorate ntrun tabel, aa c posibilitatea de a stoca orice ntr-o baz de date ncepe ntotdeauna cu crearea unui tabel. Crearea unui tabel const din generarea structurii sale, adic atribuirea unui nume tabelului i definirea caracteristicelor sale (se definesc coloanele, se definesc constrngerile de integritate, se specific parametrii de stocare etc.). n Oracle9i tabelele pot fi create n orice moment, chiar i n timpul utilizrii bazei. Structura unui tabel poate fi modificat online. Nu este necesar s se specifice dimensiunea acestuia. Totui, din considerente administrative, este important s se cunoasc estimativ ct spaiu va utiliza tabelul. Sintaxa de baz pentru instruciunea CREATE TABLE este: CREATE TABLE nume_tabel (<definiie_coloan> [,<definiie_coloan> ...]) [,<restricietabel>... ]; Definirea coloanelor n SQL DDL Sintaxa de baz folosit pentru definirea coloanelor unui tabel este: <definiie_coloan> nume coloan tip_de_date [DEFAULT expresie] [NULL | NOT NULL]

37

[<restricie_coloan>] Componentele din definiia unei coloane sunt: Numele coloanei - Numele coloanei trebuie s fie unic n cadrul tabelului. Tipul de date - Tipul de date trebuie s fie un tip de date valid pentru implementarea SGBD Restrictiile coloanei care sunt prezentate n continuare Structura unui tabel poate fi creat n urmtoarele patru moduri: fr a indica cheile; indicnd cheile la nivel de coloan; indicnd cheile la nivel de tabel; prin copiere din alt tabel.

Exemplu : Gestiunea activitilor de mprumut dintr-o bibliotec

M(1) CARTE codel# titlu autor pret nrex coded imprumuta M(0)

CITITOR codec# nume dep

M(0) apartine

DOMENIU coded# intdom

1. Crearea structurii unui tabel fr a indica cheile: CREATE TABLE (codel titlu autor pret nrex coded carte CHAR(5), VARCHAR2(30), VARCHAR2(30), NUMBER(8,2), NUMBER(3), CHAR(5));

2. Crearea structurii unui tabel indicnd cheile la nivel coloan:

38

CREATE TABLE (codel titlu autor pret nrex coded

carte CHAR(5) PRIMARY KEY, VARCHAR2(30), VARCHAR2(30), NUMBER(8,2), NUMBER(3), CHAR(5) NOT NULL REFERENCES domeniu(coded));

Constrngerea de cheie primar sau extern ce presupune? CREATE TABLE carte (codel CHAR(5) PRIMARY KEY, titlu VARCHAR2(30), autor VARCHAR2(30), pret NUMBER(8,2), nrex NUMBER(3), coded CHAR(5) NOT NULL REFERENCES domeniu(coded) ON DELETE CASCADE); CREATE TABLE domeniu (coded CHAR(5) PRIMARY KEY, den_dom VARCHAR2(30)); CREATE TABLE cititor (codec CHAR(5) PRIMARY KEY, den_cititor VARCHAR2(30));

Opiunea ON DELETE CASCADE specific c suprimarea oricrui domeniu de carte din tabelul domeniu este autorizat i implic suprimarea automat a tuturor crilor din domeniul respectiv care se gsesc n tabelul carte. 3. Crearea structurii unui tabel indicnd cheile la nivel de tabel: CREATE TABLE carte (codel CHAR(5), titlu VARCHAR2(30), autor VARCHAR2(30), pret NUMBER(8,2), nrex NUMBER(3), coded CHAR(5) NOT NULL, PRIMARY KEY (codel), FOREIGN KEY (coded)

39

REFERENCES domeniu (coded)); Dac cheia primar are mai mult de o coloan atunci cheile trebuie indicate la nivel de tabel. CREATE TABLE imprumuta (codel CHAR(5), codec CHAR(5), dataim DATE DEFAULT SYSDATE, datares DATE, dataef DATE, PRIMARY KEY (codel, codec, dataim), FOREIGN KEY (codel) REFERENCES carte(codel), FOREIGN KEY (codec) REFERENCES cititor(codec)); INSERT INTO domeniu VALUES(I, Informatica); INSERT INTO carte VALUES(bnat1, Baza_de_Date, Popescu_Ioana, 300.50, 100,I); 4. Crearea structurii unui tabel prin copiere din alt tabel: CREATE TABLE carte_info AS SELECT codel, titlu, autor FROM carte WHERE coded = I;

40

Constrngeri
Constrngerea este un mecanism care asigur c valorile unei coloane sau a unei mulimi de coloane satisfac o condiie declarat. Unei constrgeri i se poate da un nume unic. Dac nu se specific un nume explicit atunci sistemul automat i atribuie un nume de forma SYS_Cn, unde n reprezint numrul constrngerii. Constrngerile pot fi terse, pot fi adugate, pot fi activate sau dezactivate, dar nu pot fi modificate. Restriciile coloanelor Restriciile unei coloane limiteaz ntr-un mod oarecare valorile ce pot fi stocate ntr-o coloan a unui tabel. Restriciile coloanelor pot avea oricare dintre urmtoarele forme: Exemplu, crearea tabelului CONT_CLIENT, din baza de date a magazinului de produse video. CREATE TABLE CONT_CLIENT ( ID_CONT_CLIENT INTEGER NOT NULL, STARE_CONT_CLIENT CHAR(1) DEFAULT N NOT NULL CHECK (STARE_CONT_CLIENT IN (Y, N)), DATA_INSCRIERE DATE NOT NULL, DATA_INCHEIERE DATE NULL, SUMA_DEPOZIT_CLIENT NUMERIC(5,2) NULL, IND_CREDIT_CARD CHAR(1) NOT NULL CHECK (IND_CREDIT_CARD IN (Y, N)), INDIC_PERMIS_INCHIRIERE_COPIL CHAR(1) NOT NULL CHECK(INDIC_PERMIS_INCHIRIERE_COPIL IN(Y,N)), PRIMARY KEY (ID_CONT_CLIENT) ); Descriere tabel:
ID_CONT_CLIENT - cheie primara STARE_CONT_CLIENT de tip DA/NU, care indica daca un cont este sau nu blocat.(inchirierile nu sunt permise pt conturile blocate) DATA_INSCRIERE - data la care s-a deschis contul in magazin DATA_INCHEIERE - daca contul a fost inchis contine data; daca contul e activ contine NULL
41

SUMA_DEPOZIT_CLIENT pt clientii care nu au carte de credit, suma lasata ca depozit in magazin IND_CREDIT_CARD - de tip DA/NU, care indica daca un client a lasat inf despre carte de credit, pt a garanta platile asociate contului. INDIC_PERMIS_INCHIRIERE_COPIL - de tip DA/NU, care indica daca uncopil<18 ani are voie sa inchirieze filme folosind acest cont

Clauza DEFAULT - O expresie care este aplicat coloanei atunci cnd n tabel este inserat un nou rnd, care nu conine o valoare explicit pentru coloana respectiv. Expresia poate fi orice expresie valid. Sintaxa SQL cu o clauz DEFAULT este: [DEFAULT expresie] Exemplu: STARE_CONT_CLIENT CHAR(1) DEFAULT 'N' NOT NULL (la creare are val N , adica contul nu e blocat) Restricia NULL | NOT NULL - Specificarea cuvntului cheie NULL permite stocarca valorilor nule ntr-o coloan, n timp ce NOT NULL nu permite stocarca valorilor nule n coloana respectiv. O restricie NOT NULL poate fi scris i sub forma unei restricii CHECK cu condiia IS NOT NULL. Sintaxa SQL i cteva exemple: NULL | NOT NULL Exemple: DATA_INSCRIERE DATE NOT NULL DATA_INCHEIERE DATE NULL Restricia CHECK - O restricie de verificare (check) poate fl folosit pentru impunerea unei reguli care poate fi aplicat unei singure coloane a unui tabel. Condiia inclus n restricie trebuie s fie ndeplinit ori de cte ori datele din coloana respectiv a tabelului sunt modificate n caz contrar, sistemul SGBD va respinge modificarea i va afia un mesaj de eroare. Sintaxa restriciei CHECK i un exemplu: [CONSTRAINT nume restricie] CHECK (condiie) Exemplu: IND_CREDIT_CARD CHAR(1) NOT NULL, CHECK (CREDIT_CARD_INDIC IN (Y, N)) Clauz NOT NULL poate fi rescris i sub forma unei restricii CHECK: ID_CONT_CLIENT INTEGER

42

CONSTRAINT CK_CUST _ACCT _ID CHECK (ID_CONT IS NOT NULL) Restricia UNIQUE - O restricie UNIQUE impus asupra unei coloane garanteaz unicitatea valorilor din coloana respectiv a tabelului. Sintaxa: [CONSTRAINT nume_restricie] UNIQUE Exemplu: ID_CONT_CLIENT INTEGER UNIQUE Restricia PRIMARY KEY - O restricie de cheie primar (PRIMARY KEY) impus asupra unei coloane declar coloana respectiv ca fiind cheia primar a tabelului, ceea ce nseamn c n coloana respectiv nu pot exista valori nule, iar valorile trebuie s fie unice n cadrul tabelului. Sintaxa : (CONSTRAINT nume_restricie] PRIMARY KEY Exemplu: ID_CONT_CLIENT INTEGER PRIMARY KEY Restricia referential (FOREIGN KEY) - O restricie referenial impus asupra unei coloane (numit i restricie de cheie extern) definete relaia dintre o cheie extern i o cheie primar. Sintaxa: [CONSTRAINT nume_restricie] REFERENCES nume_tabel(nume_coloan) [ON DELETE CASCADE | ON DELETE SET NULL] Exemplu: MPAA_CODE_RATING din tabelul FILME este cheie extern pentru tabelul MPPA_RATING, care are cmpurile: MPAA_CODE_RATING i MPAA__RATING _DESCRIERE MPAA_COD_RATING CHAR (5) NOT NULL REFERENCES MPPA_RATING(MPAA_CODE_RATING) Clauza opional ON DELETE spune sistemului SGBD ce s fac atunci cnd este ters rndul referit din tabelul printe cu opiunea de a terge toate rndurile care conin cheia extern (CASCADE) sau de a insera valori nule pentru toate cheile externe (SET NULL).

43

Restriciile tabelelor Restricia unei coloane poate fi rescris i ca restricie a ntregului tabel, astfel nct clauza care definete restricia s apar n instruciunea CREATE TABLE dup definiiile tuturor coloanelor, nu dup definiia unei coloane. Principalul avantaj al restriciilor la nivelul tabelului este c pot referi mai multe coloane. Restricia CHECK [CONSTRAINT nume_restricie] CHECK (condiie) Restricia de mai jos mpiedic stocarea unei valori negative n coloana SUMA_DEPOZITE_CLIENT . Operatorul OR permite stocarea valorilor nule , deoarece o valoare nulA nu este mai mare sau egal cu zero.

Exemplu: CONSTRAINT CK_SUMA_DEPOZITE_CLIENT CHECK (SUMA_DEPOZITE_CLIENT >= 0 OR SUMA_DEPOZITE_CLIENT IS NULL)

Restricia UNIQUE [CONSTRAINT nume_restricie) UNIQUE (nume_coloan [,nume coloan...]) Conform acestei restricii , combinaia de coloane ID_CONT_CLIENT i DATA_INSCRIERE trebuie s fie unic n rndurile din tabel. Exemplu: CONSTRAINT UK_DATA_INSCR_CONT_CL UNIQUE (ID_CONT_CLIENT, DATA_INSCRIERE )

Restricia PRIMARY KEY [CONSTRAINT nume_restricie] PRIMARY KEY (nume_coloan [,nume_coloan...]) Restricia de mai jos este chiar definiia cheii primare din tabelul CONT_CLIENT [ Exemplu: CONSTRAINT PK_CONT_CLIENT PRIMARY KEY (ID_CONT_CLIENT)

Restricia referenial (FOREIGN KEY)

44

Spre deosebire de forma pentru restricia referenial a coloanei, aceasta poate referi mai multe coloane. [CONSTRAINT nume_restricie] FOREIGN KEY (nume_coloan [,nume coloan...]) REFERENCES nume_tabel (nume_coloan [,nume_coloan... [ON DELETE CASCADE |ON DELETE SET NULL] Exemple de constrngeri la nivel de coloan i tabel pentru gestiunea crilor dintr-o bibliotec. Exemple: 1. S se defineasc o constrngere la nivel de coloan prin care s se specifice cheia primar i cheia extern. CREATE TABLE carte (codel CHAR(5) CONSTRAINT cp_carte PRIMARY KEY, Titlu VARCHAR2(30), autor VARCHAR2(30), pret NUMBER(8,2), nrex NUMBER(3), coded CHAR(5) CONSTRAINT nn_coded NOT NULL CONSTRAINT ce_coded REFERENCES domeniu(coded)); 2. S se defineasc o constrngere la nivel de tabel prin care s se specifice cheia primar i cheia extern. CREATE TABLE carte (codel CHAR(5), titlu VARCHAR2(30), autor VARCHAR2(30), pret NUMBER(8,2), nrex NUMBER(3), coded CHAR(5) NOT NULL, CONSTRAINT cp_carte PRIMARY KEY (codel), CONSTRAINT ce_coded FOREIGN KEY (coded) REFERENCES domeniu(coded));

45

Observaii: Liniile ce nu respect constngerea sunt depuse automat ntr-un tabel special. Constrngerile previn tergerea unui tabel dac exist dependene. Constrngerile pot fi create o dat cu tabelul sau dup ce acesta a fost creat. Constrngerile pot fi activate sau dezactivate n funcie de necesiti. Constrngeri declarative pot fi: constrngeri de domeniu, constrngerea de integritate a entitii, constrngerea de integritate referenial. Constrngerile de domeniu definesc valori luate de un atribut (DEFAULT, CHECK, UNIQUE, NOT NULL). constrngerea (coloan) DEFAULT ; constrngerea (coloan sau tabel) CHECK ; constrngerea CHECK la nivel de tabel poate compara coloane ntre ele, poate face referin la una sau mai multe coloane, dar nu poate conine subcereri. Constrngerea la nivel de coloan nu poate referi alte coloane ale aceluiai tabel. CREATE TABLE carte (codel CHAR(5), nrex NUMBER(3), pret NUMBER(8,2) CONSTRAINT alfa CHECK (pret < nrex),); La execuia acestei comenzi apare mesajul: ORA 02438: Column check constraint cannot reference other columns. Dac dup NUMBER(8,2) se adaug o virgul, atunci constrngerea va fi la nivel de tabel, iar n aceste caz este permis referirea altei coloane. constrngerea (coloan sau tabel) UNIQUE ; constrngerea declarativ NOT NULL poate fi doar la nivel coloan. Constrngerea de integritate a entitii precizeaz cheia primar a unui tabel. Cnd se creeaz cheia primar se genereaz automat un index unic. Valorile cheii primare sunt distincte i diferite de valoarea null.

46

Constrngerea de integritate referenial asigur coerena ntre cheile primare i cheile externe corespunztoare. Cnd este definit o cheie extern sistemul Oracle verific: dac a fost definit o cheie primar pentru tabelul referit de cheia extern; dac numrul coloanelor ce compun cheia extern corespunde numrului de coloane a cheii primare; dac tipul i lungimea fiecrei coloane a cheii externe corespunde cu tipul i lungimea fiecrei coloane a cheii primare.

Aceast constrngere poate fi definit la nivel de coloan sau tabel i asigur coerena ntre cheile primare i cheile externe corespunztoare. Constrngerea FOREIGN KEY desemneaz o coloan sau o combinaie de coloane drept cheie extern i stabilete relaia cu o cheie primar sau o cheie unic din acelai tabel sau din altul. O cheie extern compus poate fi definit doar la nivel de tabel. Cheia extern se definete n tabelul copil, iar tabelul care conine coloana referit reprezint tabelul printe. Valoarea unei chei externe trebuie s fie egal cu o valoare existent n tabelul printe sau s fie null. Cheile externe se bazeaz pe valorile datelor i sunt pointer-i logici. Cheile externe se definesc folosind urmtoarele cuvinte cheie: FOREIGN KEY este utilizat ntr-o constrngere la nivel de tabel pentru a defini coloana din tabelul copil; REFERENCES identific tabelul printe i coloana corespunztoare din acest tabel; ON DELETE CASCADE determin ca, odat cu tergerea unei linii din tabelul printe, s fie terse i liniile dependente din tabelul copil; ON DELETE SET NULL determin modificarea automat a valorilor cheii externe la valoarea null, atunci cnd se terge valoarea printe. Definiiile i numele constrngerilor definite se pot fi consulta prin interogarea vizualizrilor USER_CONSTRAINTS i ALL_CONSTRAINTS din dicionarul datelor (Desc USER_CONSTRAINTS;)

Modificarea structurii unui tabel

47

Comanda care realizeaz modificarea structurii tabelului (la nivel de coloan sau la nivel de tabel), dar nu modificarea coninutului acestuia, este ALTER TABLE.

Instruciunea ALTER TABLE Instruciunea ALTER TABLE ajut s se fac modificri asupra tabelelor create. Utilizarea instruciunii ALTER TABLE este un alt domeniu n care au un rol important stilul i preferinele personale. Muli administratori de baze de date prefer s foloseasc instrucuni CREATE TABLE ct mai simple, evitnd s defineasc restricii n instruciunile CREATE TABLE. Acetia adaug dup instruciunea CREATE TABLE instruciuni ALTER TABLE prin care specific toate restriciile necesare (cheie primar, cheie extern, unicitate, verificare). Dezavantajul acestei metode este acela c necesit scrierea unei cantiti mai mari de cod. Pe de alt parte, instruciunea CREATE TABLE este mult mai uor de neles fr restricii, iar scrierea separat a restriciilor simplific refolosirea instruciunilor. Comanda ALTER TABLE permite: adugarea (ADD) de coloane, chei (primare sau externe), constrngeri ntr-un tabel existent; modificarea (MODIFY) coloanelor unui tabel; specificarea unei valori implicite pentru o coloan existent; activarea i dezactivarea constrngeri; suprimarea unei coloane; (ENABLE, DISABLE) unor

suprimarea (DROP) cheii primare, a cheii externe sau a unor constrngeri. Comanda ALTER TABLE are urmtoarea sintax simplificat: ALTER TABLE [<nume_schema>.] <nume_tabel> [ADD (<nume_coloana> <tip_date>, <constrngere>) | MODIFY (<nume_coloana_1>,, <nume_coloana_n>) | DROP <clauza_drop>,] [ENABLE | DISABLE <clause>];

48

 Adugarea unei coloane la un tabel. Definirea coloanei se face cu aceeai sintax ca i n cazul instruciunii CREATE TABLE. Nu se poate specifica unde s apar coloana, ea devenind ultima coloan a tabelului. ALTER TABLE nume_tabel ADD ( <definiie_co1oan> [,<definiie_co1oan> Exemplu: ALTER TABLE CONT_CLIENT ADD (DATA_CLIENT DATE, INTRODUSE_DE VARCHAR(50)); ALTER TABLE CITITOR ADD (ADRESA VARCHAR(50)); ALTER TABLE carte ADD(rezumat LONG);

Modificarca definiiei unei coloane. Majoritatea SGBD-urilor nu permit s scdei precizia unei coloane dac tabelul conine date i foarte puine permit s se schimbe tipul de date al unei coloane existente. Sunt acceptate creterea preciziei unei coloane, adugarea sau modificarea valorii prestabilite pentru o coloan, i trcerea de la NULL la NOT NULL sau invers. ALTER TABLE nume_tabel MODIFY [COLUMN] (<definiie coloan> [,<definiie_co1oan> ...]); Exemplu: ALTER TABLE CONT_CLIENT MODIFY (SUMA_DEPOZIT_CLIENT NUMERIC(7,2) DEFAULT 0 NOT NULL);

49

 Adugarea unei restricii. Definiia restriciei este identic cu definiia unei restricii care ar putea aprea ntr-o instruciune CREATE TABLE. ALTER TABLE nume_tabel ADD CONSTRAINT <definiie_restricie>; Exemplu: ALTER TABLE CONT_CLIENT ADD CONSTRAINT CK_SUMA_DEPOZIT_CLIENT CHECK (SUMA_DEPOZIT_CLIENT >= 0 OR SUMA_DEPOZIT_CLIENT IS NULL);

Dac pun o valoare negativ la suma, atunci apare eroare .

CREATE TABLE carte (CODEL char(5), ); ALTER TABLE carte ADD CONSTRAINT cheie_prim PRIMARY KEY (codel); tergerea cheii primare a unui tabel. Dac cheia primar este referit de restricii refereniale, trebuie mai nti terse restriciile respective. ALTER TABLE nume_tabel DROP PRIMARY KEY; Dac exist o CE care refer o CP i dac se ncearc tergerea cheii primare, aceast tergere nu se poate realiza (tabelele sunt legate prin declaraia de cheie extern). tergerea este totui permis dac
50

n comanda ALTER apare opiunea CASCADE, care determin i tergerea cheilor externe ce refer cheia primar. ALTER TABLE domeniu DROP PRIMARY KEY CASCADE; tergerea cheii externe se face ca si pentru tergerea cheii primare ALTER TABLE carte ADD CONSTRAINT beta FOREIGN KEY (coded) REFERENCES domeniu; Schimbarea cheii primare. Este destul de complicat procesul schimbrii cheii primare fr a afecta modul de proiectare a bazei de date. Schimbarea se face n dou etape: se terge cheia primar i apoi se recreeaz. ALTER TABLE carte ADD (PRIMARY KEY(codel)); ALTER TABLE carte DROP PRIMARY KEY; ALTER TABLE carte ADD PRIMARY KEY(titlu, autor)); Redenumirea unei coloane. Dintre bazele de date care accept aceast sintax este numai Oracle, ncepnd cu versiunea 8.0 ALTER TABLE nume_tabel RENAME COLUMN nume_vechi_coloan TO nume _nou_coloan; ALTER TABLE timp RENAME COLUMN durata_1 TO dur_1; ALTER TABLE timp RENAME COLUMN durata_2 TO dur_2;

51

 Pentru a activa constrngeri: ALTER TABLE ENABLE

(ENABLE)

sau

dezactiva

(DISABLE)

nume_tabel nume_constrangere; carte beta; cititor

ALTER TABLE DROP CONSTRAINT ALTER TABLE ADD CONSTRAINT

cp_cititor PRIMARY KEY (codec) DISABLE; ALTER TABLE cititor ENABLE CONSTRAINT cp_cititor; Stergerea unei coloane se face ca i a unei constringeri; ALTER TABLE nume_tabel DROP nume_coloana; ALTER TABLE CONT_CLIENT DROP (DATA_CLIENT ,INTRODUSE_DE );

Observaii Nu se poate specifica poziia unei coloane noi n structura tabelului. O coloan nou devine automat ultima n cadrul structurii tabelului.

52

 Modificarea unei coloane presupune schimbarea tipului de date, a dimensiunii sau a valorii implicite a acesteia. O schimbare a valorii implicite afecteaz numai inserrile care succed modificrii. Dimensiunea unei coloane numerice sau de tip caracter poate fi mrit, dar nu poate fi micorat dect dac acea coloan conine numai valori null sau dac tabelul nu conine nici o linie. Tipul de date al unei coloane poate fi modificat doar dac valorile coloanei respective sunt null. Alte opiuni ale comenzii ALTER TABLE, care au aprut ncepnd cu versiunea Oracle8i, sunt SET UNUSED i DROP UNUSED COLUMNS: ALTER TABLE nume_tabel ET UNUSED [ ( ] nume_coloan [ ) ]; ALTER TABLE nume_tabel DROP UNUSED COLUMNS; Opiunea SET UNUSED permite marcarea uneia sau mai multor coloane ca fiind nefolosite, cu scopul de a fi terse atunci cnd necesitile sistemului impun acest lucru. Coloanele nefolosite sunt tratate ca i cum ar fi fost suprimate, dei datele acestora rmn n liniile tabelului. Dup ce o coloan a fost marcat UNUSED, utilizatorul nu mai are acces la aceasta prin intermediul cererilor. n plus, numele i tipurile de date ale coloanelor nefolosite nu vor fi afiate cu comanda DESCRIBE din SQL*Plus. Utilizatorul poate s adauge tabelului o nou coloan avnd acelai nume cu cel al unei coloane nefolosite. DROP UNUSED COLUMNS terge din tabel toate coloanele marcate ca fiind nefolosite. Acest lucru se poate utiliza pentru eliberarea spaiului de pe disc corespunztor coloanelor nefolosite din tabel. Dac tabelul nu conine nici o coloan nefolosit, instruciunea nu ntoarce o eroare i nu are nici un efect. Atunci cnd se elimin o coloan dintr-un tabel folosind opiunea DROP a comenzii ALTER TABLE, vor fi suprimate i coloanele din tabel care sunt marcate cu opiunea SET UNUSED.

Suprimarea unui tabel

Pentru tergerea unui tabel este utilizat comanda DROP TABLE: DROP TABLE [nume_schema.]nume_tabel [CASCADE CONSTRAINTS]; Clauza CASCADE CONSTRAINTS permite suprimarea tuturor constrngerilor de integritate referenial corespunztoare cheilor primare i unice din tabelul supus tergerii. Dac se omite aceast clauz i exist
53

constrngeri de integritate referenial, sistemul returneaz o eroare i nu suprim tabelul. Suprimarea unui tabel presupune: 0suprimarea definiiei sale n dicionarul datelor; 0suprimarea indecilor asociai; 0suprimarea privilegiilor conferite n legtur cu tabelul; 0recuperarea spaiului ocupat de tabel; 0permanentizarea tranzactiilor in asteptare; 0invalidarea (dar nu suprimarea) funciilor, procedurilor, vizualizrilor, secventelor, sinonimelor referitoare la tabel. Odat executat, instruciunea DROP TABLE este ireversibil. Ca i n cazul celorlalte instruciuni ale limbajului de definire a datelor, aceast comand nu poate fi anulat (ROLLBACK).

Instruciunea DROP Instruciunea DROP este cea mai simpl dintre instruciunile DDL. Sintaxa de baz este: Pentru tergerea unui tabel este utilizat comanda DROP TABLE: DROP TABLE [nume_schema.]nume_tabel [CASCADE CONSTRAINTS]; Clauza CASCADE CONSTRAINTS permite suprimarea tuturor constrngerilor de integritate referenial corespunztoare cheilor primare i unice din tabelul supus tergerii. Dac se omite aceast clauz i exist constrngeri de integritate referenial, sistemul returneaz o eroare i nu suprim tabelul. Suprimarea unui tabel presupune: 0suprimarea definiiei sale n dicionarul datelor; 0suprimarea indecilor asociai; 0suprimarea privilegiilor conferite n legtur cu tabelul; 0recuperarea spaiului ocupat de tabel; 0permanentizarea tranzactiilor in asteptare; 0invalidarea (dar nu suprimarea) funciilor, procedurilor, vizualizrilor, secventelor, sinonimelor referitoare la tabel. Odat executat, instruciunea DROP TABLE este ireversibil. Ca i n cazul celorlalte instruciuni ale limbajului de definire a datelor, aceast comand nu poate fi anulat (ROLLBACK).

54

Tipul de obiect specific tipul obiectului care urmeaz s fie ters, cum ar fi INDEX, TABLE sau VIEW. Opiunile de tergere sunt specifice fiecrui SGBD. Sintaxa este diferit de la un productor la altul PostgreSQL i MySQL folosesc n acest scop cuvntul cheie CASCADE, n timp ce n Oracle trebuie s se foloseasc CASCADE CONSTRAINTS. Exemplu: DROP TABLE COD_CLIENT; DROP TABLE COD_CLIENT CASCADE CONSTRAINTS; (Oracle) DROP INDEX IX_TITLU_FILM; Pentru tergerea ntregului coninut al unui tabel i eliberarea spaiului de memorie ocupat de acesta, sistemul Oracle ofer instruciunea: TRUNCATE TABLE nume_tabel;

Fiind o instruciune DDL, aceasta nu poate fi anulat ulterior (printr-o operaie ROLLBACK). Ea reprezint o alternativ a comenzii DELETE din limbajul de prelucrare a datelor(DML). De remarcat c instruciunea DELETE nu elibereaz spaiul de memorie. Comanda TRUNCATE este mai rapid deoarece nu genereaz informaie ROLLBACK i nu activeaz declanatorii asociai operaiei de tergere. Dac tabelul este printele unei constrngeri de integritate referenial, el nu poate fi trunchiat. Pentru a putea fi aplicat instruciunea TRUNCATE, constrngerea trebuie s fie mai nti dezactivat. In DDL, informaiile despre tabele se gsesc n vizualizarea USER_TABLES. Dintre cele mai importante coloane ale acesteia, se remarca le obtinem cu instructiunea:
55

DESCRIBE USER_TABLES;

TABLE_NAME TABLESPACE_NAME CLUSTER_NAME PCT_FREE PCT_USED INI_TRANS NITIAL_EXTENT NEXT_EXTENT MIN_EXTENTS MAX_EXTENTS PCT_INCREASE BACKED_UP NUM_ROWS BLOCKS EMPTY_BLOCKS AVG_SPACE AVG_ROW_LEN TABLE_LOCK PARTITIONED TEMPORARY NESTED

Numele tabelului Spaiul tabel n care se afl tabelul Numele cluster-ului din care face parte tabelul Procentul de spaiu pstrat liber n interiorul fiecrui bloc Procentul de spaiu ce poate fi utilizat n fiecare bloc Numrul iniial de tranzacii concurente n interiorul unui bloc Dimensiunea spaiului alocat pentru prima extensie Dimensiunea spaiului alocat pentru urmtoarea extensie Numrul minim de extensii ce se aloc la crearea unui tabel Numrul maxim de extensii ce se aloc la crearea unui tabel Procentul cu care crete dimensiunea unei extensii Y sau N, dup cum tabelului i-a fost fcut o copie de siguran de la ultima modificare Numrul de nregistrri din tabel Numrul de blocuri utilizate de tabel Numrul de blocuri ce nu conin date Spaiul mediu liber din tabel Lungimea medie, n octei, a unei linii ENABLED (activat) sau DISABLED (dezactivat): este activat sau nu blocarea tabelului YES sau NO, indic dac tabelul este partiionat (sau nu) Y sau N, indic dac tabelul este temporar (sau nu) YES sau NO, indic dac tabelul este imbricat (sau nu)

Exemplu: SELECT TABLE_NAME, NUM_ROWS, NESTED FROM USER_TABLES; Exemplu: SELECT 'DROP TABLE ' || OBJECT_NAME || ';' FROM USER_OBJECTS WHERE OBJECT_TYPE = 'TABLE';

56

Instruciunea CREATE INDEX

Indexurile sunt instrumente puternice, deoarece permit sistemului s gsesc datele mult mai repede, tot aa cum indexul unei cri ne permite s gsim mai rapid ceea ce ne intereseaz. De asemenea, indexurile pe coloanele cheilor externe cresc mult peformanele la unirea tabelelor. Sistemul SGBD ntreine automat indexul, dar activitatea de ntreinere consum din resursele calculatorului. Pentru mbuntirea performanelor unor interogri, trebuie luat n considerare crearea unui index. De asemenea, un index poate fi utilizat pentru a impune unicitatea valorilor unei coloane sau ale unei colecii de coloane. Un index este un obiect al schemei, care conine cte o intrare pentru fiecare valoare ce apare n coloanele indexate ale unui tabel sau grupare i determin accesul rapid i direct la nregistrri, prin utilizarea unui pointer. Indecii sunt utilizai i ntreinui automat de ctre server-ul Oracle. Odat creat, un index nu necesit o aciune direct din partea utilizatorului. Un index poate fi creat asupra: uneia sau mai multor coloane ale unui tabel nepartiionat, partiionat, organizat pe baz de index sau ale unui cluster; unuia sau mai multor atribute de tip scalar ale unui obiect dintr-

57

un tabel sau cluster; unui tabel imbricat. Indecii sunt independeni din punct de vedere logic i fizic de tabelul pe care l indexeaz. Aceasta nseamn c indecii pot fi creai sau suprimai la orice moment fr a avea vreun efect asupra tabelelor de baz sau asupra altor indeci. Un index este un obiect al schemei unei baze de date care: crete viteza de execuie a cererilor; garanteaz c o coloan conine valori unice. Un index trebuie s aib cel puin o coloan, dar, nu exist o limit superioar a numrului de coloane. Server-ul Oracle utilizeaz identificatorul ROWID pentru regsirea liniilor n structura fizic a bazei de date. Indexul, din punct de vedere logic, este compus dintr-o valoare cheie i din identificatorul adres ROWID. select rowid, cod_artist,nume,prenume from artist; ROWID COD_ARTIST NUME PRENUME ------------------ ---------- ------------------------------ -----------AAAHkEAAJAAAAbPAAA 1 Grigorescu Dan AAAHkEAAJAAAAbPAAB 2 ene ana select * from artist where rowid='AAAHkEAAJAAAAbPAAA'; COD_ARTIST NUME PRENUME -------------------- ----------------------- -----------------------1 Grigorescu Dan Cheia indexului poate fi coloana unui tabel sau concatenarea mai multor coloane (numrul maxim de coloane care pot defini cheia indexului este 32). Coloanele care apar n cheia indexului trebuie declarate NOT NULL n tabel. Indecii sunt utilizai i ntreinui automat de ctre server-ul Oracle. Odat creat indexul, el nu necesit o aciune direct din partea utilizatorului. Indecii pot fi creai n dou moduri: automat, de server-ul Oracle (PRIMARY KEY, UNIQUE);
58

 manual, de ctre utilizator (CREATE INDEX). Server-ul Oracle creeaz automat un index unic atunci cnd se definete o constrngere PRIMARY KEY sau UNIQUE asupra unei coloane sau unui grup de coloane. Numele indexului va fi acelai cu numele constrngerii. Indecii, fiind obiecte ale schemei bazei, beneficiaz de procesul de definire a unui obiect. Crearea unui index (care nu este obligatoriu unic) pe una sau mai multe coloane ale unui tabel se face prin comanda: CREATE[{UNIQUE | BITMAP} ] [UNIQUE] INDEX <nume_index> ON [<nume_schema>.] <nume_tabel> (<nume_col> [ASC | DESC], <nume_col> [ASC | DESC], );

Cuvntul cheie opional UNIQUE definete indexul ca unic, nsemnnd c nu pot exista dou rnduri din tabel cu exact acceai combinaie de valori n coloanele specificate. Aceast clauz nu poate fi specificat alturi de clauza BITMAP sau pentru un index domeniu. Clauza BITMAP determin crearea indexului cu o hart de bii (bitmap) pentru fiecare cheie distinct, n loc de a indexa separat fiecare linie. Fiecare bit din bitmap corespunde unei valori ROWID posibile. Dac un bit este setat, nseamn c linia avnd valoarea ROWID corespunztoare acestuia conine valoarea cheii. Reprezentarea intern a bitmap-urilor este adecvat aplicaiilor cu niveluri sczute ale tranzaciilor concurente (de exemplu, aplicaii data warehouse). Cuvntul cheie opional ASC creeaz indexul n ordine cresctoare, n timp ce DESC creeaz indexul n ordine descresctoare. Dac nu este specificat nici una dintre cele dou opiuni, ordinea prestabilit este cresctoare. Cnd este creat un index, un segment de date este rezervat automat n spaiul tabel. Alocarea de memorie este controlat prin clauzele INITIAL_EXTENT, PCT_INCREASE, PCT_FREE, NEXT, care pot s apar n comanda CREATE INDEX. Exemplu: 1) S se creeze un index descresctor relativ la coloana adresa din tabelul cititor. CREATE INDEX cititor_idx

59

ON cititor (adresa DESC); CREATE INDEX cit_den ON cititor (DEN_CITITOR); 2) S se afieze informaiile referitoare la indexul cititor_idx. SELECT TABLE_NAME FROM USER_INDEXES WHERE INDEX_NAME=CITITOR_IDX; SELECT TABLE_NAME FROM USER_INDEXES WHERE INDEX_NAME=CIT_DEN;

3) S se afieze toate indexurile(numele tabelelor, numele indexului si daca a fost sau nu generat) SELECT TABLE_NAME, INDEX_NAME, TABLE_TYPE FROM USER_INDEXES; 4)S se creeze un index explicit, referitor la cheia primara a unui tabel. Pentru a schimba numele unei chei altul decit cel dat de sistem oracle, Sys_Cn; CREATE TABLE exem ( cod_id NUMBER(6) PRIMARY KEY USING INDEX (CREATE INDEX cod_id_idx ON exem (cod_id)), nume VARCHAR2(20)); Mai muli indeci asupra unui tabel nu implic ntotdeuna interogri mai rapide. Fiecare operaie LMD care este permanentizat asupra unui tabel cu indeci asociai presupune actualizarea indecilor respectivi. Prin urmare, este recomandat crearea de indeci numai n anumite situaii: coloana conine o varietate mare de valori; coloana conine un numr mare de valori null; una sau mai multe coloane sunt utilizate frecvent mpreun ntro clauz WHERE sau ntr-o condiie de join; tabelul este mare i este de ateptat ca majoritatea interogrilor asupra acestuia s regseasc mai puin de 2-4% din linii.

60

Crearea unui index nu este recomandat n urmtoarele cazuri: tabelul este mic; coloanele nu sunt utilizate des n cadrul unei condiii dintr-o cerere; majoritatea interogrilor regsesc mai mult de 2-4% din liniile tabelului; tabelul este actualizat frecvent; coloanele indexate sunt referite n expresii. In concluzie, ce tabele sau ce coloane trebuie (sau nu) indexate? indexai tabelele pentru care interogrile selecteaz un numr redus de rnduri (sub 5%); indexai tabelele care sunt interogate folosind clauze SQL simple; nu indexai tabelele ce conin puine nregistrri (accesul secvenial este mai simplu); nu indexai tabelele care sunt frecvent actualizate, deoarece tergerile, inserrile i modificrile sunt ngreunate de indeci; indexai coloanele folosite frecvent n clauza WHERE sau n clauza ORDER BY; nu indexai coloanele ce conin date asemntoare (puine valori distincte); Exemplu: Pentru a asigura c server-ul Oracle utilizeaz indexul i nu efectueaz o cutare asupra ntregului tabel, valoarea funciei corespunztoare expresiei indexate trebuie s nu fie null n interogrile ulterioare crerii indexului. Urmtoarea instruciune garanteaz utilizarea indexului dar, n absena clauzei WHERE, server-ul Oracle ar putea cerceta ntreg tabelul. SELECT * FROM artist WHERE UPPER(nume) IS NOT NULL ORDER BY UPPER(nume); Exemplu: S se creeze tabelul artist, specificndu-se indexul asociat cheii primare. CREATE TABLE artist( cod_artist NUMBER PRIMARY KEY USING INDEX (CREATE INDEX artist_cod_idx ON artist(cod_artist)),

61

nume prenume

VARCHAR2(30) NOT NULL, VARCHAR2(30));

INSERT INTO ARTIST VALUES(1,Grigorescu,Dan); INSERT INTO ARTIST VALUES(2,ene,ana); INSERT INTO ARTIST VALUES(4,Adam,Horia); (trebuie creat privilegiu din Security ..query rewrite) CREATE INDEX up_nume_id ON artist(UPPER(nume)); Indexul creat prin instruciunea precedent faciliteaz prelucrarea unor interogri precum: SELECT * FROM artist WHERE UPPER(nume) = 'ene'; tergerea unui index se face prin comanda: DROP INDEX nume_index [ON [nume_schema.] nume_tabel] Pentru a suprima indexul trebuie ca acesta s se gseasc n schema personal sau s ai privilegiul de sistem DROP ANY INDEX. Pentru a reconstrui un index se pot folosi dou metode: se terge indexul (DROP INDEX) i se recreeaz (CREATE INDEX); se utilizeaz comanda ALTER INDEX cu opiunea REBUILD. Modificarea parametrilor de stocare a indecilor (STORAGE), alocarea (ALLOCATE EXTENT) i dealocarea (DEALLOCATE UNUSED) manual a spaiului utilizat de un index se pot realiza cu ajutorul comenzii ALTER INDEX. ncepnd cu Oracle9i, este posibil modificarea structurii indecilor prin comanda ALTER INDEX. Validarea unui index, adic verificarea integritii indexului specificat pentru un tabel, se face prin comanda: VALIDATE INDEX nume_index [ON nume_tabel] [WITH LIST] VALIDATE INDEX artist_cod_idx; Informaii referitoare la indeci i la coloanele care i definesc pot fi regsite n vizualizrile USER_INDEXES, respectiv
62

USER_IND_COLUMNS din dicionarul datelor. Dintre coloanele tabelului USER_INDEXES se remarc, dnd Desc USER_INDEXES;
INDEX_NAME INDEX_TYPE TABLE_OWNER TABLE_NAME TABEL_TYPE UNIQUENESS TABLESPACE_NAME INITIAL_EXTENT NEXT_EXTENT MIN_EXTENTS MAX_EXTENTS PCT_INCREASE BLEVEL LEAF_BLOCKS DISTINCT_KEYS STATUS NUM_ROWS PARTITIONED GENERATED Numele indexului Tipul indexului (NORMAL, LOB, CLUSTER etc.) Proprietarul tabelului indexat Numele tabelului indexat Tipul tabelului indexat (TABLE, CLUSTER etc.) Starea de unicitate (UNIQUE, NONUNIQUE) Spaiul tabel n care este stocat indexul Spaiul alocat pentru prima extensie Spaiul alocat pentru urmtoarea extensie Numrul minim de extensii alocate Numrul maxim de extensii Procentul cu care cresc extensiile Nivelul din B-arbore. Acesta arat adncimea indexului de la ramuri la frunze Numrul de blocuri frunz din index Numrul de chei distincte n index Starea indexului (VALID, INVALID, DIRECT_LOAD) Numrul de linii utilizate. Acesta nu trebuie s includ valorile NULL din tabelul de baz Determin dac indexul este partiionat (YES sau NO) Determin dac sistemul a generat numele indexului (Y) sau utilizatorul (N)

SELECT TABLE_NAME, INDEX_NAME, TABLE_TYPE FROM USER_INDEXES;

63

Pentru a vedea informatiile din USER_IND_COLUMNS, avem Desc USER_IND_COLUMNS;

Exemplu: S se obin informaii referitoare la indecii tabelului carte.

64

SELECT FROM WHERE AND

a.index_name, a.column_name, a.column_position poz, b.uniqueness user_indexes b, user_ind_columns a a.index_name = b.index_name a.table_name = CITITOR;

Secvene
Multe aplicaii necesit utilizarea de numere unice ca valori ale cheilor primare. Pentru a obine astfel de numere, se pot implementa n aplicaie uniti de program corespunztoare sau se pot utiliza secvene. De obicei, secvenele sunt utilizate pentru crearea de valori ale cheii primare care trebuie s fie unice pentru fiecare linie. Secvena este incrementat sau decrementat de ctre o rutin intern Oracle. Numerele secvenei sunt stocate i generate independent de tabele. Prin urmare, aceeai secven poate fi utilizat pentru mai multe tabele. O secven este un obiect al bazei de date, creat de utilizator. Acest obiect poate fi folosit de mai muli utilizatori pentru a genera numere ntregi unice n sistemele multi-utilizator, evitnd apariia conflictelor i a blocrii. O secven poate fi creat de un utilizator i poate fi partajat de mai muli utilizatori.
65

Crearea unei secvene se face cu ajutorul comenzii: CREATE SEQUENCE [<nume_schema>.]<nume_secventa> [INCREMENT BY n] [START WITH m] [{MAXVALUE n | NOMAXVALUE}] [{MINVALUE n|NOMINVALUE}] [{CACHE k | NOCACHE}] Opiunea INCREMENT BY specific diferena dintre valorile succesive ale secvenei. Dac aceast opiune este omis, numerele generate de secven vor fi incrementate prin valoarea 1. Opiunea START WITH specific primul numr care va fi generat de secven. Dac aceast opiune este omis, secvena ncepe de la valoarea 1. Opiunile MAXVALUE, MINVALUE precizeaz valoarea maxim, respectiv minim pe care o poate genera secvena. Opiunile NOMAXVALUE, NOMINVALUE sunt implicite. NOMAXVALUE specific valoarea maxim de 1027 pentru o secven cresctoare i -1 pentru o secven descresctoare. NOMINVALUE specific valoarea minim 1 pentru o secven cresctoare i -1026 pentru o secven descresctoare. Opiunile CYCLE i NOCYCLE specific dac secvena continu s genereze numere dup obinerea valorii maxime sau minime. NOCYCLE este opiunea implicit. Se recomand s nu fie utilizat opiunea CYCLE dac secvena este folosit pentru generarea de chei primare, cu excepia cazului n care exist un mecanism care terge liniile vechi din tabel mai repede dect cicleaz secvena. CACHE k precizeaz numrul de valori pe care server-ul Oracle le prealoc i le pstreaz n memorie. n mod implicit, acest numr de valori este 20. Opiunea CACHE pemite accesul mai rapid la valorile secvenei care sunt pstrate n memorie. Aceste valori sunt generate la prima referin asupra secvenei. Fiecare valoare din secven se furnizeaz din secvena memorat. Dup utilizarea ultimei valori prealocate secvenei, urmtoarea solicitare a unei valori determin ncrcarea unui alt set de numere n memorie. Pentru a nu fi prealocate i reinute n memorie astfel de valori, se utilizeaz opiunea NOCACHE. O secven este referit ntr-o comand SQL cu ajutorul pseudocoloanelor: NEXTVAL refer valoarea urmtoare a secvenei; CURRVAL refer valoarea curent a secvenei.
66

NEXTVAL i CURRVAL pot fi folosite n: clauza VALUES a unei comenzi INSERT; clauza SET a unei comenzi UPDATE; lista SELECT a unei subcereri dintr-o comanda INSERT; lista unei comenzi SELECT. NEXTVAL i CURRVAL nu pot fi folosite n: subinterogare in SELECT, DELETE sau UPDATE; interogarea unei vizualizri; comand SELECT cu operatorul DISTINCT; comand SELECT cu clauza GROUP BY, HAVING sau ORDER BY; clauza WHERE a unei comenzi SELECT; condiia unei constrngeri CHECK; valoarea DEFAULT a unei coloane ntr-o comand CREATE TABLE sau ALTER TABLE; comand SELECT care este combinat cu alt comand SELECT printr-un operator mulime (UNION, INTERSECT, MINUS).

Din dicionarul datelor pot fi obinute informaii despre secvene folosind vizualizarea USER_SEQUENCES.

1)

2)

S se creeze o secven domeniuseq care s fie utilizat pentru a insera noi domenii n tabelul domeniu i s se insereze un nou domeniu. S se afieze informaiile referitoare la secvena domeniuseq. CREATE SEQUENCE domeniuseq START WITH 4 INCREMENT BY 1; INSERT INTO domeniu VALUES (domeniuseq.NEXTVAL,Arta);

67

SELECT INCREMENT_BY,MAX_VALUE, MIN_VALUE FROM USER_SEQUENCES WHERE SEQUENCE_NAME = 'DOMENIUSEQ; Modificarea unei secvene se face prin comanda ALTER SEQUENCE. Sintaxa comenzii este similar instruciunii CREATE SEQUENCE , dar: noua valoare maxim pentru MAXVALUE nu poate fi mai mic dect valoarea curent; opiunea START WITH nu poate fi modificat de comand. Exemplu: S se schimbe pasul secventei de la 1 la 2 ALTER SEQUENCE DOMENIUSEQ INCREMENT BY 2;

Suprimarea unei secvene se face cu ajutorul comenzii: DROP SEQUENCE [<nume_schema>.]<nume_secventa>; Dup ce a fost tears, secvena nu mai poate fi referit. Pentru a putea terge sau modifica secvena trebuie fie s fi proprietarul acesteia, fie s ai privilegiul de sistem DROP ANY SEQUENCE, respectiv privilegiul ALTER SEQUENCE. DROP SEQUENCE domeniuseq;

Sinonime

68

Oracle ofer posibilitatea de a atribui mai multe nume aceluiai obiect. Aceste nume adiionale sunt numite sinonime (synonymes). Ele sunt utile deoarece permit simplificarea formulrii cererii i referirea la obiecte, fr a fi nevoie s se specifice proprietarii obiectelor sau localizarea acestora(schema). Spre deosebire de alias a crui durat de via este limitat la cererea ce conine alias-ul, sinonimele sunt salvate n dicionarul datelor i pot fi reutilizate. Sistemul Oracle permite crearea de sinonime pentru obiecte de tipul: tabel, vizualizare, secven, funcie, procedur, pachet, clieu, sinonim. Crearea unui sinonim se realizeaz prin comanda: CREATE [PUBLIC] SYNONYM [schema.]nume_sinonim FOR [schema.]obiect Exemplu: CREATE SYNONYM artist1 FOR artist; SELECT * from user_objects; SELECT * from artist1; CREATE SYNONYM domeniu1seq for domeniuseq; Administratorul bazei poate produce i poate suprima sinonime publice sau private, iar utilizatorii pot genera sau suprima doar sinonime private. Pentru suprimarea unui sinonim din baza de date se utilizeaz comanda: DROP [PUBLIC] SYNONYM [schema.]nume_sinonim

69

Vizualizri

O vizualizare (view) nu conine date i poate fi interpretat ca o fereastr prin care informaiile din tabele pot fi consultate i modificate. Un astfel de obiect al bazei de date extrage rezultatul unei cereri i l trateaz ca pe un tabel. Prin urmare, o vizualizare poate fi considerat drept o cerere stocat sau un tabel virtual. O vizualizare este o interogare SQL stocat, care poate fi referit de instruciunile SQL DML i DQL ca i cum ar fi un tabel real. Unii consider c vizualizrile sunt tabele virtuale", deoarece se comport la fel ca tabelele, dar nu exist ca tabele fizice. Numele vizualizrii trebuie s respecte aceleai reguli de denumire ca i tabelele i alte obiecte ale bazei de date. Interogarea SQL inclus n definiia vizualizrii poate fi orice instruciunea SQL SELECT valid. Vizualizarea (view) este un tabel logic (virtual) relativ la date din una sau mai multe tabele sau vizualizri. Vizualizarea este definit plecnd de la o cerere a limbajului de interogare a datelor, motenind caracteristicile obiectelor la care se refer. Vizualizarea, fiind virtual, nu solicit o alocare de memorie pentru date. Ea este definit n DD cu aceleai caracteristici ca i un tabel. Spre deosebire de tabele, pentru coninutul vizualizrii nu se aloc spaiu de stocare. Spaiul ocupat de o vizualizare este doar cel alocat definiiei acesteia (cererii stocate) din dicionarul datelor. Tabelele din care cererea stocat selecteaz date se numesc tabele de baz ale vizualizrii. Ele pot fi tabele sau chiar vizualizri, inclusiv vizualizri materializate. Textul cererii care definete vizualizarea este salvat n DD. Nucleul Oracle determin fuzionarea cererii relative la vizualizare cu comanda de definire a vizualizrii, analizeaz rezultatul fuziunii n zona partajat i execut cererea. Oracle transform cererea referitoare la o vizualizare ntr-o cerere relativ la tabelele de baz. Vizualizarea este memorata in DD sub forma unui SELECT. Dac sunt utilizate clauzele UNION, GROUP BY i CONNECT BY, atunci Oracle nu determin fuzionarea, el va rezolva vizualizarea i apoi va aplica cererea rezultatului obinut.

70

O vizualizare reflect la orice moment coninutul exact al tabelelor de baz. Orice modificare efectuat asupra tabelelor se repercuteaz instantaneu asupra vizualizrii. tergerea unui tabel implic invalidarea vizualizrilor asociate tabelului i nu tergerea acestora. Vizualizrile sunt definite pentru: furnizarea unui nivel mai nalt de securizare a bazei; simplificarea formulrii unei cereri; mascarea complexitii datelor; afiarea datelor ntr-o alt reprezentare dect cea a tabelelor de baz; asigurarea independenei datelor; asigurarea confidenialitii anumitor informaii; definirea constrngerilor de integritate; restricionarea acesului la date. Vizualizrile pot fi simple i complexe. O vizualizare simpl extrage date dintr-un singur tabel, nu conine funcii sau grupri de date i asupra ei pot fi efectuate operaii LMD. O vizualizare este considerat complex dac extrage date din mai multe tabele, conine funcii sau grupri de date i nu permite ntotdeauna (prin intermediul su) operaii LMD asupra tabelelor de baz. Operaiile LMD asupra vizualizrilor complexe sunt restricionate de urmtoarele reguli: nu se poate insera, actualiza sau terge o linie dintr-o vizualizare dac aceasta conine funcii grup, clauza GROUP BY, cuvntul cheie DISTINCT sau pseudocoloana ROWNUM; nu se poate aduga sau modifica o linie dintr-o vizualizare, dac aceasta conine coloane definite prin expresii; nu pot fi adugate linii printr-o vizualizare, dac tabelul de baz conine coloane care au constrngerea NOT NULL i nu apar n lista SELECT a vizualizrii. Pentru a obine informaii referitoare la vizualizrile definite, se pot interoga vizualizrile USER_VIEWS i ALL_VIEWS din dicionarul datelor. Textul instruciunii SELECT care definete o vizualizare este stocat ntr-o coloan de tip LONG, numit TEXT. Atunci cnd datele sunt accesate prin intermediul unei vizualizri, server-ul Oracle efectueaz urmtoarele operaii: recupereaz definiia acesteia din USER_VIEWS; verific privilegiile de acces la tabelele ei de baz; convertete cererea ntr-o operaie echivalent asupra tabelelor de baz.

71

Crearea unei vizualizri se realizeaz cu ajutorul comenzii: CREATE [OR REPLACE][FORCE | NOFORCE] VIEW [<nume_schema>.]<nume_view> [(<alias>[,<alias>])] AS <cerere_SELECT> [WITH {CHECK OPTION [CONSTRAINT <nume_constrangere>] | READ ONLY }]; OR REPLACE recreeaz vizualizarea dac aceasta deja exist. FORCE creeaz vizualizarea chiar dac tabelul de baz nu exist sau chiar dac vizualizarea face referin la obiecte care nc nu sunt create. Dei vizualizarea va fi creat, utilizatorul nu poate s o foloseasc. NO FORCE este implicit i se refer la faptul c vizualizarea este creat numai dac tabelele de baz exist. Cererea este o comand SELECT care poate s conin alias pentru coloane. WITH CHECK OPTION specific faptul c reactualizarea datelor din tabele (inserare sau modificare) se poate face numai asupra datelor selectate de vizualizare (care apar n clauza WHERE). WITH READ ONLY asigur c nici o operaie LMD nu poate fi executat asupra vizualizrii. Exemplu: S se genereze o vizualizare care conine informaii referitoare la mprumutul crilor i n care s fie implementat constrngerea c orice carte, care exist ntr-un singur exemplar, poate fi mprumutat maximum 15 zile. CREATE VIEW imprumutare AS SELECT * FROM imprumuta WHERE codel NOT IN (SELECT codel FROM carte WHERE nrex = 1) OR datares - dataim < 15 WITH CHECK OPTION; Cererea care definete vizualizarea poate fi complex, incluznd join-uri, grupri i subcereri, ns nu poate conine clauza ORDER BY. Dac este necesar, aceast clauz poate fi specificat la interogarea vizualizrii. Interogarea unei vizualizri este similar celei unui tabel.

72

Numrul coloanelor specificate n definiia vizualizrii trebuie s fie egal cu cel din lista asociat comenzii SELECT. Asupra cererii care definete vizualizarea se impun urmtoarele restricii: nu pot fi selectate pseudocoloanele CURRVAL i NEXTVAL ale unei secvene; dac sunt selectate pseudocoloanele ROWID, ROWNUM sau LEVEL, acestora trebuie s li se specifice alias-uri; dac cererea selecteaz toate coloanele unui tabel, utiliznd simbolul *, iar ulterior se adaug coloane noi tabelului, vizualizarea nu va conine acele coloane pn la recrearea sa printr-o instruciune CREATE OR REPLACE VIEW; pentru vizualizrile obiect, numrul i tipul elementelor selectate de cerere trebuie s coincid cu cel al atributelor de pe primul nivel al tipului obiect. Aportul versiunii Oracle9i n ceea ce privete instruciunea CREATE VIEW const n posibilitatea: crerii de subvizualizri ale vizualizrilor obiect; definirii de constrngeri asupra vizualizrilor. Exemplu: a) S se creeze o vizualizare care conine numele i prenumele artistului, numrul operelor sale i valoarea medie a acestora. CREATE VIEW artist_nr_val(nume, numar_opere, val_medie) AS SELECT a.nume || ' ' || a .prenume "Nume si prenume", COUNT(o. cod_opera) numar, AVG(o.valoare) medie FROM opera o, artist a WHERE o.cod_artist = a.cod_artist GROUP BY o.cod_artist, a.nume, a.prenume; b) S se creeze vizualizarea sculptura ce va conine codul operei, data achiziiei, codul artistului i stilul operelor al cror tip este sculptura. CREATE OR REPLACE VIEW sculptura (cod_sculptura, informatii, cod_sculptor, stil) AS SELECT cod_opera, 'Sculptura ' || titlu || ' a fost achizitionata la data ' || data_achizitiei, cod_artist, stil FROM opera WHERE tip = 'sculptura';

73

Modificarea unei vizualizri presupune modificarea definiiei acesteia. Pentru a nlocui o vizualizare trebuie avut privilegiul de sistem necesar pentru distrugerea i crearea acesteia. nlocuirea se poate face n dou moduri. Vizualizarea poate fi distrus (DROP VIEW) i apoi recreat (CREATE) cu noua definiie. Atunci cnd este distrus, toate privilegiile sunt retrase. Aceste privilegii trebuie s fie create pentru noua vizualizare. Vizualizarea poate fi recreat prin redefinire cu instruciunea CREATE VIEW, dar cu clauza OR REPLACE. Aceast metod conserv toate privilegiile curente. In Oracle9i este posibila adaugarea de constrangeri unei vizualizari prin comanda ALTER VIEW. Modificarea unui vizualizri are urmtoarele efecte: definiia vizualizrii din DD este actualizat; nici unul din obiectele de baz nu este afectat de nlocuire;

toate restriciile care existau n vizualizarea original sunt distruse; toate vizualizrile i programele PL/SQL dependente de vizualizarea nlocuit devin invalide.

Suprimarea unei vizualizri se realizeaz prin comanda DROP VIEW care terge definiia vizualizrii din baza de date. DROP VIEW <nume_view> [CASCADE CONSTRAINT]; tergerea vizualizrii nu va afecta tabelele relativ la care a fost definit vizualizarea. Aplicaiile i vizualizrile care se bazeaz pe vizualizarea suprimat devin invalide. Pentru a suprima o vizualizare, utilizatorul trebuie s aib privilegiul DROP ANY VIEW sau s fie creatorul vizualizrii respective. Similar opiunii corespunztoare din comanda DROP TABLE, clauza CASCADE CONSTRAINTS permite suprimarea tuturor constrngerilor de integritate referenial corespunztoare cheilor primare i unice din vizualizarea supus tergerii. Dac se omite aceast clauz i
74

exist astfel de constrngeri, instruciunea DROP VIEW va eua. Recompilarea unei vizualizri permite detectarea eventualelor erori referitoare la vizualizare, naintea executrii vizualizrii. Dup fiecare modificare a tabelelor de baz este recomandabil ca vizualizarea s se recompileze: ALTER VIEW <nume_view> COMPILE; Reactualizarea tabelelor corespunztoare a vizualizrilor!!! implic reactualizarea

Reactualizarea vizualizrilor implic reactualizarea tabelelor de baz? NU! Exist restricii care trebuie respectate!!!
Nu pot fi modificate date din vizualizare sau adaugate date prin vizualizare, daca aceasta contine coloane definite prin expresii. Nu pot fi nserate, terse sau actualizate date din vizualizri ce conin: operatorul DISTINCT; clauzele GROUP BY, HAVING, START WITH, CONNECT BY; pseudo-coloana ROWNUM; funcii grup; operatori de mulimi. Nu pot fi inserate sau actualizate date care ar nclca constrngerile din tabelele de baz. Nu pot fi inserate sau actualizate valorile coloanelor care rezult prin calcul. Nu se pot face operaii LMD asupra coloanelor calculate cu DECODE. Alturi de restriciile prezentate anterior, aplicabile tuturor vizualizrilor, exist restricii specifice, aplicabile vizualizrilor bazate pe mai multe tabele. Regula fundamental este c orice operaie INSERT, UPDATE sau DELETE pe o vizualizare bazat pe mai multe tabele poate modifica datele doar din unul din tabelele de baz. In care??? Un tabel de baz al unei vizualizri este protejat prin cheie (key preserved table) dac orice cheie selectat a tabelului este de asemenea i cheie a vizualizrii. Deci, un tabel protejat prin cheie este un tabel ale crui chei se pstreaz i la nivel de vizualizare. Pentru ca un tabel s fie protejat prin cheie nu este necesar ca tabelul s aib toate cheile selectate n vizualizare. Este suficient ca, atunci cnd cheia tabelului este selectat, aceasta s fie i cheie a vizualizrii. Asupra unui join view pot fi aplicate instruciunile INSERT, UPDATE sau DELETE, doar dac sunt ndeplinite urmtoarele condiii: instruciunea LMD afecteaz numai unul dintre tabelele de baz;
75

 n cazul instruciunii UPDATE, toate coloanele care pot fi reactualizate trebuie s corespund coloanelor dintr-un tabel protejat prin cheie (n caz contrar, Oracle nu va putea identifica unic nregistrarea care trebuie reactualizat); n cazul instruciunii DELETE, rndurile unei vizualizri pot fi terse numai dac exist un tabel n join protejat prin cheie i numai unul (n caz contrar, Oracle nu ar ti din care tabel s tearg); n cazul instruciunii INSERT, toate coloanele n care sunt inserate valori trebuie s provin dintr-un tabel protejat prin cheie. ALL_UPDATABLE_COLUMNS, DBA_UPDATABLE_COLUMNS i USER_UPDATABLE_COLUMNS sunt vizualizri din DD ce conin informaii referitoare la coloanele vizualizrilor existente, care pot fi reactualizate. Exmplu: 1. S se creeze un view ce conine cmpurile nume, prenume, job din tabelul salariat. 2. S se insereze, s se actualizeze i s se tearg o nregistrare n acest view. Ce efect vor avea aceste aciuni asupra tabelului de baz?
CREATE VIEW vederea2

AS SELECT FROM

nume, prenume, job salariat;

Nu se pot face inserari deoarece view-ul nu conine cheia primar! INSERT INTO vederea2 VALUES ('Popescu','Valentin','grafician'); va genera eroarea: ORA-01400: cannot insert NULL into ("SCOTT"."SALARIAT"."COD_SALARIAT") Actualizarea job-ului salariatului avnd numele "Popescu":
UPDATE vederea2

SET WHERE SELECT

job = 'programator' nume = 'Popescu'; nume, prenume, job FROM

salariat;

tergerea nregistrrii referitoare la salariatul avnd numele "Popescu": DELETE WHERE vederea2 nume = 'Popescu';

76

Operaiile care se realizeaz asupra view-ului se realizeaz i n tabelul salariat. Pentru un caz mai general, cnd view-ul conine cheia extern a tabelului de baz, sunt permise modificri ale view-ului, dac acestea nu afecteaz cheia extern. Exemplu: S se creeze un view care conine cmpurile nume, prenume, job din tabelul salariat. S se introduc n view doar persoanele care sunt graficieni. CREATE VIEW vederea21 AS SELECT nume, prenume, job FROM salariat WHERE job = 'grafician' WITH CHECK OPTION; S se creeze o vizualizare care s conin cod_salariat, nume, prenume din tabelul salariat i coloana tip din tabelul grafician. Apoi s se insereze, s se actualizeze i s se tearg o nregistrare din acest view (vizualizarea conine cheia primar cod_salariat din tabelele salariat i grafician). CREATE VIEW vederea4 AS SELECT s.cod_salariat,nume,prenume,tip FROM salariat s, grafician g WHERE s.cod_salariat=g.cod_salariat; n cazul inserrii unei nregistrri pentru care se specific toate cmpurile: INSERT INTO vederea4 VALUES (30,'Popescu','Valentin','artist plastic'); va apare urmtoarea eroare: ORA-01776: cannot modify more than one base TABLE through a join view Pot fi inserate date doar ntr-un tabel de baz (n oricare, dar n unul singur) prin intermediul view-ului, astfel: INSERT INTO vederea4 (cod_salariat, nume) VALUES (30, 'Popescu'); Comanda pentru tergerea unei nregistrri: DELETE vederea4 WHERE cod_salariat = 3; va genera urmtoarea eroare:

77

ORA-01752: cannot delete from exactly one key-preserved TABLE.

view

without

Modificarea unei nregistrri se face prin secvena care urmeaz. Toate actualizrile care se fac n view se fac i n tabelele de baz. UPDATE SET WHERE vederea4 tip = 'designer' cod_salariat = 3;

Exemplu: Care dintre coloanele unei vizualizri sunt actualizabile?

SELECT column_name, updatable

FROM WHERE Exemplu:

user_updatable_columns table_name = 'vederea4';

1. S se creeze un view (vederea3) care s conin, pentru fiecare categorie de salariat, salariile medii i numrul de angajai din tabelul salariat. 2. S se insereze, s se actualizeze i s se tearg o nregistrare n view. CREATE VIEW vederea3 (nr, job, salmed) AS SELECT COUNT(*), job, AVG(salariu) FROM salariat GROUP BY job; Nu se pot face inserri, actualizri sau tergeri ntr-un view ce conine funcii grup. Dup oricare din aceste operaii apare acelai mesaj: ORA-01732: data manipulation operation not legal on this view Exemplu: S se creeze o vizualizare care s conin coloanele cod_contractant, adresa, telefon din tabelul contractant i coloanele nr_contract, tip_contract, data_incheiere din tabelul contract. S se insereze o nregistrare n vizualizare. CREATE VIEW vederea44 AS SELECT c.cod_contractant, adresa, telefon, co.nr_contract, tip_contract, data_incheiere FROM contractant c, contract co WHERE c.cod_contractant=co.cod_contractant; La inserarea unei nregistrri creia i se specific valorile tuturor cmpurilor din ambele tabele:
78

INSERT INTO

vederea44(cod_contractant, adresa, nr_contract, data_incheiere) VALUES (200, 'Str. Marmurei, 14', '6235', TO_DATE('January 03,2002','Month dd,yyyy')); se obine eroarea: ORA-01779: cannot modify a column which maps to a non key-preserved TABLE Cele dou tabele de baz, contractant i contract, se afl ntr-o relaie one-to-many, iar view-ul creat conine cheile primare din ambele tabele. Doar tabelul contract este protejat prin cheie i, prin urmare, doar el poate fi modificat prin intermediul view-ului. Aceasta, deoarece ar putea exista mai multe nregistrri n view, cu aceeai valoare corespunztoare cmpului cod_contractant (CP n contractant). Exact aceeai eroare se obine dac ncercm inserarea unei nregistrri n vederea44, specificnd fie i numai un cmp provenind din tabela contractant (indiferent dac el conine sau nu CP). Singura operaie de inserare permis este aceea efectuat prin specificarea cheilor provenind doar din tabelul contract. Astfel, prin executarea comenzii: INSERT INTO vederea44(nr_contract, tip_contract) VALUES ('6234', 0); este creat o nregistrare, dar este modificat i tabelul contract. Dac la inserie nu se specific cheia primar din contract: INSERT INTO vederea44(tip_contract) VALUES (1); ORA-01400: mandatory (NOT NULL) column is missing or NULL during insert Cererea din definiia vizualizrii poate fi restricionat prin clauzele WITH READ ONLY i WITH CHECK OPTION. Opiunea WITH READ ONLY asigur c nu pot fi efectuate operaii LMD asupra vizualizrii. Constrngerea WITH CHECK OPTION garanteaz faptul c va fi permis, prin intermediul vizualizrii, numai inserarea sau actualizarea de linii accesibile acesteia (care sunt selectate de cerere). Prin urmare, aceast opiune asigur constrngeri de integritate i verificri asupra validitii datelor inserate sau actualizate. Opiunea WITH CHECK OPTION nu poate funciona dac: exist o cerere imbricat n cadrul subcererii vizualizrii sau n vreuna dintre vizualizrile de baz;

79

 operaiile de inserare, tergere i modificare se fac prin intermediul declanatorilor INSTEAD OF. Cuvntul cheie CONSTRAINT permite numirea constrngerii WITH CHECK OPTION. n absena acestei clauze, constrngerea va avea un nume implicit de forma SYS_Cn, unde n este un numr ntreg unic. Exemplu: S se creeze o vizualizare ce conine artitii de naionalitate romn, care au opere expuse n muzeu. Definiia vizualizrii nu va permite modificarea naionalitii unui artist sau inserarea unui artist avnd alt naionalitate dect cea romn.
CREATE VIEW artist_roman AS SELECT * FROM artist WHERE nationalitate = 'romana' WITH CHECK OPTION CONSTRAINT artist_roman_ck;

UPDATE SET WHERE

artist_roman nationalitate = 'engleza' cod_artist = 25;

ncercarea de actualizare a unei linii prin instruciunea anterioar va genera eroarea ORA-01402: view WITH CHECK OPTION whereclause violation. Exemplu: S se creeze o vizualizare asupra tabelului galerie care s nu permit efectuarea nici unei operaii LMD. CREATE VIEW viz_galerie AS SELECT cod_galerie, nume_galerie FROM galerie WITH READ ONLY; DELETE FROM viz_galerie WHERE cod_galerie = 10; ncercarea de tergere a unei linii din vizualizarea viz_galerie determin apariia erorii ORA-01752: cannot delete from view without exactly one key-preserved table. Dac se ncearc modificarea sau inserarea unei linii prin intermediul unei vizualizri asupra creia a fost definit o constrngere WITH READ ONLY, server-ul Oracle genereaz eroarea ORA-01733: virtual column not allowed here. Exemplu: S se creeze o vizualizare care conine codul i titlul operelor de art, codul i numele artitilor care le-au creat, precum i codul galeriilor unde sunt expuse. S se afle dac este posibil adugarea unei noi nregistrri prin intermediul acestei vizualizri.

80

CREATE VIEW opera_artist AS SELECT o.cod_opera, o.titlu, o.cod_galerie, a.cod_artist, a.nume FROM opera o, artist a WHERE o.cod_artist = a.cod_artist; Instruciunea urmtoare afieaz numele coloanelor i valorile YES/NO, dup cum aceste coloane sunt, sau nu, modificabile. SELECT COLUMN_NAME, UPDATABLE FROM USER_UPDATABLE_COLUMNS WHERE TABLE_NAME = 'OPERA_ARTIST'; Se va obine c doar primele trei coloane ale vizualizrii sunt modificabile. Indexul primar al coloanei cod_artist din tabelul artist nu este unic n vizualizarea opera_artist. Prin urmare, tabelul artist nu este keypreserved, iar coloanele sale nu sunt modificabile. Instruciunea urmtoare va genera eroarea ORA-01776: cannot modify more than one base table through a join view. INSERT INTO opera_artist VALUES (200, 'Poeme de l''ame', 20, 147, 'Janmot'); n schimb, instruciunea urmtoare va fi executat cu succes, ntruct adaug o nregistrare n tabelul de baz opera, ale crui coloane sunt modificabile.
INSERT INTO cod_galerie) opera_artist (cod_opera, titlu,

VALUES (200, 'Poeme de l''ame', 20);

Constrngeri asupra vizualizrilor

ncepnd cu versiunea Oracle9i pot fi specificate constrngeri pentru vizualizri. Se pot defini constrngeri la nivel de vizualizare, respectiv la nivel de coloan sau atribut. Constrngerile asupra vizualizrilor constituie o submulime a constrngerilor specifice tabelelor. Pot fi specificate explicit numai constrngerile UNIQUE, PRIMARY KEY i FOREIGN KEY. Constrngerea de tip CHECK poate fi realizat prin precizarea clauzei WITH CHECK OPTION n comanda care definete vizualizarea. Constrngerile asupra vizualizrilor pot fi definite numai n modul DISABLE NOVALIDATE. Aceste cuvinte cheie trebuie specificate la declararea constrngerii, nefiind permis precizarea altor stri. Exemplu:
81

S se creeze o vizualizare care conine codurile, numele i adresele galeriilor. Se va impune unicitatea valorilor coloanei adresa i constrngerea de cheie primar pentru coloana corespunztoare codului galeriei.
CREATE VIEW viz_galerie( cod_gal, nume, adresa UNIQUE DISABLE NOVALIDATE, CONSTRAINT cp_viz PRIMARY KEY (cod_gal) DISABLE NOVALIDATE) AS SELECT cod_galerie, nume_galerie, adresa FROM galerie;

Informaii despre obiectele bazei de date

Pot fi obinute consultnd DD(Dicionarul de Date). Dintre ele se remarc: definiiile tuturor obiectelor din baza de date; spaiul alocat i spaiul utilizat n prezent de obiectele schemei; constrngerile de integritate; numele utilizatorilor bazei; privilegiile i rolurile acordate fiecrui rol; alte informaii generale despre baza de date. Tabelul USER_CATALOG conine informaii despre tabelele i vizualizrile definite de un utilizator particular. Acest tabel poate fi referit i prin sinonimul su public CAT. Tabelul USER_OBJECTS conine informaii despre toate obiectele definite de utilizatorul curent. Tabelul are urmtoarea schem relaional: USER_OBJECTS (object_name, object_id, object_type, created, last_ddl_time, timestamp, status) Vizualizrile cele mai importante ale dicionarului datelor conin: descrierea tabelelor definite de utilizatori (USER_ALL_TABLES), informaii despre constrngerile definite de utilizator(USER_CONSTRAINTS), informaii despre legturile bazei de date (USER_DB_LINKS), erorile curente ale obiectelor depozitate (USER_ERRORS), informaii despre indecii creai de utilizator (USER_INDEXES), informaii despre tabelele utilizatorului (USER_TABLES) etc.

82

Vizualizrile din dicionarul datelor referitoare la tabele conin: USER_TAB_COLUMNS|COLS informaii despre coloanele tabelelor, USER_CONS_COLUMNS informaii despre constrngeri la nivel coloan, USER_TAB_COMMENTS informaii despre comentarii la nivel tabel, USER_COL_COMMENTS informaii despre comentarii la nivel coloan, USER_TAB_PARTITIONS informaii despre partiiile tabelelor.

83

Limbajul de interogare a datelor(DQL)

Limbajul SQL de interogare a datelor (DQL Data Query Language) include o singur comand SELECT, care este cea mai folosit pentru a obine date din baza de date, astfel nct acestea s fie prelucrate de o anumit aplicaie sau s fie afiate. Rezultatul unei instruciuni SELECT, numit i set de rezultate, este returnat sub forma unui tabel. Deoarece SQL este un limbaj neprocedural, se specific rezultatele pe care le dorii s le obinei, nu i modul lor de obinere. Instruciunea SELECT de baz Cererea (interogarea) este realizat de instruciunea SELECT. Cu ajutorul ei pot fi extrase submulimi de valori att pe vertical (coloane), ct i pe orizontal (linii) din unul sau mai multe tabele. Sintaxa comenzii este simpl, apropiat de limbajul natural. SELECT FROM [WHERE [GROUP BY [HAVING [ORDER BY [ALL | DISTINCT] {* | list de atribute selectate | expr AS alias} { [schema.]tabel [alias_tabel] } condiie] list de expresii condiie]] {expresie | poziie | c_alias} [ASC | DESC]]

Forma elementar a instruciunii SELECT conine dou clauze: SELECT [DISTINCT] - Specific lista de coloane care urmeaz s fie returnate n setul de rezultate, separate prin virgule. Se poate folosi simbolul asterisc (*) n locul listei de coloane pentru a selecta toate coloanele dintr-un tabel sau dintr-o vizualizare. Cuvntul cheie DISTINCT poate fi adugat dup cuvntul cheie SELECT pentru a elimina rndurile duplicate din rezultatele interogrii. FROM - Specific lista tabelelor sau vizualizrilor din care urmeaz s fie selectate datele. n locul numelor reale ale tabelelor sau vizualizrilor se poate folosi sinonime, adic pseudonime pentru tabele sau vizualizri definite n baza de date. Prezena clauzelor SELECT i FROM este obligatorie deoarece acestea specific coloanele selectate, respectiv tabelele din care se vor extrage datele. Tabelele specificate n clauza FROM pot fi urmate de un alias, care va reprezenta numele folosit pentru referirea tabelului respectiv n cadrul instruciunii.

Eliminarea duplicatelor se poate realiza folosind clauza DISTINCT. Dac nu se specific parametrul DISTINCT, parametrul ALL este implicit i are ca efect afiarea dublurilor. Simbolul * permite selectarea tuturor atributelor din tabelele asupra crora se execut cererea. Atributele sau expresiile din lista clauzei SELECT pot conine alias-uri, care vor reprezenta numele cmpurilor respective n cadrul tabelului furnizat ca rezultat de instruciunea SELECT. Clauza WHERE poate fi folosit pentru a impune anumite condiii liniilor din care se vor extrage atributele specificate n clauza SELECT. Clauza GROUP BY grupeaz nregistrrile dup anumite cmpuri; n cazul prezenei acestei clauze, clauza HAVING poate impune restricii suplimentare asupra rezultatului final. Ordonarea nregistrrilor se poate face cu ajutorul clauzei ORDER BY. Cu ajutorul parametrilor ASC i DESC se poate specifica ordonarea cresctoare, respectiv descresctoare a nregistrrilor. Pentru o secven cresctoare valorile null sunt afiate ultimele. Dac nu se face nici o specificaie, atunci ordinea de returnare este la latitudinea serverului.

n exemplul urmtor se selecteaz coloanele: COD_GEN_FILM, MPAA_RATING_COD i TITLU_FILM din tabelul FILM. SELECT COD_GEN_FILM, COD_ RATING, TITLU_FILM FROM FILM; Pseudonime pentru numele coloanelor In setul de rezultate din interogri numele coloanelor din tabel apare automat ca titlu de coloane n interogare. Dac se dorete un alt nume pentru coloanele unei interogri se folosesc pseudonime. Pseudonimele (aliases) specificate devin numele coloanelor din setul de rezultate. Pseudonimele nu exist dect dup rularea instruciunii SQL, aa c nu pot fi folosite n alte pri ale instruciunii SQL. Pseudonimul unei coloane este specificat prin plasarea cuvntului cheie AS" dup numele coloanei n lista SELECT (cu cel puin un spaiu nainte i dup), urmat de numele dorit pentru a fi atribuit coloanei n setul de rezultate. SELECT COD_GEN_FILM AS GEN, MPAA_RATING_COD AS RATING, TITLU_FILM AS FILM FROM FILM;

Dac n interiorul alias-ului apare un spaiu liber sau caractere speciale, atunci alias-ul trebuie scris ntre ghilimele. SELECT FROM dateresdataim numar zile imprumuta;

Sortarea rezultatelor Rezultatele interogrilor sunt deseori mult mai utile dac se specific pentru rndurile returnate o ordine care s aib o semnificaie pentru persoana sau aplicaia care folosete informaiile. n SQL, acest lucru este fcut prin adugarea n instruciunea SELECT a clauzei ORDER BY, cu o list de una sau mai multe coloane care vor fi folosite pentru sortarea rndurilor n ordine ascendent sau descendent, n conformitate cu valorile datelor din coloane. De asemenea, se ine seama de urmtoarele aspecte: Ordinea prestabilit pentru fiecare coloan este ascendent, dar se poate aduga cuvntul cheie ASC dup numele coloanei pentru obinerea unei ordonri ascendente sau cuvntul cheie DESC pentru obinerea unei ordonri descendente. Nu este obligatoriu ca numele coloanelor din lista ORDER BY s fie incluse i n lista de rezultate (adic n lista SELECT). Motorul SQL din SGBD va gsi cea mai bun cale de ordonare a coloanelor. n general, sortarea datelor este un proces costisitor din punct de vedere al resurselor de calcul, aa c majoritatea sistemelor SGBD folosesc un index pentru accesul la rnduri n ordinea dorit, presupunnd c exist, i fac o sortare propriu-zis numai ca ultim soluie. Se poate folosi pseudonimele coloanelor n clauza ORDER BY, dar dac se face acest lucru se foreaz motorul SQL s sorteze rezultatele abia dup rularea interogrii. n locul coloanelor, se poate specifica n lista de ordonare poziia relativ a coloanelor. De exemplu, clauza ORDER BY 1,2 va sorta rezultatele n ordine ascendent dup primele dou coloane din setul de rezultate. Numrul specificat nu are nici o legtur cu poziia coloanei n tabelul sau vizualizarea surs. Aceast opiune nu este agreat n programarea SQL formal, deoarece dac ulterior cineva modific interogarea, este posibil s amestece coloanele din lista SELECT, fr si dea seama c astfel schimb i coloanele folosite pentru sortarea rezultatelor. Exemplu: SELECT MPAA_RATING_COD AS RATING, COD_GEN_FILM AS GEN, TITLU_FILM AS FILM

FROM FILM ORDER BY MPAA_RATING_COD, COD_GEN_FILM ; Dac dorim s ordonm acum cresctor dup rating i descresctor dup gen, atunci instruciunea de mai sus modificat va fi SELECT MPAA_RATING_COD AS RATING, COD_GEN_FILM AS GEN, TITLU_FILM AS FILM FROM FILM ORDER BY MPAA_RATING_COD ASC, COD_GEN_FILM DESC; Observaie: Oracle va afia titlu de coloana la dimensiunea maxim a valorilor din coloana(de ex. dac n coloana RATING val cea mai mare este de 5 caractere, interogarea va afia RATIN). n noua versiune de SQL produs de Oracle, iSQL*Plus, nu mai prescurteaz. Exemplu : SELECT titlu, autor, pret, coded as domeniu from carte order by coded, autor; SELECT titlu, autor, pret, coded as domeniu from carte order by coded desc, pret; Se observa ca domeniu este trunchiat la 5 caractere, DOMEN

Utilizarea clauzei WHERE pentru filtrarea rezultatelor SQL folosete clauza WHERE pentru a filtra rndurile ce urmeaz s fie afiate. O interogare fr o clauz WHERE returneaz un set de rezultate care conine toate rndurile din tabelele sau vizualizrile referite n clauza FROM. Dac este inclus o clauz WHERE, sunt folosite regulile algebrei booleene, evalund clauza WHERE pentru fiecare rnd de date. n rezultatele interogrii sunt afiate numai rndurile pentru care clauza WHERE este evaluat la valoarea logic adevrat". Operatorii utilizai n clauza WHERE se impart n patru categorii: Operatori de comparare Operatori conjuctivi Operatori logici Operatori aritmetici Operatori de comparare
Operatorii de comparare sunt folosii n clauza WHERE pentru compararea a dou valori, avnd ca rezultat o valoare logic de adevrat" sau fals". Cele dou valori comparare pot fi constante furnizate n clauza WHERE, valori ale unor coloane din baza de date sau combinaii ale celor dou. Operatorii de comparare care pot fi folosii n clauza WHERE sunt prezentai n tabelul urmtor:

Operator = < <= > >= != <>

Descriere Egal cu Mai mic dect Mai mic sau egal Mai mare dect Mai mare sau egal Diferit de Diferit de (standard ANSI)

Exemple din schema FILM: S se afieze toate filmele pentru care RATING are valoarea PG-13. SELECT MPAA_RATING_COD AS RATING, TITLU_FILM FROM FILM WHERE MPAA_RATING_COD = 'PG-13' ORDER BY TITLU_FILM; S se afieze filmele pentru care COD_RATING are alt valoare dect PG-13. SELECT COD_RATING AS RATING, TITLU_FILM FROM FILM WHERE COD_RATING <> 'PG-13' ORDER BY TITLU_FILM; S se afieze toate filmele cu preul de vnzare cu amnuntul pentru formatul DVD(DVD Retail Price) mai mare de 25.00, n ordinea cresctoare a preurilor. SELECT PRET_VANZARE_DVD, TITLU_FILM FROM FILM WHERE PRET_VANZARE_DVD >= 25.00 ORDER BY PRET_VANZARE_DVD DESC; Exemple pe schema BIBLIOTECA

S se obtin codul crtii care are data restituirii >.. SELECT codel FROM imprumuta WHERE datares >= 05oct09;

S se obin titlurile i numrul de exemplare ale crilor care au nrex>100 ; SELECT titlu, nrex FROM carte WHERE nrex>100;

Operatori conjunctivi Uneori sunt necesare condiii multiple pentru a ngusta setul de rezultate al unei interogri. Atunci cnd sunt folosite mai multe condiii, ele trebuie s fie combinate din punct de vedere logic n clauza WHERE, iar aceasta este sarcina operatorilor conjunctivi. Aceti operatori sunt: AND (I) - Clauza WHERE este evaluat ca adevrat" dac toate condiiile conectate cu operatorul AND sunt adevrate. OR (SAU) - Clauza WHERE este evaluat ca adevrat" dac oricare din condiiile conectate cu operatorul OR este adevrat. Operatorul AND are prioritate mai mare i, ca urmare, este evaluat naintea operatorilor OR. Exemple de folosire a operatorilor conjunctivi:

S se afieze toate filmele pentru care categoria RATING este PG13 i preul de vnzare cu amnuntul pentru formatul DVD este 19.99 sau mai mic, n ordinea cresctoare a preurilor. SELECT COD_RATING AS RATING, PRET_VANZARE_DVD AS PRET, TITLU_FILM FROM FILM WHERE COD_RATING = 'PG-13' AND PRET_VANZARE_DVD <= 20.00 ORDER BY PRET_VANZARE_DVD;

S se afieze toate filmele pentru care categoria RATING este PG13 sau preul de vnzare cu amnuntul pentru formatul DVD este 19.99 sau mai mic, n ordinea cresctoare a preurilor. SELECT COD_RATING AS RATING, PRET_VANZARE_DVD AS PRET, TITLU_FILM FROM FILM WHERE COD_RATING = 'PG-13' OR PRET_VANZARE_DVD <= 20 ORDER BY PRET_VANZARE_DVD;

Afiai toate filmele pentru care categoria RATING este PG-13 i sunt din genul dram sau aciune/aventur. SELECT COD_RATING AS RATING, PRET_VANZARE_DVD AS PRET, TITLU_FILM FROM FILM WHERE COD_GEN_FILM= 'ActAd' OR COD_GEN_FILM = 'Drama' AND COD_RATING = 'PG-13' ORDER BY COD_GEN_FILM, COD_RATING;

S se adauge parantezele necesare, astfel nct s obinem filmele cu categoria PG-13 i genul aciune/aventur sau dram. SELECT COD_GEN_FILM AS GEN, COD_RATING AS RATING, TITLU_FILM FROM FILM WHERE (COD_GEN_FILM = 'ActAd' OR COD_GEM_FILM = 'Drama') AND COD_RATING='PG-13' ORDER BY COND_GEN_FILM, COD_RATING; Operatori logici

Operatorii logici folosesc cuvinte cheie n locul simbolurilor la formarea expresiilor de comparare. La oricare dintre aceti operatori poate fi adugat cuvntul cheie NOT, pentru a inversa valoarea logic a comparaiei.

IS NULL Operatorul IS NULL este folosit pentru a determina dac o valoare este nul. Exemple: S se gseasc toate conturile de clieni active, adic toate conturile pentru care coloana DATATERMINATA conine o valoare nul: SELECT ID_CONT_CLIENT FROM CONT_CLIENT WHERE DATA_INCHEIERE IS NULL;

S se gseasc toate conturile inactive, adic toate conturile pentru care coloana DATATERMINAT conine o alt valoare dect NULL: SELECT ID_CONT_CLIENT FROM CONT_CLIENT WHERE DATA_INCHEIERE IS NOT NULL;

BETWEEN Operatorul BETWEEN este folosit pentru a determina dac o valoare se ncadreaz ntr-un interval special. Intervalul este specificat folosind o valoare minim i o valoare maxim, fiind un interval inclusiv, ceea ce nseamn c include i valori specificate. Exemple: S se afieze toate filmele cu preul de vnzare cu amnuntul pentru formatul DVD ntre 14.99 i 19.99, ordonate cresctor dup pre. SELECT TITLU_FILM, PRET_VANZARE_DVD FORM FILM WHERE PRER_VANZARE_DVD BETWEEN 14.99 AND 19.99 ORDER BY PRER_VANZARE_DVD;

S se afieze toate filmele pentru care preul de vnzare cu amnuntul pentru formatul DVD nu este n intervalul 14.99-19.99, ordonate cresctor dup pre. SELECT TITLU_FILM, PRET_VANZARE_DVD FORM FILM WHERE PRET_VANZARE_DVD NOT BETWEEN 14.99 AND 19.99 ORDER BY PRET_VANZARE_DVD; S se afieze toate conturile de clieni n luna ianuarie 2009. SELECT ID_CONT_CLIENT, DATA_INSCRIERE FROM CONT_CLIENT WHERE DATA_INSCRIERE BETWEEN 2009/01/01 AND 2009/01/31;
9

Tabelul DUAL se afl n schema SYS i poate fi accesat de ctre toi utilizatorii. Tabelul este util atunci cnd se afieaz valoarea unei constante, pseudocoloane sau expresii care nu este construit pe baza datelor vreunui tabel. n general, tabelul DUAL este utilizat pentru a completa sintaxa instruciunii SELECT, ntruct clauzele SELECT i FROM sunt obligatorii. S se afieze data i ora curent. SELECT TO_CHAR(SYSDATE,DD/MM/YY HH24:MI:SS) FROM DUAL;

LIKE Operatorul LIKE este folosit pentru a compara o valoare de tip caracter cu un tipar*(pattern), returnnd valoarea logic adevrat dac valoarea de tip caracter se ncadreaz n tipar i fals" n caz contrar. Pentru definirea tiparului pot fi folosite dou caractere de nlocuire: Liniua de subliniere (_) - Caracterul liniu de subliniere poate fi folosit drept caracter de nlocuire poziional, ceea ce nseamn c se potrivete cu orice caracter aflat pe poziia respectiv n irul de caractere evaluat. Procent (%) - Simbolul procent (%) poate fi folosit drept caracter de nlocuire nepoziional, ceea ce nseamn c se potrivete cu orice numr de caractere, indiferent de lungime, reprezentnd orice secven de zero sau mai multe caractere, i _, reprezentnd un singur caracter. Exemple de tipare: Tipar Now% N_w Interpretare Se potrivete cu orice ir de caractere care incepe cu Now". Se potrivete cu orice ir de caractere format din exact trei caractere, care ncepe cu N" i se termin cu w".

10

%N-w%

%Now% %Now

Se potrivete cu orice ir de caractere care conine litera N", urmat de orice alt caracter, urmat de litera w" (1a nceputul, la sfritul sau undeva n mijlocul irului de caractere) Se potrivete cu orice ir de caractere care conine Now" (1a inceput, la sfrit sau n mijloc). Se potrivete cu orice ir de caractere care se termin cu Now".

Datele din bazele de date relaionale fac ntotdeauna diferenierea literelor mari de cele mici. O liter mica din date nu se potrivete cu o liter mare din tiparul unei clauze LIKE, i invers. Exemple de utilizare a operatorului LIKE: S se afieze toate titlurile de filme care conin irul de caractere on": SELECT TITLU_FILM FROM FILM WHERE TITLU_FILM LIKE '%on%'; Dac se intenioneaz s se gseasc titlurile care conin cuvntul on", nu literele on" din alte cuvinte, ar fi trebuit s includ n tipar i spatiile necesare, ca n exemplul urmtor: Exemple S se afieze cartile ale cror titlu conine cuvntul Baza, sau pentru care al treilea caracter din autor este p. SELECT titlu, autor FROM carte WHERE titlu LIKE '%Baza%' OR

autor LIKE '__p%';

11

IN Operatorul IN este folosit pentru a determina dac o valoare face parte dintr-o list de valori. Lista poate fi specificat ca valori literale, folosind o list de valori separate prin virgule i ncadrate ntre paranteze, sau poate fi selectat din baza de date folosind o subselecie (o subinterogare), care este o interogare n cadrul unei alte interogri. Exemple de utilizare a operatorului IN: S se afieze toate filmele pentru care COD_GEN_FILM este Drama, Forgn. SELECT COD_GEN_FILM AS GEN, TITLU_FILM FROM FILM WHERE COD_GEN_FILM IN ('Drama', 'Forgn') ORDER BY COD_GEN_FILM, TITLU_FILM; S se afieze toate filmele pentru care descrierea genului conine cuvntul and". Avei nevoie de o subinterogare prin care s gsii toate valorile COD_GEN_FILM care conin cuvntul and" n descriere. Operatorul IN este apoi folosit pentru a gsi filmele care au unul dintre codurile selectate de subinterogare. SELECT COD_GEN_FILM AS GEN, TITLU_FILM FROM FILM WHERE COD_GEN_FILM IN (SELECT COD_GEN_FILM FROM GEN_FILM WHERE GEN_FILM DESCRIPTION LIKE '% and %') ORDER BY COD_GEN_FILM AS GEN, TITLU_FILM; S se afieze toate cartile din domeniile Isi M. SELECT TITLU, AUTOR FROM CARTE WHERE CODED IN(I,M);

12

EXISTS Operatorul EXISTS este folosit pentru a detemina dac o subinterogare conine nregistrri. Dac n setul de rezultate al subinterogrii nu exist nici un rnd, operatorul returneaz valoarea false; dac setul de rezultate conine cel puin un rnd, valoarea devine adevrat. Exemple de utilizare a operatorului EXIST: Proprietarul magazinului a auzit c filmul The Last Samurai se nchiriaz bine att n format DVD, ct i-n format VHS i vrea s se asigure c n inventarul magazinului exist o copie VHS. Tabelul FILM_COPIAT conine un rnd pentru fiecare copie a unui film din inventarul magazinului, aa c putei folosi o subinterogare pentru a afla dac exist copii VHS ale filmului n inventar. De cele mai multe ori, operatorul EXISTS este folosit in conjuncie cu o form mai complex de subinterogare, numit subinterogare corelat. (correlated subquery),n care valorile datelor din interogarea extern (ID_FILM, n acest caz) sunt comparate cu rndurile din interogarea inten. SELECT ID_FILM, TITLU_FILM FROM FILM M WHERE TITLU_FILM = 'The Last Samurai' AND EXISTS (SELECT ID_FILM FROM FILM_COPIAT C WHERE M. ID_FILM = C. ID_FILM); Dac inversai logica, folosind operatorul NOT EXISTS, putei afia titlul filmului numai dac nu exist o copie VHS n inventar. SELECT ID_FILM, TITLU_FILM FROM FILM M WHERE TITLU_FILM = 'The Last Samurai' AND NOT EXISTS (SELECT ID_FILM FROM FILM_COPIAT C WHERE M. ID_FILM = C. ID_FILM);

13

Operatori aritmetici n SQL, operatorii aritmetici sunt folosii pentru efectuarea calculelor matematice la fel ca i n formulele dintr-o foaie de calcul tabelar sau ntr-un limbaj de programare, precum Java sau C. Cei patru operatori aritmetici din SQL sunt: Operator + * / Descriere Adunare Scdere nmulire mprire

Ca i n cazul operatorilor conjunctivi, dac se amestec operatorii aritmetici n aceeai instruciune SQL fr a folosi paranteze, ordinea n care sunt evaluate operaiile este determinat de prioritatea predefinit. Din fericire, prioritatea operatorilor din SQL este cea pe care o folosim n operaiile matematice obinuite. Exemple de utilizare a operatorilor aritmetici: Ct v-ar costa s cumprai copiile VHS i DVD ale filmului The Last Samurai? SELECT PRET_VANZARE_VHS + PRET_VANZARE _DVD AS COST FROM FILM WHERE TITLU_FILM = 'The Last Samurai'; Ct v-ar costa aceeai achiziie dac ai avea un bon valoric de 8 ron? SELECT (PRET_VANZARE _VHS + PRET_VANZARE _DVD) - 8 AS COST FROM FILM WHERE TITLU_FILM = 'The Last Samurai'; Dac taxele sunt de 8.25% (0.0825), ct reprezint taxele de vnzare din costul achiziiei anterioare? SELECT (PRET_VANZARE _VHS+ PRET_VANZARE _DVD) * 0.0825 AS TAX FROM FILM WHERE TITLU_FILM = 'The Last Samurai'; Care este costul mediu pentru o copie a filmului The Last Samurai? SELECT (PRET_VANZARE_VHS+PRET_VANZARE _DVD) / 2 AS AVG_COST FROM FILM WHERE TITLU_FILM = 'The Last Samurai'

14

Funcii SQL elementare

O funcie este un tip special de program, care returneaz o singur valoare de fiecare data cnd este apelat. Termenul provine de la conceptul matematic al unei funcii. n SQL, funciile necesit ntotdeauna specificarea unei expresii, care deseori include numele unei coloane. Cel mai des, funciile sunt folosite n lista de coloane a unei instruciuni SELECT, sunt apelate pentru fiecare rnd prelucrat de interogare i, ca urmare, returneaz o singur valoare pentru fiecare rnd din setul de rezultate. Uneori este folosit termenul funcie de coloan, pentru a indica faptul c o funcie este aplicat unei coloane dintr-un tabel sau o vizualizare. Un numr de funcii sunt furnizate de productorul DBMS i se pot scrie propriile funcii, folosind un limbaj special livrat mpreun cu sistemul DBMS, cum ar fi PL/SQL pentru Oracle sau Transact SQL pentru Microsoft SQL Server i Sybase Adaptive Server. Atenie la folosirea funciilor SQL n condiiile WHERE. n cele mai multe situaii, pentru o coloan creia i este aplicat o funcie nu poate fi folosit indexarea. Ca urmare, n cazul tabelelor mari, utilizarea funciilor n condiiile WHERE poate duce la probleme de performan cu adevrat memorabile. Funciile pot fi clasificate n multe moduri, dar majoritatea specialitilor le mpart dup ceea ce fac. Funcii pentru caractere Funciile pentru caractere sunt numite astfel deoarece manipuleaz date de tip text. Concatenarea irurilor de caractere Funcia de concatenare a irurilor de caractere reunete mai multe iruri de caractere pentru a forma o singur valoare n rezultatele interogrii. Funcia standard de concatenare a irurilor de caractere din SQL este apelat cu dou bare verticale (||), dar exist i excepii, cum ar fi Microsoft SQL Server, care folosete semnul plus (+) pentru concatenarea irurilor de caractere. Exemple de concatenare a irurilor de caractere: Magazinul de produse video vrea s trimit fiecrui client o scrisoare care ncepe cu formula "Client", plus prenumele i numele persoanei. Numele sunt stocate n tabelul PERSON. Soluia acestei cerinte n Oracle: SELECT 'Client' || NUME_PERSOANA|| ' ' || NUME_FAMILIE_PERSOANA AS SALUT_CLIENT FROM PERSOANA;
15

Aceeai soluie, modificat pentru a funciona n Microsoft SQL Server : SELECT Client' + NUME_PERSOANA + ' ' + NUME_FAMILIE_PERSOANA AS SALUT_CLIENT FROM PERSOANA; <nume angajat> castiga <salariu> lunar, dar doreste <salariu de 3 ori mai mare> SELECT last_name||'castiga'||salary||'lunar, dar doreste'||salary*3 "salariul ideal" FROM employees; UPPER Funcia UPPER este deseori folosit n condiiile WHERE. Funcia UPPER transform literele dintr-un ir de caractere n litere mari. Numerele i caracterele speciale sunt lsate ca stare. Exemple: S se afieze comediile (COD_GEN_FILM = 'Comdy') scriind titlurile cu majuscule. SELECT UPPER(TITLU_FILM) AS TITLU_FILM FROM FILM WHERE COD_GEN_FILM = 'Comdy'; S presupunem c nu v amintii dac valorile COD_GEN_FILM au fost stocate cu litere mari, litere mici sau combinaii ale acestora. Dac n condiia WHERE transformai valorile n litere mari, putei obine rezultatele corecte indiferent de modul de stocare. SELECT UPPER(TITLU_FILM) AS TITLU_FILM FROM FILM WHERE UPPER(COD_GEN_FILM) = 'COMDY'; LOWER Funcia LOWER este inversa funciei UPPER transform literele dintr-un * de caractere n litere mici. Exemple de utilizare a funciei LOWER: S se afieze comediile (GEN_COD_FILM = 'Comedy') scriind titlurile cu minuscule. SELECT LOWER(TITLU_FILM) AS TITLU_FILM FROM FILM WHERE GEN_COD_FILM = 'Comedy';

16

 Se poate folosi funcia LOWER ntr-o clauz WHERE, atunci cnd nu titi sigur ce tip de litere obine textul pe care vrei s-1 comparai. Afiai toate filmele care au n titlu cuvntul of ", indiferent dac este scris cu litere mari sau mici. SELECT TITLU_FILM FROM FILM WHERE LOWER(TITLU_FILM) LIKE ' % of %' OR LOWER(TITLU_FILM) LIKE 'of % ' OR LOWER(TITLU_FILM) LIKE ' % of '; SUBSTR Funcia SUBSTR apare n majoritatea implementrilor SQL, dar uneori are un nume puin diferit. De exemplu, funcia se numete SUBSTRING n Microsoft SQL Server, Sybase Adaptive Server i MySQL, dar SUBSTR n Oracle i D132. Funcia returneaz o poriune a irului de caractere, n funcie de parametrii furnizai, care specific numele coloanei, poziia de nceput a subirului n datele coloanei i lungimea subirului returnat (numrul de caractere). Dei este o utilizare mai puin obinuit, funcia SUBSTR accept i un ir de caractere literal n locul numelui unei coloane. Iat forma general a funciei, urmat de un exemplu: SUBSTR (numele coloanei, poziia de nceput, lungimea subirului n tabelul PERSON, unele persoane au al doilea nume n ntregime, alii au numai initiale. Afiati numele complet al persoanelor al cror nume de familie ncepe cu litera B", sub forma unui singur ir de caractere care conine prenumele, iniiala i numele de familie. SELECT NUME_PERSOANA || ' ' || SUBSTR(PRENUME_PERSOANA, 1, 1) || ' . ' || NUME_FAMILIE_PERSOANA AS NUME_INTREG FROM PERSOANA WHERE SUBSTR(NUME_FAMILIE_PERSOANA, 1, 1)='B' Observai folosirea funciei SUBSTR n clauza WHERE pentru a elimina din rezultate persoanele al cror nume de familie nu ncepe cu litera B". Ar trebui s v putei deja gndi la alte moduri de a face acest lucru, prin folosirea operatorului LIKE.

17

LENGTH Funcia LENGTH returneaz lungimea unui ir de caractere. Microsoft SQL Server i Sybase Adaptive Server folosesc numele LEN pentru versiunea proprie a acestei funcii. Exemple: S se afieze lungimea titlului pentru filmul a crui valoare ID_FILM este 1. Presupunem c folosii o baz de date oracle, DB2 sau MySQL. SELECT TITLU_FILM, LENGTH (TITLU_FILM) AS LENGTH FROM FILM WHERE ID_FILM = 1; SELECT TITLU_FILM, LENGTH (TITLU_FILM) AS LENGTH FROM FILM WHERE LENGTH (TITLU_FILM) < 10; Funii matematice Funciile matematice manipuleaz valori numerice, n conformitate cu regulile matematicii. ROUND Funcia ROUND rotunjete o valoare la un numr specificat de zecimale. Valoarea numeric este furnizat prin primul parametru, iar numrul de zecimale prin cel de-al doilea. n continuare este prezentat formatul general al funciei ROUND. ROUND (expresie numeric, numr de poziii zecimale) Care este costul mediu al unei copii a filmului The Last Samurai, rotunjit la dou zecimale? SELECT ROUND((PRET_VANZARE_VHS + PRET_VANZARE _DVD) / 2, 2) AS AVG_COST FROM FILM WHERE TITLU_FILM = 'The Last Samurai'; Alte funcii matematice Tabelul care urmeaz prezint funciile matematice cel mai des ntlnite. Pentru toate, sintaxa general este aceeai: NUME_FUNCTIE (expresie)

18

Funcie ABS COS EXP POWER SIN TAN

Descriere Valoarea absolut a unui numr dat Cosinusul trigonometric al unui unghi specificat n radiani Valoarea exponenial a unui numr dat Ridic un numr la o putere (numrul i puterea sunt fumizate ca parametri) Sinusul trigonometric al unui unghi specificat n radiani Tangenta trigonometric a unui unghi specificat n radiani

Funcii de conversie Funciile de conversie transform date dintr-un tip de date n altul. CAST Funcia CAST transform date dintr-un tip de date n altul. Iat sintaxa general a funciei CAST, urmat de un exemplu: CAST (expresie AS tip de date) Afiati preul pentru formatul DVD al filmului The Last Samurai, cu un simbol dolar n faa sumei. Valoarea numeric trebuie s fie convertit ntr-un ir de caractere pentru a putea fi concatenat cu o valoare literal coninnd simbolul dolar. SELECT '$' || CAST(PRET_VANZARE _DVD AS VARCHAR(6)) AS PRET FROM FILM WHERE TITLU_FILM = 'The Last Samurai';

Funcii de agregare i gruparea rndurilor O funcie de agregare (aggregate functions) este o funcie care combin mai multe rnduri de date ntr-un singur rnd. Tabelul urmtor prezint funciile de agregare acceptate n majoritatea implementrilor SQL: Funcie Descriere AVG Calculeaz valoarea medie pentru o coloan sau o expresie. COUNT Numr valorile dintr-o coloan. MAX Gsete valoarea maxin dintr-o coloan. MIN Gsete valoarea minim dintr-o coloan. SUM nsumeaz valorile dintr-o coloan. Exemple: Care este preul mediu al unui DVD?

19

SELECT ROUND(AVG(PRET_VANZARE _DVD),2) AS AVG_PRET FROM FILM; Cte filme exist n tabelul FILM? SELECT COUNT(*) AS NUM_FILM FROM FILM; Cte genuri diferite de filme sunt reprezentate n tabelul FILM? SELECT COUNT(DISTINCT COD_GEN_FILM) AS NUM_GEN FROM FILM; Care sunt lungimea minim i maxim a titlurilor filmelor? SELECT MIN(LENGTH(TITLU_FILM)) AS MIN_LENGTH, MAX(LENGTH(TITLU_FILM)) AS MAX_LENGTH FROM FILM; Clauza GROUP BY GROUP BY cere sistemului DBMS s grupeze rndurile selectate de interogare pe baza valorilor din una sau mai multe coloane i s aplice funcia (sau funciile) de agregare fiecrui grup, returnnd un rnd pentru fiecare grup din setul de rezultate. Sistemul DBMS va ordona rndurile selectate de interogare dup coloanele din clauza GROUP BY, aa c grupurile vor fi returnate n ordine ascendent, exceptnd cazul n care se adug o clauz ORDER BY care specific un alt mod de ordonare. Iat un exemplu: Afiati fiecare cod de gen, mpreun cu numrul de filme asociate fiecrui cod. SELECT COD_GEN_FILM AS GEN, COUNT(*) AS COUNT FROM FILM GROUP BY COD_GEN_FILM; Ce se ntmpl dac scoatei clauza GROUP BY din aceast interogare? Sistemul DBMS retumeaz un mesaj de eroare i, din nefericire, mesajul de eroare este deseori destul de criptic. Functia COUNT(*) este o functie de agregare i, n absenta clauzei GROUP BY, retumeaz un singur rnd de date. Exemplele care urmeaz arat modul general de constituire a subansamblelor virtuale folosind clauza GROUP BY. Fiecare expresie care apare n SELECT trebuie s aib aceeai valoare pentru toate liniile care aparin aceleiai partiii. Numele coloanelor din GROUP BY nu trebuie s figureze obligatoriu n lista de la SELECT. Clauza WHERE are prioritate fata de GROUP BY. Nu se poate utiliza alias de coloana in clauza GROUP BY.
20

Pentru a returna informatie corespunxatoare fiecarui grup, pot fi utilizate functiile agregat. Acestea pot aparea in clauzele SELECT, ORDER BY si HAVING. Se poate utiliza functie grup in clauza WHERE? Este corect WHERE AVG(sal) > 200? NU! Cand se utilizeaza GROUP BY, server-ul sorteaza implicit multimea rezultata in ordinea crescatoare a valorilor coloanelor dupa care se realizeaza gruparea. Grupurile sunt formate si functiile grup sunt calculate, inainte ca clauza HAVING sa fie aplicata grupurilor. Exemplu: S se obin numrul de cte ori a fost mprumutat fiecare carte. SELECT codel, COUNT(*) FROM imprumuta GROUP BY codel; Exemplu: Pentru fiecare domeniu de carte s se obin numrul crilor din domeniu, media preurilor i numrul total de exemplare. SELECT coded,COUNT(*), AVG(pret),SUM(nrex) FROM carte GROUP BY coded; Dac n comanda SELECT apar atribute coloan (nu funcii grup) i se utilizeaz clauza GROUP BY atunci aceste coloane trebuie obligatoriu s apar n clauza GROUP BY. Exemplu: S se obin pentru fiecare autor, media preurilor crilor din bibliotec. SELECT autor, AVG(pret) FROM carte GROUP BY autor; Exemplu: Pentru departamentele n care salariul maxim depete 5000$ s se obin codul acestor departamente i salariul maxim pe departament. SELECT FROM GROUP BY HAVING deptno, MAX(sal) emp deptno MAX(sal)>5000;

21

Exemplu: SELECT FROM GROUP BY MAX(AVG(pret)) carte autor;

Exemplu: S se afieze numele i salariul celor mai prost pltii angajai din fiecare departament.

SELECT
FROM WHERE

ename, sal

emp (deptno, sal) IN (SELECT deptno, MIN(sal) FROM emp GROUP BY deptno);

Exemplu: S se obin pentru fiecare carte, codul su i numrul de exemplare care nu au fost nc restituite. SELECT FROM codel, COUNT(*) imprumuta

WHERE dataef IS NULL GROUP BY codel; Exemplu: S se obin numrul crilor mprumutate cel puin o dat. SELECT COUNT(DISTINCT codel) FROM imprumuta; Exemplu: S se afieze numrul crilor mprumutate cel puin de dou ori (pentru fiecare carte mprumutat mai mult dect o dat s se obin numrul de cte ori a fost mprumutat). SELECT FROM GROUP BY HAVING COUNT(COUNT(codel)) imprumuta codel COUNT(*)>1;

22

n cererea anterioar COUNT(codel), reprezint numrul care arat de cte ori a fost mprumutat fiecare carte, iar COUNT(COUNT(codel)), reprezint numrul total al crilor mprumutate. Exemplu: Pentru fiecare departament codul dep si numarul de angajati. 1 select department_id, count(*) 2 from employees 3* group by department_id SQL> / DEPARTMENT_ID COUNT(*) ------------- ---------10 1 20 2 30 6 40 1 50 45 60 5 70 1 80 34 90 3 100 6 110 2 1 12 rows selected. Pentru departamentele cu mai mult de un angajat se afiseaza codul dep si numarul de angajati. 1 select department_id, coun 2 from employees 3 group by department_id 4* having count(*)>1 SQL> / DEPARTMENT_ID COUNT(*) ------------- ---------20 2 30 6 50 45 60 5 80 34 90 3
23

100 110 8 rows selected.

6 2

Se afiseaza numarul departamentelor cu mai mult de un angajat. 1 select count(count(*)) 2 from employees 3 group by department_id 4* having count(*)>1 SQL> / COUNT(COUNT(*)) --------------8 Exemplu: Sa se afiseze numrul de cri imprumutate din fiecare domeniu. SELECT d.intdom, COUNT(*) FROM domeniu d, carte c, imprumuta I WHERE c.codel = i. codel AND c.coded = d.coded GROUP BY intdom;

Exemplu: Lista codurilor cititorilor care au mai mult de 3 cri nerestituite la termen.

SELECT

codec

FROM imprumuta WHERE dataef IS NULL AND datares < SYSDATE GROUP BY codec HAVING COUNT(*) > 2; Exemplu: Pentru fiecare domeniu de carte care conine cel puin o carte i unde preul oricrei cri nu depete o valoare dat, s se obin: codul domeniului, numrul crilor din domeniu i numrul mediu de exemplare. SELECT coded, COUNT(*), AVG(nrex) FROM carte GROUP BY coded
24

HAVING AND

COUNT(*) >= 1 MAX(pret) < &pret_dat;

Exemplu: Codurile domeniilor care nu contin carti. SELECT coded FROM carte GROUP BY coded HAVING COUNT(*) = 0; Nu este corect, deoarece se iau in considerare NUMAI codurile domeniilor care apar in tabelul CARTE. SELECT intdom FROM domeniu d WHERE 0 = (SELECT COUNT(*) FROM carte WHERE coded = d.coded); Urmatoarea cerere este corecta? SELECT intdom FROM domeniu d,(SELECT coded, COUNT(*) a FROM carte GROUP BY coded) b WHERE b.coded = d.coded) AND b.a = o; Exemplu: n ce interogri este necesar utilizarea cuvntului cheie HAVING? A. B. C. D. cnd este necesar s eliminm linii duble din rezultat; cnd este necesar s ordonm mulimea rezultat; cnd este necesar s efectum un calcul pe grup; cnd este necesar s restricionm grupurile de linii returnate.

Operatori pentru interogri compuse Uneori este util s se ruleze interogri multiple i s se combine rezultatele ntr-un singur set de rezultate. UNION Operatorul UNION adaug rndurile din setul de nregistrri al unei interogri la cel al unei alte inregistrri i, n acelai timp, elimin rndurile duplicate, ntr-un mod similar cu cel al cuvntului cheie

25

DISTINCT. Operaia este permis numai dac interogrile sunt compatibile din punctul de vedere al uniunii, ceea ce nseamn c au acelai numr de coloane i c tipurile de date ale coloanelor corespondente sunt compatibile. Iat un exemplu: Afiai pe o singur coloan toate valorile nenule pentru taxa de inchiriere i taxa de ntrziere din tabelul FILM_NCHIRIAT. SELECT INCHIRIAT_FEE AS FEE FROM FILM_INCHIRIAT WHERE INCHIRIAT _FEE IS NOT NULL UNION SELECT LATE_OR_LOSS_FEE AS FEE FROM FILM_INCHIRIAT WHERE LATE _OR_ LOSS FEE IS NOT NULL; UNION ALL UNION ALL funcioneaz la fel ca i operatorul UNION, exceptnd faptul c rndurile duplicate nu sunt eliminate. INTERSECT Operatorul INTERSECT gsete valorile selectate dintr-o interogare, care apar i ntr-o alt interogare. n esen, gsete intersecia valorilor din cele dou interogri. Totui, doar un numr mic de sisteme DBMS (cele mai importance fiind Oracle i DB2) implementeaz acest operator. Nu-1 vei gsi n Microsoft SQL Server sau MySQL. Iat un exemplu: Exist n tabelul FILM filme pentru care preul pentru DVD este egal cu preul pentru VHS? SELECT INCHIRIAT_FEE AS FEE FROM FILM_ INCHIRIAT WHERE INCHIRIAT _FEE IS NOT NULL INTERSECT SELECT LATE_OR_LOSS_FEE AS FEE FROM FILM_ INCHIRIAT WHERE LATE OR_ LOSS FEE IS NOT NULL

EXCEPT EXCEPT este operatorul standard ANSI/ISO care gsete diferenele dintre dou seturi de rezultate, returnnd, n esen, valorile

26

din prima interogare care nu apar n cea de-a doua interogare. Foarte puine sisteme DBMS implementeaz acest operator. n unele implementri, precum Oracle, operatorul se numete MINUS, nu EXCEPT.

27

Cereri multi relaie

Comanda SELECT ofer posibilitatea de a consulta informaii care provin din mai multe tabele. Operatorii care intervin n astfel de cereri pot fi: operatori pe mulimi (UNION, UNION ALL, INTERSECT, MINUS); operatori compunere care implementeaz diferite tipuri de JOIN. Exist dou moduri de realizare a cererilor multi-relaie: forma procedural, n care trebuie indicat drumul de acces la informaie prin imbricarea de comenzi SELECT; forma relaional, n care drumul de acces la informaie este n sarcina sistemului. Exemplu: S se obin, utiliznd aceste dou forme, codurile i titlurile crilor mprumutate. a) Forma procedural (imbricare de comenzi SELECT): SELECT codel, titlu FROM carte WHERE codel IN (SELECT DISTINCT codel FROM imprumuta); b) Forma relaional: SELECT carte.codel, titlu FROM carte, imprumuta WHERE carte.codel = imprumuta.codel;

Operatori pe mulimi sau Operatori pentru interogri

compuse (UNION, UNION ALL, INTERSECT, MINUS)
Uneori este util s se ruleze interogri multiple i s se combine rezultatele ntr-un singur set de rezultate. Operatorii pe mulimi combin rezultatele obinute din dou sau mai multe interogri. Cererile care conin operatori pe mulimi se numesc cereri compuse. Exist patru operatori pe mulimi: UNION, UNION ALL, INTERSECT i MINUS(n unele implementeri oracle operatorul MINUS se numete EXCEPT). Toi operatorii pe mulimi au aceeai preceden. Dac o instruciune SQL conine mai muli operatori pe mulimi, server-ul Oracle evalueaz cererea de la stnga la dreapta (sau de sus n jos). Pentru a schimba aceast ordine de evaluare, se pot utiliza paranteze.

n mod implicit, pentru toi operatorii cu excepia lui UNION ALL, rezultatul este ordonat cresctor dup valorile primei coloane din clauza SELECT. Pentru o cerere care utilizeaz operatori pe mulimi, cu excepia lui UNION ALL, server-ul Oracle elimin liniile duplicat. n instruciunile SELECT asupra crora se aplic operatori pe mulimi, coloanele selectate trebuie s corespund ca numr i tip de date. Nu este necesar ca numele coloanelor s fie identice. Numele coloanelor din rezultat sunt determinate de numele care apar n clauza SELECT a primei cereri. n cazul n care cererile componente selecteaz date de tip caracter, tipul de date al valorii returnate poate fi CHAR, dac valorile selectate de ambele cereri sunt de tip CHAR, sau VARCHAR2, dac valorile selectate de cel puin una din cele dou cereri sunt de tip VARCHAR2. Observaii: Comenzile SELECT, care intervin n cereri ce conin operatori pe mulimi, trebuie s satisfac anumite condiii: toate comenzile SELECT trebuie s aib acelai numr de coloane; opiunea DISTINCT este implicit (excepie UNION ALL); numele coloanelor sunt cele din prima comand SELECT; dimensiunea coloanei implicit este cea mai mare dintre cele dou coloane; sunt admise combinaii de forma: 1. SELECT1 UNION SELECT2 INTERSECT SELECT3 i ordinea de execuie este de la stnga la dreapta; 2. SELECT1 UNION (SELECT2 INTERSECT SELECT3) i ordinea este dat de paranteze. UNION Operatorul UNION adaug rndurile din setul de nregistrri al unei interogri la cel al unei alte interogri i, n acelai timp, elimin rndurile duplicate, ntr-un mod similar cu cel al cuvntului cheie DISTINCT. Operatorul UNION returneaz deci toate liniile selectate de dou cereri, eliminnd duplicatele. Operaia este permis numai dac interogrile sunt compatibile din punctul de vedere al uniunii, ceea ce nseamn c au acelai numr de coloane i c tipurile de date ale coloanelor corespondente sunt compatibile. Acest operator nu ignor valorile null i are preceden mai mic dect operatorul IN.

Exemplu: S se afieze pe o singur coloan toate valorile nenule pentru taxa de inchiriere i taxa de ntrziere din tabelul FILM_NCHIRIAT.
SELECT taxa_inchiriat AS TAXA FROM FILM_INCHIRIAT WHERE taxa_inchiriat IS NOT NULL UNION SELECT taxa_intarziere AS TAXA FROM FILM_INCHIRIAT WHERE taxa_intarziere IS NOT NULL;

Exemplu: S se afieze codurile operelor de art pentru care a fost ncheiat o poli de asigurare sau care beneficiaz de un sistem de securitate. Fiecare cod va fi afiat o singur dat. SELECT FROM UNION SELECT FROM cod_opera polita_asig cod_opera securitate;

Uneori, pentru a respecta regula conform creia expresiile din clauzele SELECT trebuie s concorde ca numr i tip de date, se pot utiliza coloane artificiale i funcii de conversie pentru tipurile de date. Exemplu: S se listeze codul operelor de art, codul i numele artitilor. SELECT FROM UNION SELECT FROM cod_opera, cod_artist, TO_CHAR(null) nume opera TO_NUMBER(null), cod_artist, nume artist;

UNION ALL Operatorul UNION ALL funcioneaz la fel ca i operatorul UNION, exceptnd faptul c rndurile duplicate nu sunt eliminate. Precizrile fcute asupra operatorului UNION sunt valabile i n cazul operatorului UNION ALL. n cererile asupra crora se aplic UNION ALL nu poate fi utilizat cuvntul cheie DISTINCT.

Exemplu: S se determine codul operelor de art pentru care s-a ncheiat o poli de asigurare sau pentru care s-a achiziionat un sistem de securitate. S se afieze firma i data contractrii, respectiv a instalrii sistemului. ntruct o oper poate avea mai multe polie de asigurare sau mai multe sisteme de securitate ncheiate, respectiv instalate la aceeai firm i dat, nu se vor suprima liniile duplicat. Rezultatul va fi ordonat dup codul operelor. SELECT cod_opera, firma, semnat_contract FROM polita_asig UNION ALL SELECT cod_opera, firma, data_inst FROM polita_asig ORDER BY cod_opera; Clauza ORDER BY poate aprea numai o singur dat ntr-o cerere compus. Dac se utilizeaz, clauza trebuie plasat la sfritul cererii i accept nume de coloane, alias-uri sau notaia poziional. Numele de coloane i alias-urile din clauza ORDER BY trebuie s fie din lista SELECT a primei instruciuni. INTERSECT Operatorul INTERSECT gsete valorile selectate dintr-o interogare, care apar i ntr-o alt interogare. n esen, gsete intersecia valorilor din cele dou interogri. Acest operator nu ignor valorile null. Totui, doar un numr mic de sisteme DBMS (cele mai importance fiind Oracle i DB2) implementeaz acest operator. Nu-1 vei gsi n Microsoft SQL Server sau MySQL. Exemplu: Exist n tabelul FILM filme pentru care preul pentru DVD este egal cu preul pentru VHS? SELECT taxa_inchiriat AS TAXA FROM FILM_INCHIRIAT WHERE taxa_inchiriat IS NOT NULL INTERSECT SELECT taxa_intarziere AS TAXA FROM FILM_INCHIRIAT WHERE taxa_intarziere IS NOT NULL;

Exemplu: S se afieze codul operelor de art, respectiv data la care s-a ncheiat o poli de asigurare i s-a instalat un sistem de securitate. SELECT cod_opera, semnat_contract FROM polita_asig INTERSECT SELECT cod_opera, data_inst FROM securitate; Exemplu: S se obin, utiliznd operatorul INTERSECT, codurile crilor din care sunt mai puin de 15 exemplare i care au fost mprumutate de cel puin trei ori. SELECT codel FROM carte WHERE nrex < 15 INTERSECT SELECT codel FROM imprumuta GROUP BY codel HAVING COUNT(*) > 3; MINUS Operatorul MINUS sau EXCEPT gsete diferenele dintre dou seturi de rezultate, returnnd, n esen, valorile din prima interogare care nu apar n cea dea doua interogare. Pentru ca operatorul MINUS s funcioneze, este necesar ca toate coloanele din clauza WHERE s se afle i n clauza SELECT. Foarte puine sisteme DBMS implementeaz acest operator. n unele implementri, precum Oracle, operatorul se numete MINUS, nu EXCEPT. Exemplu: S se determine codul i valoarea operelor de art al cror pre nu este de 20 de ori mai mare dect valoarea poliei de asigurare. SELECT cod_opera, valoare

FROM opera MINUS SELECT cod_opera, valoare*20 FROM polita_asig; Exemplu: S se afieze codurile cititorilor care nu au mprumutat cri. SELECT codec FROM cititor MINUS SELECT DISTINCT codec FROM imprumuta; Operatorii pe mulimi pot fi utilizai n subcereri. Coloanele care apar n clauza WHERE a interogrii trebuie s corespund, ca numr i tip de date, celor din clauza SELECT a subcererii. Exemplu: S se determine codul operelor de art, codul autorilor i titlul pentru operele a cror valoare este mai mare dect 5000 sau pentru cele avnd valoarea de 20 de ori mai mare dect cea a poliei de asigurare. SELECT cod_opera, cod_artist, titlu FROM opera WHERE (cod_opera, valoare) IN (SELECT cod_opera, valoare FROM opera WHERE valoare > 5000 UNION SELECT cod_opera, valoare*20 FROM polita_asig);

Operaia de compunere (JOIN)

S-au prezentat pn acum instruciuni SQL care selecteaz date dintr-un singur tabel. Deseori, este util s se combine date din tabele multiple ntr-o singur interogare. De exemplu, n listingul celor trei coloane ale tabelului FILM din figura urmtoare, observai valorile afiate pentru coloan FILM_GEN_COD. Atunci cnd s-a proiectat baza de date pentru magazinul de produse video, s-au folosit coduri n locul descrierilor complete pentru genurile filmelor n tabelul FILM. Din discuia despre procesul de normalizare, s-a evitat anomalia de actualizare dac se schimb descrierea unui gen, nu este nevoie s actualizm acea descriere pentru toate filmele asociate genului respectiv n tabelul FILM. n timpul normalizrii, descrierea genurilor a fost mutat n tabelul, FILM_GEN, iar coloan FILM_GEN_COD a devenit cheie extern n tabelul FILM, referind coloan cheie primar (cu acelai nume) din tabelul FILM_GEN. S-a optat pentru folosirea unui cod mnemonic pentru codurile genurilor. Tabelul FILM (trei coloane) FILM_COD FILM_GEN_COD
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Drama ActAd Comedie ActAd ActAd ActAd Drama ActAd ActAd Drama Rmce Comedie Comedie Drama Drama Comedie Rmce Drama ActAd Forgn

FILM_TITLU

Mystic River The Last Samurai Something's Gotta Grve The Italian Kill Bill: Voi. 1 Pirates of the Caribbean: Trie Curse of the Black Pearl Big Fish Man on Fire Master and Commander The Far Side of the World LosI n Translation Two Weeks Notice 50 First Dates Matchstick Men Cold Mountain Road to Perdition The School of Rock 13 Going on30 Monster The Day After Tomorrow Das Boot

Evident, nu putei afia pe pagina web a magazinului de produse video, tabelul FILM aa cum este prezentat n figura de mai sus - trebuie s obinei descrierea complet a genurilor din tabelul FILM_GEN. Aceasta este ideea capitolului de fa: combinarea datelor din mai multe tabele ntr-o singur interogare. Figura urmtoare prezint un listing al tabelului FILM_GEN. Tabelul FILM_GEN FILM_GEN_COD ActAd Anime ChFam Class Comedie Doc Drama Forgn Hor Indep Music Rmce SciFi Sport Thriller FILM_GEN_DESCRIERE Actiune Animatie Copii i Familie Clasic Comedie Documentar Drama Strain Horror Independent Muzical Romance(Romantic, Idila) Stiintifico-Fantastic Sport Groaza

Uniuni (join) O uniune (join) este o operaie ntr-o baz de date relaionale care combin coloane din dou sau mai multe tabele n rezultatele unei singure interogri. O uniune apare de fiecare dat cnd clauza FROM a unei instruciuni SELECT specific numele mai multor tabele. De exemplu: SELECT FILM_ID, FILM_GEN_DESCRIERE AS GEN, FILM_TITLU FROM FILM, FILM_GEN ORDER BY FILM_ID;

FILM_ID GEN FILM_TITLU 1 Actiune i Aventura Mystic River 1 Animatie Mystic River 1 Clasic Mystic River 1 Documentar Mystic River 1 Strain Mystic River 1 Independent Mystic River 1 Groaza Mystic River 1 Sport Mystic River 1 SF Mystic River 1 Musical Mystic River 1 Horror Mystic River 1 Drama Mystic River 1 Comedie Mystic River 1 Copii i Familie Mystic River 1 Actiune i Aventura The Last Samurai 2 Thriller The Last Samurai 2 Sport The Last Samurai 2 SF The Last Samurai 2 Romantic The Last Samurai 2 Musical The Last Samurai 2 Independent The Last Samurai 2 Horror The Last Samurai 2 Animatie The Last Samurai 2 Copii i Familie The Last Samurai 2 Documentar The Last Samurai 2 Strain The Last Samurai 2 Drama The Last Samurai 2 Comedie The Last Samurai 2 Clasic The Last Samurai .. ... ............... Setul de rezultate al interogrii a fost trunchiat dup primele dou titluri de filme. Problema este c am cerut bazei de date s uneasc tabelele, dar nu i-am spus care este corespondena dintre rndurile celor dou tabele. Rezultatul este cunoscut sub numele de produs cartezian (dup numele filozofului i matematicianului francez Rene Descartes) i, n bazele de date relaionale, este un set de rezultate obinut prin uniunea dintre fiecare rnd al unui tabel cu fiecare rnd dintr-un alt tabel.

Soluia este s specificm cum se va face unirea tabelelor. Trebuie indicat ce coloane ar trebui s se potriveasc pentru a uni dou rnduri din cele dou tabele, n mod normal, cele dou coloane vor fi cheia primar dintr-un tabel i cheia extern din cellalt tabel, dar pot exist i excepii. Pentru a realiza acest lucru trebuie s se fac o o uniune standard relaional, cunoscut i sub numele de uniune de egalitate (equijoin). Join-ul este operaia de regsire a datelor din dou sau mai multe tabele, pe baza valorilor comune ale unor coloane. De obicei, aceste coloane reprezint cheia primar, respectiv cheia extern a tabelelor. Condiia de join se scrie n clauza WHERE a instruciunii SELECT. ntr-o instruciune SELECT care unete tabele prin operaia de join, se recomand ca numele coloanelor s fie precedate de numele tabelelor pentru claritate i pentru mbuntirea timpului de acces la baza de date. Dac acelai nume de coloan apare n mai mult de dou tabele, atunci numele coloanei se prefixeaz obligatoriu cu numele tabelului corespunztor. Pentru a realiza un join ntre n tabele, va fi nevoie de cel puin n 1 condiii de join. Equijoin-ul corespunde situaiei n care valorile de pe coloanele ce apar n condiia de join trebuie s fie egale. Un astfel de join mai poart numele de join simplu sau inner join. Un nonequijoin este o condiie de join care conine ali operatori dect operatorul egalitate. Un self join realizeaz compunerea unui tabel cu el nsui.

Uniuni de egalitate (equijoin)

Avem o uniune de egalitale (equijoin), numit i uniune intern (inner join), atunci cnd legm una sau mai multe coloane dintr-un tabel (de obicei, o cheie extern) cu coloane similare dintr-un alt tabel (de obicei, cheia primar), folosind condiia de egalitale, aceasta fiind cea mai des folosit form de uniune. Totusi, termenul uniune de egalitate (equijoin) este rareori folosit n afara mediilor academice, find preferate denurmirile uniune intern (inner join) sau uniune standard (standard join). Exist dou modaliti de specificare a coloanelor corespondente: folosind clauza WHERE sau folosind clauza JOIN. Clauza JOIN a fost adugat relativ recent n standardul SQL, aa c programatorii mai vechi sunt obisnuii cu metoda bazat pe clauza WHERE.

Realizarea uniunilor folosind clauza WHERE Folosirea clauzei WHERE pentru unirea tabelelor seamn cu folosirea acesteia pentru eliminrea rndurilor de care nu avei nevoie din setul de rezultate. Totui, exist unele diferene. n clauza WHERE : Se compar o coloan cu o alt coloan, nu o coloan cu o constant sau o expresie. Atunci cnd coloanele din cele dou tabele au acelai nume (o soluie recomandat) trebuie s specificati numele complet al coloanelor (adic numele cu calificator), astfel nct motorul SQL s tie care dintre cele dou coloane este referit. Motorul SQL cere s se refere toate coloanele specificate ntr-o instruciune SQL. Aceasta nu nseamn numai coloanele din clauza WHERE, ci din orice alt loc al instrucunii, inclusiv n lista SELECT. Cea mai simpl form de calificator este chiar numele tabelului, separat cu caracterul punct de numele coloanei. n continuare este prezentat un exemplu de uniune realizat prin clauza WHERE, cu numele coloanelor specificate complet, folosind numele tabelelor. Observai c interogarea selecteaz coloanele FILM_ID i FILM_TITLU din tabelul FILM i genul corespunztor (FILM_GEN_DESCRIERE) din tabelul FILM_GEN. SELECT FILM_ID, FILM_GEN_DESCRIERE AS GEN, FILM_TITLU FROM FILM, FILM_GEN WHERE FILM.FILM_GEN_COD= FILM_GEN.FILM_GEN_COD ORDER BY FILM_ID; FILM_ID
1 2 3 4 5 6 7 8 9 10 11 12 Drama Actiune i Aventura Comedie Actiune i Aventura Actiune i Aventura Actiune i Aventura Drama Actiune i Aventura Actiune i Aventura Drama Romantic Comedie

FILM_GEN

FILM_TITLU
Mystic River The Last Samurai Something's Gotta Give The Italian Job Kill Bill Vol. 1 Pirates of the Caribbean Big Fish Man on Fire Master and Commander Lost n Translation Two Weeks Notice 50 First Dates

13 14 15 16 17 18 19 20

Comedie Drama Drama Comedie Romantic Drama Actiune i Aventura Strain

Matchstick Men Cold Mountain Road to Perdition The School of Rock 13 Going on 30 Monster The Day After Tomorrow Das Boot

Exemplu: S se obin codurile i titlurile crilor mprumutate. SELECT carte.codel, titlu FROM carte, imprumuta WHERE carte.codel = imprumuta.codel; Folosirea numelor complete ale tabelelor pentru specificarea coloanelor poate fi obositoare i consumatoare de timp, mai ales deoarece numele tabelelor pot avea 30 sau mai multe caractere n sistemele DBMS moderne. Din aceast cauz, n SQL este permis i folosirea pseudonimelor (aliases) pentru numele tabelelor. Acestea funcioneaz la fel ca i pseudonimele coloanelor din clauza SELECT, exceptnd faptul c nu este folosit cuvntul cheie AS" (n cele mai multe implementri SQL) - doar lsai un spaiu ntre numele tabelului i pseudonim n lista FROM. Dei unii folosesc mnemonice pentru pseudonimul tabelelor, este mult mai des ntlnit folosirea secvenelor de majuscule (adic A", B,C i aa mai departe). Dup ce se asociaz un pseudonim unui nume de tabel n clauza FROM, trebuie s folosii pseudonimul n locul numelui de tabel n ntreaga instruciune SQL. Folosirea pseudonimelor n clauza SELECT poate prea puin ciudat la nceput deoarece folosii un pseudonim nainte de a-l defini (clauza SELECT precede clauza FROM i s-ar putea s par mai simplu s completai clauza FROM nainte de a completa lista de coloane din clauza SELECT atunci cnd scriei instruciunile SQL. Exemplul urmtor prezint instruciunea anterioar, dup adugarea pseudonimelor pentru numele tabelelor. Dei nu era necesar, pseudonimele au fost adugate i n lista de coloane din clauzele SELECT i ORDER BY, pentru a va arta cum sunt folosite.

Exemplu: SELECT A.FILM_ID, B.FILM_GEN_DESCRIERE AS GEN, A.FILM_TITLU FROM FILM A, FILM_GEN B WHERE A.FILM_GEN_COD = B.FILM_GEN_COD ORDER BY A.FILM_ID; Exemplu: a) S se afieze informaii despre operele de art achiziionate n 2008 i galeriile n care au fost expuse. SELECT cod_opera, titlu, o.cod_galerie, nume_galerie, adresa FROM opera o, galerie g WHERE o.cod_galerie = g.cod_galerie AND TO_CHAR(data_achizitiei, 'yyyy') = '2008'; b) S se afieze informaii referitoare la operele de art, artitii care le-au creat i galeriile n care sunt expuse. SELECT cod_opera, titlu, data_crearii, a.cod_artist, nume, prenume, g.cod_galerie, nume_galerie, adresa FROM opera o, galerie g, artist a WHERE o.cod_artist = a.cod_artist AND o.cod_galerie = g.cod_galerie; S-ar putea ca tabelele legate prin operaia de compunere s nu aib coloane comune (non-equijoin). n acest caz n clauza WHERE nu apare operatorul egalitate i sunt folosii operatorii: <=, >=, BETWEEN. Un self join realizeaz compunerea unui tabel cu el nsui. Exemplu: S se obin pentru fiecare salariat numele, salariul i grila de salarizare ( join). SELECT FROM WHERE e.name, e.sal, s.grade emp e, salgrade s e.sal BETWEEN s.lasal AND s.hisal;

Exemplu: S se obin titlurile i preurile crilor mai scumpe dect cartea avnd titlul Baze de date, al crui autor este POPA (self join). SELECT FROM WHERE AND AND x.titlu, x.pret carte x, carte y x.pret > y.pret y.titlu = Baze de date y.autor = POPA;

Realizarea uniunilor folosind clauza JOIN

Clauza JOIN este scris ca o referin de tabel din clauza FROM i combin lista de tabele din clauza FROM i condiia de legtur scris anterior n clauza WHERE ntr-o singur clauz. Sintaxa general a clauzei JOIN pentru o uniune intern, urmat de cteva exemple. Sintaxa corespunztoare standardului SQL3 este urmtoarea: SELECT tabel_1.nume_coloan, tabel_2.nume_coloan FROM tabel_1 [CROSS JOIN tabel_2] | [NATURAL JOIN tabel_2] | [JOIN tabel_2 USING (nume_coloan) ] | [JOIN tabel_2 ON (tabel_1.nume_coloan = tabel_2.nume_coloan) ] | [LEFT | RIGHT | FULL OUTER JOIN tabel_2 ON (tabel_1.nume_coloan = tabel_2.nume_coloan) ]; Clauza ON permite specificarea unei condiii similare cu cea din clauza WHERE . Clauza USING specific numele coloanelor folosite pentru legarea rndurilor. Totui, clauza USING acioneaz numai atunci cnd coloanele pe care se face legtur au nume identice n ambele tabele. JOIN tabel_2 USING nume_coloan efectueaz un equijoin pe baza coloanei cu numele specificat n sintax. Aceast clauz este util dac exist coloane avnd acelai nume, dar tipuri de date diferite. Coloanele referite n clauza USING trebuie s nu conin calificatori (s nu fie precedate de nume de tabele sau alias-uri) n nici o apariie a lor n instruciunea SQL. Clauzele NATURAL JOIN i USING nu pot coexista n aceeai instruciune SQL.

JOIN tabel_2 ON tabel_1.nume_coloan = tabel_2.nume_coloan efectueaz un equijoin pe baza condiiei exprimate n clauza ON. Aceast clauz permite specificarea separat a condiiilor de join, respectiv a celor de cutare sau filtrare (din clauza WHERE).

Exemple: JOIN cu condiie ON: SELECT FILM_ID, FILM_GEN_DESCRIERE AS GEN, FILM_TITLU FROM FILM JOIN FILM_GEN ON FILM.FILM_GEN_COD = FILM_GEN.FILM_GEN_COD ORDER BY FILM_ID; JOIN cu pseudonime n loc de nume de tabele: SELECT FILM_ID, FILM_GEN_DESCRIERE AS GEN, FILM_TITLU FROM FILM A JOIN FILM_GEN B ON A.FILM_GEN_COD = B.FILM_GEN_COD ORDER BY FILM_ID; JOIN folosind cuvntul cheie USING (n locul condiiei ON) o scurtatur elegant atunci cnd coloanele din cele dou tabele au acelai nume (nu e recunoscut de toate SGBD-urile). SELECT FILM_ID, FILM_GEN_DESCRIERE AS GEN, FILM_TITLU FROM FILM JOIN FILM_GEN USING (FILM_GEN_COD) ORDER BY FILM_ID; JOIN cu cheie extern pe mai multe coloane. Aceast interogare afieaz lista cu copiile filmelor din tabelul FILM_COPY care nu au fost vndute (coloan DATA_VANZARE conine o valoare nul dac nu a fost vndut) i care au fost nchiriate (uniune cu tabelul FILM_INCHIRIAT) dar nu au fost nc returnate (coloan RETUR_DATA conine o valoare nul pn la returnarea filmului). SELECT FILM_ID, COPY_NUMAR, DATA_RETURNARII FROM FILM_COPY JOIN FILM__INCHIRIAT USING (FILM_ID, COPY_NUMAR)

WHERE DATA_VANZARE IS NULL AND RETUR_DATA IS NULL; FILM _ID 2 3 5 5 10 17 COPY_NUMAR 2 2 1 2 1 1 DATA_RETURNARII 02/27/2009 03/04/2009 02/27/2009 02/19/2009 03/04/2009 03/04/2009

Instruciunile care folosesc clauza JOIN sunt mai scurte. Interogarea precedent scris folosind condiii de legtur n clauza WHERE. Se remarc faptul c n acest caz trebuie specificat numele complet al coloanelor FILM_ID i COPY_NUMAR, pentru a evita referirea ambigu a lor. Instruciunea de mai jos afieaz aceleai rezultate ca i instruciunea anterioar. SELECT A.FILM_ID, A.COPY_NUMAR, DATA_RETURNARII FROM FILM_COPY A, FILM_INCH B WHERE A.FILM_ID = B.FILM_ID AND A.COPY_NUMAR = B.COPY_NUMAR AND DATA_VANZARE IS NULL AND RETURN_DATA IS NULL; Uniuni naturale O uniune natural (natural join) se bazeaz pe toate coloanele cu acelai nume din dou tabele, n esen, toate uniunile de egalitate sunt uniuni naturale. Totui, sintaxa unei uniuni naturale este mult mai simpl, deoarece nu este necesar s specificai o condiie sau o list de coloane - se nelege de la sine care sunt coloanele folosite. Nu toate SGBD-urile accept aceast sintax pentru clauza JOIN (accepta sigur Oracle i MySQL ). Exemplu: uniunea tabelelor FILM i FILM_GEN, rescris sub forma unei uniuni naturale: SELECT FILM_ID, FILM_GEN_DESCRIERE AS GEN, FILM_TITLU FROM FILM NATURAL JOIN FILM_GEN ORDER BY FILM_ID;

Uniunile pot implica mai mult de dou tabele. Exemplul urmtor prezint o uniune natural care obine coloana FILM_ID din tabelul FILM, coloana FILM_GEN_DESCRIERE din tabelul FILM_GEN i din tabelul MPAA_RATING, coloana MPAA_RATING_DESCRIERE , pentru primele trei filme din tabelul FILM. Folosirea clauzei WHERE permte s se elimine din setul de rezultate rndurile de care nu avem nevoie. Exemplul folosete dou clauze JOIN. Prima clauz JOIN cere motorului SQL s lege tabelele FILM i FILM_GEN, iar a dou clauz JOIN i cere s lege rndurile deja unite (n esen, un set de rezultate intermediar) cu tabelul MPAA_RATING. SELECT FILM_ID, FILM_GEN_DESCRIERE AS GEN, MPAA_RATING_COD AS RATING, MPAA_RATING_DESCRIERE AS RATING_DESC FROM FILM NATURAL JOIN FILM_GEN NATURAL JOIN MPAA_RATING WHERE FILM_ID < 4 ORDER BY FILM_ID;

FILM_ID

GEN

RATING

RATING_DESC

1 2 3

Drama

Sub 17 ani acompaniati de parinti Sub 17 ani acompaniati de parinti Cu acordul strict a parintilor

Aciune si Aventura R

Comedie

PG-13

Dac se folosete o implementare SQL care nu accept uniunile naturale, aceeai interogare scris folosind cuvintele cheie JOIN i ON este: SELECT A.FILM_ID, B.FILM_GEN_DESCRIERE AS GEN, C.MPAA_RATING__COD AS RATING, C.MPAA_RATING__DESCRIERE AS RATING_DESC FROM FILM A JOIN FILM_GEN B ON A.FILM_GEN_COD = B.FILM_GEN_COD JOIN MPAA_RATING C ON A.MPAA_RATING_COD = C.MPAA_RATING_COD WHERE FILM_ID < 4 ORDER BY FILM_ID;

Exemple la schema galerii de arta a) S se determine titlul operelor de art expuse n galeriile avnd codul 10 sau 30, respectiv numele i prenumele artitilor care le-au realizat. SELECT FROM WHERE titlu, nume, prenume opera NATURAL JOIN artist cod_galerie IN (10, 30);

Folosind clauza USING, acest exemplu poate fi rescris astfel: SELECT titlu, nume, prenume FROM opera JOIN artist USING (cod_artist) WHERE cod_galerie IN (10, 30); Urmtoarea cerere va returna eroarea ORA-25154: column part of USING clause cannot have qualifier, ntruct coloana specificat n clauza USING apare, n clauza WHERE, precedat de un alias de tabel. SELECT o.titlu, a.nume, a.prenume FROM opera o JOIN artist a USING (cod_artist) WHERE a.cod_artist IN (50,60); b) S se afieze titlurile operelor de art, firmele la care sunt asigurate i descrierea polielor de asigurare corespunztoare. SELECT o.titlu, p.firma, p.descriere FROM opera o JOIN polita_asig p ON (o.cod_opera = p.cod_opera);

Uniuni externe (outer joins)

Toate uniunile pe care le-am descris pn acum sunt uniuni exclusiv (uniuni interne), ceea ce nseamn c singurele rnduri care apar n setul de rezultate sunt cele pentru care a fost gsit o legtur n toate tabelele unite. Exist situaii n care se dorete s includei n rezultatele interogrii i rnduri pentru care nu exist o legtur. De exemplu, dac se dorete o list cu toate genurile de filme, mpreun cu toate titlurile asociate cu fiecare gen?

O uniune extern (outer join) - pentru care un nume mai potrivit ar fi uniune inclusiv - include n setul de rezultate i rndurile pentru care nu exist legturi din cel puin unul dintre tabele. Atunci cnd exist rnduri fr legturi, datele selectate din tabelul n care nu a fost gsit o legtur primesc valoarea nul. Un outer join este utilizat pentru a obine n rezultat i nregistrrile care nu satisfac condiia de join. Operatorul pentru outer join este semnul plus inclus ntre paranteze (+), care se plaseaz n acea parte a condiiei de join care este deficient n informaie. Efectul acestui operator este de a uni liniile tabelului care nu este deficient n informaie i crora nu le corespunde nici o linie n cellalt tabel cu o linie cu valori null. Operatorul (+) poate fi plasat n orice parte a condiiei de join, dar nu n ambele pri. O condiie care presupune un outer join nu poate utiliza operatorul IN i nu poate fi legat de alt condiie prin operatorul OR. Exemplu: Se presupune c tabelul artist conine i artiti care nu au opere expuse n muzeu. S se afieze artitii i operele acestora, inclusiv cei care nu au opere corespunztoare n tabelul opera. SELECT a.cod_artist, nume, prenume, cod_opera, titlu FROM artist a, opera o WHERE a.cod_artist = o.cod_artist (+); Exist trei tipuri de baz: Uniune extern ctre stnga (left outer join). Returneaz toate rndurile din tabelul din stnga (cel specificat primul n clauza JOIN), mpreun cu toate rndurile din tabelul din dreapta pentru care poate fi gsit o legtur. (asemnatoare interogrilor din tabele aflate in relaia 1:m) Uniune extern ctre dreapta (right outer join). Returneaz toate rndurile din tabelul din dreapta (cel specificat al doilea n clauza JOIN), mpreun cu toate rndurile din tabelul din stnga pentru care poate fi gsit o legtur, n esen, o uniune extern ctre stnga poale fi rescris ca o uniune extern ctre dreapta inversnd ordinea de specificare a tabelelor i nlocuind cuvntul cheie LEFT cu RIGHT. Uniune extern complet (full outer join). Returneaz toate rndurile din ambele tabele. Acest tip de uniune este cel mai puin probabil s fie acceptat de toate implementari;e SQL. Aceast uniune nu este acelai lucru cu un produs cartezian, care leag fiecare rnd dintr-un tabel cu fiecare rnd din cellalt tabel. O uniune extern complet leag fiecare rnd dintr-un tabel cu zero sau mai multe rnduri corespondente din cellalt tabel.

Este folosit mai mult pentru tabelele aflate in relaia m:m Sintaxa general pentru o uniune extern este: nume_tabel {RIGHT | LEFT | FULL} [OUTER] JOIN nume_tabel { ON condiie | USING (nume_coloan [ ,nume_coIoan. ..]) } Exemple de uniuni externe: S se afieze toate descrierile genurilor de filme, mpreun cu filmele asociate fiecrui gen. n setul de rezultate rndurile care nu au nici o valoare n coloan FILM_TITLU - acestea sunt genurile de filme care nu au filme asociate. Dac implementarea DBMS nu accept uniuni realizate cu cuvntul cheie USING, modificai instruciunea astfel nct s utilizeze cuvntul cheie ON, ca n exemplul care urmeaz dup acesta. SELECT FILM_GEN_DESCRIERE AS GEN, FILM_TITLU FROM FILM_GEN LEFT OUTER JOIN FILM (FILM_GEN_COD); GEN Actiune i Aventura Actiune i Aventura Actiune i Aventura Actiune i Aventura Actiune i Aventura FILM_TITLU Kill Bill: Vol. 1 Man on Fire Pirates of the Caribbean Master and Commander The Day After Tomorrow The Last Samurai The Italian Job

USING

Actiune i Aventura Actiune i Aventura Anime and Animation Copii i Familie Clasic Comedie 50 First Dates Comedie Matchstick Men Comedie The School of Rock

Comedie Documentar Drama Drama Drama Drama Drama Drama Strain Horror Independent Musical Romantic Romantic

Something's Gotta Give Big Fiah Road to Perdition Mystic River Monster Cold Mountain Lost n Translation Das Boot

13 Going on 30 Two Weeks Notice

Interogarea anterioar, rescris ca uniune extern ctre dreapta, cu condiie ON.

SELECT FILM_GEN_DESCRIERE AS GEN, FILM_TITLU FROM FILM RIGHT OUTER JOIN FILM_GEN ON FILM.FILM_GEN_COD =FILM_GEN.FILM_GEN_COD; Interogarea anterioar, rescris ca uniune extern complet. Deoarece fiecare film trebuie s aib asociat un gen, aceast interogare va produce aceleai rezultate ca i uniunea extern ctre dreapta din interogarea anterioar. Totui, dac genurile filmelor ar fi opionale, uniunea extern complet v-ar fi permis s afiai att genurile care nu au filme asociate, ct i filmele care nu au genuri asociate. SELECT FILM_GEN_DESCRIERE AS GEN, FILM_TITLU FROM FILM FULL OUTER JOIN FILM_GEN ON FILM.FILM_GEN_COD = FILM_GEN.FILM_GEN_COD; Afiai descrierile genurilor care nu au nume asociate. Exist i alte moduri de a face acest lucru, dar exemplul de fa folosete faptul c rndurile pentru care nu exist legturi returneaz valori nule pentru a selecta numai genurile care nu au nume asociate.

SELECT FILM_GEN_DESCRIERE AS GEN FROM FILM RIGHT OUTER JOIN FILM_GEN ON FILM.FILM_GEN_COD = FILM_GEN.FILM_GEN_COD WHERE FILM_TITLU IS NULL; GEN Animatie Copii i Familie Clasic Documentar Horror Independent Musical SF Special Interes Sport Thriller Ca rspuns la cererile clienilor, mai muli productori de baze de date relaionale au introdus uniunile externe inainte de standardizarea clauzei JOIN. Seciunile urmtoare prezint cteva implementri specifice ale sintaxei uniunii externe. Aceste soluii particulare sunt prezentate aici numai pentru c s-ar putea s le intlnii n instruciuni SQL mai vechi Exemplu: a) S se afieze titlurile operelor de art i firmele la care acestea sunt asigurate. Se vor lua n considerare i operele de art pentru care nu au fost ncheiate polie de asigurare. SELECT titlu, firma FROM opera o LEFT OUTER JOIN polita_asig p ON (o.cod_opera = p.cod_opera); b) S se afieze artitii (nume, prenume) i operele acestora, inclusiv cei care nu au opere expuse n cadrul muzeului. SELECT nume, prenume, titlu FROM opera o RIGHT OUTER JOIN artist a ON (o.cod_artist = a.cod_artist);

c) S se afieze numele i prenumele artitilor, precum i titlurile operelor create de acetia. Se vor afia i artitii care nu au opere expuse n cadrul muzeului, precum i titlurile operelor al cror autor este necunoscut. SELECT nume, prenume, titlu FROM opera o FULL OUTER JOIN artist a ON (o.cod_artist = a.cod_artist); Specificarea condiiilor suplimentare ale unei interogri poate fi fcut att n clauza WHERE, ct i n clauza ON. Urmtoarea instruciune este corect i are acelai efect dac n locul operatorului AND ar aprea clauza WHERE. SELECT o.titlu, p.firma, p.descriere FROM opera o JOIN polita_asig p ON (o.cod_opera = p.cod_opera) AND o.cod_opera = 180; S se obin titlurile crilor i numele domeniului cruia i aparin, remarcnd si situaiile n care domeniul nu ar avea cri (dac domeniul este fr cri atunci apare null la titlul crii). SELECT titlu, intdom FROM carte, domeniu WHERE carte.coded(+) = domeniu.coded; Exemplu: Considerm c tabelele dept i emp au urmtorul coninut: dept emp deptno dname empno deptno 1 algebra 101 null 2 analiza 102 null 103 null 105 1 106 1 Interogarea urmtoare furnizeaz lista tuturor salariailor si informatii despre departamentele in care lucreaza, inclusiv a celor care nu sunt asignai nici unui departament (right outher join). SELECT a.deptno, a.dname, b.empno, b.deptno FROM dept a, emp b

WHERE a.deptno(+) = b.deptno; Rezultatul cererii anterioare va fi: a.deptno a.dname b.empno b.deptno 101 102 103 1 algebra 105 1 1 algebra 106 1 Interogarea urmtoare afieaz lista departamentelor, inclusiv a celor care nu au salariai (left outer join). SELECT a deptno, a.dname, b.empno, b.deptno FROM dept a, emp b WHERE a.deptno = b.deptno(+); Rezultatul cererii anterioare va fi: a.deptno a.dname b.empno b.deptno 1 algebra 105 1 1 algebra 106 1 2 analiza null null Interogarea urmtoare produce ca rezultat departamentele, chiar i cele fr funcionari, i funcionarii, chiar i cei care nu sunt asignai nici unui departament (full outer join). SELECT NVL(TO_CHAR(b.empno),***) id, NVL(a.dname,***) nume_dep FROM dept a, emp b WHERE a.deptno = b.deptno(+) UNION SELECT NVL(TO_CHAR(b.empno),***) id, NVL(a.dname,***) nume_dep FROM dept a, emp b WHERE a.deptno(+) = b.deptno; Rezultatul cererii va fi: id nume_dep *** analiza 101 *** 102 *** 103 *** 105 algebra 106 algebra

c) S se afieze numele i prenumele artitilor, precum i titlurile operelor create de acetia. Se vor afia i artitii care nu au opere expuse n cadrul muzeului, precum i titlurile operelor al cror autor este necunoscut. SELECT nume, prenume, titlu FROM opera o FULL OUTER JOIN artist a ON (o.cod_artist = a.cod_artist); Specificarea condiiilor suplimentare ale unei interogri poate fi fcut att n clauza WHERE, ct i n clauza ON. Urmtoarea instruciune este corect i are acelai efect dac n locul operatorului AND ar aprea clauza WHERE. SELECT o.titlu, p.firma, p.descriere FROM opera o JOIN polita_asig p ON (o.cod_opera = p.cod_opera) AND o.cod_opera = 180; Uniuni ncruciate (cross joins) O uniune ncruciat (cross join) nu este altceva dect sintaxa standard pentru un produs cartezian. Interogarea care unea tabelele FILM i FILM_GEN i obinea un produs cartezian SELECT FILM_ID, FILM_GEN_DESCRIERE AS GEN, FILM_TITLU FROM FILM, FILM_GEN ORDER BY FILM_ID; poate fi rescris ca mai jos, folosind o uniune ncruciat: SELECT FILM_ID, FILM_GEN_DESCRIERE AS GEN, FILM_TITLU FROM FILM CROSS JOIN FILM_GEN ORDER BY FILM_ID;

Subinterogri
O caracteristic foarte puternic a limbajului SQL sunt subinterogrile (numite i selecii), care, aa cum sugereaz i numele, se refer la o instruciune SELECT care contine o instruciune SELECT subordonat. De obicei, subinterogrile sunt folosite n clauza WHERE, ca modalitate de limitare a rndurilor returnate n setul de rezultate al interogrii externe. Aceasta poate fi o modalitate foarte flexibil de selectare a datelor.

O regul esenial de sintax este ca subinterogarea s fie ncadrat de paranteze. Orice operaie efectuat cu o subinterogare poate fi facut i printr-o uniune. Subinterogri necorelate O subinterogare necorelat (noncorrelated subselect) este o subinterogare n care interogarea intern nu face nici o referire la interogarea extern care o conine. Aceasta nseamn c poate fi rulat mai inti interogarea intern, apoi setul de rezultate obinut poate fi folosit n interogarea extern. Exemple: Afiai toate limbile n care nu exist nici un film n inventarul magazinului de produse video. SELECT LIMBA_COD, LIMBA_NUME FROM LIMBA WHERE LIMBA_COD NOT IN (SELECT DISTINCT LIMBA_COD FROM FILM_LIMBA) ORDER BY LIMBA_COD LIMBA_COD Ja Ko ni ru zh LIMBA_NUME Japoneza Coreana Olandeza Rusa Chineza

Interogarea intern returneaz o list cu codurile de limb asociate filmelor n tabelul FILM_LIMBA. Cuvntul cheie DISTINCT elimin rndurile duplicate din setul de rezultate . Interogarea intern rulat independent, pentru a v ajuta s nelegei cum funcioneaz: SELECT DISTINCT LIMBA_COD FROM FILM_LIMBA; LIMBA_COD ------------------------------------------de (Germana) en (Engleza) es (Spaniola)

fr

(Franceza)

Proprietarul magazinului vrea s vad efectul recentei creteri de preuri i are nevoie de o list a tranzaciilor (TRANZACTIE_ID) n care clientul a pltit mai mult dect taxa medie (INCHIRIAT_TAXA) pentru un film. Iat cum arat interogarea: SELECT DISTINCT TRANZACTIE_ID FROM FILM_INCHIRIAT WHERE INCHIRIAT_TAXA> (SELECT AVG(INCHIRIAT_TAXA) FROM FILM_INCHIRIAT) Interogarea intern calculeaz media taxelor de nchiriere, iar interogarea extern gsete apoi toate rndurile din tabelul FILM_INCHIRIAT pentru care valoarea INCHIRIAT_TAXA depete media. Cuvntul cheie DISTINCT elimin tranzaciile duplicate. Rezultatele interogrii anterioare ar fi mai utile pentru proprietarul magazinului dac ar include i data tranzaciei. O modalitate de a realiza acest lucru este i adugm o uniune cu tabelul CLIENT_TRANZACTIE n interogarea extern. Totui, deoarece tocmai ai nvat despre subinterogari, s facem acelai lucru folosind nc o subinterogare. Iat cum arat interogarea: SELECT TRANZACTIE_ID, TRANZACTIE_DATA AS TRANZ_DATA FROM CLIENT_TRANZACTIE WHERE TRANZACTIE_ID IN (SELECT DISTINCT TRANZACTIE_ID FROM FILM_INCH, WHERE INCH_TAXA > (SELECT AVG ( INCHIRIAT_TAXA) FROM FILM_INCHIRIAT) TRANZACTIE_ID TRANZ_DATA 9 03/01/2005 10 03/01/2005 Subinterogri corelate O subinterogare corelat (correlated subselect) este o subinterogare n care interogarea intern refer valorile furnizate de interogarea extern. Aceste subinterogari sunt mult mai puin eficiente dect subinterogrile necorelate,

deoarece interogarea intern trebuie s fie apelat pentru fiecare rnd gsit de interogarea extern. Exemplu: Proprietarul magazinului vrea s transmit prin pot un cupon valoric tuturor clienilor care au pltit mai mult de 15$ pentru o singur tranzacie de nchiriere. SELECT DISTINCT CLIENT_CONT_ID FROM CLIENT_TRANZACTIE A WHERE 15 < (SELECT SUM (INCHIRIAT_TAXA) FROM FILM_INCHIRIATB WHERE A.TRANZACTIE _ID = B.TRANZACTIE_ID) CLIENT_CONT_ID 2 7 9 Observai pseudonimele asociate numelor de tabele din interogrile intern i extern, precurn i folosirea acestora n clauza WHERE a interogrii interne. Acesta este elementul de identificare al unei subinterogri corelate. Interogarea extern selecteaz o lista de valori CLIENT_CONT_ID distincte din tabelul CLIENT_TRANZACTIE. Fiecare valoare gsit este transmis interogrii interne, care este rulat pentru a calcula suma taxelor de nchiriere din tranzacia respectiv. Dac suma taxelor de nchiriere este mai mare sau egal cu 15, atunci clauza WHERE din interogarea extern ia valoarea logic adevrat", iar rndul CLIENT_ID este adugat n setul de rezultate. Vizualizri n linie Foarte puine implementri, printre care Oracle, permit folosirea unei subinterogri n clauza FROM a unei interogri, ntr-o construcie numit vizualizare n linie (inline view). Aceast construcie permite care setul de rezultate al unei interogri s fie tratat ca i cum ar fi un tabel sau o vizualizare predefinit. Iat un exemplu: Aceast interogare afl numrul maxim de nchirieri ale unui singur film; SELECT MAX(INCHIRIAT_NUMAR) AS MAX_INCHIRIAT_NUMAR FROM (SELECT FILM_ID, NUMAR(*) AS INCHIRIAT_NUMAR FROM FILM_INCHIRIAT GROUP BY FILM_ID)

MAX_INCH_NUMAR 5 Interogarea intern calculeaz numrul de nchirieri pentru fiecare valoare FILM_ID. Interogarea extern selecteaz valoarea maxim INCHIRIAT_NUMAR din interogarea intern, tratat ca i cum ar fi o vizualizare predefinit. Nu exist nici o limit n privina modurilor de utilizare a vizualizrilor n linie - putei chiar s le unii cu alte tabele sau vizualizri.

Subinterogri (Subcereri)
O caracteristic foarte puternic a limbajului SQL sunt subinterogrile (numite i selecii), care, aa cum sugereaz i numele, se refer la o instruciune SELECT care conine o instruciune SELECT subordonat. De cele mai multe ori, pentru a implementa anumite interogri, nu este suficient o singur cerere SELECT ci sunt necesare subcereri. Subcererile sunt comenzi SELECT ncapsulate n oricare din clauzele , SELECT, WHERE, HAVING, FROM, numit instruciune printe. Dac subcererea urmeaz clauzei WHERE sau HAVING, ea poate conine unul dintre operatorii ALL, ANY, IN (=ANY), EXIST, NOT IN (!=ALL) care sunt specifici cererilor care ntorc mai multe linii (multiple-row subquery) sau unul dintre operatorii de comparare (=, <, >, >=, <=, <>) care sunt specifici cererilor care ntorc o singur linie (single-row subquery). Utiliznd subcereri, se pot construi interogri complexe pe baza unor instruciuni simple. Subcererile mai sunt numite instruciuni SELECT imbricate sau interioare.

Subcererea returneaz o valoare care este utilizat de ctre instruciunea printe. Utilizarea unei subcereri este echivalent cu efectuarea a dou cereri secveniale i utilizarea rezultatului cererii interne ca valoare de cutare n cererea extern (principal). Subcererile pot fi utilizate n urmtoarele situaii: pentru a furniza valori care intervin n condiiile din clauzele WHERE, HAVING i START WITH ale instruciunilor SELECT; pentru a defini o mulime de linii care urmeaz s fie inserat n tabelul destinaie al unei instruciuni INSERT sau CREATE TABLE; pentru a defini o mulime de linii care urmeaz s fie inserate ntr-o vizualizare sau vizualizare materializat, prin intermediul unei instruciuni CREATE VIEW sau CREATE MATERIALIZED VIEW; pentru a defini una sau mai multe valori care urmeaz s fie atribuite unor linii existente ntr-o instruciune UPDATE; pentru a defini un tabel asupra cruia va opera cererea extern (plasarea subcererii n clauza FROM sau n instruciunile INSERT, UPDATE, DELETE).

Subcererile trebuie incluse ntre paranteze i trebuie plasate n partea dreapt a operatorului de comparare. Subcererea nu poate conine clauza ORDER BY. De obicei, subinterogrile sunt folosite n clauza WHERE, ca modalitate de limitare a rndurilor returnate n setul de rezultate al interogrii externe. Aceasta poate fi o modalitate foarte flexibil de selectare a datelor. O regul esenial de sintax este ca subinterogarea s fie ncadrat de paranteze. Orice operaie efectuat cu o subinterogare poate fi fcut i printr-o uniune. Exemplu: S se obin numele i salariul angajailor, avnd salariul minim. SELECT FROM WHERE name, sal angajati sal=(SELECT FROM

MIN(sal) angajati);

Exemplu: S se obin job-ul pentru care salariul mediu este minim. Sa se afiseze si salariul mediu. SELECT job, AVG(sal) FROM angajati GROUP BY job HAVING AVG(sal)=(SELECT MIN(AVG(sal)) FROM angajati GROUP BY job); Operatorul ANY presupune c este adevrat condiia dac comparaia este adevrat pentru cel puin una din valorile returnate. Sunt evidente relaiile: < ANY mai mic ca maximul; > ANY mai mare ca minimul; = ANY IN. Pentru operatorul ALL se presupune c este adevrat condiia, dac comparaia este adevrat pentru toate elementele listei returnate. Pentru operatorul ALL sunt evidente relaiile: < ALL mai mic ca minimul; > ALL mai mare ca maximul; ! = ALL NOT IN.

Exemplu: WHERE codec > ALL (C1, C2) este superior tuturor elementelor din list; WHERE codec > ANY (C1, C2) este superior cel puin unui element din list. Exemplu: S se obin salariaii al cror salariu este mai mare ca salariile medii din toate departamentele. SELECT FROM WHERE nume, job angajati sal > ALL(SELECT FROM GROUP BY

AVG(sal) angajati cod_dep);

Exist subcereri care au ca rezultat mai multe coloane (multiple-column subquery). Aceste interogri au urmtoarea sintax general: SELECT FROM WHERE col,col, tabel (col,col,) IN (SELECT col,col, FROM tabel WHERE condiie);

Dac una din valorile returnate de subcerere este valoarea null atunci cererea nu ntoarce nici o linie. Prin urmare, dac valoarea null poate s fac parte din rezultatul subcererii nu trebuie utilizat operatorul NOT IN. Problema nu mai apare dac se utilizeaz operatorul IN.

Exemplu: S se obin salariaii care nu au subordonai. SELECT FROM WHERE a.nume angajati a a.cod_ang NOT IN (SELECT m.mgr FROM angajati m);

n acest caz, instruciunea SQL nu ntoarce nici o linie deoarece una din valorile furnizate de subcerere este valoarea null.

Subinterogri necorelate (nesincronizate) O subinterogare necorelat (noncorrelated subselect) este o subinterogare n care interogarea intern nu face nici o referire la interogarea extern care o conine. Subcererile necorelate returneaz o valoare care este utilizat de cererea extern (cererea principal). Cererile care conin subcereri necorelate sunt evaluate n modul urmtor: cererea intern este executat prima i determin o valoare (sau o mulime de valori); cererea extern se execut o singur dat, utiliznd valorile returnate de cererea intern. n general, o cerere imbricat, necorelat are urmtoarea form: SELECT FROM WHERE lista_select nume_tabel expresie operator (SELECT lista_select FROM nume_tabel);

n aceast sintax, identificatorul operator poate fi de tip: single-row operator (>, =, >=, <, <>, <=), care poate fi utilizat dac subcererea returneaz o singur linie; multiple-row operator (IN, ANY, ALL), care poate fi folosit dac subcererea returneaz mai mult de o linie. Operatorul ANY, care este sinonim cu operatorul SOME, determin compararea unei valori cu fiecare valoare returnat de o subcerere. Astfel, <ANY are semnificaia mai mic dect maximul; >ANY nseamn mai mare dect minimul; =ANY este echivalent cu operatorul IN. Operatorul ALL compar o valoare cu toate valorile returnate de o subcerere. Astfel, <ALL are semnificaia mai mic dect minimul, iar >ALL este echivalent cu mai mare dect maximul. Operatorul NOT poate fi utilizat n combinaie cu IN, ANY i ALL. n utilizarea unei subcereri se impun anumite reguli. Subcererea trebuie inclus ntre paranteze. Pentru claritate, subcererea se plaseaz n partea dreapt a operatorului de comparaie. nainte de versiunea Oracle8i, subcererile nu puteau s conin clauza ORDER BY. ncepnd cu Oracle8i, clauza ORDER BY poate fi utilizat i este chiar obligatorie n subcerere pentru a efectua analiza top-n (cererea care efectueaz analiza top-n returneaz cele mai mari sau cele mai mici n valori ale unei coloane). Operatorul folosit trebuie s fie conform cu tipul cererii. Cererea va

genera o eroare dac este utilizat un operator single-row n faa unei subcereri care returneaz mai mult de o linie. De asemenea, dac subcererea nu returneaz nici o linie, apare o eroare. Server-ul Oracle nu impune nici o limit asupra numrului de subcereri. Limita acestora depinde de dimensiunea buffer-ului pe care l utilizeaz cererea. Exemple: Afiai toate limbile n care nu exist nici un film n inventarul magazinului de produse video. SELECT LIMBA_COD, LIMBA_NUME FROM LIMBA WHERE LIMBA_COD NOT IN (SELECT DISTINCT LIMBA_COD FROM FILM_LIMBA) ORDER BY LIMBA_COD LIMBA_COD Ja Ko ni ru zh LIMBA_NUME Japoneza Coreana Olandeza Rusa Chineza

Interogarea intern returneaz o list cu codurile de limb asociate filmelor n tabelul FILM_LIMBA. Cuvntul cheie DISTINCT elimin rndurile duplicate din setul de rezultate . Interogarea intern rulat independent, pentru a v ajuta s nelegei cum funcioneaz: SELECT DISTINCT LIMBA_COD FROM FILM_LIMBA; LIMBA_COD ------------------------------------------de (Germana) en (Engleza) es (Spaniola) fr (Franceza)

 Proprietarul magazinului vrea s vad efectul recentei creteri de preuri i are nevoie de o list a tranzaciilor (TRANZACTIE_ID) n care clientul a pltit mai mult dect taxa medie (INCHIRIAT_TAXA) pentru un film. Iat cum arat interogarea: SELECT DISTINCT TRANZACTIE_ID FROM FILM_INCHIRIAT WHERE INCHIRIAT_TAXA> (SELECT AVG(INCHIRIAT_TAXA) FROM FILM_INCHIRIAT) Interogarea intern calculeaz media taxelor de nchiriere, iar interogarea extern gsete apoi toate rndurile din tabelul FILM_INCHIRIAT pentru care valoarea INCHIRIAT_TAXA depete media. Cuvntul cheie DISTINCT elimin tranzaciile duplicate. Rezultatele interogrii anterioare ar fi mai utile pentru proprietarul magazinului dac ar include i data tranzaciei. O modalitate de a realiza acest lucru este i adugm o uniune cu tabelul CLIENT_TRANZACTIE n interogarea extern. Totui, deoarece tocmai ai nvat despre subinterogari, s facem acelai lucru folosind nc o subinterogare. Iat cum arat interogarea: SELECT TRANZACTIE_ID, TRANZACTIE_DATA AS TRANZ_DATA FROM CLIENT_TRANZACTIE WHERE TRANZACTIE_ID IN (SELECT DISTINCT TRANZACTIE_ID FROM FILM_INCH, WHERE INCH_TAXA > (SELECT AVG ( INCHIRIAT_TAXA) FROM FILM_INCHIRIAT) TRANZACTIE_ID TRANZ_DATA 9 03/01/2005 10 03/01/2005 Exemplu(din galeria de arta): a) S se afieze titlul, codul artistului i valoarea operelor create de artistul cruia i aparine opera avnd codul 180 i care se afl expuse n aceeai galerie cu operele al cror cod este 100 sau 110. Se presupune c o oper are un singur autor. SELECT titlu, cod_artist, valoare FROM opera WHERE cod_artist = (SELECT cod_artist

AND

FROM opera WHERE cod_opera = 180) cod_galerie IN (SELECT cod_galerie FROM opera WHERE cod_opera IN (100, 110));

b) S se determine artistul pentru care valoare medie a operelor sale de art este minim. SELECT cod_artist, AVG(valoare) FROM opera GROUP BY cod_artist HAVING AVG(valoare) = (SELECT MIN(AVG(valoare)) FROM opera GROUP BY cod_artist); c) Pentru fiecare artist, s se afieze titlul i valoarea celei mai ieftine opere de art expuse n muzeu. SELECT titlu, cod_artist, valoare FROM opera WHERE valoare IN (SELECT MIN(valoare) FROM opera GROUP BY cod_artist); d) S se afieze operele de art care nu sunt expuse n galeria avnd codul 30 i a cror valoare este mai mic dect a unei opere din galeria 30. SELECT cod_opera, titlu, valoare FROM opera WHERE valoare < ANY (SELECT valoare FROM opera WHERE cod_galerie = 30) AND cod_galerie <> 30; Dac operatorul ANY se nlocuiete cu operatorul ALL, cererea precedent returneaz operele care nu sunt expuse n galeria 30 i a cror valoare este mai mic dect a oricrei opere din galeria respectiv. e) S se afieze cele mai scumpe 3 opere de art din muzeu. SELECT ROWNUM "Nr.Crt", titlu, valoare FROM (SELECT titlu, valoare FROM opera ORDER BY valoare DESC)

WHERE ROWNUM <= 3; Exemplu: Din punct de vedere logic, urmtoarea cerere ar trebui s returneze titlurile operelor care nu sunt expuse n galeriile unde se afl lucrrile artistului avnd codul 60. SELECT titlu FROM opera WHERE cod_galerie NOT IN (SELECT cod_galerie FROM opera WHERE cod_artist = 60); Dac pentru una dintre opere valoarea coloanei cod_galerie este null, ntreaga cerere nu va returna nici o linie, chiar dac exist nregistrri cu proprietatea cerut. Justificarea este c toate condiiile n care unul dintre operanzi este null au, de asemenea, valoarea null. Prin urmare, ori de cte ori este posibil ca n rezultatul subcererii s apar valori null, nu trebuie folosit operatorul NOT IN. Operatorul NOT IN este echivalent cu <>ALL. Dac se utilizeaz operatorul IN, nu mai este nici o problem dac n rezultatul subcererii apar valori null. Operatorul IN este echivalent cu =ANY. Exemplu: S se afieze titlurile operelor care sunt expuse n galeriile unde se afl lucrrile artistului avnd codul 60. SELECT titlu FROM opera WHERE cod_galerie IN (SELECT cod_galerie FROM opera WHERE cod_artist = 60); Pentru a evita obinerea de valori null n rezultatul unei cereri care utilizeaz operatorul NOT IN, se poate specifica o condiie n subcerere: SELECT titlu FROM opera WHERE cod_galerie NOT IN (SELECT cod_galerie FROM opera WHERE cod_artist = 60 AND cod_galerie IS NOT NULL);

Subcereri (Subinterogri) corelate (incuibarite sau sincronizate) O subinterogare corelat (correlated subselect) este o subinterogare n care interogarea intern refer valorile furnizate de interogarea extern. Subcererile corelate sunt utilizate pentru procesarea linie cu linie a interogrilor. O subcerere este corelat dac face referin la o coloan dintr-un tabel specificat n instruciunea printe. O astfel de subcerere este evaluat o dat pentru fiecare linie procesat de instruciunea printe, care poate fi SELECT, UPDATE sau DELETE. Subcererile corelate permit compararea valorilor unei linii cu date determinate pe baza acestor valori. Cererile corelate se execut astfel: cererea extern determin o linie candidat; cererea intern este executat utiliznd valoarea liniei candidat; valorile rezultate din cererea intern sunt utilizate pentru calificarea sau descalificarea liniei candidat; paii precedeni se repet pn cnd nu mai exist linii candidat. Forma general a unei subcereri corelate este urmtoarea: SELECT nume_coloan_1[, nume_coloan_2 ] FROM nume_tabel_1 extern WHERE expresie operator (SELECT nume_coloan_1 [, nume_coloan_2 ] FROM nume_tabel_2 WHERE expresie_1 = extern.expresie_2);

Exemplu: Proprietarul magazinului vrea s transmit prin pot un cupon valoric tuturor clienilor care au pltit mai mult de 15$ pentru o singur tranzacie de nchiriere. SELECT DISTINCT CLIENT_CONT_ID FROM CLIENT_TRANZACTIE A WHERE 15 < (SELECT SUM (INCHIRIAT_TAXA) FROM FILM_INCHIRIATB WHERE A.TRANZACTIE _ID = B.TRANZACTIE_ID) CLIENT_CONT_ID

2 7 9 Observai pseudonimele asociate numelor de tabele din interogrile intern i extern, precurn i folosirea acestora n clauza WHERE a interogrii interne. Acesta este elementul de identificare al unei subinterogri corelate. Interogarea extern selecteaz o lista de valori CLIENT_CONT_ID distincte din tabelul CLIENT_TRANZACTIE. Fiecare valoare gsit este transmis interogrii interne, care este rulat pentru a calcula suma taxelor de nchiriere din tranzacia respectiv. Dac suma taxelor de nchiriere este mai mare sau egal cu 15, atunci clauza WHERE din interogarea extern ia valoarea logic adevrat", iar rndul CLIENT_ID este adugat n setul de rezultate. Vizualizri n linie Foarte puine implementri, printre care Oracle, permit folosirea unei subinterogri n clauza FROM a unei interogri, ntr-o construcie numit vizualizare n linie (inline view). Aceast construcie permite care setul de rezultate al unei interogri s fie tratat ca i cum ar fi un tabel sau o vizualizare predefinit. Iat un exemplu: Aceast interogare afl numrul maxim de nchirieri ale unui singur film; SELECT MAX(INCHIRIAT_NUMAR) AS MAX_INCHIRIAT_NUMAR FROM (SELECT FILM_ID, NUMAR(*) AS INCHIRIAT_NUMAR FROM FILM_INCHIRIAT GROUP BY FILM_ID) MAX_INCH_NUMAR 5 Interogarea intern calculeaz numrul de nchirieri pentru fiecare valoare FILM_ID. Interogarea extern selecteaz valoarea maxim INCHIRIAT_NUMAR din interogarea intern, tratat ca i cum ar fi o vizualizare predefinit. Nu exist nici o limit n privina modurilor de utilizare a vizualizrilor n linie - putei chiar s le unii cu alte tabele sau vizualizri. Exemplu de subcereri corelate pentru galeria de arta): a) S se afieze informaii despre operele de art a cror valoare depete valoarea medie a celor expuse n aceeai galerie.

SELECT titlu, valoare, cod_galerie FROM opera o WHERE valoare > (SELECT AVG(valoare) FROM opera WHERE cod_galerie = o.cod_galerie); b) S se afieze codul, numele i prenumele artitilor care au cel puin dou opere de art expuse n muzeu. SELECT cod_artist, nume, prenume FROM artist a WHERE 2 <= (SELECT COUNT(*) FROM opera WHERE cod_artist = a.cod_artist); Server-ul Oracle evalueaz subcererea corelat precedent urmnd succesiunea de pai prezentat n continuare. 1) Selecteaz o linie din tabelul specificat n cererea extern (aceasta va fi linia candidat curent). 2) Reine valoarea coloanei referite n subcerere din aceast linie candidat (n cazul subcererii de mai sus, coloana referit n subcerere este a.cod_artist). 3) Efectueaz subcererea, considernd condiia acesteia ca facnd referin la valoarea liniei candidat din cererea extern (n exemplul precedent, funcia COUNT(*) este evaluat pe baza valorii lui a.cod_artist determinat la pasul 2). 4) Evalueaz clauza WHERE a cererii externe pe baza rezultatelor returnate de cererea intern la pasul 3. Adic, se determin dac linia candidat este selectat n rezultatul cererii (n exemplul precedent, numrul de opere ale unui artist, evaluat de subcerere, este comparat cu 2 n clauza WHERE a cererii externe, iar dac aceast condiie este satisfcut, linia corespunztoare artistului respectiv va face parte din rezultat). 5) Procedura se repet pentru urmtoarele linii candidat din tabel, pn cnd sunt procesate toate liniile tabelului. Operatorul EXISTS n instruciunile SELECT imbricate, este permis utilizarea oricrui operator logic. Pentru a testa dac valoarea recuperat de cererea extern exist n mulimea valorilor regsite de cererea intern corelat, se poate utiliza operatorul EXISTS. Dac subcererea returneaz cel puin o linie, operatorul returneaz valoarea TRUE. n caz contrar, va fi returnat valoarea FALSE.

Operatorul EXISTS asigur c nu mai este continuat cutarea n cererea intern dup ce aceasta regsete o linie. Exemplu: a) S se determine codul, numele i prenumele artitilor care au cel puin o oper de art expus n muzeu. SELECT cod_artist, nume, prenume FROM artist a WHERE EXISTS (SELECT 'x' FROM opera WHERE cod_artist = a.cod_artist); ntruct nu este necesar ca instruciunea SELECT interioar s returneze o anumit valoare, se poate selecta o constant. De altfel, din punct de vedere al performanei, selectarea unei constante asigur mai mult rapiditate dect selectarea unei coloane. Ca alternativ a lui EXISTS, poate fi utilizat operatorul IN. Exemplul precedent poate fi rezolvat prin instruciunea urmtoare: SELECT cod_artist, nume, prenume FROM artist WHERE cod_artist IN (SELECT cod_artist FROM opera); b) S se determine operele care nu sunt menionate n nici o surs bibliografic. SELECT cod_opera, titlu FROM opera o WHERE NOT EXISTS (SELECT 'x' FROM mentionata_in WHERE cod_opera = o.cod_opera); Acest exemplu poate fi rezolvat i printr-o subcerere necorelat, utiliznd operatorul NOT IN: SELECT cod_opera, titlu FROM opera WHERE cod_opera NOT IN (SELECT cod_opera FROM ment_in WHERE cod_opera IS NOT NULL);

Clauza WITH Cu ajutorul clauzei WITH se poate defini un bloc de cerere nainte ca acesta s fie utilizat ntr-o interogare. Clauza permite reutilizarea aceluiai bloc de cerere ntr-o instruciune SELECT complex. Acest lucru este util atunci cnd o cerere face referin de mai multe ori la acelai bloc de cerere, care conine operaii join i funcii agregat. Folosind clauza WITH, server-ul Oracle regsete rezultatele unui bloc de cerere i le stocheaz n spaiul tabel temporar al utilizatorului, ceea ce poate determina mbuntirea performanelor. Exemplu: Utiliznd clauza WITH, s se scrie o cerere care afieaz numele artitilor i valoarea total a operelor acestora. Se vor considera artitii a cror valoare total a operelor este mai mare dect media valorilor totale ale operelor tuturor artitilor. WITH val_artist AS (SELECT nume, SUM(valoare) AS total FROM opera o, artist a WHERE o.cod_artist = a.cod_artist GROUP BY nume), val_medie AS (SELECT SUM(total)/COUNT(*) AS medie FROM val_artist) SELECT * FROM val_artist WHERE total > (SELECT medie FROM val_medie) ORDER BY nume; Intern, clauza WITH este tratat ca o vizualizare inline (subcerere n clauza FROM) sau ca un tabel temporar. Optimizorul alege decizia adecvat pe baza costului sau beneficiului stocrii temporare a rezultatelor clauzei WITH. Observaii: Clauza WITH poate fi folosit numai pentru instruciuni SELECT. Un nume de cerere este vizibil tuturor blocurilor din clauza WITH definite ulterior (inclusiv subcererilor acestora). De asemenea, un nume de cerere este vizibil cererii principale i subcererilor acesteia. Cnd un nume de cerere coincide cu numele unui tabel, numele blocului de cerere are preceden asupra numelui tabelului. Clauza WITH poate conine mai mult dect o singur cerere. n acest caz, cererile sunt separate prin virgule.

2.4.4. Funcii grup i clauza GROUP BY Clauza GROUP BY este utilizat pentru a diviza liniile unui tabel n grupuri. Pentru a returna informaia corespunztoare fiecrui astfel de grup, pot fi utilizate funciile agregat. Ele pot aprea n clauzele SELECT, ORDER BY i HAVING. Server-ul Oracle aplic aceste funcii fiecrui grup de linii i returneaz un singur rezultat pentru fiecare mulime. Dintre funciile grup definite n sistemul Oracle, se pot enumera: AVG, SUM, MAX, MIN, COUNT, STDDEV, VARIANCE, DENSE_RANK, RANK, FIRST, LAST, GROUP_ID, GROUPING, GROUPING_ID etc. Tipurile de date ale argumentelor funciilor grup pot fi CHAR, VARCHAR2, NUMBER sau DATE. Funciile AVG, SUM, STDDEV i VARIANCE opereaz numai asupra valorilor numerice. Funciile MAX i MIN pot opera asupra valorilor numerice, caracter sau de tip dat calendaristic. Toate funciile grup, cu excepia lui COUNT(*), ignor valorile null. COUNT(expresie) returneaz numrul de linii pentru care expresia dat nu are valoarea null. Funcia COUNT returneaz un numr mai mare sau egal cu zero i nu ntoarce niciodat valoarea null. Cnd este utilizat clauza GROUP BY, server-ul sorteaz implicit mulimea rezultat n ordinea cresctoare a valorilor coloanelor dup care se realizeaz gruparea. n clauza GROUP BY a unei cereri se pot utiliza operatorii ROLLUP i CUBE. Acetia sunt disponibili ncepnd cu versiunea Oracle8i. Operatorul ROLLUP Operatorul ROLLUP produce o mulime care conine liniile obinute n urma gruprii obinuite i linii pentru subtotaluri. Acest operator furnizeaz valori agregat i superagregat corespunztoare expresiilor din clauza GROUP BY. Operatorul ROLLUP poate fi folosit pentru extragerea de statistici i informaii totalizatoare din mulimile rezultate. Acest operator poate fi util la generarea de rapoarte, diagrame i grafice. Operatorul ROLLUP creeaz grupri prin deplasarea ntr-o singur direcie, de la dreapta la stnga, de-a lungul listei de coloane specificate n clauza GROUP BY. Apoi, se aplic funcia agregat acestor grupri. Dac sunt specificate n expresii n operatorul ROLLUP, numrul de grupri generate va fi n + 1. Liniile care se bazeaz pe valoarea primelor n expresii se numesc linii obinuite, iar celelalte se numesc linii superagregat. Dac n clauza GROUP BY sunt specificate n coloane, pentru a produce subtotaluri fr operatorul ROLLUP ar fi necesare n + 1 instruciuni SELECT

conectate prin UNION ALL. Aceasta ar face execuia cererii ineficient deoarece fiecare instruciune SELECT determin accesarea tabelului. Operatorul ROLLUP determin rezultatele efectund un singur acces la tabel i este util atunci cnd sunt implicate multe coloane n producerea subtotalurilor. Exemplu: S se afieze codurile de galerii mai mici dect 50, iar pentru fiecare dintre acestea i pentru fiecare autor care are opere expuse n galerie, s se listeze valoarea total a lucrrilor sale. De asemenea, se cere valoarea total a operelor expuse n fiecare galerie. Rezultatul va conine i valoarea total a operelor din galeriile avnd codul mai mic dect 50, indiferent de codul autorului. SELECT cod_galerie, cod_artist, SUM(valoare) FROM opera WHERE cod_galerie < 50 GROUP BY ROLLUP(cod_galerie, cod_artist); Instruciunea precedent va avea un rezultat de forma: COD_GALERIE 10 10 10 40 40 COD_ARTIST 50 60 50 SUM(VALOARE) 14000 10000 24000 8080 8080 32080

n rezultatul prezentat anterior se pot distinge 3 tipuri de linii. 1) Prima linie reprezint suma operelor artistului care are codul 50, expuse n galeria avnd codul 10. n mod similar se interpreteaz a doua i a patra linie din rezultat. 2) Linia a treia i a cincea din rezultat conin valoarea total a operelor din galeria al crei cod este 10, respectiv 40. Aceste linii se disting prin faptul c valoarea coloanei cod_artist este null. 3) Ultima linie conine suma valorilor tuturor operelor din galeriile al cror cod este 10 sau 40. Valoarea afiat este obinut prin nsumarea valorilor de pe a treia, respectiv a cincea linie. ntruct aceast linie corespunde totalului general, ea conine valoarea null pe toate coloanele, cu excepia

cmpului SUM(valoare). Operatorul CUBE Operatorul CUBE grupeaz liniile selectate pe baza valorilor tuturor combinaiilor posibile ale expresiilor specificate i returneaz cte o linie totalizatoare pentru fiecare grup. Acest operator este folosit pentru a produce mulimi de rezultate care sunt utilizate n rapoarte. n vreme ce ROLLUP produce subtotalurile doar pentru o parte dintre combinaiile posibile, operatorul CUBE produce subtotaluri pentru toate combinaiile posibile de grupri specificate n clauza GROUP BY, precum i un total general. Dac exist n coloane sau expresii n clauza GROUP BY, vor exista 2n combinaii posibile superagregat. Din punct de vedere matematic, aceste combinaii formeaz un cub n-dimensional, de aici provenind numele operatorului. Pentru producerea de subtotaluri fr ajutorul operatorului CUBE ar fi necesare 2n instruciuni SELECT conectate prin UNION ALL. Exemplu: S se afieze valoarea total a operelor de art ale unui autor, expuse n cadrul fiecrei galerii avnd codul mai mic dect 50. De asemenea, s se afieze valoarea total a operelor din fiecare galerie avnd codul mai mic dect 50, valoarea total a operelor fiecrui autor indiferent de galerie i valoarea total a operelor din galeriile avnd codul mai mic dect 50. SELECT cod_galerie, cod_artist, SUM(valoare) FROM opera WHERE cod_galerie < 50 GROUP BY CUBE(cod_galerie, cod_artist); Instruciunea precedent va genera un rezultat de forma urmtoare: COD_GALERIE 10 10 10 40 40 COD_ARTIST 50 60 50 50 60 SUM(VALOARE) 14000 10000 24000 8080 8080 22080 10000

32080 n plus fa de rezultatul corespunztor operaiei ROLLUP, operatorul CUBE a produs linii care reprezint suma valorilor operelor pentru fiecare artist care a expus n galerii avnd codul mai mic dect 50. Aceste linii se disting prin faptul c valoarea coloanei cod_galerie este null. Funcia GROUPING Funcia GROUPING poate fi utilizat alturi de operatorii CUBE i ROLLUP pentru a arta modul cum a fost obinut o valoare totalizatoare. Aceast funcie accept un singur argument, care trebuie s fie una dintre expresiile specificate n clauza GROUP BY. O valoare null a expresiei din argumentul funciei GROUPING poate proveni din tabelul de baz (valoare null stocat) sau poate fi o valoare null creat de operaia ROLLUP sau CUBE ca rezultat al unei funcii grup asupra expresiei respective. Funcia GROUPING returneaz valoarea 0 sau 1. Valoarea 0 returnat de funcia GROUPING pe baza unei expresii poate indica fie c expresia a fost utilizat pentru calculul valorii agregat, fie c valoarea null a expresiei este o valoare null stocat. Valoarea 1 returnat de funcia GROUPING pe baza unei expresii poate indica fie c expresia nu a fost utilizat pentru calculul valorii agregat, fie c valoarea null a expresiei este creat de ROLLUP sau CUBE ca rezultat al gruprii. Valorile returnate de funcia GROUPING sunt utile pentru: determinarea nivelului de agregare al unui subtotal dat, adic a grupului sau grupurilor pe care se bazeaz subtotalul respectiv; identificarea provenienei unei valori null a unei expresii calculate, dintruna din liniile mulimii rezultat. Exemplu: SELECT cod_galerie, cod_artist, SUM(valoare), GROUPING(cod_galerie), GROUPING(cod_artist) FROM opera WHERE cod_galerie < 50 GROUP BY ROLLUP(cod_galerie, cod_artist); COD_GALERIE COD_ARTIST 10 SUM GROUPING GROUPING (VALOARE) (COD_GALERIE) (COD_ARTIST) 50 14000 0 0

10 10 40 40

60 50

10000 24000 8080 8080 32080

0 0 0 0 1

0 1 0 1 1

Pe prima linie din acest rezultat, valoarea totalizatoare reprezint suma valorilor operelor artistului avnd codul 50, n cadrul galeriei 10. Pentru a calcula aceast valoare au fost luate n considerare coloanele cod_galerie i cod_artist. Prin urmare, expresiile GROUPING(cod_galerie) i GROUPING(cod_artist) au valoarea 0 pentru prima linie din rezultat. Pe linia a treia se afl valoarea total a operelor din galeria avnd codul 10. Aceast valoare a fost calculat lund n considerare doar coloana cod_galerie, astfel nct GROUPING (cod_galerie) i GROUPING(cod_artist) au valorile 0, respectiv 1. Pe ultima linie din rezultat se afl valoarea total a operelor din galeriile avnd codul mai mic dect 50. Nici una dintre coloanele cod_galerie i cod_artist nu au intervenit n calculul acestui total, prin urmare valorile corespunztoare expresiilor GROUPING(cod_galerie) i GROUPING(cod_artist) sunt 0. Clauza GROUPING SETS GROUPING SETS reprezint o extensie a clauzei GROUP BY care permite specificarea unor grupri multiple de date. Utilizarea acestei opiuni faciliteaz analiza datelor n mai multe dimensiuni. Aceast extensie, aprut n sistemul Oracle9i, permite scrierea unei singure instruciuni SELECT pentru a specifica grupri diferite (care pot conine operatorii ROLLUP i CUBE), n loc de mai multe instruciuni SELECT combinate prin operatorul UNION ALL. De altfel, reuniunea rezultatelor mai multor cereri este ineficient ntruct necesit mai multe parcurgeri ale acelorai date. Operatorii ROLLUP i CUBE pot fi considerai cazuri particulare de mulimi de grupri. Au loc urmtoarele echivalene: CUBE(a, b, c) GROUPING SETS ((a, b, c), (a, b), (a, c), (b, c), (a), (b), (c), ()) ROLLUP(a, b, GROUPING SETS c) ((a, b, c), (a, b), (a), ()) Exemplu: Considernd galeriile al cror cod este mai mic dect 50, s se calculeze media valorilor operelor:

pentru fiecare galerie i, n cadrul acesteia, pentru fiecare artist; pentru fiecare artist i, n cadrul acestuia, pentru anii de achiziie corespunztori. SELECT cod_galerie, cod_artist, TO_CHAR(data_achizitiei, 'yyyy') "an achizitie", AVG(valoare) "Valoare medie" FROM opera WHERE cod_galerie < 50 GROUP BY GROUPING SETS ((cod_galerie, cod_artist), (cod_artist, TO_CHAR(data_achizitiei, 'yyyy'))); Mulimea rezultat este constituit din valorile medii pentru fiecare dintre cele dou grupuri i are forma urmtoare: COD_GALERIE COD_ARTIST 10 50 10 60 40 50 50 50 60 60 an a Valoare medie 3500 2500 2020 2380 2300 2000 3000

2000 2002 2001 2003

Exemplul precedent poate fi rezolvat i prin urmtoarea instruciune compus: SELECT cod_galerie, cod_artist, NULL "an achizitie", AVG(valoare) "Valoare medie" FROM opera GROUP BY cod_galerie, cod_artist UNION ALL SELECT NULL, cod_artist, TO_CHAR(data_achizitiei, 'yyyy'), AVG(valoare) FROM opera GROUP BY cod_artist, TO_CHAR(data_achizitiei, 'yyyy'); n absena unui optimizor care analizeaz blocurile de cerere i genereaz planul de execuie, cererea precedent va parcurge de dou ori tabelul de baz (opera), ceea ce poate fi ineficient. Din acest motiv, este recomandat utilizarea

extensiei GROUPING SETS. Concatenarea gruprilor Concatenarea gruprilor reprezint o modalitate concis de a genera combinaii de grupri. Acestea se specific prin enumerarea mulimilor de grupri (grouping sets) i a operaiilor ROLLUP, CUBE separate prin virgul. De exemplu, expresia GROUP BY GROUPING SETS(a, b), GROUPING SETS(c, d) definete gruprile (a, c), (a, d), (b, c), (b, d). Concatenarea mulimilor de grupri este util att pentru uurina dezvoltrii cererilor, ct i pentru aplicaii. Codul SQL generat de aplicaiile OLAP implic deseori concatenarea mulimilor de grupri, n care fiecare astfel de mulime definete gruprile necesare pentru o dimensiune. Exemplu: S se determine media valorilor operelor lund n considerare urmtoarele grupri: (cod_galerie, cod_artist, an_achizitie), (cod_galerie, cod_artist), (cod_galerie, an_achizitie), (cod_galerie). SELECT cod_galerie, cod_artist, TO_CHAR(data_achizitiei, 'yyyy') an_achizitie, AVG(valoare) FROM opera GROUP BY cod_galerie, ROLLUP(cod_artist), CUBE(TO_CHAR(data_achizitiei, 'yyyy'));

PROBLEME-SUBCERERI De cele mai multe ori, pentru a implementa anumite interogri, nu este suficient o singur cerere SELECT ci sunt necesare subcereri. Subcererile sunt comenzi SELECT ncapsulate n oricare din clauzele SELECT, WHERE, HAVING, FROM. Dac subcererea urmeaz clauzei WHERE sau HAVING, ea poate conine unul dintre operatorii ALL, ANY, IN (=ANY), EXIST, NOT IN (!=ALL) care sunt specifici cererilor care ntorc mai multe linii (multiple-row subquery) sau unul dintre operatorii de comparare (=, <, >, >=, <=, <>) care sunt specifici cererilor care ntorc o singur linie (single-row subquery). Subcererile trebuie incluse ntre paranteze i trebuie plasate n partea dreapt a operatorului de comparare. Subcererea nu poate conine clauza ORDER BY. Exemplu: S se obin numele salariailor, salariile, codul departamentului n care lucreaz i salariul mediu pe departament pentru toi angajaii care au salariul mai mare ca media salariilor din departamentul n care lucreaz (folosirea subcererii n clauza FROM). SELECT a.nume, a.sal, a.cod_dep, b.salavg FROM angajati a, (SELECT dept ,avg(sal) salavg FROM angajati GROUP BY cod_dep) b WHERE a. cod_dep =b. cod_dep AND a.sal>b.salavg Exemplu: S se obin lista celor mai scumpe cri. SELECT titlu FROM carte WHERE pret = (SELECT FROM carte);

MAX(pret)

Exemplu: S se obin lista scriitorilor care au n bibliotec un numr de exemplare mai mare dect numrul mediu al crilor din bibliotec. SELECT FROM DISTINCT autor carte

WHERE

nrex > (SELECT AVG(nrex) FROM carte);

Exemplu: S se obin informaii despre crile al cror pre depete media preurilor crilor ce aparin aceluiai domeniu SELECT FROM WHERE * carte c pret > (SELECT AVG(pret) FROM carte WHERE coded = c.coded);

Exemplu: S se obin lista cititorilor care au mprumutat cel puin o carte. SELECT FROM WHERE nume cititor codec IN (SELECT DISTINCT codec FROM imprumuta);

Exemplu: S se obin codurile cititorilor care nu au mprumutat niciodat cri. SELECT FROM WHERE codec cititor codec NOT IN (SELECT DISTINCT codec FROM imprumuta);

Exemplu: S se obin lista cititorilor care sunt n ntrziere cu predarea crilor. SELECT FROM WHERE nume cititor codec IN (SELECT FROM WHERE AND DISTINCT codec imprumuta dataef IS NULL dares<SYSDATE);

Exemplu: S se obin numele cititorilor care au mprumutat cel puin o carte scris de ZOLA. SELECT FROM WHERE nume cititor codec IN (SELECT DISTINCT codec

FROM imprumuta WHERE codel IN (SELECT codel FROM carte WHERE autor=ZOLA)); Exemplu: S se obin numele cititorilor care nu au mprumutat nici o carte scris de ZOLA. SELECT FROM WHERE nume cititor codec NOT IN (SELECT DISTINCT codec FROM imprumuta WHERE codel IN (SELECT codel FROM carte WHERE autor=ZOLA));

Operatorul IN poate fi nlocuit cu = ANY (un element este n list dac i numai dac este egal cu un element al listei), iar operatorul NOT IN poate fi nlocuit prin !=ALL. Exemplu: S se obin codurile cititorilor care au mprumutat o carte de algebr. SELECT DISTINCT codec FROM imprumuta WHERE codel IN (SELECT codel FROM carte WHERE coded= (SELECT coded FROM domeniu WHERE intdom=ALGEBRA)); Exemplu: S se obin cititorii care au mprumutat numai cri scrise de ZOLA. SELECT FROM WHERE nume cititor codec NOT IN (SELECT DISTINCT codec FROM imprumuta WHERE codel NOT IN

(SELECT codel FROM carte WHERE autor=ZOLA)); Exemplu: S se obin numele cititorilor care au mprumutat cel puin o carte de informatic (procedural). SELECT nume FROM cititor WHERE codec IN (SELECT DISTINCT codec FROM imprumuta WHERE codel IN (SELECT codel FROM carte WHERE coded= (SELECT coded FROM domeniu WHERE intdom= INFORMATICA))); Exemplu: S se obin numele cititorilor i titlurile crilor de informatic mprumutate de aceti cititori (relational). SELECT FROM WHERE AND AND AND nume, titlu cititor, carte, imprumuta, domeniu imprumuta.codel = carte.codel carte.coded = domeniu.coded imprumuta.codec = cititor.codec intdom = INFORMATICA;

Subcererile pot fi executate corelat (cu sincronizare) sau ncuibrit (fr sincronizare). Subcererile fr sincronizare sunt caracterizate de faptul c se execut cererea cea mai interioar care ntoarce un rezultat ce este transmis cererii de nivel superior, care ntoarce un rezultat s.a.m.d. Subcererile cu sincronizare sunt caracterizate de faptul c evaluarea subcererii face referin la o coloan a cererii principale, iar evaluarea cererii interioare se face pentru fiecare linie a cererii (principale) care o conine.

Exemplu: S se obin, utiliznd sincronizarea subcererii cu cererea principal, titlurile crilor care au toate exemplarele mprumutate (se selecteaz un titlu din carte i pentru acest titlu se numr cte exemplare sunt mprumutate). SELECT FROM WHERE titlu carte nrex=(SELECT FROM WHERE AND COUNT(*) imprumuta codel = carte.codel dataef IS NULL);

Exemplu: S se obin codurile cititorilor i codul ultimei cri mprumutate. SELECT FROM WHERE codec, codel imprumuta i dataim>=ALL (SELECT dataim FROM imprumuta WHERE codec=i.codec); dataim=(SELECT MAX(dataim) FROM imprumuta WHERE codec=i.codec);

Pentru aceast interogare, clauza WHERE putea fi scris i sub forma: WHERE

Exemplu: S se obin lista codurilor crilor mprumutate i codul primului cititor care a mprumutat aceste crti. SELECT FROM WHERE codel,codec imprumuta i dataim<=ALL (SELECT dataim FROM imprumuta WHERE i.codel=codel);

Exemplu: S se obin codurile crilor din care cel puin un exemplar este mprumutat. SELECT FROM WHERE codel carte EXISTS (SELECT codel FROM imprumuta

WHERE AND

codel = carte.codel dataef IS NULL);

Operatorul WHERE EXISTS (subcerere) presupune c predicatul este adevrat dac subcererea ntoarce cel puin un tuplu, iar WHERE NOT EXISTS (subcerere) presupune c predicatul este adevrat dac subcererea nu ntoarce nici un tuplu. EXISTS i NOT EXISTS cer sincronizarea subcererii. Exemplu: S se obin titlurile crilor care sunt momentan mprumutate. Soluia 1 (cu sincronizare): SELECT titlu FROM carte WHERE EXISTS (SELECT * FROM WHERE AND

imprumuta codel = carte.codel dataef IS NULL);

Soluia 2 (fr sincronizare): SELECT titlu FROM carte WHERE codel IN (SELECT DISTINCT codel FROM imprumuta WHERE dataef IS NULL); Exemplu: S se obin codurile crilor care nu au fost mprumutate niciodat. Soluia 1 (cu sincronizare) SELECT codel FROM carte WHERE NOT EXISTS (SELECT FROM WHERE Soluia 2 (fr sincronizare) SELECT FROM WHERE codel carte codel NOT IN (SELECT DISTINCT codel

codel imprumuta codel = carte.codel);

FROM

imprumuta);

Exemplu: S se obin lista salariailor avnd salariul minim n departamentul n care lucreaz. SELECT FROM WHERE ename,sal emp e sal=(SELECT FROM WHERE

MIN(sal) emp deptno=e.deptno);

Exemplu: S se obin numele primilor trei salariai avnd retribuia maxim (ideea rezolvrii este de a verifica dac numrul salariailor care au leafa mai mare dect leafa salariatului considerat, este mai mic dect 3). SELECT FROM WHERE ename emp a 3>(SELECT COUNT(*) FROM emp WHERE sal > a.sal);

Exemplu: S se obin numele cititorilor care au mprumutat cel puin aceleai cri ca i cititorul avnd codul C19 (ideea problemei este de a selecta cititorii pentru care este vid lista crilor mprumutatede C19 mai puin lista crilor mprumutate de acei cititori). SELECT nume FROM cititor WHERE NOT EXISTS (SELECT codel FROM imprumuta WHERE codec=C19 MINUS SELECT codel FROM imprumuta WHERE codec= cititor.codec); Dac problema era modificat n sensul c cel puineste nlocuit prin cel mult atunci trebuiau inversate interogrile legate prin MINUS.

Exemplu: S se obin codurile cititorilor care au mprumutat aceleai cri ca i cititorul avnd un cod specificat. Rezolvarea problemei se bazeaz pe ideea: A = B A B i B A (AB) = i (B-A) = A-B i B-A nu furnizeaz nici un tuplu rezultat. SELECT codec FROM imprumuta i WHERE NOT EXISTS (SELECT codel FROM imprumuta WHERE codec=i.codec MINUS SELECT codel FROM imprumuta WHERE codec=&ccc) AND NOT EXISTS (SELECT codel FROM imprumuta WHERE codec=&ccc MINUS SELECT codel FROM imprumuta WHERE codec=i.codec) AND codec!=&ccc); Ultimul operator (AND), asigur s nu apar n rezultat cititorul specificat. n cazul formei relaionale de rezolvare a cererii, drumul de acces la informaie este n sarcina SGBD-lui i prin urmare nu mai apar cereri imbricate. Exemplu: S se obin numele cititorilor care au mprumutat cel puin o carte. Soluia 1 (forma relaional): SELECT DISTINCT nume FROM cititor,imprumuta WHERE cititor.codec=imprumuta.codec; Soluia 2 (forma procedural): SELECT nume FROM cititor WHERE codec IN (SELECT DISTINCT codec FROM imprumuta);

Exemplu: S se obin numele cititorilor care au mprumutat cel puin dou cri. Soluia 1 (forma relaional): SELECT nume FROM cititor, imprumuta WHERE cititor.codec=imprumuta.codec GROUP BY nume HAVING COUNT(*)>1; Soluia 2 (forma procedural): SELECT nume FROM cititor WHERE codec IN (SELECT codec FROM imprumuta GROUP BY codec HAVING COUNT(*)>1); Exemplu: S se afieze numele, prenumele, salariul lucrtorilor, codurile publicaiilor la care lucreaz i salariul mediu pe publicaie pentru toi angajaii care au salariul mai mare dect media salariului pe publicaia respectiv. SELECT s.nume, s.prenume, s.salariu, p.nr_publicatie, a.salariu_mediu FROM salariat s, publicatie p, (SELECT p1.nr_publicatie,AVG(salariu) salariu_mediu FROM publicatie p1, salariat s1 WHERE p1.cod_salariat = s1.cod_salariat GROUP BY p1.nr_publicatie) a WHERE p.nr_publicatie = a.nr_publicatie AND s.cod_salariat = p.cod_salariat AND s.salariu > a.salariu_mediu; Exemplu: S se obin numele salariailor care nu cunosc nici o limb strin. SELECT nume, prenume FROM salariat WHERE NOT EXISTS (SELECT * FROM limba WHERE limba.cod_salariat = salariat.cod_salariat AND limba_cun IS NOT NULL); Exemplu:

S se afieze graficienii care au ntrziat s predea frame-urile. a) cu sincronizare: SELECT nume, prenume FROM salariat WHERE EXISTS (SELECT * FROM realizeaza r WHERE salariat.cod_salariat=r.cod_salariat AND data_lim < SYSDATE); b) fr sincronizare: SELECT nume, prenume FROM salariat WHERE cod_salariat IN (SELECT DISTINCT cod_salariat FROM realizeaza WHERE data_lim < SYSDATE); Exemplu: S se determine revistele coordonate de redactori efi care nu cunosc limba n care sunt scrise. Se tie c n urma inspectrii vizuale a rezultatului interogrii se poate decide schimbarea redactorilor efi ai revistelor respective, de aceea se dorete blocarea nregistrrilor gsite. SELECT p.nr_publicatie FROM salariat s, publicatie p WHERE s.cod_salariat = p.cod_salariat AND p.limba NOT IN (SELECT limba_cun FROM limba WHERE limba.cod_salariat = s.cod_salariat) FOR UPDATE OF p.cod_salariat;

Subinterogri
O caracteristic foarte puternic a limbajului SQL sunt subinterogrile (numite i selecii), care, aa cum sugereaz i numele, se refer la o instruciune SELECT care conine o instruciune SELECT subordonat. De cele mai multe ori, pentru a implementa anumite interogri, nu este suficient o singur cerere SELECT ci sunt necesare subcereri. Subcererile sunt comenzi SELECT ncapsulate n oricare din clauzele , SELECT, WHERE, HAVING, FROM, numit instruciune printe. Dac subcererea urmeaz clauzei WHERE sau HAVING, ea poate conine unul dintre operatorii ALL, ANY, IN (=ANY), EXIST, NOT IN (!=ALL) care sunt specifici cererilor care ntorc mai multe linii (multiple-row subquery) sau unul dintre operatorii de comparare (=, <, >, >=, <=, <>) care sunt specifici cererilor care ntorc o singur linie (single-row subquery). Utiliznd subcereri, se pot construi interogri complexe pe baza unor instruciuni simple. Subcererile mai sunt numite instruciuni SELECT imbricate sau interioare. Subcererea returneaz o valoare care este utilizat de ctre instruciunea printe. Utilizarea unei subcereri este echivalent cu efectuarea a dou cereri secveniale i utilizarea rezultatului cererii interne ca valoare de cutare n cererea extern (principal). Subcererile pot fi utilizate n urmtoarele situaii: pentru a furniza valori care intervin n condiiile din clauzele WHERE, HAVING i START WITH ale instruciunilor SELECT; pentru a defini o mulime de linii care urmeaz s fie inserat n tabelul destinaie al unei instruciuni INSERT sau CREATE TABLE; pentru a defini o mulime de linii care urmeaz s fie inserate ntr-o vizualizare sau vizualizare materializat, prin intermediul unei instruciuni CREATE VIEW sau CREATE MATERIALIZED VIEW; pentru a defini una sau mai multe valori care urmeaz s fie atribuite unor linii existente ntr-o instruciune UPDATE; pentru a defini un tabel asupra cruia va opera cererea extern (plasarea subcererii n clauza FROM sau n instruciunile INSERT, UPDATE, DELETE).

Subcererile trebuie incluse ntre paranteze i trebuie plasate n partea dreapt a operatorului de comparare. Subcererea nu poate conine clauza ORDER BY. De obicei, subinterogrile sunt folosite n clauza WHERE, ca modalitate de limitare a rndurilor returnate n setul de rezultate al interogrii externe. Aceasta poate fi o modalitate foarte flexibil de selectare a datelor. O regul esenial de sintax este ca subinterogarea s fie ncadrat de paranteze. Orice operaie efectuat cu o subinterogare poate fi fcut i printr-o uniune. Subinterogri necorelate O subinterogare necorelat (noncorrelated subselect) este o subinterogare n care interogarea intern nu face nici o referire la interogarea extern care o conine. Subcererile necorelate returneaz o valoare care este utilizat de cererea extern (cererea principal). Cererile care conin subcereri necorelate sunt evaluate n modul urmtor: cererea intern este executat prima i determin o valoare (sau o mulime de valori); cererea extern se execut o singur dat, utiliznd valorile returnate de cererea intern. n general, o cerere imbricat, necorelat are urmtoarea form: SELECT FROM WHERE lista_select nume_tabel expresie operator (SELECT lista_select FROM nume_tabel);

n aceast sintax, identificatorul operator poate fi de tip: single-row operator (>, =, >=, <, <>, <=), care poate fi utilizat dac subcererea returneaz o singur linie; multiple-row operator (IN, ANY, ALL), care poate fi folosit dac subcererea returneaz mai mult de o linie. Operatorul ANY, care este sinonim cu operatorul SOME, determin compararea unei valori cu fiecare valoare returnat de o subcerere. Astfel, <ANY are semnificaia mai mic dect maximul; >ANY nseamn mai mare dect minimul; =ANY este echivalent cu operatorul IN. Operatorul ALL compar o valoare cu toate valorile returnate de o subcerere. Astfel, <ALL are semnificaia mai mic dect minimul, iar >ALL este echivalent cu mai mare dect maximul. Operatorul NOT poate fi utilizat n combinaie cu IN, ANY i ALL. n utilizarea unei subcereri se impun anumite reguli. Subcererea trebuie inclus ntre paranteze.

Pentru claritate, subcererea se plaseaz n partea dreapt a operatorului de comparaie. nainte de versiunea Oracle8i, subcererile nu puteau s conin clauza ORDER BY. ncepnd cu Oracle8i, clauza ORDER BY poate fi utilizat i este chiar obligatorie n subcerere pentru a efectua analiza top-n (cererea care efectueaz analiza top-n returneaz cele mai mari sau cele mai mici n valori ale unei coloane). Operatorul folosit trebuie s fie conform cu tipul cererii. Cererea va genera o eroare dac este utilizat un operator single-row n faa unei subcereri care returneaz mai mult de o linie. De asemenea, dac subcererea nu returneaz nici o linie, apare o eroare. Server-ul Oracle nu impune nici o limit asupra numrului de subcereri. Limita acestora depinde de dimensiunea buffer-ului pe care l utilizeaz cererea. Exemple: Afiai toate limbile n care nu exist nici un film n inventarul magazinului de produse video. SELECT LIMBA_COD, LIMBA_NUME FROM LIMBA WHERE LIMBA_COD NOT IN (SELECT DISTINCT LIMBA_COD FROM FILM_LIMBA) ORDER BY LIMBA_COD LIMBA_COD Ja Ko ni ru zh LIMBA_NUME Japoneza Coreana Olandeza Rusa Chineza

Interogarea intern returneaz o list cu codurile de limb asociate filmelor n tabelul FILM_LIMBA. Cuvntul cheie DISTINCT elimin rndurile duplicate din setul de rezultate . Interogarea intern rulat independent, pentru a v ajuta s nelegei cum funcioneaz:

SELECT DISTINCT LIMBA_COD FROM FILM_LIMBA; LIMBA_COD ------------------------------------------de (Germana) en (Engleza) es (Spaniola) fr (Franceza) Proprietarul magazinului vrea s vad efectul recentei creteri de preuri i are nevoie de o list a tranzaciilor (TRANZACTIE_ID) n care clientul a pltit mai mult dect taxa medie (INCHIRIAT_TAXA) pentru un film. Iat cum arat interogarea: SELECT DISTINCT TRANZACTIE_ID FROM FILM_INCHIRIAT WHERE INCHIRIAT_TAXA> (SELECT AVG(INCHIRIAT_TAXA) FROM FILM_INCHIRIAT) Interogarea intern calculeaz media taxelor de nchiriere, iar interogarea extern gsete apoi toate rndurile din tabelul FILM_INCHIRIAT pentru care valoarea INCHIRIAT_TAXA depete media. Cuvntul cheie DISTINCT elimin tranzaciile duplicate. Rezultatele interogrii anterioare ar fi mai utile pentru proprietarul magazinului dac ar include i data tranzaciei. O modalitate de a realiza acest lucru este i adugm o uniune cu tabelul CLIENT_TRANZACTIE n interogarea extern. Totui, deoarece tocmai ai nvat despre subinterogari, s facem acelai lucru folosind nc o subinterogare. Iat cum arat interogarea: SELECT TRANZACTIE_ID, TRANZACTIE_DATA AS TRANZ_DATA FROM CLIENT_TRANZACTIE WHERE TRANZACTIE_ID IN (SELECT DISTINCT TRANZACTIE_ID FROM FILM_INCH, WHERE INCH_TAXA > (SELECT AVG ( INCHIRIAT_TAXA) FROM FILM_INCHIRIAT) TRANZACTIE_ID TRANZ_DATA 9 03/01/2005 10 03/01/2005

Exemplu(din galeria de arta): a) S se afieze titlul, codul artistului i valoarea operelor create de artistul cruia i aparine opera avnd codul 180 i care se afl expuse n aceeai galerie cu operele al cror cod este 100 sau 110. Se presupune c o oper are un singur autor. SELECT titlu, cod_artist, valoare FROM opera WHERE cod_artist = (SELECT cod_artist FROM opera WHERE cod_opera = 180) AND cod_galerie IN (SELECT cod_galerie FROM opera WHERE cod_opera IN (100, 110)); b) S se determine artistul pentru care valoare medie a operelor sale de art este minim. SELECT cod_artist, AVG(valoare) FROM opera GROUP BY cod_artist HAVING AVG(valoare) = (SELECT MIN(AVG(valoare)) FROM opera GROUP BY cod_artist); c) Pentru fiecare artist, s se afieze titlul i valoarea celei mai ieftine opere de art expuse n muzeu. SELECT titlu, cod_artist, valoare FROM opera WHERE valoare IN (SELECT MIN(valoare) FROM opera GROUP BY cod_artist); d) S se afieze operele de art care nu sunt expuse n galeria avnd codul 30 i a cror valoare este mai mic dect a unei opere din galeria 30. SELECT cod_opera, titlu, valoare FROM opera WHERE valoare < ANY (SELECT valoare FROM opera WHERE cod_galerie = 30) AND cod_galerie <> 30; Dac operatorul ANY se nlocuiete cu operatorul ALL, cererea precedent

returneaz operele care nu sunt expuse n galeria 30 i a cror valoare este mai mic dect a oricrei opere din galeria respectiv. e) S se afieze cele mai scumpe 3 opere de art din muzeu. SELECT ROWNUM "Nr.Crt", titlu, valoare FROM (SELECT titlu, valoare FROM opera ORDER BY valoare DESC) WHERE ROWNUM <= 3; Exemplu: Din punct de vedere logic, urmtoarea cerere ar trebui s returneze titlurile operelor care nu sunt expuse n galeriile unde se afl lucrrile artistului avnd codul 60. SELECT titlu FROM opera WHERE cod_galerie NOT IN (SELECT cod_galerie FROM opera WHERE cod_artist = 60); Dac pentru una dintre opere valoarea coloanei cod_galerie este null, ntreaga cerere nu va returna nici o linie, chiar dac exist nregistrri cu proprietatea cerut. Justificarea este c toate condiiile n care unul dintre operanzi este null au, de asemenea, valoarea null. Prin urmare, ori de cte ori este posibil ca n rezultatul subcererii s apar valori null, nu trebuie folosit operatorul NOT IN. Operatorul NOT IN este echivalent cu <>ALL. Dac se utilizeaz operatorul IN, nu mai este nici o problem dac n rezultatul subcererii apar valori null. Operatorul IN este echivalent cu =ANY. Exemplu: S se afieze titlurile operelor care sunt expuse n galeriile unde se afl lucrrile artistului avnd codul 60. SELECT titlu FROM opera WHERE cod_galerie IN (SELECT cod_galerie FROM opera WHERE cod_artist = 60); Pentru a evita obinerea de valori null n rezultatul unei cereri care utilizeaz operatorul NOT IN, se poate specifica o condiie n subcerere: SELECT titlu FROM opera

WHERE cod_galerie NOT IN (SELECT cod_galerie FROM opera WHERE cod_artist = 60 AND cod_galerie IS NOT NULL);

Subcereri (Subinterogri) corelate O subinterogare corelat (correlated subselect) este o subinterogare n care interogarea intern refer valorile furnizate de interogarea extern. Subcererile corelate sunt utilizate pentru procesarea linie cu linie a interogrilor. O subcerere este corelat dac face referin la o coloan dintr-un tabel specificat n instruciunea printe. O astfel de subcerere este evaluat o dat pentru fiecare linie procesat de instruciunea printe, care poate fi SELECT, UPDATE sau DELETE. Subcererile corelate permit compararea valorilor unei linii cu date determinate pe baza acestor valori. Cererile corelate se execut astfel: cererea extern determin o linie candidat; cererea intern este executat utiliznd valoarea liniei candidat; valorile rezultate din cererea intern sunt utilizate pentru calificarea sau descalificarea liniei candidat; paii precedeni se repet pn cnd nu mai exist linii candidat. Forma general a unei subcereri corelate este urmtoarea: SELECT nume_coloan_1[, nume_coloan_2 ] FROM nume_tabel_1 extern WHERE expresie operator (SELECT nume_coloan_1 [, nume_coloan_2 ] FROM nume_tabel_2 WHERE expresie_1 = extern.expresie_2);

Exemplu: Proprietarul magazinului vrea s transmit prin pot un cupon valoric tuturor clienilor care au pltit mai mult de 15$ pentru o singur tranzacie de nchiriere. SELECT DISTINCT CLIENT_CONT_ID

FROM CLIENT_TRANZACTIE A WHERE 15 < (SELECT SUM (INCHIRIAT_TAXA) FROM FILM_INCHIRIATB WHERE A.TRANZACTIE _ID = B.TRANZACTIE_ID) CLIENT_CONT_ID 2 7 9 Observai pseudonimele asociate numelor de tabele din interogrile intern i extern, precurn i folosirea acestora n clauza WHERE a interogrii interne. Acesta este elementul de identificare al unei subinterogri corelate. Interogarea extern selecteaz o lista de valori CLIENT_CONT_ID distincte din tabelul CLIENT_TRANZACTIE. Fiecare valoare gsit este transmis interogrii interne, care este rulat pentru a calcula suma taxelor de nchiriere din tranzacia respectiv. Dac suma taxelor de nchiriere este mai mare sau egal cu 15, atunci clauza WHERE din interogarea extern ia valoarea logic adevrat", iar rndul CLIENT_ID este adugat n setul de rezultate. Vizualizri n linie Foarte puine implementri, printre care Oracle, permit folosirea unei subinterogri n clauza FROM a unei interogri, ntr-o construcie numit vizualizare n linie (inline view). Aceast construcie permite care setul de rezultate al unei interogri s fie tratat ca i cum ar fi un tabel sau o vizualizare predefinit. Iat un exemplu: Aceast interogare afl numrul maxim de nchirieri ale unui singur film; SELECT MAX(INCHIRIAT_NUMAR) AS MAX_INCHIRIAT_NUMAR FROM (SELECT FILM_ID, NUMAR(*) AS INCHIRIAT_NUMAR FROM FILM_INCHIRIAT GROUP BY FILM_ID) MAX_INCH_NUMAR 5 Interogarea intern calculeaz numrul de nchirieri pentru fiecare valoare FILM_ID. Interogarea extern selecteaz valoarea maxim INCHIRIAT_NUMAR din interogarea intern, tratat ca i cum ar fi o vizualizare predefinit. Nu exist nici o limit n privina modurilor de utilizare a vizualizrilor n linie - putei chiar s le unii cu alte tabele sau vizualizri.

Exemplu de subcereri corelate pentru galeria de arta): a) S se afieze informaii despre operele de art a cror valoare depete valoarea medie a celor expuse n aceeai galerie. SELECT titlu, valoare, cod_galerie FROM opera o WHERE valoare > (SELECT AVG(valoare) FROM opera WHERE cod_galerie = o.cod_galerie); b) S se afieze codul, numele i prenumele artitilor care au cel puin dou opere de art expuse n muzeu. SELECT cod_artist, nume, prenume FROM artist a WHERE 2 <= (SELECT COUNT(*) FROM opera WHERE cod_artist = a.cod_artist); Server-ul Oracle evalueaz subcererea corelat precedent urmnd succesiunea de pai prezentat n continuare. 1) Selecteaz o linie din tabelul specificat n cererea extern (aceasta va fi linia candidat curent). 2) Reine valoarea coloanei referite n subcerere din aceast linie candidat (n cazul subcererii de mai sus, coloana referit n subcerere este a.cod_artist). 3) Efectueaz subcererea, considernd condiia acesteia ca facnd referin la valoarea liniei candidat din cererea extern (n exemplul precedent, funcia COUNT(*) este evaluat pe baza valorii lui a.cod_artist determinat la pasul 2). 4) Evalueaz clauza WHERE a cererii externe pe baza rezultatelor returnate de cererea intern la pasul 3. Adic, se determin dac linia candidat este selectat n rezultatul cererii (n exemplul precedent, numrul de opere ale unui artist, evaluat de subcerere, este comparat cu 2 n clauza WHERE a cererii externe, iar dac aceast condiie este satisfcut, linia corespunztoare artistului respectiv va face parte din rezultat). 5) Procedura se repet pentru urmtoarele linii candidat din tabel, pn cnd sunt procesate toate liniile tabelului.

Operatorul EXISTS n instruciunile SELECT imbricate, este permis utilizarea oricrui operator logic. Pentru a testa dac valoarea recuperat de cererea extern exist n mulimea valorilor regsite de cererea intern corelat, se poate utiliza operatorul EXISTS. Dac subcererea returneaz cel puin o linie, operatorul returneaz valoarea TRUE. n caz contrar, va fi returnat valoarea FALSE. Operatorul EXISTS asigur c nu mai este continuat cutarea n cererea intern dup ce aceasta regsete o linie. Exemplu: a) S se determine codul, numele i prenumele artitilor care au cel puin o oper de art expus n muzeu. SELECT cod_artist, nume, prenume FROM artist a WHERE EXISTS (SELECT 'x' FROM opera WHERE cod_artist = a.cod_artist); ntruct nu este necesar ca instruciunea SELECT interioar s returneze o anumit valoare, se poate selecta o constant. De altfel, din punct de vedere al performanei, selectarea unei constante asigur mai mult rapiditate dect selectarea unei coloane. Ca alternativ a lui EXISTS, poate fi utilizat operatorul IN. Exemplul precedent poate fi rezolvat prin instruciunea urmtoare: SELECT cod_artist, nume, prenume FROM artist WHERE cod_artist IN (SELECT cod_artist FROM opera); b) S se determine operele care nu sunt menionate n nici o surs bibliografic. SELECT cod_opera, titlu FROM opera o WHERE NOT EXISTS (SELECT 'x' FROM mentionata_in WHERE cod_opera = o.cod_opera); Acest exemplu poate fi rezolvat i printr-o subcerere necorelat, utiliznd operatorul NOT IN: SELECT cod_opera, titlu FROM opera

WHERE

cod_opera NOT IN (SELECT cod_opera FROM ment_in WHERE cod_opera IS NOT NULL);

Instruciuni LMD corelate Subcererile corelate pot fi utilizate pentru actualizarea sau tergerea de nregistrri dintr-un tabel pe baza liniilor altui tabel. Forma general a unei instruciuni corelate UPDATE, respectiv DELETE, este urmtoarea: UPDATE nume_tabel_1 alias_1 SET nume_coloan = (SELECT FROM WHERE expresie nume_tabel_2 alias_2 alias_1.nume_coloan = alias_2.nume_coloan);

DELETE FROM nume_tabel_1 alias_1 WHERE expresie operator (SELECT expresie FROM nume_tabel_2 alias_2 WHERE alias_1.nume_coloan = alias_2.nume_coloan); Exemplu: Se presupune c valorile operelor sunt mrite cu 20% din costul ultimei polie de asigurare ncheiate. S se actualizeze corespunztor valoarea operelor care beneficiaz de cel puin o poli de asigurare. UPDATE opera SET valoare = (SELECT opera.valoare + polita_asig.valoare*0.20 FROM polita_asig WHERE cod_opera = opera.cod_opera AND semnat_contract = (SELECT MAX(semnat_contract) FROM polita_asig WHERE cod_opera = opera.cod_opera)) WHERE opera.cod_opera IN (SELECT DISTINCT cod_opera FROM polita_asig); Exemplu: Pentru fiecare autor care are mai mult de 10 creaii expuse n muzeu, s se

tearg ultima oper creat de acesta. DELETE FROM opera o1 WHERE cod_artist = (SELECT cod_artist FROM opera o2 WHERE cod_artist = o1.cod_artist AND data_crearii = (SELECT MAX(data_crearii) FROM opera WHERE cod_artist = o2.cod_artist) AND 10 > (SELECT COUNT(*) FROM opera WHERE cod_artist = o2.cod_artist)); Clauza WITH Cu ajutorul clauzei WITH se poate defini un bloc de cerere nainte ca acesta s fie utilizat ntr-o interogare. Clauza permite reutilizarea aceluiai bloc de cerere ntr-o instruciune SELECT complex. Acest lucru este util atunci cnd o cerere face referin de mai multe ori la acelai bloc de cerere, care conine operaii join i funcii agregat. Folosind clauza WITH, server-ul Oracle regsete rezultatele unui bloc de cerere i le stocheaz n spaiul tabel temporar al utilizatorului, ceea ce poate determina mbuntirea performanelor. Exemplu: Utiliznd clauza WITH, s se scrie o cerere care afieaz numele artitilor i valoarea total a operelor acestora. Se vor considera artitii a cror valoare total a operelor este mai mare dect media valorilor totale ale operelor tuturor artitilor. WITH val_artist AS (SELECT nume, SUM(valoare) AS total FROM opera o, artist a WHERE o.cod_artist = a.cod_artist GROUP BY nume), val_medie AS (SELECT SUM(total)/COUNT(*) AS medie FROM val_artist) SELECT * FROM val_artist WHERE total > (SELECT medie FROM val_medie) ORDER BY nume; Intern, clauza WITH este tratat ca o vizualizare inline (subcerere n clauza

FROM) sau ca un tabel temporar. Optimizorul alege decizia adecvat pe baza costului sau beneficiului stocrii temporare a rezultatelor clauzei WITH. Observaii: Clauza WITH poate fi folosit numai pentru instruciuni SELECT. Un nume de cerere este vizibil tuturor blocurilor din clauza WITH definite ulterior (inclusiv subcererilor acestora). De asemenea, un nume de cerere este vizibil cererii principale i subcererilor acesteia. Cnd un nume de cerere coincide cu numele unui tabel, numele blocului de cerere are preceden asupra numelui tabelului. Clauza WITH poate conine mai mult dect o singur cerere. n acest caz, cererile sunt separate prin virgule. Subcereri scalare Subcererile scalare n SQL returneaz valoarea unei singure coloane corespunztoare unei linii. Dac subcererea returneaz 0 linii, valoarea subcererii scalare este null. Dac subcererea returneaz mai mult de o linie, server-ul genereaz o eroare. Subcererile scalare erau acceptate n Oracle8i doar n anumite cazuri, cum ar fi clauzele FROM i WHERE ale instruciunii SELECT sau clauza VALUES a instruciunii INSERT. Utilitatea subcererilor scalare a fost extins n Oracle9i. Astfel, ele pot aprea n: condiiile i expresiile care fac parte din DECODE sau CASE; toate clauzele instruciunii SELECT, cu excepia lui GROUP BY; n partea stng a operatorului, n clauzele SET i WHERE ale instruciunii UPDATE. Subcererile scalare nu sunt permise n urmtoarele situaii: ca valori implicite pentru coloane sau ca expresii hash pentru grupri; n clauza RETURNING a instruciunilor LMD; n clauza GROUP BY, constrngerile de tip CHECK, condiiile WHEN; n instruciunile care nu sunt legate de cereri, cum ar fi CREATE PROFILE. Exemplu: S se afieze codul, titlul operelor i numele artistului doar dac acesta este Brncui. n caz contrar, se va afia irul alt artist. SELECT cod_opera, titlu, (CASE WHEN cod_artist = (SELECT cod_artist FROM artist WHERE nume = 'Brancusi')

THEN 'Brancusi' ELSE 'Alt artist' END) artist FROM opera; 2.4.4. Funcii grup i clauza GROUP BY Clauza GROUP BY este utilizat pentru a diviza liniile unui tabel n grupuri. Pentru a returna informaia corespunztoare fiecrui astfel de grup, pot fi utilizate funciile agregat. Ele pot aprea n clauzele SELECT, ORDER BY i HAVING. Server-ul Oracle aplic aceste funcii fiecrui grup de linii i returneaz un singur rezultat pentru fiecare mulime. Dintre funciile grup definite n sistemul Oracle, se pot enumera: AVG, SUM, MAX, MIN, COUNT, STDDEV, VARIANCE, DENSE_RANK, RANK, FIRST, LAST, GROUP_ID, GROUPING, GROUPING_ID etc. Tipurile de date ale argumentelor funciilor grup pot fi CHAR, VARCHAR2, NUMBER sau DATE. Funciile AVG, SUM, STDDEV i VARIANCE opereaz numai asupra valorilor numerice. Funciile MAX i MIN pot opera asupra valorilor numerice, caracter sau de tip dat calendaristic. Toate funciile grup, cu excepia lui COUNT(*), ignor valorile null. COUNT(expresie) returneaz numrul de linii pentru care expresia dat nu are valoarea null. Funcia COUNT returneaz un numr mai mare sau egal cu zero i nu ntoarce niciodat valoarea null. Cnd este utilizat clauza GROUP BY, server-ul sorteaz implicit mulimea rezultat n ordinea cresctoare a valorilor coloanelor dup care se realizeaz gruparea. n clauza GROUP BY a unei cereri se pot utiliza operatorii ROLLUP i CUBE. Acetia sunt disponibili ncepnd cu versiunea Oracle8i. Operatorul ROLLUP Operatorul ROLLUP produce o mulime care conine liniile obinute n urma gruprii obinuite i linii pentru subtotaluri. Acest operator furnizeaz valori agregat i superagregat corespunztoare expresiilor din clauza GROUP BY. Operatorul ROLLUP poate fi folosit pentru extragerea de statistici i informaii totalizatoare din mulimile rezultate. Acest operator poate fi util la generarea de rapoarte, diagrame i grafice. Operatorul ROLLUP creeaz grupri prin deplasarea ntr-o singur direcie, de la dreapta la stnga, de-a lungul listei de coloane specificate n clauza GROUP BY. Apoi, se aplic funcia agregat acestor grupri. Dac sunt specificate n expresii

n operatorul ROLLUP, numrul de grupri generate va fi n + 1. Liniile care se bazeaz pe valoarea primelor n expresii se numesc linii obinuite, iar celelalte se numesc linii superagregat. Dac n clauza GROUP BY sunt specificate n coloane, pentru a produce subtotaluri fr operatorul ROLLUP ar fi necesare n + 1 instruciuni SELECT conectate prin UNION ALL. Aceasta ar face execuia cererii ineficient deoarece fiecare instruciune SELECT determin accesarea tabelului. Operatorul ROLLUP determin rezultatele efectund un singur acces la tabel i este util atunci cnd sunt implicate multe coloane n producerea subtotalurilor. Exemplu: S se afieze codurile de galerii mai mici dect 50, iar pentru fiecare dintre acestea i pentru fiecare autor care are opere expuse n galerie, s se listeze valoarea total a lucrrilor sale. De asemenea, se cere valoarea total a operelor expuse n fiecare galerie. Rezultatul va conine i valoarea total a operelor din galeriile avnd codul mai mic dect 50, indiferent de codul autorului. SELECT cod_galerie, cod_artist, SUM(valoare) FROM opera WHERE cod_galerie < 50 GROUP BY ROLLUP(cod_galerie, cod_artist); Instruciunea precedent va avea un rezultat de forma: COD_GALERIE 10 10 10 40 40 COD_ARTIST 50 60 50 SUM(VALOARE) 14000 10000 24000 8080 8080 32080

n rezultatul prezentat anterior se pot distinge 3 tipuri de linii. 1) Prima linie reprezint suma operelor artistului care are codul 50, expuse n galeria avnd codul 10. n mod similar se interpreteaz a doua i a patra linie din rezultat. 2) Linia a treia i a cincea din rezultat conin valoarea total a operelor din galeria al crei cod este 10, respectiv 40. Aceste linii se disting prin faptul c valoarea coloanei cod_artist este null. 3) Ultima linie conine suma valorilor tuturor operelor din galeriile al cror

cod este 10 sau 40. Valoarea afiat este obinut prin nsumarea valorilor de pe a treia, respectiv a cincea linie. ntruct aceast linie corespunde totalului general, ea conine valoarea null pe toate coloanele, cu excepia cmpului SUM(valoare). Operatorul CUBE Operatorul CUBE grupeaz liniile selectate pe baza valorilor tuturor combinaiilor posibile ale expresiilor specificate i returneaz cte o linie totalizatoare pentru fiecare grup. Acest operator este folosit pentru a produce mulimi de rezultate care sunt utilizate n rapoarte. n vreme ce ROLLUP produce subtotalurile doar pentru o parte dintre combinaiile posibile, operatorul CUBE produce subtotaluri pentru toate combinaiile posibile de grupri specificate n clauza GROUP BY, precum i un total general. Dac exist n coloane sau expresii n clauza GROUP BY, vor exista 2n combinaii posibile superagregat. Din punct de vedere matematic, aceste combinaii formeaz un cub n-dimensional, de aici provenind numele operatorului. Pentru producerea de subtotaluri fr ajutorul operatorului CUBE ar fi necesare 2n instruciuni SELECT conectate prin UNION ALL. Exemplu: S se afieze valoarea total a operelor de art ale unui autor, expuse n cadrul fiecrei galerii avnd codul mai mic dect 50. De asemenea, s se afieze valoarea total a operelor din fiecare galerie avnd codul mai mic dect 50, valoarea total a operelor fiecrui autor indiferent de galerie i valoarea total a operelor din galeriile avnd codul mai mic dect 50. SELECT cod_galerie, cod_artist, SUM(valoare) FROM opera WHERE cod_galerie < 50 GROUP BY CUBE(cod_galerie, cod_artist); Instruciunea precedent va genera un rezultat de forma urmtoare: COD_GALERIE 10 10 10 40 40 COD_ARTIST 50 60 50 50 60 SUM(VALOARE) 14000 10000 24000 8080 8080 22080 10000

32080 n plus fa de rezultatul corespunztor operaiei ROLLUP, operatorul CUBE a produs linii care reprezint suma valorilor operelor pentru fiecare artist care a expus n galerii avnd codul mai mic dect 50. Aceste linii se disting prin faptul c valoarea coloanei cod_galerie este null. Funcia GROUPING Funcia GROUPING poate fi utilizat alturi de operatorii CUBE i ROLLUP pentru a arta modul cum a fost obinut o valoare totalizatoare. Aceast funcie accept un singur argument, care trebuie s fie una dintre expresiile specificate n clauza GROUP BY. O valoare null a expresiei din argumentul funciei GROUPING poate proveni din tabelul de baz (valoare null stocat) sau poate fi o valoare null creat de operaia ROLLUP sau CUBE ca rezultat al unei funcii grup asupra expresiei respective. Funcia GROUPING returneaz valoarea 0 sau 1. Valoarea 0 returnat de funcia GROUPING pe baza unei expresii poate indica fie c expresia a fost utilizat pentru calculul valorii agregat, fie c valoarea null a expresiei este o valoare null stocat. Valoarea 1 returnat de funcia GROUPING pe baza unei expresii poate indica fie c expresia nu a fost utilizat pentru calculul valorii agregat, fie c valoarea null a expresiei este creat de ROLLUP sau CUBE ca rezultat al gruprii. Valorile returnate de funcia GROUPING sunt utile pentru: determinarea nivelului de agregare al unui subtotal dat, adic a grupului sau grupurilor pe care se bazeaz subtotalul respectiv; identificarea provenienei unei valori null a unei expresii calculate, dintruna din liniile mulimii rezultat. Exemplu: SELECT cod_galerie, cod_artist, SUM(valoare), GROUPING(cod_galerie), GROUPING(cod_artist) FROM opera WHERE cod_galerie < 50 GROUP BY ROLLUP(cod_galerie, cod_artist); COD_GALERIE COD_ARTIST 10 SUM GROUPING GROUPING (VALOARE) (COD_GALERIE) (COD_ARTIST) 50 14000 0 0

10 10 40 40

60 50

10000 24000 8080 8080 32080

0 0 0 0 1

0 1 0 1 1

Pe prima linie din acest rezultat, valoarea totalizatoare reprezint suma valorilor operelor artistului avnd codul 50, n cadrul galeriei 10. Pentru a calcula aceast valoare au fost luate n considerare coloanele cod_galerie i cod_artist. Prin urmare, expresiile GROUPING(cod_galerie) i GROUPING(cod_artist) au valoarea 0 pentru prima linie din rezultat. Pe linia a treia se afl valoarea total a operelor din galeria avnd codul 10. Aceast valoare a fost calculat lund n considerare doar coloana cod_galerie, astfel nct GROUPING (cod_galerie) i GROUPING(cod_artist) au valorile 0, respectiv 1. Pe ultima linie din rezultat se afl valoarea total a operelor din galeriile avnd codul mai mic dect 50. Nici una dintre coloanele cod_galerie i cod_artist nu au intervenit n calculul acestui total, prin urmare valorile corespunztoare expresiilor GROUPING(cod_galerie) i GROUPING(cod_artist) sunt 0. Clauza GROUPING SETS GROUPING SETS reprezint o extensie a clauzei GROUP BY care permite specificarea unor grupri multiple de date. Utilizarea acestei opiuni faciliteaz analiza datelor n mai multe dimensiuni. Aceast extensie, aprut n sistemul Oracle9i, permite scrierea unei singure instruciuni SELECT pentru a specifica grupri diferite (care pot conine operatorii ROLLUP i CUBE), n loc de mai multe instruciuni SELECT combinate prin operatorul UNION ALL. De altfel, reuniunea rezultatelor mai multor cereri este ineficient ntruct necesit mai multe parcurgeri ale acelorai date. Operatorii ROLLUP i CUBE pot fi considerai cazuri particulare de mulimi de grupri. Au loc urmtoarele echivalene: CUBE(a, b, c) GROUPING SETS ((a, b, c), (a, b), (a, c), (b, c), (a), (b), (c), ()) ROLLUP(a, b, GROUPING SETS c) ((a, b, c), (a, b), (a), ()) Exemplu: Considernd galeriile al cror cod este mai mic dect 50, s se calculeze media valorilor operelor:

pentru fiecare galerie i, n cadrul acesteia, pentru fiecare artist; pentru fiecare artist i, n cadrul acestuia, pentru anii de achiziie corespunztori. SELECT cod_galerie, cod_artist, TO_CHAR(data_achizitiei, 'yyyy') "an achizitie", AVG(valoare) "Valoare medie" FROM opera WHERE cod_galerie < 50 GROUP BY GROUPING SETS ((cod_galerie, cod_artist), (cod_artist, TO_CHAR(data_achizitiei, 'yyyy'))); Mulimea rezultat este constituit din valorile medii pentru fiecare dintre cele dou grupuri i are forma urmtoare: COD_GALERIE COD_ARTIST 10 50 10 60 40 50 50 50 60 60 an a Valoare medie 3500 2500 2020 2380 2300 2000 3000

2000 2002 2001 2003

Exemplul precedent poate fi rezolvat i prin urmtoarea instruciune compus: SELECT cod_galerie, cod_artist, NULL "an achizitie", AVG(valoare) "Valoare medie" FROM opera GROUP BY cod_galerie, cod_artist UNION ALL SELECT NULL, cod_artist, TO_CHAR(data_achizitiei, 'yyyy'), AVG(valoare) FROM opera GROUP BY cod_artist, TO_CHAR(data_achizitiei, 'yyyy'); n absena unui optimizor care analizeaz blocurile de cerere i genereaz planul de execuie, cererea precedent va parcurge de dou ori tabelul de baz (opera), ceea ce poate fi ineficient. Din acest motiv, este recomandat utilizarea

extensiei GROUPING SETS. Coloane compuse O coloan compus este o colecie de coloane care sunt tratate unitar n timpul calculelor asupra grupurilor. Pentru a specifica o coloan compus, aceasta se include ntre paranteze. n operaia ROLLUP(a, (b, c), d), coloanele b i c formeaz o coloan compus i sunt tratate unitar. n general, coloanele compuse sunt utile pentru operaiile ROLLUP, CUBE i GROUPING SETS. De exemplu, n CUBE sau ROLLUP coloanele compuse pot determina eliminarea agregrii de pe anumite niveluri. Clauza GROUP BY ROLLUP(a, (b, c)) este echivalent cu urmtoarea instruciune compus (n care se precizeaz doar forma clauzelor GROUP BY): GROUP BY a, b, c UNION ALL GROUP BY a UNION ALL GROUP BY ( ) Astfel, (b, c) sunt tratate unitar i operaia ROLLUP nu va fi efectuat asupra grupurilor n care coloanele b i c nu apar simultan. Acest lucru este similar situaiei n care este definit un alias x pentru (b, c), iar specificaia clauzei GROUP BY este GROUP BY ROLLUP(a, x). n instruciunea precedent, GROUP BY () reprezint instruciunea SELECT cu valori null pentru coloanele a i x. Aceast clauz este folosit pentru generarea totalurilor generale: SELECT null, null, coloan_agregat FROM nume_tabel GROUP BY (); Urmtorul tabel prezint cteva specificaii care utilizeaz operatorii ROLLUP, CUBE, GROUPING SETS, mpreun cu instruciunile compuse echivalente acestora: GROUP BY ROLLUP(a, b, c) GROUP BY a, b, c ALL GROUP BY a, b ALL GROUP BY a GROUP BY a, b, c ALL GROUP BY a, b UNION UNION

GROUP BY CUBE( (a, b), c)

UNION UNION

ALL GROUP BY c UNION ALL GROUP BY() GROUP BY GROUPING SETS(a, b, GROUP BY a UNION ALL c) GROUP BY b UNION ALL GROUP BY c GROUP BY GROUPING SETS GROUP BY a UNION ALL (a, b, (b, c) ) GROUP BY b UNION ALL GROUP BY b, c GROUP BY GROUPING SETS( (a, b, GROUP BY a, b, c c) ) GROUP BY GROUPING SETS(a, GROUP BY a UNION ALL (b), ()) GROUP BY b UNION ALL GROUP BY () GROUP BY GROUPING SETS (a, GROUP BY a UNION ALL ROLLUP(b, c)) GROUP BY ROLLUP(b, c) Exemplu: S se afieze urmtoarele informaii: valoarea medie a operelor de art din fiecare galerie; valoarea medie a operelor de art pentru fiecare galerie, iar n cadrul acesteia pentru fiecare artist i fiecare an de achiziie; media general a tuturor valorilor operelor de art. SELECT cod_galerie, cod_artist, TO_CHAR(data_achizitiei, 'yyyy') "an achizitie", AVG(valoare) "Valoare medie" FROM opera GROUP BY ROLLUP (cod_galerie, (cod_artist, TO_CHAR(data_achizitiei, 'yyyy'))); Exemplul precedent poate fi rezolvat utiliznd cererea compus prezentat mai jos. Folosirea coloanelor compuse este recomandat pentru asigurarea unei execuii eficiente. SELECT cod_galerie, cod_artist, TO_CHAR(data_achizitiei, 'yyyy'), AVG(valoare) "Valoare medie" FROM opera

GROUP BY cod_galerie, cod_artist, TO_CHAR(data_achizitiei, 'yyyy') UNION ALL SELECT cod_galerie, TO_NUMBER(null), TO_CHAR(null), AVG(valoare) "Valoare medie" FROM opera GROUP BY cod_galerie UNION ALL SELECT TO_NUMBER(null), TO_NUMBER(null), TO_CHAR(null), AVG(valoare) "Valoare medie" FROM opera GROUP BY (); Concatenarea gruprilor Concatenarea gruprilor reprezint o modalitate concis de a genera combinaii de grupri. Acestea se specific prin enumerarea mulimilor de grupri (grouping sets) i a operaiilor ROLLUP, CUBE separate prin virgul. De exemplu, expresia GROUP BY GROUPING SETS(a, b), GROUPING SETS(c, d) definete gruprile (a, c), (a, d), (b, c), (b, d). Concatenarea mulimilor de grupri este util att pentru uurina dezvoltrii cererilor, ct i pentru aplicaii. Codul SQL generat de aplicaiile OLAP implic deseori concatenarea mulimilor de grupri, n care fiecare astfel de mulime definete gruprile necesare pentru o dimensiune. Exemplu: S se determine media valorilor operelor lund n considerare urmtoarele grupri: (cod_galerie, cod_artist, an_achizitie), (cod_galerie, cod_artist), (cod_galerie, an_achizitie), (cod_galerie). SELECT cod_galerie, cod_artist, TO_CHAR(data_achizitiei, 'yyyy') an_achizitie, AVG(valoare) FROM opera GROUP BY cod_galerie, ROLLUP(cod_artist), CUBE(TO_CHAR(data_achizitiei, 'yyyy')); Funcii analitice Funciile analitice calculeaz o valoare agregat pe baza unui grup de nregistrri. Ele difer de funciile agregat prin faptul c, pentru fiecare grup, pot fi returnate mai multe linii rezultat.

Aceste funcii reprezint ultimul set de operaii efectuat la procesarea unei interogri, naintea clauzei ORDER BY. Din acest motiv, o funcie analitic poate aprea numai n lista SELECT sau n clauza ORDER BY. Exemplu: Pentru fiecare oper de art, s se afle numrul de creaii ale cror valori sunt cu cel mult 1000 mai mici i cu cel mult 2000 mai mari dect valoarea operei respective. SELECT titlu, valoare, COUNT(*) OVER (ORDER BY valoare RANGE BETWEEN 1000 PRECEDING AND 2000 FOLLOWING) AS nr_dom FROM opera; Cuvntul cheie OVER indic faptul c funcia opereaz pe mulimea de rezultate a cererii, adic dup evaluarea celorlalte clauze. Opiunea RANGE definete, pentru fiecare linie, o fereastr (o mulime de linii). Funcia analitic va fi aplicat tuturor liniilor din aceast mulime. 2.4.5. Interogri ierarhice Interogrile ierarhice permit regsirea datelor pe baza unei relaii ierarhice care exist ntre liniile tabelului. O baz de date relaional nu stocheaz nregistrrile n mod ierarhic. Dac exist o relaie ierarhic ntre liniile unui tabel, un proces de parcurgere a unui arbore (tree walking) permite construirea ierarhiei. O cerere ierarhic este o metod de raportare, n ordine, a ramurilor arborelui. n tabelul opera, se poate imagina o structur arborescent pe baza valorilor echivalente ale anilor corespunztori coloanelor data_crearii i data_achizitiei. Relaia printe-copil a unei structuri arborescente permite controlul direciei n care este parcurs ierarhia i stabilirea rdcinii ierarhiei. Clauzele instruciunii SELECT care intervin n formularea unei cereri ierarhice sunt START WITH i CONNECT BY. Acestea au fost prezentate mpreun cu instruciunea SELECT, la nceputul acestui capitol. Pseudocoloana LEVEL poate fi util ntr-o cerere ierarhic. Aceasta determin lungimea drumului de la rdcin la un nod. Operatorul PRIOR face referin la linia printe. Plasarea acestui operator determin direcia interogrii, dinspre printe spre copil (top-down) sau invers (bottom-up). Traversarea top-down, respectiv bottom-up a arborelui se realizeaz prin specificri de forma urmtoare:

CONNECT BY PRIOR cheie_parinte = cheie_copil; CONNECT BY PRIOR cheie_copil = cheie_parinte; Operatorul PRIOR poate fi plasat n faa oricrui membru al condiiei specificate n clauza CONNECT BY. Liniile printe ale interogrii sunt identificate prin clauza START WITH. Pentru a gsi liniile copil, server-ul evalueaz expresia din dreptul operatorului PRIOR pentru linia printe, i cealalt expresie pentru fiecare linie a tabelului. nregistrrile pentru care condiia este adevrat vor fi liniile copil. Spre deosebire de START WITH, n clauza CONNECT BY nu pot fi utilizate subcereri. Exemplu: a) S se afieze codul, titlul, data crerii i data achiziiei operelor, astfel nct fiecare oper s fie urmat de cele achiziionate n anul crerii sale. Prima linie afiat va fi cea corespunztoare operei avnd codul 110. SELECT cod_opera, titlu, data_crearii, data_achizitiei FROM opera START WITH cod_opera = 110 CONNECT BY PRIOR TO_CHAR(data_crearii, 'yyyy') = TO_CHAR(data_achizitiei, 'yyyy'); b) Se cer aceleai informaii ca la punctul a), cu deosebirea c prima linie afiat va fi cea corespunztoare operei avnd valoarea maxim. SELECT 'In anul in care a fost creata "'|| titlu || ' " s-a achizitionat "' || PRIOR titlu || '"' "traversare bottom-up " FROM opera START WITH valoare = (SELECT MAX(valoare) FROM opera) CONNECT BY PRIOR TO_CHAR(data_achizitiei, 'yyyy') = TO_CHAR(data_crearii, 'yyyy'); c) S se afieze codul, titlul, data crerii i data achiziiei operelor, astfel nct fiecare oper s fie urmat de cele achiziionate n anul crerii sale. Se vor considera doar operele a cror valoare este mai mare dect 7000. Prima linie afiat va fi cea corespunztoare operei create cel mai recent. SELECT cod_opera, titlu, data_crearii, data_achizitiei, valoare FROM opera START WITH data_crearii = (SELECT MAX(data_crearii) FROM opera)

CONNECT BY PRIOR TO_CHAR(data_crearii, 'yyyy') = TO_CHAR(data_achizitiei, 'yyyy') AND valoare > 7000; n clauza CONNECT BY, coloana data_crearii este evaluat pentru linia printe, iar coloanele data_achizitiei i valoare sunt evaluate pentru linia copil. d) S se afieze ierarhia sub forma unui raport, folosindu-se indentri. Fiecare linie a tabelului va fi considerat drept rdcin. SELECT LEVEL, LPAD(titlu, LENGTH(titlu) + (LEVEL * 2) - 2, '_') succesiune FROM opera CONNECT BY PRIOR TO_CHAR(data_crearii, 'yyyy') = TO_CHAR(data_achizitiei, 'yyyy'); Exemplu: a) S se afieze codul, titlul, data crerii i data achiziiei operelor de art expuse n muzeu, astfel nct fiecare oper s fie urmat de cele achiziionate n anul crerii acesteia. Prima linie afiat va fi cea corespunztoare operei pictorului Nicolae Grigorescu, achiziionat cel mai recent. Rezultatul nu va conine operele create n anul 1970, dar va conine operele achiziionate n acest an. WITH opera_ng AS (SELECT cod_opera, data_achizitiei FROM opera WHERE cod_artist = (SELECT cod_artist FROM artist WHERE INITCAP(nume) = 'Grigorescu' AND INITCAP(prenume) = 'Nicolae')) SELECT cod_opera, titlu, data_crearii, data_achizitiei FROM opera WHERE TO_CHAR(data_crearii, 'yyyy') != 1970 START WITH (cod_opera, data_achizitiei) IN (SELECT cod_opera, data_achizitiei FROM opera_ng WHERE data_achizitiei = (SELECT MAX(data_achizitiei) FROM opera_ng)) CONNECT BY PRIOR TO_CHAR(data_crearii, 'yyyy') =

TO_CHAR(data_achizitiei, 'yyyy'); b) S se afieze informaiile solicitate la punctul a), cu deosebirea c prima linie listat este cea al crei cod este 110. Se vor elimina din rezultat liniile corespunztoare operelor create sau achizionate n anul 1970. SELECT cod_opera, titlu, data_crearii, data_achizitiei FROM opera START WITH cod_opera = 110 CONNECT BY PRIOR TO_CHAR(data_crearii, 'yyyy') = TO_CHAR(data_achizitiei, 'yyyy') AND TO_CHAR(data_crearii, 'yyyy') != 1970;

Curs6_IP Subcereri De cele mai multe ori, pentru a implementa anumite interogri, nu este suficient o singur cerere SELECT ci sunt necesare subcereri. Subcererile sunt comenzi SELECT ncapsulate n oricare din clauzele SELECT, WHERE, HAVING, FROM. Dac subcererea urmeaz clauzei WHERE sau HAVING, ea poate conine unul dintre operatorii ALL, ANY, IN (=ANY), EXIST, NOT IN (!=ALL) care sunt specifici cererilor care ntorc mai multe linii (multiple-row subquery) sau unul dintre operatorii de comparare (=, <, >, >=, <=, <>) care sunt specifici cererilor care ntorc o singur linie (single-row subquery). Subcererile trebuie incluse ntre paranteze i trebuie plasate n partea dreapt a operatorului de comparare. Subcererea nu poate conine clauza ORDER BY. Exemplu: S se obin numele i salariul angajailor, avnd salariul minim. SELECT FROM WHERE Exemplu: ename, sal emp sal=(SELECT FROM

MIN(sal) emp);

S se obin job-ul pentru care salariul mediu este minim. Sa se afiseze si salariul mediu. SELECT job, AVG(sal) FROM emp GROUP BY job HAVING AVG(sal)=(SELECT FROM GROUP BY

MIN(AVG(sal)) emp job);

Operatorul ANY presupune c este adevrat condiia dac comparaia este adevrat pentru cel puin una din valorile returnate. Sunt evidente relaiile: < ANY mai mic ca maximul; > ANY mai mare ca minimul; = ANY IN. Pentru operatorul ALL se presupune c este adevrat condiia, dac comparaia este adevrat pentru toate elementele listei returnate. Pentru operatorul ALL sunt evidente relaiile: < ALL mai mic ca minimul; > ALL mai mare ca maximul; ! = ALL NOT IN. Exemplu: WHERE codec > ALL (C1, C2) este superior tuturor elementelor din list; WHERE codec > ANY (C1, C2) este superior cel puin unui element din list. Exemplu: S se obin salariaii al cror salariu este mai mare ca salariile medii din toate departamentele. SELECT FROM WHERE ename, job emp sal > ALL(SELECT FROM GROUP BY

AVG(sal) emp deptno);

Exist subcereri care au ca rezultat mai multe coloane (multiple-column subquery). Aceste interogri au urmtoarea sintax general: SELECT col,col,

FROM WHERE

tabel (col,col,) IN (SELECT col,col, FROM WHERE

tabel condiie);

Exemplu: S se obin numele, numrul departamentului, salariul i comisionul tuturor funcionarilor ale cror salarii i comisioane coincid cu salariile i comisioanele unor salariai din departamentul 7. SELECT FROM WHERE ename, deptno, sal, com emp (sal,NVL(com,-1)) IN (SELECT sal,NVL(com,-1) FROM emp WHERE deptno = 7); ename, deptno, sal, com emp sal IN (SELECT sal FROM emp WHERE deptno=7) NVL(com,-1) IN (SELECT NVL(com,-1) FROM emp WHERE deptno=7);

Rezultatul acestei interogri este diferit de rezultatul urmtoarei interogri: SELECT FROM WHERE

AND

Dac una din valorile returnate de subcerere este valoarea null atunci cererea nu ntoarce nici o linie. Prin urmare, dac valoarea null poate s fac parte din rezultatul subcererii nu trebuie utilizat operatorul NOT IN. Problema nu mai apare dac se utilizeaz operatorul IN.

Exemplu: S se obin salariaii care nu au subordonai. SELECT FROM WHERE e.ename emp e e.empno NOT IN (SELECT m.mgr FROM emp m);

n acest caz, instruciunea SQL nu ntoarce nici o linie deoarece una din valorile furnizate de subcerere este valoarea null.

Exemplu: S se obin numele salariailor, salariile, codul departamentului n care lucreaz i salariul mediu pe departament pentru toi angajaii care au salariul mai mare ca media salariilor din departamentul n care lucreaz (folosirea subcererii n clauza FROM). SELECT a.ename,a.sal,a.deptno,b.salavg FROM emp a,(SELECT deptno,avg(sal) salavg FROM emp GROUP BY deptno) b WHERE a.deptno=b.deptno AND a.sal>b.salavg Exemplu: S se obin lista celor mai scumpe cri. SELECT titlu FROM carte WHERE pret = (SELECT FROM carte);

MAX(pret)

Exemplu: S se obin lista scriitorilor care au n bibliotec un numr de exemplare mai mare dect numrul mediu al crilor din bibliotec. SELECT FROM WHERE DISTINCT autor carte nrex > (SELECT AVG(nrex) FROM carte);

Exemplu: S se obin informaii despre crile al cror pre depete media preurilor crilor ce aparin aceluiai domeniu SELECT FROM WHERE * carte c pret > (SELECT AVG(pret) FROM carte WHERE coded = c.coded);

Exemplu: S se obin lista cititorilor care au mprumutat cel puin o carte. SELECT FROM WHERE nume cititor codec IN (SELECT DISTINCT codec FROM imprumuta);

Exemplu: S se obin codurile cititorilor care nu au mprumutat niciodat cri. SELECT FROM WHERE codec cititor codec NOT IN (SELECT DISTINCT codec FROM imprumuta);

Exemplu: S se obin lista cititorilor care sunt n ntrziere cu predarea crilor. SELECT FROM WHERE nume cititor codec IN (SELECT FROM WHERE AND DISTINCT codec imprumuta dataef IS NULL dares<SYSDATE);

Exemplu: S se obin numele cititorilor care au mprumutat cel puin o carte scris de ZOLA. SELECT FROM WHERE nume cititor codec IN (SELECT DISTINCT codec FROM imprumuta WHERE codel IN (SELECT codel FROM carte WHERE autor=ZOLA));

Exemplu: S se obin numele cititorilor care nu au mprumutat nici o carte scris de ZOLA. SELECT FROM WHERE nume cititor codec NOT IN (SELECT DISTINCT codec FROM imprumuta WHERE codel IN (SELECT codel FROM carte WHERE autor=ZOLA));

Operatorul IN poate fi nlocuit cu = ANY (un element este n list dac i numai dac este egal cu un element al listei), iar operatorul NOT IN poate fi nlocuit prin !=ALL. Exemplu: S se obin codurile cititorilor care au mprumutat o carte de algebr. SELECT DISTINCT codec FROM imprumuta WHERE codel IN (SELECT codel FROM carte WHERE coded= (SELECT coded FROM domeniu WHERE intdom=ALGEBRA)); Exemplu: S se obin cititorii care au mprumutat numai cri scrise de ZOLA. SELECT FROM WHERE nume cititor codec NOT IN (SELECT DISTINCT codec FROM imprumuta WHERE codel NOT IN (SELECT codel FROM carte WHERE autor=ZOLA));

Exemplu: S se obin numele cititorilor care au mprumutat cel puin o carte de informatic (procedural). SELECT nume FROM cititor WHERE codec IN (SELECT DISTINCT codec FROM imprumuta WHERE codel IN (SELECT codel FROM carte WHERE coded= (SELECT coded

FROM domeniu WHERE intdom= INFORMATICA))); Exemplu: S se obin numele cititorilor i titlurile crilor de informatic mprumutate de aceti cititori (relational). SELECT FROM WHERE AND AND AND nume, titlu cititor, carte, imprumuta, domeniu imprumuta.codel = carte.codel carte.coded = domeniu.coded imprumuta.codec = cititor.codec intdom = INFORMATICA;

Subcererile pot fi executate corelat (cu sincronizare) sau ncuibrit (fr sincronizare). Subcererile fr sincronizare sunt caracterizate de faptul c se execut cererea cea mai interioar care ntoarce un rezultat ce este transmis cererii de nivel superior, care ntoarce un rezultat s.a.m.d. Subcererile cu sincronizare sunt caracterizate de faptul c evaluarea subcererii face referin la o coloan a cererii principale, iar evaluarea cererii interioare se face pentru fiecare linie a cererii (principale) care o conine. Exemplu: S se obin, utiliznd sincronizarea subcererii cu cererea principal, titlurile crilor care au toate exemplarele mprumutate (se selecteaz un titlu din carte i pentru acest titlu se numr cte exemplare sunt mprumutate). SELECT FROM WHERE titlu carte nrex=(SELECT FROM WHERE AND COUNT(*) imprumuta codel = carte.codel dataef IS NULL);

Exemplu: S se obin codurile cititorilor i codul ultimei cri mprumutate. SELECT FROM WHERE codec, codel imprumuta i dataim>=ALL (SELECT dataim FROM imprumuta WHERE codec=i.codec);

Pentru aceast interogare, clauza WHERE putea fi scris i sub forma: WHERE dataim=(SELECT MAX(dataim) FROM imprumuta WHERE codec=i.codec);

Exemplu: S se obin lista codurilor crilor mprumutate i codul primului cititor care a mprumutat aceste crti. SELECT FROM WHERE codel,codec imprumuta i dataim<=ALL (SELECT dataim FROM imprumuta WHERE i.codel=codel);

Exemplu: S se obin codurile crilor din care cel puin un exemplar este mprumutat. SELECT FROM WHERE codel carte EXISTS (SELECT FROM WHERE AND

codel imprumuta codel = carte.codel dataef IS NULL);

Operatorul WHERE EXISTS (subcerere) presupune c predicatul este adevrat dac subcererea ntoarce cel puin un tuplu, iar WHERE NOT EXISTS (subcerere) presupune c predicatul este adevrat dac subcererea nu ntoarce nici un tuplu. EXISTS i NOT EXISTS cer sincronizarea subcererii. Exemplu: S se obin titlurile crilor care sunt momentan mprumutate. Soluia 1 (cu sincronizare): SELECT titlu FROM carte WHERE EXISTS (SELECT * FROM WHERE AND Soluia 2 (fr sincronizare):

imprumuta codel = carte.codel dataef IS NULL);

SELECT FROM WHERE

titlu carte codel IN (SELECT DISTINCT codel FROM imprumuta WHERE dataef IS NULL);

Exemplu: S se obin codurile crilor care nu au fost mprumutate niciodat. Soluia 1 (cu sincronizare) SELECT codel FROM carte WHERE NOT EXISTS (SELECT FROM WHERE Soluia 2 (fr sincronizare) SELECT FROM WHERE codel carte codel NOT IN (SELECT DISTINCT codel FROM imprumuta);

codel imprumuta codel = carte.codel);

Exemplu: S se obin lista salariailor avnd salariul minim n departamentul n care lucreaz. SELECT FROM WHERE ename,sal emp e sal=(SELECT FROM WHERE

MIN(sal) emp deptno=e.deptno);

Exemplu: S se obin numele primilor trei salariai avnd retribuia maxim (ideea rezolvrii este de a verifica dac numrul salariailor care au leafa mai mare dect leafa salariatului considerat, este mai mic dect 3). SELECT FROM WHERE ename emp a 3>(SELECT COUNT(*) FROM emp

WHERE

sal > a.sal);

Exemplu: S se obin numele cititorilor care au mprumutat cel puin aceleai cri ca i cititorul avnd codul C19 (ideea problemei este de a selecta cititorii pentru care este vid lista crilor mprumutatede C19 mai puin lista crilor mprumutate de acei cititori). SELECT nume FROM cititor WHERE NOT EXISTS (SELECT codel FROM imprumuta WHERE codec=C19 MINUS SELECT codel FROM imprumuta WHERE codec= cititor.codec); Dac problema era modificat n sensul c cel puineste nlocuit prin cel mult atunci trebuiau inversate interogrile legate prin MINUS.

Exemplu: S se obin codurile cititorilor care au mprumutat aceleai cri ca i cititorul avnd un cod specificat. Rezolvarea problemei se bazeaz pe ideea: A = B A B i B A (AB) = i (B-A) = A-B i B-A nu furnizeaz nici un tuplu rezultat. SELECT codec FROM imprumuta i WHERE NOT EXISTS (SELECT codel FROM imprumuta WHERE codec=i.codec MINUS SELECT codel FROM imprumuta WHERE codec=&ccc) AND NOT EXISTS (SELECT codel FROM imprumuta WHERE codec=&ccc

AND

MINUS SELECT codel FROM imprumuta WHERE codec=i.codec) codec!=&ccc);

Ultimul operator (AND), asigur s nu apar n rezultat cititorul specificat. n cazul formei relaionale de rezolvare a cererii, drumul de acces la informaie este n sarcina SGBD-lui i prin urmare nu mai apar cereri imbricate. Exemplu: S se obin numele cititorilor care au mprumutat cel puin o carte. Soluia 1 (forma relaional): SELECT DISTINCT nume FROM cititor,imprumuta WHERE cititor.codec=imprumuta.codec; Soluia 2 (forma procedural): SELECT nume FROM cititor WHERE codec IN (SELECT DISTINCT codec FROM imprumuta); Exemplu: S se obin numele cititorilor care au mprumutat cel puin dou cri. Soluia 1 (forma relaional): SELECT nume FROM cititor, imprumuta WHERE cititor.codec=imprumuta.codec GROUP BY nume HAVING COUNT(*)>1; Soluia 2 (forma procedural): SELECT nume FROM cititor WHERE codec IN (SELECT codec FROM imprumuta GROUP BY codec HAVING COUNT(*)>1); Exemplu: S se afieze numele, prenumele, salariul lucrtorilor, codurile publicaiilor la care lucreaz i salariul mediu pe publicaie pentru toi angajaii care au salariul mai mare dect media salariului pe publicaia respectiv.

SELECT

s.nume, s.prenume, s.salariu, p.nr_publicatie, a.salariu_mediu FROM salariat s, publicatie p, (SELECT p1.nr_publicatie,AVG(salariu) salariu_mediu FROM publicatie p1, salariat s1 WHERE p1.cod_salariat = s1.cod_salariat GROUP BY p1.nr_publicatie) a WHERE p.nr_publicatie = a.nr_publicatie AND s.cod_salariat = p.cod_salariat AND s.salariu > a.salariu_mediu; Exemplu: S se obin numele salariailor care nu cunosc nici o limb strin. SELECT nume, prenume FROM salariat WHERE NOT EXISTS (SELECT * FROM limba WHERE limba.cod_salariat = salariat.cod_salariat AND limba_cun IS NOT NULL); Exemplu: S se afieze graficienii care au ntrziat s predea frame-urile. a) cu sincronizare: SELECT nume, prenume FROM salariat WHERE EXISTS (SELECT * FROM realizeaza r WHERE salariat.cod_salariat=r.cod_salariat AND data_lim < SYSDATE); b) fr sincronizare: SELECT nume, prenume FROM salariat WHERE cod_salariat IN (SELECT DISTINCT cod_salariat FROM realizeaza WHERE data_lim < SYSDATE); Exemplu:

S se determine revistele coordonate de redactori efi care nu cunosc limba n care sunt scrise. Se tie c n urma inspectrii vizuale a rezultatului interogrii se poate decide schimbarea redactorilor efi ai revistelor respective, de aceea se dorete blocarea nregistrrilor gsite. SELECT p.nr_publicatie FROM salariat s, publicatie p WHERE s.cod_salariat = p.cod_salariat AND p.limba NOT IN (SELECT limba_cun FROM limba WHERE limba.cod_salariat = s.cod_salariat) FOR UPDATE OF p.cod_salariat; Clauza WITH Cu ajutorul clauzei WITH se poate defini un bloc de cerere nainte ca acesta s fie utilizat ntr-o interogare. Clauza permite reutilizarea aceluiai bloc de cerere ntr-o instruciune SELECT complex. Utiliznd clauza WITH, s se scrie o cerere care afieaz numele artitilor i valoarea total a operelor acestora. Se vor considera artitii a cror valoare total a operelor este mai mare dect media valorilor operelor tuturor artitilor. WITH val_artist AS (SELECT nume, SUM(valoare) AS total FROM opera o, artist a WHERE o.cod_artist = a.cod_artist GROUP BY nume), val_medie AS (SELECT SUM(total)/COUNT(*) AS medie FROM val_artist) SELECT * FROM val_artist WHERE total > (SELECT medie FROM val_medie) ORDER BY nume; Subcereri scalare Subcererile scalare n SQL returneaz valoarea unei singure coloane corespunztoare unei linii. Dac subcererea returneaz 0 linii, valoarea subcererii scalare este null. Dac subcererea returneaz mai mult de o linie, server-ul genereaz o eroare. Subcererile scalare erau acceptate n Oracle8i doar n anumite cazuri, cum ar fi clauzele FROM i WHERE ale instruciunii SELECT sau clauza VALUES a instruciunii INSERT. Utilitatea subcererilor scalare a fost extins n Oracle9i.

Astfel, ele pot aprea n: condiiile i expresiile care fac parte din DECODE sau CASE; toate clauzele instruciunii SELECT, cu excepia lui GROUP BY; n partea stng a operatorului, n clauzele SET i WHERE ale instruciunii UPDATE. Exemplu: S se afieze codul, titlul operelor i numele artistului doar dac acesta este Brncui. n caz contrar, se va afia irul alt artist. SELECT cod_opera, titlu, (CASE WHEN cod_artist = (SELECT cod_artist FROM artist WHERE nume = 'Brancusi') THEN 'Brancusi' ELSE 'Alt artist' END) artist FROM opera; Operatorul ROLLUP Operatorul ROLLUP produce o mulime care conine liniile obinute n urma gruprii obinuite i linii pentru subtotaluri. Acest operator furnizeaz valori agregat i superagregat corespunztoare expresiilor din clauza GROUP BY. Operatorul ROLLUP creeaz grupri prin deplasarea ntr-o singur direcie, de la dreapta la stnga, de-a lungul listei de coloane specificate n clauza GROUP BY. Apoi, se aplic funcia agregat acestor grupri. Dac sunt specificate n expresii n operatorul ROLLUP, numrul de grupri generate va fi n + 1. Liniile care se bazeaz pe valoarea primelor n expresii se numesc linii obinuite, iar celelalte se numesc linii superagregat. Daca in clauza GROUP BY sunt specificate n coloane, atunci pentru a produce subtotaluri in n dimensiuni ar fi necesare n+1 operatii SELECT legate prin UNION ALL. Aceasta ar fi total ineficient, deoarece fiecare SELECT ar implica o parcurgere a tabelului. Operatorul ROLLUP are nevoie de o singura parcurgere a tabelului. Exemplu: S se afieze codurile de galerii mai mici dect 50, iar pentru fiecare dintre acestea i pentru fiecare autor care are opere expuse n galerie, s se listeze valoarea total a lucrrilor sale. De asemenea, se cere valoarea total a operelor expuse n fiecare galerie. Rezultatul va conine i valoarea total a operelor din galeriile avnd codul mai mic dect 50, indiferent de codul autorului.

SELECT cod_galerie, cod_artist, SUM(valoare) FROM opera WHERE cod_galerie < 50 GROUP BY ROLLUP(cod_galerie, cod_artist); Instruciunea precedent va avea un rezultat de forma: COD_GALERIE COD_ARTIST SUM(VALOARE) 10 50 14000 10 60 10000 10 24000 40 50 8080 40 8080 32080

Operatorul CUBE Operatorul CUBE grupeaz liniile selectate pe baza valorilor tuturor combinaiilor posibile ale expresiilor specificate i returneaz cte o linie totalizatoare pentru fiecare grup. El produce subtotaluri pentru toate combinaiile posibile de grupri specificate n GROUP BY, precum i un total general. Daca exista n coloane sau expresii in clauza GROUP BY, vor exista 2 n combinatii posibile superagregat. Matematic, aceste combinatii formeaza un cub n-dimensional. Pentru producerea de subtotaluri fara ajutorul operatorului CUBE ar fi necesare 2 n instructiuni SELECT legate prin UNION ALL. Exemplu: S se afieze valoarea total a operelor de art ale unui autor, expuse n cadrul fiecrei galerii avnd codul mai mic dect 50. De asemenea, s se afieze valoarea total a operelor din fiecare galerie avnd codul mai mic dect 50, valoarea total a operelor fiecrui autor indiferent de galerie i valoarea total a operelor din galeriile avnd codul mai mic dect 50. SELECT cod_galerie, cod_artist, SUM(valoare) FROM opera WHERE cod_galerie < 50 GROUP BY CUBE(cod_galerie, cod_artist); COD_GALERIE COD_ARTIST SUM(VALOARE)

10 10 10 40 40

50 60 50 50 60

14000 10000 24000 8080 8080 22080 10000 32080

Funcia GROUPING Aceasta funcie este util pentru: determinarea nivelului de agregare al unui subtotal dat, adic a grupului sau grupurilor pe care se bazeaz subtotalul respectiv; identificarea provenienei unei valori null a unei expresii calculate, dintruna din liniile mulimii rezultat. Functia returneaz valoarea 0 sau 1. Valoarea 0 poate indica fie c expresia a fost utilizat pentru calculul valorii agregat, fie c valoarea null a expresiei este o valoare null stocat. Valoarea 1 poate indica fie c expresia nu a fost utilizat pentru calculul valorii agregat, fie c valoarea null a expresiei este o valoare creat de ROLLUP sau CUBE ca rezultat al gruprii. Exemplu: SELECT cod_galerie, cod_artist, SUM(valoare), GROUPING(cod_galerie), GROUPING(cod_artist) FROM opera WHERE cod_galerie < 50 GROUP BY ROLLUP(cod_galerie, cod_artist);

COD_GALERIE COD_ARTIST 10 10 10

SUM GROUPING GROUPING (VALOARE) (COD_GALERIE) (COD_ARTIST) 50 14000 0 0 60 10000 0 0 24000 0 1

40 40

50

8080 8080 32080

0 0 1

0 1 1

Pe prima linie din acest rezultat, valoarea totalizatoare reprezint suma valorilor operelor artistului avnd codul 50, n cadrul galeriei 10. Pentru a calcula aceast valoare au fost luate n considerare coloanele cod_galerie i cod_artist. Prin urmare, expresiile GROUPING(cod_galerie) i GROUPING(cod_artist) au valoarea 0 pentru prima linie din rezultat. Pe linia a treia se afl valoarea total a operelor din galeria avnd codul 10. Aceast valoare a fost calculat lund n considerare doar coloana cod_galerie, astfel nct GROUPING (cod_galerie) i GROUPING(cod_artist) au valorile 0, respectiv 1. Pe ultima linie din rezultat se afl valoarea total a operelor din galeriile avnd codul mai mic dect 50. Nici una dintre coloanele cod_galerie i cod_artist nu au intervenit n calculul acestui total, prin urmare valorile corespunztoare expresiilor GROUPING(cod_galerie) i GROUPING(cod_artist) sunt 0. Clauza GROUPING SETS GROUPING SETS reprezint o extensie a clauzei GROUP BY care permite specificarea unor grupri multiple de date. Aceast extensie, aprut n sistemul Oracle9i, permite scrierea unei singure instruciuni SELECT pentru a specifica grupri diferite (care pot conine operatorii ROLLUP i CUBE), n loc de mai multe instruciuni SELECT combinate prin operatorul UNION ALL. De altfel, reuniunea rezultatelor mai multor cereri este ineficient ntruct necesit mai multe parcurgeri ale acelorai date. Operatorii ROLLUP i CUBE pot fi considerai cazuri particulare de mulimi de grupri. Au loc urmtoarele echivalene: CUBE(a, b, c) GROUPING SETS ((a, b, c), (a, b), (a, c), (b, c), (a), (b), (c), ()) ROLLUP(a, b, GROUPING SETS c) ((a, b, c), (a, b), (a), ()) Exemplu: Considernd galeriile al cror cod este mai mic dect 50, s se calculeze

media valorilor operelor: pentru fiecare galerie i, n cadrul acesteia, pentru fiecare artist; pentru fiecare artist i, n cadrul acestuia, pentru anii de achiziie corespunztori. SELECT cod_galerie, cod_artist, TO_CHAR(data_achizitiei, 'yyyy') "an achizitie", AVG(valoare) "Valoare medie" FROM opera WHERE cod_galerie < 50 GROUP BY GROUPING SETS ((cod_galerie, cod_artist), (cod_artist, TO_CHAR(data_achizitiei, 'yyyy'))); Mulimea rezultat este constituit din valorile medii pentru fiecare dintre cele dou grupuri ((cod_galerie, cod_artist) si (cod_artist, an_achizitie)) i are forma urmtoare: COD_GALERIE COD_ARTIST 10 50 10 60 40 50 50 50 60 60 An achizitie Valoare medie 3500 2500 2020 2380 2300 2000 3000

2000 2002 2001 2003

Exemplul precedent poate fi rezolvat i prin urmtoarea instruciune compus: SELECT cod_galerie, cod_artist, NULL "An achizitie", AVG(valoare) "Valoare medie" FROM opera GROUP BY cod_galerie, cod_artist UNION ALL SELECT NULL, cod_artist, TO_CHAR(data_achizitiei, 'yyyy'), AVG(valoare) FROM opera GROUP BY cod_artist, TO_CHAR(data_achizitiei, 'yyyy'); n absena unui optimizor care analizeaz blocurile de cerere i genereaz planul de execuie, cererea precedent va parcurge de dou ori tabelul de baz

(opera), ceea ce poate fi ineficient. Din acest motiv, este recomandat utilizarea extensiei GROUPING SETS.

Limbajul de manipulare a datelor DML

n aceast curs se prezint instruciunile DML (Data Manipulation Language), o parte a limbajului SQL folosit pentru intreinerea datelor stocate n tabele relaionale ale bazei de date. Limbajul DML este format din trei comenzi SQL: INSERT UPDATE DELETE Adaug noi rnduri ntr-un table al bazei de date. Actualizeaza rndurile existente intr-un table al bazei de date. Sterge rnduri dintr-un tabel al bazei de date

Instruciunile DML individuale afecteaz datele dintr-un singur tabel. Este posibil ca ntr-o instruciune DML s referii i o vizualizare care conine date din mai multe tabele (adic o vizualizare care conine o uniune de tabele), dar, n acest caz, instruciunea DML poate referi numai coloane dintr-un singur tabel al vizualizrii. Cu alte cuvinte, atunci cand o instruciune DML folosete o vizualizare, toate coloanele vizualizrii referite n instruciunea DML trebuie s corespund unor coloane dintr-un singur tabel fizic al bazei de date. Sistemul SGBD nu va efectua n baza de date nici o modificare care ncalc una din restricii. La formarea instructiunilor DML, trebuie s se in seama de urmatoarele aspecte referitoare la restriciile tabelului modificat: Restricii de tip cheie primar Atunci cnd inserai un nou rnd ntr-un tabel, cheia primar a noului rnd trebuie sa fie unic n ntregul tabel.Cand modificati valoarea unei chei primare (ceea ce se intampla rareori), noua valoare trebuie s fie unic n ntregul tabel. Restricii de unicitate Ca i n cazul cheilor primare, coloanele pe care a fost definit o restricie de unicitate trebuie sa aib valori unice n ntregul tabel. Restricii NOT NULL O valoare nula (null) este o modalitate special prin care sistemul SGBD trateaz valoarea unei coloane pentru a indica faptul ca valoarea coloanei respective nu este cunoscut. O valoare nula nu este acelasi lucru un un spatiu

liber, un sir vid sau valoarea zero este o valoare speciala care nu este egala cu nimic altceva. n cazul instruciunilor INSERT, trebuie specificate valori pentru toate coloanele cu restricii NOT NULL. n cazul instruciunilor UPDATE nu se pot inlocui valorile unei coloane cu valori nule dac pe coloana respectiv este definit p restricie NOT NULL. Dac instruciunea DML refer o vizualizare , nu se poate sa o folosim intro instruciune INSERT dac una dintre coloanele tabelului cu o restricie NOT NULL(obligatorii) lipsete din definirea vizualizrii. Restricii refereniale Nu se poate insera sau actualiza valoarea unei chei externe dect dac exist deja rndul printe corespondent care conine valoarea cheii n coloana cheii primare. In sens invers, nu se poate terge un rnd printe dac exist rnduri subordonate care refer valoarea din rndul printe, dect dac restricia a fost definit cu opiunea ON DELETE CASCADE. In general inserrile n tabele trebuie fcute ierarhic (mai intai randurile parinte, apoi randurile copii), iar tergerile trebuie fcute n ordine invers (copiii inaintea prinilor). Restrictii de verificare (CHECK) O instructiune INSERT sau UPDATE nu poate stoca ntr-o coloana o valoare care ncalc o restricie CHECK definit pentru coloana respectiv.

Instruciunea INSERT
Instruciunea INSERT este folosit pentru inserarea noilor rnduri de date n tabele sau tabele de baz al unei vizualizri. Instruciunea are dou forme de baz: una n care valorile coloanelor sunt specificate chiar n instruciune i alta n care valorile sunt selectate dintr-un tabel sau o vizualizare, folosind o subinterogare. Inserarea unui singur rand de date folosind clauza Values Instruciunea INSERT care folosete o clauz VALUES poate crea un singur rnd la fiecare rulare, deoarece valorile pentru rndul de date respective sunt specificate chiar n instruciune.

Sintaxa general a instruciunii este urmtoarea: INSERT INTO nume_tabel_sau_vizualizare [(lista_de_coloane)] VALUES (lista_de_valori); Sau INSERT INTO nume_tabel / nume_view [(col1[, col2[,]])] VALUES (expresia1[, expresia2[,]]) / subcerere; expresia1, expresia2, reprezint expresii a cror evaluare este atribuit coloanelor precizate (se insereaz o linie); subcerere, reprezint o interogare (se insereaz una sau mai multe linii).

Clauza VALUES specific valorile ce vor fi introduse n tabel sau vizualizare. Pentru a insera mai multe linii prin aceeai instruciune INSERT, n locul acestei clauze se va preciza o subcerere. Exemple pentru baza de date FILM Diagrama ERD a bazei de date FILM(prezentare parial)

FILM
FILM_ID <pk> MPAA_RATING MPAA_COD_RATING <pk>
MPAA_DESCRIERE_RATING

FILM_COD_GEN <fk1> MPAA_COD_RATING <fk2> FILM_NUME RETAIL_PRET_VHS RETAIL_PRET_DVD AN_PRODUS

FILM_GEN FILM_COD_GEN <pk> FILM_DESCRIERE_GEN

FILM_COPII FILM_ID <pk, fk>> NUMAR_COPIE <pk> DATA_CUMPARARE DATA_VANZARE FORMAT_MEDIA

Se poate remarc urmtoarele: Lista de coloane este opional, dar dac este inclus trebuie s fie ncadrat n paranteze rotunde. Dac lista de coloane este omis, trebuie specificat o valoare pentru fiecare coloan din tabel, n ordinea n care sunt definite coloanele n tabel. Este bine ca ntotdeauna s includei lista de coloane, deoarece omiterea acesteia face ca instruciunea INSERT s fie dependent de definiia tabelului. Dac o coloan este modificat sau n tabel este adugat o nou coloan, chiar i opional, probabil instruciunea INSERT va eua la urmtoarea rulare. Dac lista de coloane este specificat, lista de valori trebuie s conin o valoare pentru fiecare coloan din list, n aceeai ordine. Cu alte cuvinte, ntre lista de coloane i lista de valori trbuie s existe o corespondena unu-la-unu. Orice coloana care lipsete din list va primi o valoare nul, presupunund c valorile nule sunt acceptate n coloana respectiv. n clauza VALUES, valorile de tip caracter i dat calendaristic trebuie incluse ntre apostrofuri. Nu se recomand includerea ntre apostrofuri a valorilor numerice, ntruct aceasta ar determina conversii implicite la tipul NUMBER. Pentru introducerea de valori speciale n tabel, pot fi utilizate funcii. Adugarea unei linii care va conine valori null se poate realiza n mod: - implicit, prin omiterea numelui coloanei din lista de coloane; - explicit, prin specificarea n lista de valori a cuvntului cheie null sau a irului vid n cazul irurilor de caractere sau datelor calendaristice. Exemplul urmtor conine dou instruciuni INSERT, una care creeaz un nou rnd n tabelul FILM, cu o list opional de coloane, din care este omis coloana RETAIL_PRET_VHS, i alta care creeaz un rnd n tabelul FILM_COPII pentru acelai tip, dar fr lista opional de coloane. INSERT INTO FILM (FILM_ID, FILM_COD_GEN, MPAA_RATING_COD, FILM_NUME, PRET_INCHIRIAT_DVD, AN_PRODUCERE) VALUES (21,Drama,PG-13,Ray, 29.95, 2004); INSERT INTO FILM_COPII VALUES (21, 1, 2005-04-01, NULL, V);

Exemplu baza galeria de arta

1 inclusa_in M(1)

GALERIE cod_galerie#

SALA cod_sala# cod_galerie#

1 cuprinsa_in

M(1)

SECURITATE cod_opera# sistem#

1 protejata_prin M(0)

ARTIST cod_artist#

creata_de

M(1)

OPERA cod_opera#
M(1)

asigurata_de

M(0)

M(1) M(1) studiaza mentionata_in

POLITA_ASIG cod_polita#

M(0) M(0)

SURSA_BIBLIO cod_sursa# tip

SPECIALIST cod_specialist#

ARTICOL

figureaza_in

CARTE

M(0)

M(1) editata_de

EXPOZITIE cod_expo#

M(1)

organizata_de

M(1)

ORGANIZATOR cod_organizator#

M(1)

AUTOR cod_autor#

S se adauge prin metoda explicit, respectiv prin metoda implicit, dou nregistrri n tabelul artist, preciznd numai codul, numele i prenumele artistului. ARTIST(cod_artist#, nume, prenume, an_nastere, an_moarte, nationalitate, observatii); INSERT INTO artist (cod_artist, nume, prenume) VALUES (50, 'Grigorescu', 'Nicolae'); INSERT INTO artist VALUES (70, 'Andreescu', 'Ion', NULL, NULL, NULL, NULL); n galeria creat anterior i care a fost achiziionat la 20 ianuarie 2009. Exemplu: Urmtoarea instruciune va genera eroarea ORA-01400: cannot insert NULL into , ntruct se ncearc inserarea unei linii n tabelul opera fr a preciza valoarea cheii primare. INSERT INTO opera (titlu, data_achizitiei) VALUES ('Flori de camp', SYSDATE); Exemplu BD CARTE S se insereze n tabelul carte toate crile din tabelul carte_info, presupunnd c tabelul carte_info a fost deja creat. De asemenea, s se introduc o nou carte creia i se cunoate codul (c34), titlul (algebra) i preul (500). INSERT INTO carte (codel, titlu, autor, nrex, pret, coded) VALUES (c34,algebra, null, null, 50, null); Exemplu: INSERT INTO carte (codel, nrex) VALUES ('c25', 25);

inserare prin parametrizare INSERT INTO domeniu VALUES ('&cod', '&dendom'); inserare prin parametrizare Inserri masive folosind instruciunea SELECT intern Aa cum se observ, este nevoie de foarte mult cod pentru a insera n tabel un singur rnd de date folosind o instruciune INSERT cu clauza VALUES. O alt soluie, care poate fi folosit pentru a insera rnduri multiple ntr-un tabel , este forma care folosete o instruciune SELECT intern. Aceast form este util i pentru stabilirea urmtoarei valori disponibile pentru o cheie primar cu valori secveniale. De asemenea , poate fi folosit atunci cnd creai un tabel temporar pentru testare i vrei s-l populai cu toate datele dintr-un alt tabel. Sintaxa general a instruciunii este INSERT INTO nume_tabel_sau_vizualizare [(lista_de_coloane)] SELECT instructiune_select; Se remarc urmtoarele: Lista de coloane este opional, dar dac este inclus trebuie s fie ncadrat n paranteze. Dac lista de coloane este omis, instruciune SELECT intern trebuie s furnizeze o valoare pentru fiecare coloan din tabel, n ordinea n care sunt definite coloanele n tabel. Este bine ca ntotdeauna s includei lista de coloane, deoarece omiterea acesteia face ca instruciunea INSERT s fie dependent de definiia tabelului. Dac o coloan este modificat sau n tabel este adugat o nou coloan, chiar i opional, probabil instruciunea INSERT va eua la urmtoarea rulare. Dac lista de coloane este specificat, instruciune SELECT intern s furnizeze o valoare pentru fiecare coloan din lista de valori, n aceeai ordine. Cu alte cuvinte, ntre lista de coloane i setul de rezultate al instruciunii SELECT trebuie s existe o corespondena unu-la-unu. Orice coloan care lipsete din list va primi o valoare nul, presupunund c valorile nule sunt acceptate n coloana respectiv. Cuvntul cheie NULL poate fi folosit n instruciunea SELECT pentru specificarea unei valori nule pentru o coloan.

Ca exemplu, s presupunem c toate filmele sunt acum disponibile i n limba francez. Tabelul FILM_LIMBA conine rnduri pentru limba francez pentru o parte din filme, aa c acum vrem s le adugm numai pe cele care lipsesc. Instruciunea INSERT care va rezolva aceast problem este: INSERT INTO FILM_LIMBA (FILM_ID, COD_LIMBA) SELECT FILM_ID, fr FROM FILM WHERE FILM_ID NOT IN ( SELECT FILM_ID FROM FILM_LIMBA WHERE COD_LIMBA =fr );

INSERT INTO carte SELECT * FROM carte_info; Exemplu: Presupunnd c tabelul salariat a fost completat cu datele tuturor salariailor editurii, s se completeze tabelele grafician, tehnoredactor i redactor_sef, n concordan cu datele coninute n tabelul salariat (nu pot exista graficieni, tehnoredactori sau redactori efi care s nu fie salariai!). INSERT INTO grafician (cod_salariat) SELECT cod_salariat FROM salariat WHERE job = grafician; INSERT SELECT FROM WHERE INSERT SELECT FROM WHERE INTO tehnoredactor (cod_salariat) cod_salariat salariat job = tehnoredactor; INTO redactor_sef (cod_salariat) cod_salariat salariat job = redactor_sef;

NU Inserri multitabel O inserare multitabel presupune introducerea de linii calculate pe baza rezultatelor unei subcereri, n unul sau mai multe tabele. Acest tip de inserare, introdus de Oracle9i, este util n mediul data warehouse. Astfel, datele extrase dintr-un sistem surs, pot fi transformate utiliznd instruciuni INSERT multitabel, spre a fi ncrcate n obiectele bazei de date. Pentru o astfel de inserare, n versiunile anterioare lui Oracle9i erau necesare n operaii independente INSERT INTOSELECT, unde n reprezint numrul tabelelor destinaie. Aceasta presupunea n procesri ale aceleiai surse de date i, prin urmare, creterea de n ori a timpului necesar procesului. Sintaxa clauzei inserare_multi_tabel este urmtoarea: {ALL INTO[VALUES] [INTO[VALUES] ] | inserare_condiionat} subcerere Clauza inserare_condiionat are forma urmtoare: [ALL | FIRST] WHEN condiie THEN INTO[VALUES] [INTO[VALUES] ] [WHEN condiie THEN INTO[VALUES] [INTO[VALUES] ] ] [ELSE INTO[VALUES] [INTO[VALUES] ] ] Pentru a efectua o inserare multitabel necondiionat, sistemul va executa cte o instruciune INSERTINTO pentru fiecare linie returnat de subcerere. Utiliznd clauza inserare_condiionat, decizia inserrii unei linii depinde de condiia specificat prin intermediul opiunii WHEN. Expresiile prezente n aceste condiii trebuie s fac referin la coloane returnate de subcerere. O instruciune de inserare multitabel poate conine maxim 127 clauze WHEN. Specificarea opiunii ALL determin evaluarea tuturor condiiilor din clauzele WHEN. Pentru cele a cror valoare este TRUE, se insereaz nregistrarea specificat n opiunea INTO corespunztoare. Opiunea FIRST determin inserarea corespunztoare primei clauze WHEN a crei condiie este evaluat TRUE. Toate celelalte clauze WHEN sunt ignorate. Dac nici o condiie din clauzele WHEN nu este TRUE, atunci sistemul execut clauza INTO corespunztoare opiunii ELSE, iar dac aceasta nu exist, nu efectueaz nici o aciune. Inserrile multitabel pot fi efectuate numai asupra tabelelor, nu i asupra vizualizrilor sau vizualizrilor materializate. De asemenea, acest tip de inserare nu se poate efectua asupra tabelelor distante. Subcererea dintr-o instruciune

corespunztoare unei inserri multitabel nu poate utiliza o secven. Exemplu: Se presupune c licitaiile pentru achiziionarea operelor de art au loc numai n zilele de miercuri. Fie tabelul opera_intrare (data_inceput, sapt_1, sapt_2, sapt_3, sapt_4), n care data_inceput reprezint data primei zile de miercuri din lun, iar sapt_i furnizeaz valoarea operelor achiziionate n sptmna respectiv. Considernd c n fiecare sptmn se achiziioneaz o singur lucrare, s se insereze liniile corespunztoare n tabelul opera. INSERT ALL INTO opera (cod_opera, valoare, data_achizitiei) VALUES (secv_cod_opera.NEXT_VALUE, sapt_1, data_inceput) INTO opera (cod_opera, valoare, data_achizitiei) VALUES (secv_cod_opera.NEXT_VALUE, sapt_2, data_inceput + 7) INTO opera (cod_opera, valoare, data_achizitiei) VALUES (secv_cod_opera.NEXT_VALUE, sapt_3, data_inceput + 14) INTO opera (cod_opera, valoare, data_achizitiei) VALUES (secv_cod_opera.NEXT_VALUE, sapt_4, data_inceput + 21) SELECT data_inceput, sapt_1, sapt_2, sapt_3, sapt_4 FROM opera_intrare; Exemplu: Se consider trei tabele care conin informaii referitoare la galerii, n funcie de numrul operelor gzduite de ctre acestea. Tabelele se numesc galerie_mica, galerie_medie, galerie_mare dup cum numrul de opere este mai mic dect 30, cuprins ntre 31 i 100, respectiv mai mare dect 101. Se presupune c structura fiecruia dintre tabele este alctuit din coloanele cod_galerie, nume, numr_opere. S se insereze nregistrri n aceste tabele. INSERT ALL WHEN nr_opere <= 30 THEN INTO galerie_mica WHEN nr_opere > 30 AND nr_opere <= 100 THEN INTO galerie_medie WHEN nr_opere > 100 THEN INTO galerie_mare SELECT g.cod_galerie, nume_galerie, nr_opere FROM galerie g, (SELECT cod_galerie, count(*) nr_opere FROM opera

GROUP BY cod_galerie) x WHERE g.cod_galerie = x.cod_galerie; Acelai rezultat se obine prin utilizarea clauzei ELSE, astfel: INSERT ALL WHEN nr_opere <= 30 THEN INTO galerie_mica WHEN nr_opere > 30 AND nr_opere <= 100 THEN INTO galerie_medie ELSE INTO galerie_mare SELECT g.cod_galerie, nume_galerie, nr_opere FROM galerie g, (SELECT cod_galerie, count(*) nr_opere FROM opera GROUP BY cod_galerie) x WHERE g.cod_galerie = x.cod_galerie; Exemplu: Se consider un tabel, galerie_g, avnd aceeai structur ca i cele din exemplul precedent. n acesta vor fi reinute galeriile al cror nume ncepe cu litera G. Se presupune c, dac o galerie se ncadreaz n acest tabel, ea nu mai trebuie s apar i n cele referitoare la numrul de opere gzduite. S se insereze nregistrri n tabelele galerie_g, galerie_mica, galerie_medie, galerie_mare. INSERT FIRST WHEN UPPER(nume_galerie) LIKE 'G%' THEN INTO galerie_g WHEN nr_opere <= 30 THEN INTO galerie_mica WHEN nr_opere > 30 AND nr_opere <= 100 THEN INTO galerie_medie WHEN nr_opere > 100 THEN INTO galerie_mare SELECT g.cod_galerie, nume_galerie, nr_opere FROM galerie g, (SELECT cod_galerie, count(*) nr_opere FROM opera GROUP BY cod_galerie) x WHERE g.cod_galerie = x.cod_galerie;

Comanda UPDATE
Instruciunea UPDATE este folosit pentru actualizarea datelor din coloanele unui tabel (sau ale unei vizualizri). Valorile cmpurilor care trebuie modificate pot fi furnizate explicit sau pot fi obinute n urma unei cereri SQL. Sintaxa general a instruciunii UPDATE: UPDATE nume_tabel_sau_vizualizare SET nume_coloana = expresie [,nume_coloana = expresie...] [ WHERE conditie];

Sau mai general, expresia poate fi o cerere

UPDATE nume_tabel_sau_vizualizare SET (column1[,column2[,]]) = (subquery) / column = expr / (query) [WHERE condition] Observaii: Pentru a se putea executa instruciunea UPDATE, utilizatorul care o lanseaz n execuie trebuie s aib acest privilegiu. Dac nu este specificat clauza WHERE se vor modifica toate liniile. Cererea trebuie s furnizeze un numr de valori corespunztor numrului de coloane din paranteza care precede caracterul de egalitate. Se remarc urmtoarele: Clauza SET conine o list cu una sau mai multe coloane, mpreun cu o expresie care specific noua valoare pentru fiecare coloan. Aceasta este o list de perechi nume-valoare, separate prin virgule, cu un operator de egalitate ntre fiecare nume i valoare.

Expresia poate fi o constant, un alt nume de coloan sau orice alt expresie pe care SQL o poate transforma ntr-o singur valoare, care poate fi apoi atribuit coloanei respective. Clauza WHERE conine o expresie care limiteaz rndurile actualizate. Dac aceast clauz este omis, motorul SQL va ncerca s actualizeze toate rndurile din tabel sau din vizualizare. Exemple: Un film a fost adugat cu un pre incorect. Instruciunea urmtoare va actualiza dou coloane din acelaI rnd a tabelului MOVIE. UPDATE FILM SET RETAIL_PRET_VHS = 29.95 , RETAIL_PRET_DVD = 34.95 WHERE FILM_ID = 21 Conducerea firmei de produse video a decis s creasc salariul tuturor funcionarilor cu 10 procente. Aceast instruciune va actualiza o singur coloan de pe mai multe rnduri, rotujind rezultatul la 2 zecimale cu funcia ROUND. UPDATE ANGAJAT SET ANGAJAT_PLATA_ORA = ROUND (ANGAJAT_PLATA_ORA * 1.1, 2) WHERE ANGAJAT_JOB_CATEGORY =C ;

Exemple BD CARTE Preul crilor scrise de Lucian Blaga s fie modificat, astfel nct s fie egal cu preul celei mai scumpe cri de informatic din bibliotec. UPDATE carte SET pret = (SELECT MAX(pret) FROM carte WHERE coded = I) WHERE autor = Lucian Blaga;

Exemplu: S se modifice preul crilor din bibliotec, care se gsesc ntr-un numr de exemplare mai mic dect media numrului de exemplare pe bibliotec. Noua valoare a preului s fie egal cu suma preurilor crilor scrise de Zola. UPDATE carte SET pret = (SELECT SUM(pret) FROM carte WHERE autor = Zola) WHERE nrex < (SELECT AVG(nrex) FROM carte); Exemplu: S se reduc cu 10% salariile redactorilor efi care nu sunt asociai nici unei publicaii. UPDATE salariat SET salariu = 0,9*salariu WHERE cod_salariat IN (SELECT cod_salariat FROM redactor_sef WHERE cod_salariat NOT IN (SELECT cod_salariat FROM publicatie)); Exemplu: S se mreasc cu 5% salariile redactorilor efi ce coordoneaza publicaiile care au cel mai mare numr de frame-uri. UPDATE salariat SET salariu = 1,05*salariu WHERE cod_salariat IN (SELECT cod_salariat FROM publicatie WHERE nr_publicatie IN (SELECT nr_publicatie FROM frame GROUP BY nr_publicatie HAVING COUNT(*) > ALL (SELECT COUNT(*) FROM frame GROUP BY nr_publicatie)));

** Oracle9i permite utilizarea valorii implicite DEFAULT in comenzile INSERT si UPDATE. Unei coloane i se atribuie valoarea implicit definit la crearea sau modificarea structurii tabelului dac nu se precizeaz nici o valoare sau dac se precizeaz cuvntul cheie DEFAULT n comenzile INSERT sau UPDATE. Dac nu este definit nici o valoare implicit pentru coloana respectiv, sistemul i atribuie valoarea null. Exemplu: UPDATE carte SET pret = DEFAULT WHERE codel = 77; Exemplu BD GALERIE ARTA a) S se transfere n galeria 10 opera avnd codul 110. UPDATE opera SET cod_galerie = 10 WHERE cod_opera = 110; b) S se modifice informaiile referitoare la opera avnd codul 120, considernd c se afl expus n aceeai galerie i a fost achiziionat la aceeai dat ca i opera al crei cod este 110. UPDATE opera SET (cod_galerie, data_achizitiei) = (SELECT cod_galerie, data_achizitiei FROM opera WHERE cod_opera = 110) WHERE cod_opera = 120; c) S se modifice copie_opera pe baza valorilor din tabelul opera. Se consider c operele care au acelai autor ca i opera avnd codul 100 sunt expuse n galeria ce conine lucrarea al crei cod este 110. UPDATE copie_opera SET cod_galerie = (SELECT cod_galerie FROM opera WHERE cod_opera = 110) WHERE cod_autor = (SELECT cod_autor FROM opera

WHERE cod_opera = 100); Cazurile n care instruciunea UPDATE nu poate fi executat sunt similare celor n care eueaz instruciunea INSERT. Acestea au fost menionate anterior. Exemplu: UPDATE opera SET cod_galerie = 47 WHERE cod_galerie = 40; Deoarece galeria avnd codul 47 nu exist n tabelul printe (galerie), instruciunea precedent va genera eroarea ORA-02291: integrity constraint (STUDENT.SYS_C002773) violated - parent key not found. Exemplu: S se transfere n galeria avnd codul 50 toate operele din galeria 60, care sunt create de Nicolae Grigorescu. S se mreasc cu 10% valoarea acestor opere. UPDATE opera o SET cod_galerie = 50, valoare = valoare * 1.10 WHERE (SELECT INITCAP(nume) ||' '||INITCAP(prenume) FROM artist WHERE cod_artist = o.cod_artist)= 'Nicolae Grigorescu' AND o.cod_galerie = 60; Exemplu: S se actualizeze operele al cror autor este tefan Luchian astfel: codul galeriei devine codul galeriei n care este expus cea mai scump oper a artistului, valoarea fiecrei opere va fi mrit cu 10% din media valorilor operelor din galerie, iar data achiziiei va fi considerat data celei mai recente achiziii din galerie. UPDATE opera o SET cod_galerie = (SELECT cod_galerie FROM artist a, opera b WHERE a.cod_artist = b.cod_artist AND INITCAP(nume) = 'Luchian ' AND INITCAP(prenume) = 'Stefan' AND valoare = (SELECT MAX(valoare)

FROM opera WHERE cod_artist = b.cod_artist)), (valoare, data_achizitiei) = (SELECT o.valoare + AVG(o2.valoare)*0.10, MAX(o2.data_achizitiei) FROM opera o2 WHERE o.cod_opera = o2.cod_opera) WHERE cod_artist = (SELECT cod_artist FROM artist WHERE INITCAP(nume) = 'Luchian ' AND INITCAP(prenume) = 'Stefan'); Oracle9i introduce o nou funcionalitate, reprezentat de posibilitatea utilizrii valorilor implicite (DEFAULT) n instruciunile INSERT i UPDATE. Unei coloane i se atribuie valoarea implicit definit la crearea sau modificarea structurii tabelului dac: nu se precizeaz nici o valoare; se precizeaz cuvntul cheie DEFAULT n comenzile INSERT sau UPDATE. Dac nu a fost definit nici o valoare implicit pentru coloana respectiv, sistemul i atribuie valoarea null. Cuvntul cheie DEFAULT nu poate fi specificat la actualizarea vizualizrilor. Exemplu: S se creeze tabelul test, avnd o coloan creia i se specific o valoare implicit. Ulterior, s se modifice aceast valoare. S se insereze i s se actualizeze cte o nregistrare din tabel, utiliznd valoarea implicit. CREATE TABLE test( cod NUMBER PRIMARY KEY, nume VARCHAR2(30) DEFAULT 'NECUNOSCUT'); ALTER TABLE test MODIFY (nume DEFAULT 'NEDEFINIT'); INSERT INTO test VALUES (1, DEFAULT); UPDATE test SET nume = DEFAULT WHERE cod = 2;

Comanda (Instruciunea) DELETE

Instruciunea DELETE terge unul sau mai multe rnduri dintr-un tabel. Instruciunea poate s foloseasc i o vzualizare, dar numai dac aceasta se bazeaz pe un singur tabel (ceea ce nseamn c instruciunile DELETE nu pot fi folosite pentru vizualizri care conin uniuni). n instruciunile DELETE nu sunt referite niciodat coloane, doarece instruciunea terge rnduri ntregi de date, inclusiv toate valorile datelor (toate coloanele) din rndurile afectate. Dac vrei s tergei o singur valoare din rndurile existente, folosii instruciunea UPDATE pentru a nlocui valorile respective cu valori nule (presupunnd c valorile nule sunt permise n acele coloane). Sintaxa general a instruciunii DELETE este DELETE FROM nume_tabel_sau_vizualizare [AS alias] [ WHERE conditie ]; Se remarc urmtoarele: Comanda DELETE nu terge structura tabelului. Clauza WHERE este opional. Totui, este folosit aproape ntotdeauna, deoarece o instruciune DELETE fr o clauz WHERE ncearc s tearg toate rndurile din tabel. n clauza WHERE pot fi folosite i subcereri. Atunci cnd este inclus, clauza WHERE specific rndurile care urmeaz s fie terse. Orice rnd pentru care condiia WHERE este evaluat ca adevrat este ters din tabel. Nu se pot terge rnduri dac se ncalc o restricie referenial. n general, rndurile subordonate trebuie terse naintea rndurilor printe. Pentru a terge linii identificate cu ajutorul valorilor din alte tabele, se utilizeaz subcereri. Comanda nu poate fi folosit pentru tergerea valorilor unui cmp individual. Acest lucru se poate realiza cu ajutorul comenzii UPDATE. Exemple BD MOVIE S se tearg filmul adugat mai devreme (cu FILM_ID = 21 ). Se observ c trebuie s se terg mai nti rndurile corespondente din

tabelele FILM_COPY i FILM_LIMBA, deoarece acestea sunt rnduri copii ale rndului din tabelul FILM DELETE FROM FILM_COPY WHERE FILM_ID = 21; DELETE FROM FILM_LIMBA WHERE FILM_ID = 21; DELETE FROM FILM WHERE FILM_ID = 21; S se tearg din tabelul FILM_LIMBA toate rndurile pentru limba spaniol (COD_LIMBA='es' ). n multe implementri SQL se face diferenierea literelor mari de cele mici, caz n care valoarea codului de limb trebuie specificat cu litere mici pentru a se potrivi cu datele din tabel. DELETE FROM FILM_LIMBA WHERE COD_LIMBA =es; Exemplu: S se elimine cititorii care au numele Popai cei care au restituit astzi cel puin o carte. DELETE FROM cititor WHERE nume=Popa OR codec IN (SELECT codec FROM imprumuta WHERE data_ef=SYSDATE); Exemplu: S se elimine redactorii efi care nu au coordonat nici o publicaie. DELETE FROM redactor_sef WHERE cod_salariat NOT IN (SELECT DISTINCT cod_salariat FROM publicatie);

Exemplu: S se tearg salariul angajatului avnd codul 1279. UPDATE salariat SET salariu=null WHERE cod_salariat = 1279; Exemplu: Urmatoarele doua comenzi sunt echivalente. DELETE FROM opera WHERE cod_opera = 777; DELETE FROM (SELECT * FROM opera) WHERE cod_opera = 777; Exemplu: S se tearg cartea cea mai scump DELETE FROM carte WHERE pret = (SELECT MAX(pret) FROM carte); Exemplu: Pentru fiecare autor care are mai mult de 10 creaii expuse n muzeu, s se tearg ultima oper creat de acesta. DELETE FROM opera o1 WHERE cod_artist = (SELECT cod_artist FROM opera o2 WHERE cod_artist = o1.cod_artist AND data_crearii = (SELECT MAX(data_crearii) FROM opera WHERE cod_artist = o2.cod_artist) AND 10 < (SELECT COUNT(*) FROM opera WHERE cod_artist = o2.cod_artist));

Exemple BD GALERIE de ARTA a) S se suprime nregistrarea corespunztoare operei avnd codul 120.

DELETE FROM opera WHERE cod_opera = 120; Urmtoarea instruciune are acelai efect, dar utilizeaz o subcerere: DELETE FROM (SELECT * FROM opera) WHERE cod_opera = 120; b) S se tearg ntregul coninut al tabelului copie_opera. (nu se foloseste caluza where) DELETE FROM copie_opera;

c) S se tearg toate operele care se afl expuse ntr-o galerie al crei nume conine irul de caractere muzeu. DELETE FROM opera WHERE cod_galerie = (SELECT cod_galerie FROM galerie WHERE UPPER(nume_galerie) LIKE '%MUZEU%'); Dac se ncearc tergerea unei nregistrri care conine o valoare implicat ntr-o constrngere de integritate, atunci va fi returnat o eroare. Exemplu: DELETE FROM galerie WHERE cod_galerie = 40; n urma execuiei acestei instruciuni sistemul genereaz eroarea ORA02292: integrity constraint (STUDENT.SYS_C002773) violated - child record found, datorat calitii de cheie extern a coloanei cod_galerie n tabelul opera. Exist opere n galeria avnd codul 40 i de aceea aceasta nu poate fi suprimat. n cazul n care constrngerea de integritate referenial a fost definit utiliznd opiunea ON DELETE CASCADE, atunci instruciunea DELETE va terge att liniile indicate, ct i liniile copil din tabelele corespunztoare.

LIMBAJUL PENTRU CONTROLUL DATELOR Controlul unei baze de date cu ajutorul SQL-ului se refera la: asigurarea confidentialitatii si securitatii datelor; organizarea fizica a datelor; realizarea unor performante; reluarea unor actiuni in cazul unei defectiuni; garantarea coerentei datelor in cazul prelucrarii concurente. Sistemul de gestiune trebuie: s pun la dispoziia unui numr mare de utilizatori o mulime coerent de date; s garanteze coerena datelor n cazul manipulrii simultane de ctre diferii utilizatori. Coerena este asigurat cu ajutorul conceptului de tranzacie. Tranzacia este unitatea logic de lucru constnd din una sau mai multe instruciuni SQL, care trebuie s fie executate atomic (ori se execut toate, ori nu se execut nici una!), asigurnd astfel trecerea BD dintr-o stare coerent n alt stare coerent. Dac toate operaiile ce constituie tranzacia sunt executate i devin efective, spunem c tranzacia este validat, iar modificrile aduse de tranzacie devin definitive. Dac dintr-un motiv sau altul (neverificarea condiiilor, accesul imposibil) o operaie a tranzaciei nu a fost executat spunem c tranzacia a fost anulat. Modificrile aduse de toate operaiile tranzaciei anulate sunt i ele anulate i se revine la starea bazei de date de dinaintea tranzaciei anulate. Este posibil ca o tranzacie s fie descompus n subtranzacii, astfel nct dac este necesar s se anuleze doar parial unele operaii. Fiecare tranzacie se poate termina: normal (commit); anormal (rollback). Controlul tranzaciilor const n: definirea nceputului i sfritului unei tranzacii, validarea sau anularea acesteia, eventual descompunere n subtranzacii. Limbajul pentru controlul datelor (LCD) permite salvarea informaiei, realizarea fizic a modificrilor n baza de date, rezolvarea unor probleme de concuren.

Limbajul conine urmtoarele instruciuni: COMMIT - folosit pentru permanentizarea modificrilor executate asupra BD (modificrile sunt nregistrate i sunt vizibile tuturor utilizatorilor); ROLLBACK - folosit pentru refacerea strii anterioare a BD (sunt anulate toate reactualizrile efectuate de la nceputul tranzaciei); SAVEPOINT - folosit n conjuncie cu instruciunea ROLLBACK, pentru definirea unor puncte de salvare n fluxul programului. O tranzacie const: dintr-o singur instruciune LDD; dintr-o singur instruciune LCD; din instruciuni LMD care fac schimbri consistente n date. Tranzacia ncepe: dup o comand COMMIT, dup o comand ROLLBACK, dup conectarea iniial la Oracle, cnd este executat prima instruciune SQL. Tranzacia se termin: dac sistemul cade; dac utilizatorul se deconecteaz; dac se dau comenzile COMMIT sau ROLLBACK ; dac se execut o comand LDD. Dup ce se termin o tranzacie, prima instruciune SQL executabil va genera automat nceputul unei noi tranzacii. Un commit apare automat: cnd este executat o comand LDD; cnd este executat o comand LCD; dup o ieire normal din SQL*Plus fr specificarea explicit a comenzilor COMMIT sau ROLLBACK. Un rollback apare automat dup o ieire anormal din SQL*Plus sau o cdere sistem. Din momentul n care s-a executat instruciunea COMMIT, BD s-a modificat (permanent) n conformitate cu instruciunile SQL executate n cadrul tranzaciei care tocmai s-a terminat. Din acest punct ncepe o nou tranzacie.

Dac se folosete utilitarul SQL*Plus, exist posibilitatea ca dup fiecare comand LMD s aib loc o permanentizare automat a datelor (un COMMIT implicit). Acest lucru se poate realiza folosind comanda: SET AUTO[COMMIT] {ON | OFF} Comanda ROLLBACK permite restaurarea unei stri anterioare a BD. ROLLBACK [TO [SAVEPOINT] savepoint]; Dac nu se specific nici un savepoint, toate modificrile fcute n tranzacia curent sunt anulate, iar dac se specific un anumit savepoint, atunci doar modificrile de la acel savepoint pn n momentul respectiv sunt anulate. Executarea unei instruciuni ROLLBACK presupune terminarea tranzaciei curente i nceperea unei noi tranzacii. Punctele de salvare pot fi considerate ca nite etichete care refer o submulime a schimbrilor dintr-o tranzacie, marcnd efectiv un punct de salvare pentru tranzacia curent. Punctele de salvare NU sunt obiecte ale schemei. Prin urmare, nu sunt referite in DD. Server-ul Oracle implementeaz un punct de salvare implicit pe care l mut automat dup ultima comand LMD executat. Dac este creat un punct de salvare avnd acelai nume cu unul creat anterior, cel definit anterior este ters automat. SAVEPOINT savepoint; Exemplu: Comanda ROLLBACK nu va genera terminarea tranzaciei. COMMIT INSERT SAVEPOINT a UPDATE INSERT SAVEPOINT b DELETE ROLLBACK TO a Starea datelor nainte de COMMIT sau ROLLBACK este urmtoarea: starea anterioar a datelor poate fi recuperat; utilizatorul curent poate vizualiza rezultatele operaiilor LMD prin interogri asupra tabelelor; ali utilizatori nu pot vizualiza rezultatele comenzilor LMD fcute de utilizatorul curent (read consistency);

nregistrrile (liniile) afectate sunt blocate i, prin urmare, ali utilizatori nu pot face schimbri n datele acestor nregistrri. Execuia unei comenzi COMMIT implic anumite modificri. Toate schimbrile (INSERT, DELETE, UPDATE) din baza de date fcute dup anterioara comand COMMIT sau ROLLBACK sunt definitive. Comanda se refer numai la schimbrile fcute de utilizatorul care d comanda COMMIT. Toate punctele de salvare vor fi terse. Starea anterioar a datelor este pierdut definitiv. Toi utilizatorii pot vizualiza rezultatele. Blocrile asupra liniilor afectate sunt eliberate; liniile pot fi folosite de ali utilizatori pentru a face schimbri n date. Execuia unei comenzi ROLLBACK implic anumite modificri. Anuleaz tranzacia n curs i toate modificrile de date fcute dup ultima comand COMMIT. Sunt eliberate blocrile liniilor implicate. Nu terge un tabel creat prin CREATE TABLE. Eliminarea tabelului se poate realiza doar prin comanda DROP TABLE. Exemplu: Ce efect are urmtoarea secven de instruciuni? (a) SELECT FROM * salariat; a;

(b)

SAVEPOINT

(c) DELETE FROM salariat; INSERT INTO salariat VALUES (18,Breaban,Marin,4,5000, tehnored); INSERT INTO salariat VALUES (23,Popescu,Emil,7,40000,grafician); SAVEPOINT b; (d) INSERT INTO salariat VALUES (29,,,5,3000000,tehnoredactor); SELECT AVG(salariu) FROM salariat;

(e)

ROLLBACK TO b; SELECT AVG(salariu) FROM salariat; ROLLBACK TO a; INSERT INTO salariat VALUES (18,Ion,Mihai,5,580,redr_sef); COMMIT;

(f)

Consistena la citire ntr-un sistem multi-user, sistemul Oracle furnizeaz read consistency la nivel de instruciune SQL, adic o singur comand SQL nu poate da rezultate care sunt contradictorii sau inconsistente. Read consistency asigur c fiecare utilizator vede datele aa cum existau la ultimul commit, nainte s nceap o operaie LMD. Prin urmare, modificrile efectuate asupra unei baze de date nu sunt vizibile dect dup ce operaia de actualizare a fost validat. Numai utilizatorul care a executat tranzacia poate vedea modificrile fcute de el n cursul acestei tranzacii. Modelul multiversiune, furnizat de Oracle, asigur consistena la citire: garanteaz c setul de date vzut de orice instruciune SQL este consistent i nu se schimb n timpul execuiei unei instruciuni (Oracle asigur o consisten la citire la nivel de instruciune); operaiile de citire (SELECT) nu trebuie s vad datele care sunt n proces de schimbare; operaiile de scriere (INSERT, DELETE, UPDATE) nu trebuie s afecteze consistena datelor i s ntrerup sau s intre n conflict cu alte operaii de scriere concurente. Cum se implementeaz modelul multiversiune? Dac asupra bazei este executat o comand LMD, server-ul Oracle face o copie a datelor dinainte de modificare i o depune n segmentul rollback (undo). Toi utilizatorii (cu excepia celor care modific datele) vor vedea datele cum sunt nainte de modificare (vd coninutul segmentului undo). Dac comanda LMD este commit, atunci schimbrile din baza de date devin vizibile oricrui utilizator care folosete instruciunea SELECT. Cnd se termin tranzacia, spaiul ocupat n segmentul undo de vechea dat este liber pentru reutilizare. Server-ul Oracle asigur astfel o vizualizare consistent a datelor n orice moment.

Carte

Controlul datelor (LCD)

Tranzacia este o unitate logic de lucru, constituit dintr-o secven de comenzi care trebuie s se execute atomic pentru a menine consistena datelor. Server-ul Oracle asigur consistena datelor prin intermediul tranzaciilor, inclusiv n eventualitatea unei anomalii a unui proces sau a sistemului. Tranzaciile ofer mai mult flexibilitate i control n modificarea datelor. Controlul tranzaciilor se realizeaz prin utilizarea instruciunilor limbajului de control al datelor: COMMIT, ROLLBACK, SET TRANSACTION, SAVEPOINT. Tranzaciile pot fi de tip LMD, LDD sau LCD. Tranzaciile LDD i LCD constau dintr-o singur instruciune LDD, respectiv LCD. Tranzaciile LMD constau dintr-o succesiune de instruciuni LMD care determin o modificare consistent a datelor. De exemplu, un transfer de fonduri ntre dou conturi bancare presupune debitarea unui cont i creditarea celuilalt cu aceeai sum. Ambele aciuni trebuie fie s eueze, fie s se ncheie cu succes. Creditarea nu trebuie salvat fr s fie salvat i operaia de debitare. Procesarea tranzaciilor Modificrile fcute asupra datelor n timpul unei tranzacii sunt temporare pn cnd tranzacia este salvat. Operaiile de prelucrare a datelor afecteaz iniial un buffer al bazei. Prin urmare, starea precedent a datelor poate fi recuperat. n general, o tranzacie ncepe atunci cnd este ntlnit prima instruciune LMD i se termin la: apariia unei instruciuni LDD; emiterea unei instruciuni LCD; prsirea mediului SQL*Plus; defectarea staiei de lucru sau la nregistrarea unei ntreruperi a sistemului. Execuia unei instruciuni LDD determin salvarea automat a modificrilor survenite pe perioada tranzaciei. Server-ul Oracle genereaz o operaie COMMIT implicit nainte i dup orice instruciune LDD. Aadar, chiar dac instruciunea LDD nu este executat cu succes, instruciunea anterioar acesteia nu mai poate fi anulat ntruct server-ul a efectuat deja operaia COMMIT. Instruciunile COMMIT i ROLLBACK ncheie tranzacia curent prin

definitivarea, respectiv anularea tuturor modificrilor aflate n ateptare. Aceste instruciuni permit: asigurarea consistenei datelor; previzualizarea modificrilor asupra datelor nainte ca acestea s devin permanente; gruparea logic a operaiilor. Ieirea din mediul SQL*Plus fr lansarea unei instruciuni COMMIT sau ROLLBACK are ca efect salvarea automat a tranzaciei curente. Atunci cnd intervine o anomalie (cdere) a sistemului sau nchiderea anormal a sesiunii SQL*Plus, ntreaga tranzacie curent este anulat automat (ROLLBACK). Acest fapt mpiedic eroarea s cauzeze modificri nedorite ale datelor i determin revenirea la starea din momentul ultimei operaii COMMIT. O ieire normal din iSQL*Plus are loc prin apsarea butonului Exit. Terminarea normal a unei sesiuni SQL*Plus are loc prin execuia comenzii EXIT. n SQL*Plus, nchiderea ferestrei este interpretat ca ieire anormal. Interfaa SQL*Plus pune la dispoziie variabila de mediu AUTOCOMMIT, care poate avea valorile ON sau OFF. Dac aceast variabil are valoarea ON, atunci efectul fiecrei instruciuni LMD se definitiveaz imediat ce instruciunea a fost executat. Dac variabila AUTOCOMMIT are valoarea OFF, definitivarea unei tranzacii va avea loc la execuia comenzii COMMIT sau n cazurile de salvare automat a tranzaciilor, prezentate anterior. Dup ncheierea unei tranzacii, urmtoarea instruciune SQL executabil marcheaz automat nceputul unei noi tranzacii. Comanda COMMIT Instruciunea COMMIT determin ncheierea tranzaciei curente i permanentizarea modificrilor care au intervenit pe parcursul acesteia. Instruciunea suprim toate punctele intermediare definite n tranzacie i elibereaz blocrile tranzaciei. De asemenea, instruciunea poate fi utilizat pentru terminarea unei tranzacii read-only nceput printr-o comand SET TRANSACTION. Sistemul lanseaz implicit o comand COMMIT nainte i dup orice instruciune LDD. Sintaxa corespunztoare comenzii COMMIT este urmtoarea: COMMIT [WORK] [COMMENT 'text' | FORCE 'text' [, nr_ntreg] ]; Opiunea WORK a fost introdus din motive de conformitate cu standardul SQL. Instruciunile COMMIT i COMMIT WORK sunt echivalente. Clauza COMMENT permite specificarea unui comentariu care va fi asociat

tranzaciei curente. Textul care i urmeaz poate ocupa maxim 255 octei i va fi stocat n vizualizarea DBA_2PC_PENDING din dicionarul datelor. ntr-un sistem distribuit, clauza FORCE permite salvarea manual a unei tranzacii distribuite in-doubt (n care operaia COMMIT a fost ntrerupt de o cdere a sistemului sau a reelei). Textul care i urmeaz conine identificatorul local sau global al tranzaciei. Pentru a afla aceti identificatori se poate consulta, de asemenea, vizualizarea DBA_2PC_PENDING din dicionarul datelor. Pentru a atribui tranzaciei un system change number (SCN) se specific un numr ntreg n clauza FORCE. Valoarea unui SCN este mrit ori de cte ori este salvat o tranzacie. Acest numr are un rol important n asigurarea consistenei la citire. n general, o cerere citete un bloc de date care are ca atribut un SCN corespunztor ultimei modificri a blocului respectiv. Dac acest SCN este mai mare dect cel citit la nceputul interogrii, nseamn c blocul a fost modificat ulterior lansrii cererii. Prin urmare, trebuie gsit o versiune mai veche a blocului n segmentele de anulare. O instruciune COMMIT care conine clauza FORCE permanentizeaz numai tranzacia specificat i nu o afecteaz pe cea curent. Prezena acestei clauze nu este permis n PL/SQL. Exemplu: S se insereze o nregistrare n tabelul artist i s se permanentizeze modificarea. INSERT INTO artist(cod_artist, nume, prenume) VALUES (189, 'Pallady', 'Theodor'); COMMIT; nainte de operaia COMMIT, utilizatorul curent poate vizualiza rezultatele comenzilor LMD prin interogarea tabelelor. Efectele acestor operaii nu sunt vizibile celorlali utilizatori. Server-ul Oracle asigur consistena la citire, astfel nct fiecare utilizator vizualizeaz datele n starea corespunztoare ultimei operaii COMMIT efectuate asupra lor. Liniile afectate de tranzacia curent sunt blocate, nefiind posibil modificarea lor de ctre ceilali utilizatori. Dac mai muli utilizatori modific simultan acelai tabel, fiecare dintre acetia poate consulta numai propriile modificri. Pe msur ce operaia COMMIT este executat de ctre utilizatori, actualizrile efectuate de acetia devin vizibile. n urma execuiei instruciunii COMMIT, modificrile asupra datelor sunt scrise n baza de date, iar starea precedent a datelor este pierdut definitiv. n acest fel, rezultatele tranzaciei pot fi vizualizate de ctre toi utilizatorii. Blocrile asupra liniilor afectate sunt eliberate, astfel c nregistrrile devin disponibile

celorlali utilizatori pentru a efectua noi actualizri. Dup operaia COMMIT, toate punctele intermediare (SAVEPOINT) ale tranzaciei respective sunt terse. Comanda ROLLBACK Atunci cnd o linie este modificat, valorile anterioare ale coloanelor actualizate sunt salvate ntr-un segment de reluare. Dac tranzacia este anulat, server-ul Oracle va rescrie valorile din acest segment n linia tabelului. Pentru a renuna la modificrile efectuate se utilizeaz instruciunea ROLLBACK. n urma execuiei acesteia, se ncheie tranzacia, se anuleaz modificrile asupra datelor, se restaureaz starea lor precedent i se elibereaz blocrile asupra liniilor. O parte a tranzaciei poate fi anulat automat printr-o operaie ROLLBACK implicit dac a fost detectat o eroare n timpul execuiei unei instruciuni. Dac o singur instruciune LMD eueaz n timpul execuiei unei tranzacii, efectul su este anulat de un ROLLBACK la nivel de instruciune, dar schimbrile efectuate de instruciunile LMD precedente nu sunt anulate. Acestea din urm pot fi salvate sau anulate explicit de ctre utilizator. Sintaxa instruciunii ROLLBACK este urmtoarea: ROLLBACK [WORK] [TO [SAVEPOINT] pct_intermediar | FORCE 'text']; Semnificaiile opiunilor WORK i FORCE sunt similare celor prezentate n cadrul instruciunii COMMIT. n clauza TO SAVEPOINT se poate specifica punctul intermediar pn la care se dorete anularea tranzaciei. n absena acestei clauze, ntreaga tranzacie este anulat. O tranzacie in-doubt nu poate fi anulat manual pn la un punct intermediar. Dac a fost definit un punct intermediar prin instruciunea SAVEPOINT nume, instruciunea ROLLBACK TO SAVEPOINT nume determin ntoarcerea tranzaciei curente la punctul intermediar specificat. n felul acesta se revine ntr-o stare anterioar a tranzaciei i se anuleaz modificrile care au survenit dup definirea punctului intermediar. De asemenea, sunt terse punctele intermediare ulterioare acestuia i sunt eliberate toate blocrile asupra tabelelor sau liniilor, efectuate dup punctul intermediar respectiv. Comanda SAVEPOINT Instruciunea SAVEPOINT marcheaz un punct intermediar n procesarea tranzaciei. n acest mod este posibil mprirea tranzaciei n subtranzacii.

Aceast instruciune nu face parte din standardul ANSI al limbajului SQL. Punctele intermediare definite n procesarea unei tranzacii nu sunt obiecte ale schemei i nu pot fi referite n dicionarul datelor. Nu exist nici o modalitate de a lista punctele intermediare definite. Dac este creat un al doilea punct intermediar avnd acelai nume cu un punct intermediar precedent, acesta din urm este ters. Instruciunea SAVEPOINT are sintaxa: SAVEPOINT nume_pct_intermediar; Exemplu: S se mreasc prin 20%, respectiv 50% valoarea operelor care au codurile 100, respectiv 150. S se verifice c valoarea total a operelor din galerie nu depete 7 000 000, iar apoi s se reactualizeze valoarea operei avnd codul 150, mrind-o cu 40%. UPDATE opera SET valoare = valoare * 1.2 WHERE cod_opera = 100; SAVEPOINT val_100; UPDATE opera SET valoare = valoare * 1.5 WHERE cod_opera = 150; SAVEPOINT val_150; SELECT SUM(valoare) FROM opera; ROLLBACK TO SAVEPOINT val_100; UPDATE opera SET valoare = valoare * 1.4 WHERE cod_opera = 150; COMMIT;

Consistena la citire Utilizatorii pot accesa baza de date prin operaii de citire (instruciuni SELECT) sau prin operaii de scriere (instruciuni INSERT, UPDATE, DELETE). Consistena la citire este necesar pentru a asigura c: datele vizualizate de ctre utilizatorii care scriu i citesc din baza de date sunt consistente; utilizatorii care citesc din baza de date nu pot vizualiza starea datelor care sunt n curs de modificare; utilizatorii care scriu n baza de date sunt asigurai c modificrile asupra acesteia se realizeaz n mod consistent; modificrile pe care le efectueaz un utilizator nu intr n conflict cu cele ale altui utilizator. Scopul consistenei la citire este ca fiecare utilizator s vizualizeze datele n starea existent la ultima operaie COMMIT. Consistena la citire se implementeaz automat, prin pstrarea unei copii pariale a bazei de date n segmentele de reluare. Atunci cnd se efectueaz o operaie INSERT, UPDATE sau DELETE, server-ul Oracle reine o copie a datelor n starea dinaintea modificrii i o scrie ntr-un segment de reluare. Pentru toi utilizatorii care citesc din baza de date, cu excepia celui care a iniiat modificarea, datele sunt vizibile n starea dinaintea nceperii reactualizrii. Aceti utilizatori vizualizeaz starea datelor din segmentul de reluare. Astfel, se garanteaz c utilizatorii citesc date consistente care nu sunt n curs de schimbare. Dup ce se efectueaz operaia COMMIT asupra tranzaciei, modificrile fcute n baza de date devin vizibile tuturor. Server-ul Oracle creeaz vizualizri consistente la citire pentru interogrile care au nceput nainte ca tranzacia s fie salvat. Apoi, spaiul ocupat de datele vechi n segmentul de reluare va fi eliberat pentru a fi refolosit. Dac se efectueaz operaia ROLLBACK asupra tranzaciei, modificrile sunt anulate. Astfel, versiunea datelor salvate n segmentul de reluare este rescris n tabel, iar baza de date revine n starea de dinaintea nceperii tranzaciei.