BDTC Proiect Ivan Andra Irina

UNIVERSITATEA POLITEHNICA BUCUREȘTI
FACULTATEA DE ELECTRONICĂ, TELECOMUNICAȚII ȘI TEHNOLOGIA INFORMAȚIEI
PROIECTAREA UNUI BAZE DE DATE A UNUI OPERATOR DE

TELEFONIE MOBILĂ
TEMĂ BDTC
Student:
Andra-Irina Ivan
București
2016
Cuprins
Listă de Figuri .................................................................................................................................. 5
Listă de Tabele ................................................................................................................................. 7
Listă de Acronime ............................................................................................................................ 8
Introducere 9
CAPITOLUL 1 Conceptele fundamentale ale bazelor de date .......................................................... 11
1.1 Ce este o bază de date? ........................................................................................................ 11
1.2 Sistemul de gestionare a bazei de date (SGBD) .................................................................. 12
1.3 Clasificarea sisemelor de baze de date ................................................................................ 12
1.3.1 Clasificarea după modelul de date ............................................................................... 12
1.3.2 Clasificarea după numărul de utilizatori ...................................................................... 13
1.3.3 Clasificarea după numărul de stații pe care este stocată baza de date ......................... 13
1.4 Modelul Entitate-Asociere .................................................................................................. 13
1.5 Modelul Entitate-Asociere Extins ....................................................................................... 17
1.6 Modelul relațional ............................................................................................................... 18
CAPITOLUL 2 Proiectarea bazelor de date relaționale ..................................................................... 21
2.1 Proiectarea conceptuală a bazei de date .............................................................................. 21
2.1.1 Identificarea entităților ................................................................................................. 22
2.1.2 Identificarea asocierilor dintre entități ......................................................................... 22
2.1.2.1 Tipuri de asocieri ............................................................................................................ 23
2.1.2.2 Exemplu practic.............................................................................................................. 23
2.1.3 Identificarea atributelor entităților și determinarea domeniilor atributelor ................. 24
2.1.4 Determinarea atributelor chei candidat și chei primare ............................................... 25
2.1.5 Generalizarea/Specializarea tipurilor de entități .......................................................... 26
2.2 Proiectarea logică a bazei de date ....................................................................................... 28
2.2.1 Construirea și validarea modelului de date logic pentru fiecare vedere a
utilizatorului ............................................................................................................................... 28
2.2.1.1 Transpunerea modelului de date conceptual local într-un model de date logic local .. 28
2.2.1.2 Extragerea relațiilor (tipurilor de entități) din modelul de date logic local ................... 32
2.2.1.3 Utilizarea normalizării .................................................................................................... 33
2.2.1.4 Definirea constrângerilor de integritate ........................................................................ 36
2.3 Proiectarea fizică a bazei de date ........................................................................................ 39
CAPITOLUL 3 Implementarea fizică a modelului logic asociat bazei de date a unui operator de
telefonie mobilă ................................................................................................................................. 41
3.1 Crearea tabelulor ................................................................................................................. 41
3.2 Adăugarea cheii primare și a cheii străine .......................................................................... 45
3.3 Inserarea datelor în tabele ................................................................................................... 49
3.4 Crearea vederilor ................................................................................................................. 53
3.4.1 Vederea care afișează clienții din roaming, ce au fie abonament, fie cartelă, fie și
abonament și cartelă ................................................................................................................... 53
3.4.2 Vederea care afișează clienții ce au o anumită vechime .............................................. 55
3.4.3 Vederea care afișează clienții care lunar, în cazul abonamentelor, sau la
reîncărcare, în cazul cartelei, plătesc peste o anumită sumă ...................................................... 56
Bibliografie 57
LISTĂ DE FIGURI
Figura 1.1 Notațiile folosite pentru realizarea ERD .....................................................................15

Figura 1.2 Diagrama ERD inițială a temei propuse ......................................................................15
Figura 1.3 Înlocuirea asocierii M:N dintre entitățile CARTELĂ și CLIENT ..............................17
Figura 1.4 Înlocuirea asocierii M:N dintre CLIENT și ABONAMENT ......................................17
Figura 1.5 Exemplu de generalizare .............................................................................................18
Figura 2.1 Prima formă a diagramei Entitate-Asociere a temei date ............................................22
Figura 2.2 A doua formă a diagramei Entitate-Asociere a temei date ..........................................24
Figura 2.3 Entitățile și atributele bazei de date proiectate ............................................................26
Figura 2.4 Entitățile și atributele bazei de date proiectate după generalizare ...............................27
Figura 2.5 A treia formă a diagramei Entitate-Asociere a temei date ..........................................27
Figura 2.6 Desființarea relațiilor M:N ..........................................................................................28
Figura 2.7 Entitățile și atributele bazei de date proiectate după eliminarea relațiilor M:N ..........31
Figura 2.8 Etapele normalizării.....................................................................................................34
Figura 2.9 Formele normale ale unei relații ..................................................................................35
Figura 2.10 Relațiile bazei de date proiectate ...............................................................................36
Figura 2.11 Relațiile bazei de date și legăturile dintre ele ............................................................39
Figura 3.1 Instrucțiunea folosită pentru crearea tabelului CLIENȚI ............................................42
Figura 3.2 Tabelul CLIENȚI a fost creat ......................................................................................42
Figura 3.3 Tabelul CARTELE implementat .................................................................................43
Figura 3.4 Tabelul ABONAMENTE implementat .......................................................................44
Figura 3.5 Tabelul CONTRACTE_CARTELE implementat .......................................................45
Figura 3.6 Tabelul CONTRACTE_ABONAMENTE implementat .............................................45
Figura 3.7 Cheie primară tabel CLIENȚI .....................................................................................46
Figura 3.8 Cheie primară tabel ABONAMENTE.........................................................................46
Figura 3.9 Cheie primară tabel CARTELE...................................................................................47
Figura 3.10 Cheie primară și chei străine tabel CONTRACTE_ABONAMENTE......................48
Figura 3.11 Cheie primară și chei străine tabel CONTRACTE_CARTELE................................48
Figura 3.12 Tabelul CARTELE populat .......................................................................................49
Figura 3.13 Prima jumătate a tabelul CARTELE .........................................................................49
Figura 3.14 A doua jumătate a tabelului CARTELE ....................................................................50
Figura 3.15 Tabelul ABONAMENTE populat .............................................................................50
Figura 3.16 Prima jumătate a tabelului ABONAMENTE ............................................................50
Figura 3.17 A doua jumătate a tabelului ABONAMENTE ..........................................................50
Figura 3.18 Tabelul CLIENȚI populat .........................................................................................51
Figura 3.19 Tabelul CONTRACTE_CARTELE populat .............................................................52
Figura 3.20 Tabelul CONTRACTE_ABONAMENTE populat ...................................................53
Figura 3.21 Vederea care afișează clienții din roaming, ce au fie abonament, fie cartelă, fie și
abonament și cartelă ......................................................................................................................54
Figura 3.22 Vederea care afișează clienții cu o vechime de peste 4 ani .......................................55
Figura 3.23 Vederea care afișează clienții care lunar, în cazul abonamentelor, sau la reîncărcare,
în cazul cartelei, plătesc peste 15 euro ..........................................................................................56
LISTĂ DE TABELE
Tabel 1.1 Entități și Instanțe .........................................................................................................13
LISTĂ DE ACRONIME
SGBD – Sistem de Gestionare a Bazelor de Date

SGBDR – Sistem de Gestionare a Bazelor de Date Relaționale
DDL – Data Definition Language
DML – Data Manipulation Language
E-A – Entitate-Asociere
ERD - Entity-Relationship Diagram
SQL – Structured Query Language
INTRODUCERE
Sistemele de baze de date se numără, la ora actuală, printre cele mai importante
componente ale vieții de zi cu zi. Deși importanța lor nu poate fi contestată, adeseori, nu
suntem conștienți că le utilizăm. De exemplu, nu mulți se gândesc că o agendă cu adrese
poate fi considerată o bază de date. Ce-i drept, pentru ca aceasta să fie recunoscută ca o bază
de date propriu-zisă, trebuie copiată informația din agendă într-un computer și salvată într-un
fișier, într-un mod ordonat. Trecând la un alt exemplu, atunci când cumpărăm ceva de la
supermarket, vânzătorul scanează produsele cu ajutorul cititorului de coduri de bare. Acest
aparat este conectat la o aplicație care utilizând codul de bare interoghează o bază de date
pentru a obține prețul produsului scanat. Oare câți dintre noi s-au întrebat vreodată cum
reușește acel aparat să „ghicească” prețul produsului? Sau ce se întâmplă atunci când plătim
cu ajutorul cardului de credit? În ceea ce privește ultima întrebare, atunci când plata se face cu
ajutorul cardului de credit, cititorul verifică, în primul rând, dacă există suficient credit astfel
încât tranzacția să poată fi realizată. Acest lucru este posibil datorită existenței unei baze de
date care conține informații referitoare la cumpărăturile efectuate utilizând cardul de credit.
Verificarea creditului se face cu ajutorul unei aplicații ce utilizează numărul cardului pentru a
inspecta dacă prețul produselor ce se doresc a fi cumpărate împreună cu totalul cumpărăturilor
deja efectuate în luna respectivă se află în limita creditului deținătorului cardului. În
momentul în care tranzacția este confirmată, detaliile acesteia sunt adăugate în baza de date
respectivă. Trebuie precizat faptul că, înainte ca tranzacția să fie autorizată, aplicația va
9
interoga baza de date și pentru a verifica dacă nu cumva cardul de credit se află pe lista celor
furate sau pierdute.
Având în vedere că bazele de date sunt vitale în ceea ce privește facilitarea vieții
omului modern, așa cum reiese și din exemplele anterioare, lucrarea de față își propune să
prezinte modul în care se proiectează o bază de date, mai precis o bază de date a unui operator
de telefonie mobilă.
Cerința proiectului este următoarea:
„Se va presupune faptul că un client poate avea atât abonamente (oricâte), cât și
cartele pre-plătite. Se presupune că se va cunoaște identitatea unui deținător de cartelă pre-
plătită.
Informațiile despre clienți vor conține codul clientului, numele și prenumele, adresa,
numere de telefon deținute, starea financiară (plata la zi sau întârziat/restanțier).
Structura pentru abonamente va conţine tipul de abonament, servicii oferite (voce,
sms, mms, video call, internet, roaming), cost, stare plăți (la zi sau restanţier), vechime în
reţea.
Structura pentru cartele pre-plătite va conţine servicii oferite (voce, sms, mms, video
call, internet, roaming), suma disponibilă, vechime în reţea.
În final, se vor crea vederi pentru a pune în evidenţă clienţii care sunt în roaming
(abonaţi + prepay), cei care plătesc peste o anumită sumă, care au o anumită vechime.”
10
CAPITOLUL 1
CONCEPTELE FUNDAMENTALE ALE BAZELOR

DE DATE
1.1 CE ESTE O BAZĂ DE DATE?

La modul general, o bază de date este o colecție de date corelate din punct de vedere
logic, care reflectă anumite aspecte ale realității, fiind destinată unui anumit grup de
utilizatori. Bazele de date pot fi create și întreținute manual, însă, la ora actuală, ele sunt
create și menținute computerizat.
Într-un sens mai restrâns, se poate afirma faptul că o bază de date este o colecție de date
centralizate, creată și întreținută computerizat, ce are drept scop prelucrarea datelor
(introducere, ștergere, actualizare și interogare pentru regăsirea anumitor informații, selectate
după un anumit criteriu).
Trebuie pecizat faptul că simple colecții de fișiere sau fișe (hârtii) nu sunt considerate a
fi baze de date datorită faptului că nu permit operații de interogare.
Bazele de date pot avea dimensiuni (număr de înregistrări) variate. Astfel, ele pot
ajunge de la un număr de câteva zeci de înregistrări (baza de date pentru o agenda cu numere
11
de telefon) până la un număr de câteva milioane de înregistrări (baza de date cu abonații unei
companii de telefonie mobilă).
1.2 SISTEMUL DE GESTIONARE A BAZEI DE DATE (SGBD)

