Utilizarea XML in Baze de Date

Utilizarea XML in baze de date
INTRODUCERE
Formatul de date XML devine formatul comun acceptat n industrie pentru schimbul
de informaii dintre diverse sisteme eterogene. Din acest motiv, este important ca o baz de
date s fie capabil s stocheze informaiile nu doar n formatele tradiionale, relaionale, ci i
n format XML. Stocnd datele XML n format nativ se ctig foarte mult n performan,
aceasta materializndu-se n costuri reduse. Un plus de performan la o tehnologie de baze
de date nseamn o infrastructur redus, servere cu mai puine procesoare, deci un sistem
informatic ceva mai ieftin, costuri mai mici pentru liceniere, deci per total o economie de
bani.
Standardul industrial al datelor n format XML prezint o serie de avantaje i
dezavantaje. Avantajul major este acela c este adoptat de toi productorii de tehnologie din
industrie, dar n schimb are dezavantajul c este un format nu foarte eficient din punct de
vedere al stocrii datelor. De aceea devine foarte util ca baza care stocheaz aceste date sa
aib capabiliti de compresie, care s duc la scderea spaiului i resurselor de stocare
necesare pentru a pstra date n format XML.
Lucrarea de fa i propune s prezinte n capitolele sale cteva noi direcii de
dezvoltare n domeniul bazelor de date, modelul de date semistructurat i tehnologia XML ca
o nou baz de date.
Capitolul I prezint necesitatea apariiei modelului semistructurat al datelor, datorit
nevoii de interogare a unor surse de date care nu au o schem predefinit sau a unor date care
provin din surse diferite i au scheme diferite. Modelul semistructurat al datelor reprezint
schema (tipul, structura) i instana (valoarea) datelor n mod uniform, permind interogarea
lor simultan spre deosebire de modelele de date convenionale, care difereniaz ntre cele
dou tipuri de informaie.
Capitolul II detaliaz modelul semistructurat al datelor definind conceptul de date
neconvenionale din mai multe perspective i pe cel de date semistructurate prezentnd
avantajele acestui tip de date, modelarea acestor date i limbajele de interogare a acestora, i
Pagina 1 din 97
prezint n detaliu tipul de date MPEG-21 ca suport pentru integrarea datelor n aplicaii
multimedia distribuite.
Capitolul III prezint legtura dintre tehnologia XML i bazele de date ncercnd s
clarifice n ce msur este XML-ul o baz de date, reprezentarea datelor i documentelor,
stocarea i recuperarea datelor, stocarea datelor n baze de date native XML, generarea
schemelor XML din scheme relaionale i invers, stocarea documentelor n sistemul de fiiere
i n BLOB-uri, detaliaz bazele de date native XML, i prezint noiunile de DOM
(Document Object Model) persistent i sisteme de management ale coninuturilor.
Capitolul IV se ocup de construirea documentelor XML prezentnd sintaxa XML,
descrierea de vocabulare noi cu XML, avantajele definiiei tipurilor documentului,
combaterea dezavantajelor definiiei tipurilor documentului, definirea unui document XML
ca ntreg, declaraia XML, documentele autonome, construirea unui document XML,
declaraia tipului documentului i prezint cteva aplicaii din lumea real a declaraiei tipului
documentului.
Capitolul V const n prezentarea aplicaiei magazinul virtual ElectronX - i
prezint scopul acestei aplicaii, cerinele minime hardware i software ale aplicaiei,
funcionalitile de baz ale acestui website, proiectarea bazei de date coninnd schema
conceptual a structurii bazei i schema fizic a fiecrei tabele, implementarea codului n care
sunt explicate fiierele cele mai importante ale aplicaiei cu exemplificri din codul surs, un
manual de utilizare al aplicaiei n care e descris modul de funcionare al acesteia i concluzii
asupra aplicaiei.
CAPITOLUL I
NOI MODELE DE DATE I APLICAIILE LOR
1.1 Interogarea World-Wide-Web-ului
Exist surse de date, ca de pild World-Wide-Web-ul, pe care am dori s le interogm
ca baze de date, dar care nu pot fi constrnse de o schem. Majoritatea interogrilor web-ului
folosesc tehnici de regsire a informaiei pentru a gsi pagini dup coninut. Exist ns
puine posibiliti de formulare a interogrilor n vederea exploatrii structurii web-ului i,
deoarece aceasta nu este conform cu nici un model de date standard, este necesar o metod
de descriere a acestei structuri.
Modelul de date semistructurat a fost propus n vederea satisfacerii acestei necesiti.
Ideea central n modelul semistructurat este de a reprezenta datele sub forma unui graf
Pagina 2 din 97
etichetat. Structura documentelor hipertext este capturat interpretnd arcele grafului drept
legturi. O reprezentare posibil este cea introdus n proiectul UnQL[1]. Etichetele arcurilor
pot fi att valori (de tip ntreg, ir de caractere i alte tipuri de baz, precum i de tip de date
abstract, ca video, audio, etc.) ct i nume de atribute (Film, Titlu, Regizor, Actor), etc.
modelnd de exemplu cunoscuta baz de date cinematografic IMDB [2].
Exist numeroase limbaje de interogare pentru modelul semistructurat. Toate aceste
limbaje sunt construite pe baza ideii de expresii asociate cilor (path expressions). Acestea
sunt expresii regulate ce exprim ci generice n graful etichetat, permind astfel traversarea
grafului i colecionarea tuturor etichetelor ce satisfac o anumit condiie de selecie.
Limbajele semistructurate pot fi clasificate n dou categorii, dup strategia de calcul
adoptat. Prima categorie, dezvoltat oarecum ad-hoc, se bazeaz pe modelarea grafurilor n
modelul relaional i apoi pe interogarea lor ntr-un limbaj relaional de tip SQL. Cteva
exemple prezentate n literatur sunt [3], [4], [5], [6], [7]
A doua categorie pornete de la un limbaj bazat pe o noiune formal de calcul cu date
semistructurate: limbajul UnQL este reprezentantul acestei categorii [1]. Acest limbaj
pornete de la recursivitatea structural, forma natural de recursivitate asociat cu tipul de
date grafuri etichetate. Datorit bazei sale teoretice, UnQL este capabil de restructurri
complexe, n adncime, spre deosebire de limbajele din prima categorie, care se limiteaz la
scoaterea la suprafa a datelor din graf, fr ns a crea noi structuri.
Aceast capacitate de restructurare st la baza proiectului STRUDEL[8] care propune
limbajul StruQL de gestiune a sit-urilor de web. Un alt avantaj al bazei teoretice a limbajelor
UnQL i StruQL este posibilitatea efecturii optimizrilor specifice acestui nou model de
date. Limbajele din prima categorie pot beneficia doar de optimizrile specifice modelului
relaional, deci dezvoltate pentru alt model de date i n consecin nu att de folositoare.
1.2 Integrarea surselor de date eterogene
Integrarea datelor provenind din surse eterogene (cu scheme disparate sau, mai grav,
modelate diferit), este un domeniu de cercetare care, dei consacrat de mai bine de un
deceniu, continu s rmn n centrul ateniei multor cercettori. Cercetarea n acest
domeniu este motivat de absena unui model de date atotcuprinztor, fapt ce ngreuneaz
dezvoltarea de software care convertete date ntre dou modele diferite.
O complicaie adiional este reprezentat de faptul c majoritatea datelor stocate
electronic nu se afl n baze de date convenionale, ci n sisteme de fiiere, programe de
bibliotec, de pot electronic, foi de calcul etc., care prezint capaciti de interogare
limitate.
Pagina 3 din 97
Ultima observaie a reprezentat punctul de plecare al proiectului Tsimmis [9][10] de la

Stanford. Proiectul Tsimmis i propune integrarea att a surselor de date care sunt conforme
cu modelele de date standard (relaional, orientat pe obiecte), ct i a surselor de date cu
capaciti de interogare limitate. Aceste surse neconvenionale sunt mpachetate n aa-numii
wrappers (ambalaje). Un astfel de ambalaj asigur interfaa ntre sursa de date cu capaciti
de interogare limitate i aplicaia care o interogheaz. Aplicaia trimite ctre surs interogri
ntr-un limbaj expresiv cum ar fi SQL sau OQL i ateapt rezultatul ntr-un format numit
OEM (Object Exchange Model).
OEM folosete grafuri etichetate, ca structur de date, care captureaz majoritatea
datelor folosite n aplicaii de baze de date. n acelai timp, toate celelalte structuri de date pot
fi codificate ca grafuri OEM.
Rolul ambalajului const n: interceptarea interogrii i identificarea acelor pri ale
acesteia care pot fi efectuate de ctre surs, translatarea acestor pri n limbajul specific
sursei, recepionarea i prelucrarea rezultatelor intermediare n vederea reconstituirii
rezultatului interogrii originale, codificarea rezultatului final n formatul OEM i
transmiterea acestuia ctre aplicaie.
Evident, dac interogarea original este prea complex, este posibil s nu poat fi
efectuat pornind de la capabilitile limitate ale sursei. Ambalajul detecteaz aceast situaie
i anun sursa c nu i poate satisface cererea. Cu ct crete capacitatea de evaluare a
interogrilor n cadrul ambalajului (de exemplu, capacitatea de a efectua operaii de tip join,
proiecii, selecii, etc.), cu att se extinde clasa de interogri pe care le poate satisface
combinaia surs-ambalaj.
Un proiect similar, cu scopul interogrii surselor de date structurate din web este [13].
Se remarc similaritatea dintre modelul OEM i cel semistructurat. ntr-adevr, Lore
[11],[12] este un sistem de interogare a datelor semistructurate, foarte similar cu UnQL,
utiliznd un model de date inspirat de OEM.
1.3 Navigare n Internet
n anumite situaii este avantajos s privim bazele de date convenionale ca fiind
semistructurate. Un exemplu este activitatea de navigare n Internet.
n general, utilizatorul nu poate interoga o baz de date fr a-i cunoate schema. Din
nefericire ns, aceasta este adeseori greu de neles, datorit mrimii exagerate (zeci de
tabele, de exemplu) i a terminologiei opace, nestandard, folosite de ctre proiectanii bazei
de date.
Pagina 4 din 97
Descifrarea schemei ar fi considerabil uurat de facilitatea de a interoga datele avnd

doar o nelegere parial a structurii lor. De exemplu, n cazul bazei de date cinematografice
din World-Wide Web[2], urmtoarele interogri ar fi de folos:
n
Exist
care
n
atribut
baza
de
gsim
date
irul
ntregi
de
mai
caractere
mari
Casablanca?
dect
216?
Ce obiecte din baza de date au un atribut al crui nume ncepe cu act?

i n acest domeniu, modelul semistructurat se dovedete a fi folositor. Spre deosebire
de modelele de date convenionale, care difereniaz ntre schema (tipul, structura) i instana
(valoarea) datelor, modelul de date semistructurat reprezint cele dou tipuri de informaie n
mod uniform, permind interogarea lor simultan. Din acest motiv, datele semi-structurate se
numesc i autodescriptive.
[1] prezint un elegant limbaj de interogare care permite exprimarea concis a acestor
interogri.
1.4 Cubul de date i OLAP
Sistemele de suport pentru decizii (Decision support systems) sunt utilizate de ctre
companiile moderne pentru integrarea ntr-o baz de date central numit data warehouse
(magazia central de date), a datelor provenind din baze de date mici operaionale folosite n
diferite domenii de activitate/filiale ale companiei.
Datele astfel acumulate sunt analizate n timp real (OLAP: On-Line Analitical
Processing) pentru a asista conducerea companiei n luarea deciziilor strategice de dezvoltare
[14] (de exemplu, analiznd vnzrile unui anumit produs pe trimestru i zon geografic, se
poate stabili o nou strategie de marketing pentru acest produs). Datele din magazia central
de date sunt modelate sub forma unui (hiper)cub de date multidimensional [15]) care poate fi
analizat la nivelul subcuburilor de granularitate arbitrar. Subcuburile se obin prin agregarea
cuburilor din care provin.
De exemplu, prin nsumarea vnzrilor trimestriale pentru fiecare zon, cubul de date
tridimensional reprezentnd vnzrile pe trimestru i zona geografic poate fi redus la un
subcub bidimensional (plan) reprezentnd vnzrile pe zona geografic. Agregarea este o
operaie costisitoare, efectuarea ei eficient pe un volum mare de date reprezentnd elul
principal al cercetrii n acest domeniu ([16],[17],[18],[19]).
1.5 Noi modele tranzacionale
n mod tradiional, tranzaciile modeleaz uniti de lucru atomice i izolate, efectuate
asupra datelor sistemului de gestiune a bazelor de date.
Pagina 5 din 97
Izolarea tranzaciilor nu permite crearea tranzaciilor complexe, mari, din tranzacii

simple. Acest model a avut succes atta vreme ct tranzaciile efectuau un numr mic de
operaii simple asupra datelor cu structur simpl.
Din pcate, modelul tranzaciilor simple nu satisface cerinele aplicaiilor complexe,
n care tranzaciile trebuiesc combinate i coordonate pentru a colabora la realizarea unui
scop complex. Aplicaii ca proiectarea asistat de calculator, automatizarea activitii de
birou, controlul produciei, gestiunea activitilor necesit noi modele tranzacionale, noi
metode de gestiune a tranzaciilor, i noi limbaje de specificare a tranzaciilor. Limbajele
tranzacionale sunt limbaje de nivel nalt, de obicei inspirate din logica cu predicate de
ordinul nti.
Dac limbajele tradiionale specificau interogri i actualizri, noile limbaje
tranzacionale se concentreaz asupra relaiei dintre tranzacii, exprimnd dependene de tipul
tranzacia T2 nu poate porni nainte ca T1 s se termine, sau T2 poate ncepe dac T1 ntoarce
o valoare mai mare ca 25. [20] prezint o clasificare i analiza detailat a noilor limbaje
tranzacionale.
Un excelent exponent al noii generaii de limbaje tranzacionale este Transaction
Datalog [21], un limbaj deductiv care menine n acelai timp toate proprietile tranzaciilor
clasice, cum ar fi: persisten, atomicitate, izolare, terminare i rollback (revenire).
Limbajul este nsoit de un model teoretic natural i de o teorie sigur pentru
demonstraii, permind astfel demonstrarea echivalenei ntre diverse expresii din acest
limbaj. Acest fapt este crucial pentru optimizare - care const din nlocuirea unei planificri
cu o alta echivalent din punct de vedere al efectului su asupra datelor, dar mai eficient din
punct de vedere al costului execuiei. Mai mult, faptul c putem demonstra c efectul unei
tranzacii complexe asupra setului de date este sau nu cel scontat, asigur consistena datelor.
1.6 Optimizri
Optimizarea limbajelor de interogare a bazelor de date nu este un domeniu nou, ci
dimpotriv, exist nc de la apariia acestora. Datorit importanei sale, acest domeniu va fi
ntotdeauna la mod n cercetarea bazelor de date.
Apariia unui nou model de date atrage dup sine o efervescen n activitatea de
cercetare a posibilitilor de optimizare a limbajului de interogare asociat noului model.
Referinele bibliografice introduse n seciunea anterioar prezint i primele ncercri de
optimizare a noilor limbaje de interogare.
Pagina 6 din 97
CAPITOLUL II
MODELE DE REPREZENTARE A DATELOR NECONVENIONALE
2.1 Definirea conceptului de date neconvenionale
n literatura de specialitate exist o serie de definiri ale conceptului de date
neconvenionale i a altor concepte asociate acestuia:
Datele neconvenionale sunt datele care nu au nici unul din tipurile standard: ntreg,
real etc. [Blanken, 2002]
Structura de date neconvenional este structura de date care nu este n uzul curent al
aplicaiilor; aceasta poate fi structura produs de datele semistructurate, cea definit noilor
tipuri de date folosite n aplicaii i date cu structuri ce se modific n mod dinamic. [GSIHT,
2005]
A patra generaie a tehnologiilor bazelor de date este prezentat n [Mannino, 2004]
ca fiind o extensie a tehnologiilor bazelor de date cu datele neconvenionale i Internetul.
Sistemele celei de-a patra generaii pot stoca i manipula tipuri de date neconvenionale cum
sunt: imaginile, secvenele video, hrile, sunetele i animaiile i permit accesul la bazele de
date Web.
Unul din obiectivele sistemelor de gestiune a bazelor de date orientate obiect este
prezentat ca fiind extinderea flexibilitii cu datele neconvenionale i procedurile de
prelucrare asociate acestora, inclusiv text, grafic i voce, date care nu pot fi manipulate i
integrate de sistemele de baze de date convenionale.
La University of Southern California din Los Angeles (USC) exist un laborator de
informare numit InfoLAB al crui scop este investigarea de noi metode pentru gestiunea
tipurilor de date neconvenionale cu arhitecturi atipice. Principalele zone de cercetare sunt:
Gestiunea fluxurilor de date multidimensionale n arhitecturi de tip punct la punct
(peer-to-peer),
Analiza datelor multidimensionale,
Gestiunea datelor peer-to-peer,
Prelucrarea interogrilor de stream-uri,
Baze de date spaio-temporale.
Descrierea datelor neconvenionale se realizeaz folosind metadate. Metadatele sunt
folosite pentru descrierea altor date, cu o structur complex sau nestructurate. Metadatele
pot fi privite din diferite perspective, n funcie de productorul sau sursa metadatelor:
Pagina 7 din 97
- Din perspectiva productorului de coninut, metadatele sunt utilizate pentru stocarea

informaiilor bibliografice ale resurselor, ca de exemplu: numele autorului, titlul, data crerii,
formatul resursei etc.
- Din perspectiva furnizorilor de servicii, metadatele ofer informaii descriptive cu
valoare adugat (majoritatea n format XML), care reduc informaiile necesare regsirii
datelor. Metadatele conin informaii despre diferitele formate n care este disponibil o
resurs i informaii semantice asociate acesteia. Aceste informaii sunt utile pentru realizarea
interogrii datelor.
- Din perspectiva consumatorului, metadatele ofer informaii suplimentare care
descriu preferinele consumatorului i resursele disponibile pentru utilizarea datelor.
Metadatele permit personalizarea consumului mediilor i trebuie luate n considerare de
productori. Metadatele sunt utile pentru distribuirea datelor n Internet sau n reele mobile
permind accesul la resurse n cele mai bune condiii posibile; de exemplu, metadatele pot fi
folosite pentru descrierea modului n care difuzarea secvenelor video este adaptat la
scderea lrgimii de band disponibil la un moment dat.
2.2 Modelul semistructurat ale datelor
Modelele relaional i orientat-obiect au fost folosite mult timp pentru modelarea
datelor nu neaprat pentru c erau cele mai naturale soluii, ci pentru c au n spate un
formalism bine definit. n timp ns, datorit dezvoltrii Internetului i datorit necesitii
integrrii datelor descrise folosind scheme diferite, modelele tradiionale s-au dovedit a nu
mai fi suficiente i a devenit acut necesitatea utilizrii unui alt model de date, modelul
semistructurat al datelor.
n plus, aplicaiile Internet realizeaz operaii care nu sunt curente n aplicaiile
tradiionale cu baze de date cum ar fi: transformri ale datelor, interpretarea interogrilor,
transportul datelor i prelucrarea bazat pe fluxuri.
Datele semistructurate au devenit un important subiect de studiu din mai multe
motive:
n primul rnd, exist surse de date pe care am vrea s le tratm ca baze de date dar
crora nu le putem impune constrngeri avnd la baz o schem, ca n cazul bazelor de date
tradiionale [Buneman, 1997]. Chiar i datele structurate, au structur care poate s difere de
la o aplicaie la alta sau au structur modificabil n timp. Dezvoltrile din domeniul
multimediei au dus la necesitatea de a introduce noi tipuri de date n domeniul tehnologiei
bazelor de date convenionale. Unele tehnologii necesit doar extensii ale modelelor de date
existente, prin optimizarea tehnicilor de manipulare i interogare a noilor tipuri de date, dar
Pagina 8 din 97
altele nu pot fi ncadrate n modelele clasice de gestiune a datelor. Cel mai evident exemplu
de date care nu pot fi ncadrate ntr-o schem sunt datele manipulate prin intermediul Webului. Majoritatea interogrilor Web exploateaz tehnicile de regsire a datelor pentru a
determina paginile individuale care au coninut ce corespunde criteriului solicitat. Dar numai
o mic parte din resursele Web sunt structurate astfel nct s permit rezolvarea interogrilor,
Web-ul nefiind conform nici unui model standard. Astfel c se simte nevoia de a gsi o
metod pentru descrierea structurii datelor Web n vederea rezolvrii acestei probleme.
Al doilea motiv este dat de necesitatea schimbului de date ntre aplicaii care folosesc
formate diferite de stocare i gestiune a datelor necesitnd astfel transformarea datelor. Nici
unul din modelele de date existente nu este acceptabil din toate punctele de vedere i n plus
este dificil s convertim datele dintr-un model n altul. Astfel, s-a simit nevoia s se dezvolte
un model care s lege cele dou lumi diferite: relaional i orientat obiect, acesta este
modelul semistructurat al datelor.
n plus, datele n format electronic se afl n medii diferite, interconectate care trebuie
s comunice ntre ele. Dar i cnd se folosesc datele structurate poate fi util ca acestea s fie
privite ca date semistructurate, din motive care in de manipularea acestora, fiind util s existe
un format flexibil pentru schimbul de date ntre diferite tipuri de baze de date. [Buneman,
1997]
O parte din aceste date se gsesc sub forma datelor nestructurate, ca de exemplu
sunetele, imaginile, secvenele video i chiar unele documente text, iar alt parte sub forma
datelor structurate, memorate n baze de date relaionale sau orientate obiect. n general, un
utilizator nu poate scrie o interogare pentru o baz de date fr s cunoasc schema de
organizare a datelor, iar aceasta este netransparent pentru utilizatori i raionamentul folosit
la proiectarea ei este adesea greu de determinat. Au fost dezvoltate limbaje care permit
interogarea simultan a datelor i a schemelor de organizare a bazelor de date, dar aceste
limbaje nu au flexibilitatea s manipuleze constrngeri complexe.
2.2.1 Conceptul de date semistructurate
n general, prin termenul de date semistructurate sunt denumite datele care nu
respect formate stricte cum ar fi cele impuse de modelele bazelor de date relaionale sau
orientate obiect. n mod evident o astfel de definiie este imprecis. Datele sunt
semistructurate dac: nu au o structur rigid (de exemplu datele Web, datele sunt combinate
din cteva surse eterogene - ca n cazul depozitelor de date), nu au o structur implicit
asociat datelor, sau au o structur parial specificat [Abiteboul, 1997]. Modelele orientatPagina 9 din 97
obiect i relaional au o schem fix pentru fiecare clas sau fiecare relaie. Datele
semistructurate permit o flexibilitate sporit, fiind o combinaie a celor dou concepte: clasa
i relaia.
Datele semistructurate conin informaii despre schema lor i aceast schem poate
diferi, n timp, n cadrul unei singure baze de date. Acest model care nu se bazeaz pe nici o
schem, are un rol special n sistemele bazelor de date.
n acest model datele sunt autoreferite, acest lucru nsemnnd c schema este ataat
datelor. Combinarea unor date dintr-o baz de date relaional cu altele dintr-o baz de date
orientat-obiect se poate realiza prin conectarea celor dou baze de date, prin intermediul
unei interfee, translatnd datele de la fiecare surs n date semistructurate.
n modelul semistructurat al datelor, informaiile care sunt n mod normal asociate
unei scheme sunt incluse n interiorul datelor. n aceste baze de date nu exist o distincie
clar ntre date i schem, iar gradul de structurare depinde de aplicaie. n anumite forme ale
modelului semistructurat exist o schem distinct, n altele nu.
Avantajele modelului semistructurat al datelor sunt urmtoarele:
Flexibilitatea - simplific integrarea bazelor de date care au scheme diferite. Spre
deosebire de alte modele, care au o schem de descriere a datelor, modelul semistructurat este
fr schem, ceea ce justific flexibilitatea sa. Flexibilitatea reprezint un instrument util
pentru integrarea datelor, mai ales n cazul problemelor legate de motenirea bazei de date.
mbuntirea eficienei regsirii datelor publicate n Internet
Posibilitatea integrrii datelor
Documentele HTML i cele stocate n biblioteci digitale sunt semistructurate. Spre
deosebire de fluxurile nestructurate de date (precum imagini, sunete, video), datele
semistructurate au o structur i spre deosebire de datele structurate (bazele de date
relaionale sau orientate-obiect), datele semistructurate nu au o schem absolut sau o clas
fix, fiecare obiect coninnd propria schem. Iregularitatea structural nu implic inexistena
similaritilor structurale ntre obiecte. Din contr, n mod obinuit, obiectele semistructurate
care descriu acelai tip de date au structur similar.
Modelul datelor semistructurate este un model pentru integrarea bazelor de date. Este
folosit pentru descrierea datelor aflate n dou sau mai multe baze de date care conin date
similare n diferite scheme de organizare.
2.2.2 Modelarea datelor semistructurate
Pagina 10 din 97
Datele semistructurate sunt modelate, n general, sub forma structurilor de tip graf sau
arbore, n noduri avnd reprezentate obiecte iar arcele reprezentnd atributele obiectelor. n
plus, arcele modeleaz natural relaiile de subordonare dintre dou obiecte. [Reveiu, 2003]
Modelul de facto pentru datele semistructurate este OEM (Object Exchange Model),
model propus n proiectul pentru integrarea datelor numit TSIMMIS i descris pentru prima
dat n lucrarea Multimedia database systems Design and implementation Strategies. OEM
este un model autodescriptibil, nefiind necesar definirea anterioar a structurii unui obiect i
nici nu exist o schem fix de reprezentare a datelor. Fiecare obiect reprezentat conine
propria lui schem.
Fiecare obiect din OEM poate avea un identificator (Id), o etichet, un tip i o valoare.
Id-urile obiectelor pot fi simboluri cu sau fr nelesuri speciale. De exemplu, dac un obiect
este o pagin Web, URL-ul paginii poate fi folosit ca id-ul obiectului. Etichetele nodurilor
sunt iruri care expliciteaz rolul obiectului pentru utilizator i pentru aplicaii. Eticheta joac
aici dou roluri: identific un obiect i d sens obiectului. Obiectele pot fi atomice sau
complexe (seturi de obiecte). Valorile obiectelor atomice au tipuri atomice (valori ntregi,
reale, iruri de caractere, imagine, sunet etc.), iar cele complexe au ca valori seturi de obiecte,
reprezentate prin perechi de tipul atribut-obiect. Prin urmare, un obiect complex va avea o
definire recursiv deoarece valoarea unui obiect este parte a sa. Nodurile frunz au asociate
ntotdeauna valori atomice.
Etichetele arcelor reprezint atribute, sunt descrise prin iruri de caractere i
reprezint un set de proprieti descriptive. O proprietate poate fi folosit ntr-un arc pentru a
descrie nodurile nvecinate.
Pagina 11 din 97
n figura 1 este prezentat exemplificarea modelrii unei pri dintr-o baz de date
multimedia folosind OEM.
Figura 1 Modelul OEM al unei pri dintr-o baz de date multimedia
Informaii: &o1
{film: &o21
{titlu: &o30 Titanic,
actor principal: &o31
{nume: &o41 DiCaprio,
prenume: &o42 Leonadro},
regizor: &o32
{nume: &44 Cameron,
prenume: &o45 James},
{ actor principal: &o33,
nume: &o46 Kate,
prenume: &o47 Winslet},
premii obinute: &o48 11 Oscaruri},
melodie: &o22
{titlu: &49 My heart will go on,
interpret: &o34
{nume: &o50 Dion,
Pagina 12 din 97
prenume: &o51 Celine},

premii: & o35
{an: &o52 1998,
nume: Oscar pentru cea mai bun coloan sonor},
coloan sonor: &o22}}
Datele stocate n baze de date relaionale pot fi descrise cu uurin folosind OEM. n
plus, OEM asigur o flexibilitate mai mare n descrierea datelor tolernd lipsa unor atribute
pentru anumite nregistrri sau existena mai multor valori pentru acelai atribut n cadrul
unei singure nregistrri.
OEM poate fi considerat mai apropiat de modelul orientat-obiect dect de cel
relaional, n care dou obiecte distincte chiar dac au valori identice, au existen de sine
stttoare, reprezentnd instane diferite.
Scheme de organizare a datelor semistructurate
Flexibilitatea n descrierea informaiilor adus de modelarea datelor semistructurate
are i dezavantaje, i anume dificultatea formulrii unei interogri relevante. S-a ncercat
asocierea unor scheme n modelarea datelor semistructurate, n acest sens existnd dou
abordri:
scheme flexibile descriu aprioric datele; schemele flexibile fiind concepute astfel
nct s permit flexibilitate n descrierea datelor; se folosete tipul void pentru manipularea
oricrui tip de dat.
scheme rigide descriu cu exactitate datele i sunt folosite pentru analiza datelor;
schema este refcut ori de cte ori se produce o modificare a informaiei memorate.
2.2.3 Limbaje de interogare a datelor semistructurate
Principalele elemente caracteristice ale unui limbaj de interogare pentru datele
semistructurate sunt:
Putere de expresie: pentru reprezentarea datelor relaionale sub forma datelor
semistructurate, limbajul semistructurat trebuie s acopere operaiile corespunztoare unui
limbaj relaional standard, dar n plus trebuie s dispun de faciliti de reorganizare a datelor,
astfel nct aceeai informaie s poat fi regsit sub o alt structur;
Semantic: cererile trebuie optimizate astfel nct s poat ine cont de semantica
datelor, fiind necesar o semantic precis pentru transformarea i optimizarea cererilor;
Schematizare: limbajul trebuie s poat recunoate structurile definite pentru a le
putea manipula;
Pagina 13 din 97
Compunere: datele obinute n urma unei interogri pot fi folosite ca date de intrare
n alte interogri, motiv pentru care limbajele trebuie s fie transparente.
Au fost propuse, ntr-o serie de proiecte de cercetare pe aceast tem, cteva limbaje
de interogare pentru datele semistructurate. Dou dintre acestea sunt: limbajul orientat-obiect
Lorel, derivat din OQL (Object Query Language) i limbajul UnQL (Unstructured Query
Language).
Domeniul datelor semistructurate este unul n studiu i va avea un impact mare asupra
unei multitudini de aplicaii, dar mai ales asupra aplicaiilor multimedia i a celor dezvoltate
pentru mediul Internet.
2.3 MPEG-21 Suport pentru integrarea datelor n aplicaii multimedia distribuite
n ciuda descrierilor complete i detaliate ale tipurilor datelor multimedia
implementate n MPEG-7, aspecte legate de organizarea datelor i de infrastructura unui
sistem multimedia distribuit nu pot fi descrise doar folosind metadate. Astfel c a fost iniiat
un nou standard, MPEG-21 cu scopul de a oferi mecanisme de proiectare a sistemelor
multimedia distribuite, de a crea un mediu unic, universal accesibil pentru livrarea i
utilizarea resurselor multimedia n diferite condiii, ca de exemplu diferite tipuri de utilizatori,
reele cu diferite caracteristici, terminale cu caracteristici diferite etc.
2.3.1 Prezentare general
MPEG-21 este un standard ISO/IEC21000 al MPEG (Moving Picture Experts Group)
care definete un cadru de lucru deschis pentru multimedia. Fora MPEG-21 este dat de
urmtoarea situaie: exist multe resurse mutimedia ce pot fi folosite la construirea unei
infrastructuri pentru distribuirea i utilizarea coninutului multimedia, dar nu exist nici o
arhitectur pentru descrierea modului n care aceste elemente interacioneaz ntre ele. Scopul
standardului MPEG-21 este s defineasc un cadru de lucru deschis pentru multimedia care
s permit utilizarea transparent i la performane bune a resurselor multimedia folosind
reele i dispozitive periferice diverse. Se urmrete gestiunea coninutului multimedia,
gestiunea proprietii intelectuale i adaptarea coninutului la resursele disponibile prin
intermediul diferitelor clase de servicii. MPEG-21 ofer un suport deschis pentru distribuirea
i utilizarea datelor multimedia. [Kosch, 2004]
MPEG acoper ntregul coninut multimedia din punctul de vedere al canalelor de
distribuie folosite, al modalitilor de creare a coninutului, din punct de vedere al modalitii
de producie, n vederea personalizrii, consumului, prezentrii i comercializrii acestuia.
Pentru realizarea acestui lucru, MPEG-21 propune norme pentru un standard deschis pentru
Pagina 14 din 97
crearea, distribuirea i utilizarea datelor multimedia. Acest standard se refer la toi actorii
implicai, de la creatorii de coninut, productori, distribuitori i furnizorii de servicii.
MPEG-21 standardizeaz fluxul informaiilor i serviciilor multimedia de la crearea
coninutului pn la livrarea ctre utilizatorii finali. Pentru a realiza acest lucru, coninutul
trebuie identificat, descris, gestionat i protejat. Transportul i livrarea coninutului poate avea
loc peste diferite reele, ntre o varietate de terminale.
Exist o serie de arhitecturi aprute ca rspuns la varietatea tipurilor de aplicaii care
utilizeaz coninutul multimedia. Exist trei modele principale folosite pentru gestiunea,
descrierea i regsirea resurselor multimedia i anume Dublin Core, SMPTE i MPEG-7.
Pentru a evita recomandarea unui model n defavoarea altuia, n mod nejustificat, MPEG-21
propune descrierea suportului multimedia sub forma unei arhitecturi generice. [ISO, 2001]
MPEG-21 se bazeaz pe dou concepte eseniale: definirea unei uniti fundamentale
de distribuie i tranzacionare - elementul digital i utilizatorii care interacioneaz cu
elementele digitale. Elementul digital este un obiect digital, structurat care are o reprezentare
standard, ce poate fi identificat i care are asociate metadate. Elementele digitale conin att
resursele multimedia (coninutul) ct i metadatele asociate resurselor sau ntregului element
digital. n accepiunea MPEG-21, utilizatorul este orice entitate care interacioneaz cu
mediul MPEG-21 sau care folosete un element digital, ca de exemplu un consumator al
datelor multimedia, o organizaie, sau un alt standard ce folosete resursele multimedia. Un
utilizator poate folosi coninutul n mai multe feluri: prin publicare sau prin livrare i poate
avea drepturi i responsabiliti specifice n funcie de modalitile de interaciune cu ali
utilizatori n cadrul MPEG-21.
Principalele elementele folosite n definirea arhitecturii MPEG-21 sunt:
Elementul digital - este un container ierarhic de resurse eterogene (video, audio, text
etc.), metadate i alte elemente digitale. Un element digital este o unitate elementar de
distribuie i tranzacionare;
Declararea elementului digital definete un set de termeni folosii la declararea
elementelor digitale;
Identificarea i descrierea elementului digital presupune identificarea i descrierea
elementului digital, natura lui, tipul sau granularitatea (film, scen sau cadru);
Gestiunea i utilizarea coninutului ofer interfee i protocoale care permit
crearea, manipularea, cutarea, accesarea, stocarea, livrarea i reutilizarea coninutului de-a
lungul canalelor de distribuie i consum;
Pagina 15 din 97
Protejarea i gestiunea proprietii intelectuale permite gestiunea coninutului i

