utilizarea xml in baze de date

Vizitati www.tocilar.ro ! Arhiva online cu diplome, cursuri si referate postate de utilizatori.

Utilizarea XML in baze de date

INTRODUCERE

Formatul de date XML devine formatul comun acceptat în industrie pentru schimbul

de informaţii dintre diverse sisteme eterogene. Din acest motiv, este important ca o bază de

date să fie capabilă să stocheze informaţiile nu doar în formatele tradiţionale, relaţionale, ci şi

în format XML. Stocând datele XML în format nativ se câştigă foarte mult în performanţă,

aceasta materializându-se în costuri reduse. Un plus de performanţă la o tehnologie de baze

de date înseamnă o infrastructură redusă, servere cu mai puţine procesoare, deci un sistem

informatic ceva mai ieftin, costuri mai mici pentru licenţiere, 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 toţi producătorii de tehnologie din

industrie, dar în schimb are dezavantajul că este un format nu foarte eficient din punct de

vedere al stocării datelor. De aceea devine foarte util ca baza care stochează aceste date sa

aibă capabilităţi de compresie, care să ducă la scăderea spaţiului şi resurselor de stocare

necesare pentru a păstra date în format XML.

Lucrarea de faţă îşi propune să prezinte în capitolele sale câteva noi direcţii de

dezvoltare în domeniul bazelor de date, modelul de date semistructurat şi tehnologia XML ca

o nouă bază de date.

Capitolul I prezintă necesitatea apariţiei 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 instanţa (valoarea) datelor în mod uniform, permiţând interogarea

lor simultană spre deosebire de modelele de date convenţionale, care diferenţiază între cele

două tipuri de informaţie.

Capitolul II detaliază modelul semistructurat al datelor definind conceptul de date

neconvenţionale din mai multe perspective şi pe cel de date semistructurate prezentând

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 aplicaţii

multimedia distribuite.

Capitolul III prezintă legătura dintre tehnologia XML şi bazele de date încercând să

clarifice în ce măsură 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 relaţionale şi invers, stocarea documentelor în sistemul de fişiere

şi în BLOB-uri, detaliază bazele de date native XML, şi prezintă noţiunile de DOM

(Document Object Model) persistent şi sisteme de management ale conţinuturilor.

Capitolul IV se ocupă de construirea documentelor XML prezentând sintaxa XML,

descrierea de vocabulare noi cu XML, avantajele definiţiei tipurilor documentului,

combaterea dezavantajelor definiţiei tipurilor documentului, definirea unui document XML

ca întreg, declaraţia XML, documentele autonome, construirea unui document XML,

declaraţia tipului documentului şi prezintă câteva aplicaţii din lumea reală a declaraţiei tipului

documentului.

Capitolul V constă în prezentarea aplicaţiei – magazinul virtual „ElectronX” - şi

prezintă scopul acestei aplicaţii, cerinţele minime hardware şi software ale aplicaţiei,

funcţionalităţile de bază ale acestui website, proiectarea bazei de date conţinând schema

conceptuală a structurii bazei şi schema fizică a fiecărei tabele, implementarea codului în care

sunt explicate fişierele cele mai importante ale aplicaţiei cu exemplificări din codul sursă, un

manual de utilizare al aplicaţiei în care e descris modul de funcţionare al acesteia şi concluzii

asupra aplicaţiei.

CAPITOLUL I

NOI MODELE DE DATE ŞI APLICAŢIILE 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 interogăm

ca baze de date, dar care nu pot fi constrânse de o schemă. Majoritatea interogărilor web-ului

folosesc tehnici de regăsire a informaţiei pentru a găsi pagini după conţinut. Există însă

puţine posibilităţi de formulare a interogărilor în vederea exploatării 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 necesităţi.

Ideea centrală în modelul semistructurat este de a reprezenta datele sub forma unui graf

Pagina 2 din 97


etichetat. Structura documentelor hipertext este capturată interpretând arcele grafului drept

legături. O reprezentare posibilă este cea introdusă în proiectul UnQL[1]. Etichetele arcurilor

pot fi atât valori (de tip întreg, şir de caractere şi alte tipuri de bază, precum şi de tip de date

abstract, ca video, audio, etc.) cât şi nume de atribute (Film, Titlu, Regizor, Actor), etc.

modelând 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 căilor (path expressions). Acestea

sunt expresii regulate ce exprimă căi generice în graful etichetat, permiţând astfel traversarea

grafului şi colecţionarea tuturor etichetelor ce satisfac o anumită condiţie de selecţie.

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 relaţional şi apoi pe interogarea lor într-un limbaj relaţional de tip SQL. Câteva

exemple prezentate în literatură sunt [3], [4], [5], [6], [7]

A doua categorie porneşte de la un limbaj bazat pe o noţiune formală de calcul cu date

semistructurate: limbajul UnQL este reprezentantul acestei categorii [1]. Acest limbaj

porneşte de la recursivitatea structurală, forma naturală de recursivitate asociată cu tipul de

date grafuri etichetate. Datorită bazei sale teoretice, UnQL este capabil de restructurări

complexe, în adâncime, spre deosebire de limbajele din prima categorie, care se limitează la

scoaterea la suprafaţă a datelor din graf, fără î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 efectuării optimizărilor specifice acestui nou model de

date. Limbajele din prima categorie pot beneficia doar de optimizările specifice modelului

relaţional, deci dezvoltate pentru alt model de date şi în consecinţă nu atât 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, deşi consacrat de mai bine de un

deceniu, continuă să rămână în centrul atenţiei multor cercetători. Cercetarea în acest

domeniu este motivată de absenţa unui model de date atotcuprinzător, fapt ce îngreunează

dezvoltarea de software care converteşte date între două modele diferite.

O complicaţie adiţională este reprezentată de faptul că majoritatea datelor stocate

electronic nu se află în baze de date convenţionale, ci în sisteme de fişiere, programe de

bibliotecă, de poştă electronică, foi de calcul etc., care prezintă capacităţi de interogare

limitate.

Pagina 3 din 97


Ultima observaţie a reprezentat punctul de plecare al proiectului Tsimmis [9][10] de

la Stanford. Proiectul Tsimmis îşi propune integrarea atât a surselor de date care sunt

conforme cu modelele de date standard (relaţional, orientat pe obiecte), cât şi a surselor de

date cu capacităţi de interogare limitate. Aceste surse neconvenţionale sunt împachetate în

aşa-numiţi wrappers (ambalaje). Un astfel de ambalaj asigură interfaţa între sursa de date cu

capacităţi de interogare limitate şi aplicaţia care o interoghează. Aplicaţia trimite către sursă

interogări într-un limbaj expresiv cum ar fi SQL sau OQL şi aşteaptă rezultatul într-un format

numit OEM (Object Exchange Model).

OEM foloseşte grafuri etichetate, ca structură de date, care capturează majoritatea

datelor folosite în aplicaţii de baze de date. În acelaşi timp, toate celelalte structuri de date pot

fi codificate ca grafuri OEM.

Rolul ambalajului constă în: interceptarea interogării şi identificarea acelor părţi ale

acesteia care pot fi efectuate de către sursă, translatarea acestor părţi în limbajul specific

sursei, recepţionarea şi prelucrarea rezultatelor intermediare în vederea reconstituirii

rezultatului interogării originale, codificarea rezultatului final în formatul OEM şi

transmiterea acestuia către aplicaţie.

Evident, dacă interogarea originală este prea complexă, este posibil să nu poată fi

efectuată pornind de la capabilităţile limitate ale sursei. Ambalajul detectează această situaţie

şi anunţă sursa că nu îi poate satisface cererea. Cu cât creşte capacitatea de evaluare a

interogărilor în cadrul ambalajului (de exemplu, capacitatea de a efectua operaţii de tip join,

proiecţii, selecţii, etc.), cu atât se extinde clasa de interogări pe care le poate satisface

combinaţia sursă-ambalaj.

Un proiect similar, cu scopul interogării surselor de date structurate din web este [13].

Se remarcă similaritatea dintre modelul OEM şi cel semistructurat. Într-adevăr, Lore

[11],[12] este un sistem de interogare a datelor semistructurate, foarte similar cu UnQL,

utilizând un model de date inspirat de OEM.

1.3 Navigare în Internet

În anumite situaţii este avantajos să privim bazele de date convenţionale ca fiind

semistructurate. Un exemplu este activitatea de navigare în Internet.

În general, utilizatorul nu poate interoga o bază de date fără a-i cunoaşte schema. Din

nefericire însă, aceasta este adeseori greu de înţeles, datorită mărimii exagerate (zeci de

tabele, de exemplu) şi a terminologiei opace, nestandard, folosite de către proiectanţii bazei

de date.

Pagina 4 din 97


Descifrarea schemei ar fi considerabil uşurată de facilitatea de a interoga datele având

doar o înţelegere parţială a structurii lor. De exemplu, în cazul bazei de date cinematografice

din World-Wide Web[2], următoarele interogări ar fi de folos:

În care atribut găsim şirul de caractere Casablanca?

Există în baza de date întregi mai mari decât 216?

Ce obiecte din baza de date au un atribut al cărui nume începe cu act?

Şi în acest domeniu, modelul semistructurat se dovedeşte a fi folositor. Spre deosebire

de modelele de date convenţionale, care diferenţiază între schema (tipul, structura) şi instanţa

(valoarea) datelor, modelul de date semistructurat reprezintă cele două tipuri de informaţie în

mod uniform, permiţând 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

interogări.

1.4 Cubul de date şi OLAP

Sistemele de suport pentru decizii (Decision support systems) sunt utilizate de către

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 operaţionale 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, analizând vânzările 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 obţin prin agregarea

cuburilor din care provin.

De exemplu, prin însumarea vânzărilor trimestriale pentru fiecare zonă, cubul de date

tridimensional reprezentând vânzările pe trimestru şi zona geografică poate fi redus la un

subcub bidimensional (plan) reprezentând vânzările pe zona geografică. Agregarea este o

operaţie costisitoare, efectuarea ei eficientă pe un volum mare de date reprezentând ţelul

principal al cercetării în acest domeniu ([16],[17],[18],[19]).

1.5 Noi modele tranzacţionale

În mod tradiţional, tranzacţiile modelează unităţi de lucru atomice şi izolate, efectuate

asupra datelor sistemului de gestiune a bazelor de date.

Pagina 5 din 97


Izolarea tranzacţiilor nu permite crearea tranzacţiilor complexe, mari, din tranzacţii

simple. Acest model a avut succes atâta vreme cât tranzacţiile efectuau un număr mic de

operaţii simple asupra datelor cu structură simplă.

Din păcate, modelul tranzacţiilor simple nu satisface cerinţele aplicaţiilor complexe,

în care tranzacţiile trebuiesc combinate şi coordonate pentru a colabora la realizarea unui

scop complex. Aplicaţii ca proiectarea asistată de calculator, automatizarea activităţii de

birou, controlul producţiei, gestiunea activităţilor necesită noi modele tranzacţionale, noi

metode de gestiune a tranzacţiilor, şi noi limbaje de specificare a tranzacţiilor. Limbajele

tranzacţionale sunt limbaje de nivel înalt, de obicei inspirate din logica cu predicate de

ordinul întâi.

Dacă limbajele tradiţionale specificau interogări şi actualizări, noile limbaje

tranzacţionale se concentrează asupra relaţiei dintre tranzacţii, exprimând dependenţe de tipul

tranzacţia 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

tranzacţionale.

Un excelent exponent al noii generaţii de limbaje tranzacţionale este Transaction

Datalog [21], un limbaj deductiv care menţine în acelaşi timp toate proprietăţile tranzacţiilor

clasice, cum ar fi: persistenţă, atomicitate, izolare, terminare şi rollback (revenire).

Limbajul este însoţit de un model teoretic natural şi de o teorie sigură pentru

demonstraţii, permiţând astfel demonstrarea echivalenţei între diverse expresii din acest

limbaj. Acest fapt este crucial pentru optimizare - care constă din înlocuirea unei planificări

cu o alta echivalentă din punct de vedere al efectului său asupra datelor, dar mai eficientă din

punct de vedere al costului execuţiei. Mai mult, faptul că putem demonstra că efectul unei

tranzacţii complexe asupra setului de date este sau nu cel scontat, asigură consistenţa datelor.

1.6 Optimizări

Optimizarea limbajelor de interogare a bazelor de date nu este un domeniu nou, ci

dimpotrivă, există încă de la apariţia acestora. Datorită importanţei sale, acest domeniu va fi

întotdeauna la modă în cercetarea bazelor de date.

Apariţia unui nou model de date atrage după sine o efervescenţă în activitatea de

cercetare a posibilităţilor de optimizare a limbajului de interogare asociat noului model.

Referinţele bibliografice introduse în secţiunea anterioară prezintă şi primele încercări de

optimizare a noilor limbaje de interogare.

Pagina 6 din 97


CAPITOLUL II

MODELE DE REPREZENTARE A DATELOR NECONVENŢIONALE

2.1 Definirea conceptului de date neconvenţionale

În literatura de specialitate există o serie de definiri ale conceptului de date

neconvenţionale şi a altor concepte asociate acestuia:

• Datele neconvenţionale sunt datele care nu au nici unul din tipurile standard: întreg,

real etc. [Blanken, 2002]

• Structura de date neconvenţională este structura de date care nu este în uzul curent al

aplicaţiilor; aceasta poate fi structura produsă de datele semistructurate, cea definită noilor

tipuri de date folosite în aplicaţii şi date cu structuri ce se modifică în mod dinamic. [GSIHT,

2005]

• A patra generaţie a tehnologiilor bazelor de date este prezentată în [Mannino, 2004]

ca fiind o extensie a tehnologiilor bazelor de date cu datele neconvenţionale şi Internetul.

Sistemele celei de-a patra generaţii pot stoca şi manipula tipuri de date neconvenţionale cum

sunt: imaginile, secvenţele video, hărţile, sunetele şi animaţiile ş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 flexibilităţii cu datele neconvenţionale ş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 convenţionale.

La University of Southern California din Los Angeles (USC) există un laborator de

informare numit InfoLAB al cărui scop este investigarea de noi metode pentru gestiunea

tipurilor de date neconvenţionale 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 interogărilor de stream-uri,

• Baze de date spaţio-temporale.

Descrierea datelor neconvenţionale 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 funcţie de producătorul sau sursa metadatelor:

Pagina 7 din 97


- Din perspectiva producătorului de conţinut, metadatele sunt utilizate pentru stocarea

informaţiilor bibliografice ale resurselor, ca de exemplu: numele autorului, titlul, data creării,

formatul resursei etc.

- Din perspectiva furnizorilor de servicii, metadatele oferă informaţii descriptive cu

valoare adăugată (majoritatea în format XML), care reduc informaţiile necesare regăsirii

datelor. Metadatele conţin informaţii despre diferitele formate în care este disponibilă o

resursă şi informaţii semantice asociate acesteia. Aceste informaţii sunt utile pentru realizarea

interogării datelor.

- Din perspectiva consumatorului, metadatele oferă informaţii suplimentare care

descriu preferinţele consumatorului şi resursele disponibile pentru utilizarea datelor.

Metadatele permit personalizarea consumului mediilor şi trebuie luate în considerare de

producători. Metadatele sunt utile pentru distribuirea datelor în Internet sau în reţele mobile

permiţând accesul la resurse în cele mai bune condiţii posibile; de exemplu, metadatele pot fi

folosite pentru descrierea modului în care difuzarea secvenţelor video este adaptată la

scăderea lărgimii de bandă disponibilă la un moment dat.

2.2 Modelul semistructurat ale datelor

Modelele relaţional şi orientat-obiect au fost folosite mult timp pentru modelarea

datelor nu neapărat pentru că erau cele mai naturale soluţii, ci pentru că au în spate un

formalism bine definit. În timp însă, datorită dezvoltării Internetului şi datorită necesităţii

integrării datelor descrise folosind scheme diferite, modelele tradiţionale s-au dovedit a nu

mai fi suficiente şi a devenit acută necesitatea utilizării unui alt model de date, modelul

semistructurat al datelor.

În plus, aplicaţiile Internet realizează operaţii care nu sunt curente în aplicaţiile

tradiţionale cu baze de date cum ar fi: transformări ale datelor, interpretarea interogărilor,

transportul datelor şi prelucrarea bazată pe fluxuri.

Datele semistructurate au devenit un important subiect de studiu din mai multe

motive:

În primul rând, există surse de date pe care am vrea să le tratăm ca baze de date dar

cărora nu le putem impune constrângeri având la bază o schemă, ca în cazul bazelor de date

tradiţionale [Buneman, 1997]. Chiar şi datele structurate, au structură care poate să difere de

la o aplicaţie la alta sau au structură modificabilă în timp. Dezvoltările din domeniul

multimediei au dus la necesitatea de a introduce noi tipuri de date în domeniul tehnologiei

bazelor de date convenţionale. 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 Web-

ului. Majoritatea interogărilor Web exploatează tehnicile de regăsire a datelor pentru a

determina paginile individuale care au conţinut ce corespunde criteriului solicitat. Dar numai

o mică parte din resursele Web sunt structurate astfel încât să permită rezolvarea

interogărilor, Web-ul nefiind conform nici unui model standard. Astfel că se simte nevoia de