SGBD este un sistem de programe ce-i permite utilizatorului să definească, să creeze și
să întrețină baza de date, precum și să aibă acces controlat la aceasta. SGBD este alcătuit din
elemente software care interacționează pe de-o parte cu programele de aplicație ale
utilizatorului și cu baza de date pe de altă parte.
În ceea ce privește facilitățile oferite de un SGBD, printre acestea se numără
următoarele:
 Permite utilizatorilor să definească baza de date, iar acest lucru se face, de
regulă, cu ajutorul unui limbaj de definire a datelor (DDL), care permite
utilizatorului specificarea tipurilor de date și a structurilor.
 Permite inserarea, actualizarea, ștergerea și extragerea datelor din baza de date.
Acest lucru se realizează, de regulă, cu ajutorul unui limbaj de manipulare a
datelor (DML).
 Oferă accesul controlat la baza de date, astfel poate furniza:
o Un sistem de securitate care nu permite utilizatorilor neautorizați să
acceseze baza de date;
o Un sistem de integritate ce asigură concordanța datelor stocate;
o Un sistem de control al concurenței ce permite accesul partajat la date;
o Un sistem de control al refacerii ce asigură restaurarea bazei de date
după apariția unei defecțiuni hardware sau software;
o Un catalog accesibil utilizatorilor ce conține descrieri ale datelor din
baza de date.
 Oferă generarea de vederi prin mecanismul de vizualizare. În acest mod se vor
afișa numai datele din baza de date care sunt utile uitilizatorului. Modurile de
vizualizare oferă și alte avantaje:
 Un anumit nivel de securitate. Astfel, se exclud date care nu
trebuie văzute de anumiți utilizatori;
 Un mecanism de personalizare a aspectului bazei de date.
1.3 CLASIFICAREA SISEMELOR DE BAZE DE DATE

1.3.1 Clasificarea după modelul de date
Sistemul de gestionare a bazelor de date relaționale (SGBDR) este cel mai raspândit
datorită simplității și a modelului de date relațional pe care îl utilizează:
 Datele se prezintă sub forma unei colecții de relații;
 Fiecare relație preia forma unui tabel, care, de altfel, reprezintă cea mai
importantă componentă a unei baze de date;
 Rândurile sau înregistrările tabelului reprezintă, de fapt, entități;
 Coloanele sau câmpurile tabelului sunt atribute sau proprietăți ale unor entități;
 Fiecare tabel are un set de atribute care corelate formează o cheie ce definește
fiecare entitate în mod unic.
Trecând mai departe, în cazul modelului de date ierarhic, baza de date se reprezintă
printr-o structură ierarhică de înregistrări de date conectate prin legături. Trebuie menționat
faptul că modelul ierarhic a fost primul model folosit pentru dezvoltarea bazelor de date.
12
În final, în ceea ce privește modelul de date rețea, acesta folosește o structură de graf
pentru definirea schemei conceptuale a bazei de date. Trebuie precizat faptul că nodurile
grafului sunt tipuri de entități (înregistrări) iar muchiile grafului reprezintă asocierile
(legăturile) dintre tipurile de entități.
Atât modelul ierarhic cât și modelul rețea se bazează pe parcurgerea legăturilor dintre
date pentru a lucra cu baza de date și nu vor fi prezentate în continuare în cazul acestei lucrări.
1.3.2 Clasificarea după numărul de utilizatori
Cele mai multe sisteme de baze de date sunt de tip multiutlizator, ceea ce înseamnă că
permit accesul concomitent a mai multor utilizatori la aceeași bază de date. Totuși există și un
număr redus de sisteme de tip monoutilizator, care suportă accesul unui singur utilizator la un
anumit moment de timp.
1.3.3 Clasificarea după numărul de stații pe care este stocată baza de date
Având în vedere această clasificare, există două categorii de sisteme de baze de date:
centralizate și distribuite.
În ceea ce privește sistemul de baze de date centralizat, datele și sistemul de gestiune
sunt stocate pe un singur calculator.
În cazul sistemlui de baze de date distribuit, acesta poate avea distribuite pe mai multe
calculatoare interconectate printr-o rețea de comunicație atât datele cât și sistemul de gestiune.
1.4 MODELUL ENTITATE-ASOCIERE

Modelul conceptual de nivel înalt al datelor prezintă o descriere succintă a seturilor de
date care modelează activitatea în cauză, însă fără a pune în evidență modul de reprezentare
sau de prelucrare a datelor.
Modelul Entitate-Asociere (E-A) este cel mai utilizat model conceptual de nivel înalt și
definește mulțimile de entități ale bazei de date precum și asocierile dintre ele, fără a impune
un anumit mod de gestiune a datelor (mod de structurare și prelucrare). În ceea ce privește
procesul de proiectare a bazelor de date, proiectarea modelului E-A reprezintă una dintre
primele etape ale acestuia, această etapă fiind numtă: proiectarea schemei conceptuale.
Așa cum reiese și din definiția de mai sus a modelului E-A, cele mai importante
elemente ale acestuia sunt: entitățile și asocierile.
O entitate este un lucru, obiect, persoană sau eveniment care are semnificație pentru
activitatea modelată, despre care trebuie să colectăm și să memorăm date. O entitate poate fi
un lucru real, tangibil, precum o persoană sau o cladire sau poate fi o noțiune abstractă. O
entitate este descrisă prin intermediul atributelor sale.
În ceea ce privește noțiunea de instanță, aceasta este un caz particular al unei ențități.
Pentru a înțelege mai bine ce este o instanță, se poate analiza tabelul următor.
Entitate Instanță
Abonament Cangur 10€
Client Popescu Ion
Tabel 1.1 Entități și Instanțe
Atributul nu face altceva decât să descrie un anumit aspect al unei entități, practic este o
proprietate a unei entități. Cu alte cuvinte, un atribut nu face altceva decât să descrie,
13
cuantifice, califice și să clasifice o entitate. De asemenea, trebuie precizat faptul că acesta
poate avea o singură valoare.
În cazul anumitor atribute, valoarea acestora se poate modifica constant (cum ar fi
starea financiară a clientului). Aceste atribute sunt numite atribute volatile. În schimb,
anumite atribute nu-și vor schimba valoarea decât foarte rar sau niciodată (cum ar fi adresa
clientului), ele fiind numite atribute nonvolatile.
De asemenea, un atribut poate fi obligatoriu (numele clientului) sau opțional (e-mail-ul
clientului). Dacă atributul este obligatoriu, el trebuie cunoscut și neapărat inclus în baza de
date. În ceea ce privește un atribut optional, în cazul anumitor instanțe el poate lipsi.
Revenind la entități, există două categorii de entități, și anume: entități normale
(puternice, obișuite) și entități slabe (dependente). Entitățile normale au o existență proprie. În
schimb, cele slabe nu pot exista decât dacă există o entitate normală cu care sunt asociate.
O asociere este o legătură sau o conexiune între entități, ce prezintă o anumită
semnificație pentru activitatea modelată. Gradul unei asocieri este dat de numărul de entități
asociate. Astfel asocierile pot fi binare (între 2 entități) sau multiple (între k entități, k > 2). În
ceea ce privește asocierile binare, acestea sunt de trei tipuri:
 „unu-la-unu” sau „one-to-one” – asocierea prin care unei instanțe a unei entități,
E1, îi corespunde o singură instanță a unei alte entități, E2, și reciproc. Acest tip
de asociere se notează astfel - 1:1.
 „unu-la-multe” sau „one-to-many” – asocierea prin care unei instanțe a unei
entități, E1, îi corespund una sau mai multe instanțe ale unei alte entități, E2, dar
unei instanțe ale entității E2 îi corespunde o singură instanță a entității E1. Acest
tip de asociere se notează astfel – 1:N.
 „multe-la-multe” sau „many-to-many” – asocierea prin care unei instanțe a unei
entități, E1, îi corespund una sau mai multe instanțe ale unei alte entități, E2, și
reciproc. Acest tip de asociere se notează astfel – M:N.
Cardinalitatea unei asocieri binare este dată de numărul de instanțe ale entității E1 care
pot stabili o legătură, o conexiune cu o instanță a unei entității E2.
Diagrama Entitate-Asociere (Entity-Relationship Diagram - ERD) nu este altceva decât
o reprezentare a modelului E-A. Notațiile folosite în cadrul acestei diagrame pentru
reprezentarea entităților, atributelor și asocierilor sunt prezentate în Figura 1.1. Trebuie
precizat faptul că există numeroase variante de notații, dar cele prezentate sunt cele mai
folosite.
Așa cum se poate observa și în Figura 1.1, entitatea puternică se reprezintă cu ajutorul
unui dreptunghi în timp ce entitatea slabă tot printr-un dreptunghi în interiorul căruia se afllă
alt dreptunghi. În cazul atributelor unei entități, acestea sunt reprezentate printr-o elipsă care
este conectată la entitate prin intermediul unei linii continue. Iar în ceea ce privește asocierea
dintre două entități, acesta se reprezintă printr-un romb conectat prin link-uri (linii continue)
la entitățile implicate. Asocierea poate avea sau nu un nume, însă dacă acesta există, el trebuie
scris în interiorul rombului sau în vecinătatea acestuia. Și tipul asocierii poate fi menționat
prin scrierea multiplicității în dreptul fiecărui link. De asemenea, trebuie menționat faptul că o
asociere poate să prezinte ea însăși atribute, aceste atribute reprezentându-se și ele prin elipse
care se conectează la asocierea în cauză.
În cazul diagramei ERD, numele unei entități este un substantiv iar al unei asocieri un
verb deoarece asocierea nu reprezintă altceva decît o interacțiune între entități iar o
intercațiune poate fi exprimată printr-un verb.
14
Figura 1.1 Notațiile folosite pentru realizarea ERD
Figura 1.2 Diagrama ERD inițială a temei propuse

