MINISTERUL EDUCAIEI AL REPUBLICII MOLDOVA

Centrul de Excelen n Informatic i Tehologii Informaionale

Catedra Informatica Aplicat

Programatorul este precum un copil care

ncearc necunoscutul pentru a atinge
absolutul.

la disciplina Asistena pentru Baze de Date

n cadru Lucrul individual

A EFECTUAT: A VERIFICAT:
st.grupei I-1535 profesorul
Mihailenco Mihail V. Bulat

Chiinu 2017
 Cuprins

Sarcina ...................................................................................................................................................... 3
ntroducere ............................................................................................................................................ 4
Tema .......................................................................................................................................................... 6
Proiectarea conceptuala ....................................................................................................................................... 6
Proiectarea logica .....................................................................................................................................................7

Proiectarea bazei de date. ............................................................................................................... 9

Culegerea datelor ................................................................................................................................................... 9

Normalizarea bazei de date ....................................................................................................... 11

Alegerea sistemului de gestiune a bazei de date .............................................................. 11
Proiectarea fizic ................................................................................................................................12
Tranzaciile principale ale sistemului ....................................................................................12
Protecia bazei de date. .................................................................................................................. 13
Elaborarea proiectului................................................................................................................... 13
Crearea tabelelor ....................................................................................................................................................14
Declararea PRIMARY KEY .............................................................................................................................14
Declararea FOREIGN KEY................................................................................................................................14
Declararea CHECK ...................................................................................... Error! Bookmark not defined.
Inserarea datelor ...................................................................................................................................................14

Concluzie............................................................................................................................................... 15
Bibliografie .......................................................................................................................................... 18

2
 Sarcina
S se elaboreze proiectul care prezint descrierea aplicaiei de creare, manipulare ,
interogare a unei baze de date de tip Jucarii.
Aceasta baz de date conine toate informaiile despre jucarii inclusive despre
magazine,producatori,jucarii.Aceste i sunt tabelele pe care le-am folosit n crearea Bazei de
Date.

3
 ntroducere
Anumite principii ghideaz procesul de proiectare al unei baze de date. Primul principiu
este acela c informaiile dublur (numite i date redundante) au o influen negativ, deoarece
consum spaiu i sporesc probabilitatea producerii de erori i inconsistene. Al doilea principiu
l reprezint importana corectitudinii i caracterului complet al informaiilor. Dac baza de date
conine informaii incorecte, orice rapoarte care extrag informaii din baza de date vor conine,
de asemenea, informaii incorecte. Drept urmare, orice decizie luat bazndu-v pe aceste
rapoarte va fi greit informat.
O proiectare bun a unei baze de date este, dup cum urmeaz, una care:
mparte informaiile n tabele pe baza subiectelor, pentru a reduce datele redundante.
Furnizeaz programului Access informaiile necesare pentru a asocia informaiile din
tabele dup necesiti.
Asist i asigur acurateea i integritatea informaiilor.
Adapteaz necesitile de procesare a datelor i cele de raportare.
Avantajele sistemelor de gestiune a bazelor de date fa de sistemele clasice, cu fiiere sunt
urmtoarele:
1. Controlul redundanei datelor Risipa de spaiu care se face prin stocarea acelorai
informaii n mai multe fiiere este mult diminuat prin utilizarea bazelor de date, dar nu
complet eliminat datorit altor cereri de mbuntire a performanelor.
2. Coerena datelor Dac un articol de date e nmagazinat de mai multe ori trebuie s se
garanteze c toate copiile acestuia vor fi actualizate dac se reactualizeaz o valoare a sa
(valoarea articolului e aceeai pentru toate copiile sale).
3. Mai multe informaii de la aceeai cantitate de date Se pot obine prin integrarea fiierelor
ce conin informaii diferite despre aceleai date.
4. Partajarea datelor Datele pot fi utilizate de ctre mai muli utilizatori n acelai timp. De
asemenea se pot face modificri sau adugiri la baza de date existent fr a fi necesar
definirea repetat a tuturor cerinelor referitoare la acestea.
5. Integritatea crescut a datelor Se refer la validitatea i coerena datelor nmagazinate i
se exprim prin constrngeri (reguli de coeren). Constrngerile se pot aplica articolelor
de date din cadrul unei singure nregistrri sau relaiilor dintre nregistrri.
6. Securitatea crescut Se realizeaz prin atribuirea unor nume de utilizatori i parole ce
permit identificarea persoanelor autorizate s foloseasc baza de date i impun
modalitatea de utilizare a acestor date.

