Baze de Date Relation Ale

June 20, 2018 | Author: Pantzy Alexu | Category: N/A
Share Embed Donate


Short Description

Download Baze de Date Relation Ale...

Description

TRANSILVANIA DIN BRAŞOV FACULTATEA DE ŞTIINŢE ECONOMICE

UNIVERSITATEA

Prof.dr. DORIN LIXĂNDROIU

Lector dr. RADU LIXĂNDROIU

BAZE DE DATE

RELAŢIONALE     

introducere în baze de date algebra relaţională (AR) SQL Access interogări în AR şi Access 2007

normalizarea relaţiilor

 Note de curs

 Anul universitar 2009-2010 1

CAP.1. BAZE DE DATE 1.1. ORGANIZAREA DATELOR (OD) (Ce presupune organizarea datelor?)

● definirea, structurarea, ordonarea şi gruparea datelor în colecţii de date omogene; ● stabilirea relaţiilor între date, între elementele unei colecţii, între colecţii de date; ● stocarea datelor pe suport informational. 1.2. OBIECTIVELE ORGANIZĂRII DATELOR  (De ce este necesară organizarea datelor ?)

● minimizarea timpului de acces la date; ● economie de memorie internă şi externă; ● asigurarea unicităţii datelor; ● sistemul OD trebuie să reflecte cât mai fidel toate legăturile dintre obiectele, fenomenele, procesele economice pe care aceste date le reprezintă; ● asigurarea flexibilităţii datelor. 1.3. ETAPE ALE EVOLUTIEI TEHNICILOR DE ORGANIZARE ŞI PRELUCRARE A DATELOR

●   Prima etapă  –   –  se adaptează tipurile de organizare a datelor existente în sistemele de  prelucrare manuală la condiţiile tehnice impuse de calculator. - apare fişierul (în general cu organizare secvenţială) - utilizarea benzilor magnetice - prelucrarea pe loturi (batch processing) ●   A doua etapă  –   –  este marcată de separarea dintre structura logică de date şi structura fizică. Rezultă independenţa fizică a datelor. - se utilizează fişiere secvenţial-indexate şi fişiere cu acces direct - suport extern de memorare discul magnetic - se asigură independenţa aplicaţiilor de modificările echipamentelor hardware (banda, disc, etc.) - apar primele facilităţi simple de protecţie a datelor fiecare aplicaţie lucrează cu propriile fişiere fără a avea nici o legătură cu fişierele utilizate de alte aplicaţii. Caracteristică comună a primelor două etape:

 Inconveniente:

- redundanţa datelor = > probleme î n operaţiile de actualizare - absenţa unor legături logice între datele din grupuri diferite de fişiere = > număr mare de fişiere, timp mare de prelucrare - flexibilitate redusă a sistemului la apariţia unei noi aplicaţ ii.

● A treia etapă  – este  – este definită de apariţia fişierelor integrate. - se reduce redundanţa datelor, aceleaşi date fizice pot fi utilizate în comun de către mai multe aplicaţii - rezultă o structură logică unitară.

2

CAP.1. BAZE DE DATE 1.1. ORGANIZAREA DATELOR (OD) (Ce presupune organizarea datelor?)

● definirea, structurarea, ordonarea şi gruparea datelor în colecţii de date omogene; ● stabilirea relaţiilor între date, între elementele unei colecţii, între colecţii de date; ● stocarea datelor pe suport informational. 1.2. OBIECTIVELE ORGANIZĂRII DATELOR  (De ce este necesară organizarea datelor ?)

● minimizarea timpului de acces la date; ● economie de memorie internă şi externă; ● asigurarea unicităţii datelor; ● sistemul OD trebuie să reflecte cât mai fidel toate legăturile dintre obiectele, fenomenele, procesele economice pe care aceste date le reprezintă; ● asigurarea flexibilităţii datelor. 1.3. ETAPE ALE EVOLUTIEI TEHNICILOR DE ORGANIZARE ŞI PRELUCRARE A DATELOR

●   Prima etapă  –   –  se adaptează tipurile de organizare a datelor existente în sistemele de  prelucrare manuală la condiţiile tehnice impuse de calculator. - apare fişierul (în general cu organizare secvenţială) - utilizarea benzilor magnetice - prelucrarea pe loturi (batch processing) ●   A doua etapă  –   –  este marcată de separarea dintre structura logică de date şi structura fizică. Rezultă independenţa fizică a datelor. - se utilizează fişiere secvenţial-indexate şi fişiere cu acces direct - suport extern de memorare discul magnetic - se asigură independenţa aplicaţiilor de modificările echipamentelor hardware (banda, disc, etc.) - apar primele facilităţi simple de protecţie a datelor fiecare aplicaţie lucrează cu propriile fişiere fără a avea nici o legătură cu fişierele utilizate de alte aplicaţii. Caracteristică comună a primelor două etape:

 Inconveniente:

- redundanţa datelor = > probleme î n operaţiile de actualizare - absenţa unor legături logice între datele din grupuri diferite de fişiere = > număr mare de fişiere, timp mare de prelucrare - flexibilitate redusă a sistemului la apariţia unei noi aplicaţ ii.

● A treia etapă  – este  – este definită de apariţia fişierelor integrate. - se reduce redundanţa datelor, aceleaşi date fizice pot fi utilizate în comun de către mai multe aplicaţii - rezultă o structură logică unitară.

2

 Notă. Structura integrată

constituie originea noţiunii de model conceptual (modelul ce contine descrierile tuturor datelor şi a legăturilor dintre ele). ● A patra etapă  –   – este etapa bazelor de date. 1.4. SISTEMUL BAZAT PE FISIERE INDEPENDENTE (file based)

Este o colecţie de programe de aplicaţie care efectuează servicii pentru utilizatorii finali. Fiecare program defineşte şi gestionează propriile date. Caracteristici:

● datele sunt descrise independent în toate fişierele în care apar ● fiecare fişier de date este descris în toate programele care îl accesează ● nu există control al accesului şi manipulări i datelor, în afara celui impus prin  programele de aplicaţie.  Dezavantajele tratării bazate pe fisiere:

● redundanţa şi inconsistenţa datelor ● dificultatea accesului ● izolarea datelor  ● complexitatea deosebită a actualizărilor  ● probleme de securitate ● probleme legate de integritatea datelor ● costul ridicat ● dificultatea de a obţine răspunsuri rapide la probleme ad-hoc simple ● inflexibilitatea faţă de schimbările ulterioare din sistemul informational. 1.5. BAZE DE DATE

- înregistrarea unei observaţii, obiect, fenomen, imagine, sunet sau text, într -o -o formă convenabilă unei prelucrări, interpretări sau transmiteri prin mijloacele informaticii.

 DATA

 INFORMAŢIA - semnificaţia ce poate fi ataşată sau poate fi dedusă dintr-un ansamblu de

date pe baza asociaţiilor dintre acestea.

 – o colecţie de date operaţionale înregistrate pe suport adresabil, aflate  BAZA DE DATE  –  în interdependenţă logică, împreună cu descrierea datelor şi a relaţiilor dintre ele şi care   sunt prelucrate în aplicaţiile informatice ale unei organizaţii.   Baza de date permite operaţii de introducere, ştergere, actualizare şi interogare a datelor. este un ansamblu de date: - structurate, - coerente, - persistente,

 BAZA DE DATE 

3

- cu o redundanţă minimă şi controlată, - independente de programul de aplicaţie, - direct accesibile după mai multe criterii, - simultan accesibile de către mai mulţi utilizatori.  ARHITECTURA UNUI SISTEM DE BAZE DE DATE (Database System) - baza de date propriu-zisă în care se memorează datele

- sistemul de gestiune al bazei de date (SGBD) - metabaza de date - dicţionarul datelor (DD) - mijloacele hardware - personalul (ABD, analişti, programatori, utilizatori finali) . Cerinţele minimale care se impun unei baze de date: - furnizarea în timp util a informaţiilor solicitate - costuri minime în prelucrarea şi întreţinerea informaţiei - capacitatea de a satisface , cu aceleaşi date necesităţile informaţionale ale unui

număr mare de utilizatori -  flexibilitate -   posibilitatea de adaptare la cerinţe noi, de a da răspunsuri la interogări neprevăzute iniţial - asigurarea unei redundanţe minime a datelor - sincronizare  – exploatarea simultană a datelor de către mai mulţi utilizatori - confidenţialitate  –  asigurarea securităţii datelor prin mecanisme de protecţie  împotriva accesului neautorizat - integritate  – facilităţi de validare şi recuperare a datelor deteriorate accidental - compatibilitate şi expandabilitate  –  posibilitatea de valorificare a eforturilor anterioare şi anticiparea nevoilor viitoare -  permisivitate  –   prin ierarhizarea datelor după criteriul frecvenţei acceselor, sau reorganizări care să crească performanţele BD.

Administratorul bazei de date este responsabil cu realizarea fizică a BD, care include pr oiectarea, implementarea, exploatarea şi întreţinerea acesteia, securitatea, acordarea drepturilor de acces şi controlul integrităţii.

  Database Administration (ABD) -

1.6. SISTEMUL DE GESTIUNE AL BAZELOR DE DATE ( SGBD)

 Database Management System (DBMS) SGBD - un ansamblu de programe (produs software) care permite definirea,actualizarea  şi consultarea datelor din baza dedate.

 Funcţiile unui SGBD: - definirea datelor (DDL  –  Data Definition Language)   permite

definirea conceptuală a

datelor, fără referire la modul de memorare - manipularea datelor (DML  –   Data Manipulation Language şi / sau interfaţa cu limbaje de programare)  permite specificarea operaţiilor de introducere, actualizare, ştergere şi interogare a datelor 

4

- controlul integrităţii datelor  - accesul concurent (folosirea simultană a datelor de mai mulţi utilizatori) - confidenţialitatea informaţiilor din BD - securitatea în funcţionare (DCL – Data Control Language)

Utilizator

Interfaţă de generaţia a 4-a

Definire de date S Manipulare

Pascal Visual Fox Oracle ...

G

Confidenţialitate B Securitate D

Interfeţe

Sistem de exploatare

Baze de date

Baze de date

 Arhitectura funcţională a unui SGBD

5

Obiectivele unui SGBD:

- asigurarea independenţei datelor  - asigurarea unor facilităţi sporite de utilizare a datelor  - asigurarea unei redundanţe minime şi controlate a datelor din BD (reducerea redundanţelor se face prin identificarea informaţiilor comune) - securitatea şi confidenţialitatea datelor - partajabilitatea datelor - integritatea datelor

Există mai multe nivele de reprezentare (abstractizare şi percepţie) a datelor în baza de date: 

  Nivelul conceptual –  este



 Nivelul logic – este dat de viziunea programatorului de aplicaţii asupra datelor.



  Nivelul fizic (intern)  –  este



 Nivelul virtual (extern) – este dat de viziunea utilizatorului final asupra sistemului.

dat de viziunea adminstratorului bazei de date asupra datelor. Principalele aspecte la acest nivel: - cu instrumentele oferite de SGBD, administratorul bazei de date realizează structura conceptuală a BD; - viziunea adminstratorului bazei de date este independentă de aplicaţiile care vor fi dezvoltate (independenţă logică) ; - rezultatul la acest nivel este schema conceptuală. Principalele aspecte la acest nivel: -  programatorul de aplicaţii realizează programele pentru descrierea şi manipularea datelor; -  programele implementează structura externă (logică) a datelor; - structura externă este dedusă din schema conceptuală ; - viziunea programatorului de aplicaţii este independentă de suportul tehnic de informaţie (independenţa fizică). dat de viziunea   programatorului (inginerului) de sistem asupra datelor. Principalele aspecte la acest nivel: -  programatorul de sistem realizează structura internă (fizică); - structura internă corespunde descrierii datelor pe supotul fizic de informaţie; - structura internă este dedusă din cea externă; - implementarea schemei interne se face cu ajutorul sistemului de gestiune a fişierelor din SGBD şi/sau din sistemul de operare, prin gestiunea fizică a perifericelor.

6

Domeniu de aplicaţie Parte a domeniului obiect de studiu

Formalisme Scheme externe

Schema conceptuală

Entitate-asociere, semantică relaţională, funcţională etc.

CONCEPTUAL

Relaţională Factori cantitativi

Schema logică

LOGIC

În funcţie de SGBD (tabel, înregistrare, segment, etc.)

Constrângeri ale SGBD-ului

Schema fizică

FIZIC

SGBD Programe

Baza de date

 Nivele de reprezentare a datelor 

7

Într-un raport al   ANSI / SPARC (  American National Standards Institute / Standards Planning And Requirements Committee) se disting cel puţin trei nivele de reprezentare a datelor (conceptual, logic şi fizic). Pentru fiecare nivel se asociază o schemă. Comentarii.    Manipularea datelor   presupune instrumente şi mecanisme ce permit comunicarea: bază de date - utilizatori. Pentru manipularea datelor, SGBD-urile oferă o serie de facilităţi, incluse în   Data Manipulation Language (DML). Acţiunea se exprimă sub

forma unei fraze a limbajului, care este evaluată şi executată de SGBD. Interfeţele sunt alte forme de comunicare care permit SGBD-ului să transmită date către alte limbaje de programare (Pascal, C, C++, Cobol etc.). Aceste interfeţe permit accesul şi manipularea datelor dintr -o bază de date plecând de la un program scris  într-un limbaj de programare clasic (procedural). 

  Integritatea datelor. Conceptul



 Accesul concurent. Datele dintr-o bază de date pot fi accesate concurent  de mai mulţi





de integritate a datelor  este relativ la calitatea informaţiei înregistrate. Constrângerile de integritate sunt specificate în definirea schemei bazei de date.

