Documente Academic
Documente Profesional
Documente Cultură
Baze de Date PDF
Baze de Date PDF
BAZE DE DATE
Conf. univ.dr. ELENA NECHITA
Lector univ. dr. GLORIA-CERASELA CRIŞAN
2008
Prezentarea cursului
4
Obiectivele cursului
Cerinţe de examinare
Pentru evaluare se vor realiza următoarele activităţi:
5
CUPRINS
Prezentarea cursului 3
Obiectivele cursului. Cerinţe de examinare 4
3. Modelul relaţional 19
3.1 Conceptele modelului relaţional 20
3.2 Sisteme de gestiune a bazelor de date relaţionale 21
6
6. Limbaje utilizate în lucrul cu baze de date 37
6.1 Limbajul de definire a datelor pentru modelul relaţional 37
6.2 Limbajul de manipulare a datelor pentru modelul relaţional 38
6.2.1 Algebra Relaţională 38
6.2.2 SQL 42
6.2.3 Calculul Relaţional orientat pe tupluri 42
6.2.4 Calculul Relaţional orientat pe domenii 43
9. Baze de cunoştinţe 54
Bibliografie 125
7
„Order is not sufficient.
What is required, is something
much more complex.
It is order entering upon novelty;
so that the massiveness of order
does not degenerate into mere repetition;
and so that the novelty
is always reflected
upon a background of system.''
(Alfred North Whitehead)
8
cunoştinţele că sunt elemente abstracte şi individuale despre obiectele şi domeniile lumii
reale, însuşite şi/sau dobândite.
Aproape orice activitate are şi o latură informaţională. De exemplu, în paralel cu
procesul de producere de bunuri şi servicii se desfăşoară şi un proces informaţional,
constând din fluxuri de documente prin care se ţine evidenţa activităţii desfăşurate.
Atunci când informaţia este gestionată cu ajutorul tehnicii de calcul, ea devine dată.
Data este forma de reprezentare accesibilă a informaţiei prelucrate. Ea reprezintă
suportul formal al informaţiei, care se concretizează în: cifre, litere, simboluri, coduri şi alte
însemne. Există o corespondenţă determinată între informaţie, simbol şi dată astfel că, foarte
adesea, în practică, termenul de informaţie este utilizat pentru a desemna date, iar expresia
„prelucrarea informaţiilor” înlocuieşte expresia „prelucrarea datelor”. Putem considera că
datele prelucrate, în măsura în care afectează în sens pozitiv comportamentul receptorilor
(oameni sau maşini), au calitatea de informaţii.
În procesul prelucrării şi utilizării informaţiilor, acestea sunt privite din patru puncte de
vedere:
• Din punct de vedere sintactic, atunci când se urmăreşte aspectul admisibil al
acestora, în sensul că informaţiile trebuie să capete anumite forme de reprezentare, ce
respectă riguros anumite reguli.
• Din punct de vedere semantic, urmărindu-se semnificaţia, înţelesul informaţiei
(conţinutul real al informaţiei) ce derivă din datele prelucrate.
• Din punct de vedere pragmatic, urmărindu-se utilitatea pentru receptori, efectul
asupra acestora (măsura în care acestea satisfac cerinţele utilizatorului).
• Din punct de vedere sigmatic, se tratează raportul dintre semne şi obiecte, caz
în care se poate vorbi despre cunoştinţe obiective. În locuri publice, semnalizarea şi
direcţionarea cu ajutorul indicatoarelor trebuie să fie atât sugestivă, compactă, cât şi
independentă de limbă sau cultură. Pictogramele pentru indicarea cabinelor telefonice,
zonelor de fumători, ghişeelor de informaţii sau punctelor medicale reprezintă cunoştinţe
obiective.
Datele reprezintă aşadar informaţii care fac obiectul prelucrării pe sistemele de calcul
şi pot fi:
• Elementare (numite şi simple sau scalare) – atunci când sunt indivizibile în
raport cu prelucrările la care pot fi supuse.
• Compuse (numite şi complexe) – atunci când sunt alcătuite din mai multe
date elementare, deci sunt la rândul lor divizibile în date mai simple.
Exemplu. În cazul unei persoane: vârsta, înălţimea, greutatea, codul numeric personal sunt
date elementare. Domiciliul (format din oraş, stradă, număr) este o dată compusă.
Observaţie. O dată poate fi considerată elementară dintr-un punct de vedere şi compusă din
altul, aceasta în funcţie de prelucrările necesare.
Unei date i se atribuie un nume – identificatorul său, prin intermediul căreia ea se
distinge de celelalte şi prin care poate fi adresată. O caracteristică de bază a unei date este
tipul său. Acesta determină modul în care data respectivă va fi memorată pe suporturi de
memorare şi modul în care ea va fi prelucrată (adică operatorii şi funcţiile ce i se pot aplica).
În cadrul unui limbaj de programare, de exemplu, există o serie de tipuri de date de bază
(elementare), prestabilite de către proiectanţii limbajului şi, de cele mai multe ori, există
posibilitatea definirii de noi tipuri, prin combinarea celor elementare. Marea majoritate a
limbajelor permit manipularea datelor numerice (întregi şi reale), a caracterelor şi şirurilor de
caractere, a tablourilor uni- şi multi-dimensionale.
O colecţie de date reuneşte date despre o anume clasă de obiecte (reale sau
conceptuale).
Exemplu. Colecţia de date prezentată mai jos reuneşte date cu privire la clasa de obiecte
denumită CONTURI:
Cod_cont Denumire_cont
101 Capital social
104 Prime legate de capital
105 Diferenţe din reevaluare
106 Rezerve
…
933 Costul producţiei în curs de execuţie
9
Fiecare obiect de acest tip are o existenţa proprie şi este bine definit de aceleaşi
caracteristici, respectiv codul contului şi denumirea contului. Contul cu codul 101 şi
denumirea Capital social constituie o realizare sau o instanţă a obiectului tip CONTURI,
pentru care caracteristicile Cod_cont, Denumire_cont iau valorile 101 şi respectiv Capital
social.
Alte exemple.
• Datele referitoare la materialele dintr-un depozit.
• Datele referitoare la cărţile dintr-o bibliotecă.
• Datele referitoare la pacienţii unui spital.
• Datele ce descriu situaţia contabilă a unei firme.
Omogenitatea datelor dintr-o colecţie de date trebuie înţeleasă în sens larg, sub
forma unei proprietăţi comune sau a unui obiectiv urmărit.
Noţiunile de informaţie şi dată sunt, prin urmare, diferite. Informaţiile sunt înţelese
de o persoană, în timp ce datele sunt modele stocate pe un mediu pasiv, ca de exemplu
discul hard al unui calculator. Scopul unui sistem care gestionează o colecţie de date este să
reducă distanţa între informaţii şi date – astfel, datele stocate în memoria sau pe discurile
unui calculator să fie convertite în informaţii utilizabile la momentul dorit.
Exemplu. Fişierul de date STOCURI conţine date privind stocurile de produse. Pentru fiecare
produs se memorează: codul, denumirea, unitatea de măsură, preţul de referinţă şi cantitatea
aflată în stoc. Iată (schematic reprezentată) o înregistrare logică pentru un produs aflat în
stoc:
10
fiecare înregistrare de date, sunt memorate două elemente: cheia de
identificare a înregistrarii şi adresa la care înregistrarea este memorată pe
suport tehnic.
Exemplu.
Tabel cu Înregistrări de date
indecşi
350 A1 A2 401 TV PANASONIC BUC 1000 20
401 A2 A1 350 RADIO SAMSUNG BUC 100 30
420 A3 A3 420 VIDEO SAMSUNG BUC 900 10
… … … … … …
A1 reprezintă adresa (care face referire, în cazul HD, la cilindru, pistă şi sector) la care este
memorată înregistrarea cu valoarea din câmpul de indexare (aici codul produsului) cu
valoarea 350, ş.a.m.d.
Tabelul cu indecşi permite astfel localizarea rapidă a înregistrărilor pe suportul tehnic.
Această metodă presupune existenţa unui atribut ale cărui valori să permită identificarea
înregistrărilor. Acest atribut are rolul de cheie de identificare (indexare).
Deci, un fişier de date este bine definit când se precizează identificatorul de fişier,
structura înregistrării şi modul de organizare.
Exemplu.
Fişierul: STOCURI
Structura înregistrării:
CodMat, numeric
DenMat, Text
UM, Text
PretRef, Numeric
CantStoc, Numeric
Organizare: indexată
Cheie identificare: CodMat
Deci abordarea tradiţională asocia fiecărei aplicaţii informatice propriile fişiere. În mod
evident, anumite date se regăseau în fişierele asociate mai multor aplicaţii. Schematic,
această metodă poate fi reprezentată astfel:
P1 P2 Pn
…
11
• Cod – un cod asociat fiecărui material, necesar identificării acestuia şi altfel decât prin
nume (de exemplu: 5289);
• Denumire – denumirea materialului (de exemplu: lemn de brad);
• Um – unitatea de măsură (de exemplu: mc, aici, metru cub);
• Preţ – este vorba de preţul unitar (preţul pentru un metru cub de lemn de brad);
• Cantitate – cantitatea existentă la un moment dat în fabrică.
Aceste date şi altele, specifice, vor fi prelucrate pentru diferite compartimente: aprovizionare
(pentru recepţia materialului), gestiune (păstrarea într-o magazie), producţie (consumul
materialului respectiv în procesul de producţie), contabilitate (pentru calculaţia costului
produselor finite). Deci cel puţin patru programe ar utiliza aceste date şi ar fi prin urmare
dezavantajoasă memorarea lor pe un suport fizic (în diferite fişiere) de tot atâtea ori.
Cu toate aceste limite, organizarea datelor în fişiere mai este utilizată şi astăzi,
îndeosebi pentru aplicaţii dezvoltate folosind limbajele clasice de programare.
Progresele în domeniul tehnologiilor informaţionale au marcat o creştere
considerabilă a capacităţii de memorare a suporturilor tehnice de date şi a vitezei de
procesare a datelor. La acestea se adaugă şi posibilitatea stocării şi procesării datelor
netradiţionale cum ar fi, de exemplu, imaginea şi sunetul (a se vedea [Tod04]).
P2
Bază de date
P1 Pn
12
Într-o bază de date sunt înregistrate date despre obiecte reale sau abstracte, dar şi
asocierile (relaţiile) care se pot stabili între acestea. Spunem că între datele unei baze de
date există o interdependenţă logică. Considerarea interdependenţelor ce se pot stabili între
colecţiile de date memorate într-o bază de date contribuie la asigurarea integrităţii funcţionale
a bazei de date.
O bază de date este un model al unui sistem real. Conţinutul unei baze de date
(numit uneori şi extensie) reprezintă, la un moment dat, o stare a sistemului care se
modelează. Schimbările în baza de date reprezintă evenimente care au loc în mediu şi care
schimbă starea sistemului modelat. Este evident că este de dorit să structurăm o bază de
date astfel încât aceasta să oglindească sistemul care se doreşte modelat.
13
Realizarea pe plan mondial a unor reţele de calculatoare care permit conectarea mai
multor baze de date a condus la apariţia bazelor de date distribuite şi, implicit, la apariţia
SGBD pentru astfel de baze. Bazele de date distribuite reprezintă un salt calitativ superior în
acest domeniu, oferind noi perspective pentru realizarea sistemelor informatice. Un sistem de
baze de date distribuite este o colecţie de baze de date locale, amplasate geografic în puncte
diferite şi legate logic prin relaţii funcţionale, astfel încât apar, la nivel global, ca o singură
bază de date.
În funcţie de modul în care exploatează baza de date, utilizatorii pot fi împărţiţi în
următoarele clase:
• Utilizatorii obişnuiţi, care pot să obţină informaţiile dorite fără să aibă cunoştinţe de
programare, prin comenzi cunoscute şi eventual răspunzând la diferitele opţiuni pe
care le indică sistemul la un moment dat.
• Programatorii de aplicaţii, care realizează programele ce vor fi memorate şi ulterior
lansate în execuţie de utilizatori prin invocarea numelui asociat lor.
• Administratorul bazei de date, care stabileşte structura iniţială a bazei de date şi
modul de memorare a datelor la nivel fizic, acordă utilizatorilor drepturi de acces la
bază sau la părţi ale ei, stabileşte condiţiile pentru asigurarea securităţii şi integrităţii
datelor, modifică structura bazei atunci când este nevoie, asigură întreţinerea bazei
făcând periodic copii şi reconstruind baza de date în cazul în care au apărut erori
datorate componentelor soft, hard sau utilizării şi răspunde, în general, de modul de
utilizare al bazei de date.
Cele mai multe SGBD-uri conţin şi o colecţie de utilitare folosite în diferite aplicaţii:
procesoare pentru limbaje de cereri, editoare de rapoarte, sisteme de reprezentări grafice,
posibilităţi de lucru cu tabele, programe statistice, de copiere, generatoare de aplicaţii şi alte
posibilităţi de dezvoltare a unor aplicaţii de tip CASE (computer-aided software engineering).
Pentru a facilita munca administratorului de sistem, un SGBD conţine o serie de
componente care permit: crearea unei versiuni iniţiale a bazei, salvarea şi reîncărcarea
(efectuarea de copii periodice şi posibilitatea refacerii bazei plecând de la aceste copii),
reorganizarea (rearanjarea datelor în scopul îmbunătăţirii unor performanţe), statistici şi
analize asupra exploatării bazei de date.
Evoluţia tehnologiilor informaţionale face ca în prezent majoritatea SGBD-urilor:
• Să gestioneze date tradiţionale, dar şi date netradiţionale (video, foto, sunet
etc.).
• Să permită lucrul în reţea de calculatoare.
• Sa pună la dispoziţia utilizatorului atât limbaje declarative, cât şi limbaje
procedurale.
1. www.cs.washington.edu/education/courses/444/98wi
2. www.albany.edu/acc/courses/acc682.fall98/
3. www.cs.umbc.edu/461/461.shtml
4. www-db.stanford/edu/~ulmann/fcdb.html
5. www.developer.com/db/article.php/719041
6. www.servicearchitecture.com/database/articles
7. webmonkey.wired.com/webmonkey/backend/databases/tutorial/tutorial1.html
Despre alegerea sistemului potrivit de baze de date
8. [Bas97]
Tipuri de organizare a fişierelor şi metode de căutare în fişiere
Descrierea unor SGBD-uri de tipuri diferite
14
2. Niveluri de reprezentare a unei baze de date
• Entitate - O entitate este un obiect concret sau abstract care poate fi clar delimitat în
mediu.
o Instanţă de entitate - O instanţă este o apariţie particulară a unei entităti.
De exemplu, fiecare persoană în parte poate fi o instanţă a unei entităţi
PERSOANE, fiecare maşină în parte poate fi o instanţă a unei entităţi
MAŞINI, etc.
o Tip de entitate – Un grup de entităţi similare poartă numele de clasă de
entităţi sau tip de entitate. O clasă de entităţi are proprietăţi comune.
15
» Domeniile – sunt mulţimile de definiţie ale atributelor:
• mulţimi precizate de valori scalare de acelaşi tip sau
• mulţimi de valori posibile.
• Cheile – Cheile identifică în mod unic o entitate de alta, într-o clasă de entităţi.
o Cheia primară – Identificator utilizat pentru a identifica în mod unic o instanţă
particulară a unei entităţi.
Poate fi reprezentată de unul sau mai multe atribute.
Trebuie să fie unică în domeniul său (şi nu doar în setul de date
curent).
Valorile sale nu se schimbă în timp.
Trebuie să aibă totdeauna o valoare.
Poate fi creată când nu este evident nici un atribut. Fiecărei instanţe i
se asociază o valoare.
o Cheie candidată – Când există mai multe chei primare posibile, fiecare este
o cheie candidată.
o Cheie concatenată – Este o cheie realizată din componente care, atunci
când sunt considerate împreună, identifică în mod unic entitatea. Cheile
atribute multiple sunt chei concatenate.
o Atribute cheie împrumutate – dacă există o relaţie isa, cheia clasei mai
generale este, de asemenea, o cheie pentru subclasă. De exemplu, dacă
numărul de serie pentru automobile este cheie, va fi cheie şi pentru
camioane.
o Chei secundare – Referă un tabel aflat în relaţie, prin cheia primară a acelui
tabel.
» Restricţia de integritate referenţială – Pentru fiecare valoare a unei chei
secundare, există o cheie primară cu acea valoare în tabelul referit. De
exemplu, dacă un număr de cont se utilizează într-un tabel pentru intrări,
atunci numărul de cont trebuie să existe tabelul cu numerele de cont.
16
2.1.2 Diagrama Entitate - Asociere
17
deciziilor şi de gestionare de tip ierarhic, sistemele de informare şi operare bazate pe lucrul
cu meniuri şi altele asemănătoare.
Probleme: modul de definire a datelor este predefinit; fiecare asociere trebuie să fie
definită explicit, la crearea bazei de date.
Modelul ierarhic este un caz special al modelului reţea. Cel mai cunoscut SGBD de
tip ierarhic este IMS (Information Management System) de la IBM. A fost construit în 1968 în
scopul prelucrării datelor din industria aerospaţială. Iniţial a fost un sistem pur ierarhic, dar a
căpătat unele trăsături non-ierarhice, ca rezultat al necesităţilor practice.
Exemplu.
Structura arborescentă prezentată în continuare se referă la o bază de date a unei
agenţii de vânzări de locuinţe:
JUDETE (NUMER)
OFICII (ORAS, ADROF)
AGENTI (NUMEA, VANZARI)
ANGAJAT (NR_AN, NUMEAN, ADRAN, SALARIU)
OFERTE (ADROF, PRET)
CLIENTI (NUMEC, ADRC)
TREE AGENTIE
RECORD JUDETE ROOT
NUMER CHAR(20)
RECORD OFICII PARENT=JUDETE
ORAS CHAR(20)
ADROF CHAR(30)
RECORD AGENTI PARENT=OFICII
NUMEA CHAR(20)
VANZARI INTEGER
RECORD ANGAJAT PARENT=OFICII
NR_AN INTEGER
NUMEAN CHAR(20)
ADRAN CHAR(30)
SALARIU INTEGER
RECORD OFERTE PARENT=OFICII
ADROF CHAR(30)
PRET INTEGER
RECORD CLIENTI PARENT=AGENTI
NUMEC CHAR(20)
ADRC CHAR(30)
Modelul de date reţea este cel mai apropiat de forma de reprezentare a bazelor de
date sub forma diagramelor entitate-asociere. Deosebirea constă doar în faptul că toate
relaţiile ce apar pot fi numai binare şi de tipul 1-1 sau 1-n. Această restricţie permite
reprezentarea grafică a unei baze de tip reţea sub forma unui orientat numit reţea. În acest
graf, nodurile corespund entităţilor iar relaţiile sunt reprezentate prin săgeţi de la tată la fiu şi
anume: săgeţi simple dacă relaţia este de tip 1-1 şi săgeţi duble dacă relaţia este de tip 1-n.
Iată câteva caracteristici ale modelului reţea:
• Crează asocieri între date printr-o listă de legături în care înregistrările
subordonate (membre) pot fi legate la mai mult de un element (proprietar). Un
element poate fi parte a mai multor asocieri.
• Pointer – legătură explicită, păstrând adrese ce conţin locaţia înregistrării
asociate.
• Complexitate – pentru fiecare mulţime de elemente asociate trebuie păstrată o
pereche de pointeri. Utilizănd acest model, este dificil să se structureze, din
punct de vedere conceptual, structuri de date complexe.
18
• Viteză – legăturile directe conduc la viteze de lucru mari ale sistemelor care
implementează modelul reţea.
Exemplu.
SGBD SOCRATE este de tip reţea, fiind totodată şi unul din primele sisteme de
gestiune a bazelor de date. A fost realizat de firma CII în colaborare cu ECA-Automation
pentru sisteme de tip IRIS, fiind folosit şi în ţara noastră pe vechile sisteme de tip Felix.
Sistemul conţine un limbaj de descriere pentru date (identificarea datelor, a proprietăţilor lor şi
eventual a criteriilor de validare), un limbaj de cereri, un macrogenerator (pentru generarea
unor macrocomenzi care permit utilizarea produsului şi de către nespecialişti), un modul de
metode de acces (care permite utilizarea unor programe de accesare a datelor scrise în
diverse limbaje de programare), un editor de texte (pentru gestionarea textelor programelor şi
a celor din baza de date), componente pentru asigurarea securităţii şi confidenţialităţii datelor
din bază, pentru reorganizarea bazei şi alte programe utilitare. Poate lucra atât autonom,
conţinând toate elementele necesare funcţionării sale, cât şi ca metodă de acces, fiind
deschis prin interfeţe pentru a putea funcţiona împreună cu alte programe. Poate opera atât
programabil cât şi conversaţional. În al doilea caz, poate lucra în regim multiutilizator.
2. http://unixspace.com/context/databases.html
3. www.ittia.com/dbstar/whitepapers/technicalmodel.pdf
4. www.staff.brad.ac.uk/ckarazai/Lecture3.pdf
5. www.campus.ncl.ac.uk/databases/design/design.html
6. http://databases.about.com/od/Specificproducts
7. http://ycmi.med.yale.edu/nadkarni/IntroductiontoEAVSystems.htm
8. http://wofford.org/ecs/DataAudVisualization/ermodel/material.htm
19
3. Modelul relaţional
An(Data_angajarii)>=An(Data_nasterii)+18.
Regulile pentru asigurarea integrităţii datelor pot viza şi asocieri ce se stabilesc între
realizări ale relaţiilor din baza de date.
Dintre cele trei modele de baze de date prezentate, modelul relaţional se impune prin:
simplitate, structuri de date simple, operatori simpli (fără mari diferenţe între sisteme),
mecanismul vederilor, o bază teoretică solidă, un număr mic de concepte, aplicarea
principiului dualităţii accesului (prin program şi interactiv), independenţa fizică a datelor,
independenţa logică a datelor, uşurinţa dezvoltării aplicaţiilor, a instalării şi operării,
simplificarea proiectării bazelor de date, integrarea dicţionarelor, posibilitatea dezvoltării
bazelor de date distribuite, performanţe şi posibilităţi de extindere.
20
3.1 Conceptele modelului relaţional
Conceptele modelului relaţional sunt prezentate în următoarea sinteză:
Există două restricţii ale modelului relaţional care, în practică, sunt uneori nerespectate:
1. Nu sunt permise tupluri duplicate. Dacă sunt introduse două tuple cu aceeaşi
valoare pentru fiecare din atribute, ele de fapt sunt considerate a fi acelaşi tuplu.
Această restricţie este uneori rezolvată prin asignarea unui număr de linie (sau de
tuplu) unic pentru fiecare intrare, ceea ce asigură unicitatea.
2. Nu se presupune nici o ordine a tuplurilor în cadrul relaţiei. În practică, totuşi, se
foloseşte desori o metodă de ordonare a tuplurilor.
Atribut sau
câmp sau
coloană
Numele atributelor
sunt parte a
COD_CLIENT NUME ADRESĂ CREDIT_LIMITĂ
schemei
19283 ELBAC S.A. Şos. Oituz 34 300000000
Există următoarea distincţie între schema unei relaţii şi extensia unei relaţii.
Schema este „cadrul” pentru relaţie. Ea defineşte relaţia, adică:
• Numărul atributelor
• Numele atributelor şi domeniile acestora
• Atributul cheie primară
Extensia relaţiei este conţinutul relaţiei, adică mulţimea tuplurilor care formează
relaţia. Extensia unei relaţii poate varia foarte mult în timp, dar schema este stabilă. Antetele
coloanelor din figura de mai sus pot fi privite ca o parte a schemei, iar tuplurile de sub antete,
ca fiind extensia.
21
În termeni conceptuali, o relaţie este o structură care păstrează valori ale atributelor
unei clase particulare de entităţi, sau ale unei clase particulare de asocieri. Exemplul
reprezintă o relaţie ce descrie membrii unei clase de entitate numită CLIENŢI. Relaţiile pot, de
asemenea, să descrie asocieri.
Observaţie. A nu se confunda, din cauza omonimiei, relaţia, care este o construcţie
la nivel de date a modelului relaţional, cu asocierea (pentru care se foloseşte şi termenul de
relaţie), care este o noţiune la nivel conceptual.
În relaţia CLIENŢI, cheia pentru fiecare realizare de entitate este păstrată în atributul
COD_CLIENT. Cheile compuse sunt folosite, de obicei, în cazul asocierilor. De exemplu,
dacă am crea o relaţie care să reprezinte asocierea dintre studenţi şi cursuri am avea nevoie
de o cheie, care ar putea fi combinaţia dintre cheia pentru studenţi şi cheia pentru cursuri.
Următoarele reguli permit (în cele mai multe cazuri) conversia unei diagrame entitate-
asociere într-o schemă relaţională:
• Este necesară câte o relaţie (tabel) pentru fiecare clasă de entităţi şi fiecare
relaţie de tip m-n;
• Nu sunt necesare relaţii pentru a reprezenta relataţiile de tip 1-1 sau 1-n;
• Când se construieşte o relaţie (tabel) pentru reprezentarea unei asocieri m-n,
cheia trebuie să conţină toate atributele cheie ale relaţiilor implicate.
2. http://databases.about.com/compute/databases/mbody.htm
Despre baze de date în general, cu informaţii despre modelul relaţional
3. http://www.sqlmag.com/Articles/Index.cfm?ArticleID=5113
SQL. Despre alegerea cheii primare
4. http://www.acm.org/classics/nov95/
Extrase din lucrarea lui Codd privind modelul relaţional
22
4. Noi funcţionalităţi ale bazelor de date
Lucrul în reţele de calculatoare permite distribuirea unei baze de date, din punct de
vedere fizic, pe mai multe site-uri. Fiecare site găzduieşte un sistem local de gestiune a
bazelor de date. Utilizatorii unui site au acces la baza de date locală şi, în plus, la bazele de
date distribuite în celelalte site-uri. Conexiunile între site-uri pot fi stabilite în diverse maniere.
23
Topologiile de racordare (stea, inel, combinate) se prezintă sub formă de grafuri, ale
căror noduri corespund site-urilor. Un utilizator particular va folosi baza de date fără să facă
referiri concrete şi fără să se preocupe de locul unde aceasta este memorată fizic.
Figura următoare prezintă o posibilă arhitectură pentru baza de date distribuită a unei bănci:
Centre regionale
cu Mainframe
În cazul unei întreprinderi s-ar putea opta pentru soluţia unei baze de date distribuite pe
funcţii, ca în figura următoare:
Gestiunea
Gestiunea resurselor umane
resurselor materiale şi a salariilor
Infrastructură
pentru
comunicaţie
Gestiunea Contabilitate
producţiei şi control de gestiune
24
4.3 Baze de date deductive
Bazele de date deductive se fundamentează pe cuplarea unei baze de date
relaţionale cu un procesor din clasa sistemelor expert. În figura următoare se prezintă o
arhitectură simplificată a unei baze de date deductive.
INTERFAŢA
Interpretor SGBDR
PROLOG
25
Tehnologia orientată „pe obiecte” reduce cele trei formalisme la unul singur: obiectul.
Aplicarea tehnologiei orientate obiect în domeniul bazelor de date a determinat apariţia
bazelor de date orientate pe obiecte. Primele baze de date orientate pe obiecte au apărut la
sfârşitul anilor '80, dar nu au atins un nivel de dezvoltare prea ridicat, datorită:
• lipsei produselor CASE, care să permită o proiectare corectă;
• limbajelor de interogare, care erau deficitare;
• faptului că nu existau standarde acceptate.
O bază de date orientată pe obiecte trebuie să îndeplinească două cerinţe fundamentale:
• să îndeplinească cerinţele unei baze de date;
• să fie un sistem care să aibă la bază tehnologia orientată obiect.
Obiect
Descrierea dinamică
(modele de prelucrare)
Date
Descrierea statică
(modele de date)
Exemple.
Super-Clasa Persoana
Atribute
Nume
Adresa
DataNasterii
Metode
Nume
Returneaza(Self.Nume)
Adresa
Returneaza(Self.Adresa)
DataNasterii
Returneaza(Self.DataNasterii)
Clasa Salariat
Atribute
SalariuIncadrare
LocMunca
Responsabil
Metode
SalariuIncadrare
Returneaza(Self.SalariuIncadrare)
NumeResponsabil
Returneaza(Self.NumeResponsabil)
26
O clasă (clasă derivată) poate moşteni de la o altă clasă (clasa de bază) atribute şi
metode. În exemplul de mai sus, clasa Salariat moşteneşte atributele şi metodele clasei
Persoana.
Tehnica moştenirii permite împărţirea eficace a anumitor cunoştinţe despre obiecte
pentru a obţine o reprezentare mai bogată în semantică. Datele cele mai generale se
grupează în clase care sunt în continuare specializate în subclase ce comportă atribute şi
comportamente din ce în ce mai particulare. La nivelul cel mai înalt va exista o superclasă
obiect de la care toate celelalte moştenesc (atribute, metode).
Clasa Salariat moşteneşte atributele, selectorii şi metodele superclasei Persoana. Ea
posedă în plus atribute şi metode proprii. Realizările clasei Salariat pot fi utilizate ca realizări
ale clasei Persoana şi pot poseda proprietăţi suplimentare.
Obiectele definite se integrează în sistem şi prezintă conexiuni cu alte obiecte. Aceste
conexiuni sunt materializate prin mesaje pe care obiectele le schimbă între ele. Aplicarea unei
metode la un obiect corespunde cu trimiterea unui mesaj. Receptorul mesajului se numeşte
Self.
Bazele de date orientate pe obiecte (BDOO) sunt gestionate folosind sisteme de
gestiune orientate pe obiecte (SGOO).
Principala caracteristică a BDOO este viteza de acces la date (în comparaţie cu
celelalte tipuri de Baze de date). Acest acces este asigurat prin intermediul unei hărţi a
ierarhiilor şi relaţiilor claselor de obiecte, pe care BDOO o stochează. De asemenea, permit
gruparea sau partiţionarea fizică a datelor, tehnică numită clustering. BDOO asigură
accesarea eficientă a obiectelor necesare la un moment dat unei cereri utilizator, minimizând
traficul prin reţea.
Domeniile în care este eficientă utilizarea BDOO sunt:
- simularea si modelarea diferitelor fenomene şi procese
- administrarea documentelor
- proiectele CASE (Computer Aided Software Engineering), CAD (Computer Aided
Design), CAM (Computer Aided Manufacturing), CAE (Computer Aided Engineering)
- multimedia
- ingineria cunoaşterii.
Cerere
Aplicaţie client Aplicaţie server
Răspuns
Cele mai răspândite aplicaţii client/server sunt cele cu baze de date; soft-ul pentru baza de
date este executat pe calculatorul server, iar programul care accesează baza de date pe un
calculator client.
27
4.8 Bazele de date şi sistemele informaţionale din organizaţii
Bazele de date constituie componenta centrală a sistemelor informaţionale din
întreprinderi, în cadrul reprezentat în figura următoare:
SISE
SLIC
B
D SIM
SIAD
SIT
SIR
SIIO
Post de lucru al
BD utilizatorului Server BD
distribuită de Baze de externe
date
BD
BD operaţionale
individuală
Depozite de
date
28
Materiale privind funcţionalităţile moderne ale bazelor de date:
1. www.extropia.com/tutorials/sql/toc.html
Introducere în domeniul bazelor de date, pentru dezvoltatorii de web
2. http://www.service-architecture.com/object-oriented-databases/
Articole despre bazele de date orientate obiect şi produse pentru acestea
3. http://sunsite.berkeley.edu/Imaging/Databases/
4. [Tod04]
29
5. Forme normale. Normalizare
• Asocierile 1-1 prezintă două dependenţe funcţionale. De exemplu, între numele unei
persoane şi codul său numeric personal există o dependenţă 1-1, cele două atribute
determinându-se reciproc.
• Asocierile 1-n prezintă o dependenţă funcţională. De exemplu, între numele unui
student şi numărul său matricol: un număr matricol se asociază exact unui student;
dar mai mulţi studenţi pot avea acelaşi nume, astfel că un nume poate avea mai
multe numere matricole asociate.
• Asocierile m-n nu prezintă dependenţe funcţionale. De exemplu, între studenţi şi
cursuri există o corespondenţă de acest tip: fiecare student poate urma mai multe
cursuri şi fiecare curs poate avea mai multi studenţi, fără a se observa vreo corelaţie
între valori, în sensul definiţiei dependenţei funcţionale.
5.1.1 Descompunerea
Procesul recreării tabelului original se numeşte uniune sau joncţiune (join). A se vedea
6.2.1.
Exemplu. În exemplul de mai jos sunt prezentate tabelele iniţiale, precum şi rezultatul
operaţiei join pe atributul Profesie.
Este important ca descompunerile ce se realizează într-o bază de date să aibă loc fără
pierderi de informaţie, căci în caz contrar, informaţia trebuie restaurată.
30
5.1.2 Asocierile şi proiectarea schemelor
Asocierile 1-1 sunt acelea în care fiecărui element din A i se pune în corespondenţă
un unic element din B şi reciproc. De exemplu, fiecare student are un număr matricol şi
fiecare număr matricol se asignează unui singur student. Tabelul următor prezintă o astfel de
asociere:
Într-o asociere n-1, fiecărui element din B i se asociază un unic element din A, dar
fiecărui element din A i se pot asocia mai multe elemente din B. De exemplu, dacă plecăm de
la ipoteza că un student nu poate urma decât o specializare, atunci: un student urmează o
specializare, dar o specializare are mai mulţi studenţi. Aceasta este o relaţie n-1 între studenţi
şi specializări (sau 1-n între specializări şi studenţi). Tabelul următor prezintă o astfel de
asociere:
Asocierile n-m sunt acelea în care nici unui element nu i se asociază un singur
partener. O astfel de relaţie este cea între studenţi şi cursuri. Fiecare student urmează mai
multe cursuri, iar fiecare curs are mai mulţi studenţi. Nu există limite în ceea ce priveşte
numărul partenerilor de asociere.
31
Exemplu. Fie relaţia
ORAR
CURS PROFESOR ORA LOCATIE STUDENT AN-STUDIU
Algebră Ionescu T. 10 A45 Miron Călin 1
Algebră Ionescu T. 10 A45 Matei Ruxandra 1
Programare Dinu A. 8 C9 Gruia Alina 2
Programare Dinu A. 8 C9 Traian Maria 2
Engleză Bontaş E. 16 C22 Miron Călin 1
Engleză Bontaş E. 16 C22 Matei Ruxandra 1
Engleză Bontaş E. 18 C22 Horia Anca 3
32
5.3.2 Prima formă normală (FN1)
Cod Bi
Legiti Categorie Pro Prenu Vâr
Califi Nume rou Oraş Superior
maţie Calificări fil me stă
cări nr.
21 113 Sisteme 3 Mareş Ana 29 1 Iaşi Ion
35 113 Sisteme 5 Ionescu Dan 33 2 Bucureşti Damian
35 170 Taxe 7 Ionescu Dan 33 2 Bucureşti Damian
35 200 Audit 4 Ionescu Dan 33 2 Bucureşti Damian
50 170 Taxe 3 Mircea Călin 35 2 Bucureşti Damian
77 150 Consultanţa 5 Traian Raluca 28 1 Iaşi Ion
77 200 Audit 8 Traian Raluca 28 1 Iaşi Ion
Informaţiile aflate doar în FN1 prezintă un înalt grad de redundanţă. Pentru a reduce
redundanţa vom converti datele la a doua formă normală.
Formele normale mai mari decât FN1 au fost motivate de descoperirea anomaliilor,
deci a operaţiilor pe relaţii din care rezultă inconsistenţe sau pierderi nedorite ale adtelor.
Înlăturarea anomaliilor necesită trecerea progresivă prin diferite nivele ale formelor normale.
Această transformare urmăreşte un ideal: fiecare informaţie care presupune asocieri între
date să apară o singură dată în bază şi să nu depindă de prezenţa altor asocieri.
O relaţie este în FN2 dacă este în FN1 şi toate atributele sale sunt dependente de
întreaga cheie (adică, nici unul din atributele non-cheie nu este relaţionat doar cu o parte a
cheii). Tehnica de descompunere pentru obţinerea FN2 este foarte simplă: presupune
construirea unei relaţii separate care sa inglobeze dependenţele parţiale şi să înlăture
atributele dependente din relaţia originală.
Pentru exemplul considerat, în urma eliminării dependenţelor parţiale s-au obţinut
următoarele trei relaţii.
Relaţia CADRE:
Bi
Legiti Prenu Vâr
Nume rou Oraş Superior
maţie me stă
nr.
21 Mareş Ana 29 1 Iaşi Ion
35 Ionescu Dan 33 2 Bucureşti Damian
50 Mircea Călin 35 2 Bucureşti Damian
77 Traian Raluca 28 1 Iaşi Ion
33
Se observă că numele şi prenumele, vârsta şi informaţiile referitoare la grupul din care
persona face parte (numărul biroului, orasul, şeful direct) sunt corelate direct cu numărul de
legitimaţie (am putea spune că „depind de” numărul de legitimaţie) şi nu depind de calificare.
Relaţia CALIFICĂRI:
Cod Categorie
Calificări Calificări
113 Sisteme
170 Taxe
200 Audit
150 Consultanţa
Relaţia COMPETENŢE:
Legiti Cod
Competenţe
matie Calificări
21 113 3
35 113 5
35 170 7
35 200 4
50 170 3
77 150 5
77 170 8
În acest caz, competenţa este determinată de combinaţia celor două chei (legitimaţie şi cod
calificare).
O relaţie este în FN3 dacă este în FN2 şi nu există nici un fel de dependenţe
tranzitive (adică, nici unul din atributele non-cheie nu este dependent de alt atribut, care la
rândul său este dependent de cheia relaţiei).
Aceasta înseamnă că nu există nici o pereche (sau o pereche de mulţimi de atribute) X şi Y
pentru care să apară succesiunea:
Cheie X X Y
unde X este o cheie non-candidată.
O altă modalitate de a privi a treia formă normală este dată de faptul că ea rezultă din
relaţii ce reprezintă entităţi şi relaţii ce reprezintă asocieri între entităţi. O descompunere
corespunzătoare, prin care o schemă se poate converti la a treia formă normală, este aceea
prin care acele atribute care nu sunt direct (sau, sunt doar tranzitiv) dependente de cheie sunt
plasate într-o relaţie separată. Această descompunere prezintă două caracteristici importante:
• Fiecare dependenţă este concretizată printr-o relaţie (deci descompunerea păstrează
dependenţele).
• Dacă o extensie a relaţiei originale este descompusă, ea poate fi reconstruită prin
intermediul unui JOIN, din componente (fără pierderi).
În general, orice schemă poate fi adusă la a treia formă normală, cu păstrarea dependenţelor
şi cu operaţii join fără pierderi de date. Pentru exemplul considerat, datele în FN3 se prezintă
după cum urmează.
Relaţia CADRE:
Bi
Legiti Prenu Vâr
Nume rou Oraş Superior
maţie me stă
nr.
21 Mareş Ana 29 1 Iaşi Ion
35 Ionescu Dan 33 2 Bucureşti Damian
50 Mircea Călin 35 2 Bucureşti Damian
77 Traian Raluca 28 1 Iaşi Ion
34
Relaţia BIROURI:
Bi
rou Oraş Superior
nr.
1 Iaşi Ion
2 Bucureşti Damian
Relaţia CALIFICĂRI:
Cod
Categorie
Califi
Calificări
cări
113 Sisteme
170 Taxe
200 Audit
150 Consultanţa
Relaţia COMPETENŢE:
Legiti Cod
Competenţe
matie Calificări
21 113 3
35 113 5
35 170 7
35 200 4
50 170 3
77 150 5
77 170 8
Exemplu. Fie relaţia ORAR prezentată în 5.2. Singura cheie a relaţiei este formată din
atributele STUDENT şi ORA. Dependenţa CURS →→ ORA, LOCATIE nu respectă condiţia
din FN4 deoarece CURS nu conţine o cheie. Vom descompune relaţia în:
35
CURSURI
CURS ORA LOCATIE
Algebră 10 A45
Programare 8 C9
Engleză 16 C22
ORAR1
CURS PROFESOR STUDENT AN-STUDIU
Algebră Ionescu T. Miron Călin 1
Algebră Ionescu T. Matei Ruxandra 1
Programare Dinu A. Gruia Alina 2
Programare Dinu A. Traian Maria 2
Engleză Bontaş E. Miron Călin 1
Engleză Bontaş E. Matei Ruxandra 1
Engleză Bontaş E. Horia Anca 3
care are cheia CURS, STUDENT dar nu este în FN4 deoarece prezintă dependenţa
CURS →→ PROFESOR care rezultă din CURS → PROFESOR şi CURS nu conţine o cheie.
Descompunem ORAR1 în:
PROFESORI
CURS PROFESOR
Algebră Ionescu T.
Programare Dinu A.
Engleză Bontaş E.
şi
STUDENTI
CURS STUDENT AN-STUDIU
Algebră Miron Călin 1
Algebră Matei Ruxandra 1
Programare Gruia Alina 2
Programare Traian Maria 2
Engleză Miron Călin 1
Engleză Matei Ruxandra 1
Engleză Horia Anca 3
36
5.3.8. Procesul normalizării relaţiilor
De obieci, forma normală FN3 este suficientă, iar alteori chiar FN2 este suficientă.
2. [Bas97]
Forme normale şi normalizare
3. http://databases.about.com/od/ specificproducts/a/normalization.htm
Despre normalizare
4. http://en.wikipedia.org/wiki/Database_normalization
Definiţia normalizării în enciclopedia wikipedia
5. http://www.datamodel.org/NormalizationRules.html
5 reguli pentru normalizarea datelor
6. http://www.fmsinc.com/tpapers/datanorm/
Fundamente ale normalizării datelor
37
6. Limbaje utilizate în lucrul cu baze de date
38
6.2 Limbajul de manipulare a datelor pentru modelul relaţional
Se cunosc foarte multe abordări în ceea ce priveşte limbajele de manipulare a
datelor (LMD) organizate relaţional. Cele mai multe dintre acestea sunt interactive, proiectate
pentru folosirea conversaţională de către un utilizator care aşteaptă un răspuns imediat.
Există patru sarcini de bază pe care trebuie să le realizeze un limbaj de manipulare a
datelor:
• Inserarea datelor noi.
• Ştergerea datelor vechi.
• Actualizarea datelor.
• Consultarea datelor.
Aceste funcţii se regăsesc – într-o formă sau alta – în orice limbaj de manipulare a datelor.
Complexitatea cea mai mare a operaţiilor unui limbaj de manipulare a datelor se
referă la ultima categorie de prelucrări: consultarea datelor. Inserarea, ştergerea şi
actualizarea sunt, de obicei, operaţii clare şi sunt realizate de un utilizator experimentat (sau
de un program de aplicaţie), cunoscându-se exact ce trebuie modificat şi unde. Operaţiile de
consultare sau cerere de date (query), pe de altă parte, sunt deseori realizate de utilizatori
care fie nu ştiu de la început ce caută, fie îşi exprimă cerinţele într-un mod foarte complicat.
Din această cauză, limbajele de manipulare a datelor sunt uneori numite limbaje de cereri
(query languages).
În cele ce urmează vom prezenta, prin intermediul unor exemple, trei abordări ale
limbajului de cereri în modelul relaţional:
• Algebra relaţională.
• Calculul pe tupluri.
• Calculul pe domenii.
Aceste trei limbaje s-au dovedit a fi echivalente, în sensul că orice cerere ce poate fi
exprimată în unul din limbaje poate fi exprimată şi în celelalte două. Diferenţa constă în
facilitatea scrierii cererii respective.
39
• Diferenţa. Pentru două relaţii R şi S se poate nota: R-S, MINUS(R,S), REMOVE(R,S).
Diferenţa relaţiilor R şi S este mulţimea tuplurilor din R care nu sunt în S. Este
necesar să fie îndeplinite aceleaşi condiţii ca pentru reuniune.
• Produsul cartezian. Pentru două relaţii R şi S se poate nota: R×S, PRODUCT(R,S),
TIMES(R,S). Produsul cartezian al relaţiilor R şi S este mulţimea tuplurilor cu r+s
componente, în care primele r componente reprezintă un tuplu în R iar ultimele s
componente reprezintă un tuplu în S. Dacă atributele au nume, lista numelor
atributelor din rezultat este reuniunea disjunctă a celor două liste (folosind calificări
sau redenumiri pentru atributele cu aceleaşi nume în cele două relaţii).
• Proiecţia. Fie relaţia R de grad r. Proiecţia relaţiei R după atributele c1, c2,…, ck (k<=r) se
notează πc1, c2,…, ck(R), PROJECT(R; c1, c2,…, ck) şi este mulţimea tuplurilor de aritate
k în care se păstrează doar valorile corespunzătoare atributelor menţionate explicit în
proiecţie. Dacă relaţia R are asociate nume pentru atribute, acestea se pot păstra în
relaţia rezultată. Se observă că acesastă operaţie corespunde unor „tăieturi verticale”
în R.
• Selecţia. Fie F o formulă logică formată din operanzi care sunt constante sau nume de
componente în tupluri şi operatori aritmetici şi/sau logici. Selecţia relaţiei R în raport
cu formula F se notează σF(R), SELECT(R; F) şi reprezintă mulţimea tuplurilor din R
pentru care formula F devine adevărată. Relaţia rezultat are pentru atribute aceleaşi
nume ca şi relaţia R. Toate constantele care apar în F sunt incluse între apostrofuri.
R S
A B C D E F
a b c b g a
d a f d a f
c b d
40
În acest caz, rezultatele aplicării operatorilor: reuniune, diferenţă, produs cartezian, proiecţie,
selecţie şi intersecţie asupra relaţiilor R şi S (cu precizările indicate pentru proiecţie şi
selecţie) sunt:
RUS R-S
a b c a b c
d a f c b d
c b d
b g a
R×S πA,C(R),
a b c b g a a c
a b c d a f d f
d a f b g a c d
d a f d a f
c b d b g a
c b d d a f
σ B=”b” (R), R ∩S
a b c d a f
c b d
R S
A B C D E F
a b c d c d
a b e f e f
b c e f
e d c d
e d e f
a b d e
R÷S
a b
e d
R S
A B C D E
1 2 3 3 1
4 5 6 6 2
7 8 9
În acest caz, joncţiunea lui R cu S cu B<D este:
R XB<D S
A B C D E
1 2 3 3 1
1 2 3 6 2
4 5 6 6 2
41
Exemplul 4. Fie relaţiile R şi S, cu schemele şi extensiile actuale:
R S
A B C B C D
a b c b c d
d b c b c e
b b f a d b
c a d
Relaţia ANGAJATI
Nume câmp Tip Cheie
Marca Număr Da
Nume Text 20
Prenume Text 20
Initiala_tatalui Text 1
Data_angajarii Dată
Relaţia CHITANTE
Nume câmp Tip Cheie
Numar_chitanta Număr Da
Data Dată
Total Număr
Avans Număr
Numar_cont Text 9
Credit_card Număr
Tip_card Text 2
Marca Număr
În cazul acestei cereri, sunt necesari operatorii: Selecţie, Proiecţie şi Joncţiune. Cererea
formulată se poate exprima, în limbajul algebrei relaţionale, prin secvenţa:
42
6.2.2 SQL
Unul dintre cele mai puternice limbaje structurate pentru interogarea bazelor de date
relaţionale îl constituie SQL (Structured Query Language). Pe lângă manipularea şi regăsirea
datelor, limbajul permite efectuarea de operaţii complexe privind actualizarea şi administrarea
bazelor de date.
SQL este un limbaj neprocedural sau declarativ, deoarece utilizatorul lui descrie
numai informaţiile pe care vrea să le obţină în urma interogării, fără a fi nevoie să stabilească
modalităţile de a ajunge la rezultatele dorite. În acelaşi timp, SQL nu poate fi considerat un
limbaj de programare sau unul de sistem ci, mai curând, face parte din categoria limbajelor de
aplicaţii, fiind orientat pe mulţimi. Foarte frecvent, limbajul SQL este utilizat în administrarea
bazelor de date client/server, aplicaţia client fiind aceea care generează instrucţiunile SQL.
Există un anumit grad de standardizare a limbajului SQL, mai multe sisteme de
gestiune a bazelor de date recunoscând principalele instrucţiuni ale acestuia (de exemplu:
Oracle, Access, Sybase etc.). Pe plan mondial, standardul în domeniu este considerat ANSI
(American National Standards Institute) SQL care are în vedere atât aspectele de definire,
interogare, manipulare a datelor, procesare a tranzacţiilor, cât şi caracteristicile complexe
privind integritatea informaţiilor. Mulţi producători de sisteme de gestiune a bazelor de date
furnizează propriile extensii ale limbajului SQL, asigurându-şi astfel exclusivitatea.
Se cunosc în literatura de specialitate trei metode de bază privind implementarea
limbajului SQL şi anume:
• cea prin apelare directă (Direct Invocation) - constă în introducerea instrucţiunilor
SQL de la prompter;
• cea modulară (Modul Language) - foloseşte anumite proceduri apelate de programele
aplicaţiei;
• cea de tip încapsulat (Embedded SQL) - are în vedere instrucţiunile încapsulate în
codul de program, fiind de tip static şi dinamic.
SELECT
Numar_chitanta, Data, Total_chitanta, CHITANTE.Marca, Nume, Prenume
FROM
CHITANTE, ANGAJATI
WHERE
Date&<3/1/05 AND CHITANTE.Marca# ="ANGAJATI.Marca#"
În cazul exemplului 5:
Cererea în QUEL, limbajul de cereri al SGBD INGRES, are forma:
retrieve
(c.Numar_chitanta, c.Data, c.Total, c.Marca, a.Nume, a.Prenume)
43
where
c.Data < 3/1/05 and c.Marca=”a.Marca”
CHITANTE
Numar_chitanta Data Total Avans Numar_cont Credit_card Tip_card Marca
3 3=3/1/05 3pers
ANGAJATI
Marca Nume Prenume Initiala_tatalui Data_angajarii
3pers 3 3
44
7. Restricţiile de integritate ale modelului relaţional
Integritatea bazelor de date este dată, în principiu, de corectitudinea informaţiilor
conţinute în acestea şi presupune detectarea, corectarea şi prevenirea diferitelor erori
neintenţionate privind informaţiile introduse în bazele de date.
Restricţiile de integritate (RI), denumite şi reguli de integritate, definesc cerinţele pe
care trebuie să le satisfacă datele din cadrul bazei de date relaţionale pentru a putea fi
considerate corecte şi coerente în raport cu sistemul real pe care îl reflectă.
În bazele de date relaţionale, relaţiile sunt toate la acelaşi nivel iar setul de operatori
este relativ restrâns, neputând exprima semantica operaţională a obiectelor complexe. Acest
aspect ramâne în sarcina programatorilor de aplicaţie. Totuşi, sistemele relaţionale deţin o
serie de mecanisme pentru tratatrea aspectelor de ordin semantic.
Restricţiile de integritate ale modelului relaţional sunt de două tipuri:
• RI structurale, care se definesc prinegalitatea sau inegalitatea unor valori din cadrul
relaţiilor. Din această cattegorie fac parte:
o Restriţiile de unicitate a cheii
o Restricţia referenţială
o Restricţia entităţii
o Dependenţa între date.
Exemplu. În relaţia R1 atributul A este cheie, în timp ce în relaţia R2 cheia trebuie formată
din atributele A şi B:
R1: R2:
A B A B
a1 b1 a1 b1
a2 b3 a1 b2
a3 b2 a2 b3
a4 b3 a3 b2
Într-o relaţie pot exista mai multe combinaţii de atribute cu proprietatea de identificare
unică a tuplurilor. Se spune în acest caz caz că relaţia posedă mai multe chei candidate. În
această situaţie, administratorul bazei va alege dintre cheile candidate una care să servească
efectiv la identificarea tuplurilor şi care se va numi cheie primară. Restul cheilor candidate se
vor numi chei alternate.
45
Cheia unei relaţii trebuie sa fie minimală, în sensul că nici o parte a sa nu trebuie să
posede proprietatea de identificare unică a tuplurilor relaţie.
O cheie externă reprezintă un atribut sau un grup de atribute dintr-o relaţie R1 ale
cărui/căror valori sunt deinite pe acelaşi/aceleaşi domeniu/domenii ca şi cheia primară a unei
alte relaţii R2 şi care are rolul de a modela asocierea între entităţile reprezentate prin relaţiile
R1 şi R2. În acest context, R1 este numită relaţie care referă, în timp ce R2 poartă numele de
relaţie referită.
Exemplu. În relaţia ANGAJATI atributul Marca este cheie primară, în timp ce atributul
Cod_departament este cheie externă, servind la modelarea asocierii între angajaţi şi
departamente. În relaţia DEPARTAMENTE, cheia Departament este cheie primară.
ANGAJATI: DEPARTAMENTE:
Marca Nume Cod_departament Departament Denumire
11 N1 1 1 Tehnic
22 N2 2 2 Personal
33 N3 1 3 Administrativ
44 N4 3
55 N5 3
66 N6 2
77 N7 1
Exemple. Pentru relaţia CUMPARATORI (Cod, Nume, Adresa, Debit) se poate impune
condiţia ca nici un cumpărător să nu aibă mai mult de 100.000.000 lei datorii. Pentru relaţia
MAGAZINE (Numemag, Adresamag, Codmarfa, Marfa, Pret) se poate impune ca noile preţuri
să nu crească cu mai mult de 20% faţa de preţurile vechi.
46
7.3 Aspecte privind integritatea
De integritatea datelor este legată şi protecţia datelor împotriva diferitelor evenimente
de avarie cum ar fi: căderea sistemului, cauzată de defectarea unor componente hardware
sau software, executarea incompletă a unor programe din cauza apariţiei unor erori sau din
necesitatea de întrerupere a lor în urma unor interblocări sau prin intervenţia utilizatorilor,
programarea eronată a unor activităţi prin strategiile folosite de sistem şi altele.
Pentru reconstituirea bazelor de date în eventualitatea apariţiei unor inconsistenţe în
general, majoritatea bazelor de date se copiază periodic pe medii magnetice ce se păstrează
în locuri sigure. De asemenea, se ţine o evidenţă a tuturor transformărilor efectuate în baza
de date de când s-a efectuat ultima copie. Fişierul care conţine aceste modificări se numeşte
jurnal. Fiecare înregistrare din jurnal conţine un identificator al programului care a făcut
modificarea, fosta valoare şi noua valoare introdusă pentru un element. Tot în jurnal se mai
păstrează diferite momente importante din desfăşurarea programelor (început, sfârşit,
terminarea unor operaţii).
Se spune despre o tranzacţie că este comisă dacă au fost terminate toate calculele
produse de ea în aria de lucru şi s-a realizat o copie a rezultatelor ei în jurnal. Apariţia unor
căderi după ce o tranzacţie a fost comisă nu afectează conţinutul bazei de date, deoarece
acestea se pot reconstitui cu ajutorul ultimei copii şi a jurnalului în care se găsesc toate
rezultatele tranzacţiilor comise. Modificările tranzacţiilor abandonate sau necomise nu sunt
luate în considerare la parcurgerea jurnalului pentru restaurarea bazei de date.
Se defineşte strategia de comitere în două faze astfel: o tranzacţie poate să scrie
într-o bază de date numai după ce a fost comisă şi o tranzacţie poate fi comisă numai după
ce a înregistrat în jurnal toate schimbările de elemente produse de ea.
1. [Fel96]
Despre dependenţe între date
2. www.boran.com/security/IT1x-4.html
3. www.computerworld.ro/index.cfm?t=articol&idcwd=2647
4. www.pcmagazine.ro/pcmag4-8/internet_business.shtml
47
8. Depozite de date (Data warehouse)
Depozitele de date au devenit, la sfârşitul anilor ' 90, una dintre cele mai importante
dezvoltări în domeniul sistemelor informaţionale. Industria de data warehouse s-a dezvoltat
continuu în termeni de investiţii, produse disponibile şi proiecte elaborate. Se apreciază că
aproximativ 90% dintre companiile multinaţionale au implementate depozite de date sau
lucrează la dezvoltarea unor astfel de proiecte.
Depozitele de date sunt produsul mediului economic şi al tehnologiilor avansate. Pe
de o parte, mediule conomic este tot mai competitiv, global şi complex şi solicită informaţii
elaborate pentru sprijinirea deciziilor strategice iar, pe de altă parte, evoluţia tehnologiilor
informaţionale oferă soluţii eficiente de gestionare a unor volume mari de date integrate (de
ordinul Tera bytes) asigurând niveluri de sinteză / detaliere adecvate. Astfel, evoluţiile
hardware performante precum şi sistemele de procesări paralele masive, sistemele de
multiprocesare simetrică, sistemele tip baze de date paralele fac posibile încărcarea,
întreţinerea şi accesul la baze de date de dimensiuni uriaşe. Aplicaţiile data warehouse sunt
în măsură să asigure şi un timp mediu de răspuns extrem de scurt pentru categorii extinse de
utilizatori.
Primele domenii care au adoptat tehnologia depozitelor de date au fost
telecomunicaţiile, băncile şi comerţul cu amănuntul. Ulterior, depozitele de date au pătruns şi
în alte domenii cum ar fi industria farmaceutică, sistemul sanitar, asigurările, transporturile.
Studiile statistice arată că telecomunicaţiile şi sistemul bancar se menţin în top întrucât alocă
cel puţin 15% din bugetul lor IT pentru proiecte referitoare la depozite de date.
Un proiect de data warehouse reprezintă o investiţie majoră. Costurile tipice pentru
dezvoltarea unui depozit de date într-un interval de 3-6 luni se situează între 0,8 şi 2 milioane
USD. Ponderea echipamentelor se situează între 1/2 şi 2/3 din costul total. Uneori, investiţiile
în depozite de date nu se finalizează cu succes (politici organizaţionale defectuoase,
insuficiente fonduri sau insuficientă susţinere din partea conducerii.
48
date este întotdeauna memorat separat, din punct de vedere fizic, de datele transformate din
alte aplicaţii. Datorită acestei separări, un depozit de date nu necesită mecanisme de
procesare a concurenţei. În mod uzual, solicită numai două operaţiuni: încărcarea iniţială a
datelor şi accesul la date.
Sintagma data warehousing desemnează procesul de construire şi utilizare a
depozitelor de date (data warehouse). Construirea necesită integrarea, curăţarea şi
consolidarea datelor. Utilizarea necesită o colecţie de tehnologii de asistare a deciziilor.
Acestea permit specialiştilor (manageri, analişti, executivi) să obţină rapid şi convenabil datele
necesare şi să ia decizii bazate pe informaţiile din depozit.
Nr.
Trăsături OLTP OLAP
Crt.
1 Destinaţia Procese operaţionale Procese informaţionale
2 Orientarea sistemului Tranzacţii Analize
3 Utilizatori Funcţionari, administratori
BD, profesionişti în BD
4 Funcţii Operaţii zilnice Cerinţe informaţionale pe
termen lung, asistarea
deciziei
5 Instrumente folosite în Diagrame E-A Star / snowflake
proiectare
6 Caracterul datelor Curente, noutate garantată Istorice, precizie
menţinută în timp
7 Nivelul de sinteză Primitive, detaliere ridicată Sintetizare, consolidare
8 Unitatea de lucru Scurtă, tranzacţii simple Interogări complexe
9 Scheme de acces Read, Write Aproape totdeauna Read
10 Focalizare Culegere date Furnizare informaţii
11 Număr de înregistrări Zeci Milioane
accesate
12 Număr de utilizatori Mii Sute
13 Mărimea bazelor de date 100 MB - GB 100 Gb - TB
14 Priorităţi Performanţe ridicate, Flexibilitate ridicată,
disponibilitatea ridicată autonomie utilizatori finali
15 Sistem de evaluare Tranzacţii culese Interogări culese, timp de
răspuns
49
Un sistem OLTP este orientat pe client (customer oriented) şi este utilizat pentru
procesarea tranzacţiilor şi a interogărilor. Un sistem OLAP este orientat spre piaţă (market
oriented) şi este utilizat de manageri, analişti şi specialişti.
Există şi conceptul de magazine de date (Operational Data Stores – ODS), care se
referă la o colecţie de date proiectate pentru sprijinirea controlului operaţional. La prim
avedere nu par deosebite de depozitele de date, dar – deşi ambele tehnologii sprijină
decidenţii – sunt diferite deoarece au scopul de a acoperi anumite tipuri de cerinţe
informaţionale. Magazinele de date conţin date orientate pe subiecte din întreprinderile mari
şi, spre deosebire de depozitele de date, conţin date volatile şi detaliate.
Baze de date
operaţionale
Instrumente
pentru
Accesare
şi
Utilizare
ŞTERGERE
Achiziţie DEPOZIT DE DATE
(extragere) (DATE AGREGATE ARHIVARE
+
METADATE) AGREGARE
Prelucrare
(data mining)
În depozitul de date întâlnim mai multe tipuri de date care corespund diferitelor
cerinţe informaţionale ale utilizatorilor:
• Date detaliate
• Date uşor agregate
• Date puternic agregate
• Metadate.
Metadatele descriu datele conţinute în depozitul de date şi modul în care ele sunt
obţinute şi stocate. Prin metadate se precizeză structura datelor, provenienţa lor, regulile de
transformare, de agregare şi de calcul. Metadatele joacă un rol esenţial în alimentarea
depozitului cu date. Ele sunt utilizate în toate etapele de încărcare adatelor şi sunt consultate
şi actualizate pe parcursul întregului ciclu de viaţă ale depozitului.
Agregarea datelor se referă la realizarea de: totaluri precalculate, subtotaluri, valori
medii, etc., ce se preconizează că vor fi cerute şi folosite de către utilizatori. Aceste agregări,
deşi determină o creştere a redundanţei datelor, sunt necesare deoarece în acest fel se poate
asigura un timp de răspuns cât mai redus. Sunt stocate în depozitul de date împreună cu
datele importante din surse interne şi externe.
Data Mining reprezintă un proces de prelucrare bazat pe modele performante de
selectare şi agregare a datelor din depozitele de date. Cele două scopuri principale ale
procesului de data mining sunt, din punct de vedere practic:
• Predicţia – implică utilizarea unor câmputi sau variabile din baza de date, în
scopul estimării unor valori viitoare sau necunoscute, pentru alte variabile de
interes şi
50
• Descrierea – se orientează către găsirea unor modele ce descriu datele,
interpretabile din perspectiva utilizatorului.
Procesul, numit şi Knowledge Data Discovery (KDD), este realizat prin intermediul
următoarelor sarcini:
• Clasificarea – este vorba de o funcţie care mapează (clasifică) un element de dată în
una sau mai multe clase predefinite.
• Regresia – o funcţie asociază un element de dată unei variabile cu rol de predicţie.
• Partiţionarea (clustering) – este o funcţie descriptivă prin care se urmăreşte
identificarea unui număr (finit) de categorii sau mulţimi care descriu datele. Strâns
legată de această funcţie este funcţia de estimare a densităţilor de probabilitate ale
variabilelor aleatoare constituite de câmpurile de date.
• Sumarizarea – implică metode pentru găsirea unei descrieri compacte a unei
submulţimi de date.
• Modelarea dependenţelor – constă din găsirea unor modele care descriu în mod
compact diferite dependenţe între subseturi de date. Modelele de dependenţă există
la două nivele: structural (ce variabile sunt dependente unele de altele) şi cantitativ
(specifică măsuri ale acestor dependenţe utilizând o scară numerică).
• Detectarea schimbărilor şi deviaţiilor – se focalizează pe descoperirea celor mai
semnificative schimbări ale datelor, utilizând valori anterior măsurate.
51
• Depozite virtuale – Virtual Warehouse. Un depozit virtual este un set de viziuni
asupra bazelor de date operaţionale. Este uşor de construit dar necesită capacităţi
suplimentare pe serverele de baze de date.
Din punct de vedere al modelelor de date specifice data warehouse, cele mai
populare sunt:
• Reprezentarea stea (Star Schema). Este cel mai comun model de date, în care
depozitul conţine un tabel central voluminos (tabel de fapte) care cuprinde cea mai mare parte
a datelor fără redundanţe şi un set de tabele însoţitoare (tabele-dimensiune) pentru fiecare
dimensiune. Graful asociat seamănă cu o stea în care tabelele-dimensiune apar radial, în jurul
tabelului de fapte central, ca în figura următoare.
Timp
Tabel-dimensiune 1
Cheie-timp Articol
Zi Tabel-dimensiune 3
Zi-din-săptămână Cheie-articol
Lună Nume-articol
Trimestru Marca
An Tip
Tip-furnizor
Vânzări
Tabel de fapte
Cheie-timp
Cheie-articol Zonă
Cheie-ramură Tabel-dimensiune 4
Cheie-zonă Cheie-zonă
Vânzări-lei Stradă
Ramură Cantitate-vândută Localitate
Tabel-dimensiune 2 Judeţ
Cheie-ramură Cod-poştal
Nume-ramură Ţara
Tip-ramură
În acest exemplu, vânzările sunt considerate cu patru dimensiuni: timp, articol, ramură şi
zonă.
Articol
Tabel-dimensiune 3 Furnizor
Cheie-articol Tabel-dimensiune 3-1
Nume-articol Cheie-furnizor
Marca Tip-furnizor
Tip
Cheie-furnizor
52
Zonă
Tabel-dimensiune 4 Oraş
Cheie-zonă Tabel-dimensiune 4-1
Stardă Cheie-oraş
Cheie-oraş Oraş
Judeţ
Regiune
• Constelaţie de fapte – aplicaţiile complexe pot solicita tabele multiple de fapte, care
partajează tabelele-dimensiune. Acest gen de schemă poate fi văzut ca o colecţie de stele,
de unde denumirea de constelaţie de fapte (fact constellation).
Când se justifică un proiect de data warehouse? Există mai multe situaţii în care
un depozit de date este oportun pentru rezolvarea unor probleme:
• Insuficienta partajare a informaţiilor (de exemplu, când servicii sau departamente cu
aceiaşi clienţi nu comunică între ele).
• Grupuri diferite produc rapoarte contradictorii (datorită folosirii inconsistente a unor
termeni).
• Procesul de creare a rapoartelor este foarte anevoios (necesită mult timp pentru a fi
produse şi nu rămâne timp pentru analiza efectivă a datelor).
• Rapoartele nu sunt dinamice şi nu favorizează stilul de interogare ad-hoc (nu se pot
obţine rapoarte concludente în situaţii speciale).
• Rapoartele care necesită date istorice sunt dificil de realizat (astfel de date nu sunt
stocate în sistemele operaţionale, iar încorporarea datelor vechi în rapoarte poate fi
dificilă din cauza nepotrivirii structurilor).
Majoritatea firmelor producătoare de software pentru baze de date s-au orientat către
implementarea unui modul specific depozitelor de date. În topul preferinţelor se află: SQL
Analysis Manager produs de Microsoft Corporation şi Oracle Warehouse Builder produs de
Oracle. Aceste două instrumente beneficiază de experienţa şi puterea finaciară a companiilor
producătoare şi au reuşit să se impună pe piaţă ca soluţii viabile. Industria depozitelor de date
este însă în continuă expansiune.
Instrumentele data-mining vor continua să se maturizeze şi din ce în ce mai multe
organizaţii vor adopta acest gen de tehnologie. Iniţiativele data mining provin cel ami adesea
din zona departamentelor de marketing şi de vânzări cu amănuntul şi se pretează foarte bine
în organizaţiile care deţin baze de date cu volume foarte mari. Datorită faptului că aceste
instrumente dau cele mai bune rezultate cu date la un nivel ridicat de detaliere, evoluţia
instrumentelor data mining va coincide de fapt cu dezvoltarea depozitelor de date cu
dimensiuni de ordinul TB. Proiectele de data mining vor accentua şi ami mult importanţa
calităţii datelor din depozitele de date.
Tehnologiile data warehouse continuă să fie influenţate de poularitatea soluţiilor
bazate pe Intranet şi Internet. Ca urmare, din ce în ce mai multe instrumente de acces la date
vor putea suporta facilităţile oferite de web. Unele organizaţii au început deja să folosească
infrastructura Internetului pentru a oferi utilizatorilor posibilitatea de a utiliza depozitul de adte
de la distanţă, însă în acest caz este trebuie avută în vedere problema securităţii acestui
mediu.
Exemplul 1. NAWQA – Water Quality Data Warehouse este un depozit unde se colectează
date despre calităţile chimice, biologice şi fizice ale apei din 42 de bazine din SUA. Se
măsoară zilnic: concentraţiile în apă, sedimente şi ţesuturi organice pentru aproximativ 600
de constituenţi chimici. De asemenea, se păstrează date privind nivelul apelor în aceste
bazine hidrografice.
53
activităţilor HRSA, oferă un instrument de raportare pentru generarea şi utilizarea tabelelor.
Un instrument de tip hartă este disponibil pentru cei ce vor să plaseze date într-un context
geografic. Datele depozitului sunt actualizate cu regularitate şi se adugă noi surse de
informaţii. În continuare este prezentată secţiune de arii ale site-ului
(http://datawarehouse.hrsa.gov/).
2. datawarehouse.ittoolbox.com
Instrumente pentru lucrul cu depozite de date.
3. freedatawarehouse.com
Concepte şi elemente practice.
4. www.infogoal.com/dmc/dmcdwh.htm
Informaţii despre: Data Warehouse, Data Mart, Data Mining, Decision Support
Resources.
5. www.datawarehousingonline.com
Resurse, tehnologii şi soluţii.
6. http://dbvis.inf-uni-konstanz.de/~keim/PDF/Vis04Tutorial.pdf
Articolul Information Visualization and Visual Data Mining, autori: Grinstein G.,
Keim D.A., Ward M., 2004. Prezintă istoria domeniilor vizualizare de date şi data mining,
tehnici şi sisteme de vizualizare, exemple de aplicabilitate în chimie.
7. www.nag.co.uk
The Numerical algorithms Group Ltd, Oxford. Oferă componente şi tehnologii data
mining şi vizualizare, pentru mai mult de 10000 de organizaţii din întreaga lume. Software şi
servicii de dezvoltare de aplicaţii (în bio-informatică, e-business, detecţia fraudelor, analiză
web).
54
9. Baze de cunoştinţe
55
(7) NOT D OR C
Aplicând din nou rezoluţia pentru formulele (7) şi (4) în raport cu D se obţine
(8) C
şi din (8) şi (5) unde rezoluţia se aplică în raport cu C se obţine clauza vidă, ceea ce
demonstrează că aserţiunea iniţială este adevărată.
Cererile pentru baza de cunoştinţe pot fi exprimate sub următoarea formă generală:
A1 AND A2 AND …AND Am ⇒ B1 OR B2 OR …OR Bn (*)
unde A1, A2, …, Am şi B1, B2, …, Bn sunt de forma r(x1, x2, …,xt) cu r predicat având
argumentele x1, x2, …,xt.
Dacă toate argumentele sunt constante, predicatul reprezintă o axiomă de bază şi
este o propoziţie adevărată. În termenii bazelor de date, (x1, x2, …,xt) este unul din tuplurile
existente în baza de date. În acest sens, predicatul r afirmă ceva în concordanţă cu înţelesul
pe care îl are relaţia R.
Pentru m>0 şi n=1, (*) devine clauza:
A1 AND A2 AND …AND Am ⇒ B
care poate fi privită ca o axiomă deductivă. Această axiomă deductivă dă o definiţie parţială
a predicatului din partea dreaptă a implicaţiei, în funcţie de predicatele din partea stângă.
Poate fi privită şi ca o constrângere de integritate.
Vederile unei baze de date pot fi privite ca modele teoretice. În aceste modele,
domeniile de bază conţin valori sau constante ce pot să descrie anumite obiecte ale lumii
reale, acestea formând contextul (ce poate fi privit ca un „univers”). Relaţiile de bază
reprezintă o mulţime de predicate sau formule deschise (cu variabile) ce urmează să fie
interpretate în acel context. Fiecare tuplu al unei relaţii reprezintă o particularizare a
predicatului corespunzător (adică o formulă închisă, fără variabile) care are valoarea adevărat
pentru universul respectiv. Constrângerile (restricţiile) de integritate sunt tot formule închise,
interpretabile în contextul respectiv. Prin urmare, tuplurile şi constrângerile de integritate pot fi
privite ca formând mulţimea axiomelor ce definesc o anumită teorie logică. Baza de date
poate fi privită ca mulţimea tuturor teoremelor ce se pot demonstra pornind de la axiome.
Evaluarea cererilor se face analog cu demonstrarea teoremelor.
Ca axiome ale unei baze de date pot fi considerate următoarele:
1. Axiomele de bază – corespund tuplurilor relaţiilor de bază, ele definind aşa-numita
bază de date extinsă (extensional database).
2. Câte o axiomă de completitudine pentru fiecare relaţie, prin care se afirmă că nu
există alte tupluri decât cele care apar efectiv în relaţia respectivă. Aceasta se mai
numeşte presupunerea de închidere (Closed World Assumption), prin care se
consideră false aserţiunile pentru tuplurile ce nu apar în relaţie.
3. Axioma numelui unic – prin care se afirmă că fiecare constantă se distinge de toate
celelalte constante (are nume unic).
4. Axioma închiderii domeniului – prin care se afirmă că nu există alte constante în
afară de cele existente în domeniul bazei de date.
5. O mulţime de axiome standard, prin care se defineşte predicatul „=”.
Un sistem deductiv de baze de date este un SGBD care permite construirea
vederilor cu demonstrare teoretică şi care este capabil, în particular, să deducă fapte
suplimentare din baza de date existentă aplicând axiome deductive sau reguli de inferenţă.
Axiomele deductive împreună cu constrângerile de integritate formează ceea ce se numeşte
conţinutul intern al bazei de date (intensional database) şi aceasta, împreună cu extinderea
bazei de date (care conţine informaţiile) formează baza de date deductivă (deductive
database).
56
10. Aplicaţii Access
Acest capitol conţine patru aplicaţii Access comentate, în scopul prezentării celor mai
utile informaţii privind realizarea bazelor de date relaţionale.
ELEVI
nr matricol
nume si prenume
clasa
scoala
CURSURI
URMEAZĂ cod curs
denumire curs
ziua
ora inceperii
SUSŢIN evenimente
PROFESORI
cod profesor
specializarea
norma de baza
57
În reprezentarea de mai sus, atributele subliniate cu linie continuă caracterizează în
mod unic realizările de entitate (un număr matricol este specific unui elev şi numai unuia,
aceeaşi proprietate este valabilă pentru codul unui profesor, fiecare curs are un cod unic iar
fiecare linie a tabelului repartiţie este identificată printr-un număr, păstrat în câmpul cod). Un
atribut cu această proprietate (de identificare a realizărilor unei entităţi) se numeşte cheie
primară. De exemplu, atributul cod curs realizează diferenţierea a două cursuri (în baza
noastră de date, două cursuri cu aceeaşi denumire – Pictură – sunt susţinute de profesori
diferiţi, în zile diferite din săptămână; este evident că nu ar putea fi identificate prin denumire).
Câmpurile subliniate cu linie punctată au un rol de legătură, şi anume, modelează
relaţiile între entităţile identificate în faza de analiză. Aceste câmpuri se numesc chei
secundare sau externe (cod curs pentru tabela profesori, nr matricol şi cod curs pentru
tabela repartiţie). În timp ce cheile primare au valori unice, cheile secundare pot avea valori
duplicate (se va observa, studiind baza de date oferită ca exemplu, că numărul matricol 101
apare în trei linii ale tabelei repartiţie, iar cursul cu codul 3 în patru linii).
Vom studia în continuare procedeele prin care transpunem acest model într-o bază
de date Access şi cum putem folosi această bază de date.
În fereastra Microsoft Access optăm pentru crearea unei baze de date goale (Blank
Access database) şi tastăm OK. Apare caseta File New Database, în care introducem numele
dorit (în cazul nostru, instruire). În zona de lucru a aplicaţiei apare fereastra Database,
aceasta fiind fereastra principală a noii baze de date, prin intermediul căreia putem accesa
toate obiectele ei. Se observă că în zona din stânga ferestrei obiectele sunt grupate pe tipuri
(tablouri, cereri, etc.), iar în zona din dreapta se regăsesc instrumente de lucru şi obiectele de
tipul curent. Astfel, în imaginea de mai jos nu figurează tabele (acestea vor fi primele obiecte
create), dar se pot observa instrumentele prin intermediul cărora putem accesa diferitele
modalităţi de creare a tabelelor. Se observă că eticheta fiecărui grup de obiecte este
precedată de o imagine semnificativă. Imediat sub bara de titlu a ferestrei se pot observa
butoane de manevră a obiectelor de tipul curent (de exemplu, pentru tabele, Open, Design,
New şi Delete permit deschiderea în mod tabel, deschiderea în mod proiectare, crearea unui
tabel nou şi respectiv ştergerea unui tabel) şi butoanele pentru diferite afişări ale
pictogramelor obiectelor (Large Icons, Small, List şi Detail).
58
Crearea tabelelor
Prin realizarea unui dublu clic pe opţiunea Create table in design view se deschide
fereastra Table, în cadrul căreia se definesc:
• numele câmpului (Field Name), ce poate fi format din mai multe cuvinte, trebuie să fie
sugestiv (să sugereze conţinutul câmpului pe care îl numeşte). De exemplu, "nr
matricol" este numele câmpului care va conţine numărul matricol al unui elev.
• tipul câmpului (Data Type). Un tip de dată defineşte atât mulţimea valorilor pe care le
poate lua data respectivă, cât şi tipul operaţiilor ce se pot aplica asupra ei. Un clic pe
săgeata derulantă deschide lista opţiunilor (Text, Memo, Number, Date/Time, etc.).
• descrierea (Description), acest element fiind opţional (o descriere a câmpului
respectiv, de exemplu pentru "nr matricol" s-a precizat că reprezintă un cod intern,
necesar identificării elevilor în cadrul activităţii de instruire suplimentară).
59
Se observă în această fereastră (în cazul de faţă, pentru editarea relaţiei ELEVI –
REPARTIŢIE) cele două tabele relaţionate, cheile primară şi secundară. Bifarea proprietăţii
Enforce Referential Integrity) activează un mecanism al sistemului de gestiune Access, prin
care nu este permisă introducerea datelor în tabele REPARTIŢIE, înaintea celor din tabela
ELEVI. Cu alte cuvinte, un elev cu numărul matricol 300 nu poate figura în tabela
REPARTIŢIE, înainte de a fi fost introdus în ELEVI. Această ordine de introducere este
naturală, nu putem repartiza elevii la cursuri înainte de a-i "înscrie". Situaţia se prezintă la fel
şi în cazul relaţiei CURSURI – REPARTIŢIE: trebuie să memorăm mai întâi datele despre un
curs şi apoi să repartizăm elevi la acest curs. Se observă că acest mecanism este unul de
păstrare a integrităţii referenţiale a bazei (după cum indică şi numele proprietăţii), astfel este
prevenită introducerea greşită a datelor şi sunt eliminate multe incoerenţe.
Iată fereastra Relaţii pentru baza de date instruire:
60
deplasarea stânga-dreapta (evident, ar apărea şi un cursor vertical dacă fereastra nu ar
conţine decât o parte din liniile tabelului).
Formulare
În cadrul aplicaţiei noastre, este creat un formular cu numele CURSURI, pentru
introducerea datelor în altă formă decât cea tabelară. Avantajul este o interfaţă deosebită,
care permite posibilitatea afişării unor indicaţii pentru cel care introduce datele (această
activitate fiind semnificativă, în cazul bazelor de date mari).
Antet
Zonă
de
detaliu
Subsol
61
Crearea formularului CURSURI
Efectuăm clic pe Formulare în fereastra Bază de date şi selectăm opţiunea Creare
formular utilizând Expertul. În continuare se selectează tabela cursuri şi acţionăm butonul
OK:
Urmează acum selectarea câmpurilor pe care le dorim în formular. Pentru selectarea tuturor
câmpurilor (situaţia cea mai comună), realizăm clic pe butonul .
62
rând, coloană şi arii detaliu) şi PivotChart (afişarea date vizuală prin selectarea unui tip de
diagramă şi aranjarea câmpurilor în filtru, serie, categorie şi arii date). Un formular PivotTable
efectuează calculele alese, ca sume (implicit pentru câmpurile numerice) şi numărări (implicit
pentru câmpuri text), bazat pe modul în care sunt aranjate datele. De exemplu, un formular
PivotTable poate afişa valorile unui câmp orizontal sau vertical şi apoi calculează totalul
rândului sau coloanei. De asemenea, un formular PivotTable poate folosi valorile unui câmp
drept titluri de rând sau de coloane, calculând cantităţile individuale la intersecţia titlului
fiecărui rând cu fiecare coloană, iar apoi calculând subtotaluri şi totaluri generale. De
exemplu, pentru a analiza produsele vândute de fiecare angajat: se pot lista numele
angajaţilor ca titlurile coloanelor în partea superioară a formularului PivotTable, produsele ca
titlurile rândurilor în partea de jos a formularului PivotTable, iar suma vânzărilor calculată
după produse pentru fiecare angajat la intersecţia fiecărui rând cu fiecare coloană. Formularul
PivotChart permite reprezentarea grafică a datelor, folosind tipurile oferite de Excel: coloană,
bară, structură inelară, radială, etc.
În următoarea fereastră se selectează stilul formularului (stilul implică un fundal, un tip de font
pentru date, culori, aşezare etc.):
63
Ultimul pas se referă la alegerea unui nume pentru formular şi dialogul se încheie cu
clic pe Finish.
Un alt formular (cu numele elevi) este proiectat asemănător; la activarea sa (de
exemplu, cu dublu clic) va afişa, în forma proiectată, conţinutul curent al tabelei ELEVI. Iată
cum se reflectă corecţia efectuată în câmpul şcoala, pentru elevul cu numărul matricol 303
(schimbarea valorii câmpului din 26 în 28):
Vom observa în continuare cum arată acest formular în mod proiectare (această vedere se
poate obţine selectând formularul în fereastra Database şi apoi realizând clic pe butonul
Proiect):
64
Fiecare componentă a formularului (Antet, Detaliere, Subsol) are proprietăţi care se pot seta
prin deschiderea meniului contextual aferent (clic dreapta pe şi selectarea
opţiunii Proprietăţi, care deschide meniul prezentat în continuare).
Acestea au funcţii numeroase şi complexe, dar eticheta este controlul cel mai simplu
de utilizat. Etichetele afişează textul indicat – astfel au fost create antetul şi subsolul
formularului cursuri.
Să realizăm un subsol şi pentru formularul elevi. Pentru aceasta, urmăm etapele de
mai jos:
• modificăm zona Subsol Formular, plasând cursorul pe linia inferioară, până când
devine de forma: apoi tragem până mărim zona după dorinţă;
65
• acţionăm butonul Label (al treilea de pe bara de mai sus) şi ducem cursorul în zona
creată. Forma cursorului se schimbă, devenind un simbol A precedat de o cruce.
Punctul unde plasăm mijlocul crucii devine colţul din stânga sus al zonei destinate
etichetei;
• mişcăm cursorul spre dreapta şi în jos, până obţinem dimensiunea dorită a etichetei
şi eliberăm butonul mouse-ului;
• în interiorul zonei etichetei edităm textul dorit şi, dacă dorim, putem modifica
proprietăţile etichetei (culoare de fond, mărimea caracterelor etc.) selectând din
meniul rapid (obţinut cu clic dreapta) eticheta Proprietăţi, ca în imaginea următoare:
66
• în fereastra Database, clic pe Interogări şi apoi pe Creare interogare în modul
Vizualizare proiect;
• pe ecran apar fereastra Interogare de selectare şi caseta de dialog Afişare Tabel:
o din caseta Afişare Tabel se selectează tabelele şi/sau cererile din care dorim să
extragem date, după care închidem caseta;
o fereastra Interogare de selectare are două zone: cea superioară, în care vedem
tabelele şi/sau cererile selectate, împreună cu legăturile dintre ele şi cea
inferioară, numită grilă de proiectare sau grilă QBE (Query By Example – cerere
prin exemplificare), în care se va proiecta efectiv cererea.
67
Iată şi rezultatul execuţiei cererii (se execută prin dublu clic pe pictograma sa), aşa
cum a fost proiectată până în momentul de faţă:
Sortarea datelor
Ordonarea datelor într-o cerere se poate realiza crescător sau descrescător, după
mai multe câmpuri numite chei de sortare. Se realizează clic în celula din grilă aflată la
intersecţia coloanei câmpului de sortare cu linia Sort şi se alege între Ascending (crescător) şi
Descending (descrescător). Iată grila QBE a unei cereri de interogare prin care se
vizualizează elevii înscrişi la cursurile facultative, în ordinea claselor. În cadrul unei clase,
elevii apar în ordine alfabetică. Prima cheie este de tip numeric iar a doua de tip text.
68
Se observă că ordinea câmpurilor de sortare (în cazul în care sunt mai multe)
influenţează rezultatul obţinut.
Selecţia datelor
Pentru a selecta dintre date pe acelea care ne interesează la un moment dat se
utilizează criterii de selecţie. Acestea pot fi:
• Compuse. Se constituie din criterii simple, legate între ele prin operatorii logici AND
(conjuncţia) şi OR (disjuncţia). În acest sens, grila QBE utilizează mai multe linii
Criterii, iar regulile pentru construcţia criteriilor compuse sunt următoarele:
o criteriile simple aflate pe aceeaşi linie Criterii sunt implicit conectate prin AND
(deci vor fi satisfăcute simultan);
o dacă selecţia valorilor unui câmp se face după mai multe criterii simple conectate
prin OR, acestea se vor specifica pe aceeaşi linie. Exemplu:
69
o dacă selecţia se face după mai multe criterii simple aplicate unor câmpuri diferite,
criteriile fiind conectate prin OR, acestea se vor specifica pe linii diferite.
Exemplu:
Operaţii predefinite
Access permite realizarea unor operaţii de calcul predefinite, care se pot realiza
asupra unui întreg tabel sau asupra unui grup de înregistrări. Sunt disponibile următoarele
operaţii predefinite:
• SUMĂ – calculează suma valorilor unui câmp;
• MEDIE – calculează media aritmetică a valorilor unui câmp;
• MIN – returnează valoarea minimă;
• MAX – returnează valoarea maximă;
• CONTOR – numără valorile dintr-un câmp;
• STDEV (de la Standard deviation) – calculează abaterea medie pătratică sau
varianţa valorilor unui câmp (reprezintă o măsură a abaterii valorilor de la media lor);
• VAR – varianţa statistică a valorilor luate de un anumit câmp;
• PRIM - întoarce prima valoare din câmp;
• ULTIM – întoarce ultima valoare din câmp.
70
Pentru realizarea unei operaţii de acest gen asupra tuturor înregistrărilor tabelei se
realizează următorii paşi (vom exemplifica pentru a calcula media notelor elevilor):
• se creează o cerere care conţine doar câmpurile asupra cărora vor acţiona operaţiile
de calcul;
• se acţionează View, Totals, efectul fiind introducerea în grila QBE a liniei TOTALS,
care va conţine pentru toate câmpurile operaţia Goup By în capul unei liste derulante;
• se alege din lista derulantă operaţia dorită;
• se execută cererea prin Query, Run şi se observă rezultatul.
Iată cererea în mod proiectare şi imaginea execuţiei acesteia:
Pentru realizarea unei operaţii predefinite asupra unui grup de înregistrări, cel puţin un câmp
din cerere trebuie să conţină operaţia Group By, pentru a se preciza gruparea. Dacă sunt
prezente mai multe criterii de grupare, ordinea de evaluare este de la stânga la dreapta. Iată
o cerere care determină mediile elevilor, grupaţi după cele 4 cursuri. În grila de proiectare se
observă gruparea înregistrărilor după câmpul cod curs:
71
Se observă formatul general al câmpului AvgOfapreciere (afişarea tuturor zecimalelor
semnificative), iar pentru ultima valoare rotunjirea ultimei poziţii.
Rapoarte
Rapoartele (Reports) sau situaţiile finale constituie prezentări ale datelor pe suport de
hârtie. Aceste rapoarte au fost folosite totdeauna, constituindu-se în documente oficiale,
purtătoare ale semnăturilor persoanelor autorizate. Realizarea unui raport implică
prezentarea datelor dorite într-un format cât mai convenabil, conform cu necesităţile de
informare (de exemplu pot conţine totaluri, subtotaluri, grafice, diagrame). În general, datele
care apar în rapoarte sunt preluate din tabele sau din cereri. Mai ales dacă datele provin din
mai multe tabele se preferă realizarea mai întâi a unei cereri şi apoi a raportului
corespunzător. În afară de datele propriu-zise, situaţiile finale mai conţin:
• controale;
• zone de text;
• cadre (pentru imagini şi grafice);
• etichete (pentru realizarea unui format cât mai atrăgător).
Pentru a crea un raport putem folosi instrumente wizard sau proiectarea directă, dar o
metodă convenabilă este (ca şi în cazul formularelor) îmbinarea acestor două facilităţi, astfel:
• în fereastra Database se activează Rapoarte, apoi Creare raport utilizând Expertul;
• se selectează numele tabelei sau cererii care furnizează datele raportului;
• se trece în mod proiectare (cu clic pe Design View) şi se modifică raportul conform
dorinţei proiectantului, adăugându-se text, controale, etc.
Spre exemplificare, să construim un raport care să prezinte situaţia elevilor înscrişi la
cursurile suplimentare în anul curent. Elevii să fie grupaţi pe şcoli şi pentru fiecare să se
precizeze clasa şi cursul pe care îl frecventează.
Observăm că datele cerute în raport se află în trei tabele: ELEVI (numele, clasa, şcoala),
REPARTIŢIE (corespondenţa elev-curs) şi CURSURI (denumirea cursului). Construim mai
întâi o cerere care să adune aceste date. Iată structura sa, în mod proiectare:
72
Utilizând metoda descrisă anterior, construim o situaţie finală cu ajutorul instrumentului
wizard, după care o modificăm astfel încât să se plaseze frumos pe o pagină A4, adăugăm un
titlu, un subsol şi linii separatoare între grupurile de elevi aparţinând aceleiaşi şcoli. Forma
Vizualizare Proiect a raportului este următoarea:
iar sfârşitul listei conţine ziua, data şi numărul paginii curente (din totalul de pagini).
73
Se observă că structura situaţiei finale include: antetul general, antetul de pagină, antetul
de grup (în cazul de mai sus, cel referitor la şcoală), rândul de detaliu, subsolul de pagină şi
subsolul de raport. După crearea unei situaţii finale, rezultatul poate fi vizualizat (înainte de
imprimare), ceea ce permite verificarea datelor şi a aspectului general al raportului.
Ca şi în cazul celorlalte obiecte, cititorul care studiază aplicaţia Access va descoperi
numeroase posibilităţi de a realiza un raport.
74
10.2. Bază de date pentru o activitate comercială
În cadrul acestei aplicaţii vom simula activitatea comercială a unei firme. Vom descrie
furnizorii şi produsele achiziţionate de firmă, personalul firmei, clienţii si comenzile pe care
aceştia le emit, precum şi modul de transport al produselor către clienţi. Vom presupune că
un produs, identificat prin codul său, Produs_id, este cumpărat de la un singur furnizor, pentru
a putea relaţiona tabelele Furnizori şi Produse printr-o legătură de tip 1-n. Tot pentru
simplitate, vom considera că fiecare client emite câte o comandă pentru fiecare produs, astfel
că tabelele Clienţi şi Comanda au o relaţie 1-n, iar tabelele Comanda şi Produs_comanda au
o relaţie 1-1.
Aplicaţia este constituită din 8 tabele, având următoarele câmpuri:
Acest model logic al aplicaţiei evidenţiază atât cheile primare (subliniate cu linie
continuă), cât şi cheile externe (subliniate cu linie punctată).
Crearea tabelelor se poate realiza în trei moduri:
• utilizând fereastra de proiectare (Creare tabel în modul Vizualizare proiect). Este
modalitatea recomandată, pe care o vom explica în continuare.
• utilizând instrumentul Wizard (Creare tabel utilizând Expertul). Se creează tabele prin
alegerea unor câmpuri standard.
• prin introducerea datelor (Creare tabel prin introducere date). Această modalitate nu
poate fi aplicată aplicaţiilor complexe, dar este utilă în cazul aplicaţiilor foarte simple, în
care avem nevoie de rapiditate în crearea tabelelor.
Dacă selectăm opţiunea Creare tabel în modul Vizualizare proiect, se deschide o
fereastră în care se precizează structura tabelului: numele câmpurilor, tipul şi proprietăţile
acestora.
75
Tipurile de bază din Access sunt următoarele:
• Text. Un câmp de acest tip conţine cel mult 255 caractere (implicit, lungimea este de
50). De tip text sunt definite câmpurile care conţin nume de persoane, denumiri,
adrese etc.
• Memo. Pot conţine cel mult 64000 caractere (cu comentarii, explicaţii). Câmpurile de
tip Text şi Memo sunt numite alfanumerice (pot conţine caractere şi/sau numere). Iată
exemple de valori alfanumerice (le vom delimita cu " "): "Dragoş", "Mircea cel
Bătrân", "Oţel laminat OL 50", "X4532A", "345990".
• Număr. Este tipul numeric, cu mai multe subtipuri disponibile, determinate de
dimensiunea câmpului:
o Octet – valori întregi, pozitive, reprezentate pe un octet;
o Întreg - valori întregi, pozitive şi negative, pe doi octeţi;
o Întreg lung – valori întregi, pozitive şi negative, pe patru octeţi;
o Simplă precizie – valori reale, cu cel mult 7 zecimale, pozitive şi negative, pe
patru octeţi;
o Dublă precizie - valori reale, cu cel mult 15 zecimale, pozitive şi negative, pe opt
octeţi;
o ID reproducere – identificator global unic, pe 16 octeţi;
o Zecimal - valori întregi, pozitive şi negative, pe 16 octeţi.
• Dată/Oră. Este un tip special creat pentru date calendaristice sau de tip oră, întrucât
aceste valori se întâlnesc adesea în documente, înregistrări. Permite, de asemenea,
diferite formate de afişare, de exemplu: Sunday, August 11, 2003 şi 8/11/03
reprezintă data de 11 august 2003, duminică iar 5:00:00 PM şi 17:00 reprezintă ora 3
după amiază.
• Monedă. Acest format fix, cu patru zecimale, permite lucrul cu valori monetare.
• AutoNumerotare. Câmpurile de acest tip sunt completate în mod automat pentru
fiecare înregistrare adăugată într-o tabelă, fie crescător, fie cu valori aleatoare
(întâmplătoare), după cum alege utilizatorul.
• Da/Nu. Conţin de fapt valori logice, reprezentate prin –1 (pentru Yes, True –
adevărat) şi prin 0 (pentru No, False – fals).
Observaţie. Câmpurile de tip: Număr, AutoNumerotare, Da/Nu şi Monedă sunt
de tip numeric, deci conţin numere reprezentând: cantităţi, coduri, sume de
bani, valori logice de adevăr. Iată exemple de valori numerice: 23.90, 6785,
1. Vom vedea că o dată numerică poate fi afişată în formate diferite.
• Obiect OLE. Reprezintă obiecte mari, de tipul imaginilor, desenelor, fişierelor audio.
• Hyperlink. Conţine un text ce este o adresă a unei pagini Web.
• Expert căutare. Creează câmpuri care permit alegerea de valori din cadrul unor
structuri (tabele, liste), deci permit legarea informaţiilor.
76
Observăm cheia primară Agent_id şi proprietăţile câmpului Nume_agent. După
realizarea tuturor tabelelor, relaţiile se construiesc astfel: se acţionează butonul Relationships
de pe bara Database, în fereastra Afişare Tabel se includ toate tabelele deja create, prin
selectarea lor şi apoi punctarea repetată a butonului Adăugare:
77
Introducerea articolelor în tabele se realizează astfel: în fereastra Bază de date se
efectuează dublu-clic pe numele tabelului (de exemplu, Furnizori) şi se introduc valorile
câmpurilor din fereastra care se deschide. În imaginea următoare, se observă cum tabelul
Furnizori are 15 articole. La fel se introduc articole în toate tabelele, în ordinea indicată de
relaţiile deja definite. Dacă se produc erori din punctul de vedere al integrităţii referenţiale,
acestea sunt semnalate printr-un mesaj care cere corectarea câmpului respectiv.
O metodă alternativă pentru introducerea de articole într-un tabel este realizarea unui
formular, care să ofere o altă prezentare a câmpurilor. Un formular creat în modul Vizualizare
proiect este individualizat, deoarece permite intervenţia programatorului la un nivel înalt. În
continuare vom prezenta crearea în acest mod a formularului pentru introducerea comenzilor.
În fereastra Bază de date se selectează opţiunea Formulare şi apoi Creare formular
în modul Vizualizare proiect. După apariţia ferestrei de editare a formularului, prin clic dreapta
pe titlul ferestrei deschidem un meniu contextual din care alegem ultima opţiune: Proprietăţi.
78
Fereastra Formular permite
alegerea tabelului în care vom
introduce date, prin clic de eticheta
Date şi derularea listei de opţiuni
posibile pentru Sursă înregistrări.
Alegem tabelul Comanda şi
observăm că apare o nouă fereastră
care conţine lista câmpurilor
acestuia:
Prin tragerea câmpurilor din această fereastră (cu ajutorul mouse-ului) până în zona
Detaliu a formularului, fixăm poziţiile lor pe grilă.
Fiecare element al formularului este alcătuit dintr-un text explicativ, respectiv numele
câmpului şi o zonă de introducere a valorii câmpului respectiv. În figura de mai jos este
selectat elementul corespunzător numărului comenzii. Deplasarea relativă a componentelor
se realizează prin tragere de colţul stânga-sus, evidenţiat. Deplasarea integrală se face prin
tragere de margine.
79
Pentru a obţine o aliniere, se pot selecta
mai multe elemente, prin menţinerea apăsată
a tastei Shift şi tragere de mouse. Apoi se
deschide meniul contextual ataşat prin clic
dreapta pe unul dintre elementele selectate.
Din acesta alegem opţiunea Align, Stânga.
Prin clic dreapta pe grilă putem alege opţiunea
Proprietăţi, care permite selectarea din
eticheta Format a unei culori a grilei (opţiunea
Culoare fundal).
Din acelaşi meniu putem îmbogăţi formularul prin adăugarea unui antet/subsol ale
paginii sau ale întregului formular (Page Header/Footer, Form Header/Footer).
Întroducerea datei şi a orei curente se face prin alegerea din meniul Insert a opţiunii
Date and Time.
Introducerea numărului curent de pagină se face din acelaşi meniu, opţiunea Page
numbers.
La subsolul formularului, introducem menţiunea de responsabilitate, sub forma unei
etichete care conţine numele persoanei care a realizat formularul.
Imaginea următoare prezintă formularul, în modul proiectare.
80
Acest formular, folosit la introducerea datelor, are următorul aspect:
81
Rapoartele sunt situaţii finale, care nu mai permit intervenţii ale operatorului. Să
presupunem că se doreşte realizarea unui raport care să conţină agenţii firmei, grupaţi după
oraşele de reşedinţă. În fereastra Bază de date se selectează Rapoarte şi se alege opţiunea
Creare raport utilizând Expertul. În prima fereastră de dialog se aleg câmpurile care se includ
în raport, prin transfer din stânga în dreapta cu ajutorul butoanelor şi . Primul buton
transferă câmpul curent, iar cel de-al doilea transferă toate câmpurile în viitorul raport.
82
Pentru o aşezare plăcută a articolelor în raport, se alege o sortare a agenţilor din
fiecare grup, crescătoare după câmpul Nume_agent.
83
În final, alegem numele raportului: Agenţi. Observăm că aplicaţia poate manevra
obiecte diferite (tabel şi raport) cu acelaşi nume.
84
După salvare, executăm raportul prin dublu-clic pe numele său din fereastra Bază de
date. Imaginea următoare prezintă o parte din raportul Agenţi.
85
10.3. Bază de date pentru gestiunea unui parc auto
Această aplicaţie propune realizarea unei baze de date conţinând informaţii despre
maşinile dintr-un garaj. Pentru fiecare maşină se vor memora informaţii cum ar fi:
- tipul maşinii;
- destinaţia: transport de persoane sau marfă;
- firma producătoare;
- data fabricaţiei;
- capacitatea cilindrică;
- număr km. parcurşi;
- consumul specific;
- data achiziţionării.;
Aplicaţia va fi dotată cu facilităţi referitoare la validarea datelor introduse. Când
numărul opţiunilor (pentru valorile unei anumite date) este mic, se vor pune la dispoziţia
utilizatorilor opţiunile din care aceştia să aleagă. Vor fi prevăzute principalele operaţii
efectuate asupra datelor în bazele de date:
- adăugarea de noi date;
- modificarea datelor existente;
- ştergerea datelor;
- afişarea datelor pe ecran şi la imprimantă.
86
Cerinţele problemei specifică validarea datelor introduse. Validarea este un
instrument informatic ce împiedică apariţia unor greşeli de introducere simple cât şi a unor
inconsistenţe greu de verificat fără instrumente informatice (exemplu: coduri unice atribuite
repetat). Bazele de date relaţionale s-au îndepărtat puternic de modelul „validării batch”, care
se aplică post-factum pe loturi de date, deoarece au introdus integritatea referenţială bazată
pe chei unice, chei străine şi verificări simple (numerice, logice) înglobate direct în baza de
date şi nu în program. Validările bazate pe integritatea referenţială sunt însă adeseori
completate cu validări-program pe formularele de introducere.
În cele ce urmează, vom înţelege garajul ca o unitate (agent economic) ce dispune de
maşini cu care efectuează curse. Aceste curse determină tranzacţii, stocate fiecare din ele în
baza de date. Ca urmare a curselor, se modifică numărul de km. parcurşi de fiecare maşină.
Iată cum arată fereastra Relationships a bazei de date.
Cu excepţia colţului din stânga-jos, unde sunt specificate două interogări necesare
pentru calculul numărului de km. parcurşi, toate celelalte sunt tabele, având relaţii între ele.
În plus fată de tabele definite deja, în procesul de analiză s-au considerat necesare şi:
• şoferi;
• culori (ale maşinilor);
• tip transport;
• date (adică tranzacţiile curselor).
Cursele sunt cele care determină tranzacţiile. Şoferii fac parte integrantă din
„resursele principale ale curselor”, împreună cu maşinile. Culorile nu apar la fel de importante,
însă în proiectare unei baze de date amănuntele sunt semnificative. Am disociat tip transport
de marca maşinii, deoarece reprezintă o caracteristică comună mai multor maşini, ca şi
culorile maşinilor (pot fi mai multe astfel de caracteristici comune: cauciucuri, tip carburant,
ulei, practic lista poate fi mare, dar ne vom limita la acestea două). Datele (tranzacţiile
curselor) construiesc numărul de km. parcurşi ai fiecărei maşini.
Relaţiile sunt toate de tipul 1 - n, având fiecare coduri interne ale bazei de date cu
cheie unică pe partea 1 a relaţiilor (reprezentată cu bold). Tabelul Date are cheie unică pe
toate cele 3 câmpuri concatenate, pentru asigurarea unei normalizări suficiente şi protecţie la
duplicate incorecte. Acest lucru se realizează astfel: după definirea numelui câmpurilor, a
tipului şi descrierii lor, se selectează cu butonul Shift ţinut apăsat toate câmpurile tabelului şi
se efectuează clic pe butonul Primary Key din bara de instrumente Table Design.
Selecţia câmpurilor se face prin tragere de mouse, în faţa numelui câmpurilor, pe zona gri.
Rezultatul este prezentat în imaginea următoare.
87
Următoarea imagine prezintă fereastra Bază de date a aplicaţiei, cu obiectele de tip tabel.
88
S-au folosit controale vizuale: câmpuri text/numerice/date calendaristice, combo, liste,
butoane, control-tab. S-au folosit atât forme simple, cât şi mai complexe (tab-uri, master-
detail), pentru care Access oferă suport puternic şi accesibil. S-au folosit controalele de
navigare implicite ale Access. Toate cheile unice sunt pe câmpuri de tip Autonumerotare
(secvenţe). Următoarea imagine prezintă fereastra Bază de date a aplicaţiei, cu obiectele de
tip formular.
End Sub
89
După clic pe butonul , acest formular lansează formularul Curse, care este practic cel
mai complex formular al aplicaţiei. În continuare sunt oferite trei imagini ale acestui formular,
pentru a prezenta respectiv: resursele cursei, resursele pentru toate cursele şi distanţa totală
parcursă.
90
Schema obiectelor este următoarea:
91
Formular Cod Cursa Distanta (km)
Curse Data Start Note
Data Sfarsit
Buton soferi
Buton masini
Buton Preview Raport: Curse
Buton Listare
Buton Adaugare
Buton Stergere
Observaţii:
- săgeţile groase deschid prin dublu clic (pe grid) opţiunile respective;
- săgeţile groase punctate deschid prin clic opţiunile respective.
92
End If
Exit_Data_Sfarsit_Exit:
Exit Sub
Err_Data_Sfarsit_Exit:
MsgBox Err.Description
Resume Exit_Data_Sfarsit_Exit
End Sub
93
DoCmd.OpenForm stDocName, , , stLinkCriteria
Exit_Open_Soferi_Click:
Exit Sub
Err_Open_Soferi_Click:
MsgBox Err.Description
Resume Exit_Open_Soferi_Click
End Sub
Private Sub Open_Masini_Click()
On Error GoTo Err_Open_Masini_Click
Dim stDocName As String
Dim stLinkCriteria As String
stDocName = "Masini"
DoCmd.OpenForm stDocName, , , stLinkCriteria
Exit_Open_Masini_Click:
Exit Sub
Err_Open_Masini_Click:
MsgBox Err.Description
Resume Exit_Open_Masini_Click
End Sub
Formularul Maşini permite vizualizarea datelor şi introducerea de noi articole în baza de date.
94
Butonul acţionat cu dublu clic deschide forma de editare/adăugare item listă. Butonul
acestui raport, iar butonul permite ştergerea unui maşini din baza noastră de date.
95
DoCmd.DoMenuItem acFormBar, 3, 0, , acMenuVer70
End If
End Sub
Dintre rapoartele ce se pot realiza în cadrul aceastei aplicaţii, prezentăm Curse şi Tip maşină:
96
Interogările Distanţe şi Distante Query sunt prezentate în continuare.
Această comandă este vizibilă dacă din meniul View se alege opţiunea SQL View.
97
Interogarea Distante Query necesită adăugarea tabelelor Masini şi Distante, iar în
grilă se includ câmpurile Cod Identificare Masina, Număr Maşină, Nr Km Iniţiali din tabela
Maşini şi câmpul calculat Distanţe Parcurse, aflat pe baza valorilor câmpului Distanţa din
tabela Distanţe. În plus, se afişează articolele sortate ascendent după primul câmp al
interogării.
Funcţiile aplicaţiei
Aplicaţia „Garaj” asigură gestiunea operativă a principalelor resurse ale unui garaj
(privit ca un agent economic), care efectuează curse cu maşini şi şoferi. Fiecare cursă este
memorată individual:
- data start a cursei;
- data sfârşit a cursei;
- distanţa cursei;
- note despre cursă;
- maşini în cursă (pot fi mai multe într-o cursă);
- şoferi în cursă (pot fi mai mulţi într-o cursă).
Se pot adăuga resurse (maşini, şoferi) la garaj. Se pot şterge doar cele complet
nefolosite. Pot exista mai multe maşini de acelaşi tip în garaj. Cursele determina tranzacţiile
curselor:
Tranzacţie=(cod cursă, cod maşină, cod şofer).
Aplicaţia este scrisă în Microsoft Access 2000, constând dintr-un fişier Garaj_lg.mdb
(conform paradigmei Access, acesta conţine tabele, relaţiile între tabele, formulare, rapoarte,
interogări, codul VBA). Pentru introducerea datelor se folosesc formulare cu funcţii de
validare (care ghidează utilizatorul).
Funcţiile aplicaţiei sunt cele generale ale unei aplicaţii de baze de date, dar şi
specifice. Pe scurt, aplicaţia Garaj memorează utilizarea în curse a resurselor (maşini, şoferi)
pentru o anumită perioadă de timp, furnizând un punct de vedere raţional asupra gradului de
utilizare a acestor resurse, cât şi asupra distanţelor parcurse sau planificarea consumului de
carburant pentru curse. Funcţia principală este aceea că oferă managementului garajului
98
suport atât pentru deciziile operative, cât şi pentru planificare şi pentru control, având în
centrul atenţiei cursele auto.
Toate intrările/ieşirile sunt conforme cu schema:
În aplicaţie, simbolul este alăturat unei liste ce ramifică programul spre forme de
introducere date (sau editare).
99
10.4. Bază de date pentru contabilitatea TVA
Nivelul conceptual este nivelul central care reflectă datele structurate astfel încât
acestea să poată fi preluate şi prelucrate cu ajutorul unui SGBD.
Schema conceptuală stă la baza modelului conceptual care va permite definirea
proprietăţilor elementare ale obiectelor care interesează în cadrul SC ADES SA, gruparea
acestora, în funcţie de criterii de omogenitate stabilite, în scopul descrierii obiectelor lumii
reale şi a relaţiilor dintre ele. Sunt definite regulile de care trebuie să se ţină seama în
manevrarea datelor existente. Pe baza regulilor de gestiune se stabilesc cardinalităţi sau
conectivităţi între realizările atributelor din entităţi şi cele ale proprietăţilor din asocieri
(corespondenţe). Acestea exprimă maniera de participare a valorilor atributelor din entităţi la
fiecare apariţie de valori din asocieri. Putem vorbi despre o conectivitate minimă (0 sau 1) şi
una maximă (1 sau n). Vom utiliza modelul entitate – asociere.
În urma analizei problemei rezultă următoarele entităţi, care sunt modelate de tabele:
Stabilirea cardinalităţilor
Corespondenţa EMITE
a) dinspre entitatea furnizor (1, n)
- un furnizor emite cel puţin o factură (cardinalitate 1)
- un furnizor poate emite mai multe facturi (cardinalitate n)
b) dinspre entitatea factură (1, 1)
- factura este emisă de cel puţin şi de cel mult un furnizor (cardinalitate 1, 1)
100
Corespondenţa RECEPTIE
a) dinspre entitatea client (1, n)
- un client primeşte cel puţin o factură (cardinalitate 1)
- un client poate primi mai multe facturi (cardinalitate n)
b) dinspre entitatea factura (1, 1)
- factura este recepţionată de cel puţin şi de cel mult un client (cardinalitate 1,1)
• t_soc (id-soc, denumire, CUI, judet, localit, strada, cod_postal, sector, telefon,
administrator, banca, cont_bancar)
• t_furnizor (id-furn, cui, denumire, sediu, telefon)
• t_fact_furn (id-fact, id_furn, nr_fact, data, cota_tva)
• t_fact_furn_prod (id-fact, nr_crt, explicatie, cant, pret_fara_tva)
• t_client (id-client, cui, denumire, sediu, telefon)
• t_fact_client (id-fact, id_client, nr_fact, data, cota_tva)
• t_fact_client_prod (id-fact, nr_crt, explicatie, cant, pret_fara_tva)
Nivelul intern (modelul fizic) este cel ce corespunde structurii în care sunt stocate
datele în interiorul calculatorului. Sunt specificate tabelele (fişierele) care le conţin (nume,
organizare, localizare, etc.), componentele fiecărui fişier (lungime, câmpuri), căile de acces la
componentele tabelelor (indecşi, relaţii, legături între tabele).
Pentru eficientizarea bazei de date este necesară separarea datelor în mai multe
tabele, fiecare având o temă bine definită. Prin această separare se evită redundanţa.
Tabelele astfel rezultate se relaţionează, adică se leagă prin relaţii.
În figura următoare se poate observa fereastra de relaţii a bazei de date.
101
Primul pas în stabilirea relaţiilor între tabelele bazei de date constă în alegerea tipului
de relaţie folosit: în această aplicaţie, toate cele patru relaţii sunt de tipul 1 - n. Urmează
realizarea acestor relaţii: se deschide fereastra Relaţii şi se adaugă toate tabelele; apoi se
trage cu ajutorul mouse-ului câmpul din prima tabelă către câmpul corespondent din cea de-a
doua tabelă; la deschiderea ferestrei Editare relaţii se bifează opţiunile Impunere integritate
referenţială, Actualizare în cascadă câmpuri corelate, Ştergere în cascadă câmpuri corelate.
102
Formulare
Formularele acestei aplicaţii oferă o interfaţă atractivă pentru vizualizarea sau
introducerea datelor din tabele. Prin faptul că urmăresc introducerea sau modificarea datelor
din tabele, după anumite reguli stricte, impuse de programator, permit eliminarea erorilor
provocate de utilizatori la manevrarea datelor.
În cadrul acestei aplicaţii formularele îndeplinesc funcţii de:
• introducere a datelor, formularele fiind create pentru fiecare tabel, în scopul introducerii
datelor în altă formă decât cea tabelară, creându-se o interfaţă deosebită;
• afişare a datelor într-o formă dorită de utilizator, în scopul consultării acestora;
• editare a datelor, datele afişate în cadrul formularelor pot fi modificate sau şterse.
103
3. Formularul cu datele despre furnizorii de produse:
104
6. Formularul ce conţine facturile emise clienţilor de către SC ADES SA, cu produsele
vândute acestora:
105
8. Subformular ce conţine facturile emise clienţilor de societate:
Interogări
106
La execuţia cererii, se obţin următoarele date:
Ce-a de a doua interogare pe care o vom prezenta foloseşte date din 2 tabele şi două
interogări anterioare, pentru a răspunde la întrebarea: Care este valoarea fără TVA şi
valoarea TVA pe fiecare factură? Interogarea q_jv_19 calculează, pentru fiecare factură,
valoarea fără TVA şi valoarea TVA, dacă valoarea din câmpul cota_tva este 19, iar
interogarea q_jv_9 calculează pentru fiecare factură valoarea fără TVA şi valoarea TVA, dacă
valoarea din câmpul cota_tva este 9. După includerea în fereastră a celor patru obiecte care
vor participa la interogare, se trece la completarea grilei. Câmpurile preluate se aleg din
tabele sau din interogări, iar singurul câmp calculat se obţine prin adunarea bazei de
impozitare cu valoarea TVA.
107
Rapoarte
Rapoartele sau situaţiile finale permit extragerea datelor din tabele, constituind
prezentări ale datelor pe suport de hârtie.
Raportul este un obiect al bazei de date asemănător cu interogarea - din punct de
vedere al structurii. Diferenţa faţă de interogări constă în aceea că raportul nu este destinat
afişării pe ecran, ci tipăririi la o imprimantă. Din acest motiv, raportul nu poate fi deschis şi
afişat pe ecran (precum tabelele, formularele şi interogările). Este posibilă numai o
previzualizate a modului cum va arata raportul tipărit.
Rapoartele acestei aplicaţii sunt următoarele:
1. Decontul privind taxa pe valoarea adăugată, este un document contabil, o
declaraţie financiară, ce se întocmeşte de societate în cadrul compartimentului financiar-
contabil pentru fiecare lună. Documentul prezentat reflectă activitatea de vânzare-cumpărare
a societăţii pentru luna decembrie 2004, valoarea facturilor emise de furnizori către SC ADES
SA, precum şi valoarea facturilor emise de SC ADES SA către clienţi, cu procentul taxei pe
valoare adăugată.
Cotele de impozitare prevăzute de lege se aplică la baza de impozitare şi astfel se
determină T.V.A. Aceste cote de impozitare se regăsesc în această aplicaţie şi sunt:
- 19% pentru operaţiunile referitoare la vânzarea-cumpărarea de bunuri şi prestări de
servicii;
- 9% pentru o serie de produse de strictă necesitate cum sunt: carnea de animale şi
păsări, vândute în stare proaspătă, preparate şi conserve, peşte şi produse din peşte,
etc. sau diverse formulare tipizate.
108
Exemplu de calcul a T.V.A. :
În data de 08.12.2004 SC Ades SA vinde către SC Bio Sim SRL 100 de kg.
grâu Dobrogea la preţul unitar de 7000 lei, conform facturii nr. 2584151.
100 kg. x 7000 lei / kg = 700000 lei, care este valoarea facturii fără T.V.A
700000 x 19% = 133000 lei, care este valoarea T.V.A
700000 + 133000 = 833000 lei, care este valoarea totală a facturii (inclusiv T.V.A).
Cu ocazia vânzării produselor, întreprinderea furnizoare percepe (facturează şi
încasează) şi TVA de 19% sau 9% asupra livrărilor. Aceasta suma reprezintă ceea ce numim
TVA colectată. Cum fiecare întreprindere în calitatea ei de client, în momentul aprovizionării a
plătit la rându-i furnizorului său TVA, această TVA deductibilă se va scădea din TVA
colectată, rezultând TVA de plată la buget. Daca TVA colectată este mai mică decât TVA
deductibilă, diferenţa reprezintă TVA de recuperat. Raportul Decont vizualizat în modul
proiect are următoarea imagine.
109
Din decontul SC ADES SA aferent lunii decembrie 2004 rezultă următoarele:
Valoarea totală a facturilor recepţionate de la furnizori cu cota de 19% este de 74.256.000 lei
din care:
- 62.400.000 lei este valoarea fără TVA ,
- 11.856.000 fiind valoarea TVA de 19%.
Valoarea totală a facturilor emise clienţilor cu cota de 19% şi 9% este de 89.301.120 lei din
care:
Vânzări de produse cu cota de 19% :
- 71.500.000 lei este valoarea fără TVA,
- 13.585.000 fiind valoarea TVA de 19%.
Vânzări de produse cu cota de 9% :
- 3.868.000 lei este valoarea fără TVA,
- 348.120 lei fiind valoarea TVA de 9%.
Din valoarea totală a TVA aferentă vânzărilor de 13.933.12 lei minus valoarea totală a TVA
aferentă cumpărărilor de 11.856.000 lei obţinem TVA-ul de plată către bugetul de stat de
2.077.120 lei datorită faptului că societatea a înregistrat venituri din vânzarea mărfurilor.
2. Jurnalul pentru cumpărări este un document contabil în care sunt reflectate
achiziţiile de produse, cumpărările efectuate de SC Ades SA. Jurnalul de cumpărări al
societăţii este:
110
Acest raport este obţinut prin execuţia raportului rpt_jc:
3. Jurnalul pentru vânzări este un document contabil care reflectă vânzările de bunuri
către clienţi. Jurnalul de vânzări al SC Ades SA se prezintă astfel:
111
11. Teste
11.1 Testul 1
1. Indicele de calitate a informaţiei ce exprimă „necesitatea de a se dispune de cât mai
multe informaţii (dacă este posibil, de toate informaţiile) referitoare la un sistem economic
analizat” se numeşte:
a. Precizie
b. Oportunitate
c. Completitudine
d. Concizie
e. Actualitate
2. Precizaţi care dintre variante indică alegerea corectă a cheilor candidate şi cea mai
bună alegere a cheii primare, pentru relaţia
Curs (Cod-curs, Denumire-curs, Sala, Ora, Profesor)
Cheia primară este cea subliniată.
a. Cod-curs, Sala
b. Cod-curs, Ora
c. Cod-curs, Profesor
d. Cod-curs, Denumire-curs
e. Cod-curs, Denumire-curs
3. Fie relaţia Personal, ce conţine informaţii despre angajaţii unei fabrici de confecţii:
4. Obiectele Microsoft ACCESS care permit accesul la date prin intermediul browserelor
Internet sunt:
a. Tabelele
b. Formularele
112
c. Cererile de interogare
d. Paginile Web
e. Modulele
a. Proiecţia
b. Intersecţia
c. Joncţiunea
d. Diviziunea
e. Selecţia
CURSURI GRUPE
a. 1-1
b. 1-n
c. n-1
d. m-n
e. 1–3
113
11.2 Testul 2
4. Fie relaţia
114
6. O regulă de validare are următorul rol:
a. Realizează iniţializarea câmpurilor unei tabele
b. Testează, conform unui criteriu furnizat, valorile introduse într-un câmp
c. Stabileşte obligativitatea introducerii unei valori într-un câmp
d. Realizează eliminarea unui index
e. Stabileşte tipul unui câmp
Localitate
Iaşi
Bacău
Constanţa
a. Reuniune.
b. Proiecţie.
c. Selecţie.
d. Diviziune.
e. Intersecţie.
Ţara Jurnalişti
Franţa Marin Gabriel, Iurea Victor
Italia Pricop Adrian, Dan Irina
Spania Manoliu Alexandru
a. FN1
b. FN2
c. FN3
d. FN4
e. Nici una dintre acestea.
115
11.3 Testul 3
1. Operaţiile de: selectare, codificare, conversie de suport, validare sunt specifice,
într-un sistem informatic, fazei de:
a. Culegere şi pregătire a datelor
b. Pelucrare a datelor
c. Memorare a datelor
d. Ahivare a datelor
e. Comunicare / raportare
3. Fie relaţia
CATALOG(nr_matricol, nume, an, nota)
care conţine date despre studenţii secţiei Informatică (numărul matricol, numele, anul de
studiu şi nota la un concurs de baze de date) şi următoarea frază SQL ACCESS:
5. Care dintre următoarele elemente nu reprezintă obiecte ale unei baze de date
ACCESS:
a. Tabele
b. Fişiere de parametri
c. Formulare
d. Rapoarte
e. Cereri de interogare
6. Având în vedere că un furnizor poate avea mai mulţi clienţi şi un client se poate
aproviziona de la mai mulţi furnizori, relaţia între entităţile FURNIZORI şi CLIENŢI este de tip:
a. 1-1
b. 1-n
c. n-1
d. m-n
e. nici unul din tipurile a,b,c,d
116
7. Una sau mai multe colecţii de date aflate în interdependenţă, împreună cu descrierea
datelor şi a relaţiilor dintre acestea reprezintă:
a. un fişier
b. un server
c. o structură arborescentă
d. o bază de date
e. o arhivă electronică
117
11.4 Testul 4
1. Fie asocierea
CLIENT FACTURA
10 Microsistem Bacău
20 InfoData Bacău
30 Flamingo Computers Iaşi
Precizaţi care dintre următoarele tupluri poate fi adăugat în tabela FACTURA, astfel încât
pentru atributul CodClient să fie satisfăcută proprietatea de integritate referenţială:
a. PRODUSE1
CodProducător Ţara Caracteristici
Gr11 Grecia Varietatea1; Recolta2
Sp20 Spania Varietatea1; Recolta2
Ro30 România Varietatea2; Recolta1
b. PRODUSE2
CodProducător Ţara ConţinutZahăr Producător
Gr11 Grecia z1000 Alexis
Sp20 Spania z0800 Jose
Ro30 România z0450 Tudor
Gr12 Grecia z1000 Alexis
Sp22 Spania z0800 Jose
c. PRODUSE3
CodProducător Ţara ConţinutZahăr Producător
Gr11 Grecia z1000 Alexis
Sp20 Spania z0800 Jose
Ro30 România z0450 Tudor
Gr12 Grecia z1000 Alexis
Sp22 Spania z0800 Jose
TIP
ConţinutZahăr Producător
z1000 Alexis
z0800 Jose
z0450 Tudor
118
d. PRODUSE4
Ţara CantitateaImportată
Grecia 1000000; 95000
Spania 50000; 70000; 20000
e. PRODUSE5
CodProducător NrLot Data Cantitate
Gr11 N0001 09-04 10000
Gr11 N0001 12-04 10000
Gr11 N0001 01-05 10000
Gr11 N0002 11-04 20000
Sp20 N0005 02-05 25000
3. Precizaţi care dintre următoarele funcţii (ce pot fi incluse în clauza Group By, pentru
gruparea tuplurilor) furnizează valoarea medie pentru atributul specificat?
a. Count
b. StDev
c. Max
d. Min
e. Avg
4. Care următoarele linii ale grilei Query Design permite inhibarea afişării realizărilor
unui câmp?
a. Table
b. Sort
c. Criteria
d. Show
e. Or
6. Care dintre următoarele aspecte este esenţial pentru elegerea unui atribut drept
cheie primară a unei tabele?
a. Valorile atributului să fie de tip numeric
b. Valorile atributului să fie de tip caracter
c. Valorile atributului să fie unice
d. Tabela să conţină cel puţin două înregistrări
e. Tabela să fie deja indexată după atributul respectiv
7. Care dintre atributele de mai jos este adecvat pentru a deveni cheia primară a entităţii
CLIENŢI?
a. Nume
b. Cod fiscal
c. Telefon
d. Adresa
e. Banca
119
d. Nu sunt admise imbricări ale formularelor
e. Oricâte se doreşte.
9. Dată tabela
PRODUSE
CodProdus DenumireProdus Gestiune
A201 Carton Canson 1
A205 Vopsea acrilică 1
A700 Creion B3 2
X309 Pânză pictură 3
B285 Cărbune desen 2
MAGAZII
Gestiune
1
2
3
120
11.5 Testul 5
1. Fie relaţiile
STUDENŢI
NumeStudent NumărMatricol
Ionescu Mihai 101
Popa Angela 103
Zaharia Florin 107
şi
NOTE1
NumărMatricol NotaProgramare
101 9
103 8
107 10
Relaţia
LISTA
NumeStudent NumărMatricol NotaProgramare
Ionescu Mihai 101 9
Popa Angela 103 8
Zaharia Florin 107 10
2. Dată relaţia CARTE(Autor, Titlu, ISBN, Preţ), precizaţi care dintre următoarele fraze
SELECT va furniza titlurile cărţilor cu preţul între 50000 şi 200000:
a. SELECT DISTINCTROW [Titlu], Preţ FROM CARTE
WHERE Preţ<=200000;
b. SELECT Titlu FROM CARTE
WHERE Preţ>=50000;
c. SELECT DISTINCT Autor FROM CARTE;
d. SELECT Titlu FROM CARTE
WHERE Preţ IN (50000, 100000, 200000);
e. SELECT Titlu FROM CARTE
WHERE Preţ BETWEEN 50000 AND 200000;
121
4. Într-o bază de date, alegerea arhitecturii de stocare a datelor nu trebuie să fie
influenţată de:
a. Cantitatea de date ce urmează a fi memorată
b. Numărul de utilizatori ce vor accesa datele
c. Numărul de tranzacţii pe unitate de timp
d. Limbajul de programare cunoscut de către managerul unităţii beneficiare
e. Resursele financiare disponibile
5. Dacă într-o bază de date s-ar proceda la ştergerea unor date care fac parte din tupluri
în care se găsesc şi alte date care mai sunt încă necesare, această manevră ar reprezenta:
a. O anomalie de modificare
b. O anomalie de adăugare
c. O anomalie de ştergere
d. O violare a integrităţii entităţii
e. O violare a integrităţii referirii
6. Un obiect Access care conţine o definiţie structurată a uneia sau mai multor acţiuni pe
care Access le realizează ca răspuns la un anumit eveniment este:
a. O cerere de interogare
b. Un raport
c. Un formular
d. O comandă macro
e. Un modul
7. O valoare care este atribuită automat unui câmp, atunci când utilizatorul nu introduce
nici o valoare în câmp, se numeşte:
a. Etichetă (Caption)
b. Regulă de validare (Validation Rule)
c. Text de validare (Validation Text)
d. Valoare iniţială (Default Value)
e. Câmp memo
122
11.6 Testul 6
4. Transformaţi relaţia de mai jos (de tip ) în două relaţii de tip 1-n:
REVISTE CITITORI
AI Journal Ionuţ
PC Magazine Ştefan
CD Forum Maria
123
6. Ce este un depozit de date? Indicaţi câteva elemente specifice unui depozit de date.
124
11.7 Testul 7
1. Ce înseamnă modelarea datelor şi de ce este necesară?
125
BIBLIOGRAFIE
2. [Bro98] Browne A., Balter A. – Bazele Access 95, Editura Teora, 1998
3. [Dim99] Dima G., Dima M. – FoxPro 2.5, 2.6 sub DOS, Editura Teora, 1999
6. [Flo99] Florescu V., Stanciu V., Cozgarea G., Cozgarea A. – Baze de date, Editura
Economică, Bucureşti, 1999
7. [Gro96] Grommes, B., Hampe K. – Secretele sistemului FoxPro 2.5 pentru DOS,
Editura Teora, 1996
9. [Lun95] Lungu I., Bodea C., Bădesc G., Ioniţă C. – Baze de date. Organizare,
proiectare şi implementare, Editura All, Bucureşti, 1995
10. [Lun96] Lungu I., Muşat N., Velicaru M. – Sistemul FoxPro 2.6. Prezentare şi aplicaţii,
Editura All, 1996
11. [Nas00] Năstase P., Mihai F., Cosăcescu L., Bărbulescu B., Stanciu A., Şova R.A.,
Covrig L. – Baze de date. Microsoft Access 2000, Editura Teora, Bucureşti,
2000
12. [Opr02] Oprea D., Airinei D., Fotache M. – Sisteme informaţionale pentru afaceri,
Editura Polirom, 2002
13. [Tod02] Todoroi D., Micuşa D., Clocotici V., Linga I., Ţapcov V., Drucioc N., Calcatin A.,
Morari M. – Data Bases and Communication Tools. MS Access 2000, Editura
ASEM, Chişinău, 2002
14. [Tod04] Todoroi D., Micuşa D., Spătaru S., Andronatiev V., Todoroi Z., Donici S. –
Databases and Multimedia Communications (Teaching Aids), Series IEEE-
2000, Chişinău, 2004
127