Baze de Date Relation Ale
June 20, 2018 | Author: Pantzy Alexu | Category: N/A
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
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
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ă
Y
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