a găsi o metodă pentru descrierea structurii datelor Web în vederea rezolvării acestei

probleme.

Al doilea motiv este dat de necesitatea schimbului de date între aplicaţii care folosesc

formate diferite de stocare şi gestiune a datelor necesitând 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 simţit nevoia să se dezvolte

un model care să lege cele două lumi diferite: relaţională ş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 când 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 găsesc sub forma datelor nestructurate, ca de exemplu

sunetele, imaginile, secvenţele video şi chiar unele documente text, iar altă parte sub forma

datelor structurate, memorate în baze de date relaţionale sau orientate obiect. În general, un

utilizator nu poate scrie o interogare pentru o bază de date fără să cunoască schema de

organizare a datelor, iar aceasta este netransparentă pentru utilizatori şi raţionamentul 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 constrângeri 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 relaţionale sau

orientate obiect. În mod evident o astfel de definiţie este imprecisă. Datele sunt

semistructurate dacă: nu au o structură rigidă (de exemplu datele Web, datele sunt combinate

din câteva surse eterogene - ca în cazul depozitelor de date), nu au o structură implicită

Pagina 9 din 97


asociată datelor, sau au o structură parţial specificată [Abiteboul, 1997]. Modelele orientat-

obiect şi relaţional au o schemă fixă pentru fiecare clasă sau fiecare relaţie. Datele

semistructurate permit o flexibilitate sporită, fiind o combinaţie a celor două concepte: clasa

şi relaţia.

Datele semistructurate conţin informaţii 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 însemnând că schema este ataşată

datelor. Combinarea unor date dintr-o bază de date relaţională cu altele dintr-o bază de date

orientată-obiect se poate realiza prin conectarea celor două baze de date, prin intermediul

unei interfeţe, translatând datele de la fiecare sursă în date semistructurate.

În modelul semistructurat al datelor, informaţiile care sunt în mod normal asociate

unei scheme sunt incluse în interiorul datelor. În aceste baze de date nu există o distincţie

clară între date şi schemă, iar gradul de structurare depinde de aplicaţie. În anumite forme ale

modelului semistructurat există o schemă distinctă, în altele nu.

Avantajele modelului semistructurat al datelor sunt următoarele:

• 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

fără schemă, ceea ce justifică flexibilitatea sa. Flexibilitatea reprezintă un instrument util

pentru integrarea datelor, mai ales în cazul problemelor legate de moştenirea bazei de date.

• Îmbunătăţirea eficienţei regăsirii datelor publicate în Internet

• Posibilitatea integrării 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

relaţionale sau orientate-obiect), datele semistructurate nu au o schemă absolută sau o clasă

fixă, fiecare obiect conţinând propria schemă. Iregularitatea structurală nu implică inexistenţa

similarităţilor structurale între obiecte. Din contră, în mod obişnuit, obiectele semistructurate

care descriu acelaşi 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 conţin 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 având reprezentate obiecte iar arcele reprezentând atributele obiectelor. În

plus, arcele modelează natural relaţiile 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 conţine

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 fără înţelesuri 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 aplicaţii. 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 proprietăţi descriptive. O proprietate poate fi folosită într-un arc pentru a

descrie nodurile învecinate.

Pagina 11 din 97


În figura 1 este prezentată exemplificarea modelării unei părţi dintr-o bază de date

multimedia folosind OEM.

Figura 1 – Modelul OEM al unei părţi dintr-o bază de date multimedia

Informaţii: &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 obţinute: &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 relaţionale pot fi descrise cu uşurinţă folosind OEM. În

plus, OEM asigură o flexibilitate mai mare în descrierea datelor tolerând lipsa unor atribute

pentru anumite înregistrări sau existenţa mai multor valori pentru acelaşi atribut în cadrul

unei singure înregistrări.

OEM poate fi considerat mai apropiat de modelul orientat-obiect decât de cel

relaţional, în care două obiecte distincte chiar dacă au valori identice, au existenţă de sine

stătătoare, reprezentând instanţe diferite.

Scheme de organizare a datelor semistructurate

Flexibilitatea în descrierea informaţiilor adusă de modelarea datelor semistructurate

are şi dezavantaje, şi anume dificultatea formulării unei interogări relevante. S-a încercat

asocierea unor scheme în modelarea datelor semistructurate, în acest sens existând două

abordări:

• scheme flexibile – descriu aprioric datele; schemele flexibile fiind concepute astfel

încât să permită flexibilitate în descrierea datelor; se foloseşte tipul void pentru manipularea

oricărui tip de dată.

• scheme rigide – descriu cu exactitate datele şi sunt folosite pentru analiza datelor;

schema este refăcută ori de câte ori se produce o modificare a informaţiei 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 relaţionale sub forma datelor

semistructurate, limbajul semistructurat trebuie să acopere operaţiile corespunzătoare unui

limbaj relaţional standard, dar în plus trebuie să dispună de facilităţi de reorganizare a datelor,

astfel încât aceeaşi informaţie să poată fi regăsită sub o altă structură;

• Semantică: cererile trebuie optimizate astfel încât să poată ţine cont de semantica

datelor, fiind necesară o semantică precisă pentru transformarea şi optimizarea cererilor;

• Schematizare: limbajul trebuie să poată recunoaşte structurile definite pentru a le

putea manipula;

Pagina 13 din 97


• Compunere: datele obţinute în urma unei interogări pot fi folosite ca date de intrare

în alte interogări, motiv pentru care limbajele trebuie să fie transparente.

Au fost propuse, într-o serie de proiecte de cercetare pe această temă, câteva 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 aplicaţii, dar mai ales asupra aplicaţiilor multimedia şi a celor dezvoltate

pentru mediul Internet.

2.3 MPEG-21 – Suport pentru integrarea datelor în aplicaţii 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 iniţiat

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 condiţii, ca de exemplu diferite tipuri de utilizatori,

reţele 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 defineşte un cadru de lucru deschis pentru multimedia. Forţa MPEG-21 este dată de

următoarea situaţie: există multe resurse mutimedia ce pot fi folosite la construirea unei

infrastructuri pentru distribuirea şi utilizarea conţinutului multimedia, dar nu există nici o

arhitectură pentru descrierea modului în care aceste elemente interacţionează între ele. Scopul

standardului MPEG-21 este să definească un cadru de lucru deschis pentru multimedia care

să permită utilizarea transparentă şi la performanţe bune a resurselor multimedia folosind

reţele şi dispozitive periferice diverse. Se urmăreşte gestiunea conţinutului multimedia,

gestiunea proprietăţii intelectuale şi adaptarea conţinutului 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 conţinut multimedia din punctul de vedere al canalelor de

distribuţie folosite, al modalităţilor de creare a conţinutului, din punct de vedere al modalităţii

de producţie, în vederea personalizării, consumului, prezentării şi comercializării 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 toţi actorii

implicaţi, de la creatorii de conţinut, producători, distribuitori şi furnizorii de servicii.

MPEG-21 standardizează fluxul informaţiilor şi serviciilor multimedia de la crearea

conţinutului până la livrarea către utilizatorii finali. Pentru a realiza acest lucru, conţinutul

trebuie identificat, descris, gestionat şi protejat. Transportul şi livrarea conţinutului poate

avea loc peste diferite reţele, între o varietate de terminale.

Există o serie de arhitecturi apărute ca răspuns la varietatea tipurilor de aplicaţii care

utilizează conţinutul multimedia. Există trei modele principale folosite pentru gestiunea,

descrierea şi regăsirea 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 esenţiale: definirea unei unităţi fundamentale

de distribuţie şi tranzacţionare - elementul digital şi utilizatorii care interacţionează 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 conţin atât

resursele multimedia (conţinutul) cât şi metadatele asociate resurselor sau întregului element

digital. În accepţiunea MPEG-21, utilizatorul este orice entitate care interacţionează cu

mediul MPEG-21 sau care foloseşte un element digital, ca de exemplu un consumator al

datelor multimedia, o organizaţie, sau un alt standard ce foloseşte resursele multimedia. Un

utilizator poate folosi conţinutul în mai multe feluri: prin publicare sau prin livrare şi poate

avea drepturi şi responsabilităţi specifice în funcţie de modalităţile de interacţiune cu alţi

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

distribuţie şi tranzacţionare;

• Declararea elementului digital – defineşte un set de termeni folosiţi 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 conţinutului – oferă interfeţe şi protocoale care permit

crearea, manipularea, căutarea, accesarea, stocarea, livrarea şi reutilizarea conţinutului de-a

lungul canalelor de distribuţie şi consum;

Pagina 15 din 97


• Protejarea şi gestiunea proprietăţii intelectuale – permite gestiunea conţinutului şi

protejarea elementelor digitale într-o serie de reţele şi dispozitive;

• Terminale şi reţele – oferă instrumente ce permit accesul transparent la conţinut prin

intermediul reţelelor şi terminalelor, realizând inclusiv controlul calităţii serviciului;

• Reprezentarea conţinutului – cum sunt reprezentate resursele media;

• Raportarea evenimentelor – conţine metrici şi interfeţe ce permit utilizatorilor să

evalueze performanţele tuturor evenimentelor raportabile din cadrul sistemului.

Structura MPEG-21

În prezent sunt definite 18 părţi 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 protecţia proprietăţii intelectuale (IPMP)

Partea 5: Limbajul de reprezentare a drepturilor (REL)

Partea 6: Dicţionar de drepturi ale datelor (RDD)

Partea 7: Adaptarea elementului digital (DIA),

Partea 8: Software de referinţă

Partea 9: Formate de fişiere pentru stocarea şi regăsirea elementelor digitale ale

MPEG-21

Partea 10: Prelucrarea elementelor digitale

Partea 11: Asocieri persistente

Partea 12: Testare distribuirii resurselor MPEG-21

Partea 13: Codarea secvenţelor video scalabile

Partea 14: Conformanţa

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 fiecărui 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 – defineşte 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 defineşte entităţile necesare declarării

elementului digital.

Un prim set de entităţi este format din elementele de bază folosite pentru declararea

elementelor digitale:

- resursa – este un flux de date identificabil, ca de exemplu un fişier video, imagine,

secvenţă audio sau text.

- componenta – are rolul de a lega una sau mai multe resurse de un set de descriptori

ce conţin informaţii 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

informaţiilor cu alte entităţi ale modelului abstract. Un descriptor asociază informaţii

textuale, secundare entităţii 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 conţine informaţii despre containerul reprezentat.

Pentru rafinarea descrierii resurselor se foloseşte următorul set de entităţi:

- 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 conţin

informaţii 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 adăugarea de informaţii la o entitate a modelului fără a modifica

entitatea.

- alternativa – este o opţiune din mai multe existente; ca de exemplu, alternativa unei

conexiuni la Internet la o lărgime de bandă mare sau alternativa unei conexiuni prin dial-up.

- selecţia – este opţiunea utilizatorului din alternativele disponibile.

Pagina 17 din 97


- condiţia – pe baza selecţiei utilizatorului, pot fi satisfăcute (sau nu) condiţiile

asociate unei entităţi 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 defineşte câteva elemente suplimentare care nu corespund entităţilor modelului

abstract:

- Elementul DIDL ca rădăcină a documentului DIDL,

- Elementul Referinţă - reprezintă o legătură la un alt element al documentului DIDL

şi include conţinutul elementul referenţiat în elementul referit. Referinţele se pot face la

elemente din acelaşi document DIDL sau la elemente din alt document DIDL. O referinţă

internă permite păstrarea unei singure surse pentru un element care apare în documentul

DIDL în mai multe locuri. Referinţa externă permite unui document DIDL să fie împărţit în

mai multe documente DIDL conectate.

- Elementul Declaraţii este folosit pentru definirea elementelor documentului DIDL,

fără a le instanţia. Un element declarat poate fi instanţiat folosind elementul Referinţă.

• Schema XML – specifică sintaxa DIDL şi constrângerile pentru structura

documentelor DIDL.

Relaţia dintre modelul abstract MPEG-21 şi DIDL este prezentată în figura 4.2.

Figura 2 - Relaţia 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:01-

DIDL-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 conţin

câte o secvenţă video, atunci pentru fiecare secvenţă se va folosi câte un container ce conţine

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 conţinutului utilizând MPEG-21

Standardul MPEG-21 facilitează dezvoltarea de soluţii de adaptare a conţinutului

distribuit în funcţie de caracteristicile tehnice ale terminalelor folosite pentru receptarea

datelor, de caracteristicile tehnice ale mediului de comunicaţie folosit sau în funcţie de

preferinţele utilizatorului.

Pentru adaptarea conţinutului multimedia este necesară existenţa unei descrieri a

mediului de lucru, pe lângă descrierea conţinutului propriu-zis. În vederea adaptării

conţinutului 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 adaptării elementelor digitale la aceste caracteristici.

Pagina 20 din 97


DIA defineşte doar instrumentele necesare în procesul de adaptare, nu realizează şi

adaptarea conţinutului.

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 conţinutului

multimedia: posibilităţile de codare/decodare ale terminalului, facilităţile/dispozitivele de

intrare-ieşire conectate, alte caracteristici relevante;

- caracteristicile reţelei: capacitatea reţelei, tipul conexiunii etc.;

- caracteristicile utilizatorului: informaţii despre utilizator, preferinţele utilizatorului,

un istoric al datelor utilizate, preferinţe legate de prezentarea informaţiilor, caracteristici de

accesibilitate şi localizarea acestuia;

- caracteristici ale mediul natural: atributele audiovizuale măsurabile ale mediului

natural, care afectează modalitatea în care conţinutul multimedia este livrat şi/sau consumat

de utilizator: nivelul zgomotului, intensitatea luminii, fusul orar, locaţia.

• Instrumentele de adaptare a resurselor sunt folosite pentru descrierea datelor

structurale, ale fluxurilor de biţi şi a datelor despre adaptabilitatea metadatelor şi se foloseşte

pentru aceasta Binary Syntax Description Language. Descrierea se bazează pe împărţirea

fluxului de biţi în componente logice, ca de exemplu împărţirea unei secvenţe video în cadre.

Fluxul de biţi este apoi transformat de un motor pentru adaptarea resursei elementului digital

într-un descriptor al sintaxei fluxului (BSD), transformare care poate fi făcută sub controlul

XSLT (Extensible Stylesheet Language Transformations). Descriptorul este de dorit să fie

independent de un format media ceea ce permite realizarea adaptării resurselor binare în orice

locaţie.

• Instrumentele pentru adaptarea metadatelor – identifică datele care pot fi utilizate

pentru reducerea complexităţii instanţelor XML de adaptare a metadatelor. Specificaţiile se

referă la filtrarea şi scalarea conţinutului şi la integrarea a două sau mai multe instanţe ale

descrierilor.

Legăturile 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

reţele 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ă răspundem la întrebarea

„Este XML-ul o bază de date?”

Un document XML este o bază de date în sensul cel mai strict al cuvântului şi anume

este o colecţie de date. Se poate considera că aceste documente nu sunt diferite de orice alt tip

de fişiere – în fond, toate fişierele conţin anumite tipuri de date. Având 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ă analizării şi conversiei

textului.

Putem considera şi că XML şi tehnologiile asociate constituie o bază de date în sensul

mai larg al cuvântului – 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.), interfeţe de programare (SAX, DOM, JDOM). Totuşi multe componente ale bazelor de

date convenţionale: stocare eficientă, indecşi, securitate, tranzacţii şi integritatea datelor,

accesul multi-user, triggere, interogări făcute pe mai multe documente ş.a.

Astfel, se pot folosi documente XML ca o bază de date într-un mediu cu cerinţe

modeste şi date puţine, dar această soluţie nu este viabilă într-un mediu pentru producţie în

masă, unde există mulţi utilizatori, cerinţe 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

aplicaţie sau poate fi folosit integral ca în cazul documentelor XHTML şi DocBook. Scopul

utilizării XML este important deoarece toate documentele centrate pe date au anumite

caracteristici comune, la fel se întâmpla şi în cazul informaţiilor centrate pe documente, şi

aceste caracteristici influenţează 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 către aplicaţii şi nu are nici o

importanţă faptul că informaţiile folosite au fost reţinute pentru o perioadă de timp în

documente XML. Exemple de documente centrate pe date sunt ordine de plată, programarea

zborurilor, date ştiinţifice.

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ă, decât în momentul validării documentului.

Informaţiile care există în documentele centrate pe date pot proveni din baza de date

(caz în care se doreşte extragerea lor în fişiere XML), dar şi din afara bazei de date (caz în

care se doreşte stocarea acestora în baza de date). Un exemplu de informaţii care provin dintr-

o bază de date sunt cantităţile de date stocare în bazele de date relaţionale, iar un exemplu de

informaţii care se doresc a fi introduse într-o bază de date pot fi considerate datele ştiinţifice

obţinute de un sistem de măsurători şi convertite în XML.

De exemplu următorul ordin de vânzare 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 lângă documentele centrate pe date cu structura asemănătoare cu documentul din

exemplul anterior, multe documente care conţin şi text adiţional sunt centrate pe date. Spre

exemplu să considerăm o pagină web care conţine informaţii despre o carte. Deşi pagina

conţine în mare parte text, structura acelui text este regulată, şi o parte din acel text este