Pentru a pune în evidență aspectele teoretice precizate în paragrafele anterioare, a fost
construită diagrama ERD inițială a temei propuse. Aceasta poate fi observată în Figura 1.2,
prezentată mai sus.
Analizând figura menționată, se poate observa faptul că avem de-a face cu 3 entități:
CARTELĂ, CLIENT și ABONAMENT.
Entitatea „CARTELĂ” reprezintă o cartelă pre-plătită sau, cu alte cuvinte, una din
opțiunile pe care un client o poate alege pentru a putea beneficia de serviciile oferite de o
companie de telefonie mobilă și este o entitate puternică. Această entitate este caracterizată de
mai multe atribute: tip cartelă (de exemplu: Frog, etc.), servicii (servicii oferite: sms, mms,
etc) și suma disponibilă.
Entitatea „CLIENT” reprezintă presoana care poate beneficia de serviciile oferite de
compania de telefonie mobilă în schimbul achitării unei anumite sume de bani și a fost
considerată a fi o entitate tare. Așa cum se poate observa, entitatea „CLIENT” este
15
caracterizată de mai multe atribute: cod, nume, prenume, adresă, numere de telefon deținute,
stare financiară (plata la zi sau întârziat/restanțier).
În ceea ce privește entitatea „ABONAMENT”, aceasta reprezintă un abonamen sau, cu
alte cuvinte, una din opțiunile pe care un client o poate alege pentru a putea beneficia de
serviciile oferite de o companie de telefonie mobilă și este o entitate puternică. Această
entitate este caracterizată de mai multe atribute: tip abonament (de exemplu: Cangur, etc.),
servicii (servicii oferite: sms, mms, etc.), cost.
Asocierea CARTELĂ-CLIENT este o asociere de tipul „multe-la-multe”, ce se notează
M:N. S-a ales acest tip de asociere datorită faptului că un anumit tip de cartelă (care oferă
anumite servicii) poate fi deținut de mai mulți clienți iar un client poate deține mai multe
cartele, de același tip sau de tipuri diferite.
Asocierea ABONAMENT-CLIENT este o asociere de tipul „multe-la-multe”, ce se
notează M:N. S-a ales acest tip de asociere datorită faptului că un anumit tip de abonament
(care oferă anumite servicii) poate fi deținut de mai mulți clienți iar un client poate deține mai
multe abonamente, de același tip sau de tipuri diferite.
Pentru ambele cazuri de relații: CARTELĂ-CLIENT și ABONAMENT-CLIENT, tipul
de asociere ales a fost cel „multe-la-multe” datorită faptului că nu a fost impusă nicio
constrângere în ceea ce privește numărul de abonamente/cartele ce pot fi deținute de un client
iar un anumit tip de abonament sau cartelă este evident că poate fi deținut de mai mulți clienți.
Trebuie precizat faptul că diagrama ERD prezentată în Figura 1.2 nu reprezintă o unică
soluție datorită faptului că modul de stabilire a entităților și asocierilor dintre ele nu este unul
unic, totul depinzând de felul în care persoana care proiectează baza de date dezvoltă modelul
conceptual. Astfel, o asociere poate fi înlocuită de o entitate așa cum se întâmplă în cazul
asocierilor de tipul „multe-la-multe” dintre CARTELĂ și CLIENT și ABONAMENT și
CLIENT. Aceste asocieri iau naștere între cele două entități participante în urma stabilirii unui
angajament între compania de telefonie mobile și client, cu alte cuvinte, putem spune că în
urma stabilirii unui contract (având în vedere că este cunoscută identitatea unui deținător de
cartelă pre-plătită, putem considera că la achiziționarea cartelei de încheie un fel de contract
între cele două părți implicate). Așadar asocierile pot fi înlocuite de entitatea „CONTRACT”
ce poate avea atribute precum: numărul de telefon asociat abonamentului sau cartelei, codul
clientului, etc. Schimbările survenite în cadrul diagramei ERD în urma înlocuirii asocieririlor
menționate anterior cu entitatea „CARTELĂ” pot fi observate în figurile următoare: Figura
1.3 și Figura 1.4.
16
Figura 1.3 Înlocuirea asocierii M:N dintre entitățile CARTELĂ și CLIENT
Figura 1.4 Înlocuirea asocierii M:N dintre CLIENT și ABONAMENT
1.5 MODELUL ENTITATE-ASOCIERE EXTINS

Spre deosebire de modelul Entitate-Asociere clasic, modelul Entitate-Asociere Extins
(Enhanced Entity-Relationship Model) oferă posibilitatea definirii de subtipuri ale unui tip de
entitate. Aceste subtipuri moștenesc atribute de la tipul de entitate pe care îl extind și care, în
mod evident, poartă numele de supertip dar au în plus și atribute specifice lor.
Acest tip de model propune câteva concepte noi, folosite pentru reprezentarea cât mai
intuitivă a tipurilor de entități din bazele de date mai complexe: specializarea și generalizarea.
Specializarea este un proces prin care, pornind de la o anumită entitate, se definesc mai
multe subtipuri, fiecare având atribute specifice.
În schimb, generalizarea este procesul invers specializării. Astfel, prin intermediul
generalizării se obține un supertip pornind de la mai multe entități. Primul pas ce trebuie
17
urmat în vederea obținerii supertipului este următorul: se identifică atributele comune ale mai
multor entități precum și atributele specifice fiecăreia. Atributele comune identificate nu vor fi
altceva decât atributele supertipului. De exemplu, în cazul nostru au fost definite entitățile
„CARTELĂ” și „ABONAMENT”. Atributele comune ale acestora sunt: servicii și într-un fel
suma plătită de client în scopul obținerii serviciilor, prin urmare acestea se vor regăsi în
supertipul „CONTRACT”. Trebuie precizat că principala diferență dintre abonament și cartelă
este reprezentată de restricții: la terminarea minutelor/mesajelor/etc nu mai poți folosi
serviciul respectiv în cazul cartelei, însă, în ceea ce privește abonamentul, serviciul mai poate
fi folosit introducandu-se un cost suplimetar. Prin urmare criteriul de generalizare poate fi
chiar această restricție.
Figura 1.5 Exemplu de generalizare
1.6 MODELUL RELAȚIONAL

Modelul relational, ca și orice alt model de date utilizat în proiectarea logică a bazelor
de date eliberează utilizatorul de cunoașterea detaliilor despre structura fizică și metodele de
acces la date. În afară de aceasta, el prezintă două avantaje suplimentare: e simplu și elegant.
Simplitatea sa constă în structurile de date omogene în formă de relații tabelare iar eleganța
18
modelului se explică prin temelia sa științifică. El este riguros din punct de vedere matematic
grație faptului că se sprijină pe teoria matematică a relațiilor și teoria logicii de ordinul unu.
Modelul relational a fost primul exemplu de model de date formal și a fost propus de E.
Codd în 1970. Prin intermediul acestui model, datele utilizatorului sunt reprezentate și
manipulate în mod abstract.
Conform unei sugestii a lui Codd, orice model de date trebuie să se bazeze pet rei
componente:
 Structurile de date – sunt definite prin intermediul unui limbaj de definire a
datelor (data definition language). Datele, în modelul relațional, sunt structurate
în relații bidimensionale. Elementele principale ale structurii relaționale sunt
relațiile, tuplurile, atributele, domeniile.
 Constrângerile de integritate – prin integritatea datelor se înțelege că datele
rămân stabile, în siguranță și corecte. Integritatea în modelul relational este
menținută de constrângeri interne ce nu sunt cunoscute utilizatorului.
 Manipularea datelor – relațiile pot fi manipulate prin intermediul unui limbaj de
manipulare a datelor (data manipulation language). În modelul relational,
limbajul folosește operatorii relaționali bazați pe conceptul algebrei relaționale.
Anterior au fost amintite următoarele concepte: relație, tuplu, atribut, domeniu. În cele
ce urmează se va explica ce noțiuni definesc acestea precum și alte concept.
O relație este un tabel ce conține coloane și rânduri iar un atribut este o coloană a unei
relații și are asociat o anumită denumire.
Domeniul este mulțimea valorilor premise pentru unul sau mai multe atribute. Astfel,
pentru fiecare atribut se va stabili: denumirea domeniului, sensul și domeniul de definiție,
evitându-se, în acest fel, apariția operațiilor incorecte din punct de vedere semantic.
Un tuplu este un rând într-o relație iar intensitatea unei relații reprezintă structura
tabelului, specificarea domeniilor și a altor restricții referitoare la valorile posibile, fiind, în
general, fixă. Trebuie menționat faptul că, există tupluri care se modifică în timp, acestea fiind
numite extensii ale unei relații.
Gradul unei relații nu reprezintă altceva, decât numărul de atribute asociat relației
(numărul de coloane ale unui tabel) iar cardinalitatea, numărul de tupluri asociate relației
(numărul de rânduri ale unui tabel).
În final, poartă numele de bază de date relațională, un set de relații normalizate,
structurate adecvat.
19
20
CAPITOLUL 2
PROIECTAREA BAZELOR DE DATE

RELAȚIONALE
În ceea ce privește etapele proiectării unei baze de date, acestea sunt următoarele:
 Proiectarea conceptuală;
 Proiectarea logică;
 Proiectarea fizică:
2.1 PROIECTAREA CONCEPTUALĂ A BAZEI DE DATE

În ceea ce privește această fază de proiectare, scopul său este acela de a se obține o
schemă conceptuală a bazei de date. Practic se construiește un model de date conceptual de
nivel înalt ce este independent de SGBD sau ce nu este specific unui anumit SGBD.
Așa cum am precizat și în subcapitolul 1.4, cel mai utilizat model conceptual de nivel
înalt este modelul Entitate-Asociere. Prin urmare, scopul acestei etape este acela de obținere a
diagramei ERD. Însă pentru realizarea acestei diagrame trebuie urmați o serie de pași ce vor fi
prezentați în cele ce urmează.
21
2.1.1 Identificarea entităților
O entitate poate fi un lucru real, tangibil, precum o persoană sau o cladire sau poate fi
o noțiune abstractă și este descrisă prin intermediul proprietăților sale. Într-o diagram ERD,
prin convenție, entitățile sunt reprezentate prin intermediul unui dreptunghi în interiorul
căruia este scris numele entității, întotdeauna cu litere mari. Trebuie precizat faptul că nu pot
exista două entități cu același nume în cadrul aceleiași diagrame ERD.
Principala modalitate de identificare a entităților, care este folosită și în cazul temei de
față, este: studierea cerinței utilizatorului, practic se caută principalele substantive prezente în
specificație, principalele obiecte de interes, excluzându-se calitățile.
În cazul temei propuse, într-o primă fază, s-au identificat următoarele entități:
 CLIENT – această entitate reprezintă persoana care poate beneficia de
serviciile oferite de compania de telefonie mobilă în schimbul achitării unei
anumite sume de bani;
 ABONAMENT – reprezintă una dintre ofertele pe care compania de telefonie
mobilă le poate oferi unui client;
 CARTELĂ – precizează cealaltă ofertă ce poate fi oferită de compania de
telefonie mobilă.
Având în vedere entitățile identificate anterior, se poate construi o primă formă a
diagramei E-A, prezentată în figura următoare.
Figura 2.1 Prima formă a diagramei Entitate-Asociere a temei date
2.1.2 Identificarea asocierilor dintre entități

Având în vedere că scopul bazei de date este acela de a modela anumite elemente din
lumea reală precum și legăturile dintre ele, este necesară reprezentarea acestor legături sau
asocieri în cadrul diagramei Entitate-Asociere.
22
Asocierile dintre entități se reprezintă prin intermediul arcelor neorientate iar fiecăreo
asocieri i se oferă un nume plasat deasupra arcului sau în mijlocul arcului, în interiorul unui
romb. Cardinalitatea asocierii, ce exprimă numărul minim și maxim de realizări a unei entități
cu cealaltă entitate asociată, se specific și el deasupra arcului neorientat ce reprezintă
asocierea. Maximul unei cardinalități este cunoscut și sub denumirea de: grad de asociere iar
minimul sub numele de: obligativitatea participării entității la asociere
2.1.2.1 Tipuri de asocieri
Clasificare tipurilor de asocieri se poate face în funcție de cardinalitatea asocierii sau
de numărul de entități distincte ce participă la asociere.
În funcție de gradul de asociere (maximul cardinalității) se cunosc următoarele tipuri
de asocieri:
 asocieri „unu-la-unu”, care se împart în funcție de gradul de obligativitate al
participării la asociere (minima cardinalității) în:
o asocieri „unu-la-unu” parțiale
o asocieri „unu-la-unu” totale
 asocieri „unu-la-multe”, care se împart și ele în:
o asocieri „unu-la-multe” parțiale
o asocieri „unu-la-multe” totale
 asocieri „multe-la-multe”, care se împart în:
o asocieri „multe-la-multe” parțiale
o asocieri „multe-la-multe” totale
În funcție de numărul de entități distincte ce participă la asociere se cunosc
următoarele tipuri de asocieri:
 binare – între două entități distincte
 recursive
 complexe – între n entități, unde n>2
În ceea ce privește asocierea „multe-la-multe” trebuie precizat faptul că, în cazul
alegerii unui anumit SGBD, ea poate devini greu de implementat și astfel, va fi transformată,
de regulă, în două asocieri „unu-la-multe”, ce sunt mult mai ușor de implementat.
O asociere parțială este o asociere în cazul căreia nicio entitate vizată nu este obligată
să participe. Practic, entitățile vizate pot participa toate la asociere sau pot participa doar
câteva din ele sau chiar niciuna. Având în vedere acest lucru rezultă faptul că minima
cardinalității este 0.
În cazul în care minima cardinalității este mai mare ca 0 atunci se poate afirma că
entitatea este obligată să participe la asociere și că, astfel, avem de-a face cu o asociere totală.
2.1.2.2 Exemplu practic
În ceea ce privește tema acestei lucrări și având în vedere tipurile de asocieri
menționate anterior, au fost identificate următoarele asocieri între entitățile din Figura 2.1:
 CARTELĂ-CLIENT – este o asociere de tipul „multe-la-multe”. Justificarea este
următoarea: Un client poate deține mai multe cartele de același tip sau de tipuri
diferite iar același tip de cartelă poate fi deținut de mai mulți clienți; de asemenea, un
client poate să nu dețină o cartelă, ci un abonament iar un anumit tip de cartelă este
neapărat deținut de un client;
 ABONAMENT-CLIENT - este o asociere de tipul „multe-la-multe”. Justificarea este
următoarea: Un client poate deține mai multe abonament de același tip sau de tipuri
23
diferite iar același tip de abonament poate fi deținut de mai mulți clienți; de asemenea,
un client poate să nu dețină un abonament, ci o cartelă iar un anumit tip de abonament
este neapărat deținut de un client;
Prin urmare, a doua formă a diagramei Entitate-Asociere a temei date este prezentată în
figura următoare.
Figura 2.2 A doua formă a diagramei Entitate-Asociere a temei date
2.1.3 Identificarea atributelor entităților și determinarea domeniilor atributelor

Pentru identificarea atributelor entităților se caută substantive în cadrul cerinței
utilizatorului care să caracterizeze entitățile găsite. Trebuie specifcat faptul că atributul nu este
altceva decât o proprietate a unei entități și că de îndată ce un atribut este identificat, trebuie
să i se precizeze tipul de date asociat, lungimea, dacă are o valoare prestabilită, dacă se
acceptă null-uri (dacă este opțional sau obligatoriu), dacă este derivat (se poate calcula din
alte atrbute existente în baza de date) sau dacă este compus.
În ceea ce privește tema propusa, pentru entitățile identificate, au fost găsite
următoarele atribute:
 Pentru entitatea CLIENT:
o cod_client – atribut obligatoriu, tipul de date: șir de caractere
o CNP - atribut obligatoriu, tipul de date: șir de caractere, dimensiune: 13
o data_nașterii - atribut obligatoriu, tipul de date: data calendaristică
o nume - atribut obligatoriu, tipul de date: șir de caractere
o prenume - atribut obligatoriu, tipul de date: șir de caractere
o adresa - atribut obligatoriu, tipul de date: șir de caractere
o numere_de_telefon_deținute - atribut obligatoriu, tipul de date: șir de
caractere
o stare_financiară - atribut opțional, tipul de date: șir de caractere
o e-mail - atribut opțional, tipul de date: șir de caractere
 Pentru entitatea ABONAMENT:

o tip_abonament - atribut obligatoriu, tipul de date: șir de caractere
o cost - atribut obligatoriu, tipul de date: întreg
o minute_rețea - atribut opțional, tipul de date: șir de caractere
o minute_naționale - atribut opțional, tipul de date: șir de caractere
o minute_roaming - atribut opțional, tipul de date: șir de caractere
o sms_rețea - atribut opțional, tipul de date: șir de caractere
o sms_naționale - atribut opțional, tipul de date: șir de caractere
o sms_roaming - atribut opțional, tipul de date: șir de caractere
o mms_rețea - atribut opțional, tipul de date: șir de caractere
o mms_naționale - atribut opțional, tipul de date: șir de caractere
o mms_roaming - atribut opțional, tipul de date: șir de caractere
o internet - atribut opțional, tipul de date: șir de caractere
o apel_video - atribut opțional, tipul de date: șir de caractere
 Pentru entitatea CARTELĂ:

24
o tip_cartelă - atribut obligatoriu, tipul de date: șir de caractere
o suma_disponibilă_inițial - atribut obligatoriu, tipul de date: întreg
În ceea ce privește entitatea CLIENT, se vor discuta următoarele atribute: codul
clientului - reprezintă de fapt un număr de marcă asociat acestuia de către compania de
telefonie mobilă, fiind un șir de numere și tocmai de aceea tipul de date este: șir de caractere;
stare_financiară - este un atribut ce poate lua doar 2 valori: „la zi” sau „restanțier” și pune în
evidență starea plăților în cazul abonamentului și tocmai de aceea este un atribut opțional, el
putând avea valoarea null în cazul în care un client nu deține un abonament.
În cazul enității ABONAMENT, vor fi explicate următoarele atribute: tip_abonament
– reprezintă tipul abonamentului (de exemplu: Cangur); apel_video – atribut ce poate lua doar
două valori: „suportat/nesuportat”, el este un atribut opțional datorită faptului că nu toate
tipurile de abonament oferă acest tip de serviciu. Prin urmare, se observă faptul că s-a ales ca
serviciile ce pot fi oferite de un abonament și menționate în cerința din Introducere să fie
considerate atribute opționale tocmai din cauza faptului că ele nu sunt oferite în cazul tuturor
abonamentelor și astfel vor putea avea valoarea Null. Trebuie menționat faptul că, în cazul
atributului cost, unitatea asociată valorii câmpului atributului va fi euro iar în cazul atributului
internet, Gb.
Mai trebuie precizat faptul că pentru atributele minute_rețea, minute_naționale,
minute_roaming, sms_rețea, sms_națioanle, sms_roaming, mms_rețea, mms_naționale,
mms_roaming, internet tipul de date ales a fost șir de caractere doarece s-a considerat
următorul lucru: aceste câmpuri pot avea și valoarea „nelimitat”.
Ajungând la entitatea CARTELĂ, vor fi detaliate următoarele atribute: tip_cartelă –
reprezintă tipul cartelei (de exemplu: Frog); suma_disponibilă_inițial – reprezintă creditul
inițial asociat cartelei. În ceea ce privește atributele opționale, este valabilă aceeași discuție ca
și în cazul entității ABONAMENT. Trebuie menționat faptul că, în cazul atributului
suma_disponibilă_inițial, unitatea asociată valorii câmpului atributului va fi euro iar în cazul
atributului internet, Gb.
2.1.4 Determinarea atributelor chei candidat și chei primare
Trecând mai departe, pentru toate entitățile identificate se aleg cheile candidat iar
dintre acestea se selectează cheia primară.
O cheie candidat nu reprezintă altceva decât cea mai mică submulțime de atribute ale
unei entități, ce identifică în mod unic orice apariție a acesteia. Cheia primară, sau atributul de
identificare, este un atribut care pentru fiecare instanță a entității prezintă o valoare unică și se
alege din toate cheile candidat identificate. Cheile candidat care nu sunt selectate drept cheie
primară sunt numite chei alternative.
Se alege dintre cheile primare cheia care:
25
 cuprinde un set minim de atribute;
 este cheia canditat care are cea mai mică probabilitate de modificare a
valorii;
 este cheia candidat care are cea mai mică probabilitate de a-și pierde
unicitatea;
 este cheia candidat cu cele mai puține caractere;
 este cheia candidat care este cel mai ușor de identificat din punct de vedere
al utilizatorului
În cazul de față, pentru entitatea CLIENT, cheile candidat sunt: cod_client și CNP.
Atât numărul de marcă al clientului cât și CNP-ul acestuia îl pot identifica în mod unic, însă
având în vedere că CNP-ul are 13 cifre și că este imposibil ca o companie de telefonie mobilă
să aibă peste un bilion de abonați, se va alege drept cheie primară atributul cod_client
deoarece are mai puține caractere.
În cazul entității ABONAMENT, singura cheie candidat este: tip_abonament și, prin
urmare, atributul tip_abonament va fi cheia primară a acestei entități.
În ceea ce privește entitatea CARTELĂ, singura cheie candidat este: tip_cartelă și,
prin urmare, atributul tip_cartelă va fi cheia primară a acestei entități.
Figura 2.3 Entitățile și atributele bazei de date proiectate

Pentru a nu încărca diagrama Entitate-Asociere, s-a ales ca prezentarea atributelor
entităților să se facă așa cum se poate observa în Figura 2.3
2.1.5 Generalizarea/Specializarea tipurilor de entități
Scopul generalizării sau al specializării este acela de a obține o diagramă Entitate-
Asociere cât mai clară, în care atât entitățile cât și relațiile dintre ele să fie vizibile. În cazul
temei propuse se va aplica procesul de generalizare deoarece, după cum se poate observa
entitățile CARTELĂ și ABONAMENT prezintă numeroase atribute comune.
Așadar, primul pas ce trebuie făcut este acela de a identifica atributele comune celor
două entități. Acestea sunt:
 minute_rețea
 minute_naționale
26
 minute_roaming
 sms_rețea
 sms_naționale
 sms_roaming
 mms_rețea
 mms_naționale
 mms_roaming
 internet
 apel_video
Prin urmare, dupa realizarea generalizării se obține o noua entitate numită OFERTĂ
datorită faptului că abonamentul sau cartela pot fi privite ca o ofertă pe care compania de
telefonie mobilă o propune clientului. Iar această nouă entitate prezintă atributele menționate
anterior. Astfel, entitățile și atributele bazei de date dupa realizarea generalizării vor fi
prezentate în Figura 2.4 iar întreaga diagramă Entitate-Asociere în Figura 2.5.
Figura 2.4 Entitățile și atributele bazei de date proiectate după generalizare
Figura 2.5 A treia formă a diagramei Entitate-Asociere a temei date
27
2.2 PROIECTAREA LOGICĂ A BAZEI DE DATE
Proiectarea logică a bazei de date este procesul în care se decide structura logică a bazei
de date sau, cu alte cuvinte, este procesul în urma căruia se obține modelul de informații al
bazei de date ce se bazează pe modelul de date dar este independent de particularizările
sistemului de gestiune a bazei de date și a altor considerente fizice. În cadrul acestei etape se
pornește de la modelul conceptual al bazei de date și, prin anumite prelucrări (ce vor fi
menționate în cele ce urmează), se obține modelul logic.
2.2.1 Construirea și validarea modelului de date logic pentru fiecare vedere a
utilizatorului
Așa cum am menționat, se pornește de la modelul comceptual și se efectuează anumite
modificări conform cerințelor unui sistem de gestionare relațional.
2.2.1.1 Transpunerea modelului de date conceptual local într-un model de date
logic local
Se ia modelul conceptual local și se elimină caracteristicile nedorite, urmând mai mulți
pași ce vor fi prezentați în cele ce urmează.
2.2.1.1.1 Eliminarea relațiilor de tip „multe-la-multe”
Datorită faptului că în cazul anumitor sisteme de gestionare a bazei de date relațiile de
tip M:N sunt mai greu de implementat, se urmărește desființarea acestora și înlocuirea lor cu
două relații de tip 1:N („unu-la-multe”).
Figura 2.6 Desființarea relațiilor M:N