protejarea elementelor digitale ntr-o serie de reele i dispozitive;
Terminale i reele ofer instrumente ce permit accesul transparent la coninut prin
intermediul reelelor i terminalelor, realiznd inclusiv controlul calitii serviciului;
Reprezentarea coninutului cum sunt reprezentate resursele media;
Raportarea evenimentelor conine metrici i interfee ce permit utilizatorilor s
evalueze performanele tuturor evenimentelor raportabile din cadrul sistemului.
Structura MPEG-21
n prezent sunt definite 18 pri ale MPEG-21: [ISO/IEC 21000-1-18] :
Partea 1: Tehnologiile i strategia MPEG-21,
Partea 2: Declararea elementului digital (DID)
Partea 3: Identificarea elementului digital (DII)
Partea 4: Gestiunea i protecia proprietii intelectuale (IPMP)
Partea 5: Limbajul de reprezentare a drepturilor (REL)
Partea 6: Dicionar de drepturi ale datelor (RDD)
Partea 7: Adaptarea elementului digital (DIA),
Partea 8: Software de referin
Partea 9: Formate de fiiere pentru stocarea i regsirea elementelor digitale ale
MPEG-21
Partea 10: Prelucrarea elementelor digitale
Partea 11: Asocieri persistente
Partea 12: Testare distribuirii resurselor MPEG-21
Partea 13: Codarea secvenelor video scalabile
Partea 14: Conformana
Partea 15: Raportarea evenimentelor
Partea 16: Formatul binar
Partea 17: Identificarea fragmentelor
Partea 18: Streaming-ul elementului digital
2.3.2 Declararea elementelor digitale
Declararea elementului digital presupune definirea unui set de termeni i concepte
folosite la definirea elementelor digitale, la descrierea sintaxei i semanticii fiecrui element
digital i a schemei de reprezentare n XML.
Declararea unui element digital se realizeaz n 3 etape:
- Crearea modelului abstract,
Pagina 16 din 97
- Reprezentarea modelului abstract n XML,

- Crearea schemei XML.
Modelul abstract definete un set de termeni i concepte care formeaz un model
pentru declararea elementelor digitale. Modelul abstract permite reprezentarea elementelor
digitale n diferite moduri. Modelul abstract definete entitile necesare declarrii
elementului digital.
Un prim set de entiti este format din elementele de baz folosite pentru declararea
elementelor digitale:
- resursa este un flux de date identificabil, ca de exemplu un fiier video, imagine,
secven audio sau text.
- componenta are rolul de a lega una sau mai multe resurse de un set de descriptori
ce conin informaii secundare referitoare la resursele componentei. Componenta este folosit
doar pentru gruparea resurselor i a datelor secundare transmise printr-un descriptor.
- elementul digital reprezint conectarea unuia sau mai multor elemente sau
componente la un descriptor. Se pot crea elemente digitale individuale i elemente compuse.
- descriptorul introduce un mecanism extensibil care poate fi folosit pentru asocierea
informaiilor cu alte entiti ale modelului abstract. Un descriptor asociaz informaii
textuale, secundare entitii incluse.
- containerul reprezint asocierea unuia sau mai multor elemente digitale i/sau
container(e) la un descriptor. Containerele sunt folosite pentru gruparea elementelor digitale.
Descriptorul conine informaii despre containerul reprezentat.
Pentru rafinarea descrierii resurselor se folosete urmtorul set de entiti:
- fragmentul identific un anumit punct sau interval din cadrul unei resurse
(secven video, audio etc.). Fragmentele sunt specifice tipului resursei.
- ancora conecteaz descriptori de un fragment. n acest caz, descriptorii conin
informaii despre fragmentele ancorei. Ancora este folosit pentru gruparea fragmentelor i
descriptorilor. Exemplu de ancor: un moment de timp al unei resurse video, o form
poligonal din cadrul unei resurse de tip imagine.
- adnotarea permite adugarea de informaii la o entitate a modelului fr a modifica
entitatea.
- alternativa este o opiune din mai multe existente; ca de exemplu, alternativa unei
conexiuni la Internet la o lrgime de band mare sau alternativa unei conexiuni prin dial-up.
- selecia este opiunea utilizatorului din alternativele disponibile.
Pagina 17 din 97
- condiia pe baza seleciei utilizatorului, pot fi satisfcute (sau nu) condiiile

asociate unei entiti a elementului digital i entitatea elementului digital poate deveni
disponibil (sau nu).
Reprezentarea modelului abstract n XML presupune descrierea sintaxei XML
pentru fiecare entitate definit n modelul abstract. Aceast sintax formeaz limbajul de
declarare a elementului digital al MPEG-21 (DIDL Digital Item Declaration). Declararea
elementelor digitale reprezentate n conformitate cu sintaxa DIDL formeaz documentul
DIDL.
DIDL definete cteva elemente suplimentare care nu corespund entitilor modelului
abstract:
- Elementul DIDL ca rdcin a documentului DIDL,
- Elementul Referin - reprezint o legtur la un alt element al documentului DIDL
i include coninutul elementul refereniat n elementul referit. Referinele se pot face la
elemente din acelai document DIDL sau la elemente din alt document DIDL. O referin
intern permite pstrarea unei singure surse pentru un element care apare n documentul
DIDL n mai multe locuri. Referina extern permite unui document DIDL s fie mprit n
mai multe documente DIDL conectate.
- Elementul Declaraii este folosit pentru definirea elementelor documentului DIDL,
fr a le instania. Un element declarat poate fi instaniat folosind elementul Referin.
Schema XML specific sintaxa DIDL i constrngerile pentru structura
documentelor DIDL.
Relaia dintre modelul abstract MPEG-21 i DIDL este prezentat n figura 4.2.
Figura 2 - Relaia dintre modelul abstract MPEG-21 i DIDL
n continuare sunt prezentate componentele de baz ale schemei de declarare a
elementelor digitale. Aceste elemente se folosesc n schemele documentelor XML.
Pagina 18 din 97
Schema de declarare a elementului digital

Schema de declarare a unui element digital numit ElementDigital care are la primul
nivel un container sau un alt element digital este:
<xsd:schema targetNamespace = "urn:mpeg:mpeg21:2002:01DIDL-NS" xmlns = "urn:mpeg:mpeg21:2002:01-DIDL-NS"
xmlns:xsd = "http://www.w3.org/2001/XMLSchema"
version = "0.01">
<xsd:element name = "ElementDigital">
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="Declaratii" minOccurs="0"/>
<xsd:choice>
<xsd:element ref="Container"/>
<xsd:element ref="Element"/>
</xsd:choice>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:schema>
Container
Containerul are o structur ierarhic, iar definirea sa se realizeaz recursiv:
<xsd:element name="Container">
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="Descriptor" minOccurs="0"
maxOccurs="unbounded"/>
<xsd:choice>
<xsd:element ref="Referinta"/>
<xsd:sequence>
<xsd:element ref="Container" minOccurs="0"
<xsd:element ref="Element" minOccurs="0"
Pagina 19 din 97
</xsd:sequence>
</xsd:choice>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
De exemplu, dac ntr-un element digital vor fi grupate mai multe elemente ce conin
cte o secven video, atunci pentru fiecare secven se va folosi cte un container ce conine
declararea elementului.
Declararea descriptorului elementului digital compus este:
<ElementDigital>
<Container>
<Descriptor>
<Declarare mimeType = "video/avi">Secventele Video</Declarare>
</Descriptor>
<Element id = "Secventa1">
</Element>
<Element id = "Secventa2">
</Element>
</Container>
</ElementDigital>
2.3.3 Adaptarea coninutului utiliznd MPEG-21
Standardul MPEG-21 faciliteaz dezvoltarea de soluii de adaptare a coninutului
distribuit n funcie de caracteristicile tehnice ale terminalelor folosite pentru receptarea
datelor, de caracteristicile tehnice ale mediului de comunicaie folosit sau n funcie de
preferinele utilizatorului.
Pentru adaptarea coninutului multimedia este necesar existena unei descrieri a
mediului de lucru, pe lng descrierea coninutului propriu-zis. n vederea adaptrii
coninutului multimedia trebuie s existe o descriere a sa, folosind unul din standardele
adecvate, ca de exemplu Dublin Core, SMPTE sau MPEG-7. Partea a aptea a MPEG-21,
denumit Adaptarea elementului digital (DIA) este dedicat descrierii caracteristicilor
mediului i adaptrii elementelor digitale la aceste caracteristici.
Pagina 20 din 97
DIA definete doar instrumentele necesare n procesul de adaptare, nu realizeaz i

adaptarea coninutului.
Categoriile de instrumente descriptive folosite sunt:
Instrumentele pentru descrierea mediului au rolul de a descrie caracteristicile
semnificative ale contextului i anume:
- caracteristicile terminalului folosit pentru receptarea sau crearea coninutului
multimedia: posibilitile de codare/decodare ale terminalului, facilitile/dispozitivele de
intrare-ieire conectate, alte caracteristici relevante;
- caracteristicile reelei: capacitatea reelei, tipul conexiunii etc.;
- caracteristicile utilizatorului: informaii despre utilizator, preferinele utilizatorului,
un istoric al datelor utilizate, preferine legate de prezentarea informaiilor, caracteristici de
accesibilitate i localizarea acestuia;
- caracteristici ale mediul natural: atributele audiovizuale msurabile ale mediului
natural, care afecteaz modalitatea n care coninutul multimedia este livrat i/sau consumat
de utilizator: nivelul zgomotului, intensitatea luminii, fusul orar, locaia.
Instrumentele de adaptare a resurselor sunt folosite pentru descrierea datelor
structurale, ale fluxurilor de bii i a datelor despre adaptabilitatea metadatelor i se folosete
pentru aceasta Binary Syntax Description Language. Descrierea se bazeaz pe mprirea
fluxului de bii n componente logice, ca de exemplu mprirea unei secvene video n cadre.
Fluxul de bii este apoi transformat de un motor pentru adaptarea resursei elementului digital
ntr-un descriptor al sintaxei fluxului (BSD), transformare care poate fi fcut sub controlul
XSLT (Extensible Stylesheet Language Transformations). Descriptorul este de dorit s fie
independent de un format media ceea ce permite realizarea adaptrii resurselor binare n orice
locaie.
Instrumentele pentru adaptarea metadatelor identific datele care pot fi utilizate
pentru reducerea complexitii instanelor XML de adaptare a metadatelor. Specificaiile se
refer la filtrarea i scalarea coninutului i la integrarea a dou sau mai multe instane ale
descrierilor.
Legturile dintre principalele componente ale DIA sunt prezentate n figura 3.
Pagina 21 din 97
Figura 3 Adaptarea elementului digital i instrumente pentru DIA

Declararea unui DIA pentru descrierea caracteristicilor statice i dinamice ale unei
reele se poate face:
<DIA xmlns="urn:mpeg:mpeg21:dia:schema:2003"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<Descriere xsi:type="UtilizareaMediului">
<Retea>
<Capacitate Maxima="384000" MinimaGarantata="32000"/>
</Retea>
</Descriere>
</DIA>
Caracteristicile monitorului unui terminal se pot descrie:
<DIA xmlns="urn:mpeg:mpeg21:dia:schema:2003"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
Pagina 22 din 97
<Terminal>
<Monitor>
<Caracteristici bitiPerPixel="24" Culori="32biti" RataRefresh="70">
<Rezolutia Orizontala="1024" Verticala="768"/>
</Caracteristici>
</Monitor>
</Terminal>
</DIA>
CAPITOLUL III
XML CA BAZ DE DATE
3.1 Este XML-ul o baz de date?
nainte de a discuta despre XML i baze de date trebuie s rspundem la ntrebarea
Este XML-ul o baz de date?
Un document XML este o baz de date n sensul cel mai strict al cuvntului i anume
este o colecie de date. Se poate considera c aceste documente nu sunt diferite de orice alt tip
de fiiere n fond, toate fiierele conin anumite tipuri de date. Avnd formatul unei baze de
date documentele XML prezint anumite avantaje. De exemplu este auto-descris (tag-urile
descriu structura i numele tipurilor de date, dar nu i semantica), este portabil (Unicode), i
poate descrie date n structuri de arbori sau grafuri. De asemenea are i dezavantaje. De
exemplu, este prolixs(neclar) i accesul la date este greoi datorit analizrii i conversiei
textului.
Putem considera i c XML i tehnologiile asociate constituie o baz de date n sensul
mai larg al cuvntului adic, un sistem de gestiune a bazelor de date (SGBD). XML ofer
multe din avantajele bazelor de date: stocare (documente XML), scheme (DTD-uri, scheme
XML, RELAX NG, .a,), limbaje de interogare (XQuery, XPath, XQL, XML-QL, QUILT,
etc.), interfee de programare (SAX, DOM, JDOM). Totui multe componente ale bazelor de
date convenionale: stocare eficient, indeci, securitate, tranzacii i integritatea datelor,
accesul multi-user, triggere, interogri fcute pe mai multe documente .a.
Astfel, se pot folosi documente XML ca o baz de date ntr-un mediu cu cerine
modeste i date puine, dar aceast soluie nu este viabil ntr-un mediu pentru producie n
mas, unde exist muli utilizatori, cerine stricte de integritate a datelor i nevoia de o
performan bun.
Pagina 23 din 97
3.2 Date i documente