4
 7. Aplicarea standardelor Se refer la formatul datelor, conveniile privind denumirile,
documentarea, procedurile de reactualizare, regulile de acces.
8. Reducerea costurilor Prin realizarea integrrii se aloc fonduri centralizat i nu separat
fiecrui departament.
9. Rezolvarea conflictelor Fiecare utilizator va avea propriile cerine ce pot intra n conflict
cu ale altora. Administratorul bazei de date poate lua decizii ce duc la utilizarea optim a
resurselor.
10. Creterea accesibilitii datelor i a capacitii de rspuns Se realizeaz prin intermediul
utilizrii limbajelor de programare din generaia a IV-a
Proiectarea unei baze de date consta din proiectarea schemei conceptuale (logice) si fizice a
acesteia, astfel nct sa raspunda cerintelor utilizatorilor pentru un anumit set de aplicatii. n
general, se considera ca proiectarea unei baze de date se poate diviza n urmatoarele faze:
Colectarea si analiza cerintelor.
Proiectarea conceptuala a bazei de date.
Alegerea unui SGBD.
Proiectarea logica a bazei de date.
Proiectarea fizica a bazei de date.
Cele cinci faze de proiectare enumerate mai sus nu se desfasoara strict ntr-o singura
secventa. n multe cazuri este necesara modificarea proiectului dintr-o faza initiala ntr-una din
fazele ulterioare, pentru a se obtine rezultatele dorite. Aceste bucle de reactie ntre faze (sau n
interiorul unei faze) sunt, n general, frecvente n cursul proiectarii unei baze de date. nainte de a
se proiecta efectiv o baza de date, este necesar sa se cunoasca ce rezultate se asteapta utilizatorii
potentiali sa obtina de la baza de date respectiva si ce informatii primare sunt disponibile pentru
aceasta. De asemenea, este necesar sa se cunoasca ce aplicatii se vor efectua (aplicatii de
gestiune a stocurilor, aplicatii contabile, salarizare, etc.)

5
 Tema
Proiectarea conceptuala
n faza de proiectare conceptuala a bazelor de date se proiecteaza schema conceptuala si
schemele externe ale bazei de date. Desi nu este obligatoriu, aceasta faza se poate mentine
independenta de SGBD si produce un model de date de nivel nalt, care va fi implementat dupa
transpunerea lui ntr-un model de date specific. Chiar daca proiectantii pot porni direct cu
scheme conceptuale specifice unui anumit SGBD (care se mai numesc si scheme logice), este
totusi recomandabil sa se realizeze mai nti schema conceptuala de nivel nalt independenta de
SGBD, deoarece aceasta este o descriere stabila si inavuabila a bazei de date. Alegerea unui
SGBD si deciziile ulterioare de proiectare se pot schimba fara ca aceasta sa se schimbe. Proiectul
conceptual de nivel nalt se realizeaza pe baza cerintelor definite n prima etapa de proiectare si
se reprezinta, n general printr-o diagrama Entitate-Asociere (extinsa).
Modelul Entitate-Asociere (Entity-Relationship Model) este un model conceptual de nivel nalt
al unei baze de date, care defineste multimile de entitati si asocierile dintre ele, dar nu impune
nici un mod specific de structurare si prelucrare a datelor. Elementele esentiale ale modelului
Entitate-Asociere sunt entitatile (entities) si asocierile dintre acestea (relationships). O entitate
(entity) este "orice poate fi identificat n mod distinctiv"; o entitate se refera la un aspect al
realitatii obiective care poate fi deosebit de restul universului si poate reprezenta un obiect fizic,
o activitate, un concept, etc. Orice entitate este descrisa prin atributele sale. Un atribut (attribute )
este o proprietate care descrie un anumit aspect al unei entitati. Toate entitatile similare, care pot
fi descrise prin aceleasi atribute, apartin unui acelasi tip de entitate (entity type), iar colectia
tuturor entitatilor de acelasi tip dintr-o baza de date constitue o multime de entitati (entities set).
n general, n modelul E-A se foloseste aceeasi denumire att 2 pentru un tip de entitate ct si
pentru multimea entitatilor de acel tip. De exemplu, tipul de entitate angajat (al unei institutii)
reprezinta orice persoana angajata a institutiei, care are o anumita functie si primeste un anumit
salariu. Acest tip de entitate poate fi descris prin mai multe atribute, dintre care o parte sunt
atribute de identificare a persoanei (Nume,Prenume,DataNasterii,Adresa), iar altele sunt atribute
legate de activitatea acesteia n institutia respectiva (Functie,Salariu).
n proiectarea bazelor de date se considera doua categorii de entitati: entitati normale (puternice,
obisnuite -regular entities) si entitati slabe (dependente -weak entities). Entitatile normale au o
existenta proprie n cadrul modelului, n timp ce entitatile slabe nu pot exista dect daca exista o
entitate normala (puternica) cu care sunt asociate. De exemplu, o entitate dependent poate sa
reprezinte o persoana care depinde de un angajat al unei institutii (adica se afla n ntretinerea
acestuia). O entitate angajat este o entitate puternica, deoarece ea exista n mod mod normal n
6
modelul activitatii institutiei, n timp ce o entitate dependent este o entitate slaba: nu se va
nregistra o astfel de persoana dect daca parintele (sustinatorul) acesteia este angajat n acea
institutie. O asociere (relationship ) este o corespondenta ntre entitati din doua sau mai multe
multimi de entitati. Gradul unei asocieri este dat de numarul de multimi de entitati asociate.
Asocierile pot fi binare (de gradul 2, ntre 2 multimi de entitati) sau multiple (ntre k multimi de
entitati, k> 2). Asocierile binare sunt, la rndul lor, de trei categorii, dupa numarul elementelor
din fiecare dintre cele doua multimi puse n corespondenta de asocierea respectiva. Fiind date
doua multimi de entitati, E1 si E2, se definesc urmatoarele categorii de asocieri binare:
Asocierea unul-la-unul (one-to-one) este asocierea prin care unui element (entitate) din
multimea E1 i corespunde un singur element din multimea E2, si reciproc; se noteaza cu 1:1.
Asocierea unul-la-multe (one-to-many) este asocierea prin care unui element din multimea E1
i corespund unul sau mai multe elemente din multimea E2, dar unui element din E2 i
corespunde un singur element n multimea E1; se noteaza cu 1:N.
Asocierea multe-la-multe (many-to-many) este asocierea prin care unui element din multimea
E1 i corespund unul sau mai multe elemente din multimea E2, si reciproc; se noteaza cu M:N.
O asociere ntre doua sau mai multe multimi de entitati este, n acelasi timp, o asociere ntre
tipurile de entitati corespunzatoare

