Proiectarea unei baze de date folosind sistemul MySql WorkBench

INTRODUCERE:
O bază de date (database) este o colecţie de date creată şi menţinută computerizat, care permite operaţii de
introducere, ştergere, actualizare şi interogare a datelor.

I. Proiectarea Bazei de date

Dezvoltarea sistemelor de baze de date comportă mai multe etape, care pot fi prezentate succint astfel:
1.1. Analiza şi definirea sistemului: definirea scopului sistemului de baze de date, a utilizatorilor şi a
aplicaţiilor acestuia.
1.2. Proiectarea sistemului: în această etapă se realizează proiectul logic şi proiectul fizic al sistemului,
pentru un anumit SGBD ales.
1.3. Implementarea: este etapa în care se scriu definiţiile obiectelor bazei de date (tabele, vederi, etc.) şi se
implementează aplicaţiile software.
1.4.Incarcarea(sau conversia) datelor: popularea bazei de date,fie prin incarcarea directa a datelor,fie prin
conversia unor date existente sub diferite alte forme.
1.5.Conversia aplicatiilor: toate aplicatiile software existente in sistemele informatice precedente ale
organizatiei se convertesc in noul sistem.
1.6. Testarea şi validarea: noul sistem de baze de date este testat şi validat cât mai riguros posibil.
1.7.Operarea:sistemul de baze de date este pus la dispozitia utilizatorilor sai cu toate aplicatiile realizate in
cadrul sistemului informatic al organizatiei.
1.8.Monitorizarea si intretinerea: pe tot parcursul etapei de operare sistemul de baze de date trebuie sa fie
in mod permanent monitorizat si intretinut pentru a sigura consistenta si securitatea datelor si pentru a permite
atat cresterea continutului de date cat si dezvoltarea de noi aplicatii software.Pot fi necesare la anumite
intervale de timp,revizii si reorganizari ale sistemului de baze de date.

În general, se consideră că etapa de proiectare a unei baze de date se pot diviza, la rândul ei, în mai multe
faze:
a. Proiectarea conceptuală a bazei de date.
b. Alegerea unui SGBD.
c. Proiectarea logică a bazei de date.
d. Proiectarea fizică a bazei de date.
În mod tipic, dezvoltarea unei baze de date constă din desfăşurarea a două categorii de activităţi paralele,
aşa cum se poate vedea în figura de mai jos:
 Faza
Faza 1:
1: Cerinţele de Cerinţele de
date prelucrare
Colectarea
Colectarea şi
şi
analiza
analiza
cerinţelor
cerinţelor
Faza
Faza 2:
2: Proiectarea
Proiectarea Proiectarea
Proiectarea
schemei
schemei tranzacţiilor
tranzacţiilor
Proiectare
Proiectare conceptuale
conceptuale şi
şi aa (independente
(independente de de
conceptuală
conceptuală schemelor
schemelor externe
externe SGBD)
SGBD)
(independente
(independente dede
Faza 3: SGBD)
SGBD)

Alegerea unui

SGBD
Faza 4: Proiectarea
Proiectarea schemei
schemei
conceptual
conceptual si
si aa
Proiectare schemelor
schemelor
logica externe(dependente
externe(dependente de de
SGBD)
SGBD)
Faza 5: Proiectarea schemei
interne
Proiectare
fizica (dependent de SGBD)
Instructiuni
Instructiuni de
de Implemantarea
Faza 6:
descriere
descriere aa datelor
datelor tranzactiilor
Implementare (LDD)
(LDD)
(dependente de
(dependete
(dependete de
de SGBD)
SGBD) SGBD)

Prima categorie de activităţi se referă la proiectarea structurii şi a conţinutului bazei de date, iar cea
de-a doua categorie se referă la proiectarea modului de prelucrare a datelor.
Aceste două categorii de activităţi sunt strâns corelate: toate prelucrările care se efectuează în
tranzacţii depind de structura datelor memorate, iar proiectarea fizică a bazei de date depinde de prelucrările
necesare în tranzacţii.

Cele şase faze de proiectare şi implementare enumerate mai sus nu se desfăşoară strict într-o singură
secvenţă.În multe cazuri este necesară modificarea proiectului dintr-o fază iniţială într-una din fazele
ulterioare, pentru a se obţine rezultatele dorite. Aceste bucle de reacţie între faze (sau în interiorul unei faze)
sunt, în general frecvente în cursul proiectării unei baze de date, dar nu au mai fost reprezentate în figura de
mai sus, pentru a nu complica diagrama respectivă.

Fazele cele mai importanate de proiectare a unei baze de date sunt fazele 2,4 si 5. Faza 1 in care se
colectează informatiile despre cerintele de utilizare a bazei de date si faza 6,de implementare a datelor si a
tranzactiilor pot sa nu fie considerate ca parte a procesului de proiectere a bazei de date, ci ca parte de a ciclui
de viata a sistemului din care face parte baza de date.Faza 3 de alegere a sistemului de gestiune a bazei de date
este mai putin o faza de proiectare ci mai curand o faza de decizie,in care factorii economici au pondere la fel
de importanta ca si factorii tehnici.
II. Colectarea si analiza cerintelor
Inainte de a se proiecta efectiv o bază de date, este necesar să se cunoască ce rezultate se aşteaptă
utilizatorii potenţiali să obţină de la baza de date respectivă şi ce informaţii primare sunt disponibile pentru
aceasta.
De asemenea, este necesar să se cunoască ce aplicaţii se vor efectua (aplicaţii de gestiune a stocurilor,
aplicaţii contabile, aplicaţii de urmărire a consumurilor, aplicaţii de salarizare, etc.).

In general,in acesta faza de colectare si analiza a cerintelor se desfasoara urmatoarele activitati:

 Identificarea grupurilor de utilizatori potentiali si a aplicatiilor.De regula,persoana cea mai avizata din
cadrul fiecarui grup de utilizatori este cooptata ca participant in activitatile ulterioare de colectare si
analiza a cerintelor.
 Revederea documentatiei existente privind aplicatiile dorite.In afara de documentatiile aplicatiilor
dorite se studiaza si alte documentatii(diagramele de organizare a intreprinderii, formularele existente
de introducere a datelor,rapoartele utilizate in controlul activitatii respective, etc.)pentru a se decide
daca aceste aspect influenteaza cerintele bazei de date.
 Analiza mediului de operare si cerintelor de prelucrare a datelor.
Aceasta activitate include analiza fluxului de informatii in cadrul sistemului ,precum si analiza
tipurilor de tranzactii si a frecventei de lansare a acestora.Deosebit de importanta este si stabilirea
volumului si frecventei datelor actualizate precum si a volumului datelor returnate de interogari si a
frecventei acestora.
 Chestionare si interviuri.Se colecteaza raspunsuri scrise de la utilizatorii potentiali la diferite seturi de
intrebari si se organizeaza interviuri cu persoanele care reprezinte diferitele grupuri de utilizatori.In
felul acesta,proiectantii pot intelege care sunt prioritatile de proiectare a bazei de date,importanta
diferitelor aplicatii si performantele dorite de la acestea.

Toate aceste activităţi oferă informaţii slab structurate, în general în limbaj natural, pe baza cărora se pot
construi diagrame, tabele, grafice, etc., manual sau folosind diferite instrumente software de proiectare.
Această fază este puternic consumatoare de timp, dar este crucială pentru succesul sistemului informatic.

2 .1 Proiectarea conceptual a bazelor de date

Faza de proiectare conceptuală a bazelor de date implică două activităţi paralele: proiectarea schemei
conceptuale şi a schemelor externe ale bazei de date şi proiectarea tranzacţiilor.

