Conceptul de baz de date

Componenta de baz a unui fiier este un element( data item), care este cea mai mic
parte fiind numit unitate de dat. Un grup de elemente luate ca o unitate ntr-o aplicaie se
numete o nregistrare. Un fiier este o colecie de mai multe nregistrri de un singur tip.
Sistemul de baz de date s-a construit pe urma acestor definiii, astfel un element dintr-o baz de
date relaional a devenit o coloan sau un atribut, o nregistrare s-a transformat ntr-un rnd, iar
un fiier ntr-un tabel.
O baz de date poate fi definita ca fiind o colecie de informaii centralizate creat i
meninut computerizat n scopul prelucrarii datelor n contextul unui set de aplicaii.Prelucrarea
datelor se refer la operaiile de introducere,tergere,actualizare i interogare a datelor.
O baz de date reprezint o colecie de date de urmtoarele dou tipuri:
Mulime de date aflate n interdependen,memorate n diferite fiiere;
Diferite tabele (fiiere,dicionare,containere) de descriere a datelor
memorate in baza de date.[TL02]
Arhitectura bazelor de date
Arhitectura intern a bazelor de date a fost propus in anul 1975 prin standardul
ANSI/X3/SPARC i contine trei nivele funcionale:
1. Nivelul intern(baza de date fizica);
2. Nivelul conceptual;
3. Nivelul extern;
Obiectivul arhitecturii cu trei nivele este separarea vederii fiecrui utilizator asupra bazei de date
de modul n care este ea reprezentat fizic.

1.Nivelul intern descrie cum sunt stocate datele n baza de date,reprezentarea fizic pe
calculator.La acest nivel se aloc spaiu de stocare pentru date si indexuri,se descriu nregistrrile
pentru stocare,tehnicile de comprimare a datelor si de codificarea lor.
2.Nivelul conceptual este o vedere general a bazei de date care prezinta ce date sunt
stocate in baza de date si relaiile dintre acestea.Conine structura logica a bazei de date,aa cum
e vazut ea de administrator.Nivelul conceptual reprezint toate entitaiile,atributele si relaiile
dintre ele,constrngeri asupra datelor,informaii privind securitatea i integritatea datelor.
3.Nivelul extern reprezint vederea utilizatorului asupra bazei de date. Utilizatorii au
acces doar la prile bine definite din baza de date, fiindu-le ascunse prile care nu
intereseaz.Prin modelul extern se realizeaz independena logic a datelor.

Clasificarea bazelor de date

1.Clasificarea dup numrul de utilizatori

Se imparte in doua categorii:
Monoutilizator baze de date foarte mici,implementate pentru uzul personal sau
al unui grup restrns de persoane.Suport accesul unui singur
utilizator la un moment dat;
Multiutilizator permit accesul in acelai timp a mai multor utilizatori la aceeai
baz de date.Necesita msuri speciale de protecie a datelor
att prin limitarea accesului la informaii cat i pentru eliminarea
inconsistenelor logice.

2.Clasificarea dup numrul de staii pe care este stocat baza de date

Exista doua categorii de sisteme de baze de date:
Centralizate datele i sistemul de gestiune sunt stocate pe un singur calculator
Distribuite datele i sistemul de gestiune sunt distribuite pe mai multe
calculatoare interconectate printr-o reea de comunicaii.

3.Clasificarea dup modelul de date

Modelul de date este o colecie integrat de concepte necesare descrierii datelor, relaiilor
dintre date i constrngerilor impuse datelor. Dicionarul Webster definete un model ca fiind o
descriere sau o analogie care vizualizeaz ceva ce nu poate fi observat direct.[pdf1]
Exista cinci modele prezentate n ordine cronologic: ierarhic, retea , relaional , entitate
relaie si orientat obiect.Se va observa ct de mult au evoluat conceptul i structura bazelor de
date de la un model la altul.

1.Modelul ierarhic

Modelul ierarhic a fost creat prin anii 1960 de americanul Rockwell mpreun cu IBM
care au dezvoltat un software GUAM (Generalized Update Acces Method) ceea ce a dus la
apariia IMS (Information Management System). IMS a devenit cea mai important baz de date
ierarhic din lume din anii 1970-1980.
Modelul se reprezint printr-o structur ierarhic, precum o pdure (mulime de arbori)
unde toate legaturile sunt de la rdcin la nodul fiu din relaie si toate relaiile sunt de tipul
1:n . Se remarc apariia cmpului cheie numit i cheie primar care face legtura ntr-o
nregistrare dintr-un tabel de baz cu mai multe nregistrri dintr-un tabel corespondent.
Dei n zilele noastre modelul ierarhic l ntlnim foarte rar n aplicaii acesta a pus
bazele pentru dezvoltarea celorlalte modele.Principalele avantaje ale lui sunt:

simplicitatea conceptual;se poate vizualiza foarte uor conceptul bazei de date;
securitatea bazei de date prevazut si aplicat de DBMS;
independena datei; DBMS creaza un mediu n care independena datei poate fi
meninut, astfel scznd n mod substanial efortul de programare i de meninere a unui
program;
integritatea bazei de date; reiese din faptul ca ntotdeauna exista o legatura ntre relaiile
parinte/copil;
eficiena; modelul ierarhic este foarte eficient cnd o baz de date conine un volum mare
de date n relatii 1:m si utilizatorii necesita un numr mare de tranzacii care folosesc date
avnd relaii fixate n timp;
Popularitatea acestui model a sczut destul de mult din cauza unor motive serioase precum:
implementare complexa;necesita cunotine detaliate despre caracteristicile de stocare
fizica a datelor;
dificil de gestionat; orice schimbare n baza de date,precum realocarea segmentelor,
necesita modificri n toate programele de aplicaii care acceseaza baza de date;
lipsa independenei structurale;modificrile n structura bazei de date pot conduce la
probleme aplicaiile care funcionau corect nainte ca modificrile sa fie fcute;
limitarea implementarii;multe relaii nu se conformeaz la relaia standard 1:m cerut de
modelul ierarhic;

2.Modelul reea

Modelul reea a fost creat pentru a reprezenta relaiile dintre date mult mai eficient dect
modelul ierarhic,pentru a impune o baz de date standard i a mbuntii performana
ei.Apariia acestui model a fost n anul 1975 iniiat de SPARC (ANSI Standards Planning and
Requirements Committee).
Modelul reea folosete o structur de graf pentru definirea schemei conceptuale a bazei
de date;nodurile graflui sunt tipuri de entiti,iar muchiile reprezint asocierile dintre tipurile de
entiti.Acest model a motenit multe din avantajele modelului ierarhic avand ns si
mbuntiri majore:
apariia relaiilor m:n care sunt mult mai uor de implementat la acest model dect n cel
ierarhic;
flexibilitatea accesului la date;o aplicaie poate sa acceseze nregistrrile sale i a
celorlali membrii ntr-un set;
conformitate cu standardele;includerea DDL si a DML n standardele bazelor de date
facilitez administrarea i portabilitatea lor;
Dei modelul reea cuprinde avantaje semnificative fa de cel ierarhic exist si cteva
dezavantaje precum:
complexitatea sistemului;controlul integritii bazei de date i eficiena cu care
modelul relaional gestioneaz relaiile sunt cteodat ntrerupte de
complexitatea sistemului.Modelul prevede un mediu de acces navigaional al
datelor,n care sunt accesate doar cte o nregistrare la un moment dat;
lipsa independenei structurale;

3.Modelul relaional

