Elemente Avansate de Baze de Date SC 2019-2020 - Sem5 - IE ID

Informatică economică
Elemente Avansate
de Baze de Date
III I
2019
CUPRINS
I. INFORMAŢII GENERALE................................................................................................................................. 4
I.1. DATE DE IDENTIFICARE ALE CURSULUI .................................................................................................................... 4
I.1.1. Date de identificare a titularului de curs .............................................................................................. 4
I.1.2. Date de identificare curs şi contact tutori ............................................................................................. 4
I.2. CONDIŢIONĂRI ŞI CUNOŞTINŢE PRERECHIZITE .......................................................................................................... 5
I.3. DESCRIEREA CURSULUI ...................................................................................................................................... 5
I.4. ORGANIZAREA TEMELOR DIN CADRUL CURSULUI ...................................................................................................... 5
I.5. MATERIALE BIBLIOGRAFICE OBLIGATORII ................................................................................................................ 6
I.6. MATERIALE ŞI INSTRUMENTE NECESARE PENTRU CURS .............................................................................................. 7
I.7. CALENDAR AL CURSULUI..................................................................................................................................... 7
I.8. POLITICA DE EVALUARE ŞI NOTARE ........................................................................................................................ 7
I.9. ELEMENTE DE DEONTOLOGIE ACADEMICĂ ............................................................................................................... 8
I.10. STUDENŢI CU DIZABILITĂŢI ................................................................................................................................ 8
I.11. STRATEGII DE STUDIU RECOMANDATE.................................................................................................................. 8
II. SUPORTUL DE CURS PROPRIU-ZIS ................................................................................................................. 9

II.1. CAPITOLUL 1 – FRAGMENTAREA BAZELOR DE DATE ................................................................................................. 9
II.1.1.1. Scopul şi obiectivele capitolului ..................................................................................................................... 9
II.1.1.2. Schema logică a capitolului ........................................................................................................................... 9
II.1.2. Conţinutul detaliat .............................................................................................................................10
Structura distribuită a organizaţiilor .......................................................................................................................... 10
Importanţa integrării datelor în aplicaţiile economice ................................................................................................ 10
Fragmentarea – partiţionarea ................................................................................................................................... 12
Fragmentarea orizontală........................................................................................................................................... 14
Fragmentarea verticală ............................................................................................................................................. 15
Fragmentarea – mixtă............................................................................................................................................... 17
Fragmentarea derivată ............................................................................................................................................. 18
Relaţii nefragmentate ............................................................................................................................................... 18
II.2. CAPITOLUL 2 – REPLICAREA ŞI ALOCAREA FRAGMENTELOR .......................................................................................22
II.2.1.1. Scopul şi obiectivele capitolului ................................................................................................................... 22
II.2.1.2. Schema logică a capitolului ......................................................................................................................... 22
Replicarea ................................................................................................................................................................ 22
Proiectarea alocării ................................................................................................................................................... 23
Alocarea fragmentelor verticale ................................................................................................................................ 25
Arhitectura de referinţă a unui SD ............................................................................................................................. 26
Principiile lui Date referitoare la SD ........................................................................................................................... 28
Prelucrarea distribuită a interogărilor........................................................................................................................ 29
Gestionarea distribuită a tranzacţiilor ....................................................................................................................... 30
II.2.3. Sumar ................................................................................................................................................32
II.2.4. Sarcini şi teme ce vor fi notate ...........................................................................................................32
II.2.5. Întrebări de evaluarea cunoştinţelor ..................................................................................................32
II.2.6. Bibliografie capitol .............................................................................................................................32
II.3. CAPITOLUL 3 – BAZE DE DATE OBIECTUALE ...........................................................................................................33
Argumente în favoarea modelului OO ....................................................................................................................... 33
Concepte teoretice privind paradigma OO................................................................................................................. 36
Aspecte referitoare la proiectarea BDOO................................................................................................................... 38
Reprezentarea relaţiilor structurale dintre obiecte .................................................................................................... 39
Dan-Andrei Sitar-Tăut (Anul univ. 2019-2020) Elemente avansate de baze de date

Proiectarea comportamentală .................................................................................................................................. 41
Comparaţii între modelul OO şi R .............................................................................................................................. 42
Elemente de SGBDOO ............................................................................................................................................... 44
Manifestul sistemelor BDOO ..................................................................................................................................... 45
Dezvoltarea de sisteme SGBDOO .............................................................................................................................. 46
Gestiunea tranzacţiilor în sisteme SGBDOO ............................................................................................................... 47
Standarde legate de SGBDOO ................................................................................................................................... 48
Specificaţia CORBA (Common Request Object Arhitecture) ........................................................................................ 50
Modelul ODMG (Object Database Management Group) ............................................................................................ 50
Arhitectura sistemelor SGBDOO distribuite ............................................................................................................... 51
Avantajele şi dezavantajele sistemelor orientate-obiect............................................................................................. 52
Avantaje.............................................................................................................................................................. 53
Dezavantaje ........................................................................................................................................................ 54
Concluzii................................................................................................................................................................... 54
II.3.3. Sumar ................................................................................................................................................57
II.4. CAPITOLUL 4 – BAZE DE DATE OBIECTUAL RELAŢIONALE ŞI ALTE TIPURI DE BAZE DE DATE ................................................58
Consideraţii generale asupra SGBDOR ....................................................................................................................... 58
Manifeste ale BD ...................................................................................................................................................... 60
Extensii O în cadrul sistemelor OR ............................................................................................................................. 62
Standardul SQL3 ....................................................................................................................................................... 63
Alte baze de date..........................................................................................................................................64
Big Data.................................................................................................................................................................... 64
Bazele de date NoSQL ............................................................................................................................................... 65
Concluzii .......................................................................................................................................................66
II.4.3. Sumar ................................................................................................................................................67
II.5. CAPITOLUL 5 – MONGODB ..............................................................................................................................69
Consideraţii generale asupra bazelor de date NoSQL ................................................................................................. 69
MogoDB - Introducere .............................................................................................................................................. 72
Instalare MongoDB ................................................................................................................................................... 74
CRUD........................................................................................................................................................................ 79
II.5.3. Sumar ................................................................................................................................................82
III. ANEXE ..........................................................................................................................................................85
III.1. BIBLIOGRAFIA COMPLETĂ A CURSULUI ................................................................................................................85
III.2. SCURTĂ BIOGRAFIE A TITULARULUI DE CURS .........................................................................................................86

I. INFORMAŢII GENERALE
I.1. Date de identificare ale cursului
I.1.1. Date de identificare a titularului de curs
Nume: Conf. dr. Sitar-Tăut Dan-Andrei

Cabinet: str. Th. Mihali, Nr. 58-60, Cluj-Napoca, Cabinet 432/Laborator 441
Telefon: 0264-418652
Fax: 0264-412570
E-mail: dan.sitar@econ.ubbcluj.ro
Consultaţii: local - săptămânal marţi/miercuri ora 13:00 - 14:00 în timpul semestrului sau prin e-
mail în maxim 48 ore de la primirea mesajului
I.1.2. Date de identificare curs şi contact tutori
Numele cursului: Elemente avansate de baze de date

Codul cursului: ELR0096
Web: https://portal.portalid.ubbcluj.ro/
Anul, Semestrul: Anul III, Semestrul 1
Tipul cursului: Obligatoriu
Tutore: Conf. dr. Sitar-Tăut Dan-Andrei, dan.sitar@econ.ubbcluj.ro

I.2. Condiţionări şi cunoştinţe prerechizite
Acest curs, fiind continuarea unui alt curs de baze de date, presupune parcurgerea celui amintit,
intitulat Baze de Date în Economie din anul 2 semestrul 4.
Pentru acesta, precum şi pentru asimilarea unor cunoştinţe teoretice de bază în domeniu, se
recomandă conspectarea materialelor:
 S.Niţchi şi colectiv, Baze de date şi programarea aplicaţiilor economice, Editura Risoprint
Cluj-Napoca, 2007
 Date C.J., An Introduction to Data Bases, vol I şi II, Addison-Wesley, 2004; Baze de date
Teora, 2005 E+.
 T. Connolly, C. Begg, A. Strachan, Baze de date, Proiectare, Implementare, Gestionare,
Addison-Wesley, Toera, 2001.
I.3. Descrierea cursului
Cursul urmăreşte aprofundarea cunoştinţelor studenţilor referitoare la problemele bazelor de date,

precum şi la extensiile acestora. Acest curs este esenţial pentru orice specialist în domeniul
informaticii economice având în vedere faptul că nivelul organizării datelor stă la baza oricărei
construcţii informatice din domeniul economic. Cursul se axează pe câteva elemente majore:
 distribuirea bazelor de date;
 baze de date federative, element fundamental al organizaţiei virtuale;
 orientarea bazelor de date către obiectualitate;
 analiza multidimensională (depozite de date, OLAP şi OLTP);
 elemente de Big Data şi NoSQL.
I.4. Organizarea temelor din cadrul cursului
Cursul, conform normelor metodologice are 2 componente:

 componenta teoretică;
 componenta practică.
Parcurgerea componentei teoretice se realizează de către cursanţi. Elementele principale sunt

organizate pe 3 nivele:
 baze de date distribuite şi federative (primele 2 capitole);
 baze de date obiectuale şi obiectual-relaţionale (capitolele 3-4);
 elemente de NoSQL exemplificate în Mongo DB (capitolul 5).
Referitor la elementele de teorie cursanţii pot apela, pentru problemele de bază, la actualul syllabus
depus pe portal şi difuzat şi pe suport magnetic. Pentru o bibliografie mai detaliată poate recurge
la bibliografia din literatura în limba română, care este accesibilă la biblioteca departamentului,
facultăţii, dar şi la majoritatea bibliotecilor din ţară, iar pentru cea în limba engleză în special la
biblioteca Departamentului de Informatică Economică. Informaţii suplimentare se pot obţine şi
din site-uri aminitite în material.
Pentru partea practică, în cadrul suportului de curs sunt date exemple după care trebuie întocmite
proiectele. De asemenea, cursanţii pot participa la pregătiri periodice unde se discută aspectele
referitoare la proiecte, dar şi probleme de teorie cu un grad mai ridicat de dificultate.

I.5. Materiale bibliografice obligatorii
Sursele bibliografice obligatorii sunt:
 Pentru baze de date distribuite:

1. Date C.J., An Introduction to Data Bases, vol I şi II, Addison-Wesley, 2004; Baze de date
Teora, 2005 E+.
2. T. Connolly. C. Begg, A. Strachan, Baze de date, Proiectare, Implementare, Gestionare,
Addison-Wesley, Toera, 2001.
3. Ozsu M, Valduriez T., Principles of Distributed Database Systems, Prentice-Hall, 2003
4. Sitar-Tăut Dan-Andrei, Baze de date distribuite, Risoprint, 2005, p.159-175.
 Pentru orientarea obiectuală şi relaţional obiectuală

1. Abitaboul S., Hull R., Vianu V., Foundations of Databases, Addison-Wesley, 1998.
2. Date C., Darween J.H., Foundation for Future Database Systems. The Third Manifesto,
Addison Weslley, 2000
3. BDASEIG, Baze de date, Fundamente teoretice şi practice, Infomrga, 2002.
4. Sitar-Tăut Dan-Andrei, Baze de date distribuite, Risoprint, 2005
 Pentru NoSQL, Big Data, MongoDB

1. [Evans 2009] Eric Evans, NOSQL 2009. May 2009. – Blog post of 2009-05-12.
http://blog.sym-link.com/2009/05/12/nosql_2009.html
2. [Francis 2012] Matthew Francis, Future telescope array drives development of exabyte
processing. Future Square Kilometer Array telescopes will need new computing
technology, 2012, http://arstechnica.com/science/2012/04/future-telescope-array-drives-
development-of-exabyte-processing/
3. [IBM BigData] What is big data?, Big Data and the Speed of Business, http://www-
01.ibm.com/software/data/bigdata/what-is-big-data.html
4. [Strauch 2011] Strauch Christof, NoSQL Databases, Selected Topics on Software-
Technology, Ultra-Large Scale Sites, Cursul Computer Science and Media, Stuttgart
Media University, 2011
5. [Zikopoulos & Eaton 2011] Paul Zikopoulos, Chris Eaton. 2011. Understanding Big Data:
Analytics for Enterprise Class Hadoop and Streaming Data (1st ed.). McGraw-Hill
Osborne Media.
6. [Oracle 2012] Introduction to Oracle NoSQL Database, Documentaţie de firmă (D76115),
Oracle, 2012
7. [W3C Strozzi] Strozzi, Carlo: NoSQL – A relational database management system. 2007–
2010. – http://www.strozzi.it/cgi-bin/CSA/tw7/I/en_US/nosql/Home%20Page
8. [W3-Villa] What is Big Data? http://www.villanovau.com/university-online-
programs/what-is-big-data/
9. https://www.mongodb.com/nosql-explained?jmp=footer
10. https://docs.mongodb.com/manual/introduction/
11. M101P: MongoDB for Developers,
https://university.mongodb.com/courses/MongoDB/M101P/2016_May/syllabus

I.6. Materiale şi instrumente necesare pentru curs
Pentru curs este necesară conectarea cursanţilor la Internet, participarea la lecţiile de sinteză. În
privinţa soft-urilor, în general cursul este proiectat pe soft-uri gratuite, sau pentru care există licenţiere
academică. În acest sens:
 Oracle, Express Edition, în varianta academică poate fi obţinut de pe site-ul Oracle, cu
notificarea prealabilă a titularului de curs, totodată şi instructor Oracle Academy. Varianta
găzduită – Oracle Application Express – se va folosi în decursul semestrului, studentului
fiindu-i oferit un nume de utilizator şi o parolă implicită
 MongoDB, pentru baze de date tip document, se poate descărca şi instala de pe site-ul
companiei. La fel şi drivere pentru diverse limbaje de programare, precum PyMongo
 Python, limbaj de programare ce va fi utilizat pentru accesarea datelor din cadrul bazelor de
date MongoDB, se va descărca gratuit, la fel şi eventuale medii de dezvoltare ca PyCharm
I.7. Calendar al cursului
Calendarul va include ordinea în care vor fi abordate temele de curs, activităţile premergătoare
fiecărei teme (materiale ce trebuie parcurse în prealabil, exerciţii etc), lista tuturor activităţilor cu
datele acestora, sarcinile ce trebuie predate şi data la care vor fi predate, datele testelor
parţiale/evaluărilor pe parcurs şi a examenului final. Este foarte important să precizăm locaţia
activităţilor prezente în calendar precum şi ce aşteptări concrete avem de la studenţi pentru activitatea
în cauză. În cazul capitolelor de cărţi sau al articolelor este recomandat să precizăm şi numărul de
pagini pentru a oferi studenţilor oportunitatea să evalueze acurat timpul necesar parcurgerii acestora.
Datele testelor şi ale examenelor ar trebui să fie ferme şi să nu sufere modificări. În schimb, în cazul
calendarului de activităţi, este bine să menţionăm că acesta este unul orientativ şi susceptibil a fi
modificat. Orice modificare la nivelul calendarului trebuie anunţată cât mai din timp posibil cu un
interval minim de 48 de ore înaintea activităţii.
I.8. Politica de evaluare şi notare
Modul de evaluare a cursului:

50% din notă reprezintă răspunsurile la problemele teoretice;
50% din notă reprezintă partea practică.
Pentru partea teoretică, cursanţii vor da o lucrare scrisă de o oră. Intrebările şi răspunsurile se vor da
în format liber, câte o întrebare-două din fiecare capitol pentru a verifica gradul de înţelegere şi
însuşire a teoriei.
Pentru partea practică, cursanţii vor realiza:

Fie A) un proiect în care se va implementa în Oracle, utilizând Oracle Application Express,
baza de date proiectată la materia Baze de date în economie, se vor crea 2 proceduri stocate, 2
funcţii şi 2 declanşatori, toate obiectele fiind în strânsă legătură cu domeniul bazei de date.
Proiectul constă într-un document Word care să conţină o scurtă descriere a domeniului
modelat, a tabelelor şi a celorlalte tipuri de obiecte, comenzile de creare a tabelelor,
procedurilor, funcţiilor şi declanşatorilor; precum şi comenzile de populare a tabelelor, lansare
a fiecărui obiect creat şi prezentarea rezultatului returnat. Modalitatea de conectare la platforma
Oracle şi la documentaţia online va fi prezentată la întâlnirile din timpul semestrului.
Fie B):
 un proiect pe o bază de date MongoDB, preferabil partiţionată şi replicată. Prin
intermediul unei interfeţe web şi cu ajutorul unui limbaj de programare, să se realizeze
operaţii CRUD asupra bazei de date, într-o înlănţuire logică.
Tot codul şi explicaţiile să fie incluse într-un document Word sau OpenOffice.
Proiectul se va trimite prin intermediul platformei Moodle până la începutul sesiunii, urmând a fi
prezentat la ultima întâlnire sau după examen. Ponderea fazelor fiecărui proiect sunt precizate în
cadrul capitolelor.
I.9. Elemente de deontologie academică
Se aplică regulile generale de deontologie academică din UBB.
I.10. Studenţi cu dizabilităţi
În principiu pentru cursanţii cu dizabilităţi care nu se pot deplasa la sediul facultăţii se aplică 3 soluţii
esenţiale:
 deplasarea la nevoie a titularului de curs la cerinţa cursantului la locaţia unde se află acesta;
 utilizarea internet-ului şi a portalului după aceleaşi reguli ca la ceialalţi cursanţi;
 utilizarea la nevoie a unui sistem webcam şi skype la nevoie în cazul evaluărilor.
I.11. Strategii de studiu recomandate
În principiu în medie pentru înţelegerea conţinutului unui capitol sunt necesare minim 3 ore. Prezentul
curs fiind unul fundamental pentru orice specialist în informatică economică este necesar ca el să fie
studiat cu mare atenţie şi deci numărul de ore de studiu ar putea fi în funcţie de particularităţile
cursanţilor, mai mare sau mai mic.
Pentru proiecte timpul afectat ar putea fi substanţial mai mare. În cadrul site-urilor prezentate în cadrul
suportului de curs se găsesc exemple, tutoriale şi o diversitate de materiale ajutătoare.
II. SUPORTUL DE CURS PROPRIU-ZIS
II.1. Capitolul 1 – Fragmentarea bazelor de date
II.1.1.1. Scopul şi obiectivele capitolului
Scopul capitolului este familiarizarea cu avantajele şi dezavantajele fragmentării unei baze de date şi
tipurile de fragmentare. Această abordarea este importantă din cel puţin două motive:
 distribuirea activităţilor economice;
 utilizarea pe scară din ce în ce mai largă a intranet-ului unde datele se distribuie la nivelul
departamentului care le utilizează.
Obiectivele propuse:
 stabilirea diferenţei dintre bazele de date centralizate şi cele distribuite;
 cerinţele generale ale distribuirii;
 tipuri de fragmentare, avantajele şi dezavantajele acestora;
 complexitatea activităţii de fragmentare.
II.1.1.2. Schema logică a capitolului
Structura distribuită a organizaţiilor → distribuirea bazelor de date

↓
Fragmentarea – avantaje şi dezavantaje
↓
Condiţiile impuse fragmentării
↓
Fragmentarea orizontală
↓
Fragmentarea verticală
↓
Fragmentarea mixtă
↓
Fragmentarea derivată
II.1.2. Conţinutul detaliat
Elemente avansate de baze
Fragmentarea bazelor de date
de date
Structura distribuită a organizaţiilor
(5’ teorie)
Iniţial prelucrare distribuită – hibrid = sistemul cu prelucrare distribuită + un sistem centralizat de BD

→
 Punctele forte: integrarea aplicaţiilor şi datelor din organizaţie, simplitatea proiectării.
 Neajunsuri - accesul concurent, vulnerabilitatea şi disponibilitatea nodului central, număr
relativ scăzut de utilizatori şi accese concomitente; viteza scăzută, „distanţa” acceselor.
Primitive - sistemele centralizate - cotă destul de ridicată în implementările existente – pentru
„comunităţile informatice” de dimensiuni mici – decât SD

de date
Importanţa integrării datelor în aplicaţiile economice
(15’ teorie)
1: (Messaoui2001, DBASEIG2001, Popescu2001) BDD - colecţie de BD
integrate logic, însă repartizate fizic pe siturile unei reţele de calculatoare.
2: (Gardarin1999, DBASEIG2001) BDD - ansamblu de BD administrate de

diferite situri - pentru utilizator o BD unică → proiectate sub forma unor
colecţii de date integrate, omogene 1 / eterogene 2 , împrăştiate în reţea de
Definiţie
calculatoare – comportă ca BD globală.
Elemente importante:
 Integrarea logică - nu sunt simple colecţii de fişiere - o structură bine

organizată pe care utilizatorul – o percepe ca pe o BD globală, la fel ca şi
în cazul BD locale sau centralizate - (Date2005) bază de date „virtuală” cu
componentele stocate pe baze de date reale diferite;
 Repartizarea fizică - BD nu este stocată într-o singură locaţie -
