Baze de Date pentru Telecomunicaț ii [602334]

1

Universitatea Politehnica București
Facultatea de Electronică, Telecomunicați și Tehnologia Informației

Proiect
Baze de Date pentru Telecomunicaț ii

Indrumător: Student: [anonimizat]: MSR

-2016 –

2
Cuprins
1. Introducere ………………………….. ………………………….. ………………………….. ……….. 3
1.1 Baze de date – definiție și informații generale ………………………….. ……………… 3
1.2 Clasificare bazelor de date ………………………….. ………………………….. ……………. 5
1.2.1 Bazele de date ierarhizate ………………………….. ………………………….. ……….. 5
1.2.2 Baze de date relaționale ………………………….. ………………………….. ………….. 5
2. Realizarea unei baze de date. Etape. Arhitectura ………………………….. ……………. 6
3. Terminologie ………………………….. ………………………….. ………………………….. …….. 7
3.1.Entitatea ………………………….. ………………………….. ………………………….. ………… 7
3.2.Atributul ………………………….. ………………………….. ………………………….. ………… 7
3.3.Relația ………………………….. ………………………….. ………………………….. …………… 9
3.4.Tabele ………………………….. ………………………….. ………………………….. ………….. 10
4. Realizarea bazei de date ………………………….. ………………………….. ………………… 11
5. Proiectarea bazei de date ………………………….. ………………………….. ………………. 13
5.1. Crearea unui tabel ………………………….. ………………………….. …………………….. 15
5.2. Modificarea structurii tabelelor ………………………….. ………………………….. …..19
5.3. Constrângeri ………………………….. ………………………….. ………………………….. …21
5.4. Secvențe și triggere ………………………….. ………………………….. ………………….. 26
5.5. Tipuri de chei ………………………….. ………………………….. ………………………….. .29
5.6. Tipuri de date folosite ………………………….. ………………………….. ……………….. 32
6. Popularea tabelelor ………………………….. ………………………….. ………………………. 32
7. Vederi ………………………….. ………………………….. ………………………….. …………….. 36
8. Concluzii ………………………….. ………………………….. ………………………….. ………… 44
9. Bibliografie ………………………….. ………………………….. ………………………….. …….. 45

3
1. Introducere
1.1 Baze de date – definiție și informații generale
Necesitatea stocă rii datelor a existat din totdeauna, zilnic stocam informatie folosind
dosare, biblioteci, sticky notes etc. Dezavantajul apare insa in momentul cand cantitatea de
informatie devine considerabila si gasirea unei anumite parti din ea devine cu adevarat
problematica. In era sistemelor de calcul acestea se pot ocupa in locul nostru atat de memorarea
datelor cat si de cautarea lor, insa acest lucru presupune structurarea informatiei pentru a putea fi
mai usor de gestionat.
In societatea moderna sistemele de ba ze de date sunt o componenta esentiala pentru buna
desfasurare a activitatilor noastre, multe persoane desfasoara uneori fara sa isi dea seama
activitati care presupun interactionarea cu o baza de date (extragere de bani, rezervare bilete
avion etc). O ba ză de date reprezintă o colecție de date între care există o legătură logică, se
adresează unui anumit grup de utilizatori și reflectă un aspect al lumii reale. Datele sunt coerente,
fără redundanță inutilă, pentru a putea fi prelucrate ef icient de mai mul ți utilizatori în același
timp. O bază de date permite următoarele operațiuni:
 crearea bazei de date ;
 introducerea a noi date („insert ”);
 ștergerea unor date („delete ”);
 actualizarea datelor („update ”);
 interogarea datelor („query ”).

Acestea se fac prin intermediul unui Sistem de Gestiune a Bazei de Date (SGBD) .Toate
operațiunile sunt tratate de catre SGBD.

În cadrul unei baze de date se pot evidenția următoarele componente:
 baza de date;
 sistemul de gestiune (gestionarea și prelucra rea bazelor de date);
 dicționar al bazei de date (informații despre date, structura lor, statistici etc);
 resurse fizice (servere, calculatoare etc);
 reguli administrative menite să ajute la desfășurarea corectă a activității cu baza
de date și impunerea u nor reguli etice de utilizare a acesteia;
 presonalul (utilizatori, administratori etc).

Softuri cunoscute de tip SGBD:
 Oracle – produs al Oracle Corporation, probabil cel mai cunoscut si folosit software
pentru gestionarea bazelor de date
 DB2 – produs al companiei IBM
 Microsoft SQL – produs de compania Microsoft pentru baze de date relationale
 Postgresql – software SGBD de tip open -source
 MySQL – software SGBD de tip open -source

Avantaje ale SGBD:
 Controlul redundanț ei datelor; nu se e limina in intregime redundanta, ci se controleaza

4
volumul inerent al acesteia in BD.
 Coerenta datelor; datorita eliminarii redundantei, orice reactualizare a unui articol (stocat
o singura data) se face o singura data, eliminandu -se incoerenta. Daca articolul este stocat
de mai multe ori, SGBD garanteaza coerenta tuturor exemplarelor din articolul respectiv.
 Mai multe informatii obtinute de la aceeasi cantitate de date; ca urmare a integrarii
datelor operationale, doua sau mai multe fisiere pot fi int egrate, extragandu -se mai multe
informatii.
 Partajarea datelor; fisierele sunt detinute de compartimentele organizatiei care le
utilizeaza, dar fiind parte din BD, ele sunt la dispozitia tuturor utilizatorilor interesati.
 Integritatea crescuta a datelor; s e refera la validitatea si coerenta datelor stocate.
Integritatea este exprimata prin constrangeri, care reprezinta reguli de coerenta pe care
BD nu are voie sa le încalce.
 Securitatea crescuta; se refera la protectia BD fata de utilizatorii neautorizati. Fara
sisteme de securitate, integrarea ar face datele foarte vulnerabile. Securitatea se realizeaza
prin nume de utilizatori plus parole. Se poate limita tipul de operatie efectuata.
 Aplicarea standardelor; prin integrare se pot aplica standarde organizati onale, nationale
sau internationale, ca de ex. formatul datelor, conventii referitoare la denumire, pt. a
facilita schimburi intre sisteme.
 Imbunatatirea accesibilitatii datelor si capacitatii de raspuns; limbajele de interogare si
generatoare de rapoarte asociate SGBD ofera utilizatorilor posibilitatea unor interogari
adhoc, fara a apela la programator.
 Productivitatea crescuta; SGBD furnizeaza standardele necesare aplicatiei, economisind
timpul programatorului.
 Concurenta/simultaneitatea imbunatatita; se garanteaza alterarea datelor in situatia cand
acelasi fisier este utilizat simultan de mai multi utilizatori.

Dezavantajele SGBD sunt:
 Complexitatea; pt. ca un SGBD sa fie functional, acesta va evolua intr – un sistem soft
