Introducere

Orice aplicaţie a calculatoarelor în economie are la bază o colecţie de date intercorelate numită,
evident, bază de date.
Un sistem client-server are o parte a softului, necesar pentru lucrul cu baza de date, pe server şi
altă parte pe fiecare client.
Oracle introduce cu APPEX un alt mod de lucru: Avem pe server tot softul necesar şi la orice
client un browser cu care accesăm prin intermediul internetului aplicaţia server. Marele avantaj este că
clientul este orice calculator care nu mai trebuie pregătit dinainte.
Pentru a învăţa să lucrezi cu Application Express (APPEX), Oracle pune la dispoziţie spaţiu de
lucru gratuit pe serverele pentru dezvoltatorul aplicaţiei.
Lucrarea de faţă conţine 5 capitole.
În primul capitol am prezentat câteva concepte importante din teoria bazelor de date relaţionale.
Capitolul al doilea prezintă, pe scurt, sistemul Oracle şi câteva caracteristici ale sistemului APPEX.
Proiectul logic al aplicaţiei pentru activitatea de schimb valutar dintr-o bancă se află în capitolul al treilea.
Conform cu acest proiect logic, capitolul patru prezintă, pas cu pas, modul de realizare a proiectului fizic.
În ultimul capitol, în cadrul manualului de utilizare, este desccris modul în care poate fi folosită această
aplicaţie în practica schimbului valutar dintr-o bancă.
Contribuţia autorului constă din
 selectarea şi organizarea materialului bibliografic,
 analiza activităţii de schimb valutar, cuprinsă în proiectul logic,
 proiectul fizic realizat cu APPEX
 manualul de utilizare
.

I
CUPRINS
Introducere........................................................................................................................................................................................I
Capitolul 1. Baze de date relaţionale...............................................................................................................................................3
1.1. Abstractizarea datelor............................................................................................................................................................3
1.2 Independenţa datelor..............................................................................................................................................................3
1.3. Principalele componente ale unui SGBD..............................................................................................................................4
1.4. Modelul relaţional.................................................................................................................................................................5
1.5.. Definirea sistemelor de gestiune a bazelor de date relaţionale............................................................................................5
1.6. Regulile lui Codd..................................................................................................................................................................6
Capitolul 2. Despre ORACLE şi Oracle Application Express(APPEX).........................................................................................8
2.1. Oracle....................................................................................................................................................................................8
2.2. APPEX..................................................................................................................................................................................8
Capitolul 3. Proiectul logic al aplicaţiei activitatea de schimb valutar într-o bancă......................................................................11
3.l. Descrierea unităţii economice la care se află activitatea de schimb valutar........................................................................11
3.2. Cerinţele utilizatorului........................................................................................................................................................11
3.3 CREAREA MODELULUI CONCEPTUAL LOCAL, PENTRU VEDERILE UTILIZATORILOR.........................................12
3.3.1. Identificarea tipurilor de entităţi..................................................................................................................................12
3.3.2 Identificarea tipurilor de relaţii........................................................................................................................................12
3.3.3 Identificarea şi asocierea atributelor la tipurile de entităţi şi tipurile de relaţii.............................................................12
3.3.4. Determinarea domeniilor de definiţie a atributelor......................................................................................................13
3.3.5. Determinarea atributelor care compun cheile candidate şi primare.............................................................................13
3.3.6. Desenarea diagramei entity-relationship.....................................................................................................................15
3.4. CREAREA ŞI VALIDAREA MODELULUI LOGIC LOCAL..........................................................................................15
3.4.1. Proiectarea modelului conceptual local pe un model logic local.................................................................................15
3.4.2. Crearea relaţiilor pentru modelul logic local................................................................................................................16
3.4.3. Validarea modelului, utilizând normalizarea...............................................................................................................16
3.4.4. Validarea modelului utilizând tranzacţiile...................................................................................................................17
3.4.5. Definirea regulilor de integritate a bazei de date.........................................................................................................18
3.4.6. Verificarea modelului logic local cu ajutorul utilizatorului.........................................................................................19
Capitolul 4. Proiectarea fizică........................................................................................................................................................20
4.1. Cerere de spaţiu de lucru ( Work space).............................................................................................................................20
4.2. Tabele APPEX....................................................................................................................................................................23
4.3. Formulare APPEX..............................................................................................................................................................28
4.4 Liste de valori.......................................................................................................................................................................31
4.5 Formular cu subformular........................................................................................................................................................35
4.5. Rapoarte APPEX.................................................................................................................................................................39
4.5. Crearea unui buton.......................................................................................................................................................51
4.6. Completare pagina de start..................................................................................................................................................55
Capitolul 5. Manual de utilizare.....................................................................................................................................................58
5.1. Intrarea în aplicaţie..............................................................................................................................................................58
5.2. Introducerea clienţilor.........................................................................................................................................................59
5.3. Introducerea cursului valutar...............................................................................................................................................60
5.4. Introducerea cumpărării de valută.......................................................................................................................................61
5.5. Introducerea vânzării de valută...........................................................................................................................................65
5.6 Rapoarte...............................................................................................................................................................................68
5.6.1 Cursul zilnic..................................................................................................................................................................68
5.6.2 Clienţii...........................................................................................................................................................................68
5.6.3 Clienţi cu vânzări..........................................................................................................................................................72
5.6.4 Clienţi cu cumpărări......................................................................................................................................................73
Bibliografie....................................................................................................................................................................................75

II
Capitolul 1. Baze de date relaţionale.

1.1. Abstractizarea datelor

Un scop important al unui sistem de gestiune a bazelor de date este să poată asigura o viziune
abstractă asupra realităţii. Este necesar să se reţină, din mulţimea vastă de informaţii, doar acele informaţii
care sunt necesare unei anumite aplicaţii.
Se poate face referire spre exemplu la încercarea de modelare a unei aplicaţii într-o intreprindere.
Trebuie modelate „obiectele” şi relaţiile dintre ele. Nu realitatea, complexă în totalitatea ei, intră în
discuţie ci doar o mică parte a ei, constituită din anumite „obiecte” şi pentru acele obiecte se iau în
considerare doar o parte din caracteristici (acele caracteristici care sunt importante pentru aplicaţia în
cauză). Astfel în cazul modelarii „obiectului” (sau entităţii) client, trebuie alese doar acele proprietăţi (sau
atribute) care interesează. Acestea ar putea fi, de exemplu: numele, actul de identitate, numărul,. O
mulţime impresionantă de informaţii, care contribuie la descrierea unei persoane anume, nu sunt luate în
seamă deoarece nu prezintă interes pentru intreprindere. De exemplu, nu interesează dacă cliantul are
ochii albaştri, dacă este blond sau brunet, dacă ascultă cu placere muzică sau dacă este o fire sentimentală.
Componentele bazei de date pot fi structurate pe trei nivele, în functie de clasa utilizatorilor
implicati şi de viziunea asupra structurării informaţiei, după cum urmează:
- nivelul logic de vizualizare (view) sau nivelul extern. Este dat de viziunea programatorului de
aplicaţii, care realizează programele de aplicaţii pentru manipularea datelor la nivel de structură logică
(subschema) corespunzatoare descrierii datelor aplicaţiei;
-nivelul conceptual (global). Este dat de viziunea administratorului bazei de date, care realizează
structura conceptuala (schema) corespunzătoare descrierii întregii baze de date şi administrează
componentele bazei de date. Acest nivel descrie ce date sunt memorate în baza de date şi ce relaţii sunt
stabilite între date. Nivelul conceptual reprezintă:
- toate entităţile, atributele lor şi relaţiile dintre ele;
- restricţiile impuse datelor
- informaţiile semantice despre date
- informaţiile privitoare la securitatea şi integritatea datelor.
-nivelul fizic. Este dat de viziunea inginerului de sistem care realizează structura fizică corespunzătoare
descrierii datelor pe suportul fizic (periferic). Acest nivel descrie cum sunt memorate datele în baza de
date. Nivelul intern se ocupă de:
-alocarea spatiului de memorie pentru date şi indecşi;
-descrierea înregistrărilor pentru memorare;
-plasarea înregistrărilor pe suport;
-tehnicile de compresie şi de criptare a datelor.

1.2 Independenţa datelor

Un obiectiv major al arhitecturii pe trei nivele de abstractizare este realizarea 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 asupra aceloraşi date;