comună tuturor paginilor care descriu cărţi, fiecare porţiune de text specific având dimensiuni

limitate. Astfel pagina ar putea fi construită dintr-un document XML simplu, centrat pe date

care conţine informaţii despre o singură carte şi este obţinut dintr-o bază de date şi un

stylesheet XSL care adaugă textul care leagă informaţiile din XML. În general orice site web

care construieşte documente HTML dinamic prin completarea unui template cu informaţii

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ă considerăm următorul 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 fişier 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 Informaţii centrate pe documente

Documentele care folosesc viziunea centrată pe documente sunt, de obicei, acele

documente care sunt destinate folosirii de către utilizatori. Exemple de astfel de documente

sunt cărţile, email, anunţuri publicitare şi aproape orice document XHTML scris de mână.

Acestea sunt caracterizate de o structură mai puţin regulată, datele nu sunt atomice (cea mai

mică unitate independentă de informaţie poate fi formată dintr-un element îmbinat cu alte

informaţii 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 următorul document ce conţine 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 diferenţa 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 conţin şi porţiuni 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 stocării informaţiilor din aceste documente. De

obicei datele sunt stocate într-o bază de date tradiţională cum sunt cele relaţionale sau

orientate-obiect. Documentele sunt stocate într-o bază de date nativă XML (o bază de date

destinată stocării XML) sau un sistem de gestionare a conţinuturilor (content management

system) – o aplicaţie destinată administrării documentelor şi construită peste o bază de date

nativă XML.

Totuşi 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 tradiţionale

atunci când nu sunt necesare foarte multe caracteristici specifice XML. În plus, graniţele

dintre bazele de date tradiţionale şi cele native XML devin din ce în ce mai neclare, deoarece

la bazele de date tradiţionale se adaugă facilitaţi native XML şi bazele de date native XML

suportă stocarea fragmentelor de documente în baze de date, de obicei relaţionale, 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 interogării SELECT *

FROM Tabelă).

În al doilea caz, structura documentului şi structura necesară pentru mapare trebuie să

fie identice. Deoarece acest lucru se întâmplă 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 întâi adus la structura necesară mapării şi apoi datele sunt

transferate. Similar după transferarea datelor din baza de date, documentul obţinut este adus

la structura folosită de către aplicaţie.

3.3.1 Maparea schemelor documentelor pe schemele bazelor de date

Mapările î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

entităţile şi informaţia codificată) şi unele structuri logice (cum ar fi instrucţiunile de

procesare, comentariile). Aceste omiteri nu au o influenţă prea mare, deoarece baza de date şi

aplicaţia sunt interesate numai de datele din documentul XML.

Pagina 28 din 97

O consecinţă a acestor transformări – adică stocarea datelor dintr-un document într-o

bază de date şi apoi reconstruirea documentului din datele existente în baza de date – este

obţinerea unui document diferit. Dacă acest lucru este acceptabil depinde de cerinţele fiecărui

proiect şi poate influenţa 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-relaţională.

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 relaţională. Aceasta modelează un document

XML ca o singură tabelă sau ca un set de tabele. Structura documentului XML este arătată în

exemplul următor.

<bazadedate>

<tabela>

<linie>

<coloana1>...</coloana1>

<coloana2>...</coloana2>

</linie>

<linie>

</linie>

</tabela>

<tabela>

</tabela>

</bazadedate>

În funcţie de software datele din coloane pot fi stocate ca elemente descendente sau ca

atribute. În plus, produsele care folosesc mapări bazate pe tabele de multe ori includ metadate

fie la începutul documentului fie ca atribute asociate fiecărui element din tabelă sau coloană.

Pagina 29 din 97


Maparea bazată pe tabele este utilizată pentru serializarea datelor relaţionale, ca în

cazul transferării datelor între două baze de date relaţionale. Dezavantajul acestei mapări este

că nu poate fi folosită pentru un document XML care nu respectă formatul din exemplu.

3.3.1.2 Maparea obiectual-relaţională

Maparea obiectual-relaţională este folosită de către toate bazele de date relaţionale

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 proprietăţi scalare. Modelul este apoi mapat

pe bazele de date relaţionale folosind tehnici de mapare obiectual-relaţionale tradiţionale.

Astfel clasele sunt mapate pe tabele, proprietăţile scalare pe coloane, şi proprietăţile cu valori

obiect sunt mapate pe perechi de chei primare/chei străine.

Denumirea de „mapare obiectual-relaţională” este de fapt un termen impropriu,

deoarece arborele de obiecte poate fi mapat direct pe baze de date orientate obiect şi

ierarhizate. Totuşi este folosit pentru că majoritatea produselor care folosesc această mapare

folosesc baze de date relaţionale şi acest termen este bine cunoscut.

Este importantă înţelegerea faptului că modelul obiectual din această mapare nu este

modelul DOM (Document Object Model). DOM-ul modelează chiar documentul şi este

acelaşi 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 vânzări din secţiunea 3.2.1 ar putea fi modelat

ca un arbore de obiecte format din 4 clase – OrdineVânzări, Client, Item, şi Parte – aşa cum

se arată în diagrama de mai jos:

OrdineVânzări

/ | \

Client Item Item

| |

Parte Parte

Dacă ar trebui să construim un arbore DOM din acelaşi document, acesta ar fi compus

din obiecte cum ar fi Element, Atribut şi Text.

Pagina 30 din 97


Element ------ Atribut

(OrdineVânzări) (Număr OV)

_________/ / \ \_____

/ / \ \

Element Text Element Element

(Client) (Data ordinului) (Item) (Item)

| | |

etc. etc. etc.

Instanţierea obiectelor din model depinde de produsul folosit. Unele produse dau

posibilitatea generării claselor în model şi apoi folosirea obiectelor din aceste clase în

aplicaţii. Î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-relaţională 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 proprietăţi.

Toate produsele dau posibilitatea desemnării unui element rădăcină care nu este

mapat pe modelul obiect sau pe baza de date. Acest element este folositor atunci când se

doreşte stocarea obiectelor cu mai multe nivele în acelaşi document XML.

Majoritatea produselor oferă posibilitatea specificării dacă proprietăţile 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 aceloraşi nume atât în documentul

XML cât şi în baza de date.

Majoritatea produselor permit specificarea ordinii în care elementele descendente apar

în părintele lor, dar care face imposibilă construirea mai multor modele pentru conţinut. Din

fericire, modelele pentru conţinut 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 conţin sau sunt folosite cu XSLT. Acesta dă posibilitatea utilizatorilor

să transforme documente la structura modelului înaintea transferării datelor în baza de date, şi

invers. Deoarece procesarea XSLT poate fi scumpă, unele produse conţin un număr limitat de

transformări în mapările lor.

Soluţia 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ă situaţie se va schimba atunci

când XQuery şi SQL/XML vor fi finalizate, acestea aflându-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 facilitaţi vor fi adăugate).

3.3.2.1 Limbaje de interogare bazate pe şabloane

Cele mai des întâlnite limbaje de interogare care returnează XML din baze de date

relaţionale 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 către software-ul care transfera date. De exemplu, următorul template

foloseşte 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 procesării 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. Deşi 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 ieşire, incluzând ca

parametrii şi frazele SELECT .

Construcţii cum ar fi cicluri FOR şi instrucţiuni IF.

Definiri de variabile şi funcţii

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 relaţionale în documente XML. Deşi unele produse care

folosesc limbaje de interogare bazate pe şabloane pot transfera date din documente XML în

baze de date relaţionale, ele nu folosesc şabloanele numai pentru acest lucru. În schimb ele

folosesc o mapare bazată pe tabele, aşa 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ă câteva limbaje particulare de acest tip şi cel mai

simplu dintre acestea foloseşte fraze SQL imbricate (nested), care sunt transformate direct în

XML imbricat (nested) conform cu maparea relaţional-obiectuală. Un alt limbaj de acest tip

Pagina 33 din 97

foloseşte obiecte SQL 3, de asemenea transformate direct în XML. Un alt limbaj foloseşte

fraze OUTER UNION şi marcaje speciale pentru a determina cum sunt transformate

rezultatele în XML.

În plus faţa de limbajele particulare, un număr de companii s-au reunit în 2000 pentru

a standardiza extensiile XML la SQL. Rezultatele lor fac parte acum din specificaţia ISO

SQL şi este cunoscută ca SQL/XML. SQL/XML introduce un tip de date XML şi adaugă un

număr de funcţii la SQL, aşa că este posibilă construirea elementelor XML şi a atributelor din

date relaţionale.

De exemplu, următoarea 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

construieşte un set de rezultate cu două coloane. Prima coloană conţine numărul

ordinului de vânzări şi a doua coloană conţine un document XML. Există un document XML

pe fiecare linie, construit din datele din linia corespunzătoare în tabelul de comenzi. De

exemplu documentul pentru linia pentru ordinul de vânzare 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 relaţionale, limbajele de interogare XML pot fi folosite

pentru orice document XML. Pentru a folosi acest tip de limbaje cu baze de date relaţionale,

datele din baza de date trebuie să fie modelate ca XML.

Cu XQuery, poate fi folosită fie maparea bazată pe tabele fie maparea obiectual

relaţională. 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-relaţională atunci ierarhiile de tabele sunt tratate ca un singur

document şi sunt specificate uniri în mapare. Se preconizează că mapările bazate pe tabele

Pagina 34 din 97


vor fi utilizate în majoritatea implementărilor, în detrimentul bazelor de date relaţionale,

deoarece se consideră că sunt mai uşor de implementat şi mai bine cunoscute de utilizatorii

SQL.

Cu XPath, o mapare obiectual-relaţională trebuie să fie folosită pentru a executa

interogări peste mai multe tabele. Aceasta se întâmplă 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 când datele sunt

semistructurate, adică acestea au o structură regulată, dar acea structură variază destul încât

maparea ei la o bază de date relaţională duce fie la un număr mare de coloane cu valori nule

(care ocupă spaţiu inutil), fie la un număr mare de tabele (care este ineficient). Deşi 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 funcţie de cum sunt stocate datele în baza de date nativă XML, ar

putea fi posibilă recuperarea datelor mult mai repede decât într-o bază de date relaţională.

Acest lucru se poate întâmpla deoarece unele strategii de stocare folosite de către bazele de

date native XML reţin fizic documente întregi sau folosesc pointeri fizici (şi nu logici) între

părţile documentelor. Acestea permit ca documentele să fie recuperate fie fără uniri fie

folosind uniri fizice, ambele fiind mai rapide decât unirile logice folosite în bazele de date

relaţionale.

De exemplu se consideră ordinul de vânzare prezentat mai sus. Într-o bază de date

relaţională, acesta ar fi stocat în patru tabele – OrdineVânzări, Itemi, Clienţi, ş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ă locaţie pe disc, aşa că recuperarea

lui sau a unui fragment din el necesită o singură căutare indexată şi o singură citire pentru

recuperarea datelor. O bază de date relaţională necesită patru căutări indexate şi cel puţin

patru citiri pentru a recupera datele.

Dezavantajul în acest caz este acela că viteza de recuperare este mare numai atunci

când datele din comandă sunt stocate pe disc. Dacă se doreşte recuperarea altor date, cum ar

fi o listă a clienţilor şi ordinele de vânzare ale lor, atunci performanta va fi mai slabă decât

într-o bază de date relaţională. Astfel, stocarea datelor într-o bază de date nativă XML se

Pagina 35 din 97


recomandă din motive de performanţa atunci când predomină o singură vedere asupra

datelor.

Al treilea motiv pentru stocarea datelor într-o bază de date nativă XML este

exploatarea capacităţilor specifice XML, cum ar fi executarea interogărilor XML. Deoarece

relativ puţine aplicaţii centrate pe date au nevoie de acestea şi bazele de date relaţionale

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. (Puţine baze de date suportă legarea

elementelor sau atributelor de variabilele dintr-o aplicaţie.) Dacă o aplicaţie 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 aplicaţiile locale care folosesc o bază de date

nativă XML în locul unei baze de date relaţionale.

3.3.4 Tipuri de date, valori nule, seturi de caractere

Această secţiune se ocupă de anumite probleme legate de stocarea datelor din

documente XML în baze de date tradiţionale. Problemele legate de tipurile de date şi datele

binare apar şi în cazul stocării 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 când 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 excepţia entităţilor 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 către software a tipurilor de date din

schema bazei de date, deoarece aceasta este accesibilă la rulare. (Schema XML nu este

neapărat accesibilă la rulare sau s-ar putea sa nu existe.) În a doua metodă utilizatorul

specifică tipul de date. Acesta poate fi scris de către utilizator sau generat automat dintr-o

schemă a unei baze de date sau dintr-o schemă XML. Atunci când 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 când se transferă date din XML, la fel şi formatele care se pot crea atunci când se

transferă date către XML. În cele mai multe cazuri, numărul 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 internaţionale 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 reprezentând

cifre hexazecimale [0-9,a-f,A-F]), şi entităţi 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 entităţi

neanalizate şi constă în faptul că majoritatea produselor nu stochează notaţii şi declaraţii de

entităţi. Astfel, notaţia asociată cu o anumită entitate va fi pierdută atunci când 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 colecţie de date de la o staţie meteo. Dacă termometrul nu

funcţionează, î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

opţionale. Dacă valoarea unui tip sau atribut opţional este nulă acesta nu este inclus în

document. În cazul bazelor de date, atributele care conţin ş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 opţionale sunt mapate ca şi coloane vide. Dacă nu se procedează în acest mod s-ar

putea inserarea o eroare (atunci când se transferă date în baza de date), sau la un document

invalid (atunci când se transferă date din baza de date).

Pagina 37 din 97

3.3.4.4 Seturi de caractere

Un document XML poate conţine orice caracter Unicode cu excepţia unor caractere

de control. Din nefericire, multe baze de date oferă suport limitat sau nu oferă suport deloc

pentru Unicode şi necesită o configuraţie specială pentru caracterele non-ASCII.

3.3.4.5 Instrucţiuni de procesare şi comentarii

Instrucţiunile 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. Totuşi ele pot apărea

aproape oriunde într-un document XML şi de aceea nu se integrează uşor în mapările bazate

pe tabele şi cele obiectual relaţionale. O soluţie total ineficientă într-o bază de date relaţională

este adăugarea unor tabele pentru instrucţiuni de procesare şi comentarii, adăugarea de chei

străine la aceste tabele pentru toate celelalte tabele, şi verificarea acestor tabele de fiecare

data când se procesează o altă tabelă. Astfel majoritatea soft-urilor de transfer de date le

înlătură.

3.3.4.6 Stocarea marcajelor

În anumite situaţii este indicată stocarea elementelor cu conţinut mixt în baza de date

fără a se efectua analiza completă. Când este realizat acest lucru, marcajul este realizat cu

caractere de marcare. Totuşi apare o problemă la stocarea caracterelor de marcare care nu

sunt folosite pentru marcaj. În fişierul XML, acestea sunt stocate folosind entitatile lt, gt,

amp, quot, şi apos. Acest lucru poate fi făcut şi în baza de date. De exemplu următoarea

descriere:

<descriere>

Exemplu confuz: <foo/>

</descriere>

poate fi stocată în baza de date ca:


Totuşi apare o problemă, limbajele de interogare non-XML, cum ar fi SQL, nu caută

în coloane marcaje sau folosirea de entităţi şi le interpretează ca atare. Astfel, dacă se caută

şirul „<foo/>” cu SQL, de fapt trebuie căutat şirul „<foo/>”.

Pagina 38 din 97

Pe de altă parte, dacă referinţele la entităţi sunt extinse, software-ul de transfer de date

nu poate distinge între marcaj şi folosirea entităţilor. De exemplu, dacă descrierea de mai sus

este stocată în baza de date în forma următoare, soft-ul nu poate spune dacă ,, şi

<foo/> sunt marcaje sau text:


Soluţia 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 când aplicaţii non-XML lucrează cu XML.

3.3.5 Generarea schemelor XML din scheme relaţionale ş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 reţinut faptul că aceasta este o operaţie design-

time. Motivul pentru acest lucru este că majoritatea aplicaţiilor centrate pe date, şi cele mai

multe aplicaţii 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 rulării. În plus procedurile

pentru generarea schemelor nu sunt perfecte. Aplicaţiile care trebuie să reţină 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 uşoară cale de a genera scheme relaţionale din scheme XML şi invers este de

a codifica o cale prin maparea obiectual relaţională, care are un număr de trăsături opţionale.

O schemă relaţională 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 conţinut mixt, trebuie creată o tabelă separată în care

se va stoca PCDATA, legată de tabela părinte prin intermediul cheii primare din tabela

părinte.

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 conţine informaţia despre tipurile de date, atunci trebuie setate tipurile de

date ale coloanelor la tipul corespunzător. 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 opţional 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 părinte prin intermediul cheii primare din tabela părinte.

Pentru fiecare element descendent complex, trebuie legată tabela tipului elementului

părinte de tabela tipului elementului descendent prin intermediul cheii primare din tabela

părinte.

O schema XML se generează dintr-o schemă relaţională 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

conţine 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 străina, se adaugă un element descendent la model şi se

procesează tabela cu cheie străină recursiv.

Există câteva dezavantaje la aceste procedee. Multe dintre acestea se pot corecta uşor