extrem de complex. Functionalitat ea trebuie cunoscuta de catre toti cei implicati in BD,
de la DA la utilizatorul final, pentru a o putea exploata. Daca SGBD este gresit inteles,
BD proiectata poate fi gresita, cu toate consecintele acestei situatii.
 Dimensiunea; Fiind un element soft foarte complicat, SGBD ocupa mult spatiu pe disc si
necesita multa memorie pentru a functiona eficient.
 Costul SGBD; variaza in functie de mediu si functionalitate.
 Costurile aditionale pentru elemente hardware; pentru a sigura performantele SGBD
poate fi nevoie de achizitionarea unui calculator mai mare, chiar dedicat rularii SGBD, cu
disc si memorie mai mari.
 Costul conversiei; la implementarea unui nou sistem SGBD si/sau a unei noi configuratii
hard, conversia poate costa semnificativ mai mult decat noi le elemente hard. Se include
costul instruirii personalului, angajarea de personal specializat. Apare termenul de sistem
mostenit, adica un sistem mai vechi, inferior, de care organizatia se cramponeaza din
motive de costuri de conversie.
 Performanta; SGBD (spre deosebire de cel bazat pe fisiere) este general, creat pentru a
permite diverse aplicatii; astfel unele pot functiona mai putin rapid decat in cazul
sistemului bazat pe fisiere, creat pentru o anume aplicatie.

5
 Impactul crescut al unei defectiuni. Ce ntralizarea (partajarea) resurselor creste
vulnerabilitatea SGBD. Esecul oricarei componente poate duce la sistarea tuturor
operatiilor

Simple colecții de fișe (documente pe hârtie) sau fișiere de date care conțin date, dar nu
permit operații de intero gare nu sunt considerate baze de date. De exemplu, datele memorate în
fișiere pe disc într -o aplicație de calcul tabelar (Microsoft Excel) sau documentele memorate de
un editor de texte (ca Microsoft Word) nu sunt considerate baze de date.
Față de vechil e metode de înregistrare a datelor privind diferite activități pe fișe
(documente scrise) sau chiar în fișiere pe disc, sistemele de baze de date oferă avantaje
considerabile, ceea ce explică extinsa utilizare a acestora. Câteva dintre avantajele oferite s unt:
1. Controlul centralizat al datelor , putând fi desemnată o persoană ca responsabil cu
administrarea bazei de date
2. Viteză mare de regăsire și actualizare a informațiilor
3. Sunt compacte : volumul ocupat de sistemele de baze de date este mult mai redus decât
documetele scrise
4. Flexibilitatea ce constă în posibilitatea modificării structurii bazei de date fără a fi
necesară modificarea programelor de aplicație
5. Redundanță scăzută a datelor memorate, care se obține prin partajarea datelor între mai
mulți utilizatori și aplicații.

Pentru buna funcționare a bazei de date este recomandată menținerea unei redundanțe
minime, cât și a unor costuri necesare întreținerii și prel ucrării informației. De asemenea este
nevoie de asigurarea unui nivel de securitate al informației, de control asupra accesului și a
integrității datelor. Structura trebuie sa permită accesul rapid la date (răspuns mic la interogări)
și adaptarea la noi modificări.

1.2 Clasificare bazelor de date
Pornind de la structura lor, bazele de date pot fi clasificate în:
–baze de date ierarhizate
–baze de date relaționale.

1.2.1 Bazele de date ierarhizate
Bazele de date ierarhizate în mod tradițional au o structură arborescentă pentru reținerea
informației. Ele constau dintr -un fișier format din mai multe înregistrări, care la rândul lor sunt
constituite din numeroase câmpuri de date. Aceste baze de date su nt mai degrabă inflexibile și
folosesc mult spațiu întrucât datele sunt adesea repetitive.

1.2.2 Baze de date relaționale
Modelul relațional pentru bazele de date a fost conceput și dezvoltat de E.F. Codd. Este
un model formal de organizare conceptuală a datelor, destinat reprezentării legăturilor dintre
date, bazat pe teoria matematică a relațiilor. Fiind alcătuit numai din relații, orice interogare

6
asupra bazei de date este tot o relație. Acest model este simplu, riguros din punct de vedere
matematic, și nu este orientat spre sistemul de calcul.
Printre lim itările unui asemen ea model putem menționa existen ța unei redundanțe ,
apariția unor inconsistențe, inexistența unor mecanisme pentru tratarea optima a cererilor
recursive, faptul că nu se lucrează cu obiecte comple xe, inexistența unor mijloace p erfecțio nate
pentru exprimarea constrâng erilor de intregritate. De asemenea nu există o gesti une totală a
datelor distribuite.
O bază de date relațională este o bază de date formată dintr -o serie de tabele neordonate,
ce pot fi manipulate folosind operații non -procedurale care returnează tabele. Aceste baze de
date sunt percepute de utilizatori ca o colecție de tabele bidimensionale, în care fiecare linie
corespunde unui tuplu și fiecare coloană corespunde unui atribut.
Modelul relațional a fost propus de către IBM și a revoluționat reprezentarea datelor
făcând trecerea la generația a doua de baze de date. Modelul este simplu, are o solidă
fundamentare teoretică fiind bazat pe teoria seturilor (ansamblurilor) și pe logica matematică.
Pot fi reprezentate toate tipurile de structuri de date de mare complexitate, din diferite
domeniide ac tivitate. Modelul relațional este definit prin: structura de date, operatorii care
acționează asupra structurii și restricțiile de integritate.
Acest model, in care datele sunt stocate sub forma tabelara are o serie de avantaje care au
dus la inlaturarea celorlalte modele:
 Datele sunt stocate doar ca valori, nu exista pointeri sau navigare prin date
 Face posibila dezvoltarea de limbaje de cereri de nivel inalt in care utilizatorul specifica
ce date doreste si nu cum se ajunge la rezultat, modul in care este calculat acesta fiind in
sarcina sistemului de gestiune (exemplu de astfel de limbaj: SQL)
 Furnizeaza o baza solida pentru problemelor de corectitudine a datelor (redundanta,
anomalii, etc)
 Permite tratarea problemelor de independenta a datelor
 Este extensibil, putand fi utilizat si pentru modelarea si manipularea de date complexe

2. Realizarea unei baze de date. Etape. Arhitectura
O bază de date trebuie să țină cont de sistemul din lumea reală pe care îl modelează.
Astfel, înainte de crea rea acesteia, trebuie cunoscut exact scopul bazei de date, complexitatea și
mai ales d acă acel model poate fi modelat print r-o bază de date (mai exact dacă între elemente
există concept comune ce pot fi modelate). Există mai multe etape în procesul de realizar e a
unei baze de date:
 proiectarea conceptuală;
 proiectarea logică;
 proiectarea fizică.

