Program de formare continuă Phare 2006 Coeziune Economică şi Socială

„Formare şi dezvoltare profesională în mediul defavorizat” - C.C.D. BACĂU

MODULUL V – Baze de date

Obiective:
- Să înţeleagă noţiunile de bază privind bazele de date;
- Să utilizeze o bază de date pe un computer personal;
- Să proiecteze şi să planifice o bază de date simplă folosind o
aplicaţie standard de realizare de baze de date;
- Să extragă informaţii dintr-o bază de date existentă folosing
instrumente de interogare, selecţie şi sortare existente în cadrul
acesteia;
§

V.1. Pregătirea

Obiective:
- Înţelegerea conceptelor ce stau la baza funcţionării unui Sistem de
Gestiune a Bazelor de Date;
- Pornirea unei aplicaţii de bază de date;
- Deschiderea unei baze de date existente cu caracteristici
standard;
- Să modifice o înregistrare dintr-o bază de date şi să salveze;
- Să închidă o bază de date;

V.1.1. Concepte

Bazele de date (BD) reprezintă suportul fundamental pentru sistemele informatice (SI).
Modelarea BD constituie un subiect vast tratat de-a lungul anilor în numeroase şi
voluminoase lucrări. În aceast capitol ne propunem să realizăm într-o manieră simplă şi
accesibilă studiul proiectării şi implementării bazelor de date relaţionale (DBR).
Deşi s-au propus numeroase definiţii bazelor de date, s-a ajuns l-a concluzia că fiecare
dintre ele nu identifică în totalitate noţiunea şi de aceea este bine să o acceptăm ca pe o
noţiune primară (precum mulţimea, algoritmul, punctul,dreapta, planul, etc), acceptând în
schimb pentru descrierea BD diferite caracterizări:

• O mulţime structurată de date care modelează un sistem sau un proces din

lumea reală, accesibilă cu ajutorul calculatorului şi care poate satisface în timp minim şi
într-o manieră selectivă mai mulţi utilizatori; această mulţime serveşte ca suport unei
aplicaţii informatice;
• Un ansamblu de date ce poate fi manipulat de mai mulţi utilizatori în viziuni
diferite asupra datelor;
• O colecţie unică, un ansamblu de date unitar, organizat şi structurat la care să
aibă acces diferiţi utilizatori, nu neapărat programatori, pentru operaţii curente de
adăugare de valori, corecţii, extrageri de date, asemenea operaţiilor dintr-o bancă obişnuită;

În general, BD îşi propune un ansamblu de obiective fundamentale. Dintre acestea

enumerăm:
• Centralizarea datelor, adică eliminarea redundanţelor, asigurarea unicităţii înregistrării
şi controlul centralizat asupra datelor. Astfel, majoritatea BD bine proiectate impun condiţii ca
într-un tabel cel puţin un câmp să conţină valori unice (distincte) pentru fiecare înregistrare;
Program de formare continuă Phare 2006 Coeziune Economică şi Socială
„Formare şi dezvoltare profesională în mediul defavorizat” - C.C.D. BACĂU
acest câmp oferă cheia cu care un program de BD validează datele şi menţine ceea ce se
numeşte integritatea datelor.
• Independenţa dintre date şi prelucrări: BD, ca imagine a unei anumite realităţi, trebuie
actualizată permanent, lucru care nu trebuie să afecteze programele de prelucrare. Pentru
aceasta, trebuie ca fiecare program să aibă o viziune proprie asupra BD.
• Realizarea de legături între entităţile de date care sunt necesare pentru exploatarea
eficientă a SI. Exemplu: legătura dinte tabela FURNIZORI şi tabela care conţine lista de
produse pe care le vinde.
• Integritatea datelor asigură fiabilitatea şi coerenţă BD. Pentru aceasta trebuie definite
restricţii de integritate:
- apartenenţa la o listă de valori sau interval;
- apartenenţa la un anumit format;
- reguli de coerenţă cu alte date;
• Securitatea datelor: BD trebuie să fie protejată împotriva unei distrugeri logice
(anomalii de actualizare) şi fizice. Pentru aceasta se crează ceea ce se numesc puncte de
repriză şi jurnale de tranzacţii.
• Confidenţialitatea datelor:
- identificarea utilizatorilor prin nume sau cod;
- autentificarea prin parole;
- autorizarea accesului diferenţiat prin drepturi la cerere, consultare, modificare,
ştergere pentru anumite segmente de date;
• Partajarea datelor: înlănţuirea tranzacţiilor solicitate simultan pe acceaşi înregistrare
din BD, prin blocarea cererilor în aşteptare şi deservirea ulterioară a acestora.

Baze de date relaţionale

Se cunoaşte istoria şi evoluţia organizării datelor de la tablouri, liste, fişiere, la baze şi
bănci de date. O adevărată revoluţie în gestionarea BD a provocat-o modelarea sub forma
tabelelor (numite şi relaţii) a structurii conceptuale a datelor, la sfârşitul anilor ’70 de către
matematicianul Codd de la Centrul de cercetări San Jose (California) al firmei IBM. Structura
propusă se bazează pe algebra relaţională, în care se lucrează cu noţiuni matemetice
specifice: relaţie, operatori relaţionali (reuniune, intersecţie, produs cartezian, diferenţă,
selecţie, proiecţie, comprimare etc.), cheie primară, cheie străină, tuplu etc. Modelul
relaţional (MR) marchează începutul unei noi generaţii de sisteme de gestiune a bazelor de
date (SGBD) la care utilizatorul nu mai este interesat de descrierea căilor de acces la date ci
doar de extragerea şi prelucrarea datelor.
Odată cu apariţia reţelelor de calculatoare, a apărut organizarea BD sub forma de
baze de date distribuite (BDD). Tehnologiile multimedia au dus la dezvoltarea capacităţii
noilor suporturi de a stoca informaţii de natură diversă: sunet, imagine, text, animaţie.
La sfârşitul anilor ’80 au apărut BD orientate obiect (BDOB) prin convergenţa a două
tehnologii: tehnologia BDR şi tehnologia limbajelor de programare orientate obiect.
Bazele de date inteligente reprezintă o nouă tehnologie pentru managementul
informaţiei, rezultată din integrarea tehnologiilor convenţionale pentru BD cu cele mai
recente tehnologii referitoare la programarea orientată obiect (OOP), sisteme expert,
hipermedia, cu acces on-line la informaţii.

Niveluri de organizare a BD
Ţinând cont de obiectivele pe care trebuie să la asigure BD, de faptul că în „existenţa
şi evoluţia” unei BD participă mai multe persoane cu drepturi şi activităţi diferenţiate şi bine
determinate; din aceste motive şi nu numai la BD se specifică trei niveluri de organizare:
 Structura virtuală, sau structura globală (externă): se
