PROIECT DE CERCETARE ŞI DOCUMENTARE

BAZE DE DATE PENTRU TELECOMUNICAŢII

Student: Popescu Victoria-Andreea

MASTER RITc anul II
2014

1
Contents
Intorducere .............................................................................................................................................................. 4
Capitolul 1. Bază de date. Noţiuni Teoretice .......................................................................................................... 5
1.1 Definiţie Bază de Date .................................................................................................................................. 5
1.2 Arhitectura unei baze de date ........................................................................................................................ 5
1.3 Sistemul de gestiune al bazei de date ............................................................................................................ 6
1.3.1 Componentele unui sistem de baze de date ........................................................................................... 6
1.3.2 Exemple de SGBD ................................................................................................................................. 7
1.4 Modele de date .............................................................................................................................................. 7
1.5 Bază de Date Relaţională. Definiţie. ............................................................................................................. 8
1.6 Proiectarea unei Baze de Date ...................................................................................................................... 8
Capitolul 2 Proiectarea Bazei de Date................................................................................................................... 10
2.1 Etapa I. Colectarea şi analiza cerinţelor. ..................................................................................................... 10
2.2 Etapa a II-a. Proiectarea conceptuală a bazei de date.................................................................................. 11
2.2.1 Descrierea cerinţelor utilizatorului. ...................................................................................................... 11
2.2.2. Aspecte teoretice. ................................................................................................................................ 13
2.3. Etapa a III-a. Proiectarea logică a Bazei de Date ....................................................................................... 29
2.4. Etapa a IV-a. Alegerea SGBD-ului ............................................................................................................ 30
Capitolul 3. Implementarea fizică a bazei de date................................................................................................ 31
3.1. Crearea Administratorului şi Utilizatorilor ................................................................................................ 31
3.2. Crearea tabelelor ........................................................................................................................................ 33
3.2.1 Crearea tabelului Abonaţi..................................................................................................................... 34
3.2.2. Crearea tabelului DateDeContact ........................................................................................................ 36
3.2.3. Crearea tabelului Contracte ................................................................................................................. 37
3.2.4. Crearea tabelului Facturi ..................................................................................................................... 38
3.2.5. Crearea tabelului Abonamente ............................................................................................................ 39
3.2.6. Crearea tabelului Tarife ....................................................................................................................... 40
3.2.7. Crearea tabelului NumereTelefon ....................................................................................................... 41
3.2.8. Crearea tabelului Servicii .................................................................................................................... 42
3.2.9. Crearea tabelului CartelePrepay .......................................................................................................... 43
3.3. Introducerea constrângerilor Foreign Key (Cheie Străină) ........................................................................ 44
3.3.1. Introducerea cheii străine IdAbonat în tabelul DateDeContact ........................................................... 44
3.3.2. Introducerea cheilor străine IdAbonat, NumarTelefon în tabelul Contracte ...................................... 44
2
 3.3.3. Introducerea cheii străine IdAbonat în tabelul Facturi ........................................................................ 45
3.3.4. Introducerea cheilor străine IdServiciu, IdTarif în tabelul Abonamente ............................................ 46
3.3.5. Introducerea cheilor străine IdAbonat, IdAbonament şi IdPrepay în tabelul NumereTelefon. ......... 46
3.3.6. Introducerea cheii străine IdServiciu în tabelul CartelePrepay ........................................................... 48
3.4. Introducerea datelor în tabele .................................................................................................................... 48
3.4.1. Introducerea datelor în tabela Abonaţi ................................................................................................ 48
3.4.2. Introducerea datelor în tabela Servicii................................................................................................. 50
3.4.3. Introducerea datelor în tabela Tarife ................................................................................................... 51
3.4.4. Introducerea datelor în tabela DateDeContact .................................................................................... 52
3.4.5. Introducerea datelor în tabela Facturi .................................................................................................. 54
3.4.6. Introducerea datelor în tabela Abonamente......................................................................................... 55
3.4.7. Introducerea datelor în tabela CartelePrepay ...................................................................................... 57
3.4.8. Introducerea datelor în tabela NumereTelefon .................................................................................... 58
3.4.9 Introducerea datelor în tabela Contracte .............................................................................................. 59
3.5. Crearea vederilor ........................................................................................................................................ 60
3.5.1. Crearea vederii cu clieţii în Roaming .................................................................................................. 62
3.5.2. Crearea vederii cu clienţii care plătesc peste o anumită sumă. ........................................................... 64
Concluzii ............................................................................................................................................................... 69
Bilbliografie .......................................................................................................................................................... 70

3
Intorducere

În prezent bazele de date prezintă o largă răspândire, fiind necesare în aproape toate domeniile de
activitate actuale. Baza de date reprezintă acum cadrul fundamental al unui sistem informaţional şi a modificat
radical modul de operare al multor organizaţii. În particular, dezvoltarea acestei tehnologii de-a lungul ultimilor
ani a dus la crearea unor sisteme mai puternice, ce pot fi utilizate într-un mod mai intuitiv. Rezultatul a fost că
sistemele de baze de date au devenit din ce în ce mai accesibile pentru o mai largă varietate de utilizatori.
Dimensiunea acestora poate varia de la câteva zeci de înregistrări la câteva zeci de milioane (spre exemplu baze
de date care ţin evidenţa populaţiei ). Prin urmare sunt necesare mecansime şi metode de stocare a unor blocuri
masive de date cât şi de acces rapid la acestea.

Un sistem de baze de date este în principiu un sistem computerizat de păstrare a evidenţelor. Iar baza de
date este cea care înglobează aceste evidenţe şi le stochează într-o colecţie de date. Utilizatorii unui sistem de
baze de date pot efectua o serie de operaţii asupra acestor date. Printre ele se numără: adăugarea de date noi în
baza de date (insert), actualizarea datelor memorate (update), ştergerea unora din datele existente (delete),
interogarea bazei de date (query).

Caracteristica principală a aplicaţiilor de baze de date constă în faptul că accentul este pus pe operaţiile
de memorare şi regăsire , efectuate asupra unor volume mari de date, şi mai puţin asupra operaţiilor de
prelucrare a acestora asa cum este cazul în alte domenii de aplicare a informaticii.

Lucrarea prezentă se doreşte a fi o introducere în domeniul bazelor de date, prin care se evidenţiază
conceptul teoretic al unei baze de date şi paşii necesari în proiectarea şi crearea propriu-zisă a acesteia. Totodată,
fundamentul teoretic va fi susţinut de o parte aplicativă realizată în mediul Oracle Database 10g Express
Edition. Această parte constituie un exemplu practic de dezvoltare a unei baze de date destinate unei companii
de telecomunicaţii mobile. Pornind de la cerinţele utilizatorului, se va prezenta pas cu pas metodologia de
proiectare a bazei de date dorite şi se vor introduce noţiunile necesare conceperii si dezvoltării acesteia.

4
Capitolul 1. Bază de date. Noţiuni Teoretice

1.1 Definiţie Bază de Date

O bază de date reprezintă o colecţie logică coerentă de date, creată şi menţinută computerizat, în scopul
prelucrării datelor în contextul unui set de aplicaţii.

Simpla memorare a datelor în fişiere pe disc sau în colecţii de fişe nu va fi suficientă pentru ca acestea
să fie considerate baze de date, deoarece pe lângă stocare, o bază de date permite operaţii de interogare
complexe, care selectează anumite informaţii după un criteriu ales. De exemplu datele stocate într-un fişier de
tipul Microsoft Excel ce foloseşte principii asemănătoare cu cele ale bazelor de date relaţionale , fiind o aplicaţie
de calcul tabelar, nu vor fi considerate ca făcând parte din o bază de date, deoarece Excel nu permite operaţii de
query.

Faţă de vechile 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 sunt:

• Controlul centralizat al datelor, putând fi desemnată o persoană ca responsabil cu administrarea bazei de

date.
• Viteză mare de regăsire şi actualizare a informaţiilor.
• Sunt compacte: volumul ocupat de sistemele de baze de date este mult mai redus decât documetele
scrise.
• Flexibilitatea: ce constă în posibilitatea modificării structurii bazei de date fără a fi necesară
modificarea programelor de aplicaţie.
• Redundanţă scăzută a datelor memorate, care se obţine prin partajarea datelor între mai mulţi utilizatori
şi aplicaţii. În sistemele de baze de date, mai multe aplicaţii pot folosi date comune, memorate o
singură dată.
• Menţinerea integrităţii datelor prin politica de securitate (drepturi de acces diferenţiate în funcţie de
rolul utilizatorilor).
• Independenţa datelor faţă de suportul hardware utilizat. Sistemul de gestiunea a bazelor de date oferă o
vizualizare a datelor, care nu se modifică atunci când se schimbă suportul de memorare fizic, ceea ce
asigură imunitatea structurii bazei de date şi a aplicaţiilor la modificări ale sistemului hardware
utilizat.

1.2 Arhitectura unei baze de date

Asigurarea independenţei fizice şi logice a datelor impune adoptarea unei arhitecturi de baze de date
organizate pe cel puţin trei nivele:

- nivelul intern: colecţie de fişiere conţinând datele fizice, la care se adaugă diverse structuri auxiliare
menite să asigure accesul la date. Structurile auxiliare pot fi: directoare, indecsi, pointeri etc. Baza de date fizică
este rezidentă în memoria secundară a calculatorului, în general pe harddisk.

5
- nivelul conceptual: abstractizare a unei parţi din lumea reală ce constă în descrierea structurii logice a
datelor dintr-o bază de date, integrând viziunile tuturor utilizatorilor asupra acesteia.

- nivelul extern: corespunde viziunii unui utilizator sau a unui grup de utilizatori. Este modelul cel mai
apropiat de utilizator, fiind derivat din modelul conceptual, dar poate prezenta deosebiri substanţiale faţă de
acesta. Termenul tehnic adesea folosit pentru modelul extern este acela de vedere. Vederile au mai multe
utilizări în cadrul bazelor de date, cum ar fi asigurarea securităţii bazei de date, prin limitarea accesului la date a
anumitor categorii de utilizatori.

1.3 Sistemul de gestiune al bazei de date

Un sistem de gestiune al bazei de date (SGBD) reprezintă un ansamblu de componente software care
asigură crearea, utilizarea şi întreţinerea uneia sau mai multor baze de date. Un SGBD cuprinde:

 un subsistem de memorare care inregistrează şi regăseşte datele din fişiere.

 un subsistem de modelare şi manipulare a datelor care conţine procedurile de organizare a datelor şi
de operare asupra lor (adăugare, modificare, ştergere) şi de control la partajarea datelor şi access
concurent (tranzacţii multi-user).
 interfaţa dintre SGBD şi utilizatori.

SGBD-ul cuprinde două facilităţi importante pentru proiectarea şi exploatarea bazelor de date:

- facilităţi de descriere a datelor: prin limbajul de definire al datelor LDD (Data Definition Languages -
DDL), care serveşte pentru descrierea modelelor externe, al modelului conceptual şi a inerfeţelor dintre cele trei
nivele de organizare a bazei de date.

- facilităţi de manipulare a datelor: prin limbajele de manipulare a datelor – LMD (Data Manipulation
Languages–DML) , acestea constituind interfaţa dintre SGBD şi utilizatori. Limbajul de manipulare a datelor
constă dintr-un set de comenzi care corespund operatiilor de exploatare a bazei de date (precum formularea
cererilor de acces la date (interogări), adăugarea, ştergerea şi actualizarea datelor).

1.3.1 Componentele unui sistem de baze de date

Componentele unui sistem de baze de date sunt: hardware, software, utilizatori, date persistente.

1.3.1.1 Hardware
Calculatoarele pe care sunt instalate de obicei sistemele de baze de date sunt PC standard, dar şi
calculatoare multiprocesor foarte puternice. Cea mai importantă caracteristică a calculatorului pe care
funcţionează sistemul de baze de date este capacitatea harddisk-ului, utilizat pentru memorarea datelor din baza
de date.

1.3.1.2 Software
 Sisteme de operare, biblioteci, instrumente de dezvoltare, interfeţe.
 Sistemul de Gestiune a Bazelor de Date(SGBD) (Database Management System –DBMS) -
recepţionează cererile utilizatorilor de acces la baza de date, le interpretează, execută operaţiile
corespunzătoare şi returnează rezultatul.
 Aplicaţii de baze de date: (Database Applications)–sunt programe care oferă anumite utilizări ale
unei baze de date.
6
1.3.1.3 Utilizatorii
Utilizatorii unui sistem de baze de date se împart în câteva categorii:

 Programatorii de aplicaţii sunt cei care dezvoltă aplicaţiile de baze de date în anumite medii de
programare.
 Utilizatorii obişnuiţi sunt acei utilizatori care accesează baza de date prin intermediul unei aplicaţii
de baze de date. Aceşti utilizatori au drepturi limitate asupra accesului la datele din baza de date, ei
neavând cunoştinţe aprofundate asupra structurii şi a datelor din acea bază de date.
 Administratorul bazei de date (DataBase Administrator) care este o persoană autorizată, care are ca
sarcină administrarea resurselor, autorizarea accesului la baza de date, a coordonării şi monitorizării
utilizatorilor acelei baze de date.

1.3.1.4 Date persistente

Datele memorate într-o bază de date sunt date persistente, adică date care rămân memorate pe suport
magnetic, independent de execuţia programelor de aplicaţii. Datele persistente ale unei baze de date se
introduc, se şterg sau se actualizează în funcţie de date de intrare provenite de la tastatură. Iniţial datele de
intare sunt date nepersistente, ele devenind persistente după ce au fost validate de SGBD. Datele de ieşire ale
unui sistem de baze de date sunt tot date nepersistenete, ele provenind din operaţii de interogare a bazei de date
şi puse la dispoziţie utilizatorului sunt formă de raport, afişare etc.

1.3.2 Exemple de SGBD

În momentul de faţă, pe piaţă există o ofertă foarte mare de sisteme de gestiune a bazelor de date, de la
sisteme care se pot folosi gratuit (fără licenţă sau cu licenţă publică), până la sisteme de înaltă performanţă, a
căror utilizare necesită cumpărarea de licenţe.

Microsoft SQL Server este sistemul de gestiune a bazelor de date relaţionale multi-utilizator dezvoltat
de firma Microsoft pentru sistemele de operare Windows.

Microsoft Access este unul din cele mai cunoscute sisteme de gestiune a bazelor de date relaţionale pe
platforme de calculatoare personale.

Sistemul Oracle este un sistem de gestiune al bazelor de date multi-utilizator foarte puternic, cu
implementări pe toate platformele (Windows, Linux, Unix), care oferă atât performanţe de execuţie ridicate, cât
şi un grad mare de protecţie şi securitate a datelor.

MySQL este un sistem de gestiune a bazelor de date relaţionale cu implementări pentru sistemele de
operare Linux, Unix, Windows. Acest sistem se poate utiliza gratuit, fiind open source.

Visual FOX PRO este un limbaj de programare complet, care acceptă un mediu interactiv şi un mediu
compilat la rulare.

IBM DB2 este un sistem de gestiune al bazelor de date al firmei IBM. Acest sistem asigură integritatea
datelor, oferă o securitate sporită pentru date, are o interfaţă grafică pentru gestionarea bazei de date.

1.4 Modele de date

Un model de date stabileşte regulile de organizare şi interpretare a unei colecţii de date.

În proiectarea bazelor de date se folosesc două categorii de modele:

7
 • Modele conceptualede nivel înalt(modelul Entitate-Asociere, modelul Entitate-Asociere Extins)–
descriu concis colectiile de date care modelează activitatea dorită fără să detalieze modul de
reprezentare sau de prelucrare a datelor.
• Modele specializate (modelul ierarhic, modelul reţea, modelul relaţional, modelul obiect-orientat,
modelul obiect-relaţional) -descriu reprezentarea mulţimilor de entităţi şi a asocierilor dintre acestea
prin structuri de date specifice.

1.5 Bază de Date Relaţională. Definiţie.

O bază de date relaţională este o bază de date care respectă modelul relaţional. Modelul de date relaţional
(Relational Model) se bazează pe noţiunea de relaţie din matematică, care corespunde unei entităţi de acelaşi tip
şi are o reprezentare uşor de înţeles şi de manipulat, ce constă dintr-un tabel bidimensional, compus din linii şi
coloane. Fiecare linie din tabel reprezintă o entitate şi este compusă din mulţimea valorilor atributelor entităţii
respective, fiecare atribut corespunzând unei coloane a tabelului.

O bază de date relaţională este compusă dintr-o mulţime finită de relaţii

• fiecare relaţie reprezintă o mulţime (tip) de entităţi sau o mulţime (tip) de asocieri
• fiecare relaţie este unică într-o bază de date
 relaţia se defineşte prin intermediul atributelor sale

Atributele unei relaţii corespund atributelor tipului de entitate sau de asociere pe care îl reprezintă relaţia
respectivă.

 fiecare atribut are un nume (Ai) şi un domeniu de definiţie D(Ai)

 pentru o entitate dată, un atribut poate lua o singură valoare

Un exemplu potrivit pentru a ilustra aceste concepte teoretice ar fi tipul de entitate „Abonat” (al unei
companii de telecomunicaţii) ce reprezintă orice persoană care a încheiat un contract cu compania de
telecomunicaţii pentru un anumit abonament si care beneficiază de serviciile oferite de companie pe baza acelui
contract. Din acest exemplu se mai poate deduce existenţa a cel puţin două tipuri de entităţi relevante pentru o
astfel de bază de date: tipul de date „Abonamente” şi tipul de date „Servicii” precum şi ideea de asociere între
acestea: asocierea dintre Abonat şi Abonamente şi asocierea dintre Abonamente şi Servicii.