Proiectarea logica
n faza de proiectare logica a unei baze de date se realizeaza schema conceptuala globala si
schemele conceptuale (vederile) externe pentru sistemul SGBD ales, pornind de la schema
conceptuala si schemele externe de nivel nalt independente de SGBD, proiectate n faza 34
precedenta. Aceasta faza de proiectare logica poate fi realizata n doua sub-faze: transpunerea
schemei conceptuale n modelul de date al sistemului SGBD ales, dar independent de sistemul de
gestiune propriu-zis si rafinarea schemei conceptuale si a schemelor externe obtinute anterior,
astfel nct sa se utilizeze unele (sau ct mai multe) din facilitatile oferite de sistemul SGBD ales
(modul de generare a cheilor primare, definirea constrngerilor, etc.). Aceste doua sub-faze se
pot realiza mpreuna, folosind unul din instrumentele de proiectare oferite de sistemul SGBD
ales. Rezultatul acestei faze de proiectare l constituie, asadar, schema conceptuala si schemele
externe ale bazei de date, dependente de sistemul SGBD ales si de modelul de date al acestuia.
Pentru transpunerea modelului Entitate-Asociere (reprezentat prin diagrama E-A) n model
relational se parcurg n principal doua etape: proiectarea relatiilor si proiectarea asocierilor.
Proiectarea relatiilor. n Fig. 2.2 este data schema conceptuala a bazei de date relationale
corespunzatoare diagramei E-A din Fig. 2.1, dezvoltata n SQL Server. n SQL Server relatiile si
asocierile ntre ele sunt reprezentate vizual n diagrama de asocieri (Relationships), care este