2.2 Proiectarea schemei conceptuale de nivel înalt

Deşi nu este obligatoriu, această fază se poate menţine independenta de SGBD şi produce un model de date de
nivel înalt, care va fi implementat după transpunerea lui într-un model de date specific. Chiar dacă proiectanţii pot porni
direct cu scheme conceptuale specifice unui anumit SGBD (care se mai numesc şi scheme logice), este totuşi
recomandabil să se realizeze mai întâi schema conceptuală de nivel înalt independentă de SGBD, deoarece o astfel de
schema conceptuală este o descriere stabilă şi inavuabilă a bazei de date, iar alegerea unui SGBD şi deciziile ulterioare
de proiectare se pot schimba fără ca aceasta să se schimbe.

Pentru proiectarea schemei conceptuale se identifică elementele esenţiale ale acesteia: tipurile de entităţi şi
atributele lor precum şi asocierile dintre aceste tipuri. Se pot defini, dacă este necesar, subtipuri, prin specializări ale
tipurilor de bază, sau supertipuri, prin generalizări ale tipurilor deja definite. Acest proiect conceptual de nivel înalt este
realizat pe baza cerinţelor definite în prima etapă de proiectare şi se reprezintă, în general printr-o diagramă Entitate-
Asociere (extinsă).

Există mai multe aspecte privind modul de abordare a proiectării conceptuale.

Un prim aspect se referă la modul de proiectare a schemei conceptuale a bazei de date: proiectare prin
integrarea cerinţelor şi proiectare prin integrarea schemelor externe.
 În proiectarea prin integrarea cerinţelor (care se mai numeşte şi proiectare centralizată) se realizează mai
întâi integrarea (combinarea) tuturor cerinţelor de proiectare într-un singur set de cerinţe, pe baza căruia se proiectează
schema conceptuală a bazei de date. Din această schema conceptuală (unică) proiectată se deduc schemele externe
(vederile) corespunzătoare diferitelor grupuri de utilizatori şi aplicaţii.

În proiectarea prin integrarea vederilor (schemelor) externe se proiectează câte o schemă

corespunzătoare fiecărui grup de utilizatori şi aplicaţii, pe baza cerinţelor acestora, după care se combină
aceste scheme într-o singură schemă conceptuală globală, pentru întreaga bază de date.

Fiind dat un set de cerinţe, pentru un singur utilizator sau pentru mai mulţi utilizatori ai bazei de date,
proiectarea schemei conceptuale care să satisfacă aceste cerinţe se poate aborda într-o varietate de strategii,
dintre care cele mai relevante sunt proiectarea ascendentă (bottom-up) şi proiectarea descendentă (top-down).

În proiectare ascendentă a bazelor de date se porneşte de la o schemă conceptuală universală care

conţine toate atributele, care sunt apoi grupate pentru a forma tipuri de entităţi şi asocierile dintre acestea.
Proiectul poate fi rafinat prin grupări ulterioare şi creare de supertipuri şi subtipuri ale tipurilor existente.

În proiectarea descendentă a bazelor de date se porneşte de la o schemă conceptuală dezvoltată în

modelul Entitate-Asociere (extins) în care sunt cuprinse aspectele de bază (tipuri de entităţi şi asocieri ale
acestora). Dezvoltarea şi rafinarea acestui model se face prin adăugarea de noi atribute şi constrângeri, crearea
unor subtipuri (prin specializare) şi asocierea acestora cu tipurile de bază.

Aşadar, în această fază de proiectare se obţine schema conceptuală de nivel înalt a bazei de date, care
este independentă de orice model de date specific (ierarhic, reţea, relaţional, etc.), şi de orice sistem de
gestiune care poate fi folosit pentru realizarea bazei de date.
3.SCHEMA CONCEPTUALA DE NIVEL ÎNALT A BAZEI DE DATE
Entităţi
Tipurile de entităţi puternice (normale) care se pot defini pentru modelarea activitătii unei agentii sunt:
ANGAJAT(Nume,Prenume,Parola,Ghiseu)
PERSOANE(Nume,Prenume,Serie_buletin,Numar_Buletin,CNP)
RUTA(Nr_Km,Nr_bilete_rezervate,Clasa)
TRONSON_Aerian(Data_plecare,Ora_Plecare,Data_sosire,Ora_sosire,Locuri_ramase,Sursa,Destinatie,Vehicul)
TRONSON_Tren(Data_plecare,Ora_Plecare,Data_sosire,Ora_sosire,Locuri_ramase,Sursa,Destinatie,Vehicul)
TRONSON_Autocar(Data_plecare,Ora_Plecare,Data_sosire,Ora_sosire,Locuri_ramase,Sursa,Destinatie,Vehicul)
Aeroporturi(Oras,Aeroporturi)
Gari(Oras,Gari)
Autogari(Oras,Autogari)
Vehicul(Vehicul,Nr_locuri)
Tara(Tari)
Asocieri
Asocierile dintre mulţimile de entităţi se stabilesc în funcţie de modul în care se desfăşoară activitatea modelată.
De exemplu, dacă agentia respectivă activitatea este organizată pe mai multe birouri(ghisee) şi fiecare angajat
lucrează într-unul (şi numai unul) din birouri,si se ocupa de cate o rezervare la un anumit moment(nu realizeaza
mai multe rezervari concomitent) atunci între mulţimile de entităţi ANGAJAT-REZERVARI există o asociere
1:N.
Asocierea PERSOANE-REZERVARI este o asociere M:N dacă se consideră că opersoana poate sa faca mai
multe rezervari si o rezervare poate sa contina mai multe persoane .

O ruta este compusa din mai multe tronsoane şi fiecare tronson poate fi inclus în mai multe, rute; deci asocierea
RUTA-TRONSON este este M:N.

O mulţime de entităţi slabe se află, de regulă, în asociere N:1 cu mulţimea de entităţi puternice de care depinde.
In exemplul dat, între mulţimea AEROPORTURI şi mulţimea de entităţi ORAS există o asociere N:1.

III. Proiectarea asocierilor

3.1 Asocierea binară N:1
Asocierea binară N:1 dintre două mulţimi de entităţi puternice din diagrama E-A se realizează în
modelul relaţional prin intermediul unei chei străine în prima relaţie (cea cu multiplicitatea N a asocierii) care
referă cheia primară (sau o cheie candidată) din relaţia referită (cea cu multiplicitatea 1 a asocierii). De
exemplu,asocierea N:1 între relaţiile AEROPORTURI - ORAS se realizează prin cheia străină IdOras adăugată
relaţiei AEROPORTURI, care referă cheia primară cu acelaşi nume a relaţiei ORAS.

Astfel de atribute (pentru definirea cheilor străine) nu există în modelul E-A şi ele trebuie să fie adăugate
în modelul relaţional pentru definirea asocierii N:1, aşa cum în modelul ierarhic pentru o astfel de asociere se
adaugă link-uri (pointeri) între noduri. Asocierea binară N:1 poate apare şi ca asociere între o relaţie
corespunzătoare unei mulţimi de entităţi slabe şi relaţia corespunzătoare mulţimii de entităţi puternice de care
aceasta depinde, aşa cum a fost prezentată mai sus.
3.2 Asocierea binară M:N
Asocierea binară M:N dintre două mulţimi de entităţi din diagrama E-A se realizează în modelul
relaţional prin intermediul unei noi relaţii, numită relaţie de asociere. Această nouă relaţie se află în asociere
M:1, respectiv N:1 cu fiecare din cele două relaţii date prin intermediul a două chei străine care referă cheile
primare (sau cheile candidate) din relaţiile date.