utilizatori. SGBD-ul trebuie să ofere mecanisme de gestiune a conflictelor de acces. Confidenţialitate. Punerea

în comun a datelor pentru mai mulţi utilizatori impune  problema confidenţialităţii. Confidenţialitatea este asigurată prin nume de utilizator şi  parolă care generează drepturi de acces diferenţiate. Securitatea în funcţionare. SGBD-ul

trebuie să ofere mecanisme care să permită repunerea rapidă a bazei de date în stare operaţională, în caz de incident hardware sau software. Aceste mecanisme sunt bazate pe înregistrarea operaţiunilor realizate asupra  bazei de date şi reexecutarea lor automată în caz de incident.

1.7. BANCA DE DATE – BAZA DE DATE

Există în literatura de specialitate mai multe abordări ale celor două concepte. Modul lor de tratare este departe de a fi unitar. În unele lucrări se consideră:  A. Banca de date :=

Baza de date + SGBD

Alţi autori extind noţiunea de bancă de date şi consideră banca de date formată din :  B. Banca de date :=

baza de date + hardware + SGBD + programele de aplicaţii + utilizatorii

În cartea L’art des bases de données, autorii Miranda S.M., Busta J.M. fac distincţia între cele două concepte:

8

conţine date primare care sunt exploatate cu ajutorul unui SGBD. În cazul unei interogări, sistemul de gestiune al bazei de date furnizează direct răspunsul.  Banca de date date conţine date referenţiale şi accesul este asigurat cu ajutorul unui sistem documentar (SD) documentar  (SD). Sistemul documentar  permite o direcţionare către un text (carte, articol, ...) şi după consultare se obţine răspunsul la interogarea formulată. C. Baza de date

[Miranda, 1988]: Dacă se consideră atributul  –  “stare de sănătate” având mai multe valori, printre care {...., nebun, ...} şi formulăm interogarea:

 Exemplu

“Care a fost starea de sănătate a preşedintelui Wilson (SUA) între 1914- 1918 ?” Răspunsul dat de banca de date va fi de genul: Istoria contemporană a SUA, pag. 52, ed. 1980, iar răspunsul efectiv se obţine în urma consultării lucrării indicate . În cazul unei baze de date răspunsul va fi direct valoarea atributului “stare de sănătate”: nebun.

1.8. MODELE DE REPREZENTARE A DATELOR

Tipologia SGBD-urilor este în general funcţie de tipurile de s tructuri ale datelor pe care le suportă. Dintre modelele cele mai întâlnite amintim [Ionescu, 2004]:     

modelul ierarhic modelul reţea modelul relaţional  modelul orientat-obiect  modelul obiect relaţional 

acesta a fost primul model folosit pentru dezvoltarea bazelor de date. Modelul permite reprezentarea claselor sau ansamblelor de obiecte printr-o structură ierarhică de înregistrări. Relaţiile de tip "tată -fiu" -fiu" între clase sunt de tip 1:N. Ansamblul claselor se constituie într-un arbore direcţionat în care nodurile sunt tipurile de înregistrări, iar arcele sunt tipurile de legături.

  Modelul ierarhic (Hierarchical Model)  – 

 –  utilizează Modelul reţea (Network Model)  – utilizează

o structură de graf pentru definirea schemei conceptuale a bazei de date.   Nodurile grafului sunt tipurile de entităţi, iar muchiile reprezintă legăturile dintre tipurile de entităţi. Relaţiile sunt de tipul M:N şi se reprezintă fără duplicarea înregistrărilor, fiecare înregistrare putând fi referită de mai multe înregistrări. Acest model este în prezent rar folosit pentru baze de date generale, care implică operaţii de interogare. Aplicarea modelului reţea se întâlneşte în bazele de date grafice utilizate în modelarea realităţii virtuale.

Modelul relaţional  (Relational Model)  –  premite vizualizarea unei baze de date ca un

ansamblu de tabele bidimensionale. Modelul se bazează pe noţiunea de relaţie din matematică, care corespunde unei mulţimi de entităţi de acelaşi tip. Limbajele relaţionale de manipulare a datelor sunt limbaje neprocedurale – utilizatorul,  – utilizatorul, de exemplu, formulează interogarea fără să indice procedura (algoritmul) de rezolvare. SGBD-urile relaţionale oferă un limbaj de   programare unanim recunoscut şi acceptat, limbajul SQL, bazat pe

9

algebra relaţională. Pentru limbajul SQL au fost emise mai multe standarde de către  International Standardization Office (ISO).   Modelul orientat-obiect (Object Model) –  este

un concept unificator în informatică, fiind aplicabil în programare, în proiectare hardware-ului, a bazelor de date, etc. Sistemele de  baze de date orientate obiect se bazează pe limbajele de programare orientate obiect. Au o utilizare limitată, mult mai redusă decât cea a sistemelor de baze de date relaţionale. Pentru bazele de date orientate obiect există un limbaj standard standard de interogare OQL (Object Query Language).  M odelul obiect relaţional  (Object Relational Model)  – este considerat

următorul mare val în dezvoltarea şi întreţinerea bazelor de date. Construcţia se poate realiza dezvoltând sistemul relaţional prin adăugarea caracteristicilor obiectuale necesare sau pornind de la un sistem orientat obiect şi adăugând caracteristicile relaţionale. 1.9. SCURTĂ ISTORIE A BAZELOR DE DATE 1961 - apariţia sistemului  IDS (Integrated Data Storage, General Electric) . Terminologia

introdusă (tipuri de înregistrări şi tipuri set) va fi utilizată în modelul reţea prezentat la "Conference On DAta SYstems and Languages Data Base Task Group" (CODASYL DBTG). 1965-1970 - dezvoltarea sistemelor de gestiune a fişierelor generalizate.  IBM  a dezvoltat modelul iererhic şi sistemul IMS (Information Management System). În acceasşi perioadă apare IMS DB/DC (DataBase/DataCom) care suportă modelul reţea. În anii 70, domeniul se dezvoltă foarte mult, ajungând să fie disciplină universitară şi de cercetare. Astfel apar numeroase produse comerciale care implementează propuner ile raportului CODASYL DBTGi:   ISD II (HoneyWell), DMS1100 (UNIVAC), DMS II  (Burroughs), etc. 1970 - apare modelul relaţional de date 1971 - publicarea raportului CODASYL DBTG 1972  –   prima conferinţă internaţională organizată de  ACM SIGMOD (Association of  Computing Machinery, Special Interest Group on Management Of Data) 1975 -   prima conferinţă internaţională VLDB (Very Large Data Base); publicarea raportului ANSI-SPARC  1976 - publicarea modelului Entitate - Asociere 1975 - 1980 - dezvoltarea sistemelor relaţionale experimentale: SYSTEM-R (IBM) şi  INGRES (Berkeley, University of California) 1980 - .... apariţia şi comercializarea a numeroase SGBD-uri relaţionale ce au înlocuit

SGBD-urile ierarhce şi reţea. SGBD-urile pot fi utilizate pe microcalculatoare şi se realizează sisteme din generaţia a patra cu instrumente şi interfeţe multiple. 1990 - .... se dezvoltă numeroase produse a căror complexitate creşte, la un preţ tot mai scăzut: PowerBuilder (SYSBASE), Oracle Developer, VB (Microsoft) , etc. Se dezvoltă modelul client-server, ce se foloseşte în tot mai multe aplicaţii economice. Se dezvoltă şi produse sotftware ca   Excel/ Access (Microsoft) pentru scop personal de o complexitate mai scăzută.

10

- apar baze de date pentru  Internet . Sunt utilizate conceptele client-server , şi astfel complexitatea Internet-ului creşte exponenţial. 2000 -  pentru aplicaţiile pe Internet  apar o serie de instrumente cum ar fi   Active Server  1990-1995

Pages, Java Servlets, JDBC, Enterprise Java Beans, ColdFusion, Dream Weaver, Oracle   Developer 2000, Apache, MySQL. Se dezvoltă procesarea tranzacţiilor online (OLTP)  precum şi procesarea analitică de tip OLAP. După 2000 - se dezvoltă aplicaţii pe arhitectura client-server pentru PDA-uri, tranzacţii cu POS-uri, telefoane mobile. Companiile cele mai reprezentative din domeniu rămân:  IBM, Microsoft şi Oracle .

1.10. BAZE DE DATE RELAŢIONALE

Conceptul de baze de date relaţionale (BDR) apare în lucrarea lui  E.F.CODD (IBM),  A  Relational Model for Large Shared Data Banks, (1970) . Modelul de date relaţional a fost  perfecţionat în anii următori de C.J. DATE, R. BOYCE, R. FAGIN, W.W. ARMSTRONG . Caracteristicile modelului relaţional:    

datele sunt percepute de utilizatori ca tabele simplitate şi precizie în definirea elementelor de bază (relaţii, atribute, domenii) operatorii relaţionali generează un tabel rezultat  din tabelele operanzi restricţiile de integritate, normalizarea relaţiilor, controlul concurenţei permit crearea structurii datelor şi a prelucrării lor într -un mod consistent şi asigură integritatea şi  protecţia acestora.

  Definiţia 1.1. BDR este un ansamblu organizat de tabele (relaţii)

împreună cu legăturile

dintre ele.

Avantajele BDR faţă de fişiere (sisteme file-based ) [Velicanu, 2003]: CRITERIU

Independenţa datelor  Nivele de structurare Deschidere şi portabilitate Reprezentarea şi utilizarea datelor Structura datelor se păstrează

BDR

FIŞIERE

logică şi fizică conceptual, logic, fizic mare simplificată prin model

fizică logic şi fizic mică complicată

în dicţionarul datelor 

în programe

 E.F.CODD formulează 13 reguli  pentru evaluarea performanţelor unui sistem de gestiune a bazelor de date relaţionale (SGBDR). Aceste reguli exprimă cerinţele maximale ca un SGBDR să fie relaţional.

Condiţiile minimale ca un SGBD să fie relaţional , pot fi formulate astfel:  să implementeze modelul de date relaţional prin   DDL (Data Definition Language) şi  DML (Data Manipulation Language) 

să implementeze un limbaj de interogare relaţional

11

Interfaţa utilizatorului Gestiunea vederilor R E Z U L T A T E

Integritatea semantică Autorizarea accesului

Control

Optimizarea cererilor Gestiunea planurilor de execuţie

Tratarea cererilor

Controlul execuţiei Executarea operatorilor algebrici

Gestiunea buffer-ului Mecanisme de acces

Gestiunea accesului

Gestiunea accesului concurent

Securitate

Jurnalizarea  Arhitectura funcţională a unui SGBD relaţional 

Elementele de bază utilizate pentru a descrie datele în modelul relaţional  din punct de vedere formal, uzual sau fizic sunt: Formal

relaţie tuplu atribut domeniu

Uzual

Fizic

fişier  articol câmp tip de dată

tablou linie coloană tip de dată

12

Principalele concepte utilizate în bazele de date relaţionale

  Definiţia 1.2. Domeniul este un ansamblu de valori care poate fi definit explicit prin

enumerarea tuturor valorilor sau implicit prin precizarea proprietăţilor pe care le au valorile domeniului respectiv.  Exemplu:  D1 = {“MK”, “ECTS”, “FB”, “CIG”, “IE”, “MN” }  D2  x | x  N  , x 0 ,100  D3 = {0, 9, 19} - domeniul D1 este definit explicit prin enumerarea programelor de studii care plan disciplina Baze de date; - domeniul  D2 este definit implicit prin specificarea proprietăţilor care pot fi

-

au în

luate

de valorile domeniului; domeniul  D3 este definit explicit prin enumerarea valorilor posibile (în procente) ale cotelor de TVA.  D1  D2

...  Dn

V 1 ,V 2 ,...,V n  , unde V 1 Fiecărui domeniu i se asociază un atribut  :  f  :  Ai

 D1 ,...,V n

Dn

 Di ,  f   Ai

Di

  Definiţia 1.3. Relaţia  poate fi definită ca o mulţime cartezian  D1  D2 ... Dn , astfel spus  R  D1  D2

de tupluri ce aparţine produsului ... Dn .

Relaţia se poate memora într -o tabelă bidimensională:  R

A1

 A 2

t 1 t 2

a11 a21 ... am1

a12 a22 ... am2

t m

 

.....

... .....

 n

a1n a2n ... amn

Liniile tabelului formează elementele relaţiei numite şi tupluri. Notăm: tuplul i prin t i ai1 , ai 2 ,..., ain . este un element invariant în timp şi este dată de mulţimea numelor atributelor corespunzătoare unei relaţii. Pentru fiecare atribut se  precizează domeniul asociat.  Notăm schema unei relaţii cu:  R  A1 :  D1 , A2 :  D2 ,..., An : Dn sau pe scurt:  R  A1 , A2 ,..., An . Schema relaţiei (schema relaţională)

este dată de mulţimea tuturor schemelor relaţionale corespunzătoare unei aplicaţii, iar conţinutul curent al relaţiilor la un moment dat se numeşte bază de date relaţională . Schema bazei de date relaţionale

Cardinalul unei relaţii este dat de numărul de tupluri din relaţie. Gradul unei relaţii (aritatea relaţiei) este dat de numărul de atribute din relaţie.

13

A

este definită implicit pe baza altor relaţii, prin intermediul unei expresii relaţionale. Stabilirea efectivă a tuplurilor care compun relaţia virtuală se realizează prin evaluarea expresiei relaţionale în momentul în care utilizatorul apelează la această relaţie.

  Relaţia virtuală (relaţie derivată, viziune)

  Domenii compatibile cu reuniunea –  domeniile

corespondente iau valori în aceleaşi domenii.