3
-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ăi 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 şi care reprezintă o investiţie majoră la care nu trebuie să se renunţe
prea uşor.

Figura 1.1. Arhitectura ANSI-SPARC pe trei nivele

De aceea, se impune ca atunci cand apar noi cerinţe în cadrul sistemului informaţional, sistemele
informatice să poată funcţiona cu programele şi procedurile existente, iar datele existente să poată fi
convertite.
Independenţa datelor trebuie privită din două puncte de vedere: independenţa fizică şi
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.

1.3. Principalele componente ale unui SGBD

Ţinând seama de faptul că există diferite tipuri de sisteme de gestiune, care se diferenţiază:
- prin limbajele utilizate,
- prin anumite componente ce imprimă diferite facilităţi de exploatare a bazei de date,
- şi prin faptul că unele oferă posibilitatea lucrului în regim de teleprelucrare, altele numai în regim
local, iar altele atât în regim local cât şi în regim de teleprelucrare, ajungem la concluzia că nu poate
fi stabilită o arhitectură unică, valabilă pentru toate sistemele, ci apar particularităţi de la un sistem
la altul.

Arhitectura unui SGBD evidentiază componentele acestuia şi urmează standarde internaţionale. O astfel
de arhitectură generală cuprinde următoarele componente:
- baza de date propriu-zisă în care se memorează colecţia de date;

4
 - sistemul de gestiune al bazei de date, care este un ansamblu de programe (soft) care realizează
gestiunea şi prelucrarea complexă a datelor;
- un set de proceduri manuale şi automate, precum şi reglementările administrative, destinate bunei
funcţionari a întregului sistem;
- un dicţionar al bazei de date (metabaza de date), ce conţine informaţii despre date, structura
acestora, elemente de descriere a semanticii, statistici, documentaţie etc.
- mijloacele hard utilizate (comune, specializate etc.);
- personalul implicat: (categorii de utilizatori: finali - (neinformaţicieni); de specialitate
(administrator), analişti - programatori, gestionari, operatori).
Arhitectura bazei de date dă o imagine despre modul general de organizare şi funcţionare a ei.
Limbajele untilizate într-un SGBD sunt de două tipuri: Limbajul de definire a datelor (Data
Definition Language - DDL) şi Limbajul de manipulare a datelor (Data Manipulation Language -
DML). Aceste limbaje mai sunt cunoscute ca sublimbaje de date deoarece ele nu includ construcţii
adecvate oricăror necesităţi de calcul, asemănătoare cu structurile puse la dispoziţie de limbajele de nivel
înalt.
Multe SGBD au facilitatea de a incorpora sublimbajul într-un limbaj de nivel înalt (numit limbaj
gazdă) cum ar fi COBOL, Fortran, Pascal, Ada, C, Jawa, C#. Pentru compilare, comenzile sublimbajului
sunt înlocuite în limbajul gazdă cu apeluri de funcţii. Fişierul preprocesat este compilat, plasat într-un
modul obiect, link-editat cu o bibliotecă în care se află funcţiile înlocuite, furnizate o dată cu SGBD, şi
este executat când este necesar.

1.4. Modelul relaţional

În 1978 E.F.Codd, de la IBM Research Laboratory, a elaborat o lucrare care a avut o influenţă
covârşitoare în dezvoltarea bazelor de date. Lucrarea trata despre modelul de date relaţional.
De aici încolo s-au proiectat multe sisteme dintre care menţionăm System R dezvoltat la IBM's San
Jose Research Laboratory din California, la sfârşitul anilor '70. Acest proiect a dus la:
 dezvoltarea unui limbaj structurat de interogare (numit SQL) care de atunci a devenit un standard
pentru sistemele relaţionale;
 producerea în anii '80 de sisteme comerciale arhicunoscute dintre care menţionăm: DB2, SQL Server,
SQL/DS de la IBM şi ORACLE de la ORACLE Corporation.
Alte exemple de sisteme relaţionale: INGRES de la Relaţional Technology Inc., Informix de la
Informix Sofware Inc., Sybase de la Sybase Inc.. Dintre sitemele relaţionale pentru microcalculatoare
enumerăm aici: Paradox şi dBase IV de la Borland, Access de la Microsoft, FoxPro şi R:base de la
Microrim. Toate acestea constituie generatia a doua de SGBD.

1.5.. Definirea sistemelor de gestiune a bazelor de date relaţionale

Într-o primă încercare de definire, se poate considera un sistem de gestiune a bazelor de date
relaţionale (SGBDR) ca reprezentând un SGBD care utilizează drept concepţie de organizare a datelor
modelul relaţional. Astfel spus, un SGDBR reprezintă un sistem care suportă modelul relaţional.
Definiţia de mai sus este prea generală pentru a putea fi operaţională, deoareca modul de implemantare a
modelului relaţional diferă, de regulă atât între diferitele SGBDR, cât şi în raport cu modelul “teoretic”,
cel definit în cadrul teoriei relaţionale, datorită eforturilor producătorilor de a realiza sisteme cât mai
perfomante care să satisfacă cerinţele şi exagerările utilizatorilor. Cât de aproape (sau de departe) de
modelul relaţional teoretic trebuie să fie modelul datelor efectiv utilizat de SGBD pentru a putea afirma că
SGBD-ul respectiv utilizează sau nu modelul relaţional, deci este sau nu SGBDR?
Diversitatea modelelor relaţionale operaţionale au determinat, în mod natural existanţa unei mari

5
diversităţii de SGBDR, pentru a căror prezentare a fost necesară nuanţarea terminologiei. Au apărut o
serie de sintagme precum: sisteme cu interfaţă relaţională, sisteme pseudorelaţionale, sisteme complet
relaţionale.
Conceptele specifice organizăriidatelor în fişiere, SGBDR şi teoriei relaţionale între care se pot stabili analogii

Organizarea datelor în fişiere SGBDR Teoria relaţională

Fişier Tabelă Relaţie
Record(înregistrare) Linie Tuplu
Câmp Coloană Atribut
În general, conceptele utilizate la prezentarea SGBDR şi a modelelor relaţionale operaţionale
diferă de cele din cadrul teoriei relaţionale. Figura de mai sus prezintă comparativ conceptele organizării
datelor în fişiere, concepte SGBDR şi ale teoriei relaţionale.
Faptul că se pot stabili analogii între conceptele organizării datelor în fişiere şi conceptele
relaţionale, i-au determinat pe unii producători să prezinte sisteme fără nici o legătură cu modelul
relaţional drept SGBDR, în scopul asigurării succesului comercial al acestor sisteme.

1.6. Regulile lui Codd

Definirea unui SGBDR impune o detaliere a caracteristicilor pe care trebuie să le prezinte un SGBD
pentru a putea fi considerat relaţional.În acest sens, Codd a formulat 13 reguli care exprimă cerinţele pe
care trebuie să le prezinte un SGBD ca să fie relaţional. Deşi reguli au stârnit o serie de controverse, eu le
voi prezenta în continuare, ele fiind deosebit de utile în evaluarea unui SGBDR.
R0: Regula privind gestionarea datelor la nivel de relaţie
Sistemul trebuie să gestioneze baza de date numai prin mecanisme relaţionale.Acest lucru
înseamnă că sistemul trebuie să-şi îndeplinească toate funcţiile prin manipulări în care unitatea de
informaţie să fie mulţimea (relaţia), adică să utilizeze limbaje, precum SQL, care să opereze la un moment
dat pe o întreagă relaţie.Deci SGBD nu trebuie să accepte operaţii non-relaţionale care să îndeplinească
operaţiile de definire şi manipulare a datelor.
Unele sisteme utilizează mecanisme releţionale numai pentru o parte din funcţii, în special pentru
interogare. Aceste sisteme se numesc sisteme cu interfaţă relaţională ţi nu SGBDR.
R1: Regula privind reprezenterea logică a datelor
Toate datele din daza de date relaţională trebuie să fie reprezentate explicit la nivel logic, într-un
singur mod, şi anume ca valori în tabele de date. Acest lucru înseamnă că toate datele trebuie să fie
memorate şi prelucrate în acelaşi mod. Informaţiile privind numele de tabele,coloane, domenii, definiţiile
tabelelor virtuale, restricţii de integritate trebuie să fie memotare tot în tabele de date (cataloage).
Referinţa la 'nivelul logic' înseamnă că construcţia fizică nu este reprezentată şi nu necesită explicaţie.
R2: Regula privind garantarea accesului la date.
Orice dată din baza de date relaţională trebuie să poată fi accesată prin specificarea numelui da
tabelă, valorii cheii primare şi numelui de coloană.Această regulă exprimă cerinţa ca linbajul de cereri al
SGBDR să permită accesul la fiecare valoare atomică din baza de date.
R3: Regula privind valorile null
Sistemele trebuie să permită declararea să manipularea sistematică a valorilor null, cu
semnificaţia unor date lipsă sau inaplicabile. Valorile null, care diferă de şirurile de caractere ' spaţiu' sau
de şirurile vide da caractere sunt deosebit de importante în implementarea restricţiilor de integritate
(integritatea entităţii şi integritatea refereanţială).
R4: Regula privind metadatele
Descrierea bazei de date trebuie să se prezinte la nivel logic în acalaşi mod cu descrierea datelor
propiu-zise, astfel încât utilizatorii autorizaţi să poată descrierii bazei de date aceleaşi operaţii ca şi asupra
datelor obijnuite. Acestă regulă specifică că trebuie să existe un unic limbaj de manipulare a metedatelor
şi a datelor propui-zise, mai mult, există o unică structură logică folosită pentru a depozita informaţiile de
sistem.
Sisteme nu trebuie să facă diferenţieri în definirea şi tratarea datelor şia metadatelor, utilizând o