De exemplu, pentru a reprezenta asocierea M:N dintre relaţiile RUTA-TRONSON_AERIAN se adaugă

o nouă relaţie numită RUTA2, care conţine cheile străine IdTronson şi IdRuta, ce referă cheile primare din
relaţiile TRONSON_AERIAN, respectiv RUTA.

O relaţie de asociere poate să conţină şi alte atribute în afara cheilor străine, atribute care caracterizează
asocierea dintre relaţiile date. Cheia primară a unei relaţii de asociere binară poate fi o cheie artificială sau poate
fi compusă din cheile străine, eventual împreună cu alte atribute ale relaţiei.

Asocierea M:N dintre relaţiile PERSOANE-REZERVARI se realizează prin introducerea relaţiei de

asociere PERS, care conţine două chei străine, IdPersoane1 şi IdPersoane2, care referă cheile primare
IdPersoane si IdRezervari.

Schema conceptuală a unei baze de date relaţionale poate fi dezvoltată independent de un anumit SGBD,
urmând ca ulterior să se adauge diferite trăsături specifice SGBD-ului folosit. De obicei însă, fiecare SGBD
pune la dispoziţie un număr de instrumente mai mult sau mai puţin „prietenoase” de proiectare a relaţiilor şi a
asocierilor, astfel încât în mod frecvent, proiectul conceptual se dezvoltă de la început în cadrul sistemului
SGBD în care se va realiza baza de date.

De exemplu, Microsoft Access oferă o interfaţă vizuală de proiectare a relaţiilor şi a asocierilor deosebit
de uşor de utilizat. La fel, sistemele SQL Server sau Oracle 10g oferă instrumente grafice pentru proiectarea
vizuală a relaţiilor.

IV. Proiectarea tranzacţiilor

Atunci când se proiectează o bază de date, se cunosc în mare parte şi ce tipuri de aplicaţii se vor executa.
Un aspect important în proiectarea bazelor de date este specificarea caracteristicilor funcţionale ale acestor
aplicaţii cât mai devreme în cursul procesului de proiectare, astfel încât schema bazei de date să includă toate
informaţiile necesare cu privire la aceste aplicaţii.
În plus, cunoaşterea importanţei relative a diferitelor tranzacţii executate de aplicaţiile bazei de date,
precum şi a frecvenţei de invocare a acestora, permite luarea unor decizii în etapa de proiectare fizică a bazei de
date.
Una din tehnicile cele mai obisnuite de specificare a tranzactiilor la nivel conceptual si independent de
sistemul de de gestiune este de identifica intrarile si iesirile lor su comportarea functional.Tranzactiile sunt
grupate in trei categorii:tranzactii de interogare,trnzactii de actualizare si tranzactii mixte,care executa atat
interogari cat si actualizari.

Pentru dezvoltarea ulterioara in bune conditii a proiectului unui sitem de baze de date,atat proiectarea
schemei conceptual

După implementarea sistemului de baze de date vor mai fi identificate şi implementate noi tranzacţii.
Totuşi, cele mai importante tranzacţii sunt cel mai adesea cunoscute înainte de implementarea sistemului.
Dacă operaţiile de acces la baza de date ale unei tranzacţii sunt numai operaţii de citire, acea tranzacţie
se numeşte tranzacţie de citire (read-only transaction) şi controlul concurenţei unor astfel de tranzacţii este
mult mai simplu.

In cele ce urmează se va studia cazul general, al tranzacţiilor de citire şi scriere (read-write

transactions) care efectuează atât regăsiri de date (prin operaţii de citire) cât şi actualizări (prin operaţii de
scriere), şi care necesită tehnici de control al concurenţei mult mai complexe.

Operaţiile efectuate de o tranzacţie şi înregistrate de administratorul de refacere (recovery manager),

pentru a asigura cele patru proprietăţi importante ale tranzacţiilor (ACID), sunt următoarele:

1. begin: această operaţie marchează începutul execuţiei unei tranzacţii.

2. read sau write: sunt operaţii de citire sau scriere a articolelor în baza de date, executate în cadrul unei
tranzacţii.
3. end: această operaţie marchează terminarea operaţiilor de scriere sau citire din baza de date, ceea ce
înseamnă că tranzacţia se poate termina; totuşi, este posibil să fie necesare unele operaţii de verificare înainte de
validarea (commit) tranzacţiei.
4. commit: această operaţie semnalează terminarea cu succes a tranzacţiei, validarea tuturor modificărilor
efectuate în baza de date şi vizibilitatea modificărilor efectuate pentru alte tranzacţii; din acest moment,
modificările efectuate nu mai pot fi anulate, nici pierdute printr-o defectare ulterioară a sistemului (bineînţeles,
dacă mecanismul de refacere al SGBD-ului funcţionează corect).
5. rollback (sau abort): această operaţie semnalează faptul că tranzacţia a fost abandonată şi că orice efect pe
care tranzacţia l-a avut asupra bazei de date trebuie să fie anulat (printr-o “rulare înapoi” a operaţiilor).
6. undo: această operaţie este similară operaţiei rollback, dar se aplică unei singure operaţii, nu unei întregi
tranzacţii.
7. redo: această operaţie specifică faptul că unele operaţii ale unei tranzacţii trebuie să fie executate din nou
pentru a se putea valida întreaga tranzacţie.
Ultimele două operaţii sunt necesare numai în anumite tehnici de refacere.

În figura de mai jos este reprezentată diagrama de stare a unei tranzacţii folosind limbajul UML, unde fiecare
stare are o denumire şi fiecare operaţie provoacă o anumită tranziţie între stări.

În starea ACTIVA se ajunge ca urmare a lansării unei tranzacţii prin operaţia begin, iar execuţia corectă
a operaţiilor read sau write nu modifică această stare. Atunci când o tranzacţie se termină, ea trece în starea
PARTIAL VALIDATA în care se efectuează operaţii de verificare impuse de tehnicile (protocoalele) de control
al concurenţei şi de refacere.

Dacă ambele verificări sunt îndeplinite cu succes, atunci tranzacţia este validată (prin execuţia unei
operaţii commit) şi trecută în starea VALIDATA; dacă una sau ambele condiţii nu sunt îndeplinite, tranzacţia
este trecută în starea ABANDONATĂ prin execuţia operaţiei abort.

Starea TERMINATĂ este consecinţa imediată a atingerii uneia din stările VALIDATĂ sau
ABANDONATĂ şi nu necesită nici o altă operaţie pentru efectuarea acestei tranziţii.În cursul stării ACTIVĂ,
orice tranzacţie poate fi abandonată (şi trecută în starea ABANDONATĂ prin execuţia unei operaţii abort),
dacă diferite verificări efectuate nu sunt îndeplinite.
 Pentru refacerea bazei de date în condiţiile în care unele tranzacţii sunt abandonate sau în care pot
apărea defecte de funcţionare, sistemul SGBD menţine un fişier jurnal, în care memorează operaţiile efectuate
de tranzacţii. Fişierul jurnal este memorat pe disc şi nu este afectat de diferite erori de execuţie, cu excepţia unei
defectări catastrofice a discului. În plus, fişierul jurnal este salvat periodic pe un suport auxiliar (bandă
magnetică), ca o măsură de prevedere pentru astfel de defecte catastrofice.

În fişierul jurnal (log file) se înregistrează operaţiile efectuate de fiecare tranzacţie, identificată printr-un
identificator unic (T) generat de sistem.

Prima înregistrare referitoare la o tranzacţie cu identificatorul T este înregistrarea de start a tranzacţiei:

[begin,T].