Revenind la relaţia Abonat, aceasta poate fi descrisă prin mai multe atribute, dintre care o parte pot fi
folosite pentru identificarea persoanei precum: Nume, Prenume, CNP, Adresa etc. iar altele pot corespunde
asocierii acestuia cu compania respectivă precum Tip Abonament, Numar Contract etc.

O bază de date relaţională este în esenţă o muţime de tabele legate între ele prin diverse asocieri. În cazul
expus în exemplul nostru, baza de date referită ar putea avea în componenţa sa tabelele Abonat, Abonamente,
Servicii .

1.6 Proiectarea unei Baze de Date

Proiectarea unei baze de date constă din proiectarea logică şi fizică a acesteia, pentru a corespunde cerinţelor
utilizatorilor pentru un anumit set de aplicaţii.

În general, vom considera că proiectarea corectă a unei baze de date trebuie să parcurgă următoarele etape:

 Colectarea şi analiza cerinţelor

 Proiectarea bazelor de date
8
  Proiectarea conceptuală a bazelor de date
 Alegerea unui SGBD
 Proiectarea logică a bazelor de date
 Proiectarea fizică a bazelor de date
 Implementarea bazelor de date

Înainte de a se proiecta efectiv o bază de date (in cadrul unui sistem informatic – sistem de baze de
date), este necesar să se cunoască:

1. ce rezultate se aşteaptă utilizatorii potenţiali să obţină de la baza de date respectivă

2. ce informaţii primare sunt disponibile pentru acestea
3. ce aplicaţii se vor executa (aplicaţii de gestiune a plăţilor, aplicaţii contabile, aplicaţii de urmărire a
consumurilor, aplicaţii de salarizare, etc.).

Toate acestea sunt informaţii slab structurate, în general în limbaj natural. Din aceste informaţii trebuie să
fie extrase date precise de proiectare a bazelor de date şi a aplicaţiilor. Deşi este o fază puternic consumatoare de
timp, această etapă este deosebit de importantă. Implementarea bazei de date trebuie să se facă în conformitate
cu cerinţele utilizatorilor. De regulă cel care concepe şi crează baza de date nu este şi acela care o va utiliza în
final. Prin urmare, aceasta ar putea fi respinsă de eventualii utilizatori dacă cerinţele nu au fost satisfacute
corespunzător.

Având cerinţele formulate precis şi concis se poate trece la elaborarea schemei conceptuale utilizând un
model de nivel înalt. Schema conceptuală reprezintă o descriere concisă a datelor utilizatorului, incluzând
descrierea detaliată a tipurilor de date, a relaţiilor şi restricţiilor acestora.

Alegerea unui SGBD se bazează pe factori de tip tehnici, economici şi administrativi. Factorii tehnici se
referă în special la modelul de date folosit, capacitatea de stocare a datelor, configuraţia hardware-software
necesară etc. Factorii economici şi administrativi sunt de regulă costul de achiziţie a software-ului, costul de
întreţinere şi costul de pregătire a personalului.

Pentru proiectarea logică a bazei de date se porneşte de la schema coneceptuală şi se realizează schema
logică (diagrama logică) şi schemele (vederile) externe pentru sistemul SGBD ales. În mod frecvent, etapele de
proiectare conceptuală şi proiectarelogică se efectuează împreună, proiectând schema (diagrama) logică a bazei
de date cu ajutorul toolset-urilor de dezvoltare oferite de SGBD-ul utilizat.

În faza de proiectare fizică a bezelor de date se creează obiectele principale ale bazei de date (tabele, vederi,
indexuri), pe baza proiectului logic, folosind limbajul de descriere a datelor (LDD) oferit de sistemul SGBD
ales, sau toolset-uri grafice (de ex. table editor) sau prin executia scriptului generat de un toolset de proiectare.

9
Capitolul 2 Proiectarea Bazei de Date

În acestă lucrare vom exemplifica procedura de proiectare a unei baze de date destinată unei companii de
telecomunicaţii mobile. Vom parcurge fiecare etapă de proiectare în care vom detalia şi exemplifica aspectele
necesare construcţiei bazei de date propuse. Pe parcurs, vor mai fi evidenţiate anumite aspecte teoretice pentru o
mai bună înţelegere. Trebuie menţionat faptul că, lucrarea prezentă este pur didactică, şi are scopul de a pune în
practică partea teoretică în scopuri educative. Prin urmare conceptul bazei de date din cadrul acestui proiect va fi
mult simplificat. Baza de date prezentată aici nu se va putea compara cu o baza de date destinată în realitate unei
companii de telecomunicaţii mobile, ce poate avea milioane de înregistrări. Totodată, aş dori să atrag atenţia
asupra faptului că SGBD-ul ales este Sistemul Oracle, aplicaţia de gestiune a bazei de date fiind Oracle
Database 10g Express Edition. Un alt aspect important este acela că proiectarea conceptuală a bazei de date şi
proiectarea logică a acesteia se vor realiza într-o singură etapă.

2.1 Etapa I. Colectarea şi analiza cerinţelor.

Se doreşte crearea unei baze de date pentru un operator de telecomunicaţii mobile.

Aşteptările potenţialilor utilizatori cu privire la baza de date sunt acelea de a avea acces rapid la informaţii
caracteristice abonaţilor respectiv clienţilor prepay. Spre exemplu se doreşte crearea de 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 etc.

Informaţiile primare oferite de clienţi sunt următorele:

 Baza de date va fi orientata spre doua structuri de date principale. Una pune în evidenţă abonaţii.
Cea de-a doua se referă la cartelele prepay respectiv clienţii prepay din cadrul companiei.
 Structura pentru abonaţi va conţine numele, codul clientului, număr telefon, tipul de abonament,
servicii oferite (voce, sms, mms, video call, internet, roaming), cost, stare plati (la zi sau restanţier),
vechime în reţea.
 Structura pentru clienţi prepay va conţine număr telefon, servicii oferite (voce, sms, mms, video
call, internet, roaming), suma disponibilă, vechime în reţea.

Potenţialele aplicaţii ce vor folosi baza de date sunt aplicaţii de gestiune a clienţilor companiei de
telecomunicaţii. Un exemplu de astfel de aplicaţie este o aplicaţie web , baza de date poate fi accesată de
personalul autorizat (administrator şi utilizatori) folosind o pagină web.

10
2.2 Etapa a II-a. Proiectarea conceptuală a bazei de date.

În această etapă va intra şi etapa de proiectare logică a bazei de date.

Această etapă se va împărţi în mai multe subetape.

1. Descrierea cerinţelor utilizatorului. În cadrul acestei subetape, se vor analiza cerinţele utilizatorului şi în
funcţie de acestea se vor lua decizii asupra tabelelor folosite şi a relaţiilor dintre acestea, se vor realiza
totodată diagramele entitate relaţie.
2. Introducerea anumitor aspecte teoretice necesare înţelegerii modelului Entitate-Relaţie şi a termenilor:
tabel, entitate, atribut, tip de dată, relaţie, cheie candidată, cheie primară, cheie străină (externă) etc .
3. Proiectarea logică a bazei de date.
4. Arhitectura generală a bazei de date

2.2.1 Descrierea cerinţelor utilizatorului.

2.2.1.1 Cerinţele utilizatorului

Structura pentru abonaţi va conţine numele, codul clientului, număr telefon, tipul de abonament, servicii
oferite (voce, sms, mms, video call, internet, roaming), cost, stare plati (la zi sau restanţier), vechime în reţea.

Structura pentru clienţi prepay va conţine număr telefon, servicii oferite (voce, sms, mms, video call,
internet, roaming), suma disponibilă, vechime în reţea.

2.2.1.2 Tabelele utilizate

În structura de date pentru abonaţi vom avea următoarele tabele: Abonaţi, DateDeContact, Contracte,
Abonamente, Facturi, Tarife, NumereTelefon şi Servicii.

În structura de date pentru clienţi prepay vom avea următoarele tabele: CartelePrepay, NumereTelefon,
Servicii.

Observaţii:

 Tabelele NumereTelefon şi Servicii fac parte din ambele structuri de date.

 Având în vedere că ambele tipuri de clienţi folosesc serviciile companiei de telecomunicaţii, este
normal ca tabela Servicii să fie comună celor două tipuri de structuri de date.
 Tabela NumereTelefon reprezintă tabela în care sunt stocate numerele de telefon disponibile din
cadrul companiei telecom. O parte din numere sunt alocate abonaţilor, iar cealaltă clienţilor prepay.
Această tabelă poate reprezenta şi o legătură între cele două tabele în cazul în care un abonat poate
deţine şi o cartelă prepay.

11
2.2.1.3 Descrierea tabelelor
Tabela Abonaţi reprezintă tabela de identificare a abonaţilor companiei de telefonie mobilă. Această
tabelă va fi cuprinsă din următoarele coloane: IdAbonat, Nume, Prenume, CNP.

Tabela DateDeContact reprezintă tabela în care sunt detaliate datele de contact ale abonaţilor. Aceasta
va cuprinde coloanele: IdContact, Adresă, Email, NumărTelefonDeContact şi IdAbonat. * Coloana IdAbonat
este folosită pentru a identifica abonatul în cauză din cadrul tabelei Abonaţi. Acest câmp are o semnificaţie
specială ce va fi dezvăluită în următoarea etapă.

Tabela Contracte reprezintă tabela în care sunt înregistrate contractele dintre companie şi abonaţi.
Coloanele tabelei sunt următoarele: IdContract, DatăÎnceput, DatăSfârşit, IdAbonat, NumărTelefon. * La fel ca
şi în cazul tabelei DateDeContact, coloana IdAbonat identifcă abonatul, iar coloana NumărTelefon va identifica
numărul de telefon pentru care a fost iniţiat contractul. Acest ultim câmp face legătura cu tabela NumereTelefon.

Tabela Facturi reprezintă tabela ce deţine informaţiile referitoare la plăţile efectuate de către clienţi. În
această tabelă sunt stocate facturile clienţilor. Coloanele tabelei Facturi sunt următoarele: IdFactură,
DataFacturare, DataScadentă, TotalulDePlată, IdAbonat.

Tabela Abonamente conţine tipurile de abonamente oferite de compania de telefonie mobilă. Această
tabelă cuprinde coloanele: IdAbonament, TipAbonament, Cost, IdServiciu, IdTarif. * Din sturctura de date cerută
de client se regăsesc câmpurile: tipul de abonament şi cost.

Tabela Tarife cuprinde tarifele standard pentru convorbiri în reţea sau în afara reţelei atât pentru
abonamente cât şi pentru cartele prepay. În această tabelă se regăsesc următorele coloane: IdTarif, Apeluri
Reţea, ApeluriExtraReţea, SMSReţea, SMSExtraReţea, MMSReţea, MMSExtraReţea, TraficInternet. Tarifele
vor fi introduse în €/minut, €/SMS, €/MMS şi €/MB.

Tabela NumereTelefon cuprinde numerele de telefon date de operatorul de telecomunicaţii. Coloanele

acestei tabele sunt: NumărTelefon, IdAbonat, IdAbonament, IdPrepay.

Tabela Servicii reprezintă tabela cu informaţii referitoare la serviciile oferite de compania telecom.
Aceasta este alcătuită din următoarele coloane: IdServiciu, MinuteGratuite, SMSGratuite, MMSGratuite,
Internet, VideoCall, Roaming.

Tabela CartelePrepay reprezintă tabela ce cuprinde datele legate de cartele prepay. Coloanele acestei
tabele sunt următoarele: IdPrepay, SumăDisponibilă, IdServiciu.

2.2.1.4 Diagrama Enitate-Asociere formă primară

Figura de mai jos reprezintă o primă formă a diagramei entitate-asociere (E-R).

12
2.3.1.5 Relaţiile între tabele
Relaţie de tipul unul-la-unul– Tabela DateDeContact cu Tabela Abonaţi, Tabela Abonamente cu Tabela Tarife,
Tabela CartelePrepay cu Tabela NumereTelefon.

Relaţie de tipul unul-la-multe – Tabela Abonaţi cu Tabela Facturi, Tabela Abonaţi cu Tabela Contracte, Tabela
Abonaţi cu Tabela NumereTelefon , Tabela NumereTelefon cu Tabela Contracte, Tabela Servicii cu Tabela
Abonamente, Tabela Abonamente cu Tabela NumereTelefon, Tabela Servicii cu Tabela CartelePrepay.

Relaţie de tipul multe-la-multe – Tabela Abonaţi cu Tabela Abonamente folosind ca tabelă de legătură tabela
NumereTelefon.

2.2.1.6 Diagrama Entitate-Asociere formă finală

Odată stabilite relaţiile între cele 9 tabele, putem înainta cu proiectarea diagramei entitate-asociere .Pentru a
avea o imagine completă referitoare la arhitectura bazei de date ce se doreşte a fi proiectată, figura de mai jos
pune în evidenţă cele 9 entităţi împreună cu atributele corespunzătoare şi relaţiile dintre acestea.

2.2.2. Aspecte teoretice.

2.2.2.1. Modelul entitate-relaţie.

Modelul entitate-relaţie este cel mai utilizat model conceptual de nivel înalt, care reprezintă schema
conceptuală a bazei de date cu ajutorul entităţilor şi a relaţiilor dintre acestea.

13
2.2.2.2. Noţiunea de Entitate. Definiţie
O entitate este un obiect al lumii reale, cu o existenţă independentă şi poate reprezenta un obiect fizic, o
activitate, un concept. O entitate este un obiect cu existenţă fizică , de exemplu: persoană particulară, automobil,
companie, activitate, curs universitar. Orice entitate are o serie de proprietăţi numite atribute, ce descriu
entitatea respectivă. Cu toate că nu reprezintă acelaşi lucru, pentru denumirea de entitate se mai foloseşte şi
denumirea de tabel al bazei de date, iar pentru atribute câmpurile tabelului.

Pentru baza de date propusă, toate tabelele menţionate în etapa anterioară reprezintă entităţi. Prin urmare
entităţile ce copun baza de date sunt: Abonaţi, DateDeContact, Contracte, Abonamente, Facturi,
NumereTelefon, Servicii şi CartelePrepay. Fiecare dintre aceste există în realitate şi pot fi identificate într-un
mod distinctiv. Spre exemplu un Abonat este o persoană reală, în cadrul bazei de date entitatea Abonaţi
reprezintă indivizi care beneficiază de serviciile companieie de telecomunicaţii contra cost.

2.2.2.3. Noţiunea de Atribut. Definiţie

Un atribut este o proprietate care descrie un anumit aspect al unei entităţi. Spre exemplu un abonat are
nume, un prenume, un CNP etc. Fiecare dintre entităţile date sunt definite în mod unic de către atributele proprii.
Tabela Abonamente este defintă prin atributele IdAbonament, TipAbonament, Cost, IdServiciu. Nici o altă
entitate din baza de date nu este caracterizată de aceleaşi atribute. Fiecare dintre aceste atribute au o însemnătate
pentru entitatea în cauză.

Spre exemplu IdAbonament este un număr care identifică în mod unic un tip de abonament oferit de
compania de telefonie mobilă. Pe când atributul TipAbonament este un nume dat abonamentului respectiv
pentru a putea fi mai uşor de reţinut. Atributul Cost identifică preţul unui tip de abonament iar IdServiciu
reprezintă un atribut care face trimitere la tabela Servicii unde se regăsesc informaţii despre serviciile şi
beneficiile oferite de către acel abonament.

Unele atribute pot fi divizate în mai multe părţi cu semnificaţie independentă. Un astfel de atribut este un
atribut complex.

Un exemplu este cel al atributului Adresă care poate fi divizat în mai multe atribute : Oras, Cod Postal,
Stradă, Număr, Bloc etc.

Atributele care nu sunt compuse se numesc atribute atomice. Valoarea atributelor complexe se formează
prin concatenarea valorilor atributelor atomice.

Multe atribute au valoare unică pentru o entitate particulară şi sunt numite atribute cu o singură valoare. De
exemplu CNP-ul unei persoane. Există atribute ce pot lua mai multe valori dintr-un set dat, cum ar fi tipurile de
abonamente, stare plaţi (la zi sau restanţier), roaming (activat, dezactivat) etc. Aceste atribute sunt atribute cu
mai multe valori.

Atributele derivate sunt atributele ce se pot determina din alte atribute, cum ar fi vârsta unei persoane se
poate calcula din data curentă minus data naşterii persoanei respective.

În anumite situaţii, o entitate poate să nu aibă valori pentru toate atributele asociate ei, în acest caz
folosindu-se o valoare specială numită atributul null.

Fiecare atribut are un nume şi un domeniu de definiţie. Domeniul de definiţie al unui atribut este domeniul
în care atributul poate lua valori. Cu alte cuvinte, domeniul de definiţie reprezintă un tip de dată. Tipurile de date
cunoscute sunt: caractere, numere întregi, numere zecimale, boolean, data, datetime etc. Fiecărui atribut i se

14
atribuie şi o anumită dimensiune maximă. Spre exemplu atributul Adresă este o dată de tip caracter de
dimnesiune maximă 50 caractere.

Revenind la exemplul nostru, să ne definim toate entităţile din baza de date Telecom.

Entităţile sunt următoarele :

 Abonaţi cu atributele: IdAbonat(Int), Nume(Char), Prenume(Char), CNP(Int).

 DateDeContact cu atributele : IDContact(Int), Adresă(Char), Email(Char),