referă la toate datele necesare tuturor utilizatorilor BD, în condiţii de redundanţă minimă şi
controlată a datelor. Descrierea acestui nivel (ansamblu de date, legături, proprietăţi) se face
într-un limbaj de descriere special al SGBD şi poartă numele de SCHEMA CONCEPTUALA.
Ea este unică, se memorează pe suport fizic şi este apelată la fiecare solicitare a unui
subset de date de către un program aplicaţie. Ea este realizată de administratorul BD.
Program de formare continuă Phare 2006 Coeziune Economică şi Socială
„Formare şi dezvoltare profesională în mediul defavorizat” - C.C.D. BACĂU
 Structura logică (conceptuală) se referă la forma în
care fiecare utilizator vede datele în funcţie de aplicaţia pe care o rezolvă. Descrierea
structurii logice se numeşte SUBSCHEMA şi reprezintă un subset de date necesare unui
program.
 Structura fizică (internă) este nivelul elementar la care
se pot constitui datele; se referă la modul de memorare a datelor pe suportul de stocare.
Intră în atribuţiile inginerului de sistem sau al unui programator la nivel de limbaj de
asamblare. Fişierele de date sunt stocate în memoria externă în diferite structuri interne care
să permită utilizarea eficientă a suportului şi minimizarea timpului de acces. La acest nivel,
structura se numeşte SCHEMA INTERNA.

Terminologie şi concepte specifice BD

Entitate: element fundamental al modelului conceptual, desemnează obiecte

similare ca structură care sunt identificabile, deci se pot deosebi între ele prin trăsături
specifice.
O entitate este formată din mai multe atribute (caracteristici) care pot defini
complet obiectul.
Lista atributelor care pot caracteriza o entitate se numeşte familie de
caracteristici.
Valorile familiei de caracteristici corespunzătoare unui obiect distinct se numesc
realizare de entitate (instanţiere).

Caracteristica asociază câte o valoare dintr-un domeniu fiecărei realizări. Domeniile

pot fi deci numere întregi, şiruri de caractere, etc.

Un atribut sau un set de atribute care identifică în mod unic fiecare realizare a unei
entităţi se numeşte cheie.

Realizările sunt distincte, deci fiecare realizare are cheia sa.

Exemplu:
serie culoare marca pret
automobil 1111 alb Matiz 5000
1234 roz Tico 4000
1999 bleu Cielo 7000
Obs.: S-a definit entitatea automobil folosind familia de caracteristici: serie, culoare,
marca, preţ. O realizare de entitate poate fi considerată oricare linie de valori, de exemplu: 1999,
bleu, Cielo, 7000. Domeniul pentru caracteristica culoare: alb, roz, bleu. Cheia entităţii este
atributul serie.

Relaţiile care se pot stabili între două entităţi ale BD

• Relaţia 1-1 (unu-la-unu). Exemplu: CLASE şi DIRIGINTI; Relaţia se verifică astfel:
unei clase i se numeşte un singur diriginte; un diriginte este numit la o singură clasă.
• Relaţia 1-n (unu-la-mulţi). Exemplu: CLASE şi ELEVI; Relaţia se verifică astfel: într-
o clasă există unul sau mai mulţi elevi; un elev aparţine unei singure clase.
• Relaţia n-n (mulţi-la-mulţi). Exemplu: CLASE şi PROFESORI; Relaţia se verifică
astfel: la o clasă predau unul sau mai mulţi profesori; un profesor predă la una sau mai
multe clase.
Obs.: Ultima relaţie nu este acceptată în BDR; dacă există, atunci ea reprezintă o
problemă de proiectare şi trebuie transformată introducând un tabel intermediar care are
rolul da a „sparge” relaţia mulţi-la-mulţi într-o pereche de relaţii unu-la-mulţi. Exemplu: ELEVI
şi OPTIONALE legate prin relaţia n-n, se introduce un tabel intermediar INSCRIERI, cu
următoarele legături: ELEVI, INSCRIERI cu 1-n, în sensul că un elev poate să completeze
Program de formare continuă Phare 2006 Coeziune Economică şi Socială
„Formare şi dezvoltare profesională în mediul defavorizat” - C.C.D. BACĂU
una sau mai multe cerei de inscriere la opţionale, o cerere fiind întocmită de un singur elev;
şi OPTIONALE, INSCRIERI cu 1-n, adică pentru un opţional pot fi una sau mai multe
înscrieri, o cerere de înscriere fiind întocmită pentru un singur opţional.

V.1.2. Prezentarea aplicaţiei Access

Unul dintre cele mai utilizate sisteme de gestiune a bazelor de date este Microsoft
Access din suita Microsoft Office.

Principalele caracteristici ale acestuia sunt:

• sistem de gestiune a bazelor de date relaţional şi lucrează sub Windows;
• este deschis comunicării cu alte sisteme de gestiune a bazelor de date:
FoxPro, Paradox;
• este compatibil cu tehnologia ActiveX care permite realizarea aplicaţiilor
client/server;
• permite realizarea unor aplicaţii complexe prin utilizarea limbajului Visual Basic;
• permite comunicarea cu SQL Server, un alt produs Microsoft care gestionează
baze de date;
• permite accesul la baze de date din reţeaua Internet, fiind un instrument util
pentru publicarea informaţiilor în paginile Web;
• cerinţe hard pentru instalare: calculator Pentium cu 32 MB RAM, 200 MB spaţiu
HD, CD-ROM, SVGA;
• este autodocumentat prin HELP;
• conţine instrumente wizard care permit utilizatorului crearea facilă a unor obiecte;
• acceptă nume lungi în definirea fişierelor;
• permite crearea de comenzi rapide (shortcuts) în vederea accesării obiectelor
ACCESS;
• permite setarea proprietăţilor iniţiale ale BD cum ar fi: titlul aplicaţiei, ataşarea de
pictograme (icons), precum şi forma de afişare iniţială;
• oferă posibilitatea creării unei copii a BD, precum şi sincronizarea diferitelor copii
al BD;
• permite utilizarea de adrese şi legături Internet;

O bază de date ACCESS poate fi definită ca o colecţie de obiecte: tabele (tables),

cereri de interogare (querys), formulare (forms), rapoarte (reports), pagini Web (pages),
comenzi macro (macros), module (modules).

