Introducere

Orice aplicaie a calculatoarelor n economie are la baz o colecie 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 accesm prin intermediul internetului aplicaia server. Marele avantaj este c
clientul este orice calculator care nu mai trebuie pregtit dinainte.
Pentru a nva s lucrezi cu Application Express (APPEX), Oracle pune la dispoziie spaiu de
lucru gratuit pe serverele pentru dezvoltatorul aplicaiei.
Lucrarea de fa conine 5 capitole.
n primul capitol am prezentat cteva concepte importante din teoria bazelor de date relaionale.
Capitolul al doilea prezint, pe scurt, sistemul Oracle i cteva caracteristici ale sistemului APPEX.
Proiectul logic al aplicaiei 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
aplicaie n practica schimbului valutar dintr-o banc.
Contribuia autorului const din
selectarea i organizarea materialului bibliografic,
analiza activitii de schimb valutar, cuprins n proiectul logic,
proiectul fizic realizat cu APPEX
manualul de utilizare
.

CUPRINS
Introducere........................................................................................................................................................................................I
Capitolul 1. Baze de date relaionale...............................................................................................................................................3
1.1. Abstractizarea datelor............................................................................................................................................................3
1.2 Independena datelor..............................................................................................................................................................3
1.3. Principalele componente ale unui SGBD..............................................................................................................................4
1.4. Modelul relaional.................................................................................................................................................................5
1.5.. Definirea sistemelor de gestiune a bazelor de date relaionale............................................................................................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 aplicaiei activitatea de schimb valutar ntr-o banc......................................................................11
3.l. Descrierea unitii economice la care se afl activitatea de schimb valutar........................................................................11
3.2. Cerinele utilizatorului.........................................................................................................................................................11
3.3 CREAREA MODELULUI CONCEPTUAL LOCAL, PENTRU VEDERILE UTILIZATORILOR..........................................12
3.3.1. Identificarea tipurilor de entiti..................................................................................................................................12
3.3.2 Identificarea tipurilor de relaii........................................................................................................................................12
3.3.3 Identificarea i asocierea atributelor la tipurile de entiti i tipurile de relaii.............................................................12
3.3.4. Determinarea domeniilor de definiie 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 relaiilor pentru modelul logic local................................................................................................................16
3.4.3. Validarea modelului, utiliznd normalizarea................................................................................................................16
3.4.4. Validarea modelului utiliznd tranzaciile....................................................................................................................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 spaiu 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 aplicaie..............................................................................................................................................................58
5.2. Introducerea clienilor.........................................................................................................................................................59
5.3. Introducerea cursului valutar...............................................................................................................................................60
5.4. Introducerea cumprrii de valut.......................................................................................................................................61
5.5. Introducerea vnzrii de valut...........................................................................................................................................65
5.6 Rapoarte...............................................................................................................................................................................68
5.6.1 Cursul zilnic..................................................................................................................................................................68
5.6.2 Clienii...........................................................................................................................................................................68
5.6.3 Clieni cu vnzri..........................................................................................................................................................72
5.6.4 Clieni cu cumprri......................................................................................................................................................73
Bibliografie....................................................................................................................................................................................75

II

Capitolul 1. Baze de date relaionale.

1.1. Abstractizarea datelor
Un scop important al unui sistem de gestiune a bazelor de date este s poat asigura o viziune
abstract asupra realitii. Este necesar s se rein, din mulimea vast de informaii, doar acele informaii
care sunt necesare unei anumite aplicaii.
Se poate face referire spre exemplu la ncercarea de modelare a unei aplicaii ntr-o intreprindere.
Trebuie modelate obiectele i relaiile dintre ele. Nu realitatea, complex n totalitatea ei, intr n
discuie 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 aplicaia n
cauz). Astfel n cazul modelarii obiectului (sau entitii) client, trebuie alese doar acele proprieti (sau
atribute) care intereseaz. Acestea ar putea fi, de exemplu: numele, actul de identitate, numrul,. O
mulime impresionant de informaii, 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 albatri, 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 structurrii informaiei, dup cum urmeaz:
- nivelul logic de vizualizare (view) sau nivelul extern. Este dat de viziunea programatorului de
aplicaii, care realizeaz programele de aplicaii pentru manipularea datelor la nivel de structur logic
(subschema) corespunzatoare descrierii datelor aplicaiei;
-nivelul conceptual (global). Este dat de viziunea administratorului bazei de date, care realizeaz
structura conceptuala (schema) corespunztoare descrierii ntregii baze de date i administreaz
componentele bazei de date. Acest nivel descrie ce date sunt memorate n baza de date i ce relaii sunt
stabilite ntre date. Nivelul conceptual reprezint:
- toate entitile, atributele lor i relaiile dintre ele;
- restriciile impuse datelor
- informaiile semantice despre date
- informaiile privitoare la securitatea i integritatea datelor.
-nivelul fizic. Este dat de viziunea inginerului de sistem care realizeaz structura fizic corespunztoare
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 indeci;
-descrierea nregistrrilor pentru memorare;
-plasarea nregistrrilor pe suport;
-tehnicile de compresie i de criptare a datelor.
1.2 Independena datelor
Un obiectiv major al arhitecturii pe trei nivele de abstractizare este realizarea independenei
datelor. O aplicaie, n general, este dependent de date n sensul c modificarea structurii de memorare a
datelor sau a strategiei de acces la date afecteaz i aplicaia. Independena datelor fa de aplicaie este
totui necesar cel puin din urmtoarele considerente:
-diferite aplicaii au nevoie de viziuni diferite asupra acelorai date;

-administratorul bazei de date trebuie s aib libertatea de a schimba structura de memorare sau strategia
de acces, ca rspuns la cerine (schimbi de standarde, prioritile aplicaiilor, unitile de memorare etc.),
fr a modifica aplicaiile existente, baza de date existent, precum i programele de exploatare a ei, care
au fost folosite o perioad de timp i care reprezint o investiie major la care nu trebuie s se renune
prea uor.

Figura 1.1. Arhitectura ANSI-SPARC pe trei nivele