NumărTelefonDeContact(Int) şi IdAbonat(Int).
 Contracte cu atributele: IdContract(Int), DatăÎnceput(Date), DatăSfârşit(Date), IdAbonat(Int),
NumărTelefon(Int).
 Abonamente cu atributele: IdAbonament(Int), TipAbonament(Char), Cost(Int), IdServiciu(Int),
IdTarif(Int).
 Tarife cu atributele: IdTarif(Int) , Apeluri Reţea(Int), ApeluriExtraReţea(Int), SMSReţea (Int),
SMSExtraReţea(Int), MMSReţea(Int), MMSExtraReţea(Int), TraficInternet(Int).
 Facturi cu atributele : IdFactură(Int), DataFacturare(Date), DataScadentă(Date),
TotalulDePlată(Int), IdAbonat(Int).
 NumereTelefon cu atributele: NumărTelefon(Int), IdAbonat(Int), IdAbonament(Int), IdPrepay(Int).
 Servicii cu atributele: IdServiciu(Int), MinuteGratuite(Int), SMSGratuite(Int), MMSGratuite(Int),
Internet(Char), VideoCall(Char), Roaming(Char).
 CartelePrepay cu atributele: IdPrepay(Int), SumăDisponibilă(Int), Valabilitate (Date),
IdServiciu(Int).

2.2.2.4. Noţiunea de tabel. Definţie.

Un tabel (entitate) reprezintă o colecţie de informaţii logice relaţionale tratată ca o unitate. Acesta
constituie practic reprezentarea grafică a unei relaţii. Un tabel este compus din:

 Numele tabelului -identic cu numele relaţiei

 Coloanele corespund atributelor relatiei
 O mulţime de linii, fiecare linie corespunzând unui tuplu
 Valori ale atributelor fiecarui tuplu

Exemplu. Tabelul de mai jos:

Abonaţi

IdAbonat Nume Prenume CNP

1 Popescu Andreea 2881218180051
2 Visan Luiza 2900624030155
3 Barb Razvan 1830415232254
Cuprinde următoarele elemente componente:

Numele Tabelului: Abonaţi

Coloanele Tabelului: IdAbonat, Nume, Prenume, CNP.
Valori atribute: Andreea,Luiza,Razvan.

15
Linie (tuplu):
1 Popescu Andreea 2881218180051

Înregistrare

Un tabel (o tabelă) este compusă din înregistrări sau rânduri. Fiecare înregistrare este tratată ca o simplă
unitate. Fiecare înregistrare se poate lega de înregistrări ale altei tabele. Înregistrările sunt constituite din
câmpuri (coloane) . Un câmp este o particulă atomică a bazei de date ce reprezintă cea mai mică cantitate de
informaţie care poate fi manipulată. Toate înregistrările dintr-o tabelă au aceleaşi câmpuri.

2.2.2.5. Construcţia schemelor relaţie

În proiectarea bazelor de date se definesc relaţii sau asocieri între mulţimile de entităţi componente, pentru
a reprezenta anumite aspecte ale realităţii pe care o modelează baza de date.

O relaţie este o corespondenţă între entităţi din una sau mai multe mulţimi de entităţi. Gradul unei relaţii
este dat de numărul de mulţimi de entităţi asociate. Relaţiile pot fi binare (între 2 mulţimi de entităţi) sau
multiple (între mai mult de 2 entităţi). În lucrarea de faţă se lucrează doar cu mulţimi binare.

Se consideră 2 mulţimi de entităţi E1 şi E2.

2.2.2.5.1. Relaţia „unul-la-unul” (1-1 sau one to one)

Relaţia „unul-la-unul” este cel mai simplu tip de relaţie. Ea este relaţia prin care unui element din mulţimea
E1 îi corespunde un singur element din mulţimea E2 şi reciproc. Această relaţie „unul-la-unul” este foarte rar
folosită în lumea reală.

Un exemplu ar fi la aplicaţia pe care o proiectăm, relaţia dintre tabelele Abonaţi şi DateDeContact. Am

putea considera tabela DateDeContact ca o prelungire a tabelei Abonaţi, care cuprinde informaţii suplimentare
despre clienţii companiei de telecomunicaţii. Fiecărei înregistrări din tabelul Abonaţi îi va corespunde o
înregistrare din tabelul DateDeContact (şi numai una). În particular, folosind înregistrarea cu Id-ul 1 din tabelul
exeplificat anterior, abonatului cu numele şi prenumele Popescu Andreea îi va corespude o singură linie din
tabelul DateDeContact. Înregistrarea din acest tabel va asocia abonatului în cauză informaţii despre adresa,
emailul şi numărul de contact al persoanei respective. Asocierea e valabilă şi în sens invers, o înregistrare în
tabelul DatedeContact va corespunde unui singur abonat din tabela Abonaţi.

Pentru a realiza efectiv această relaţie trebuie introdus atributul IdAbonat în tabela DateContact.
Informaţiile stocate aşa sunt şi mai uşor de manipulat.

2.2.2.5.2. Relaţia „unul-la-multe” (1-N sau one to many)

Această relaţie este o relaţie prin care unui element din mulţimea E1 îi corespund unul sau mai multe
elemente din mulţimea E2, dar unui element din mulţimea E2 îi corespunde un singur element din mulţimea E1.

Un exemplu al acestui tip de relaţie din cadrul aplicaţiei pe care o proiectăm este cazul relaţiei dintre tabela
Servicii şi tabela CartelePrepay. Tabela Servicii este tabela cu informaţii referitoare la serviciile oferite de
compania telecom. Adică la numărul de minute oferite, numărul de mesaje SMS sau MMS, dacă se dispune de
Internet, Videocall sau Roaming. Fiecare tip de servici este unic. Nu vom avea tupluri identice. Un serviciu (o
înregistrare în tabela Servicii) poate corespunde mai multor cartele prepay. Adică o serie de cartele pot dispune
de aceeaşi ofertă de servicii ale companiei. Cazul invers nu va fi valabil. Unei cartele nu i se pot asocia mai
multe tipuri de servicii. Prin urmare relaţia dintre cele două entităţi este de tipul unul-la-multe.

16
 Pentru a realiza efectiv această relaţie trebuie introdus atributul IdServiciu şi în tabela CartelePrepay, pentru
a identifica tipul de serviciu (tuplul) din tabela Servicii.

2.2.2.5.3. Relaţia „multe-la-multe” (M-N sau many to many)

Această relaţie este o relaţie prin care unui element din mulţimea E1 îi corespund unul sau mai multe
elemente din mulţimea E2, şi reciproc. Acest tip de relaţie este foarte des întâlnită, dar nu poate fi implementată
în bazele de date relaţionale. De fapt, pentru modelarea acestei relaţii se foloseşte o relaţie suplimentară, de
tip unul-la-multe pentru fiecare din relaţiile iniţiale.

Un exemplu al acestui tip de relaţie din cadrul bazei de date pe care o proiectăm este cea dintre tabelele
Abonaţi şi Abonamente. Un abonat poate deţine mai multe abonamente (tipuri de abonamente), iar un
abonament (tip de abonament) este alocat mai multor abonaţi.

Pentru a crea această relaţie am introdus o tabelă suplimetară numită NumereTelefon, care va face
legătura între tabelele Abonaţi şi Abonamente. Între tabele Abonaţi, NumereTelefon şi Abonamente
NumereTelefon există o relaţie de tipul 1 la m. Un abonat poate avea mai multe numere de telefon, iar acelaşi tip
de abonament poate fi folosit pentru mai multe numere de telefon.

Pentru a realiza efectiv această relaţie în tabelul NumereTelefon au fost introduse câmpurile: IdAbonat
şi IdAbonament.

2.2.2.6. Constrângeri de integritate

Constrângerile de integritate sunt reguli care se definesc la proiectarea unei baze de date şi care trebuie
să fie respectate de-a lungul existenţei acesteia. Entităţiile unei baze de date reflectă realitatea modelată şi de
aceea valorile pe care le conţin trebuie să respecte anumite reguli, care să corespundă celor din realitate.

Vom folosi în continuare pentru termenul de entitate denumirea tabelă.

Constrângerile se pot clasifica astfel:

 Constrângeri în cadrul tabelei

 Constrângeri între tabele.

Constrângerile din cadrul unei tabele sunt reguli care se impun în cadrul unei singure tabele şi asigură
integritatea datelor acesteia. Ele sunt de 3 categorii:

 constrângeri de domeniu. Aceste constrângeri sunt condiţii care se impun valorilor atributelor şi asigură
integritatea domeniilor atributelor.
 constângeri de tuplu (de înregistrare din tabelă). Aceste constrângeri sunt condiţii care se impun
înregistrărilor din tabelă şi asigură identificarea corectă a tuplurilor prin intermediul cheilor primare.
 constrângeri impuse de dependenţe de date(dependenţe funcţionale). Acestea sunt constrângeri prin care
valorile unor atribute ale unei entităţi (câmpuri ale tabelei) determină valorile altor atribute ale aceleiaşi
entităţi.

Constrângerile între tabele sunt reguli care se impun între două sau mai multe relaţii. Cele mai importante sunt
constrângerile de integritate referenţială, care se realizează prin intermediul cheilor străine şi asigură asocierea
corectă a tabelelor.

17
2.2.2.6.1. Constrângerile de domeniu
Constrângerile de domeniu sunt condiţii impuse valorilor atributelor pentru ca acestea să corespundă
semnificaţiei pe care o au în realitatea modelată. În reprezentarea unei entităţi printr-un tabel, valorile atributelor
sunt reprezentate pe coloane. Din această cauză aceste constrângeri se mai numesc şi constrângeri de coloană.

Vom descrie 3 tipuri de constrângeri de coloană:

• Constrângerea NOT NULL. Valoarea NULL este o valoare particulară, care nu reprezintă valoarea 0, ci lipsă
de informaţie. Această valoare NULL poate apărea când nu se cunosc respectivele informaţii, ca de exemplu, în
cazul bazei de date Telecom, în tabela DateDeContact nu se cunoaşte numărul de telefon alternativ, ori această
informaţie nu este esenţială deorece clientul poate fi contactat folosind alte mijloace şi alte informaţii din acea
tabelă (precum Adresă sau Email). Nu orice atribut poate lua valoarea NULL, ca exemplu, numele unui abonat,
pentru că nu ar avea sens înregistrarea unui abonat al cărui nume nu se cunoaşte. Alte exemple pentru atribute ce
nu pot lua valoarea NULL ar fi numărul de telefon, tipul de abonament, suma datorată, suma disponibilă a
cartelei etc. În astfel de situaţii la definirea relaţiilor se impune atributului constrângerea NOT NULL,
însemnând că acest atribut nu poate lua valoare NULL în orice înregistrare din tabelă .

• Constrângerea DEFAULT. Această constrângere este folosită pentru stabilirea unei valori implicite
(DEFAULT) pentru un atribut al entităţii. În cazul în care la inserarea unei înregistrări nu se specifică valoarea
unui atribut (câmp), atunci acesta primeşte valoarea implicită (dacă a fost definită) sau valoarea NULL (dacă nu
a fost definită o valoare implicită pentru atributul respectiv, dar sunt admise valori NULL). Dacă nu a fost
definită o valoare implicită şi nici nu sunt admise valori NULL se generează o eroare.

• Constrângerea CHECK. Constrângerea CHECK este după cum îi spune şi numele o constrângere de
verificare. În limbajul SQL, domeniile în care pot lua valori atributele se pot stabili ca tipuri de date predefinite.
Pentru fiecare atribut se pot adăuga constrângeri de verificare la definirea tabelului.

2.2.2.6.2. Constrângerile referitoare la tupluri (înregistrările din tabelă)

O entitate este definită ca o mulţime de tupluri. Deci, tuplurile entităţii trebuie să fie distincte, acest
lucru însemnând că într-o entitate nu pot exista două sau mai multe tupluri care să conţină acceaşi combinaţie de
valori pentru fiecare atribut. Un concept mai util în dezvoltarea bazelor de date îl reprezintă conceptul de cheie
candidată.

O cheie candidată reprezintă o submultime de atribute ale unei entităţi care prezintă proprietatea de
unicitate, adică orice combinaţie de valori ale atributelor supercheii este unică pentru orice stare a relaţiei şi
proprietatea de ireductibilitate, adică nu exista nici o submulţime proprie, nevidă a cheii care sa aibă proprietatea
de unicitate. O cheie candidata poate sa fie simpla (alcatuita dintr-un singur atribut), sau compusa (alcatuita din
mai multe atribute).

Atunci când exista mai multe chei candidate, una dintre ele se alege ca si cheie primara, celelalte chei
candidate fiind numite chei secundare, alternative sau unice.

Exemplu. În cadrul bazei de date pe care dormi să o proiectăm avem o serie de entităţi. Pentru fiecare
dintre acestea pot exista cel puţin o combinaţie ireductibilă de atribute care să identifice unic entitatea şi care să
formeze cheia candidată.

Considerând tabelul Abonaţi cu atributele: IdAbonat(Int), Nume(Char), Prenume(Char), CNP(Int), vom

analiza fiecare atribut sau combinaţie de atribute pentru a determina cheia candidată. Pentru o primă observaţie,
trebuie să menţionăm faptul că mulţimea atributelor tabelului Abonaţi formează o combinaţie ce identifică în
18
mod unic acesată entitate. Însă această mulţime nu este ireductibilă ci se poate diviza în submulţimi care pot
identifica în mod unic entitatea în cauză. Prin urmare aceasta nu se poate considera a fi o cheie candidată.

Să presupunem că submuţimea Nume, Prenume şi CNP ar fi o cheie candidată compusă. Aceasta

identifică în mod unic un abonat, dar din nou se poate reduce în alte submulţimi ce prezintă aceeaşi proprietate.
Vom considera divizarea acestei submulţimi în două: submulţimea alcătută din elementul CNP şi submulţimea
formată din Nume şi Prenume. Atributul CNP identifică cu siguranţă în mod unic un Abonat ( fiecare dispune
de un cod numeric personal propriu) şi totodată este indivizibil. Aşadar una din cheile candidate pentru tabela
referită este atributul CNP.

Cea de-a doua submulţime alcătuită din atributele Nume şi Prenume ar putea fi considerată o cheie
candidată. Dacă este divizată în cele două elemente constituente nici unul nu vor putea identifica unic abonatul.
Prin urmare acestă submulţime nu se poate reduce. Problema care se pune este dacă acestă combinaţie de
atribute prezintă proprietatea de unicitate, adică dacă pot exista abonaţi cu acelaşi nume şi prenume. În mod
evident există şanse, deşi acestea sunt destul de mici. Indiferent, submulţimea în discuţie nu beneficiază de
această proprietate. Aşadar, nu este o cheie candidată.

Atributul IdAbonat este o cheie candidată, deoarece prezintă prorietatea de unicitate şi de

ireductibilitate. Aşadar cheile candidate ale entităţii Abonaţi sunt: IdAbonat şi CNP.

În următorul tabel sunt prezentate cheile candidate pentru fiecare entitate în parte:

Entitate Atribute Chei candidate

Abonaţi IdAbonat, Nume, Prenume, CNP IdAbonat , CNP

DateDeContact IDContact, Adresă, Email, IdContact, Email,

NumărTelefonDeContact, IdAbonat NumărTelefonDeContact

Contracte IdContract, DatăÎnceput, DatăSfârşit, IdAbonat, IdContract

NumărTelefon

Abonamente IdAbonament,TipAbonament, Cost, IdServiciu, IdAbonament, TipAbonament

IdTarif.

Tarife IdTarif , Apeluri Reţea, ApeluriExtraReţea,  IdTarif ,  Apeluri Reţea,

SMSReţea, SMSExtraReţea, MMSReţea, ApeluriExtraReţea, SMSReţea,
MMSExtraReţea, TraficInternet SMSExtraReţea, MMSReţea,
MMSExtraReţea, TraficInternet 
Facturi IdFactură, DataFacturare, DataScadentă, IdFactură
TotalulDePlată, IdAbonat
NumereTelefon NumărTelefon, IdAbonat, Abonament, IdPrepay NumărTelefon

Servicii IdServiciu, MinuteGratuite, SMSGratuite, IdServiciu, MinuteGratuite,

MMSGratuite, Internet, VideoCall, Roaming SMSGratuite, MMSGratuite,
Internet, VideoCall, Roaming 
CartelePrepay IdPrepay, SumăDisponibilă, Valabilitate, IdPrepay
IdServiciu, IdTarif

19
 Pentru tabela DateDeContact am considerat cheile candidat IdContact, Email,
NumărTelefonDeContact, deoare fiecare dintre acestea se bucură de proprietăţile unei asfel de chei (sunt
indivizibile şi unice pentru entitate în cauză). Atributul Adresă a fost elimant din lista de posibile chei deoarece
doi abonaţi pot locui la aceeaşi adresă. Prin urmare înregistrările în tabela DateDeContact pentru adresa celor
doi abonaţi vor fi aceleaşi.

Pentru tabela Contracte cheia candidată considerată este IdContract. Nici un alt atribut, sau
combinaţie de atribute nu prezintă proprietatea de unicitate. Pot exista mai multe contracte cu aceleaşi date de
început şi date de încheiere.

În cazul tabelei Abonamente cheile candidate sunt IdAbonament şi TipAbonament. Atributul

TipAbonament desemnează practic denumirea abonamentului. Aşadar nu pot exista două abonamente cu acelaşi
nume şi implicit de acelaşi tip. Însă două abonamente pot avea acelaşi preţ, acestea diferind prin tipurile de
servicii pe care le oferă.