Cel mai important factor n alegerea unei baze de date este ce va stoca aceasta: date
sau documente. XML-ul poate fi folosit doar pentru a transporta date ntre baza de date i o
aplicaie sau poate fi folosit integral ca n cazul documentelor XHTML i DocBook. Scopul
utilizrii XML este important deoarece toate documentele centrate pe date au anumite
caracteristici comune, la fel se ntmpla i n cazul informaiilor centrate pe documente, i
aceste caracteristici influeneaz felul cum XML-ul este stocat n baza de date.
3.2.1 Documente centrate pe date
Documentele centrate pe date sunt documente care folosesc XML-ul pentru
transportul datelor. Aceste documente sunt folosite de ctre aplicaii i nu are nici o
importan faptul c informaiile folosite au fost reinute pentru o perioad de timp n
documente XML. Exemple de documente centrate pe date sunt ordine de plat, programarea
zborurilor, date tiinifice.
Documente centrate pe date au o structur regulat, datele sunt atomice (cea mai mic
unitate independenta de date este un element sau un atribut). Ordinea elementelor care apar n
document nu este important, dect n momentul validrii documentului.
Informaiile care exist n documentele centrate pe date pot proveni din baza de date
(caz n care se dorete extragerea lor n fiiere XML), dar i din afara bazei de date (caz n
care se dorete stocarea acestora n baza de date). Un exemplu de informaii care provin dintro baz de date sunt cantitile de date stocare n bazele de date relaionale, iar un exemplu de
informaii care se doresc a fi introduse ntr-o baz de date pot fi considerate datele tiinifice
obinute de un sistem de msurtori i convertite n XML.
De exemplu urmtorul ordin de vnzare este un document centrat pe date:
<OrdinVanzari NumarOV="12345">
<Client NumarClient="543">
<NumeClient>ABC Industries</NumeClient>
<Strada>123 Main St.</Strada>
<Oras>Chicago</Oras>
<Stat>IL</Stat>
<CodPostal>60609</CodPostal>
</Client>
<DataOrdin>981215</DataOrdin>
<Item NumarItem="1">
Pagina 24 din 97
<Parte NumarParte="123">
<Descriere>
Cheie reglabila: 
Hotel inoxidabil,
Garantie pe viata.
</Descriere>
<Pret>9.95</Pret>
</Parte>
<Cantitate>10</Cantitate>
</Item>
<Item NumarItem="2">
<Parte NumarParte="456">
<Descriere>
Separator: 
Aluminiu, un an garantie.
</Descriere>
<Pret>13.27</Pret>
</Parte>
<Cantitate>5</Cantitate>
</Item>
</OrdinVanzari>
Pe lng documentele centrate pe date cu structura asemntoare cu documentul din
exemplul anterior, multe documente care conin i text adiional sunt centrate pe date. Spre
exemplu s considerm o pagin web care conine informaii despre o carte. Dei pagina
conine n mare parte text, structura acelui text este regulat, i o parte din acel text este
comun tuturor paginilor care descriu cri, fiecare poriune de text specific avnd dimensiuni
limitate. Astfel pagina ar putea fi construit dintr-un document XML simplu, centrat pe date
care conine informaii despre o singur carte i este obinut dintr-o baz de date i un
stylesheet XSL care adaug textul care leag informaiile din XML. n general orice site web
care construiete documente HTML dinamic prin completarea unui template cu informaii
dintr-o baz de date poate fi nlocuit cu mai multe documente XML centrate pe date i unul
sau mai multe stylesheet-uri XSL.
De exemplu, s considerm urmtorul document care descrie un zbor:
Pagina 25 din 97
<InfoZbor>
<LinieAeriana>ABC Airways</LinieAeriana> ofera <Numar>trei</Numar>
zboruri zilnice non-stop din <Origine>Dallas</Origine> spre
<Destinatie>Fort Worth</Destinatie>. Orele de plecare sunt
<Plecare>09:15</Plecare>, <Plecare>11:15</Plecare>,
and <Plecare>13:15</Plecare>. Sosirile sunt cateva minute mai tarziu.
</InfoZbor>
Acesta ar putea fi construit dintr-un fiier XML i un stylesheet simplu:
<Zboruri>
<LinieAeriana>ABC Airways</LinieAeriana>
<Origine>Dallas</Origine>
<Destinatie>Fort Worth</Destinatie>
<Zbor>
<Plecare>09:15</Plecare>
<Sosire>09:16</Sosire>
</Zbor>
<Zbor>
</Zbor>
<Zbor>
</Zbor>
</Zboruri>
3.2.2 Informaii centrate pe documente
Documentele care folosesc viziunea centrat pe documente sunt, de obicei, acele
documente care sunt destinate folosirii de ctre utilizatori. Exemple de astfel de documente
sunt crile, email, anunuri publicitare i aproape orice document XHTML scris de mn.
Acestea sunt caracterizate de o structur mai puin regulat, datele nu sunt atomice (cea mai
mic unitate independent de informaie poate fi format dintr-un element mbinat cu alte
informaii din document). Ordinea elementelor care apar n document este aproape
ntotdeauna important.
Pagina 26 din 97
Aceste tipuri de documente sunt de obicei scrise manual n XML sau n alte formate
cum ar fi RTF, PDF sau SGML i apoi sunt transformate n XML. Spre deosebire de
documentele centrate pe date aceste documente nu pot proveni din baze de date.
Spre exemplu urmtorul document ce conine descrierea unui produs este centrat pe
documente:
<Produs>
<Intro>
<NumeProdus>Cheie reglabila</NumeProdus> de la <Producator>Full
Fabrication Labs,Inc.</Producator>este<Sumar>ca o cheie universala,
dar mai mica.</Sumar>
</Intro>
<Descriere>
<Paragraf>Cheia universala, care are doua versiuni stanga si dreapta , este
confectionata din cel mai fin hotel inoxidabil
. Manerul cauciucat se adapteaza la mainile dumneavoastra
chiar si in cele mai aluneacoase situatii. Se poate regla
prin mai multe discuri.</Paragraf>
<Paragraf>Puteti:</Paragraf>
<Lista>
<Item><Link URL="Comanda.html">comanda propria dumneavoastra
cheie reglabila </Link></Item>
<Item><Link URL="Wrenches.htm">Cititi mai multe despre chei</Link></Item>
<Item><Link URL="Catalog.zip">Descarcati catalogul</Link></Item>
</Lista>
<Paragraf>Cheia reglabila costa doar 44.90 RON si, daca veti
comanda acum, veti primi un ciocan
cadou.</Para>
</Descriere>
</Produs>
3.2.3 Date, documente i baze de date
n realitate diferena dintre documentele centrate pe date i cele centrate pe documente
nu este ntotdeauna clar. Astfel de documente sunt cele legale sau medicale, care sunt scrise
Pagina 27 din 97
ca text dar conin i poriuni de date cum ar fi nume, date, proceduri i de multe ori trebuiesc
stocate n ntregime din cauze legale.
Cu toate acestea clasificarea documentelor ca fiind centrate pe date sau pe documente
poate determina tipul bazei de date necesare stocrii informaiilor din aceste documente. De
obicei datele sunt stocate ntr-o baz de date tradiional cum sunt cele relaionale sau
orientate-obiect. Documentele sunt stocate ntr-o baz de date nativ XML (o baz de date
destinat stocrii XML) sau un sistem de gestionare a coninuturilor (content management
system) o aplicaie destinat administrrii documentelor i construit peste o baz de date
nativ XML.
Totui aceste reguli nu sunt stricte. Datele n special datele semistructurate pot fi
stocate n baze de date native XML i documentele pot fi stocate n baze de date tradiionale
atunci cnd nu sunt necesare foarte multe caracteristici specifice XML. n plus, graniele
dintre bazele de date tradiionale i cele native XML devin din ce n ce mai neclare, deoarece
la bazele de date tradiionale se adaug facilitai native XML i bazele de date native XML
suport stocarea fragmentelor de documente n baze de date, de obicei relaionale, externe.
3.3 Stocarea i recuperarea datelor
Pentru transferarea datelor ntre documente XML i o baz de date, este necesar
maparea schemei documentului XML (DTD, Scheme XML, RELAX NG, etc.) pe schema
bazei de date. Software-ul pentru transferul de date este construit peste aceast mapare.
Software-ul poate folosi un limbaj de interogare XML (cum ar fi XPath, XQuery) sau poate
transfera direct date conform cu maparea (echivalentul n XML al interogrii SELECT *
FROM Tabel).
n al doilea caz, structura documentului i structura necesar pentru mapare trebuie s
fie identice. Deoarece acest lucru se ntmpl destul de rar, produsele care folosesc aceast
strategie sunt adesea folosite mpreun cu XSLT. Astfel, nainte de transferarea datelor n
baza de date, documentul este nti adus la structura necesar maprii i apoi datele sunt
transferate. Similar dup transferarea datelor din baza de date, documentul obinut este adus
la structura folosit de ctre aplicaie.
3.3.1 Maparea schemelor documentelor pe schemele bazelor de date
Maprile ntre schemele documentelor i schemele bazelor de date sunt efectuate pe
tipurile elementelor, atribute, i text. Aproape ntotdeauna se omit structurile fizice (cum ar fi
entitile i informaia codificat) i unele structuri logice (cum ar fi instruciunile de
procesare, comentariile). Aceste omiteri nu au o influen prea mare, deoarece baza de date i
aplicaia sunt interesate numai de datele din documentul XML.
Pagina 28 din 97
O consecin a acestor transformri adic stocarea datelor dintr-un document ntr-o

baz de date i apoi reconstruirea documentului din datele existente n baza de date este
obinerea unui document diferit. Dac acest lucru este acceptabil depinde de cerinele fiecrui
proiect i poate influena alegerea softului.
De obicei sunt folosite dou metode pentru a mapa schema unui document XML pe
schema unei baze de date: maparea bazat pe tabele i maparea obiectual-relaional.
3.3.1.1 Maparea bazat pe tabele
Maparea bazat pe tabele este folosit de multe produse care efectueaz transferul de
date ntre un document XML i o baz de date relaional. Aceasta modeleaz un document
XML ca o singur tabel sau ca un set de tabele. Structura documentului XML este artat n
exemplul urmtor.
<bazadedate>
<tabela>
<linie>
<coloana1>...</coloana1>
<coloana2>...</coloana2>
</linie>
<linie>
</linie>
</tabela>
<tabela>
</tabela>
</bazadedate>
n funcie de software datele din coloane pot fi stocate ca elemente descendente sau ca
atribute. n plus, produsele care folosesc mapri bazate pe tabele de multe ori includ metadate
fie la nceputul documentului fie ca atribute asociate fiecrui element din tabel sau coloan.
Pagina 29 din 97
Maparea bazat pe tabele este utilizat pentru serializarea datelor relaionale, ca n

cazul transferrii datelor ntre dou baze de date relaionale. Dezavantajul acestei mapri este
c nu poate fi folosit pentru un document XML care nu respect formatul din exemplu.
3.3.1.2 Maparea obiectual-relaional
Maparea obiectual-relaional este folosit de ctre toate bazele de date relaionale
care suport XML i anumite produse middleware. Aceasta modeleaz datele din documentul
XML ca un arbore de obiecte care sunt specifice datelor din document. n acest model,
tipurile de elemente cu atribute sunt n general modelate n clase. Tipurile de elemente
simple, atributele, i PCDATA sunt modelate ca proprieti scalare. Modelul este apoi mapat
pe bazele de date relaionale folosind tehnici de mapare obiectual-relaionale tradiionale.
Astfel clasele sunt mapate pe tabele, proprietile scalare pe coloane, i proprietile cu valori
obiect sunt mapate pe perechi de chei primare/chei strine.
Denumirea de mapare obiectual-relaional este de fapt un termen impropriu,
deoarece arborele de obiecte poate fi mapat direct pe baze de date orientate obiect i
ierarhizate. Totui este folosit pentru c majoritatea produselor care folosesc aceast mapare
folosesc baze de date relaionale i acest termen este bine cunoscut.
Este important nelegerea faptului c modelul obiectual din aceast mapare nu este
modelul DOM (Document Object Model). DOM-ul modeleaz chiar documentul i este
acelai pentru toate documentele XML, n timp ce modelul descris mai sus modeleaz datele
din document i este diferit pentru fiecare set de documente XML care corespund unei
scheme XML de date. De exemplu ordinul de vnzri din seciunea 3.2.1 ar putea fi modelat
ca un arbore de obiecte format din 4 clase OrdineVnzri, Client, Item, i Parte aa cum
se arat n diagrama de mai jos:
OrdineVnzri
/|\
Client Item Item
||
Parte Parte
Dac ar trebui s construim un arbore DOM din acelai document, acesta ar fi compus
din obiecte cum ar fi Element, Atribut i Text.
Pagina 30 din 97
Element ------ Atribut

(OrdineVnzri) (Numr OV)
_________/ / \ \_____
//\\
Element Text Element Element
(Client) (Data ordinului) (Item) (Item)
|||
etc. etc. etc.
Instanierea obiectelor din model depinde de produsul folosit. Unele produse dau
posibilitatea generrii claselor n model i apoi folosirea obiectelor din aceste clase n
aplicaii. n cazul folosirii acestor produse, datele sunt transferate ntre documentul XML i
aceste obiecte, i ntre aceste obiecte i baza de date. Alte produse folosesc aceste obiecte
numai pentru a vizualiza maparea i transferul de date direct ntre documentul XML i baza
de date.
Felul n care maparea obiectual-relaional este suportat variaz de la produs la
produs. De exemplu:
Toate produsele suport maparea tipurilor complexe de elemente pe clase i a tipurilor
simple de elemente i atribute pe proprieti.
Toate produsele dau posibilitatea desemnrii unui element rdcin care nu este mapat
pe modelul obiect sau pe baza de date. Acest element este folositor atunci cnd se dorete
stocarea obiectelor cu mai multe nivele n acelai document XML.
Majoritatea produselor ofer posibilitatea specificrii dac proprietile sunt mapate
pe atribute sau pe elemente descendente n documentul XML. Unele produse permit
combinarea atributelor cu elementele descendente; altele cer folosirea numai a elementelor
descendente sau a atributelor.
Majoritatea produselor permit folosirea numelor diferite n documentul XML i baza
de date, dar sunt anumite produse care necesit folosirea acelorai nume att n documentul
XML ct i n baza de date.
Majoritatea produselor permit specificarea ordinii n care elementele descendente apar
n printele lor, dar care face imposibil construirea mai multor modele pentru coninut. Din
fericire, modelele pentru coninut suportate sunt suficiente pentru majoritatea documentelor
centrate pe date (ordinea este important numai dac se face validarea documentului).
3.3.2 Limbaje de interogare
Pagina 31 din 97
Multe produse transfer date direct conform cu modelul pe care sunt construite.
Deoarece structura documentului XML este de obicei diferit de structura bazei de date,
aceste produse deseori conin sau sunt folosite cu XSLT. Acesta d posibilitatea utilizatorilor
s transforme documente la structura modelului naintea transferrii datelor n baza de date, i
invers. Deoarece procesarea XSLT poate fi scump, unele produse conin un numr limitat de
transformri n maprile lor.
Soluia pe termen lung la aceast problem este implementarea unor limbaje de
interogare care returneaz XML. n prezent cele mai multe asemenea limbaje se bazeaz pe
fraze SELECT integrate n abloane. Se presupune c aceast situaie se va schimba atunci
cnd XQuery i SQL/XML vor fi finalizate, acestea aflndu-se n lucru. Aproape toate
limbajele de interogare XML sunt deocamdat read-only, deci vor fi necesare metode diferite
pentru inserarea, actualizarea i tergerea datelor (n viitor aceste facilitai vor fi adugate).
3.3.2.1 Limbaje de interogare bazate pe abloane
Cele mai des ntlnite limbaje de interogare care returneaz XML din baze de date
relaionale sunt cele bazate pe abloane. n aceste limbaje, nu exist o mapare predefinit
ntre document i baza de date. Frazele SELECT sunt integrate ntr-un ablon i rezultatele
sunt procesate de ctre software-ul care transfera date. De exemplu, urmtorul template
folosete elementele <SelectStmt> pentru a include fraze SELECT i numele coloanelor
pentru a determina unde trebuiesc plasate rezultatele:
<?xml version="1.0"?>
<InfoZbor>
<Introducere> Urmatoarele zboruri sunt diponibile:</Introduction>
<SelectStmt>SELECT Airline, FltNumber,
Depart, Arrive FROM Flights</SelectStmt>
<Zbor>
<LinieAeriana>$Airline</LinieAeriana>
<NumarFlt>$FltNumber</NumarFlt>
<Plecare>$Depart</Plecare>
<Sosire>$Arrive</Sosire>
</Zbor>
<Concluzie>Speram ca unul dintre ele va este de folos</Concluzie>
</InfoZbor>
Pagina 32 din 97
Rezultatul procesrii unui asemenea ablon ar putea fi:

<?xml version="1.0"?>
<InfoZbor>
<Introducere> Urmatoarele zboruri sunt diponibile:</Introduction>
<Zboruri>
<Zbor>
<LinieAeriana>ACME</LinieAeriana>
<NumarFlt>123</NumarFlt>
<Plecare>Dec 12, 1998 13:43</Plecare>
<Sosire>Dec 13, 1998 01:21</Sosire>
</Zbor>
</Zboruri>
<Concluzie>Speram ca unul dintre ele va este de folos</Concluzie>
</InfoZbor>
Limbajele de interogare bazate pe abloane pot fi foarte flexibile. Dei setul de
caracteristici variaz de la un produs la altul, exist unele caracteristici comune:
Abilitatea de a plasa seturi de rezultate oriunde n documentul de ieire, incluznd ca
parametrii i frazele SELECT .
Construcii cum ar fi cicluri FOR i instruciuni IF.
Definiri de variabile i funcii
Parametrizarea frazelor SELECT prin intermediul parametrilor HTTP.
Limbajele de interogare bazate pe abloane sunt folosite aproape exclusiv pentru a
transfera date din baze de date relaionale n documente XML. Dei unele produse care
folosesc limbaje de interogare bazate pe abloane pot transfera date din documente XML n
baze de date relaionale, ele nu folosesc abloanele numai pentru acest lucru. n schimb ele
folosesc o mapare bazat pe tabele, aa cum este descris anterior.
3.3.2.2 Limbaje de interogare bazate pe SQL
Limbajele de interogare bazate pe SQL folosesc fraze SELECT modificate, iar
rezultatele sunt transformate n XML. Exist cteva limbaje particulare de acest tip i cel mai
simplu dintre acestea folosete fraze SQL imbricate (nested), care sunt transformate direct n
XML imbricat (nested) conform cu maparea relaional-obiectual. Un alt limbaj de acest tip
Pagina 33 din 97
folosete obiecte SQL 3, de asemenea transformate direct n XML. Un alt limbaj folosete
fraze OUTER UNION i marcaje speciale pentru a determina cum sunt transformate
rezultatele n XML.
n plus faa de limbajele particulare, un numr de companii s-au reunit n 2000 pentru
a standardiza extensiile XML la SQL. Rezultatele lor fac parte acum din specificaia ISO
SQL i este cunoscut ca SQL/XML. SQL/XML introduce un tip de date XML i adaug un
numr de funcii la SQL, aa c este posibil construirea elementelor XML i a atributelor din
date relaionale.
De exemplu, urmtoarea interogare:
SELECT Orders.SONumber,
XMLELEMENT(NAME "Order",
XMLATTRIBUTES(Orders.SONumber AS SONumber),
XMLELEMENT(NAME "Date", Orders.Date),
XMLELEMENT(NAME "Customer", Orders.Customer)) AS xmldocument FROM
Orders
construiete un set de rezultate cu dou coloane. Prima coloan conine numrul
ordinului de vnzri i a doua coloan conine un document XML. Exist un document XML
pe fiecare linie, construit din datele din linia corespunztoare n tabelul de comenzi. De
exemplu documentul pentru linia pentru ordinul de vnzare 123 ar putea fi:
<Ordin NumarOV="123">
<Data>04/29/07</Data>
<Client>Gallagher Industries</Client>
</Ordin>
3.3.2.3 Limbaje de interogare XML
Spre deosebire de limbajele de interogare bazate pe abloane sau bazate pe SQL, care
pot fi folosite numai cu baze de date relaionale, limbajele de interogare XML pot fi folosite
pentru orice document XML. Pentru a folosi acest tip de limbaje cu baze de date relaionale,
datele din baza de date trebuie s fie modelate ca XML.
Cu XQuery, poate fi folosit fie maparea bazat pe tabele fie maparea obiectual
relaional. Dac este folosit o mapare bazat pe tabele, fiecare tabel este tratat ca un
document separat i n fiecare interogare sunt specificate uniri ntre tabele, ca n SQL. Dac
este folosit o mapare obiectual-relaional atunci ierarhiile de tabele sunt tratate ca un singur
document i sunt specificate uniri n mapare. Se preconizeaz c maprile bazate pe tabele
Pagina 34 din 97
vor fi utilizate n majoritatea implementrilor, n detrimentul bazelor de date relaionale,

deoarece se consider c sunt mai uor de implementat i mai bine cunoscute de utilizatorii
SQL.
Cu XPath, o mapare obiectual-relaional trebuie s fie folosit pentru a executa
interogri peste mai multe tabele. Aceasta se ntmpl deoarece XPath nu suport unirile ntre
documente. Astfel, dac ar fi folosit o mapare bazat pe tabele, ar fi posibil interogarea unei
singure tabele la un moment dat.
3.3.3 Stocarea datelor n baze de date native XML
De asemenea este posibil stocarea datelor n documente XML ntr-o baz de date
nativ XML. Acest lucru se face din mai multe motive. Primul ar fi acela cnd datele sunt
semistructurate, adic acestea au o structur regulat, dar acea structur variaz destul nct
maparea ei la o baz de date relaional duce fie la un numr mare de coloane cu valori nule
(care ocup spaiu inutil), fie la un numr mare de tabele (care este ineficient). Dei datele
semistructurate pot fi stocate n baze de date ierarhizate orientate-obiect, se poate alege
stocarea lor ntr-o baz de date nativ XML sub forma unui document XML.
Al doilea motiv pentru stocarea datelor ntr-o baz de date nativ XML este viteza de
recuperare a datelor. n funcie de cum sunt stocate datele n baza de date nativ XML, ar
putea fi posibil recuperarea datelor mult mai repede dect ntr-o baz de date relaional.
Acest lucru se poate ntmpla deoarece unele strategii de stocare folosite de ctre bazele de
date native XML rein fizic documente ntregi sau folosesc pointeri fizici (i nu logici) ntre
prile documentelor. Acestea permit ca documentele s fie recuperate fie fr uniri fie
folosind uniri fizice, ambele fiind mai rapide dect unirile logice folosite n bazele de date
relaionale.
De exemplu se consider ordinul de vnzare prezentat mai sus. ntr-o baz de date
relaional, acesta ar fi stocat n patru tabele OrdineVnzri, Itemi, Clieni, i Parte i
recuperarea documentului ar necesita uniri ntre aceste tabele. ntr-o baz de date nativ
XML, ntreg documentul ar putea fi stocat ntr-o singur locaie pe disc, aa c recuperarea
lui sau a unui fragment din el necesit o singur cutare indexat i o singur citire pentru
recuperarea datelor. O baz de date relaional necesit patru cutri indexate i cel puin
patru citiri pentru a recupera datele.
Dezavantajul n acest caz este acela c viteza de recuperare este mare numai atunci
cnd datele din comand sunt stocate pe disc. Dac se dorete recuperarea altor date, cum ar
fi o list a clienilor i ordinele de vnzare ale lor, atunci performanta va fi mai slab dect
Pagina 35 din 97
ntr-o baz de date relaional. Astfel, stocarea datelor ntr-o baz de date nativ XML se
recomand din motive de performana atunci cnd predomin o singur vedere asupra datelor.
Al treilea motiv pentru stocarea datelor ntr-o baz de date nativ XML este
exploatarea capacitilor specifice XML, cum ar fi executarea interogrilor XML. Deoarece
relativ puine aplicaii centrate pe date au nevoie de acestea i bazele de date relaionale
implementeaz limbaje de interogare XML, acest motiv nu este foarte important.
O problem cu stocarea datelor ntr-o baz de date nativ XML este c majoritatea
acestor baze de date pot returna datele numai ca XML. (Puine baze de date suport legarea
elementelor sau atributelor de variabilele dintr-o aplicaie.) Dac o aplicaie are nevoie de
date ntr-un alt format (ceea ce este posibil), aceasta trebuie s analizeze XML-ul nainte de a
folosi datele. Acesta este un dezavantaj pentru aplicaiile locale care folosesc o baz de date
nativ XML n locul unei baze de date relaionale.
3.3.4 Tipuri de date, valori nule, seturi de caractere
Aceast seciune se ocup de anumite probleme legate de stocarea datelor din
documente XML n baze de date tradiionale. Problemele legate de tipurile de date i datele
binare apar i n cazul stocrii datelor n baze de date native XML. n general utilizatorul nu
poate alege modalitatea n care sotf-ul care transfer datele rezolv aceste probleme, dar
atunci cnd se alege un anumit soft trebuie inut cont de faptul c aceste probleme exist.
3.3.4.1 Tipuri de date

XML nu suport prea multe tipuri de date. Cu excepia entitilor neanalizate, toate
datele dintr-un document XML sunt text, chiar dac reprezint alt tip de date, cum ar fi datele
calendaristice sau integer. n general soft-ul de transfer date va transforma textul (din
documentul XML) n alte tipuri de date (n baza de date) i invers.
Softul determin ce conversii sunt necesare i exist dou metode pentru efectuarea
acestora. Prima metod const n determinarea de ctre software a tipurilor de date din
schema bazei de date, deoarece aceasta este accesibil la rulare. (Schema XML nu este
neaprat accesibil la rulare sau s-ar putea sa nu existe.) n a doua metod utilizatorul
specific tipul de date. Acesta poate fi scris de ctre utilizator sau generat automat dintr-o
schem a unei baze de date sau dintr-o schem XML. Atunci cnd sunt generate automat,
tipurile de date pot fi recuperate din schemele bazelor de date i din anumite tipuri de scheme
XML.
Pagina 36 din 97
Formatele de text recunoscute n momentul conversiilor pot constitui o problem

atunci cnd se transfer date din XML, la fel i formatele care se pot crea atunci cnd se
transfer date ctre XML. n cele mai multe cazuri, numrul de formate de text care sunt
suportate de un tip de dat este limitat la unul anume sau la cele suportate de driverul JDBC.
Datele pot cauza multe probleme pentru c gama de formate posibile este foarte mare, iar
numerele cu diferitele lor formate internaionale pot cauza de asemenea probleme.
3.3.4.2 Date binare
Datele binare se pot stoca n documente XML n trei feluri: codificare Base64 (o
codificare MIME care mapeaz datele binare pe un subset al US-ASCII [0-9, a-z, A-Z,+,/]),
codificarea hexazecimal (fiecare octet binar este codificat cu dou caractere reprezentnd
cifre hexazecimale [0-9,a-f,A-F]), i entiti neanalizate (datele binare sunt stocate ntr-o
entitate fizic separat de restul documentului XML).
Cea mai mare problem cu datele binare este c multe dintre produsele care transfer
date nu suport acest tip de date. O problem secundar apare dac sunt folosite entiti
neanalizate i const n faptul c majoritatea produselor nu stocheaz notaii i declaraii de
entiti. Astfel, notaia asociat cu o anumit entitate va fi pierdut atunci cnd datele sunt
transferate dintr-un document XML ntr-o baz de date.
3.3.4.3 Date vide

n domeniul bazelor de date, date vide sunt numite datele care nu exist. Acestea sunt
foarte diferite de valoarea 0 (pentru numere), sau lungimea zero (pentru un string). De
exemplu, se ia n considerare o colecie de date de la o staie meteo. Dac termometrul nu
funcioneaz, n baza de date este stocat o valoare nul i nu valoarea zero, care ar nsemna
cu totul altceva.
XML suport de asemenea conceptul de date vide prin tipuri de elemente i atribute
opionale. Dac valoarea unui tip sau atribut opional este nul acesta nu este inclus n
document. n cazul bazelor de date, atributele care conin iruri de caractere cu lungimea zero
sau elemente nule nu sunt vide, valoarea lor este un ir cu lungimea zero.
La maparea structurii unui document XML la baza de date i invers, tipurile de date i
atributele opionale sunt mapate ca i coloane vide. Dac nu se procedeaz n acest mod s-ar
putea inserarea o eroare (atunci cnd se transfer date n baza de date), sau la un document
invalid (atunci cnd se transfer date din baza de date).
Pagina 37 din 97
3.3.4.4 Seturi de caractere