au acelaşi grad (aritate) şi atributele

Relaţia se prezintă ca o mulţime de tupluri. Logic, această mulţime nu poate conţine elemente identice, cu alte cuvinte, relaţia nu poate avea tupluri duplicate. Necesitatea identificării unui tuplu a condus la noţiunea de cheie. unei relaţii reprezintă ansamblul minimal de atribute cu rol de identificare unică a tuplurilor dintr -o relaţie. Într -o relaţie pot exista mai multe atribute / combinaţii de atribute cu rol de identificare unică a tuplurilor, există deci mai mulţi candidaţi cheie. Dintre aceştia  ABD-ul alege cheia primară  , celelalte devin chei secundare sau alternante. Orice relaţie are cel puţin o cheie.

  Definiţia 1.3. Cheia

cheia formată dintr -un singur atribut, iar cheia compusă  este formată din mai multe atribute. Cheia simplă  este

 Domeniul primar  este domeniul pe care este definită cheia primară. Cheia extern ă  este un atribut /grup pe domeniul primar al altei relaţii.

de atribute dintr-o relaţie, ale cărui valori sunt definite

relaţie  RP este  pr imară  , dacă există o altă relaţie  R, legată semantic de ea, care are drept cheie externă , cheia primară a relaţiei considerate (RP).

  Relaţia primară. O

 Exemple.

1. Fie relaţia STUDENT [nr_matricol, nume, facultate, grupa, sectia, CNP, adresa] Atributele nr_matricol şi CNP au rol de identificare unică a tuplurilor din relaţie; reprezintă candidaţi cheie . Alegem drept cheie primară  atributul nr_matricol, care are domeniul format din 4 caractere numerice şi este mai uşor de operat. Atributul CNP, format din 13 caractere numerice devine cheie secundară (alternantă). 2. Se consideră relaţiile: PRODUSE [cod_produs, denumire, um] CONTRACTE [nr_contract, cod_produs , cod_client , data, cantitate, pret_unitar] CLIENTI [cod_client, nume, CUI, adresa, cont, tel, email] 

relaţia PRODUSE are cheia primară  - cod_produs;

14

  

relaţia CONTRACTE are cheia primară  - nr_contract, iar atributele cod_produs şi cod_client  sunt chei externe ; relaţia CLIENTI are cheia primară  - cod_client, iar atributul CUI este cheie  secundară ; PRODUSE şi CLIENTI sunt r elaţii primare.

1.11. RESTRICŢIILE DE INTEGRITATE MINIMALE   Restricţiile de integritate minimale

sunt reguli pe care trebuie să le satisfacă datele din

baza de date. A.   Integritatea domeniului –  constă din controlul sintactic şi semantic al unei date oarecare şi se referă la definiţia tipului domeniului. De exemplu, în cazul unui domeniu definit explicit prin enumerarea valorilor, trebuie să ne asigurăm că valorile atributului respectiv fac parte din mulţimea enumerată. Sau, în cazul unui domeniu definit implicit, se poate verifica dacă numărul unei facturi aparţine unui interval dat. B.   Integritatea entităţii – se referă la restricţii asupra cheii primare. Aceasta trebuie să fie unică  şi nenulă  (atributele cheii primare trebuie să fie diferite de valoarea null) . C.   Integritatea referirii – impune ca valorile cheii externe să figureze printre valorile cheii primare din relaţia referită (relaţia primară) .

15

CAP.2. ALGEBRA RELAŢIONALĂ este operaţia prin care se obţin datele dorite dintr-o bază de date, selectate conform unor criterii. Deoarece această operaţie este cea mai importantă operaţie, limbajele de manipulare a datelor sunt denumite şi limbaje de interogare.

  Interogarea (query)

Pentru formularea conceptuală a interogărilor în bazele de date relaţionale s-au dezvoltat două limbaje abstracte de interogare: algebra relaţională  şi calculul relaţional. introdusă de Codd în 1970, defineşte cadrul formal al limbajelor relaţionale pentru baze de date.   Algebra relaţională introduce o colecţie de operatori algebrici care se aplică relaţiilor (tabelelor). Fiecare operaţie din algebra relaţională are drept operanzi una sau mai multe relaţii, iar rezultatul este tot o relaţie. Această uniformitate (proprietatea algebrică de închidere) permite aplicarea de combinaţii de operatori relaţiilor.

  Algebra relaţională (relational algebra),

Prin analogie cu un compilator care, plecând de la un program sursă produce un program executabil, rezultatul compilării unei interogări (cereri) de către un SGBD relaţional este o expresie algebrică care va fi evaluată. În cadrul modelului relaţional se consideră limbaje relaţionale complete numai acele limbaje de interogare care permit implementarea tuturor operaţiilor prevăzute de unul din limbajele abstracte de interogare. Limbajele de interogare reale implementate în sistemele de baze de date relaţionale sunt limbaje definite pe baza limbajelor abstracte de interogare.

Cunoaşterea limbajului abstract de interogare bazat pe algebra relaţ ională  este obligatorie pentru înţelegerea aprofundată a modului de execuţie a interogărilor.  Algebra relaţională conţine două tipuri de operaţii:  operaţii pe mulţimi : reuniunea, intersecţia, diferenţa şi produsul cartezian. Pentru



a determina reuniunea, intersecţia şi diferenţa a două relaţii, acestea trebuie să fie compatibile cu reuniunea (trebuie să aibă acelaşi număr de atribute şi atributele corespondente să fie definite pe domenii compatibile, adică să aibă formatul datelor identic). operaţii relaţionale : selecţia, proiecţia, joncţiunea şi diviziunea.

reprezintă un ansamblu minimal de operaţii, în sensul că niciuna din operaţii nu poate fi exprimată ca o combinaţie a celorlalte operaţii. Pentru algebra relaţională există mai multe ansambluri minimale. În continuare prezentarea va considera ca operaţii de bază: trei operaţii pe mulţimi: reuniunea, diferenţa ,   produsul cartezian şi două operaţii relaţionale unare: selecţia şi proiecţia. Operatorii de intersecţie, joncţiune şi diviziune  pot fi obţinuţi din cei cinci operatori de bază. Operaţii de bază  -

 Notă. În definirea operatorilor algebrei relaţionale vom nota cu: t  – un tuplu din relaţia R t(A) – subtuplu din R relativ la atributul A.

16

Fiecare operator al algebrei relaţionale va fi descris prin  signatură. Signatura indică numărul şi tipul operanzilor, precum şi tipul rezultatului.

2.1. OPERATORII ALGEBREI RELAŢIONALE 1. UNION  –  reuniunea a două relaţii  R1 şi  R2 , compatibile cu reuniunea, este dată de mulţimea tuplurilor care aparţin fie relaţiei  R1 , fie relaţiei  R2 , fie ambelor relaţii. Tuplurile care aparţin ambelor relaţii se introduc în reuniune o singură dată, adică nu se duplică.  Re latie  Re latie

Signatura:  R1   R2

 R3

t | t   R1 sau t 

 Re latie

R2

 R3



 R1

R2

 Exemplu.

 R1

A

B

a c x

b d y

 R 2

A

B

d x h c

f  y r d

 R 3

A

B

a c x d h

b d y f  r

Sintaxa:

UNION (R1, R2)

- rezultatul este o relaţie.

 2.  DIFFERENCE – diferenţa a două relaţii R1 şi R2 , compatibile cu reuniunea, este dată de mulţimea tuplurilor care aparţin relaţiei R1 şi nu aparţin relaţiei R2.. Signatura:  R3

 R1  R2

 Re latie  Re latie t | t   R1 si t 

 Re latie

R2

17

 R3

_

 R1

R2

 Exemplu.

 R1

A

B

a c x

b d y

 R 2

A

B

d x h c

f  y r d

 R 3

A

B

a

b

Sintaxa:

- rezultatul este o relaţie.

DIFFERENCE (R1, R2)

 3.  INTERSECT  – intersecţia a două relaţii  R1 şi  R2 , compatibile cu reuniunea, este dată de mulţimea tuplurilor care aparţin atât relaţiei R1 , cât şi relaţiei R2. Signatura:  R3

 R1   R2

 Re latie  Re latie t | t   R1 si t 

 Re latie

R2

 R3



 R1

R2

18

 Exemplu.

 R1

A

B

a c x

b d y

 R 2

A

B

d x h c

f  y r d

 R 3

A

B

c x

d y

Sintaxa:

- rezultatul este o relaţie.

INTERSECT (R1, R2)

Observaţie.

Intersecţia poate fi exprimată cu ajutorul operaţiei de diferenţă  (operaţie de

 bază):  R  S

 R

 R

S

S

S  R

  4. PRODUCT  – produsul cartezian a două relaţii R1 şi R2 , produce o nouă relaţie care are ca atribute, reuniunea atributelor din cele două relaţii (atributele comune vor fi luate separat, calificările fiind făcute cu numele relaţiei), ia r fiecare element din  R1 se combină (concatenează) cu fiecare element din R2. Signatura:

 Re latie  Re latie

 R3

t 1 ,t 2 | t 1

 R1  R2

 Re latie

 R1 si t 2

R2

 R3

 R1

 R2

 Exemplu.

 R1

A

B

a c x

b d y

 R 2

A

a d

19

 R 3

R1. A

a c x a c x

B R 2.A

b d y b d y

a a a d d d

Sintaxa:

- rezultatul este o relaţie.

PRODUCT (R1, R2)

 5. SELECT  – este o operaţie unară de restricţie care selectează din tuplurile relaţiei  R, acele tu  pluri care satisfac o condiţie specificată. Condiţia este o expresie logică (predicat) specificată asupra atributelor relaţiei  R. Condiţia poate cuprinde nume de atribute, constante, operatori logici (and, or, not), operatori aritmetici de comparare (, =, ≤, ≥, ≠). Signatura: S

 Re latie  Expresie log ica

conditie  R

 Re latie

t | t   R si t   A

unde: t(A) θ α defineşte condiţia de selecţie (θ  este un operator aritmetic de comparare, iar α un tuplu care poate fi înlocuit de un atribut sau valoarea unui atribut). S

condiţie

 R  Exemplu. S

 R

 B '  x'   R

A

B

C

x t z c

y x x u

z a b w

S

A

B

C

t z

x x

a b

Sintaxa:

SELECT (R; condiţie)

- rezultatul este o relaţie.

20

Observaţii .

1. Această operaţie nu trebuie confundată cu instrucţiunea SELECT , care este instrucţiunea generală de interogare din limbajele de manipulare a datelor. 2. În termenii limbajului de interogare SQL, operaţia de selecţie realizează o 3.

decupare pe oriz ontală a tabelei operand R . Cardinalul relaţiei rezultat S este mai mic

sau egal decât cardinalul relaţiei  R. Egalitatea poate apare în situaţia în care condiţia este adevărată pentru toate tuplurile din relaţie.

6. PROJECT  - este o operaţie unară de restricţie prin care se selectează din relaţia  R, numai acele atribute specificate explicit în cadrul operaţiei. Relaţia rezultată P va avea ca atribute submulţimea selectată. Signatura:

 Re latie  Lista atribute

Fie  R [  A1 , A2 ,..., An ] şi P

 R

 A1 ,..., Ak 

 Re latie

 A1 , A2 ,..., An

t  a1 ,..., ak 

P

lista atribute

 R  Exemplu. P

 R

 A ,C   R

A

B

C

x z x z x

u x z y t

x y x y x

 P’ 

A

C

x z x z x

x y x y x

 P

A

C

x z

x y

Sintaxa:

- rezultatul este o relaţie.

PROJECT (R; lista atribute)

21

Observaţii .

1. Dacă în lista atributelor de proiecţie există o cheie a relaţiei operand  R, atunci relaţia rezultat are toate tuplurile distincte, adică relaţiile  R şi P vor avea acelaşi cardinal. 2. Dacă în lista atributelor de proiecţie nu există o cheie a relaţiei operand  R, atunci în relaţia rezultat P pot apare tupluri duplicate care vor fi eliminate. În exemplul   prezentat după eliminarea tuplurilor duplicate din relaţia intermediară P’  , s-a obţinut relaţia P care conţine două tupluri distincte. 3. Relaţia rezultat P are gradul k , dat de numărul atributelor din listă. 4. În termenii limbajului de interogare SQL, operaţia de proiecţie realizează o decupare pe verticală a tabelei operand R .

7. JOIN  –  este o operaţie definită pe două relaţii  R1 şi  R2. Relaţia rezultat  R3 va fi construită prin concatenarea unor tupluri din  R1 cu tupluri din  R2 care satisfac o anumită condiţie (condiţia de joncţiune - θ ) specificată explicit în cadrul relaţiei. C ondiţia de joncţiune - θ  este o expresie logică (predicat) specificată asupra atributelor relaţiilor  R1 şi  R2. C ondiţia de joncţiune - θ  poate cuprinde nume de atribute, constante, operatori logici (and, or, not), operatori aritmetici de comparare (, =, ≤, ≥, ≠). Signatura:

 Re latie  Re latie

Fie relaţiile  R1 [ A , B1 ] şi  R2 acelaşi domeniu. Atunci:  R3

 R1

 R2

Observaţie. Joncţiunea se cartezian şi selecţie astfel:  R1

 R2

exp resie

[ B2 ,C ]

 Re latie

, unde  B1 şi  B2 sunt atribute definite pe

t | t   R1  R2 si t   B1

t  B2

poate exprima în funcţie de operaţiile de bază:  produs  R1

R2

 R3

θ   R1

R2

22

 Exemplu.  R3

 R1

 R1

R2

A

B

C

a b d

x y z

c c g

unde θ : R1.A > R2.A  R 2

D

E

