of 97
Utilizarea XML in baze de date
Utilizarea XML in baze de date
INTRODUCERE
Formatul de date XML devine formatul comun acceptat n industrie pentru schimbul de informaii dintre diverse sisteme eterogene. Din acest motiv, este important ca o baz de date s fie capabil s stocheze informaiile nu doar n formatele tradiionale, relaionale, ci i n format XML. Stocnd datele XML n format nativ se ctig foarte mult n performan, aceasta materializndu-se n costuri reduse. Un plus de performan la o tehnologie de baze de date nseamn o infrastructur redus, servere cu mai puine procesoare, deci un sistem informatic ceva mai ieftin, costuri mai mici pentru liceniere, deci per total o economie de bani.
Standardul industrial al datelor n format XML prezint o serie de avantaje i dezavantaje. Avantajul major este acela c este adoptat de toi productorii de tehnologie din industrie, dar n schimb are dezavantajul c este un format nu foarte eficient din punct de vedere al stocrii datelor. De aceea devine foarte util ca baza care stocheaz aceste date sa aib capabiliti de compresie, care s duc la scderea spaiului i resurselor de stocare necesare pentru a pstra date n format XML.
Lucrarea de fa i propune s prezinte n capitolele sale cteva noi direcii de dezvoltare n domeniul bazelor de date, modelul de date semistructurat i tehnologia XML ca o nou baz de date.
Capitolul I prezint necesitatea apariiei modelului semistructurat al datelor, datorit nevoii de interogare a unor surse de date care nu au o schem predefinit sau a unor date care provin din surse diferite i au scheme diferite. Modelul semistructurat al datelor reprezint schema (tipul, structura) i instana (valoarea) datelor n mod uniform, permind interogarea lor simultan spre deosebire de modelele de date convenionale, care difereniaz ntre cele dou tipuri de informaie.
Capitolul II detaliaz modelul semistructurat al datelor definind conceptul de date neconvenionale din mai multe perspective i pe cel de date semistructurate prezentnd avantajele acestui tip de date, modelarea acestor date i limbajele de interogare a acestora, i prezint n detaliu tipul de date MPEG-21 ca suport pentru integrarea datelor n aplicaii multimedia distribuite.
Capitolul III prezint legtura dintre tehnologia XML i bazele de date ncercnd s clarifice n ce msur este XML-ul o baz de date, reprezentarea datelor i documentelor, stocarea i recuperarea datelor, stocarea datelor n baze de date native XML, generarea schemelor XML din scheme relaionale i invers, stocarea documentelor n sistemul de fiiere i n BLOB-uri, detaliaz bazele de date native XML, i prezint noiunile de DOM (Document Object Model) persistent i sisteme de management ale coninuturilor.
Capitolul IV se ocup de construirea documentelor XML prezentnd sintaxa XML, descrierea de vocabulare noi cu XML, avantajele definiiei tipurilor documentului, combaterea dezavantajelor definiiei tipurilor documentului, definirea unui document XML ca ntreg, declaraia XML, documentele autonome, construirea unui document XML, declaraia tipului documentului i prezint cteva aplicaii din lumea real a declaraiei tipului documentului.
Capitolul V const n prezentarea aplicaiei magazinul virtual ElectronX - i prezint scopul acestei aplicaii, cerinele minime hardware i software ale aplicaiei, funcionalitile de baz ale acestui website, proiectarea bazei de date coninnd schema conceptual a structurii bazei i schema fizic a fiecrei tabele, implementarea codului n care sunt explicate fiierele cele mai importante ale aplicaiei cu exemplificri din codul surs, un manual de utilizare al aplicaiei n care e descris modul de funcionare al acesteia i concluzii asupra aplicaiei.
CAPITOLUL I
NOI MODELE DE DATE I APLICAIILE LOR
1.1 Interogarea World-Wide-Web-ului
Exist surse de date, ca de pild World-Wide-Web-ul, pe care am dori s le interogm ca baze de date, dar care nu pot fi constrnse de o schem. Majoritatea interogrilor web-ului folosesc tehnici de regsire a informaiei pentru a gsi pagini dup coninut. Exist ns puine posibiliti de formulare a interogrilor n vederea exploatrii structurii web-ului i, deoarece aceasta nu este conform cu nici un model de date standard, este necesar o metod de descriere a acestei structuri.
Modelul de date semistructurat a fost propus n vederea satisfacerii acestei necesiti. Ideea central n modelul semistructurat este de a reprezenta datele sub forma unui graf etichetat. Structura documentelor hipertext este capturat interpretnd arcele grafului drept legturi. O reprezentare posibil este cea introdus n proiectul UnQL[1]. Etichetele arcurilor pot fi att valori (de tip ntreg, ir de caractere i alte tipuri de baz, precum i de tip de date abstract, ca video, audio, etc.) ct i nume de atribute (Film, Titlu, Regizor, Actor), etc. modelnd de exemplu cunoscuta baz de date cinematografic IMDB [2].
Exist numeroase limbaje de interogare pentru modelul semistructurat. Toate aceste limbaje sunt construite pe baza ideii de expresii asociate cilor (path expressions). Acestea sunt expresii regulate ce exprim ci generice n graful etichetat, permind astfel traversarea grafului i colecionarea tuturor etichetelor ce satisfac o anumit condiie de selecie.
Limbajele semistructurate pot fi clasificate n dou categorii, dup strategia de calcul adoptat. Prima categorie, dezvoltat oarecum ad-hoc, se bazeaz pe modelarea grafurilor n modelul relaional i apoi pe interogarea lor ntr-un limbaj relaional de tip SQL. Cteva exemple prezentate n literatur sunt [3], [4], [5], [6], [7]
A doua categorie pornete de la un limbaj bazat pe o noiune formal de calcul cu date semistructurate: limbajul UnQL este reprezentantul acestei categorii [1]. Acest limbaj pornete de la recursivitatea structural, forma natural de recursivitate asociat cu tipul de date grafuri etichetate. Datorit bazei sale teoretice, UnQL este capabil de restructurri complexe, n adncime, spre deosebire de limbajele din prima categorie, care se limiteaz la scoaterea la suprafa a datelor din graf, fr ns a crea noi structuri.
Aceast capacitate de restructurare st la baza proiectului STRUDEL[8] care propune limbajul StruQL de gestiune a sit-urilor de web. Un alt avantaj al bazei teoretice a limbajelor UnQL i StruQL este posibilitatea efecturii optimizrilor specifice acestui nou model de date. Limbajele din prima categorie pot beneficia doar de optimizrile specifice modelului relaional, deci dezvoltate pentru alt model de date i n consecin nu att de folositoare.
1.2 Integrarea surselor de date eterogene
Integrarea datelor provenind din surse eterogene (cu scheme disparate sau, mai grav, modelate diferit), este un domeniu de cercetare care, dei consacrat de mai bine de un deceniu, continu s rmn n centrul ateniei multor cercettori. Cercetarea n acest domeniu este motivat de absena unui model de date atotcuprinztor, fapt ce ngreuneaz dezvoltarea de software care convertete date ntre dou modele diferite.
O complicaie adiional este reprezentat de faptul c majoritatea datelor stocate electronic nu se afl n baze de date convenionale, ci n sisteme de fiiere, programe de bibliotec, de pot electronic, foi de calcul etc., care prezint capaciti de interogare limitate.
Ultima observaie a reprezentat punctul de plecare al proiectului Tsimmis [9][10] de la Stanford. Proiectul Tsimmis i propune integrarea att a surselor de date care sunt conforme cu modelele de date standard (relaional, orientat pe obiecte), ct i a surselor de date cu capaciti de interogare limitate. Aceste surse neconvenionale sunt mpachetate n aa-numii wrappers (ambalaje). Un astfel de ambalaj asigur interfaa ntre sursa de date cu capaciti de interogare limitate i aplicaia care o interogheaz. Aplicaia trimite ctre surs interogri ntr-un limbaj expresiv cum ar fi SQL sau OQL i ateapt rezultatul ntr-un format numit OEM (Object Exchange Model).
OEM folosete grafuri etichetate, ca structur de date, care captureaz majoritatea datelor folosite n aplicaii de baze de date. n acelai timp, toate celelalte structuri de date pot fi codificate ca grafuri OEM.
Rolul ambalajului const n: interceptarea interogrii i identificarea acelor pri ale acesteia care pot fi efectuate de ctre surs, translatarea acestor pri n limbajul specific sursei, recepionarea i prelucrarea rezultatelor intermediare n vederea reconstituirii rezultatului interogrii originale, codificarea rezultatului final n formatul OEM i transmiterea acestuia ctre aplicaie.
Evident, dac interogarea original este prea complex, este posibil s nu poat fi efectuat pornind de la capabilitile limitate ale sursei. Ambalajul detecteaz aceast situaie i anun sursa c nu i poate satisface cererea. Cu ct crete capacitatea de evaluare a interogrilor n cadrul ambalajului (de exemplu, capacitatea de a efectua operaii de tip join, proiecii, selecii, etc.), cu att se extinde clasa de interogri pe care le poate satisface combinaia surs-ambalaj.
Un proiect similar, cu scopul interogrii surselor de date structurate din web este [13].
Se remarc similaritatea dintre modelul OEM i cel semistructurat. ntr-adevr, Lore [11],[12] este un sistem de interogare a datelor semistructurate, foarte similar cu UnQL, utiliznd un model de date inspirat de OEM.
1.3 Navigare n Internet
n anumite situaii este avantajos s privim bazele de date convenionale ca fiind semistructurate. Un exemplu este activitatea de navigare n Internet.
n general, utilizatorul nu poate interoga o baz de date fr a-i cunoate schema. Din nefericire ns, aceasta este adeseori greu de neles, datorit mrimii exagerate (zeci de tabele, de exemplu) i a terminologiei opace, nestandard, folosite de ctre proiectanii bazei de date.
Descifrarea schemei ar fi considerabil uurat de facilitatea de a interoga datele avnd doar o nelegere parial a structurii lor. De exemplu, n cazul bazei de date cinematografice din World-Wide Web[2], urmtoarele interogri ar fi de folos:
n care atribut gsim irul de caractere Casablanca?Exist n baza de date ntregi mai mari dect 216?Ce obiecte din baza de date au un atribut al crui nume ncepe cu act?
i n acest domeniu, modelul semistructurat se dovedete a fi folositor. Spre deosebire de modelele de date convenionale, care difereniaz ntre schema (tipul, structura) i instana (valoarea) datelor, modelul de date semistructurat reprezint cele dou tipuri de informaie n mod uniform, permind interogarea lor simultan. Din acest motiv, datele semi-structurate se numesc i autodescriptive.
[1] prezint un elegant limbaj de interogare care permite exprimarea concis a acestor interogri.
1.4 Cubul de date i OLAP
Sistemele de suport pentru decizii (Decision support systems) sunt utilizate de ctre companiile moderne pentru integrarea ntr-o baz de date central numit data warehouse (magazia central de date), a datelor provenind din baze de date mici operaionale folosite n diferite domenii de activitate/filiale ale companiei.
Datele astfel acumulate sunt analizate n timp real (OLAP: On-Line Analitical Processing) pentru a asista conducerea companiei n luarea deciziilor strategice de dezvoltare [14] (de exemplu, analiznd vnzrile unui anumit produs pe trimestru i zon geografic, se poate stabili o nou strategie de marketing pentru acest produs). Datele din magazia central de date sunt modelate sub forma unui (hiper)cub de date multidimensional [15]) care poate fi analizat la nivelul subcuburilor de granularitate arbitrar. Subcuburile se obin prin agregarea cuburilor din care provin.
De exemplu, prin nsumarea vnzrilor trimestriale pentru fiecare zon, cubul de date tridimensional reprezentnd vnzrile pe trimestru i zona geografic poate fi redus la un subcub bidimensional (plan) reprezentnd vnzrile pe zona geografic. Agregarea este o operaie costisitoare, efectuarea ei eficient pe un volum mare de date reprezentnd elul principal al cercetrii n acest domeniu ([16],[17],[18],[19]).
1.5 Noi modele tranzacionale
n mod tradiional, tranzaciile modeleaz uniti de lucru atomice i izolate, efectuate asupra datelor sistemului de gestiune a bazelor de date.
Izolarea tranzaciilor nu permite crearea tranzaciilor complexe, mari, din tranzacii simple. Acest model a avut succes atta vreme ct tranzaciile efectuau un numr mic de operaii simple asupra datelor cu structur simpl.
Din pcate, modelul tranzaciilor simple nu satisface cerinele aplicaiilor complexe, n care tranzaciile trebuiesc combinate i coordonate pentru a colabora la realizarea unui scop complex. Aplicaii ca proiectarea asistat de calculator, automatizarea activitii de birou, controlul produciei, gestiunea activitilor necesit noi modele tranzacionale, noi metode de gestiune a tranzaciilor, i noi limbaje de specificare a tranzaciilor. Limbajele tranzacionale sunt limbaje de nivel nalt, de obicei inspirate din logica cu predicate de ordinul nti.
Dac limbajele tradiionale specificau interogri i actualizri, noile limbaje tranzacionale se concentreaz asupra relaiei dintre tranzacii, exprimnd dependene de tipul tranzacia T2 nu poate porni nainte ca T1 s se termine, sau T2 poate ncepe dac T1 ntoarce o valoare mai mare ca 25. [20] prezint o clasificare i analiza detailat a noilor limbaje tranzacionale.
Un excelent exponent al noii generaii de limbaje tranzacionale este Transaction Datalog [21], un limbaj deductiv care menine n acelai timp toate proprietile tranzaciilor clasice, cum ar fi: persisten, atomicitate, izolare, terminare i rollback (revenire).Limbajul este nsoit de un model teoretic natural i de o teorie sigur pentru demonstraii, permind astfel demonstrarea echivalenei ntre diverse expresii din acest limbaj. Acest fapt este crucial pentru optimizare - care const din nlocuirea unei planificri cu o alta echivalent din punct de vedere al efectului su asupra datelor, dar mai eficient din punct de vedere al costului execuiei. Mai mult, faptul c putem demonstra c efectul unei tranzacii complexe asupra setului de date este sau nu cel scontat, asigur consistena datelor.
1.6 Optimizri
Optimizarea limbajelor de interogare a bazelor de date nu este un domeniu nou, ci dimpotriv, exist nc de la apariia acestora. Datorit importanei sale, acest domeniu va fi ntotdeauna la mod n cercetarea bazelor de date.
Apariia unui nou model de date atrage dup sine o efervescen n activitatea de cercetare a posibilitilor de optimizare a limbajului de interogare asociat noului model. Referinele bibliografice introduse n seciunea anterioar prezint i primele ncercri de optimizare a noilor limbaje de interogare.
CAPITOLUL IIMODELE DE REPREZENTARE A DATELOR NECONVENIONALE
2.1 Definirea conceptului de date neconvenionale
n literatura de specialitate exist o serie de definiri ale conceptului de date neconvenionale i a altor concepte asociate acestuia:
Datele neconvenionale sunt datele care nu au nici unul din tipurile standard: ntreg, real etc. [Blanken, 2002]
Structura de date neconvenional este structura de date care nu este n uzul curent al aplicaiilor; aceasta poate fi structura produs de datele semistructurate, cea definit noilor tipuri de date folosite n aplicaii i date cu structuri ce se modific n mod dinamic. [GSIHT, 2005]
A patra generaie a tehnologiilor bazelor de date este prezentat n [Mannino, 2004] ca fiind o extensie a tehnologiilor bazelor de date cu datele neconvenionale i Internetul. Sistemele celei de-a patra generaii pot stoca i manipula tipuri de date neconvenionale cum sunt: imaginile, secvenele video, hrile, sunetele i animaiile i permit accesul la bazele de date Web.
Unul din obiectivele sistemelor de gestiune a bazelor de date orientate obiect este prezentat ca fiind extinderea flexibilitii cu datele neconvenionale i procedurile de prelucrare asociate acestora, inclusiv text, grafic i voce, date care nu pot fi manipulate i integrate de sistemele de baze de date convenionale.
La University of Southern California din Los Angeles (USC) exist un laborator de informare numit InfoLAB al crui scop este investigarea de noi metode pentru gestiunea tipurilor de date neconvenionale cu arhitecturi atipice. Principalele zone de cercetare sunt:
Gestiunea fluxurilor de date multidimensionale n arhitecturi de tip punct la punct (peer-to-peer),
Analiza datelor multidimensionale,
Gestiunea datelor peer-to-peer,
Prelucrarea interogrilor de stream-uri,
Baze de date spaio-temporale.
Descrierea datelor neconvenionale se realizeaz folosind metadate. Metadatele sunt folosite pentru descrierea altor date, cu o structur complex sau nestructurate. Metadatele pot fi privite din diferite perspective, n funcie de productorul sau sursa metadatelor:
- Din perspectiva productorului de coninut, metadatele sunt utilizate pentru stocarea informaiilor bibliografice ale resurselor, ca de exemplu: numele autorului, titlul, data crerii, formatul resursei etc.
- Din perspectiva furnizorilor de servicii, metadatele ofer informaii descriptive cu valoare adugat (majoritatea n format XML), care reduc informaiile necesare regsirii datelor. Metadatele conin informaii despre diferitele formate n care este disponibil o resurs i informaii semantice asociate acesteia. Aceste informaii sunt utile pentru realizarea interogrii datelor.
- Din perspectiva consumatorului, metadatele ofer informaii suplimentare care descriu preferinele consumatorului i resursele disponibile pentru utilizarea datelor. Metadatele permit personalizarea consumului mediilor i trebuie luate n considerare de productori. Metadatele sunt utile pentru distribuirea datelor n Internet sau n reele mobile permind accesul la resurse n cele mai bune condiii posibile; de exemplu, metadatele pot fi folosite pentru descrierea modului n care difuzarea secvenelor video este adaptat la scderea lrgimii de band disponibil la un moment dat.
2.2 Modelul semistructurat ale datelor
Modelele relaional i orientat-obiect au fost folosite mult timp pentru modelarea datelor nu neaprat pentru c erau cele mai naturale soluii, ci pentru c au n spate un formalism bine definit. n timp ns, datorit dezvoltrii Internetului i datorit necesitii integrrii datelor descrise folosind scheme diferite, modelele tradiionale s-au dovedit a nu mai fi suficiente i a devenit acut necesitatea utilizrii unui alt model de date, modelul semistructurat al datelor.
n plus, aplicaiile Internet realizeaz operaii care nu sunt curente n aplicaiile tradiionale cu baze de date cum ar fi: transformri ale datelor, interpretarea interogrilor, transportul datelor i prelucrarea bazat pe fluxuri.
Datele semistructurate au devenit un important subiect de studiu din mai multe motive:
n primul rnd, exist surse de date pe care am vrea s le tratm ca baze de date dar crora nu le putem impune constrngeri avnd la baz o schem, ca n cazul bazelor de date tradiionale [Buneman, 1997]. Chiar i datele structurate, au structur care poate s difere de la o aplicaie la alta sau au structur modificabil n timp. Dezvoltrile din domeniul multimediei au dus la necesitatea de a introduce noi tipuri de date n domeniul tehnologiei bazelor de date convenionale. Unele tehnologii necesit doar extensii ale modelelor de date existente, prin optimizarea tehnicilor de manipulare i interogare a noilor tipuri de date, dar 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 interogrilor Web exploateaz tehnicile de regsire a datelor pentru a determina paginile individuale care au coninut ce corespunde criteriului solicitat. Dar numai o mic parte din resursele Web sunt structurate astfel nct s permit rezolvarea interogrilor, Web-ul nefiind conform nici unui model standard. Astfel c se simte nevoia de a gsi o metod pentru descrierea structurii datelor Web n vederea rezolvrii acestei probleme.
Al doilea motiv este dat de necesitatea schimbului de date ntre aplicaii care folosesc formate diferite de stocare i gestiune a datelor necesitnd astfel transformarea datelor. Nici unul din modelele de date existente nu este acceptabil din toate punctele de vedere i n plus este dificil s convertim datele dintr-un model n altul. Astfel, s-a simit nevoia s se dezvolte un model care s lege cele dou lumi diferite: relaional i orientat obiect, acesta este modelul semistructurat al datelor.
n plus, datele n format electronic se afl n medii diferite, interconectate care trebuie s comunice ntre ele. Dar i cnd se folosesc datele structurate poate fi util ca acestea s fie privite ca date semistructurate, din motive care in de manipularea acestora, fiind util s existe un format flexibil pentru schimbul de date ntre diferite tipuri de baze de date. [Buneman, 1997]
O parte din aceste date se gsesc sub forma datelor nestructurate, ca de exemplu sunetele, imaginile, secvenele video i chiar unele documente text, iar alt parte sub forma datelor structurate, memorate n baze de date relaionale sau orientate obiect. n general, un utilizator nu poate scrie o interogare pentru o baz de date fr s cunoasc schema de organizare a datelor, iar aceasta este netransparent pentru utilizatori i raionamentul folosit la proiectarea ei este adesea greu de determinat. Au fost dezvoltate limbaje care permit interogarea simultan a datelor i a schemelor de organizare a bazelor de date, dar aceste limbaje nu au flexibilitatea s manipuleze constrngeri complexe.
2.2.1 Conceptul de date semistructurate
n general, prin termenul de date semistructurate sunt denumite datele care nu respect formate stricte cum ar fi cele impuse de modelele bazelor de date relaionale sau orientate obiect. n mod evident o astfel de definiie este imprecis. Datele sunt semistructurate dac: nu au o structur rigid (de exemplu datele Web, datele sunt combinate din cteva surse eterogene - ca n cazul depozitelor de date), nu au o structur implicit asociat datelor, sau au o structur parial specificat [Abiteboul, 1997]. Modelele orientat-obiect i relaional au o schem fix pentru fiecare clas sau fiecare relaie. Datele semistructurate permit o flexibilitate sporit, fiind o combinaie a celor dou concepte: clasa i relaia.
Datele semistructurate conin informaii despre schema lor i aceast schem poate diferi, n timp, n cadrul unei singure baze de date. Acest model care nu se bazeaz pe nici o schem, are un rol special n sistemele bazelor de date.
n acest model datele sunt autoreferite, acest lucru nsemnnd c schema este ataat datelor. Combinarea unor date dintr-o baz de date relaional cu altele dintr-o baz de date orientat-obiect se poate realiza prin conectarea celor dou baze de date, prin intermediul unei interfee, translatnd datele de la fiecare surs n date semistructurate.
n modelul semistructurat al datelor, informaiile care sunt n mod normal asociate unei scheme sunt incluse n interiorul datelor. n aceste baze de date nu exist o distincie clar ntre date i schem, iar gradul de structurare depinde de aplicaie. n anumite forme ale modelului semistructurat exist o schem distinct, n altele nu.
Avantajele modelului semistructurat al datelor sunt urmtoarele:
Flexibilitatea - simplific integrarea bazelor de date care au scheme diferite. Spre deosebire de alte modele, care au o schem de descriere a datelor, modelul semistructurat este fr schem, ceea ce justific flexibilitatea sa. Flexibilitatea reprezint un instrument util pentru integrarea datelor, mai ales n cazul problemelor legate de motenirea bazei de date.
mbuntirea eficienei regsirii datelor publicate n Internet
Posibilitatea integrrii datelor
Documentele HTML i cele stocate n biblioteci digitale sunt semistructurate. Spre deosebire de fluxurile nestructurate de date (precum imagini, sunete, video), datele semistructurate au o structur i spre deosebire de datele structurate (bazele de date relaionale sau orientate-obiect), datele semistructurate nu au o schem absolut sau o clas fix, fiecare obiect coninnd propria schem. Iregularitatea structural nu implic inexistena similaritilor structurale ntre obiecte. Din contr, n mod obinuit, obiectele semistructurate care descriu acelai tip de date au structur similar.
Modelul datelor semistructurate este un model pentru integrarea bazelor de date. Este folosit pentru descrierea datelor aflate n dou sau mai multe baze de date care conin date similare n diferite scheme de organizare.
2.2.2 Modelarea datelor semistructurate
Datele semistructurate sunt modelate, n general, sub forma structurilor de tip graf sau arbore, n noduri avnd reprezentate obiecte iar arcele reprezentnd atributele obiectelor. n plus, arcele modeleaz natural relaiile de subordonare dintre dou obiecte. [Reveiu, 2003]
Modelul de facto pentru datele semistructurate este OEM (Object Exchange Model), model propus n proiectul pentru integrarea datelor numit TSIMMIS i descris pentru prima dat n lucrarea Multimedia database systems Design and implementation Strategies. OEM este un model autodescriptibil, nefiind necesar definirea anterioar a structurii unui obiect i nici nu exist o schem fix de reprezentare a datelor. Fiecare obiect reprezentat conine propria lui schem.
Fiecare obiect din OEM poate avea un identificator (Id), o etichet, un tip i o valoare. Id-urile obiectelor pot fi simboluri cu sau fr nelesuri speciale. De exemplu, dac un obiect este o pagin Web, URL-ul paginii poate fi folosit ca id-ul obiectului. Etichetele nodurilor sunt iruri care expliciteaz rolul obiectului pentru utilizator i pentru aplicaii. Eticheta joac aici dou roluri: identific un obiect i d sens obiectului. Obiectele pot fi atomice sau complexe (seturi de obiecte). Valorile obiectelor atomice au tipuri atomice (valori ntregi, reale, iruri de caractere, imagine, sunet etc.), iar cele complexe au ca valori seturi de obiecte, reprezentate prin perechi de tipul atribut-obiect. Prin urmare, un obiect complex va avea o definire recursiv deoarece valoarea unui obiect este parte a sa. Nodurile frunz au asociate ntotdeauna valori atomice.
Etichetele arcelor reprezint atribute, sunt descrise prin iruri de caractere i reprezint un set de proprieti descriptive. O proprietate poate fi folosit ntr-un arc pentru a descrie nodurile nvecinate.
n figura 1 este prezentat exemplificarea modelrii unei pri dintr-o baz de date multimedia folosind OEM.
Figura 1 Modelul OEM al unei pri dintr-o baz de date multimedia
Informaii: &o1
{film: &o21
{titlu: &o30 Titanic,
actor principal: &o31
{nume: &o41 DiCaprio,
prenume: &o42 Leonadro},
regizor: &o32
{nume: &44 Cameron,
prenume: &o45 James},
{ actor principal: &o33,
nume: &o46 Kate,
prenume: &o47 Winslet},
premii obinute: &o48 11 Oscaruri},
melodie: &o22
{titlu: &49 My heart will go on,
interpret: &o34
{nume: &o50 Dion,
prenume: &o51 Celine},
premii: & o35
{an: &o52 1998,
nume: Oscar pentru cea mai bun coloan sonor},
coloan sonor: &o22}}
Datele stocate n baze de date relaionale pot fi descrise cu uurin folosind OEM. n plus, OEM asigur o flexibilitate mai mare n descrierea datelor tolernd lipsa unor atribute pentru anumite nregistrri sau existena mai multor valori pentru acelai atribut n cadrul unei singure nregistrri.
OEM poate fi considerat mai apropiat de modelul orientat-obiect dect de cel relaional, n care dou obiecte distincte chiar dac au valori identice, au existen de sine stttoare, reprezentnd instane diferite.
Scheme de organizare a datelor semistructurate
Flexibilitatea n descrierea informaiilor adus de modelarea datelor semistructurate are i dezavantaje, i anume dificultatea formulrii unei interogri relevante. S-a ncercat asocierea unor scheme n modelarea datelor semistructurate, n acest sens existnd dou abordri:
scheme flexibile descriu aprioric datele; schemele flexibile fiind concepute astfel nct s permit flexibilitate n descrierea datelor; se folosete tipul void pentru manipularea oricrui tip de dat.
scheme rigide descriu cu exactitate datele i sunt folosite pentru analiza datelor; schema este refcut ori de cte ori se produce o modificare a informaiei memorate.
2.2.3 Limbaje de interogare a datelor semistructurate
Principalele elemente caracteristice ale unui limbaj de interogare pentru datele semistructurate sunt:
Putere de expresie: pentru reprezentarea datelor relaionale sub forma datelor semistructurate, limbajul semistructurat trebuie s acopere operaiile corespunztoare unui limbaj relaional standard, dar n plus trebuie s dispun de faciliti de reorganizare a datelor, astfel nct aceeai informaie s poat fi regsit sub o alt structur;
Semantic: cererile trebuie optimizate astfel nct s poat ine cont de semantica datelor, fiind necesar o semantic precis pentru transformarea i optimizarea cererilor;
Schematizare: limbajul trebuie s poat recunoate structurile definite pentru a le putea manipula;
Compunere: datele obinute n urma unei interogri pot fi folosite ca date de intrare n alte interogri, motiv pentru care limbajele trebuie s fie transparente.
Au fost propuse, ntr-o serie de proiecte de cercetare pe aceast tem, cteva limbaje de interogare pentru datele semistructurate. Dou dintre acestea sunt: limbajul orientat-obiect Lorel, derivat din OQL (Object Query Language) i limbajul UnQL (Unstructured Query Language).
Domeniul datelor semistructurate este unul n studiu i va avea un impact mare asupra unei multitudini de aplicaii, dar mai ales asupra aplicaiilor multimedia i a celor dezvoltate pentru mediul Internet.
2.3 MPEG-21 Suport pentru integrarea datelor n aplicaii multimedia distribuite
n ciuda descrierilor complete i detaliate ale tipurilor datelor multimedia implementate n MPEG-7, aspecte legate de organizarea datelor i de infrastructura unui sistem multimedia distribuit nu pot fi descrise doar folosind metadate. Astfel c a fost iniiat un nou standard, MPEG-21 cu scopul de a oferi mecanisme de proiectare a sistemelor multimedia distribuite, de a crea un mediu unic, universal accesibil pentru livrarea i utilizarea resurselor multimedia n diferite condiii, ca de exemplu diferite tipuri de utilizatori, reele cu diferite caracteristici, terminale cu caracteristici diferite etc.
2.3.1 Prezentare general
MPEG-21 este un standard ISO/IEC21000 al MPEG (Moving Picture Experts Group) care definete un cadru de lucru deschis pentru multimedia. Fora MPEG-21 este dat de urmtoarea situaie: exist multe resurse mutimedia ce pot fi folosite la construirea unei infrastructuri pentru distribuirea i utilizarea coninutului multimedia, dar nu exist nici o arhitectur pentru descrierea modului n care aceste elemente interacioneaz ntre ele. Scopul standardului MPEG-21 este s defineasc un cadru de lucru deschis pentru multimedia care s permit utilizarea transparent i la performane bune a resurselor multimedia folosind reele i dispozitive periferice diverse. Se urmrete gestiunea coninutului multimedia, gestiunea proprietii intelectuale i adaptarea coninutului la resursele disponibile prin intermediul diferitelor clase de servicii. MPEG-21 ofer un suport deschis pentru distribuirea i utilizarea datelor multimedia. [Kosch, 2004]
MPEG acoper ntregul coninut multimedia din punctul de vedere al canalelor de distribuie folosite, al modalitilor de creare a coninutului, din punct de vedere al modalitii de producie, n vederea personalizrii, consumului, prezentrii i comercializrii acestuia. Pentru realizarea acestui lucru, MPEG-21 propune norme pentru un standard deschis pentru crearea, distribuirea i utilizarea datelor multimedia. Acest standard se refer la toi actorii implicai, de la creatorii de coninut, productori, distribuitori i furnizorii de servicii.
MPEG-21 standardizeaz fluxul informaiilor i serviciilor multimedia de la crearea coninutului pn la livrarea ctre utilizatorii finali. Pentru a realiza acest lucru, coninutul trebuie identificat, descris, gestionat i protejat. Transportul i livrarea coninutului poate avea loc peste diferite reele, ntre o varietate de terminale.
Exist o serie de arhitecturi aprute ca rspuns la varietatea tipurilor de aplicaii care utilizeaz coninutul multimedia. Exist trei modele principale folosite pentru gestiunea, descrierea i regsirea resurselor multimedia i anume Dublin Core, SMPTE i MPEG-7. Pentru a evita recomandarea unui model n defavoarea altuia, n mod nejustificat, MPEG-21 propune descrierea suportului multimedia sub forma unei arhitecturi generice. [ISO, 2001]
MPEG-21 se bazeaz pe dou concepte eseniale: definirea unei uniti fundamentale de distribuie i tranzacionare - elementul digital i utilizatorii care interacioneaz cu elementele digitale. Elementul digital este un obiect digital, structurat care are o reprezentare standard, ce poate fi identificat i care are asociate metadate. Elementele digitale conin att resursele multimedia (coninutul) ct i metadatele asociate resurselor sau ntregului element digital. n accepiunea MPEG-21, utilizatorul este orice entitate care interacioneaz cu mediul MPEG-21 sau care folosete un element digital, ca de exemplu un consumator al datelor multimedia, o organizaie, sau un alt standard ce folosete resursele multimedia. Un utilizator poate folosi coninutul n mai multe feluri: prin publicare sau prin livrare i poate avea drepturi i responsabiliti specifice n funcie de modalitile de interaciune cu ali utilizatori n cadrul MPEG-21.
Principalele elementele folosite n definirea arhitecturii MPEG-21 sunt:
Elementul digital - este un container ierarhic de resurse eterogene (video, audio, text etc.), metadate i alte elemente digitale. Un element digital este o unitate elementar de distribuie i tranzacionare;
Declararea elementului digital definete un set de termeni folosii la declararea elementelor digitale;
Identificarea i descrierea elementului digital presupune identificarea i descrierea elementului digital, natura lui, tipul sau granularitatea (film, scen sau cadru);
Gestiunea i utilizarea coninutului ofer interfee i protocoale care permit crearea, manipularea, cutarea, accesarea, stocarea, livrarea i reutilizarea coninutului de-a lungul canalelor de distribuie i consum;
Protejarea i gestiunea proprietii intelectuale permite gestiunea coninutului i protejarea elementelor digitale ntr-o serie de reele i dispozitive;
Terminale i reele ofer instrumente ce permit accesul transparent la coninut prin intermediul reelelor i terminalelor, realiznd inclusiv controlul calitii serviciului;
Reprezentarea coninutului cum sunt reprezentate resursele media;
Raportarea evenimentelor conine metrici i interfee ce permit utilizatorilor s evalueze performanele tuturor evenimentelor raportabile din cadrul sistemului.
Structura MPEG-21
n prezent sunt definite 18 pri ale MPEG-21: [ISO/IEC 21000-1-18] :
Partea 1: Tehnologiile i strategia MPEG-21,
Partea 2: Declararea elementului digital (DID)
Partea 3: Identificarea elementului digital (DII)
Partea 4: Gestiunea i protecia proprietii intelectuale (IPMP)
Partea 5: Limbajul de reprezentare a drepturilor (REL)
Partea 6: Dicionar de drepturi ale datelor (RDD)
Partea 7: Adaptarea elementului digital (DIA),
Partea 8: Software de referin
Partea 9: Formate de fiiere pentru stocarea i regsirea elementelor digitale ale MPEG-21
Partea 10: Prelucrarea elementelor digitale
Partea 11: Asocieri persistente
Partea 12: Testare distribuirii resurselor MPEG-21
Partea 13: Codarea secvenelor video scalabile
Partea 14: Conformana
Partea 15: Raportarea evenimentelor
Partea 16: Formatul binar
Partea 17: Identificarea fragmentelor
Partea 18: Streaming-ul elementului digital
2.3.2 Declararea elementelor digitale
Declararea elementului digital presupune definirea unui set de termeni i concepte folosite la definirea elementelor digitale, la descrierea sintaxei i semanticii fiecrui element digital i a schemei de reprezentare n XML.
Declararea unui element digital se realizeaz n 3 etape:
- Crearea modelului abstract,
- Reprezentarea modelului abstract n XML,
- Crearea schemei XML.
Modelul abstract definete un set de termeni i concepte care formeaz un model pentru declararea elementelor digitale. Modelul abstract permite reprezentarea elementelor digitale n diferite moduri. Modelul abstract definete entitile necesare declarrii elementului digital.
Un prim set de entiti este format din elementele de baz folosite pentru declararea elementelor digitale:
- resursa este un flux de date identificabil, ca de exemplu un fiier video, imagine, secven audio sau text.
- componenta are rolul de a lega una sau mai multe resurse de un set de descriptori ce conin informaii secundare referitoare la resursele componentei. Componenta este folosit doar pentru gruparea resurselor i a datelor secundare transmise printr-un descriptor.
- elementul digital reprezint conectarea unuia sau mai multor elemente sau componente la un descriptor. Se pot crea elemente digitale individuale i elemente compuse.
- descriptorul introduce un mecanism extensibil care poate fi folosit pentru asocierea informaiilor cu alte entiti ale modelului abstract. Un descriptor asociaz informaii textuale, secundare entitii incluse.
- containerul reprezint asocierea unuia sau mai multor elemente digitale i/sau container(e) la un descriptor. Containerele sunt folosite pentru gruparea elementelor digitale. Descriptorul conine informaii despre containerul reprezentat.
Pentru rafinarea descrierii resurselor se folosete urmtorul set de entiti:
- fragmentul identific un anumit punct sau interval din cadrul unei resurse (secven video, audio etc.). Fragmentele sunt specifice tipului resursei.
- ancora conecteaz descriptori de un fragment. n acest caz, descriptorii conin informaii despre fragmentele ancorei. Ancora este folosit pentru gruparea fragmentelor i descriptorilor. Exemplu de ancor: un moment de timp al unei resurse video, o form poligonal din cadrul unei resurse de tip imagine.
- adnotarea permite adugarea de informaii la o entitate a modelului fr a modifica entitatea.
- alternativa este o opiune din mai multe existente; ca de exemplu, alternativa unei conexiuni la Internet la o lrgime de band mare sau alternativa unei conexiuni prin dial-up.
- selecia este opiunea utilizatorului din alternativele disponibile.
- condiia pe baza seleciei utilizatorului, pot fi satisfcute (sau nu) condiiile asociate unei entiti a elementului digital i entitatea elementului digital poate deveni disponibil (sau nu).
Reprezentarea modelului abstract n XML presupune descrierea sintaxei XML pentru fiecare entitate definit n modelul abstract. Aceast sintax formeaz limbajul de declarare a elementului digital al MPEG-21 (DIDL Digital Item Declaration). Declararea elementelor digitale reprezentate n conformitate cu sintaxa DIDL formeaz documentul DIDL.
DIDL definete cteva elemente suplimentare care nu corespund entitilor modelului abstract:
- Elementul DIDL ca rdcin a documentului DIDL,
- Elementul Referin - reprezint o legtur la un alt element al documentului DIDL i include coninutul elementul refereniat n elementul referit. Referinele se pot face la elemente din acelai document DIDL sau la elemente din alt document DIDL. O referin intern permite pstrarea unei singure surse pentru un element care apare n documentul DIDL n mai multe locuri. Referina extern permite unui document DIDL s fie mprit n mai multe documente DIDL conectate.
- Elementul Declaraii este folosit pentru definirea elementelor documentului DIDL, fr a le instania. Un element declarat poate fi instaniat folosind elementul Referin.
Schema XML specific sintaxa DIDL i constrngerile pentru structura documentelor DIDL.
Relaia dintre modelul abstract MPEG-21 i DIDL este prezentat n figura 4.2.
Figura 2 - Relaia dintre modelul abstract MPEG-21 i DIDL
n continuare sunt prezentate componentele de baz ale schemei de declarare a elementelor digitale. Aceste elemente se folosesc n schemele documentelor XML.
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:
Container
Containerul are o structur ierarhic, iar definirea sa se realizeaz recursiv:
De exemplu, dac ntr-un element digital vor fi grupate mai multe elemente ce conin cte o secven video, atunci pentru fiecare secven se va folosi cte un container ce conine declararea elementului.
Declararea descriptorului elementului digital compus este:
Secventele Video
2.3.3 Adaptarea coninutului utiliznd MPEG-21
Standardul MPEG-21 faciliteaz dezvoltarea de soluii de adaptare a coninutului distribuit n funcie de caracteristicile tehnice ale terminalelor folosite pentru receptarea datelor, de caracteristicile tehnice ale mediului de comunicaie folosit sau n funcie de preferinele utilizatorului.
Pentru adaptarea coninutului multimedia este necesar existena unei descrieri a mediului de lucru, pe lng descrierea coninutului propriu-zis. n vederea adaptrii coninutului multimedia trebuie s existe o descriere a sa, folosind unul din standardele adecvate, ca de exemplu Dublin Core, SMPTE sau MPEG-7. Partea a aptea a MPEG-21, denumit Adaptarea elementului digital (DIA) este dedicat descrierii caracteristicilor mediului i adaptrii elementelor digitale la aceste caracteristici.
DIA definete doar instrumentele necesare n procesul de adaptare, nu realizeaz i adaptarea coninutului.
Categoriile de instrumente descriptive folosite sunt:
Instrumentele pentru descrierea mediului au rolul de a descrie caracteristicile semnificative ale contextului i anume:
- caracteristicile terminalului folosit pentru receptarea sau crearea coninutului multimedia: posibilitile de codare/decodare ale terminalului, facilitile/dispozitivele de intrare-ieire conectate, alte caracteristici relevante;
- caracteristicile reelei: capacitatea reelei, tipul conexiunii etc.;
- caracteristicile utilizatorului: informaii despre utilizator, preferinele utilizatorului, un istoric al datelor utilizate, preferine legate de prezentarea informaiilor, caracteristici de accesibilitate i localizarea acestuia;
- caracteristici ale mediul natural: atributele audiovizuale msurabile ale mediului natural, care afecteaz modalitatea n care coninutul multimedia este livrat i/sau consumat de utilizator: nivelul zgomotului, intensitatea luminii, fusul orar, locaia.
Instrumentele de adaptare a resurselor sunt folosite pentru descrierea datelor structurale, ale fluxurilor de bii i a datelor despre adaptabilitatea metadatelor i se folosete pentru aceasta Binary Syntax Description Language. Descrierea se bazeaz pe mprirea fluxului de bii n componente logice, ca de exemplu mprirea unei secvene video n cadre. Fluxul de bii este apoi transformat de un motor pentru adaptarea resursei elementului digital ntr-un descriptor al sintaxei fluxului (BSD), transformare care poate fi fcut sub controlul XSLT (Extensible Stylesheet Language Transformations). Descriptorul este de dorit s fie independent de un format media ceea ce permite realizarea adaptrii resurselor binare n orice locaie.
Instrumentele pentru adaptarea metadatelor identific datele care pot fi utilizate pentru reducerea complexitii instanelor XML de adaptare a metadatelor. Specificaiile se refer la filtrarea i scalarea coninutului i la integrarea a dou sau mai multe instane ale descrierilor.
Legturile dintre principalele componente ale DIA sunt prezentate n figura 3.
Figura 3 Adaptarea elementului digital i instrumente pentru DIA
Declararea unui DIA pentru descrierea caracteristicilor statice i dinamice ale unei reele se poate face:
Caracteristicile monitorului unui terminal se pot descrie:
CAPITOLUL III
XML CA BAZ DE DATE
3.1 Este XML-ul o baz de date?
nainte de a discuta despre XML i baze de date trebuie s rspundem la ntrebarea Este XML-ul o baz de date?
Un document XML este o baz de date n sensul cel mai strict al cuvntului i anume este o colecie de date. Se poate considera c aceste documente nu sunt diferite de orice alt tip de fiiere n fond, toate fiierele conin anumite tipuri de date. Avnd formatul unei baze de date documentele XML prezint anumite avantaje. De exemplu este auto-descris (tag-urile descriu structura i numele tipurilor de date, dar nu i semantica), este portabil (Unicode), i poate descrie date n structuri de arbori sau grafuri. De asemenea are i dezavantaje. De exemplu, este prolixs(neclar) i accesul la date este greoi datorit analizrii i conversiei textului.
Putem considera i c XML i tehnologiile asociate constituie o baz de date n sensul mai larg al cuvntului adic, un sistem de gestiune a bazelor de date (SGBD). XML ofer multe din avantajele bazelor de date: stocare (documente XML), scheme (DTD-uri, scheme XML, RELAX NG, .a,), limbaje de interogare (XQuery, XPath, XQL, XML-QL, QUILT, etc.), interfee de programare (SAX, DOM, JDOM). Totui multe componente ale bazelor de date convenionale: stocare eficient, indeci, securitate, tranzacii i integritatea datelor, accesul multi-user, triggere, interogri fcute pe mai multe documente .a.
Astfel, se pot folosi documente XML ca o baz de date ntr-un mediu cu cerine modeste i date puine, dar aceast soluie nu este viabil ntr-un mediu pentru producie n mas, unde exist muli utilizatori, cerine stricte de integritate a datelor i nevoia de o performan bun.
3.2 Date i documente
Cel mai important factor n alegerea unei baze de date este ce va stoca aceasta: date sau documente. XML-ul poate fi folosit doar pentru a transporta date ntre baza de date i o aplicaie sau poate fi folosit integral ca n cazul documentelor XHTML i DocBook. Scopul utilizrii XML este important deoarece toate documentele centrate pe date au anumite caracteristici comune, la fel se ntmpla i n cazul informaiilor centrate pe documente, i aceste caracteristici influeneaz felul cum XML-ul este stocat n baza de date.
3.2.1 Documente centrate pe date
Documentele centrate pe date sunt documente care folosesc XML-ul pentru transportul datelor. Aceste documente sunt folosite de ctre aplicaii i nu are nici o importan faptul c informaiile folosite au fost reinute pentru o perioad de timp n documente XML. Exemple de documente centrate pe date sunt ordine de plat, programarea zborurilor, date tiinifice.
Documente centrate pe date au o structur regulat, datele sunt atomice (cea mai mic unitate independenta de date este un element sau un atribut). Ordinea elementelor care apar n document nu este important, dect n momentul validrii documentului.
Informaiile care exist n documentele centrate pe date pot proveni din baza de date (caz n care se dorete extragerea lor n fiiere XML), dar i din afara bazei de date (caz n care se dorete stocarea acestora n baza de date). Un exemplu de informaii care provin dintr-o baz de date sunt cantitile de date stocare n bazele de date relaionale, iar un exemplu de informaii care se doresc a fi introduse ntr-o baz de date pot fi considerate datele tiinifice obinute de un sistem de msurtori i convertite n XML.
De exemplu urmtorul ordin de vnzare este un document centrat pe date:
ABC Industries
123 Main St.
Chicago
IL
60609
981215
Cheie reglabila:
Hotel inoxidabil,
Garantie pe viata.
9.95
10
Separator:
Aluminiu, un an garantie.13.275Pe lng documentele centrate pe date
cu structura asemntoare cu documentul din exemplul anterior, multe
documente care conin i text adiional sunt centrate pe date. Spre
exemplu s considerm o pagin web care conine informaii despre o
carte. Dei pagina conine n mare parte text, structura acelui text
este regulat, i o parte din acel text este comun tuturor paginilor
care descriu cri, fiecare poriune de text specific avnd dimensiuni
limitate. Astfel pagina ar putea fi construit dintr-un document XML
simplu, centrat pe date care conine informaii despre o singur carte
i este obinut dintr-o baz de date i un stylesheet XSL care adaug
textul care leag informaiile din XML. n general orice site web care
construiete documente HTML dinamic prin completarea unui template
cu informaii dintr-o baz de date poate fi nlocuit cu mai multe
documente XML centrate pe date i unul sau mai multe stylesheet-uri
XSL.De exemplu, s considerm urmtorul document care descrie un
zbor:ABC Airways ofera treizboruri zilnice non-stop din Dallas
spreFort Worth. Orele de plecare sunt09:15, 11:15,and 13:15.
Sosirile sunt cateva minute mai tarziu.Acesta ar putea fi construit
dintr-un fiier XML i un stylesheet simplu:ABC AirwaysDallasFort
Worth09:1509:1611:1511:1613:1513:163.2.2 Informaii centrate pe
documenteDocumentele care folosesc viziunea centrat pe documente
sunt, de obicei, acele documente care sunt destinate folosirii de
ctre utilizatori. Exemple de astfel de documente sunt crile, email,
anunuri publicitare i aproape orice document XHTML scris de mn.
Acestea sunt caracterizate de o structur mai puin regulat, datele
nu sunt atomice (cea mai mic unitate independent de informaie poate
fi format dintr-un element mbinat cu alte informaii din document).
Ordinea elementelor care apar n document este aproape ntotdeauna
important.Aceste tipuri de documente sunt de obicei scrise manual n
XML sau n alte formate cum ar fi RTF, PDF sau SGML i apoi sunt
transformate n XML. Spre deosebire de documentele centrate pe date
aceste documente nu pot proveni din baze de date.Spre exemplu
urmtorul document ce conine descrierea unui produs este centrat pe
documente:Cheie reglabila de la FullFabrication Labs,Inc.esteca o
cheie universala,dar mai mica.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.Puteti:comanda propria dumneavoastra
cheie reglabila Cititi mai multe despre cheiDescarcati
catalogulCheia reglabila costa doar 44.90 RON si, daca
veticomanda acum, veti primi un ciocan cadou.3.2.3 Date,
documente i baze de daten realitate diferena dintre documentele
centrate pe date i cele centrate pe documente nu este ntotdeauna
clar. Astfel de documente sunt cele legale sau medicale, care sunt
scrise ca text dar conin i poriuni de date cum ar fi nume, date,
proceduri i de multe ori trebuiesc stocate n ntregime din cauze
legale. Cu toate acestea clasificarea documentelor ca fiind
centrate pe date sau pe documente poate determina tipul bazei de
date necesare stocrii informaiilor din aceste documente. De obicei
datele sunt stocate ntr-o baz de date tradiional cum sunt cele
relaionale sau orientate-obiect. Documentele sunt stocate ntr-o baz
de date nativ XML (o baz de date destinat stocrii XML) sau un
sistem de gestionare a coninuturilor (content management system) o
aplicaie destinat administrrii documentelor i construit peste o baz
de date nativ XML.Totui aceste reguli nu sunt stricte. Datele n
special datele semistructurate pot fi stocate n baze de date native
XML i documentele pot fi stocate n baze de date tradiionale atunci
cnd nu sunt necesare foarte multe caracteristici specifice XML. n
plus, graniele dintre bazele de date tradiionale i cele native XML
devin din ce n ce mai neclare, deoarece la bazele de date
tradiionale se adaug facilitai native XML i bazele de date native
XML suport stocarea fragmentelor de documente n baze de date, de
obicei relaionale, externe.3.3 Stocarea i recuperarea datelorPentru
transferarea datelor ntre documente XML i o baz de date, este
necesar maparea schemei documentului XML (DTD, Scheme XML, RELAX
NG, etc.) pe schema bazei de date. Software-ul pentru transferul de
date este construit peste aceast mapare. Software-ul poate folosi
un limbaj de interogare XML (cum ar fi XPath, XQuery) sau poate
transfera direct date conform cu maparea (echivalentul n XML al
interogrii SELECT * FROM Tabel).n al doilea caz, structura
documentului i structura necesar pentru mapare trebuie s fie
identice. Deoarece acest lucru se ntmpl destul de rar, produsele
care folosesc aceast strategie sunt adesea folosite mpreun cu XSLT.
Astfel, nainte de transferarea datelor n baza de date, documentul
este nti adus la structura necesar maprii i apoi datele sunt
transferate. Similar dup transferarea datelor din baza de date,
documentul obinut este adus la structura folosit de ctre
aplicaie.3.3.1 Maparea schemelor documentelor pe schemele bazelor
de dateMaprile ntre schemele documentelor i schemele bazelor de
date sunt efectuate pe tipurile elementelor, atribute, i text.
Aproape ntotdeauna se omit structurile fizice (cum ar fi entitile i
informaia codificat) i unele structuri logice (cum ar fi
instruciunile de procesare, comentariile). Aceste omiteri nu au o
influen prea mare, deoarece baza de date i aplicaia sunt interesate
numai de datele din documentul XML.O consecin a acestor transformri
adic stocarea datelor dintr-un document ntr-o baz de date i apoi
reconstruirea documentului din datele existente n baza de date este
obinerea unui document diferit. Dac acest lucru este acceptabil
depinde de cerinele fiecrui proiect i poate influena alegerea
softului.De obicei sunt folosite dou metode pentru a mapa schema
unui document XML pe schema unei baze de date: maparea bazat pe
tabele i maparea obiectual-relaional.3.3.1.1 Maparea bazat pe
tabeleMaparea bazat pe tabele este folosit de multe produse care
efectueaz transferul de date ntre un document XML i o baz de date
relaional. Aceasta modeleaz un document XML ca o singur tabel sau
ca un set de tabele. Structura documentului XML este artat n
exemplul urmtor.......n funcie de software datele din coloane pot
fi stocate ca elemente descendente sau ca atribute. n plus,
produsele care folosesc mapri bazate pe tabele de multe ori includ
metadate fie la nceputul documentului fie ca atribute asociate
fiecrui element din tabel sau coloan.Maparea bazat pe tabele este
utilizat pentru serializarea datelor relaionale, ca n cazul
transferrii datelor ntre dou baze de date relaionale. Dezavantajul
acestei mapri este c nu poate fi folosit pentru un document XML
care nu respect formatul din exemplu.3.3.1.2 Maparea
obiectual-relaionalMaparea obiectual-relaional este folosit de ctre
toate bazele de date relaionale care suport XML i anumite produse
middleware. Aceasta modeleaz datele din documentul XML ca un arbore
de obiecte care sunt specifice datelor din document. n acest model,
tipurile de elemente cu atribute sunt n general modelate n clase.
Tipurile de elemente simple, atributele, i PCDATA sunt modelate ca
proprieti scalare. Modelul este apoi mapat pe bazele de date
relaionale folosind tehnici de mapare obiectual-relaionale
tradiionale. Astfel clasele sunt mapate pe tabele, proprietile
scalare pe coloane, i proprietile cu valori obiect sunt mapate pe
perechi de chei primare/chei strine. Denumirea de mapare
obiectual-relaional este de fapt un termen impropriu, deoarece
arborele de obiecte poate fi mapat direct pe baze de date orientate
obiect i ierarhizate. Totui este folosit pentru c majoritatea
produselor care folosesc aceast mapare folosesc baze de date
relaionale i acest termen este bine cunoscut.Este important
nelegerea faptului c modelul obiectual din aceast mapare nu este
modelul DOM (Document Object Model). DOM-ul modeleaz chiar
documentul i este acelai pentru toate documentele XML, n timp ce
modelul descris mai sus modeleaz datele din document i este diferit
pentru fiecare set de documente XML care corespund unei scheme XML
de date. De exemplu ordinul de vnzri din seciunea 3.2.1 ar putea fi
modelat ca un arbore de obiecte format din 4 clase OrdineVnzri,
Client, Item, i Parte aa cum se arat n diagrama de mai jos:
OrdineVnzri/ | \Client Item Item| |Parte ParteDac ar trebui s
construim un arbore DOM din acelai document, acesta ar fi compus
din obiecte cum ar fi Element, Atribut i Text.Element ------
Atribut(OrdineVnzri) (Numr OV)_________/ / \ \_____/ / \ \Element
Text Element Element(Client) (Data ordinului) (Item) (Item)| |
|etc. etc. etc.Instanierea obiectelor din model depinde de produsul
folosit. Unele produse dau posibilitatea generrii claselor n model
i apoi folosirea obiectelor din aceste clase n aplicaii. n cazul
folosirii acestor produse, datele sunt transferate ntre documentul
XML i aceste obiecte, i ntre aceste obiecte i baza de date. Alte
produse folosesc aceste obiecte numai pentru a vizualiza maparea i
transferul de date direct ntre documentul XML i baza de date.Felul
n care maparea obiectual-relaional este suportat variaz de la
produs la produs. De exemplu:Toate produsele suport maparea
tipurilor complexe de elemente pe clase i a tipurilor simple de
elemente i atribute pe proprieti.Toate produsele dau posibilitatea
desemnrii unui element rdcin care nu este mapat pe modelul obiect
sau pe baza de date. Acest element este folositor atunci cnd se
dorete stocarea obiectelor cu mai multe nivele n acelai document
XML.Majoritatea produselor ofer posibilitatea specificrii dac
proprietile sunt mapate pe atribute sau pe elemente descendente n
documentul XML. Unele produse permit combinarea atributelor cu
elementele descendente; altele cer folosirea numai a elementelor
descendente sau a atributelor. Majoritatea produselor permit
folosirea numelor diferite n documentul XML i baza de date, dar
sunt anumite produse care necesit folosirea acelorai nume att n
documentul XML ct i n baza de date.Majoritatea produselor permit
specificarea ordinii n care elementele descendente apar n printele
lor, dar care face imposibil construirea mai multor modele pentru
coninut. Din fericire, modelele pentru coninut suportate sunt
suficiente pentru majoritatea documentelor centrate pe date
(ordinea este important numai dac se face validarea
documentului).3.3.2 Limbaje de interogareMulte produse transfer
date direct conform cu modelul pe care sunt construite. Deoarece
structura documentului XML este de obicei diferit de structura
bazei de date, aceste produse deseori conin sau sunt folosite cu
XSLT. Acesta d posibilitatea utilizatorilor s transforme documente
la structura modelului naintea transferrii datelor n baza de date,
i invers. Deoarece procesarea XSLT poate fi scump, unele produse
conin un numr limitat de transformri n maprile lor.Soluia pe termen
lung la aceast problem este implementarea unor limbaje de
interogare care returneaz XML. n prezent cele mai multe asemenea
limbaje se bazeaz pe fraze SELECT integrate n abloane. Se presupune
c aceast situaie se va schimba atunci cnd XQuery i SQL/XML vor fi
finalizate, acestea aflndu-se n lucru. Aproape toate limbajele de
interogare XML sunt deocamdat read-only, deci vor fi necesare
metode diferite pentru inserarea, actualizarea i tergerea datelor
(n viitor aceste facilitai vor fi adugate). 3.3.2.1 Limbaje de
interogare bazate pe abloaneCele mai des ntlnite limbaje de
interogare care returneaz XML din baze de date relaionale sunt cele
bazate pe abloane. n aceste limbaje, nu exist o mapare predefinit
ntre document i baza de date. Frazele SELECT sunt integrate ntr-un
ablon i rezultatele sunt procesate de ctre software-ul care
transfera date. De exemplu, urmtorul template folosete elementele
pentru a include fraze SELECT i numele coloanelor pentru a
determina unde trebuiesc plasate rezultatele: Urmatoarele zboruri
sunt diponibile:SELECT Airline, FltNumber,Depart, Arrive FROM
Flights$Airline$FltNumber$Depart$ArriveSperam ca unul dintre ele va
este de folos Rezultatul procesrii unui asemenea ablon ar putea fi:
Urmatoarele zboruri sunt diponibile:ACME123Dec 12, 1998 13:43Dec
13, 1998 01:21Speram ca unul dintre ele va este de folos Limbajele
de interogare bazate pe abloane pot fi foarte flexibile. Dei setul
de caracteristici variaz de la un produs la altul, exist unele
caracteristici comune:Abilitatea de a plasa seturi de rezultate
oriunde n documentul de ieire, incluznd ca parametrii i frazele
SELECT .Construcii cum ar fi cicluri FOR i instruciuni IF.Definiri
de variabile i funciiParametrizarea frazelor SELECT prin
intermediul parametrilor HTTP.Limbajele de interogare bazate pe
abloane sunt folosite aproape exclusiv pentru a transfera date din
baze de date relaionale n documente XML. Dei unele produse care
folosesc limbaje de interogare bazate pe abloane pot transfera date
din documente XML n baze de date relaionale, ele nu folosesc
abloanele numai pentru acest lucru. n schimb ele folosesc o mapare
bazat pe tabele, aa cum este descris anterior.3.3.2.2 Limbaje de
interogare bazate pe SQLLimbajele de interogare bazate pe SQL
folosesc fraze SELECT modificate, iar rezultatele sunt transformate
n XML. Exist cteva limbaje particulare de acest tip i cel mai
simplu dintre acestea folosete fraze SQL imbricate (nested), care
sunt transformate direct n XML imbricat (nested) conform cu maparea
relaional-obiectual. Un alt limbaj de acest tip folosete obiecte
SQL 3, de asemenea transformate direct n XML. Un alt limbaj
folosete fraze OUTER UNION i marcaje speciale pentru a determina
cum sunt transformate rezultatele n XML.n plus faa de limbajele
particulare, un numr de companii s-au reunit n 2000 pentru a
standardiza extensiile XML la SQL. Rezultatele lor fac parte acum
din specificaia ISO SQL i este cunoscut ca SQL/XML. SQL/XML
introduce un tip de date XML i adaug un numr de funcii la SQL, aa c
este posibil construirea elementelor XML i a atributelor din date
relaionale.De exemplu, urmtoarea interogare:SELECT
Orders.SONumber,XMLELEMENT(NAME
"Order",XMLATTRIBUTES(Orders.SONumber AS SONumber),XMLELEMENT(NAME
"Date", Orders.Date),XMLELEMENT(NAME "Customer", Orders.Customer))
AS xmldocument FROM Ordersconstruiete un set de rezultate cu dou
coloane. Prima coloan conine numrul ordinului de vnzri i a doua
coloan conine un document XML. Exist un document XML pe fiecare
linie, construit din datele din linia corespunztoare n tabelul de
comenzi. De exemplu documentul pentru linia pentru ordinul de
vnzare 123 ar putea fi:04/29/07Gallagher Industries3.3.2.3 Limbaje
de interogare XMLSpre deosebire de limbajele de interogare bazate
pe abloane sau bazate pe SQL, care pot fi folosite numai cu baze de
date relaionale, limbajele de interogare XML pot fi folosite pentru
orice document XML. Pentru a folosi acest tip de limbaje cu baze de
date relaionale, datele din baza de date trebuie s fie modelate ca
XML.Cu XQuery, poate fi folosit fie maparea bazat pe tabele fie
maparea obiectual relaional. Dac este folosit o mapare bazat pe
tabele, fiecare tabel este tratat ca un document separat i n
fiecare interogare sunt specificate uniri ntre tabele, ca n SQL.
Dac este folosit o mapare obiectual-relaional atunci ierarhiile de
tabele sunt tratate ca un singur document i sunt specificate uniri
n mapare. Se preconizeaz c maprile bazate pe tabele vor fi
utilizate n majoritatea implementrilor, n detrimentul bazelor de
date relaionale, deoarece se consider c sunt mai uor de implementat
i mai bine cunoscute de utilizatorii SQL.Cu XPath, o mapare
obiectual-relaional trebuie s fie folosit pentru a executa
interogri peste mai multe tabele. Aceasta se ntmpl deoarece XPath
nu suport unirile ntre documente. Astfel, dac ar fi folosit o
mapare bazat pe tabele, ar fi posibil interogarea unei singure
tabele la un moment dat. 3.3.3 Stocarea datelor n baze de date
native XMLDe asemenea este posibil stocarea datelor n documente XML
ntr-o baz de date nativ XML. Acest lucru se face din mai multe
motive. Primul ar fi acela cnd datele sunt semistructurate, adic
acestea au o structur regulat, dar acea structur variaz destul nct
maparea ei la o baz de date relaional duce fie la un numr mare de
coloane cu valori nule (care ocup spaiu inutil), fie la un numr
mare de tabele (care este ineficient). Dei datele semistructurate
pot fi stocate n baze de date ierarhizate orientate-obiect, se
poate alege stocarea lor ntr-o baz de date nativ XML sub forma unui
document XML. Al doilea motiv pentru stocarea datelor ntr-o baz de
date nativ XML este viteza de recuperare a datelor. n funcie de cum
sunt stocate datele n baza de date nativ XML, ar putea fi posibil
recuperarea datelor mult mai repede dect ntr-o baz de date
relaional. Acest lucru se poate ntmpla deoarece unele strategii de
stocare folosite de ctre bazele de date native XML rein fizic
documente ntregi sau folosesc pointeri fizici (i nu logici) ntre
prile documentelor. Acestea permit ca documentele s fie recuperate
fie fr uniri fie folosind uniri fizice, ambele fiind mai rapide
dect unirile logice folosite n bazele de date relaionale.De exemplu
se consider ordinul de vnzare prezentat mai sus. ntr-o baz de date
relaional, acesta ar fi stocat n patru tabele OrdineVnzri, Itemi,
Clieni, i Parte i recuperarea documentului ar necesita uniri ntre
aceste tabele. ntr-o baz de date nativ XML, ntreg documentul ar
putea fi stocat ntr-o singur locaie pe disc, aa c recuperarea lui
sau a unui fragment din el necesit o singur cutare indexat i o
singur citire pentru recuperarea datelor. O baz de date relaional
necesit patru cutri indexate i cel puin patru citiri pentru a
recupera datele.Dezavantajul n acest caz este acela c viteza de
recuperare este mare numai atunci cnd datele din comand sunt
stocate pe disc. Dac se dorete recuperarea altor date, cum ar fi o
list a clienilor i ordinele de vnzare ale lor, atunci performanta
va fi mai slab dect ntr-o baz de date relaional. Astfel, stocarea
datelor ntr-o baz de date nativ XML se recomand din motive de
performana atunci cnd predomin o singur vedere asupra datelor.Al
treilea motiv pentru stocarea datelor ntr-o baz de date nativ XML
este exploatarea capacitilor specifice XML, cum ar fi executarea
interogrilor XML. Deoarece relativ puine aplicaii centrate pe date
au nevoie de acestea i bazele de date relaionale implementeaz
limbaje de interogare XML, acest motiv nu este foarte important.O
problem cu stocarea datelor ntr-o baz de date nativ XML este c
majoritatea acestor baze de date pot returna datele numai ca XML.
(Puine baze de date suport legarea elementelor sau atributelor de
variabilele dintr-o aplicaie.) Dac o aplicaie are nevoie de date
ntr-un alt format (ceea ce este posibil), aceasta trebuie s
analizeze XML-ul nainte de a folosi datele. Acesta este un
dezavantaj pentru aplicaiile locale care folosesc o baz de date
nativ XML n locul unei baze de date relaionale.3.3.4 Tipuri de
date, valori nule, seturi de caractereAceast seciune se ocup de
anumite probleme legate de stocarea datelor din documente XML n
baze de date tradiionale. Problemele legate de tipurile de date i
datele binare apar i n cazul stocrii datelor n baze de date native
XML. n general utilizatorul nu poate alege modalitatea n care
sotf-ul care transfer datele rezolv aceste probleme, dar atunci cnd
se alege un anumit soft trebuie inut cont de faptul c aceste
probleme exist.3.3.4.1 Tipuri de dateXML nu suport prea multe
tipuri de date. Cu excepia entitilor neanalizate, toate datele
dintr-un document XML sunt text, chiar dac reprezint alt tip de
date, cum ar fi datele calendaristice sau integer. n general
soft-ul de transfer date va transforma textul (din documentul XML)
n alte tipuri de date (n baza de date) i invers.Softul determin ce
conversii sunt necesare i exist dou metode pentru efectuarea
acestora. Prima metod const n determinarea de ctre software a
tipurilor de date din schema bazei de date, deoarece aceasta este
accesibil la rulare. (Schema XML nu este neaprat accesibil la
rulare sau s-ar putea sa nu existe.) n a doua metod utilizatorul
specific tipul de date. Acesta poate fi scris de ctre utilizator
sau generat automat dintr-o schem a unei baze de date sau dintr-o
schem XML. Atunci cnd sunt generate automat, tipurile de date pot
fi recuperate din schemele bazelor de date i din anumite tipuri de
scheme XML. Formatele de text recunoscute n momentul conversiilor
pot constitui o problem atunci cnd se transfer date din XML, la fel
i formatele care se pot crea atunci cnd se transfer date ctre XML.
n cele mai multe cazuri, numrul de formate de text care sunt
suportate de un tip de dat este limitat la unul anume sau la cele
suportate de driverul JDBC. Datele pot cauza multe probleme pentru
c gama de formate posibile este foarte mare, iar numerele cu
diferitele lor formate internaionale pot cauza de asemenea
probleme.3.3.4.2 Date binareDatele binare se pot stoca n documente
XML n trei feluri: codificare Base64 (o codificare MIME care mapeaz
datele binare pe un subset al US-ASCII [0-9, a-z, A-Z,+,/]),
codificarea hexazecimal (fiecare octet binar este codificat cu dou
caractere reprezentnd cifre hexazecimale [0-9,a-f,A-F]), i entiti
neanalizate (datele binare sunt stocate ntr-o entitate fizic
separat de restul documentului XML).Cea mai mare problem cu datele
binare este c multe dintre produsele care transfer date nu suport
acest tip de date. O problem secundar apare dac sunt folosite
entiti neanalizate i const n faptul c majoritatea produselor nu
stocheaz notaii i declaraii de entiti. Astfel, notaia asociat cu o
anumit entitate va fi pierdut atunci cnd datele sunt transferate
dintr-un document XML ntr-o baz de date.3.3.4.3 Date viden domeniul
bazelor de date, date vide sunt numite datele care nu exist.
Acestea sunt foarte diferite de valoarea 0 (pentru numere), sau
lungimea zero (pentru un string). De exemplu, se ia n considerare o
colecie de date de la o staie meteo. Dac termometrul nu funcioneaz,
n baza de date este stocat o valoare nul i nu valoarea zero, care
ar nsemna cu totul altceva. XML suport de asemenea conceptul de
date vide prin tipuri de elemente i atribute opionale. Dac valoarea
unui tip sau atribut opional este nul acesta nu este inclus n
document. n cazul bazelor de date, atributele care conin iruri de
caractere cu lungimea zero sau elemente nule nu sunt vide, valoarea
lor este un ir cu lungimea zero.La maparea structurii unui document
XML la baza de date i invers, tipurile de date i atributele
opionale sunt mapate ca i coloane vide. Dac nu se procedeaz n acest
mod s-ar putea inserarea o eroare (atunci cnd se transfer date n
baza de date), sau la un document invalid (atunci cnd se transfer
date din baza de date).3.3.4.4 Seturi de caractereUn document XML
poate conine orice caracter Unicode cu excepia unor caractere de
control. Din nefericire, multe baze de date ofer suport limitat sau
nu ofer suport deloc pentru Unicode i necesit o configuraie special
pentru caracterele non-ASCII.3.3.4.5 Instruciuni de procesare i
comentariiInstruciunile de procesare i comentariile nu fac parte
din datele dintr-un document XML i majoritatea soft-urilor de
transfer de date nu le pot manipula. Totui ele pot aprea aproape
oriunde ntr-un document XML i de aceea nu se integreaz uor n
maprile bazate pe tabele i cele obiectual relaionale. O soluie
total ineficient ntr-o baz de date relaional este adugarea unor
tabele pentru instruciuni de procesare i comentarii, adugarea de
chei strine la aceste tabele pentru toate celelalte tabele, i
verificarea acestor tabele de fiecare data cnd se proceseaz o alt
tabel. Astfel majoritatea soft-urilor de transfer de date le nltur.
3.3.4.6 Stocarea marcajelorn anumite situaii este indicat stocarea
elementelor cu coninut mixt n baza de date fr a se efectua analiza
complet. Cnd este realizat acest lucru, marcajul este realizat cu
caractere de marcare. Totui apare o problem la stocarea
caracterelor de marcare care nu sunt folosite pentru marcaj. n
fiierul XML, acestea sunt stocate folosind entitatile lt, gt, amp,
quot, i apos. Acest lucru poate fi fcut i n baza de date. De
exemplu urmtoarea descriere:Exemplu confuz: poate fi stocat
n baza de date ca:Exemplu confuz: Totui apare o problem,
limbajele de interogare non-XML, cum ar fi SQL, nu caut n coloane
marcaje sau folosirea de entiti i le interpreteaz ca atare. Astfel,
dac se caut irul cu SQL, de fapt trebuie cutat irul .Pe de alt
parte, dac referinele la entiti sunt extinse, software-ul de
transfer de date nu poate distinge ntre marcaj i folosirea
entitilor. De exemplu, dac descrierea de mai sus este stocat n baza
de date n forma urmtoare, soft-ul nu poate spune dac ,, i
sunt marcaje sau text: Exemplu confuz: Soluia pe termen lung
la aceast problem sunt bazele de date care recunosc XML, n care
marcajul efectiv e tratat diferit de elementele care doar par a fi
marcaj. Dar, probabil vor fi ntotdeauna probleme atunci cnd
aplicaii non-XML lucreaz cu XML.3.3.5 Generarea schemelor XML din
scheme relaionale i inversO ntrebare care apare frecvent la
transferul datelor ntre documente XML i baze de date este cum se
genereaz scheme XML din scheme ale bazelor de date i invers. nainte
de a explica cum se face acest lucru, este bine de reinut faptul c
aceasta este o operaie design-time. Motivul pentru acest lucru este
c majoritatea aplicaiilor centrate pe date, i cele mai multe
aplicaii pe vertical, lucreaz cu un set cunoscut de scheme XML i
scheme de baze de date. Astfel ele nu trebuie s genereze scheme n
momentul rulrii. n plus procedurile pentru generarea schemelor nu
sunt perfecte. Aplicaiile care trebuie s rein documente XML
aleatoare ntr-o baz de date ar trebui s foloseasc o baz de date
nativ XML n loc s genereze scheme la rulare.Cea mai uoar cale de a
genera scheme relaionale din scheme XML i invers este de a codifica
o cale prin maparea obiectual relaional, care are un numr de
trsturi opionale. O schem relaional se genereaz dintr-o schema XML
astfel:Pentru fiecare tip complex de elemente trebuie creat o tabel
i o coloan cheie primar.Pentru fiecare tip de elemente cu coninut
mixt, trebuie creat o tabel separat n care se va stoca PCDATA,
legat de tabela printe prin intermediul cheii primare din tabela
printe.Pentru fiecare atribut cu o singur valoare a acelui tip de
element, i pentru fiecare element descendent simplu care apare o
singur dat trebuie creat o coloan n acel tabel. Dac schema XML
conine informaia despre tipurile de date, atunci trebuie setate
tipurile de date ale coloanelor la tipul corespunztor. Altfel,
tipurile de date trebuie setate la un tip predeterminat, cum ar fi
CLOB sau VARCHAR(255). Dac tipul elementelor descendente sau al
atributelor este opional coloana trebuie s aib posibilitatea de a
fi setat nul.Pentru fiecare atribut cu mai multe valori i pentru
fiecare element descendent simplu care apare de mai multe ori
trebuie creat o tabel separat pentru a stoca valorile, legat de
tabela printe prin intermediul cheii primare din tabela
printe.Pentru fiecare element descendent complex, trebuie legat
tabela tipului elementului printe de tabela tipului elementului
descendent prin intermediul cheii primare din tabela printe.O
schema XML se genereaz dintr-o schem relaional astfel:Pentru
fiecare tabel se genereaz un tip de elementPentru fiecare coloan
care nu este cheie n acea tabel, dar i pentru coloanele chei
primare, se adaug la model un atribut la tipul elementului sau un
element descendent ce conine numai PCDATA.La fiecare tabel pentru
care cheia primar este exportat, se adaug un element descendent la
model i se proceseaz tabela recursiv.Pentru fiecare cheie strina,
se adaug un element descendent la model i se proceseaz tabela cu
cheie strin recursiv. Exist cteva dezavantaje la aceste procedee.
Multe dintre acestea se pot corecta uor de ctre programator, cum ar
fi coliziuni de nume i specificarea lungimilor i tipurilor de date
ale coloanelor. DTD-urile nu conin informaii despre tipurile de
date, deci nu este posibil cunoaterea tipurilor de date care ar
trebui folosite n baza de date. Tipurile de date i lungimile pot fi
prevzute dintr-o schem XML.O problem mai important este aceea c
modelul de date folosit de documentul XML este adesea diferit i de
obicei mai complex dect cel mai eficient model pentru stocarea
datelor n baza de date. De exemplu, se consider urmtorul fragment
XML:ABC Industries123 Main St.FoovilleCAUSA95041Procedura pentru
generarea unei scheme relaionale dintr-o schem XML ar crea dou
tabele: una pentru clieni i una pentru adrese. Totui n majoritatea
cazurilor ar fi mai bine s se rein adresa n tabela de clieni, i nu
ntr-o tabel separat.Elementul este un bun exemplu pentru un element
wrapper. Elementele wrapper sunt n general folosite din dou motive.
n primul rnd, ele ofer structuri adiionale ceea ce face documentul
mai uor de neles. n al doilea rnd, ele sunt de obicei folosite ca o
form de redactare a datelor. De exemplu, elementul ar putea fi
trimis la o rutin care transform toate adresele n obiecte Adresa,
indiferent unde apar acestea.Daca elementele wrapper sunt
folositoare n XML, n general ele cauzeaz probleme atunci cnd sunt
mapate la baza de date dac acestea se gsesc sub forma
extra-structurilor. Din aceast cauz, ele ar trebui eliminate din
schema XML naintea generrii schemei relaionale. Din moment ce este
puin probabil c modificarea schemei XML ar trebui s fie permanent,
acest lucru duce la o neconcordan ntre documentul existent i
documentele presupuse de ctre soft-ul de transfer de date, din
moment ce elementele wrapper nu sunt incluse n mapare. Acest lucru
poate fi rezolvat prin transformarea documentelor la rulare cu
XSLT: elementele wrapper sunt eliminate naintea transferrii datelor
n baza de date i sunt inserate dup transferul datelor din baza de
date. Cu toate aceste dezavantaje, procedurile de mai sus ofer n
continuare un punct de pornire folositor pentru generarea schemelor
XML din scheme relaionale i invers, n special n sisteme mari.3.4
Stocarea i recuperarea documentelorPentru stocarea documentelor XML
exist dou strategii de baz: stocarea lor n sistemul de fiiere sau
ca un BLOB ntr-o baz de date relaional i acceptarea funcionalitilor
XML limitate, sau stocarea lor ntr-o baz de date nativ XML.3.4.1
Stocarea documentelor n sistemul de fiiereDac se lucreaz cu un set
simplu de documente, cum ar fi un set mic de documentaie, cea mai
uoara cale de stocare este n sistemul de fiiere. Se pot folosi
instrumente cum ar fi grep pentru interogarea lor, i sed pentru
modificarea lor. Cutrile complete de text n documentele XML sunt
inexacte, pentru c ele nu pot distinge marcajul de text i nu pot
nelege folosirea entitilor. Totui, ntr-un sistem mic, aceste
inexactiti ar putea fi acceptabile. Dac se dorete un simplu control
al tranzaciilor, documentele pot fi ntreinute cu o versiune de
control a sistemului cum ar fi CVS sau RCS.3.4.2 Stocarea
documentelor n BLOB-uriO opiune puin mai sofisticat este stocarea
documentelor ca BLOB-uri ntr-o baz de date relaional. Aceast
modalitate ofer un numr de avantaje a bazelor de date: controlul
tranzaciilor, securitate, acces multiuser. n plus, multe baze de
date au instrumente pentru cutri de text i pot face cutri complete
de text, cutri aproximative, cutri sinonime i cutri fuzzy. Unele
dintre aceste instrumente sunt construite pentru a recunoate XML,
ceea ce va elimina problemele care apar la cutrile documentelor XML
ca simplu text. Atunci cnd se stocheaz documente XML ca BLOB-uri,
se pot implementa uor indexri simple care recunosc XML, chiar dac
baza de date nu poate indexa XML. O modalitate de a face acest
lucru este crearea a dou tabele, o tabel index i o tabel document.
Tabela document conine o cheie primar i o coloan BLOB n care este
reinut documentul. Tabela index conine o coloan n care se gsete
valoarea ce va fi indexat i o cheie strin care duce la cheia primar
a tabelei document.Atunci cnd documentul este stocat n baza de
date, el este cutat pentru toate instanele elementului sau
atributului care este indexat. Fiecare instana este stocat n tabela
index, mpreuna cu cheia primara a documentului. Coloana de valori
este apoi indexat, i permite unei aplicaii s efectueze o cutare
rapid a unei anumite valori a unui element sau atribut i s
recupereze documentul corespunztor.De exemplu, se consider un set
de documente cu urmtorul DTD i se dorete construirea unui index de
autori: Acestea ar putea fi stocate n urmtoarele tabele:Autori
Brosuri---------------------- ---------Autor VARCHAR(50) BrosurID
INTEGERBrosuraID INTEGER Brosura LONGVARCHARCnd se insereaz o brour
n baza de date, aplicaia insereaz broura n tabela Brouri, apoi caut
elementele , reinnd valorile acestora i ID-ul brourii din tabela
Autori. Aplicaia poate recupera brourile n funcie de autor cu o
simpl fraza SELECT. De exemplu, pentru a recupera toate brourile
scrise de autorul Chen, aplicaia execut urmtoarea interogare:SELECT
BrosuraFROM BrosuriWHERE BrosuraID IN (SELECT BrosuraID FROM Autori
WHERE Autor= 'Chen')O tabel de indeci mai sofisticat ar conine
patru coloane: numele atributului sau elementului, tipul, valoarea
i ID-ul documentului. Aceasta tabel ar putea stoca valorile
marcajelor multiple i ar trebui indexat dup nume, tip, i valoare.
Scrierea unei aplicaii generice SAX pentru a popula o astfel de
tabel ar fi relativ uoar.3.4.3 Baze de date native XMLDac sunt
necesare mai multe caracteristici dect cele oferite de unul din
sistemele de mai sus, trebuie luat n considerare o baz de date
nativ XML. Bazele de date native XML sunt baze de date construite
special pentru a stoca documente XML. Ca i alte baze de date,
acestea suport tranzacii, securitate, acces multiuser, API-uri
programatice, limbaje de interogare. Singura diferen fa de alte
baze de date este aceea c modelul lor interior este bazat pe XML i
nu pe altceva, ca n cazul modelului relaional. Bazele de date
native XML sunt de obicei folosite pentru a stoca documente
centrate pe documente. Principalul motiv este c ofer suport pentru
limbaje de interogare XML, care ofer posibilitatea adresrii unor
ntrebri de forma: Extrage toate documente n care al treilea
paragraf de la nceputul seciunii conine un cuvnt ngroat, sau ofer
posibilitatea limitrii cutrilor complete de text la anumite poriuni
din document. Asemenea interogri sunt dificil de scris ntr-un
limbaj ca SQL. Un alt motiv este acela c bazele de date native XML
pstreaz ordinea documentelor, instruciunile de procesare, i
comentarii, i adesea pstreaz seciuni CDATA, folosirea entitilor, i
altele, pe cnd bazele de date ce permit folosirea XML nu posed
aceste caracteristici.Bazele de date native XML sunt de obicei
folosite pentru a integra date. Integrarea datelor a fost fcut cu
baze de date relaionale federate, dar acestea necesitau ca toate
resursele de date s fie mapate la modelul relaional. Aceast
modalitate nu funcioneaz pentru mai multe tipuri de date i modelul
de date XML ofer o flexibilitate mai mare. Bazele de date native
XML trateaz modificrile schemelor mai uor dect bazele de date
relaionale i pot trata i date care nu au schem. Ambele consideraii
sunt importante pentru integrarea datelor din surse care nu se afl
sub control direct.Al treilea caz de utilizare major al bazelor de
date native XML este pentru datele semistructurate, aa cum se gsesc
n finane, n biologie, date care se schimb att de des nct nu este
posibil definirea unor scheme definitive. Datorit faptului c bazele
de date native XML nu necesit scheme, ca bazele de date relaionale,
ele pot s trateze acest tip de date, dei aplicaiile adesea necesit
procesarea acestor date de ctre oameni.Ultima utilizare majora a
bazelor de date native XML este tratarea evoluiei schemelor. Chiar
dac bazele de date native XML nu ofer soluii complete, ele ofer o
flexibilitate mai mare dect bazele de date relaionale. De exemplu,
bazele de date native XML nu necesit ca datele existente s fie
mutate ntr-o alt schem, ele pot trata modificri ale schemelor
pentru care nu exist nicio cale a migraiei, i pot stoca date chiar
dac acestea aparin unei versiuni necunoscute a unei scheme.Alte
utilizri ale bazelor de date native XML includ punerea la dispoziie
de cache pentru date i metadate pentru tranzacii lungi, operarea cu
documente mari i date ierarhice, i comportarea ca un intermediar
ntre date i cache (mid-tier data cache).3.4.3.1 Ce este o baz de
date nativ XML?Termenul baz de date nativ XML a aprut prima dat n
campania de marketing a Tamino, o baz de date nativ XML dezvoltat
de Software AG. Probabil datorit succesului acestei campanii,
termenul a fost acceptat de ctre companiile care dezvoltau produse
similare. Dezavantajul acestui termen este c fiind un termen de
marketing, nu a avut niciodat o definiie formal tehnic.O definiie
posibila (dezvoltat de membrii XML:DB) este aceea c o baz de date
nativ XML are urmtoarele caracteristici:Definete un model logic
pentru un document XML spre deosebire de datele din acel document i
stocheaz i recupereaz documente conform acelui model. Modelul
trebuie s includ minim elemente, atribute, PCDATA, i ordinea
documentelor. Exemple de astfel de modele sunt modelul de date
Xpath, XML Infoset, i modelele coninute de DOM i evenimentele din
SAX 1.0.Are ca unitate fundamental de stocare logic un document
XML, aa cum o baz de date relaional are ca unitate de baz de
stocare logic o linie dintr-o tabel.Nu este necesar un model fizic
special de stocare a datelor. De exemplu, acesta poate fi construit
pe o baz de date relaional, ierarhic, sau orientat pe obiecte, sau
se poate folosi un format de stocare particular cum ar fi fiierele
comprimate indexate.Prima parte a acestei definiii este similar cu
definiiile altor tipuri de baze de date, i se concentreaz pe
modelul folosit de baza de date. Nu are nicio importan faptul c o
anumit baz de date nativ XML ar putea stoca mai multe informaii
dect conine modelul folosit de baza de date. De exemplu, ar putea
suporta interogri bazate pe modelul Xpath, dar s stocheze documente
ca text. n acest caz, seciunile CDATA i folosirea entitilor sunt
stocate n baza de date dar nu sunt incluse n model.A doua parte a
definiiei spune c unitatea de baz de stocare ntr-o baz de date
nativ XML este un document XML. Dei poate prea posibil ca o baz de
date nativ XML ar putea atribui acest rol fragmentelor de
documente, bazele de date native XML sunt populate cu documente
complete.Unitatea de baz de stocare este nivelul elementar de
context n care se potrivete un anumit element de date, i este
echivalent cu o linie ntr-o baz de date relaional. Existena acestei
uniti de baz nu mpiedic recuperarea unor uniti mai mici de date,
cum ar fi fragmente de documente sau elemente individuale, i nu
exclude nici posibilitatea combinrii fragmentelor dintr-un document
cu fragmente din alt document. n termeni relaionali, acest lucru
este echivalent cu faptul c existena liniilor nu mpiedica
recuperarea individual a valorilor din coloane sau crearea unor
linii noi din altele existente deja. A treia parte a definiiei
spune c formatul de stocare nu este important. Acest lucru este
adevrat, i este analog cu faptul c formatul fizic de stocare
folosit de o baz de date relaional nu are legtur cu faptul ca baza
de date este relaional.3.4.3.2 Arhitecturile bazelor de date native
XMLArhitecturile bazelor de date native XML se clasific n dou
categorii: bazate pe text i bazate pe modele.Baze de date native
XML bazate pe textO baz de date nativ XML bazat pe text stocheaz
XML ca text. Acesta ar putea fi un fiier ntr-un sistem de fiiere,
un BLOB ntr-o baz de date relaional, sau un format de text
particular. Nu are nicio importan faptul c o baz de date relaional
care a adugat procesarea ce recunoate XML a coloanelor CLOB
(Character Large Object) este, de fapt, o baz de date nativ XML
avnd n vedere aceste abiliti.Toate bazele de date native XML bazate
pe text au n comun indecii, care ofer posibilitatea motorului de
interogare s sar uor n orice punct din orice document XML. Acest
lucru d o vitez extraordinar la recuperarea documentelor ntregi sau
a fragmentelor de documente. Acest lucru se ntmpla deoarece baza de
date poate executa o singur cutare indexat, poate poziiona capul de
citire o singur dat, i, presupunnd c fragmentul necesar este stocat
continuu pe disc, poate recupera ntregul document sau fragment cu o
singur citire. Spre deosebire de aceasta modalitate, reasamblarea
unui document din fragmente, cum se face n cazul bazelor de date
relaionale i unele baze de date native XML bazate pe modele,
necesit cutri indexate multiple i mai multe citiri ale discului.n
acest sens, o baz de date nativ XML bazat pe text este similar cu
bazele de date ierarhice, amndou avnd performane mai bune dect
bazele de date relaionale la recuperarea i returnarea datelor n
funcie de o ierarhie predefinit. La fel ca bazele de date
ierarhice, bazele de date native XML bazate pe text ar putea
ntmpina dificulti la recuperarea i returnarea datelor n orice alt
form, cum ar fi inversarea ierarhiei sau a unor poriuni ale ei.
Acest lucru nu a fost dovedit nc, dar predominana bazelor de date
relaionale, care folosesc pointeri logici ce permit ca toate
interogrile de aceeai complexitate s fie executate cu aceeai vitez,
pare s indice c aa se va ntmpla. Baze de date native XML bazate pe
modeleA 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