La fiecare operaţie write(X) executată de o tranzacţie T, în fişierul jurnal se memorează o înregistrare de tipul
[write,T,X,vechea_valoare,noua_valoare], dacă pentru refacerea datelor se folosesc operaţii undo, sau o
înregistrare de tipul [write,T,X,noua_ valoare], dacă se folosesc operaţii redo.

Sistemele care nu evită abandonarea în cascadă a tranzacţiilor înregistrează în fişierul jurnal şi operaţiile
de citire read(X), printr-o înregistrare de tipul [read,T,X,valoare].

Pentru fiecare tranzacţie T, în fişierul jurnal se mai memorează starea de terminare: validată (printr-o
înregistrare [commit,T] ) sau anulată (printr-o înregistrare[rollback,T]). După executarea validării şi
înregistrarea ei în fişierul jurnal, efectul tranzacţiei este permanent memorat în baza de date.

Dacă sistemul se defectează, la reluarea execuţiei după îndepărtarea defectului, sistemul SGBD va aduce
baza de date într-o stare consistentă prin examinarea fişierului jurnal.

Dat fiind că fişierul jurnal conţine o înregistrare pentru fiecare operaţie de scriere care a modificat valoarea unui
articol al bazei de date, este posibil de a anula efectul tuturor operaţiilor de scriere efectuate de o tranzacţie care
a fost lansată dar nu a fost validată, parcurgând înapoi fişierul jurnal şi înlocuind valoarea existentă a articolului
modificat cu vechea valoare, memorată în fişierul jurnal.

În cazul abandonării în cascadă, trebuie să fie abandonate şi tranzacţiile care au citit valori modificate de
tranzacţiile abandonate.
V. Prezentare Mysql WorkBench
1. Mysql WorkBench
1.1.Introducere
Acest capitol introductiv scoate in evidenta facilitatile oferite de Mysql WorkBench si de produsele sale
punandu-le in contextul instrumentelor si tehnologiilor.Acest capitol explica de asemenea principiile de baza ale
bazelor de date relationale.
Mysql WorkBench este o versiune free acelui mai capabil soft de dezvoltare de baze de date relationale.
Mysql WorkBench este usor de instalat si usor de folosit.

Acesta are o interfata usor de folosit ce ofera:

 Administrare baza de date
 Creare de tabele,view-uri si alte obiecte ale bazei de date
 Rularea de queri-uri si scripturi SQL
 Generarea de rapoarte

2.Despre Serverul Mysql

Serverul Mysql WorkBench cuprinde un DBMS care controleaza:
 Stocarea de date in sfera bazelor de date dedicate
 Recuperarea de date pentru aplicatii utilizand tehnici de optimizare adecvate
 Securitatea bazelor de date si a taskurilor permise pentru anumiti utilizatori
 Consistenta si protectia datelor,incluzand arhivarea taskurilor si mecanisme de cautare
 Comunicarea si integritatea informatiilor,cand bazele de date sunt distribuite intr-o retea.

Aplicatiile Mysql WorkBench trebuie rulate pe acelasi computer la fel ca si Serverul Mysql.
Alternativ,aplicatiile si utilitarele utilizate de ele pot sa fie rulate pe un sistem local pentru utilizator (sistemul
'client'),in timp ce Mysql DBMS ruleaza pe un altul (sistemul 'server').
In acest mediu 'client-server',un numar mare de resurse de calcul pot fi rulate.
De exemplu,o aplicatie ' Mysql Forms' poate rula pe un computer personal client,in timp ce accesarea datelor
este condusa conventional de un Server Mysql pe un computer central.

3.ABORDAREA RELATIONALA
3.1 Abordarea relationala
Principiile modelului relational au fost pentru prima data expuse de Dr. E. F.Codd,care in iunie 1970 a
publicat un articol numit 'Un model relational de date pentru marile banci de date'.In acest articol Dr. Codd a
propus modelul 'relational' pentru sistemele de baze de date.
Baza de date relationala este perceputa de utilizatorii sai ca o colectie de tabele bidimensionale care sunt
usor de inteles.Sunt doar patru concepte de inteles:
 tabele
 coloane
 randuri
 campuri
Modelul relational imita procesele unei ramuri a algebrei cunoscute sub numele de 'Algebra relationala'.
Aceste procese implica:
 o colectie de obiecte cunoscute sub numele de RELATII
  o multime de operatori ce actioneza asupra relatiilor pentru a produce noi relatii.
O relatie poate fi inteleasa ca o Tabela.Modificarea datelor este realizata prin operatiile relationale
aplicate asupre tabelelor.

3.2 Operatori relationali sunt definiti mai jos:

Restrictia este o operatie care preia si afiseaza datele din relatie.Este posibil sa se afiseze toate randurile sau
doar randurile care indeplinesc o conditie sau mai multe conditii.Aceasta este de multe ori numita 'submultime
orizontala'
Proiectia este operatia care afiseaza anumite coloane din relatie si de aceea este numita 'submultime verticala'.
Produs este rezultatul obtinut cand randurile a doua multimi de date sunt concatenate conform conditiilor specificate.
Join este rezultatul obtinut cand randurile a doua multimi de date sunt concatenate conform conditiilor specificate.
Reuniunea afiseaza toate randurile care apar in una ,in cealalta sau in ambele din cele doua relatii.
Intersectia afiseaza toate randurile care apar in ambele din cele doua relatii.
Diferenta afiseaza randurile care apar numai intr-o singura relatie (SQL utilizeaza operatorul minus ).

3.3 Proprietati ale bazelor de date relationale

 O baza de date relationala apare ca o colectie de relatii(tabele) catre utilizator.
 Formatul coloanei/randului este familiar si usor pentru vizualizarea datelor .
 Exista o multime de operatori pentru partitionarea si combinarea
relatiilor(selectia,proiectia,produsul,joinul,uniunea, intersectia, diferenta).
 Nu sunt pointeri expliciti;conexiunile sunt facute numai pe baza datelor.
 Limbajul utilizat pentru interogarea bazei de date este non-procedural si similar limbii engleze.
 Utilizatorul nu specifica calea de acces si nu are nevoie sa stie cum este informatia aranjata fizic.
 Comenzile pentru refacerea datelor si acelea pentru realizarea schimbarilor in baza de date sunt incluse
intr-un singur limbaj SQL.
 Exista o independenta totala a datelor.

3.4 Proprietatile relatiilor tabelare

O singura tabela are urmatoarele proprietati:
 Nu exista randuri duplicate
 Nu exista nume de coloana duplicate
 Ordinea randurilor este neimportanta
 Ordinea coloanalor este neimportanta
 Valorile sunt atomice(nedecompozabile).

4.Structuri de date Mysql

In acest subcapitol sunt prezentate aspectele logice de creare a tabelelor.Desi tabelele pot fi create fara a da
informatii de asezare fizice, ar trebui notat ca un utilizator Mysql WorkBench trebuie sa fi primit privilegiul de
CREATE TABLE de catre administratorul bazei de date si sa aiba alocat ceva spatiu de tabela pentru a crea
tabele.
In general, structurile de date Mysql WorkBench pot fi rezumate dupa cum urmeaza.
 Tabelele pot fi create oricand, chiar cu utilizatori folosind baza de date.
  Nu este necesar sa specificati dimensiunea nici unei tabele. Aceasta este definita ultima prin cat spatiu a
fost alocat bazei de date ca un intreg. Oricum, este important sa se estimatimeze cat de mult spatiu va
utiliza o tabela.
 Structurile pot fi modificate online.
 Tabelele pot capata automat mai mult spatiu daca dimensiunea initiala este umpluta.

4.1 Limbajul de Definire a Datelor (LDD)