Tabela (table) este un obiect definit de utilizator în care sunt stocate datele primare ;
Formularul (form) este un obiect care permite introducerea datelor, afişarea acestora
sau controlul întregii aplicaţii;
Interogarea (query) este un obiect care permite vizualizarea informaţiilor obţinute prin
prelucrarea datelor din una sau mai multe tabele şi/sau alte cereri de interogare.
Raportul (report) este un obiect care permite formatarea şi tipărirea informaţiilor
obţinute în urma consultării bazei de date sub formă de documente;
Pagina Web (pages) reprezintă un obiect care include un fişier HTML şi alte fişiere
suport în vederea furnizării accesului la date prin intermediul browser-elor Internet.
Macro (macro) reprezintă un obiect care conţine o definiţie structurată a uneia sau mai
multor acţiuni pe care Microsoft Access le realizează ca răspuns la un anumit
eveniment.
Modulul (module) reprezintă un obiect care conţine proceduri definite de utilizator şi
scrise în limbajul de programare Visual Basic (VBA).

Lansarea în execuţie a aplicaţiei se poate realiza în următoarele

moduri:
Program de formare continuă Phare 2006 Coeziune Economică şi Socială
„Formare şi dezvoltare profesională în mediul defavorizat” - C.C.D. BACĂU
- Metoda 1: dublu clic pe pictograma corespunzătoare aflată pe desktop.
- Metoda 2: clic pe Start - All Programs - Microsoft Office - Microsoft
Access 2003.
Program de formare continuă Phare 2006 Coeziune Economică şi Socială
„Formare şi dezvoltare profesională în mediul defavorizat” - C.C.D. BACĂU
La pornire, SGBD ACCESS afişează ecranul de mai jos, în care se crează o bază
nouă sau se deschide una existentă după tipicul Windows.

TaskPane cu
opţiuni de
deschidere

Operaţiile cu documente: deschiderea unei baze existente, deschiderea unei baze

de date noi, salvarea, utilizarea funcţiei HELP, închiderea, precum şi lucrul cu fereastra
aplicaţiei: utilizarea elementelor, accesarea meniurilor, adăugarea / eliminarea barelor
de butoane, sunt cele specifice Windows şi Microsoft Office.

V.2. Crearea unei baze de date

Obiective:
- Proiectarea unei baze de date;
- Crearea unui tabel cu câmpuri şi atribute;
- Navigarea în cadrul unui tabel;
- Definirea unei chei primare;
- Modificarea caracteristicilor unui tabel;
- Modificarea atributelor unui camp;
- Modificarea datelor într-un tabel;
- Ştergerea datelor dintr-un tabel;
- Adăugarea unei înregistrări la baza de date;
- Ştergerea de înregistrări ale bazei de date;
Program de formare continuă Phare 2006 Coeziune Economică şi Socială
„Formare şi dezvoltare profesională în mediul defavorizat” - C.C.D. BACĂU
V.2.1. Proiectarea bazei de date

Despre proiectarea BD s-au scris foarte multe volume relevante, pe măsură ce

procesul de proiectare a BD a fost definit, revizuit şi rafinat.

Proiectarea reprezintă procesul de transformare a cerinţelor de date din lumea reală

într-o structură de baze de date care constă în relaţiile dintre tabele şi câmpuri

Este activitatea cea mai grea, deoarece presupune multă experinţă, inventivitate,
capacitate de analiză şi decizie; de modul cum s-a realizat proiectarea BD depinde succesul
şi eficienţa bazei de date. Analişti celebri au scris cărţi pline de sfaturi pentru începători,
foarte valoroase, deoarece experienţa se dobândeşte foarte greu şi nu este indicat ca
fiecare viitor analist să parcurgă aceleaşi etape dificile de acumulări. Îmi permit să vă citez
câteva [5]:
- nu încercaţi să săriţi peste faza de proiectare, deoarece nereuşita proiectării este
echivalentă cu proiectarea nereuşitei; este preferabil să construiţi o fundaţie bună decât să
proptiţi o structură proastă; dacă vă zgârciţi la faza de proiectare, vă puteţi aştepta să vă
confruntaţi măcar cu o parte din următoarele probleme:
- dacă schimbaţi numele unui câmp, va trebui să modificaţi, de asemenea, toate
interogărilor, formularele, rapoartele, comenzile macro şi modulele care folosesc numele
câmpului respectiv;
- dacă schimbaţi tipul unui câmp, va fi nevoie să modificaţi formatul de reprezentare a
datelor în interogări, formulare şi rapoarte, precum şi declaraţiile de variabile din cadrul
modulelor;
- modificarea dimensiunii unui câmp poate duce la invalidarea relaţiilor cu tabelele
asociate, sau la situaţia în care spaţiul de ecran alocat în formulare şi rapoarte să devină
necorespunzător;
- modificarea relaţiilor dintre tabele poate determina efecte neaşteptate asupra
interogărilor; efecte care se vor manifesta în formularele sau rapoartele bazate pe aceste
interogări;
- nepotrivirile dintre datele stocate în părţi diferite ale bazei dvs. pot crea incertitudini în
ceea ce priveşte varianta corectă;
- s-ar putea ca problemele mai subtile să rămână neobservate luni de zile, până în
momentul în care nişte modificări efectuate într-o anumită parte a BD determină apariţia
unor efecte colaterale nedorite în celelalte părţi.

Înainte de toate, este bine să vă notaţi răspunsurile la următoarele întrebări:

- pe scurt, care este scopul acestei BD?
- ce categorii de date trebuie stocate? Inspiraţi-vă din diferite formulare, carnete,
rapoarte, liste, situaţii,etc. Creaţi şi o listă cu datele care nu vor fi incluse;
- cât de mari sunt tipurile de date şi ce dimensiuni pot avea elementele componente?
- care sunt elementele care vor fi înregistrate pe o perioadă mai lungă?
- ce fel de rapoarte sunt necesare? (creaţi o listă a lor cu caracteristicile mai importante);
- care este mediul de calcul în care este utilizată BD? (precizaţi nevoile de import/export de
date);
- câţi utilizatori şi câte amplasamente de reţea (unul sau mai multe calculatoare) vor folosi
BD?;
- sunt necesare niveluri de securitate diferite pentru diversele categorii de utilizatori?

Proiectarea unei BDR începe prin definirea entităţilor şi a relaţiilor între ele. Se definesc
apoi tabelele care vor memora atât datele din entităţi cât şi relaţiile dintre acestea
Program de formare continuă Phare 2006 Coeziune Economică şi Socială
„Formare şi dezvoltare profesională în mediul defavorizat” - C.C.D. BACĂU
Trebuie să construim tabele care să evite anomaliile de actualizare şi dificultăţile de
prelucrare. O tabelă este corect formulată (este o relaţie) dacă îndeplineşte următoarele
condiţii (Codd):
- în cadrul BD tabela are un nume distinct;
- fiecare celulă a relaţiei conţine o singură valoare;
- fiecare atribut are un nume distinct;
- orice valoare a unui atribut face parte din domeniul pe care a fost definit acesta;
- ordinea dispunerii atributelor în relaţie nu are importanţă;
- orice linie este distinctă de celelalte;
- ordinea liniilor nu influenţează conţinutul informaţional al relaţiei.