A

0 1 3 4 6 7

11 13 11 11 12 13

a a a d d c

 R 3

R1. A

b b b d d d d

B

C

D

E

y y y z z z z

c c c g g g g

0 1 3 0 1 3 7

11 13 11 11 13 11 13

R2. A

a a a a a a c

Sintaxa:

- rezultatul este o relaţie.

THETA - JOIN (R1, R2; θ - expresie)

În continuare se prezintă patru forme ale operaţiei de joncţiune. 7.1. EQUI  – JOIN  – este un caz particular al lui THETA – JOIN , când θ este egalitate.  Exemplu.  R3

 R1

 R1

R2

A

B

C

a b d

x y z

c c a

unde θ : R1.A = R2.A  R 2

D

E

A

0 1 3 4 6 7

11 13 11 11 12 13

a a a d d c

 R 3

R1. A

a a a d d

B

C

D

E

x x x z z

c c c a a

0 1 3 4 6

11 13 11 11 12

R2. A

a a a d d

Sintaxa:

EQUI - JOIN (R1, R2; θ - expresie)

- rezultatul este o relaţie.

7.2. NATURAL  –  JOIN  –  este o joncţiune pe egalitate (EQUI  –  JOIN) pentru toate atributele cu acelaşi nume din cele două relaţii, urmată de o proiecţie pe reuniunea atributelor celor două relaţii. În cazul  EQUI  –  JOIN  schema relaţiei rezultat conţine toate atributele celor doi operanzi şi rezultă că în fiecare tuplu al relaţiei rezultat vor exista cel puţin două valori egale. Introducerea joncţiunii naturale va elimina această redundanţă. Schema relaţiei rezultat  R3 se obţine prin reuniunea atributelor celor două relaţii R1 şi  R2 (atributele cu acelaşi nume se iau o singură dată), iar extensia relaţiei  R3 va conţine

23

tuplurile obţinute prin concatenarea tuplurilor din  R1 cu tupluri din  R2, care au aceleaşi valori pentru atributele cu acelaşi nume.  Joncţiunea naturală este joncţiunea cea mai utilizată în practică şi poate fi definită cu ajutorul operaţiilor de bază: proiecţie , selecţie şi produs cartezian .

Dacă se notează cu: θ  - condiţia de egalitate între valorile atributelor din intersecţia schemelor relaţiilor   R1 şi R2 (coloanele comune), atr - reuniunea atributelor celor două scheme (atributele cu acelaşi nume se iau o singură dată), atunci:  R3

 R1

 R2

 R1

atr 

R2

 Exemple.  A. Se dau relaţiile: R1[A , B, C ] şi R2 [ B, C, D]  R1 . B  R2 . B and   R1 .C   R2 .C  atr = A, B, C, D

 R1

A

B

C

a d b c

b b b a

c c f  d

 R 2

B

C

D

b b a

c c d

d e b

 R 3

A

B

C

D

a a d d c

b b b b a

c c c c d

d e d e b

 B. Se dau relaţiile: R1 [A , B, C ] şi R2 [ D, E, A]  R1 . A  R2 . A atr = A, B, C, D, E 

 R1

A

B

C

a b d

x y z

c c a

 R 2

D

E

A

0 1 3 4 6 7

11 13 11 11 12 13

a a a d d c

 R 3

A

B

C

D

E

a a a d d

x x x z z

c c c a a

0 1 3 4 6

11 13 11 11 12

Sintaxa: *

NATURAL - JOIN (R1, R2; atribut(e) joncţiune )- rezultatul este o relaţie.

* pentru mărirea clarităţii va apare atributul / atributele de joncţiune. 24

Observaţi e. Selecţia este un caz particular de  joncţiune naturală a unei relaţii cu o relaţie constantă. Înţelegem prin relaţie constantă  o relaţie care are un singur tuplu, eventual redus la o

singură valoare.

7.3. SEMI  – JOIN - este  joncţiunea dintre două relaţii R1 şi R2 , urmată de o proiecţie pe atributele relaţiei  R1. Semi  –  joncţiunea conservă atributele unei relaţii participante la  joncţiune ( R1). Semi  –  joncţiunea mai poate fi privită ca o generalizare a operaţiei de  selecţie , rezultatul fiind o selecţie asupra relaţiei R1 , realizată pe baza valorilor din R2 ale atributului de joncţiune.  R3

θ   R1  Exemplu.  R3

 R1

 R1

R2

A

B

C

a b d

x y z

c c a

R2

unde θ : R1.A = R2.A  R 2

D

E

A

0 1 3 4 6 7

11 13 11 11 12 13

a a a d d c

 R 3

A

B

C

a a a d d

x x x z z

c c c a a

Sintaxa:

SEMI - JOIN (R1, R2; θ - expresie)

- rezultatul este o relaţie.

Observaţie.

Considerăm   joncţiunea naturală dintre R1  B2 sunt atributele de joncţiune.   

[  A , B1 ]

şi  R2

[ B2 ,C ]

, unde  B1 şi

Dacă  B1 = B2 = Φ , atunci joncţiunea corespunde produsului cartezian. Dacă   A = C = Φ , atunci joncţiunea corespunde intersecţiei . Dacă  A = Φ sau C  = Φ (dar nu amândouă), atunci operaţia este o semi joncţiune.

25

7.4. OUTER – JOIN. Joncţiunea dintre două relaţii R1 şi R2 poate conduce la pierdere de tupluri, dacă relaţiile participante la joncţiune nu au proiecţii identice pe atributul de  joncţiune, adică nu au aceleaşi valori în relaţiile care se joncţionează. Relaţia rezultat  R3 conţine  joncţiunea naturală dintre R1 şi  R2, la care se adaugă tuplurile din  R1 şi R2, care nu au participat la joncţiune. În aceste tupluri se va atribui valorea null pentru atributele relaţiei corespondente.  R3

ext   R1

 Exemplu.  R3

 R1

 R1

ext  R2

A

B

C

a

x

c

b

y

c

d

z

R2

a

 R 2

D

E

A

0 1 3 4 6

11 13 11 11 12

a a a d d

7

13

c

 R 3 A a a a d d b c

B

C

D

E

x x x z z

c c c a a

0 1 3 4 6

11 13 11 11 12

y null

c null

null 7

null 13

Observaţii. În urma  joncţiunii naturale se pierd informaţiile din tuplurile < b, y, c > din  R1 şi < 7, 13, c > din  R2. Aceste tupluri se adaugă în cazul   joncţiunii externe şi se completează cu null pe atributele relaţiei corespondente. Sintaxa:

OUTER - JOIN (R1, R2; atribut(e) joncţiune)

- rezultatul este o relaţie.

 R1 [ A1 , 8.  DIVISION - este o operaţie definită pe două relaţii care au schema  A2  ,..., An] şi  R2 [ A p+1 , A p+2  ,..., An]. Relaţia rezultat  R3  R1 R2 are schema  R3 [ A1 ,  A2 ,..., A p] şi este formată din toate tuplurile care, concatenate cu fiecare tuplu din  R2 , dau întotdeauna un tuplu din R1.

 Notăm:

 ATR1 = { A1 , A2 ,..., A p+1 , A p+2 ,..., An}  ATR2 = { A p+1 , A p+2 ,..., An}

26

 Definiţia 1. t   R1

şi

 ATR2 t 1

R2

dacă t 2  R2

t 1

 ATR1  ATR2  R1

Signatura:

 ATR1  ATR2 t 1



t 2 .

  Definiţia 2. Diviziunea se poate exprima cartezian , diferenţă  şi proiecţie astfel:  R1  R2

R1 , astfel încât

în funcţie de operaţiile de bază:  produs

 ATR1  ATR2

 Re latie  Re latie

 ATR1  ATR2  R1

 R2

R1

 Re latie  R3

 R1  Problemă (   Exemplu de diviziune).

 R2

Fie relaţia R1 [K, P] unde atributul K  are ca valori codurile angajaţilor unui institut de cercetare, iar atributul P conţine codurile proiectelor în derulare. Un cercetător poate lucra la unul sau mai multe proiecte. Să se determine codurile angajaţilor angrenaţi simultan în proiectele P3 şi P4.  Rezolvare.

Construim relaţia R2 [P] care va conţine două tupluri: şi . Codurile angajaţilor care lucrează la proiectele P3 şi P4 sunt date de rezultatul diviziunii  R1

R2 .

 R1

K

P

17 17

P1 P2

17 17

P3 P4

53 53

P3 P4

80

P3

29 29

 R 2

P

P3 P4

P1 P3

27

Calculăm diviziunea conform definiţiei 2: Pasul 1. Calculăm Q1

Q1

 R1  R2

Q1

Pasul 2.

 ATR1  ATR2 R1

S

K

17 29 53 80

Q2

Calculăm S Q1 R2 K

P

17 29 53 80 17

P3 P3 P3 P3 P4

29

P4

80

P4

53

Pasul 3. Calculăm T 



S  R1

K

P

29 80

P4 P4

Pasul 5. Calculăm  R1  R2

 R1:R 2

Pasul 4.

Calculăm Q2 T 

P4

 ATR1

ATR2 T 

K

29 80

Q1

Q2

K

17 53   Rezultatul interogării: angajaţii şi .

cu codul şi lucrează simultan în proiectele

Sintaxa:

DIVISION (R1, R2)

- rezultatul este o relaţie.

28

2.2 OPERAŢII DE CALCUL

La operaţiile descrise anterior se pot adăuga operaţii de calcul pe relaţii . Aceste operaţii sunt justificate de numeroasele interogări (cereri) care necesită operaţii de calcul. Operaţiile de calcul sunt implementate în toate limbajele de interogare. Aceşti operatori de calcul formează deci o extensie a operatorilor de bază şi nu pot fi exprimaţi cu ajutorul acestora. 1. COUNT  - este o operaţie care permite numărarea tuplurilor dintr -o relaţie (liniilor  dintr-o tabelă) care au aceeaşi valoare pe atributul considerat (sau aceleaşi valori pe atributele considerate). Relaţia rezultantă va conţine numai atributul (atributele) de regrupare X i , iar tuplurile vor fi formate din valorile distincte şi numărul de apariţii.

 Notăm: T 

COUNT  X   ,..., X  (  R ) 1 n

, unde  X 1 ,...,X n sunt atributele de regrupare. T

Count...

R

Operatorul COUNT   Exemplu.

 R

A a b c d e f

B

C

n o n p m m

17 14 17 13 20 10

Count B(R)

B

Count

n m o p

2 2 1 1

Count B,C (R) B n m m o p

C

Count

17 20 10 14 13

2 1 1 1 1

Dacă nu este precizat niciun atribut de regrupare, operaţia COUNT va determina numărul de tupluri din relaţie: Count(R)

Count

6 Sintaxa:

COUNT (R; X1, X2, ..., Xn)

- rezultatul este o relaţie;

29

rezultatul este un număr (poate fi interpretat şi ca o relaţie cu un singur atribut şi un singur tuplu, care are ca valoare numărul de linii din tabelă). COUNT (R) -

  2. SUM  –  este o operaţie care permite efectuarea sumei valorilor atributului Y  pentru fiecare din valorile diferite ale atributelor de regrupare X 1 ,...,X n . Atributul Y trebuie să fie numeric.

 Notăm: T 

SUM  X   ,..., X  (  R ,Y  ) 1 n

,

unde  X 1 ,...,X n sunt atributele de regrupare.

Dacă nu este precizat niciun atribut de regrupare, operaţia SUM  va determina suma valorilor atributului Y. T

Sum...

R

Operatorul SUM   Exemplu.

 R

A a b c d e f

B

C

n o n p m m

17 14 17 13 20 10

Sum B(R,C)

B

Sum

n m o p

34 30 14 13

Sum(R,C)

Sum

91

Sintaxa:

SUM (R, Y; X1, X2, ..., Xn)

- rezultatul este o relaţie;

rezultatul este un număr (poate fi interpretat şi ca o relaţie cu un singur atribut şi un singur tuplu, care are ca valoare suma valorilor atributului Y din toate liniile tabelei). SUM (R, Y)

-

30

  3. MEAN   –  este o operaţie care permite efectuarea mediei aritmetice a valorilor atributului Y  pentru fiecare din valorile diferite ale atributelor de regrupare  X 1 ,...,X n . Atributul Y trebuie să fie numeric.

 Notăm: T   MEAN  X   ,..., X  (  R ,Y  ) 1 n

, unde  X 1 ,...,X n sunt atributele de regrupare.

Dacă nu este precizat niciun atribut de regrupare, operaţia  MEAN  va determina media aritmetică a valorilor atributului Y din toată relaţia. T

 Mean..

R

Operatorul MEAN   Exemplu.

 R

A a b c d e f

B

C

n o p n p p

17 9 21 13 20 10

 Mean B(R,C)

B

Sum

n o p

15 9 17

 Mean(R,C)

Sum

15

Sintaxa:

MEAN (R, Y; X1, X2, ..., Xn)

- rezultatul este o relaţie;

este un număr (poate fi interpretat şi ca o relaţie cu un singur atribut şi un singur tuplu, care are ca valoare media aritmetică a valorilor atributului Y din toate liniile tabelei). MEAN (R, Y)

- rezultatul

 4. MAX  şi  MIN  - este o operaţie care permite determinarea valorii maxime / minime a atributului Y  pentru fiecare din valorile diferite ale atributelor de regrupare  X 1 ,...,X n . Atributul Y trebuie să fie numeric.

31

 Notăm: T   MAX  X   ,..., X  (  R ,Y  ) 1 n

,

unde  X 1 ,...,X n sunt atributele de regrupare.

T   MIN  X   ,..., X  (  R ,Y  ) 1 n