Un document XML poate conine orice caracter Unicode cu excepia unor caractere
de control. Din nefericire, multe baze de date ofer suport limitat sau nu ofer suport deloc
pentru Unicode i necesit o configuraie special pentru caracterele non-ASCII.
3.3.4.5 Instruciuni de procesare i comentarii
Instruciunile de procesare i comentariile nu fac parte din datele dintr-un document
XML i majoritatea soft-urilor de transfer de date nu le pot manipula. Totui ele pot aprea
aproape oriunde ntr-un document XML i de aceea nu se integreaz uor n maprile bazate
pe tabele i cele obiectual relaionale. O soluie total ineficient ntr-o baz de date relaional
este adugarea unor tabele pentru instruciuni de procesare i comentarii, adugarea de chei
strine la aceste tabele pentru toate celelalte tabele, i verificarea acestor tabele de fiecare
data cnd se proceseaz o alt tabel. Astfel majoritatea soft-urilor de transfer de date le
nltur.
3.3.4.6 Stocarea marcajelor
n anumite situaii este indicat stocarea elementelor cu coninut mixt n baza de date
fr a se efectua analiza complet. Cnd este realizat acest lucru, marcajul este realizat cu
caractere de marcare. Totui apare o problem la stocarea caracterelor de marcare care nu
sunt folosite pentru marcaj. n fiierul XML, acestea sunt stocate folosind entitatile lt, gt,
amp, quot, i apos. Acest lucru poate fi fcut i n baza de date. De exemplu urmtoarea
descriere:
<descriere>
Exemplu confuz: <foo/>
</descriere>
poate fi stocat n baza de date ca:
Totui apare o problem, limbajele de interogare non-XML, cum ar fi SQL, nu caut
n coloane marcaje sau folosirea de entiti i le interpreteaz ca atare. Astfel, dac se caut
irul <foo/> cu SQL, de fapt trebuie cutat irul <foo/>.
Pagina 38 din 97
Pe de alt parte, dac referinele la entiti sunt extinse, software-ul de transfer de date
nu poate distinge ntre marcaj i folosirea entitilor. De exemplu, dac descrierea de mai sus
este stocat n baza de date n forma urmtoare, soft-ul nu poate spune dac ,, i
<foo/> sunt marcaje sau text:
Soluia pe termen lung la aceast problem sunt bazele de date care recunosc XML, n
care marcajul efectiv e tratat diferit de elementele care doar par a fi marcaj. Dar, probabil vor
fi ntotdeauna probleme atunci cnd aplicaii non-XML lucreaz cu XML.
3.3.5 Generarea schemelor XML din scheme relaionale i invers
O ntrebare care apare frecvent la transferul datelor ntre documente XML i baze de
date este cum se genereaz scheme XML din scheme ale bazelor de date i invers. nainte de
a explica cum se face acest lucru, este bine de reinut faptul c aceasta este o operaie designtime. Motivul pentru acest lucru este c majoritatea aplicaiilor centrate pe date, i cele mai
multe aplicaii pe vertical, lucreaz cu un set cunoscut de scheme XML i scheme de baze de
date. Astfel ele nu trebuie s genereze scheme n momentul rulrii. n plus procedurile pentru
generarea schemelor nu sunt perfecte. Aplicaiile care trebuie s rein documente XML
aleatoare ntr-o baz de date ar trebui s foloseasc o baz de date nativ XML n loc s
genereze scheme la rulare.
Cea mai uoar cale de a genera scheme relaionale din scheme XML i invers este de
a codifica o cale prin maparea obiectual relaional, care are un numr de trsturi opionale.
O schem relaional se genereaz dintr-o schema XML astfel:
Pentru fiecare tip complex de elemente trebuie creat o tabel i o coloan cheie
primar.
Pentru fiecare tip de elemente cu coninut mixt, trebuie creat o tabel separat n care
se va stoca PCDATA, legat de tabela printe prin intermediul cheii primare din tabela
printe.
Pentru fiecare atribut cu o singur valoare a acelui tip de element, i pentru fiecare
element descendent simplu care apare o singur dat trebuie creat o coloan n acel tabel.
Dac schema XML conine informaia despre tipurile de date, atunci trebuie setate tipurile de
date ale coloanelor la tipul corespunztor. Altfel, tipurile de date trebuie setate la un tip
predeterminat, cum ar fi CLOB sau VARCHAR(255). Dac tipul elementelor descendente
sau al atributelor este opional coloana trebuie s aib posibilitatea de a fi setat nul.
Pagina 39 din 97
Pentru fiecare atribut cu mai multe valori i pentru fiecare element descendent simplu
care apare de mai multe ori trebuie creat o tabel separat pentru a stoca valorile, legat de
tabela printe prin intermediul cheii primare din tabela printe.
Pentru fiecare element descendent complex, trebuie legat tabela tipului elementului
printe de tabela tipului elementului descendent prin intermediul cheii primare din tabela
printe.
O schema XML se genereaz dintr-o schem relaional astfel:
Pentru fiecare tabel se genereaz un tip de element
Pentru fiecare coloan care nu este cheie n acea tabel, dar i pentru coloanele chei
primare, se adaug la model un atribut la tipul elementului sau un element descendent ce
conine numai PCDATA.
La fiecare tabel pentru care cheia primar este exportat, se adaug un element
descendent la model i se proceseaz tabela recursiv.
Pentru fiecare cheie strina, se adaug un element descendent la model i se
proceseaz tabela cu cheie strin recursiv.
Exist cteva dezavantaje la aceste procedee. Multe dintre acestea se pot corecta uor
de ctre programator, cum ar fi coliziuni de nume i specificarea lungimilor i tipurilor de
date ale coloanelor. DTD-urile nu conin informaii despre tipurile de date, deci nu este
posibil cunoaterea tipurilor de date care ar trebui folosite n baza de date. Tipurile de date i
lungimile pot fi prevzute dintr-o schem XML.
O problem mai important este aceea c modelul de date folosit de documentul XML
este adesea diferit i de obicei mai complex dect cel mai eficient model pentru stocarea
datelor n baza de date. De exemplu, se consider urmtorul fragment XML:
<Client>
<Nume>ABC Industries</Nume>
<Adresa>
<Strada>123 Main St.</Strada>
<Oras>Fooville</Oras>
<Stat>CA</Stat>
<Tara>USA</Tara>
<CodPostal>95041</CodPostal>
</Adresa>
</Client>
Pagina 40 din 97
Procedura pentru generarea unei scheme relaionale dintr-o schem XML ar crea dou
tabele: una pentru clieni i una pentru adrese. Totui n majoritatea cazurilor ar fi mai bine s
se rein adresa n tabela de clieni, i nu ntr-o tabel separat.
Elementul <Adresa> este un bun exemplu pentru un element wrapper. Elementele
wrapper sunt n general folosite din dou motive. n primul rnd, ele ofer structuri adiionale
ceea ce face documentul mai uor de neles. n al doilea rnd, ele sunt de obicei folosite ca o
form de redactare a datelor. De exemplu, elementul <Adresa> ar putea fi trimis la o rutin
care transform toate adresele n obiecte Adresa, indiferent unde apar acestea.
Daca elementele wrapper sunt folositoare n XML, n general ele cauzeaz probleme
atunci cnd sunt mapate la baza de date dac acestea se gsesc sub forma extra-structurilor.
Din aceast cauz, ele ar trebui eliminate din schema XML naintea generrii schemei
relaionale. Din moment ce este puin probabil c modificarea schemei XML ar trebui s fie
permanent, acest lucru duce la o neconcordan ntre documentul existent i documentele
presupuse de ctre soft-ul de transfer de date, din moment ce elementele wrapper nu sunt
incluse n mapare. Acest lucru poate fi rezolvat prin transformarea documentelor la rulare cu
XSLT: elementele wrapper sunt eliminate naintea transferrii datelor n baza de date i sunt
inserate dup transferul datelor din baza de date.
Cu toate aceste dezavantaje, procedurile de mai sus ofer n continuare un punct de
pornire folositor pentru generarea schemelor XML din scheme relaionale i invers, n special
n sisteme mari.
3.4 Stocarea i recuperarea documentelor
Pentru stocarea documentelor XML exist dou strategii de baz: stocarea lor n
sistemul de fiiere sau ca un BLOB ntr-o baz de date relaional i acceptarea
funcionalitilor XML limitate, sau stocarea lor ntr-o baz de date nativ XML.
3.4.1 Stocarea documentelor n sistemul de fiiere
Dac se lucreaz cu un set simplu de documente, cum ar fi un set mic de
documentaie, cea mai uoara cale de stocare este n sistemul de fiiere. Se pot folosi
instrumente cum ar fi grep pentru interogarea lor, i sed pentru modificarea lor. Cutrile
complete de text n documentele XML sunt inexacte, pentru c ele nu pot distinge marcajul
de text i nu pot nelege folosirea entitilor. Totui, ntr-un sistem mic, aceste inexactiti ar
putea fi acceptabile. Dac se dorete un simplu control al tranzaciilor, documentele pot fi
ntreinute cu o versiune de control a sistemului cum ar fi CVS sau RCS.
3.4.2 Stocarea documentelor n BLOB-uri
Pagina 41 din 97
O opiune puin mai sofisticat este stocarea documentelor ca BLOB-uri ntr-o baz
de date relaional. Aceast modalitate ofer un numr de avantaje a bazelor de date:
controlul tranzaciilor, securitate, acces multiuser. n plus, multe baze de date au instrumente
pentru cutri de text i pot face cutri complete de text, cutri aproximative, cutri
sinonime i cutri fuzzy. Unele dintre aceste instrumente sunt construite pentru a recunoate
XML, ceea ce va elimina problemele care apar la cutrile documentelor XML ca simplu
text.
Atunci cnd se stocheaz documente XML ca BLOB-uri, se pot implementa uor
indexri simple care recunosc XML, chiar dac baza de date nu poate indexa XML. O
modalitate de a face acest lucru este crearea a dou tabele, o tabel index i o tabel
document. Tabela document conine o cheie primar i o coloan BLOB n care este reinut
documentul. Tabela index conine o coloan n care se gsete valoarea ce va fi indexat i o
cheie strin care duce la cheia primar a tabelei document.
Atunci cnd documentul este stocat n baza de date, el este cutat pentru toate
instanele elementului sau atributului care este indexat. Fiecare instana este stocat n tabela
index, mpreuna cu cheia primara a documentului. Coloana de valori este apoi indexat, i
permite unei aplicaii s efectueze o cutare rapid a unei anumite valori a unui element sau
atribut i s recupereze documentul corespunztor.
De exemplu, se consider un set de documente cu urmtorul DTD i se dorete
construirea unui index de autori:
<!ELEMENT Brosura (Titlu, Autor, Continut)>
<!ELEMENT Titlu (#PCDATA)>
<!ELEMENT Autor (#PCDATA)>
<!ELEMENT Continut (%Inline;)> 
Acestea ar putea fi stocate n urmtoarele tabele:
Autori Brosuri
---------------------- --------Autor VARCHAR(50) BrosurID INTEGER
BrosuraID INTEGER Brosura LONGVARCHAR
Cnd se insereaz o brour n baza de date, aplicaia insereaz broura n tabela
Brouri, apoi caut elementele <Autor>, reinnd valorile acestora i ID-ul brourii din tabela
Autori. Aplicaia poate recupera brourile n funcie de autor cu o simpl fraza SELECT. De
Pagina 42 din 97
exemplu, pentru a recupera toate brourile scrise de autorul Chen, aplicaia execut
urmtoarea interogare:
SELECT Brosura
FROM Brosuri
WHERE BrosuraID IN (SELECT BrosuraID FROM Autori WHERE Autor= 'Chen')
O tabel de indeci mai sofisticat ar conine patru coloane: numele atributului sau
elementului, tipul, valoarea i ID-ul documentului. Aceasta tabel ar putea stoca valorile
marcajelor multiple i ar trebui indexat dup nume, tip, i valoare. Scrierea unei aplicaii
generice SAX pentru a popula o astfel de tabel ar fi relativ uoar.
3.4.3 Baze de date native XML
Dac sunt necesare mai multe caracteristici dect cele oferite de unul din sistemele de
mai sus, trebuie luat n considerare o baz de date nativ XML. Bazele de date native XML
sunt baze de date construite special pentru a stoca documente XML. Ca i alte baze de date,
acestea suport tranzacii, securitate, acces multiuser, API-uri programatice, limbaje de
interogare. Singura diferen fa de alte baze de date este aceea c modelul lor interior este
bazat pe XML i nu pe altceva, ca n cazul modelului relaional.
Bazele de date native XML sunt de obicei folosite pentru a stoca documente centrate
pe documente. Principalul motiv este c ofer suport pentru limbaje de interogare XML, care
ofer posibilitatea adresrii unor ntrebri de forma: Extrage toate documente n care al
treilea paragraf de la nceputul seciunii conine un cuvnt ngroat, sau ofer posibilitatea
limitrii cutrilor complete de text la anumite poriuni din document. Asemenea interogri
sunt dificil de scris ntr-un limbaj ca SQL. Un alt motiv este acela c bazele de date native
XML pstreaz ordinea documentelor, instruciunile de procesare, i comentarii, i adesea
pstreaz seciuni CDATA, folosirea entitilor, i altele, pe cnd bazele de date ce permit
folosirea XML nu posed aceste caracteristici.
Bazele de date native XML sunt de obicei folosite pentru a integra date. Integrarea
datelor a fost fcut cu baze de date relaionale federate, dar acestea necesitau ca toate
resursele de date s fie mapate la modelul relaional. Aceast modalitate nu funcioneaz
pentru mai multe tipuri de date i modelul de date XML ofer o flexibilitate mai mare. Bazele
de date native XML trateaz modificrile schemelor mai uor dect bazele de date relaionale
i pot trata i date care nu au schem. Ambele consideraii sunt importante pentru integrarea
datelor din surse care nu se afl sub control direct.
Pagina 43 din 97
Al treilea caz de utilizare major al bazelor de date native XML este pentru datele
semistructurate, aa cum se gsesc n finane, n biologie, date care se schimb att de des
nct nu este posibil definirea unor scheme definitive. Datorit faptului c bazele de date
native XML nu necesit scheme, ca bazele de date relaionale, ele pot s trateze acest tip de
date, dei aplicaiile adesea necesit procesarea acestor date de ctre oameni.
Ultima utilizare majora a bazelor de date native XML este tratarea evoluiei
schemelor. Chiar dac bazele de date native XML nu ofer soluii complete, ele ofer o
flexibilitate mai mare dect bazele de date relaionale. De exemplu, bazele de date native
XML nu necesit ca datele existente s fie mutate ntr-o alt schem, ele pot trata modificri
ale schemelor pentru care nu exist nicio cale a migraiei, i pot stoca date chiar dac acestea
aparin unei versiuni necunoscute a unei scheme.
Alte utilizri ale bazelor de date native XML includ punerea la dispoziie de cache
pentru date i metadate pentru tranzacii lungi, operarea cu documente mari i date ierarhice,
i comportarea ca un intermediar ntre date i cache (mid-tier data cache).
3.4.3.1 Ce este o baz de date nativ XML?
Termenul baz de date nativ XML a aprut prima dat n campania de marketing a
Tamino, o baz de date nativ XML dezvoltat de Software AG. Probabil datorit succesului
acestei campanii, termenul a fost acceptat de ctre companiile care dezvoltau produse
similare. Dezavantajul acestui termen este c fiind un termen de marketing, nu a avut
niciodat o definiie formal tehnic.
O definiie posibila (dezvoltat de membrii XML:DB) este aceea c o baz de date
nativ XML are urmtoarele caracteristici:
Definete un model logic pentru un document XML spre deosebire de datele din
acel document i stocheaz i recupereaz documente conform acelui model. Modelul
trebuie s includ minim elemente, atribute, PCDATA, i ordinea documentelor. Exemple de
astfel de modele sunt modelul de date Xpath, XML Infoset, i modelele coninute de DOM i
evenimentele din SAX 1.0.
Are ca unitate fundamental de stocare logic un document XML, aa cum o baz de
date relaional are ca unitate de baz de stocare logic o linie dintr-o tabel.
Nu este necesar un model fizic special de stocare a datelor. De exemplu, acesta poate
fi construit pe o baz de date relaional, ierarhic, sau orientat pe obiecte, sau se poate
folosi un format de stocare particular cum ar fi fiierele comprimate indexate.
Pagina 44 din 97
Prima parte a acestei definiii este similar cu definiiile altor tipuri de baze de date, i
se concentreaz pe modelul folosit de baza de date. Nu are nicio importan faptul c o
anumit baz de date nativ XML ar putea stoca mai multe informaii dect conine modelul
folosit de baza de date. De exemplu, ar putea suporta interogri bazate pe modelul Xpath, dar
s stocheze documente ca text. n acest caz, seciunile CDATA i folosirea entitilor sunt
stocate n baza de date dar nu sunt incluse n model.
A doua parte a definiiei spune c unitatea de baz de stocare ntr-o baz de date
nativ XML este un document XML. Dei poate prea posibil ca o baz de date nativ XML
ar putea atribui acest rol fragmentelor de documente, bazele de date native XML sunt
populate cu documente complete.
Unitatea de baz de stocare este nivelul elementar de context n care se potrivete un
anumit element de date, i este echivalent cu o linie ntr-o baz de date relaional. Existena
acestei uniti de baz nu mpiedic recuperarea unor uniti mai mici de date, cum ar fi
fragmente de documente sau elemente individuale, i nu exclude nici posibilitatea combinrii
fragmentelor dintr-un document cu fragmente din alt document. n termeni relaionali, acest
lucru este echivalent cu faptul c existena liniilor nu mpiedica recuperarea individual a
valorilor din coloane sau crearea unor linii noi din altele existente deja.
A treia parte a definiiei spune c formatul de stocare nu este important. Acest lucru
este adevrat, i este analog cu faptul c formatul fizic de stocare folosit de o baz de date
relaional nu are legtur cu faptul ca baza de date este relaional.
3.4.3.2 Arhitecturile bazelor de date native XML
Arhitecturile bazelor de date native XML se clasific n dou categorii: bazate pe text
i bazate pe modele.
Baze de date native XML bazate pe text
O baz de date nativ XML bazat pe text stocheaz XML ca text. Acesta ar putea fi
un fiier ntr-un sistem de fiiere, un BLOB ntr-o baz de date relaional, sau un format de
text particular. Nu are nicio importan faptul c o baz de date relaional care a adugat
procesarea ce recunoate XML a coloanelor CLOB (Character Large Object) este, de fapt, o
baz de date nativ XML avnd n vedere aceste abiliti.
Toate bazele de date native XML bazate pe text au n comun indecii, care ofer
posibilitatea motorului de interogare s sar uor n orice punct din orice document XML.
Acest lucru d o vitez extraordinar la recuperarea documentelor ntregi sau a fragmentelor
Pagina 45 din 97
de documente. Acest lucru se ntmpla deoarece baza de date poate executa o singur cutare
indexat, poate poziiona capul de citire o singur dat, i, presupunnd c fragmentul necesar
este stocat continuu pe disc, poate recupera ntregul document sau fragment cu o singur
citire. Spre deosebire de aceasta modalitate, reasamblarea unui document din fragmente, cum
se face n cazul bazelor de date relaionale i unele baze de date native XML bazate pe
modele, necesit cutri indexate multiple i mai multe citiri ale discului.
n acest sens, o baz de date nativ XML bazat pe text este similar cu bazele de date
ierarhice, amndou avnd performane mai bune dect bazele de date relaionale la
recuperarea i returnarea datelor n funcie de o ierarhie predefinit. La fel ca bazele de date
ierarhice, bazele de date native XML bazate pe text ar putea ntmpina dificulti la
recuperarea i returnarea datelor n orice alt form, cum ar fi inversarea ierarhiei sau a unor
poriuni ale ei. Acest lucru nu a fost dovedit nc, dar predominana bazelor de date
relaionale, care folosesc pointeri logici ce permit ca toate interogrile de aceeai
complexitate s fie executate cu aceeai vitez, pare s indice c aa se va ntmpla.
Baze de date native XML bazate pe modele
A doua categorie de baze de date native XML este cea bazat pe modele. n loc s
stocheze documentul XML ca text, aceste baze de date construiesc un model obiectual intern
din document i stocheaz acest model. Modalitatea reinerii acestui model depinde de baza
de date. Unele baze de date stocheaz modelul ntr-o baz de date relaional sau orientat
obiect. De exemplu, stocarea DOM-ului ntr-o baz de date relaional ar putea duce la
obinerea unor tabele cum ar fi Elements, Attributes, PCDATA, Entities, i EntityReferences.
Alte baze de date folosesc un format de stocare particular optimizat pentru modelul lor.
Un exemplu de baz de date simpl nativ XML bazat pe un model construit pe o
baz de date relaional este cea descrisa de Mark Birbeck la XML-L n decembrie 1998.
Sistemul folosete cinci tabele definirea atributelor, asocierile dintre elemente/atribute,
definirea coninutului modelului, valorile atributelor, i valorile elementelor (PCDATA sau
pointeri la alte elemente) i un model care include numai elemente, atribute, text, i ordinea
documentelor.
Bazele de date native XML bazate pe modele construite pe alte baze de date vor avea
performane similare cu acele baze de date la recuperarea documentelor pentru c ele se
bazeaz pe acele sisteme pentru a recupera datele. Totui, designul bazei de date, n special
pentru bazele de date native XML construite pe baze de date relaionale poate varia destul de
mult. De exemplu, o baz de date care folosete o mapare obiectual-relaional direct a
Pagina 46 din 97
DOM-ului ar putea duce la un sistem care necesit executarea frazelor SELECT separat
pentru a recupera descendenii fiecrui nod. Pe de alt parte, majoritatea acestor baze de date
i optimizeaz modelul de stocare i softul de recuperare. De exemplu, Richard Edwards a
descris un sistem de stocare a DOM-ului ntr-o baz de date relaional care poate recupera
orice fragment de document (inclusiv ntregul document) cu o singur fraza SELECT.
Este probabil c bazele de date native XML bazate pe modele care folosesc un format
de stocare particular s aib performane similare cu cele native XML bazate pe text la
recuperarea datelor n ordinea n care au fost stocate. Acest lucru se ntmpl deoarece
majoritatea acestor baze de date folosesc pointeri fizici ntre noduri, ceea ce ar trebui s duc
la o performan similar cu recuperarea textului. (Rapiditatea unei metode sau alteia depinde
i de formatul de ieire. Sistemele bazate pe text sunt mai rapide la returnarea documentelor
ca text, pe cnd sistemele bazate pe modele sunt mai rapide la returnarea documentelor ca
arbori DOM, presupunnd c modelul lor se mapeaz uor la DOM.)
Ca i bazele de date native XML bazate pe text, e probabil c i cele bazate pe modele
s ntmpine probleme de performan la recuperarea i returnarea datelor ntr-un formular,
altul dect cel n care sunt stocate, cum ar fi inversarea ierarhiei sau a unor poriuni a ei. Nu
se tie dac aceste baze de date vor fi mai rapide sau nu dect cele bazate pe text.
3.4.3.3 Caracteristici ale bazelor de date native XML
n aceast seciune sunt prezentate un numr de caracteristici ale bazelor de date
native XML.
Colecii de documente
Multe baze de date native XML suport noiunea de colecie. Acestea au un rol similar
cu cel al tabelelor n bazele de date relaionale sau cu cel al directoarelor ntr-un sistem de
fiiere. De exemplu, dac se folosete o baz de date nativ XML pentru stocarea unor ordine
de vnzare, ar trebui definit o colecie de ordine de vnzare astfel nct interogrile cu
privire la ordinele de vnzare s poat fi limitate la documentele din acea colecie.
Ca un alt exemplu, dac se stocheaz manualele pentru toate produsele unei companii
ntr-o baz de date nativ XML, ar trebui definit o ierarhie de colecii, o colecie pentru
fiecare produs, i n acea colecie, cte o colecie pentru fiecare capitol din fiecare manual.
Limbaje de interogare
Aproape toate bazele de date native XML suport unul sau mai multe limbaje de
interogare. Cel mai popular este Xpath (cu extensii pentru interogri asupra mai multor
Pagina 47 din 97
documente) i Xquery, dei numeroase limbaje de interogare particulare sunt suportate de

asemenea.
n viitor, majoritatea bazelor de date native XML vor suporta XQuery din W3C.
Updatri i tergeri
Bazele de date native XML au o varietate de strategii pentru actualizarea i tergerea
documentelor, de la simpla nlocuire sau tergere a documentului existent pn la modificarea
arborelui DOM, pn la limbaje care specific cum s se modifice fragmente ale unui
document. Majoritatea acestor metode sunt particulare. Totui, au aprut dou limbaje
ntructva standardizate pentru actualizarea documentelor XML:
XUpdate, de la XML:DB Initiative, este un limbaj bazat pe XML. Folosete XPath
pentru a identifica un set de noduri, apoi specific dac s se insereze sau s se tearg aceste
noduri, sau s insereze noduri noi naintea sau dup acestea. XUpdate a fost implementat n
mai multe baze de date native XML.
Un set de extensii ale XQuery a fost propus de membrii grupului W3C XQuery i
Patrick Lehti. Variaii asupra acestor extensii au fost implementate n mai multe baze de date
native XML i pare probabil c acestea vor forma bazele sintaxei pentru actualizare n
XQuery.
n ciuda acestor limbaje, este probabil ca abilitile de actualizare s rmn
fragmentate pn cnd va fi adugat formal o sintax de actualizare la XQuery.
Tranzacii, blocri, i concuren
Aproape toate bazele de date native XML suport tranzacii (i probabil suport i
ntoarceri). Totui, blocarea se face adesea la nivelul ntregului document, i nu la nivelul
unui nod individual, de aceea concurena multi-user este relativ redus. Dac aceasta este o
problem depinde de aplicaie i ceea ce constituie un document. De exemplu:
Un document este un capitol al unui ghid al utilizatorului i scriitorii editeaz
capitolele. Este puin probabil ca blocarea la nivel de document s cauzeze probleme de
concuren, deoarece este improbabil ca doi scriitori s actualizeze acelai capitol n acelai
moment.
Un document stocheaz toate datele despre toate vnzrile i vnztorii adaug
informaii despre noile vnzri. Este probabil ca blocarea la nivel de document s determine
probleme de concuren, deoarece ansele ca doi vnztori s actualizeze informaii n acelai
timp este destul de mare. Din fericire, acest lucru poate fi rezolvat cel puin parial prin
crearea unui document de vnzare pentru fiecare client.
Pagina 48 din 97
Un document conine datele folosite ntr-un flux, cum ar fi un contract financiar.

Fiecare pas al fluxului citete date dintr-un computer i adaug datele proprii. De exemplu, un
pas ar putea face o verificare de credit i ar aduga un credit la document. Un alt pas ar putea
cuta balane n ateptare n alte contracte ale aceluiai client i ar putea aduga totalul
balanelor. Dac blocarea la nivel de nod este folosit, unii dintre aceti pai ar putea fi
executai n paralel. Dac este folosit blocarea la nivel de document, aceti pai ar trebui
executai secvenial pentru a evita conflicte de scriere. Acest lucru ar putea aduce ntrzieri
inacceptabile n aplicaii mari.
Problema blocrii la nivel de nod este implementarea acesteia. Blocarea unui nod
necesit de obicei blocarea printelui su, ceea ce necesit blocarea printelui acestuia, i aa
pn la rdcin, blocnd efectiv ntregul document. Pentru a vedea de ce acest lucru este
adevrat, se consider o tranzacie care citete un nod frunz. Dac tranzacia nu are blocri
pe strmoii nodului frunz, o alt tranzacie poate terge un nod strmo al frunzei, astfel
tergnd i nodul frunz. Totui, o alt tranzacie ar trebui s poat actualiza acele pri ale
documentului care nu sunt pe calea direct de la rdcin la nodul frunz.
O soluie parial a acestei probleme este propus de Stijn Dekeyser n timp ce
problema blocrii strmoilor unui nod int nu a fost total ocolit, aceste blocri au fost
fcute mai flexibile prin adnotarea lor cu definirea prin interogare a cii de la nodul blocat
pn la nodul int. Acest lucru permite altor tranzacii s determine dac sunt n conflict cu
alte tranzacii. Deoarece evaluarea interogrilor pentru a obine blocri este foarte
costisitoare, schema actual este ntructva mai limitat dect a fost descris aici, dar acesta
este principiul de funcionare.
n viitor, majoritatea bazelor de date native XML vor oferi probabil posibilitatea
blocrii la nivel de nod.
Interfee de programare a aplicaiilor (API-uri)
Majoritatea bazelor de date native XML ofer API-uri programatice. Acestea sunt de
obicei sub forma unei interfee asemntoare ODBC, cu metode pentru legarea la baza de
date, explorarea metadatelor, executarea interogrilor, i recuperarea rezultatelor. Rezultatele
sunt de obicei returnate ca un ir XML, un arbore DOM, sau un Parser SAX, sau un
XMLReader peste documentul returnat. Dac interogrile pot returna documente multiple,
atunci metodele pentru parcurgerea rezultatelor sunt de asemenea disponibile. Dei
majoritatea bazelor de date native XML ofer API-uri particulare au fost dezvoltate dou
API-uri independente (iulie 2004):
Pagina 49 din 97
API-ul XML:DB al XML:DB.org care este independent de limbajul de programare, i

folosete XPath ca limbajul su de interogare, i este extins pentru a suporta XQuery. A fost
implementat pentru mai multe baze de date native XML i se poate s fi fost implementat i
pentru baze de date care nu sunt native XML.
JSR 225: XQuery API pentru Java (XQJ) este bazat pe JDBC i folosete XQuery ca
limbaj de interogare. Este dezvoltat de ctre Java Community Process (JCP) de la Sun.
Deoarece aceast iniiativa este condus de IBM i Oracle este probabil rspndirea ei la
scar larg.
Majoritatea bazelor de date native XML ofer de asemenea posibilitatea executrii
interogrilor i returnarea rezultatelor prin HTTP.
Round-Tripping
O caracteristic important a bazelor de date native XML este c pot efectua un
round-trip al documentelor XML. Acest lucru nseamn c se poate stoca un document
XML ntr-o baz de date nativ i se poate recupera din baza de date acelai document. Acest
lucru este important pentru aplicaiile centrate pe documente, pentru care seciunile CDATA,
folosirea entitilor, comentariile i procesarea instruciunilor sunt o parte integrant a
documentului. De asemenea este foarte important pentru multe aplicaii medicale i legale,
care sunt obligate prin lege sa pstreze copii fidele ale documentelor.
Round-tripping-ul este mai puin important pentru aplicaiile centrate pe date, pentru
care de obicei conteaz elementele, atributele, textul, i ordinea ierarhic. Toate softurile care
transfer date ntre documente XML i baze de date pot executa acest procedeu cu aceste
date. Aceleai operaii pot fi aplicate i unor ordonri similare (ordinea elementelor i a
PCDATA n printele lor) ntr-un numr limitat de cazuri care sunt importante pentru
aplicaiile centrate pe date. Totui deoarece nu pot face aceste operaii n toate cazurile, i nici
asupra instruciunilor de procesare, comentariilor, i structurilor fizice (referinele ctre
entiti, seciuni CDATA), nu sunt potrivite pentru aplicaii centrate pe documente.
Toate bazele de date native XML pot aplica round-tripping-ul la nivelul elementelor,
al atributelor, al PCDATA, i al ordinii documentelor. Ct de mult se poate aplica acest
procedeu depinde de baza de date. Ca o regul general, bazele de date native XML bazate pe
text aplic acest procedeu pe documentele XML exact, n timp ce bazele de date native XML
bazate pe modele aplic acest procedeu asupra documentelor XML la nivelul modelului. n
cazul modelelor minimale de documente, acest procedeu se face la un nivel mai mic dect
XML-ul canonic.
Pagina 50 din 97
Din moment ce nivelul de round-tripping depinde de fiecare aplicaie, i alegerea

bazei de date native XML potrivite poate varia.
Date aflate la distan
Unele baze de date native XML pot include date aflate la distan n documente
stocate n baza de date. De obicei aceste date sunt recuperate dintr-o baz de date relaional
cu ODBC, OLE DB, sau JDBC i sunt modelate folosind maparea bazat pe tabele sau
maparea relaional-obiectual. Daca aceste date sunt live adic dac actualizrile
documentului din baza de date nativ XML sunt reflectate n baza de date aflat la distan
depinde de baza de date nativ XML. n viitor majoritatea bazelor de date native XML vor
suporta date live aflate la distan.
Indeci
Toate bazele de date native XML suport indeci ca o modalitate de a mri viteza de
interogare. Exista trei tipuri de indeci. Indecii valoare indexeaz text i valori ale atributelor
i sunt folosii pentru a rezolva interogri de forma: Gsete toate elementele sau atributele
ale cror valori sunt Santa Cruz. Indecii structurali indexeaz locaia elementelor i
atributelor i sunt folosii pentru a rezolva interogri de forma: Gsete toate elementele
adres. Indecii valoare i structurali sunt combinai pentru a rezolva interogri de forma:
Gsete toate elementele orae ale cror valori sunt Santa Cruz. Indecii full-text
indexeaz semnele individuale din text i valorile atributelor i sunt folosii pentru a rezolva
interogri de forma: Gsete toate documentele care conin cuvintele Santa Cruz. sau n
conjuncie cu indecii structurali :Gsete toate documentele care conin cuvintele Santa
Cruz ntr-un element adres.
Majoritatea bazelor de date native XML suport att indeci valoare ct i indeci
structurali. Unele baze de date native XML suport indeci full-text.
Stocarea entitilor externe
O problem dificil care apare la stocarea documentelor XML este tratarea entitilor
externe. Adic, ar trebui extinse i valorile lor stocate mpreuna cu restul documentului, sau
ar trebui ca referinele la entiti s fie lsate la locul lor? Aceast ntrebare nu are rspuns
unic.
De exemplu, se consider c un document include o entitate extern general care
apeleaz un program CGI pentru prognoza meteo. Dac documentul este folosit ca o pagina
Web care ofer prognoza meteo, ar fi o greeal extinderea referinei la entitate, deoarece
pagina de Web nu ar mai returna date live. Pe de alt parte, dac documentul ar fi o parte a
Pagina 51 din 97
unei colecii de date despre vreme mai vechi, ar fi o greeal s nu se extind referina,
deoarece documentul ar recupera ntotdeauna datele curente i nu le-ar mai reine pe cele
vechi.
Ca un alt exemplu, se consider un manual al unui produs care nu conine altceva
dect referine la entiti externe care trimit la capitolele manualului. Daca unele dintre aceste
capitole ar fi folosite n alte documente, ca manualele pentru diferite modele ale aceluiai
produs, ar fi o greeal extinderea acestor referine, pentru ca ar duce la copii multiple ale
acelorai capitole.
3.4.3.4 Normalizare, integritate referenial i scalabilitate
Pentru muli, n special pentru cei ce poseda cunotine despre baze de date
relaionale, bazele de date native XML ridic un numr de probleme controversate, n special
cu privire la problemele de stocare a datelor (spre deosebire de documente). Unele dintre
aceste probleme sunt dezbtute n seciunile urmtoare.
Normalizarea
Normalizarea se refer la procesul de proiectare a schemei unei baze de date n care
un anumit set de date sunt reprezentate o singur dat. Normalizarea are cteva avantaje
clare, cum ar fi reducerea spaiului necesar pe disc i eliminarea posibilitii apariiei
inconsistenelor, care se pot gsi atunci cnd un set de date este stocat n mai multe locuri.
Aceasta este una din pietrele de temelie a tehnologiei relaionale i este un punct aprins n
discuiile despre stocarea datelor n baze de date native XML.
Normalizarea nu este o problem pentru documente centrate pe documente. De
exemplu, se consider o colecie de documente ce descrie produsele unei companii. n multe
asemenea colecii, exist puine date comune tuturor documentelor notificri de copyright,
adresele corporaiilor i numere de telefon, logo-uri ale produselor i aceste date sunt prea
puine relativ la total nct normalizarea acestora nu se ia n calcul. Pe de alt parte, alte seturi
de documentaii au pri comune importante ntre documente i se merit normalizarea lor.
Ca i n cazul bazelor de date relaionale, normalizarea bazelor de date native XML nu
este obligatorie. De aceea este important proiectarea atent a structurii documentelor nainte
de stocarea lor ntr-o baz de date nativ XML. Bazele de date native XML au un avantaj fa
de bazele de date relaionale. Din moment ce bazele de date native XML nu au scheme, se pot
stoca documente similare n baza de date cu mai multe scheme la un anumit moment. Chiar
dac este necesar reproiectarea interogrilor i convertirea documentelor existente, acest
lucru ar putea uura procesul de tranziie.
Pagina 52 din 97
Normalizarea datelor pentru o baz de date nativ XML este aproximativ la fel ca
normalizarea unei baze de date relaionale: documentele trebuie proiectate astfel nct datele
s nu se repete. O diferen ntre bazele de date native XML i bazele de date relaionale este
aceea ca XML suport proprieti multi-valoare n timp ce majoritatea bazelor de date
relaionale nu. Aceasta face posibil normalizarea datelor ntr-o baz de date nativ XML
ntr-o manier care nu este posibil ntr-o baz de date relaional.
De exemplu, se consider un ordin de vnzare. Acesta const n informaiile din antet,
cum ar fi numrul ordinului, data, numrul clientului, i unul sau mai muli itemi care conin
un numr curent, cantitatea, i preul total. ntr-o baz de date relaional, informaia din antet
trebuie stocat ntr-o tabel separat fa de itemi, deoarece sunt mai multe linii n fiecare
antet. ntr-o baz de date nativ XML, aceast informaie poate fi stocat ntr-un singur
document fr redundane, deoarece natura ierarhic a XML permite unui element printe s
aib mai muli descendeni.
Din nefericire, normalizarea pe cazuri concrete nu este att de simpl. De exemplu, ce
se ntmpl atunci cnd se dorete ca ordinul de vnzare s conin informaii despre client,
cum ar fi nume de contact i adresa de expediere i facturare? Exista dou variante. Prima, se
pot duplica informaiile despre client n fiecare ordin de vnzare pentru acel client, ducnd la
date redundante i toate problemele care apar cu acestea. A doua variant, se pot stoca
informaiile despre client separat i fie adugat un XLink n documentul ordinului de vnzare
ctre documentul clientului, fie unite cele dou documente atunci cnd datele sunt interogate.
Acest lucru presupune c fie legturile XLink sunt suportate (n majoritatea cazurilor nu
sunt), fie limbajul de interogare suport uniri (de asemenea nu se ntmpl ntotdeauna).
n practic nu exist soluii clare. Datele relaionale din lumea real sunt adesea
nenormalizate din motive de performan. Dac se stocheaz documente centrate pe
documente i acestea se pot normaliza pn la un anumit grad cum ar fi stocarea capitolelor
sau procedurilor ca documente separate i unirea lor pentru a crea documente end-user
atunci o baz de date nativ XML este o soluie bun, n special pentru c va oferi
caracteristici precum limbaje de interogare XML care nu se gsesc n alte baze de date. Dac
se stocheaz documente centrate pe date i o baz de date nativ XML mbuntete
performana aplicaiei sau ofer stocarea datelor semi-structurate, faciliti care nu se gsesc
n alte baze de date atunci aceast baz de date ar trebui folosit.
Integritatea referenial
Pagina 53 din 97
Integritatea referenial este strns legat de normalizare. Aceasta se refer la

validitatea pointerilor la datele legate i sunt o parte necesar a meninerii consistenei bazei
de date. De exemplu nu este de niciun folos un numr de client dintr-un ordin de vnzare care
nu are o nregistrare a clientului corespondent. Departamentul de expediere nu va ti unde s
trimit marfa i departamentul de contabilitate nu va ti unde s trimit factura.
ntr-o baz de date relaional, integritatea referenial nseamn asigurarea c se face
legtura corect ntre cheile strine i cheile primare adic, verificarea c linia cheii primare
ce corespunde oricrei chei strine exist. ntr-o baz de date nativ XML, integritatea
referenial nseamn asigurarea c pointerii n documentul XML trimit la documente valide
sau fragmente de documente.
Pointerii din documentele XML sunt de mai multe feluri: atribute ID/IDREF, cmpuri
key/keyref (aa cum sunt definite n scheme XML), legturi XLink, i diferite mecanisme
particulare. Cele din urma includ elemente i atribute de referire ntr-un limbaj specific, cum
ar fi atributul ref al elementului <element> n schemele XML, i mecanisme de legturi
specifice bazelor de date. n timp ce elementele i atributele de referire ntr-un limbaj specific
sunt destul de des ntlnite, mecanismele de legturi specifice bazelor de date sunt mai rare.
Integritatea referenial ntr-o baz de date nativ XML poate fi mprit n dou
categorii: integritatea pointerilor interni (pointeri dintr-un document) i integritatea
pointerilor externi (pointeri dintre documente). Integritatea referenial a pointerilor interni
care folosesc mecanisme non-standard nu este forat, deoarece bazele de date native XML
nu pot identifica aceti pointeri. Integritatea referenial a pointerilor interni care folosesc un
mecanism standard, cum ar fi ID/IDREF sau key/keyref, este cel puin parial suportat prin
validare.
Motivul pentru care acest suport este parial este c majoritatea bazelor de date native
XML execut validri numai cnd un document este introdus n baza de date. Astfel, dac
sunt efectuate actualizri la nivel de document prin tergeri i apoi nlocuiri a unui
document validarea este suficient pentru a asigura integritatea pointerilor interni. Dar dac
sunt efectuate actualizri la nivel de nod inserri, modificri i tergeri de noduri
individuale atunci baza de date trebuie s mai fac operaii n plus, cum ar fi validarea
tuturor modificrilor, pentru a garanta integritatea referenial a pointerilor interni.
Integritatea refenial a pointerilor externi nu este suportat, nici de puinele baze de
date care suport pointeri externi. Dac un pointer extern trimite la o resurs stocat n alt
parte n baza de date, nu exist motiv pentru a nu se impune integritatea pointerului. Totui,
dac un pointer trimite la o resurs din afara bazei de date nu este obligatorie impunerea
Pagina 54 din 97
integritii. De exemplu, se presupune c un document conine o legtur XLink care trimite

la un document pe un site web extern. Baza de date nu are nici un control asupra existenei
documentului extern i astfel nu se poate impune integritatea legturii XLink.
n viitor, majoritatea bazelor de date native XML probabil vor suporta integritatea
referenial a pointerilor interni care folosesc mecanisme standard. Multe baze de date native
XML vor suporta anumite tipuri de pointeri externi, ca i pointerii externi care trimit la
resurse stocate n aceeai baz de date. Deocamdat n majoritatea cazurilor aplicaiile impun
integritatea pointerilor att interni ct i externi.
Scalabilitate
Ca i bazele de date ierarhice i relaionale, bazele de date native XML folosesc
indeci pentru a localiza date. Acest lucru nseamn c localizarea documentelor i a
fragmentelor de documente este legat de dimensiunile indecilor, nu de dimensiunile
documentelor sau de numrul de documente, i de faptul c aceste baze de date pot localiza
nceputul unui document sau fragment la fel de repede ca i alte baze de date care folosesc
aceeai tehnologie de indexare. Astfel, bazele de date native XML vor scala la fel de bine ca
i alte baze de date.
Ca i bazele de date ierarhice, dar spre deosebire de cele relaionale, multe baze de
date native XML leag fizic datele nrudite. n special, bazele de date native XML bazate pe
text grupeaz fizic datele nrudite i bazele de date native XML bazate pe modele care
folosesc sisteme de stocare particulare folosesc adesea pointeri pentru a grupa date nrudite.
Bazele de date native XML bazate pe modele construite pe baze de date relaionale folosesc
ca i acestea legturi logice.
Deoarece legturile fizice sunt mai rapide dect cele logice, bazele de date native
XML, ca i cele ierarhice, pot recupera date mai repede dect bazele de date relaionale.
Astfel, ele ar trebui s scaleze bine din punctul de vedere al recuperrii datelor. De fapt, ar
trebui s se comporte mai bine dect bazele de date relaionale, deoarece scalabilitatea este
legat de o singur cutare indexat iniial, spre deosebire de multiplele cutri necesare n
cazul bazelor de date relaionale.
Din pcate, aceast scalabilitate este limitat. Ca i bazele de date ierarhice, legturile
fizice n bazele de date native XML se aplic numai asupra anumitor ierarhii. Recuperarea
datelor n ierarhia n care sunt stocate este foarte rapid, dar recuperarea acelorai date ntr-o
ierarhie diferit este mai nceat. De exemplu, se presupune c informaiile despre clieni sunt
stocate n fiecare ordin de vnzare. Recuperarea acestor ordine de vnzare va fi foarte rapid,
deoarece acesta este ordinul n care datele sunt stocate. Recuperarea unei alte vederi a datelor,
Pagina 55 din 97
cum ar fi o list cu ordinele de vnzare pentru un anumit client, va fi mult mai nceat,
deoarece legturile fizice nu se mai folosesc.
Pentru a rezolva parial aceast problema, bazele de date native XML folosesc foarte
muli indeci, adesea indexnd toate elementele i atributele. Dac acest lucru ajut la
scderea timpului de recuperare a datelor, totui crete timpul de actualizare, pentru c
ntreinerea acestor indeci poate fi costisitoare. Aceasta nu este o problem n medii readonly, dar poate cauza probleme n medii n care se folosesc multe tranzacii.
n cele din urm, bazele de date native XML scaleaz mai slab dect cele relaionale
n cutarea datelor neindexate. Ambele tipuri de baze de date trebuie s caute secvenial
datele n acest caz, dar n cazul bazelor de date native XML este mai greu datorit
normalizrii mai puin complete. De exemplu, se caut toate ordinele de vnzri cu o anumit
dat i datele nu sunt indexate. ntr-o baz de date relaional, aceasta nseamn citirea tuturor
valorilor din coloana OrderDate. ntr-o baz de date nativ XML, acest lucru nseamn citirea
fiecrui ordin de vnzare n ntregime i cutarea elementului <OrderDate>. Nu numai c se
citete coninutul fiecrui element <OrderDate>, dar se citete i coninutul tuturor celorlalte
elemente. n bazele de date native bazate pe text, textul trebuie analizat i convertit la
formatul dat calendaristic nainte de a putea fi comparat cu data cutat.
Aici se ncheie descrierea bazelor de date native XML. Urmtoarele doua seciuni
trateaz dou tipuri specializate de baze de date native XML: DOM-uri persistente i sisteme
de management ale coninuturilor.
3.4.4 DOM-uri persistente (PDOM-uri)
Un DOM persistent sau PDOM este un tip specializat de baz de date nativ XML
care implementeaz DOM-ul peste un tip de stocare persistent. Spre deosebire de
majoritatea bazelor de date native XML, care pot returna documente ca arbori DOM, arborele
DOM returnat de un PDOM este activ (live). Adic, modificrile fcute arborelui DOM sunt
reflectate direct n baza de date. Dac modificrile sunt fcute imediat sau n urma apelrii
unei metode commit depinde de baza de date. n majoritatea bazelor de date native XML,
arborele DOM returnat aplicaiei este o copie, i modificrile sunt fcute n baza de date prin
intermediul unui limbaj de actualizare XML sau prin nlocuirea ntregului document.
Deoarece arborii PDOM sunt activi, baza de date este de obicei local, adic este n
acelai spaiu de procesri ca i aplicaia, sau cel puin pe aceeai main, dei acest lucru nu
este neaprat necesar. Acest lucru este fcut pentru eficien, deoarece un PDOM peste o baz
de date aflat la distan ar necesita cereri frecvente la un server aflat la deprtare.
Pagina 56 din 97
PDOM-urile au acelai rol pentru aplicaiile DOM ca i bazele de date orientate obiect
pentru aplicaiile orientate obiect: ele ofer stocare persistent pentru datele aplicaiei, i
servesc i drept memorie virtuala pentru aplicaie. Al doilea rol este foarte important pentru
aplicaiile DOM care opereaz cu documente mari, deoarece arborii DOM pot uor s
depeasc documentele XML ca mrime.
3.4.5 Sisteme de management ale coninuturilor
Sistemele de management ale coninuturilor sunt un alt tip specializat de baze de date
native XML. Acestea sunt proiectate pentru operarea cu documente scrise de oameni, cum ar
fi manualele de utilizare, i sunt construite peste baze de date native XML. Baza de date este
n general ascuns de utilizator n spatele unui front end care ofer caracteristici precum:
Control al versiunilor i al accesului
Motoare de cutare
Editoare XML/SGML
Motoare de publicare pe hrtie, CD sau pe Web
Separarea coninuturilor i a stilurilor
Extinderea n scripturi i programare
Integrarea datelor din baza de date
Termenul de sistem de management al coninuturilor spre deosebire de sistem de
management al documentelor reflect faptul c asemenea sisteme permit n general
mprirea documentelor n fragmente cu coninut discret, cum ar fi exemple, proceduri,
capitole, dar i metadate cum ar fi numele autorilor, datele reviziilor, i numerele
documentelor, dect s opereze cu fiecare document ca un ntreg. Nu numai c astfel se
simplific coordonarea lucrului mai multor scriitori la acelai document, dar permite i
asamblarea unor documente noi din componente care exist deja.
CAPITOLUL IV
CONSTRUIREA DOCUMENTELOR XML
4.1 Sintaxa XML
XML este format de fapt din dou metalimbaje, ambele descrise n acelai document.
Primul este un set de reguli pentru realizarea de documente XML construite corect, n timp ce
al doilea este un set de reguli pentru realizarea unei definiii a tipului documentului XML, sau
DTD (Document Type Definition), care permite ca structura documentului XML s se supun
unor constrngeri i s fie validat fa de acele constrngeri. Distincia dintre aceste dou
Pagina 57 din 97
limbaje este deseori neclar, deoarece un document XML complet presupune mcar existena
opional a unui DTD, indiferent dac acesta este de fapt prezent sau nu. Pentru a complica i
mai mult lucrurile, un DTD poate fi compus din dou pri, o submulime intern i o
submulime extern. Aceasta parte studiaz documentul XML fr a insista prea mult asupra
DTD-ului, deoarece un document XML poate fi creat i fr a face referiri la un DTD. Din
motive de performan, multe documente XML vor fi utilizate fr a le valida n raport cu
DTD-ul, chiar dac DTD-ul este disponibil. n cazul conexiunilor lente, citirea dintr-un DTD
situat pe un alt sistem poate fi foarte nceat, iar datorit faptului c un DTD poate conine
referine la alte documente, rezolvarea tuturor referinelor externe poate dura exagerat de
mult chiar i n cazul conexiunilor de mare vitez. Utilizatorii sunt obinuii ca documentele
HTML s fie ncrcate incremental, deci pot citi nainte ca documentul s fie ncrcat n
totalitate, dar analizatoarele XML de validare nu permit afiarea documentului dect n cazul
n care acesta este valid, deci documentul va aprea pe ecranul utilizatorului numai n
momentul n care este ncrcat n totalitate. Acest lucru poate fi suprtor. Totui, fiecare
document este creat avnd n minte un DTD, indiferent dac DTD-ul este explicit sau nu.
Chiar i la crearea documentelor fr un DTD, trebuie s avut n vedere un fel de DTD
empiric pe msur ce este creat documentul, deoarece un DTD descrie o structur de date.
4.2 Descrierea de vocabulare noi cu XML
XML are o natur dual: un metalimbaj care permite descrierea de noi structuri de
documente i vocabulare i un limbaj utilizat ca s exprime acea structur i acel vocabular n
cazul unui document. Exist o diferen clar ntre un document XML, care poate avea sau nu
asociat un DTD exprimat n metalimbajul XML, i un DTD XML. Ele utilizeaz sintaxe
complet diferite pentru a descrie un document XML, unul prin exemplu iar cellalt
prescriptiv.
Definiiile tipului documentului XML (DTD-urile) descriu instane ale limbajului
XML, numite uneori vocabulare XML. Dcumentele XML sunt create utiliznd acele limbaje.
Din pcate, aceast diferen se pierde uneori n exprimarea neoficial, iar vocabularele XML
particulare i DTD-urile asociate sunt descrise inexact ca XML. Utilizatorul unui limbaj
sau vocabular XML poate c nu va vedea niciodat sau poate c nici nu i pas de DTD-ul
utilizat pentru a descrie aplicaia sa, la fel cum miilor de persoane care lucreaz n design
Web utiliznd HTML nu le pas de W3C HTML 4.0 SGML DTD utilizat n descrierea
HTML. De fapt, un DTD poate s nu existe. Nu are o importan chiar aa mare la nivelul
aplicaiei.
4.3 Avantajele definiiei tipurilor documentului
Pagina 58 din 97
Cu toate c DTD-urile sunt opionale deoarece un procesor XML poate conduce un

DTD convenabil dintr-o instan a XML, existena unui DTD ofer multe avantaje:
Un DTD descrie organizarea unui document ntr-un mod care poate fi distribuit cu
uurin.
Un DTD permite unui proiectant s creeze o transformare robust dintr-un anumit
tip de document XML ntr-un alt format, pentru afiare sau transfer. Deoarece cu un DTD se
cunoate absolut orice despre documente, se vor putea trata structuri care este posibil s nu
existe ntr-un anumit exemplu, dar sunt permise de tipul documentului, chiar dac nu au fost
ntlnite niciodat pn acum.
Un DTD permite unui analizor care valideaz s determine dac un anumit
document este sau nu creat n conformitate cu regulile stabilite de autorul specificaiei. Acest
lucru este extrem de important pentru EDI (Electronic Data Interchange schimb electronic
de date) i alte aplicaii n care documentele vor fi partajate i utilizate i de alte procese.
Fr un DTD, un mediu de creare XML nu poate oferi sugestii despre elementele
care sunt necesare sau opionale ntr-un anumit loc i despre atributele pe care le poate
conine un anumit element. Meniurile contextuale sau sugestiile pot fi de mare ajutor n
accelerarea dezvoltrii documentelor i n prevenirea erorilor.
Fr un DTD, autorul unui manual de creaie sau al unui document de stil nu are de
unde s tie cum ar trebui construit documentul definit. Un manual de creaie este o ntrupare
a informaiei exprimate ntr-un DTD, cu toate c nu este un DTD n sine.
Specificarea DTD-ului utilizat ntr-un document identific versiunea standardului
folosit la crearea sa. Cnd documentele se dezvolt n funcionalitate i sintax, acesta poate
fi un indiciu ntr-o situaie nou.
4.4 Combaterea dezavantajelor definiiei tipurilor documentului
Cu toate avantajele lor, DTD-urile ridic i probleme. Ele utilizeaz o sintax diferit
de XML, deci construirea unui DTD necesit un alt set de abiliti. n plus ca orice descriere
tehnic, implicarea n proiectarea unui DTD neavnd n vedere aspectul structurii datelor n
document poate duce la mpotmolirea n detalii atunci cnd este nevoie de atenie la structura
general. Multe persoane proiecteaz documente XML utiliznd vocabularul XML destinat i
apoi utilizeaz un instrument de extragere automat de DTD-uri pentru a genera un DTD pe
baza documentului. Dup realizarea acestui lucru, DTD-ul poate fi reglat prin adugri la
codul surs sau prin ajustarea acestuia.
Dar DTD au i urmtoarele dezavantaje:
Pagina 59 din 97
Cu un DTD, un agent utilizator XML care valideaz necesit cel puin nc o

operaie de citire pentru a accesa locaia unde este disponibil DTD-ul. Cu toate c plasarea n
cache poate reduce performanele pentru unii utilizatori din reea, multe utilizri previzibile
ale documentelor XML vor face imposibil utilizarea stocrii n cache.
Un DTD crete cu mult complexitatea analizorului necesar pentru a determina dac
un document poate fi afiat. Pentru unele dispozitive, este posibil ca acest lucru s fie
realizabil.
Unele medii de creare care valideaz i utilizeaz un DTD ngreuneaz salvarea
spaiului de lucru la sfritul zilei sau restaurarea sa n ziua urmtoare, cu excepia cazului n
care documentul se afl ntr-o stare valid.
Din punct de vedere teoretic, un DTD este capabil s continue nelimitat citiri
externe, deoarece un DTD poate conine alte DTD-uri sau mulimi de entiti. Este posibil ca
pentru afiarea unor documente complexe s fie nevoie de foarte mult timp atunci cnd se
utilizeaz un analizor care valideaz.
Decizia utilizrii unui DTD este un compromis ntre abilitatea de utilizare fr
restricii, obinuit n HTML posibilitate de a face aproape tot ce se dorete i un mediu
mult mai structurat. n multe situaii, cum sunt cele n care se realizeaz documente care
trebuie s fie general disponibile i sunt create distribuit, trebuie s se respecte strict regulile
i este de dorit folosirea unui DTD. n alte cazuri, cum ar fi atunci cnd se dezvolta un tip de
document XML nou, nu este nevoie sau nu este dorit constrngerea strict i se poate realiza
fr un DTD, cel puin n timpul proiectrii iniiale.
Dar dup ce dezvoltarea a devenit un produs stabil, este de dorit ca proiectul s poat
fi distribuit cu uurin. Chiar dac se dorete crearea unui manual de utilizare, un DTD este o
metod simpl de a permite utilizatorilor s i testeze propriile documente pentru a se asigura
c au respectat indicaiile pe care le-au citit n manual. n acel moment, se poate considera c
DTD-urile ofer o flexibilitate prea mare.
4.5 XML, doar un alt HTML?
XML este un limbaj cu etichete i atribute asemntor cu HTML, dar un HTML
transformat att de mult, nct nu mai poate fi recunoscut. XML este mult mai structurat dect
HTML. n timp ce procesoarele HTML accept n mod curent cod incorect i diform i
ncearc s i dea sens pe ecran, XML trebuie s se opreasc atunci cnd gsete o eroare
fatal, care poate fi aproape orice tip de eroare. Aceasta este ntr-un fel o ntoarcere la primele
zile ale prelucrrii datelor, cnd orice eroare din cod era pedepsit cu un vidaj de memorie,
(core dump) lng care se puteau petrece ore ntregi n ncercarea de a-l descifra.
Pagina 60 din 97
Totui pe lng acest comportament necrutor, XML este cu mult mai puternic. n
timp ce HTML se mulumete cu un numr relativ mic de etichete, XML are un numr de
etichete aproape infinit, structurate n aproape orice fel se dorete. Oricum, fundamentele au
rmas aceleai, XML reprezentnd un pas evolutiv al HTML. Nu numai c un HTML bine
fcut este foarte aproape de XHTML un nlocuitor al HTML care respect XML dar un
cod HTML 4.0 curat este destul de lizibil ca XHTML 1.0. Deoarece HTML 4.0 a fost
structurat ca o aplicaie SGML, iar XML este o submulime a SGML, acest lucru este logic.
Diferenele sintactice minore dintre XHTML, un vocabular XML, i HTML, un vocabular
SGML, pot fi ajustate automat dac este nevoie. Autorul unui document XML ofer de obicei
un manual de creare sau codare (sau o foaie, pentru DTD-uri mici) descriind etichetele
utilizate n aplicaia XML, atributele lor, valorile posibile i modul lor de imbricare.
Urmrirea unui astfel de manual de codare nu este mai dificil dect reinerea faptului c o
linie de tablou <tr> trebuie s fie imbricat n interiorul unui tablou <table> i nu are, sau nu
ar trebui s aib, sens n afara acelui context. Pentru majoritatea situaiilor, acest lucru este
suficient. XML este capabil s ofere autorilor suficient ajutor n nvarea modului de
utilizare a unei anumite aplicaii, deoarece acetia sunt ncurajai s dea etichetelor nume
sugestive, care s fie uor de reinut. Autorul unei aplicaii ar trebui s furnizeze un manual de
creare care s explice n termeni simpli modul de utilizare a aplicaiei.
Cu toate c orice procesor XML poate spune despre o poriune de cod dac este sau
nu construit corect, iar un manual poate ajuta la construirea unui document valid, DTD-ul
permite verificarea fr ambiguiti a codului. Totui, n funcie de tipul de creare utilizat,
acesta poate fi un pas diferit de procesul de editare.
Codul ndeplinete acest ideal n funcie de utilizarea dat numelor etichetelor, totui
ntre anumite limite:
Numele de etichete care ncep cu irul xml, indiferent de tipul literelor, sunt
rezervate; adic, indiferent de situaie, nu este permisa crearea lor.
Numele de etichete care conin caracterul dou puncte pot fi interpretate ca
identificatori avnd asociat o zon de nume, deci utilizarea celor dou puncte n numele
etichetelor este puternic combtut i poate fi chiar interzis.
Un nume de etichet trebuie s nceap cu o liter, care n acest context este orice
liter sau ideogram Unicode/ISO/IEC 10646, sau cu o liniu de subliniere
n continuare, numele unei etichete poate conine orice liter, ideogram sau cifr
Unicode/ISO/IEC 10646, caractere de combinare, caractere de extindere, puncte, cratime,
spaii sau dou puncte. De altfel, puine limbi de pe glob au caractere cu care s nu poat
Pagina 61 din 97
ncepe un nume corect n limba respectiv. Aceste caractere sunt excluse din lista de caractere
dac se afl ntr-o poziie n care pot fi vzute ca primele dup o cratim sau un alt
separator logic de cuvinte.
Caracterul thailandez mai yamok (arat ca un f ntors i fr liniu), de exemplu,
arat ca o liter, dar nu poate fi folosit ca prim liter a unui cuvnt deoarece el semnific
repetarea literei anterioare.
Caracterele de combinare sunt caractere speciale, folosite pentru a accentua un alt
caracter, multe dintre ele fiind normalizate la un singur caracter cu accent. Acesta este un
avantaj pentru intrrile de la tastatur deoarece multe limbi care conin caractere accentuate
permit introducerea utiliznd caractere accent speciale de lime zero care se pot ataa la
orice alt caracter.
Caracterele de extindere sunt diverse semne de punctuaie, cum ar fi (n limbile
europene) middle dot, triangular colon i half-triangular colon. Caracterele extinse sunt
similare n alte scrieri din lume; nu sunt exacte din punct de vedere alfabetic dar se potrivesc
pe undeva.
4.6 Startul n XML
Acest subiect evideniaz mulimea de deprinderi necesare pentru XML i clarific
numeroasele asemnri dintre XML i HTML:
XML este sensibil la tipul literelor deoarece majusculele nu reprezint un concept
universal Dac s-ar trata literele mari i mici ca fiind echivalente, ar trebui s se fac la fel
pentru mii de alte variante de litere n alte limbi, o operaie mpovrtoare. Unele limbi nici
nu au tipuri de litere. De exemplu, n limba ebraic nu exist litere mici, iar limba arab nu
face distincie ntre forma iniial, de mijloc i final a literelor. Pentru cei care prefer s
scrie etichetele cu majuscule i atributele cu litere mici, pentru a le evidenia, aceasta este o
tire teribil. Dar editoarele de cod moderne nu mai acord o importan aa de mare acestui
lucru ca nainte. De exemplu, precizarea anumitor culori pentru a marca etichete este un lucru
obinuit, deci utilizarea majusculelor este ntructva un anacronism istoric, asemenea
numerelor de linii n COBOL.
XML este foarte precis cu privire la imbricarea corect a etichetelor Etichetele nu
se pot ncheia ntr-un context diferit de cel de nceput. Deci, dac se dorete <bold><italics>,
fraza evideniat trebuie nchis cu </italics></bold>, pentru a evita o eroare fatal. Deoarece
XML poate referi i include documente XML i fragmente de documente oriunde pe Web,
fiecare document XML trebuie s se supun acelorai reguli pentru a nu strica documentele
altora.
Pagina 62 din 97
XML nu este bine protejat mpotriva recursivitii Cu toate c este posibil

stabilirea excluderilor explicite la un anumit nivel, la o structur complex a unui document
este dificil meninerea acelor excluderi la un nivel redus, mai ales atunci cnd se utilizeaz
etichete care pot fi aplicate la orice nivel. Deci, interdicia HTML referitoare la includerea
unei etichete ancor <a> n interiorul altei etichete ancor exist i n XML, dar nu este
impus dincolo de includerea direct.
XML oblig la nchiderea fiecrei etichete, chiar i a etichetelor vide Deoarece
este posibila crearea unui document XML care s nu utilizeze un DTD, un procesor XML nu
are de unde s tie dac o etichet este sau nu vid. Deoarece toate documentele XML trebuie
s fie construite corect, etichetele vide trebuie marcate cu o sintax special care spune unui
procesor XML c eticheta este vid i nchis. Acest lucru se realizeaz plasnd un spaiu i
un caracter slash la sfritul etichetei, astfel:
<break />
Exist o sintax alternativ, care este la fel de bun pentru procesoarele XML reale,
dar blocheaz frecvent browserele Web atunci cnd este utilizat cu XHTML; aceasta cere ca
o etichet vid, cum ar fi , s fie nchis cu , astfel: 
Din pcate, este prea periculoas pentru a fi utilizat n siguran. Multe browsere
actuale i majoritatea celor motenite nu recunosc eticheta de nchidere non- HTML i fac
lucruri ciudate cu ea. Navigator 4.7, de exemplu, poate zpci afiarea atunci cnd se
mpiedic de o etichet . Comportamentul exact poate diferi n funcie de poziia n cod
i de eticheta vid care se nchide. Pe scurt, aceast sintax este predispus la erori i ar trebui
evitat.
XML necesit ncadrarea valorilor atributelor fie ntre apostrofuri, fie ntre ghilimele
Acolo unde HTML este indulgent, mai ales n ceea ce privete numerele i aproape orice ir
fr spaii n interior, XML trateaz totul ca ir de caractere i las aplicaia s i dea seama
singur de toate acestea.
XML recunoate mai multe limbi Spre deosebire de HTML, seturile de caractere
extinse utilizate n multe limbi europene nu sunt pe deplin recunoscute n mod prestabilit.
Exist un mecanism simplu pentru includerea acestora, precum i a ntregului set de caractere
Unicode (cunoscut, de asemenea, i ca ISO/IEC 10646) care are peste un milion de caractere,
deci suportul pentru chinez, arab i multe alte limbi mai exotice ale lumii este un lucru
uor. n afar de diferenele menionate n aceast list, XML este foarte asemntor cu
HTML din punctul de vedere al marcrii etichetelor, al argumentrii atributelor i al trecerii
coninutului ntre perechi de etichete.
Pagina 63 din 97
Limbajul XML a fost proiectat astfel nct s fie transparent la utilizare pentru a putea
fi neles i utilizat cu uurin. Descrierile XML succinte sau complicate din majoritatea
documentelor sunt greu de neles n efortul de a fi explicit ntr-un mod n care programatorii
s l poat translata cu uurin n aplicaii care s funcioneze.
4.7 Definirea unui document XML ca ntreg
Un document XML este o colecie de entiti care pot fi sau nu analizate. Datele care
nu sunt nelese de un procesor XML, date binare sau date care au sens numai pentru alte
aplicaii, reprezint date neanalizate. Datele nelese de XML, fie ca i caractere fie ca
marcaje, sunt date analizate.
Un document XML trebuie s fie construit corect. n Recomandarea XML 1.0 a W3C
aceast situaie este descris concis prin urmtoarele cerine:
Luat ca ntreg, corespunde produciei etichetate ca document.
Satisface toate constrngerile de construire corect din aceast specificaie
(Recomandarea XML 1.0)
Fiecare entitate analizat, referit direct sau indirect n cadrul documentului, este
construit corect.
Prima constrngere spune c pentru a fi construit corect, un document XML trebuie s
respecte toate regulile care descriu un document n Recomandarea XML 1.0. Acele reguli
spun n primul rnd c un document XML trebuie s conin un prolog i un singur element
care formeaz elementul rdcin al documentului, mpreun cu comentarii opionale i
instruciuni de prelucrare la sfritul documentului, dar, din pcate, analizorul XML nu are
cum s spun dac aceste comentarii i instruciuni de prelucrare ataate sunt sau nu ataate
documentului. Deoarece ele pot sa fie plasate dup eticheta de ncheiere, un analizor XML nu
poate s spun nici dac instruciunile de prelucrare i comentariile ataate au fost sau nu
recepionate. Aceasta contravine regulii generale din XML care spune c un analizor trebuie
s fie capabil s indice dac un document este sau nu complet. Dac se utilizeaz instruciuni
de prelucrare sau comentarii, este preferabil trecerea lor n prolog unde sunt mult mai n
siguran i nu se pot pierde.
Cea de a doua constrngere spune c documentul respect constrngerile construirii
corecte descrise n document. Una din constrngerile construirii corecte este c entitile
analizate recursiv sunt interzise. Recursivitatea din aceast interdicie se refer la formarea
unei bucle de entiti n care o entitate se ncorporeaz pe ea nsi sau o alt entitate care se
ncorporeaz pe ea nsi indiferent de nivelul de indirectare. Aceasta mai nseamn i c un
document nu se poate referi la el nsui, nici mcar indirect printr-o entitate extern. El se
Pagina 64 din 97
poate referi la o entitate extern numai dac aceasta nu se refer la ea nsi, chiar i indirect.
Este posibil ca analizoarele care nu valideaz s nu depisteze aceast eroare, dar aceasta este
totui o eroare. Din punct de vedere logic este evident c dac documentul A conine
documentul B, definindu-l pe B ca i cnd l-ar conine pe A se genereaz o bucl infinit.
Bucla infinit este interzis.
n termeni XML, construcia corect este o alt modalitate de a spune c un document
XML formeaz un arbore, sau o ramur a unui arbore, adic este complet n sine. Acest lucru
este necesar deoarece XML permite construirea de documente mai mari din unele mai mici i
reprezint o cheie a posibilitii de utilizare a XML pe Web.
Dei construirea corect poate fi considerat suficient deoarece un document
construit corect are un DTD care l descrie, pot fi construite un numr infinit de DTD-uri
care, de asemenea, s l descrie. Deci, pentru validitate total, un DTD asociat este necesar.
Producia documentului este definit n numai dou afirmaii, preluate din nou din
Recomandarea XML 1.0:
Conine unul sau mai multe elemente.
Exist un singur element, numit rdcin sau element document, care s nu aib nici
o parte a sa n coninutul oricrui alt element. Pentru toate celelalte elemente, dac eticheta de
pornire se afl n coninutul unui alt element, atunci i eticheta de ncheiere se afl n
coninutul aceluiai element. Exprimat mai simplu, elemente delimitate de etichete de pornire
i ncheiere sunt imbricate corect unele n altele.
Prima afirmaie spune c ntr-un document trebuie s existe cel puin un element sau,
altfel spus, un document construit corect nu poate fi vid.
Cea de a doua afirmaie spune c, ntr-un sens restrns, un document trebuie s fie un
arbore. El nu poate fi o reea conectat arbitrar sau s aib orice alt topologie care nu se
reduce la un arbore simplu. El trebuie s fie complet pentru a putea vedea diferena dintre o
descrcare reuit i una parial.
Din punct de vedere tehnic, un arbore este un graf conex care nu conine circuite. Cu
alte cuvinte, un arbore se ramific de la rdcina sa fr a se mai conecta la el nsui, deci nu
conine muchii multiple sau bucle. Orice lucru care conine bucle sau muchii multiple, nu este
un arbore, ci altceva, i nu poate fi reprezentat n XML. Un efect secundar interesant este
acela c ntr-un arbore se poate alege arbitrar un punct, i se poate transforma un nod ntr-o
rdcin, reorganiznd arborele ntr-un alt arbore, cu o alt ordine de parcurgere. Aceasta
ilustreaz caracterul capricios al schemelor de clasificare.
Pagina 65 din 97
O descrcare parial este posibil n HTML, deoarece HTML nu are nevoie de

eticheta de ncheiere </html>, sau nu are nevoie de aproape nici o etichet de ncheiere.
Uneori browserul poate detecta ntreruperea, dar acest lucru nu este garantat. Aceasta
nsemn c un document parial se poate deghiza ntr-unul complet, iar utilizatorul nu are de
unde s tie acest lucru pn cnd n text nu apare o eroare evident. XML previne aceste
probleme, lucru care poate fi important n cazul n care un utilizator reclam ulterior c o
convenie de acordare a licenei, de exemplu, nu a fost afiat n ntregime. Insistnd asupra
unui arbore complet, un astfel de exemplu fiind prezentat n Figura 1, se
elimin aceste probleme posibile.
Figura 1
Pe de alt parte, un graf care nu formeaz un arbore nu poate fi transformat ntr-un
document XML dect dac graful poate fi simplificat, eliminnd toate caracteristicile care nu
sunt reprezentative pentru arbori. n Figura 2, de exemplu, graful din stnga poate fi
simplificat prin eliminarea unei ci de la frunza de sus ctre un nod. n aceeai figur,
Pagina 66 din 97
grafului din partea dreapt trebuie s i se elimine o rdcin deoarece un document XML
poate avea o singur rdcin.
4.8 Prologul: declaraia XML

Fiecare document XML, ar trebui s nceap cu o declaraie XML care identific
fiierul ca fiind un fiier XML i identific, de asemenea, versiunea XML utilizat n
documentul respectiv. Caracterul opional este datorat numai faptului c pe Web exist multe
fiiere HTML i SGML care corespund perfect unui document XML construit corect. De
asemenea, declaraia XML este locul unde se declar codificarea i dac documentul este sau
nu autonom. Ordinea din fragmentul urmtor este obligatorie cu toate c atributele encoding
i standalone sunt ambele opionale.
<?xml version=1.0 encoding=ISO-8859-1 standalone=yes>
Codificrile permit identificarea crui dintre multiplele seturi de caractere va fi
utilizat n document. Acest lucru este important deoarece, spre deosebire de HTML, care
implic ASCII, i oblig la folosirea numelor ASCII, XML permite vorbitorilor de Hindi, de
exemplu, s utilizeze codificarea lor i s fac textul i mediul de editare lizibil i pentru
persoanele obinuite care pot fi autori XML. Sau, un autor chinez poate s prefere caracterele
chinezeti n etichete i n coninut cu cteva limitri bazate pe regulile limbajului n sine, se
pot utiliza moduri de scriere i ideograme att n numele etichetelor ct i n coninut.
4.9 Documente autonome
Pagina 67 din 97
n conformitate cu Recomandarea XML 1.0 a W3C, Documentele autonome nu au

declaraii de marcare externe care s afecteze informaia XML transferat de procesorul XML
unei aplicaii. Acesta este un mod extraordinar de succint i obscur de a spune c
standalone=yes nseamn c:
ntr-un DTD extern nu exist valori prestabilite declarate ale atributelor care s nu
fie setate explicit n document.
Nu sunt utilizate alte entiti n afar de &, <, >, ', i ", care
nu au fost declarate local sau poate citite prin referin dintr-un fiier.
Nu exist elemente care s aib ca i coninut numai spaii albe de orice natur.
Nu exist atribute externe care trebuie normalizate, deci coninutul atributelor nu
poate conine spaii albe, caractere sau referine la entiti. Aceasta nu nseamn c
documentul nu are nimic extern. Aceasta nseamn n special c, indiferent de locul n care un
procesor XML care nu valideaz se oprete din citirea documentelor externe, se oprete
prelucrarea tuturor declaraiilor. Toate aceste lucruri se pot face dac i numai dac sunt puse
n submulimea DTD-ului intern. Datele externe care nu sunt marcaje nu fac subiectul acestei
afirmaii. Deci, pot exista fiiere grafice, fiiere text incluse i orice altceva, att timp ct ele
nu sunt marcaje i au fost declarate n submulimea DTD-ului intern. Dup toate acestea,
procesorul XML nu trebuie s anune aplicaia dac documentul este sau nu autonom. De
fapt, procesorul nu trebuie s fac nimic cu aceast informaie i nici s se comporte ntr-un
anumit fel atunci cnd ntlnete aceast informaie.
n mod fundamental, proiectantul DTD-ului trebuie s descifreze dac documentul
creat utiliznd acel DTD poate fi sau nu autonom i s comunice acest lucru oamenilor
inclusiv autorilor. Autorii care tiu c DTD a fost proiectat pentru a fi autonom sau cei care au
convertit un document care nu a fost proiectat s fie autonom n acest format, pot insera
stanalone=yes n declaraia lor XML ca o documentaie a acelui fapt:
<?xml version=1.0 standalone=yes ?>
Documentele care nu sunt autonome pot fi convertite prin algoritmi la documente
autonome, automat, presupunnd c este disponibil o facilitate care s realizeze acest lucru,
sau manual n caz contrar.
4.10 Construirea prologului unui document XML: Declaraia tipului documentului
(Document Type Declaration)
Prologul unui document XML conine mai multe instruciuni. Prima, declaraia XML,
afirm c documentul urmtor este XML. Cea de a doua, declaraia tipului documentului
(Document Type Declaration), este metoda utilizata pentru a identifica definiia tipului
Pagina 68 din 97
documentului (Document Type Definition - DTD) folosit de un anumit document. Faptul c

acronimul DTD poate fi aplicat la Document Type Declaration este o coinciden nefericit.
DTD se refer numai la Document Type Definition. ntr-un document XML poate exista o
singur declaraie a tipului documentului, deci este introdus chiar n instana documentului.
Deoarece pot fi combinate mai multe DTD-uri pentru a forma un singur document, aceasta
permite controlul ncrcrii DTD-urilor n fiecare document.
Declaraia tipului documentului (DOCTYPE) are dou pri, ambele opionale. Prima
se refer la un DTD extern, i utilizeaz cuvinte cheie PUBLIC sau SYSTEM pentru a
identifica o intrare dintr-un catalog, respectiv un URI. n cazul n care cataloagele nu sunt
implementate n procesorul XML, se pot specifica ambele pri deodat, fr cel de al doilea
cuvnt cheie:
<!DOCTYPE nume-document PUBLIC {catalog id}>
<!DOCTYPE nume-document PUBLIC {catalog id} {uri}>
<!DOCTYPE nume-document SYSTEM {uri}>
Cea de a doua parte opional a declaraiei DOCTYPE permite introducerea
submulimii interne a unui DTD direct n document. Exist restricii severe cu privire la genul
de informaie care poate fi introdus n DTD-ul intern, dar oricum se pot face destul de multe.
Submulimea intern a unui DTD este ncadrat ntre paranteze drepte, astfel:
<!DOCTYPE nume-document [ {declaraiile DTD-ului intern} ]>
De asemenea, cele dou pot fi combinate, permind adugarea anumitor tipuri de
declaraii i entiti aproape n orice mod:
<!DOCTYPE nume-document PUBLIC {catalog id} {uri} [ {declaraiile DTDului intern} ]>
Pentru claritate, submulimea intern este evideniat ca mai jos:
<!DOCTYPE nume-document PUBLIC {catalog id} {uri} [
{declaraiile DTD-ului intern}
]>
Declaraia DOCTYPE trebuie s utilizeze numele elementului rdcin al DTD-ului
fie acesta intern sau extern, ca fiind cmpul etichetat nume-document din exemplele
anterioare. Deci dac numele elementului rdcin al DTD-ului este Dave, declaraia
DOCTYPE ar trebui s nceap astfel:
<!DOCTYPE Dave >
Manualul de codare indic autorilor ce trebuie trecut n DOCTYPE. Un proiectant
DTD ar trebui s furnizeze un astfel de document sau o foaie de codare fiecrui autor. De
Pagina 69 din 97
asemenea, se poate crea un DTD master care apeleaz prile DTD necesare, lucru care
seamn cu comenzile dintr-un meniu. Atunci cnd se obine o combinaie de funcionaliti
care permite crearea structurii documentului de care este nevoie, se poate publica DTD-ul
rezultat i nltura neplcerea refacerii pentru fiecare document nou.
4.10.1 Crearea corpului documentului
Un document XML este alctuit din text, care de obicei este format dintr-un amestec
de marcaje i date caracter. Prologul conine numai marcaje, dar nu aceasta este partea
interesant, deoarece este nevoie de date care s nsoeasc marcajele care, altfel, nu ar fi
dect nite cutii goale ce ateapt s fie umplute. Corpul documentului conine aproape tot
ceea ce conteaz din perspectiva unei aplicaii mprtiate generos n cadrul marcajelor.
4.10.2 Date caracter
Un DTD poate declara multe tipuri de date care s poat fi utilizate ntr-un document,
dar tipul de date prestabilit este ntotdeauna CDATA, pentru date obinuite de tip caracter.
Foaia sau manualul de codare indic ce tip de dat poate fi introdus n fiecare atribut sau
cmp cu coninut element. Presupunnd c tipul de date este CDATA, n cmp se poate pune
aproape orice se dorete att timp ct nu conine un marcaj n afara unei secvene escape.
Este pe deplin posibil construirea unui DTD care s nu conin text n interiorul
elementelor. n schimb, se pot pune datele semnificative n interiorul atributelor asociate
fiecrui element, care pot fi toate declarate ca fiind vide sau avnd numai coninut element.
Acest lucru se face uneori pentru a converti un document utiliznd un standard de codificare
cum ar fi MARC, care este n esen un format binar, la XML.
4.10.3 Marcajul
Marcajul este format din ansamblu de date non-caracter dintr-un fiier XML.
Diversele forme pe care le poate lua un marcaj sunt prezentate n tabelul urmtor:
Tabel
1 Sintaxa marcajului XML
Pagina 70 din 97
Toate celelalte sunt date de tip caracter.

Marcajul ncepe ntotdeauna fie cu caracterul <, caz n care se ncheie ntotdeauna cu
caracterul >, fie cu caracterul &, caz n care se ncheie ntotdeauna cu caracterul ;.
4.10.4 Formarea structurilor logice n XML
Imbricarea elementelor este singurul mecanism utilizat pentru a arta structura logic
dintr-un document XML. Etichetele de pornire i ncheiere din fluxul de text spun
procesorului XML c a fost ntlnit un nod. Dac procesorul XML ntlnete o alt etichet
de pornire nainte de eticheta de ncheiere corespunztoare, atunci procesorul tie c acesta
este fie un nod nou n arbore, fie o frunz. Dac nu gsete o nou etichet de pornire i
ntlnete o etichet de ncheiere, atunci procesorul tie c aceasta este o frunz i c poate
aciona iterativ la acel nivel al arborelui pn cnd ntlnete o alt etichet de pornire sau de
ncheiere. Prelucrarea acioneaz treptat, bazndu-se pe aceast regul simpl. Dac
procesorul valideaz documentul, atunci fiecrui nod i se poate asocia o regul care s
determine ce tip de coninut poate aprea n el. O etichet vid este, prin definiie, o frunz,
deoarece nu poate avea nici un coninut.
Majoritatea structurilor de date coninute ntr-un document XML pot fi accesate
secvenial fr a construi structura n memorie. O etichet de pornire ncepe un nod sau o
frunz, iar eticheta de ncheiere corespunztoare l(o) ncheie. Orice etichete ntlnite ntre o
etichet de ncheiere corespunztoare ei ncep un nod sau o frunz nou. Acest principiu
reprezint baza lui SAX i a altor procesoare XML conduse prin evenimente.
Restul structurii logice a documentului este definit prin atributele asociate fiecrui
element. n plus, structura logic poate diferi n funcie de coninutul seciunilor condiionale
din cadrul documentului sau al componentelor sale.
4.10.5 Cum formeaz XML structurile fizice
Imbricarea entitilor este singurul mecanism utilizat pentru a arta structura fizic
dintr-un document XML. Definiiile de entiti ntlnite n fluxul de text i comunic
procesorului XML c a fost gsit o alt entitate.
Exist multe tipuri de entiti, de la entitile mici care formeaz caractere individuale,
cum ar fi: (spaiu), pn la entitile externe care permit ncorporarea ntr-un
document poriuni din alte documente XML sau includerea ntr-un document a referinelor la
date neanalizate, cum ar fi fiiere multimedia pentru redarea ulterioar de ctre un agent
utilizator.
Pagina 71 din 97
Un document XML este o colecie de astfel de entiti. Fiecare din aceste subentiti
trebuie s fie complet n sine. Aceasta nseamn c, deoarece structura documentului ca
ntreg trebuie s fie un arbore simplu, fiecare subentitate trebuie s fie un singur nod sau
trebuie s fie, de asemenea, un arbore simplu. Structuri mai mari se pot construi prin
adugarea nodurilor sau a arborilor subentitate ca poriuni ale arborelui mai mare.
4.10.6 Etichete de pornire i etichete de ncheiere
n XML sunt utilizate dou tipuri de etichete, etichete cu coninut i etichete vide.
Etichetele cu coninut trebuie s aib o etichet de pornire i o etichet de ncheiere. Eticheta
de pornire conine numele elementului ncadrat ntre paranteze unghiulare, avnd opional
atribute ca argumente. Eticheta de ncheiere conine numele elementului precedat de
caracterul slash, totul fiind ncadrat ntre paranteze unghiulare. n eticheta de ncheiere nu
putei trece atribute. Codul urmtor reprezint o etichet cu coninut:
<titlu subtitlu=0 cltorie acas >Dus-ntors</titlu>
Seamn mult cu etichetele HTML standard i nu ar trebui s ridice alte probleme n
afara celei de construire corect, care cere ca ele s se imbrice ntr-adevr una n cealalt. Nu
pot exista etichete care s alterneze ntre ele ca n acest exemplu greit construit:
<bold><italic>TEXT ACCENTUAT</bold></italic>
Cu toate c este o eroare obinuit n HTML, XML este cu mult mai pretenios i nu
va permite aceast construcie. Etichetele trebuie imbricate corect, dup cum se vede n
exemplul urmtor:
<bold><italic>TEXT ACCENTUAT</italic></bold>
Acum etichetele sunt imbricate corect. Trebuie nchis fiecare etichet care ncepe n
contextul unei anumite etichete (sau a mai multor etichete) nainte de nchiderea contextului
etichetei respective.
Etichetele vide au disponibil un format special, cu toate c aceeai schem, etichet de
pornire/ etichet de ncheiere, poate fi utilizat atta timp ct se ine cont de faptul c nu
trebuie pus nici un fel de coninut ntre eticheta de pornire a elementului vid i eticheta de
ncheiere care urmeaz imediat dup ea. De asemenea, poate exista preocuparea c este
posibil ca documentul XML s fie vizualizat cu un browser Web obinuit, deoarece etichetele
de ncheiere pentru elementele care arat ca etichete HTML vide pot duce la blocarea
browserului sau la un comportament ciudat al acestuia. Totui, pentru utilizare general,
formatul special este mnemonic n sine, un avantaj deoarece se poate vedea c eticheta este
vid i nu blocheaz aproape nici un browser. De obicei, etichetele vide sunt pornite i
ncheiate n cadrul aceleiai perechi de paranteze unghiulare, plasnd dup numele
Pagina 72 din 97
elementului i toate atributele sale posibile un spaiu, un caracter slash i apoi paranteza
unghiular nchis:
<image source=pozamea.jpeg type=JPEG />
4.10.7 Normalizarea
Normalizarea este un cuvnt excentric pentru aducerea lucrurilor la cel mai mic
numitor comun i punerea lor ntr-un fel de form canonic. n contextul XML, el se refer la
procesul rezolvrii referinelor la entiti n locaii n care pot aprea astfel de referine, la
aranjarea rndurilor noi pentru a lua n considerare diversele metode de tratare a lor de ctre
diferite sisteme de operare i la ordonarea altor lucruri care trebuie fcute n anumite situaii.
Proiectantul rareori trebuie s se preocupe de normalizare, excepie fcnd cazurile
negative. Analizorul XML ar trebui s realizeze toate normalizrile necesare, deci singurul
lucru la care trebuie s se gndeasc creatorul documentului este dac normalizarea va afecta
sau nu datele sale atunci cnd se va face trecerea de la forma nenormalizat i invers. S-a
dovedit c exist dou locuri n care pot fi ntlnite spaii albe: n datele de tip caracter din
cadrul documentului i n datele de tip caracter atribuite atributelor elementelor. n primul
caz, n entitile analizate este dificil s se fac distincie ntre spaiile albe semnificative i
cele nesemnificative. Pentru proiectani, cea mai bun cale pare s fie transferul ctre
aplicaie al tuturor spaiilor albe mpreun cu cea mai bun presupunere a procesorului,
bazat pe DTD, referitoare la datele care sunt n mod sigur nesemnificative i la cele
nesigure. Acest transfer de rspundere are sens deoarece aplicaia este cea n msur s tie
cum s procedeze cu spaiile albe suplimentare.
Procesorul XML poate numai s presupun care spaiu alb este semnificativ i care
nu, bazndu-se pe ceea ce a fost definit n DTD sau n orice alt limbaj de scheme utilizat. O
aplicaie trebuie s fie pregtit s trateze presupunerile eronate. Cu tratarea sfriturilor de
linie, o alt form de spaii albe, exist o alt problem. Liniile noi sunt tratate diferit pe
sisteme diferite. Alternativele generale sunt un salt la linie nou (UNIX), un return (MacOS)
i att un return ct i saltul la linie nou (MS Windows). Un alt lucru obinuit pentru aplicaii
este, de asemenea, inserarea de secvene contradictorii cu oricare dintre acestea, n orice
ordine, atunci cnd ntlnesc un fiier dintr-un sistem strin. W3C a hotrt c nu poate face
totul i a ales un set rezonabil de reguli. Dac analizorul ntlnete fie
(return
, salt la linie nou), fie (return), el le nlocuiete cu &#0A; (salt la linie nou),
caracterul de linie nou UNIX.
Microsoft i Apple au ales mecanisme diferite pentru separarea liniilor, Microsoft
alegnd tehnica curea i bretele obinuit pentru teleimprimatoare, utiliznd un return i
Pagina 73 din 97
apoi un salt la linie nou pentru a indica o linie nou. Apple a hotrt c saltul la linie nou
era redundant i a considerat c un singur return este suficient, modelat probabil dup
comportamentul unei maini de scris obinuite. UNIX a utilizat de la nceput un singur salt la
linie nou pentru a realiza acelai lucru, iar acesta a fost standardul convenit pentru XML. n
atribute exist o secven de transformare standard i apoi o prelucrare
adugat special pentru orice n afar de CDATA:
Referinele la caractere sunt prelucrate prin adugarea caracterului referit la valoarea
de ieire a atributului.
Referinele la entiti sunt procesate prin prelucrarea recursiv a textului de nlocuit
al entitii.
Spaiile albe, #x20 (spaiu), #x0D (retur de car), #x0A (salt de linie nou) i #x09
(tab orizontal) sunt prelucrate prin adugarea lui #x20 (spaiu) la valoarea normalizat a
ieirii excepie fcnd faptul c se adaug un singur #x20(spaiu) pentru secvena
#x0D#x0A (retur de car, salt la linie nou), care este parte a unei entiti externe analizate
sau valoarea entitii literale a unei entiti analizate interne.
Celelalte caractere sunt prelucrate prin adugarea lor la valoarea normalizat a
ieirii.
Dac tipul de dat al atributului nuI este CDATA, cel prestabilit, atunci se aplic
nc o transformare. Spaiile din fa i din spate sunt eliminate, iar spaiile multiple sunt
comasate ntr-un singur spaiu. Diferena dintre cele dou tipuri de normalizare const n
faptul c se pot transfera n mod convenabil iruri lungi ntr-un atribut, restrnge linii astfel
nct s ncap n pagin, iar n final coninutul elementului s rmn relativ curat.
4.10.8 Tipuri de elemente
n mod surprinztor, la validare nu este o eroare utilizarea unui element de un tip care
nu a fost declarat, cu toate c este posibil ca analizorul s emit un advertisment. De fapt,
permind n interiorul unor elemente alte tipuri de elmente nedeclarate, indiferent de ceea ce
spune modelul lor de coninut, se poate suplimenta DTD-ul unui document cu elemente din
alte zone de nume. Deci, tot ce rmne de fcut este utilizarea elementului nedeclarat ntr-o
manier exact, construit corect, identificnd pe ct posibil zona de nume de unde provine.
n termeni XML, a fi construit corect este un alt mod de a spune c acel element formeaz un
arbore sau o ramur a unui arbore care este complet n sine. Acest lucru este necesar
deoarece XML permite construirea de documente mai mari din unele mai mici i este un
element cheie pentru utilizarea XML pe Web. Fiecare element dintr-un document XML valid
Pagina 74 din 97
a fost definit n DTD-ul asociat acelui document prin declaraia DOCTYPE. DTD-ul declar
urmtoarele:
Numele efective ale elementelor
Regulile utilizate pentru a determina care elemente se pot imbrica n alte elemente i
n ce ordine
Atributele posibile i valorile lor prestabilite sau constante
Valorile caracter ale tipurilor enumerate
Entitile neanalizate utilizate n document i modul n care sunt referite prin nume
Codificrile de limb utilizate n document
Alte informaii importante pentru prelucrarea i redarea documentului
Respectnd aceste reguli se pot crea documente n concordan cu ablonul pe care
proiectantul documentului l-a avut n minte atunci cnd a creat DTD-ul. ntr-un mediu care
nu valideaz se pot crea etichete i atribute pe msura naintrii. Foaia sau manualul de
codare afieaz toate acestea ntr-un format uor de citit i neles, dac autorul DTD-ului i-a
fcut treaba corect. Cnd se creeaz un document XML sau se corecteaz o eroare, este
posibil s nu se beneficieze de avantajul unui mediu de creare complet. Este ntotdeauna
important pstrarea la ndemn a documentaiei de codare pentru cazul n care apar
defeciuni.
4.10.9 Entiti neanalizate
O entitate neanalizat este orice lucru care nu poate fi recunoscut de un procesor
XML, fie date binare, cum ar fi un fiier imagine sau audio, fie text care trebuie s fie
transferat unei aplicaii fr a fi prelucrat n vreun fel. HTML utilizeaz comentarii pentru a
ascunde un astfel de text de browserul HTML, dar XML are cteva mecanisme care
funcioneaz mult mai sigur.
O entitate neanalizat trebuie mai nti s fie declarat ca NOTATION, o declaraie
special care numete o aplicaie de asisten care tie cum s lucreze cu entiti de un anumit
tip. Notaiei i este dat un nume, un identificator public opional i apoi numele mai puin
opional al aplicaiei de asisten, ca n una din variantele urmtoare:
<! NOTATION nume-mnemonic PUBLIC identificator-public>
<!
NOTATION
nume-mnemonic
PUBLIC
identificator-public
nume-
aplicaie.exe>
<! NOTATION nume-mnemonic SYSTEM nume-aplicaie.exe>
Prima opiune funcioneaz numai dac exist un catalog. Nu se poate pune baza pe
un catalog deoarece acesta funcioneaz indiferent dac exist sau nu catalog. Nu se poate
Pagina 75 din 97
baza pe un catalog deoarece acesta este un instrument SGML pe care multe procesoare XML
actuale l-au motenit implicit de la predecesoarele lor SGML. Studierea catalogului nu este
specificat n recomandarea W3C i nu se poate conta niciodat pe ea. Dac este posibil, se
recomand utilizarea ultimele dou versiuni. Pe de alt parte, codarea hard a informaiilor
despre locaia i identitatea aplicaiei de asisten n absolut fiecare DTD este un anacronism
predispus la erori pe Web.
Prin redefinirea comportamentului script-urilor n prezena comentariilor, proiectanii
XML-ului au introdus o problem de incompatibilitate ntre XML i HTML. Dup toate
probabilitile, procesoarele XML vor continua s transfere comentarii la aplicaii deoarece
multe pagini se vor ntrerupe dac nu vor avea acest comportament. De asemenea,
procesoarelor le este permis transferul informaiei comentate prin acelai limbaj prin care li
se permite s nu o fac. Dup ce o notaie a unei entiti neanalizate a fost definit, ea trebuie
s fie declarat ca o entitate, astfel:
<! ENTITY nume-mnemonic NDATA nume-mnemonic>
i apoi trecut ca un atribut ntr-un element pentru a o putea utiliza:
<! ELEMENT name EMPTY>
<! ATTLIST name type NOTATION mnemonic
>
Numele mnemonice nu mpart aceeai zon de nume, deci nu are importan dac ele
sunt identice. n acest moment se poate utiliza tipul de date definit astfel. Tipul de date poate
fi utilizat numai ca atribut al unui element declarat ca fiind de acel tip sau avnd acel tip
disponibil ntr-o enumerare. Celelalte atribute adun informaiile de care are nevoie aplicaia
de asisten extern pentru a fi capabil s prelucreze datele. O aplicaie tipic poate fi un
fiier imagine:
<image source =uri alt =graphic description type=gif89a>
Acest element va necesita n DTD urmtoarele declaraii:
<! NOTATION gif89a PUBLIC -//CompuServe//NOTATION Graphics Interchange
Format 89a//EN explorer.exe>
<! ENTITY gif89a NDATA gif89a >
<! ELEMENT image EMPTY>
<! ATTLIST image source CDATA #REQUIRED
alt CDATA #IMPLIED
type NDATA gif89a >
Pagina 76 din 97
Pentru majoritatea instrumentelor, nu va avea importan dac formatul este specificat

ca gif87a sau ca gif89a, deoarece aceleai instrumente manevreaz ambele formate.
Notaiile vor fi mult mbuntite o dat cu adugarea facilitilor oferite de
XLink/XPointer care ajut la urmrirea locaiilor asistenilor. Cu instabilitatea general a
Web-ului la nivelul su actual i cu larga varietate de faciliti i arhitecturi de pe sistemele
utilizatorilor, orice ajutor care poate fi obinut de ctre utilizator va face mai uoar
configurarea instrumentelor XML. DTD-ul, n forma sa actual, necesit mult prea mult
ajustare n stil UNIX a fiierelor pentru a fi pe placul utilizatorilor obinuii. XLink i
XPointer ncearc s nving limitrile tehnologiei pointer actuale. Permit toate tipurile de
relaii, inclusiv pointeri inveri care s fie generai pe loc n documente fr acces la scriere,
realiznd-ui efectul chiar asupra copiei afiate, i nu prin inserarea fizic brut a etichetelor
n coninut.
Cerinele XML pentru notaii, n forma actual, sunt extrem de severe.
Posibilitatea de a indica locaia unde se afl aplicaia de asisten poate fi comod
pentru notaii neobinuite sau foarte specializate. Totui, este de ateptat ca agentul utilizator
s tie cum s afieze multe dintre tipurile mai obinuite, cum ar fi GIF-uri, JPEG-uri,
PNGuri, WAV-uri i alte tipuri de fiiere binare mai mult sau mai puin standard, utilizate pe
Web. Iat o list a notaiilor obinuite:
<! NOTATION eps PUBLIC +//ISBN -201-18127-4::Adobe//NOTATION
Postscript Language Reference Manual//EN>
<! NOTATION tex PUBLIC +//ISBN -201-13448-9::Knuth//NOTATION The
TeXbook//EN>
<! NOTATION cmgchar PUBLIC ISO 8632/2//NOTATION Character encoding
//EN >
<! NOTATION cmgbinary PUBLIC ISO 8632/3//NOTATION Binary encoding
//EN >
<! NOTATION cmgclear PUBLIC ISO 8632/4//NOTATION Clear text encoding
//EN >
<! NOTATION tiff PUBLIC ISO 12083:1994//NOTATION TIFF-1 //EN >
<!
NOTATION
jpeg
PUBLIC
ISO/IEC
10918:1983//NOTATION
Digital
Compresion and Encoding of

Continuous tone Still Images (JPEG)//EN >
<! NOTATION gif87a PUBLIC -//CompuServe //NOTATION Graphics Interchange
Format 87a//EN
Pagina 77 din 97
>
<! NOTATION gif89a PUBLIC -//CompuServe //NOTATION Graphics Interchange
Format 89a//EN
>
<! NOTATION fax PUBLIC -//USA-DOD//NOTATION CCITT Group 4 Facsimile
Type 1 Untiled
Raster//EN >
Desigur, va trebui s se adauge un ID sistem pentru a le putea utiliza, fie ca pointer la
o aplicaie de asisten local, fie n fiierul catalog care centralizeaz locaiile acestor
aplicaii, dac este disponibil pentru instrumentele folosite.
4.10.10 Aplicaii din lumea real
S-au vzut deja, mai sus, unele dintre instrumentele care pot fi utilizate pentru a crea
un document XML, dar unde se pot gsi DTD-urile? Multe DTD-uri se afl n domenii
publice sau sunt disponibile ca standarde de la ISO, ANSI sau de la alte organisme de
standardizare. Cteva dintre aplicaiile mai importante ale XML care se afirm n lumea de
azi sunt:
Health Level-7 (HL7), Standardul informatic de sntate (Health Informatics
Standard) a fost introdus n anul 1987 pentru a dezvolta standarde pentru schimbul electronic
de informaii clinice, financiare i administrative ntre sistemele de calcul din domeniul
sntii. HL7 s-a concentrat asupra utilizrii SGML i XML ca mecanisme de transport ntre
diferite sisteme informatice din domeniul sntii.
Real Estate Transaction Standard (RETS standardul de tranzacii imobiliare) este o
metod bazat pe XML pentru schimbul de informaii referitoare la tranzaciile imobiliare.
Un standard concurent este Real Estate Markup Language (RELML limbajul de marcare
pentru domeniul imobiliar) care utilizeaz DTD-urile XML pentru a prezenta listinguri cu
spaii pentru locuine, spaii comerciale i terenuri virane, pentru publicarea lor pe Web.
RosettaNet, limbajul comun pentru afaceri, este o iniiativ EDI/E-Commerce
destinat intermedierilor n domeniul calculatoarelor.
MathML i CML sunt dou standarde XML tiinifice care permit matematicienilor
s editeze ecuaii, iar chimitilor s prezinte formule chimice.
SMIL, the Synchronized Multimedia Integration Language (limbajul de integrare
multimedia sincronizat), este HyTime for Everyman (HyTime pentru fiecare), un limbaj de
marcare multimedia care permite furnizorilor de coninut s realizeze prezentri audio i
video complexe.
Pagina 78 din 97
ICE, Information and Content Exchange (schimb de informaii i coninut), cu toate

c nu este chiar o aplicaie XML, fiind de fapt un mecanism de transport, permite schimbul
de investiii on-line i informaii personale pe Web.
SAE J2008 este un sistem de comenzi i inventariere bazat pe XML pentru industria
auto; MISTI, the Missile Industry Supply-chain Transaction Infrastructures, face acelai lucru
pentru industria spaial.
Chinese DTDs furnizeaz structura specializat necesar pentru publicarea n limba
chinez. DTD-uri similare exist pentru japonez, coreean, vietnamez i multe alte limbi.
GedML, un standard XML genealogic, ncurajeaz fluxul liber pe Web al datelor
genealogice. Exist deja programe pentru conversia fiierelor standard Genealogical Data
COMmunication (GEDCOM) la GedML. Fiecare productor de browsere are standarde
propuse, despre care ceilali se plng c sunt ndreptate mpotriva lor. Aa cum rzboaiele
browserelor au dus la dezvoltarea unor extensii patentate la HTML, care tindeau (sau
ncercau) s blocheze celelalte browsere, crend un turn Babel de metode incompatibile,
XML va fi ntr-o continu schimbare pentru o bun perioad de timp. Totui, bazele exist
deja, iar o comunitate de utilizatori cernd din ce n ce mai insistent standarde deschise
conduce diferitele propuneri spre convergen. Multe dintre succesele majore au fost
standarde ale ISO i ANSI, care vnd documentaia pentru a-i finana eforturile n crearea de
standarde, dar asigur un teren neutru pentru toi partenerii. Pentru preul documentaiei, de
obicei cteva sute de dolari, toi pot concura la acelai nivel.
CAPITOLUL V
PREZENTAREA APLICAIEI
ElectronX este o aplicaie e-commerce, un site web ce reprezint un magazin
virtual de electronice care se adreseaz tuturor persoanelor care doresc s achiziioneze
diverse produse, n cazul de fa electronice, prin intermediul internetului accesnd un
magazin virtual din confortul propriei locuine, comerul electronic mondial avnd o
dinamic ascendent pe msur ce tot mai muli consumatori i tot mai multe afaceri se
conecteaz la web, acest tip de comer ctignd din ce n ce mai mult teren i n Romnia.
Aplicaia se dorete a fi o unealt folositoare utilizatorilor, avndu-se n vedere
dezvoltarea interfeei pentru a fi user-friendly, dorindu-se a fi o aplicaie ct mai uor de
Pagina 79 din 97
folosit, eventualele neajunsuri i opinii putnd fi aduse la cunotina administratorului siteului prin adresele de e-mail puse la dispoziia utilizatorilor n pagina de contact.
Tehnologiile folosite pentru realizarea aplicaiei sunt PHP pentru generarea dinamic
paginilor XHTML i interogarea bazelor de date , i MySql pentru gestionarea bazelor de
date, totul rulnd pe suportul oferit de serverul Apache.
Realizarea acestui site presupune utilizarea unei baze de date care s conin att date
despre utilizatori ct i date despre produsele puse n vnzare i date despre comenzile
efectuate de ctre utilizatori. Baza de date va conine apte tabele cuprinznd informaiile
necesare bunei funcionri a aplicaiei.
5.1 Cerine hardware
Aplicaia nu necesit componente hardware performante.
Cerinele hardware pentru server sunt:
Procesor Pentium IV 2600 MHz
Memorie RAM 512 Mb
Hard Disk 120 Gb
Minimul cerinelor hardware pentru utilizatori consta in:
Procesor Pentium III (AMD Athlon), 800 MHz
Memorie RAM 128 Mb
5.2 Cerine software
Cerinele software pentru aplicaie sunt:
Pentru server:
Wampserver 5, versiunea 1.6.4
Un editor PHP
Pentru client:
Internet Explorer 5.0 si versiunile urmtoare sau Mozilla Firefox 1.0.7
5.3 Funcionalitile aplicaiei
La accesarea site-ului se va deschide pagina principal unde utilizatorul se va putea
autentifica prin intermediul unui nume de utilizator i a unei parole. Dac nu are cont i va
putea crea unul nou.
Dup autentificare utilizatorul poate s modifice datele personale sau parola
deschizndu-se un formular predefinit unde se pot efectua schimbrile dorite.
Utilizatorul poate s acceseze pagina de prezentare a produselor oferite de site de
unde i poate alege unul sau mai multe produse pentru a le cumpra. Produsele alese vor fi
Pagina 80 din 97
adugate ntr-un co de cumprturi acestea putnd fi comandate. La trimiterea comenzii

datele utilizatorului i produsele comandate sunt reinute n baza de date.
Se poate de asemenea efectua o cutare dup nume a produselor, fiind afiate
rezultatele cutrii n baza de date.
5.4 Proiectarea bazei de date
Baza de date conine apte tabele.
Tabela Utilizatori conine informaii despre utilizatorii nregistrai n sistem.
Tabela Itemi reine datele despre produsele oferite la vnzare.
n tabela Caracteristici sunt reinute caracteristicile fiecrui produs din tabela Itemi
n tabela Categorii sunt stocate datele categoriilor definite pentru ierarhia produselor.
n tabela Co sunt reinute produsele pe care un utilizator logat dorete s le comande
la un moment dat. Dup trimiterea comenzii sau la ieirea din cont nregistrrile din aceast
tabel sunt terse.
Tabela Comenzi conine informaii despre toate comenzile efectuate de ctre
utilizatori.
Tabela Itemi_Comanda stocheaz datele despre produsele comandate.
Structura bazei de date este descris n schema conceptual urmtoare:
Pagina 81 din 97
Schema fizic a bazei de date se prezint astfel:

Utilizatori Tip
Setare de baz
Setri extra
Cmp
id
int(11)
ul
D
NULL
Auto_increment primar
utilizator
char(60)
a
D
char(60)
a
D
char(30)
a
D
prenume
char(30)
a
D
cnp
varchar(13)
a
D
char(3)
a
D
varchar(50)
a
D
telefon
varchar(25)
a
D
adresa
varchar(255
a
D
sector
)
varchar(2)
a
D
varchar(10)
a
D
al
oras
char(30)
a
D
judet
varchar(25)
a
D
parola
nume
varsta
email
cod_post
Cheie
a
Itemi
Tip
Nul
Setare de baz
Setri extra
Cmp
item_id
cat_id
nume_item
Prt
int(11)
int(11)
varchar(75)
float(8,2)
Da
Da
Da
Da
NULL
Auto_increment Primara
-
Pagina 82 din 97
Cheie
descriere
imagine
varchar(200)
varchar(50)
Caracteristici Tip
Cmp
Id_item
producator
Model
Da
Da
Nul Setare de
Setri extra
Cheie
baz
int(11)
Da
varchar(25) Da
varchar(25) Da
Categorii
Tip
Nul Setare de baz
Cmp
cat_id
nume_cat
desc_cat
int(11)
Da
varchar(50) Da
varchar(200) Da
Co
Tip
Nul Setare de baz
Setri extra
Cmp
Id
Id_sesiune
Id_item_v
Cant
producator
Model
data_ad
int(11)
char(60)
int(11)
int(11)
varchar(25)
varchar(25)
datetime
Da
Da
Da
Da
Da
Da
Da
Auto_increment primara
-
Comenzi
Tip
Nul Setare de
Cmp
id_c
data_c
Nume_c
adresa
Oras
cod_postal
Judet
sector
valoare
mod_plata
Status
Int(11)
datetime
varchar(100)
varchar(255)
varchar(50)
varchar(10)
varchar(25)
varchar(2)
float(8,2)
varchar(20)
enum('procesata',
Da
Da
Da
Da
Da
Da
Da
Da
Da
Da
Da
NULL
Setri extra
Cheie
Auto_increment primar
-
NULL
baz
NULL
Cheie
Setri extra
Cheie
Auto_increment primara
-
'asteptare')
Itemi_comanda
Tip
Nul Setare de baz
Setri extra
Cheie
Cmp
Id
int(11)
Da
Auto_increment
primar
NULL
Pagina 83 din 97
Id_comanda
Id_item
Cant
producator
Model
Prt
int(11)
int(11)
int(11)
varchar(25)
varchar(25)
float(8,2)
Da
Da
Da
Da
Da
Da
5.5 Implementarea codului

Dup crearea bazei de date, urmtorul pas este generarea paginilor web ale aplicaiei
folosind codul HTML/PHP.
Pentru editarea codului am folosit utilitarul PHPEdit versiunea 2.10.0.4616 dezvoltate
de compania WaterProof Software, acest utilitar putnd fi descrcat de pe internet de la
adresa http://www.waterproof.fr/ cu o licen de utilizare gratuit pe o perioada de 30 de zile.
Acest editor de cod este destinat n special crerii scripturilor PHP oferind suport i pentru
alte limbaje: HTML, CSS, XML, XSLT, Javascript, SQL.
Sistemul complet are dou tipuri de componente: fiiere HTML i fiiere PHP.
Interfaa aplicaiei este realizat cu ajutorul paginilor HTLM, iar scripturile PHP gestioneaz
interaciunea dintre paginile HTML i baza de date prin intermediul serverului Apache.
Inregistrare.php
Atunci cnd un client nou dorete s achiziioneze unul din produsele oferite de siteul
ElectronX trebuie s i creeze mai nti un cont de utilizare. Clientul trebuie s introduc
datele personale (nume, prenume, CNP, vrsta, adresa de e-mail, telefon, adres, ora, jude )
ntr-un formular, precum i un nume de utilizator i o parol. Datele vor fi folosite
nregistrarea comenzilor i pentru a deine o eviden a utilizatorilor site-ului. Contul nu va fi
creat dac nu sunt completate toate cmpurile considerate obligatorii. Dup inserarea datelor
n tabela Utilizatori se creeaz i fiierul clieni.xml n care sunt stocate toate datele clienilor
nregistrai n baza de date.
$_SESSION['user'] = $_POST['user'];
$_SESSION['parola1'] = $_POST['parola1'];
$_SESSION['parola2'] = $_POST['parola2'];
$_SESSION['nume'] = $_POST['nume'];
$_SESSION['prenume'] = $_POST['prenume'];
$_SESSION['cnp'] = $_POST['cnp'];
$_SESSION['varsta'] = $_POST['varsta'];
Pagina 84 din 97
$_SESSION['email'] = $_POST['email'];
$_SESSION['telefon'] = $_POST['telefon'];
$_SESSION['adresa'] = $_POST['adresa'];
$_SESSION['sector'] = $_POST['sector'];
$_SESSION['cod_postal'] = $_POST['cod_postal'];
$_SESSION['oras'] = $_POST['oras'];
$_SESSION['judet'] = $_POST['judet'];
if(($_SESSION['user'] == '') || ($_SESSION['parola1'] == '') ||

($_SESSION['parola2'] != $_SESSION['parola1']) || ($_SESSION['nume'] == '')
|| ($_SESSION['prenume'] == '') || ($_SESSION['varsta'] == '') ||
(!is_numeric($_SESSION['varsta'])) || (strlen($_SESSION['varsta']) < 2) ||
($_SESSION['cnp'] == '') ||($_SESSION['email'] == '') || ($_SESSION['telefon'] == '')
||
($_SESSION['adresa'] == '') || ($_SESSION['oras'] == ''))
{
echo '<html>
<head></head>
<body text="#1A1A8C">
Eroare! 
<center>Nu ai introdus date in formular sau cele introduse nu sunt
corecte. 
Apasa <a href="inregistrare.php">aici</a> pentru a te intoarce la pagina
anterioara.</center>
</body>
</html>';
}
else
{
echo '<html>
<head></head>
 
Pagina 85 din 97
<center>Va multumim. 

Datele au fost introduse cu succes in baza de date. 
Pentru
va
autentifica
apasati
<a
href=
"autentificare.php">
aici
</a>.</center>
</body>
</html>';
$cerereSQL = "INSERT INTO ùtilizatori` (ùtilizator`, `parola`, `nume`, `prenume`,
`cnp`,
èmail`, `telefon`, `varsta`, àdresa`, `sector`, `cod_postal`, òras`, `judet`)
VALUES ('".addentities($_SESSION['user'])."', ' " .md5($_SESSION['parola1'])." ',
'".addentities($_SESSION['nume'])."', '".addentities($_SESSION['prenume'])."',
'".addentities($_SESSION['cnp'])."', '".addentities($_SESSION['email'])."',
'".addentities($_SESSION['telefon'])."', '".addentities($_SESSION['varsta'])."',
'".addentities($_SESSION['adresa'])."', '".addentities($_SESSION['sector'])."',
'".addentities($_SESSION['cod_postal'])."', '".addentities($_SESSION['oras'])."',
'".addentities($_SESSION['judet'])."')";
mysql_query($cerereSQL);
Autentificare.php
Odat ce contul de utilizare a fost creat utilizatorul trebuie sa se autentifice pentru a
avea acces la paginile de administrare a contului personal, pentru a putea face comenzi. n
acest script se verific existena numelui de utilizator n baza de date i corectitudinea parolei,
i n caz de eroare, aceasta se semnaleaz. Autentificarea se realizeaz prin intermediul
sesiunilor, reinndu-se pentru fiecare utilizator o instan unic de sesiune.
$_SESSION['user'] = $_POST['user'];
if(($_POST['user'] == '') || ($_POST['parola'] == ''))
{
echo '<html>
<head></head>
 <center>Pentru a va accesa contul trebuie sa completati
casutele. 
Pagina 86 din 97
Apasati <a href="autentificare.php">aici</a> pentru a va intoarce la pagina

precedenta.
</center>
</body>
</html>';
}
else
{
$cerereSQL
"SELECT
FROM
ùtilizatori`
WHERE
utilizator='
".htmlentities($_POST['user'])."' AND parola=' ". md5($_POST['parola'])."'";

$rezultat = mysql_query($cerereSQL);
if(mysql_num_rows($rezultat) == 1)
{
while($rand = mysql_fetch_array($rezultat))
{
$_SESSION['logat'] = 'Da';
echo '<META HTTP-EQUIV=Refresh CONTENT="0; URL=pagina.php">';
}
}
else
{
echo '<html>
<head></head>
Eroare! 
<center> Date incorecte. 
Apasati <a href="autentificare.php">aici</a> pentru a va intoarce la pagina
precedenta.

</center>
</body>
</html>';
Pagina.php
Pagina 87 din 97
Dup ce utilizatorul s-a autentificat se deschide pagina de administrare a contului de

utilizare. n acest script utilizatorul are la dispoziie mai multe opiuni: modificarea datelor
personale, modificarea parolei, sunt afiate toate comenzile trimise de ctre utilizator, i poate
accesa unul din link-urile care duc ctre paginile de prezentare a produselor, afiare a
statisticilor vnzrilor, afiare a coului de cumprturi sau pentru ieirea din cont.
Vezimagazin.php
n acest script sunt prezentate toate categoriile i toate produsele existente n baza de
date. La deschiderea paginii apare o list de link-uri cu toate categoriile de produse, iar dac
utilizatorul selecteaz o categorie se vor afia toate produsele din acea categorie, pentru
fiecare dintre acestea afindu-se numele, preul i o mic imagine de prezentare.
$get_cats = "select cat_id, nume_cat, desc_cat from categorii order by nume_cat";
$get_cats_res = mysql_query($get_cats) or die(mysql_error()) ;
if (mysql_num_rows($get_cats_res)<1) {
$display_block = " Nu exista categorii de vizualizat ";
} else {
while($cats = mysql_fetch_array($get_cats_res)){
$cat_id = $cats[cat_id];
$cat_title = strtoupper(stripslashes($cats[nume_cat]));
$cat_desc = stripslashes($cats[desc_cat]);
$display_block .= "
<a href=\"$_SERVER[PHP_SELF]?cat_id= $cat_id\"> $cat_title </a>
 $cat_desc ";
if ($_GET[cat_id] == $cat_id) {
$get_items = "select item_id, nume_item, pret, imagine from itemi where
cat_id=$cat_id order by nume_item"; $get_items_res = mysql_query($get_items) or
die(mysql_error());
if (mysql_num_rows($get_items_res) <1) {
$display_block = " Nu exista produse in aceasta categorie ";
} else {
$display_block .= "<ul>";
while($items = mysql_fetch_array($get_items_res)) {
Pagina 88 din 97
$item_id = $items[item_id];
$item_title = stripslashes($items[nume_item]);
$item_price = $items[pret];
$item_image = $items[imagine];
$display_block .= " <li>
<table border=1 width=50%>
<tr>
<th><a href=\"showitem.php?item_id=$item_id\"> $item_title</a></th>
</tr>
<tr>
<th height=180 width=180><img src=\"$item_image\" alt=\"poza\" border=0></th>
</tr>
<tr>
<th>$item_price RON (Pretul contine TVA)</th>
</tr>
<tr>
<th><a href=\"showitem.php?item_id=$item_id\"> Cumpara acest produs</a></th>
</tr>
</table> ";
}
$display_block .= "</ul>";
}
}
}
}
Arataprodus.php
Pagina de afiare a produselor nu face dect sa afieze toate informaiile referitoare la
cte un produs. Aceste informaii sunt introduse automat ntr-un formular. n acest formular
utilizatorul mai poate s aleag numrul produselor pe care dorete s le comande i apoi
dac dorete s-l adauge la co trebuie s apese pe butonul Adaug la co.
Aratacos.php
Pagina 89 din 97
n aceast pagin este prezentat coninutul coului de cumprturi. Produsele existente

n co sunt afiate ntr-un tabel, pentru fiecare fiind afiate numele, productorul, modelul,
preul, cantitatea, preul total i un link pentru scoaterea produsului respectiv din co. Pe
pagin mai sunt prezente valoarea total a produselor adugate n co i link-urile ctre
pagina de afiare a produselor i ctre pagina de comand.
Comanda.php
Pagina de comand conine un formular n care sunt afiate numele, prenumele, CNPul utilizatorului, adresa, oraul, judeul, aceste cmpuri putnd fi modificate n cazul n care
utilizatorul dorete livrarea comenzii la o alt adresa dect cea din cont i valoarea total a
comenzii. La apsarea butonului Trimite comanda se insereaz n tabela comenzi datele
despre comand, iar n tabela itemi_comanda se insereaz produsele comandate. Dup
inserarea datelor n tabele se creeaz fiierul comenzi.xml n care sunt stocate toate comenzile
din tabel.
if(!isset($_POST['adresa'])) $_SESSION['adresa'] = '';
else $_SESSION['adresa'] = $_POST['adresa'];
if(!isset($_POST['sector'])) $_SESSION['sector'] = '';
else $_SESSION['sector'] = $_POST['sector'];
if(!isset($_POST['cod_postal'])) $_SESSION['cod_postal'] = '';
else $_SESSION['cod_postal'] = $_POST['cod_postal'];
if(!isset($_POST['oras'])) $_SESSION['oras'] = '';
else $_SESSION['oras'] = $_POST['oras'];
if(!isset($_POST['judet'])) $_SESSION['judet'] = '';
else $_SESSION['judet'] = $_POST['judet'];
if(($_SESSION['adresa'] == '') || ($_SESSION['oras'] == ''))
{
echo '<html>
<head></head>
<center><h4>Nu ai introdus noua adresa de livrare sau orasul. 
Apasa
<a
href="comanda.php">aici</a>
anterioara.</h4></center>
</body>
Pagina 90 din 97
pentru
te
intoarce
la
pagina
</html>';
}
else
{
echo '<html>
<head></head>
<center><h4>Va multumim. 
Comanda a fost trimisa cu succes. 
Inapoi la magazin <a href="seestore.php">aici</a>.</h4></center>
</body>
</html>';
$cerereSQL = "INSERT INTO `comenzi` (`data_c`, `nume_c`, àdresa`, òras`,
`cod_postal`,
`judet`, `sector`, `valoare`, `mod_plata`, `status`)
VALUES (now(), '".addentities($_SESSION['user'])."',
'".addentities($_SESSION['adresa'])."', '".addentities($_SESSION['oras'])."',
'".addentities($_SESSION['cod_postal'])."', '".addentities($_SESSION['judet'])."',
'".addentities($_SESSION['sector'])."',
'".addentities($_SESSION['afis_price_prod'])."',
'".$_POST['plata']."', 'asteptare' )";
$cid=mysql_insert_id();
$cerereSQL1 = "SELECT cos.id_sesiune, cos.id_item_v, cos.cant, cos.producator,
cos.model, itemi.item_id, itemi.pret FROM cos left join itemi on cos.id_item_v =
itemi.item_id WHERE id_sesiune ='$_SESSION[user]'";
$rezultat1 = mysql_query($cerereSQL1);
while($rand1 = mysql_fetch_array($rezultat1))
{
$cidit=$rand1['id_item_v'];
$ccant=$rand1['cant'];
$cproducator=$rand1['producator'];
$cmodel=$rand1['model'];
$cpret=$rand1['pret'];
Pagina 91 din 97
$cerereSQL =
"insert
into
itemi_comanda
id_comanda,
id_item,
cant,
producator,model, pret ) values ( '$cid', '$cidit', '$ccant',

'$cproducator', '$cmodel', '$cpret' )";
}
$cerereSQL2 = "delete from cos where id_sesiune='$_SESSION[user]'";
mysql_query($cerereSQL2) or die(mysql_error());
}
5.6 Manual de utilizare

Aceast seciune are drept scop prezentarea modului de interacionare al utilizatorului
cu aplicaia.
La accesarea site-ului se va deschide pagina principal unde utilizatorul are doua
posibiliti:
Dac are un cont creat va accesa link-iul care trimite la pagina de autentificare.
n cazul n care nu are un cont trebuie s acceseze link-ul de nregistrare care va
deschide o pagina ce conine un formular de nscriere.
De asemenea pe aceasta pagina, ca de altfel pe toate paginile aplicaiei, exist mai
multe seciuni:
1. Un meniu cu urmtoarele link-uri:
Home face legtura cu pagina principal
Contul meu deschide pagina de administrare a contului personal
Produse sunt afiate categoriile i produsele existente n baza de date
Coul de cumprturi conine produsele adugate n co de ctre utilizator
Statistici vnzri sunt prezentate vnzrile totale i pe categorii n termen de o
sptmna i o lun, precum i cel mai bine vndute produse din fiecare categorie i categoria
cu cele mai mari vnzri
Contact sunt prezentate opiunile de a lua legtura cu sediul societii
Termeni i condiii conine drepturile i obligaiile utilizatorilor si societii
Ieire din cont dezautentificarea utilizatorului
2. O seciune de cutare unde utilizatorul poate s introduc unul sau mai multe
cuvinte ce vor fi cutate n baza de date
3. O seciune n care sunt afiate toate categoriile de produse
Pagina 92 din 97
4. O seciune ce conine un top ale celor mai vndute cinci produse din magazin
Pentru crearea unui cont trebuie accesat link-ul de nregistrare i se va deschide o
pagina cu un formular de nscriere. Apoi utilizatorul va completa datele cerute i va apsa
butonul nregistreaz. Astfel se va crea un cont i se va confirma nregistrarea contului,
afindu-se i un link ctre pagina de autentificare. n cazul n care nu mai dorete nscrierea
va apsa butonul Reseteaz pentru a terge toate informaiile introduse.
La pagina de autentificare utilizatorul trebuie s introduc numele de utilizator
i parola. Dup aceasta trebuie s apese butonul Login i se va deschide pagina Contul meu
unde utilizatorul va putea modifica datele personale sau parola, va putea vizualiza
produ
sele, coul de cumprturi i va vizualiza comenzile efectuate de el anterior.
Pagina 93 din 97
n pagina de prezentare a produselor sunt afiate toate categoriile i toate produsele

existente n magazin. Pe pagin apare o list de link-uri cu toate categoriile de produse. La
selectarea unei categorii se vor afia toate produsele din acea categorie, pentru fiecare dintre
acestea afindu-se numele, preul i o mic imagine de prezentare.
Pentru a vizualiza un produs se apas fie pe numele produsului fie pe link-ul
Cumpr acest produs i se va deschide pagina de prezentare a produselor care afieaz
toate informaiile referitoare la cte un produs. Utilizatorul mai poate s aleag numrul
produselor pe care dorete s le comande i apoi dac dorete s-l adauge la co trebuie s
apese pe butonul Adaug la co.
Pagina 94 din 97
pagina de vizualizare a coului de cumprturi este prezentat coninutul acestuia.
Produsele existente n co sunt afiate ntr-un tabel, pentru fiecare fiind afiate numele,
productorul, modelul, preul, cantitatea, preul total i un link pentru scoaterea produsului
respectiv din co. Pe pagin mai sunt afiate valoarea total a produselor adugate n co i
link-urile ctre pagina de afiare a produselor i ctre pagina de comand.
Pentru a comanda produsele din cont se apas butonul de comanda i se va deschide
pagina de comand n care sunt afiate numele, prenumele, CNP-ul utilizatorului, adresa,
oraul, judeul, aceste cmpuri putnd fi modificate de ctre utilizator dac acesta dorete
livrarea la alt adres i valoarea total a comenzii i apoi va apsa pe butonul Trimite
Comanda dup care utilizatorul va primi confirmarea nregistrrii comenzii.
Pagina 95 din 97
5.7 Concluzii
Odat cu nceputurile Internetului un nou tip de afacere s-a profilat din ce n ce mai
pronunat pe plan internaional: comerul online. Au aprut nenumrate site-uri i firme care
se ocup cu vnzrile en-gros de produse prin Internet, cu furnizarea accesului contracost la
pagini cu informaii, ntr-un cuvnt abordeaz o form sau alta de comer electronic, un
domeniu aflat n plin expansiune. Avantajul comerului online este evident: piaa pe Internet
crete exponenial de la un an la altul. Un site bine lucrat, cunoscut i care ofer produse de
calitate la preuri bune va avea mai muli vizitatori, mai motivai i mai nzestrai financiar
dect multe magazine convenionale.
Avnd n vedere proiectarea, implementarea i testarea acestui tip de aplicaii
resursele de hardware, software, de timp, cele umane i cele materiale sunt reduse, i n
acelai timp aceast aplicaie are un potenial mare de succes.
Aplicaia ElectronX are ca scop prezentarea unui model de magazin virtual care s
conin funcionalitile de baz specifice unei aplicaii de acest gen: gestionarea conturilor
unui utilizator, prezentarea categoriilor i produselor, cutarea n baza de date, adugarea
produselor ntr-un co de cumprturi, trimiterea comenzilor. Aceste funcionaliti pot fi
mbuntite i de asemenea pot fi adugate i altele att la nivelul aspectului interfeei ct i
la nivelul operaiilor ce pot fi efectuate astfel nct s asigure o funcionare optim a site-ului.
Pagina 96 din 97
Dezvoltarea fr precedent din ultimele dou decenii a tehnologiilor informaionale

determinate de necesitatea stocrii i a transmiterii rapide a informaiilor cu cele mai mici
costuri, a revoluionat comerul global, comerul direct sau cu amnuntul.
Pagina 97 din 97

Utilizarea XML in Baze de Date

Încărcat de

Informații document

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

Utilizarea XML in Baze de Date

Încărcat de

Drepturi de autor:

Formate disponibile

Utilizarea XML in baze de date

Ultima observaie a reprezentat punctul de plecare al proiectului Tsimmis [9][10] de la

Descifrarea schemei ar fi considerabil uurat de facilitatea de a interoga datele avnd

Ce obiecte din baza de date au un atribut al crui nume ncepe cu act?

Izolarea tranzaciilor nu permite crearea tranzaciilor complexe, mari, din tranzacii

- Din perspectiva productorului de coninut, metadatele sunt utilizate pentru stocarea

prenume: &o51 Celine},

Protejarea i gestiunea proprietii intelectuale permite gestiunea coninutului i

- Reprezentarea modelului abstract n XML,

- condiia pe baza seleciei utilizatorului, pot fi satisfcute (sau nu) condiiile

Schema de declarare a elementului digital

DIA definete doar instrumentele necesare n procesul de adaptare, nu realizeaz i

Figura 3 Adaptarea elementului digital i instrumente pentru DIA

3.2 Date i documente

O consecin a acestor transformri adic stocarea datelor dintr-un document ntr-o

Maparea bazat pe tabele este utilizat pentru serializarea datelor relaionale, ca n

Element ------ Atribut

Rezultatul procesrii unui asemenea ablon ar putea fi:

vor fi utilizate n majoritatea implementrilor, n detrimentul bazelor de date relaionale,

3.3.4.1 Tipuri de date

Formatele de text recunoscute n momentul conversiilor pot constitui o problem

3.3.4.3 Date vide

3.3.4.4 Seturi de caractere

documente) i Xquery, dei numeroase limbaje de interogare particulare sunt suportate de