6
singură structură, şi anume cea relaţionala.
R5: Regula privind facilitaţile limbajelor utilizate
Un sistem relaţional trebuie să facă posibilă utilizarea mai multor limbaje, în mai multe moduri.
Trebuie să existe însă cel puţin un limbaj de nivel înalt ale cărui instrucţiuni să poată exprima oricare din
următoarele operaţii: definirea tabelelor de date, definirea tabelelor virtuale, manipularea datelor),
definirea restricţiilor de integritate, autorizarea accesului, precizarea limitelor tranzacţiilor.
A se nota aici că noul standard O/I pentru SQL furnizează toate aceste funcţii, deci orice limbaj
care acceptă acest standard va satisface automat această regulă.
R6: Regula privind actualizarea tabelelor virtuale
Toate tabelele virtuale care teoretic sunt posibil de actualizat trebuie să poată fi efectiv
actualizabile.Nu toate atributele din cadrul unei tabele virtuale, deci nu toate tabele virtuale sunt toeretic
actualizabile.
R7: Regula privind inserările, modificările şi ştergerile în baza de date
Sistemul trebuie să ofere posibilitatea manipulării unei tabele (da bază sau virtuală) nunumai în
cadrul operaţiilor de regăsire, ci şi în acţiuni de inserare, modificare şi ştergere a datelor. Această regulă
exprimă cerinţa ca prin operaţiile în care se schimbă bazei da date să se lucreze la un moment dat pe o
întreagă relaţie.
R8: Regula privind independenţa fizică a datelor
Programele de aplicaţie nu trebuie să fie afectate de schimbările efectuate în modul de
reprezentare a datelor sau în metodele de acces. O schimbare a structurii fizice a datelor nu trebuie să
blocheze funcţionarea programelor de alpicaţie.
R9: Regula privind independenţa logică a datelor
Programele de aplicaţie nu trebuie să fie afectate de schimbările efectuate asupra relaţiilor bazei de
date, schimbări care conservă datele şi care toeretic garantează valabilitatea programelor de apicaţie
existente.
R10: Regula privind restricţiile de integritate
Restrictiile de integritate trebuie să fie definite în limbajul utilizat de sistem pentru definirea
datelor ţi să fie memorate în cadrul bazei de date şi nu în cadrul programului de aplicaţie.
R11: Regula privind distribuirea geografică a datelor
Limbajul de manipulare a datelor utilizat de sistem trebuie să permită ca, în situaţia în care datele
sunt distribuite, programele de aplicaţie să fie logic aceleaşi cu cele utilizate în cazul în care datele sunt
fizic centralizate.
Utilizatorul trebuie să perceapă datele ca fiind centralizate. Sarcina de localizare a datelor, atunci
când acestea sunt distribuite geografic precum şi sarcina recompunerii datelor trebuie să revină sistemului
şi nu utilizatorului.
R12: Regula privind prelucrarea datelor la nivelul de bază
Dacă sistemul posedă un limbaj de bază (de nivel scăzut) orientat pe prelucrare de recorduri
(tupuri) şi nu pe prelucrarea mulţimiilor (relaţiilor), acest limbaj nu trebuie să fie utilizat pentru a se
evitarestricţiile de integritate sau restricţiile introduse prin utilizarea limbajelor de nivel înalt, adică
accesul la toate dazele va fi controlat de SGBDR, altfel integritate bazelor de date nu poate fi
compromisă fără cunoaşterea utilizatorului sau a administratorului bazei de date.

7
Capitolul 2. Despre ORACLE şi Oracle Application Express(APPEX).

2.1. Oracle
Oracle constă dintr-un set complet de constructori de aplicaţii şi produse pentru utilizatori,cautând
să asigure soluţii complete în tehnologia informaţiei.
Aplicatiile Oracle sunt portabile pe un numar mare de staţii de lucru şi sisteme de operare, de la
calculatoare personale la main frame-uri cu procesoare paralele.
Oracle este înzestrat cu un flexibil Sistem de Management al Bazelor de Date(DBMS)-Serverul
Oracle-pentru stocarea şi managementul informaţiei utilizate de aplicaţii.
Ultimul server Oracle, ORACLE 11g, utilizează o bază de date cu toate avantajele unei structuri
relaţionale, având în plus capacitatea de a stoca şi executa obiecte de tip bază de date precum proceduri şi
mecanisme de siguranţă.
Serverul Oracle cuprinde un DBMS care controlează:
 Stocarea de date în sfera bazelor de date dedicate

 Recuperarea de date pentru aplicaţii utilizând tehnici de optimizare

adecvate
 Securitatea bazelor de date şi a taskurilor permise pentru anumiţi
utilizatori
 Consistenţa şi protecţia datelor,incluzând arhivarea taskurilor şi
mecanisme de căutare
 Comunicarea şi integritatea informaţiilor,când bazele de date sunt
distribuite într-o reţea.

2.2. APPEX
Oracle Application Express este un instrument de dezvoltare rapidă a aplicaţiilor web pentru baze
de date Oracle. Folosind doar un browser web şi experienţă limitată în programare, se pot dezvolta
aplicaţii profesionale care sunt atât rapide cât şi sigure. Datorită caracteristicilor predefinite, cum ar fi
teme de interfaţă, controalele de navigare, agenţi de formular şi rapoartele flexibile, Oracle Application
Express accelerează procesul de dezvoltare al aplicaţiei.
Din perspectiva utilizatorului final, aplicaţiile desfăşurate necesită doar un navigator web şi
accesul la o bază de date Oracle care rulează Application Express.
Oracle Application Express se instalează cu baza de date Oracle şi este format din datele din
tabele şi codul PL/SQL.
Fie că se execută mediul de dezvoltare al Oracle Application Express sau o aplicatie construită cu
Oracle Application Express, procesul este acelaşi. Browser-ul trimite o cerere de adresă URL care este
translatată într-un apel Oracle Application Express PL/SQL. După ce baza de date procesează codul
PL/SQL, rezultatele sunt retransmise către browser sub forma de cod HTML. Acest ciclu se petrece de
fiecare dată cand se cere sau se execută o pagină.
Sesiunea publică a aplicaţiei este gestionată în tabelele bazei de date din cadrul Oracle Application
Express. Nu foloseşte o conexiune de baze de date dedicată. În schimb, fiecare cerere este făcută printr-o
sesiune de baze de date separată, consumatoare de resurse minime de calculator.
Atât Serverul HTTP Oracle, cât şi Oracle Application Express Listener functionează ca agenţi de
comunicare între serverul Web şi obiectele Oracle Application Express din baza de date Oracle. Mai
exact, acestea mapează cereri de browser spre solicitări de proceduri de baze de date stocate peste o
conexiune SQL*Net. Următorul grafic ilustrează arhitectura Oracle Application Express utilizând

8
Serverul HTTP Oracle şi mod_plsql.

Motorul Application Express face şi procesează pagini. De asemenea, efectuează următoarele