,

unde  X 1 ,...,X n sunt atributele de regrupare.

Dacă nu este precizat niciun atribut de regrupare, operaţia   MAX (MIN) va determina maximul (minimul) valorilor atributului Y din toată relaţia.

T

 Max...

R

Operatorul MAX (MIN)

 Exemplu.

 R

A a b c d e f

B

C

n o p n p p

17 9 21 13 20 10

 Min B(R,C)

B

Min

n o p

13 9 10

 Max(R,C)

Max

21

Sintaxa:

MAX (R, Y; X1, X2, ..., Xn)

- rezultatul este o relaţie;

rezultatul este un număr (poate fi interpretat şi ca o relaţie cu un singur atribut şi un singur tuplu, care are ca valoare maximul valorilor atributului Y din toate liniile tabelei). MAX (R, Y) -

Observaţie.

Pentru operaţia MIN  sintaxa este analoagă.

32

CAP. 3. LIMBAJUL SQL

SQL (Structured Query Language - Limbaj Structurat de Interogare) este un limbaj de programare neprocedural specific bazelor de date. Limbajul SQL este standardizat  ANSI -ISO (fiind cel mai popular limbaj de manipulare a   bazelor de date relaţionale) şi poate fi utilizat în:  MySQL, SQL Server, MS Access, Oracle, DB2, etc.

Pe lângă versiunile standardizate ale limbajului SQL, există şi o mulţime de dialecte şi variante caracteristice diferitelor SGBD-uri. Limbajul SQL permite: manipularea structurii bazelor de date manipularea datelor conţinute

Principalele instucţiuni de definire a datelor sunt: CREATE TABLE ALTER TABLE DROP TABLE

3.1. Instrucţiunea CREATE TABLE Instrucţiunea CREATE TABLE este utilizată pentru a crea o nouă tabelă. Această opţiune este utilizată cu precădere dacă mediul de lucru nu posedă instrumente pentru crearea şi modificarea tabelelor într-o manieră mai facilă, aşa cum are spre exemplu  Microsoft   Access.

Sintaxa generală a instrucţiunii CREATE TABLE este: CREATE TABLE nume_tabela (c1 d1 [constrângeri_coloană], c2 d2 [constrângeri_coloană], ... cn dn [constrângeri_coloană], [constrângeri _coloană]) unde: c1, c2, ... , cn - reprezintă coloanele tabelei d1, d2, ... , dn - reprezintă domeniile fiecărui câmp   Exemplul 1. Dacă

dorim crearea unei tabele cu numele angajati1, cu următoarele

câmpuri:

33

vom avea: CREATE TABLE angajati1 (cod_sal int , nume varchar(250) , adresa varchar (250) , localitate varchar(250) , sal_brut int , cod_dep varchar (10), data_angajarii date)

 Re zultatul afişat pentru exemplul 1

3.2. Instrucţiunea ALTER TABLE Pentru modificarea strcturii unei tabele se utilizează instrucţiunea ALTER TABLE. Această instrucţiune permite adăugarea sau ştergerea unor câmpuri, modificarea domeniilor unor câmpuri, precum şi adăugarea sau ştergerea unor constrângeri ale tabelei. Instrucţiunea ALTER TABLE are următoarele sintaxe: - pentru adăugarea unui nou câmp: ALTER TABLE nume_tabela ADD nume_coloană domeniu - pentru ştergerea unui câmp ALTER TABLE nume_tabela DROP nume_coloană - pentru modificarea constrângerilor unu câmp ALTER TABLE nume_tabela ALTER COLUMN nume_coloană domeniu  Exemplul 2. Dacă dorim tip integer  vom avea:

adăugarea în tabela angajati1 a unui nou câmp numit bonus de

ALTER TABLE angajati1 ADD bonus int 

34

 Rezultatul afişat pentru exemplul 2   Exemplul 3. Dacă dorim, în tabela angajati1, modificarea câmpului numit bonus integer  în tip de caractere cu lungimea maxima de 10 caractere vom avea:

din

ALTER TABLE angajati1 ALTER COLUMN bonus varchar(10)

 Rezultatul afişat pentru exemplul 3   Exemplul 4.

Dacă dorim ştergerea din tabela angajati1 a câmpului numit bonus vom

avea: ALTER TABLE angajati1 DROP bonus

35

 Re zultatul afişat pentru exemplul 4

3.3. Instrucţiunea DROP TABLE

Pentru ştergerea unei tabele se utilizează instrucţiunea DROP TABLE. Această instrucţiune va face ştergerea efectivă a întregii tabele cu toate datele conţinute. Sintaxa generală a instrucţiunii DROP TABLE este: DROP TABLE nume_tabela  Exemplul 5.

Dacă dorim ştergerea tabelei angajati1 vom avea:

DROP TABLE angajati1

Principalele instrucţiuni de manipulare a datelor sunt: SELECT INSERT UPDATE DELETE 3.4. Instrucţiunea SELECT

Instrucţiunea SELECT este instrucţiunea de interogare a datelor din limbajul SQL. Utilizarea acestei instrucţiuni generează o tabelă virtuală, numită vedere (query) . În query se regăsesc toate informaţiile dorite din unul sau mai multe tabele ale bazei de date.

Sintaxa generală a instrucţiunii SELECT este: SELECT [DISTINCT] c1, c2, ... , cn [FROM t1, t2, ... , tm] [WHERE condiţie] [clauze secundare] unde: c1, c2, ... , cn - sunt coloanele dorite din tabelele specficate în clauza FROM t1, t2, ... , tm - sunt tabelele din care se face selecţia

36

Rezultatul selecţiei este format din coloanele c1, c2, ... , cn cu datele rezultate din produsul cartezian al tabelelor t1, t2, ... , tm   pentru care se respectă eventuala condiţie specificată în clauza WHERE.   

Clauza SELECT defineşte coloanele tabelei rezultat. Clauza FROM indică unu sau mai multe tabele ce conţin datele dorite. Clauza WHERE definşte condiţia sau condiţiile ce trebuie îndepline de datele din clauza SELECT.

Între clauzele secundare amintim: ORDER BY, GROUP BY, HAVING.

Exemplele următoare vor fi construite pentru tabela ANGAJATI:

Tabela ANGAJATI   Exemplul 6. Dacă dorim afişarea tuturor datelor din tabelă vom avea:

SELECT cod_sal, nume, adresa, localitate, sal_brut, cod_dep, data_angajarii FROM angajati sau SELECT * FROM salariati Observaţie. În acest al doilea caz, simblul * î nlocuieşte toate câmpurile din tabelă.   Exemplul 7. Dacă dorim afişarea mai mare de 1200 vom avea:

tuturor angajaţilor din localitatea Brasov ce au salariul

SELECT cod_sal, nume, localitate, sal_brut FROM angajati WHERE localitate="brasov" AND salariu_brut>1200

37

 Re zultatul afişat pentru exemplul 7    Exemplul 8. Dacă

dorim afişarea tuturor persoanelor angajate după data de 01.01.2009

vom avea: SELECT cod_sal, nume, data_angajarii FROM angajati WHERE data_angajarii>=#01-01-2009#

 Rezultatul afişat pentru exemplul 8

În clauza SELECT se pot utiliza următoarele funcţii agregat: COUNT (numără liniile din tabela rezultat) SUM (calculează suma valorilor dintr -o coloană) MAX (returnează valoarea maximă dintr -o coloană) MIN (returnează valoarea minimă dintr -o coloană) AVG (returnează media aritmetică a valorilor dintr -o coloană)  Exemplul 9. Dacă dorim afişarea numărului de angajaţi vom avea:

SELECT count(*) FROM angajati

 Rezultatul afişat pentru exemplul 9

38

 Exemplul 10. Dacă dorim afişarea mediei aritmetice a salariului brut vom avea:

SELECT AVG(sal_brut) FROM angajati

 Rezultatul afişat pentru exemplul 10

Instrucţiunea SELECT poate să nu conţină nici clauza FROM, dacă datele nu sunt conţinute de nicio tabelă. În acest caz, instrucţiunea SELECT conţine o listă de expresii  pe care le calculează.  Exemplul 11. Dacă dorim afişarea rezultatului

produsului 50x25 vom avea:

SELECT 50*25

 Rezultatul afişat pentru exemplul 11

Dacă se doreşte, în tabela rezultat se pot redenumi coloanele, sau se pot denumi anumite expresii, utilizând clauza AS.  Exemplul 12. Dacă

dorim afişarea rezultatului produsului 50x25, iar numele tabelei să fie REZULTAT vom avea: SELECT 50*25 AS rezultat

 Rezultatul afişat pentru exemplul 12 Clauza FROM este obligatorie, dacă în clauza SELECT se doreşte afişarea

unor coloane din tabele. Dacă se doreşte selectarea unor coloane din tabele diferite, acestea vor fi toate enumerate în clauza FROM, despărţite prin virgulă. În cazul în care un câmp apare în mai mult de o tabelă, atunci pentru a se cunoaşte din ce tabelă se doreşte respectivul câmp, la clauza FROM se va specifica şi numele tabelei de forma: nume_tabel.nume_câmp

39

În clauza WHERE se impun toate condiţiile necesare pentru datele din tabela rezultat. În clauza WHERE se pot utiliza şi operatorii logici (AND, OR, NOT) şi paranteze.  Exemplul 13. Dacă dorim afişarea angajaţilor din Brasov sau Predeal vom avea:

SELECT nume, localitate FROM angajati WHERE localitate="brasov" or localitate="predeal"

 Rezultatul afişat pentru exemplul 13

face ordonarea liniilor din tabela rezultat după coloana ce urmează clauzei. Implicit, ordonarea se face în ordine crescătoare sau alfabetică dacă tipul câmpului după care se face ordonarea este de tip text. În cazul în care se doreşte ordonare invers lexicografică (descrescătoare), atunci numele coloanei trebuie urmat de cuvântul DESC. Clauza ORDER BY

 Exemplul 14. Dacă dorim afişarea angajaţilor în ordine descrescătoare vom

SELECT nume FROM angajati ORDER BY nume DESC

 Rezultatul afişat pentru exemplul 14

40

avea:

Clauza GROUP BY se utilizează pentru gruparea rezultatelor funcţiilor agregat, în funcţie de valoarea unei sau mai multor coloane. Clauza GROUP BY se utilizează la sfârşitul instrucţiunii, fiind urmată de câmpul pentru care se face gruparea rezultatelor  funcţiei agregat.  Exemplul 15. Dacă dorim numărul de angajaţi din fiecare localitate vom avea:

SELECT COUNT(*) AS numar, localitate FROM angajati GROUP BY localitate

 Rezultatul afişat pentru exemplul 15

se utilizează în loc de clauza WHERE, atunci când în instrucţiune se utilizează funcţii agregat. Clauza HAVING este asemănătoare clauzei WHERE, adică introduce o condiţie pe care trebuie să o respecte liniile din rezultat şi în plus permite utilizarea funcţiilor agregat în expresia condiţională. Clauza HAVING

 Exemplul 16. Dacă dorim numărul de angajaţi din Brasov si Predeal vom avea:

SELECT COUNT(*) AS numar, localitate FROM angajati GROUP BY localitate HAVING localitate="brasov" OR localitate="predeal"

 Rezultatul afişat pentru exemplul 16 

Subinterogările reprezintă instrucţiuni SELECT în alte interogări de tip SELECT.  Numim această tehnică imbricare. Astfel, instrucţiunile SELECT se pot imbrica pe mai multe niveluri, o instrucţiune având ca argument rezultatul unei alte instrucţiuni, numită şi subinterogare.

41

  Exemplul 17. Dacă

dorim numele angajatului care are salariul egal cu salariul maxim

vom avea: SELECT nume, sal_brut FROM angajati WHERE sal_brut IN (SELECT MAX(sal_brut) FROM angajati)

 Rezultatul afişat pentru exemplul 17 

Clauza IN şi NOT IN specifică dacă valorile unui câmp aparţin unei mulţimi precizate. Această mulţime poate fi formată prin enumerarea elementelor sau printr -o subinterogare.  Exemplul 18. Dacă dorim numele angajaţilor din Brasov, Bucuresti şi Predeal vom avea:

SELECT nume, localitate FROM angajati WHERE localitate IN ("brasov", "bucuresti", "predeal")

 Rezultatul afişat pentru exemplul 18

3.5. Instrucţiunea INSERT

Instrucţiunea INSERT este utilizată pentru introducerea datelor în tabelă. Instrucţiunea INSERT are următoarea sintaxă: INSERT INTO nume_tabela (c1,c2,..., cn) VALUES (v1,v2,..., vn) unde: c1, c2, ... ,cn - reprezintă coloanele din tabelă în care se vor introduce datele v1, v2, ... ,vn - reprezintă valorile corespunzătoare coloanelor c1, c2, ... ,cn Observaţie . Între valori şi numele coloanelor trebuie să existe o corespondenţă directă.

42

  Exemplul 19. Dacă dorim introducerea în tabela ANGAJAŢI a unui datele: 18, EMILIA, str. O.Goga nr. 3, bucuresti, 1300, prod, 05.05.2009

nou angajat cu vom avea:

INSERT INTO TABLE angajati VALUES (18, "EMILIA", "str. O.Goga nr. 3", "bucuresti", 1300, " prod", #5/5/2009#);

 Rezultatul afişat pentru exemplul 19

Dacă se doreşte introducerea datelor în altă ordine decât cea implicită a coloanelor din tabelă, sau nu se cunoaşte această ordine, trebuie specificată ordinea câmpurilor după numele tabelei.   Exemplul 20. Dacă dorim introducerea în tabela ANGAJAŢI a unui nou angajat datele: 19, str. Agriselor, constanta, raluca, 1300, prod, 10.08..2009 vom avea:

cu

INSERT INTO angajati ( cod_sal, adresa, localitate, nume, sal_brut, cod_dep, data_angajarii ) VALUES (19, "str. Agriselor nr. 3", "constanta", "RALUCA", 1300, " prod", #10/8/2009#);

 Rezultatul afişat pentru exemplul 20

43

3.6. Instrucţiunea UPDATE

Instrucţiunea UPDATE permite modificarea valorilor din coloanele unei tabele pentru anumite condiţii. Sintaxa generală este: UPDATE nume_tabel SET c1=e1 [c2=e2 , ... ,n] [WHERE condiţie]

Clauza WHERE impune ca actualizarea valorilor să se facă doar asupra liniilor care îndeplinesc o serie de condiţii. Dacă lipseşte, se vor modifica toate liniile din tabelă.   Exemplul 21. Dacă

dorim modificarea tuturor salariilor angajaţilor din departamentul "prod" la valoarea de 1000 lei vom avea: UPDATE angajati SET sal_brut=1000 WHERE cod_dep="prod"

 Rezultatul afişat pentru exemplul 21

Valoarea poate fi schimbată şi cu valoarea unei expresii calculate. De exemplu:   Exemplul 22. Dacă dorim modificarea tuturor "conta" în sensul creşterii cu 15% vom avea:

salariilor angajaţilor din departamentul

UPDATE angajati SET sal_brut=sal_brut*115/100 WHERE cod_dep="conta"

44

 Rezultatul afişat pentru exemplul 22

3.7. Instrucţiunea DELETE

Instrucţiunea DELETE este utilizată pentru ştergerea uneia sau mai multor linii dintr -o tabelă. Sintaxa instrucţiunii DELETE este: DELETE FROM nume_tabela [WHERE condiţie] Utilizând această instrucţiune se vor şterge toate liniile care îndeplinesc condiţia specificată în clauza WHERE. Dacă este omisă clauza WHERE se vor şterge toate liniile din tabelă.   Exemplul 23. Dacă

dorim ştergerea tuturor angajaţilor din departamentul "conta" vom

avea: DELETE FROM angajati WHERE cod_dep="conta"

45

 Rezultatul afişat pentru exemplul 23

46

CAP. 4. NORMALIZAREA RELAŢIILOR 

1. INTRODUCERE

În activitatea de modelare a bazelor de date problema care se pune este de a stabili mulţimea de relaţii care realizează o reprezentare fidelă a schemei conceptuale, evitând incoerenţa, redundanţa şi   pierderile de informaţii. Relaţiile (tabelele) unei baze de date se pot stabili în mai multe moduri şi de aceea este necesar să existe criterii de evaluare a calităţii relaţiilor, pentru ca acestea să asigure integritatea datelor  şi   posibilităţi de interogare performante .

Teoria normalizării se bazează pe observaţia că anumite relaţii au posibilităţi mai bune de actualizare şi interogare decât alte relaţii echivalente (care conţin aceleaşi informaţii).   Normalizarea relaţiilor permite obţinerea unei baze de date în care să nu se manifeste anomalii de actualizare sau stocare. Pentru a înţelege nevoia de normalizare să considerăm relaţia  R care conţine informaţii legate de furnizori (cod_funizor, nume_furnizor, localitate, cod_loc) şi de produsele care le oferă (cod_produs, denumire, um, cantitate) . Un furnizor poate oferi mai multe produse, iar un produs poate fi oferit de mai mulţi furnizori.  R [cod_funizor, cod_produs, nume_furnizor, localitate, cod_loc, denumire, um, cantitate]

Cheia relaţiei R este (cod_funizor, cod_produs). cod_furnizor

cod_produs

F1 F2 F3 F1 F2

P13 P17 P13 P17 P29

nume_furnizor

localit

cod_loc

denumire

um

cant

Alfa SRL Beta SRL Gama SRL Alfa SRL Beta SRL

Brasov Cluj Sinaia Brasov Cluj

5000 3000 2555 5000 3000

xyz abc xyz abc efg

kg mp kg mp litru

200 600 800 400 600

Observăm că datele despre fiecare furnizor  (nume_furnizor, localitate, cod_loc) apar în fiecare tuplu în care se prezintă un produs oferit de un anumit furnizor. Analog, datele generale despre fiecare produs ( denumire, um) apar în fiecare tuplu în care un furnizor oferă respectivul produs. Aceste redundanţe conduc la creşterea spaţiului de memorare şi la anomalii de actualizare a relaţiei.   Anomalii de inserare –  nu se pot introduce datele generale despre un furnizor (nume_furnizor, localitate, cod_loc), dacă nu există cel puţin un produs pe care acesta

să-l ofere. O altă anomalie de inserare – nu putem introduce informaţiile generale despre un produs ( denumire, um), dacă nu există un furnizor care să-l ofere. Aceste anomalii apar datorită restricţiei de integritate care impun ca într-o relaţie atributele cheie nu pot să aibă valoarea null.

47

 Anomalii de ştergere –  dacă

se şterg toate informaţiile legate de un furnizor, de exemplu firma nu mai lucrează cu furnizorul F2, atunci tuplurile cu cheile şi vor fi şterse. Se pierd astfel informaţiile generale legate de produsul P29, (denumire, um).

  Anomalii de actualizare –  orice

modificare a unei informaţii generale legate de un furnizor trebuie să se propage în toate tuplurile în care apare acel furnizor. Aceasta măreşte timpul de actualizare şi creşte riscul de incoerenţă al datelor. Acelaşi tip de anomalie apare şi în cazul modificării unei informaţii generale despre un produs. Teoria normalizării are la bază analiza dependenţelor dintre atributele care sunt la originea fenomenelor de redundanţă şi propune două scheme de modelare a bazelor de date relaţionale fără anomalii sau pierderi de informaţii [Popescu, 1996]: 



 –  schema relaţiei universale (relaţia universală  este relaţia care conţine toate atributele care modelează sistemul real cercetat) se descompune prin proiecţii succesive în subrelaţii; descompunerea se opreşte când continuarea ar conduce la pierderi de informaţii; procesul de descompunere este reversibil, ceea ce garantează că relaţia de plecare (universală) poate fi regăsită prin utilizarea operatorului de joncţiune şi astfel nicio informaţie nu a fost pierdută; schema sintezei  –   porneşte de la o mulţime de atribute independente; pe baza   proprietăţilor de semantică şi legături între atribute se compun relaţii care să evite eventualele anomalii. schema descompunerii

Procesul de ameliorare a schemei conceptuale trebuie să satisfacă următoarele cerinţe:  să asigure conservarea datelor , adică în schema conceptuală finală trebuie să regăsim toate datele din cadrul schemei iniţiale;  să asigure conservarea dependenţelor  dintre date, adică în schema conceptuală finală fiecare dependenţă trebuie să aibă determinantul şi determinatul în schema aceleiaşi relaţii;  să reprezinte o descompunere minimală  a relaţiilor iniţiale, adică niciuna din relaţiile care compun schema finală nu trebuie conţinută într -o altă relaţie din această schemă. Pentru ca informaţiile dintr -o bază de date să fie prelucrate cât mai simplu este necesar ca relaţiile să verifice anumite condiţii, altfel spus să aibă un anumit grad de normalizare . Forma normală (Normal Form) a unei relaţii presupune anumite condiţii pe care trebuie să le îndeplinească valorile atributelor şi dependenţele funcţionale definite pe aceea relaţie. E.F.Codd a definit primele trei forme normale (1NF, 2NF, 3NF). Ulterior a fost definită mai complet 3NF şi a primit numele de forma normală Boyce-Codd (BCNF). Formele normale superioare, definite de R. Fagin, se referă la dependenţel e multivaloare (4NF) şi dependenţele de joncţiune (5NF). De remarcat că BCNF, 4NF şi 5NF corespund definiţiei unice: orice determinant al unei dependenţe este o cheie . Diferenţa este dată de faptul că

48

  în cazul BCNF este vorba de dependenţa funcţională , în cazul 4NF de dependenţa multivaloare, iar în cazul 5NF de dependenţa de joncţiune [Fotache, 2005].

În continuare ne limităm prezentarea la primele trei forme normale definite de Codd, considerate în multe lucrări de specialitate a fi suficiente pentru proiectarea corectă a bazelor de date. 2.

DEPENDENŢE FUNCŢIONALE

  Dependenţa funcţională reprezintă dependenţa dintre date prin care se poate identifica un

atribut sau grup de atribute prin intermediul altui atribut sau grup de atribute.  Definiţia 4.1.   Dependenţa funcţională. Dată o relaţie R, spunem că un atribut sau un grup de atribute Y  depinde funcţional  de un atribut sau grup de atribute X, dacă pentru fiecare valoare a lui X se asociază o singură valoare a lui Y  în orice tuplu din R.

Formal: t 1 ,t 2

 R avem :

 X  t 1

 X  t 2

Y  t 1

Y  t 2

sau echivalent: pentru orice tupluri , din  R, x = x‟ → y = y‟.

Vom spune că “X determină pe Y” sau “Y depinde funcţ ional de X ” şi vom nota  X → Y . Atributul (grupul de atribute) X  se numeşte determinant, iar atributul (grupul de atribute) Y se numeşte determinat, adică: determinant → determinat.

În cazul exemplului prezentat în introducere identificăm următoarele dependenţe funcţionale: (1) (2) (3) (4) (5) (6) (7) (8) (9) (10) (11) (12)

(cod_furnizor, cod_produs) → nume_furnizor  (cod_furnizor, cod_produs) → localitate (cod_furnizor, cod_produs) → cod_loc (cod_furnizor, cod_produs) → denumire (cod _furnizor, cod_produs) → um (cod _furnizor, cod_produs) → cantitate cod _furnizor → nume_furnizor  cod _furnizor → localitate cod _furnizor → cod_loc cod_produs → denumire cod_produs → um cod_loc → localitate

49

Tipuri de dependenţe funcţionale

 Definiţia 4.2. Dependenţa funcţională trivială . O dependenţă funcţională X → Y este trivială  dacă Y 

 X  .

 Definiţia 4.3. Dependenţa funcţională   parţială (dfp). O dependenţă funcţională X → Y este parţială dacă  X 1  X  a.i .  X 1 Y  Vom numi dependenţa funcţională  X1 → Y, dependenţă argument dfp.  Exemplu.

Dependenţa funcţională: (cod_furnizor, cod_produs) → nume_furnizor  este parţială deoarece se manifestă şi dependenţa argument dfp : cod_furnizor → nume_furnizor  Definiţia 4.4. Dependenţa funcţională completă (totală) (dfc) . O dependenţă funcţională   X → Y este completă (totală)  X 1

 X  a .i .  X 1

dacă nu există



 Definiţia 4.5. Dependenţa funcţională tranzitivă (dft). O dependenţă funcţională  X  → Y  este tranzitivă  dependenţele funcţionale: Z → X şi Z → Y .

dacă se manifestă concomitent

 Exemplu.

Dependenţa funcţională: cod_loc → localitate este tranzitivă deoarece se manifestă concomitent şi dependenţele: cod_furnizor → localitate cod_furnizor → cod_loc Observaţie. Cheia unei relaţii  poate fi definită cu ajutorul dependenţelor funcţionale astfel:  X este o cheie pentru relaţia R [ X, Y ] dacă Y depinde funcţional de X  adică: X → Y . Cheia X este minimală  dacă dependenţa funcţională X → Y  este completă .

3.

PRIMA FORMĂ NORMALĂ (1NF)

  Definiţia 4.6. O

relaţie este în   prima formă normală notată (1NF), dacă fiecare din atributele sale are un domeniu atomic (monovaloare). O relaţie în 1NF nu conţine grupuri repetitive. Observaţie.

 Noţiunea de grup repetitiv (mulţime de valori) nu există în modelul relaţional. O relaţie nenormalizată poate fi transformată într -o relaţie 1NF , înlocuind atributul compus prin atributele simple corespunzătoare (spargerea relaţiei) sau duplicând tuplele de atâtea ori câte valori există pentru un atribut dat (spargerea grupului repetitiv).  Exemple de relaţii nenormalizate:

50

a) relaţie în care un atribut este o relaţie ZBOR [NR_ZBOR, AVION] cu AVION [tip_nava, capacitate] ZBOR

NR_ZBOR

102 107 108 109 110

AVION

(B707, 150) (B737, 180) (AIRB320, 250) (B707, 150) (B747, 300)

Observăm că atributul compus  AVION  din relaţia  ZBOR este de fapt o relaţie cu două atribute tip_nava şi capacitate (număr de locuri). Rezultatul trecerii în 1NF prin spargerea relaţiei AVION este: ZBOR 1

NR_ZBOR

102 107 108 109 110

TIP NAVA

CAPCITATE

B707 B737 AIRB320 B707 B747

150 180 250 150 300

b) relaţie în care un atribut este un ansamblu de valori CATALOG [Nume, Note] CATALOG

NUME

Einstein Freud

NOTE

8, 6 7, 9, 5

Rezultatul trecerii în 1NF, în situaţia că numărul maxim de note este cunoscut, prin  spargerea relaţiei NOTE este: CATALOG 1

NUME

Einstein Freud

NOTA 1

NOTA 2

NOTA 3

8 7

6 9

null 5

În cazul spargerii grupului repetitiv NOTE  se obţine relaţia: CATALOG 2

NUME

Einstein Einstein Freud Freud Freud

NOTA

8 6 7 9 5

51