LDD este un subset al comenzilor SQL folosit pentru a crea, modifica sau muta structurile bazei de date
ORACLE, si deasemenea sa inregistreze informatii in Dictionarul de Date (acesta este discutat mai tarziu).

4.1.1 Denumirea unei tabele

Numele pe care-l se alege pentru o tabela trebuie sa urmeze regulile standard pentru numirea unui obiect al unei
baze de date Mysql WorkBench.
1. Numele trebuie sa inceapa cu o litera, A-Z sau a-z.
2. Poate contine litere, numerale si caracterele speciale underscore (_). Caracterele $ si # sunt
deasemenea legale, dar folosirea lor este descurajata.
3. Numele este acelasi indiferent daca sunt folosite litere mari sau mici, de exemplu, EMP, emp, si
eMp sunt toate aceeasi tabela.
4. Pot fi de maxim 30 caractere in lungime.
5. Numele nu trebuie sa duplice numele altui obiect din contul dumneavoastra.
6. Numele nu trebuie sa fie un cuvant rezervat SQL.

NUME VALID ? Motiv

EMP85 da
85EMP nu nu incepe cu o litera
FIXED_ASSETS da
FIXED ASSETS nu contine un blank
UP DATE nu cuvant rezervat SQL

4.1.2 Crearea unei tabele

Se creaza o noua tabela folosind comanda CREATE TABLE. Una dintre cele mai simple forme a acestei
comenzi este cand informatia de baza pentru fiecare coloana este definita impreuna cu tipul ei de data si
dimensiunea.
Sintaxa: CREATE TABLE nume tabela
(nume coloana tip(dimensiune),
nume coloana tip(dimensiune),
...);

Exemplu:
CREATE TABLE DEPT
(DEPTNO NUMBER(2),

DNAME VARCHAR2(12),

LOC VARCHAR2(12));

Numele coloanelor intr-o tabela trebuie sa fie unice.

4.1.2.1 Tipurile coloanelor
Cand se creaza o tabela trebuie sa se specifice fiecare tip de data al coloanei. Tabela de mai jos arata cele mai
importante tipuri de date.
Tipul de data poate fi urmat de unul sau mai multe numere in paranteze care dau informatii despre
latimea coloanei. Latimea coloanei determina latimea maxima pe care valorile in coloana pot s-o aiba.
VARCHAR2 trebuie sa aiba o dimensiune, dar cele implicite sunt disponibile.

Tabela de mai jos arata tipurile de date principale in Mysql WorkBench

Tip de date Descriere

VARCHAR2(w) Sir de caractere de lungime maxim w.

Lungimea maxima este de 2000 caractere.
CHAR(w) Sir de lungime fixa w.
Lungimea implicita este 1.
Lungimea maxima este 255.
NUMBER Numere in virgula mobila cu precizie : 38
de cifre semnificative.
NUMBER(w) Numere intregi de precizie w.
NUMBER(w,s) Numere cu precizia w si scala s.
Precizia reprezinta numarul maxim de cifre
semnificative permise care nu pot depasi 38.
SCALA Este numarul de pozitii zecimale inregistrate in dreapta
punctului.
DATE Valorile datei din 1 Ianuarie 4712 inainte
de Hristos pana in 31 Decembrie 4712 dupa Hristos. Informatia
de timp este deasemenea
stocata.
LONG Sir de caractere de lungime variabila de lungime 2 Gb, sau 2 la
puterea 31 minus 1.
Este permisa o singura coloana de tipul LONG pe tabela.

RAW Echivalent cu VARCHAR2 si respectiv LONG,

si dar folosit pentru a stoca date binare ca
LONG RAW imagini grafice sau sunete digitizate.

Tabela de mai jos arata exemple de specificatii de coloane:

NUMBER(4) Poate contine toate numerele pana la 4 cifre.
NUMBER(8,3) Poate contine pana la 8 cifre, dintre care 3
pot fi in dreapta punctului zecimal.
VARCHAR2(1000) Valorile pot contine pana la 1000 caractere.
CHAR(80) Siruri de caractere de lungime fixa egala cu
80. Valorile mai scurte sunt inlocuite cu
blank-uri.

Constrangerea NOT NULL

Aceasta ne asigura ca valorile nule nu sunt permise pentru aceste coloane, de cand aceste coloane servesc ca
chei pentru operatii pe aceasta tabela. Coloanele fara constrangerea NOT NULL permit valori nule. NOT
NULL este una dintre constrangerile de integritate care pot fi definite.

OPTIUNEA DEFAULT
Unei coloane ii poate fi data o valoare implicita prin optiunea DEFAULT. Aceasta previne aparitia de
null-uri (sau erori, daca NOT NULL este specificata) daca o linie este inserata fara o valoare din
coloana.Valorile implicite pot fi literali, o expresie, dar nu numele altei coloane. Functii ca SYSDATE si USER
sunt valide.

4.1.3 Constrangeri de integritate

Mysql WorkBench permite constrangerilor de integritate sa fie definite pentru tabele si coloanelor sa forteze
reguli sigure, inauntrul unei tabele sau intre tabele.
Constrangerile sunt folosite:
 de serverul Mysql WorkBench sa forteze reguli la nivelul tabelei oricand este inserata o linie,
actualizata sau stearsa din acea tabela. Constrangerea trebuie sa fie satisfacuta pentru ca operatiile sa
reuseasca.
 pentru a preveni stergerea unei tabele daca sunt posesiuni din alte tabele.
Constrangerile sunt clasate dupa cum urmeaza:

a. Constrangeri de tabela
Acestea pot referi una sau mai multe coloane si sunt definite SEPARAT de definitiile coloanelor din tabela.
b. Constrangeri de coloana
Acestea refera o singura coloana si sunt definite INAUNTRUL specificatiei pentru coloana posesoare.
Constrangerile pot fi adaugate unei tabele dupa crearea ei si deasemenea temporar dezactivate .Toate detaliile
despre constrangeri sunt stocate in Dictionarul de Date. Fiecarei constrangeri ii este repartizat un nume. Iti este
mai usor sa suplimentezi una tu singur, astfel ca poate fi mai usor referita mai tarziu,dar daca nu, atunci un
nume este generat automat pe forma: SYS_Cn
unde n este un numar unic. Cuvantul cheie CONSTRAINT iti permite sa numesti o noua constrangere tu insuti.

4.1.3.1 Tipuri de constrangeri

Puteti defini urmatoarele tipuri de constrangeri:
 NULL/NOT NULL
 UNIQUE
 PRIMARY KEY
 FOREIGN KEY(integritatea de referinta)
 CHECK

4.1.3.1.1 Constrangerea UNIQUE

Aceasta desemneaza o coloana sau o combinatie de coloane ca o cheie unica.Doua linii in aceeasi tabela nu pot
avea aceeasi valoare pentru aceasta cheie.NULL-urile sunt permise daca cheia unica este bazata pe o singura
coloana.

Sintaxa constrangerii de tabela :

 [CONSTRAINT nume constrangere] UNIQUE (Coloana, Coloana, ...)
Sintaxa constrangerii de coloana :
[CONSTRAINT nume constrangere] UNIQUE

De exemplu, pentru a va asigura ca nu sunt 2 nume de departamente identice la o singura locatie:

CREATE TABLE DEPT

(DEPTNO NUMBER, DNAME VARCHAR2(9),

LOC VARCHAR2(10),

CONSTRAINT UNQ_DEPT_LOC UNIQUE(DNAME,LOC))

In exemplul de mai sus, constrangerea UNQ_DEPT_LOC este o constrangere de ta bela. Virgula precede
detaliile. O constrangere unica il face pe Mysql WorkBench sa creeze un singur index pentru a manui regula.

