Sarcina: Catedra Informatica Aplicată

MINISTERUL EDUCAŢIEI REPUBLICII MOLDOVA
CENTRUL DE EXCELENŢĂ ÎN INFORMATICĂ ŞI TEHNOLOGII INFORMAŢIONALE
Catedra Informatica Aplicată

Complexitatea programului creşte
până ce depăşeşte abilitatea programatorului care
trebuie să-l întreţină.
Legea 7 a lui Hinds
la disciplina „Asistența bazelor de date”

în cadrul lucrului individual
Tema: „Proiectarea logica a bazei de date”
A EFECTUAT: A VERIFICAT:
st. grupei I-1435 profesorul
Cazacliu Cristian V. Bulat
Chişinău 2016
Sarcina
Informațiile despre imobilul și răspunzătorii de auditoare din colegiu sunt stocate într-o bază de date.
De elaborat un proiect, a cărei aplicație respectivă, folosind meniuri, rapoarte formulare și

subprogram, realizează, la solicitarea utilizatorului, următoarele funcționalități:
1) Înregistrează un nou auditoriu;

2) Exclude din baza de date înregistrarea ce corespunde numărului de auditoriu introdus de la
tastatură;
3) Determină răspunzătorul, asociat auditoriului cu numărul introdus de la tastatură;
4) Afișează la ecran atributele auditoriului: numărul și imobilul, asociate răspunzătorului introdus
de la tastatură;
5) Determină răspunzătorii angajați după specialitatea informatică și după anul 2013, introdusă
de la tastatură;
6) Afișează la ecran răspunzătorii de auditoare, în ordinea alfabetică a numelor acestora;
7) Afișează lista numerelor impare a cabinetelor, înregistrate în baza de date;
8) Creează o tabelă, în care se vor copia datele, care corespund imobilelor din auditoare, numărul
căreia este introdus de la tastatură.
2
Introducere
Această bază de date elaborată are scopul de a duce evidența imobilului din colegiu. Cu ajutorul
acestei baze de date se va putea controla mai ușor starea și numărul de imobil din auditoare. Cred că este o
necesitate foarte mare în astfel de bază de date, doarece doar în așa mod se poate gestiona cu auditoarele și
imobilul simplu și ușor.
O bază de date este un ansamblu de date, înregistrate pe un suport accesibil calculatorului, pentru a
satisface simultan cerințele mai multor utilizatori într-un mod selectiv și într-un timp rezonabil.
În ultimii ani, dezvoltarea sistemelor de baze de date reprezintă unul dintre cele mai importante
aspecte în domeniul tehnologiei informaţiei, având un impact decisiv asupra modului de organizare şi
funcţionare a numeroaselor instituţii şi servicii. Acestea sunt companiile de comunicaţie, intreprinderile de
comerţ, serviciile bancare, serviciile de transport, asigurările, universităţile etc. Acestea sunt dependente de
funcţionarea corectă şi neîntreruptă a sistemelor de baze de date.
3
Cuprins
Sarcina..........................................................................................................................2
Introducere...................................................................................................................3
Baza de date.................................................................................................................8
Inventarierea atributelor............................................................................................8
Determinarea cheii primare.......................................................................................8
Eliminarea atributelor calculabile.............................................................................8
Normalizarea bazei de date........................................................................................8
Baza de date nenormalizată......................................................................................10
Proiectarea bazei de date..........................................................................................15
1. Determinarea scopului bazei de date..........................................................15
2. Determinarea datelor necesare....................................................................15
3. Determinarea cîmpurilor.............................................................................15
4. Determinarea relațiilor dintre tabele..........................................................15
5. Crearea bazei de date...................................................................................16
6. Crearea tabelelor..........................................................................................16
7. Modificarea structurii bazei de date...........................................................16
8. Popularea bazei de date................................................................................16
9. Imbunătățirea bazei de date........................................................................16
Eliminarea dependențelor funcționale parțiale......................................................17
Eliminarea dependențelor funcționale tranzitive...................................................17
Baza de date normalizată..........................................................................................18
Tipuri de date.............................................................................................................25
4
Concluzie....................................................................................................................27
5
1. Tema
Proiectarea logică a bazei de date
Proiectare logica este procesul de construcție a unui model de informații folosite într-o întreprindere, bazata
pe modelul de date, dar independent de particularizările sistemului de gestiune a bazei de date si a altor
considerente fizice.
Proiectarea logica a bazei de date se divide în trei pasi mari. Primul pas are ca obiectiv,
descompunerea proiectarii sistemului informatic în vederi, care se pot discuta cu utilizatorii sistemului.
Modelul de date astfel creat, se valideaza prin normalizare si prin tranzactii în pasul doi. În final, se
genereaza modelul global al întreprinderii, cars este la rândul lui validat si verificat cu ajutorul utilizatorului
sistemului.
Factori critici pentru succesul proiectarii logice:

 Lucrul interactiv cu utilizatorul sistemului.
 Folosirea unei metodologii structurate pentru procesul de proiectare a bazei de date.
 Încorporarea regulilor de integritate în modelul logic de date.
 Combinarea validarii conceptuale, prin normalizare si prin tranzactii, la proiectarea modelului logic
de baze de date.
 Utilizarea diagramelor pentru a reprezenta cât mai multe modele logice posibile.
 Crearea dictionarului de date, ca supliment al modelului de date.
Pasul 1. Crearea modelului conceptual local, pentru utilizatori.

Obiectivul: Crearea unui model conceptual local, pentru view-urile utilizatorilior.
Primul pas în proiectarea bazei de date este de a colecta datele necesare pentru realizarea sistemului,
ceea ce putem culege, discutând cu viitorii tilizatori ai bazei de date. Acrasta discutie presupune o despartire
în vederi, a bazei de date, vederi care pot lucra separat.
Despartirea în vederi se poate realiza în mai multe moduri. O modaliate ar fi analiza datelor globale
si gasirea de parti relativ independente. O alta modalitate ar fii analiza rapoartelor, procedurilor cerute si/sau
observarea sistemului existent în lucru.
Modelele conceptuale locale trebuie sa contina:
 tipuri de entitati,
 tipuri de relatii,
 atribute,
 domeniile atributelor,
 cheile candidat,
 chei primare
Pasul 1.1. Identificarea tipurilor de entitati
Obiectivul: Identificarea tipurilor de entitati principale în vederile utilizatorilor.
Primul pas în proiectarea bazei de date este identificarea entitatiilor din datele furnizate de utilizatori.
Exista cazuri când entitatiile sunt greu de identificat, pentru ca modul de prezentare a viitorilor
utilizatori necesita explicatii. Utilizatorii descriu aceste entitati, folosind sinonime si omonime, ceea ce
îngreuneaza identificarea entitatilor. Sinonimele prin care se descrie aceasi entitate, se pot considera
sinonime si la crearea modelului logic, evidentiind aceste sinonime ca diverse aliasuri ai entitatiilor.
Pasul 1.1. Identificarea tipurilor de entitati.
Începem sa identificam tipurile de entitati din toate vederile utilizatorilor. Vom descrie separat
identificarea acestor entitati pentru cele doua vederi.
Pasul 1.2. Identificarea tipurilor de relatii

Obiectivul: Identificarea relatiilor importante dintre entitati.
Dupa identificarea entitatiilor, va trebui sa identificam si relatiile importante dintre aceste entitati.
La identificarea relatiilor vom lua în considerare doar relatiile care ne intereseaza. Degeaba
exista si alte relatii care sa se poata identificate, daca nu prezinta importanta pentru problema noastra, atunci
nu le luam în consideratie.
6
În cele mai multe din cazuri, relatiile sunt binare, adica se realizeaza întrea exact doua entitati.
Exista si relatii mai complexe, care se realizeaza între mai multe entitati, sau relatii recursive, care pune în
relatie o singura entitate cu ea însasi.
Pasul 1.3. Identificarea si asocierea de atribute la tipurile de entitati si tipurile de relatii
Obiectivul: Asocierea de atribute la tipurile de entitati si la tipurile de relatii.
Urmatorul pas în metodologie este identificarea atributelor. Aceste atribute se identifica în aceeasi
mod ca si entitatiile. Pentru o mai usoara identificare, trebuie sa luam entitatiile si relatiile ra rând si sa ne
punem urmatoarea întrebare: Ce informatii detinem despre aceasta . ? Raspunsul la aceasta întrebare ne va
da atributele cautate.
Atribute simple sau compuse

Este important sa notam daca un atribut este simplu sau compus. Conform acestei informatii va
trebui sa luam decizii referitoare la acel atribut. Daca un atribut este compus, atunci putem opta pentru
descompunerea sa, daca este necesara prelucrarea separata a detelor compuse, sau putem sa-l lasam compus
în caz contrar.
Atribute derivate (calculate)
Sunt acele atribute, care se pot calcula din alte atribute existente în baza de date. De exemplu
numarul locatarilor de pe o scara se poate numara în tipul de entitate Locatari. Deci acest atribut este atribut
derivat.
În general aceste atribute nu trebuie incluse în modelul de date, pentru ca în cazul în care se modifica
atributul din care se calculeaza atributul derivat, trebuie sa se modifice si acesta. În cazul în care nu se
modifica, baza de date devine inconsistenta. De aceea este important de a mentiona daca un atribut este sau
nu derivat.
Daca identificam un atribut care sa nu-l putem asocia nici unei entitati sau relatii, ne întoarcem la
pasii anteriori, identificând noua relatie sau entitate la care sa asociem atributul respectiv.
În cazul în care putem asocia acelasi atribut la mai multe entitati, atunci va trebui sa decidem daca
generalizam sau nu aceste entitati, proces care este descris la pasul 1.6.
Pasul 1.3. Identificarea si asocierea atributelor la tipurile de reletii si tipurile de entitati.
În acest pas identificam atributele ce se asociaza tipurilor de entitati sau tipurilor de relatii. Atributele
sunt informatii care caracterizeaza entitatile, resoective relatiile. Aceste atribute le putem gasi în descrierea
acordata de utilizatori.
Pasul 1.4. Determinarea domeniilor atributelor
În acest pas determinam domeniile atributelor. Domeniul unui atribut este nultimea acelor valori, pe care le
poate lua în lucrul de zi cu zi.
Pasul 2. Crearea si validarea modelului logic local
Obiectivul: Crearea unui model logic local bazata pe modelul conceptual al utilizatorilor asupra
întreprinderii si validarea ei prin procesul de normalizare si prin tehnica tranzactiilor cerute.
În acest pas verificam modelul conceptual creat în pasul anterior si eliminam din el structurile care
sunt dificil de realizat într-un SGBD. Daca la sfârsitul acestui proces modelul ete alterat, vom corecta aceste
probleme si ne vom referi în continuare la modelul rezultat, ca fiind modelul logic local. Vom valida
modelul logic prin procesul de normalizare si a tranzactiilor.
Pasul 2.1. Proiectarea modelului conceptual local pe modelul logic local