Proiectarea conceptuală a bazei de date constă în construirea reprezentării
conceptuale a bazei de date, care include identificarea tipurilor importante de entități, relații,
atribute și prezintă următorii pași: identificarea tipurilor de entități (E), identificarea tipurilor de
relații (R), identificarea și asocierea atributelor (A) cu tipurile de E sau R, determinarea

7
domeniilor atributelor, determinarea atributelor chei candidat și chei primare, specializarea și
generalizarea tipurilor de entități.
Proiectarea logică reprezintă transpunerea reprezentării conceptuale în structura
logică a bazei de date, care include proiectarea relațiilor. Putem distinge următoarele etape:
 transpunerea modelului conceptual local în modelul de date logic local
(eliminarea relațiilor M: N prin înlocuirea cu relații de tip 1:M sau alte metode;
 eliminarea relațiilor complexe prin înlocuirea cu relații de tip 1:M;
 eliminarea relațiilor recursive prin înlocuirea cu relații dependente;
 eliminarea atributelor multiple prin înlocuirea cu relați i dependente;
 reexaminarea relațiilor 1:1, eliminarea relațiilor redundante);
 extragerea relațiilor din modelul de date logic local pentru a reprezenta entitățile
și relațiile, normalizarea relațiilor;
 validarea modelului conform tranzacțiilor utilizatorului pentru a garanta că acesta
acceptă și rezolvă operațiile cerute de către model, definirea constrângerilor de integritate.

Proiectarea fizică a bazei de date reprezintă implementarea fizică a struct urii logice
într-o capacitate de stocare secundară corespunzătoare SGBD -ului țintă .

3. Terminologie
3.1.Entitatea
Entitatea este un aspect al realității obiective, un conținut de sine stătător și este
caracterizată prin proprietățile sale, reprezentate de at ribute. Entitățile sunt semnificative pentru
ceea ce modelăm. Există câteva observații în ceea ce le privește: entitățile, în modelele
relaționale devin tabele; se scriu, în general, cu litere mari; sunt substantive, însă nu orice
substantiv este o entitat e. În cadrul aceleiași structuri nu pot exista două enități identice sau 2
entități cu același nume. În cazul de față, entitățile cele mai importante identificate în cadrul
bazei de date pentru telecomunicații sunt entitatea abonat și entitatea client prep ay.
Vom considera entități secundare tipurile de abonamente și tipurile de servicii.
Prin urmare vom avea 4 entități:
 abonați;
 clien ți prepay;
 tipuri de abonamente;
 tipuri de extraopțiuni.
3.2.Atributul
Atributele sunt proprietăți care descriu anumite aspecte ale unei entități sau ale unei
relații. Ele pot fi simple, compuse, cu valori multiple sau derivate. Se pot face câteva observații
cu privire la atribute:
 se face distincția între tipul atributului (care devine coloană în modelele
relaționale) și valoarea acestuia (care devine valoare în coloane);
 sunt substantive, dar nu orice substantiv este atribut;

8
 pentru fiecare atribut trebuie specificat numele, tipul fizic (integer, floar, char
etc.), valori p osibile, valori implicite, reguli de validare, tipuri compuse.
În cazul nostru, următoarele elemente sunt atribute:

Pentru entitatea ABONATI :
 nume;
 prenume;
 cod client;
 codul numeric personal;
 număr de telefon;
 tipul de abonament;
 costul lunar;
 dacă a bonatul a plătit sau nu;
 data de la care abonatul s -a alăturat rețelei.

Pentru entitatea PREPAY , ce va defini clien ții utilizatori de cartele preî ncărcate:
 număr de telefon;
 codul de client;
 tipul extraopțiunii;
 cost;
 suma disponibilă/credit;
 data la care s -a activat prima oară cartela.

Pentru entitatea TIP_ABONAMENTE :
 numele abonamentului;
 costul abonamentului;
 numărul de minute apeluri de voce/SMS -uri incluse în abonament;
 numărul de MMS -uri incluse în abonament;
 numărul de minute apeluri video inc luse în abonament;
 volumul de date transferate (în MB) inclus în abonament;
 numărul de minute apeluri de voce/trafic MB roaming;
 costul pentru minutele/SMS -urile suplimentare;
 costul pentru MMS -urile suplimentare;
 costul pentru minutele apeluri video supli mentare;
 costul pentru traficul de date suplimentar;
 costul pentru apelurile de voce/traficul MB în roaming.

Pentru entitatea TIP_EXTRAOPȚIUNI :
 numele extraopțiunii;
 costul extraopțiunii;
 numărul de minute apeluri de voce/SMS -uri incluse;
 numărul de MMS -uri incluse;

9
 numărul de minute videocall incluse în abonament;
 volumul de date transferate (în MB) inclus în abonament;
 numărul de minute apeluri de voce/trafic MB roaming.
Fiecare din entități sunt identificate unic printr -un atribut de identificare (ID).
3.3.Relația
O relație este o comunicare intre două sau mai multe entități. Existența unei relații este
subordonată existenței entităților pe care le leagă. Tipul unei relații este dat de numărul entităților
participante la relația respectivă.
În mod elul rela țional, relațiile devin tabele special sau coloane special care referă chei
primare. Acestea sunt verbe, însă nu orice verb este o relație. În aceeași diagramă pot exista
relații diferite cu același nume, caz în care le diferențiază entitățile car e sunt asociate prin relația
respectivă; pentru fiecare relație se stabilește cardinalitatea (maximă și minimă) relației, adică
numărul de tupluri ce aparțin relației. În funcție de acest număr de tupluri, relațiile pot fi de tip
1:1, 1:N sau N:N.
Între tabelele din baza noastră de date vor exista relații de tip 1:N. Astfel, între tabelele
TIP_ABONAMENTE și ABONATI vom avea o relație de tipul 1:N, întrucât un tip de
abonament poate fi asociat cu mai mulți abonați, însă un abonat poate avea un singur tip de
abonament. Legătura se va putea stabili prin intermediul atributului nume al
TIP_ABONAMENTE, ce se va regăsi în ABONATI în câmpul tip_abonament . De asemenea
între TIP_EXTRAOPȚIUNI și PREPAY se va stabili o relație de tipul 1:N, deoarece fiecare
client prepay poate avea o singură extraopțiune, însă o extraopțiune poate fi asignată mai multor
clienți prepay. Legătura se va putea stabili, de asemenea, prin intermediul atributului nume al
TIP_ABONAMENTE, ce se va regăsi în ABONATI în câmpul tip_extraopț iune.

1:N

1:N

Fig. 1 – Tipuri de rela ții Tip_abonament Abonați
Fiecare abonat poate avea un singur
tip de abonament, însă un abonament
poate fi asignat mai multor abonați

Tip_extraopțiune Prepay
Fiecare client prepay poate avea o
singură extraopțiune, însă o
extraopțiune poate fi asignată mai
multor clienți prepay