de către programator, cum ar fi coliziuni de nume şi specificarea lungimilor şi tipurilor de

date ale coloanelor. DTD-urile nu conţin informaţii despre tipurile de date, deci nu este

posibilă cunoaşterea tipurilor de date care ar trebui folosite în baza de date. Tipurile de date şi

lungimile pot fi prevăzute 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 decât cel mai eficient model pentru stocarea

datelor în baza de date. De exemplu, se consideră următorul 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 relaţionale dintr-o schemă XML ar crea două

tabele: una pentru clienţi şi una pentru adrese. Totuşi în majoritatea cazurilor ar fi mai bine să

se reţină adresa în tabela de clienţi, ş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 rând, ele oferă structuri adiţionale

ceea ce face documentul mai uşor de înţeles. În al doilea rând, 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 când sunt mapate la baza de date dacă acestea se găsesc sub forma extra-structurilor.

Din această cauză, ele ar trebui eliminate din schema XML înaintea generării schemei

relaţionale. Din moment ce este puţin probabil că modificarea schemei XML ar trebui să fie

permanentă, acest lucru duce la o neconcordanţă între documentul existent şi documentele

presupuse de către 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 transferării 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 relaţionale ş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 fişiere sau ca un BLOB într-o bază de date relaţională şi acceptarea

funcţionalităţilor XML limitate, sau stocarea lor într-o bază de date nativă XML.

3.4.1 Stocarea documentelor în sistemul de fişiere

Dacă se lucrează cu un set simplu de documente, cum ar fi un set mic de

documentaţie, cea mai uşoara cale de stocare este în sistemul de fişiere. Se pot folosi

instrumente cum ar fi „grep” pentru interogarea lor, şi „sed” pentru modificarea lor. Căutările

complete de text în documentele XML sunt inexacte, pentru că ele nu pot distinge marcajul

de text şi nu pot înţelege folosirea entităţilor. Totuşi, într-un sistem mic, aceste inexactităţi ar

putea fi acceptabile. Dacă se doreşte un simplu control al tranzacţiilor, documentele pot fi

întreţinute 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 opţiune puţin mai sofisticată este stocarea documentelor ca BLOB-uri într-o bază

de date relaţională. Această modalitate oferă un număr de avantaje a bazelor de date:

controlul tranzacţiilor, securitate, acces multiuser. În plus, multe baze de date au instrumente

pentru căutări de text şi pot face căutări complete de text, căutări aproximative, căutări

sinonime şi căutări fuzzy. Unele dintre aceste instrumente sunt construite pentru a recunoaşte

XML, ceea ce va elimina problemele care apar la căutările documentelor XML ca simplu

text.

Atunci când se stochează documente XML ca BLOB-uri, se pot implementa uşor

indexări 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 conţine o cheie primară şi o coloană BLOB în care este reţinut

documentul. Tabela index conţine o coloană în care se găseşte valoarea ce va fi indexată şi o

cheie străină care duce la cheia primară a tabelei document.

Atunci când documentul este stocat în baza de date, el este căutat pentru toate

instanţele elementului sau atributului care este indexat. Fiecare instanţa este stocată în tabela

index, împreuna cu cheia primara a documentului. Coloana de valori este apoi indexată, şi

permite unei aplicaţii să efectueze o căutare rapidă a unei anumite valori a unui element sau

atribut şi să recupereze documentul corespunzător.

De exemplu, se consideră un set de documente cu următorul DTD şi se doreşte

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 următoarele tabele:

Autori Brosuri

---------------------- ---------

Autor VARCHAR(50) BrosurID INTEGER

BrosuraID INTEGER Brosura LONGVARCHAR

Când se inserează o broşură în baza de date, aplicaţia inserează broşura în tabela

Broşuri, apoi caută elementele <Autor>, reţinând valorile acestora şi ID-ul broşurii din tabela

Autori. Aplicaţia poate recupera broşurile în funcţie de autor cu o simplă fraza SELECT. De

Pagina 42 din 97


exemplu, pentru a recupera toate broşurile scrise de autorul „Chen”, aplicaţia execută

următoarea interogare:

SELECT Brosura

FROM Brosuri

WHERE BrosuraID IN (SELECT BrosuraID FROM Autori WHERE Autor= 'Chen')

O tabelă de indecşi mai sofisticată ar conţine 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 aplicaţii

generice SAX pentru a popula o astfel de tabelă ar fi relativ uşoară.

3.4.3 Baze de date native XML

Dacă sunt necesare mai multe caracteristici decât 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ă tranzacţii, 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 relaţional.

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 adresării unor întrebări de forma: „Extrage toate documente în care al

treilea paragraf de la începutul secţiunii conţine un cuvânt îngroşat”, sau oferă posibilitatea

limitării căutărilor complete de text la anumite porţiuni din document. Asemenea interogări

sunt dificil de scris într-un limbaj ca SQL. Un alt motiv este acela că bazele de date native

XML păstrează ordinea documentelor, instrucţiunile de procesare, şi comentarii, şi adesea

păstrează secţiuni CDATA, folosirea entităţilor, şi altele, pe când 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 făcută cu baze de date relaţionale federate, dar acestea necesitau ca toate

resursele de date să fie mapate la modelul relaţional. Această modalitate nu funcţionează

pentru mai multe tipuri de date şi modelul de date XML oferă o flexibilitate mai mare. Bazele

de date native XML tratează modificările schemelor mai uşor decât bazele de date relaţionale

şi pot trata şi date care nu au schemă. Ambele consideraţii 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, aşa cum se găsesc în finanţe, în biologie, date care se schimbă atât de des

încât nu este posibilă definirea unor scheme definitive. Datorită faptului că bazele de date

native XML nu necesită scheme, ca bazele de date relaţionale, ele pot să trateze acest tip de

date, deşi aplicaţiile adesea necesită procesarea acestor date de către oameni.

Ultima utilizare majora a bazelor de date native XML este tratarea evoluţiei

schemelor. Chiar dacă bazele de date native XML nu oferă soluţii complete, ele oferă o

flexibilitate mai mare decât bazele de date relaţionale. De exemplu, bazele de date native

XML nu necesită ca datele existente să fie mutate într-o altă schemă, ele pot trata modificări

ale schemelor pentru care nu există nicio cale a migraţiei, şi pot stoca date chiar dacă acestea

aparţin unei versiuni necunoscute a unei scheme.

Alte utilizări ale bazelor de date native XML includ punerea la dispoziţie de cache

pentru date şi metadate pentru tranzacţii 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 apărut 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 către companiile care dezvoltau produse

similare. Dezavantajul acestui termen este că fiind un termen de marketing, nu a avut

niciodată o definiţie formală tehnică.

O definiţie posibila (dezvoltată de membrii XML:DB) este aceea că o bază de date

nativă XML are următoarele caracteristici:

Defineşte 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 conţinute de DOM şi

evenimentele din SAX 1.0.

Are ca unitate fundamentală de stocare logică un document XML, aşa cum o bază de

date relaţională 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 relaţională, ierarhică, sau orientată pe obiecte, sau se poate

folosi un format de stocare particular cum ar fi fişierele comprimate indexate.

Pagina 44 din 97


Prima parte a acestei definiţii este similară cu definiţiile 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 informaţii decât conţine modelul

folosit de baza de date. De exemplu, ar putea suporta interogări bazate pe modelul Xpath, dar

să stocheze documente ca text. În acest caz, secţiunile CDATA şi folosirea entităţilor sunt

stocate în baza de date dar nu sunt incluse în model.

A doua parte a definiţiei spune că unitatea de bază de stocare într-o bază de date

nativă XML este un document XML. Deşi poate părea 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 potriveşte un

anumit element de date, şi este echivalent cu o linie într-o bază de date relaţională. Existenţa

acestei unităţi de bază nu împiedică recuperarea unor unităţi mai mici de date, cum ar fi

fragmente de documente sau elemente individuale, şi nu exclude nici posibilitatea combinării

fragmentelor dintr-un document cu fragmente din alt document. În termeni relaţionali, acest

lucru este echivalent cu faptul că existenţa liniilor nu împiedica recuperarea individuală a

valorilor din coloane sau crearea unor linii noi din altele existente deja.

A treia parte a definiţiei spune că formatul de stocare nu este important. Acest lucru

este adevărat, şi este analog cu faptul că formatul fizic de stocare folosit de o bază de date

relaţională nu are legătură cu faptul ca baza de date este relaţională.

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 fişier într-un sistem de fişiere, un BLOB într-o bază de date relaţională, sau un format de

text particular. Nu are nicio importanţă faptul că o bază de date relaţională care a adăugat

procesarea ce recunoaşte XML a coloanelor CLOB (Character Large Object) este, de fapt, o

bază de date nativă XML având în vedere aceste abilităţi.

Toate bazele de date native XML bazate pe text au în comun indecşii, care oferă

posibilitatea motorului de interogare să sară uşor î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 întâmpla deoarece baza de date poate executa o singură căutare

indexată, poate poziţiona capul de citire o singură dată, şi, presupunând 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 relaţionale şi unele baze de date native XML bazate pe

modele, necesită căutări 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, amândouă având performanţe mai bune decât bazele de date relaţionale la

recuperarea şi returnarea datelor în funcţie de o ierarhie predefinită. La fel ca bazele de date

ierarhice, bazele de date native XML bazate pe text ar putea întâmpina dificultăţi la

recuperarea şi returnarea datelor în orice altă formă, cum ar fi inversarea ierarhiei sau a unor

porţiuni ale ei. Acest lucru nu a fost dovedit încă, dar predominanţa bazelor de date

relaţionale, care folosesc pointeri logici ce permit ca toate interogările de aceeaşi

complexitate să fie executate cu aceeaşi viteză, pare să indice că aşa se va întâmpla.

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 reţinerii acestui model depinde de baza

de date. Unele baze de date stochează modelul într-o bază de date relaţională sau orientată

obiect. De exemplu, stocarea DOM-ului într-o bază de date relaţională ar putea duce la

obţinerea 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 relaţională este cea descrisa de Mark Birbeck la XML-L în decembrie 1998.

Sistemul foloseşte cinci tabele – definirea atributelor, asocierile dintre elemente/atribute,

definirea conţinutului 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

performanţe similare cu acele baze de date la recuperarea documentelor pentru că ele se

bazează pe acele sisteme pentru a recupera datele. Totuşi, designul bazei de date, în special

pentru bazele de date native XML construite pe baze de date relaţionale poate varia destul de

mult. De exemplu, o bază de date care foloseşte o mapare obiectual-relaţională directă a

Pagina 46 din 97


DOM-ului ar putea duce la un sistem care necesită executarea frazelor SELECT separat

pentru a recupera descendenţii fiecărui 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 relaţională 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ă performanţe similare cu cele native XML bazate pe text la

recuperarea datelor în ordinea în care au fost stocate. Acest lucru se întâmplă 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 ieşire. Sistemele bazate pe text sunt mai rapide la returnarea documentelor

ca text, pe când sistemele bazate pe modele sunt mai rapide la returnarea documentelor ca

arbori DOM, presupunând că modelul lor se mapează uşor la DOM.)

Ca şi bazele de date native XML bazate pe text, e probabil că şi cele bazate pe modele

să întâmpine probleme de performanţă la recuperarea şi returnarea datelor într-un formular,

altul decât cel în care sunt stocate, cum ar fi inversarea ierarhiei sau a unor porţiuni a ei. Nu

se ştie dacă aceste baze de date vor fi mai rapide sau nu decât cele bazate pe text.

3.4.3.3 Caracteristici ale bazelor de date native XML

În această secţiune sunt prezentate un număr de caracteristici ale bazelor de date

native XML.

Colecţii de documente

Multe baze de date native XML suportă noţiunea de colecţie. Acestea au un rol

similar cu cel al tabelelor în bazele de date relaţionale sau cu cel al directoarelor într-un

sistem de fişiere. De exemplu, dacă se foloseşte o bază de date nativă XML pentru stocarea

unor ordine de vânzare, ar trebui definită o colecţie de ordine de vânzare astfel încât

interogările cu privire la ordinele de vânzare să poată fi limitate la documentele din acea

colecţie.

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 colecţii, o colecţie pentru

fiecare produs, şi în acea colecţie, câte o colecţie 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 interogări asupra mai multor

Pagina 47 din 97


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

asemenea.

În viitor, majoritatea bazelor de date native XML vor suporta XQuery din W3C.

Updatări ş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 până la modificarea

arborelui DOM, până la limbaje care specifică cum să se modifice fragmente ale unui

document. Majoritatea acestor metode sunt particulare. Totuşi, au apărut două limbaje

întrucâtva standardizate pentru actualizarea documentelor XML:

XUpdate, de la XML:DB Initiative, este un limbaj bazat pe XML. Foloseşte 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. Variaţii 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 abilităţile de actualizare să rămână

fragmentate până când va fi adăugată formal o sintaxă de actualizare la XQuery.

Tranzacţii, blocări, şi concurenţă

Aproape toate bazele de date native XML suportă tranzacţii (şi probabil suportă şi

întoarceri). Totuşi, blocarea se face adesea la nivelul întregului document, şi nu la nivelul

unui nod individual, de aceea concurenţa multi-user este relativ redusă. Dacă aceasta este o

problemă depinde de aplicaţie şi ceea ce constituie un „document”. De exemplu:

Un document este un capitol al unui ghid al utilizatorului şi scriitorii editează

capitolele. Este puţin probabil ca blocarea la nivel de document să cauzeze probleme de

concurenţă, deoarece este improbabil ca doi scriitori să actualizeze acelaşi capitol în acelaşi

moment.

Un document stochează toate datele despre toate vânzările şi vânzătorii adaugă

informaţii despre noile vânzări. Este probabil ca blocarea la nivel de document să determine

probleme de concurenţă, deoarece şansele ca doi vânzători să actualizeze informaţii în acelaşi

timp este destul de mare. Din fericire, acest lucru poate fi rezolvat cel puţin parţial prin

crearea unui document de vânzare pentru fiecare client.

Pagina 48 din 97


Un document conţine datele folosite într-un flux, cum ar fi un contract financiar.

Fiecare pas al fluxului citeşte date dintr-un computer şi adaugă datele proprii. De exemplu, un

pas ar putea face o verificare de credit şi ar adăuga un credit la document. Un alt pas ar putea

căuta balanţe în aşteptare în alte contracte ale aceluiaşi client şi ar putea adăuga totalul

balanţelor. Dacă blocarea la nivel de nod este folosită, unii dintre aceşti paşi ar putea fi

executaţi în paralel. Dacă este folosită blocarea la nivel de document, aceşti paşi ar trebui

executaţi secvenţial pentru a evita conflicte de scriere. Acest lucru ar putea aduce întârzieri

inacceptabile în aplicaţii mari.

Problema blocării la nivel de nod este implementarea acesteia. Blocarea unui nod

necesită de obicei blocarea părintelui său, ceea ce necesită blocarea părintelui acestuia, şi aşa

până la rădăcină, blocând efectiv întregul document. Pentru a vedea de ce acest lucru este

adevărat, se consideră o tranzacţie care citeşte un nod frunză. Dacă tranzacţia nu are blocări

pe strămoşii nodului frunză, o altă tranzacţie poate şterge un nod strămoş al frunzei, astfel

ştergând şi nodul frunză. Totuşi, o altă tranzacţie ar trebui să poată actualiza acele părţi ale

documentului care nu sunt pe calea directă de la rădăcină la nodul frunză.

O soluţie parţială a acestei probleme este propusă de Stijn Dekeyser În timp ce

problema blocării strămoşilor unui nod ţintă nu a fost total ocolită, aceste blocări au fost

făcute mai flexibile prin adnotarea lor cu definirea prin interogare a căii de la nodul blocat

până la nodul ţintă. Acest lucru permite altor tranzacţii să determine dacă sunt în conflict cu

alte tranzacţii. Deoarece evaluarea interogărilor pentru a obţine blocări este foarte

costisitoare, schema actuală este întrucâtva mai limitată decât a fost descrisă aici, dar acesta

este principiul de funcţionare.

În viitor, majoritatea bazelor de date native XML vor oferi probabil posibilitatea

blocării la nivel de nod.

Interfeţe de programare a aplicaţiilor (API-uri)

Majoritatea bazelor de date native XML oferă API-uri programatice. Acestea sunt de

obicei sub forma unei interfeţe asemănătoare ODBC, cu metode pentru legarea la baza de

date, explorarea metadatelor, executarea interogărilor, ş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ă interogările pot returna documente multiple,

atunci metodele pentru parcurgerea rezultatelor sunt de asemenea disponibile. Deşi

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

foloseşte XPath ca limbajul său 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 foloseşte XQuery ca

limbaj de interogare. Este dezvoltat de către Java Community Process (JCP) de la Sun.

Deoarece această iniţiativa este condusă de IBM şi Oracle este probabilă răspândirea ei la

scară largă.

Majoritatea bazelor de date native XML oferă de asemenea posibilitatea executării

interogărilor ş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 acelaşi document. Acest

lucru este important pentru aplicaţiile centrate pe documente, pentru care secţiunile CDATA,

folosirea entităţilor, comentariile şi procesarea instrucţiunilor sunt o parte integrantă a

documentului. De asemenea este foarte important pentru multe aplicaţii medicale şi legale,