De aceea, se impune ca atunci cand apar noi cerine n cadrul sistemului informaional, sistemele
informatice s poat funciona cu programele i procedurile existente, iar datele existente s poat fi
convertite.
Independena datelor trebuie privit din dou puncte de vedere: independena fizic i
independena logic a datelor.
Independena fizic a datelor face ca memorarea datelor i tehnicile fizice de memorarea s poat
fi modificate fr a determina rescrierea programelor de aplicaie.
1.3. Principalele componente ale unui SGBD
innd seama de faptul c exist diferite tipuri de sisteme de gestiune, care se difereniaz:
- prin limbajele utilizate,
- prin anumite componente ce imprim diferite faciliti 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 att n regim local ct i n regim de teleprelucrare, ajungem la concluzia c nu poate
fi stabilit o arhitectur unic, valabil pentru toate sistemele, ci apar particulariti de la un sistem
la altul.
Arhitectura unui SGBD evidentiaz componentele acestuia i urmeaz standarde internaionale. O astfel
de arhitectur general cuprinde urmtoarele componente:
- baza de date propriu-zis n care se memoreaz colecia 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 reglementrile administrative, destinate bunei
funcionari a ntregului sistem;
- un dicionar al bazei de date (metabaza de date), ce conine informaii despre date, structura
acestora, elemente de descriere a semanticii, statistici, documentaie etc.
- mijloacele hard utilizate (comune, specializate etc.);
- personalul implicat: (categorii de utilizatori: finali - (neinformaicieni); de specialitate
(administrator), analiti - programatori, gestionari, operatori).
Arhitectura bazei de date d o imagine despre modul general de organizare i funcionare 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 construcii
adecvate oricror necesiti de calcul, asemntoare cu structurile puse la dispoziie 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 funcii. Fiierul preprocesat este compilat, plasat ntr-un
modul obiect, link-editat cu o bibliotec n care se afl funciile nlocuite, furnizate o dat cu SGBD, i
este executat cnd este necesar.
1.4. Modelul relaional
n 1978 E.F.Codd, de la IBM Research Laboratory, a elaborat o lucrare care a avut o influen
covritoare n dezvoltarea bazelor de date. Lucrarea trata despre modelul de date relaional.
De aici ncolo s-au proiectat multe sisteme dintre care menionm System R dezvoltat la IBM's San
Jose Research Laboratory din California, la sfritul anilor '70. Acest proiect a dus la:
dezvoltarea unui limbaj structurat de interogare (numit SQL) care de atunci a devenit un standard
pentru sistemele relaionale;
producerea n anii '80 de sisteme comerciale arhicunoscute dintre care menionm: DB2, SQL Server,
SQL/DS de la IBM i ORACLE de la ORACLE Corporation.
Alte exemple de sisteme relaionale: INGRES de la Relaional Technology Inc., Informix de la
Informix Sofware Inc., Sybase de la Sybase Inc.. Dintre sitemele relaionale pentru microcalculatoare
enumerm 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 relaionale
ntr-o prim ncercare de definire, se poate considera un sistem de gestiune a bazelor de date
relaionale (SGBDR) ca reprezentnd un SGBD care utilizeaz drept concepie de organizare a datelor
modelul relaional. Astfel spus, un SGDBR reprezint un sistem care suport modelul relaional.
Definiia de mai sus este prea general pentru a putea fi operaional, deoareca modul de implemantare a
modelului relaional difer, de regul att ntre diferitele SGBDR, ct i n raport cu modelul teoretic,
cel definit n cadrul teoriei relaionale, datorit eforturilor productorilor de a realiza sisteme ct mai
perfomante care s satisfac cerinele i exagerrile utilizatorilor. Ct de aproape (sau de departe) de
modelul relaional teoretic trebuie s fie modelul datelor efectiv utilizat de SGBD pentru a putea afirma c
SGBD-ul respectiv utilizeaz sau nu modelul relaional, deci este sau nu SGBDR?
Diversitatea modelelor relaionale operaionale au determinat, n mod natural existana unei mari
5

diversitii de SGBDR, pentru a cror prezentare a fost necesar nuanarea terminologiei. Au aprut o
serie de sintagme precum: sisteme cu interfa relaional, sisteme pseudorelaionale, sisteme complet
relaionale.
Conceptele specifice organizriidatelor n fiiere, SGBDR i teoriei relaionale ntre care se pot
stabili analogii
Organizarea datelor n fiiere SGBDR
Teoria relaional
Fiier
Tabel
Relaie
Record(nregistrare)
Linie
Tuplu
Cmp
Coloan
Atribut
n general, conceptele utilizate la prezentarea SGBDR i a modelelor relaionale operaionale
difer de cele din cadrul teoriei relaionale. Figura de mai sus prezint comparativ conceptele organizrii
datelor n fiiere, concepte SGBDR i ale teoriei relaionale.
Faptul c se pot stabili analogii ntre conceptele organizrii datelor n fiiere i conceptele
relaionale, i-au determinat pe unii productori s prezinte sisteme fr nici o legtur cu modelul
relaional drept SGBDR, n scopul asigurrii 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 relaional.n acest sens, Codd a formulat 13 reguli care exprim cerinele pe
care trebuie s le prezinte un SGBD ca s fie relaional. Dei reguli au strnit 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 relaie
Sistemul trebuie s gestioneze baza de date numai prin mecanisme relaionale.Acest lucru
nseamn c sistemul trebuie s-i ndeplineasc toate funciile prin manipulri n care unitatea de
informaie s fie mulimea (relaia), adic s utilizeze limbaje, precum SQL, care s opereze la un moment
dat pe o ntreag relaie.Deci SGBD nu trebuie s accepte operaii non-relaionale care s ndeplineasc
operaiile de definire i manipulare a datelor.
Unele sisteme utilizeaz mecanisme releionale numai pentru o parte din funcii, n special pentru
interogare. Aceste sisteme se numesc sisteme cu interfa relaional i nu SGBDR.
R1: Regula privind reprezenterea logic a datelor
Toate datele din daza de date relaional 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 acelai mod. Informaiile privind numele de tabele,coloane, domenii, definiiile
tabelelor virtuale, restricii de integritate trebuie s fie memotare tot n tabele de date (cataloage).
Referina la 'nivelul logic' nseamn c construcia fizic nu este reprezentat i nu necesit explicaie.
R2: Regula privind garantarea accesului la date.
Orice dat din baza de date relaional trebuie s poat fi accesat prin specificarea numelui da
tabel, valorii cheii primare i numelui de coloan.Aceast regul exprim cerina 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
semnificaia unor date lips sau inaplicabile. Valorile null, care difer de irurile de caractere ' spaiu' sau
de irurile vide da caractere sunt deosebit de importante n implementarea restriciilor de integritate
(integritatea entitii i integritatea refereanial).
R4: Regula privind metadatele
Descrierea bazei de date trebuie s se prezinte la nivel logic n acalai mod cu descrierea datelor
propiu-zise, astfel nct utilizatorii autorizai s poat descrierii bazei de date aceleai operaii 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 informaiile de
sistem.