Așa cum se poate observa, Figura 2.6 prezintă modul în care au fost desființate cele
două relații „multe-la-multe” existente în diagrama ERD a bazei de date a operatorului de
telefonie mobilă.
Asocierea de tip M:N dintre entitatea CARTELĂ și entitatea CLIENT a fost înlocuită
de către o nouă entitate numită CONTRACT_CARTELĂ și două asocieri de tip 1:N:
CARTELĂ – CONTRACT_CARTELĂ și CONTRACT_CARTELĂ – CLIENT. Noua
entitate a fost numită CONTRACT_CARTELĂ datorită faptului că pentru a se cunoaște
identitatea deținătorului unei cartele preplătite trebuie încheiat un fel de „contract” între acesta
și compania de telefonie mobilă în momentul achiziționării cartelei. Relația dintre entitatea
CARTELĂ și entitatea CONTRACT_CARTELĂ este una de tip „unu-la-multe” datorită
faptului că un anumit tip de cartelă poate figura în cadrul mai multor contracte, fiind
achizițonat de mai mulți clienți, însă un contract este întocmit pentru o singură cartelă și deci
pentru un singur tip de cartelă. De asemenea, trebuie precizat faptul că o cartelă trebuie să
figureze în cadrul unui contract iar într-un contract trebuie să figureze o cartelă. În ceea ce
privește relația dintre entitatea CLIENT și entitatea CONTRACT_CARTELĂ, aceasta este o
relație de tip 1:N deoarece un client poate deține mai multe contracte însă un contract aparține
unui singur client. De asemenea, este de menționat faptul că un client poate să nu dețină un
28
contract asociat unei cartele, el putând avea un abonament, însă un contract întotdeauna va
avea un client.
Și asocierea de tip M:N dintre entitatea ABONAMENT și entitatea CLIENT a fost
înlocuită de către o nouă entitate numită CONTRACT_ABONAMENT și două asocieri de tip
1:N: ABONAMENT – CONTRACT_ABONAMENT și CONTRACT_ABONAMENT –
CLIENT. Relația dintre entitatea CARTELĂ și entitatea CONTRACT_ABONAMENT este
una de tip „unu-la-multe” datorită faptului că un anumit tip de abonament poate figura în
cadrul mai multor contracte, fiind achizițonat de mai mulți clienți, însă un contract este
întocmit pentru un singur abonament și deci pentru un singur tip de abonament. De asemenea,
trebuie precizat faptul că un abonament trebuie să figureze în cadrul unui contract iar într-un
contract trebuie să figureze un anumit tip de abonament. În ceea ce privește relația dintre
entitatea CLIENT și entitatea CONTRACT_ABONAMENT, aceasta este o relație de tip 1:N
deoarece un client poate deține mai multe contracte însă un contract aparține unui singur
client. De asemenea, este de menționat faptul că un client poate să nu dețină un contract
asociat unui abonament, el putând avea o cartelă, însă un contract va avea întotdeauna un
client.
Având în vedere noile entități adaugate, entitățile finale ale bazei de date împreună cu
atributele asociate acestora sunt:
 CLIENT cu atributele:
o CNP - atribut obligatoriu, tipul de date: șir de caractere, dimensiune: 13
o data_nașterii - atribut obligatoriu, tipul de date: data calendaristică
o nume - atribut obligatoriu, tipul de date: șir de caractere
o prenume - atribut obligatoriu, tipul de date: șir de caractere
o adresa - atribut obligatoriu, tipul de date: șir de caractere
o e-mail - atribut opțional, tipul de date: șir de caractere
 ABONAMENT cu atributele:
o tip_abonament - atribut obligatoriu, tipul de date: șir de caractere
o cost - atribut obligatoriu, tipul de date: întreg
 CARTELĂ cu atributele:
o tip_cartelă - atribut obligatoriu, tipul de date: șir de caractere
o suma_disponibilă - atribut obligatoriu, tipul de date: întreg
29
 CONTRACT_ABONAMENT cu atributele:
o număr_telefon – atribut obligatoriu, tipul de date: șir de caractere,
dimensiune: 10
o tip_abonament – atribut obligatoriu, tipul de date: șir de caractere
o dată_semnare – atribut obligatoriu, tipul de date: dată calendaristică
o dată_expirare_contract – atribut obligatoriu, tipul de date: dată
calendaristică
o stare_financiară_client – atribut obligatoriu, tipul de date: șir de
caractere
 CONTRACT_CARTELĂ cu atributele:
o număr_telefon – atribut obligatoriu, tipul de date: șir de caractere,
dimensiune: 10
o tip_cartelă – atribut obligatoriu, tipul de date: șir de caractere
o dată_achiziționare_cartelă – atribut obligatoriu, tipul de date: dată
calendaristică
o dată_expirare_credit – atribut obligatoriu, tipul de date: dată
calendaristică
o credit – atribut obligatoriu, tipul de date: întreg
În cazul entității CONTRACT_ABONAMENT, atributul număr_telefon reprezintă
numărul de telefon atribuit clientului și tocmai de aceea acesta este un șir de caractere;
atributul tip_abonament reprezintă tipul abonamentului (de exemplu: Cangur); atributul
cod_client nu reprezintă altceva decât numărul de marcă asociat clientului; atributul
dată_semnare reprezintă data la care a fost semnat contractul; atributul dată_expirare_contract
reprezintă data la care contractul expiră și trebuie realizat un act adițional prin care acesta este
prelungit iar atributul stare_financiară_client poate lua doar două valori: „la zi/restanțier” și
pune în evidență starea plăților clientului.
În ceea ce privește cheile candidat ale entității CONTRACT_ABONAMENT, acestea
sunt: număr_telefon; număr_telefon și tip_abonament; număr_telefon și cod_client;
număr_telefon, cod_client și tip_abonament; orice combinație ce conține număr_telefon.
Dintre toate aceste chei candidat, cheia primară aleasă a fost: număr_telefon deoarece
îndeplinește toate caracteristicile pe care trebuie să le aibă o cheie primară și care au fost
menționate în subcapitolul: 2.1.4 .
Trecând mai departe la entitatea CONTRACT_CARTELĂ, atributul număr_telefon
reprezintă numărul de telefon atribuit clientului și tocmai de aceea acesta este un șir de
caractere; atributul tip_cartelă reprezintă tipul cartelei (de exemplu: Frog); atributul
cod_client nu reprezintă altceva decât numărul de marcă asociat clientului; atributul
data_achiziționare_cartelă reprezintă data la care a fost achiziționată cartela; atributul
30
data_expirare_credit reprezintă data la care creditul expiră dacă nu este folosit și trebuie
reîncărcată cartela iar atributul credit nu reprezintă altceva decât creditul rămas.
În ceea ce privește cheile candidat ale entității CONTRACT_CARTELĂ, acestea sunt:
număr_telefon; număr_telefon și tip_cartelă; număr_telefon și cod_client; număr_telefon,
cod_client și tip_cartelă; orice combinație ce conține număr_telefon. Dintre toate aceste chei
candidat, cheia primară aleasă a fost: număr_telefon deoarece îndeplinește toate
caracteristicile pe care trebuie să le aibă o cheie primară și care au fost menționate în
subcapitolul: 2.1.4 .
În ceea ce privește entitatea CLIENT, s-a ales să se elimine atributul numere_de_telefon
deținute deoarece se pot afla numerele de telefon deținute și prin verificarea contractului
asociat cartelei sau abonamentului. De asemenea, s-a mai eliminat atributul opțional
stare_financiară deoarece și această informație poate fi obținută în alt fel și anume prin
verificarea contractului asociat abonamentului.
În cazul entității CONTRACT_ABONAMENT singura cheie candidat este atributul
număr_telefon și prin urmare acesta va fi cheia primară a entității.
Același lucru și în cazul entității CONTRACT_CARTELĂ singura cheie candidat este
atributul număr_telefon și prin urmare acesta va fi cheia primară a entității.
Figura 2.7 Entitățile și atributele bazei de date proiectate după eliminarea relațiilor M:N
2.2.1.1.2 Eliminarea relațiilor complexe
Numim relație complexă, asocierea dintre m entități, unde m ≥ 3. O astfel de relație
trebuie neapărat înlocuită de către mai multe relații de tip 1:N. Cum în cazul diagramei ERD a
bazei de date proiectate în cadrul acestei lucrări nu avem relații complexe, acest pas va fi sărit.
2.2.1.1.3 Eliminarea relațiilor recursive
O relație recursivă este, de fapt, o asociere dintre o entitate și ea însăși și trebuie
descompusă pentru a se identifica o relație intermediară. Și această etapă va fi sărită datorită
faptului că nu exită relații recursive în cadrul diagramei ERD a bazei de date a operatorului de
telefonie mobilă.
2.2.1.1.4 Eliminarea relațiilor cu atribute
Existența unei astfel de relații indică faptul că nu a fost identificată o anumită entitate și
prin urmare trebuie introdusă această nouă entitate în cadrul diagramei ERD. Cum în cazul
diagramei ERD a bazei de date proiectate în cadrul acestei lucrări nu avem relații ce au
asociate atribute, această etapă va fi sărită.
2.2.1.1.5 Eliminarea atributelor cu valori multiple
31
Atributele cu mai multe valori sunt acele atribute care pot avea mai multe valori în cazul
aceleiași instanțe. Un astfel de atribut trebuie descompus pentru a identfica o nouă entitate. Și
acest pas va fi sărit datorită faptului ca nu există astfel de atribute în cazul bazei de date
proiectate.
2.2.1.1.6 Eliminarea relațiilor redudante
O relație este redundantă atunci când aceeași informație se poate obține și prin alte
relații. Cum în cazul exemplului prezentat în această lucrare nu există astfel de relații această
etapă va fi sărită.
2.2.1.2 Extragerea relațiilor (tipurilor de entități) din modelul de date logic local
Toți pașii efectuați până în acest punct au dus la obținerea modelului de date logic din
modelul de date conceptual.
În continuare, din modelul de date logic se vor extrage relațiile ce vor reprezenta
entitățile ce le compun. Fiecare relație va fi descrisă cu ajutorul unui limbaj de definire a
bazelor de date, astfel: se va denumi relația, apoi, între paranteze atributele simple (ce nu pot
fi descompuse în alte atribute).
Trebuie menționat faptul că relația dintre două entități este exprimată prin asocierea
cheie primară – cheie străină. Cu alte cuvinte, cheia primară din entitatea părinte devine cheie
străină în entitatea copil.
Cheia străină sau cheia externă este reprezentată de un atribut sau un grup de atribute
al unei relații, R1, a cărui valoare sau ale căror valori sunt definite pe același domeniu
respectiv aceleași domenii ca și cheia primară a unei alte relații, R2. O astfel de cheie străină
are rolul de a modela legptura dintre cele două relații (tabele).
În continuare, se vor prezenta relațiile extrase:
Clienți(cod_client, CNP, nume, prenume, data_nașterii, adresa, e-mail)
Cheie primară: cod_client
Contracte_abonamente(număr_telefon, tip_abonament, cod_client, dată_semnare,

dată_expirare_contract, stare_financiară)
Cheie primară: număr_telefon
Chei străine: tip_abonament, cod_client
Abonamente(tip_abonament, cost, minute_rețea, minute_naționale, minute_roaming,

sms_rețea, sms_naționale, sms_roaming, mms_rețea, mms_naționale, mms_roaming, internet,
apel_video)
Cheie primară: tip_abonament
Contracte_cartele(număr_telefon, tip_cartelă, cod_client, data_achiziționare_cartelă,

dată_expirare_credit, credit)
Cheie primară: număr_telefon
Chei străine: tip_cartelă, cod_client
32
Cartele(tip_cartelă, suma_disponibilă inițial, minute_rețea, minute_naționale,
minute_roaming, sms_rețea, sms_naționale, sms_roaming, mms_rețea, mms_naționale,
mms_roaming, internet, apel_video)
Cheie primară: tip_cartelă
2.2.1.3 Utilizarea normalizării

