Coordonator științific: Conf. Univ. Dr. Bogdan PĂTRU Ț Brașov 2010 UNIVERSITATEA “TRANSILVANIA” din BRAȘOV FACULTA TEA DE MATEMATICĂ ȘI INFORMATICĂ… [610935]
UNIVERSITATEA “TRANSILVANIA” din BRAȘOV
FACULTATEA DE MATEMATICĂ ȘI INFORMATICĂ
LUCRARE DE LICENȚĂ
Autor: Camelia CIOCAN
Coordonator științific: Conf. Univ. Dr. Bogdan PĂTRU Ț
Brașov
2010
UNIVERSITATEA “TRANSILVANIA” din BRAȘOV
FACULTA TEA DE MATEMATICĂ ȘI INFORMATICĂ
Sistem de gestiune pentru un
club de dans sportiv
Autor: Camelia CIOCAN
Coordonator științific: Conf. Univ. Dr. Bogdan PĂTRU Ț
Brașov
2010
Cuprins
Lista tabelelor ………………………….. ………………………….. ………………………….. ……………………… – 4 –
Lista figurilor ………………………….. ………………………….. ………………………….. ………………………. – 4 –
Introducere ………………………….. ………………………….. ………………………….. …………………………. – 5 –
CAP.I: Baze de date. Sisteme de gestiune a bazelor de date ………………………….. ……………. – 7 –
I.1. Introducere în domeniul bazelor de date ………………………….. ………………………….. …. – 7 –
I.2. Scurt istoric ………………………….. ………………………….. ………………………….. …………….. – 8 –
I.3. Modelul entități – relații ………………………….. ………………………….. ………………………… – 8 –
I.4. Modele de date ………………………….. ………………………….. ………………………….. ……… – 10 –
I.4.1 Mode lul rețea și modelul ierarhic ………………………….. ………………………….. …. – 10 –
I.4.2 Modelul relațional ………………………….. ………………………….. ………………………. – 10 –
I.5. Dezvoltarea aplicațiilor care lucrează cu baze de date ………………………….. ………… – 12 –
CAP.I I: Probleme de gestiune în cadrul As. C.S. Dance Energy Bacău ……………………… – 14 –
II.1. Prezentare generală ………………………….. ………………………….. ………………………….. . – 14 –
II.2. Modul de funcționare și cerințele pentru aplicație ………………………….. ……………… – 14 –
II.2.1 Membrii sportivi, prezența și cotizațiile ………………………….. ……………………. – 15 –
II.2.2 Grupe și instructori ………………………….. ………………………….. ……………………. – 15 –
II.2.3 Concursuri și rezultate ………………………….. ………………………….. ……………….. – 16 –
CAP.I II: Software de gestiune pentru c luburi sportive ………………………….. …………………. – 19 –
III.1. SalaVB ………………………….. ………………………….. ………………………….. ………………. – 19 –
III.2. Sport Club ………………………….. ………………………….. ………………………….. ………….. – 20 –
III.3. FirmPOS ………………………….. ………………………….. ………………………….. ……………. – 20 –
III.4. Software pentru cluburi de dans sportiv ………………………….. ………………………….. – 21 –
CAP.I V: Proiectarea sistemului DSC -Base ………………………….. ………………………….. ……… – 22 –
IV.1. Normalizarea relațiilor ………………………….. ………………………….. ……………………… – 22 –
IV.1.1. Dependențe de date ………………………….. ………………………….. …………………. – 22 –
IV.1.2. Forme nor male ………………………….. ………………………….. ……………………….. – 23 –
IV.2. Evoluția bazei de date ………………………….. ………………………….. ………………………. – 25 –
IV.3. Implementarea bazei de date cu MySQL ………………………….. ………………………… – 32 –
CAP.V : Aplicația DSC -Base ………………………….. ………………………….. ………………………….. .. – 38 –
V.1. Interfața aplicației ………………………….. ………………………….. ………………………….. … – 38 –
V.2. Dezvoltarea aplicației ………………………….. ………………………….. ………………………… – 43 –
Concluzii ………………………….. ………………………….. ………………………….. ………………………….. .. – 51 –
Bibilografie ………………………….. ………………………….. ………………………….. ………………………… – 53 –
Lista tabelelor
Tabelul II.1. Puncte și finale necesare pentru avansarea în clasă ………………………….. ………… – 17 –
Tabelul II.2. Clasele maxime pe vârstă ………………………….. ………………………….. ……………….. – 17 –
Tabelul IV.1. Drepturile utilizato rilor ………………………….. ………………………….. …………………. – 31 –
Tabelul IV.2. Membrii – tipurile atributelor ………………………….. ………………………….. …………. – 34 –
Tabelul IV.3. Spatiul de memorie ocupat de sirurile de caractere ………………………….. ……….. – 34 –
Tabelul IV.4. Sportivi – tipurile atributelor ………………………….. ………………………….. ………….. – 35 –
Tabelul IV.5. Sportivi – ON DELETE și ON UPDATE ………………………….. …………………….. – 36 –
Lista figurilor
Figura IV.1. Relația SPORTIV – PĂRINTE ………………………….. ………………………….. ………… – 26 –
Figura IV.2. En titatea de joncțiune PĂRINTE_SPORTIV ………………………….. …………………. – 26 –
Figura IV.3. Relația SPORTIV – PREZENȚĂ ………………………….. ………………………….. …….. – 27 –
Figura IV.4. Relația SPORTIV – PREZENȚĂ ………………………….. ………………………….. …….. – 27 –
Figura IV.5. Noua relație SPORTIV – PREZENȚĂ ………………………….. ………………………….. – 27 –
Figura IV.6. Entitatea de joncțiune CH_CTZ ………………………….. ………………………….. ………. – 28 –
Figura IV.7. Relația SPORTIV – CHITANȚĂ ………………………….. ………………………….. …….. – 28 –
Figura IV.8. Diagrama E -R pentru prima problemă ………………………….. ………………………….. – 28 –
Figura IV.9. Diagrama E -R pentru prima problemă ………………………….. ………………………….. – 28 –
Figura IV.10. Entitatea de joncțiune PĂRINTE_MEMBRU ………………………….. ………………. – 29 –
Figura IV.11. Diagr ama E -R după rezolvarea problemei 2 ………………………….. ………………… – 30 –
Figura IV.12. Diagrama E -R după rezolvarea problemei 3 ………………………….. ………………… – 31 –
Figura IV.13. Diagrama E -R a bazei de date ………………………….. ………………………….. ……….. – 33 –
Figura V.1. Împărțirea și aspectul general al paginii ………………………….. …………………………. – 40 –
Figura V.2. Formular înregistrare ………………………….. ………………………….. ………………………. – 41 –
Figura V.3. Formular – grupă nouă ………………………….. ………………………….. …………………….. – 42 –
Figura V.4. Verificarea datei ………………………….. ………………………….. ………………………….. …. – 44 –
Figura V.5. Atenționare vize medicale ………………………….. ………………………….. ………………… – 48 –
Figura V.6. Rezultate – date incorecte ………………………….. ………………………….. …………………. – 49 –
Figura V.7. Rezultate – date corecte ………………………….. ………………………….. ……………………. – 50 –
Camelia Ciocan Introducere
– 5 –
Introducere
Încă din cele mai vechi timpuri, oamenii au avut nevoie de eviden țe, în propria
gospodărie sau în institu ții publice: recolta strânsă într -un an, taxe și impozite plătite către stat,
decizii ale judecătorilor, etc . Astfel au început să se dezvolte diverse tehnici de a organiza și
gestiona înregistrările. A șa au apărut, de exemplu, bibliotecile.
De la mormanele de hârtii și dosare care se foloseau în trecut pentru gestionarea
datelor dintr -o institu ție, s-a ajuns c a astăzi, în orice organiza ție, institu ție sau firmă, să se
utilizeze calculatorul. În secolul vitezei nu mai sunt necesare ore întregi și echipe de zeci de
oameni pentru ob ținerea unor rapoarte și nici încăperi uria șe pentru depozitarea dosarelor cu
diver se date. Astăzi, aceste date se stochează pe un hard disk, de dimensiuni foarte mici, dar cu o
capacitate de stocare foarte mare. Câ țiva oameni care să lucreze cu aplica ții speciale instalate pe
calculator sunt suficien ți pentru a introduce înregistrări în baza de date și pentru a ob ține
informa țiile necesare unor rapoarte.
De la apari ția lor, bazele de date și sistemele de gestiune a bazelor de date au evoluat
foarte mult, iar aplica țiile care lucrează cu baze de date sunt dintre cele mai variate. Aceste
aplica ții asigură, printre altele, o interfa ță intuitivă, pentru ca utilizatorii să în țeleagă și să
interac ționeze u șor cu baza de date. Ele pot fi personalizate și create special pentru necesită țile
unei firme.
În această lucrare voi trata dezvoltarea une i astfel de aplica ții, pornind de la analiza și
proiectarea bazei de date și până la interfa ța cu utilizatorul și modul de func ționare al aplica ției.
Este vorba despre un sistem de gestiune pentru un club de dans sportiv.
Am ales această temă deoarece chi ar eu m -am lovit de necesitatea unui astfel de
sistem. Împreună cu al ți patru asocia ți, am înfiin țat în urmă cu doi ani un club de dans sportiv.
Până acum, țineam eviden țe folosind suita Microsoft Office, mai exact Excel și Word. Însă
numărul membrilor spo rtivi a crescut și gestionarea lor a devenit un proces ceva mai anevoios.
Un alt motiv pentru alegerea temei, este acela că la ora actuală nu există nicun soft de
gestiune care să satisfacă nevoile specifice dansului sportiv. Există aplica ții comerciale pe ntru
cluburi sportive, dar acestea se referă la săli de fitness și aerobic. În plus, acestea nu se potrivesc
Camelia Ciocan Introducere
– 6 –
modului de organizare și func ționare a clubului meu. Câteva astfel de aplica ții am prezentat în al
treilea capitol al lucrării.
De exemplu, într -un club de dans sportiv este necesară eviden ța membrilor care
participă în competi ții și a rezultatelor și punctajelor pe care le ob țin ace știa. Ca în orice sport,
există reguli emise de către federa ția de profil, care încadrează sportivii în diverse clase valorice.
Aplica ția pe care o dezvolt în această lucrare, vine în sprijinul instructorilor și antrenorilor,
ajutându -i în calculul punctajelor și claselor valorice ale sportivilor lor.
În primul capitol, am prezentat câteva no țiuni teoretice despre baze d e date și sisteme
de gestiune a bazelor de date. Aceste no țiuni au fost utile în proiectarea și dezvoltarea bazei de
date pentru aplica ția mea.
În cel de -al doilea capitol am detaliat problemele de gestiune din cadrul clubului de
dans sportiv pentru care am realizat aplica ția. Pa șii proiectării bazei de date sunt parcur și în
capitolul al patrulea, iar în ultimul capitol am tratat dezvoltarea aplica ției.
Interfa ța va fi realizată prin intermediul unui browser de internet. Asfel, pentru
dezvoltarea acestui sistem de gestiune, am folosit tehnologiile web: HTML, PHP, JavaScript și
CSS, iar ca sistem de gestine al bazei de date: MySQL.
Soluțiile oferite de Oracle, Microsoft Access, Microsoft SQL Server, Visual Basic
sau alte medii de programare și sisteme de gestiune a bazelor de date sunt produse comerciale.
Utilizarea tehnologiilor pe care le -am preferat în realizarea aplica ției mele este gratuită. În plus,
astfel va fi mai u șor de realizat o aplica ție care să fie instalată pe un server, și care să poată fi
accesată de către mai mulți utilizatori din loca ții diferite.
Anexat prezentei lucrări este un DVD care con ține: programul EasyPHP (care
include serverul Apache și suportul pentru baze de date MySQL), baza de date “dance” utilizată
de aplica ție și site-ul ce reprezintă interfa ța aplica ției și care cuprinde codurile sursă ale acesteia.
De asemenea, am inclus și lucrarea în format electronic.
Camelia Ciocan CAP. I : Baze de date. Sisteme de gestiune a bazelor de date
– 7 –
Capitolul I
Baze de date. Sisteme de gestiune a bazelor de date
I.1. Introducere în domeniul bazelor de date
În via ța de zi cu zi suntem înconjura ți de informa ții. Citim ziare și cărți, ascultăm
radioul , urmărim o emisiune la televizor, navigăm pe internet, interac ționăm cu oamenii. Toate
acestea reprezintă modalită ți prin care noi aflăm diverse informa ții. Pe baza acestora știm ce și
cum să facem. Un copil care s -a fript când a pus mâna pe aragazul în func țiune, cel mai probabil
nu va mai pune mâna și a doua oară. El are acum informa ția că “frige”. Peste ani, mama sa îl va
învăța cum să folosească aragazul, a dică îi va da informa ții despre func ționarea acestuia.
Apare adeseori confuzia între “informatii” și “date”. Un manager, de exemplu, î și
alege membrii echipei și hotără ște atribu țiile fiecăruia, în func ție de ceea ce știe despre ace știa:
studii, abilită ți, experien ță, etc. CV -ul lui Ionu ț Popescu reprezintă un set de date, din care
managerul extrage informa ții: Popescu a terminat facultatea de informatică și are experien ță ca
programator, deci îl va pune să realizeze o aplica ție utilă proiectului pe care îl conduce.
Un alt exemplu ar fi: la o anumită materie elevii unei clase ob țin note. Fiecare notă
reprezintă o dată, iar o informa ție care s -ar putea extrage ar fi media pe clasă a notelor.
Așadar, datele sunt fapte din lumea reală, iar informa țiile rezultă din aceste date prin
interpretarea lor. În plus, datele au un caracter obiectiv, în vreme ce informa ția este subiectivă,
pentru că fiecare poate găsi o altă interpretare a datelor.
Necesitatea de a lucra cu un volum foarte mare de informa ții a dus la apar iția bazelor
de date. Astfel, acestea au devenit o componentă esen țială, de și mai pu țin vizibilă, a sistemelor
informa ționale din aproape orice domeniu: economic, social, științific, cultural, ș.a. [1].
O bază de date poate fi definită ca un ansamblu de da te elementare, structurate. Ea
centralizează datele, pentru ca apoi să fie accesate și prelucrate. Această centralizare reduce
redundan ța datelor memorate și men ține integritatea lor [2].
Lucrul cu bazele de date se face prin intermediul sistemelor de gest iune a bazelor de
date (SGBD1). Acestea permit memorarea datelor pe suport fizic, realizarea legăturilor între date,
introducerea, extragerea și prelucrarea datelor. De asemenea, un SGBD realizează și codificarea,
1 SGBD = sistem de gestiune a bazelor de date
Camelia Ciocan CAP. I : Baze de date. Sisteme de gestiune a bazelor de date
– 8 –
aranjarea și protejarea datelor. Toate ace stea se realizează printr -un limbaj de nivel înalt, astfel că
putem spune că un SGBD este o interfa ță între utilizator și baza de date [3].
I.2. Scurt istoric
În anii „60, firme precum IBM realizează că angajarea unui număr mare de oameni
care să îndeplin ească sarcini precum stocarea și indexarea de dosare, este mult prea costisitoare.
Astfel, decid să adopte solu ții “mecanice”, mai ieftine: calculatoarele [4]. În 1970, bazele de date
se aflau pe calculatoare mari cât o încăpere (mainframe). Procesarea dat elor se făcea tot pe
mainframe, iar rezultatele se afi șau pe calculatoare client, mai mici (numite “thin clients” sau
“dumb terminals” ) [4].
În 1979, Relational Software, Inc., (astăzi Oracle) lansează primul sistem de gestiune
pentru baze de date, bazat pe modelul rela țional propus de Edgar F. Codd în 1970. Oracle este și
primul sistem de baze de date dezvoltat cu SQL (Structured Query Language), devenit un
standard în limbajele pentru baze de date [1].
Relația client/server a evoluat, astfel că, în anii „80, calculatoarele ( “workstations”,
stații de lucru) au devenit “smart clients”, fiind capabile să proceseze date și aveau și o interfa ță
grafică [4].
Odată cu apari ția internetului și dezvoltarea acestuia, au evoluat și sistemele de
gestiune a bazelor de date și posibilită țile acestora de a lucra cu date stocate la distan ță.
I.3. Modelul entită ți – rela ții
Acest model , prescurtat E -R2, a fost fondat de Peter P. Chen, în anul 1976 [5].
Modelul E -R reprezintă o metodă eficientă pentru a vizualiza entită țile și legăturile dintre
acestea. În plus, s -a dovedit util în modelarea datelor, fază a procesului de analiză și proiectare a
bazei de date [1].
Modelul E -R operează cu no țiuni precum: entitate, atribut, rela ție, cheie [2],[3] .
Entitate – un obiect concret sau abstract . Grafic se reprezint ă printr -un dreptunghi.
ex.: PERSOANĂ
2 E-R = (modelul) entități – relații
Camelia Ciocan CAP. I : Baze de date. Sisteme de gestiune a bazelor de date
– 9 –
Instan ță – o apari ție particulară a unei entită ți.
ex.: Ion este o instan ță a entită ții PERSOANĂ
Clasa de entită ți – un grup de entită ți cu propriet ăți comune .
ex.: clasa ANGAJAT cupr inde entit ățile MANAGER și ECONOMIST
Atribut – proprietate a unei entit ăți. Grafic se reprezint ă printr -o elips ă.
ex.: pentru PERSOAN Ă: nume, prenume, data na șterii, adres ă
Atribut simplu – atribut unitate atomic ă.
ex.: prenume
Atribut compus – grup de atribute privit unitar .
ex.: adres ă – strad ă, numar , oraș, jude ț
Domeniul atributului – mulțimea de defini ție a atributului. Aceast ă mulțime
poate fi definit ă și explicit, preciz ând valorile pe care le poate avea atributul.
ex.: numere naturale, șiruri de caractere, {profesor, student}
Cheie – atribut care identific ă unic o entitate sau care stabile ște o rela ție cu o alt ă entitate.
Pentru reprezentarea grafic ă, atributele cheie sunt subli niate.
Cheie primar ă – atribut care identifică unic o instan ță a unei entită ți. Nu pot
exista două instan țe ale aceleia și entită ți care să aibă aceea și cheie primară. O cheie
primară nu poate fi niciodată nulă.
Cheie candidat ă – dacă există mai multe chei primare posibile într -o entitate,
atunci fiecare dintre acestea e ste o cheie candidată.
Cheie împrumutat ă – cheia primară a clasei devine cheie împrumutată pentru
entitatea ce apar ține acelei clase.
Cheie secundar ă – atribut ce referă la cheia primară a entită ții cu care entitatea
curentă se află în rela ție.
Rela ție – legatura dintre doua entitati . Grafic, se reprezinta printr -un romb.
Gradul rela ției – numărul de entită ți implicat în rela ție.
Opționalitate a rela ției – specifică dacă o instan ță a entită ții E 1 poate fi sau dacă
trebuie să fie asociată cu o instan ță a enti tății E 2.
Cardinalitate – indică numărul de instan țe ale unei entită ți E 1 care pot fi sau
care trebuie asociate cu instan țe ale entită ții E 2. Cardinalitatea poate fi de tip:
a) 1-1 (One to One) : unei instan țe a entită ții E 1 i se asociază cel mult o instan ță a
entită ții E 2, și reciproc.
Camelia Ciocan CAP. I : Baze de date. Sisteme de gestiune a bazelor de date
– 10 –
ex.: un student are un singur carnet de student, iar un carnet apar ține
unui singur student
b) 1-n (One to Many) : unei instan țe a entită ții E 1 i se asociază (i se pot asocia) una
sau mai multe instan țe ale entită ții E 2, dar reciproc nu este valabil .
ex.: o persoană poate avea unul sau mai multe conturi în bancă, dar
un cont îi corespunde unei singure persoane
c) m -n (Many to Many) : unei instan țe a entită ții E 1 i se asociază (i se pot asocia)
una sau mai multe instan țe ale entită ții E 2, și reciproc .
ex.: un student urmează mai multe cursuri și un curs are mai mul ți
studen ți
I.4. Modele de date
Datele sunt organizate și manipulate după anumite reguli. Aceste reguli reprezintă
modelul de date, care se utilizează în proiectar ea sistemelor SGBD -urilor .
I.4.1 Modelul rețea și modelul ierarhic
Modelul re țea se apropie cel mai mult de diagramele E-R. Diferen ță este că rela țiile
pot fi numai binare și doar de tipul 1 -1 și 1-n. Astfel, o bază de tip re țea se reprezintă sub forma
unui graf orientat. Nodurile corespund entită ților, iar săge țile de la tată la fiu rela țiilor dintre
entită ți. [3]
În modelul ierarhic , schema conceptuală a bazei de date se reprezintă ca un arbore.
Nodurile reprezintă clasele de obiecte, iar arcele rela țiile dintre acestea. Acest model este
considerat a fi un caz particular al modelului re țea, în care rela țiile sunt de tipul 1 -n. Modelul
ierarhic este indicat numai atunci când datele au în mod natural o structură de arbore . [3]
I.4.2 Modelul rela țional
Apăr ut mai târziu, modelul rela țional a fost propus de către americanul Edgar F.
Codd, în 1970, în lucrarea “A relational model of large shared data banks“ [3].
Camelia Ciocan CAP. I : Baze de date. Sisteme de gestiune a bazelor de date
– 11 –
În modelul rela țional, baza de date se reprezintă printr -un grup de tabele corelate.
După cum îi sp une și numele, modelul este bazat pe rela ții, având fundamentele în teoria
matematică a rela țiilor. [2]
Noțiunea de rela ție poate fi definită astfel [2]:
Fie colec ția de mul țimi D 1, D 2,…, D n. Spunem c ă R este o relație pe aceste mul țimi, dac ă
este o mul țime de n -tuple ordonate (d 1,d2,…,d n), unde d iDi.
sau
O relație R pe mul țimile D1, D 2,…, D n este o submul țime a produsului cartezian
D1D2…Dn.
Asadar, o relație este o mul țime ce are ca elemente n -tuple.
Practic, o relație se materializează într -un tabel, iar un tuplu va fi o linie din tabel.
Corelând cu modelul E -R, un tabel reprezintă o entitate, iar o linie din tabelul respectiv o
instan ță. Coloanele tabelului sunt atributele entită ții.
Principalele caracteristici ale unei rela ții (ale unu i tabel) sunt [1]:
– într-o bază de date, o rela ție trebuie să aibă un nume distinct de al celorlalte rela ții;
– un atribut trebuie să aibă un nume distinct de al celorlalte atribute;
– într-un tuplu oarecare, un atribut are o singură valoare (valoare atomică) ;
– valoarea unui atribut trebuie să facă parte din domeniul pe care acesta a fost definit;
– ordinea în care sunt aranjate atributele într -o rela ție nu este importantă;
– nu pot exista tupluri identice;
– conținutul informa țional al rela ției nu este i nfluen țat de ordinea în care sunt aranjate
tuplurile.
În modelul rela țional se definesc restric ții, dintre care, cele mai importante sunt: de
domeniu, de atomicitate, de unicitate, referen țială și cele definite de utilizator . [1]
Restric ția de domeniu – orice valoare a unui atribut trebuie să se încadreze în domeniul
definit pentru acesta.
ex.: valoarea atributului “nume” trebuie să fie un șir de caractere, valoarea
atributului “sex” trebuie să fie din mul țimea {masculin, feminin}
Restric ția de atomicitate – orice atribut trebuie să fie atomic, în sensul că nu se poate
descompune în alte atribute.
ex.: numele unei persoane se poate descompune în nume și prenume
Camelia Ciocan CAP. I : Baze de date. Sisteme de gestiune a bazelor de date
– 12 –
Restric ția de unicitate – nu pot exista două linii indentice într -o rela ție. Cheia primară,
care p oate fi un atribut simplu sau compus, are rolul de a diferen ția un tuplu de toate celelalte
tupluri ale rela ției.
ex.: două persoane cu acela și nume pot fi diferen țiate prin codul numeric
personal
Restric ția refer ențială – valoarea unei chei străine trebui e să se regăsească printre valorile
cheii primare corespunzătoare din rela ția pe care o referă .
ex.: valoarea cheii străine “client” din rela ția COMANDĂ trebuie să se
regăsească printre valorile atributului “cod_client”, care este cheia primară a
relației CLIENT
Restric ții definite de uti lizator – reguli de validare definite de utilizator.
ex.: se poate face o regulă care să interzică unei persoane să ia căr ți cu
împrumut, dacă persoană respectivă are de restituit alte căr ți
Câteva avantaje ale modelului re lațional fa ță de modelele re țea și ierarhic sunt:
structurile de date sunt u șor de utilizat, cre ște independen ța logică și fizică, optimizează accesul
la date, îmbunătă țește integritatea și confiden țialitatea datelor . [1]
În prezent, modelul rela țional est e cel mai popular model de date și stă la baza
majorită ții SGBD -urilor. Răspândirea sa se datorează și faptului că bazele de date rela ționale
dispun de limbaje de nivel înalt pentru manipularea datelor, numite limbaje rela ționale . [1],[2]
I.5. Dezvoltare a aplica țiilor care lucrează cu ba ze de date
Într-una dintre căr țile sale, Marin Fotache face o analogie interesantă: prive ște bazele
de date ca pe ni ște rezervoare imense în care se stochează informa ții [1]. Se pot extrage și
prelucra aceste informa ții, dar putem adăuga și altele noi.
Este important ca, încă de la început, rezervoarele să fie proiectate și construite astfel
încât substan țele depozitate să nu î și piardă din caracteristici. De asemenea, trebuie ca
substan țele să poată fi sintetizate , și să s e evite pe cât posibil situa ția în care să fie necesară
schimbarea structurii rezervoarelor. Ar fi utile și filtre care să prevină introducerea de substan țe
nepotrivite .
Camelia Ciocan CAP. I : Baze de date. Sisteme de gestiune a bazelor de date
– 13 –
În paralela făcută de Marin Fotache, utilajele necesare pentru introducerea și
extrag erea substan țelor reprezintă SGBD -urile, iar cei care operează cu acestea sunt
administratorii de baze de date, programatorii și utilizatorii.
Eu aș mai adăuga și interfa ța cu utilizatorul, care ar fi panoul cu butoane, manete și
ecrane, prin care angaja ții operează utilajele pentru lucrul cu substan țe.
Pentru că o aplica ție ce lucr ează cu baze de date poate fi realizată pentru firme,
institu ții, asocia ții, organiza ții de diverse tipuri și cu activită ți diferite, voi numi în continuare
destinatarul aplica ției “firmă”, pentru a evita toată această enumerare.
Realizarea unei aplica ții care lucrează cu baze de date începe cu analiza și
proiectarea sistemelor informa ționale. Deci mai întâi se trece printr -un proces de documentare
despre firmă: domeniul de act ivitate, modul cum func ționează și ce perspective are, ce opera țiuni
și tranzac ții au loc, ce anume se dore ște să facă aplica ția, cine va utiliza aplica ția, ce limite va
avea fiecare utilizator, ce planuri de dezvoltare are firma, etc. Acestea se pot afla, de exemplu,
prin intervievarea personalului și examinarea de documente și rapoarte ale firmei [1],[3] .
După parcurgerea acestei etape, urmează proiectarea bazei de date. Acesta este un
pas foarte important deoarece o bază de date prost structurată nu va p utea fi utilizată corect. Încă
de la început trebuie avute în vedere și eventualele modificări sau adăugiri pe care firma va vrea
să le facă.
Acum se stabilesc entită țile și rela țiile dintre acestea, atributele și cheile, se
normalizează rela țiile. La fin alul acestei etape, vom știi exact structura bazei de date (schema).
Deoarece aplica ția lucrează și depinde de baza de date, se va trece la proiectarea ei
abia după crearea bazei de date. Nu sunt absolut necesare datele efective din bază, de și ar fi utile
pentru verificarea corectitudinii bucă ților de cod și a func ționării aplica ției. În etapa proiectării
aplica ției trebuie să ne asigurăm că am acoperit toate cerin țele firmei.
În cele ce urmează, voi parcurge aceste etape ale dezvoltării aplica țiilor pentr u baze
de date și voi aplica no țiunile teoretice prezentate, precum și alte no țiuni ce vor fi explicate la
momentul oportun. După cum am men ționat în introducere, am lucrat cu un exemplu concret,
real: am realizat un sistem de gestiune pentru un club sport iv.
Camelia Ciocan CAP. II : Probleme de gestiune în cadrul As. C.S. Dance Energy Bacău
– 14 –
Capitolul II
Probleme de gestiune în cadrul As. C.S. Dance Energy Bacău
După cum am precizat în finalul capitolului anterior, prima fază care trebuie parcursă
pentru realizarea unei aplica ții cu baze de date presupune documentarea. Acest capitol pr ezintă
clubul sportiv și descrie cererile pentru aplica ție.
II.1. Prezentare general ă
Clubul Sportiv Dance Energy din Bacău este o asocia ție nonprofit și
neguvernamentală, cu activitate principală în dansul sportiv. În cadrul clubului se țin cursuri de
dans pentru copii și adul ți.
La înscriere, un membru sportiv este repartizat în grupa corespunzătoare vârstei,
precum și nivelului de pregătire în dans sportiv. În timp, un sportiv poate fi transferat la o altă
grupă, în func ție de evolu ția sa și de vârst a pe care o are la momentul transferului.
În prezent, orele sunt sus ținute de către un antrenor și trei instructori.
Scopul Clubului Sportiv Dance Energy este să ini țieze cât mai multe persoane în
dansul sportiv. Clubul încurajează performan ța în acest sport și își pregăte ște membrii să
participe în competi ții locale, na ționale și interna ționale. De asemenea, sus ține și participă la
spectacole, serbări, festivaluri și alte manifestări culturale .
II.2. Modul de func ționare și cerin țele pentru aplica ție
Proiectul presupune realizarea unui sistem de gestiune pentru clubul de dans sportiv
prezentat. Pentru a urmări mai u șor, am împăr țit proiectul în mai multe păr ți.
Camelia Ciocan CAP. II : Probleme de gestiune în cadrul As. C.S. Dance Energy Bacău
– 15 –
II.2.1 Membrii sportivi, prezen ța și cotiza țiile
Clubul Dance Energy are un număr de sporti vi înscri și, număr în continuă cre ștere.
De aceea, este necesară eviden ța acestora. La înscriere, fiecare sportiv completează o fi șă cu date
personale. Sportivii minori trebuie să completeze și date despre părin ți / tutori.
Sportivii pot fi prezen ți la to ate, o parte sau niciuna din orele grupei de care apar ține.
Instructorii țin o prezen ța, în func ție de care se calculează valoarea cotiza ției lunare ce trebuie
plătită de fiecare membru. Cotiza ția pentru o luna este de 60 lei.
Se cere:
a) eviden ța membrilo r sportivi
– vizualizarea datelor despre sportivi;
– introducerea unui nou sportiv;
– modificarea datelor unui sportiv.
b) eviden ța încasărilor din cotiza ții
– introducerea de noi încasări ;
– vizualizarea încasări lor efectuate ;
c) eviden ța prezen țelor fiec ărui sportiv
– introducerea prezen țelor;
– vizualizarea prezen țelor sportivilor.
II.2.2 Grupe și instructori
Sportivii clubului sunt împăr țiți în func ție de nivelul de pregătire în dans sportiv, dar
și pe grupe de vârstă. În momentul de fa ță există trei g rupe de ini țiere, trei de intermediari și
două de avansa ți, împăr țiți pe grupe de vârstă.
Fiecare grupă respectă un program, care se poate schimba periodic. Clubul are în
vedere extinderea sa, astfel că la un moment dat vor fi două sau mai multe săli, în care să î și
desfă șoare activitatea (în acela și timp) grupe diferite.
În timp, numărul de grupe poate să crească, dar și să scadă (de exemplu, dacă se
unesc două grupe). De asemenea, numele/denumirea grupei se poate schimba.
În cadrul clubului există câ țiva instructori și antrenori (numi ți general: instructori),
fiecare având repartizate câte una sau mai multe grupe. Însă, la un moment dat, un instructor
poate s ă nu predea niciunei grupe sau se poate ca instructorul unei grupe să fie schimbat.
Camelia Ciocan CAP. II : Probleme de gestiune în cadrul As. C.S. Dance Energy Bacău
– 16 –
Se cere:
a) eviden ța grupelor
– vizualizarea datelor despre grupe (program, membrii, instructor );
– introducerea unei grupe noi;
– modificarea datelor unei grupe.
b) eviden ța instructorilor
* obs evatia 1 : datele care intereseaza despre instructori sunt similare cu ce le ale
membrilor sportivi, adaug ându-se câteva informa ții în plus.
* obs ervatia 2 : licen ța de instructor se poate ob ține de la v ârsta de 16 ani.
– vizualizarea datelor despre instructori ;
– introducerea unui instructor nou;
– modificarea datelor unui inst ructor.
II.2.3 Concursuri și rezultate
Unii sportivi ai clubului, în special cei de la grupele avansate, pot trece la sportul de
performan ță, începând să participe în concursuri oficiale na ționale, recunoscute de către federa ția
de profil (FRDS3 – Federa ția Rom ână de Dans Sportiv) .
Evidenta concursurilor si rezultatelor obtinute de sportivii clubului vor urma regulile
FRDS.
Reguli ale Federa ției Român e de Dans Sportiv [6]
Un dansator are dreptul de a participa într -o competi ție dacă: are carnet de concurs, a
achitat cotiza ția anuală către federa ție și are viza medicală valabilă. Viza medicală esta valabilă 6
luni de la data acordării.
Clasele valorice sunt, în ordine: Hobby, E, D, C, B, A, S. Clasa Hobby este singura
la care nu se acordă puncte competi ționale. La clasă S se acordă puncte de ranking (care plasează
dansatorii într -un clasament de nivel interna țional). O pereche va participa la clasa
corespunzătoare partenerului mai avansat .
Categoriile de vârstă sunt Copii I (până la 9 ani), Copii II (10 -11 ani), Juniori I (12 –
13 ani), Juniori II (14 -15 ani), Tineret (16 -18 ani), Adul ți (19-35 ani) și Seniori (peste 35 de ani).
Se ia în considerare vârsta împlinită în anul desfă șurării competi ției la care participă sportivul. Se
permite unirea grupelor Copii I cu Copii II, Juniori I cu Juniori II sau Tineret cu Adul ți.
3 FRDS = Federa ția Rom ână de Dans Sportiv
Camelia Ciocan CAP. II : Probleme de gestiune în cadrul As. C.S. Dance Energy Bacău
– 17 –
O pereche poate concura la o categorie de vârstă superioară în cazul în care la acea
competi ție în ziua respectivă nu se organizează categoria ei de vârstă. Copiii nu pot dansa la
categoria Juni ori.
La toate categoriile de vârstă, excep ție făcând Seniorii, unul din parteneri poate fi
mai tânăr. Seniorii pot participa în competi țiile de adul ți cu excep ția Campionatului Na țional și
Cupei României. Deci, o pereche va participa la categoria de vârstă corespunzătoare partenerului
mai în vârstă.
Promovarea dansatorilor în clase superioare se realizează prin acumularea de puncte
competi ționale. În momentul legitimării, sportivul este considerat de clasă Hobby. Dacă un
dansator de Hobby ob ține 2 prezen țe de clasificare (locul I dacă concursul începe din finală,
podium dacă începe din semifinale sau sferturi, finală dacă începe din optimi sau mai mult), va
trece în mod automat în clasă E. De asemenea, un dansator de Hobby trece automat în clasă E în
momen tul participării la o competi ție de clasă superioară (E, D, etc.).
Necesarul de puncte și finale pentru celelalte clase este prezentat în tabelul de mai
jos:
Tabelul II.1. Puncte și finale necesare pentru avansarea în clasă
CLASA PUNCTE
(minim 5 competi ții) FINALE
din cls. E in cls. D 200 3
din cls. D in cls. C 180 5
din cls. C in cls. B 150 5
din cls. B in cls. A 150 5
din cls. A in cls. S 150 5
În funcție de vârstă, dansatorii pot înainta în clasă numai până la un anumit nivel:
Tabelul II.2. Clas ele maxime pe vârstă
VÂRSTA NIVEL MAX. (CLS.)
6-9 D
10-11 C
12-13 B
14-15 A
peste 16 S
Perechilor participante la o competi ție li se acordă un număr de puncte echivalent cu
numărul de perechi întrecute în competi ția respectivă. Punctajul ob ținut de o pereche într -un
concurs reprezintă punctajul ob ținut de fiecare partener în parte, la clasa valorică în care este
încadrat, la sec țiunea (standard, latino, mixt) la care a participat perechea .
Camelia Ciocan CAP. II : Probleme de gestiune în cadrul As. C.S. Dance Energy Bacău
– 18 –
La Campionatele Na ționale, la concursurile interna ționale IDSF4, Cupe Mondiale,
Campionate Mondiale și Europene se acordă un număr dublu de puncte. La Cupa României se
vor acord a în plus 75% din numărul de puncte, iar la Campionatele de Clasă 50% din numărul de
puncte.
Numărul punctelor cumulate într -o clasă se calcu lează separat pentru Standard și
Latino. Punctele de la sec țiunea Mixt se adună la fiecare din celelalte două sec țiuni.
Se cere eviden ța concursurilor și rezultatelor :
– introducerea rezultatelor ob ținute de sportivi;
– vizualizarea concursurilor și rezul tatelor la care au participat sportivii;
– calcularea automată a punctajelor sportivilor, precum și a claselor valorice și de vârstă;
– atenționarea utilizatorilor atunci când sportivii se apropie de avansarea în clasă valorică
(mai au cel mult 30 de pun cte și o finală);
– atenționarea utilizatorilor atunci când se apropie termenul de expirare a vizei medicale .
4 IDSF = International DanceSport Federation (Federatia Internationala de Dans Sportiv)
Camelia Ciocan CAP . III : Software de gestiune pentru cluburi sportive
– 19 –
Capitolul III
Software de gestiune pentru cluburi sportive
Pe pia ță interna țională, dar și cea na țională, există produse software pentru gest iunea
cluburilor sportive. Unele sunt mai complexe, altele mai simple. În cele ce urmează, voi prezenta
trei astfel de aplica ții.
III.1. SalaVB
SalaVB este o aplica ție dedicată cluburilor sportive (săli de fitness, aerobic) și
cabinetelor de masaj și de r ecuperare fizică [7]. Acest soft este un produs de pe pia ța
românească .
Cu ajutorul acestei aplica ții se poate ține eviden ța clien ților, gestionarea
abonamentelor și prezen țelor, gestiunea stocului de produse de ținut de firmă, un clasament (top)
al clien ților în func ție de prezen țe pentru posibila acordare de bonusuri. De asemenea, se poate
ține un registru de casă cu încasările și plă țile efectuate și se pot imprima chitan țe și bonuri
fiscale direct din aplica ție. Aplica ția mai oferă posibilitatea listării de rapoarte diverse .
SalaVB mai îndepline ște niște func ții interesante, mai speciale, mai complexe și care
implică și alte echipamente, în afară de calculator: case de marcat, camere web, scannere pentru
coduri de bare, cititoare de proximitate, imprimant e de carduri PVC.
La operarea unei vânzări, aplica ția generează automat un bon fiscal care va fi
imprimat printr -o casă de marcat.
Cititoarele de proximitate pot folosi pentru operarea intrărilor și ieșirilor din sală. La
citirea datelor din tr-un breloc trecut prin dreptul cititorului, poate în mod automat să înregistreze,
de exemplu, o preze nță abonatului. Scannerul pentru coduri de bare poate avea aceea și func ție,
putând ac ționa ridicarea unei bariere sau deschiderea unei yale electrice. În plus, prin c itirea
codurilor de bare de pe cardul de client se pot opera și încasări.
Aplica ția mai permite preluarea de poze prin intermediul unei camere web, dar și
generarea de carduri PVC .
Camelia Ciocan CAP . III : Software de gestiune pentru cluburi sportive
– 20 –
III.2. Sport Club
O aplica ție de pe pia ța interna țională este Sport Club [8].
Înregistrarea de membrii noi și vizualizarea datelor celor deja înscri și, clasificarea lor
după diverse criterii sunt func ții care țin de gestionarea membrilor și nu lipsesc nici din această
aplica ție. În plus, Sport Club oferă posibilitatea de a im prima plicuri care să fie trimise apoi către
membrii, dar și de a trimite mesaje pein e -mail sau de a telefona direct din cadrul aplica ției.
Latura financiară nu este lăsată deoparte. Se pot opera încasări și lista rapoarte
privind taxele și cotiza țiile p lătite sau datoriile membrilor.
Un aspect important omis de alte softuri din acest domeniu, dar care este oferit de
Sport Club, este cel al competi țiilor. Această aplica ție permite înregistrarea de echipe, jucători și
antrenori, introducerea și vizualizar ea programelor competi țiilor, dar și a rezultatelor.
De asemnea, acest prin acest soft se poate ține eviden ța sponsorilor și se pot
înregistra și imprima articole cu noută ți din cadrul sau din afara clubului.
În plus, Sport Club oferă un modul separat, S port Club Plus, prin care anumite date
pot fi accesate online .
III.3. FirmPOS
FirmPOS este un soft american mai complex, dar care poate servi și alte tipuri de
organiza ții, nu doar cluburi sportive [9]. Ar putea fi folosit cu succes și într -un centru de
înfrumuse țare. Aplica ția îndepline ște, în general, acelea și func ții ca și cele prezentate mai sus.
Tine eviden ța membrilor, dar ace știa pot avea mai multe abonamente la un moment
dat, pentru diverse servicii. Ce este mai interesant este faptul că de abonam entul unui client pot
beneficia mai mul ți membrii ai familiei clientului respectiv. Sau, se pot face abonamente, care,
atunci când expiră, creează automat un alt abonament. De asemenea, programul anun ță când un
abonament a expirat, când este ceva în neregu lă cu un cont al unui client sau când cineva are
datorii. Aplica ția oferă și posibilitatea ca un abonament să poată fi folosit doar în anumite zile
ale săptămânii sau ale lunii.
FirmPOS pune la dispozi ție un creator de carduri de clien ți, cu coduri de bar e. Cu
ajutorul acestora se operează intrările și ieșirile clien ților din incintă sau dintr -o anumită zonă a
clădirii și se ocupă automat de înregistrarea prezen țelor din abonamente. În plus, are suport
pentru detectarea membrilor prin amprentă pentru a evi ta folosirea cardurilor altor membrii.
Camelia Ciocan CAP . III : Software de gestiune pentru cluburi sportive
– 21 –
În func ție de tipul abonamentului de ținut, un client poate beneficia de reduceri pentru
anumite servicii sau produse. și aceste bonusuri pot fi aplicabile doar în anumite perioade sau
zile din an, lună sau săptămână.
Programul permite achitarea abonamentelor sau produselor și prin card bancar.
Pentru situa țiile în care membrii pot achizi ționa produse, se pot defini butoane pentru
introducerea rapidă a anumitor produse sau grupuri de produse în “coșul de cump ărături” al
clientului. Această func ție este utilă dacă s -a constatat că se cumpără foarte des un anumit
produs, sau o anumită comb inație de produse.
Aplica ția FirmPOS poate crea calendare și programe. Clien ții pot face progr amări la
o anumită oră, într -o zi specif icată, la instructorul sau maseurul preferat. FirmPOS va avea grijă
să nu se suprapună programările pentru aceea și sală, acela și instructor sau client.
Acestea sunt câteva dintre cele mai complexe func ții ale aplica ției FirmPOS. Pe
lângă acestea, programu l generează rapoarte, contracte, chitan țe, etc .
III.4. Software pentru clubu ri de dans sportiv
Aplica țiile prezentate în acest capitol sunt generale, în sensul că pot fi folosite nu
doar de cluburi sportive. Se observă că toate au câteva func ții comune: e viden ța membrilor,
încasărilor și prezen țelor. Acestea sunt și cerin țele tututor cluburilor sportive pentru soft -urile de
gestiune.
Func țiile suplimentare oferite de unele programe sunt utile pentru orice club. Altele
sunt prea avansate pentru activitatea , dimensiunea sau posibilită țile unui club de dans sportiv . De
exemplu, la ora actuală și chiar nici în viitorul apropiat, nu vom avea în țară cluburi de dans
sportiv atât de dezvoltate încât să fie necesare carduri de membr u cu coduri de bare pentru
accesul în sală. Această func ție ar putea fi totu și aplicabilă la o sală de fitness. Pe de altă parte,
generarea de chitan țe și contracte ar fi de ajutor .
Aplica țiile prezetate nu se pliază pe modul de organizare și pe necesită țile clubului
meu de dans sportiv . Îmi trebuie un soft care să se ocupe mai mult de partea competi țională. Un
club cu activitate în sportul de performan ță își îndreaptă aten ția mai mult spre sus ținerea
sportivilor în competi ții decât spre investi ții în carduri de acces sau alte echipament e sofisticate,
precum cele necesare soft-utilor prezentate .
Camelia Ciocan CAP . IV : Proiectarea sistemului DSC -Base
– 22 –
Capitolul IV
Proiectarea sistemului DSC -Base
În primul capitol al lucrării, la subpunctul I.5, am descris etapele parcurse în
realizarea unei aplica ții care lucrează cu baze de date. Prima etap ă, cea a documentării, a fost
parcursă în capitolul al doilea. Urmatorea este cea a proiectării bazei de date, după care trecem la
realizarea interfe ței aplica ției.
IV.1. Normalizarea rela țiilor
Proiectarea bazei de date presupune crearea schemei bazei de date: stabilirea
entită ților, atributelor și a rela țiilor dintre entită ți. Aceste no țiuni teoretice au fost tratate în
primul capitol, la subpunctul I.3. Urmează normalizarea rela țiilor, care se încadrează în aceea și
etapă de proiectare a schemei .
IV.1.1. Dependen țe de date
În teoria bazelor de date rela ționale apare no țiunea de “dependen ță a datelor”.
Aceasta se referă la faptul că între atributele unei entită ți sau a două entită ți diferite pot exista
legături logice. Aceste legături influen țează opera țiunile efectuate în timpul utilizării bazei de
date: adăugări, ștergeri, actualizări de date. Există dependen țe func ționale, multivalorice și de
uniune . [2]
Spunem c ă un atribut A 1 este dependent func țional de atributul A 2 dacă și numai
dacă fiecare valoare a lui A 1 este asociat ă exact cu o valore a lui A 2. Vom nota A1→A2 și
spunem c ă A1 este determinant al lui A 2, sau c ă A1 determin ă pe A 2. [3]
Dependen țele func ționale sunt determinate prin analiza mediului real. De exemplu, o
mașină are un singur număr de înmatriculare, iar un număr de înmatriculare corespunde unei
singure ma șini: număr înmatriculare → mașină.
Camelia Ciocan CAP . IV : Proiectarea sistemului DSC -Base
– 23 –
Fie rela ția R {A 1,A2,…,A n} și X, Y si Z trei subansambluri de atribute ale
ansamblului {A 1,A2,…,A n}. Între X și Y exist ă o dependen ța multivaloa re dacă și numai dac ă
pentru fiecare valoare a lui X pot fi asociate una sau mai multe valori ale lui Y, iar aceast ă
asociere este independent ă de valorile lui Z. Not ăm X→→Y sau X→→Y|Z și spunem c ă
atributul Y este multidependent fa ță de atributul X sau c ă atributul X multidetermin ă pe Y. [1]
De exemplu, unui curs i se poate asocia o mul țime de perechi de ore și săli, care nu
depind de alte informa ții precum profesorul care ține cursul respectiv sau studen ții care se
prezintă [3].
Spunem c ă relația R satisf ace dependen ța de uniune , notat ă *(R 1,R2,…,R n), dac ă si
numai dac ă R este egal ă cu uniunea proiec țiilor sale pe R1, R2,…, Rn, unde acestea din urma sunt
submul țimi ale lui R. [3]
IV.1.2. Form e normale
Normalizarea presupune aplicarea unui set de regu li asupra unei baze de date, mai
exact, asupra relațiilor. Obiectivele normalizării sunt [1],[2] :
– minimizarea spa țiului necesar pentru stocarea datelor;
– ameliorarea integrită ții datelor prin reducerea red undan ței și a inconsisten ței;
– îmbunătă țirea structurii bazei;
– scăderea necesită ții de a reorganiza periodic modelul bazei .
Prima formă normală (FN1) – o rela ție se află în FN1 dacă și numai dacă toate
atributele sale au numai valori atomice. [2]
FN1 cere să nu existe atribute compuse și grup uri repetitive de atribute. A șadar,
fiecare atribut trebuie să aibă câte o singură valoare pentru fiecare instan ță a unei entită ți. Pentru
eliminarea grupurilor repetitive de atribute, acestea trebuie puse într -o nouă entitate care se va
afla în rela ție de 1-M cu entitatea originală. [4]
Descompunerea atributelor astfel încât să ia doar valori atomice este discutabilă [1].
De exemplu, “adres ă” este un atribut non -atomic, putându -se descompune în: “strad ă”, ”num ăr”,
”bloc”, “scară”, “etaj”, “apartament”. A ceastă descompunere ar putea fi utilă unei companii de
telefonie sau de cablu TV, dar pentru o firmă de produc ție nu este necesară .
A doua formă normală (FN2) – o rela ție se află în FN2 dacă este în FN1 și toate
atributele sale sunt dependente de cheia pri mară. [3]
Camelia Ciocan CAP . IV : Proiectarea sistemului DSC -Base
– 24 –
Problema trecerii unei rela ții de la FN1 la FN2 se pune când cheia primară este
compusă din mai multe atribute. A două și a treia formă normală au ca scop eliminarea
dependen țelor func ționale.
Pentru a trece din FN1 în FN2 se construie ște o r elație nouă, care să cuprindă acele
atribute care sunt dependente doar de o parte a cheii primare (dependen țe par țiale) și se înlătură
aceste atribute din rela ția originală . [3]
A treia formă normală (FN3) – o rela ție se află în FN3 dacă este în FN2 și niciun
atribut neprim (care nu este cheie primară) nu depinde func țional de un alt atribut neprim. [2]
O rela ție poate trece din FN2 în FN3 construindu -se o nouă rela ție care să cuprindă
atributele care nu depind direct de cheia primară a rela ției originale . [3]
Forma normală Boyce -Codd (FNBC) – o rela ție R se află în FNBC dacă pentru
orice dependen ță func țională X→A din cadrul R, unde A nu face parte din X, atributul X (care
poate fi compus) este sau include o cheie din R. [2]
Altfel spus, niciun atribut pr im sau neprim nu poate depinde funcțional de un alt
atribut care nu este o cheie, sau care nu con ține o cheie. Putem spune că o rela ție în FNBC este și
în FN3, dar reciproca nu este valabilă.
Nu există întotdeauna descompuneri echivalente în rela ții afl ate în FNBC. Această
formă normală este prea restrictivă pentru a fi aplicată în toate situa țiile pentru că se pot pierde
dependen țele func ționale ale rela ției originale . [2]
A patra formă normală (FN4) – o rela ție R este în FN4 dacă oricare ar fi
dependen ța multivalorică X→→Y , unde Y nu este un subset al lui X si XY nu con ține toate
atributele lui R, atributul X este sau con ține o cheie a lui R . [2]
După cum se observă, a patra formă normală tratează dependen țele multivalorice,
spre deosebire de FN2, FN3 și FNBC, care referă la dependen țe func ționale. O dependen ță
funcțională este un caz particular de dependen ță multivalorică. Astfel, deducem că o rela ție în
FN4 este și în FNBC, aceasta din urmă fiind mai pu țin restrictivă.
Asemănător cu FNBC, pentru FN4 nu există întotdeauna o descompunere care să
păstreze dependen țele func ționale și multivalorice ale rela ției originale .
A cincea formă normală (FN5) – o rela ție R este în FN5 dacă și numai dacă orice
dependen ță de uniune *(R 1,R2,…,R n) a relației R este o consecin ță a unei chei candidat a rela ției
[3]. Cu alte cuvinte, fiecare dintre rela țiile R1, R2,…, Rn include o cheie candidată a lui R.
FN5 elimină rela țiile M -M, diminuând redundan ța datelor.
Camelia Ciocan CAP . IV : Proiectarea sistemului DSC -Base
– 25 –
În viziunea lui Marin Fotache, normalizarea unei ba ze de date rela ționale poate fi
imaginată astfel: pornim de la o rela ție ini țială universală R și apoi facem descompuneri
succesive ale acesteia. Astfel ob ținem subrela ții ale rela ției R, din care aceasta poate fi
reconstruită prin opera ții de jonc țiune [1 ].
În cele mai multe cazuri, a treia formă normală este suficientă, iar uneori chiar și
doar a doua formă normală [3].
IV.2. Evoluția bazei de date
Am numit aplicația creată “DSC -Base”. Denumirea este în engleză și vine de la
“dancesport club”, care înse amnă club de dans sportiv, și “base” (database), care înseamnă bază
(de date).
În capitolul al doilea, am realizat împărțirea proiectului în mai multe părți, pe care le
voi numi în continuare “probleme”. În cele ce urmează, voi parcurge rezolvarea probleme lor, în
ordine, ilustrând evoluția bazei de date . Am încercat să dau entităților și atributelor nume cât mai
sugestive, pentru a nu fi nevoie să explic semnificația lor, acestea fiind destul de numeroase .
În descrierea relațiilor dintre entități am folosit notații care să evidențieze
opționalitatea (prin subliniere) și cardinalitatea acestora (prin litere italice). Numele e ntităților
le-am scris cu majuscule, iar pe cele ale tabelelor cu litere italice .
Pentru reprezentarea grafică am ales metoda propusă d e Oracle [4]. Relațiile
opționale sunt marcate prin linie punctată, iar cele obligatorii prin linie continuă. Atributele sunt
notate astfel: cele obligatorii cu *, iar cele opționale cu O, cheile primare sunt notate cu #, iar cele
străine cu fk (din englez ă: “foreign key”).
Problema 1 . Membrii sportivi, prezența și cotizațiile
Plecăm de la un singur tabel, în care vom avea date despre membrii sportivi ai
clubului ( Sportivi ). Informațiile pe care clientul dorește să le știe despre un sportiv sunt cele
regăsi te pe fișa de înscriere : date de identificare și date de contact.
Se remarcă existența unei secțiuni, adresate doar minorilor, în care se solicită detalii
despre părinții/tutorii cursantului. Există situații în care doi sau mai mulți sportivi sunt frați.
Aceștia au aceeași părinți. Atunci, vom crea un al doilea tabel ( Părinți ), cu date despre părinți,
pentru a evita repetarea informațiilor în baza de date.
Camelia Ciocan CAP . IV : Proiectarea sistemului DSC -Base
– 26 –
De asemenea, în cazul fraților vom vorbi despre aceeași adresă. Presupunem că mai
adugam un tabel cu adrese ( Adrese ). Însă pentru a identifica un rând din acest tabel, vom avea
nevoie de o cheie primară compusă care va cuprinde toate coloanele tabelului. Iar pentru a stabili
relația dintre Sportivi și Adrese , cheia primară a tabelului Adrese va deveni ch eie străină în
tabelul Sportivi . Astfel, vom avea date introduse de două ori.
Renunțăm, deci, la tabelul Adrese . Vom lăsa adresa ca și atribut al entității
SPORTIV, fără a -l descompune în atributele atomice “ stradă”, ”număr”, ”bloc”, “scară”, “etaj”,
“apartament” , făcând o abatere de la regula impusă de FN1.
Definirea relației SPORTIV – PĂRINTE (Figura IV.1) :
Un SPORTIV poate avea unul sau mai mulți PĂRINȚI.
Un PĂRINTE trebuie să fie al unuia sau al mai multor SPORTIVI .
Figura IV.1. Relația SPORTIV – PĂRINTE
Între cele două entități avem o relație M -M. Spargem relația, utilizând o nouă entitate
(de joncțiune) PĂRINTE_SPORTIV, care se va afla în relație 1 -M cu ambele entități și respectă
FN3. În Figura IV.2, am precizat doar at ributele tabelului de joncți une:
Figura IV.2. Entitatea de joncțiune PĂRINTE_SPORTIV
În tabelul Prezențe se notează prezența sportivilor pentru fiecare zi în care grupa de
care aparțin are cursuri. Apare o relație M -M, pentru că un sportiv vine în mai multe zile la ore,
iar la o or ă se prezintă mai mulți sportivi. Mai mult decât atât, în Prezențe vor exista mai multe
înregistrări cu aceeași dată, care acum este cheie primară.
Definirea relației SPORTIV – PREZENȚĂ (Figura IV.3):
Un SPORTIV poate avea una sau mai multe PREZENȚE.
O PREZENȚĂ trebuie să cuprindă unul sau mai mulți SPORTIVI.
Atributul “prezent” indică dacă un sportiv a fost prezent sau absent.
Camelia Ciocan CAP . IV : Proiectarea sistemului DSC -Base
– 27 –
Figura IV.3. Relația SPORTIV – PREZENȚĂ
Entitatea de joncțiune PREZENȚĂ_SPORTIV sparge relația. Dacă mutăm atributul
“prezent” în noul tabel, Prezențe -Sportivi va fi în continuare în FN3, deoarece prezența sau
absența sportivului indicat de “sp_id” în ziua indicată de “data” determină valoarea atributului
“prezent” (Figura IV.4). Pentru simplitate, redenumim noua entitate PR EZENȚĂ (Figura IV.5).
Figura IV.4. Relația SPORTIV – PREZENȚĂ
Figura IV.5. Noua relație SPORTIV – PREZENȚĂ
Cotizațiile se plătesc lunar și au, în general, aceeași valoare. În funcție de situațiile
apărute, într -o lună valoarea cotizației poate fi mai mică sau mai mare. În tabelul Cotizații vom
ține evidența acestor valori pentru fiecare lună.
Un sportiv poate achita, în același timp mai multe cotizații, sau poate plăti în tranșe
pentru aceeași lună :
O CHITANȚĂ trebuie să acopere una sau mai multe COT IZAȚII.
O COTIZAȚIE trebuie achitată cu una sau mai multe CHITANȚE.
Avem din nou o relație M -M, între CHITANȚĂ și COTIZAȚIE, pe care o eliminăm
cu entitatea CH_CTZ (Figura IV.6) . Spre deosebire de situația prezențelor, în cazul de față nu
putem muta atri butul “val_ctz” în noul tabel, deoarece valoarea acestuia nu are niciun fel de
legătură cu numărul chitanței.
Camelia Ciocan CAP . IV : Proiectarea sistemului DSC -Base
– 28 –
Figura IV.6. Entitatea de joncțiune CH_CTZ
Definirea relației SPORTIV – CHITAN ȚĂ (Figura IV. 7):
Un SPORTIV poate primi una sau mai multe CHITA NȚE.
O CHITAN ȚĂ trebuie eliberat ă pentru un singur SPORTIV.
Aceast ă relație are cardinalitate 1 -M.
Figura IV.7. Relația SPORTIV – CHITANȚĂ
În Figura IV.8 este prezentat ă diagrama E -R pentru prima problem ă:
Figura IV.8. Diagrama E -R pentru prima problem ă
Problema 2. Grupe și instructori
Pentru evidența instructorilor, am putea crea un nou tabe l. Însă cele două observații
din capitolul al doilea, subpunctul II.2.2.b), sugerează că putem stabili o relație supertip -subtip.
MEMBRU va fi supertip, iar SPORTIV și INSTRUCTOR vor fi subtipuri (Figura IV.9 ).
Atributele comune sportivilor și instructorilor sunt înglobate în entitatea MEMBRU, SPORTIV
și INSTRUCTOR cuprinzând doar atributele specifice.
Figura IV.9. Diagrama E -R pentru prima problemă
Camelia Ciocan CAP . IV : Proiectarea sistemului DSC -Base
– 29 –
Un membru poat e fi ori sportiv ori instructo r, lucru specificat de coloana
“tip_membru” din tabelul Membrii .
În urma acestei transformări, relațiile entității SPORTIV cu PREZENȚĂ și
CHITANȚĂ rămân neschimbate, în timp ce relația cu PĂRINTE este transferată către
MEMBRU , pentru c ă și instructorii pot fi minori . Apar modificările arătate de Figura IV.10:
Figura IV.10. Entitatea de joncțiune PĂRINTE_MEMBRU
Tabelul Grupe conține detaliile legate de gr upele formate la un moment dat,
entitatea PROGRAM descrie orarul unei grupe , iar ORE tine evidența num ărului de ore pe care
le-a avut o grup ă într-o lun ă. GRUPA se află în relaț ie 1-M cu SPORTIV, INSTRUCTOR,
PROGRAM si ORE :
Un SPORTIV poate să aparțină unei singure GRUP E.
O GRUPĂ poate să aibă unul sau mai mulți SPORTIVI.
Un INSTRUCTOR poate să predea uneia sau mai multor GRUPE.
O GRUPĂ trebuie să fie condusă numai de un INSTRUCTOR.
O GRUPĂ trebuie să aibă unul sau mai multe PROGRAME.
Un PROGRAM trebuie să fie al unei singure GRUPE .
O GRUPĂ trebuie să aibă unul sau mai m ulte PROGRAME.
Un PROGRAM trebuie să fie al unei singure GRUPE .
În Figura IV.11 (pag. 30) este prezentat ă în noua diagram ă E-R.
Problema 3. Concursuri și rezultate
Pentru a cuprinde datele problemei, vom crea trei tabele noi: CARNET și
REZULTAT, plecând d e la modelul unui carnet de concurs.
Relația MEMBRU – CARNET este de cardinalitate 1 -1:
Un MEMBRU poate avea un singur CARNET.
Un CARNET trebuie să aparțină unui singur MEMBRU.
Camelia Ciocan CAP . IV : Proiectarea sistemului DSC -Base
– 30 –
Figura IV.11. Diagrama E -R după rezolvarea problemei 2
Definirea relației CARNET – REZULTAT , de cardinalitate 1 -M:
Un CARNET poate conține unul sau mai multe REZULTATE.
Un REZULTAT trebuie să se găsească pe un singur CARNET.
Relația REZULTAT – CONCURS este de cardinalitate 1 -M:
Un REZULTAT trebuie să corespund ă unuia sau ma i multor CONCURSURI.
Un CONCURS trebuie să aibă unul sau mai multe REZULTATE.
Figura IV.1 2 (pag. 31) prezintă noua diagramă E -R, actualizat ă după rezolvarea
problemei 3.
Utilizatorii aplica ției
Pentru a folosi aplicația va fi nevoie de un nume de utilizato r și de o parolă.
Utilizatorii sistemului de gestiune vor fi: casierii, instructorii, secretarii și antrenorii. Aceștia vor
avea drepturi limitate pentru utilizarea aplicației. Deși secretarii și antrenorii vor avea aceleași
permisiuni, numirea lor separat ă ca și tip de utilizator este strict pentru diferențierea funcțiilor în
cadrul clubului. Vom crea un nou tabel: Utilizatori .
Camelia Ciocan CAP . IV : Proiectarea sistemului DSC -Base
– 31 –
Figura IV.12. Diagrama E -R după rezolvarea problemei 3
În Tabelul IV.1 se pot vedea drepturile fiecărui tip de utilizator, asup ra datelor din
tabelele bazei de date .
Tabelul IV.1. Drepturile utilizatorilor
CASIER INSTRUCTOR SECRETAR și ANTRENOR
Membrii,
Părinți vizualizare (f ără detalii) vizualizare, ad ăugare vizualizare, ad ăugare, modificare
Prezente ,
Ore vizualizare vizualiza re, ad ăugare vizualizare, ad ăugare
Chitan țe vizualizare, ad ăugare vizualizare, ad ăugare vizualizare, ad ăugare
Cotiza ți vizualizare vizualizare vizualizare, ad ăugare, modificare
Grupe,
Program vizualizare vizualizare vizualizare, ad ăugare, modificare
Carnete,
Rezultate ,
Concursuri vizualizare vizualizare vizualizare, ad ăugare, modificare
Camelia Ciocan CAP . IV : Proiectarea sistemului DSC -Base
– 32 –
Doar membrii clubului pot utiliza aplicația. Deci putem relaționa tabelul Utilizatori
cu Membrii , dar și cu Chitanțe , deoarece aceștia sunt cei care le pot elibera și v or fi trecuți ca și
casieri pe chitanțe.
Definirea relației UTILIZATO R – MEMBRU, de cardinalitate 1 -1:
Un UTILIZATOR trebuie să fie (un) MEMBRU.
Un MEMBRU poate să fie (un) UTILIZATOR.
Relației UTILIZATOR – CHITANȚĂ, are cardinalitate 1 -M:
Un UTILIZAT OR poate elibera una sau mai multe CHITANȚE.
O CHITANȚĂ trebuie să fie eliberată de un (singur) UTILIZATOR.
Diagrama E -R final ă, cu entit ăți și atribute, este prezentat ă în Figura IV.13 (pag. 33) .
Baza de date a sistemului DSC -Base respect ă regulile impu se de FN3.
IV.3. Implementarea bazei de date cu MySQL
Înainte de a crea efectiv baza de date trebuie să alegem domeniile atributelor.
Acestea trebuie să se potrivească cu datele pe care le conțin.
Menționez că în continuare am folosit numele atributelor și tabelelor așa cum sunt
ele în baza de date.
MySQL suportă tipuri de date pentru date numerice, șiruri de caractere și tipuri
speciale pentru dată (calendaristică) și timp [10]. Dintre acestea, pentru baza de date a aplicației
DSC -Base am folosit următo arele: INT, CHAR, VARCHAR, ENUM, DATE, TIME și YEAR.
Tabelul IV.2 (pag. 34) arată atributele și domeniile lor, așa cum au fost implementate
cu MySQL, în cazul entității MEMBRU.
Majoritatea tabelelor au cheile primare de tipul INT, pentru a lucra mai ușor cu
acestea (sortări, selectarea celei mai mici sau a celei mai mari valori, etc.). Un alt avantaj este
folosirea op țiunii AUTO_INCREMENT [10]: u nei coloane de tip INT i se va atribui automat o
valoare la efectuarea unei operațiuni INSERT. Funcția adaugă 1 la ultima valoare (cea mai mare)
întâlnită în coloana respectivă. Astfel, nu mai trebuie introduse manual cheile și se evită apariția
rânduri lor cu aceeași cheie primară .
Camelia Ciocan CAP . IV : Proiectarea sistemului DSC -Base
– 33 –
Figura IV.13. Diagrama E -R a bazei de date
Camelia Ciocan CAP . IV : Proiectarea sistemului DSC -Base
– 34 –
Tabelul IV.2. Membrii – tipurile atribut elor
ATRIBUT TIP
# id_mem int (6)
* tip_mem enum ('sportiv','instructor')
* d_mem date
* nume varchar (30)
* prenume varchar (30)
* d_nastere date
* loc_nastere varchar (30)
* sex enum („F‟,‟M‟)
* cnp char (13)
* adresa varchar (60)
* loc varch ar (30)
* jud varchar (30)
* tel char (10)
O tel2 char (10)
O mail varchar (50)
O alte_date varchar (100)
Tipurile CHAR și VARCHAR sunt pentru șiruri de caractere. Între paranteze se
specific ă lungimea maxim ă a șirului de caractere. Diferența dintre acestea este că CHAR are
lungime fixă, iar VARCHAR nu. De fapt, deosebirea este la nivelul spațiului de memorie
(Tabelul IV.3) [10].
Tabelul IV.3. Spatiul de memorie ocupat de sirurile de caractere
TIPUL DE DATE SPATIU DE MEMORIE NECESAR
varchar 1 octet + lungimea sirului dat (in octeti)
char lungimea declarata (in octeti) numarul de octeti necesari pentru
caracterul de lungime maxima din setul de caractere
De exemplu, în tabelul “membrii”, “nume” poate avea lungimea de 30 de caractere și
va ocupa 3 1 de octeți, dar poate avea și doar 10 caractere, caz în care va ocupa 11 octeți. În
schimb, “cnp” va ocupa întotdeauna 13 octeți, chiar dacă lungimea șirului introdus va fi mai
mică de 13 caractere.
ENUM este un tip de date tot pentru șiruri de caractere. Acesta ocupă doar unul sau
doi octeți, în funcție de numărul de valori pe care le poate lua [10]. Între paranteze se enumeră
valorile pe care le poate lua atributul. Acest tip de date definește explicit domeniul atributului,
care nu poate avea alte valori decât cele specificate. ENUM este ideal pentru “tip_mem” din
Camelia Ciocan CAP . IV : Proiectarea sistemului DSC -Base
– 35 –
tabelul membrilor, dar și pentru coloane din alte tabele: pentru specificarea tipului de concurs
(“tip_concurs”, tabelul “concursuri”), a claselor valorice ( “cls_st” și “cls_la” din “carnete”, “cls”
din “rezultate”), a secțiunii la care s -a obținut un rezultat ( “sectiune”, tabelul “rezultate”), a
zilelor în care o grupă are ore ( “ziua”, tabelul “programe”) și a tipului de utilizator ( “tip”, tabelul
“utilizatori”). Pentru toate acestea se cunosc d inainte valorile, care sunt limitate ca număr. La
introducerea datelor, utilizatorul va trebui doar să aleagă valoarea dintr -o listă .
Tipul DATE este folosit pentru a stoca o dată (calendaristică): ziua, luna și anul.
Formatul în care se memorează este “AAAA-LL-ZZ”. Pe de altă parte, YEAR memorează doar
anul. Formatul depinde de numărul precizat între paranteze la declarare: pentru “year(2)” se vor
stoca ultimele două cifre ale anului, iar pentru “year(4)” toate cele patru cifre. [10]
La definirea atribute lor “an_ch” din tabelul “chitante” și “an_ctz” din tabelul
“cotizatii” am folosit tipul YEAR.
Pentru coloanele “ora_start” și “ora_fin” ale tabelului “programe” am optat pentru
tipul TIME. Acest tip este folosit pentru a stoca ore, minute și secunde, în f ormatul
“HH:MM:SS”. TIME poate fi folosit și pentru a memora cât timp s -a scurs între două
evenimente, de exemplu, nu doar pentru a menționa ora din zi.
Un lucru important de menționat legat de domeniile atributelor este acela că o cheie
străină trebuie să aibă domeniul identic cu cel al cheii primare pe care o referă. De exemplu, din
tabelele IV.2 și IV.4 se observă că tipul “mem_id” din tabelul “sportivi” este identic cu cel al
coloanei “id_mem” din tabelul “membrii”, coloană pe care o referă .
Tabelul IV. 4. Sportivi – tipurile atributelor
ATRIBUT TIP
# fisa int (6)
fk * mem_id int (6)
fk O gr_id int (3)
MySQL, mai exact motorul de stocare pe care l -am folosit, InnoDB, permite
definirea cheilor străine, împreună cu referințele acestora.
De asemenea, există posibilitatea de a alege ce acțiuni să se facă automat la ștergerea
(ON DELETE) sau modificarea (ON UPDATE) unor înregistrări [10]:
– CASCADE: ștergerea sau modificarea unei înregistrări din tabelul părinte va
declanșa și ștergerea sau modificarea înregistrărilor corespunzătoare din tabelul fiu;
Camelia Ciocan CAP . IV : Proiectarea sistemului DSC -Base
– 36 –
– SET NULL: ștergerea sau modificarea unei înregistrări din tabelul părinte va
determina modificarea cheii străine din tabelul fiu, aceasta devenind nulă (NULL);
– NO ACTION și RESTRICT: interzic modificar ea sau ștergerea înregistrării din
tabelul părinte, dacă în tabelul fiu există un rând în care cheia străină referă cheia primară a
tabelului părinte.
Dacă nu se specifică acțiunile pentru ON DELETE și ON UPDATE, InnoDB se
comportă ca și cum s -ar fi selec tat NO ACTION sau RESTRICT.
Aceste opțiuni ajută la păstrarea integrității datelor, dar și la simplificarea aplicației,
în sensul că nu mai trebuie create funcții speciale în cadrul aplicației care să facă verificările,
modificările și ștergerile .
În tabel ul IV.5, am exemplificat acțiunile ON DELETE și ON UPDATE pentru
tabelul “sportivi”. “Referin ță” precizează numele tabelului părinte și cheia primară referită .
Tabelul IV.5. Sportivi – ON DELETE și ON UPDATE
ATRIBUT REFERINTA ON DELETE ON UPDATE
mem_id membrii.id_mem cascade cascade
gr_id grupe.id_gr set null cascade
Dacă se șterge un membru din baza de date, atunci nu ne mai interesează nici datele
sale ca sportiv. Deci vom șterge și înregistrarea corespunzătoare din tabela “sportivi”. Dacă se
schimbă valoarea “id_mem” din “membrii”, atunci se va actualiza și “mem_id” în tabelul
“sportivi”, pentru a păstra integritatea datelor despre membrul respectiv.
Similar și în relația cu “grupe”. Dacă se șterge o grupă din baza de date, “gr_id” din
“sportivi” co respunzător acelei grupe va fi setat la NULL. Ștergerea unei grupe nu va implica și
ștergerea sportivilor care făceau parte din aceasta. Dacă se modifică valoarea “ id_gr” din “grupe”
se va modifica și “gr_id” din “sportivi”, indicând corect în continuare g rupele din care fac parte
sportivii.
Crearea tabelelor se face cu comanda CREATE, specificând numele bazei de date,
numele tabelului, atributele și proprietățile atributelor.
În porțiunea de cod următoare se crează tabelul “membrii”:
CREATE TABLE `dance `.`membr ii` (
`id_mem` INT(6) NOT NULL AUTO_INCREMENT PRIMARY KEY,
`tip_mem` ENUM('sportiv', 'instructor' , 'user') NOT NULL DEFAULT 'sportiv',
`d_mem` DATE NOT NULL,
`nume` VARCHAR( 30) NOT NULL,
Camelia Ciocan CAP . IV : Proiectarea sistemului DSC -Base
– 37 –
`prenume` VARCHAR( 30) NOT NULL,
`d_nastere` DATE NOT NULL,
`loc_nastere` VARCHAR( 30) NOT NULL,
`cnp` CHAR(13) NOT NULL,
`adresa` VARCHAR( 60) NOT NULL,
`loc` VARCHAR( 30) NOT NULL,
`jud` VARCHAR( 30) NOT NULL ,
`tel` CHAR(10) NOT NULL,
`tel2` CHAR(10) NULL,
`mail` VARCHAR( 50) NULL,
`alte_date` VARCHAR( 100) NULL,
) ENGINE = InnoDB
Pentru relaționarea tabelelor “ membrii” și “sportivi”, folosim comanda ALTER
TABLE, care realizează modificări (de structură sau de conținut) ale tabelelor. FOREIGN KEY
specifică atributul pe care dorim să îl facem cheie străină, iar REFERENCES atributul pe care îl
referă .
ALTER TABLE `sportiv i`
ADD FOREIGN KEY ( `mem_id` )
REFERENCES `dance`.`membr ii` (`id_mem`)
ON DELETE CASCADE ON UPDATE CASCADE
Se remarc ă și definirea ac țiunilor ON DELETE și ON CASCADE.
Similar se creează și se relațion ează toate tabelele bazei de date.
Camelia Ciocan CAP. V : Aplicația DSC -Base
– 38 –
Capitolul V
Aplica ția DSC -Base
V.1. Interfața aplicației
Intrucat aplicatia DSC -Base ruleaza intr -un browser de internet , pentru realizarea
interfetei , dar si a aplicatiei propriu -zise, am folosit tehnicile web HTML, C SS, JavaSc ript si
PHP.
HTML ( HyperText Markup Language ) este un limbaj prin care se descriu paginile
web, mai exact cum să se afișeze conținu tul acestora. Limbajul folosește perechi de eti chete
pentru definirea de paragrafe, tabele, formulare, liste, etc.
Pentru crearea de site -uri dinamice se folosește limbajul PHP (PHP: Hypertext
Preprocessor). Acesta este un limbaj de scripting pentru server, care poate interacționa cu un
SGBD, precum MySQL. Codurile PHP generează dinamic, în funcție de acțiunile utilizatorului,
coduri HTML (etichete, proprietăți ale acestora, conținutul propriu -zis al paginii web).
Și JavaScript este un limbaj care crește interactivitatea site -urilor, dar rulează pe
client. Cu ajutorul acestora se poate genera conținutul paginii, dar se pot face și validări pentru
formulare, înainte ca datele să fie trimise către server. Codurile JavaScript pot fi descrise într -un
document HTML, între etichetele “<script>” și “</scrip t>”, sau pot fi externe, într -un document
cu extensia “.js”.
Standardul CSS (Cascading Style Sheets) se folose ște pentru f ormatarea elementelor
HTML . Acest lucru se poate face în documentul HTML, prin definirea proprietăților etichetelor,
dar printr -un document CSS extern , personalizarea aspectului se face mai rapid și mai simplu.
Pentru aranjarea elementelor în pagină, am folosit tabele și elemente “div”, pentru
care am definit as pectul într -un document extern “ style.css”. Elementele ce țin de aspect sun t
folosite pe fiecare pagină în parte . Am optat pentru descrierea lor în documente spearate, și
includerea acestora în document ele HTML cu ajutorul funcției “include” a limbajului PHP.
<?php
include ("head.php"); include ("header.php");
include ("atentio nari.php"); include ("meniu.php"); ?>
<?php include ("bottom.php"); ?>
Camelia Ciocan CAP. V : Aplicația DSC -Base
– 39 –
Rezultatul acestor func ții va fi urm ătorul:
<div id="container">
<div id="header"> <p id="ceas_data"> </p></div>
<div id="border">
<div id="content">
<table align="center"> <tr>
<td id="stanga" valign="top" width="200px">
<div id="top_stg"></div>
<div id="atentionari"> -Atentionari – </div>
<div id="separator"></div>
<div id="meniu"> -Meniu- </div>
<div id="bot_meniu"></div> </td>
<td id="dreap ta" valign="top" width="570"> -Continut pagina –
</td></tr></table>
</div>
</div>
<div id="border_bottom"> <br /><cr> 2010 © Camelia </cr></div>
</div>
În cadrul documentului CSS, am personalizat aceste elemente, specificând culorile
sau imaginile de fundal, dimensiunile elementelor, culoarea textului, etc. Iată câteva exemple de
cod din “style.css”.
/* elemente identificate prin ID */
#container{ margin: auto; /* pozitioneaza in centru */
width: 800px;}
#header{ background -image:url(template/top t.jpg);
background -repeat: no -repeat;
height: 130px ; }
#content{ background -image:url(template/contentbg.gif);
background -repeat: repeat -x;
background -color:#abe4fe;
margin: 0px 10px 0px 10px; }
/* stilul pentru nota de copyright */
cr{ color: #6 03;
font-size: 13px; }
În figura V.1, se pot vedea aspectul și așezarea în pagină a elementelor principale,
identificate prin atributul “id”, așa cum rezultă din bucățile de cod prezentate mai sus și
includerea întregului document CSS.
Camelia Ciocan CAP. V : Aplicația DSC -Base
– 40 –
Figura V.1. Împărțirea și aspectul general al paginii
În partea de sus a paginii, în dreapta, se afișează data și ora. Acest lucru este posibil
printr -o funcție scrisă în JavaScript, apelată la încărcarea paginii .
<body onLoad="startclock()">
Func ția “setTimeout( cod, timp)”, execut ă cod la un interval ul de timp timp, exprimat
în milisecunde, după apelarea func ției.
function startclock(){
var timp = new Date(); //data curenta
var zi = timp.getDate();
var luna = timp.getMonth() + 1;
var an = timp.getFullYear();
if (zi < 10) zi = "0" + zi; // daca este o cifra se adauga 0 in fata
if (luna < 10)luna = "0" + luna;
var ora = timp.getHours();
var minut = timp.getMinutes();
var sec = timp.getSeconds();
if (ora < 10) ora = "0" + ora; // daca este o cifra se adauga 0 i n fata
if (minut < 10) minut = "0" + minut;
if (sec < 10) sec = "0" + sec;
document.getElementById("ceas_data").innerHTML = zi + " / " + luna + "
/ " + an + "<br \>" + ora + ":" + minut + ":" + sec;
setTimeout('startclock()',1000);
}
Camelia Ciocan CAP. V : Aplicația DSC -Base
– 41 –
Includerea scri pturilor JavaScript externe si a foilor de stil CSS, se face in prima
parte a documentului HTML, intre etichetele “<head>” si “</head>”:
<head>
<meta http -equiv="Content -Type" content="text/html; charset=utf -8" />
<title> DEBC </title>
<link rel= "stylesh eet" type="text/css" href="style.css" />
<script type="text/javascript" src="scripts.js"></script>
<script type="text/javascript" src="ceas.js"></script>
</head>
Un formular simplu, creat în HTML , este cel pentru înregistrarea unui utilizator
(Figura V.2) :
<form method="post" action="login.php">
<table align="center"><tr>
<td> Nume utilizator : </td>
<td><input type="text" name="user" id="user" maxlength="20" size="20" /></td>
</tr><tr>
<td> Parola : </td>
<td><input type="password" name="parola " id="parola" maxlength="30" size="30"
/></td>
</tr><tr>
<td colspan="2" align="right"> <input type="submit" name="login"
value="Login" />
</tr></table>
</form>
Figura V.2. Formular î nregistrare
Un exemplu de formular cu elemente de tip “input” g enerate cu PHP este cel pentru
adăugarea unei grupe noi (Figura V.3). Am interogat baza de date pentru a crea o listă cu
instructori.
<tr>
<th align="right"> Instructor: </th>
<?php include ("conectare.php");
//conectare.php realizeaza conexiunea cu baza de date
Camelia Ciocan CAP. V : Aplicația DSC -Base
– 42 –
// selectam coloanele care ne intereseaza din fiecare tabel
$select = mysql_query("SELECT instructor i.id_ins,membr ii.nume,membr ii.prenume
FROM instructor i, membrii
WHERE instructor i.mem_id = membru.id_mem
ORDER BY membr ii.nume ASC", $c on)
or die("Nu am putut selecta instructorii din baza de date.");
// mesajul de eroare in caz ca SELECT nu functioneaza ?>
<td>
<select name="instr" id="instr">
<?php //$row parcurge fiecare rand intors
while ($row = mysql_fetch_assoc($select))
echo "<option value= \"". $row['id_ins'] ." \">". $row['nume'] ."
". $row['prenume'] ."</option>" ; ?>
</select>
</td>
</tr>
Figura V.3. Formular – grupă nouă
Lista derulant ă (“drop -down”), este populat ă cu numele și prenumele instruct orilor
existen ți. Aceste valori sunt preluate din baza de date. Se poate observa c ă lista este creat ă cu
ajutorul unei bucle “while”, gener ând pentru fiecare instructor g ăsit în baza de date câte un
element “option”.
Un alt exemplu de formular creat cu PHP , este cel pentru adăugarea de noi membrii.
Mai întâi, utilizatorul trebuie să aleagă tipul de membru (sportiv sau instructor) sau dacă vrea să
Camelia Ciocan CAP. V : Aplicația DSC -Base
– 43 –
creeze un nou utilizator. În funcție de opțiunea aleasă , se va genera un formular specific tipului
de utilizator .
De exemplu, titlul formularului:
<?php if ($tip == "sportiv") echo "Sportiv nou: ".$_SESSION['nume']." ".
$_SESSION['prenume'];
else if ($tip == "instructor") echo "Instruct or nou: ". $_SESSION['nume']." ".
$_SESSION['prenume'];
else echo "Utilizator nou: ". $_SESSION['nume']." ".$_SESSION['prenume'];?>
Variabilele de sesiune $_SESSION['nume'] și $_SESSION['prenume'] memorează
numele și prenumele noului membru, așa cum au fost introduse într -o pagină anterioară a
formlarului.
Similar, cu aj utorul unei structuri decizionale “if” se stabilește ce anume se
generează pe ultima pagină a formularului: se cere grupa pentru un sportiv, pentru un instructor
detalii legate de pregătirea sa, iar pentru un nou utilizator numele, tipul (drepturile) și parola.
V.2. Dezvoltarea aplicației
DSC -Base nu este doar o interfață prin intermediul căreia utilizatorii introduc și
vizualizează date. Aplicația prelucrează datele și le verifică înainte de a le introduce efectiv în
baza de date.
De exemplu, la introd ucerea unui nou membru trebuie introdusă data nașterii. Pentru
a asigura integritatea datelor, înainte de a se face comanda INSERT, f uncția check_date()
verifică dacă data introdusă este corectă. Dacă nu, atenționează utilizatorul.
function check_date (dat a_id){
document.getElementById("a_data").innerHTML = "";
// verificam doar daca este ceva introdus in caseta de text
if (document.getElementById(data_id).value!="")
if(document.getElementById(data_id).value.match(
"[0-3][0-9]-(0|1)[0-9]-(19|20)[0 -9]{2}"))
{ //se creaza vector : elementele din data_id, despartite prin –
var data_i = document.getElementById(data_id).value.split(' -');
var zi = data_i[0];
var luna = data_i[1];
var an = data_i[2];
data = new Date(an,luna,zi); //se creaza data din variabilele date
prezent = new Date(); //data curenta
Camelia Ciocan CAP. V : Aplicația DSC -Base
– 44 –
if (data > prezent) //nu trebuie sa fie o data din viitor
document.getElementById("a_data").innerHTML = "<br /> Data
introdusa nu este corecta!";
else if (document.getElementById(data_id).id = = "data_n")
{ // varsta trebuie sa fie intre 2 si 80 de ani
if ((an > prezent.getFullYear() -2) ||
(an < prezent.getFullYear() -80))
document.getElementById("a_data").innerHTML = "<br /> Varsta prea mica sau
prea mare!";
if ((luna == " 00") || (luna > 12))
document.getElementById("a_data").innerHTML = "<br /> Luna este incorecta!";
if ((zi == "00") || (zi > 31))
document.getElementById("a_data").innerHTML = "<br /> Ziua este incorecta!";
}
}
else
document.getElementById("a_da ta").innerHTML = "<br /> Data este incorecta!
Verificati formatul.";
}
Dacă valoarea câmpului nu este nulă se face verificarea. Formatul datei introduse
trebuie să respecte expresia regulară "[0-3][0-9]-(0|1)[0 -9]-(19|20)[0 -9]{2}" . Verificare a se face
cu ajutorul metodei match(). În cazul în care funcția check_date() găsește o dată introdusă greșit,
va anunța utilizatorul printr -un mesaj afișat imediat sub căsuța de text corespunzătoare (Figura
V.4).
Funcția este apelată de evenimentul “onBlur”, adi că atunci când utilizatorul apăsa în
afara câmpului de text destinat introducerii datei de naștere .
<tr><th align="right"> Data nasterii: </th>
<td><input type="text" name="data_n" id="data_n" maxlength="10"
onBlur="check_date('data_n')" />
<i style=" font-size:12px"> (zz -ll-aaaa) </i>
<span id="a_data" style="color:#F03; font -size:13px; font -weight:bold;"> 
</span>
</td></tr>
Figura V.4. Verificarea datei
Camelia Ciocan CAP. V : Aplicația DSC -Base
– 45 –
Tot cu expresii regulare se face și verificarea adreselor de e -mail.
function check_mail (ma il){
document.getElementById("a_mail").innerHTML = "";
if (document.getElementById(mail).value!="")
if (!document.getElementById(mail).value.match
(/^.+\@(\[?)[a-zA-Z0-9\-\.]+\.([a-zA-Z]{2,3}|)( \]?)$/))
document.getElementById("a_mail").innerHTML = " Adresa gresita!";
}
După verificarea cu JavaScript a corectitudinii datelor, în PHP am verificat ca datele
introduse să nu existe deja. În cazul în care există, aplicația se întoarce la pagina anterioară și
atenționează utilizatorul. Dacă datele nu se regă sesc în baza de date, atunci se face o nouă
înregistrare .
<?php // verificam ca datele introduse sa nu existe in baza de date
$select = mysql_query("SELECT nume, varsta1, varsta2, id_gr
FROM grupa WHERE nume= \"$nume\" AND varsta1= \"$varsta1 \" AND
varsta2=\"$varsta2 \" AND instr_id= \"$instr\"",
$con) or die("Nu am putut selecta grupele baza de date.");
// daca exista: ne intoarcem la formular si atentionam
// exista daca s -a intors cel putin un rand
if (mysql_num_rows($select)>=1){
$row = mysql_fet ch_assoc($select);
$_SESSION['id_gr'] = $row['id_gr'];
$_SESSION['exista'] = "Aceasta grupa exista deja.";
header("location: form_grupa.php");
exit(0);}
//altefel: adaugam in baza de date
else {// introducem atributele obligatorii
mysql_query("INSERT INTO grupa (id_gr,nume,varsta1,instr_id)
VALUES (NULL, \"$nume\",\"$varsta1 \",\"$instr\")", $con)
or die("Nu am putut adauga atributele obligatorii.");
$id_gr = mysql_insert_id($con); // preluam id -ul grupei
// daca au valori, introducem si atribute le optionale
if ($varsta2 != "") mysql_query("UPDATE grupa SET varsta2= \"$varsta2 \"
WHERE id_gr= \"$id_gr\"", $con)
or die("Nu am putut adauga un atribut optional.");
if ($obs != "") mysql_query("UPDATE grupa SET obs= \"$obs\"
WHERE id_gr= \"$id_gr\"", $con)
or die("Nu am putut adauga un atribut optional.");
} ?>
Camelia Ciocan CAP. V : Aplicația DSC -Base
– 46 –
Aplicația folosește variabile de sesiune ($_SESSION) pentru a păstra valorile
elementelor “input” din formularele cu mai multe pagini sau atunci când în urma unor verific ări
precum cea de mai sus , aplica ția ne intoarce la formular pentru a reintroduce date . Astfel , la
reîncarcarea paginii, câmpurile vor fi deja completate cu valorile date înainte . Mai jos, am
prezentat un extras din codul formularul ui pentru adăugarea unei grupe noi. Acesta ilustrează
modalitatea de autocompletare a ca setelor de text : “nume”, “varsta1” și “varsta2” .
<tr><th align="right"> Nume:</th> <td valign="bottom">
<input type="text" name="nume" id="nume" maxlength="20" size="20"
<?php if(isset($_SESSION[ 'nume']))
echo "value=\"".$_SESSION['nume']." \""?> />
<i style="font -size:12px"> (ex.: Avansati A) </i> </td>
</tr> <tr><th align="right" valign="top"> Grupa de varsta:</th> <td>
<input type="text" name="varsta1" id="varsta1" maxlength="3" size="2"
<?php if(isset($_SESSION['varsta1']))
echo "value= \"".$_SESSION['varsta1']." \"" ?> /> –
<input type="text" name="varsta2" id="varsta2" maxlength="2" size="2"
<?php if(isset($_SESSION['varsta2']))
echo "value= \"".$_SESSION['varsta2']." \"" ?> /> <br />
<i style="font -size:12px"> (ex.: <12, 12 -15) </i> </td> </tr>
Funcția “isset()” verifică dacă variabila dată ca parametru există și are valoare. În
continuare, dacă variabila respectivă există, aplicația va completa caseta de te xt corespunzătoare
cu valoarea acesteia. Dacă nu există, caseta de text va rămâne goală .
Variabile de sesiune am folosit și pentru a restricționa accesul utilizatorilor pe
anumite pagini și pentru a nu permite accesul pe nicio pagină fără înregistrarea în prealabil.
Clubul meu sportiv este în mod special interesat să țină evidența sportivilor care
participă în concursuri. Cerințele clubului și regulile legate de competiții le -am descris în al
doilea capitol al lucrării.
Pe lângă formularele pentru creare a de carnete noi, introducerea de concursuri și
rezultate noi, aplicația avertizează când se apropie sau când a trecut termenul de expirare a vizei
medicale si anunță când un sportiv se apropie de avansarea în clasă sau dacă acesta a întrunit
condițiile necesare, dar nu a fost avansat.
Următorul extras de cod, exemplifică modul în care aplicația verifică și atenționează
utilizatorii în legătură cu termenul de expirare al vizelor medicale. Am utilizat funcțiile SQL
“PERIOD_DIFF” (întoarce diferența dintre do uă date calendaristice, rezultatul fiind exprimat în
luni) și “DATE_FORMAT” (întoarce o dată în formatul dorit).
Camelia Ciocan CAP. V : Aplicația DSC -Base
– 47 –
include ("conectare.php");
$select = mysql_query ("SELECT
PERIOD_DIFF(DATE_FORMAT(SYSDATE(),'%Y%c'),DATE_FORMAT(carnete.viza,'%Y%c')) -6
AS diferenta
FROM carnete W HERE
PERIOD_DIFF(DATE_FORMAT(SYSDATE(),'%Y%c'),DATE_FORMAT(carnete.viza,'%Y%c')) -6
>= -1",
$con) or die("Nu am putut selecta carnetele din baza de date.");
if (mysql_num_rows($select)>=1){
$_SESSION['atentionari'] = 1;
//contoare pentru vize expirate, respectiv care vor expira
$exp = 0; $vexp = 0 ;
while($row = mysql_fetch_assoc($select)) //parcurge fiecare rand intors
if ($row['diferenta']>=1) $exp = $exp + 1;
else if ($row['diferenta']== -1) $vexp = $vexp + 1;
// setam mesajul de atentionare pentru vize expirate
if ($exp==1) $_SESSION['vize_exp'] = "O viza expirata.";
else if ($exp>1) $_SESSION['vize_exp'] = $exp ." vize expirate.";
// setam mesajul de atentionare pentru vize care vor expira
if ($vexp==1) $_SESSION ['vize_vexp'] = "O viza va expira in curand.";
else if ($vexp>1) $_SESSION['vize_vexp'] = $exp ." vize vor expira in
curand.";
}
Odată cu interogarea bazei de date, obținem, cu funcția “PERIOD_DIFF”, diferența
dintre data curentă și data vizei medicale. Din acest rezultat scădem 6, adică perioada de
valabilitate a vizelor și am notat noul rezultat cu “diferenta” (SELECT … AS diferen ta …).
“diferenta” va fi un număr negativ dacă viz a nu a expirat încă, altfel va fi un număr pozitiv.
Pentru că ne intere sează doar cele expirate și cele care își vor pierde valabilitatea într -o lună,
specificăm în clauza WHERE ca “diferenta” să fie mai mare sau egală cu -1.
Într-o buclă “while” vom număra câte vize au expirat și câte mai sunt valabile o lună,
iar apoi const ruim mesajele de atenționare, separat pentru fiecare situație. Aceste mesaje vor fi
afișate în zona definită de “div” -ul cu id -ul “atentionari”.
<?php if (isset($_SESSION['atentionari'])) {
echo "<strong style= \"padding -left:45px; \">ATENTIONARI</strong>
<p style= \"font-size:9px; \"></p>";
if (isset($_SESSION['vize_exp'])) echo "<ared>".$_SESSION['vize_exp'] .
"</ared><br \>";
if (isset($_SESSION[ 'vize_vexp'])) echo "<agreen>". $_SESSION['vize_vexp'] .
"</agreen><br \>";
} ?>
Camelia Ciocan CAP. V : Aplicația DSC -Base
– 48 –
Figura V.5 arată că există o singură viză care va expira într -o lună sau mai puțin .
Figura V.5. Aten ționare vize medicale
O altă funcție care vine în sprijinul antrenorilor și instructorilor este cea care, l a
introducerea de noi rezultate , calculează automat, în timp real, punctajele obținute de sportivi ,
conform regulilor FRDS .
function calcul_pct (){
var eroare = document.getElementById("eroare"); //mesajul de eroare
var procent = document.getElementById("procent"); //procentul pentru bonus
var loc = document.getElem entById("loc").value;
var perechi = document.getElementById("perechi").value;
var t_pct = document.getElementById("pct"); //puncte obtinute
var t_plus = document.getElementById("plus"); //bonus pt. tipul competitiei
var t_total = document.getElementById("t otal"); //punctajul final
eroare.innerHTML = "";
procent.innerHTML = "";
if ((loc!="")&&(perechi!="")) //daca nu sunt completate nu se calculeaza
if (parseInt(loc)>parseInt(perechi)){
eroare.innerHTML= "Locul este mai mare decat numarul de prechi!";
t_pct.value = "";
t_plus.value = "";
t_total.value = ""; }
else {
loc = parseInt(loc);
perechi = parseInt(perechi);
pct = perechi – loc; //calcul puncte
t_pct.value = pct; //afisarea punctelor obtinute
// bifarea automata a checkbox -ului “finala”
if (loc<=5) document.getElementById("finala").checked = true;
else document.getElementById("finala").checked = false;
// ce tip de competitie este selectat?
var optiuni = document.formular.tip_concurs; //lista drop -down
var tip = optiuni.opt ions[optiuni.selectedIndex].value; //tipul selectat
// bonusul, in funtie de tipul competitiei
switch (tip) {
case "Cupa":
bonus = 0;
break;
Camelia Ciocan CAP. V : Aplicația DSC -Base
– 49 –
case "C.N. de cls.":
bonus = Math.round(pct/2);
procent.innerHTML = "50%";
break;
case "Cupa Romaniei":
bonus = Math.round(pct * 3/4);
procent.innerHTML = "75%";
break;
default:
bonus = pct;
procent.innerHTML = "100%"; }
t_plus.value = bonus; // afisarea bonusului
t_total.value = pct + bonus; //afisarea pun ctajului final }
}
Prin “document.getElementById()” se întoarce elementul HTML cu id -ul specificat
între paranteze. Variabilele “eroare” și “procent” devin un fel de alias pentru elementele
specificate. Func ția parseInt() face conversia la tipul întreg.
Funcția “calcul_pct()” este apelat ă de metoda “onchange” a elementului de tip
“select”, prin care se seteaz ă tipul competiției, și de metoda “onkeyup” a casetelor de text în care
se introduc locul obținut și numărul de perechi participante la competiție .
Figura V. 6 ilustrează situația în care datele introduse nu sunt corecte, iar figura V. 7
un caz cu date corecte .
Figura V. 6. Rezultate – date incorecte
Camelia Ciocan CAP. V : Aplicația DSC -Base
– 50 –
Figura V. 7. Rezultate – date corecte
După calcularea punctajelor, prin apăsarea butonului de “submit”, datele sunt trimise
către server, se verifică dacă datele mai există în baza de date, și dacă totul este în ordine, se vor
crea noi înregistră ri: două în tabelul “ rezultate” (câte una pentru fiecare sportiv) și una în tabelul
“concursuri” (doar dacă acel concurs nu există deja).
Așadar, aplicația DSC -Base pune la dispoziția utilizatorilor formulare pentru a
facilita introducerea datelor în tabelele bazei de date și asigură o interfață simplă și intuitivă
pentru extragerea de informații .
Camelia Ciocan Concluzii
– 51 –
Concluzii
DSC -Base este un sistem de gestiune pentru un club de dans sportiv , ce se pliază
foarte bine pe nevoile actuale ale clubului meu. Oferă posibilitatea gestionarii sportivilor,
instructorilor și a grupelor. Se pot vizualiză încasările făcute din cotizații și pr ezențele fiecărui
sportiv înregistrat .
Partea cea mai importantă și cea care constituie un element de noutate pentru
aplicațiile similare este legată de activitatea competițională din dansul sportiv. Nici una dintre
aplicați ile prezentate în al treilea capi tol al lucrării nu oferă posibilitatea de a ține evidența
concursurilor la care au participat membrii și a rezultatelor sportivilor .
Majoritatea soft -urilor de gestiune pentru cluburi sportive sunt create pentru săli de
fitness, aerobic sau alte activităț i de întreținere corporală. Acestea sunt altfel organizate și multe
dintre ele au activitate economică. Sunt mai dezvoltate, deci își permit achiziția de aparaturi
sofisticate și de aplicații comerciale mai costisitoare .
Un club de dans sportiv are o struc tură mult mai simplă, colectivul membrilor este
mult mai stabil decât în cazul sălilor de forță, iar interesul principal este performanța sportivilor
și participarea la concursuri. Astfel, soft -urile de gestiune prezentate sunt mult prea complexe și
nici n u oferă suport pentru partea competițională .
DSC -Base are avantajul că este realizat folosind tehnologii gratuite, eliminând mare
parte din costurile necesare achiziției și mentenanței unui soft comercial.
Interfaț a are un design simplu și este ușor de ut ilizat, oferind meniuri intuitive. De
asemenea, structura actuală a bazei de date permite dezvoltări ulterioare, fără pierderi majore de
informații. În etapa de proiectare am ținut cont de eventualele cerințe noi ce ar putea să apară.
Aplicația poate fi i nstalată cu ușurință pe un server, împreună cu baza de date. Astfel,
va putea fi accesată prin internet din orice loc , prin intermediul unui browser de internet.
DSC -Base satisface nevoile actuale ale Clubului Sportiv Dance Energy. E ste o
aplicație simplă, destinată în special instructorilor și antrenorilor. Însă, în viitorul apropiat
intenționez să integrez mai multe utilități pentru contabilitate: evidența încasărilor și din alte
surse decât cotizațiile sportivilor, evidența cheltuielilor, registru de cas ă, generare de diverse
rapoarte ce se întocmesc periodic .
Camelia Ciocan Concluzii
– 52 –
Urmăresc să integrez și partea de secretariat: registru de numere (intrări și ieșiri),
evidența contractelor, generare de formulare, adeverințe și contracte, evidența sponsorilor și a
evenimentelor organizate.Spectacolele și cantonamentele organizate sau la care au participat
sportivii clubului ar interesa și pe instructori, dar și pe sportivii care urmăresc o carieră de
dansator, ajutându -i să își facă un portofoliu de activități .
În cadrul clubului se fac periodic evaluări ale sportivilor, pentru a le testa condiția
fizică, tehnica și cunoașterea unor pași și coregrafii. Aplicația poate fi dezvoltată și în această
direcție, prin introducerea de noi tabele în baza de date, pentru evidența probelor și rezultatelor.
Trimiterea automată de e -mail-uri pentru atenționarea membrilor cu restanțe sau cu
rapoarte lunare privind activitatea lor în cadrul clubului (prezențe, competiții, spectacole,
rezultate ale unor evaluări) ar fi o îmbunătățire ce ar putea fi adusă aplicației. Posibilitatea de a
crea copii de siguranță ( “backup”) ale bazei de date chiar din cadrul aplicației este un alt element
pe care doresc să îl implementez.
De asemenea, mi -am propus să cresc interactivitatea site -ului. Doresc să creez un
nou tip de utilizator pentru sportivii care doresc să își vizualizeze profilul online. Plecând de la
această idee, s -ar putea dezvolta, în paralel, un site de socializare pentru dansatori, unde fiecare
să încarce poze sau filmări de la diverse activități sportive sau artistice, să facă teste de
cunoștințe legate de domeniul dansului sportiv, să comunice între ei pe un forum de discuții , etc.
Așadar, DSC -Base este o aplicație utilă în orice club de dans sportiv. Posibilitățile de
dezvoltare sunt numeroase ș i dintre cele mai interesante. Pe lângă integrarea părților contabile și
de secretariat ce țin strict de gestiune a clubului, DSC -Base constituie și un punct de plecare în
realizarea unor proiecte mai ambițioase precum o rețea de socializare pentru dansator i și cluburi
de dans sportiv .
Camelia Ciocan Bibliografie
– 53 –
Bibilografie
[1] Fotache, M. (2005), Proiectarea bazelor de date: Normalizare și postnormalizare:
Implement ări SQL și Oracle, Editura Polirom, Ia și
[2] Dollinger, R. și Andron, L. (2004), Baze de date și gestiunea tranzac țiilor, Editura Albastr ă,
Cluj-Napoca
[3] Nechita, E. și Crișan, G. C. (2008), Baze de date – Curs, Universitatea din Bac ău, Facultatea
de Științe, Bac ău
[4] Oracle Internet Academy (2006) – Database Design and Database Programming With SQL –
curs online, a ccesat 2007 la adresa https://academy.oracle.com/
[5] Fotache, M. (1997), Baze de date relationale . Ed. a II -a, Editura Junimea, Ia și
[6] Federa ția Român ă de Dans Sportiv, Regulamentul tehnic , accesat august 2009 la adresa:
http://dancesport.ro/document_vi ew.php?cod=1
[7] SalaVB – Sport Club Database Assistant , accesat noiembrie 2009 la adresa:
http://sites.google.com/site/salavb/
[8] Global Presence, sport club :: features , accesat noiembrie 2009 la asdresa:
http://www.globalpresence.com.au/sport/
[9] Firm POS – Health Club Management Software, Gym Management Software, Fitness Center
Management Software , accesat noiembrie 2009 la adresa:
http://www.firmpos.com/nversion4/
[10] MySQL 5.1 Reference Manual , accesat octombrie 2009 la adresa:
http://dev.mysql.com/ doc/refman/5.1/en/index.html
Copyright Notice
© Licențiada.org respectă drepturile de proprietate intelectuală și așteaptă ca toți utilizatorii să facă același lucru. Dacă consideri că un conținut de pe site încalcă drepturile tale de autor, te rugăm să trimiți o notificare DMCA.
Acest articol: Coordonator științific: Conf. Univ. Dr. Bogdan PĂTRU Ț Brașov 2010 UNIVERSITATEA “TRANSILVANIA” din BRAȘOV FACULTA TEA DE MATEMATICĂ ȘI INFORMATICĂ… [610935] (ID: 610935)
Dacă considerați că acest conținut vă încalcă drepturile de autor, vă rugăm să depuneți o cerere pe pagina noastră Copyright Takedown.