Un document conine datele folosite ntr-un flux, cum ar fi un contract financiar.

API-ul XML:DB al XML:DB.org care este independent de limbajul de programare, i

Din moment ce nivelul de round-tripping depinde de fiecare aplicaie, i alegerea

Integritatea referenial este strns legat de normalizare. Aceasta se refer la

integritii. De exemplu, se presupune c un document conine o legtur XLink care trimite

Cu toate c DTD-urile sunt opionale deoarece un procesor XML poate conduce un

Cu un DTD, un agent utilizator XML care valideaz necesit cel puin nc o

XML nu este bine protejat mpotriva recursivitii Cu toate c este posibil

O descrcare parial este posibil n HTML, deoarece HTML nu are nevoie de

elimin aceste probleme posibile.

4.8 Prologul: declaraia XML

n conformitate cu Recomandarea XML 1.0 a W3C, Documentele autonome nu au

documentului (Document Type Definition - DTD) folosit de un anumit document. Faptul c

Toate celelalte sunt date de tip caracter.

Pentru majoritatea instrumentelor, nu va avea importan dac formatul este specificat

Compresion and Encoding of

ICE, Information and Content Exchange (schimb de informaii i coninut), cu toate

adugate ntr-un co de cumprturi acestea putnd fi comandate. La trimiterea comenzii

Structura bazei de date este descris n schema conceptual urmtoare:

Schema fizic a bazei de date se prezint astfel:

Nul Setare de baz

Nul Setare de baz

Nul Setare de baz

5.5 Implementarea codului

if(($_SESSION['user'] == '') || ($_SESSION['parola1'] == '') ||

<center><font size="+1">Va multumim. <br>

Apasati <a href="autentificare.php">aici</a> pentru a va intoarce la pagina

".htmlentities($_POST['user'])."' AND parola=' ". md5($_POST['parola'])."'";

Dup ce utilizatorul s-a autentificat se deschide pagina de administrare a contului de

n aceast pagin este prezentat coninutul coului de cumprturi. Produsele existente

producator,model, pret ) values ( '$cid', '$cidit', '$ccant',

5.6 Manual de utilizare

n pagina de prezentare a produselor sunt afiate toate categoriile i toate produsele

pagina de vizualizare a coului de cumprturi este prezentat coninutul acestuia.

Dezvoltarea fr precedent din ultimele dou decenii a tehnologiilor informaionale

S-ar putea să vă placă și