Obiectivul: Verificarea modelului conceptual local pentru eliminarea structurilor care se pot
implementa greu într-un SGBD si proiectarea modelului rezultat la modelul logic local.
În pasul întâi am pregatit un model conceptual bazat pe informatiile date de utilizator. Acest model
trebuie prelucrat, pentru a putea fi usor de prelucrat de sistemul de gestiune a bazelor de date.
Eliminarea relatiilor multe-la-multe
7
Daca în modelul de date apar relatii de tipul multe-la-multe (M:N), trebuie descompuse în doua
relatii unu-la-multe (1:M) prin adaugarea unei noi entitati suplimentare.
De exemplu, pot exista mai multe cheltuieli pentru o scara, dar si o cheltuiala (factura) poate sa se
refere la mai multe scari. Deci relatia dintre entitatea Scari si entitatea Cheltuieli este de M:N, ceea de este
evidentiat în figura 6.1.(a).
Eliminarea relatiilor complexe
O relatie complexa este o relatie între mai mult de coua tipuri de entitati. Daca în modelul conceptual
apar relatii complexe, acestea trebuie eliminate. Se pot elimina prin crearea unui nou tip de entitate, care sa
fie în relatie de tipul 1:M cu fiecare tip de entitate din relatia initiala, partea cu M a relatiei fiind spre tipul de
entitate nou creat.
Eliminarea relatiilor recursive
Relatiile recursive sunt niste relatii particulare, prin care un tip de entitate este în relatie cu el însusi.
Daca apare o astfel de relatie în modelul conceptual, ea trebuie eliminata. Eliminarea se poate rezolva prin
crearea unei noi entitati unde sa se evidentieze fiecare entitate care este legata de entitatea din tipul de
entitate initial. În acest caz vom avea o relatie de tipul 1:M între tipul de entitate initial si tipul de entitate
nou creat si o relatie de tipul 1:1 între tipul de entitate nou creat si tipul de entitate initial.
Eliminarea relatiilor cu atribute
Daca în modelul conceptual avem relatie cu atribute, putem descompune aceasta relatie, identificând
un nou tip de entitate în care sa înregistram atributele necesare.
Eliminarea relatiilor redundante
O relatie este redundanta daca se poate ajunge de la un tip de entitate la alt tip de entitate pe mai
multe drumuri. Va amintim ca noi vrem sa ajungem la un model minimal si deci relatiile redundante nu sunt
necesare. Decizia ca o relatie este redundanta trebuie sa fie precedata de o analiza amanuntita a relatiilor
care compun cele doua drumuri dintre cele doua entitati, pentru ca pot aparea situatii, când o relatie este
aparent redundanta, dar în realitate este nevoie de ea.
În finalul acestui pas putem spune ca am eliminat din modelul conceptual acele structuri care sunt
dificil de implementat si deci este mai corect ca în continuare sa ne referim la acest model ca fiind un model
logic local de date.
Pasul 2.2. Crearea de relatii peste modelul logic local
Obiectivul: Crearea de relatii peste modelul logic.
Relatia pe care un tip de entitate o are cu alt tip de entitate este reprezentata prin mecanismul cheie
primara/cheie straina. Cheia straina pentru o entitate este reproducerea cheii primare a altei entitati. Pentru a
decide entitatiile unde vom include copia cheii primare a altei entitati, trebuie înainte sa identificam entitatile
"parinte" si "fiu". Entitatile "parinte" se refera la acele entitati ale caror chei primare se vor copia în entitatile
"fiu".
Pentru descrierea relatiilor vom folosi un limbaj de definire a bazei de date (Database Definition
Language - DDL). În acest limbaj, specificam prima data numele entitatii, urmat de atributele asociate între
paranteze. Dupa aceea identificam cheia primara si toate cheile alternante, precum si/sau cheile straine.
Tipuri de entitati tari

Pentru tipurile de entitati tari în modelul logic crearea unei relatii include toate atributele entitatii.
Pentru atributele compuse al unei entitati, vom include numai atributele simple din compunerea atributului
compus în descrierea entitatii.
Tipurile de entitati slabe

Descrierea tipurilor de entitati slabe se face la fel ca si tipurile de entitati tari, cu o completare si
anume, evidentierea cheii straine.
Mentionam ca în cazul acesta cheia straina este si în compunerea chei primare. Deci înainte de
introducerea cheii straine, cheia primara nu identifica unic o entitate. La terminarea acestui pas, putem
identifica cheile prinare pentru toate tipurile de entitati din modelul logic.
Tipurile de relatii binare de tipul unu-la-unu (1:1)
Pentru fiecare tip de relatie binara de tipul 1:1 între doua tipuri de entitate E1 si E2 gasim o copie a
cheii primare a tipului de entitate E1 în compunerea tipului de entitate E2, sub denumirea de cheie straina.
Identificarea tipului de entitate "parinte" si a tipului de entitate "fiu" depinde de participarea entitatilor la
8
relatie. Tipul de entitate care participa partial la relatie este desemnat ca fiind "parinte" iar cel cu participare
totala "fiu". Daca ambele tipuri de entitate participa partial sau total la relatie, atunci tipurile de entitati se
pot evidentia ca fiind "parinte" sau "fiu" arbitrar. În cazul în care participarea este totala, putem încerca sa
combinam cele doua tipuri de entitati într-una singura. Aceasta compunere poate sa fie posibila în cazul în
care nici unul dintre cele doua tipuri de entitati nu mai ia parte la alta relatie.
Tipurile de relatii binare de tipul unu-la-multe 1:M
Pentru toate relatiile 1:M între doua entitati E1 si E2 în modelul logic de date, vom avea copia cheii
primare a entitatii E1 în compunerea entitatii E2. Totdeauna entitatea de partea unu a relatiei este
considerata entitate "parinte", iar cealalta entitate "fiu".
Atributele cu mai multe valori
Pentru ficarea atribut A care permite mai multe valori din entitatea E1 în modelul logic de date,
cream o noua relatie care va contine atributul A împreuna cu cheia primara a entitatii E1 pe post de cheie
straina.
Documentarea relatiilor si a atributelor din cheile straine
Actualizam dictionarul de date, întroducând fiacare atribut nou introdus în compunerea unei chei la
acest pas.
Pasul 2.3. Validarea, utilizând normalizarea
Obiectivul: Validarea modelului logic, utilizând tehnica normalizarii.
Examinam procesul de normalizare dupa cum am descris în capitolul 5 Prin normalizare trebuie sa
demonstram ca modelul creat este consistent, contine redundanta minimala si are stabilitate maxima.
Normalizarea este procesul prin care se decide daca atributele pot sau nu sa ramâna înpreuna.
Conceptul de baza a teoriei relatiilor este ca atributele sunt grupate împreuna pentru ca exista o relatie logica
între ele. Câteodata baza de date nu este cea mai eficienta. Acesta se argumenteaza prin urmatoarele:
Proiectarea normalizata organizeaza datele în functie de dependentele functionale. Deci acest proces este
situat undeva între proiectarea conceptuala si cea fizica.
Proiectul logic nu este un proiect final. El ajuta priectantul sa înteleaga natura datelor în întreprindere.
Proiectul fizic poate fi diferit. Exista posibilitatea ca unele tipuri de entitati sa se denormalizeze. Totusi
normalizarea nu este un timp pierdut.
Proiectul normalizat este robust si independent de anomaliile de actualizare prezentate în capitolul 5.
Calculatoarele moderne au mult mai multa putere de calcul, ca cele de acum câtiva ani. Din aceasta cauza,
câteodata este mai convenabila implementarea unei baze de date cu putina redundanta, decât suportarea
cheltuielilor pentru procedurile aditionale.
Normalizarea produce o baza de date care va fi usor extensibila în viitor.
Pasul 2.4. Validarea modelului prin tranzactii
Obiectivul: Verificarea ca modelul de date suporte toate tranzactiile cerute de utilizator.
În acest pas se valideaza baza de date prin verificarea tranzactiilor ce se cer de catre utilizator. Luând
în considerare tipurile de entitati, relatiile, cheile primare si straine, încercam sa rezolvam manual cerintele
utilizatorilor. Daca reusim sa rezolvam fiecare tranzactie ceruta, atuci înseamna ca modelul creat este valid.
Daca nu putem rezolva o tranzactie, atunci este foarte posibil sa fi omis un atribut, o relatie, sau o entitate
din modelul de date.
Trebuie sa examinam daca baza de date suporta tranzactiile cerute. Mai întâir fi prin rezolvarea de
tranzactii. De exemplu sa luam relatia dintre Furnizori si Cheltuieli exemplificata în figura 6.3.
Cheia primara al acestei entitati este Nr_furnizor. Deci prima data verific daca numarul introdus nu
exista deja; dupa care, în caz ca nu exista acest cod, inserez detaliile despre furnizor. Daca exista deja codul,
nu admit inserarea. Pot verifica si existenta codului fiscal, care pentru aceasta entitate este cheie alternanta.
Stergerea detaliilor despre un furnizor
Se cauta codul furnizorului de sters. Daca exista se sterge furnizorul, actualizându-se si cheia straina
în entitatea Cheltuieli. Daca nu exista codul cerut, atunci apare un mesaj de eroare si nu este sters nici un
furnizor.
A doua modalitate de verificare trebuie folosita în cazul în care avem entitati care nu iau parte direct
la nici o tranzactie. Pentru verificarea acestor entitati, vom verifica niste interogari pregatie special.
Pasul 2.6. Identificarea regulilor de integritate.
Obiectivul: Identificarea regulilor de integritate pentru vederile utilizatorilor asupra întreprinderii.
9
Regulile de integritate sunt importante pentru a proteja baza de date împotriva posibilelor
inconsistente. Daca este necesar, putem produce un proiect fizic de baza de date, pentru a putea vedea mai
usor ce reguli sunt necesare.
Necesitatea datelor
Exista atribute care nu pot contine valoarea nula, ci trebuie sa aiba totdeauna o valoare. De
exemplu fiecare cheltuiala înregistrata trebuie sa aiba asociat un furnizor al serviciilor sau al obiectelor ce se
platesc prin acea cheltuiala.
Aceste reguli deja le-am identificat, când am documentat atributele în pasul 1.3.
Reguli asupra domeniului atributelor.
Unele atribute au un domeniu de definitie bine definit. Aceste domenii trebuie respectate. Domeniile
de definitie au fost deja identificate când am documentat domeniile atributelor în pasul 1.2.
Integritatea entitatilor.
Cheia primara a entitatilor nu poate lua valori nule. De exemplu fiecare furnizor trebuie sa aiba un
cod diferit de zero.
Aceste reguli au fost deja identificate, când am documentat cheile primare în pasul 1.5.
Integritatea referintelor
Cheia straina din tipul de entitate "fiu" face ligatura cu o entitate din tipul de entitate "parinte".
Deci, daca cheia straina contine o valoare, ea trebuie neaparat sa se regaseasca si în tipul de entitate
"parinte". De exemplu tipul de entitate Cheltuieli contine cheia straina Cod_furnizor, care se refera la
Furnizori(Cod_furnizor). Daca aceasta cheie nu este nula, atunci trebuie sa gasim un furnizor care sa aiba
acel cod.
Prima întrebare pe care trebuie sa ne-o ponem este: Poate fii cheia straina nula? În cazul exemplului
nostru asta ar însemna ca exista cheltuieli care nu se pratesc nimanui. Aceste cazuri nu sunt admise de lege,
deci nu putem avea valoare nula în cheia straina din tipul de entitate Cheltuieli.
În general daca pariciparea tipului de entitate "fiu" este totala, atunci nu putem avea valoare nula în
cheia straina. În caz contrar putem avea valoare nula.
Regulile întreprinderii.
În final evidentiem acele reguli care sunt date de realitatea ce se va modela în baza de date.
Documentarea tuturor regulilor de integritate.
Trecem toate regulile de integritate în dictionarul de date.
Pasul 2.7. Verificarea modelului logic local cu ajutorul utilizatorului.
Obiectivul: Convingerea ca modelul creat reprezinta în totalitate realitatea care trebuie modelata
în baza de date.
La acest pas modelul local logic este clomplet si este bine documentat. Înainte de a trece la pasul 3,
trebuie verificat modelul, sa fie conform cu realitatea. În cazul în care se gasesc diferente, ne vom reîntoarce
la pasii anteriori si modificam cele necasare.
Pasul 3. Crearea si validarea modelului global logic de date.