Exemplu: Presupunem că tabelul următor reţine codurile produselor solicitate pe o comandă

precum şi numărul, data şi valoarea comenzii:

COM DATA FURN ADR COD1 COD2 COD3 COD4 CANT VAL
006 01.03.98 F1 Bc A23 B66 C33 10 12980
007 01.09.98 F2 Gl C33 12 12000

Verificăm să fie o relaţie conform definiţiei date mai sus: nu sunt linii identice, nu
sunt valori de tipuri diferite în coloane, cheia este atributul Com. Dar:
a) cine ne garantează că nu pot fi comenzi cu mai mult de 4 produse?
b) cine ne garantează că toate produsele, chiar dacă sunt cel mult 4, au aceeaşi
cantitate?
c) unde punem preţul fiecărui produs?
d) prelucrări de tipul „valoare totală a comenzilor pentru produsul B66” necesită
verificarea tuturor coloanelor şi însumarea rezultatelor pentru întreaga bază de date, lucru
care conduce la un timp mare de răspuns.

Deci se impune eliminarea câmpurilor care se repetă şi astfel se ajunge la prima

formă normală:

Com Data Furn Adr Codprod Cant Preţ Valoare

006 01.03.98 F1 Bc A23 10 1000 12980
006 01.03.98 F1 Bc B66 10 1700 12980
006 01.03.98 F1 Bc C33 10 1180 12980
007 01.09.98 F2 Gl C33 12 1000 12000

În această tabelă cheia este compusă din atributele Com şi Codprod..

Prima formă normală se identifică cu noţiunea de relaţie. Dar nu toate formele

normale sunt perfect acceptabile, deoarece anumite relaţii pot conduce la dificultăţi de
actualizare sau manevrare.

Operaţia de „spargere” a relaţiei care manifestă anomalii în alte relaţii poartă numele
de normalizare.

Procesul de normalizare are la bază noţiunea de dependenţă funcţională dintre două

atribute, în sensul că al doilea atribut poate fi determinat dacă se cunoaşte primul.

Exemplu: dacă se cunoaşte codul unui furnizor putem să-i aflăm adresa. Spunem că
atributul Adr este dependent funcţional de atributul Furn şi vom nota (furn)>>>(adr).

Spunem că o relaţie se află în a doua formă normală dacă toate atributele non-cheie
sunt dependente de întreaga cheie.
 Program de formare continuă Phare 2006 Coeziune Economică şi Socială
„Formare şi dezvoltare profesională în mediul defavorizat” - C.C.D. BACĂU

Deci, problema apare când cheia este compusă din mai multe atribute (în cazul nostru
com + codprod).
O relaţie care are chei simple este în a doua formă normală. În cazul nostru, observăm
că atributele non-cheie nu sunt dependente de întraga cheie (atributul valoare care
reprezintă valoarea totală a facturii depinde doar de atributul comandă).

Normalizăm şi împărţim tabela în două alte tabele.

COMENZI PRODUSE
Com Data Furn Adr Valoare Com Codprod Cant Pret
006 01.03.98 F1 Bc 12980 006 A23 10 1000
007 01.09.98 F2 Gl 12000 006 B66 10 1700
006 C33 10 1180
007 C33 12 1000

Observăm că în acest exemplu avem următoarele dependenţe funcţionale:

(Com)>>>(Furn); (Furn)>>>(Adr).

Din aceste relaţii se poate trage concluzia (falsă) că adresa depinde funcţional prin
tranzitivitate de comandă, deci incorect.

Spunem că o relaţie se află în a treia formă normală dacă se află în forma a doua şi
nu prezintă dependenţe tranzitive.

Vom normaliza în continuare şi obţinem alte două tabele:

FURNIZORI COMENZI
Codfurn Adr Comanda Data Codfur Val
F1 bc 006 01.03.98 F1 12980
F2 Gl 007 01.09.98 F2 12000

Deci:
- prima formă normală se identifică cu definiţia unei relaţii.
- a doua formă normală impune ca toate atributele non-cheie să fie dependente de întraga
cheie.
- a treia formă normală presupune inexistenţa dependenţelor tranzitive.

În concluzie, prin normalizare spectrul anomaliilor de care suferă o relaţie se

restrânge foarte mult. Toate aceste forme normale sunt folositoare, dar nici una nu garantează
că au fost eliminate toate anomaliile. De fapt, mai toţi analiştii recunosc faptul că ori de căte ori li
s-ar cere să reproiecteze o BD, rezultatul ar fi cu totul schimbat din punct de vedere al concepţiei
şi al performanţelor. Dar, practica demonstrează că o bază de date odată finalizată prezintă deja
numeroase semne de „îmbătrânire”.

Studiul de caz
Conducerea şcolii „XXX” comandă realizarea unei BD pentru informatizarea activităţii
bibliotecii şcolii. Se doreşte:
- cunoaşterea permanentă a fondului de carte pe autori, titluri, edituri, genuri etc.;
- cunoaşterea exemplarelor disponibile pentru fiecare titlu (cotă) solicitat de un abonat;
- cunoaşterea cititorilor abonaţi pe vârste, profesii, clase;
- cunoaşterea fondului de carte împrumutat;
- cunoaşterea abonaţilor care nu au restituit cărţile la timp şi redactarea automată a
scrisorilor de somaţie;
Echipa de analiză a preluat problema şi după o minuţioasă documentare la biblioteca
şcolii, după disciţii purtate cu bibliotecarul, cu elevii, profesorii, în urma verificării modului de
Program de formare continuă Phare 2006 Coeziune Economică şi Socială
„Formare şi dezvoltare profesională în mediul defavorizat” - C.C.D. BACĂU
completare a documentelor din bibliotecă şi chiar a completării efective de către membri
echipei, s-a stabilit următorul flux informaţional:
Abonaţilor bibliotecii li se întocmesc fişe ce conţin: un număr al fişei, data întocmirii,
seria, numărul şi data eliberării B.I., numele, prenumele, profesia, clasa, adresa, telefon, vârsta.
Aceştia pot să împrumute maxim 3 cărţi. Pentru fiecare carte se cunoaşte cota, titlul, numărul
total de exemplare, numărul de exemplare disponibil, anul editării, autorii. Autorii sunt
caracterizaţi prin: cod, nume, prenume, text. Fiecare carte aparţine unui anumit gen şi este
editată de o numită editură. Un titlu de carte nu poate fi editat decât de o singură editură.
Editurile sunt caracterizate prin: număr, denumire, adresă, telefon. Pentru fiecare împrumut
clientul trebuie să completeze câte o cerere de împrumut care este caracterizată printr-un
număr, dată şi cărţile ce se doresc a fi împrumutate. Toate împrumuturile sunt acordate pe o
perioadă de cel mult 21 zile. Cererea de împrumut se poate aproba diferenţiat în funcţie de
titlurile disponibile în momentul întocmirii cererii. Anularea cererii de împrumut se realizează în
momentul în care au fost restituite toate cărţile trecute pe cerere, menţionându-se data restituirii.
Echipa de analiză prezintă acest flux conducerii şcolii şi bibliotecarului şi deoarece nu sunt
sugestii şi recomandări, de comun acord se stabileşte trecerea la elaborarea modelului
conceptual al datelor, al modelului relaţional şi apoi al modelului fizic.