De reţinut împărţită între mai multe staţii de lucru – (Date2005). Fiecare site este o
bază de date proprie, SGBD propriu, manager de comunicaţii proprii,
utilizatori locali.
Exemplul FSEGA sau a unei firme [Sitar2005].
Exemplu: SD într-o firmă:
Desfacere
Aprovizionare Contabilitate
BD
BD BD
Producţie
Marketing
Clienţi Management
BD
BD
BD BD
Obiectiv SGBDD [Sitar2005] - a face ca aplicaţiile să efectueze transparent diverse operaţii asupra
datelor împrăştiate în mai multe BD, gestionate de diverse SGBD-uri, pe platforme diferite, conectate
prin reţele de calculatoare de topologii diferite. SGBDD-ul - o extensie software şi funcţională a
SGBD locale.
SGBDD (Conolly2001) - sistemul software care permite gestiunea BDD,

făcând distribuirea fizică transparentă pentru utilizatori.
Definiţie
1
Majoritatea BDD sunt omogene; Primele în ‘70
2
Începând din ‘80
Aplicaţii locale şi globale; orice SGBDD – cel puţin o aplicaţie globală.
Atributele SGBDD:
 colecţia de date partajate, corelate logic

 fragmentare
 replicare – reproducerea fragmentelor
 site-uri legate prin reţea de calculatoare
 datele din fiecare site – sub controlul unui –SGBD
Citire  fiecare SGBD poate trata autonom datele
 fiecare SGBD participă la cel puţin o aplicaţie globală
Termeni de bază: fragmentare, alocare şi replicare.

de date
Fragmentarea – partiţionarea
(5’ teorie, 25’ practică)
Fragmentarea - procedeul de spargere a relaţiilor utilizate într-un SD prin

operaţiuni relaţionale de proiecţie şi selecţie controlate, pentru a plasa
fragmentele acolo unde sunt cel mai frecvent solicitate datele lor.
O abordare - prin divizarea tabelelor în unul sau mai multe fragmente

disjuncte, în scopul stocării fizice.
Definiţie
[Connolly] premisele de bază pentru fragmentare:
 Uzanţa - Aplicaţiile cu BD – multiutilizator – tabelele virtuale în

detrimentul relaţiilor - nu este nevoie de toate informaţiile, atât ca şi
structură, cât şi ca şi conţinut, pe care o relaţie întreagă este capabilă să le
furnizeze → unitatea atomică de proiectare şi utilizare nu va fi relaţia, ci o
subdiviziune a acesteia;
De reţinut  Eficienţa – Apropierea de locul utilizării şi eliminarea datelor care nu
sunt prelucrate local. Exemplu: corect - în situl X din Cluj - stochează relaţia ce conţine
materiile de studiu, iar pe nodul Y din Sighet relaţia care conţine datele de identificare a
tuturor studenţilor? Secretariatul din Cluj utilizează informaţiile studenţilor din Cluj; cel din
Sighet, informaţiile studenţilor din Sighet → Abordare normală - datele studenţilor din Cluj -
stocate pe situl X, a celor din Sighet în Y → plasăm datele unde sunt solicitate cel mai des;
 Paralelismul. Mai multe fragmente ale unei BD → sporirea accesului concurent - sistemul
poate răspunde în acelaşi timp la mai multe cereri. Exemplu: se răspunde mai repede unor
cereri lansate simultan, una de pe situl X şi una de pe Y, în cazul în care X solicită mediile
studenţilor din Cluj, iar Y ale celor din Sighet;
 Securitate - un atac asupra unui site nu afectează funcţionarea întregului sistem - doar
fragmente ale BD şi nu întreaga BD sau relaţii întregi. Pentru succesul atacului ar trebui să fie
direcţionat asupra mai multor noduri.
Dezavantajele fragmentării:
 Complexitatea proiectării. SD - mai greu de proiectat. Existenţa

fragmentelor → factori suplimentari, cum ar fi stabilirea locaţiei unui
fragment, optimizarea interogărilor etc.;
 Performanţa - unui SD chiar dacă sunt bune decât ale unui sistem
nedistribuit - cazul unor interogări complexe care solicită informaţii prea
De reţinut disparate (de pe mai multe situri);
 Controlul integrităţi - dezideratul primordial al oricărui sistem
tranzacţional - existenţa mai multor fragmente răspândite pe siturile
sistemului, complică lucrurile.
Fragmentele rezultate - condiţiile:
 Completitudinea fragmentării. Fragmentele să asigure acoperirea

întregii relaţii iniţiale. Unele fragmente pot fi redundante, încălecându-se
total sau parţial → fragmentarea are ca obiectiv eliminarea apariţiei
pierderilor informaţionale şi nu cea a redundanţelor.
 Reconstruirea relaţiei iniţiale. În orice moment să poată fi reprodusă
De reţinut relaţia iniţială din care provin fragmentele. Se păstrează dependenţele
funcţionale. Operatorii de recompunere trebuie să fie strict relaţionali.
 Caracterul disjunct - o completare la completitudine. Fragmentele din
aceeaşi relaţie trebuie să fie disjuncte, să nu se suprapună, ca tuple sau atribute. Excepţie
fragmentarea verticală: pentru recompunere, cheile primare - replicate pentru fiecare fragment
creat de-a lungul atributelor. Unele SGBD-uri utilizează atribute surogat pentru cheie primară
- prin generarea automată a unor valori unice pentru fiecare tuplu - chei de replicare Access:
Autonumber.
În funcţie de operatorii relaţionali: fragmentarea (partiţionarea): orizontală,

verticală şi mixtă. Uneori - fragmentări derivate (tip de fragmentare
orizontală) sau relaţii nefragmentate.
Limitele de fragmentarea - de la un tuplu (în cazul fragmentării orizontale)

un atribut (în cazul celei verticale), sau o valoare a unui tuplu, în cazul
Citire celei mixte, până la întreaga relaţie în toate cazurile de fragmentare sau
până la întreaga BD în cazul fragmentării derivate → granulaţia
fragmentării. Ce, cum şi cât fragmentăm - întrebările proiectanţilor de BDD [Sitar2005]
de date
Fragmentarea orizontală
Se face de-a lungul tuplelor unei relaţii → fragment orizontal = submulţime

a tuplelor unei relaţii, obţinută prin selecţie după locaţie sau aplicaţie.
Restricţia - o descompunere ortogonală în fragmente orizontale.
Reprezentarea simbolică a unui fragment orizontal F, obţinut dintr-o relaţie

R, prin specificarea modalităţii de obţinere:
De reţinut Fi: σp(R),
Fi - numele fragmentului, p - un predicat bazat pe unul sau mai multe
atribute ale relaţiei, R reprezintă denumirea relaţiei. σ - simbolul operaţiei de restricţie (selecţie).
Reprezentarea intuitivă:
Fragment orizontal Fragment orizontal
Fragment orizontal
În relaţia STUDENT: atributul Locatia - locul unde urmează cursurile studenţii de la FSEGA.
Considerând că aceştia pot să fie într-una din cele două locaţii posibile, avem fragmentele:
CJ_STUD: σLocatia = ”Cluj”(STUDENT)
SM_STUD: σLocatia = ”Sighet”(STUDENT)
→ FSEGA - două fragmente: CJ_STUD şi fragmentul SM_STUD pentru studenţii din Sighet. Cele
două fragmente îndeplinesc 3 reguli:
 Completitudinea: Studenţii înscrişi la FSEGA sunt fie în Cluj, fie în
Sighet → fragmentele acoperă domeniul atributului Locaţia, deci nu pot
exista studenţi din altă localitate.
 Capacitatea de refacere a relaţiei iniţiale: în orice moment se poate
recompune relaţia iniţială din cele două fragmente, prin reuniune:
STUDENT FSEGA = CJ_STUD  SM_STUD.
De reţinut
 Caracterul disjunct: Nici unul din studenţi nu poate fi arondat atât la
Cluj, cât şi la Sighet.
În proiectarea fragmentelor se ţine cont de aspectul logic (calitativ) şi cel statistic (cantitativ).
 Componenta logică a unui fragment - dată de predicatul pe baza căruia
se face fragmentarea - numele de calificare.
 Proprietăţile statistice se referă la afinitatea (număr şi frecvenţă) unor
aplicaţii sau cereri pentru fragmentul în cauză.
Citire Forma normală conjunctivă (Oszu&Valdiriez) → predicatele pe baza cărora

se abordează fragmentarea orizontală se numesc predicatele minterm -
conjuncţii bazate pe de predicate atomice sau negaţii ale acestora. Predicate
atomice – forma:
pi: Aj  <valoare>, i=1, 2, ...,n,
A1, ...,Am atributele relaţiei,  operator de comparaţie {=, <, >, <=,>=, <>}.
Unele predicate minterm sunt echivalente sau să apară contradicţii în cazul unui astfel de predicat →
constituirea unui fragment vid.
Regula de bază completitudine şi minimalitate: relaţia se fragmentează

în cel puţin 2 fragmente accesate diferit de cel puţin o aplicaţie.
Informaţii cantitative:
 selectivitatea predicatului minterm: cardinalitatea selecţiei;
De reţinut  frecvenţa accesului: frecvenţa accesării datelor de către aplicaţii.
În cazul n predicate simple → numărul predicatelor minterm ce pot fi

definite pe baza acestora este de 2n → numărul maxim teoretic de fragmente orizontale care pot fi
constituite. Poate fi redus - o serie de predicate se pot suprapune sau devin contradictorii.

de date
Fragmentarea verticală
[Sitar2005]
Fragmentarea verticală - de-a lungul atributelor unei relaţii → operaţii de
proiecţie pe sub-relaţii - fiecare sub-relaţie să fie rulată optimal în sensul că
- executată local într-un timp minimal. In fiecare fragment - includerea a
unei chei alternative a relaţiei. Scopul - descompunere fără pierderi,
verificarea celor 3 condiţii impuse fragmentării:
 Completitudinea fragmentării - Fragmentele să asigure acoperirea
De reţinut întregii relaţii iniţiale. Nu se pune problema redundanţei, fragmentarea are
ca obiectiv eliminarea apariţiei pierderilor informaţionale şi nu cea a
redundanţelor.
 Refacerea relaţiei iniţiale. În orice moment - reprodusă relaţia iniţială din care provin
fragmentele. Operatorii de recopunere trebuie să fie strict relaţionali (join).
 Caracterul disjunct - o completare la completitudine. Fragmentele - disjuncte, ca atribute.
Excepţie: pentru legătura între datele unui tuplu şi pentru a putea face recompunerea cu
uşurinţă, cheile primare trebuie replicate pentru fiecare fragment creat. Unele SGBD-uri
transparentizează acest aspect prin utilizarea unor atribute ascunse, în locul cheii primare -
prin generarea automată a unor valori unice pentru fiecare tuplu. Ele mai sunt numite şi chei
de replicare.
Simbolistica: fragment vertical Fi - prin proiecţia atributelor a1, a2, ..., an ale
unei relaţii R:
Fi: Πa1, a2, ...,an(R), Π reprezintă proiecţia din algebra relaţională.
Exemplu: Relaţia LOCALITATI(CodLoc, Loc, CodJud) - fragmente:

L_LOC: ΠCodLoc, Loc(LOCALITATI)
De reţinut J_LOC: ΠCodLoc, Jud(LOCALITATI)
În ambele fragmente - includem cheia primară a relaţiei LOCALITATI. Reguli:

 Completitudinea: Relaţia iniţială, formată din atributele CodLoc, Loc şi Jud îşi regăseşte toate
atributele în cele două fragmente.
 Capacitatea de refacere a relaţiei iniţiale: propagarea cheii primare în ambele fragmente →
recompunerea relaţiei iniţiale se poate realiza oricând printr-o simplă operaţiune de JOIN.
 Caracterul disjunct: Cu excepţia atributului cheie primară fiecare din celelalte două atribute
se află câte unul în câte un fragment.
Partiţionarea verticală - mult mai complexă decât cea orizontală - în

fragmentarea orizontală numărul de variante posibile la un număr dat (n) de
predicate minterm este 2n şi nu toate generează fragmente valabile. La un
număr dat de m atribute non-cheie ale unei relaţii, numărul de variante de
fragmentare verticală este valoarea unei funcţii B(m), care reprezintă al m-
lea număr Bell [Niamir1978, Oszu&Valdiriez2002, Sitar2005]. Pentru
Citire valori mari ale lui m, numărul de variante posibile tinde spre 10m.
Două modalităţi de abordare a proiectării fragmentării verticale:

 Gruparea atributelor (abordare bottom-up). Propusă în BD centralizate [Hammer&Namir
1979]; [Sacca&Widerhold 1985] în BDD. Iniţial stabilirea câte unui fragment pentru fiecare
atribut - apoi, până la satisfacerea unor criterii stabilite se agregă noi atribute. Încalcă
proprietatea de disjunctivitate a fragmentelor → se recomandă ca atributele replicate să nu fie
deloc, sau eventual doar rar actualizate;
 Partiţionarea atributelor. Tehnica - discutată şi propusă pentru BD centralizate în
[Hoffer&Severance 1975], [Navathe&all 1984] în BDD. Se porneşte de la schema iniţială a
relaţiei şi pe baza unor criterii statistice (număr de accese din partea aplicaţiilor) se constituie
în fragmente separate.
În general se aplică cea de-a doua metodă - top-down şi optimizarea mai clară şi mai naturală evitând
suprapunerile. Pentru stabilirea atributelor care vor face parte dintr-un anumit fragment se identifică
mai întâi aplicaţiile (cererile) care acționează asupra acestor atribute. Caracterul disjunct numai pentru
atributele care nu sunt cheie.
Exemplu: relaţia STUDENTI.

de date
Fragmentarea – mixtă
[Sitar2005]
Fragmentarea mixtă –hibridă, nu reprezintă un tip special de fragmentare -
o combinaţie a celorlalte două. Combinaţia se datorează aplicării celor doi
operatori din algebra relaţională utilizaţi pentru fragmentarea pe orizontală
/ verticală. În funcţie de ordinea în care sunt aplicaţi, 2 tipuri de fragmentări
mixte:
 dacă întâi - selecţie, urmată apoi pentru fiecare fragment, de operaţii de
De reţinut proiecţie → fragmente orizontale partiţionate vertical.
 dacă ordinea operaţiilor este inversată → fragmente verticale
partiţionate orizontal.
→ reprezentarea simbolică se vor folosi uzuale. Un fragment din cadrul unei partiţionări hibride poate
fi descris ca fiind rezultatul aplicării fie a unei operaţii de proiecţie asupra uneia de restricţie, fie
rezultatul unei restricţii aplicat asupra rezultatului unei proiecţii:
Fi: Πa1, a2, ...,a n(σp(R)) sau Fj: σp(Πa1, a2, ...,an(R))
F1 F2 F1 F4
F3 F4 F5 F3 F5
F6 F2 F6
Tipuri de fragmente mixte
Din imagine → caracterul complet al fragmentării mixte, indiferent de cazul analizat. Cele 6
fragmente acoperă pe de-a-ntregul relaţia studiată.
Reconstrucţia se face prin operaţii de join şi reuniune.

R = (F1 F2) U (F3 F4 F5) U F6, sau
R = (F1 U F2) F3 (F4 U F5 U F6).
Caracterul disjunct - nici un fragment nu încalcă un alt fragment.

de date
Fragmentarea derivată

[Sitar2005]
Fragmentarea derivată - în practică este cel mai des întâlnită:

 impusă de cerinţe practice menite să optimizeze accesul la date prin
reducerea timpului de transmisie în reţele;
 bazată pe relaţia owner – member (tată – fiu);
 chiar dacă contravine într-o anumită măsură procesului normalizării -
De reţinut cvasi-utilizate.
 presupune crearea unor fragmente orizontale bazate pe mai multe
relaţii aflate în situri diferite.
 în cazul execuţiei ad-hoc a unei astfel de interogări, dacă probabilitatea de repetare a acestor
cereri este destul de mare, s-a optat pentru această soluţie, chiar cu riscul creşterii redundanţei
informaţionale în cadrul sistemului distribuit
→ Fragmentarea derivată este o fragmentare orizontală care se face între două relaţii: una părinte şi
cealaltă fiu. Se va porni de la relaţia fiu, care va fi fragmentată conform predicatului prestabilit.
Predicatul implică în mod obligatoriu cheia externă. După obţinerea fragmentelor orizontale din
relaţia fiu, se face join cu fragmentele – tot orizontale ale relaţiei părinte – corespunzătoare aceluiaşi
predicat (în care este implicat, deci cheia primară). Asocierea se va face pe o operaţie de semi-join
din algebra relaţională. În cazul în care tipul de entitate reprezentat de relaţia fiu este cu participare
totală faţă de tipul de entitate părinte, atunci în fragmentele rezultate vor fi cuprinse toate tuplele din
relaţia părinte. În caz contrar anumite tuple vor rămânea nereprezentate în niciunul dintre fragmente.
Chiar şi aşa, fragmentele rezultate satisfac cele 3 cerinţe primordiale ale fragmentării.

de date
Relaţii nefragmentate

[Sitar2005]
Fragmentarea nu întotdeauna va fi eficientă şi nu va fi aplicată. O astfel de abordare se utilizează
pentru relaţiile cu un număr mic de înregistrări. Se recomandă fie replicarea pe fiecare sit în parte, fie
menţinerea lor în acele noduri unde se utilizează cel mai des, iar în cazul unei cereri la distanţă care
le solicită, strategia optimă ar fi cea de mutare a acestei relaţii, şi nu a celorlalte, fie în situl din care
s-a solicitat cererea, fie într-un alt sit în care există deja una sau mai multe din relaţiile implicate.
La optimizarea interogărilor o astfel de strategie este salutară, atunci când se pune problema
actualizărilor pentru toate copiile, situaţia se complică într-o oarecare măsură. Totuşi, dacă
actualizările la nivelul tabelelor se desfăşoară relativ rar – cel mult o dată pe an – replicarea chiar şi
totală este de bun augur.
II.1.3. Sumar
In cadrul capitolului s-au tratat problemele referitoare la distribuire şi fragmentare a bazelor de date.
Astfel au fost analizate diferenţele dintre bazele centralizate şi distribuite şi cerinţele distribuirii. Au
fost, de asemenea analizate diferenţele dintre fragmentările orizontale, verticale şi mixte, trecându-se
în vedere avantajele şi dezavantajele fiecăreia.
II.1.4. Sarcini şi teme ce vor fi notate
Pentru acest capitol studenţii tebuie:

 să studieze bibliografia;
 să creeze modele de baze de date fragmentate pentru IMM-uri şi pentru firme distribuite;
 modelele conceptuale vor face parte din proba practică pe care studenţii vor trebui să o susţină,
reprezentând 10% din ponderea notei pentru proba practică;
 lămuriri suplimentare pot fi obţinute prin platformă, prin e-mail adresat tutorelui sau în orele
de consultaţii.
II.1.5. Întrebări de evaluarea cunoştinţelor
 Care sunt aspectele importante surprinse în cadrul definiţiilor

sistemelor distribuite? Vezi Importanţa integrării datelor în aplicaţiile
economice pagina 10.
 Desenaţi simbolic modul de dispunere a unei baze de date distribuite în
cadrul unei societăţi comerciale. Vezi Importanţa integrării datelor în
Teme de aplicaţiile economice pagina 10.
reflecţie  Ce este fragmentarea? Vezi pagina 12.
 Care sunt premisele ce stau la baza fragmentării? Vezi pagina 12.
 Ce este fragmentarea orizontală? Vezi Error! Reference source not found. pagina 14.
 Ce este fragmentarea verticală? Vezi Fragmentarea verticală pagina 15.
 Ce este fragmentarea mixtă? Vezi Fragmentarea – mixtă pagina 17.
/ Întrebări pentru platformă/test grilă clasic

II.1.6. Bibliografie capitol
[Date C.J. 2005, T. Connolly. C. Begg, A. 2001, D., A, Sitar-Tăut 2005, Oszu şi Valdiriez 2002].
II.2. Capitolul 2 – Replicarea şi alocarea fragmentelor
Scopul capitolului este familiarizarea cu tehnicile de replicare şi alocare a bazelor de date distribuite.
 studierea problematicii replicării bazelor de date distribuite;
 problemele referitoare la alocare;
 arhitectura conceptuală a bazelor de date distribuite;
 optimizarea interogărilor bazelor de date distribuite.
Replicarea→ Alocarea
↓
Arhitectura conceptuală a bazelor de date distribuite
↓
Optimizarea interogărilor în bazele de date distribuite
↓
Independenţe în cadrul bazelor de date distribuite

de date
Replicarea
(15’ teorie)
[Sitar2005]
Caracteristici de baza SD: fiabilitatea şi disponibilitatea. Fiabilitatea - O
pană în unul dintre situri nu va paraliza funcţionarea sistemului şi nu va
afecta disponibilitatea datelor care au fost înmagazinate în site-ul respectiv.
Performanţa - cu ajutorul replicării fragmentelor.
Replicarea/ reproducerea – copierea unor fragmente în mai multe locaţii. În