Sisteme nu trebuie s fac diferenieri n definirea i tratarea datelor ia metadatelor, utiliznd o

singur structur, i anume cea relaionala.
R5: Regula privind facilitaile limbajelor utilizate
Un sistem relaional trebuie s fac posibil utilizarea mai multor limbaje, n mai multe moduri.
Trebuie s existe ns cel puin un limbaj de nivel nalt ale crui instruciuni s poat exprima oricare din
urmtoarele operaii: definirea tabelelor de date, definirea tabelelor virtuale, manipularea datelor),
definirea restriciilor de integritate, autorizarea accesului, precizarea limitelor tranzaciilor.
A se nota aici c noul standard O/I pentru SQL furnizeaz toate aceste funcii, 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 inserrile, modificrile i tergerile n baza de date
Sistemul trebuie s ofere posibilitatea manipulrii unei tabele (da baz sau virtual) nunumai n
cadrul operaiilor de regsire, ci i n aciuni de inserare, modificare i tergere a datelor. Aceast regul
exprim cerina ca prin operaiile n care se schimb bazei da date s se lucreze la un moment dat pe o
ntreag relaie.
R8: Regula privind independena fizic a datelor
Programele de aplicaie nu trebuie s fie afectate de schimbrile efectuate n modul de
reprezentare a datelor sau n metodele de acces. O schimbare a structurii fizice a datelor nu trebuie s
blocheze funcionarea programelor de alpicaie.
R9: Regula privind independena logic a datelor
Programele de aplicaie nu trebuie s fie afectate de schimbrile efectuate asupra relaiilor bazei de
date, schimbri care conserv datele i care toeretic garanteaz valabilitatea programelor de apicaie
existente.
R10: Regula privind restriciile 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 aplicaie.
R11: Regula privind distribuirea geografic a datelor
Limbajul de manipulare a datelor utilizat de sistem trebuie s permit ca, n situaia n care datele
sunt distribuite, programele de aplicaie s fie logic aceleai 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
cnd 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 sczut) orientat pe prelucrare de recorduri
(tupuri) i nu pe prelucrarea mulimiilor (relaiilor), acest limbaj nu trebuie s fie utilizat pentru a se
evitarestriciile de integritate sau restriciile 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 fr cunoaterea utilizatorului sau a administratorului bazei de date.

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

2.1. Oracle
Oracle const dintr-un set complet de constructori de aplicaii i produse pentru utilizatori,cautnd
s asigure soluii complete n tehnologia informaiei.
Aplicatiile Oracle sunt portabile pe un numar mare de staii 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 informaiei utilizate de aplicaii.
Ultimul server Oracle, ORACLE 11g, utilizeaz o baz de date cu toate avantajele unei structuri
relaionale, avnd 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 aplicaii utiliznd tehnici de optimizare

adecvate

Securitatea bazelor de date i a taskurilor permise pentru anumii

utilizatori

Consistena i protecia datelor,incluznd arhivarea taskurilor i

mecanisme de cutare

Comunicarea i integritatea informaiilor,cnd bazele de date sunt

distribuite ntr-o reea.

2.2. APPEX
Oracle Application Express este un instrument de dezvoltare rapid a aplicaiilor web pentru baze
de date Oracle. Folosind doar un browser web i experien limitat n programare, se pot dezvolta
aplicaii profesionale care sunt att rapide ct i sigure. Datorit caracteristicilor predefinite, cum ar fi
teme de interfa, controalele de navigare, ageni de formular i rapoartele flexibile, Oracle Application
Express accelereaz procesul de dezvoltare al aplicaiei.
Din perspectiva utilizatorului final, aplicaiile desfurate 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 acelai. 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 ctre browser sub forma de cod HTML. Acest ciclu se petrece de
fiecare dat cand se cere sau se execut o pagin.
Sesiunea public a aplicaiei este gestionat n tabelele bazei de date din cadrul Oracle Application
Express. Nu folosete o conexiune de baze de date dedicat. n schimb, fiecare cerere este fcut printr-o
sesiune de baze de date separat, consumatoare de resurse minime de calculator.
Att Serverul HTTP Oracle, ct i Oracle Application Express Listener functioneaz ca ageni de
comunicare ntre serverul Web i obiectele Oracle Application Express din baza de date Oracle. Mai
exact, acestea mapeaz cereri de browser spre solicitri de proceduri de baze de date stocate peste o
conexiune SQL*Net. Urmtorul grafic ilustreaz arhitectura Oracle Application Express utiliznd
8

Serverul HTTP Oracle i mod_plsql.

Motorul Application Express face i proceseaz pagini. De asemenea, efectueaz urmtoarele

sarcini:

Gestionarea sesiunii de stat

Servicii de autentificare
Servicii de autorizare
Controlul fluxului de pagin
Validri de prelucrare
Zona n care se vor dezvolta aplicaii se numete spaiu de lucru. Un spaiu de lucru este o baz
de date virtual privat, care permite mai multor utilizatori s lucreze n cadrul aceleiai instalri Oracle
Application Express pstrnd n acelai timp private obiectele lor, datele i aplicaiile.
ntr-un mediu tipic de dezvoltare, se poate crea un singur spaiu de lucru pe care dezvoltatorii s-l
mpart. Oricum, se poate crea spaii de lucru dedicate pentru anumii dezvoltatori sau proiecte. Crearea
unui spaiu de lucru dedicat limiteaz accesul la obiectele spaiului de lucru numai pentru utilizatorii
asociai cu spaiul de lucru.
Urmtoarea ilustraie arat relaia dintre utilizatori i dezvoltatori, spaii de lucru i scheme de
baze de date.

Cnd se configureaz utilizatorii Application Express la o organizaie mare, se atribuie roluri i

privilegii utilizatorilor specifici. Rolurile din Oracle Application Express includ urmtoarele:
Administratorii spaiului de lucru sunt utilizatorii care realizeaz sarcini specifice de administrator
ntr-un spaiu de lucru, cum ar fi gestionarea conturilor de utilizator, monitorizarea activitii n spaiul de
9

lucru, precum i vizualizarea fielor nregistrate.

Dezvoltatorii sunt utilizatori care creeaz i editeaz aplicaii i modific obiectele bazei de date.
Dezvoltatorii pot avea propriul spaiu de lucru sau pot mpri un spaiu de lucru.
Utilizatorii finali nu au privilegii de dezvoltare. Utilizatorii finali se definesc pentru accesa aplicaii
care nu utilizeaz o schem extern de autentificare.
Administratorii instan sunt superutilizatori care gestioneaz o ntreag instan gzduit utiliznd
aplicaia Application Express Administration Services.