Teorema 1 (de eliminare a grupurilor repetitive) Dacă R [ A1 , A2 , ..., An] este o relaţie în care Am+1 , Am+2 , ..., An formează un grup repetitiv , şi { A1 , A2 , ..., A p} cu p < m este o cheie primară, atunci relaţia R se poate descompune în

două relaţii fără grupuri repetitive şi pierdere de informaţii, astfel:  R1 [ A1 , A2 , ..., Am] =

 A1 , A2 ,...,Am

 R2 [ A1 , A2 , ..., A p , Am+1 ,..., An] =

 R  A1 , A2 ,...,  A p  , Am 1 ,..., An

 R

 Algoritmul 1NF - de aducere a unei relaţii nenormalizate în 1NF  (eliminarea atributelor compuse şi repetitive)

Se trec în relaţie în locul atributelor compuse componentele acestora ca atribute simple. Pasul 2. Se trec grupurile de atribute repetitive, fiecare într-o nouă relaţie. Pasul 3. Se introduce în schema fiecărei noi relaţii create la Pasul 2 cheia primară a relaţiei din care a fost extras grupul repetitiv. Pasul 4. Se stabileşte cheia primară a fiecărei noi relaţii create la Pasul 2. Aceasta va fi compusă din cheia introdusă la Pasul 3 (cheia primară iniţială) precum şi din unul sau mai multe atribute proprii relaţiei. Pasul 1.

 Exemplu.

Pentru gestionarea cărţilor dintr -o bibliotecă se consideră relaţia: CARTE [ cota, nume_autori, titlul, editura, an_apariţie, ISBN, cuvinte_cheie] Cota

Nume autori

Titlul

Editura

An apar.

ISBN

Cuvinte-cheie

proiectarea bazelor de date, SQL Server 2008, Oracle analiza SI, proiectarea SI, implementarea SI, auditul SI

C104 Ionescu M Popescu F Georgescu L

Baze de date

Economica

2009

978-9738204-417

C289 Marinescu A

Sisteme informatice

Polirom

2007

978-9731978-895

În relaţia CARTE (nenormalizată) există două grupuri de atribute repetitive: nume_autori şi cuvinte_cheie care crează mari greutăţi în stocarea informaţiilor şi r ealizarea interogărilor . Alegem drept cheie primară atributul COTA. Aplicarea   Algoritmului 1NF  conduce la următoarele relaţii: CARTE 1 [ cota, titlul, editura, an_apariţie, ISBN] AUTORI [ cota, nume autori] CUVINTE CHEIE [ cota, cuvinte cheie]

52

CARTE 1 Cota

C104 C289

Titlul

Baze de date Sisteme informatice

Editura

Economica Polirom

An aparitie

ISBN

2009 2007

978-973-8204-41-7 978-973-1978-89-5

AUTORI Cota

C104 C104 C104 C289

Nume autori

Ionescu M Popescu F Georgescu L Marinescu A

CUVINTE CHEIE Cota

C104 C104 C104 C289 C289 C289 C289

Cuvinte cheie

proiectarea bazelor de date SQL Server 2008 Oracle analiza SI proiectarea SI implementarea SI auditul SI

4. A DOUA FORMĂ NORMALĂ (2NF)

  Definiţia 4.7. O relaţie (1NF) şi oricare dintre

este în a doua   formă normală notată (2NF), dacă relaţia este în atributele care nu aparţin cheii primare este complet dependent

funcţional de cheie. O relaţie în 2NF  nu conţine dependenţe funcţionale parţiale între atributele cheie şi celelate atribute. Observaţie.

 Exemplu.

Redundanţe care apar în cazul unei relaţii 1NF , care nu este 2NF .

Fie R [ A, B, C, D] în care cheia primară este ( A, B) şi se manifestă dependenţele: ( A, B) → D

( A, B) → C 

 B → C 

A

B

C

D

a1 a2 a3 a4

b1 b1 b2 b2

c1 c1 c3 c3

d1 d2 d2 d3

53

Teorema 2 ( de descompunere fără pierdere de informaţie) Fie  R [ A1 , A2  , ..., An] o relaţie în 1NF  şi K = { A1 , A2  , ..., A p} cu   p < n este o cheie  A  A1 , A2 ,..., An  , K  , adică  β  este un  primară . Presupunem că există

atribut noncheie şi α → β  cu K (  β  este complet dependent funcţional de o submulţime strictă de atribute din cheie). Atunci dependenţa α → β  se poate elimina descompunând relaţia R în următoarele două relaţii:  R1

 R

 R2  A

 A

 R

Observaţie. Conform teoremei de mai sus, relaţia  R [ A, B , C, D] din exemplul precedent, în care se manifestă dependenţa parţială  (  A, B) → C  se descompune fără pierdere de

informaţie în:  R1 [ B, C ]

şi

R2 [ A, B, D]

 Algoritmul 2NF - de aducere a une i relaţii 1NF în 2NF  (eliminarea dependenţelor funcţionale parţiale )

Pentru fiecare dependenţă funcţională argument  dfp se crează o nouă relaţie, cu schema constituită din determinantul şi determinatul acestei dependenţe. Dacă există mai multe d ependenţe funcţionale argument dfp cu acelaşi determinant se va crea o singură relaţie formată din determinant luat o singură dată şi determinaţii dependenţelor considerate. Pasul 2. Din relaţia iniţială se elimină atributul / atributele care formează dete rminatul dependenţelor funcţionale argument dfp . Pasul 3. Se stabileşte cheia primară a fiecărei noi relaţii create la Pasul 1. Aceasta va fi formată din determinantul dependenţei funcţionale argument  dfp. Pasul 1.

 Aplicaţie.

Pentru evidenţa autoturismelor închiriate de o firmă clienţilor se consideră relaţia: AUTO [ nr_client, nume_client, adresa, nr_auto, marca, data ] Nr client

C234 C145 C679 C089 C445

Nume client

Smith A Lungu M Tudor A Stan D Bondescu I

Adresa

Nr auto

Marca

Data

Castelului 12, Brasov Libertatii 14, Predeal Armoniei 23, Iasi Sadoveanu 45, Cluj Caragiale 66, Arad

BV 21 XXI BV 19 XIX CJ 12 XII CT 07 VII BV 61 LXI

Logan 1.4 Ford Focus Audi A6 Opel Astra VW Golf

22.05.2009 17.04.2009 23.05.2009 07.04.2009 26.04.2009

54

Cheia relaţiei este (nr_client, nr_auto), iar dependeţele funcţionale care se manifestă sunt: (1) (nr_client, nr_auto) → nume_client (2) (nr_client, nr_auto) → adresa (3) (nr_client, nr_auto) → marca (4) (nr_client, nr_auto) → data (5) nr_client → nume_client (6) nr_client → adresa (7) nr_auto → marca Observa ţie.

-

relaţia AUTO este în forma normală 1; dependenţa funcţională (1) este parţială deoarece se manifestă şi d.f.argument dfp (5); dependenţa funcţională (2) este parţială deoarece se manifestă şi d.f.ar gument dfp (6); dependenţa funcţională (3) este parţială deoarece se manifestă şi d.f.argument dfp (7).

Aplicarea Algoritmului 2NF - de aducere a unei relaţii 1NF în 2NF  bazat pe Teorema 2, conduce la spargerea relaţiei AUTO, în trei relaţii în 2NF : EVIDENTA [ nr_client, nr_auto, data ] CLIENT [ nr_client, nume_client, adresa ] AUTO [ nr_auto, marca ]

EVIDENŢA Nr client

C234 C145 C679 C089 C445

Nr auto

Data

BV 21 XXI BV 19 XIX CJ 12 XII CT 07 VII BV 61 LXI

22.05.2009 17.04.2009 23.05.2009 07.04.2009 26.04.2009

CLIENT Nr client

C234 C145 C679 C089 C445

Nume client

Smith A Lungu M Tudor A Stan D Bondescu I

Adresa

Castelului 12, Brasov Libertatii 14, Predeal Armoniei 23, Iasi Sadoveanu 45, Cluj Caragiale 66, Arad

AUTO Nr auto

Marca

BV 21 XXI BV 19 XIX CJ 12 XII CT 07 VII BV 61 LXI

Logan 1.4 Ford Focus Audi A6 Opel Astra VW Golf 

55

5. A TREIA FORMĂ NORMALĂ (3NF)

  Definiţia 4.8. O relaţie (2NF) şi oricare dintre

este în a treia  formă normală  notată (3NF), dacă relaţia este în atributele care nu aparţin cheii primare nu depinde tranzitiv de

cheie. Observaţie.

O altă exprimare: orice atribut ce nu aparţine cheii primare depinde direct de

cheie. Fie R o relaţie, K cheia primară şi presupunem că β este un atribut ce depinde tranzitiv de cheie. Aceasta înseamnă că există un atribut α, astfel încât există dependenţele funcţionale: K → α şi α → β  Deoarece relaţia  R este în 2NF  rezultă că  β  este complet dependent funcţional de cheia relaţiei şi deci K  , adică α este un atribut noncheie.  Exemplu.

Redundanţe care apar în cazul unei relaţii 2NF , care nu este 3NF .

Fie R [ A, B, C ] în care cheia primară este A şi se manifestă dependenţele:  A → B

A → C 

 B → C 

A

B

C

a1 a2 a3 a4

b1 b1 b2 b2

c1 c1 c2 c2

Teorema 3 - Casey  –  Delobel (de descompunere fără pierdere de informaţie) Fie  R [ A1 , A2  , ..., An] o relaţie în 2NF  şi K  este o cheie primară . Dacă există atributul  A  A1 , A2 ,..., An  , K  , şi α → β  cu K  ( β depinde tranzitiv de cheie),

atunci dependenţa α → β  se poate elimina descompunând relaţia R în următoarele două relaţii:  R1  R2  A

 R  A

 R

Observaţie. Conform teoremei de mai sus, relaţia  R [  A, B, C ] din exemplul precedent, în care se manifestă dependenţa tranzitivă B → C  se descompune fără pierdere de

informaţie în:  R1 [ B, C ]

şi

 R2 [ A, B]

56

 Algoritmul 3NF - de aducere a unei relaţii 2NF în 3NF  (eliminarea dependenţelor funcţionale tranzitive )

Pentru fiecare dependenţă funcţională  tran zitivă  din cadrul relaţiei considerate, se crează o nouă relaţie, formată din atributele implicate în această dependenţă. Pasul 2. Se stabileşte cheia primară a fiecărei noi relaţii create la Pasul 1. Pasul 3. Se introduc în relaţia iniţială în locul atributelor transferate la Pasul 1, cheile primare detrminate la Pasul 2. Pasul 1.

 Aplicaţie.

Pentru evidenţa rezultatelor examenului de licenţă, se consideră relaţia: EXAMEN [nr_matricol, nume_student, program_studiu, nota, prof_coordonator, catedra] Nr matricol

2345 5678 7890 4567 3456

Nume student

Ionescu M Popescu V Georgescu D Constantinescu Marinescu H

Program

ECTS MK CIG FB CIG

Nota

9.45 9.30 9.70 9.60 9.20

Prof coord

Zamfir R Teodorescu N Oancea C Cristea D Andreescu M

Catedra

MKTS MKTS FBC FBC MNIE

Cheia relaţiei este nr_matricol, iar dependeţele funcţionale care se manifestă sunt: (1) nr_matricol → nume_student (2) nr_matricol → program_studii (3) nr_matricol → nota (4) nr_matricol → prof_coordonator (5) nr_matricol → catedra (6) prof_coordonator → catedra Observa ţie.

- relaţia EXAMEN este în 2NF , deoarece toate valorile atributelor sunt atomice, nu avem atribute repetitive (1NF) şi nu există dependenţe funcţionale parţiale (2NF). - dependenţele (4) şi (6) arată ca atributul catedra depinde tranzitiv de cheia primară a relaţiei. Aplicarea Algoritmului 3NF - de aducere a unei relaţii 2NF în 3NF  bazat pe Teorema 3, conduce la spargerea relaţiei EXAMEN, în două relaţii în 3NF : REZULTAT [nr_matricol, nume_student, program_studiu, nota, prof_coordonator] PROFESOR [prof_coordonator, catedra]

57

REZULTAT Nr matricol

2345 5678 7890 4567 3456

Nume student

Ionescu M Popescu V Georgescu D Constantinescu Marinescu H

Program

ECTS MK CIG FB CIG

Nota

9.45 9.30 9.70 9.60 9.20

Prof coord

Zamfir R Teodorescu N Oancea C Cristea D Andreescu M

PROFESOR Prof coord

Zamfir R Teodorescu N Oancea C Cristea D Andreescu M

Catedra

MKTS MKTS FBC FBC MNIE

 Rezumat.

toate atributele sunt atomice şi nu există atribute repetitive 1NF + orice atribut noncheie este complet dependent funcţional de cheie (nu există dependenţe funcţionale parţiale) 3NF 2NF + atributele care nu aparţin cheii nu depind tranzitiv de cheie (nu există dependenţe funcţionale tranzitive / nu există dependenţe funcţionale într e atributele noncheie) 1NF 2NF

58

CAP. 5. APLICAŢII FIRMA DE COMERCIALIZARE PRODUSE ELECTRONICE

FURNIZORI [cod_furnizor, nume_furnizor, CIF, adresa, localitate, cont, tel, email] (FURNIZ)

FACTURI_PRIMITE [nr_factura, cod_furnizor, data_factura, valoare, tva_deductibil] (FACTP)

CLIENTI [cod_client, tip_client, nume_client, adresa, localitate] (CLI)

PRODUSE [ cod_produs, denumire, um, grupa] (PROD)

FACTURI_EMISE [nr_factura, data_factura, cod_client, valoare, tva_colectat] (FACTE)