De reţinut BDD există mai multe nivele de replicare:
 BD centralizate. Sistemele cu prelucrare distribuită (centralizate - o
BD stocată pe nodul central & un SGBD) →
o caracterul local al referinţei – scăzut - doar nodul central poate face accesări sau prelucrări
locale
o securitatea, fiabilitatea şi disponibilitatea - scăzute şi depind de nodul central
o costul comunicaţiei - ridicat;
 BD partiţionate, fragmentate sau nereplicate - fragmentele apar o singură dată:
o cel mai scăzut cost al stocării
o nu oferă fiabilitate şi nici disponibilitate prea ridicate, dar > decât în cazul sistemelor
centralizate.
o caracterul local al referinţei - la nivel acceptabil.
o costurile de comunicaţie – moderate
o actualizările şi consultările se fac eficient;
 BD replicate integral. - orice site conţine câte o copie a BD
o caracterul local al referinţei, disponibilitatea, securitatea şi fiabilitatea - maxime.
o cost ridicat al echipamentelor de stocare
o comunicaţia aglomerată în cazul actualizărilor.
→ Rezolvare parţială - utilizarea instanţelor - imagini ale BD care se actualizează periodic.
Dezavantaj – uneori nu oferă o situaţie actualizată, iar în actualizări se generează trafic mare
pe reţea;
 BD replicate parţial/selectiv - fragmente replicate, altele nu. Replicate fragmente cu utilizare
frecventă, fie relaţii întregi de dimensiuni mici care nu merită să fie fragmentate - memorate pe
fiecare site. Nereplicate relaţii sau fragmente cu actualizări sporadice. Strategia îmbină cele 3
enunţate anterior. Preia avantajele şi minimizează dezavantajele → se implementează cel mai des.
 costurile de comunicaţie şi de stocare reduse
 caracterul local al referinţei
 securitatea, fiabilitatea şi disponibilitatea sunt apropiate de maxim.
Replicarea favorizează performanţele sistemului la consultare. La actualizări, poate constitui un

impediment: se generează trafic suplimentar, pot apărea inconsistenţe datorită indisponibilităţii
temporare a unei replici.
de date
Proiectarea alocării
(10’ teorie)
[Sitar2005]
Fie un set de fragmente F = {F1, F2, ..., Fi, ..., Fn} într-o reţea cu site-urile
S = {S1, S2, ..., Sj, ..., Sm} & aplicaţii (interogări) Q = {q1, q2, ..., qk, ...,
qq}. Problema proiectării alocării - distribuirea optimă a fragmentelor F pe
siturile S.
Potrivit lui Dowdy şi Foster, „optimul” se referă la:

De reţinut  Cost minim. Funcţia cost – compusă din:
o costul plasării fragmentului Fi pe site-ul Sj
o costul interogării din Sj a fragmentului Fi
o costul actualizării tuturor fragmentelor Fi plasate în toate siteurile
o costul comunicaţiei.
Problema alocării – găsirea unei scheme de minimizare a costurilor.
 Performanţă. Strategia de proiectare - nivel de performanţă prin minimizarea timpului de
răspuns şi maximizarea capacităţilor sistemului ca măsură a contribuţiei fiecărui site.
Alocarea - neredundantă sau redundantă
 Alocarea neredundantă avantaje:

o mai ieftină ca efort de proiectare şi mai uşor de realizat;
o posibilitatea de actualizare a fragmentelor.
Se bazează pe metoda celei mai bune alegeri - unei staţii pe care deja a fost
plasat un fragment, nu poate să-i mai fie alocat un fragment „înrudit”.
De reţinut  Alocarea redundantă - mai complexă. Consultările de date şi
actualizările - problematice. Există două variante de abordare a proiectării
în acest caz:
a) Metoda selectării - identificarea siturilor pentru care beneficiul alocării unei copii
depăşeşte costul alocării;
b) Metoda alocării progresive - se implementează iniţial o alocare neredundantă. Apoi, în
funcţie de gradul de profitabilitate al staţiilor se vor răspândi replici ale fragmentelor deja
alocate, până când nu mai există candidaţi la replicare.
Prima metodă (selectarea) - mai riguroasă şi elimină posibilitatea înmagazinării pe acelaşi site şi copia
fragmentului deja stocat. Replicarea progresivă - metodă euristică - bazată pe aserţiunea că
profitabilitatea scade pe măsură ce gradul de redundanţă creşte.
Abordare mai eficientă, dar şi mai selectivă - metoda celei mai bune alegeri şi în etapa de proliferare
a copiilor. Se începe cu fragmentele considerate ca fiind cele mai importante, ţinându-se cont la
fiecare alocare de relaţia de „rudenie” a tuturor fragmentelor ce există sau urmează a fi stocate într-
un site.
de date
Alocarea fragmentelor verticale
 Partiţionarea atributelor - măsurarea beneficiului partiţionării unui

fragment Fi alocat la staţia j, în două fragmente Fs şi Ft plasate în siturile s
şi t se consideră şi seturile de aplicaţii ce accesează atributele din cele două
fragmente disparate Qs şi Qt. Aceste cereri sunt cereri locale. Există încă
trei seturi de aplicaţii: Q1, Q2 şi Q3, - Q1 - local staţiei r, care utilizează
numai atribute ale fragmentelor Fs sau Ft. Cererile Q1 necesită un acces la
Citire
distanţă. Setul Q2 - rezident în site-ul r şi accesează atribute din ambele
fragmente (q şi t). Aici vom avea două accese la distanţă. Q3 aparţine altor
situri decât r, s, sau t, dar utilizează şi fragmentul Fs, cât şi Ft. Beneficiul acestei partiţionări
se cuantifică astfel:
Bist  
kQ s

f ksnki 
kQ t

f kt nki 
k Q1

f kr nki 
k Q2

2 f kr nki  f kj nki
k Q3 jr , s, t
Formula - numără atât accesele locale, cât şi cele la distanţă. Se poate rescrie prin înlocuirea
lui nki cu rki + C  wki.
Pentru determinarea schemei de alocare a fragmentelor Fs şi Ft se va calcula beneficiul pentru
toate combinaţiile posibile ale siturilor s şi t, alegându-se perechea pentru care se realizează
beneficiu maxim.
 Gruparea atributelor - proiectarea fragmentelor - rezultat fragmente nedisjuncte. Problema
descrisă în paragraful anterior - un set comun de atribute I. Gruparea verticală va prezenta
particularităţi şi în ceea ce priveşte cererile implicate.
o Qs - setul de aplicaţii locale site-ului s, care citesc sau actualizează orice atribut al
fragmentului Fs, dar care nu se suprapun cu I.
o Q2 - cererile de actualizare aflate pe staţia r - actualizarea atributelor setului I şi
necesită acces atât la Fs, cât şi la Ft.
o Q3 - aplicaţii din alte staţii decât cele amintite, care actualizează atributele setului I şi
necesită acces atât la Fs, cât şi la Ft.
→ Formula descrisă în cazul abordării anterioare este valabilă şi în cazul grupării → alocarea
trebuie să asigure regăsirea facilă a fragmentelor prin conferirea unui plasament optim, astfel
ca să se reducă pe cât posibil numărul de accese la distanţă. În afară de componenta costului
de comunicaţie, alocarea trebuie să ţină cont şi de celelalte aspect relative costului proiectării
alocării.
de date
Arhitectura de referinţă a unui SD
(15’ teorie)
[Sitar2005]
(DBTG) - 1971 propunere standardiza BD pe două nivele – schemă şi subschemă – în 1975 (ANSI-
SPARC) a fost abordată o arhitectură pe trei nivele: extern, conceptual şi intern → separarea
viziunii utilizatorului de modul fizic de reprezentare a datelor. Referinţă, uzitată în mediile academice
şi chiar pragmatice ale BD. Datorită complexităţii domeniului BDD faţă de cele centralizate,
impunerea unei arhitecturi standardizate ar fi cu mult mai greu de realizat.
Arhitectura este formată din:
S1 S2 Sn
...
Schema Schema Schema
externă globală externă globală externă globală
Schema conceptuală
globală
Schema de
fragmentare
Schema de
S1 S2 alocare Sn
...
Schema de Schema de Schema de

transformare transformare locală transformare locală
locală

conceptuală locală conceptuală locală conceptuală locală

internă locală internă locală internă locală
BD BD BD
 schemele externe globale - viziunea fiecărui utilizator asupra
sistemului;
 schemă conceptuală globală - imaginea completă a întregii BD, fără
a lăsă impresia că aceasta ar putea fi una distribuită;
 schema de fragmentare ideea proiectantului de partiţionare a întregii
BD;
De reţinut  schema de alocare - modul de amplasare fizică a fragmentelor şi
replicilor acestora în vederea deservirii optime a interogărilor şi tranzacţiilor
SD;
 pentru fiecare site - arhitectură ANSI-SPARC pe trei nivele:
o schema de transformare - armonizare între fragmentele amplasate conform schemei de
alocare şi vederile utilizatorilor BD locale
o schema conceptuală locală - logică a BD amplasate pe un anumit site
o schema internă locală indică modalitatea de stocare a datelor locale (reprezentarea fizică a
BD locale).
Ahitectura - orientativă, de care se poate sau nu ţine seama. În funcţie de specificul SD, o serie de
componente ale acesteia vor fi ignorate, sau altele suplimentate.

de date
Principiile lui Date referitoare la SD
(15’ teorie)
Chris Date – 2 set-uri de „reguli” pentru BDD → o duzină – de principii pe

care SD trebuie / ar trebui să le respecte + principiul fundamental -
„Principiul 0” / „Regula 0”
Principiul fundamental al BDD - „pentru utilizator, SD trebuie să arat
ca unul nedistribuit” Utilizatorului îi este transparentă distribuirea,
accesul la distanţă = o problemă locală → 12 principii (obiective):
De reţinut 1. Autonomia locală.
2. Absenţa unei dependenţe de un sit central
3. Operarea continuă - 2 aspecte majore ce privesc performanţele SD: fiabilitate şi
disponibilitatea.
Fiabilitatea
Disponibilitatea
Un incident nu trebuie să afecteze SD, sub aspectul funcţionării, sau al completitudinii datelor + SD
trebuie să funcţioneze şi în timpul procedurilor de mentenanţă, de natură software / de natură
hardware.
4. Independenţa de fragmentare
5. Independenţa de localizare/transparenţa la localiţie - Nivelul mediu al transparenţei.
6. Independenţa de replicare/ transparenţa la replicare - transparenţă de alocare.
Transparenţa la transformările locale → nivelulul cel mai scăzut la distribuire, apropiat de nivelul
fizic. Problemele de transparenţă la distribuire → o dependenţă mai mică sau mai mare de problema
alocării şi gestionării numelor obiectelor din cadrul unui SD. Connolly - „transparenţă la denumire”
- Date - o abordare mai complexă „administrare a catalogului”.
Soluţii pentru cataloage:
a) Localizare centralizată;
b) Replicare totală;
c) Fragmentare.
Celelalte principii vor fi detaliate în cadrul secvenţelor următoare.

de date
Prelucrarea distribuită a interogărilor
[Sitar2005]
Interogări pur locale - rare în SD. Datele cerute - plasate în cel puţin două
situri diferite → în vederea optimizării interogărilor, problema trebuie
tratată:
 la nivel global: stabilirea strategiei în funcţie de datele problemei,
coordonarea tuturor operaţiunilor aferente, transmiterea şi preluarea de
mesaje către/dinspre siturile locale;
De reţinut  nivel local: strategia internă de prelucrare a interogărilor, comunicare
rezultate parţiale, verificări.
Dacă cererea a fost emisă de situl X, către Y pentru filtrări şi returnarea rezultatului parţial, pentru
economie de timp, X rezolvă în paralel problemele care-l privesc. În funcţie de cardinalitatea
rezultatelor parţiale, a dimensiunii unui tuplu şi a vitezei de transfer pe linia de comunicaţie Y va
trimite rezultatul parţial la X pentru prelucrări finale → în cazul sistemelor relaţionale se transmit a
doar 2 mesaje. Pentru alte modele de date - numărul poate creşte în funcţie de cardinalitatea
fragmentului de pe un sit, sau cardinalitatea rezultatului parţial → Pentru fiecare tuplu - mesaj prin
care se exprimă cererea şi câte unul de răspuns din partea sitului căruia i-a fost adresată cererea → în
privinţa numărului de mesaje dintre siturile participante la interogare, modelul relaţional se pretează
cel mai bine sistemelor distribuite.
O interogare poate fi rezolvată în mai multe feluri, neexistând doar o soluţie
unanim acceptată. - 6 modalităţi de rezolvare a unei cereri într-un sistem
distribuit. Numărul soluţiilor depinde de factori:
 complexitatea interogării;
 situl de pe care se efectuează cererea;
De reţinut
 numărul de situri solicitate;
 densitatea datelor de pe fragmentele siturilor implicate.
Timpul de răspuns depinde de strategie. Există cereri a căror răspuns printr-o strategie poate fi furnizat
în mai puţin de o secundă, iar prin alta necesită zile întregi. La acelaşi tip de interogare, strategiile
optime nu coincid. În majoritatea cazurilor strategiile BD relaţionale dau rezultate mai bune.
Ideea de bază - a trata cererile cât mai apropiat de performanţele unei cereri locale. Sistemele
distribuite pot surclasa pe cele centralizate, deoarece în situaţia centralizării, interogările implică
accesări la distanţă.
Exemplu de identificare a strategiei optime de rezolvare a interogărilor - una din principalele

probleme ale SD. Problema: cu cât creşte timpul de prelucrare a unei cereri
distribuite faţă de una locală şi care ar fi strategia optimă? Ipoteze de lucru:
 între noduri există aceeaşi rată de transfer;
 n-are importanţă situl din care se va lansa cererea - în practică, acest
factor nu este de neglijat;
 interogarea - sursă de date a 3 fragmente plasate în 2 situri, unul la
Temă de Secretariat, iar altul la Arhivă;
reflecţie  rezolvarea interogării necesită join-uri ale fragmentelor, proiecţii şi
selecţii pentru răspuns;
 se neglijează timpii de prelucrare internă (la aceluiaşi fragment) a datelor; aceşti timpi s-ar
cheltui oricum şi la o prelucrare locală.

de date
Gestionarea distribuită a tranzacţiilor
[Sitar2005]
Obiectul de studiu: controlul accesului concurent şi problema toleranţei la

pene. Faţă de nod central, în cazul SD lucrurile se complică. O tranzacţie în
SD are nevoie de agenţi, care să reprezinte şi să verifice rezultatul finalizării
tranzacţiei în fiecare din situri. Pentru atomicitate fiecare agent al tranzacţiei
trebuie fie să-şi îndeplinească sarcina, fie toţi sunt nevoiţi să o anuleze.
De reţinut
Metoda cea mai răspândită de control al accesului concurent este blocarea.
Gestionarea distribuită a tranzacţiilor este strâns legată de transparenţă. Fără a lua în considerare
aspectele referitoare la controlul concurenţei şi a rezistenţei la pene, în SD performanţe atât la nivelul
vitezei de execuţie, cât şi la cel al concurenţei se realizează prin utilizarea sub-tranzacţiilor.
Transparenţa la defecţiuni şi capacitatea de refacere, trebuie să se ţină cont

de atomicitatea tranzacţiilor şi de caracterul durabil (permanent) al
modificărilor făcute. Un SGBDD trebuie să garanteze că tranzacţia globală
este atomică, adică toate tranzacţiile locale pe care le implică fie s-au
terminat cu succes, fie au fost toate anulate. Nu există situaţii de
compromis, deoarece caracterului durabil al subtranzacţiilor → ajunge la
Citire inconsistenţe. Pe lângă problemele din sistemele centralizate – căderea
sistemului, pene de mediu, erori software, neglijenţa, dezastre fizice
naturale sau sabotajul – SD trebuie să ţină cont şi de: pierderea unui mesaj, defectarea legăturilor de
comunicaţie, defectarea unui sit sau de partiţionarea reţelei → SD trebuie să furnizeze mecanisme de
refacere, care indiferent de posibilele accidente trebuie să susţină atomicitatea tranzacţiei globale.
Independenţa de hardware
Aplicaţiile trebuie să satisfacă criteriul transparenţei faţă de maşină. SD nu
trebuie să facă rabat de la acest aspect. Putem să avem echipamente Dell,
HP, Siemens-Fujitsu, Compaq, IBM etc. în configuraţii şi de performanţe
diferite. SD indiferent la mărci → nu tratează discriminatoriu nodurile
conectate. Siturile sunt tratate egal. Tehnologia – transparentă utilizatorului.
De reţinut
Independenţa de SO
SD trebuie să funcţioneze identic pe platforme hard, cât şi pe calculatoare

echipate cu SO. Utilizatorul nu trebuie să resimtă amprenta unui SO diferite,
instalate pe maşini diferite, sau chiar pe acelaşi echipament. Indiferent că e
vorba de Unix/Windows, OS/2, de versiuni sau „dialecte” diferite SD
rulează pe oricare dintre acestea, fără ca operatorul să sesizeze diferenţe în
utilizare între calculatoare cu SO diferit.
De reţinut
Independenţa de reţea
Nodurile SD sunt conectate logic la aceeaşi reţea de comunicaţie – indiferent de topologii, vitezele
de transfer, dimensiunile pachetelor, metodele de acces la mediu sau tehnologia subreţelelor – acestea
nu trebuie să devină un impediment în buna funcţionare a sistemului. Siturile unui astfel de ansamblu
pot să provină din reţele eterogene fără a fi afectate performanţele.
Independenţa de SGBD
Este mai greu de atins. Ideal - toate siturile SD să ruleze acelaşi SGBD. Nu
poate fi pus în practică datorită eterogenităţii echipamentelor şi a SO şi
latura financiară. Cu SGBD-uri - diferite, ar fi de recomandat ca să nu fie
problema incompatibilităţii canalelor de comunicare între siturile cu SGBD-
uri diferite. Canal ar fi recunoaşterea de către siturile implicate a aceluiaşi
standard SQL. SD ideal – asigură transparenţa faţă de SGBD-ul utilizabil în
De reţinut siturile sale.
II.2.3. Sumar
In cadrul capitolului s-au tratat problemele referitoare la replicarea şi alocarea bazelor de date
distribuite. A fost prezentată o arhitectură conceptuală de bază de date distribuită şi s-au analizat
diverse aspecte ale interogărilor bazelor de date, de la optimizare la independenţe.

 pornind de la exemplul din material să studieze probleme referitoare la alocarea şi replicarea
bazelor de date distribuite şi optimizarea interogărilor;
 să studieze exemple de optimizări de interogări în MS SQL Server şi Oracle, precum şi modul
de transfer a interogărilor şi a rezultatelor acestora între aceste două tipuri de SGBD-uri.
 modelele conceptuale vor face parte din proba practică pe care studenţii vor trebui să o susţină,
reprezentând 10% din ponderea notei pentru proba practică;
de consultaţii.

 Ce este replicarea şi care sunt nivelele de replicare cunoscute? Vezi
Replicarea pagina 22.
 Ce este alocarea şi care sunt metodele de alocare? Vezi Proiectarea
alocării pagina 23.
 Schiţaţi arhitectura de referinţă a unui SD. Vezi pagina 27.
Teme de  Enumeraţi principiile lui Date pentru SD. Vezi începând cu pagina 28
şi până la finalul capitolului.
reflecţie

[Date C.J. 2005, T. Connolly. C. Begg, A. Strachan 2001, D.A. Sitar-Tăut 2005, I. Lungu 1995,
BDASEIG, 2002, 2002, Ozsu M, Valduriez T, 2002]
II.3. Capitolul 3 – Baze de date obiectuale
Scopul capitolului este familiarizarea cu Orientarea Obiectuală în domeniul bazelor de date
 Studierea problematicii generale OO.
 Studierea modelor de date OO şi a deosebirilor faţă de cele relaţionale.
 Baze de date OO şi SGBDOO
 Distribuirea BDOO
Orientarea Obiectuală (OO)

↓
Modele de date OO → BDOO → SGBDOO
↓
Diferenţele dintre SGBDOO şi SDGBDR
↓
Distribuirea BDOO

de date
Argumente în favoarea modelului OO
Modelul O – a apărut la sfârşitul anilor ’60, începutul anilor ’70, ca soluţie

la:
 descrierea naturală a unor structuri din lumea înconjurătoare;
 definirea - tipuri abstracte de date, ca: imaginea, sunetul, vocea, video
etc.;
De reţinut  necesitatea unor tipuri de date compuse: mulţimi, vectori, secvenţe etc.;
 definirea şi utilizarea facilă a unor tipuri-utilizator;
 moştenirea unor componente;
 reutilizarea codului;
 simulare, modelare;
 îmbunătăţirea interfeţei cu utilizatorul;
 surprinderea aspectelor dinamice;
 suportului pentru noi tehnologii: CAD, CAM, CAE, CASE, OIS, cartografie, sisteme