sarcini:
 Gestionarea sesiunii de stat
 Servicii de autentificare
 Servicii de autorizare
 Controlul fluxului de pagină
 Validări de prelucrare
Zona în care se vor dezvolta aplicaţii se numeşte spaţiu de lucru. Un spaţiu de lucru este o bază
de date virtuală privată, care permite mai multor utilizatori să lucreze în cadrul aceleiaşi instalări Oracle
Application Express păstrând în acelaşi timp private obiectele lor, datele şi aplicaţiile.
Într-un mediu tipic de dezvoltare, se poate crea un singur spaţiu de lucru pe care dezvoltatorii să-l
împartă. Oricum, se poate crea spaţii de lucru dedicate pentru anumiţi dezvoltatori sau proiecte. Crearea
unui spaţiu de lucru dedicat limitează accesul la obiectele spaţiului de lucru numai pentru utilizatorii
asociaţi cu spaţiul de lucru.
Următoarea ilustraţie arată relaţia dintre utilizatori şi dezvoltatori, spaţii de lucru şi scheme de
baze de date.

Când se configurează utilizatorii Application Express la o organizaţie mare, se atribuie roluri şi

privilegii utilizatorilor specifici. Rolurile din Oracle Application Express includ următoarele:

■ Administratorii spaţiului de lucru sunt utilizatorii care realizează sarcini specifice de administrator
într-un spaţiu de lucru, cum ar fi gestionarea conturilor de utilizator, monitorizarea activităţii în spaţiul de
lucru, precum şi vizualizarea fişelor înregistrate.

9
■ Dezvoltatorii sunt utilizatori care creează şi editează aplicaţii şi modifică obiectele bazei de date.
Dezvoltatorii pot avea propriul spaţiu de lucru sau pot împărţi un spaţiu de lucru.
■ Utilizatorii finali nu au privilegii de dezvoltare. Utilizatorii finali se definesc pentru accesa aplicaţii
care nu utilizează o schemă externă de autentificare.
■ Administratorii instanţă sunt superutilizatori care gestionează o întreagă instanţă găzduită utilizând
aplicaţia Application Express Administration Services.

10
Capitolul 3. Proiectul logic al aplicaţiei activitatea de schimb valutar într-o
bancă.

3.l. Descrierea unităţii economice la care se află activitatea de schimb valutar

În banca studiată se desfăşoară activităţi de vânzare/cumpărare valută. Un operator va utiliza
aplicaţia pentru a facilita calculul valorii plătite clientului conform cursului valutar/zi, precum şi pentru
realizarea situaţiilor finale, zilnice sau periodice.
Activitatea de schimb valutar poate cumpăra în mod liber, fără limitări, contra lei, valută sub
formă de numerar (bancnote şi monede care nu sunt divizionare) şi cecuri de călătorie, în oricare din
valutele cotate de Banca Naţională a României, de la rezidenţi şi nerezidenţi, persoane fizice.
Atât cursurile de vânzare cât şi cele de cumpărare pentru toate valutele şi cecurile de călătorie
negociate vor fi afişate zilnic, la loc vizibil, la începutul programului de lucru. Cursurile afişate mai pot
fi modificate în timpul zilei respective de lucru, în cadrul unei localităţi, unitatea de schimb valutar va
practica, aceleaşi cursuri pentru toate punctele sale de schimb.
Cursurile afişate vor fi înscrise în listele de cursuri zilnice, semnate de persoanele împuternicite
de conducerea băncii şi cu aplicarea ştampilei punctului de schimb valutar. Listele de cursuri se vor
păstra ca documente justificative la punctele de schimb valutar respective.
Pentru operaţiunile de schimb valutar se pot încasa comisioane numai în lei, în afara marjei între
cursurile de cumpărare şi cele de vânzare. Comisioanele vor fi afişate zilnic, la începutul programului de
lucru şi nu mai pot fi modificate în timpul zilei de lucru.
Pentru fiecare tranzacţie, punctele de schimb valutar vor întocmi buletine de schimb tipizat.
Buletinele de schimb valutar vor fi emise, înregistrate, evidenţiate şi utilizate ca documente cu
regim special, în care scop vor purta în mod obligatoriu antet, serie şi număr de ordine imprimate.
Buletinele de schimb valutar se întocmesc în două exemplare, fiind obligatorie completarea lor cu
toate datele prevăzute în formular. Pe buletinul de schimb valutar, la rubrica nr. l "Numele şi
prenumele", se va trece numele titularului buletinului de identitate sau al paşaportului individual.
Originalul buletinului de schimb valutar, datat, semnat şi ştampilat de punctul de schimb se
înmânează clientului, iar exemplarul 2 se păstrează ca document justificativ de casă.
În cazul unităţilor de schimb valutar care au organizat operaţiunile în sistem computerizat,
întocmirea buletinelor de schimb valutar se poate face pe calculatorul electronic, cu condiţia însă de a se
respecta întocmai modelul de formular aprobat, inclusiv regimul special al acestuia, prin înscrierea
seriei şi a numărului de ordine.
Se va ţine un registru zilnic al tranzacţiilor, indicând cumpărările şi vânzările de valuta şi cecuri de
călătorie, pe feluri de valute, precum şi sumele în lei plătite şi, respectiv, încasate în cadrul acestor
operaţiuni.
În vederea asigurării supravegherii bancare asupra tranzacţiilor, unităţile de schimb valutar vor
avea în dotare tehnică de calcul adecvată pentru preluarea pe suport magnetic a operaţiunilor efectuate
prin toate punctele de schimb valutar.

3.2. Cerinţele utilizatorului

Evidenţa clienţilor
Evidenţa cursului valutar / monedă
Evidenţa tranzacţiilor valutare
Tipărirea bonului fiscal în urma realizării unei tranzacţii
Afişarea unor situaţii zilnice sau periodice privind totalul tranzacţiilor
REGULILE UNITĂŢII
~ Nici o tranzacţie nu se poate desfăşura fără detalii referitoare la clienţi O tranzacţie este fie de
cumpărare valută fie de vânzare valută Orice tranzacţie se finalizează cu tipărirea unui bon fiscal

11
DESCRIEREA DATELOR DE INTRARE
Actele de identitate (buletin, carte de identitate, paşaport) ale clienţilor
Cursul valutar introdus în fiecare zi
DESCRIEREA SITUAŢIILOR NECESARE
Bonul fiscal tipărit la fiecare tranzacţie
Situaţia zilnică a vânzărilor de valută
Situaţia zilnică a cumpărărilor de valută
Situaţii periodice ale vânzărilor de valută
Situaţii periodice ale cumpărărilor de valută
Situaţia vânzărilor şi cumpărărilor raportate la un client
Evoluţia cursului afişat de către Banca Naţionala Română

3.3 CREAREA MODELULUI CONCEPTUAL LOCAL, PENTRU VEDERILE UTILIZATORILOR

Obiectivul urmărit constă în crearea unui model conceptual local, pentru view-urile utilizatorilor.
Primul pas în proiectarea bazei de date este de a colecta datele necesare pentru realizarea sistemului,
ceea ce putem culege, discutând cu viitorii utilizatori ai bazei de date.

3.3.1. Identificarea tipurilor de entităţi

În urma analizei listei documentelor de intrare şi de ieşire se conturează următoarele tipuri de entităţi:
Clienţi - grupează datele clienţilor firmei;
Curs valutar- memorează cursul valutar pe fiecare monedă în fiecare zi;
Valută- memorează monezile cu care se realizează, tranzacţii;
Cumpărări — cuprinde datele referitoare la cumpărările efectuate;
Vânzări - cuprinde datele referitoare la vânzările efectuate;
Tranzacţii- grupează datele tranzacţiei valutare;

3.3.2 Identificarea tipurilor de relaţii

Tip de entitate Tip de relaţie Tip de entitate Cardinalitate
CursVal este referit în Vânzări 1:N
CursVal este referit în Cumpărări 1:N
Valută este referită în Curs 1:N
Clienti efectuează Vânzări 1:N
Clienti efectuează Cumpărări 1:N

3.3.3 Identificarea şi asocierea atributelor la tipurile de entităţi şi tipurile de relaţii

Tip de entitate Atribute Descriere atribute

CLIENŢI idClient id-ul fiecărui client, valoarea ce se ia din secvenţă
nume numele clientului
tara ţara clientului
tip_ai tipul actului de identitate
serie_ai seria actului de identitate
numar_ai numărul actului de identitate
org_em_ai organul care a emis actul de identitate
data_em_ai data emiterii actului de identitate