Obiectivul: Combinarea modelelor locale logice într-un model logic global care sa reprezinte
întreprinderea care este modelata.
A treia activitate majora în proiectarea bazei de date logice este crearea modelului logic global, prin
compunerea tuturor modelelor locale. Dupa combinarea modelelor locale, trebuie validat modelul global
prin tehnica de normalizare si dupa aceea, prin tehnica tranzactiilor. Acest proces utilizeaza aceleasi tehnici
pe care le-am descris la pasii 2.3. si 2.2.
Acest proces este foarte important în proiectarea bazei de date, pentru ca el demonstreaza ca
reprezentarea întreprinderii este independenta de orice utilizator, functie sau aplicatie.
Pasul 3.1. Compunerea modelelor logice locale într-un model logic global.
Obiectivul: Compunerea tuturor modelelor logice locale într-un model logic global al întreprinderii.
În cazul unui sistem mic, cu putine vederi ai utilizatorilor, este relativ usor de a compune modelele
logice locale. În cazul unui sistem mai mare însa, trebuie sa urmam un proces sistematic de realizare a
modelului global.
Verificarea numelor entitatilor si a cheilor lor primare.
Aceasta verificare se face folosind si dictionarul creat în decursul pasilor de dinainte. Probleme apar
doar atunci când:
10
Doua entitati au acelasi nume, dar sunt de fapt diferiti.
Doua entitati sunt aceleasi, dar nu au aceleasi nume.
Probabil va fi necesara analizarea atributelor antitatilor, prntru a rezola aceasta problema. În
particular, putem utiliza cheia primara si numele entitatii, pentru a identifica entitatile echivalente.
Verificarea numelor relatiilor.
Aceasta activitate este asemanatoare celei descrise la entitati.
Compunerea entitatilor de pe view-urile locale.
Compunerea entitatilor care au aceleasi nume si aceleasi chei primare. În general entitatile cu
aceleasi chei primare reprezinta "lumea reala", si deci pot fi compuse. Atributele care apar în entitatile de pe
ambele view-uri, vor fi trecute doar o singura data. Daca într-un view apare un atribut compus, iar într-un alt
view acelasi atribut dar descompus în atribute simple, atunci vom întreba, daca se poate, utilizatorii pentru a
decide asupra formei de utilizare a atributului.
Compunerea entitatilor care au aceleasi nume, dar au chei primare diferite. În astfel de situatii,
cautam doua entitati care au aceleasi nume si nu au aceleasi chei primare, dar au aceleasi chei candidat. Cele
doua entitati pot fi compuse, urmând ca dupa compunere sa alegem o cheie primara, restul ramanând chei
alternante.
Compunerea entitatilor care nu au nume comune si nu au aceleasi chei primare. Aceste entitati se
pot depista prin analiza atributelor celor doua entitati.
Includerea (fara compunere) a entitatilor care apar doar într-un view.
Pasul anterior identifica toate entitatile comune. Celelalte entitati, se vor include în modelul logic
global exact asa cum apar în view-ul respectiv.
Compunerea relatiilor de pe modelele locale.
În acest pas analizam similitudinile dintre relatii de pe diferite modele locale. În timpul compunerii
relatiilor trebuie rezolvate si conflictele dintre relatii, ca si regulile de cardinalitate si participare. Putem
compune relatii care au aceleasi nume si acelasi scop, sau acelasi scop, dar nume diferite.
Includerea (fara compunere) a relatiilor care apar doar pe un view.
Relatile care au ramas neincluse în modelul global dupa pasul anterior, se includ în modelul global
fara modificare.
Cautarea entitatilor si relatilor care lipsesc.
Este unul din cei mai grei pasi din crearea modelului global. Trebuie cautate acele entitati si relatii,
care s-au omis la pasii anteriori si n-au ajuns în modelul global.
Cautarea cheilor straine.
În decursul pasilor anterioare, s-au modificat entitati, chei primare si chei straine. În acest pas
verificam daca cheile straine sunt corecte în fiecare entitate fiu si efectuam toate modificarile necesare.
Cautarea regulilor de integritate
Verificam daca regulile de integritate a modelului global nu sunt în conflict cu regulile definite la
modelele locale. Fiecare problema de acest gen se rezolva cu ajutorul utilizatorului sistemului.
Actualizarea documentatiei.
Actualizam documentatia, ca sa reflecte toate modificarile aduse în acest pas modelului.
Pasul 3.2. Validarea modelului logic global.
Obiectivul: Validarea modelului global logic de date, folosind normalizarea, dupa care folosind
tranzactile cerute.
Acest pas este schivalent cu pasii 2.3. si 2.4., unde am validat modelul local de date.
Pasul 3.3. Verificarea posibilitatilor de extindere a bazei de date în viitor.
Obiectivul: Determinarea ca daca modelul se acomodeaza usor la modificari oricât de mari ce pot
intervenii în viitor.
Este important ca modelul creat sa fie expansibil în viitor. Daca modelul nu are aceasta calitate, viata
lui poate fi scurta si pentru o mai mare modificare va trebui refacuta de la început.
Pasul 3.4. Verificarea modelului global cu ajutorul utilizatorului.
Obiectivul: Verificarea ca modelul global reprezinta în totalitate realitatea.
În acest moment modelul global este complet si documentat. Împreuna cu utilizatorul sistemului se
verifica acest model si se aduc eventualele corecturi prin întoarcerea la pasii în cauza.
11
2. Proiectarea bazei de date
2.1. Culegerea datelor
Adunarea tuturor tipurilor de informații pe care le înregistrați în baza de date, în scopul obţinerii de
informaţiile necesare , documente în scopul primirii de decizii care ar îmbunătăţi managmentul întreprinderii
Pentru a găsi şi organiza informaţiile necesare, începeți cu informațiile existente. De exemplu, se pot
înregistra comenzile de cumpărare într-un registru sau se pot ține informații despre clienți în formulare, într-
un dulap pentru dosare. Colectați aceste documente și treceți în listă fiecare tip de informații afișate (de
exemplu, fiecare casetă completată dintr-un formular). Dacă nu aveți formulare existente, imaginați-vă că
trebuie să proiectați un formular pentru a înregistra informații despre clienți. Ce informații ați dori să puneți
în formular? Ce casete de completat ați crea? Identificați și treceți în listă toate aceste elemente. De
exemplu, să presupunem că în prezent țineți lista de clienți pe fișe indexate. Examinând aceste fișe veți
descoperi că fiecare fișă conține numele, adresa, orașul, statul, codul poștal și numărul de telefon ale unui
client. Fiecare dintre aceste elemente poate reprezenta o coloană din tabel.Pe măsură ce pregătiţi lista, nu vă
faceți griji dacă nu este perfectă din prima încercare. În schimb, treceți în listă fiecare element la care vă
gândiți. Dacă va utiliza și altcineva baza de date, cereți-i părerea. Lista se poate îmbunătăți ulterior.
Apoi, luați în considerare tipurile de rapoarte sau de liste poștale pe care doriți să le obțineți din baza
de date. De exemplu, se poate crea un raport de vânzări pentru un produs, care afișează vânzările în funcție
de regiune sau un raport de rezumare a inventarului, care afișează nivelurile de inventar ale produselor. De
asemenea, se pot genera scrisori formale, care li se vor trimite clienților pentru a îi anunța de evenimente sau
de oferte speciale. Proiectați mintal raportul și imaginați-vă cum ar arăta. Ce informații ați dori să puneți în
raport? Treceți fiecare element în listă. Faceți același lucru pentru scrisoarea formală și pentru orice alt
raport pe care considerați că îl veți crea.
Proiectarea mentală a rapoartelor și a listelor poștale pe care doriți să le creați vă ajută la identificarea
elementelor de care veți avea nevoie în baza de date. De exemplu, să presupunem că le oferiți clienților
oportunitatea de a se abona (sau a se dezabona) la actualizări periodice prin poștă electronică și că doriți să
imprimați o listă a celor care s-au abonat. Pentru a înregistra acele informații, adăugați o coloană “Abonat la
mesaje de poștă electronică” la tabelul pentru clienți. Pentru fiecare client, se poate seta câmpul la Da sau la
Nu.
Necesitatea de a le trimite mesaje de poștă electronică clienților sugerează alt element de înregistrat.
După ce știți că un client dorește să primească mesaje de poștă electronică, va trebui să aflați adresa de poștă
electronică la care să le trimiteți. Așadar, trebuie înregistrată o adresă de poștă electronică pentru fiecare
client.
Este logic să se construiască un prototip al fiecărui raport sau listare de ieșire și să se ia în considerare
elementele necesare pentru a produce raportul. De exemplu, când examinați o scrisoare formală, se poate să
vă vină în minte alte idei. Pentru a include o formulă introductivă corespunzătoare — 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”, decât cu “Dragă Dl. Florin
Georgescu”. Așadar, de obicei este mai bine să se stocheze numele de familie separat de prenume.
Trebuie să se țină cont de faptul că informațiile trebuie despărțite în cele mai mici părți utile. În cazul
unui nume, pentru ca numele de familie să fie ușor disponibil, se va despărți numele în două părți — Nume
și Prenume. Pentru a sorta un raport după numele de familie, de exemplu, este util să se stocheze separat
numele de familie ale clienților. În general, pentru a sorta, căuta, celula sau raporta în funcție de un element
informațional, trebuie pus acel element într-un câmp propriu.
12
Tipuri de date
ID Tipul de date NULL/ NOT NULL
Nr_mese int NOT NULL
Nr_scaune int NOT NULL
Nr_tabla int NOT NULL
Nr_computere int NOT NULL
Culoare_mese char(50) NULL
Culoare_scaune char(50) NULL
Firma_Producatoare _mese char(100) NULL
Firma_Producatoare_scaune char(100) NULL
Tabelul nr.1 - Imobilul