10

Capitolul 3. Proiectul logic al aplicaiei activitatea de schimb valutar ntr-o

banc.
3.l. Descrierea unitii economice la care se afl activitatea de schimb valutar
n banca studiat se desfoar activiti de vnzare/cumprare valut. Un operator va utiliza
aplicaia pentru a facilita calculul valorii pltite clientului conform cursului valutar/zi, precum i pentru
realizarea situaiilor finale, zilnice sau periodice.
Activitatea de schimb valutar poate cumpra n mod liber, fr limitri, contra lei, valut sub
form de numerar (bancnote i monede care nu sunt divizionare) i cecuri de cltorie, n oricare din
valutele cotate de Banca Naional a Romniei, de la rezideni i nerezideni, persoane fizice.
Att cursurile de vnzare ct i cele de cumprare pentru toate valutele i cecurile de cltorie
negociate vor fi afiate zilnic, la loc vizibil, la nceputul programului de lucru. Cursurile afiate mai pot
fi modificate n timpul zilei respective de lucru, n cadrul unei localiti, unitatea de schimb valutar va
practica, aceleai cursuri pentru toate punctele sale de schimb.
Cursurile afiate vor fi nscrise n listele de cursuri zilnice, semnate de persoanele mputernicite
de conducerea bncii i cu aplicarea tampilei punctului de schimb valutar. Listele de cursuri se vor
pstra ca documente justificative la punctele de schimb valutar respective.
Pentru operaiunile de schimb valutar se pot ncasa comisioane numai n lei, n afara marjei ntre
cursurile de cumprare i cele de vnzare. Comisioanele vor fi afiate zilnic, la nceputul programului de
lucru i nu mai pot fi modificate n timpul zilei de lucru.
Pentru fiecare tranzacie, punctele de schimb valutar vor ntocmi buletine de schimb tipizat.
Buletinele de schimb valutar vor fi emise, nregistrate, evideniate i utilizate ca documente cu
regim special, n care scop vor purta n mod obligatoriu antet, serie i numr de ordine imprimate.
Buletinele de schimb valutar se ntocmesc n dou exemplare, fiind obligatorie completarea lor cu
toate datele prevzute n formular. Pe buletinul de schimb valutar, la rubrica nr. l "Numele i
prenumele", se va trece numele titularului buletinului de identitate sau al paaportului individual.
Originalul buletinului de schimb valutar, datat, semnat i tampilat de punctul de schimb se
nmneaz clientului, iar exemplarul 2 se pstreaz ca document justificativ de cas.
n cazul unitilor de schimb valutar care au organizat operaiunile n sistem computerizat,
ntocmirea buletinelor de schimb valutar se poate face pe calculatorul electronic, cu condiia ns de a se
respecta ntocmai modelul de formular aprobat, inclusiv regimul special al acestuia, prin nscrierea
seriei i a numrului de ordine.
Se va ine un registru zilnic al tranzaciilor, indicnd cumprrile i vnzrile de valuta i cecuri de
cltorie, pe feluri de valute, precum i sumele n lei pltite i, respectiv, ncasate n cadrul acestor
operaiuni.
n vederea asigurrii supravegherii bancare asupra tranzaciilor, unitile de schimb valutar vor
avea n dotare tehnic de calcul adecvat pentru preluarea pe suport magnetic a operaiunilor efectuate
prin toate punctele de schimb valutar.
3.2. Cerinele utilizatorului
Evidena clienilor
Evidena cursului valutar / moned
Evidena tranzaciilor valutare
Tiprirea bonului fiscal n urma realizrii unei tranzacii
Afiarea unor situaii zilnice sau periodice privind totalul tranzaciilor
REGULILE UNITII
~ Nici o tranzacie nu se poate desfura fr detalii referitoare la clieni O tranzacie este fie de
cumprare valut fie de vnzare valut Orice tranzacie se finalizeaz cu tiprirea unui bon fiscal
11

DESCRIEREA DATELOR DE INTRARE

Actele de identitate (buletin, carte de identitate, paaport) ale clienilor
Cursul valutar introdus n fiecare zi
DESCRIEREA SITUAIILOR NECESARE
Bonul fiscal tiprit la fiecare tranzacie
Situaia zilnic a vnzrilor de valut
Situaia zilnic a cumprrilor de valut
Situaii periodice ale vnzrilor de valut
Situaii periodice ale cumprrilor de valut
Situaia vnzrilor i cumprrilor raportate la un client
Evoluia cursului afiat de ctre Banca Naionala Romn
3.3 CREAREA MODELULUI CONCEPTUAL LOCAL, PENTRU VEDERILE UTILIZATORILOR
Obiectivul urmrit 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, discutnd cu viitorii utilizatori ai bazei de date.
3.3.1. Identificarea tipurilor de entiti
n urma analizei listei documentelor de intrare i de ieire se contureaz urmtoarele tipuri de entiti:
Clieni - grupeaz datele clienilor firmei;
Curs valutar- memoreaz cursul valutar pe fiecare moned n fiecare zi;
Valut- memoreaz monezile cu care se realizeaz, tranzacii;
Cumprri cuprinde datele referitoare la cumprrile efectuate;
Vnzri - cuprinde datele referitoare la vnzrile efectuate;
Tranzacii- grupeaz datele tranzaciei valutare;
3.3.2 Identificarea tipurilor de relaii
Tip de entitate

Tip de relaie

Tip de entitate

Cardinalitate

CursVal

este referit n

Vnzri

1:N

CursVal

este referit n

Cumprri

1:N

Valut

este referit n

Curs

1:N

Clienti

efectueaz

Vnzri

1:N

Clienti

efectueaz

Cumprri

1:N

3.3.3 Identificarea i asocierea atributelor la tipurile de entiti i tipurile de relaii

Tip de entitate

Atribute

Descriere atribute

CLIENI

idClient

id-ul fiecrui 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

numrul 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 fiecrui curs, valoarea ce se ia din secven

nr_schimb

Numarul scimbarii zilnice

idValuta

id-ul fiecrui client, valoarea ce se ia din secven

dataCurs

data la care s-a nregistrat cursul

curs_cump

cursul de cumprare

curs_vnz

cursul de vnzare

curs_bnr

cursul afiat de BNR

idValuta

id-ul fiecrei valute, valoarea ce se ia din secven

idTranz

id-ul fiecrei tranzacie, val. ce se ia din secven

idCurs

id-ul fiecrui curs, valoarea ce se ia din secven

suma

suma n lei, reprezentnd contravaloarea valutei

idVanzare

id-ul fiecrei vnzri, valoarea ce se ia din secven