12
CURSVAL idCurs id-ul fiecărui curs, valoarea ce se ia din secvenţă
nr_schimb Numarul scimbarii zilnice

idValuta id-ul fiecărui client, valoarea ce se ia din secvenţă

dataCurs data la care s-a înregistrat cursul

curs_cump cursul de cumpărare
curs_vânz cursul de vânzare
curs_bnr cursul afişat de BNR
VALUTE
idValuta id-ul fiecărei valute, valoarea ce se ia din secvenţă

idTranz id-ul fiecărei tranzacţie, val. ce se ia din secvenţă

idCurs id-ul fiecărui curs, valoarea ce se ia din secvenţă

suma suma în lei, reprezentând contravaloarea valutei

VÂNZĂRI
idVanzare id-ul fiecărei vânzări, valoarea ce se ia din secvenţă

idClient

idCurs id-ul fiecărui curs,

suma suma în lei, reprezentând contravaloarea vânzării

CUMPĂRĂRI
idCumpar id-ul fiecărei cumpărări, val. ce se ia din secvenţă

idClient

idCurs id-ul fiecărui curs,

suma suma în valută,

3.3.4. Determinarea domeniilor de definiţie a atributelor

Domeniul atributului: Un set de valori ce se pot da acelui atribut.
Pentru a controla în totalitate domeniul atributelor, se pot evidenţia următoarele:
 setul de valori admisibile pentru un atribut
 operaţiile admisibile asupra unui atribut
 ce atribute se pot compara cu atributul respectiv, în combinaţiile cu alte atribute
 mărimea şi formatul câmpului atributului

3.3.5. Determinarea atributelor care compun cheile candidate şi primare

O cheie candidat este un atribut, sau un grup de atribute care identifică unic fiecare înregistrare din tipul
de entitate. Putem identifica una sau mai multe chei candidat, în acest caz trebuie să alegem dintre ele o

13
cheie primară. Cheile candidat care nu sunt primare, se vor numii chei alternante. Pentru alegerea unei
chei ca fiind cheie primară, vom ţine cont de următoarele:
 cheia candidat, care are un număr minimal de atribute
 cheia candidat, care îşi va schimba cel mai rar valoarea
 cheia candidat, care este cel mai puţin probabil să sufere modificări în viitor
 cheia candidat, care este compusă din cele mai puţine caractere (în cazul atributelor
de tip caracter)
 cheia candidat, care este cel mai uşor de folosit din punctul de vedere al
utilizatorului.
Clienţi
Nume atribut Tipul Dimensiunea Reguii
idClient secventa 2 Cheie primară
nume varehar 40
tara varchar 20
tip_ai char 2
seria_ai char 2
numar_ai char 7
org_em_ai varchar 40
data_em_ai smalldatetime 4
CursVal
Nume atribut Tipul Dimensiunea Reguli

idCurs smallint 4 Cheie primară

nr_schimb smallint 2
idValuta smallint 2
dataCurs smalldatetime 4
curs_cump int 4
curs_vânz int 4
curs_bnr int 4
Valută
Nume atribut Tipul Dimensiunea Reguli
idValuta smallint 2 Cheie primară
CodValuta varchar 3
denValuta varchar 20
Vânzări
Nume atribut Tipul Dimensiunea Reguli

idVanzare int 4 Cheie primară

idClient int 10
idCurs smallint 4
suma int 4

14
Cumpărări
Nume atribut Tipul Dimensiunea Reguli

idCumpar int 4 Cheie primară

idClient int 10
idCurs smallint 4
suma int 4

3.3.6. Desenarea diagramei entity-relationship

3.4. CREAREA ŞI VALIDAREA MODELULUI LOGIC LOCAL

Obiectivul urmărit este de a crea un model logic local bazat pe modelul conceptual al
utilizatorilor asupra firmei şi validarea prin procesul de normalizare şi prin tehnica tranzacţiilor
cerute.
Vom verifica modelul conceptual creat în pasul anterior şi vom elimina din el structurile care sunt
dificil de realizat într-un SGBD.

3.4.1. Proiectarea modelului conceptual local pe un model logic local

Eliminarea relaţiilor multe-la-multe
Dacă în modelul de date apar relaţii de tipul multe-la-multe (M:N), trebuie descompuse în două
relaţii unu-la-multe (l :M) prin adăugarea unei noi entităţi suplimentare.
Eliminarea relaţiilor complexe
O relaţie complexă este o relaţie între mai mult de două tipuri de entităţi. Dacă în modelul
conceptual apar relaţii complexe, acestea trebuie eliminate. Se pot elimina prin crearea unui nou tip de
entitate, care să fie în relaţie de tipul l :M cu fiecare tip de entitate din relaţia iniţială, partea cu M a
relaţiei fiind spre tipul de entitate nou creat.
Eliminarea relaţiilor recursive
Relaţiile recursive sunt nişte relaţii particulare, prin care un tip de entitate este în relaţie cu el
însuşi. Dacă apare o astfel de relaţie în modelul conceptual, ea trebuie eliminată. Eliminarea se poate
rezolva prin crearea unei noi entităţi unde să se evidenţieze fiecare entitate care este legată de entitatea din
tipul de entitate iniţial. În acest caz vom avea o relaţie de tipul l :M între tipul de entitate iniţial şi tipul de
entitate nou creat şi o relaţie de tipul 1:1 între tipul de entitate nou creat şi tipul de entitate iniţial.
Eliminarea relaţiilor cu atribute
Dacă în modelul conceptual avem relaţii cu atribute, putem descompune această relaţie,

15
identificând un nou tip de entitate în care să înregistrăm atributele necesare.
Reexaminarea relaţiilor de tipul 1:1
În modelul conceptual putem avea entităţi între care să avem relaţie de tipul 1:1. Se poate întâmpla ca
aceste entităţi să fie de fapt aceeaşi entitate cu nume diferite. Dacă suntem în acest caz, unim cele două
entităţi, cheia primară devenind cheia primară al uneia dintre entităţi.
Eliminarea relaţiilor redundante
O relaţie este redundantă dacă se poate ajunge de la un tip de entitate la alt tip de entitate pe
mai multe drumuri. Amintesc că se vrea a se ajunge la un model minimal şi deci relaţiile redundante
nu sunt necesare. Decizia ca o relaţie este redundantă trebuie să fie precedată de o analiză amănunţită a
relaţiilor care compun cele două drumuri dintre cele două entităţi, pentru că pot apărea situaţii, când o
relaţie este aparent redundantă, dar în realitate este nevoie de ea.
În modelul logic local nu avem nici un astfel de caz de aceea putem considera modelul conceptual local
ca fiind modelul logic local.

3.4.2. Crearea relaţiilor pentru modelul logic local

Relaţia pe care un tip de entitate o are cu alt tip de entitate este reprezentată prin mecanismul
cheie primară/cheie străină. Cheia străină pentru o entitate este reproducerea cheii primare altei entităţi.
Pentru a decide entităţile unde vom include copia cheii primare a altei entităţi, trebuie înainte să
identificăm entităţile "părinte" şi "fiu". Entităţile "părinte" se referă la acele entităţi ale căror chei primare
se vor copia în entităţile "fiu".
Pentru descrierea relaţiilor vom folosi un limbaj de definire a bazei de date (Database Definition
Language - DBDL). în acest limbaj, specificăm prima dată numele entităţii, urmat de atributele asociate
între paranteze. După aceea identificăm cheia primară şi toate cheile alternante, precum şi/sau cheile
străine.
Clienţi (IDClient, Nume, Tara, Tip_ai, Serie_ai, Numar_ai, Org_em_ai, Data_em_ai)
Cheie primară: IDclient;

Curs Val (IDCurs, IdValuta, DataCurs, Curs_cump, Curs_vânz, Curs_bnr)

Cheie primară: IDCurs;
Cheie străină: IdValuta, se referă la Valute(IdValuta);

Valute (IdValuta, CodValuta, DenValuta)

Cheie primară: IdValuta;

Cumpărări (IDCumpar,IdClient, IDCurs, Suma)

Cheie primară: IDCumpar;
Cheie străină: IDCurs, se referă la CursVal(IDCurs)
Cheie străină:IDClient se referă la Clienti(IDClient)