Modelul relaional dezvoltat de E.F.Codd(de compania IBM) n anul 1970 a reprezentat
o descoperire major att pentru utilizatori ct i pentru designeri.Acest model a produs o
transmisie automat a bazelor de date pentru a nlocui transmisia standard . Simplicitatea
conceptului a stabilit o revoluie a bazelor de date.
Modelul se bazeaz pe o reprezentare uor de neles, ce const dintr-un tabel
bidimensional compus din linii i coloane.Fiecare linie din tabel reprezint o entitate i este
compus din mulimea valorilor atributelor entitii respective i fiecare atribut corespunznd
unei coloane din tabel. Fa de primele dou modele cel relaional a reuit s surprind prin:
independena structural;acest model neutiliznd un sistem de accesat datele
navigaional;
mbuntirea simplicitii conceptului;accentul punndu-se pe percepia uman de
stocare a datelor i nu pe modul dificil de neles n care calculatorul vede datele;
uurina proiectrii, implementrii i a folosirii bazei de date;
apariia unui limbaj de programare recunoscut i acceptat, limbajul SQL (Structured
Query Language) care este folosit i n zilele noastre;
un sistem de management a bazei de date mult mai puternic;
Principalele dezavantaje ale modelului relaional sunt:
sisteme software suprasolicitate;necesitatea unor calculatoare mult mai performante
doarece s-a observat c bazele de date relaionale sunt mult mai lente ca celelalte;
faciliteaz o implementare si un design saracacios; tocmai pentru c sunt foarte
simplu de utilizat pesoanele nespecializate pot s genereze cu uurin rapoarte i
interogri fr s se gndeasc prea mult c este nevoie de proiectarea unei baze de date;



4.Modelul Entitate-Relaie

Modelul Entitate-Relaie (ER) a fost prezentat de Peter Chien n lucrarea The Entity-
RelationShip Model: Toward a Unified View Data publicat n ACM Transactions on
Systems n martie 1976. ER reprezint i la ora actual cel mai utilizat model n modelarea
conceptual a bazelor de date.
Modelul se caracterizeaz printr-o reprezentare grafic a entitiilor i a relaiilor dintre
ele.Entitiile se scriu la singular cu litere mari i fiecare rnd dintr-un tabel este cunoscut sub
numele de instan a entitii.ntre dou entiti se pot asocia una din cele trei relaii posibile
1:M(one-to-many), 1:1 (one-to-one), M:N (many-to-many).Apariia diagramelor este unul dintre
avanatajele majore ale modelului entitate-relatie,dar pe lng acesta se pot identifica i
urmtoarele mbuntiri:
reprezentare vizual;
instrumente de comunicare eficiente;ER permite designului bazei de date s capteze
vederi diferite ale programatorilor,managerilor,utilizatorilor asupra datelor ntr-o baz de
date;
integrat cu modelul de date relaional;aceast integrare ajut baza de date sa aib un
proces bine structurat;
simplicitate conceptual excepional;
n ciuda faptului c modelul ER este cel mai utilizat model, designerii bazelor de date au cteva
rezervri n privina lui precum:
reprezentarea constrngerilor limitat;
reprezentarea relaiilor limitat;se pot reprezenta doar relaiile ntre entiti nu i
relaiile dintre atribute cu entitiile;
nu exist un limbaj manipulat al datelor;

5.Modelul orientat obiect

Primul model aprut de acest gen a fost modelul semantic (SDM), descoperit de
M.Hammer i D.McLeod publicat n Database Description with SDM: A Semantic Database
Model(ACM Transactions on Database Systems :3) 1981.Modelul este aplicabil n
programare,n proiectarea hardware,a interfeelor,a bazelor de date.
Modelul orientat obiect se caracterizeaza prin abstractizare,motenire, ncapsulare i
modularizare.Programele sunt organizate ca i colecii de obiecte, fiecare obiect fiind o instan a
unei clase.Fiecare clas reprezint abstractizarea unei entiti, iar clasele sunt membre ale unei
ierarhii de clase corelate ntre ele prin relaii de motenire.Modelul OO prezinta avantaje
importante fa de cel ER:
adugare de coninut semantic;
prezentarea vizual include coninut semantic;
integritatea bazelor de date;
date structurale,ct i independente;
Dei a avut mbuntiri impresionante modelul OO nu a reuit s l depeasc pe cel relaional
din mai multe motive:
ritmul lent de dezvoltare a standardelor OODM;
un acces navigaional la date complex;
dei complexitatea sistemului e mult mai mare ca i la modelul relaional,tranzaciile se
desfooar mult prea lent;
o lips de ptrundere pe pia;

Sistemul de gestiune a bazelor de date

SGBD reprezint un pachet de programare care permite crearea, utilizarea i eliminarea
obiectelor ce compun baza de date, n scopul creterii randamentului global alutilizatorului bazei
de date i avnd ca principalul obiectiv reducerea dependenei aplicaiilor n raport cu structura
datelor. [TL02]
Un sistem de gestiune a bazei de date( SGBD,DBMS-Database Management System )
este un produs software furnizat de productorul bazei de date. Produse software precum
Microsoft Access, Microsoft Sql Server, Oracle Database, Sybase, DB2, INGRES, MySql,
PostgreSql fac parte din categoria DBMS.
Un DBMS realizeaz o gam larg de funcii importante care garanteaz integritatea i
consistena datelor ntr-o baz de date.Majoritatea acestor funcii nu sunt vizibile pentru
utilizatori i pot fi obinute doar prin utilizarea DBMS-ului:
1. gestiunea dicionarului de date; DBMS-ul stocheaz datele i relaiile dintre ele ntr-un
dicionar de date.DBMS utilizeaz acest dicionar pentru a ascunde utilizatorului
detaliile privind implementarea fizic intern ( organizarea fiierelor i structurile de
stocare ).n plus orice modificri fcute n structura bazei de date sunt nregistrate
automat n dicionarul de date;
2. gestionarea stocrii datelor; Un DBMS modern permite pe lng stocarea datelor i
stocarea regulilor de validare a datelor, definiii de rapoarte, codul procedural, structuri
care se ocup de video i de formatul pozelor,etc.
3. transformarea i prezentarea datelor;DBMS ne scutete de corvoada de a face o
distincie ntre formatul logic i cel fizic al datelor;Pentru a menine independena
datelor, DBMS transforma cererile logice ale utilizatorilor n comenzii care localizeaza
fizic i regsesc datele solicitate.
4. servicii de securitate; Un SGBD creaz un sistem de securitate care ntrete securitatea
utilizatorilor i confidenialitatea datelor.Regulie de securitate determin care utilizatori
pot s acceseze baza de date, ce date pot s acceseze fiecare utilizator i ce operaii
(citire, adugare, tergere i modificare) pot s realizeze asupra datelor.
5. Controlul accesului multiutilizatorilor; SGBD utilizeaz algoritmi complexi pentru a
permite utilizatorilor accesul concurent la baza de date, fr a compromite integritatea i
consistena datelor.
6. Servicii de integritate; SGBD-ul promoveaz regulile de integritate pentru a reduce
redundana datelor. Integritatea se refer la corectitudinea i coerena datelor stocate.
7. Limbajul bazelor de date; SGBD-ul furnizeaz accesul datelor la un query language
,adic un limbaj neprocedural care permite utilizatorului s specifice ce trebuie fcut,
fr s spun i cum trebuie fcut.
8. Backup i servicii de recuperare;se ofer mijloace speciale care permit DBA-ului s
restocheze proceduri n cazul n care apar probleme.
9. Comunicarea bazelor de date cu interfeele;astfel se feciliteaz legtura ntre utilizatori
i sistemul de baze de date.Exist mai multe tipuri de interfee,precum cele bazate pe
meniuri sau pe forme, interfee grafice, etc.

Limbajele bazelor de date