4.1.3.1.2 Constrangere de cheie primara

Ca si la cheile unice, o cheie primara forteaza unicitatea unei coloane sau combinatii de coloane
implicate si un index unic este creat pentru a conduce aceasta. Totusi poate fi o singura cheie primara pe o
tabela, si aceasta este cunoscuta ca fiind cheia definitiva prin care liniile in tabela sunt identificate individual.
NULL-urile nu sunt permise in coloanele de chei primare.

Sintaxa constrangerii de tabela:

[CONSTRAINT nume constrangere] PRIMARY KEY (Coloana, Coloana, ...)
Sintaxa constrangerii de coloana:
[CONSTRAINT nume constrangere] PRIMARY KEY

Aceeasi combinatie de coloane nu poate fi folosita si pentru o cheie primara si pentru una unica. Urmatorul
exemplu defineste DEPTNO ca o cheie primara folosind o constrangere de coloana:
CREATE TABLE DEPT

(DEPTNO NUMBER(2) CONSTRAINT DEPT_PRIM PRIMARY KEY, ...)

4.1.3.1.3 Constrangere de cheie externa

Cheile externe furnizeaza reguli de integritate de referinta inauntrul unei tabele sau intre tabele. O cheie externa
este folosita intr-o relatie cu fiecare cheie primara sau unica oriunde si poate fi folosita.

Sintaxa constrangerii de tabela:

[CONSTRAINT nume constrangere] FOREIGN KEY (Coloana, Coloana, ...)

REFERENCES tabela (Coloana, Coloana, ...)

Sintaxa constrangerii de coloana:

[CONSTRAINT nume constrangere] REFERENCES tabela (Coloana)

4.1.3.2 Constrangerea de verificare (CHECK)

 Constrangerea CHECK defineste explicit o conditie pe care fiecare linie trebuie sa o satisfaca(sau sa o faca
necunoscuta datorita unui NULL). Conditia poate folosi aceleasi constructii ca acelea intr-o restrictie de
cerere,cu urmatoarele exceptii:
 subcererile nu sunt permise
 referirile la pseudo-coloane ca SYSDATE nu sunt permise

Sintaxa: [CONSTRAINT nume constrangere] CHECK (conditie)

Alte optiuni ale constrangerilor

DISABLE - Adaugand DISABLE unei definitii de constrangere inseamna ca Mysql WorkBench nu o

forteaza. Constrangerea poate fi inca citita de uneltele Mysql pentru a construi reguli intr-o aplicatie si puteti
face posibila constrangerea mai tarziu prin comanda ALTER TABLE.

EXCEPTIONS - Identifica o tabela existenta unde este plasata

INTO nume tabela
informatia despre liniile care incalca constrangerea.

4.1.4 Crearea unei tabele cu linii din alta tabela

Exista o a doua forma a declaratiei CREATE TABLE in care tabela este creata cu linii potrivite, derivate din alta
tabela:
CREATE TABLE DEPT [(nume-coloana ,. . . .)] AS SELECT declaratie
 Tabela va fi creata cu coloane specificate si linii recuperate din declaratia SELECT inserata.
 Numai constrangerile NULL/NOT NULL sunt mostenite din tabela selectata.
 Daca toata coloanele in declaratia SELECT au nume bine definite (nu sunt expresii s.a.m.d.) specificatiile
coloanei pot fi omise.
 Daca sunt date specificatiile coloanei, atunci numarul de coloane trebuie sa fie egal cu numarul de articole in lista
SELECT.

4.1.5 Modificarea unei tabele

Folositi comanda ALTER TABLE pentru a schimba definitia unei tabele.

Sintaxa:
ALTER TABLE nume-tabela
[ ADD ](specificator coloana[constrangere de coloana])[ENABLE clauza ]
[MODIFY ] [DISABLE clauza]
[DROP optiuni]

Clauza ADD
Folositi cuvantul cheie ADD pentru a adauga o coloana si/sau constrangeri pentru o tabela.

Clauza MODIFY
Folositi cuvantul cheie MODIFY pentru a modifica definitia unei coloane existente.

ALTER TABLE nume

MODIFY (tip coloana [NULL])
Sunt 4 schimbari pe care nu se pot face
 Nu se poate schimba o coloana continand null-uri din NULL in NOT NULL.
 Nu se poate adauga o noua coloana care este NOT NULL. Se face null, se umple complet si apoi se
schimba in NOT NULL.
 Nu se poate sa se scada dimensiunea unei coloane sau sa se schimbe tipul de date, numai daca nu
contine date.
 Nu se poate folosi optiunea MODIFY pentru a defini constrangeri pe o coloana exceptand NULL/NOT
NULL.

Pentru a modifica alte constrangeri trebuie sa se elimine si apoi sa se adauge specificand modificarile.

Clauza DROP
Se foloseste clauza DROP pentru a muta o constrangere din alta tabela.
Sintaxa:
ALTER TABLE nume tabela
DROP[CONSTRAINT nume constrangere ] [CASCADE]
[PRIMARY KEY]
[UNIQUE (coloana, coloana, ...)]

Optiunea CASCADE (in clauza DROP)

Optiunea CASCADE a clauzei DROP face ca orice constrangere dependenta sa fie deasemenea
eliminata.

Clauza ENABLE/DISABLE
Aceasta clauza a comenzii ALTER TABLE permite constrangerilor sa fie facute posibile sau
dezactivate fara a le elimina sau recrea.
Sintaxa:
[DISABLE] [ UNIQUE (coloana, coloana, ...) ] [CASCADE]
[ENABLE ] [ PRIMARY KEY ]
[ CONSTRAINT nume constrangere ]

Ca si la clauza DROP, adaugarea cuvantului cheie CASCADE semnifica ca constrangerile dependente sunt
deasemenea afectate.

Alte comenzi LDD

Eliminarea unei tabele
Pentru a sterge definitia unei tabele ORACLE, folositi comanda DROP TABLE.
Sintaxa:
DROP TABLE nume tabela [CASCADE CONSTRAINTS]
Stergerea unei tabele duce la pierderea tuturor datelor din ea si a tuturor indecsilor asociati ei. Optiunea
CASCADE CONSTRAINTS va sterge deasemenea referirile la constrangerile de integritate dependente.
Note:
 Toate datele vor fi deasemenea sterse din tabela.
 Orice VIEWS sau SYNONYMS vor ramane, dar vor deveni invalide.
  Orice tranzactii nerezolvate sunt realizate.
 Numai creatorul tabelei sau DBA poate sa o stearga.

Comanda COMMENT
Se foloseste comanda COMMENT pentru a insera un comentariu pana la 255 de caractere, despre o
tabela sau coloana, in dictionarul de date. Pentru a sterge un comentariu, emiteti comanda COMMENT fara un
comentariu:
COMMENT ON COLUMN EMP.EMPNO IS '';
,/pre>
Pentru a vedea comentariul, selectati coloana COMMENTS din una din vederile dictionarului:
ALL_COL_COMMENTS sau USER_COL_COMMENTS.

Comanda RENAME
Comanda RENAME este folosita de creatorul lui TABLES, VIEWS si SYNONYMS pentru a schimba
numele obiectului bazei de date. Pentru a redenumi un obiect al bazei de date sintaxa este:
RENAME vechi TO nou;
Este important de notat ca orice aplicatii/programe/rapoarte care se refera la obiecte ce au fost
redenumite, trebuie amendate.

Comanda TRUNCATE TABLE