DETALII_FACTURA [nr_factura, cod_produs, cantitate, pret_unitar] (FACTD)

 P1. Cum se numesc furnizorii din Braşov ? Lista: |cod_furnizor | nume_furnizor | CIF | AR

R1 = SELECT  (FURNIZ; localitate = “Brasov”) R2 = PROJECT (R1; cod_furnizor, nume_furnizor, CIF) MS ACCESS

SELECT cod_furnizor, nume_furnizor, CIF FROM furniz WHERE localitate="Brasov";  P2. Lista cu numerele şi valorile facturilor primite, ce au fost întocmite după 1.03.2009  şi au o valoare mai mare de 500 lei ? AR

R1 = SELECT  (FACTP; (data_factura > 1.03.2009) and (valoare>500)) R2 = PROJECT (R1; nr_factura, valoare) MS ACCESS

SELECT nr_factura, valoare FROM factp WHERE data_factura>#3/1/2009# AND valoare>500;

59

 P3. Care sunt localităţile în care firma îşi are partenerii de afaceri ? C âţi  clien ţi există în fiecare localitate ? AR

R1 = PROJECT (FURNIZ; localitate) R2 = PROJECT (CLI; localitate) R3 = UNION (R1, R2) Q1 = COUNT (CLI; localitate) Q2 = PROJECT  (Q1; localitate, count) MS ACCESS

SELECT distinct localitate FROM furniz UNION (SELECT localitate FROM cli); SELECT count(*), localitate FROM cli GROUP BY localitate;

 Dacă dorim să vedem câţi parteneri comerciali avem in fiecare localitate vom avea: SELECT Count(*) AS nr, total.localitate FROM [SELECT cod_furnizor AS cod_partener, localitate FROM furniz UNION (SELECT cod_client AS cod_partener, localitate FROM cli)]. AS total GROUP BY total.localitate;  P4. Lista facturilor primite în acest an. Lista: |nr_factura | data_factura | cod_furnizor | nume_furnizor | AR

R1 = SELECT  (FACTP; data_factura > 1.01.2009) R2 = NATURAL JOIN (R1, FURNIZ; cod_furnizor) R3 = PROJECT (R2; nr_factura, data_factura, cod_furnizor, nume_furnizor) MS ACCESS

SELECT nr_factura, data_factura, factp.cod_furnizor, nume_furnizor FROM furniz, factp WHERE factp.cod_furnizor=furniz.cod_furnizor AND data_factura>#1/1/2009#; Sau: SELECT nr_factura, data_factura, factp.cod_furnizor, nume_furnizor FROM furniz, factp

60

WHERE factp.cod_furnizor=furniz.cod_furnizor AND YEAR(data_factura)=YEAR(DATE());  P5. De la care furnizori s-au primit facturi întocmite în data de 4.03.2009? Lista: |nr_factura | cod_furnizor | nume_furnizor | AR

R1 = SELECT  (FACTP; data_factura = 4.03.2009) R2 = NATURAL JOIN (R1, FURNIZ; cod_furnizor) R3 = PROJECT (R2; nr_factura, cod_furnizor, nume_furnizor) Sau: Q1 = NATURAL JOIN (FACTP, FURNIZ; cod_furnizor) Q2 = SELECT  (Q1; data_factura = 4.03.2009) Q3 = PROJECT  (Q2; nr_factura, cod_furnizor, nume_furnizor) MS ACCESS

SELECT nr_factura, factp.cod_furnizor, nume_furnizor FROM factp, furniz WHERE furniz.cod_furnizor=factp.cod_furnizor AND data_factura=#3/4/2009#; Sau: SELECT nr_factura, factp.cod_furnizor, nume_furnizor FROM factp INNER JOIN furniz ON furniz.cod_furnizor=factp.cod_furnizor WHERE data_factura=#3/4/2009#;  P6. În ce localităţi se găsesc clienţii care au cumpărat produsul ‘XYZ’? AR

R1 = SELECT  (PROD; denumire = „XYZ‟) R2 = NATURAL JOIN (R1, FACTD; cod_produs) R3 = NATURAL JOIN (R2, FACTE; nr_factura) R4 = NATURAL JOIN (R3, CLI; cod_client) R5 = PROJECT (R4; localitate) MS ACCESS

SELECT DISTINCT localitate FROM cli, prod, facte, pdfe WHERE facte.cod_client=cli.cod_client AND facte.nr_factura=pdfe.nr_factura AND pdfe.cod_produs=prod.cod_produs AND prod.denumire="xyz";

61

 P7. În ce localităţi s-a vândut produsul ‘XYZ’ în perioada 15.04.2009 – 30.04.2009 ? AR R1 = SELECT (PROD; denumire = „XYZ‟) R2 = NATURAL JOIN  (R1, FACTD; cod_produs) R3 = SELECT (FACTE; (data_factura>14.04.2009) R4 = NATURAL JOIN  (R2, R3; nr_factura) R5 = NATURAL JOIN  (R4, CLI; cod_client) R6 = PROJECT (R5; localitate)

and (data_factura=#4/15/2009# AND data_factura1.01.2009) R3 = PROJECT (R2; nr_factura, cod_produs) R4 = PROJECT (PROD; cod_produs) R5 = DIVISION (R3, R4) MS ACCESS

SELECT nr_factura, data_factura FROM facte WHERE data_factura>=#01-01-2009# AND nr_factura IN (SELECT pdfe.nr_factura FROM pdfe, facte GROUP BY pdfe.nr_factura HAVING count(*)=(SELECT COUNT(*) FROM prod));  P10. Care sunt numerele facturilor emise, în care s-a consemnat vânzarea simultană a  produselor ‘XYZ’ şi ‘ABC’ ? AR R1 = SELECT (PROD; denumire = „XYZ‟) R2 = NATURAL JOIN  (R1, FACTD; cod_produs) R3 = PROJECT (R2; nr_factura)

R4 = SELECT (PROD; denumire = „ABC‟) R5 = NATURAL JOIN  (R4, FACTD; cod_produs) R6 = PROJECT (R5; nr_factura) R7 = INTERSECT (R3, R6) Varianta 2 R1 = PROJECT (FACTD; nr_factura, cod_produs) R2 = SELECT  (PROD; (denumire = „XYZ‟) or (denumire = „ABC‟)) R3 = PROJECT (R2; cod_produs) R4 = DIVISION  (R1, R3) MS ACCESS

SELECT DISTINCT facte.nr_factura FROM cli, prod, facte, pdfe WHERE facte.cod_client=cli.cod_client AND facte.nr_factura=pdfe.nr_factura AND pdfe.cod_produs=prod.cod_produs AND (prod.denumire="xyz" OR prod.denumire="abc");

63

Sau: SELECT DISTINCT facte.nr_factura FROM cli, prod, facte, pdfe WHERE facte.cod_client=cli.cod_client AND facte.nr_factura=pdfe.nr_factura AND pdfe.cod_produs=prod.cod_produs AND prod.denumire IN ("xyz","abc"); Sau: SELECT DISTINCT facte.nr_factura FROM cli, facte, pdfe, [SELECT * FROM prod WHERE prod.denumire IN ("xyz","abc")]. AS tmp WHERE facte.cod_client=cli.cod_client AND facte.nr_factura=pdfe.nr_factura AND pdfe.cod_produs=prod.cod_produs;

 P11. Care este valoarea totală a facturilor emise în luna mai 2009 pentru fiecare  client? Lista: |cod_client | nume_client | valoare totala | AR

R1 = SELECT  (FACTE; (data_factura ≥ 01.05.2009) and (data_factura ≤ 31.05.2009)) R2 = SUM (R1, valoare; cod_client) R3 = NATURAL JOIN  (R2, CLI; cod_client) R4 = PROJECT (R3; cod_client, nume_client, sum) MS ACCESS

SELECT tmp.total, tmp.cod_client, nume_client FROM cli, [SELECT sum(valoare) AS total, facte.cod_client FROM facte WHERE year(data_factura)=2009 AND month(data_factura)=5 GROUP BY facte.cod_client]. AS tmp WHERE tmp.cod_client=cli.cod_client;

 P12. Care este valoarea totală a facturilor emise în luna mai 2009 pentru fiecare clien t  persoană fizică? Lista: |cod_client | nume_client | valoare totala | AR

R1 = SELECT  (FACTE; (data_factura ≥ 01.05.2009) and (data_factura ≤ 31.05.2009))

64

R2 = SUM (R1, valoare; cod_client) R3 = SELECT  (CLI; tip_client = „F‟) R4 = NATURAL JOIN  (R2, R3; cod_client) R5 = PROJECT (R4; cod_client, nume_client, sum) MS ACCESS

SELECT tmp.total, tmp.cod_client, nume_client FROM cli, [SELECT sum(valoare) AS total, cod_client FROM facte WHERE year(data_factura)=2009 and month(data_factura)=5 and cod_client IN (SELECT cod_client FROM cli WHERE tip_client="f") GROUP BY cod_client]. AS tmp WHERE tmp.cod_client=cli.cod_client;

 P13. Care sunt valorile totale TVA colectat şi TVA deductibil în luna mai 2009? AR

R1 = SELECT  (FACTE; (data_factura ≥ 01.05.2009) and (data_factura ≤ 31.05.2009)) R2 = SUM (R1, tva_colectat) Q1 = SELECT  (FACTP; (data_factura ≥ 01.05.2009) and (data_factura ≤ 31.05.2009)) Q2 = SUM (Q1, tva_deductibil) MS ACCESS

(SELECT sum(factp.valoare*19/100) AS tva FROM factp) UNION (SELECT sum(facte.valoare*19/100) AS tva FROM facte);  P14. Care este valoarea maximă a facturilor emise în luna mai 2009 pentru fiecare  client persoană juridică? Lista: |cod_client | nume_client | valoare maximă factură | AR

R1 = SELECT  (FACTE; (data_factura ≥ 01.05.2009) and (data_factura ≤ 31.05.2009)) R2 = MAX (R1, valoare; cod_client) R3 = SELECT  (CLI; tip_client = „J‟) R4 = NATURAL JOIN  (R2, R3; cod_client) R5 = PROJECT (R4; cod_client, nume_client, max) MS ACCESS

SELECT tmp.total, tmp.cod_client, nume_client FROM cli, [SELECT MAX(valoare) AS total, cod_client FROM facte WHERE cod_client IN (SELECT cod_client FROM cli WHERE tip_client="j") AND YEAR(data_factura)=2009 AND MONTH(data_factura)=5 GROUP BY cod_client]. AS tmp WHERE tmp.cod_client=cli.cod_client;

65

BIBLIOGRAFIE

1. AIRINEI D., Depozite de date, Editura Polirom, Iaşi, 2002. 2. BÂSCĂ O., Baze de date, Editura ALL, Bucureşti, 1997. 3. CONNOLLY Th., ş.a., Baze de date. Proiectare, Implementare, Gestionare, Editura Teora, Bucureşti, 2001. 4. CONNOLLY Th., ş.a., Database Systems, Addison-Wesley, 2002. 5. DATE C.J., Baze de date, Editura Plus, Bucureşti, 2005. 6. DOLLINGER R., Baze de date şi gestiunea tranzacţiilor, Editura Albastră, Cluj Napoca, 1998. 7. DOLLINGER R., Utilizarea sistemului SQL Server, Editura Albastră, Cluj Napoca, 2001. 8. EAGLESTONE B., ş.a., Web Database Systems, Mc Graw Hill Book Company, Londra, 2001. 9. FLORESCU V., ş.a., Baze de date, Editura Economică, Bucureşti, 1999. 10. FOTACHE M., Baze de date relaţionale , Editura Junimea, Iaşi, 1997. 11. FOTACHE M., SQL, Editura Polirom, Iaşi, 2001. 12. FOTACHE M., Proiectarea bazelor de date, Editura Polirom, 2005. 13. Grupul BDASEIG, Baze de date. Fundamente teoretice şi practice, Editura Infomega, Bucureşti, 2002. 14. HERNANDEZ M., Proiectarea bazelor de date, Ed. Teora, 2003. 15. HORGA M., ş.a., Limbajul SQL în Oracle şi Visual FoxPro, Editura Bibliotheca, Târgovişte, 2007. 16. IONESCU F., Baze de date relaţionale şi aplicaţii, Editura Tehnică, Bucureşti, 2004. 17. LUNGU I., ş.a., Baze de date. Organizare, proiectare şi implementare, Editura ALL Educational, Bucureşti, 1995. 18. LUNGU I., ş.a., Baze de date. Sistemul ORACLE, Ed. Economică, Bucureşti, 2002. 19. LUNGU I., Baze de date ORACLE. Limbajul SQL, Editura ASE, Bucureşti, 2005. 20. MEIER A., Introduction pratique aux bases de données relationnelles, Ed. Springer France, 2006 21. MIRANDA S.M., BUSTA J.M., L’art des bases de données, Ed. Eyrolles, Paris, 1988. 22. PASCU C., ş.a., Totul despre SQL, Editura Tehnică, Bucureşti, 1994. 23. POPA GHE., ş.a., Sisteme de gestiune a bazelor de date, Editura Cison, Bucureşti, 1996. 24. POPESCU I., Baze de date relaţionale, Editura. Universităţii din Bucureşti, Bucureşti, 1996. 25. POPESCU I., ORACLE 8. Prelucrarea avansată a informaţiei, Ed. Tehnică, Bucureşti,1999. 26. POPESCU I., Modelarea bazelor de date, Editura Tehnică, Bucureşti, 2001. 27. POPESCU I., ş.a., Pr ogramare avansată în ORACLE 9i , Editura Tehnică, Bucureşti, 2004.

66

View more...

Comments

Copyright ©2017 KUPDF Inc.
SUPPORT KUPDF