Limbajele bazelor de date sunt mprite n doua categorii: limbaje de definire a datelor(
DDL) i cele de manipulare a datelor (DML). Aceste limbaje sunt numite sublimbaje de date
deoarece ele nu includ construcii pentru toate necesitiile de calcul cum sunt cele asigurate de
limbajele la nivel nalt.
DDL este un limbaj descriptiv, care permite administratorului sau utilizatorului s descrie
i s denumeasc entitiile cerute de aplicaie i relaiile care pot s existe ntre diferitele entiti.
Rezultatul compilrii instruciunilor DDL este un set de tabele stocate n dicionarul de date al
SGBD-ului.
DML asigur un set de procedee ce permit relaiile de baz pentru manipularea
datelor:inserarea,modificarea,tergerea i regsirea datelor. Limbajele DMl pot fi de dou
tipuri:procedurale( specific modul cum trebuie s fie obinut rezultatul unei instruciuni DML)
i neprocedurale( descriu numai ce rezultat trebuie obinut).

Cap 2.Specificarea i proiectarea unei baze de date

Bazele de date relaionale au evoluat de la art la tiin care a fost parial implementat
ca i un set de design soft-uri ajuttoare. Multe dintre aceste design-uri ajuttoare ofer o
capacitate interactiv de modelare utiliznd o abordare simplist de structurare a datelor.
Ciclul de via a unei baze de date ncorporeaz paii de baz implicai n proiectarea
schemei globale a bazei de date logice. Odat ce proiectarea este complet se continu cu
implementarea i meninerea bazei de date.
Principalele etape n specificarea i proiectarea unei bazei de date sunt:

1.Analiza cerinelor
Cerinele bazei de date sunt determinate pe baza interviurilor att cu productorii ct i cu
utilizatorii, pentru stabilirea obiectivelor aplicaiei informatice. Cu informaiile obinute astfel se
formeaz o documentaie care va include toate datele necesare pentru proiectarea bazei de date,
etapele proiectrii,ct i platforma software pentru implementarea bazei de date. Obiectivele
principale ale analizrii cerinelor sunt:
Pentru a descrie informaiile despre elementele datelor i relaiile dintre ele necesare
pentru modelarea cerinelor;
Pentru a determina tipurile de tranzacii care se intenioneaz a fi exeutate de baza de date
i interaciunea dintre tranzacii i elementele datelor;
Pentru a defini performana, integritatea, securitatea sau constrngerile administrative ce
trebuie impuse n baza de date;
Pentru a specifica design-ul i constrngerile implementrii, precum componentele
hardware i software, limbajele de programare sau interfeele externe;
Elementele datelor pot fi definite ntr-un sistem de dicionar de date, prevzut ca i o
parte integral a sistemului de management a bazei de date;


2.Design-ul logic
Schema global reprezentat de obicei printr-o diagram care cuprinde toate datele i
relaiile dintre ele, este dezvoltat utiliznd tehnici precum modelul Entitate-Relaie(ER) sau
UML. Modelul de date construit trebuie transformat n tabele. Pai n aceast etap sunt:
Modelarea conceptual a datelor
Vederea integral
Transformarea modelului conceptual de date n tabele SQL
Normalizarea tabelelor

3.Design-ul fizic
Design-ul fizic implic selecia de indeci(metode de acces), partiionarea i gruparea
datelor. Scopul principal al acestei etape este de a optimiza performana.
Ca parte a design-ului fizic, schema global poate fi rafinat uneori n moduri limitate pentru a
reflecta cerinele de procesare(tranzacii i queri-uri) ,dac exist avantaje mari ce pot fi fcute
n domeniul eficienei. Acest proces se numete denormalizare i const n selectarea proceselor
dominante cu un volum mare, definind extensii simple ntre tabele pentru a mbuntii
performana query-urilor, evalund costul total pentru query-uri, update-uri, stocrile de date i
lund n considerare efectele secundare care pot duce la pierderea integritii.



Modelarea conceptual a datelor

Modelarea conceptual a datelor este baza design-ului logic al bazei de date, accentul
major fiind pe simplicitate i lizibilitate. Scopul schemei conceptuale a design-ului, create de
obicei cu modelul ER i UML, este de a reda datele i cerinele ntr-un mod ct mai simplu i
mai uor de neles att de designer-ul bazei de date ct i de administratorul ei. Administratorul
este persoana responsabil pentru accesul la baza de date i pentru executarea query-urilor i a
update-urilor prin utilizarea unui SGBD .

UML(The Unified Modeling Language)

UML a fost introdus n 1970 de Grady Booch i James Rumbaugh i a devenit un limbaj
grafic standard pentru specificarea i documentarea sistemelor software. Exist mai multe tipuri
de diagrame UML, fiecare dintre ele avnd un rol bine definit:
Diagrama cazurilor de utilizare- prezint funciile sistemului din punct de vedere al
utilizatorului;
Diagrama de clasa- prezint structura clasic n termeni de clase i asocieri(relaii);
Diagrama de colaborare- include reprezentri spaiale ale obiectelor,legturilor i
interaciunilor;
Diagrama de secven- prezint temporal obiectele i interaciunile lor;
Diagrama de componente- prezint componentele fizice ale unei aplicaii;
Diagrama de construcie- prezint construcia componentelor pe dispozitivele hardware;
Diagrama de stri tranzitive- descrie comportamentul unei clase n termeni de stri;
Diagrama de obiecte- prezint obiectele i relaiile lor, fiind nite diagrame de
colaborare simplificate, fr reprezentarea mesajelor trimise ntre obiecte;
Diagrama de activiti- reprezint comportamentul unei operaii n termeni de aciuni;

Diagrama cazurilor de utilizare reflect modul static de vizualizre a cazurilor de utilizare
asupra sistemului,dar i modul de organizare i de modelare a comportamentului unui sistem.
Prezint actorii externi, cazurile de utilizare identificate numai din punct de vedere al actorilor(
comportamentul sistemului, aa cum e perceput de utilizatori), nu i din interior, precum i
relaiile dintre actori i cazurile de utilizare. Un actor poate fi orice sau oricine interacioneaz cu
sistemul. Actorul are un rol n cadrul sistemului, nu este un utilizator individual al acestuia, i din
acest motiv, el este o entitate, nu o instan. Un caz de utilizare este iniiat mereu de un actor i
furnizeaz o valuare actorului.
Un exemplu de diagram a cazurilor de utilizare este dat n Fig. Pentru viramentul prin
serviciul Internet:

Diagrama de clas i cea de activitate sunt de obicei utilizate pentru a discuta despre
problemele legate de design-ul bazei de date. Diagrama de clas captureaz aspectele
structurale gasite n schema bazei de date, iar cea de activitate faciliteaz procesul dinamic
implicat n design-ul bazei de date. Diagramele de clas UML i modelele ER sunt
asemntoare att n forma, ct i semantic.
O clas este un descriptor pentru un set de obiecte care au atribute i operaii. O clas
este reprezentat n diagram ca fiind un tabel, unde atributele formeaz coloanele din tabel, iar
randurile sunt alctuite din obiectele clasei respective. Diferena principal ntre o clas i o
entitate este lipsa operaiilor din entitate.
Relaiile care pot aprea ntre entitiile dintr-o diagram de clas sunt:
1. Asocierea- este o relaie generic ntre dou clase;poate fi e mai multe tipuri( 1:1, 1:M,
M:M);
2. Motenirea- relaie care indic faptul c o clas motenete caracteristicile unei clase
printe;
3. Dependen- se folosete atunci cnd o clas depinde de o alt clas, n sensul c
utilizeaz acea clas ca i atribut al su;
4. Agregare- indic o relaie de tip ntreg-parte( se poate spune despre clasa printe c are
clase de tip copil). n aceast relaie, clasa copil poate exista i fr clasa printe;
5. Compoziie- aceast relaie deriv din agregare, dar se utilizeaz cnd o clas copil nu
poate exista dect n cazul existenei clasei printe.
Diagrama de activitate UML este utilizat n specificarea activitiilor i a fluxului de
control ntr-un process. Este organizat pe baz de partiii care despart activitiile n subseturi.
Fiecare subset este numit i anexat cu linii.
Elementele ce compun o diagram de clas sunt:
Noduri- iniial( punctul de plecare ntr-o activitate, este unic i ntotdeauna pornete o
singur tranzacie din el), final( punctul de ieire dintr-o activitate, pot fi mai multe) i
nodul de activitate( aciuni ale unui obiect);
Puncte de decizii- unde se fac alegeri pentru o anumit ramur a unui flux;
Bar de sincronizare- folosit n cazurile n care anumite aciuni se pot desfura n
paralel; poate avea loc fie separarea fluxurilor, fie reuniunea lor dup o separare
anterioar;
Culoar( swimline)- permit separarea activitilor din flux dup criteriul responsabilitii
realizrii activitii;
Tranziii- reprezin trecerea de la o aciune la alta;
Condiii- sunt un tip special de tranziii, utilizate la fiecare dintre ieirile posibile dintr-o
decizie;