Vânzări (IDVânzare,IdClient, IDCurs, Suma) Cheie primară: ID Vânzare;

Cheie străină:IDCurs, se referă la CursVal(IDCurs);
Cheie străină:IDClient se referă la Clienti(IDClient)

3.4.3. Validarea modelului, utilizând normalizarea

Normalizarea este procesul prin care se decide dacă atributele pot sau nu să rămână împreună.
Conceptul de bază a teoriei relaţiilor este că atributele sunt grupate împreună pentru că există o relaţie logică
între ele.
Proiectarea normalizată organizează datele în funcţie de dependenţele funcţionale. Deci acest proces
este situat undeva între proiectarea conceptuală şi cea fizică. Proiectul logic nu este un proiect final. El ajută
proiectantul să înţeleagă natura datelor în întreprindere. Proiectul fizic poate fi diferit. Există posibilitatea ca

16
unele tipuri de entităţi să se denormalizeze. Totuşi normalizarea nu este un timp pierdut.
Proiectul normalizat este robust şi independent de anomaliile de actualizare. Calculatoarele moderne au
mult mai multă putere de calcul, ca cele de acum câţiva ani. Din această cauză, câteodată este mai convenabil
implementarea unei baze de date cu puţină redundanţă, decât suportarea cheltuielilor pentru procedurile
adiţionale.
Normalizarea produce o bază de date care va fi uşor extensibilă în viitor. Procesul de normalizare
include următoarele etape mari:
Forma Normală Unu (INF), eliminarea grupurilor repetitive;
Forma Normală Doi (2NF), eliminarea dependenţelor parţiale de cheia primară;
Forma Normală Trei (3NF), eliminarea dependenţelor tranzitive de cheia primară;
Forma Normală Boyce-Codd (BCNF), eliminarea anomaliilor care au mai rămas.
Clienţi (IDClient, Nume, Tara, Tip_ai, Serie_ai, Numar_ai, Org_em_ai, Data_em_ai)
Curs Val (IDCurs, IdValuta, DataCurs, Curs_cump, Curs_vânz, Curs_bnr)
Valute (IdValuta. CodValuta, DenValuta)
Cumpărări (IDCumpar, IDTranz, IDCurs, Suma)
Vânzări flDVanzare, IDTranz, IDCurs, Suma)
În relaţiile noastre nu există grupuri repetitive deci relaţiile sunt în Forma normală unu.
Forma Normală Doi
O relaţie este în 2NF dacă este în 1FN şi fiecare atribut care nu aparţine cheii primare este total
dependent de cheia primară. Relaţiile la care cheia primară se compune dintr-un singur atribut, aşa cum
sunt relaţiile noastre sunt în Forma normală doi.
Forma Normală Trei
O relaţie este în 3NF dacă este în 2FN şi nu există nici un atribut care să nu aparţină cheii primare
şi care să fie tranzitiv dependent de cheia primară. În relaţiile noastre nu există dependenţe tranzitive de
cheie, deci relaţiile se află în Forma normală trei.

3.4.4. Validarea modelului utilizând tranzacţiile

În acest pas se validează baza de date prin verificarea tranzacţiilor ce se cer de utilizator.
Luând în considerare tipurile de entităţi, relaţiile, cheile primare şi străine, încercăm să rezolvăm manual
cerinţele utilizatorilor. Dacă reuşim să rezolvăm fiecare tranzacţie cerută, atunci înseamnă că modelul
creat este valid. Dacă nu putem rezolva o tranzacţie, atunci este foarte posibil să fi omis un atribut, o
relaţie, sau o entitate din modelul de date. Sunt necesare următoarele tranzacţii:
I. Clienţi
T1 - Vizualizare clienţi
Cheia primară a entităţii clienţi este IDClient. în cadrul acestei forme se pot vizualiza toţi clienţii
introduşi în baza de date, adică clienţii care au efectuat deja o tranzacţie;
T2 - Căutare client
Prin tastarea numelui clientului căutat se verifică caracter cu caracter potrivirea cu unul din numele
deja introduse; în cazul potrivirii exacte, în fereastra deschisă va rămâne doar numele clientului căutat,
în caz contrar clientul va trebui înregistrat;
T3 - Adăugare client
In cazul în care clientul nu se găseşte în baza de date acesta va fi introdus împreună cu toate datele
necesare identificării lui (nume, ţară, tip act, serie act, număr act, organul care a emis actul precum şi data
emiterii);
T4 - Modificare date client
Dacă clientul se află în baza de date a casei de schimb valutar dar datele acestuia s-au modificat
între timp, acestea vor fi modificate;
II. Valute
T5 - Vizualizare valute
Cheia primară a entităţii este IdValuta. Din forma Valute se pot vizualiza toate valutele care se află

17
în baza de date, observându-se la fiecare codul scurt, format din trei litere precum şi întreaga denumire
pentru a putea fi recunoscute mai uşor;
T6 — Adăugare valute
Dacă este nevoie de o valută nouă, care nu a fost introdusă până în acest moment, se poate
înregistra prin codul scurt urmat de întreaga denumire; prima dată verific dacă valuta de introdus nu
există deja; după care în caz că nu există, inserez detaliile necesare. Dacă există deja valuta, nu admit
inserarea.
T7 - Modificare valute
Pentru a modifica datele despre o valută, se caută mai întâi IdValuta. Dacă acesta există, se
modifică datele despre ea, altfel nu se poate.
T8 - Ştergere valută
Se caută cheia valutei de şters. Dacă există, se şterge valuta, altfel apare un mesaj de eroare.
III. Curs valutar
T9 - Vizualizare curs
Cheia primară a entităţii este IDcurs. Din forma Curs se poate vizualiza cursul pentru toate
valutele care se află în baza de date; acest curs este alcătuit din cursul BNR, cursul de cumpărare (cu
care casa de schimb valutar cumpără valuta de la clienţi) şi din cursul de vânzare (cu care casa de
schimb valutar vinde valuta clienţilor).
TIO - Adăugare curs
Acesta trebuie introdus în parte pentru fiecare valută, în cele trei câmpuri: curs BNR, curs
cumpărare şi curs vânzare.
TI l - Modificare curs
In cazul în care cursul este introdus greşit, se va suprascrie noul curs.
T12 - Ştergere curs
Se caută cheia cursului pe care dorim să-l ştergem. Dacă există se şterge.
IV. Cumpărări
TI6 - Adăugare cumpărare
Cheia primară a entităţii este IDCumpar. Se selectează codul valutei dorite, din cele existente în
baza de date, lângă acesta fiind automat copiat cursul de cumpărare.
TI7 - Şterge tranzacţie de cumpărare.
Se caută cheia tranzacţiei de şters. Când aceasta este găsita se şterge tranzacţia.
V. Vânzări
TI8 - Adăugare vânzare
Cheia primară a entităţii este IDVanzare. Se selectează codul valutei dorite, din cele existente în
baza de date, lângă acesta fiind automat copiat cursul de vânzare.
TI9 - Şterge tranzacţie de vânzare.
Se caută cheia tranzacţiei de şters. Când aceasta este găsită se şterge tranzacţia.

3.4.5. Definirea regulilor de integritate a bazei de date

Regulile de integritate sunt importante pentru a proteja baza de date împotriva posibilelor
inconsistenţe. Dacă este necesar, putem produce un proiect fizic de bază de date, pentru a putea vedea mai
uşor ce reguli sunt necesare.
Vom considera cinci tipuri de reguli de integritate:
 necesitatea datelor,
 reguli asupra domeniului atributelor,
 integritatea entităţilor,
 integritatea referinţelor,
 regulile întreprinderii.
1. Necesitatea datelor
Există atribute care nu pot conţine valoarea nulă, ci trebuie să aibă totdeauna o valoare. Aceste reguli