care sunt obligate prin lege sa păstreze copii fidele ale documentelor.

Round-tripping-ul este mai puţin important pentru aplicaţiile 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. Aceleaşi operaţii pot fi aplicate şi unor ordonări similare (ordinea elementelor şi a

PCDATA în părintele lor) într-un număr limitat de cazuri care sunt importante pentru

aplicaţiile centrate pe date. Totuşi deoarece nu pot face aceste operaţii în toate cazurile, şi nici

asupra instrucţiunilor de procesare, comentariilor, şi structurilor fizice (referinţele către

entităţi, secţiuni CDATA), nu sunt potrivite pentru aplicaţii 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. Cât 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 decât

XML-ul canonic.

Pagina 50 din 97


Din moment ce nivelul de round-tripping depinde de fiecare aplicaţie, ş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 relaţională

cu ODBC, OLE DB, sau JDBC şi sunt modelate folosind maparea bazată pe tabele sau

maparea relaţional-obiectuală. Daca aceste date sunt “live” – adică dacă actualizările

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ţă.

Indecşi

Toate bazele de date native XML suportă indecşi ca o modalitate de a mări viteza de

interogare. Exista trei tipuri de indecşi. Indecşii valoare indexează text şi valori ale atributelor

şi sunt folosiţi pentru a rezolva interogări de forma: „Găseşte toate elementele sau atributele

ale căror valori sunt ‘Santa Cruz’.” Indecşii structurali indexează locaţia elementelor şi

atributelor şi sunt folosiţi pentru a rezolva interogări de forma: „Găseşte toate elementele

adresă.” Indecşii valoare şi structurali sunt combinaţi pentru a rezolva interogări de forma:

„Găseşte toate elementele oraşe ale căror valori sunt ‘Santa Cruz’.” Indecşii full-text

indexează semnele individuale din text şi valorile atributelor şi sunt folosiţi pentru a rezolva

interogări de forma: „Găseşte toate documentele care conţin cuvintele ’Santa Cruz’.” sau în

conjuncţie cu indecşii structurali :”Găseşte toate documentele care conţin cuvintele ‘Santa

Cruz’ într-un element adresă.”

Majoritatea bazelor de date native XML suportă atât indecşi valoare cât şi indecşi

structurali. Unele baze de date native XML suportă indecşi full-text.

Stocarea entităţilor externe

O problemă dificilă care apare la stocarea documentelor XML este tratarea entităţilor

externe. Adică, ar trebui extinse şi valorile lor stocate împreuna cu restul documentului, sau

ar trebui ca referinţele la entităţi să fie lăsate la locul lor? Această întrebare nu are răspuns

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 greşeală extinderea referinţei 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 colecţii de date despre vreme mai vechi, ar fi o greşeală să nu se extindă referinţa,

deoarece documentul ar recupera întotdeauna datele curente şi nu le-ar mai reţine pe cele

vechi.

Ca un alt exemplu, se consideră un manual al unui produs care nu conţine altceva

decât referinţe la entităţi externe care trimit la capitolele manualului. Daca unele dintre aceste

capitole ar fi folosite în alte documente, ca manualele pentru diferite modele ale aceluiaşi

produs, ar fi o greşeală extinderea acestor referinţe, pentru ca ar duce la copii multiple ale

aceloraşi capitole.

3.4.3.4 Normalizare, integritate referenţială şi scalabilitate

Pentru mulţi, în special pentru cei ce poseda cunoştinţe despre baze de date

relaţionale, bazele de date native XML ridică un număr de probleme controversate, în special

cu privire la problemele de stocare a datelor (spre deosebire de documente). Unele dintre

aceste probleme sunt dezbătute în secţiunile următoare.

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 câteva avantaje

clare, cum ar fi reducerea spaţiului necesar pe disc şi eliminarea posibilităţii apariţiei

inconsistenţelor, care se pot găsi atunci când un set de date este stocat în mai multe locuri.

Aceasta este una din pietrele de temelie a tehnologiei relaţionale şi este un punct aprins în

discuţiile despre stocarea datelor în baze de date native XML.

Normalizarea nu este o problemă pentru documente centrate pe documente. De

exemplu, se consideră o colecţie de documente ce descrie produsele unei companii. În multe

asemenea colecţii, există puţine date comune tuturor documentelor – notificări de copyright,

adresele corporaţiilor şi numere de telefon, logo-uri ale produselor – şi aceste date sunt prea

puţine relativ la total încât normalizarea acestora nu se ia în calcul. Pe de altă parte, alte seturi

de documentaţii au părţi comune importante între documente şi se merită normalizarea lor.

Ca şi în cazul bazelor de date relaţionale, 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 relaţionale. 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 interogărilor şi convertirea documentelor

existente, acest lucru ar putea uşura procesul de tranziţie.

Pagina 52 din 97


Normalizarea datelor pentru o bază de date nativă XML este aproximativ la fel ca

normalizarea unei baze de date relaţionale: documentele trebuie proiectate astfel încât datele

să nu se repete. O diferenţă între bazele de date native XML şi bazele de date relaţionale este

aceea ca XML suportă proprietăţi multi-valoare în timp ce majoritatea bazelor de date

relaţionale 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 relaţională.

De exemplu, se consideră un ordin de vânzare. Acesta constă în informaţiile din antet,

cum ar fi numărul ordinului, data, numărul clientului, şi unul sau mai mulţi itemi care conţin

un număr curent, cantitatea, şi preţul total. Într-o bază de date relaţională, informaţia 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ă informaţie poate fi stocată într-un singur

document fără redundanţe, deoarece natura ierarhică a XML permite unui element părinte să

aibă mai mulţi descendenţi.

Din nefericire, normalizarea pe cazuri concrete nu este atât de simplă. De exemplu, ce

se întâmplă atunci când se doreşte ca ordinul de vânzare să conţină informaţii despre client,

cum ar fi nume de contact şi adresa de expediere şi facturare? Exista două variante. Prima, se

pot duplica informaţiile despre client în fiecare ordin de vânzare pentru acel client, ducând la

date redundante şi toate problemele care apar cu acestea. A doua variantă, se pot stoca

informaţiile despre client separat şi fie adăugat un XLink în documentul ordinului de vânzare

către documentul clientului, fie unite cele două documente atunci când datele sunt interogate.

Acest lucru presupune că fie legăturile XLink sunt suportate (în majoritatea cazurilor nu

sunt), fie limbajul de interogare suportă uniri (de asemenea nu se întâmplă întotdeauna).

În practică nu există soluţii clare. Datele relaţionale din lumea reală sunt adesea

nenormalizate din motive de performanţă. Dacă se stochează documente centrate pe

documente şi acestea se pot normaliza până 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 soluţie bună, în special pentru că va oferi

caracteristici precum limbaje de interogare XML care nu se găsesc în alte baze de date. Dacă

se stochează documente centrate pe date şi o bază de date nativă XML îmbunătăţeşte

performanţa aplicaţiei sau oferă stocarea datelor semi-structurate, facilităţi care nu se găsesc

în alte baze de date atunci această bază de date ar trebui folosită.

Integritatea referenţială

Pagina 53 din 97

Integritatea referenţială este strâns legată de normalizare. Aceasta se referă la

validitatea pointerilor la datele legate şi sunt o parte necesară a menţinerii consistenţei bazei

de date. De exemplu nu este de niciun folos un număr de client dintr-un ordin de vânzare 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 relaţională, integritatea referenţială înseamnă asigurarea că se face

legătura corectă între cheile străine şi cheile primare – adică, verificarea că linia cheii primare

ce corespunde oricărei chei străine există. Într-o bază de date nativă XML, integritatea

referenţială î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, câmpuri

key/keyref (aşa cum sunt definite în scheme XML), legături 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 legături

specifice bazelor de date. În timp ce elementele şi atributele de referire într-un limbaj specific

sunt destul de des întâlnite, mecanismele de legături specifice bazelor de date sunt mai rare.

Integritatea referenţială într-o bază de date nativă XML poate fi împărţită în două

categorii: integritatea pointerilor interni (pointeri dintr-un document) şi integritatea

pointerilor externi (pointeri dintre documente). Integritatea referenţială a pointerilor interni

care folosesc mecanisme non-standard nu este forţată, deoarece bazele de date native XML

nu pot identifica aceşti pointeri. Integritatea referenţială a pointerilor interni care folosesc un

mecanism standard, cum ar fi ID/IDREF sau key/keyref, este cel puţin parţial suportată prin

validare.

Motivul pentru care acest suport este parţial este că majoritatea bazelor de date native

XML execută validări numai când un document este introdus în baza de date. Astfel, dacă

sunt efectuate actualizări 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 actualizări la nivel de nod – inserări, modificări şi ştergeri de noduri

individuale – atunci baza de date trebuie să mai facă operaţii în plus, cum ar fi validarea

tuturor modificărilor, pentru a garanta integritatea referenţială a pointerilor interni.

Integritatea refenţială a pointerilor externi nu este suportată, nici de puţinele 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. Totuşi,

dacă un pointer trimite la o resursă din afara bazei de date nu este obligatorie impunerea

Pagina 54 din 97


integrităţii. De exemplu, se presupune că un document conţine o legătură XLink care trimite

la un document pe un site web extern. Baza de date nu are nici un control asupra existenţei

documentului extern şi astfel nu se poate impune integritatea legăturii XLink.

În viitor, majoritatea bazelor de date native XML probabil vor suporta integritatea

referenţială 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 aceeaşi bază de date. Deocamdată în majoritatea cazurilor aplicaţiile impun

integritatea pointerilor atât interni cât şi externi.

Scalabilitate

Ca şi bazele de date ierarhice şi relaţionale, bazele de date native XML folosesc

indecşi pentru a localiza date. Acest lucru înseamnă că localizarea documentelor şi a

fragmentelor de documente este legată de dimensiunile indecşilor, nu de dimensiunile

documentelor sau de numărul 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

aceeaşi 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 relaţionale, 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 relaţionale folosesc

ca şi acestea legături logice.

Deoarece legăturile fizice sunt mai rapide decât cele logice, bazele de date native

XML, ca şi cele ierarhice, pot recupera date mai repede decât bazele de date relaţionale.

Astfel, ele ar trebui să scaleze bine din punctul de vedere al recuperării datelor. De fapt, ar

trebui să se comporte mai bine decât bazele de date relaţionale, deoarece scalabilitatea este

legată de o singură căutare indexată iniţială, spre deosebire de multiplele căutări necesare în

cazul bazelor de date relaţionale.

Din păcate, această scalabilitate este limitată. Ca şi bazele de date ierarhice, legăturile

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 aceloraşi date într-o

ierarhie diferită este mai înceată. De exemplu, se presupune că informaţiile despre clienţi sunt

stocate în fiecare ordin de vânzare. Recuperarea acestor ordine de vânzare 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 vânzare pentru un anumit client, va fi mult mai înceată,

deoarece legăturile fizice nu se mai folosesc.

Pentru a rezolva parţial această problema, bazele de date native XML folosesc foarte

mulţi indecşi, adesea indexând toate elementele şi atributele. Dacă acest lucru ajută la

scăderea timpului de recuperare a datelor, totuşi creşte timpul de actualizare, pentru că

întreţinerea acestor indecşi poate fi costisitoare. Aceasta nu este o problemă în medii read-

only, dar poate cauza probleme în medii în care se folosesc multe tranzacţii.

În cele din urmă, bazele de date native XML scalează mai slab decât cele relaţionale

în căutarea datelor neindexate. Ambele tipuri de baze de date trebuie să caute secvenţial

datele în acest caz, dar în cazul bazelor de date native XML este mai greu datorită

normalizării mai puţin complete. De exemplu, se caută toate ordinele de vânzări cu o anumită

dată şi datele nu sunt indexate. Într-o bază de date relaţională, aceasta înseamnă citirea tuturor

valorilor din coloana OrderDate. Într-o bază de date nativă XML, acest lucru înseamnă citirea

fiecărui ordin de vânzare în întregime şi căutarea elementului <OrderDate>. Nu numai că se

citeşte conţinutul fiecărui element <OrderDate>, dar se citeşte şi conţinutul 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 căutată.

Aici se încheie descrierea bazelor de date native XML. Următoarele doua secţiuni

tratează două tipuri specializate de baze de date native XML: DOM-uri persistente şi sisteme

de management ale conţinuturilor.

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ă, modificările făcute arborelui DOM sunt

reflectate direct în baza de date. Dacă modificările sunt făcute imediat sau în urma apelării

unei metode ‘commit’ depinde de baza de date. În majoritatea bazelor de date native XML,

arborele DOM returnat aplicaţiei este o copie, şi modificările sunt făcute î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

acelaşi spaţiu de procesări ca şi aplicaţia, sau cel puţin pe aceeaşi maşină, deşi acest lucru nu

este neapărat necesar. Acest lucru este făcut pentru eficienţă, deoarece un PDOM peste o

bază de date aflată la distanţă ar necesita cereri frecvente la un server aflat la depărtare.

Pagina 56 din 97


PDOM-urile au acelaşi rol pentru aplicaţiile DOM ca şi bazele de date orientate obiect

pentru aplicaţiile orientate obiect: ele oferă stocare persistentă pentru datele aplicaţiei, şi

servesc şi drept memorie virtuala pentru aplicaţie. Al doilea rol este foarte important pentru

aplicaţiile DOM care operează cu documente mari, deoarece arborii DOM pot uşor să

depăşească documentele XML ca mărime.

3.4.5 Sisteme de management ale conţinuturilor

Sistemele de management ale conţinuturilor 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 căutare

Editoare XML/SGML

Motoare de publicare pe hârtie, CD sau pe Web

Separarea conţinuturilor şi a stilurilor

Extinderea în scripturi şi programare

Integrarea datelor din baza de date

Termenul de sistem de management al conţinuturilor spre deosebire de sistem de

management al documentelor reflectă faptul că asemenea sisteme permit în general

împărţirea documentelor în fragmente cu conţinut discret, cum ar fi exemple, proceduri,

capitole, dar şi metadate cum ar fi numele autorilor, datele reviziilor, şi numerele

documentelor, decât să opereze cu fiecare document ca un întreg. Nu numai că astfel se

simplifică coordonarea lucrului mai multor scriitori la acelaşi 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 acelaşi 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 definiţii a tipului documentului XML, sau

DTD (Document Type Definition), care permite ca structura documentului XML să se

supună unor constrângeri şi să fie validată faţă de acele constrângeri. Distincţia dintre aceste

Pagina 57 din 97


două limbaje este deseori neclară, deoarece un document XML complet presupune măcar

existenţa opţională 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ă părţi, o submulţime internă

şi o submulţime externă. Aceasta parte studiază documentul XML fără a insista prea mult

asupra DTD-ului, deoarece un document XML poate fi creat şi fără a face referiri la un DTD.

Din motive de performanţă, multe documente XML vor fi utilizate fără 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

conţine referinţe la alte documente, rezolvarea tuturor referinţelor externe poate dura exagerat

de mult chiar şi în cazul conexiunilor de mare viteză. Utilizatorii sunt obişnuiţi ca

documentele HTML să fie încărcate incremental, deci pot citi înainte ca documentul să fie

încărcat în totalitate, dar analizatoarele XML de validare nu permit afişarea documentului

decât în cazul în care acesta este valid, deci documentul va apărea pe ecranul utilizatorului

numai în momentul în care este încărcat în totalitate. Acest lucru poate fi supărător. Totuşi,

fiecare document este creat având în minte un DTD, indiferent dacă DTD-ul este explicit sau

nu. Chiar şi la crearea documentelor fără un DTD, trebuie să avut în vedere un fel de DTD

empiric pe măsură 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 celălalt

prescriptiv.

Definiţiile tipului documentului XML (DTD-urile) descriu instanţe ale limbajului

XML, numite uneori vocabulare XML. Dcumentele XML sunt create utilizând acele limbaje.

Din păcate, 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 aplicaţia sa, la fel cum miilor de persoane care lucrează în design

Web utilizând 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 aşa mare la nivelul

aplicaţiei.

4.3 Avantajele definiţiei tipurilor documentului

Pagina 58 din 97


Cu toate că DTD-urile sunt opţionale deoarece un procesor XML poate conduce un

DTD convenabil dintr-o instanţă a XML, existenţa unui DTD oferă multe avantaje:

• Un DTD descrie organizarea unui document într-un mod care poate fi distribuit cu

uşurinţă.

• Un DTD permite unui proiectant să creeze o transformare robustă dintr-un anumit

tip de document XML într-un alt format, pentru afişare sau transfer. Deoarece cu un DTD se

cunoaşte 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

întâlnite niciodată până 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 specificaţiei. Acest

lucru este extrem de important pentru EDI (Electronic Data Interchange – schimb electronic

de date) şi alte aplicaţii în care documentele vor fi partajate şi utilizate şi de alte procese.

• Fără un DTD, un mediu de creare XML nu poate oferi sugestii despre elementele

care sunt necesare sau opţionale într-un anumit loc şi despre atributele pe care le poate

conţine un anumit element. Meniurile contextuale sau sugestiile pot fi de mare ajutor în

accelerarea dezvoltării documentelor şi în prevenirea erorilor.

• Fără un DTD, autorul unui manual de creaţie sau al unui document de stil nu are de