Tabela Tarife are drept chei canditate o cheie simplă IdTarif şi una compusă  Apeluri Reţea,
ApeluriExtraReţea, SMSReţea, SMSExtraReţea, MMSReţea, MMSExtraReţea, TraficInternet . Cele două
submulţimi alcătuiesc mulţimea totală de atribute a tabelului Tarife. Pentru atributul IdTarif lucrurile sunt clare.
Celelalte atribute luate ca întreg formează o submulţime care este unică pentru fiecare înregistrare în tabelul
Tarife şi care este totodată o submulţime ireductibilă din punctul de vedere al proprietăţii de unicitate. Fiecare
element al submuţimii nu va putea fi unic pentru entitatea în discuţie. Considerând însă combinaţia de elemente,
nu vor exista două planuri tarifare cu aceleaşi valori pentru atributele respective. Prin urmare submuţimea de
atribute  ApeluriReţea, ApeluriExtraReţea, SMSReţea, SMSExtraReţea, MMSReţea, MMSExtraReţea,
TraficInternet  este o cheie candidată.

Pentru tabela Facturi cheia candidată este  IdFactură. Nici un alt atribut, sau combinaţie de atribute nu
prezintă proprietatea de unicitate. Acest lucru este valabil şi în cazul tabelelor NumereTelefon şi CartelePrepay
cu cheile candidat NumărTelefon respectiv IdPrepay.

La tabela Servicii întâlnim un caz similar cu cel al tabelei Tarife. Aceasta are drept chei candidate o
cheie simplă IdServiciu şi o cheie compusă MinuteGratuite, SMSGratuite, MMSGratuite, Internet,
VideoCall, Roaming . Combinaţia de atribute a cheii compuse este ireductibilă şi unică pentru tabelul Servicii.

Observaţie. În analiza cheilor candidat nu am considerat atributele care fac legătura dintre tabele
precum IdAbonat din tabela DateDeContact sau IdServiu, IdTarif din tabela Abonamente. Aceste atribute
reprezintă un alt tip de chei .

O cheie primară (primary key) este o cheie candidată căreia proiectantul îi conferă un rol special de
accesare şi identificare a tuplurilor relaţiei. În plus, se impune ca atributelor cheii primare să nu admită valori de
NULL şi să nu fie modificate prin operaţii de actualizare a datelor.

O cheie secundară (alternativă, unică) (secondary, alternate, unique key) este o cheie candidată care nu a
fost desemnată de proiectant ca şi cheie primară. Cheile secundare admit valori NULL pentru unele din
atributele lor dacă se respectă condiţia de unicitate a valorilor.

O cheie primară compusă din atributele existente ale tipului de entitate se numeşte cheie naturală. În
general, cheile naturale sunt compuse din mai multe atribute (ceea ce produce scăderea eficienţei operaţiilor

20
relaţionale) şi de cele mai multe ori se folosesc chei artificiale . O cheie primara artificială este un atribut care se
adaugă în schema relatiei pentru identificarea unică a tuplurilor.

De exemplu, atributele IdAbonat, IdContract, IdContact, IdAbonament, IdServiciu, IdFactură,

IdPrepay, IdTarif sunt toate chei primare artificiale, special create pentru a manevra cu mai multă uşurinţă
tabelele constituente ale bazei de date. Aceste atribuet pot identifica în mod unic un tuplu, deoarece (prin
convenţie) nu se atribuie acelaşi număr de identificare una dintre entităţile respective.

Un exemplu de cheie primară naturală este cheia NumărTelefon. Am considerat că în acest caz este mai
util şi mai uşor să se păstreze cheia naturală, pentru un lucru mai eficient cu baza de date. Introducerea unui
câmp IdNumărTelefon ar fi fost mai degrabă un dezavantaj decât un avantaj.

Printre cheile candidat existau spre exemplu şi chei naturale compuse din mai multe atribute precum
cheia  Apeluri Reţea, ApeluriExtraReţea, SMSReţea, SMSExtraReţea, MMSReţea, MMSExtraReţea,
MesagerieVocală, TraficInternet . Folosirea unei astfel de chei drept cheie primară ar fi fost dificlă, luând în
considerare relaţia tabelei Tarife cu tabela Abonamente şi faptul că în tabela Abonamente există un câmp de
identificare a tabelei Tarife (IdTarif), câmp ce corespunde cheii primare a acestei tabele. Cum ar fi fost dacă în
loc de atributul IdTarif s-ar fi folosit submulţimea  Apeluri Reţea, ApeluriExtraReţea, SMSReţea,
SMSExtraReţea, MMSReţea, MMSExtraReţea, TraficInternet . În primul rând ineficient, având în vedere
numărul de atribute iar în al doilea rând tabela Tarife ar fi fost redundantă.

În următorul tabel sunt ilustrate cheile primare pentru fiecare din entităţile bazei de date:

Entitate Atribute Chei primare

Abonaţi IdAbonat, Nume, Prenume, CNP IdAbonat 

DateDeContact IDContact, Adresă, Email, IdContact

NumărTelefonDeContact, IdAbonat

Contracte IdContract, DatăÎnceput, DatăSfârşit, IdAbonat, IdContract

NumărTelefon

Abonamente IdAbonament,TipAbonament, Cost, IdServiciu, IdAbonament

IdTarif.

Tarife IdTarif , Apeluri Reţea, ApeluriExtraReţea,  IdTarif 

SMSReţea, SMSExtraReţea, MMSReţea,
MMSExtraReţea, TraficInternet

Facturi IdFactură, DataFacturare, DataScadentă, IdFactură

TotalulDePlată, IdAbonat
NumereTelefon NumărTelefon, IdAbonat, Abonament, IdPrepay NumărTelefon

Servicii IdServiciu, MinuteGratuite, SMSGratuite, IdServiciu

MMSGratuite, Internet, VideoCall, Roaming

CartelePrepay IdPrepay, SumăDisponibilă, Valabilitate, IdPrepay

VechimeÎnReţea, IdServiciu, IdTarif

21
2.2.2.6.3. Constrângeri între tabele
Relaţiile dintre tipurile de entităţi definite în modelul conceptual al unei baze de date se realizează în modelul
relaţional prin intermediul cheilor străine.

O cheie străină (cheie externă ) este o submulţime de atribute ale unei entităţi E1 care referă entitatea E2 şi
îndeplineşte următoarele condiţii: atributele cheii străine din E1 sunt definite pe domenii compatibile cu cele ale
atributelor cheii din entitatea E2, şi cheia din entitatea E2 este cheie primară în această relaţie. Această cheie
străină determină o asociere între câmpurile unor tabele cu cele ale altei tabele şi creează abilitatea de realizare
a unirii tabelelor respective prin intermediul operaţiilor JOIN.

Integritatea referenţială este proprietatea bazei de date care garantează că oricare valoare a unei chei străine se
regăseşte printre valorile cheii corespunzătoare din relaţia referită, sau cheia străină are valoarea NULL (dacă
atributele acesteia nu sunt supuse constrângerii NOT NULL).

Exemplu:

Revenind la baza de date ce se doreşte a fi proiectată, numită Telecom vom analiza fiecare relaţie în parte şi
totodată vom evidenţia cheile străine corespunzătoare.

Se vor analiza mai întâi relaţiile unul-la-unul. Unui element din mulţimea E1 îi corespunde un singur element
din mulţimea E2 şi reciproc.

Relaţia dintre tabela DateDeContact şi tabela Abonaţi este o relaţie de tipul 1-1. Tabela DateDeContact referă
tabela Abonaţi prin atributul DateDeContact.IdAbonat. *Observaţie. Această notaţie se foloseşte în limbajul
SQL în momentul în care două tabele au acelaşi atribut şi se doreşte să se facă diferenţerea dintre cele două.
Atributul IdAbonat din cadrul tabelei DateDeContact va fi cheia străină în această relaţie. Aceasta corespunde
practic cheii primare din tabela Abonaţi. Aşadar, cele două vor avea acelaşi domeniu de definiţie şi valoarea
atrbutului DateDeContact.IdAbonat se va regăsi printre una din valorile atributului Abonaţi.IdAbonat. Pentru o
mai bună înţelegere vom considera un exemplu practic.

Să presupunem că în tabela Abonaţi şi în tabela DateDeContact avem o serie de înregistrări. Relaţia dintre cele
două este evidenţiată în următoarea figură.

Observaţii
22
  Valorile pentru câmpul IdAbonat din cadrul tabelului DateDeContact corespund celor pentru câmpul
IdAbonat din cadrul tabelului Abonaţi.
 Aşadar prima înregistrare din tabelul DateDeContact corespunde primei înregistrări din tabela Abonaţi,
adică abonatul Popescu Andreea are drept date de contact adresa Str. Aleea Plopilor, emailul
andreea.popescu@yahoo.com şi numărul alternativ de telefon 0740000886. Cea de-a doua înregistrare
în tabelul DateDeContact corespunde celei de-a treia înregistrări din tabela Abonaţi. Cea de-a treia
înregistrare din tabelul DateDeContact corespunde celei de-a doua înregistrări din tabela Abonaţi.
 Din acest exemplu reiese deasemenea tipul de relaţie dintre cele două tabele. Fiecărei înregistrări din un
tabel îi corespunde câte o înregistrare şi numai una din tabelul celălalt.
 Cheia străină pentru această relaţie este IdAbonat.

Relaţia dintre tabela Abonamente şi tabela Tarife. Această relaţie este deasemenea o relaţie de tipul 1-1.
Tabela Abonamente referă tabela Tarife prin atributul Abonamente.IdTarif, acesta fiind practic cheia străină în
cazul acestei relaţii. Fiecărui tip de abonament îi va corespunde un tarif şi numai unul. Tabela tarife nu se referă
la costul efectiv al abonamentului ci la costul suplimentar care se adaugă pentru folosirea anumitor servicii.
Atributul IdTarif este cheie primară pentru tabela Tarife şi corespunde cheii străine din tabelul Abonamente. Ca
şi în cazul precedent vom evidenţia această relaţie prin un exemplu.

Să presupunem că în tabela Tarife şi în tabela Abonamnete avem înregistrări. Relaţia dintre cele două tabele este
ilustrată în figura următoare:

Observaţii

 Valorile atributului IdTarif din cadrul tabelei Abonamente se regăsesc printre valorile atributului IdTarif
din cadrul tabelei Tarife.
 Fiecarei înregistrări din tabela abonamente îi corespunde câte o înregistrare din tabela Tarife şi reciproc
rezultând o relaţie de tipul 1-1
 Abonamentul VoceNaţional dispunde de planul tarifar cu Id-ul 2 unde tarifele pentru covorbirile din
cadrul reţelei cât şi pentru cele din afara acesteia sunt asemănătoare.
 Cheia străină în cazul acestei relaţii va aparţine tabelei Abonamente şi va fi IdTarif.
 În tabela Abonamente există o a doua chei străină ce face referire la tabela Servicii. Relaţia dintre cele
două tabele va fi analizată în cele ce urmează.

23
Relaţia dintre tabela CartelePrepay şi tabela NumereTelefon. (Relaţie 1-1) Tabela NumereDeTelefon face
referinţă la tabela CartelePrepay prin atributul IdPrepay, care este de altfel cheia străină. Se observă că la fel ca
în cazurile precedente IdPrepay este cheie primară pentru tabelul CartelePrepay şi cheie străină pentru
NumereTelefon. Relaţia dintre cele două tabele este totuşi mai complexă faţă de cazul precedent. În tabela
NumereTelefon se mai regăsesc încă două chei străine. Aceasta este practic tabela de legătură în relaţia multe-
la-multe dintre Abonaţi şi Abonamente. Se pleacă de la premisa că un abonat poate avea mai multe numere de
telefon, acestea putând fi folosite fie doar pentru abonamente, fie pentru abonamente şi pentru caretele prepay.
Aşadar un abonat poate deţine şi un abonament şi o cartelă, lucru ce este posibil în realitatea de zi cu zi. Un
număr de telefon poate fi alocat unei cartele fără a se cunoaşte clientul. Acest lucru se întâmplă atunci când
clientul respectiv nu deţine un abonament şi nu se cunosc alte informaţii despre acesta. În cazul de faţă vom
considera următorul exemplu:

Observaţii

 Valorile atributului IdPrepay din tabela NumereTelefon se regăsesc printre valorile atributului IdPrepay
din tabela CartelePrepay.
 Cheia străină este IdPrepay
 Din acest exemplu se poate deduce faptul că numerele de telefon pot fi alocate în trei moduri:
o Unui abonat ce deţine un abonament fără să deţină o cartelă preapy. Este cazul primelor 3
înregistrări din tabel. Adică abonatul cu Id-ul 2, deţine abonamentul cu Id-ul 1 şi nu deţine
cartelă prepay.
o Unei cartele prepay ce este deţinută de un abonat (are şi un abonament).
o Unei cartele prepay pentru care nu se cunosc date despre deţinător.
 Tabela CartelePrepay mai are o cheie externă (străină) şi anume IdServiciu care face legătura 1-n cu
tabela Servicii.

Vom analiza în continuare relaţia de tipul multe-la-multe dintre tabelele Abonaţi şi Abonamente.
Tabela intermediară este NumereTelefon. Între tabelele Abonaţi respectiv Abonamente şi tabela NumeTelefon
există relaţii de tipul unul-la-multe. Pentru această analiză vom considera tabelele Abonaţi, Abonamente şi
NumereTelefon exemplificate mai sus.

24
În cadrul relaţiei Abonaţi-NumereTelefon (relaţie 1-n) unui abonat îi va corespunde mai multe numere de
telefon. Cheia străină definitorie pentru această relaţie face parte din tabela NumereTelefon şi este IdAbonat.

În cadrul relaţiei Abonamente-NumereTelefon (relaţie 1-n) unui abonament i se vor aloca mai multe numere de
telefon. Cheia străină definitorie pentru această relaţie face parte din tabela NumerTelefon şi este IdAbonament.

Din exemplele de înregistrări reiese că unui abonat (abonatul cu Id-ul 2) îi poate corespunde mai multe numere
de telefon (0771502506 şi 0771956525). Acelaşi număr de telefon nu poate fi alocat însă mai multor abonaţi.
Prin urmare am dovedit că relţia dintre cele două este de tipul 1-n.

Un abonament poate fi alocat mai multor numere de telefon aşa cum este cazul numerelor de telefon
0771502506 şi 0771771177 cărora li se alocă abonamentul cu Id 1. Un număr de telefon corespunde însă unui
singur abonament. Prin urmare relaţia dintre cele două tabele este de tip 1-n.

Tot din exemplele de mai sus se poate deduce relaţia de tip n-m dintre tabelele Abonaţi şi Abonamente. Un
abonat poate deţine mai multe abonamente aşa cum este cazul abonatului 2 ( Luiza Vișan ) căreia îi corespund
abonamentele cu Id-urile 1 şi 3 (VoceNaţional respectiv VoceStandard). Iar un abonament poate fi alocat mai
multor clienţi aşa cum apare în cazul abonamentului cu Id 1 (VoceNaţional) ce aparţine atât clientului cu Id 1
(Andreea Popescu) cât şi clientului cu Id 3 (Razvan Barb).

Observaţii

 Cum am menţionat anterior tabela NumereTelefon este asociată şi cu tabela CartelePreapay şi cuprinde
pe lângă cheile străine IdAbonat şi IdAbonament cheau străină IdPrepay.
 Modul de alocare a numerelor de telefon poate diferi. Numerele de telefon pot corespunde fie unui
abonament fie unui prepay. Primele trei înregistrări din tabela prepay corespund unei alocări de
abonament. Următorele două corespund alocării numerelor respective unor cartele prepay. În acest caz,
pentru un număr de telefon se cunoaşte şi deţinătorul cartelei respective iar pentru celălalt nu se cunosc
informaţii suplimentare despre client.
 Lipsa de informaţie corespunde introducerii unei valori NULL în câmpul respectiv.

25
Se vor considera deasemenea în continuare şi relaţiile de tipul unul-la-multe.

Relaţia Servicii-Abonamente . Este o relaţie de tipul 1-n, un serviciu poate corespunde mai multor abonamente
iar un abonament poate avea un singur serviciu. Cheia străină (externă) pentru această asociere este IdServiciu şi
aparţine tabelei Abonamente. Atributul IdServiciu este pentru tabela Servicii cheia primară.

IdServiciu MinuteGratuite SMSGratuite MMSGratuite Internet VideoCall Roaming

1 100 100 10 Inactiv Inactiv Inactiv
2 150 50 5 Inactiv Inactiv Activ

IdAbonament TipAbonament Cost IdServiciu IdTarif

( Euro )
1 VoceNational 6 1 2
2 VoceRețea 6 2 3
3 VoceStandard 6 1 1

Observaţii

 Valorile atributului IdServiciu din tabela Abonamnete se regăsesc printre valorile atributului IdServiciu
din tabela Servicii.
 Se observă de asemenea tipul de relaţie existentă prin faptul că abonamentele cu Id-urile 1 şi 2 dispun de
acelaşi serviciu, serviciul cu Id 1

Relaţia Servicii-CartelePrepay . Este o relaţie de tipul 1-n, un serviciu poate corespunde mai multor cartele
prepay iar o cartelă prepay poate dispune de un singur serviciu. Cheia străină (externă) pentru această asociere
este IdServiciu şi aparţine tabelei CartelePrepay. Atributul IdServiciu este pentru tabela Servicii cheia primară.

Observaţii

 Valorile atributului IdServiciu din tabela CartelePrepay (cheie străină) se regăsesc printre valorile