VALUTE

VNZRI

idClient
idCurs

id-ul fiecrui curs,

suma

suma n lei, reprezentnd contravaloarea vnzrii

idCumpar

id-ul fiecrei cumprri, val. ce se ia din secven

CUMPRRI

idClient
idCurs

id-ul fiecrui curs,

suma

suma n valut,

3.3.4. Determinarea domeniilor de definiie a atributelor

Domeniul atributului: Un set de valori ce se pot da acelui atribut.
Pentru a controla n totalitate domeniul atributelor, se pot evidenia urmtoarele:
setul de valori admisibile pentru un atribut
operaiile admisibile asupra unui atribut
ce atribute se pot compara cu atributul respectiv, n combinaiile cu alte atribute
mrimea i formatul cmpului 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 urmtoarele:
cheia candidat, care are un numr minimal de atribute
cheia candidat, care i va schimba cel mai rar valoarea
cheia candidat, care este cel mai puin probabil s sufere modificri n viitor
cheia candidat, care este compus din cele mai puine caractere (n cazul atributelor
de tip caracter)
cheia candidat, care este cel mai uor de folosit din punctul de vedere al
utilizatorului.
Clieni
Nume atribut
Tipul
Dimensiunea Reguii
idClient

secventa

Cheie primar

nume

varehar

40

tara

varchar

20

tip_ai

char

seria_ai

char

numar_ai

char

org_em_ai

varchar

40

data_em_ai

smalldatetime

CursVal
Nume atribut

Tipul

Dimensiunea

Reguli

idCurs

smallint

Cheie primar

nr_schimb

smallint

idValuta

smallint

dataCurs

smalldatetime

curs_cump

int

curs_vnz

int

curs_bnr

int

Valut
Nume atribut

Tipul

Dimensiunea

Reguli

idValuta

smallint

Cheie primar

CodValuta

varchar

denValuta

varchar

20

Vnzri
Nume atribut

Tipul

Dimensiunea

Reguli

idVanzare

int

Cheie primar

idClient

int

10

idCurs
suma

smallint

int

14

Cumprri
Nume atribut

Tipul

Dimensiunea

Reguli

idCumpar

int

Cheie primar

idClient

int

10

idCurs
suma

smallint

int

3.3.6. Desenarea diagramei entity-relationship

3.4. CREAREA I VALIDAREA MODELULUI LOGIC LOCAL

Obiectivul urmrit 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 tranzaciilor
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 relaiilor multe-la-multe
Dac n modelul de date apar relaii de tipul multe-la-multe (M:N), trebuie descompuse n dou
relaii unu-la-multe (l :M) prin adugarea unei noi entiti suplimentare.
Eliminarea relaiilor complexe
O relaie complex este o relaie ntre mai mult de dou tipuri de entiti. Dac n modelul
conceptual apar relaii complexe, acestea trebuie eliminate. Se pot elimina prin crearea unui nou tip de
entitate, care s fie n relaie de tipul l :M cu fiecare tip de entitate din relaia iniial, partea cu M a
relaiei fiind spre tipul de entitate nou creat.
Eliminarea relaiilor recursive
Relaiile recursive sunt nite relaii particulare, prin care un tip de entitate este n relaie cu el
nsui. Dac apare o astfel de relaie n modelul conceptual, ea trebuie eliminat. Eliminarea se poate
rezolva prin crearea unei noi entiti unde s se evidenieze fiecare entitate care este legat de entitatea din
tipul de entitate iniial. n acest caz vom avea o relaie de tipul l :M ntre tipul de entitate iniial i tipul de
entitate nou creat i o relaie de tipul 1:1 ntre tipul de entitate nou creat i tipul de entitate iniial.
Eliminarea relaiilor cu atribute
Dac n modelul conceptual avem relaii cu atribute, putem descompune aceast relaie,
15

identificnd un nou tip de entitate n care s nregistrm atributele necesare.

Reexaminarea relaiilor de tipul 1:1
n modelul conceptual putem avea entiti ntre care s avem relaie de tipul 1:1. Se poate ntmpla ca
aceste entiti s fie de fapt aceeai entitate cu nume diferite. Dac suntem n acest caz, unim cele dou
entiti, cheia primar devenind cheia primar al uneia dintre entiti.
Eliminarea relaiilor redundante
O relaie 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 relaiile redundante
nu sunt necesare. Decizia ca o relaie este redundant trebuie s fie precedat de o analiz amnunit a
relaiilor care compun cele dou drumuri dintre cele dou entiti, pentru c pot aprea situaii, cnd o
relaie 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 relaiilor pentru modelul logic local
Relaia pe care un tip de entitate o are cu alt tip de entitate este reprezentat prin mecanismul
cheie primar/cheie strin. Cheia strin pentru o entitate este reproducerea cheii primare altei entiti.
Pentru a decide entitile unde vom include copia cheii primare a altei entiti, trebuie nainte s
identificm entitile "printe" i "fiu". Entitile "printe" se refer la acele entiti ale cror chei primare
se vor copia n entitile "fiu".
Pentru descrierea relaiilor vom folosi un limbaj de definire a bazei de date (Database Definition
Language - DBDL). n acest limbaj, specificm prima dat numele entitii, urmat de atributele asociate
ntre paranteze. Dup aceea identificm cheia primar i toate cheile alternante, precum i/sau cheile
strine.
Clieni (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_vnz, Curs_bnr)
Cheie primar: IDCurs;
Cheie strin: IdValuta, se refer la Valute(IdValuta);
Valute (IdValuta, CodValuta, DenValuta)
Cheie primar: IdValuta;
Cumprri (IDCumpar,IdClient, IDCurs, Suma)
Cheie primar: IDCumpar;
Cheie strin: IDCurs, se refer la CursVal(IDCurs)
Cheie strin:IDClient se refer la Clienti(IDClient)
Vnzri (IDVnzare,IdClient, IDCurs, Suma) Cheie primar: ID Vnzare;
Cheie strin:IDCurs, se refer la CursVal(IDCurs);
Cheie strin:IDClient se refer la Clienti(IDClient)
3.4.3. Validarea modelului, utiliznd normalizarea
Normalizarea este procesul prin care se decide dac atributele pot sau nu s rmn mpreun.
Conceptul de baz a teoriei relaiilor este c atributele sunt grupate mpreun pentru c exist o relaie logic
ntre ele.
Proiectarea normalizat organizeaz datele n funcie de dependenele funcionale. Deci acest proces
este situat undeva ntre proiectarea conceptual i cea fizic. Proiectul logic nu este un proiect final. El ajut
proiectantul s neleag natura datelor n ntreprindere. Proiectul fizic poate fi diferit. Exist posibilitatea ca