Nr_auditoriul char(50) NOT NULL
Suprafata_auditoriu_mp int NOT NULL
Etajul int NOT NULL
Nr_ferestre int NOT NULL
Inaltimea_m int NOT NULL
Tabelul nr.2 - Auditoriul

Nr_mese int NOT NULL
Nr_scaune int NOT NULL
Nr_tabla int NOT NULL
Nr_computere int NOT NULL
Culoare_mese char(50) NULL
Culoare_scaune char(50) NULL
Firma_Producatoare _mese char(100) NULL
Firma_Producatoare_scaun
char(100) NULL
e
Tabelul nr.3 - Raspunzatorul
Denumire char(50) NOT NULL
Nume_prenume_director char(50) NOT NULL
Telefon_contact int NOT NULL
Sediul_strada_oras char(50) NOT NULL
Tara char(50) NOT NULL
Tabelul nr.4 – Firmele producatoare de scaune și scaune
13
14
2.2. Proiectarea conceptuală.
Modelul conceptual ER (diagrama Entitatea-Relație)
În faza de proiectare conceptuală a bazelor de date se proiectează schema conceptuală şi schemele
externe ale bazei de date.
Deşi nu este obligatoriu, această fază se poate menţine independenţa 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 aceasta este o descriere stabilă şi inavuabilă a bazei de date. Alegerea unui
SGBD şi deciziile ulterioare de proiectare se pot schimba fără ca aceasta să se schimbe.
Proiectul conceptual de nivel înalt se realizează pe baza cerinţelor definite în prima etapa de
proiectare şi se reprezintă, în general printr-o diagramă Entitate-Asociere (extinsă).
Proiectarea conceptuala, sau designul conceptual, este acea parte a procesului de design în care se
trece la elaborarea unei solutii de principiu prin:
· identificarea problemelor esentiale, prin abstractizare;
· stabilirea structurii functiilor;
· cautarea celor mai adecvate principii de lucru si a modului de combinare a acestora.
Designul conceptual determina principiul unei solutii.
Această schemă evidentiaza faptul ca faza de conceptie este precedata de o decizie. Scopul acestei decizii
este de a raspunde la o serie de întrebari, pe baza listei de cerinte stabilita în etapa clarificarii obiectivului:
 A fost tema clarificata suficient, astfel încât sa permita dezvoltarea unei solutii sub forma unui
proiect?
 Mai sunt necesare informatii suplimentare referitoare la tema?
 Este posibil ca obiectivele sa fie atinse în conditiile restrictiilor de ordin financiar?
 Este cu adevarat necesara etapa de conceptie, sau solutiile cunoscute permit trecerea direct la etapele
de proiectare a formelor si detaliere?
 Daca etapa de conceptie este absolut necesara, cum si cu ce amploare trebuie dezvoltata?
Mai concret, etapa de conceptie are drept scop determinarea elementelor de masina, a mecanismelor,
proceselor si configuratiilor, care, combinate într-un anumit mod, pot da nastere unui proiect care sa
raspunda cerintelor formulate. Aceasta este etapa în care inventivitatea si creativitatea sunt stimulate si se
pot manifesta cel mai din plin.
15
De cele mai multe ori, aceasta etapa implica formularea unui model, care poate fi de doua
feluri: analitic sau experimental. Lucrarea de fata pune accentul pe dezvoltarea modelelor analitice bazate pe
efecte si principii fizice.
Un alt aspect deosebit de important în etapa conceptuala este sinteza. Sinteza reprezinta acel proces
prin care elementele conceptului sunt aranjate într-o anumita ordine, calculate si dimensionate în cel mai
potrivit mod posibil. Sinteza este un proces creativ care este prezent în orice proiect, ca si în principalele
etape ale procesului de design.
Modelul conceptual ER (diagrama Entitatea-Relație)
Faza 1: Cerinţele de date Cerinţele de prelucrare

Colectarea şi analiza
cerinţelor
Faza 2: Proiectarea schemei Proiectarea tranzacţiilor

Proiectare conceptuală conceptuale şi a schemelor (independente de SGBD)
externe (independente de
SGBD)
Faza 3:
Alegerea unui SGBD
Faza 4: Proiectarea schemei conceptual si a

schemelor externe(dependente de
Proiectare logica SGBD)
Faza 5: Proiectarea schemei interne

Proiectare fizica (dependent de SGBD)
Instructiuni de descriere a datelor Implemantarea tranzactiilor

Faza 6: (LDD)
Implementare (dependente de SGBD)
(dependete de SGBD)
16
2.3. Modelul relațional
Modelul relațional ca și orice alt model utilizat în proiectarea logica a bazelor de date eliberează
utilizatorului de cunoaștere detaliilor despre structura fizică și metodele de acces la date. În afară de aceasta,
el are două avantaje suplimentare: e simplu și elegant. Simplitatea sa constă în structurile de date omogene
în formă de relații tabelare. Iar elegența modelului se explică prin temelia sa științifică. El este riguros din
punct de vedere matematic grație faptului că se sprijină pe bine puse la punct teoriile matematica relațiilor și
logca de ordinul unu.
Elementele de bază ale modelului
1. Domeniu
Domeniu – este o mulțime de valori avînd asociat un nume. Un domeniu se poate defini fie prin enumerarea
elementelor sale fie prin specificarea unor caracteristici definitorii ale acestora. Exemplu:
 Culori={gri, alb, negru, maro etc.}
 Numere={Mulțimea numerelor întregi pozitive din intervalul [0, 100000]}
Trebuie menționat că în șirul de domenii care participă la un produs cartezian unele se poate găsi în mod
repetat.
2. Relația
Relația este o submulțime a unui produs cartezian avînd asociat un nume. Termenul de relație
provide de asemenea din matematica. Un exemplu de relație aparținînd bazei de date Imobil este:
Imobil={ ('14','16','16','1','14','Neagra','Neagra','Mobex','Mobex'),
('19','19','21','2','19','Cafenie','Cafenie','Mobex','Plimob'),
('20','12','10','1','20','Albastra','Albastra','Sortilemn','GP Sofa')}
Elementele unei relații sunt denumite în literatura de specialitate tupluri.

O reprezentare intuitivă pentru relația de mai sus este si urmatoarea, in care fiecare element al relatiei devine
o linie a unei tabele si fiecare coloana corespunde unui domeniu din produsul cartezian de baza:
In fapt deci o relatie se reprezinta o tabela care contine date, fiecare coloana avand asociat un anumit tip de
date, dat de domeniul din care provine.
3. Atribut
Deoarece o relatie are o reprezentare tabelara putem vorbi de ‘coloană a unei relatii’. In mod
obisnuit, intr-o tabela coloanele au un nume.
Atribut este coloană a unei relatii avand asociat un nume.
Pentru tabelul Imobil putem fixa de exemplu următoarele nume de atribute :
 id_auditoriul- numărul auditoriului.
 Nr_mese, Nr_scaune, Nr_tabla, Nr_computere – cantitatea de imobil enumerat.
 Culoare_mese, Culoare_scaune – culoarea meselor și a scaunelor.
 Firma_Producatoare_mese, Firma_Producatoare _scaune – firma ce a produs imobilul dat.
17
Imobil
4. Schema tabelei
Continutul unei relatii (vazuta ca o tabela) poate varia in timp: se pot adauga sau sterge linii sau se
pot modifica unele dintre valorile din liniile existente. Ceea ce ramane constanta este structura relatiei:
numele relatiei, numarul si tipul atributelor sale. In terminologia relationala structura unei relatiei este
denumita si schema relatiei.
Schema unui tabel este numele relatiei urmat de lista atributelor sale si (eventual) de domeniul din
care acestea provin.
Exista mai multe modalitati prin care se poate specifica schema unei relatii. In exemplele urmatoare
prezentam cateva dintre acestea cu referire la tabelul Imobil:
Imobil(id_auditoriu, Nr_scaune, Nr_mese, Nr_tabla, Nr_computere, Culoare_mese, Culoare_scaune,
Firma_Producatoare_mese, Firma_Producatoare_scaune)
Imobil(id_auditoriu:19, Nr_scaune:22, Nr_mese:21, Nr_tabla:2, Nr_computere:19,
Culoare_mese:Cafenie, Culoare_scaune:Cafenie, Firma_Producatoare_mese:Mobex,
Firma_Producatoare_scaune:Plimob)
Imobil=id_auditoriu, Nr_scaune, Nr_mese, Nr_tabla, Nr_computere, Culoare_mese,
Culoare_scaune, Firma_Producatoare_mese, Firma_Producatoare_scaune
5. Cheia tabelei
O relatie fiind o multime (de tupluri) nu poate contine elemente duplicat – spre deosebire de exemplu
de un tabel Excel unde putem avea dubluri.
Rezulta ca tuplurile pot fi deosebite intre ele prin valorile aflate pe una sau mai multe coloane din
relatie.
Cheia tabelei este o multime minimala de atribute ale caror valori identifica in mod unic un tuplu al
relatiei respective.
Cheia unei relatii este o caracteristica a schemei acesteia si nu este determinata prin inspectarea
valorilor aflate la un moment dat in relatie.
In tabela Imobil cele trei linii existente pot fi identificate unic de valorile de pe 3 atribute (id_auditoriu,
Nr_scaune, Nr_mese) dar numai id_auditoriu este cheie:
 id_auditoriu identifica (prin definitie) in mod unic un produs; rezulta ca multimea de atribute
{ id_auditoriu } este cheie (fiind si minimala prin natura sa}.
 Multimea de atribute { id_auditoriu} identifica de asemenea unic fiecare tuplu al relatiei dar nu este
cheie nefiind minimala: prin inlaturarea lui id_auditoriu multimea ramane in continuare cheie.
 Multimea de atribute { Nr_scaune } nu este cheie: este posibil ca in tabela Imobil sa avem mai multe
linii cu Nr_scaune. Asa cum am mentionat cheia se determina din semnificatia atributelor relatiei si
nu din valorile la un moment dat.
 Din acelasi motiv nici una dintre celelalte multimi de atribute ale relatiei Imobil nu este cheie: fie nu