atributului IdServiciu din tabela Servicii (cheia primară a tabelului Servicii).
26
  Clientul prepay cu IdPrepay 1 beneficează de serviciul cu IdServiciu 1 iar clientul cu IdPrepay 2
dispune de serviciul cu IdServiciu 2.
 Acest exemplu nu evidenţiază tipul de relaţie, însă în tabelul cartele prepay se mai pot insera date
corespunzătoare unei noi cartele care să beneficieze de serviciul cu Id-ul 1. În acest caz relaţia a fost
exemplificată prin faptul că un serviciu se poate oferi mai multor cartele prepay.

Relaţia Abonaţi-Facturi. Această relaţie este la rândul său o relaţie de tipul unul-la-multe. Asocierea dintre
cele două tabele este realizată prin folosirea în tabelul Facturi a cheii străine IdAbonat. Această relaţie este o
relaţie tipică 1-n în care unui abonat îi corepunde mai multe facturi în funcţie de vechimea acesteia. Pentru a
exemplifica vom folosi tabelele Abonaţi şi Facturi.

IdAbonat Nume Prenume CNP

1 Popescu Andreea 2881218180051
2 Vișan Luiza 2900624030155
3 Barb Razvan 1830415232254

IdFactura DataFacturare DataScadentă TotalulDePlată IdAbonat

( Euro )
1 10.09.2014 20.09.2014 10 1
2 10.10.2014 20.10.2014 6 1
3 10.10.2014 20.10.2014 6 2
4 10.10.2014 20.10.2014 11 3

Observaţii

 Valorile atributului IdAbonat din tabela Facturi(cheie străină) se regăsesc printre valorile atributului
IdAbonat din tabela Abonaţi (cheia primară a tabelului Abonaţi).
 Prin acest exemplu se pune în evidenţă tipul de relaţie. Abonatul cu IdAbonat 1 are asociate 2 facturi cu
dăţi de facturare respectiv scadente diferite. Factura cu Id 1 este o factură mai veche, iar cea cu Id 2 este
mai recentă.

Relaţia Abonaţi-Contracte. Această relaţie de tipul unul-la-multe. Asocierea dintre cele două tabele este
realizată prin folosirea în tabelul Contracte a cheii străine IdAbonat. Tabele sunt exemplificate mai jos.

IdContact DatăÎnceput DatăSfârșit IdAbonat NumărDeTelefon

1 03.03.2014 03.03.2016 2 0771502506
2 03.03.2014 03.03.2016 2 0771956525
3 05.07.2014 05.07.2016 1 0771771177
4 24.05.2014 24.05.2016 3 0771897887

27
Observaţii

 Un abonat, cu mai multe numere de telefon, încheie câte un contract pentru fiecare dintre acestea. Prin
urmare un abonat poate avea mai multe contracte iar un contract este asociat unui singur abonat.
 Din cele două tabele putem deduce tipul de relaţie dintre acestea. Abonatul cu IdAbonat 2 are două
contracte cu Id-urile 1 şi 2 pentru două numere de telefon.
 Tabela Contracte mai cuprinde o altă cheie străină NumărTelefon ce leagă tabela NumereTelefon de
tabela Contracte în o relaţie de tipul unul-la-multe.

Relaţia NumereTelefon-Contracte. Tabela Contracte face referinţă la tabela NumereTelefon folosind

atributul NumărTelefon, care este cheia străină a acestei relaţii. Atributul NumărTelefon este cheie primară în
tabela NumereTelefon. Pentru o mai bună punere în evidenţă a cheilor şi a relaţiei dintre cele două tabele, vom
folosi tabelele exemplificate în analiza relaţiilor anterioare.

NumărTelefon IdAbonat IdAbonament IdPrepay

0771502506 2 1 NULL
0771771177 1 1 NULL
0771956525 2 3 NULL
0775001122 1 NULL 1
0775256232 NULL NULL 2
0771897887 3 2 NULL

IdContract DataÎnceput DataSfârșit IdAbonat NumărTelefon

1 03.03.2014 03.03.2016 2 0771502506
2 03.03.2014 03.03.2016 2 0771956525
3 05.07.2014 05.07.2016 1 0771771177
4 24.05.2014 24.05.2016 3 0771897887
5 24.05.2012 24.05.2014 3 0771897887

Observaţii

 Valorile introduse în câmpul NumărTelefon al tabelului Contracte corespund celor din câmpul
NumărTelefon al tabelului NumereTelefon.
 Faţă de exemplu precedent, în tabela Contracte s-a mai adăugat o nouă înregistrare pentru a demonstra
tipul de relaţie dintre cele două tabele. Noua înregistrare corespunde unui contract mai vechi (data de
început şi de sfârşit anterioare) al abonatului cu IdAbonat 3 pentru numărul de telefon 0771897887.
Pentru acelaşi număr de telefon în tabelul Contracte există şi înregistrarea cu IdContract 4 care deţine
cele mai recente informaţii despre contractul pentru numărul respectiv. Rezultă, deci, că şi acestă relaţie
este de tipul 1-n, având cheia străină NumărTelefon.

28
 2.3. Etapa a III-a. Proiectarea logică a Bazei de Date

În acestă etapă vom face o anliza a schemei coceptuale create şi vom determina dacă schema propusă poate
fi transpusă într-o schemă logică. Proiectarea logică a bazei de date ar presupune anumiţi paşi importanţi
precum:

 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 recursive prin înlocuirea cu relații dependente;
 eliminarea atributelor multiple;
 reexaminarea relațiilor 1:1, eliminarea relațiilor redundante;

O parte din aceşti paşi au fost deja luaţi în considerare deoarece cele două etape de proiectare (conceptuală şi
logică) au fost oarecum contopite într-o singură etapă. S-a pornit încă de la început cu o idee asupra tipurilor de
relaţii ce vor fi folosite şi s-a analizat necesitatea fiecări entităţi în parte. Această etapă are însă scopul de a
analiza mai în detaliu schema prezentată şi de a o valida în cazul în care aceasta varintă corespunde cerinţelor
utilizatorului şi este optimă din punctul de vedere al relevanţei şi al relaţiilor dintre tabele.

Primul pas de eliminare a relaţiilor M-N a fost abordat . Singura relaţie de tipul M-N din cadrul schemei este
relaţia dintre Abonaţi şi Abonamente , relaţie tranpusă în două folosind tabela intermediară Numere Telefon.
Sigur, puteau exista şi alte alegeri însă aceasta este una dintre cele mai potrivite. Nu numai că tabela
NumereTelefon leagă abonaţii de abonamente, ci aceasta face deopotrivă legătura dintre abonaţi şi cartele
Prepay, relaţie de tipul 1-N.

O relaţie recursivă apare atunci când o entitate depinde de ea însăşi. Un exemplu bun pentru a asfel de relaţie
este entitatea Angajat (persoană care lucrează într-o companie). Acesta poate fi conduce alţi angajaţi şi poate fi
condus la rândul său de un alt angajat. Prin urmare se crează o relaţie recursivă. Astfel de relaţii nu sunt întâlnite
în cadrul schemei conceptuale propuse în această lucrare. Spre exemplu entitatea Abonaţi prezintă numai relaţii
dependente, precum cele cu entităţile DateDeContact, Facturi, Contracte, NumereTelefon (Abonamente,
CartelePrepay).

Schema Conceptuală propusă nu deţine atribute multiple. Un exemplu în care acest lucru ar fi fost posibil ar fi
folosirea atributelor din cadrul tabelei Servicii ca atribute în tabele Abonamente şi CartelePrepay. Fiecare dintre
aceste două entităţi dispune de anumite servicii oferite de compania de telefonie mobilă. Însă folosirea acestor
atribute în dublu exemplar în ambele tabele ar fi redundantă şi ar complica foarte mult schema. Prin urmare s-a
preferat crearea unei tabele comune numită Servicii care sa încorporeze atributele comune celor două entităţi.

Relaţiile de tipul unul-la-unul propuse sunt relaţiile dintre Tabela DateDeContact şi Tabela Abonaţi, Tabela
Abonamente şi Tabela Tarife, Tabela CartelePrepay şi Tabela NumereTelefon. Dintre acestea, relaţiile care ar
putea fi considerate redudante ar fi relaţia dintre Abonaţi şi DateDeContact şi relaţia dintre Abonamente şi
Tarife. Relaţia dintre CartelePrepay şi NumerTelefon este o relaţie specială care leagă totodată tabela
CartelePrepay de tabela Abonaţi.

29
O analiză a relaţiei 1-1 dintre tabelel Abonaţi şi DateDeContact ar putea conduce la ideea că aceasta este o
relaţie redundantă şi atributele din cadrul tabelei DateDeContact ar putea fi transferate în tabelul Abonaţi.
Acelaşi lucru poate fi dedus şi pentru cea de-a doua relaţie dintre Abonamente şi Tarife. Problema care se pune
însă este aglomerarea tabelelor în loc sa avem un tabel cu câteva coloane avem unul cu un număr dublu sau
chiar triplu de coloane. În cazul relaţiei Abonamente-Tarife ar putea exista posibilitatea ca tabelul Tarife să fie
asociat cu un alt tabel, spre exemplu tabelul CartelePrepay. Ori dacă acest lucru are loc şi în loc de tabeulul
Tarife avem un singur tabel Abonamente ce cuprinde şi atributele acestuia ne vom afla în situaţia unor atribute
multiple. Totodată, separea celor două tabele este necesară pentru cazurile în care utilizatorul nu este interesat de
tipul de tarif folosit ci de numele sau costul abonamentului sau de serviciile de care abonamentul dispune. Şi
atunci o supraîncărcare a tabelului cu coloane nu este o idee prea bună. Acelaşi lucru se poate spune şi despre
relaţia Abonaţi-DateDeContact. Separarea în două entităţi diferite este mai avantajoasă decât păstrarea unei
etităţi singulare. Astfel informaţiile referitoare la datele personale a clientului sunt separate de informaţiile
referitoare la acesta ca abonat al unei companii de telefonie mobilă.

2.4. Etapa a IV-a. Alegerea SGBD-ului

Alegerea unui SGBD pentru implementarea unei baze de date se face ţinând seama de mai mulţi factori:
tehnici, economici şi administrativi. Factorii tehnici trebuie să asigure alegerea unui SGBD adecvat sarcinii de
realizare a sistemului informatic al întreprinderii. De asemenea, înainte de achiziţionarea unui anumit SGBD
trebuie să se cunoască configuraţia hardware-software necesară, precum şi alte cerinţe de dezvoltare a
programelor de aplicaţii (compilatoare, drivere, etc.).

Vom lucra cu baza de date relaţională Oracle Database 11g Express Edition.

Caracteristicile sistemului Oracle 11g

Oracle 11g oferă o infrastructură cuprinzătoare de înaltă performanţă incluzând:

 O arhitectură robustă, solidă, accesibilă şi sigură

 Opţiuni de dezvotare uşor de utilizat
 O singură interfaţă de management pentru toate aplicaţiile
 Posibilitatea de grid computing

Baza de date Oracle 11g a fost proiectată pentru a stoca şi administra datele unei întreprinderi. Această bază
de date reduce costurile de management şi asigură servicii de înaltă calitate. Oracle Database XE este uşor de
instalat şi de administrat. Se foloşte o interfaţă de tipul Home-Page accesată prin intermediul browser-ului, cu
ajutotul căreia se pot crea tabele , vederi şi alte obiecte, se pot importa/exporta date, se pot crea ineterogări şi
scripturi SQL.

Serverul de aplicaţii Oracle 10 g asigură o platformă completă pentru dezvolatarea şi implementarea aplicaţiilor
enterprise, integrând multe funcţii incluzând J2EE, Servicii Web etc.

Serverul Oracle are suport atât pentru modelul de date relaţional cât şi pentru cel obiect-relaţional.

30
Capitolul 3. Implementarea fizică a bazei de date

Pentru a implementa baza de date TELECOM am instalat pentru început mediul Oracle Database 10g
Express Edition. Cum orice bază de date are administratori şi utilizatori vom începe cu crearea acestora.

3.1. Crearea Administratorului şi Utilizatorilor

Meniul principal al mediului Oracle Database 11g Express Edition este:

Pentru a crea contul de administrator şi conturile de utilizatori se vor accesa Administration> Database Users>
Create User.

Contul de administrator va avea numele de AdminTelecom, iar conturile de utilizator UserTelecom1,

UserTelecom2 etc.

În cazul contului de administator se va selecta căsuţa DBA, care va indica că userul AdminTelecom are drepturi
de administrator. Parola pentru admin va fi „oracle” .

31
După apăsarea butonului create, în lista cu utilizatori va apărea contul nou creat.

Acelaşi procedeu se aplică şi pentru crearea conturilor de utilizator, numai că, în acest caz nu se va mai
selecta casuţa DBA. Aceştia vor fi în număr de trei. Parola pentru useri va fi „oracle” .

32
 În final lista cu utilizatori va arata în felul următor:

3.2. Crearea tabelelor

Cel de-al doilea pas în crearea bazei de date este crearea tabelelor. Tablele pe care le vom crea au fost prezentate
în secţiunile precedente. Acestea sunt în număr de nouă şi poartă numele: Abonaţi, DateDeContact, Contracte,
Abonamente, Tarife, Facturi, NumereTelefon, Servicii, CartelePrepay.

Comenzile de creare şi interogare a bazei de date se vor da în linie de comandă. Acest lucru se poate face prin
accesarea SQL -> SQL Commands -> Enter command.

Sintaxa comenzii SQL de creare a tabelelor în Oracle este:

CREATE TABLE [schema.]nume_tabela

(nume_coloana_1 tip_coloana_1 [DEFAULT expresie_1],
nume_coloana_2 tip_coloana_2 [DEFAULT expresie_2],
. . .
nume_coloana_n tip_coloana_n [DEFAULT expresie_n]
);
unde:
 nume_tabela este numele tabelei care se crează;
 nume_coloana_1, nume_coloana_2, ... sunt numele coloanelor acesteia;
 tip_coloana_1, tip_coloana_2, ... reprezintă tipurile de date pentru coloanele respective, alese dintre cele
prezentate în paragraful anterior, cu specificarea, dacă este cazul, a dimensiunii maxime sau preciziei;
 clauza opţională DEFAULT expresie_i specifică o valoare implicită care este introdusă automat în acea
coloană în cazul în care la adăugarea unei noi linii nu se specifică o valoare pe coloana respectivă;
 schema este numele de utilizator Oracle al proprietarului noii tabele. Valoarea implicită pentru acesta
este numele utilizatorului care execută cererea de creare.

33
Observaţie. În sintaxa prezentată, nu au fost incluse contrângeri (de domeniu, de tuplu, constrângeri impuse de
dependenţe de date). Acestea se pot defini fie odată cu crearea tabelului, fie pot fi adăugate în tabel după ce
acesta a fost creat, folosind comanda SQL “ALTER TABLE ADD CONSTRAINT...”. Ambele situaţii vor fi
prezentate în cele ce urmează.

Comanda ALTER TABLE poate fi folosită în general pentru eventualele modificări ce se aduc într-un tabel.
Sintaxa pentru comanda SQL de modificare a tabelelor poate fi una din cele menţionate mai jos:

1. ALTER TABLE <nume_tabel> ADD <nume_coloana> <definitie_coloana>

2. ALTER TABLE <nume_tabel> MODIFY <nume_coloana> <definitie_coloana>
3. ALTER TABLE <nume_tabel> DROP <nume_coloana>
Unde :
 prima comandă se foloseşte în cazul în care se doreşte adăugarea unei coloane noi în tabel;
 cea de-a doua comandă este folosită pentru a modifica numele coloanei sau tipul de dată pe care aceasta
o reprezintă;
 cea de-a treia coloană este folosită în scopul de a şterge o anumită coloană.

Cum am menţionat mai sus există cazul în care se doreşte adăugarea constrângerilor după crearea tabelului.

Sintaxa pentru comanda de adăugare a cheii primare este:

ALTER TABLE <nume_tabel> ADD CONSTRAINT <nume_constrangere> PRIMARY KEY
(<coloana_cheie_primară>)
Unde:
 nume_constrangere reprezintă un nume arbitrar ales pentru constrângerea în cauză
 clauza PRIMARY KEY defineşte drept cheie primară coloana sau muţimea de coloane ce urmează
după aceasta.
 coloana_cheie_primară reprezintă numele coloanei (mulţimii de coloane) stabilită drept cheie primară.

Sintaxa pentru comanda de adăugare a cheii primare este:

ALTER TABLE <nume_tabel> ADD CONSTRAINT <nume_constrangere> FOREIGN KEY
(<coloana_cheie_straina> ) REFERENCES <nume_tabel_referit>(<coloana_referita>) ON DELETE
CASCADE/SET NULL
 nume_constrangere reprezintă un nume arbitrar ales pentru constrângerea referitoare la cheia străină.
 clauza FOREIGN KEY defineşte drept cheie străină coloana sau muţimea de coloane definită după
aceasta.
 coloana_cheie_straina reprezintă numele coloanei (mulţimii de coloane) stabilită drept cheie străină.
 clauza REFERENCES <nume_tabel_referit>(<coloana_referita>) identifică tabelul şi coloana referite.
 Cuvântul cheie ON DELETE CASCADE presupune că atunci când un rând este şters din tabelul referit,
rândul din tabelul ce referă va fi de asemenea şters. Fără acest cuvânt cheie sau fără cuvântul cheie ON
DELETE SET NULL (converteşte valorile cheii străine dependentă în NULL) rândul din tabelul referit
nu va putea fi şters.