16

unele tipuri de entiti s se denormalizeze. Totui 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 civa ani. Din aceast cauz, cteodat este mai convenabil
implementarea unei baze de date cu puin redundan, dect suportarea cheltuielilor pentru procedurile
adiionale.
Normalizarea produce o baz de date care va fi uor extensibil n viitor. Procesul de normalizare
include urmtoarele etape mari:
Forma Normal Unu (INF), eliminarea grupurilor repetitive;
Forma Normal Doi (2NF), eliminarea dependenelor pariale de cheia primar;
Forma Normal Trei (3NF), eliminarea dependenelor tranzitive de cheia primar;
Forma Normal Boyce-Codd (BCNF), eliminarea anomaliilor care au mai rmas.
Clieni (IDClient, Nume, Tara, Tip_ai, Serie_ai, Numar_ai, Org_em_ai, Data_em_ai)
Curs Val (IDCurs, IdValuta, DataCurs, Curs_cump, Curs_vnz, Curs_bnr)
Valute (IdValuta. CodValuta, DenValuta)
Cumprri (IDCumpar, IDTranz, IDCurs, Suma)
Vnzri flDVanzare, IDTranz, IDCurs, Suma)
n relaiile noastre nu exist grupuri repetitive deci relaiile sunt n Forma normal unu.
Forma Normal Doi
O relaie este n 2NF dac este n 1FN i fiecare atribut care nu aparine cheii primare este total
dependent de cheia primar. Relaiile la care cheia primar se compune dintr-un singur atribut, aa cum
sunt relaiile noastre sunt n Forma normal doi.
Forma Normal Trei
O relaie este n 3NF dac este n 2FN i nu exist nici un atribut care s nu aparin cheii primare
i care s fie tranzitiv dependent de cheia primar. n relaiile noastre nu exist dependene tranzitive de
cheie, deci relaiile se afl n Forma normal trei.
3.4.4. Validarea modelului utiliznd tranzaciile
n acest pas se valideaz baza de date prin verificarea tranzaciilor ce se cer de utilizator.
Lund n considerare tipurile de entiti, relaiile, cheile primare i strine, ncercm s rezolvm manual
cerinele utilizatorilor. Dac reuim s rezolvm fiecare tranzacie cerut, atunci nseamn c modelul
creat este valid. Dac nu putem rezolva o tranzacie, atunci este foarte posibil s fi omis un atribut, o
relaie, sau o entitate din modelul de date. Sunt necesare urmtoarele tranzacii:
I.
Clieni
T1 - Vizualizare clieni
Cheia primar a entitii clieni este IDClient. n cadrul acestei forme se pot vizualiza toi clienii
introdui n baza de date, adic clienii care au efectuat deja o tranzacie;
T2 - Cutare client
Prin tastarea numelui clientului cutat se verific caracter cu caracter potrivirea cu unul din numele
deja introduse; n cazul potrivirii exacte, n fereastra deschis va rmne doar numele clientului cutat,
n caz contrar clientul va trebui nregistrat;
T3 - Adugare client
In cazul n care clientul nu se gsete n baza de date acesta va fi introdus mpreun cu toate datele
necesare identificrii lui (nume, ar, tip act, serie act, numr 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 entitii este IdValuta. Din forma Valute se pot vizualiza toate valutele care se afl

17

n baza de date, observndu-se la fiecare codul scurt, format din trei litere precum i ntreaga denumire
pentru a putea fi recunoscute mai uor;
T6 Adugare valute
Dac este nevoie de o valut nou, care nu a fost introdus pn 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 nti 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 entitii este IDcurs. Din forma Curs se poate vizualiza cursul pentru toate
valutele care se afl n baza de date; acest curs este alctuit din cursul BNR, cursul de cumprare (cu
care casa de schimb valutar cumpr valuta de la clieni) i din cursul de vnzare (cu care casa de
schimb valutar vinde valuta clienilor).
TIO - Adugare curs
Acesta trebuie introdus n parte pentru fiecare valut, n cele trei cmpuri: curs BNR, curs
cumprare i curs vnzare.
TI l - Modificare curs
In cazul n care cursul este introdus greit, se va suprascrie noul curs.
T12 - tergere curs
Se caut cheia cursului pe care dorim s-l tergem. Dac exist se terge.
IV.
Cumprri
TI6 - Adugare cumprare
Cheia primar a entitii este IDCumpar. Se selecteaz codul valutei dorite, din cele existente n
baza de date, lng acesta fiind automat copiat cursul de cumprare.
TI7 - terge tranzacie de cumprare.
Se caut cheia tranzaciei de ters. Cnd aceasta este gsita se terge tranzacia.
V.
Vnzri
TI8 - Adugare vnzare
Cheia primar a entitii este IDVanzare. Se selecteaz codul valutei dorite, din cele existente n
baza de date, lng acesta fiind automat copiat cursul de vnzare.
TI9 - terge tranzacie de vnzare.
Se caut cheia tranzaciei de ters. Cnd aceasta este gsit se terge tranzacia.
3.4.5. Definirea regulilor de integritate a bazei de date
Regulile de integritate sunt importante pentru a proteja baza de date mpotriva posibilelor
inconsistene. Dac este necesar, putem produce un proiect fizic de baz de date, pentru a putea vedea mai
uor ce reguli sunt necesare.
Vom considera cinci tipuri de reguli de integritate:
necesitatea datelor,
reguli asupra domeniului atributelor,
integritatea entitilor,
integritatea referinelor,
regulile ntreprinderii.
1. Necesitatea datelor
Exist atribute care nu pot conine valoarea nul, ci trebuie s aib totdeauna o valoare. Aceste reguli
18

deja le-am identificat, cnd am documentat atributele n pasul 4.1.3.

2. Reguli asupra domeniului atributelor
Unele atribute au un domeniu de definiie bine definit. Aceste domenii trebuie respectate.
Domeniile de definiie au fost deja identificate cnd am documentat domeniile atributelor n pasul 4.1.4.
3. Integritatea entitilor
Cheia primar a entitilor nu poate lua valori nule pentru c i pierde rolul de identificator
unic. Aceste reguli au fost deja identificate, cnd am documentat cheile primare n pasul 3.1.5.
4. Integritatea referinelor
Cheia strin din tipul de entitate "fiu" face legtura cu o entitate din tipul de entitate "printe".
Deci, dac cheia strin conine o valoare, ea trebuie neaprat s se regseasc i n tipul de entitate
"printe".n general dac participarea tipului de entitate "fiu" este total, atunci nu putem avea valoare
nul n cheia strin. n caz contrar putem avea valoare nul.
Considerm urmtoarele cazuri:
Cazul 1: Inserarea unei entiti n tipul de entitate "fiu": Pentru a verifica integritatea referinei,
verificm dac atributele din componena cheii strine sunt vide, sau s existe entitate n tipul de
entitate "printe" care s aib valoare cheii primare egal cu valoare cheii strine.
Cazul 2: tergerea unei entiti din tipul de entitate "fiu" : tergerea unei entiti din tipul de entitate
"fiu" nu cauzeaz probleme cu privin la integritatea referinelor.
Cazul 3: Actualizarea cheii strine n tipul de entitate "fiu" : Acest caz este similar cazului 1.
Cazul 4: tergerea unei entiti din tipul de entitate "printe" : Dac se terge o entitate din tipul de entitate
"printe", integritatea referinelor se stric n cazul n care exist entiti n tipul de entitate "fiu", care se
refer la entitatea tears. Exist strategii severe de a rezolva integritatea referinelor:
FR ACIUNE
Neacceptarea tergerii unei entiti din tipul de entitate printe, dac acesta este
referit de o entitate din tipul de entitate fiu.
CASCAD
Dac o entitate din tipul de entitate printe este tears, se terg automat toate entitile
din tipurile de entiti fiu. Dac tipurile de entiti fiu au i ele la rndul lor alte tipuri de entiti fiu, se va
efectua tergerea n cascad n toate tipurile de entiti fiu, pn la ultimul nivel.
Cazul 5: Modificarea cheii primare n tipul de entitate printe : Dac se modific cheia primar din tipul
de entitate printe, integritatea referinelor se stric. Pentru meninerea integritii, se pot folosii toate
cazurile descrise mai sus, dar cel mai indicat este folosirea cazului FR ACIUNE.
Clieni
cheie primar: IDClient
CursVal
cheie primar: IDCurs - la modificare i la tergere : FR ACIUNE
cheie strin: IdValuta nenul, se refer la Valute
Valute
cheie primar: IdValuta
Vnzri
cheie primar: IDVnzare la modificare i la tergere : FR ACIUNE
cheie strin: IDClient nenul, referindu-se la Client
cheie strin:IdCurs nenul, referindu-se la CursVal.
Cumprri
cheie primar: IDCumpar - la modificare i la tergere : FR ACIUNE
cheie strin: IDClient nenul, referindu-se la Client
cheie strin:IdCurs nenul, referindu-se la CursVal.
3.4.6. Verificarea modelului logic local cu ajutorul utilizatorului.
Obiectivul urmrit 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 gsit
diferene).