Normalizarea bazei de date nu reprezintă altceva decât un proces prin intermediul căruia
o relație inițială R (numită și relație universală) este descompusă succesiv în subrelații.
Relația inițială poate fi reconstituită ulterior din cele n relații obținute în urma normalizării
prin aplicarea asupra acestora a unor operații de joncțiune.
Etapele normalizării sunt prezentate în figura următoare.
33
Figura 2.8 Etapele normalizării
34
Astfel, o relație se află într-o formă normală dacă satisface o serie de constrângeri, așa
cum se sugerează și în Figura 2.9. De exemplu, o relație se află în a treia formă normală
(3FN) dacă și numai dacă se află în a două formă normal (3FN).
Figura 2.9 Formele normale ale unei relații
În Figura 2.8 au fost introduce noi concepte precum: atribute atomice. Acestea vor fi
explicate în cele ce urmează.
Un atribut atomic este un atribut ce nu poate fi descompus în alte atribute. Astfel, dacă
atributele din modelul logic sunt atomice se poate spune că baza de date se află în prima
formă normală.
2.2.1.3.1 Prima formă normală (1FN)
Prima formă nomală este legată de noțiunea introdusă mai devreme, și anume: atribut
atomic. De asemenea se mai introduce următoarele noțiuni:
 atribut simplu
 atribut compus
 grupuri repetitive de atribute
Un atribut simplu, sau atribut atomic, este un atribut care nu mai poate fi descompus în
alte atribute (de exemplu, în cazul bazei de date proiectate în această lucrare, atributul „nume”
este un atribut simplu). În caz contrar, avem de-a face cu un atribut compus (atribut
neatomic).
Există câteva exemple de atribute, ce se regăsesc și în cazul exemplului luat în
considerare în această lucrare, care pot fi considerate simple sau compuse, în funcție de
obiectivele bazei de date:
 data calendaristică – acesta conține câmpurile: zi, lună, an
 adresă – acesta conține câmpurile: stradă, număr, bloc, scară, etaj, apartament,
localitate, județ
Un grup repetitiv este un grup de atribute care apar cu valori multiple pentru o singură
apariție a cheii primare a relației nenormalizate, cu alte cuvinte, care apar cu valori multiple
pentru aceeași instanță a unei entități.
Dintre toate cele cinci forme normale, doar prima formă are character de
obligativitate, prin urmare pentru a putea continua proiectarea este suficient să verificăm dacă
baza de date proiectată până acum conține relații ce se află în prima formă normală.
35
O relație se află în prima formă normală dacă toate atributele asociate acesteia sunt
atribute atomice. De semenea, un tuplu nu trebuie să conțină atribute sau grupuri de atribute
repetitive. Prin urmare, pentru a aduce o relație în prima formă normală trebuie eliminate
atributele neatomice și atributele repetitive.
Etapele de aducere a unei relații în prima formă normală sunt:
 pentru fiecare grup repetitiv se construiește câte o relație
 fiecărei noi relații obținute în urma pasului anterior i se adaugă și cheia primară
a relației R nenormalizate
 cheia primară a noii relații va fi compusă din cheile relației R, la care se adugă
unul sau mai multe atribute proprii.
În figura următoare sunt prezentate relațiile asociate bazei de date proiectate în cadrul
acestei lucrări.
Figura 2.10 Relațiile bazei de date proiectate

Analizând atributele asociate relațiiilor se poate observa că nu se regăsesc printre
acestea atribute repetitive sau grupuri de atribute repetitive. În ceea ce privește atributele
compuse se poate observa că următoarele atribute candidează la acest statut:
dată_achiziționare_cartelă, dată_expirare_credit, data_nașterii, adresa, dată_semnare,
dată_expirare_contract. În ceea ce privește adresa unui client, aceasta ne interesează la nivel
global și acelaș lucru poate fi afirmat despre celelalte atribute reprezentând o dată
calendaritică. Prin urmare acestea or fi considerate atribute simple. Așadar, relațiile se află
deja în prima formă normal și nu trebuie realizată nicio prelucrare în cadrul acestei etape. Cu
alte cuvinte, baza de date este normalizată.
2.2.1.4 Definirea constrângerilor de integritate
Impunerea anumitor constrângeri protejează baza de date împotriva riscului de
incoerență. Prin urmare, se urmărește ca datele să fie coerente și ca orice actualizare a unui
articol (stocat o singură dată) să se facă o singură dată.
Există cinci tipuri de integritate:
 integritatea datelor cerute
 integritatea domeniilor atributelor
 integritatea entităților
 integritatea referențială
 constrângerile întreprinderii
36
2.2.1.4.1 Integritatea datelor cerute
Anumite atribute nu pot avea valoarea Null, aceste atribute fiind, de fapt atribute
obligatorii. În cazul bazei de date proiectate în această lucrare s-a asigurat integritatea datelor
cerute prin specificarea, în dreptul fiecărui atribut, a opționalității acestuia: „obligatoriu” sau
„optional”.
2.2.1.4.2 Constrângerile privind domeniile atributelor
În cazul bazei de date proiectate în cadrul acestei lucrări, constrângerile au fost impuse
în momentul alegerii atributelor.
2.2.1.4.3 Integritatea entităților
Se referă la faptul că o cheie primară a unei entități nu poate avea valoare Null. În
cazul nostru s-a respectat acest lucru datorită faptului că s-au ales drept chei primare atribute
obligatorii.
2.2.1.4.4 Integritatea referențială
Integritatea referențială vizează relația entitate părinte – entitate copil. Trebuie amintit
următorul lucru: cheia primară a entității părinte e copiază în entitatea copil, devenind cheie
străină.
Integritatea referențială înseamnă următorul lucru: o valoare nenulă a cheii străine din
entitatea copil trebuie să coincide cu o valoare nenulă în entitatea părinte. Dacă entitatea copil
prezintă o participare totală în asociere, atunci nu sunt premise Null-uri în câmpul cheie
străină, acestea fiind premise în cazul în care entitatea copil prezintă o participare parțială.
Integritatea referențială se realizează prin constrângeri de existență, ce definesc
condițiile în care poate fi inserată, modificată sau ștearsă o cheie străină.
Se va lua drept exemplu relația: Client are un Contract_Abonament, de cardinalitate
1:N.
Entitatea părinte (Ep): Clienți, cu cheia primară: cod_client.
Entitatea copil (Ec): Contracte_Abonamente, cu cheia străină: cod_client, copie a cheii
primare din Client.
În cazul inserării unei apariții în relația (entitatea) copil, pentru a se asigura
integritatea referențială se verifică dacă atributul cod_client din noua apariție introdusă în Ec
este stabilt ca sau are o valoare existentă în Ep. În cazul nostru, având în vedere că un contract
are asociat întotdeauna un client, cheia străină cod_client nu va avea niciodată valoarea Null.
În ceea ce privește ștergerea unei apariții din relația (entitatea) copil aceasta se poate
efectua fără probleme, integritatea referențială nefiind afectată.
Dacă se reactualizează cheia străină în relația (entitatea) copil trebuie stabilit dacă
aceasta este Null sau are o valoare existentă în relația (entitatea) părinte. În cazul nostru,
având în vedere că un contract are asociat întotdeauna un client, cheia străină cod_client nu va
avea niciodată valoarea Null.
Inserarea unei apariții în relația (entitatea) părinte se poate efectua fără problem
datorită faptului că Ep are o participare parțială. Cu alte cuvinte, poate exista un client care nu
are un contract asociat unui abonament.
37
În ceea ce privește ștergerea unei apariții din relația (entitatea) părinte, dacă acelei
apariții îi corespund una sau mai multe apariții în entitatea copil, atunci integritatea
referențială se pierde. Astfel, se vor lua în considerare următoarele strategii:
 NO ACTION – se blochează ștergerea apariției din relația (entitatea) părinte
dacă acesteia îi corespund mai multe apariții în relația (entitatea) copil;
 CASCADE – se șterg automant aparițiile corespondente din (entitatea) copil
dacă se șterge o apariție în relația (entitatea) părinte. Dacă relația (entitatea)
copil este o relația (entitatea) părinte pentru o altă relație (entitate), ștergerea se
propagă în cascadă;
 SET NULL – se setează valoarea cheii străine la Null, această strategie putând
fi aplicată numai în cazul în care cheia străină acceptă valoarea Null;
 SET DEFAULT – se setează cheia străină la o valoare prestabilită.
 NO CHECK – nu se verifică integritatea. Cul alte cuvinte, când se realizează
ștergerea nu se garantează menținerea integrității referențiale.
De asemenea se pierde integritatea referențială dacă se dorește reactualizarea unei chei
primare în relația (entitatea) părinte iar acesteia îi corespundeau una sau mai multe apariții în
entitatea copil.
2.2.1.4.5 Constrângerile întreprinderii
Sunt regulile de afaceri care, uneori, pot genera reactualizări ale entităților.
Toate constângerile prezentate mai sus trebuie luate în considerare în momentul în

care se trece la implementarea fizică.
Încheiată fiind proiectarea logică, relațiile bazei de date, precum și legăturile dintre
ele, sunt prezentate în cele ce urmează.
Trebuie precizat că, datorită limitelor impuse de spațiu, au fost făcute următoarele
prescurtări:
 sumă_disp_iniț = sumă_disponibilă_inițial
 min_reț = miunte_rețea
 min_naț = minute_naționale
 min_ro = minute_roaming
 sms_reț = sms_rețea
 sms_naț = sms_naționale
 sms_ro = sms_roaming
 mms_reț = mms_rețea
 mms_naț = mms_naționale
 mms_ro = mms_ roaming
38
CARTELE
min min min sms sms sms mms_ mms_ mms_
tip_cartelă sumă_disp_iniț internet apel_video
_reț _naț _ro _reț _naț _ro reț naț ro
Frog 5 100 50 50 100 50 50 10 10 10 10 nu
FrogXXL 10 1000 500 100 1000 500 500 50 50 50 20 da
CONTRACTE_CARTELE
număr_telefon tip_cartelă cod_client dată_achiziționare_cartelă dată_expirare_credit credit
0744112333 Frog 3800 28.08.2014 02.02.2017 2
0744300200 FrogXXL 2667 01.09.2013 03.03.2017 5
CLIENȚI
cod_client CNP nume prenume data_nașterii adresa e-mail
Giurgiu, N.
3800 2930831424226 Ivan Irina 31.08.1993 Titulescu, nr. ivanirina93@gmail.com
57
Giurgiu, N.
2667 1930601112233 Anghel Ion 01.06.1993 Titulescu, nr. anghelion@gmail.com
50
CONTRACTE_ABONAMENTE
număr_telefon tip_abonament cod_client dată_semnare data_expirare_contract stare_financiară
074411244 Cangur 3800 01.07.2014 02.02.2018 la zi
0744300211 CangurXXL 2667 01.10.2013 03.03.2018 restanțier
ABONAMENTE
min min min sms sms sms mms_ mms_ mms_
tip_abonament cost internet apel_video
_reț _naț _ro _reț _naț _ro reț naț ro
Cangur 10 1000 500 150 1000 250 50 10 10 10 10 nu
CangurXXL 30 2000 500 100 5000 1500 500 50 50 50 20 da
Figura 2.11 Relațiile bazei de date și legăturile dintre ele
2.3 PROIECTAREA FIZICĂ A BAZEI DE DATE