3.2.1 Crearea tabelului Abonaţi

Tabelul Abonaţi reprezintă tabelul de identificare a abonaţilor companiei de telefonie mobilă. Aceasta va fi
cuprins din următoarele coloane: IdAbonat, Nume, Prenume, CNP. Cheia primară, care identifică în mod unic
tuplurile acestui tabel va fi IdAbonat. În acest tabel nu există chei externe. Printre alte constrângeri se va folosi
şi contrângerea de domeniu NOT NULL.

Comanda de creare a tabelei Abonaţi este:

34
CREATE TABLE Abonati (
IdAbonat NUMBER(10) NOT NULL,
Nume VARCHAR(45) NOT NULL ,
Prenume VARCHAR(45) NOT NULL ,
CNP NUMBER(13) NOT NULL );

Observaţii.

 Tipurile de date pentru atributele folosite sunt number și varchar(variable-length caracter data). Tipul de
dată number este folosit pentru codul de identificare a abonatului şi pentru CNP. Precizia acestuia
pentru atributul IdAbonat este de 10, în ideea că compania de telefonie mobilă are un număr
impresionant de abonaţi. Pentru CNP, numărul de cifre folosite este de 13, atât cât este şi lungimea unui
cod numeric personal.
Tipul de dată varchar reprezintă un şir de caractere de lungime variabilă, dimensiunea a fost aleasă
arbitrar 45 de caractere. Numărul maxim de carctere este de 4000, iar numărul minim 1 caracter.
Varchar a fost folosit pentru atributele nume şi prenume.

 Cheia primară nu a fost introdusă încă. Pentru a introduce în tabel cheia primară vom folosi o comanda
de alterare a tabelului, prin care vom adăuga contrângerea de cheie primară. Comanda este: ALTER
TABLE Abonati ADD CONSTRAINT pkAbonati PRIMARY KEY (IdAbonat)

35
  Dacă se doreşte se poate adăuga şi o cheie candidat folosind costrângerea UNIQUE. Dorim spre
exemplu ca atributul CNP să fie unic, prin urmare vom da comanda: ALTER TABLE Abonati ADD
CONSTRAINT uniqueCNP UNIQUE (CNP)

3.2.2. Crearea tabelului DateDeContact

Tabeluk DateDeContact reprezintă tabelul în care sunt detaliate datele de contact ale abonaţilor. Acesta va
cuprinde coloanele: IdContact, Adresă, Email, NumărTelefonDeContact şi IdAbonat. Cheia primară, care
identifică în mod unic tuplurile acestui tabel va fi IdContact.La fel ca şi în cazul precedent vom folosi
contrângerea de domeniu NOT NULL.

Comanda de creare a tabelului DateDeContact este:

CREATE TABLE DateDeContact (

IdContact NUMBER(10) NOT NULL,
Adresă VARCHAR(100) NOT NULL ,
Email VARCHAR(45) NOT NULL ,
NumărTelefonDeContact NUMBER(10) NOT NULL,
CONSTRAINT pkDateDeContact
PRIMARY KEY (IdContact) );

36
Observaţii.

 Tipurile de date folosite sunt varchar şi number

 Contrângerea cu privire la cheia primară a fost introdusă direct în comanda de creare a tabelului
DateDeContact.
 Între tabelul Abonaţi şi tabelul DateDeContact există o relaţie unul-la-unul definită prin cheia străină
IdAbonat din cadrul tabelului DateDeContact. Am uitat să adaug coloana IdAbonat. Prin urmare voi
folosi comanda: ALTER TABLE în felul următor

 Cheile străine vor fi introduse după ce au fost create toate tabelele pentru a nu întâmpina probleme.

3.2.3. Crearea tabelului Contracte

Tabelul Contracte reprezintă tabelul în care sunt înregistrate contractele dintre companie şi abonaţi. Coloanele
tabelei sunt următoarele: IdContract, DatăÎnceput, DatăSfârşit, IdAbonat, NumărTelefon, Coloana IdAbonat
identifcă abonatul, iar coloana NumărTelefon va identifica numărul de telefon pentru care a fost iniţiat
contractul. Acest ultim câmp va face legătura cu tabela NumereTelefon. Cele două coloane reprezintă chei

37
străine iar constrângerile pentru chei străine vor fi adăugate ulterior. Cheia primară a acestui tabel este
IdContract

Comanda de creare a tabelului Contracte este:

CREATE TABLE Contracte (

IdContract NUMBER(10) NOT NULL,
DataInceput DATE NOT NULL ,
DataSfarsit DATE NOT NULL ,
IdAbonat NUMBER(10) NOT NULL,
NumarTelefon NUMBER(10) NOT NULL,
CONSTRAINT pkContracte
PRIMARY KEY (IdContract) );

3.2.4. Crearea tabelului Facturi

Tabela Facturi reprezintă tabela ce deţine informaţiile referitoare la plăţile efectuate de către clienţi. În această
tabelă sunt stocate facturile clienţilor. Coloanele tabelei Facturi sunt următoarele: IdFactură, DataFacturare,
DataScadentă, TotalulDePlată, StarePlăţi, IdAbonat. Cheia primară pentru acest tabel va fi IdFactură, iar cheia
străină, ce va relaţiona tabelul Facturi cu tabelul Abonaţi va fi IdAbonat.
Comanda de creare a tabelului Contracte este:

CREATE TABLE Facturi (

IdFactura NUMBER(10) NOT NULL,
DataFacturare DATE NOT NULL ,
DataScadenta DATE NOT NULL ,
TotalulDePlata NUMBER(10) NOT NULL,
IdAbonat NUMBER(10) NOT NULL,
CONSTRAINT pkFacturi
PRIMARY KEY (IdFactura) );

38
3.2.5. Crearea tabelului Abonamente
Tabelul Abonamente conţine tipurile de abonamente oferite de compania de telefonie mobilă. Această tabelă
cuprinde coloanele: IdAbonament, TipAbonament, Cost, IdServiciu, IdTarif. Cheia primară a acestei tabele este
IdAbonament. Tabela se află într-o relaţie de tipul unul-la-multe cu tabela Servicii, asociere definită prin cheia
străină IdServiciu şi într-o relaţie unul-la-unul cu tabela Tarife, asociere definită prin cheia străină IdTarif. Se
poate defini de asemena o constrângere de tip UNIQUE în cazul atributului TipAbonament.

Comanda de creare a tabelului Abonamente este:

CREATE TABLE Abonamente (

IdAbonament NUMBER(10) NOT NULL,
TipAbonament VARCHAR(45) NOT NULL ,
Cost NUMBER(10) NOT NULL,
IdServiciu NUMBER(10) NOT NULL ,
CONSTRAINT pkAbonamente
PRIMARY KEY (IdAbonament) ,
CONSTRAINT uniqueAbonamente
UNIQUE (TipAbonament ) );

39
Observaţii.

 Am uitat să introduc coloana IdTarif. Pentru a introduce această coloană folosim comanda: ALTER
TABLE Abonamente ADD IdTarif NUMBER(10) NOT NULL;

3.2.6. Crearea tabelului Tarife

Tabela Tarife cuprinde tarifele standard pentru convorbiri în reţea sau în afara reţelei atât pentru abonamente
cât şi pentru cartele prepay. În această tabelă se regăsesc următorele coloane: IdTarif, Apeluri Reţea,
ApeluriExtraReţea, SMSReţea, SMSExtraReţea, MMSReţea, MMSExtraReţea, MesagerieVocală,
TraficInternet. Cheia primră, în acest caz, este IdTarif. Nu există chei străine.

Comanda de creare a tabelului Tarife este:

CREATE TABLE Tarife (

IdTarif NUMBER(10) NOT NULL,
ApeluriReţea NUMBER(5) NOT NULL ,
ApeluriExtraReţea NUMBER(5) NOT NULL,
SMSReţea NUMBER(5) NOT NULL ,
SMSExtraReţea NUMBER(5) NOT NULL,
MMSReţea NUMBER(5) NOT NULL,
MMSExtraReţea NUMBER(5) NOT NULL,
TraficInternet NUMBER(5) NOT NULL,
CONSTRAINT pkTarife
PRIMARY KEY (IdTarif) );

40
Observaţii.
 Am introdus din greşeală coloana MesagerieVocală. Pentru a scoate această coloană din tabel se
foloseşte următoarea comandă: ALTER TABLE Tarife DROP COLUMN MesagerieVocală;

3.2.7. Crearea tabelului NumereTelefon

Tabelul NumereTelefon cuprinde numerele de telefon date de operatorul de telecomunicaţii. Coloanele acestui
tabel sunt: NumarTelefon, IdAbonat, IdAbonament, IdPrepay. Atributul NumarTelefon reprezintă cheia
primară. Atributele IdAbonat, IdAbonament, IdPrepay reprezintă chei străine prin intermediul cărora se face
asocierea dintre tabela NumereTelefon şi tabelele Abonati, Abonamente şi CartelePrepay. Tabela
NumereTelefon reprezintă tabela intermediară în relaţia de tipul multe-la-multe dintre tabelele Abonati şi
Abonamente. Relaţia dintre aceasta şi tabela CartelePrepay este de tipul unul-la-unul. Aşa cum am mai
menţionat constrângerile pentru cheile străine vor fi introduse după ce au fost create toate tabelele.

Comanda de creare a tabelului NumereTelefon este:

CREATE TABLE NumereTelefon (

NumarTelefon NUMBER(10) NOT NULL,
IdAbonat NUMBER(10),
IdAbonament NUMBER(10),

41
IdPrepay NUMBER(10),
CONSTRAINT pkNumereTelefon
PRIMARY KEY (NumarTelefon) );

Observaţie.

 Pentru coloanele IdAbonat, IdAbonament, IdPrepay nu am mai pus contrângerea NOT NULL. Motivul
este acela că aceste câmpuri pot lua valoarea NULL atunci când un număr de telefon este asociat cu un
anumit tip de client (abonat, client prepay sau abonat cu cartela prepay). Aşa cum am exemplificat în
capitolele anterioare atributul IdPrepay poate lua valoarea NULL în cazul în care numărul de telefon
este asociat unui abonat care deţine abonamnetul X. Totodată, atributele IdAbonat şi IdAbonamenete
pot fi NULL atunci când numărul de telefon este asociat cu o cartelă prepay.

3.2.8. Crearea tabelului Servicii

Tabela Servicii reprezintă tabela cu informaţii referitoare la serviciile oferite de compania telecom. Aceasta
este alcătuită din următoarele coloane: IdServiciu, MinuteGratuite, SMSGratuite, MMSGratuite, Internet,
VideoCall, Roaming. Cheia primară este IdServiciu. Tabela nu prezintă chei străine.

Comanda de creare a tabelului Servicii este:

CREATE TABLE Servicii (

IdServiciu NUMBER(10) NOT NULL,
MinuteGratuite NUMBER(5) NOT NULL ,
SMSGratuite NUMBER(5) NOT NULL,
MMSGratuite NUMBER(5) NOT NULL ,
Internet VARCHAR(45) NOT NULL,
VideoCall VARCHAR(45) NOT NULL,
Roaming VARCHAR(45) NOT NULL,
CONSTRAINT pkServicii
PRIMARY KEY (IdServiciu) );

42
3.2.9. Crearea tabelului CartelePrepay
Tabela CartelePrepay reprezintă tabela ce cuprinde datele legate de cartele prepay. Coloanele acestei tabele sunt
următoarele: IdPrepay, SumaDisponibila, Valabilitate, VechimeInRetea, IdServiciu. Cheia primară ce identifică
unic tuplurile acestei tabele este IdPrepay. Cheia străină corespunzătoare relaţiei dintre această tabelă şi tabela
Servicii este IdServiciu.

Comanda de creare a tabelului CartelePrepay este:

CREATE TABLE CartelePrepay(

IdPrepay NUMBER(10) NOT NULL,
SumaDisponibila NUMBER(5) NOT NULL ,
Valabilitate DATE NOT NULL,
IdServiciu NUMBER(10) NOT NULL,
CONSTRAINT pkPrepay
PRIMARY KEY (IdPrepay) );

43
3.3. Introducerea constrângerilor Foreign Key (Cheie Străină)
Constrângerea FOREIGN KEY desemnează o coloană sau o combinaţie de coloane drept cheie străină şi
stabileşte legătura cu cheia primară sau unică din acelaşi tabel sau dintr-un tabel diferit.

3.3.1. Introducerea cheii străine IdAbonat în tabelul DateDeContact

Relaţia dintre tabelele Abonati şi DateDeContact este de tipul 1-1. Comanda pentru introducerea unei
constrângerii este: ALTER TABLE DateDeContact ADD CONSTRAINT fkContact FOREIGN KEY
(IdAbonat) REFERENCES Abonaţi(IdAbonat) ON DELETE CASCADE ;

Observaţii.

 Cuvântul cheie FOREIGN KEY defineşte coloana din tabelul ce referă cheie străină (În acest caz
IdAbonat)
 Cuvântul cheie REFERENCES identifică tabelul şi coloana referite (În acest caz Abonaţi(IdAbonat))
 Cuvântul cheie ON DELETE CASCADE presupune că atunci când un rând este şters din tabelul referit,
rândul din tabelul ce referă va fi de asemenea şters. Fără acest cuvânt cheie sau fără cuvântul cheie ON
DELETE SET NULL (converteşte valorile cheii străine dependentă în NULL) rândul din tabelul referit
nu va putea fi şters.

3.3.2. Introducerea cheilor străine IdAbonat, NumarTelefon în tabelul Contracte

Tabela Abonaţi cu tabela Contracte formează o asociere 1-n. Tabla NumereTelefon cu tabele contracte formează
o asociere 1-n. Comenzile pentru introducerea constrângerilor sunt:

ALTER TABLE Contracte ADD CONSTRAINT fkContractA FOREIGN KEY (IdAbonat)

REFERENCES Abonaţi(IdAbonat) ON DELETE CASCADE ;

ALTER TABLE Contracte ADD CONSTRAINT fkContractN FOREIGN KEY (NumarTelefon)

REFERENCES NumereTelefon(NumarTelefon) ON DELETE CASCADE ;

44
3.3.3. Introducerea cheii străine IdAbonat în tabelul Facturi
Tabela Abonaţi cu tabela Facturi se află într-o relaţie de tipul 1-n. Comanda pentru introducerea constrângerii
este: ALTER TABLE Facturi ADD CONSTRAINT fkFacturi FOREIGN KEY (IdAbonat)
REFERENCES Abonati(IdAbonat) ON DELETE CASCADE ;

45
3.3.4. Introducerea cheilor străine IdServiciu, IdTarif în tabelul Abonamente
Tabelul Servicii cu tabelul Abonamnete sunt asociate prin o relaţie de tipul 1-n. Tabelul Tarife cu tabelul
Abonamente sunt asociate prin o relaţie 1-1. Comenzile pentru introducerea constrângerilor sunt:

ALTER TABLE Abonamente ADD CONSTRAINT fkAbonamenteS FOREIGN KEY (IdServiciu)

REFERENCES Servicii(IdServiciu) ON DELETE CASCADE ;

ALTER TABLE Abonamente ADD CONSTRAINT fkAbonamenteT FOREIGN KEY (IdTarif)

REFERENCES Tarife(IdTarif) ON DELETE CASCADE ;

3.3.5. Introducerea cheilor străine IdAbonat, IdAbonament şi IdPrepay în tabelul NumereTelefon.

Între tabele Abonati şi Abonamente există o relaţie de tipul n-n. Prin urmare tabela NumereTelefon va fi tabela
de legătură. Între cele de două tabele şi tabela NumereTelefon există relaţii de tipul 1-n. Între tabela
CartelePrepay şi tabela NumereTelefon există o asociere 1-1. Comenzile pentru introducerea constrângerilor
sunt:
46
ALTER TABLE NumereTelefon ADD CONSTRAINT fkNumereTelefonAbonati FOREIGN KEY
(IdAbonat) REFERENCES Abonati(IdAbonat) ON DELETE CASCADE;

ALTER TABLE NumereTelefon ADD CONSTRAINT fkNumereTelefonAbonamente FOREIGN KEY

(IdAbonament) REFERENCES Abonamente(IdAbonament) ON DELETE CASCADE;

ALTER TABLE NumereTelefon ADD CONSTRAINT fkNumereTelefonP FOREIGN KEY (IdPrepay)

REFERENCES CartelePrepay(IdPrepay) ON DELETE CASCADE ;

47
3.3.6. Introducerea cheii străine IdServiciu în tabelul CartelePrepay
Între tabela Servicii şi tabela CartelePrepay există o relaţie de tipul 1-n. Comanda pentru introducerea
constrângerii este: ALTER TABLE CartelePrepay ADD CONSTRAINT fkCartelePrepay FOREIGN
KEY (IdServiciu) REFERENCES Servicii(IdServiciu) ON DELETE CASCADE ;

3.4. Introducerea datelor în tabele

Pasul cu numărul patru în implementarea bazei de date este popularea tabelelor cu date

Vom insera mai întâi datele în tabelele care nu conţin chei străine pentru a evita orice neconcordanţe. Aceste
tabele sunt Abonaţi, Servicii şi Tarife.

3.4.1. Introducerea datelor în tabela Abonaţi

Pentru a introduce date, în oricare tabelă vom folosi comanda INSERT. Sintaxa comenzii SQL de
inserare a datelor într-un tabel este: INSERT INTO tabela [(coloana1, coloana 2)] VALUES (valoarel,
valoare2, .. ).

În momentul inserării datelor, trebuie respectate următoarele reguli:

48
  Coloanele pot fi specificate în orice ordine, însă trebuie asigurată corespondenţta între coloane şi
valorile furnizate iar coloanelor nespecificate le va fi ataşată valoarea Null;
 În cazul în care coloanele nu sunt specificate explicit, se impune sa fie specificate valori pentru toate
coloanele şi ordinea acestor valori să coincidă cu cea în care coloanele au fost definite la crearea
tabelei;
 Valorile trebuie sa aibă acelaşi tip de dată ca şi câmpurile în care sunt adăugate;
 Dimensiunea valorilor introduse trebuie sa fie mai mică sau cel mult egală cu dimensiunea coloanei (un
şir de 20 de caractere nu poate fi adăugat într-o coloană cu dimensiunea de 15 caractere);
 Valorile introduse trebuie să respecte restricţiile de integritate definite la crearea tabelei (de exemplu,
câmpuri definite ca NOT NULL sau UNIQUE).

Pentru a vedea rezultatul comnzii de inserare vom folosi comanda SELECT * FROM nume_tabel, comandă ce
are ca rezultat selecţia tuturor tuplurilor din cadrul tabelului. Operatorul * este folosit pentru a simboliza toate
coloanele ce alcătuiesc tabelul . Prin urmare se vor selecta valorile din tabel pentru toate coloanele acestuia.

În acest caz specific, pentru a introduce date în tabela Abonaţi folosim comanda:

INSERT ALL
INTO Abonati (IdAbonat, Nume, Prenume, CNP) VALUES ('1', 'Popescu', 'Andreea',
'2881218180051')
INTO Abonati (IdAbonat, Nume, Prenume, CNP) VALUES ('2', 'Vișan', 'Luiza',
'2900624030155')
INTO Abonati (IdAbonat, Nume, Prenume, CNP) VALUES ('3', 'Barb', 'Răzvan',
'1830415232254')

SELECT 1 FROM DUAL

Pentru a verifica introducerea corectă a datelor în tabelul Abonaţi vom folosi comanda: SELECT * FROM
Abonati. Rezultatul rulării comenzii este redat în imaginea de mai jos. Se poate observa ca datele au fost corect
introduse.

49
3.4.2. Introducerea datelor în tabela Servicii
Introducerea datelor în tabela Servicii se execută utilizând comanda:

INSERT ALL
INTO Servicii (IdServiciu, MinuteGratuite, SMSGratuite, MMSGratuite, Internet,
VideoCall, Roaming) VALUES ('1', '100', '100', '10', 'Activ', 'Inactiv', 'Inactiv')
INTO Servicii (IdServiciu, MinuteGratuite, SMSGratuite, MMSGratuite, Internet,
VideoCall, Roaming) VALUES ('2', '150', '50', '5', 'Activ', 'Inactiv', 'Activ')
INTO Servicii (IdServiciu, MinuteGratuite, SMSGratuite, MMSGratuite, Internet,
VideoCall, Roaming) VALUES ('3', '1000', '1000', '100', 'Activ', 'Activ', 'Activ')
INTO Servicii (IdServiciu, MinuteGratuite, SMSGratuite, MMSGratuite, Internet,
VideoCall, Roaming) VALUES ('4', '500', '250', '20', 'Activ', 'Activ', 'Inactiv')
INTO Servicii (IdServiciu, MinuteGratuite, SMSGratuite, MMSGratuite, Internet,
VideoCall, Roaming) VALUES ('5', '100', '100', '10', 'Activ', 'Inactiv', 'Activ')
INTO Servicii (IdServiciu, MinuteGratuite, SMSGratuite, MMSGratuite, Internet,
VideoCall, Roaming) VALUES ('6', '50', '50', '0', 'Inactiv', 'Inactiv', 'Inactiv')
SELECT 1 FROM DUAL

50
 Pentru a verifica introducerea corectă a datelor în tabelul Servicii vom folosi comanda: SELECT * FROM
Servicii. Rezultatul rulării comenzii se poate observa în imaginea de mai jos.

3.4.3. Introducerea datelor în tabela Tarife

Introducerea datelor în tabela Tarife se execută folosind comanda:

INSERT ALL
INTO Tarife (IdTarif , Apeluri Reţea, ApeluriExtraReţea, SMSReţea, SMSExtraReţea,
MMSReţea, MMSExtraReţea, TraficInternet) VALUES ('1','5', '7', '3', '5', '10', '20', '10')

INTO Tarife (IdTarif , Apeluri Reţea, ApeluriExtraReţea, SMSReţea, SMSExtraReţea,

MMSReţea, MMSExtraReţea, TraficInternet) VALUES ('2','5', '5', '5', '5', '10', '15', '10')

INTO Tarife (IdTarif , Apeluri Reţea, ApeluriExtraReţea, SMSReţea, SMSExtraReţea,

MMSReţea, MMSExtraReţea, TraficInternet) VALUES ('3','2', '10', '2', '10', '5', '25', '10')

INTO Tarife (IdTarif , Apeluri Reţea, ApeluriExtraReţea, SMSReţea, SMSExtraReţea,

MMSReţea, MMSExtraReţea, TraficInternet) VALUES ('4','7', '7', '7', '7', '10', '20', '5')

INTO Tarife (IdTarif , Apeluri Reţea, ApeluriExtraReţea, SMSReţea, SMSExtraReţea,

MMSReţea, MMSExtraReţea, TraficInternet) VALUES ('5','5', '10', '5', '10', '20', '25', '10')

INTO Tarife (IdTarif , Apeluri Reţea, ApeluriExtraReţea, SMSReţea, SMSExtraReţea,

MMSReţea, MMSExtraReţea, TraficInternet) VALUES ('6','5', '5', '5', '5', '5', '10', '15')

SELECT 1 FROM DUAL

51
Rezultatul inserării poate fi observat în imaginea de mai jos:

3.4.4. Introducerea datelor în tabela DateDeContact

Pentru a insera date în tabela de contact, trebuie mai întâi să populăm tabela pe care o referă, şi anume
Abonaţi. Cum acest lucru a fost înfăptuit într-o etapa anterioară, se poate continua cu introducerea datelor în
tabelul în cauză. În caz contrar,introducerea datelor în tabelul DateDeContact nu ar fi fost posibilă, având în
vedere faptl că acest tabel conţine un câmp ce referă tabelul Abonaţi şi ale cărui valori trebuie să coincidă cu
valorile din tabelul respectiv. Acesta este şi motivul pentru care s-a preferat popularea cu date a tabelelor ce nu
deţin chei străine.

52
 Comanda pentru introducerea datelor în tabela DateDeContact este:

INSERT ALL
INTO DateDeContact (IdContact, Adresă, Email, NumărTelefonDeContact , IdAbonat)
VALUES ('1', ' Str. Aleea Plopilor ', ' andreea.popescu@yahoo.com ', '0740000886', '1')
INTO DateDeContact (IdContact, Adresă, Email, NumărTelefonDeContact, IdAbonat)
VALUES ('2', ' Bld. Iuliu Maniu nr 50 ', ' luiza.vișan@yahoo.com ', '0731218414', '2')
INTO DateDeContact (IdContact, Adresă, Email, NumărTelefonDeContact, IdAbonat)
VALUES ('3', ' Str. Clucerului ', ' razvan.barb@yahoo.com ', '0768900001', '3')

SELECT 1 FROM DUAL

Rezultatele inserării sunt următoarele:

Observaţie. În imaginea de mai sus se poate vedea că cifra 0 din faţa numărului de telefon nu apare. Acest lucru
se datorează faptului că atributul NumarTelefonContact a fost definit ca tip de dată number, iar SGBD a
considerat că cifra 0 în faţa unui număr este irelevantă. Pentru a evita acest lucru coloana NumarTelefonContact
ar fi trebuit definita drept tip de date caracter. Pentru a nu complica lucrurile, tipul de data în acest exemplu şi în
53
exemplele ce vor urma nu vor fi modificate, întrucât nu este vorba de o bază de date reală, ci doar de un
exemplu teoretic.

3.4.5. Introducerea datelor în tabela Facturi

În tabela Facturi ar trebui să existe câte o înregistrare cu informaţii privitoare la factura unui abonat
pentru fiecare lună de când acesta beneficiază de serviciile companieie de telefonie mobilă. Acest lucru implică
o cantitatea mare de informaţii ce ar trebui să fie introduse în tabelă. Cum scopul lucrării nu este de a introduce
date într-o tabelă, nu vom introduce decât câteva înregistrări în tabela Facturi pentru a le folosi apoi în operaţii
viitoare.

INSERT ALL
INTO Facturi (IdFactura, DataFacturare, DataScadenta, TotalulDePlata, IdAbonat)
VALUES ('1', ' 10/09/2014', ' 20/09/2014', '10', '1')

INTO Facturi (IdFactura, DataFacturare, DataScadenta, TotalulDePlata, IdAbonat)

VALUES ('2', ' 10/10/2014', ' 20/10/2014', '6', '1')

INTO Facturi (IdFactura, DataFacturare, DataScadenta, TotalulDePlata, IdAbonat)

VALUES ('3', ' 10/10/2014', ' 20/10/2014', '6', '2')

SELECT 1 FROM DUAL

Rezultatul inserării este:

54
Observaţie. Pentru a pune în evidenţă, totuşi, tipul de relaţie dintre tabele Abonaţi şi tabela Facturi (1-n) s-a
considerat introducerea unei înregistrări pentru o factură anterioară corespunzătoare abonatului cu Id 1. Prin
urmare, în acest exemplu acest abonat deţine 2 facturi, cea din luna curentă şi cea din luna anterioară, conturând
astfel ideea de relaţie unul-la-multe.

3.4.6. Introducerea datelor în tabela Abonamente

Pentru a introduce date în tabelul Abonamente este necesară completarea tabelelor Servicii şi Tarife. Comanda
de inserare în tabelul Abonamente va fi:

INSERT ALL
INTO Abonamente (IdAbonament, TipAbonament, Cost, IdServiciu, IdTarif) VALUES
('1', 'VoceNational ', '6', '1', '2')
INTO Abonamente (IdAbonament, TipAbonament, Cost, IdServiciu, IdTarif) VALUES
('2', 'VoceReţea ', '6', '2', '3')
INTO Abonamente (IdAbonament, TipAbonament, Cost, IdServiciu, IdTarif) VALUES
('3', 'VoceStandard ', '6', '1', '1')
INTO Abonamente (IdAbonament, TipAbonament, Cost, IdServiciu, IdTarif) VALUES
('4', 'VoceExcelent', '25', '3', '5')
INTO Abonamente (IdAbonament, TipAbonament, Cost, IdServiciu, IdTarif) VALUES
('5', 'VoceInternet', '15', '4', '4')
INTO Abonamente (IdAbonament, TipAbonament, Cost, IdServiciu, IdTarif) VALUES
('6', 'VoceMini', '4', '6', '6')
SELECT 1 FROM DUAL

55
 Rezultatul comenzii este următorul:

Observaţie. La fel ca în exemplul teoretic folosit pentru a pune în evidenţă relaţiile dintre tabelele Abonaţi,
Servicii şi Tarife se poate observa că tipul de relaţie este respectat. În cazul relaţiei 1-1 dintre tabelele
Abonamnete şi Tarife observăm că toate valorile pentru IdTarif din tabelul tarife corespund abonamnetelor în
cauză, fiecărui tip de abonamnet fiindu-i asociat un tip de tarif. Relaţia dintre Abonamnete şi Servicii (n-1) este
de asemenea evidenţiată în acest exemplu. Se poate observa că abonamnetele cu Id-urile 1 şi 3 dispun de acelaşi
tip de serviciu (IdServiciu 1).

56
3.4.7. Introducerea datelor în tabela CartelePrepay
Comanda de introducere a datelor în tabela Prepay este:

INSERT ALL
INTO CartelePrepay (IdPrepay, SumaDisponibila, Valabilitate, IdServiciu) VALUES ('1',
'5 ', '10/12/2014', '1')
INTO CartelePrepay (IdPrepay, SumaDisponibila, Valabilitate, IdServiciu) VALUES ('2',
'10 ', '10/01/2015', '2')
INTO CartelePrepay (IdPrepay, SumaDisponibila, Valabilitate, IdServiciu) VALUES ('3',
'15', '11/02/2015', '1')
INTO CartelePrepay (IdPrepay, SumaDisponibila, Valabilitate, IdServiciu) VALUES ('4',
'7', '25/12/2014', '5')
INTO CartelePrepay (IdPrepay, SumaDisponibila, Valabilitate, IdServiciu) VALUES ('5',
'6', '17/03/2015', '4')
INTO CartelePrepay (IdPrepay, SumaDisponibila, Valabilitate, IdServiciu) VALUES ('6',
'2', '24/02/2015', '6')
SELECT 1 FROM DUAL

Rezultatul inserării este următorul:

57
3.4.8. Introducerea datelor în tabela NumereTelefon
Comanda de introducere a datelor în tabelul NumereTelefon este:

INSERT ALL
INTO NumereTelefon (NumarTelefon, IdAbonat, IdAbonament) VALUES ('0771502506', '2', '1')
INTO NumereTelefon (NumarTelefon, IdAbonat, IdAbonament) VALUES ('0771771177', '1', '1')
INTO NumereTelefon (NumarTelefon, IdAbonat, IdAbonament) VALUES ('0771956525', '2', '3')
INTO NumereTelefon (NumarTelefon, IdAbonat, IdAbonament) VALUES ('0771897887', '3', '2')
INTO NumereTelefon (NumarTelefon, IdAbonat, IdAbonament) VALUES ('0771056978', '4', '3')
INTO NumereTelefon (NumarTelefon, IdAbonat, IdAbonament) VALUES ('0771322884', '5', '4')
INTO NumereTelefon (NumarTelefon, IdAbonat, IdAbonament) VALUES ('0771156982', '6', '5')
INTO NumereTelefon (NumarTelefon, IdAbonat, IdAbonament) VALUES ('0771568456', '7', '4')
INTO NumereTelefon (NumarTelefon, IdAbonat, IdAbonament) VALUES ('0771458596', '8' , '6')
INTO NumereTelefon (NumarTelefon, IdAbonat, IdAbonament) VALUES ('0771051122', '9', '6')
INTO NumereTelefon (NumarTelefon, IdAbonat, IdAbonament) VALUES ('0771063222', '10', '2')
INTO NumereTelefon (NumarTelefon, IdAbonat, IdPrepay) VALUES ('0775001122', '1','1')
INTO NumereTelefon (NumarTelefon, IdPrepay) VALUES ('0775256232','2')
INTO NumereTelefon (NumarTelefon, IdAbonat, IdPrepay) VALUES ('0775215669', '10','3')
INTO NumereTelefon (NumarTelefon, IdAbonat, IdPrepay) VALUES ('0775693256', '4', '4')
INTO NumereTelefon (NumarTelefon, IdPrepay) VALUES ('0775214522','5')
INTO NumereTelefon (NumarTelefon, IdPrepay) VALUES ('0755423562','6')
SELECT 1 FROM DUAL

Observaţii. Numerele de telefon sunt asociate fie unui abonat cu abonament şi atunci nu s-a inserat nici o
valoare în tabel pentru câmpul IdPrepay, fie unei cartele prepay, şi atunci nu s-au inserat valori pentru câmpurile
IdAbonat şi IdAbonament sau fie unui abonat care deţine şi cartelă prepay caz în care nu s-au inserat valori
pentri IdAbonament. Abonaţii care deţin cartele prepay sunt abonaţii cu IdAbonat 1, 4 şi 10.Totodată un abonat
poate avea mai multe numere de telefon folosind pentru acestea abonamente diferite sau identice. Abonatul cu
IdAbonat 2 deţine două numere de telefon respectiv două abonamente diferite. Rezultatul inserării va fi:

58
3.4.9 Introducerea datelor în tabela Contracte
Comanda pentru inserarea datelor în tabela Contracte este:

INSERT ALL
INTO Contracte (IdContract, DataInceput, DataSfarsit, IdAbonat, NumarTelefon) VALUES ('1',
'03/03/2014', '03/03/2016', '2', '0771502506')
INTO Contracte (IdContract, DataInceput, DataSfarsit, IdAbonat, NumarTelefon) VALUES ('2',
'03/03/2014', '03/03/2016', '2' , '0771956525')
INTO Contracte (IdContract, DataInceput, DataSfarsit, IdAbonat, NumarTelefon) VALUES ('3',
'05/07/2014', '05/07/2016', '1' , '0771771177')
INTO Contracte (IdContract, DataInceput, DataSfarsit, IdAbonat, NumarTelefon) VALUES ('4',
'24/05/2014', '24/05/2016', '3' , '0771897887')
INTO Contracte (IdContract, DataInceput, DataSfarsit, IdAbonat, NumarTelefon) VALUES ('5',
'24/05/2012', '23/05/2014', '3' , '0771897887')
INTO Contracte (IdContract, DataInceput, DataSfarsit, IdAbonat, NumarTelefon) VALUES ('6',
'03/03/2014', '03/03/2016', '4' , '0771056978')
INTO Contracte (IdContract, DataInceput, DataSfarsit, IdAbonat, NumarTelefon) VALUES ('7',
'03/07/2014', '03/07/2016', '5', '0771322884')
INTO Contracte (IdContract, DataInceput, DataSfarsit, IdAbonat, NumarTelefon) VALUES ('8',
'03/09/2014', '03/09/2016', '6', '0771156982')
INTO Contracte (IdContract, DataInceput, DataSfarsit, IdAbonat, NumarTelefon) VALUES ('9',
'17/03/2014', '18/04/2016', '7' , '0771568456')
INTO Contracte (IdContract, DataInceput, DataSfarsit, IdAbonat, NumarTelefon) VALUES ('10',
'24/02/2014', '24/02/2016', '8', '0771458596')
INTO Contracte (IdContract, DataInceput, DataSfarsit, IdAbonat, NumarTelefon) VALUES ('11',
'11/02/2014', '10/02/2016', '9', '0771051122')
INTO Contracte (IdContract, DataInceput, DataSfarsit, IdAbonat, NumarTelefon) VALUES ('12',
'20/12/2014', '17/12/2016', '10', '0771063222')
SELECT 1 FROM DUAL