Modelul conceptual al BD trebuie să facă faţă listei de cerere solicitate de conducere şi

nu numai.
De exemplu, dacă se doreşte rezolvarea problemei: „Ce cărţi a împrumutat abonatul
Ionescu Ion?”, atunci se impune generarea entităţilor ABONATI şi IMPRUMUTURI; apoi fixăm
relaţia ABONATI -> 1,n -> IMPRUMUTURI (în sensul că un abonat poate efectua unul sau mai
multe împrumuturi, dar un împrumut de carte nu poate fi facut decât de un singur abonat). În acest
sens se definesc toate entităţile şi legăturile, obţinându-se următorul model conceptual al
datelor:

INTOCMESC / ANULEAZA

ABONATI
NrAbonat IMPRUMUTURI
AUTORI
DataInsc NrCerere
CodAutor
SeriaBI DataCerere
NumeAutor
NrBI Anulat
PrenAutor
DataElib NrAbonat
NumeAb
PrenumAb
AdresaAb SCRIU
TelAb RESTITUIE
FormAdr
CARTI
Cota
TitluCarte
EDITURI AnEdit
NrEditura Gen
DenEd Exempl
AdresaEd ExemplDisp SOLICITA
TelEd Nr.Editura

EDITEAZA
Program de formare continuă Phare 2006 Coeziune Economică şi Socială
„Formare şi dezvoltare profesională în mediul defavorizat” - C.C.D. BACĂU

Modelul relaţional al datelor (tabele ce întră în componenţa bazei de date)

• ABONATI (NrAbonat, DataInsc, SeriaBI, NrBi, DataElib, NumeAb, PrenumAb,
AdresaAb, TelAb, FormAdr)
• IMPRUMUTURI (NrCerere, DataCerere, Anulat, NrAbonat)
• DETALIIIMPRUMUT (IdDetI, NrCere, Cota)
• DETALIIRESTIT (IdDetR, NrCere, Cota, DataRest)
• CARTI (Cota, TitluCarte, AnEdit, Gen, Exempl, ExemplDisp, NrEdit)
• EDITURI (NrEditura, NumeEdit, AdresaEd, TelEd)
• AUTORI (CodAut, NumeAut, PrenAutor)
• AUTORICARTE (CodAutor, Cota)

Modelul fizic al datelor va fi implementat în Microsoft Access în cele ce urmează şi va

avea forma:

V.2.2. Crearea tabelelor

Se selectează butonul Tables după care se poate alege una din cele trei variante:
• Create table in desigh view – utilzatorul are deplin control asupra stabilirii
atributelor câmpurilor;
• Create table by using wizard – se deschide “expertul” care va conduce
utilizatorul printr-o serie de etape prestabilite prin care îşi setează atributele câmpurilor
utilizând exemple;
• Create table by entering data – utilizatorul introduce direct datele într-un
table, iar sistemul va formata atributele în funcţie de informaţiile introduce.
Program de formare continuă Phare 2006 Coeziune Economică şi Socială
„Formare şi dezvoltare profesională în mediul defavorizat” - C.C.D. BACĂU

Selectând prima opţiune se obţine fereastra următoare în care va trebui să se

completeze cele trei coloane pentru fiecare câmp.

DataType (Tip de date) conţine o listă ascunsă prin care se stabileşte tipul fiecărei
caracteristici; de asemenea, în fereastra Field Properties (Proprietăţile câmpurilor) se
introduc informaţii suplimentare, ca de exemplu: Dimensiunea, Formatul, numărul de
zecimale...
La salvare, aplicaţia cere definirea unei chei primare.
Program de formare continuă Phare 2006 Coeziune Economică şi Socială
„Formare şi dezvoltare profesională în mediul defavorizat” - C.C.D. BACĂU
Cum numărul abonatului trebuie să fie unic, acest câmp va deveni cheia primară.
Stabilirea câmpului cheie primară se face dând clic dreapta pe caseta din stânga numelui
câmpului şi selectând opţiunea din lista apărută.

Tabela nou creată va apare în lista secţiunii Tables (Tabele).

V.2.3. Relaţii între tabele

Din punct de vedere al momentului creării acestora, există două tipuri de relaţii între
tabelele unei BD:
- relaţii permanente care se stabilesc după definirea tabelelor şi sunt cerute de modelul
relaţional făcând parte din structura BD. Aceastea se realizează prin corespondenţa cheie
primară-cheie externă şi sunt memorate în baza de date (fereastra Relationships).
- relaţii temporare care se stabilesc între tabele cu ocazia definirii unor cereri de
interogare, nefiind înregistrate în structura BD.

În fereastra Relationships se adaugă toate tabelele din BD, se închide lista cu tabele
(Close), dupa care se realizează relaţiile între tabele prin operaţia drug and drop de la
cheia primară a tabelei principale la cheia externă a tabelei secundare.

ACCESS va deschide fereastra de dialog Edit Relationships aşa cum este prezentată
în imagine pentru tabelele ABONATI respectiv IMPRUMUTURI.
Dacă se selectează Enforce Referential Integrity atunci ordinea introducerii datelor în
tabele va fi impusă. De asemenea următoarele două opţiuni se referă la actualizarea, respectiv
stergerea în cascadă. Tipul de asociere a realizărilor din cele două tabele se stabileşte
selectând unul din cele 3 butoane ale opţiunii Join Type (inner join, left-outer join, right-outer
join).
Program de formare continuă Phare 2006 Coeziune Economică şi Socială
„Formare şi dezvoltare profesională în mediul defavorizat” - C.C.D. BACĂU

V.2.4. Introducerea datelor

Prin dublu clic pe numele tabelei se deschide o ferestră în care putem introduce
datele:

Dacă datele nu respectă formatul specificat (tip, dimensiune, regula de validare) pe

ecran va apărea un mesaj de atenţionare. Dacă aplicaţia poate face corecţia (data
calendaristică este corectă, dar nu în formatul implicit) corectarea se face automat, fărăr
apariţia unui mesaj de atenţionare.