Vederea integral

O parte critic a procesului de proiectare a bazei de date este integrarea vederilor a
diferii utilizatori ntr-una singur, o schem global non-redundant. Vederile
administratorului sunt reprezentate de modelele conceptuale de date, i schema conceptual
integrat reiese din analiza analiza vederi administratorului n rezolvarea tuturor diferenelor n
terminologie i perspectiv.
Diveristatea ntr-o schem poate aprea cnd diferii utilizatori sau grupuri de utilizatori
i dezvolt o perspectiv individual ce trebuie reprezentat n baza de date. De exemplu un
utilizator poate vedea un proiect n ceea ce privete obiectivele sale i progresul pe care l poate
face n timp pentru a ajunge la obiectivele respective, pe cnd un alt utilizator poate vedea un
proiect n ceea ce privete resursele pe care le necesit i a personalului implicat. Aceste difene
pot cauza la incompatibilitatea dintre relaii i terminologii ntre modelele conceptuale.
Sunt necesari trei pai n crearea unei scheme conceptuale integrat:
Pasul 1: Comparaii ntre scheme i identificarea conflictelor
Conflictele care apar ntr-o schem sunt legate de:
Denumiri- sinonime i omonime; Sinonimele apar atunci cnd pentru acelai concept se
dau nume diferite. Acest conflict se poate detecta consultnd dicionarul de date al bazei
de date, n cazul n care s-a stabilit unul. Omonimele apar n momentul n care aceleai
denumiri sunt utilizate pentru concepte diferite. Pot fi detectate scannd scheme diferite
i cutnd cuvintele cu denumiri asemntoare.
Cheile entitiilor- apar atunci cnd chei diferite sunt asociate aceleai entiti, n vederi
diferite. Spre exemplu dac avem o entitate angajat(nume, id, nr_sec) i toate cele trei
atribute ale angajatului sunt desemnate ca i chei apare acest conflict i trebuie modificate
cheile pentru a menine consistena;
Dependene- conflictul apare cnd utilizatorii specific nivele diferite de conectivitate (
one-to-many, etc) pentru aceleai concepte. Pentru evitarea acestui tip de conflict este
bine s se schimbe numele entitiilor pentru ca fiecare tip de conectivitate s aib un set
cu nume diferite de entiti;

Pasul 2: Rezolvarea conflictelor i conformitate ntre scheme
Scopul acestui pas este de a alinia toate schemele i de a le face compatibile pentru
integrare. Unele entiti i atributele cheie pot avea nevoie de redenumiri, conversii pentru a
obine unicitatea conceptelor. Relaiile cu acelai grad, rol i constrngeri de conectivitate
similare sunt foarte uor de fuzionat. Mai greu este cu relaiile care au caracteristici diferite,
uneori este chiar imposibil s fuzioneze.
Tehnicile utilizate n vederea integrat sunt abstractizarea, precum generalizarea i
agregarea, pentru a creea noi supertipuri sau subtipuri, chiar i introducerea de noi relaii. Spre
exemplu generalizarea unui Individ cu atribute precum servici-titlu poate conduce la
consolidarea a dou vederi a bazei de date: una bazndu-se pe clasificarea indivizilor dup job,
titluri sau alte caracteristici, si o alt vedere se bazeaz pe individ ca i personal al unei
organizaii.
Pasul 3: Fuziunarea i restructurarea schemelor
Obiectivele ale acestei etape sunt completitudinea, minimalitatea i inteligibilitatea
schemelor. Completitudinea necesit ca toate componentele conceptelor s apar intacte din
punct de vedere semantic n schema global. Minimalitatea este ndeplininit atunci cnd sunt
terse toate conceptele redundante din schem, precum entitiile care se suprapun i relaiile
dintre acestea. Un exemplu de entiti care se suprapun pot fi Automobil i Vehicol.
Inteligibilitatea necesit ca schema global sa fie benefic i sa aib sens pentru utilizator.
Componentele schemelor se unesc suprapunndu-se aceleai concepte, dup care
urmeaz procesul de restructurare a schemei finale, cu scopul de a ndeplini cele trei obiective.
Vederea integral este un proces n continuu rafinare i reevaluare.


Transformarea modelului conceptual de date n tabele SQL

Transformriile de baz pot produce trei tipuri de tabele:
tabel SQL cu acelai coninut ca i entitatea original din care a fost derivat;
tabel SQL cu o cheie strin ncorporat de la entitatea printe;
tabel SQL derivat dintr-o relaie care conine toate cheile primare ale entitiilor
implicate n acea relaie;

Exist trei tipuri de relaii binare care pot aprea ntre tabele:
1:1 ( one-to-one) este o relaie n care o entitate poate fi legat doar de o singur entitate
i viceversa;
1:M(one-to-many) este relaia ideal n orice baz de date relaional; uor de
implementat, trebuie doar inclus cheia primar de la entitatea one ca i cheie strin
n tabelul many;
M:M(many-to-many) ar trebui evitat deoarece duce la date redundante, ns poate fi
implementat desprind-o ntr-un set de relaii 1:M;

Relaii ternare i n-are
O relaie n-ar are (n+1) variaii posibile de conectivitate: toate cele n pari se conecteaz
cu partea one; (n-1) pri se conecteaz cu one i partea one se conectez cu many; (n-
2) pri se conecteaz cu one i dou pri cu many, i tot aa pn cnd toate prile vor fi
many. Relaiile ternare i n-are sunt definite ca i nite colecii de n chei primare asociate
entitiilor implicate n relaie.
Generalizarea i agregarea
Transformarea produs de generalizare creaz tabele separate SQL, att pentru entitatea
parinte, ct i pentru entitiile copii. Tabelul derivat din printe va conine cheia primar a
entitii respective, la fel ca i toate tabelele derivate din copii. Integritatea actualizrilor n tabele
este meninut prin adugarea sau tergerea de valori att n tabelul printe, ct i pentru tabelele
derivate din entitiile copii.
De obicei ce adaug un discriminator atunci cnd se implementeaz generalizarea.
Discriminatorul este un atribut care are o valoare separat pentru fiecare subtip (entitate copil) i
indic care subtip trebuie folosit pentru a lua informaiile necesare.
Transformarea agregrii produce la fel tabele sepate pentru supertipuri (entitatea printe)
i subtipuri, ns nu exist atribute comune ntre ele i nici constrngeri de integritate de
meninut. n UML, agregarea este o relaie de compoziie care corespunde unei entiti slabe.
Relaii multiple
Relaiile multiple ntre n entiti sunt considerate ntotdeauna complet independente.
Unu-la-unu sau unu-la-mai muli sunt relaii care produc tabele echivalente, difer doar prin
apariia cheii strine, deci pot fi unite ntr-un singur tabel care va conine toate chile strine.
Relaiile ternare i M:M tind s fie unice i de aceea nu pot fi fuzionate.
Entiti slabe
Entitiile slabe difer de cele normale doar prin necesitatea lor de chei de la alte entiti
pentru a-i stabili unicitatea. n rest au aceleai proprieti de transformare ca i restul entitiilor
i nu necesit reguli speciale. Cnd o entitate slab este derivat din una sau mai multe entiti
din diagrama ER, poate fi transformat direct n tabel, fr nici o alt modificare.