multimedia, editare digitală, medicină, chimie, analiză spectrală, GIS, ingineria cunoaşterii,
controlul proceselor în timp real etc.
Primele limbaje OO: Simula67 şi SmallTalk – apoi C++, Ada, Pascal etc. BD relaţionale – rigide nu
oferă o imagine a realităţii prin capacităţi de modelare semantică → primele SGBD-uri OO: Ontos,
O2, GemStone, Versant, Jasmine. În ultimii 15 ani modelul OO şi pe piaţa BD, constituind o
ameninţare la adresa BDR.
Aplicarea tehnologiei BD ca suport al activităţii CAD a fost salutară. BD OO surprinde un număr

mare de caracteristici. Proiectele pot avea dimensiuni mari şi multe
subansamble de sine stătătoare. O actualizare a unei componente produce
actualizări în lanţ în toate sub-componentele cu care interacţionează, fără
intervenţii exprese ale utilizatorului. BD OO permit un control eficient al
versiunilor - proiectantul poate reveni la variantele anterioare. Creează
premisele proiectării în echipă şi integrarea proiectului final de o manieră
De reţinut
coerentă.
Instrumentele CASE conduc proiectantul în ciclul de viaţă al produselor, permiţând extinderi,

cooperări între proiecte şi proiectanţi, generări de scheme, secvenţe de cod, documentaţii, facilităţi de
administrare şi configurare etc.
Sistemele OIS integrează: rapoarte, analize, tabele, schiţe, corespondenţă, documente financiare sau
comerciale, agende, imagini, sunete, secvenţe video etc. într-un format neconvenţional. Compatibile
cu HTML sau XML.
Editarea digitală - domeniu de viitor. Subdomenii: e-Library şi e-Learning. Informaţia digitală

concurează publicaţiile fizice: literatură, jurnalistică, cărţi pentru copii, benzi desenate etc. -
înglobează formatele multimedia cunoscute. → necesită capacităţi de stocare şi procesare uriaşe.
Connolly - „handicapul” BD relaţionale:

 Reprezentarea precară a entităţilor din lumea reală - normalizarea
BDR poate conduce la relaţii artificiale, pe care nu le găsim realitate. De
regulă se întâmplă când se evită forme normale superioare. Dezavantajul
construcţiei – relaţiile nu reprezintă realitatea → plătim tribut – operaţii de
join – pentru a obţine entităţi conforme realităţii.
 Limitarea semantică - BDR exprimă legătura dintre entităţi numai
De reţinut prin utilizarea relaţii. Dacă avem legături de tip 1:N sau N:1 situaţia este
normală: 2 relaţii între care se manifestă tipul legătura. La relaţii N:M,
lucrurile se complică: se utilizează o relaţie intermediară cu/faţă de care relaţiile implicate sunt
în relaţii de tip N:1 şi respectiv 1:M. → BDR - „limitat semantic” - nu există o altă modalitate
de a exprima legăturile dintre entităţi decât tot prin intermediul unor relaţii. Avem totuşi:
domenii, chei relaţionale, dependenţe funcţionale, multivoce sau proiecţie.
 Control insuficient al integrităţii şi mecanisme deficitare de gestionare a constrângerilor
de întreprindere. Regulile de integritate - aspecte definitorii ale unei BD. Neimplementarea în
SGBD comerciale / negocieri cu utilizatorul - nocive pentru coerenţa unei BD. Suportul pentru
constrângerile de întreprindere, SGBD-urile nu acoperă. → gestionăm de unii singuri problema,
efort suplimentar.
 Structura de date prea omogenă - la nivelul BD conţinutul şi semantica se exprimă uniform
– doar prin relaţii – intrarelaţional → reprezentare omogenă atât vertical cât şi orizontal. Pe
coloană - valori de atribute în conformitate cu domeniu, pe orizontală, tuplele de dimensiuni
egale şi conţin toate valori ale aceloraşi atribute pentru fiecare linie a relaţiei. Restricţia şi la
intersecţia unei coloane cu o linie - o singură valoare scalară. Restricţie impusă de 1NF, şi
definiţia modelului relaţional, contravine multor structuri fireşti din lumea înconjurătoare. Au
existat o propuneri: o valoare, o mulţime de valori, un O compus, o nouă relaţie, sau o
combinaţie a acestora. Structura omogenă a relaţiilor - de multe ori atu. O concesie în BDR
BLOB (Binary Large Objects) - înmagazinate date nestructurate de dimensiuni mari: texte
formatate, tabele de calcul, aplicaţii, imagini, sunet, voce, sau video. Memorarea - în fişiere
separate, externe tabelei. Se rezumă doar la memorare & redare fără cunoştinţe de conţinut &
comportament.
 Set redus de operaţii ca cele pe mulţimi şi pe tupluri insuficiente ca să simuleze realitatea.
Exemplu, dintr-o secvenţă video cu două maşini, BDR nu poate să extragă denumirea mărcilor,
viteza, sau distanţa dintre ele.
 Gestionarea greoaie a interogărilor recursive - SQL extragerea greoaie a informaţiilor despre
relaţii, directe sau indirecte din membrii relaţiei. Exemplu, într-o relaţie - 2 atribute ce
desemnează unul componentele unui subansamblu, altul numele subansamblului. Unele
subansamble pot fi la rândul lor componente ale altor subansamble, o interogare extrage destul
de greu (trebuie specificat subansamblul) sau deloc toate componentele a tuturor
subansamblelor din relaţie. Exemplu: {(cărămidă, casă); (lut, cărămidă); (casă, cartier) ...}.
Interogarea extrage informaţiile: cărămida contribuie la subansamblu casă, lutul la fabricarea
cărămizii şi casele fac parte dintr-un cartier, nu va fi capabilă să indice că lutul este o
componentă necesară pentru ridicarea unei case şi contribuie la realizarea cartierului sau
cărămida pentru cartier. Pentru rezolvare s-a propus [Meret1984] extensie AR cu o operaţie
unară închidere tranzitivă → „legăturile” lut – casă, lut – cartier şi cărămidă – cartier.
 Nepotrivirea de impedanţă - pentru a folosi în anumite aplicaţii rezultatele interogărilor SQL
se utilizează un limbaj non-SQL de pe platforma gazdă → o nepotrivire - SQL- limbaj
declarativ, poate prelucra odată relaţii întregi sau blocuri de linii - limbajul prin intermediul
căruia este integrat, fiind generaţia a treia, va putea prelucra câte o linie. Soluţia lui Date - nu
extinderea BDR cu facilităţi O, ci extinderea limbajelor de programare cu facilităţi de
manipulare în bloc a relaţiilor. O altă problemă – pseudo-incompatibilitatea dintre tipurile
recunoscute de SQL şi cele ale limbajului gazdă → necesitatea ca aplicaţiile să ofere o conversie
a datelor într-un format recunoscut de SQL. [Date] - operaţii prea costisitoare, necesitând până
la 30% din efortul de proiectare, din secvenţa de cod, contribuind şi la creşterea timpului total
de execuţie.
 Mecanismele tranzacţionale de control al concurenţei - proiectate pentru perioade scurte de
timp. Tehnologiile care necesită facilităţi OO cer perioade lungi de actualizare → abordarea
mecanismului tranzacţional existent trebuie revizuit.
 Deficienţe în modificarea schemelor - proiectarea unei BD - îndelung gândită şi concepută ca
să asigure suport şi pentru dezvoltările ulterioare - altfel structurile trebuie revizuite periodic →
operaţie costisitoare care implică şi modificări ale aplicaţiilor, întreruperi periodice a activităţii,
perioade de testare etc. → se vrea un sistem care să-şi modifice comportamentul odată cu
modificările schemei.
 Acces asociativ bazat pe conţinut vs acces navigaţional. Tendinţele - în general pe cel de-al
doilea.
de date
Concepte teoretice privind paradigma OO
[Sitar2005]
O parte - dezbătute la modelul E-R.
O - entitate unic identificabilă – lucru, vietate, proces, fenomen din lumea

reală sau uneori virtuală – conţine descrierea (proprietăţi) şi
comportamentul acesteia.
Starea O - descrisă de proprietăţi sau atribute, denumite şi variabile de

Definiţie instanţă. Notaţia uzuală a proprietăţii cu ”.” între numele clasei şi al
proprietăţii. În concordanţă cu BDR O = un tuplu al unei relaţii, proprietate
= atribut. Exemplu: student - proprietăţile nume (Popescu) şi prenume
(Marcel). Proprietăţile simple / complexe. Complexe = mulţimi de
elemente, structuri compuse, sau referinţe. Exemplu: proprietatea Tel sau
Email - mai multe valori, Popescu Marcel are telefon fix, mobil, de la firmă
& mai multe adrese de email. O structură compusă - adresa ca referinţă la
De reţinut proprietăţile Localitate, Strada, Nr, CodP ale unui alt O din clasa Adresa.
O pot fi simple / complexe. Cele din urmă - formate sub O, subansamble sau părţi componente.
Relaţiile dintre O componente şi cele complexe sunt de genul A-PART-OF (APO). Dacă elementele
componente sunt formate O cu existenţă de sine stătătoare în lumea reală → o ierarhie de tip APO.
În abordarea OO fiecare O deţine un identificator de O (OID) cu rol de cheie primară din BDR. O
proprietate specială a O, caracterizată de: unicitate, invariabilitate pe toată perioada de viaţă (nu poate
fi modificat), independenţă faţă de valorile proprietăţilor sale. Generat de către sistem → de preferat
să rămână necunoscut şi invizibil pentru utilizatori. Faţă de cheile unei relaţii destul de greoaie, OID
permit regăsirea rapidă a O referit, pointând adresa de memorie a O.
Metode - deosebire de 4GL - independenţa datelor faţă de programe / OO se bazează pe

încapsularea proprietăţilor şi comportamentului în cadrul O.
Metodă = program ce manipulează O / indică starea acestuia. Descrie procedurile (funcţiile) /

aspectul dinamic al O; proprietăţile aspectul static - cu metode se modifică / interoghează starea O.
Modificarea structurii O → modificarea automată şi o recompilarea programelor. Metodele şi
proprietăţile invizibile din exteriorul O → o implementare care este privată şi o interfaţă care este
publică, putând fi accesată de O externe şi utilizatori. Metoda - definită prin semnătura compusă din
denumirea metodei, de parametrii de intrare şi eventual de cei de răspuns.
Constructorii & destructorii – 2 metode speciale: primii dau naştere O, creează o nouă instanţă, al
doilea pune capăt acestei existenţe şi îl elimină din memorie.
Dialog prin mesaje - cereri adresate O de a executa o metodă. Ca la proprietăţi, se va folosi simbolul
”.”.
Exemplu: STUDENT.Calcul_Media(Integer Matricol):float Media
Mesajele nu au corespondent în modelarea entitate-relaţie.
Încapsularea
Structura şi implementarea metodelor unui O nu pot fi accesate sau

modificate de un factor extern O, însă pot fi actualizate indirect prin
intermediul mesajelor. Proprietate de ermetizare faţă de agenţii externi -
încapsulare. → 2 viziuni asupra O: una externă, se referă la setul de mesaje
acceptate = interfaţa O şi una internă referitoare la proprietăţi şi metode.
Citire Alt aspect - O pot fi considerate date abstracte care permit accesări din
exterior prin intermediul mesajelor în vederea efectuării unei operaţiuni,
însă modul în care sunt implementate metodele implicate sunt ascunse utilizatorului. El ştie doar să
lanseze un mesaj şi să examineze ieşirile, fără a avea detalii suplimentare asupra modului în care s-a
rezolvat problema - considerate „cutii negre”.
→ încapsularea ascunde complexitatea unui O, punându-i însă la dispoziţie o imagine simplificată,

dar funcţională - utilizatorul poate să fie preocupat de esenţa problemei modelate fără a fi deranjat de
detaliile tehnice, neimportante scopului propus.
Clasele
Clasă = mulţimea O care au aceleaşi proprietăţi şi răspund la aceleaşi

mesaje; se foloseşte şi termenul tip (nu cu semnificaţia referitoare la
domeniul de definire al unui atribut). O - instanţe ale unei clase. Metodele
şi proprietăţile se definesc o singură dată pentru întreaga clasă. Dacă se
transmit mesaje unei clase de o altă clasă, clasa din urmă că este o
Citire metaclasă.
Subclase, superclase, generalizare, specializare, ierarhie de clasă şi moştenire analog ca la E-R

extins. Unii termeni se refereau doar la atribute, în cazul OO aceştia se referă şi la metode. O seamănă
cu entitatea, cu diferenţa că aceasta din urmă nu încorporează şi comportamentul.
Proprietăţile şi metodele sunt moştenite de subclase. Totuşi, în interiorul unei subclase pot avea loc
redefiniri ale unor proprietăţi sau metode. Exemplu: fereastra în VFP. Implementarea unei astfel de
metode – suprascriere - un caz particular al supraîncărcării. Prin aceasta se pot defini metode
specifice pentru fiecare tip de O în parte → o simplificare a aplicaţiilor ce vor folosi aceste metode
asupra unei clase întregi: cu acelaşi mesaj asupra unei clase se vor efectua operaţiuni specializate
asupra anumitor tipuri de O ce compun clasa.
Polimorfismul
Este caz mai general de supraîncărcare cu 3 „forme”: operaţional sau ad-hoc, de incluziune şi
parametric (generic).
 Supraîncărcarea - un polimorfism operaţional.
 Polimorfismul de incluziune este cazul tipic de moştenire, adică o
metodă dintr-o superclasă este moştenită automat în subclase.
 Polimorfismul parametric presupune o definire mai generală a unei
metode, prin utilizarea în locul parametrilor obişnuiţi direct tipurile de date
Citire - transferă etapa de cunoaştere a parametrilor reali de la compilare la
execuţie unde sunt evaluaţi şi în funcţie de tipul identificat se va executa
metoda specifică acestuia. Decalată de momentul compilării, selecţia metodei beneficiază de
aşa-numita legare dinamică.
Persistenţa
Este o caracteristică a BD. Spre deosebire variabile, vectori sau liste volatile
utilizate în programare, O şi alte tipuri de date le menţin o perioadă mai
lungă de timp. Persistenţa, în cazul O se referă la proprietăţi & declaraţii ale
metodelor chiar şi după încetarea procesului care le-a creat sau le-a
actualizat şi până la apariţia unui alt factor extern care produce tipurile de
modificări menţionate sau chiar distrugerea O. Aceasta este una din
Citire premisele relaţiei BD cu O.
O construcţie mai formalizată a ierarhiei claselor şi O poate fi obţinută pornind de la filosofia

modelului OO, de exemplu O2 şi IQL, analog cu (Abitaboul, Hull şi Vianu 1997).
Modelul de date orientat spre O (OODM) - un model logic de date ce

descrie acea semantică a datelor acceptată în programarea OO → BD
orientate spre O - o îmbinare a tehnologiei BD cu cea O → înmagazinării şi
regăsirii unor informaţii complexe implementate cu ajutorul O.
BDOO (OODB) - o colecţie de O persistente şi partajabile definite pe baza

Definiţie unui model de date OO.
Specificarea schemei BD se realizează prin mecanismul de definire a claselor. Schema BD conţine

clasele necesare implementării aplicaţiei dorite. Între clase există o legătură ierarhică şi între care sunt
relaţii structurale. O schemă completă a unei BD constă în una sau mai multe ierarhii de clasă
interconectate structural pe baza relaţiilor dintre ele. Schema BD poate fi modificată şi dinamic în
funcţie de cerinţele utilizatorilor.
de date
Aspecte referitoare la proiectarea BDOO
(5’ teorie)
Tehnica de proiectare bazată pe modelarea E-R şi utilizată în proiectarea
BDR, nu diferă de abordarea proiectării BDOO. Există etape care pot fi
omise - modelarea O este superioară faţă de cea R. Chiar şi normalizarea –
orientată către BDR – poate fi aplicată. Indiferent de modelul de date
redundanţa este un pericol. Normalizarea trebuie regândită în termeni O.
Astfel, o interpretare 2NF şi 3NF ar putea suna astfel: „Fiecare atribut dintr-
De reţinut un O este dependent de OID”.
Cu toate că OO semnifică naturaleţe, proiectarea nu se face deloc în conformitate cu acest principiu.

Mai ales pentru proiectanţii specializaţi în implementări „clasice”, problema proiectării O devine una
destul de spinoasă.
Tehnica de abordare este diferită. Dacă pentru BDR cea mai la îndemână este top-down, în proiectarea
OO se utilizează tehnica bottom-up. Se identifică la început componentele funcţionale ale
ansamblului. La o reproiectare se identifică O care pot fi folosite, în stare naturală sau ajustate, în
model; dacă nu există sau se porneşte de la zero, proiectantul va construi ierarhiile de clase. Testările
şi crearea documentaţiei nu trebuie excluse din proiectare.

de date
Reprezentarea relaţiilor structurale dintre obiecte

În abordarea OO relaţiile se reprezintă prin intermediul atributelor de
referinţă, implementate prin utilizarea identificatorilor OID.
Relaţia 1:1 între O SEF_CATEDRA şi CATEDRA
Relaţie 1:1 - şef de catedră poate conduce una şi numai una catedre, iar
fiecare catedră trebuie să aibă un şef.
De reţinut
Relaţii 1:N
Relaţiile de tip „unu la mai mulţi” dintre A şi B se reprezintă în cazul OO
prin adăugarea ca valori atribut în A o mulţime de referinţe, iar în B a unui
atribut care indică înspre OID A.
CATEDRA
Relaţie de tip 1:N - în cadrul unei facultăţi se află mai multe catedre, iar o
De reţinut
catedră nu poate să fie partajată de mai multe facultăţi.
Relaţii M:N
Se realizează prin utilizarea de mulţimi de referinţe înspre O de tipul celui
cu care intră în relaţie.
Relaţie de tip M:N între O STUDENT şi EXAMEN
De reţinut
În BDR o relaţie de acest gen nu poate fi descrisă decât prin intercalarea între cele două relaţii a unei
relaţii intermediare. Poate fi simulat şi în OO, dar există şi varianta directă a cărei acoperire n-o
regăsim în modelul relaţional.
Integritatea referenţială
Modelul R - între două relaţii părinte-fiu conectate logic prin valorile atributelor de legătură (cheie
candidat, respectiv cheie externă), valorile cheii externe trebuie să se
regăsească prin mulţimea valorilor cheii candidat (de regulă cheia primară)
din relaţia părinte. Similar, şi în OO referinţele spre alte O trebuie să fie
valide. Dacă în tratarea relaţiilor nu există O referite de către alte O, relaţiile
devin invalide → integritatea referenţială. Integritatea referenţială trebuie să
fie satisfăcută şi în momentul creării legăturii şi menţinută pe durata
Citire
existenţei relaţiei sau a O implicate. Modalităţi de întreţinere a acesteia,
regulile fiind puse în aplicare de sistemul SGBDOO:
 Utilizatorul nu poate şterge un O implicat într-o relaţie - sistemul se ocupă de acest aspect. Dacă
O nu mai este solicitat, acesta îl va şterge şi valorifică spaţiul de memorie - regulă implementată
în GemStone;
 Utilizatorul poate şterge, dacă este nevoie, acele O care nu mai sunt referite. Sistemul detectează
O fără referinţe valide - le atribuie valoarea NULL sau îngăduie ştergerea lor - aplicată de
sistemul Versant;
 Utilizatorul poate să actualizeze referinţele / să şteargă O sau relaţii dintre O. La intervenţiile
lui ce pot afecta stabilitatea integrităţii referenţiale sistemul ia atitudine făcând actualizări
automate pe baza relaţiilor inverse dintre atribute. Această variantă este cea mai permisivă şi
este aplicată în Ontos, Objectivity/DB şi ObjectStore. [Conolly]

de date
Proiectarea comportamentală
(5’ teorie)
Abordarea E-R, nu este un instrument suficient de complex pentru proiectarea „semantică” a BD OO
- nu furnizează bagajul logistic necesar pentru modelarea comportamentului
O (entităţile nu au proprietatea de încapsulare). În implementarea unei
ierarhii de clasă nu se vor separa datele de prelucrare, definindu-se deodată
atât proprietăţile, cât şi metodele. Metodele pot fi clasificate în trei grupe
mari:
a. Constructori şi destructori. Constructorii creează noi O, cărora le
Citire
atribuie un OID. Destructorii sunt metode care şterg O de care nu mai este
nevoie & recuperează spaţiul de memorie pe care acesta îl ocupau. În unele
sisteme destructorii se lansează singuri. Atunci când un O nu mai este referit de nici un alt O,
acesta este considerat inutil şi este distrus;
b. Metode de acces - returnează valoarea unei sau mai multor proprietăţi, sau un set de astfel de
valori din cadrul unui O. Pentru a afla valoarea proprietăţii Media a unui O STUDENT vom
invoca o metodă de acces. Acestea se mai numesc şi metode de tip GET;
c. Metode de transformare - schimbă valorile proprietăţilor unui O. La sfârşitul unui an
universitar studenţii care au obţinut un baremul de credite vor trece în anul de studiu următor
(dacă nu e ultimul) → aplicarea unei metode care incrementează anul de studiu - metode de tip
PUT.
Pentru a putea şti ce metode se pot utiliza, trebuie inventariate toate metodele posibile. Aceasta
presupune fie identificarea tuturor claselor din care vom extrage toate metodele definite, fie vom
controla întreaga aplicaţie pentru depistarea metodelor care asigură funcţionalitatea solicitată.