10
3.4.T abele
Tabelele reprezintă o entitate.Ele sunt formate din rânduri și coloane.Col oanele reprezintă
atributele fiecărei entități. În cadrul tabelelor poate apărea ambiguitatea. Acest lucru se poate
rezolva prin a asigura pe cât posibil unicitatea informațiilor. Acest lucru se obține prin utilizarea
unei chei primare unice pentru fiecare înregistrare.
Pentru a realiza baza de date pentru telecomunicații, am creat 4 tabele (Fig. 2).

ABONATI PREPAY

TIP_ABONAMENTE TIP_EXTRAOPTIUNI

Fig. 2 – Tabele

Fiecare element din tabele reprezintă un atribut prezentat în paragraful anterior.

ID
NUME
PRENUME
COD_CLIENT
CNP
NUMAR_TELEFON
TIP_ABONAMENT
COST
STARE_PLATI
VECHIME_IN_RETEA

ID
COD_CLIENT
NUMAR_TELEFON
TIP_EXTRAOPTUNE
COST
SUMA_DISPONIBILA
VECHIME_IN_RETEA

ID
NUME
MINUTE_SMS_INCLUSE
MMS_INCLUSE
MINUTE_VIDEOCALL_INCLUSE
MB_TRAFIC
MINUTE_MB_TRAFIC_ROAMING
COSTEXTRA_MINUTE_SMS
COSTEXTRA_MMS
COSTEXTRA_MINUTE_VIDEOCALL
COSTEXTRA_MB_TRAFIC
COSTEXTRA_MINUTE_MB_ROAMI
NG ID
NUME
MINUTE_SMS_INCLUSE
MMS_INCLUSE
MINUTE_VIDEOCALL_INCLUSE
MB_TRAFIC
MINUTE_MB_TRAFIC_ROAMING

11
4. Realizarea bazei de date

Ca mediu de dezvoltare în această lucra re vom folosi Oracle Database 11 g Express
Edition (Oracle Database XE). Utilizând Database Home Page, o interfață intuitivă de tip
browser pentru administ rarea bazei de date, putem crea tabele, obiecte, importa și exporta date,
interoga scripturi SQL, genera rapoarte.
Pentru a deschide pagina de administrare a bazei de date sunt necesari a se urma
următorii pași:
(1) Pornirea serverului prin accesarea Start> All Programs> Oracle Database 11 g
Express Edition> Start Database
(2) Accesarea ferestrei de administrare Start> All Programs> Oracle Database 11 g
Express Edition> Get Started
Fig. 3 –Pașii pentru deschiderea paginii de administrare a bazei de date

Se va deschide o fereastră, exemplificată în fig. 4, în care se completează user system și
parola dată la instalare:

12

Fig. 4 – Autentificarea la baza de date

Utilizatorul „system ” este cel introdus la instalarea programului și prin intermediul
acestuia pot fi creați și alți utilizatori. S-a creat un cont de administrator numit „Gombar Sabin ”.

Fig. 5a – Crearea unui utilizator

13

Fig. 5b – Crearea unui utilizator

5. Proiectarea bazei de date
Ideea acestor tabele pornește de la scopul principal al bazei de date: realizarea unei baze
de date pentru un operator de telecomunicații care sa conțină fiecare abonat în parte cu serviciile
de care beneficiază. Fiecare abonat trebuie să se identifice în vreun fel, indiferent dacă este
utilizator postpay sau prepay. Serviciile și tipurile de abonamente trebuie tratate similar.
Astfel, am construit tabelul ABONATI pentru a identifica fiecare abonat în parte. Acest
tabel va avea legatură cu tabelul TIP_ABONAMENTE, prin intermediul căruia se vor identifica
tipurile de servicii disponibile clientului. Pe de altă parte am construit tabelul PREPAY, ce va
identifica fiecare client al operatorului ce folosește o cartela prepay. Acest tabel va avea leg ătură
cu tabelul TIP_EXTRAOPTIUNI, prin intermediul căruia se vor identifica tipurile de servicii
disponibile clientului.
Fiecare linie din tabelul ABONATI se va identifica în mod unic prin atributul cnp. Astfel
va trebui să impunem acest lucru. De asemenea , dimensiunea câmpului trebuie validată (13

14
cifre). Numărul de telefon, atât în cazul ABONATI cât și în cazul PREPAY, trebuie sa fie de 11
cifre. La inserarea fiecărei linii se va incrementa c âmpul corespunzător atributului id pentru
fiecare tabel. În acest f el vom asigura unicitatea fiecărei linii, dar și o ordine a datelor și un
control asupra eventualelor ștergeri.
Dorim ca în final să putem vizualiza fiecare client în parte cu tipul de abonament și
serviciile disponibile. Astfel, va trebui sa creem legatu rile din figura 3. Acestea vor fi cre ate cu
ajutorul cheilor străine.

ABONATI TIP_ABONAMENTE

PREPAY TIP_EXTRAOPTIUNI

Fig. 6 – Structura bazei de date

Fiecare pas al creării bazei de date va fi prezentat în continuare.
ID
NUME
PRENUME
COD_CLIENT
CNP
NUMAR_TELEFON
TIP_ABONAMENT
COST
STARE_PLATI
VECHIME_IN_RETEA
ID
NUME
MINUTE_SMS_INCLUSE
MMS_INCLUSE
MINUTE_VIDEOCALL_INCLUSE
MB_TRAFIC
MINUTE_MB_TRAFIC_ROAMING
COSTEXTRA_MINUTE_SMS
COSTEXTRA_MMS
COSTEXTRA_MINUTE_VIDEOCALL
COSTEXTRA_MB_TRAFIC
COSTEXTRA_MINUTE_MB_ROAMING

ID
COD_CLIENT
NUMAR_TELEFON
TIP_EXTRAOPTUNE
COST
SUMA_DISPONIBILA
VECHIME_IN_RETEA
ID
NUME
MINUTE_SMS_INCLUSE
MMS_INCLUSE
MINUTE_VIDEOCALL_INCLUSE
MB_TRAFIC
MINUTE_MB_TRAFIC_ROAMING

15
5.1. Crearea unui tabel
Crearea unui tabel constă din generarea structurii sale, adică atribuirea unui nume
tabelului și definirea caracteristicilor sale (se definesc coloanele, se definesc constrângerile de
integritate, se specifică parametr ii de stocare e tc.). În Oracle 11 g tabelele pot fi create în orice
moment, chiar și în timpul utilizării bazei. Comanda CREATE TABLE permite crearea unui
tabel relațional sau a unui tabel obiect. Tabelul relațional reprezintă structura fundamentală
pentru stocarea datelo r utilizatorului. Un tabel obiect utilizează un tip obiect pentru definiția unei
singure coloane și este folosit pentru a stoca instanțele unui obiect particular. Sintaxa SQL a
acestei comenzi este următoarea:

CREATE TABLE [<nume_schemă>].<nume_tabelă>
( <nume_coloană_1><tip_date>[DEFAULT <expresie>] [NOT NULL],
<nume_coloană_2><tip_date>[DEFAULT <expresie>] [NOT NULL],
…
<nume_coloană_n><tip_date>[DEFAULT <expresie>] [NOT NULL])
[CLUSTER <nume_cluster> (<coloana_1>, …, <coloana_m>)]
[ENABLE | DISA BLE <clause>];
Un tabel poate fi creat in patru moduri:
– fară a indica cheile
– cu indicarea cheilor la nivelul fiecărei coloane
– cu indicarea cheilor la nivelul fiecărui tabel
– prin copierea din alt tabel

Am ales crearea fiecărui tabel prin indicarea ulterioară a cheilor primare, cu a jutorul
instrucțiunii ALTER TABLE . Structura acestei comenzi este:
ALTER TABLE [<nume_schemă>.]<nume_tabel>
[ADD (<nume_coloană><tip_date>, <constrângere>) |
MODIFY (<nume_coloană_1>, …, <nume_coloană_n>) |
DROP <clauză_drop>,]
[ENABLE | DISABLE <clause>];
În figurile de mai jos sunt prezentate comenzile sql pentru crearea tabelelor.

16
Fig. 7 – Crearea tabelului ABONATI
Fig. 8 – Crearea tabelului PREPAY

17
Fig. 9 – Crearea tabelului TIP_ABONAMENTE
Fig. 1 0 – Crearea tabelului TIP_EXTRAOPTIUNI

18
S-au creat cheile primare pentru fiecare tabel. În figurile de mai jos, este explicitat codul
sql pentru fiecare tabel.
Fig. 1 1 – Cheia primară pentru tabelul ABONATI: id
Fig. 1 2 – Cheia primară pentru tabelul PREPAY: id

19
Fig. 1 3 – Cheia primară pentru tabelul TIP_ABONAMENTE: id
Fig. 1 4 – Cheia primară pentru tabelul TIP_SERVICII: id
5.2. Modificarea structurii tabelelor
De multe ori, este necesar ă modificare a structurii tabelelor din diverse motive. Pot ap ărea
de exemplu necesit ăți de business importante care pentru a fi modelate necesit ă adaugarea sau
ștergerea unor anumite atribute în/din diverse tabele din baza de date. Trebuie precizat faptul că
adaugarea unor coloane nu afecteaza in niciun fel coloanele deja existente ale tabelei respective.
Toate valorile coloanelor din tabela vor r ămâne nemodificate. În momentul adaugarii unei noi

20
coloane / unui nou atribut, se va insera acel atribut pentru fiecare tuplu din tabe lă. Dac ă în
instruc țiunea folosi tă pentru ad ăugarea noii coloane / noului atribut se specific ăși o valoare
implicit ă pe care acest atribut o va lua, atunci toate tuplurile vor avea inserat ă acea valoare
pentru atributul respectiv. Dac ă nu se speci fică nicio valoare implicit ă, tabela va con ține noua
coloan ă / noul atribut, dar p ână la completarea explicit ă a acelui atribut pentru fiecare tuplu în
parte, atributul nu va con ține nicio valoare și va fi interpretat ca null.
Presupunem ca in tabela PREPA Y se insereaza un c âmp COST. Pentru a realiza acest
lucru se va folosi urm ătorea instruc țiune:
Fig. 1 5 – Inserarea unui câmp nou în tabela PREPAY

Stergerea unui atribut din tabela se face cu urmatoarea instructiune:

Fig. 1 6 – Ștergerea unui câmp din tabela PREPAY

21
5.3. Constrângeri

Așa cum am menționat în paragraful din secțiunea anterioară, vom impune anumite
constrângeri. Se observă că în declararea tabelelelor am impus ca unele câmpuri corespunzătoare
atributelor, să fie nenule. Astfel, în cazul în care la popularea cu date unul dintre aceste câmpuri
va fi nul, codul va întoarce un mesaj de eroare. Constrângerile se pot adăuga la declararea
tabelelor sau pe parcurs cu ajutorul sintaxei:
ALTER TABLE <nume_tabel>
ADD CONSTRAINT <nume_constrangere>< tip_constrangere(check/foreign
key/primary key/unique)> ( <constrangerea> )
Constrângerile se pot diferenția astfel:
– de domeniu, ce impun ca datele să corespundă realității
– de tuplu, legate de unicitate
– inter-relație, ce sunt modelate de cheile s trăine și asigura asocierea corectă a relațiilor
– intra-relație, ce se referă la o singură relație

Fig. 17 – Unicitatea CNP -ului

22

Fig. 18 – Dimensiunea CNP -ului

Mai jos, este prezentat codul sql pentru impunerea ca orice număr de telefon să aibă
exact 11 cifre. Astfel, se asigură valabilitatea informației.

Fig. 19 – Dimensiune nr. telefon abonați

23

Fig. 20 – Dimensiune nr. telefon prepay

Rezultatele modificărilor efectuate mai sus , pentru tabelul ABONAȚI, pot fi observate
în figurile 2 1, 22 și 23.

Fig. 21 – Vizualizarea modificărilor pentru tabelul ABONAȚI

24

Fig. 22 – Tabel ABONATI

Fig. 2 3 – Constrângeri tabel ABONATI

25
Anterior, s-au prezentat diferite noțiuni teoretice. Astfel, prin supercheie se întelege o
submul țime de atribute ale unei relații, cu proprietatea că orice combinație a valorilor atribut elor
este unică în acea relație, sau mai pe scurt, fiecare tuplu este identifi cat în mod unic de o
combinație a valorilor atributelor. În tabelul abonament, putem consid era că următo area
combinație a atribut elor “cod_client”, „num e”, „prenume” identifi că în m od unic un abonat. Am
definit astfel o constr ângere de unicita te pe tabelă.
Fig. 2 4 – Identificare unică a unui abonat

Fig. 2 5 – Condiție pentru cod client unic

26
Astfel, s-a impus condiția de unicita te pe coloana cod_client, datorită faptului că nu vor
exista două persoane cu același cod de client în tabelele abonati , respectiv prepay .
Tot în cadrul celor două tabele, o altă condiție de unicitate este introdusă pentru
numerele de telefon utilizate , întru cat oricare doi clienți vor av ea întotdeauna numere de telefon
diferite.

Fig. 26 – Condiție pentru număr de telefon unic