Paii ce trebuie urmai n transformarea unei diagrame ER n tabele SQL sunt:
1. Transformarea fiecrei entiti ntr-un tabel coninnd cheia primar i atributele entitii;
2. Transformarea tuturor relaiilor binare M:M sau a celor recursive binare n tabele cu toate
cheile i atributelor entitiilor implicate n relaiile respective;
3. Transformarea tuturor relaiilor ternare n tabele;
Normalizarea tebelelor
Tabelele bazei de date relaionale, fie c sunt derivate din modele ER sau UML, pot avea
probleme serioase n ceea ce privete performana, integritatea i meninerea. Spre exemplu cnd
o ntreag baz de date este definit ca un singur tabel pot rezulta date redundante i cutri
ndelungate pentru un numr mic de rnduri. Se poate ajunge i la modificri lungi i scumpe
sau la tergeri care pot s elimine i date utile.
Normalizarea este un process care const n evaluarea i corectarea structurii tabelelor
pentru a minimiliza apariia datelor redundante i a elimina anomaliile dintre date. Normalizarea
este ndeplinit analiznd interdependenele dintre atributele individuale asociate cu tabele mari
pentru a forma unele mai mici.
Normalizarea lucreaz prin mai multe etape numite forme normale. Primele trei etape
sunt: prima form normal(1NF), a doua form normal(2NF) i a treia form normal(3NF).
Din punct de vedere structural, forma a doua normal este mai bun dect 1NF,iar 3NF este cea
mai bun dintre toate. Pentru majoritatea bazelor de date este de ajuns s se ajung la a treia
form normal, ns exist i aplicaii specializate care necesit normalizarea pn la forma a
patra normal(4NF).
Cel mai nalt nivel al normalizrii unei baze de date nu este ntotdeauna i cel mai
eficient, doarece necesit mai multe join-uri pentru a obine rezultatul dorit i astfel este ncetinit
i timpul de rspundere al bazei de date la cererile utilizatorilor. Un design de succes trebuie sa ia
n considerare cererile utilizatorilor pentru a obine o performan rapid. n acest scop se poate
ajunge i la denormalizarea unor poriuni din design-ul bazei de date. Prin denormalizare se
ajunge la o form normal mai mic dect cea iniial,adic se convertete de exemplu din 3NF
n 2NF.

Prima form normal

Pentru a nelege mai bine definiia primei forme normale, trebuie cunoscut diferena
ntre domeniu, atribut i coloan. Un domeniu este un set de valori posibile ce pot fi luate de un
tip particular de atribut, dar poate fi folosit pentru mai mult de un singur atribut. Fiecare coloan
dintr-un tabel reprezint un singur atribut, dar n unele cazuri mai mult de o coloan se poate
referi la atribute diferite din acelai domeniu. Cnd se ntmpl acest lucru, tabelul este n prima
form normal, deoarece valorile din tabel sunt atomice.
Un tabel n prima form normal sufer deseori de date duplicate, degradarea
performanei update-urilor i probleme la integritatea modificrilor. O supercheie este un set de
unul sau mai multe atribute care,luate ca i o colectivitate, poate identifica unic o entitate sau un
tabel. Oricare subset de atribute al unei superchei care este i el o supercheie i nu este reductibil
la alt supercheie, se numete cheie candidat. O cheie primar este selectat arbitrar din setul de
chei candidate, pentru a fi utilizat ntr-un index la acel tabel.
Condiiile care trebuie ndeplinite pentru ca un tabel s fie n 1NF sunt:
Toate cheile sunt definite;
Nu sunt grupuri repetitive n tabel, adic fiecare rnd/coloan poate conine doar o
singur valuare i nu un set de valori;
Toate atributele sunt dependente de cheia primar;
Un exemplu de tabel n 1NF este reprezentat n Fig.Tabel Raport, unde toate atributele
formeaz o supercheie deoarece nu sunt permise rnduri duplicate ntr-un model relaional.
Presupunnd c fiecare adres a unui departament( dep_adr) conine o singur valuare, atunci
toate celelalte atribute, cu excepia lui dep_adr, pot fi superchei. Se observ c atributele
(report_nr,autor_id) pot identifica unic celelalte atribute din tabel, fiind o supercheie. Totui dac
lum separat aceste doua atribute,ele nu pot s identifice unic un rnd din tabel, ceea ce
tranform compoziia ntr-o cheie candidat. Fiind singura cheie candidat din tabel va deveni
cheia primar a tabelului respectiv.

Report_nr Editor Dep_nr Dep_nume Dep_adr Autor_id Autor_nume Autor_adr
420 Andrei 15 Design Eroilor1 21 Cristian Cetatii

420 Andrei 15 Design Eroilor1 22 Cosmin Bucegi
530 Robert 27 Analiz Eroilor2 35 Ciprian Florilor
530 Robert 27 Analiz Eroilor2 41 Robert Eroilor

Forma a doua normal
Pentru a explica conceptul 2NF, trebuie cunoscut semnificaia unei dependene
funcionale. Proprietatea unuia sau mai multor atribute de a determina unic valoarea unui alt
atribut sau a mai multor atribute se numete depdenden funcional. Fiind dat un tabel R, un set
de atribute B este dependent funcional de un alt set de atribute A dac n orice moment, fiecare
valoare A este asociat cu o singur valoare B. Aceast dependen funcional se notez A -> B.
Un tabel este n 2NF dac:
Este n 1NF;
Nu include nici o dependen parial, adic nici un atribut nu este dependent doar de o
poriune a cheii primare;
Exist o serie de dezavantaje care se regsesc n 1NF i care duc la transformarea n 2NF:
Anomalia de inserare se refer la o situaie n care nu se pot insera date n baza de date
din cauza unei dependene artificiale dintre coloanele unui tabel;
Anomalia de tergere este inversul anomaliei de inserare. Se refer la situaia n care
tergerea unor date duce la pierderea neintenionat a altor date;
Anomalia de actualizare se refer la o situaie n care actualizarea unei singure valori
necesit actualizarea mai multor rnduri. Un alt pericol legat de aceast anomalie este
faptul c stocarea unor date redundante poate duce la posibilitatea de a actualiza numai o
parte a copiilor respectivelor date, ceea ce ar avea ca rezultat apariia inconsecvenelor n
baza de date;
Transformarea tabelui Raport din Fig. Tabel Raport din 1NF n 2NF este urmtoarea cu
dependenele funcionale:
report1: report_nr -> editor, dept_no
dep_no ->:dep_nume, dep_adr
report2: autor_id -> autor_nume, autor_adr
report3: (report_nr,autor_id) este cheia candidat

Report_nr Editor Dep_nr Dep_nume Dep_adr
420 Andrei 15 Design Eroilor1
530 Robert 27 analiza Eroilor2
Fig Report1

Autor_id Autor_nume Autor_adr
21 Cristian Cetii
22 Cosmin Bucegi
35 Ciprian Eroilor
41 Robert florilor
Fig. Report2

Report_nr Autor_id
430 21
430 22
530 35
530 41
Fig. Report3

Astfel se elimin problemele cele mai grave din 1NF, n special anomalia de tergere. Este
important de tiut c aceste trei tabele din 2NF se pot genera direct din diagrama ER sau UML,
prin dou entiti Autor i Raport n care exist o relaie M:M.

Forma a treia normal

Un tabel este n forma a treia normal daca:
Este n 2NF;
Nu conine nici o dependen tranzitiv;
Forma a doua normal prezint mbuntiri semnificative fa de 1NF, ins nu se elimin
definitiv anomaliile de care suferea 1NF. Dac exist o dependen funcional tranzitiv ntr-
un tabel, nseamn c doi factori separai sunt reprezentai n acelai tabel.
Pentru a transforma tabelul Raport din 2NF n 3NF se vor produce urmtoarele
modificri pentru a elimina dependenele tranzitive:
report11: report_nr -> editor,dep_nr
report12:dep_nr -> dep_nume, dep_adr
report2: autor_id ->autor_nume, autor_adr
report3: report_nr,autor_id) este cheia candidat