Aceasta comanda permite sa se sterga toate liniile dintr-o tabela.De notat ca comanda DELETE poate
deasemenea realiza aceasta ca o parte a tranzactiei de manipulare a datelor dar comanda TRUNCATE TABLE
umple o tabela mai eficient ca o actiune de definire de date, pana cand nu este retinuta nici o informatie de
rollback.
Sintaxa:
TRUNCATE TABLE nume tabela [REUSE STORAGE]
Optiunea REUSE STORAGE pastreaza spatiul din liniile sterse pentru reutilizarea tabelei. Implicit, acest spatiu
este eliberat.

4.1.6 Inserarea de noi linii intr-o tabela

Comanda INSERT este folosita pentru a adauga linii unei tabele Sintaxa comenzii INSERT este:
INSERT INTO nume tabela [ (coloana,coloana,....)]
VALUES (valoare,valoare,....);

Este posibila inserarea unei noi linii cu valori in fiecare coloana, in care caz lista de coloane nu este
ceruta. Este recomandat ca COLUMN LIST sa fie intotdeauna specificata. Daca lista nu este specificata,
software-ul va cere modificari oriunde definitia tabelei este modificata.Valorile CHARACTER si DATE trebuie
puse in ghilimele simple.

Folosirea Variabilelor de Substitutie pentru a insera linii

Dupa cum am mentionat anterior, INSERT este o comanda pentru o singura linie. Folosind variabile de
substitutie este posibil sa se mareasca viteza de intrare.

Inserarea informatiilor de data si timp

 Cand se insereaza o valoare DATE, formatul DD-MON-YY este de obicei folosit. Cu acest format
secolul implicit este secolul 20 (19nn). Data deasemenea contine informatii de timp, care daca nu sunt
specificate, implicit devin miezul noptii (00:00:00). Daca o data trebuie introdusa in alt secol si un timp specific
este cerut deasemenea, folositi functia TO_DATE
Copierea de linii din alta tabela
INSERT INTO tabela [(coloana, coloana, ....)]
SELECT lista-select
FROM tabela(e)

Aceasta forma a declaratiei INSERT permite sa se insereze cateva linii intr-o tabela unde valorile sunt
derivate din continutul tabelelor existente in baza de date.

4.1.7 Actualizarea liniilor

Declaratia UPDATE va permite sa schimbati valori in liniile unei tabele.
UPDATE tabela[alias]
SET coloana [, coloana...] = {expresie, subcerere}
[WHERE conditie];

Daca clauza WHERE este omisa, toate liniile din tabela vor fi actualizate. Este posibil sa folositi subcereri inlantuite si
subcereri corelate in declaratia UPDATE.
Schimbarile listate in tabela COMMISSION pot fi aplicate tabelei EMP, folosind o subcerere corelata si o
subcerere inlantuita, ca mai jos:

4.1.8 Stergerea Coloanelor dintr-o Tabela

Comanda DELETE permite stergerea unei sau mai multor linii dintr-o tabela.
Sintaxa:
DELETE FROM tabela
[WHERE conditie];

VI. Prezentare Mysql Workbench si realizare baza de date:

1.Instalare Mysql Workbench
In acest subcapitol prezint modalitatea de instalare a toolsetului Mysql Workbench.Acesta un utilitar usor de
folosit si foarte usor de instalat.
Pas 1: Se descarca Mysql Workbench de pe internet.Acesta fiind un toolset free nu este nevoie sa achizitionati
o licenta o data cu el. Descaracare se face de pe site-ul: http://wb.mysql.com
Pas 2: Se lanseaza in executie mysql-workbench-oss-5.2.11-beta-win32.Se da Next.
Pas 3: Se alege tipul instalarii: Diferenta intre complete si custom este aceea ca modul custom ne lasa sa
alegem ce dorim sa instalam si unde vrem sa il instalam.
Pas 4: Dupa alegerea optinilor de la pasul precedent se da Install,se astepta ca acesta sa se termine de instalat
si dupa terminarea acesteia se da Finish.
Pas 5: Se porneste executabilul dupa instalare.
Pas 6: Utilizand interfata grafica a programului se pot crea tabele si relatii intre ele sau se pot folosii
scripturi(prezentate in subcapitolul urmator).
Pas 7: Se da dublu click pe Add Table.In urma acestei operatiuni se va aparea un submeniu care permite
configurarea tebelelordupa cum se poate observa in imaginea urmatoare.
2.Prezentare baza de date
Cel mai răspândit tip de baze de date este cel relaţional, în care datele sunt memorate în tabele. Pe lânga tabele, o
bază de date relaţională mai poate conţine: indecşi, proceduri stocate, trigger-e, utilizatori şi grupuri de
utilizatori, tipuri de date, mecanisme de securitate şi de gestiune a tranzacţiilor etc. Alte tipuri de baze de date
sunt modelul ierarhic, modelul orientat pe obiecte şi, mai nou, modelul XML.
Baza de date Agentie de turism cuntine 18 tabele,fiecare memorand un anumit set de date.
Prezentare table si scripturi aferente crearii lor:

1.Tabelul Persoane
Dupa cum se poate vedea acest tabel contine o cheie primara IdPersoane prin care se face legatura de 1
la N cu tabelul rezervari(o persoana poate face mai multe rezervari) si prin care acesta este unic
identificabil.Pelanga acest camp tabelul mai contine urmatoarele coloane:
 Nume - variabila de tip varchar(45),care identifica numele persoanei care a facut rezervarea
 Prenume – variabila de tip varchar(45),care identifica prenumele personei care a facut rezervarea
 Serie Buletin – reprezinta seria buletinului celui care a facut rezervarea;identifica unui o persoana
 Numar bulletin- variabila de tip INT care identifica unuic o persoana
 CNP- reprezinta cnp-ul persoanei care a facut rezervarea

Script:
create table Persoane(
IdPersoane primary key not null,
Nume varchar(45),
Prenume varchar(45),
SerieBuletin varchar(45),
NumarBuletin int,
Cnp int,);

2.Tabelul Bilete
Acest tabel contine o cheie primara IdBilete prin care se realizeaza identificarea unuica,si o cheie straina
idRezervari prin care se face legatura cu tabelul Rezervari.Legatura este de tipul N la 1(mai multe bilete la o
rezervare).
 Serie – variabia de tip INT care identifica unic un bilet
 Data - variabila de tip DATETIME care identifica data la care are loc calatoria
 Pozitie - variabila de tip varchar(20),care reprezinta pozitia posesorului biletului in mijlocul de
transport
 Ora – indica ora la care are loc plecarea
 Bagaje – indica daca posesorul biletului are bagaje sau nu(este de tip boolean)
 Clasa- indica clasa la care a fost achizitionat biletul(ex.clasa I sau clasa II)

Script:
Create table Bilete(
IdBilete primary key not null,
Serie int,
Data DATETIME,
Pozitie varchar(20),
Ora TIME,
Bagaje Boolean,
Clasa varchar(20),
IdRezervari foreign key references Rezervari(IdRezervari),
);

3.Tabelul Rezervari
Acest tabel este unul care contine numai chei.Acesta face legatura intre diferite elemente.Are o cheie primara IdRezervari
care este referita de cheia secundara din bilete.
 IdPesoane – cheie secundara care face legatura cu tabelul Persoane
 IdPersonal - cheie secundara care realizeaza legatura cu tabelul Angajati
 IdVehicul- cheie secundara care face legatura cu tabelul Vehicul