5.4. Secvențe și triggere
Pentru a simplifica modalitatea de introducere a înregistrărilor în baza de date, vom
utiliza conceptele de secvență și trigger (declanșator). Secvențele sunt practic niște contori și sunt
utilizate pentru a reține, de exemplu, un număr de ordine pentru in trările dintr -o tabelă. Sunt
obiecte din baza de date care servesc pentru generarea unor întregi unici în sistemele
multiutilizator, evitând apariția conflictelor și a blocării. Crearea unei secvențe se face cu
ajutorul comenzii:
CREATE SEQUENCE [<nume_sc hemă>.]<nume_secvență>
[INCREMENT BY n] [START WITH m]
[{MAXVALUE n | NOMAXVALUE}] [{MINVALUE n | NOMINVALUE}]
[{CACHE k | NOCACHE}];
CACHE k | NOCACHE specifică numărul de valori alocate de server -ul Oracle pe care
le va păstra în memoria cache pentru a oferi utilizatorilor un acces rapid (implicit sunt alocate 20
de valori). O secvență este referită într -o comandă cu ajutorul pseudo -coloanelor:
– NEXTVAL – referă valoarea următoare a secvenței;
– CURRVAL – referă valoarea curentă a secvenței.

27
Pentru baza noastră de date vom crea triggere pentru fiecare id al fiecărui tabel, începând
de la 1, impunând ca la fiecare inregistrare nouă, acesta să fie incrementat. Se poate seta și o
valoare maximă a secvenței, pentru a limita numărul de înregistrăr i.

Fig. 2 7 – Condiție pentru număr de telefon unic

Trigger -ele (sau declanșatoare) sunt proceduri care sunt stocate în baza de date și
asociate cu o tabelă, care pot fi apelate în momentul în care se execută anumite acțiuni
(evenimente) asupra acelei tabele (operații de inserare, ștergere sau actualizare a datelor), sau in
cazul apariției unor evenimente de sistem. Ele sunt folosite împreună cu secvențele pentru a
simplifica introducerea datelor în tabela cu care trigger -ul este asociat, astfel încât să nu mai fie
nevoie specificarea valorii pentru un câmp, de exemplu Id din acea tabelă. Sintaxa pentru
comanda de creare a unui trigger este următoarea:

CREATE TRIGGER [<nume_schemă>.]<nume_trigger>
{BEFORE | AFTER | INSTEAD OF} <eveniment>
ON [<nume_schemă>.]<nume_tabelă>
[WHEN (condiție)]
Bloc PL/SQL;

Pentru baza noastră de date s -au creat triggere pentru fiecare inserție de câmp nou.
Astfel, se va declanșa incrementarea din cadrul fiecărei secvențe, la inserarea de campuri noi.

28

Fig. 28 – Secvențele pentru atributul “id” al fiecărei tabele

Trigger -ele pot fi activate sau dezactivate oricând. Acest lucru nu este recomandat,
deoarece se pot pierde date importante despre ordinea în care s -au introdus datele în rețea.
Trigge -ele mai sunt utile deoarece, folosite cu secvențele, reprezint ă un registru al datelor
introduse sau șterse din baza de date. Putem activa sau dezactiva trigger -ele oricând, cu ajutorul
comenzii:

ALTER TRIGGER nume_trigger ENABLE | DISABLE;

29
Rezultatele modificărilor efectuate mai sus pot observate în figura 29:
Fig.29 – Trigger tabel ABONATI

5.5. Tipuri de chei
O cheie candidată este o coloană sau o combinație de coloane dintr -o tabelă care, prin
valorile sale identifică în mod unic o înregistrare din tabelă (un tuplu). Din aceste chei candidate
una singură trebuie aleasă pentru a fi cheie primară, pe când celela lte rămân chei alternative
(secundare). Pot exista chei simple sau compuse. O cheie simplă conține o singură coloană, în
timp ce o cheie compusă poate conține două sau mai multe coloane.
Pentru tabelele TIP_ABONAMENTE și TIP_EXTRAOPTIUNI există o singură cheie
candidată: Id. Astfel, câmpul nume nu poate fi cheie candidată deoarece ștergerea unui tip de
extraopțiune sau a unui tip de abonament, va duce la nevoia de a insera o altă înregistrare cu
același nume. Acest lucru este imposibil atunci când numele e ste unic (condiție impusă de
privilegiul de a fi cheie).
PREPAY are 2 chei candidate: id și cod_client, iar ABONATI, are mai multe chei
candidate: nume, cnp, id, cod_client.
Câmpurilor care sunt chei primare li se impune constrângerea de a nu accepta val ori
NULL, ele identificând în mod unic fiecare înregistrare din tabelă. Cheile primare ar trebui să
respecte următoarele principii:
– să fie unică și cunoscută la orice moment
– să fie controlată de administratorul bazei
– să nu conțină informații descriptive
– să fie simplă, fără ambiguități
– să fie stabile
– să fie familiară utilizatorului.

Pentru a respecta aceste principii, fiecare tabel are cheia primară Id. Aceste chei sunt chei
artificiale, deoarece au fost in troduse special în tabelă, fără a fi nevoie explicit de ele.

30
Cheile primare au fost adăugate cu ajutorul sintaxei:

ALTER TABLE <nume_tabel>
ADD CONSTRAINT <nume_constrangere>
PRIMARY KEY(id) -unde id este atributul căruia i s -a acordat cheia primară

Conceptul de cheie străină se referă la câmpuri care fac legătura dintre două tabele. Într –
una din tabele (numită și tabelă copil) există un câmp în care se află o valoare, care reprezintă de
fapt o cheie primară dintr -un alt tabel (tabelul părinte). Acest ea sunt folosite pentru a reprezenta
relațiile de tip 1:n, sau chiar pentru a reprezenta relații de tip n:n, în cazul în care nu se alege o
restrângere a relației n:n în două relații de tip 1:n prin adăugarea încă unei tabele.
În cazul nostru, pentru a re prezenta relația de tipul 1:N dintre tabela ABONATI și tabela
TIP_ABONAMENTE, s -a folosit o cheie străină. Similar pentru relația 1:N dintre PREPAY și
TIP_EXTRAOPTIUNI.

Fig. 30 – Unicitatea atrbutului “nume” pentru cele două tabele

În figurile de mai jos, sunt prezentate comenzile SQL pentru implementarea cheilor
străine.

Fig. 3 1 – Cheia străină ABONATI -> TIP_ABONAMENTE(nume)

31
Fig. 3 2 – Cheia străină PREPAY -> TIP_EXTRAOPTIUN I(nume)

În final, structura bazei de date va fi cea din figura 3 3. Ceea ce s -a dorit, a fost realizat,
însă în continuare dorim sa populăm și să afi șăm diferite interogări pe baza acestei structuri.
ABONATI TIP_ABONAMENTE

PREPAY TIP_EXTRAOPTIUNI