Report_nr Editor Dep_nr
420 Andrei 15
530 Robert 27
Fig. Report11

Dep_nr Dep_nume Dep_adr
15 Design Eroilor1
27 Analiz Eroilor2
Fig Report12

Forma a patra normal
Un tabel este n 4NF dac:
Este n 3NF;
Nu exist atribute multiple cu valori multiple;
Spre exemplu un angajat poate avea mai multe misiuni i poate fi implicat n mai multe
organizaii. Presupunnd c angajatul X lucreaz ca i voluntar la Y i Z, i tot acelai angajat lucreaz
pentru alte trei proiecte. Prin crearea tabelului Voluntar(angajat, cod_organizaie, nr_proiect) atributele
cod_organizaie i nr_proiect pot avea multe valori diferite. Tabelul va conine dou seturi de dependene
multiple. Pentru eliminarea acestei probleme se pot crea tabele Proiecte i Misiuni.
Performana
Performana bazei de date este unul dintre cei mai importani factori din implementarea
bazei de date. Evaluarea performanei poate fi redat mai dificil deoarece nu exist un standard
de msurare a performanei bazelor de date. Performana variaz n funcie de mediul hardware
i software utilizat. Chiar i mrimea bazei de date afectez performana bazei de date: o cutare
de 10 tupluri va fi mai rapid dect o cutare de 100.000 de tupluri.
Factori importani n performana bazei de date includ i sistemul i parametrii de
configurare a bazei de date, precum plasarea datelor, definirea calei de acces, utilizarea index-
urilor, dimensiunea buffer-ului.
Securitatea
Datele stocate ntr-o baz de date trebuie protejate de accesul unor utilizatori neautorizai.
n acest scop trebuie luate n considerare urmtorii factori:
Securitatea fizic permite accesul fizic n anumite zone numai de personal autorizat;
Depinznd de implementarea bazei de date, stabilirea unei securiti fizice nu este
ntotdeauna o soluie optim. De exemplu, pentru o baz de date care implic cutarea
unui student ntr-o universitate securitatea fizic nu este practic;
Securitatea parolei permite redarea drepturilor de acces pentru utilizatorii autorizai
specifici. Securitatea parolei este de obicei executat la logarea utilizatorilor la nivelul de
operare al sistemului;
Drepturile de acces pot fi stabilite n timpul utilizrii softului bazei de date. Aceste
drepturi de acces pot restriciona operaiile( create, update, delete) asupra tabelelor,
vederilor, rapoartelor, queri-urilor;
Criptarea datelor poate fi utilizat pentru a se ocupa de datele nefolositoare ale
utilizatorilor neautorizai care s-ar putea s fi violat nite layere de securitate a bazei de
date;
Staiile de lucru fr disc permit administratorului s acceseze baza de date fr a fi
nevoie s instaleze informaiile de la staia lor de lucru;

Meninerea i evoluia bazelor de date
Administratorul bazei de date trebuie s fie pregtit pentru a efectua nite activiti de
meninere a bazelor de date precum:
Meninere preventiv (backup);
Meninere corect (recuperare);
Meninere adaptiv (consolidarea performanei, adugnd entiti i atribute,etc);
Meninerea i accesul a utilizatorilor noi i vechi;
Generarea de statistici de acces la baza de date pentru a mbuntii eficiena i a
monotoriza performana sistemelor;

Strategii ale bazelor de date
Exist dou abordri clasice ale design-ului bazelor de date:
1. Design top-down care ncepe identificnd seturile de date, dup care definete
elementele datelor pentru fiecare dintre aceste seturi. Acest proces implic identificarea
tipurilor diferite de entiti i definirea a fiecrui atribut din entitate.
2. Design bottom-up care identific prima dat elementele datelor, iar apoi le grupeaz n
seturi de date. Cu alte cuvinte, la nceput definete atributele i apoi le grupeaz n
entiti.

Alegerea nte cele dou strategii depinde de obicei de scopul aplicaiei i de preferinele
personalului. Totui aceste dou metodologii sunt complementare, nu se exclud reciproc. Design-
ul bottom-up poate fi mai productiv pentru bazele de date mai mici, cu puine entiti, relaii i
tranzacii, ns design-ul top-down poate fi mai uor de administrat.
Procesul de normalizare al tabelelor utilizeaz tehnica bottom-up, chiar dac este selectat
desgn-ul top-down. La fel i modelele ER constituie un process top-down, dei selecia
atributelor i entitiilor este descrisa ca fiind bottom-up.
Design-ul centralizat i decentralizat
Cele dou abordri ale design-ului bazelor de date (bottom-up i top-down) pot fi
influenate de factori precum scopul i dimensiunea sistemului sau stilul de management al
companiei. Depinznd de aceti factori, design-ul bazei de date se bazeaz pe dou filozofii
diferite:
1. Design-ul centralizat este productiv cnd componenta datlor este compus dintr-un
numr relativ mic de obiecte i proceduri. Design-ul centralizat este utilizat de bazele de
date mici i simple i poate fi fcut cu succes de o singur persoan( administrator) sau de
o echip redus. Operaiile aplicaiei i scopul ei permit limitarea chiar la un singur
designer pentru a defini problemele, crearea design-ului conceptual, verificarea acestui
design conceptual cu vederile utilizatorilor, definirea proceselor sistemului i asigurarea
eficinei prin constrngerile dintre date, i mai ales s se asigure c design-ul respectiv
corespunde tuturor cerinelor.
2. Design-ul decentralizat poate fi utilizat cnd componenta datelor din sistem conine un
numr mare de entiti i relaii complexe pe care sunt efectuate operaii complexe. n
proiecte mari i complexe, design-ul unei baze de date nu poate fi fcut doar de o singur
persoan, ci de o ntreag echip aleas cu atenie pentru ndeplinirea acestei sarcini.
Designer-ul lider atribuie module grupurilor din echipa de designeri. Fiecare grup creaz
un model de date conceptual pentru subsetul care i-a fost atribuit. Fiecare model
conceptual este verificat individual mpotriva vederilor utilizatorilor, proceselor i
constrngerile fiecrui modul. Dup ce procesul de verificare este complet toate modulele
se integrez ntr-un singur model conceptual. La final liderul trebuie s verifice dac
modelul conceptual suport toate tranzaciile cerute.


Cap 3 Aplicatia Practic

Aplicaia practic const n crearea unei baze de date i principalul ei scop este de a
exemplifica ciclul de via al bazelor de date, n special primele dou etape: specificarea i
proiectarea. Tema aleas pentru realizarea aplicaiei este o baz de date n asisten social, axat
pe vrstnici( persoane peste 65 de ani) din centrele de btrni sau care sunt ngrijii la domiciliu.
n urma unei documentri aprofundate pentru ntocmirea informaiilor necesare realizrii
acestei aplicaii, vizitarea mai multor centre de btrni, interogarea unor asisteni sociali care
lucreaz cu vrstnici, s-a ajuns la concluzia c o baz de date care s in evidena lor este
absolut necesar deoarece n momentul actual, n majoritatea centrelor, nu se gsete nimic
computerizat, totul este pe baz de dosare i fie.