59
 Rezultatul inserării va fi:

3.5. Crearea vederilor

O vedere este în esenţă o relaţie virtuală care nu este de fapt de sine stătătoare, ci este derivată în mod
dinamic din una sau mai multe relaţii de bază. O vedere are aspectul unui tabel continând coloane si linii care
pot fi actualizate si în care se pot efectua inserări sau eliminări .O vedere este de fapt un tabel logic care nu
stocheaza date. Ea îsi preia datele din tabelele sau vederile pe care se bazează. Toate operaşiile efectuate asupra
unei vederi afecteaza practic tabelele de bază ale vederii.

O vedere este creata folosind o interogare şi prin urmare poate fi privită ca fiind un tabel virtual sau o
interogare stocată.Vederile sunt dinamice si afiseaza întotdeauna informatiile curente ale tabelelor. Atunci când
tabelele vederii sunt manipulate, aceste modificari sunt reflectate instantaneu în vedere.

Vederile permit sa afişarea datelor într-o formă diferită de cea în care sunt stocate în tabele. Vederile permit
adaptarea prezentării datelor în conformitate cu cerinţele specifice ale diverselor tipuri de utilizatori.

60
În general, vederile sunt create în urmatoarele scopuri:

 Pentru a asigura un nivel mai înalt de securitate al bazei de date prin restrângerea accesului la un
număr predeterminat de coloane şi linii ale unui tabel. Acest lucru permite utilizatorilor sa vadă un
subset restrâns al datelor.
 Pentru simplificarea prezentării datelor prin ascunderea structurilor reuniunilor şi tabelelor care
stau la baza vederii.
 Pentru afişarea datelor într-o altă reprezentare decât cea a tabelelor de bază.

Pentru a crea o vedere, se foloseşte comanda SQL CREATE VIEW. O vedere se poate defini folosind orice
interogare care face referire la tabele sau alte vederi. Sintaxa pentru crearea unei vederi este următoarea:

CREATE VIEW nume_vedere AS

SELECT coloana1, coloana2, coloana3,..., coloanai
FROM nume_tabel1, nume_tabel2, ..., nume_tabeli
WHERE <condiţie>
Unde
 CREATE VIEW nume_vedere este comanda de creare a vederii cu numele nume_vedere.
 Cuvântul cheie AS face referire la modul în care vederea va fi contruită
 SELECT coloana1, coloana2, coloana3,..., coloanai este comanda de selcţie a coloanelor care se doresc
a face parte din vedere. Aceste coloane pot aparţine mai multor tabele. În cazul în care două coloane ce
fac parte din tabele diferite au acelaşi nume, acestea vor fi diefernţiate prin adăugarea numelui tabelului
in fata numelui coloanei. Spre exemplu nume_tabel1.coloana1.
 FROM nume_tabel1, nume_tabel2, ..., nume_tabeli este comanda prin care se identifică tabelele care
vor contribui la crearea vederii
 WHERE <condiţie> reprezintă condiţia care se pune asupra înregistrărilor tabelei.

Înlocuirea vederilor

Pentru a modifica definitia unei vederi, vederea trebuie înlocuita. Vederile pot fi înlocuite în doua moduri:

 Vederea poate fi distrusă şi apoi recreată cu noua definiţie.

 Vederea poate fi recreatăprin redefinirea ei cu instrucţiunea CREATE VIEW cu clauza opţională OR
REPLACE. Această metodă este folosită pentru înlocuirea definiţiei curente a unei vederi .

Utilizarea vederilor

Vederile sunt tratate similar cu tratarea tabelelor în instructiunile SQL. Adică, pentru a interoga o vedere se
foloseşete tot instrucţiunea select. Exemeplu: SELECT coloana1, coloana2 FROM nume_vedere. Pentru a insera
o valoare în vedere se foloseşte instrcţiunea INSERT, ca şi la tabele. Exemplu INSERT INTO nume_vedere
VALUES (...)

Utilizarea vederilor face obiectul urmatoarelor limitări:

 Nu se poate folosi o vedere pentru a efectua operatii de inserare , actualizare sau ştergere atunci când
interogarea vederii conţine o operatie JOIN, operatorii SET sau DISTINCT, o clauza GROUP BY sau o
functie GROUP.
 Nu se poate utiliza o vedere definită cu clauza WITH CHECK OPTION pentru a insera sau a actualiza
tabelele de bază.
 Nu pot fi inserate linii în tabele utilizând o vedere care a fost creată folosind expresia DECODE.

61
 Dezavantajul utilizării unei vederi este că aceasta adaugă unul sau mai multe nivele de procesare atunci când
un utilizator interoghează sau manipulează datele prin intermediul vederii. Utilizarea vederilor necesită un timp
suplimentar de procesare înainte ca datele sa fie citite, reducând puţin viteza de raspuns a serverului Oracle.

Distrugerea vederilor

Pentru a distruge o vedere, se utilizează comanda DROP VIEW.

În continuare vom exemplifica procesul de creare a trei vederi. Prima vedere se referă la abonaţii/clienţii
prepay care sunt în Roaming, adica cei care au în tabela Servicii Roamingul activ. A doua vedere va fi una
pentru clieţii care plătesc peste o anumită sumă, iar a treia va fi pentru clienţii care au o anumită vechime.

3.5.1. Crearea vederii cu clieţii în Roaming

Vederea pentru abonaţii care sunt în Roaming va purta numele AbonatiRoaming iar instrucţiunea de creare a
vederii este următoarea:

CREATE VIEW AbonatiRoaming AS

SELECT Abonati.IdAbonat, Abonati.Nume, Abonati.Prenume, NumereTelefon.NumarTelefon,
Abonamente.TipAbonament, Servicii.IdServiciu, Roaming
FROM Abonati, Abonamente, NumereTelefon, Servicii
WHERE Abonati.IdAbonat=NumereTelefon.IdAbonat AND
NumereTelefon.IdAbonament=Abonamente.IdAbonament AND Abonamente.IdServiciu=Servicii.IdServiciu
AND Roaming='Activ'

Pentru a vedea rezultatul vom folosi comanda SELECT * FROM AbonatiRoaming

Vederea pentru clienţii prepay care sunt în Roaming va purta numele PrepayRoaming iar instrucţiunea de
creare a vederii este următoarea:

CREATE VIEW PrepayRoaming AS

SELECT CartelePrepay.IdPrepay, NumereTelefon.NumarTelefon, Servicii.IdServiciu, Roaming
FROM CartelePrepay, NumereTelefon, Servicii
WHERE CartelePrepay.IdPrepay= NumereTelefon.IdPrepay AND CartelePrepay.IdServiciu=
Servicii.IdServiciu AND Roaming='Activ'

62
Rezultatul va putea fi vizualizat folosind comanda SELECT * FROM PrepayRoaming

Observaţii.

1. Utilitatea vederilor în cauză se poate deduce foarte uşor. În cazul în care doream sa vedem abonaţii care sunt
în roaming spre exemplu, ar fi trebuit să ne uităm mai întâi în tabeul Servicii pentru a vedea care din serviciile
oferite au valoarea pentru câmpul Roaming 'Activ'. Ar fi trebui apoi să ne uităm în tabela Abonamente pentru a
vedea care abonamente folosesc serviciile pentru care roamingul este activ. Apoi ar fi trebuit sa vizualizăm
tabela NumereTelefon pentru a vedea căror abonaţi le sunt alocate aceste aboanamente. Iar în final ar fi trebuit
sa vizualizăm tabela Abonaţi pentru a cunoaşte numele şi prenumele abonaţilor care satisfac această condiţie.
Ori în acest caz avem date despre abonatii cu tipurile de abonament deţinute şi codul serviciului utilizat ce sunt
în roaming folosind un simplă comandă de SELECT. Acelaşi lucru este valabil şi pentru clieţii preapay, chiar
daca în acest caz este mai simplu deoarece folosim doar 3 tabele CartelePrepay, NumereTelefon, Servicii, ideea
de bază este aceea ca avem acces la astfel de informaţii folosind o instructiune simpla de SELECT şi nu una aşa
complexă precum cea folosită la crearea vederii.

2. Intrucţiunea de interogarea a bazei de date folosită în crearea tabelelor este o instructiune destul de complexă.
Pentru a exemplifica modul de cocepere a unei astfel de comenzi alegem ca exemplu vederea AbonaţiRoaming
pentru care comanda de SELECT este:

SELECT Abonati.IdAbonat, Abonati.Nume, Abonati.Prenume, NumereTelefon.NumarTelefon,

Abonamente.TipAbonament, Servicii.IdServiciu, Roaming FROM Abonati, Abonamente, NumereTelefon,
Servicii WHERE Abonati.IdAbonat=NumereTelefon.IdAbonat AND NumereTelefon.IdAbonament =
Abonamente.IdAbonament AND Abonamente.IdServiciu = Servicii.IdServiciu AND Roaming='Activ';

Prima parte a comenzii selectează coloanele care se doresc a fi incluse în vedere. În acest caz, am considerat ca
id-ul abonatului, numele şi prenumele acestuia, numărul de telefon, tipul de abonament şi serviciul utilizat
împreună cu coloana Roaming din cadrul tabelului Servicii sunt suficiente pentru a avea informaţii legate de
abonaţii care sunt în roaming. Se observa că anumite coloane au în faţa lor numele tabelului din care fac parte.
Acest lucru este datorită faptului că anumite câmpuri se regăsesc în mai multe tabele, aşa cum este cazul

63
atributului IdServiciu, care este cheie primară pentru tabelul Servicii şi cheie externă pentru tabelul
Abonamente.

A doua parte a coemnzii începe cu cuvântul cheie FROM cu ajutorul căruia alegem tabelele din care am luat
coloanele şi care contribuie la relaţia dintre tabelele Abonaţi şi Servicii.

Cea de-a treia parte a instrucţiunii reprezintă condiţia impusă. Aşa cum am menţionat în prima observaţie
trebuie să vizualizăm potrivirile din cadrul fiecărui tabel. Pornim de la un capăt cu tabelul Abonaţi şi ajungem la
celălalt şi anume tabelul Servicii. Considerăm mai întâi aboanţii pentru care există înregistrări în tabela
NumereTelefon prin Abonati.IdAbonat=NumereTelefon.IdAbonat, la această condiţie se adaugă condiţia ca
aceşti abonaţi să aibă în tabela NumereTelefon abonamente prin AND NumereTelefon.IdAbonament =
Abonamente.IdAbonament, la acestea trebuie să se facă legătura dintre tabelele Abonamente şi Servicii AND
Abonamente.IdServiciu = Servicii.IdServiciu şi să se adauge condiţia finală AND Roaming='Activ'. Această
comandă reprezintă ceea ce se numeşte joncţiune naturală între tabele.

O joncţine naturală este în esenţă o relaţie care se obţine în felul următor: se calculează produsul cartezian al
celor doua relatii, din tuplurile produsului cartezian se selecteza acele tupluri care au valori egale pentru
atributele comune şi apoi se face proiecţia rezultatului pe mulţimea de atribute corespunzătoare tabelelor
participante. Produsul cartezian dintre două relaţii reprezintă concatenarea valorilor atributelor fiecărui tuplu
din prima relaţie cu valorile atributelor tuturor tuplurilor din a doua relaţie.

Comanda de interogare folosită în construcţia vederii PrepayRoaming este SELECT CartelePrepay.IdPrepay,

NumereTelefon.NumarTelefon, Servicii.IdServiciu, Roaming FROM CartelePrepay, NumereTelefon, Servicii
WHERE CartelePrepay.IdPrepay = NumereTelefon.IdPrepay AND CartelePrepay.IdServiciu =
Servicii.IdServiciu AND Roaming='Activ'.

La fel ca şi în cazul precedent coamanda reprezintă o jocţiune între tabelele CartelePrepay, NumereTelefon
şi Servicii. În acest caz tabelele în cauză sunt în relaţie directă, nemaifiind nevoie de tabele adiţionale
intermediare. Coloanele care intră în structura tabelei sunt IdPrepay, NumarTelefon, Servicii şi Roaming.
Puteam să creem vederea fără a mai folosi tabela NumereTelefon deoarece tabelele CartelePrepay şi Servicii
sunt într-o relaţie directă n:1. Am considerat însă că într-un asfel de caz ar putea exista situaţia în care şi
numărul de telefon ar fi necesar pentru cel care utilizează vederea. Condiţia impusă este la fel ca şi în cazul
precedent, clienţii prepay ce folosesc servicii pentru care roamingul este activ vor fi introduşi în vedere alături
de numărul de telefon corespunzător.

3.5.2. Crearea vederii cu clienţii care plătesc peste o anumită sumă.

În acestă secţiune vom crea două vederi, una pentru abonaţi iar cealalta pentru clienţi prepay în care vom
identifica acei clienţi care plătesc sau au plătit (în cazul prepay) pest suma de 10 euro.

În cazul abonaţilor se pot folosi 2 tabele, tabela Facturi sau tabela Abonamente. În tabela Facturi avem
informaţii privitoare la cât au plătit sau au de plată abonaţii. Această sumă este un total între costul
abonamentului şi eventualele cheltuieli suplimentare. În tabele Abonamente avem informarţii referitoare la
costul abonamentului. Deşi tabela Facturi cuprinde informaţii şi din tabela Abonamente vom exemplifica
ambele cazuri.

64
 Vederea pentru abonaţii care plătesc facturi cu suma de peste 7 Euro va fi creată folosind comanda
următoare:

CREATE OR REPLACE VIEW AbonatiPlati1 AS

SELECT Abonati.IdAbonat, Abonati.Nume, Abonati.Prenume, IdFactura, TotalulDePlata
FROM Abonati, Facturi
WHERE Abonati.IdAbonat=Facturi.IdAbonat AND TotalulDePlata>7

Vederea pentru abonaţii care plătesc abonamente cu suma de peste 7 Euro va fi creată folosind comanda
următoare:

CREATE OR REPLACE VIEW AbonatiPlati2 AS

SELECT Abonati.IdAbonat, Abonati.Nume, Abonati.Prenume, Abonamente.IdAbonament, TipAbonament,
Cost
FROM Abonati, NumereTelefon, Abonamente
WHERE Abonati.IdAbonat=NumereTelefon.IdAbonat AND
NumereTelefon.IdAbonament=Abonamente.IdAbonament AND Cost>7

65
 Rezulatul se observă folosind coamanda SELECT * FROM AbonatiPlati2.

În cazul clienţilor prepay, vom căuta acei clienţi care au în cont sume de peste 7 euro.

Vederea pentru clienţii prepay care au sume disponibile pe cartelele prepay de peste 7 Euro va fi creată
folosind comanda următoare:

CREATE VIEW PrepayPlati AS

SELECT CartelePrepay.IdPrepay, NumereTelefon.NumarTelefon, SumaDisponibilă
FROM CartelePrepay, NumereTelefon
WHERE CartelePrepay.IdPrepay= NumereTelefon.IdPrepay AND SumaDisponibila>7

66
Observaţii.

 Ca şi în cazul vederilor pentru clienţii din roaming pentru crearea acestor vederi s-au folosit
joncţiuni naturale.
 În cazul vederii AbonatiPlati1 am folosit o joncţiune simplă între tabelele Abonaţi şi Facturi
folosind ca atribute datele de identificare a abonatului şi cele pentru factură.
 În cazul vederii AbonaţiPlati2 am folosit o joncţiune între tabelele Abonaţi, Abonamente şi
NumereTelefon. Deşi nu am folosit nici o coloana din tabelul NumereTelefon, acest tabel era
necesar pentru a face legătura dintre Abonaţi şi Abonamente.
 În cazul vederii PrepayPlati am folosit o joncţiune naturală între tabelele Abonaţi şi NumereTelefon
pentru a avea în cadrul vederii informaţii legate de numărul de telefon al clientului prepay. Aceasta
nu era însă necesară, pentru a pune în eveidenţă clieţii care plătesc peste o anumită sumă se putea
folosi o instrucţiune de interogare simplă SELECT * FROM CartelePrepay WHERE
SumaDisponibila>7.

67
68
Concluzii

Scopul acestei lucrări este acela de a de a evidenţia conceptul teoretic al unei baze de date şi paşii necesari
în proiectarea şi crearea propriu-zisă a acesteia.

Baza de Date creată în cadrul acestui proiect se numeşte TELECOM şi poate fi folosită de un operator de
telefonie mobilă pentru o administrare uşoară şi rapidă a clienţilor. În construcţia bazei de date s-a pornit de la
cerinţele clienţilor referitoare la baza de date dorită, ca mai apoi să se continue cu proiectarea conceptuală,
logică şi fizică a acesteia. Accentul a fost pus în special pe entităţile bazei de date, atributele corespunzătoare şi
relaţiile dintre entităţi.

Implementarea fizică a bazei de date a fost realizată în mediul Oracle Database 11g Express Edition

69
Bilbliografie
Note de curs

70