Fig. 3 3 – Structura bazei de date
ID
NUME
PRENUME
COD_CLIENT
CNP
NUMAR_TELEFON
TIP_ABONAMENT
COST
STARE_PLATI
VECHIME_IN_RETEA
ID
NUME
MINUTE_SMS_INCLUSE
MMS_INCLUSE
MINUTE_VIDEOCALL_INCLUSE
MB_TRAFIC
MINUTE_MB_TRAFIC_ROAMING
COSTEXTRA_MINUTE_SMS
COSTEXTRA_MMS
COSTEXTRA_MINUTE_VIDEOCALL
COSTEXTRA_MB_TRAFIC
COSTEXTRA_MINUTE_MB_ROAMING

ID
COD_CLIENT
NUMAR_TELEFON
TIP_EXTRAOPTUNE
SUMA_DISPONIBILA
VECHIME_IN_RETEA
NUME
PRENUME
ID
NUME
MINUTE_SMS_INCLUSE
MMS_INCLUSE
MINUTE_VIDEOCALL_INCLUSE
MB_TRAFIC
MINUTE_MB_TRAFIC_ROAMING

32
5.6. Tipuri de date folosite
În cadrul declarării tabelelor, s -au folosit următoarele tipuri de date:
– int : valoarea integer, pentru a define id al fiecărui tabel; tipul de date integer este
suficient pentru definirea index -ului întrucât reprezintă un număr întreg și ocupă memorie
minimă
– varchar2 : șir de caratere de dimensiune variabilă, de dimensiune maximă 4000 de
caractere (suficient)
– number: reprezintă un număr având precizia p și scara s. Precizia p poate lua valori
întregi între 1 și 38. Scara s poate varia între -84 și 127 și este tot un număr întreg. O valoare de
tip NUMBER necesită între 1 și 22 bytes în memorie. A fost folosit pentr u a exprima prețuri, cnp
și numerele de telefon. Din pricina definițiilor, nu s -a putut folosi int pentru aceste atribute
– DATE – reprezintă o dată calendaristică; datele valide se află în intervalul 1 Ianuarie
4712 î. Hr. și 31 Decembrie 9999, d. Hr. Fo rmatul implicit este dat explicit de către parametrul
NLS_DATE_FORMAT sau implicit de către parametrul NLS_TERRITORY . Dimensiunea în
memorie este fixată la 7 bytes. Acest tip de dată conține următoarele câmpuri specifice unor date:
anul, luna, ziua, ora mi nutul și secunda. Nu există sutimi de secundă sau fusuri orare.

6. Popularea tabelelor

