universitatea de vest din timiȘoara - seap.usv.rosorinv/curs baze de date.pdf · construirea şi...
TRANSCRIPT
5
UNIVERSITATEA DE VEST DIN TIMIŞOARA
FACULTATEA DE ECONOMIE ŞI DE ADMINISTRARE A
AFACERILOR
CENTRUL DE EDUCAŢIE CONTINUĂ ŞI ÎNVĂŢĂMÂNT
DESCHIS LA DISTANŢĂ
Lect.univ.dr. Diana Târnăveanu
Asist.univ.dr. Ileana Hauer
Baze de date. Access 2007
MANUAL PENTRU ÎNVĂŢĂMÂNTUL LA DISTANŢĂ,
ANUL I, CONTABILITATE ŞI INFORMATICĂ DE
GESTIUNE
2011
6
Capitolele 1-3: asist. univ. dr. Ileana Hauer
Capitolele 4-6: lect. univ. dr. Diana Târnăveanu
7
CUPRINS
OBIECTIVELE CURSULUI .............................................................. 11
CAPITOLUL 1
CONCEPTE GENERALE DESPRE BAZELE DE DATE ŞI
SISTEMELE DE GESTIUNE A BAZELOR DE DATE .................... 13
1.1 Revoluţia relaţională ........................................................................................ 13
1.2 Conceptul de bază de date ................................................................................ 15
1.3 Conceptul de sistem de gestiune a bazelor de date ............................................ 19
1.3.1 Introducere............................................................................................... 19 1.3.2 Obiectivele unui SGBD ............................................................................ 19 1.3.3 Funcţiile unui SGBD ................................................................................ 21 1.3.4 Regulile lui Codd ..................................................................................... 23
1.4 Modelarea datelor ............................................................................................ 27
1.4.1 Modele de date: perspectivă istorică ......................................................... 27 1.4.2 Sistemul de gestiune bazat pe fişiere (SGF) .............................................. 28 1.4.3 Modele prerelaţionale ............................................................................... 29 1.4.4 Modelul relaţional .................................................................................... 30 1.4.5 Modelele postrelaţionale şi noi funcţionalităţi ........................................... 32
1.5 Rezumatul capitolului ...................................................................................... 34
1.6 Întrebări de auto-evaluare ................................................................................ 35
CAPITOLUL 2
PROIECTAREA ŞI IMPLEMENTAREA BAZELOR DE DATE ...... 37
2.1 Arhitectura ANSI-SPARC ............................................................................... 37
2.2 Proiectarea bazelor de date............................................................................... 39
2.3 Utilizarea modelelor de date în etapa de proiectare ........................................... 40
2.4 Modelul conceptual al bazei de date ................................................................. 42
2.5 Modelul logic al bazei de date .......................................................................... 42
2.6 Modelul fizic al bazei de date........................................................................... 43
2.7 Rezumatul capitolului ...................................................................................... 45
2.8 Întrebări de autoevaluare.................................................................................. 46
8
CAPITOLUL 3
MODELUL CONCEPTUAL AL BAZELOR DE DATE
RELAŢIONALE .................................................................................. 47
3.1 Entitaţi şi instanţe ............................................................................................ 47
3.2 Atribute .......................................................................................................... 48
3.2.1 Concept şi tipologie ................................................................................. 48 3.2.2 Cheia primară, un atribut special .............................................................. 50 3.2.3 Entitate sau atribut ................................................................................... 51
3.3 Relaţii ............................................................................................................. 53
3.3.1 Definiţie .................................................................................................. 53 3.3.2 Gradul şi cardinalitatea relaţiilor .............................................................. 53
3.4 Schema conceptuală şi diagrama entitate-relaţie ............................................... 54
3.5 Modelul relaţional: fundamentarea teoretică .................................................... 57
3.5.1 Concepte de bază ..................................................................................... 57 3.5.2 Stabilirea relaţiilor între entităţi ................................................................ 59
3.6 Reguli de integritate pentru bazele de date relaţionale ...................................... 63
3.6.1 Valoarea specială Null a atributelor .......................................................... 63 3.6.2 Integritatea entităţilor ............................................................................... 64 3.6.3 Integritatea referenţială ............................................................................ 64 3.6.4 Restricţii procedurale ............................................................................... 65
3.7 Implementarea modelului conceptual............................................................... 66
3.8 Rezumatul capitolului ..................................................................................... 68
3.9 Întrebări de auto-evaluare ................................................................................ 70
CAPITOLUL 4
NORMALIZAREA BAZELOR DE DATE .......................................... 73
4.1. Introducere..................................................................................................... 73
4.2 Organizarea datelor ......................................................................................... 73
4.3 Dependenţe ..................................................................................................... 75
4.3.1 Dependenţe funcţionale simple ................................................................ 75 4.3.2 Dependenţe funcţionale directe şi tranzitive.............................................. 78 4.3.3 Dependenţe funcţionale multiple .............................................................. 78 4.3.4 Dependenţe multivaloare ......................................................................... 78 4.3.5 Dependenţe joncţiune .............................................................................. 80 4.3.6 Matricea dependenţelor funcţionale .......................................................... 81
4.4 Forme normale ................................................................................................ 85
4.4.1 Forma normală 1 ..................................................................................... 85 4.4.2 Forma normală 2 ..................................................................................... 86
9
4.4.3 Forma normală 3 ...................................................................................... 88
4.5 Concluzii ......................................................................................................... 89
4.6 Rezumatul capitolului ...................................................................................... 89
4.7 Întrebări de autoevaluare din partea teoretică .................................................... 90
4.8 Exemple .......................................................................................................... 91
4.8.1 Problemă rezolvată – Filiala CEC ............................................................. 91 4.8.2 Probleme propuse..................................................................................... 94
CAPITOLUL 5
ELEMENTE INTRODUCTIVE ÎN ACCESS .................................... 97
5.1 Introducere ...................................................................................................... 97
5.2 SGBD Access: prezentare generală .................................................................. 97
5.2.1 Caracteristici generale .............................................................................. 98 5.2.2 Operaţii cu baze de date ........................................................................... 99 5.2.3 Obiectele bazei de date ........................................................................... 105
5.3 Obiecte Tables ............................................................................................... 106
5.4 Obiecte Queries ............................................................................................. 116
5.4.1. Interogări de selecţie ............................................................................. 117 5.4.2 Interogări de sintetizare a datelor ............................................................ 119 5.4.3 Interogări de acţiune ............................................................................... 120
5.5 Obiecte Forms ............................................................................................... 123
5.5.1 Formulare create cu ajutorul butonului Form .......................................... 124 5.5.2 Formulare create cu ajutorul butonului Form Wizard .............................. 125 5.5.3 Formulare create cu ajutorul butonului Form Design ............................... 128 5.5.4 Formulare cu sub-formulare ................................................................... 133
5.6 Obiecte Reports ............................................................................................. 134
5.7 Obiecte Macros ............................................................................................. 139
5.8 Obiecte Modules ........................................................................................... 141
5.9 Concluzii ....................................................................................................... 141
5.10 Rezumatul capitolului .................................................................................. 141
5.11 Întrebări de autoevaluare din partea teoretică ................................................ 142
5.12 Exemple ...................................................................................................... 143
5.12.1 Problemă rezolvată – Tabelă creată în Datasheet View .......................... 143 5.12.2 Problemă rezolvată – Tabele create în Design View .............................. 148 5.12.3 Problemă rezolvată – Formulare şi controale ......................................... 154 5.12.4 Problemă rezolvată – Formulare cu controale calculate, Switchboard .... 161 5.12.5 Problemă rezolvată – Interogări ............................................................ 168 5.12.6 Problemă rezolvată – Rapoarte ............................................................. 175
10
5.13 Probleme propuse ........................................................................................ 181
5.13.1 Problema propusă – Crearea tabelelor – Filială CEC ............................. 181 5.13.2 Problemă propusă – Crearea formularelor............................................. 181 5.13.3 Problemă propusă – Crearea interogărilor ............................................. 181 5.13.4 Problemă propusă – Crearea rapoartelor ............................................... 181
CAPITOLUL 6
ELEMENTE SQL ............................................................................. 183
6.1 Introducere.................................................................................................... 183
6.2 Comenzi SQL ............................................................................................... 183
6.2.1 Comanda CREATE TABLE .................................................................. 186 6.2.2 Comanda ALTER TABLE ..................................................................... 188 6.2.3 Comanda DROP TABLE ....................................................................... 190 6.2.4 Comanda INSERT INTO ....................................................................... 190 6.2.5 Comanda DELETE ................................................................................ 191 6.2.6 Comanda SELECT ................................................................................ 192 6.2.7 Comanda UPDATE ............................................................................... 200
6.3 Concluzii ...................................................................................................... 201
6.4 Rezumatul capitolului ................................................................................... 201
6.5 Întrebări de autoevaluare din partea teoretică ................................................. 202
6.6 Exemple ....................................................................................................... 203
6.6.1. Problemă rezolvată – Produse ............................................................... 203 6.6.2 Problemă rezolvată – Aprovizionare....................................................... 208 6.6.3 Problemă propusă – Bibliotecă ............................................................... 216 6.6.4 Problemă propusă – Amenajări interioare ............................................... 216
BIBLIOGRAFIE ............................................................................... 219
GLOSAR DE TERMENI .................................................................. 221
11
OBIECTIVELE CURSULUI
Calculatorul va fi utilizat ca instrument de lucru pentru prelucrarea automată a volumelor mari de date organizate sub formă de baze de date,
extrem de importante ca suport de date pentru sistemele informatice integrate de
management al activităţii organizaţiilor.
Obiectivele cursului sunt însuşirea conceptelor de bază legate de :
organizarea volumelor mari de date sub formă de baze de date şi
prelucrarea acestora;
formarea deprinderilor de a utiliza facilităţile specifice programului
Microsoft Access;
construirea şi gestionarea unor baze de date proprii (prelucrări de
complexitate medie).
În cadrul cursului sunt expuse principiile de bază ale proiectării bazelor de date după modelul relaţional al şi se prezintă principalele obiecte ale bazelor de
date Access, precum şi modul de proiectare şi utilizare a acestora.
În cadrul seminarului se exersează crearea bazelor de date Access, a tabelelor, interogărilor, formularelor, rapoartelor şi a comenzilor SQL.
12
13
CAPITOLUL 1
CONCEPTE GENERALE DESPRE BAZELE DE DATE
ŞI SISTEMELE DE GESTIUNE A BAZELOR DE DATE
1.1 Revoluţia relaţională
Astăzi beneficiem de avantajele aduse de bazele de date relaţionale:
capacitatea de stocare, accesare, şi modificare rapidă a datelor pe calculatoarele
low-cost. Totuşi, până la sfârşitul anilor 1970, bazele de date au stocat cantităţi
mari de date într-o structură ierarhică, care a fost dificil de navigat şi inflexibilă. Programatorii aveau nevoie să ştie ce doreau clienţii să facă cu datele înainte
de a proiecta baza de date . Adăugarea sau schimbarea modului de analiză a
datelor a fost un proces îndelungat şi costisitor.
În 1970, Edgar "Ted" Codd, un matematician angajat de IBM, a scris un articol care va schimba toate astea. La acea vreme, nimeni nu şi-a dat seama
că teoriile lui Codd vor declanşa o revoluţie tehnologică la egalitate
cu dezvoltarea calculatoarelor personale şi Internet (Coronel, et al., 2009) Don Chamberlin, coinventor al SQL, cel mai popular limbaj utilizat de
sistemele de baze de date de astăzi, şi-a amintit cum teoriile matematice ale lui
Codd nu au fost luate în seamă. Apoi Ted Codd a organizat un simpozion, iar Chamberlin a ascultat cum Codd a redus cinci pagini complicate de
program la o linie. Simpozionul a convins IBM pentru a finanţa Sistem R, un
proiect de cercetare care a construit o prototip al unei baze de date relaţionale
şi care va duce în cele din urmă la crearea limbajelor SQL şi DB2. Adevăratele sisteme relaţionale s-au afirmat pe piaţă începând cu anul
1984: sistemul DB2 (IBM Corp.) funcţionează pe mainframe-urile IBM şi, prin
urmare, e portabil pe RS/6000; Oracle (Oracle Systems) a devenit un sistem de
gestiune relaţional portabil pe mai multe platforme; sistemul RDBMS (AWB)
funcţionează pe calculatoarele AT&T 3B; sistemele de gestiune Informix
(Informix Software) şi Sybase (Sybase Inc.) funcţionează în mediul Unix. Mai
multe sisteme de gestiune ale bazelor de date relaţionale (FoxPro, Paradox etc.)
au fost elaborate pentru calculatoarele personale.
Dezvoltarea teoriei bazelor de date relaţionale a căpătat o amploare
nemaivăzută în domeniul aplicării tehnicii de calcul. Au apărut o serie de reviste specializate în domeniul respectiv. Între elaborările teoretice şi
producerea sistemelor comerciale s-a creat un spaţiu de cel puţin 20 ani. Acesta e un rar exemplu când necesităţile software considerabil depăşesc
capacităţile hardware. Rezultatele obţinute în teoria relaţională au influenţat
esenţial sistemele de gestiune ce se bazează pe celelalte două modele de date:
14
ierarhic şi reţea. Modelul relaţional de date e aplicat pe larg şi în bazele de date deductive. Pe de altă parte, se observă convergenţa modelului relaţional şi
tehnologiilor orientate pe obiecte.
"Revoluţia relaţională" a introdus mai multe idei valoroase în lumea bazelor de date. Printre acestea progrese tehnologice şi beneficii ale sistemelor
de gestiune ale bazelor de date pot fi menţionate:
• Tabelele sunt un mijloc simplu de reprezentare a datelor. Ele permit
programatorilor şi utilizatorilor finali să-şi organizeze datele în mod acceptabil. Extinderea modelului relaţional a confirmat puterea de atracţie
a acestei reprezentări.
• SQL este un standard de limbaje de interpelări foarte comod. El e un limbaj nonprocedural de manipulare a datelor şi a contribuit mult la creşterea
popularităţii sistemelor de gestiune ale bazelor de date relaţionale.
• Operaţiile orientate pe mulţimi permit programatorilor şi utilizatorilor
ordinari să găsească şi să actualizeze mari colecţii de înregistrări fără a scrie programe speciale.
• Joncţiunile sunt instrumente puternice de asociere a înregistrărilor anterior independente. Utilizatorii pot crea noi seturi de înregistrări (aşa-numitele
tabele virtuale), apelând la joncţiune.
• Interpelările interactive. Căutarea şi prelucrarea datelor în mod dinamic a adus la utilizarea largă a bazelor de date relaţionale. Gestionarea tabelelor, vizualizarea interactivă şi îmbunătăţirea interactivă a contribuit
ca utilizatorul să-şi dea votul pentru sistemele relaţionale.
• Consistenţa datelor. Sistemele de gestiune relaţionale asigură că nici un
utilizator şi nici o aplicaţie nu pot modifica baza de date, dacă modificarea e în contradicţie cu constrângerile de integritate.
15
1.2 Conceptul de bază de date
Apariţia şi dezvoltarea calculatoarelor electronice au condus la
amplificarea activităţilor legate de stocarea, interogarea şi administrarea
colecţiilor de date. O colecţie de date reuneşte date despre o anume clasă de
obiecte (reale sau conceptuale). Folosirea tehnologiilor informaţionale în colectarea, stocarea, procesarea şi
transmiterea colecţiilor de date a impus definirea unor tehnici şi metode de
organizare a acestora. Se cunosc două metode de organizare a colecţiilor de date:
- organizarea în fişiere de date;
- organizarea în baze de date. Organizarea datelor în fişiere de date este specifică anilor 60‟ şi poate fi
utilizată şi astăzi, îndeosebi în cazul folosirii limbajelor procedurale de
programare1, cum ar fi limbajele Cobol, Fortran, Basic.
Ca limite ale organizării datelor în fişiere menţionăm: - descrierea datelor se face în fiecare program în care ele sunt utilizate;
spunem că datele sunt dependente de program.
- lipsa unui formalism riguros de definire şi validare a datelor. - menţinerea unei redundanţe ridicate în cadrul colecţiilor de date
memorate pe suporturi tehnice.
- performanţe scazute pentru procesarea datelor îndeosebi cand este
necesar să se facă asocieri între datele memorate în fişiere de date distincte.
Limitele organizării datelor în fişiere şi posibilităţile oferite de noile
tehnologii informaţionale au dus la promovarea metodei de organizare a datelor în baze de date.
Astăzi, cele mai multe dintre activităţile noastre zilnice necesită accesarea
şi actualizarea informaţiei dintr-o bază de date: extragerea unei sume de bani din cortul bancar, rezervarea unei camere de hotel, cumpărarea unui bilet de
avion, împrumutul unei cărţi de la bibliotecă, plata facturilor de telefon, curent
electric etc. Toate acestea se pot face rapid şi în siguranţă, pentru că datele
respective sunt bine organizate într-o bază de date şi administrate de un sistem de gestiune a bazelor de date.
Pentru baza de date2 avem mai multe definiţii:
este un ansamblu integrat de înregistrări sau de fişiere legate între ele în mod logic (Lungu, et al., 1995).
1 Versiuni recente ale acestor limbaje permit și accesarea datelor organizate în baze de date. 2 Termenul database (bază de date în limba engleză) a apărut pentru prima dată în titlul unei
conferințe organizate în Santa Monica, SUA, în 1964: Development and Management of
Computer Centered Database.
16
ansamblu structurat de date înregistrate pe suporturi accesibile de calculator pentru a satisface, chiar simultan, mai mulţi utilizatori de o
manieră selectivă şi în timp oportun (Delobel, Adiba, 1982).
colecţie de date aflate în interdependenţă, împreună cu descrierea datelor şi a relaţiilor dintre ele (Pescaru, et al, 1976).
colecţie de date utilizată într-o organizaţie, colecţie care este
automatizată, partajată, definită riguros (formalizată) şi controlată la
nivel central (Everest, 1986). Faţă de modelul bazat pe fişier, noutatea adusă de organizarea datelor în baze de
date o constituie existenţa unui fişier de descriere globală al bazei, astfel încât
să se poată asigura independenţa programelor faţă de date. Acest fişier de descriere globală al bazei este denumit dicţionar de date sau catalog al
sistemului. După cum se observă din figura 1.1, lucrul cu fişierele de date, deci
extragerea şi modificarea datelor, se desfăşoară exclusiv prin intermediul
dicţionarului de date în care se găsesc informaţii privitoare la structura datelor şi restricţiile îndeplinite de acestea.
Termenul de bază de date este folosit de multe ori în mod eronat,
confundându-se cu softul pentru bază de date care este utilizat. În realitate, softul pentru baze de date este numit sistem de gestiune a bazelor de date
(SGBD), iar baza de date este recipientul care conţine informaţiile, recipient
creat şi manipulat prin intermediul SGBD. Conţinutul acestui recipient se schimbă foarte des, atunci când se lucrează cu baza de date (adăugări, ştergeri şi
modificări de informaţii)
17
Figura 1.1 Schema de principiu a unei baze de date
Adaptare după Fotache, M., 1997
A proiecta o bază de date înseamnă a-i stabili structura, adică elementele
componente, caracteristicile acestora, restricţiile pe care trebuie să le respecte,
relaţiile dintre ele.
A construi o bază de date înseamnă a memora (a introduce) datele în baza de
date, după proiectarea acesteia.
A administra o bază de date înseamnă a asigura: (1) accesul la date al uti-
lizatorilor, în funcţie de drepturile fiecăruia (funcţia şi importanţa fiecăruia în
organizaţia respectivă), (2) coerenţa bazei de date (recuperarea informaţiei
atunci când au loc incidente: întreruperea alimentării cu curent electric, operaţii
contradictorii etc), (3) securitatea datelor stocate etc.
A interoga o bază de date înseamnă a extrage şi a vizualiza datele care
îndeplinesc anumite criterii şi condiţii.
A actualiza o bază de date înseamnă a modifica structura sau informaţiile
stocate în baza de date.
De exemplu, lista cărţilor dintr-o bibliotecă nu este o bază de date, ci un simplu
inventar de obiecte, o listă, un tabel. Dacă la această listă adăugăm lista
cititorilor abonaţi la bibliotecă (eventual şi lista angajaţilor bibliotecii) şi luăm
în considerare activităţile specifice bibliotecii (achiziţionarea de cărţi noi,
împrumutul şi restituirea cărţilor de către cititori, eventual administrarea
sarcinilor de serviciu ale angajaţilor), atunci avem de a face cu o bază de date.
Nu orice colecţie de date este o bază de date.
18
În concluzie, faţă de un inventar (un tabel), o bază de date are
următoarele proprietăţi:
♦ reprezintă un anumit aspect al lumii reale, numit microuniversul bazei
de date; orice modificare care se produce în acest microunivers se
reflectă în baza de date (de exemplu: cumpărarea unui nou DVD în
vederea închirierii, modificarea diferenţei permise între cursul de
cumpărare şi cel de vânzare al valutei etc);
♦ este o colecţie de date coerentă din punct de vedere logic şi având un
înţeles intrinsec (de exemplu: din baza de date asociată bibliotecii
universităţii nu vor face parte cărţile de telefon sau lista de materiale
didactice din laboratorul de informatică);
♦ este proiectată, construită şi administrată, având permanent în vedere un
anumit scop; o bază de date este destinată utilizării de către un anumit
grup de persoane şi permite efectuarea unui anumit set de operaţii.
19
1.3 Conceptul de sistem de gestiune a bazelor de date
1.3.1 Introducere
O bază de date apare ca o colecţie de date stocată pe memorii externe
adresabile, folosite de o multitudine de utilizatori, dar dacă baza de date care nu are asociat un sistem de gestiune al acesteia, ea nu îşi atinge obiectivele pentru
care a fost creată.
Prin urmare un SGBD3 (în engleză Database Management System abreviat
DBMS) este un pachet software de nivel înalt, care permite proiectarea, construirea şi administrarea bazelor de date dedicate rezolvării problemelor din
cele mai variate domenii ale vieţii reale.
Sistemul de gestiune al bazei de date reprezintă software-ul propriu-zis al acesteia care asigură realizarea următoarelor activităţi (Lungu, et al., 1995):
- definirea structurii bazei de date;
- încărcarea datelor în baza de date;
- accesul la date (interogare, actualizare);
- întreţinerea bazei de date (colectarea şi refolosirea spaţiilor goale, refacerea bazei de date în cazul unui incident);
- reorganizarea bazei de date (restructurarea şi modificarea strategiei de acces);
- securitatea datelor. Aşadar, sistemul de gestiune al bazei de date apare ca un sistem complex
de programe care asigură interfaţa între o bază de date şi utilizatorii acestuia.
1.3.2 Obiectivele unui SGBD
După cum este cunoscut, obiectivul informaticii îl constituie culegerea, verificarea, transmitarea, stocarea şi prelucrarea automată a datelor cu ajutorul
mijloacelor electronice de calcul, în scopul satisfacerii diferitelor nivele de
conducere cu informaţii necesare luării deciziilor, în condiţii de eficienţă economică sporită.
În aceste condiţii, necesitatea acută de informare trebuie satisfăcută ţinând
seama de o serie de cerinţe prin care să se asigure: minimizarea costului procesului de prelucrare a datelor; creşterea vitezei de răspuns la întrebările
solicitate de utilizatori; adaptarea facilă a sistemului informatic la evoluţia în
timp a sistemului informaţional din care face parte; posibilitatea răspunsului la
anumite întrebări neanticipate de către proiectanţii de sistem; posibilitatea
3 Exemple de SGBD: Microsoft Access, FoxPro (de la Microsoft), Paradox, Visual dBase (de la
Borland), Oracle 10g (de la Oracle Corporation), Sybase Adapted Server (de la Sybase Inc.), Iris (de la Hewlett-Packard), IMS, DB2 (până DB9 de la IBM).
20
folosirii sistemului de informare dispunând de un minim de cunoştinţe despre modul de organizare a lui în general şi informatică în special; integritatea şi
securitatea datelor etc.
În acest context, sistemului de gestiune al bazei de date îi revin o serie de de obiective, cum sunt:
1) Asigurarea independenţei datelor. O aplicaţie, în general, este
dependentă de date în sensul că modificarea structurii de memorare a datelor
sau a strategiei de acces la date afectează şi aplicaţia. Independenţa datelor faţă de aplicaţie este totuşi necesară cel puţin din următoarele considerente: diferite
aplicaţii au nevoie de viziuni diferite ale aceloraşi date; administratorul bazei de
date trebuie să aibă libertatea de a schimba structura de memorare sau strategia de acces, ca răspuns la cerinţe (schimbări de standarde, priorităţile aplicaţiilor,
unităţile de memorare etc), fără a modifica aplicaţiile existente; baza de date
existentă, precum şi programele de exploatare a ei, care au fost folosite o
perioadă de timp, reprezintă o investiţie majoră la care nu trebuie să se renunţe prea uşor.
Independenţa datelor trebuie privită din două puncte de vedere:
independenţa fizică; independenţa logică a datelor. Independenţa fizică a datelor face ca memorarea datelor şi tehnicile fizice
de memorarea să poată fi modificate fără a determina rescrierea programelor de
aplicaţie.
Independeţa logică a datelor se referă la posibilitatea adăugării de noi articole de date sau extinderea structurii conceptuale (globale), fără ca aceasta
să impună rescrierea programelor existente.
2) Asigurarea unei redundanţe minime şi controlate a datelor din baza de date. Spre deosebire de sistemele clasice de prelucrare automată a datelor,
stocarea datelor în cazul bazelor de date se face astfel încât flecare dată să apară
o singură dată. Totuşi, nu sunt excluse nici cazurile în care, pentru a realiza performanţe sporite, referitoare la timpul de acces la date şi răspuns la
solicitările utilizatorilor, să se accepte o anumită redundanţă a datelor, însă în
acest caz se va institui un control automat asupra ei în vederea asigurării
coerenţei datelor din bază.
3) Asigurarea unor facilităţi sporite de utilizare a datelor. Aceasta
presupune:
- folosirea datelor de către mai mulţi utilizatori în diferite scopuri (aplicaţii);
- accesul cât mai simplu al utilizatorilor la date, fără ca aceştia să fie nevoiţi
să cunoască structura întregii baze de date, acest lucru rămânând în sarcina administratorului bazei de date;
- existenţa unor limbaje performante de regăsire a datelor, care permit exprimarea sub forma unei conversaţii, a unor criterii de selecţie a datelor şi
indicarea unor reguli cât mai generale pentru editarea informaţiilor solicitate;
21
- spre deosebire de sistemul clasic de prelucrare pe fişiere, unde exista un
singur criteriu de adresare (cel care a stat la baza organizării fişierului) în cazul bazelor de date, sistemul de gestiune trebuie să ofere posibilitatea unui acces
multicriterial, fără sortări suplimentare, în timp ce modificarea criteriului la
fişierele clasice implică reorganizarea lor;
- utilizarea unui limbaj cât mai apropiat de limbajul natural, cu posibilitatea exploatării bazei de date în regim conversaţional. Aceasta ar oferi posibilitatea exploatării în mod facil a bazei de date şi de către utilizatorii neinformaticieni.
4) Sporirea gradului de securitate a datelor împotriva accesului neautorizat la ele. În condiţiile bazelor de date, administratorul bazei de date
poate prevedea ca accesul la baza de date să se facă numai prin canale
corespunzătoare, şi poate, totodată, defini, verificări de autorizare realizate oricând se încearcă accesul la anumite date.
5) Asigurarea integrităţii datelor împotriva unor ştergeri intenţionate sau neintenţionate, prin intermediul unor proceduri de validare, a unor protocoale de control concurent şi a unor proceduri de refacere a bazei de date după incidente.
6) Asigurarea partajabilităţii datelor. Partaj abilitatea datelor trebuie înţeleasă nu numai sub aspectul asigurării accesului mai multor utilizatori la aceleaşi date, ci şi acela al posibilităţii dezvoltării unor aplicaţii fără a se modifica structura bazei de date.
1.3.3 Funcţiile unui SGBD
Pentru realizarea obiectivelor enumerate anterior, sistemele de gestiune a
bazelor de date dispun de o serie de componente ce permit efectuarea
numeroaselor operaţii. În funcţie de natura lor şi scopul urmărit, operaţiile pot fi
grupate pe activităţi. Activităţile acceptă şi ele o grupare pe funcţii (una sau mai multe activităţi, relativ omogene, vor realiza o anumită funcţie).
Ţinând seama de multitudinea sarcinilor ce revin unui sistem de gestiune
a bazelor de date şi grupând aceste sarcini pe activităţi şi apoi pe funcţii, se deduc, în final, funcţiile sistemului de gestiune. Ţinând seama de complexitatea
sistemului de gestiune, de facilităţile propuse a fi oferite de acesta, de limbajele
utilizate4 şi tipul bazei de date ce urmează a fi gestionată de SGBD, gruparea
activităţilor pe funcţii are un oarecare caracter relativ. În situaţia sistemelor de
4 Un SGBD pune la dispoziție utilizatorilor limbaje distincte pentru 1) descrierea bazei de date
(limbaj de descriere a datelor- LDD) și 2) manipularea bazelor de date (limbaj de manipulare a datelor-LMD). Limbajele de manipulare (interogare) a bazelor de date pot fi: declarative (permit
utilizatorului să declare de ce informații are nevoie) și procedurale (obligă utilizatorul să descrie procedura de obținere a informațiilor).
22
gestiune ce utilizează limbaje gazdă de nivel înalt, identificarea şi delimitarea funcţiilor nu este atât de evidentă. În ciuda acestor particularităţi, totuşi, se pot
deduce câteva funcţii cu caracter de generalitate pentru toate sistemele de
gestiune a bazelor de date. Prezentăm în continuare câteva astfel de funcţii:
1) Funcţia de descriere a datelor permite definirea structurii bazei de date cu ajutorul limbajului de definire. Definirea datelor poate fi realizată la nivel
logic, conceptual şi fizic. La nivelul acestei funcţii se descriu multitudinea
atributelor (câmpurilor) din cadrul structurii bazei de date, legăturile dintre entităţile bazei de date sau dintre atributele aceleiaşi entităţi, se definesc
eventualele criterii de validare a datelor, metodele de acces la date, aspectele
referitoare la asigurarea integrităţii şi confidenţialităţii datelor, etc. Rezultatul
acestei funcţii se va concretiza în schema bazei de date, memorate în cod intern.
2) Funcţia de manipulare a datelor este cea mai complexă funcţie şi realizează următoarele activităţi:
- crearea (încărcarea) bazei de date;
- adăugarea de noi înregistrări (tupluri);
- suprimarea unor înregistrări;
- modificarea valorilor corespunzătoare unor câmpuri; - căutarea, sortarea şi editarea parţială sau totală a unei înregistrări
virtuale etc.
Funcţia de manipulare a datelor se realizează prin intermediul limbajului de manipulare a datelor.
3) Funcţia de utilizare asigură mulţimea interfeţelor necesare pentru comunicarea tuturor utlizatorilor cu baza de date. În cadrul realizării acestei
funcţii, apar mai multe categorii de utilizatori:
- utilizatori „liberi” sau conversaţionali. Aceaştia reprezintă categoria beneficiarilor de informaţii (utilizatori finali) care utilizează limbajele de interogare a bazei de date într-o formă simplistă. Ei apar ca utilizatori
neinformaticieni;
- utilizatori programatori, care utilizează limbajele de manipulare, realizând proceduri complexe de exploatare a bazei de date;
- administratorul bazei de date apare ca un utilizator special şi are rolul hotărâtor în ceea ce priveşte funcţionarea optimă a întregului ansamblu.
4) Funcţia de administrare a bazei de date apare ca o funcţie complexă şi
este de competenţa administratorului bazei de date.
23
1.3.4 Regulile lui Codd
Un sistem de gestiune a bazelor de date relaţionale (Relational Database Management System - RDBMS) este o un sistem de gestiune a bazelor de date
care foloseşte modelul relaţional.
În anul 1985, E.F. Codd a publicat un set de 13 reguli de fidelitate pe
baza cărora se apreciază dacă un sistem de gestiune de baze de date poate fi considerat relaţional.
Tabelul 1.1 prezintă pe scurt aceste reguli.
Nr. Nume
regulă
Descriere Implementare
Access 0 Principiu de
bază
Orice SGBD Relaţional (SGBDR)
trebuie să gestioneze întreaga bază de
date numai prin posibilităţile modelului
relaţional. Dacă un SGBD este
dependent de un instrument de manipulare al datelor la nivel de
întregistrare, nu este total relaţional.
Access a fost primul
SGBD care rula sub
Windows şi respecta
această regulă. Access
nu foloseşte numere de înregistrări.
1 Stocarea
informaţiei
Toate datele unui SGBD relaţional se
reprezintă explicit ca valori în tabele.
Datele nu pot fi stocate prin alte
metode.
Access îşi stochează
datele în tabelele
motorului bazei de
date Microsoft Jet.
2 Garantarea
accesului
Fiecare element de dată trebuie să fie
accesibil logic printr-o combinaţie de
forma: cheie primară, nume de tabel şi
nume de câmp.
Access respectă
această regulă prin
folosirea Cheii Primare
(Primary Key)
3 Lipsa
informaţiei
Valorile vide (Null) trebuie să fie
suportate explicit. Null-urile reprezintă
informaţia lipsă sau imposibil de
aplicat.
Access suportă lucrul
cu valori Null pentru
descrierea
informaţiilor lipsă.
4 Catalogul de sistem
Descrierea bazei de date sau catalogul trebuie să se facă la nivelul logic sub
forma unor valori în tabele. Limbajul
relaţional (SQL) trebuie să poată
acţiona asupra proiectului bazei de date
în acelaşi mod în care acşionează
asupra datelor stocate în structură.
Catalogul rezidă în motorul bazei de date
Microsoft Jet. Se poate
folosi OpenSchema
din ADO pentru
interogarea catalogului
de sistem. Limbajul
DDL SQL al
motorului bazei de
date Microsoft Jet
oferă posibilitatea
creării tabelelor,
cheilor etc.
24
5 Limbaj
cuprinzăto
Un SGBD trebuie să suporte un limbaj
clar pentru manipularea datelor (SQL)
care asigură modalităţi cuprinzătoare
pentru manipularea datelor, definirea
datelor, definirea vederilor,
constrângerile de integritate, limitările
de tranzacţii şi de autorizare.
Access, prin motorul
Jet, asigură SQL
pentru manipularea
datelor, crearea
vederilor (Select
Queries),
constrângerile de
intergritate
(Relationships şi Create Constraint.
6 Actualizarea
vederilor
Toate vederile trebuie să poată fi
actualizate de sistem. Într-un SGBD
total relaţional majoritatea vederilor ar
trebui să se poată actualiza.
Access a fost primul
SGBD pe PC-uri care
a permis interogări de
actualizare (Update
Query)
7 Actualizări
la nivel de
mulţime
Un SGBDR trebuie să facă mai mult
decât simpla extragere a datelor.
Trebuie să aibă capacitatea de inserare,
actualizare şi ştergere a datelor, privite
ca o mulţime relaţională.
Access suportă
interogări de acţiune
(Action Query)
8 Independenţa
fizică a
datelor
Datele trebuie să fie fizic independente
de programul aplicaţie. SGBDR trebuie
să fie în stare să urmărească modificările fizice la nivelul datelor pe
"sub aplicaţie". De exemplu, SGBDR
nu se va modifica dacă un index se
adaugă sau se şterge dintr-un tabel.
Access permite
modificarea obiectelor
bazei de date fără alterarea celorlalte
componete ale
Accessului. Jet are
motor de stocare logic.
9 Independenţa
logică a
datelor
Pe cât este posibil, aplicaţiile software
trebuie să fie independente de
modificările făcute în tabelele de bază.
De exemplu, nu trebuie să se rescrie
codul în cazul în care tabelele sunt
combinate într-o vedere.
În Access, o interogare
se poate lega la un
formular sau la un
raport la fel de simplu
ca un tabel.
10 Independenţa integrităţii
datelor
Integritatea datelor trebuie să se poată defini într-un limbaj relaţional şi să fie
stocată în catalog. Constrângeri de
integritate a datelor trebuie să poată fi
construite la nivel de aplicaţie. Acest
concept este oarecum străin modelului
relaţional. În modelul relaţional,
integritatea trebuie să fie inerentă
proiectului bazei de date.
Deşi Microsoft nu a documentat modul în
care Jet stochează
integrităţile, se pot
crea reguli de
integritate via SQL. Jet
va stoca aceste
informaţii în proiectul
bazei de date ca parte a
catalogului.
25
11 Independenţa
distribuţiei
Capacităţile SGBDR nu au voie să fie
limitate datorită distribuţiei unor
componente ale acestuia în baze de
date separate.
Pentru că motorul Jet
stochează regulile de
integritate la nivel de
motor, alte
componente ale
motorului nu afectează
regulile de integritate.
12 Inexistenţa
subminărilor
Dacă un SGBDR are un limbaj de
manipulare "a unei singure înregistrări
la un moment dat", acest limbaj nu va putea fi folosit la ocolirea regulilor de
integritate sau a constrângerilor
modelului relaţional. Astfel nu numai
că SGBDR trebuie să fie guvernat de
reguli relaţionale, ci aceste reguli
trebuie să fie şi primare.
Access permite
folosirea lui DAO şi
ADO pentru manipularea a câte
unei singure
înregistrări la un
moment dat prin
intermediul mulţimilor
de înregistrări
actualizabile
(updateable recordsets)
Nici unul dintre SGBD disponibile astăzi nu respectă complet cerinţele
exprimate de Codd, în cadrul celor 13 reguli. De aceea pentru caracterizarea
unui SGBD nu sunt utilizate regulile lui Codd, fiind formulate în schimb o serie de cerinţe minimale pe care trebuie să le îndeplinească programul pentru a fi
considerat relaţional (Lungu, et al., 1995).
Un SGBD este minimal relaţional dacă datele din cadrul bazei de date sunt reprezentate prin valori în tabele, nu există pointeri observabili de către
utilizatori, iar sistemul suportă operatorii relaţionali de proiecţie, selecţie şi
compunere naturală, fără limitări impuse din considerente interne.
Un SGBD este complet relaţional dacă este minimal relaţional şi, în plus, sistemul suportă restricţiile de integritate de bază (unicitatea cheii primare,
constrângerile de referinţă, integritatea entităţii) şi precum şi toate operaţiile de
bază ale algebrei relaţionale.
Un obiectiv important a proiectării unei baze de date de tip relaţional îl
reprezintă gruparea atributelor în relaţii astfel încât redundanţa datelor să fie
minimă. Relaţiile care conţin date redundante pot crea probleme, denumite anomalii de reactualizare, care clasificate în:
o anomalii de ştergere constau în faptul că anumite date care urmează să
fie şterse, fac parte din tupluri în care se găsesc şi alte date care mai sunt necesare în continuare, ori ştergerea făcându-se la nivelul tuplului,
acestea se pierd;
o anomalii de inserare (adăugare) constau în faptul că anumite date care urmează să fie adăugate fac parte din tupluri incomplete (pentru care nu
se cunosc toate datele), ceea ce face ca acestea să nu poată fi adăugate;
26
o anomalii de modificare rezultă din faptul că este dificil de modificat o valoare a unui atribut atunci când ea apare în mai multe tupluri ale
relaţiei.
Eliminarea acestor anomalii se realizează cu ajutorul operaţiei numite normalizare
5, care este o tehnică formală care se bazează pe cheile primare,
respectiv cheile candidat ale relaţiilor şi pe dependenţele funcţionale. Tehnica
include o mulţime de reguli care pot fi utilizate pentru testarea relaţiilor
individuale.
5 Subiect dezvoltat în capitolul 4.
27
1.4 Modelarea datelor
Pentru cunoaşterea realităţii înconjurătoare şi prelucarea datelor cu ajutorul
calculatoarelor este necesară modelarea acestei realităţi.
O bază de date oferă un anumit grad de abstractizare a datelor
(asemenea celor mai multe limbaje de programare), ascunzând detaliile de
implementare, detalii care nu sunt necesare celor mai mulţi dintre utilizatori. Cu
alte cuvinte, programele specifice unei baze de date nu depind de modul de stocare şi accesare a datelor la nivel fizic. Acest concept se numeşte
independenţă a datelor, se realizează cu ajutorul unui model de date (Data
Model6) şi este principalul mecanism care asigură partajarea datelor din baza de
date între diferitele aplicaţii care le accesează.
1.4.1 Modele de date: perspectivă istorică
Evoluţia modelelor de date pentru bazele de date şi SGBD-uri a fost
sugestiv sintetizată de R.G.G. Canttell în articolul său „What Are Next-
Generation DB Systems?", publicat în revista Communications of the ACM, în
octombrie 1991: “Istoria informaticii a cunoscut multe generaţii de sisteme de
gestiune a datelor, începând cu sistemele de fişiere indexate, continuând apoi cu
sistemele de tip ierarhic şi de tip reţea, iar - mai nou - cu sistemele relaţionale.
Acum suntem pe punctul de a intra într-o nouă generaţie de sisteme de gestiune
a bazelor de date care oferă administrare de obiecte şi care acceptă tipuri de
date mult mai complexe".
Cu toate că a generat o activitate de cercetare foarte susţinută dar şi o
activitate practică, industrială extrem de productivă, domeniul bazelor de date
este unul dintre cele mai tinere domenii ale informaticii. Este general acceptat
faptul că „rădăcinile" sale trebuie căutate aproximativ acum 40 de ani (data
apariţiei primului sistem comercial de gestiune a bazelor de date), în obiectivul
fixat de preşedintele J.F. Kennedy pentru programul Apollo: aducerea primului
om pe Lună până la sfârşitul anilor 60‟. În acel moment, nu exista nici un
instrument informatic care să funcţioneze efectiv şi care să poată administra
uriaşele volume de date implicate în programul spaţial. Ca urmare, North
American Aviation (NAA), primul contractor al proiectului, a dezvoltat un
software bazat pe o structură ierarhică (părţile se agregă în componente din ce
în ce mai ample) denumit GUAM (Generalized Update Access Method). Spre
6 E.F.Codd este considerat a fi “părintele “ conceptului de model de date, în general, și al
conceptului de model de date relațional, în particular.
28
mijlocul anilor '60, IBM s-a alăturat NAA dezvoltând în continuare GUAM şi
producând unul dintre primele sisteme comerciale de gestiune a bazelor de date:
IMS (Information Management System). IBM a preluat modelul ierarhic pentru
a respecta cerinţa de stocare a datelor pe benzi magnetice (deci în acces
secvenţial). Ulterior, această restricţie a fost înlăturată şi IMS continuă să fie
principalul SGBD ierarhic utilizat de majoritatea calculatoarelor mainframe7.
Construirea bazelor de date a cunoscut o evoluţie foarte rapidă, trecând
prin mai multe abordări, clasificate după cum urmează:
sistemele de fişiere;
sistemele prerelaţionale (sau „istorice", numite şi navigante sau
tradiţionale -legacy systems): ierarhic şi reţea;
sistemul relaţional;
sistemele postrelaţionale: orientat obiect şi hibrid (obiect-relaţional);
sistemele semantice: multidimensional şi logic (deductiv).
1.4.2 Sistemul de gestiune bazat pe fişiere (SGF)
Considerat de fapt un predecesor al sistemelor de gestiune a bazelor de
date, SGF reprezenta o colecţie de programe care realizau - fiecare - câte „un
serviciu" pentru utilizatorii datelor (de obicei: generarea de rapoarte). Fiecare
program îşi definea şi îşi administra propriile date. Chiar dacă a avut numeroase
dezavantaje (abordarea descentralizată în stocarea informaţiilor, gradul mare de
redundanţă şi dependenţă program-date), sistemul de gestiune bazat pe fişiere a
constituit un salt semnificativ faţă de fişierele administrate manual: saltul de la
abordarea informaţională la cea informatică.
7 Un calculator mainframe este un calculator cu capacitate de memorie şi viteză de lucru foarte
mari, utilizat de marile corporaţii pentru a stoca volume foarte mari de date şi pentru a coordona sute sau mii de terminale (inclusiv calculatoare personale) conectate la el.
29
1.4.3 Modele prerelaţionale
Aceste modele pot fi caracterizate ca modele de moment: au oferit soluţii
pentru problemele vremii lor, dar nu au avut un fundament teoretic puternic şi
riguros. Atât în modelul ierarhic, cât şi în modelul reţea datele erau reprezentate
ca mulţimi de înregistrări (în sensul limbajului de programare Pascal: colecţii de pate de diferite tipuri: Integer, Boolean, Real etc.). Relaţiile dintre ele erau
reprezentate prin legături de tip pointer (adrese de locaţii fizice de memorie)
Înregistrările care formau baza de date erau organizate:
în modelul ierarhic: ca o mulţime de arbori ;
în modelul reţea: ca o mulţime de grafuri.
Ambele modele prerelaţionale permiteau accesul la date de-a lungul unor
drumuri (căi) predefinite, explicit stabilite la nivelul programelor de aplicaţii (de
şi numele de modele navigante). Ca urmare, orice modificare a structurii bazei
de date antrena modificarea acestor căi în programele deja scrise. Exemple: :tru
modelul ierarhic: IMS (amintit mai sus); pentru modelul reţea: IDS II (de
Honeywell), IMAGE (de la Hewlett Packard).
Studiu de caz: modelarea activităţii didactice
Într-o facultate, cadrele didactice desfăşoară activităţi didactice de curs sau
examen; aceste activităţi sunt pentru studenţi şi se desfăşoară în locaţii
(amfiteatre sau laboratoare). De asemenea, cadrele didactice participă la
proiecte de cercetare ştiinţifică. Figura 1.2 prezintă modelul ierarhic al facultăţii
iar figura 1.3 prezintă modelul reţea.
Figura 1.2 Modelul ierarhic
30
Figura 1.3 Modelul reţea
1.4.4 Modelul relaţional
Considerat drept cel mai important eveniment din istoria bazelor de date,
apariţia modelului relaţional s-a produs în iunie 1970, odată cu publicarea - în
revista Communications of the ACM - a articolului fundamental al lui Edgar
Frank Codd8 (de la IBM Research Laboratory): „A Relaţional Model of Data for
Large Shared Databanks". În acest articol, autorul aplica o serie de concepte din
algebra relaţională pentru a rezolva problemele legate de stocarea volumelor
mari de date şi enunţa „celebrele" 12 reguli (condiţii) pe care trebuie să le
îndeplinească un SGBD pentru a fi declarat relaţional.
Să amintim însă existenţa unui precursor: modelul bazat pe teoria
mulţimilor, propus de D.L. Childs în articolul său: „Feasability of a Set-
Theoretical Data Structure", apărut în 1968.
Cele mai importante prototipuri de sisteme de gestiune a bazelor de date
de tip relaţional au fost:
System R, dezvoltat la San Jose Research Laboratory din California spre
sfârşitul anilor '70. Acest model a condus la:
8 E.F. Codd s-a născut la 23 august 1923 în Portland, Marea Britanie, şi a murit în 18 aprilie
2003, în Florida. A făcut studii de matematică şi chimie la Oxford şi s-a mutat în Statele Unite, în 1948, pentru a lucra la IBM. A introdus termenul OLAP (OnLine Analytical Processing) şi a impus modelul relaţional; a avut, de asemenea, contribuţii în domeniul modelelor de
calculabilitate prin lucrările sale privind automatele celulare. A obţinut de două ori Premiul Turing: în 1981 şi 1994.
31
o apariţia unui limbaj structurat de interogare a bazelor de date: SQL.
o producerea mai multor SGBD-uri relaţionale comerciale: DB2 şi
SQL/DS de la IBM şi, respectiv, ORACLE de la Oracle
Corporation (în deceniul 9 al secolului trecut).
INGRES (Interactive Graphics Retrival System), dezvoltat la Universitatea
Berkeley din California.
Peterlee Relaţional Test Vehicle, dezvoltat la IBM UK Centre din Peterlee,
Marea Britanie.
Numărul sistemelor relaţionale comerciale a ajuns acum la câteva sute, dintre
care cele mai cunoscute sunt: DB2 (de la IBM), Ingres II (de la Computer
Associates International Inc.), Oracle 10g (de la Oracle Corporation), Ms
Access, FoxPro (de la Microsoft), Paradox, Visual dBase (de la Borland),
Sybase Adapted Server (de la Sybase Inc.). Succesul acestui model continuă să
fie atât de mare încât multe sisteme nerelaţionale oferă acum şi o interfaţă cu
utilizatorii de tip relaţional, indiferent de modelul de date pe care se bazează de
fapt.
Informal putem defini model relaţional de date ca pe un model în care:
datele sunt percepute de utilizatori ca nişte tabele şi numai ca nişte tabele;
operaţiile disponibile pentru utilizatori (spre exemplu, pentru obţinerea informaţiilor) sunt operaţii care generează noi tabele pe baza tabelelor
vechi: operaţia de selecţie (SELECT) extrage o submulţime de rânduri
dintr-o tabelă, operaţia de proiecţie (PROJECT) extrage o submulţime de
coloane, operaţia de juxtapunere (JOIN) asociază două tabele pe baza valorilor identice pe care le conţin în anumite coloane, de asemenea
identice; or, toate aceste submulţimi rezultate pot fi privite şi ele însele ca
nişte tabele.
Numele modelului relaţional provine de la conceptul matematic de relaţie. Aşa
cum o funcţie f : {1, 2,...,n} N→ R are mai multe reprezentări convenţionale, dintre care cea mai comodă este cea de vector, tot astfel relaţia poate avea mai multe reprezentări, una dintre ele fiind tabela. Din acest motiv, cel puţin la nivel
informal, termenii de relaţie şi tabelă pot fi consideraţi sinonimi.
32
1.4.5 Modelele postrelaţionale şi noi funcţionalităţi
Chiar dacă se regăseşte în descrierea unor situaţii reale, cu organizare intrinsec piramidală, modelul ierarhic şi-a atins rapid limitele. La fel, modelul
relaţional a devenit impropriu pentru rezolvarea unor probleme din realitatea
înconjurătoare care presupun manipularea unor volume uriaşe de informaţie, a unei mari varietăţi de tipuri de date: hărţi meteorologice sau geografice necesare
previziunilor meteorologice sau dirijării traficului, imagini transmise prin satelit
utilizate în măsurarea factorilor poluanţi, date neconvenţionale pentru
proiectarea asistată de calculator în inginerie sau arhitectură, serii dinamice implicate în tranzacţiile bursiere sau bancare, stocarea obiectelor binare mari
(BLOBs = Binary Large Objects) necesare în digitalizarea informaţiei conţinută
în fişierele audio sau video. Au apărut astfel şi s-au dezvoltat modelele postrelaţionale, de generaţia a treia: modelul orientat obiect şi modelul obiect-
relaţional. Alături de acestea observăm noi funcţionalităţi ale bazelor de date:
baze de date partajate în reţea, baze de date distribuite, baze de date deductive,
depozite de date, baze de date multidimensionale.
(I) Modelul orientat obiect permite înglobarea semanticii obiectelor
celor mai variate, la fel ca în limbajele de programare orientate-obiect. De altfel,
una dintre deosebirile majore faţă de modelul relaţional constă în distanţarea de conceptul de independenţă faţă de limbajele de programare şi dezvoltarea
conceptului de integrare a limbajelor de programare în sistemul de gestiune a
bazei de date (invocarea unor funcţii C++ mai degrabă decât înglobarea unui
limbaj special pentru interogarea datelor, ca de exemplu SQL). Acest fapt a fost determinat de:
♦ utilizarea aproape exclusivă a limbajelor de programare orientate-obiect pentru dezvoltarea aplicaţiilor software;
♦ includerea în aproape orice aplicaţie software a unei baze de date ca
element fundamental al acesteia.
Cele mai cunoscute prototipuri de baze de date orientate-obiect sunt:
OPENOODB (de la Texas Instruments), IRIS (de la Hewlett Packard), iar ca variantă comercială: GEMSTONE/OPAL (de la GemStone Systems), VERSANT
(de la Versant Object Technology). Deşi cu o cotă de piaţă semnificativ
inferioară sistemului relaţional (150 milioane dolari faţă de 10 miliarde, numai în SUA în anul 1999), modelul orientat-obiect este creditat cu o creştere anuală
extrem de rapidă: 50%.
În ciuda caracterului intuitiv şi a altor avantaje evidente ale modelului orientat-obiect, modelul relaţional continuă să domine piaţa sistemelor de
gestiune a bazelor de date. Motivele sunt numeroase: fundamentarea matematică riguroasă, simplitatea, volumul mare de date deja stocate după acest
model şi costul enorm al migrării spre un model complet diferit.
33
(II) Modelul obiect-relaţional extinde modelul relaţional, oferind un set de tipuri de date mai bogat, şi include şi orientarea obiect. Se încearcă astfel
combinarea avantajelor celor două abordări, cea relaţională şi cea orientată-
obiect: atributele şi instanţele entităţilor pot avea tipuri complexe şi pot evita unele dintre restricţiile specifice modelului relaţional. De exemplu, în timp ce în
modelul relaţional fiecare atribut trebuie să ia pentru fiecare instanţă a unei
entităţi o valoare şi numai una din domeniul lui de definiţie, în acest model
poate lua un sub-set de valori (de exemplu: pentru un angajat oarecare, atributul Telefon poate lua ca valori numărul telefonului fix de acasă şi de la serviciu, al
telefonului mobil propriu şi de serviciu, dacă angajatul dispune de toate patru).
Cel mai cunoscut exemplu: Informix Universal Server care combină teh-
nologiile relaţionale şi orientate obiect din două produse preexistente: Informix
şi Illustra. Noi funcţionalităţi ale bazelor de date:
a. baze de date partajate în reţea; în condiţiile lucrului în reţea este posibil să
se stocheze baza de date pe un calculator ce are loc de server. Astfel toţi utilizatorii vor partaja între ei baza de date. Administratorul bazei de date
are sarcini pe linia modelării datelor, a implementării bazei de date, definirii
utilizatorilor şi a drepturilor de acces şi întreţinerea bazei de date. Drepturile
de acces la nivel utilizator vizează operaţiile pe care acestea le pot realiza. b. baze de date distribuite; unităţile economice dispersate geografic sunt
nevoite să acceseze baze de date care sunt distribuite. Lucrul într-o reţea 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 bază de date
locală şi, în plus, la bazele de date distribuite în celelalte site-uri. Conexiunile inter-site-uri pot fi stabilite într-o manieră diversă.
c. baze de date deductive; acest gen de baze de date se fundamentează
cuplarea unei baze de date relaţionale cu un procesor din clasa sistemelor
expert. d. depozite de date (datawarehouse); un depozit de date reprezintă un sistem
de baze de date 1) ce acoperă un sistem temporal mai mare; 2) ce conţine
date interne şi externe; 3) optimizat pentru a răspunde interogărilor complexe (de la manageri la analişti).
e. baze de date multidimensionale; acest gen de baze de date au apărut ca
urmare a necesităţilor crescânde de procesare multidimensională a datelor.
Aplicaţiile care se bazează pe analiza multidimensională a datelor sunt cunoscute sub numele de OLAP (On Line Analytical Processing
9)
9 Se face distincție între:- OLTP (On-Line Transactional Processing) care privilegiază:
integritatea și securitatea datelor și tratarea cererilor informaționale simple de către servicii operaționale (producție, comercial, resurse umane).și – OLAP, care privilegiază analiza și
manipularea datelor (folosind cereri complexe) în vederea elaborării stategiei și sunt destinate îndeosebi conducerii și controlului de gestiune.
34
1.5 Rezumatul capitolului
A proiecta o bază de date înseamnă a-i stabili structura, adică elementele
componente, caracteristicile acestora, restricţiile pe care trebuie să le respecte,
relaţiile dintre ele.
A construi o bază de date înseamnă a memora (a introduce) datele în baza de
date, după proiectarea acesteia.
A administra o bază de date înseamnă a asigura: (1) accesul la date al uti-
lizatorilor, în funcţie de drepturile fiecăruia (funcţia şi importanţa fiecăruia în
organizaţia respectivă), (2) coerenţa bazei de date (recuperarea informaţiei
atunci când au loc incidente: întreruperea alimentării cu curent electric, operaţii
contradictorii etc), (3) securitatea datelor stocate etc.
A interoga o bază de date înseamnă a extrage şi a vizualiza datele care
îndeplinesc anumite criterii şi condiţii.
A actualiza o bază de date înseamnă a modifica structura sau informaţiile
stocate în baza de date.
Sistemul de gestiune al bazei de date (SGBD) reprezintă software-ul propriu-zis al acesteia care asigură realizarea următoarelor activităţi:
- definirea structurii bazei de date;
- încărcarea datelor în baza de date;
- accesul la date (interogare, actualizare);
- întreţinerea bazei de date (colectarea şi refolosirea spaţiilor goale, refacerea bazei de date în cazul unui incident);
- reorganizarea bazei de date (restructurarea şi modificarea strategiei de
acces).
SGBDR se defineşte ca fiind un sistem de gestiune care utilizează
organizarea datelor conform modelului relaţional.
35
1.6 Întrebări de auto-evaluare 1) Explicaţi conceptul de bază de date.
2) Definiţi sistemul de gestiune al bazelor de date şi daţi exemple.
3) Enumeraţi obiectivele unui SGBD.
4) Enumeraţi funcţiile unui SGBD.
Citiţi întrebările de mai jos şi alegeţi varianta corectă de răspuns:
5) Un model de date este: a. mecanismul care asigură partajarea datelor dintr-o bază de date între
aplicaţiile care o accesează.
b. tehnica prin care pot fi organizate informaţiile într-o întreprindere. 6) Modelul ierarhic şi modelul reţea sunt:
a) modele relaţionale;
b) modele prerelaţionale;
c) modele hibride. 7) Asociaţi fiecare tip de model de date cu conceptul teoretic pe care se
bazează:
Model Concept
Ierarhic Relaţie
Reţea Arbore
Relaţional Graf
36
37
CAPITOLUL 2
PROIECTAREA ŞI IMPLEMENTAREA BAZELOR DE
DATE
2.1 Arhitectura ANSI-SPARC
Asigurarea independenţei fizice şi logice a datelor impune adoptarea unei arhitecturi organizată pe cel puţin 3 nivele (arhitectura ANSI-SPARC
10):
1. nivelul intern (baza de date fizică)
2. nivelul conceptual
3. nivelul extern Obiectivul arhitecturii cu 3 nivele este separarea vederii fiecărui utilizator
asupra bazei de date de modul în care este ea reprezentată fizic (figura 2.1).
Figura 2.1 Arhitectura ANSI-SPARC pe trei nivele pentru bazele de date
10
ANSI = American National Standards Institute
SPARC = Standards Planning and Requirements Committee
38
Nivelul intern (baza de date fizică) este o colecţie de fişiere conţinând datele
fizice la care se adaugă diverse structuri auxiliare menite să asigure accesul
operativ la date. Structurile auxiliare pot fi: directoare, indexi, pointeri, tabele de dispersie. Modul de organizare a bazei de date fizice este în mare măsură
influenţat de configuraţia echipamentelor hardware care suportă baza de date şi
de sistemul de operare. Schimbarea sistemului de operare sau modificări în
configuraţia hardware pot atrage modificări ale bazei de date fizice. Dacă este satisfăcută condiţia de independenţă fizică, aceste modificări în nivelul intern al
bazei de date nu vor ataca nivelele superioare ale acesteia.
Nivelul intern tratează chestiuni cum ar fi:
• alocarea spaţiului de stocare pentru date şi indexi ;
• descrierea înregistrărilor pentru stocare (cu dimensiunile de
stocare pentru date) ;
• plasarea înregistrărilor ;
• tehnici de comprimare a datelor şi de codificare a acestora.
Nivelul conceptual conţine structura logică a bazei de date, aşa cum este ea
văzută de administratorul bazei de date. Fiecare bază de date are un model
conceptual propriu prin care sunt numite şi descrise toate entităţile logice din
baza de date împreună cu legăturile dintre acestea. El reprezintă o imagine
completă a cerinţelor organizaţiei privind datele. Ex: în descrierea bazei de date a unei întreprinderi pot apărea concepte ca: angajat, produse, furnizor, beneficiar, etc.
Nivelul conceptual integrează viziunile tuturor utilizatorilor asupra
bazei de date, fiind rezultatul unui compromis între cerinţele diferiţilor utilizatori. Nivelul conceptual reprezintă:
• toate entităţile, atributele şi relaţiile dintre ele;
• constrângeri asupra datelor; • informaţii semnatice asupra datelor;
• informaţii privind securitatea şi integritatea.
De reţinut că nivelul conceptual este o descriere a conţinutului de date din
baza de date şi NU cuprinde nici un fel de referire la modul de memorare a
datelor sau la strategia de acces. De ex. descrierea unei entităţi trebuie să
conţină numai tipurile de date (integer, real, character) şi lungimea lor
(numărul maxim de cifre sau caractere), dar nici o informaţie privind
stocarea, cum ar fi numărul de octeţi ocupat.
Nivelul extern este cel mai apropiat utilizatorului. Este ceea ce vede acesta din
baza de date, sau modul cum vede acesta baza de date. Nivelul extern este
derivat din cel conceptual dar poate prezenta deosebiri substanţiale faţă de acesta. Un termen deseori folosit pentru modelul extern este acela de vedere sau
39
viziune. Prin aceste viziuni, utilizatorii au acces doar la părţi bine definite din baza de date, fiindu-le ascunse părţile care nu interesează. Prin modelul extern
se realizează independenţa logică a datelor. Fiecărei viziuni îi corespunde o
descriere în termenii entităţilor logice din modelul conceptual. Diferite vederi pot avea reprezentări diferite ale aceloraşi date. De ex, un
utilizator poate vedea datele calendaristice în format an-lună-zi, altul le poate
vedea ca zi-lună-an.Vederile pot include chiar date combinate sau derivate din
entităţi diferite.
2.2 Proiectarea bazelor de date
Realizarea unei baze de date se desfăşoară în mai multe etape; cele mai importante sunt: (1) analiza, (2) proiectarea şi (3) implementarea.
(1) în etapa de analiză se examinează în mod sistematic şi aprofundat acel
aspect al lumii reale care trebuie transpus într-o bază de date: o tipografie, magazin universal, organizarea unei expoziţii etc; se stabilesc gradul de
generalitate, dimensiunea bazei de date, categoriile şi numărul de viitori
utilizatori. O bază de date trebuie să conducă la ameliorarea activităţii din
organizaţia respectivă şi se realizează la cererea proprietarului.
(2) Etapa de proiectare se poate descompune în trei subetape:
2a) proiectarea bazei de date la nivel conceptual,
2b) proiectarea bazei de date la nivel logic şi
2c) proiectarea bazei de date la nivel fizic. În această etapă se poate selecta
sistemul de gestiune a bazei de date, se proiectează interfeţele şi aplicaţiile de utilizare şi administrare a bazei de date.
(3) Etapa de implementare constă din realizarea propriu-zisă a bazei de date:
scrierea programelor, conversia şi încărcarea datelor.
Proiectarea unei baze de date= procesul de creare a unui proiect
pentru baza de date care să asigure desfășurarea corectă a
activităților și rezolvarea cerințelor utilizatorilor.
40
Principalele scopuri ale etapei de proiectare sunt:
reprezentarea datelor şi a relaţiilor dintre date, conform cerinţelor formulate
de utilizatori şi condiţiilor impuse de programele de calculator;
furnizarea unui model de date care să asigure orice tip de prelucrare a
datelor;
schiţarea unui proiect astfel structurat încât să satisfacă parametrii de efi-
cienţă specificaţi (de exemplu: obţinerea datelor solicitate într-un interval de
timp cel mult egal cu o valoare prestabilită).
Proiectarea bazei de date se poate face prin metoda:
bottom-up: se începe cu stabilirea atributelor şi - prin analiza asocierilor
dintre ele - se obţin entităţile şi relaţiile dintre entităţi;
top-down: se dezvoltă un model de date constând din câteva entităţi şi
relaţii foarte generale. Apoi, modelul este rafinat, obţinându-se modele
din ce în ce mai detaliate;
mixtă: se combină şi se iterează metodele de mai sus.
2.3 Utilizarea modelelor de date în etapa de proiectare
Indiferent de metoda de proiectare folosită, identificarea entităţilor şi a
relaţiilor dintre ele necesită:
înţelegerea semnificaţiei datelor care circulă în organizaţia respectivă;
înţelegerea cerinţelor specifice modului de lucru din organizaţie;
reprezentarea coerentă şi sugestivă a acestor informaţii.
Candance Fleming şi Barbara von Halle (1989) au identificat câteva criterii
pe care ar trebui să le îndeplinească un model de date pentru a fi considerat
optim în raport cu realitatea modelată: corectitudine, simplitate, expresivitate, neredundanţă, extensibilitate, integritate.
41
Figura 2.2 Succesiunea fazelor în modelarea bazelor de date
Instrumentul universal capabil să asigure realizarea acestor obiective printr-o
bună comunicare între specialiştii care proiectează baza de date şi viitorii
utilizatori ai acesteia este modelarea datelor. Modelul de date de nivel înalt cel
mai frecvent folosit este modelul entitate-relaţie (Entity-Relationship Model), iar
cea mai larg utilizată reprezentare grafică a acestuia (asupra căreia vom reveni
în capitolul următor) este diagrama entitate-relaţie (figura 2.3).
Figura 2.3 Diagrama entitate-relaţie a bazei de date a unei facultăţi
42
2.4 Modelul conceptual al bazei de date
Proiectarea schemei conceptuale a bazei de date constituie prima fază a
proiectării şi conduce la realizarea modelului conceptual. Acest model este
complet independent de orice detalii de implementare: ce SGBD, ce programe
de aplicaţie (scrise în ce limbaj de programare) se vor folosi, pe ce platformă hardware şi sub ce sistem de operare. Această fază a proiectării bazei de date se
desfăşoară iterativ: fiecare variantă a modelului este testată în raport cu cerinţele
utilizatorilor (condiţiile sau restricţiile formulate de aceştia) pentru a verifica adecvarea modelului de date la situaţia reală modelată.
De exemplu, pentru domeniul comercial schema conceptuală va conţine
următoarele colecţii de date: agenţi comerciali, clienţi (beneficiari), furnizori, produse finite, materii prime, comenzi de produse finite, comenzi pentru
aprovizionarea cu materii prime, facturi, înregistrări contabile în contul
furnizori şi de clienţi.
2.5 Modelul logic al bazei de date
Proiectarea logică a bazei de date este a doua fază a proiectării şi conduce la
realizarea modelului logic. întrucât porneşte obligatoriu de la modelul con-
ceptual, deci se bazează implicit pe un anumit tip de model de date - relaţional,
ierarhic, orientat-obiect etc, modelul logic orientează proiectul bazei de date
spre un anumit tip de SGBD - relaţional, ierarhic etc, fără a alege, spre exemplu,
între MS Access şi Oracle. În continuare, detaliile de implementare fizică -
Proiectarea bazei de date la nivel conceptual = procesul de
construire a unui model privind informaţiile care circulă într-o
organizaţie, independent de orice implementare a acestora la
nivel fizic.
Proiectarea baze de date la nivel logic = procesul de construire a
unui model privind informaţiile care circulă într-o organizaţie pe
baza unui model conceptual independent de alegerea unui SGBD,
precum şi de orice detalii de implementare la nivel fizic.
43
precum modul de stocare a datelor, tipurile de indexare etc. - sunt complet
ignorate.
Pe parcursul acestei etape, modelul este permanent testat şi validat, cu
ajutorul datorilor, pentru a descoperi eventualele neconcordanţe cu restricţiile
formulate de aceştia. Tehnica folosită se numeşte normalizare şi urmăreşte
asigurarea corectitudinii modelului logic (de exemplu, prin eliminarea
redundanţelor în date, redudanţe care - o dată implementate - pot genera erori în
timpul operaţiilor de actualizare a bazei).
Proiectarea conceptuală şi proiectarea logică a bazei de date sunt etape
foarte importante, critice, pentru realizarea unui proiect bun al bazei de date.
Dacă unul dintre ele nu reprezintă corect aspectul modelat, implementarea fizică
a bazei de date va fi eronată şi corectarea ulterioară aproape imposibilă. De
aceea, rafinarea modelului conceptual şi a celui logic este un proces iterativ,
virtual infinit.
2.6 Modelul fizic al bazei de date
Proiectarea fizică a bazei de date este ultima fază a proiectării, cea în care
proiectantul alege modul concret de implementare a bazei de date. Prima
operaţie constă în alegerea unui SGBD care să poată implementa modelul logic.
Urmează comunicarea între modelul fizic şi cel logic, similară celei dintre
modelul logic şi cel conceptual: orice decizie privind implementarea fizică
(ameliorarea performanţelor, asigurarea securităţii etc.) poate afecta structura
modelului logic. Cu toate acestea, modelul conceptual şi modelul logic trebuie
să fie în continuare complet separate de modelul fizic al bazei de date şi fiecare
trebuie să-şi păstreze scopul: primele să răspundă la întrebarea: „CE trebuie
făcut"; ultimul la: „CUM trebuie făcut".
Această abordare a proiectării bazelor de date este compatibilă cu
arhitectura pe trei nivele a acestora, aşa cum a fost ea stabilită de ANSI-SPARC în 1975.
Figura 2.4 prezintă modelarea datelor şi arhitectura ANSI-SPARC.
Proiectarea baze de date la nivel fizic = procesul de construire a unei
specificaţii privind memorarea datelor din baza de date pe suporturile
fizice de memorie; sunt descrise: structura memoriei și metodele de
accesare menite să asigure accesul eficient la informaţii.
44
Figura 2.4 Modelarea datelor şi arhitectura ANSI-SPARC.
45
2.7 Rezumatul capitolului
Asigurarea independenţei fizice şi logice a datelor impune adoptarea unei
arhitecturi organizată pe cel puţin 3 nivele (arhitectura ANSI-SPARC): . nivelul intern (baza de date fizică); nivelul conceptual şi nivelul extern.
Nivelul intern (baza de date fizică) este o colecţie de fişiere conţinând datele
fizice la care se adaugă diverse structuri auxiliare menite să asigure accesul operativ la date.
Nivelul intern tratează chestiuni cum ar fi: alocarea spaţiului de stocare pentru
date şi indexi ; descrierea înregistrărilor pentru stocare (cu dimensiunile de
stocare pentru date) ; plasarea înregistrărilor ; tehnici de comprimare a
datelor şi de codificare a acestora.
Nivelul conceptual conţine structura logică a bazei de date, aşa cum este ea
văzută de administratorul bazei de date. Fiecare bază de date are un model
conceptual propriu prin care sunt numite şi descrise toate entităţile logice din
baza de date împreună cu legăturile dintre acestea. Nivelul conceptual
reprezintă: toate entităţile, atributele şi relaţiile dintre ele; constrângeri asupra
datelor; informaţii semnatice asupra datelor; informaţii privind securitatea şi integritatea.
Nivelul extern este cel mai apropiat utilizatorului. Prin modelul extern se
realizează independenţa logică a datelor. Fiecărei viziuni îi corespunde o
descriere în termenii entităţilor logice din modelul conceptual. Proiectarea unei baze de date este procesul de creare a unui proiect pentru
baza de date care să asigure desfăşurarea corectă a activităţilor şi rezolvarea
cerinţelor utilizatorilor.
Realizarea unei baze de date se desfăşoară în mai multe etape; cele mai
importante sunt:
(1) analiza se examinează în mod sistematic şi aprofundat acel aspect al lumii
reale care trebuie transpus într-o bază de date;
(2) proiectarea, are 3 subetape: 2a) proiectarea bazei de date la nivel conceptual,
2b) proiectarea bazei de date la nivel logic şi 2c) proiectarea bazei de date la
nivel fizic. În această etapă se poate selecta sistemul de gestiune a bazei de date, se proiectează interfeţele şi aplicaţiile de utilizare şi administrare a bazei de
date.
(3) implementarea: realizarea propriu-zisă a bazei de date.
Proiectarea bazei de date se poate face prin metoda: bottom-up, top-down sau
mixtă.
46
2.8 Întrebări de autoevaluare
Citiţi întrebările de mai jos şi alegeţi varianta corectă de răspuns:
1) Care este ordinea corectă a celor trei niveluri care compun arhitectura
ANSI-SPARC pentru bazele de date:
a) nivelul conceptual, nivelul intern, nivelul extern;
b) nivelul conceptual, nivelul extern, nivelul intern;
c) nivelul extern; nivelul conceptual, nivelul intern.
2) Proiectarea bazelor de date se poate face prin:
a) metoda bottom-up;
b) metoda top-down;
c) combinarea şi iterarea metodelor bottom-up şi top-down.
d) oricare dintre metodele de mai sus.
3) Un model de date optim îndeplineşte următoarele criterii:
a) corectitudine, simplitate;
b) expresivitate, neredundanţă;
c) extensibilitate, integritate;
d) toate cele de mai sus.
4) Care dintre cele trei modele ale unei baze de date: logic, conceptual, fizic,
„răspunde" la întrebarea: CE trebuie făcut?
a) modelul logic şi modelul conceptual;
b) modelul conceptual şi modelul fizic;
c) modelul fizic şi modelul logic.
47
CAPITOLUL 3
MODELUL CONCEPTUAL AL BAZELOR DE DATE
RELAŢIONALE
Aşa cum am văzut în capitolul anterior, proiectarea unei baze de date
începe cu analiza situaţiei reale care trebuie modelată prin baza de date. Această analiză necesită un dialog între proiectantul bazei de date şi viitorii ei utilizatori.
Astfel, sunt puse în evidenţă:
♦ cerinţele utilizatorilor privind datele care trebuie stocate şi administrate;
♦ cerinţele utilizatorilor privind operaţiile care trebuie efectuate cu aceste date.
Etapa următoare constă în realizarea modelului conceptual al bazei de date. în
cazul modelului relaţional, se începe cu o descriere detaliată a entităţilor şi atributelor, a relaţiilor dintre entităţi şi a condiţiilor pe care trebuie să le îndepli-
nească. Această descriere poate fi fi reprezentată prin mai multe forme: schema
conceptuală, diagrama entitate-relaţie (diagrama ER).
3.1 Entitaţi şi instanţe
În literatura dedicată bazelor de date există mai multe definiţii pentru
termenul entitate:
Trebuie să facem distincţie între conceptele de entitate şi instanţă a unei entităţi,
istă distincţie este similară celei dintre tipul de dată şi valoare într-un limbaj
programare.
Entitate = un „lucru" sau un „obiect" din lumea reală care poate fi
distins (deosebit) de toate celelalte lucruri sau obiecte. Entitate = un obiect (un tablou etc), un eveniment (naşterea unei
persoane etc), o activitate (închirierea unei maşini etc.) din lumea
reală care poate fi descris(ă) prin racteristici bine definite (despre care există date care pot fi stocate).
Prin entitate înţelegem mulţimea tuturor elementelor de un anumit tip
(care prezintă aceleaşi caracteristici).
Prin instanţă a unei entităţi înţelegem un singur element, bine
individualizat, unic, din mulţimea elementelor care formează entitatea
respectivă.
48
Exemplu: fiecare client al unei bănci este o instanţă a entităţii Clienţi; fiecare
curs predat într-o facultate este o instanţă a entităţii CursuriUniversitare etc.
OBSERVAŢII.
• O entitate poate avea subentităţi; acestea trebuie să fie disjuncte; de
exemplu, entităţile Piloţi şi MecaniciDeBord sunt disjuncte şi sunt subentităţi
ale entităţii PersonalNavigant.
• Într-o bază de date pot exista entităţi a căror existenţă este determinată de
alte entităţi; primele se numesc entităţi dependente, celelalte se numesc entităţi
principale (de exemplu, entitatea Persoaneînîntreţinere depinde de entitate
Salariaţi).
3.2 Atribute
3.2.1 Concept şi tipologie
Un atribut posedă un nume şi - pentru fiecare instanţă a entităţii - poate lua o
valoare dintr-o mulţime fixată de valori, numită domeniul de valori ale
atributului.
Exemplu:
Fie entitatea Ţări; considerăm atributele Nume, Continent, Capitală, Formă
DeGuvernământ, Suprafaţă, SărbătoareNaţională. Tabelul 3.1 prezintă câteva
instanţe ale acestei entităţi şi valorile luate de atribute.
NumeŢară Continent Capitala Forma de
guvernământ
Nr.km
pătraţi
Sărbătoare
naţională
Slovacia Europa Bratislava Republică
constituţională
49.036 1 Sept.
Franţa Europa Paris Republică
prezidenţială
547.026 14 Iul.
România Europa Bucureşti Republică
constituţională
237.500 1 Dec.
Japonia Asia Tokyo Monarhie
constituţională
370.073 29 Apr.
SUA America
de Nord
Washington Republică
prezidenţială
9.363.123 4 Iul.
Tabel 3.1. Instanţele entităţii Ţări şi valorile atributelor sale
Atribut = o caracteristică a unei entităţi.
49
Clasificarea atributelor
A) Atributele se pot clasifica după complexitate:
o atribute compuse;
o şi atribute simple sau elementare, după cum ele se mai descompune sau
nu în alte atribute, de mai mică complexitate.
Există atribute nu pot fi decât simple (atributele Capitală, Suprafaţă, Continent
ale entităţii Ţări). Există însă atribute care pot fi considerate fie simple, fie
compuse. De exemplu atributul DataNaşterii cu valorile: 1 ianuarie 2000, 2 Mai
1990 etc. poate fi privit fie ca un atribut simplu, fie ca unul compus din
atributele Zi, Lună, An.
Este indicat să îl tratăm ca un atribut compus, dacă prevedem necesitatea de a
avea acces direct la luna sau anul de naştere al unei persoane înregistrate în baza
de date. Dacă însă o astfel de necesitate nu este probabilă şi dacă dorim să sim-
plificăm structura entităţii (şi deci a bazei de date), atunci este preferabil să îl
tratăm ca atribut simplu.
B) Atributele se pot clasifica după mulţimea de valori în:
o atribute cu valori unice;
o şi atribute cu valori multiple, după cum ele pot lua câte o singură
valoare (de exemplu, atributele Capitală, Suprafaţă, Continent ale
entităţii Ţări) sau, dimpotrivă, pentru unele instanţe pot lua câte o
singură valoare, pentru altele mai multe valori, iar pentru altele nici o
valoare (de exemplu, atributul OraşCuMinimumlMilioane Locuitori al
entităţii Ţări).
Când este cazul se pot defini limite inferioare şi/sau superioare pentru numărul
de valori pe care le poate lua un astfel de atribut pentru o instanţă oarecare (de
exemplu, putem specifica faptul că atributul NrTelefon al entităţii Persoane
poate lua minimum o valoare - telefonul de serviciu - şi maximum trei).
C) Atributele se pot clasifica după stabilitate în:
o atribute de bază;
o şi atribute derivate, după cum ele au valori de sine stătătoare sau valori
care pot fi calculate din valorile altor atribute.
De exemplu, să considerăm entităţile corelate Cărţi, cu atributul NumărAutori -
şi Autori, cu atributul Titlu; atributul NumărAutori este un atribut derivat:
valorile pe care le ia pentru diferite instanţe ale entităţii Cărţi pot fi calculate pe
baza numărului de apariţii ale atributului Titlu pentru diferite instanţe ale
entităţii Autori.
50
3.2.2 Cheia primară, un atribut special
Un atribut special îl reprezintă identificatorul unic. Utilizarea instanţelor unei
entităţi ridică două probleme foarte importante:
- modul de adresare a fiecărei instanţe a unei entităţi;
- determinarea instanţelor care se repetă.
Să presupunem că dispunem de o bază de date a trenurilor care circulă în
România şi vrem să prelucrăm informaţiile legate de un rapid care leagă oraşul
Timişoara de Cluj Napoca. Ca să ne referim la această instanţă Trenuri ar trebui
să enumerăm toate valorile pe care le iau atributele entităţii. Dacă ar fi 5 sau 10
atribute nu ar fi prea greu; dar dacă ar fi 50? Pentru a simplifica referirea la
instanţele unei entităţi s-a recurs la mecanismul identificatorului unic, adică al
cheii primare.
Exemple:
1) pentru entităţi precum Studenţi, Profesori, Angajaţi un exemplu de
identificator unic este codul numeric personal; un contraexemplu: numele
(chiar însoţit de prenume) sau data naşterii. Se poate utiliza şi atributul
convenţional CodStudent (CodProfesor etc), cu valori formate din iniţialele
numelui şi prenumelui, urmate de numere distincte formate din 2 sau 3
cifre.
2) Pentru entitatea Comenzi putem folosi un atribut convenţional (de exemplu:
CodComandă, cu valori numere distincte) sau putem folosi trei atribute ale
sale: NumeFurnizor, NumeClient, DataEmiterii.
În alte situaţii, identificatorul unic este compus dintr-o combinaţie de două sau
mai multe atribute (identificator unic compus). De exemplu combinaţia dintre
titlu, numele autorului şi data apariţiei poate forma unicul identificator al
Cheia primară= un atribut sau cea mai mică mulţime de atribute ale
unei entităţi care iau, fiecare instanţă a entităţii respective, o valoare
şi numai una, sugestiv prin sensul figurat al cuvântului cheie. Atunci
când niciun atribut sau pe atribute ale entităţii, rezonabil de numeros, nu iau valori distincte pentru fiecare instanţă a acesteia, se poate
adăuga un „atribut convenţional" care să îndeplinească această
condiţie. De obicei, acest atribut este denumit cu ajutorul prefixelor cod sau id.
51
entităţii CARTE. Oare combinaţia titlu şi nume autor nu era suficientă?
Răspunsul este NU, deoarece pot exista de exemplu mai multe volume scrise de
Mihai Eminescu având toate titlul Poezii, dar apărute la date diferite.
O entitate (de exemplu: Angajaţi, având atributele Nume, IniţialaTatălui,
Prenume, Adresă, Funcţie, CodDepartament, Salariu, DataAngajării) poate avea
mai multe atribute care pot juca rolul de identificator unic; de exemplu:
Nume, Prenume, Adresă; Nume, Prenume, IniţialaTatălui, Adresă; Nume, Prenume, Funcţie, CodDepartament; Nume, Prenume, Adresă, Funcţie, CodDepartament.
Toate aceste combinaţii de atribute se numesc chei candidate. Prima
combinaţie îndeplineşte condiţia de minimalitate (pe care a doua nu o poate
satisface). Ca atare, dintre cele două, numai aceasta poate constitui un
identificator unic sau o cheie primară pentru entitatea Angajaţi, în timp ce a
doua este numai o cheie candidat. Acelaşi lucru este valabil şi pentru a treia şi
a patra combinaţie de atribute, ca şi pentru prima şi a patra combinaţie de
atribute.
La alegerea cheia candidate ţinem cont de următoarele:
♦ compusă din cel mai mic număr de atribute;
♦ compusă din atribute ale căror valori nu sunt susceptibile de modificări
în viitor;
♦ care nu este susceptibilă să-şi piardă unicitatea în viitor;
♦ care are valorile cele mai mici (cuvintele cele mai scurte, numerele cu
cel mai mic număr de cifre etc);
♦ care este cel mai uşor de utilizat.
3.2.3 Entitate sau atribut
Suntem adeseori confruntaţi cu problema: fiind dată o informaţie care
trebuie inclusă în baza de date, cum o modelăm – ca entitate sau ca atribut al
unei entităţi deja existente? De exemplu adresa unui cadru didactic ar trebui să
fie un atribut al entităţii CadruDidactic sau o entitate (corelată cu entitatea
CadruDidactic)? Răspunsul depinde de:
♦ semantica (semnificaţia, înţelesul) datelor,
♦ modul în care vom utiliza informaţia respectivă.
În exemplul nostru, adresa va fi modelată ca entitate în oricare dintre
următoarele cazuri:
52
o cadrul didactic are mai multe adrese. Motivul: într-o bază de date corect proiectată
(normalizată) un atribut nu poate lua simultan mai multe valori pentru aceeaşi instanţă
a unei entităţi;
o structura adresei (localitate, stradă, sectorul/judeţul etc.) este importantă ( exemplu,
trebuie să extragem din baza de date cadrele didactice care loc iese într-o anumită
localitate sau într-un anumit sector din Bucureşti). Motivul: valorile atributelor sunt
atomice.
Este indicată modelarea prin atribut în oricare dintre situaţiile complementare (o singură adresă, tratarea adresei ca un tot unitar).
53
3.3 Relaţii
3.3.1 Definiţie
Ori de câte ori un atribut al unei entităţi se referă la altă entitate din baza de date se stabileşte, de fapt, o relaţie între cele două entităţi (de exemplu,
atributul Destinaţie al entităţii Trenuri se referă la oraşul către care circulă un
tren, indicând astfel o relaţie între entitatea Trenuri şi entitatea Oraşe). Când
proiectăm baza de date, aceste referiri nu ar trebui să fie reprezentate ca atribute ale entităţilor, ci ca relaţii (atât în sensul real, cât şi în sensul matematic al
cuvântului) între entităţi. Atributele prin care se stabileşte această relaţie se
numesc chei sau câmpuri de legătură.
3.3.2 Gradul şi cardinalitatea relaţiilor
Relaţiile sunt caracterizate prin grad şi cardinalitate (sau tip).
După grad, relaţiile pot fi:
♦ grad binar (între două entităţi; de exemplu: relaţia Joacăîn este o relaţie binară
între entităţile Actori şi Filme);
♦ grad de tip n (între mai multe entităţi; de exemplu: relaţia Montează este o
relaţie de gradul cinci între entităţile Regizori, Scenografi, DesigneriCostume, Actori şi PieseDeTeatru).
Să considerăm două entităţi E1 şi E2; după cardinalitate (sau tip), relaţiile dintre cele două
entităţi pot fi :
o 1-1 (one-to-one): o relaţie între două entităţi E1 şi E2 în care unei instanţe a entităţii E 1 îi corespunde o singura instanţă din entitatea E2 şi reciproc.
o 1 - m (one-to-many): o relaţie între două entităţi E1 şi E2 în care unei instanţe a
entităţii E1 (numită entitate dominantă) îi pot corespunde mai multe instanţe din entitatea E2 (dar unei instanţe din E2 nu-i poate corespunde decât cel mult o
instanţă din E1).
Relaţie într-o bază de date = o legătură logică între două sau mai multe entităţi.
Gradul unei relații = numărul de entităţi care participă la relaţia respectivă
Cardinalitatea (tipul) unei relaţii binare = numărul de instanţe ale celor
două entităţi care sunt asociate prin relaţia respectivă.
54
o n - m (many-to-many): o relaţie între două entităţi E1 şi E2 în care unei instanţe a entităţii E1 îi pot corespunde mai multe instanţe din entitatea E2 şi, reciproc, unei
instanţe din entitatea E2 îi pot corespunde mai multe instanţe din entitatea E1.
În baza de date a facultăţii putem avea următoarele tipuri de relaţii:
1-1: un student are o singură foaie matricolă (în care sunt înregistrate notele sale); o foaie
matricolă aparţine unui singur student;
1-m: un student participă la mai multe cursuri opţionale; un curs pentru un student;
m-m: un profesor predă la mai mulţi ani de studiu; la un an de studiu predau mai mulţi
profesori.
3.4 Schema conceptuală şi diagrama entitate-relaţie
Aşa cum am descris anterior, primul pas în realizarea unei aplicaţii de
baze de date este analiza datelor şi realizarea unei scheme conceptuale (model
conceptual) al acestor date.
În această etapă sunt analizate natura şi modul de utilizare a datelor. Sunt identificate datele care vor trebui memorate şi procesate, se împart aceste date
în grupuri logice şi se identifică relaţiile care există între aceste grupuri.
Analiza datelor este un proces uneori dificil, care necesită mult timp, însă este o etapă absolut obligatorie. Fără o analiză atentă a datelor şi a modului de
utilizare a acestora, vom realiza o bază de date care putem constata în final că
nu întruneşte cerinţele beneficiarului. Informaţiile necesare realizării modelului
conceptual se obţin folosind metode convenţionale precum intervievarea oamenilor din cadrul organizaţiei şi studierea documentelor folosite.
Odată obţinute aceste informaţii ele trebuiesc reprezentate într-o formă
convenţională care să poată fi uşor înţeleasă de toată lumea. O astfel de reprezentare este diagrama entitate-relaţie
11, numită şi harta relaţiilor, sau
ERD-ul (Entity Relationship Diagram). Aceste scheme sunt un instrument util
care uşurează comunicarea dintre specialiştii care proiectează bazele de date şi programatori pe de o parte şi beneficiari, pe de altă parte. Aceştia din urmă pot
înţelege cu uşurinţă o astfel de schemă, chiar dacă nu sunt cunoscători în
domeniul IT.
Schema conceptuală a unei baze de date este o descriere de forma
nume_entitate={listă de atribute}.
Cheile primare sunt atribute subliniate.
11 Modelul entitate-relație a fost descries de Chen în 1976 și perfecționat ulterior.
55
Tabelul 3.2 şi Tabelul 3.3 prezintă convenţiile de reprezentare grafică (în diagramele ER)
a entităţilor, atributelor şi relaţiilor din modelul conceptual al unei baze de date relaţionale.
Observaţie.
• Entităţile şi atributele sunt denumite prin substantive; relaţiile dintre entităţi sunt
denumite prin verbe precedate sau urmate de prepoziţii; există situaţii în care ordinea
entităţilor aflate în relaţie este importantă (atunci avem, de fapt, două relaţii care trebuie
citite de la stânga la dreapta, respectiv de la dreapta la stânga) şi situaţii în care ordinea nu
este importantă.
• Numele date entităţilor, respectiv relaţiilor, trebuie să fie unice la nivelul bazei de
date. Numele atributelor trebuie să fie unice numai la nivelul aceleiaşi entităţi; eventualele
confuzii la nivelul bazei de date se rezolvă prin cuplarea numelui atributului cu numele
entităţii. Este totuşi indicat- pentru simplificarea referirilor- ca numele atributelor care
constituie cheile primare să fie unice la nivelul bazei de date.
Reprezentare grafică
Entitate principală dreptunghi simplu
Entitate dependentă dreptunghi dublu
Atribut elipsă
Atribut cu valori multiple elipsă dublă
Atribut derivat elipsă punctată
Cheie primară elipsă şi subliniere cu linie continuă
Cheie externă elipsă şi subliniere cu linie punctată
Relaţie romb
Tabelul 3.2. Un set de convenţii pentru diagrama entitate-relaţie
Reprezentare grafică
Entitate principală dreptunghi cu colţurile rotunjite
Atribut obligatoriu asterisc
Atribut opţional cerc
Cheie primară diez
Relaţie Linii cu sau fără bifurcaţii
Tabelul 3.3. Un alt set de convenţii pentru diagrama entitate-relaţie
În figura 3.1 este prezentată schema conceptuală şi diagramele entitate-relaţie (conform
convenţiilor de mai sus) pentru baza de date a unei companii cinematografice care deţine
mai multe studiouri unde se produc filme în care joacă actori.
Actori={IdActor, Nume, Prenume}; Studiouri={Nume, Adresa};
Filme={Titlu, An, Buget, Tip}
56
Figura 3.1 Diagrama entitate-relaţie
În concluzie putem sublinia câteva caracteristici ale ERD-urilor:
- sunt un instrument de proiectare ;
- sunt o reprezentare grafică a unui sistem de date ;
- oferă un model conceptual de înalt nivel al bazelor de date ;
- sprijină înţelegerea de către utilizatori a datelor şi a relaţiilor dintre acestea ;
- sunt independente de implementare.
57
3.5 Modelul relaţional: fundamentarea teoretică
3.5.1 Concepte de bază
Modelul relaţional a fost fundamentat în anul 197012
de E.F.Codd şi este
azi cel mai folosit model de baze de date în gestiunea bazelor de date. Acest
model este fundamentat pe două ramuri ale matematicii – teoria mulţimilor şi
logica predicatelor de ordinul întâi. Într-adevăr, numele modelului provine de la
termenul relaţie13
, care constituie o parte a teoriei mulţimilor.
Noţiunile fundamentale ale modelului relaţional sunt: relaţie, domeniu, atribut,
tuplu şi schemă relaţională.
Conceptul matematic aflat la baza modelului relaţional al bazelor de date este cel de
relaţie:
Fie mulţimile Marca = {Dacia, Ford, Fiat, Audi, Opel, Volvo}, Tip = {benzină,
motorină}, CapacCil = {1100, 1200, 1300, 1400, 1600}, NrLoc = {4,5}, NrUşi = {2, 4,
5}. Atunci, entitatea Automobil poate fi reprezentată ca o relaţie peste aceste mulţimi:
Automobil Marca x Tip x CapacCil x NrLoc x NrUşi
Iată câteva instanţe ale acestei entităţi:
(Dacia, benzină, 1400, 5, 4), (Dacia, motorină, 1400, 5, 4), (Dacia, benzină, 1100, 5, 4),
(Dacia, motorină, 1400, 5. 5), (Ford, motorină, 1400, 5, 5), (Ford, benzină, 1600, 5, 4),
(Fiat, benzină. 1300, 5, 4), (Fiat, benzină, 1100, 5,4), (Audi, motorină, 1600, 5, 4), (Opel,
benzină, 1400, 5, 5), (Volvo, benzină, 1400, 5, 5), (Volvo, motorină, 1600, 5, 4).
Generalizând exemplul de mai sus, obţinem:
E A1x A2 x ... x An
unde am notat cu E entitatea şi cu A1, A2,.................An mulţimile de valori
(domeniile) ale atributelor sale. Un element al acestei relaţii (adică un tuplu al
produsului cartezian) reprezintă o instanţă ei a entităţii E şi constă din valori particulare ale atributelor).
12 Ideea îi aparţine lui D.F.Childs care a publicat în 1968 o lucrare în care a arătat că orice
structură de date poate fi reprezentată sub formă de tabele în interiorul căreia trebuie să existe şi informaţie de legătură (Lungu, et al, 1995). 13 O concepţie greşită, larg răspândită, este aceea că modelul relaţional şi-ar fi preluat numele de la faptul că între tabelele unei baze de date relaţionale există relaţii.
Se numeşte relaţie peste mulţimile M1, M2, ...Mn orice submulţime a produsului lor
cartezian: R M1 x M2 x ... x Mn
58
Pentru simplitatea reprezentării, entităţile nu sunt reprezentate ca mulţimi de tupluri (ca în exemplul nostru de mai sus), ci ca tabele (tabelul 3.4), tot aşa cum în loc să notăm
cu <(3,5) instanţa relaţiei de ordine < N X N dintre naturale 3 şi 5, scriem 3 < 5.
Marca Tip CapacCil NrLoc NrUşi
Dacia benzină 1400 5 4
Dacia motorină 1400 5 4
Dacia benzină 1100 5 4
Dacia motorină 1400 5 5
Ford motorină 1400 5 5
Ford benzină 1600 5 5
Fiat benzină 1300 5 4
Fiat benzină 1100 5 4
Audi motorină 1600 5 4
Opel benzină 1400 5 5
Volvo benzină 1400 5 5
Volvo motorină 1600 5 4
Tabelul 3.4 Instanţe ale entităţii Automobil
Puterea şi eleganţa modelului relaţional sunt date de faptul că relaţiile dintre entităţi conduc la asocieri ce pot fi reprezentate tot prin tabele.
Conform modelului relaţional avem următoarele:
o Orice entitate este reprezentată printr-o tabelă; numele entităţii devine numele tabelei.
o Oricărui atribut al unei entităţi îi corespunde o coloană (numită şi
câmp) în tabela corespunzătoare entităţii; numele atributului devine
antetul coloanei respective din tabelă. o Orice instanţă a unei entităţi este reprezentată printr-un rând în tabelă
asociată entităţii, numit înregistrare; fiecare celulă din înregistrare
conţine valoarea luată de atributul corespunzător pentru instanţa respectivă.
59
3.5.2 Stabilirea relaţiilor între entităţi
La nivelul modelului conceptual, cardinalitatea relaţiilor este o
caracteristică intrinsecă a acestora; când proiectăm baza de date, relaţiile dintre entităţi trebuie definite în mod efectiv. Acest lucru se realizează în mod diferit
pentru fiecare tip de relaţie.
Fie două entităţi U şi V şi fie T1 şi T2 tabelele prin care sunt reprezentate
(conform convenţiilor din paragraful 3.4). Pentru simplitate, vom presupune că entităţile aflate în relaţie sunt identificate prin chei primare formate dintr-un
singur atribut.
Relaţii 1-1 Să presupunem că proiectăm baza de date a unei policlinici. În fiecare cabinet
lucrează un singur medic şi o singură asistentă. Este evident că (din punctul de
vedere al ocupării cabinetelor, al lucrului în echipă) cele două entităţi, Medici
şi Asistente, se află în relaţia 1-1. Pentru a stabili o relaţie (numită LucreazăCu) de 1-1 între entităţile Medici şi
Asistente vom utiliza acelaşi atribut pe post de cheie primară (aici atributul
CodCabinet).
Figura 3.2. O relaţie 1-1
Figura 3.3. Implementarea unei relaţii 1-1 în MS Access
60
Relaţii 1-m Fie două entităţi U şi V (de exemplu: Pacienţi şi Programări) având atributele
a1, (cheie primară), a2, ... , an şi respectiv b1(cheie primară), b2, ... , bm, ap (de
exemplu: codPacient, numepren, datanaşterii, adresa, telefon, nrSerieCI, CNP, respectiv nrProgramare, dataprogramare, oraprogramare, codpacient). Prin
cheie externă înţelegem un atribut al entităţii V a cărui mulţime de valori
coincide cu mulţimea valorilor cheii primare din entitatea U (aici: atributul
codPacient este cheie primară pentru entitatea Pacienţi şi cheie externă pentru entitatea Programări).
Figura 3.4. O relaţie 1-m
Figura 3.5. Implementarea unei relaţii 1-m în MS Access
Observaţii:
• În diagrama entitate-relaţie, cheile externe se reprezintă la fel ca şi cheile
primare, dar sublinierea se face punctat.
• Observăm că în timp ce, la nivelul entităţii U, valorile luate de atributul a1
sunt unice (el fiind cheie primară), la nivelul entităţii V valorile luate de
atributul a1 pot fi duplicate (el fiind cheie externă).
• Din punctul de vedere al relaţiei 1-m dintre entităţile U şi V, entitatea U
poate fi privită drept entitate principală, iar entitatea V drept entitate
secundară.
61
Pentru a stabili o relaţie (numită Areprogramare) de 1-m între entităţile Pacienţi şi Programări procedăm astfel:
1. includem în descrierea ambelor entităţi un acelaşi atribut (aici:
CodPacient); 2. definim acest atribut drept cheie primară pentru entitatea principală şi
cheie externă pentru entitatea secundară.
Relaţii n-m În acest caz, ne bazăm pe faptul că în modelul relaţional nu numai entităţile, ci
şi relaţiile dintre ele sunt relaţii în sens matematic şi, ca urmare, pot fi
reprezentate prin tabele. Să considerăm baza de date a unei facultăţi care conţine cel puţin entităţile Curs
(IdCurs, denumire) şi Student (NrMatricol, nume, prenume, grupa). Evident un
student poate să se înscrie la mai multe cursuri, iar la un curs pot participa mai
mulţi studenţi.Avem de-a face cu o relaţie n-m, numită CerereŞiOfertă.
Pentru a o relaţie n-m între două entităţi (aici CerereŞiOfertă între entităţile
Curs şi Student) procedăm astfel: 1. identificăm cheile externe - două atribute care să corespundă atributelor
care funcţionează drept chei primare pentru cele două entităţi (aici:
IdCurs şi NrMatricol); 2. definim o entitate nouă, CursStudent descrisă prin cele două atribute;
această entitate este numită si entitate intersecţie.
3. reducem astfel stabilirea unei relaţii n-m (aici: relaţia dintre Curs şi
Student) la stabilirea a două relaţii 1-m (aici: relaţiile dintre Curs şi CursStudent, şi respectiv dintre Student şi CursStudent (figurile 3.6 şi
3.7).
Figura 3.6 prezintă diagrama entitate pentru o relaţie n-m, iar figura 3.7 prezintă
implementarea acesteia în Access.
Observăm că singurele relaţii dintre entităţi care conduc la tabele
intermediare sunt relaţiile de cardinalitate n-m. Tabela
corespunzătoare trebuie să conţină cel puţin cheile externe necesare relaţionalii celor două entităţi; în acest caz, cheia primară a relaţiei
este formată din cele două atribute; altfel: se poate adăuga relaţiei un
alt atribut care va fi definit drept cheie primară a acesteia.
62
Figura 3.6. Diagrama entitate pentru o relaţie n-m
Figura 3.7. Implementarea unei relaţii de tip n-m
în Access
63
3.6 Reguli de integritate pentru bazele de date relaţionale
După modelarea bazei de date la nivel structural (definirea entităţilor,
atributelor lor şi a relaţiilor dintre ele), urmează nivelul operaţional al modelării:
♦ stabilirea tipurilor de operaţii care se pot efectua asupra datelor stocate
(sortare, căutare, vizualizare, adăugare, ştergere, modificare etc.);
♦ verificarea respectării regulilor de integritate (ceea ce va asigura
corectitudinea şi consistenţa datelor).
Distingem următoarele tipuri de reguli de integritate:
♦ reguli de integritate a entităţilor;
♦ reguli de integritate a relaţiilor (numite şi reguli de integritate
referenţială)
La acestea se adaugă şi regulile de integritate impuse de situaţia reală
modelată prin baza de date, numite restricţii procedurale.
3.6.1 Valoarea specială Null a atributelor
Pentru a analiza regulile de integritate trebuie să analizăm situaţia unei
valori speciale pe care o pot lua atributele entităţilor: valoarea Null.
Prin urmare, această valoare (artificială), care nu trebuie confundată cu valoarea 0 sau cu şirul vid de caractere, a fost incorporată modelului relaţional bazelor de
date pentru a permite tratarea excepţiilor şi a datelor incomplete.
Null= valoarea pe care o ia un atribut pentru o instanţă a unei entităţi
atunci când pentru respectiva instanţă:
nu există o valoare (de exemplu, pentru entitatea Angajaţi,
în cazul salariaţilor care nu sunt membri de sindicat, atributul
Restanţă cotizaţie nu poate lua nici o valoare, deci i se
atribuie valoarea Null.
există o valoare dar nu a fost înregistrată (de exemplu,
atributul SerieNrCI),
nu ştim dacă există sau nu o valoare (de exemplu, atributul
NrApartament).
64
3.6.2 Integritatea entităţilor
Prima regulă de integritate se aplică cheilor primare.
Dacă un atribut din structura cheii primare a entităţii primeşte valoarea
NULL este contrazisă cerinţa de minimalitate a cheii primare (ar însemna că
restul atributelor care formează cheia şi care iau numai valori din domeniile lor
de definiţie ar fi suficiente pentru a identifica în mod unic fiecare instanţă a
entităţi).
3.6.3 Integritatea referenţială
A doua regulă de integritate se aplică cheilor externe.
Exemplu Fie baza de date cu tabele Pacienţi (codPacient, numepren, datanaşterii, adresa,
telefon, nrSerieCI, CNP) şi Programări (nrProgramare, dataprogramare,
oraprogramare, codpacient) aflate în relaţie 1-m (Figura 3.8). Regula de integritate referenţială nu permite să înregistrăm datele personale ale unui
pacient şi să-l includem într-o listă de programări care „nu există" (adică să dăm
atributului său Codpacient - cheie externă pentru entitatea Programări - o
valoare pe care nu a luat-o atributul CodPacient -cheie primară pentru entitatea
Pacienţi-pentru niciuna dintre instanţele entităţii).
Oricare ar fi entitatea E din baza de date, nici un atribut care face
parte din cheia sa primară nu poate lua valoarea NULL pentru
nici o instanţă a entităţii.
Fie două entităţi U şi V relaţionate; pentru orice instanţă a entităţii V (secundară) valoarea cheii externe trebuie să
corespundă valorii cheii primare a unei instanţe oarecare a
entităţii U (principală) sau să fie NULL.
Exemplu
Observaţie: Dacă trebuie să înregistrăm datele unui pacient înainte de a înregistra datele din tabela căreia îi aparţine, putem
face acest lucru dând atributului Codpacient. al entităţii
programări valoarea NULL (lucru permis, întrucât aici atributul
Codpacient este externă, şi nu primară).
65
Figura 3.8 Stabilirea integrităţii referenţiale în Access
3.6.4 Restricţii procedurale
În etapa de analiză a situaţiei reale care trebuie modelată prin baza de date, în discuţiile dintre proiectanţii bazei de date şi viitorii ei proprietari şi
utilizatori, pot apărea informaţii suplimentare privind restricţiile pe care trebuie
să le îndeplinească datele stocate şi operaţiile efectuate asupra lor.
Restricţii procedurale = reguli suplimentare privind modul de înregistrare a datelor şi de efectuare a operaţiilor, specifice situaţiei
reale sau impuse de diferitele categorii de participanţi la proiectarea,
construirea, administrarea şi utilizarea bazei de date.
66
3.7 Implementarea modelului conceptual
Regulile ce se pot extrage studiu de caz pot fi descrise prin elemente ale
modelului conceptual: atribute, identificatori unici, relaţii între entităţi.
Trecerea de la modelul conceptual la modelul fizic se face prin
implementarea într-un SGBD (Microsoft Access în această carte) a elementelor
specifice reprezentate simbolic în Figura 3.9.
Model Conceptual Model Fizic
Entitate ------------------------------------- Tabelă
Atribut ------------------------------------- Coloană
Identificator unic ------------------------ Cheie primară
Relaţie ------------------------------------- Cheie străină (externă)
Figura 3.9. Trecerea de la modelul conceptual la modelul fizic
Un pas important în construirea bazei de date îl reprezintă crearea tabelelor a
relaţiilor dintre ele, conform regulilor de integritate.
Tabelele sunt formate din linii şi coloane. Fiecare coloană reţine date de anumit
tip şi corespunde unui atribut al entităţii; numele atributului devine antetul
coloanei.
Un rând din tabelă corespunde unui element al entităţii (instanţă) şi se
num înregistrare. Aceasta descrie complet proprietăţile unei instanţe. Dacă ne
imaginăm un tabel sub forma unei grile asemănătoare unei foi de calcul tabelar,
coloanele verticale din grilă sunt coloanele tabelului, iar rândurile orizontale
reprezintă rândurile tabelului.
Tabela = o structură utilizată pentru stocarea şi organizarea datelor.
67
O cheie primară este reprezentată de o coloană sau o combinaţie de
coloane ale căror valori sunt unice la nivelul tabelei şi sunt completate
obligatoriu. Cheile primare provin din identificatorii unici ai entităţii.
O relaţie dintre două entităţi va fi transformată într-o coloană cheie
străină.
O constrângere de integritate implementează o regulă referitoare la o
coloană sau la întregul tabel. Constrângerile de integritate pot fi stocate în baza
de date, ca parte a definiţiei tabelului.
Crearea unei tabele se realizează în două etape:
a) în prima etapă, se stabileşte structura tabelei, specificându-se numele
câmpurilor, lungimile acestora, precum şi tipul informaţiilor care vor fi
introduse în fiecare câmp;
b) în a doua etapă, se încarcă efectiv datele în tabelă.
68
3.8 Rezumatul capitolului
Modelul relaţional a fost fundamentat în anul 197014
de E.F.Codd şi este
azi cel mai folosit model de baze de date în gestiunea bazelor de date. Acest
model este fundamentat pe două ramuri ale matematicii – teoria mulţimilor şi
logica predicatelor de ordinul întâi. Noţiunile fundamentale ale modelului relaţional sunt: relaţie, domeniu,
atribut, tuplu şi schemă relaţională.
Conform modelului relaţional avem următoarele: o Orice entitate este reprezentată printr-o tabelă; numele entităţii devine
numele tabelei.
o Oricărui atribut al unei entităţi îi corespunde o coloană (numită şi câmp) în tabela corespunzătoare entităţii; numele atributului devine
antetul coloanei respective din tabelă.
o Orice instanţă a unei entităţi este reprezentată printr-un rând în tabelă
asociată entităţii, numit înregistrare; fiecare celulă din înregistrare conţine valoarea luată de atributul corespunzător pentru instanţa
respectivă.
Prin entitate înţelegem mulţimea tuturor elementelor de un anumit tip (care
prezintă aceleaşi caracteristici).
Prin instanţă a unei entităţi înţelegem un singur element, bine individualizat,
unic, din mulţimea elementelor care formează entitatea respectivă. Atributul este o caracteristică a unei entităţi.
Cheia primară este un atribut sau cea mai mică mulţime de atribute ale unei
entităţi care iau, fiecare instanţă a entităţii respective, o valoare şi numai una, sugestiv prin sensul figurat al cuvântului cheie
Relaţia într-o bază de date este o legătură logică între două sau mai multe entităţi.
La proiectarea bazei de date, relaţiile dintre entităţi trebuie definite în mod
efectiv şi pot fi de următoarele tipuri: 1-1, 1-m, n-m.
După modelarea bazei de date la nivel structural (definirea entităţilor,
atributelor lor şi a relaţiilor dintre ele), urmează nivelul operaţional al modelării:
♦ stabilirea tipurilor de operaţii care se pot efectua asupra datelor stocate
(sortare, căutare, vizualizare, adăugare, ştergere, modificare etc.);
♦ verificarea respectării regulilor de integritate (ceea ce va asigura
corectitudinea şi consistenţa datelor).
Distingem următoarele tipuri de reguli de integritate:
14 Ideea îi aparţine lui D.F.Childs care a publicat în 1968 o lucrare în care a arătat că orice
structură de date poate fi reprezentată sub formă de tabele în interiorul căreia trebuie să existe şi informaţie de legătură (Lungu, et al, 1995).
69
♦ reguli de integritate a entităţilor;
♦ reguli de integritate referenţială.
La acestea se adaugă şi regulile de integritate impuse de situaţia reală modelată
prin baza de date, numite restricţii procedurale.
Prima regulă de integritate se aplică cheilor primare (cheia sa primară nu poate lua valoarea NULL pentru nici o instanţă a entităţii).
A doua regulă de integritate se aplică cheilor externe (pentru orice
instanţă a entităţii secundare, valoarea cheii externe trebuie să corespundă
valorii cheii primare a unei instanţe oarecare a entităţii principale sau să fie
NULL.
70
3.9 Întrebări de auto-evaluare
I) Entităţi disjuncte; entităţi dependente.
a) Fie baza de date a unei facultăţi şi entităţile Persoane, CadreDidactice,
Studenţi, PersonalAdministrativ. Identificaţi entităţile disjuncte. În ce
situaţie se află entităţile Persoane, CadreDidactice şi
PersonalAdministrativ?
b) Fie baza de date a unui club dotat cu săli de gimnastică, saloane de
cosmetică, solare şi saună. Identificaţi entităţile disjuncte, subentităţile,
precum şi entităţile principale şi cele dependente.
II) Entităţi, atribute şi chei primare
a) Daţi exemple de instanţe ale entităţii Studenţi.
b) Daţi exemple de valori ale atributului Viteză al entităţii Microprocesor.
c) Descrieţi atributele următoarelor entităţi şi identificaţi un atribut/grup de
atribute cu proprietatea de identificator unic: (i) persoană; (ii) abonat
telefonic; (iii) automobil; (iv) calculator.
III) Exemple de relaţii: grad şi cardinalităţi
Daţi exemple de relaţii binare din baza de date a unui club sportiv.
Daţi exemple de relaţii 1-1, 1-m şi n-m din baza de date a unui spital.
Citiţi întrebările de mai jos şi alegeţi varianta corectă de răspuns:
IV) Modelul conceptual
1.Elementele de bază ale modelului conceptual sunt:
a) entităţile şi atributele;
b) instanţele şi relaţiile;
c) cheile primare şi cheile candidat;
d) entităţile, atributele şi relaţiile.
2.Entităţile principale sunt entităţi care:
a) admit subentităţi;
b) admit entităţi dependente;
c) constau dintr-o singură instanţă.
3. După gradul de complexitate, atributele pot fi:
a) atribute de bază şi atribute derivate:
b) atribute elementare şi atribute compuse;
c) atribute cu valori unice şi atribute cu valori multiple.
4.O entitate poate avea:
a) cel puţin două chei primare;
b) oricâte chei primare, dar o singură cheie candidat;
c) oricâte chei candidat, dar o singură cheie primară.
71
5.Modelul conceptual al unei baze de date poate fi reprezentat:
a) printr-o schemă logică;
b) printr-o diagramă relaţionată;
c) printr-o schemă conceptuală sau printr-o diagramă entitate-relaţie.
V) Reguli de integritate
1.Principalele reguli de integritate pentru bazele de date se referă la:
a) entităţi şi relaţii;
b) entităţi şi atribute;
c) entităţi şi chei primare;
d) atribute şi relaţii.
2. Regula de integritate a entităţilor interzice unui atribut care face parte din
cheia primară a unei entităţi:
a) să ia valoarea 0;
b) să ia valoarea 1;
c) să ia valoarea NULL;
d) să ia oricare dintre valorile 0, 1 sau NULL.
3. Integritatea referenţială se referă la valorile luate de:
a) fiecare dintre cheile candidat ale entităţii principale;
b) fiecare dintre cheile candidat ale entităţii dependente;
c) cheia primară;
d) cheia externă.
72
73
CAPITOLUL 4
NORMALIZAREA BAZELOR DE DATE
4.1. Introducere
Normalizarea bazelor de date este o tehnică de proiectare a bazelor de date
relaţionale. Scopul acesteia este de a elimina redundanţele şi anomaliile la
adăugare, ştergere şi modificare. Crearea mai multor relaţii poate încetini timpul
de acces la date. În cadrul acestui capitol sunt prezentate toate tipurile de
dependenţe funcţionale care stau la baza creării formelor normale, cu exemple.
Modul în care se pot stabili relaţiile unei baze de date nu este unic, eficienţa
variantei aleasă fiind dată de raportul dintre accesibilitatea datelor şi eliminarea
anomaliilor.
4.2 Organizarea datelor
Dacă datele sunt simple, ele pot fi organizate într-un tabel simplu. O bază de
date simplă poate fi întreţinută chiar şi cu ajutorul unui procesor de texte sau a
unei aplicaţii cu foi de calcul tabelar. Pentru a lucra cu un tabel simplu nu sunt
necesare cunoştinţe despre teoria bazelor de date. De exemplu o listă de
contacte – Figura 1. Fiecare coloană de date (nume, adresă, număr de telefon)
este logic legată de celelalte.
Fig. 1. Tabela non-relaţională Contacte (în Microsoft Excel)
Bazele de date din viaţa reală conţin adeseori sute de mii sau chiar milioane de
înregistrări, datele fiind legate instrinsec între ele.
Definiţie: Relaţia redă informaţiile despre un obiect reprezentat (o entitate
concretă sau abstractă). Schema relaţiei este expresia proprietăţilor comune şi
74
invariante ale liniilor care compun relaţia şi este relativ constantă în timp.
Atributul este o caracteristică a obiectului reprezentat într-o relaţie.15
Un exemplu de relaţie este prezentat în figura 1. Exemple de atribute: ID, Nume
Contact, Adresa Contact şi Nr_tel Contact.
Utilizarea unei singure relaţii pentru a menţine o bază de date conduce la
repetări inutile ale datelor, adică redundanţă16
.
Fig 2. Relaţie simplă în Microsoft Access
După cum se poate vedea din figura 2, redundanţa excesivă poate determina un
proiectant de baze de date să evite folosirea unei singure relaţii. În afara
redundanţei, mai există trei probleme importante legate de acest tip de
organizare:
Anomalia la modificare: pentru a modifica adresa furnizorului Pop Ion
este necesară modificarea fiecărui rând care conţine acea adresă. Dacă o
înregistrare nu este modificată, apare anomalia la modificare, rezultând
o relaţie care conţine inexactităţi.
Anomalia la inserare: dacă se doreşte adăugarea unui nou furnizor, dar
nu există nici o factură a acestuia sau nici un detaliu despre produsele
facturate, se poate adăuga un rând nou, iar în câmpurile în care
informaţiile nu sunt disponibile se va plasa valoarea NULL (o valoare
15
Hurbean L., Dănăiață D., Negovan A.-M. – Baze de date: de la teorie la practică utilizând
Access 2007, Editura Mirton, Timişoara, 2008, p.84 16 Giulvezan C., Mircea G., Târnăveanu D. – Baze de date: Teorie şi practică. Access, VBA şi
SQL, Editura Universității de Vest, Timişoara, 2009, p. 15
Redundanţa reprezintă o proprietate a unei colecţii de date care se referă la
faptul că unele componente sunt memorate de mai multe ori pe suportul de
memorare.
75
care indică o valoarea necunoscută sau care lipseşte). Aceasta cauzează
aşa-numita anomalie la inserare.
Anomalia la ştergere: În contradicţie cu problema precedentă, dacă se
doreşte ştergerea tuturor apariţiilor furnizorului Pop Ion, automat vor fi
şterse toate informaţiile legate de produsele livrate şi facturile pe care
acesta apare. Aceasta constituie anomalia la ştergere.
Această listă de probleme potenţiale oferă suficiente argumente în favoarea
utilizării mai multor relaţii.
4.3 Dependenţe
În procesul de normalizare a bazei de date este necesar să se ţină seama de
anumite reguli (dependenţe, forme normale) care permit eliminarea anomaliilor
prezentate în paragraful anterior.
Dependenţele de date reprezintă constrângeri care se impun valorilor
atributelor unei relaţii şi care determină proprietăţile relaţiei în raport cu
operaţiile care pot genera anomalii (inserare, ştergere, actualizare).
4.3.1 Dependenţe funcţionale simple
Dependenţele sunt structuri logice ce se stabilesc între atributele modelului
relaţional. Acestea nu se determină inspectând conţinutului relaţiei la un
moment dat, ci studiind semnificaţia atributelor acesteia.
Definiţie: Între două atribute A şi B există o dependenţă funcţională17
dacă fiecărei valori a lui A îi corespunde o singură valoarea a lui B
(simbolizată A→B). A poartă numele de determinant iar B poartă numele
de determinatul dependenţei.
De exemplu, în cazul studenţilor, unei valori a numărului matricol îi corespunde
un singur nume şi prenume, deci între nrmatr şi numeprenstudent există o
dependenţă funcţională:
17 Tamaş I. (coord.), Stanciu V., Gheorghe M. – Access 2007 – Proiectare şi realizare pas cu pas,
Editura Infomega, Bucureşti, 2010, p.23
nrmatr→numeprenstudent
76
unde nrmatr este determinantul, iar numeprenstudent este determinatul.
Observaţie: Dacă A → B, atunci la două linii cu aceeaşi valoare pentru
atributul A le corespund aceeaşi valoare a atributului B18
.
Alte exemple:
unde nr_f este numărul facturii, cod_furn este codul furnizorului, iar cod_p este
codul de bare al produsului, unit_masura fiind unitatea de măsură a produsului.
Definiţie: O dependenţă funcţională în care determinatul este alcătuit dintr-
un singur atribut se numeşte dependenţă funcţională canonică19
.
Exemple de dependenţe funcţionale canonice:
unde den_p este denumirea produsului, nr_document este seria şi numărul
documentului de plată.
Definiţie: O dependenţă funcţională este trivială dacă şi numai dacă
determinatul este un subset al determinantului: dacă BA atunci A→B.
Exemple de dependenţe funcţionale triviale:
Definiţie: Dependenţele funcţionale compuse20
prezintă ca determinant
două sau mai multe atribute, care se scriu între paranteze.
18 Hurbean L., Dănăiață D., Negovan A.-M. – Baze de date: de la teorie la practică utilizând
Access 2007, Editura Mirton, Timişoara, 2008, p.55 19 Florescu V. (coord.), Ionescu B. (coord.), Cozgarea G., et al – Baze de date, Editura Infomega,
Bucureşti, 2009, p.41 20 Hurbean L., Dănăiață D., Negovan A.-M. – Baze de date: de la teorie la practică utilizând
Access 2007, Editura Mirton, Timişoara, 2008, p.56
nr_f → cod_furn
cod_p → unit_masura
cod_p → den_p
nr_document → data document
(cod_p, nr_f) → cod_p
(nr_document, tip_document) → nr_document
Observaţie: Între câmpul de tip cheie primară al unei relaţii şi celelalte
câmpuri ale relaţiei există dependenţe funcţionale.
77
Exemple de dependenţe funcţionale compuse:
unde un număr de factură şi un cod produs (cu presupunerea că pe o factură
codul produsului apare o singură dată) determină un unic preţ unitar.
Definiţie: Se numeşte dependenţă funcţională completă21
, o dependenţă
funcţională de forma A→B unde B este dependent funcţional de A, fără să
fie dependent de nici una din componentele lui A.
Între grupul de câmpuri (nr_matr, cod_disciplina) şi nota există o dependenţă
funcţională completă, deoarece:
Pentru un student, numărul matricol şi codul disciplinei determină în mod unic
nota, dar pentru un număr matricol există mai multe note (la discipline diferite),
iar unui cod de disciplină îi corespund mai multe note (ale mai multor studenţi).
Definiţie: O dependenţă A→B se numeşte dependenţă funcţională
parţială22
dacă şi numai dacă B este dependent funcţional atât de A, cât şi
de o componentă a lui B.
De exemplu, între grupul de câmpuri (nr_document,tip_document) şi suma
există o dependenţă funcţională parţială, deoarece:
unde nr_document semnifică seria şi numărul de pe documentul de plată
(valoare unică), suma seminifică suma de plată iar tip_document are una din
valorile: chitanţă, ordin de plată, etc. Pentru un număr de document suma de
plată este unică. Dar pentru fiecare tip de document suma de plată poate fi
diferită (de exemplu, nu toate chitanţele au aceeaşi sumă de plată).
21 Florescu V. (coord.), Ionescu B. (coord.), Cozgarea G., et al – Baze de date, Editura Infomega,
Bucureşti, 2009, p.41 22 Florescu V. (coord.), Ionescu B. (coord.), Cozgarea G., et al – Baze de date, Editura Infomega,
Bucureşti, 2009, p.41
(nr_matricol, cod_disciplina) → nota
nr_matricol → nota
cod_disciplina → nota
(nr_document, tip_document) → suma nr_document → suma
tip_document → suma
(nr_f, cod_p) → pret_unitar
78
4.3.2 Dependenţe funcţionale directe şi tranzitive
Definiţie: O dependenţă funcţională tranzitivă este acea dependenţă
A→B care se poate descompune în A→C→B.
Exemplu de dependenţă funcţională tranzitivă:
Fiecare bancă are mai multe agenţii, fiecare agenţie are propria adresă.
Definiţie: O dependenţă funcţională directă este acea dependenţă A→B
pentru care nu există dependenţe tranzitive A→C→B.
Exemplu de dependenţă directă:
4.3.3 Dependenţe funcţionale multiple
Definiţie: Între două atribute A şi B există o dependenţă funcţională
multiplă, notată A B, dacă şi numai dacă unei valori a atributului A îi
corespund două sau mai multe valori ale atributului B23
.
4.3.4 Dependenţe multivaloare
Definiţie: Tuplul reprezintă o linie distinctă de valori din cadrul unei
relaţii24
.
23 Tamaş I. (coord.), Stanciu V., Gheorghe M. – Access 2007 – Proiectare şi realizare pas cu pas,
Editura Infomega, Bucureşti, 2010, p.24 24 Hurbean L., Dănăiață D., Negovan A.-M. – Baze de date: de la teorie la practică utilizând
Access 2007, Editura Mirton, Timişoara, 2008, p.84
cod_banca → adresa
cod_banca → cod_agenţie
cod_agenţie → adresa
cod_banca → denumire_banca
cod_banca → cod_agenţie
nr_f → cantitate
79
Definiţie: Se consideră relaţia R(A,B,C), unde A, B şi C sunt atribute ale
acesteia (simple sau compuse). Fie ai,bi şi ci valorile atributelor A, B şi C.
Spunem că există o dependenţă funcţională multivaloare a atributului C
faţă de B, notată B C dacă pentru orice valori a1, a2, b, c1, c2 şi a1≠a2 şi
c1≠c2, astfel încât tuplurile (a1,b,c1) şi (a2,b,c2) fac parte din relaţia R, atunci
şi tuplurile (a1,b,c2) şi (a2,b,c1) fac parte din relaţia R.
Ca exemplu de dependenţă multivaloare putem considera:
unde cod_depozit este codul depozitului, cod_magazie este codul magaziei şi
cod_p este codul produsului. Este esenţială presupunerea că magaziile se
aprovizionează de la acelaşi depozit şi comercializează toate produsele
cumpărate de la depozitul respectiv.
Din relaţia R se pot extrage următoarele dependenţe multivaloare:
Există dependenţă multivaloare a atributului cod_p faţă de cod_magazie dacă
pentru orice valori de tipul:
cod_depozit cod_magazie cod_p
111 49 1234
111 51 1235
atunci următoarele valori aparţin relaţiei:
cod_depozit cod_magazie cod_p
111 49 1235
111 51 1234
Toate magazinele aprovizionându-se din acelaşi depozit, şi comercializând
aceleaşi produse, dacă magazinul 49 comercializează produsul 1234 şi
magazinul 51 comercializează produsul 1235 atunci putem fi siguri că şi
magazinul 49 comercializează produsul 1235 şi magazinul 51 comercializează
produsul 1234.
Dependenţele funcţionale sunt un caz particular al dependeţei multivaloare.
R(cod_depozit, cod_magazie, cod_p)
cod_depozit cod_magazie
cod_depozit cod_p
80
4.3.5 Dependenţe joncţiune
O relaţie R{X, Y, Z} este joncţiunea proiecţiilor sale XY, XZ şi YZ dacă
(x1,y1)XY, (y1,z1)YZ, atunci (x1, y1, z1)XYZ. Dacă în R{X, Y, Z} există
trei tupluri (x1, y1, z2), (x2, y1, z1) şi (x1, y2, z1) atunci obligatoriu apare şi tuplul
(x1, y1, z1) (condiţia de joncţiune).
Fie relaţia R(A1, A2, ... An) şi X1, X2,..., Xm, m subansambluri de atribute din R.
Definiţie: Se spune că există o dependenţă joncţiune25
de ordinul m între
X1, X2,..., Xm, notată * X1│X2│...│Xm sau *{X1, X2,..., Xm} dacă şi numai
dacă R reprezintă joncţiunea proiecţiilor sale pe X1, X2,..., Xm, deci
R=R(X1)* R(X2)*...* R(Xm).
Considerând relaţia R(cod_prof, nr_matr, cod_facultate) unde cod_prof este
codul profesorului universitar, nr_matr este numărul matricol al studentului, iar
cod_disc este codul disciplinei. Dacă profesorul 111 predă studentului 1234,
profesorul 111 predă disciplina cu codul 13 şi studentul 1234 studiază disciplina
cu codul 13, atunci profesorul 111 intră în relaţie cu studentul 1234 prin
intermediul disciplinei cu codul 13.
Se presupune că relaţia R conţine următoarele înregistrări:
cod_prof nr_matr cod_disc
111 1234 13
112 1234 12
111 1235 12
atunci există şi
cod_prof nr_matr cod_disc
111 1234 12
iar proiecţiile relaţiei R sunt:
cod_prof nr_matr nr_matr cod_disc cod_prof cod_disc
cod_prof nr_matr nr_matr cod_disc cod_prof cod_disc
111 1234 1234 13 111 13
112 1234 1234 12 111 12
111 1235 1235 12 112 12
Dependenţa multivaloare este un caz particular al dependenţei joncţiune.
25 Florescu V. (coord.), Ionescu B. (coord.), Cozgarea G., et al – Baze de date, Editura Infomega,
Bucureşti, 2009, p.44
81
4.3.6 Matricea dependenţelor funcţionale
Pentru obţinerea modelului relaţional se parcurg următorii paşi26
:
1. Construirea dicţionarului de atribute (DA) – atributele se vor prelua
din documente primare, rapoarte, indicatori, etc şi se vor adăuga în DA.
Reguli de formare a dicţionarului de atribute:
fiecare atribut este scris o singură dată;
se vor elimina atributele calculate şi atributele sinonime.
2. Stabilirea cheilor primare – se vor alege cheile primare dintre
atributele candidate (cele care au valori unice).
3. Specificarea dependenţelor – se vor identifica tipurile de dependenţe
care există între fiecare cheie primară şi restul atributelor din DA.
4. Determinarea atributelor izolate – se vor căuta determinanţii
acestora. Se selectează mai întâi grupurile de chei primare, apoi
grupurile de atribute non-cheie, iar în final, dacă este cazul, se vor
adăuga chei surogat.
5. Formarea relaţiilor. Se va ţine cont de următoarele reguli:
a. Fiecare determinant împreună cu atributele determinate, vor
forma câte un tabel.
b. Dacă între două chei primare există o dependenţă multiplă
reciprocă, atunci această dependenţă va genera un tabel. Cheia
primară a acestei relaţii va fi formată din cele două atribute,
care, individual vor avea şi rol de chei externe.
Exemplu:
Se doreşte informatizarea unei părţi din activitatea unei firme. Furnizorii sunt
identificaţi prin cod furnizor, denumire furnizor (numele şi prenumele
furnizorului), localitatea, adresa, email, banca furnizor şi cont furnizor. Despre
produse se cunosc cod produs, denumire produs, unitate de măsură, stoc, preţ
unitar. Produsele sunt depozitate în magazii, pentru care se cunosc cod
magazie, denumire magazie, gestionar (numele persoanei care are în gestiune
depozitul respectiv). Operaţiunile se desfăşoară pe baza unor facturi, care
trebuie să conţină numărul facturii şi data facturii. Fiecare factură conţine
detaliate liniile facturii şi anume denumirea produsului, preţul unitar, cantitatea
facturată, calculându-se valoarea produsului (cu şi fără TVA) şi valoarea totală
a facturii (cu şi fără TVA).
26 Florescu V. (coord.), Ionescu B. (coord.), Cozgarea G., et al – Baze de date, Editura Infomega,
Bucureşti, 2009, p.44, p.57
82
Rezolvare:
1. Inventarierea atributelor
Pe baza analizei rezultă următoarele atribute: cod_f (cod furnizor), den_f
(denumire furnizor), localit (localitatea furnizorului), adresa, email, banca, cont,
nr_f (numărul facturii), data_f (data facturii), nr_crt (numărul curent asociat
fiecărui produs de pe factură), cod_p (codul produsului), cantit (cantitatea
facturată), val_f_TVA (valoarea produsului fără TVA), val_c_TVA (valoarea
produsului cu TVA), val_totala_f_TVA (valoarea totală a facturii fără TVA),
val_totala_c_TVA (valoarea totală a facturii cu TVA), TVA (TVA-ul din
valoarea produsului), cotaTVA (valoarea cotei TVA), den_p (denumirea
produsului), um (unitatea de măsură a produsului), stoc (stocul din produsul
respectiv), pret_u (preţul unitar facturat al produsului), cod_m (codul magaziei
în care este depozitat), den_m (denumirea magaziei) şi gestionar (numele
gestionarului).
2. Specificarea regulilor de gestiune
o factură este emisă de un singur furnizor, un furnizor poate să apară pe
mai multe facturi;
o factură poate conţine mai multe produse, iar un produs poate să apară
pe mai multe facturi;
un produs poate fi depozitat în mai multe magazii, iar o magazie poate
depozita mai multe produse.
Algoritmi de calcul
Val_f_tva = cantit*pret_u
TVA=cantit*pret_u*cotaTVA
Val_c_TVA=Val_f_TVA+TVA
Val_totala_f_TVA=
Val_totala_c_TVA=
3. Întocmirea dicţionarului de atribute
Dicţionarul de atribute DA: cod_f, den_f, localit, adresa, email, banca, cont,
nr_f, data_f, nr_crt, cod_p, cantit, cotaTVA, den_p, um, stoc, pret_u, cod_m,
den_m şi gestionar.
4. Stabilirea cheilor primare: cod_f, cod_p, cod_m, nr_f.
5. Stabilirea dependeţelor funcţionale
Graful dependenţelor funcţionale simple
83
Graful dependenţelor funcţionale multiple
cod_f nr_f
cod_m cod_p cod_p cod_m
nr_f cod_p cod_p nr_f
6. Atribute izolate: cantit, cotaTVA şi preţ_u sunt determinate de un grup
de atribute după cum urmează:
7. Formarea tabelelor: Fiecare cheie primară şi atributele determinate
direct şi intranzitiv vor forma un tabel.
8. Identificarea cheilor externe: atributele subliniate prin linie
discontinuă la nivelul modelului relaţional.
Fig. 3 – Graful dependenţelor funcţionale multiple
unde semnifică reprezentarea grafică a unei chei compuse.
84
9. Matricea dependenţelor funcţionale
unde 1 = dependenţe funcţionale simple
1T= dependenţe funcţionale simple tranzitive
# = chei primare
10. Definitivarea modelului relaţional:
Furnizori(cod_f, den_f, localit, adresa, email, banca, cont)
Facturi(nr_f, data_f, cod_f)
Produse(cod_p, den_p, um)
ProduseFacturate(nr_f, nr_crt, cod_p, cantit, pret_u, cotaTVA )
Magazii(cod_m, den_m, gestionar)
ProduseMagazii(cod_p, cod_m, stoc)
Prin linie continuă se simbolizează cheile primare, iar prin linie întreruptă,
cheile străine.
11. Implementarea în Access
Fig. 4. Fereastra Relationship din Access
85
4.4 Forme normale
O formă normală a unei relaţii implică anumite condiţii pe care trebuie să le
îndeplinească valorile atributelor şi dependenţelor de date definite pe acea
relaţie27
.
E.F. Codd a prezentat în 1972 o tehnică pentru proiectarea bazelor de date
relaţionale pe care a numit-o normalizare28
. Acesta a propus trei forme
normale, numite prima formă normală (FN1), a doua formă normală (FN2) şi a
treia formă normală (FN3). Ulterior, a mai fost introdusă o formă normală care
completa FN3, aceasta fiind numită Boyce-Codd (FNBC). Acestor forme
normale le corespund dependenţe funcţionale între atributele unei relaţii.
Formele normale superioare cum ar fi (FN4) şi (FN5) impun condiţii
dependeţelor multivaloare, respectiv de joncţiune între atributele unei relaţii şi
sunt atribuite cercetătorului Fagin.
4.4.1 Forma normală 1
O relaţie se află în forma normală 1 (FN1) dacă toate atributele sale sunt
atomice (nu se mai pot descompune) şi nerepetitive.
Pentru aducerea relaţiilor în FN1 se parcurg următorii paşi:
atributele compuse sunt înlocuite cu atribute complete;
pentru grupurile de atribute repetitive, se formează o altă relaţie;
cheia primară a noii relaţii va fi compusă din cheia primară a primei
relaţii şi din atributele adiţionale din noua relaţie. Cheia primară a noii
relaţii va fi cheie externă.
O relaţie nu este în FN1 dacă are câmpuri care conţin valori care pot fi
descompuse în mai multe câmpuri (cum ar fi adresa) sau valori redundante –
figura 5.
27 Ionescu F. – Baze de date relaționale şi aplicații, Editura Tehnică, Bucureşti, 2004, p.187 28 Hurbean L., Dănăiață D., Negovan A.-M. – Baze de date: de la teorie la practică utilizând
Access 2007, Editura Mirton, Timişoara, 2008, p.60
86
De exemplu:
Fig. 5 – Relaţia Factura – nu respectă FN1
Fig. 6 – Relaţiile Furnizori, Facturi, LiniiFacturi şi Produse – respectă FN1
4.4.2 Forma normală 2
O relaţie se află în forma normală 2 (FN2) dacă respectă FN1 şi orice atribut
non-cheie este complet dependent de cheia primară a relaţiei. FN2 interzice
existenţa dependenţelor funcţionale parţiale între atributele cu rol de cheie
primară şi celelalte atribute.
Pentru aducerea relaţiilor din FN1 în FN2 se parcurg următorii paşi:
se identifică dependenţele funcţionale parţiale;
acestea vor genera o nouă relaţie, având ca structură atributele
participante în dependenţa funcţională parţială;
atributele determinante devin chei externe în relaţiile iniţiale şi chei
primare în relaţiile nou create.
87
Fig. 6 – Relaţia FacturiProduse – nu respectă FN2
Relaţia FacturiProduse nu se află în forma normală 2 deoarece:
(Nrfact, Nrprod) → DenProd
Nrprod → DenProd
Relaţia FacturiProduse prezintă următoarele anomalii:
redundanţă pentru câmpul DenProd (care depinde parţial de cheia
primară) – figura 6;
anomalii la adăugare: nu se pot adăuga produse dacă nu există o
factură pentru acestea;
anomalii la ştergere: ştergerea unei facturi poate duce la ştergerea
definitivă a unor produse;
anomalii la modificare: dacă se modifică denumirea unui produs,
atunci trebuie modificate toate înregistrările care conţin denumirea
produsului respectiv.
Fig. 7 – Relaţiile LiniiFacturi şi Produse – respectă FN2
88
4.4.3 Forma normală 3
O relaţie este în forma normală 3 (FN3) dacă respectă FN2 şi toate atributele
non-cheie sunt dependente direct de cheia primară. Altfel spus, FN3 interzice
dependenţele tranzitive.
O relaţie care nu respectă FN3 prezintă anomalii la ştergere, inserare şi
modificare, precum şi redundanţe pentru atributele determinate funcţional
tranzitiv.
Pentru aducerea unei relaţii FN2 în FN3, se parcurg următorii paşi:
se identifică dependenţele funcţionale tranzitive;
determinantul non-cheie împreună cu atributul sau atributele
determinate funcţional de către acestea, vor forma o nouă relaţie;
determinantul non-cheie devine cheie primară în relaţia nou formată şi
cheie externă în relaţia iniţială.
Fig. 8 – Relaţia FacturiFurnizori – nu respectă FN3
Relaţia FacturiFurnizori nu se află în forma normală 3 deoarece există o
dependenţă funcţională tranzitivă:
Nrfact → Nrfurn → Numefurn
Relaţia FacturiFurnizori prezintă următoarele anomalii:
redundanţă pentru câmpul Numefurn (determinat funcţional tranzitiv
din Nrfurn) – figura 8;
anomalii la adăugare: nu se pot adăuga furnizori dacă nu există o
factură a acestora;
anomalii la ştergere: ştergerea unei facturi poate duce la ştergerea
definitivă a furnizorului;
anomalii la modificare: dacă se modifică denumirea unui furnizor,
atunci trebuie modificate toate înregistrările care conţin denumirea
furnizorului respectiv.
Majoritatea specialiştilor sunt de acord că o bază de date aflată în FN3 asigură
un raport satisfăcător între rezolvarea redundanţelor şi a anomaliilor pe de o
parte şi viteza de lucru şi accesibilitatea datelor, de pe altă parte.
89
4.5 Concluzii
Normalizarea presupune efectuarea de verificări asupra datelor dintr-o relaţie
pentru a determina dacă aceasta satisface regulile formelor normale. Formele
normale se bazează pe dependenţele funcţionale ce se pot stabili între atributele
unei relaţii.
Obiectivele normalizării sunt: minimizarea redundanţei, eliminarea anomaliilor,
facilitarea interogărilor bazei de date şi diminuarea nevoii de modificare
periodică a structurii bazei de date.29
O bază de date riguros normalizată nu este neapărat şi o bază de dată optimă –
datorită vitezei de lucru, a accesibilităţii datelor – de aceea în unele cazuri se
introduc selectiv date redundante pentru a creşte performanţa sistemului. Acest
proces poartă numele de denormalizare.
4.6 Rezumatul capitolului
Obiectivul central al normalizării îl constituie conceperea bazelor de date. O
bază de date normalizată trebuie să conţină relaţii în care să nu existe
redundanţe şi anomalii. Eliminarea acestor anomalii se poate realiza prin
descompunerea relaţiei în mai multe tabele. Modul în care se pot stabili relaţiile
unei baze de date nu este unic, de aceea este necesar să existe criterii de
evaluare a calităţii relaţiilor. Pe baza dependenţelor de date se pot stabili reguli
de definire a relaţiilor, astfel încât acestea să prezinte anumite proprietăţi care
caracterizează formele normale ale relaţiilor.
29 Hurbean L., Dănăiață D., Negovan A.-M. – Baze de date: de la teorie la practică utilizând
Access 2007, Editura Mirton, Timişoara, 2008, p.85
90
4.7 Întrebări de autoevaluare din partea teoretică
1. Să se definească conceptul de normalizare. Să se detalieze obiectivele
normalizării.
2. Să se definească conceptul de redundanţă. Să se susţină cu argumente
necesitatea redundanţelor necesare.
3. Să se exemplifice dependenţele funcţionale, directe şi tranzitive.
4. Să se exemplifice dependenţele complete şi parţiale.
5. Să se formuleze un enunţ de bază de date care să conţină mai multe
tabele şi să se detalieze schema bazei de date pe baza matricii
dependenţelor funcţionale.
6. Să se exemplifice o relaţie care nu este în FN1 şi să se detalieze
rezolvarea problemei.
7. Să se exemplifice o relaţie care nu este în FN2 şi să se detalieze
rezolvarea problemei.
8. Să se exemplifice o relaţie care nu este în FN3 şi să se detalieze
rezolvarea problemei.
91
4.8 Exemple
4.8.1 Problemă rezolvată – Filiala CEC
Se cere informatizarea activităţii la o filială CEC. Clienţii filialei sunt
identificaţi prin nume şi prenume, cnp, seria şi numărul de buletin, data
eliberării buletinului şi adresă. Fiecare client poate să deţină unul sau mai multe
cecuri. Pentru fiecare cec se cunoaşte: seria, numărul, data la care a fost eliberat,
suma depusă în momentul eliberării şi tipul cecului (poate fi la termen sau la
vedere). De asemenea, fiecare cec poate să aibă unul sau mai mulţi titulari.
Fiecare client poate efectua depuneri şi restituiri. Depunerile se efectuează prin
intermediul unei foi de depunere (FD) caracterizată prin: număr, dată şi suma
depusă. Restituirile se efectuează prin intermediul foilor de restituire (FR)
caracterizate prin: număr, data şi suma restituită. Fiecare cec se poate lichida de
către unul din titulari prin intermediul unei foi de lichidare (FL) caracterizată
prin: număr, data şi suma din momentul lichidării. Dobânda acordată pentru
cecuri se modifică de la o zi la alta şi este diferită pentru cecurile la termen faţă
de cele la vedere.
Rezolvare
1. Inventarierea atributelor
Pe baza analizei rezultă următoarele atribute: codcl, numepren, cnp, serieci,
nrci, dataelibci, adresa, serie_nrcec, dataelibcec, titularcec, codtipcec, tipcec,
termen, coddep, datadep, sumadep, codrest, datarest, sumarest, codlich,
datalich, sumalich, datadob, dobanda.
2. Specificarea regulilor de gestiune
un client poate avea mai multe cecuri, un cec poate avea mai mulţi
titulari (clienţi);
pe un cec se pot face mai multe depuneri;
pe un cec se pot face mai multe restituiri;
un cec poate fi lichidat doar o singură dată;
mai multe cecuri sunt de acelaşi tip.
3. Întocmirea dicţionarului de atribute
Dicţionarul de atribute DA – eliminăm atributul titularcec (este echivalent cu
client) şi unim atributele seriecec şi nrcec într-un singur câmp, rezultând: codcl,
numepren, cnp, serieci, nrci, dataelibci, adresa, serie_nrcec, dataelibcec, tipcec,
92
termen, coddep, datadep, sumadep, codrest, datarest, sumarest, codlich,
datalich, sumalich, datadob, dobanda.
4. Stabilirea cheilor primare: codcl, serie_nrcec, codtipcec, coddep,
codrest, codlich, codtipcec+datadob.
5. Stabilirea dependeţelor funcţionale
Graful dependenţelor funcţionale simple
Graful dependenţelor funcţionale multiple
codcl serie_nrcec serie_nrcec codcl
serie_nrcec coddep
serie_nrcec codrest
codtip serie_nrcec
Atribute izolate: pentru un tip de cec, într-o anumită dată, se
calculează o dobândă.
6. Formarea tabelelor: Fiecare cheie primară şi atributele determinate
direct şi intranzitiv vor forma un tabel.
7. Identificarea cheilor externe: atributele subliniate prin linie
discontinuă la nivelul modelului relaţional.
codtip dobanda
datadob
93
8. Graful dependenţelor funcţionale
Matricea dependenţelor funcţionale
unde 1 = dependenţe funcţionale simple
1T= dependenţe funcţionale simple tranzitive
# = chei primare
94
9. Definitivarea modelului relaţional:
Clienti (codcl, numepren, cnp, serieci, nrci, dataelibcl, adresa)
TipuriCecuri (codtip, tipcec, termen)
Cecuri (serie_nrcec, dataelibcec, codtip)
CecuriClienti (codcl, serie_nrcec)
Depuneri (coddep, datadep, sumadep, serie_nrcec)
Restituiri (codrest, datarest, sumarest, serie_nrcec)
Lichidari (codlich, datalich, sumalich, serie_nrcec)
Dobanzi (codtip, datadob, dobanda)
10. Implementarea în Access
Fig. 9 – Fereastra Relationships
4.8.2 Probleme propuse
4.8.2.1 Agenţie de turism30
O agenţie de turism doreşte să-şi informatizeze activitatea de gestionare a
contractelor încheiate pentru pachetele de servicii pe care le oferă. Turiştii sunt
persoane fizice care se identifică printr-un cod unic, nume prenume, CNP, serie
şi număr CI, data naşterii, telefon, număr paşaport. Agenţia oferă mai multe
categorii de servicii (excursii, cazare, bilete de avion); fiecare categorie de
servicii include tipuri de servicii (excursii – circuit sau sejur, cazare – all
inclusive sau demipensiune, bilete de avion – dus, întors, dus-întors) pentru
30 Stanciu A. (coord.), Mihai F, Mangiuc D, et al – Baze de date Access 2007: studii de caz,
Editura Infomega Bucureşti, 2009, p. 28
95
care se memorează un cod unic şi denumirea serviciului. Indiferent de
denumirea serviciului, se impune specificarea ţării destinaţie – identificată prin
cod şi denumire; pentru ţara de destinaţie se precizează localitatea destinaţie,
pentru care se reţine codul şi numele.
Pentru ca să fie cât mai atractivă, agenţia oferă anumite reduceri în funcţie de
vâsrta turiştilor, astfel pentru turiştii cu vârsta mai mică sau egală cu 12 ani, se
acordă o reducere de 40% din tariful standard aferent fiecărui serviciu, iar copii
care nu au împlinit încă 12 ani beneficiază de gratuitate.
Fiecare prestator de servicii se identifică printr-un cod unic, denumire, numărul
de telefon, categoria în care se încadrează (companie aeriană, firmă de transport
terestru, unitate cazare).
Pentru serviciile prestate, agenţia încheie un contract de care pot beneficia mai
mulţi turişti (de exemplu, o familie). În cadrul contractului, pe lângă numărul şi
data încheierii acestuia, se precizează turistul/turiştii beneficiar(i), clauzele
contractuale (drepturile/obligaţiile părţilor contractuale), avansul, data până la
care se poate achita valoarea integrală a contractului, tariful standard aferent
serviciului respectiv, data plecării şi data sosirii. Dacă turistul renunţă din vina
sa la serviciile care fac obiectul respectivului contract, el datorează agenţiei
despăgubiri diferenţiate în funcţie de momentul renunţării (mai exact, numărul
de zile înainte de data plecării).
4.8.2.2 Registrul de casă31
Firma ABC SRL are ca obiect de activitate realizarea de cursuri de pregătire şi
perfecţionare în domeniul limbilor străine. Se doreşte realizarea unei baze de
date pentru evidenţa operaţiilor realizate în lei în cadrul casieriei.
Zilnic se va realiza registrul de casă ce va conţine data realizării operaţiei,
explicaţia operaţiei, suma operaţiei şi tipul operaţiei (încasare sau plată) precum
şi numărul şi tipul documentului (cec de numerar, chitanţa, foaie de vărsământ,
dispoziţie de plată sau încasare, state de salarii, etc). Registrul de casă va
conţine soldul iniţial al zilei, totalul sumelor încasate precum şi soldul final al
zilei. Fiecare operaţie înregistrată în baza de date va primi un număr unic folosit
la identificare.
Încasările pot să provină din vânzarea de servicii proprii (taxele cursanţilor) sau
ridicări de numerar de la bancă, aport de capital. Plăţile se pot face pentru
achitarea drepturilor salariale, avansuri spre decontare, cumpărări de bunuri,
31 Stanciu A. (coord.), Mihai F, Mangiuc D, et al – Baze de date Access 2007: studii de caz,
Editura Infomega Bucureşti, 2009, p. 111
96
depuneri de numerar la bancă. Operaţiile sunt grupate pe categorii în funcţie de
sursa acestora, reţinându-se pentru fiecare operaţie codul categoriei, denumirea
acesteia şi tipul. Principalele categorii de operaţii sunt taxă cursanţi, ridicare
numerar bancă, aport capital, achitare drepturi salariale, avans spre decontare,
cumpărare bunuri, depunere de numerar la bancă, la care pot fi adăugate ulterior
(în timpul exploatării bazei de date) şi alte plăţi sau încasări.
O categorie specială de operaţii o reprezintă avansurile spre decontare. Acestea
trebuie justificate prin intermediul unor documente în cadrul deconturilor de
cheltuieli. Pentru fiecare decont de cheltuieli este necesară reţinerea numărului
şi datei acestuia, a documentelor (număr, data, suma, tip) ce justifică cheltuirea
avansului precum şi a datelor titularului avansului. Pot să beneficieze de
avansuri spre decontare salariaţii firmei. Datele fiecărui salariat (nume, data
naşterii, adresa) vor fi înregistrate în cadrul bazei de date o singură dată, acesta
fiind identificat cu ajutorul mărcii. Avansul neutilizat este restituit la casierie pe
baza documentului de încasare. Documentele justificative pentru avansuri se
vor scana şi se vor arhiva.
4.8.2.3 Societate de asigurări32
Se cere informatizarea activităţii unei societăţi de asigurări. Clienţii societăţii
pot fi persoane fizice sau juridice, caracterizate printr-un număr unic, nume şi
prenume/denumire, adresă şi telefon. Aceştia pot să încheie diferite tipuri de
asigurări (de bunuri, de viaţă). Asigurările sunt încheiate de agenţii care sunt
identificaţi printr-un cod unic, nume şi prenume. Contractul de asigurare este
caracterizat print-un număr, data încheierii, obiectul încheierii, obiectul
asigurării, perioada (în luni), valoarea asigurată şi prima ce va trebui plătită în
fiecare lună de către client. Clienţii efectuează plata primelor din ordin de plată
(persoane juridice) sau direct la casierie (persoane fizice), eliberându-se
chitanţe. Documentul de plată conţine: numărul documentului, data la care a
fost întocmit şi suma plătită. În momentul producerii riscului pentru care a fost
întocmită asigurarea societatea plăteşte clientului despăgubiri. La plata
despăgubirilor se întocmeşte un proces verbal care este caracterizat printr-un
număr, data încheierii, descrierea cauzei care a generat despăgubirea şi
procentul în care este despăgubit clientul.
32 Năstase P., Cosăcescu L., Covrig L., et al – Tehnologia bazelor de date Access 2000, Editura
Economică, Bucureşti, 2000, p. 351
97
CAPITOLUL 5
ELEMENTE INTRODUCTIVE ÎN ACCESS
5.1 Introducere
Sistemele informatice din domeniul economic conţin un volum relativ mare de
date care se organizează cel mai bine în baze de date. Microsoft Access 2007
face parte din suita Microsoft Office 2007, având caracteristicile specifice unui
sistem de gestiune al bazelor de date relaţionale. Access este totodată şi un
instrument complex de dezvoltare al aplicaţiilor de baze de date.
5.2 SGBD Access: prezentare generală
Microsoft Office Access 2007 este un sistem de gestiune a bazelor de date
(SGBD) dezvoltat de firma Microsoft care oferă următoarele facilităţi33
:
permite lucrul atât pe staţii individuale cât şi în reţea, cu exploatarea
partajată a datelor;
are în structură un limbaj neprocedural SQL (Structured Query
Language) – larg răspândit în toate SBDG-urile;
modul de lucru vizual facilitează crearea rapidă a unor aplicaţii;
este autodocumentat şi conţine Wizard-uri;
are access la reţeaua Internet.
Access 2007 include facilităţi oferite de sistemul de operare Microsoft
Windows (de exemplu meniu contextual al obiectelor) şi permite şi facilităţi de
tipul drag and drop. Microsoft Access este compatibil cu tehnicile de legare şi
încapsulare din tehnologia OLE Microsoft (Object Linking and Embedding).
Este recomandată utilizarea Microsoft Access dacă:
sunt necesare baze de date relaţionale (tabele multiple sau multi-
dimensionale) sau dacă se anticipează adăugarea unor noi tabele pe
viitor;
cantitatea de date este mare;
este necesară o legătură permanentă cu o bază de date externă de
dimensiuni mari, cum ar fi una construită cu Microsoft SQL Server sau
cu sistemul integrat al organizaţiei;
33 Tamaş I. (coord.), Stanciu V., Gheorghe M. – Access 2007 – Proiectare şi realizare pas cu pas,
Editura Infomega, Bucureşti, 2010, p.7
98
este necesară regruparea datelor din diverse tabele într-un singur loc cu
ajutorul unor interogări complexe;
baza de date este accesată de mai mulţi utilizatori (se poate beneficia de
mecanismele de modificare furnizate de baza de date).
Este recomandată utilizarea Microsoft Excel dacă:
sunt suficiente tabelele simple, fără relaţii între ele;
se doresc efectuarea de calculi şi comparaţii statistice;
setul de date nu depăşeşte 15000 de înregistrări.
5.2.1 Caracteristici generale
Primul lucru care se poate observa la deschiderea Microsoft Access este noua
interfaţă grafică prietenoasă cu utilizatorul (GUI – Graphical User Interface),
folosită atât de Access cât şi de toată gama de produse Office 2007.
De pe bara de meniuri evidenţiem:
pagina Home (Views, Clipboard, Font, Rich Text, Records,
Sort&Filter, Find) – pagina principală Access, conţine funcţii de
editări de bază cum ar fi Cut şi Paste, împreună cu marea majoritate a
opţiunilor de formatare;
pagina Create (Tables, Forms, Reports, Other) – grupează toate
opţiunile de creare;
pagina External Data (Import, Export, Collect Data, SharePoint
Lists) – conţine toate operaţiile care facilitează colaborarea şi schimbul
de date;
pagina Database tools (Macro, Show/Hyde, Analyze, Move Data,
Database Tools) – coloana vertebrală a Access-ului. Aici se pot crea
sau menţine relaţiile dintre tabele, se analizează performanţele fişierului
şi se execută rutine de întreţinere.
Fereastra Access Options furnizează acces rapid la aproape toate opţiunile care
pot fi configurabile în Access. Dintre acestea vom evidenţia următoarele
opţiuni:
Popular: opţiunile cele mai populare printre utilizatori (selectate de
Microsoft);
Current Database: opţiuni care afectează baza de date curentă, de
exemplu, opţiuni pentru adăugarea unui titlu sau a unei icoane,
selectarea unui formular care să apară la deschiderea aplicaţiei,
dezactivarea opţiunii Layout view, şi o opţiune utilă programatorilor,
activarea sau dezactivarea panoului de navigare (Navigation Pane). În
99
cadrul acestei opţiuni, utilizatorii pot crea o panglică specială şi o pot
folosi în locul celei predefinite;
Datasheet: opţiuni de formatare pentru Datasheet View. Utilizând
această opţiune, se poate selecta tipul literelor folosite, afişarea liniilor
de ghidaj pe formulare şi setarea efectelor implicite ale celulelor;
Object Designers: opţiuni care pot fi setate şi afectează modul în care
uneltele de design sunt configurate în Access. Opţiunile sunt grupate
astfel: Table Design, Query Design, Form Design, Error Checking;
Proofing: include opţiuni legate de verificări gramaticale cum ar fi:
spell checking, grammar checking, şi auto correction;
Advanced: opţiuni care pot fi setate şi care controlează modul în care
Access interacţionează cu datele şi utilizatorul cu aplicaţiile. Sunt
disponibile următoarele grupuri de opţiuni: Editing, Display, Printing,
General, Advanced;
Customization: utile pentru a adăuga sau şterge opţiuni de pe panglică.
Add-Ins: o listă a utilitarelor add-ins disponibile pentru Access;
Trust Center: accesează Trust Center. Mulţi utilizatori setează nivelul
de securitate la nivelul minim pentru a evita mesajele care apar atunci
când se deschide o bază de date care conţine o macrocomandă.
Microsoft recomandă păstrarea nivelului de securitate la valoarea
implicită, şi anume funcţionalitate deplină. În Trust Center sunt
disponibile două opţiuni: Show the message bar in all applications
when content has been blocked şi Never show information about
blocked content.
Resources: conţine link-uri către resurse online care asistă utilizatorul
care lucreză cu Access. Sunt disponibile linkuri la pagina Office,
diagnostice interactive Office 2007, help online şi actualizări de
software.
Există multe opţiuni, controale şi unelte disponibile pentru a ajuta la
modificarea programului şi a aplicaţiei fără a fi necesare cunoştinţe de
programare.
5.2.2 Operaţii cu baze de date
Pentru a deschide Microsoft Access 2007 se acţionează butonul Start de pe
bara de sarcini, se selectează Microsoft Office, apoi Microsoft Office Access
2007.
100
Fig. 1 – Deschiderea mediului de lucru Microsoft Access 2007
La deschiderea Microsoft Access 2007 pe ecran va apare fereastra Getting
Started with Microsoft Office Access.
Fig. 2. – Fereastra Getting Started with Microsoft Office Access
Butonul Office
101
În partea din dreapta a ecranului sunt vizibile link-uri către ultimele fişiere de
tip bază de date utilizate. În cazul închiderii accidentale a bazei de date, aceasta
poate fi deschisă rapid selectând primul link din lista Open Recent Database.
Dacă se doreşte modificarea locaţiei implicite de salvare a bazelor de date se
selectează butonul Office, se alege opţiunea Access Options, modificând cu
ajutorul butonului Browse opţiunea Default database folder.
Fig. 3. – Modificarea locaţiei implicite în care sunt salvate bazele de date
5.2.2.1 Crearea unei baze de date
Pentru a crea o bază de date vidă se alege butonul Blank Database – figura 2.
Folosind icoana de folder din partea din dreapta a ecranului se alege locaţia
unde va fi salvată baza de date, se tastează numele dorit, apoi se apasă butonul
Create – figura 4.
Fig. 4 – Stabilirea locaţiei şi a denumirii bazei de date
102
Odată cu crearea unei baze de date vide, Microsoft Access crează o nouă tabelă
în care să fie salvate datele. Aceasta poarta numele implicit Table1 şi este
deschisă în Datasheet View (mod de vizualizare care permite afişarea datelor
din tabel). Pentru a crea o tabelă în acest mod de vizualizare se poate studia
problema rezolvată 5.13.1.
5.2.2.2 Parolarea unei baze de date
Pentru a parola baza de date, aceasta trebuie să fie deschisă exclusiv. Pentru
aceasta, se închide baza de date folosind butonul Office, opţiunea Close
Database – figura 5.
Fig. 5 – Închiderea unei baze de date
Pentru a uşura accesul la anumite butoane se poate folosi bara de acces rapid.
Pentru a afişa mai multe butoane pe aceasta (în cazul de faţă butonul Open) se
apasă săgeata din partea dreaptă a barei, selectându-se comanda Open. Butonul
Open va fi afişat pe bara de acces rapid. Analog se pot selecta alte butoane
pentru a fi afişate pe bara de acces rapid. Dacă acestea nu sunt afişate implicit,
se pot căuta utilizând comanda More Commands.
103
Fig. 6 – Adăugarea butonului Open pe bara de acces rapid
Pentru a deschide exclusiv baza de date creată anterior se apasă butonul Open
de pe bara de acces rapid – figura 7.
Fig. 7 – Butonul Open de pe bara de acces rapid
În fereastra Open se selectează locaţia, numele bazei de date, apoi de pe
butonul Open se selectează opţiunea Open Exclusiv – figura 8.
Fig. 8 – Deschiderea exclusivă a unei baze de date
Baza de date fiind deschisă exclusiv, de pe bara de meniuri se alege opţiunea
Database Tools, apoi comanda Encrypt with Password – figura 9. În fereastra
Set Database Password se cere introducerea parolei de două ori, la apăsarea
butonului OK baza de date fiind protejată.
104
Fig. 9 – Parolarea bazei de date
Protejarea bazei de date este vizibilă doar la deschiderea acesteia, deci pentru a
verifica acest lucru se închide şi se deschide din nou baza de date. Pentru a
elimina parola setată la deschiderea bazei de date, aceasta trebuie deschisă
exclusiv, selectându-se mai apoi opţiunea Decrypt Database – figura 10.
Fig. 10 – Decriptarea bazei de date
În cazul în care panoul de navigare este ascuns, acesta poate fi afişat selectând
săgeţile laterale – figura 11.
Fig. 11 – Afişarea/ascunderea panoului de navigare
105
Afişarea sau ascunderea panglicii (Ribbon) poate fi controlată folosind
opţiunea Minimize the Ribbon de pe bara de acces rapid – figura 12.
Fig. 12 – Minimizarea/afişarea panglicii (Ribbon)
5.2.2.3 Salvarea unei baze de date
Pentru a salva o bază de date cu un alt nume, se apelează butonul Office,
opţiunea Save as, apoi Access 2007 Database, selectându-se apoi locaţia şi/sau
noul nume al fişierului.
5.2.2.4 Închiderea unei baze de date
Pentru a închide o bază de date, de pe butonul Office se apelează comanda
Close Database.
5.2.2.5 Deschiderea unei baze de date
Pentru a deschide o bază de date se poate folosi lista din partea dreaptă a
ecranului, priul link fiind către ultima bază de date utilizată, sau utilizând
butonul Office, opţiunea Open.
5.2.3 Obiectele bazei de date
Principalele obiecte conţinute în Microsoft Access 2007 sunt:
Tabele (Tables): structuri elementare în care sunt stocate datele în
cadrul unei baze de date. Tabelele sunt inima oricărei baze de date. De
exemplu, o bază de date legată de fitness poate să reţină informaţii
legate de antrenamentul efectuat, echipamentele utilizate şi numărul
Observaţie: Baza de date se salvează automat, dar obiectele conţinute trebuie salvate de către utilizator. Numele bazei de date este setat la începutul creării
acesteia. Dacă se doreşte salvarea bazei de date cu alt nume, de pe butonul
Office se alege Save as.. urmată de opţiunea Access 2007 Database,
specificându-se locaţia şi numele bazei de date.
106
milkshake-urilor consumate în fiecare zi în trei tabele separate. O tabelă
este containerul în care sunt stocate datele. Restul obiectelor permit
manipularea datelor stocate în tabele. Construirea tabelelor Access se
poate rezuma la două activităţi principale: crearea structurii tabelei (în
modul de vizualizare Design View) şi popularea tabelului cu date – fie
în Datasheet View, prin intermediul formularelor sau a instrucţiunilor
SQL;
Interogări (Queries): sunt structuri care permit efectuarea unei acţiuni
rapide asupra unei tabele sau mai multor tabele. Aceste acţiuni implică
de obicei obţinerea unei informaţii necesare (de exemplu, cumpărăturile
efectuate pe parcursul unei zile cu cardul de credit), sau aplicarea unor
modificări. Interogările sunt obiecte virtuale de tip tabelă care nu au
corespondent fizic, fiind definite cu ajutorul tabelelor create deja în
baza de date. Ele permit efectuarea selecţiilor şi sortărilor în tabele, a
calculelor simple şi analizelor încrucişate, a acţiunilor (crearea unui nou
tabel, adăugarea, ştergerea sau actualizarea înregistrărilor) sau execuţia
unor comenzi SQL.
Formulare (Forms) sunt ferestre atractive folosite pentru a consulta
sau actualiza datele dintr-un tabel sau o interogare. Ele permit totodată
crearea unui meniu interactiv construit de către utilizator, furnizând şi o
facilitate specială pentru aceasta (Switchboard). Pe un formular pot fi
plasate butoane care pot încorpora comenzi SQL;
Rapoarte (Reports) – sunt utilizate pentru a tipări unele sau toate
informaţiile din tabele sau interogări. Permit gruparea şi sortarea
datelor, adăugarea unor câmpuri calculate, numere de pagină, etc;
Macrocomenzi (Macros) – mini-programe care automatizează
sarcinile curente. Macrocomenzile sunt formate dintr-o suită de acţiuni;
Module (Modules) – fişiere care conţin cod Visual Basic Application.
VBA este un mediu de programare orientat obiect. Se pot defini
variabile, constante, funcţii şi proceduri globale întregii aplicaţii sau
asociate unui anumit obiect. Cu ajutorul acestor coduri se poate executa
aproape orice.
5.3 Obiecte Tables
Înaintea descoperirii bazelor de date, organizaţiile lucrau cu datele manual. Ei
plasau hârtii în dosare şi organizau dosarele în sertare ale unui dulap. Dulapul
este echivalentul bazei de date. Fiecare sertar plin de dosare corespunde unui
tabel din baza de date.
107
Un câmp este o unitate elementară sau o categorie cum ar fi titlurile cărţilor sau
numerele de telefon. Un câmp nu conţine în mod necesar o valoare. De
exemplu, un câmp numit e-mail poate rămâne necompletat dacă furnizorul nu
deţine o adresă de e-mail. O înregistrare este un set complet de date (câmpuri)
care se referă la o persoană, loc, eveniment, idee. De exemplu, pentru un
profesor numărul matricol, numele, prezenţa şi nota finală compun o
înregistrare. O tabelă, fundaţia oricărei baze de date, este o colecţie de
înregistrări care au legătură unele cu altele, şi conţine câmpuri pentru a organiza
datele.
O coloană reprezintă un câmp, o linie reprezintă o înregistrare. Fiecare
înregistrare conţine aceleaşi câmpuri în aceeaşi ordine. Fişierul profesorului cu
prezenţele studenţilor este o tabelă care conţine înregistrări despre toţi studenţii
având o structură comună. O bază de date constă în una sau mai multe tabele şi
obiectele suport care permit introducerea datelor, prelucrarea şi extragerea lor
din tabele.
Fig 13. Bază de date primitivă
Definiţie: O cheie primară este un câmp (sau o combinaţie de
câmpuri) a cărui valori identifică în mod unic o înregistrare într-un
tabel.
Fig. 14 Concepte de bază
Cheie primară Câmp
Înregistrare
valoare
valoarea câmpului
tabel
înregistrare
baza de date
108
Codul produsului este cheie primară în tabela produse. Cheia primară poate
conţine numere, litere, sau o combinaţie a acestora.
Puterea bazelor de date relaţionale stă în abilitatea SGBD-ului de a organiza
datele şi a le recombina pentru a obţine o imagine completă a evenimentelor
descrise. Un design eficient a bazelor de date conectează datele din diferite
tabele sub forma unui sistem de legături.
Legătura dintre tabele este ca un fir electric care traversează baza de date
conectând tabelele astfel încât să permită obţinerea răspunsului la cererea
utilizatorului (figura 15). Odată identificat răspunsul, câmpurile şi înregistrările
sunt rearanjate astfel încât să poate fi înţelese cu uşurinţă de către utilizator.
Capătul de început al firului este creat odată cu setarea cheii primare într-unul
dintre tabele. Celălalt capăt la firului este legat de un câmp dintr-un alt tabel.
Acel câmp poartă numele de cheie străină. De exemplu câmpul cod_f (cod
furnizor) din tabela furnizori este un câmp de tip cheie străină.
Definiţie: O cheie străină este un câmp dintr-o tabelă, care într-o altă
tabelă este cheie primară.
Fig. 15 – Fereastra Relationships
După cum se poate observa din figura 15, chiar şi în relaţia normalizată încă
mai există redundanţe. De exemplu, codul produsului (cod_p) apare în mai
multe tabele. De fapt nu pot fi eliminate toate câmpurile duplicate şi în acelaşi
timp menţinute legăturile dintre tabele. Acest tip de redundanţă (cheie primară-
cheie străină) poartă numele de redundanţă necesară.
Orice legătură dintre două tabele poată fi întărită utilizându-se regulile de
integritate referenţială. Integritatea sugerează încredere. Atunci când regulile de
integritate sunt stabilite, utilizatorul poate avea încredere în firul care leagă
tabelele bazei de date, fiind păstrată acurateţea datelor.
Regulile de tip cascadă permit ca modificările datelor să se perpetueze dintr-o
tabelă în alta – figura 16.
109
Definiţie: Regula Cascade Update Related Records va fi setată în cazul
în care dacă o valoare a câmpului pe care este setată cheia primară este
modificată, atunci toate valorile corespunzătoare din tabela referită sunt
modificate automat cu aceeaşi valoare. Regula Cascade Delete Related
Records va fi setată în cazul în care dacă o valoare din tabela de referinţă
este ştearsă prin ştergerea înregistrării care o conţine, atunci toate
înregistrările din tabela referită care conţin acea valoare referită vor fi
automat şterse.
Fig. 16 – Setarea regulilor de integritate referenţială
Legăturile dintre tabele în Microsoft Access 2007 sunt de mai multe tipuri:
One-to-Many (unu-la-mai-mulţi) – această legătură se crează între o
cheie primară dintr-un tabel şi o cheie străină din alt tabel. În prima
tabelă există o singură înregistrare care conţine o valoare a câmpului de
tip cheie primară. În cea de-a doua tabelă există mai multe înregistrări
care conţin în câmpul comun aceeaşi valoare a câmpului comun.
One-to-One (unu-la-unu) – se crează între două tabele care au aceeaşi
cheie primară sau un câmp de tip cheie primară în prima tabelă şi un
câmp cheie străină pe care este setat un index Unique din a doua tabelă.
În acest caz în ambele tabele există o singură înregistrare cu valoarea
câmpului comun identică. Acest tip de relaţie se foloseşte foarte rar, în
special datorită necesităţii menţinerii securităţii datelor din tabele.
Many-to-Many (mai-mulţi-la-mai-mulţi) – acest tip de relaţie este
construită artificial (nu există în Access) şi corespunde mai multor
valori ale câmpului comun din ambele tabele. În acest caz este necesară
construirea unui nou tabel numit tabel de joncţiune.
Într-o bază de date bine definită, relaţia de tip one-to-many este cel mai frecvent
întâlnită.
Pentru a crea un nou tabel, de pe panglică, opţiunea de meniu Create, se
selectează Table Design. Design View este un mod de vizualizare care oferă
cele mai puternice opţiuni pentru definirea unei tabele.
110
Atunci când se proiectează o tabelă este importantă cunoaşterea operaţiilor de
bază care pot fi efectuate cu câmpurile acesteia:
pentru adăugarea unui nou câmp între alte câmpuri existente – se
poziţionează cursorul pe câmpul deasupra căruia se doreşte adăugarea
unui nou câmp, se apelează meniul contextual (clic cu butonul din
dreapta al mouse-ului) şi se alege opţiunea Insert Rows;
mutarea unui câmp – un câmp poate fi mutat folosind drag-and-drop,
selectându-se pătratul gri din stânga numelui câmpului şi
repoziţionându-se câmpul în poziţia dorită;
ştergerea unui câmp – se apelează meniul contextual al pătratului gri
din stânga numelui câmpului şi se selectează Delete Rows. De reţinut
faptul că odată cu ştergerea unui câmp se şterg toate datele depozitate
în acel câmp, acţiunea nefiind reversibilă, de aceea Access afişează un
mesaj pentru a preveni eventualele ştergeri accidentale.
Fiecare câmp are un nume (Field Name) cu ajutorul căruia sunt identificate
datele introduse în acel câmp. Numele câmpului trebuie să fie descriptiv pentru
datele conţinute şi poate conţine maxim 64 de caractere incluzând litere, cifre şi
spaţii. Este interzisă utilizarea caracterelor ., !, [, şi ], iar numele câmpului nu
poate începe cu cu spaţiu.
Fiecare câmp este definit ca fiind de un anumit tip (Data Type), care determină
valorile care pot fi introduse şi operaţiile care pot fi efectuate cu datele. Access
recunoaşte 10 tipuri de date:
Text – date alfanumerice – cele mai multe caractere care se află pe
tastatură (incluzând numere), cu limita maximă de 255 de caractere.
Câmpurile care conţin doar numere care nu sunt folosite pentru a
efectua calcule ar trebui setate ca fiind de tip Text (numere de
telefon, coduri poştale, numărul cărţii de identitate, numărul de
paşaport);
Number – conţine o valoare care poate fi folosită în calcule, ca de
exemplu numărul creditelor pe care le are un student. Conţinutul
câmpului de tip Number este restricţionat la numere, virgula zecimală şi
simbolurile + şi -:
Byte – numere între 1 şi 255 (ocupă 1 byte);
Integer – numere în intervalul [-32768,+32757] (ocupă 2 bytes);
Long Integer – [-2147483648,+2147483647] (ocupă 4 bytes);
Single – numere reprezentate în simplă precizie:
[-3.40*1038
,3.40*1038
] (ocupă 4 bytes şi are precizie de 7
zecimale);
111
Double – numere reprezentate în dublă precizie, [-1.797*10308
,
1.797*10308
] (ocupă 8 bytes şi are precizie de 15 zecimale);
Replication ID – GUID (Global Unique IDentifier) – identificator
unic global, (ocupă 16 bytes) este folosit pentru un câmp care
este sau compun un câmp de tip cheie străină – corespondentul
unui câmp de tip cheie primară Autonumber;
Decimal – [-1028
, 1028
] (ocupă 12 bytes şi implicit are o precizie
de 18 zecimale care poate să crească până la 28 de zecimale).
Memo – blocuri mari de text – de lungime maximă 65536 caractere.
Câmpurile de tip Memo sunt utilizate pentru a păstra date descriptive
(propoziţii, paragrafe). Lungimea maximă este de is 2 GB.
Date/Time – conţine date calendaristice formatate, ore, sau ambele,
permiţând calcule aritmetice cu acestea. Anii din datele calendaristice
sunt în intervalul dintre anii 100 şi 9999. Datele sunt salvate sub formă
de număr pe 8 bytes, cu dublă precizie;
Currency – numere cu 4 zecimale urmate de simbolul monetar, cu care
pot fi efecuate calcule. Ocupă 8 bytes şi sunt utilizate pentru calcule
financiare, dacă nu se doreşte rotunjirea valorilor;
AutoNumber – un număr care este incrementat automat pentru fiecare
înregistrare. Valoarea unui câmp de tip Autonumber este unică pentru
fiecare înregistrare din tabel, de aceea tipul Autonumber se utilizeză în
mod frecvent ca tip de date al unui câmp cheie primară. Numărătoarea
poate fi secvenţială sau întâmplătoare (random). Valoarea acestuia nu
poate fi modificată şi ocupă 4 bytes;
Yes/No – permite alegerea unei valori din 2 posibile, o informaţie
discretă care poate avea doar două valori cum ar fi: True/False, Yes/No,
On/Off, (ocupă 1 byte);
OLE Object – conţine un obiect creat cu o altă aplicaţie, cum ar fi
Microsoft Excel, Microsoft Word sau poze. Dimensiunea maximă a
fişierului este de 2GB, dar baza de date este încetinită considerabil prin
înglobarea obiectelor externe;
Hyperlink – utilizat pentru a stoca adrese Web (URL – Uniform
Resource Locators). Toate fişierele din suita Office permit facilităţi
Web – dacă se selectează un link, automat este afişată pagina Web
asociată (1 GB);
Attachment – cel mai nou tip de date introdus doar în MS Access
2007, permite ataşarea mai multo obiecte create cu alte aplicaţii.
Măreşte flexibilitatea bazei de date prin utilizarea technicilor OLE
(Object Linking and Embedding=Legare şi Încorporare de Obiecte);
112
Lookup Wizard – este utilizat pentru valori care vor fi completate
selectând o valoare dintr-o casetă combinată. Nu este un tip de date
propriu-zis, ci un program utilitar care crează relaţii cu tabela părinte
sau o listă definită de utilizator.
Pentru a crea o legătură între tabele, se va crea tabela de referinţă cu cheia
primară, se inserează date în tabelă, apoi se crează tabela referită, iar pentru
câmpul care va fi cheie străină se va selecta opţiunea Lookup Wizard, cu prima
opţiune I want the lookup column to lookup the values in a table or query;
se selectează numele tabelei de referinţă, câmpul de tip cheie primară din tabela
de referinţă şi ordinea de sortare. Atunci când se introduc date în câmpul de tip
cheie străină din tabela referită se utilizează caseta combinată creată cu ajutorul
opţiunii Lookup Wizard, selectându-se din valorile din listă.
Dacă se doreşte crearea unei liste predefinite de către utilizator, se va selecta
Lookup Wizard cu a doua opţiune I will type in the values that I want, apoi
se vor insera toate valorile pe o coloană. Atunci când se inserează datele în
câmpul respectiv, se utilizează caseta combinată creată automat de către
Lookup Wizard.
Description este o coloană opţională care se utilizeză dacă se doreşte afişarea
descrierii câmpului pe bara de stare atunci când câmpul este selectat (activ).
O proprietate este o caracteristică sau un atribut care determină cum va arăta şi
cum se va comporta obiectul. Fiecare obiect Access are o mulţime de
proprietăţi. Proprietăţile tabelei sunt afişate şi pot fi modificate în fereastra
Property Sheet. Aceasta se găseşte pe panglică, în modul de vizualizare Design
View, opţiunea de meniu Design.
Fiecare câmp are o mulţime de proprietăţi. Proprietăţile sunt setate pe valoarea
implicită în concordanţă cu tipul de date selectat, dar pot fi modificate. Ele sunt
afişate în modul de vizualizare Design View, în partea de jos a ecranului.
Field Size (dimensiunea câmpului) – ajustează dimensiunea unui
câmp de tip text sau limitează valoarea permisă într-un câmp de tip
numeric. Microsoft Access utilizează doar cantitatea de spaţiu de
stocare necesară, chiar dacă dimensiunea câmpului permite o
dimensiune mai mare. Multe SGBD-uri folosesc tot spaţiul specificat ca
dimensiune a cîmpului. De aceea, este utilă crearea obişnuinţei de a
reduce dimensiunea spaţiului cu scopul ajustării la cerinţele de stocare
ale sistemului (optimizarea spaţiului de stocare);
113
Decimal Places – specifică numărul de zecimale. Valoare predefinită
este Auto – sunt afişate toate zecimalele rezultate în urma calculelor,
dar nu mai mult de 15 zecimale;
Format – modifică modul de afişare al valorii unui câmp, dar nu
afectează valoarea stocată;
pentru unele tipuri de date cum ar fi Number, Date/Time şi
Yes/No – se poate alege formatul dorit dintr-o listă;
pentru câmpuri de tip Number pot fi afişate valori pozitive,
negative, zero sau valoarea Null folosind caractere speciale (0,
#, $, %, E+, E-, e+, e-);
pentru câmpuri de tip Date/Time: se utilizează următoarele
caractere (d – zi între 1 şi 31, dd – zi între 01 şi 31, ddd –
primele 3 litere în engleză din numele zilei (de exemplu, Mon
de la Monday pentru ziua de Luni), dddd – numele întreg al
zilei, etc…);
pentru câmpuri de tip Text:
! – dacă se introduc numere;
< – litere mici; > – majuscule;
“text” – textul va apărea exact cum este scris: “text”;
@ – crează grupuri de numere: @@@@-@@@-@@@
cum ar fi 0744-256-56.
Input Mask – facilitează introducerea datelor afişând caractere care nu
sunt stocate, cum ar fi caracterul slash într-o dată calendaristică (/). De
asemenea, asigură validarea datelor pentru a corespunde formatului ales
(de exemplu, previne introducerea unei cifre în plus sau în minus în
cazul unui număr de telefon);
0 – o cifră obligatorie între 0 şi 9;
9 – o cifră opţională între 0 şi 9;
A – o literă sau o cifră obligatorie;
a – o literă sau o cifră opţională;
# – o cifră opţională între 0 şi 9 sau un spaţiu opţional;
& – orice caracter sau spaţiu;
C – un caracter opţional sau un spaţiu
L – o literă obligatorie de la A la Z;
? – o literă opţională de la A la Z;
> – litere care vor fi transformate în majuscule;
< – litere care vor fi transformate în majuscule.
Când ambele proprietăţi sunt setate, (Format şi Input Mask),
Format este cea impusă (are prioritate).
114
Caption – specifică o etichetă diferită faţă de numele câmpului, care va
fi afişată în DataSheet View în capul de tabel, pe formulare şi rapoarte.
Lungimea maximă a valorii introduse în Caption este 2084 caractere.
Valoarea proprietăţii Caption nu are nici o semnificaţie în cadrul
interogărilor sau când se utilizează cod în Visual Basic Application;
Default value – introduce automat o valoare predefinită pentru câmpul
respectiv atunci când o nouă înregistrare este inserată într-un tabel. De
exemplu, dacă foarte mulţi dintre studenţi sunt născuţi în Timişoara,
valoarea proprietăţii Default Value poate fi modificată în Timişoara;
Validation Rule – respinge orice înregistrare pentru care valoarea
introdusă în câmpul respectiv nu respectă regula stabilită. Expresia
poate fi tastată în interiorul casetei de text, sau se poate selecta butonul
pentru a deschide fereastra Expression Builder. Această
proprietate nu poate fi folosită pentru tipuri de date cum ar fi:
Autonumber, OLE Object, Attachment, Number cu sub-tipul
Replication ID. Pentru a construi o regulă de validare pot fi folosite
funcţii Access, operatori şi constante. Numele câmpului trebuie să apară
între paranteze drepte, de exemplu [cod produs]. Exemple de reguli de
validare:
>200 and <=400 – pentru un câmp numeric;
<>NULL, IS NOT NULL – pentru orice fel de câmp;
“Timisoara” – pentru un câmp de tip Text;
>=#03/12/2011# – pentru o dată calendaristică;
>=Date() – pentru o dată calendaristică;
Year([data factura])=Year(Date()) – unde fucţia Year extrage
anul dintr-o dată calendaristică (în acet caz câmpul data
facturii), iar funcţia Date() extrage data curentă;
Validation Text – specifică mesajul de eroare care va fi afişat în cazul
în care regula de validare nu este respectată;
Required – dacă este setată pe Yes, respinge orice înregistrare care nu
conţine o valoare în câmpul respectiv; valoarea predefinită este No;
Allow Zero Length – dacă este setată pe Yes, permite şirul de lungime
zero în cazul câmpurilor de tip text sau memo; valoarea predefinită este
No;
Indexed – măreşte eficacitatea căutărilor în acel câmp (câmpul pe care
este setată cheia primară este întotdeauna indexat):
No – nu este setat nici un index;
Yes (No Duplicates) – este setat un index care nu permite
duplicarea valorilor, ca în cazul CNP-ului, de exemplu. Este
valoarea care apare atunci când se setează cheia primară;
115
Yes (Duplicates Ok) – este setat un index care permite duplicarea
valorilor, ca în cazul numelui pacientului, de exemplu.
Indecşii mai pot fi definiţi şi prin intermediul butonului Indexes de pe
panglică – figura 17. Se poate seta numele indexului (Index Name),
câmpul pe care acesta va fi setat (Index Field), şi ordinea de sortare
(Sort Order), specificându-se pentru fiecare index tipul acestuia:
Primary (dacă se doreşte crearea unui index de tip Primary Key),
Unique (crearea unor chei candidate – cu valori unice) sau Ignore Null
(crearea unui index care ignoră valorile Null).
Fig. 17 – Fereastra Indexes
Unicode Compression – pentru câmpurile Text, Memo şi Hyperlink,
are valoarea implicită setată pe Yes şi este folosită pentru a eficientiza
modul de stocare a datelor;
IME Mode and IME Sentence Mode – specifică modul Input Method
Editor cu opţiunea implicită No Control pentru versiunea în engleză şi
tipul de dată – pentru modul Input Method;
Smart Tags – pentru utilizatorii avansaţi, permite adăugarea butoanelor
de acţiune asociate unui câmp. Atunci când o bază de date oferă
produse la ofertă, un buton de tip Smart Tag încorporat câmpului nume
produs ar putea deschide un fişier de inventar pentru a vizualiza
produsele din stoc;
Text Align – aliniază textul, furnizând următoarele opţiuni: General
(aliniere predefinită), Left (aliniere la stânga), Center (aliniere
centrată), Right (aliniere la dreapta) şi Distributed (aliniere şi la stânga
şi la dreapta).
Datasheet View este utilizat pentru inserarea datelor în tabele. Vizualizarea de
tip Pivot Table View furnizeză un mod convenabil de sumatizare şi organizare
a datelor în grupuri de înregistrări. Vizualizarea Pivot Chart View afişează un
116
grafic asociat modului de vizualizare Pivot Table View. Pentru a trece de la un
mod de vizualizare la altul, se poate utiliza fie butonul View de pe panglică,
opţiunea de meniu Home, fie butonul corespunzător de pe bara de stare (Status
bar). O tabelă poate fi deschisă din panoul de navigare direct în modul de
vizualizare dorit apelându-se meniul contextual al tabelei şi selectându-se
modul de vizualizare dorit.
5.4 Obiecte Queries
Interogarea este un obiect ce permite vizualizarea informaţiilor din una sau mai
multe tabele pe baza unor criterii de selecţie. Microsoft Access prevede o
interfaţă prietenoasă cu utilizatorul, de tip QBE (Query By Example) pentru a
construi o interogare. Rezultatul unei interogări este o foaie de răspuns
dinamică care poartă numele de Dynaset. Aceasta este volatilă (dispare odată cu
închiderea interogării).
Cu ajutorul unei interogări pot fi grupate datele din mai multe tabele, pe baza
leagăturilor create între ele, pot fi create noi câmpuri calculate, dar pot fi
efectuate şi următoarele acţiuni: crearea unui nou tabel, adăugarea înregistrărilor
din alt tabel, modificarea valorii câmpurilor sau ştergerea înregistrărilor.
Interogările se crează de obicei în modul de vizualizare Query Design. Pentru a
vedea rezultatul interogării, se trece în modul de vizualizare Datasheet View
sau se apasă butonul Run de pe panglică, opţiunea de meniu Design. O altă
modalitate de a crea o interogare este folosind modul de vizualizare SQL View.
Această metodă necesită cunoştinţe de SQL (Structured QueryLanguage) –
detaliate în capitolul următor.
Interogările sunt de mai multe tipuri:
de selecţie (SELECT) – permit afişarea datelor din una sau mai multe
tabele, pe baza unor criterii de selecţie, calcularea unor câmpuri şi
afişarea datele ordonate după anumite câmpuri crescător sau
descrescător;
de sintetizare a datelor (TOTAL) – permit selectarea unor câmpuri ca
criterii de grupare, fiind aplicate diverse funcţii: SUM, MIN, MAX,
COUNT, etc;
de analiză încrucişată (CROSSTAB) – de analiză încrucişată a
datelor;
de acţiune (MAKE TABLE, APPEND, UPDATE, DELETE);
speciale (UNION, PASS THROUGH, DATA DEFINITION).
Cel mai des întâlnite şi utilizate sunt interogările de selecţie.
117
5.4.1. Interogări de selecţie
Pentru a crea o interogare, de pe panglică, opţiunea de meniu Create, se apasă
butonul Query Design.
Fig. 18 – Fereastra QBE
În fereastra Show Table se va preciza sursa datelor executând dublu-clic pe
numele tabelei sau tabelelor – figura 18. De reţinut că dacă se selectează mai
multe tabele, trebuie specificate toate tabele intermediare pentru a fi vizibile
legăturile dintre ele – în caz contrar rezultatul interogării nu este cel dorit. După
închiderea ferestrei, dacă se doreşte redeschiderea ferestrei pentru a adăuga o
nouă tabelă, se selectează butonul cu acelaşi nume de pe panglică. Dacă se
doreşte ştergerea unei tabele, se apelează meniul contextual asociat acesteia,
selectându-se comanda Delete. După ce tabelele au fost selectate, ferestra Show
Table se închide.
Următorul pas este selectarea câmpurile din tabele. Se execută dublu clic pe
numele de câmpurilor din tabele, acestea fiind selectate automat în partea de jos
a ecranului, find completate liniile Field şi Table.
Linia Sort permite ordonarea valorilor câmpurilor în ordine crescătoare
(Ascending) sau descrescătoare (Descending).
Pe linia Show sunt selectate implicit toate câmpurile ca fiind vizibile. Dacă se
doreşte ascunderea unui câmp din vizualizarea finală, se debifează check-box-ul
corespunzător.
Liniile Criteria şi Or permit impunerea unor condiţii. Dacă operatorul dintre
condiţii este AND, atunci toate condiţiile se scriu pe linia Criteria. Dacă între
condiţii operatorul este OR, atunci a doua condiţie se scrie pe linia Or.
Pentru a vizualiza rezultatul interogării se trece de pe bara de stare în Datasheet
View.
118
Dintre operatorii folosiţi în construirea expresiilor de pe linia Criteria
amintim: + (adunare), - (scădere), * (înmulţire), / (împărţire), MOD (restul
împărţirii a două numere), ^ (ridicarea la putere, de exemplu x2 se scrie x^2), &
(concatenare a două şiruri de caractere), = (verifică egalitatea a două valori), <>
(operatorul diferit, de exemplu ), < (strict mai mic), > (strict mai mare), <= (mai
mic sau egal), >= (mai mare sau egal), LIKE (format general LIKE „masca‟, de
exemplu nume LIKE „A*‟ se vor afişa toate numele care încep cu A, indiferent
din câte caractere, dar LIKE „A??‟ va afişa doar numele care începe cu A şi are
lungimea de trei caractere), IN (formatul general IN (listă de valori), de
exemplu condiţia: sex IN („m‟,‟f‟) sau [tip client] IN („persoana
fizica‟,‟persoana juridica‟)), BETWEEN (format general Between Val_minimă
AND Val_maximă, de exemplu, dacă se doreşte afişarea studenţilor cu note
între 9 şi 10 se va utiliza condiţia BETWEEN 9 AND 10), NOT (negaţie), AND
(conjuncţie), OR (disjuncţie), NOT NULL (va afişa toate înregistrările care nu
au valori introduse în acel câmp), Date() (returnează data curentă), MONTH
(afişează luna dintr-o dată calendaristică, de exemplu MONTH(#27.12.2011#)
va returna valoarea 12), YEAR (afişează anul dintr-o dată calendaristică, de
exemplu YEAR(#21.11.2011#) va returna valoarea 2011), IIF (cu formatul
general IIF (condiţie, val_dacă_adevarat, val_daca_fals), de exemplu dacă se
doreşte afişarea situaţiei bursierilor: pentru studenţi care au media peste 9,50 se
va afişa bursă de merit, celor între 8 şi 9,50 bursă de studiu iar celorlaţi nimic,
se va scrie următoarea condiţie: IIF ([media]>9,5; „bursa de merit‟; IIF([media]
BETWEEN 8 AND 9,50;‟Bursa de studiu‟;‟‟)) ) şi multe altele. Simbolul ; care
desparte argumentele funcţiei depinde de setările regionale. Setările regionale
utilizate în cadrul aceszui capitol sunt cele corespunzătoare României (Control
Panel, Clock Language and Region, Change Location, pagina Location, Current
Location: Romania). Data calendaristică este astfel formatată ca dd.mm.yyyy,
iar punctul zecimal este simbolul virgulă. În cazul în care este selectată o altă
locaţie, atât separatorul care desparte argumentele funcţiei, simbolul zecimal,
formatul Currency cât şi formatele Date/Time sunt modificate în consecinţă.
Dacă se doreşte adăugarea unui câmp care va fi calculat după o formulă, se
selectează prima coloană liberă în Design View, iar pe linia Field se tastează
numele care se doreşte să apară în capul de table ca titlul al coloanei respective,
urmat de simbolul : şi formula de calcul. Numele de câmpuri se scriu între
paranteze drepte. De exemplu: Valoare: [cant]*[pret]. Dacă se doreşte
formatarea câmpului (de exemplu, Currency), în Design View se apelează
meniul contextual pe câmpul proaspăt construit, se selectează Properties, apoi
la proprietatea Format se selectează Currency.
119
Interogări cu parametru
În cazul interogărilor de selecţie se pot utiliza parametrii. Dacă se doreşte citirea
interactivă de la tastatură a unei valori a unui câmp, în vederea verificării unui
criteriu şi a afişării datelor din tabelă/tabele, pe linia Criteria se introduce între
paranteze drepte un text, de exemplu [Introduceti data facturii]. Acest text va fi
interpretat ca un parametru, construindu-se automat pentru acest parametru o
casetă de introducere a valorii. Va fi evaluată valoarea citită de la tastatură, se
verifică egalitatea cu valorile din câmpul pe care este plasat parametrul, şi
anumte [data facturii], şi sunt afişate înregistrările care verifică condiţia [data
facturii]=valoarea introdusă de la tastatură.
5.4.2 Interogări de sintetizare a datelor
Interogarea de selecţie poate fi transformată într-o interogare de sintetizare a
datelor apelîndu-se butonul Totals de pe panglică. Aceasta are ca efect crearea
unei linii noi denumită Total, unde automat apare condiţia Group by.
Pentru a crea o interogare de sintetizare a datelor:
1. se crează o interogare în Design View;
2. se selectează sursa datelor (din fereastra Show Table, dublu-clic pe
numele tabelelor, neapărat acestea trebuie să fie toate legate între ele),
apoi se închide fereastra Show Table;
3. se selectează câmpurile după care se grupează datele şi câmpurile care
trebuie calculate (de exemplu dacă se doreşte afişarea mediei anului, se
aleg câmpuri an şi medie; dacă se doreşte afişarea medie studenţilor pe
grupe, se aleg câmpurile an, grupa şi medie);
4. se selectează butonul Totals. Pe linia Totals vor apare opţiunile Group
By – utilizate pentru a defini grupurile de înregistrări asupra cărora se
vor executa funcţii agregat (SUM, MIN, MAX, COUNT, AVG, etc);
5. pe coloana/coloanele care se doresc a fi calculate şi linia Totals se alege
o funcţie de agregare sau condiţia WHERE care permite impunerea
unor criterii suplimentare. Toţi operatorii amintiţi mai sus pot fi folosiţi
în clauza Where;
6. dacă se doreşte ascunderea unor câmpuri, se deselectează caseta
corespunzătoare de pe linia Show;
7. pentru a vizualiza rezultatul se apelează opţiunea Datasheet View.
120
5.4.3 Interogări de acţiune
Interogările de acţiune sunt nu au ca efect afişarea unui rezultat, ele au un alt
scop: manipularea datelor din tabele. Operaţiile care pot fi executate cu ajutorul
interogărilor de acţiune sunt: Make Table, Append, Update şi Delete.
Pentru ca toate aceste interogări de acţiune să poată fi executate, este necesară
setarea unui nivelul de securitate mai scăzut prin selectarea butonului Options
de pe bara Security Warning, selectându-se opţiunea Enable this content.
5.4.3.1 Interogări pentru crearea unei noi tabele (MAKE TABLE)
Interogările care crează o nouă tabelă sunt utilizate de obicei pentru a obţine un
tabel unic cu date din mai multe tabele legate între ele.
Pentru a crea o interogare de tip Make Table se parcurg următorii paşi:
1. se crează o interogare în Design View;
2. se selectează sursa datelor (din fereastra Show Table, dublu-clic pe
numele tabelelor, acestea fiind legate între ele), apoi se închide fereastra
Show Table;
3. se selectează câmpurile dorite, se ordonează datele, se adăugă condiţii;
4. se verifică trecând în Datasheet View rezultatul dorit, apoi se revine în
Design View;
5. se transformă interogarea de selecţie într-una de acţiune selectându-se
butonul Make Table de pe panglică. În fereastra Make Table se va
tasta numele noului tabel care va fi creat – figura 19;
6. se va salva interogarea:
7. se execută interogarea prin apăsarea butonului Run de pe panglică.
Observaţie: Dacă se doreşte deschiderea interogării pentru modificare, se apelează meniul contextual ataşat interogării din panoul de navigare, apoi se
alege Design View. De fiecare dată când interogarea este apelată, tabela este
rescrisă.
121
Fig. 19 – Interogare de tip Make Table
Se observă că icoana asociată interogării de tip Make Table este diferită faţă de
cea asociată interogărilor de selecţie.
5.4.3.2 Interogări pentru actualizarea datelor (UPDATE)
Interogările care permit actualizarea datelor sunt folosite pentru a efectua
anumite calcule asupra unor câmpuri din tabele (de exemplu, se măreşte preţul
pâinii cu 2%). Pentru a crea o interogarea de tip Update se parcurg următorii
paşi:
1. se crează o interogare în Design View;
2. se selectează sursa datelor (din fereastra Show Table, dublu-clic pe
numele tabelelor, acestea fiind legate între ele), apoi se închide fereastra
Show Table;
3. se selectează câmpul a cărui valoare trebuie modificată şi cel ce
limitează modificarea la anumite înregistrări (în acest caz, câmpul
denumirea produsului pe care se va seta condiţia pe linia Criteria
(=‟paine‟, şi câmpul pret, căruia i se va modifica valoarea în urma
interogării);
4. se transformă interogarea de selecţie într-una de acţiune selectându-se
butonul Update de pe panglică. În fereastra QBE va apare o nouă linie
numită Update To. Pe acea linie, sub pret se va scrie formula de calcul:
[pret]+[pret]*2/100;
5. se verifică trecând în Datasheet View rezultatul dorit, apoi se revine în
Design View;
6. se salvează interogarea;
7. se execută interogarea prin apăsarea butonului Run de pe panglică.
122
Se observă că icoana asociată interogării de tip Update este diferită faţă de cea
asociată interogărilor de selecţie şi de cea a interogării de tip Make Table.
5.4.3.3 Interogări pentru adăugarea datelor din alte tabele (APPEND)
Interogările de acest tip permit adăugarea unor înregistrări din alte tabele care
au în componenţă câmpuri de acelaşi tip.
Pentru a crea o interogarea de tip Append se parcurg următorii paşi:
1. se crează o interogare în Design View;
2. se selectează sursa datelor – tabelul sursă, de unde se doreşte transferul
datelor în celălalt tabel (din fereastra Show Table, dublu-clic pe numele
tabelelor, acestea fiind legate între ele), apoi se închide fereastra Show
Table;
3. se selectează câmpurile care se doresc a fi trimise într-o altă tabelă. În
acea tabelă vor trebui să existe câmpuri de acelaşi tip cu cele selectate
la acest pas;
4. se selectează o ordine de sortare a înregistrărilor şi/sau se completează
liniile Criteria şi Or (dacă este cazul);
5. se verifică trecând în Datasheet View rezultatul dorit, apoi se revine în
Design View;
6. se transformă interogarea de selecţie într-una de acţiune selectându-se
butonul Append To. Se selectează numele tabelei destinaţie. Se
observă adăugarea unei noi linii în fereastra QBE, cu numele Append
To. Dacă numele câmpurilor din cele două tabele diferă, celula
corespunzătoare din tabela destinaţie, de pe linia Append to, va rămâne
necompletată. Ea poate fi completată utilizându-se caseta combinată,
alegând numele câmpului dorit din tabela destinaţie;
7. se salvează interogarea;
8. se execută interogarea prin apăsarea butonului Run de pe panglică.
Aceeaşi observaţie este valabilă ca şi la interogarea de tip Update. Totodată,
icoana asociată acestui tip de interogare este diferită de celelalte.
Observaţie: Dacă se doreşte deschiderea interogării pentru modificare, se
apelează meniul contextual ataşat interogării din panoul de navigare, apoi se alege Design View. De fiecare dată când interogarea este apelată, valoarea
câmpului este modificată.
123
5.4.3.4 Interogări pentru ştergerea înregistrărilor (DELETE)
Acest tip de interogare se utilizează pentru a şterge automat anumite înregistrări
din una sau mai multe tabele. Pentru a crea o interogarea de tip Delete se
parcurg următorii paşi:
1. se crează o interogare în Design View;
2. se selectează sursa datelor – tabelul sursă, de unde se doreşte ştergerea
datelor (din fereastra Show Table, dublu-clic pe numele tabelelor,
acestea fiind legate între ele), apoi se închide fereastra Show Table;
3. se selectează câmpul/câmpurile care conţin valorile care compun
condiţia de ştergere;
4. se completează liniile Criteria şi Or (dacă este cazul – în caz contrar
vor fi şterse toate înregistrările din tabela sau tabelele respective);
5. se transformă interogarea de selecţie într-una de acţiune selectându-se
butonul Delete. Pe linia Delete va apare clauza Where, care permite
construirea condiţiei de ştergere ;
6. se verifică trecând în Datasheet View rezultatul dorit, apoi se revine în
Design View;
7. se salvează interogarea;
8. se execută interogarea prin apăsarea butonului Run de pe panglică.
Aceeaşi observaţie este valabilă ca şi la interogarea de tip Append. Icoana
asociată acestui tip de interogare este diferită de celelalte.
5.5 Obiecte Forms
Formularul este un obiect al bazei de date care permite vizualizarea,
modificarea sau introducerea a noi informaţii în tabela pe baza căruia a fost
creat.
Pe un formular pot fi adăugate următoarele tipuri de controale:
legate: sunt create pe baza unui tabel, a mai multor tabele sau a unei
interogări, permit vizualizarea înregistărilor, actualizarea valorilor
câmpurilor sau adăugarea unor câmpuri calculate;
Observaţie: În cazul ştergerii înregistrărilor din mai multe tabele, aceasta poate
fi împiedicată datorită setării regulilor de integritate referenţială (dacă în fereastra Relationship, fiind selectată legătura dintre tabele, este selectată
caseta Enforce Referential Integrity iar Cascade Delete Related Records nu
este bifată).
124
nelegate: destinate creării unui meniu, afişării unor mesaje, informaţii
despre sistem, etc.
Formularele pot fi create utilizând butoanele de pe panglică. Vom prezenta în
continuare crearea formularelor cu ajutorul butoanelor Form, Form Wizard şi
Design Form.
5.5.1 Formulare create cu ajutorul butonului Form
Pentru a crea un formular, se selectează din panoul de navigare numele tabelei
sau interogării care va conţine sursa datelor.
Dacă tabelul este tabel de referinţă pentru mai multe alte tabele sau este tabel
referit de alte tabele (copil) – atunci Access va crea automat un formular cu
layout-ul Columnar (este afişat conţinutul unei singure înregistrări la un
moment dat) – figura 20.
Pentru a vizualiza toate înregistrările se poate utiliza bara de navigare Record
aflată în partea de jos a formularului, utilizându-se butoanele Next Record
(trecerea la următoarea înregistrare), Previous Record (trecerea la înregistrarea
anterioară), First Record (trecerea la prima înregistrare), Last Record (trecerea
la ultima înregistrare), New (Blank) Record (adăugarea unei noi înregistrări) şi
Search.
Fig. 20 – Formularul Furnizori
Dacă tabelul este tabel de referinţă pentru un singur tabel, atunci Access va crea
automat un formular cu subformular, afişând în subformular doar acele
înregistrări din tabela referită care verifică condiţia ca valoarea cheie străină
este egală cu valoarea afişată în câmpul cheie primară din tabela de referinţă
afişată în formular. Pentru tabela de referinţă layout-ul formularului este
Columnar (este afişată o singură înregistrare la un moment dat), iar pentru sub-
125
formular layout-ul este Tabular (sunt afişate toate înregistrările care verifică
condiţia de legătură) – figura 21. Totodată câmpul cheie străină (din tabelul
referit) este ascuns (nu este necesară afişarea aceluiaşi câmp de mai multe ori în
cadrul unui formular).
Se observă că pentru fiecare formular apare câte o bară de navigare Record.
Cea mai de jos este pentru datele din tabelul de referinţă (părinte), cea din
interior va fi pentru datele din tabelul referit (copil). Pentru a naviga prin
înregistrări se utilizeză bara corespunzătoarelor formularului creat pentru tabelul
de referinţă.
Fig. 21. Formular cu sub-formular
Modul de afişare afişat implicit va fi Form View. Dacă se doreşte, se poate
trece la Design View pentru a modifica proprietăţile controalelor de pe formular
cu ajutorul butonului View de pe panglică.
5.5.2 Formulare create cu ajutorul butonului Form Wizard
Access 2007 pune la dispoziţia utilizatorilor un asistent care permite crearea
rapidă a înregistrărilor urmând anumiţi paşi. Pentru a utiliza butonul Form
Wizard este necesară selectarea butonului More forms… de pe panglică,
opţiunea de meniu Create – figura 22.
126
Fig. 22 – Selectarea butonului Form Wizard
Pentru a crea un formular utilizând Form Wizard trebuie parcurşi următorii paşi:
se selectează sursa datelor – numele tabelului sau a interogării pe baza
căruia se doreşte crearea formularului şi a câmpurilor care se doreşte să
apară pe formular – figura 23, apoi se apasă butonul Next;
Fig. 23 – Selectarea sursei formularului
se selectează layout-ul formei (modul în care sunt aranjate înregistrările
pe formulare; Columnar şi Justified afişează o singură înregistrare la
un moment dat, Tabular şi Datasheet afişează toate înregistrările la un
moment dat) – figura 24, apoi se apasă butonul Next;
Fig. 24 – Alegerea Layout-ului formularului
127
se alege stilul (combinaţiile de culori şi obiectele grafice de pe
formular) – figura 25, apoi se apasă butonul Next;
Fig. 25 – Alegerea stilului formularului
se alege un titlu pentru formular şi modul de vizualizare al acestuia, în
cazul de faţă deschiderea în modul de vizualizare Form View (Open
the form to view or enter information) – figura 26, apoi se apasă
butonul Finish.
Fig. 26 – Crearea unui titlu şi deschiderea formularului în modul Form View
Formularul astfel creat va arăta ca în figura 27.
Fig. 27 – Formularul Furnizori1 în Form View
128
Orice formular conţine următoarele zone – figura 28:
Form Header – antetul formularului, utilizat pentru afişarea unui titlu,
sigla unei companii, data întocmirii;
Detail – zona în care sunt amplasate controalele corespunzătoare
înregistrărilor din tabelul sau interogarea sursă;
Form Footer: subsolul formularului, utilizat pentru comentarii,
semnături, numărul paginii, butoane de comandă.
Fig. 28 – Formularul Furnizori1 în Design View
Pentru a activa zonele Form Header/Footer se apelează meniul contextual al
formularului, selectându-se opţiunea cu acelaşi nume.
5.5.3 Formulare create cu ajutorul butonului Form Design
Pentru a creea un formular cu ajutorul butonului Form Design se parcurg
următorii paşi:
1. se selectează butonul Form Design de pe panglică, opţiunea de meniu
Create – figura 29;
Fig. 29 – Un formular gol în Design View
129
2. de pe panglică, opţiunea de meniu Design, se selectează butonul
Property Sheet . În fereastra cu acelaşi nume, în cadrul casetei
combinate Selection Type se alege obiectul Form. De pe pagina All,
apelând săgeata din dreptul casetei Record Source numele tabelei pe
baza căreia se va creea formularul: de exemplu furnizori – figura 30;
Fig. 30 – Selectarea sursei formularului
3. se selectează butonul Add Existing Fields iar din fereastra Field List
se execută dublu-clic pe numele câmpurilor care se doreşte să apară pe
formular – figura 31. Acestea vor apărea pe formular în zona de Detail
a formularului;
Fig. 31 – Adăugarea controalelor pe formular
4. se salvează formularul – butonul Save de lângă butonul Office;
5. pentru a vizualiza înregistrările se trece în modul de vizualizare Form
View (folosind butonul View de pe panglică) – figura 32.
Fig. 32 – Formular în modul de vizualizare Form View
Pe formulare pot fi plasate diverse obiecte care poartă numele de controale.
130
Dintre cele mai des utilizate controale amintim:
Label (etichete) – control cu un conţinut fix, corespunzător
constantelor, utilizat pentru afişarea unor comentarii, titluri, mesaje.
Access generează automat câte o etichetă pentru majoritatea
controalelor definite de utilizator. De obicei ele sunt plasate în stânga
controlului pe care îl însoţeşte. Toate etichetele vor fi salvate cu nume
care încep cu prefixul de 3 litere lbl (label). Pentru fiecare control de tip
etichetă se vor modifica proprietăţile Name şi Caption. Proprietatea
Caption controlează textul care va apare pe formular – figura 33.
Pentru a crea o etichetă, se selectează butonul de pe panglică,
opţiunea de meniu Design. În fereastra Property Sheet se modifică
proprietatea Name: lblTitluFurnizor, Caption: Lista furnizorilor;
Fig. 33 – Controale de tip etichetă
Text-box (casete de text) – sunt controale cu conţinut variabil,
corespunzătoare câmpurilor dintr-o tabelă sau interogare, sau
variabilelor. Conţinutul acestora se modifică în funcţie de înregistrarea
curentă – figura 34. Pentru toate casetele de text se modifică
proprietatea Name în fereastra Property Sheet. Prefixul pentru casetele
de text este txt (text). Pentru casetele de text legate de un câmp,
proprietatea Control Source apare automat completată în cazul
formularului creat după paşii prezentaţi anterior. De exemplu, pentru
caseta de text Nr_furn se va modifica proprietatea Name: txtNr_furn,
proprietatea Control Source va fi automat completată cu valoarea
Furnizori.Nr_furn (numele tabelei sursă urmată de punct apoi numele
câmpului de unde provin datele). Dacă se doreşte crearea unei casete de
text, se selectează de pe panglică butonul . Vor fi create automat
atât o casetă de text cât şi o etichetă care va explicita valorile afişate în
caseta de text. Pentru etichetă se vor modifica proprietăţile Name şi
131
Caption, iar pentru caseta de text se vor modifica proprietăţile Name şi
Control Source (dacă nu este deja completat);
Fig. 34 – Controale de tip casete de text
Button (butoane de comandă) – serveşte la declanşarea unor acţiuni
predefinite sau a unor acţiuni definite prin intermediul unor proceduri
Visual Basic Application. În capitolul următor este prezentată o
modalitate de a crea butoane de comandă fără ajutorul asistentului.
Vom prezenta în continuare crearea unui buton cu ajutorul asistentului.
Pentru a crea un buton fără a cunoaşte comenzi Visual Basic Application este
necesară selectarea butonului Use Control Wizards de pe panglică
. Se selectează butonul Button de pe panglică apoi se
execută un clic în zona Form Footer – figura 35.
La primul pas se alege categoria de acţiuni (navigare prin înregistrări, operaţii
cu înregistrări, operaţii cu formulare, operaţii cu rapoarte, închiderea aplicaţiei
şi diverse – tipărirea tabelelor, execuţia unei interogări, execuţia unei
macrocomenzi, etc).
Fig. 35 – Crearea unui buton de comandă cu ajutorul asistentului
După ce s-a ales categoria, se alege acţiunea din partea dreaptă. În cazul de faţă,
s-au ales operaţiile cu formulare pentru că se doreşte crearea unui buton care să
închidă forma, de aceea a fost selectată acţiunea Close Form. Se trece cu Next
la pasul următor.
132
Se va alege opţiunea Text specificându-se textul care se doreşte să apară pe
buton: Închidere – figura 36, apoi se apasă butonul Next.
Fig. 36 – Specificarea textului care va apare pe buton
În cadrul ultimei ferestre se specifică numele controlului. Butoanele de
comandă au prefixul cmd, deci numele controlului va fi cmdInchidere – figura
37. Pentru a finaliza crearea butonului se apasă selectează opţiunea Finish.
Fig. 37 – Denumirea controlului de tip buton de comandă
Pentru a încerca butonul trebuie selectat modul de vizualizare Form View –
figura 38.
Fig. 38 – Butonul Inchidere
În mod similar pot fi create multe alte butoane de comandă pentru a automatiza
baza de date.
133
Pe un formular pot fi plasate controale care să afişeze valori calculate. Pentru a
crea un control calculat, se parcurg următorii paşi:
1. se selectează butonul Text box de pe panglică, apoi execută clic în zona
Detail, sub controalele existente;
2. se modifică proprietăţile Name şi Caption ale etichetei;
3. se modifică proprietatea Name a casetei de text;
4. în cadrul proprietăţii Control Source se tastează formula de calcul,
începând cu semnul =. Numele câmpurilor sunt scrise între paranteze
drepte, de exemplu: =[valoare fara TVA]*1,24.
5.5.4 Formulare cu sub-formulare
Crearea unui formular cu subformular permite actualizarea mai multor tabele
prin intermediul unui singur obiect. Subformularele sunt create pentru tabelele
referite din cadrul unei relaţii de tip one-to-many. Formularul principal are ca
sursă tabelul de referinţă, reprezentând partea de „one” (unu). Pentru acest
formular se va utiliza un layout de tip Columnar sau Justified (permite
afişarea unei singure înregistrări). Sursa subformular este tabelul referit,
reprezentând partea „many” (mai mulţi). Subformularul va fi construit pe baza
unui layout de tip Tabular sau Datasheet (sunt afişate toate înregistrările).
Crearea unui formular cu subformular presupune înglobarea formularului
„many” în formularul „one”.
Pentru a crea un formular cu subformular se parcurg următorii paşi:
1. se crează un formular utilizându-se Form Wizard pentru tabela de
referinţă, pe un layout de tip Columnar. Se salvează formularul.
Formularul rămâne deschis în Design View;
2. se crează un formular utilizându-se Form Wizard pentru tabela referită
(copil), pe un layout de tip Tabular. Se salveză formularul şi se
închide;
3. în primul formular, se extinde zona Detail. Din panoul de navigare se
alege numele formularului corespunzător tabelului referit şi se
depozitează pe formular în zona Detail, sub celelalte controale. Se
salvează formularul utilizându-se butonul Office, opţiunea Save as,
Save object as, cu numele celor două formulare care compun
formularul cu subformular (de exemplu FurnizoriFacturi).
134
5.6 Obiecte Reports
Raportul este un obiect al bazei de date care permite vizualizarea informaţiilor
pe ecran sau trimiterea acestora la imprimantă. Raportul poate fi creat fie pe
baza unui tabel, fie pe baza unei interogări.
Un obiect de tip report poate conţine următoarele zone:
Report Header/Footer – zona de antet şi subsol ale raportului, ele apar
o singură dată la începutul, respectiv finalul raportului;
Page Header/Footer – zona de antet şi subsol ale fiecărei pagini a
raportului;
Group Header/Footer – zona de antet şi subsol al
câmpului/câmpurilor după care se realizează o grupare;
Detail – se afişează pentru fiecare înregistrare în parte;
Subrapoarte – sunt obiecte de tip raport conţinute în cadrul raportului
părinte;
Controale – obiecte care pot fi plasate în cadrul raportului.
Varianta cea mai simplă de creare a rapoartelor este Report Wizard. Dacă se
doreşte afişarea datelor din mai multe tabele, poate fi creată o nouă tabelă pe
baza unei interogări, raportul fiind construit pe baza acesteia. Dacă se doreşte
afişarea unor câmpuri calculate, acestea pot fi create cu ajutorul unei interogări,
raportul fiind creat pe baza interogării.
Raportul creat cu ajutorul instrumentului Report Wizard poate fi deschis în
modul Design View şi modificat prin adăugarea unui nivel de grupare, a unei
sortari sau a unor câmpuri calculate.
Pentru a construi un raport în Report Wizard se parcurg următorii paşi:
1. se selectează opţiunea de meniu Create, butonul Report Wizard;
2. din caseta Tables/Queries se alege sursa raportului (tabelul sau
interogarea), iar cu ajutorul săgeţilor din mijlocul ferestrei se selectează
câmpurile care se doresc a fi afişate în raport, ele apărând în fereastra
Selected Fields, apoi se apasă butonul Next – figura 39;
135
Fig. 39 – Selectarea sursei raportului
3. Se pot adăuga unul sau mai multe niveluri de grupare selectând numele
câmpului din partea din stânga. Se folosesc butoanele cu săgeţi pentru a
selecta câmpul/câmpurile ca nivel de grupare. Pot fi adăugate până la 10
niveluri de grupare – figura 40.
Fig. 40 – Adăugarea unor criterii de grupare
Dacă se doresc grupări mai speciale, se poate selecta butonul Grouping
Options. În funcţie de tipul câmpului selectat pot fi alese intervale de
grupare, de exemplu în cazul unui câmp de tip Text – grupare după prima
literă, după primele 2 litere, etc – figura 41. Pentru a trece la pasul următor
se apasă butonul Next;
Fig. 41 – Opţiuni de grupare
136
4. se poate stabili o ordine de afişare a înregistrărilor în cadrul raportului,
sortând până la 4 câmpuri simultan – figura 42, apoi se apasă butonul
Next – figura;
Fig. 42 – Opţiuni de ordonare
5. Se pot alege diverse modalităţi de aranjare a datelor (Stepped, Block
sau Outline) şi se poate seta orientarea paginii (Portrait – pe verticală
sau Landscape – pe orizontală), apoi se apasă butonul Next – figura
43;
Fig. 43 – Opţiuni legate de formatare
6. se poate alege un stil dintr-o listă cu stiluri disponibile, fiind vizibil un
Preview al acestuia în partea din stânga al ferestrei, apoi se apasă Next
– figura 44;
Fig. 44 – Alegerea unui stil
137
7. la ultimul pas se alege titlul raportului şi vizualizarea acestuia în modul
Preview – figura 45, apoi se apasă butonul Finish.
Fig. 45 – Adăugarea unui titlu
Raportul va fi afişat în modul Print Preview – figura 46. Pentru a reveni la
modul de Design, se apasă butonul Close Print Preview de pe panglică.
Fig 47 – Raport în modul Print Preview
Raportul în modul Design View seamănă cu un obiect de tip formular în Design
View – figura 48.
138
Fig. 48 – Raport în Design View
Pentru câmpurile numerice care conţin valori multiple în cadrul aceluiaşi grup,
la pasul 4 se va afişa un buton în plus, denumit Summary Options – figura 49.
Fig. 49 – Butonul Summary Options
Dacă acesta este selectat, pune la dispoziţia utilizatorilor funcţii totalizatoare:
SUM, MIN, MAX şi AVG – figura 50.
Fig. 50 – Fereastra Summary Options
Se poate selecta una din opţiunile – Detail and Summary (vor fi afişate
subtotaluri la nivelul fiecărui grup şi la nivel de raport) sau Summary Only
(doar subtotal la nivel de grup) – figura 51.
139
Fig. 51 – Raport cu grupare şi subtotaluri la nivel de grup şi raport
Pe orice raport pot fi create casete de text care pot fi calculate după modelul
prezentat în paragraful 5.5.3. Pentru a adăuga o funcţie totalizatoare (de
exemplu, calcularea valorii totale a tuturor facturilor, în zona Report Footer se
va adăuga o casetă de text. Se vor modifica proprietăţile Name şi Caption
corespunzătoare etichetei. Se va modifica proprietatea Name asociată casetei de
text. În cadrul proprietăţii Control Source asociată casetei de text se va tasta
formula =SUM([cantitate]*[pret]*1,24)). Din cadrul proprietăţii Format
asociată casetei de text se va alege opţiunea Currency, pentru afişarea
simbolului valutar.
5.7 Obiecte Macros
Obiectele de tip Macro sunt un instrument util atunci când se doreşte execuţia
unor acţiuni şi evitarea programării. Ele automatizează operaţiunile din cadrul
unei baze de date Access. Obiectele de tip Macro pot fi încorporate în cadrul
unui formular, depinzând de obiectul în care este plasat, sau pot fi autonome,
fiind apelabile de oriunde.
În cadrul unui obiect de tip Macro pot fi selectate mai multe acţiuni, acestea
fiind alese dintr-o listă şi executate în ordinea în care au fost create.
O macrocomandă se execută folosindu-se butonul Run (ca şi în cazul
interogărilor de acţiune).
Cu ajutorul macrocomenzilor pot fi create meniuri personalizate pentru a
înlocui panglica (Ribbon-ul).
Pentru a crea o macrocomandă se selectează opţiunea de meniu Create, iar din
zona Other, Macro. De exemplu, dacă se doreşte crearea unei macrocomenzi
140
care să deschidă o interogarea în mod Read-Only se vor parcurge următorii
paşi:
în coloana Action se alege dintr-o listă de acţiuni predefinite, Open
Query;
în partea de jos a ecranului se selectează Query Name (numele
interogării);
se selectează modul de vizualizare în care va fi deschisă interogarea (în
cazul de faţă Datasheet);
în caseta Data Mode se alege Read-Only.
Macrocomanda va fi salvată cu numele Deschidere Interogare Furniz şi poate
fi executată apăsând butonul Run – figura 52.
Fig. 52 – Crearea unei macrocomenzi
De regulă macrocomenzile sunt ataşate fie unei opţiuni de meniu fie unui buton
de comandă plasat pe un formular.
141
5.8 Obiecte Modules
Obiectele de tip Module sunt module de program scrise în Visual Basic
Application. Ne vom ocupa de module de cod în capitolul următor, ca suport al
execuţiei comenzilor SQL (Structured Query Language). Utilizarea limbajului
de programare Visual Basic Application nu face obiectul prezentului curs.
5.9 Concluzii
Microsoft Access oferă utilizatorilor un mediu vizual cu o interfaţă grafică
prietenoasă, capabil de a dezvolta aplicaţii complexe, fără a avea nevoie de
cunoştinţe de programare. Faţă de versiunile anterioare, Access conţine o serie
de îmbunătăţiri (sunt puse la dispoziţia utilizatorului o serie de şabloane, oferă
suport pentru introducerea datei calendaristice, apariţia unui nou tip de câmp –
Attachment, pentru stocarea mai multor obiecte create cu alte aplicaţii, etc).
Noua interfaţă Microsoft Access 2007 este una unitară în pachetul Microsoft
Office, utilizatorul putând regăsi cu uşurinţă comenzile uzuale.
5.10 Rezumatul capitolului
Gestionarea obiectelor Access se realizează într-o manieră centralizată prin
înglobarea lor în baza de date. Sunt disponibile interfeţe simple pentru
construirea structurii bazei de date (tabelele, relaţiile dintre ele şi dicţionarul de
date), crearea unor formulare pentru inserarea datelor în tabele sau actualizarea
datelor din tabele, automatizarea acestora cu ajutorul butoanelor de comandă,
crearea unor panouri de comandă care vor gestiona operaţiile efectuate cu baza
de date, selecţia datelor din una sau mai multe tabele, după anumite criterii,
actualizarea tabelelor prin interogări care permit crearea unor noi tabele,
inserarea de noi înregistrări, modificarea sau ştergerea automată a acestora în
funcţie de anumite criterii, crearea macrocomenzilor pentru anumite acţiuni
uzuale sau crearea unor secvenţe de cod şi afişarea datelor sau trimiterea
acestora către imprimantă.
Mediul de lucru Access se bazează pe utilizarea ferestrelor, oferindu-se
posibilitatea vizualizării într-o fereastră cu mai multe tab-uri. Panoul de
navigarea grupează toate obiectele bazei de date.
142
5.11 Întrebări de autoevaluare din partea teoretică
1. Specificaţi caracteristicile SGBD-ului MS Access 2007.
2. Specificaţi care sunt cazurile în care se utilizează Microsoft Access.
3. Specificaţi care sunt cazurile în care se utilizează Microsoft Excel.
4. Detaliaţi opţiunile de pe bara de meniu MS Access 2007.
5. Detaliaţi cinci proprietăţi importante care pot fi setate utilizându-se
butonul Access Options.
6. Definiţi obiectul Table din Acces. Daţi exemple de tabele.
7. Definiţi conceptele de câmp şi înregistrare. Daţi exemple.
8. Definiţi conceptele de cheie primară şi chei străine. Daţi exemple.
9. Definiţi conceptul de redundanţă necesară.
10. Explicaţi regulile de integritate referenţială.
11. Detaliaţi tipurile de legături dintre tabele în Access. Daţi exemple la
fiecare tip de legătură.
12. Detaliaţi operaţiile care pot fi efectuate cu câmpurile unei tabele.
13. Daţi exemple de completare a proprietăţii Input Mask.
14. Daţi exemple de reguli de validare (Validation Rule).
15. Definiţi obiectul Query din Access. Daţi exemplu de interogare de
selecţie.
16. Detaliaţi operatorii Like, Between şi In.
17. Daţi un exemplu de interogare care să ilustreze utilizarea pentru funcţiei
IIF.
18. Definiţi interogarea cu parametru. Exemplu.
19. Daţi exemple pentru fiecare tip de interogare de acţiune.
20. Detaliaţi modul de creare a unui formular cu subformular.
21. Definiţi controalele de tip Label, Text Box şi Button. Exemple.
22. Definiţi obiectul Report din Access.
23. Definiţi obiectul Macros din Access.
24. Definiţi obiectul Modules din Access.
143
5.12 Exemple
5.12.1 Problemă rezolvată – Tabelă creată în Datasheet View
Să se creeze o bază de date cu numele Exemplul 1 care să conţină un tabel cu
numele Studenţi. Acesta va avea structura ID, nume, prenume, an, serie, grupa,
data naşterii, adresa, căsătorit, email, fotografie. Se vor introduce 3 studenţi în
tabelă.
Rezolvare
Se va crea o bază de date cu numele Exemplul 1, salvată pe Desktop. Odată cu
crearea bazei de date, Access crează automat o tabelă cu numele care va conţine
un câmp ID (identificator) de tip Autonumber, care va fi cheia primară a
tabelei.
Figura 53. Crearea unei tabele
Pentru a salva tabela şi a modifica numele acesteia, se apasă butonul Save
aflat pe bara panglică – figura 53.
Construirea a structurii tabelei va continua cu adăugarea unui nou câmp (o nouă
coloană) executându-se dublu-clic pe linia cu ID, celula în care apare Add New
Field – figura 53. După tastarea numelui câmpului, se apasă Enter, trecerea
fiind făcută la următoarea coloană. După ce s-a editat capul de tabel se trece la
introducerea datelor în tabel.
Câmpul ID fiind de tip Autonumber, acesta va fi completat automat odată cu
selectarea primei litere din numele studentului. Se completează toate câmpurile
până la fotografie. Se observă faptul că nu există posibilitatea completării
acestui câmp. Pentru aceasta trebuie modificat tipul. Pentru aceasta se alege de
pe bara de meniuri opţiunea de meniu Datasheet, caseta Data Type şi se
selectează OLE Object.
144
Fig. 54. Meniul Datasheet, caseta Data type
Se observă faptul că valoarea din coloana anul, faţă de valorile din coloanele
seria şi grupa, este aliniată la stânga, faţă de celelalte două valori care sunt
aliniate la dreapta. Microsoft Access 2007 păstrează acelaşi mod de aliniere ca
şi Microsoft Excel 2007, şirurile de caractere sunt aliniate la stânga, iar
numerele aliniate la dreapta. Deci câmpul an nu este recunoscut ca fiind de tipul
potrivit (Number). De aceea se selectează coloana an şi se procedează în acelaşi
mod ca în cazul fotografiei, selectând tipul de date Number. Microsoft Access
afişează un mesaj de avertizare atunci când tipul de date este schimbat, unele
valori putând fi pierdute – figura 55.
Fig. 55 – Mesaj de avertizare la schimbarea tipului de date
Se poate selecta fiecare câmp pentru a se verifica formatul dorit. În cazul în care
valoarea care a fost introdusă nu corespunde cu valorile care trebuie introduse în
cadrul acestui câmp, valoarea existentă este pierdută.
În cazul câmpului data naşterii acesta trebuie să fie de tip Date/time, adresa de
tip memo (texte mai mari de 255 de caractere), casatorit un câmp de tip Yes/No.
Formatul clasic de afişare fiind un check-box (casetă de opţiune) care poate fi
bifat sau nu, corespunzător celor două valori posibile.
Fig. 56 – Valorile câmpului de tip Yes/No
Câmpul e-mail trebuie să fie de tip Hyperlink.
145
Pentru a introduce o fotografie în câmpul omonim, se selectează celula
corespunzătoare, se selectează meniul contextual, apoi opţiunea Insert Object.
Fig. 57 – Introducerea unui obiect într-un câmp de tip OLE Object
Sunt disponibile două opţiuni – Create New sau Create from File. În acest caz
vom presupune faptul că fotografia există deja, deci alegem a doua opţiune.
Tehnologia OLE (Object Linking and Embedding) – legare şi încorporare de
obiecte, permite înglobarea obiectului în tabel, deci în baza de date, sau, dacă se
selectează opţiunea Link, crearea unei legături către obiectul respectiv, fără ca
acesta să fie încorporat în tabel.
Fig. 58 – Alegerea unei fotografii
Câmpul fotografie va fi completat cu textul Package. La execuţia unui dublu-
clic, fotografia va fi deschisă pentru a fi vizualizată cu softul predefinit pentru
vizualizarea fotografiilor.
Se introduc încă 2 studenţi. Dacă este necesar, se poate utiliza bara orizontală de
derulare (Scroll) aflată în partea de jos a ecranului – figura 59.
Fig. 59 – Bara de derulare orizontală
146
Modul de vizualizare utilizat se observă de pe bara de stare – Datasheet View.
Pentru a trece de la un mod de vizualizare la altul se pot utiliza butoanele de pe
bara de stare: Datasheet View, PivotTable View, PivotChart View sau
Design View. Modul de vizualizare Datasheet View se utilizează în general
pentru a vizualiza datele din tabelă, iar modul Design View se utilizează pentru
a modifica proprietăţile structurii tabelei. Opţiunile PivotTable View şi
PivotChart View permit crearea unui tabel, respectiv a unui grafic pivot.
În modul de vizualizare Datasheet View, bara de unelte Record permite
navigarea prin înregistrări. Cu ajutorul acesteia se permit în ordine: selectarea
primei înregistrări, trecerea la înregistrarea anterioară, afişarea numărului
înregistrării curente din numărul total de înregistrări, trecerea la următoarea
înregistrare, selectarea ultimei înregistrări, crearea unei noi înregistrări,
dezactivarea unui filtru (dacă există activat un criteriu de filtrare) precum şi
căutarea unei valori în tabel – figura 60. De reţinut faptul că la un moment dat
suntem poziţionaţi pe o singură înregistrare din tabel.
Fig. 60 – Bara de navigare Records – fără filtrare
Pentru a şterge o înregistrare se selectează antentul de linie şi se apasă tasta
Delete de pe tastatură. În cazul exemplificat în figura 61 s-au selectat 2
înregistrări pentru ştergere.
Fig. 61 – Mesajul de atenţionare afişat la ştergerea a două înregistrări
Pentru a şterge un câmp se poziţionează cursorul pe antetul de coloană (unde
este afişat numele cîmpului) şi se selectează din meniul contextual opţiunea
Delete Column. Sistemul afişează un mesaj de avertizare – figura 62.
Fig. 62 – Mesaj de avertizare la ştergerea unui câmp
147
Tabelul va fi automat deschis în modul de vizualizare Datasheet View. Pentru a
trece la modul de vizualizare special pentru modificarea proprietăţilor tabelului
se selectează butonul Design View de pe bara de stare – figura 63.
Fig. 63 – Trecerea la modul de vizualizare Design View.
Modul de vizualizare Design View permite setarea unor caracteristici
(proprietăţi) nivel de fiecare câmp în parte – figura 64.
Fig. 64 – Modul de vizualizare Design View
Modul uzual de lucru pentru crearea unei tabele este în modul de vizualizare
Design View, acesta permiţând setarea unor valori implicite, reguli de validare,
moduri de afişare a datelor în câmp, etc.
148
5.12.2 Problemă rezolvată – Tabele create în Design View
Se doreşte informatizarea activităţii unei firme. Furnizorii sunt identificaţi prin
cod furnizor, denumire furnizor (numele şi prenumele furnizorului), localitatea,
adresa, email, banca furnizor şi cont furnizor. Despre produse se cunosc cod
produs, denumire produs, unitate de măsură, stoc, preţ unitar. Produsele sunt
depozitate în magazii, pentru care se cunosc cod magazie, denumire magazie,
gestionar (numele persoanei care are în gestiune depozitul respectiv).
Operaţiunile se desfăşoară pe baza unor facturi, care trebuie să conţină numărul
facturii şi data facturii. Fiecare factură conţine detaliate liniile facturii şi anume
denumirea produsului, preţul unitar, cantitatea facturată, calculându-se
valoarea produsului (cu şi fără TVA) şi valoarea totală a facturii cu şi fără TVA.
Rezolvare
În urma analizei datelor şi a aplicării metodei matricii dependenţelor funcţionale
din capitolul anterior, se obţine următoarea schemă a bazei de date:
Fig. 65 – Fereastra Relationship
Primul pas este crearea bazei de date. Aceasta va purta numele Firme. Pentru a
crea baza de date, se deschide mediul de lucru Access, apoi se alege opţiunea
Blank Database. Pentru a alege locaţia în care va fi salvat fişierul se alege
icoana galbenă de folder, selectându-se Desktop-ul ca destinaţie, apoi se
tastează denumirea: Firme.
După crearea bazei de date se trece la analiza fiecărui tabel în parte şi alegerea
tipului de câmp cel mai potrivit datelor care vor fi salvate în acesta.
Este foarte importantă ordinea în care tabelele voi fi create. Pentru aceasta se
aleg tabelele de referinţă (tabelele părinte, cum ar fi Furnizori, Magazii,
Produse) urmând ca după crearea acestora să se creeze tabelele referite (Facturi,
ProduseFacturate, ProduseMagazii).
În momentul în care se crează baza de date, Access deschide automat un tabel
cu numele Table1.
Se va modifica tabelul Table1 în tabelul Furnizori. Pentru aceasta vom salva
tabelul cu numele Furnizori, apelând butonul Save de lângă butonul Office.
Pentru a adăuga câmpuri şi pentru a modifica proprietăţile acestora, se va trece
149
în modul de vizualizare Design View, fie folosind butonul View de pe panglică,
fie butonul cu acelaşi nume de pe bara de stare.
Se vor introduce următoarele câmpuri:
primul câmp îl vom modifica din ID în cod_f (codul furnizorului), vom
alege tipul de date Number, Field Size: Integer, şi Caption: cod
furnizor, Validation Rule: >0, Validation Text: “Introduceţi un număr
pozitiv”, Required: Yes;
pentru câmpul den_f (denumirea furnizorului) – tipul de dată Text,
Field Size: 30, Format: >, Caption: denumire furnizor, Required: Yes,
Allow Zero Length: No, Indexed: Yes (Duplicates OK);
localit (localitate) – de tip Text, Field Size: 30, Caption: localitate,
Default Value: Timisoara;
adresa – de tip Memo;
email – de tip Hyperlink;
banca – de tip Text, Field Size: 30, Format: >, Required: Yes, Allow
Zero Length: No;
cont (contul din bancă, IBAN) – de tip Text, Fields Size: 24, Input
Mask: "RO"99LLLL9999999999999999.
Fig. 66 – Butonul View
După ce toate câmpurile au fost create, se salvează tabela alegând butonul Save,
apoi se apasă săgeata de pe butonul View, de unde se alege Datasheet View –
figura 66, pentru a introduce datele a trei furnizori în tabelă – figura 67.
Fig. 67 – Tabela Furnizori în Datasheet View
150
După ce tabela a fost creată şi s-au introdus înregistrări în ea, aceasta va fi
închisă.
Pentru a crea o nouă tabelă, de pe bara de meniuri se alege opţiunea Create,
butonul Table Design. Pentru tabela Magazii se inserează următoarele
câmpuri:
cod_m (cod magazie) – Primary key, de tip Number, Field Size: Byte,
Caption: Cod magazie, Required: Yes;
den_m – de tip Text, Field Size: 15, Caption: Denumire magazie,
Indexed: Yes (Duplicates OK);
gest – de tip Text, Field Size: 30, Caption: Gestionar.
Se vor introduce 3 magazii, cu codurile magazinelor 111, 112 şi 113;
Fig. 67 – Tabela Magazii în Datasheet View
Pentru tabela Produse:
cod_p (codul produsului) – Primary key, de tip Number, Field Size:
Long Integer, Caption: Codul produsului, Required: Yes;
den_p (denumirea produsului) – tipul câmpului Text, Field Size:15,
Caption: Denumirea produsului;
um (unitate de măsură) – de tipul Lookup Wizard, apoi opţiunea – I
will type in the values that I want, în caseta Number of Columns nu se
modifică valoarea 1, iar în lista col1 vor fi tastate pe rând, una sub alta,
valorile dorite: kg, l, m, buc, selectând butonul Next, apoi Finish.
În tabela Produse se vor introduce 3 produse, cu codurile 11111, 111112 şi
111113 – figura 68.
Fig. 68 – Tabela Produse
151
Tabela ProduseMagazii:
cod_p (cod produs) – un câmp de tip Lookup Wizard – pentru care se
selectează opţiunea I want the lookup column to lookup the values in
a table or query, apoi se alege tabela Produse, apoi se selectează
butonul Next; se alege câmpul cod_p, apoi se apasă butonul Next –
figura 69. Ordonarea va fi făcută după acelaşi câmp cod_p, apoi se
alege butonul Next.
Fig. 69 – Crearea legăturii cu tabela Produse
În ecranul următor pot fi observate valorile introduse anterior în tabela
Produse, apoi se apasă butonul Next – figura 70.
Fig. 70 – Valorile introduse în câmpul cod_p din tabela Produse
La ultimul pas este posibilă modificarea numelui câmpului (acesta va fi
lăsat neschimbat) apoi se apasă butonul Finish;
Între cele două tabele (Produse(tabela părinte) şi ProduseMagazii (tabela copil)
va fi creată automat o relaţie. De aceea Access cere salvarea tabelei cu un nume
(ProduseMagazii). Datorită faptului că nu a fost creată nici o cheie primară,
sistemul sugerează crearea uneia. Se va alege No (cheia primară compusă va fi
creată după crearea câmpului cod_m).
cod_m (cod magazie) – un câmp pentru care se alege Lookup Wizard –
se selectează opţiunea I want the lookup column to lookup the values
152
in a table or query, apoi se alege tabela Magazii; selectăm câmpul
cod_m (cod magazie). Ca ordine de sortare se alege cod_m, se
vizualizează codurile magaziilor introduse în tabela Magazii, apoi se
lasă neschimbat numele câmpului şi se apasă Finish. Se cere din nou
salvarea tabele;
stoc (stocul disponibil în magazie) – de tip Number, Field Size: Long
Integer, Caption: Stoc produs, Required: Yes.
Pentru a crea o cheie primară compusă, se selectează utilizându-se pătratul gri
din faţa numelui câmpului ambele câmpuri cod_p şi cod_m şi se apasă butonul
Primary Key de pe panglică. Se salveză tabela şi se trece în modul de
vizualizare Datasheet View pentru a introduce date în tabelă.
Pentru ca ambele relaţii să fie de tipul one-to-many, se vor introduce minim 4
înregistrări, un produs fiind depozitat în două magazii (de exemplu 111113).
Fig. 71 – Tabela ProduseMagazii
Pentru tabela Facturi:
nr_f (numărul facturii) – Primary key, de tip Number, Field Size: Long
integer, Caption: Numarul facturii, Required: Yes;
data_f – de tip Date/Time, Caption: Data Facturii, Required: Yes,
Format: Short date, Default Value =Date();
cod_f (cod furnizor) – tipul de date Lookup Wizard, se crează o
legătură cu tabela Furnizori, câmpul cod_f, Caption: Cod furnizor.
Tabela Facturi este copilul tabelei Furnizori. Având 3 furnizori în tabela părinte,
vom introduce minim 4 facturi, codul furnizorului 1 repetându-se de 2 ori:
Fig. 72 – Tabela Facturi
153
Tabela ProduseFacturate:
nr_f (numărul facturii) – un câmp pentru care se alege Lookup Wizard,
se crează a legătură cu tabela Facturi, câmpul nr_f; Caption: Numarul
facturii. Se salvează tabela cu numele ProduseFacturate, iar la
întrebarea dacă se doreşte alegerea unei chei primare se alege No;
nr_crt (număr curent) – un câmp de tip Number, Field Size: Integer,
Caption: Numar curent;
cod_p (codul produsului) – un câmp pentru care se selectează Lookup
Wizard, se crează o legătură cu tabela Produse, pe baza câmpului
câmpul cod_p;
cantit – un câmp de tip Number, Field Size: Integer, Caption: Cantitate;
pret_u – un câmp de tip Currency, Caption: Pret unitar;
cotaTVA – un câmp de tip Number, Field Size: Single, Default Value:
0,24, Caption: Cota TVA.
Se selectează câmpurile nr_f şi nr_crt şi se crează o cheie primară compusă
apăsând butonul Primary Key de pe panglică.
Acest tabel fiind copilul tabelelor Produse şi Facturi, vom introduce 8
înregistrări:
Fig. 73 – Tabela ProduseFacturate
Pentru a verifica relaţiile şi a seta regulile de integritate referenţială, se
selectează butonul Relationships de pe panglică – figura 74.
Fig. 74 – Butonul Relationship
154
Pentru fiecare legătură în parte, se apelează meniul contextual, se alege opţiunea
Edit Relationships... Pentru a seta regulile de integritate referenţială se
selectează opţiunea Enforce Referential Integrity, bifând opţiunea Cascade
Update Related Field. Dacă se doreşte modificarea tipului de relaţie dintre cele
două tabele, se selectează butonul Join Type..., alegând una dintre cele trei
tipuri de relaţii (Left Join, Inner Join sau Right Join).
Fig. 75 – Fereastra Edit Relationships
Selectând pentru fiecare relaţie în parte opţiunile respective şi reordonând
tabele, se obţine următoarea situaţie:
Fig. 76 – Fereastra Relationships
5.12.3 Problemă rezolvată – Formulare şi controale
Să se creeze un folder pe Desktop cu numele şi prenumele dvs. În acesta, să se
creeze o bază de date cu numele Programari care să conţină informaţiile legate
despre pacienţi: un cod unic al pacientului, numele şi prenumele acestuia, data
naşterii, adresa, telefonul formatat de tipul 0722-456-768, seria şi numărul cărţii
de identitate – exact 2 litere şi 6 cifre. Pentru fiecare programare se cunoaşte
data programării – implicit data de azi, ora programării, doctorul la care se face
programarea şi suma de plată. Pentru fiecare doctor se cunoaşte numele
doctorului, adresa, numărul de telefon, titlul (rezident, primar, specialist) şi
155
specialitatea sa (cardiolog, ORL, etc). Să se introducă 3 înregistrări în tabela
(tabelele) părinte şi numărul necesar de înregistrări în tabela (tabelele) copil.
1. Să se afişeze toţi pacienţii ordonaţi alfabetic după nume.
2. Să se creeze un formular de meniu care să conţină 4 butoane de
comandă: primul va deschide forma Pacienţi – cu subformularul
Programări, al doilea va deschide forma Programari (care va fi creat în
Design, modificând culoarea fundalului), al treilea buton va deschide
forma Doctori (care va avea un titlu şi o poza pe fundal), iar ultimul
buton permite închiderea formei.
Rezolvare
În urma analizei problemei, s-a ajuns la următoarea structură a datelor:
Fig. 77. – Fereastra Relationships
1. Pentru a sorta datele dintr-o tabelă se pot folosi fie butoanele
Ascending sau Descending aflate pe panglică (Ribbon), dacă este
selectată opţiunea de meniu Home, tabelul fiind deschis în Design
View, fie săgeata din dreptul numelui câmpului în modul Datasheet
View – figura78.
Fig. 78 – Sortarea crescătoare a valorilor din câmpul IDdoctor
156
2. Formularul de meniu va fi creat ultimul, acesta apelând formularele
create anterior.
Pentru a crea primul formular cu subformular, vom selecta tabela părinte
(Pacienţi) din panoul de navigare şi apăsăm butonul Form de pe panglică
(Ribbon), fiind selectată opţiunea de meniu Create – figura 79. Se observă că
dacă au fost create relaţiile dintre tabele, apelarea butonului Form nu crează un
formular simplu, ci un formular pentru tabela părinte cu un subformular
corespunzător tabelei copil. Formularul se va salva cu numele
PacientiProgramari. Dacă se doreşte vizualizarea formularului în Design
View, se foloseşte fie butonul View de pe panglică, opţiunea de meniu Home,
opţiunea Design View, fie butonul cu acelaşi nume de pe bara de stare. Se pot
observa 3 zone: Form Header, Detail şi Form Footer.
Fig. 79 –Formular cu subformular
Pentru a crea un formular în Design View, se alege opţiunea de meniu Create,
apoi butonul Form Design de pe panglică (Ribbon). Se observă faptul că pe
formular este vizibilă doar zona de Detail. Pentru a afişa şi celelalte zone de
meniu, se apelează meniul contextual (clic cu butonul din dreapta al mouse-ului
pe formular), apoi se selectează opţiunea Form Header/Footer. Formularul se
salvează (butonul Save din dreapta butonului Office) cu numele Programari –
figura 80.
157
Fig.80 – Formular în Design View
Pentru a schimba proprietăţile formularului, se apelează meniul contextual, apoi
se alege opţiunea Properties. Pentru a selecta tabela sursă a formularului, se
selectează în cadrul casetei Selection type: Form, apoi opţiunea Recourd
Source de unde alegem selectând săgeata, se alege numele tabelei Programari
– figura 81.
Fig. 81 – Fereastra Property Sheet
De pe panglică se selectează opţiunea de meniu Design, apoi se selectează
butonul Add Existing Fields, adăugându-se prin dublu-clic sau drag-and-drop
toate câmpurile din tabela Programari în zona de Design a formularului –
figura 82.
158
Fig. 82 – Adăugarea controalelor pe formular
Pentru a schimba culoarea fundalului se foloseşte butonul Fill/Back Color. Se
utilizează pentru fiecare zonă în parte – figura 83. Pentru a vizualiza rezultatul,
se foloseşte opţiunea Form View fie de pe bara de stare, fie din cadrul
butonului View de pe panglică (opţiunea de meniu Home).
Fig. 83 – Modificarea culorii fundalului
Pentru a crea formularul Doctori vom urma aceeaşi paşi ca şi la punctul b.
Pentru a adăuga un titlu vom selecta butonul Label de pe panglică (opţiunea de
meniu Design) şi vom executa clic în zona Form Header. Titlul adăugat va fi
Lista doctorilor. Când s-a terminat introducerea textului, se execută clic oriunde
pe formă pentru a finaliza editarea. Vom executa clic cu butonul din dreapta al
mouse-ului pe titlu, selectând opţiunea Properties. În fereastra Property Sheet
vom modifica proprietatea Name: lblTitlu. De observat faptul că proprietatea
Caption apare deja completată cu textul care apare pe formă.
Se pot alege opţiuni de formatare cum ar fi dimensiunea literelor, culoarea
literelor, îngroşare, înclinare, centrare, etc. Aceste se găsesc în zona Font de pe
panglică. Dacă este nevoie se va redimensiona controlul.
159
Pentru a adăuga adăuga o poză de fundal vom selecta butonul Property Sheet
de pe panglică. De la Selection type vom alege Form, apoi opţiunea Picture.
Selectând butonul cu trei puncte se va alege o poză pentru fundal. Dacă este
nevoie, se va modifica culoarea textului etichetelor pentru a crea un contrast cu
fundalul. Pentru formă se va selecta proprietatea Picture Size Mode şi se vor
alege opţiunea Stretch – figura 84. Pentru a vizualiza formularul se va alege
opţiune Form View. Se închide formularul.
Fig. 84 – Adăugarea unei poze de fundal
Pentru a crea un formular de meniu, se va selecta butonul Form Design de pe
panglică, fiind selectată opţiunea Create de pe bara de meniuri. Nu se va mai
selecta Form Hearde/Footer. Se verifică dacă pe panglică butonul Use
Control Wizard este selectat, iar dacă nu este selectat, îl selectăm. Se alege
apoi butonul Button. La execuţia unui clic pe formă, fereastra Command
Button Wizard va apare pe ecran – figura 85.
160
Fig. 85 – Fereastra Command Button Wizard
Se alege categoria Form Operations, apoi acţiunea Open Form, apoi se apasă
butonul Next. Se alege formularul PacientiProgramari, apoi se apasă Next. Se
va alege opţiunea Open the form and show all the records, apoi se apasă
butonul Next. Se selectează opţiunea Text, modificând textul în „Forma
PacientiProgramari”, apoi se apasă butonul Next. Numele butonul va fi
cmdPacCons, apoi se apasă Finish.
Analog se construiesc butoanele corespunzătoare celorlalte două formulare.
Pentru ultimul buton se va alege categoria Application, acţiunea Quit
Application. Se va selecta pentru opţiunea Text: Ieşire, numele butonului fiind
cmdIeşire.
Formularul va fi salvat cu numele Meniu – Figura 86. Se va testa formularul
trecând în Form View.
Fig. 86 – Crearea unui formular de meniu
161
5.12.4 Problemă rezolvată – Formulare cu controale calculate,
Switchboard
Să se creeze pe Desktop un folder cu numele şi prenumele dvs. Să se creeze o
bază de date cu numele Transporturi. Clienţii pot fi atât persoane fizice, caz în
care pe fişă sunt specificate numele, adresa clientului şi numărul de telefon, cât
şi persoane juridice, caz în care se specifică denumirea firmei şi codul fiscal.
Transporturile sunt realizate prin intermediul unei fişe de transport, caracterizate
prin data şi ora plecării, numărul autovehicolului, destinaţia şi tariful. Angajaţii
firmei (şoferii) sunt identificaţi prin nume, adresă şi număr de telefon.
1. Să se creeze relaţii de tip one-to-many între tabele. Să se introducă 3
înregistrări în tabela (tabelele) părinte şi numărul necesar de înregistrări
în tabela (tabelele) copil. Să se modifice relaţiile pentru a realiza
modificarea datelor în cascadă.
2. Să se creeze un formular cu subformular pentru Clienţi şi transporturile
efectuate utilizându-se Form Wizard.
3. Să se creeze un formular pentru tabela FişeTrans, afişându-se toate
câmpurile, şi în plus, TVA-ul şi valoarea cu TVA a tarifului pentru
fiecare fişă de transport. Să se adauge un buton de comandă în Form
Footer pentru a închide forma.
4. Să se creeze un formular de tip Switchboard denumit Meniu cu 2
butoane de comandă: primul, denumit Vizualizare formulare, va apela
un alt Switchboard care va grupa toate formele create anterior. Al doilea
buton de pe primul Switchboard, denumit Ieşire, va permite închiderea
mediului de lucru Access. Să se seteze Switchboardul Meniu ca fiind
prima formă afişată atunci când va fi deschisă aplicaţia.
Rezolvare
1. Analizând problema, s-a ajuns la următoarea structură a datelor – figura 87.
Fig. 87 – Fereastra Relationship
2. Pentru a construi un formular cu subfomular se vor construi câte un
formular pentru fiecare tabel, urmând a le uni într-unul singur. Pentru tabela
162
părinte se va alege un formular de tip Columnar, iar pentru tabela copil, un
formular de tip Tabular.
Pentru a crea primul formular, se alege opţiunea de meniu Create, butonul
More forms... apoi Form Wizard. La primul pas se alege tabela Clienti,
selectându-se toate câmpurile cu ajutorul butonului cu două săgeţi, apoi se
apasă Next – figura 88. Aspectul (layout-ul) formularului va fi Columnar, apoi
se selectează butonul Next. Se alege un stil, apoi se apasă Next. La ultimul pas
se apasă doar butonul Finish. Se salvează formularul cu numele Clienti.
Fig. 88 – Form Wizard pentru tabela Clienţi
În mod similar se crează un formular pentru tabela FiseTrans, selectând ca
layout Tabular (la pasul 2). Se salvează formularul cu numele FiseTrans.
Pentru clasificarea obiectelor, în panoul de navigare din partea din stânga a
ecranului (Navigation Pane) se alege de la All Tables săgeata, apoi Object
Type. Obiectele vor fi ordonate după tipul lor.
Se deschide formularul Clienti in Design View. Se măreşte zona de Detail şi se
trage formularul FiseTrans din panoul de navigare în zona de detaliu a
formularului părinte. Se trage în jos de butonul de redimensionare (portocaliu) a
subformularul astfel încât să fie vizibilă zona acestuia de Detaliu. Se salveză
utilizând butonul Office, Save as..., Save Object As cu numele
ClientiFiseTrans – figura 89.
163
Fig. 89 – Formularul Clienti cu subformularul FiseTrans
3. Pentru a crea un formular în Design View, se alege de pe panglică opţiunea
Create, apoi Form Design. Din fereastra Properties (de pe panglică,
opţiunea de meniu Design, butonul Property Sheet), se alege la Selection
Type – Form, iar la opţiunea RecordSource (sursa înregistrărilor) se
selectează din listă FiseTrans. Se apelează butonul Add Existing Fields (de
pe panglică, opţiunea de meniu Design) şi prin dublu-click pe câmp sau
drag-and-drop se selectează pe formular toate câmpurile.
Pentru a adăuga un nou câmp pe formular, se foloseşte butonul Text Box de pe
panglică (drag-and-drop). Controlul va fi plasat pe formular în zona Detail, sub
celelalte controale. Acesta este format dintr-o etichetă (în engleză Label)
(partea din stânga, Text8 în acest caz), şi cutia de text (Text Box în engleză)
(partea din dreapta, care apare completată cu cuvântul Unbound – nelegat).
Efectuând clic cu butonul din dreapta pe etichetă, alegem opţiunea Properties.
În fereastra Property Sheet se vor modifica două proprietăţi pentru etichetă:
Name: lblTVA şi Caption: TVA (pe pagina All sunt primele două opţiuni).
Pentru cutia de text vom modifica proprietăţile Name: txtTVA şi
ControlSource: semnul egal urmat de formula de calcul a TVA-ului,
punând numele câmpului între paranteze drepte. În mod similar se calculează şi
valoarea tarifului cu TVA. Se va adăuga un nou Text box de pe panglică în zona
Detail a formularului, sub celelalte controale. Pentru etichetă se modifică
proprietăţile Name:lblTarifTVA şi Caption: Tarif cu TVA. Pentru text-box
se modifică proprietăţile Name:txtTarifTVA şi Control Source: semnul egal
urmat de formula de calcul, numele câmpului sau a câmpurilor fiind scrise
între paranteze drepte – figura 90.
164
Fig. 90 – Crearea unui câmp calculat
Pentru a formata cele două cutii de text create astfel încât să conţină simbolul
valutar, în fereastra Property Sheet, se va selecta proprietatea Format de unde
se alege Currency. Formularul va fi salvat cu numele FiseTransport.
Pentru a adăuga un buton de comandă care va închide formularul, se verifică
dacă este apăsat butonul Use Control Wizard din opţiunea de meniu Design
(de pe panglică). Dacă este selectat, se alege butonul Button, apoi se execută un
clic pe formular, sub restul controalelor. Se alege categoria Forms, acţiunea
Close Form, apoi se apasă butonul Next. Se selectează opţiunea Text unde se
tastează Închidere, apoi se apasă butonul Next. Pentru a finaliza, se tastează
numele controlului, cmdInchidere, apoi se apasă butonul Finish.
4. Pentru a crea un Switchboard, de pe bara de meniuri se alege opţiunea
Database Tools, apoi Switchboard Manager. La apariţia mesajului The
Switchboard Manager was unable to find a valid switchboard in this
database. Would you like to create one? se alege opţiunea Yes. În
fereastra Switchboard se selectează butonul Edit pentru a modifica
formularul principal (Main Switchboard(Default)). În fereastra Edit
Switchboard Page se modifică opţiunea Switchboard Name din Main
Switchboard în Meniu. Se apasă butonul Close şi se crează al doilea
formular care va avea numele Vizualizare formulare. Pentru aceasta se
apasă butonul New şi se modifică numele formularului din New
Switchboard page în Vizualizare formulare – figura 91.
165
Fig. 91 – Crearea celui de-al doilea formular
Se vor adăuga în continuare elemente pe fiecare formular în parte.
Primul formular, Meniu va avea două elemente: unul care permite vizualizarea
formularului Vizualizare formulare şi al doilea care permite părăsirea
aplicaţiei. Pentru aceasta, se selectează Meniu, apoi se apasă butonul Edit. În
caseta Item on this Switchboard vor fi afişate cele două elemente create.
Pentru a adăuga un element nou, se apasă butonul New – figura 92.
Fig. 92 – Adăugarea unui item pe primul formular
În cadrul casetei Text se va completa textul care dorim să apară în dreptul
butonului: Vizualizare formular. În caseta Command se lasă neschimbat Go
to Switchboard, iar din ultima casetă Switchboard se alege numele
formularului care va fi apelat atunci când butonul acesta va fi acţionat:
Vizualizare formulare. Se apasă butonul OK.
Pentru a adăuga al doilea element, se apasă butonul New. În cadrul casetei Text
se va completa Ieşire, iar în caseta Command se va alege Exit Application,
apoi se apasă butonul OK – figura 93.
166
Fig. 93 – Adăugarea unui item pe primul formular
Pentru a ieşi din modul de editare al formularului Meniu se utilzează butonul
Close.
Se alege formularul Vizualizare formulare, apoi se apasă butonul Edit, pentru
a adăuga butoane. Pentru aceasta se utilizează butonul New – Figura 94.
În caseta Text se tastează „Formularul ” urmat de numele formularului ales, în
cutia de text Command se alege Open form in Edit Mode iar din caseta Form
se alege primul formular. Se apasă butonul OK.
Fig. 94 – Adăugarea unui item pe formularul Vizualizare formulare
În mod similar se crează butoane pentru fiecare formular.
Ultimul buton va face trecerea înapoi la formularul Meniu. Pentru aceasta se
apasă din nou butonul New – figura 95.
167
Fig. 95 – Adăugarea item-ului Intoarcere pe formularul Vizualizare formulare
Pentru a încheia modul de editare al formularului Vizualizare formulare se
apasă butonul Close. Dacă formularul Meniu nu este formularul principal (dacă
în dreptul lui nu apare cuvântul Default în paranteză), acesta se selectează, apoi
se apasă butonul Make Default. Odată cu apăsarea butonului Close observăm
crearea unui nou formular cu numele Switchboard şi a unei tabele cu numele
Switchboard Items în panoul de navigare din stânga – Figura 96.
Fig. 96 – Formularul Meniu (de tip Switchboard)
Pentru a seta formularul ca fiind primul obiect care apare la deschiderea bazei
de date, se selectează butonul Office, se alege butonul Access Options, apoi
Current Database. Se poate alege un titlu pentru aplicaţie, în caseta
Application Title: Transporturi, iar din lista Display Form se alege
Switchboard – figura 97.
168
Fig. 97 – Crearea unui titlu a aplicaţiei şi setarea formularului principal
5.12.5 Problemă rezolvată – Interogări
Se consideră baza de date creată la punctul 5.12.2.
1. Să se creeze o interogare care să permită afişarea informaţiilor de pe
toate facturile (nr_f, data_f, den_p, cantit, preţ_u şi cota TVA) pentru
data curentă.
2. Să se creeze o interogare afişându-se pentru fiecare înregistrare TVA-ul
şi Valoarea.
3. Să se creeze o interogare care să permită citirea interactivă în momentul
execuţiei a unui număr de factură şi afişarea informaţiilor legate de
aceasta.
4. Să se creeze o interogare care să permită afişarea tuturor facturilor
eliberate între 2 date calendaristice (operatorii Between cu And).
5. Să se creeze prin intermediul unei interogări un nou câmp cu numele
Observaţii care va conţine textul “Produs eficient” dacă valoarea este
mai mare decât o anumită valoare sau “Produs ineficient” daca valoarea
este mai mică decât acea valoare.
6. Să se afişeze toate facturile eliberate luna aceasta.
7. Operatorul Like:
a. Să se afişeze toate produsele care încep cu litera l.
b. Să se afişeze doar produsele care sunt din 6 litere si încep cu
litera l.
169
8. Să se afişeze toate produsele care au preţurile 50 şi 1000 lei.
9. Să se determine pentru fiecare factură valoarea totală.
10. Să se creeze un nou tabel pe baza tabelelor Facturi, Produse şi
LiniiFact, rezultatul unei interogări, care să conţină toate datele din
toate tabele, suprimând apariţia dublată a câmpurilor de legătură,
tabelul fiind ordonat alfabetic după denumirea produselor.
Rezolvare:
1. Pentru a crea o interogare, de pe bara de meniuri se alege opţiunea
Create, apoi Query Design. În fereastra Show table se vor selecta prin
dublu-clic tabelele Facturi, ProduseFacturate şi Produse, apoi se
închide fereastra. Pentru a alege câmpurile dorite, acestea se selectează
prin dublu-click. Sub coloana data_f, pe linia Criteria, se va introduce
=Date(). Se salvează interogarea apăsând pe butonul Save (numele
interogării fiind Facturi curente). Pentru a vizualiza rezultatul
interogării, de pe butonul View se alege Datasheet View.
Fig. 98 – Interogare în Query Design
Observaţie: Dacă interogarea nu returnează nici un rezultatul, înseamnă că nici
o înregistrare nu a verificat condiţia ca data facturii să fie data curentă.
Fig. 99 – Interogare în Datasheet View
Se închide interogarea.
170
2. Pentru a crea a doua interogare, se alege de pe panglică opţiunea de
meniu Create, apoi Query Design. Din tabela ProduseFacturate se
selectează cantitatea, preţul şi cotaTVA, iar din tabela Produse
denumirea produsului şi unitatea de măsură. Deci în fereastra Show
Tables, se vor alege ambele tabele, selectându-se câmpurile respective.
Pe prima coloană liberă se calculează TVA-ul după următoarea formulă
TVA: [cantit]*[pret_u]*[cotaTVA]
Pe următoarea coloană se calculează valoarea:
Valoare: [cant]*[pret_u]+[TVA]
Se salvează şi vizualizeză rezultatul interogării. Pentru a afişa simbolul
valutar într-o anumită coloană din interogare (de exemplu pt. TVA), în
modul de vizualizare Design View se selectează coloana, se apelează
din meniul contextual opţiunea Properties, iar la opţiunea Format se
alege Currency. Analog se procedează şi cu coloana Valoare.
Fig. 100 – Interogare în Design View
3. Se selectează tabelele Facturi, Produse şi ProduseFacturate, câmpurile:
nr_f, data_f, den_p, pret_u şi cantit. Pentru a crea o interogare cu parametru,
care să permită citirea interactivă a numărului facturii de pe tastatură, pe
coloana nr_f, linia Criteria se tastează [Introduceti numarul facturii]. Se
închide interogarea şi se lansează în execuţie prin dublu-clic pe numele
interogării din panoul de navigare.
Fig. 101 – Interogare cu parametru
171
4. Se selectează tabela Facturi, ProduseFacturate şi Produse, câmpurile:
nr_f, data_f, den_p, pret_u şi cantit:
Fig. 102 – Operatorul Between
5. Se deschide interogarea de la punctul 2, în Design View, se salvează cu
numele Observaţii (Save as de pe butonul Office, Save object as...). Se
apelează meniul contextual asociat unui nou câmp (prima coloană liberă), se
alege opţiunea Build – figura 103.
Fig. 103 – Funcţia IIF
Se selectează funcţia IIF, modificând-o astfel:
Observatii: IIf([valoare]>=50000;"Produs eficient";"Produs ineficient")
Fig. 104 – Funcţia IIF
172
Dacă se trece în modul de vizualizare Datasheet View se poate observa
rezultatul aplicării funcţiei IIf – figura 105.
Fig. 105 – Rezultatul funcţiei Iif
6. Vom folosi 2 funcţii care pot fi aplicate unor date calendaristice:
Datepart (o parte dintr-o dată calendaristică) şi funcţia Month (extrage luna
dintr-o dată calendaristică).
Fig. 106 – Funcţii pentru dată calendaristică
7. a). Se alege tabela Produse, câmpurile: den_p, pret_u. Pe coloana
den_p, linia Criteria se tastează condiţia: LIKE "l*".
b) Se deschide interogarea de la punctul a), se salvează cu alt nume, se
trece în modul de vizualizare Design View şi se modifică condiţia: LIKE
"l?????".
8. Se alege tabela ProduseFacturate, coloana pret_u, utilizându-se
operatorul IN – figura 107.
173
Fig. 107 – Operatorul IN
9. Se crează o nouă interogare. Se adaugă tabelele Produse şi
ProduseFacturate. Se calculează valoarea. Se adaugă câmpul nr_f şi se
selectează butonul Totals de pe bara de unelte, iar sub valoare, pe linia
Total, se alege funcţia SUM – figura 108.
Fig. 108 – Interogări de sintetizare a datelor
10. Pentru a crea o nouă tabelă cu toate înregistrările din tabelele Facturi,
Produse şi ProduseFacturate, se adaugă toate câmpurile din aceste
tabele, fără a le duplica. Se salvează interogarea cu numele Creare
tabela. De pe panglică se alege butonul Make Table – figura 109, se
tasteată numele noii tabele: Reuniune, apo se apasă butonul OK. Pentru
a se executa interogarea se va selecta Run. Dacă nivelul de securitate
nu este setat astfel încât să permită execuţia codurilor Visual Basic,
interogarea nu va funcţiona. Pentru a permite utilizarea codurilor, de pe
174
bara Security Warning se alege butonul Options, apoi opţiunea
Enable this content.
Fig. 109 – Interogare de tip Make Table
Dacă interogarea este închisă, se va lansa în execuţie prin dublu-clic pe numele
acesteia din panoul de navigare – figura 109. Sistemul Access avertizează
asupra eventualelor riscuri care pot apare la execuţia unei interogări de acţiune.
Vom alege butonul Yes.
Fig. 110 – Mesaj de avertizare
Şi mesajul următor este doar unul de avertizare, şi anume că datele salvate în
tabele vor fi adăugate în tabelul nou creat. Deci vom apăsa butonul Yes.
175
Fig. 111 – Mesaj de avertizare la transferarea înregistrărilor într-un nou tabel
5.12.6 Problemă rezolvată – Rapoarte
1. Să se creeze un raport pentru tabelul ProduseFacturate, datele fiind
grupate după nr_f.
2. Să se creeze un raport pentru afişarea datelor de pe fiecare factură în
parte, calculându-se valoarea facturii şi valoarea totală a tuturor
facturilor.
Rezolvare:
1. Pentru a crea un raport cu ajutorul asistentului, se alege opţiunea de
meniu Create, butonul Report Wizard. La primul pas se alege tabela sau
interogarea pe baza căreia se va crea raportul (Tables/Queries). Din caseta
Available Fields se selectează câmpurile dorite, apoi se apasă butonul Next.
Fig. 112 – Report Wizard pentru tabela ProduseFacturate
La pasul 2 se selectează criteriul de grupare, în cazul de faţă vom grupa
produsele facturate după nr_f. Dacă se apasă butonul Grouping Options se pot
alege mai multe variante de grupare: după primele 10, 50, 100, etc numere de
factură. În cazul de faţă opţiunea Normal rămâne selectată – figura 113.
176
Fig. 113 – Fereastra Grouping Intervals
La pasul următor se selectează ordinea în care vor fi afişate înregistrările în
raport:
Fig. 114 – Ordonarea datelor de pe raport
Dacă este selectat butonul Summary Options... se pot selecta funcţii ce vor fi
aplicate pe câmpurile numerice din tabel sau interogare – figura 115.
177
Fig. 115 – Summary Options
În continuare se selectează orientarea paginii (verticală, orizontală), precum şi
modul de afişare al informaţiilor pe pagină:
Fig. 116 – Opţiuni de formatare a paginii
La pasul următor se alege un stil din lista afişată – figura 117.
Fig. 117 – Alegerea stilului raportului
178
Ultimul pas permite modificarea titlului raportului (nu este vorba de numele cu
care va fi salvat raportul, ci doar textul care va apare în antentul raportului),
apoi putem alege între a vizualiza raportul şi a modifica raportul. Pentru a
încheia crearea raportului se alege opţiunea Finish. – figura 118
Fig. 118 - Alegerea unui titlu şi vizualizarea raportului în mod Print Preview
Raportul în modul Print Preview va apare ca în figura următoare – figura 119.
Fig 119 – ProduseFacturate în Print Preview
179
În Design View raportul arată ca în figura 120.
Fig. 120 – Raportul ProduseFacturate în Design View
Dacă datele provin din mai multe tabele, sau sunt necesare unele câmpuri
calculate, se poate crea o interogare în care se selectează tabelele, se calculează
câmpurile dorite, apoi se creează raportul pe baza interogării.
Dacă se doreşte adăugarea unui câmp care va fi calculat, se alege de pe panglică
controlul Text Box. Se modifică pentru etichetă proprietăţile Name: lblValoare
şi Caption: Valoare. Aceasta va fi mutată în zona nr_f Header. Pentru controlul
de tip Text Box se vor modifica proprietăţile Name: txtValoare şi Control
Source: =[cantit]*[pret_u]* [cotaTVA].
2. Pentru a crea raportul, se va alege ca sursă a datelor interogarea cu
numele Valoare. Având câmpuri numerice, la pasul 3 se selectează butonul
Summary Option, bifând check-box-urile de sub funcţia SUM pentru
câmpurile TVA şi Valoare.
Fig. 121 – Fereastra Summary Options
180
Pentru a vizualiza raportul, de pe butonul View se alege opţiunea Print
Preview – figura 122.
Fig. 122 – Raportul în Print Preview
Pentru a modifica raportul (adăuga controale calculate) este necesară
vizualizarea acestuia în modul Design View.
Fig. 123 – Raportul în Design View
181
5.13 Probleme propuse
5.13.1 Problema propusă – Crearea tabelelor – Filială CEC
Se cere informatizarea activităţii la o filială CEC. Clienţii filialei sunt
identificaţi prin seria şi numărul de buletin, data eliberării buletinului, nume,
prenume şi adresă. Fiecare client poate să deţină unul sau mai multe cecuri.
Pentru fiecare cec se cunoaşte: seria, numărul, data la care a fost eliberat, suma
depusă în momentul eliberării şi tipul cecului (poate fi la termen şi la vedere).
De asemenea, fiecare cec poate să aibă unul sau mai mulţi titulari. Fiecare client
poate efectua depuneri şi restituiri. Depunerile se efectuează prin intermediul
unei foi de depunere (FD) caracterizată prin: număr, data şi suma depusă.
Restituirile se efectuează prin intermediul foilor de restituire (FR) caracterizate
prin: număr, data şi suma restituită. Fiecare cec se poate lichida de către unul
din titulari prin intermediul unei foi de lichidare (FL) caracterizată prin: număr,
data şi suma din momentul lichidării. Dobânda acordată pentru cecuri se
modifică de la o zi la alta şi este diferită pentru cecurile la termen faţă de cele la
vedere.
5.13.2 Problemă propusă – Crearea formularelor
Să se creeze o interfaţă grafică cu utilizatorul cu ajutorul opţiunii Switchboard,
fiind create formulare cu subformulare pentru toate tabelele părinte-copil,
îmbogăţite cu butoane de comandă care să permită închiderea formelor şi
câmpuri calculate pe baza tabelelor create în baza de date de la punctul 5.13.1.
5.13.3 Problemă propusă – Crearea interogărilor
Să se creeze toate tipurile de interogări pentru baza de date creată la punctul
5.13.1.
5.13.4 Problemă propusă – Crearea rapoartelor
Să se creeze rapoarte pentru toate tabelele şi interogările create la punctul 5.13.1
şi 5.13.3.
182
183
CAPITOLUL 6
ELEMENTE SQL
6.1 Introducere
Unul dintre cele mai puternice limbaje structurate pentru interogarea datelor,
SQL (Structured Query Language), a devenit un standard pentru o gamă din ce
în ce mai largă de sisteme pentru gestiunea bazelor de date. A fost construit în
1986 de către ANSI (American National Standards Institute). De atunci, este
considerat a fi un standard interaţional avizat de către ISO (International
Organization for Standardization) şi IEC (International Electrotechnical
Comission). A fost adoptat ca fiind standard federal de către FIPS (american
Federal Information Processing Standard). În cadrul acestui capitol se vor
prezenta comanda Select – care permite realizarea interogării bazelor de date,
precum şi instrucţiunile care permit actualizarea datelor (adăugarea, modificarea
şi ştergerea datelor prin comenzi SQL).
6.2 Comenzi SQL
Limbajul SQL (Structured Query Language) este un limbaj structurat de
interogări şi gestionare a bazelor de date relaţionale. Access foloseşte SQL ca
limbaj de interogare. În momentul creării unei interogări în modul de interogare
Design, Access construieşte în paralel instrucţiunile SQL echivalente. De altfel,
majoritatea proprietăţilor interogărilor în modul de interogare Design prezintă
clauze echivalente şi opţiuni accesibile în limbajul SQL.
Avantajele utilizării instrucţiunii SQL în VBA sunt următoarele:
viteza de execuţie: o instrucţiune Select este mai rapidă decât
parcurgerea secvenţială a unui tabel.
performanţă mai bună: în modul client/server, interogările sunt
compilate de SGBD care le optimizează performaţele.
întreţinere mai uşoară: codul de instrucţiuni SQL este mai scurt, deci
mai uşor de citit, decât echivalentul său în VBA.
184
standardizare: limbajul SQL este standardul de interogare al bazelor de
date relaţionale.34
SQL are următoarele componente:
1. DDL – Data Definition Language (limbaj de definire a datelor):
include comenzi legate de crearea, modificarea şi ştergerea schemei de
structură a bazei de date şi/sau a tabelelor. Dintre comenzile cele mai
des întâlnite amintim: CREATE TABLE, ALTER TABLE, DROP
TABLE;
2. DML – Data Manipulation Language (limbaj de manipulare a
datelor): include comenzi pentru a realiza interogări şi pentru a
modifica datele stocate în tabele. Dintre cele mai des utilizate comenzi
amintim: SELECT, INSERT INTO, UPDATE, DELETE;
3. DCL – Data Control Language (limbaj de control a datelor): include
comenzi pentru menţinerea securităţii şi a confidenţialităţii bazei de
date. Dintre comenzile uzuale amintim: GRANT (acordarea drepturilor
unui utilizator) şi REVOKE (revocarea drepturilor unui utilizator).
Vocabularul SQL cuprinde o serie de cuvinte cheie, dintre care amintim35
:
instrucţiuni – determină execuţia unei anumite acţiuni (de exemplu
Create Table, Select, Delete);
clauze – permit specificarea unor argumente care nuanţează
instrucţiunile, delimitând entităţile participante la interogare (exemple
de clauze: From, Where, Group By, Order By);
funcţii – efectuează prelucrări asupra anumitor date denumite
argumentele sau parametrii funcţiei, rezultatele returnate fiind utilizate
în cadrul unei clauze SQL. Funcţiile şi operatorii prezentaţi în
paragraful 5.4.1 sunt valabili şi în SQL.
Principalele reguli de sintaxă sunt:
orice instrucţiune SQL se termină cu simbolul „punct şi virgulă”;
SQL utilizează ierarhia obiectelor din modelele orientate pe obiecte,
caracterul „punct” separând un obiect de un atribut sau o metodă a
acestuia. De exemplu, numele_tabelei.numele_câmpului;
parantezele drepte se utilizeză atunci când un nume de tabel sau câmp
conţine caracterul spaţiu, de exemplu [Denumire Furnizor];
34
Giulvezan C., Mircea G., Târnăveanu D., Margea C. – Baze de date, Editura Universităţii de
Vest, Timişoara, 2009, p.59 35 Florescu V. (coord.), Ionescu B. (coord.), Cozgarea G., et al – Baze de date, Editura Infomega,
Bucureşti, 2009, p. 67
185
caracterul „virgulă” este utilizată pentru a delimita valorile unei liste (de
exemplu lista câmpurilor);
valorile de tip Number sunt scrise direct, fără a fi încadrate de nici un
alt caracter;
valorile de tip Text sunt încadrate între caracterul „apostrof” (de
exemplu: „Timişoara‟);
valorile de tip dată calendaristică sunt încadrate între caracterul „diez”
(de exemplu: #31/12/2011#).
Reguli de editare în cazul instrucţiunilor SQL36
:
fiecare clauză a interogării se plasează pe câte o linie separată, indentată
faţă de instrucţiunea din care face parte;
începutul fiecărei clauze va fi aliniat cu începutul celorlalte;
dacă o clauză este fragmentată, fiecare din părţile ei constitutive se
poziţionează pe câte o linie separată şi se indentează faţă de începutul
clauzei;
pentru evidenţierea cuvintelor rezervate, specifice SQL, se folosesc
majuscule.
Atunci când se scriu instrucţiunile în format general, există mai multe convenţii
de notare:
cuvintele rezervate sunt scrise cu majuscule;
cuvintele definite de utilizator se scriu cu litere mici;
bara verticală │ semnifică separarea mai multor elemente alternative
care se exclud reciproc (doar unul din acestea poate fi să apară);
parantezele drepte [ ] încadrează un element opţional;
acoladele {} încadrează un element obligatoriu;
punctele de suspensie semnalează repetarea opţională a unui element al
unei liste.
36 Florescu V. (coord.), Ionescu B. (coord.), Cozgarea G., et al – Baze de date, Editura Infomega,
Bucureşti, 2009, p. 71
186
6.2.1 Comanda CREATE TABLE
Pentru a crea o tabelă de referinţă se poate utiliza următorul format general:
unde numet1 este numele tabelului creat, numec1, numec2,... sunt numele
câmpurilor care vor constitui structura tabelului. Tip1, tip2, ... sunt tipurile de
date suportate de limbajul SQL – vezi figura 1. PRIMARY KEY semnifica
setarea unui câmp ca fiind de tip cheie primară. Atributul NOT NULL
semnifică faptul că acel câmp este este obligatoriu să fie completat (echivalentul
proprietăţii Required din Access). Programatorii folosesc o denumire pentru
fiecare constrângere utilizată (Primary Key, Foreign Key, Not Null, Unique).
Denumirea constrângerii este poziţionată în faţa constrîngerii, după cuvântul
predefinit CONSTRAINT. Numele constrângerilor sunt formate dintr-un prefix
urmat de numele câmpului pe care este setat. Prefixul este prestabilit:
pk (pentru PRIMARY KEY);
nn (pentru NOT NULL);
un (pentru UNIQUE);
fk (pentru FOREIGN KEY).
Între tipurile de date din Access (din Design View) şi tipurile de date din SQL
nu există o corespondenţă perfectă – figura 1.
Access SQL
Double Number
Long Integer Integer
Yes/No Logical
Date/Time Date
Text Text
Fig. 1 – Corespondenţele între tipurile de date din Access şi SQL
Pentru tipul de date Text, dacă nu se specifică lungimea acestuia, valoarea
implicită este de 255 de caractere. Dacă un nume de câmp conţine caracterul
space, acesta trebuie pus între paranteze drepte. De exemplu, [Nume Prenume].
CREATE TABLE numet1
(numec1 tip1 [CONSTRAINT nn_c1 NOT NULL]
[CONSTRAINT pk_c1] PRIMARY KEY,
numec2 tip2 [CONSTRAINT nn_c2 NOT NULL], …);
187
Exemplu: Să se creeze o tabelă cu turiştii unei agenţii de turism. Pentru aceştia
vom cunoaşte CNP-ul, numele şi prenumele, seria şi numărul de pe cartea de
identitate, data naşterii, telefonul şi numărul de paşaport.
CREATE TABLE Turisti (CNP_turist TEXT(13)
CONSTRAINT pk_CNP_turist PRIMARY KEY,
numepren_turist TEXT(30), serienrCI TEXT (8),
datanast_turist DATE, telefon TEXT (12),
nrpass_turist NUMBER);
Pentru a crea o tabelă cu o cheie primară compusă, se utilizează următorul
format general:
Pentru crearea unei chei primare compuse, constrângerea va fi specificată la
sfărşit, numele acesteia va fi format din prefix şi numele celor două câmpuri.
După PRIMARY KEY se specifică între paranteze câmpurile care compun
cheia primară.
Exemplu: Să se creeze o tabelă cu o cheie primară compusă. Tabela va avea
numele ProduseFacturate şi va conţine următoarele câmpuri: numărul facturii,
numărul curent al produsului de pe factură, cantitate, preţ unitar, unitatea de
măsură şi cotaTVA. Cheia primară va fi compusă din câmpurile nr_f şi nr_crt.
CREATE TABLE ProduseFacturate (nr_f INTEGER NOT NULL,
nr_crt INTEGER NOT NULL,
cantitate NUMBER, pret_u NUMBER, um TEXT (10),
cotaTVA NUMBER,
CONSTRAINT pk_nrfcrt PRIMARY KEY (nr_f, nr_crt));
CREATE TABLE numet2
(numec1 tip1 [CONSTRAINT nn_c1] [NOT NULL], numec2 tip2 [CONSTRAINT nn_c2][NOT NULL],
…,
[CONSTRAINT pk_nc1c2] PRIMARY KEY
(numec1,numec2));
188
Pentru a crea o tabelă referită, se utilizează următorul format general:
Pentru a crea o tabelă referită este necesară crearea legăturii cu tabela de
referinţă. Când se defineşte câmpul de legătură, acesta trebuie să fie de acelaşi
tip ca şi câmpul corespunzător din tabela de referinţă, apoi se creează o
constrângere de tip FOREIGN KEY, iar după cuvântul predefinit
REFERENCES se alege numele tabelei de referinţă şi în paranteză numele
câmpului de legătură din tabela de referinţă. Numele celor două câmpuri nu
trebuie să fie identice.
Exemplu: Să se creeze o tabelă cu contractele încheiate de către turiştii agenţiei
de turism. Se presupune că un turist încheie mai multe contracte, cunoscându-se
numărul contractului, data contractului, tipul serviciului, data plecării, data
sosirii, ţara şi beneficiarii (numele celorlalte persoane din familie, dacă este
cazul).
CREATE TABLE Contracte (nrc INTEGER
CONSTRAINT pk_nrc PRIMARY KEY,
datac DATE CONSTRAINT nn_datac NOT NULL,
tip_serv TEXT(30), data_plec DATE, data_sos DATE,
tara TEXT (20), benef TEXT (120), CNP_turist TEXT(13)
CONSTRAINT fk_CNP_turist REFERENCES Turisti (CNP_turist));
6.2.2 Comanda ALTER TABLE
Comanda ALTER TABLE modifică structura tabelei, permiţând adăugarea unui
nou câmp sau ştergerea unui câmp, precum şi modificarea proprietăţilor
acestora.
CREATE TABLE numet3 (numec1 tip1 [CONSTRAINT nn_c1 NOT NULL]
[CONSTRAINT pk_c1 ]PRIMARY KEY,
numec2 tip2 [CONSTRAINT nn_c2 NOT NULL]
[CONSTRAINT fk_nc2]
REFERENCES numet1(numec1), …);
189
Dacă se doreşte adăugarea unui nou câmp:
Exemplu: Să se adauge în tabela Contracte câmpul suma_platita.
ALTER TABLE Contracte
ADD COLUMN (suma_platita NUMBER);
Dacă se doreşte ştergerea unui câmp:
Exemplu: Să se şteargă câmpul ţara din tabela Contracte.
ALTER TABLE Contracte
DROP COLUMN tara;
Dacă se doreşte modificarea proprietăţilor unui câmp:
Exemplu: Să se modifice dimensiunea câmpului benef din tabela Contracte.
ALTER TABLE Contracte
ALTER COLUMN benef TEXT(100);
Dacă se doreşte adăugarea unei constrângeri:
Exemplu: Să se adauge o constrângere de tip NOT NULL pentru câmpul
data_plec din tabela Contracte.
ALTER TABLE Contracte
ALTER COLUMN data_plec CONSTRAINT nn_data_plec
NOT NULL;
ALTER TABLE numet1
ADD COLUMN (numec1 tip1,
numec2 tip2, ...);
ALTER TABLE numet1
DROP COLUMN numec1;
ALTER TABLE numet1
ALTER COLUMN numec1 tip_nou;
ALTER TABLE numet1 ALTER COLUMN numec1 [CONSTRAINT numeconst]
{PRIMARY KEY│UNIQUE│NOT NULL};
190
Dacă se doreşte ştergerea unei constrângeri:
Exemplu: Să se şteargă constrângerea de tip NOT NULL impusă pe câmpul
datac.
ALTER TABLE Contracte
DROP CONSTRAINT nn_datac;
6.2.3 Comanda DROP TABLE
Comenda DROP TABLE şterge fizic tabela (nu doar datele din tabelă ci şi
structura acesteia).
Exemplu: Să se şteargă tabela Turisti.
DROP TABLE Contracte;
Dacă o tabelă este de referinţă, nu poate fi ştearsă datorită relaţiei pe care o are
cu tabela referită. Pentru a rezolva acest neajuns, se şterge condiţia de legătură
dintre tabele cu ajutorul comenzii ALTER TABLE, apoi se şterge tabela.
Exemplu: Să se şteargă tabela Turisti.
ALTER TABLE contracte
DROP CONSTRAINT fk_CNP_turist;
DROP TABLE Turisti;
6.2.4 Comanda INSERT INTO
Comanda INSERT INTO inserează o înregistrare într-un tabel. Formatul
general este:
INSERT INTO numet1 [(numec1, numec2, …)]
VALUES
(valoare1, valoare2, ...);
DROP TABLE numet1;
ALTER TABLE numet1 DROP CONSTRAINT numeconst;
191
Specificarea listei câmpurilor este opţională. Dacă lista câmpurilor este omisă,
toate câmpurile din tabelă vor fi completate, în ordinea în care ele au fost create,
cu valorile specificate în lista de valori.
Dacă lista câmpurilor apare dar nu este completă, unele câmpuri lipsind, acele
câmpuri care nu apar în listă vor fi completate cu valoarea NULL, sau cu
valoarea setată ca valoare implicită (DEFAULT). Din păcate, în standardul
minimal, setarea unei valori predefinite nu este permisă.
Numărul câmpurilor din lista de câmpuri trebuie să fie identic cu numărul
valorilor din lista valorilor, iar valorile trebuie să corespundă ca tip tipului de
date a câmpurilor din lista de câmpuri.
Exemplu: Să se introducă o înregistrare în tabela Turişti şi două înregistrări în
tabela Contracte (presupunem că tabela are structura de la creare).
INSERT INTO Turisti VALUES („1711227136548‟, „POP Ion‟,
„TM569856‟, #27.12.1971#, „0730126589‟, 9856978);
INSERT INTO Contracte VALUES (1452, #04.11.2011#, „Charter‟,
#30.12.2011#, #06.01.2012#, „Cuba‟, „POP Maria, POP Carla‟,
„1711227136548‟);
INSERT INTO Contracte (nrc, datac, tip_serv, data_plec, data_sos, tara,
CNP_turist)
VALUES (1453, #25.11.2011#, „Bilete avion‟, #08.04.2012#,
#18.04.2012#, „Italia‟, „1711227136548‟);
6.2.5 Comanda DELETE
Comanda Delete şterge înregistrările care verifică condiţia specificată în clauza
Where dintr-o tabelă. Dacă clauza Where nu apare, sunt şterse automat toate
înregistrările. Tabela nu dispare fizic, sunt şterse doar înregistrările, structura
tabelei rămânând neschimbată.
Formatul general:
Exemplu: Să se şteargă din tabela Contracte contractul cu codul 1453.
DELETE FROM Contracte
WHERE nrc=1453;
DELETE FROM numet1
[WHERE conditie];
192
6.2.6 Comanda SELECT
Comanda SELECT permite filtrarea datelor din una sau mai multe tabele pe
baza unor condiţii. Formatul general al comenzii:
unde:
comanda SELECT afişează înregistrări din una sau mai multe tabele;
clauza From specifică numele tabelei sau a tabelelor sursă a interogării.
Dacă datele provin din mai multe tabele, este necesară adăugarea unei
condiţii de legătură în cadrul clauzei WHERE sau setarea unei jocţiuni
între tabele. Dacă se doreşte afişarea unui câmp care apare în două
tabele, este necesară precizarea numelui tabelei din care acesta face
parte. Numele tabelei este separat de numele câmpului prin caracterul
punct (de exemplu: Produse.CodProdus);
înregistrările pot fi distincte (dacă clauza DISTINCT este selectată – o
valoare va apare o singură dată) sau nu;
filtrarea înregistrărilor se face în funcţie de evaluarea condiţiei logice
din cadrul clauzei Where (dacă aceasta este selectată);
dacă se utilizeză clauza Group By, aceasta va grupa înregistrările în
funcţie de criteriul de grupare. În acest caz pot fi adăugate condiţii
pentru grupurile astfel create utilizându-se clauza Having;
poate fi impusă o ordine de sortare dacă se utilizează clauza Order by,
valoarea implicită fiind Ascending;
simbolul * semnifică selecţia tuturor câmpurilor din acea tabelă. Dacă
se doreşte omiterea unor câmpuri, se va specifica lista câmpurilor fără a
specifica câmpurile respective. Ambele liste – lista_campuri şi
lista_tabele conţin elemente despărţite între ele prin virgulă.
În scrierea interogărilor de selecţie este posibilă utilizarea funcţiilor
totalizatoare. Dintre acestea amintim:
COUNT – returnează numărul total de înregistrări;
SUM – afişează suma valorilor unui câmp (se poate folosi doar pentru
câmpuri numerice);
SELECT [DISTINCT] *│lista_campuri FROM lista_tabele
[WHERE conditie]
[GROUP BY crit_grupare] [HAVING crit_dupa_grupare]
[ORDER BY el_ordonare [ASC│DESC]];
193
AVG – calculează media aritmetică a valorilor unui câmp numeric;
MAX – afişează valoarea maximă din cadrul valorilor unui câmp, dar
nu poate fi folosită în cadrul clauzei WHERE;
MIN – afişează valoarea minimă din cadrul valorilor unui câmp, dar nu
poate fi folosită în cadrul clauzei WHERE.
6.2.6.1 Comenzi SELECT simple
Comenzile SELECT simple au ca sursă înregistrările dintr-un singur tabel.
Considerăm următorul tabel: Studenţi cu structura CNP, nume_prenume, serie
_numărCI (seria şi numărul cărţii de identitate), localitate, adresa, data_nasterii,
an_studiu şi medie_an_anterior.
Exemplul 1: Să se afişeze toţi studentii.
SELECT *
FROM studenti;
Exemplul 2: Să se afişeze CNP-ul şi numele tuturor studenţilor.
SELECT CNP, nume_prenume
FROM studenti;
Exemplul 3: Să se afişeze CNP-ul şi numele tuturor studenţilor din Timişoara.
SELECT CNP, nume_prenume
FROM studenti
WHERE localitate=‟Timisoara‟;
Exemplul 4: Să se afişeze numărul studenţilor din Timişoara.
SELECT COUNT(*)
FROM studenti
WHERE localitate=‟Timisoara‟;
Exemplul 5: Să se afişeze numele şi să se calculeze vârsta studenţilor din anul 2
de studiu.
SELECT nume_prenume, YEAR(Date())-YEAR(data_nasterii)
FROM studenti
WHERE an_studiu=2;
194
Exemplul 6: Să se afişeze numele studenţilor care încep cu litera A şi sunt
născuţi în luna octombrie 1980.
SELECT nume_prenume
FROM studenti
WHERE nume_prenume LIKE „A*‟ AND
datan BETWEEN #01/10/1980# AND #31/10/1980#;
6.2.6.2 Comenzi SELECT complexe
Comenzile SELECT complexe au ca sursă înregistrările din mai multe tabele
conectate între ele pe baza unei relaţii de legătură. Se pot distinge mai multe
tipuri de joncţiuni:
joncţiunea naturală (echijoncţiunea, joncţiunea echivalentă), care
prespune folosirea clauzei Where urmată de o condiţie de legătură de
egalitate între câmpurile corespondente (=). Această condiţie vizează
egalitatea valorilor din câmpurile corespondente;
joncţiuni ne-echivalente – determinaţi de folosirea clauzei Where şi a
unei condiţii de legătură exprimată prin comparaţii (<, >, <=, >=, <>,
BETWEEN, IN, LIKE);
cross (joncţiunea încrucişată) – mai puţin utilizată, cu rol în analiza
multidimensională a datelor.
Se va prezenta în continuare joncţiunea naturală. Formatul general:
unde domeniul de selecţie poate fi: ALL (vor fi returnate toate înregistrările),
DISTINCT, DISTINCTROW (vor fi afişate doar înregistrările distincte), TOP n
[PERCENT] (vor fi returnate doar primele n înregistrări sau un procent din
numărul total de înregistrări, înregistrările fiind ordonate cu ajutorul clauzei
Order By).
În acest caz, înregistrările unui tabel se combină rând pe rând cu toate
înregistrările din celălalt table (se efectuează produsul cartezian), relaţia dintre
cele două tabele fiind stabilită ulterior, prin condiţia de joncţiune specificată în
clauza Where.
SELECT [domeniu_selectie] lista_campuri FROM numet1, numet2, ...
WHERE conditie_jonctiune [AND criterii_de_selectie];
195
În mod uzual, compunerile de tabele au la bază condiţii de tipul cheie primară-
cheie străină.
Considerând tabela Studenti creată anterior, se consideră tabela Centrepractică,
cu structura: IDcentru, Den_centru, Adresa, Localitate, NumeTutore. În tabela
studenţi se va adăuga câmpul IDcentru (unui centru de practică sunt arondaţi
mai mulţi studenţi).
Exemplul 1: Să se afişeze numele tutorelui şi a studenţilor arondaţi acestuia.
SELECT NumeTurore, nume_prenume
FROM studenti, Centrepractica
WHERE studenti.IDcentru=Centrepractica.IDcentru;
Exemplul 2: Să se afişeze numărul şi numele centrelor de practică din
Timişoara şi CNP-ul studenţilor.
SELECT Centrepractica.IDcentru, Den_centru, CNP
FROM studenti, Centrepractica
WHERE studenti.IDcentru=Centrepractica.IDcentru AND
Centrepractica.localitate=‟Timisoara‟;
O altă abordare a jocţiunilor împarte compunerile tabelelor în:
interne (INNER JOIN) – liniile celor două tabele se combină pe baza
valorilor identice ale câmpurilor corespondente;
externe (OUTER JOIN) – destul de rar utilizate, sunt de două tipuri: de
stânga LEFT [OUTER] JOIN şi de dreapta RIGHT [OUTER] JOIN.
Acestea produc linii în setul de rezultate chiar dacă condiţia de legătură
nu este verificată. Setul de înregistrări rezultat conţine liniile celor două
tabele, combinate pe baza valorilor identice ale câmpurilor de legătură,
la care se adaăugă înregistrările fără corespondent în tabelul care
constituie fie membrulstâng al compunerii, fie membrul drept.
Specificatorul Outer este opţional. În cazul compunerilor externe este
importantă poziţia tabelelor37
.
37 Florescu V. (coord.), Ionescu B. (coord.), Cozgarea G., et al – Baze de date, Editura Infomega,
Bucureşti, 2009, p.93
196
Formatul general al interogărilor ce include compuneri de tabele:
Se vor considera în continuare tabelele Studenti şi CentrePractica.
Exemplul 1: Să se afişeze numele tutorelui şi a studenţilor arondaţi acestuia.
SELECT NumeTurore, nume_prenume
FROM studenti INNER JOIN Centrepractica
ON studenti.IDcentru=Centrepractica.IDcentru;
Exemplul 2: Să se afişeze numărul şi numele centrelor de practică din
Timişoara şi CNP-ul studenţilor.
SELECT Centrepractica.IDcentru, Den_centru, CNP
FROM studenti INNER JOIN Centrepractica
ON studenti.IDcentru=Centrepractica.IDcentru
WHERE Centrepractica.localitate=‟Timisoara‟;
6.2.6.3 Agregări de date
Funcţiile de grup permit constuirea unor interogări de sintetizare a datelor
(Totals). Utilizatorul poate efectua calcule pentru grupuri de înregistrări care au
câmpuri cu aceeaşi valoare (de exemplu calcularea mediei studenţilor pe fiecare
grupă în parte).
Formatul general al instrucţiunii38
:
38 Năstase P., Cosăcescu L., Covrig L., et al – Tehnologia bazelor de date Access 2000, Editura
Economică, Bucureşti, 2000, p. 197
SELECT [domeniu_selectie] lista_campuri
FROM numet1
{INNER│LEFT[OUTER]│RIGHT[OUTER]} JOIN numet2 ON conditie_jonctiune
[WHERE criterii_de_selectie];
SELECT [domeniu_selectie] [functie_agregata (numec1) AS alias1] [,lista_selectie]
FROM numet1, numet2, ...
GROUP BY camp_de_grupare
[HAVING criteriu_de_grupare]
[WHERE criterii_de_selectie];
197
unde:
funcţiile agregate sunt cele amintite în cadrul instrucţiunilor SELECT
simple: COUNT, SUM, MIN, MAX, AVG, etc.
lista_selectie seminifică una sau mai multe funcţii agregate care au ca
argumente câmpuri ale bazei de date;
AS alias – asociază un pseudonim rezultatului utilizării funcţiei agregat;
GROUP BY – precizează câmpul sau câmpurile care vor fi criterii de
grupare (echivalentul liniei Total din cadrul unei interogări de
sintetizare a datelor);
HAVING – criteriu care va fi aplicat câmpului definit ca argument al
funcţiei agregat. Spre deosebire de clauza Where, criteriul va acţiona
înaintea grupării înregistrărilor.
Se vor considera în continuare tabelele Studenti şi CentrePractica.
Exemplul 1: Să se afişeze numele tutorelui şi numărul studenţilor arondaţi
acestuia.
SELECT Den_centru, NumeTutore, COUNT(CNP) AS Nrstud
FROM studenti, Centrepractica
GROUP BY Den_centru, NumeTutore
WHERE studenti.IDcentru=Centrepractica.IDcentru
ORDER BY NumeTutore;
Exemplul 2: Să se afişeze denumirea centrelor de practică din Timişoara, Arad
şi Deva care au mai mult de 5 studenţi şi numărul studenţilor arondaţi.
SELECT Den_centru, COUNT(CNP) As NrStud
FROM studenti INNER JOIN Centrepractica
ON studenti.IDcentru=Centrepractica.IDcentru
GROUP BY Den_centru
HAVING COUNT(CNP)>5
WHERE Centrepractica.localitate IN (‟Timisoara‟,‟Arad‟,‟Deva‟);
198
6.2.6.4 Subinterogări
O subinterogare este formată dintr-o interogare în care este plasată (imbricată) o
altă interogare.
Formatul general39
:
unde operator_comparatie poate fi =, <, <=, >, >=, <>, IN, LIKE, Between.
Observaţii: subinterogările trebuie incluse între paranteze rotunde;
subinterogările trebuie plasate în partea dreaptă a operatorului de
comparare;
nu se va adăuga o clauză ORDER BY într-o subinterogare;
atât în interogare cât şi în subinterogare, sursa datelor poate fi simplă
(un singur tabel) sau compusă (mai multe tabele), putând fi chiar
identică, necesitând crearea legăturilor dintre tabele;
clauzele Group By, Having şi Order pot să apară în ambele interogări;
dacă se utilizează operatorul IN, rezultatul subinterogării va fi o coloană
cu mai multe valori;
domeniul rezultatelor unei subinterogări poate fi influenţat prin
recurgerea la următoarele cuvinte cheie: ALL, ANY şi EXISTS. În
cazul în care se doreşte negarea condiţiei, se plasează operatorul NOT
în faţa specificatorului:
- ANY/SOME – comparaţia este adevărată dacă se găseşte cel puţin
o valoare în valorile din coloana returnată de subinterogare. În
cazul utilizării acestui specificator, ;
- ALL – comparaţia este adevărată dacă este verificată de toate
valorile din coloana returnată de subinterogare. În mod uzual,
comparaţia constă într-o inegalitate: <, <=, >, >=, <>. De
regulă, rezultatul comparaţiei este False;
39 Florescu V. (coord.), Ionescu B. (coord.), Cozgarea G., et al – Baze de date, Editura Infomega,
Bucureşti, 2009, p.101
SELECT [domeniu_selectie] lista_selectie
FROM numet1, numet2, ...
WHERE {numec1 │ expresie} operator_comparatie (SELECT {camp│expresie}
FROM numet1, numet2, ...
[WHERE criterii_selectie_subinterogare]);
199
- EXISTS – comparaţia este adevărată dacă subinterogarea
returnează cel puţin o valoare din coloana sau coloanele
returnate de subinterogare.
Tipuri de subinterogări
- subinterogări care au ca rezultat o singură linie (single-row subquery);
- subinterogări care au ca rezultat mai multe linii (multiple-row subquery);
- subinterogări care au ca rezultat mai multe coloane (multiple-column
subquery).
Se vor considera în continuare tabelele Studenti şi CentrePractica.
Exemplul 1: Să se afişeze numele studenţilor care sunt în acelaşi an cu
studentul cu CNP-ul 1711227658965 (s-a considerat câmpul CNP ca fiind de tip
Text).
SELECT nume_prenume
FROM studenti
WHERE an=(SELECT an
FROM Studenti
WHERE CNP=‟1711227658965‟);
Exemplul 2: Să se afişeze numele şi media studenţilor cu media anului anterior
mai mică decât media tuturor studenţilor.
SELECT nume_prenume, medie_an_anterior
FROM studenti
WHERE medie_an_anterior <=
(SELECT AVG(medie_an_anterior)
FROM Studenti);
Exemplul 3: Să se afişeze toate informaţiile despre studenţii care au media mai
mare decât toţi studenţii timişoreni.
SELECT *
FROM studenti
WHERE medie_an_anterior >
ALL (SELECT medie_an_anterior
FROM studenti
WHERE localitate=‟Timişoara‟);
200
6.2.7 Comanda UPDATE
Comanda Update permite modificarea valorilor unuia sau mai multor câmpuri.
Formatul general este:
Dacă clauza WHERE nu apare, vor fi modificate toate valorile câmpului
respectiv. În partea din dreapta egalităţii se poate folosi o expresie de calcul (o
formulă) care să aibă ca rezultat valoarea care va fi depozitată în câmpul
respectiv, sau valoarea poate fi obţinută ca rezultat al unei interogări (comanda
SELECT).
Exemplul 1: Să se modifice valoarea câmpului ţara din tabela Contracte în
Spania, pentru contractul cu numărul 1453.
UPDATE Contracte
SET tara=„Spania‟
WHERE nrc=1453;
Exemplul 2: Presupunând că în tabela Contracte s-a adăugat câmpul
suma_platita, să se micşoreze valoarea sumei cu 2% pentru contractul cu
numărul 1453 (clientului i se acordă o reducere de 2%).
UPDATE Contracte
SET suma_platita=suma_platita-(2/100*suma_platita)
WHERE nrc=1453;
UPDATE numet1 SET numec1={expresie1│(SELECT ...)}
numec2={expresie2│(SELECT ...)}
[WHERE conditie];
201
6.3 Concluzii
SQL este unul dintre cele mai puternice şi larg răspândite limbaje folosite
pentru definirea şi accesarea bazelor de date relaţionale. El permite consultarea
bazei de date sau efectuarea anumitor acţiuni prin simpla specificare a
comenzilor, fără a fi necesară specificarea unor modalităţi concrete sau a
algoritmilor de obţinere a rezultatului. SQL este suportat de diferite sisteme de
gestiune a bazelor de date cum ar fi: MS Access, MS SQL Server, DB2,
Informix (IBM), Oracle, MySql, etc, diferenţele dintre dialecte fiind minore40
.
6.4 Rezumatul capitolului
SQL nu se încadrează în categoria limbajelor de programare, fiind un limbaj de
aplicaţii, destinat bazelor de date relaţionale. Pronunţat „sequel”, a devenit un
standard pentru o gamă largă de sisteme de gestiune a bazelor de date. SQL este
un limbaj declarativ, utilizatorul descriind doar informaţiile pe care doreşte să le
obţină în urma interogării, fără a fi nevoie să stabilească modalităţile de a
ajunge la rezultatele dorite. Pe lângă manipulearea şi regăsirea datelor, se
efectuează operaţii complexe privind actualizarea şi administrarea bazei de date.
Sistemul de gestiune a bazelor de date Access 2007 acceptă utilizarea limbajului
de interogarea SQL. Dialectul Access conţine unele particularităţi în raport cu
standardul ANSI SQL, fiind conceput în special pentru crearea interogărilor de
selecţie. Existenţa interfeţei grafice QBE permite proiectarea facilă a unei
interogări complexe, informaţia astfel definită fiind transformată într-o
instrucţiune SQL41
.
40 Florescu V. (coord.), Ionescu B. (coord.), Cozgarea G., et al – Baze de date, Editura Infomega,
Bucureşti, 2009, p.66 41 Năstase P., Cosăcescu L., Covrig L., et al – Tehnologia bazelor de date Access 2000, Editura
Economică, Bucureşti, 2000, p. 189
202
6.5 Întrebări de autoevaluare din partea teoretică
1. Să se specifice avantajele utilizării instrucţiunilor SQL.
2. Să se descrie cele trei componente SQL.
3. Să se creeze următoarele tabele, precum şi relaţia dintre acestea:
discipline (codd, dend, an_studiu, sem, obs);note (nrmatr, codd, nota,
dataex).
4. Sa se insereze disciplina: codd = 2; dend = baze de date, precum si
notele a 2 studenţi la aceasta disciplină.
5. Să se şteargă una dintre notele înregistrate (se va şterge înregistrarea
corespunzătoare).
6. Să se elimine câmpul obs din structura tabelei discipline.
7. Să se afişeze disciplinele care se predau în anul 2, sem = 2.
8. Să se afiseze notele obţinute de către studentul cu nrmatr = 1001 la
disciplinele din anul 1. Se va afişa şi denumirea disciplinelor.
9. Să se afişeze mediile studenţilor luaţi în evidenţă.
203
6.6 Exemple
6.6.1. Problemă rezolvată – Produse
Să se creeze următoarea formă de meniu.
Fig. 2 – formularul Meniu
Rezolvare:
Se crează o nouă bază de date cu numele Produse. Se crează tabela Produse cu
următoarea structură: cod_p, den_p, um_p, stoc_p, pret_p, cod_magazin. Se vor
introduce 3 înregistrări în tabelă.
Se crează un nou formular folosind de pe bara de meniuri opţiunea Create,
butonul Form Design.
De pe panglică se verifică dacă butonul Use Control Wizards este selectat.
Acesta trebuie să fie deselectat pentru a permite crearea manuală a controalelor,
fără ajutorul asistentului. În continuare se alege butonul Button, executându-se
un clic pe formă. Apelând meniul contextual asociat butonului de comandă de
pe formă, se selectează opţiunea Properties şi se modifică proprietăţile Name şi
Caption pentru fiecare buton în parte. În total sunt 8 butoane de comandă,
fiecare având un alt Name şi Caption. Proprietatea Name va fi completată
întotdeauna cu prefixul cmd urmat de un cuvânt sau alăturare de cuvinte
semnificativă pentru acţiunea executată de buton, fără caracterul spaţiu între ele.
Numele butoanelor vor fi în ordine: cmdDesPr, cmdDesPr1, cmdInsPr,
cmdModDen, cmdCrTNou, cmdViz, cmdValoare, cmdIesire. Proprietatea
Caption va fi completată cu textul care apare pe butonul corespunzător din
figura 1 şi admite orice fel de caractere, inclusiv caracterul spaţiu. Se selectează
butonul dorit, iar în fereastra Property Sheet se modifică cele două proprietăţi
aflate pe pagina All. Dacă fereastra Property Sheet nu apare, ea poate fi
204
activată folosind butonul Property Sheet de pe panglică, atunci când este
selectată opţiunea de meniu Design.
Se salvează forma cu numele Meniu (butonul Save din dreapta butonului
Office).
Pentru a introduce instrucţiuni ataşate butoanelor trebuie apelat editorul Visual
Basic. Pentru aceasta, se apelează meniul contextual al fiecărui buton în parte
(clic cu butonul din dreapta al mouse-ului), se alege Build Event, Code
builder, OK.
Mediul de programare Visual Basic Application arată ca în figura următoare:
Fig. 3 – Mediul de lucru Visual Basic
Deasupra procedurii se tastează:
DIM v_cod as Integer, v_den as String, v_um as String
şi se apasă tasta Enter.
Pentru fiecare buton în parte se scrie codul corespunzător. Tot ce este scris după
caracterul apostrof semnifică un comentariu, este un mesaj pentru programator,
o explicaţie. Dacă acesta apare, nu influenţează cu nimic execuţia programului,
dar poate fi ignorat dacă se consideră oportun.
Private Sub cmdDesPr_Click()
' se deschide tabela Produse pt. vizualizare in Design
DoCmd.OpenTable "Produse", acViewDesign
End Sub
205
DoCmd este o comandă Visual Basic care permite execuţia unei comenzi (Do
Command). Open Table este comanda care permite deschiderea unei tabele.
Numele tabelei este scris între ghilimele, iar parametrul acViewDesign
specifică deschiderea tabelei în modul Design, nu în Datasheet View.
Private Sub cmdDesPr1_Click()
' se deschide tabela Produse pt. vizualizare in Datasheet View
DoCmd.OpenTable "Produse"
End Sub
Private Sub cmdInsPr_Click()
'adaugarea unei noi inregistrari
DoCmd.RunSQL "insert into produse values (cod_produs, den_produs,
um_produs, stoc_produs, pret_produs, cod_mag)"
End Sub
Comanda RunSQL este comanda care permite execuţia unei instrucţiuni SQL
(Structured Query Language). Dintre cel mai des utilizate instrucţiuni SQL
amintim: SELECT, INSERT INTO, UPDATE, ALTER TABLE, DELETE
TABLE. Toate instrucţiunile SQL se scriu între ghilimele, simbolul ; de la
sfârşitul comenzilor SQL fiind ignorat.
În acest caz s-a folosit instrucţiunea INSERT INTO, care permite introducerea
unei singure înregistrări în tabela Produse. Pentru fiecare din parametrii din
paranteză, aceştia fiind consideraţi nişte variabile, este creat automat un
InputBox (o casetă de introducere a valorilor de la tastatură) care permite
citirea lor de la tastatură. Comanda Insert Into conţine cuvântul Values, iar
numărul parametrilor din paranteză (care ca nume sunt diferite de numele
câmpurilor din tabela Produse) trebuie să fie acelaşi cu numărul câmpurilor din
tabelă şi să corespundă ca tip de valori şi semnificaţie. De exemplu, dacă în
tabela Produse avem 5 câmpuri, în paranteză, după cuvântul Value, trebuie să
avem 5 parametrii, în aceeaşi ordine.
Private Sub cmdModDen_Click()
'modificarea denumirii unui produs la care este cunoscut codul
v_cod = InputBox("Introduceti codul produsului la care doriti sa ii modificati
denumirea:")
DoCmd.RunSQL "update produse set den_p=denumire where cod_p=" &
v_cod
End Sub
206
Pentru a modifica denumirea unui produs pentru care se cunoaşte codul, se
utilizează o variabilă pentru a citi de la tastatură codul respectiv. Variabila
v_cod este definită la începutul aplicaţiei, în secţiunea DIM (de dimensionare a
variabilelor). Cu ajutorul unei casete de introducere a datelor (Inputbox),
valoarea variabilei cod produs este reţinută în variabila v_cod. Pentru a
modifica valoarea denumirii produsului, se utilizează instrucţiunea Update.
După cuvântul predefinit SET avem o atribuire. Membrul din stânga este
numele câmpului den_p din tabela Produse, iar în partea din dreapta avem un
parametru. Pentru parametru, Access construieşte automat o casetă de
introducere a datelor, permiţând citirea acestuia de la tastatură. Valoarea citită
va înlocui valoarea veche a denumirii. Dacă nu este adăugată condiţia Where,
toate denumirile produselor vor fi modificate. Pentru a modifica doar un anumit
câmp, în cadrul condiţiei Where este specificată o condiţie logică. Cod_p este
câmpul cod produs din tabela Produse. Pentru a se utiliza valoarea reţinută în
variabila v_cod, acesta va fi scris în afara ghilimelelor. Simbolul & este
simbolul care semnifică concatenarea mai multor valori de tip şir de caractere.
Private Sub cmdCrTNou_Click()
'selectarea produselor cu stoc 0 si crearea unei tabele cu aceste produse
DoCmd.RunSQL "Select cod_p, den_p, um_p, stoc_p, pret_p, cod_m into
StocNul from produse where stoc_p=0"
DoCmd.OpenTable "StocNul"
End Sub
În cazul instrucţiunii SQL SELECT, este necesară introducerea clauzei INTO
(care crează automat o nouă tabelă ca rezultat al interogării). Noua tabelă creată
se numeşte StocNul. Condiţia de filtrare este ca stocul produsului să fie zero.
Dacă în tabela Produse nu există nici o înregistrare în care stocul produsului să
fie zero, noua tabelă va fi creată dar nu conţine nici o înregistrare. Noua tabelă
creată va fi deschisă pentru a fi vizualizată.
Private Sub cmdViz_Click()
'vizualizarea produselor cu codul >= o valoare introdusa de la tastatura
v_cod = InputBox("Introduceti un cod pentru a fi afisate produsele cu codul
mai mare decat aceasta valoare")
DoCmd.RunSQL "Select cod_p,den_p,um_p,stoc_p, pret_p, cod_m into
Temp1 from produse where cod_p>=" & v_cod
DoCmd.OpenTable "Temp1"
End Sub
207
Pentru a citi o valoare de la tastatură este necesară declararea unei variabile în
care valoarea să fie stocată. Variabila poartă numele v_cod. Valoarea este citită
de la tastatură prin intermediul comenzii InputBox (crearea unei casete de
introducere a textului). Comanda Select crează o nouă tabelă numită Temp1,
fiind selectate doar câmpurile definite în lista câmpurilor (cod_p, den_p, um,
stoc, pret_u, cod_m) şi acele înregistrări care verifică condiţia Where (codul
produsului să fie mai mare decât valoarea care a fost introdusă în variabila
v_cod). Tabela Temp1 va fi apoi deschisă pentru a vizualiza rezultatul
interogării.
Private Sub cmdValoare_Click()
DoCmd.RunSQL "select cod_p, den_p, um_p, pret_p, stoc_p, pret_p*stoc_p
as valoare into Valoare from produse"
DoCmd.OpenTable "Valoare"
End Sub
Acest buton permite calcularea unui câmp în cadrul unei interogări. Acesta se
scrie în lista de câmpuri, începând cu formula de calcul, urmată de cuvântul
predefinit AS şi numele care se doreşte să apară în capul de tabel ca nume de
câmp: valoare. Rezultatul interogării este un nou tabel cu numele Valoare.
Pentru a vedea rezultatul interogării se deschide tabelul Valoare.
Private Sub cmdIesire_Click()
DoCmd.Quit
End Sub
Comanda Quit permite închiderea aplicaţiei.
Pentru a putea utiliza butoanele trebuie setat nivelul de securitate astfel încât să
permită utilizarea codurilor Visual Basic Application. Pentru aceasta, de pe
bara Security Warning se selectează butonul Options..., selectând opţiunea
Enable this content.
208
Fig. 4 – Setarea nivelului minimal de securitate
6.6.2 Problemă rezolvată – Aprovizionare
Să se creeze o bază de date cu numele Aprovizionare. Să se creeze o formă de
meniu cu butoane de comandă – figura 1 – care să permită următoarele operaţii:
1. Crearea tabelelor necesare gestionării procesului de recepţie a
materialelor. Toate materialele achiziţionate de firmă sunt cuprinse într-
un nomenclator de materiale în care sunt specificate: codul materialului,
denumire material, unitate de măsură şi clasa de calitate. În momentul
realizării unei aprovizionări se întocmeşte o notă de recepţie pe care
sunt consemnate: numărul recepţiei, data recepţiei, denumirile
materialului, cantităţile şi preţurile aferente fiecărui material;
2. Inserarea înregistrărilor în tabele (3 înregistrări în tabelele de referinţă,
mai multe înregistrări în tabela referită).
3. Să se modifice structura tabelei receptiemateriale adăugându-se un
câmp denumit cotaTVA. Să se şteargă câmpul clasa din tabela
Materiale.
4. Să se modifice toate valorile câmpului cotaTVA cu valoarea 0,24. Să se
modifice data pentru numărul de receptie 245369 în 23.11.2011.
5. Să se afişeze toate produsele cu unitatea de măsură bucăţi. Să se afişeze
toate notele de recepţie din data de 25.11.2011, inclusiv denumirea
produselor, cantitatea şi preţul, calculându-se valoarea. Să se afişeze
pentru fiecare număr de recepţie valoarea totală (suma valorilor).
209
6. Să se şteargă toate notele de recepţie corespunzătoare codului material
111 din tabela receptiemateriale. Să se şteargă toate înregistrările din
tabela receptiemateriale.
7. Să se şteargă toate tabele din baza de date (inclusiv cele create în cadrul
interogărilor).
Fig. 5 – formularul Meniu
Rezolvare:
Se va crea o nouă bază de date cu numele Aprovizionare. Table 1 se închide,
fără a fi salvat. Tabelele nu vor fi create cu ajutorul instrumentelor vizuale, ci
tot cu ajutorul comenzilor SQL.
Construind matricea dependenţelor funcţionale se ajunge la următoarea
structură a bazei de date – figura 6.
Fig. 6 – Fereastra Relationship – Baza de date Aprovizionare
Pentru a crea un formular nou, se selectează opţiunea de meniu Create, apoi
butonul Form Design. Se salvează formularul cu numele Meniu.
1. Pentru a adăuga primul buton de comandă pe formă se deselectează
butonul de pe panglică, se alege butonul şi
210
se execută clic pe formular. Se apelează meniul contextual asociat
butonului şi se alege opţiunea Properties. În fereastra Property Sheet
se modifică proprietăţile Name: cmdCreare şi Caption: Crearea
tabelelor – figura 7.
Fig. 7 – Butonul cmdCreare
Pentru a asocia cod butonului, se apelează meniul contextual al butonului şi se
alege opţiunea Build Event/Code builder.
Codul asociat butonului de Creare este detaliat în continuare:
Private Sub cmdCreare_Click()
DoCmd.RunSQL "CREATE TABLE materiale (codm integer
CONSTRAINT pk_codm PRIMARY KEY CONSTRAINT nn_codm NOT
NULL, denm TEXT(15), um TEXT(10), clasa TEXT(10))"
MSG = MsgBox("Tabela materiale a fost creata!", vbOKOnly)
DoCmd.RunSQL "CREATE TABLE receptii (nrrec INTEGER
CONSTRAINT pk_nrrec PRIMARY KEY CONSTRAINT nn_nrrec NOT
NULL, datarec DATE)"
MSG = MsgBox("Tabela receptii a fost creata!", vbOKOnly)
DoCmd.RunSQL "CREATE TABLE receptiemateriale (nrrec
INTEGER CONSTRAINT fk_nrrec REFERENCES receptii(nrrec), codm
INTEGER CONSTRAINT fk_codm REFERENCES materiale(codm), cantitate
INTEGER, pret_unitar NUMBER, CONSTRAINT pk_recmat PRIMARY
KEY(nrrec,codm))"
MSG = MsgBox("Tabela receptiemateriale a fost creata!", vbOKOnly)
End Sub
211
Observaţii:
Fiecare constrângere (PRIMARY KEY, NOT NULL, FOREIGN KEY)
a fost denumită cu un nume format din prefixul pk pentru Primary Key,
nn pentru Not Null sau fk pentru Foreign Key. Înainte de a specifica
constrângerea se adaugă cuvântul predefinit CONSTRAINT apoi
numele constrângerii. În cazul unei chei primare compuse,
constrângerea este lăsată la urmă, după ultimul câmp şi definită ca fiind
combinaţia dintre nrrec şi codm.
Relaţia dintre tabele este creată de la tabela referită (copil) la tabela de
referinţă (părinte), setându-se o constrîngere de tip FOREIGN KEY pe
câmpul comun, utilizându-se cuvântul predefinit REFERENCES, urmat
de numele tabelei de referinţă (părinte) şi câmpul de legătură din acea
tabelă. Ambele câmpuri trebuie să fie definite ca fiind de acelaşi tip.
MSG este un nume de variabilă, care va lua valoarea apăsării butonului
OK specificat în partea dreaptă a egalităţii. În partea din dreapta se
utilizeză o comanda care afişează pe ecran mesajul scris între ghilimele
şi afişează doar butonul OK.
2. Pentru a insera înregistrări în tabele se adaugă un nou buton pe formă
(se selectează butonul Button, apoi se execută clic pe formular). Se
modifică proprietăţile butonului: Name: cmdInserare şi Caption:
Inserare înregistrări. Pentru a asocia cod butonului, se apelează
meniul contextual al acestuia, se alege opţiunea Build Event/Code
Builder.
Codul asociat butonului cmdInserare este prezentat în continuare:
Private Sub cmdInserare_Click()
DoCmd.RunSQL "INSERT INTO materiale VALUES (111,
'imprimanta','buc','cal.I')"
DoCmd.RunSQL "INSERT INTO materiale VALUES (112,
'mouse','buc','cal.I')"
DoCmd.RunSQL "INSERT INTO materiale VALUES (113,
'hartie','buc','cal.I')"
MSG = MsgBox("S-au introdus inregistrari in tabela materiale!",
vbOKOnly)
DoCmd.OpenTable "materiale"
DoCmd.RunSQL "INSERT INTO receptii VALUES
(245369,#19/11/2011#)"
212
DoCmd.RunSQL "INSERT INTO receptii VALUES
(245370,#25/11/2011#)"
DoCmd.RunSQL "INSERT INTO receptii VALUES
(245371,#25/11/2011#)"
MSG = MsgBox("S-au introdus inregistrari in tabela receptii!",
vbOKOnly)
DoCmd.OpenTable "receptii"
DoCmd.RunSQL "INSERT INTO receptiemateriale VALUES
(245369,111, 200, 500)"
DoCmd.RunSQL "INSERT INTO receptiemateriale VALUES
(245369,112, 25, 50)"
DoCmd.RunSQL "INSERT INTO receptiemateriale VALUES
(245369,113, 1000, 7)"
DoCmd.RunSQL "INSERT INTO receptiemateriale VALUES
(245370,111, 10, 560)"
DoCmd.RunSQL "INSERT INTO receptiemateriale VALUES
(245370,112, 15, 55)"
DoCmd.RunSQL "INSERT INTO receptiemateriale VALUES
(245371,111, 1, 600)"
DoCmd.RunSQL "INSERT INTO receptiemateriale VALUES
(245371,112, 10, 60)"
DoCmd.RunSQL "INSERT INTO receptiemateriale VALUES
(245371,113, 1, 100)"
MSG = MsgBox("S-au introdus inregistrari in tabela
receptiemateriale!", vbOKOnly)
DoCmd.OpenTable "receptiemateriale"
End Sub
3. Pentru a modifica structura tabelelor adaugă un nou buton pe formă (se
selectează butonul Button, apoi se execută clic pe formular). Se
modifică proprietăţile butonului: Name: cmdModStruct şi Caption:
Modificarea structuriilor tabelelor. Pentru a asocia cod butonului, se
apelează meniul contextual al acestuia, se alege opţiunea Build
Event/Code Builder.
213
Codul asociat butonului cmdModStruct este prezentat în continuare:
Private Sub cmdModStruct_Click()
DoCmd.RunSQL "ALTER TABLE receptiemateriale ADD COLUMN
cotatva number"
DoCmd.OpenTable "receptiemateriale", acViewDesign
MSG = MsgBox("S-a adaugat campul cotatva!", vbOKOnly)
DoCmd.RunSQL "ALTER TABLE materiale DROP COLUMN clasa"
DoCmd.OpenTable "materiale", acViewDesign
MSG = MsgBox("S-au sters campul clasa!", vbOKOnly)
End Sub
4. Pentru a modifica valorile din tabele se adaugă un nou buton pe formă
(se selectează butonul Button, apoi se execută clic pe formular). Se
modifică proprietăţile butonului: Name: cmdModifValori şi Caption:
Modificarea valorilor din tabele. Pentru a asocia cod butonului, se
apelează meniul contextual al acestuia, se alege opţiunea Build
Event/Code Builder.
Codul asociat butonului cmdModifValori este prezentat în continuare:
Private Sub cmdModifValori_Click()
DoCmd.RunSQL "UPDATE receptiemateriale SET cotaTVA=0.24"
DoCmd.OpenTable "receptiemateriale"
MSG = MsgBox("S-a modificat valoarea campului cotaTVA!",
vbOKOnly)
DoCmd.RunSQL "UPDATE receptii SET datarec=#23/11/2011#
WHERE nrrec=245369"
DoCmd.OpenTable "receptii"
MSG = MsgBox("S-a modificat valoarea campului datarec=23.11.2011
pt nrrec=245369!", vbOKOnly)
End Sub
5. Pentru a vizualiza interogările se adaugă un nou buton pe formă (se
selectează butonul Button, apoi se execută clic pe formular). Se
modifică proprietăţile butonului: Name: cmdInterogari şi Caption:
Interogari. Pentru a asocia cod butonului, se apelează meniul
contextual al acestuia, se alege opţiunea Build Event/Code Builder.
214
Codul asociat butonului cmdInterogari este prezentat în continuare:
Private Sub cmdInterogari_Click()
DoCmd.RunSQL "SELECT * INTO T1 FROM materiale WHERE
um='buc'"
DoCmd.OpenTable "T1"
MSG = MsgBox("Produsele cu UM=buc", vbOKOnly)
DoCmd.RunSQL "SELECT receptii.nrrec, datarec, denm, cantitate,
pret_unitar, cantitate*pret_unitar*cotaTVA as valoare INTO T2 FROM
materiale, receptiemateriale, receptii WHERE
receptii.nrrec=receptiemateriale.nrrec AND
materiale.codm=receptiemateriale.codm AND datarec=#25/11/2011#"
DoCmd.OpenTable "T2"
MSG = MsgBox("Calcularea valorii", vbOKOnly)
DoCmd.RunSQL "SELECT receptii.nrrec,
SUM(cantitate*pret_unitar*cotaTVA) as valoare_nota_receptie INTO
T3 FROM receptiemateriale, receptii WHERE
receptii.nrrec=receptiemateriale.nrrec GROUP BY receptii.nrrec"
DoCmd.OpenTable "T3"
MSG = MsgBox("valoare pe fiecare nota de receptie in parte",
vbOKOnly)
End Sub
Observaţii:
Specificatorul * semnifică afişarea tuturor câmpurilor din tabela
respectivă.
Clauza INTO creează o nouă tabelă în care rezultatul interogării va fi
depus. Dacă se doreşte vizualizarea acestuia, tabelul trebuie deschis.
Dacă datele sunt extrase din mai multe tabele, în cazul în care este
specificat un câmp care apare în ambele tabele, este necesară
specificarea aparteneţei lui (de exemplu receptii.nrc).
Dacă se doreşte afişarea datelor din mai multe tabele, este necesară
specificarea condiţiei de legătură dintre tabele. În acest caz s-a ales
joncţiunea naturală. Condiţia de legătură apare în cadrul clauzei
WHERE, operatorul dintre condiţii fiind AND.
Dacă se doreşte afişarea unor totaluri pe grupe de înregistrări, se
utilizează clauza Group By. Aceasta este specificată după clauza
Where. Câmpul specificat ca şi criteriu de grupare va apare ca primul
câmp selectat în lista câmpurilor.
215
6. Pentru a şterge înregistrări din tabele se adaugă un nou buton pe formă
(se selectează butonul Button, apoi se execută clic pe formular). Se
modifică proprietăţile butonului: Name: cmdStergereValori şi
Caption: Stergere valori. Pentru a asocia cod butonului, se apelează
meniul contextual al acestuia, se alege opţiunea Build Event/Code
Builder.
Codul asociat butonului cmdInterogari este prezentat în continuare:
Private Sub cmdStergereValori_Click()
DoCmd.RunSQL "DELETE FROM receptiemateriale WHERE
codm=111"
DoCmd.OpenTable "receptiemateriale"
MSG = MsgBox("S-au sters notele de receptie cu codm=111!",
vbOKOnly)
DoCmd.RunSQL "DELETE FROM receptiemateriale"
DoCmd.OpenTable "receptiemateriale"
MSG = MsgBox("S-au sters toate produsele de pe notele de receptie",
vbOKOnly)
End Sub
7. Pentru a şterge tabelele se adaugă un nou buton pe formă (se selectează
butonul Button, apoi se execută clic pe formular). Se modifică
proprietăţile butonului: Name: cmdStergereTabele şi Caption:
Stergere tabele. Pentru a asocia cod butonului, se apelează meniul
contextual al acestuia, se alege opţiunea Build Event/Code Builder.
Codul asociat butonului cmdInterogari este prezentat în continuare:
Private Sub cmdStergereTabele_Click()
DoCmd.RunSQL "DROP TABLE T1"
DoCmd.RunSQL "DROP TABLE T2"
DoCmd.RunSQL "DROP TABLE T3"
DoCmd.RunSQL "DROP TABLE receptiemateriale"
DoCmd.RunSQL "DROP TABLE materiale"
DoCmd.RunSQL "DROP TABLE receptii"
MSG = MsgBox("S-au sters toate tabelele!", vbOKOnly)
End Sub
216
6.6.3 Problemă propusă – Bibliotecă
O bibliotecă doreşte să-şi informatizeze activitatea de împrumut a cărţilor.
Pentru fiecare carte se cunosc titlul cărţii, autorii, editura, anul publicării şi
numărul de exemplare. Pentru fiecare abonat se cunoaşte CNP-ul, numele, data
naşterii, adresa, telefonul şi oraşul. Pentru fiecare împrumut se completează o
cerere de împrumut. Pe această cerere apar data împrumutului, cartea
împrumutată, abonatul (cititorul), şi data de returnare a cărţii. Pe o cerere de
împrumut apare o singură carte.
Să se creeze o formă de meniu cu butoane care să permită:
1. crearea tabelelor;
2. inserarea datelor în tabele;
3. vizualizarea informaţiilor din tabele;
4. adăugarea unui câmp cu numele gen în tabela Cărţi;
5. completarea câmpului gen cu valoarea Beletristică pentru cartea cu
titlul “La Medeleni”;
6. vizualizarea titlurilor cărţilor împrumutate astăzi;
7. vizualizarea numelui abonaţilor şi numărul cărţilor editate anul acesta
care au fost împrumutate de aceştia;
8. vizualizarea autorilor cărţilor împrumutate în săptămâna în curs;
9. ştergerea cererii de împrumut cu numărul 123;
10. ştergerea tuturor tabelelor;
11. închiderea formei.
6.6.4 Problemă propusă – Amenajări interioare O firmă de construcţii şi amenajări interioare solicită informatizarea activităţilor
de contractare a lucrărilor. Firma îşi prezintă oferta sub forma unei liste de
lucrări pe care este în măsură să le efectueze pentru clienţii săi. Pentru fiecare lucrare se cunoaşte codul lucrării, denumirea lucrării şi costul acesteia. Între
firmă şi beneficiari se încheie contracte. Pentru fiecare contract sunt cunoscute
numărul contractului, codul beneficiarului, codul lucrării, data, data începerii
execuţiei, termen execuţie. Un beneficiar poate comanda mai multe lucrări diferite, deci poate încheia cu firma mai multe contracte. Pentru beneficiar se
cunosc câmpurile cod beneficiar, denumire beneficiar, adresă, telefon, cod
curent bancă. Să se creeze un formular cu butoane de comandă care să permită:
1. crearea tabelelor;
2. inserarea datelor în tabele;
3. vizualizarea informaţiilor din tabele;
217
4. adăugarea unui câmp cu numele alte clauze în tabela Contracte;
5. completarea câmpului observaţii cu valoarea “plătit integral” pentru
comanda cu codul 1234;
6. vizualizarea comenzilor care expiră luna aceasta;
7. vizualizarea numelui beneficiarilor şi suma totală plătită de aceştia;
8. vizualizarea numărului beneficiarilor care au încheiat contracte care
expiră anul acesta;
9. ştergerea comenzii cu numărul 1234;
10. ştergerea tuturor tabelelor;
11. închiderea formei.
218
219
BIBLIOGRAFIE
1. Adamski J., Finnegan K. (2006) – New Perspectives on Microsoft Office
Access 2003, Second Edition, Thomson Course Technology, Boston
2. Bandu I. (2009) – Baze de date Access 2007, Editura Mirton, Timişoara
3. Biriescu S. (2010) – Baze de date în mediul economic: studii de caz, Editura
Mirton, Timişoara
4. Boldea M., Boldea C.M. (2010) – Access 2007, Editura Mirton, Timişoara
5. Coronel, C., Morris, St., Rob, P. (2009). – Database Systems: design, implementation, and management, Ninth Edition. Publisher Course
Technologies
6. Delobel, C., Adiba, M., (1982) – Bases de donnees at systemes relationnels, Dunod Informatique, Paris
7. Hurbean L., Dănăiaţă D., Negovan A.-M. (2008) – Baze de date: de la teorie
la practică utilizând Access 2007, Editura Mirton, Timişoara
8. Florescu V. (coord.), Ionescu B. (coord.), Cozgarea G., et al (2009) – Baze de
date, Editura Infomega, Bucureşti
9. Fotache M. (1997) – Baze de date relaţionale, Editura Junimea, Iaşi
10. Giulvezan C., Mircea G., Târnăveanu D., Margea C. (2009) – Baze de date,
Editura Universităţii de Vest, Timişoara
11. Fleming, Candace, von Halle, Barbara (1989) – Handbook of
Relational Database Design, Addison-Wesley
12. Ionescu F. (2004) – Baze de date relaţionale şi aplicaţii, Editura Tehnică,
Bucureşti
13. Johnson S., trad. Mănăstireanu M. (2008) – Microsoft Office Access 2007,
Editura Niculescu, Bucureşti
14. Johnson S., trad. Biriş R. (2008) – Microsoft Office Access 2007, Editura
Teora, Bucureşti
15. Lungu, I., Bodea, Constanţa, Bădescu, Georgeta, Ioniţă, Cristina (1995) – Baze de date. Organizare, proiectare şi implementare, Editura
All Educaţional
16. Năstase P., Cosăcescu L., Covrig L., et al (2000) – Tehnologia bazelor de date
Access 2000, Editura Economică, Bucureşti
17. Pescaru, V., Catona, I., Duţă, D., Popescu, C., Satran, I., (1976) –
Fişiere, baze şi bănci de date, Editura Tehnică, Bucureşti
18. Roman S. (2002) – Access Database Design & Programming, 3rd Edition,
O‟Reilley
19. Stanciu A. (coord.), Mihai F, Mangiuc D, et al (2009) – Baze de date Access
2007: studii de caz, Editura Infomega Bucureşti
220
20. Tamaş I. (coord.), Stanciu V., Gheorghe M. (2010) – Access 2007 – Proiectare
şi realizare pas cu pas, Editura Infomega, Bucureşti
21. Whitehorne M., Marklyn B. (2007) – Inside Relational Databases with
Examples in Access, Springer
221
GLOSAR DE TERMENI
Baza de date Colecţie de date aflate în interdependenţă,
împreună cu descrierea datelor şi a relaţiilor dintre
ele.
SGBD Pachet software de nivel înalt, care permite
proiectarea, construirea şi administrarea bazelor de
date dedicate rezolvării problemelor din cele mai
variate domenii ale vieţii reale
SGBDR Este o un sistem de gestiune a bazelor de date care
foloseşte modelul relaţional.
Nivelul intern al bazei de
date
Este o colecţie de fişiere conţinând datele fizice la
care se adaugă diverse structuri auxiliare menite să
asigure accesul operativ la date.
Nivelul conceptual Conţine structura logică a bazei de date, aşa cum
este ea văzută de administratorul bazei de date.
Nivelul extern Este ceea ce vede acesta din baza de date, sau modul
cum vede acesta baza de date.
Proiectarea unei baze de
date
Procesul de creare a unui proiect pentru baza de date
care să asigure desfăşurarea corectă a activităţilor şi
rezolvarea cerinţelor utilizatorilor.
Entitate Mulţimea tuturor elementelor de un anumit tip (care
prezintă aceleaşi caracteristici).
Instanţă a unei entităţi Înţelegem un singur element, bine individualizat,
unic, din mulţimea elementelor care formează
entitatea respectivă.
Atribut O caracteristică a unei entităţi.
Cheia primară Un atribut sau cea mai mică mulţime de atribute ale
unei entităţi care iau, fiecare instanţă a entităţii
respective, o valoare şi numai una,
Relaţie într-o bază de
date
O legătură logică între două sau mai multe entităţi.
Normalizare tehnică pentru proiectarea bazelor de date
relaţionale
Redundanţă o proprietate a unei colecţii de date care se referă la
faptul că unele componente sunt memorate de mai
multe ori pe suportul de memorare
222
Forma normală 1 (FN1) O relaţie se află în FN1 dacă toate atributele sale
sunt atomice (nu se mai pot descompune) şi
nerepetitive
Forma normală 2 (FN2) O relaţie se află în FN2 dacă respectă FN1 şi orice
atribut non-cheie este complet dependent de cheia
primară a relaţiei (interzice dependenţe funcţionale
parţiale)
Forma normală 3 (FN3) O relaţie se află în FN3 dacă respectă FN2 şi toate
atributele non-cheie sunt dependente direct de cheia
primară (interzice dependenţele funcţionale
tranzitive)
Câmp o unitate elementară sau o categorie cum ar fi
titlurile cărţilor sau numerele de telefon
Înregistrare un set complet de date (câmpuri) care se referă la o
persoană, loc, eveniment, idee
Tabel structură elementare în care sunt stocate datele în
cadrul unei baze de date
Interogare structură care permite efectuarea unei acţiuni rapide
(obţinerea unor informaţii sau efectuarea unor
modificări) asupra unei tabele sau mai multor tabele
Formular fereastră atractivă folosită pentru a consulta sau
actualiza datele dintr-un tabel sau o structură de
interogare
Raport structură care permite tipărirea informaţiilor din
tabele sau interogări
Macrocomandă mini-programe care automatizează sarcinile curente
(formate dintr-o suită de acţiuni)
Modul fişier care conţine cod Visual Basic Application
SQL (Structured Query
Language)
este un limbaj de interogări şi gestionare a bazelor
de date relaţionale
CREATE TABLE permite crearea unei tabele
ALTER TABLE permite modificarea structurii unei tabele –
adăugarea, ştergerea unor câmpuri sau modificarea
proprietăţilor acestora
DROP TABLE permite ştergerea fizică a înregistrărilor
INSERT INTO permite inserarea unei înregistări într-o tabelă
DELETE Permite ştergerea înregistrărilor dintr-o tabelă,
structura tabelei rămânând neschimbată
223
SELECT permite selectarea înregistrărilor din una sau mai
multe tabele, în funcţie de anumite criterii,
permiţând agregarea datelor şi crearea
subinterogărilor
UPDATE permite modificarea valorilor unui câmp dintr-o
tabelă