7
corespondentul relational al diagramei E-A. Multimile de entitati puternice (normale) din
diagrama E-A devin relatii, cu atributele date de atributele entitatilor. n astfel de relatii cheia
primara se defineste fie ca o cheie naturala (combinatie de atribute care definesc n mod unic un
tuplu al relatiei), fie ca o cheie primara artificiala. n exemplul prezentat, n fiecare din relatiile
care corespund multimilor de entitati puternice s-a adaugat cte o cheie primara artificiala
(IdAngajat,IdSectie,IdProiect,etc.). Multimile de entitati slabe din diagrama E-A devin, de
regula, relatii aflate n asociere N:1 cu relatia corespunzatoare multimii de entitati de care acestea
depind. Pentru realizarea acestei asocieri, n relatia dependenta se adauga o cheie straina care
refera cheia primara a relatiei referite (puternice). Cheia primara a unei relatiei dependente poate
fi o combinatie formata din atributul cheie straina si alte atribute care asigura posibilitatea de
identificare unica a unui tuplu, sau poate fi o cheie artificiala. Cheia primara a relatiei
DEPENDENTI este compusa din atributul cheie straina (IdAngajat, care refera cheia primara a
relatiei ANGAJATI) si atributele Nume si Prenume (ale persoanei dependente). Multimile de
entitati care sunt subtipuri ale unui tip de entitate dat devin relatii aflate n asociere 1:1 cu relatia
corespunzatoare multimii de entitati de tipul respectiv (supertip). Pentru realizarea acestei
asocieri. n relatia corespunzatoare subtipului de entitati se defineste o cheie straina care refera
cheia primara din relatia corespunzatoare supertipului de entitati; aceasta cheie straina este n
acelasi timp si cheie primara n relatia corespunzatoare subtipului de entitati. n exemplul
prezentat, asocierile ANGAJATI-INGINERI si ANGAJATI-SECRETARE sunt asocieri 1:1. n
relatia INGINERI atributul IdAngajat este cheie straina care refera cheia primara cu acelasi
nume din relatia ANGAJATI si este n acelasi timp si cheie primara; la fel, n relatia
SECRETARE atributul IdAngajat este cheie straina care refera cheia primara cu acelasi nume
din relatia ANGAJATI si este n acelasi timp si cheie primara. Proiectarea asocierilor. Asocierea
binara N:1 dintre doua multimi de entitati puternice din diagrama E-A se realizeaza n modelul
relational prin intermediul unei chei straine n prima relatie (cea cu multiplicitatea N a asocierii)
care refera cheia primara (sau o cheie candidata) din relatia referita (cea cu multiplicitatea 1 a
asocierii). De exemplu, asocierea N:1 ntre relatiile ANGAJATISECTII se realizeaza prin cheia
straina IdSectie adaugata relatiei ANGAJATI, care refera cheia primara cu acelasi nume a
relatiei SECTII. Asocierea binara M:N dintre doua multimi de entitati din diagrama E-A se
realizeaza n modelul relational prin intermediul unei noi relatii, numita relatie de asociere.
Aceasta noua relatie se afla n asociere M:1, respectiv N:1 cu fiecare din cele doua relatii date
prin intermediul a doua chei straine care refera cheile primare (sau chei candidate) din relatiile
date. De exemplu, pentru a reprezenta asocierea M:N dintre relatiile COMPONENTEPRODUSE
se adauga o noua relatie numita COMPOZITII, care contine cheile straine IdComponenta si
IdProdus, care refera cheile primare cu acelasi nume din relatiile COMPONENTE, respectiv
8
PRODUSE. Cheia primara a unei relatii de asociere poate fi o cheie artificiala sau poate fi
compusa din cheile straine care refera cele doua relatii asociate, eventua l mpreuna cu alte
atribute ale relatiei, care caracterizeaza asocierea respectiva. Asa cum se poate vedea n Fig. 2.2,
cheia primara a relatiei COMPOZITII este formata din cele doua chei straine pe care le contine.
Asocierea binara 1:1 ntre doua multimi de entitati puternice se poate transpune n modelul
relational n doua moduri: fie prin intermediul unei chei straine (ca un caz particular al unei
asocieri N:1), fie printr-o relatie de asociere (ca un caz particular al unei asocieri M:N).
Asocierea binara 1:1 dintre o multime de entitati de un subtip si multimea de entitati supertip din
diagrama Entitate-Asociere este tot o asociere binara cu raportul de cardinalitate1:1 ntre relatiile
corespunzatoare n modelul relational. Acest tip de asociere se realizeaza prin definirea n relatia
corespunzatoare subtipului de entitati a unei chei straine care refera cheia primara din relatia
corespunzatoare supertipului de entitati; aceasta cheie straina este n acelasi timp si cheie primara
n relatia corespunzatoare subtipului de entitati. Acest mod de definire a fost 56 folosit pentru
asocierea dintre tabelele INGINERI, SECRETAREsi tabelul ANGAJATI. Asocierea multipla
M:N:P:. dintre mai mult de doua multimi de entitati din diagrama E-A se realizeaza n mod
asemanator cu asocierea binara, prin intermediul unei noi relatii care se afla n asociere M:1,
N:1, P:1, etc, cu fiecare din relatiile date. Aceasta asociere este realizata prin intermediul mai
multor chei straine, fiecare cheie straina referind cheia primara (sau o cheie candidata) dintr-una
din relatiile date. De exemplu, relatia ACHIZITII realizeaza asocierea ntre relatiile
COMPONENTE, FURNIZORI, ANGAJATI. Ea contine trei chei straine (IdComponenta,
IdFurnizor, IdAchizitor) care refera relatiile COMPONENTE, FURNIZORI, respectiv
ANGAJATI, iar cheia primara este cheia artificiala IdAchizitie.