Popularea bazei de date se face cu instrucțiunea INSERT. Sintaxa instrucțiunii este
următoarea:
INSERT INTO <nume_tabelă> / <nume_view>
[(<nume_coloana_1>, …,< nume_coloana_n>)
VALUES
(<expr_1>[,expr_2[, …]]) / subcerere;
Expr_1, expr_2, reprezintă expresii a căror evaluare este atribuită coloanelor precizate
(când se inserează o linie); subcerere reprezintă o interogare (când se inserează una sau mai
multe linii). Câteva observații privind utilizarea comenzii INSERT:
– este necesaracordul folosirii instrucțiunii INSERT
– în cazul în carelipsește specificația coloanelor, se consideră că sunt completate toate
câmpurile tabelului sau vizualizării;
– dacă nu a fost specificată lista coloanelor și dacă există câmpuri care nu au valori
efective, atunci valoarea NULL va fi atribuită acestor câmpuri;
– în situația în care se specifică acea cerere din comanda INSERT, vor fi copiate date
dintr -un tabel în altul pe atâtea linii câte au rezultat din cerere;
– dacă se introduc date doar în anumite coloane, atunci aceste coloane trebuie specificate.
În restul coloanelor se introduce automat NULL (dacă nu există DEFAULT sau un trigger care
să introducă date în acea colo ană);
– dacă se introduc numai anumite câmpuri într -o înregistrare, atunci printre acestea
trebuie să se găsească câmpurile cheii primare;
Pentru o inserare mai ușoară a datelor, vom folosi sintaxa:
INSERT ALL
INTO <nume_tabela> (<nume_coloana_1>, …, <nume_coloana_n>)
VALUES (<expr_1>[,expr_2[, …]]) ;

33

SELECT 1 FROM DUAL
Cu ajutorul INSERT ALL și al selecției SELECT 1 FROM DUAL putem insera date bulk
în baza noastră de date.
Vom popula mai intâi tabelele: TIP_ABONAMENTE și TIP_EXTRAOPTIUNI, pentru
a respecta restricțiile impuse de cheile străine. Fără aceste tabele, nu vor exista tipuri de
abonamente sau servicii, ceea ce va duce la erori întrucât referințele cheilor nu există. Al doilea
pas îl reprezintă popularea tabelelor ABONATI și PREPAY.
Fig. 3 4 – Popularea tabelului TIP_ABONAMENTE

Fig. 35 – Popularea tabelului TIP_EXTRAOPTIUNI

34
Fig. 36 – Popularea tabelului ABONATI
Fig. 37 – Popularea tabelului PREPAY
Fig. 38 a – select * from abonati

35
Fig. 38 b – select * from PREPAY

Fig. 38 c – select * from tip_abonamente

Fig. 38 d – select * from tip_EXTRAOPTIUNI

36
7. Vederi

Vederea (sau view) este un tabel logic (virtual) relativ la date din una sau mai multe
tabele sau vederi. Se definește ca cerere a limbaj ului de programare pentru a afișa/interoga date
moștenind caracteristicile obiectelor la care se face referire. Nu solicit alocare de memorie. O
vedere reflectă la orice moment conținutul exact al tabelelor de bază. Orice modificare efectuată
asupra tabele lor va avea efect instantaneu asupra vederii. Ștergerea unui tabel implică invalidarea
vederilor asociate tabelului și nu ștergerea acestora.
Motivele pentru care se folosesc vederile:
 furnizează un nivel mai înalt de securizare a bazei de date (informaț iei);
 simplitatea formulării unei cereri;
 afișarea datelor necesare;
 asigurarea independenței datelor;
 se asigura confidențialitatea unor date;
 definirea constrângerilor de integritate.

Vederile pot fi simple sau complexe. O vedere simplă extrage date dintr -un singur tabel și
nu conține funcții sau grupări de date. O vedere este considerată complexă dacă extrage date din
mai multe tabele, sau conține funcții sau grupări de date.
Crearea unei vederi se realizează cu ajutorul comenzii:
CREATE [OR REPLACE] [FORCE | NOFORCE] VIEW
[<nume_schemă>.]<nume_view> [(<alias>[,<alias>]…)]
AS <cerere_SELECT>
[WITH { CHECK OPTION [CONSTRAINT <nume_constrângere>] |
READ ONLY }]

– OR REPLACE poate înlocui vederea deja existentă
– FORCE creează vederea chiar dacă tabelul de bază nu există sau chiar dacă vederea
face referință la obiecte care încă nu sunt create. Deși vederea va fi creată, utilizatorul nu poate
să o folosească
– NO FORCE este implicită și se referă la faptul că vederea este creată numai dacă
tabelele de bază există
– SELECT se selectează coloanele
– WITH CHECK OPTION specifică faptul că reactualizarea datelor din tabele (inserare
sau modificare) se poate face numai asupra datelor selectate de vedere (care apar în clauza
WHERE)
– WITH READ ONLY asigură că nicio operație nu po ate fi executată asupra vederii ;
Unirea datelor reprezintă un pas important pentru scăderea redundanței datelor. Aceasta
poate fi facută prin mai multe metode. În vederile pe care le vom vizualiza în cadrul bazei
noastre de date, vom folosi operatorul UNION.

Uniri posibile în S QL:
 JOIN (compunere), care extrage tupluri din mai multe relații correlate;

37
 NATURAL JOIN (compunere naturală), care combină tupluri din două relații, cu
condiția ca atributele comune să aibă valori identice;
 SEMI -JOIN (semi -compunere), care selectează t upluri ce aparțin unei singure
relații, care sunt corelate cu tupluri din cea de -a doua relație;
 OUTER JOIN (compunere externă), care combină tupluri din două relații, astfel
încât condițiile de corelare să fie satisfăcute; tuplurile din orice relație car e nu satisfac aceste
condiții sunt completate cu valori null.
Pentru baza noastră de date vom crea șapte tipuri de vizualizări.
Prima, pentru vizualizarea clienților care utilizează trafic de roaming . Pentru acest tip de
vizualizare, am creat 2 secvente SQL, una care folosește atributele
MINUTE_MB_TRAFIC_ROAMING, TIP_ABONAMENT și NUME doar pentru tabela
ABONATI , și cea de -a doua folosește operatorul UNION pentru a uni 2 vizualizări din tabele
diferite .
Fig. 39 – View Roaming ABONATI

Fig. 40 – select * from ab_roaming

38
Fig. 4 1 – View Roaming ABONATI + PREPAY

Fig. 4 2 – select * from ab_roaming1

Această vedere afișează numerele de abonament respectiv cartelă ale utilizatorilor
pentru utilizatorii care au trafic de roaming inclus. Astfel am ales câmpurile numar_telefon,
data_abonarii și trafic_roaming care să fie și câmpurile vederii.
Operatorul U NION este cel cu ajutorul căruia se identifică părțile comune din cele 2
tabele.

39
În cea de -a doua vizualizare, dorim sa aflăm clienții care plătesc peste 6 euro pe lună
pentru un abonament. Astfel , am ales câmpurile numar_telefon, data_abonarii și cost, câmpurile
vederii.

Fig. 4 3 – View abonați cu cost abonament mai mare de 6 euro

Fig. 4 4 – select * from cost_ab

Cea de -a treia vedere va arăta vechimea clienților în rețea. Aceasta s -a realizat tot cu
operatorul UNION, întrucât dorim informații atât despre clientii abonați cât și depre cei cu
cartelă. S -a presupus referința sysdate care este data curentă. Se va extrage data_abonarii
respectiv data_activarii din fiecare tabel pentru a efectua diferența. Operatorul round() a fost
folosit pentru a rotunji diferența la numărul de zile.

40

Fig. 4 5 – View vechimea clienților în rețea

Fig. 4 6 – select * from vechime_retea

Următoarea vedere afișează numerele de telefon ale abonaț ilor cu o vechime mai mică de
5 ani:

41
Fig. 47 – view abonați vechime rețea sub 5 ani
Fig. 48 – select * from vechime_retea_sub5ani
În cea de -a cincea vizualizare, dorim sa aflăm clienții care au abonamentul „6EURO‟ .
Astfel , am ales câmpurile numar_telefon și data_abonarii , câmpurile vederii:

Fig. 49 – view clienți abonament „6EURO‟

42

Fig. 50 – select * from view_abonament6euro
În cea de -a șasea vizualizare, dorim sa aflăm clienții care au abonamentul facturile
plătite la zi . Astfel , am ales câmpurile nume, prenume, numar_telefon șitipul abonamentului ,
câmpurile vederii:

Fig. 51 – view clienti cu plata la zi

Fig. 52 – select * from view_factura_zi

43
În cea de -a șaptea vizualizare, dorim sa aflăm clienții prepay care au un credit mai mare
de 2 euro . Astfel , am ales câmpurile numar_telefon și tipul extraopțiunii , câmpurile vederii:

Fig. 56 – view clienți prepay cu credit mai mare de 2 euro

Fig. 57 – select * from credit_mai_mare_de_2euro

44
8. Concluzii

Calculatoarele personale au apărut din necesitatea stocării și prelucrării cât mai rapide a
informațiilor. Evoluția tehnicii de calcul a dus la o creștere substanțială a capacității de
memorare și a vitezei de prelucrare a datelor.
Sistemele de gestiune a bazelor de date reprezintă sisteme informatice specializate în
stocarea și prelucrarea unui volum mare de date .
Organizarea datelor ocupă un loc important în proiectarea sistemelor informatice, de
aceasta depinzând eficiența sistemului informatic.
Astfel au apărut bazele de date care au oferit multe avantaje în organizarea și prelucrarea
diferitelor date, avantaje precum :
 controlul centralizat al d atelor
 viteză mare de regăsire și actualizare a informațiilor
 sunt compa cte
 flexibilitatea
 redund anță scăzută a datelor memo rate
 posibi litatea introducerii stand ardelor privind modul de stoc are a datelor
 menține rea integrității datelor
 indep endența datelor față de suportul ha rdware utilizat.

Acest proiect a contribuit la înțelegerea etapeleor necesare elaborării și
implementării unei baze de date, a ceea ce reprezintă și ce presupune aceasta, i mportanța
unei baze de date, totalitatea compo nentelor un ei baze de date și model ele pe baza cărora se
proiectează. Prin intermediul limbajului de programare SQL, s-au realizat două tabele pentru
un operator de telefonie mobilă, una pentru clienții abonați și una p entru cei prepay. Prin
intermediul acestor tabele, s-au putut realiza diferite operații precum inse rarea clienților, crearea
de v ederi, unirea tabelelor, prin intermediul cărora s-au putut sublin ia avantajele oferite de
utilizarea bazelor de date.

45
9. Bibliografie

• Cursuri “ Baze de Date pentru Telecomunicatii “ , 2011
• Laboratoare “ Baze de Date pentru Telecomunicatii “ , 2011
• Ryan K. Stephens , Ronald Plew , Bryan Morgan , Jeff Perkins – “ Teach Yourself
SQL in 21 Days, Second Edition “ , Sams Publishing , 2004
• http://ro.wikipedia.org/wiki/Baz%C4%83_de_date
• http://www.dba -oracle.com/
• http://www.mytecbits.com/microsoft/sql -server/
• http://www.techonthenet.com/oracle/errors/