este minimala (in cazul in care il include pe id_auditoriu) fie nu identifica unic tuplurile relatiei (pot
exista valori duble)
In literatura de specialitate si in sistemele de gestiune a bazelor de date exista trei alte concepte
legate de cheie si care vor fi prezentate in paragrafele urmatoare ale acestui capitol:
 Cheie primara;
 Cheie straina;
 Supercheie.
18
2.4. Proiectarea logică a bazei de date
Baza de date trebuie pentru :
 A duce evidența imobilului ;
 A facilita administrarea imobilului ;
 A facilita procesul de reînoire a auditoarelor .
Domeniul de aplicare a acestei baze de date are o arie largă, deoarece cu ajutorul ei , dacă modificăm
denumirea atribuitelor, se poate de administra la fel imobilul, lucrurile altor întreprinderi.
Prima fază în proiectarea unei baze de date trebuie să fie analiza obiectivului urmărit. Iar atunci cînd
proiectăm o bază de date trebuie să urmărim o serie de pași.
1. Determinarea scopului bazei de date.
Acest lucru va ajuta să stabilesc ce fel de date voi stoca în baza mea de date pe care o voi crea.
Baza de date creată de mine va avea scopul de a duce evidența imobilului din colegiu.
2. Determinarea datelor necesare.

Odată ce am un scop clar stabilit, voi împărți informațiile în subiecte separate. Iar fiecare subiect
va fi un tabel în baza de date și numele tabelului va fi sugestiv pentru informațiile pe care le va conține.
Prin urmare pentru baza mea de date ce duce evidența imobilului din colegiu, am stocat
informații despre imobiluri, auditoare, răspunzatorii de auditoare și în final informație despre firmele
producătoare de imobil.
3. Determinarea cîmpurilor de care am nevoie în tabel.

În primul rînd hotărăsc ce fel de informații vor fi stocate în cadrul tabelelor. Fiecare categorie de
informație dintr-un tabel poartă denumirea de cîmp și fiecare cîmp va fi afișat pe o coloană în tabel. Spre
exemplu, în tabelul Imobilul va avea următoarele cîmpuri: Nr_mese, Nr_scaune, Nr_tabla, Nr_computere,
Culoare_mese, Culoare_scaune, Firma_Producatoare_mese, Firma_Producatoare_scaune.
În tabelul Auditoriul vor fi cîmpurile:
Nr_auditoriul, Suprafata_auditoriu_mp, Etajul, Nr_ferestre, Inaltimea_m.
În tabelul Raspunzatorul vor fi cîmpurile:
Nume_raspunzator, Prenume_raspunzator, Virsta_raspunzator, Specialitate, Anul_angajarii,
Cabinet_raspunzator.
În tabelul Firma_producatoare_scaune vor fi cîmpurile:
Denumire, Nume_prenume_director, Telefon_contact, Sediul_strada_oras, Tara.
În tabelul Firma_producatoare_mese vor fi cîmpurile:
Denumire, Nume_prenume_director, Telefon_contact, Sediul_strada_oras, Tara.
4. Determinarea relațiilor dintre tabele.

Pentru aceasta trebuie sa analizăm cu atenție tabelele și să stabilim legăturile care există între
datele conținute în diferite tabele.
În cazul în care nu am găsit aceste legături, eu le-am adăugat pentru a satisface condiția dată.
5. Crearea bazei de date în mediul SQL se va face prin intermediul comenzii New Database, după
care vom creea în baza dată o interogare nouă cu ajutorul la New Query. Adică tot acest lucru se face
prin instrucțiunile de tranzacție SQL.
6. Crearea tabelelor se efectuează cu ajutorul limbajului de definire Create, unde vom introduce
denumirea de tabel și cîmpurile cu bazele de date respective.
În continuare prin intermediul limbajului de manipulare Insert vom introduce în tabele
respective datele necesare.
7. Modificarea structurii bazei de date se efectueaza cu ajutorul limbajului de defininire a datelor
Alter table. Prin modificarea structurii a BD se înțelege modificarea sau ștergerea datelor din bază.
19
8. Popularea bazei de date cum am spus mai sus se face prin intermediul limbajului de manipulare
Insert, introducîndu-se datele necesare conform tabelelor și respectiv cîmpurilor declarate.
9. Imbunătățirea bazei de date.
Analiza bazei de date pentru a găsi eventuale erori. Inițial creez tabele și adaug cîteva
înregistrări de probă. După care văd daca pot obține din tabelele respective rezultate necesare și în
continuare fac modificări dacă este nevoie de ele.
Desigur pentru a parcurge aceste etape mai bine să folosim un maculator pentru că sunt necesare
multe modificări pentru a ajunge la o formă a bazei de date acceptabilă.
Trebuie să ne asigurăm că datele sunt stocate în mod corespunzător în baza de date și că putem
obține toate informațiile și situațiile finale dorite. Este mult mai deficil să facem modificări după ce au fost
introduse toate datele.
10. Inventarierea atributelor.
Sunt următoarele atribute :
1. Numărul de mese, numărul de scaune, numărul de table, numărul de calculatoare, culoarea meselor și
scaunelor pentru a ști cu exactitate cît imobil este în auditoare și ce fel de imobil ;
2. Firma producătoare de mese și scaune, denumirea directorilor de firme ce produc aceste mese și
scaune pentru a ști de unde vine acest imobil.
3. Desigur pentru a dacă merge vorba despre auditorii, atunci trebuie să fie și informații despre ele :
suprafața, etajul, înălțimea auditoriului, numărul de ferestre.
4. Fiecare auditoriu are un răspunzător, aici am introdus și datele sale, pentru a ști ce reprezintă
persoana dată. Deci am introdus: numele, prenumele, vărsta, specialitatea, anul angajării și desigur
cabinetul de care răspunde.
5. La fel am mai introdus numărul de telefon, țara în care se află și strada sediului firmei producătoare
de mese și scaune, acestea vor ajuta în cazul în care va trebui să fie apelată o firmă cutare.
11. Determinarea cheii primare.

Am determinat cheile primare pentru fiecare auditoriu și am făcut un tabel de formă normală 1.
12. Eliminarea atributelor calculabile

În baza de date rezpectiva nu au fost prezente atribute repetitive sau calculabile.
20
2.5. Normalizarea bazei de date
Tabelul Imobilul este tabelul inițial pentru baza de date, astfel se va stabili apariția de anomalii și
redudanțe, aplicînd procesul de normalizare Forma normală 1. Pentru a respecta condițiile FN1 se vor
elimina atributele calculabile și cele repetitive. Deci se vor crea tabelele : Imobilul, Auditoriul,
Raspunzatorul, Firma_producatoare_scaune, Firma_producatoare_mese.
Tabel nenormalizat
Normalizarea tabelului
1. Tabelul Imobilul
2. Tabelul Auditoriul
3. Tabelul Raspunzatorul
21
4. Tabelul Firma_producatoare_scaune
5. Tabelul Firma_producatoare_mese
22
2.6. Schema bazei de date
Schema conceptuală reprezintă o descriere concisă a datelor utilizatorului, incluzând descrierea detaliată a
tipurilor de date, a relaţiilor şi restricţiilor acestora.
Elementele subliniate din schema dată reprezintă cheia primară, iar săgețile leagă
cheile exterioare.
Eliminarea relaţiilor cu atribute
În cazul în care în modelul de date este reprezentată o relaţie cu atribute (relaţie barată), ea trebuie să
fie descompusă pentru a identifica o entitate.
Eliminarea atributelor cu valori multiple
Un atribut cu valori multiple conţine mai multe valori pentru o singură entitate. În cazul când
modelul de date conceptual este reprezentat un atribut cu valori multiple, el trebuie descompus pentru a
identifica o entitate.
Eliminarea relaţiilor redundante
O relaţie este redundantă dacă aceeaşi informaţie poate fi obţinută prin intermediul altor relaţii.
Relaţiile redundante nu sunt necesare, acestea trebuie eliminate, fapt care se realizează după ce se analizează
semnificaţia fiecărei relaţii dintre entităţi. In final rezultă o simplificare a modelulului de date conceptual.
Desenarea diagramei entitate – relaţie (ERD) îmbunătăţite
Obiectivul acestei etape constă în desenarea unei diagrame Entitate-Relaţie (ER) care să fie o
reprezentare fizică a modelului conceptual al beneficiarului.
23
2.7. Rafinarea proiectării
În baza de date Imobil nu a fost nevoie de rafinare, deoarece de la bun început m-am străduit să fac o
bază de date cît mai logic și corect. În primul rînd am făcut o schiță aparte a bazei de date, iar apoi în final
nu a fost necesitatea de a mai adauga ceva aparte.
Din momentul în care am tabelele, câmpurile și relațiile de care am nevoie, trebuie să creez și să
populez tabelele cu date eșantion și să încerc să lucrez cu informațiile: creând interogări, adăugând
înregistrări noi și așa mai departe. Acest lucru ajută la evidențierea problemelor potențiale — de exemplu,
este posibil să am nevoie să adăugați o coloană pe care am uitat să o inserez în timpul fazei de proiectare,
sau este posibil să am un tabel care să trebuiască separat în două tabele pentru a elimina duplicarea.
Văd dacă se poate utiliza baza de date pentru a obține răspunsurile dorite. Creez schițe neprelucrate
ale formularelor și rapoartelor, și văd dacă vă arată datele pe care le așteptați. Caut dubluri inutile de date și,
dacă le găsesc, modific proiectarea pentru a le elimina.
Pe măsură ce testez baza de date inițială, probabil veți descoperi că se pot face îmbunătățiri. Câteva
lucruri care trebuie verificate:
Ați uitat vreo coloană? Dacă da, apar informațiile în tabelele existente? Dacă informațiile sunt despre
altceva, este posibil să fie nevoie să creați un alt tabel. Creați o coloană pentru fiecare element
informațional care trebuie urmărit. Dacă informațiile nu se poate calcula de pe o altă coloană, probabil
aveți nevoie de o coloană nouă pentru asta.
Sunt inutile unele coloane, pentru că se pot calcula din câmpuri deja existente? Dacă un element
informațional se poate calcula dintr-o altă coloana deja existentă — ca, de exemplu, prețul redus
calculat din prețul de vânzare — este mai bine, în general, să se procedeze așa și să se evite crearea
unei coloane noi.
Introduceți în mod repetat informații dublate în unul din tabele? Dacă da, probabil că trebuie împărțit
tabelul în două tabele între care să existe o relație de tipul unu-la-mai-mulți.
Aveți tabele cu multe câmpuri, un număr limitat de înregistrări și multe câmpuri goale în înregistrările
individuale? Dacă da, gândiți-vă la reproiectarea tabelului astfel încât să aibă mai puține câmpuri și mai
multe înregistrări.
A fost împărțit fiecare element informațional în cele mai mici părți utile? Dacă trebuie efectuate
operații de raportare, sortare, căutare sau calculare pentru un element informațional, puneți acel
element în propria sa coloană.
Conține fiecare coloană date despre subiectul tabelului? Dacă o coloană nu conține informații despre
subiectul tabelului, aceasta aparține unui alt tabel.
Sunt toate relațiile dintre tabele reprezentate prin câmpuri comune sau printr-un al treilea tabel?
Relațiile unu-la-unu și unu-la-mai-mulți necesită coloane comune. Relațiile mai-mulți-la-mai-mulți
necesită un al treilea tabel.
24
3. Alegerea SGBD
Alegerea SGBD-ului este o etapă opțională şi presupune alegerea unui SGBD adecvat pentru
aplicația realizată. Această alegere poate fi făcută în orice moment anterior proiectării logice, cu condiția să
fie disponibile suficiente informații referitoare la cerințele sistemului, cum ar fi performanța sau
constrângerile de securitate şi integritate.
Procesul de alegere a unui SGBD presupune realizarea urmatoarelor activitati:

A. Stabilirea cerintelor utilizatorilor, sub aspectul:
tipurilor de aplicatii
timpului de raspuns
confidentialitatii datelor
securitatii datelor
usurintei de utilizare si altele
B. Stabilirea cerintelor de ordin tehnic privind realizarea B.D., precum:
portabilitatea S.G.B.D. (utilizarea S.G.B.D.-ului pe diferite sisteme de calcul).
portabilitatea colectiilor de date si a programelor.
facilitatile de incarcare, exploatare si intretinere a B.D. ce trebuiesc asigurate (modalitatile
de descriere a datelor tehnicile de organizare si regasire a datelor ) si altele.
C. Stabilirea cerintelor de ordin economic, privind:
incadrarea in bugetul alocat pentru realizarea B.D.
timpul necesar pentru pregatirea utilizatorilor si trecerea la exploatarea curenta a bazei de
date.
25
4. Proiectarea fizică
Proiectarea fizică reprezintă procesul de descriere a implementării bazei de date pe mediile
secundare de stocare. Sunt descrise structurile de stocare şi metodele de acces utilizate pentru a obţine un
acces eficient la date.
Proiectul fizic al bazei de date efectuează şi o rafinare a modelului logic; acesta transpune modelul
logic într-un sistem relaţional de gestiune a bazelor de date. În această fază este obligatorie examinarea
modului în care utilizatorul accesează baza de date. Se recomandă separarea modelului logic de modelul
fizic astfel încât modificările să poată fi documentate în conformitate cu modelul fizic pentru a corespunde
constrângerilor. În acest fel, modelul logic rămâne independent de tehnologie, ţinând cont doar de cerinţele
specifice domeniului pe care îl modelează.
Acest pas din cadrul procesului de proiectare implică determinarea următoarelor categorii de informaţii:
- datele folosite în mod curent;
- coloanele ce urmează a fi indexate pentru a obţine un acces mai rapid la date;
- spaţiul necesar precum şi cel prevăzut pentru creşterea dimensiunilor bazei de date;
- dacă denormalizarea bazei de date va duce la creşterea performanţelor acesteia;
- cereri de funcţionalitate:
- procesarea secvenţială a tuplurilor;
- tuplurile ce îndeplinesc o anumită condiţie impusă prin intermediul unei valori;
- tuplurile inserate sau eliminate;
- obiective de performanţă:
- evitarea pierderii inutile de spaţiu;
- primirea într-un timp cât mai scurt a răspunsului.
O bază de date relaţională constă din două părţi importante:
- dicţionarul de date care descrie datele;
- fişierele de date ce conţin datele fizice.
Fleming von Halle, în lucrarea sa “Handbook of Relational Database Design”, propune paşii necesari creării
modelului fizic, aşa cum se poate observa din figura 6.19:
D – date; P – proces
Figura 3. Crearea modelului fizic
O structură de stocare reprezintă o implementare a tabelelor şi coloanelor în cadrul unui sistem specific de
gestiune a bazelor de date. Opţiunile tipice de implementare presupun luarea unor decizii referitoare la:
- transformarea tabelelor în fişiere;
- spaţiul liber;
- transferul tabelelor în bazele de date;
- blocări;
26
- ordinea coloanelor.
Aceste consideraţii pot diferi considerabil de la un sistem de gestiune a bazelor de date la altul.
Pasul Analizarea evenimentelor existente în baza de date este împărţit în şapte subpaşi, după cum urmează:
- revizuirea evenimentelor înlănţuite prin modelul logic;
- alcătuirea unei liste de priorităţi a evenimentelor pentru a înţelege importanţa acestora;
- identificarea regulilor care se aplică celor mai importante evenimente;
- identificarea criteriilor de căutare pe baza cărora se accesează tabelul, în cazul fiecărui eveniment sau
tabel accesat;
- identificarea cerinţelor de sortare pe baza cărora se accesează tabelul, în cazul fiecărui eveniment sau
tabel accesat;
- identificarea coloanelor destinaţie pe baza cărora se accesează tabelul, în cazul fiecărui eveniment sau
tabel accesat;
- estimarea numărului de rânduri căutate raportate la numărul total de rânduri din tabel pe baza cărora se
accesează tabelul, în cazul fiecărui eveniment sau tabel accesat;
O cale de acces reprezintă o procedură logică pe baza căreia un sistem de gestiune a bazelor de date poate
selecta anumite rânduri, poate obţine coloanele cerute, prelucrând acele coloane şi rânduri în maniera
corespunzătoare.
Opţiunile de reglare invizibilă sunt acele opţiuni care sunt transparente utilizatorilor şi programatorilor. În
cele mai multe sisteme de gestiune a bazelor de date opţiunile invizibile pe care le poate regla proiectantul se
referă la scanări, ordinea rândurilor în tabele, indexarea coloanelor.
O structură vizibilă de date este acea structură palpabilă utilizatorilor sau programatorilor. Reglarea unei
structuri vizibile de date constă din modificarea structurii datelor astfel încât acestea s-ar putea să nu mai
corespundă modelului logic. Cele mai obişnuite modalităţi de reglare a structurilor vizibile de date sunt:
- stocarea coloanelor ce reprezintă copii exacte ale altor coloane;
- stocarea coloanelor cu ajutorul cărora se efectuează calcule pe baza unei formule;
- stocarea coloanelor ce se obţin prin deducţie (cu ajutorul unei reguli).
27
5. Tranzacțiile principale ale sistemului
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,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 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.
28
6. Protecția 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 răuvoitor, intenţionat.
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 i.
Acordarea de privilegii folosind comanda GRANT
29
7. Elaborarea proiectului
Elaborarea proiectului constă în executarea următorilor paşi:
 Proiectarea BD;
 Crearea BD;
 Culegerea textului MC Word
Inițial înainte de a efectua baza mea de date am proiectat-o pe foaie și am elaborat un scop anume a
acestei baze, după care au fost selectate datele necesare spre creare.
După aceasta a urmat crearea bazei de date în mediul Microsoft SQL Server Management Studio,
conform condițiilor și datelor effectuate în timpul proiectării. Desigur pe parcursul creării acestei baze de
date au mai fost adăugate unele idei și date.
În final în Microsoft Word am editat un proiect în care sunt enumerați pașii după care a fost creată
baza mea de date. Aici eu povestesc și explic prin ce metode și pași a trecut acesta baza pentru a deveni
astfel. Desigur tot aici am și explicat toate cele trei feluri de proiectare a unei baze de date.
30
8. Descrierea datelor de ieșire
Datele de ieșire constituie rezultate ale operațiilor cu valori din tabele, câmpuri aparte, vederi, tabele
întregi, etc.
31
9. Crearea bazei de date
Crearea bazei de date în mediul SQL se va face prin intermediul comenzii New Database, după
care vom creea în baza dată o interogare nouă cu ajutorul la New Query. Adică tot acest lucru se face prin
instrucțiunile de tranzacție SQL.
9.1. Crearea tabelelor

Crearea tabelelor se efectuează cu ajutorul limbajului de definire Create, unde vom introduce
denumirea de tabel și cîmpurile cu bazele de date respective.
În continuare prin intermediul limbajului de manipulare Insert vom introduce în tabele respective
datele necesare.
Create Table Auditoriul( id_auditoriu char(50) NOT NULL, Suprafata_auditoriu_mp int NOT
NULL, Etajul int NOT NULL, Nr_ferestre int NOT NULL,Inaltimea_mp int NOT NULL );
9.2. Modificarea structurii tabelelor

Modificarea structurii bazei de date se efectueaza cu ajutorul limbajului de defininire a datelor Alter
table. Prin modificarea structurii a BD se înțelege modificarea sau ștergerea datelor din bază.
ALTER TABLE Auditoriul WITH NOCHECK ADD CONSTRAINT PK_Auditoriul PRIMARY
KEY CLUSTERED (Nr_auditoriul);
ALTER TABLE Auditoriul ADD CONSTRAINT FK_Auditoriu FOREIGN KEY (Nr_auditoriul)
REFERENCES Auditoriul (Nr_auditoriul);
9.3. Inserarea datelor

Popularea bazei de date cum am spus mai sus se face prin intermediul limbajului de manipulare
Insert, introducîndu-se datele necesare conform tabelelor și respectiv cîmpurilor declarate.
INSERT INTO Imobilul(Nr_mese, Nr_scaune, Nr_tabla,Nr_computere, Culoare_mese,
Culoare_scaune, Firma_Producatoare_mese,Firma_Producatoare_scaune)
9.4. Modificarea datelor

Modificarea datelor din baza de date se efectuează cu ajutorul limbajului de definire a datelor
Update. Prin modificare datelor din BD se înțelege înlocuirea unor date cu altele noi, după dorința
utilizatorului.
UPDATE Imobil SET Nr_mese=15 WHERE id_auditoriu='14';
UPDATE Raspunzatorul SET Nume_raspunzator='Garuta',Prenume_raspunzator='Vitalie'
WHERE id_auditoriu='19';
9.5. Ștergerea datelor

