BDAS C1 Baze de Date Pentru Aplicatii Stiintifice-Merged

Baze de Date pentru Aplicații
Științifice
Curs
Facultatea de Electronică, Telecomunicaţii

şi Tehnologia Informaţiei
Mastere:
Ingineria Informatiei şi a Sistemelor de Calcul (IISC)

Tehnici Avansate de Imagistică Digitală (TAID)
Prof. Felicia Ionescu

Conţinutul cursului
 Introducere - evoluţia şi tendinţele de dezvoltare a

tehnologiilor de baze de date
 Baze de date active
 Baze de date obiect-orientate
 Baze de date obiect-relaţionale
 Baze de date XML
 Baze de date spațiale
 Baze de date multimedia
 Baze de date distribuite
 Depozite de date (data warehouse)
Prof. Felicia Ionescu Baze de date pentru aplicatii stiintifice 2

Bibliografie generală
 Felicia Ionescu, “Baze de date relationale si aplicatii”, Editura Tehnica, Bucureşti,
2004
 M. Piatini, O. Diaz (editors), “Advanced Database Technology and Design”, Artech
House, 2005
 R. Elmasri and S. B. Navathe, “Fundamentals of Database Systems”, Fourth
Edition, 2004.
 C. J. Date, “An Introduction to Database Systems”, 8th Edition, 2004
 A. Silberschatz, H. Korth, S. Sudarshan, “Database System Concepts”, Fourth
Edition, McGrow Hill, 2004
 J. Melton, “Advanced SQL-1999”, Morgan Kaufmann, 2003
 Oracle 11g, 12c Documentation
http://www.oracle.com/technetwork/database/enterprise-edition/documentation/index.html
 MySQL Documentation - http://dev.mysql.com/doc/
 PostgreSQL Documentation - http://www.postgresql.org/docs/manuals/
 Microsoft SQL Server Books Online – MSDN - Academic Alliance

Sisteme informatice
 Un sistem informatic (Information System - IS) este o reprezentare a unui anumit
domeniu de activitate din lumea reală şi are următoarele funcţii:
 Funcţia de memorare – stochează informaţii despre starea domeniului; această funcţie
este îndeplinită de o bază de date
 Funcţia de informare – oferă informaţii despre starea domeniului
 Funcţia de activare – permite modificarea stării domeniului
 Partea centrală (nucleul) unui IS este baza de date

Funcţiile sistemelor informatice
 Funcţia de memorare:
 nu modifică starea domeniului
 este o funcţie statică
 Funcţia de informare:
 nu modifică starea domeniului
 necesită capacitate de inferenţă (deducere) a IS
 utilizatorii trimit interogări, iar IS răspunde
 uneori starea domeniului poate fi observată direct în domeniu şi este
reprezentată şi în IS (exemplu numărul de produse de o anumită categorie)
 alteori starea domeniului nu poate fi observată direct, ci rezultă numai din
informaţiile din IS (ex. balanţa unui cont)
 Funcţia de activare
 permite IS să execute anumite acţiuni care modifică starea domeniului
 activare la cerere: utilizatorii cer sistemului să efectueze anumite operaţii (de
exemplu, calcularea dobânzii unui cont şi înscrierea ei în balanţa contului)
 activare autonomă: sistemul monitorizează starea domeniului şi execută o
operaţie când sunt îndeplinite anumite condiţii (de exemplu, comanda de noi
produse atunci când stocul a scăzut sub o anumită valoare)

Evoluţia şi tendinţele de dezvoltare ale
tehnologiilor de baze de date
 Dezvoltarea bazelor de date a început in anii 1960; acestea:
 reprezintă nucleul sistemelor informatice
 constitue suportul pentru luarea deciziilor
 au un mare impact economic
 În primele etape de dezvoltare ale calculatoarelor datele erau memorate
în sistemul de fişiere numeroase probleme
 redundanţă mare, securitate precară, dependenţă între date şi aplicaţii
 Prima generaţie de baze de date şi sisteme de gestiune (în modelul
ierarhic şi modelul reţea) a rezolvat o parte dintre probleme
 A doua generaţie de baze de date  modelul relaţional (după 1970),
bazat pe limbajul SQL (Structured Query Language) - în special pentru
aplicaţii financiar contabile
 “Noua generaţie”
 încearcă să înlăture problemele tehnologiilor existente
 în special pentru aplicaţii avansate (ştiinţifice)

Probleme ale SGBD-urilor “tradiţionale”
 SGBD-urile tradiţionale (SQL):
 sunt “monolitice”: ele oferă toate funcţiile şi serviciile într-un singur packet,
indiferent de necesitățile utilizatorului
 nu sunt întotdeauna eficiente
 este dificil de combinat date structurate (tabele din baze de date) cu date
nestructurate (din diferite aplicaţii ca e-mail, ftp etc)
 Ca urmare:
 multe sisteme (de exemplu, sistemele de workflow) accesează datele direct,
folosind interfeţe de aplicaţie (API), nu sub controlul unui SGBD
 mai sunt multe date stocate în foi de calcul tabelar (spreadsheets), sau
sisteme de stocare a datelor moştenite și învechite (legacy systems) ~ 50%,
în loc să fie stocate în baze de date SQL

Evoluţia bazelor de date

Aplicaţii “netradiţionale” de baze de date (1)
 M. Piattini, O. Diaz, Advanced Database Technology and Design:
 Computer-Aided Software/System Engineering (CASE)
CASE requires managing information sets associated with all the IS life cycle:
planning, analysis, design, programming, maintenance, and so on. To meet
those requirements, DBMSs must provide version control, triggers, matrix and
diagram storage, and so on
 Computer-Aided Design (CAD)/Computer-Aided Manufacturing (CAM) -
Computer-Integrated Manufacturing (CIM)
CAD/CAM/CIM requires the introduction of alerters, procedures, and triggers in
DBMSs to manage all the data relative to the different stages of the production
operation
 Geographical Information Systems (GISs).
GISs manage geographical/spatial data (e.g., maps) for environmental and
military research, city planning, and so on
 Textual Information (TI)
TI was executed by special software (IRS - Information Retrieval Systems), but
the integration of textual data in databases is now in demand

 Scientific applications
Both in the microcosmos (e.g., Genome project) and in the macrocosmos
(e.g., NASA’s earth-observing systems), new kinds of information must be
managed and a larger quantity of information (petabytes) must be stored
 Medical systems
Health personnel need different types of information about their patients. Such
information could be distributed to different medical centers. Security
concerns are also high in this type of IS
 Digital publication
The publishing sector is going through big changes due to the development of
electronic papers and books, which combine text with audio, video, and
images
 Education and training
In distance learning processes, multimedia courses require data in real time
and in an Internet or Intranet environment

 Statistical systems
Statistical systems have to deal with considerable data volumes, with
expensive cleaning and aggregation processes, handling time, and spatial
dimensions. These systems are also a grave security concern
 Electronic commerce
The applications linked to the Internet (video on demand, electronic
shopping, etc.) are increasing every day. The tendency is to put all the
information in databases into cyberspace, thus making it accessible to more
and more people
 On-Line Analytical Processing (OLAP) and Data Warehousing (DW)
DW is generally accepted as a good approach to providing the framework for
accessing the sources of data needed for decision making in business. Even
though vendors now offer many DW servers and OLAP tools, the very large
multidimensional DBs required

Evoluţia tehnologiilor de baze de date
 Dimensiunile în care evoluează bazele
de date: performanţe, distribuţie,
funcţionalitate
 Direcţii de evoluţie:
 De la sisteme de baze de date “monolit”
(care oferă toate serviciile: securitate,
interogare etc) - către sisteme de baze
de date modulare
 Diversitate de tehnologii:
 Baze de date SQL: relaționale, obiect-relaționale
 Baze de date NoSQL: obiect-orientate, XML, MapReduce (Hadoop) –
http://nosql-database.org/

Evoluția performanţelor bazelor de date
 Volumul datelor stocate creşte ~ 10 ori în 5 ani

 Analogie cu expansiunea gazelor care ocupă tot spaţiul disponibil
 Acum 10 ani: Gigabytes de data (1GB = 109 bytes)
 Actualmente: Terabytes (1 TB = 1012 bytes), Petabytes (1PB = 1015 bytes)
 Utilizarea bazelor de date distribuite
 Utilizarea bazelor de date stocate în sisteme Cloud Computing
 Performanţe ridicate sunt necesare în toate sistemele de baze de date,
cu precădere în bazele de date pentru aplicaţii în timp real; performanţele
(viteza de execuție) în bazele de date cresc prin:
 creşterea performanţelor calculatoarelor folosite
 utilizarea bazelor de date stocate în memoria principală (main-memory DB)
 utilizarea calculatoarelor paralele (baze de date paralele)
 utilizarea sistemelor distribuite (baze de date distribuite)

Evoluția distribuirii bazelor de date
 Din punct de vedere al autonomiei, bazele de date distribuite sunt:
 baze de date federative (semiautonome – federated databases)
 baze de date multiple (autonome - multidatabases)
 baze de date mobile (autonome, cu posibilitatea de modificare dinamică a
link-urilor între noduri)
 Tehnologia bazelor de date distribuite oferă:
 distribuirea (fragmentarea) și replicarea datelor
 validarea tranzacţiilor distribuite în două faze (2 phase commit)
 optimizarea interogărilor distribuite
 Integrarea bazelor de date cu tehnologiile sistemelor distribuite: Internet,
Web, Cloud:
 dezvoltarea bazelor de date distribuite
 posibilitatea de acces a bazelor de date prin Internet, din orice fel de dispozitiv
(calculatoare personale, laptop, PDA)
 utilizarea interfeţelor grafice bazate pe protocolul HTTP pentru accesarea
bazelor de date
Evoluția funcţionalităților bazelor de date
 Funcţionalităţi adăugate bazelor de date şi SGBD-urilor:
 baze de date active
 baze de date deductive
 baze de date multimedia
 baze de date temporale
 baze de date spaţiale
 În sistemele informatice bazate pe sistemul de fişiere:
 bazele de date conţineau numai date, iar toate informaţiile despre date,
constrângeri şi control erau gestionate de program;probleme privind redundanţa,
mentenanţa etc.
 Migrarea funcţionalităţilor de la progr. de aplicaţii către bazele de date

Maturitatea tehnologiilor de baze de date
 Unele funcţionalităţi sunt comune mai
multor categorii de BD:
 gestionarea timpului (şi a intervalelor
de timp) – în bazele de date temporale
şi bazele de date de timp real
 limbaje logice – în bazele de date fuzzy
şi bazele de date deductive
 paralelismul - în bazele de date
paralele, în bazele de date distribuite,
data warehouses
 Aspectele maturităţii tehnologiilor de
baze de date:
 ştiinţific – cercetările care se efectuează
în tehnologia respectivă
 industrial – produsele dezvoltate de
producători în tehnologia dată
 comercial – acceptarea pe piaţă a
tehnologiei

Capitolul 2 - Baze de date active
 Funcţia de activare din sistemele informatice: modificarea stării domeniului;
necesară în sistemele complexe
 exemplu: înscrierea unui nou cursant necesită adăugarea adresei acestuia în
lista de adrese în care opreşte autobusul care transportă cursanţii
 În sistemele “tradiţionale” (pasive):
 funcţia de activare inclusă în programele de aplicaţie: acestea execută un
polling în lista cursanţilor, descoperă un cursant nou şi inserează adresa
 probleme: frecvenţa de polling greu de optimizat
 În bazele de date active:
 migrarea funcţiei de activare de la aplicaţie către baza de date
 în exemplul dat, la inserarea unui nou cursant un trigger adaugă adresa
acestuia în lista de adrese
 Avantajele sistemelor active:
 eficienţa execuţiei (nu se mai consumă timp pentru polling)
 reutilizabilitatea codului – toate aplicaţiile pot folosi ac. funcţie de activare
Prof. Felicia Ionescu Baze de date active 1

Analiza şi proiectarea
comportării active a bazei de date
 Analiza  identificarea cerinţelor aplicaţiilor d.p.v. al utilizatorilor
 modelul conceptual al comportării bazei de date (behavior model)
 comportarea activă a bazei de date se defineşte prin proceduri stocate,
funcţii definite de utilizator şi triggere (în special triggere)
 Proiectarea definirea regulilor de activare (active rules)
 O regulă de activare (active rule) conţine 3 elemente:
 Evenimentul (event)  evenimentul care poate provoca o acţiune (tipic
operaţii de insert, update, delete în tabelele bazei de date)
 Condiţia (condition) o expresie logică care condiţionează execuţia acţiunii
 Acţiunea (action) un bloc de program care specifică răspunsul la apariţia
evenimentului, dacă condiţia este evaluată la valoarea true; tipic, acţiunea
modifică baza de date sau comunică unele informaţii către utilizatori
 Implementarea  în sistemele de baze de date relaţionale comportarea
activă se obţine prin utilizarea triggerelor

Comportarea activă
 Comportarea activă depinde de:
 Momentul activării acţiunii (cuplarea evenimentului cu acţiunea):
 Cuplare imediată (immediate): atunci când se declanşează un eveniment
asociat regulii r1, tranzacţia care a declanşat acel eveniment este
suspendată, şi se începe execuţia acţiunii asociate lui r1; dacă acestă acţiune
declanşează un alt eveniment, asociat regulii r2, acţiunea regulii r1 se
suspendă, se prelucrează regula r2, apoi se completează regula r1; pot exista
mai multe imbricări, cu modul de execuţie lifo (last in, first out)
 Cuplare amânată (deferred): când este declanşat un eveniment al unei reguli,
ea este memorată într-o coadă care este prelucrată mai târziu, tipic după
terminarea tranzacţiei
 Gestionarea evenimentelor multiple:
 Cuplarea imediată: se activează acţiunea regulii după fiecare eveniment
asociat regulii respective – activare la nivel de tuplu (linie)
 Cuplarea cu amânare: se activează acţiunea regulii după ce s-au declanşat
toate evenimentele regulii respective – activare la nivel de instrucţiune
(statement)

Standardizarea comportării active în SQL’99
 Majoritatea producătorilor de BD relaţionale în versiuni actuale includ
triggere conform specificaţiilor standardului SQL’99
 Sintaxa instrucţiunii de creare a unui trigger în SQL’99:
CREATE TRIGGER trigger_name numele triggerului
{BEFORE | AFTER} momentul declanş.
{[DELETE] | [INSERT] | [UPDATE] [OF column [,...n]} ON table_name evenimentul
[REFERENCING {OLD [ROW] [AS] old_name | NEW [ROW] [AS] new_name
OLD TABLE [AS] old_name | NEW TABLE [AS] new_name}] tabele temporare
[FOR EACH { ROW | STATEMENT }] nivel activare
[WHEN (conditions)] condiţia
code block acţiunea
 Caracteristici triggere SQL’99:
 fiecare trigger are un nume (trigger_name);
 evenimentul de declanşare: una din instrucţiunile de modificare a datelor
DELETE, INSERT, UPDATE executate intr-un tabel dat prin numele său
(table_name); (pentru UPDATE se poate specifica coloana modificată)
 momentul declanşării: înainte (BEFORE) sau după (AFTER) instr. respectivă

Caracteristicile triggerelor SQL’99
 Implicit, un trigger se declanşează o dată (la nivel de instrucţiune)
 Selecţia explicită a declanșării:
 FOR EACH ROW: la nivel de linie (cu cuplare imediată)
 FOR EACH STATEMENT: la nivel de instrucţiune (cu cuplare amânată)
 Pentru transmiterea informaţiilor către trigger se folosesc tabelele
temporare NEW şi OLD, care au aceeaşi schemă ca şi tabelul dat
 pentru triggerele declanşate de INSERT sunt vizibile datele nou introduse în
tabelul (linia) temporar NEW
 pentru triggerele declanşate de DELETE sunt vizibile datele vechi în tabelul
temporar OLD
 pentru triggerele declanşate de UPDATE sunt vizibile atât datele vechi
(OLD) cât şi noi (NEW)
 Triggerele definite în diferite SGBD-uri prezintă variaţii faţă de aceste
caracteristici din standardul SQL’99

Caracteristicile triggerelor Oracle
 Sintaxa Oracle pentru crearea unui trigger:
CREATE [OR REPLACE] TRIGGER [owner.]trigger_name
{BEFORE | AFTER | INSTEAD OF}
{[DELETE] [OR] [INSERT] [OR] [UPDATE [OF column [,...n] ]] [...n]}
ON {table_name | view_name}
[REFERENCING {OLD [AS] old_name | NEW [AS] new_name}]
[FOR EACH { ROW | STATEMENT }]
[WHEN (conditions)]
PL/SQL block
 Opţiunea INSTEAD OF este admisă numai pentru vederi (views)
 Acţiunea este specificată printr-un bloc PL/SQL, care este limbajul
procedural de extensie a limbajului SQL pentru sistemele Oracle

Utilizarea comportării active a bazelor de date
 Menţinerea (actualizarea) valorilor datelor derivate
Ex: salariul total se actualizează ori de cate ori se modifică salariul unui angajat
 Impunerea unor constrângeri de integritate
 Implementarea unor funcţiuni (reguli) specifice domeniului -business rules
 În toate aceste situaţii se definesc reguli de activare (eveniment, condiţie,
acţiune – ECA rules)
 Exemplu de comportare activă: impunere a unor reguli specifice
 Fie o bază de date relaţională pentru
M N înscrierea studenţilor la cursuri,
Courses Students distribuite în diferite săli
enrolment  Pentru fiecare tip (mulțime) de entități
M
(cursuri, săli, studenti)  câte o relaţie
distribution
(tabel)
N
 Asocierile de tip M:N (înregistrare -
enrolment şi distribuţie - distribution) se
Rooms modelează prin tabele suplimentare

Comportarea activă a bazei de date (1)
 Proiectul logic al bazei de

date pentru inregistrarea
studentilor pentru sistemul
Oracle 11g, realizat in
MySQL Workbench Modeler
(se poate dezvolta și în

Oracle SQL Developer Data
Modeler)

 Definirea regulii
 Ex: “numărul de participanţi la un curs nu poate să depăşească capacitatea
(numărul de locuri) sălii în care este planificat (distribuit) cursul”
 Definirea evenimentelor care pot viola regula dată; exemple:
 înscrierea unui student la un curs (insert în enrollment)
 modificarea sălii unui curs (update în distribution)
 Definirea condiţiei de activare
 numărul de participanţi la un curs mai mare decât capacitatea sălii în care
este distribuit cursul
 Definirea politicii de impunere a regulii:
 Se alege una dintre acţiunile posibile:
 se împarte cursul în două sau mai multe serii
 se limitează înscrierile la cursul respectiv
 se planifică (distribuie) o altă sală
 Implementarea acţiunilor printr-unul sau mai multe triggere

 Se proiecteză un trigger care să limiteze înscrierea studentilor la un
curs, dacă se depășește capacitatea sălii în care a fost distribuit cursul:
CREATE OR REPLACE TRIGGER LIMIT_ENROLMENTS

BEFORE INSERT ON ENROLMENT FOR EACH ROW
DECLARE
nr_stud integer; room varchar2(8); room_capacity integer;
BEGIN
SELECT COUNT (*) INTO nr_stud FROM ENROLMENT e
WHERE e.COURSE_ID = :NEW.COURSE_ID GROUP BY e.COURSE_ID;
SELECT ROOM_ID INTO room FROM DISTRIBUTION d
WHERE d.COURSE_ID = :NEW.COURSE_ID;
SELECT capacity INTO room_capacity FROM ROOMS r WHERE r.ROOM_ID = room;
IF nr_stud >= room_capacity THEN
:NEW.COURSE_ID := 'DUMMY';
:NEW.OBSERVATION := 'ROOM LIMITS OVERFILLED FOR ROOM '|| room;
END IF;
END;

 Comportarea:
 De exemplu cursul BD este distribuit in sala B10 cu capacitate de 6 locuri
 La inserarea in ENROLMENT a unor studenti la cursul de BD peste această
limită, acestia vor fi pusi intr-o lista (serie) separata (DUMMY), cu specificarea
cauzei acestei actiuni (în coloana OBSERVATION)
insert into enrolment (COURSE_ID, STUDENT_ID) values ('BD', 7);
 Tabelul ENROLMENT arată astfel in SQL Developer:

Capitolul 3 - Baze de date obiect-orientate
 Nevoia de asocieri și tipuri de date complexe pentru bazele de date
 Conceptele modelului obiect-orientat
 Integrarea baze de date – modelul obiect:
 Corespondenţa obiect-relaţională
 Baze de date obiect-relaţionale
 Standardul ODMG pentru baze de date obiect-orientate:
 Particularităţile modelului obiect în standardul ODMG
 Limbajul de definire a obiectele (ODL - Object Definition Language)
 Limbajul de interogare a obiectelor (OQL – Object Query Languaje)
 Corespondenţa modelului ODMG cu limbajele obiect-orientate (binding)
 Proiectarea bazelor de date OO
 Tehnologii şi produse pentru baze de date obiect-orientate
Prof. Felicia Ionescu Baze de date obiect-orientate 1

Nevoia de asocieri și tipuri de date complexe
 Bazele de date relaţionale sunt cele mai răspândite dar:
 manevrează tipuri de date puţine şi simple
 nu suportă tipuri definite de utilizator
 admit numai forme normale ale relaţiilor – cel putin prima forma normală care
impune valori atomice și scalare ale atributelor
 suportă numai asocieri simple care se reprezintă prin chei străine
 Aplicaţiile ştiinţifice necesită date și asocieri complexe :
 CAD/CAM (Computer-Aided Design/ Computer/Aided Manufacturing)
 CASE – Compute-Aided Software Engineering
 GIS – Geografical Information Systems
 BIO-MEDICAL SYSTEMS etc.
 În astfel de aplicaţii este necesară:
 reprezentarea unor tipuri de date complexe
 posibilitatea de definire de noi tipuri de date (tipuri definite de utilizator)
 manevrarea unor operatori complecși pentru tipurile definite de utilizator
 reprezentarea unor asocieri complexe (arbori, grafuri etc.)
 SOLUŢIA: folosirea altor modele de baze de date
 Baze de date noSQL:
 Baze de date în model arbore, graf, perechi cheie-valoare etc.
 Baze de date SQL: baze de date obiect-relaționale
Nevoia de tipuri de date complexe - Exemplu
 Fie tipul de entitate dreptunghi cu laturile paralele cu axele Ox şi Oy,
definit prin coordonatele a două vârfuri opuse (X1, Y1) şi (X2, Y2)
 Tabelul corespunzător se poate defini în limbajul SQL astfel:
CREATE TABLE RECTANGLES (
X1 float, Y1 float, X2 float, Y2 float,
primary key(X1,Y1,X2,Y2));
 Se consideră interogarea: Aflaţi toate dreptunghiurile care se suprapun
(parţial sau total) peste dreptunghiul unitate (0,0,1,1) (C.J.Date)
Se observă cât de
complexă şi ineficientă
este o astfel de
interogare, care s-ar
putea rezolva elegant
prin operaţa de
comparaţie a două
obiecte în modelul
obiect-orientat

Conceptele modelului obiect-orientat
 O clasă descrie un tip de entitate; este un tip de date definit de utilizator
care grupează:
 atribute
 metode
 Un obiect este o instanță a unei clase, corespunde unei entităţi din lumea
reală și posedă:
 un tip  clasa pe care o instanțiază
 o identitate  identificator unic şi imutabil – Object Identifier - OID
 o stare  valorile atributelor sale
 o comportare  metodele pe care le poate execută
 Toate obiectele instanţe ale aceleiaşi clase sunt similare, adică au aceeaşi
structură şi aceeaşi comportare
 Un program în modelul OO este o colecţie de obiecte cooperante care
comunică între ele prin mesaje
 Un mesaj înseamnă transmiterea unei cerei către un obiect  invocarea
(apelarea) unei metode a acelui obiect
 Caracteristicile modelului obiect sunt:
 caracteristici principale: abstractizare, modularitate, încapsulare, moștenire
 caracteristici secundare: tipizare, concurență, persistență

Abstractizare, modulatitate, încapsulare
 Abstractizare – reținerea numai a caracteristic. relevante ale entită ților modelate
 Modularitate – împărțirea elementelor modelului în module
 Încapsulare – separarea elementelor unei clase în două părţi:
 Structura, constituită din atribute şi implementarea metodelor
 Comportarea, dată de mulțimea prototipurilor metodelor publice, care pot fi invocate prin
mesaje și constitue interfaţa clasei
class Punct {
int x; Atribute
int y;
public:
Punct(int a, int b); Prototipuri
int getX(); metode publice
int getY(); Mesaje
Structura
Interfaţa
void setX(int a);
void setY(int a);
void translatie(int a, int b); Comportarea
};
Punct::Punct(int a,int b){x=a;y=b;}
int Punct::getX(){return x;} Implementarea
int Punct::getY(){return y;} metodelor
void Punct::setX(int a){x=a;}
void Punct::setY(int b){y=b;}
Ascunderea implementării
 Încapsularea datelor permite ascunderea implementării:
 datele membre (atributele) să fie date private, inaccesibile din afara clasei
 ele pot fi accesate numai prin intermediul medodelor publice ale interfeţei
 Funcţiile publice (interfaţa) unei clase sunt:
 constructori (ex. Punct)
 funcţii de acces la date: selectori (ex. getX), modificatori (ex. setX)
 funcţii de execuţie specifice (business logic) – logica aplicaţiilor (ex. translatie)
 Un obiect este o instanţă a unei clase și are:
 indentificator unic (nume, referință)
 o stare  valorile variabilelor sale
 o comportare funcţiile pe care le poate executa (definite în clasa sa)
 Încapsularea prevede o barieră în

calea accesului la starea unui obiect getX setX
 Asupra unui obiect se poate acţiona x=1

numai prin funcţiile de tip public pe care y=1
acesta le pune la dispoziţie în interfaţă translatie rotatie

Moştenirea claselor
 Moştenirea  definirea de noi tipuri (clase derivate sau subclase) care
specializează una (sau mai multe) clase (clase de bază sau superclase)
 Clasa derivată:
 moşteneşte atributele şi (aproape toate) metodele clasei de bază
 defineşte noi funcţionalităţi prin noi atribute şi metode
 Moştenirea este al doilea mecanism de reutilizare a codului
 primul mecanism este instanţierea obiectelor
 Moștenirea:
 simplă – o singură clasă de bază directă (Java, C#)
 multiplă (C++) – mai multe clase de bază directe  creează probleme
 Evitarea problemelor create de moştenirea multiplă: interfeţe
 o interfaţă conţine numai prototipuri de metode
 o clasă care implementează o interfaţă defineşte metodele interfeţei
 Metodele redefinite în clasele derivate domină (override) metodele din
clasa de bază  comportarea polimorfică
 Moştenire pe mai multe niveluri ierarhii de clase
Standarde pentru reprezentarea modelului obiect
 Modelul obiect-orientat mai este numit pe scurt modelul obiect
 Object Management Group (OMG)
 Specificaţii pentru arhitectura sistemelor obiect-orientate
 Specificaţii pentru managementul obiectelor distribuite (CORBA – Common
Object Request Broker Architecture)
 Limbajul UML (Unified Modeling Language) – standard pentru modelarea,
construirea şi documentarea sistemelor, bazat pe modelul obiect
 Object Data Management Group (ODMG)
 Suport pentru managementul datelor
 Modelul de baze de date ODMG, bazat pe modelul obiect

Modelul obiect şi limbajul UML
 UML (Unified Modeling Language) este un limbaj pentru construirea,
specificarea, vizualizarea şi documentarea modelelor
 Un model este o abstractizare a unui sistem, într-un anumit context:
 un model captează conceptele relevante ale acelui sistem (din punct de vedere
al scopului acestuia), ignorând aspectele neesenţiale
 în cursul etapelor de dezvoltare a unui produs software se crează mai multe
modele ale produsului, care captează diferite aspecte ale acestuia
 Limbajul UML:
 se bazează pe modelul obiect, având posibilitatea de reprezentare a tuturor
conceptelor de bază ale modelului obiect
 are un grad de generalitate mai ridicat decât modelul obiect, permitând
modelarea şi a altor sisteme (de exemplu, baze de date relaționale)
 reprezintă unificarea metodologiilor lui Grady Booch, James Rumbaugh (OMT
– Object Modeling Technique) şi Ivar Iacobsen (OOSE – Object-Oriented
Software Engineering)
 primul standard - OMG (Object Management Group) UML 1.1 (1997)
 standardul actual: UML 2.0 (www.uml.org)

Limbajul UML
 În UML diferite modele ale sistemului se reprezintă ca diagrame:
 fiecare diagramă reprezenzintă o vedere (view) a sistemului (diagrame ale
claselor, diagrame ale secvenţelor de mesaje, diagrame de colaborare,
diagrame de stare etc).
 Cele mai importante elemente ale diagramelor sunt:
 Clasificatori; un clasificator (classifier) este un concept care defineşte trăsături
structurale şi comportamentale ale unui element al modelului; generalizare a
elementelor: class (clasă), interface (interfaţă), data type (tip de date)
 Obiecte - instanţe ale clasificatorilor (claselor) (ex. p1:Persoana)
 Legături (relaţionships) - conexiuni între elemente ale modelului: generalizarea,
dependenţa, realizarea, asocierea
obiect
interfata
clasa

Legături de generalizare
 Generalizarea – este inversul specializării (moștenirii)
 modelul obiect-orientat suportă moștenirea pe mai multe niveluri ; se pot crea
ierarhii de clase - ex: ierarhia claselor Java-AWT
 modelul relaţional nu suportă moştenirea (tipuri de date care moștenesc atribute și
metode), dar se pot extinde tipurile de date definind subtipuri, legate de tipul extins
prin asociere 1:1, folosind o cheie primară comună

Legături de dependenţă
 În UML dependenţa (dependency) este o legătură între două elemente ale
modelului: un element (client) depinde sau utilizează un alt element (server,
ţintă, furnizor – server, target, supplier)
 Tipuri de dependenţe (diferenţiate printr-un stereotip):
 dependenţa de utilizare (<<uses>>)legătura dintre un element (clientul) care
utilizează alt element (ţinta) – îi trimite mesaje
 dependenţa de conexiune (<<bind>>)  legătura dintre un parametru al unei
clase parametrizate (template) şi valoarea lui actuală
 dependenţa de trasare (<<traces>>)  legătură între două elemente care
reprezintă acelaşi concept pe diferite niveluri de dezvoltare (versiuni)
 dependenţa de rafinare (<<refines>>)  legătură între două elemente care
reprezintă diferite stadii de rafinare a unui concept

Legături de realizare
 Realizarea – este o legătură între un element care oferă o implementare
unei specificaţii descrise de un alt element
 În modelul obiect-orientat realizarea poate reprezenta:
Instanţierea unei clase Implementarea unei
(prin crearea unui obiect) interfeţe de către o clasă

Legături de asociere
 O asociere (association) este o legătură între doi sau mai mulţi
clasificatori şi stabileşte o corespondenţă între instanţe ale clasificatorilor
asociaţi
 Din punct de vedere al numărului de clasificatori asociaţi:
 asocieri binare (de gradul 2, între 2 clasificatori); se reprezintă printr-o linie
continuă între cei doi clasificatori
 asocieri multiple (între n clasificatori, n > 2); se reprezintă prin mai multe linii
 Asocierile binare între clasificatorii E1 şi E2:
 Asocierea “unul-la-unul” (one-to-one)  unei instanţe a lui E1 îi corespunde o
sigură instanţă a clasificatorului E2, şi reciproc; notație: 1:1.
 Asocierea “unul-la-multe” (one-to-many)  unei instanţe a lui E1 îi corespund
una sau mai multe instanţe a lui E2, dar unei instanţe a lui E2 îi corespunde o
singură instanţă a lui E1; notație: 1:N.
 Asocierea “multe-la-unul” (many-to-one)  inversul asocierii prec. notație: N:1
 Asocierea „multe-la-multe” (many-to-many)  unei instanţe a lui E1 îi
corespund una sau mai multe instanţe a lui E2 şi reciproc; notaţie: M:N.
Cardinalitatea şi navigabilitatea asocierilor
 Cardinalitatea (multiplicitatea) unei asocieri faţă de un clasificator
(cardinality, multiplicity) este numărul maxim de instanţe ale acelui
clasificator care pot fi asociate cu o instanţă a celuilalt clasificator
 Raportul dintre cardinalităţile unei asocieri binare faţă de cei doi
clasificatori  raport de cardinalitate (cardinality ratio)
 Reprezentarea raportului de cardinalitate:
 generic: 1:1, 1: N, N :1, M : N
 în UML: se specifică o limită inferioară şi o limită superioară pentru fiecare
cardinalitate; separate prin doua puncte (ex. 1..*); * reprezintă orice valoare
 Asocierile multiple (n-are, n > 2) prezintă câte un raport de cardinalitate
pentru fiecare pereche de clasificatori
 Navigabilitatea unei asocieri – posibilitatea de a naviga – de a afla
clasificatorii asociați unui clasificator dat:
 asociere unidirecţională (reprezentată printr-o săgeată pe linia de asociere)
 asocierei bidirecţională (reprezentată prin două săgeți pe linia de asociere)
 navigabilitate neprecizată (fără săgeți pe linia de asociere)
 Tipuri de asocieri: asocieri simple şi asocieri întreg-parte

Asocieri simple
 Asocierile simple: instanţele asociate sunt de sine stătătoare
 pot fi binare sau multiple
 pot avea orice raport de cardinalitate (1:1, 1: N, N :1, M : N)
 pot avea orice fel de navigabilitate
 În UML se poate specifica:
 Rolul în asociere al fiecărui clasificator (de ex. angajat, angajator)
 Multiplicitatea asocierii față de fiecare clasificator (de ex. 0..1, 1..* etc.)
 Navigabilitatea (unidirecțională, bidirecțională, fără direc ții precizate)
Asocieri simple binare Asociere simplă multiplă

Asocieri de tip întreg-parte
 Asocieri de tip întreg-parte: compoziţia şi agregarea
 Asocierea de compoziţie (composition) este o asociere prin care se
defineşte o legătură puternică de tip întreg-parte:
 instanţe ale unui clasificator de tip “parte” (obiecte) sunt înglobate într-un
obiect - instanţă a clasificatorului care reprezintă întregul
 obiectul compus (“întreg”) nu poate exista (în mod normal) fără părţile sale
 un obiect “parte” nu poate face parte decât dintr-un singur obiect “întreg”
 compoziţia este, în mod tipic, heterogenă
 Compoziţia este o asociere 1: N: unui obiect (obiectul “întreg”) îi
corespund (de fapt, îi aparţin) unul sau mai obiecte “parte”; repr. în UML:

Compoziţia
 În limbajele obiect-orientate compoziţia se implementează prin clase
compuse (clase care au ca atribute instanţe sau referinţe ale altor clase)
 O instanţă a unei clase compuse este un obiect compus şi conţine alte
obiecte (sau referinţe la alte obiecte)
 Un obiect conţinut într-un obiect complex obiect “parte”
 Un atribut al unui obiect compus poate memora:
 o valoare (de un tip primitiv)
 un obiect sau o referinţă la un obiect “parte”
 Compunerea pe mai multe niveluri  ierarhii de compoziţie
 Compoziția este cea mai puternică legătură dintre obiecte; un obiect
“întreg” nu poate exista fără obiectele “parte”; urmează:
 Agregarea – legătură mai slabă decât compoziția și mai puternică decât
asocierea simplă; un obiect “agregat” poate exista fără obiectele “membre”
 Asocierea simplă – legătura cea mai slabă între obiecte; obiectele sunt
independente și pot fi asociate sau nu cu alte obiecte

Agregarea
 Agregarea (aggergation) este o asociere prin care se defineşte o
legătură între un grup (agregat) şi membrii acestuia:
 un “obiect agregat” este mapat cu 0, unul sau mai multe obiecte “membre”
 o agregare poate avea raportul de cardinalitate 1:N sau M:N
 un obiect poate fi membru al mai multor grupuri (obiecte agregat)
 obiectul agregat poate exista (în general) şi în lipsa membrilor săi
 agregarea are (în general) un caracter omogen

Diagrama claselor
 Diagrama UML a claselor
defineşte modelul
structural al unui sistem
prin intermediul unui graf
 nodurile (vârfurile)
grafului sunt clasificatori
 muchiile grafului sunt
legături între clasificatori
 În modelul obiect-orientat
diagrama claselor
reprezintă clasele şi
legăturile dintre ele
 În modelul E-A diagrama
claselor reprezintă
mulţimile de entităţi şi
asocierile dintre ele
Diagrama UML a claselor

Reprezentarea diagramei E-A extinse
printr-o diagramă a claselor în limbajul UML (1)
 Se consideră următoarea diagramă E-A extinsă; generalizarea poate fi:
 disjoint (d – tipurile specializate nu se suprapun) sau overlapped (o)
 complete (se moştenesc toate caracteristicile) sau incomplete
Numar Buget Nume Salariu Denumire Buget
1 N ANGAJAT M N PROIECT
SECTIE
1
d
DEPENDENT
SECRETARA TEHNICIAN INGINER
Nume GradRudenie VitezaRedact Calificare Specialitate

Reprezentarea diagramei E-A extinse
printr-o diagramă a claselor în limbajul UML (2)
 Tipurile de entităţi se reprezintă în UML ca şi clasificatori (clase)
 Pentru reprezentarea subtipurilor în UML se foloseşte generalizarea;
se pot adăuga clauze: disjoint/overlapped şi complete/incomplete
 Pentru reprezentarea asocierilor se folosesc asocieri UML
ANGAJAT
SECTIE PROIECT
Nume
Număr 1 1..* Prenume 1..* 1..* Denumire
Denumire DataNasterii DataInceperii
Buget Adresa Buget
Salariul
1
{disjoint}
1..*
DEPENDENT SECRETARA TEHNICIAN INGINER
Nume VitezaRedactare Specialitatea Specialitatea
Varsta
GradRudenie

Modelarea datelor: entităţi şi asocieri
 Pentru modelarea datelor, necesară în bazele de date, se reprezintă
entităţile şi asocierile dintre acestea
Modelul E-A Modelul relaţional Limbajul UML Modelul
obiect-orientat
tip de entitate relaţie – tabel clasificator - clasa clasa
entitate tuplu – linie în tabel obiect obiect
atribut atribut – coloană în tabel atribut atribut
asociere chei străine asociere ??
 Modelul OO nu are un mecanism precis de reprezentare a asocierilor și a

persistenței datelor
 În modelul OO diferenţa dintre diferite tipuri de asocieri este dată de detalii
de reprezentare a datelor în limbajul de implementare
 În C++ compoziţia se obţine prin definirea datelor membre ale clasei compuse
ca obiecte, iar agregarea şi asocierea simplă se obţin prin definirea datelor
membre ca pointeri la obiecte (din clasa parte)
 În Java nu se pot defini obiecte (instanţe ale claselor) prin declaraţie în clasă,
deci nu se pot evidenţia deosebiri între diferitele tipuri de asocieri
Implementarea asocierilor în limbajele OO
 Conceptual, asocierile se pot implementa prin variabile de asociere; de
exemplu, pentru o asociere bidirecţională 1: N
 variabila de asociere din clasa cu cardinalitatea 1 este o mulţime (set) de referinţe
(pointeri) la clasa asociată
 variabila de asociere din clasa cu card. N este o referinţă simplă (pointer)
class Department {
String dname; ..........
// Variabila de asociere
set<Employee> has_emps; };
class Employee {
String name; …….
// Variabila de asociere
Diagrama E-A în limbajul UML Department work_for; };
 Pentru o asociere M : N se pot folosi variabile de asociere ca mulţimi de
referinţe în ambele clase, sau se poate defini o clasă suplimentară
 Pentru o asociere unidirecţională se prevede o variabilă de asociere
numai în clasa din care pleacă săgeata de navigaţie
 DAR aceste asocieri se definesc între obiecte nepersistente,
deoarece folosesc pointeri sau referinţe la obiecte în memorie,
deci nu se pot folosi într-o bază de date
Bazele de date şi limbajele obiect-orientate
 Sistemele de baze de date sunt axate către:
 stocarea cât mai sigură a unor volume mari de date
 regăsirea cât mai eficientă a informaţiilor
 Modelul obiect (limbaje de programare obiect-orientate) sunt axate către:
 definirea şi manevrarea de date complexe
 extensibilitatea şi reutilizabilitatea codului
 Datele sunt:
 tranzitorii – în limbajele de programare “standard”
 persistente – în bazele de date
 Modalitățile de realizare a bazelor de date şi a limbajelor obiect-orientate
sunt divergente, dar este necesară interoperabilitatea
 În modul cel mai simplist, conversia datelor din tabele (din modelul rela țional) în
obiecte se poate face prin interfețe de programare (ODBC, JDBC)
 Soluţii pentru interoperabilitatea avansată model obiect - baze de date:
 Corespondenţa între modelul obiect-orientat și baze de date relaţionale
(ORM – Object-Relațional Mapping)
 Baze de date obiect-orientate (Object-Oriented Databases)
 Baze de date obiect-relaţionale (Object-Relational Databases)
Corespondenţa obiect-relaţională (1)
 Se defineşte o corespondenţă (mapping) între tabelele din modelul
relaţional şi clasele şi obiectele din modelul obiect-orientat
 Diferite tehnologii oferă automatizarea conversiei între obiecte (stocate
în memorie) şi datele relaţionale (stocate în baza de date pe hard-disk)
 Standarde şi produse pentru corespondenţa obiect-relaţională
 Tehnologia Java
 EJB 2.1 (Enterprise Java Beans) (Platforma J2EE- 1.4)
 Java Persistence API (Platformele Java EE - 5 , 6, 7)
 Java Hibernate (ORM care poate fi integrat în Java standalone și Java EE)
 Platforma .NET (ADO.NET, NHibernate)
 Avantaje:
 Permite accesul la bazele de date relaţionale existente
 Majoritatea operaţiilor de conversie se execută automat
 Dezavantaje:
 Dificultăţi de programare
 Limitări funcţionale şi restricţii datorită corespondenței (mapping-ului)
 Ineficienţă în execuţie (se consumă timp pentru corespondență)

Corespondenţa obiect-relaţională (ORM) în Java
 În tehnologia Java corespondenţa obiect-relaţională se realizează prin:
 asocierea schemei unei relaţii cu o clasă
 fiecare obiect (instanţă a clasei) reprezintă un tuplu din relaţia respectivă
 Clasa conţine câte o variabilă membră corespunzătoare fiecărui atribut al
relaţiei, iar fiecare obiect va avea ca valori ale acestor variabile valorile
atributelor tuplului respectiv din relaţie
 Ex: clasa Cont corespunde tipului entităţilor din tabelul CONT(IdCont, Nume,
Prenume, Suma) şi fiecare obiect corespunde unei linii din tabel
 Diferite implementări (EJB, JPA, Java Hibernate etc)

Corespondenţa ORM în EJB 2.1
 În platforma J2EE 1.4 (EJB 2.1) corespondenţa ORM se realizează prin
componente EJB entitate, deploy-ate într-un container
 Clasa unei componente EJB entitate se asociază cu schema unei relaţii
 Un obiect instanţă a clasei unei componente EJB entitate (obiect entity
enterprise bean, numit obiect entitate) corespunde unei linii din tabel
 Clasa componentei entitate (entity bean class) trebuie să implementeze:
 metodele de citire-scriere a fiecărui atribut (numite metode getter-setter)
 metodele de prelucrare a acestora (numite metode business)
 metodele callback impuse de container
 orice componentă entitate trebuie să prevadă o cheie primară (printr-o clasă
definită), care să permită identificarea unică a fiecărui obiect entitate
 Menţinerea consistenței între valorile atributelor din baza de date şi
valorile atributelor din obiectele asociate  ejbLoad(), ejbStore():
 metoda ejbLoad() citeşte datele din tabelul asociat în obiecte; este apelată de
container la iniţializarea obiectului.
 metoda ejbStore() memorează datele din obiectul entitate în tabel; este
apelată de container ori de câte ori obiectul este modificat
Corespondenţa ORM în Java Persistence API (JPA)
 JPA folosește clase de tip entity (nu enterprise entity bean, ca în J2EE)
 O clasă entitate (entity class) este o clasă care respectă câteva cerinţe:
 Are cel puțin un constructor implicit (fără argumente)
 Este adnotată cu adnotarea javax.persistence.Entity
 Nu poate fi declarată final, nici clasa, și nici unul dintre atributele sau metodele
clasei
 În mod tipic, o clasă entity reprezintă un tabel dintr-o bază de date
relațională, iar fiecare instanță a unei clase entity corespunde unei linii în
tabelul respectiv (la fel ca în EJB)
 O clasă entity poate conține câmpuri tranzitorii (adnotate cu
javax.persistence.Transient) și persistente (toate celelalte)
 Prin moștenire se pot defini ierarhii de clase entity
 Java Persistence API conține și un limbaj de interogare (Java Persistent
Query Language - JPQL) prin care se definesc interogări pentru entită ți și
stările lor persistente
 JPA este integrat în platformele Java EE 5, 6, 7 (2013)

Corespondenţa ORM în Java Hibernate
 Java Hibernate folosește clase de tip POJO (Plain Old Java Object)
pentru definirea coresponenței cu tabelele bazei de date
 O clasă POJO este o clasă care respectă câteva cerinţe:
 Are un constructor implicit (fără argumente)
 Implementează corespunzător metodele moștenite equals() și hashCode()
 Corespondența între clasele Hibernate și tabelele bazei de date
relaționale se realizează prin descriptori în limbajul XML sau prin adnotări
Java (Java annotations, introduse în Java SE 5)
 Java Hibernnate oferă limbajul de interogare HQL (Hibernate Query
Language), inspirat din SQL, prin care se interoghează obiectele de date
Hibernate
 Java Hibernate poate fi integrată în platforma Java (standalone) sau Java
EE (prin servlets sau EJB session beans) folosind toolset-urile NetBeans
IDE, Eclipse etc. sau în platforma .NET (NHibernate)

Biblioteca ADO.NET (1)
 ADO.NET (Access Data Object)  corespondenţa obiect-relaţională în
platforma .NET, oferind un nivel de integrare mai ridicat decât EJB
 ADO permite:
 conectarea la o sursă de date (printr-un obiect de tip Connection)
 transmiterea unei comenzi SQL (printr-un obiect de tip Command)
 recepţionarea rezultatelor (într-un obiect de tip RecordSet)
 Arhitectura ADO.NET constă din mai multe clase, dintre care cea mai
importantă este clasa DataSet, mapată cu o submulţime de tabele
 Datele din aceste tabele sunt încărcate în DataSet, acesta se
deconectează, iar utilizatorul poate manipula datele din acest obiect.
 Periodic, DataSet se reconectează la baza de date pentru:
 actualizarea bazei de date cu modificările efectuate de utilizator în DataSet
 actualizarea obiectului DataSet cu modificările efectuate de ceilalţi utilizatori
în tabelele corespunzătoare obiectului DataSet

Biblioteca ADO.NET (2)
 Clasa DataSet conţine:
 O colecţie (DataTableCollection) de
DataSet
obiecte DataTable, fiecare
reprezentând un tabel din baza de
date
1 1  O colecţie (DataRelationCollection)
DataRelationCollection DataTableCollection de obiecte DataRelation, fiecare
reprezentând o asociere între două
tabele ale bazei de date
0...* 1...*
DataRelation DataTable
1 1 1
DataRowCollection DataCollumnCollection ConstraintCollection
0...* 1...* 0...*

DataRow DataCollumn Constraint

Baze de date obiect-orientate
 Corespondenţa obiect-relaţională:
 ocupă o parte însemnată de cod
 consumă timp cu conversia de la liniile din tabelele de pe disk la obiectele din
memorie şi invers
 Bazele de date obiect-orientate trebuie să integreze limbajele
obiect-orientate cu sistemele de baze de date (cu date persistente) și să
asigure suport pentru:
 persistenţa obiectelor  limbaje de programare persistente
 reprezentarea asocierilor între obiecte persistente
 interogarea bazelor de date şi tranzacţii

Persistenţa obiectelor
 Obiectele din limbajele de programare “obişnuite” (Pascal, C, C++, Java,
C# etc.) sunt tranzitorii, adică dispar când se termină programul
 Pentru a transforma un limbaj de programare obişnuit în limbaj persistent,
necesar pentru bazele de date, prima cerinţă este prevederea unui
mecanism de persistenţă a obiectelor; posibilităţi:
 Persistenţa prin clasă: declararea unei clase persistente; toate obiectele
(instanţele) acelei clase vor fi persistente  metodă neflexibilă
 Persistenţa declarată la crearea obiectelor  se pot crea atât obiecte
persistente cât şi tranzitorii
 Persistenţa prin marcare  obiectele se creează tranzitorii şi se marchează
ca persistente atunci când este necesar
 Persistenţa prin accesibiliate (reachability)  unele obiecte se declară
persistente la creare (obiecte rădăcină - root); orice obiect devine permanent
dacă este referit direct sau indirect de un obiect persistent
 Diferite sisteme de baze de date obiect-orientate adoptă una sau mai
multe din aceste metode de persistenţă

Identitatea obiectelor şi extensia claselor
 În limbajele nepersistente, identificatorul unui obiect (OID) este, în
general, adresa obiectului creat în memorie (pointer, referință), deci este
nepersistent
 Astfel de OID nu pot fi folosiţi în limbajele de programare persistente
 Pentru limbajele persistente, tipic OID “persistenţi”, generaţi de sistem,
care atribuie o identitate unică şi imutabilă unui obiect, care nu se
modifică după ce programul s-a terminat (şi obiectul e memorat pe disk)
 Mai este posibil ca unui obiect să i se atribuie şi o cheie unică într-un
anumit context (extensie a clasei - extent)
 Mai multe (sau toate) obiecte de aceeaşi clasă pot fi grupate într-o
mulţime  extensia clasei
 O clasă poate avea una sau mai multe extinsii şi, în fiecare extensie,
fiecare obiect trebuie să aibă cheia diferită de a celorlalte obiecte (cheia
unică  cheia primară)
 Extensia clasei se foloseşte pentru găsirea obiectelor, prin iterarea
(folosind un iterator) în colecţia respectivă

Standardul ODMG
 ODMG (Object Data Management Grup)  consorţium al producătorilor
de baze de date obiect-orientate:
Ardent Software Inc., Ericsson, Object Design Inc., Objectivity Inc., POET
Software, Versant Corporation
 Standarde pentru ODBMS (Object Database Management Systems)
 1993: ODMG 1.0
 1997: ODMG 2.0
 1999: ODMG 3.0 -http://www.omg.org/docs/omg/04-07-02.pdf
 ODMG specifică:
 Modelul obiect pentru baze de date (ODMG Object model)
 ODL (Object Definition Language)
 OQL (Object Query Language)
 Corespondenţa cu limbaje de programare obiect-orientate de implementare
(binding) (C++, Java, Smalltalk)
 ODMG s-a dizolvat în 2001
 În 2003 OMG a obţinut drepturile asupra standardului ODMG 3.0
 Datorită creșterii utilizării bazelor de date în model obiect, în 2005 s-a
infiinţat OMG Object Database Technology Working Group (ODBTWG),
cu scopul de lansa versiunea 4.0 a standardului, care încă nu a apărut
Particularităţile modelului obiect în ODMG
 Standardul ODMG foloseşte noţiunea de “interface” pentru a descrie
tipuri (clase abstracte) predefinite în ODMG, care oferă funcţii de bază
 Interfeţele nu pot fi instanţiate
 Toate clasele definite de utilizator moştenesc interfaţa Object, care oferă
funcţii de bază (comparaţie, copiere, ştergere)
interface Object { …….
Boolean same_as (in Object other_object);
Object copy();
void delete(); };
 Sunt predefinite interfeţe pentru reprezentarea datei şi timpului: date,
time, timestamp, interval
 Sunt predefinite interfeţe pentru colecţii de obiecte de acelaşi tip: Set,
List, Bag, Array, Dictionary; ex.: tipul Set<T> poate fi folosit pentru
crearea unui obiect a cărui valoare este o mulţime de obiecte de tipul T
(asemenea template-urilor C++ sau tipurilor generice Java SE 5.0)
 Pentru parcurgerea unei colecţii se foloseşte un iterator

Limbajul ODL (Object Definition Language)
 Limbajul ODL se poate folosi pentru crearea schemei unei baze de date
obiect-orientate conform specificaţiilor ODMG
 ODL este proiectat să definească construcţiile din standardul ODMG (clase şi
interfeţe), dar nu este un limbaj complet de programare
 ODL este independent de orice limbaj de programare
 Pentru utilizarea schemei bazei de date specificate în ODL, se face “legarea”
(binding) la un limbaj specific (C++, SMALLTALK, JAVA)
 Obiectele sunt atomice şi au un identificator (OID)
 Identificatorii obiectelor sunt generaţi automat de sistem, nu de aplicaţie
 Indiferent de clasă, obiectele pot fi:
 tranzitorii – memorate numai în memorie
 persistente – stocate pe disk
 Obiectele instanțe ale unei clase sunt grupate într-o mulțime numită
extensia clasei (extent):
 În cadrul extensiei un obiect poate fi identificat prin valoarea unei chei
 Cheia este compusă din unul sau mai multe atribute ale obiectului și trebuie
ca fiecare valoare a cheii să fie unică în cadrul extensiei

Moştenirea în limbajul ODL
 În ODL se poate reprezenta (a) moştenirea comportării (is-a relationship)
și (b) mostenirea stării şi a comportării
 Moştenirea comportării:
moştenirea interfeţelor
interface Employee {…};
inteface Professor : Employee {…};
interface Assistant : Employee {…};
 Moştenirea stării şi a comportării:
moştenirea între clase prin extends:
 moştenire simplă
 se poate combina cu moştenirea
interfeţelor (ca în Java)
 Moştenirile sunt tranzitive şi se pot
defini pe oricâte niveluri

Interfeţe pentru colecţii de date în ODL
<<interface>>
Object
<<interface>> <<interface>>
Iterator Collection
<<interface>> <<interface>> <<interface>> <<interface>> <<interface>>

Set List Bag Array Dictionary

Clase, proprietăţi şi operaţii în limbajul ODL
 Clasele (specificate cu class) definesc tipuri care pot fi instanţiate şi
conţin proprietăţi şi operaţii
 Proprietăţile pot fi atribute (attributes) sau legături (relationships); pentru
fiecare proprietate se specifică:
 tipul proprietății (attribute sau relationship)
 tipul de date (class)
 numele proprietăţii
 exemplu: attribute string name;
 Obiectele - instanţe ale claselor sunt structurate și atomice (indivizibile);
valorile atributelor pot fi:
 Literali - nu au identificatori, sunt înglobaţi în obiecte
 Structuri (struct) - nu au identificatori, sunt înglobaţi în obiecte
 Identificatori ai altor obiecte
 Colectii de elemente (set, array etc.)

Definirea asocierilor în limbajul ODL
 Limbajul ODL permite definirea numai a asocierilor binare
 Pentru o asociere binară (relationship) se definesc ambele capete ale
asocierii, în fiecare din clasele asociate
 Clauza inverse din relationship defineşte referinţa din clasa asociată şi permite
menţinerea automată a integrităţii referenţiale: când se inserează o referinţă,
se verifică existenţa obiectului referit
 Referințele folosesc identificatorii (OID) generați de sistem ai obiectelor
persistente
 Exemplu – Department - Employee cu asocierea binară bidirecţională 1:N
 În clasa cu cardinalitatea N (clasa Employee) relationship este o referinţă la
clasa cu cardinalitatea 1 (relationship Department works_for), iar clauza
inverse specifică proprietatea (relationship) referită din clasa asociată:
inverse Department::has_emps
 În clasa cu cardinalitatea 1 (clasa Department) relationship este o mulţime de
referințe la obiecte din clasa cu cardinalitatea N (relationship set<Employee>
has_emps), iar clauza inverse specifică proprietatea (relationship) referită din
clasa asociată: inverse Employee::works_for

Exemplu de definire a claselor asociate în ODL

Limbajul OQL (Object Query Language)
 OQL este un limbaj de interogare pentru baze de date în modelul obiect
standard ODMG
 OQL poate fi legat (binding) la unul din limbajele de programare C++,
Java, Smalltalk, prin definirea operaţiilor claselor în limbajul respectiv
 Sintaxa unei interogări OQL este similară cu sintaxa SQL, cu
caracteristicile adiţionale prevăzute de modelul obiect ODMG (identitatea
obiectelor, moştenire etc.):
select ..…from …..where
 De exemplu, în baza de date definită mai sus (Department-Employee)
interogarea Q1: “Care sunt numele angajaţilor din departamentul
“Engineering” în limbajul OQL:
Q1: select e.name
from e in all_emplyees
where e.works_for.dname = “Engineering”;

Interogări în limbajul OQL
 Pentru majoritatea interogărilor se specifică un punct de intrare (entry
point) ca extensie a unei clasei, care conţine toate obiectele persistente
din acea clasă
Obiectul cu nume all_employees, care este o colecţie de obiecte de tip mulțime
de obiecte Employee (set<Employee>) în exemplul din interogarea Q1
 Pentru parcurgerea colecţiei se defineşte o variabilă iterator (variabila e
în interogarea Q1) care parcurge toate obiectele din colecţie
 In majoritatea cazurilor, interogarea selectează anumite obiecte din
colecţie, pe baza condiţiei exprimate în clauza where
În Q1, se selectează obiectele care au valoarea atributului dname al proprietăţii
(relationship) works_for egală cu “Engineering”
 Pentru fiecare obiect selectat, valoarea atributului e.works_for.dname
este inclusă în rezultatul interogării
 Rezultatul interogării este o colecţie de tip bag<string>, dat fiind că pot
exista duplicate în rezultat

Legătura (binding) ODL – C++
 Legătura ODL- C++ specifică modul de translatare a construcţiile din
standardul ODL în limbajul C++
 C++ ODL foloseşte o bibliotecă C++ care conţine clasele necesare
lucrului cu bazele de date, cu convenţia ca denumirile acestor clase încep
cu prefixul d_
 Pentru definirea tipurilor predefinite (built-in) din ODMG Object Model,
biblioteca C++ ODL foloseşte clase template; ex:
d_Object, pentru specificarea comportării generale a obiectelor
d_Ref<T>, pentru specificarea unei referinţe (persistente) la un obiect de tip T
d_Collection<T>, pentru specificarea comportării colecţiilor de obiecte de tip T
d_Set<T>, d_Bag<T>, d_List<T>, d_Array<T>, pentru colecţii de ob. de tip T
 Programatorul poate crea clase ca:
d_Set<String> ale cărei instanţe sunt mulţimi de şiruri (obiecte String)
d_Set<d_Ref<Student>> ale cărei instanţe sunt mulţimi de referinţe la obiecte de
tip (clasa) Student
Proiectarea bazelor de date OO
 Prima fază: definirea schemei conceptuale de nivel înalt a bazei de date:
 Se foloseşte un limbaj de modelare suportat de instrumentele CASE
disponibile: diagrama E/A; sau (mai recomandabil) limbajul UML
 Alegerea unui sistem de gestiune OO
 Criteriile de alegere sunt tehnice şi economice
 Proiectarea schemei logice de

implementare (specifice sistemului
de gestiune OO ales):
 Direct, pornind de la schema
conceptuală de nivel înalt
 Indirect, trecând printr-o etapă de
proiectare în standardul ODMG,
folosind limbajul ODL
 Schema logică dependentă de SGBD (implementation design) trebuie să

folosească construcţiile SGBD-ului ales

Exemplu de proiectare a unei baze de date OO
 Fie schema UML a unei baze de date pentru programe de doctorat
(Advanced Database Technology and Design) – moştenirile sunt reprezentate în
notaţia mai veche cu săgeţi pline
 Se remarcă tipul de entitate (clasa)

Participant, cu două clase derivate
Student şi Lecturer
 Clasa PhDProgram este asociată
1:N cu clasa Student şi M:N cu clasa
Lecturer
 Pentru trecerea de la schema UML la schema în limbaj ODL se face

corespondenţa între limbajul UML şi limbajul ODL pentru:
 Definirea tipurilor (clase)
 Definirea generalizărilor (moşteniri între clase)
 Definirea asocierilor (proprietăți relationship ale claselor)

Exemplu - definirea claselor în ODL
 Fiecărei clase UML îi va corespunde o clasă persistentă ODL
 Pentru fiecare clasă ODL se defineşte extensia clasei (extend – mulţime de
obiecte persistente din acea clasă)
 Atributele UML se translatează în atribute ODL
 Atributele UML complexe se pot defini în ODL grupate în structuri (de exemplu
address)
 Atributele cu valori multiple se reprezintă prin colecţii ODL (ex. phone)
 Pentru fiecare metodă din interfaţa UML se prevede o metodă în ODL
 Constrângerile se definesc în cadrul operaţiilor ODL

Exemplu - definirea asocierilor în ODL
 Asocierile 1:N sau M:N bidirecţionale: prin câte o proprietate relationship
în fiecare clasă ODL asociată, cu clauza inverse

Exemplu - definirea moştenirilor în ODL
 Modelul ODMG suportă:
 moştenire simplă a stării – nu se pot reprezenta clase care moştenesc stare
din două sau mai multe clase
 moştenire multiplă a comportării – prin intermediul interfeţelor

Trecerea de la schema conceptuală ODL la
schema conceptuală de implementare
 Depinde de corespondenţa ODL – limbaj de implementare (C++, Java,
SmallTalk binding)
 De exemplu, C++ binding
pentru sistemul POET 4.0
 Clasele trebuie declarate
persistent
 Nu admite struct  se
defineşte clasa Addresstype
 POET suportă colecţiile cset,
lset, hset – mulţimi în diferite
modele de reprezentare
 Asocierile se reprezintă
explicit, unidirecţionale sau
bidirecţionale

Diferenţe între modul de proiectare a
bazelor de date OO şi relaţionale (1)
Modul de reprezentare a asocierilor
 În bazele de date OO se pot reprezenta direct asocieri binare
bidirecţionale M : N prin mulțimi de referinţe (relationship set) la
identificatori OID în ambele clase asociate
 Celelalte asocieri mai simple (asocieri unidirecţionale sau asocieri 1:N) sunt
cazuri particulare ale acestui tip de asociere
 În bazele de date relaţionale:
 asocierea binară unidirecţională 1 : N se reprezintă direct, printr-o cheie
străină introdusă în relaţia care referă (cu cardinalitate N)
 valoarea cheii străine din tuplul care referă (din relaţia cu cardinalitate N)
trebuie să fie egală cu cheia (primară) a tuplului referit (din relaţia cu
cardinalitate 1) sau are valoarea null (integritate referențială)
 orice alt tip de asociere se modelează prin intermediul mai multor asocieri
1 : N, folosind relaţii suplimentare de asociere

Diferenţe între modul de proiectare a
bazelor de date OO şi relaţionale (2)
Modul de reprezentare a moştenirilor
 În bazele de date OO moştenirea se reprezintă prin clase derivate
 Se definesc clase derivate care specializează (moştenesc) clasele de bază
 Un obiect instanţă al unei clase derivate conţine toate valorile atributelor, atât
ale celor moştenite cât şi ale celor definite în propria clasă şi răspunde la
toate mesajele (apel de metode), atât ale celor moştenite cât şi ale celor
definite în propria clasă
 În bazele de date relaţionale pentru extinderea unui tip de entitate
(specializare):
 se defineşte un subtip, asociat cu supertipul pe care îl specializează, cu
raportul de cardinalitate 1:1 unidirecţional (direcţia: de la subtip către supertip)
 unei entităţi de subtip îi corespund două tupluri, unul în relaţia subtip şi cel
asociat din relaţia supertip
 tuplul din relaţia subtip conţine o cheie străină care referă tuplul corespunzător
din relaţia supertip

Sisteme actuale de gestiune a bazelor de date OO (1)
 http://en.wikipedia.org/wiki/Comparison_of_object_database_management_systems

Sisteme actuale de gestiune a bazelor de date OO (2)

Sisteme SGBDOO actuale comerciale
 Objectivity/DB (http://www.objectivity.com)
 Versiunea actuală (11.2) - binding pentru: C++, Java, Smalltalk, SQL (ODBC)
 Suportă tranzacții ACID și replicarea gestionată de software-ul Objectibity/DB
 Asigură scalabilitate în managementul volumelor mari de date (big data)
 Este indicată pentru: analiza volumelor mari de date (big data analysis),
analiza rețelelor, fuziunea datelor
 ObjectStore (http://www.objectstore.com)
 Versiunea actuală ObjectStore 2013 oferă binding pentru C++ si Java, în
sisteme de operare Windows 7 și Linux (RedHat); indicată pentru:
 Aplicații de timp real
 Prelucrarea volumelor mari de date (big data)

Bibliografie specifică
Baze de date obiect-orientate
 R. Cattell, “Object Database Tutorial”, 2009
 R.G. Cattell, D.K. Barry, “The Object Data Standard: ODMG 3.0”, Morgan
Kaufmann, 1999

Capitolul 4 - Baze de date obiect-relaţionale
 Caracteristicile modelului obiect-relaţional
 Tipuri de date definite de utilizator şi instanţele acestora (obiecte)
 Metodele tipurilor definite de utilizator; constructori
 Categorii de obiecte: de coloană (column object) şi de linie (row object)
 Operaţii cu obiecte şi colecţii de obiecte
 Identificatorii obiectelor (OID)
 Referinţe la obiecte (REF)
 Moştenirea tipurilor de date
 Colecţii de date în modelul OR:
 vectori de elemente (varray)
 tabele imbricate (nested tables)
 Proiectarea bazelor de date obiect-relaţionale
 Exemplu – baza de date PurchaseOrder (PO) în sistemul Oracle
 Caracteristici obiect-relaţionale în alte SGBD-uri
Prof. Felicia Ionescu Baze de date obiect-relationale 1

Motivaţia pentru modelul obiect-relaţional (OR)
 Reluăm deficienţele modelului relaţional:
 nu suportă tipuri de date complexe
 nu suportă tipuri definite de utilizator
 admite numai forme normale ale relaţiilor - prima forma normală impune
memorarea numai de valori atomice şi scalare ale atributelor; pentru valori
multiple ale unui atribut, trebuie creată o nouă relaţie
 Deficienţele modelului obiect-orientat de baze de date:
 complexitate mare a tipurilor de date
 intercorelare între proiectul bazei de date şi aplicaţiile bazei de date
 lipsa unui limbaj standardizat atât de concis și productiv cum este SQL
 Modelul obiect-relaţional
 combină avantajele modelului relaţional cu cele ale modelului obiect
 încercă să elimine cât mai multe din deficienţele fiecăruia dintre modele
 Tranziţia de la modelul relaţional la modelul obiect relaţional  în mod
treptat, pentru a micşora riscul de piaţă: Oracle, IBM, Microsoft

Caracteristicile modelului obiect-relaţional (OR)
 Caracteristicile modelului OR:
1. Tipuri de date definite de utilizator (UDT - user defined types, sau tipuri
abstracte de date - ADT abstract data types) corespund claselor (OO)
 se foloseşte modelul de date relaţional, dar atributele pot avea ca valori
obiecte, instanţe ale unor tipuri definite de utilizator
 tipurile de date definite de utilizator încapsulează atribute și metode;
metodele se pot defini în diferite limbaje (PL/SQL, Java, C, C++)
 permite moştenirea tipurilor şi polimorfismul
 obiecte instanţe ale tipurilor; se pot defini identificatori ai obiectelor și
referinţe la obiecte (REF)
2. Tipuri de date pentru obiecte mari – BLOB (bits large objects), CLOB
3. Colecţii de date: vectori de elemente şi tabele imbricate
 permite utilizarea unei colecţii ca valoare a unui atribut  elimină restricţia de
formă normală FN1
 Suport pentru standardul SQL:
 SGBD-urile relaționale suportă standardul SQL-92 (SQL-2) (sau precedente)
 SGBD-urile obiect-relaţionale (OR) suportă standardul SQL-99 (SQL-3) sau
versiuni ulterioare (SQL:2003, SQL:2005, SQL:2008)
Standarde SQL
 Marea majoritate a SGBD-urilor relaționale și obiect-relaționale suportă
una din versiunile standardului SQL, care oferă instrucțiuni pentru toate
operațiile cu bazele de date
 SQL este standardizat de două comitete internaționale recunoscute de
majoritatea producătorilor și utilizatorilor de baze de date: ANSI (American
National Standardization Institute) și ISO (International Standardization Office),
afiliat la IEC (Int. Electrotechnical Commission)
 Fiecare standard SQL este publicat de ambele comitete, cu denumiri conform
propriilor convenții, dar identice din punct de vedere tehnic
 Primele standarde SQL (până la SQL-92 inclusiv) prevedeau instruc țiuni
pentru modelul relațional, fără suport pentru tipuri de date complexe
(definite de itilizator) sau de control al ordinii de execuție
 Standardele SQL ulterioare (SQL-99, SQL:2003, SQL:2005, SQL:2008)
definesc modelul obiect-relațional de baze de date, cu suport pentru tipuri
de date complexe și control al ordinii de execuție a instruc țiunilor

Standardul SQL:2008 (1)
 Standardul SQL:2008 conține mai multe părți, cu denumirile:
 ANSI/ISO/IEC 9075:2008, "Database Language SQL“: Parts:
1 ("SQL/Framework"), 2 ("SQL/Foundation"), 3 ("SQL/CLI"), 4 ("SQL/PSM"),...
9 ("SQL/MED"), 10 ("SQL/OLB"), 11("SQL/Schemata"),…
 ANSI/ISO/IEC 9075-14:2008, "Database Language SQL",Part 14("SQL/XML")
 SGBD-urile implementează caracteristicile SQL cu diferite grade de
conformitate cu standardele existente:
 Oracle SQL oferă full support (pentru toate caracteristicile) SQL:2008
 Alte SGBD-uri oferă suport numai pentru anumite caracteristici SQL:2008
 Partea obligatorie de conformitate cu standardul SQL pentru SGBD-urile
relaționale este numită Core SQL:2008 și este cuprinsă în SQL:2008
Part 2 (Foundation) și Part 11 (Schemata)
 Instrucțiunile de control al ordinii de execuție sunt cuprinse în SQL :2008
Part 4 (PSM – Persistent Stored Modules); acestea permit scrierea și
execuția modulelor stocate (proceduri, funcții, triggere, package-uri)
 Astfel de instrucțiuni sunt prevăzute în majoritatea SGBD-urilor relaționale sau
obiect-relaționale, ca extensii procedurale ale limbajului SQL
 Oracle PL/SQL a fost dezvoltat ca extensie a limbajului SQL încă din primele
implementări în SGBD Oracle; apoi a fost adaptat să fie în conformitate cu
standardele obiect-relaționale (SQL:2008)
 La fel, PostgreSQL, Transact-SQL (Microsoft SQL Server), MySQL - similare
cu SQL-PSM
Standardul SQL:2008 (2)
 SQL- PSM specifică construcţii care permit scrierea codului procedurilor şi
funcţiilor  extensii procedurale
 Instrucţiuni compuse:
BEGIN
<statement list>
END;
 Declararea variabilelor locale:
DECLARE <data type> identifier [DEFAULT <value>] ;
 Instrucţiuni condiţionale:
IF <condition> THEN <statement list>
ELSEIF <condition> THEN <statement list>
ELSEIF <condition> THEN <statement list>
ELSE <statement list>
END IF;
 Instrucţiuni de ciclare (bucle):
WHILE <condition> DO REPEAT
<statement list> <statement list>
END WHILE ; UNTIL <condition>
END REPEAT;

Oracle SQL şi PL/SQL (1)
 Oracle (versiunile actuale 11gR2, 12c) oferă cele mai avansate
caracteristici obiect-relaţionale şi va fi folosit pentru majoritatea
exemplificărilor
 Pentru dezvoltarea aplicaţiilor Oracle se folosesc SQL şi PL-SQL
 Oracle SQL este limbaj de definire, modificare şi interogare a bazelor de date
 PL/SQL este extensia procedurală a limbajului SQL, conform cu SQL:2008
PSM; este folosit pentru crearea funcţiilor, procedurilor stocate, trigerelor şi a
pachetelor (packages)
 În programe PL/SQL se pot introduce majoritatea instrucţiunilor SQL
 Oracle SQL implementeaza toate caracteristicile limbajului SQL standard,
și contine mai multe tipuri de instructiuni (statements) :
 Data Definition Language (DDL): CREATE…, ALTER…, DROP…, GRANT
 Data Manipulation Language (DML): CALL <procedure_name> INSERT,
DELETE, UPDATE, SELECT
 Transaction Control: SET TRANSACTION, COMMIT, ROLLBACK
 Session Control Statements
 System Control Statement
 Embedded SQL Statements

 Oracle PL/SQL are ca unitate de bază a unui program PL/SQL blocul,
compus din trei părţi: declaraţii, partea executabilă, rutine de tratare a
excepţiilor
[DECLARE variabile] -- opţională
BEGIN
-- partea executabila, obligatorie pentru orice bloc
[EXCEPTION rutine_tratare_exceptii] -- opţională
END;
 În partea executabilă, între BEGIN şi END, se admit:
 instrucţiuni SQL de manipulare a datelor SQL
 instrucţiuni SQL de control a tranzacţiilor
 instrucţiuni de control PL/SQL
 NU se admit instrucţiuni SQL de definire a datelor
 Blocurile PL/SQL pot fi imbricate
 Blocurile PL/SQL pot fi:
 Blocuri anonime (care se execută imediat)
 Blocuri memorate (proceduri stocate, triggere şi funcţii definite de utilizator): se
compilează, se memorează și pot fi apelate apoi din orice program

 Instrucţiuni PL/SQL de control a execuţiei:
IF conditie THEN ... [ELSE ... ] END IF;
CASE
FOR conditie LOOP
WHILE conditie LOOP
LOOP ... EXIT WHEN conditie
 Instrucţiunile de manipulare a datelor SELECT, INSERT, UPDATE,

DELETE:
 Pot fi folosite interactiv, ca instrucțiuni SQL transmise SGBD-ului
 Pot fi incluse în blocuri PL/SQL și folosite în combinaţie cu variabilele locale
ale programului; de ex., SELECT se poate folosi astfel într-un bloc PL/SQL:
SELECT lista_coloane INTO lista_variabile
FROM lista_tabele [WHERE conditie] [optiuni];
 Crearea tipurilor UDT, a tipurilor de colecţii de date şi a tipurilor de tabele
imbricate (caracteristici obiect-relaţionale) se face prin instrucţiuni SQL
(CREATE TYPE…)
 Crearea și utilizarea obiectelor se poate face și în SQL şi în PL/SQL

Tipuri de date SQL
 În standard SQL-92 (model relarional) tipurile de date ale atributelor sunt
tipuri simple, predefinite:
 numere (integer, floating point, numeric, decimal)
 şiruri de caractere și de biți (de lungime fixă sau variabilă) (char, varchar etc.)
 dată-timp (date, time, datetime, interval)
 pentru acestea sunt prevăzute operaţii prin operatori şi funcţii SQL predefinite
 În standardul SQL:2008 (modelul obiect-relational) există:
 Tipuri de date predefinite (built-in) – la fel ca în SQL-92
 Tipuri de date definite de utilizator (User-Defined Type – UDT)
 Tipuri de date furnizate de SGBD – sunt tot tipuri UDT, dar furnizate de SGBD
 Tipuri de date UDT furnizate de SGBD Oracle:
 XML_types: XMLType, URIType
 spatial_types: SDO_Geometry, SDO_Topo_Geometry, SDO_Raster
 media_types: ORDAudio, ORDImage,ORDVideo,ORDDoc, ORDDicom
 Instrucțiunea SQL:2008 pentru crearea unui tip de date (UDT):
CREATE TYPE <type-name> [AS] (
list of component attributes with individual types
declaration of EQUAL and LESS THAN functions
declaration of other functions (methods)
);
Tipuri de date (UDT) și obiecte Oracle SQL
 Un tip de date (“object type”) este o clasă care conţine atribute şi metode:
 Atributele memorează datele obiectului; ele pot fi de tipuri predefinite, alte
tipuri UDT, vectori de valori, tabele imbricate, referinţe
 Metodele sunt proceduri sau funcţii pe care se pot executa şi definesc
comportarea obiectelor tipului respectiv – CREATE TYPE BODY
 Tipurile Oracle SQL se creeaza cu instrucțiunea SQL CREATE TYPE:
CREATE TYPE person_typ AS OBJECT (
idno NUMBER, //
first_name VARCHAR2(20), // class person_typ (C++)
last_name VARCHAR2(25), //
email VARCHAR2(25),
phone VARCHAR2(20), class person_typ {
MAP MEMBER FUNCTION get_idno int idno;
RETURN NUMBER) NOT FINAL; char first_name[20];
/ char last_name[25];
CREATE TYPE BODY person_typ AS char email[25];
MAP MEMBER FUNCTION get_idno char phone[20];
RETURN NUMBER IS public:
-- Metoda este definita in PL/SQL int get_idno();
BEGIN
};
RETURN idno;
END; int person_typ::get_idno(){
END; return idno;
/ }

Tipuri de date (UDT) și obiecte Oracle SQL (2)
 In Oracle SQL tipul de acces la componente este implicit: atributele si
metodele declarate in tip constitue interfata si sunt de tip public, iar
implementarea metodelor este de tip private
 Obiectele sunt instante ale tipurilor UDT (clase) si contin valorile
atributelor tipului instantiat

Metodele tipurilor de date UDT (1)
 Metodele definite în tipurile UDT sunt subprograme (proceduri sau funcţii)
care definesc comportarea obiectelor de acel tip
 Aceste subprograme pot fi scrise în diferite limbaje şi pot fi:
 cu memorare internă (în baza de date)
 cu memorare externă (în afara bazei de date)
 În Oracle, metodele scrise în PL/SQL şi Java sunt memorate în baza de
date; cele scrise în C, C++, C# sunt memorate extern
 Parametrii metodelor pot fi de intrare (IN), de ieşire (OUT), de
intrare-ieşire (IN OUT); implicit sunt IN
 Metodele unui tip de date (object type, class): metode membre nestatice
(ale obiectelor), metode statice (ale clasei), constructori
 Metodele membre nestatice ale tipurilor de date:
 permit accesul la obiectele instanţe ale clasei
 conţin un parametru predefinit (SELF) care referă obiectul instanţă pentru care
se invocă metoda (asemănător cu this din C++, Java)
 parametrul SELF poate fi declarat explicit, dar declararea nu este neapărat
necesara
 se utilizeaza in diferite situatii, de exemplu pentru a diferentia parametrii de
apel de atributele clasei, daca au aceeasi denumire
Metodele tipurilor de date UDT (2)
 Exemplu (Oracle) (NOCOPY – obiectele nu se copiază local în funcţie):
CREATE OR REPLACE TYPE solid_typ AS OBJECT (
len INTEGER,
wth INTEGER,
hgt INTEGER,
MEMBER FUNCTION volume RETURN INTEGER,
MEMBER PROCEDURE display (SELF IN OUT NOCOPY solid_typ) );
/ //
CREATE OR REPLACE TYPE BODY solid_typ AS // class solid_typ (C++)
MEMBER FUNCTION volume RETURN INTEGER IS //
BEGIN class solid_typ {
RETURN len * wth * hgt; int len;
-- RETURN SELF.len * SELF.wth * SELF.hgt; int wth;
-- equivalent to previous implementation int hgt;
END; public:
MEMBER PROCEDURE display ( int volume();
SELF IN OUT NOCOPY solid_typ) IS void display();
BEGIN };
DBMS_OUTPUT.PUT_LINE ( int solid_typ::volume() {
'L: ' || len || ' - ' || 'W: ' || wth || ' - ' || 'H: ' || hgt); return len*wth*hgt;
END; }
END; void solid_typ::display() {
/ printf ("L: %4d W: %4d H: %4d \n",
len, wth, hgt);
}

Metode constructori
 O metodă constructor este o funcţie care returnează o nouă instanţă a
unui tip de date; are acelaşi nume ca şi tipul de date respectiv
 Invocarea constructorului se face prin numele tipului de date urmat de
lista de argumente; ex:
person_typ (1, 'John’, ‘ Smith', ‘john@yahoo.com’, '1-650-555-0135')
 Pentru invocarea unui constructor se poate folosi şi new, dar acesta nu
este neapărat necesar (PL/SQL: p := new person_typ(100, ‘Ian’, …);
 Tipuri de constructori: generaţi de sistem sau definiţi de utilizator
 Sistemul SGBD generează un constructor implicit pentru orice tip UDT
care conţin atribute si le initializeaza cu valorile date ca argumente (se
numeşte attribute-value constructor)
 Constructorii definiţi de utilizator:
 Pot ascunde constructorul generat de sistem
 Se pot defini mai mulţi constructori ca metode supraîncărcate (overloaded);
selecţia constructorului se face după numărul sau tipul argumentelor
 Au ca prim parametru obligatoriu SELF (declarat explicit sau nu)
 Returnează obligatoriu SELF: RETURN SELF AS RESULT

Exemplu de constructori definiţi de utilizator
CREATE TYPE shape AS OBJECT (
name VARCHAR2(30),
area NUMBER,
CONSTRUCTOR FUNCTION shape (SELF IN OUT NOCOPY shape, name VARCHAR2)
RETURN SELF AS RESULT,
CONSTRUCTOR FUNCTION shape (SELF IN OUT NOCOPY shape, name VARCHAR2,
area NUMBER) RETURN SELF AS RESULT
) NOT FINAL;
class shape {
/
protected:
CREATE TYPE BODY shape AS
char name[30];
CONSTRUCTOR FUNCTION shape (
float area;
SELF IN OUT NOCOPY shape, name VARCHAR2)
public:
RETURN SELF AS RESULT IS
shape () {}
BEGIN
shape (char name[]);
SELF.name := name;
shape (char name[], float area);
SELF.area := 0;
};
RETURN;
shape::shape(char name[]) {
END;
// Daca name are lung >= 30,
CONSTRUCTOR FUNCTION shape(
// va apare eroare
SELF IN OUT NOCOPY shape, name VARCHAR2,
// ar trebui tratatarea exceptiei
area NUMBER) RETURN SELF AS RESULT IS
strcpy (this->name, name);
BEGIN
area = 0;
SELF.name := name;
}
SELF.area := area; shape::shape(char name[], float area){
RETURN; strcpy (this->name, name);
END; this->area = area;
END; }
/
Tipuri de date compuse
 Tipul employee_typ are un atribut care este de tip address_typ
CREATE TYPE address_typ AS OBJECT ( class address_typ {
street VARCHAR2(30), char street[30], city[20];
city VARCHAR2(20), int number;
numar INTEGER); public:
/ address_typ (char street[],char city[], int number);
CREATE TYPE employee_typ AS OBJECT (
};
employee_id NUMBER(6),
first_name VARCHAR2(20), address_typ::address_typ(char street[],
last_name VARCHAR2(25), char city[], int number) {
address address_typ, strcpy (this->street, street); strcpy (this->city, city);
MAP MEMBER FUNCTION get_idno this->number = number;
RETURN NUMBER, }
MEMBER PROCEDURE display_address ( class employee_typ {
SELF IN OUT NOCOPY employee_typ ) ); int employee_id;
/ char first_name[30], last_name[30];
CREATE TYPE BODY employee_typ AS address_typ address;
MAP MEMBER FUNCTION get_idno public:
RETURN NUMBER IS employee_typ(int employee_id, char first_name[],
BEGIN char last_name[],char street[],char city[], int number);
RETURN employee_id; int get_idno();
END; void display();
MEMBER PROCEDURE display_address ( };
SELF IN OUT NOCOPY employee_typ ) IS employee_typ::employee_typ(int employee_id,
BEGIN char first_name[], char last_name[], char street[],
DBMS_OUTPUT.PUT_LINE(first_name || ' ' || char city[], int number) : address(street,city,number){
last_name); this->employee_id = employee_id;
DBMS_OUTPUT.PUT_LINE(address.street || ', ' || strcpy(this->first_name, first_name);
address.city || ' ' || address.numar); strcpy(this->last_name, last_name);
END; }
END; int employee_typ::get_idno(){
/ return employee_id;
Prof. Felicia Ionescu Baze de date obiect-relationale
} 17
Exemple de creare a tipurilor de date
 În SQL Developer se pot inspecta tipurile de date create (definiția atributelor și
a metodelor)
 Obs. Codul de creare este rescris de toolset, în format standard

Creare și accesarea obiectelor UDT
 Obiectele (instanţe ale tipurilor UDT) se pot creea:
 Prin inserarea obiectelor in tabele care contin tipurile de date instantiate (vom
exemplifica dupa prezentarea tipurilor de tabele Oracle)
 In blocuri PL/SQL
 Pentru accesul la metodele şi atributele obiectelor se foloseşte operatorul
de selecţie membru (.)
 Exemplu - obiecte în blocuri PL/SQL - asemănător cu creeare în C++
DECLARE
emp employee_typ; -- declare object emp; it is atomically null
BEGIN
-- call the constructor for employee_typ; new is optional
emp := new employee_typ(315, 'Francis', 'Logan',
address_typ('376 Mission', 'San Francisco', 94222));
DBMS_OUTPUT.PUT_LINE(emp.first_name || ' ' || emp.last_name); -- display details
emp.display_address(); -- call object method to display details
END;
/ int main() {
employee_typ emp (315, (char*)"Frances",
(char*)"Logan", (char*)"Mission",
(char*) "San Francisco", 94222);
emp.display();
return 0;
}

Crearea tabelelor
 În sistemele Oracle se pot crea două categorii de tabele: tabele
relaționale și tabele de obiecte
 Tabele relaționale (relational table) – se crează cu instrucțiunea CREATE
TABLE și poate conține mai multe atribute (coloane); tipul unui atribut
poate fi: tip predefinit, tip UDT, vector de date, tabel imbricat
 Valoarea unui atribut (coloană) de tip UDT este un obiect instanță a acelui tip;
se mai numește și obiect coloană (column object)
 De exemplu, tabelul “contacts” este definit ca tabel relaţional, în care coloana
“contact” are ca valori obiecte de tipul person_typ;
CREATE TABLE contacts (
contact person_typ,
contact_date DATE );
 Tabele de obiecte (object table): fiecare linie conține un obiect de tipul
tabelului (numit obiect linie – row object) ; de exemplu:
CREATE TABLE persons OF person_typ;
 Un astfel de tabel poate fi privit ca:
 Un tabel cu o singură coloană care conţine numai obiecte (object table);
fiecare linie conţine un obiect de tipul dat (row object)
 Un tabel cu coloanele corespunzătoare atributelor tipului dat

Exemplu: crearea tabelelor
 In SQL Developer se observă că:
 CONTACTS este un tabel relational care contine:
 un atribut (CONTACT) care este de tipul UDT PERSON_TYP
 un atribut (CONTACT_DATE) care este de tip SQL predefinit (DATE)
 PERSONS este un tabel de obiecte compus dintr-o coloană de tip UDT și
fiecare linie conține un obiect de acel tip (PERSON_TYP)
 reprezentarea se face ca tabel care are ca și coloane atributele tipului respectiv

Cheile primare ale tabelelor
 Pentru tabelele relaționale cheile primare se definesc printr-un atribut
(simplu sau compus) al relației - la fel ca în modelul relațional
 Pentru tabelele de obiecte cheile primare se definesc printr-un atribut
(simplu sau compus) al tipului de obiecte
 Exemplu:
-- CREATE OR REPLACE TYPE person_typ AS OBJECT (…) a fost creat deja
CREATE OR REPLACE TYPE location_typ AS OBJECT (
building_no NUMBER,
city VARCHAR2(40) );
/
CREATE OR REPLACE TYPE office_typ AS OBJECT (
office_id VARCHAR(10),
office_loc location_typ,
occupant person_typ );
/
CREATE TABLE office_tab OF office_typ (
office_id PRIMARY KEY );
/

Crearea, iniţializarea si accesarea obiectelor coloană
 Se pot crea obiecte coloană în tabele relationale în SQL, prin instructiuni
INSERT; la crearea obiectelor se invocă constructorii care le şi iniţializează
CREATE TABLE persons_tab (
name varchar2(20),
address address_typ);
/
INSERT INTO persons_tab VALUES ('John Smith', address_typ ('Rock', 'New York', 17) );
INSERT INTO persons_tab VALUES('Ave Mile', address_typ ('Lake Lane', 'New York', 62) );

Creearea si utilizarea tabelelor de obiecte în SQL
 Crearea tabelelor de obiecte:
CREATE TABLE solids of solid_typ;
 Inserarea obiectelor în tabel – se apeleză implicit sau explicit constructorul
tipului UDT iar datele se introduc ca valori ale atributelor tipului de obiecte:
INSERT INTO solids VALUES(10, 10, 10);
-- SAU: INSERT INTO solids VALUES(solid_typ(10,10,10));
INSERT INTO solids VALUES(3, 4, 5);
 Interogarea interactivă folosind limbajul SQL:
 se defineste o variabilă tabel (table alias - solids s, în exemplul dat)
 se foloseşte operatorul de selecţie membru (.) pentru acea variabilă
select s.volume() from solids s where s.len=10; select s.len from solids s;

Utilizarea tabelelor de obiecte în blocuri PL/SQL
 Fie tabelul employee_tab creat cu comanda SQL:
CREATE TABLE employee_tab of employee_typ;
/
 În blocul PL/SQL următor se creează și se citesc obiecte (linii) în tabel:
DECLARE emp employee_typ;
BEGIN
INSERT INTO employee_tab VALUES (employee_typ(310, 'Evers', 'Boston',
address_typ('123 Main', 'San Francisco', 94111)) );
INSERT INTO employee_tab VALUES (employee_typ(321, 'Martha', 'Dunn',
address_typ('123 Broadway', 'Redwood City', 94065)) );
SELECT VALUE(e) INTO emp FROM employee_tab e WHERE e.employee_id = 310;
emp.display_address();
END;
/
 Funcţia VALUE are ca argument o variabilă tabel de obiecte (object table
alias) si returnează obiectele coresp liniilor care îndeplinesc conditia dată

Metode de comparare a obiectelor
 Valorile tipurilor scalare predefinite (char, float, numeric etc.) pot fi
comparate şi ordonate, deoarece au o ordine predefinită
 Obiectele conţin valori ale atributelor proprii de diferite tipuri şi nu pot fi
comparate sau ordonate direct
 Pentru obiecte este necesar definirea unei metode de mapare (MAP)
SAU a unei metode de ordonare (ORDER); NU ambele!
 Functia definita este invocată automat atunci când se compară două
obiecte de acel tip (în clauze ca DISTINCT, GROUP BY, ORDER BY)
 Metoda de mapare (MAP MEMBER FUNCTION):
 Returnează o valoare de un tip scalar predefinit, calculată din valorile
atributelor obiectului
 Pentru un UDT în care s-a definit funcția MAP MEMBER FUNCTION map()
RETURN number, comparaţia a două obiecte din acea clasa (UDT)
obj_1 > obj_2 este echivalentă cu: obj_1.map() > obj_2.map()
 Metoda de ordonare (ORDER MEMBER FUNCTION) compară obiectul
curent cu obiectul dat ca argument pe baza unui anumit criteriu si
returnează:
 valoare negativă (dacă obiectul curent este mai mic decat obiectul argument)
 0 (obiectele sunt egale)
 valoare pozitivă (dacă obiectul curent este mai mare decat obiectul argument)

Metode de mapare şi ordonare
 Exemplu: pentru comparaţia a două obiecte rectangle_typ se defineşte o
metoda de tip MAP area() SAU o metoda de tip ORDER compare()
CREATE OR REPLACE TYPE rectangle_typ AS OBJECT (
len NUMBER,
wid NUMBER,
-- se poate defini o metoda de ordonare in locul metodei de mapare ; NU ambele
-- MAP MEMBER FUNCTION area RETURN NUMBER);
ORDER MEMBER FUNCTION compare (r rectangle_typ) RETURN INTEGER );
/
CREATE OR REPLACE TYPE BODY rectangle_typ AS class rectangle_typ {
-- MAP MEMBER FUNCTION area RETURN NUMBER IS int len;
int wid;
-- BEGIN public:
-- RETURN len * wid; rectangle_typ(int len, int wid);
-- END; int area ();
ORDER MEMBER FUNCTION compare(r rectangle_typ) int compare(rectangle_typ &r);
RETURN INTEGER IS };
BEGIN rectangle_typ::rectangle_typ(int len, int wid){
IF len*wid < r.len*r.wid THEN RETURN -1; this-> len = len;
-- any negative number will do this->wid = wid;
ELSIF len*wid > r.len*r.wid THEN RETURN 1; }
-- any positive number will do int rectangle_typ::area(){
ELSE RETURN 0; return len*wid;
}
END IF; int rectangle_typ::compare(rectangle_typ &r){
END; if (len*wid < r.len*r.wid) return -1;
END; else if (len*wid > r.len*r.wid) return 1;
/ else return 0;
}
Exemplu de utilizare a metodei de ordonare
 Se defineste tabelul relational RECTANGLES_TAB:
CREATE TABLE RECTANGLES_TAB(
rectangle RECTANGLE_TYP,
color varchar2(10));
/
 Se inserează valori in tabel folosind instructiuni SQL; pentru obiecte se
invoca constructorul (rectangle_typ) :
INSERT INTO RECTANGLES_TAB VALUES(rectangle_typ(2,4), 'rosu');
INSERT INTO RECTANGLES_TAB VALUES(rectangle_typ(7,3), 'verde');
INSERT INTO RECTANGLES_TAB VALUES(rectangle_typ(5,9), 'albastru');
 Ordonare linii după
atributul color:
SELECT r.color FROM
RECTANGLES_TAB r
order BY color;
 Ordonare linii după
atributul rectangle –
invoca metoda de
comparare a tipului:
SELECT r.rectangle FROM
RECTANGLES_TAB r
order BY rectangle;

Metode statice
 Metodele statice sunt invocate pentru un tip de obiecte, nu pentru
instanţe ale acestuia
 Metodele statice nu au parametrul SELF
 Metodele statice se declară folosind specificatorii: STATIC FUNCTION
sau STATIC PROCEDURE.
 Apelul metodelor statice se face calificând metoda (folosind operatorul
de selecţie membru .) cu numele tipului, nu cu numele unui obiect
instanţă al acestuia
 De exemplu:
type_name.method()

Identificatorii obiectelor şi referinţe la obiecte
 Obiectele linie (“row objects”) din tabelele de obiecte pot fi identificate
prin identificatori (OIDs – Object IDentifiers), care pot fi de două feluri:
 OID generaţi de sistem
 OID bazaţi pe chei primare – definite de proiectant
 Obiectele coloană (“column objects”) din tabelele relationale sunt
identificate prin cheia primară a liniei (tuplului) din care fac parte şi nu
necesită OID speciali
 O referinţă REF T (unde T este un tip de date) este un “pointer” logic
care permite identificarea unui obiect linie de tipul T folosind OID-ul
 O referinţă poate fi modificată astfel încât să indice un obiect diferit, dar
de acelaşi tip T (sau un supertip al acestuia)
 Referinţele modelează asocierile N:1, și pot înlocui cheile străine:
CREATE TYPE emp_typ AS OBJECT (
emp_id number, class emp_typ {
name VARCHAR2(30), int emp_id;
char name[30];
manager REF emp_typ ); emp_typ &manager;
/ };
CREATE TABLE emp_objtab OF emp_typ;
/

Referinţe la obiecte
 Referintele se definesc cu operatorul REF; de exemplu, se introduc date
in tabelul emp_objtab cu instructiuni SQL astfel:
INSERT INTO emp_objtab VALUES (1,'Evens Brown', NULL);
INSERT INTO emp_objtab VALUES (2, 'Martin Joe', (SELECT REF(e)
FROM emp_objtab e WHERE e.name = 'Evens Brown'));
 Se afişează continutul tabelului:
SELECT * FROM emp_objtab;

Referinţele la obiecte pot înlocui cheile străine
 Varianta relationala a tabelului emp_objtab poate fi scrisă astfel:
CREATE TABLE emp_reltab (
emp_id number PRIMARY KEY,
name varchar2(30),
manager number,
FOREIGN KEY (manager) REFERENCES emp_reltab(emp_id));
/
 Se introduc date în tabelul emp_reltab:
INSERT INTO emp_reltab VALUES (1,'Evens Brown', NULL);
INSERT INTO emp_reltab VALUES (2, 'Martin Joe', (SELECT e.emp_id
FROM emp_reltab e WHERE e.name = 'Evens Brown'));

Crearea referinţelor şi dereferenţierea
 O referinţă la un obiect linie se poate obţine prin selectarea obiectului din
tabelul său de obiecte şi aplicând operatorul REF
 Dereferentierea înseamnă accesarea obiectului cu o referinta data
 În SQL dereferentierea se face implicit sau cu operatorul DEREF:
-- dereferntiere implicita în SQL
SELECT e.name, e.manager.name FROM emp_objtab e WHERE e.name = 'Martin Joe';
-- dereferntiere cu operatorul DEREF în SQL
SELECT e.name, DEREF(e.manager).name FROM emp_objtab e where e.name = 'Martin Joe';
 În Oracle PL/SQL, dereferetierea se face numai cu operatorul DEREF;
exemplu: obţinerea referinţei la obiectul persoanei care are idno = 1 și
apoi dereferentierea cu operatorul DEREF și tabelul DUAL:
DECLARE
person_ref REF person_typ;
person person_typ;
BEGIN
SELECT REF(p) INTO person_ref
FROM persons p
WHERE p.idno = 1;
SELECT DEREF(person_ref) into person FROM dual; -- use dummy table DUAL
DBMS_OUTPUT.PUT_LINE (person.FIRST_NAME || ' ' || person.LAST_NAME);
END;
 În ferestra DBMS Output se afişează numele și prenumele persoanei cu idno = 1
Moştenirea tipurilor UDT
 Un subtip reprezintă o specializare a unui tip dat (numit supertip) şi se
defineşte folosind cuvântul cheie under:
CREATE TYPE person_typ AS OBJECT ( class person_typ {
idno NUMBER, int idno;
first_name VARCHAR2(20),
char first_name[20];
last_name VARCHAR2(25),
char last_name[25];
email VARCHAR2(25),
char email[25];
phone VARCHAR2(20),
char phone[20];
) NOT FINAL;
};
/
class student_typ: public person_typ {
CREATE TYPE student_typ UNDER person_typ (
department varchar2(20) char department[20];
); };
 Tipul de baza (supertipul) trebuie sa fie declarat explicit NOT FINAL

 Un subtip moşteneşte:
 atributele definite sau moştenite de supertip
 metodele definite sau moştenite de supertip(cu excepţia constructorilor)
 Metodele moştenite pot fi redefinite (redefined), dacă nu sunt declarate
FINAL
 Ierarhii de tipuri de date - supertipuri şi subtipuri
 Unele sisteme (printre care şi Oracle) admit numai moştenirea simplă
Exemplu - Moştenire (1)
CREATE TYPE rectangle UNDER shape (
len NUMBER, wth NUMBER,
CONSTRUCTOR FUNCTION rectangle(SELF IN OUT NOCOPY rectangle,
name VARCHAR2, len NUMBER, wth NUMBER) RETURN SELF as RESULT,
CONSTRUCTOR FUNCTION rectangle(SELF IN OUT NOCOPY rectangle,
name VARCHAR2, side NUMBER) RETURN SELF as RESULT);
/ class shape {
CREATE TYPE BODY rectangle IS protected:
CONSTRUCTOR FUNCTION rectangle ( char name[30];
SELF IN OUT NOCOPY rectangle, float area;
name VARCHAR2, len NUMBER, wth NUMBER) public: shape () {}
shape (char name[]);
RETURN SELF AS RESULT IS
shape (char name[], float area);
BEGIN };
SELF.name := name; SELF.area := len*wth; class rectangle : public shape {
SELF.len := len; SELF.wth := wth; float len, wth;
RETURN ; public:
END; rectangle(char name[], float len, float wth);
CONSTRUCTOR FUNCTION rectangle ( rectangle(char name[], float side);
SELF IN OUT NOCOPY rectangle, };
rectangle::rectangle(char name[], float len,
name VARCHAR2, float wth) : shape(name) {
side NUMBER) RETURN SELF AS RESULT IS this->len = len;
BEGIN this->wth = wth;
SELF.name := name; SELF.area := side * side; area = len*wth;
SELF.len := side; SELF.wth := side; }
RETURN ; rectangle::rectangle(char name[], float side) {
END; strcpy(this->name, name);
END; len = side;
wth = side;
/ area = side*side;
Prof. Felicia Ionescu Baze de date obiect-relationale
} 35
Exemplu - Moştenire (2)
 Într-o coloana de obiecte de un tip dat (dintr-un tabel relational sau tabel de
obiecte) se pot insera obiecte de tipul respectiv şi de subtipuri ale acestuia
 De exemplu: în tabelul de obiecte de tip shape se pot insera obiecte shape
şi rectangle:
CREATE TABLE shape_tab OF shape;
/
INSERT INTO shape_tab VALUES(shape('shape1'));
INSERT INTO shape_tab VALUES(shape('shape2', 20));
INSERT INTO shape_tab VALUES(rectangle('rectangle', 2, 5));
INSERT INTO shape_tab VALUES(rectangle('square', 12));
SELECT * FROM shape_tab;

Colecţii de date
 Modelul OR suportă colecţii de date: vectori de date (varray) şi tabele
imbricate (nested tables); sunt folosite pentru atribute cu valori multiple
 Un vector de date este o colecţie ordonată de elemente de acelaşi tip
 Un tabel îmbricat este un tabel de obiecte de un tip dat
 În Oracle, un vector (varray) este o mulţime ordonată de elemente:
 Elementele sunt de acelaşi tip sau de un subtip al tipului declarat
 Fiecare element are un index, care este poziţia elementului în vector
 La definirea unui vector se specifică numărul maxim de elemente admis
 Numărul real de elemente poate varia, fără a depăşi limita impusă
 Exemplu:
CREATE TYPE phone_typ AS OBJECT (
country_code VARCHAR2(2),
area_code VARCHAR2(3),
ph_number VARCHAR2(7));
/
CREATE TYPE phone_varray_typ AS VARRAY(5) OF phone_typ;
/
CREATE TABLE dept_phone_list (
dept_no NUMBER(5),
phone_list phone_varray_typ);
/

Vectori de date
 Se inserează date în tabel, apeland constructori pentru obiecte si varray:
INSERT INTO dept_phone_list VALUES (100, phone_varray_typ ( phone_typ ('01', '650',
'5550123'), phone_typ ('01', '650', '5550148'), phone_typ ('01', '650', '5550192')));
 Se afișează liniile tabelului:
SELECT * FROM dept_phone_list;

Tabele imbricate
 Un tabel imbricat este un tabel de obiecte de un anumit tip
 Exemplu – reluam tipul person_typ si cream un tip nou, pentru un tabel imbricat de
obiecte person_typ:
CREATE TYPE people_typ AS TABLE OF person_typ; -- used as nested table type
/
 După crearea tipului unui tabel imbricat (nested table), se poate folosi acest tip ca
tip al unel coloane a unui tabel relational:
CREATE TABLE people_tab ( -- relational table
group_no NUMBER,
people_column people_typ ) -- an instance of nested table
NESTED TABLE people_column STORE AS people_column_nt;
/
INSERT INTO people_tab VALUES (100,
people_typ(person_typ(1, 'John','Smith', 'jsmith@yahoo.co','1-650-555-0135'),
person_typ(2, 'Diane','Smith', NULL, NULL)));
 O instanţă a unui tip de colecţie (varray sau nested table) se creează la fel ca o
instanţă a oricărui tip (object type), prin apelul metodei constructor al acelui tip

Memorarea tabelelor imbricate
 Oracle memorează tabelele imbricate într-o zonă de memorie separată
 Un identificator NESTED_TABLE_ID (generat de SGBD pe 16 biţi sau
creeat folosind PK a tabelului parinte) corelează liniile unui tabel imbricat
cu linia corespunzatoare din tabelul părinte
 Datele imbricate sunt grupate în
tabele corespunzătoare liniilor din
tabelul părinte (tabel A, tabel B etc.)
 În coloana NT_DATA din tabelul
părinte se memorează ID-ul
(identificatorul) tabelului imbricat al
fiecarei linii a tab. parinte (A,B,C etc.)
 Tabelele imbricate sunt grupate
într-un tabel memorat separat de
tabelul parinte (storage table)
 Storage table contine o coloana cu
identificatorul tabelului imbricat
( NESTED_TABLE_ID)
corespunzator liniei din tabelul
parinte si o coloana cu un obiect de
tipul obiectelor din tabelul imbricat;
Rezumat: crearea tipurilor de date și a tabelelor
 Crearea unui tip UDT:
CREATE TYPE person_typ AS OBJECT (
idno NUMBER, first_name VARCHAR2(20), last_name VARCHAR2(25),
email VARCHAR2(25), phone VARCHAR2(20)) NOT FINAL;
 Crearea unui tabel de obiecte:
CREATE TABLE persons OF person_typ;
 Crearea unui tabel relational cu o coloana de tip UDT:
CREATE TABLE contacts (
contact person_typ, contact_date date);
 Crearea unui tip pentru vectori VARRAY
CREATE TYPE person_varray_typ AS VARRAY(5) OF person_typ;
 Crearea unui tabel relational cu o coloana varray:
CREATE TABLE people_varray_tab (
group_no number, person_list person_varray_typ );
 Crearea unui tip pentru tabele imbricate (nested table)
CREATE TYPE people_typ AS TABLE OF person_typ; -- nested table type
 Crearea unui tabel relational cu o coloana tabel imbricat (nested table):
CREATE TABLE people_tab (
group_no NUMBER, people_column people_typ ) -- an instance of nested table
NESTED TABLE people_column STORE AS people_column_nt;

Proiectarea unei baze de date în Oracle
 Se va compara proiectul relaţional cu proiectul obiect-relaţional al
aceleiaşi baze de date – Purchase Order (PO)
 Baza de date este descrisă prin diagrama E/A de mai jos
1 N 1 N 1
Customer PurchaseOrder ItemLine N Stock
 Schema logică relaţională a bazei de date se obţine uşor prin

transpunerea directă a diagramei E/A:
 tipurile de entitate din diagrama E/A devin relaţii (tabele) în schema logică
 asocierile din diagrama E/A devin asocieri prin chei străine în schema logică

Crearea tabelelor în modelul relaţional (1)
 Se creează tabelele şi asocierile dintre ele:
CREATE TABLE Customer_reltab (
CustNo NUMBER NOT NULL,
CustName VARCHAR2(200) NOT NULL,
Street VARCHAR2(200) NOT NULL,
City VARCHAR2(200) NOT NULL,
State CHAR(2) NOT NULL,
Zip VARCHAR2(20) NOT NULL,
Phone1 VARCHAR2(20),
PRIMARY KEY (CustNo)
);
/
CREATE TABLE Stock_reltab (
StockNo NUMBER PRIMARY KEY,
Price NUMBER,
TaxRate NUMBER
);
/

Crearea tabelelor în modelul relaţional (2)
CREATE TABLE PurchaseOrder_reltab (
PONo NUMBER, /* PK, purchase order no */
Custno NUMBER references Customer_reltab, /* FK referencing Customer */
OrderDate DATE, /* date of order */
ShipDate DATE, /* date to be shipped */
ToStreet VARCHAR2(200), /* shipto address */
ToCity VARCHAR2(200),
ToState CHAR(2),
ToZip VARCHAR2(20),
PRIMARY KEY(PONo)
);
/
CREATE TABLE LineItems_reltab (
LineItemNo NUMBER,
PONo NUMBER REFERENCES PurchaseOrder_reltab, /* FK ref. PurchaseOrder*/
StockNo NUMBER REFERENCES Stock_reltab, /* FK ref. Stock */
Quantity NUMBER,
Discount NUMBER,
PRIMARY KEY (PONo, LineItemNo)
);
/
Tabelul LineItems_reltab face asocierea intre PurchaseOrder_reltab si Stock_reltab
prin cele doua chei straine (PONo, StockNo) (observati sintaxa simplificata pt. FK)
Inserarea datelor în tabelele relaţionale
 Stabilirea inventarului (stocurile):
INSERT INTO Stock_reltab VALUES(1004, 6750.00, 2);
 Înregistrarea clienţilor:
INSERT INTO Customer_reltab VALUES (1, 'Jean Nance', '2 Avocet Drive',
'Redwood Shores', 'CA', '95054', '415-555-0102', NULL, NULL);
INSERT INTO Customer_reltab VALUES (2, 'John Nike', '323 College Drive',
'Edison', 'NJ', '08820', '609-555-0190', '201-555-0140', NULL);
 Plasarea ordinelor de cumpărare:
INSERT INTO PurchaseOrder_reltab VALUES (1001, 1, SYSDATE, '10-MAY-2014',
NULL, NULL, NULL, NULL);
INSERT INTO PurchaseOrder_reltab VALUES (2001, 2, SYSDATE, '20-MAY-2014',
'55 Madison Ave', 'Madison', 'WI', '53715');
 Stabilirea liniilor din ordinele de cumpărare in tabelul de asociere:
INSERT INTO LineItems_reltab VALUES(01, 1001, 1534, 12, 0);

Continutul tabelelor relaționale

Interogări în modelul relaţional (1)
 Interogarea: Care sunt numarul și numele clientului unui ordin de
cumpărare dat (PONo = 1001)?
SELECT C.CustNo, C.CustName
FROM Customer_reltab C,
PurchaseOrder_reltab P,
LineItems_reltab L
WHERE C.CustNo = P.CustNo
AND P.PONo = L.PONo
AND P.PONo = 1001;

 Interogarea: Care este valoarea totală a tuturor ordinelor de cumpărare?
SELECT P.PONo, SUM(S.Price * L.Quantity)
FROM PurchaseOrder_reltab P, LineItems_reltab L, Stock_reltab S
WHERE P.PONo = L.PONo AND L.StockNo = S.StockNo GROUP BY P.PONo;

 Interogarea: Care sunt datele ordinului de cumparare si a liniilor
acestora care se refera la un stoc dat (StockNo= 1004)?
SELECT P.PONo, P.CustNo,
L.StockNo, L.LineItemNo, L.Quantity, L.Discount
FROM PurchaseOrder_reltab P, LineItems_reltab L
WHERE P.PONo = L.PONo AND L.StockNo = 1004;

Proiectarea schemei obiect-relaţionale
 Plecând de la aceeaşi diagramă E/A,
se reprezintă schema
obiect-relaţională ca diagramă a
claselor în limbajul UML:
 Tipurile de entităţi principale devin
tipuri de date (“object type”):
Customer, PurchaseOrder, Stock,
LineItem
 Se defineşte un tip UDT pentru
adresă, care reuneşte toate
componentele adresei (street, city
etc.);
 Pentru reprezentarea telefoanelor se
foloseşte un vector (varray)
 Pentru reprezentarea liniilor
(LineItems) din ordinul de cumpărare *
(PurchaseOrder) se folosește un
tabel imbricat (nested table)
Definirea tipurilor de date (1)
 Tipul StockItem_objtyp se foloseşte pentru definirea tabelului de obiecte “stock”
CREATE TYPE StockItem_objtyp AS OBJECT (
StockNo NUMBER,
Price NUMBER,
TaxRate NUMBER );
 Tipul LineItem_objtyp se foloseşte pentru definirea unei linii din ordin de cump.
CREATE TYPE LineItem_objtyp AS OBJECT (
LineItemNo NUMBER,
Stock_ref REF StockItem_objtyp, /* reference to StockItem_objtyp */
Quantity NUMBER,
Discount NUMBER );
 Tipul pentru tabelul imbricat cu liniile din ordinul de cumpărare (line items):
CREATE TYPE LineItemList_ntabtyp AS TABLE OF LineItem_objtyp;
 Tipul Address_objtyp se foloseşte pentru adrese:
CREATE TYPE Address_objtyp AS OBJECT (
Street VARCHAR2(200),
City VARCHAR2(200),
State CHAR(2),
Zip VARCHAR2(20) );

 Pentru numerele de telefon se defineşte un tip de date vector (varray):
CREATE TYPE PhoneList_vartyp AS VARRAY(10) OF VARCHAR2(20);
 Tipul Customer_objtyp se foloseşte pentru definirea tabelului Customer
 conţine un obiect de tipul PhoneList_vartyp care este un vector pentru telefoane şi un
obiect de tipul Address_objtyp pentru adresa
 conţine o metodă de comparaţie de tip ORDER, care este invocată automat atunci când
se compară două obiecte de acest tip
CREATE TYPE Customer_objtyp AS OBJECT (
CustNo NUMBER,
CustName VARCHAR2(200),
Address_obj Address_objtyp,
PhoneList_var PhoneList_vartyp,
ORDER MEMBER FUNCTION
compareCustOrders(x IN Customer_objtyp) RETURN INTEGER
) NOT FINAL;
/
CREATE OR REPLACE TYPE BODY Customer_objtyp AS
ORDER MEMBER FUNCTION
compareCustOrders (x IN Customer_objtyp) RETURN INTEGER IS
BEGIN RETURN CustNo - x.CustNo; END;
END;
/
 Crearea tipului PurchaseOrder_objtyp pentru tabelul PurchaseOrder:
CREATE TYPE PurchaseOrder_objtyp AUTHID CURRENT_USER AS OBJECT (
PONo NUMBER,
Cust_ref REF Customer_objtyp,
OrderDate DATE,
ShipDate DATE,
LineItemList_ntab LineItemList_ntabtyp,
ShipToAddr_obj Address_objtyp,
MAP MEMBER FUNCTION getPONo RETURN NUMBER,
MEMBER FUNCTION sumLineItems RETURN NUMBER);
/
 Fiecare obiect instanţă a acestui tip reprezintă un ordin de cumpărare
(PurchaseOrder); AUTHID CURRENT_USER specifică faptul ca tipul
respectiv este definit folosind drepturile utilizatorului curent
 Obiectele au şase atribute care sunt:
 atribute de tipuri predefinite (PONo, OrderDate, ShipDate)
 o referinţă la un obiect de tipul Customer_objtyp, care asigură asocierea cu
tabelul Customer
 un obiect de tipul Adress_objtyp, care conţine adresa de livrare (ShipTo)
 un tabel imbricat de tipul LineItemList_ntabtyp, care conţine liniile ordinului
 Metodele tipului PurchaseOrder_objtyp, definite ca funcţii PL/SQL sunt:
 O metodă de comparaţie de tipul MAP (getPONo) care returnează valoarea
atributului PONo şi care va fi invocată automat ori de câte ori se compară
două obiecte de acest tip
 Metoda de calcul a sumei valorilor liniilor unui ordin (sumLineItems) – care
va fi explicata mai tarziu, dupa definirea tabelului imbricat
CREATE OR REPLACE TYPE BODY PurchaseOrder_objtyp AS
MAP MEMBER FUNCTION getPONo RETURN NUMBER IS
BEGIN RETURN PONo; END;
MEMBER FUNCTION sumLineItems RETURN NUMBER IS
i INTEGER; StockVal StockItem_objtyp; Total NUMBER := 0;
BEGIN
IF (UTL_COLL.IS_LOCATOR(LineItemList_ntab)) -- check for locator
THEN SELECT SUM(L.Quantity * L.Stock_ref.Price) INTO Total
FROM TABLE(CAST(LineItemList_ntab AS LineItemList_ntabtyp)) L;
ELSE FOR i in 1..SELF.LineItemList_ntab.COUNT LOOP
UTL_REF.SELECT_OBJECT(LineItemList_ntab(i).Stock_ref,StockVal);
Total := Total + SELF.LineItemList_ntab(i).Quantity * StockVal.Price;
END LOOP;
END IF;
RETURN Total;
END;
END;
/

Crearea tabelelor de obiecte
 Folosind tipurile UDT definite anterior se vor crea urm. tabele de obiecte:
Stock_objtab, Customer_objtab, Purchase_Order_objtab, LineItemList_ntab (tabel
imbricat în PurchaseOrder_objtab)
 Fiecare linie a unui astfel de tabel conţine un obiect de tipul specificat
(obiect linie)
 Obiectele linie sunt referenţiabile, adică alte linii relaţionale sau obiecte
linii (row objects) pot referi un obiect linie folosind identif. acesteia (OID)
 Identificatorii OID ai obiectelor linie:
 pot fi generaţi automat de sistem; aceasta se specifică în instrucţiunea
CREATE TABLE prin opţiunea: OBJECT IDENTIFIER IS SYSTEM
GENERATED
 se poate folosi cheia primară a tabelului ca identificator OID al obiectelor
tabelului; aceasta se specifică în instrucţiunea CREATE TABLE prin opţiunea:
OBJECT IDENTIFIER IS PRIMARY KEY
 Tabelul Stock_objtab:
CREATE TABLE Stock_objtab OF StockItem_objtyp (StockNo PRIMARY KEY)
OBJECT IDENTIFIER IS PRIMARY KEY;

Tabelul Customer_objtab
CREATE TABLE Customer_objtab OF Customer_objtyp (CustNo PRIMARY KEY)
OBJECT IDENTIFIER IS PRIMARY KEY;
Fiecare obiect linie

conţine:
 Atribute de tipuri
predefinite (CUSTNO,
CUSTNAME)
 Un atribut obiect de tipul
Addres_objtyp care
conţine componentele
adresei
 Un atribut obiect de tipul
PhoneList_vartyp, care
este un vector de
dimensiune maximă 10
cu numere de telefon
(repr. ca varchar2(20))

Tabelul PurchaseOrder_objtab (1)
CREATE TABLE PurchaseOrder_objtab OF PurchaseOrder_objtyp ( /* Line 1 */
PRIMARY KEY (PONo), /* Line 2 */
FOREIGN KEY (Cust_ref) REFERENCES Customer_objtab) /* Line 3 */
OBJECT IDENTIFIER IS PRIMARY KEY /* Line 4 */
NESTED TABLE LineItemList_ntab STORE AS PoLine_ntab ( /* Line 5 */
(PRIMARY KEY(NESTED_TABLE_ID, LineItemNo)) /* Line 6 */
ORGANIZATION INDEX COMPRESS) /* Line 7 */
RETURN AS LOCATOR /* Line 8*/
/
 Line 1: specifică tipul obiectelor tabelului; fiecare linie va conţine un
obiect de tipul PurchaseOrder_objtyp; atributele acestor obiecte sunt:
PONo NUMBER
Cust_ref REF Customer_objtyp
OrderDate DATE
ShipDate DATE
LineItemList_ntab LineItemList_ntabtyp
ShipToAddr_obj Address_objtyp
 Line 2: specifică cheia primară a tabelului (PONo)

 Line 3: FOREIGN KEY (Cust_ref) REFERENCES Customer_objtab)
 Specifică constrângerea de integritate referenţială (FOREIGN KEY): atributul Cust_ref
trebuie să refere numai obiecte existente în tabelul Customer_objtab
Column object of
the defined type

 Line 4: OBJECT IDENTIFIER IS PRIMARY KEY
 Această linie specifică faptul că identificatorul OID al unui obiect linie al tabelului este
cheia primară a tabelului
 Line 5-8: specifică proprietăţile tabelului imbricat LineItemList_ntab
NESTED TABLE LineItemList_ntab STORE AS PoLine_ntab ( /* Line 5 */
(PRIMARY KEY(NESTED_TABLE_ID, LineItemNo)) /* Line 6 */
ORGANIZATION INDEX COMPRESS) /* Line 7 */
RETURN AS LOCATOR /* Line 8 */
 Line 5: indică faptul că tabelul imbricat LineItemList_ntab este memorat ca tabel
separat, numit PoLine_ntab
 Linia 6: o coloană ascunsă numită NESTED_TABLE_ID pune în corespondenţă fiecare
linie din tabelul imbricat cu linia părinte
 Cheia primara a tabelului imbricat este formata din coloana NESTED_TABLE_ID si
LineItemNo (atribut al tipului LiniItem_objtyp)
 Liniia 7: tabelul imbricat este organizat indexat (index-organized table - IOT) cu
compresia identificatorilor (adică identificatorul liniei părinte se memorează o singură
dată pentru toate liniile imbricate corespunzătoare)
 Linia 8: se returnează locația tabelului imbricat; dacă acest specificator lipsește, implicit
se returnează VALUE, adică tot tabelul imbricat

Definirea metodei sumLineItems a tipului
PurchaseOrder_objtyp
 Tabelul imbricat LineItemsList_ntab poate fi returnat ca valoare sau ca
localizare, daca in defintia tabelului parinte exista specificatia: RETURN
AS LOCATOR si aceasta se afla prin apelul functiei
UTL_COLL.IS_LOCATOR, care returneaza TRUE in acest caz
 Daca tabelul imbricat este returnat ca localizare, acesta este interogat
folosind expresia TABLE, cu conversia (CAST) de la numele coloanei la
tipul tabelului:
SELECT SUM(L.Quantity * L.Stock_ref.Price) INTO Total
FROM TABLE(CAST(LineItemList_ntab AS LineItemList_ntabtyp)) L;
 Daca tabelul imbricat este returnat ca valoare (in lipsa specificatiei
RETURN AS LOCATOR):
 Cuvântul cheie SELF indică utilizarea atributelor proprii obiectului
 Cuvântul cheie COUNT specifică numărul de elemente ale tabelului
 Pentru derefenţierea referinţei Stock_ref se apelează funcţia
SELECT_OBJECT din package-ul UTL_REF, deoarece PL/SQL nu suportă
dereferenţierea directă din programe PL/SQL

Tabelul imbricat LineItemList_ntab
 Tabelul imbricat LineItemList_ntab conţine o referinţă (STOCK_REF) la
tabelul Stock_objtab, care realizează asocierea între tabelul
PurchaseOrder_objtab și tabelul Stock_objtab
 Se adaugă SCOPE pentru STOCK_ REF in tabelul imbricat:
ALTER TABLE PoLine_ntab
ADD (SCOPE FOR (Stock_ref) IS Stock_objtab);

Inserarea datelor în tabelele
Stock_objtab și Customer_objtab
 Inserarea datelor în tabelele de obiecte seamănă cu inserarea în
tabelele relaţionale, doar că pentru fiecare obiect se invocă constructorul
 Inserarea datelor în tabelul Stock_objtab:
INSERT INTO Stock_objtab VALUES(1004, 6750.00, 2) ;
 Inserarea datelor în tabelul Customer_objtab:
INSERT INTO Customer_objtab
VALUES (1, 'Jean Nance',
Address_objtyp('2 Avocet Drive', 'Redwood Shores', 'CA', '95054'),
PhoneList_vartyp('415-555-0102')
);
INSERT INTO Customer_objtab
VALUES ( 2, 'John Nike',
Address_objtyp('323 College Drive', 'Edison', 'NJ', '08820'),
PhoneList_vartyp('609-555-0190','201-555-0140')
);

Conținutul tabelelor
Stock_objtab și Customer_objtab

Inserarea datelor în tabelul PurchaseOrder_objtab
 Inserarea datelor în tabelul PurchaseOrder_objtab:
INSERT INTO PurchaseOrder_objtab
SELECT 1001, REF(C), SYSDATE, '10-MAY-15',
LineItemList_ntabtyp(), NULL -- void nested table, ShipToAddress = NULL
FROM Customer_objtab C WHERE C.CustNo = 1 ;
INSERT INTO PurchaseOrder_objtab
SELECT 2001, REF(C), SYSDATE, '20-MAY-15', LineItemList_ntabtyp(),
Address_objtyp('55 Madison Ave','Madison','WI','53715')
FROM Customer_objtab C WHERE C.CustNo = 2 ;
 Prima instrucţiune crează un obiect de tipul PurchaseOrder_objtyp cu
următoarele atribute:
PONo 1001
Cust_ref referință la Customer cu CustNo = 1
OrderDate SYSDATE
ShipDate 10-May-15
LineItemList_ntab o listă vidă de obiecte de tipul LineItem_ntabtyp
ShipToAddr_obj null
 Aceaste instrucţiuni folosesc o interogare SELECT pentru a construi
referinţa la obiectul din tabelul Customer_objtab care are CustNo = ...
Inserarea datelor în tabelul LineItemList_ntab (1)
 Următoarele instrucţiuni insereaza cate o linie in tabelul imbricat din
coloana LineItemList_ntab din tabelul PurchaseOrder_objtab, coresp.
liniei care are valoarea lui PONo egală cu o val data (1001 sau 2001);
INSERT INTO TABLE (
SELECT P.LineItemList_ntab
FROM PurchaseOrder_objtab P
WHERE P.PONo = 1001
)
SELECT 1, REF(S), 12, 0 -- LineItemNO = 1, REF(S), Quantity = 12, Discount = 0
FROM Stock_objtab S
WHERE S.StockNo = 1534 ;
INSERT INTO TABLE (

WHERE P.PONo = 1001
)
SELECT 2, REF(S), 10, 10 -- LineItemNO = 2, REF(S), Quantity = 10, Discount = 10
FROM Stock_objtab S

Inserarea datelor în tabelul LineItemList_ntab (2)
INSERT INTO TABLE (
WHERE P.PONo = 2001
)
SELECT 10, REF(S), 1, 0 -- LineItemNo = 10 10, REF(S), Quantity = 1, Discount = 0
FROM Stock_objtab S
INSERT INTO TABLE (

WHERE P.PONo = 2001
)
SELECT 11, REF(S), 2, 1 -- LineItemNo = 11, REF(S), Quantity = 2, Discount = 1
FROM Stock_objtab S
 Valoarea inserată conţine o referinţă la obiectul linie din tabelul
STOCK_objtab care are valoarea atributului StockNo dorită

Conținutul tabelului PurchaseOrder_objtab

Interogări în baza de date obiect-relaţională
 Interogarea: Care sunt valorile PONo ale ordinelor de cumpărare,
ordonate după numărul ordinului (PONo)?
SELECT p.PONo FROM PurchaseOrder_objtab p
ORDER BY VALUE(p) ;
 În această interogare este invocată automat metoda getPONo pentru
ordonarea liniilor rezultatului după atributul PONo
 Interogarea: Care este valoarea totală a fiecărui ordin de cumpărare?
SELECT p.PONo, p.sumLineItems()
FROM PurchaseOrder_objtab p ;
 Interogarea: Care sunt datele clientului şi detaliile (liniile) ordinulului de
cumpărare cu numărul 1001?
SELECT DEREF(p.Cust_ref), p.ShipToAddr_obj, p.PONo, p.OrderDate,
LineItemList_ntab FROM PurchaseOrder_objtab p WHERE p.PONo = 1001 ;

Comparație – baze de date relaționale și
obiect-relaționale Oracle
 Exemplul de mai sus a avut ca scop comparația între proiectul relațional și
cel obiect-relațional al aceleiași baze de date Purchase Order (PO)
 Proiectul relaţional al unei baze de date pare mai simplu decât proiectul
obiect-relaţional al aceleiaşi baze de date, dar modelul obiect-relaţional:
 Structurează proiectul bazei de date – prin gruparea atributelor în tipuri și
vectori de date (tip adresa, vector de numere de telefon etc.)
 Folosește referințe pentru asociere, în locul cheilor străine, ceea ce este mult
mai eficient
 Permite gruparea unor linii de asociere în tabele imbricate, mărind viteza de
execuție (nu se mai caută valoarea referită în tabel ci se folose ște indexarea)
 În modelul relațional asocierea între tabelul PurchaseOrder_reltab și Stock_reltab
se face prin tabel LineItems_reltab care con ține 2 chei străine
 În modelul obiect-rela țional, asocierea dintre tabelul PurchaseOrder_objtab și
Stock_objtab se dace printr-un tabelul imbricat LineItemList_ntab (continut ca
atribut al tipului PurchaseOrder_objtyp), compus din liniile ordinului de plată
respectiv, și fiecare linie din tabelul imbricat con ține o referin ță la un obiect din
tabelul Stock_objtab
 Majoritatea bazelor de date pentru aplicaţii ştiinţifice folosesc
caracteristicile modelului obiect-relațional, atât pentru tipuri complexe de
date (tipuri de date spaţiale, temporale, multimedia etc.) cât și pentru
referințe, vectori, tabele imbricate
Caracteristici obiect-relaţionale în alte SGBD-uri
 MySQL (versiunea 5.6) nu oferă suport pentru tipuri definite de utilizator,
dar are unele extensii de tipuri de date mai complexe, pentru format XML
și date spațiale (vor fi prezentate la capitolele corespunzatoare)
 PostgreSQL (versiunea 8.4) are o varietate de tipuri complexe predefinite
sau definite de utilizator:
 Geometric types
 Network address types
 Arrays types
 Composite types
 Object identifier types – folosite de PostgreSQL ca şi chei primare în tabelele
de sistem
 Pseudo types – tipuri care pot fi folosite pentru argumente sau valorile
returnate de funcţii (nu coloane în tabele) (any, cstring, record etc.)
 Tipuri definite de utilizator

Tipuri geometrice în PostgreSQL
 Tipurile geometrice sunt predefinite, impreuna cu mai multi operatori geometrici

Tipuri complexe în PostgreSQL
 Tablouri uni şi multidimensionale de date și tabele care contin tablouri:
CREATE TABLE tictactoe (
squares integer[ ][ ]);
 Tipuri compuse şi tabele care conţin tipuri compuse:
CREATE TYPE complex AS (
r double precision,
i double precision );
CREATE TYPE inventory_item AS (
name text, -- text este un sir de caractere de lungime nelimitata, delimitat caract. spec.
supplier_id integer,
price numeric );
CREATE TABLE inventory_tab (
item inventory_item,
count integer );
 Se pot defini functii care au ca argumente tipuri complexe
 Se pot executa operaţii de manipulare a datelor folosind instrucţiuni SQL
INSERT INTO inventory_tab VALUES (ROW(’fuzzy dice’, 42, 1.99), 1000);
SELECT item.name FROM inventory_tab WHERE item.price > 9.99;

Tipuri definite de utilizator în PostgreSQL (1)
 Tipurile definite de utilizator:
 Conţin tipuri de date (structuri, clase) şi metode create într-un limbaj de uz
general (tipic, C), memorate într-o bibliotecă partajată (so, dll)
 Tipul SQL corespunzător accesează şi utilizează biblioteca respectivă
 Pentru fiecare tip definit de utilizator se definesc funcţii de intrare şi
ieşire care specifică modul de serializare a tipului, precum şi funcţii
pentru orice operaţie efectuată cu obiecte de acel tip
 Funcţia de intrare primeşte ca argument un şir de caractere terminat cu null
şi returnează reprezentarea internă (în memorie) a tipului
 Funcţia de ieşire primeşte ca argument reprezentarea internă a unui obiect
de acel tip şi returnează un şir de caractere terminat cu null
 Exemplu: se defineşte în C tipul (structura) de numere complexe şi
funcţiile de intrare iesire într-o bibliotecă partajată (în ‘filename’):
typedef struct Complex {
double x;
double y;
} Complex;

Tipuri definite de utilizator în PostgreSQL (2)
 Apoi se declară tipul complex şi funcţiile de intrare-ieşire în SQL:
CREATE TYPE complex;
CREATE FUNCTION complex_in (cstring)
RETURNS complex
AS ’filename’
LANGUAGE C IMMUTABLE STRICT;
CREATE FUNCTION complex_out (complex)
RETURNS cstring
AS ’filename’
LANGUAGE C IMMUTABLE STRICT;
IMMUTABLE STRICT – inseamna ca functia nu poate modifica baza de date

 În final se poate defini tipul SQL complex:
CREATE TYPE complex (
internallength = 16,
input = complex_in,
output = complex_out,
alignment = double
);

Caracteristici obiect-relaţionale în MS SQL Server
 Începând cu versiunea SQL Server 2005, tipurile de date definite de
utilizator, procedurile stocate, funcţiile şi triggerele sunt integrate în
executivul CLR (Common Language Runtime) din platforma .NET, ceea
ce înseamnă că se pot folosi toate limbajele .NET
 Programele sursă în C++ (Managed C++), C#, J#, Visual Basic .NET se
compilează în module în limbajul MSIL (MS Intermediate Language)
 Executivul CLR este o maşină virtuală care gestionează execuţia
programelor .NET (a modulelor MSIL)
 Toate limbajele .NET respectă specificaţia de tipuri comune numită
Common Language Specification (CLS)
 CLR nu opereaza direct cu module ci cu ansambluri (assemblies)
 Un ansamblu (assembly) este o componenta software sub forma de
biblioteca DLL sau o aplicatie executabila .exe, compusa dintr-o grupare
logica de module si de resurse si este cea mai mica unitate de reutilizare,
instalare si securitate
 In functie de optiunile de compilare un assembly este compus dintr-un
unul sau mai multe fisiere

Tipuri definite de utilizator în SQL Server
 Pentru crearea tipurilor definite de utilizator se urmează paşii:
 Se creează tipul de date ca o clasă sau structură într-un limbaj .NET
 Se compilează clasa cu compilatorul limbajului respectiv şi se obţine
ansamblul corespunzător
 Se înregistrează ansamblul în SQL Server cu comanda:
CREATE ANSAMBLY
 Se creează tipul SQL care referă ansamblul înregistrat
 La deployment-ul unui proiect SQL Server în Microsoft Visual Studio se
înregistrează automat în baza de date ansamblul specificat de proiect
 De asemenea, la deployment CLR generează câte un tip definit de
utilizator pentru baza de date corespunzător oricărei clase care are
adnotarea (atributul) SqlUserDefinedType
 Pentru ca SQL Server să execute cod CLR trebuie configurat folosind
opţiunea CLR-enabled în procedura sp_configure

Concluzii – Baze de date obiect-relaționale
 SGBD-urile relationale actuale tind să devină obiect-relaţionale prin
introducerea gradată a obiectelor într-o reprezentare relaţională
 Avantajele oferite de modelul obiect-relaţional (structurare, extensibilitate,
reutilizabilitate, eficiență) sunt foarte importante pentru aplicaţii ştiinţifice,
industriale şi comerciale complexe
 Chiar daca proiectarea şi implementarea bazelor de date OR este mai
dificila decât a celor pur relaţionale, rezultatele proiectelor
obiect-relationale sunt mai structurate, mai extensibile și mai eficiente
 Bazele de date avansate (XML, spațiale, multimedia, medicale etc.)
SUNT baze de date obiect-relaționale

Baze de date obiect-relaţionale
 Oracle Documentation
 Oracle SQL Language Reference
 PL/SQL Language Reference
 Database Object-Relational Developer’s Guide

Capitolul 5 - Baze de date XML
 Limbajul XML – noţiuni introductive
 Spaţii de nume (namespaces)
 Validarea documentelor XML: DTD (Document Type Definition), XML Schema
 Limbaje pentru transformarea şi interogarea datelor XML
 XPath (XML Path)
 XSLT (eXtensible Stylesheet Language Transformation)
 XQuery (XML Query)
 Biblioteci şi interfeţe (API) de manevrare a datelor XML
 DOM (Document Object Model)
 SAX (Simple API for XML)
 Stocarea datelor XML – baze de date XML
 Oracle XML Database
 Baza de date BaseX
 Suport pentru XML in MySQL
 Suport pentru XML in PostgreSQL
 Suport pentru XML în SQL Server
Prof. Felicia Ionescu Baze de date XML 1

Limbajul XML
 Este un limbaj de marcare, definit (în anul 1996), ca şi HTML, pe baza
limbajului SGML (Standard Generalized Markup Language),
 XML este un standard cross-platform, portabil, extensibil, bazat pe text
 XML este folosit pentru:
 reprezentarea modului de structurare (ierarhică) a datelor
 schimbul de documente în Internet
 reprezentarea protocoalelor de comunicaţie
 baze de date
 prelucrarea datelor
 XML este asemănător cu HTML, dar:
 XML reprezintă modul de structurare a datelor
 HTML reprezintă modul de prezentare (afişare) a datelor
 XML permite definirea de marcaje noi, specifice aplicaţiei
 HTML conţine un set de marcaje fixe
 XML este structurat ierarhic şi bine-format (well-formed, imbricare corectă)
 HTML nu este obligatoriu bine-format

Exemplu de document XML
 Fie următorul document XML, conform XML 1.0 Recommendation
(http://www.w3.org/TR/REC-xml), compus din header şi conţinut:
 Header-ul conţine informaţii destinate unui parser sau aplicaţii privind modul
de interpretare şi manevrare a documentului
 Conţinutul (content) reprezintă datele documentului


<?xml version="1.0"?>

<book xmlns=“http://www.oreilly.com/javaxml2”
xmlns:ora="http://www.oreilly.com">
<title ora:series="Java">Java and XML</title>
<contents>

<chapter title="Introduction" number="1">
<topic name="XML Matters" />
<topic name="What's Important" />
<topic name="The Essentials" />
</chapter>

</contents>
</book>

Elemente XML
 Fiecare element XML începe cu un marcaj (tag) de deschidere şi se
încheie cu un marcaj de închidere
 Marcajul de deschidere este format din numele elementului între paranteze
ascuţite
 Marcajul de închidere este format din numele elementului precedat de “/”
între paranteze ascuţite
<contents>……</ contents>
 Un element conţine:
 Zero, unul sau mai multe atribute, specificate sub forma atribut=valoare în
marcajul de deschidere: <title ora:series="Java"> ….</title>
 Text (opţional) între marcajul de deschidere şi cel de închidere: <title…>Java
and XML</title>
 Zero, unul sau mai multe sub-elemente între marcajul de deschidere şi cel de
închidere; fiecare sub-element este, la rândul său un element care are
aceeaşi structură
 Dacă un element conţine doar atribute sau nu conţine nimic (element vid)
se pot combina cele două marcaje de deschidere şi de închidere
într-unul singur: <topic name="XML Matters" />
Validarea documentelor XML
 Elementul rădăcină (root): orice document XML are un singur element root
care are aceeaşi structură ca orice alt element şi cuprinde (imbrică) toate
celelalte elemente ale documentului:
<book…> … </book>
 Structura elementelor unui document se reprezintă printr-un arbore
 Document XML bine-format (well-formed): respectă corect structura şi
imbricarea elementelor
 Document XML valid  se verifică validitatea conform cu:
 Document DTD (Document Type Definition) – specifică modul de formatare a
datelor: ce elemente XML sunt admise în document, subelementele lor,
numărul maxim de apariţii admis, valorile admise ale atributelor etc.
 XML Schema – este recomandarea mai recentă de la W3C (WWW
Consortium) care foloseşte tot limbajul XML pentru definirea formatării
documentelor XML
 XML Schema îmbunătăţeşte modul de definire a schemei documentelor
XML faţă de DTD şi se foloseşte cu precădere în produsele nou
proiectate; DTD este un subset al XML Schema
 Un document XML care poate fi validat conform unei scheme se numeşte
document instanţă (instance document); el trebuie să respecte numele,
structura, valorile etc. elementelor specificate în schemă

Spaţii de nume XML (namespaces)
 Un namespace XML este o grupare de unul sau mai multe elemente
dintr-un document XML, asociată cu un nume URI (Uniform Resource
Identifier); pentru unicitate, se recomandă folosirea unui URL
 Fiecare element este unic (ca denumire) în namespace-ul său şi poate fi
deosebit de un alt element cu acelaşi nume, dintr-un namespace diferit
 Pentru fiecare namespace folosit într-un document se defineşte un prefix
(abreviere), care se asociază cu numele unic URL
 Numele unic (URL) este numele global al mamespace-ului
 Prefixul (abrevierea) este numele local (în acel document) al namespace-ului
 În exemplul dat, în elementul root s-au definit 2 namespace-uri prin
intermediul a două atribute ale elementului root (book):
 Un namespace implicit, asociat cu URL-ul http://www.oreilly.com/javaxml2
 Un namespace cu prefixul ora, asociat cu URL-ul http://www.oreilly.com
<book xmlns="http://www.oreilly.com/javaxml2"
xmlns:ora=“http://www.oreilly.com” >
 Elementele din namespace-ul implicit se scriu doar cu numele elem,
elementele din alte namespace-uri sunt precedate de prefixul respectiv:
<title ora:series="Java">Java and XML</title>

XML Schema şi XML Schema instance
 Specificaţiile XML definesc două namespace-uri fundamentale:
 XML Schema namespace cu URI-ul (numele global)
http://www.w3.org/2001/XMLSchema
de obicei se folosește numele local (abreviaţia, prefixul) xs sau xsd
 XML Schema Instance namespace cu URI-ul (numele global)
http://www.w3.org/2001/XMLSchema-instance
de obicei se folosește cu numele local (abreviaţia, prefixul) xsi
 Chiar dacă acestea au în comun un subset de entităţi (ca type, element,
attribute etc.), aceste namespace-uri au scopuri diferite:
 XML Schema este referit din documentele de definire ale schemelor
 XML Schema Instance este referit din documentele XML instanţă
 De exemplu, atributul schemaLocation folosit în documentul instanţă dat aparţine
namespace-ului XML Schema Instance

Definirea Schemelor XML (1)
Definirea schemelor XML este foarte complexă; vom prezenta numai aspectele de bază folosind
schema XML a documentului dat (din fişierul mySchema.xsd)
În general, în definirea schemelor XML se referă namespace-ul XML Schema (definit de W3C)


 Schema XML este un document XML valid, care poate fi parsat de orice
parser XML
 Definiţia unei scheme XML este conţinută în interiorul elementului root
numit schema din namespace-ul XMLSchema, asociat cu URL-ul
http://www.w3.org/2001/XMLSchema și notat cu prefixul xs în ex. prec.
 Atributul targetNamespace se foloseşte pentru a seta un nume URL
namespace-ului implicit al documentului schemei (care conţine elementele
definite de schemă)
targetNamespace=“http://www.oreilly.com/javaxml2”
 Namespace-ul cu prefixul ora este declarat şi importat în document
 Pentru fiecare element al schemei se definesc:
 Numele elementului: <xs:element name="book">
 Tipul de date al elementului; pentru tipurile complexe se specifică părţile
componente, eventual cu sub-elemente
 Numărul de apariţii posibile ale unui element
 Schema XML > tip (clasa); document XML > instanţă (obiect)

Definirea documentelor XML
 Completăm documentul XML ca instanţă a schemei definite mai sus:
<?xml version="1.0"?>
<book xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns=“http://www.oreilly.com/javaxml2”
xsi:schemaLocation=“http://www.oreilly.com/javaxml2 http://domain/mySchema.xsd
http://www.w3.org/2001/XMLSchema-instance http://www.w3.org/2001/XMLSchema.xsd">
<contents>
<chapter title="Introduction" number="1">
<topic name="XML Matters" /> ……..
</chapter>

</contents>
</book>
 Primul atribut al elementului root referă XML Schema Instance namespace
(definit de W3C) prin asocierea prefixului xsi cu URL-ul lui
 Al doilea atribut defineşte URL-ul namespace-ului implicit al documentului
 Deoarece URL-ul unui namespace nu specifică locaţia fişierului schemei,
se foloseşte atributul xsi:schemaLocation pentru a asocia URL-ul unui
namespace cu locaţia fişierului care conţine schema acestuia
 Valoarea acestui atribut este compusă din una sau mai multe perechi: numele
URL al namespace-ului şi locaţia fişierului care conţine schema acestuia pentru
fiecare namespace folosit în document

Transformarea şi interogarea datelor XML
 Limbaje pentru transformarea şi interogarea datelor XML:
XPath, XSLT, XQuery
 Aceste limbaje folosesc reprezentarea ca arbore a unui document XML, cu
nodurile reprezentând elemente, atribute sau text
 Limbajul XPath – adresează o parte dintr-un document XML printr-o expresie
de cale (path expresion) în reprezentarea ca arbore a documentului
 O expresie de cale este o secvenţă de locaţii separate prin “/” (în locul
operatorului “.” folosit în SQL)
De exemplu, expresia: /book/contents/chapter/topic/
va returna: <topic name="XML Matters" />
<topic name="What's Important" />
<topic name="The Essentials" />
 Atributele pot fi accesate folosind simbolul “@”
 O expresie XPath poate ignora unul sau mai multe niveluri utilizând “//”
 XPath suportă predicate (condiţii) în expresii:
/bank/account[balance>400]

Limbajul XSLT
 Un style sheet conţine opţiunile de formatare a unui document, de obicei
memorate într-un fişier separat de documentul însuşi
 XSL (eXtensible Stylesheet Language) este un limbaj care specifică modul
de prezentare a conţinutului documentelor şi de transformare dintr-un
format în altul
 XSL Transformation (XSLT)  partea din limbajul XSL care specifică
modul de transformare a documentelor dintr-un format în altul
 Un document XSLT este un document XML definit conform unui DTD sau
scheme specificate (predefinite)
 XSLT se bazează pe structuri ierarhice (arbori) în care elementele
imbricate sunt fii ai elementelor părinte
 XLST prevede un mecanism de găsire a unui pattern în document
(folosind expresii XPath) şi de aplicare a unor formatări rezultatului
 Se obţin date formatate (de exemplu, fără numele elementelor XML) care
pot fi inserate în documente HTML sau de alt tip

Limbajul XQuery
 Limbajul XQuery permite specificarea interogărilor asupra documentelor
XML prin expresii numite “expresii FLWR” după iniţialele clauzelor
interogării:
FOR <variable bindings to individual nodes (elements)>
LET <variable bindings to collections of nodes (elements)>
WHERE <qualifier conditions>
RETURN <query result specification>
 Mai jos sunt date 3 interogări XQuery pentru documente conforme cu
schema dată (în partea dreaptă)

Interfeţe (API) de manevrare a datelor XML
 Standarde de API pentru manevrarea prin program a datelor XML:
 DOM (Document Object Model)
 SAX (Simple API for XML)
 Modelul DOM tratează documentul XML ca pe un arbore compus din
noduri; o parte a documentului XML poate fi accesată navigând prin
arbore începând de la nodul rădăcină (root)
 Metode de navigare prin arbore:
getFirstChild(), getNextSibiling(),
getParentNode()
 Biblioteci DOM sunt disponobile
pentru majoritatea limbajelor uzuale
 În figura alăturată este prezentată
structura DOM a unui document XML
 Dezavantaj DOM: structura arbore
poate fi foarte mare, dificil de a fi
stocată în memorie; se fol. SAX

Interfaţa SAX
 Interfaţa SAX oferă un model bazat pe evenimente (event-driven API)
pentru parcurgerea (parsarea) documentelor XML
 În loc să copieze în memorie arborele corespunzător documentului XML
şi să transmită clientului date din acesta (ca în DOM), în SAX clientul se
înregistrează pentru a primi notificaţii atunci când parserul recunoaşte
anumite elemente din document (identificate ca evenimente)

Date structurate, semistructurate, nestructurate
 Date structurate – date memorate ca instanţele a unor tipuri definite
(structuri, scheme); formatul datelor este verificat să fie în conformitate cu
tipul specificat; tipul poate fi:
 în modelul relațional: tabele relaţionale
 în modelul obiect-orientat: clasă
 în modelul obiect-relational: tipuri de date definite de utilizator (UDT), vectori
de date (varray), tabele de obiecte, tabele relaționale
 in modelul XML: format DTD, schemă XML
 Date semistructurate – schema informaţiei este mixată cu datele
 Fiecare obiect poate avea atribute diferite, care nu sunt definite în avans
 Se mai numesc şi date care se autodescriu (self-describing data)
 Deosebire faţă de tipul structurat: nu este necesară definirea prealabilă a
structurii (tabel relaţional, tip de date definit de utilizator, schemă XML)
 De exemplu, documente XML care nu trebuie să fie validate (nu au schemă -
schema-less XML documents, cu atributul STANDALONE =‘YES’ în header-ul
documentului
 Date nestructurate – nu există informaţii referitoare la structura obiectului
 De exemplu tipurile BLOB, CLOB din Oracle reprezintă şiruri de biţi sau de
caractere, fără o structură precizată

Stocarea datelor XML
 Există mai multe posibilităţi de stocare a datelor XML:
 Stocarea în sistemul de fişiere al calculatorului gazdă, ca fişiere XML
 Are multe dezavantaje (lipsa de izolare a datelor, lipsa verificărilor de integritate
a datelor, lipsa verificărilor de securitate etc.)
 Dar, pentru aplicaţii simple, poate fi folosită; datele se parcurg folosind biblioteci
care implementează diferite interfeţe (API) pentru XML
 Stocarea în baze de date
 Stocarea în baze de date obiect-orientate, prin extinderea ac. cu clasele nec.
 Stocarea în baze de date relaţionale:
 Stocarea în tabele relaţionale ca şiruri de caractere: fiecare element fiu al rădăcinii
se reprezintă ca un tuplu (compus dintr-un şir de caractere) într-o relaţie
 Reprezentarea ca arbore: datele XML modelate ca arbore (în care fiecare nod are
un identificator - id) se reprezintă printr-o pereche de tabele:
nodes(id, type, label, value) şi child (child_id, parent_id) (interogări ineficiente)
 Stocarea în baze de date obiect-relaţionale - cea mai avansată metodă:
 Documentelor XML si elementelor definite în XML Schema li se asociază tipuri de
obiecte (UDT, type object), vectori (varray) sau tabele imbricate (nested tables)
 Aceste tipuri se folosesc ca şi coloane sau linii ale tabelelor

Baze de date XML
 Termenul de “baze de date XML” sau, mai nuanţat, “baze de date native
XML” se referă la stocarea persistentă a datelor cu urm. caracteristici:
 Respectă o structură care poate fi descrisă printr-o schemă XML (cu elemente,
subelemente, atribute etc.) astfel încât datele pot fi memorate şi regăsite
conform acestei structuri
 Suportă cel puţin un limbaj de interogare XML (ca XPath, XQuery)
 Suportă un limbaj de transformare a datelor XML (ca XSLT)
 Unele baze de date XML mai suportă şi XML:DB API (or XAPI) ca API de
acces la date, care înlocuieşte ODBC sau JDBC
 Există numeroase implementări care respectă, mai mult sau mai puţin,
caracteristicile de baze de date XML
 În bazele de date XML se pot folosi diferite modele de stocare: relaţionale,
obiect-orientate, obiect-relaţionale sau format proprietar (ca fişiere
indexate)
 Baze de date XML sunt considerate atât cele care stocheaza datele XML
folosind sistemul de fişiere al calculatorului gazdă (de ex. BaseX), cât și
cele care stocheaza datele XML în tabele obiect-relaţionale (ex. Oracle
XML DB)
Implementări de baze de date XML
Conform cu: http://en.wikipedia.org/wiki/XML_database

Baza de date BaseX
 BaseX este o bază de
date XML open-source
bazată pe sistemul de
fişiere, care oferă
posibilitatea de
interogare prin limbajul
XQuery
 Prezintă conformanţă
ridicată (99.9%) cu
recomandarea XQuery
Full Text
 Defineşte diferite
structuri de indexare
(după numele
elementelor, cale,
valoare, text)

Oracle XML Database (1)
 Oracle XML Database este inclus în Oracle Database Server și oferă
securitate, disponibilitate şi scalabilitate operaţiilor cu documente XML
 Aplicaţiile pot folosi limbajul SQL (specificaţiile SQL-2003 sau SQL-2006,
SQL-2008 care au extensii referitoare la XML) sau operatori XML pentru
prelucrarea şi generarea documentelor complexe
 Oracle XML DB permite gestionarea documentelor XML:
 Documente XML memorate în tabele folosind tipul XMLType, oferind suport
pentru XML Schema, XPath, XSLT, DOM
 Documente XML memorate în XML Repository, accesibile prin biblioteci
standard XML API şi limbajul SQL
 Oracle XML DB poate fi folosită în conjuncţie cu Oracle XML Developer's
Kits (XDK) pentru dezvoltarea aplicaţiilor care se execută în Oracle
Application Server
 Oracle XML Developer's Kits (XDK) oferă suport pentru citirea,
manipularea, transformarea documentelor XML, stocate fie în baza de
date, fie în XML Repository
Oracle XML Database (2)
 Oracle XML DB constă din:
 Tabele şi vederi care contin tipul de date XMLType, indexari (XML Index, Btree..);
accesare fol XMLType API (XML Schema, XML Transformation, SQL,Java,PL/SQL,C etc.)
 Oracle XML DB Repository – stocare orice tip de fisier, incl. fisiere XML si XML Schema;
accesare prin FTP, WebDAV

Tipul de date XMLType (1)
 Tipul de date XMLType este tipul Oracle pentru lucrul cu XML
 Metodele XMLType: constructori, metode de operare cu obiecte XMLType
 Parametrii de constructie a obiectelor XMLType:
xmlData Datele XML
schema Schema XML care poate fi folosită pentru verificarea conformităţii datelor;
Valoarea implicita NULL înseamnă document fără schema (schema-less)
validated Indică validitatea datelor, conform schemei XML date; dacă este setat (1)
înseamnă ca datele au fost deja validate și nu se mai face verificarea
wellformed Indică dacă datele sunt bine-formate; dacă este setat (1), inseamna ca
datele de intrare au fost deja verificate si nu se mai executa verificarea
CSID Identificatorul setului de caractere al datelor de intrare
 Constructorii permit crearea unei instanţe a tipului XMLType pornind de la un şir de caractere
(varchar), obiecte CLOB, BLOB sau fisier BFILE; ex:
constructor function XMLType (xmlData IN clob, schema IN varchar2 := NULL,
validated IN number := 0, wellformed IN number := 0 ) return self as result;
constructor function XMLType (xmlData IN blob, csid IN number,
schema IN varchar2 := NULL, validated IN number := 0, wellformed IN number := 0)
return self as result;
constructor function XMLType (xmlData IN bfile, csid IN number,
schema IN varchar2 := NULL, validated IN number := 0, wellformed IN number := 0)
return self as result;
Tipul de date XMLType (2)
 Metodele tipului XMLType:
extract() – extrage un subset de noduri conţinute în obiectul curent
existsNode() – verifică dacă un anumit nod există în obiectul curent
schemaValidate() – validează conţinutul obiectului conform cu schema XML
transform() – execută o transformare XSLT a conţinutului obiectului
 Tipul XMLType poate fi folosit pentru:
 Crearea unui tabel de obiecte de tipul XMLType:
CREATE TABLE mytable1 OF XMLType;
 Crearea unei coloane a unui tabel relaţional:
CREATE TABLE mytable2( key_column VARCHAR2(10) PRIMARY KEY,
xml_column XMLType);
 Ca variabile PL/SQL
 Constructorul este apelat la inserarea datelor XMLType în tabele (sau coloane)
INSERT INTO mytable2 VALUES (XMLType (bfilename('SS_OE_XMLDIR', 'purchaseOrder.xml'),
nls_charset_id('AL32UTF8')));
 Dacă nu există, dir. SS_OE_XMLDIR se creează cu com CREATE DIRECTORY:
CREATE DIRECTORY SS_OE_XMLDIR AS
‘/home/oracle/app/oracle/product/11.2.0/db_home2/demo/schema/order_entry/'; COMMIT;
GRANT READ,WRITE ON DIRECTORY SS_OE_XMLDIR TO OE; Commit;
 Userul OE trebuie sa aibă privilegiul CREATE ANY DIRECTORY
Stocarea datelor XML în Oracle XML – DB (1)
 Stocarea obiectelor de tipul XMLType:
 Stocare structurată: datele XML sunt stocate ca un set de obiecte – stocare
obiect-relaţională, cu persistenţă bazată pe obiecte (object-based persistence)
 Stocare nestructurată: datele XML sunt stocate ca obiect CLOB (text-based
persistence)
 Stocare binară: datele XML sunt stocate într-un format binar special proiectat, care
poate respecta o schema XML data (post-parse persistence)
 Stocare ca resurse (resources) în XML Repository
 Orice fel de date XML (fără schema sau cu schemă) pot fi stocate: nestructurat
(ca obiect CLOB), în format binar sau ca resurse (resources) în XML Repository
 Datele XML cu schema mai pot fi stocate și structurat (ca set de obiecte)
 Se pot mixa modelele de stocare (hybride storage)
 Indiferent de modul de stocare, Oracle XML DB ofera aceleasi functionalitati, dar
pot sa difere performantele și spațiul de memorie ocupat, în funcție de tipul și
utilizarea datelor XML
 Din punct de vedere al tipului, documentele XML pot fi:
 Centrate pe date (data-centric): documente cu organizare statica și predictibila, cu multe
sub-elemente și puțin text
 Centrate pe documente (document-centric): documente cu organizare variabila, cu puține
sub-elemente și mult text
 De tip intermediar (hibrid), intre data-centric și document-centric

 Pentru performormante cât mai bune se recomandă urmatoarele moduri de stocare
in functie de tipul documentului XML:
 Documentele data-centric cu schema - stocare structurata (object-relational)
 Documentele document-centric - stocare nestructurata (CLOB) sau în format binar
 Documentele cu formate intermediare - stocare hibrida (hybride storage)


Dualitatea SQL/XML
 Oracle XML- DB implementeaza standardul SQL-2008 – partea 14 (SQL/XML)
 Dualitatea SQL/XML inseamna ca aceleasi date (de tipul XMLType) pot fi vazute ca
linii in tabele si manipulate folosind operatii SQL sau pot fi vazute ca noduri intr-un
document XML si manipulate prin operatii XLS, XQuery, DOM
 Functiile standardului SQL/XML implementate de Oracle XML DB sunt:
 Funcții SQL/XML de generare (sau de publicare), care genereaza date XML din rezultatul
returnat de o functie SQL
 Funcții SQL/XML de interogare și accesare, care permit accesarea și interogarea
continutului XML ca parte a operatiilor (functiilor) SQL
 Functiile SQL/XML și metodele XMLType folosesc expresii XPath și XQuery pentru
a interoga documente XML și pentru a accesa nodurile din documente XML
 Expresiile XPath care operează asupra datelor XMLType sunt evaluate sau
transformate în funcție de metoda de stocare a datelor XML astfel:
 Pentru stocarea structurată Oracle XML DB rescrie expresia XPath,
transformand-o în interogare SQL echivalenta, care refera structura
obiect-relationala a datelor, generată conform schemei XML
 Pentru stocarea nestructurata se foloseste XMLIndex (dacă este prezent) sau
prin evaluare functionala, care construiese mai întâi DOM, apoi adapteaza
expresia XPath pentru acest DOM
 Pentru stocarea binara se folosește XMLIndex sau scanarea datelor binare

Date XML schema-less
 XMLType este un ADT ( Abstract Data Type) care poate fi folosit pentru:
 Crearea unui tabel de obiecte de tip XMLType:
CREATE TABLE mytable1 OF XMLType;
 Crearea unei coloane a unui tabel relaţional:
CREATE TABLE mytable2 (
key_column VARCHAR2(10) PRIMARY KEY, xml_column XMLType);
 Instructiunea CREATE TABLE fara specificarea schemei si fara specificarea
modului de stocare a datelor, stocheaza XML Data in format XML binar
schema-less
 Pentru crearea unui tabel XMLType intr-o baza de date detinuta de un utilizator
oarecare, acesta trebuie sa aiba drepturi: CREATE ANY TABLE si CREATE ANY
INDEX. Tabelul va contine o coloana OBJECT_ID care memoreaza OID-ul generat
de sistem a fiecarui obiect si pe care se defineste indexul unic al tabelului
 Constructorii XML permit crearea unei instante XMLType din diferite surse, ca
varchar2, CLOB, sau BFILE
 Constructorii accepta argumente aditionale pentru a se evita verificari ale datelor
XML, daca se stie sigur ca acestea sunt bine formate si/sau validate; in plus, pentru
BLOB si BFILE trebuie specificat setul de caractere; exemplu (care a mai fost dat):
INSERT INTO mytable2 VALUES (XMLType(bfilename('SS_OE_XMLDIR',
'purchaseOrder.xml'), nls_charset_id('AL32UTF8')));

Exemplu: tabelul PURCHASEORDER din schema OE
 Tabelul PURCHASEORDER din schema OE (din Oracle Virtual Appliance)
stocheaza documente XML în format XML binar schema-less

Un obiect XMLType din tabelul PURCHASEORDER
Atributul xsi:noNamespaceSchemaLocation s-a

introdus deoarece in schema corespunzatoare nu
s-a definit targetNamespace; daca se defineste
targetNamespace, atunci se introduce atributul
xsi:schemaLocation
Acest atribut este necesar atunci cand documentul
XML se stocheaza structurat, daca schema lui a
fost inregistrata mai inainte in Oracle XML DB

Selectarea si interogarea datelor XML
 Ca exemplu se poate folosi schema OE (order_entry) in care s-a creat tabelul
PURCHASEORDER de XMLType, in care s-au introdus mai multe documente XML
 Datele XML din tabelul PURCHASEORDER se pot interoga folosind functii
SQL/XML ca XMLExists, XMLCast, XMLTable, XMLQuery
 Exemplul de mai jos foloseste functia XMLExists pentru a selecta obiectele de tipul
XMLType in care elementul SpecialInstructions are valoarea “Courier”
SELECT OBJECT_VALUE FROM PURCHASEORDER
WHERE XMLExists('/PurchaseOrder[SpecialInstructions="Courier"]'
PASSING OBJECT_VALUE);
Rezultat: COUNT(*): 982

(din cele 10000 de linii)

Stocarea structurată a datelor XML
 Se poate face numai pentru date XML bazate pe schema XML
 Se realizeaza prin descompunerea datelor XML într-un set de obiecte SQL
(instanţe UDT - type objects) definite conform schemei XML
 Pentru aceasta, schema XML se înregistrează în Oracle XML DB prin apelul
procedurii registerSchema din package-ul DBMS_XMLSCHEMA
 La înregistrare se generează automat definiţiile de tipuri SQL (UDT) pentru fiecare
tip complex din schema XML
 Fiecare element sau atribut definit într-un tip complex devine un atribut SQL în tipul SQL
corespunzător
 Fiecare din cele 47 de tipuri scalare prevazute in recomandările XML Schema sunt
mapate într-unul din cele 19 tipuri scalare suportate de Oracle SQL
 Pentru fiecare element care conţine un element XML repetat de un număr de ori se
generează un varray
 De exemplu, in schema PurchaseOrder.xsd (din schema SCOTT – Oracle Virtual
Appliance) se defineste elementul root cu numele PURCHASEORDER de tipul
PurchaseOrderType (SCOTT/XML Schemas/http://10.10.10.100/published...
 Tipul PurchaseOrderType se defineste ca un tip complex, format dintr-o secvența
de elemente:
<xs:element name="Reference" type="ReferenceType"
<xs:element name="CostCenter" type="CostCenterType"
........................................................................................
<xs:element name="LineItems" type="LineItemsType"

Exemplu: PurchaseOrder.xsd - XML Schema
…………………………………………………………………….....

PurchaseOrder.xsd – structura arbore

Inregistrarea XML Schema în Oracle XML DB
 Pentru ca o shema XML sa poată fi folosită în Oracle XML DB, trebuie mai întâi
înregistrată folosind functia registerSchema din package-ul DBMS_XMLSCHEMA
 Argumentele procedurii stabilesc optiunile de inregistrare ale schemei:
SCHEMAURL – numele unic (URL) al schemei
SCHEMADOC – documentul surrsa al schemei, dat ca BLOB, CLOB, VARCHAR,
FILE, XMLType
CSID – setul de caractere (pentru BLOB si BFILE)
OPTIONS – opțiuni: GENTYPES, GENTABLES, LOCAL REGISTER_BINARYXML
De exemplu, inregistrarea schemei PurchaseOrder.xml (user SCOTT):
BEGIN
DBMS_XMLSCHEMA.registerSchema(
SCHEMAURL =>
'http://10.10.10.101:80/publishedContent/XML-ETL/xsd/2010/purchaseOrder.xsd'
SCHEMADOC => bfilename('XMLDIR','purchaseOrder.xsd'),
CSID => nls_charset_id('AL32UTF8'));
END;
/
 După inregistrare comanda următoare afiseaza schema înregistrată:
SELECT * FROM USER_XML_SCHEMAS;
 Se afiseaza (pentru user SCOTT): SCHEMA_URL:
http://10.10.10.101:80/publishedContent/XML-ETL/xsd/2010/purchaseOrder.xsd

Adnotarea schemelor XML
 W3C XML Schema Recommendation defineşte un mecanism de adnotare a
schemelor care permite introducerea de informaţii speciale
 Oracle XML DB foloseşte adnotarea schemelor pentru maparea (corespondenţa)
elementelor schemei XML cu elementele SQL astfel:
 Specificarea tabelelor în care se memorează datele XML
 Suprascrierea mapării implicite dintre elementele XML şi elementele SQL
 Stocarea colecţiilor de date din XMLType:
 varray într-un tabel: fiecare element al colecţiei este mapat cu un obiect SQL, iar colecţia
de astfel de obiecte este memorată ca un set de linii într-un tabel numit tabel ordonat
(OCL - Ordered Collection Table); în mod implicit toate colecţiile se memorează ca OCT;
aceasta corespunde adnotării implicite a schemei XML xdb:storeVarrayAsTable = "true"
 varray într-un LOB: fiecare element este mapat cu un obiect SQL, colecţia este serializată
ca un varray si memorată ca o coloana de tip LOB; adnotarea este
xdb:storeVarrayAsTable = "false".
 Pentru adnotarea unei scheme se declară namespace-ul
xmlns:xdb="http://xmlns.oracle.com/xdb"
 În exemplul următor se văd o parte din adnotarile folosite pentru a crea tipuri
UDT-SQL cu nume diferite de numele elementelor XML din schema:
<xs:complexType name="PurchaseOrderType" xdb:maintainDOM="false"
xdb:SQLType="PurchaseOrderType1230_T" xdb:SQLSchema="SCOTT">

Exemplu - Schema PurchaseOrder adnotată

Generarea tipurilor SQL de mapare a elem. XML
 În cursul înregistrării schemei se creează:
 Tipurile de date UDT corespunzătoare descrierii din schema XML; implicit numele
tipurilor SQL sunt formate din numele elementului XML urmat de T; prin adnotarea
schemei, aceste nume se pot schimba; de ex. implicit elem. LineItem ar fi generat tipul
SQL (UDT) LineItem_T; prin adnotare s-a specificat numele LineItemType_1227_T
 Câte un tabel corespunzător fiecărui element global al schemei (dacă argumentul
GENTABLES din apelul procedurii DBMS_XMLSCHEMA.registerSchema este TRUE);
tabelele se pot crea si manual (dacă parametrul GENTABLE este FALSE)
 Exemplu: la înregistrarea schemei XML PurchaseOrder.xsd (adnotata) in baza de
date SCOTT se creează tipurile UDT:

Crearea datelor XMLType bazate pe XML Schema
 Pentru crearea tabelelor și coloanelor XMLType, trebuie specificata schema
înregistrată în instrucțiunea CREATE TABLE:
CREATE TABLE purchaseorder OF XMLType
XMLSCHEMA ”http://10.10.10.101:80/publishedContent/XML-ETL/xsd/2010/purchaseOrder.xsd”
ELEMENT "PurchaseOrder";
 Se creeaza un tabel (PURCHASEORDER) in care datele de tipul XMLType
trebuie sa respecte schema definita cu URL-ul dat, avand ca element root
PurchaseOrder
 Modul implicit de stocare a datelor XML este obiect-relational (ca set de obiecte
de tipurile create la inregistarea schemei)
 Se poate modifica acest mod la inregistrarea schemei sau la crearea unui tabel de
XMLType (prin clauza STORE AS cu una din valorile BINARY_XML, CLOB )
 Pentru datele XML stocate structurat (obiect-relational) exista mai multe interfete
de prelucrare in PL/SQL:
 PL/SQL DOM API for XMLType (DBMS_XMLDOM)
 PL/SQL Parser API for XMLType (DBMS_XMLPARSER)
 PL/SQL XSLT Processor for XMLType (DBMS_XSLPROCESSOR)
 PL/SQL Translation API for XMLType (DBMS_XMLTRANSLATIONS)

Generarea tabelelor XMLType bazate pe XML Schema

Suport pentru XML în MySQL
 Începând cu versiunea 5.1.5 MySQL oferă suport pentru doc. XML:
 Formatarea datelor de ieşire în format XML
 Pentru comanda mysqldump, cu opţiunea --xml
 Funcţii de prelucrare bazate pe limbajul Xpath:
 ExtractValue() – extrage o valoare dintr-un şir de caractere in format XML
folosind expresii Xpath
 UpdateXML() – actualizează un şir XML
 Exemplu: proc. stocată extractXML(); se apelează cu call extractXML:
mysql> call extractXML;

Suport pentru XML în PostgreSQL
 PostgreSQL 8.4 oferă suport pentru date XML:
 Tipul de date predefinit xml – poate stoca documente XML bine-formate;
 Funcţii pentru variabile de tip XML
 Maparea documentelor XML în tabele relaţionale
 Funcţii pentru variabile de tip XML:
 xmlparse – transformă un şir de caractere într-o valoare (variabilă) de tip xml
XMLPARSE ( { DOCUMENT | CONTENT } value)
XMLPARSE (DOCUMENT ’<?xml version="1.0"?
><book><title>Manual</title><chapter>...</chapter></book>’
XMLPARSE (CONTENT ’abc<foo>bar</foo><bar>foo</bar>’)
 xmlserialize – transformă o variabilă xml într-un şir de caractere (type = char,
varchar, text)
XMLSERIALIZE ( { DOCUMENT | CONTENT } value AS type)
 xmlconcat – concatenează mai multe variabile xml într-una singură;
 xmlelement – generează un element XML cu nume, atribute şi conţinut dat
SELECT xmlelement (name foo, xmlattributes(’xyz’ as bar));
-----------------
<foo bar="xyz"/>
 xpath – evaluează o expresie XPath şi returnează elementul coresp; şi altele

Suportul pentru XML în Microsoft SQL Server
 Începând cu SQL Server 2008, tipul de date xml este tip predefinit şi
permite stocarea documentelor sau a fragmentelor XML în baza de date
 Un fragment SQL este o instanţă XML fără un element root
 Datele XML asociate cu o schemă XML se numesc “tipizate”
 Sunt definite metode asociate tipului xml
 Tipul xml se poate folosi pentru:
 Variabile: DECLARE @x xml
 Coloane în tabele: CREATE TABLE T1(Col1 int primary key, Col2 xml)
 Tip pentru parametri şi valori returnate de funcţii:
CREATE PROCEDURE SampleProc(@XmlDoc xml) AS ...
 Metodele tipului xml se folosesc pentru interogarea datelor xml stocate
în variabile sau în coloane ale tabelelor
 query ('XQuery') – ‘XQuery’ este o expresie care caută noduri XML
(elemente, atribute) într-o instanţă XML
 value (XQuery, SQLType) – returnează rezultatul în format tip SQL, şi altele

Baze de date XML
 Brett McLaughlin, “Java & XML”, 2th Edition, O’Reilly, 2001
 Oracle 11g Documentation
 Oracle XML DB Developer's Guide – 11gR2 - E23094
 Oracle XML Developer's Kit Programmer's Guide

Capitolul 6 - Baze de date spatiale
 Modelarea datelor spațiale: obiecte spațiale, algebra spațială
 Integrarea datelor spațiale în baze de date și limbaje de interogare
 Sisteme GIS
 Date spaţiale în sistemul Oracle – Oracle Spatial
 Tipuri de date spatiale
 Interogări spatiale
 Indexarea datelor spatiale
 Date spatiale în sistemul MySQL
 Date spaţiale în sistemul PostgreSQL
 Date spaţiale în sistemul SQL Server 2008
Prof. Felicia Ionescu Baze de date spatiale 1

Date spațiale
 Date spațiale: date care se referă la reprezentarea în spațiu a
obiectelor:
 Reprezentarea obiectelor 3D (în medicină, arhitectură, CAD-CAM etc.)
 Reprezentarea spațiului geografic
 Reprezentare layout VLSI etc.
 Sistem de baze de date spațiale  sistem de baze de date care:
 Oferă suport pentru tipuri de date spațiale (POINT, LINE, REGION etc.)
 Permite interogarea datelor spațiale
 Permite indexarea spațială
 Modelarea obiectelor în plan și în spațiu – puncte, linii, regiuni

Integrarea datelor spațiale în limbaje de interogare
 Pentru integrare sunt necesare:
 Specificarea obiectelor spațiale ca valori (constante sau nu) în interogări
 Specificarea operațiilor fundamentale de algebră spațială:
 Selecție spațială – selectează obiectele care îndeplinesc anumite condiții de
poziționare în spațiu
 Funcții spațiale – calculează un obiect spațial prin intersecții, extensii etc. a altor
obiecte spațiale
 Joncțiuni spațiale – combină informații despre obiecte spațiale
 Operații cu mulțimi de obiecte spațiale (suprapunerea partițiilor, fuziunea partițiilor,
diagrame Voronoi etc.)
 Specificarea modului de prezentare a rezultatului
 Problema care trebuie rezolvată: implementarea algebrei spațiale astfel
încât să fie integrată cu sistemul de interogare al bazei de date:
 Reprezentarea tipurilor algebrei spațiale
 Implementarea algoritmilor operațiilor algebrei spațiale
 Soluționarea  abordare obiect-relațională
Domenii de utilizare a datelor spațiale
 Cele mai utilizate aplicații GIS (Geographical Information Systems)

Evolutia aplicatiilor GIS
Trecut Prezent
Aplicatie Aplicatie
Aplicatie
GIS
Proprietary Middleware Open Server de
API Spatial API harta
Fisiere proprii
Baza de
SGBD date
traditional spatiala
Middleware Platforma
Standalone
propriu Internet

Date spațiale în sistemul Oracle – Oracle Spatial
 Începând cu versiunea 10g, Oracle Spatial este conform cu specificațiile Open
Geospatial Consortium (OGC) – Simple Features Specification 1.1.1 (Document
99-049) și permite:
 Modelarea vectorială a datelor
 Modelarea rastru a datelor spațiale
 Modelarea topologică a datelor spațiale
 Oracle Spatial folosește modelul obiect-relațional de date:
 Datele spațiale se pot reprezenta prin tipuri și ierarhii de tipuri
 Datele spațiale pot fi utilizate ca tabele de obiecte sau ca și coloane în tabele
 Oracle Spatial folosește:
 O schemă SQL (MDSYS) care conține tipuri de date geometrice modelate vectorial (și
care nu trebuie să fie modificată de useri)
 Mecanisme de indexare spațială a obiectelor spațiale
 Operatori, funcții și proceduri pentru efectuarea interogărilor spațiale
 Dimensionalitatea datelor spațiale:
 Bidimensionale (2D)
 Tridimensionale (3D)
 Cu patru dimensiuni (4D)

Modelarea vectorială a datelor în Oracle Spatial
 Modelul de date este o ierarhie compusă din elemente (elements),
geometrii (geometries) și niveluri (layouts)
 Date spațiale 2D – coordonate reprezentate ca perechi de valori (X,Y)
 Point – reprezentat printr-o coordonată (1 punct)
 Line string – fiecare segment reprezentat prin 2 puncte
 Poligon – reprezentat printr-o listă ordonată de coordonate; nu se admite
autointersecția liniei poligonale

Reprezentarea datelor spațiale vectoriale în Oracle
 Geometry: colecție de elemente – de ex. poate reprezenta o clădire
 Layout: colecție de geometrii, având anumite atribute comune – de ex.
un layout într-o aplicație GIS poate reprezenta rețeaua de drumuri
 Sisteme de coordonate – dupa tipul reperului:
 Sistemul de coordonate Cartesian – definit prin origine și 2 (sau 3) axe de
coordonate perpendiculare
 Sisteme de coordonate unghiulare
 Sisteme de coordonate folosite în reprezentarea datelor spatiale:
 Non-georeferențiale - nu sunt corelate cu reprezentare Pamântului
 Coordonate locale – sistem de coordonate Cartesian non-georeferențial
 Georeferențiale - se referă la o anumită reprezentare a Pamântului
 Sistemul de coordonate geodetic (sau geografic) – coordonate unghiulare
(latitudine, longitudine), referitoare la coordonatele sferice polare pentru
reprezentarea fata de o anumită poziție pe globul pământesc
 Sistem de coordonate de proiecție – rezultate printr-o proiecție a suprafeței
pământului pe un plan

Indexuri spațiale în Oracle
 În Oracle indexarea datelor spa țiale folose ște indexuri R-tree pe 2, 3, sau 4 dim.
 R-tree (R de la Rectangle) este o extindere a arborilor B-tree, in care fiecare nod intern
(non-leaf) conține un numar variabil de noduri fii, cuprins intre doua limite predefinite
 Un R-tree este o structură de date care împarte ierarhic spa țiul în zone de acoperire
minime (MBR – Minimum Bounding Rectangle, în plan, respectiv MBB – Minimum
Bounding Box, în spațiul tridimensional) imbricate (nested) și posibil cu suprapuneri
(overlapping)
 Fiecare nod intern (non-leaf) are un număr variabil de elemente si fiecare element
memorează două informații: o referin ță către un nod fiu și MBR-ul acestuia

Indexuri R-tree în Oracle
 Algoritmii de căutare în baza de date dupa
poziția unui element spatial foloseste
indexul R-tree
 Pentru fiecare nod se folosește MBR-ul
(sau MBB-ul) fiecarui fiu pentru a decide
dacă să caute în interiorul acelui nod fiu
 În felul acesta se exceptează de la căutare
un număr mare de noduri (se caută în mai
puține noduri)
 Algoritmul de inserare în tabel a unui obiect
spațial folosește MBR-ul (sau MBB-ul)
pentru a plasa acel obiect în cel mai
apropiat nod (ca poziție în spațiu)
 Cel mai apropiat nod este nodul al cărui
MBR (sau MBB) necesită extinderea
minimă pentru a acoperi MBR-ul (sau
MBB-ul) obiectului nou introdus Index R-tree 3D

Exemplu: indexarea datelor spațiale
 Fig (a) - MBR (Minimum Bounding Rectangle) - aproximează o geometrie
 Fig (b) – Index R-tree: o ierarhie de MBR-uri ale geometriilor dintr-un nivel dat
(b)
(a)
 În fig. b, geometriile sunt numerotate de la 1 la 9

 a, b, c, d sunt noduri frunză în arbore şi conţin MBR-urile geometriilor, împreună cu
pointeri la geometriile conţinute
 A conţine MBR-ul pentru a şi b, B conţine MBR-ul pentru c şi d
 Root conţine MBR-ul pentru A şi B şi, deci al întregii regiuni
 Exemplu de utilizarea a indexului: operația de căutare a tututor intersectiilor dintre
poligonul 1 (dat ca geometrie și MBR) cu celelalte geometrii din spa țiu
 MBR(1) nu intersectează MBR(B), deci nu se cauta în nodul (B), dar intersectează
MBR(A), deci se continua căutarea cu fii lui (A)
 MBR(1) nu intersectează MBR(b), deci nu se cauta în nodul (b), dar intersectează
MBR(a), deci se calculează intersecția cu geometriile din nodul (a): geometria (2)
Tipurile de date Oracle Spatial (1)
 Oracle Spatial defineşte o geometrie ca un obiect de tipul:
CREATE TYPE sdo_geometry AS OBJECT (
SDO_GTYPE NUMBER, -- defineşte tipul geometriei
SDO_SRID NUMBER, -- Sistem Reference IDentifier -
-- sistemul de coordonate al geometriei
SDO_POINT SDO_POINT_TYPE,
SDO_ELEM_INFO SDO_ELEM_INFO_ARRAY,
SDO_ORDINATES SDO_ORDINATE_ARRAY);
 Dacă SDO_ELEM_INFO şi SDO_ORDINATES sunt ambele null, atunci
geometria defineşte punctul SDO_POINT; altfel SDO_POINT este ignorat
 Tipurile folosite sunt definite astfel:
CREATE TYPE SDO_POINT_TYPE AS OBJECT (
X NUMBER,
Y NUMBER,
Z NUMBER);
CREATE TYPE SDO_ELEM_INFO_ARRAY AS VARRAY (1048576) of NUMBER;
CREATE TYPE SDO_ORDINATE_ARRAY AS VARRAY (1048576) of NUMBER;

Tipurile de date Oracle Spatial (2)
 SDO_GTYPE
conţine 4 digiţi în
format DLTT, unde:
 D - numărul de
dimensiuni (2,3,4)
 L - măsuri lineare
(- de detaliat)
 TT – tipul
geometriei; actual
de la 00 la 09;
rezervat 10-99
pentru viitor

Metodele tipului SDO_GEOMETRY

Constructorii tipului de date SDO_GEOMETRY
 Obiecte SDO_GEOMETRY se pot construi:
 Definind valori ale fiecărui atribut al tipului SDO_GEOMETRY:
SDO_GEOMETRY (
type SDO_GTYPE,
srid SDO_SRID,
point SDO_POINT,
elem_info_array SDO_ELEM_INFO_ARRAY,
ordinate_array SDO_ORDINATE_ARRAY
);
 Dintr-un șir WKT (well-known text) conținut în varchar2 sau CLOB:
SDO_GEOMETRY(wkt CLOB, srid NUMBER DEFAULT NULL);
SDO_GEOMETRY(wkt VARCHAR2, srid NUMBER DEFAULT NULL);
 Dintr-un obiect WKB (well-known binary) în format BLOB:
SDO_GEOMETRY(wkb BLOB, srid NUMBER DEFAULT NULL);

Exemplu: crearea şi interogarea datelor spaţiale
 Exemplu:
 Se creează tabelul COLA_MARKETS
care conţine o coloana cu date spaţiale
 Se inserează linii în tabel pentru
obiectele cola_a, cola_b, cola_c,
cola_d
 Se insereaza metadata pentru datele
spatiale create
 Se execută diferite interogări
 Pentru exerciţiu se poate folosi
schema MDDATA, al cărui user are
privilegiile necesare de a executa
operaţiile dorite sau userul curent
 Deblocare user MDDATA şi setarea
unei noi parole:
alter user MDDATA ACCOUNT UNLOCK;
alter user MDDATA IDENTIFIED BY “passwd”;

Exemplu: crearea unui tabel cu date spațiale
 Crearea tabelului:
CREATE TABLE cola_markets (
mkt_id NUMBER PRIMARY KEY,
name VARCHAR2(32),
shape SDO_GEOMETRY);
 Inserarea geometriilor:
INSERT INTO cola_markets VALUES( 1, 'cola_a',
SDO_GEOMETRY( 2003, -- two-dimensional polygon
NULL, -- SRID = NULL (local)
NULL, -- SDO_POINT = NULL
SDO_ELEM_INFO_ARRAY(1,1003,3), -- one rectangle (1003 = exterior)
SDO_ORDINATE_ARRAY(1,1, 5,7) ) -- only 2 points needed to
-- define rectangle (lower left and upper right)
-- with Cartesian-coordinate data
);
INSERT INTO cola_markets VALUES( 2, 'cola_b',
SDO_GEOMETRY(2003, -- two-dimensional polygon
NULL, NULL,
SDO_ELEM_INFO_ARRAY (1,1003,1), -- one polygon (exterior polygon ring)
SDO_ORDINATE_ARRAY (5,1, 8,1, 8,6, 5,7, 5,1) )
);

Exemplu: inserarea datelor spatiale în tabel
 Inserarea geometriilor:
INSERT INTO cola_markets VALUES( 3, 'cola_c',
NULL, NULL,
SDO_ELEM_INFO_ARRAY(1,1003,1), -- one polygon (exterior polygon ring)
SDO_ORDINATE_ARRAY(3,3, 6,3, 6,5, 4,5, 3,3) )
);
INSERT INTO cola_markets VALUES( 4, 'cola_d',
NULL, NULL,
SDO_ELEM_INFO_ARRAY(1,1003,4), -- one circle
SDO_ORDINATE_ARRAY(8,7, 10,9, 8,11) )
);
 Actualizare metadata (detaliere metadata pag. 24):
INSERT INTO USER_SDO_GEOM_METADATA
(TABLE_NAME, COLUMN_NAME, DIMINFO, SRID)
VALUES ('cola_markets', 'shape',
SDO_DIM_ARRAY( -- 20X20 grid
SDO_DIM_ELEMENT('X', 0, 20, 0.005),
SDO_DIM_ELEMENT('Y', 0, 20, 0.005) ),
NULL ); --SRID

Exemplu: crearea unui poligon cu o gaură
 Se definesc 2 contururi, cel exterior și apoi cel interior (al găurii)
INSERT INTO cola_markets VALUES( 10, 'polygon_with_hole',
SDO_GEOMETRY( 2003, -- polygon 2D
NULL,
NULL,
SDO_ELEM_INFO_ARRAY(1,1003,1, 19, 2003,1),
SDO_ORDINATE_ARRAY (2,4, 4,3, 10,3, 13,5, 13,9, 11,13, 5,13, 2,11, 2,4,
7,5, 7,10, 10,10, 10,5, 7,5) )
);
 SDO_ELEM_INFO_ARRAY conține atâtea

elemente câte elemente spatiale există în
geometria respectivă și fiecare element
conține 3 parametri:
 Primul parametru: poziția în
SDO_ORDINATE_ARRAY a primului vârf al
conturului (numerele 1, respectiv 19)
 Al doilea parametru: tipul conturului (1003 –
contur exterior, 2003 – contur interior)
 Al treilea parametru: tipul elementului (1- linear,
3 - rectangle, 4 - circular)

Exemplu: interogări spaţiale (1)
 Executarea unor interogări spaţiale:
-- Returneaza intersecția a doua geometrii
SELECT SDO_GEOM.SDO_INTERSECTION(c_a.shape, c_c.shape, 0.005)
FROM cola_markets c_a, cola_markets c_c
WHERE c_a.name = 'cola_a' AND c_c.name = 'cola_c';
-- Doua geometrii date au vreo interactiune spatiala (intersectie)?

SELECT SDO_GEOM.RELATE(c_b.shape, 'anyinteract', c_d.shape, 0.005)
FROM cola_markets c_b, cola_markets c_d
WHERE c_b.name = 'cola_b' AND c_d.name = 'cola_d';
-- Raspunsul este: FALSE

Exemplu: interogări spațiale (2)
-- Returneaza ariile tuturor geometriilor din
tabelul cola_markets:
SELECT name,
SDO_GEOM.SDO_AREA(shape, 0.005)
FROM cola_markets;
-- Returneaza distanța dintre două geometrii:

SELECT SDO_GEOM.SDO_DISTANCE(c_b.shape,
c_d.shape, 0.005)
FROM cola_markets c_b, cola_markets c_d
WHERE c_b.name = 'cola_b'
AND c_d.name = 'cola_d';
-- Returneaza aria geometriei cola_a:.

SELECT c.name, SDO_GEOM.SDO_AREA (c.shape,
0.005) FROM cola_markets c
WHERE c.name = 'cola_a';

Tipuri geometrice 3D în Oracle Spatial

Exemplu: tabel care conține poligoane 3D
create table polygons3d(id number, geometry sdo_geometry);
-- Simple Polygon -- All points have to be on the same plane.
insert into polygons3d values(1, SDO_Geometry (3003, NULL, NULL ,
SDO_Elem_Info_Array(1,1003,1), SDO_Ordinate_Array(0.5,0.0,0.0,
0.5,1.0,0.0,
0.0,1.0,1.0,
0.0,0.0,1.0,
0.5,0.0,0.0
)));
insert into polygons3d values(2, SDO_Geometry (3007, NULL, NULL ,
SDO_Elem_Info_Array(1,1003,1,16,1003,1), SDO_Ordinate_Array(6.0,6.0,6.0,
5.0,6.0,10.0,
3.0,4.0,8.0,
4.0,4.0,4.0,
6.0,6.0,6.0,
0.5,0.0,0.0,
0.5,1.0,0.0,
0.0,1.0,1.0,
0.0,0.0,1.0,
0.5,0.0,0.0
)));

Metadata geometrice în Oracle Spatial (1)
 Metadata reprezintă descrierea datelor (geometrice în acest caz)
 Fiecare user al unei scheme Oracle Spatial are două vederi care con țin
metadata referitoare la toate tipurile geometrice (ALL) sau create (USER)
 ALL_SDO_GEOM_METADATA - metadata ref. la toate tabelele spațiale;
 USER_SDO_GEOM_METADATA - ref. la tabele spațiale create; are atribute:
TABLE_NAME VARCHAR2(32), - nume tabel
COLUMN_NAME VARCHAR2(32), - nume coloana spațială în tabelul dat
DIMINFO SDO_DIM_ARRAY,
SRID NUMBER
Unde:
Coloana DIMINFO este un varray (SDO_DIM_ARRAY) de lungime egală cu
dimensionalitatea spațiului (1D, 2D, 3D, 4D), de obiecte SDO_DIM_ELEMENT;
tipul SDO_DIM_ARRAY este definit astfel:
Create Type SDO_DIM_ARRAY as VARRAY(4) of SDO_DIM_ELEMENT;
Tipul SDO_DIM_ELEMENT este definit astfel:
Create Type SDO_DIM_ELEMENT as OBJECT (
SDO_DIMNAME VARCHAR2(64), -- numele dimensiunii: X, Y, Z, W
SDO_LB NUMBER, SDO_UB NUMBER, -- limitele dimensiunii în grilă
SDO_TOLERANCE NUMBER); -- toleranța
SRID – Spatial Reference Identifier; identificatorul sistemului de coord al spa țiului:
null dacă nu este precizat sau se specifică prin identificatori și mai multe atribute
Modelul de date rastru în Oracle Spatial (1)
 Componenta GeoRaster permite memorarea, indexarea, interogarea
datelor reprezentate ca valori într-o grilă spațială (rastru), folosind
modelul DEM (Digital Elevation Model)
 GeoRaster folosește mașina JVM incorporată și Oracle XML DB
 Datele rastru sunt achiziționate prin:
 Detectoare la distanță (remote sensing)
 Fotogrametrie
 Sistemele GIS (inclusiv Oracle GIS) folosesc atât reprezentarea
vectorială cât și reprezentarea rastru a scoarței terestre
 Datele rastru conțin o parte sau toate elementele următoare:
 Pixeli (pixels) sau celule (cells)
 Domeniul spatial (footprint)
 Informații spațiale, temporare sau de bandă
 Atribute ale celulelor
 Metadata
 Date de prelucrare și suport pentru hartă

Modelul de date rastru în Oracle Spatial (2)
 Modelul rastru este un model pe multiple niveluri (multi-layered)
 Fiecare nivel este reprezentat printr-o banda, care este o dimensiune fizică a
rastrului multidimensional si constă dintr-o matrice bidimemsională de celule
 Benzile sunt numerotate de la o la n-1, unde n este nivelul maxim, iar
nivelurile de la 1 la n
 Fiecare nivel este descris prin metadata XML
 Un obiect GeoRaster poate fi reprezentat prin mai multe benzi, deci pe
mai multe niveluri logice
 De exemplu, undele electromagnetice de la un senzor la distanță sunt grupate
în canale, care sunt mapate în benzi, iar benzile sunt asociate cu nivelurile
 În aplicațiile rastru GIS, un set de date poate conține mai multe niveluri,
fiecare nivel avand o anumita temă (theme); exemple de teme: densitatea
populatiei, nivelul veniturilor, utilizarea terenurilor etc.

Tipul de date SDO_GEORASTER
 Tipul de date rastru este definit astfel:
CREATE TYPE SDO_GEORASTER AS OBJECT (
rasterType NUMBER,
spatialExtent SDO_GEOMETRY,
rasterDataTable VARCHAR2(32),
rasterID NUMBER,
metadata XMLType);
 Semnificația atributelor:
 rasterType: de forma [d][b][t][gt], unde
 d=2 (versiunea curentă),
 b: informații despre numărul de benzi
 t: rezervat pentru viitor
 gt = 01 (restul valorilor rezervate pentru dezvoltări ulterioare
 spatialExtent – un model de obiect geometric
 rasterDataTable – tabel de obiecte SDO_GEORASTER
 rasterID – identificator obiect SDO_GEORASTER
 metadata – descrise în GeoRaster XML schema

Modelarea topologică a datelor în Oracle Spatial
 Se definesc muchii, fețe și obiecte prin definirea legăturilor topologice
între nodurile (puncte în spațiu) unei mulțime date

Tipuri de date topologice în Oracle Spatial
 Tipul SDO_TOPO_GEOMETRY este definit astfel:
CREATE TYPE sdo_topo_geometry AS OBJECT (
tg_type NUMBER,
tg_id NUMBER,
tg_layer_id NUMBER,
topology_id NUMBER);
 Se pot crea tabele de obiecte de acest tip:

CREATE TABLE land_parcels ( -- Land parcels (selected faces)
feature_name VARCHAR2(30) PRIMARY KEY,
feature SDO_TOPO_GEOMETRY);

Date spațiale în MySQL (1)
 Extensiile spațiale ale MySQL 5.1 pemit generarea, stocarea și analiza
datelor spațiale, prin impementarea unui subset al recomandărilor
OpenGIS - Simple Features Specifications for SQL (publicate de OGC
-The Open Geospatial Consortium )
 MySQL definește câteva tipurile de date geometrice 2D care
corespund claselor OpenGIS:
 GEOMETRY
 POINT
 LINESTRING
 POLYGON
 MULTIPOINT
 MULTILINESTRING
 MULTYPOLYGON
 GEOMETRYCOLLECTION

 Extensiile spațiale ale MySQL 5.1 pemit generarea, stocarea și analiza
datelor spațiale, prin impementarea unui subset al recomandărilor
OpenGIS - Simple Features Specifications for SQL (publicate de OGC
-The Open Geospatial Consortium )
 MySQL definește câteva tipurile de date geometrice 2D care corespund
claselor OpenGIS:
 GEOMETRY
 POINT
 LINESTRING
 POLYGON
 MULTIPOINT
 MULTILINESTRING
 MULTYPOLYGON
 GEOMETRYCOLLECTION

 În MySQL se pot crea tabele care au coloane cu date de tip geometric:
CREATE TABLE geom (id int PRIMARY KEY, g GEOMETRY);
 În astfel de tabele se pot insera date geometrice:
INSERT INTO geom VALUES (GeomFromText('POINT(1 1)'));
SET @g = 'POINT(1 1)'; -- variabila locala
INSERT INTO geom VALUES (GeomFromText(@g));
 Indexuri spațiale se pot defini numai pentru modul de memorare
MyISAM a tabelelor (nu și pentru INODB)
 Prelucrarea informațiilor spațiale:
 Funcții care fac conversii între diferite formate geometrice
 Funcții de calcul a diferitelor proprietăți ale formelor geometrice
 Funcții care descriu relațiile dintre două geometrii
 Funcții de generare a unor noi geometrii din alte geometrii date

Date spațiale în PostgreSQL
 În PostgreSQL 8.4 sunt definite tipuri geometrice 2D:
 De asemenea sunt definiți operatori și funcții pentru tipurile geometrice:

 Scalare
 Translație
 Rotație
 Intersecții

Date spaţiale în SQL Server 2008
 SQL Server suportă două tipuri de date spațiale, implementate ca tipuri
CLR (Common Language Runtime):
 Tipuri geometrice - tipuri planare, definite conform specificațiilor Open
Geospatial Consortium (OGC) - Simple Features for SQL Specification 1.1.0
 Tipuri geografice (geodetice) – tipuri de date reprezentate în coordonate
sferice (longitudine, latitudine)
 Ierarhia de tipuri: cele albastre sunt instantiabile, celelalte sunt abstracte
 Indexuri spatiale – de tipul B-Tree

Exemplu – tipuri de date spațiale în SQL server
 Tipul POLYGON poate reprezenta:
 Poligoane simple, cu un singur
contur (conturul exterior) (1)
 Poligoane cu găuri, care au un
contur exterior și unul sau mai multe
contururi interioare (2), (3)
 Exemplu: crearea unui poligon cu o gaură și cu SRID = 10
DECLARE @g geometry; (SRID – Spatial Reference Identifier)
SET @g = geometry::STPolyFromText('POLYGON((0 0, 0 3, 3 3, 3 0, 0 0),
(1 1, 1 2, 2 1, 1 1))', 10);
 Exemplu: crearea unui tabel cu o coloana de identificare și o coloana de
date de tip (abstract) geometry. La inserare, în coloana tipului geometry
se intanțiază prin obiecte de subtipuri ale acestuia; ex. in Transact/SQL
CREATE TABLE SpatialTable ( id int IDENTITY (1,1), -- Primary KEY
GeomCol1 geometry );
GO
INSERT INTO SpatialTable (GeomCol1)
VALUES (geometry::STGeomFromText('LINESTRING (100 100, 20 180, 180 180)', 0));
INSERT INTO SpatialTable (GeomCol1)
VALUES (geometry::STGeomFromText('POLYGON ((0 0, 150 0, 150 150, 0 150, 0 0))', 0));
GO
Baze de date spațiale
 R.H. Güting, “An Introduction to Spatial Database Systems”, Praktische
Informatik IV, FernUniversität Hagen, D-58084 Hagen, Germany
 Felicia Ionescu, “Grafica în realitatea virtuală”, Editura Tehnica,
București, 2000
 Oracle Documentation (11g, 12c)
 Oracle Spatial Developer's Guide
 Oracle Spatial GeoRaster Developer's Guide
 Oracle Spatial Topology and Network Data Models Developer's Guide

Capitolul 7 - Baze de date multimedia
 Date şi aplicaţii multimedia
 Date multimedia şi metadate
 Arhitectura bazelor de date multimedia
 Evoluţia bazelor de date multimedia
 Oracle Multimedia
 Modelul de memorare a obiectelor Oracle Multimedia
 Tipuri de date Oracle Multimedia: ORDAudio, ORDImage, ORDVideo,
ORDDoc
 Aplicaţii Oracle Multimedia
 Baza de date Oracle Multimedia
 Serverul de aplicaţii Oracle
 Biblioteca Oracle Multimedia Java classes
 Standardul DICOM – Digital Imaging and Communications in Medicine
 Standardele de aplicaţii multimedia MPEG-7 şi MPEG-21
 Suport multimedia în alte SGBD-uri (MySQL, PostgreSQL, SQL Server)
Prof. Felicia Ionescu Baze de date multimedia 1

Multimedia – la confluenţa multor domenii

Date multimedia
 Bazele de date multimedia permit utilizatorilor să stocheze şi să
interogheze diferite tipuri de informaţii multimedia:
 Texte - pot fi formatate sau neformatate; textele formatate respectă diferite
standarde ca SGML (cu variante HTML, XML)
 Grafice – desene sau ilustraţii codate într-un standard descriptiv (PICT, VRML
etc.)
 Imagini – desene, fotografii etc., codate într-un format standard: bitmap,
JPEG, MPEG, TARGA etc.; în JPEG şi MPEG imaginile sunt comprimate
 Animaţie – secvenţe temporale de grafice sau imagini
 Video – un set de imagini care se succed în timp la o rată specificată (de
exemplu, 30 cadre/sec)
 Audio – sunete digitizate şi memorate ca şiruri de biţi
 Cel mai frecvent tip de interogare este de a găsi o sursă multimedia care
conţine anumite obiecte sau trăsături de interes
 Astfel de interogări se mai numesc şi regăsirea informaţiei după conţinut
(Content-Based Information Retrieval – CBIR sau CBR)
Aplicaţii multimedia
 Datele multimedia sunt folosite în tipuri de aplicaţii ca:
 Depozite de informaţii – ca imagini satelitare, imagini medicale, proiecte
inginereşti etc.
 Prezentări – prin livrarea datelor multimedia cu anumite constângeri de timp
 Aplicaţii colaborative – realizarea proiectelor complexe prin colaborarea mai
multor proiectanţi care prelucrează date partajate
 Astfel de aplicaţii sunt necesare în numeroase domenii de activitate ca:
 Sisteme de proiectare şi producţie asistate de calculator (Computer-aided
design and manufacturing - CAD/CAM)
 Sisteme de diagnoză medicală
 Sisteme de prelucrare a imaginilor
 Sisteme de studiere şi prognoze climatice
 Sisteme de recunoaştere a caracterelor şi a obiectelor folosind inteligenţa
artificială
 Baze de date versus Information Retrieval Systems (IRS)
 Tradiţional, bazele de date memorează şi interoghează date simple, în timp ce
sistemele IRS oferă memorarea și interogarea unor date complexe
 Integrarea IR în baze de date  provocare rezolvabilă baze de date MM

Cerinţe pentru bazele de date multimedia
 Fiecare tip de obiect multimedia (monomedia sau document) este
caracterizat de o mare varietate de trăsături care trebuie să fie reprezentate
în bazele de date
 De ex., o imagine reprezentată ca un tablou bidimensional de biţi, mai are şi alte
caract. globale ca distribuţia de culori, texturi, obiecte identificate etc.
 Într-un document multimedia interactiv (Interactive Multimedia Document –
IMD) o varietate de obiecte monomedia sunt ordonate în domeniul spaţial
şi temporal, iar utilizatorul sau interacţiuni interne pot modifica această
ordonare în cursul prezentării
 Bazele de date MM trebuie să asigure, ca şi bazele de date tradiţionale:
 Integrarea datelor – datele nu trebuie să fie duplicate pentru fiecare program
 Independenţa datelor – separarea datelor de programele de aplicaţii
 Controlul concurenţei – permite execuţia concurentă a tranzacţiilor
 Persistenţa datelor – datele sunt salvate pe suport persistent
 Confidenţialitatea şi integritatea datelor
 Refacerea datelor- defectele necatastrof nu trebuie să afecteze datele persist
 În plus, bazele de date multimedia trebuie să ofere:
 Suport pentru stocarea și interogarea eficientă a datelor multimedia
 Suport pentru manevrarea şi livrarea unor volume mari de date
 Suport pentru prezentare datelor multimedia în condiţiile cerute de utilizator

Date multimedia şi metadata multimedia
 Fiind cunoscut faptul că multe din datele media (imagini, video, audio)
prezintă informaţii redundante, au fost dezvoltate numeroase standarde
de codare, decodare şi compresie a datelor multimedia
 Standardele MPEG (MPEG-1, MPEG-2, MPEG-4) pentru compresia video şi
audio
 Standardul AVI (Audio-Video Interleaved) introdus de Microsoft
 Metadata multimedia descriu datele multimedia din diferite perspective:
 Din perspectiva producătorului: metadata oferă informaţii bibliografice (titlu,
autor, data creerii etc.)
 Din perspectiva furnizorului: descriptori ai formatului resursei, informaţii
semantice (de exemplu, numele jucătorilor echipelor dintr-un video cu un meci
de fotbal); aceste informaţii ajută la căutări în aplicaţiile multimedia
 Din perspectiva consumatorului: metadata care permit personalizarea modului
de livrare (prin Internet) şi de prezentare
 Standarde pentru metadata: Dublin Core Standard, Metadata Dictionary
SMPTE (Society of Motion Picture and Television Engineers), MPEG-7,
MPEG-21

Metadata multimedia
 MPEG-7 este un standard foarte important pentru sistemele multimedia
de regăsire pe baza conţinutului (CBIR)
 Acest standard bazat pe XML specifică elementele de descriere a datelor
(metadata) pentru întreg ciclul procesului multimedia: captură, analiză,
filtrare, codare, livrare
 Standardul MPEG-21 specifică organizarea infrastructurii de livrare a
datelor multimedia
 MPEG-21 defineşte entitatea de distribuire (Digital Item), care poate fi
schimbată între actori (utilizatori), modul de administrare a conţinutului,
managementul drepturilor de proprietate etc.
 Metadata sunt stocate în baza de date împreună cu datele multimedia,
sunt prelucrate şi utilizate pentru interogări

Arhitectura bazelor de date multimedia

Etapele de dezvoltare a bazelor de date multimedia
 Primele sisteme de baze de date MM comerciale au fost dezvoltate în anii
1990, implementate ad-hoc, cu mecanisme de inserare, actualizare şi
interogare a datelor special proiectate
 Dintre acestea (MediaDB - actualmente MediaWay- JASMINE, ITASCA,
ORION) puţine mai sunt în funcţiune (de ex. MediaWay)
 “Al doilea val” - Bazele de date MM dezvoltate prin extensia bazelor de
date comerciale existente; s-au remarcat:
 Baze de date OO – ObjectStore (cu extensii pentru date multimedia)
 Baze de date obiect-relaţionale: Oracle (9i, 10g, 11g), IBM DB2, IBM Informix
 “Al treilea val” – Sisteme integrate de baze de date MM şi regăsire după
conţinut (Content-Based Retrieval)
 Proiecte recent terminate sau în curs de finalizare cu capacităţi puternice de
regăsire semantică, bazate pe standardele MPEG-7 şi MPEG-21
 Proiectul MARS (Multimedia Analysis and Retrieval System) - University of
Illinois at Urbana-Champaign
 MPEG-7 Oracle Multimedia Data Cartridge

Oracle Multimedia
 Oracle Multimedia (redenumire pentru Oracle interMedia) este o parte
integrantă din sistemul Oracle 11g care permite stocarea, gestionarea şi
regăsirea datelor media (imagini, video, audio, documente IMD)
 Oracle Multimedia prevede:
 Stocarea şi regăsirea (interogarea) datelor media
 Managementul metadata media şi a celor ale aplicaţiei
 Suport pentru cele mai cunoscute formate de date imagini, audio, video
 Interogări folosind datele relaţionale asociate
 Interogări utilizând metadatele extrase
 Interogări utilizând conţinutul media indexat cu indexări specializate
 Pentru dezvoltarea aplicaţiilor complexe, sunt prevăzute:
 Interfeţe de acces tradiţionale şi interfeţe Web
 Posibilitatea de comunicare cu servere streaming pentru livrarea datelor
media în timp real

Tipuri de date Oracle multimedia
 Tipurile de date multimedia în Oracle, definite în schema ORDSYS sunt:
 ORDImage – pentru reprezentarea imaginilor
 ORDAudio – pentru reprezentarea audio
 ORDVideo – pentru reprezentarea video
 ORDDoc – pentru reprezentarea documentelor care conţin combinaţii de
imagini, audio şi video
 Aceste tipuri (clase) definesc:
 atribute care reprezintă:
 conţinutul (media data - date imagine, video sau audio)
 metadata (dimensiunea datelor, tipul, formatul, metoda de compresie)
 Metode care pot fi executate de obiecte
(import, export, citire/scriere metadata,
compresie, conversii de formate etc.)
 Instanţe ale acestor tipuri de date pot fi
inserate ca obiecte în coloanele
tabelelor bazei de date

Modelul de memorare a obiectelor multimedia (1)
 Atributele de date (media data) ale obiectelor ORDImage, ORDAudio,
ORDVideo, ORDDoc, pot fi memorate:
 În baza de date, ca obiect BLOB, sub controlul tranzacţiilor
 În afara bazei de date (fără controlul tranzacţiilor); în acest caz în tabel este
memorată o referinţă la datele media, care sunt memorate:
 într-un fişier (BFILE - File-based large object ), sau
 la o adresă URL, sau
 pe un server de date media definit de utilizator
 Datele media memorate în afara bazei de date pot fi importate în obiecte
BLOB, pentru controlul tranzacţiilor
 Metadata media sunt memorate în baza de date sub controlul
tranzacţiilor, indiferent dacă datele media sunt memorate în baza de date
sau în afara ei
 Oracle Multimedia gestionează metadata pentru toate tipurile media şi le
poate extrage automat pentru imagini, audio, video

Modelul de memorare a obiectelor multimedia (2)
 Modelul de memorare Oracle Multimedia include şi un set de operaţii
asupra conţinutului multimedia cum sunt:
 Operaţii BLOB: încărcare, extragere, ştergere conţinut multimedia
 Operaţii externe: deschidere (open), închidere (close), import/export între o
sursă externă (BFILE) şi un obiect BLOB
 Alte operaţii: extragerea multimedia metadata, memorarea metadata,
manipularea datelor etc.

Încărcarea conţinutului multimedia
 Încărcarea conţinutului multimedia în baza de date Oracle:
 SQL*Loader: încarcă mari cantităţi de conţinut multimedia foarte eficient
 Proceduri PL/SQL de încărcare, ca alternativă faţă de SQL *Loader
 Replicare din alte baze de date Oracle
 Annotator: un toolset sofisticat care extrage metadata din conţinutul
multimedia şi le memorează împreună în baza de date
 Oracle Internet File System:
un toolset de import/export
conţinut multimedia folosind
interfeţe client
 Metadata extrase de un toolset
evoluat (ca Annotator) pot fi
memorate ca:
 atribute metadata în tabele
 documente XML, pentru
prelucrare ulterioară

Atribute metadata
 Metadata includ următoarele atribute:
 Informaţii privind modul de stocare a datelor audio, imagini, video,
documente, incluzând tipul sursei de date, numele sursei de date, locaţia,
dacă datele media sunt stocate intern sau extern
 Momentul de timp (timestamp) al actualizării datelor media
 Descrierea datelor audio, video, imagini
 Tipul MIME (Multipurpose Internet Mail Extensions)
 Caracteristici audio: tipul de codare, număr de canale, frecvenţa de
eşantionare, dimensiunea eşantioanelor, tipul de compresie, durata de
redare
 Caracteristici imagini: dimensiunile imaginii (lăţime, înălţime), formatul
conţinutului imaginii, mărimea conţinutului imaginii
 Caracteristici video: dimensiunile cadrelor (lăţime, înălţime), rezoluţia cadre,
număr de cadre, tipul compresiei, durata de redare
 În plus, este prevăzut un set minimal de metode de manevrare a
imaginilor: conversia formatelor, compresie, scalare, copiere, oglindire,
rotire, deplasare, ajustarea strălucirii
Livrarea conţinutului multimedia
 Oracle Multimedia oferă posibilitatea de regăsire după conţinut a imaginilor
digitale (Content-Based Retrieval - CBR)
 Regăsirea după conţinut caută în baza de date imagini care “seamănă” cu o
imagine dată (adică au distribuţii de culoare sau forme similare)
 Regăsirea după conţinut nu permite recunoaşterea de pattern-uri puternic
specializate (recunoaşterea amprentelor, a feţelor sau a imaginilor medicale)
 Modurile de livrare a conţinutului multimedia către clien ți :
 Toate tipurile de date multimedia pot fi livrate clientului direct din baza de date
 Oracle Multimedia mai oferă posibilitatea de livrare a conţinutului multimedia prin
intermediul unui server Web
 Pentru anumite formate video sau
audio este posibilă livrarea
isocronă în protocol RTSP
(Real-time Streaming Protocol)
prin intermediul unui server de
streaming (de ex. RealNetworks),
astfel încât să poată fi redată
direct la utilizator

Tipurile de date Oracle Multimedia
 Exemplele din acest capitol folosesc tabelul ONLINE_MEDIA din
schema Product Media (PM), care folosește tipurile multimedia din
schema ORDSYS: ORDSYS.ORDIMAGE, ORDSYS.ORDAUDIO etc.
 Fiecare obiect multimedia (ORDAudio, ORDImage,ORDVideo,

ORDDoc) conţine un obiect imbricat (numit source) de tipul ORDSource
 Obiectul ORDSource permite accesul la o sursă de diferite tipuri

Tabelul online_media
 Datele inițiale din tabelul online_media sunt prezentate mai jos:

Obiectul imbricat ORDSource
 Atributele obiectului imbricat ORDSource sunt:
 localData: datele multimedia memorate local ca obiect BLOB cu dimensiunea
de maxim 128 TB
 srcType: tipul sursei de date
 srcLocation: locaţia sursei de date
 srcName: numele obiectului de date
 updateTime: momentul de timp al ultimei actualizări a datelor
 local: un flag care indică dacă datele sunt locale (1,NULL) sau externe (0)
 Multe din metodele comune tipurilor multimedia se referă la operaţii legate
de obiectul ORDSource, imbricat în fiecare dintre ele
 Metodele invocate la nivel ORDSource au ca prim argument ctx(RAW)
care defineşte contextul de execuţie:
 Înainte de apelul oricărei astfel de funcţii, clientul trebuie să aloce structura ctx,
să o iniţializeze cu NULL şi să invoce metoda openSource(); prin acest apel,
modulul plug-in al sursei iniţializează contextul pentru client
 După terminarea operaţiilor, clientul trebuie să invoce metoda closeSource()
 Tipul SQL Oracle raw(n) memorează un şir de biţi de lungime maximă de
2000 octeţi (16.000 biţi)

Metodele comune ale tipurilor Oracle Multimedia
 Metode comune ale tipurilor Oracle MM de tip selectori (get) şi modificatori
(set):
 getBFile( ) RETURN BFILE
 getContent( ) RETURN BLOG
 getMimeType( ) RETURN VARCHAR2
 getSource( ) RETURN VARCHAR2
 getSourceLocation( ) RETURN VARCHAR2
 getSourceName( ) RETURN VARCHAR2
 getSourceType( ) RETURN VARCHAR2
 getUpdateTime( ) RETURN DATE
 isLocal( )
 setLocal( )
 setMimeType( )
 setSource( )
 setUpdateTime( )
 deleteContent()
 Alte metode comune citesc sau scriu date în sursele de date:
 readFromSource( )
 writeToSource( )

Exemple de utilizare a metodelor comune (1)
 Aflarea tipului datelor multimedia din tabelul online_media:
SELECT t.product_id id,
t.product_photo.getMimeType() mimetype
FROM pm.online_media t;

t.product_audio.getMimeType() mimetype

t.product_video.getMimeType() mimetype

 Aflarea timpului de selecție/actualizare a unei date audio:
DECLARE
obj ORDSYS.ORDAudio;
BEGIN
SELECT p.product_audio INTO obj FROM pm.online_media p
WHERE p.product_id = 1743;
DBMS_OUTPUT.PUT_LINE('Update time is:');
DBMS_OUTPUT.PUT_LINE(TO_CHAR(obj.getUpdateTime(),
'MM-DD-YYYY HH24:MI:SS'));
END;
 La execuția acestui bloc PL/SQL
se obține rezultatul afișat

 Setarea unei surse externe de date:
DECLARE obj ORDSYS.ORDAudio;
BEGIN
WHERE p.product_id = 1743 FOR UPDATE;
DBMS_OUTPUT.PUT_LINE( 'setting and getting source');
obj.setSource('file','FILE_DIR','audio.wav');
DBMS_OUTPUT.PUT_LINE( obj.getSource());
UPDATE pm.online_media p
SET p.product_audio = obj
END;
 Dacă sursa este un fișier, locația

acestuia trebuie să fie un director
Oracle definit cu sys as sysdba:
CREATE OR REPLACE DIRECTORY
FILE_DIR AS ‘/home/Oracle/Desktop/’;
Commit;
GRANT READ,WRITE ON DIRECTORY
FILE_DIR TO pm;
Commit;
Tipul de date multimedia ORDAudio (1)
 Tipul de date ORDAudio permite stocarea şi manipularea datelor audio:
CREATE TYPE ORDAudio AS OBJECT (
--------------------------------------
-- Attributes
description VARCHAR2(4000),
source ORDSource,
format VARCHAR2(31),
mimeType VARCHAR2(4000),
comments CLOB,
---------------------------------------
-- Audio Related Attributes
encoding VARCHAR2(256),
numberOfChannels INTEGER,
samplingRate INTEGER,
sampleSize INTEGER,
compressionType VARCHAR2(4000),
audioDuration INTEGER,
----------------------------------------------
-- Constructors
CONSTRUCTOR FUNCTION ORDAudio (SELF IN OUT NOCOPY ORDSYS.ORDAudio,
data IN BLOB,
setProperties IN INTEGER DEFAULT 0
) RETURN SELF AS RESULT,

Tipul de date multimedia ORDAudio (2)
CONSTRUCTOR FUNCTION ORDAudio(SELF IN OUT NOCOPY ORDSYS.ORDAudio,
source_type IN VARCHAR2 DEFAULT 'LOCAL', --Allowed value: LOCAL, FILE, HTTP
source_location IN VARCHAR2 DEFAULT NULL,
source_name IN VARCHAR2 DEFAULT NULL,
--
STATIC FUNCTION init RETURN ORDAudio,
STATIC FUNCTION init( srcType IN VARCHAR2,
srcLocation IN VARCHAR2,
srcName IN VARCHAR2 ) RETURN ORDAudio,
-- DATE RELATED METHODS
MEMBER FUNCTION getUpdateTime RETURN DATE,
MEMBER PROCEDURE setUpdateTime(SELF IN OUT NOCOPY ORDAudio, current_time
DATE),
-- MIMETYPE RELATED METHODS
MEMBER FUNCTION getMimeType RETURN VARCHAR2,
MEMBER PROCEDURE setMimeType(SELF IN OUT NOCOPY ORDAudio,
mime IN VARCHAR2),
----------------------------------- )
 Crearea și iniţializarea obiectelor ORDAudio se poate face prin:
 constructori
 metode statice init(), care setează valorile (unele implicite) ale unei instanţe (seamănă
cu constructorii)
Crearea și iniţializarea obiectelor ORDAudio
 Metoda init( ) RETURN ORDAudio - iniţializează toate atributele
obiectului cu NULL, cu următoarele excepţii:
 source.updateTime – este setat la SYSDATE
 source.local - este setat la 1 (local)
 source.localData - este setată la valoarea empty_blob
 Metoda: init (srcType IN VARCHAR2, srcLocation IN VARCHAR2, srcName IN
VARCHAR2) RETURN ORDAudio; - iniţializează toate atributele cu NULL,
cu următoarele excepţii:
 source.updateTime - este setată cu SYSDATE
 source.local - este setată la 0
 source.localData - este setată cu empty_blob
 source.srcType, source.srcLocation, source.srcName - sunt setate cu
valoarea de intrare a argumentului respectiv
 Exemple de iniţializare:
BEGIN INSERT INTO pm.online_media (product_id, product_audio)
VALUES (1729, ORDSYS.ORDAudio.init()); END;
/
BEGIN INSERT INTO pm.online_media (product_id, product_audio)
VALUES (1733, ORDSYS.ORDAudio.init('FILE', 'FILE_DIR','audio.wav')); END;
/
Metodele specifice tipului de date ORDAudio
 Cele mai multe dintre metode specifice tipului ORDAudio sunt selectori (get())
sau modificatori (set()) pentru diferitele atribute:
 getAllAttributes( )  setAudioDuration( )
 getAttribute( )  setCompressionType( )
 getAudioDuration( )  setDescription( )
 getCompressionType( )  setEncoding( )
 getContentLength( )  setFormat( )
 getContentInLob( )  setKnownAttributes( )
 getDescription( )  setNumberOfChannels( )
 getEncoding( )  setSampleSize( )
 getFormat( )  setSamplingRate( )
 getNumberOfChannels( )
 getSampleSize( )
 getSamplingRate( )
 Pe lângă acestea, mai există:
 metode de import a conţinutului media (import(), importFrom())
 metoda de verificare a proprietăţilor obiectului (checkProperties())
 metoda de prelucrare (processAudioCommand())

Exemplu pentru tipul ORDAudio (1)
 Setarea şi citirea atributelor unui obiect ORDAudio:
DECLARE obj ORDSYS.ORDAudio;
BEGIN
obj.setFormat('AUFF');
obj.setEncoding('MULAW');
obj.setNumberOfChannels(1);
obj.setSamplingRate(8);
obj.setSampleSize(8);
obj.setCompressionType('8BITMONOAUDIO');
obj.setAudioDuration(16);
DBMS_OUTPUT.PUT_LINE('format: ' || obj.getFormat());
DBMS_OUTPUT.PUT_LINE('encoding: ' || obj.getEncoding());
DBMS_OUTPUT.PUT_LINE('channels: ' || TO_CHAR(obj.getNumberOfChannels()));
DBMS_OUTPUT.PUT_LINE('samplingRate: ' || TO_CHAR(obj.getSamplingRate()));
DBMS_OUTPUT.PUT_LINE('sampleSize: ' || TO_CHAR(obj.getSampleSize()));
DBMS_OUTPUT.PUT_LINE('compressionType : ' || obj.getCompressionType());
DBMS_OUTPUT.PUT_LINE('audioDuration: ' || TO_CHAR(obj.getAudioDuration()));
COMMIT;
END;

Exemplu pentru tipul ORDAudio (2)

Importul datelor audio din surse externe
 Metodele de import sunt:
 import(ctx IN OUT ROW) - transferă datele audio de la o sursă externă de
date audio în variabila localData a obiectului ORDSource imbricat; parametrul
ctx este contextul de informaţii al modulului plug-in al sursei
 importFrom(ctx IN OUT RAW,
source_type IN VARCHAR2,
source_location IN VARCHAR2,
source_name IN VARCHAR2) - transferă datele audio de la sursa externă
specificată în variabila localData a obiectului ORDSource imbricat
 Exemplu:
DECLARE
obj ORDSYS.ORDAudio; ctx RAW(64) :=NULL;
BEGIN
obj.importFrom(ctx,'file','FILE_DIR',‘Canary.wav');
-- display size
DBMS_OUTPUT.PUT_LINE('Length is ' || TO_CHAR(obj.getContentLength(ctx)));
UPDATE pm.online_media p SET p.product_audio = obj
END;

Tipul de date multimedia ORDImage
 Tipul de date ORDImage permite stocarea, managementul şi
manipularea imaginilor; atributele tipului de date ORDImage sunt:
-- TYPE ATTRIBUTES
source ORDSource, -- sursa continutului de date
height INTEGER, -- inaltimea imaginii in numar de pixeli
width INTEGER, -- latimea imaginii in numar de pixeli
contentLength INTEGER, -- dim. in bytes ocupata de imagine pe disc
fileFormat VARCHAR2(4000), -- formatul fisierului (TIFF, JPEG etc.)
contentFormat VARCHAR2(4000), -- tipul imaginii (monocroma etc)
compressionFormat VARCHAR2(4000), -- formatul de compresie
mimeType VARCHAR2(4000), -- tipul MIME
 Metodele de iniţializare și constructorii sunt similare cu ale tip ORDAudio:
 init () RETURN ORDImage
 init (srcType IN VARCHAR2, srcLocation IN VARCHAR2, srcName IN VARCHAR2)
RETURN ORDImage
 Exemplu de iniţializare a unui obiect ORDImage:
BEGIN
INSERT INTO pm.online_media (product_id, product_photo)
VALUES (3515, ORDSYS.ORDImage.init('FILE', 'FILE_DIR',‘Garden.jpg'));
END;
Metodele specifice tipului ORDImage
 checkProperties( )  getMetadata( )
 copy( )  getWidth( )
 getCompressionFormat( )  import( )
 getContentFormat( )  importFrom( )
 getContentLength( )  process( )
 getDicomMetadata( )  processCopy( )
 getFileFormat( )  putMetadata( )
 getHeight( )  setProperties( )
Exemplu: crearea unei copii a unei imagini
DECLARE image_1 ORDSYS.ORDImage; image_2 ORDSYS.ORDImage;
BEGIN -- Initialize a new ORDImage object where the copy will be stored:
INSERT INTO pm.online_media (product_id, product_photo)
VALUES (3091, ORDSYS.ORDImage.init());
-- Select the source object into image_1:
SELECT product_photo INTO image_1 FROM pm.online_media WHERE product_id = 1743;
-- Select the target object into image_2:
SELECT product_photo INTO image_2 FROM pm.online_media
WHERE product_id = 2400 FOR UPDATE;
image_1.copy(image_2); -- Copy the data from image_1 to image_2:
UPDATE pm.online_media SET product_photo = image_2 WHERE product_id = 2400;
END;

Tipul de date multimedia ORDVideo
 Tipul de date ORDVideo suportă stocarea şi managementul datelor video;
atributele acestui tip sunt:
-- TYPE ATTRIBUTES
description VARCHAR2(4000),
source ORDSource,
format VARCHAR2(31),
mimeType VARCHAR2(4000),
comments CLOB,
-- VIDEO RELATED ATTRIBUTES
width INTEGER,
height INTEGER,
frameResolution INTEGER,
frameRate INTEGER,
videoDuration INTEGER,
numberOfFrames INTEGER,
compressionType VARCHAR2(4000),
numberOfColors INTEGER,
bitRate INTEGER
 Metodele de iniţializare (și constructori similari): init () RETURN ORDVideo şi
init (srcType IN VARCHAR2, srcLocation IN VARCHAR2, srcName IN
VARCHAR2) RETURN ORDVideo

Metodele specifice tipului ORDVideo
 checkProperties( )  import( )
 getAllAttributes( )  importFrom( )
 getAttribute( )  processVideoCommand( )
 getBitRate( )  setBitRate( )
 getCompressionType( )  setCompressionType( )
 getContentInLob( )  setDescription( )
 getContentLength( )  setFormat( )
 getDescription( )  setFrameRate( )
 getFormat( )  setFrameResolution( )
 getFrameRate( )  setFrameSize( )
 getFrameResolution( )  setKnownAttributes( )
 getFrameSize( )  setNumberOfColors( )
 getNumberOfColors( )  setNumberOfFrames( )
 getNumberOfFrames( )  setProperties( )
 getVideoDuration( )  setVideoDuration( )
 Exemplu: citirea rezoluţiei de cadru a unui obiect video
DECLARE obj ORDSYS.ORDVideo; res INTEGER;
BEGIN
SELECT p.product_video INTO obj FROM pm.online_media p WHERE p.product_id =1743;
DBMS_OUTPUT.PUT_LINE(‘Duration : ' ||TO_CHAR(obj.getVideoDuration()));
END;

Tipul de date multimedia ORDDoc
 Tipul de date ORDDoc permite stocarea şi managementul oricărui tip de
date multimedia, incluzând imagini, date audio şi date video; atributele
acestui tip sunt:
-- TYPE ATTRIBUTES
source ORDSource,
format VARCHAR(80),
mimeType VARCHAR(80),
contentLength INTEGER,
comments CLOB,
 Metodele de iniţializare statice (și constructori similari):
 init () RETURN ORDDoc
 init (srcType IN VARCHAR2, srcLocation IN VARCHAR2, srcName IN
VARCHAR2) RETURN ORDDoc
 Metodele specifice tipului ORDDoc:
 getContentInLob( )  import( )
 getContentLength( )  importFrom( )
 getFormat( )  setFormat( )
 setProperties( )

Aplicaţii Oracle Multimedia
 Aplicaţiile multimedia se folosesc pentru colectarea, modelarea, stocarea
şi prezentarea datelor multimedia
 Aplicaţiile Oracle Multimedia sunt aplicaţii multi-tier care folosesc: Oracle
Database, Oracle Application Server, biblioteci Java
 Oracle Database asigură:
 Stocare, management, regăsire imagini, audio, video
 Formatarea datelor, extragere metadate, metode de prelucrare a imaginilor
 Suport pentru comunicaţia cu servere streaming
 Oracle Application Server asigură:
 Suport de dezvoltare a aplicaţiilor bazate pe JSP, servlet, PL/SQL
 Servicii de adaptare a mediilor la transmiterea wireless
 JDeveloper (BC4J/UIX) şi integrarea portalurilor
 Biblioteci Java:
 JAI (Java Advanced Imaging)
 JMF(Java Media Framework)
 JDBC (Java Database Connectivity)

Arhitectura aplicaţiilor Oracle Multimedia
 OCI (Oracle Call Interface)

 RTP (Real-time Transport Protocol) RTSP (Real-time Streaming Protocol)

Oracle Database și Oracle Application Server
 Oracle Database conţine tabelele care au coloane de obiecte multimedia; de
asemenea pot exista date multimedia externe, referite din tabele
 Modulele Java Media Parser şi Media (Image) Processor se evecută într-o JVM
 Media parser preia şi verifică conţinutul de date şi metadata atunci când datele sunt
inserate în baza de date
 Procesorul media (Media sau Image Processor) bazat pe biblioteca JAI (Java Advanced
Imaging) permite prelucrări de imagini în baza de date
 Oracle Application Server conţine:
 Mediul de dezvoltare a aplicaţiilor JDeveloper, care poate fi folosit pentru dezvoltarea
aplicaţiilor Java care utilizează obiecte Oracle Multimedia
 Portalul de acces al serverului de aplicaţii
 Un container de componente business (BC4J – Business Components for Java) care
permit dezvoltarea de aplicaţii Java
 Biblioteca Oracle Multimedia Java API și biblioteca de tag-uri JSP
 Biblioteca Oracle Multimedia Java API conţinută în package-ul oracle.ord.im.*
conţine clase corespunzătoare tipurilor Oracle Multimedia
 Aceste clase au denumiri asemănătoare cu cele din Oracle Multimedia, dar respectând
convenţiile Java: OrdAudio, OrdImage, OrdVideo, OrdDoc
 Folosind această bibliotecă se pot dezvolta aplicaţii de tipul client (puternic) şi aplicaţii
Web bazate pe Java, care accesează datele multimedia stocate în baza de date

Client Java pentru aplicaţii Oracle Multimedia
 Obiectele Oracle Multimedia pot fi folosite (pentru încărcare, interogare,
salvare) prin intermediul claselor corespunzătoare din Oracle Multimedia
Java API (OrdAudio, OrdDoc,OrdImage, OrdVideo)
 Conectarea la baza de date se face prin biblioteca JDBC prin care se
pot trimite comenzi SQL de interogare:
String query = "select product_photo, product_audio,"+
" product_video, product_testimonials from" +
" pm.online_media where product_id=3117";
PreparedStatement pstmt = conn.prepareStatement(query);
 Rezultatul este returnat în structura rset:
OracleResultSet rset = (OracleResultSet)pstmt.executeQuery();
 Şi apoi poate fi prelucrat:
if ( rset.next() ) {
OrdImage imgProxy = (OrdImage) rset.getORAData (
"product_photo", OrdImage.getORADataFactory());
OrdAudio audProxy = (OrdAudio) rset.getORAData (
"product_audio", OrdAudio.getORADataFactory());
…………..
}

Aplicaţii Web Oracle Multimedia bazate pe Java
 Aplicaţiile Web bazate pe Java constau din servleţi şi pagini JSP
 Un servlet este o clasă Java care prelucrează cererile HTTP şi generează
pagini HTML dinamice de răspuns
 O pagină JSP este un document text care conţine cod Java:
 codul Java se converteşte într-un servlet care construieşte partea dinamică de
răspuns
 această parte se combină cu partea statică din pagina JSP pentru a forma
pagina HTML de răspuns către client
 Clasele din Oracle Multimedia Servlets & JSP Java API (incluse în
pachetul (oracle.ord.im.* ) permit regăsirea datelor media în baza de date
şi încărcarea lor în aplicaţia Web
 Aceste clase sunt:
 OrdHttpResponseHandler
 OrdHttpJspResponseHandler
 OrdHttpUploadFormData
 OrdHttpUploadFile
 OrdMultipartFilter
 OrdMultipartWrapper

Baze de date medicale - Standardul DICOM
 Digital Imaging and Communications in Medicine (DICOM) este un
standard pentru imagini medicale
 Acest standard a fost iniţiat de American College of Radiology (ACR) şi
National Electrical Manufacturers Association (NEMA) pentru a permite
interschimbul imaginilor şi conectivitatea dispozitivelor radiologice
 Imaginile medicale sunt componente de bază în înregistrările medicale
electronice (Electronic Medical Records - EMR)
 Stocarea şi manevrarea sigură a imaginilor medicale prezintă un mare interes
ştiinţific aplicativ
 Standardul DICOM permite stocarea împreună a imaginilor şi metadata şi
are 2 componente: modelul de date şi protocolul de comunicaţie
 Modelul de date este obiect-orientat: imaginile sau formele de undă captate
de dispozitivele medicale sunt reprezentate prin:
 obiecte de informaţii
 operaţii care pot fi executate asupra acestor obiecte (get, fiind, store)
 împreună, obiectele şi operaţiile sunt denumite “service object pair” (SOP)
 Protocolul de comunicaţie defineşte sintaxa de transfer pentru trimiterea
obiectelor prin reţea sau pentru memorarea într-un sistem de fişiere

Oracle Multimedia DICOM
 DICOM a fost introdus în Oracle începând cu versiunea 10g, iniţial ca
extensie a tipului ORDImage
 În versiunea următoare (11g) s-a adăugat tipul de date ORDDicom în
schema ORDSYS
 Datele DICOM sunt prezentate în tabele (ca şi coloane ale acestora) şi
pot fi accesate pentru interogări
 Oracle Multimedia DICOM asigură securitatea şi confidenţialitatea
datelor medicale prin criptarea acestora şi prin controlul accesului
(autentificare, autorizare)
 Metadata DICOM includ:
 informaţii despre pacient
 informaţii despre medic (fizician)
 informaţii privind seria şi studiul medical în care se încadrează imaginile
 Metadata DICOM se reprezintă în format XML, cu posibilitatea de
extindere şi definire de către utilizator a informaţiilor de interes pentru
fiecare aplicaţie

Tipul de date ORDDicom (1)
CREATE TYPE ORDDicom AS OBJECT (
-- Attributes
SOP_INSTANCE_UID VARCHAR2(128),
SOP_CLASS_UID VARCHAR2(64),
STUDY_INSTANCE_UID VARCHAR2(64),
SERIES_INSTANCE_UID VARCHAR2(64),
Source ORDDataSource,
Metadata SYS.XMLType,
ContentLength INTEGER,
Flag INTEGER,
Extension BLOB,
CONSTRUCTOR FUNCTION ORDDicom(SELF IN OUT NOCOPY ORDDICOM, -- from BLOB
data IN BLOB,
CONSTRUCTOR FUNCTION ORDDicom(SELF IN OUT NOCOPY ORDDICOM, -- from file
source_type IN VARCHAR2 DEFAULT 'LOCAL',
source_location IN VARCHAR2 DEFAULT NULL,
source_name IN VARCHAR2 DEFAULT NULL,
CONSTRUCTOR FUNCTION ORDDicom(SELF IN OUT NOCOPY ORDDicom, -- from image
data IN ORDImage,
setproperties IN INTEGER DEFAULT 0
MEMBER FUNCTION extractMetadata (
extractOption IN VARCHAR2 DEFAULT 'ALL',
docName IN VARCHAR2 DEFAULT 'ordcmmp.xml')
RETURN SYS.XMLTYPE, …………………………………………………….)

Tipul de date ORDDicom (2)
 Exemplu de tabel care include obiecte ORDDicom este tabelul
MEDICAL_IMAGE_OBJ din setul de exemple Oracle Product Media
 Un obiect ORDDicom (1) este compus din:
(2) Atributele DICOM metadata reprezentate ca
document XML:
metadata XMLType
(3) Conţinutul DICOM, reprezentat ca obiect BLOB în
baza de date sau ca referinţă la un fişier:
source ORDDataSource
(4) Atributele generale care memorează identificatori:
SOP_INSTANCE_UID varchar2(128),
SOP_CLASS_UID varchar2(64),
STUDY_INSTANCE_UID varchar2(64),
SERIES_INSTANCE_UID varchar2(64),
(5) Atribute diverse utilizate de Oracle:
contentLength INTEGER,
flag INTEGER,
extension BLOB

Construirea obiectelor ORDDicom
 Obiectele ORDDicom pot fi construite folosind un constructor
ORDDicom( ) într-o instrucţiune SQL sau într-un program PL/SQL
 Construirea unui obiect ORDDicom pornind de la un BLOB:
ORDDicom(SELF IN OUT NOCOPY ORDDicom, data IN BLOB,
setproperties IN INTEGER DEFAULT 0) RETURN SELF AS RESULT
 Construirea unui obiect ORDDicom pornind de la un obiect ORDImage:
ORDDicom(SELF IN OUT NOCOPY ORDDicom, data IN ORDImage,
setproperties IN INTEGER DEFAULT 0) RETURN SELF AS RESULT
 Construirea unui obiect ORDDicom pornind de la o sursă:
ORDDicom( SELF IN OUT NOCOPY ORDDicom, source_type IN VARCHAR2 DEFAULT
'LOCAL', source_location IN VARCHAR2 DEFAULT NULL, source_name IN
VARCHAR2 DEFAULT NULL, setproperties IN INTEGER DEFAULT 0 ) RETURN
SELF AS RESULT
 Exemplu – crearea unui obiect ORDDicom dintr-un fişier şi extragerea
atributelor prin setarea flag-ului setProperties:
insert into medical_image_obj (id, dicom_src)
values (2, ORDDicom('FILE', 'DICOMDIR', 'example.dcm', 1));

Metodele tipului de date ORDDicom
 export( )  getSOPInstanceUID( )
 extractMetadata( )  getStudyInstanceUID( )
 getAttributeByName( )  import( )
 getAttributeByTag( )  isAnonymous( )
 getContent( )  isConformanceValid( )
 getContentLength( )  isLocal( )
 getSeriesInstanceUID( )  makeAnonymous( )
 getSourceInformation( )  processCopy( ) to BLOBs
 getSourceLocation( )  processCopy( ) to ORDDicom
 getSourceName( )  processCopy( ) to ORDImage
 getSourceType( )  setProperties( )
 getSOPClassUID( )  writeMetadata( )
 Exemplu: scrierea de noi metadata într-un obiect DICOM:
declare obj_src orddicom; obj_dest orddicom; metadata xmltype;
begin
metadata := xmltype(bfilename('DICOMDIR', 'wm_meta.xml'),
nls_charset_id('AL32UTF8'), select dicom_src, dicom_dest into obj_src, obj_dest
from medical_image_obj where id = 1 for update;
obj_src.writeMetadata(metadata, obj_dest);
update medical_image_obj set dicom_dest = obj_dest where id = 1;
end;

Arhitectura Oracle Multimedia DICOM
Oracle Multimedia DICOM permite stocarea, managementul şi regăsirea datelor DICOM în
baze de date, de unde pot fi accesate în siguranţă de mii de utilizatori

Reprezentarea datelor în Oracle Multimedia DICOM
 În Oracle, datele DICOM sunt reprezentate ca şi coloane în tabele,
conținând obiecte de diferite tipuri:
 Imagini radiografice (X-ray), imagini ultrasunete, imagini de rezonanţă
magnetică (RMN)
 Imagini miniatură JPEG (thumbnail) a imaginilor originale
 Forme de undă
 Metadata ca documente XML care însoţesc imaginile
 Maşina virtuală Java (JVM) găzduieşte:
 Un depozit DICOM (repository) - conţine modelul de date al bazei de date
 Un parser DICOM – extrage metadata din conţinutul DICOM
 Un codor XML–DICOM – converteşte metadata în format XML
 Un validator de conformanţă DICOM - verifică sintaxa şi semantica datelor
 Un procesor de imagine bazat pe JAI (Java Advanced Imaging) care
efectuează operaţii ca transformări de formate, generarea imaginilor de
miniatură etc.

Modelul de date Oracle Multimedia DICOM (1)
 Comportarea în timpul execuţiei a sistemului Oracle Multimedia DICOM
este determinată de modelul de date definit pentru domeniul aplicaţiei şi
stocat în Repository (run-time model-based behavior)
 Modelul de date DICOM este o colecţie de documente XML, care pot fi
adăugate sau şterse în mod dinamic în cursul execuţiei şi sunt
gestionate de administratori
 În figura următoare sunt prezentate elementele acestei comportări:
 Deasupra liniei punctate sunt elementele de definire a modelului de date în
cursul proiectării; elementele:
(1) Dicţionarul de date DICOM include definirea atributelor standardului DICOM
(2) Document de mapping corespondenţa între atributele modelului şi documentul
XML de descriere a acestuia
(3) Exemplu de schemă metadata reprezentată în XML
 Sub linia punctată sunt reprezentate operaţiile de extragere a trăsăturilor în
cursul execuţiei:
(4) Conţinutul DICOM este compus din elemente de date (5)

Modelul de date Oracle Multimedia DICOM (2)
(6) Parserul găseşte
definiţia unui atribut
prin examinarea
dicţionarului de date
DICOM
(7) Codorul XML
inspectează
documentul de
corespondenţă
pentru a genera
documentul XML
(8) Documentul XML
generat reprezintă
metadata
(9) Validatorul de
schemă XML poate
valida documentul
pe baza schemei
XML metadata

Extinderea capacităţilor multimedia
ale bazelor de date
 Sistemele de baze de date actuale, în special cele obiect-relaţionale,
oferă posibilităţi de stocare şi management al datelor multimedia:
 IBM DB2 - Universal Database Multimedia Extender extinde modelul
obiect-relaţional pentru obiecte de tip imagini, audio, video; se pot importa şi
exporta obiecte multimedia şi se pot regăsi obiecte după atributele lor
 IBM Informix – DataBlades Extender oferă capacităţi funcţionale de căutare
şi regăsire a datelor multimedia similare cu DB2
 Oracle Multimedia şi Oracle Multimedia DICOM folosesc modelul
obiect-relaţional pentru implementarea modelului de date multimedia
 Aceste tehnologii sunt destul de restrictive şi, de aceea au fost studiate
posibilităţi de extindere a capacităţilor bazelor de date multimedia
 Extensiile se pot realiza folosind cartuşe de date (data cartridge) pe
baza standardelor MPEG-7 şi MPEG-21
 De exemplu, MPEG-7 Multimedia Data Cartridge (MDC) se poate
adapta la capacităţile de încasetare a datelor (data cartridge) oferite de
marii producători de baze de date (Oracle, IBM, Microsoft)

Standardele MPEG-7 şi MPEG-21
 MPEG-7 este un standard ISO/IEC (2002) dezvoltat de MPEG (Moving
Picture Experts Group) pentru descrierea conţinutului multimedia (numit
şi standardul Multimedia Content Description Interface)
 Standardul definşte modul de descriere a conţinutului multimedia prin:
 Descriptori (D); un descriptor este o reprezentare a unei trăsături
caracteristice a informaţiei audio-vizuale
 Scheme de Descriere (Description Schemes - DS); o schemă de descriptori
identifică legăturile între descriptori
 Atât schemele de descriptori cât şi descriptorii sunt definite în limbajul
DDL (Description Definition Language) bazat pe XML Schema, extinsă
prin noi tupuri de date
 MPEG-21 este un standard pentru definirea unui cadru deschis de lucru
cu datele multimedia (open multimedia framework)
 MPEG-21 trebuie să acopere întreg lanţul de creare, producţie, livrare,
personalizare, consum, prezentare şi comercializare a datelor
multimedia

Exemplu de document MPEG-7 şi arborele DOM

Oracle Data Cartridge
 Data Cartridge grupează tipuri de date şi a operaţii specifice unui anumit
domeniu într-un pachet (package) care extinde funcţionarea serverului
Oracle (de exemplu MPEG-7 Oracle Multimedia Data Cartridge)
 Data cartridges sunt executate pe server (server-based) (chiar integrate în
server) dar permit operaţii specifice domeniului respectiv (indexare,
optimizare specfică domeniului etc.)
 Oracle Data Cartradge extinde următoarele caracteristici ale serverului:
 Tipurile de date definite de utilizator pentru domeniul specific (de exemplu,
tipuri de date pentru imagini)
 Capacitatea de execuţie a serverului – care va permite utilizarea rutinelor
scrise în diferite limbaje (Java, C++) ca metode ale tipurilor nou definite
 Optimizarea interogărilor - folosirea
funcţiilor de cost şi a algoritmilor de
optimizare specifici domeniului
 Indexarea datelor – posibilitatea de ORACLE 11g
mentenanţă a indexurilor în timpul

încărcării şi actualizării datelor şi de
utilizare în cursul interogărilor

MPEG-7 Oracle Multimedia Data Cartridge (MDC)
 MDC constă din două părţi: schema multimedia şi modelul de indexare
multimedia
 Schema multimedia constă din metadata care descriu datele multimedia:
 Este realizată pe baza caracteristicii de extensibilitate a mediului cartridge
 Se obţine prin transpunerea schemei datelor multimedia din standardul
MPEG-7 (MDS) în schema bazei de date multimedia, constând din tipuri de
date (object types) şi tabele
 Schema conţine atât descriptori de nivel scăzut (culoare, formă, textură), cât şi
descriptori de nivel înalt (definiţi în partea structurală şi semantică a MPEG
 Aceasta permite regăsirea datelor multimedia pe baza caracteristicilor
semantice în combinaţie cu trăsături de nivel scăzut
 Modelul de indexare multimedia (Multimedia Indexing Framework -MIF)
oferă un cadru de indexare extensibilă pentru regăsirea datelor
 Modelul de indexare este integrat cu limbajul de interogare şi permite regăsirea
eficientă a datelor multimedia
 Un set de biblioteci interne şi externe permit accesul la datele multimedia şi
comunicaţia cu MDC (query, insert, update, etc.).

Suport multimedia în alte SGBD-uri
 MySQL (5.6), PostgreSQL (8.4) MS SQL Server (2008) nu oferă suport
pentru date multimedia, dar utilizatorii pot memora diferite date media
(imagini, date audio etc.) ca și obiecte CLOB sau BLOB sau alte tipuri
 De exemplu, în MS SQL Server 2008 sunt definite tipurile de date:
 text
 ntext (national text)
 image
 Și mai multe instrucțiuni Transact-SQL cu astfel de date:
 Readtext
 Writetext
 Updatetext

Baze de date multimedia
 Harald Kosch, “Distributed Multimedia Database Technologies
Supported by MPEG-7 and MPEG-21”, Auerbach Publications, 2004
 S. Deb, “Multimedia Systems and Content-Based Image Retrieval”,
Idea Group Publishing, 2004
 Oracle 11g Documentation:
 Oracle Multimedia User’s Guide
 Oracle Multimedia Reference
 Oracle Multimedia DICOM Developer’s Guide
 Oracle Data Cartridge Developer's Guide

Capitolul 8 - Baze de date distribuite
 Definiţii ale bazelor de date distribuite, clasificări
 Arhitectura, avantajele şi dezavantajele sistemelor de baze de date distribuite
 Fragmentarea şi replicarea datelor în bazele de date distribuite
 Prelucrarea şi optimizarea interogărilor distribuite
 Gestiunea tranzacţiilor distribuite
 Protocolul 2PL distribuit
 Protocoalele 2PC şi 3PC
 Sisteme de baze de date distribuite Oracle
 Gestiunea tranzacţiilor distribuite
 Replicarea datelor folosind Oracle Stream
 Replicarea datelor folosind Oracle Materialized Views
 Sisteme de baze de date distribuite MySQL
 MySQL Cluster
 Replicarea datelor în sistemele MySQL
 Baze de date distribuite SQL Server
 Baze de date şi sistemul World Wide Web
 Baze de date în Cloud Computing
Prof. Felicia Ionescu Baze de date distribuite 1

Baze de date distribuite – definiţii, termeni
 O bază de date distribuită (Distributed Database - DDB) este o colecţie de
mai multe baze de date intercorelate logic şi distribuite într-o reţea
 Un sistem distribuit de gestiune a bazelor de date (Distributed Database
Management System - Distributed DBMS - DDBMS) este un sistem
software care permite managementul bazelor de date distribuite şi face
distribuţia transparentă pentru utilizator
 Termenul de sistem de baze de date distribuite se referă la o combinaţie de
baze de date distribuite şi la sisteme distribuite de gestiune
 Sistemele de baze de date distribuite sunt similare sistemelor distribuite de
fişiere (Distributed File Systems - DFS), în sensul că ambele facilitează
accesul la date stocate distribuit, dar sunt şi diferenţe:
 În DFS, în general, utilizatorul trebuie să cunoască locaţia datelor
 DDBMS asigură accesul transparent la date; utilizatorul percepe baza de date
distribuită ca pe o bază de date unică, chiar dacă aceasta este distribuită pe
mai multe site-uri şi unele date sunt fragmentate sau replicate
 Bazele de date care funcţionează într-un multiprocesor (cu memorie
partajată) se numesc baze de date paralele; prelucrările se execută
concurent pe mai multe procesoare, dar datele sunt unice şi partajate
Avantajele sistemelor de baze de date distribuite
 Sistemele de baze de date distribuite pot să ofere următoarele avantaje:
 Volum de stocare a datelor crescut
 Independenţa datelor faţă de suportul fizic de memorare: schema conceptuală
defineşte structura logică a datelor, independentă de platforma de memorare
şi poate fi transpusă în diferite scheme fizice, dependente de organizarea
suportului de memorare
 Transparenţă a distribuţiei (în reţea): înseamnă că utilizatorul nu trebuie să
cunoască detalii ale distribuţiei datelor în reţea, atât ca localizare cât şi ca
nume ale entităţilor
 Transparenţă privind replicarea şi fragmentarea datelor
 Siguranţă de funcţionare (reliability) şi disponibilitate (availability) crescută
(reliability – înseamnă probabilitatea ca sistemul să fie în funcţiune într-un
anumit moment de timp; availability – înseamnă probabilitatea ca un sistem să
fie disponibil continuu într-un anumit interval de timp)
 Deoarece datele şi sistemul de gestiune sunt distribuite în mai multe site-uri, atunci
când unul din site-uri s-a defectat, alte site-uri pot să continue să funcţioneze şi
utilizatorii să acceseze cel puţin o parte din date

Dezavantajele sistemelor de baze de date distribuite
 Complexitate mai ridicată (faţă de sistemele centralizate) privind
prelucrarea, administrarea și întreţinerea
 Dificultăţi suplimentare de proiectare și implementare (faţă de sistemele
centralizate) datorită necesităţii de prelucrare distribuită a interogărilor şi
de control al tranzacţiilor distribuite
 Securitatea necesită mecanisme speciale de protecţie (autentificare,
criptarea datelor) datorită comunicaţiilor prin reţea
 Dificultatea de menţinere a integrităţii datelor – care necesită operaţii în
reţea, care pot încărca mult capacitatea reţelei
 Lipsa de standarde pentru structurarea datelor şi comunicarea între
site-uri pentru distribuirea datelor
 Imaturitatea tehnologiilor şi a toolset-urilor de proiectare
 Lipsa de experienţă a personalului, datorită noutăţii tehnologiilor

Arhitectura sistemelor de baze de date distribuite
 Un sistem de baze de date distribuite constă din:
 O mulţime nevidă de site-uri de date (cu capacităţi de stocare a datelor și de
interogare) conectate în rețea
 O mulţime (posibil vidă) de site-uri de interogare, care nu au capacitate de
stocare a datelor, ci numai interfaţă de acces la site-urile de date

Clasificarea sistemelor de baze de date distribuite
 Clasificare după modul stocare a datelor
 Sisteme de baze de date pur distribuite: există o singură copie stocată a
datelor, posibil fragmentată în unităţi, distribuite în diferite site-uri
 Sisteme de baze de date distribuite cu replicare: există mai multe copii
(replici) ale datelor
 În general, se combina replicarea cu fragmentarea
 Clasificare după modul de distribuire a datelor:
 Sisteme de baze de date distribuite (omogene): datele şi sistemele de
gestiune din diferite site-uri sunt de acelaşi tip (omogene) ca model de date,
metode de acces, controlul concurenţei etc.
 Sisteme de baze de date multiple (heterogene - multi-database systems):
datele şi sistemele de gestiune din diferite site-uri pot fi de tipuri diferite
(heterogene) ca model de date, metode de acces, controlul concurenţei etc.);
poate fi definită totuşi o schemă globală a datelor (la fel ca şi pentru sistemele
de baze de date omogene)
 Sisteme de baze de date federalizate (federated database systems): compuse
din sisteme de baze de date autonome, pentru care nu este disponibilă o
schemă globală a datelor, dar pot comunica între ele prin import/export de
date
Sisteme de baze de date distribuite omogene
 Sistemul distribuit de
gestiune a bazelor de
date conţine:
 Catalogul global
 Monitorul de tranzacţii
globale
 Monitoarele de tranzacţii
locale
 Interfeţele de comunicaţie
includ software-ul de
rutare a interogărilor
distribuite între site-uri
 Fiecare site conţine
sistemul local de gestiune
(LDBMS) care
gestionează:
 Baza de date locală (LDB)
 Catalogul de date locale
(LCAT)
Sisteme de baze de date multiple
 Sistemele de baze de
date multiple
(multi-database systems)
conţin:
 Un centru de control
global care deţine
dicţionarul datelor globale
şi controlează accesul
global la date
 Mai multe site-uri
distribuite, fiecare site
având o bază de date
locală, un sistem de
gestiune local şi un nivel
local de acces
 Sistemele pot fi
heterogene, chiar ca
modele de date (ierarhice,
relaţionale etc.)
Sisteme de baze de date federalizate
 Sistemele de baze de
date federalizate
constau din mai multe
sisteme complet
autonome (şi posibil
heterogene) care
comunică între ele
 Nu există un dicţionar
global de date
 Fiecare catalog local
conţine tabelele de
sistem, vederile şi
indexurile locale
 Schema de export este
o parte a catalogului
local
 Schema de import este
reuniunea schemelelor
importate de la
celelalte site-uri
Fragmentarea tabelelor (1)
 Fragmentarea (partiţionarea) tabelelor:
 Fragmentare orizontală – se distribuie liniile tabelelor în site-uri diferite
 Fragmentare verticală – se distribuie coloanele tabelelor în site-uri diferite;
toate fragmentele conțin coloana cheie primară (PK – coloana c1 în figură)
 Fragmentarea hibridă

Fragmentarea tabelelor (2)
 Fragmentarea impune o anumită
unitate de distribuţie a datelor
 Tabelul nu este cea mai bună unitate,
deoarece aplicaţiile folosesc vederi
care sunt subseturi ale tabelelor
 Astfel de subseturi (fragmente) sunt
mai potrivite ca unităţi de distribuţie
 Fragmentarea permite:
 Execuţia în paralel a interogărilor prin
divizarea acestora în subinterogări
care operează pe fragmente
 Exploatarea localităţii datelor
(fragmentelor)
 Această formă de concurenţă se
numeşte concurenţă în interiorul 4 5 4 5
interogării (intraquery concurreny)
 Dezavantajul fragmentării: cost
suplimentar de transfer al fragmentelor
de la un site la altul Hybrid table fragmentation

Replicarea datelor
 Replicarea – replicarea tabelelor în fiecare din site-uri
 Replicarea totală a tabelelor
 Replicarea parţială a tabelelor  fragmentare (orizontală sau verticală),
împreună cu replicarea fragmentelor

Reprezentarea interogărilor
 Interogările transmise SGBD-urilor ca instrucț. SQL se pot exprima prin expresii de
algebră relaţională, care pot fi reprezentate prin arbori, în care frunzele sunt
operanzii (relaţii) și fiecare nod este o operaţie cu şi unul sau mai mulţi operanzi
 Exemplu: interogarea următoare cu instrucțiunea SQL dată poate fi exprimată
printr-o expresie de algebră relațională reprezentată prin arborele din fig. (a)
Care sunt numele şi prenumele furnizorilor din ‘Bucuresti’ care au livrat componenta
‘Rezistenta’ în cantităţi mai mari sau egale cu 200 ?
SELECT Nume, Prenume FROM FURNIZORI F, ACHIZITII A, COMPONENTE C
WHERE Adresa = ‘Bucuresti’ AND Denumire = ‘Rezistenta’ AND Cantitate ≥ 200
AND F.IdFurnizori = A.IdFurnizori AND C.IdComponente = A.IdComponente
Nume,PrenumeAdresa = ‘Bucuresti’ AND Denumire = ‘Rezistenta’ AND Cantitate ≥ 200 (F  (A  C))
(a)

Transformarea expresiilor algebrice (1)
 Expresiile de algebră relaţională se pot transforma în expresii echivalente
prin modificarea ordinii operaţiilor
 Eficienţa de execuţie variază foarte mult de la o expresie la alta, deci se pot
face optimizări ale interogărilor
 Cele mai importante transformări ale expresiilor algebrice sunt:
 Comutarea restricţiei (selecţiei) cu joncţiunea
 Comutarea proiecţiei cu joncţiunea
 Comutarea restricţiei cu joncţiunea se face pe baza proprietăţii de
descompunere a condiţiei de restricţie:
(b)
 Fie relaţiile R şi S şi expresia  = p AND q,
a. î. p conţine numai atribute din R și
q conţine numai atribute din S; atunci
următoarele expresii sunt echivalente:
(R S) = (p(R))(q(S))
 Aplicarea restricţiei înaintea joncţiunii se
numeşte “împingerea în jos a restricţiei”
 În figura alăturată (b) este dată o astfel de
transformare a expresiei algebrice precedente
Nume,Prenume((Adresa=‘Bucuresti’ (F))  (( Denumire=‘Rezistenta’(C)) (Cantitate ≥200 (A)))
Transformarea expresiilor algebrice (2)
 Comutarea proiecţiei cu joncţiunea se face pe baza proprietăţii:
 Fiind date relaţiile R(A,B) şi S(B,C) şi mulţimile de atribute M,N,L care
îndeplinesc condiţiile: B  M, B  N şi L  (M  N), se poate scrie:
L(R S) = L((M(R))  (N(S)))
 Această transformare
(c)
reprezintă o "împingere în
jos a proiecţiei", adică se
execută proiecţii parţiale
înaintea joncţiunilor
 În figura (c) este dată
transformarea expresiei
algebrice precedente prin
împingerea în jos a
proiecţiilor și a restricțiilor

Prelucrarea interogărilor
 Sistemele de gestiune primesc interogările în limbajul SQL, care descriu
concis şi simplu rezultatul dorit, nu procedura de calcul pentru obţinerea
acestuia; este sarcina unui modul al sistemului de gestiune, numit
procesorul de interogări :
 să transforme instrucțiunile SQL într-o expresie (procedură) de calcul
 să optimizeze expresia de calcul ţinând seama de modul concret de
organizare a datelor
 Optimizarea interogărilor este o problemă complexă chiar şi pentru
sisteme centralizate, şi deosebit de complexă pentru sisteme de baze
de date distribuite, în care mai apar fragmentarea şi replicarea
 Pentru optimizarea interogărilor se pot considera (în mod simplificat)
complexităţile operaţiilor algebrice din tabelul de mai jos, unde n este
cardinalitatea relaţiei (numărul de tupluri)
Operaţii Complexitate
Selecţia (restricţia), proiecţie fără eliminarea duplicatelor O(n)
Proiecţie cu eliminarea duplicatelor, joncţiune, diviziune, operaţii pe O(n x log n)

mulţimi (reuniunea, intersecţia, diferenţa)
Optimizarea interogărilor
 Conceptual, optimizarea interogărilor constă din alegerea celei mai bune
strategii (ordine de execuție a operaţiilor) din toate strategiile posibile
 Cea mai directă metodă de optimizare a interogărilor este de a căuta în
întreg spaţiul soluţiilor şi de a selecta soluţia cu cost minim
 Această metodă poate să consume un timp apreciabil, datorită faptului că
spaţiul soluţiilor este mare şi creşte cu numărul relaţiilor şi al fragmentelor
 Pentru evitarea costului prea mare al căutării soluţiei optime se pot folosi
diferite principii (heuristici), care restrâng spaţiul căutării şi se poate găsi o
soluţie aproape optimală într-un timp de căutare redus
 Simpla observare a valorilor complexităţilor operaţiilor algebrice de bază
sugerează diferite principii de optimizare a interogărilor:
 Deoarece complexitatea operațiilor depinde de dimensiunea relaţiilor, se va
încerca minimizarea dimensiunilor (cardinalitate, grad) rela țiilor intermediare
 Selecția reduce cardinalitatea rela ției
 Proiecția reduce gradul rela ției
 Operaţiile trebuie să fie ordonate în ordinea creşterii complexităţii
 Operaţia de selecţie are complexitatea cea mai mică, deci trebuie aplicată prima
 Produsul cartezian trebuie evitat sau întârziat cât mai mult
 Aceste principii au fost aplicate în exemplul precedent
Exemplu: Optimizarea unei interogări centralizate
 Fie un subset al schemei logice a unei baze de date care conţine relaţiile:
EMP (ENO, ENAME, TITLE)

PRJ (PNO, PNAME)
ASG (ENO, PNO, RESP, DUR)
 Interogarea: ”Care sunt numele angajaţilor care sunt manageri la un

proiect?” se exprima prin instrucţiunea SQL:
SELECT ENAME FROM EMP, ASG
WHERE EMP.ENO = ASG.ENO AND RESP = ‘Manager’
 Această interogare poate fi exprimată prin mai multe expresii algebrice:
(a)  ENAME(RESP = ‘Manager’ AND EMP.ENO = ASG.ENO(EMP x ASG))
(b)  ENAME(RESP = ‘Manager’ (ASG EMP))
(c)  ENAME(EMP  (RESP = ‘Manager’ (ASG)))
 Intuitiv, expresia (c), care evită produsul cartezian și execută mai întâi
selecția, este cea mai eficientă
 Procedura de optimizare din SGBD trebuie să determine exact care este
expresia optimă
Exemplu: Optimizarea unei interogări distribuite (1)
 Într-un sistem distribuit, procesorul de interogări:
 trebuie să adauge informaţiile privind fragmentarea şi operaţiile de transfer a
datelor între site-uri
 trebuie să selecteze care este procesorul cel mai potrivit să execute diferitele
faze a interogării distribuite
 Se consideră următoarea fragmentare orizontală a tabelelor EMP şi ASG:
EMP1 = ENO ≤ ‘E3’ (EMP) – memorat la Site 3
EMP2 = ENO > ‘E3’ (EMP) – memorat la Site 4
ASG1 = ENO ≤ ‘E3’ (ASG) – memorat la Site 1
ASG2 = ENO > ‘E3’ (ASG) – memorat la Site 2
 Rezultatul este aşteptat la Site 5; se vor analiza 2 strategii echivalente de
execuţie a interogării, prezentate în figura următoare
 O săgeată de la site i către site j etichetată R, înseamnă că relația R este
transferată de la site i la site j

Exemplu: Optimizarea unei interogări distribuite (2)
Site 5
result = EMP’1  EMP’2
EMP’1 EMP’2
Site 3 Site 4
EMP’1= EMP1  ASG’1 EMP’2= EMP2  ASG’2
ASG’1 ASG’2
Site 1 Site 2
ASG’1=  RESP = ‘Manager’(ASG1) ASG’2=  RESP = ‘Manager’(ASG2)
Strategia A - exploatează faptul că cele două tabele sunt fragmentate în acelaşi mod
Costul de execuţie estimat: 460 operații
Site 5
result = (EMP1  EMP2 )   RESP = ‘Manager’ (ASG1  ASG2)
ASG1 ASG2 EMP1 EMP2
Site 1 Site 2 Site 3 Site 4

Strategia B - se centralizează toate datele operanzilor înainte de a se executa interogarea
Costul de execuţie estimat: 23000 operații
Controlul concurenţei –Tranzacţii - recapitulare
 Chiar şi în sistemele centralizate, un SGBD deserveşte mai mulţi
utilizatori, care accesează concurent tabelele şi pot apare anomalii
 O tranzacţie (transaction) este o unitate logică de prelucrare a datelor
unei baze de date, care trebuie se asigure consistenţa acesteia
(corectitudinea operațiilor și respectarea constr ângerilor impuse)
 Pentru această comportare, tranzacţiile trebuie să aibă proprietă țile ACID :
 Atomicitatea (atomicity): proprietatea unei tranzacţii de a reprezenta o unitate
de execuţie indivizibilă, adică de a executa “totul sau nimic”:
 fie execută cu succes toate acţiunile şi se termină cu o validare a modificărilor
efectuate asupra bazei de date (commit)
 fie nu poate efectua (din diferite motive) toate acţiunile şi este abandonată şi
anulată (abort, rollback)
 Consistenţa (consistency): proprietatea unei tranzactii de a efectua modificări
corecte asupra bazei de date
 Izolarea (isolation): proprietatea unei tranzacţii de a face vizibile modificările
efectuate numai după ce a fost validată (committed)
 Durabilitarea (durability): proprietatea prin care, după validarea unei tranzacţii,
modificările efectuate de aceasta în baza de date nu vor mai fi pierdute
datorită unor defectări necatastrofice ulterioare a sistemului

Planificarea tranzacțiilor
 În orice SGBD se execută concurent mai multe tranzacții, care
accesează aceleași date memorate în baza de date
 O planificare (schedule, sau istorie - history) S a n tranzacţii
T1,T2,..Ti,...Tn este o ordonare a operaţiilor tranzacţiilor astfel încât:
 Pentru orice tranzacţie Ti care participă în S, operaţiile lui Ti în S respectă
ordinea iniţială din Ti
 Alte operaţii (ale altor tranzacţii Tj, unde j ≠ i) pot fi întreţesute cu operaţii ale
tranzacţiei Ti
 Două operaţii dintr-o planificare sunt conflictuale (conflicting operations)
dacă aparţin unor tranzacţii diferite, accesează acelaşi articol şi cel puţin
una dintre operaţii este operaţie de scriere
 Planificări seriale (serial schedules): o planificare S se numeşte serială
dacă pentru orice tranzacţie T participantă în planificare, toate operaţiile
din T se execută consecutiv în S; altfel, planificarea se numeşte
neserială
 Orice planificare seriala a unor tranzactii corecte este corecta, dar nu permite
întreţeserea operaţiilor şi concurenţa tranzacţiilor
 Planificările neseriale permit concurența tranzacțiilor, dar pot să inducă
inconsistența datelor din baza de date

Planificarea serializabilă a tranzactiilor
 O planificare a n tranzacţii se numeşte serializabilă, dacă este echivalentă
cu una din cele n! planificări seriale a celor n tranzacţii
 Două planificări sunt echiv. (d.p.v. al conflictelor) dacă oricare pereche de op
conflictuale se execută în aceeaşi ordine în cele două planificări
 Îm sistemele de baze de date cu utiliz multipli se fol planific serializabile,
care admit concurenţa, asigurând în aceelaşi timp consistenţa bazei de date
 Testarea echivalenței unei planificări date cu o planificare serială este
costisitoare, dar se poate asigura serializabilitatea prin controlul concurenţei
tranzacţiilor, care să asigure ordinea corectă de execuție
 Cele mai utilizate tehnici de control al concurenţei sunt:
 Tehnici bazate pe blocarea accesului la date prin zăvoare (locks)
 Tehnici bazate pe mărci de timp (timestamps)
 Un zăvor (lock) este o variabilă L(X) asociată cu un articol X al bazei de date
care descrie starea acelui articol în raport cu op. care i se pot aplica
 Un zăvor binar (binary lock) L(X) poate avea două stări:
 L(X) = 1 - liber (sau neblocat - free, unlocked) – se poate accesa articolul X
 L(X) = 0 - ocupat (sau blocat - busy, locked) – nu se poate accesa articolul X
 Asupra unui zăvor binar L(X) se pot executa două operaţii:
 Blocare: lock(X) – trece zăvorul L(X) în starea blocat (ocupat)
 Eliberare: unlock(X) – trece zăvorul L(X) în starea neblocat (liber)

Zăvoare binare
 Dacă o tranzacție T dorește să acceseze articolul X, ea trebuie să
execute operația lock (X) care testează starea zăvorului L(X) :
 Dacă zăvorul articolului X este liber (L(X) = 1), atunci tranzactia T:
 achiziţionează zăvorul (trecându-l în starea ocupat)
 execută operaţiile necesare asupra articolului X
 eliberează zăvorul (trcându-l in starea liber prin operaţia unlock)
 Dacă zăvorul articolului X este ocupat (L(X) = 0), atunci tranzacţia T:
 aşteaptă până ce acesta este eliberat (de o altă tranzacţie, care şi-a terminat
operaţiile de acces la acel articol),
 după care execută aceeaşi secvenţă de operaţii: blocarea zăvorului, execuţia
operaţiilor care accesează articolul respectiv şi eliberarea zăvorului
 Operaţia de blocare (lock) se executată ca operaţie indivizibilă (folosind
instrucţiuni speciale ale procesoarelor de tip TestAndSet)
 Tehnica zăvoarelor binare este prea restrictivă şi limitează în mod
nejustificat concurenţa în execuţia tranzacţiilor
 De exemplu, mai multe tranzacţii pot efectua operaţii de citire concurentă
asupra aceluiași articol, fără ca acest lucru să afecteze consistenţa bazei de
date, dar acest lucru este interzis în tehnica zăvoarelor binare
 De aceea, multe sisteme de gestiune a bazelor de date utilizează zăvoare
cu stări multiple
Protocolul de blocare în două faze
 Pentru a asigura serializabilitatea planificărilor tranzactiilor care implică
mai multe zăvoare, se foloseşte protocolul de blocare în două faze
(two-phase locking 2PL)
 Protocolul de blocare în două faze impune ca fiecare tranzacție să
respecte protocolul de utilizare a zăvoarelor și toate operaţiile de blocare
a zăvoarelor sa preceadă prima operaţie de eliberare a unui zăvor
 O astfel de tranzacţie poate fi divizată în două faze:
 faza de creştere (growing phase), în care pot fi achiziţionate noi zăvoare ale
articolelor care vor fi accesate, dar nici un zăvor nu poate fi eliberat
 faza de descreştere (shrinking phase), în care zăvoarele deţinute pot fi
eliberate, dar nici un alt zăvor nu mai poate fi achiziţionat.
 S-a demonstrat că, dacă fiecare tranzacţie a unei planificări respectă
protocolul 2PL, atunci planificarea este serializabilă
 Probleme care apar la utilizarea zăvoarelor:
 Impasul (deadlock): blocarea execuţiei tranzacţiilor atunci când două sau mai
multe tranzacţii se aşteaptă una pe cealălaltă ca să elibereze un zăvor; exista
tehnici de prevenire si de eliminare a impasului
 Amânarea permanentă (“înfometare”) - (livelock, indefinit postponement,
starvation): o tranzacţie se află în stare de amânare nedefinită dacă ea nu
poate continua execuţia o perioadă lungă de timp, în timp ce toate celelalte
tranzacţii se execută normal; prevenirea se face prin asigurarea unei politici
echilibrate de obtinere (blocare) a zavoarelor
Controlul concurenţei în bazele de date distribuite
 La prima vedere, ar părea că execuţia protocolului 2PL de către fiecare
planificator local de tranzacţii poate asigura serializabilitatea
planificărilor tranzacţiilor distribuite; dar acest mod de execuţie:
 Nu asigură decât serializabilitatea locală a tranzacţiilor
 Tranzacţiile globale distribuite pot să nu fie global serializabile, dacă, pentru
aceeași tranzacție, unele dintre site-uri execută commit, iar celelalte execută
abort (rollback)
 Soluţiile pentru evitarea acestei anomalii sunt:
 Protocolul 2PL distribuit (distributed 2PL)
 Protocoale de validare distribuită atomică (atomic distributed commit)
 Pentru protocolul 2PL distribuit este necesar un administrator global de
tranzacţii care să controleze când începe faza de cedare a zăvoarelor
 Protocolul 2PL distribuit are diferite variante:
 Protocol 2PL strict – cedarea zăvoarelor se face la validarea tranzacţiei
(commit); produce frecvent impas (deadlock), care trebuie rezolvat
 Protocol 2PL cu replicarea zăvoarelor – se face o replicare a zăvoarelor în
fiecare site; produce întârzierea execuţiei datorită necesităţii de control a
tuturor zăvoarelor în fiecare site

Protocoale de validare a tranzacţiilor distribuite
 Protocoalele de validare distribuită atomică (atomic distributed
commit) necesită un mecanism prin care toate serverele implicate
efectuează aceeaşi operaţie, fie commit, fie abort
 Un astfel de mecanism necesită:
 Componente de control global al tranzacţiilor distribuite – printre care un
proces coordonator (Global Transaction Monitor - GTM)
 Protocoale de validare a tranzacţiilor distribuite
 Într-o tranzacţie distribuită:
 Procesul coordonator cere tuturor serverelor participante la tranzacție să
voteze dacă pot valida tranzacţia (commit)
 Serverele participante votează pentru validarea sau anularea tranzacţiei
 Coordonatorul cere serverelor să valideze tranzacţia numai dacă toate au
votat pentru validare; altfel, le cere să anuleze tranzacţia
 Protocoalele folosite sunt:
 Validarea în două faze (two-phase commit - 2PC)
 Validarea în trei faze (three-phase commit – 3PC)

Protocolul de validare în două faze (2PC)
 Protocolul de validare în două faze este cel mai folosit (inclusiv în Oracle)
 Prima fază:
 Coordonatorul trimite tuturor participanţilor mesajul C-PREPARE, informându-i
să se pregătească de vot
 Fiecare server participant răspunde:
 Cu mesajul C-READY dacă este gata de a valida tranzacţia; după acest punct,
serverul nu mai poate anula tranzacţia decât dacă coordonatorul îi cere
 Cu mesajul C-REFUSE, dacă nu poate valida tranzacţia efectuată
 Faza a doua:
 Dacă coordonatorul a primit C-READY de la toate serverele, el transmite
mesajul C-COMMIT tuturor serverelor şi fiecare server va valida tranzacţia
 Dacă coordonatorul a primit C-REFUSE de la cel puţin un server, atunci el
trimite C-ROLLBACK tuturor serverelor şi fiecare server va anula tranzacţia
 Dacă toate serverele funcţionează corect şi nu există erori de reţea, 2PC
asigură validarea distribuită atomică a tranzacţiilor
 Totuşi, pentru a lua în seamă apariţia defectelor în cursul validării, sunt
necesare alte protocoale mai complexe (de exemplu 3PL)

Diagrama stărilor protocolului 2PC
 Coordonatorul trece în:
 Starea GLOBAL COMMIT,
dacă toate serverele au
votat validarea
 Starea GLOBAL ABORT,
dacă cel puţin un server a
votat abandonarea
 Participantul trece în:
 Starea LOCAL COMMIT,
dacă a primit de la
coordonator mesajul
C-COMMIT
 Starea LOCAL ABORT,
dacă a primit de la
coordonator mesajul
C-ROLLBACK

Protocolul de validare în trei faze (3PC)
 Protocolul 2PC produce blocarea, dacă un server care a votat pentru
validare nu primeşte nici-un răspuns de la coordonator, deci nu poate nici
valida, nici anula tranzacţia
 Protocolul 2PC poate fi făcut neblocant prin introducerea unei stări (faze)
suplimentare – PRE COMMIT STATE → protocolul în trei faze (3PC)
 În această stare procesele participante aşteaptă raspuns de la
coordonator (în starea READY) un timp predeterminat; dacă în acest
interval nu primesc nici un mesaj, se trece în LOCAL ABORT STATE

Baze de date Oracle distribuite
 Baze de date Oracle distribuite:
 Omogene - baze de date Oracle (eventual de diferite versiuni) conectate
 Heterogene - baze de date Oracle şi non-Oracle conectate
 Fiecare bază de date
dintr-un sistem distribuit
este identificată printr-un
nume global (public), care
se form. prin adăugarea la
numele acesteia a
numelui dom. de reţea
 O aplicaţie poate interoga
datele simultan din mai
multe locaţii:
 Se efectuează operaţii
(de ex. joncţiuni) în mod
transparent între tabele
locale şi tabele remote
 De exemplu, join între
tabelul PRODUCTS (din
baza de date MFC) şi
tabelul DEPT (din baza
de date HG)

Conexiuni (link-uri) între bazele de date Oracle
 O conexiune între două servere de baze de date Oracle (link) este o
legătură unidirecţională de la un server către celălalt
 Prin intermediul unui link, un utilizator poate accesa obiecte într-o bază
de date remote
 Un utilizator conectat la baza de date locală A
poate utiliza link-ul memorat în această bază de
date pentru a accesa informaţii din baza de
date remote B
 Userii conectaţi la baza de date B nu pot
accesa baza de date A prin acest link; trebuie
definit un alt link, în direcţie opusă

Replicarea şi integrarea datelor în sistemul Oracle
 Oracle oferă mecanisme standard pentru replicarea şi integrarea datelor şi
pentru comunicarea sigură între baze de date, aplicaţii şi utilizatori
 Pentru accesarea imediată şi directă, dar cu frecvenţă redusă, a datelor din
baze de date multiple (omogene sau heterogene) se folosesc tranzacţii
distribuite
 Pentru accesarea frecventă a datelor la diferite locaţii (site-uri) se foloseşte
replicarea datelor care se poate realiza cu:
 Oracle Stream (fluxuri de evenimente)
 Oracle Materialized Views (vederi materializate)
 Un flux de evenimente (Oracle Stream) asigură replicarea permanentă
(near real-time) a datelor
 Bazele de date transmit modificările către toate replicile în mod automat
 Se poate asigura echilibrarea încărcării reţelei (load-balancing)
 O vedere materializată (materialized view) este o replică (copie) a unui
tabel sau subset de tabele
 Vederile materializate nu replică datele în mod permanent, ci numai în anumite
momente, atunci când se efectuează anumite tranzacţii
 Sunt necesare atunci când lărgimea de bandă a reţelei de interconectare este
redusă
Tranzacţii distribuite în sistemul Oracle
 O tranzacţie distribuită include una sau mai multe instrucţiuni care
actualizează date din două sau mai multe noduri distincte dintr-o bază de
date distribuită
 Oracle foloseşte protocolul 2PC pentru gestiunea tranzacţiilor distribuite
 De exemplu, următoarea tranzacţie distribuită executată de userul scott
actualizează baza de date locală sales şi bazele de date remote hq, mfg
UPDATE scott.dept@hq.us.acme.com
SET loc = 'REDWOOD SHORES'
WHERE deptno = 10;
UPDATE scott.emp
SET deptno = 11
WHERE deptno = 10;
UPDATE scott.bldg@maint.us.acme.com
SET room = 1225
WHERE room = 1163;
COMMIT;

Oracle Stream
 Oracle Stream asigură partajarea și replicarea informaţiilor şi a
evenimentelor în interiorul unei baze de date sau între baze de date
diferite, ceea ce permite dezv. sistemelor de baze de date distribuite
 Oracle Stream constă din următoarele procese:
 Captare (capture): înregistrează modificările efectuate într-o bază de date
(baza de date sursă) în fişierul jurnal (redo log) al acelei baze de date și
într-o coadă de evenimente
 Evenimentul corespunzător unei modificări a bazei de date se numeşte
înregistrare de stare logică - LCR (logical state record)
 Propagare (staging): evenimentele sunt direcţionate de la o coadă la alta,
în aceeași bază de date sau în baze de date diferite (staging)
 Consumare (consumption): atunci când evenimentele ating destinaţia, sunt
consumate prin extragere din coadă de către un proces de aplicaţie (apply
process) care execută operaţiile indicate de eveniment

Replicarea datelor folosind Oracle Stream
 Atunci când se operează o modificare asupra unui obiect replicat, Oracle Stream
efectuează următoarele acţiuni:
1. Captează automat schimbările apărute şi le depune într-o coadă, formatate ca LCR
(logical change records)
2. Împinge (pushes) schimbările din coadă către toatre celelalte baze de date care conţin
obiectul replicat respectiv
3. Consumă în mod automat înregistr. LCR din coadă pt fiecare bază de date

Tipuri de replicare a datelor folosind Oracle Stream
 Cele mai folosite tipuri de replicare sunt:
 Replicarea între două baze de date
 Replicarea între mai multe baze de date
 Replicarea cu copie centrală (hub-and-spokes, “butuc şi spiţe”)
 Replicarea cu căi multiple (n-way)
 Replicarea între două baze de date
(a)
 Replicarea uni-direcţională – se admit
modificări numai într-una din bazele
de date, care se transmit celeilalte (a)
 Replicarea bi-direcţională – se admit (b)
modificări în ambele baze de date,
care se transmit celeilalte (b)
 Replicarea între mai multe baze de date cu copie centrală hub-and-spoke
 O bază de date centrală (copie centrală, “butuc” - hub) comunică cu mai multe
baze de date sec. (copii, replici, “spiţe” – spokes), care nu comunică între ele
 În copiile (nodurile) secundare se pot admite sau nu modificări ale datelor
 Dacă nu se admit modificări în copiile secundare, acestea sunt read-only
 Dacă se admit modificări în copiile secundare, acestea sunt read-write

Replicarea hub-and-spoke cu copii secundare
read-only (Oracle)
 Acest tip de replicare are următoarele componente de bază:
 Captare: numai nodul central conţine
un proces de captare, care
înregistrează modificările efectuate
asupra obiectelor partajate
 Propagare: nodul central (hub) propagă
modificările către fiecare din nodurile
secundare (spokes)
 Consumare: fiecare nod secundar
conţine un proces de aplicare care
aplică bazei de date modificările venite
de la nodul central

Replicarea hub-and-spoke cu copii secundare
read-write (Oracle)
 Dacă se admit modificări ale datelor în copiile secundare, atunci acestea
sunt trimise nodului central, care apoi le replică în celelalte noduri
 Captare: atât nodul central cât şi nodurile
secundare conţin câte un proces de captare
 Propagare:
 Fiecare nod secundar propagă modificările
captate numai către nodul central
 Nodul central propagă modificările din propria
copie către toate nodurile secundare, iar pe
cele primite de la un nod secundar, către toate
celelalte nodurile secundare
 Consumare: atât nodul central cât şi
nodurile secundare au câte un proces de
aplicare a modificărilor primite

Replicarea cu căi multiple (n-way) (Oracle)
 În replicarea cu căi multiple, fiecare bază de date comunică direct cu
fiecare dintre celelalte baze de date
 Modificările efectuate într-una din bazele de date sunt captate şi
propagate direct către fiecare din celelalte baze de date
 Fiecare bază de date conţine unul sau mai
multe procese de captare
 Fiecare bază de date poate propaga
modificările captate către fiecare din
celelalte baze de date
 Fiecare bază de date are câte un proces de
aplicare a modificărilor primite de la fiecare
din celelalte baze de date
 În astfel de replicare pot apare conflicte,
care trebuie rezolvate prin ordonarea
configurarea operaţiilor de aplicare

Replicarea folosind vederi materializate (Oracle) (1)
 O vedere materializată (materialized view) este o replică (copie) a unui

tabel master (sau un fragment al tabelului master) dintr-un site master
 Vederile materializate pot fi read-only sau read-write (updatable):
 Vederile materializate read-only admit acces numai pentru citirea tabelelor
copii locale ale tabelelor remote
 Vederile read-write admit atât citirea cât şi scrierea în copiile locale, iar aceste
modificări trebuie să fie sincronizate (refresh) la un moment dat
 Împrospătarea (refresh-ul) vederilor sincronizează datele din vedere cu
cele din tabelele master; se poate face:
 Refresh rapid – se transmit numai liniile din tabele care au fost modificate de
la ultimul refresh
 Refresh complet – actualizează întreaga vedere materializată

Replicarea folosind vederi materializate (Oracle)(2)
 În replicarea read-only clienţii execută interogări asupra vederii materializate
read-only şi pot modifica datele în masterul remote (a)
 În replicarea read-write clienţii pot executa atât interogări, cât şi modificări
locale, în vederea materializată (b)
 În ambele situaţii datele din vedere sunt împrospătate din tabelele master
(a) (b)

Baze de date distribuite în sistemul MySQL
 Un sistem de baze de date distribuite MySQL poate fi realizat prin:
 MySQL Cluster
 Replicarea datelor
 MySQL cluster – constă dintr-un set de calculatoare, fiecare executând
unul sau mai multe procese care pot fi:
 Servere MySQL
(SQL Nodes - cu
NDB storage
engine)
 Noduri de date
 Server de
management
(configurabil
printr-un client)
 Interfețe
(conectori) pentru
C, PHP, .NET
 Aplicaţii client

Replicarea datelor în sistemul MySQL
 MySQL suportă replicarea unidirecţională şi asincronă, în care un server
este master, iar celelalte sunt replici (copii, slaves)
 Replicarea MySQL este asemănătoare cu vederile materializate din
Oracle
 În MySQL replicarea se foloseşte pentru:
 Salvarea bazelor de date (backing up):
 se replică baza de date master într-o bază de date slave, care apoi este salvată
prin copiere pe disc sau pe bandă;
 serverul slave poate fi oprit (shutdown) pentru a obține chiar un snapshot al
datelor memorate
 Utilizarea de tipuri de tabele şi maşini de stocare diferite (deoarece aceşti
parametri nu se replică)
 Optimizarea timpilor de execuţie, prin distribuirea operaţiilor de interogare pe
mai multe servere

Baze de date distribuite în SQL Server
 Microsoft SQL Server 2008 folosește replicarea pentru copierea și
distribuirea datelor între baze de date diferite, aflate în loca ții la distan ță,
utilizând rețele locale, rețele wireless sau Internet
 Medii de replicare SQL Server:
 Replicare între servere (server-la-server)
 Replicare client-server
 Replicarea între servere folosește replicarea tranzacțională pentru:
 Integrarea datelor heterogene și/sau a datelor din locații (site-uri) diferite
 Creșterea disponibilității și a scalabilității datelor
 Pentru depozitarea datelor (data warehousing)
 Replicarea client-server folosește replicarea prin combinare (merge):
 Schimbul de date cu utilizatori mobili
 Integrarea datelor de la mai multi clienți
 Aplicații POS (Point Of Sales) – automate de banca, de verificare (check-in)

Replicarea tranzacțională (SQL Server 2008)
 Replicarea tranzacțională permite replicarea
între servere
 Folosește mecanismul publish-subscribe:
serverele publisher publică tranzacțiile de
replicat, iar serverele subscriber primesc
astfel de tranz, folosind un server distributor
 În publisher un agent de instantaneu
(snapshot agent) prepară fișierele care conțin
schema și datele publicate
 În distributor:
 Un agent de citire jurnal (log reader agent)
monitorizează jurnalele de tranzacții din bazele
de date configurate pentru replicare
tranzacțională și copiază tranzacțiile marcate
pentru replicare în baza de date de distribuire
 Un agent de distribuire (distribution agent)
copiază tranzacțiile din baza de date de
distribuire în bazele de date subscriber
 În subscriber sunt aplicate tranzacțiile primite
de la distribuitor
Baze de date şi World Wide Web
 Sistemul WWW este compus din clienţi care accesează datele oferite de
servere, conectate printr-o reţea de interconectare
 Clienţii sunt browsere care trimit cereri către serverele Web; acestea răspund
cu documente formate în limbajul HTML
 Transmisia foloseşte protocolul HTTP (Hypertext Transmission Protocol)
 Bazele de date pot fi conectate la un server Web, care extrage datele din
bazele de date şi le transmit clienţilor după prelucrarea corespunzătoare,
eventual prin intermediul unui server de aplicaţie
 Bazele de date sunt incluse în majoritatea aplicațiilor distribuite multinivel
(multilayer), constituind nivelul de date

Baze de date în sisteme Cloud Computing
 Cloud computing se referă la aplicații și servicii care se execută într-o rețea
distribuită de resurse virtualizate accesate prin protocoale standard în Internet
(Barrie Sosinsky, Cloud Computing Bible, Wiley Publishing, 2011)
 În cloud computing utilizatorul închiriază resursele de calcul necesare, iar
costurile sunt în funcție de cantitatea de resurse folosite (putere de calcul,
memorie, rețea de interconectare, timp de execuție etc.) – pay-per-use
 Pentru a se încadra în categoria cloud, un sistem trebuie să prezinte caract.:
 Abstractizare: cloud computing abstractizează modul de realizare a aplicațiilor:
utilizatorul cunoaște numai esențialul despre aplicații (ce execută) și poate ignora
detaliile de implementare (pe ce sisteme fizice rulează aplicația, cine asigură
administrarea sistemelor de calcul respective etc.)
 Virtualizarea: cloud computing virtualizează sistemele de calcul folosind resurse din
“bazine” (pools), posibil partajate; puterea de calcul și de stocare este aprovizionată
din infrastructuri centralizate (centre de date), cu posibilitatea de scalare rapidă
 Deși este bazat pe tehnologii existente de mai multă vreme: virtualizare, Internet,
sisteme distribuite (servicii), cloud computing reprezintă totuși o schimbare
importantă de modalitate de calcul, având caracteristica de calcul ca utilitate
(utility computing), pentru care se plătește în funcție de resursele utilizate
 În general, sistemele cloud permit accesul de oriunde și oricînd (prin Internet)
 În momentul de față există un număr mare de furnizori de servicii Cloud, inclusiv
baze de date, cum sunt Amazon, Google, Microsoft, Oracle, HP, IMB și alții
Modelul de livrare a serviciilor Cloud Computing
 Infrastructure as a Service: IaaS oferă mașini virtuale, memorie virtuală,
infrastructură de comunicație virtuală și orice dispozitiv hardware pe care
furnizorul îl poate pune la dispoziția cliențiilor
 Furnizorul IaaS administrează întreaga infrastructură, iar clientul este responsabil cu
toate celelalte aspecte ale execuției (sisteme de operare, biblioteci, aplicații etc.)
 Platform as a Service: PaaS oferă mașini virtuale, sisteme de operare, servicii
și toolset-uri de dezvoltare (development frameworks)
 Clientul deploy-ază propriile aplicații în platforma cloud, cu condi ția ca acestea să fie
dezvoltate folosind limbajele și bibliotecile suportate de platformă și le administrează
 Furnizorul PaaS administrează și întreține infrastructura de calcul, sistemul de operare,
toolset-urile de dezvoltare și serviciile oferite
 Software as a Service: SaaS este un sistem complet cu aplicații, servicii,
administrare și interfață utilizator (pentru client)
 Administrarea aplicației (serviciului) intră în responsabilitatea furnizorului
 Clientul poate folosi aplicația, dar nu o poate modifica sau administra
 Pe lângă tipurile de servicii de bază IaaS, PaaS și SaaS, mai există și alte tipuri
de servicii cloud (generic XaaS):
 Storage-as-a-service  Integration-as-a-service
 Database-as-a-service  Security-as-a-service
 Information-as-a-service  Management/governance-as-a-service
 Process-as-a-service  Testing-as-a-service
 Communication-as-a-service  Identity-as-a-Service
Serviciile Cloud de la Amazon: AWS (1)
 Serviciile Amazon Web Services (AWS) sunt axate în principal pe modelul IaaS
 Amazon este una dintre cele mai mari companii online de distribuție (retailer)
(cea mai mare este Wal-Mart), cu activitate începută în domeniul cărților și
ulterior diversificată în numeroase domenii, cu vânzări de $24.51 billion (2009)
 Infrastructura sa imensă, construită să acopere vârfurile cererilor clienților, a fost
rentabilizată prin închirierea capacităților nefolosite către utilizatori, după modelul
pay-per-use caracteristic sistemelor cloud computing
 Amazon folosește monitorul de mașină virtuală (hypervisor) Xen pentru crearea
serverelor virtuale destinate utilizatorilor
 În hypervisor se pot instanția mașini virtuale oferite de Amazon (AMI – Amazon
Machine Image), ca dispozitive virtuale (Virtual Appliances) care pot fi folosite pentru
orice fel de aplicații software distribuite și robuste
 Unele dispozitivele virtuale includ diferite programe și toolset-uri software, care se
execută în mașina virtuală pe infrastructura Amazon
 AWS se bazează pe arhitecturile SOA (cu protocol de comunicație SOAP) și REST (cu
protocol de comunicație HTTP)

Serviciile Cloud de la Amazon: AWS (2)
 Serviciile AWS (Amazon Web Services - http://aws.amazon.com/products/) se
încadrează în mai multe categorii:
 Infrastructură de calcul
 Amazon Elastic Compute Cloud (EC2; http://aws.amazon.com/ec2/), este serviciul
central în structura AWS; el permite crearea, utilizarea și managementul serverelor
virtuale (Linux sau Windows) executate ca instanțe de mașini AMI (Amazon Machine
Image) în hypervisor Xen. Acestea pot fi dimensionate pe diferite niveluri (putere de
calcul, memorie, interconectare) și închiriate (calcul/oră)
 Amazon Elastic Block Store (EBS; http://aws.amazon.com/ebs/) - serviciu pentru
creare volume (disk) virtuale care pot fi folosite în instanțe de mașini virtualeîn EC2
 Amazon Elastic MapReduce (http://aws.amazon.com/elasticmapreduce/) - serviciu
pentru prelucrarea eficientă a volumelor mari de date în infrastructura Amazon
 Servicii care optimizează execuția serverelor virtuale: monitorizare - Amazon
CloudWatch (http://aws.amazon.com/cloudwatch/), scalare automată – Amazon
AutoScale, echilibrarea încărcării – Amazon Elastic Load Balancing
 Stocarea datelor
 Amazon Simple Storage System (S3; http://aws.amazon.com/s3/)
 Amazon SimpleDB (http://aws.amazon.com/simpledb/)
 Amazon DynamoDB (http://aws.amazon.com/dynamodb)
 Amazon Relational Database Service (RDS; http://aws.amazon.com/rds/)
 Alte servicii :
 AWS Import/Export - import/export rapid de date
 Amazon Cloudfront (http://aws.amazon.com/cloudfront/) – livrare de conținut
Baze de date Amazon AWS
 În sistemele AWS se poate alege o bază de date potrivită (și optimizată) pentru
diferite cerințe (ca volum de date și viteză de prelucrare)
 Baze de date gestionale de utilizator - se poate folosi o instanță Amazon EC2

pentru a executa un SGBD, iar baza de date (datele persistente) se memorează
în volume EBS (Elastic Block Store)
 Se poate folosi direct un dispozitiv AMI care include un SGBD; de exemplu:
 AMI - PostgreSQL - Object-relational Database System powered by TurnKey Linux
 AMI - MySQL - Relational Database Management System powered by TurnKey Linux
 AMI - MongoDB 2.4
 AMI - Cloud Data Warehouse
Amazon S3 și Simple DB
 Serviciul Amazon Simple Storage System (S3) memorează obiecte de dim. de
la 1 Byte la 5 TeraByte, fiecare obiect inclus într-un container (bucket)
 Un bucket poate fi memorat într-una din mai multe regiuni, în funcție de cerin țele de
optimizare; bucket-urile și obiectele pe care le conțin nu părăsesc niciodată regiunea
în care au fost memorate, decât dacă utilizatorul face un transfer explicit
 Pentru fiecare obiect sunt stabilite mecanisme de autentificare și de autorizare (cine
are dreptul să le acceseze și cum se identifică cel care îl accesează)
 Operațiile de upload/download a datelor în/din Amazon S3 se fac prin protocol HTTPS,
cu criptare SSL
 Amazon S3 asigură durabilitatea datelor prin memorarea acestora cu redundanță, în
mai multe dispozitive (calculatoare) din zona de disponibilitate, cu verificarea sumei de
control (checksum) la fiecare operație cu rețeaua
 Serviciul Amazon SimpleDB memorează colecții de articole reprezentate prin
perechi atribut-valoare
 Amazon SimpleDB a fost proiectat pentru a asigura memorarea și regăsirea rapidă
pentru seturi mici de date, reprezentate fără schemă și ne-relațional, ceea ce oferă
simplitate în gestionare
 Dimensiunea setului de date este limitată la 10 GB
 Datele sunt scalabile și sigure (durabile) datorită replicării (copii multiple)
 Se pot efectua tranzacții simple prin operații INSERT, REPLACE, DELETE asupra
valorilor atributelor folosind un mecanism de control optimist al concuren ței bazat pe
mărci de timp, fără operații ROLLBACK
 Serviciul SimpleDB se poate integra cu EC2 și cu S3
Amazon DynamoDB și RDS
 Serviciul Amazon DynamoDB este recomandat pentru aplicații de baze de date
NoSQL care suportă volume mari de date, cu timp de răspuns rapid, dar fără
interogări complicate, dat fiind că nu suportă joncțiuni sau tranzacții
 DynamoDB reprezintă datele sub formă de tabele, dar fără o schemă fixă, ci numai cu
o cheie de identificare pentru fiecare set de date (linie în tabel)
 Amazon DynamoDB scaleză automat capacitatea de stocare și de acces la date prin
partiționarea datelor și replicarea lor în mai multe servere din mai multe zone de
disponibiliate din aceeași regiune
 Această organizare oferă în același timp disponibilitate ridicată (cel puțin una din replici
este disponibilă) și durabilitate (refacerea datelor din copii multiple)
 Serviciul Amazon Relational Database Service (Amazon RDS) este un serviciu
care permite instalarea și operarea unei baze de date relaționale în cloud
 Din AWS Management Console se poate lansa ca instanță de bază de date unul din
sistemele de gestiune MySQL, Oracle, Microsoft SQL Server, PostgreSQL
 Conectarea la sistemul de gestiune se face prin toolset-urile standard ale fiecărui
SGBD, care lucrează nemodificat în AWS (MySQL Workbench sau mysql pentru
SGBD-ul MySQL, Oracle SQL Developer pentru Oracle etc.)
 RDS asigură scalabilitate – capacitatea de memorare se pot scala prin rezervarea de
memorie persistentă până la 3 TB
 Siguranța datelor – folosind salvări automate, snapshots, înlocuirea automată a
serverului (în caz de funcționare incorectă)

Aplicații și tehnologii Google Cloud Platform
 Google este prototipul de companie de servicii cloud computing și găzduiește
unele dintre cele mai mari site-uri Web și servicii din lume
 În centrul activității companiei se află tehnologia de căutare prin indexarea
paginilor Web, prin care Google pune gratuit la dispoziția utilizatorilor o mașină
de căutare standard, iar pentru dezvoltatori, o colecție de toolset-uri de căutare
pentru diferite domenii de activitate
 Mare parte din profitul companiei provine din publicitatea direcționată bazată pe
informațiile pe care Google le culege din activitățile utilizatorilor cu cont Google
sau prin cookies pe care le plasează pe calculatoarele utilizatorilor
 Google controlează 65% din piața de căutare pe Internet și în 2009 veniturile au fost
de $23.6 billion (miliarde)
 Profitabilitatea companiei a permis ca aceasta să-și dezvolte o infrastructură de
calcul imensă și să lanseze numeroase servicii și aplicații de cloud computing
 Google oferă mai multe modele de cloud, cu aplicații în diferite domenii
(publicitate, livrare conținut media, interacțiune socială etc.)
(https://developers.google.com/):
 SaaS - Google Apps
 IaaS - Google Compute Engine
 PaaS - Google App Engine
 DBaaS - Google Cloud Storage (blob), Google Datastore (tree), Google Cloud SQL
Google Cloud Storage și Cloud Datastore
 Google Cloud Storage asigură stocarea datelor ca obiecte (blob) în
infrastructura Google; în Google Cloud Storage datele aparțin unui proiect și
fiecare utilizator poate avea unul sau mai multe proiecte
 În proiect, obiectele blob sunt stocate într-un container (bucket); se pot insera mai
multe bucket-uri într-un proiect, cu posibilități de control individual al fiecărui bucket,
dar într-o structură plată (flat), nu sunt admise ierarhii de bucket-uri (bucket în bucket)
 Google Cloud Datastore este un serviciu DBaaS care permite stocarea datelor
sub formă de obiecte (entități) cu identificatori (chei), organizate într-o structură
ierarhică (arborescentă), similară structurii directoarelor dintr-un sistem de fișiere
 Entitatea rădăcină (root entity) poate avea mai mulți fii, care la rândul lor au al ți fii etc.
 Entitățile care au un ascendent comun formează un grup
 Datastore este extrem de rezistent la defecte (chiar catastrofice, dacă acestea nu apar
simultan în toate centrele de date în care sunt replicate entitățile)
 Consistența (toate datele actualizate) și tranzacționalitatea (operații ACID):
 Interogările care se referă la un singur grup asigură consisten ța și tranzac ționalitatea
 La interogările care se referă la grupuri diferite, este posibil să apară inconsisten țe

Google Cloud SQL
 Google Cloud SQL este un serviciu DBaaS care permite crearea, configurarea și
utilizarea unei baze de date relaționale stocată în infrastructura Google
 Google Cloud SQL poate fi folosit direct sau din aplicații Google App Engine
https://developers.google.com/cloud-sql/
https://developers.google.com/appengine/docs/java/cloud-sql/
 Google Cloud SQL se bazează pe SGBD MySQL, ceea ce permite transferarea
datelor și aplicațiilor din infrastructura locală (cu server MySQL) în cloud și
invers, cu înaltă portabilitate
 Caracteristicile Google Cloud SQL
 Ușurința în utilizare – datorită unei interfețe grafice care permite crearea, configurarea
și monitorizarea bazei de date Google Cloud SQL
 Administrarea este asigurată de furnizor (Google) (replicarea, copiile de rezervă etc.)
 Configurare flexibilă – utilizarea instanțelor mici costă $0.025 pe oră, iar trecerea la
capacități mai mari se face rapid, fără a necesita rezervare
 Disponibilitate ridicată (high availability) datorită replicării datelor în diferite centre
 Integrare cu App Engine și alte servicii Google
 Securitate excepțională asigurată pentru fiecare componentă

Microsoft Cloud Services
 Microsoft deține un bogat portofoliu de servicii cloud, aflat în continuă dezvoltare
 Serviciile cloud Microsoft sunt cuprinse în:
 Platforma Microsoft Azure (http://azure.microsoft.com/en-us) care constă din mai
multe componente (fig. de mai jos); oferă servicii și aplicații accesibile prin Internet care
se execută în centrele de date Microsoft
 Windows Live Services – colecție de aplicații și servicii cloud (bazate pe model SaaS)

Azure Data Management
 Azure Data Management oferă servicii de stocare a datelor: obiecte blobs (binary
large objects), tabele (tables) și baze de date
http://www.windowsazure.com/en-us/develop/net/fundamentals/cloud-storage/
 În tabelul de mai jos sunt date câteva caracteristici ale acestor servicii
TDS: Tabular Data Protocol, OData – Open Data Protocol

Azure Storage Blobs și Storage Tables
 Azure Storage Blobs conțin date binare nestructurate de orice dimensiune
(până la un terabyte), pot avea metadata și sunt incluse in containere
 Containerele sunt organizate într-o ierarhie simplă, pe care instanțele de execuție
(aplicațiile) le accesează
 Obiectele blob sunt replicate (3 replici) în regiunea respectivă
 Azure Storage Tables sunt mecanisme de stocare și accesare a datelor, dar nu
sunt date relaționale (deși numele ar putea sugera acest lucru) ci date NoSQL
 Tabelele Azure memorează datele în modelul cheie-valori (key/values), asociind un set
de valori cu o cheie
 Fiecare tabel poate fi partiționat și memorat replicat în mai multe mașini distincte
 Avantajele tabelelor Azure: tabelele pot fi foarte mari (până la 100 Terabytes) și permit
acces rapid la date
 Dezavantajele tabelelor Azure: spre deosebire de bazele de date relaționale, tabelele
Azure nu oferă suport pentru tranzacții sau proceduri stocate

Azure SQL Database
 SQL Database este serviciul DBaaS de baze de date relaționale de la Azure
 SQL Database nu creează câte o instanță de server SQL pentru fiecare utilizator,
ci unul sau mai multe servere care pot fi închiriate mai multor clienți
 Fiecare bază de date este replicată de trei ori, pe trei computere separate în
cadrul aceluiași centru de date, ceea ce asigură datelor o înaltă disponibilitate
 Pentru o aplicație, Azure SQL Database este similar cu un SQL Server:
 se pot defini proceduri stocate în limbajul Transact-SQL,
 se pot executa interogări ale datelor din tabelele relaționale
 se pot executa tranzacții
 Se pot replica baze de date SQL Database în centre de date diferite folosind
serviciul SQL Sync

Azure SQL Server in a VM
 Azure permite execuția unui SQL Server într-o mașină virtuală Azure - o aplicație
executată într-o mașină virtuală poate accesa date gestionate de un SGBD (SQL
Server) executat în altă mașină virtuală
 Utilizatorul are impresia că datele sunt memorate pe un disk local în VM în care se
execută serverul SGBD
 În realitate, fiecare astfel de disc este un Azure blob
 Ca orice blob, datele pe care le conține sunt replicate de 3 ori în același centru de date
sau în centre de date diferite din aceeași regiune
 Acest mod de stocare oferă disponibilitate și siguranță în stocarea datelor

Baze de date distribuite
 Angelo R. Bobak, Distributed and Multi-Database Systems, Artech
House, 1995
 Oracle 11g, 12c Documentation
 Oracle Database Administrator's Guide
 Oracle Database Data Replication and Integration Guide
 [Velte, 2010] - A.T Velte, T.J. Velte, R Elsenpeter: Cloud Computing – Practical
Approach, McGrow Hill, 2010
 [Sosinsky, 2011] - B. Sosinsky: Cloud Computing Bible, Wiley Publishing, 2011
 Resurse Web:
 http://www.windowsazure.com/
 https://aws.amazon.com/
 https://cloud.google.com/

Capitolul 9 – Depozite de date (Data Warehouse)
 Definiţii: Business Intelligence, Data Warehouse, OLAP
 Arhitectura unui depozit de date
 Modelul logic dimensional pentru depozite de date: schema stea
 Dimensiuni, ierarhii, niveluri
 Cube
 Indexuri
 Oracle Data Warehouse (ODW)
 Implementarea relaţională a modelului stea în ODW
 Interogări în reprezentarea stea – transformarea stea
 Oracle Date Warehouse Builder
 OLAP şi Data Mining
 Suport pentru depozite de date în alte SGBD-uri
 MySQL
 PostgreSQL
 Microsoft SQL Server
Prof. Felicia Ionescu Depozite de date (Data Warehouse) 1

Business Intelligence
 Business Intelligence (BI) este abilitatea unei întreprinderi de a studia
comportarea şi acţiunile trecute, cu scopul:
 de a stabili poziţia şi situaţia curentă a organizaţiei şi
 de a prezice sau modifica ceea ce se va întâmpla în viitor
 BI foloseste depozitele de date (data warehouse) care conţin informaţii
necesare pentru luarea deciziilor prin sisteme:
 Decision Support Systems (DSS)
 On-Line Analytical Processing (OLAP)
 BI şi data warehouse se înscriu în domeniul mai general “Corporate
Information Factory” (CIF), care s-a dezvoltat în ultimii 20 ani
 Aceste sisteme au îmbunătăţit sistemele de informaţii executive
(Executive Information Systems - EIS), folosite pentru analiza activităţii
de către conducerea organizaţiilor
 ERP – Enterprise Resource Planning – un subsistem al BI, care se ocupă
de planificarea resurselor folosind, de asemenea, data warehouse

Evoluția tehnologiilor de Business Intelligence
 BI se bazează pe data warehouse, care trebuie să suporte:
 Tehnologii de prelucrare multiple: interogări, rapoarte (Executive Information System
- EIS), analiză multidimensională, prelucrarea analitică online (Online Analitical
Processing - OLAP), extragerea informațiilor (data mining), explorarea datelor
 Niveluri de granularitate multiple: atât date detaliate (pentru opera ții tranzac ționale),
cât și date agregate (rezumate - pentru opera ții de analiză și explorare)

Depozite de date (Data Warehouse)
 Un depozit de date este o colecţie de date orientate pe subiect
(subject-oriented), integrate, non-volatile, variabile în timp (timevarying),
care constitue suport pentru luarea deciziilor într-o întreprindere
(organizaţie)
 Orientarea pe subiect:
 In general, depozitele de
date sunt organizate în
jurul aplicaţiilor funcţionale
ale companiei
 De exemplu, pentru o
companie de asigurări
aplicaţiile sunt orientate
pentru auto, viaţă,
sănătate, şi depozitele de
date se construiesc pe
aceste subiecte

Caracteristicile depozitelor de date (1)
 Datele sunt integrate:
 Depozitele sunt alimentate
dintr-o multitudine de
surse separate
 La alimentare, ele sunt
curăţate, convertite,
transformate, rezumate
 Rezultă o singură imagine
integrată a datelor pentru
intreaga companie
 Datele sunt stocate astfel
încât să faciliteze
utilizarea lor în mai multe
aplicaţii
 Se respectă convenţii de
nume, de structură, de
măsuri

Caracteristicile depozitelor de date (2)
 Datele sunt nonvolatile
 În depozite datele se
încarcă în anumite
momente de timp şi sunt
stocate pe perioade lungi
de timp
 Depozitele de date
stochează date istorice
 Datele sunt semnificative
pentru un anumit moment
de timp (time-variancy)
 De aceea înregistrările
contin o informaţie privind
momentul sau perioada
de timp pentru care sunt
valabile

Granularitatea datelor în depozite
 Este un aspect important în proiectarea depozitelor de date, deoarece
determină volumul ocupat de date
 Granularitatea se referă la nivelul de detaliu (sau de rezumare) a unei
unităţi de date din depozit:
 Cu cât nivelul de detaliu este mai mare, cu atât granularitatea este mai mică
(mai fină) – de ex. o simplă tranzacţie este de granularitate mică
 Cu cât rezumarea este mai puternică, cu atât granularitatea este mai mare;
de ex. suma tuturor tranzacţiilor dintr-o lună, an etc.

Niveluri de granularitate multiple
 Nivelul de granularitate fină (detaliere mare) se foloseşte în bazele de
date operaţionale şi ca date nerezumate (sau slab rezumate) în depozite
 Pe nivelul de granularitate ridicat (date puternic rezumate) se pot stoca
date pe perioade îndelungate şi se folosesc pentru decizii de organizare

Structura unui depozit de date
 Se pot identifica mai multe niveluri de structură ale unui depozit de date:
nivelul vechi, curent, uşor rezumat, puternic rezumat

OLTP - OLAP
 În mod tipic, depozitele de date se menţin separat de bazele de date
curente (operaţionale) deoarece:
 Bazele de date operaţionale suportă prelucrarea tranzacţiilor (On-Line
Transaction Processing – OLTP)
 Tranzacţiile sunt operaţii atomice care accesează (în general) un număr mic
de înregistrări, pentru operaţiile zilnice ale întreprinderii
 Bazele de date operaţionale sunt proiectate să maximizeze numărul de
tranzacţii/secundă (throughput) şi să minimizeze conflictele concurenţiale
 Depozitele de date suportă prelucrarea analitică a datelor (On-Line
Analitical Processing - OLAP)
 Depozitele de date conţin date consolidate, rezumate din mai multe baze de
date operaţionale, pe perioade de timp îndelungate
 Depozitele de date sunt mult mai mari (cu cel puţin un ordin de mărime)
decât bazele de date operaţionale
 Cerinţele OLAP diferă de cerinţele OLTP

Comparaţie OLTP – Data Warehouse
 Operaţii tipice:
 În OLTP se accesează un număr mic de înregistrări
 În depozite de date se accesează mii sau milioane de linii
 Modificarea datelor:
 Sistemele OLTP sunt în permanenţă la zi, actualizate de utilizatori
 În depozitele de date detele sunt actualizate regulat de către procesul ELT
(Extract, Load, Transformation)

Arhitectura unui depozit de date (1)
 Descrierea datelor  metadata, stocate într-un repertoriu (repository)
 Toolset-uri de monitorizare şi administrare

Arhitectura unui depozit de date (2)
 Colectarea datelor în depozite implică:
 Extragerea datelor din baze de date operaţionale multiple şi din surse externe
 Curăţarea (cleanup), transformarea şi integrarea datelor
 Încărcarea datelor (load)
 Împrospătarea datelor (refresh); preluarea noilor date din surse; transferul
datelor învechite către alte suporturi de date mai lente
 Datele din depozite sunt gestionate de unul sau mai multe servere de
depozite (warehouse servers)
 Mai există şi centre de date (data marts) care conţin date specifice
anumitor departamente şi servere pentru acestea (data mart servers)
 Depozitele şi centrele de date reprezintă datele de intrare pentru
toolset-uri de:
 Interogare
 Analiză (OLAP)
 Explorare (data mining)

Modelul dimensional pentru depozite de date
 Cel mai răspândit model conceptual pentru depozitele de date este
modelul dimensional care specifică un set de “subiecte”; acestea:
 pot fi definite prin valori numerice („măsuri”)
 sunt analizate în sistemele de decizie
 Exemple de subiecte (facts): vânzări, buget, venit, inventar
 Fiecare măsură (measure, subject, fact) depinde de un set de dimensiuni
 De exemplu, pentru “măsura” vânzări (SALES), dimensiunile pot fi: numele
produsului, orașul, data (calendaristică)
 O dată din modelul dimensional poate fi văzută ca un punct (valoare) într-un
spaţiu multidimensional
 Orice subiect poate fi agregat pe oricare dintre dimensiuni; de exemplu
vânzările totale pe o anumită regiune, perioadă de timp sau produs

Schema logică a depozitelor de date
 Pentru sistemele OLTP se folosesc scheme logice deduse din diagrama
E-A (Entitate-Asociere)
 În depozite de date şi sisteme OLAP se foloseşte modelarea dimensională
 Modelul dimensional se poate
reprezenta prin:
 Schema star (stea)
 Schema snowflake (fulg de zăpadă)
 Schema constellation (constelaţie)
 Implementarea schemei stea (star):
 multidimensional
 relaţional
 În implementarea relaţională a
schemei stea, baza de date constă din:
 o tabelă corespunzătoare subiectului
sau măsurii (fact table)
 câte o tabelă pentru fiecare dimensiune

Oracle Data Warehouse (ODW)
 În Oracle 11g se pot construi depozite de date care se folosesc pentru:
 Raportări şi analize
 Prelucrarea analitică (OLAP)
 Explorarea datelor (data mining)
 În ODW se foloseşte
preponderent:
 Schema stea pentru
proiectarea logică a
depozitului
 Implementarea relaţională
a schemei stea

Modelul dimensional în ODW
 Modelul dimensional se defineşte printr-un CUBE, care conţine una sau
mai multe măsuri (measures), determinate de mai mulţi parametri, fiecare
descris printr-o dimensiune
 Ca măsuri (ale unei activităţi) sunt considerate producţia, vânzările, profiturile,
şi orice alt indicator care poate fi monitorizat
 Fiecare dimensiune defineşte atributele dimensiunii, nivelurile de
agregare, şi ierarhia intre niveluri
 Ca dimensiuni sunt
considerate timpul, distribuţia
geografică a clienţilor,
canalele de distribuţie,
departamente, şi orice alt
element care influenţează
activitatea respectivă
 Modelul dimensional poate fi
reprezentat printr-o schemă
stea

Cube - în ODW
 Datele unui CUBE pot fi interpretate diferit de grupuri de utilizatori prin
decuparea “feliilor” din cub pe diferite dimensiuni:
 Managerii regionali: studierea “feliilor” orientate pe pieţe regionale (market);
 Managerii de producţie: studierea “feliilor” orientate pe produs (product);

Oracle Warehouse Builder (OWB)
 OWB permite proiectarea şi construirea depozitelor de date, a centrelor
de date (data mart) şi a aplicaţiilor BI (Business Intelligence)
 OWB conţine un set de instrumente grafice care asistă utilizatorul în
proiectare, pentru crearea obiectelor memorate într-un spaţiu de lucru
(workspace) memorat în baza de date Oracle
 Toolset-ul Design Center permite importul obiectelor sursă şi proiectarea
proceselor ETL şi a obiectelor de corespondenţă (mapping)
 Un mapping (mapare) defineşte un flux de date de la sursă la depozitul ţintă
(target warehouse)
 OWB generează codul pentru extragerea, transferul şi încărcarea datelor
(procesul ETL)
 Toolset-ul Repository Browser asigură o interfaţă Web pentru inspectarea
metadata din depozit
 Control Center Service – controlează deployment-ul bazei de date target
 Schema depozitului creat (target schema) conţine: codul generat,
cuburile, dimensiunile, tabelele, vederile, mapările şi pachetele care
execută procesul ETL

Componentele OWB

Exemplul SALES_WH în toolset-ul Data Center

Exemplu de schemă stea: SALES_WH
 Schema stea
conţine:
 CUBE – SALES
 Dimensiunile:
 PRODUCTS
 PROMOTIONS
 CUSTOMERS
 CHANNELS
 TIMES

Proiectarea unui CUBE
 CUBE – SALES din modulul
SALES_WH, proiectul
OWB_DEMO
 Defineşte măsurile:
 AMOUNT
 QUANTITY
 COST
 Referă dimensiunile:
 TIMES
 PRODUCTS
 CHANNELS
 CUSTOMERS
 PROMOTIONS

Proiectarea dimensiunilor
 O dimensiune constă din:
 Atribute ale dimensiunii – fiecare atribut având nume şi tip (de date)
 Un set de niveluri şi un set de ierarhii definite pe aceste niveluri
 Un nivel defineşte un grad se agregare pe dimensiunea respectivă şi
fiecare nivel are 2 identificatori:
 Identificator surogat – identifică unic fiecare nivel în cadrul nivelelor
dimensiunii (compus dintr-un singur atribut, asemănător cheii primare
artificiale a tabelelor relaţionale)
 Identificator business - alcătuit din unul sau mai multe atribute ale nivelului
(asemănotor cheii primare naturale a tabelelor relaţionale)
 O ierarhie este o structură care ordonează nivelurile unei dimensiuni,
definind asocieri de tipul părinte-fiu
 Exemplu: dimensiunea PRODUCTS din depozitul SALES_WH, care
poate fi studiat cu toolset-ul Design Center (din Oracle Warehouse
Builder), lansând Data Object Editor

Exemplu: dimensiunea PRODUCTS (1)

Exemplu: dimensiunea PRODUCTS (2)
 Fiecare nivel are o
denumire:
 PRODUCT
 SUBCATEGORY
 CATEGORY
 TOTAL
 Fiecare nivel are un set
de atribute:
 este un subset al
setului de atribute ale
dimensiunii
 conţine identificatorii
surogat şi business
 Ierarhia de niveluri (cu
numele PROD_STD)

Exemplu: dimensiunea CUSTOMERS

Implementarea relaţională a schemei stea
 Pentru implementarea relaţională a schemei stea a unui depozit de date
se definesc:
 Tabele de subiecte (fact table) – un fact table pentru fiecare schemă stea;
tabelul fact corespunde unui cube din proiectul logic
 Tabele de dimensiuni (numite şi tabele de referinţă) – care corespund
dimensiunilor din proiectul logic
 Asocierile (relationships)
sunt definite între tabelul
fact şi tabelele de
dimensiuni, prin chei
străine din tabelul fact
 Cheia primară a tabelului
fact este, de regulă, o
combinaţie a cheilor
străine care referă cheile
primare din tabelele de
dimensiuni

Implementarea relaţională a dimensiunilor
 Tabelul corespunzător
unei dimensiuni:
 Memorează date pentru
toate nivelurile
dimensiunii
 Conţine o cheie primară
care este referită de
tabelul fact (implem. a
măsurii – cube)
 Coloanele tabelului
corespund atributelor
nivelurilor dimensiunii
 Numele unei coloane se
obţine prin prefixarea
numelui atributului cu
numele nivelului
 Exemplu: tabelul
PRODUCTS

Implementarea relaţională a unui CUBE
 CUBE SALES îi
corespunde tabelul
relaţional SALES în
care:
 Fiecărei măsuri îi
corespunde o
coloană
 Fiecare tabel de
dimensiune este
referit printr-o cheie
străină

Încărcarea datelor în depozit
 Încărcarea datelor din fişiere sau tabele sursă în baza de date ţintă
(target) se face prin operaţiile de extragere, transformare şi încărcare
(operaţiile ETL)
 Operaţiile ETL se definesc în mapări (mapping)
 O mapare este compusă din operatori şi poate fi definită în cadrul OWB
 Operatorii folosiţi de OWB:
 Operatori sursă/target Oracle – reprezintă obiecte Oracle (tabele, vederi etc.)
 Operatori sursă/target non-Oracle sau remote
 Operatori de flux de date (data-flow) – definesc transformările datelor
 Operatori pre sau post mapping
 Operatori de grupare (pluggable maping operators)
 De exemplu, maparea LOAD_CHANNELS din modulul SALES_WH
 Operatorul CHANNELS_IN este legat (BOUND) la tabelul CHANNELS
 Operatorul CHANNELS_OUT este legat la dimensiunea CHANNELS
 Sunt definite corespondenţe între atributele operatorilor

Exemplu: maparea LOAD_CHANNELS

Proiectarea proceselor flux
 Un proces flux (flow process) asigură execuţia operaţiilor ETL, conform
mapărilor definite

Deployment-ul şi încărcarea datelor în OWB
 Prin deployment se creează sistemul ţintă din modelul proiectat
 Pentru un depozit proiectat se deploy-ază:
 Tabelele externe
 Cubul şi dimensiunile
 Mapările
 Procesele flux
 În OWB deplymentul se face cu Control Center Manager, care poate fi
lansat din Design Center
 Încărcarea datelor în tabelele ţintă se face conform mapărilor şi a
proceselor flux definite şi deployate
 Datele încărcate în tabelele ţintă pot fi viyualiyate, selectate etc.
 De exemplu, datele din tabelele schemei sh din baza de date Oracle
11g corespund bazei de date ţintă SALES_WH (cu mici diferenţe de
denumiri ale atributelor, provenind din diferenţa de versiuni)

Conţinutul tabelului PRODUCTS
Observatii: tabelul PRODUCTS este nenormalizat – prezintă redundanţe, dar interogarile sunt mai rapide
Denumirile coloanelor difera pt. ca s-a folosit deploymentul existent din exemplele Oracle (schema sh)

Conţinutul tabelului SALES

Indexuri în Oracle Data Warehouse
 În ODW se folosesc:
 Indexuri B-Tree - pentru indexuri pe atribute chei unice (primare)
 Indexuri bitmap - pentru alte atribute
 Indexuri bitmap - utilizate în depozite, unde sunt mari cantităţi de date şi
interogări ad-hoc, dar un nivel scăzut de concurenţă a tranzacţiilor
 În astfel de aplicaţii indexurile bitmap asigură:
 Timp de răspuns bun pentru interogări
 Spaţiu de memorare mai redus decât alte tipuri de indexuri (indexurile bitmap
necesită o mică fracţie din dimensiunea datelor, în timp ce indexurile B-tree pot
ajunge mai mari decât tabelel însele)
 Un index furnizează pointeri la liniile dintr-un tabel care conţine o anumită
valoare a cheii de ordonare a indexului.
 Un index obişnuit conţine lista identificatorilor liniilor care conţin cheia
 Un index bitmap conţine câte un bit pentru fiecare linie din tabel: 1 dacă linia
conţine cheia; 0 dacă linia nu conţine cheia
 Indexurile bitmap se pot comprima foarte eficient

Indexuri bitmap (1)
 Un index bitmap este cu atât mai eficient cu cât numărul de valori
distincte ale atributului folosit ca şi cheie de indexare este mai mic
 deoarece pentru fiecare valoare distinctă a atributului cheie a indexului se
memorează un şir cu un număr de biţi egal cu numărul de linii
 Exemplu: în tabelul CUSTOMERS (cust_id, cust_gender,
cust_marital_status, cust_income_level, ....)
 Se pot pune indexuri bitmap pe atributele:
 cust_gendre – 2 valori posibile (F, B)
 cust_marital_status – 5 valori posibile (null, single, married, divorced, widow)
 cust_income_level – 12 niveluri posibile
 Pe atributul cust_id nu se poate defini un index bitmap, deoarece are
număr mare de valori distincte, dar se poate defini indexul primar (de tip
B-Tree)

Index-uri bitmap (2)
 Se consideră o parte (selecţie) din tabelul CUSTOMERS
 Dacă acesta ar fi tot tabelul, atunci indexul bitmap pe atributul cust_gendre ar
arăta astfel:
cust_id ‘M’ ‘F’

555 0 1
556 0 1
557 0 1
558 0 1
559 1 0
560 0 1
561 1 0
562 1 0
563 1 0
564 1 0
 Observaţie: şirul de biţi al indexului nu are doar 10 biţi, ci o lungime egală cu

cardinalitatea tabelului CUSTOMERS

Index-uri bitmap (3)
 Indexul bitmap pe atributul cust_marital_status pe porţiunea selectată
din tabelul CUSTOMERS arată în felul următor:
cust_id ‘null’ ‘single’ ‘married’ ‘divorced’ ‘widow’
555 1 0 0 0 0
556 0 1 0 0 0
557 0 0 1 0 0
558 0 0 0 1 0
559 0 1 0 0 0
560 0 1 0 0 0
561 0 1 0 0 0
562 1 0 0 0 0
563 0 1 0 0 0
564 0 0 1 0 0

Agregarea datelor în ODW folosind SQL
 Funcţiile de agregare se pot
folosi ca extensii ale clauzei
GROUP BY:
 ROLLUP
 CUBE
 GROUPING
 GROUPING SET
 Extensia ROLLUP a clauzei
GROUP BY permite
instrucţiunii SELECT să
calculeze niveluri de subtotal
multiple peste un grup de
dimensiuni
 Exemplu de interogare cu
agregare prin clauza GROUP
BY fără nici o extensie (în
schema sh, folosind SQL
Developer):

Extensia ROLLUP a clauzei GROUP BY
 Aceeaşi interogare în care
clauza GROUP BY are
extensia ROLLUP
 Se obţin:
 Liniile cu vânzările
trimestriale, pe categorii de
produse, în intervalul dat
 Totalul pentru toate
categoriile, pe fiecare
trimestru
 Totalul pe toate categoriile,
pe tot intervalul

Extensia CUBE a clauzei GROUP BY
 Extensia CUBE a clauzei
GROUP BY generează
toate subtotalurile care pot
fi calculate dintr-un CUBE
pe dimensiunile specificate;
 Exemplu – adăugând
extensia CUBE în clauza
GROUP BY se obţin:
 Liniile cu vânzările
trimestriale, pe categorii de
produse, în intervalul dat
 Toate totalurile posibile
pentru vânzările
trimestriale şi pe categorii
de produse

Interogări stea în ODW
 Interogare stea: o joncţiune
între tabelul fact şi unul sau
mai multe tabele de dimensiuni,
folosind cheile străine din
tabelul fact
 Nu se pot face joncţiuni între
tabele de dimensiuni
 Pentru optimizarea interogărilor
stea foloseşte “transformarea
stea”:
 Se defineşte câte un index
bitmap în tabelul fact pentru
fiecare cheie străină
 Exemplu: în tabelul fact SALES
sunt definite indexuri pe cheile
străine: time_id, channel_id,
cust_id, prod_id, and promo_id

Transformarea stea
 Pentru execuţia interogării folosind transformarea stea, se transformă
interogarea stea în sub-interogări pe fiecare dimensiune:
SELECT ... FROM sales
WHERE time_id IN
(SELECT time_id FROM times WHERE calendar_quarter_desc = '1999-Q1')
AND cust_id IN
(SELECT cust_id FROM customers WHERE cust_state_province='CA')
AND channel_id IN
(SELECT channel_id FROM channels WHERE channel_desc IN('Internet','Catalog'));
 Se execută joncţiunea între tabelul fact şi fiecare tabel de dimensiune
rezultat prin selecţie folosind indexul bitmap corespunzător dimensiunii
respective
 Se obţine câte un bitmap pentru fiecare dimensiune, fiecare valoare 1
din bitmap reprezentând mulţimea liniilor din tabelul sales care satisface
condiţia corespunzătoare dimensiunii respective
 Se execută operaţia AND între bitmap-urile de dimensiuni pentru a
obţine mulţimea liniilor rezultat

Funcţii SQL pentru analiză şi raportare
 Oracle extinde SQL cu următoarele funcţii pentru analiză şi raportare:

Funcţiile RANK şi DENSE_RANK
 Funcţiile RANK şi DENSE RANK permit aflarea rangului unui articol
dintr-un grup dat
 Ex: să găsim primele 3 produse cel mai bine vândute în California anul
trecut
 Sintaxa:
RANK ( ) OVER ( [query_partition_clause] order_by_clause )
DENSE_RANK ( ) OVER ( [query_partition_clause] order_by_clause )
 Dacă lipseşte clauza query_partition_clause, rangul se aplică
întregului result set
 Diferenţa dintre cele 2 funcţii:
 La RANK: urmatorul rang are valoarea obţinută prin incrementarea valorii
rangului precedent cu numărul de aticole de pe rangul precedent
 La DENSE_RANK, următorul rang are valoare incrementata cu 1 fată de
rangul precedent, indiferent câte articole sunt asignate acestuia

Exemplu: funcţia RANK

Funcţiile lag/lead
 Sintaxa:
{LAG | LEAD} ( value_expr [, offset] [, default] )
OVER ( [query_partition_clause] order_by_clause )
 Exemplu:

OLAP şi Data Mining în Oracle
 OLAP şi Data Mining sunt integrate în serverul Oracle; pot fi privite ca
modalităţi complementare de analiză:
 OLAP oferă calcule de rezumare (sinteză); de ex. “Cum sunt vânzările de
fonduri mutuale din acest trimestru comparate cu cele de anul trecut? Ce se
poate prevedea pentru vânzările în trimestrul următor?”
 Data mining descoperă legături (pattern-uri) neaşteptate în seturile de date;
explorarea operează cu detalii, nu cu rezumate ale datelor; de exemplu,
explorarea poate oferi răspuns la întrebări: “Care sunt cartacteristicile celor
care vor cumpăra fonduri mutuale în următoarele 6 luni?”
 OLAP foloseşte kernelul bazei de date Oracle:
 Securitatea este administrată în mod standard, prin acordarea sau
revocarea de drepturei utilizatorilor şi rolurilor
 Obiectele dimensionale sunt memorate în baza de date (de ex.cuburile)
 Se poate folosi limbajul SQL pentru interogarea obiectelor dimensionale
 Data mining foloseşte mari volume de date pentru a crea modele, atât în
aplicaţiile economice cât şi în aplicaţii ştiinţifice

Oracle Data Mining (ODM)
 Oracle Data Mining suportă majoritatea funcţiilor de explorare:
 Clasificarea (gruparea entităţilor în clase) – algoritmi implementaţi: arbori de
decizie, regresie, SVM (support vector machines)
 Regresia (aproximarea şi predicţia valorilor numerice continue) – algoritmi
SVM, modele lineare generalizate (multivariate linear regression)
 Detecţia anomaliilor – foloseşte algoritmi SVM
 Detecţia importanţei atributelor – algoritmi de detecţie a descriptorilor de
lungime minimă (minimum descriptor length)
 Gruparea (clustering – identificarea grupării naturale a datelor) – algoritmi
k-Means, O-Cluster
 Asocieri (analiza în “coşul de cumpărături” a articolelor care sunt cumpărate
împreună) – algoritmul apriori
 Extragerea trăsăturilor – algoritmul de factorizare cu matrice non-negativă
 Pe lângă explorarea datelor structurate, ODM mai permite explorarea
textelor (de ex. rapoarte ale poliţiei, note medicale) sau a datelor spaţiale

Suport pentru depozite de date în alte SGBD-uri
 MySQL (versiunea 5.1) și PostgreSQL (versiunea 8.4) nu oferă suport
pentru depozite de date
 Dar există toolset-uri cu care se pot construi depozite implementate în baze
de date relationale ale acestora
 De exemplu: The Data Warehouse Toolkit by Ralph Kimball
 Microsoft SQL Server 2008 permite crearea și utilizarea depozitelor de
date prin următoarele componente:
 Componente de stocare - acestea sunt baze de date ce conțin date
colectate și informații de configurare
 Componente de execuție - folosite pentru colectarea și stocarea datelor
 Componente de interfață (API) – permit interacțiunea dintre interfețele
utilizator și colecțiile de date
 Componente client – sunt interfețe utilizatori pentru accesarea colecțiilor de
date

Microsoft SQL Server Data Warehouse

Depozite de date
 W.H. Inmon, “Building the Data Warehouse”, Fourth Edition, Wiley
Publishing, Inc., 2005
 Oracle 11g Documentation
 Oracle Database - Data Warehousing Guide
 Oracle Database - 2 Day + Data Warehousing Guide
 Oracle Warehouse Builder User's Guide

BDAS C1 Baze de Date Pentru Aplicatii Stiintifice-Merged

Î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

BDAS C1 Baze de Date Pentru Aplicatii Stiintifice-Merged

Încărcat de

Drepturi de autor:

Formate disponibile

Baze de Date pentru Aplicații

Facultatea de Electronică, Telecomunicaţii

Ingineria Informatiei şi a Sistemelor de Calcul (IISC)

Prof. Felicia Ionescu

 Introducere - evoluţia şi tendinţele de dezvoltare a

Prof. Felicia Ionescu Baze de date pentru aplicatii stiintifice 2

Prof. Felicia Ionescu Baze de date pentru aplicatii stiintifice 3

Prof. Felicia Ionescu Baze de date pentru aplicatii stiintifice 4

Prof. Felicia Ionescu Baze de date pentru aplicatii stiintifice 5

Prof. Felicia Ionescu Baze de date pentru aplicatii stiintifice 6

Prof. Felicia Ionescu Baze de date pentru aplicatii stiintifice 7

Prof. Felicia Ionescu Baze de date pentru aplicatii stiintifice 8

Prof. Felicia Ionescu Baze de date pentru aplicatii stiintifice 9

Prof. Felicia Ionescu Baze de date pentru aplicatii stiintifice 10

Prof. Felicia Ionescu Baze de date pentru aplicatii stiintifice 11

Prof. Felicia Ionescu Baze de date pentru aplicatii stiintifice 12

 Volumul datelor stocate creşte ~ 10 ori în 5 ani

Prof. Felicia Ionescu Baze de date pentru aplicatii stiintifice 13

Prof. Felicia Ionescu Baze de date pentru aplicatii stiintifice 15

Prof. Felicia Ionescu Baze de date pentru aplicatii stiintifice 16

Prof. Felicia Ionescu Baze de date active 1

Prof. Felicia Ionescu Baze de date active 2

Prof. Felicia Ionescu Baze de date active 3

Prof. Felicia Ionescu Baze de date active 4

Prof. Felicia Ionescu Baze de date active 5

Prof. Felicia Ionescu Baze de date active 6

Prof. Felicia Ionescu Baze de date active 7

 Proiectul logic al bazei de

(se poate dezvolta și în

Prof. Felicia Ionescu Baze de date active 8

Prof. Felicia Ionescu Baze de date active 9

CREATE OR REPLACE TRIGGER LIMIT_ENROLMENTS

Prof. Felicia Ionescu Baze de date active 10

Prof. Felicia Ionescu Baze de date active 11

Prof. Felicia Ionescu Baze de date obiect-orientate 1

Prof. Felicia Ionescu Baze de date obiect-orientate 3

Prof. Felicia Ionescu Baze de date obiect-orientate 4

 Încapsularea prevede o barieră în

 Asupra unui obiect se poate acţiona x=1

Prof. Felicia Ionescu Baze de date obiect-orientate 6

Prof. Felicia Ionescu Baze de date obiect-orientate 8

Prof. Felicia Ionescu Baze de date obiect-orientate 9

Prof. Felicia Ionescu Baze de date obiect-orientate 10

Prof. Felicia Ionescu Baze de date obiect-orientate 11

Prof. Felicia Ionescu Baze de date obiect-orientate 12

Prof. Felicia Ionescu Baze de date obiect-orientate 13

Prof. Felicia Ionescu Baze de date obiect-orientate 15

Asocieri simple binare Asociere simplă multiplă

Prof. Felicia Ionescu Baze de date obiect-orientate 16

Prof. Felicia Ionescu Baze de date obiect-orientate 17

Prof. Felicia Ionescu Baze de date obiect-orientate 18

Prof. Felicia Ionescu Baze de date obiect-orientate 19

Prof. Felicia Ionescu Baze de date obiect-orientate 20

Numar Buget Nume Salariu Denumire Buget

Nume GradRudenie VitezaRedact Calificare Specialitate

Prof. Felicia Ionescu Baze de date obiect-orientate 21

Prof. Felicia Ionescu Baze de date obiect-orientate 22

 Modelul OO nu are un mecanism precis de reprezentare a asocierilor și a

Prof. Felicia Ionescu Baze de date obiect-orientate 26

Prof. Felicia Ionescu Baze de date obiect-orientate 27

Prof. Felicia Ionescu Baze de date obiect-orientate 29

Prof. Felicia Ionescu Baze de date obiect-orientate 30

Prof. Felicia Ionescu Baze de date obiect-orientate 31