18
deja le-am identificat, când am documentat atributele în pasul 4.1.3.
2. Reguli asupra domeniului atributelor
Unele atribute au un domeniu de definiţie bine definit. Aceste domenii trebuie respectate.
Domeniile de definiţie au fost deja identificate când am documentat domeniile atributelor în pasul 4.1.4.
3. Integritatea entităţilor
Cheia primară a entităţilor nu poate lua valori nule pentru că îşi pierde rolul de identificator
unic. Aceste reguli au fost deja identificate, când am documentat cheile primare în pasul 3.1.5.
4. Integritatea referinţelor
Cheia străină din tipul de entitate "fiu" face legătura cu o entitate din tipul de entitate "părinte".
Deci, dacă cheia străină conţine o valoare, ea trebuie neapărat să se regăsească şi în tipul de entitate
"părinte".În general dacă participarea tipului de entitate "fiu" este totală, atunci nu putem avea valoare
nulă în cheia străină. În caz contrar putem avea valoare nulă.
Considerăm următoarele cazuri:
Cazul 1: Inserarea unei entităţi în tipul de entitate "fiu": Pentru a verifica integritatea referinţei,
verificăm dacă atributele din componenţa cheii străine sunt vide, sau să existe entitate în tipul de
entitate "părinte" care să aibă valoare cheii primare egală cu valoare cheii străine.
Cazul 2: Ştergerea unei entităţi din tipul de entitate "fiu" : Ştergerea unei entităţi din tipul de entitate
"fiu" nu cauzează probleme cu privinţă la integritatea referinţelor.
Cazul 3: Actualizarea cheii străine în tipul de entitate "fiu" : Acest caz este similar cazului 1.
Cazul 4: Ştergerea unei entităţi din tipul de entitate "părinte" : Dacă se şterge o entitate din tipul de entitate
"părinte", integritatea referinţelor se strică în cazul în care există entităţi în tipul de entitate "fiu", care se
referă la entitatea ştearsă. Există strategii severe de a rezolva integritatea referinţelor:
FĂRĂ ACŢIUNE Neacceptarea ştergerii unei entităţi din tipul de entitate părinte, dacă acesta este
referit de o entitate din tipul de entitate fiu.
CASCADĂ Dacă o entitate din tipul de entitate părinte este ştearsă, se şterg automat toate entităţile
din tipurile de entităţi fiu. Dacă tipurile de entităţi fiu au şi ele la rândul lor alte tipuri de entităţi fiu, se va
efectua ştergerea în cascadă în toate tipurile de entităţi fiu, până la ultimul nivel.
Cazul 5: Modificarea cheii primare în tipul de entitate părinte : Dacă se modifică cheia primară din tipul
de entitate părinte, integritatea referinţelor se strică. Pentru menţinerea integrităţii, se pot folosii toate
cazurile descrise mai sus, dar cel mai indicat este folosirea cazului FĂRĂ ACŢIUNE.
Clienţi
cheie primară: IDClient
CursVal
cheie primară: IDCurs - la modificare şi la ştergere : FĂRĂ ACŢIUNE
cheie străină: IdValuta nenulă, se referă la Valute
Valute
cheie primară: IdValuta –
Vânzări
cheie primară: IDVânzare — la modificare şi la ştergere : FĂRĂ ACŢIUNE
cheie străină: IDClient nenulă, referindu-se la Client
cheie străină:IdCurs nenulă, referindu-se la CursVal.
Cumpărări
cheie primară: IDCumpar - la modificare şi la ştergere : FĂRĂ ACŢIUNE
cheie străină: IDClient nenulă, referindu-se la Client
cheie străină:IdCurs nenulă, referindu-se la CursVal.

3.4.6. Verificarea modelului logic local cu ajutorul utilizatorului.

Obiectivul urmărit este convingerea că modelul creat reprezintă în totalitate realitatea care trebuie
modelată în baza de date. La verificarea modelului s-a constatat: este conform cu realitatea (nu s-au găsit
diferenţe).

19
Capitolul 4. Proiectarea fizică.

4.1. Cerere de spaţiu de lucru ( Work space)

Pentru a crea o bază de date în Oracle(web based – pe internet),se accesează site-ul
http://apex.oracle.com de unde se creează un workspace, cu CLICK pe Request a Free Workspace se
obţine:

După accesarea link-ului de mai sus se urmează paşii pentru a crea un nou workspace.

Se completează formularul cu NUME, PRENUME şi EMAIL.

Apăsând butonul NEXT apare:

Numele Workspace-ul(Exemplu: Aplicatie_facultate, Baza_de_date) După NEXT:

20
 Numele Schemei (Exemplu: aplicatie, aplicatie_2012) apoi NEXT.

De ce aţi cerut crearea acestui workspace(Exemplu: University Project, To learn Oracle) Apăsaţi butonul
NEXT.

21
După definirea workspace-ului se primeşte de la oracle un email cu un link, dând CLICK pe acel link,
workspace-ul va fi creat în apex şi se primeşte încă un email cu datele de login(Workspace, Email şi
parola).

Se introduc datele de logare pentru a putea accesa Application Express. (Numele Workspace-ului,
Emailul, Parola)

22
4.2. Tabele APPEX
Pentru a putea crea tabele CLICK pe SQL Workshop şi din meniul de mai jos CLICK pe Object
Browser.

În partea dreapta a browserului există un buton CREATE, CLICK pe CREATE după care se alege TABLE.

Se vor proiecta pe rând tabelele în ordinea: clienti, valuta, cursVal, cumparari, vanzari. Pentru clienti obţinem:

23
Pentru valuta obţinem:

Pentru cursVal obţinem:

24
Aici arătăm cum se stabileşte cheia principală ca fiind cu valori date automat prin secvenţă.

După CLIK pe NEXT adăugăm cheia străină:

Atenţie!
Acţiunea devine efectivă numai după CLIK pe ADD.
La fel se introduce tabela cumparari cu două chei străine: idcurs spre cursval şi idclient spre clienti.

La fel se introduce tabela vanzari cu două chei străine: idcurs spre cursval şi idclient spre clienti.

25
Dacă vreţi să vedeţi fraza SQL se selectează SQL şi apare:

Dacă vrem să vedem cum arată legăturile între tabele, de exemplu, de la tabela cursval, cu CLIK pe model
obţinem:

26
Cu CLIK pe data obţinem datele prezente în tabelă:

Tot de aici se pot modifica datele (mai puţin cheia) sau introduce linii noi în tabelă.
Pentru a începe crearea aplicaţiei CLICK pe Application Builder şi se selectează Database Applications

Acum CLICK pe buton CREATE care se află în partea dreaptă.

27
Introduceţi numele bazei de date şi apăsaţi butonul NEXT

4.3. Formulare APPEX

Urmează să proiectăm formularele.
Pe ecranul următor selectăm Form, dăm nume tabelei valuta şi ADD Page

Similar pentru clienti

Similar pentru cursval:

28
Şi mai departe pentru cumparari:

În final pentru vanzari:

După adăugarea tuturor tabelelor apăsând butonul NEXT apare:

29
După NEXT:, NEXT … se alege Thema standard.

Din ecranul următor:

se alege Create Application şi se obţine:

30
Cu CLIK pe aplicaţia schimb valutar se poate vedea ce conţine, pentru moment, această aplicaţie:

Pentru formulare avem nevoie să luăm date din alte tabele. De exemplu când vrem să introducem o
înregistrare în cursval să putem alege denumirea valutei din valuta.

4.4 Liste de valori

POP LOV (Popup List Of Values) În aplicaţia creată apare:

Daţi CLICK pe numele tabelei cursval. Apare

31
Din meniul tree se dă CLIK dreapta pe idvaluta şi vom avea:

De aici CLIK pe edit şi obţinem:

32
Selectăm Popup List of Values,
Mai jos veţi găsi List Of Values, Selectaţi Create Dynamic List of Values

Daţi CLICK pe săgeata din dreptul Table or View

Apare:

33
De aici selectând valuta:

După NEXT va trebui să alegem la Display Column Den valuta şi la Return Value idvaluta.

După NEXT:

34
Se vede aici fraza Select în PLSQL. După Finish:
Apăsaţi Apply Changes

La fel vom proceda pentru a crea liste de valori pentru cumparari.

4.5 Formular cu subformular

Pentru a vedea vânzările către un anumit client vom crea o pagină:

Apoi:

35
Selectăm form şi după NEXT:

Selectăm Master Detail Form şi:

De aici selectăm tabela Clienti şi:

36
După NEXT:

Selectăm NO la Show Only Related Tables şi apoi view-ul creat anterior Det_vanz:

Selectăm cheile primare la tabelele legate şi:

37
Aici facem legătura între master şi detail:

Acum arătăm cum se va forma cheia:

Şi la detail. Apoi:

38
 Să le ordoneze după nume. Apoi:

Să fie pe aceeaşi pagină:

Apoi NEXT, NEXT şi Create.