Cu un tabel în Access se lucrează în acelaşi mod ca şi cu un tabel în Excel. Astfel,

asupra informaţiilor pot fi realizate următoarele operaţii:
- ştergerea conţinutului – clic în celulă şi ştergem textul;
- selectarea unei linii – clic pe secţiunea stângă;

- odată linia selectată, prin clic dreapta, din meniul contextual se

pot alege operaţiile pe care doresc să le efectuez:

La închiderea ferstrei, salvarea datelor introduse se face

automat.

Formatări suplimentare asupra afişării datelor în tabel pot fi

operate activând opţiunile din meniul Format. Modul lor de lucru
este acelaşi ca în Excel sau Word.
 Program de formare continuă Phare 2006 Coeziune Economică şi Socială
„Formare şi dezvoltare profesională în mediul defavorizat” - C.C.D. BACĂU
V.3. Utilizarea formularelor (Forms)

Obiective:
- Crearea unui formular simplu;
- Introducerea datelor în baza de date folosind formulare simple;
- Formatarea textului;
- Schimbarea culorii fondului într-un formular;

Formularele (Forms) reprezintă interfaţa principală între utilizator şi o aplicaţie

ACCESS care permite introducerea şi afişarea datelor într-o manieră cât mai atractivă.

Formularele se pot crea în mai multe moduri (conform ferestrei alăturate) dintre toate
primele două fiind cele mai uzitate: automat, folosind instrumentul wizard, sau manual în
fereastra de proiectare.

Alegând Wizard-ul, aplicaţia ne pune la dispoziţie o serie de ecrane care ne ajută să

stabilim de la în ce câmpuri se vor introduce date (imaginea de mai jos), până la aspectul
formularului
Program de formare continuă Phare 2006 Coeziune Economică şi Socială
„Formare şi dezvoltare profesională în mediul defavorizat” - C.C.D. BACĂU

În final, un formular poate arăta ca mai jos:

V.4. Extragerea de informaţii

Obiective:
− Încărcarea sau conectarea la o bază de date existentă;
− Găsirea unei înregistrări pe baza unui criteriu dat;
− Crearea unei interogări simple;
− Crearea unei interogări cu criterii multiple;
− Salvarea unei interogări;
− Adăugarea / scoaterea filtrelor;
− Selecţia şi sortarea datelor după criterii date.

Interogarea bazei de date: se poate face în mai multe moduri:

- prin vizualizarea în totalitate a conţinutului tabelelor – dublu clic pe numele
tabelului
- prin vizualizarea parţială sau totală a conţinutului tabelelor cu ajutorul unor
formulare sau situaţii finale – realizarea unor rapoarte;
- prin cereri explicite - realizând un querry.

Primele două moduri pot fi catalogate ca cereri simple, fără restricţii şi pot fi formulate
pentru o singură tabelă.

Interogarea prin cereri explicite este complexă, comportând în general mai multe
tabele, ale căror date sunt filtrate prin intermediul unor criterii. Poate fi de 4 tipuri: selecţie
(select), analiză încrucişată (crosstab), acţiune (action) şi cu parametrii (parameter).
Rezultatul execuţiei unei asemenea cereri este plasat într-o foaie de răspuns, asemănătoare
foii de date asociate unei tabele.
În imaginea de mai jos am prezentat interogarea pentru obţinerea listei cu cititorii
somati pentru întârzierea restituirii cărţilor.
Program de formare continuă Phare 2006 Coeziune Economică şi Socială
„Formare şi dezvoltare profesională în mediul defavorizat” - C.C.D. BACĂU

Obţinerea unei astfel de foi de răspuns se realizează activând semnul din bara
de meniu ataşată, sau dând clic pe numele interogării.

V.5. Raportarea

Obiective:
− Prezentarea datelor selectate într-o secvenţă specifică şi în rapoarte;
− Modificarea unui raport;
− Operaţii într-un raport – gruparea datelor total, sub – total, etc.

Situaţiile finale se pot obţine pe ecran sau pe hârtie prin intermediul foilor de date,
formularelor şi a rapoartelor. Ultima variantă constituie cea mai bună modalitate de
prezentare a datelor pe hârtie (imprimantă).

Un raport este o grupare de date prezentate într-un anumit format şi o structură de

pagină în funcţie de necesităţile utilizatorilor şi care servesc diferitelor scopuri de
informare sau de fundamentare a deciziilor. Ele pot include totaluri, subtotaluri,
subformulare grafice şi obiecte de tip OLE.
Program de formare continuă Phare 2006 Coeziune Economică şi Socială
„Formare şi dezvoltare profesională în mediul defavorizat” - C.C.D. BACĂU

Cea mai simplă metodă de realizare a unui raport este folosind “wizard-ul”. Aplicaţia
pune la dispoziţie o serie de ecrane ce ne permit să stabilim conţinutul şi modul de
formatare:

- ce tabele şi ce câmpuri din ele vor fi incluse:

- se stabileste câmpul de grupare, în cazul nostru sunt mai mulţi înscrişi în aceeaşi zi / lună
Program de formare continuă Phare 2006 Coeziune Economică şi Socială
„Formare şi dezvoltare profesională în mediul defavorizat” - C.C.D. BACĂU

- se stabileşte criteriul de ordonare a informaţiilor ce se includ în raport (nu se ordonează

efectiv informaţiile în tabel)

- se stabileşte formatul raportului şi orientarea în pagină:

Program de formare continuă Phare 2006 Coeziune Economică şi Socială
„Formare şi dezvoltare profesională în mediul defavorizat” - C.C.D. BACĂU
- se stabilesc atributele font-urilor

- se stabileşte numele sub care se salvează

Program de formare continuă Phare 2006 Coeziune Economică şi Socială
„Formare şi dezvoltare profesională în mediul defavorizat” - C.C.D. BACĂU
După salvare, datele pot fi afişate pe ecran sau tipărite, pot fi exportate în alte
aplicaţii. Operaţiile pot fi accesate prin clic dreapta pe numele raportului.

Modificarea caracteristicilor elementelor raportului se poate face alegând opţiunea

Design View (Vizualizare în mod proiectare)

Fiecare element poate fi accesat prin clic şi acţionat asupra lui.

Program de formare continuă Phare 2006 Coeziune Economică şi Socială
„Formare şi dezvoltare profesională în mediul defavorizat” - C.C.D. BACĂU

 Aplicaţie: Modelul conceptual