19

Capitolul 4. Proiectarea fizic.

4.1. Cerere de spaiu 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
obine:

Dup accesarea link-ului de mai sus se urmeaz paii pentru a crea un nou workspace.

Se completeaz formularul cu NUME, PRENUME i EMAIL.

Apsnd butonul NEXT apare:

20

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

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

De ce ai cerut crearea acestui workspace(Exemplu: University Project, To learn Oracle) Apsai butonul
NEXT.

21

Dup definirea workspace-ului se primete de la oracle un email cu un link, dnd CLICK pe acel link,
workspace-ul va fi creat n apex i se primete 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 rnd tabelele n ordinea: clienti, valuta, cursVal, cumparari, vanzari. Pentru clienti obinem:

23

Pentru valuta obinem:

Pentru cursVal obinem:

24

Aici artm cum se stabilete cheia principal ca fiind cu valori date automat prin secven.

Dup CLIK pe NEXT adugm cheia strin:

Atenie!
Aciunea devine efectiv numai dup CLIK pe ADD.
La fel se introduce tabela cumparari cu dou chei strine: idcurs spre cursval i idclient spre clienti.

25

La fel se introduce tabela vanzari cu dou chei strine: idcurs spre cursval i idclient spre clienti.

Dac vrei s vedei fraza SQL se selecteaz SQL i apare:

26

Dac vrem s vedem cum arat legturile ntre tabele, de exemplu, de la tabela cursval, cu CLIK pe model
obinem:

Cu CLIK pe data obinem datele prezente n tabel:

27

Tot de aici se pot modifica datele (mai puin cheia) sau introduce linii noi n tabel.
Pentru a ncepe crearea aplicaiei CLICK pe Application Builder i se selecteaz Database Applications

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

Introducei numele bazei de date i apsai butonul NEXT

4.3. Formulare APPEX
Urmeaz s proiectm formularele.
Pe ecranul urmtor selectm Form, dm nume tabelei valuta i ADD Page

28

Similar pentru clienti

Similar pentru cursval:

29

i mai departe pentru cumparari:

n final pentru vanzari:

Dup adugarea tuturor tabelelor apsnd butonul NEXT apare:

30

Dup NEXT:, NEXT se alege Thema standard.

Din ecranul urmtor:

se alege Create Application i se obine:

31

Cu CLIK pe aplicaia schimb valutar se poate vedea ce conine, pentru moment, aceast aplicaie:

Pentru formulare avem nevoie s lum date din alte tabele. De exemplu cnd 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 aplicaia creat apare:

Dai CLICK pe numele tabelei cursval. Apare

32

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

De aici CLIK pe edit i obinem:

33

Selectm Popup List of Values,

Mai jos vei gsi List Of Values, Selectai Create Dynamic List of Values

Dai CLICK pe sgeata din dreptul Table or View

Apare:

34

De aici selectnd valuta:

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

Dup NEXT:

35

Se vede aici fraza Select n PLSQL. Dup Finish:

Apsai Apply Changes

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

4.5 Formular cu subformular
Pentru a vedea vnzrile ctre un anumit client vom crea o pagin:

Apoi:

36

Selectm form i dup NEXT:

Selectm Master Detail Form i:

De aici selectm tabela Clienti i:

37

Dup NEXT:

Selectm NO la Show Only Related Tables i apoi view-ul creat anterior Det_vanz:

Selectm cheile primare la tabelele legate i:

38

Aici facem legtura ntre master i detail:

Acum artm cum se va forma cheia:

i la detail. Apoi:

39

S le ordoneze dup nume. Apoi:

S fie pe aceeai pagin:

Apoi NEXT, NEXT i Create.
4.5. Rapoarte APPEX
Pentru a crea un raport, din ecranul urmtor

40

cu CLIK pe Create Page obinem:

Aici alegem Report i dup NEXT:

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

Dm numele paginii i al regiunii i NEXT.

Aici tot NEXT.

41