Pentru realizarea oricrui sistem informatic exist anumite cerine impuse care trebuie
respectate, spre exemplu aceast aplicaie ndeplinete urmtoarele condiii:
Din punct de vedere hadware , implementarea programului nu implic costuri
suplimentare. Se va utiliza doar calculatorul aflat la dispoziia personalului.
Se utilizeaz un software de uz general, al crui licen este gratuit( Java i My
Sql WorkBench).
Sistemul trebuie s ndeplineasc toate sarcinile impuse de client.
S permit dezvoltri ulterioare, adugarea de noi funcionaliti,etc.
Sistemul s aib un caracter de generalitate i posibilitatea de a putea fi utilizat
pentru o perioad ndelungat de timp.
Utilizarea aplicaiei de clieni sa nu necesite cunotine n informatic, doar
informaii minimale despre utilizarea calculatorului.
1. Specificarea i analiza cerinelor
Informaiile necesare realizrii proiectrii bazei de date au fost obinute pe baza mai
multor interviuri cu diferii asisteni sociali care se ocup de vrstnici i cu personalul anumitor
centre de btrni precum Centrul de Asisten social i ngrijire din Cluj-Napoca, comunitatea
Sfntul Vasile cel Mare care ofer asisten la domiciliu, Consiliul Local al municipiului Cluj-
Napoca Direcia de Asisten Social.
Pe lng aceste interviuri au fost procurate i nite fie de evaluare despre informaiile
necesare introducerii unui asistat ntr-un centru de btrni i despre testrile periodice la care
sunt supui pentru a menine evidena fiecrei persoane. Principalele fie care au avut un rol
important n conceperea aplicaie sunt: Fia de Evaluare Sociomedical Geriatric , Fi de
evaluare pentru persoanele cu handicap , Fi de evaluare pentru persoanele fr handicap,
Fi general de evaluare, Raport activitate.
Cerinele aplicaiei
Aplicaia gestioneaz asistaii i personalul unui centru de btrni i realizeaz
urmtoarele funcionaliti:
Administratrea tuturor utilizatorilor;
Introducerea asistaiilor n sistem, vizualizarea informaiilor despre ei, efectuarea
testelor pe calculator i generarea de noi teste;
Statistici cu referire la venitul vrstnicilor, vrsta, gradul de dependen sau
handicap;
Gestionarea serviciilor acordate persoanelor asistate i ale activitiilor zilnice;
Evidena sponsorilor i a voluntarilor i serviciilor oferite de acetia;
Gestionarea venitului de ctre administratorul bazei de date;
Meninerea activitiilor zilnice i introducerea de noi evenimente pentru asistai;

Aplicaia conine trei tipuri de utilizatori: administrator cu drepturi depline, asisteni
sociali cu posibilitatea de a produce transformri la nivelul bazei de date i utilizatori care au
dreptul la vizualizarea anumitor statistici sau informaii despre centrul respectiv. Se mparte n
mai multe module precum:
1.1 Modulul de autentificare i administrarea utilizatorilor
Acest modul permite accesul la seciunile private ale utilizatorilor la baza de date prin
intermediul autentificrii. Acetia se autentific folosind userul i parola care vor fi salvate n
baza de date codificate cu ajutorul lui Base64 encoder. Utilizatorii vor fi verificai ca autentificai
la orice cerere care se va face ctre aplicaie.
1.1.1 Submodul administrare utilizatori
Acest modul va permite utilizatorilor de tip Super-utilizatori s administreze toate
aspectele legate de utilizatorii sistemului i s intervin pentru a preveni abuzul prin tergerea
coninutului care nu respect termenii si condiiile de utilizare i interzicerea accesului
utilizatorilor care ncalc in mod frecvent regulile.
1.2 Modul Administrator baz de date
n baza de date se salveaz cteva informaii minimale legate de administratorul bazei de
date: numele, prenumele,cnp, adresa i telefonul. El realizeaz funcionalitiile:
Genereaz parolele i gestioneaz toi utilizatori;
Gestiunea asistenilor sociali (introducerea n sistem, editarea, tergerea lor,
vizualizarea informaiilor despre ei);
Administrarea venitului asistaiilor, a serviciilor acordate fiecruia n funcie de
venitul lor;
Gestiunea voluntarilor( adugarea, editarea , tergerea i vizualizare lor);
Gestiune activitiilor( adugarea, editarea , tergerea i vizualizare lor);
Gestiunea sponsorilor( adugarea, editarea , tergerea i vizualizare lor);
Autentificarea la aplicaie;
Gestiunea serviciilor acordate asistaiilor i stabilirea costului fiecrui serviciu;
Efectuarea de anumite cutri ale utilizatorilor dup diferite criterii;
Realizarea unor statistici asupra asistaiilor;

1.2.1 Submodul administrare venit
n funcie de venitul fiecrei persoane se stabilete lista serviciilor care vor fi acordate
pentru fiecare asistat n parte la domiciuliu. Orice serviciu va avea un cost, ns pentru
persoanele cu un venit foarte mic sau chiar deloc, va putea beneficia gratuit de toate serviciile
centrului.
Administratorul stabilete suma care va delimita persoanele ce primesc servicii gratuite
de cele contracost.

1.3 Modul Asistent Social
Asistentul social efectueaz urmtoarele:
Gestionarea tututor asistaiilor, pe lng operaiile clasice( adugare, editare,
tergere, vizualizare) au posibilitatea de ai testa periodic;
Vizualizarea tuturor serviciilor de care beneficiez fiecare asistat n parte;
Posibilitatea de a vizualiza activitiile persoanelor asistate;
Vizualizarea voluntarilor i a grupurilor de asistaii de la fiecare asistat;
Se pot realiza diferite cutri ale asistailor dup diferite criteii precum: vrsta,
venitul, gradul de dependen, handicap;
Cutri ale voluntarilor dup cnp;
Gestiunea testelor pentru asistai care este prezent n submodulul Testare
Asistai;
1.3.1 Submodul Testare Asistai
Asistentul social are posibilitatea s introduc n sistem noi teste prin completarea unor
formulare cu ntrebrile testelor, rspunsurile la fiecare ntrebare i punctajul respectiv. Se pot
modifca testele existente sau terge.
Un asistent testeaz periodic asistaii i informaiile legate de teste i de rspunsurile la
fiecare test, de punctaj, toate se salveaz n baza de date. Un asistat poate s fie examinat de mai
multe ori cu acelai test i se poate vizualiza fiecare variant completat a testului. La finalul
oricrui test rezultatul este calculat prin adunarea tuturor punctelor de la fiecare variant de
rspuns aleas i salvat n baza de date.
1.4 Modul Utilizator
Aplicaia poate fi utilizat pe lnga administrator i asistenii sociali i de alte persoane
autorizate ale unui centru de btrni, cum ar fi directorul, secretarul sau personalul din incinta
centrului respectiv. Fiecare utilizator va primi o parol i un user cu care se vor loga la aplicaie.
Acetia nu au posibilitatea s produc transformri la nivelul bazei de date, vor putea
vizualiza doar anumite statistici despre asistai precum: persoanele cu venitul peste nite limite
impuse de administrator, numrul de persoane cu handicap i fr handicap, cele cu vrstre
cuprinse n anumite perioade de ani.