de date
Comparaţii între modelul OO şi R
(10’ teorie)
[Sitar2005]
Între modelul OO şi R există puţine similitudini de terminologie, chiar dacă
aceşti termeni se ascund în general concepte asemănătoare. Pentru
familiarizarea cu terminologia şi a face o comparaţie de la acelaşi nivel:
Modelul OO Modelul R
Clasă Relaţie
De reţinut
O Tuplu
Atribut, Proprietate Atribut
Metodă nu este implementată în model
Comparaţie de terminologie între modelul OO şi modelul relaţional
În ce privesc diferenţele la capitolul structură, operaţii şi reguli de integritate, [Lungu] 3 comparaţii.

Ierarhia de clasă Schema BD
Definiţia de clasă Definiţia relaţiei
... ...
Identificatorul de O Cheie primară
Moştenirea de clasă –
Comparaţia structurii între modelul OO şi modelul R
Definirea, ştergerea şi modificarea unei clase Definirea, ştergerea şi modificarea unei relaţii
sau a unui O sau a unui atribut
Definirea, ştergerea sau modificarea metodei –
Crearea unui O Adăugarea unui nou tuplu în cadrul relaţiei
Transmitere/comunicare mesaje –
– Selecţie
– Join
– Proiecţie
Comparaţia operaţiilor între modelul OO şi modelul R
Protocol de O –
Încapsulare –
Identificator de O Integritatea entităţii
Integritate referenţială Integritate referenţială
Comparaţia regulilor de integritate între modelul OO şi modelul R
Referitor la disputa teoretico-comercială dintre OO şi R, există mai multe curente.
 Unul susţinătorilor modelului R care consideră că trebuie menţinut
neschimbat în domeniile în care şi-a dovedit eficienţa, iar pentru activităţile
complexe, propun o extensie OO.
 Adepţii modelului OO - sistemele OO de pe piaţă ar trebui să fie mai
puţin exclusiviste conform cu cerinţele, recomandând necesitatea unei
adaptări a acestora şi pentru activităţi pentru care sistemele R deţin
Citire monopolul.

de date
Elemente de SGBDOO
(10’ teorie)
SGBDOO reprezintă o nouă generaţie de SGBD-uri, după cele ierarhice, reţea reprezentând
& relaţionale. Ideea - de a descrie mai uman lumea reală, nu riguros, matematic şi abstract ca în
sistemele R.
Un SGBDOO - o aplicaţie cu facilităţi de memorare persistentă, care asigură recunoaşterea
obiectelor ca identităţi separate, înlesnesc moştenirile şi permit
definirea tipurilor abstracte de date [Khoshafian & Abnous 1990].
După părerea unor autori, există un set minimal de caracteristici pe care

trebuie să îl îndeplinească un sistem SGBDOO:
1) asigurarea funcţionalităţii BD;
Definiţie
2) acceptarea identităţii O;
3) asigurarea încapsulării;
4) acceptarea de O cu structuri complexe.
În replică Date - analogie cu SGBDR, se întreba dacă un SGBDOO este sau
nu în sine un SGBD, deoarece, după un studiu amănunţit s-a constatat că
mai toate sistemele OO nu satisfac următoarele caracteristici:
1) partajarea datelor între aplicaţii;
2) independenţa fizică;
3) interogări ad-hoc;
De reţinut 4) vederi şi independenţă logică de date;
5) constrângeri de integritate declarative şi independente de aplicaţie;
6) proprietatea datelor şi un mecanism de securitate flexibil;
7) controlul concurenţei;
8) existenţa unui catalog general;
9) posibilitatea de proiectare a BD independent de aplicaţie.
Lungu – pornind de la primul manifest a BDOO (al bazelor de date, SGBDOO urmăresc trei principii
definitorii:
 într-un SGBDOO se folosesc funcţii ce conţin metode ale BD şi trebuie
să fie cât mai compacte, încapsulate şi ascunse mediului extern;
 SGBDOO trebuie să preia avantajele din SGBDR. Aceste avantaje se
referă doar la două aspecte, şi anume la accesul neprocedural şi
Citire independenţa datelor;
 SGBDOO să ofere interfaţă pentru alte tipuri de sisteme.
Date - un SGBDOO este mai degrabă „un kit de construcţie a sistemului SGBD”, deoarece după
instalare încă nu poate fi utilizat pentru gestiunea BD. Pentru a deveni funcţional mai trebuie instalate
clase sau biblioteci care să-i asigure funcţiile specifice BD.
de date
Manifestul sistemelor BDOO
(10’ teorie)
În 1989 - articol intitulat „Manifestul sistemelor de baze de date orientate obiect” (al 2-lea) -
autorii elogiază sistemele OO, considerate tehnologia care va revoluţiona
lumea BD. Victima era sistemul R, care după 3 decenii de existenţă, era
considerat uzat moral. SGBDOO erau considerate soluţia garantată pentru
orice domeniu, lucru pe care însă istoria l-a infirmat.
Printre subiectele abordate - specificarea regulilor pe care un SGBDO
trebuie să le urmărească. Aceste reguli trebuie să acopere atât conceptul de
Citire
SGBD, cât şi de OO. Din cele 13 reguli, primele 8 se adresează OO, în timp
ce ultimele 5 se referă la SGBD-uri.
1. Trebuie să permită crearea de O complexe - pornind de la O de bază, prin utilizarea
constructorilor ca SET, TUPLE şi LIST (ARRAY); constructorii trebuie să îndeplinească în
plus condiţia de ortogonalitate, să se poată aplica fiecare atât la O de bază, cât şi la cele
complexe;
2. Trebuie să asigure suport identităţii obiectelor - O trebuie să fie unic identificabile în cadrul
sistemului, identitatea nefiind condiţionată de valoarea atributelor lor;
3. Trebuie să ofere suport pentru încapsulare - metodele sunt integrate în O, modul de
implementare ascuns. Utilizatorii pot accesa aceste metode prin intermediul mesajelor. Există
însă şi situaţii când se renunţă la încapsulare, de exemplu, cazul interogărilor ad-hoc;
4. Trebuie să ofere suport pentru clase sau tipuri - un sistem poate acoperi doar unul din cele
două concepte, fie tipuri (domenii), fie clase. Acestea trebuie să fie accesibile utilizatorului;
5. Tipurile/clasele trebuie să posede capacitatea de moştenire - o subclasă moşteneşte
atributele şi metodele superclasei din care provine;
6. Trebuie să ofere posibilitatea de legare dinamică - metodele trebuie să poată fi aplicate unor
tipuri mai generale, stabilindu-se doar în momentul execuţiei ce tip trebuie să solicite;
7. Limbajul de manipulare a datelor va furniza completitudine de calcul;
8. Setul de tipuri de date trebuie să fie extensibil. Utilizatorul trebuie să beneficieze de
facilitatea de a crea noi tipuri de date pornind de la cele predefinite;
9. Asigurarea suportului pentru persistenţă a datelor – datele create trebuie să rămână stocate
în memoria fizică, chiar şi după ce procesul respectiv a luat sfârşit. Utilizatorul trebuie degrevat
de sarcina de a face salvări manuale ale conţinutului BD;
10. SGBDOO trebuie să poată gestiona BD de dimensiuni mari - trebuie să pună la dispoziţie
tehnici transparente pentru utilizator prin care să poată gestiona eficient atât obiecte de
dimensiuni mici, cât şi de dimensiuni mari;
11. SGBDOO trebuie să ofere mecanisme de control a concurenţei;
12. SGBDOO trebuie să fie înzestrate cu mecanisme de control a refacerilor;
13. Sistemele trebuie să aibă capacitatea de interogare facilă a datelor - trebuie să fie capabil
să rezolve interogări ad-hoc eficient şi independent de aplicaţii. Nu sunt necesare limbajele de
interogare.
În plus sistemul trebuie să fie dotat cu instrumente grafice care să amelioreze dialogul.
În manifest se mai întâlnesc şi propuneri cu titlu opţional: moştenirea multiplă, control de tipuri şi
suprapunerea lor, distribuţia prin reţea, tranzacţii şi versiuni.

de date
Dezvoltarea de sisteme SGBDOO
(5’ teorie)
Modalităţi de abordare a implementării unui sistem OO:
a. Extensii spre BD a limbajelor OO - Limbajelor OO: C++, Java sau
SmallTalk - aplică facilităţi specifice BD clasice. Exemplu: GemStone;
b. Biblioteci pentru gestiunea BD - există biblioteci opţionale pentru
gestiunea datelor → transformarea în SGBD se face doar la cerere.
Exemple: Ontos, Versant şi ObjectStore;
c. Încapsularea construcţiilor specifice BDOO într-un limbaj gazdă.
De reţinut
Exemplu: O2, - C drept limbaj gazdă;
d. Extinderea unui limbaj de date convenţional cu facilităţi OO.
Datorită numărului mare de utilizatori SQL, producătorii de SGBDOO, îl extind cu
facilităţi O. Prima variantă de SQL standardizată şi îmbogăţită cu facilităţi O - SQL3.
Pe lângă acesta, grupul ODMG propune un standard pentru Object SQL. Exemple:
Ontos, Versant, O2;
e. Proiectarea din temelii a unui limbaj de gestiune a BD - se bazează pe crearea unui
SGBDOO de la început. Exemplu: Semantic Information Manager (SIM).

de date
Gestiunea tranzacţiilor în sisteme SGBDOO
(10’ teorie)
Indiferent de modelul de date, T - „unităţile logice de prelucrare” care asigură „trecerea BD dintr-o
stare persistentă în altă stare persistentă”. În BDR metoda folosită - blocarea.
Printre carenţele SGBDR sunt şi protocoale de blocare, în cazul tranzacţiilor
de lungă durată cu O complexe (inginerie, multimedia, GIS etc.).
Protocoalele care asigură într-un mediu distribuit controlul accesului
concurent sunt protocoalele de supraveghere - nu permit T ce solicită
aceleaşi date (O) să interfereze. Unitatea de acces - O. Cu toate acestea se
De reţinut
mai poate lucra la modificarea granulelor.
Durata mare de execuţie a T → posibilitatea de eşec a T este ridicată. T trebuie să ofere ca punct de
pornire şi punct de sosire stări coerente. Pentru refacerea stării iniţiale - versiunile sau diferite modele
de T avansate [Conolly].
Rolul versiunilor - asigurarea capacităţii de refacere în caz de pană, gestiunea accesului concurent,
jurnalizarea stărilor unui O & evaluarea mai multor soluţii care rezolvă probleme complexe, precum
cele de proiectare. Reprezentarea versiunilor – arborescentă; putem fi interesaţi nu numai de o
versiune următoare sau precedentă - putem lua orice versiune coerentă derivată din versiunile
anterioare. Exemplu, pentru O A avem versiunile VA1, VA2, VA3, dar şi versiuni derivate (imbricate)
ale acestora, precum VA12 – a doua versiune provenită din versiunea VA1 / VA21 / VA213 a treia versiune
a versiunii VA21. Ansamblul versiunilor luate în consideraţie de o T la un anumit moment dat -
configuraţie de O.
Ontos, Versant, ObjectStore, Objectivity/DB, Itasca furnizează forme de administrare a versiunilor

[Conolly]. - mai multe tipuri de versiuni; au fost identificate în cadrul sistemului Itasca:
 Versiuni tranzitorii - stocate în mediul privat de lucru al celui care le creează - instabile şi
nu pot fi şterse. Se creează de la început pe baza unei versiuni puse în circulaţie a BD
publice / pe baza unei versiuni de lucru / chiar a uneia tranzitorii;
 Versiuni de lucru - memorate în spaţiul privat de lucru al utilizatorului care le creează -
stabile, nu pot fi reactualizate, pot fi şterse de autori;
 Versiuni puse în circulaţie - stocate într-o BD publică prin verificarea prealabilă a versiunii
de lucru. Versiunile - stabile, nu pot fi reactualizate şi nici şterse.
Itasca cere aplicaţiilor să specifice dacă o clasă poate sau nu poate avea versiune. Dacă clasa acceptă
versiuni, la crearea unui O al clasei, la prima versiune se va crea şi un O
format din informaţiile privind administrarea versiunilor.
La accesarea în paralel a O de dimensiuni mari, aplicarea protocoalelor de

blocare nu este strategie eficientă. Versiunile - importante în gestiunea
accesului concurent deoarece utilizatorii pot accesa versiuni diferite ale
Citire
aceluiaşi O, fără a exista pericolul interferenţei T. Pentru garantarea
serializabilităţii se folosesc metode de ordonare a mărcilor de timp şi
versiuni multiple ale aceluiaşi O, cu condiţia ca orice T să vadă un set coerent de articole de date ale
aceluiaşi O. Atunci când T efectuează operaţii de actualizare se va crea o nouă versiune, dar este
necesar ca sistemul s-o reţină şi pe cea veche. Operaţiile de citire cer sistemului să furnizeze o
versiune astfel încât să nu fie afectată capacitatea de serializare. Mărcile de timp se stabilesc pentru
fiecare versiune a unui O, astfel:
- pentru citire a versiunii curente a O, marca de timp va fi cea mai mare valoare a mărcilor
tuturor T care au citit cu succes versiunea curentă;
- pentru scriere a versiunii curente a O, marca de timp a acesteia va fi valoarea mărcii tranzacţiei
care a creat versiunea curentă [Connolly].

de date
Standarde legate de SGBDOO
(5’ teorie)
În 1989 s-a format OMG (Object Management Group) - consorţiu non-profit care cuprinde
producătorii de soft şi hard - scop promovarea orientării O & dezvoltarea de
standarde în domeniu. Consorţiul, la finele mileniului trecut - aproximativ
700 de membri certifică conformitatea produselor cu standardele elaborate.
Standardele propuse sunt supuse procesului de standardizare ISO/ANSI.
Facilităţile standard urmăresc:
 execuţia concurentă: execuţia simultană de metode asupra unor O de
Citire
pe un sit local sau de pe situri diferite;
 T distribuite;
 realizarea versiunilor;
 notificarea evenimentelor: contribuie la activarea evenimentelor în funcţie de anumite
evenimente;
 internaţionalizarea: uniformizarea variantelor diferitelor ţări.
1990 OMG publică ”Object Management Architecture” - descrie un model de referinţă pentru
aplicaţiile distribuite. În raport cu acest model, s-au identificat modelul de O (OM - Object Model),
brokerul de cerere de O (ORB – Object Request Broker), serviciile de O şi facilităţile comune
[Conolly].
OM - model abstract de proiectare portabil, utilizat în comunicarea cu sisteme orientate O. Un

solicitant trimite o cerere pentru servicii de O la ORB. Acesta conţine informaţii despre toate O din
sistem & serviciile pe care acestea le asigură. Brokerul expediază mesajul la furnizorul de serviciu
care prelucrează mesajul şi trimite către solicitant răspunsul tot prin intermediul brokerului.
ORB transmite şi recepţionează mesaje şi răspunsuri între O. Dacă este necesar va asigura şi conversia
mesajelor pentru a fi recunoscute de către O. Asigură transparenţa la localizare pentru O care
interacţionează.
Serviciile de O - furnizează funcţiile principale pentru sarcinile de bază ale O. Referitor la serviciile
pentru BDOO, Connolly: colectarea (suport pentru colecţii de date), controlul concurenţei,
administratorul de evenimente (componentele pot manifesta dinamic interesul pentru O),
exteriorizarea, brevetarea, ciclul de viaţă (asigură operaţii de manipulare a O asupra grupurilor de O
înrudite), denumirea, persistenţa, proprietatea, interogarea, relaţia, securitatea, timpul (reprezentare
unică şi unitară pentru toate sistemele de calcul implicate), comeciantul (dă O posibilitatea să-şi facă
„publicitate” serviciilor lor, iar altora să se „aboneze” la un serviciu) şi T.
În aplicaţiile clasice, facilităţile comune erau realizate prin multiplicarea codului pentru fiecare
aplicaţie care-l solicita. În OO, aceste facilităţi sunt implementate prin intermediul interfeţelor de
clase. Facilităţi: imprimarea, vizualizarea unui document, corectarea ortografică, poşta electronică
etc. Facilităţile comune pot fi împărţite în facilităţi orizontale comune şi facilităţi verticale pe domenii
(transport, financiar, telecomunicaţii etc.)
de date
Specificaţia CORBA (Common Request Object Arhitecture)
(5’ teorie)
Specificaţia arhitecturii brokerului de cereri comune se bazează pe un mediu bazat pe brokerul ORB.
Arhitectura CORBA defineşte părţile componente şi structura brokerului de
O. Astfel de specificaţii se referă la limbajul de definire al interfeţelor (IDL
- Interface Definition Language) şi interfeţele de programare ale aplicaţiilor
(API - Application Programming Interface) ce autorizează legăturile client-
server cu implementare caracteristică unui broker de O. Facilităţile acestui
tip de arhitectură sunt extinse de la versiune la versiune, iar componentele
Citire
cooperează din ce în ce mai închegat. Elementele versiunii:
 limbajul de definire al interfeţelor - la descrierea interfeţelor claselor
în mod transparent faţă de SGBD sau de limbajele de programare;
 „modelul tip” ce defineşte valorile transmisibile prin intermediul reţelei;
 depozitul de interfeţe - oferă informaţii asupra interfeţelor şi tipurilor în vederea posibilităţii
construirii unei cereri dinamice în timpul execuţiei;
 metode de obţinere a interfeţelor şi specificaţiilor O;
 metodele de conversie a OID înspre şi dinspre şiruri de caractere.
Pornind de la definiţiile IDL O CORBA pot fi reprezentate într-un limbaj particular sau în sisteme de
O, ca C, C++, SmallTalk şi Java.
Există produse care se conformează arhitecturii CORBA: DEC, Sun, HP, IBM, Object Design Inc.,
Objectivy etc.

de date
Modelul ODMG (Object Database Management Group)
(5’ teorie)
OMG - încercare de standardizare a tehnologiei O în general, ODMG încerca definirea standardelor
pentru SGBDO. Iniţial: GemStone Systems, Object Design, O2,
Technology, Versant Object Technology, UniSQL, POET Software,
Objectivity, IBEX Computing şi Lockheed Martin. Modelul determină
„semantica încorporată” pe care un sistem orientat OO înţelege şi o poate
accentua. Bibliotecile şi clasele care se bazează pe această semantică trebuie
să fie compatibile cu mai multe tipuri de SGBDOO. Componentele
Citire
importante ale arhitecturii ODMG – lansate pentru prima dată în 1993 –
sunt:
 modelul de O;
 limbajul de definire al O;
 limbajul de interogare al O (OQL – Object Query Language);
 cuplarea la C++, SmallTalk şi Java.
Printre elementele nou introduse în versiunea ODMG 2.0:
 o nouă legătură pentru limbajul de programare al Sun;
 revizuirea versiunilor anterioare pentru suportul semanticii legăturii BDOO cu multiple
limbaje;
 un standard privind deschiderea spre comunicare dintre BD.

de date
Arhitectura sistemelor SGBDOO distribuite
(5’ teorie)
În mediu distribuit arhitectura care se pretează cel mai bine este arhitectura client-server. Serverul -
pe acelaşi sistem de calcul cu BD. Clientul poate fi pe acelaşi sistem sau pe
unul diferit. Clientul comunică cu toate serverele care au în gestiune
informaţia solicitată. Există situaţii când mai mulţi utilizatori solicită resurse
şi prelucrări aceluiaşi server. Noţiunea de client-server este generică,
sistemele O pot avea implementate diferite variante, diferenţierea făcându-
se doar prin funcţionalităţile atribuite componentelor. Tipurile de arhitecturi
Citire
sunt:
a. Server de O - pe server se desfăşoară procesele: gestiunea memoriei,
a blocărilor & a mărcilor de timp, a operaţiilor din memoria secundară, pornirea unei
sesiuni de lucru normale / a uneia de refacere ca urmare a unui accident, controlul
integrităţii şi a securităţii, optimizarea interogărilor şi execuţia procedurilor stocate
asociate BD. Componenta client: gestiunea tranzacţiilor şi realizarea interfeţei cu mediul
de programare. Deşi serverul pare destul de încărcat cu alocarea sarcinilor, acest tip de
arhitectură este considerat cea mai bună soluţie în cadrul unui SD cu prelucrare directă
între O;
b. Server de pagini - sarcinile sunt atribuite clientului; serverul - doar operaţiile privind
memoria secundară şi furnizarea de pagini pentru client;
c. Server de BD - majoritatea operaţiunilor – serverul; clientul transmite doar cererile către
server, primeşte rezultatele pe care le oferă apoi aplicaţiei. Este varianta abordată de către
multe SGBDR [Loomis1992];
d. Server mixt - funcţiile serverului pot fi asigurate de un SGBDR – 2 module, unul
manipulează cererile de O sub forma de OID-uri, iar celălalt modul gestionează T şi
memorează O rezultate în tabele R. Abordarea este utilă în cazul sistemelor O-R şi la
integrarea BD federative.
Locaţia şi modul de execuţie al metodelor - sistemele comerciale utilizează fie abordarea prin
intermediul unor fişiere externe ca la SGBD-urile clasice, fie abordarea prin
BD, legarea fiind una întârziată. A doua – utilizată de GemStone şi Itasca –
este preferată - avantaje:
 Eliminarea codului redundant - se reduce dimensiunea programelor
prin replicarea metodei, ori de câte ori este invocată;
Citire  Simplificarea modificărilor – o actualizare a unei metode se va
efectua o singură dată & orice aplicaţie va apela metoda în noua formă. În
cazul anterior ar fi fost necesar ca noua metodă să fie recopiată în codul
aplicaţiilor care o solicită; se elimină posibilele conflicte dintre versiunile aceleiaşi metode;
 Securitatea metodelor - înglobarea metodelor într-o BD semnifică automat garantarea
securităţii chiar de către SGBDOO;
 Partajarea concurentă a metodelor - metodele - puse la dispoziţia utilizatorilor (aplicaţiilor)
pentru accesare concomitentă. Potrivit drepturilor şi privilegiilor pe care le oferă sistemul, se
interzice utilizatorilor să execute concomitent actualizări asupra metodelor;
 Integritate sporită - Constrângerile de integritate pot fi gestionate coerent şi facil de către
sistem.

de date
Avantajele şi dezavantajele sistemelor orientate-obiect
(20’ teorie)
SGBDOO – mai bune în anumite condiţii decât SGBDR dar au şi dezavantaje [Conolly].
Avantaje
 Caracteristici semantice superioare - modelul O s-a dezvoltat pentru a acoperi rigiditatea
unor aspecte reproşate abstractului şi ultra-matematizatului model R. O şi
sistemul lor de manipulare şi gestionare îşi propun să fie naturale &
apropiate de lumea reală. Pot exista O cu structuri complexe bazate pe tipuri
implicite / definite de utilizator - comportamentul şi esenţa relaţiilor cu alte
entităţi sunt memorate în interior. Aceste caracteristici se referă şi la noile
facilităţi ale limbajului de interogare. Exploatează accesul navigaţional,
De reţinut
mult mai expresiv decât cel bazat pe conţinut → asigură suport pentru
tratarea interogărilor recursive şi a celor care presupuneau multe operaţii de
join. Standardul ODMG propune şi o alternativă la SQL - OQL.
 Capacitatea de extindere - sistemele O permit utilizarea unor tipuri noi faţă de cele
implementate apriori – predefinite sau tipuri utilizator; odată atribuite proprietăţile unui O,
acestea pot fi moştenite de subclasele lui. La fel şi metodele. Suprascrierea - importantă -
permite gestionarea facilă a unor cazuri speciale. Relaţiile dintre entităţi superclasă – subclasă
permit reutilizarea unei părţi a codului în cadrul unui sistem OO, facilitând dezvoltări şi
întreţineri mai rapide.
 Rezolvarea nesincronizării de impedanţă - Existenţa unei singure interfeţe între limbajul
de manipulare şi cel în care se scriu aplicaţiile determină eliminarea acestui neajuns.
 Facilităţi pentru actualizarea schemei BD - din încapsularea datelor şi a transparenţa
implementării metodelor pentru exterior, utilizatorul nu va sesiza eventualele modificări
structurale sau comportamentale, iar aplicaţiile nu vor avea în general de suferit de pe urma
acestui aspect.
 Suport pentru T mari consumatoare de timp - structuri complexe şi dimensiuni mari a
datelor, în mediu distribuit, protocoalele de control a accesului, specifice sistemelor T R, nu
pot fi aplicate şi asupra BDOO. Pentru gestiunea T mai eficient, fără necesitatea unor refaceri
de anvergură în caz de accidente, sistemele O au un mecanisme îmbunătăţite pentru gestiunea
T, bazate în general pe exploatarea versiunilor.
 Suport pentru BD avansate - domenii – CAD, CAM, CASE, GIS, OIS, gestiunea avansată
a elementelor multimedia etc. – pentru care sistemele R nu oferă un suport suficient. Sistemele
O se emulează pe aceste domenii.
 Performanţe sporite - există domenii pentru care sistemele R pure nu pot face faţă cu acelaşi
succes sistemelor OO. Uneori, raportul dintre performanţele obţinute de către fiecare este
semnificativ, iar în anumite cazuri sistemele R nu sunt capabile să ofere o soluţie.
 Costul sistemului - BDOO nu sunt SGBD-uri, ci limbaje de programare OO cărora li se
ataşează module, biblioteci / clase suplimentare, costul încropirii va fi mai redus decât cel al
unui SGBD propriu-zis.
Dezavantaje
 Existenţa unui model de date universal - sistemele OO nu au modele de date recunoscute şi
suportul teoretic este deficitar - se încearcă o standardizare, grupul ODMG
depunând eforturi în vederea realizării.
 Lipsă de experienţă - Sistemele R au în spate o vastă experienţă, de
35-40 ani de „activitate”. Sistemele OO nu au acest avantaj. Încearcă să
dezvolte o piaţă de departe dominată de sistemele R. Din punctul de vedere
al experienţei, dezvoltarea de aplicaţii se adresează unor programatori mai
De reţinut
experimentaţi.
 Necesitatea elaborării de standarde. ODMG se preocupă de
problema standardizării. Rezultatul muncii lor nu se poate concretiza decât în standarde
temporare, până la certificarea lor de către ISO/ANSI. Acesta se referă atât la SGBDOO, cât
şi la limbajul de manipulare al O.
 Optimizare interogări vs încapsulare - pentru optimizarea interogărilor este necesară
cunoaşterea structurii interne a O → conflict cu încapsularea, ermetizarea O, structura fiind
ascunsă exteriorului. → uneori se apelează la interogări încapsulate sub forma unor metode.
Acest lucru conduce la problema imposibilităţii execuţiei unor interogări ad-hoc.
 Blocările de granuaritate mare compromit performanţa - Blocarea - pe larg aplicată de
către sistemele OO. Totuşi, în cazul O complexe şi de dimensiuni mari, O blocare la nivelul
întregului O ar crea serioase probleme într-un mediu concurent.
 Configurări suplimentare - SGBDOO-urile sunt medii de programare OO care trebuie
reconfigurate adecvat pentru dobândirea funcţionalităţii gestionării BD . Această operaţiune
solicită personal cu experienţă.
 Complexitatea sistemelor. Construcţia unui sistem OO & exploatarea lui sunt mult mai
complexe decât în cazul unui sistem R.
 Inexistenţa suportului pentru vederi - utilizarea vederilor a devenit o practică eficientă.
Sistemele OO nu oferă această facilitate.
 Securitate redusă - SGBDOO oferă un suport redus pentru securitate. Pentru asigurarea
extinderii pe piaţa SGBD, remedierea acestei probleme este imperios
necesară.
Concluzii
[Peter Kueng 1994]- paralelă între cele mai utilizate 10 SGBDOO de pe
Citire piaţă. A analizat în funcţie de 3 atribute importante şi a construit clasamentul
final.
Comparaţii între funcţionalităţile unor SGBDOO
Comparaţia - pe baza documentaţiei furnizate de producători. La „Caracteristici de bază”: suport

pentru date definite de utilizator, pentru relaţii PART_OF şi IS_A, moştenire multiplă etc. La
„Limbaje şi interfaţă BD”: standardele, interogările, modificarea schemei şi deschiderea spre alte
SGBD-uri. La mediile de sistem: arhitectură, precum şi la SO suportate de, respectiv client → se
poate spune că cele mai complete sisteme erau O2 şi ObjectStore. Chiar dacă la punctajul general cele
două sisteme sunt în frunte, acest lucru nu înseamnă că potenţialul beneficiar ar trebui să ia în
consideraţie doar acest aspect. Orientarea se face prin maparea cerinţelor asupra unor caracteristici
mai specifice.
Exemple de sisteme OO care dau rezultate mai bune decât cele R, cel puţin în faza de testare:
 US Air Force - iniţiative de dezvoltare a unor depozite de date
prevăzute cu sisteme de detecţie a intruşilor (IRS - Intrusion Detection
Systems) în reţele de mare viteză. Sistemele realizate utilizau sisteme R
pentru stocarea datelor. În 2001, Phillip Folk propune înlocuirea unuia
dintre sistemele R cu un de BD distribuite OO cu un mediu de detectare
automată a intruşilor (AIDE Automatic Intrusion Detection). S-a proiectat,
Citire implementat şi testat, cu Objectivity/DE → performanţe încurajatoare –
inserările de O şi regăsirile pentru interogări în care avem mai mult de o
legătură sunt mai rapide decât în cazul vechiului sistem → premisele necesare extinderii
proiectului către reţele eterogene. BD este replicată şi distribuită mai întâi într-o reţea de
dimensiuni reduse. Testele preliminare nu indică scăderi de performanţă, aşa că extinderea
proiectului către alte reţele şi alte sisteme va fi următorul pas [Folk2001].
 Cu OID în BDOO, aplicaţiile pot manipula mult mai uşor relaţiile de natură complexă dintre
O - deoarece BDOO au abilitatea de a “naviga” prin urmărirea referinţelor, gestionează relaţii
M:N bidirecţionale şi permit propagarea operaţiilor de-a lungul relaţiilor pentru a forma O
compuse. SGBDOO oferă suport redus pentru aceste lucruri, însă sistemele R nu oferă deloc.
Modelarea acestor relaţii necesită relaţii auxiliare, pe când procesarea solicită operaţiuni de
join multiple şi foarte mari consumatoare de timp. Air France utilizează produsul Versant
pentru rezervare de bilete şi repartizarea locurilor în aparatele de zbor. Air France motivează
nu prin complexitatea datelor, ci prin complexitatea relaţiilor dintre punctele de stocare a
datelor. Un sistem R ar fi trebuit să asigure aceeaşi funcţionalitate prin mai mult de 30 de
operaţiuni de join. În testele preliminare se afirmă că sistemul Oracle furniza timpi infinit mai
mari decât Versant. Ca performanţă, la 207.000 de T executate într-o zi, 99,48% din acestea
au fost executate în mai puţin de 30 de milisecunde [McClure1997].
 Exemple de companii sau instituţii în care utilizează sisteme OO:
o Bursa din Chicago derulează T cu ajutorul Versant;
o Radio Computing Services - cea mai mare companie din lume în soft pentru staţiile radio.
Produsul său Selector utilizează POET şi poate să automatizeze toate nevoile unui studio
radio: de la biblioteci de muzică, la newsroom-uri şi departamente de vânzări. Sistemul
POET permite integrarea diferitelor tipuri de informaţii într-un singur program;
o Objectivity/DB - utilizat ca depozit de date pentru denumirea componentelor, planificarea
misiunilor prin satelit şi gestiunea datelor orbitale realizate de către Motorola cu ajutorul
sistemului Iridium;
o ObjectStore se foloseşte de SouthWest Airline's Home Gate pentru a servicii turistice prin
Internet;
o Ajou University Medical Center din Coreea de Sud utilizează InterSystems' Cachè pentru
a face faţă tuturor funcţionalităţilor spitaliceşti, incluzând departamente cu misiuni critice
ca cel de patologie, laboratoare, bănci de sânge, farmacie şi radiologie;
o Large Hadron Collider la CERN foloseşte Objectivity DB. BD - testată la dimensiuni de
ordinul sutelor de TB la rate de transfer de 35 MB/s;
o 2000, Stanford Linear Accelerator Center (SLAC) înmagazina 169 TB de date referitoare
la producţie utilizând Objectivity/DB. Datele erau distribuite de-a lungul a câteva sute de
noduri de procesare şi folosea peste 30 de servere on-line [Oasanjo2001];
o Northwest Natural Gas utilizează un SGBDOO pentru informaţii referitoare la clienţi -
stochează informaţii relativ la 400.000 de clienţi şi este accesat de 250 de reprezentanţi de
servicii din 7 districte din zona Pacificului de N-V;
o Ameritech Advanced Data Services - un sistem OO care gestionează un SI ce cuprinde
activitatea de contabilitate, introducerea ordinelor de vânzare, politica de preţuri, suport
pentru vânzări etc. şi este accesat de mai bine de 200 de persoane dispersate în 5 state
[Bray1997].
→ caracteristici esenţiale pe baza cărora sistemele OO au acaparat o parte din piaţa SGBD:
 BD de dimensiuni mari de GB până la TB, care pot fi gestionate fără
probleme.
 Aplicaţiile de BD - suport eficient pentru legături complexe dintre
entităţi.
 Tipurile de date sunt în general destul de complexe, iar sistemele OO
De reţinut integrează eficient date de complexităţi diferite.
 Permit o distribuire a aplicaţiilor între multe situri, multipli utilizatori
şi arii geografice însemnate.
 Aplicaţiile având ca mediu de distribuţie Internetul se potrivesc cu tehnologia OO şi se
întrevede şi în continuare un succes exploziv al acestor aplicaţii.
→ SGBDOO - „sistemele numerelor mari”, fie că e vorba de dimensiunea BD, număr de situri, număr
de utilizatori, accese concomitente, complexitatea structurilor, operaţiile de calcul, cardinalitatea
relaţiilor dintre entităţi, semantică şi de ce nu şi domeniile de aplicabilitate. Cu toate acestea,
supremaţia va fi asigurată tot de către sistemele R, în variantă pură sau extinse cu facilităţi OO.
II.3.3. Sumar
În cadrul capitolului s-au tratat problemele referitoare bazele de date obiectuale. Sunt analizate
diferenţele faţă de cele relaţionale, dar şi elemente specifice referitoare la mopdele de date OO,
SGBD-uri OO sau distribuirea BD OO.

 să studieze modul în care se transcrie orientarea obiect în baze de date de tip SQL;
 limbaje de suprafaţă pentru BDOO pe baza C# şi Visual Basic .NET;
 să studieze exemple din MS SQL Server 2005 şi Oracle;
 abordarea practică a consideraţiilor OO vor reprezenta 20% din ponderea notei pentru proba
practică;
de consultaţii.

 Enumeraţi câteva argumente în favoarea modelului OO. Vezi pagina 33.
 Care sunt limitările bazelor de date relaţionale? Vezi pagina 34.
 Definiţi conceptul de obiect. Vezi pagina 36.
 Ce sunt clasele de obiecte? Vezi Clasele pagina 37.
 Daţi câte un exemplu pentru fiecare tip de relaţie dintre obiecte. Vezi
pagina 39.
Teme de  Ce este un SGBDOO şi care sunt cerinţele minimale pe care acesta
reflecţie trebuie să le îndeplinească? Vezi pagina 44.
 Enumeraţi şi detaliaţi avantajele şi dezavantajele sistemelor orientate-
obiect. Vezi pagina 52.
 Treceţi în revistă câteva sisteme obiectuale din diverse domenii de activitate. Vezi Concluzii
pagina 54.

Date C.J. 2005, T. Connolly. C. Begg, A. Strachan, 2001, D.A. Sitar-Tăut 2005, Baze de date,
Proiectare, Implementare, Gestionare, Addison-Wesley, Teora, 2001, BDASEIG, 2002, M.
Fotache, 2001 şi 2003].
II.4. Capitolul 4 – Baze de date Obiectual Relaţionale şi alte tipuri de baze de
date