Proiectarea bazei de date.

Culegerea datelor
Se creaz un tabel ce conine toate datele gsite i de care este necesar a se afla n BD.
1. Adunarea tuturor tipurilor de informaii pe care le nregistrai n baza de date, n scopul
obinerii de informaiile necesare , documente n scopul primirii de decizii care ar
mbunti managmentul ntreprinderii Pentru a gsi i organiza informaiile necesare,
ncepei cu informaiile existente. De exemplu, se pot nregistra comenzile de cumprare
ntr-un registru sau se pot ine informaii despre clieni n formulare, ntr-un dulap pentru
dosare. Colectai aceste documente i trecei n list fiecare tip de informaii afiate (de
exemplu, fiecare caset completat dintr-un formular). Dac nu avei formulare existente,
imaginai-v c trebuie s proiectai un formular pentru a nregistra informaii despre
clieni. Ce informaii ai dori s punei n formular? Ce casete de completat ai crea?
9
 Identificai i trecei n list toate aceste elemente. De exemplu, s presupunem c n
prezent inei lista de clieni pe fie indexate. Examinnd aceste fie vei descoperi c
fiecare fi conine numele, adresa, oraul, statul, codul potal i numrul de telefon ale
unui client. Fiecare dintre aceste elemente poate reprezenta o coloan din tabel.
2. Pe msur ce pregtii lista, nu v facei griji dac nu este perfect din prima ncercare. n
schimb, trecei n list fiecare element la care v gndii. Dac va utiliza i altcineva baza de
date, cerei-i prerea. Lista se poate mbunti ulterior.
3. Apoi, luai n considerare tipurile de rapoarte sau de liste potale pe care dorii s le
obinei din baza de date. De exemplu, se poate crea un raport de vnzri pentru un produs,
care afieaz vnzrile n funcie de regiune sau un raport de rezumare a inventarului, care
afieaz nivelurile de inventar ale produselor. De asemenea, se pot genera scrisori formale,
care li se vor trimite clienilor pentru a i anuna de evenimente sau de oferte speciale.
Proiectai mintal raportul i imaginai-v cum ar arta. Ce informaii ai dori s punei n
raport? Trecei fiecare element n list. Facei acelai lucru pentru scrisoarea formal i
pentru orice alt raport pe care considerai c l vei crea.
4. Proiectarea mental a rapoartelor i a listelor potale pe care dorii s le creai v ajut la
identificarea elementelor de care vei avea nevoie n baza de date. De exemplu, s
presupunem c le oferii clienilor oportunitatea de a se abona (sau a se dezabona) la
actualizri periodice prin pot electronic i c dorii s imprimai o list a celor care s-au
abonat. Pentru a nregistra acele informaii, adugai o coloan Abonat la mesaje de pot
electronic la tabelul pentru clieni. Pentru fiecare client, se poate seta cmpul la Da sau la
Nu.
5. Necesitatea de a le trimite mesaje de pot electronic clienilor sugereaz alt element de
nregistrat. Dup ce tii c un client dorete s primeasc mesaje de pot electronic, va
trebui s aflai adresa de pot electronic la care s le trimitei. Aadar, trebuie nregistrat
o adres de pot electronic pentru fiecare client.
6. Este logic s se construiasc un prototip al fiecrui raport sau listare de ieire i s se ia n
considerare elementele necesare pentru a produce raportul. De exemplu, cnd examinai o
scrisoare formal, se poate s v vin n minte alte idei. Pentru a include o formul
introductiv corespunztoare de exemplu, irul "Dl.", "Dna." sau "Dra." cu care ncepe o
formul de salut, va trebui creat un element pentru introducere. De asemenea, este mai bine
s se nceap scrisorile cu Drag Dl. Georgescu, dect cu Drag Dl. Florin Georgescu.
Aadar, de obicei este mai bine s se stocheze numele de familie separat de prenume.
7. Trebuie s se in cont de faptul c informaiile trebuie desprite n cele mai mici pri
utile. n cazul unui nume, pentru ca numele de familie s fie uor disponibil, se va despri
10
 numele n dou pri Nume i Prenume. Pentru a sorta un raport dup numele de