O agentie de asigurari simplă are câteva reguli canonice legate de entităţi obligatorii
(agent de asigurări, client asigurat, contract) dar şi legate de situaţii probabile, dar nu
obligatorii (plata de rate de asigurare de la client la agenţie, plata asigurării de la agenţie la
client).
Modelul conceptual este legat de câţiva paşi temporali:
1. existenţa a cel puţin unui agent de asigurări;
2. existenţa a cel puţin unui client ce se asigură;
3. urmare a acţiunii de asigurare rezultă contractul de asigurare;
4. în baza contractului de asigurare pot decurge un număr de plăţi a unor rate de
asigurare de client către agenţie;
5. în baza contractului de asigurare şi dacă este cazul, clientul poate fi despăgubit de
agenţie cu suma asigurată;
6. plata ratelor de asigurare se poate face în numerar (clientul primeste chitanţa) sau
bancar, prin ordin de plată.
Modelul conceptual delimitează entităţile (agent, client, contracte, chitanţe, ordine de plată,
procese-verbale de despăgubire) cărora se atribuie relaţiile conform scenariului general descris
mai sus.
Punctul de vedere al aplicaţiei şi modelului este acela al managerului agenţiei, care trebuie
să ştie:
1. dacă are clienţi asiguraţi;
2. care sunt sumele asigurate;
3. care este rulajul plăţilor ratelor (chitanţe, ordine de plată);
4. care sunt clienţii despăgubiţi;
5. care este volumul asigurat de fiecare agent de asigurare;
6. care este eficienţa (volumul asigurat-volumul despăgubirilor) pe fiecare agent de
asigurări,
Modelul conceptual de aici este suprapus pe un model entitate-relaţie, bazat pe paşi
temporali obligatorii (apariţia agenţiei, apariţia agenţilor de asigurări, apariţia clienţilor) dar şi
ne-obligatorii (contracte, plăţi de rate, plăţi de despăgubiri).
Modelul relaţional
CLIENTI (NrClient, Tip,Nume,Prenume,Denumire,Adresa,Tel,Cont,Notes);
CONTRACTE (NrContr,NrClient,TipAsig,DataContr,Perioadas,Obiect,Val,Rata,CodAgent);
AGENTI (CodAgent,Nume,Prenume,Tel,Salariu,Notes);
PROCESE_VERBALE (NrPV,NrContr,Data,Cauza,ProcesDesp);
ORDIN_PLATA (NrOrdin,Data,SumaLei,NrContr);
CHITANTE (NrChit,Data,SumaLei,NrContr);
Program de formare continuă Phare 2006 Coeziune Economică şi Socială
„Formare şi dezvoltare profesională în mediul defavorizat” - C.C.D. BACĂU

Diagrama entitate – relaţie rezultată în Microsoft Access

Program de formare continuă Phare 2006 Coeziune Economică şi Socială
„Formare şi dezvoltare profesională în mediul defavorizat” - C.C.D. BACĂU

Descrierea câmpurilor s-a facut astfel ca în toate tabelele în care există restricţii de
integritate cu cheie străină, dar în acea tabelă în care nu este cheie unică, încărcarea să se
facă cu Lookup pe combobox. Mai există şi o serie de restricţii de integritate tip tabelă
(valorile unor câmpuri satisfac anumite criterii): ”Validation Rule” combinat cu „Validation
Text”.
Baza de date conţine: tabele, forme, queries, rapoarte. Construcţia porneşte de la tabele:
denumirea câmpurilor, proprietăţile, regulile de validare, restricţiile de integritate cu „cheie
straină” (adică o restricţie care punctează pe o altă tabelă, pe un câmp „cheie”). După aceea
se construiesc formele şi celelalte obiecte.

În cele ce urmează se va descrie pas cu pas construcţia tabelelor şi de ce sunt alcatuite

practic în această formă.

Tabelele aplicaţiei
Aici se descriu tabelele în ordinea creării lor.Cu  s-a marcat cheia unică.

AGENTI
Chei Camp Tip Explicatie Regula Validare Mesaj
 CodAgent trebuie să fie
CodAgent Number Cod Agent [codagent]>10
mai mare ca 10
NumeAg Text Nume Agent
PrenAg Text Prenume
Agent
Tel Number Telefon agent
Salariu Number Salariu Agent
Notes Text Note

Tabela AGENTI este similară cu CLIENTI, adică este o tabelă „nomenclator”, care are o
cheie unică, restul fiind un conţinut informativ (de identificare).
Câmpul CodAgent are o regulă de validare, regulă ce conţine o inegalitate. Sintaxa
utilizată pentru această bază de date a unei astfel de reguli conţine:
- câmpuri ale tabelei (numele câmpului între [ ]);
- operatori de comparaţie ( >,<,= ,<=,>=) ;
- constante (numere; exemplu: 10).
În cazul în care „Validation Rule”= false, atunci se blochează trecerea la altă
înregistrare şi afişează „Mesaj”.
Câmpul [AGENTI!CodAgent] (adică CodAgent din tabela AGENTI) este referenţiat drept
„cheie straină” de tabela CONTRACTE.
Ca regulă generală, la introducerea datelor, mai întâi se introduc datele în tabela
„nomenclator”, apoi în cele care le referenţiază (adică aici CONTRACTE), pentru că altfel
restricţia de „cheie straină” ne împiedică să trecem la o nouă înregistrare în tabela cu
restricţie de cheie straină (CONTRACTE). Pentru simplitate şi ca regulă generală am ales ca
în tabelele gen CONTRACTE, pe câmpurile ce referenţiază chei străine (i.e. din alte table)
să folosim lista ascunsă „combo” construită cu „Lookup” pe tabela nomenclator (pentru a
permite selecţia unor chei deja existente în tabela „nomenclator”). Modul de construcţie în
Access al unui astfel de „combo-lookup” va fi descrisă la tabela CONTRACTE.
Tripleta de tabele (CONTRACTE, AGENTI, CLIENTI) formează ceea ce se numeşte
„snowflake”- o tabelă cu valori (CONTRACTE) şi două tabele de „dimensiuni” (AGENTI şi
CONTRACTE).
Celelalte 3 tabele ale aplicaţiei (PROCESEVB, CHITANTE, ORDPLATA) referenţiază
drept „cheie straină” câmpul „NrContract” (din tabela CONTRACTE, unde este „cheie
unică”).
Tripleta de tabele (CONTRACTE, AGENTI, CLIENTI) este utilzată şi la construcţia
formelor, deoarece oferă două perspective:
1. contracte pe client;
2. contracte pe agent de asigurare.
Program de formare continuă Phare 2006 Coeziune Economică şi Socială
„Formare şi dezvoltare profesională în mediul defavorizat” - C.C.D. BACĂU

∞
CONTRACTE
CodAgent
∞ CodClient
AGENTI
CLIENTI
CodAgent
CodClient

”Snowflake”: (CONTRACTE, CLIENTI, AGENTI) cu două ramuri

CLIENTI