Modul Asistat
La introducerea oricrei persoane asistate ntr-un centru se completeaz un formular cu
informaii legate de persoana respectiv precum:
Date personale(nume, prenume, adresa, vrst, venit, religie, studii, copii, stare civil,
telefon, profesie, handicap);
Date legate de reprezentantul legal al asistatului( nume, prenume, adres,
telefon,cnp). Fiecare asistat trebuie s aib un reprezentant legal la care se apeleaz n
caz de deces sau la diferite alte probleme;
Se efectueaz o evaluare social care cuprinde informaii despre relaiile
asistatului cu familia, cu prietenii, starea locuinei pe care o are, dac este
cumva neglijat de persoana ce l are n grij, starea de sntate i cea
economic;
Se realizeaz trei teste: ADL(activiti de zi cu zi, IADL(activitiile
instrumentale de zi cu zi) i MMSE(minimental state examination) pentru a
descoperi capacitiile fiecrei persoane i mai ales nevoile lor. n funcie de
rezultatele la aceste teste se hotrte ce fel de servicii trebuie acordate
asistaiilor;
2. Design-ul logic
Modelarea conceptual cu ajutorul diagramelor UML
Pentru a realiza un sistem, trebuie mai nti sa fie modelat. Pentru a analiza un sistem,
trebuie, de asemenea, s fie modelat. Modelarea are nevoie de un limbaj, n primul rnd ca
mijloc de comunicare, pentru ca toi factorii implicai, constructori i utilizatori, s neleag
acelai lucru.
n realizarea etapei de analiz s-a optat pentru Limbajul de modelare unificat(UML)
deoarece n prezent este limbajul universal standard pentru dezvoltatorii software din toat
lumea. UML deine o expresivitate care ajut la rezolvarea problemelor de modelare pe care
vechiile limbaje nu o aveau. UML ofer arhitecturi de sisteme ce funcioneaz pe analiza i
proiectarea obiectelor cu un limbaj corespunztor pentru specificarea, vizualizarea, construirea i
documentarea.
Funcionalitiile aplicaiei sunt reprezentate prin Diagrama Cazurilor de Utilizare care
ofer o imagine de ansamblu asupra comportamentului sistemului din punct de vedere al
utilizatorilor.
Rafinarea diagramei cazurilor de utilizare se face cu ajutorul Diagramei de Activitate
care reflect vederea dinamic de design, interaciunile dintre activiti, fluxul de control al
trecerii de la o activitate la alta.
Pentru descrierea structurii statice a softului, adic a entitiilor sau claselor existente n
aplicaie se utilizeaz Diagrama de Clase.

Alegerea SGBD-ului adecvat
n dezvoltarea aplicaiei s-a optat pentru MySQL Workbench care ofer un tool grafic
pentru a lucra cu servere i baze de date MySQL. MySQl Workbench sprijin pe deplin
versiunile MySQL Server 5.1 i este de asemenea compatibil i cu veriunea 5.0. Principalul
motiv n alegerea acestui SGBD sunt cele trei domenii de funcionare care le prevede:
Dezvoltare SQL: permite crearea i gestionarea conexiunilor la serverele de baze
de date, precum i posibilitatea de a configura parametrii de conectare, de a
executa interogri SQL pe conexiuni de date folosind SQL Editor. Aceast
funcionalitate nlocuiete aplicaia de sine stttoare Query Browser.
Modelarea datelor: permite crearea de modele grafice ale schemei bazelor de date
i editarea tuturor aspectelor legate de baza de date folosind Tabelul Editor.
Acesta ofer faciliti uor de utilizat pentru editarea tabelelor, coloanelor, index-
urilor, insert-urilor, triggere-lor, rutinelor, i vederilor.
Administrarea serverului: permite crearea i administrarea instanelor serverului.
MySQL Workbench este disponibil n dou ediii: Ediia Standard i Ediia Comunitate
(Community Edition). Ediia Comunitate este disponibil gratuit, iar cea Standard ofer
caracteristici suplimentare de vizitare, cum ar fi generarea documentaiei bazei de date, la un cost
sczut.

Crearei schemei fizice a bazei de date cu Diagrama EER
Primul pas este crearea unui model al bazei de date care poate conine mai multe scheme
fizice. n sectiune Physical Schemata din MySQL Workbench s-a creat un nou model mydb
i schema fizic a bazei de date. Schema respectiv conine toate piesele necesare pentru
definirea bazei de date. Fiecare obiect adugat n modelul grafic va aprea i n schema fizic.
Diagramele EER(Extended Entity-Relationship) modeleaz datele i relaiile dintre ele
utiliznd simboluri standard. Modelele EER pot fi complexe, ns MySQL Workbench utilizeaz
doar un subset din elementele grafice, deoarece scopul acestei diagrame este ca fiecare element
s fie mapat n schema fizic.

Generarea scriptului SQL i crearea bazei de date
Dupa crearea modelului, urmatorul pas este generarea scriptului SQL pentru a fi executat
de un server pentru a crea baza de date fizic. n realizarea acestui scop MySQLWorkbench
ofer opiunea Forward Engineer unde se poate revedea sau edita scriptul nainte de generarea
lui. Dup generare se selectez conexiunea unde va fi trimis scriptul respectiv i dac toat
operaiunea se termin cu succes, o nou baz de date va fi creat.



Concluzii

n ultimii ani tehnologiile bazelor de date au devenit tot mai complexe, integrnd tot mai
multe concepte din alte domenii. Bazele de date reprezint n momentul actual cadrul
fundamental al unui sistem informaional i a modificat radical modul de operare al multor
organizaii.
n particular, dezvoltarea acestei tehnologii de-a lungul ultimilor ani a dus la crearea unor
sisteme mai puternice, ce pot fi utilizate ntr-un mod mult mai intuitiv. Rezultatul a fost c
sistemele de baz de date au devenit din ce n ce mai accesibile pentru o varietate mai larg de
utilizatori.
O baz de date poate fi de diverse mrimi i diverse complexiti, putnd fi generat i
meninut manual sau cu ajutorul programelor utilitare. Sistemul de gestiune al bazei de
date(SGBD) este reprezentat de colecia programelor ce ajut utilizatorul s creeze i s ntrein
baza de date.
Bazele de date ofer back-up la defectrile hardware i software, contribuie la reducerea
timpului de dezvoltare a aplicaiilor, faciliteaz reactualizare ca urmare a a adugrii de noi date
sau a modificrilor structurii datelor existente.
Exist mai multe moduri pentru a organiza datele ntr-o baz de date, dar bazele de date
relaionale sunt unele din cele mai eficace. Sistemele baze de date relaionale sunt o aplicaie a
teoriei serviciului matematic n problema organizrii efective a datelor. ntr-o baz de date
relaional datele sunt adunate n tabele( denumite relaii n teoria relaional).
Specificarea i proiectarea bazelor de date sunt etapele cele mai importante n crearea
unei aplicaii, deoarece dac nu se respect n totalitate cerinele clienilor i paii ce trebuie
urmai n procesul de proiectare aplicaia nu va putea ndeplini funcionalitiile propuse. S-a
constat c cele mai costisitoare erori sunt cele aflate la nivelul specificaiei softului.
O baz de date utilizat n gestionarea persoanelelor asistate din centrele de btrni sau de
cele care ofer servicii la domiciliu este mult mai eficient dect meninerea evidenei lor prin
intermediul fiierelor. n prelucrarea tradiional a fiierelor fiecare utilizator implementeaz
fiierele necesare propriei aplicaii. Este posibil ca doi utilizatori s creeze fiiere diferit, chiar
dac manipuleaz aceleai date. n aceast situaie utilizatorii folosesc propriile fiiere, fapt ce
duce la creterea redundanei datelor i la spaiu de stocare ineficient ocupat. ntr-o baz de date
o singur structur de date este stocat, dar este folosit de ctre toi utilizatorii.
Aceste consideraii, mpreun cu principiile expuse n aceast lucrare, argumenteaz
importana utilizrii bazelor de date n diferite domenii, fiind n momentul actual unealt
principal i cea mai practic n crearea sistemelor soft.

Abstract

This thesis presents the relational databases, focusing in particular on the specification
and designing. A relational database matches data by using common characteristics within the
data set. The resulting groups of data are organized and are much easier for many people to
understand.
The first part of this thesis describes the general characteristics of databases, their
arhitecture, their classification and cronological presentation of data models. In next chapter are
represented the stages of relational database design and the concepts used for this purpose.
The thesis has an application part, which exemplifies the process of creating a database.
The application is developed using MySQL Workbench and presents the personss management
in a center for elderly. The requirement of application are received from social assistants who
work in nursing homes.
The application contains many features and all information is stored in the database. The
functionalities are described in a rigorous specification and are represented by different digrams
that provides a much more clear view on the data.
This work is the result of my own activity.I have neither given nor received unathorized
assistance on this work.