Scopul capitolului este familiarizarea cu Orientarea Obiectual Relaţională şi disputele academice pe
marginea tematicii din cadrul celor trei manifeste
 Studierea problematicii generale OR.
 Studierea diferenţelor dintre modelele OO, R şi OR.
 Analiza conţinutului celor 3 manifeste în domeniul BD
 Alte tipuri de baze de date
Orientarea Obiectual - Relaţională (OO)

↓
Comparaţia dintre modelele OO şi OR
↓
Cele 3 manifeste în domeniul BD
↓
SQL3 – implementare a modelului OO
de date
Consideraţii generale asupra SGBDOR
(10’ teorie)
Încă o perioadă SGBDR – vor deţine supremaţia pe piaţa BD. La sfârşitul

mileniului 2, vânzările anuale > 10 G$ [Connolly & Begg 1998]; dacă
includem şi echipamentele > 25 G$, cu ritm de creştere de 25%. SGBDOO
au atins în anul 1996 o valoare a vânzărilor de 150 M$, în 1997 acoperă
3% din piaţa BD. Aşteptările creşterilor anuale - 50%, → depăşeşte ritmul
anual de creştere al întregii pieţe de BD [Connolly]. Acest deceniu va fi
Citire
controlat de SGDBR, cu toate că există o expansiune mult mediatizată a
SGBDOO. Tehnologiile acestora devin - bine închegate şi performante, iar domeniile ţintă teoretic
nelimitate. SGBDR vor rezista încă mult timp - costurile unei schimbări radicale înspre OO sunt
foarte mari, există domenii care se pretează mult mai bine principiului R decât celui O şi
conservatorismul utilizatorilor de sistemele R; pe mainframe-uri mai rulează sisteme ierarhice şi reţea
– ca IMS sau IDMS.
Comercianţi importanţi în BD n-au tranşat clar spre un curent sau altul şi au ales o soluţie de mijloc,
de interimat, până se limpezesc apele - vor să împace conservatorismul SGBDR cu avangardismul
SGBDOO. Renunţarea la R – neglijarea unei experienţe bogate – respingerea OO → pierderea unui
avantaj competiţional. → SGBDOR / servere universale de date / SGBD-uri universale -
extinderea (integrarea) tehnologiei DBR cu tehnologia OO.
SGBDOR - capacităţi de stocare OO sistemelor R - integrează gestiunea datelor organizate în tuple

şi atribute - cu O complexe ca seriile temporale, date GIS, tipuri media ca audio, video, imagini, aplet-
uri etc. Prin încapsularea metodelor cu structurile de date, un „server” SGBDOR - operaţii analitice
complexe de regăsire şi transformare a obiectelor multimedia şi a altor tipuri complexe. Abordarea
OR a moştenit robusteţea gestiunii tranzacţiilor şi alte facilităţi performante de la R şi flexibilitatea
OO. Proiectanţii BD pot lucra cu structuri tabelare şi DDL cu facilităţi de gestiune O. Limbajele
procedurale şi de interogare, precum şi interfeţele SGBDOR sunt relativ aceleaşi: SQL (SQL3),
limbajele procedurale ale furnizorilor cunoscuţi, ODBC, JDBC şi toate interfeţele sunt extensii ale
limbajelor relaţionale. Liderii: Oracle, IBM, Informix [Grimes 1998].
Se întrevede a fi un real succes, chiar dacă o serie de producători mai

jonglează încă cu terminologia şi există discrepanţe între ceea ce pretind că
este sistemul produs de ei şi realitatea faptică [Date&Darwen 2000]. Se
întrevede un boom al sistemelor OR, [Connolly] în scurt timp vor câştiga un
segment de piaţă cu 50% mai mare chiar decât cel al sistemelor R.
[Stonebraker 1998] - piaţa BD - dominată de 4 mari categorii de produse:

Citire
fişiere clasice, SGBDR, SGBDOO şi SGBDOR. Clasifică după gradul de
complexitate al modelelor de date şi extensibilitate, facilităţile de regăsire a
informaţiei, şi după facilităţile de exploatare în regim multiutilizator:
S-V - fişierele clasice = de procesoarele de text, şi tabeloare, incluse în pachete standard precum MS
Office, Works, Lotus Notes etc., sau disparate. Pentru exploatarea lor este nevoie doar de SO şi
cunoştinţe de utilizare. Prezintă suport redus pentru lucrul în reţea, datele sunt de complexitate redusă.
Rar sunt supuse unor prelucrări specifice BD.
N-V – SGBDR - sunt de complexitate relativ redusă, excelează la regăsirea de date şi gestiune
distribuită prin intermediul reţelelor de calculatoare.
S-E – SGBDOO - complexitatea structurilor lor de date ridicată, posibilitatea de regăsire a

informaţiilor sunt deficitare, deoarece O - cutii negre, ascunzând detaliile pentru exterior. Nici la
servicii multiutilizator nu sunt mari.
N-E - SGBDOR - preiau avantajele ambelor tehnologii, încearcă să înlăture neajunsurile acestora.
Extensia lor OO poate duce la date complexe pentru acoperirea unor domenii rămase descoperite de
tehnologia R, facilităţile de căutare şi serviciile la nivel multiutilizator - moşteniri ale sistemelor R.