Chei Camp Tip Explicatie Regula Validare Mesaj

 NrClient Number Cod unic [Nrclient]>100 Numărul client trebuie
And sa fie in intervalul
[nrclient]<1000 (100,1000)
Tip Number 1=pers.fizica; [tip]=1 Or [tip]=2 Tip trebuie sa fie 1 sau
2=pers. Juridica 2
Nume Text Nume Client
Prenume Text Prenume Client
Denumire Memo Denumire Client
( firma)
Adresa Text Adresa Client
Tel Number Telefon Client [tel]>=0 And Telefon are maxim 6
[tel]<1000000 cifre
Cont Number Cont Client [cont]>100000000 Cont trebuie sa fie mai
mare ca 100000000
Notes Memo

Tabela CLIENTI este oarecum similară cu AGENTI (este o tabelă „nomenclator”, care nu
referenţiază nici o altă tabela, ci este doar referenţiată).
Conţine patru reguli de validare pe campurile NrClient, Tip, Tel si Cont. Este evident că
regula de validare pe Tel (telefon) este prea simplă, deoarece un telefon de tipul +40-234-
514423 nu poate fi introdus aici.

După cum rezultă din diagrama de mai sus: pentru a exista un contract, trebuie să
existe anterior un agent de asigurări şi un client. Dar, nu este obligatoriu să existe
contracte.
Program de formare continuă Phare 2006 Coeziune Economică şi Socială
„Formare şi dezvoltare profesională în mediul defavorizat” - C.C.D. BACĂU

CONTRACTE

Chei Camp Tip Explicatie Regula Validare Mesaj

 NrContract Number Numar [NrContract]>10 Numărul
Contract 00 Contractului
trebui sa fie mai
mare ca 1000
CLIENTI NrClient Number Numar [NrCLient]>100 Număr Client
Client And trebuie să fie
[NrClient]<1000 între (100,1000)
TipAsig Number Tip [Tipasig]>=1 Tipul Asigurării
Asigurare And trebuie să fie
[tipasig]<=10 între [1 şi 10]
DataContra Date/Time cu Data
ct masca: Contractulu
00.00.0000;0; i
_
(Short Date)
Perioada Number Perioada în
Luni
Obiect Text Obiectul
asigurării
ValAsig Number Valoare [ValAsig]>10000 Valoarea
Asigurată 0000 Asigurată
trebuie să fie
mai mare ca
100000000
Rata Number Rata [Rata]>1000000 Rata trebuie să
Asigurării And fie între
[Rata]<1000000 (1000000 şi
00 10000000)
AGENTI CodAgent Number Cod Agent

În coloana „Chei”, pe lângă cheia unică NrContract (ce va fi folosită ca referinţă externă de
tabelele CHITANTE, PROCESEVB şi ORDPLATA) sunt incluse referinţele externe NrClient-
>CLIENT şi CodAgent->AGENTI.
Ca observaţie, regula de validare pe NrClient este redundantă, deoarece regula există în
tabela CLIENTI referenţiată aici.

„Combo-Lookup”
Câmpurile [CONTRACTE!NrClient] şi [CONTRACTE!CodAgent] conţin două astfel de
liste ascunse.

Mod de realizare:
1. se selectează tabela CONTRACTE;
2. se selectează un câmp din cele două ( NrClient sau CodAgent);
3. click pe tab-ul Lookup (după „General”);
4. click pe „Display Control”;
5. selecţie „Combo Box”;
6. Row Source Type=Table/Query
7. Row Source=CLIENTI (pentru NrClient ) sau AGENTI (pentru CodAgent)
8. Bound Column=1 (deoarece codul este în prima coloană)

Existenţa tabelei CONTRACTE este legată de presupunerile (îndreptăţite): un agent de

asigurări poate încheia mai multe contracte de asigurare şi un client poate avea mai multe
contracte de asigurare cu aceeaşi agenţie de asigurări.
Program de formare continuă Phare 2006 Coeziune Economică şi Socială
„Formare şi dezvoltare profesională în mediul defavorizat” - C.C.D. BACĂU

CHITANTE

Chei Camp Tip Explicatie Regula Validare Mesaj

 NrChit Number Numar
Chitanta
Data Date/Time cu Data
masca: Chitantei
00.00.0000;0;
_
(Short Date)
SumaLei Number Suma [sumalei]>= Suma
platită cu 1000000 introdusă
chitanţă And [sumalei]<= trebuie să
(lei) 50000000 fie între
[1000000,
50000000]
CONTRACTE NrContract Nujmber Numar
Contract

Plăţile efectuate de clienţi (dar, numai în cadrul unui contract) sunt marcate aici, dacă
este vorba de numerar pe bază de chitanţe. Există combo-lookup pe NrContract.

Clientul asigurat poate plăti rate de asigurare numai dacă are un contract cu agenţia de
asigurări.

ORDPLATA

Regula
Chei Camp Tip Explicatie Mesaj
Validare
 NrOrdinPl Number Numar
Ordin de
Plata
Data Date/Time cu Data
masca: Ordinului de
00.00.0000;0; Plata
_
(Short Date)
SumaLei Number Rata platită [Sumalei]>= Suma
de client cu 1000000 trebuie să
ordin de And fie între
plată [sumalei]<= [1000000
100000000 şi
10000000
]
CONTRACTE NrContract Number Numar
Contract

Plăţile efectuate de clienti (dar, numai în cadrul unui contract) sunt marcate aici, dacă
este vorba de plăţi prin bancă (tabela similara cu CHITANTE).

Există combo-lookup pe NrContract.

Program de formare continuă Phare 2006 Coeziune Economică şi Socială
„Formare şi dezvoltare profesională în mediul defavorizat” - C.C.D. BACĂU

PROCESEVB

Regula
Chei Camp Tip Explicatie Mesaj
Validare
 NrProcesVerbal Number Număr proces
verbal de
despăgubire
CONTRACTE NrContract Number
Data Date/Time cu Data procesului
masca: verbal de
00.00.0000;0; despăgubire
_(Short Date)
Cauza Text Cauza
despăgubirii
ProcesDespag Number Proces verbal de
despăgubire

Detalii de construcţie a aplicaţie Access

Tabelele aplicaţiei
Program de formare continuă Phare 2006 Coeziune Economică şi Socială
„Formare şi dezvoltare profesională în mediul defavorizat” - C.C.D. BACĂU

Exemplu de „Validation Rule”

Formele aplicaţiei:
Program de formare continuă Phare 2006 Coeziune Economică şi Socială
„Formare şi dezvoltare profesională în mediul defavorizat” - C.C.D. BACĂU

Queries

Raportul
Program de formare continuă Phare 2006 Coeziune Economică şi Socială
„Formare şi dezvoltare profesională în mediul defavorizat” - C.C.D. BACĂU