Ștergerea datelor din baza de date se efectuează prin cu ajutorullimbajului de definire a datelor Delete. Prin
ștergerea datelor se înțelege eliminarea definitorie a unor date anume din baza de date.
DELETE FROM Auditoriul WHERE id_auditoriu='19';
32
10.Interogarea bazei de date.
11.
33
Baza de date normalizată
create database Auditoriul – crearea bazei de date cu denumirea „Auditoriul”
use Auditoriul – alegem cu ce bază de date să lucrez
go – se pornește procesul de creare a bazei de date
--Create Imobilul table Crearea tabelului cu denumirea
------------------------- „Imobilul” în care se vor
Create Table Imobilul introduce datele: numărul de mese
( (tipul de date int), numărul de
id_auditoriu char(50) NOT NULL, scaune (tipul de date int), numărul
Nr_mese int NOT NULL, de table (tipul de date int),
numărul de computere (tipul de
Nr_scaune int NOT NULL, date int), culoarea meselor (tipul
Nr_tabla int NOT NULL, de date char), culoarea scaunelor
Nr_computere int NOT NULL, (tipul de date char), firma
Culoare_mese char(50) NULL, producătoare de mese (tipul de
Culoare_scaune char(50) NULL, date char) și firma producătoare de
Firma_Producatoare_mese char(100) NULL, scaune (tipul de date char). NOT
NULL– înregistrările nu pot
Firma_Producatoare_scaune char(100) NULL conține valori nule.
);
--Create Auditoriu1 table
------------------------- Crearea tabelului cu denumirea
Create Table Auditoriul „Auditoriul” în care se vor introduce
( datele:numărul auditoriului (tipul de
id_auditoriu char(50) NOT NULL, date char), suprafața auditoriului în
Suprafata_auditoriu_mp int NOT NULL, metri pătrați (tipul de date int), etajul
(tipul de date int), numărul de ferestre
Etajul int NOT NULL, (tipul de date int), înălțimea auditoriului
Nr_ferestre int NOT NULL, (tipul de date int). NOT NULL–
Inaltimea_m int NOT NULL înregistrările nu pot conține valori nule.
);
--Create Raspunzator table
------------------------- Crearea tabelului cu denumirea
Create Table Raspunzatorul „Raspunzatorul” în care se vor
( introduce datele: numele raspunzătorului
Nume_raspunzator char(50) NOT NULL, (tipul de date char), prenumele
răspunzătorului (tipul de date char),
Prenume_raspunzator char(50) NOT NULL, virsta răspunzătorului (tipul de date int),
Virsta_raspunzator int NOT NULL, specialitatea răspunzătorului (tipul de
Specialitate char(50) NOT NULL, date char), anul angajării a
Anul_angajarii int NOT NULL, răspunzătorului (tipul de date int) și
id_auditoriu char(50) NOT NULL, cabinetul de care va răspunde
); răspunzătorul (tipul de date char). NOT
NULL– înregistrările nu pot conține
--Create Firma_producatoare_scaune table valori nule.
-------------------------
Create Table Firma_producatoare_scaune
(
Denumire char(100) NOT NULL,
Nume_prenume_director char(100) NULL,
34
Crearea tabelului cu denumirea
„Firma_producatoare_scaune” în care se
vor introduce datele: denumire (tipul de date
Telefon_contact int NOT NULL,
char), numele și prenumele directorului (tipul
Sediul_strada_oras char(50) NOT NULL, de date char), telefon de contact (tipul de
Tara char(50) NOT NULL date int), sediul(tipul de date charși țara(tipul
); de date char). NOT NULL– înregistrările nu
--Create Firma_producatoare_mese table pot conține valori nule.
-------------------------
Crearea tabelului cu denumirea
Create Table Firma_producatoare_mese
„Firma_producatoare_mese” în care se vor
( introduce datele: denumire (tipul de date
Denumire char(100) NOT NULL, char), numele și prenumele directorului (tipul
Nume_prenume_director char(100) NOT NULL, de date char), telefon de contact (tipul de
Telefon_contact int NOT NULL, date int), sediul(tipul de date charși țara(tipul
Sediul_strada_oras char(50) NOT NULL, de date char). NOT NULL– înregistrările nu
pot conține valori nule.
Tara char(50) NOT NULL
);
-----------------------------------
--Define primary keys
-----------------------------------
ALTER TABLE Auditoriul WITH NOCHECK ADD CONSTRAINT PK_Auditoriul
PRIMARY KEY CLUSTERED (Nr_auditoriul);
-----------------------------------
--Define foreign keys
-----------------------------------
ALTER TABLE Auditoriul ADD
CONSTRAINT FK_Auditoriu FOREIGN KEY (Nr_auditoriul) REFERENCES
Auditoriul (Nr_auditoriul);
ALTER TABLE modifică structura unui tabel existent prin

redenumirea/adăugarea/ștergerea/schimbarea structurii unei coloane sau
index.
PRIMARY KEY – defineşte o cheie primară la nivel de coloană sau tabelă
( nu pot fi mai multe înregistrări cu aceeaşi cheie primară).
FOREIGN KEY – defineşte o cheie externă ( tabela relaționează cu altă
tabelă, pe o cheie unică sau cheie primară) .
CHECK – forțează o condiție pe coloană.
CONSTRAINT - permite să numim o nouă constrîngere.
-----------------------------------
--Populate Laborator1 table
-----------------------------------
VALUES ('14','16','1','14','Neagra','Neagra','Mobex','Mobex');
-----------------------------------
-----------------------------------
35
VALUES ('19','21','2','19','Cafenie','Cafenie','Mobex','Plimob');
-----------------------------------
-----------------------------------
VALUES ('20','10','1','20','Albastra','Albastra','Sortilemn','GP Sofa');
-----------------------------------
--Populate Laborator4 table Prin
----------------------------------- intermediul
instrucțiuni-
lor Insert și
Culoare_scaune, Firma_Producatoare_mese,Firma_Producatoare_scaune) Values se
VALUES ('23','25','1','23','Maro','Maro','S.C. Agache S.R.L.','S.C. Agache S.R.L.');
introduc
--Populate Laborator5 table datele(
----------------------------------- numărul de
INSERT INTO Imobilul(Nr_mese, Nr_scaune, Nr_tabla,Nr_computere, Culoare_mese, mese,
scaune, table
și
VALUES ('24','26','2','24','Maro','Maro','S.C. Artgranit S.R.L.','S.C. Artgranit S.R.L.');
computere)
--Populate Laborator6 table în tabelul
----------------------------------- „Imobilul”.
VALUES ('14','16','1','14','Neagra','Neagra','S.C. Bed & Sofa S.R.L.','S.C. Anteco S.A.');
-----------------------------------
VALUES ('10','12','1','10','Alba','Alba','S.C. Amis Impex S.A.','S.C. Adorianis Trans
S.R.L.');
-----------------------------------
INSERT INTO Imobilul(Nr_mese, Nr_scaune, Nr_tabla,Nr_computere, Culoare_mese, Prin
intermediul
Culoare_scaune, Firma_Producatoare_mese,Firma_Producatoare_scaune) instrucțiuni-
VALUES ('13','15','2','13','Gri','Gri','IKEA','IKEA'); lor Insert și
--Populate Laborator9 table Values se
----------------------------------- introduc
INSERT INTO Imobilul(Nr_mese, Nr_scaune, Nr_tabla,Nr_computere, Culoare_mese, datele(
Culoare_scaune, Firma_Producatoare_mese,Firma_Producatoare_scaune) numărul de
mese,
VALUES ('14','17','2','14','Albastra','Albastra','IKEA','IKEA'); scaune,
--Populate Laborator10 table table și
----------------------------------- computere)
INSERT INTO Imobilul(Nr_mese, Nr_scaune, Nr_tabla,Nr_computere, Culoare_mese, în tabelul
Culoare_scaune, Firma_Producatoare_mese,Firma_Producatoare_scaune) „Imobilul”.
VALUES ('20','22','3','20','Neagra','Neagra','Ada Fabrica de Mobila','Aramis Invest');
-----------------------------------
36
--Populate Auditoriu1 table
-----------------------------------
INSERT INTO Auditoriul(Nr_auditoriul, Suprafata_auditoriu_mp,Etajul ,Nr_ferestre,
Inaltimea_mp)
VALUES ('18','30','1','2','3');
Inaltimea_mp)
VALUES ('19','22','1','3','3');
Inaltimea_mp)
VALUES ('20','29','1','2','3');
Prin
Inaltimea_mp) intermediul
VALUES ('24','19','1','2','3'); instrucțiuni-
lor Insert și
Values se
Inaltimea_mp) introduc
VALUES ('25','30','1','2','3'); datele
(numărul
Inaltimea_mp) auditoriului,
VALUES ('25 A','25','1','4','3'); suprafața sa
în metri
pătrați, etajul,
Inaltimea_mp) numărul de
VALUES ('30','27','2','2','5'); ferestre și
înalțimea
Inaltimea_mp) auditoriului
VALUES ('31','25','2','2','5'); ) în tabelul
„Auditoriul”.
Inaltimea_mp)
VALUES ('34','30','2','2','5');
Inaltimea_mp)
VALUES ('34 A','30','2','4','5');
-----------------------------------
--Populate Raspunzatorul table
-----------------------------------
INSERT INTO Raspunzatorul(Nume_raspunzator,
Prenume_raspunzator,Virsta_raspunzator,Specialitate, Anul_angajarii,
Cabinet_raspunzator)
VALUES ('Alexa','Gheorghe','18','Informatica','2010', '18');
VALUES ('Richard','Eduard','20','Administrarea WEB','2016','19');
37
VALUES ('Filipoc','Boris','21','Turism','2014','20');
VALUES ('Margin','Andrei','19','Bazele de date','2013','24');
Cabinet_raspunzator) Prin intermediul
instrucțiunilor
VALUES ('Verdes','Ion','18','Informatica','2013','25'); Insert și Values se
INSERT INTO Raspunzatorul(Nume_raspunzator, introduc
Prenume_raspunzator,Virsta_raspunzator,Specialitate, Anul_angajarii, datele
Cabinet_raspunzator) (numele
VALUES ('Belic','Victor','28','Informatica','2012','25 A'); răspunzătorului,
INSERT INTO Raspunzatorul(Nume_raspunzator, prenumele
răspunzătorului,
Prenume_raspunzator,Virsta_raspunzator,Specialitate, Anul_angajarii, virsta
Cabinet_raspunzator) răspunzătorului,
VALUES ('Bitca','Vasile','25','Matematica','2011','30'); specialitatea, anul
INSERT INTO Raspunzatorul(Nume_raspunzator, angajării și
Prenume_raspunzator,Virsta_raspunzator,Specialitate, Anul_angajarii, cabinetul de care
Cabinet_raspunzator) răspunde) în
tabelul
VALUES ('Goncear','Ana','27','Informatica','2013','31'); „Raspunzatorul”.
VALUES ('Chetrean','Boris','18','Turism','2015','34');
VALUES ('Dobrovolschi','Angela','19','Informatica','2009','34 A');
-----------------------------------
--Populate Firma_producatoare_scaune table
-----------------------------------
INSERT INTO Firma_producatoare_scaune(Denumire, Nume_prenume_director,
Telefon_contact, Sediul_strada_oras, Tara)
VALUES('Mobex', 'Cojocaru Ana', '022907621',
'Nicolae Costin 70, Chisinau', 'Republica Moldova');
Telefon_contact, Sediul_strada_oras, Tara) Prin intermediul
VALUES('Plimob', 'Galusca Ion', '079678909', instrucțiunilor
'Stefan Neaga 45, Telenesti', 'Republica Moldova'); Insert și Values se
introduc
Telefon_contact, Sediul_strada_oras, Tara) datele
(denumire de
VALUES('GP Sofa', 'Ginga Vasile', '022345678',
firma, numele și
'Alexandru cel Bun, Orhei', 'Republica Moldova'); prenumele
directorului de
Telefon_contact, Sediul_strada_oras, Tara) firma, telefonul de
contact, sediul,
38
țara) în tabelul
„Firma_producat
-oare_scaune”.
VALUES('S.C. Agache S.R.L.', 'Gutu Eduard', '069540798',
'Stefan cel Mare, Chisinau', 'Republica Moldova');
VALUES('S.C. Artgranit S.R.L.', 'Stati Andrei', '061666999', 'Vasile Lupu 89, Balti',
'Republica Moldova');
VALUES('S.C. Anteco S.A.', 'Cirlig Boris', '077903021', 'Ion Creanga 36, Chisinau',
VALUES('S.C. Adorianis Trans S.R.L.', 'Indigo Aliona', '090121345', 'Calea Orheiului 1,
Chisinau', 'Republica Moldova');
VALUES('IKEA', 'Ginga Elena', '022345465', 'Sarmizegetusa 12, Chisinau', 'Republica
Moldova');
VALUES('Aramis Invest', 'Voronin Vladimir', '060000000', 'Grenoble 56, Chisinau',
-----------------------------------
--Populate Firma_producatoare_mese table
-----------------------------------
INSERT INTO Firma_producatoare_mese(Denumire, Nume_prenume_director,
VALUES('Mobex', 'Chetrean Veronica', '023456789',
'Valea pietei 23, Orhei', 'Republica Moldova');
VALUES('Sortilemn', 'Untura Ion', '079899065',
'Valea dorului 56, Balti', 'Republica Moldova'); Prin intermediul
INSERT INTO Firma_producatoare_mese(Denumire, Nume_prenume_director, instrucțiunilor
Telefon_contact, Sediul_strada_oras, Tara) Insert și Values se
VALUES('S.C. Agache S.R.L.', 'Gutu Eduard', '069540798', introduc
datele
'Stefan cel Mare, Chisinau', 'Republica Moldova'); (denumire de
INSERT INTO Firma_producatoare_mese(Denumire, Nume_prenume_director, firma, numele și
Telefon_contact, Sediul_strada_oras, Tara) prenumele
VALUES('S.C. Artgranit S.R.L.', 'Stati Andrei', '061666999', directorului de
'Vasile Lupu 89, Balti', 'Republica Moldova'); firma, telefonul de
INSERT INTO Firma_producatoare_mese(Denumire, Nume_prenume_director, contact, sediul,
țara) în tabelul
Telefon_contact, Sediul_strada_oras, Tara) „Firma_producat
VALUES('S.C. Bed & Sofa S.R.L.', 'Andreiciuc Andrei', -oare_scaune”.
'090899097', 'Gheorghe Asachi 39, Chisinau', 'Republica Moldova');
39
VALUES('S.C. Amis Impex S.A.', 'Istrati Valerii', '063456789', 'Hincesti 21, Chisinau',
VALUES('IKEA', 'Ginga Elena', '022345465', 'Sarmizegetusa 12, Chisinau', 'Republica
Moldova');
VALUES('Ada Fabrica de Mobila', 'Petrov Vladimir', '079765421', 'Valea Trandafirilor
80, Chisinau', 'Republica Moldova');
Prin intermediul comenzii select*from afișăm la ecran datele
select*from Imobilul introduse anterior din tabelul „Imobilul”.
Prin intermediul comenzii select*from afișăm la ecran datele

select*from Auditoriul
introduse anterior din tabelul „Auditoriul”.
select*from Raspunzatorul Prin intermediul comenzii select*from afișăm la ecran datele

introduse anterior din tabelul „Raspunzatorul”.
Prin intermediul comenzii select*from afișăm
select*from Firma_producatoare_scaune la ecran datele introduse anterior din tabelul
„Firma_producatoare_scaune”.
select*from Firma_producatoare_mese Prin intermediul comenzii select*from afișăm

la ecran datele introduse anterior din tabelul
„Firma_producatoare_mese”.
40
Concluzie
Scopul propus pentru această lucrare individuală a fost de a elabora o bază de date
destinată ducerii evidenței imobilului din auditoare.
Elaborarea programului a necesitat diverse modalități pentru crearea bazei cerute în
condiție. Bazele desigur sunt noi pentru mine și mi-a creat uneori unele probleme și erori în
procesul de producere. Dar în același timp mi-a provocat și un interes în elaborarea lor, ceea ce m-a
făcut să mă descurc cu mare plăcere. Pentru a verifica corectitudinea rezultatelor returnate de
calculator am propus valori de testare, iar soluţiile afişate au fost corespunzătoare şi satisfăcătoare.
De data aceasta am întîlnit dificultăţi în îndeplinirea sarcinei, acestea caracterizîndu-se
prin erori,dar în final le-am rezolvat cu mare plăcere şi am învăţat mai bine aceste modalități și
proceduri de rezolvare, ceea ce mă bucură că am putut să mă descurc și cu această etapă.
În cursul formării acestei baze de date în mediul Microsoft SQL Server Management
Studio am acumulat o gamă de informație și cunoștințe. Această lucrarea individuală a fost una
destul de ușoară și clară. Am apelat la toate felurile de izvoarea, la manual, internet și profesor, iar
în final am reușit să rezolv. Mulţumită acestor operații și limbajuri de definire și manipulare a
datelor, personal am aflat mai mult şi am făcut cunoştinţă cu o treaptă mai complexă a programării.
În cadrul lecţiilor este posibilă studierea doar a principiilor generale ale metodicei de
elaborare a bazelor de date şi anumitor aspecte ale lor,însă lucrarea individuală îmi oferă
posibilitatea de a evolua în rolul de elaborator şi organizator al proiectului şi nu în ultimul rînd mă
ajută să-mi reamintesc procedura de lucru în Microsoft Word. Nu în ultimul rînd prin aceste lucrări
individuale cunosc treptat ce înseamnă lucrul de programator.
Desigur mi-a făcut mare plăcere faptul că muncind mult asupra bazei în final mi s-a afişat
tabele efectuate prin intermediul comenzilor Insert și Values, ce m-a motivat şi mi-a dat mai multă
voinţă spre a munci mai departe. Dar aceste programe le-am rezolvat și datorită lecţiilor din timpul
studiului.
În final am făcut o explicaţie la toate acţiunile făcute în această sarcină,pentru a întipări şi
a memora mai bine procedurile şi algoritmul. Sper ca pe viitor să mă descurc mai ușor cu aceste
lucrări și să acumulez din ce în ce mai multă informație.
41

Sarcina: Catedra Informatica Aplicată

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Sarcina: Catedra Informatica Aplicată

Încărcat de

Drepturi de autor:

Formate disponibile

MINISTERUL EDUCAŢIEI REPUBLICII MOLDOVA

CENTRUL DE EXCELENŢĂ ÎN INFORMATICĂ ŞI TEHNOLOGII INFORMAŢIONALE

Catedra Informatica Aplicată

la disciplina „Asistența bazelor de date”

De elaborat un proiect, a cărei aplicație respectivă, folosind meniuri, rapoarte formulare și

1) Înregistrează un nou auditoriu;

Determinarea cheii primare.......................................................................................8

Eliminarea atributelor calculabile.............................................................................8

Normalizarea bazei de date........................................................................................8

Baza de date nenormalizată......................................................................................10

Proiectarea bazei de date..........................................................................................15

1. Determinarea scopului bazei de date..........................................................15

2. Determinarea datelor necesare....................................................................15

4. Determinarea relațiilor dintre tabele..........................................................15

5. Crearea bazei de date...................................................................................16

7. Modificarea structurii bazei de date...........................................................16

8. Popularea bazei de date................................................................................16

9. Imbunătățirea bazei de date........................................................................16

Eliminarea dependențelor funcționale parțiale......................................................17

Eliminarea dependențelor funcționale tranzitive...................................................17

Baza de date normalizată..........................................................................................18

Factori critici pentru succesul proiectarii logice:

Pasul 1. Crearea modelului conceptual local, pentru utilizatori.

Pasul 1.1. Identificarea tipurilor de entitati.

Pasul 1.2. Identificarea tipurilor de relatii

Pasul 1.3. Identificarea si asocierea de atribute la tipurile de entitati si tipurile de relatii

Obiectivul: Asocierea de atribute la tipurile de entitati si la tipurile de relatii.

Atribute simple sau compuse

Pasul 2.1. Proiectarea modelului conceptual local pe modelul logic local

Eliminarea relatiilor multe-la-multe

Tipuri de entitati tari

Tipurile de entitati slabe

Pasul 3. Crearea si validarea modelului global logic de date.

ID Tipul de date NULL/ NOT NULL

ID Tipul de date NULL/ NOT NULL

Modelul conceptual ER (diagrama Entitatea-Relație)

Faza 1: Cerinţele de date Cerinţele de prelucrare

Faza 2: Proiectarea schemei Proiectarea tranzacţiilor

Faza 4: Proiectarea schemei conceptual si a

Faza 5: Proiectarea schemei interne

Instructiuni de descriere a datelor Implemantarea tranzactiilor

Elementele unei relații sunt denumite în literatura de specialitate tupluri.

2. Determinarea datelor necesare.

3. Determinarea cîmpurilor de care am nevoie în tabel.

4. Determinarea relațiilor dintre tabele.

11. Determinarea cheii primare.

12. Eliminarea atributelor calculabile

Eliminarea relaţiilor cu atribute

Eliminarea atributelor cu valori multiple

Eliminarea relaţiilor redundante

Desenarea diagramei entitate – relaţie (ERD) îmbunătăţite

Procesul de alegere a unui SGBD presupune realizarea urmatoarelor activitati:

Figura 3. Crearea modelului fizic

9.1. Crearea tabelelor

9.2. Modificarea structurii tabelelor

9.3. Inserarea datelor

9.4. Modificarea datelor

9.5. Ștergerea datelor

ALTER TABLE modifică structura unui tabel existent prin

Prin intermediul comenzii select*from afișăm la ecran datele

select*from Raspunzatorul Prin intermediul comenzii select*from afișăm la ecran datele

select*from Firma_producatoare_mese Prin intermediul comenzii select*from afișăm

S-ar putea să vă placă și

selectfrom Raspunzatorul Prin intermediul comenzii selectfrom afișăm la ecran datele

selectfrom Firma_producatoare_mese Prin intermediul comenzii selectfrom afișăm