4.5. Rapoarte APPEX

Pentru a crea un raport, din ecranul următor

cu CLIK pe Create Page obţinem:

39
Aici alegem Report şi după NEXT:

Avem de ales între mai multe tipuri de rapoarte. Alegem Interactive report şi NEXT.

Dăm numele paginii şi al regiunii şi NEXT.

Aici tot NEXT.

40
Trebuie să scriem acum fraza select pentru tabela care va fi originea raportului. Putem să scriem direct,
dar mai sigur că nu are greşeli este să o creăm prin Query Builder. După CLIK obţinem:

Aici selectăm tabela clienti şi de acolo coloanele pe care vrem să le avem în raport.

Selectând SQL vedem fraza SQL care trebuie scrisă în ecranul precedent. Selectăm fraza şi după CLIK
dreapta:

41
Acum apare un ecran din are putem copia fraza select. După copy părăsim acest ecran cu Ctrl+V ducem
fraza la locul ei.

După NEXT:

Aici trebuie să confirmăm cererea şi după Create:

42
Suntem anunţaţi că avem creat raportul. putem să-l rulăm sau să-l edităm. După Run Page:

Un alt exemplu interesant de raport este cel în care vrem să aflăm cursul valutar al zilei curente.
Pentru asta creăm mai întâi un view din object Browser ca să putem lua şi denumirea valutei din valuta.

Atenţie!
Comparaţia directă a datei cu data din server nu merge!
Am făcut, după cum se vede, transformarea în caracter şi apoi în data la ambele. Ca şi mai înainte din:

43
Cu Create Page …Report…

Alegem acum clasic report şi după NEXT:

Dăm aici numele şi NEXT

Alegem aici numele view creat anterior.

După confirmare putem să dăm Run şi se obţine:

44
 Pentru crearea unui raport grafic din pagina:

după CLIK pe Create Page:

alegem Chart şi după NEXT:

45
alegem în Chart Rendering HTML5 CHART şi la aspect Line apoi:

Completăm, ca în figură, istoric euro şi NEXT:

şi iar NEXT pentru a ajunge la:

46
Completăm Chart Title, denumirile care vor fi în query datacurs şi curs_bnr şi după NEXT:

Cu Create creăm raportul şi după Run va arăta aşa:

47
Dacă vrem să creăm un raport legat de o anumită pagină (de exemplu buletinul de vânzare pentru o
anumită tranzacţie) atunci după Create Page…Report…Interactive Report…NEXT…NEXT..ajungem la:

Unde după CLIK pe Query Builder:

48
Aici construim o cerere:

După CLIK pe SQL şi selectare apare:

49
Copiem cu CLIK dreapta!!!!
şi îl ducem înapoi

50
Facem aici modificări ca să calculeze suma în RON şi se ia Idvanzare din pagina 33.

Efectele acestei modificări se vor vedea în manualul de utilizare.

4.5. Crearea unui buton.

Din pagina aplicaţiei selectăm formularul cursval. Va apare:

51
La buttons selectăm + care înseamnă adăugarea unui buton. Apare:

Şi după NEXT:

NEXT din nou

52
Aici dăm numele butonului şi eticheta. Apoi NEXT:

Aici alegem aşezarea butonului

şi NEXT:

53
Alegem acţiunea de redirectare la pagină. După NEXT:
Trebuie să alegem acum pagina ce conţine formularul de introducere a valutelor:

După CLIK apare:

Dacă ştim numărul paginii putem să îl scriem direct. După NEXT:

54
De aici numai avem decât să facem CLIK pe Create Button şi se creează butonul.

4.6. Completare pagina de start

Până acum am avut în pagina de start a aplicaţiei (cea declanşată cu run applicationn) doar
formularele. Vrem să apară acolo şi rapoartele. Pentru aceasta din meniul aplicaţiei:

selectăm Home şi apare:

55
De la List vom avea:

Făcând CLIK pe Create List Entry obţinem:

56
Aici trebuie să selectăm pagina pe care o introducem în meniu. cu CLIK pe se
obţine :

De unde selectăm raportul pe care vrem să îl includem în meniu şi apoi îi dăm eticheta:

57
Capitolul 5. Manual de utilizare.

5.1. Intrarea în aplicaţie

După intrare în APPEX:

se dă CLIK pe Application Builder:

De aici, după Run pe aplicaţia schimb valutar:

58
Acesta este meniul pe care l-am construit.
De aici se pot introduce datele prin formulare identificate cu cuvântul form.

5.2. Introducerea clienţilor

Cu CLIK pe Clienti form:

Aici introducem datele clientului de exemplu:

59
Se selectează data din calendar şi după clic şi Create putem alege din meniu altă opţiune.

5.3. Introducerea cursului valutar

De exemplu Curs val form:

După CLIK:

60
 De aici cu CLIK pe săgeata de la Idvaluta:

Şi putem alege tipul de valută. Dacă nu avem în listă valuta respectivă o putem introduce cu butonul
Valută nouă. De exemplu:

După Create vom avea posibilitatea de a introduce cursul pentru această valută.
După cum am scris în analiza activităţii, într-o zi putem avea mai multe modificări ale cursului,
deci la Nr Schimb vom trece a câta modificare este.

5.4. Introducerea cumpărării de valută.

Din meniul aplicaţiei se alege Cumparari form:

61
 După CLIK obţinem:

Pe săgeata de la idclient obţinem:

De unde alegem clientul.

Dacă clientul nu este în listă cu CLIK pe client nou putem introduce un nou client din formularul
cunoscut.

62
 Pentru a stabili cursul facem CLIK pe Curs zilnic:

Preluăm, de aici, idcurs şi îl scriem în formularul de la cumpărări.

Cu CLICK dreapta obţinem:

De aici, cu CLICK pe Back, revenim la formularul de cumpărări unde trecem numărul de la

IDCURS:
La idcumpar se trece un număr încă nefolosit.

63
După scrierea sumei CLIK pe Create şi înregistrarea este înscrisă în baza de date şi apare raportul:

Cu CLICK pe creionul de la 25 apare:

Aici putem să facem eventuale modificări sau, dacă totul este în regulă, putem edita buletinul de

64
cumpărare cu CLICK pe butonul respectiv.

Revenind la HOME putem continua cu alte acţiuni.

5.5. Introducerea vânzării de valută.

Pentru a introduce o vânzare din meniul Home CLIK pe vanzari form:

După CLIK obţinem:

Aici, ca şi la cumpărări, alegem cursul zilnic, clientul existent sau introducem un client nou.

65
Alegem, de asemenea, un Idvanzare care nu a mai fost.
După Cursul zilnic apare:

Cu CLIK dreapta putem să ne întoarcem, să alegem sau să introducem un nou client şi introducem suma.

După Create apare:

66
Selectând, cu creionul, vânzarea 5 apare:

De aici cu CLIK pe Buletin De Vânzare:

Aici se vede cum acţionează un fomular cu raport şi un raport legat de acea pagină.

67
5.6 Rapoarte
5.6.1 Cursul zilnic.
Din meniul HOME se selectează Curs zilnic rap şi apare:

5.6.2 Clienţii.
Din meniul HOME selectăm Clienti rap inter şi apare:

Putem sorta clienţii după nume .

68
După Apply obţinem:

69
Putem să grupăm clienţii după diverse criterii, de exemplu după ţară:

După CLICK:

70
Selectăm Coloana Tara şi după CLICK:

De aici CLICK pe iconiţă şi avem:

71
5.6.3 Clienţi cu vânzări.
Dacă vrem să vedem ce vânzări de valută a făcut un anumit client CLICK pe Clienti cu vânzări :

De aici selectăm de la creion clientul care ne interesează şi după CLICK:

72
Se văd vânzările.
5.6.4 Clienţi cu cumpărări.

Analog se pot vedea cumpărările făcute de un client. Din meniul HOME KLICK pe Clienti cu
cumpărări :

De aici CLICK pe creionul din dreptul clientului căutat:

73
Aici se văd cumpărările.

74
Bibliografie
[1] Connoly T., Begg C., Strachan A., Data base systems, ADDison Wesley, 1997
[2] Harrington J.L., Relational database design, AP Professional, 1998.
[3] Iacob P., Baze de date, Curs Univ. ‘Transilvania’ Braşov, 2003
[4] Iacob P., Access la purtător, Editura Lux Libris, 2007

75