Trebuie s scriem acum fraza select pentru tabela care va fi originea raportului. Putem s scriem direct,
dar mai sigur c nu are greeli este s o crem prin Query Builder. Dup CLIK obinem:

Aici selectm tabela clienti i de acolo coloanele pe care vrem s le avem n raport.

Selectnd SQL vedem fraza SQL care trebuie scris n ecranul precedent. Selectm fraza i dup CLIK
dreapta:

42

Acum apare un ecran din are putem copia fraza select. Dup copy prsim acest ecran cu Ctrl+V ducem
fraza la locul ei.

Dup NEXT:

Aici trebuie s confirmm cererea i dup Create:

43

Suntem anunai c avem creat raportul. putem s-l rulm sau s-l editm. Dup Run Page:

Un alt exemplu interesant de raport este cel n care vrem s aflm cursul valutar al zilei curente.
Pentru asta crem mai nti un view din object Browser ca s putem lua i denumirea valutei din valuta.

Atenie!
Comparaia direct a datei cu data din server nu merge!
Am fcut, dup cum se vede, transformarea n caracter i apoi n data la ambele. Ca i mai nainte din:

44

Cu Create Page Report

Alegem acum clasic report i dup NEXT:

Dm aici numele i NEXT

Alegem aici numele view creat anterior.

Dup confirmare putem s dm Run i se obine:

45

Pentru crearea unui raport grafic din pagina:

dup CLIK pe Create Page:

alegem Chart i dup NEXT:

46

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

Completm, ca n figur, istoric euro i NEXT:

i iar NEXT pentru a ajunge la:

47

Completm Chart Title, denumirile care vor fi n query datacurs i curs_bnr i dup NEXT:

Cu Create crem raportul i dup Run va arta aa:

48

Dac vrem s crem un raport legat de o anumit pagin (de exemplu buletinul de vnzare pentru o
anumit tranzacie) atunci dup Create PageReportInteractive ReportNEXTNEXT..ajungem la:

Unde dup CLIK pe Query Builder:

49

Aici construim o cerere:

Dup CLIK pe SQL i selectare apare:

50

Copiem cu CLIK dreapta!!!!

i l ducem napoi

51

Facem aici modificri ca s calculeze suma n RON i se ia Idvanzare din pagina 33.

Efectele acestei modificri se vor vedea n manualul de utilizare.

4.5.

Crearea unui buton.

Din pagina aplicaiei selectm formularul cursval. Va apare:

52

La buttons selectm + care nseamn adugarea unui buton. Apare:

i dup NEXT:

NEXT din nou

53

Aici dm numele butonului i eticheta. Apoi NEXT:

Aici alegem aezarea butonului

i NEXT:

54

Alegem aciunea de redirectare la pagin. Dup NEXT:

Trebuie s alegem acum pagina ce conine formularul de introducere a valutelor:

Dup CLIK apare:

Dac tim numrul paginii putem s l scriem direct. Dup NEXT:

55

De aici numai avem dect s facem CLIK pe Create Button i se creeaz butonul.
4.6. Completare pagina de start
Pn acum am avut n pagina de start a aplicaiei (cea declanat cu run applicationn) doar
formularele. Vrem s apar acolo i rapoartele. Pentru aceasta din meniul aplicaiei:

selectm Home i apare:

56

De la List vom avea:

Fcnd CLIK pe Create List Entry obinem:

57

Aici trebuie s selectm pagina pe care o introducem n meniu. cu CLIK pe

obine :

De unde selectm raportul pe care vrem s l includem n meniu i apoi i dm eticheta:

58

se

Capitolul 5. Manual de utilizare.

5.1. Intrarea n aplicaie
Dup intrare n APPEX:

se d CLIK pe Application Builder:

De aici, dup Run pe aplicaia schimb valutar:

59

Acesta este meniul pe care l-am construit.

De aici se pot introduce datele prin formulare identificate cu cuvntul form.
5.2. Introducerea clienilor
Cu CLIK pe Clienti form:

Aici introducem datele clientului de exemplu:

60

Se selecteaz data din calendar i dup clic i Create putem alege din meniu alt opiune.
5.3. Introducerea cursului valutar
De exemplu Curs val form:

Dup CLIK:

61

De aici cu CLIK pe sgeata 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 activitii, ntr-o zi putem avea mai multe modificri ale cursului,
deci la Nr Schimb vom trece a cta modificare este.
5.4. Introducerea cumprrii de valut.
Din meniul aplicaiei se alege Cumparari form:

62

Dup CLIK obinem:

Pe sgeata de la idclient obinem:

De unde alegem clientul.

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

63

Pentru a stabili cursul facem CLIK pe Curs zilnic:

Prelum, de aici, idcurs i l scriem n formularul de la cumprri.

Cu CLICK dreapta obinem:

De aici, cu CLICK pe Back, revenim la formularul de cumprri unde trecem numrul de la

IDCURS:
La idcumpar se trece un numr nc nefolosit.

64

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 modificri sau, dac totul este n regul, putem edita buletinul de
65

cumprare cu CLICK pe butonul respectiv.

Revenind la HOME putem continua cu alte aciuni.

5.5. Introducerea vnzrii de valut.
Pentru a introduce o vnzare din meniul Home CLIK pe vanzari form:

Dup CLIK obinem:

Aici, ca i la cumprri, alegem cursul zilnic, clientul existent sau introducem un client nou.
66

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:

67

Selectnd, cu creionul, vnzarea 5 apare:

De aici cu CLIK pe Buletin De Vnzare:

Aici se vede cum acioneaz un fomular cu raport i un raport legat de acea pagin.

68

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

5.6.2 Clienii.
Din meniul HOME selectm Clienti rap inter i apare:

Putem sorta clienii dup nume .

69

Dup Apply obinem:

70

Putem s grupm clienii dup diverse criterii, de exemplu dup ar:

Dup CLICK:

71

Selectm Coloana Tara i dup CLICK:

De aici CLICK pe iconi i avem:

72

5.6.3 Clieni cu vnzri.

Dac vrem s vedem ce vnzri de valut a fcut un anumit client CLICK pe Clienti cu vnzri :

De aici selectm de la creion clientul care ne intereseaz i dup CLICK:

73

Se vd vnzrile.
5.6.4 Clieni cu cumprri.
Analog se pot vedea cumprrile fcute de un client. Din meniul HOME KLICK pe Clienti cu
cumprri :

De aici CLICK pe creionul din dreptul clientului cutat:

74

Aici se vd cumprrile.

75

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 Braov, 2003
[4] Iacob P., Access la purttor, Editura Lux Libris, 2007

76