de date
Manifeste ale BD
(10’ teorie)
15 ani - preocupările din BD concentrate pe modelul O. Conceptul de O era considerat o revoluţie

ştiinţifică. Există lupte de culise şi victime mai mult sau mai puţin colaterale. Orice luptă → pioni de
sacrificiu. Acesta este cazul şi modelului R. Multă lume a privit cu entuziasm nemărginit expansiunea
modelului O, ca eliberatorul de sub tiranicul „jug” de decenii a modelului R.
Manifestele BD - dezbateri academice în favoarea sau defavoarea unor sisteme de BD. Primele 2 -
pentru sistemele OO & afirmă că sistemul viitorului nu poate să conţină
sisteme din prima generaţie şi nici măcar dintr-a doua (R), al 3-lea readuce
în atenţie sistemele R.
 1989 „Manifestul sistemelor de BD OO” [Atkinson 1989] - aduce
elogii BDOO şi sfidează meritele modelului R
Citire  Al doilea manifest – „Manifestul sistemelor de BD din a treia
generaţie” - Third-Generation Database System Manifesto – vine totuşi în
apărarea modelului R căruia-i recunoaşte o parte din meritele majore, şi
anume 2: „accesul neprocedural la date şi independenţa datelor”, pe care următorul val de
sisteme de BD ar trebui să le păstreze. Propune 13 caracteristici pentru sistemele proclamate
ca făcând parte din generaţia a treia:
1. Un sistem G3 trebuie să suporte un set complex de tipuri;
2. Moştenirea recomandată;
3. Funcţiile, procedurile, metodele BD şi încapsularea, nu trebuie ignorate;
4. SGBD-ul trebuie să genereze identificatori de tuplu, în cazul în care utilizatorul omite
să o facă;
5. Regulile (declanşatori şi constrângeri) trebuie integrate în sistem;
6. Accesul prin programe la BD trebuie să se facă prin secvenţe de cod al unui limbaj de
nivel înalt, neprocedural;
7. Colecţiile trebuie să poată fi specificate atât prin enumerare, cât şi prin interogări;
8. Se impune utilizarea vederilor reactualizabile;
9. Indicatorii de performanţă nu trebuie să fie influenţaţi de modelul de date;
10. SGBD-urile trebuie să fie disponibile pentru o multitudine de limbaje de nivel înalt;
11. Recomandat ca limbajele de nivel înalt să posede „forme persistente”. „Toate vor fi
susţinute peste un singur SGBD, prin extensii ale compilatoarelor şi un sistem
complex din timpul execuţiei”;
12. Indiferent ce s-ar întâmpla, SQL-ul constituie „limbajul de date intergalactic”;
13. În dialogul client-server, interogările şi răspunsurile la acestea, trebuie să fie nivelul
inferior de conversaţie [Conolly].
 Al 3-lea manifest apare în momentul în care cauza sistemelor R era aproape pierdută.
Prima versiune neoficială - la începutul 1994, urmând a fi publicat în 1995. Materialul a
suferit o serie de modificări, ca urmare a unor discuţii deschise în diverse cercuri
academice. Chris Date şi Hugh Darween – în 2000 au publicat întreg manifestul
„Fundament pentru sistemele de BD viitoare” – Foundation for Future Database
Systems. The Third Manifesto. Reprezintă o bulă de oxigen pentru modelul R, cel puţin
din punct de vedere teoretic. Materialul este foarte bine documentat teoretic, logic,
didactic şi bine orientat psihologic, fapt menţionat pe coperta interioară: „Am dori să
dedicăm această carte filosofilor şi poeţilor de pretutindeni”.
Autori sunt revoltaţi de locul pe care „noua generaţie” o conferă sistemelor tradiţionale şi de felul
cum înţeleg integrarea tehnologiei O cu cea a BDR în cadrul „serverelor universale”. Ei nu condamnă
apariţia acestui hibrid, însă maniera în care s-a făcut este considerată scandaloasă. Pe lângă faptul că
se doreşte a fi un material cu privire la evoluţia sistemelor de BD, ei vor să clarifice şi anumite aspecte
referitoare atât la cele două manifeste care-l preced, cât şi la curentele nocive care circulau în acea
perioadă.
În al doilea manifest se aduceau critici SQL-ului pe care unii îl confundă cu esenţa modelului R →
criticile SQL erau adresate tot modelului R. Oricât de util este acest limbaj de interogare în mediul
BDR, i-a dezamăgit profund pe coautorii manifestului. Date şi-a exprimat
dezacordul faţă de SQL → pentru a fi în acord cu teoriile iniţiale ale lui
Codd şi spre binele general al SGBD, Date şi Darwen resping fără drept de
apel SQL-ul. Propun un limbaj intitulat D, care să fie în conformitate cu
modelul R. Totuşi, datorită gradului mare de utilizare al SQL-ului se
recomandă ca acest nou limbaj să aibă o interfaţă orientată spre aceşti
Citire utilizatori, până la migrarea definitivă spre D.
Manifestul descrie recomandări şi interdicţii ale modelului R şi alte recomandări sau interdicţii
ortogonale. Una din problemele esenţiale pe care manifestul le dezbate este cea legată de domenii
(tipuri de date), variabile de R şi corespondentul lor în modelul O.
Când vorbim de domenii, ne gândim la valori simple pe care acestea pot să le ia: numere, şiruri de
caractere, valori de adevăr etc. Modelul R nu stipulează în mod explicit complexitatea ce trebuie s-o
aibă un astfel de domeniu → ca urmare a evoluţiei tehnologiei BD, trebuie luate în considerare tipuri
noi de date, pe care nimeni nu putea anticipa acum 30 de ani ca tehnologia să le reprezinte, sau să
creadă că s-ar putea să apară vreodată.
Un proces evolutiv normal → pe lângă domeniile clasice putem să avem domenii de înregistrări audio
sau video, domenii reprezentând formele geometrice sau desene inginereşti, domenii de documente
şi multe altele. Constrângerea - valorile acestor domenii poată fi manipulate numai de către operatorii
definiţi pentru domeniul în cauză. Reprezentarea internă a operatorilor, indiferent de complexitate,
trebuie să fie transparentă utilizatorului. Acelaşi lucru este cerut şi de către modelarea O,
protagonistul fiind clasa de O.
Poziţia manifestului - în cazul unui sistem R care suportă în mod adecvat domeniile, nu se va
întâmpina nici o problemă în a se suporta tipuri de date a căror exclusivitate era acordată doar O: serii
temporale de date, date biometrice, date financiare, date privind ingineria proiectării sau birotică →
sistemele OR, trebuie privite ca integrarea celor două tehnologii doar ca substituibilitatea claselor de
O cu domeniile modelului R →un sistem cu adevărat OR nu trebuie să fie altceva decât un sistem
„curat” R.
Adepţii modelului OO fac echivalenţa între clase de O şi relaţii, în locul echivalenţei clasă =
domeniu.
de date
Extensii O în cadrul sistemelor OR
(5’ teorie)
Au existat, există şi vor exista sisteme OR. Dintre acestea amintim: Postgres, PostgreSQL (variantă
gratuită), GigaBASE, OpenODB/Odapter, OSMOS, DB/2 Extenders,
Illustra, UniSQL/X, Oracle după versiunea 8.x, Informix. Toate acestea
au fost clădite pe baza unei versiuni anterioare R.
Extensiile O atribuite în general sistemelor R:

 definirea de tipuri abstracte (ADT-Abstract Data Type), tipuri definite
Citire
de utilizator pornind de la cele predefinite şi operaţiile pe care le pot suporta;
 definirea de tipuri structurate - pornind de la tipurile existente –
predefinite sau ADT-uri – utilizatorul poate să construiască structuri complexe de date;
 tipuri de date complexe, BLOB şi CLOB – Caracter Long OBject;
 introducerea posibilităţii de definire a unor date prin intermediul unor proceduri
înmagazinate în definiţia R;
 introducerea unor reguli de integritate în definiţia R;
 moştenirea;
 identificatorii de O etc.
 Elemente avansate de
baze de date
Standardul SQL3
 1979 Relational Software Inc. lansează sistemul Oracle care este

primul SGBD comercializat care se bazează pe SQL.
 1981 - IBM produce primul său SGBD, SQL/DS.
 1982-1986 SQL este subiectul unei standardizări ANSI, pentru ca un
an mai târziu norma SQL să fie adoptată de către ISO.
 1989 ANSI şi ISO definitivează standardizarea şi publică extensia
Citire SQL89 care adaugă la versiunea anterioară tratarea integrităţii datelor
 1992 apare prima formă revizuită a limbajului sub numele de SQL2 sau
SQL92. Acesta a devenit un standard internaţional
 1999 apare o nouă normă SQL, intitulată SQL:1999, sau simplu SQL3.
Cuprinde revizuiri faţă de varianta standardizată anterior, însă cele mai multe modificări ţin de
capacităţile OR ale limbajului. Printre caracteristicile de bază, se numără:
 generatorul de referinţe;
 constructorii de tipuri pentru tipurile de rânduri;
 permisiunea definirii tipurilor-utilizator, fie că sunt tipuri distincte, fie
structurate. Acestea pot participa la relaţii supertip/subtip;
De reţinut  crearea procedurilor, funcţiilor şi a operatorilor definiţi de utilizator;
există restricţii în ceea ce priveşte polimorfismul;
 suport pentru reprezentarea colecţiilor de date: şiruri, liste, mulţimi şi
multiseturi;
 suport pentru tipuri de date complexe şi de dimensiuni mari (BLOB, CLOB).
 aspectele de actualitate care totuşi nu au trecut de această etapă a standardizării, precum şi
posibile noi aspecte, intră în discuţie pentru standardul SQL4.
Alte baze de date
de date
Big Data
(10’ teorie)
În ultimii ani, tot mai multă lume interacţionează cu datele prin intermediul dispozitivelor mobile
inteligente, reţelelor de socializare, în general al internetului. Zilnic, 2,5 EB
(Exabytes, catralioane, 1018 octeţi) sunt create la nivel mondial. În raport cu
tendinţele ultimilor ani, se poate afirma că 90% din totalul datelor existente
apar în ultimii 2 ani, iar procesul este în dinamică [IBM BigData]. Volume
din ce în ce mai mari se acumulează mai ales automat datorită serviciilor
GPRS, 3 sau mai nou 4G, a unei largi varietăţi de senzori, sisteme de
De reţinut monitorizare, climaterice, date geospaţiale, reţele de socializare, servicii
email sau partajare diverse tipuri de media etc. Astfel, datele din jurul nostru
au cunoscut creşteri exponenţiale, ajungându-se la nivelul anului 2012 ca Exabytes de date, să poată
fi totuşi procesate în parametri rezonabili de timp [Francis 2012]. Aceste colecţii de date, stocate şi
prelucrabile în vederea desfăşurării în bune condiţii a activităţii, oferire de servicii în limita termenilor
agreaţi faţă de terţii implicaţi şi a extragerii de informaţii utile pentru organizaţie, poartă termenul
generic de “Big Data”.
Tot mai des, atunci când vorbim de Big Data, se remarcă următoarele 4 caracteristici – cunoscute
generic ca 4V – 3 considerate de [Zikopoulos & Eaton 2011], în timp ce unii autori constată că
numărul declarat de 4 este exagerat, când de fapt poate fi surprins şi cu doar două caracteristici [W3-
Villa], dar mai cuprinzătoare.
 Volum: Datele încearcă să surprindă cât mai fidel realitatea, de aceea trebuie să fie mai
detaliate, complexe, presupunând un volum ridicat de atribute. De asemenea, fenomenele
repetitive necesită un volum cât mai mare de instanţe. Chiar dacă ambele caracteristici fac
apel la „volum”, nu înseamnă neapărat că orice date care satisfac una sau chiar ambele valenţe
privitoare la volum, pot fi asociate cu conceptul de Big Data. Să urmărim şi celelalte
caracteristici;
 Viteză: datele cresc ca volum cu o viteză foarte mare. Viteza se referă nu atât la rata de creştere
a volumului de date, ci la viteza cu care instrumentele sunt capabile să proceseze aceste date,
pentru a le putea face disponibile beneficiarilor, într-un timp încadrabil în limita parametrilor
de calitate;
3
General Packet Radio Service, un serviciu mobil de date orientat pe pachete în cadrul sistemelor de comunicaţii
mobile
 Varietate: Datele pot proveni din diverse surse şi pot avea formate şi tipuri multiple: text,
numere, date calendaristice, imagini, secvenţe de voce sau video etc., semi- dar de cele mai
multe ori nestructurate.
 Veracitate (sau Valoare): O mică parte din volumul de date este utilizabilă în procesul
decizional, însă aceste date luate individual nu au nicio relevanţă fără aportul celorlalte.
Această caracteristică se referă la veridicitatea datelor, consistenţă, integritate şi încredere în
ele.
Pentru a putea fi catalogate Big Data, colecţiile de date trebuie să satisfacă toate caracteristicile
menţionate anterior.

de date
Bazele de date NoSQL
(10’ teorie)
Istoric
Termenul NoSQL este folosit pentru prima dată în 1998 şi se referă la acele baze de date relaţionale
ce nu folosesc SQL [Str10]. În 2009, Jon Oskarsson consfinţeşte termenul
în cadrul unei conferinţe din San Francisco, iniţiată de către susţinătorii
teoriei bazelor de date nerelaţionale, fiind mai apoi mediatizat de blogger-
ul Eric Evans [Evans 2009].
De acum, folosim denumiri precum NoSQL sau NOSQL (Not Only SQL).
Bazele de date NoSQL nu au schemă şi nu stochează date relaţionale. Ele
De reţinut
ridică problematici importante, legate de consistenţă,
durabilitate/persistenţă şi gestiunea versiunilor.
La ora actuală există următoarele categorii de baze de date NoSQL:
 Key-/Value-stores – cel mai simplu model pentru date nestructurate. Foarte eficient şi
flexibil. Dezavantaj: datele nu conţin descrierea lor
 Document databases – pentru depozite XML şi obiecte care se autodescriu. Stocarea în acest
caz este foarte ineficientă. În această categorie întâlnim subtipurile următoare:
– Baze de date relaţionale cu facilităţi XML: CLOB, XML împărţit în mai multe
tabele în funcţie de schema; SGBDR-uri care acceptă tipul ISO XML (Ex. IBM DB2,
Microsoft SQL Server, Access, Oracle Database, PostgreSQL)
– Baze de date XML native.
 Column-Oriented Databases (Baze de date pe coloane) – model foarte bun folosit în cadrul
depozitelor de date pentru date rarefiate. Putem avea coloane grupate şi agregate.
 Graf [Oracle 2012] – un model relativ nou, bun pentru parcurgerea relaţiilor, dar nu pentru
căutări generale.
Materialul de faţă nu îşi propune detalierea altor aspecte privitoare la bazele de date NoSQL.
Concluzii
 Tehnologia BDOR - în linii mari - software-ul şi metodologiile de
modelare şi înmagazinare a unor largi volume de date de tipuri şi structuri
arbitrare care să răspundă la interogări şi cereri de date. Tehnologia trebuie
să treacă dincolo de capacităţile BDR tradiţionale pentru înmagazinarea,
regăsirea şi analizarea datelor multimedia (imagini, video, audio, voce,
grafică şi animaţie), date geospaţiale, serii temporale, tipuri şi date definite
de utilizator, text liber şi ultraformatat, date semistructurate precum datele
De reţinut
HTML şi XML, controlul inteligent al versiunilor, descoperiri automate de
cunoştinţe şi şabloane comportamentale (data mining) etc.
 Există păreri că modelul R pur, însă înzestrat cu tipuri de date mai complexe, ar putea
face faţă de unul singur acestor provocări. [Date&Drween]
 Ceea ce există pe piaţa acestor sisteme hibride se referă la aplicarea unui strat de
software peste sistemul R. O abordare corectă ar presupune reproiectarea sistemului,
luându-se încă de la început în considerare evaluarea corectă a domeniilor [Date].
 Tehnica wrapperului practicată de furnizorii de sisteme OR, nu face decât să dea
impresia unor sisteme OR cârpite şi încropite în grabă, încât performanţele lor ar putea
fi mai reduse chiar decât a sistemului R de la care s-a pornit → integrarea a celor două
tehnologii – a BDR şi cea a OO – trebuie făcută în limitele decenţei. În aceste condiţii,
colaborarea va deveni fructuoasă şi generatoare de satisfacţii pentru toate părţile
implicate: teoreticieni, proiectanţi, furnizori, beneficiari direcţi şi indirecţi,
contribuind la creştere economică şi a productivităţii muncii, dezvoltarea producţiei
industriale şi a serviciilor spre satisfacţia consumatorului de rând (posibilitate de a
alege dintr-o gamă mai largă de produse şi servicii, scăderea tarifelor şi a preţurilor,
sporirea confortului individual şi al comunităţii în general).
 SGBDOR prezintă cel mai mare potenţial de dezvoltare în domeniul BD, prin
posibilitatea de atragere atât a domeniilor specifice acaparate de fiecare tehnologie în
parte, cât şi a unor domenii „interdisciplinare” pentru care niciuna dintre cele două nu
era suficiente.
 Sistemele SGBDOR au avantajul că pot fi compatibile atât cu sistemele O, cât şi cu
cele R, astfel încât trecerea la un sistem OR să se facă fără mari probleme de
compatibilitate la importul datelor din vechile sisteme. Sistemele universale trebuie să
rezolve toate problemele pentru care modelul R s-a dovedit a fi neputincios.
Producătorii şi comercianţii trebuie să profite de acest avantaj prin dezvoltarea unor
pachete de produse modulare destinate unor multiple categorii bine delimitate de
consumatori, şi nu în ultimul rând printr-o politică de preţuri adecvată.
 Ofertele producătorilor trebuie să întâlnească solicitările ale clienţilor cât mai
apropiate, iar preţurile şi pachetul oferit să fie dozate după nevoile lui şi nu înspre
domenii intangibile. Ar fi ridicol ca un patron de chioşc care doreşte să-şi tină
contabilitatea să aibă la dispoziţie doar posibilitatea de alegere a unui pachet software
care să permită atât gestiunea proceselor pentru un întreg lanţ mondial de hipermarket-
uri şi să aibă posibilitatea prelucrării de date geospaţiale, recunoaştere vocală etc. la
un preţ de zeci sau sute de mii de Euro.
 Există şi păreri sceptice împotriva acestor sisteme, chiar dacă pentru o scurtă perioadă
se pariază pe dezvoltarea şi afinitatea mult mai mare către acestea în detrimentul
sistemelor pur O. Steve McClure de pildă, în 1997 afirma că în următorii 5 ani
sistemele OR le vor surclasa pe cele O. Cu toate acestea, să pui facilităţi O unor sisteme
R e ca şi cum ai pune un radio stereo sau sisteme de navigaţie prin satelit unei trăsuri
trase de cai. Vor fi într-adevăr dotări excepţionale, însă vehiculul nu este unul potrivit,
astfel încât în scurt timp se constată că nu mai are loc pe superautostrada informaţiei
[McClure]
 Conceptul de Big Data este unul relativ nou, de care se leagă o serie de caracteristici,