unde să ştie cum ar trebui construit documentul definit. Un manual de creaţie este o întrupare

a informaţiei 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. Când documentele se dezvoltă în funcţionalitate şi sintaxă, acesta poate

fi un indiciu într-o situaţie nouă.

4.4 Combaterea dezavantajelor definiţiei 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 abilităţi. În plus ca orice descriere

tehnică, implicarea în proiectarea unui DTD neavând în vedere aspectul structurii datelor în

document poate duce la împotmolirea în detalii atunci când este nevoie de atenţie la structura

generală. Multe persoane proiectează documente XML utilizând 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 adăugări la

codul sursă sau prin ajustarea acestuia.

Dar DTD au şi următoarele dezavantaje:

Pagina 59 din 97


• Cu un DTD, un agent utilizator XML care validează necesită cel puţin încă o

operaţie de citire pentru a accesa locaţia unde este disponibil DTD-ul. Cu toate că plasarea în

cache poate reduce performanţele pentru unii utilizatori din reţea, multe utilizări previzibile

ale documentelor XML vor face imposibilă utilizarea stocării în cache.

• Un DTD creşte cu mult complexitatea analizorului necesar pentru a determina dacă

un document poate fi afişat. Pentru unele dispozitive, este posibil ca acest lucru să fie

realizabil.

• Unele medii de creare care validează şi utilizează un DTD îngreunează salvarea

spaţiului de lucru la sfârşitul zilei sau restaurarea sa în ziua următoare, cu excepţia 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 conţine alte DTD-uri sau mulţimi de entităţi. Este posibil ca

pentru afişarea unor documente complexe să fie nevoie de foarte mult timp atunci când se

utilizează un analizor care validează.

Decizia utilizării unui DTD este un compromis între abilitatea de utilizare fără

restricţii, obişnuită în HTML – posibilitate de a face aproape tot ce se doreşte – şi un mediu

mult mai structurat. În multe situaţii, 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 când se dezvolta un tip de

document XML nou, nu este nevoie sau nu este dorită constrângerea strictă şi se poate realiza

fără un DTD, cel puţin în timpul proiectării iniţiale.

Dar după ce dezvoltarea a devenit un produs stabil, este de dorit ca proiectul să poată

fi distribuit cu uşurinţă. Chiar dacă se doreşte 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 indicaţiile 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 asemănător cu HTML, dar un HTML

transformat atât de mult, încât nu mai poate fi recunoscut. XML este mult mai structurat

decât 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 când găseşte o eroare

fatală, care poate fi aproape orice tip de eroare. Aceasta este într-un fel o întoarcere la primele

zile ale prelucrării datelor, când orice eroare din cod era pedepsită cu un vidaj de memorie,

(core dump) lângă care se puteau petrece ore întregi în încercarea de a-l descifra.

Pagina 60 din 97

Totuşi pe lângă acest comportament necruţător, XML este cu mult mai puternic. În

timp ce HTML se mulţumeşte cu un număr relativ mic de etichete, XML are un număr de

etichete aproape infinit, structurate în aproape orice fel se doreşte. Oricum, fundamentele au

rămas aceleaşi, XML reprezentând un pas evolutiv al HTML. Nu numai că un HTML bine

făcut 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 aplicaţie SGML, iar XML este o submulţime a SGML, acest lucru este logic.

Diferenţele 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 aplicaţia XML, atributele lor, valorile posibile şi modul lor de imbricare.

Urmărirea unui astfel de manual de codare nu este mai dificilă decât reţinerea 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 situaţiilor, acest lucru este

suficient. XML este capabil să ofere autorilor suficient ajutor în învăţarea modului de

utilizare a unei anumite aplicaţii, deoarece aceştia sunt încurajaţi să dea etichetelor nume

sugestive, care să fie uşor de reţinut. Autorul unei aplicaţii ar trebui să furnizeze un manual

de creare care să explice în termeni simpli modul de utilizare a aplicaţiei.

Cu toate că orice procesor XML poate spune despre o porţiune de cod dacă este sau

nu construit corect, iar un manual poate ajuta la construirea unui document valid, DTD-ul

permite verificarea fără ambiguităţi a codului. Totuşi, în funcţie de tipul de creare utilizat,

acesta poate fi un pas diferit de procesul de editare.

Codul îndeplineşte acest ideal în funcţie de utilizarea dată numelor etichetelor, totuşi

între anumite limite:

• Numele de etichete care încep cu şirul “xml”, indiferent de tipul literelor, sunt

rezervate; adică, indiferent de situaţie, nu este permisa crearea lor.

• Numele de etichete care conţin caracterul două puncte pot fi interpretate ca

identificatori având asociată o zonă de nume, deci utilizarea celor două puncte în numele

etichetelor este puternic combătută ş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 conţine orice “literă”, ideogramă sau cifră

Unicode/ISO/IEC 10646, caractere de combinare, caractere de extindere, puncte, cratime,

spaţii sau două puncte. De altfel, puţine 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 poziţie în care pot fi văzute ca “primele” după o cratimă sau un

alt separator logic de cuvinte.

Caracterul thailandez mai yamok (arată ca un f întors şi fără liniuţă), de exemplu,

arată ca o literă, dar nu poate fi folosit ca primă literă a unui cuvânt 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 intrările de la tastatură deoarece multe limbi care conţin caractere accentuate

permit introducerea utilizând caractere accent speciale “de lăţime zero” care se pot ataşa la

orice alt caracter.

Caracterele de extindere sunt diverse semne de punctuaţie, 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 evidenţiază mulţimea de deprinderi necesare pentru XML şi clarifică

numeroasele asemănări 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 operaţie împovărătoare. Unele limbi nici

nu au tipuri de litere. De exemplu, în limba ebraică nu există litere mici, iar limba arabă nu

face distincţie între forma iniţială, de mijloc şi finală a literelor. Pentru cei care preferă să

scrie etichetele cu majuscule şi atributele cu litere mici, pentru a le evidenţia, aceasta este o

ştire teribilă. Dar editoarele de cod moderne nu mai acordă o importanţă aşa de mare acestui

lucru ca înainte. De exemplu, precizarea anumitor culori pentru a marca etichete este un lucru

obişnuit, deci utilizarea majusculelor este întrucâtva 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 doreşte <bold><italics>,

fraza evidenţiată 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ă aceloraşi reguli pentru a nu strica documentele

altora.

Pagina 62 din 97

• XML nu este bine protejat împotriva recursivităţii – Cu toate că este posibilă

stabilirea excluderilor explicite la un anumit nivel, la o structură complexă a unui document

este dificilă menţinerea acelor excluderi la un nivel redus, mai ales atunci când se utilizează

etichete care pot fi aplicate la orice nivel. Deci, interdicţia 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 fiecărei 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ă plasând un spaţiu şi

un caracter slash la sfârşitul etichetei, astfel:

<break />

Există o sintaxă alternativă, care este la fel de bună pentru procesoarele XML reale,

dar blochează frecvent browserele Web atunci când este utilizată cu XHTML; aceasta cere ca

o etichetă vidă, cum ar fi , să fie închisă cu , astfel: 

Din păcate, este prea periculoasă pentru a fi utilizată în siguranţă. Multe browsere

actuale şi majoritatea celor moştenite nu recunosc eticheta de închidere non- HTML şi fac

lucruri ciudate cu ea. Navigator 4.7, de exemplu, poate zăpăci afişarea atunci când se

împiedică de o etichetă . Comportamentul exact poate diferi în funcţie de poziţia î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 priveşte numerele şi aproape orice şir

fără spaţii în interior, XML tratează totul ca şir de caractere şi lasă aplicaţia să îşi dea seama

singură de toate acestea.

• XML recunoaşte 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

uşor. În afară de diferenţele menţionate în această listă, XML este foarte asemănător cu

HTML din punctul de vedere al marcării etichetelor, al argumentării atributelor şi al trecerii

conţinutului între perechi de etichete.

Pagina 63 din 97


Limbajul XML a fost proiectat astfel încât să fie transparent la utilizare pentru a putea

fi înţeles şi utilizat cu uşurinţă. Descrierile XML succinte sau complicate din majoritatea

documentelor sunt greu de înţeles în efortul de a fi explicit într-un mod în care programatorii

să îl poată translata cu uşurinţă în aplicaţii care să funcţioneze.

4.7 Definirea unui document XML ca întreg

Un document XML este o colecţie de entităţi care pot fi sau nu analizate. Datele care

nu sunt înţelese de un procesor XML, date binare sau date care au sens numai pentru alte

aplicaţii, reprezintă date neanalizate. Datele înţelese 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ă situaţie este descrisă concis prin următoarele cerinţe:

• Luat ca întreg, corespunde producţiei etichetate ca document.

• Satisface toate constrângerile de construire corectă din această specificaţie

(Recomandarea XML 1.0)

• Fiecare entitate analizată, referită direct sau indirect în cadrul documentului, este

construită corect.

Prima constrângere 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 rând că un document XML trebuie să conţină un prolog şi un singur element

care formează elementul rădăcină al documentului, împreună cu comentarii opţionale şi

instrucţiuni de prelucrare la sfârşitul documentului, dar, din păcate, analizorul XML nu are

cum să spună dacă aceste comentarii şi instrucţiuni de prelucrare ataşate sunt sau nu ataşate

documentului. Deoarece ele pot sa fie plasate după eticheta de încheiere, un analizor XML nu

poate să spună nici dacă instrucţiunile de prelucrare şi comentariile ataşate au fost sau nu

recepţionate. 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ă instrucţiuni

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 constrângere spune că documentul respectă constrângerile construirii

corecte descrise în document. Una din constrângerile construirii corecte este că entităţile

analizate recursiv sunt interzise. Recursivitatea din această interdicţie se referă la formarea

unei bucle de entităţi în care o entitate se încorporează pe ea însăşi sau o altă entitate care se

încorporează pe ea însăşi indiferent de nivelul de indirectare. Aceasta mai înseamnă şi că un

document nu se poate referi la el însuşi, nici măcar 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 însăşi, chiar şi indirect.

Este posibil ca analizoarele care nu validează să nu depisteze această eroare, dar aceasta este

totuşi o eroare. Din punct de vedere logic este evident că dacă documentul A conţine

documentul B, definindu-l pe B ca şi când l-ar conţine pe A se generează o buclă infinită.

Bucla infinită este interzisă.

În termeni XML, construcţia 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 posibilităţii de utilizare a XML pe Web.

Deşi construirea corectă poate fi considerată suficientă deoarece un document

construit corect are un DTD care îl descrie, pot fi construite un număr infinit de DTD-uri

care, de asemenea, să îl descrie. Deci, pentru validitate totală, un DTD asociat este necesar.

Producţia documentului este definită în numai două afirmaţii, preluate din nou din

Recomandarea XML 1.0:

• Conţine unul sau mai multe elemente.

• Există un singur element, numit rădăcină sau element document, care să nu aibă nici

o parte a sa în conţinutul oricărui alt element. Pentru toate celelalte elemente, dacă eticheta de

pornire se află în conţinutul unui alt element, atunci şi eticheta de încheiere se află în

conţinutul aceluiaşi element. Exprimat mai simplu, elemente delimitate de etichete de pornire

şi încheiere sunt imbricate corect unele în altele.

Prima afirmaţie spune că într-un document trebuie să existe cel puţin un element sau,

altfel spus, un document construit corect nu poate fi vid.

Cea de a doua afirmaţie spune că, într-un sens restrâns, un document trebuie să fie un

arbore. El nu poate fi o reţea 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 diferenţa dintre o

descărcare reuşită şi una parţială.

Din punct de vedere tehnic, un arbore este un graf conex care nu conţine circuite. Cu

alte cuvinte, un arbore se ramifică de la rădăcina sa fără a se mai conecta la el însuşi, deci nu

conţine muchii multiple sau bucle. Orice lucru care conţine 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

rădăcină, reorganizând arborele într-un alt arbore, cu o altă ordine de parcurgere. Aceasta

ilustrează caracterul capricios al schemelor de clasificare.

Pagina 65 din 97

O descărcare parţială 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 parţial se poate deghiza într-unul complet, iar utilizatorul nu are de

unde să ştie acest lucru până când î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

convenţie de acordare a licenţei, de exemplu, nu a fost afişată în întregime. Insistând 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 decât dacă graful poate fi simplificat, eliminând toate caracteristicile care nu

sunt reprezentative pentru arbori. În Figura 2, de exemplu, graful din stânga poate fi

simplificat prin eliminarea unei căi de la frunza de sus către un nod. În aceeaşi figură,

grafului din partea dreaptă trebuie să i se elimine o rădăcină deoarece un document XML

poate avea o singură rădăcină.

Pagina 66 din 97

4.8 Prologul: declaraţia XML

Fiecare document XML, ar trebui să înceapă cu o declaraţie XML care identifică

fişierul ca fiind un fişier XML şi identifică, de asemenea, versiunea XML utilizată în

documentul respectiv. Caracterul opţional este datorat numai faptului că pe Web există multe

fişiere HTML şi SGML care corespund perfect unui document XML construit corect. De

asemenea, declaraţia XML este locul unde se declară codificarea şi dacă documentul este sau

nu autonom. Ordinea din fragmentul următor este obligatorie cu toate că atributele encoding

şi standalone sunt ambele opţionale.

<?xml version=”1.0” encoding=”ISO-8859-1” standalone=”yes”>

Codificările permit identificarea cărui 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 obişnuite care pot fi autori XML. Sau, un autor chinez poate să prefere caracterele

chinezeşti în etichete şi în conţinut cu câteva limitări bazate pe regulile limbajului în sine, se

pot utiliza moduri de scriere şi ideograme atât în numele etichetelor cât şi în conţinut.

4.9 Documente autonome

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

declaraţii de marcare externe care să afecteze informaţia XML transferată de procesorul XML

Pagina 67 din 97

unei aplicaţii”. 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 entităţi în afară de &, <, >, ', şi ", care

nu au fost declarate local sau poate citite prin referinţă dintr-un fişier.

• Nu există elemente care să aibă ca şi conţinut numai spaţii albe de orice natură.

• Nu există atribute externe care trebuie normalizate, deci conţinutul atributelor nu

poate conţine spaţii albe, caractere sau referinţe la entităţi. 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 opreşte din citirea documentelor externe, se opreşte

prelucrarea tuturor declaraţiilor. Toate aceste lucruri se pot face dacă şi numai dacă sunt puse

în submulţimea DTD-ului intern. Datele externe care nu sunt marcaje nu fac subiectul acestei

afirmaţii. Deci, pot exista fişiere grafice, fişiere text incluse şi orice altceva, atât timp cât ele

nu sunt marcaje şi au fost declarate în submulţimea DTD-ului intern. După toate acestea,

procesorul XML nu trebuie să anunţe aplicaţia dacă documentul este sau nu autonom. De

fapt, procesorul nu trebuie să facă nimic cu această informaţie şi nici să se comporte într-un

anumit fel atunci când întâlneşte această informaţie.

În mod fundamental, proiectantul DTD-ului trebuie să descifreze dacă documentul

creat utilizând 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 declaraţia lor XML ca o documentaţie a acelui fapt:

<?xml version=”1.0” standalone=”yes” ?>

Documentele care nu sunt autonome pot fi convertite prin algoritmi la documente

autonome, automat, presupunând că este disponibilă o facilitate care să realizeze acest lucru,

sau manual în caz contrar.

4.10 Construirea prologului unui document XML: Declaraţia tipului documentului

(Document Type Declaration)

Prologul unui document XML conţine mai multe instrucţiuni. Prima, declaraţia XML,

afirmă că documentul următor este XML. Cea de a doua, declaraţia tipului documentului

(Document Type Declaration), este metoda utilizata pentru a identifica definiţia tipului

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ă.

Pagina 68 din 97

DTD se referă numai la Document Type Definition. Într-un document XML poate exista o

singură declaraţie a tipului documentului, deci este introdusă chiar în instanţa documentului.

Deoarece pot fi combinate mai multe DTD-uri pentru a forma un singur document, aceasta

permite controlul încărcării DTD-urilor în fiecare document.

Declaraţia tipului documentului (DOCTYPE) are două părţi, ambele opţionale. 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 părţi deodată, fără cel de al doilea

cuvânt cheie:

<!DOCTYPE nume-document PUBLIC “{catalog id}”>

<!DOCTYPE nume-document PUBLIC “{catalog id}” “{uri}”>

<!DOCTYPE nume-document SYSTEM “{uri}”>

Cea de a doua parte opţională a declaraţiei DOCTYPE permite introducerea

submulţimii interne a unui DTD direct în document. Există restricţii severe cu privire la genul

de informaţie care poate fi introdusă în DTD-ul intern, dar oricum se pot face destul de multe.

Submulţimea internă a unui DTD este încadrată între paranteze drepte, astfel:

<!DOCTYPE nume-document [ {declaraţiile DTD-ului intern} ]>

De asemenea, cele două pot fi combinate, permiţând adăugarea anumitor tipuri de

declaraţii şi entităţi aproape în orice mod:

<!DOCTYPE nume-document PUBLIC “{catalog id}” “{uri}” [ {declaraţiile DTD-

ului intern} ]>

Pentru claritate, submulţimea internă este evidenţiată ca mai jos:

<!DOCTYPE nume-document PUBLIC “{catalog id}” “{uri}” [

{declaraţiile DTD-ului intern}

]>

Declaraţia DOCTYPE trebuie să utilizeze numele elementului rădăcină al DTD-ului

fie acesta intern sau extern, ca fiind câmpul etichetat nume-document din exemplele

anterioare. Deci dacă numele elementului rădăcină al DTD-ului este Dave, declaraţia

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 fiecărui autor. De

asemenea, se poate crea un DTD master care apelează părţile DTD necesare, lucru care

seamănă cu comenzile dintr-un meniu. Atunci când se obţine o combinaţie de funcţionalităţi

Pagina 69 din 97


care permite crearea structurii documentului de care este nevoie, se poate publica DTD-ul

rezultat şi înlătura neplăcerea refacerii pentru fiecare document nou.

4.10.1 Crearea corpului documentului

Un document XML este alcătuit din text, care de obicei este format dintr-un amestec

de marcaje şi date caracter. Prologul conţine numai marcaje, dar nu aceasta este partea

interesantă, deoarece este nevoie de date care să însoţească marcajele care, altfel, nu ar fi

decât nişte cutii goale ce aşteaptă să fie umplute. Corpul documentului conţine aproape tot

ceea ce contează din perspectiva unei aplicaţii împrăştiate 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 obişnuite de tip caracter.

Foaia sau manualul de codare indică ce tip de dată poate fi introdus în fiecare atribut sau

câmp cu conţinut element. Presupunând că tipul de date este CDATA, în câmp se poate pune

aproape orice se doreşte atât timp cât nu conţine un marcaj în afara unei secvenţe escape.

Este pe deplin posibilă construirea unui DTD care să nu conţină text în interiorul

elementelor. În schimb, se pot pune datele semnificative în interiorul atributelor asociate

fiecărui element, care pot fi toate declarate ca fiind vide sau având numai conţinut element.

Acest lucru se face uneori pentru a converti un document utilizând 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 fişier XML.

Diversele forme pe care le poate lua un marcaj sunt prezentate în tabelul următor:

Tabel

1 Sintaxa marcajului XML

Toate celelalte sunt date de tip caracter.

Pagina 70 din 97

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 arăta structura logică

dintr-un document XML. Etichetele de pornire şi încheiere din fluxul de text spun

procesorului XML că a fost întâlnit un nod. Dacă procesorul XML întâlneşte o altă etichetă

de pornire înainte de eticheta de încheiere corespunzătoare, atunci procesorul ştie că acesta

este fie un nod nou în arbore, fie o frunză. Dacă nu găseşte o nouă etichetă de pornire şi

întâlneşte o etichetă de încheiere, atunci procesorul ştie că aceasta este o frunză şi că poate

acţiona iterativ la acel nivel al arborelui până când întâlneşte o altă etichetă de pornire sau de

încheiere. Prelucrarea acţionează treptat, bazându-se pe această regulă simplă. Dacă

procesorul validează documentul, atunci fiecărui nod i se poate asocia o regulă care să

determine ce tip de conţinut poate apărea în el. O etichetă vidă este, prin definiţie, o frunză,

deoarece nu poate avea nici un conţinut.

Majoritatea structurilor de date conţinute într-un document XML pot fi accesate

secvenţial fără a construi structura în memorie. O etichetă de pornire începe un nod sau o

frunză, iar eticheta de încheiere corespunzătoare îl(o) încheie. Orice etichete întâlnite între o

etichetă de încheiere corespunzătoare 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 fiecărui

element. În plus, structura logică poate diferi în funcţie de conţinutul secţiunilor condiţionale

din cadrul documentului sau al componentelor sale.

4.10.5 Cum formează XML structurile fizice

Imbricarea entităţilor este singurul mecanism utilizat pentru a arăta structura fizică

dintr-un document XML. Definiţiile de entităţi întâlnite în fluxul de text îi comunică

procesorului XML că a fost găsită o altă entitate.

Există multe tipuri de entităţi, de la entităţile mici care formează caractere individuale,

cum ar fi: (spaţiu), până la entităţile externe care permit încorporarea într-un

document porţiuni din alte documente XML sau includerea într-un document a referinţelor la

date neanalizate, cum ar fi fişiere multimedia pentru redarea ulterioară de către un agent

utilizator.

Un document XML este o colecţie de astfel de entităţi. Fiecare din aceste subentităţi

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

Pagina 71 din 97

trebuie să fie, de asemenea, un arbore simplu. Structuri mai mari se pot construi prin

adăugarea nodurilor sau a arborilor subentitate ca porţiuni ale arborelui mai mare.

4.10.6 Etichete de pornire şi etichete de încheiere

În XML sunt utilizate două tipuri de etichete, etichete cu conţinut şi etichete vide.

Etichetele cu conţinut trebuie să aibă o etichetă de pornire şi o etichetă de încheiere. Eticheta

de pornire conţine numele elementului încadrat între paranteze unghiulare, având opţional

atribute ca argumente. Eticheta de încheiere conţine numele elementului precedat de

caracterul slash, totul fiind încadrat între paranteze unghiulare. În eticheta de încheiere nu

puteţi trece atribute. Codul următor reprezintă o etichetă cu conţinut:

<titlu subtitlu=”0 călătorie acasă” >Dus-întors</titlu>

Seamănă 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-adevăr una în cealaltă. Nu

pot exista etichete care să alterneze între ele ca în acest exemplu greşit construit:

<bold><italic>TEXT ACCENTUAT</bold></italic>

Cu toate că este o eroare obişnuită în HTML, XML este cu mult mai pretenţios şi nu

va permite această construcţie. Etichetele trebuie imbricate corect, după cum se vede în

exemplul următor:

<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ă aceeaşi schemă, etichetă de

pornire/ etichetă de încheiere, poate fi utilizată atâta timp cât se ţine cont de faptul că nu

trebuie pus nici un fel de conţinut î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 obişnuit, deoarece etichetele

de încheiere pentru elementele care arată ca etichete HTML vide pot duce la blocarea

browserului sau la un comportament ciudat al acestuia. Totuşi, 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 aceleiaşi perechi de paranteze unghiulare, plasând după numele

elementului şi toate atributele sale posibile un spaţiu, un caracter slash şi apoi paranteza

unghiulară închisă:

<image source=”pozamea.jpeg” type=”JPEG” />

Pagina 72 din 97


4.10.7 Normalizarea

Normalizarea este un cuvânt 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 rezolvării referinţelor la entităţi în locaţii în care pot apărea astfel de referinţe, la

aranjarea rândurilor noi pentru a lua în considerare diversele metode de tratare a lor de către

diferite sisteme de operare şi la ordonarea altor lucruri care trebuie făcute în anumite situaţii.

Proiectantul rareori trebuie să se preocupe de normalizare, excepţie făcând cazurile

negative. Analizorul XML ar trebui să realizeze toate normalizările necesare, deci singurul

lucru la care trebuie să se gândească creatorul documentului este dacă normalizarea va afecta

sau nu datele sale atunci când se va face trecerea de la forma nenormalizată şi invers. S-a

dovedit că există două locuri în care pot fi întâlnite spaţii albe: în datele de tip caracter din

cadrul documentului şi în datele de tip caracter atribuite atributelor elementelor. În primul

caz, în entităţile analizate este dificil să se facă distincţie între spaţiile albe “semnificative” şi

cele nesemnificative. Pentru proiectanţi, cea mai bună cale pare să fie transferul către

aplicaţie al tuturor spaţiilor 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 răspundere are sens deoarece aplicaţia este cea în măsură să ştie

cum să procedeze cu spaţiile albe suplimentare.

Procesorul XML poate numai să presupună care spaţiu alb este semnificativ şi care

nu, bazându-se pe ceea ce a fost definit în DTD sau în orice alt limbaj de scheme utilizat. O

aplicaţie trebuie să fie pregătită să trateze presupunerile eronate. Cu tratarea sfârşiturilor de

linie, o altă formă de spaţii 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 atât un return cât şi saltul la linie nouă (MS Windows). Un alt lucru obişnuit pentru

aplicaţii este, de asemenea, inserarea de secvenţe contradictorii cu oricare dintre acestea, în

orice ordine, atunci când întâlnesc un fişier dintr-un sistem străin. W3C a hotărât că nu poate

face totul şi a ales un set rezonabil de reguli. Dacă analizorul întâlneşte fie

(return , salt la linie nouă), fie (return), el le înlocuieşte cu &#0A; (salt la linie nouă),

caracterul de linie nouă UNIX.

Microsoft şi Apple au ales mecanisme diferite pentru separarea liniilor, Microsoft

alegând tehnica “curea şi bretele” obişnuită pentru teleimprimatoare, utilizând un return şi

apoi un salt la linie nouă pentru a indica o linie nouă. Apple a hotărât că saltul la linie nouă

era redundant şi a considerat că un singur return este suficient, modelat probabil după

comportamentul unei maşini de scris obişnuite. UNIX a utilizat de la început un singur salt la

Pagina 73 din 97


linie nouă pentru a realiza acelaşi lucru, iar acesta a fost standardul convenit pentru XML. În

atribute există o secvenţă de transformare standard şi apoi o prelucrare

adăugată special pentru orice în afară de CDATA:

• Referinţele la caractere sunt prelucrate prin adăugarea caracterului referit la valoarea

de ieşire a atributului.

• Referinţele la entităţi sunt procesate prin prelucrarea recursivă a textului de înlocuit

al entităţii.

• Spaţiile albe, #x20 (spaţiu), #x0D (retur de car), #x0A (salt de linie nouă) şi #x09

(tab orizontal) sunt prelucrate prin adăugarea lui #x20 (spaţiu) la valoarea normalizată a

ieşirii excepţie făcând faptul că se adaugă un singur #x20(spaţiu) pentru secvenţa

“#x0D#x0A” (retur de car, salt la linie nouă), care este parte a unei entităţi externe analizate

sau valoarea entităţii literale a unei entităţi analizate interne.

• Celelalte caractere sunt prelucrate prin adăugarea lor la valoarea normalizată a

ieşirii.

• Dacă tipul de dată al atributului nuI este CDATA, cel prestabilit, atunci se aplică

încă o transformare. Spaţiile din faţă şi din spate sunt eliminate, iar spaţiile multiple sunt

comasate într-un singur spaţiu. Diferenţa dintre cele două tipuri de normalizare constă în

faptul că se pot transfera în mod convenabil şiruri lungi într-un atribut, restrânge linii astfel

încât să încapă în pagină, iar în final conţinutul elementului să rămână relativ curat.

4.10.8 Tipuri de elemente

În mod surprinzător, 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,

permiţând în interiorul unor elemente alte tipuri de elmente nedeclarate, indiferent de ceea ce

spune modelul lor de conţinut, se poate suplimenta DTD-ul unui document cu elemente din

alte zone de nume. Deci, tot ce rămâne de făcut este utilizarea elementului nedeclarat într-o

manieră exactă, construită corect, identificând pe cât 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

a fost definit în DTD-ul asociat acelui document prin declaraţia DOCTYPE. DTD-ul declară

următoarele:

• Numele efective ale elementelor

Pagina 74 din 97

• 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

• Entităţile neanalizate utilizate în document şi modul în care sunt referite prin nume

• Codificările de limbă utilizate în document

• Alte informaţii importante pentru prelucrarea şi redarea documentului

Respectând aceste reguli se pot crea documente în concordanţă cu şablonul pe care

proiectantul documentului l-a avut în minte atunci când a creat DTD-ul. Într-un mediu care

nu validează se pot crea etichete şi atribute pe măsura înaintării. Foaia sau manualul de

codare afişează toate acestea într-un format uşor de citit şi înţeles, dacă autorul DTD-ului şi-a

făcut treaba corect. Când 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ă păstrarea la îndemână a documentaţiei de codare pentru cazul în care apar

defecţiuni.

4.10.9 Entităţi neanalizate

O entitate neanalizată este orice lucru care nu poate fi recunoscut de un procesor

XML, fie date binare, cum ar fi un fişier imagine sau audio, fie text care trebuie să fie

transferat unei aplicaţii fără a fi prelucrat în vreun fel. HTML utilizează comentarii pentru a

ascunde un astfel de text de browserul HTML, dar XML are câteva mecanisme care

funcţionează mult mai sigur.

O entitate neanalizată trebuie mai întâi să fie declarată ca NOTATION, o declaraţie

specială care numeşte o aplicaţie de asistenţă care ştie cum să lucreze cu entităţi de un anumit

tip. Notaţiei îi este dat un nume, un identificator public opţional şi apoi numele mai puţin

opţional al aplicaţiei de asistenţă, ca în una din variantele următoare:

<! NOTATION nume-mnemonic PUBLIC “identificator-public”>

<! NOTATION nume-mnemonic PUBLIC “identificator-public” “nume-

aplicaţie.exe”>

<! NOTATION nume-mnemonic SYSTEM “nume-aplicaţie.exe”>

Prima opţiune funcţionează numai dacă există un catalog. Nu se poate pune baza pe

un catalog deoarece acesta funcţionează indiferent dacă există sau nu catalog. Nu se poate

baza pe un catalog deoarece acesta este un instrument SGML pe care multe procesoare XML

actuale l-au moştenit 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

Pagina 75 din 97

recomandă utilizarea ultimele două versiuni. Pe de altă parte, codarea hard a informaţiilor

despre locaţia şi identitatea aplicaţiei de asistenţă în absolut fiecare DTD este un anacronism

predispus la erori pe Web.

Prin redefinirea comportamentului script-urilor în prezenţa comentariilor, proiectanţii

XML-ului au introdus o problemă de incompatibilitate între XML şi HTML. După toate

probabilităţile, procesoarele XML vor continua să transfere comentarii la aplicaţii deoarece

multe pagini se vor întrerupe dacă nu vor avea acest comportament. De asemenea,

procesoarelor le este permis transferul informaţiei comentate prin acelaşi limbaj prin care li

se permite să nu o facă. După ce o notaţie a unei entităţi 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 aceeaşi 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 având acel tip

disponibil într-o enumerare. Celelalte atribute adună informaţiile de care are nevoie aplicaţia

de asistenţă externă pentru a fi capabilă să prelucreze datele. O aplicaţie tipică poate fi un

fişier imagine:

<image source =”uri” alt =”graphic description” type=”gif89a”>

Acest element va necesita în DTD următoarele declaraţii:

<! 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 >

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

ca gif87a sau ca gif89a, deoarece aceleaşi instrumente manevrează ambele formate.

Notaţiile vor fi mult îmbunătăţite o dată cu adăugarea facilităţilor oferite de

XLink/XPointer care ajută la urmărirea locaţiilor asistenţilor. Cu instabilitatea generală a

Pagina 76 din 97

Web-ului la nivelul său actual şi cu larga varietate de facilităţi şi arhitecturi de pe sistemele

utilizatorilor, orice ajutor care poate fi obţinut de către utilizator va face mai uşoară

configurarea instrumentelor XML. DTD-ul, în forma sa actuală, necesită mult prea multă

ajustare în stil UNIX a fişierelor pentru a fi pe placul utilizatorilor obişnuiţi. XLink şi

XPointer încearcă să învingă limitările tehnologiei pointer actuale. Permit toate tipurile de

relaţii, inclusiv pointeri inverşi care să fie generaţi pe loc în documente fără acces la scriere,

realizând-uşi efectul chiar asupra copiei afişate, şi nu prin inserarea fizică brută a etichetelor

în conţinut.

Cerinţele XML pentru notaţii, în forma actuală, sunt extrem de severe.

Posibilitatea de a indica locaţia unde se află aplicaţia de asistenţă poate fi comodă

pentru notaţii neobişnuite sau foarte specializate. Totuşi, este de aşteptat ca agentul utilizator

să ştie cum să afişeze multe dintre tipurile mai obişnuite, cum ar fi GIF-uri, JPEG-uri,

PNGuri, WAV-uri şi alte tipuri de fişiere binare mai mult sau mai puţin standard, utilizate pe

Web. Iată o listă a notaţiilor obişnuite:

<! 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”

>

<! NOTATION gif89a PUBLIC “-//CompuServe //NOTATION Graphics Interchange

Format 89a//EN”

>

Pagina 77 din 97

<! 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 aplicaţie de asistenţă locală, fie în fişierul catalog care centralizează locaţiile acestor

aplicaţii, dacă este disponibil pentru instrumentele folosite.

4.10.10 Aplicaţii din lumea reală

S-au văzut deja, mai sus, unele dintre instrumentele care pot fi utilizate pentru a crea

un document XML, dar unde se pot găsi 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. Câteva dintre aplicaţiile mai importante ale XML care se afirmă în lumea de

azi sunt:

• Health Level-7 (HL7), Standardul informatic de sănătate (Health Informatics

Standard) a fost introdus în anul 1987 pentru a dezvolta standarde pentru schimbul electronic

de informaţii clinice, financiare şi administrative între sistemele de calcul din domeniul

sănătăţii. HL7 s-a concentrat asupra utilizării SGML şi XML ca mecanisme de transport între

diferite sisteme informatice din domeniul sănătăţii.

• Real Estate Transaction Standard (RETS – standardul de tranzacţii imobiliare) este o