Proiectarea fizică nu reprezintă altceva decât procesul de descrere a implementării bazei
de date într-un SGBD. În această etapă există un feedback între proiectarea fizică și cea
logică, pentru că deciziile luate în cadrul implementării fizice pot afecta modelul logic al
bazei de date.
39
40
CAPITOLUL 3
IMPLEMENTAREA FIZICĂ A MODELULUI

LOGIC ASOCIAT BAZEI DE DATE A UNUI
OPERATOR DE TELEFONIE MOBILĂ
Modelul logic a fost implementat în mediul Oracle Database 11g Express Edition
folosindu-se limbajul SQL. În continuare va fi prezentat modul de implementare.
3.1 CREAREA TABELULOR

Pentru crearea tabelelor s-a folosit instrucțiunea a cărei sintaxă este descrisă în cele ce
urmează:
CREATE TABLE nume_tabel
(
41
nume_coloană1 tip_date [NULL | NOT NULL],
…
nume_coloanăn tip_date [NULL | NOT NULL],
);
Pentru relația CLIENȚI:
Figura 3.1 Instrucțiunea folosită pentru crearea tabelului CLIENȚI

Având în vedere că a fost uitată introducerea coloanei „CNP” s-a folosit următoarea
instrucțiune pentru adăugarea acesteia:
ALTER TABLE clienti
ADD CNP VARCHAR2 (13);
Iar pentru a specifica faptul că valorile asociate acestei coloane nu pot fi nule s-a
folosit comanda:
ALTER TABLE clienti
MODIFY CNP VARCHAR2 (13) NOT NULL;
Figura 3.2 Tabelul CLIENȚI a fost creat
Pentru relația CARTELE:

CREATE TABLE cartele(
tip_cartela VARCHAR2 (30) NOT NULL,
42
suma_disponibila_initial number (3) NOT NULL,
minute_retea VARCHAR2 (15),
minute_nationale VARCHAR2 (15),
minute_roaming VARCHAR2 (15),
sms_retea VARCHAR2 (15),
sms_nationale VARCHAR2 (15),
sms_roaming VARCHAR2 (15),
mms_retea VARCHAR2 (15),
mms_nationale VARCHAR2 (15),
mms_roaming VARCHAR2 (15),
internet VARCHAR2 (15),
apel_video VARCHAR2 (2)
);
Figura 3.3 Tabelul CARTELE implementat

Pentru relația ABONAMENTE:
CREATE TABLE abonamente(
tip_abonament VARCHAR2 (30) NOT NULL,
cost number (3) NOT NULL,
minute_retea VARCHAR2 (15),
minute_nationale VARCHAR2 (15),
minute_roaming VARCHAR2 (15),
sms_retea VARCHAR2 (15),
43
sms_nationale VARCHAR2 (15),
sms_roaming VARCHAR2 (15),
mms_retea VARCHAR2 (15),
mms_nationale VARCHAR2 (15),
mms_roaming VARCHAR2 (15),
internet VARCHAR2 (15),
apel_video VARCHAR2 (2)
);
Figura 3.4 Tabelul ABONAMENTE implementat

Pentru relația CONTRACTE_CARTELE:
CREATE TABLE contracte_cartele(
numar_telefon VARCHAR2 (10) NOT NULL,
tip_cartela VARCHAR2 (30) NOT NULL,
cod_client VARCHAR2 (10) NOT NULL,
data_achizitionare_cartela date NOT NULL,
data_expirare_credit date NOT NULL,
credit number (3,2) NOT NULL
);
44
Figura 3.5 Tabelul CONTRACTE_CARTELE implementat
Pentru relația CONTRACTE_ABONAMENTE:

CREATE TABLE contracte_abonamente(
numar_telefon VARCHAR2 (10) NOT NULL,
tip_abonament VARCHAR2 (30) NOT NULL,
cod_client VARCHAR2 (10) NOT NULL,
data_semnare date NOT NULL,
data_expirare_contract date NOT NULL,
stare_financiara VARCHAR2 (10) NOT NULL
);
Figura 3.6 Tabelul CONTRACTE_ABONAMENTE implementat
3.2 ADĂUGAREA CHEII PRIMARE ȘI A CHEII STRĂINE

Sintaxa folosită pentru adăugarea cheii primare este următoarea:
ALTER TABLE nume_tabel
ADD CONSTRAINT nume_constrângere PRIMARY KEY (nume_coloană1, nume_coloană2,
nume_coloană2, …, nume_coloanăn)
Sintaxa folosită pentru adăugarea cheii străine este următoarea:
ALTER TABLE nume_tabel
45
ADD CONSTRAINT nume_constrângere
FOREIGN KEY (nume_coloană1, nume_coloană2, nume_coloană3, …, nume_coloanăn)
REFERENCES nume_tabel_referit (nume_coloană1, nume_coloană2, nume_coloană3, …,
nume_coloanăn);
Pentru relația CLIENȚI:
ALTER TABLE clienti
ADD CONSTRAINT clienti_pk PRIMARY KEY (cod_client);
Figura 3.7 Cheie primară tabel CLIENȚI
Pentru relația ABONAMENTE:

ALTER TABLE abonamente
ADD CONSTRAINT abonamente_pk PRIMARY KEY (tip_abonament);
Figura 3.8 Cheie primară tabel ABONAMENTE

46
Pentru relația CARTELE:
ALTER TABLE cartele
ADD CONSTRAINT cartele_pk PRIMARY KEY (tip_cartela);
Figura 3.9 Cheie primară tabel CARTELE
Pentru relația CONTRACTE_ABONAMENTE:

ALTER TABLE contracte_abonamente
ADD CONSTRAINT contracte_abonamente_pk PRIMARY KEY
(numar_telefon);

ADD CONSTRAINT contracte_abonamente_pk1
FOREIGN KEY (tip_abonament)
REFERENCES abonamente (tip_abonament);

ADD CONSTRAINT contracte_abonamente_pk2
FOREIGN KEY (cod_client)
REFERENCES clienti (cod_client);
47
Figura 3.10 Cheie primară și chei străine tabel CONTRACTE_ABONAMENTE
Pentru relația CONTRACTE_CARTELE:

ALTER TABLE contracte_cartele
ADD CONSTRAINT contracte_cartele_pk PRIMARY KEY (numar_telefon);

ADD CONSTRAINT contracte_cartele_pk1
FOREIGN KEY (tip_cartela)
REFERENCES cartele (tip_cartela);

ADD CONSTRAINT contracte_cartele_pk2
FOREIGN KEY (cod_client)
REFERENCES clienti (cod_client);
Figura 3.11 Cheie primară și chei străine tabel CONTRACTE_CARTELE
48
3.3 INSERAREA DATELOR ÎN TABELE
Sintaxa instrucțiunii folosite pentru popularea tabelelor cu date este următoarea:
INSERT INTO nume_tabel (nume_coloană1, nume_coloană2, nume_coloană3...,
nume_coloanăn)
VALUES (valoare1,valoare2, valoare3 ..., valoaren);
Trebuie menționat faptul că, datele vor fi inserate cu succes dacă se respectă
constrângerile de integritate.
Inserarea datelor în tabelul CARTELE:
INSERT INTO cartele (tip_cartela, suma_disponibila_initial, minute_retea,
minute_nationale, minute_roaming, sms_retea, sms_nationale, sms_roaming,
mms_retea, mms_nationale, mms_roaming, internet, apel_video)
VALUES ('Frog', 5, '1000', '1000', NULL, '1000', '1000', NULL, NULL,
NULL, NULL, '10', 'da');

VALUES ('FrogXXL', 15, 'nelimitat', 'nelimitat', '100', 'nelimitat', 'nelimitat',
'100', '1000', '1000', '100', '30', 'nu');

VALUES ('Express', 30, 'nelimitat', 'nelimitat', 'nelimitat', 'nelimitat',
'nelimitat', 'nelimitat', 'nelimitat', 'nelimitat', 'nelimitat', 'nelimitat', 'da');
Pentru a vizualiza înregul tabel populat s-a folosit următoarea comandă: SELECT *
FROM clienti;.
Figura 3.12 Tabelul CARTELE populat

Pentru a vedea mai bine datele introduse în tabelul CARTELE, acesta s-a împărțit în
două așa cum se poate observa și în figurile următoare:
Figura 3.13 Prima jumătate a tabelul CARTELE
49
Figura 3.14 A doua jumătate a tabelului CARTELE
Inserarea datelor în tabelul ABONAMENTE:
INSERT INTO abonamente (tip_abonament, cost, minute_retea,
VALUES ('Cangur', 10, '1000', '500', NULL, '1000', '500', NULL, '100', '100',
NULL, '2', 'da');

VALUES ('Pantera', 20, 'nelimitat', '2000', '1000', 'nelimitat', '2000', '500',
'1000', '500', NULL, '20', 'da');

VALUES ('Delfin', 30, 'nelimitat', 'nelimitat', 'nelimitat', 'nelimitat', 'nelimitat',
'nelimitat', 'nelimitat', 'nelimitat', 'nelimitat', 'nelimitat', 'da');
Figura 3.15 Tabelul ABONAMENTE populat

Pentru a vedea mai bine datele introduse în tabelul ABONAMENTE, acesta s-a
împărțit în două așa cum se poate observa și în figurile următoare:
Figura 3.16 Prima jumătate a tabelului ABONAMENTE
Figura 3.17 A doua jumătate a tabelului ABONAMENTE

Inserarea datelor în tabelul CLIENȚI:
50
INSERT INTO clienti (cod_client, CNP, nume, prenume, data_nasterii, adresa,
email)
VALUES ('111', '2930831000000', 'Ivan', 'Irina', TO_DATE('31.08.1993',
'DD.MM.YYYY'), 'N. Titulescu, nr. 57, Giurgiu', 'ivanirina@gmail.com');

email)
VALUES ('2681', '1860620110022', 'Popescu', 'Ion', TO_DATE('20.06.1986',
'DD.MM.YYYY'), 'Partizani, nr. 60, Buzau', 'popescuion@gmail.com');

email)
VALUES ('3678', '2700121333124', 'Andrei', 'Emilia',
TO_DATE('21.01.1970', 'DD.MM.YYYY'), 'M. Viteazul, nr. 13, Ploiesti',
'emiliaandrei@gmail.com');

email)
VALUES ('4001', '1920301123456', 'Stan', 'Filip', TO_DATE('01.03.1992',
'DD.MM.YYYY'), 'Cantacuzino, nr. 1, Buzau', 'stanfilip@gmail.com');

email)
VALUES ('5555', '2900228555666', 'Vulcan', 'Sanda', TO_DATE('28.02.1990',
'DD.MM.YYYY'), 'Pacii, nr. 51, Craiova', 'sandavulcan@gmail.com');

email)
VALUES ('6781', '1890401567123', 'Ionescu', 'Ciprian',
TO_DATE('01.04.1989', 'DD.MM.YYYY'), 'Libertatii, nr. 50, Galati',
'ciprianionescu@gmail.com');
Figura 3.18 Tabelul CLIENȚI populat
51
Inserarea datelor în tabelul CONTRACTE_CARTELE:
INSERT INTO contracte_cartele (numar_telefon, tip_cartela, cod_client,

data_achizitionare_cartela, data_expirare_credit, credit)
VALUES ('0744758900', 'Frog', '111', TO_DATE('01.01.2007',
'DD.MM.YYYY'), TO_DATE('06.03.2017', 'DD.MM.YYYY'), 3.95);