familie, de exemplu, este util s se stocheze separat numele de familie ale clienilor. n
general, pentru a sorta, cuta, celula sau raporta n funcie de un element informaional,
trebuie pus acel element ntr-un cmp propriu.

Normalizarea bazei de date

Chiar daca toate etapele de pana aici au fost parcurse cu maxima atentie, exista un numar de
probleme care pot sa apara in cazul unor operatii de actualizare in baza de date, probleme care
risca sa compromita integritatea datelor. Este vorba despre asa-zisele anomalii de actualizare,
datorate dependentelor functionale nedorite. Evitarea acestor anomalii se face printr-un proces
numit normalizare, avand o fundamentare formala riguroasa.
Se aduc exemple de tabele nenormalizate dup care se normalizeaz
Prima form normal presupune c exist o singur valoare la fiecare intersecie dintre un rnd
i o coloan din tabel, i niciodat o list de valori. De exemplu, nu poate exista un cmp
denumit Pre n care s plasai mai multe preuri. Dac privii intersecia dintre un rnd i o
coloan ca pe o celul, atunci fiecare celul poate conine o singur valoare.
A doua form normal necesit ca fiecare coloan care nu este cheie s depind complet de
cheia primar, nu doar de o parte a cheii. Aceast regul se aplic cnd se utilizeaz o cheie
primar care conine mai multe coloane.
A treia form normal necesit ca fiecare coloan care nu este cheie s depind de ntreaga
cheie primar, dar i ca toate coloanele care nu sunt chei s fie reciproc independente.

Alegerea sistemului de gestiune a bazei de date

Pentru a crea o aplicaie cu baze de date trebuie ales cel mai potrivit tip de sistem de gestiune al
bazei de date. Acesta trebuie ales n aa fel nct s corespund att necesitilor actuale ct i
celor viitoare. n acest scop trebuie fcut o apreciere asupra caracteristicilor sistemului raportate
la cerinele bazei de date i a aplicaiei (aplicaiilor) create pe baza acesteia.
Aceast faz urmeaz dup faza de modelare conceptual i nainte de faza proiectrii fizice i
const din:
1. Stabilirea costului, care se bazeaz pe:
a. costul de achiziie a programelor;
b. costul mentenanei;
c. costul de achiziie a componentelor hardware;
d. costul de creare a bazei de date sau a conversiei acesteia;
e. costul legat de personal;
f. costul de pregtire a personalului;
11
 g. costul de operare.
2. Modelul de date depinde de:
a. structura i utilizarea datelor;
b. familiarizarea cu sistemul;
c. disponibilitatea serviciilor oferite de ctre productor, a programelor de comunicare, a
programelor de introducere a datelor, a instrumentelor de proiectare i monitorizare etc.

Proiectarea fizic
Proiectarea fizic a bazei de date reprezint procesul de alegere a structurilor de memorare i de
acces la fiierele bazei de date, pentru a obine performane ct mai bune pentru aplicaia
proiectat. Ca parametrii generali de alegere a opiunilor proiectului fizic al unei baze de date
relaionale se pot enumera:
timpul de rspuns, utilizarea spaiului de memorare, capacitatea tranzacional.
Deciziile de proiectare fizic se pot lua numai dup o analiz a aplicaiilor care se vor executa i
n principal, a interogrilor i tranzaciilor pe care acestea le vor lansa. n urma analizei se pot
sintetiza informaii care s dea imaginea de ansamblu a utilizrii atributelor relaiilor bazei de
date: care atribute sunt actualizate cel mai frecvent, care atribute sunt folosite cel mai frecvent n
selecii ale interogrilor, etc. Aceste informaii se folosesc pentru stabilirea indecilor secundari
ai relaiilor.

Tranzaciile principale ale sistemului

