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 informaii dintre diverse sisteme eterogene. Din acest motiv, este important ca o baz de date s fie capabil s stocheze informaiile nu doar n formatele tradiionale, relaionale, ci i n format XML. Stocnd datele XML n format nativ se ctig foarte mult n performan, aceasta materializndu-se n costuri reduse. Un plus de performan la o tehnologie de baze de date nseamn o infrastructur redus, servere cu mai puine procesoare, deci un sistem informatic ceva mai ieftin, costuri mai mici pentru liceniere, deci per total o economie de bani. Standardul industrial al datelor n format XML prezint o serie de avantaje i dezavantaje. Avantajul major este acela c este adoptat de toi productorii de tehnologie din industrie, dar n schimb are dezavantajul c este un format nu foarte eficient din punct de vedere al stocrii datelor. De aceea devine foarte util ca baza care stocheaz aceste date sa aib capabiliti de compresie, care s duc la scderea spaiului i resurselor de stocare necesare pentru a pstra date n format XML. Lucrarea de fa i propune s prezinte n capitolele sale cteva noi direcii de dezvoltare n domeniul bazelor de date, modelul de date semistructurat i tehnologia XML ca o nou baz de date. Capitolul I prezint necesitatea apariiei modelului semistructurat al datelor, datorit nevoii de interogare a unor surse de date care nu au o schem predefinit sau a unor date care provin din surse diferite i au scheme diferite. Modelul semistructurat al datelor reprezint schema (tipul, structura) i instana (valoarea) datelor n mod uniform, permind interogarea lor simultan spre deosebire de modelele de date convenionale, care difereniaz ntre cele dou tipuri de informaie. Capitolul II detaliaz modelul semistructurat al datelor definind conceptul de date neconvenionale din mai multe perspective i pe cel de date semistructurate prezentnd avantajele acestui tip de date, modelarea acestor date i limbajele de interogare a acestora, i
Pagina 1 din 97
prezint n detaliu tipul de date MPEG-21 ca suport pentru integrarea datelor n aplicaii multimedia distribuite. Capitolul III prezint legtura dintre tehnologia XML i bazele de date ncercnd s clarifice n ce msur este XML-ul o baz de date, reprezentarea datelor i documentelor, stocarea i recuperarea datelor, stocarea datelor n baze de date native XML, generarea schemelor XML din scheme relaionale i invers, stocarea documentelor n sistemul de fiiere i n BLOB-uri, detaliaz bazele de date native XML, i prezint noiunile de DOM (Document Object Model) persistent i sisteme de management ale coninuturilor. Capitolul IV se ocup de construirea documentelor XML prezentnd sintaxa XML, descrierea de vocabulare noi cu XML, avantajele definiiei tipurilor documentului, combaterea dezavantajelor definiiei tipurilor documentului, definirea unui document XML ca ntreg, declaraia XML, documentele autonome, construirea unui document XML, declaraia tipului documentului i prezint cteva aplicaii din lumea real a declaraiei tipului documentului. Capitolul V const n prezentarea aplicaiei magazinul virtual ElectronX - i prezint scopul acestei aplicaii, cerinele minime hardware i software ale aplicaiei, funcionalitile de baz ale acestui website, proiectarea bazei de date coninnd schema conceptual a structurii bazei i schema fizic a fiecrei tabele, implementarea codului n care sunt explicate fiierele cele mai importante ale aplicaiei cu exemplificri din codul surs, un manual de utilizare al aplicaiei n care e descris modul de funcionare al acesteia i concluzii asupra aplicaiei.
CAPITOLUL I NOI MODELE DE DATE I APLICAIILE LOR 1.1 Interogarea World-Wide-Web-ului Exist surse de date, ca de pild World-Wide-Web-ul, pe care am dori s le interogm ca baze de date, dar care nu pot fi constrnse de o schem. Majoritatea interogrilor web-ului folosesc tehnici de regsire a informaiei pentru a gsi pagini dup coninut. Exist ns puine posibiliti de formulare a interogrilor n vederea exploatrii structurii web-ului i, deoarece aceasta nu este conform cu nici un model de date standard, este necesar o metod de descriere a acestei structuri. Modelul de date semistructurat a fost propus n vederea satisfacerii acestei necesiti. Ideea central n modelul semistructurat este de a reprezenta datele sub forma unui graf
Pagina 2 din 97
etichetat. Structura documentelor hipertext este capturat interpretnd arcele grafului drept legturi. O reprezentare posibil este cea introdus n proiectul UnQL[1]. Etichetele arcurilor pot fi att valori (de tip ntreg, ir de caractere i alte tipuri de baz, precum i de tip de date abstract, ca video, audio, etc.) ct i nume de atribute (Film, Titlu, Regizor, Actor), etc. modelnd de exemplu cunoscuta baz de date cinematografic IMDB [2]. Exist numeroase limbaje de interogare pentru modelul semistructurat. Toate aceste limbaje sunt construite pe baza ideii de expresii asociate cilor (path expressions). Acestea sunt expresii regulate ce exprim ci generice n graful etichetat, permind astfel traversarea grafului i colecionarea tuturor etichetelor ce satisfac o anumit condiie de selecie. Limbajele semistructurate pot fi clasificate n dou categorii, dup strategia de calcul adoptat. Prima categorie, dezvoltat oarecum ad-hoc, se bazeaz pe modelarea grafurilor n modelul relaional i apoi pe interogarea lor ntr-un limbaj relaional de tip SQL. Cteva exemple prezentate n literatur sunt [3], [4], [5], [6], [7] A doua categorie pornete de la un limbaj bazat pe o noiune formal de calcul cu date semistructurate: limbajul UnQL este reprezentantul acestei categorii [1]. Acest limbaj pornete de la recursivitatea structural, forma natural de recursivitate asociat cu tipul de date grafuri etichetate. Datorit bazei sale teoretice, UnQL este capabil de restructurri complexe, n adncime, spre deosebire de limbajele din prima categorie, care se limiteaz la scoaterea la suprafa a datelor din graf, fr ns a crea noi structuri. Aceast capacitate de restructurare st la baza proiectului STRUDEL[8] care propune limbajul StruQL de gestiune a sit-urilor de web. Un alt avantaj al bazei teoretice a limbajelor UnQL i StruQL este posibilitatea efecturii optimizrilor specifice acestui nou model de date. Limbajele din prima categorie pot beneficia doar de optimizrile specifice modelului relaional, deci dezvoltate pentru alt model de date i n consecin nu att de folositoare. 1.2 Integrarea surselor de date eterogene Integrarea datelor provenind din surse eterogene (cu scheme disparate sau, mai grav, modelate diferit), este un domeniu de cercetare care, dei consacrat de mai bine de un deceniu, continu s rmn n centrul ateniei multor cercettori. Cercetarea n acest domeniu este motivat de absena unui model de date atotcuprinztor, fapt ce ngreuneaz dezvoltarea de software care convertete date ntre dou modele diferite. O complicaie adiional este reprezentat de faptul c majoritatea datelor stocate electronic nu se afl n baze de date convenionale, ci n sisteme de fiiere, programe de bibliotec, de pot electronic, foi de calcul etc., care prezint capaciti de interogare limitate.
Pagina 3 din 97
Ultima observaie a reprezentat punctul de plecare al proiectului Tsimmis [9][10] de la Stanford. Proiectul Tsimmis i propune integrarea att a surselor de date care sunt conforme cu modelele de date standard (relaional, orientat pe obiecte), ct i a surselor de date cu capaciti de interogare limitate. Aceste surse neconvenionale sunt mpachetate n aa-numii wrappers (ambalaje). Un astfel de ambalaj asigur interfaa ntre sursa de date cu capaciti de interogare limitate i aplicaia care o interogheaz. Aplicaia trimite ctre surs interogri ntr-un limbaj expresiv cum ar fi SQL sau OQL i ateapt rezultatul ntr-un format numit OEM (Object Exchange Model). OEM folosete grafuri etichetate, ca structur de date, care captureaz majoritatea datelor folosite n aplicaii de baze de date. n acelai timp, toate celelalte structuri de date pot fi codificate ca grafuri OEM. Rolul ambalajului const n: interceptarea interogrii i identificarea acelor pri ale acesteia care pot fi efectuate de ctre surs, translatarea acestor pri n limbajul specific sursei, recepionarea i prelucrarea rezultatelor intermediare n vederea reconstituirii rezultatului interogrii originale, codificarea rezultatului final n formatul OEM i transmiterea acestuia ctre aplicaie. Evident, dac interogarea original este prea complex, este posibil s nu poat fi efectuat pornind de la capabilitile limitate ale sursei. Ambalajul detecteaz aceast situaie i anun sursa c nu i poate satisface cererea. Cu ct crete capacitatea de evaluare a interogrilor n cadrul ambalajului (de exemplu, capacitatea de a efectua operaii de tip join, proiecii, selecii, etc.), cu att se extinde clasa de interogri pe care le poate satisface combinaia surs-ambalaj. Un proiect similar, cu scopul interogrii surselor de date structurate din web este [13]. Se remarc similaritatea dintre modelul OEM i cel semistructurat. ntr-adevr, Lore [11],[12] este un sistem de interogare a datelor semistructurate, foarte similar cu UnQL, utiliznd un model de date inspirat de OEM. 1.3 Navigare n Internet n anumite situaii este avantajos s privim bazele de date convenionale ca fiind semistructurate. Un exemplu este activitatea de navigare n Internet. n general, utilizatorul nu poate interoga o baz de date fr a-i cunoate schema. Din nefericire ns, aceasta este adeseori greu de neles, datorit mrimii exagerate (zeci de tabele, de exemplu) i a terminologiei opace, nestandard, folosite de ctre proiectanii bazei de date.
Pagina 4 din 97
Descifrarea schemei ar fi considerabil uurat de facilitatea de a interoga datele avnd doar o nelegere parial a structurii lor. De exemplu, n cazul bazei de date cinematografice din World-Wide Web[2], urmtoarele interogri ar fi de folos: n Exist n care baza atribut de gsim date irul ntregi de mai caractere mari Casablanca? dect 216?
Ce obiecte din baza de date au un atribut al crui nume ncepe cu act? i n acest domeniu, modelul semistructurat se dovedete a fi folositor. Spre deosebire de modelele de date convenionale, care difereniaz ntre schema (tipul, structura) i instana (valoarea) datelor, modelul de date semistructurat reprezint cele dou tipuri de informaie n mod uniform, permind interogarea lor simultan. Din acest motiv, datele semi-structurate se numesc i autodescriptive. [1] prezint un elegant limbaj de interogare care permite exprimarea concis a acestor interogri. 1.4 Cubul de date i OLAP Sistemele de suport pentru decizii (Decision support systems) sunt utilizate de ctre companiile moderne pentru integrarea ntr-o baz de date central numit data warehouse (magazia central de date), a datelor provenind din baze de date mici operaionale folosite n diferite domenii de activitate/filiale ale companiei. Datele astfel acumulate sunt analizate n timp real (OLAP: On-Line Analitical Processing) pentru a asista conducerea companiei n luarea deciziilor strategice de dezvoltare [14] (de exemplu, analiznd vnzrile unui anumit produs pe trimestru i zon geografic, se poate stabili o nou strategie de marketing pentru acest produs). Datele din magazia central de date sunt modelate sub forma unui (hiper)cub de date multidimensional [15]) care poate fi analizat la nivelul subcuburilor de granularitate arbitrar. Subcuburile se obin prin agregarea cuburilor din care provin. De exemplu, prin nsumarea vnzrilor trimestriale pentru fiecare zon, cubul de date tridimensional reprezentnd vnzrile pe trimestru i zona geografic poate fi redus la un subcub bidimensional (plan) reprezentnd vnzrile pe zona geografic. Agregarea este o operaie costisitoare, efectuarea ei eficient pe un volum mare de date reprezentnd elul principal al cercetrii n acest domeniu ([16],[17],[18],[19]). 1.5 Noi modele tranzacionale n mod tradiional, tranzaciile modeleaz uniti de lucru atomice i izolate, efectuate asupra datelor sistemului de gestiune a bazelor de date.
Pagina 5 din 97
Izolarea tranzaciilor nu permite crearea tranzaciilor complexe, mari, din tranzacii simple. Acest model a avut succes atta vreme ct tranzaciile efectuau un numr mic de operaii simple asupra datelor cu structur simpl. Din pcate, modelul tranzaciilor simple nu satisface cerinele aplicaiilor complexe, n care tranzaciile trebuiesc combinate i coordonate pentru a colabora la realizarea unui scop complex. Aplicaii ca proiectarea asistat de calculator, automatizarea activitii de birou, controlul produciei, gestiunea activitilor necesit noi modele tranzacionale, noi metode de gestiune a tranzaciilor, i noi limbaje de specificare a tranzaciilor. Limbajele tranzacionale sunt limbaje de nivel nalt, de obicei inspirate din logica cu predicate de ordinul nti. Dac limbajele tradiionale specificau interogri i actualizri, noile limbaje tranzacionale se concentreaz asupra relaiei dintre tranzacii, exprimnd dependene de tipul tranzacia T2 nu poate porni nainte ca T1 s se termine, sau T2 poate ncepe dac T1 ntoarce o valoare mai mare ca 25. [20] prezint o clasificare i analiza detailat a noilor limbaje tranzacionale. Un excelent exponent al noii generaii de limbaje tranzacionale este Transaction Datalog [21], un limbaj deductiv care menine n acelai timp toate proprietile tranzaciilor clasice, cum ar fi: persisten, atomicitate, izolare, terminare i rollback (revenire). Limbajul este nsoit de un model teoretic natural i de o teorie sigur pentru demonstraii, permind astfel demonstrarea echivalenei ntre diverse expresii din acest limbaj. Acest fapt este crucial pentru optimizare - care const din nlocuirea unei planificri cu o alta echivalent din punct de vedere al efectului su asupra datelor, dar mai eficient din punct de vedere al costului execuiei. Mai mult, faptul c putem demonstra c efectul unei tranzacii complexe asupra setului de date este sau nu cel scontat, asigur consistena datelor. 1.6 Optimizri Optimizarea limbajelor de interogare a bazelor de date nu este un domeniu nou, ci dimpotriv, exist nc de la apariia acestora. Datorit importanei sale, acest domeniu va fi ntotdeauna la mod n cercetarea bazelor de date. Apariia unui nou model de date atrage dup sine o efervescen n activitatea de cercetare a posibilitilor de optimizare a limbajului de interogare asociat noului model. Referinele bibliografice introduse n seciunea anterioar prezint i primele ncercri de optimizare a noilor limbaje de interogare.
Pagina 6 din 97
CAPITOLUL II MODELE DE REPREZENTARE A DATELOR NECONVENIONALE 2.1 Definirea conceptului de date neconvenionale n literatura de specialitate exist o serie de definiri ale conceptului de date neconvenionale i a altor concepte asociate acestuia: Datele neconvenionale sunt datele care nu au nici unul din tipurile standard: ntreg, real etc. [Blanken, 2002] Structura de date neconvenional este structura de date care nu este n uzul curent al aplicaiilor; aceasta poate fi structura produs de datele semistructurate, cea definit noilor tipuri de date folosite n aplicaii i date cu structuri ce se modific n mod dinamic. [GSIHT, 2005] A patra generaie a tehnologiilor bazelor de date este prezentat n [Mannino, 2004] ca fiind o extensie a tehnologiilor bazelor de date cu datele neconvenionale i Internetul. Sistemele celei de-a patra generaii pot stoca i manipula tipuri de date neconvenionale cum sunt: imaginile, secvenele video, hrile, sunetele i animaiile i permit accesul la bazele de date Web. Unul din obiectivele sistemelor de gestiune a bazelor de date orientate obiect este prezentat ca fiind extinderea flexibilitii cu datele neconvenionale i procedurile de prelucrare asociate acestora, inclusiv text, grafic i voce, date care nu pot fi manipulate i integrate de sistemele de baze de date convenionale. La University of Southern California din Los Angeles (USC) exist un laborator de informare numit InfoLAB al crui scop este investigarea de noi metode pentru gestiunea tipurilor de date neconvenionale cu arhitecturi atipice. Principalele zone de cercetare sunt: Gestiunea fluxurilor de date multidimensionale n arhitecturi de tip punct la punct (peer-to-peer), Analiza datelor multidimensionale, Gestiunea datelor peer-to-peer, Prelucrarea interogrilor de stream-uri, Baze de date spaio-temporale. Descrierea datelor neconvenionale se realizeaz folosind metadate. Metadatele sunt folosite pentru descrierea altor date, cu o structur complex sau nestructurate. Metadatele pot fi privite din diferite perspective, n funcie de productorul sau sursa metadatelor:
Pagina 7 din 97
- Din perspectiva productorului de coninut, metadatele sunt utilizate pentru stocarea informaiilor bibliografice ale resurselor, ca de exemplu: numele autorului, titlul, data crerii, formatul resursei etc. - Din perspectiva furnizorilor de servicii, metadatele ofer informaii descriptive cu valoare adugat (majoritatea n format XML), care reduc informaiile necesare regsirii datelor. Metadatele conin informaii despre diferitele formate n care este disponibil o resurs i informaii semantice asociate acesteia. Aceste informaii sunt utile pentru realizarea interogrii datelor. - Din perspectiva consumatorului, metadatele ofer informaii suplimentare care descriu preferinele consumatorului i resursele disponibile pentru utilizarea datelor. Metadatele permit personalizarea consumului mediilor i trebuie luate n considerare de productori. Metadatele sunt utile pentru distribuirea datelor n Internet sau n reele mobile permind accesul la resurse n cele mai bune condiii posibile; de exemplu, metadatele pot fi folosite pentru descrierea modului n care difuzarea secvenelor video este adaptat la scderea lrgimii de band disponibil la un moment dat. 2.2 Modelul semistructurat ale datelor Modelele relaional i orientat-obiect au fost folosite mult timp pentru modelarea datelor nu neaprat pentru c erau cele mai naturale soluii, ci pentru c au n spate un formalism bine definit. n timp ns, datorit dezvoltrii Internetului i datorit necesitii integrrii datelor descrise folosind scheme diferite, modelele tradiionale s-au dovedit a nu mai fi suficiente i a devenit acut necesitatea utilizrii unui alt model de date, modelul semistructurat al datelor. n plus, aplicaiile Internet realizeaz operaii care nu sunt curente n aplicaiile tradiionale cu baze de date cum ar fi: transformri ale datelor, interpretarea interogrilor, transportul datelor i prelucrarea bazat pe fluxuri. Datele semistructurate au devenit un important subiect de studiu din mai multe motive: n primul rnd, exist surse de date pe care am vrea s le tratm ca baze de date dar crora nu le putem impune constrngeri avnd la baz o schem, ca n cazul bazelor de date tradiionale [Buneman, 1997]. Chiar i datele structurate, au structur care poate s difere de la o aplicaie la alta sau au structur modificabil n timp. Dezvoltrile din domeniul multimediei au dus la necesitatea de a introduce noi tipuri de date n domeniul tehnologiei bazelor de date convenionale. Unele tehnologii necesit doar extensii ale modelelor de date existente, prin optimizarea tehnicilor de manipulare i interogare a noilor tipuri de date, dar
Pagina 8 din 97
altele nu pot fi ncadrate n modelele clasice de gestiune a datelor. Cel mai evident exemplu de date care nu pot fi ncadrate ntr-o schem sunt datele manipulate prin intermediul Webului. Majoritatea interogrilor Web exploateaz tehnicile de regsire a datelor pentru a determina paginile individuale care au coninut ce corespunde criteriului solicitat. Dar numai o mic parte din resursele Web sunt structurate astfel nct s permit rezolvarea interogrilor, Web-ul nefiind conform nici unui model standard. Astfel c se simte nevoia de a gsi o metod pentru descrierea structurii datelor Web n vederea rezolvrii acestei probleme. Al doilea motiv este dat de necesitatea schimbului de date ntre aplicaii care folosesc formate diferite de stocare i gestiune a datelor necesitnd astfel transformarea datelor. Nici unul din modelele de date existente nu este acceptabil din toate punctele de vedere i n plus este dificil s convertim datele dintr-un model n altul. Astfel, s-a simit nevoia s se dezvolte un model care s lege cele dou lumi diferite: relaional i orientat obiect, acesta este modelul semistructurat al datelor. n plus, datele n format electronic se afl n medii diferite, interconectate care trebuie s comunice ntre ele. Dar i cnd se folosesc datele structurate poate fi util ca acestea s fie privite ca date semistructurate, din motive care in de manipularea acestora, fiind util s existe un format flexibil pentru schimbul de date ntre diferite tipuri de baze de date. [Buneman, 1997] O parte din aceste date se gsesc sub forma datelor nestructurate, ca de exemplu sunetele, imaginile, secvenele video i chiar unele documente text, iar alt parte sub forma datelor structurate, memorate n baze de date relaionale sau orientate obiect. n general, un utilizator nu poate scrie o interogare pentru o baz de date fr s cunoasc schema de organizare a datelor, iar aceasta este netransparent pentru utilizatori i raionamentul folosit la proiectarea ei este adesea greu de determinat. Au fost dezvoltate limbaje care permit interogarea simultan a datelor i a schemelor de organizare a bazelor de date, dar aceste limbaje nu au flexibilitatea s manipuleze constrngeri complexe. 2.2.1 Conceptul de date semistructurate n general, prin termenul de date semistructurate sunt denumite datele care nu respect formate stricte cum ar fi cele impuse de modelele bazelor de date relaionale sau orientate obiect. n mod evident o astfel de definiie este imprecis. Datele sunt semistructurate dac: nu au o structur rigid (de exemplu datele Web, datele sunt combinate din cteva surse eterogene - ca n cazul depozitelor de date), nu au o structur implicit
Pagina 9 din 97
asociat datelor, sau au o structur parial specificat [Abiteboul, 1997]. Modelele orientatobiect i relaional au o schem fix pentru fiecare clas sau fiecare relaie. Datele semistructurate permit o flexibilitate sporit, fiind o combinaie a celor dou concepte: clasa i relaia. Datele semistructurate conin informaii despre schema lor i aceast schem poate diferi, n timp, n cadrul unei singure baze de date. Acest model care nu se bazeaz pe nici o schem, are un rol special n sistemele bazelor de date. n acest model datele sunt autoreferite, acest lucru nsemnnd c schema este ataat datelor. Combinarea unor date dintr-o baz de date relaional cu altele dintr-o baz de date orientat-obiect se poate realiza prin conectarea celor dou baze de date, prin intermediul unei interfee, translatnd datele de la fiecare surs n date semistructurate. n modelul semistructurat al datelor, informaiile care sunt n mod normal asociate unei scheme sunt incluse n interiorul datelor. n aceste baze de date nu exist o distincie clar ntre date i schem, iar gradul de structurare depinde de aplicaie. n anumite forme ale modelului semistructurat exist o schem distinct, n altele nu. Avantajele modelului semistructurat al datelor sunt urmtoarele: Flexibilitatea - simplific integrarea bazelor de date care au scheme diferite. Spre deosebire de alte modele, care au o schem de descriere a datelor, modelul semistructurat este fr schem, ceea ce justific flexibilitatea sa. Flexibilitatea reprezint un instrument util pentru integrarea datelor, mai ales n cazul problemelor legate de motenirea bazei de date. mbuntirea eficienei regsirii datelor publicate n Internet Posibilitatea integrrii datelor Documentele HTML i cele stocate n biblioteci digitale sunt semistructurate. Spre deosebire de fluxurile nestructurate de date (precum imagini, sunete, video), datele semistructurate au o structur i spre deosebire de datele structurate (bazele de date relaionale sau orientate-obiect), datele semistructurate nu au o schem absolut sau o clas fix, fiecare obiect coninnd propria schem. Iregularitatea structural nu implic inexistena similaritilor structurale ntre obiecte. Din contr, n mod obinuit, obiectele semistructurate care descriu acelai tip de date au structur similar. Modelul datelor semistructurate este un model pentru integrarea bazelor de date. Este folosit pentru descrierea datelor aflate n dou sau mai multe baze de date care conin date similare n diferite scheme de organizare. 2.2.2 Modelarea datelor semistructurate
Pagina 10 din 97
Datele semistructurate sunt modelate, n general, sub forma structurilor de tip graf sau arbore, n noduri avnd reprezentate obiecte iar arcele reprezentnd atributele obiectelor. n plus, arcele modeleaz natural relaiile de subordonare dintre dou obiecte. [Reveiu, 2003] Modelul de facto pentru datele semistructurate este OEM (Object Exchange Model), model propus n proiectul pentru integrarea datelor numit TSIMMIS i descris pentru prima dat n lucrarea Multimedia database systems Design and implementation Strategies. OEM este un model autodescriptibil, nefiind necesar definirea anterioar a structurii unui obiect i nici nu exist o schem fix de reprezentare a datelor. Fiecare obiect reprezentat conine propria lui schem. Fiecare obiect din OEM poate avea un identificator (Id), o etichet, un tip i o valoare. Id-urile obiectelor pot fi simboluri cu sau fr nelesuri speciale. De exemplu, dac un obiect este o pagin Web, URL-ul paginii poate fi folosit ca id-ul obiectului. Etichetele nodurilor sunt iruri care expliciteaz rolul obiectului pentru utilizator i pentru aplicaii. Eticheta joac aici dou roluri: identific un obiect i d sens obiectului. Obiectele pot fi atomice sau complexe (seturi de obiecte). Valorile obiectelor atomice au tipuri atomice (valori ntregi, reale, iruri de caractere, imagine, sunet etc.), iar cele complexe au ca valori seturi de obiecte, reprezentate prin perechi de tipul atribut-obiect. Prin urmare, un obiect complex va avea o definire recursiv deoarece valoarea unui obiect este parte a sa. Nodurile frunz au asociate ntotdeauna valori atomice. Etichetele arcelor reprezint atribute, sunt descrise prin iruri de caractere i reprezint un set de proprieti descriptive. O proprietate poate fi folosit ntr-un arc pentru a descrie nodurile nvecinate.
Pagina 11 din 97
n figura 1 este prezentat exemplificarea modelrii unei pri dintr-o baz de date multimedia folosind OEM. Figura 1 Modelul OEM al unei pri dintr-o baz de date multimedia Informaii: &o1 {film: &o21 {titlu: &o30 Titanic, actor principal: &o31 {nume: &o41 DiCaprio, prenume: &o42 Leonadro}, regizor: &o32 {nume: &44 Cameron, prenume: &o45 James}, { actor principal: &o33, nume: &o46 Kate, prenume: &o47 Winslet}, premii obinute: &o48 11 Oscaruri}, melodie: &o22 {titlu: &49 My heart will go on, interpret: &o34 {nume: &o50 Dion,
Pagina 12 din 97
prenume: &o51 Celine}, premii: & o35 {an: &o52 1998, nume: Oscar pentru cea mai bun coloan sonor}, coloan sonor: &o22}} Datele stocate n baze de date relaionale pot fi descrise cu uurin folosind OEM. n plus, OEM asigur o flexibilitate mai mare n descrierea datelor tolernd lipsa unor atribute pentru anumite nregistrri sau existena mai multor valori pentru acelai atribut n cadrul unei singure nregistrri. OEM poate fi considerat mai apropiat de modelul orientat-obiect dect de cel relaional, n care dou obiecte distincte chiar dac au valori identice, au existen de sine stttoare, reprezentnd instane diferite. Scheme de organizare a datelor semistructurate Flexibilitatea n descrierea informaiilor adus de modelarea datelor semistructurate are i dezavantaje, i anume dificultatea formulrii unei interogri relevante. S-a ncercat asocierea unor scheme n modelarea datelor semistructurate, n acest sens existnd dou abordri: scheme flexibile descriu aprioric datele; schemele flexibile fiind concepute astfel nct s permit flexibilitate n descrierea datelor; se folosete tipul void pentru manipularea oricrui tip de dat. scheme rigide descriu cu exactitate datele i sunt folosite pentru analiza datelor; schema este refcut ori de cte ori se produce o modificare a informaiei memorate. 2.2.3 Limbaje de interogare a datelor semistructurate Principalele elemente caracteristice ale unui limbaj de interogare pentru datele semistructurate sunt: Putere de expresie: pentru reprezentarea datelor relaionale sub forma datelor semistructurate, limbajul semistructurat trebuie s acopere operaiile corespunztoare unui limbaj relaional standard, dar n plus trebuie s dispun de faciliti de reorganizare a datelor, astfel nct aceeai informaie s poat fi regsit sub o alt structur; Semantic: cererile trebuie optimizate astfel nct s poat ine cont de semantica datelor, fiind necesar o semantic precis pentru transformarea i optimizarea cererilor; Schematizare: limbajul trebuie s poat recunoate structurile definite pentru a le putea manipula;
Pagina 13 din 97
Compunere: datele obinute n urma unei interogri pot fi folosite ca date de intrare n alte interogri, motiv pentru care limbajele trebuie s fie transparente. Au fost propuse, ntr-o serie de proiecte de cercetare pe aceast tem, cteva limbaje de interogare pentru datele semistructurate. Dou dintre acestea sunt: limbajul orientat-obiect Lorel, derivat din OQL (Object Query Language) i limbajul UnQL (Unstructured Query Language). Domeniul datelor semistructurate este unul n studiu i va avea un impact mare asupra unei multitudini de aplicaii, dar mai ales asupra aplicaiilor multimedia i a celor dezvoltate pentru mediul Internet. 2.3 MPEG-21 Suport pentru integrarea datelor n aplicaii multimedia distribuite n ciuda descrierilor complete i detaliate ale tipurilor datelor multimedia implementate n MPEG-7, aspecte legate de organizarea datelor i de infrastructura unui sistem multimedia distribuit nu pot fi descrise doar folosind metadate. Astfel c a fost iniiat un nou standard, MPEG-21 cu scopul de a oferi mecanisme de proiectare a sistemelor multimedia distribuite, de a crea un mediu unic, universal accesibil pentru livrarea i utilizarea resurselor multimedia n diferite condiii, ca de exemplu diferite tipuri de utilizatori, reele cu diferite caracteristici, terminale cu caracteristici diferite etc. 2.3.1 Prezentare general MPEG-21 este un standard ISO/IEC21000 al MPEG (Moving Picture Experts Group) care definete un cadru de lucru deschis pentru multimedia. Fora MPEG-21 este dat de urmtoarea situaie: exist multe resurse mutimedia ce pot fi folosite la construirea unei infrastructuri pentru distribuirea i utilizarea coninutului multimedia, dar nu exist nici o arhitectur pentru descrierea modului n care aceste elemente interacioneaz ntre ele. Scopul standardului MPEG-21 este s defineasc un cadru de lucru deschis pentru multimedia care s permit utilizarea transparent i la performane bune a resurselor multimedia folosind reele i dispozitive periferice diverse. Se urmrete gestiunea coninutului multimedia, gestiunea proprietii intelectuale i adaptarea coninutului la resursele disponibile prin intermediul diferitelor clase de servicii. MPEG-21 ofer un suport deschis pentru distribuirea i utilizarea datelor multimedia. [Kosch, 2004] MPEG acoper ntregul coninut multimedia din punctul de vedere al canalelor de distribuie folosite, al modalitilor de creare a coninutului, din punct de vedere al modalitii de producie, n vederea personalizrii, consumului, prezentrii i comercializrii acestuia. Pentru realizarea acestui lucru, MPEG-21 propune norme pentru un standard deschis pentru
Pagina 14 din 97
crearea, distribuirea i utilizarea datelor multimedia. Acest standard se refer la toi actorii implicai, de la creatorii de coninut, productori, distribuitori i furnizorii de servicii. MPEG-21 standardizeaz fluxul informaiilor i serviciilor multimedia de la crearea coninutului pn la livrarea ctre utilizatorii finali. Pentru a realiza acest lucru, coninutul trebuie identificat, descris, gestionat i protejat. Transportul i livrarea coninutului poate avea loc peste diferite reele, ntre o varietate de terminale. Exist o serie de arhitecturi aprute ca rspuns la varietatea tipurilor de aplicaii care utilizeaz coninutul multimedia. Exist trei modele principale folosite pentru gestiunea, descrierea i regsirea resurselor multimedia i anume Dublin Core, SMPTE i MPEG-7. Pentru a evita recomandarea unui model n defavoarea altuia, n mod nejustificat, MPEG-21 propune descrierea suportului multimedia sub forma unei arhitecturi generice. [ISO, 2001] MPEG-21 se bazeaz pe dou concepte eseniale: definirea unei uniti fundamentale de distribuie i tranzacionare - elementul digital i utilizatorii care interacioneaz cu elementele digitale. Elementul digital este un obiect digital, structurat care are o reprezentare standard, ce poate fi identificat i care are asociate metadate. Elementele digitale conin att resursele multimedia (coninutul) ct i metadatele asociate resurselor sau ntregului element digital. n accepiunea MPEG-21, utilizatorul este orice entitate care interacioneaz cu mediul MPEG-21 sau care folosete un element digital, ca de exemplu un consumator al datelor multimedia, o organizaie, sau un alt standard ce folosete resursele multimedia. Un utilizator poate folosi coninutul n mai multe feluri: prin publicare sau prin livrare i poate avea drepturi i responsabiliti specifice n funcie de modalitile de interaciune cu ali utilizatori n cadrul MPEG-21. Principalele elementele folosite n definirea arhitecturii MPEG-21 sunt: Elementul digital - este un container ierarhic de resurse eterogene (video, audio, text etc.), metadate i alte elemente digitale. Un element digital este o unitate elementar de distribuie i tranzacionare; Declararea elementului digital definete un set de termeni folosii la declararea elementelor digitale; Identificarea i descrierea elementului digital presupune identificarea i descrierea elementului digital, natura lui, tipul sau granularitatea (film, scen sau cadru); Gestiunea i utilizarea coninutului ofer interfee i protocoale care permit crearea, manipularea, cutarea, accesarea, stocarea, livrarea i reutilizarea coninutului de-a lungul canalelor de distribuie i consum;
Pagina 15 din 97
Protejarea i gestiunea proprietii intelectuale permite gestiunea coninutului i protejarea elementelor digitale ntr-o serie de reele i dispozitive; Terminale i reele ofer instrumente ce permit accesul transparent la coninut prin intermediul reelelor i terminalelor, realiznd inclusiv controlul calitii serviciului; Reprezentarea coninutului cum sunt reprezentate resursele media; Raportarea evenimentelor conine metrici i interfee ce permit utilizatorilor s evalueze performanele tuturor evenimentelor raportabile din cadrul sistemului. Structura MPEG-21 n prezent sunt definite 18 pri ale MPEG-21: [ISO/IEC 21000-1-18] : Partea 1: Tehnologiile i strategia MPEG-21, Partea 2: Declararea elementului digital (DID) Partea 3: Identificarea elementului digital (DII) Partea 4: Gestiunea i protecia proprietii intelectuale (IPMP) Partea 5: Limbajul de reprezentare a drepturilor (REL) Partea 6: Dicionar de drepturi ale datelor (RDD) Partea 7: Adaptarea elementului digital (DIA), Partea 8: Software de referin Partea 9: Formate de fiiere pentru stocarea i regsirea elementelor digitale ale MPEG-21 Partea 10: Prelucrarea elementelor digitale Partea 11: Asocieri persistente Partea 12: Testare distribuirii resurselor MPEG-21 Partea 13: Codarea secvenelor video scalabile Partea 14: Conformana Partea 15: Raportarea evenimentelor Partea 16: Formatul binar Partea 17: Identificarea fragmentelor Partea 18: Streaming-ul elementului digital 2.3.2 Declararea elementelor digitale Declararea elementului digital presupune definirea unui set de termeni i concepte folosite la definirea elementelor digitale, la descrierea sintaxei i semanticii fiecrui element digital i a schemei de reprezentare n XML. Declararea unui element digital se realizeaz n 3 etape: - Crearea modelului abstract,
Pagina 16 din 97
- Reprezentarea modelului abstract n XML, - Crearea schemei XML. Modelul abstract definete un set de termeni i concepte care formeaz un model pentru declararea elementelor digitale. Modelul abstract permite reprezentarea elementelor digitale n diferite moduri. Modelul abstract definete entitile necesare declarrii elementului digital. Un prim set de entiti este format din elementele de baz folosite pentru declararea elementelor digitale: - resursa este un flux de date identificabil, ca de exemplu un fiier video, imagine, secven audio sau text. - componenta are rolul de a lega una sau mai multe resurse de un set de descriptori ce conin informaii secundare referitoare la resursele componentei. Componenta este folosit doar pentru gruparea resurselor i a datelor secundare transmise printr-un descriptor. - elementul digital reprezint conectarea unuia sau mai multor elemente sau componente la un descriptor. Se pot crea elemente digitale individuale i elemente compuse. - descriptorul introduce un mecanism extensibil care poate fi folosit pentru asocierea informaiilor cu alte entiti ale modelului abstract. Un descriptor asociaz informaii textuale, secundare entitii incluse. - containerul reprezint asocierea unuia sau mai multor elemente digitale i/sau container(e) la un descriptor. Containerele sunt folosite pentru gruparea elementelor digitale. Descriptorul conine informaii despre containerul reprezentat. Pentru rafinarea descrierii resurselor se folosete urmtorul set de entiti: - fragmentul identific un anumit punct sau interval din cadrul unei resurse (secven video, audio etc.). Fragmentele sunt specifice tipului resursei. - ancora conecteaz descriptori de un fragment. n acest caz, descriptorii conin informaii despre fragmentele ancorei. Ancora este folosit pentru gruparea fragmentelor i descriptorilor. Exemplu de ancor: un moment de timp al unei resurse video, o form poligonal din cadrul unei resurse de tip imagine. - adnotarea permite adugarea de informaii la o entitate a modelului fr a modifica entitatea. - alternativa este o opiune din mai multe existente; ca de exemplu, alternativa unei conexiuni la Internet la o lrgime de band mare sau alternativa unei conexiuni prin dial-up. - selecia este opiunea utilizatorului din alternativele disponibile.
Pagina 17 din 97
- condiia pe baza seleciei utilizatorului, pot fi satisfcute (sau nu) condiiile asociate unei entiti a elementului digital i entitatea elementului digital poate deveni disponibil (sau nu). Reprezentarea modelului abstract n XML presupune descrierea sintaxei XML pentru fiecare entitate definit n modelul abstract. Aceast sintax formeaz limbajul de declarare a elementului digital al MPEG-21 (DIDL Digital Item Declaration). Declararea elementelor digitale reprezentate n conformitate cu sintaxa DIDL formeaz documentul DIDL. DIDL definete cteva elemente suplimentare care nu corespund entitilor modelului abstract: - Elementul DIDL ca rdcin a documentului DIDL, - Elementul Referin - reprezint o legtur la un alt element al documentului DIDL i include coninutul elementul refereniat n elementul referit. Referinele se pot face la elemente din acelai document DIDL sau la elemente din alt document DIDL. O referin intern permite pstrarea unei singure surse pentru un element care apare n documentul DIDL n mai multe locuri. Referina extern permite unui document DIDL s fie mprit n mai multe documente DIDL conectate. - Elementul Declaraii este folosit pentru definirea elementelor documentului DIDL, fr a le instania. Un element declarat poate fi instaniat folosind elementul Referin. Schema XML specific sintaxa DIDL i constrngerile pentru structura documentelor DIDL.
Relaia dintre modelul abstract MPEG-21 i DIDL este prezentat n figura 4.2. Figura 2 - Relaia dintre modelul abstract MPEG-21 i DIDL n continuare sunt prezentate componentele de baz ale schemei de declarare a elementelor digitale. Aceste elemente se folosesc n schemele documentelor XML.
Pagina 18 din 97
Schema de declarare a elementului digital Schema de declarare a unui element digital numit ElementDigital care are la primul nivel un container sau un alt element digital este: <xsd:schema targetNamespace = "urn:mpeg:mpeg21:2002:01DIDL-NS" xmlns = "urn:mpeg:mpeg21:2002:01-DIDL-NS" xmlns:xsd = "http://www.w3.org/2001/XMLSchema" version = "0.01"> <xsd:element name = "ElementDigital"> <xsd:complexType> <xsd:sequence> <xsd:element ref="Declaratii" minOccurs="0"/> <xsd:choice> <xsd:element ref="Container"/> <xsd:element ref="Element"/> </xsd:choice> </xsd:sequence> </xsd:complexType> </xsd:element> <xsd:schema> Container Containerul are o structur ierarhic, iar definirea sa se realizeaz recursiv: <xsd:element name="Container"> <xsd:complexType> <xsd:sequence> <xsd:element ref="Descriptor" minOccurs="0" maxOccurs="unbounded"/> <xsd:choice> <xsd:element ref="Referinta"/> <xsd:sequence> <xsd:element ref="Container" minOccurs="0" maxOccurs="unbounded"/> <xsd:element ref="Element" minOccurs="0" maxOccurs="unbounded"/>
Pagina 19 din 97
</xsd:sequence> </xsd:choice> </xsd:sequence> </xsd:complexType> </xsd:element> De exemplu, dac ntr-un element digital vor fi grupate mai multe elemente ce conin cte o secven video, atunci pentru fiecare secven se va folosi cte un container ce conine declararea elementului. Declararea descriptorului elementului digital compus este: <ElementDigital> <Container> <Descriptor> <Declarare mimeType = "video/avi">Secventele Video</Declarare> </Descriptor> <Element id = "Secventa1"> </Element> <Element id = "Secventa2"> </Element> </Container> </ElementDigital> 2.3.3 Adaptarea coninutului utiliznd MPEG-21 Standardul MPEG-21 faciliteaz dezvoltarea de soluii de adaptare a coninutului distribuit n funcie de caracteristicile tehnice ale terminalelor folosite pentru receptarea datelor, de caracteristicile tehnice ale mediului de comunicaie folosit sau n funcie de preferinele utilizatorului. Pentru adaptarea coninutului multimedia este necesar existena unei descrieri a mediului de lucru, pe lng descrierea coninutului propriu-zis. n vederea adaptrii coninutului multimedia trebuie s existe o descriere a sa, folosind unul din standardele adecvate, ca de exemplu Dublin Core, SMPTE sau MPEG-7. Partea a aptea a MPEG-21, denumit Adaptarea elementului digital (DIA) este dedicat descrierii caracteristicilor mediului i adaptrii elementelor digitale la aceste caracteristici.
Pagina 20 din 97
DIA definete doar instrumentele necesare n procesul de adaptare, nu realizeaz i adaptarea coninutului. Categoriile de instrumente descriptive folosite sunt: Instrumentele pentru descrierea mediului au rolul de a descrie caracteristicile semnificative ale contextului i anume: - caracteristicile terminalului folosit pentru receptarea sau crearea coninutului multimedia: posibilitile de codare/decodare ale terminalului, facilitile/dispozitivele de intrare-ieire conectate, alte caracteristici relevante; - caracteristicile reelei: capacitatea reelei, tipul conexiunii etc.; - caracteristicile utilizatorului: informaii despre utilizator, preferinele utilizatorului, un istoric al datelor utilizate, preferine legate de prezentarea informaiilor, caracteristici de accesibilitate i localizarea acestuia; - caracteristici ale mediul natural: atributele audiovizuale msurabile ale mediului natural, care afecteaz modalitatea n care coninutul multimedia este livrat i/sau consumat de utilizator: nivelul zgomotului, intensitatea luminii, fusul orar, locaia. Instrumentele de adaptare a resurselor sunt folosite pentru descrierea datelor structurale, ale fluxurilor de bii i a datelor despre adaptabilitatea metadatelor i se folosete pentru aceasta Binary Syntax Description Language. Descrierea se bazeaz pe mprirea fluxului de bii n componente logice, ca de exemplu mprirea unei secvene video n cadre. Fluxul de bii este apoi transformat de un motor pentru adaptarea resursei elementului digital ntr-un descriptor al sintaxei fluxului (BSD), transformare care poate fi fcut sub controlul XSLT (Extensible Stylesheet Language Transformations). Descriptorul este de dorit s fie independent de un format media ceea ce permite realizarea adaptrii resurselor binare n orice locaie. Instrumentele pentru adaptarea metadatelor identific datele care pot fi utilizate pentru reducerea complexitii instanelor XML de adaptare a metadatelor. Specificaiile se refer la filtrarea i scalarea coninutului i la integrarea a dou sau mai multe instane ale descrierilor. Legturile dintre principalele componente ale DIA sunt prezentate n figura 3.
Pagina 21 din 97
Figura 3 Adaptarea elementului digital i instrumente pentru DIA Declararea unui DIA pentru descrierea caracteristicilor statice i dinamice ale unei reele se poate face: <DIA xmlns="urn:mpeg:mpeg21:dia:schema:2003" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <Descriere xsi:type="UtilizareaMediului"> <Retea> <Capacitate Maxima="384000" MinimaGarantata="32000"/> </Retea> </Descriere> </DIA> Caracteristicile monitorului unui terminal se pot descrie: <DIA xmlns="urn:mpeg:mpeg21:dia:schema:2003" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
Pagina 22 din 97
<Terminal> <Monitor> <Caracteristici bitiPerPixel="24" Culori="32biti" RataRefresh="70"> <Rezolutia Orizontala="1024" Verticala="768"/> </Caracteristici> </Monitor> </Terminal> </DIA>
CAPITOLUL III XML CA BAZ DE DATE 3.1 Este XML-ul o baz de date? nainte de a discuta despre XML i baze de date trebuie s rspundem la ntrebarea Este XML-ul o baz de date? Un document XML este o baz de date n sensul cel mai strict al cuvntului i anume este o colecie de date. Se poate considera c aceste documente nu sunt diferite de orice alt tip de fiiere n fond, toate fiierele conin anumite tipuri de date. Avnd formatul unei baze de date documentele XML prezint anumite avantaje. De exemplu este auto-descris (tag-urile descriu structura i numele tipurilor de date, dar nu i semantica), este portabil (Unicode), i poate descrie date n structuri de arbori sau grafuri. De asemenea are i dezavantaje. De exemplu, este prolixs(neclar) i accesul la date este greoi datorit analizrii i conversiei textului. Putem considera i c XML i tehnologiile asociate constituie o baz de date n sensul mai larg al cuvntului adic, un sistem de gestiune a bazelor de date (SGBD). XML ofer multe din avantajele bazelor de date: stocare (documente XML), scheme (DTD-uri, scheme XML, RELAX NG, .a,), limbaje de interogare (XQuery, XPath, XQL, XML-QL, QUILT, etc.), interfee de programare (SAX, DOM, JDOM). Totui multe componente ale bazelor de date convenionale: stocare eficient, indeci, securitate, tranzacii i integritatea datelor, accesul multi-user, triggere, interogri fcute pe mai multe documente .a. Astfel, se pot folosi documente XML ca o baz de date ntr-un mediu cu cerine modeste i date puine, dar aceast soluie nu este viabil ntr-un mediu pentru producie n mas, unde exist muli utilizatori, cerine stricte de integritate a datelor i nevoia de o performan bun.
Pagina 23 din 97
3.2 Date i documente Cel mai important factor n alegerea unei baze de date este ce va stoca aceasta: date sau documente. XML-ul poate fi folosit doar pentru a transporta date ntre baza de date i o aplicaie sau poate fi folosit integral ca n cazul documentelor XHTML i DocBook. Scopul utilizrii XML este important deoarece toate documentele centrate pe date au anumite caracteristici comune, la fel se ntmpla i n cazul informaiilor centrate pe documente, i aceste caracteristici influeneaz felul cum XML-ul este stocat n baza de date. 3.2.1 Documente centrate pe date Documentele centrate pe date sunt documente care folosesc XML-ul pentru transportul datelor. Aceste documente sunt folosite de ctre aplicaii i nu are nici o importan faptul c informaiile folosite au fost reinute pentru o perioad de timp n documente XML. Exemple de documente centrate pe date sunt ordine de plat, programarea zborurilor, date tiinifice. Documente centrate pe date au o structur regulat, datele sunt atomice (cea mai mic unitate independenta de date este un element sau un atribut). Ordinea elementelor care apar n document nu este important, dect n momentul validrii documentului. Informaiile care exist n documentele centrate pe date pot proveni din baza de date (caz n care se dorete extragerea lor n fiiere XML), dar i din afara bazei de date (caz n care se dorete stocarea acestora n baza de date). Un exemplu de informaii care provin dintro baz de date sunt cantitile de date stocare n bazele de date relaionale, iar un exemplu de informaii care se doresc a fi introduse ntr-o baz de date pot fi considerate datele tiinifice obinute de un sistem de msurtori i convertite n XML. De exemplu urmtorul ordin de vnzare este un document centrat pe date: <OrdinVanzari NumarOV="12345"> <Client NumarClient="543"> <NumeClient>ABC Industries</NumeClient> <Strada>123 Main St.</Strada> <Oras>Chicago</Oras> <Stat>IL</Stat> <CodPostal>60609</CodPostal> </Client> <DataOrdin>981215</DataOrdin> <Item NumarItem="1">
Pagina 24 din 97
<Parte NumarParte="123"> <Descriere> Cheie reglabila: Hotel inoxidabil, Garantie pe viata. </Descriere> <Pret>9.95</Pret> </Parte> <Cantitate>10</Cantitate> </Item> <Item NumarItem="2"> <Parte NumarParte="456"> <Descriere> Separator: Aluminiu, un an garantie. </Descriere> <Pret>13.27</Pret> </Parte> <Cantitate>5</Cantitate> </Item> </OrdinVanzari> Pe lng documentele centrate pe date cu structura asemntoare cu documentul din exemplul anterior, multe documente care conin i text adiional sunt centrate pe date. Spre exemplu s considerm o pagin web care conine informaii despre o carte. Dei pagina conine n mare parte text, structura acelui text este regulat, i o parte din acel text este comun tuturor paginilor care descriu cri, fiecare poriune de text specific avnd dimensiuni limitate. Astfel pagina ar putea fi construit dintr-un document XML simplu, centrat pe date care conine informaii despre o singur carte i este obinut dintr-o baz de date i un stylesheet XSL care adaug textul care leag informaiile din XML. n general orice site web care construiete documente HTML dinamic prin completarea unui template cu informaii dintr-o baz de date poate fi nlocuit cu mai multe documente XML centrate pe date i unul sau mai multe stylesheet-uri XSL. De exemplu, s considerm urmtorul document care descrie un zbor:
Pagina 25 din 97
<InfoZbor> <LinieAeriana>ABC Airways</LinieAeriana> ofera <Numar>trei</Numar> zboruri zilnice non-stop din <Origine>Dallas</Origine> spre <Destinatie>Fort Worth</Destinatie>. Orele de plecare sunt <Plecare>09:15</Plecare>, <Plecare>11:15</Plecare>, and <Plecare>13:15</Plecare>. Sosirile sunt cateva minute mai tarziu. </InfoZbor> Acesta ar putea fi construit dintr-un fiier XML i un stylesheet simplu: <Zboruri> <LinieAeriana>ABC Airways</LinieAeriana> <Origine>Dallas</Origine> <Destinatie>Fort Worth</Destinatie> <Zbor> <Plecare>09:15</Plecare> <Sosire>09:16</Sosire> </Zbor> <Zbor> <Plecare>11:15</Plecare> <Sosire>11:16</Sosire> </Zbor> <Zbor> <Plecare>13:15</Plecare> <Sosire>13:16</Sosire> </Zbor> </Zboruri> 3.2.2 Informaii centrate pe documente Documentele care folosesc viziunea centrat pe documente sunt, de obicei, acele documente care sunt destinate folosirii de ctre utilizatori. Exemple de astfel de documente sunt crile, email, anunuri publicitare i aproape orice document XHTML scris de mn. Acestea sunt caracterizate de o structur mai puin regulat, datele nu sunt atomice (cea mai mic unitate independent de informaie poate fi format dintr-un element mbinat cu alte informaii din document). Ordinea elementelor care apar n document este aproape ntotdeauna important.
Pagina 26 din 97
Aceste tipuri de documente sunt de obicei scrise manual n XML sau n alte formate cum ar fi RTF, PDF sau SGML i apoi sunt transformate n XML. Spre deosebire de documentele centrate pe date aceste documente nu pot proveni din baze de date. Spre exemplu urmtorul document ce conine descrierea unui produs este centrat pe documente: <Produs> <Intro> <NumeProdus>Cheie reglabila</NumeProdus> de la <Producator>Full Fabrication Labs,Inc.</Producator>este<Sumar>ca o cheie universala, dar mai mica.</Sumar> </Intro> <Descriere> <Paragraf>Cheia universala, care are doua versiuni stanga si dreapta , este confectionata din cel mai fin hotel inoxidabil . Manerul cauciucat se adapteaza la mainile dumneavoastra chiar si in cele mai aluneacoase situatii. Se poate regla prin mai multe discuri.</Paragraf> <Paragraf>Puteti:</Paragraf> <Lista> <Item><Link URL="Comanda.html">comanda propria dumneavoastra cheie reglabila </Link></Item> <Item><Link URL="Wrenches.htm">Cititi mai multe despre chei</Link></Item> <Item><Link URL="Catalog.zip">Descarcati catalogul</Link></Item> </Lista> <Paragraf>Cheia reglabila costa doar 44.90 RON si, daca veti comanda acum, veti primi un ciocan cadou.</Para> </Descriere> </Produs> 3.2.3 Date, documente i baze de date n realitate diferena dintre documentele centrate pe date i cele centrate pe documente nu este ntotdeauna clar. Astfel de documente sunt cele legale sau medicale, care sunt scrise
Pagina 27 din 97
ca text dar conin i poriuni de date cum ar fi nume, date, proceduri i de multe ori trebuiesc stocate n ntregime din cauze legale. Cu toate acestea clasificarea documentelor ca fiind centrate pe date sau pe documente poate determina tipul bazei de date necesare stocrii informaiilor din aceste documente. De obicei datele sunt stocate ntr-o baz de date tradiional cum sunt cele relaionale sau orientate-obiect. Documentele sunt stocate ntr-o baz de date nativ XML (o baz de date destinat stocrii XML) sau un sistem de gestionare a coninuturilor (content management system) o aplicaie destinat administrrii documentelor i construit peste o baz de date nativ XML. Totui aceste reguli nu sunt stricte. Datele n special datele semistructurate pot fi stocate n baze de date native XML i documentele pot fi stocate n baze de date tradiionale atunci cnd nu sunt necesare foarte multe caracteristici specifice XML. n plus, graniele dintre bazele de date tradiionale i cele native XML devin din ce n ce mai neclare, deoarece la bazele de date tradiionale se adaug facilitai native XML i bazele de date native XML suport stocarea fragmentelor de documente n baze de date, de obicei relaionale, externe. 3.3 Stocarea i recuperarea datelor Pentru transferarea datelor ntre documente XML i o baz de date, este necesar maparea schemei documentului XML (DTD, Scheme XML, RELAX NG, etc.) pe schema bazei de date. Software-ul pentru transferul de date este construit peste aceast mapare. Software-ul poate folosi un limbaj de interogare XML (cum ar fi XPath, XQuery) sau poate transfera direct date conform cu maparea (echivalentul n XML al interogrii SELECT * FROM Tabel). n al doilea caz, structura documentului i structura necesar pentru mapare trebuie s fie identice. Deoarece acest lucru se ntmpl destul de rar, produsele care folosesc aceast strategie sunt adesea folosite mpreun cu XSLT. Astfel, nainte de transferarea datelor n baza de date, documentul este nti adus la structura necesar maprii i apoi datele sunt transferate. Similar dup transferarea datelor din baza de date, documentul obinut este adus la structura folosit de ctre aplicaie. 3.3.1 Maparea schemelor documentelor pe schemele bazelor de date Maprile ntre schemele documentelor i schemele bazelor de date sunt efectuate pe tipurile elementelor, atribute, i text. Aproape ntotdeauna se omit structurile fizice (cum ar fi entitile i informaia codificat) i unele structuri logice (cum ar fi instruciunile de procesare, comentariile). Aceste omiteri nu au o influen prea mare, deoarece baza de date i aplicaia sunt interesate numai de datele din documentul XML.
Pagina 28 din 97
O consecin a acestor transformri adic stocarea datelor dintr-un document ntr-o baz de date i apoi reconstruirea documentului din datele existente n baza de date este obinerea unui document diferit. Dac acest lucru este acceptabil depinde de cerinele fiecrui proiect i poate influena alegerea softului. De obicei sunt folosite dou metode pentru a mapa schema unui document XML pe schema unei baze de date: maparea bazat pe tabele i maparea obiectual-relaional. 3.3.1.1 Maparea bazat pe tabele Maparea bazat pe tabele este folosit de multe produse care efectueaz transferul de date ntre un document XML i o baz de date relaional. Aceasta modeleaz un document XML ca o singur tabel sau ca un set de tabele. Structura documentului XML este artat n exemplul urmtor. <bazadedate> <tabela> <linie> <coloana1>...</coloana1> <coloana2>...</coloana2> </linie> <linie> </linie> </tabela> <tabela> </tabela> </bazadedate> n funcie de software datele din coloane pot fi stocate ca elemente descendente sau ca atribute. n plus, produsele care folosesc mapri bazate pe tabele de multe ori includ metadate fie la nceputul documentului fie ca atribute asociate fiecrui element din tabel sau coloan.
Pagina 29 din 97
Maparea bazat pe tabele este utilizat pentru serializarea datelor relaionale, ca n cazul transferrii datelor ntre dou baze de date relaionale. Dezavantajul acestei mapri este c nu poate fi folosit pentru un document XML care nu respect formatul din exemplu. 3.3.1.2 Maparea obiectual-relaional Maparea obiectual-relaional este folosit de ctre toate bazele de date relaionale care suport XML i anumite produse middleware. Aceasta modeleaz datele din documentul XML ca un arbore de obiecte care sunt specifice datelor din document. n acest model, tipurile de elemente cu atribute sunt n general modelate n clase. Tipurile de elemente simple, atributele, i PCDATA sunt modelate ca proprieti scalare. Modelul este apoi mapat pe bazele de date relaionale folosind tehnici de mapare obiectual-relaionale tradiionale. Astfel clasele sunt mapate pe tabele, proprietile scalare pe coloane, i proprietile cu valori obiect sunt mapate pe perechi de chei primare/chei strine. Denumirea de mapare obiectual-relaional este de fapt un termen impropriu, deoarece arborele de obiecte poate fi mapat direct pe baze de date orientate obiect i ierarhizate. Totui este folosit pentru c majoritatea produselor care folosesc aceast mapare folosesc baze de date relaionale i acest termen este bine cunoscut. Este important nelegerea faptului c modelul obiectual din aceast mapare nu este modelul DOM (Document Object Model). DOM-ul modeleaz chiar documentul i este acelai pentru toate documentele XML, n timp ce modelul descris mai sus modeleaz datele din document i este diferit pentru fiecare set de documente XML care corespund unei scheme XML de date. De exemplu ordinul de vnzri din seciunea 3.2.1 ar putea fi modelat ca un arbore de obiecte format din 4 clase OrdineVnzri, Client, Item, i Parte aa cum se arat n diagrama de mai jos: OrdineVnzri /|\ Client Item Item || Parte Parte Dac ar trebui s construim un arbore DOM din acelai document, acesta ar fi compus din obiecte cum ar fi Element, Atribut i Text.
Pagina 30 din 97
Element ------ Atribut (OrdineVnzri) (Numr OV) _________/ / \ \_____ //\\ Element Text Element Element (Client) (Data ordinului) (Item) (Item) ||| etc. etc. etc. Instanierea obiectelor din model depinde de produsul folosit. Unele produse dau posibilitatea generrii claselor n model i apoi folosirea obiectelor din aceste clase n aplicaii. n cazul folosirii acestor produse, datele sunt transferate ntre documentul XML i aceste obiecte, i ntre aceste obiecte i baza de date. Alte produse folosesc aceste obiecte numai pentru a vizualiza maparea i transferul de date direct ntre documentul XML i baza de date. Felul n care maparea obiectual-relaional este suportat variaz de la produs la produs. De exemplu: Toate produsele suport maparea tipurilor complexe de elemente pe clase i a tipurilor simple de elemente i atribute pe proprieti. Toate produsele dau posibilitatea desemnrii unui element rdcin care nu este mapat pe modelul obiect sau pe baza de date. Acest element este folositor atunci cnd se dorete stocarea obiectelor cu mai multe nivele n acelai document XML. Majoritatea produselor ofer posibilitatea specificrii dac proprietile sunt mapate pe atribute sau pe elemente descendente n documentul XML. Unele produse permit combinarea atributelor cu elementele descendente; altele cer folosirea numai a elementelor descendente sau a atributelor. Majoritatea produselor permit folosirea numelor diferite n documentul XML i baza de date, dar sunt anumite produse care necesit folosirea acelorai nume att n documentul XML ct i n baza de date. Majoritatea produselor permit specificarea ordinii n care elementele descendente apar n printele lor, dar care face imposibil construirea mai multor modele pentru coninut. Din fericire, modelele pentru coninut suportate sunt suficiente pentru majoritatea documentelor centrate pe date (ordinea este important numai dac se face validarea documentului). 3.3.2 Limbaje de interogare
Pagina 31 din 97
Multe produse transfer date direct conform cu modelul pe care sunt construite. Deoarece structura documentului XML este de obicei diferit de structura bazei de date, aceste produse deseori conin sau sunt folosite cu XSLT. Acesta d posibilitatea utilizatorilor s transforme documente la structura modelului naintea transferrii datelor n baza de date, i invers. Deoarece procesarea XSLT poate fi scump, unele produse conin un numr limitat de transformri n maprile lor. Soluia pe termen lung la aceast problem este implementarea unor limbaje de interogare care returneaz XML. n prezent cele mai multe asemenea limbaje se bazeaz pe fraze SELECT integrate n abloane. Se presupune c aceast situaie se va schimba atunci cnd XQuery i SQL/XML vor fi finalizate, acestea aflndu-se n lucru. Aproape toate limbajele de interogare XML sunt deocamdat read-only, deci vor fi necesare metode diferite pentru inserarea, actualizarea i tergerea datelor (n viitor aceste facilitai vor fi adugate). 3.3.2.1 Limbaje de interogare bazate pe abloane Cele mai des ntlnite limbaje de interogare care returneaz XML din baze de date relaionale sunt cele bazate pe abloane. n aceste limbaje, nu exist o mapare predefinit ntre document i baza de date. Frazele SELECT sunt integrate ntr-un ablon i rezultatele sunt procesate de ctre software-ul care transfera date. De exemplu, urmtorul template folosete elementele <SelectStmt> pentru a include fraze SELECT i numele coloanelor pentru a determina unde trebuiesc plasate rezultatele: <?xml version="1.0"?> <InfoZbor> <Introducere> Urmatoarele zboruri sunt diponibile:</Introduction> <SelectStmt>SELECT Airline, FltNumber, Depart, Arrive FROM Flights</SelectStmt> <Zbor> <LinieAeriana>$Airline</LinieAeriana> <NumarFlt>$FltNumber</NumarFlt> <Plecare>$Depart</Plecare> <Sosire>$Arrive</Sosire> </Zbor> <Concluzie>Speram ca unul dintre ele va este de folos</Concluzie> </InfoZbor>
Pagina 32 din 97
Rezultatul procesrii unui asemenea ablon ar putea fi: <?xml version="1.0"?> <InfoZbor> <Introducere> Urmatoarele zboruri sunt diponibile:</Introduction> <Zboruri> <Zbor> <LinieAeriana>ACME</LinieAeriana> <NumarFlt>123</NumarFlt> <Plecare>Dec 12, 1998 13:43</Plecare> <Sosire>Dec 13, 1998 01:21</Sosire> </Zbor> </Zboruri> <Concluzie>Speram ca unul dintre ele va este de folos</Concluzie> </InfoZbor> Limbajele de interogare bazate pe abloane pot fi foarte flexibile. Dei setul de caracteristici variaz de la un produs la altul, exist unele caracteristici comune: Abilitatea de a plasa seturi de rezultate oriunde n documentul de ieire, incluznd ca parametrii i frazele SELECT . Construcii cum ar fi cicluri FOR i instruciuni IF. Definiri de variabile i funcii Parametrizarea frazelor SELECT prin intermediul parametrilor HTTP. Limbajele de interogare bazate pe abloane sunt folosite aproape exclusiv pentru a transfera date din baze de date relaionale n documente XML. Dei unele produse care folosesc limbaje de interogare bazate pe abloane pot transfera date din documente XML n baze de date relaionale, ele nu folosesc abloanele numai pentru acest lucru. n schimb ele folosesc o mapare bazat pe tabele, aa cum este descris anterior. 3.3.2.2 Limbaje de interogare bazate pe SQL Limbajele de interogare bazate pe SQL folosesc fraze SELECT modificate, iar rezultatele sunt transformate n XML. Exist cteva limbaje particulare de acest tip i cel mai simplu dintre acestea folosete fraze SQL imbricate (nested), care sunt transformate direct n XML imbricat (nested) conform cu maparea relaional-obiectual. Un alt limbaj de acest tip
Pagina 33 din 97
folosete obiecte SQL 3, de asemenea transformate direct n XML. Un alt limbaj folosete fraze OUTER UNION i marcaje speciale pentru a determina cum sunt transformate rezultatele n XML. n plus faa de limbajele particulare, un numr de companii s-au reunit n 2000 pentru a standardiza extensiile XML la SQL. Rezultatele lor fac parte acum din specificaia ISO SQL i este cunoscut ca SQL/XML. SQL/XML introduce un tip de date XML i adaug un numr de funcii la SQL, aa c este posibil construirea elementelor XML i a atributelor din date relaionale. De exemplu, urmtoarea interogare: SELECT Orders.SONumber, XMLELEMENT(NAME "Order", XMLATTRIBUTES(Orders.SONumber AS SONumber), XMLELEMENT(NAME "Date", Orders.Date), XMLELEMENT(NAME "Customer", Orders.Customer)) AS xmldocument FROM Orders construiete un set de rezultate cu dou coloane. Prima coloan conine numrul ordinului de vnzri i a doua coloan conine un document XML. Exist un document XML pe fiecare linie, construit din datele din linia corespunztoare n tabelul de comenzi. De exemplu documentul pentru linia pentru ordinul de vnzare 123 ar putea fi: <Ordin NumarOV="123"> <Data>04/29/07</Data> <Client>Gallagher Industries</Client> </Ordin> 3.3.2.3 Limbaje de interogare XML Spre deosebire de limbajele de interogare bazate pe abloane sau bazate pe SQL, care pot fi folosite numai cu baze de date relaionale, limbajele de interogare XML pot fi folosite pentru orice document XML. Pentru a folosi acest tip de limbaje cu baze de date relaionale, datele din baza de date trebuie s fie modelate ca XML. Cu XQuery, poate fi folosit fie maparea bazat pe tabele fie maparea obiectual relaional. Dac este folosit o mapare bazat pe tabele, fiecare tabel este tratat ca un document separat i n fiecare interogare sunt specificate uniri ntre tabele, ca n SQL. Dac este folosit o mapare obiectual-relaional atunci ierarhiile de tabele sunt tratate ca un singur document i sunt specificate uniri n mapare. Se preconizeaz c maprile bazate pe tabele
Pagina 34 din 97
vor fi utilizate n majoritatea implementrilor, n detrimentul bazelor de date relaionale, deoarece se consider c sunt mai uor de implementat i mai bine cunoscute de utilizatorii SQL. Cu XPath, o mapare obiectual-relaional trebuie s fie folosit pentru a executa interogri peste mai multe tabele. Aceasta se ntmpl deoarece XPath nu suport unirile ntre documente. Astfel, dac ar fi folosit o mapare bazat pe tabele, ar fi posibil interogarea unei singure tabele la un moment dat. 3.3.3 Stocarea datelor n baze de date native XML De asemenea este posibil stocarea datelor n documente XML ntr-o baz de date nativ XML. Acest lucru se face din mai multe motive. Primul ar fi acela cnd datele sunt semistructurate, adic acestea au o structur regulat, dar acea structur variaz destul nct maparea ei la o baz de date relaional duce fie la un numr mare de coloane cu valori nule (care ocup spaiu inutil), fie la un numr mare de tabele (care este ineficient). Dei datele semistructurate pot fi stocate n baze de date ierarhizate orientate-obiect, se poate alege stocarea lor ntr-o baz de date nativ XML sub forma unui document XML. Al doilea motiv pentru stocarea datelor ntr-o baz de date nativ XML este viteza de recuperare a datelor. n funcie de cum sunt stocate datele n baza de date nativ XML, ar putea fi posibil recuperarea datelor mult mai repede dect ntr-o baz de date relaional. Acest lucru se poate ntmpla deoarece unele strategii de stocare folosite de ctre bazele de date native XML rein fizic documente ntregi sau folosesc pointeri fizici (i nu logici) ntre prile documentelor. Acestea permit ca documentele s fie recuperate fie fr uniri fie folosind uniri fizice, ambele fiind mai rapide dect unirile logice folosite n bazele de date relaionale. De exemplu se consider ordinul de vnzare prezentat mai sus. ntr-o baz de date relaional, acesta ar fi stocat n patru tabele OrdineVnzri, Itemi, Clieni, i Parte i recuperarea documentului ar necesita uniri ntre aceste tabele. ntr-o baz de date nativ XML, ntreg documentul ar putea fi stocat ntr-o singur locaie pe disc, aa c recuperarea lui sau a unui fragment din el necesit o singur cutare indexat i o singur citire pentru recuperarea datelor. O baz de date relaional necesit patru cutri indexate i cel puin patru citiri pentru a recupera datele. Dezavantajul n acest caz este acela c viteza de recuperare este mare numai atunci cnd datele din comand sunt stocate pe disc. Dac se dorete recuperarea altor date, cum ar fi o list a clienilor i ordinele de vnzare ale lor, atunci performanta va fi mai slab dect ntr-o baz de date relaional. Astfel, stocarea datelor ntr-o baz de date nativ XML se
Pagina 35 din 97
recomand din motive de performana atunci cnd predomin o singur vedere asupra datelor. Al treilea motiv pentru stocarea datelor ntr-o baz de date nativ XML este exploatarea capacitilor specifice XML, cum ar fi executarea interogrilor XML. Deoarece relativ puine aplicaii centrate pe date au nevoie de acestea i bazele de date relaionale implementeaz limbaje de interogare XML, acest motiv nu este foarte important. O problem cu stocarea datelor ntr-o baz de date nativ XML este c majoritatea acestor baze de date pot returna datele numai ca XML. (Puine baze de date suport legarea elementelor sau atributelor de variabilele dintr-o aplicaie.) Dac o aplicaie are nevoie de date ntr-un alt format (ceea ce este posibil), aceasta trebuie s analizeze XML-ul nainte de a folosi datele. Acesta este un dezavantaj pentru aplicaiile locale care folosesc o baz de date nativ XML n locul unei baze de date relaionale. 3.3.4 Tipuri de date, valori nule, seturi de caractere Aceast seciune se ocup de anumite probleme legate de stocarea datelor din documente XML n baze de date tradiionale. Problemele legate de tipurile de date i datele binare apar i n cazul stocrii datelor n baze de date native XML. n general utilizatorul nu poate alege modalitatea n care sotf-ul care transfer datele rezolv aceste probleme, dar atunci cnd se alege un anumit soft trebuie inut cont de faptul c aceste probleme exist.
3.3.4.1 Tipuri de date XML nu suport prea multe tipuri de date. Cu excepia entitilor neanalizate, toate datele dintr-un document XML sunt text, chiar dac reprezint alt tip de date, cum ar fi datele calendaristice sau integer. n general soft-ul de transfer date va transforma textul (din documentul XML) n alte tipuri de date (n baza de date) i invers. Softul determin ce conversii sunt necesare i exist dou metode pentru efectuarea acestora. Prima metod const n determinarea de ctre software a tipurilor de date din schema bazei de date, deoarece aceasta este accesibil la rulare. (Schema XML nu este neaprat accesibil la rulare sau s-ar putea sa nu existe.) n a doua metod utilizatorul specific tipul de date. Acesta poate fi scris de ctre utilizator sau generat automat dintr-o schem a unei baze de date sau dintr-o schem XML. Atunci cnd sunt generate automat, tipurile de date pot fi recuperate din schemele bazelor de date i din anumite tipuri de scheme XML.
Pagina 36 din 97
Formatele de text recunoscute n momentul conversiilor pot constitui o problem atunci cnd se transfer date din XML, la fel i formatele care se pot crea atunci cnd se transfer date ctre XML. n cele mai multe cazuri, numrul de formate de text care sunt suportate de un tip de dat este limitat la unul anume sau la cele suportate de driverul JDBC. Datele pot cauza multe probleme pentru c gama de formate posibile este foarte mare, iar numerele cu diferitele lor formate internaionale pot cauza de asemenea probleme. 3.3.4.2 Date binare Datele binare se pot stoca n documente XML n trei feluri: codificare Base64 (o codificare MIME care mapeaz datele binare pe un subset al US-ASCII [0-9, a-z, A-Z,+,/]), codificarea hexazecimal (fiecare octet binar este codificat cu dou caractere reprezentnd cifre hexazecimale [0-9,a-f,A-F]), i entiti neanalizate (datele binare sunt stocate ntr-o entitate fizic separat de restul documentului XML). Cea mai mare problem cu datele binare este c multe dintre produsele care transfer date nu suport acest tip de date. O problem secundar apare dac sunt folosite entiti neanalizate i const n faptul c majoritatea produselor nu stocheaz notaii i declaraii de entiti. Astfel, notaia asociat cu o anumit entitate va fi pierdut atunci cnd datele sunt transferate dintr-un document XML ntr-o baz de date.
3.3.4.3 Date vide n domeniul bazelor de date, date vide sunt numite datele care nu exist. Acestea sunt foarte diferite de valoarea 0 (pentru numere), sau lungimea zero (pentru un string). De exemplu, se ia n considerare o colecie de date de la o staie meteo. Dac termometrul nu funcioneaz, n baza de date este stocat o valoare nul i nu valoarea zero, care ar nsemna cu totul altceva. XML suport de asemenea conceptul de date vide prin tipuri de elemente i atribute opionale. Dac valoarea unui tip sau atribut opional este nul acesta nu este inclus n document. n cazul bazelor de date, atributele care conin iruri de caractere cu lungimea zero sau elemente nule nu sunt vide, valoarea lor este un ir cu lungimea zero. La maparea structurii unui document XML la baza de date i invers, tipurile de date i atributele opionale sunt mapate ca i coloane vide. Dac nu se procedeaz n acest mod s-ar putea inserarea o eroare (atunci cnd se transfer date n baza de date), sau la un document invalid (atunci cnd se transfer date din baza de date).
Pagina 37 din 97
3.3.4.4 Seturi de caractere Un document XML poate conine orice caracter Unicode cu excepia unor caractere de control. Din nefericire, multe baze de date ofer suport limitat sau nu ofer suport deloc pentru Unicode i necesit o configuraie special pentru caracterele non-ASCII. 3.3.4.5 Instruciuni de procesare i comentarii Instruciunile de procesare i comentariile nu fac parte din datele dintr-un document XML i majoritatea soft-urilor de transfer de date nu le pot manipula. Totui ele pot aprea aproape oriunde ntr-un document XML i de aceea nu se integreaz uor n maprile bazate pe tabele i cele obiectual relaionale. O soluie total ineficient ntr-o baz de date relaional este adugarea unor tabele pentru instruciuni de procesare i comentarii, adugarea de chei strine la aceste tabele pentru toate celelalte tabele, i verificarea acestor tabele de fiecare data cnd se proceseaz o alt tabel. Astfel majoritatea soft-urilor de transfer de date le nltur. 3.3.4.6 Stocarea marcajelor n anumite situaii este indicat stocarea elementelor cu coninut mixt n baza de date fr a se efectua analiza complet. Cnd este realizat acest lucru, marcajul este realizat cu caractere de marcare. Totui apare o problem la stocarea caracterelor de marcare care nu sunt folosite pentru marcaj. n fiierul XML, acestea sunt stocate folosind entitatile lt, gt, amp, quot, i apos. Acest lucru poate fi fcut i n baza de date. De exemplu urmtoarea descriere: <descriere> Exemplu confuz: <foo/> </descriere> poate fi stocat n baza de date ca: Exemplu confuz: <foo/> Totui apare o problem, limbajele de interogare non-XML, cum ar fi SQL, nu caut n coloane marcaje sau folosirea de entiti i le interpreteaz ca atare. Astfel, dac se caut irul <foo/> cu SQL, de fapt trebuie cutat irul <foo/>.
Pagina 38 din 97
Pe de alt parte, dac referinele la entiti sunt extinse, software-ul de transfer de date nu poate distinge ntre marcaj i folosirea entitilor. De exemplu, dac descrierea de mai sus este stocat n baza de date n forma urmtoare, soft-ul nu poate spune dac ,, i <foo/> sunt marcaje sau text: Exemplu confuz: <foo/> Soluia pe termen lung la aceast problem sunt bazele de date care recunosc XML, n care marcajul efectiv e tratat diferit de elementele care doar par a fi marcaj. Dar, probabil vor fi ntotdeauna probleme atunci cnd aplicaii non-XML lucreaz cu XML. 3.3.5 Generarea schemelor XML din scheme relaionale i invers O ntrebare care apare frecvent la transferul datelor ntre documente XML i baze de date este cum se genereaz scheme XML din scheme ale bazelor de date i invers. nainte de a explica cum se face acest lucru, este bine de reinut faptul c aceasta este o operaie designtime. Motivul pentru acest lucru este c majoritatea aplicaiilor centrate pe date, i cele mai multe aplicaii pe vertical, lucreaz cu un set cunoscut de scheme XML i scheme de baze de date. Astfel ele nu trebuie s genereze scheme n momentul rulrii. n plus procedurile pentru generarea schemelor nu sunt perfecte. Aplicaiile care trebuie s rein documente XML aleatoare ntr-o baz de date ar trebui s foloseasc o baz de date nativ XML n loc s genereze scheme la rulare. Cea mai uoar cale de a genera scheme relaionale din scheme XML i invers este de a codifica o cale prin maparea obiectual relaional, care are un numr de trsturi opionale. O schem relaional se genereaz dintr-o schema XML astfel: Pentru fiecare tip complex de elemente trebuie creat o tabel i o coloan cheie primar. Pentru fiecare tip de elemente cu coninut mixt, trebuie creat o tabel separat n care se va stoca PCDATA, legat de tabela printe prin intermediul cheii primare din tabela printe. Pentru fiecare atribut cu o singur valoare a acelui tip de element, i pentru fiecare element descendent simplu care apare o singur dat trebuie creat o coloan n acel tabel. Dac schema XML conine informaia despre tipurile de date, atunci trebuie setate tipurile de date ale coloanelor la tipul corespunztor. Altfel, tipurile de date trebuie setate la un tip predeterminat, cum ar fi CLOB sau VARCHAR(255). Dac tipul elementelor descendente sau al atributelor este opional coloana trebuie s aib posibilitatea de a fi setat nul.
Pagina 39 din 97
Pentru fiecare atribut cu mai multe valori i pentru fiecare element descendent simplu care apare de mai multe ori trebuie creat o tabel separat pentru a stoca valorile, legat de tabela printe prin intermediul cheii primare din tabela printe. Pentru fiecare element descendent complex, trebuie legat tabela tipului elementului printe de tabela tipului elementului descendent prin intermediul cheii primare din tabela printe. O schema XML se genereaz dintr-o schem relaional astfel: Pentru fiecare tabel se genereaz un tip de element Pentru fiecare coloan care nu este cheie n acea tabel, dar i pentru coloanele chei primare, se adaug la model un atribut la tipul elementului sau un element descendent ce conine numai PCDATA. La fiecare tabel pentru care cheia primar este exportat, se adaug un element descendent la model i se proceseaz tabela recursiv. Pentru fiecare cheie strina, se adaug un element descendent la model i se proceseaz tabela cu cheie strin recursiv. Exist cteva dezavantaje la aceste procedee. Multe dintre acestea se pot corecta uor de ctre programator, cum ar fi coliziuni de nume i specificarea lungimilor i tipurilor de date ale coloanelor. DTD-urile nu conin informaii despre tipurile de date, deci nu este posibil cunoaterea tipurilor de date care ar trebui folosite n baza de date. Tipurile de date i lungimile pot fi prevzute dintr-o schem XML. O problem mai important este aceea c modelul de date folosit de documentul XML este adesea diferit i de obicei mai complex dect cel mai eficient model pentru stocarea datelor n baza de date. De exemplu, se consider urmtorul fragment XML: <Client> <Nume>ABC Industries</Nume> <Adresa> <Strada>123 Main St.</Strada> <Oras>Fooville</Oras> <Stat>CA</Stat> <Tara>USA</Tara> <CodPostal>95041</CodPostal> </Adresa> </Client>
Pagina 40 din 97
Procedura pentru generarea unei scheme relaionale dintr-o schem XML ar crea dou tabele: una pentru clieni i una pentru adrese. Totui n majoritatea cazurilor ar fi mai bine s se rein adresa n tabela de clieni, i nu ntr-o tabel separat. Elementul <Adresa> este un bun exemplu pentru un element wrapper. Elementele wrapper sunt n general folosite din dou motive. n primul rnd, ele ofer structuri adiionale ceea ce face documentul mai uor de neles. n al doilea rnd, ele sunt de obicei folosite ca o form de redactare a datelor. De exemplu, elementul <Adresa> ar putea fi trimis la o rutin care transform toate adresele n obiecte Adresa, indiferent unde apar acestea. Daca elementele wrapper sunt folositoare n XML, n general ele cauzeaz probleme atunci cnd sunt mapate la baza de date dac acestea se gsesc sub forma extra-structurilor. Din aceast cauz, ele ar trebui eliminate din schema XML naintea generrii schemei relaionale. Din moment ce este puin probabil c modificarea schemei XML ar trebui s fie permanent, acest lucru duce la o neconcordan ntre documentul existent i documentele presupuse de ctre soft-ul de transfer de date, din moment ce elementele wrapper nu sunt incluse n mapare. Acest lucru poate fi rezolvat prin transformarea documentelor la rulare cu XSLT: elementele wrapper sunt eliminate naintea transferrii datelor n baza de date i sunt inserate dup transferul datelor din baza de date. Cu toate aceste dezavantaje, procedurile de mai sus ofer n continuare un punct de pornire folositor pentru generarea schemelor XML din scheme relaionale i invers, n special n sisteme mari. 3.4 Stocarea i recuperarea documentelor Pentru stocarea documentelor XML exist dou strategii de baz: stocarea lor n sistemul de fiiere sau ca un BLOB ntr-o baz de date relaional i acceptarea funcionalitilor XML limitate, sau stocarea lor ntr-o baz de date nativ XML. 3.4.1 Stocarea documentelor n sistemul de fiiere Dac se lucreaz cu un set simplu de documente, cum ar fi un set mic de documentaie, cea mai uoara cale de stocare este n sistemul de fiiere. Se pot folosi instrumente cum ar fi grep pentru interogarea lor, i sed pentru modificarea lor. Cutrile complete de text n documentele XML sunt inexacte, pentru c ele nu pot distinge marcajul de text i nu pot nelege folosirea entitilor. Totui, ntr-un sistem mic, aceste inexactiti ar putea fi acceptabile. Dac se dorete un simplu control al tranzaciilor, documentele pot fi ntreinute cu o versiune de control a sistemului cum ar fi CVS sau RCS. 3.4.2 Stocarea documentelor n BLOB-uri
Pagina 41 din 97
O opiune puin mai sofisticat este stocarea documentelor ca BLOB-uri ntr-o baz de date relaional. Aceast modalitate ofer un numr de avantaje a bazelor de date: controlul tranzaciilor, securitate, acces multiuser. n plus, multe baze de date au instrumente pentru cutri de text i pot face cutri complete de text, cutri aproximative, cutri sinonime i cutri fuzzy. Unele dintre aceste instrumente sunt construite pentru a recunoate XML, ceea ce va elimina problemele care apar la cutrile documentelor XML ca simplu text. Atunci cnd se stocheaz documente XML ca BLOB-uri, se pot implementa uor indexri simple care recunosc XML, chiar dac baza de date nu poate indexa XML. O modalitate de a face acest lucru este crearea a dou tabele, o tabel index i o tabel document. Tabela document conine o cheie primar i o coloan BLOB n care este reinut documentul. Tabela index conine o coloan n care se gsete valoarea ce va fi indexat i o cheie strin care duce la cheia primar a tabelei document. Atunci cnd documentul este stocat n baza de date, el este cutat pentru toate instanele elementului sau atributului care este indexat. Fiecare instana este stocat n tabela index, mpreuna cu cheia primara a documentului. Coloana de valori este apoi indexat, i permite unei aplicaii s efectueze o cutare rapid a unei anumite valori a unui element sau atribut i s recupereze documentul corespunztor. De exemplu, se consider un set de documente cu urmtorul DTD i se dorete construirea unui index de autori: <!ELEMENT Brosura (Titlu, Autor, Continut)> <!ELEMENT Titlu (#PCDATA)> <!ELEMENT Autor (#PCDATA)> <!ELEMENT Continut (%Inline;)>  Acestea ar putea fi stocate n urmtoarele tabele: Autori Brosuri ---------------------- --------Autor VARCHAR(50) BrosurID INTEGER BrosuraID INTEGER Brosura LONGVARCHAR Cnd se insereaz o brour n baza de date, aplicaia insereaz broura n tabela Brouri, apoi caut elementele <Autor>, reinnd valorile acestora i ID-ul brourii din tabela Autori. Aplicaia poate recupera brourile n funcie de autor cu o simpl fraza SELECT. De
Pagina 42 din 97
exemplu, pentru a recupera toate brourile scrise de autorul Chen, aplicaia execut urmtoarea interogare: SELECT Brosura FROM Brosuri WHERE BrosuraID IN (SELECT BrosuraID FROM Autori WHERE Autor= 'Chen') O tabel de indeci mai sofisticat ar conine patru coloane: numele atributului sau elementului, tipul, valoarea i ID-ul documentului. Aceasta tabel ar putea stoca valorile marcajelor multiple i ar trebui indexat dup nume, tip, i valoare. Scrierea unei aplicaii generice SAX pentru a popula o astfel de tabel ar fi relativ uoar. 3.4.3 Baze de date native XML Dac sunt necesare mai multe caracteristici dect cele oferite de unul din sistemele de mai sus, trebuie luat n considerare o baz de date nativ XML. Bazele de date native XML sunt baze de date construite special pentru a stoca documente XML. Ca i alte baze de date, acestea suport tranzacii, securitate, acces multiuser, API-uri programatice, limbaje de interogare. Singura diferen fa de alte baze de date este aceea c modelul lor interior este bazat pe XML i nu pe altceva, ca n cazul modelului relaional. Bazele de date native XML sunt de obicei folosite pentru a stoca documente centrate pe documente. Principalul motiv este c ofer suport pentru limbaje de interogare XML, care ofer posibilitatea adresrii unor ntrebri de forma: Extrage toate documente n care al treilea paragraf de la nceputul seciunii conine un cuvnt ngroat, sau ofer posibilitatea limitrii cutrilor complete de text la anumite poriuni din document. Asemenea interogri sunt dificil de scris ntr-un limbaj ca SQL. Un alt motiv este acela c bazele de date native XML pstreaz ordinea documentelor, instruciunile de procesare, i comentarii, i adesea pstreaz seciuni CDATA, folosirea entitilor, i altele, pe cnd bazele de date ce permit folosirea XML nu posed aceste caracteristici. Bazele de date native XML sunt de obicei folosite pentru a integra date. Integrarea datelor a fost fcut cu baze de date relaionale federate, dar acestea necesitau ca toate resursele de date s fie mapate la modelul relaional. Aceast modalitate nu funcioneaz pentru mai multe tipuri de date i modelul de date XML ofer o flexibilitate mai mare. Bazele de date native XML trateaz modificrile schemelor mai uor dect bazele de date relaionale i pot trata i date care nu au schem. Ambele consideraii sunt importante pentru integrarea datelor din surse care nu se afl sub control direct.
Pagina 43 din 97
Al treilea caz de utilizare major al bazelor de date native XML este pentru datele semistructurate, aa cum se gsesc n finane, n biologie, date care se schimb att de des nct nu este posibil definirea unor scheme definitive. Datorit faptului c bazele de date native XML nu necesit scheme, ca bazele de date relaionale, ele pot s trateze acest tip de date, dei aplicaiile adesea necesit procesarea acestor date de ctre oameni. Ultima utilizare majora a bazelor de date native XML este tratarea evoluiei schemelor. Chiar dac bazele de date native XML nu ofer soluii complete, ele ofer o flexibilitate mai mare dect bazele de date relaionale. De exemplu, bazele de date native XML nu necesit ca datele existente s fie mutate ntr-o alt schem, ele pot trata modificri ale schemelor pentru care nu exist nicio cale a migraiei, i pot stoca date chiar dac acestea aparin unei versiuni necunoscute a unei scheme. Alte utilizri ale bazelor de date native XML includ punerea la dispoziie de cache pentru date i metadate pentru tranzacii lungi, operarea cu documente mari i date ierarhice, i comportarea ca un intermediar ntre date i cache (mid-tier data cache). 3.4.3.1 Ce este o baz de date nativ XML? Termenul baz de date nativ XML a aprut prima dat n campania de marketing a Tamino, o baz de date nativ XML dezvoltat de Software AG. Probabil datorit succesului acestei campanii, termenul a fost acceptat de ctre companiile care dezvoltau produse similare. Dezavantajul acestui termen este c fiind un termen de marketing, nu a avut niciodat o definiie formal tehnic. O definiie posibila (dezvoltat de membrii XML:DB) este aceea c o baz de date nativ XML are urmtoarele caracteristici: Definete un model logic pentru un document XML spre deosebire de datele din acel document i stocheaz i recupereaz documente conform acelui model. Modelul trebuie s includ minim elemente, atribute, PCDATA, i ordinea documentelor. Exemple de astfel de modele sunt modelul de date Xpath, XML Infoset, i modelele coninute de DOM i evenimentele din SAX 1.0. Are ca unitate fundamental de stocare logic un document XML, aa cum o baz de date relaional are ca unitate de baz de stocare logic o linie dintr-o tabel. Nu este necesar un model fizic special de stocare a datelor. De exemplu, acesta poate fi construit pe o baz de date relaional, ierarhic, sau orientat pe obiecte, sau se poate folosi un format de stocare particular cum ar fi fiierele comprimate indexate.
Pagina 44 din 97
Prima parte a acestei definiii este similar cu definiiile altor tipuri de baze de date, i se concentreaz pe modelul folosit de baza de date. Nu are nicio importan faptul c o anumit baz de date nativ XML ar putea stoca mai multe informaii dect conine modelul folosit de baza de date. De exemplu, ar putea suporta interogri bazate pe modelul Xpath, dar s stocheze documente ca text. n acest caz, seciunile CDATA i folosirea entitilor sunt stocate n baza de date dar nu sunt incluse n model. A doua parte a definiiei spune c unitatea de baz de stocare ntr-o baz de date nativ XML este un document XML. Dei poate prea posibil ca o baz de date nativ XML ar putea atribui acest rol fragmentelor de documente, bazele de date native XML sunt populate cu documente complete. Unitatea de baz de stocare este nivelul elementar de context n care se potrivete un anumit element de date, i este echivalent cu o linie ntr-o baz de date relaional. Existena acestei uniti de baz nu mpiedic recuperarea unor uniti mai mici de date, cum ar fi fragmente de documente sau elemente individuale, i nu exclude nici posibilitatea combinrii fragmentelor dintr-un document cu fragmente din alt document. n termeni relaionali, acest lucru este echivalent cu faptul c existena liniilor nu mpiedica recuperarea individual a valorilor din coloane sau crearea unor linii noi din altele existente deja. A treia parte a definiiei spune c formatul de stocare nu este important. Acest lucru este adevrat, i este analog cu faptul c formatul fizic de stocare folosit de o baz de date relaional nu are legtur cu faptul ca baza de date este relaional. 3.4.3.2 Arhitecturile bazelor de date native XML Arhitecturile bazelor de date native XML se clasific n dou categorii: bazate pe text i bazate pe modele. Baze de date native XML bazate pe text O baz de date nativ XML bazat pe text stocheaz XML ca text. Acesta ar putea fi un fiier ntr-un sistem de fiiere, un BLOB ntr-o baz de date relaional, sau un format de text particular. Nu are nicio importan faptul c o baz de date relaional care a adugat procesarea ce recunoate XML a coloanelor CLOB (Character Large Object) este, de fapt, o baz de date nativ XML avnd n vedere aceste abiliti. Toate bazele de date native XML bazate pe text au n comun indecii, care ofer posibilitatea motorului de interogare s sar uor n orice punct din orice document XML. Acest lucru d o vitez extraordinar la recuperarea documentelor ntregi sau a fragmentelor
Pagina 45 din 97
de documente. Acest lucru se ntmpla deoarece baza de date poate executa o singur cutare indexat, poate poziiona capul de citire o singur dat, i, presupunnd c fragmentul necesar este stocat continuu pe disc, poate recupera ntregul document sau fragment cu o singur citire. Spre deosebire de aceasta modalitate, reasamblarea unui document din fragmente, cum se face n cazul bazelor de date relaionale i unele baze de date native XML bazate pe modele, necesit cutri indexate multiple i mai multe citiri ale discului. n acest sens, o baz de date nativ XML bazat pe text este similar cu bazele de date ierarhice, amndou avnd performane mai bune dect bazele de date relaionale la recuperarea i returnarea datelor n funcie de o ierarhie predefinit. La fel ca bazele de date ierarhice, bazele de date native XML bazate pe text ar putea ntmpina dificulti la recuperarea i returnarea datelor n orice alt form, cum ar fi inversarea ierarhiei sau a unor poriuni ale ei. Acest lucru nu a fost dovedit nc, dar predominana bazelor de date relaionale, care folosesc pointeri logici ce permit ca toate interogrile de aceeai complexitate s fie executate cu aceeai vitez, pare s indice c aa se va ntmpla. Baze de date native XML bazate pe modele A doua categorie de baze de date native XML este cea bazat pe modele. n loc s stocheze documentul XML ca text, aceste baze de date construiesc un model obiectual intern din document i stocheaz acest model. Modalitatea reinerii acestui model depinde de baza de date. Unele baze de date stocheaz modelul ntr-o baz de date relaional sau orientat obiect. De exemplu, stocarea DOM-ului ntr-o baz de date relaional ar putea duce la obinerea unor tabele cum ar fi Elements, Attributes, PCDATA, Entities, i EntityReferences. Alte baze de date folosesc un format de stocare particular optimizat pentru modelul lor. Un exemplu de baz de date simpl nativ XML bazat pe un model construit pe o baz de date relaional este cea descrisa de Mark Birbeck la XML-L n decembrie 1998. Sistemul folosete cinci tabele definirea atributelor, asocierile dintre elemente/atribute, definirea coninutului modelului, valorile atributelor, i valorile elementelor (PCDATA sau pointeri la alte elemente) i un model care include numai elemente, atribute, text, i ordinea documentelor. Bazele de date native XML bazate pe modele construite pe alte baze de date vor avea performane similare cu acele baze de date la recuperarea documentelor pentru c ele se bazeaz pe acele sisteme pentru a recupera datele. Totui, designul bazei de date, n special pentru bazele de date native XML construite pe baze de date relaionale poate varia destul de mult. De exemplu, o baz de date care folosete o mapare obiectual-relaional direct a
Pagina 46 din 97
DOM-ului ar putea duce la un sistem care necesit executarea frazelor SELECT separat pentru a recupera descendenii fiecrui nod. Pe de alt parte, majoritatea acestor baze de date i optimizeaz modelul de stocare i softul de recuperare. De exemplu, Richard Edwards a descris un sistem de stocare a DOM-ului ntr-o baz de date relaional care poate recupera orice fragment de document (inclusiv ntregul document) cu o singur fraza SELECT. Este probabil c bazele de date native XML bazate pe modele care folosesc un format de stocare particular s aib performane similare cu cele native XML bazate pe text la recuperarea datelor n ordinea n care au fost stocate. Acest lucru se ntmpl deoarece majoritatea acestor baze de date folosesc pointeri fizici ntre noduri, ceea ce ar trebui s duc la o performan similar cu recuperarea textului. (Rapiditatea unei metode sau alteia depinde i de formatul de ieire. Sistemele bazate pe text sunt mai rapide la returnarea documentelor ca text, pe cnd sistemele bazate pe modele sunt mai rapide la returnarea documentelor ca arbori DOM, presupunnd c modelul lor se mapeaz uor la DOM.) Ca i bazele de date native XML bazate pe text, e probabil c i cele bazate pe modele s ntmpine probleme de performan la recuperarea i returnarea datelor ntr-un formular, altul dect cel n care sunt stocate, cum ar fi inversarea ierarhiei sau a unor poriuni a ei. Nu se tie dac aceste baze de date vor fi mai rapide sau nu dect cele bazate pe text. 3.4.3.3 Caracteristici ale bazelor de date native XML n aceast seciune sunt prezentate un numr de caracteristici ale bazelor de date native XML. Colecii de documente Multe baze de date native XML suport noiunea de colecie. Acestea au un rol similar cu cel al tabelelor n bazele de date relaionale sau cu cel al directoarelor ntr-un sistem de fiiere. De exemplu, dac se folosete o baz de date nativ XML pentru stocarea unor ordine de vnzare, ar trebui definit o colecie de ordine de vnzare astfel nct interogrile cu privire la ordinele de vnzare s poat fi limitate la documentele din acea colecie. Ca un alt exemplu, dac se stocheaz manualele pentru toate produsele unei companii ntr-o baz de date nativ XML, ar trebui definit o ierarhie de colecii, o colecie pentru fiecare produs, i n acea colecie, cte o colecie pentru fiecare capitol din fiecare manual. Limbaje de interogare Aproape toate bazele de date native XML suport unul sau mai multe limbaje de interogare. Cel mai popular este Xpath (cu extensii pentru interogri asupra mai multor
Pagina 47 din 97
documente) i Xquery, dei numeroase limbaje de interogare particulare sunt suportate de asemenea. n viitor, majoritatea bazelor de date native XML vor suporta XQuery din W3C. Updatri i tergeri Bazele de date native XML au o varietate de strategii pentru actualizarea i tergerea documentelor, de la simpla nlocuire sau tergere a documentului existent pn la modificarea arborelui DOM, pn la limbaje care specific cum s se modifice fragmente ale unui document. Majoritatea acestor metode sunt particulare. Totui, au aprut dou limbaje ntructva standardizate pentru actualizarea documentelor XML: XUpdate, de la XML:DB Initiative, este un limbaj bazat pe XML. Folosete XPath pentru a identifica un set de noduri, apoi specific dac s se insereze sau s se tearg aceste noduri, sau s insereze noduri noi naintea sau dup acestea. XUpdate a fost implementat n mai multe baze de date native XML. Un set de extensii ale XQuery a fost propus de membrii grupului W3C XQuery i Patrick Lehti. Variaii asupra acestor extensii au fost implementate n mai multe baze de date native XML i pare probabil c acestea vor forma bazele sintaxei pentru actualizare n XQuery. n ciuda acestor limbaje, este probabil ca abilitile de actualizare s rmn fragmentate pn cnd va fi adugat formal o sintax de actualizare la XQuery. Tranzacii, blocri, i concuren Aproape toate bazele de date native XML suport tranzacii (i probabil suport i ntoarceri). Totui, blocarea se face adesea la nivelul ntregului document, i nu la nivelul unui nod individual, de aceea concurena multi-user este relativ redus. Dac aceasta este o problem depinde de aplicaie i ceea ce constituie un document. De exemplu: Un document este un capitol al unui ghid al utilizatorului i scriitorii editeaz capitolele. Este puin probabil ca blocarea la nivel de document s cauzeze probleme de concuren, deoarece este improbabil ca doi scriitori s actualizeze acelai capitol n acelai moment. Un document stocheaz toate datele despre toate vnzrile i vnztorii adaug informaii despre noile vnzri. Este probabil ca blocarea la nivel de document s determine probleme de concuren, deoarece ansele ca doi vnztori s actualizeze informaii n acelai timp este destul de mare. Din fericire, acest lucru poate fi rezolvat cel puin parial prin crearea unui document de vnzare pentru fiecare client.
Pagina 48 din 97
Un document conine datele folosite ntr-un flux, cum ar fi un contract financiar. Fiecare pas al fluxului citete date dintr-un computer i adaug datele proprii. De exemplu, un pas ar putea face o verificare de credit i ar aduga un credit la document. Un alt pas ar putea cuta balane n ateptare n alte contracte ale aceluiai client i ar putea aduga totalul balanelor. Dac blocarea la nivel de nod este folosit, unii dintre aceti pai ar putea fi executai n paralel. Dac este folosit blocarea la nivel de document, aceti pai ar trebui executai secvenial pentru a evita conflicte de scriere. Acest lucru ar putea aduce ntrzieri inacceptabile n aplicaii mari. Problema blocrii la nivel de nod este implementarea acesteia. Blocarea unui nod necesit de obicei blocarea printelui su, ceea ce necesit blocarea printelui acestuia, i aa pn la rdcin, blocnd efectiv ntregul document. Pentru a vedea de ce acest lucru este adevrat, se consider o tranzacie care citete un nod frunz. Dac tranzacia nu are blocri pe strmoii nodului frunz, o alt tranzacie poate terge un nod strmo al frunzei, astfel tergnd i nodul frunz. Totui, o alt tranzacie ar trebui s poat actualiza acele pri ale documentului care nu sunt pe calea direct de la rdcin la nodul frunz. O soluie parial a acestei probleme este propus de Stijn Dekeyser n timp ce problema blocrii strmoilor unui nod int nu a fost total ocolit, aceste blocri au fost fcute mai flexibile prin adnotarea lor cu definirea prin interogare a cii de la nodul blocat pn la nodul int. Acest lucru permite altor tranzacii s determine dac sunt n conflict cu alte tranzacii. Deoarece evaluarea interogrilor pentru a obine blocri este foarte costisitoare, schema actual este ntructva mai limitat dect a fost descris aici, dar acesta este principiul de funcionare. n viitor, majoritatea bazelor de date native XML vor oferi probabil posibilitatea blocrii la nivel de nod. Interfee de programare a aplicaiilor (API-uri) Majoritatea bazelor de date native XML ofer API-uri programatice. Acestea sunt de obicei sub forma unei interfee asemntoare ODBC, cu metode pentru legarea la baza de date, explorarea metadatelor, executarea interogrilor, i recuperarea rezultatelor. Rezultatele sunt de obicei returnate ca un ir XML, un arbore DOM, sau un Parser SAX, sau un XMLReader peste documentul returnat. Dac interogrile pot returna documente multiple, atunci metodele pentru parcurgerea rezultatelor sunt de asemenea disponibile. Dei majoritatea bazelor de date native XML ofer API-uri particulare au fost dezvoltate dou API-uri independente (iulie 2004):
Pagina 49 din 97
API-ul XML:DB al XML:DB.org care este independent de limbajul de programare, i folosete XPath ca limbajul su de interogare, i este extins pentru a suporta XQuery. A fost implementat pentru mai multe baze de date native XML i se poate s fi fost implementat i pentru baze de date care nu sunt native XML. JSR 225: XQuery API pentru Java (XQJ) este bazat pe JDBC i folosete XQuery ca limbaj de interogare. Este dezvoltat de ctre Java Community Process (JCP) de la Sun. Deoarece aceast iniiativa este condus de IBM i Oracle este probabil rspndirea ei la scar larg. Majoritatea bazelor de date native XML ofer de asemenea posibilitatea executrii interogrilor i returnarea rezultatelor prin HTTP. Round-Tripping O caracteristic important a bazelor de date native XML este c pot efectua un round-trip al documentelor XML. Acest lucru nseamn c se poate stoca un document XML ntr-o baz de date nativ i se poate recupera din baza de date acelai document. Acest lucru este important pentru aplicaiile centrate pe documente, pentru care seciunile CDATA, folosirea entitilor, comentariile i procesarea instruciunilor sunt o parte integrant a documentului. De asemenea este foarte important pentru multe aplicaii medicale i legale, care sunt obligate prin lege sa pstreze copii fidele ale documentelor. Round-tripping-ul este mai puin important pentru aplicaiile centrate pe date, pentru care de obicei conteaz elementele, atributele, textul, i ordinea ierarhic. Toate softurile care transfer date ntre documente XML i baze de date pot executa acest procedeu cu aceste date. Aceleai operaii pot fi aplicate i unor ordonri similare (ordinea elementelor i a PCDATA n printele lor) ntr-un numr limitat de cazuri care sunt importante pentru aplicaiile centrate pe date. Totui deoarece nu pot face aceste operaii n toate cazurile, i nici asupra instruciunilor de procesare, comentariilor, i structurilor fizice (referinele ctre entiti, seciuni CDATA), nu sunt potrivite pentru aplicaii centrate pe documente. Toate bazele de date native XML pot aplica round-tripping-ul la nivelul elementelor, al atributelor, al PCDATA, i al ordinii documentelor. Ct de mult se poate aplica acest procedeu depinde de baza de date. Ca o regul general, bazele de date native XML bazate pe text aplic acest procedeu pe documentele XML exact, n timp ce bazele de date native XML bazate pe modele aplic acest procedeu asupra documentelor XML la nivelul modelului. n cazul modelelor minimale de documente, acest procedeu se face la un nivel mai mic dect XML-ul canonic.
Pagina 50 din 97
Din moment ce nivelul de round-tripping depinde de fiecare aplicaie, i alegerea bazei de date native XML potrivite poate varia. Date aflate la distan Unele baze de date native XML pot include date aflate la distan n documente stocate n baza de date. De obicei aceste date sunt recuperate dintr-o baz de date relaional cu ODBC, OLE DB, sau JDBC i sunt modelate folosind maparea bazat pe tabele sau maparea relaional-obiectual. Daca aceste date sunt live adic dac actualizrile documentului din baza de date nativ XML sunt reflectate n baza de date aflat la distan depinde de baza de date nativ XML. n viitor majoritatea bazelor de date native XML vor suporta date live aflate la distan. Indeci Toate bazele de date native XML suport indeci ca o modalitate de a mri viteza de interogare. Exista trei tipuri de indeci. Indecii valoare indexeaz text i valori ale atributelor i sunt folosii pentru a rezolva interogri de forma: Gsete toate elementele sau atributele ale cror valori sunt Santa Cruz. Indecii structurali indexeaz locaia elementelor i atributelor i sunt folosii pentru a rezolva interogri de forma: Gsete toate elementele adres. Indecii valoare i structurali sunt combinai pentru a rezolva interogri de forma: Gsete toate elementele orae ale cror valori sunt Santa Cruz. Indecii full-text indexeaz semnele individuale din text i valorile atributelor i sunt folosii pentru a rezolva interogri de forma: Gsete toate documentele care conin cuvintele Santa Cruz. sau n conjuncie cu indecii structurali :Gsete toate documentele care conin cuvintele Santa Cruz ntr-un element adres. Majoritatea bazelor de date native XML suport att indeci valoare ct i indeci structurali. Unele baze de date native XML suport indeci full-text. Stocarea entitilor externe O problem dificil care apare la stocarea documentelor XML este tratarea entitilor externe. Adic, ar trebui extinse i valorile lor stocate mpreuna cu restul documentului, sau ar trebui ca referinele la entiti s fie lsate la locul lor? Aceast ntrebare nu are rspuns unic. De exemplu, se consider c un document include o entitate extern general care apeleaz un program CGI pentru prognoza meteo. Dac documentul este folosit ca o pagina Web care ofer prognoza meteo, ar fi o greeal extinderea referinei la entitate, deoarece pagina de Web nu ar mai returna date live. Pe de alt parte, dac documentul ar fi o parte a
Pagina 51 din 97
unei colecii de date despre vreme mai vechi, ar fi o greeal s nu se extind referina, deoarece documentul ar recupera ntotdeauna datele curente i nu le-ar mai reine pe cele vechi. Ca un alt exemplu, se consider un manual al unui produs care nu conine altceva dect referine la entiti externe care trimit la capitolele manualului. Daca unele dintre aceste capitole ar fi folosite n alte documente, ca manualele pentru diferite modele ale aceluiai produs, ar fi o greeal extinderea acestor referine, pentru ca ar duce la copii multiple ale acelorai capitole. 3.4.3.4 Normalizare, integritate referenial i scalabilitate Pentru muli, n special pentru cei ce poseda cunotine despre baze de date relaionale, bazele de date native XML ridic un numr de probleme controversate, n special cu privire la problemele de stocare a datelor (spre deosebire de documente). Unele dintre aceste probleme sunt dezbtute n seciunile urmtoare. Normalizarea Normalizarea se refer la procesul de proiectare a schemei unei baze de date n care un anumit set de date sunt reprezentate o singur dat. Normalizarea are cteva avantaje clare, cum ar fi reducerea spaiului necesar pe disc i eliminarea posibilitii apariiei inconsistenelor, care se pot gsi atunci cnd un set de date este stocat n mai multe locuri. Aceasta este una din pietrele de temelie a tehnologiei relaionale i este un punct aprins n discuiile despre stocarea datelor n baze de date native XML. Normalizarea nu este o problem pentru documente centrate pe documente. De exemplu, se consider o colecie de documente ce descrie produsele unei companii. n multe asemenea colecii, exist puine date comune tuturor documentelor notificri de copyright, adresele corporaiilor i numere de telefon, logo-uri ale produselor i aceste date sunt prea puine relativ la total nct normalizarea acestora nu se ia n calcul. Pe de alt parte, alte seturi de documentaii au pri comune importante ntre documente i se merit normalizarea lor. Ca i n cazul bazelor de date relaionale, normalizarea bazelor de date native XML nu este obligatorie. De aceea este important proiectarea atent a structurii documentelor nainte de stocarea lor ntr-o baz de date nativ XML. Bazele de date native XML au un avantaj fa de bazele de date relaionale. Din moment ce bazele de date native XML nu au scheme, se pot stoca documente similare n baza de date cu mai multe scheme la un anumit moment. Chiar dac este necesar reproiectarea interogrilor i convertirea documentelor existente, acest lucru ar putea uura procesul de tranziie.
Pagina 52 din 97
Normalizarea datelor pentru o baz de date nativ XML este aproximativ la fel ca normalizarea unei baze de date relaionale: documentele trebuie proiectate astfel nct datele s nu se repete. O diferen ntre bazele de date native XML i bazele de date relaionale este aceea ca XML suport proprieti multi-valoare n timp ce majoritatea bazelor de date relaionale nu. Aceasta face posibil normalizarea datelor ntr-o baz de date nativ XML ntr-o manier care nu este posibil ntr-o baz de date relaional. De exemplu, se consider un ordin de vnzare. Acesta const n informaiile din antet, cum ar fi numrul ordinului, data, numrul clientului, i unul sau mai muli itemi care conin un numr curent, cantitatea, i preul total. ntr-o baz de date relaional, informaia din antet trebuie stocat ntr-o tabel separat fa de itemi, deoarece sunt mai multe linii n fiecare antet. ntr-o baz de date nativ XML, aceast informaie poate fi stocat ntr-un singur document fr redundane, deoarece natura ierarhic a XML permite unui element printe s aib mai muli descendeni. Din nefericire, normalizarea pe cazuri concrete nu este att de simpl. De exemplu, ce se ntmpl atunci cnd se dorete ca ordinul de vnzare s conin informaii despre client, cum ar fi nume de contact i adresa de expediere i facturare? Exista dou variante. Prima, se pot duplica informaiile despre client n fiecare ordin de vnzare pentru acel client, ducnd la date redundante i toate problemele care apar cu acestea. A doua variant, se pot stoca informaiile despre client separat i fie adugat un XLink n documentul ordinului de vnzare ctre documentul clientului, fie unite cele dou documente atunci cnd datele sunt interogate. Acest lucru presupune c fie legturile XLink sunt suportate (n majoritatea cazurilor nu sunt), fie limbajul de interogare suport uniri (de asemenea nu se ntmpl ntotdeauna). n practic nu exist soluii clare. Datele relaionale din lumea real sunt adesea nenormalizate din motive de performan. Dac se stocheaz documente centrate pe documente i acestea se pot normaliza pn la un anumit grad cum ar fi stocarea capitolelor sau procedurilor ca documente separate i unirea lor pentru a crea documente end-user atunci o baz de date nativ XML este o soluie bun, n special pentru c va oferi caracteristici precum limbaje de interogare XML care nu se gsesc n alte baze de date. Dac se stocheaz documente centrate pe date i o baz de date nativ XML mbuntete performana aplicaiei sau ofer stocarea datelor semi-structurate, faciliti care nu se gsesc n alte baze de date atunci aceast baz de date ar trebui folosit. Integritatea referenial
Pagina 53 din 97
Integritatea referenial este strns legat de normalizare. Aceasta se refer la validitatea pointerilor la datele legate i sunt o parte necesar a meninerii consistenei bazei de date. De exemplu nu este de niciun folos un numr de client dintr-un ordin de vnzare care nu are o nregistrare a clientului corespondent. Departamentul de expediere nu va ti unde s trimit marfa i departamentul de contabilitate nu va ti unde s trimit factura. ntr-o baz de date relaional, integritatea referenial nseamn asigurarea c se face legtura corect ntre cheile strine i cheile primare adic, verificarea c linia cheii primare ce corespunde oricrei chei strine exist. ntr-o baz de date nativ XML, integritatea referenial nseamn asigurarea c pointerii n documentul XML trimit la documente valide sau fragmente de documente. Pointerii din documentele XML sunt de mai multe feluri: atribute ID/IDREF, cmpuri key/keyref (aa cum sunt definite n scheme XML), legturi XLink, i diferite mecanisme particulare. Cele din urma includ elemente i atribute de referire ntr-un limbaj specific, cum ar fi atributul ref al elementului <element> n schemele XML, i mecanisme de legturi specifice bazelor de date. n timp ce elementele i atributele de referire ntr-un limbaj specific sunt destul de des ntlnite, mecanismele de legturi specifice bazelor de date sunt mai rare. Integritatea referenial ntr-o baz de date nativ XML poate fi mprit n dou categorii: integritatea pointerilor interni (pointeri dintr-un document) i integritatea pointerilor externi (pointeri dintre documente). Integritatea referenial a pointerilor interni care folosesc mecanisme non-standard nu este forat, deoarece bazele de date native XML nu pot identifica aceti pointeri. Integritatea referenial a pointerilor interni care folosesc un mecanism standard, cum ar fi ID/IDREF sau key/keyref, este cel puin parial suportat prin validare. Motivul pentru care acest suport este parial este c majoritatea bazelor de date native XML execut validri numai cnd un document este introdus n baza de date. Astfel, dac sunt efectuate actualizri la nivel de document prin tergeri i apoi nlocuiri a unui document validarea este suficient pentru a asigura integritatea pointerilor interni. Dar dac sunt efectuate actualizri la nivel de nod inserri, modificri i tergeri de noduri individuale atunci baza de date trebuie s mai fac operaii n plus, cum ar fi validarea tuturor modificrilor, pentru a garanta integritatea referenial a pointerilor interni. Integritatea refenial a pointerilor externi nu este suportat, nici de puinele baze de date care suport pointeri externi. Dac un pointer extern trimite la o resurs stocat n alt parte n baza de date, nu exist motiv pentru a nu se impune integritatea pointerului. Totui, dac un pointer trimite la o resurs din afara bazei de date nu este obligatorie impunerea
Pagina 54 din 97
integritii. De exemplu, se presupune c un document conine o legtur XLink care trimite la un document pe un site web extern. Baza de date nu are nici un control asupra existenei documentului extern i astfel nu se poate impune integritatea legturii XLink. n viitor, majoritatea bazelor de date native XML probabil vor suporta integritatea referenial a pointerilor interni care folosesc mecanisme standard. Multe baze de date native XML vor suporta anumite tipuri de pointeri externi, ca i pointerii externi care trimit la resurse stocate n aceeai baz de date. Deocamdat n majoritatea cazurilor aplicaiile impun integritatea pointerilor att interni ct i externi. Scalabilitate Ca i bazele de date ierarhice i relaionale, bazele de date native XML folosesc indeci pentru a localiza date. Acest lucru nseamn c localizarea documentelor i a fragmentelor de documente este legat de dimensiunile indecilor, nu de dimensiunile documentelor sau de numrul de documente, i de faptul c aceste baze de date pot localiza nceputul unui document sau fragment la fel de repede ca i alte baze de date care folosesc aceeai tehnologie de indexare. Astfel, bazele de date native XML vor scala la fel de bine ca i alte baze de date. Ca i bazele de date ierarhice, dar spre deosebire de cele relaionale, multe baze de date native XML leag fizic datele nrudite. n special, bazele de date native XML bazate pe text grupeaz fizic datele nrudite i bazele de date native XML bazate pe modele care folosesc sisteme de stocare particulare folosesc adesea pointeri pentru a grupa date nrudite. Bazele de date native XML bazate pe modele construite pe baze de date relaionale folosesc ca i acestea legturi logice. Deoarece legturile fizice sunt mai rapide dect cele logice, bazele de date native XML, ca i cele ierarhice, pot recupera date mai repede dect bazele de date relaionale. Astfel, ele ar trebui s scaleze bine din punctul de vedere al recuperrii datelor. De fapt, ar trebui s se comporte mai bine dect bazele de date relaionale, deoarece scalabilitatea este legat de o singur cutare indexat iniial, spre deosebire de multiplele cutri necesare n cazul bazelor de date relaionale. Din pcate, aceast scalabilitate este limitat. Ca i bazele de date ierarhice, legturile fizice n bazele de date native XML se aplic numai asupra anumitor ierarhii. Recuperarea datelor n ierarhia n care sunt stocate este foarte rapid, dar recuperarea acelorai date ntr-o ierarhie diferit este mai nceat. De exemplu, se presupune c informaiile despre clieni sunt stocate n fiecare ordin de vnzare. Recuperarea acestor ordine de vnzare va fi foarte rapid, deoarece acesta este ordinul n care datele sunt stocate. Recuperarea unei alte vederi a datelor,
Pagina 55 din 97
cum ar fi o list cu ordinele de vnzare pentru un anumit client, va fi mult mai nceat, deoarece legturile fizice nu se mai folosesc. Pentru a rezolva parial aceast problema, bazele de date native XML folosesc foarte muli indeci, adesea indexnd toate elementele i atributele. Dac acest lucru ajut la scderea timpului de recuperare a datelor, totui crete timpul de actualizare, pentru c ntreinerea acestor indeci poate fi costisitoare. Aceasta nu este o problem n medii readonly, dar poate cauza probleme n medii n care se folosesc multe tranzacii. n cele din urm, bazele de date native XML scaleaz mai slab dect cele relaionale n cutarea datelor neindexate. Ambele tipuri de baze de date trebuie s caute secvenial datele n acest caz, dar n cazul bazelor de date native XML este mai greu datorit normalizrii mai puin complete. De exemplu, se caut toate ordinele de vnzri cu o anumit dat i datele nu sunt indexate. ntr-o baz de date relaional, aceasta nseamn citirea tuturor valorilor din coloana OrderDate. ntr-o baz de date nativ XML, acest lucru nseamn citirea fiecrui ordin de vnzare n ntregime i cutarea elementului <OrderDate>. Nu numai c se citete coninutul fiecrui element <OrderDate>, dar se citete i coninutul tuturor celorlalte elemente. n bazele de date native bazate pe text, textul trebuie analizat i convertit la formatul dat calendaristic nainte de a putea fi comparat cu data cutat. Aici se ncheie descrierea bazelor de date native XML. Urmtoarele doua seciuni trateaz dou tipuri specializate de baze de date native XML: DOM-uri persistente i sisteme de management ale coninuturilor. 3.4.4 DOM-uri persistente (PDOM-uri) Un DOM persistent sau PDOM este un tip specializat de baz de date nativ XML care implementeaz DOM-ul peste un tip de stocare persistent. Spre deosebire de majoritatea bazelor de date native XML, care pot returna documente ca arbori DOM, arborele DOM returnat de un PDOM este activ (live). Adic, modificrile fcute arborelui DOM sunt reflectate direct n baza de date. Dac modificrile sunt fcute imediat sau n urma apelrii unei metode commit depinde de baza de date. n majoritatea bazelor de date native XML, arborele DOM returnat aplicaiei este o copie, i modificrile sunt fcute n baza de date prin intermediul unui limbaj de actualizare XML sau prin nlocuirea ntregului document. Deoarece arborii PDOM sunt activi, baza de date este de obicei local, adic este n acelai spaiu de procesri ca i aplicaia, sau cel puin pe aceeai main, dei acest lucru nu este neaprat necesar. Acest lucru este fcut pentru eficien, deoarece un PDOM peste o baz de date aflat la distan ar necesita cereri frecvente la un server aflat la deprtare.
Pagina 56 din 97
PDOM-urile au acelai rol pentru aplicaiile DOM ca i bazele de date orientate obiect pentru aplicaiile orientate obiect: ele ofer stocare persistent pentru datele aplicaiei, i servesc i drept memorie virtuala pentru aplicaie. Al doilea rol este foarte important pentru aplicaiile DOM care opereaz cu documente mari, deoarece arborii DOM pot uor s depeasc documentele XML ca mrime. 3.4.5 Sisteme de management ale coninuturilor Sistemele de management ale coninuturilor sunt un alt tip specializat de baze de date native XML. Acestea sunt proiectate pentru operarea cu documente scrise de oameni, cum ar fi manualele de utilizare, i sunt construite peste baze de date native XML. Baza de date este n general ascuns de utilizator n spatele unui front end care ofer caracteristici precum: Control al versiunilor i al accesului Motoare de cutare Editoare XML/SGML Motoare de publicare pe hrtie, CD sau pe Web Separarea coninuturilor i a stilurilor Extinderea n scripturi i programare Integrarea datelor din baza de date Termenul de sistem de management al coninuturilor spre deosebire de sistem de management al documentelor reflect faptul c asemenea sisteme permit n general mprirea documentelor n fragmente cu coninut discret, cum ar fi exemple, proceduri, capitole, dar i metadate cum ar fi numele autorilor, datele reviziilor, i numerele documentelor, dect s opereze cu fiecare document ca un ntreg. Nu numai c astfel se simplific coordonarea lucrului mai multor scriitori la acelai document, dar permite i asamblarea unor documente noi din componente care exist deja.
CAPITOLUL IV CONSTRUIREA DOCUMENTELOR XML 4.1 Sintaxa XML XML este format de fapt din dou metalimbaje, ambele descrise n acelai document. Primul este un set de reguli pentru realizarea de documente XML construite corect, n timp ce al doilea este un set de reguli pentru realizarea unei definiii a tipului documentului XML, sau DTD (Document Type Definition), care permite ca structura documentului XML s se supun unor constrngeri i s fie validat fa de acele constrngeri. Distincia dintre aceste
Pagina 57 din 97
dou limbaje este deseori neclar, deoarece un document XML complet presupune mcar existena opional a unui DTD, indiferent dac acesta este de fapt prezent sau nu. Pentru a complica i mai mult lucrurile, un DTD poate fi compus din dou pri, o submulime intern i o submulime extern. Aceasta parte studiaz documentul XML fr a insista prea mult asupra DTD-ului, deoarece un document XML poate fi creat i fr a face referiri la un DTD. Din motive de performan, multe documente XML vor fi utilizate fr a le valida n raport cu DTD-ul, chiar dac DTD-ul este disponibil. n cazul conexiunilor lente, citirea dintr-un DTD situat pe un alt sistem poate fi foarte nceat, iar datorit faptului c un DTD poate conine referine la alte documente, rezolvarea tuturor referinelor externe poate dura exagerat de mult chiar i n cazul conexiunilor de mare vitez. Utilizatorii sunt obinuii ca documentele HTML s fie ncrcate incremental, deci pot citi nainte ca documentul s fie ncrcat n totalitate, dar analizatoarele XML de validare nu permit afiarea documentului dect n cazul n care acesta este valid, deci documentul va aprea pe ecranul utilizatorului numai n momentul n care este ncrcat n totalitate. Acest lucru poate fi suprtor. Totui, fiecare document este creat avnd n minte un DTD, indiferent dac DTD-ul este explicit sau nu. Chiar i la crearea documentelor fr un DTD, trebuie s avut n vedere un fel de DTD empiric pe msur ce este creat documentul, deoarece un DTD descrie o structur de date. 4.2 Descrierea de vocabulare noi cu XML XML are o natur dual: un metalimbaj care permite descrierea de noi structuri de documente i vocabulare i un limbaj utilizat ca s exprime acea structur i acel vocabular n cazul unui document. Exist o diferen clar ntre un document XML, care poate avea sau nu asociat un DTD exprimat n metalimbajul XML, i un DTD XML. Ele utilizeaz sintaxe complet diferite pentru a descrie un document XML, unul prin exemplu iar cellalt prescriptiv. Definiiile tipului documentului XML (DTD-urile) descriu instane ale limbajului XML, numite uneori vocabulare XML. Dcumentele XML sunt create utiliznd acele limbaje. Din pcate, aceast diferen se pierde uneori n exprimarea neoficial, iar vocabularele XML particulare i DTD-urile asociate sunt descrise inexact ca XML. Utilizatorul unui limbaj sau vocabular XML poate c nu va vedea niciodat sau poate c nici nu i pas de DTD-ul utilizat pentru a descrie aplicaia sa, la fel cum miilor de persoane care lucreaz n design Web utiliznd HTML nu le pas de W3C HTML 4.0 SGML DTD utilizat n descrierea HTML. De fapt, un DTD poate s nu existe. Nu are o importan chiar aa mare la nivelul aplicaiei. 4.3 Avantajele definiiei tipurilor documentului
Pagina 58 din 97
Cu toate c DTD-urile sunt opionale deoarece un procesor XML poate conduce un DTD convenabil dintr-o instan a XML, existena unui DTD ofer multe avantaje: Un DTD descrie organizarea unui document ntr-un mod care poate fi distribuit cu uurin. Un DTD permite unui proiectant s creeze o transformare robust dintr-un anumit tip de document XML ntr-un alt format, pentru afiare sau transfer. Deoarece cu un DTD se cunoate absolut orice despre documente, se vor putea trata structuri care este posibil s nu existe ntr-un anumit exemplu, dar sunt permise de tipul documentului, chiar dac nu au fost ntlnite niciodat pn acum. Un DTD permite unui analizor care valideaz s determine dac un anumit document este sau nu creat n conformitate cu regulile stabilite de autorul specificaiei. Acest lucru este extrem de important pentru EDI (Electronic Data Interchange schimb electronic de date) i alte aplicaii n care documentele vor fi partajate i utilizate i de alte procese. Fr un DTD, un mediu de creare XML nu poate oferi sugestii despre elementele care sunt necesare sau opionale ntr-un anumit loc i despre atributele pe care le poate conine un anumit element. Meniurile contextuale sau sugestiile pot fi de mare ajutor n accelerarea dezvoltrii documentelor i n prevenirea erorilor. Fr un DTD, autorul unui manual de creaie sau al unui document de stil nu are de unde s tie cum ar trebui construit documentul definit. Un manual de creaie este o ntrupare a informaiei exprimate ntr-un DTD, cu toate c nu este un DTD n sine. Specificarea DTD-ului utilizat ntr-un document identific versiunea standardului folosit la crearea sa. Cnd documentele se dezvolt n funcionalitate i sintax, acesta poate fi un indiciu ntr-o situaie nou. 4.4 Combaterea dezavantajelor definiiei tipurilor documentului Cu toate avantajele lor, DTD-urile ridic i probleme. Ele utilizeaz o sintax diferit de XML, deci construirea unui DTD necesit un alt set de abiliti. n plus ca orice descriere tehnic, implicarea n proiectarea unui DTD neavnd n vedere aspectul structurii datelor n document poate duce la mpotmolirea n detalii atunci cnd este nevoie de atenie la structura general. Multe persoane proiecteaz documente XML utiliznd vocabularul XML destinat i apoi utilizeaz un instrument de extragere automat de DTD-uri pentru a genera un DTD pe baza documentului. Dup realizarea acestui lucru, DTD-ul poate fi reglat prin adugri la codul surs sau prin ajustarea acestuia. Dar DTD au i urmtoarele dezavantaje:
Pagina 59 din 97
Cu un DTD, un agent utilizator XML care valideaz necesit cel puin nc o operaie de citire pentru a accesa locaia unde este disponibil DTD-ul. Cu toate c plasarea n cache poate reduce performanele pentru unii utilizatori din reea, multe utilizri previzibile ale documentelor XML vor face imposibil utilizarea stocrii n cache. Un DTD crete cu mult complexitatea analizorului necesar pentru a determina dac un document poate fi afiat. Pentru unele dispozitive, este posibil ca acest lucru s fie realizabil. Unele medii de creare care valideaz i utilizeaz un DTD ngreuneaz salvarea spaiului de lucru la sfritul zilei sau restaurarea sa n ziua urmtoare, cu excepia cazului n care documentul se afl ntr-o stare valid. Din punct de vedere teoretic, un DTD este capabil s continue nelimitat citiri externe, deoarece un DTD poate conine alte DTD-uri sau mulimi de entiti. Este posibil ca pentru afiarea unor documente complexe s fie nevoie de foarte mult timp atunci cnd se utilizeaz un analizor care valideaz. Decizia utilizrii unui DTD este un compromis ntre abilitatea de utilizare fr restricii, obinuit n HTML posibilitate de a face aproape tot ce se dorete i un mediu mult mai structurat. n multe situaii, cum sunt cele n care se realizeaz documente care trebuie s fie general disponibile i sunt create distribuit, trebuie s se respecte strict regulile i este de dorit folosirea unui DTD. n alte cazuri, cum ar fi atunci cnd se dezvolta un tip de document XML nou, nu este nevoie sau nu este dorit constrngerea strict i se poate realiza fr un DTD, cel puin n timpul proiectrii iniiale. Dar dup ce dezvoltarea a devenit un produs stabil, este de dorit ca proiectul s poat fi distribuit cu uurin. Chiar dac se dorete crearea unui manual de utilizare, un DTD este o metod simpl de a permite utilizatorilor s i testeze propriile documente pentru a se asigura c au respectat indicaiile pe care le-au citit n manual. n acel moment, se poate considera c DTD-urile ofer o flexibilitate prea mare. 4.5 XML, doar un alt HTML? XML este un limbaj cu etichete i atribute asemntor cu HTML, dar un HTML transformat att de mult, nct nu mai poate fi recunoscut. XML este mult mai structurat dect HTML. n timp ce procesoarele HTML accept n mod curent cod incorect i diform i ncearc s i dea sens pe ecran, XML trebuie s se opreasc atunci cnd gsete o eroare fatal, care poate fi aproape orice tip de eroare. Aceasta este ntr-un fel o ntoarcere la primele zile ale prelucrrii datelor, cnd orice eroare din cod era pedepsit cu un vidaj de memorie, (core dump) lng care se puteau petrece ore ntregi n ncercarea de a-l descifra.
Pagina 60 din 97
Totui pe lng acest comportament necrutor, XML este cu mult mai puternic. n timp ce HTML se mulumete cu un numr relativ mic de etichete, XML are un numr de etichete aproape infinit, structurate n aproape orice fel se dorete. Oricum, fundamentele au rmas aceleai, XML reprezentnd un pas evolutiv al HTML. Nu numai c un HTML bine fcut este foarte aproape de XHTML un nlocuitor al HTML care respect XML dar un cod HTML 4.0 curat este destul de lizibil ca XHTML 1.0. Deoarece HTML 4.0 a fost structurat ca o aplicaie SGML, iar XML este o submulime a SGML, acest lucru este logic. Diferenele sintactice minore dintre XHTML, un vocabular XML, i HTML, un vocabular SGML, pot fi ajustate automat dac este nevoie. Autorul unui document XML ofer de obicei un manual de creare sau codare (sau o foaie, pentru DTD-uri mici) descriind etichetele utilizate n aplicaia XML, atributele lor, valorile posibile i modul lor de imbricare. Urmrirea unui astfel de manual de codare nu este mai dificil dect reinerea faptului c o linie de tablou <tr> trebuie s fie imbricat n interiorul unui tablou <table> i nu are, sau nu ar trebui s aib, sens n afara acelui context. Pentru majoritatea situaiilor, acest lucru este suficient. XML este capabil s ofere autorilor suficient ajutor n nvarea modului de utilizare a unei anumite aplicaii, deoarece acetia sunt ncurajai s dea etichetelor nume sugestive, care s fie uor de reinut. Autorul unei aplicaii ar trebui s furnizeze un manual de creare care s explice n termeni simpli modul de utilizare a aplicaiei. Cu toate c orice procesor XML poate spune despre o poriune de cod dac este sau nu construit corect, iar un manual poate ajuta la construirea unui document valid, DTD-ul permite verificarea fr ambiguiti a codului. Totui, n funcie de tipul de creare utilizat, acesta poate fi un pas diferit de procesul de editare. Codul ndeplinete acest ideal n funcie de utilizarea dat numelor etichetelor, totui ntre anumite limite: Numele de etichete care ncep cu irul xml, indiferent de tipul literelor, sunt rezervate; adic, indiferent de situaie, nu este permisa crearea lor. Numele de etichete care conin caracterul dou puncte pot fi interpretate ca identificatori avnd asociat o zon de nume, deci utilizarea celor dou puncte n numele etichetelor este puternic combtut i poate fi chiar interzis. Un nume de etichet trebuie s nceap cu o liter, care n acest context este orice liter sau ideogram Unicode/ISO/IEC 10646, sau cu o liniu de subliniere n continuare, numele unei etichete poate conine orice liter, ideogram sau cifr Unicode/ISO/IEC 10646, caractere de combinare, caractere de extindere, puncte, cratime, spaii sau dou puncte. De altfel, puine limbi de pe glob au caractere cu care s nu poat
Pagina 61 din 97
ncepe un nume corect n limba respectiv. Aceste caractere sunt excluse din lista de caractere dac se afl ntr-o poziie n care pot fi vzute ca primele dup o cratim sau un alt separator logic de cuvinte. Caracterul thailandez mai yamok (arat ca un f ntors i fr liniu), de exemplu, arat ca o liter, dar nu poate fi folosit ca prim liter a unui cuvnt deoarece el semnific repetarea literei anterioare. Caracterele de combinare sunt caractere speciale, folosite pentru a accentua un alt caracter, multe dintre ele fiind normalizate la un singur caracter cu accent. Acesta este un avantaj pentru intrrile de la tastatur deoarece multe limbi care conin caractere accentuate permit introducerea utiliznd caractere accent speciale de lime zero care se pot ataa la orice alt caracter. Caracterele de extindere sunt diverse semne de punctuaie, cum ar fi (n limbile europene) middle dot, triangular colon i half-triangular colon. Caracterele extinse sunt similare n alte scrieri din lume; nu sunt exacte din punct de vedere alfabetic dar se potrivesc pe undeva. 4.6 Startul n XML Acest subiect evideniaz mulimea de deprinderi necesare pentru XML i clarific numeroasele asemnri dintre XML i HTML: XML este sensibil la tipul literelor deoarece majusculele nu reprezint un concept universal Dac s-ar trata literele mari i mici ca fiind echivalente, ar trebui s se fac la fel pentru mii de alte variante de litere n alte limbi, o operaie mpovrtoare. Unele limbi nici nu au tipuri de litere. De exemplu, n limba ebraic nu exist litere mici, iar limba arab nu face distincie ntre forma iniial, de mijloc i final a literelor. Pentru cei care prefer s scrie etichetele cu majuscule i atributele cu litere mici, pentru a le evidenia, aceasta este o tire teribil. Dar editoarele de cod moderne nu mai acord o importan aa de mare acestui lucru ca nainte. De exemplu, precizarea anumitor culori pentru a marca etichete este un lucru obinuit, deci utilizarea majusculelor este ntructva un anacronism istoric, asemenea numerelor de linii n COBOL. XML este foarte precis cu privire la imbricarea corect a etichetelor Etichetele nu se pot ncheia ntr-un context diferit de cel de nceput. Deci, dac se dorete <bold><italics>, fraza evideniat trebuie nchis cu </italics></bold>, pentru a evita o eroare fatal. Deoarece XML poate referi i include documente XML i fragmente de documente oriunde pe Web, fiecare document XML trebuie s se supun acelorai reguli pentru a nu strica documentele altora.
Pagina 62 din 97
XML nu este bine protejat mpotriva recursivitii Cu toate c este posibil stabilirea excluderilor explicite la un anumit nivel, la o structur complex a unui document este dificil meninerea acelor excluderi la un nivel redus, mai ales atunci cnd se utilizeaz etichete care pot fi aplicate la orice nivel. Deci, interdicia HTML referitoare la includerea unei etichete ancor <a> n interiorul altei etichete ancor exist i n XML, dar nu este impus dincolo de includerea direct. XML oblig la nchiderea fiecrei etichete, chiar i a etichetelor vide Deoarece este posibila crearea unui document XML care s nu utilizeze un DTD, un procesor XML nu are de unde s tie dac o etichet este sau nu vid. Deoarece toate documentele XML trebuie s fie construite corect, etichetele vide trebuie marcate cu o sintax special care spune unui procesor XML c eticheta este vid i nchis. Acest lucru se realizeaz plasnd un spaiu i un caracter slash la sfritul etichetei, astfel: <break /> Exist o sintax alternativ, care este la fel de bun pentru procesoarele XML reale, dar blocheaz frecvent browserele Web atunci cnd este utilizat cu XHTML; aceasta cere ca o etichet vid, cum ar fi , s fie nchis cu , astfel: Din pcate, este prea periculoas pentru a fi utilizat n siguran. Multe browsere actuale i majoritatea celor motenite nu recunosc eticheta de nchidere non- HTML i fac lucruri ciudate cu ea. Navigator 4.7, de exemplu, poate zpci afiarea atunci cnd se mpiedic de o etichet . Comportamentul exact poate diferi n funcie de poziia n cod i de eticheta vid care se nchide. Pe scurt, aceast sintax este predispus la erori i ar trebui evitat. XML necesit ncadrarea valorilor atributelor fie ntre apostrofuri, fie ntre ghilimele Acolo unde HTML este indulgent, mai ales n ceea ce privete numerele i aproape orice ir fr spaii n interior, XML trateaz totul ca ir de caractere i las aplicaia s i dea seama singur de toate acestea. XML recunoate mai multe limbi Spre deosebire de HTML, seturile de caractere extinse utilizate n multe limbi europene nu sunt pe deplin recunoscute n mod prestabilit. Exist un mecanism simplu pentru includerea acestora, precum i a ntregului set de caractere Unicode (cunoscut, de asemenea, i ca ISO/IEC 10646) care are peste un milion de caractere, deci suportul pentru chinez, arab i multe alte limbi mai exotice ale lumii este un lucru uor. n afar de diferenele menionate n aceast list, XML este foarte asemntor cu HTML din punctul de vedere al marcrii etichetelor, al argumentrii atributelor i al trecerii coninutului ntre perechi de etichete.
Pagina 63 din 97
Limbajul XML a fost proiectat astfel nct s fie transparent la utilizare pentru a putea fi neles i utilizat cu uurin. Descrierile XML succinte sau complicate din majoritatea documentelor sunt greu de neles n efortul de a fi explicit ntr-un mod n care programatorii s l poat translata cu uurin n aplicaii care s funcioneze. 4.7 Definirea unui document XML ca ntreg Un document XML este o colecie de entiti care pot fi sau nu analizate. Datele care nu sunt nelese de un procesor XML, date binare sau date care au sens numai pentru alte aplicaii, reprezint date neanalizate. Datele nelese de XML, fie ca i caractere fie ca marcaje, sunt date analizate. Un document XML trebuie s fie construit corect. n Recomandarea XML 1.0 a W3C aceast situaie este descris concis prin urmtoarele cerine: Luat ca ntreg, corespunde produciei etichetate ca document. Satisface toate constrngerile de construire corect din aceast specificaie (Recomandarea XML 1.0) Fiecare entitate analizat, referit direct sau indirect n cadrul documentului, este construit corect. Prima constrngere spune c pentru a fi construit corect, un document XML trebuie s respecte toate regulile care descriu un document n Recomandarea XML 1.0. Acele reguli spun n primul rnd c un document XML trebuie s conin un prolog i un singur element care formeaz elementul rdcin al documentului, mpreun cu comentarii opionale i instruciuni de prelucrare la sfritul documentului, dar, din pcate, analizorul XML nu are cum s spun dac aceste comentarii i instruciuni de prelucrare ataate sunt sau nu ataate documentului. Deoarece ele pot sa fie plasate dup eticheta de ncheiere, un analizor XML nu poate s spun nici dac instruciunile de prelucrare i comentariile ataate au fost sau nu recepionate. Aceasta contravine regulii generale din XML care spune c un analizor trebuie s fie capabil s indice dac un document este sau nu complet. Dac se utilizeaz instruciuni de prelucrare sau comentarii, este preferabil trecerea lor n prolog unde sunt mult mai n siguran i nu se pot pierde. Cea de a doua constrngere spune c documentul respect constrngerile construirii corecte descrise n document. Una din constrngerile construirii corecte este c entitile analizate recursiv sunt interzise. Recursivitatea din aceast interdicie se refer la formarea unei bucle de entiti n care o entitate se ncorporeaz pe ea nsi sau o alt entitate care se ncorporeaz pe ea nsi indiferent de nivelul de indirectare. Aceasta mai nseamn i c un document nu se poate referi la el nsui, nici mcar indirect printr-o entitate extern. El se
Pagina 64 din 97
poate referi la o entitate extern numai dac aceasta nu se refer la ea nsi, chiar i indirect. Este posibil ca analizoarele care nu valideaz s nu depisteze aceast eroare, dar aceasta este totui o eroare. Din punct de vedere logic este evident c dac documentul A conine documentul B, definindu-l pe B ca i cnd l-ar conine pe A se genereaz o bucl infinit. Bucla infinit este interzis. n termeni XML, construcia corect este o alt modalitate de a spune c un document XML formeaz un arbore, sau o ramur a unui arbore, adic este complet n sine. Acest lucru este necesar deoarece XML permite construirea de documente mai mari din unele mai mici i reprezint o cheie a posibilitii de utilizare a XML pe Web. Dei construirea corect poate fi considerat suficient deoarece un document construit corect are un DTD care l descrie, pot fi construite un numr infinit de DTD-uri care, de asemenea, s l descrie. Deci, pentru validitate total, un DTD asociat este necesar. Producia documentului este definit n numai dou afirmaii, preluate din nou din Recomandarea XML 1.0: Conine unul sau mai multe elemente. Exist un singur element, numit rdcin sau element document, care s nu aib nici o parte a sa n coninutul oricrui alt element. Pentru toate celelalte elemente, dac eticheta de pornire se afl n coninutul unui alt element, atunci i eticheta de ncheiere se afl n coninutul aceluiai element. Exprimat mai simplu, elemente delimitate de etichete de pornire i ncheiere sunt imbricate corect unele n altele. Prima afirmaie spune c ntr-un document trebuie s existe cel puin un element sau, altfel spus, un document construit corect nu poate fi vid. Cea de a doua afirmaie spune c, ntr-un sens restrns, un document trebuie s fie un arbore. El nu poate fi o reea conectat arbitrar sau s aib orice alt topologie care nu se reduce la un arbore simplu. El trebuie s fie complet pentru a putea vedea diferena dintre o descrcare reuit i una parial. Din punct de vedere tehnic, un arbore este un graf conex care nu conine circuite. Cu alte cuvinte, un arbore se ramific de la rdcina sa fr a se mai conecta la el nsui, deci nu conine muchii multiple sau bucle. Orice lucru care conine bucle sau muchii multiple, nu este un arbore, ci altceva, i nu poate fi reprezentat n XML. Un efect secundar interesant este acela c ntr-un arbore se poate alege arbitrar un punct, i se poate transforma un nod ntr-o rdcin, reorganiznd arborele ntr-un alt arbore, cu o alt ordine de parcurgere. Aceasta ilustreaz caracterul capricios al schemelor de clasificare.
Pagina 65 din 97
O descrcare parial este posibil n HTML, deoarece HTML nu are nevoie de eticheta de ncheiere </html>, sau nu are nevoie de aproape nici o etichet de ncheiere. Uneori browserul poate detecta ntreruperea, dar acest lucru nu este garantat. Aceasta nsemn c un document parial se poate deghiza ntr-unul complet, iar utilizatorul nu are de unde s tie acest lucru pn cnd n text nu apare o eroare evident. XML previne aceste probleme, lucru care poate fi important n cazul n care un utilizator reclam ulterior c o convenie de acordare a licenei, de exemplu, nu a fost afiat n ntregime. Insistnd asupra unui arbore complet, un astfel de exemplu fiind prezentat n Figura 1, se
elimin aceste probleme posibile.
Figura 1 Pe de alt parte, un graf care nu formeaz un arbore nu poate fi transformat ntr-un document XML dect dac graful poate fi simplificat, eliminnd toate caracteristicile care nu sunt reprezentative pentru arbori. n Figura 2, de exemplu, graful din stnga poate fi simplificat prin eliminarea unei ci de la frunza de sus ctre un nod. n aceeai figur,
Pagina 66 din 97
grafului din partea dreapt trebuie s i se elimine o rdcin deoarece un document XML poate avea o singur rdcin.
4.8 Prologul: declaraia XML Fiecare document XML, ar trebui s nceap cu o declaraie XML care identific fiierul ca fiind un fiier XML i identific, de asemenea, versiunea XML utilizat n documentul respectiv. Caracterul opional este datorat numai faptului c pe Web exist multe fiiere HTML i SGML care corespund perfect unui document XML construit corect. De asemenea, declaraia XML este locul unde se declar codificarea i dac documentul este sau nu autonom. Ordinea din fragmentul urmtor este obligatorie cu toate c atributele encoding i standalone sunt ambele opionale. <?xml version=1.0 encoding=ISO-8859-1 standalone=yes> Codificrile permit identificarea crui dintre multiplele seturi de caractere va fi utilizat n document. Acest lucru este important deoarece, spre deosebire de HTML, care implic ASCII, i oblig la folosirea numelor ASCII, XML permite vorbitorilor de Hindi, de exemplu, s utilizeze codificarea lor i s fac textul i mediul de editare lizibil i pentru persoanele obinuite care pot fi autori XML. Sau, un autor chinez poate s prefere caracterele chinezeti n etichete i n coninut cu cteva limitri bazate pe regulile limbajului n sine, se pot utiliza moduri de scriere i ideograme att n numele etichetelor ct i n coninut. 4.9 Documente autonome
Pagina 67 din 97
n conformitate cu Recomandarea XML 1.0 a W3C, Documentele autonome nu au declaraii de marcare externe care s afecteze informaia XML transferat de procesorul XML unei aplicaii. Acesta este un mod extraordinar de succint i obscur de a spune c standalone=yes nseamn c: ntr-un DTD extern nu exist valori prestabilite declarate ale atributelor care s nu fie setate explicit n document. Nu sunt utilizate alte entiti n afar de &, <, >, ', i ", care nu au fost declarate local sau poate citite prin referin dintr-un fiier. Nu exist elemente care s aib ca i coninut numai spaii albe de orice natur. Nu exist atribute externe care trebuie normalizate, deci coninutul atributelor nu poate conine spaii albe, caractere sau referine la entiti. Aceasta nu nseamn c documentul nu are nimic extern. Aceasta nseamn n special c, indiferent de locul n care un procesor XML care nu valideaz se oprete din citirea documentelor externe, se oprete prelucrarea tuturor declaraiilor. Toate aceste lucruri se pot face dac i numai dac sunt puse n submulimea DTD-ului intern. Datele externe care nu sunt marcaje nu fac subiectul acestei afirmaii. Deci, pot exista fiiere grafice, fiiere text incluse i orice altceva, att timp ct ele nu sunt marcaje i au fost declarate n submulimea DTD-ului intern. Dup toate acestea, procesorul XML nu trebuie s anune aplicaia dac documentul este sau nu autonom. De fapt, procesorul nu trebuie s fac nimic cu aceast informaie i nici s se comporte ntr-un anumit fel atunci cnd ntlnete aceast informaie. n mod fundamental, proiectantul DTD-ului trebuie s descifreze dac documentul creat utiliznd acel DTD poate fi sau nu autonom i s comunice acest lucru oamenilor inclusiv autorilor. Autorii care tiu c DTD a fost proiectat pentru a fi autonom sau cei care au convertit un document care nu a fost proiectat s fie autonom n acest format, pot insera stanalone=yes n declaraia lor XML ca o documentaie a acelui fapt: <?xml version=1.0 standalone=yes ?> Documentele care nu sunt autonome pot fi convertite prin algoritmi la documente autonome, automat, presupunnd c este disponibil o facilitate care s realizeze acest lucru, sau manual n caz contrar. 4.10 Construirea prologului unui document XML: Declaraia tipului documentului (Document Type Declaration) Prologul unui document XML conine mai multe instruciuni. Prima, declaraia XML, afirm c documentul urmtor este XML. Cea de a doua, declaraia tipului documentului (Document Type Declaration), este metoda utilizata pentru a identifica definiia tipului
Pagina 68 din 97
documentului (Document Type Definition - DTD) folosit de un anumit document. Faptul c acronimul DTD poate fi aplicat la Document Type Declaration este o coinciden nefericit. DTD se refer numai la Document Type Definition. ntr-un document XML poate exista o singur declaraie a tipului documentului, deci este introdus chiar n instana documentului. Deoarece pot fi combinate mai multe DTD-uri pentru a forma un singur document, aceasta permite controlul ncrcrii DTD-urilor n fiecare document. Declaraia tipului documentului (DOCTYPE) are dou pri, ambele opionale. Prima se refer la un DTD extern, i utilizeaz cuvinte cheie PUBLIC sau SYSTEM pentru a identifica o intrare dintr-un catalog, respectiv un URI. n cazul n care cataloagele nu sunt implementate n procesorul XML, se pot specifica ambele pri deodat, fr cel de al doilea cuvnt cheie: <!DOCTYPE nume-document PUBLIC {catalog id}> <!DOCTYPE nume-document PUBLIC {catalog id} {uri}> <!DOCTYPE nume-document SYSTEM {uri}> Cea de a doua parte opional a declaraiei DOCTYPE permite introducerea submulimii interne a unui DTD direct n document. Exist restricii severe cu privire la genul de informaie care poate fi introdus n DTD-ul intern, dar oricum se pot face destul de multe. Submulimea intern a unui DTD este ncadrat ntre paranteze drepte, astfel: <!DOCTYPE nume-document [ {declaraiile DTD-ului intern} ]> De asemenea, cele dou pot fi combinate, permind adugarea anumitor tipuri de declaraii i entiti aproape n orice mod: <!DOCTYPE nume-document PUBLIC {catalog id} {uri} [ {declaraiile DTDului intern} ]> Pentru claritate, submulimea intern este evideniat ca mai jos: <!DOCTYPE nume-document PUBLIC {catalog id} {uri} [ {declaraiile DTD-ului intern} ]> Declaraia DOCTYPE trebuie s utilizeze numele elementului rdcin al DTD-ului fie acesta intern sau extern, ca fiind cmpul etichetat nume-document din exemplele anterioare. Deci dac numele elementului rdcin al DTD-ului este Dave, declaraia DOCTYPE ar trebui s nceap astfel: <!DOCTYPE Dave > Manualul de codare indic autorilor ce trebuie trecut n DOCTYPE. Un proiectant DTD ar trebui s furnizeze un astfel de document sau o foaie de codare fiecrui autor. De
Pagina 69 din 97
asemenea, se poate crea un DTD master care apeleaz prile DTD necesare, lucru care seamn cu comenzile dintr-un meniu. Atunci cnd se obine o combinaie de funcionaliti care permite crearea structurii documentului de care este nevoie, se poate publica DTD-ul rezultat i nltura neplcerea refacerii pentru fiecare document nou. 4.10.1 Crearea corpului documentului Un document XML este alctuit din text, care de obicei este format dintr-un amestec de marcaje i date caracter. Prologul conine numai marcaje, dar nu aceasta este partea interesant, deoarece este nevoie de date care s nsoeasc marcajele care, altfel, nu ar fi dect nite cutii goale ce ateapt s fie umplute. Corpul documentului conine aproape tot ceea ce conteaz din perspectiva unei aplicaii mprtiate generos n cadrul marcajelor. 4.10.2 Date caracter Un DTD poate declara multe tipuri de date care s poat fi utilizate ntr-un document, dar tipul de date prestabilit este ntotdeauna CDATA, pentru date obinuite de tip caracter. Foaia sau manualul de codare indic ce tip de dat poate fi introdus n fiecare atribut sau cmp cu coninut element. Presupunnd c tipul de date este CDATA, n cmp se poate pune aproape orice se dorete att timp ct nu conine un marcaj n afara unei secvene escape. Este pe deplin posibil construirea unui DTD care s nu conin text n interiorul elementelor. n schimb, se pot pune datele semnificative n interiorul atributelor asociate fiecrui element, care pot fi toate declarate ca fiind vide sau avnd numai coninut element. Acest lucru se face uneori pentru a converti un document utiliznd un standard de codificare cum ar fi MARC, care este n esen un format binar, la XML. 4.10.3 Marcajul Marcajul este format din ansamblu de date non-caracter dintr-un fiier XML. Diversele forme pe care le poate lua un marcaj sunt prezentate n tabelul urmtor:
Tabel 1 Sintaxa marcajului XML

Pagina 70 din 97
Toate celelalte sunt date de tip caracter. Marcajul ncepe ntotdeauna fie cu caracterul <, caz n care se ncheie ntotdeauna cu caracterul >, fie cu caracterul &, caz n care se ncheie ntotdeauna cu caracterul ;. 4.10.4 Formarea structurilor logice n XML Imbricarea elementelor este singurul mecanism utilizat pentru a arta structura logic dintr-un document XML. Etichetele de pornire i ncheiere din fluxul de text spun procesorului XML c a fost ntlnit un nod. Dac procesorul XML ntlnete o alt etichet de pornire nainte de eticheta de ncheiere corespunztoare, atunci procesorul tie c acesta este fie un nod nou n arbore, fie o frunz. Dac nu gsete o nou etichet de pornire i ntlnete o etichet de ncheiere, atunci procesorul tie c aceasta este o frunz i c poate aciona iterativ la acel nivel al arborelui pn cnd ntlnete o alt etichet de pornire sau de ncheiere. Prelucrarea acioneaz treptat, bazndu-se pe aceast regul simpl. Dac procesorul valideaz documentul, atunci fiecrui nod i se poate asocia o regul care s determine ce tip de coninut poate aprea n el. O etichet vid este, prin definiie, o frunz, deoarece nu poate avea nici un coninut. Majoritatea structurilor de date coninute ntr-un document XML pot fi accesate secvenial fr a construi structura n memorie. O etichet de pornire ncepe un nod sau o frunz, iar eticheta de ncheiere corespunztoare l(o) ncheie. Orice etichete ntlnite ntre o etichet de ncheiere corespunztoare ei ncep un nod sau o frunz nou. Acest principiu reprezint baza lui SAX i a altor procesoare XML conduse prin evenimente. Restul structurii logice a documentului este definit prin atributele asociate fiecrui element. n plus, structura logic poate diferi n funcie de coninutul seciunilor condiionale din cadrul documentului sau al componentelor sale. 4.10.5 Cum formeaz XML structurile fizice Imbricarea entitilor este singurul mecanism utilizat pentru a arta structura fizic dintr-un document XML. Definiiile de entiti ntlnite n fluxul de text i comunic procesorului XML c a fost gsit o alt entitate. Exist multe tipuri de entiti, de la entitile mici care formeaz caractere individuale, cum ar fi: (spaiu), pn la entitile externe care permit ncorporarea ntr-un document poriuni din alte documente XML sau includerea ntr-un document a referinelor la date neanalizate, cum ar fi fiiere multimedia pentru redarea ulterioar de ctre un agent utilizator.
Pagina 71 din 97
Un document XML este o colecie de astfel de entiti. Fiecare din aceste subentiti trebuie s fie complet n sine. Aceasta nseamn c, deoarece structura documentului ca ntreg trebuie s fie un arbore simplu, fiecare subentitate trebuie s fie un singur nod sau trebuie s fie, de asemenea, un arbore simplu. Structuri mai mari se pot construi prin adugarea nodurilor sau a arborilor subentitate ca poriuni ale arborelui mai mare. 4.10.6 Etichete de pornire i etichete de ncheiere n XML sunt utilizate dou tipuri de etichete, etichete cu coninut i etichete vide. Etichetele cu coninut trebuie s aib o etichet de pornire i o etichet de ncheiere. Eticheta de pornire conine numele elementului ncadrat ntre paranteze unghiulare, avnd opional atribute ca argumente. Eticheta de ncheiere conine numele elementului precedat de caracterul slash, totul fiind ncadrat ntre paranteze unghiulare. n eticheta de ncheiere nu putei trece atribute. Codul urmtor reprezint o etichet cu coninut: <titlu subtitlu=0 cltorie acas >Dus-ntors</titlu> Seamn mult cu etichetele HTML standard i nu ar trebui s ridice alte probleme n afara celei de construire corect, care cere ca ele s se imbrice ntr-adevr una n cealalt. Nu pot exista etichete care s alterneze ntre ele ca n acest exemplu greit construit: <bold><italic>TEXT ACCENTUAT</bold></italic> Cu toate c este o eroare obinuit n HTML, XML este cu mult mai pretenios i nu va permite aceast construcie. Etichetele trebuie imbricate corect, dup cum se vede n exemplul urmtor: <bold><italic>TEXT ACCENTUAT</italic></bold> Acum etichetele sunt imbricate corect. Trebuie nchis fiecare etichet care ncepe n contextul unei anumite etichete (sau a mai multor etichete) nainte de nchiderea contextului etichetei respective. Etichetele vide au disponibil un format special, cu toate c aceeai schem, etichet de pornire/ etichet de ncheiere, poate fi utilizat atta timp ct se ine cont de faptul c nu trebuie pus nici un fel de coninut ntre eticheta de pornire a elementului vid i eticheta de ncheiere care urmeaz imediat dup ea. De asemenea, poate exista preocuparea c este posibil ca documentul XML s fie vizualizat cu un browser Web obinuit, deoarece etichetele de ncheiere pentru elementele care arat ca etichete HTML vide pot duce la blocarea browserului sau la un comportament ciudat al acestuia. Totui, pentru utilizare general, formatul special este mnemonic n sine, un avantaj deoarece se poate vedea c eticheta este vid i nu blocheaz aproape nici un browser. De obicei, etichetele vide sunt pornite i ncheiate n cadrul aceleiai perechi de paranteze unghiulare, plasnd dup numele
Pagina 72 din 97
elementului i toate atributele sale posibile un spaiu, un caracter slash i apoi paranteza unghiular nchis: <image source=pozamea.jpeg type=JPEG /> 4.10.7 Normalizarea Normalizarea este un cuvnt excentric pentru aducerea lucrurilor la cel mai mic numitor comun i punerea lor ntr-un fel de form canonic. n contextul XML, el se refer la procesul rezolvrii referinelor la entiti n locaii n care pot aprea astfel de referine, la aranjarea rndurilor noi pentru a lua n considerare diversele metode de tratare a lor de ctre diferite sisteme de operare i la ordonarea altor lucruri care trebuie fcute n anumite situaii. Proiectantul rareori trebuie s se preocupe de normalizare, excepie fcnd cazurile negative. Analizorul XML ar trebui s realizeze toate normalizrile necesare, deci singurul lucru la care trebuie s se gndeasc creatorul documentului este dac normalizarea va afecta sau nu datele sale atunci cnd se va face trecerea de la forma nenormalizat i invers. S-a dovedit c exist dou locuri n care pot fi ntlnite spaii albe: n datele de tip caracter din cadrul documentului i n datele de tip caracter atribuite atributelor elementelor. n primul caz, n entitile analizate este dificil s se fac distincie ntre spaiile albe semnificative i cele nesemnificative. Pentru proiectani, cea mai bun cale pare s fie transferul ctre aplicaie al tuturor spaiilor albe mpreun cu cea mai bun presupunere a procesorului, bazat pe DTD, referitoare la datele care sunt n mod sigur nesemnificative i la cele nesigure. Acest transfer de rspundere are sens deoarece aplicaia este cea n msur s tie cum s procedeze cu spaiile albe suplimentare. Procesorul XML poate numai s presupun care spaiu alb este semnificativ i care nu, bazndu-se pe ceea ce a fost definit n DTD sau n orice alt limbaj de scheme utilizat. O aplicaie trebuie s fie pregtit s trateze presupunerile eronate. Cu tratarea sfriturilor de linie, o alt form de spaii albe, exist o alt problem. Liniile noi sunt tratate diferit pe sisteme diferite. Alternativele generale sunt un salt la linie nou (UNIX), un return (MacOS) i att un return ct i saltul la linie nou (MS Windows). Un alt lucru obinuit pentru aplicaii este, de asemenea, inserarea de secvene contradictorii cu oricare dintre acestea, n orice ordine, atunci cnd ntlnesc un fiier dintr-un sistem strin. W3C a hotrt c nu poate face totul i a ales un set rezonabil de reguli. Dac analizorul ntlnete fie
(return , salt la linie nou), fie (return), el le nlocuiete cu &#0A; (salt la linie nou), caracterul de linie nou UNIX. Microsoft i Apple au ales mecanisme diferite pentru separarea liniilor, Microsoft alegnd tehnica curea i bretele obinuit pentru teleimprimatoare, utiliznd un return i
Pagina 73 din 97
apoi un salt la linie nou pentru a indica o linie nou. Apple a hotrt c saltul la linie nou era redundant i a considerat c un singur return este suficient, modelat probabil dup comportamentul unei maini de scris obinuite. UNIX a utilizat de la nceput un singur salt la linie nou pentru a realiza acelai lucru, iar acesta a fost standardul convenit pentru XML. n atribute exist o secven de transformare standard i apoi o prelucrare adugat special pentru orice n afar de CDATA: Referinele la caractere sunt prelucrate prin adugarea caracterului referit la valoarea de ieire a atributului. Referinele la entiti sunt procesate prin prelucrarea recursiv a textului de nlocuit al entitii. Spaiile albe, #x20 (spaiu), #x0D (retur de car), #x0A (salt de linie nou) i #x09 (tab orizontal) sunt prelucrate prin adugarea lui #x20 (spaiu) la valoarea normalizat a ieirii excepie fcnd faptul c se adaug un singur #x20(spaiu) pentru secvena #x0D#x0A (retur de car, salt la linie nou), care este parte a unei entiti externe analizate sau valoarea entitii literale a unei entiti analizate interne. Celelalte caractere sunt prelucrate prin adugarea lor la valoarea normalizat a ieirii. Dac tipul de dat al atributului nuI este CDATA, cel prestabilit, atunci se aplic nc o transformare. Spaiile din fa i din spate sunt eliminate, iar spaiile multiple sunt comasate ntr-un singur spaiu. Diferena dintre cele dou tipuri de normalizare const n faptul c se pot transfera n mod convenabil iruri lungi ntr-un atribut, restrnge linii astfel nct s ncap n pagin, iar n final coninutul elementului s rmn relativ curat. 4.10.8 Tipuri de elemente n mod surprinztor, la validare nu este o eroare utilizarea unui element de un tip care nu a fost declarat, cu toate c este posibil ca analizorul s emit un advertisment. De fapt, permind n interiorul unor elemente alte tipuri de elmente nedeclarate, indiferent de ceea ce spune modelul lor de coninut, se poate suplimenta DTD-ul unui document cu elemente din alte zone de nume. Deci, tot ce rmne de fcut este utilizarea elementului nedeclarat ntr-o manier exact, construit corect, identificnd pe ct posibil zona de nume de unde provine. n termeni XML, a fi construit corect este un alt mod de a spune c acel element formeaz un arbore sau o ramur a unui arbore care este complet n sine. Acest lucru este necesar deoarece XML permite construirea de documente mai mari din unele mai mici i este un element cheie pentru utilizarea XML pe Web. Fiecare element dintr-un document XML valid
Pagina 74 din 97
a fost definit n DTD-ul asociat acelui document prin declaraia DOCTYPE. DTD-ul declar urmtoarele: Numele efective ale elementelor Regulile utilizate pentru a determina care elemente se pot imbrica n alte elemente i n ce ordine Atributele posibile i valorile lor prestabilite sau constante Valorile caracter ale tipurilor enumerate Entitile neanalizate utilizate n document i modul n care sunt referite prin nume Codificrile de limb utilizate n document Alte informaii importante pentru prelucrarea i redarea documentului Respectnd aceste reguli se pot crea documente n concordan cu ablonul pe care proiectantul documentului l-a avut n minte atunci cnd a creat DTD-ul. ntr-un mediu care nu valideaz se pot crea etichete i atribute pe msura naintrii. Foaia sau manualul de codare afieaz toate acestea ntr-un format uor de citit i neles, dac autorul DTD-ului i-a fcut treaba corect. Cnd se creeaz un document XML sau se corecteaz o eroare, este posibil s nu se beneficieze de avantajul unui mediu de creare complet. Este ntotdeauna important pstrarea la ndemn a documentaiei de codare pentru cazul n care apar defeciuni. 4.10.9 Entiti neanalizate O entitate neanalizat este orice lucru care nu poate fi recunoscut de un procesor XML, fie date binare, cum ar fi un fiier imagine sau audio, fie text care trebuie s fie transferat unei aplicaii fr a fi prelucrat n vreun fel. HTML utilizeaz comentarii pentru a ascunde un astfel de text de browserul HTML, dar XML are cteva mecanisme care funcioneaz mult mai sigur. O entitate neanalizat trebuie mai nti s fie declarat ca NOTATION, o declaraie special care numete o aplicaie de asisten care tie cum s lucreze cu entiti de un anumit tip. Notaiei i este dat un nume, un identificator public opional i apoi numele mai puin opional al aplicaiei de asisten, ca n una din variantele urmtoare: <! NOTATION nume-mnemonic PUBLIC identificator-public> <! NOTATION nume-mnemonic PUBLIC identificator-public numeaplicaie.exe> <! NOTATION nume-mnemonic SYSTEM nume-aplicaie.exe> Prima opiune funcioneaz numai dac exist un catalog. Nu se poate pune baza pe un catalog deoarece acesta funcioneaz indiferent dac exist sau nu catalog. Nu se poate
Pagina 75 din 97
baza pe un catalog deoarece acesta este un instrument SGML pe care multe procesoare XML actuale l-au motenit implicit de la predecesoarele lor SGML. Studierea catalogului nu este specificat n recomandarea W3C i nu se poate conta niciodat pe ea. Dac este posibil, se recomand utilizarea ultimele dou versiuni. Pe de alt parte, codarea hard a informaiilor despre locaia i identitatea aplicaiei de asisten n absolut fiecare DTD este un anacronism predispus la erori pe Web. Prin redefinirea comportamentului script-urilor n prezena comentariilor, proiectanii XML-ului au introdus o problem de incompatibilitate ntre XML i HTML. Dup toate probabilitile, procesoarele XML vor continua s transfere comentarii la aplicaii deoarece multe pagini se vor ntrerupe dac nu vor avea acest comportament. De asemenea, procesoarelor le este permis transferul informaiei comentate prin acelai limbaj prin care li se permite s nu o fac. Dup ce o notaie a unei entiti neanalizate a fost definit, ea trebuie s fie declarat ca o entitate, astfel: <! ENTITY nume-mnemonic NDATA nume-mnemonic> i apoi trecut ca un atribut ntr-un element pentru a o putea utiliza: <! ELEMENT name EMPTY> <! ATTLIST name type NOTATION mnemonic > Numele mnemonice nu mpart aceeai zon de nume, deci nu are importan dac ele sunt identice. n acest moment se poate utiliza tipul de date definit astfel. Tipul de date poate fi utilizat numai ca atribut al unui element declarat ca fiind de acel tip sau avnd acel tip disponibil ntr-o enumerare. Celelalte atribute adun informaiile de care are nevoie aplicaia de asisten extern pentru a fi capabil s prelucreze datele. O aplicaie tipic poate fi un fiier imagine: <image source =uri alt =graphic description type=gif89a> Acest element va necesita n DTD urmtoarele declaraii: <! NOTATION gif89a PUBLIC -//CompuServe//NOTATION Graphics Interchange Format 89a//EN explorer.exe> <! ENTITY gif89a NDATA gif89a > <! ELEMENT image EMPTY> <! ATTLIST image source CDATA #REQUIRED alt CDATA #IMPLIED type NDATA gif89a >
Pagina 76 din 97
Pentru majoritatea instrumentelor, nu va avea importan dac formatul este specificat ca gif87a sau ca gif89a, deoarece aceleai instrumente manevreaz ambele formate. Notaiile vor fi mult mbuntite o dat cu adugarea facilitilor oferite de XLink/XPointer care ajut la urmrirea locaiilor asistenilor. Cu instabilitatea general a Web-ului la nivelul su actual i cu larga varietate de faciliti i arhitecturi de pe sistemele utilizatorilor, orice ajutor care poate fi obinut de ctre utilizator va face mai uoar configurarea instrumentelor XML. DTD-ul, n forma sa actual, necesit mult prea mult ajustare n stil UNIX a fiierelor pentru a fi pe placul utilizatorilor obinuii. XLink i XPointer ncearc s nving limitrile tehnologiei pointer actuale. Permit toate tipurile de relaii, inclusiv pointeri inveri care s fie generai pe loc n documente fr acces la scriere, realiznd-ui efectul chiar asupra copiei afiate, i nu prin inserarea fizic brut a etichetelor n coninut. Cerinele XML pentru notaii, n forma actual, sunt extrem de severe. Posibilitatea de a indica locaia unde se afl aplicaia de asisten poate fi comod pentru notaii neobinuite sau foarte specializate. Totui, este de ateptat ca agentul utilizator s tie cum s afieze multe dintre tipurile mai obinuite, cum ar fi GIF-uri, JPEG-uri, PNGuri, WAV-uri i alte tipuri de fiiere binare mai mult sau mai puin standard, utilizate pe Web. Iat o list a notaiilor obinuite: <! NOTATION eps PUBLIC +//ISBN -201-18127-4::Adobe//NOTATION Postscript Language Reference Manual//EN> <! NOTATION tex PUBLIC +//ISBN -201-13448-9::Knuth//NOTATION The TeXbook//EN> <! NOTATION cmgchar PUBLIC ISO 8632/2//NOTATION Character encoding //EN > <! NOTATION cmgbinary PUBLIC ISO 8632/3//NOTATION Binary encoding //EN > <! NOTATION cmgclear PUBLIC ISO 8632/4//NOTATION Clear text encoding //EN > <! NOTATION tiff PUBLIC ISO 12083:1994//NOTATION TIFF-1 //EN > <! NOTATION jpeg PUBLIC ISO/IEC 10918:1983//NOTATION Digital Compresion and Encoding of Continuous tone Still Images (JPEG)//EN > <! NOTATION gif87a PUBLIC -//CompuServe //NOTATION Graphics Interchange Format 87a//EN
Pagina 77 din 97
> <! NOTATION gif89a PUBLIC -//CompuServe //NOTATION Graphics Interchange Format 89a//EN > <! NOTATION fax PUBLIC -//USA-DOD//NOTATION CCITT Group 4 Facsimile Type 1 Untiled Raster//EN > Desigur, va trebui s se adauge un ID sistem pentru a le putea utiliza, fie ca pointer la o aplicaie de asisten local, fie n fiierul catalog care centralizeaz locaiile acestor aplicaii, dac este disponibil pentru instrumentele folosite. 4.10.10 Aplicaii din lumea real S-au vzut deja, mai sus, unele dintre instrumentele care pot fi utilizate pentru a crea un document XML, dar unde se pot gsi DTD-urile? Multe DTD-uri se afl n domenii publice sau sunt disponibile ca standarde de la ISO, ANSI sau de la alte organisme de standardizare. Cteva dintre aplicaiile mai importante ale XML care se afirm n lumea de azi sunt: Health Level-7 (HL7), Standardul informatic de sntate (Health Informatics Standard) a fost introdus n anul 1987 pentru a dezvolta standarde pentru schimbul electronic de informaii clinice, financiare i administrative ntre sistemele de calcul din domeniul sntii. HL7 s-a concentrat asupra utilizrii SGML i XML ca mecanisme de transport ntre diferite sisteme informatice din domeniul sntii. Real Estate Transaction Standard (RETS standardul de tranzacii imobiliare) este o metod bazat pe XML pentru schimbul de informaii referitoare la tranzaciile imobiliare. Un standard concurent este Real Estate Markup Language (RELML limbajul de marcare pentru domeniul imobiliar) care utilizeaz DTD-urile XML pentru a prezenta listinguri cu spaii pentru locuine, spaii comerciale i terenuri virane, pentru publicarea lor pe Web. RosettaNet, limbajul comun pentru afaceri, este o iniiativ EDI/E-Commerce destinat intermedierilor n domeniul calculatoarelor. MathML i CML sunt dou standarde XML tiinifice care permit matematicienilor s editeze ecuaii, iar chimitilor s prezinte formule chimice. SMIL, the Synchronized Multimedia Integration Language (limbajul de integrare multimedia sincronizat), este HyTime for Everyman (HyTime pentru fiecare), un limbaj de marcare multimedia care permite furnizorilor de coninut s realizeze prezentri audio i video complexe.
Pagina 78 din 97
ICE, Information and Content Exchange (schimb de informaii i coninut), cu toate c nu este chiar o aplicaie XML, fiind de fapt un mecanism de transport, permite schimbul de investiii on-line i informaii personale pe Web. SAE J2008 este un sistem de comenzi i inventariere bazat pe XML pentru industria auto; MISTI, the Missile Industry Supply-chain Transaction Infrastructures, face acelai lucru pentru industria spaial. Chinese DTDs furnizeaz structura specializat necesar pentru publicarea n limba chinez. DTD-uri similare exist pentru japonez, coreean, vietnamez i multe alte limbi. GedML, un standard XML genealogic, ncurajeaz fluxul liber pe Web al datelor genealogice. Exist deja programe pentru conversia fiierelor standard Genealogical Data COMmunication (GEDCOM) la GedML. Fiecare productor de browsere are standarde propuse, despre care ceilali se plng c sunt ndreptate mpotriva lor. Aa cum rzboaiele browserelor au dus la dezvoltarea unor extensii patentate la HTML, care tindeau (sau ncercau) s blocheze celelalte browsere, crend un turn Babel de metode incompatibile, XML va fi ntr-o continu schimbare pentru o bun perioad de timp. Totui, bazele exist deja, iar o comunitate de utilizatori cernd din ce n ce mai insistent standarde deschise conduce diferitele propuneri spre convergen. Multe dintre succesele majore au fost standarde ale ISO i ANSI, care vnd documentaia pentru a-i finana eforturile n crearea de standarde, dar asigur un teren neutru pentru toi partenerii. Pentru preul documentaiei, de obicei cteva sute de dolari, toi pot concura la acelai nivel.
CAPITOLUL V PREZENTAREA APLICAIEI ElectronX este o aplicaie e-commerce, un site web ce reprezint un magazin virtual de electronice care se adreseaz tuturor persoanelor care doresc s achiziioneze diverse produse, n cazul de fa electronice, prin intermediul internetului accesnd un magazin virtual din confortul propriei locuine, comerul electronic mondial avnd o dinamic ascendent pe msur ce tot mai muli consumatori i tot mai multe afaceri se conecteaz la web, acest tip de comer ctignd din ce n ce mai mult teren i n Romnia. Aplicaia se dorete a fi o unealt folositoare utilizatorilor, avndu-se n vedere dezvoltarea interfeei pentru a fi user-friendly, dorindu-se a fi o aplicaie ct mai uor de
Pagina 79 din 97
folosit, eventualele neajunsuri i opinii putnd fi aduse la cunotina administratorului siteului prin adresele de e-mail puse la dispoziia utilizatorilor n pagina de contact. Tehnologiile folosite pentru realizarea aplicaiei sunt PHP pentru generarea dinamic paginilor XHTML i interogarea bazelor de date , i MySql pentru gestionarea bazelor de date, totul rulnd pe suportul oferit de serverul Apache. Realizarea acestui site presupune utilizarea unei baze de date care s conin att date despre utilizatori ct i date despre produsele puse n vnzare i date despre comenzile efectuate de ctre utilizatori. Baza de date va conine apte tabele cuprinznd informaiile necesare bunei funcionri a aplicaiei. 5.1 Cerine hardware Aplicaia nu necesit componente hardware performante. Cerinele hardware pentru server sunt: Procesor Pentium IV 2600 MHz Memorie RAM 512 Mb Hard Disk 120 Gb Minimul cerinelor hardware pentru utilizatori consta in: Procesor Pentium III (AMD Athlon), 800 MHz Memorie RAM 128 Mb 5.2 Cerine software Cerinele software pentru aplicaie sunt: Pentru server: Wampserver 5, versiunea 1.6.4 Un editor PHP Pentru client: Internet Explorer 5.0 si versiunile urmtoare sau Mozilla Firefox 1.0.7 5.3 Funcionalitile aplicaiei La accesarea site-ului se va deschide pagina principal unde utilizatorul se va putea autentifica prin intermediul unui nume de utilizator i a unei parole. Dac nu are cont i va putea crea unul nou. Dup autentificare utilizatorul poate s modifice datele personale sau parola deschizndu-se un formular predefinit unde se pot efectua schimbrile dorite. Utilizatorul poate s acceseze pagina de prezentare a produselor oferite de site de unde i poate alege unul sau mai multe produse pentru a le cumpra. Produsele alese vor fi
Pagina 80 din 97
adugate ntr-un co de cumprturi acestea putnd fi comandate. La trimiterea comenzii datele utilizatorului i produsele comandate sunt reinute n baza de date. Se poate de asemenea efectua o cutare dup nume a produselor, fiind afiate rezultatele cutrii n baza de date. 5.4 Proiectarea bazei de date Baza de date conine apte tabele. Tabela Utilizatori conine informaii despre utilizatorii nregistrai n sistem. Tabela Itemi reine datele despre produsele oferite la vnzare. n tabela Caracteristici sunt reinute caracteristicile fiecrui produs din tabela Itemi n tabela Categorii sunt stocate datele categoriilor definite pentru ierarhia produselor. n tabela Co sunt reinute produsele pe care un utilizator logat dorete s le comande la un moment dat. Dup trimiterea comenzii sau la ieirea din cont nregistrrile din aceast tabel sunt terse. Tabela Comenzi conine informaii despre toate comenzile efectuate de ctre utilizatori. Tabela Itemi_Comanda stocheaz datele despre produsele comandate.
Structura bazei de date este descris n schema conceptual urmtoare:
Pagina 81 din 97
Schema fizic a bazei de date se prezint astfel: Utilizatori Tip Cmp id utilizator parola nume prenume cnp varsta email telefon adresa sector cod_post al oras judet int(11) char(60) char(60) char(30) char(30) varchar(13) char(3) varchar(50) varchar(25) varchar(255 ) varchar(2) varchar(10) char(30) varchar(25) N ul D a D a D a D a D a D a D a D a D a D a D a D a D a D a Itemi Cmp item_id cat_id nume_item Prt Tip int(11) int(11) varchar(75) float(8,2) Nul Da Da Da Da Setare de baz NULL Setri extra Cheie Setare de baz NULL Setri extra Auto_incremen t Cheie primar
Auto_increment Primara -
Pagina 82 din 97
descriere imagine
varchar(200) varchar(50)
Da Da Nu Setare de baz Setare de baz NULL Setri extra Setri extra
Cheie
Caracteristici Tip Cmp Id_item producator Model Categorii Cmp cat_id nume_cat desc_cat Co Cmp Id Id_sesiune Id_item_v Cant producator Model data_ad Comenzi Cmp id_c data_c Nume_c adresa Oras cod_postal Judet sector valoare mod_plata Status
l int(11) Da varchar(25) Da varchar(25) Da Tip Nu
Cheie
l int(11) Da varchar(50) Da varchar(200) Da Tip int(11) char(60) int(11) int(11) varchar(25) varchar(25) datetime Tip Int(11) datetime varchar(100) varchar(255) varchar(50) varchar(10) varchar(25) varchar(2) float(8,2) varchar(20) enum('procesata', 'asteptare') Nu l Da Da Da Da Da Da Da
Auto_increment primar Setri extra Cheie
Setare de baz NULL
Auto_increment primara Setare de baz NULL Setri extra Cheie
Nu l Da Da Da Da Da Da Da Da Da Da Da
Auto_increment primara -
Itemi_comanda Cmp Id
Tip int(11)
Nul Setare de baz Da NULL
Setri extra Auto_increment
Cheie primar
Pagina 83 din 97
Id_comanda Id_item Cant producator Model Prt
int(11) int(11) int(11) varchar(25) varchar(25) float(8,2)
Da Da Da Da Da Da
5.5 Implementarea codului Dup crearea bazei de date, urmtorul pas este generarea paginilor web ale aplicaiei folosind codul HTML/PHP. Pentru editarea codului am folosit utilitarul PHPEdit versiunea 2.10.0.4616 dezvoltate de compania WaterProof Software, acest utilitar putnd fi descrcat de pe internet de la adresa http://www.waterproof.fr/ cu o licen de utilizare gratuit pe o perioada de 30 de zile. Acest editor de cod este destinat n special crerii scripturilor PHP oferind suport i pentru alte limbaje: HTML, CSS, XML, XSLT, Javascript, SQL. Sistemul complet are dou tipuri de componente: fiiere HTML i fiiere PHP. Interfaa aplicaiei este realizat cu ajutorul paginilor HTLM, iar scripturile PHP gestioneaz interaciunea dintre paginile HTML i baza de date prin intermediul serverului Apache. Inregistrare.php Atunci cnd un client nou dorete s achiziioneze unul din produsele oferite de siteul ElectronX trebuie s i creeze mai nti un cont de utilizare. Clientul trebuie s introduc datele personale (nume, prenume, CNP, vrsta, adresa de e-mail, telefon, adres, ora, jude ) ntr-un formular, precum i un nume de utilizator i o parol. Datele vor fi folosite nregistrarea comenzilor i pentru a deine o eviden a utilizatorilor site-ului. Contul nu va fi creat dac nu sunt completate toate cmpurile considerate obligatorii. Dup inserarea datelor n tabela Utilizatori se creeaz i fiierul clieni.xml n care sunt stocate toate datele clienilor nregistrai n baza de date. $_SESSION['user'] = $_POST['user']; $_SESSION['parola1'] = $_POST['parola1']; $_SESSION['parola2'] = $_POST['parola2']; $_SESSION['nume'] = $_POST['nume']; $_SESSION['prenume'] = $_POST['prenume']; $_SESSION['cnp'] = $_POST['cnp']; $_SESSION['varsta'] = $_POST['varsta'];
Pagina 84 din 97
$_SESSION['email'] = $_POST['email']; $_SESSION['telefon'] = $_POST['telefon']; $_SESSION['adresa'] = $_POST['adresa']; $_SESSION['sector'] = $_POST['sector']; $_SESSION['cod_postal'] = $_POST['cod_postal']; $_SESSION['oras'] = $_POST['oras']; $_SESSION['judet'] = $_POST['judet'];
if(($_SESSION['user'] == '') || ($_SESSION['parola1'] == '') || ($_SESSION['parola2'] != $_SESSION['parola1']) || ($_SESSION['nume'] == '') || ($_SESSION['prenume'] == '') || ($_SESSION['varsta'] == '') || (!is_numeric($_SESSION['varsta'])) || (strlen($_SESSION['varsta']) < 2) || ($_SESSION['cnp'] == '') ||($_SESSION['email'] == '') || ($_SESSION['telefon'] == '') || ($_SESSION['adresa'] == '') || ($_SESSION['oras'] == '')) { echo '<html> <head></head> <body text="#1A1A8C"> Eroare! <center>Nu ai introdus date in formular sau cele introduse nu sunt corecte. Apasa <a href="inregistrare.php">aici</a> pentru a te intoarce la pagina anterioara.</center> </body> </html>'; } else { echo '<html> <head></head> <body text="#1A1A8C"> 
Pagina 85 din 97
<center>Va multumim. Datele au fost introduse cu succes in baza de date. Pentru </body> </html>'; $cerereSQL = "INSERT INTO ùtilizatori` (ùtilizator`, `parola`, `nume`, `prenume`, `cnp`, èmail`, `telefon`, `varsta`, àdresa`, `sector`, `cod_postal`, òras`, `judet`) VALUES ('".addentities($_SESSION['user'])."', ' " .md5($_SESSION['parola1'])." ', '".addentities($_SESSION['nume'])."', '".addentities($_SESSION['prenume'])."', '".addentities($_SESSION['cnp'])."', '".addentities($_SESSION['email'])."', '".addentities($_SESSION['telefon'])."', '".addentities($_SESSION['varsta'])."', '".addentities($_SESSION['adresa'])."', '".addentities($_SESSION['sector'])."', '".addentities($_SESSION['cod_postal'])."', '".addentities($_SESSION['oras'])."', '".addentities($_SESSION['judet'])."')"; mysql_query($cerereSQL); Autentificare.php Odat ce contul de utilizare a fost creat utilizatorul trebuie sa se autentifice pentru a avea acces la paginile de administrare a contului personal, pentru a putea face comenzi. n acest script se verific existena numelui de utilizator n baza de date i corectitudinea parolei, i n caz de eroare, aceasta se semnaleaz. Autentificarea se realizeaz prin intermediul sesiunilor, reinndu-se pentru fiecare utilizator o instan unic de sesiune. $_SESSION['user'] = $_POST['user']; if(($_POST['user'] == '') || ($_POST['parola'] == '')) { echo '<html> <head></head> <body text="#1A1A8C"> <center>Pentru a va accesa contul trebuie sa completati casutele. 
Pagina 86 din 97
va
autentifica
apasati
<a
href=
"autentificare.php">
aici
</a>.</center>
Apasati <a href="autentificare.php">aici</a> pentru a va intoarce la pagina precedenta. </center> </body> </html>'; } else { $cerereSQL = "SELECT * FROM ùtilizatori` WHERE utilizator=' ".htmlentities($_POST['user'])."' AND parola=' ". md5($_POST['parola'])."'"; $rezultat = mysql_query($cerereSQL); if(mysql_num_rows($rezultat) == 1) { while($rand = mysql_fetch_array($rezultat)) { $_SESSION['logat'] = 'Da'; echo '<META HTTP-EQUIV=Refresh CONTENT="0; URL=pagina.php">'; } } else { echo '<html> <head></head> <body text="#1A1A8C"> Eroare! <center> Date incorecte. Apasati <a href="autentificare.php">aici</a> pentru a va intoarce la pagina precedenta. </center> </body> </html>'; Pagina.php
Pagina 87 din 97
Dup ce utilizatorul s-a autentificat se deschide pagina de administrare a contului de utilizare. n acest script utilizatorul are la dispoziie mai multe opiuni: modificarea datelor personale, modificarea parolei, sunt afiate toate comenzile trimise de ctre utilizator, i poate accesa unul din link-urile care duc ctre paginile de prezentare a produselor, afiare a statisticilor vnzrilor, afiare a coului de cumprturi sau pentru ieirea din cont. Vezimagazin.php n acest script sunt prezentate toate categoriile i toate produsele existente n baza de date. La deschiderea paginii apare o list de link-uri cu toate categoriile de produse, iar dac utilizatorul selecteaz o categorie se vor afia toate produsele din acea categorie, pentru fiecare dintre acestea afindu-se numele, preul i o mic imagine de prezentare. $get_cats = "select cat_id, nume_cat, desc_cat from categorii order by nume_cat"; $get_cats_res = mysql_query($get_cats) or die(mysql_error()) ; if (mysql_num_rows($get_cats_res)<1) { $display_block = " Nu exista categorii de vizualizat "; } else { while($cats = mysql_fetch_array($get_cats_res)){ $cat_id = $cats[cat_id]; $cat_title = strtoupper(stripslashes($cats[nume_cat])); $cat_desc = stripslashes($cats[desc_cat]); $display_block .= " <a href=\"$_SERVER[PHP_SELF]?cat_id= $cat_id\"> $cat_title </a> $cat_desc "; if ($_GET[cat_id] == $cat_id) { $get_items = "select item_id, nume_item, pret, imagine from itemi where cat_id=$cat_id order by nume_item"; $get_items_res = mysql_query($get_items) or die(mysql_error()); if (mysql_num_rows($get_items_res) <1) { $display_block = " Nu exista produse in aceasta categorie "; } else { $display_block .= "<ul>"; while($items = mysql_fetch_array($get_items_res)) {
Pagina 88 din 97
$item_id = $items[item_id]; $item_title = stripslashes($items[nume_item]); $item_price = $items[pret]; $item_image = $items[imagine]; $display_block .= " <li> <table border=1 width=50%> <tr> <th><a href=\"showitem.php?item_id=$item_id\"> $item_title</a></th> </tr> <tr> <th height=180 width=180><img src=\"$item_image\" alt=\"poza\" border=0></th> </tr> <tr> <th>$item_price RON (Pretul contine TVA)</th> </tr> <tr> <th><a href=\"showitem.php?item_id=$item_id\"> Cumpara acest produs</a></th> </tr> </table> "; } $display_block .= "</ul>"; } } } } Arataprodus.php Pagina de afiare a produselor nu face dect sa afieze toate informaiile referitoare la cte un produs. Aceste informaii sunt introduse automat ntr-un formular. n acest formular utilizatorul mai poate s aleag numrul produselor pe care dorete s le comande i apoi dac dorete s-l adauge la co trebuie s apese pe butonul Adaug la co. Aratacos.php
Pagina 89 din 97
n aceast pagin este prezentat coninutul coului de cumprturi. Produsele existente n co sunt afiate ntr-un tabel, pentru fiecare fiind afiate numele, productorul, modelul, preul, cantitatea, preul total i un link pentru scoaterea produsului respectiv din co. Pe pagin mai sunt prezente valoarea total a produselor adugate n co i link-urile ctre pagina de afiare a produselor i ctre pagina de comand. Comanda.php Pagina de comand conine un formular n care sunt afiate numele, prenumele, CNPul utilizatorului, adresa, oraul, judeul, aceste cmpuri putnd fi modificate n cazul n care utilizatorul dorete livrarea comenzii la o alt adresa dect cea din cont i valoarea total a comenzii. La apsarea butonului Trimite comanda se insereaz n tabela comenzi datele despre comand, iar n tabela itemi_comanda se insereaz produsele comandate. Dup inserarea datelor n tabele se creeaz fiierul comenzi.xml n care sunt stocate toate comenzile din tabel. if(!isset($_POST['adresa'])) $_SESSION['adresa'] = ''; else $_SESSION['adresa'] = $_POST['adresa']; if(!isset($_POST['sector'])) $_SESSION['sector'] = ''; else $_SESSION['sector'] = $_POST['sector']; if(!isset($_POST['cod_postal'])) $_SESSION['cod_postal'] = ''; else $_SESSION['cod_postal'] = $_POST['cod_postal']; if(!isset($_POST['oras'])) $_SESSION['oras'] = ''; else $_SESSION['oras'] = $_POST['oras']; if(!isset($_POST['judet'])) $_SESSION['judet'] = ''; else $_SESSION['judet'] = $_POST['judet']; if(($_SESSION['adresa'] == '') || ($_SESSION['oras'] == '')) { echo '<html> <head></head> <body text="#1A1A8C"> <center><h4>Nu ai introdus noua adresa de livrare sau orasul. Apasa </body>
Pagina 90 din 97
<a
href="comanda.php">aici</a>
pentru
te
intoarce
la
pagina
anterioara.</h4></center>
</html>'; } else { echo '<html> <head></head> <body text="#1A1A8C"> <center><h4>Va multumim. Comanda a fost trimisa cu succes. Inapoi la magazin <a href="seestore.php">aici</a>.</h4></center> </body> </html>'; $cerereSQL = "INSERT INTO `comenzi` (`data_c`, `nume_c`, àdresa`, òras`, `cod_postal`, `judet`, `sector`, `valoare`, `mod_plata`, `status`) VALUES (now(), '".addentities($_SESSION['user'])."', '".addentities($_SESSION['adresa'])."', '".addentities($_SESSION['oras'])."', '".addentities($_SESSION['cod_postal'])."', '".addentities($_SESSION['judet'])."', '".addentities($_SESSION['sector'])."', '".addentities($_SESSION['afis_price_prod'])."', '".$_POST['plata']."', 'asteptare' )"; mysql_query($cerereSQL); $cid=mysql_insert_id(); $cerereSQL1 = "SELECT cos.id_sesiune, cos.id_item_v, cos.cant, cos.producator, cos.model, itemi.item_id, itemi.pret FROM cos left join itemi on cos.id_item_v = itemi.item_id WHERE id_sesiune ='$_SESSION[user]'"; $rezultat1 = mysql_query($cerereSQL1); while($rand1 = mysql_fetch_array($rezultat1)) { $cidit=$rand1['id_item_v']; $ccant=$rand1['cant']; $cproducator=$rand1['producator']; $cmodel=$rand1['model']; $cpret=$rand1['pret'];
Pagina 91 din 97
$cerereSQL
"insert
into
itemi_comanda
id_comanda,
id_item,
cant,
producator,model, pret ) values ( '$cid', '$cidit', '$ccant', '$cproducator', '$cmodel', '$cpret' )"; mysql_query($cerereSQL); } $cerereSQL2 = "delete from cos where id_sesiune='$_SESSION[user]'"; mysql_query($cerereSQL2) or die(mysql_error()); }
5.6 Manual de utilizare Aceast seciune are drept scop prezentarea modului de interacionare al utilizatorului cu aplicaia. La accesarea site-ului se va deschide pagina principal unde utilizatorul are doua posibiliti: Dac are un cont creat va accesa link-iul care trimite la pagina de autentificare. n cazul n care nu are un cont trebuie s acceseze link-ul de nregistrare care va deschide o pagina ce conine un formular de nscriere. De asemenea pe aceasta pagina, ca de altfel pe toate paginile aplicaiei, exist mai multe seciuni: 1. Un meniu cu urmtoarele link-uri: Home face legtura cu pagina principal Contul meu deschide pagina de administrare a contului personal Produse sunt afiate categoriile i produsele existente n baza de date Coul de cumprturi conine produsele adugate n co de ctre utilizator Statistici vnzri sunt prezentate vnzrile totale i pe categorii n termen de o sptmna i o lun, precum i cel mai bine vndute produse din fiecare categorie i categoria cu cele mai mari vnzri Contact sunt prezentate opiunile de a lua legtura cu sediul societii Termeni i condiii conine drepturile i obligaiile utilizatorilor si societii Ieire din cont dezautentificarea utilizatorului 2. O seciune de cutare unde utilizatorul poate s introduc unul sau mai multe cuvinte ce vor fi cutate n baza de date 3. O seciune n care sunt afiate toate categoriile de produse
Pagina 92 din 97
4. O seciune ce conine un top ale celor mai vndute cinci produse din magazin Pentru crearea unui cont trebuie accesat link-ul de nregistrare i se va deschide o pagina cu un formular de nscriere. Apoi utilizatorul va completa datele cerute i va apsa butonul nregistreaz. Astfel se va crea un cont i se va confirma nregistrarea contului, afindu-se i un link ctre pagina de autentificare. n cazul n care nu mai dorete nscrierea va apsa butonul Reseteaz pentru a terge toate informaiile introduse. La pagina de autentificare utilizatorul trebuie s introduc numele de utilizator i parola. Dup aceasta trebuie s apese butonul Login i se va deschide pagina Contul meu unde utilizatorul va putea modifica datele personale sau parola, va putea vizualiza
produ sele, coul de cumprturi i va vizualiza comenzile efectuate de el anterior.
Pagina 93 din 97
n pagina de prezentare a produselor sunt afiate toate categoriile i toate produsele existente n magazin. Pe pagin apare o list de link-uri cu toate categoriile de produse. La selectarea unei categorii se vor afia toate produsele din acea categorie, pentru fiecare dintre acestea afindu-se numele, preul i o mic imagine de prezentare. Pentru a vizualiza un produs se apas fie pe numele produsului fie pe link-ul Cumpr acest produs i se va deschide pagina de prezentare a produselor care afieaz toate informaiile referitoare la cte un produs. Utilizatorul mai poate s aleag numrul produselor pe care dorete s le comande i apoi dac dorete s-l adauge la co trebuie s apese pe butonul Adaug la co.
Pagina 94 din 97
pagina de vizualizare a coului de cumprturi este prezentat coninutul acestuia.
Produsele existente n co sunt afiate ntr-un tabel, pentru fiecare fiind afiate numele, productorul, modelul, preul, cantitatea, preul total i un link pentru scoaterea produsului respectiv din co. Pe pagin mai sunt afiate valoarea total a produselor adugate n co i link-urile ctre pagina de afiare a produselor i ctre pagina de comand. Pentru a comanda produsele din cont se apas butonul de comanda i se va deschide pagina de comand n care sunt afiate numele, prenumele, CNP-ul utilizatorului, adresa, oraul, judeul, aceste cmpuri putnd fi modificate de ctre utilizator dac acesta dorete livrarea la alt adres i valoarea total a comenzii i apoi va apsa pe butonul Trimite Comanda dup care utilizatorul va primi confirmarea nregistrrii comenzii.
Pagina 95 din 97
5.7 Concluzii Odat cu nceputurile Internetului un nou tip de afacere s-a profilat din ce n ce mai pronunat pe plan internaional: comerul online. Au aprut nenumrate site-uri i firme care se ocup cu vnzrile en-gros de produse prin Internet, cu furnizarea accesului contracost la pagini cu informaii, ntr-un cuvnt abordeaz o form sau alta de comer electronic, un domeniu aflat n plin expansiune. Avantajul comerului online este evident: piaa pe Internet crete exponenial de la un an la altul. Un site bine lucrat, cunoscut i care ofer produse de calitate la preuri bune va avea mai muli vizitatori, mai motivai i mai nzestrai financiar dect multe magazine convenionale. Avnd n vedere proiectarea, implementarea i testarea acestui tip de aplicaii resursele de hardware, software, de timp, cele umane i cele materiale sunt reduse, i n acelai timp aceast aplicaie are un potenial mare de succes. Aplicaia ElectronX are ca scop prezentarea unui model de magazin virtual care s conin funcionalitile de baz specifice unei aplicaii de acest gen: gestionarea conturilor unui utilizator, prezentarea categoriilor i produselor, cutarea n baza de date, adugarea produselor ntr-un co de cumprturi, trimiterea comenzilor. Aceste funcionaliti pot fi mbuntite i de asemenea pot fi adugate i altele att la nivelul aspectului interfeei ct i la nivelul operaiilor ce pot fi efectuate astfel nct s asigure o funcionare optim a site-ului.
Pagina 96 din 97
Dezvoltarea fr precedent din ultimele dou decenii a tehnologiilor informaionale determinate de necesitatea stocrii i a transmiterii rapide a informaiilor cu cele mai mici costuri, a revoluionat comerul global, comerul direct sau cu amnuntul.
Pagina 97 din 97

Utilizarea XML in Baze de Date

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Utilizarea XML in Baze de Date

Încărcat de

Drepturi de autor:

Formate disponibile

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