VALUES ('0744668111', 'FrogXXL', '6781', TO_DATE('10.08.2008',

VALUES ('0744500123', 'Frog', '5555', TO_DATE('27.02.2010',

VALUES ('0744100200', 'Express', '4001', TO_DATE('31.08.2014',
Figura 3.19 Tabelul CONTRACTE_CARTELE populat
Inserarea datelor în tabelul CONTRACTE_ABONAMENTE:

INSERT INTO contracte_abonamente (numar_telefon, tip_abonament,
cod_client, data_semnare, data_expirare_contract, stare_financiara)
VALUES ('0744 491 123', 'Cangur', '3678', TO_DATE('10.10.2012',
'DD.MM.YYYY'), TO_DATE('31.08.2018', 'DD.MM.YYYY'), );

VALUES ('0744299199', 'Pantera', '2681', TO_DATE('01.12.2014',
'DD.MM.YYYY'), TO_DATE('10.10.2019', 'DD.MM.YYYY'), 'restantier');
52
VALUES ('0744311212', 'Delfin', '111', TO_DATE('31.08.2015',
'DD.MM.YYYY'), TO_DATE('10.11.2019', 'DD.MM.YYYY'), 'la zi');

VALUES ('0744700100', 'Pantera', '4001', TO_DATE('28.02.2013',
'DD.MM.YYYY'), TO_DATE('01.06.2017', 'DD.MM.YYYY'), 'la zi');
Figura 3.20 Tabelul CONTRACTE_ABONAMENTE populat
3.4 CREAREA VEDERILOR

O vedere nu reprezintă altceva decât structura bazei de date, așa cum apare ea unui
anumit utilizator. De asemenea, ea este rezultatul dinamic al uneia sau mai multor operații
ralaționale care acționează asupra relațiilor de bază, cu scopul de a se obține altă relație.
O relație de bază este o relație cu o anumită denumire ce-i corespunde unei entități din
schema conceptuală și ale cărei tupluri sunt stocate fizic în baza de date.
O vedere este o relație virtuală ce nu există în realitate în baza de date ci este produsă în
momentul respectiv, la cererea utilizatorului. Vederile sunt dinamice, cu alte cuinte,
modificările în relațiile de bază sunt reflectate imediat în vederi și invers, modificările ce sunt
permise și care sunt operate asupra vederii se transmit relațiilor de bază.
Pentru a crea o vedere se folosește instrucțiunea ce prezintă următoarea sintaxă:
CREATE VIEW nume_vedere AS

SELECT t1.coloana1, t2.coloana1, t2.coloana3
FROM tabel1 t1
INNER JOIN tabel2 t2
ON t1.coloana1 = t2.coloana1
WHERE t1.coloana2 = abc;
3.4.1 Vederea care afișează clienții din roaming, ce au fie abonament, fie cartelă,
fie și abonament și cartelă
Vom considera că un client este în roaming dacă toate atributele: minute_roaming,
sms_roaming, mms_roaming nu sunt NULL.
53
Pentru realizarea vederii s-a procedat în felul următor:
 folosindu-se operatorul INNER JOIN (acesta selectează rânduri din două
tabele atât timp cât există o potrivire între anumite coloane ale tabelelor) s-au
selectat clienții care au abonament și sunt în roaming. În cazul exemplului
nostru, a trebuit să existe o potrivire între cheia primară a tabelului părinte și
cheia străină a tabelului copil.
 tot folosindu-se operatorul INNER JOIN s-au selectat clienții care au cartelă și
sunt în roaming
 pentru a se afișa împreună rezultatele obținute anterior s-a folosit operatorul
UNION (acesta combină rezultatul a două sau mai multe selecții)
Astfel, instrucțiunile folosite au fost următoarele:
CREATE VIEW clienti_roaming AS
SELECT c.cod_client, c.CNP, c.nume, c.prenume, ab.tip_abonament as
nume_oferta, ab.minute_roaming, ab.sms_roaming, ab.mms_roaming FROM clienti c
INNER JOIN contracte_abonamente ca
ON ca.cod_client = c.cod_client
INNER JOIN abonamente ab
ON ab.tip_abonament = ca.tip_abonament
WHERE ab.minute_roaming IS NOT NULL
AND ab.sms_roaming IS NOT NULL
AND ab.mms_roaming IS NOT NULL
UNION
SELECT c.cod_client, c.CNP, c.nume, c.prenume, car.tip_cartela as
nume_oferta, car.minute_roaming, car.sms_roaming, car.mms_roaming FROM clienti
c
INNER JOIN contracte_cartele cc
ON cc.cod_client = c.cod_client
INNER JOIN cartele car
ON car.tip_cartela = cc.tip_cartela
WHERE car.minute_roaming IS NOT NULL
AND car.sms_roaming IS NOT NULL
AND car.mms_roaming IS NOT NULL;
Figura 3.21 Vederea care afișează clienții din roaming, ce au fie abonament, fie cartelă, fie și
abonament și cartelă
54
3.4.2 Vederea care afișează clienții ce au o anumită vechime
Vom presupune că se dorește afișarea clienților ce au o vechime mai mare de 4 ani.
 folosindu-se operatorul INNER JOIN s-au selectat clienții care au abonament
și au o vechime de peste 4 ani
au o vechime de peste 4 ani
UNION
CREATE VIEW clienti_vechi AS

nume_oferta, ca.data_semnare as client_incepand_cu FROM clienti c
WHERE MONTHS_BETWEEN(SYSDATE, ca.data_semnare)/12 > 4
UNION
nume_oferta, cc.data_achizitionare_cartela as client_incepand_cu FROM clienti c
WHERE MONTHS_BETWEEN(SYSDATE,
cc.data_achizitionare_cartela)/12 > 4;
Figura 3.22 Vederea care afișează clienții cu o vechime de peste 4 ani
55
3.4.3 Vederea care afișează clienții care lunar, în cazul abonamentelor, sau la
reîncărcare, în cazul cartelei, plătesc peste o anumită sumă
Se presupune că se dorește afișarea clienților care plătesc peste 15 euro.

 folosindu-se operatorul INNER JOIN s-au selectat clienții care au abonament
și plătesc lunar peste 15 euro
plătesc la reîncărcare peste 15 euro
UNION
CREATE VIEW clienti_cost AS

nume_oferta, ab.cost as suma_platita FROM clienti c
WHERE ab.cost>15
UNION
nume_oferta, cc.suma_disponibila_initial as suma_platita FROM clienti c
WHERE cc.suma_disponibila_initial>15;
Figura 3.23 Vederea care afișează clienții care lunar, în cazul abonamentelor, sau la reîncărcare,
în cazul cartelei, plătesc peste 15 euro
56
BIBLIOGRAFIE
[1]Olteanu, A., Anghel M., Pietraru R. N., „Baze de date și utilizarea acestora”;
[2]„Conceptele fundamentale ale bazelor de date”, http://vega.unitbv.ro/~cataron/Courses/
BD/BD_Cap_1.pdf;
[3]„Proiectarea bazelor de date relaționale”, http://id.inf.ucv.ro/~popirlan/bd/laborator3.pdf;
[4]Galațchi, D., Note de curs
57

BDTC Proiect Ivan Andra Irina

Î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

BDTC Proiect Ivan Andra Irina

Încărcat de

Drepturi de autor:

Formate disponibile

UNIVERSITATEA POLITEHNICA BUCUREȘTI

FACULTATEA DE ELECTRONICĂ, TELECOMUNICAȚII ȘI TEHNOLOGIA INFORMAȚIEI

PROIECTAREA UNUI BAZE DE DATE A UNUI OPERATOR DE

Figura 1.1 Notațiile folosite pentru realizarea ERD .....................................................................15

SGBD – Sistem de Gestionare a Bazelor de Date

CONCEPTELE FUNDAMENTALE ALE BAZELOR

1.1 CE ESTE O BAZĂ DE DATE?

1.2 SISTEMUL DE GESTIONARE A BAZEI DE DATE (SGBD)

1.3 CLASIFICAREA SISEMELOR DE BAZE DE DATE

1.4 MODELUL ENTITATE-ASOCIERE

Figura 1.2 Diagrama ERD inițială a temei propuse

Figura 1.4 Înlocuirea asocierii M:N dintre CLIENT și ABONAMENT

1.5 MODELUL ENTITATE-ASOCIERE EXTINS

Figura 1.5 Exemplu de generalizare

1.6 MODELUL RELAȚIONAL

PROIECTAREA BAZELOR DE DATE

2.1 PROIECTAREA CONCEPTUALĂ A BAZEI DE DATE

Figura 2.1 Prima formă a diagramei Entitate-Asociere a temei date

2.1.2 Identificarea asocierilor dintre entități

Figura 2.2 A doua formă a diagramei Entitate-Asociere a temei date

2.1.3 Identificarea atributelor entităților și determinarea domeniilor atributelor

 Pentru entitatea ABONAMENT:

 Pentru entitatea CARTELĂ:

Figura 2.3 Entitățile și atributele bazei de date proiectate

Figura 2.4 Entitățile și atributele bazei de date proiectate după generalizare

Figura 2.5 A treia formă a diagramei Entitate-Asociere a temei date

Figura 2.6 Desființarea relațiilor M:N

Contracte_abonamente(număr_telefon, tip_abonament, cod_client, dată_semnare,

Abonamente(tip_abonament, cost, minute_rețea, minute_naționale, minute_roaming,

Contracte_cartele(număr_telefon, tip_cartelă, cod_client, data_achiziționare_cartelă,

2.2.1.3 Utilizarea normalizării

Figura 2.9 Formele normale ale unei relații

Figura 2.10 Relațiile bazei de date proiectate

Toate constângerile prezentate mai sus trebuie luate în considerare în momentul în

Figura 2.11 Relațiile bazei de date și legăturile dintre ele

2.3 PROIECTAREA FIZICĂ A BAZEI DE DATE

IMPLEMENTAREA FIZICĂ A MODELULUI

3.1 CREAREA TABELULOR

Figura 3.1 Instrucțiunea folosită pentru crearea tabelului CLIENȚI

Figura 3.2 Tabelul CLIENȚI a fost creat

Pentru relația CARTELE:

Figura 3.3 Tabelul CARTELE implementat

Figura 3.4 Tabelul ABONAMENTE implementat

Pentru relația CONTRACTE_ABONAMENTE:

Figura 3.6 Tabelul CONTRACTE_ABONAMENTE implementat

3.2 ADĂUGAREA CHEII PRIMARE ȘI A CHEII STRĂINE

Figura 3.7 Cheie primară tabel CLIENȚI

Pentru relația ABONAMENTE:

Figura 3.8 Cheie primară tabel ABONAMENTE

Figura 3.9 Cheie primară tabel CARTELE

Pentru relația CONTRACTE_ABONAMENTE:

ALTER TABLE contracte_abonamente

ALTER TABLE contracte_abonamente

Pentru relația CONTRACTE_CARTELE:

ALTER TABLE contracte_cartele

ALTER TABLE contracte_cartele

Figura 3.11 Cheie primară și chei străine tabel CONTRACTE_CARTELE

INSERT INTO cartele (tip_cartela, suma_disponibila_initial, minute_retea,

INSERT INTO cartele (tip_cartela, suma_disponibila_initial, minute_retea,

Figura 3.12 Tabelul CARTELE populat

Figura 3.13 Prima jumătate a tabelul CARTELE

INSERT INTO abonamente (tip_abonament, cost, minute_retea,

INSERT INTO abonamente (tip_abonament, cost, minute_retea,