metodă bazată pe XML pentru schimbul de informaţii referitoare la tranzacţiile 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

spaţii pentru locuinţe, spaţii comerciale şi terenuri virane, pentru publicarea lor pe Web.

• RosettaNet, limbajul comun pentru afaceri, este o iniţiativă EDI/E-Commerce

destinată intermedierilor în domeniul calculatoarelor.

• MathML şi CML sunt două standarde XML ştiinţifice care permit matematicienilor

să editeze ecuaţii, iar chimiştilor 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 conţinut să realizeze prezentări audio şi

video complexe.

• ICE, Information and Content Exchange (schimb de informaţii şi conţinut), cu toate

că nu este chiar o aplicaţie XML, fiind de fapt un mecanism de transport, permite schimbul

de investiţii on-line şi informaţii personale pe Web.

Pagina 78 din 97


• SAE J2008 este un sistem de comenzi şi inventariere bazat pe XML pentru industria

auto; MISTI, the Missile Industry Supply-chain Transaction Infrastructures, face acelaşi lucru

pentru industria spaţială.

• 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 fişierelor standard Genealogical Data

COMmunication (GEDCOM) la GedML. Fiecare producător de browsere are standarde

propuse, despre care ceilalţi se plâng că sunt îndreptate împotriva lor. Aşa cum războaiele

browserelor au dus la dezvoltarea unor “extensii” patentate la HTML, care tindeau (sau

încercau) să blocheze celelalte browsere, creând un turn Babel de metode incompatibile,

XML va fi într-o continuă schimbare pentru o bună perioadă de timp. Totuşi, bazele există

deja, iar o comunitate de utilizatori cerând 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 vând documentaţia pentru a-şi finanţa eforturile în crearea de

standarde, dar asigură un teren neutru pentru toţi partenerii. Pentru preţul documentaţiei, de

obicei câteva sute de dolari, toţi pot concura la acelaşi nivel.

CAPITOLUL V

PREZENTAREA APLICAŢIEI

“ElectronX” este o aplicaţie „e-commerce”, un site web ce reprezintă un magazin

virtual de electronice care se adresează tuturor persoanelor care doresc să achiziţioneze

diverse produse, în cazul de faţă electronice, prin intermediul internetului accesând un

magazin virtual din confortul propriei locuinţe, comerţul electronic mondial având o

dinamică ascendentă pe măsură ce tot mai mulţi consumatori şi tot mai multe afaceri se

conectează la web, acest tip de comerţ câştigând din ce în ce mai mult teren şi în România.

Aplicaţia se doreşte a fi o unealtă folositoare utilizatorilor, avându-se în vedere

dezvoltarea interfeţei pentru a fi user-friendly, dorindu-se a fi o aplicaţie cât mai uşor de

folosit, eventualele neajunsuri şi opinii putând fi aduse la cunoştinţa administratorului site-

ului prin adresele de e-mail puse la dispoziţia utilizatorilor în pagina de contact.

Pagina 79 din 97


Tehnologiile folosite pentru realizarea aplicaţiei sunt PHP pentru generarea dinamică

paginilor XHTML şi interogarea bazelor de date , şi MySql pentru gestionarea bazelor de

date, totul rulând pe suportul oferit de serverul Apache.

Realizarea acestui site presupune utilizarea unei baze de date care să conţină atât date

despre utilizatori cât şi date despre produsele puse în vânzare şi date despre comenzile

efectuate de către utilizatori. Baza de date va conţine şapte tabele cuprinzând informaţiile

necesare bunei funcţionări a aplicaţiei.

5.1 Cerinţe hardware

Aplicaţia nu necesită componente hardware performante.

Cerinţele hardware pentru server sunt:

Procesor Pentium IV 2600 MHz

Memorie RAM 512 Mb

Hard Disk 120 Gb

Minimul cerinţelor hardware pentru utilizatori consta in:

Procesor Pentium III (AMD Athlon), 800 MHz

Memorie RAM 128 Mb

5.2 Cerinţe software

Cerinţele software pentru aplicaţie sunt:

Pentru server:

Wampserver 5, versiunea 1.6.4

Un editor PHP

Pentru client:

Internet Explorer 5.0 si versiunile următoare sau Mozilla Firefox 1.0.7

5.3 Funcţionalităţile aplicaţiei

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

deschizându-se un formular predefinit unde se pot efectua schimbările 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 cumpăra. Produsele alese vor fi

adăugate într-un coş de cumpărături acestea putând fi comandate. La trimiterea comenzii

datele utilizatorului şi produsele comandate sunt reţinute în baza de date.

Pagina 80 din 97


Se poate de asemenea efectua o căutare după nume a produselor, fiind afişate

rezultatele căutării în baza de date.

5.4 Proiectarea bazei de date

Baza de date conţine şapte tabele.

Tabela Utilizatori conţine informaţii despre utilizatorii înregistraţi în sistem.

Tabela Itemi reţine datele despre produsele oferite la vânzare.

În tabela Caracteristici sunt reţinute caracteristicile fiecărui produs din tabela Itemi

În tabela Categorii sunt stocate datele categoriilor definite pentru ierarhia produselor.

În tabela Coş sunt reţinute produsele pe care un utilizator logat doreşte să le comande

la un moment dat. După trimiterea comenzii sau la ieşirea din cont înregistrările din această

tabelă sunt şterse.

Tabela Comenzi conţine informaţii despre toate comenzile efectuate de către

utilizatori.

Tabela Itemi_Comanda stochează datele despre produsele comandate.

Structura bazei de date este descrisă în schema conceptuală următoare:

Schema fizică a bazei de date se prezintă astfel:

Pagina 81 din 97


Itemi Tip Nul Setare de bază Setări extra Cheie

Pagina 82 din 97

Utilizatori

Câmp

Tip N

ul

Setare de bază Setări extra Cheie

id int(11) D

a

NULL Auto_incremen

t

primară

utilizator char(60) D

a

-

parola char(60) D

a

-

nume char(30) D

a

-

prenume char(30) D

a

-

cnp varchar(13) D

a

-

varsta char(3) D

a

-

email varchar(50) D

a

-

telefon varchar(25) D

a

-

adresa varchar(255

)

D

a

-

sector varchar(2) D

a

-

cod_post

al

varchar(10) D

a

-

oras char(30) D

a

-

judet varchar(25) D

a

-


Câmp

item_id int(11) Da NULL Auto_increment Primara

cat_id int(11) Da -

nume_item varchar(75) Da -

Prêt float(8,2) Da -

descriere varchar(200) Da -

imagine varchar(50) Da -

Caracteristici

Câmp

Tip Nul Setare de

bază

Setări extra Cheie

Id_item int(11) Da -

producator varchar(25) Da -

Model varchar(25) Da -

Categorii

Câmp

Tip Nul Setare de bază Setări extra Cheie

cat_id int(11) Da NULL Auto_increment primară

nume_cat varchar(50) Da -

desc_cat varchar(200) Da -

Coş

Câmp


Id int(11) Da NULL Auto_increment primara

Id_sesiune char(60) Da -

Id_item_v int(11) Da -

Cant int(11) Da -

producator varchar(25) Da -

Model varchar(25) Da -

data_ad datetime Da -

Comenzi

Câmp

Tip Nul Setare de

bază

Setări extra Cheie

id_c Int(11) Da NULL Auto_increment primara

Pagina 83 din 97


data_c datetime Da -

Nume_c varchar(100) Da -

adresa varchar(255) Da -

Oras varchar(50) Da -

cod_postal varchar(10) Da -

Judet varchar(25) Da -

sector varchar(2) Da -

valoare float(8,2) Da -

mod_plata varchar(20) Da -

Status enum('procesata',

'asteptare')

Da -

Itemi_comanda

Câmp


Id int(11) Da NULL Auto_increment primară

Id_comanda int(11) Da

Id_item int(11) Da

Cant int(11) Da

producator varchar(25) Da

Model varchar(25) Da

Prêt float(8,2) Da

5.5 Implementarea codului

După crearea bazei de date, următorul pas este generarea paginilor web ale aplicaţiei

folosind codul HTML/PHP.

Pentru editarea codului am folosit utilitarul PHPEdit versiunea 2.10.0.4616 dezvoltate

de compania WaterProof Software, acest utilitar putând fi descărcat 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 creării scripturilor PHP oferind suport şi pentru

alte limbaje: HTML, CSS, XML, XSLT, Javascript, SQL.

Sistemul complet are două tipuri de componente: fişiere HTML şi fişiere PHP.

Interfaţa aplicaţiei este realizată cu ajutorul paginilor HTLM, iar scripturile PHP gestionează

interacţiunea dintre paginile HTML şi baza de date prin intermediul serverului Apache.

Pagina 84 din 97

http://www.waterproof.fr/

Inregistrare.php

Atunci când un client nou doreşte să achiziţioneze unul din produsele oferite de siteul

„ElectronX” trebuie să îşi creeze mai întâi un cont de utilizare. Clientul trebuie să introducă

datele personale (nume, prenume, CNP, vârsta, 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 deţine o evidenţă a utilizatorilor site-ului. Contul nu va fi

creat dacă nu sunt completate toate câmpurile considerate obligatorii. După inserarea datelor

în tabela Utilizatori se creează şi fişierul clienţi.xml în care sunt stocate toate datele clienţilor

înregistraţi î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'];

$_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'] == ''))

{

Pagina 85 din 97

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>


 

<center>Va multumim. 

Datele au fost introduse cu succes in baza de date. 

Pentru a 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'])."')";

Pagina 86 din 97

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ă existenţa numelui de utilizator în baza de date şi corectitudinea parolei,

şi în caz de eroare, aceasta se semnalează. Autentificarea se realizează prin intermediul

sesiunilor, reţinându-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. 

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

precedenta.

</center>

</body>

</html>';

}

else

{

$cerereSQL = "SELECT * FROM `utilizatori` 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">';

Pagina 87 din 97

}

}

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

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

utilizare. În acest script utilizatorul are la dispoziţie mai multe opţiuni: modificarea datelor

personale, modificarea parolei, sunt afişate toate comenzile trimise de către utilizator, şi poate

accesa unul din link-urile care duc către paginile de prezentare a produselor, afişare a

statisticilor vânzărilor, afişare a coşului de cumpărături sau pentru ieşirea 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 afişa toate produsele din acea categorie, pentru

fiecare dintre acestea afişându-se numele, preţul ş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 ";

Pagina 88 din 97

} 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)) {

$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>

Pagina 89 din 97

</tr>

</table> ";

}

$display_block .= "</ul>";

}

}

}

}

Arataprodus.php

Pagina de afişare a produselor nu face decât sa afişeze toate informaţiile referitoare la

câte un produs. Aceste informaţii sunt introduse automat într-un formular. În acest formular

utilizatorul mai poate să aleagă numărul produselor pe care doreşte să le comande şi apoi

dacă doreşte să-l adauge la coş trebuie să apese pe butonul „Adaugă la coş”.

Aratacos.php

În această pagină este prezentat conţinutul coşului de cumpărături. Produsele existente

în coş sunt afişate într-un tabel, pentru fiecare fiind afişate numele, producătorul, modelul,

preţul, cantitatea, preţul total şi un link pentru scoaterea produsului respectiv din coş. Pe

pagină mai sunt prezente valoarea totală a produselor adăugate în coş şi link-urile către

pagina de afişare a produselor şi către pagina de comandă.

Comanda.php

Pagina de comandă conţine un formular în care sunt afişate numele, prenumele, CNP-

ul utilizatorului, adresa, oraşul, judeţul, aceste câmpuri putând fi modificate în cazul în care

utilizatorul doreşte livrarea comenzii la o altă adresa decât cea din cont şi valoarea totală a

comenzii. La apăsarea 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ă fişierul 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'] = '';

Pagina 90 din 97

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> pentru a te intoarce la pagina

anterioara.</h4></center>

</body>

</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`, `adresa`, `oras`,

`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'])."',

Pagina 91 din 97


'".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'];

$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ă secţiune are drept scop prezentarea modului de interacţionare al utilizatorului

cu aplicaţia.

La accesarea site-ului se va deschide pagina principală unde utilizatorul are doua

posibilităţi:

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 conţine un formular de înscriere.

Pagina 92 din 97


De asemenea pe aceasta pagina, ca de altfel pe toate paginile aplicaţiei, există mai

multe secţiuni:

1. Un meniu cu următoarele link-uri:

Home – face legătura cu pagina principală

Contul meu – deschide pagina de administrare a contului personal

Produse – sunt afişate categoriile şi produsele existente în baza de date

Coşul de cumpărături – conţine produsele adăugate în coş de către utilizator

Statistici vânzări – sunt prezentate vânzările totale şi pe categorii în termen de o

săptămâna şi o lună, precum şi cel mai bine vândute produse din fiecare categorie şi categoria

cu cele mai mari vânzări

Contact – sunt prezentate opţiunile de a lua legătura cu sediul societăţii

Termeni şi condiţii – conţine drepturile şi obligaţiile utilizatorilor si societăţii

Ieşire din cont – dezautentificarea utilizatorului

2. O secţiune de căutare unde utilizatorul poate să introducă unul sau mai multe

cuvinte ce vor fi căutate în baza de date

3. O secţiune în care sunt afişate toate categoriile de produse

4. O secţiune ce conţine un top ale celor mai vândute 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 apăsa

butonul Înregistrează. Astfel se va crea un cont şi se va confirma înregistrarea contului,

afişându-se şi un link către pagina de autentificare. În cazul în care nu mai doreşte înscrierea

va apăsa butonul Resetează pentru a şterge toate informaţiile 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

Pagina 93 din 97


produ

sele, coşul de cumpărături şi va vizualiza comenzile efectuate de el anterior.

În pagina de prezentare a produselor sunt afişate 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 afişa toate produsele din acea categorie, pentru fiecare dintre

acestea afişându-se numele, preţul şi o mică imagine de prezentare.

Pentru a vizualiza un produs se apasă fie pe numele produsului fie pe link-ul

„Cumpără acest produs” şi se va deschide pagina de prezentare a produselor care afişează

toate informaţiile referitoare la câte un produs. Utilizatorul mai poate să aleagă numărul

produselor pe care doreşte să le comande şi apoi dacă doreşte să-l adauge la coş trebuie să

apese pe butonul „Adaugă la coş”.

Pagina 94 din 97


În pagina de vizualizare a coşului de cumpărături este prezentat conţinutul acestuia.

Produsele existente în coş sunt afişate într-un tabel, pentru fiecare fiind afişate numele,

producătorul, modelul, preţul, cantitatea, preţul total şi un link pentru scoaterea produsului

respectiv din coş. Pe pagină mai sunt afişate valoarea totală a produselor adăugate în coş şi

link-urile către pagina de afişare a produselor şi către pagina de comandă.

Pagina 95 din 97


Pentru a comanda produsele din cont se apasă butonul de comanda şi se va deschide

pagina de comandă în care sunt afişate numele, prenumele, CNP-ul utilizatorului, adresa,

oraşul, judeţul, aceste câmpuri putând fi modificate de către utilizator dacă acesta doreşte

livrarea la altă adresă şi valoarea totală a comenzii şi apoi va apăsa pe butonul „Trimite

Comanda” după care utilizatorul va primi confirmarea înregistrării comenzii.

5.7 Concluzii

Odată cu începuturile Internetului un nou tip de afacere s-a profilat din ce în ce mai

pronunţat pe plan internaţional: comerţul online. Au apărut nenumărate site-uri şi firme care

se ocupă cu vânzările en-gros de produse prin Internet, cu furnizarea accesului contracost la

pagini cu informaţii, într-un cuvânt abordează o formă sau alta de comerţ electronic, un

domeniu aflat în plină expansiune. Avantajul comerţului online este evident: piaţa pe Internet

creşte exponenţial de la un an la altul. Un site bine lucrat, cunoscut şi care oferă produse de

calitate la preţuri bune va avea mai mulţi vizitatori, mai motivaţi şi mai înzestraţi financiar

decât multe magazine convenţionale.

Având în vedere proiectarea, implementarea şi testarea acestui tip de aplicaţii

resursele de hardware, software, de timp, cele umane şi cele materiale sunt reduse, şi în

acelaşi timp această aplicaţie are un potenţial mare de succes.

Pagina 96 din 97


Aplicaţia „ElectronX” are ca scop prezentarea unui model de magazin virtual care să

conţină funcţionalităţile de bază specifice unei aplicaţii de acest gen: gestionarea conturilor

unui utilizator, prezentarea categoriilor şi produselor, căutarea în baza de date, adăugarea

produselor într-un coş de cumpărături, trimiterea comenzilor. Aceste funcţionalităţi pot fi

îmbunătăţite şi de asemenea pot fi adăugate şi altele atât la nivelul aspectului interfeţei cât şi

la nivelul operaţiilor ce pot fi efectuate astfel încât să asigure o funcţionare optimă a site-ului.

Dezvoltarea fără precedent din ultimele două decenii a tehnologiilor informaţionale

determinate de necesitatea stocării şi a transmiterii rapide a informaţiilor cu cele mai mici

costuri, a revoluţionat comerţul global, comerţul direct sau cu amănuntul.

Pagina 97 din 97

http://www.tocilar.ro/

utilizarea xml in baze de date

Documents