precum volum, viteză, varietate şi veracitate.
Din motive financiare – un raport recent elaborat de instituţii serioase costă – nu putem furniza o
situaţie la zi a împărţirii pieţei BD între tipurile de sisteme cunoscute. Prognoză a grupului IDC pentru
perioada 2000 – 2004, în care se afirmă că până în 2004 sistemele R aveau o rată de creştere de
18,2%, în timp ce creşterea sistemelor OR doar de 12,5%. Segmentul sistemelor O, deşi în uşoară
creştere este încă destul de mic, reprezentând a 50-a parte din acoperirea sistemelor R. Cu toate
acestea sistemele OO au nişte nişe sigure, garantate. Tehnologia Web are o afinitate deosebită pentru
aceste sisteme [W3C IDC #22542]. Acestea sunt estimări. Chiar dacă procentele în valoare absolută
nu corespund, proporţia dintre acestea se putea menţine.
II.4.3. Sumar
In cadrul capitolului s-au tratat problemele referitoare bazele de date OR şi trematica celor 3 manifeste
ca dispute academice din domeniul discursului. Sunt analizate elemente specifice ale SQL 3.

 să compare standardele SQL2 cu SQL3;
 să studieze exemple din MS SQL Server 2005 şi Oracle;
 abordarea practică a consideraţiilor OO vor reprezenta 20% din ponderea notei pentru proba
practică;
de consultaţii.
 Ce sunt aşa-numitele manifeste ale bazelor de date? Vezi pagina 60.
 Care sunt facilităţile OR ale standardului SQL3? Vezi pagina 63.
 Care sunt caracteristicile Big Data? Vezi pagina 64.
 Menţionaţi pe scurt tipurile de baze de date NoSQL. Vezi pagina 65.
Teme de
reflecţie

1. [Date C.J. 2005, T. Connolly. C. Begg, A. Strachan, 2001] D.A.Sitar Tăut 2005, BDASEIG
2001, M. Fotache 2001 şi 2003].
2. [Evans 2009] Eric Evans, NOSQL 2009. May 2009. – Blog post of 2009-05-12.
http://blog.sym-link.com/2009/05/12/nosql_2009.html
3. [Francis 2012] Matthew Francis, Future telescope array drives development of exabyte
processing. Future Square Kilometer Array telescopes will need new computing technology,
2012, http://arstechnica.com/science/2012/04/future-telescope-array-drives-development-of-
exabyte-processing/
4. [IBM BigData] What is big data?, Big Data and the Speed of Business, http://www-
5. [Strauch 2011] Strauch Christof, NoSQL Databases, Selected Topics on Software-
Technology, Ultra-Large Scale Sites, Cursul Computer Science and Media, Stuttgart Media
University, 2011
6. [Zikopoulos & Eaton 2011] Paul Zikopoulos, Chris Eaton. 2011. Understanding Big Data:
Analytics for Enterprise Class Hadoop and Streaming Data (1st ed.). McGraw-Hill Osborne
Media.
7. [Oracle 2012] Introduction to Oracle NoSQL Database, Documentaţie de firmă (D76115),
Oracle, 2012
8. [W3C Strozzi] Strozzi, Carlo: NoSQL – A relational database management system. 2007–
2010. – http://www.strozzi.it/cgi-bin/CSA/tw7/I/en_US/nosql/Home%20Page
9. [W3-Villa] What is Big Data? http://www.villanovau.com/university-online-programs/what-
is-big-data/
II.5. Capitolul 5 – MongoDB
Scopul capitolului este familiarizarea cursanţilor cu problematica generală a bazelor de date NoSQL
prin interacţiunea cu MongoDB, un SGBD din această familie.
 Studiul aspectelor generale ce privesc produsele NoSQL
 Prezentarea generală a produsului MongoDB
 Instalarea MongoDB şi prezentarea instrumentelor de bază
 Rularea operaţiilor CRUD asupra bazei de date MongoDB
Consideraţii generale referitoare la NoSQL

↓
Prezentare MongoDB
↓ ↓
Instalare CRUD

de date
Consideraţii generale asupra bazelor de date NoSQL
(15’ teorie)
NoSQL încearcă să acopere cerinţele unei diversităţi de tehnologii de baze de

date ce trebuie să răspundă solicitărilor aplicaţiilor moderne şi cărora sistemele
relaţionale nu le pot face faţă. Acestea ar fi:
 Volume mari de date cu creştere dinamică, structurate, semistructurate,
nestructurate şi polimorfice
De reţinut
 Apusul aplicaţiilor costisitoare ca timp, cu proiectare în cascadă, cu ciclu de dezvoltare de 1-
1,5 ani. Trebuie să facă loc celor “agile”, realizate de echipe mici, cu ciclu de ordinal
săptămânilor, sau chiar mai puţin
 Aplicaţii ce se adresau unei audienţe limitate, acum pot fi distribuite ca servicii pe cale largă
 Companiile mari au migrat de la aplicaţiile ce folosesc baze de date monolit către arhitecturi
descentralizate şi chiar cu externalizarea serviciilor de date.
Exemple de baze de date NoSQL

 Documents Ex: MongoDB, Couch DB, Cloudant
 Graph stores Ex: Neo4J şi Giraph
 Key-value stores Ex: Memcached, Coherence, Riak şi Berkeley DB. Unele astfel de baze
de date – Redis – adaugă o funcţionalitate nouă, asociind valorilor şi tipul de date
 Wide-column stores Ex: Big Table, Accumulo, Cassandra şi Hbase. Sunt optmizate pentru
interogări asupra seturilor mari de date. Memorează datele în cadrul coloanelor, faţă de
varianta relaţională, pe linii
Caracteristici NoSQL
 Scheme dinamice
o BDR – trebuie să aibă structura definită anterior introducerii datelor →
Analiză şi Proiectare solidă. Chiar şi aşa nu se pot identifica în avans toate
dezvoltările ulterioare → modificare schemă, module sau chiar sistem
informatic, migrare date = timpi lungi de întrerupere parţială/totală a
De reţinut sistemului în cazul bazelor de date mari;
o NoSQL – nu e necesară vreo schemă anterior introducerii de date.
Apariţia unei noi funcţionalităţi/facilităţi se reflectă odată cu noile introduceri →
trecerea la o nouă schemă se face la nivel de aplicaţie în timp real, serviciile de
gestiune a BD sunt simplificate. Aplicaţia trebuie să efectueze controlul integrităţii
datelor. Unele baze de date NoSQL au implementat reguli de integritate, chiar şi în
cazul schemelor dinamice.
 Partiţionarea automată (Auto-sharding)
o BDR – în general la normalizare şi partiţionare se utilizează fragmentarea verticală:
→ uniunile, tranzacţiile devin costisitoare ca timp şi resurse. Pentru partiţionare
trebuie construite instrumente in-house, care în plus trebuie să ţină cont şi de
replicări, integritate tranzacţii, valori duplicate, distribuirea interogărilor etc (manual
sharding);
o NoSQL – suportă în general în mod nativ partiţionarea şi alocarea pe un număr mare
de servere. Serviciile furnizorilor de Cloud computing (ex. serviciile web Amazon)
oferă partiţionare, alocare şi replicare în mod externalizat, la un tarif competitiv.
 Replicarea
o BDR – aplicaţii suplimentare, add-on-uri costisitoare
o NoSQL – Majoritatea bazelor de date NoSQL suportă şi replicarea, pentru creşterea
disponibilităţii şi fiabilităţii. Unele astfel de baze de date, mai sofisticate, dispun de
rutine de prevenţie şi recuperare în caz de eşec şi asigură distribuirea geografică.
 Caching Integrat
o BDR – O serie de produse conţin un nivel intermediar destinat caching-ului. Astfel,
se îmbunătăţeşte considerabil performanţa sistemului, însă doar pentru operaţiunile de
citire şi sporesc complexitatea proiectării aplicaţiilor.
o NoSQL – Multe baze de date NoSQL beneficiază de facilităţi avansate de caching
integrat, menţinând în memorie datele cel mai frecvent utilizate, fără a necesita un
nivel suplimentar de caching ca şi în cazul BDR.
Popularitate SGBD-uri în mediul online
Citire
http://db-engines.com/en/ranking
Evoluţie în timp şi tendinţă popularitate SGBD-uri în mediul online
Citire

de date
MogoDB - Introducere

MogoDB – Este un SGBD NoSQL, gratuit, open-source, cross-platform, ce gestionează baze de
date tip document cu schemă dinamică în format Binary JavaScript Object
Notation (BSON, derivat din JSON).
Acesta este distribuit de către compania MongoDB Inc (2013), anterior
denumită 10gen.
Caracteristici de bază
 Performanţă înaltă
De reţinut
Performanţă foarte bună cu privire la persistenţa datelor prin:
Suport pentru modele de date încapsulate, fapt ce reduce operaţiile de intrare/ieşire
Indecşi, ce accelerează interogările
 Limbaj de interogare dezvoltat
Agregări de date
Căutări text şi interogări geospaţiale
 Disponibilitate ridicată
Se datorează facilităţii de replicare ce permite o redundanţă controlată, dar şi proceduri de refacere

automata în caz de pană
Scalabilitate pe orizontală
Partiţionare orizontală ce permite distribuirea bazei de date în cadrul unor clustere de maşini de
calcul
Suport pentru multiple motoare de stocare (WiredTiger Storage Engine şi MMAPv1 Storage
Engine)
Angajat
{
"_id": ObjectId("100000000000000000000000"),
marca: 1,
nume: 'Pop',
prenume: 'Ion',
salariu: 1500
},
{
marca: 2,
nume: 'Albu',
prenume: 'Ana',
comision: 0.15
},
{
marca: 3,
prenume: 'Bob',
nume: 'Chis',
"data angajarii": '10/22/2015'
}
Tipuri de relaţii între colecţii
Angajati:
{ "_id" : ObjectId("100000000000000000000000"), "marca" : 1, "nume" :
"Pop", "prenume" : "Ion", "salariu" : 1500 },
{ "_id" : ObjectId("572decc61265de9d6f9d96c1"), "marca" : 2, "nume" :
"Albu", "prenume" : "Ana", "comision" : 0.15 },
{ "_id" : ObjectId("572decc61265de9d6f9d96c2"), "marca" : 3, "prenume" :
De reţinut
"Bob", "nume" : "Chis", "data angajarii" : "10/22/2015" }
Departamente:
{nr: 10, denumire: 'IT', angajat: [ObjectId("100000000000000000000000"),
ObjectId("572decc61265de9d6f9d96c2")]},
{nr: 20, denumire: 'Conta', angajat: [ObjectId("572decc61265de9d6f9d96c1")]}
Angajati : Departamente = Relaţie N : 1
Tipuri imbricate
Departamente:
{nr: 10, denumire: 'IT', angajati:
[{ "_id" : ObjectId("100000000000000000000000"), "marca" : 1, "nume" : "Pop", "prenume" :
"Ion", "salariu" : 1500 },
{ "_id" : ObjectId("572decc61265de9d6f9d96c2"), "marca" : 3, "prenume" : "Bob", "nume" :
"Chis", "data angajarii" : "10/22/2015" }
]},
{nr: 20, denumire: 'Conta', angajati:
[{ "_id" : ObjectId("572decc61265de9d6f9d96c1"), "marca" : 2, "nume" : "Albu", "prenume" :
"Ana", "comision" : 0.15 }
]}
de date
Instalare MongoDB

Scrieti
Instrumente
 Serviciul de baze de date
mongod: D:\MongoDB\bin\mongod.exe
 Clientul/Shell
mongo: D:\MongoDB\bin\mongo.exe
De reţinut Creare director pentru baza de date
Mutăm director instalare: Ex. D:\MongoDB
Se creează director BD/date: D:\MongoData
<cmd> D:\MongoDB\bin\mongod.exe --dbpath D:\MongoData
Scrieti
Conectare client la baza de date
Scrieti
de date
CRUD
 Creare colecţie (catedra), documente (IE, MK)

db.catedra.insert({denumire:'Informatica Economica',
anul_inf:'1991',localizare:'etaj 4', nr_membri:'25'})
db.catedra.insert({denumire:'Marketing', anul_inf:'1980',localizare:'etaj 2',
nr_membri:'9'})
Scrieti show collections
 Inserare n documente
db.catedra.drop()
db.catedra.insert([
{denumire:'Informatica Economica', anul_inf:1991,localizare:'etaj 4', nr_membri:25},
{denumire:'Marketing', anul_inf:1980,localizare:'etaj 2', nr_membri:9}
])
 Interogare colecţie (catedra)
db.catedra.find()
db.catedra.find({denumire:'Informatica Economica'})
db.catedra.find({"_id": ObjectId("572a73beb74542971195f5ec")})
 Interogare colecţie, formatare rezultat
db.catedra.find().pretty()
Scrieti
 Actualizare document
db.catedra.update({denumire:'Informatica Economica'},{denumire:'Informatica Economica',

anul_inf:1991,localizare:'etaj 4', nr_membri:26})
db.catedra.find({denumire:'Informatica Economica'})
 Ştergere document
db.catedra.remove({denumire:'Marketing'})
db.catedra.find()
db.catedra.find({denumire:'Marketing'})
Scrieti
 Sortarea datelor
db.angajat.find().sort({nume: 1})
db.angajat.find().sort({nume: -1})
db.angajat.find().sort({salariu: 1})
 Alte operaţii
Închidere client
- exit/închidere fereastră
Închidere serviciu BD
- închidere fereastră
De reţinut
II.5.3. Sumar
In cadrul capitolului s-au tratat conceptele referitoare la bazele de date NoSQL prin exemplificarea
acestora în cadrul unui produs din această categorie, şi anume MongoDB.

 să compare domeniul BDR cu cele NoSQL şi să evidenţieze diferenţele;
 să furnizeze exemple concrete de problematici abordabile prin baze de date NoSQL în diferite
domenii economice
 abordarea practică a consideraţiilor NoSQL în MongoDB vor reprezenta 20% din ponderea
notei pentru proba practică;
de consultaţii.
/ Întrebări pentru platformă/test grilă clasic

https://www.mongodb.com/nosql-explained?jmp=footer
https://docs.mongodb.com/manual/introduction/
M101P: MongoDB for Developers ,

https://university.mongodb.com/courses/MongoDB/M101P/2016_May/syllabus
https://www.youtube.com/watch?v=CvIr-2lMLsk
https://www.youtube.com/watch?v=liQzIsFnCr0
Video
III. Anexe
III.1. Bibliografia completă a cursului

1. Abitaboul S., Hull R., Vianu V., Foundations of Databases, Addison-Wesley, 1998.
2. Date C., Darween J.H., Foundation for Future Database Systems. The Third Manifesto,
Addison Weslley, 2000
3. BDASEIG, Baze de date, Fundamente teoretice şi practice, Infomrga, 2002.
4. Eric Evans, NOSQL 2009. May 2009. – Blog post of 2009-05-12. http://blog.sym-
link.com/2009/05/12/nosql_2009.html
5. M. Fotache, SQL Dialecte DB2, Oracle, Visual FoxPro, Ed. Politrom, Bucureşti, 2001.
6. M.Fotache, C. Strâmbei, Creţu L., ORACLE 9i2, Ghidul dezvoltării aplicaţiilor profesionale,
Polirom, 2003
7. Matthew Francis, Future telescope array drives development of exabyte processing. Future
Square Kilometer Array telescopes will need new computing technology, 2012,
http://arstechnica.com/science/2012/04/future-telescope-array-drives-development-of-
exabyte-processing/
8. Ozsu M, Valduriez T., Principles of Distributed Database Systems, Prentice-Hall, 2003
9. Pang-Ning Tan, Steinbach M., Kumar V., Introduction to Data Mining, Addison Wesley,
2005.
10. Kamaran Parasaye şi Alţii, Intelligent Data Bases, Object-oriented, Deductive Hypermedia
Technologies, John Wiley & Sons., 1989.
11. Sitar-Tăut Dan-Andrei, Baze de date distribuite, Risoprint, 2005
12. Strauch Christof, NoSQL Databases, Selected Topics on Software-Technology, Ultra-Large
Scale Sites, Cursul Computer Science and Media, Stuttgart Media University, 2011
13. Strozzi, Carlo: NoSQL – A relational database management system. 2007–2010. –
http://www.strozzi.it/cgi-bin/CSA/tw7/I/en_US/nosql/Home%20Page
14. Usama M.Fayyad, Gregory Piatetski Shapiro etc. Advences in Knowledge Discovery and
Data Mining, AAAI Press / The MIT Press, 1996
15. Ian Witten, Eibe Frank, Data Mining, Practical Machine Learning Tools and Technique with
Java Implementation, Morgan Kaufmann Publishers, 2000
16. Paul Zikopoulos, Chris Eaton. 2011. Understanding Big Data: Analytics for Enterprise Class
Hadoop and Streaming Data (1st ed.). McGraw-Hill Osborne Media.
17. Introduction to Oracle NoSQL Database, Documentaţie de firmă (D76115), Oracle, 2012
18. What is Big Data? http://www.villanovau.com/university-online-programs/what-is-big-data/
19. What is big data?, Big Data and the Speed of Business, http://www-
III.2. Scurtă biografie a titularului de curs
Dl. Sitar-Tăut Dan-Andrei s-a născut în 1976. A absolvit în anul 1999 Facultatea de Ştiinţe
Economice din cadrul Universităţii „Babeş-Bolyai” Cluj-Napoca, secţia de
Informatică Economică, iar în 2000 studiile aprofundate, specializarea Strategii
Informatice în Economie şi Business, în cadrul aceleiaşi instituţii. Dl. Sitar-
Tăut a obţinut la începutul anului 2006 titlul de doctor în domeniul Cibernetică
şi Statistică Economică, teza de doctorat având titlul „Baze de date
distribuite”. În februarie 2002 s-a angajat ca preparator la Facultatea de Ştiinţe
Economice şi Gestiunea Afacerilor, în prezent fiind conferenţiar. A publicat 3
cărţi ca autor unic intitulate „Baze de date distribuite”, „Elemente de baze de date pentru
economişti”şi „Databases in the Real Life Economy”, două în calitate de coautor în domeniul bazelor
de date şi alte 25 ca membru în comitetul redacţional, la două dintre ele fiind coordonator. A mai
publicat peste 60 de articole în reviste sau cu ocazia unor conferinţe naţionale şi internaţionale.

Elemente Avansate de Baze de Date SC 2019-2020 - Sem5 - IE ID

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Elemente Avansate de Baze de Date SC 2019-2020 - Sem5 - IE ID

Încărcat de

Drepturi de autor:

Formate disponibile

Informatică economică

II. SUPORTUL DE CURS PROPRIU-ZIS ................................................................................................................. 9

Dan-Andrei Sitar-Tăut (Anul univ. 2019-2020) Elemente avansate de baze de date

Dan-Andrei Sitar-Tăut (Anul univ. 2019-2020) Elemente avansate de baze de date

I.1. Date de identificare ale cursului

I.1.1. Date de identificare a titularului de curs

Nume: Conf. dr. Sitar-Tăut Dan-Andrei

I.1.2. Date de identificare curs şi contact tutori

Numele cursului: Elemente avansate de baze de date

Dan-Andrei Sitar-Tăut (Anul univ. 2019-2020) Elemente avansate de baze de date

I.3. Descrierea cursului

Cursul urmăreşte aprofundarea cunoştinţelor studenţilor referitoare la problemele bazelor de date,

I.4. Organizarea temelor din cadrul cursului

Cursul, conform normelor metodologice are 2 componente:

Parcurgerea componentei teoretice se realizează de către cursanţi. Elementele principale sunt

Dan-Andrei Sitar-Tăut (Anul univ. 2019-2020) Elemente avansate de baze de date

 Pentru baze de date distribuite:

 Pentru orientarea obiectuală şi relaţional obiectuală

 Pentru NoSQL, Big Data, MongoDB

Dan-Andrei Sitar-Tăut (Anul univ. 2019-2020) Elemente avansate de baze de date

I.7. Calendar al cursului

I.8. Politica de evaluare şi notare

Modul de evaluare a cursului:

Pentru partea practică, cursanţii vor realiza:

I.9. Elemente de deontologie academică

Se aplică regulile generale de deontologie academică din UBB.

I.10. Studenţi cu dizabilităţi

I.11. Strategii de studiu recomandate

II.1. Capitolul 1 – Fragmentarea bazelor de date

II.1.1.1. Scopul şi obiectivele capitolului

II.1.1.2. Schema logică a capitolului

Structura distribuită a organizaţiilor → distribuirea bazelor de date

Structura distribuită a organizaţiilor

Iniţial prelucrare distribuită – hibrid = sistemul cu prelucrare distribuită + un sistem centralizat de BD

Elemente avansate de baze

Importanţa integrării datelor în aplicaţiile economice

2: (Gardarin1999, DBASEIG2001) BDD - ansamblu de BD administrate de

 Integrarea logică - nu sunt simple colecţii de fişiere - o structură bine

SGBDD (Conolly2001) - sistemul software care permite gestiunea BDD,

 colecţia de date partajate, corelate logic

Termeni de bază: fragmentare, alocare şi replicare.

Elemente avansate de baze

(5’ teorie, 25’ practică)

Fragmentarea - procedeul de spargere a relaţiilor utilizate într-un SD prin

O abordare - prin divizarea tabelelor în unul sau mai multe fragmente

[Connolly] premisele de bază pentru fragmentare:

 Uzanţa - Aplicaţiile cu BD – multiutilizator – tabelele virtuale în

 Complexitatea proiectării. SD - mai greu de proiectat. Existenţa

Fragmentele rezultate - condiţiile:

 Completitudinea fragmentării. Fragmentele să asigure acoperirea

În funcţie de operatorii relaţionali: fragmentarea (partiţionarea): orizontală,

Limitele de fragmentarea - de la un tuplu (în cazul fragmentării orizontale)

(5’ teorie, 10’ practică)

Se face de-a lungul tuplelor unei relaţii → fragment orizontal = submulţime

Reprezentarea simbolică a unui fragment orizontal F, obţinut dintr-o relaţie

Citire Forma normală conjunctivă (Oszu&Valdiriez) → predicatele pe baza cărora

Regula de bază completitudine şi minimalitate: relaţia se fragmentează

În cazul n predicate simple → numărul predicatelor minterm ce pot fi

Elemente avansate de baze

(5’ teorie, 10’ practică)

Exemplu: Relaţia LOCALITATI(CodLoc, Loc, CodJud) - fragmente:

În ambele fragmente - includem cheia primară a relaţiei LOCALITATI. Reguli:

Partiţionarea verticală - mult mai complexă decât cea orizontală - în