Script:
Create table Rezervari (
IdRezervari primary key not null,
IdPersoane foreign key references Persoane(IdPersoane),
IdPersonal foreign key references Angajati(IdPersonal),
IdVehicul foreign key references Vehicul(IdVehicul),
);
4.Tabelul Angajati
In acest tabel se stocheaza informatii privind ghiseul de la care se face rezervarea si tot el face trimitere care
tabelul Identitate care ca informatii despre angajatul are face rezervarea(este o detaliere).
 IdPersonal- parte din cheia primara referita de cheia secundara IdPersonal din tabelul Rezervari
 Ghiseu – variabila de tip INT care da detalii despre numarul ghiseului de la care se face rezervarea
 IdIdentitate- parte din cheia primara a tabelului prin care se realizeaza o relatie de 1 la 1

Script:
Create Table Angajati (
IdPersonal primary key not null,
Ghiseu int,
IdIdentitate primary key not null,
);

5.Tabelul Identitate
Acest tabel ofera informatii despre angajatul care face rezervarea.
 IdIdentitate- cheie primara prin care se realizeza relatia de 1 la 1 cu tabelul Angajati
 Nume- variabila de tip varchar(20) care da numele angajatului
 Prenume- variabila de tip varchar(20) care da prenumele angajatului
 Salariu- variabila de tip INT in care se afla informatii despre salariul angajatului.

Script:
Create table Identitate(
IdIdentitate primary key not null,
Nume varchar(20),
Prenume varchar(20),
Salariu int,
);

6.Tabelul Vehicul
Acest tabel da informatii despre vehiculul cu care se face calatoria si face legatura cu tabelul Ruta.

 IdVehicul – cheie primara care este referita de cheia secundara IdVehicul din tabelul Rezervari si prin care se
realizeaza legatura
 Denumire_vehicul – variabila de tip VarChar(20) prin care se specifica tipul de vehicul cu care se face
calatoria(Tren,Avion,Autocar)
 IdRuta – cheie straina prin care se face legatura cu tabelul Ruta

Script:
Create table Vehicul(
IdVehicul primary key not null,
Denumire_Vehicul varchar(20),
IdRuta foreign key references Ruta(IdRuta),
);

7.Tabelul Ruta
Acest tabel furnizeaza date despre rut ape care se face transportul,despre durata calatoriei,numarul total de bilete alocate
rutei respective si numarul de bilete ramase nerezervate.

 IdRuta – cheie primara referita de cheia secundare IdRuta din tabelul vehicule
 Nr_KM- variabila de tip intreg care precizeaza numarul de Km al traseului
 Durata_medie- precizeaza durata calatoriei in conditii favorabile
 Numar bilete total – precizeaza numarul de bilete de pe o anumita cursa
 Numar_bilete_ramase – precizeaza cate bilete mai sunt nerezervate

Script:
Create table Ruta(
IdRuta primary key not null,
Nr_Km int,
Durata_medie int,
Numar bilete total int,
Numar bilete ramase int,
);

8.Tabelele Ruta2,Ruta3,Ruta4
Aceste table contin doar chei,si servesc la realizarea unor legaturi N la M.O sa dau scripturile de creare doar
pentru un singur tabel,pentru restul fiind similare.

Script:
Create table Ruta2(
IdRuta2 primary key not null,
IdTronson foreign key references Tronson_Aerian(Cursa Avion),
IdRuta foreign key references Ruta(IdRuta),
);
9.Tabelul Tronson_Aerian
Acest tabel specifica faptul ca transportul de calatori se face cu avionul .
  Cursa avion- cheie primara referita de cheia straina IdTronson din Ruta2
 Sursa- cheie straina care refera cheia primara din Aeroporturi
 Destinatie- cheie straina care refera cheia primara din Aeroporturi

Script:
Create table Tronson_Aerian(
Cursa avion primary key nor null,
Sursa foreign key references Aeroporturi(IdAeroporturi)
Destinatie foreign key references Aeroporturi(IdAeroporturi)
);

10.Tabelul Tronson_Tren
Acest tabel specifica faptul ca transportul de calatori se face cu trenul .
 Cursa tren- cheie primara referita de cheia straina IdTronson din Ruta3
 Sursa- cheie straina care refera cheia primara din Gari
 Destinatie- cheie straina care refera cheia primara din Gari

Script:
Create table Tronson_Tren(
Cursa tren primary key not null,
Sursa foreign key references Gari(IdGari)
Destinatie foreign key references Gari(IdGari)
);

11. Tabelul Tronson_Autocar

Acest tabel specifica faptul ca transportul de calatori se face cu autocarul.
 Cursa autocar- cheie primara referita de cheia straina IdTronson din Ruta4
 Sursa- cheie straina care refera cheia primara din Autogari
 Destinatie- cheie straina care refera cheia primara din Autogari

Script:
Create table Tronson_Autocar(
Cursa autocar primary key not null,
Sursa foreign key references Autogari(IdAutogari),
Destinatie foreign key references Autogari(IdAutogari),
);

12.Tabelul Aeroporturi
Acest tabel face legatura cu tabelul Orase pentru a putea alege dintre orase ca sursa si ca destinatie.
 IdAeroporturi-cheie primara care identifica unic tabelul
 Aeroporturi-variabila care indica numele aeroportului
 IdOras – cheie straina care refera cheia primara IdOras din tabelul Oras

Script:
Create table Aeroporturi(
IdAeroporturi primary key not null,
Aeroporturi varchar(45),
IdOras foreign key references Oras(IdOras),
);

13.Tabel Gari
Acest tabel face legatura cu tabelul Orase pentru a putea alege dintre orase ca sursa si ca destinatie.
 IdGari-cheie primara care identifica unic tabelul
 Gari- variabila care indica numele garii
 IdOras – cheie straina care refera cheia primara IdOras din tabelul Oras

Script:
Create table(
IdGari primary key not null,
Gari varchar(20),
IdOras foreign key references Oras(IdOras)
);

14.Tabel Autogari
Acest tabel face legatura cu tabelul Orase pentru a putea alege dintre orase ca sursa si ca destinatie.
 IdAutogari-cheie primara care identifica unic tabelul
 Autogari- variabila care indica numele autogarii
 IdOras – cheie straina care refera cheia primara IdOras din tabelul Oras

Script:
Create table(
IdAutogari primary key not null
IdOras foreign key references Oras(IdOras),
Autogari varchar(20)
);

15.Tabelul Oras
Acest tabel contine numele tuturor oraselor in care se afla aeroporturi,gari si autogari.
 IdOras-cheie primara care identifica unic tabelul
 Orase – variabila de tip Varchar(20) care contine numele oraselor
 Tara_IdTara- cheie staina care refera tabelul Tara care specifica numele tarii

Script:
Create table(
IdOras primary key not null,
Orase varchar(20),
Tara_IdTara foreign key references Tara(idTara)
);
16.Tabelul Tara
Acest table specifica numele tarii in caz ca transpotul se face international.
  IdTara-cheie primara care identifica unic tabelul
 Tari – variabila in care se afla numele tarilor.
Script:
Create table(
IdTara primary key not null,
Tari varchar(20)
);
Dupa definirea tabelelor si a legaturilor dintre ele baza de date arata astfel:

VII.Concluzii
Adaptarea la noile cerinte ale tehnologiei informatiei si comunicatiilor impune eforturi sustinute din
partea proiectantilor si programatorilor de aplicatii, pentru asimilarea noutatilor si integrarea lor în produsele
softw
are rezultate.
Tehnologia MySQL este una de mare actualitate în dezvoltarea aplicatiilor cu baze de date de tip
Internet. Aceasta, deoarece avantajele majore aduse de stocarea si prelucrarea informatiei din bazele de date
sau multiplicat prin facilitatile de comunicatie si facilitatile orientate obiect.
Aplicatiile cu baze de date de tip Internet îsi anunta înca din denumire natura dubla, ca urmare a
coexistentei celor doua elemente(bazele de date si comunicatiile).