Atunci cnd se proiecteaz o baz de date, se cunosc n mare parte i ce tipuri de aplicaii
se vor executa. Un aspect important n proiectarea bazelor de date este specificarea
caracteristicilor funcionale ale acestor aplicaii ct mai devreme n cursul procesului de
proiectare, astfel nct schema bazei de date s includ toate informaiile necesare cu privire la
aceste aplicaii. n plus, cunoaterea importanei relative a diferitelor tranzacii executate de
aplicaiile bazei de date, precum i a frecvenei 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,tranzactii de
actualizare si tranzactii mixte,care executa atat interogari cat si actualizari.
Pentru dezvoltarea ulterioara 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
tranzacii. Totui, cele mai importante tranzacii sunt cel mai adesea cunoscute nainte de
12
 implementarea sistemului. Dac operaiile de acces la baza de date ale unei tranzacii sunt
numai operaii de citire, acea tranzacie se numete tranzacie de citire (read-only
transaction) i controlul concurenei unor astfel de tranzacii este mult mai simplu.

Protecia bazei de date.

Prin securitatea bazelor de date se intelege protejarea bazelor de date impotriva folosirii
neautorizate a lor si in special a modificarilor si distrugerilor nedorite de date si a citirilor
nepermise . Pentru realizarea securitatii datelor din baza de date se utilizeaza controale tehnice si
administrative.
Securitatea este in general asociata cu urmatoarele situatii:
-acces fraudulos la date,
-pierderea confidentialitatii (secretului) datelor,
-pierderea caracterului privat al datelor,
-pierderea integritatii datelor,
-pierderea disponibilitatii datelor
Notiunea de securitate a bazei de date este de obicei asociata cu accesul rauvoitor, pe cand
integritatea se refera la evitarea pierdelor accidentale de consistenta. Adevarul este insa undeva la
mijloc.
Pentru protectia bazei de date se pot lua masuri de asigurare a securitatii la mai multe nivele:
-la nivel fizic - locurile in care se afla calculatoarele trebuie protejate de accesul persoanelor
neautorizate;
-la nivel uman - este recomandabil sa se acorde autorizatiile de acces cu multa grija si sa se tina
evidente stricte ale persoanelor autorizate
-la nivel sistem de operare - slabiciunile protectiei la nivel de sistem de operare trebuie eliminate
sau compensate de alte masuri
-la nivel SGBD - sistemul ofera anumite facilitati care sprijina protectia datelor
Este mai dificil protejarea datelor mpotriva accesului ruvoitor, intenionat.
Nu exista protectie absolut sigura ci doar protectii si masuri de securitate mai eficiente sau
mai putin eficiente.
Protejarea datelor prin codificare (criptare). Deoarece s-ar putea ajunge la date si prin alte
mijloace decat prin intermediul SGBD-ului (de exemplu prin citirea directa a mediului magnetic)
se poate face o protectie prin pastrarea codificata a datelor pe mediul magnetic. Decodificarea
datelor se poate face numai dupa identificarea utilizatorului.

Elaborarea proiectului
Elaborarea proiectului const n executarea urmtorilor pai:
13
 Proiectarea BD;
Crearea BD;
Culegerea textului MC Word

Crearea tabelelor
CREATE DATABASE Jucarii1
USE Jucarii1
GO
Create table Principal
(
id_jucarie int not null,
id_magazin int not null,
id_producator int not null,
);
Create table Jucarii
(
id_jucarie int not null,
denumire_jucarie char(50)not null,
tip_jucarie char(20) not null,
pret_jucarie int not null,
);
Create table Magazine
(
id_magazin int not null,
proprietar char(30) not null,
Adresa char(30) not null,
nr_telefon int not null,
);
Create table Producator
(
id_producator int not null,
producator char(30) not null,
Brand char(30) not null,
adresa_web char(30) not null,
Telefon int not null,
Declararea PRIMARY KEY
ALTER TABLE Principal WITH NOCHECK ADD CONSTRAINT PK_Principal PRIMARY
KEY CLUSTERED(id_jucarie,id_magazin,id_producator);
ALTER TABLE Jucarii WITH NOCHECK ADD CONSTRAINT PK_Jucarii PRIMARY KEY
CLUSTERED(id_jucarie);
ALTER TABLE Magazine WITH NOCHECK ADD CONSTRAINT PK_Magazine PRIMARY
KEY CLUSTERED(id_magazin);
ALTER TABLE Producator WITH NOCHECK ADD CONSTRAINT PK_Producator
PRIMARY KEY CLUSTERED(id_producator);
Declararea FOREIGN KEY
ALTER TABLE Principal ADD CONSTRAINT FK_Principal_Jucarii FOREIGN
KEY(id_jucarie)REFERENCES Jucarii(id_jucarie);
ALTER TABLE Principal ADD CONSTRAINT FK_Principal_Magazine FOREIGN
KEY(id_magazin)REFERENCES Magazine(id_magazin);
ALTER TABLE Principal ADD CONSTRAINT FK_Principal_Producator FOREIGN
KEY(id_producator)REFERENCES Producator(id_producator);

14
 Inserarea datelor
------------------------------------------
---Inserarea datelor in tabelul Principal
------------------------------------------
INSERT INTO Principal (id_jucarie,id_magazin,id_producator)
VALUES (1574,1920,5555);
INSERT INTO Principal (id_jucarie,id_magazin,id_producator)
VALUES (1575,1921,6666);
INSERT INTO Principal (id_jucarie,id_magazin,id_producator)
VALUES (1576,1922,7777);
INSERT INTO Principal (id_jucarie,id_magazin,id_producator)
VALUES (1577,1923,8888);
INSERT INTO Principal (id_jucarie,id_magazin,id_producator)
VALUES (1578,1924,9999);
------------------------------------------
---Inserarea datelor in tabelul Jucarii
------------------------------------------
INSERT INTO Jucarii
(id_jucarie,denumire_jucarie,tip_jucarie,pret_jucarie)
VALUES (1574,'Ninjago','LEGO',150);
INSERT INTO Jucarii
(id_jucarie,denumire_jucarie,tip_jucarie,pret_jucarie)
VALUES (1575,'Kitty Club','Figurina',120);
INSERT INTO Jucarii
(id_jucarie,denumire_jucarie,tip_jucarie,pret_jucarie)
VALUES (1576,'My Little Pony','Figurina',170);
INSERT INTO Jucarii
(id_jucarie,denumire_jucarie,tip_jucarie,pret_jucarie)
VALUES (1577,'Dinozaur','Robot',130);
INSERT INTO Jucarii
(id_jucarie,denumire_jucarie,tip_jucarie,pret_jucarie)
VALUES (1578,'2D','Puzzle',200);
------------------------------------------
---Inserarea datelor in tabelul Magazine
------------------------------------------
INSERT INTO Magazine (id_magazin,proprietar,Adresa,nr_telefon)
VALUES (1920,'Ion Verde','Sarmizegetusa 31',068342215);
INSERT INTO Magazine (id_magazin,proprietar,Adresa,nr_telefon)
VALUES (1921,'Curechi Alexandru','Blvd Decebal 70',069141415);
INSERT INTO Magazine (id_magazin,proprietar,Adresa,nr_telefon)
VALUES (1922,'Negru Valeriu','Cuza Voda 32',060131211);
INSERT INTO Magazine (id_magazin,proprietar,Adresa,nr_telefon)
VALUES (1923,'Rosie Ion','Burebista 19',061111213);
INSERT INTO Magazine (id_magazin,proprietar,Adresa,nr_telefon)
VALUES (1924,'Balica Igor','Stefan cel Mare 11',062342115);
------------------------------------------
---Inserarea datelor in tabelul Producator
------------------------------------------
INSERT INTO Producator
(id_producator,producator,Brand,adresa_web,telefon)
VALUES (5555,'Juno','Romanesc','juno.ru',068284812);

15
INSERT INTO Producator
(id_producator,producator,Brand,adresa_web,telefon)
VALUES (6666,'Noriel','Romanesc','noriel.ro',069324356);
INSERT INTO Producator
(id_producator,producator,Brand,adresa_web,telefon)
VALUES (7777,'DToys','Romanesc','dtoys.ro',079373285);
INSERT INTO Producator
(id_producator,producator,Brand,adresa_web,telefon)
VALUES (8888,'Plastor','Romanesc','plastor.ro',069342231);
INSERT INTO Producator
(id_producator,producator,Brand,adresa_web,telefon)
VALUES (999,'Flaro','Romanesc','flaro.ro',068224351);

16
 Concluzie
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 software rezultate. Tehnologia SQL 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).

17
 Bibliografie
Crstoiu, Dorin, Baze de date relaionale, Editura Printech, 1999
Rdulescu, Florin, Baze de date n Internet, Editura Printech, 2000
Pribeanu, Costin, Baze de date i aplicaii, Editura MatrixRom, 2000
Ionescu, Felicia, Baze de date relaionale i aplicaii, Editura Tehnic, 2004
http://www.umfcv.ro/files/0/3/03_Baze%20de%20date.pdf
http://www.seap.usv.ro/~sorinv/CursBD%20Cibernetica.pdf

18