. Aplicatii ale Xml In Baze de Date

. Aplicatii ale Xml In Baze de Date

Byadmin ianuarie 1, 2024

INTRODUCERE

Formatul de date XML devine formatul comun acceptat în industrie pentru schimbul de informații dintre diverse sisteme eterogene. Din acest motiv, este important ca o bază de date să fie capabilă să stocheze informațiile nu doar în formatele tradiționale, relaționale, ci și în format XML. Stocând datele XML în format nativ se câștigă foarte mult în performanță, aceasta materializându-se în costuri reduse. Un plus de performanță la o tehnologie de baze de date înseamnă o infrastructură redusă, servere cu mai puține procesoare, deci un sistem informatic ceva mai ieftin, costuri mai mici pentru licențiere, deci per total o economie de bani.

Standardul industrial al datelor în format XML prezintă o serie de avantaje și dezavantaje. Avantajul major este acela că este adoptat de toți producătorii de tehnologie din industrie, dar în schimb are dezavantajul că este un format nu foarte eficient din punct de vedere al stocării datelor. De aceea devine foarte util ca baza care stochează aceste date sa aibă capabilități de compresie, care să ducă la scăderea spațiului și resurselor de stocare necesare pentru a păstra date în format XML.

Lucrarea de față își propune să prezinte în capitolele sale câteva noi direcții de dezvoltare în domeniul bazelor de date, modelul de date semistructurat și tehnologia XML ca o nouă bază de date.

Capitolul I prezintă necesitatea apariției modelului semistructurat al datelor, datorită nevoii de interogare a unor surse de date care nu au o schemă predefinită sau a unor date care provin din surse diferite și au scheme diferite. Modelul semistructurat al datelor reprezintă schema (tipul, structura) și instanța (valoarea) datelor în mod uniform, permițând interogarea lor simultană spre deosebire de modelele de date convenționale, care diferențiază între cele două tipuri de informație.

Capitolul II detaliază modelul semistructurat al datelor definind conceptul de date neconvenționale din mai multe perspective și pe cel de date semistructurate prezentând avantajele acestui tip de date, modelarea acestor date și limbajele de interogare a acestora, și prezintă în detaliu tipul de date MPEG-21 ca suport pentru integrarea datelor în aplicații multimedia distribuite.

Capitolul III prezintă legătura dintre tehnologia XML și bazele de date încercând să clarifice în ce măsură este XML-ul o bază de date, reprezentarea datelor și documentelor, stocarea și recuperarea datelor, stocarea datelor în baze de date native XML, generarea schemelor XML din scheme relaționale și invers, stocarea documentelor în sistemul de fișiere și în BLOB-uri, detaliază bazele de date native XML, și prezintă noțiunile de DOM (Document Object Model) persistent și sisteme de management ale conținuturilor.

Capitolul IV se ocupă de construirea documentelor XML prezentând sintaxa XML, descrierea de vocabulare noi cu XML, avantajele definiției tipurilor documentului, combaterea dezavantajelor definiției tipurilor documentului, definirea unui document XML ca întreg, declarația XML, documentele autonome, construirea unui document XML, declarația tipului documentului și prezintă câteva aplicații din lumea reală a declarației tipului documentului.

Capitolul V constă în prezentarea aplicației – magazinul virtual „ElectronX” – și prezintă scopul acestei aplicații, cerințele minime hardware și software ale aplicației, funcționalitățile de bază ale acestui website, proiectarea bazei de date conținând schema conceptuală a structurii bazei și schema fizică a fiecărei tabele, implementarea codului în care sunt explicate fișierele cele mai importante ale aplicației cu exemplificări din codul sursă, un manual de utilizare al aplicației în care e descris modul de funcționare al acesteia și concluzii asupra aplicației.

CAPITOLUL I

NOI MODELE DE DATE ȘI APLICAȚIILE LOR

1.1 Interogarea World-Wide-Web-ului

Există surse de date, ca de pildă World-Wide-Web-ul, pe care am dori să le interogăm ca baze de date, dar care nu pot fi constrânse de o schemă. Majoritatea interogărilor web-ului folosesc tehnici de regăsire a informației pentru a găsi pagini după conținut. Există însă puține posibilități de formulare a interogărilor în vederea exploatării structurii web-ului și, deoarece aceasta nu este conformă cu nici un model de date standard, este necesară o metodă de descriere a acestei structuri.

Modelul de date semistructurat a fost propus în vederea satisfacerii acestei necesități. Ideea centrală în modelul semistructurat este de a reprezenta datele sub forma unui graf etichetat. Structura documentelor hipertext este capturată interpretând arcele grafului drept legături. O reprezentare posibilă este cea introdusă în proiectul UnQL[1]. Etichetele arcurilor pot fi atât valori (de tip întreg, șir de caractere și alte tipuri de bază, precum și de tip de date abstract, ca video, audio, etc.) cât și nume de atribute (Film, Titlu, Regizor, Actor), etc. modelând de exemplu cunoscuta bază de date cinematografică IMDB [2].

Există numeroase limbaje de interogare pentru modelul semistructurat. Toate aceste limbaje sunt construite pe baza ideii de expresii asociate căilor (path expressions). Acestea sunt expresii regulate ce exprimă căi generice în graful etichetat, permițând astfel traversarea grafului și colecționarea tuturor etichetelor ce satisfac o anumită condiție de selecție.

Limbajele semistructurate pot fi clasificate în două categorii, după strategia de calcul adoptată. Prima categorie, dezvoltată oarecum ad-hoc, se bazează pe modelarea grafurilor în modelul relațional și apoi pe interogarea lor într-un limbaj relațional de tip SQL. Câteva exemple prezentate în literatură sunt [3], [4], [5], [6], [7]

A doua categorie pornește de la un limbaj bazat pe o noțiune formală de calcul cu date semistructurate: limbajul UnQL este reprezentantul acestei categorii [1]. Acest limbaj pornește de la recursivitatea structurală, forma naturală de recursivitate asociată cu tipul de date grafuri etichetate. Datorită bazei sale teoretice, UnQL este capabil de restructurări complexe, în adâncime, spre deosebire de limbajele din prima categorie, care se limitează la scoaterea la suprafață a datelor din graf, fără însă a crea noi structuri.

Această capacitate de restructurare stă la baza proiectului STRUDEL[8] care propune limbajul StruQL de gestiune a sit-urilor de web. Un alt avantaj al bazei teoretice a limbajelor UnQL și StruQL este posibilitatea efectuării optimizărilor specifice acestui nou model de date. Limbajele din prima categorie pot beneficia doar de optimizările specifice modelului relațional, deci dezvoltate pentru alt model de date și în consecință nu atât de folositoare.

1.2 Integrarea surselor de date eterogene

Integrarea datelor provenind din surse eterogene (cu scheme disparate sau, mai grav, modelate diferit), este un domeniu de cercetare care, deși consacrat de mai bine de un deceniu, continuă să rămână în centrul atenției multor cercetători. Cercetarea în acest domeniu este motivată de absența unui model de date atotcuprinzător, fapt ce îngreunează dezvoltarea de software care convertește date între două modele diferite.

O complicație adițională este reprezentată de faptul că majoritatea datelor stocate electronic nu se află în baze de date convenționale, ci în sisteme de fișiere, programe de bibliotecă, de poștă electronică, foi de calcul etc., care prezintă capacități de interogare limitate.

Ultima observație a reprezentat punctul de plecare al proiectului Tsimmis [9][10] de la Stanford. Proiectul Tsimmis își propune integrarea atât a surselor de date care sunt conforme cu modelele de date standard (relațional, orientat pe obiecte), cât și a surselor de date cu capacități de interogare limitate. Aceste surse neconvenționale sunt împachetate în așa-numiți wrappers (ambalaje). Un astfel de ambalaj asigură interfața între sursa de date cu capacități de interogare limitate și aplicația care o interoghează. Aplicația trimite către sursă interogări într-un limbaj expresiv cum ar fi SQL sau OQL și așteaptă rezultatul într-un format numit OEM (Object Exchange Model).

OEM folosește grafuri etichetate, ca structură de date, care capturează majoritatea datelor folosite în aplicații de baze de date. În același timp, toate celelalte structuri de date pot fi codificate ca grafuri OEM.

Rolul ambalajului constă în: interceptarea interogării și identificarea acelor părți ale acesteia care pot fi efectuate de către sursă, translatarea acestor părți în limbajul specific sursei, recepționarea și prelucrarea rezultatelor intermediare în vederea reconstituirii rezultatului interogării originale, codificarea rezultatului final în formatul OEM și transmiterea acestuia către aplicație.

Evident, dacă interogarea originală este prea complexă, este posibil să nu poată fi efectuată pornind de la capabilitățile limitate ale sursei. Ambalajul detectează această situație și anunță sursa că nu îi poate satisface cererea. Cu cât crește capacitatea de evaluare a interogărilor în cadrul ambalajului (de exemplu, capacitatea de a efectua operații de tip join, proiecții, selecții, etc.), cu atât se extinde clasa de interogări pe care le poate satisface combinația sursă-ambalaj.

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

Se remarcă similaritatea dintre modelul OEM și cel semistructurat. Într-adevăr, Lore [11],[12] este un sistem de interogare a datelor semistructurate, foarte similar cu UnQL, utilizând un model de date inspirat de OEM.

1.3 Navigare în Internet

În anumite situații este avantajos să privim bazele de date convenționale ca fiind semistructurate. Un exemplu este activitatea de navigare în Internet.

În general, utilizatorul nu poate interoga o bază de date fără a-i cunoaște schema. Din nefericire însă, aceasta este adeseori greu de înțeles, datorită mărimii exagerate (zeci de tabele, de exemplu) și a terminologiei opace, nestandard, folosite de către proiectanții bazei de date.

Descifrarea schemei ar fi considerabil ușurată de facilitatea de a interoga datele având doar o înțelegere parțială a structurii lor. De exemplu, în cazul bazei de date cinematografice din World-Wide Web[2], următoarele interogări ar fi de folos:

În care atribut găsim șirul de caractere Casablanca?
Există în baza de date întregi mai mari decât 216?
Ce obiecte din baza de date au un atribut al cărui nume începe cu act?

Și în acest domeniu, modelul semistructurat se dovedește a fi folositor. Spre deosebire de modelele de date convenționale, care diferențiază între schema (tipul, structura) și instanța (valoarea) datelor, modelul de date semistructurat reprezintă cele două tipuri de informație în mod uniform, permițând interogarea lor simultană. Din acest motiv, datele semi-structurate se numesc și autodescriptive.

[1] prezintă un elegant limbaj de interogare care permite exprimarea concisă a acestor interogări.

1.4 Cubul de date și OLAP

Sistemele de suport pentru decizii (Decision support systems) sunt utilizate de către companiile moderne pentru integrarea într-o bază de date centrală numită data warehouse (magazia centrală de date), a datelor provenind din baze de date mici operaționale folosite în diferite domenii de activitate/filiale ale companiei.

Datele astfel acumulate sunt analizate în timp real (OLAP: On-Line Analitical Processing) pentru a asista conducerea companiei în luarea deciziilor strategice de dezvoltare [14] (de exemplu, analizând vânzările unui anumit produs pe trimestru și zonă geografică, se poate stabili o nouă strategie de marketing pentru acest produs). Datele din magazia centrală de date sunt modelate sub forma unui (hiper)cub de date multidimensional [15]) care poate fi analizat la nivelul subcuburilor de granularitate arbitrară. Subcuburile se obțin prin agregarea cuburilor din care provin.

De exemplu, prin însumarea vânzărilor trimestriale pentru fiecare zonă, cubul de date tridimensional reprezentând vânzările pe trimestru și zona geograând vânzările pe trimestru și zona geografică poate fi redus la un subcub bidimensional (plan) reprezentând vânzările pe zona geografică. Agregarea este o operație costisitoare, efectuarea ei eficientă pe un volum mare de date reprezentând țelul principal al cercetării în acest domeniu ([16],[17],[18],[19]).

1.5 Noi modele tranzacționale

În mod tradițional, tranzacțiile modelează unități de lucru atomice și izolate, efectuate asupra datelor sistemului de gestiune a bazelor de date.

Izolarea tranzacțiilor nu permite crearea tranzacțiilor complexe, mari, din tranzacții simple. Acest model a avut succes atâta vreme cât tranzacțiile efectuau un număr mic de operații simple asupra datelor cu structură simplă.

Din păcate, modelul tranzacțiilor simple nu satisface cerințele aplicațiilor complexe, în care tranzacțiile trebuiesc combinate și coordonate pentru a colabora la realizarea unui scop complex. Aplicații ca proiectarea asistată de calculator, automatizarea activității de birou, controlul producției, gestiunea activităților necesită noi modele tranzacționale, noi metode de gestiune a tranzacțiilor, și noi limbaje de specificare a tranzacțiilor. Limbajele tranzacționale sunt limbaje de nivel înalt, de obicei inspirate din logica cu predicate de ordinul întâi.

Dacă limbajele tradiționale specificau interogări și actualizări, noile limbaje tranzacționale se concentrează asupra relației dintre tranzacții, exprimând dependențe de tipul tranzacția T2 nu poate porni înainte ca T1 să se termine, sau T2 poate începe dacă T1 întoarce o valoare mai mare ca 25. [20] prezintă o clasificare și analiza detailată a noilor limbaje tranzacționale.

Un excelent exponent al noii generații de limbaje tranzacționale este Transaction Datalog [21], un limbaj deductiv care menține în același timp toate proprietățile tranzacțiilor clasice, cum ar fi: persistență, atomicitate, izolare, terminare și rollback (revenire).

Limbajul este însoțit de un model teoretic natural și de o teorie sigură pentru demonstrații, permițând astfel demonstrarea echivalenței între diverse expresii din acest limbaj. Acest fapt este crucial pentru optimizare – care constă din înlocuirea unei planificări cu o alta echivalentă din punct de vedere al efectului său asupra datelor, dar mai eficientă din punct de vedere al costului execuției. Mai mult, faptul că putem demonstra că efectul unei tranzacții complexe asupra setului de date este sau nu cel scontat, asigură consistența datelor.

1.6 Optimizări

Optimizarea limbajelor de interogare a bazelor de date nu este un domeniu nou, ci dimpotrivă, există încă de la apariția acestora. Datorită importanței sale, acest domeniu va fi întotdeauna la modă în cercetarea bazelor de date.

Apariția unui nou model de date atrage după sine o efervescență în activitatea de cercetare a posibilităților de optimizare a limbajului de interogare asociat noului model. Referințele bibliografice introduse în secțiunea anterioară prezintă și primele încercări de optimizare a noilor limbaje de interogare.

CAPITOLUL II

MODELE DE REPREZENTARE A DATELOR NECONVENȚIONALE

2.1 Definirea conceptului de date neconvenționale

În literatura de specialitate există o serie de definiri ale conceptului de date neconvenționale și a altor concepte asociate acestuia:

• Datele neconvenționale sunt datele care nu au nici unul din tipurile standard: întreg, real etc. [Blanken, 2002]

• Structura de date neconvențională este structura de date care nu este în uzul curent al aplicațiilor; aceasta poate fi structura produsă de datele semistructurate, cea definită noilor tipuri de date folosite în aplicații și date cu structuri ce se modifică în mod dinamic. [GSIHT, 2005]

• A patra generație a tehnologiilor bazelor de date este prezentată în [Mannino, 2004] ca fiind o extensie a tehnologiilor bazelor de date cu datele neconvenționale și Internetul. Sistemele celei de-a patra generații pot stoca și manipula tipuri de date neconvenționale cum sunt: imaginile, secvențele video, hărțile, sunetele și animațiile și permit accesul la bazele de date Web.

• Unul din obiectivele sistemelor de gestiune a bazelor de date orientate obiect este prezentat ca fiind extinderea flexibilității cu datele neconvenționale și procedurile de prelucrare asociate acestora, inclusiv text, grafică și voce, date care nu pot fi manipulate și integrate de sistemele de baze de date convenționale.

La University of Southern California din Los Angeles (USC) există un laborator de informare numit InfoLAB al cărui scop este investigarea de noi metode pentru gestiunea tipurilor de date neconvenționale cu arhitecturi atipice. Principalele zone de cercetare sunt:

• Gestiunea fluxurilor de date multidimensionale în arhitecturi de tip punct la punct (peer-to-peer),

• Analiza datelor multidimensionale,

• Gestiunea datelor peer-to-peer,

• Prelucrarea interogărilor de stream-uri,

• Baze de date spațio-temporale.

Descrierea datelor neconvenționale se realizează folosind metadate. Metadatele sunt folosite pentru descrierea altor date, cu o structură complexă sau nestructurate. Metadatele pot fi privite din diferite perspective, în funcție de producătorul sau sursa metadatelor:

– Din perspectiva producătorului de conținut, metadatele sunt utilizate pentru stocarea informațiilor bibliografice ale resurselor, ca de exemplu: numele autorului, titlul, data creării, formatul resursei etc.

– Din perspectiva furnizorilor de servicii, metadatele oferă informații descriptive cu valoare adăugată (majoritatea în format XML), care reduc informațiile necesare regăsirii datelor. Metadatele conțin informații despre diferitele formate în care este disponibilă o resursă și informații semantice asociate acesteia. Aceste informații sunt utile pentru realizarea interogării datelor.

– Din perspectiva consumatorului, metadatele oferă informații suplimentare care descriu preferințele consumatorului și resursele disponibile pentru utilizarea datelor. Metadatele permit personalizarea consumului mediilor și trebuie luate în considerare de producători. Metadatele sunt utile pentru distribuirea datelor în Internet sau în rețele mobile permițând accesul la resurse în cele mai bune condiții posibile; de exemplu, metadatele pot fi folosite pentru descrierea modului în care difuzarea secvențelor video este adaptată la scăderea lărgimii de bandă disponibilă la un moment dat.

2.2 Modelul semistructurat ale datelor

Modelele relațional și orientat-obiect au fost folosite mult timp pentru modelarea datelor nu neapărat pentru că erau cele mai naturale soluții, ci pentru că au în spate un formalism bine definit. În timp însă, datorită dezvoltării Internetului și datorită necesității integrării datelor descrise folosind scheme diferite, modelele tradiționale s-au dovedit a nu mai fi suficiente și a devenit acută necesitatea utilizării unui alt model de date, modelul semistructurat al datelor.

În plus, aplicațiile Internet realizează operații care nu sunt curente în aplicațiile tradiționale cu baze de date cum ar fi: transformări ale datelor, interpretarea interogărilor, transportul datelor și prelucrarea bazată pe fluxuri.

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

În primul rând, există surse de date pe care am vrea să le tratăm ca baze de date dar cărora nu le putem impune constrângeri având la bază o schemă, ca în cazul bazelor de date tradiționale [Buneman, 1997]. Chiar și datele structurate, au structură care poate să difere de la o aplicație la alta sau au structură modificabilă în timp. Dezvoltările din domeniul multimediei au dus la necesitatea de a introduce noi tipuri de date în domeniul tehnologiei bazelor de date convenționale. Unele tehnologii necesită doar extensii ale modelelor de date existente, prin optimizarea tehnicilor de manipulare și interogare a noilor tipuri de date, dar altele nu pot fi încadrate în modelele clasice de gestiune a datelor. Cel mai evident exemplu de date care nu pot fi încadrate într-o schemă sunt datele manipulate prin intermediul Web-ului. Majoritatea interogărilor Web exploatează tehnicile de regăsire a datelor pentru a determina paginile individuale care au conținut ce corespunde criteriului solicitat. Dar numai o mică parte din resursele Web sunt structurate astfel încât să permită rezolvarea interogărilor, Web-ul nefiind conform nici unui model standard. Astfel că se simte nevoia de a găsi o metodă pentru descrierea structurii datelor Web în vederea rezolvării acestei probleme.

Al doilea motiv este dat de necesitatea schimbului de date între aplicații care folosesc formate diferite de stocare și gestiune a datelor necesitând astfel transformarea datelor. Nici unul din modelele de date existente nu este acceptabil din toate punctele de vedere și în plus este dificil să convertim datele dintr-un model în altul. Astfel, s-a simțit nevoia să se dezvolte un model care să lege cele două lumi diferite: relațională și orientată obiect, acesta este modelul semistructurat al datelor.

În plus, datele în format electronic se află în medii diferite, interconectate care trebuie să comunice între ele. Dar și când se folosesc datele structurate poate fi util ca acestea să fie privite ca date semistructurate, din motive care țin de manipularea acestora, fiind util să existe un format flexibil pentru schimbul de date între diferite tipuri de baze de date. [Buneman, 1997]

O parte din aceste date se găsesc sub forma datelor nestructurate, ca de exemplu sunetele, imaginile, secvențele video și chiar unele documente text, iar altă parte sub forma datelor structurate, memorate în baze de date relaționale sau orientate obiect. În general, un utilizator nu poate scrie o interogare pentru o bază de date fără să cunoască schema de organizare a datelor, iar aceasta este netransparentă pentru utilizatori și raționamentul folosit la proiectarea ei este adesea greu de determinat. Au fost dezvoltate limbaje care permit interogarea simultană a datelor și a schemelor de organizare a bazelor de date, dar aceste limbaje nu au flexibilitatea să manipuleze constrângeri complexe.

2.2.1 Conceptul de date semistructurate

În general, prin termenul de date semistructurate sunt denumite datele care nu respectă formate stricte cum ar fi cele impuse de modelele bazelor de date relaționale sau orientate obiect. În mod evident o astfel de definiție este imprecisă. Datele sunt semistructurate dacă: nu au o structură rigidă (de exemplu datele Web, datele sunt combinate din câteva surse eterogene – ca în cazul depozitelor de date), nu au o structură implicită asociată datelor, sau au o structură parțial specificată [Abiteboul, 1997]. Modelele orientat-obiect și relațional au o schemă fixă pentru fiecare clasă sau fiecare relație. Datele semistructurate permit o flexibilitate sporită, fiind o combinație a celor două concepte: clasa și relația.

Datele semistructurate conțin informații despre schema lor și această schemă poate diferi, în timp, în cadrul unei singure baze de date. Acest model care nu se bazează pe nici o schemă, are un rol special în sistemele bazelor de date.

În acest model datele sunt autoreferite, acest lucru însemnând că schema este atașată datelor. Combinarea unor date dintr-o bază de date relațională cu altele dintr-o bază de date orientată-obiect se poate realiza prin conectarea celor două baze de date, prin intermediul unei interfețe, translatând datele de la fiecare sursă în date semistructurate.

În modelul semistructurat al datelor, informațiile care sunt în mod normal asociate unei scheme sunt incluse în interiorul datelor. În aceste baze de date nu există o distincție clară între date și schemă, iar gradul de structurare depinde de aplicație. În anumite forme ale modelului semistructurat există o schemă distinctă, în altele nu.

Avantajele modelului semistructurat al datelor sunt următoarele:

• Flexibilitatea – simplifică integrarea bazelor de date care au scheme diferite. Spre deosebire de alte modele, care au o schemă de descriere a datelor, modelul semistructurat este fără schemă, ceea ce justifică flexibilitatea sa. Flexibilitatea reprezintă un instrument util pentru integrarea datelor, mai ales în cazul problemelor legate de moștenirea bazei de date.

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

• Posibilitatea integrării datelor

Documentele HTML și cele stocate în biblioteci digitale sunt semistructurate. Spre deosebire de fluxurile nestructurate de date (precum imagini, sunete, video), datele semistructurate au o structură și spre deosebire de datele structurate (bazele de date relaționale sau orientate-obiect), datele semistructurate nu au o schemă absolută sau o clasă fixă, fiecare obiect conținând propria schemă. Iregularitatea structurală nu implică inexistența similarităților structurale între obiecte. Din contră, în mod obișnuit, obiectele semistructurate care descriu același tip de date au structură similară.

Modelul datelor semistructurate este un model pentru integrarea bazelor de date. Este folosit pentru descrierea datelor aflate în două sau mai multe baze de date care conțin date similare în diferite scheme de organizare.

2.2.2 Modelarea datelor semistructurate

Datele semistructurate sunt modelate, în general, sub forma structurilor de tip graf sau arbore, în noduri având reprezentate obiecte iar arcele reprezentând atributele obiectelor. În plus, arcele modelează natural relațiile de subordonare dintre două obiecte. [Reveiu, 2003]

Modelul de facto pentru datele semistructurate este OEM (Object Exchange Model), model propus în proiectul pentru integrarea datelor numit TSIMMIS și descris pentru prima dată în lucrarea Multimedia database systems – Design and implementation Strategies. OEM este un model autodescriptibil, nefiind necesară definirea anterioară a structurii unui obiect și nici nu există o schemă fixă de reprezentare a datelor. Fiecare obiect reprezentat conține propria lui schemă.

Fiecare obiect din OEM poate avea un identificator (Id), o etichetă, un tip și o valoare. Id-urile obiectelor pot fi simboluri cu sau fără înțelesuri speciale. De exemplu, dacă un obiect este o pagină Web, URL-ul paginii poate fi folosit ca id-ul obiectului. Etichetele nodurilor sunt șiruri care explicitează rolul obiectului pentru utilizator și pentru aplicații. Eticheta joacă aici două roluri: identifică un obiect și dă sens obiectului. Obiectele pot fi atomice sau complexe (seturi de obiecte). Valorile obiectelor atomice au tipuri atomice (valori întregi, reale, șiruri de caractere, imagine, sunet etc.), iar cele complexe au ca valori seturi de obiecte, reprezentate prin perechi de tipul atribut-obiect. Prin urmare, un obiect complex va avea o definire recursivă deoarece valoarea unui obiect este parte a sa. Nodurile frunză au asociate întotdeauna valori atomice.

Etichetele arcelor reprezintă atribute, sunt descrise prin șiruri de caractere și reprezintă un set de proprietăți descriptive. O proprietate poate fi folosită într-un arc pentru a descrie nodurile învecinate.

În figura 1 este prezentată exemplificarea modelării unei părți dintr-o bază de date multimedia folosind OEM.

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

Informații: &o1

{film: &o21

{titlu: &o30 “Titanic”,

actor principal: &o31

{nume: &o41 “DiCaprio”,

prenume: &o42 “Leonadro”},

regizor: &o32

{nume: &44 “Cameron”,

prenume: &o45 “James”},

{ actor principal: &o33,

nume: &o46 “Kate”,

prenume: &o47 “Winslet”},

premii obținute: &o48 “11 Oscaruri”},

melodie: &o22

{titlu: &49 “My heart will go on”,

interpretă: &o34

{nume: &o50 “Dion”,

prenume: &o51 “Celine”},

premii: & o35

{an: &o52 “1998”,

nume: “Oscar pentru cea mai bună coloană sonoră”},

coloană sonoră: &o22}}

Datele stocate în baze de date relaționale pot fi descrise cu ușurință folosind OEM. În plus, OEM asigură o flexibilitate mai mare în descrierea datelor tolerând lipsa unor atribute pentru anumite înregistrări sau existența mai multor valori pentru același atribut în cadrul unei singure înregistrări.

OEM poate fi considerat mai apropiat de modelul orientat-obiect decât de cel relațional, în care două obiecte distincte chiar dacă au valori identice, au existență de sine stătătoare, reprezentând instanțe diferite.

Scheme de organizare a datelor semistructurate

Flexibilitatea în descrierea informațiilor adusă de modelarea datelor semistructurate are și dezavantaje, și anume dificultatea formulării unei interogări relevante. S-a încercat asocierea unor scheme în modelarea datelor semistructurate, în acest sens existând două abordări:

• scheme flexibile – descriu aprioric datele; schemele flexibile fiind concepute astfel încât să permită flexibilitate în descrierea datelor; se folosește tipul void pentru manipularea oricărui tip de dată.

• scheme rigide – descriu cu exactitate datele și sunt folosite pentru analiza datelor; schema este refăcută ori de câte ori se produce o modificare a informației memorate.

2.2.3 Limbaje de interogare a datelor semistructurate

Principalele elemente caracteristice ale unui limbaj de interogare pentru datele semistructurate sunt:

• Putere de expresie: pentru reprezentarea datelor relaționale sub forma datelor semistructurate, limbajul semistructurat trebuie să acopere operațiile corespunzătoare unui limbaj relațional standard, dar în plus trebuie să dispună de facilități de reorganizare a datelor, astfel încât aceeași informație să poată fi regăsită sub o altă structură;

• Semantică: cererile trebuie optimizate astfel încât să poată ține cont de semantica datelor, fiind necesară o semantică precisă pentru transformarea și optimizarea cererilor;

• Schematizare: limbajul trebuie să poată recunoaște structurile definite pentru a le putea manipula;

• Compunere: datele obținute în urma unei interogări pot fi folosite ca date de intrare în alte interogări, motiv pentru care limbajele trebuie să fie transparente.

Au fost propuse, într-o serie de proiecte de cercetare pe această temă, câteva limbaje de interogare pentru datele semistructurate. Două dintre acestea sunt: limbajul orientat-obiect Lorel, derivat din OQL (Object Query Language) și limbajul UnQL (Unstructured Query Language).

Domeniul datelor semistructurate este unul în studiu și va avea un impact mare asupra unei multitudini de aplicații, dar mai ales asupra aplicațiilor multimedia și a celor dezvoltate pentru mediul Internet.

2.3 MPEG-21 – Suport pentru integrarea datelor în aplicații multimedia distribuite

În ciuda descrierilor complete și detaliate ale tipurilor datelor multimedia implementate în MPEG-7, aspecte legate de organizarea datelor și de infrastructura unui sistem multimedia distribuit nu pot fi descrise doar folosind metadate. Astfel că a fost inițiat un nou standard, MPEG-21 cu scopul de a oferi mecanisme de proiectare a sistemelor multimedia distribuite, de a crea un mediu unic, universal accesibil pentru livrarea și utilizarea resurselor multimedia în diferite condiții, ca de exemplu diferite tipuri de utilizatori, rețele cu diferite caracteristici, terminale cu caracteristici diferite etc.

2.3.1 Prezentare generală

MPEG-21 este un standard ISO/IEC21000 al MPEG (Moving Picture Experts Group) care definește un cadru de lucru deschis pentru multimedia. Forța MPEG-21 este dată de următoarea situație: există multe resurse mutimedia ce pot fi folosite la construirea unei infrastructuri pentru distribuirea și utilizarea conținutului multimedia, dar nu există nici o arhitectură pentru descrierea modului în care aceste elemente interacționează între ele. Scopul standardului MPEG-21 este să definească un cadru de lucru deschis pentru multimedia care să permită utilizarea transparentă și la performanțe bune a resurselor multimedia folosind rețele și dispozitive periferice diverse. Se urmărește gestiunea conținutului multimedia, gestiunea proprietății intelectuale și adaptarea conținutului la resursele disponibile prin intermediul diferitelor clase de servicii. MPEG-21 oferă un suport deschis pentru distribuirea și utilizarea datelor multimedia. [Kosch, 2004]

MPEG acoperă întregul conținut multimedia din punctul de vedere al canalelor de distribuție folosite, al modalităților de creare a conținutului, din punct de vedere al modalității de producție, în vederea personalizării, consumului, prezentării și comercializării acestuia. Pentru realizarea acestui lucru, MPEG-21 propune norme pentru un standard deschis pentru crearea, distribuirea și utilizarea datelor multimedia. Acest standard se referă la toți actorii implicați, de la creatorii de conținut, producători, distribuitori și furnizorii de servicii.

MPEG-21 standardizează fluxul informațiilor și serviciilor multimedia de la crearea conținutului până la livrarea către utilizatorii finali. Pentru a realiza acest lucru, conținutul trebuie identificat, descris, gestionat și protejat. Transportul și livrarea conținutului poate avea loc peste diferite rețele, între o varietate de terminale.

Există o serie de arhitecturi apărute ca răspuns la varietatea tipurilor de aplicații care utilizează conținutul multimedia. Există trei modele principale folosite pentru gestiunea, descrierea și regăsirea resurselor multimedia și anume Dublin Core, SMPTE și MPEG-7. Pentru a evita recomandarea unui model în defavoarea altuia, în mod nejustificat, MPEG-21 propune descrierea suportului multimedia sub forma unei arhitecturi generice. [ISO, 2001]

MPEG-21 se bazează pe două concepte esențiale: definirea unei unități fundamentale de distribuție și tranzacționare – elementul digital și utilizatorii care interacționează cu elementele digitale. Elementul digital este un obiect digital, structurat care are o reprezentare standard, ce poate fi identificat și care are asociate metadate. Elementele digitale conțin atât resursele multimedia (conținutul) cât și metadatele asociate resurselor sau întregului element digital. În accepțiunea MPEG-21, utilizatorul este orice entitate care interacționează cu mediul MPEG-21 sau care folosește un element digital, ca de exemplu un consumator al datelor multimedia, o organizație, sau un alt standard ce folosește resursele multimedia. Un utilizator poate folosi conținutul în mai multe feluri: prin publicare sau prin livrare și poate avea drepturi și responsabilități specifice în funcție de modalitățile de interacțiune cu alți utilizatori în cadrul MPEG-21.

Principalele elementele folosite în definirea arhitecturii MPEG-21 sunt:

• Elementul digital – este un container ierarhic de resurse eterogene (video, audio, text etc.), metadate și alte elemente digitale. Un element digital este o unitate elementară de distribuție și tranzacționare;

• Declararea elementului digital – definește un set de termeni folosiți la declararea elementelor digitale;

• Identificarea și descrierea elementului digital – presupune identificarea și descrierea elementului digital, natura lui, tipul sau granularitatea (film, scenă sau cadru);

• Gestiunea și utilizarea conținutului – oferă interfețe și protocoale care permit crearea, manipularea, căutarea, accesarea, stocarea, livrarea și reutilizarea conținutului de-a lungul canalelor de distribuție și consum;

• Protejarea și gestiunea proprietății intelectuale – permite gestiunea conținutului și protejarea elementelor digitale într-o serie de rețele și dispozitive;

• Terminale și rețele – oferă instrumente ce permit accesul transparent la conținut prin intermediul rețelelor și terminalelor, realizând inclusiv controlul calității serviciului;

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

• Raportarea evenimentelor – conține metrici și interfețe ce permit utilizatorilor să evalueze performanțele tuturor evenimentelor raportabile din cadrul sistemului.

Structura MPEG-21

În prezent sunt definite 18 părți ale MPEG-21: [ISO/IEC 21000-1-18] :

Partea 1: Tehnologiile și strategia MPEG-21,

Partea 2: Declararea elementului digital (DID)

Partea 3: Identificarea elementului digital (DII)

Partea 4: Gestiunea și protecția proprietății intelectuale (IPMP)

Partea 5: Limbajul de reprezentare a drepturilor (REL)

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

Partea 7: Adaptarea elementului digital (DIA),

Partea 8: Software de referință

Partea 9: Formate de fișiere pentru stocarea și regăsirea elementelor digitale ale MPEG-21

Partea 10: Prelucrarea elementelor digitale

Partea 11: Asocieri persistente

Partea 12: Testare distribuirii resurselor MPEG-21

Partea 13: Codarea secvențelor video scalabile

Partea 14: Conformanța

Partea 15: Raportarea evenimentelor

Partea 16: Formatul binar

Partea 17: Identificarea fragmentelor

Partea 18: Streaming-ul elementului digital

2.3.2 Declararea elementelor digitale

Declararea elementului digital presupune definirea unui set de termeni și concepte folosite la definirea elementelor digitale, la descrierea sintaxei și semanticii fiecărui element digital și a schemei de reprezentare în XML.

Declararea unui element digital se realizează în 3 etape:

– Crearea modelului abstract,

– Reprezentarea modelului abstract în XML,

– Crearea schemei XML.

• Modelul abstract – definește un set de termeni și concepte care formează un model pentru declararea elementelor digitale. Modelul abstract permite reprezentarea elementelor digitale în diferite moduri. Modelul abstract definește entitățile necesare declarării elementului digital.

Un prim set de entități este format din elementele de bază folosite pentru declararea elementelor digitale:

– resursa – este un flux de date identificabil, ca de exemplu un fișier video, imagine, secvență audio sau text.

– componenta – are rolul de a lega una sau mai multe resurse de un set de descriptori ce conțin informații secundare referitoare la resursele componentei. Componenta este folosită doar pentru gruparea resurselor și a datelor secundare transmise printr-un descriptor.

– elementul digital – reprezintă conectarea unuia sau mai multor elemente sau componente la un descriptor. Se pot crea elemente digitale individuale și elemente compuse.

– descriptorul – introduce un mecanism extensibil care poate fi folosit pentru asocierea informațiilor cu alte entități ale modelului abstract. Un descriptor asociază informații textuale, secundare entității incluse.

– containerul – reprezintă asocierea unuia sau mai multor elemente digitale și/sau container(e) la un descriptor. Containerele sunt folosite pentru gruparea elementelor digitale. Descriptorul conține informații despre containerul reprezentat.

Pentru rafinarea descrierii resurselor se folosește următorul set de entități:

– fragmentul – identifică un anumit punct sau interval din cadrul unei resurse (secvență video, audio etc.). Fragmentele sunt specifice tipului resursei.

– ancora – conectează descriptori de un fragment. În acest caz, descriptorii conțin informații despre fragmentele ancorei. Ancora este folosită pentru gruparea fragmentelor și descriptorilor. Exemplu de ancoră: un moment de timp al unei resurse video, o formă poligonală din cadrul unei resurse de tip imagine.

– adnotarea – permite adăugarea de informații la o entitate a modelului fără a modifica entitatea.

– alternativa – este o opțiune din mai multe existente; ca de exemplu, alternativa unei conexiuni la Internet la o lărgime de bandă mare sau alternativa unei conexiuni prin dial-up.

– selecția – este opțiunea utilizatorului din alternativele disponibile.

– condiția – pe baza selecției utilizatorului, pot fi satisfăcute (sau nu) condițiile asociate unei entități a elementului digital și entitatea elementului digital poate deveni disponibilă (sau nu).

• Reprezentarea modelului abstract în XML – presupune descrierea sintaxei XML pentru fiecare entitate definită în modelul abstract. Această sintaxă formează limbajul de declarare a elementului digital al MPEG-21 (DIDL – Digital Item Declaration). Declararea elementelor digitale reprezentate în conformitate cu sintaxa DIDL formează documentul DIDL.

DIDL definește câteva elemente suplimentare care nu corespund entităților modelului abstract:

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

– Elementul Referință – reprezintă o legătură la un alt element al documentului DIDL și include conținutul elementul referențiat în elementul referit. Referințele se pot face la elemente din același document DIDL sau la elemente din alt document DIDL. O referință internă permite păstrarea unei singure surse pentru un element care apare în documentul DIDL în mai multe locuri. Referința externă permite unui document DIDL să fie împărțit în mai multe documente DIDL conectate.

– Elementul Declarații este folosit pentru definirea elementelor documentului DIDL, fără a le instanția. Un element declarat poate fi instanțiat folosind elementul Referință.

• Schema XML – specifică sintaxa DIDL și constrângerile pentru structura documentelor DIDL.

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

Figura 2 – Relația dintre modelul abstract MPEG-21 și DIDL

În continuare sunt prezentate componentele de bază ale schemei de declarare a elementelor digitale. Aceste elemente se folosesc în schemele documentelor XML.

• Schema de declarare a elementului digital

Schema de declarare a unui element digital numit ElementDigital care are la primul nivel un container sau un alt element digital este:

<xsd:schema targetNamespace = "urn:mpeg:mpeg21:2002:01-

DIDL-NS" xmlns = "urn:mpeg:mpeg21:2002:01-DIDL-NS"

xmlns:xsd = "http://www.w3.org/2001/XMLSchema"

version = "0.01">

<xsd:element name = "ElementDigital">

<xsd:complexType>

<xsd:sequence>

<xsd:element ref="Declaratii" minOccurs="0"/>

<xsd:choice>

<xsd:element ref="Container"/>

<xsd:element ref="Element"/>

</xsd:choice>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

…

<xsd:schema>

• Container

Containerul are o structură ierarhică, iar definirea sa se realizează recursiv:

<xsd:element name="Container">

<xsd:complexType>

<xsd:sequence>

<xsd:element ref="Descriptor" minOccurs="0"

maxOccurs="unbounded"/>

<xsd:choice>

<xsd:element ref="Referinta"/>

<xsd:sequence>

<xsd:element ref="Container" minOccurs="0"

maxOccurs="unbounded"/>

<xsd:element ref="Element" minOccurs="0"

maxOccurs="unbounded"/>

</xsd:sequence>

</xsd:choice>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

De exemplu, dacă într-un element digital vor fi grupate mai multe elemente ce conțin câte o secvență video, atunci pentru fiecare secvență se va folosi câte un container ce conține declararea elementului.

• Declararea descriptorului elementului digital compus este:

<Declarare mimeType = "video/avi">Secventele Video</Declarare>

</Descriptor>

…

</Element>

…

</Element>

</Container>

</ElementDigital>

2.3.3 Adaptarea conținutului utilizând MPEG-21

Standardul MPEG-21 facilitează dezvoltarea de soluții de adaptare a conținutului distribuit în funcție de caracteristicile tehnice ale terminalelor folosite pentru receptarea datelor, de caracteristicile tehnice ale mediului de comunicație folosit sau în funcție de preferințele utilizatorului.

Pentru adaptarea conținutului multimedia este necesară existența unei descrieri a mediului de lucru, pe lângă descrierea conținutului propriu-zis. În vederea adaptării conținutului multimedia trebuie să existe o descriere a sa, folosind unul din standardele adecvate, ca de exemplu Dublin Core, SMPTE sau MPEG-7. Partea a șaptea a MPEG-21, denumită Adaptarea elementului digital (DIA) este dedicată descrierii caracteristicilor mediului și adaptării elementelor digitale la aceste caracteristici.

DIA definește doar instrumentele necesare în procesul de adaptare, nu realizează și adaptarea conținutului.

Categoriile de instrumente descriptive folosite sunt:

• Instrumentele pentru descrierea mediului – au rolul de a descrie caracteristicile semnificative ale contextului și anume:

– caracteristicile terminalului folosit pentru receptarea sau crearea conținutului multimedia: posibilitățile de codare/decodare ale terminalului, facilitățile/dispozitivele de intrare-ieșire conectate, alte caracteristici relevante;

– caracteristicile rețelei: capacitatea rețelei, tipul conexiunii etc.;

– caracteristicile utilizatorului: informații despre utilizator, preferințele utilizatorului, un istoric al datelor utilizate, preferințe legate de prezentarea informațiilor, caracteristici de accesibilitate și localizarea acestuia;

– caracteristici ale mediul natural: atributele audiovizuale măsurabile ale mediului natural, care afectează modalitatea în care conținutul multimedia este livrat și/sau consumat de utilizator: nivelul zgomotului, intensitatea luminii, fusul orar, locația.

• Instrumentele de adaptare a resurselor sunt folosite pentru descrierea datelor structurale, ale fluxurilor de biți și a datelor despre adaptabilitatea metadatelor și se folosește pentru aceasta Binary Syntax Description Language. Descrierea se bazează pe împărțirea fluxului de biți în componente logice, ca de exemplu împărțirea unei secvențe video în cadre. Fluxul de biți este apoi transformat de un motor pentru adaptarea resursei elementului digital într-un descriptor al sintaxei fluxului (BSD), transformare care poate fi făcută sub controlul XSLT (Extensible Stylesheet Language Transformations). Descriptorul este de dorit să fie independent de un format media ceea ce permite realizarea adaptării resurselor binare în orice locație.

• Instrumentele pentru adaptarea metadatelor – identifică datele care pot fi utilizate pentru reducerea complexității instanțelor XML de adaptare a metadatelor. Specificațiile se referă la filtrarea și scalarea conținutului și la integrarea a două sau mai multe instanțe ale descrierilor.

Legăturile dintre principalele componente ale DIA sunt prezentate în figura 3.

Figura 3– Adaptarea elementului digital și instrumente pentru DIA

Declararea unui DIA pentru descrierea caracteristicilor statice și dinamice ale unei rețele se poate face:

<DIA xmlns="urn:mpeg:mpeg21:dia:schema:2003"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

<Retea>

</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">

</Caracteristici>

</Monitor>

</Terminal>

</DIA>

CAPITOLUL III

XML CA BAZĂ DE DATE

3.1 Este XML-ul o bază de date?

Înainte de a discuta despre XML și baze de date trebuie să răspundem la întrebarea „Este XML-ul o bază de date?”

Un document XML este o bază de date în sensul cel mai strict al cuvântului și anume este o colecție de date. Se poate considera că aceste documente nu sunt diferite de orice alt tip de fișiere – în fond, toate fișierele conțin anumite tipuri de date. Având formatul unei baze de date documentele XML prezintă anumite avantaje. De exemplu este auto-descris (tag-urile descriu structura și numele tipurilor de date, dar nu și semantica), este portabil (Unicode), și poate descrie date în structuri de arbori sau grafuri. De asemenea are și dezavantaje. De exemplu, este prolixs(neclar) și accesul la date este greoi datorită analizării și conversiei textului.

Putem considera și că XML și tehnologiile asociate constituie o bază de date în sensul mai larg al cuvântului – adică, un sistem de gestiune a bazelor de date (SGBD). XML oferă multe din avantajele bazelor de date: stocare (documente XML), scheme (DTD-uri, scheme XML, RELAX NG, ș.a,), limbaje de interogare (XQuery, XPath, XQL, XML-QL, QUILT, etc.), interfețe de programare (SAX, DOM, JDOM). Totuși multe componente ale bazelor de date convenționale: stocare eficientă, indecși, securitate, tranzacții și integritatea datelor, accesul multi-user, triggere, interogări făcute pe mai multe documente ș.a.

Astfel, se pot folosi documente XML ca o bază de date într-un mediu cu cerințe modeste și date puține, dar această soluție nu este viabilă într-un mediu pentru producție în masă, unde există mulți utilizatori, cerințe stricte de integritate a datelor și nevoia de o performanță bună.

3.2 Date și documente

Cel mai important factor în alegerea unei baze de date este ce va stoca aceasta: date sau documente. XML-ul poate fi folosit doar pentru a transporta date între baza de date și o aplicație sau poate fi folosit integral ca în cazul documentelor XHTML și DocBook. Scopul utilizării XML este important deoarece toate documentele centrate pe date au anumite caracteristici comune, la fel se întâmpla și în cazul informațiilor centrate pe documente, și aceste caracteristici influențează felul cum XML-ul este stocat în baza de date.

3.2.1 Documente centrate pe date

Documentele centrate pe date sunt documente care folosesc XML-ul pentru transportul datelor. Aceste documente sunt folosite de către aplicații și nu are nici o importanță faptul că informațiile folosite au fost reținute pentru o perioadă de timp în documente XML. Exemple de documente centrate pe date sunt ordine de plată, programarea zborurilor, date științifice.

Documente centrate pe date au o structură regulată, datele sunt atomice (cea mai mică unitate independenta de date este un element sau un atribut). Ordinea elementelor care apar în document nu este importantă, decât în momentul validării documentului.

Informațiile care există în documentele centrate pe date pot proveni din baza de date (caz în care se dorește extragerea lor în fișiere XML), dar și din afara bazei de date (caz în care se dorește stocarea acestora în baza de date). Un exemplu de informații care provin dintr-o bază de date sunt cantitățile de date stocare în bazele de date relaționale, iar un exemplu de informații care se doresc a fi introduse într-o bază de date pot fi considerate datele științifice obținute de un sistem de măsurători și convertite în XML.

De exemplu următorul ordin de vânzare este un document centrat pe date:

<NumeClient>ABC Industries</NumeClient>

<Oras>Chicago</Oras>

</Client>

Cheie reglabila:

Hotel inoxidabil,

Garantie pe viata.

</Descriere>

</Parte>

</Item>

Separator:

Aluminiu, un an garantie.

</Descriere>

</Parte>

</Item>

</OrdinVanzari>

Pe lângă documentele centrate pe date cu structura asemănătoare cu documentul din exemplul anterior, multe documente care conțin și text adițional sunt centrate pe date. Spre exemplu să considerăm o pagină web care conține informații despre o carte. Deși pagina conține în mare parte text, structura acelui text este regulată, și o parte din acel text este comună tuturor paginilor care descriu cărți, fiecare porțiune de text specific având dimensiuni limitate. Astfel pagina ar putea fi construită dintr-un document XML simplu, centrat pe date care conține informații despre o singură carte și este obținut dintr-o bază de date și un stylesheet XSL care adaugă textul care leagă informațiile din XML. În general orice site web care construiește documente HTML dinamic prin completarea unui template cu informații dintr-o bază de date poate fi înlocuit cu mai multe documente XML centrate pe date și unul sau mai multe stylesheet-uri XSL.

De exemplu, să considerăm următorul document care descrie un zbor:

<LinieAeriana>ABC Airways</LinieAeriana> ofera <Numar>trei</Numar>

zboruri zilnice non-stop din <Origine>Dallas</Origine> spre

<Destinatie>Fort Worth</Destinatie>. Orele de plecare sunt

<Plecare>09:15</Plecare>, <Plecare>11:15</Plecare>,

and <Plecare>13:15</Plecare>. Sosirile sunt cateva minute mai tarziu.

</InfoZbor>

Acesta ar putea fi construit dintr-un fișier XML și un stylesheet simplu:

<LinieAeriana>ABC Airways</LinieAeriana>

<Origine>Dallas</Origine>

<Destinatie>Fort Worth</Destinatie>

<Zbor>

</Zbor>

<Zbor>

</Zbor>

<Zbor>

</Zbor>

</Zboruri>

3.2.2 Informații centrate pe documente

Documentele care folosesc viziunea centrată pe documente sunt, de obicei, acele documente care sunt destinate folosirii de către utilizatori. Exemple de astfel de documente sunt cărțile, email, anunțuri publicitare și aproape orice document XHTML scris de mână. Acestea sunt caracterizate de o structură mai puțin regulată, datele nu sunt atomice (cea mai mică unitate independentă de informație poate fi formată dintr-un element îmbinat cu alte informații din document). Ordinea elementelor care apar în document este aproape întotdeauna importantă.

Aceste tipuri de documente sunt de obicei scrise manual în XML sau în alte formate cum ar fi RTF, PDF sau SGML și apoi sunt transformate în XML. Spre deosebire de documentele centrate pe date aceste documente nu pot proveni din baze de date.

Spre exemplu următorul document ce conține descrierea unui produs este centrat pe documente:

<Intro>

<NumeProdus>Cheie reglabila</NumeProdus> de la <Producator>Full

Fabrication Labs,Inc.</Producator>este<Sumar>ca o cheie universala,

dar mai mica.</Sumar>

</Intro>

<Paragraf>Cheia universala, care are doua versiuni stanga si dreapta , este confectionata din cel mai fin hotel inoxidabil

. Manerul cauciucat se adapteaza la mainile dumneavoastra

chiar si in cele mai aluneacoase situatii. Se poate regla

prin mai multe discuri.</Paragraf>

<Paragraf>Puteti:</Paragraf>

<Lista>

<Item><Link URL="Comanda.html">comanda propria dumneavoastra

cheie reglabila </Link></Item>

<Item><Link URL="Wrenches.htm">Cititi mai multe despre chei</Link></Item>

<Item><Link URL="Catalog.zip">Descarcati catalogul</Link></Item>

</Lista>

<Paragraf>Cheia reglabila costa doar 44.90 RON si, daca veti

comanda acum, veti primi un ciocan

cadou.</Para>

</Descriere>

</Produs>

3.2.3 Date, documente și baze de date

În realitate diferența dintre documentele centrate pe date și cele centrate pe documente nu este întotdeauna clară. Astfel de documente sunt cele legale sau medicale, care sunt scrise ca text dar conțin și porțiuni de date cum ar fi nume, date, proceduri și de multe ori trebuiesc stocate în întregime din cauze legale.

Cu toate acestea clasificarea documentelor ca fiind centrate pe date sau pe documente poate determina tipul bazei de date necesare stocării informațiilor din aceste documente. De obicei datele sunt stocate într-o bază de date tradițională cum sunt cele relaționale sau orientate-obiect. Documentele sunt stocate într-o bază de date nativă XML (o bază de date destinată stocării XML) sau un sistem de gestionare a conținuturilor (content management system) – o aplicație destinată administrării documentelor și construită peste o bază de date nativă XML.

Totuși aceste reguli nu sunt stricte. Datele – în special datele semistructurate – pot fi stocate în baze de date native XML și documentele pot fi stocate în baze de date tradiționale atunci când nu sunt necesare foarte multe caracteristici specifice XML. În plus, granițele dintre bazele de date tradiționale și cele native XML devin din ce în ce mai neclare, deoarece la bazele de date tradiționale se adaugă facilitați native XML și bazele de date native XML suportă stocarea fragmentelor de documente în baze de date, de obicei relaționale, externe.

3.3 Stocarea și recuperarea datelor

Pentru transferarea datelor între documente XML și o bază de date, este necesară maparea schemei documentului XML (DTD, Scheme XML, RELAX NG, etc.) pe schema bazei de date. Software-ul pentru transferul de date este construit peste această mapare. Software-ul poate folosi un limbaj de interogare XML (cum ar fi XPath, XQuery) sau poate transfera direct date conform cu maparea (echivalentul în XML al interogării SELECT * FROM Tabelă).

În al doilea caz, structura documentului și structura necesară pentru mapare trebuie să fie identice. Deoarece acest lucru se întâmplă destul de rar, produsele care folosesc această strategie sunt adesea folosite împreună cu XSLT. Astfel, înainte de transferarea datelor în baza de date, documentul este întâi adus la structura necesară mapării și apoi datele sunt transferate. Similar după transferarea datelor din baza de date, documentul obținut este adus la structura folosită de către aplicație.

3.3.1 Maparea schemelor documentelor pe schemele bazelor de date

Mapările între schemele documentelor și schemele bazelor de date sunt efectuate pe tipurile elementelor, atribute, și text. Aproape întotdeauna se omit structurile fizice (cum ar fi entitățile și informația codificată) și unele structuri logice (cum ar fi instrucțiunile de procesare, comentariile). Aceste omiteri nu au o influență prea mare, deoarece baza de date și aplicația sunt interesate numai de datele din documentul XML.

O consecință a acestor transformări – adică stocarea datelor dintr-un document într-o bază de date și apoi reconstruirea documentului din datele existente în baza de date – este obținerea unui document diferit. Dacă acest lucru este acceptabil depinde de cerințele fiecărui proiect și poate influența alegerea softului.

De obicei sunt folosite două metode pentru a mapa schema unui document XML pe schema unei baze de date: maparea bazată pe tabele și maparea obiectual-relațională.

3.3.1.1 Maparea bazată pe tabele

Maparea bazată pe tabele este folosită de multe produse care efectuează transferul de date între un document XML și o bază de date relațională. Aceasta modelează un document XML ca o singură tabelă sau ca un set de tabele. Structura documentului XML este arătată în exemplul următor.

<linie>

…

</linie>

<linie>

…

</linie>

…

</tabela>

…

</tabela>

…

</bazadedate>

În funcție de software datele din coloane pot fi stocate ca elemente descendente sau ca atribute. În plus, produsele care folosesc mapări bazate pe tabele de multe ori includ metadate fie la începutul documentului fie ca atribute asociate fiecărui element din tabelă sau coloană.

Maparea bazată pe tabele este utilizată pentru serializarea datelor relaționale, ca în cazul transferării datelor între două baze de date relaționale. Dezavantajul acestei mapări este că nu poate fi folosită pentru un document XML care nu respectă formatul din exemplu.

3.3.1.2 Maparea obiectual-relațională

Maparea obiectual-relațională este folosită de către toate bazele de date relaționale care suportă XML și anumite produse middleware. Aceasta modelează datele din documentul XML ca un arbore de obiecte care sunt specifice datelor din document. În acest model, tipurile de elemente cu atribute sunt în general modelate în clase. Tipurile de elemente simple, atributele, și PCDATA sunt modelate ca proprietăți scalare. Modelul este apoi mapat pe bazele de date relaționale folosind tehnici de mapare obiectual-relaționale tradiționale. Astfel clasele sunt mapate pe tabele, proprietățile scalare pe coloane, și proprietățile cu valori obiect sunt mapate pe perechi de chei primare/chei străine.

Denumirea de „mapare obiectual-relațională” este de fapt un termen impropriu, deoarece arborele de obiecte poate fi mapat direct pe baze de date orientate obiect și ierarhizate. Totuși este folosit pentru că majoritatea produselor care folosesc această mapare folosesc baze de date relaționale și acest termen este bine cunoscut.

Este importantă înțelegerea faptului că modelul obiectual din această mapare nu este modelul DOM (Document Object Model). DOM-ul modelează chiar documentul și este același pentru toate documentele XML, în timp ce modelul descris mai sus modelează datele din document și este diferit pentru fiecare set de documente XML care corespund unei scheme XML de date. De exemplu ordinul de vânzări din secțiunea 3.2.1 ar putea fi modelat ca un arbore de obiecte format din 4 clase – OrdineVânzări, Client, Item, și Parte – așa cum se arată în diagrama de mai jos:

OrdineVânzări

/ | \

Client Item Item

| |

Parte Parte

Dacă ar trebui să construim un arbore DOM din același document, acesta ar fi compus din obiecte cum ar fi Element, Atribut și Text.

Element –– Atribut

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

_________/ / \ \_____

/ / \ \

Element Text Element Element

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

| | |

etc. etc. etc.

Instanțierea obiectelor din model depinde de produsul folosit. Unele produse dau posibilitatea generării claselor în model și apoi folosirea obiectelor din aceste clase în aplicații. În cazul folosirii acestor produse, datele sunt transferate între documentul XML și aceste obiecte, și între aceste obiecte și baza de date. Alte produse folosesc aceste obiecte numai pentru a vizualiza maparea și transferul de date direct între documentul XML și baza de date.

Felul în care maparea obiectual-relațională este suportată variază de la produs la produs. De exemplu:

Toate produsele suportă maparea tipurilor complexe de elemente pe clase și a tipurilor simple de elemente și atribute pe proprietăți.

Toate produsele dau posibilitatea desemnării unui element rădăcină care nu este mapat pe modelul obiect sau pe baza de date. Acest element este folositor atunci când se dorește stocarea obiectelor cu mai multe nivele în același document XML.

Majoritatea produselor oferă posibilitatea specificării dacă proprietățile sunt mapate pe atribute sau pe elemente descendente în documentul XML. Unele produse permit combinarea atributelor cu elementele descendente; altele cer folosirea numai a elementelor descendente sau a atributelor.

Majoritatea produselor permit folosirea numelor diferite în documentul XML și baza de date, dar sunt anumite produse care necesită folosirea acelorași nume atât în documentul XML cât și în baza de date.

Majoritatea produselor permit specificarea ordinii în care elementele descendente apar în părintele lor, dar care face imposibilă construirea mai multor modele pentru conținut. Din fericire, modelele pentru conținut suportate sunt suficiente pentru majoritatea documentelor centrate pe date (ordinea este importantă numai dacă se face validarea documentului).

3.3.2 Limbaje de interogare

Multe produse transferă date direct conform cu modelul pe care sunt construite. Deoarece structura documentului XML este de obicei diferită de structura bazei de date, aceste produse deseori conțin sau sunt folosite cu XSLT. Acesta dă posibilitatea utilizatorilor să transforme documente la structura modelului înaintea transferării datelor în baza de date, și invers. Deoarece procesarea XSLT poate fi scumpă, unele produse conțin un număr limitat de transformări în mapările lor.

Soluția pe termen lung la această problemă este implementarea unor limbaje de interogare care returnează XML. În prezent cele mai multe asemenea limbaje se bazează pe fraze SELECT integrate în șabloane. Se presupune că această situație se va schimba atunci când XQuery și SQL/XML vor fi finalizate, acestea aflându-se în lucru. Aproape toate limbajele de interogare XML sunt deocamdată read-only, deci vor fi necesare metode diferite pentru inserarea, actualizarea și ștergerea datelor (în viitor aceste facilitați vor fi adăugate).

3.3.2.1 Limbaje de interogare bazate pe șabloane

Cele mai des întâlnite limbaje de interogare care returnează XML din baze de date relaționale sunt cele bazate pe șabloane. În aceste limbaje, nu există o mapare predefinită între document și baza de date. Frazele SELECT sunt integrate într-un șablon și rezultatele sunt procesate de către software-ul care transfera date. De exemplu, următorul template folosește elementele <SelectStmt> pentru a include fraze SELECT și numele coloanelor pentru a determina unde trebuiesc plasate rezultatele:

<?xml version="1.0"?>

<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>

Rezultatul procesării unui asemenea șablon ar putea fi:

<?xml version="1.0"?>

<Introducere> Urmatoarele zboruri sunt diponibile:</Introduction>

<Zbor>

</Zbor>

…

</Zboruri>

<Concluzie>Speram ca unul dintre ele va este de folos</Concluzie>

</InfoZbor>

Limbajele de interogare bazate pe șabloane pot fi foarte flexibile. Deși setul de caracteristici variază de la un produs la altul, există unele caracteristici comune:

Abilitatea de a plasa seturi de rezultate oriunde în documentul de ieșire, incluzând ca parametrii și frazele SELECT .

Construcții cum ar fi cicluri FOR și instrucțiuni IF.

Definiri de variabile și funcții

Parametrizarea frazelor SELECT prin intermediul parametrilor HTTP.

Limbajele de interogare bazate pe șabloane sunt folosite aproape exclusiv pentru a transfera date din baze de date relaționale în documente XML. Deși unele produse care folosesc limbaje de interogare bazate pe șabloane pot transfera date din documente XML în baze de date relaționale, ele nu folosesc șabloanele numai pentru acest lucru. În schimb ele folosesc o mapare bazată pe tabele, așa cum este descrisă anterior.

3.3.2.2 Limbaje de interogare bazate pe SQL

Limbajele de interogare bazate pe SQL folosesc fraze SELECT modificate, iar rezultatele sunt transformate în XML. Există câteva limbaje particulare de acest tip și cel mai simplu dintre acestea folosește fraze SQL imbricate (nested), care sunt transformate direct în XML imbricat (nested) conform cu maparea relațional-obiectuală. Un alt limbaj de acest tip folosește obiecte SQL 3, de asemenea transformate direct în XML. Un alt limbaj folosește fraze OUTER UNION și marcaje speciale pentru a determina cum sunt transformate rezultatele în XML.

În plus fața de limbajele particulare, un număr de companii s-au reunit în 2000 pentru a standardiza extensiile XML la SQL. Rezultatele lor fac parte acum din specificația ISO SQL și este cunoscută ca SQL/XML. SQL/XML introduce un tip de date XML și adaugă un număr de funcții la SQL, așa că este posibilă construirea elementelor XML și a atributelor din date relaționale.

De exemplu, următoarea interogare:

SELECT Orders.SONumber,

XMLELEMENT(NAME "Order",

XMLATTRIBUTES(Orders.SONumber AS SONumber),

XMLELEMENT(NAME "Date", Orders.Date),

XMLELEMENT(NAME "Customer", Orders.Customer)) AS xmldocument FROM Orders

construiește un set de rezultate cu două coloane. Prima coloană conține numărul ordinului de vânzări și a doua coloană conține un document XML. Există un document XML pe fiecare linie, construit din datele din linia corespunzătoare în tabelul de comenzi. De exemplu documentul pentru linia pentru ordinul de vânzare 123 ar putea fi:

<Client>Gallagher Industries</Client>

</Ordin>

3.3.2.3 Limbaje de interogare XML

Spre deosebire de limbajele de interogare bazate pe șabloane sau bazate pe SQL, care pot fi folosite numai cu baze de date relaționale, limbajele de interogare XML pot fi folosite pentru orice document XML. Pentru a folosi acest tip de limbaje cu baze de date relaționale, datele din baza de date trebuie să fie modelate ca XML.

Cu XQuery, poate fi folosită fie maparea bazată pe tabele fie maparea obiectual relațională. Dacă este folosită o mapare bazată pe tabele, fiecare tabelă este tratată ca un document separat și în fiecare interogare sunt specificate uniri între tabele, ca în SQL. Dacă este folosită o mapare obiectual-relațională atunci ierarhiile de tabele sunt tratate ca un singur document și sunt specificate uniri în mapare. Se preconizează că mapările bazate pe tabele vor fi utilizate în majoritatea implementărilor, în detrimentul bazelor de date relaționale, deoarece se consideră că sunt mai ușor de implementat și mai bine cunoscute de utilizatorii SQL.

Cu XPath, o mapare obiectual-relațională trebuie să fie folosită pentru a executa interogări peste mai multe tabele. Aceasta se întâmplă deoarece XPath nu suportă unirile între documente. Astfel, dacă ar fi folosită o mapare bazată pe tabele, ar fi posibilă interogarea unei singure tabele la un moment dat.

3.3.3 Stocarea datelor în baze de date native XML

De asemenea este posibilă stocarea datelor în documente XML într-o bază de date nativă XML. Acest lucru se face din mai multe motive. Primul ar fi acela când datele sunt semistructurate, adică acestea au o structură regulată, dar acea structură variază destul încât maparea ei la o bază de date relațională duce fie la un număr mare de coloane cu valori nule (care ocupă spațiu inutil), fie la un număr mare de tabele (care este ineficient). Deși datele semistructurate pot fi stocate în baze de date ierarhizate orientate-obiect, se poate alege stocarea lor într-o bază de date nativă XML sub forma unui document XML.

Al doilea motiv pentru stocarea datelor într-o bază de date nativă XML este viteza de recuperare a datelor. În funcție de cum sunt stocate datele în baza de date nativă XML, ar putea fi posibilă recuperarea datelor mult mai repede decât într-o bază de date relațională. Acest lucru se poate întâmpla deoarece unele strategii de stocare folosite de către bazele de date native XML rețin fizic documente întregi sau folosesc pointeri fizici (și nu logici) între părțile documentelor. Acestea permit ca documentele să fie recuperate fie fără uniri fie folosind uniri fizice, ambele fiind mai rapide decât unirile logice folosite în bazele de date relaționale.

De exemplu se consideră ordinul de vânzare prezentat mai sus. Într-o bază de date relațională, acesta ar fi stocat în patru tabele – OrdineVânzări, Itemi, Clienți, și Parte – și recuperarea documentului ar necesita uniri între aceste tabele. Într-o bază de date nativă XML, întreg documentul ar putea fi stocat într-o singură locație pe disc, așa că recuperarea lui sau a unui fragment din el necesită o singură căutare indexată și o singură citire pentru recuperarea datelor. O bază de date relațională necesită patru căutări indexate și cel puțin patru citiri pentru a recupera datele.

Dezavantajul în acest caz este acela că viteza de recuperare este mare numai atunci când datele din comandă sunt stocate pe disc. Dacă se dorește recuperarea altor date, cum ar fi o listă a clienților și ordinele de vânzare ale lor, atunci performanta va fi mai slabă decât într-o bază de date relațională. Astfel, stocarea datelor într-o bază de date nativă XML se recomandă din motive de performanța atunci când predomină o singură vedere asupra datelor.

Al treilea motiv pentru stocarea datelor într-o bază de date nativă XML este exploatarea capacităților specifice XML, cum ar fi executarea interogărilor XML. Deoarece relativ puține aplicații centrate pe date au nevoie de acestea și bazele de date relaționale implementează limbaje de interogare XML, acest motiv nu este foarte important.

O problemă cu stocarea datelor într-o bază de date nativă XML este că majoritatea acestor baze de date pot returna datele numai ca XML. (Puține baze de date suportă legarea elementelor sau atributelor de variabilele dintr-o aplicație.) Dacă o aplicație are nevoie de date într-un alt format (ceea ce este posibil), aceasta trebuie să analizeze XML-ul înainte de a folosi datele. Acesta este un dezavantaj pentru aplicațiile locale care folosesc o bază de date nativă XML în locul unei baze de date relaționale.

3.3.4 Tipuri de date, valori nule, seturi de caractere

Această secțiune se ocupă de anumite probleme legate de stocarea datelor din documente XML în baze de date tradiționale. Problemele legate de tipurile de date și datele binare apar și în cazul stocării datelor în baze de date native XML. În general utilizatorul nu poate alege modalitatea în care sotf-ul care transferă datele rezolvă aceste probleme, dar atunci când se alege un anumit soft trebuie ținut cont de faptul că aceste probleme există.

3.3.4.1 Tipuri de date

XML nu suportă prea multe tipuri de date. Cu excepția entităților neanalizate, toate datele dintr-un document XML sunt text, chiar dacă reprezintă alt tip de date, cum ar fi datele calendaristice sau integer. În general soft-ul de transfer date va transforma textul (din documentul XML) în alte tipuri de date (în baza de date) și invers.

Softul determină ce conversii sunt necesare și există două metode pentru efectuarea acestora. Prima metodă constă în determinarea de către software a tipurilor de date din schema bazei de date, deoarece aceasta este accesibilă la rulare. (Schema XML nu este neapărat accesibilă la rulare sau s-ar putea sa nu existe.) În a doua metodă utilizatorul specifică tipul de date. Acesta poate fi scris de către utilizator sau generat automat dintr-o schemă a unei baze de date sau dintr-o schemă XML. Atunci când sunt generate automat, tipurile de date pot fi recuperate din schemele bazelor de date și din anumite tipuri de scheme XML.

Formatele de text recunoscute în momentul conversiilor pot constitui o problemă atunci când se transferă date din XML, la fel și formatele care se pot crea atunci când se transferă date către XML. În cele mai multe cazuri, numărul de formate de text care sunt suportate de un tip de dată este limitat la unul anume sau la cele suportate de driverul JDBC. Datele pot cauza multe probleme pentru că gama de formate posibile este foarte mare, iar numerele cu diferitele lor formate internaționale pot cauza de asemenea probleme.

3.3.4.2 Date binare

Datele binare se pot stoca în documente XML în trei feluri: codificare Base64 (o codificare MIME care mapează datele binare pe un subset al US-ASCII [0-9, a-z, A-Z,+,/]), codificarea hexazecimală (fiecare octet binar este codificat cu două caractere reprezentând cifre hexazecimale [0-9,a-f,A-F]), și entități neanalizate (datele binare sunt stocate într-o entitate fizică separată de restul documentului XML).

Cea mai mare problemă cu datele binare este că multe dintre produsele care transferă date nu suportă acest tip de date. O problemă secundară apare dacă sunt folosite entități neanalizate și constă în faptul că majoritatea produselor nu stochează notații și declarații de entități. Astfel, notația asociată cu o anumită entitate va fi pierdută atunci când datele sunt transferate dintr-un document XML într-o bază de date.

3.3.4.3 Date vide

În domeniul bazelor de date, date vide sunt numite datele care nu există. Acestea sunt foarte diferite de valoarea 0 (pentru numere), sau lungimea zero (pentru un string). De exemplu, se ia în considerare o colecție de date de la o stație meteo. Dacă termometrul nu funcționează, în baza de date este stocată o valoare nulă și nu valoarea zero, care ar însemna cu totul altceva.

XML suportă de asemenea conceptul de date vide prin tipuri de elemente și atribute opționale. Dacă valoarea unui tip sau atribut opțional este nulă acesta nu este inclus în document. În cazul bazelor de date, atributele care conțin șiruri de caractere cu lungimea zero sau elemente nule nu sunt vide, valoarea lor este un șir cu lungimea zero.

La maparea structurii unui document XML la baza de date și invers, tipurile de date și atributele opționale sunt mapate ca și coloane vide. Dacă nu se procedează în acest mod s-ar putea inserarea o eroare (atunci când se transferă date în baza de date), sau la un document invalid (atunci când se transferă date din baza de date).

3.3.4.4 Seturi de caractere

Un document XML poate conține orice caracter Unicode cu excepția unor caractere de control. Din nefericire, multe baze de date oferă suport limitat sau nu oferă suport deloc pentru Unicode și necesită o configurație specială pentru caracterele non-ASCII.

3.3.4.5 Instrucțiuni de procesare și comentarii

Instrucțiunile de procesare și comentariile nu fac parte din datele dintr-un document XML și majoritatea soft-urilor de transfer de date nu le pot manipula. Totuși ele pot apărea aproape oriunde într-un document XML și de aceea nu se integrează ușor în mapările bazate pe tabele și cele obiectual relaționale. O soluție total ineficientă într-o bază de date relațională este adăugarea unor tabele pentru instrucțiuni de procesare și comentarii, adăugarea de chei străine la aceste tabele pentru toate celelalte tabele, și verificarea acestor tabele de fiecare data când se procesează o altă tabelă. Astfel majoritatea soft-urilor de transfer de date le înlătură.

3.3.4.6 Stocarea marcajelor

În anumite situații este indicată stocarea elementelor cu conținut mixt în baza de date fără a se efectua analiza completă. Când este realizat acest lucru, marcajul este realizat cu caractere de marcare. Totuși apare o problemă la stocarea caracterelor de marcare care nu sunt folosite pentru marcaj. În fișierul XML, acestea sunt stocate folosind entitatile lt, gt, amp, quot, și apos. Acest lucru poate fi făcut și în baza de date. De exemplu următoarea descriere:

Exemplu confuz: <foo/>

</descriere>

poate fi stocată în baza de date ca:

Exemplu confuz: <foo/>

Totuși apare o problemă, limbajele de interogare non-XML, cum ar fi SQL, nu caută în coloane marcaje sau folosirea de entități și le interpretează ca atare. Astfel, dacă se caută șirul „<foo/>” cu SQL, de fapt trebuie căutat șirul „<foo/>”.

Pe de altă parte, dacă referințele la entități sunt extinse, software-ul de transfer de date nu poate distinge între marcaj și folosirea entităților. De exemplu, dacă descrierea de mai sus este stocată în baza de date în forma următoare, soft-ul nu poate spune dacă ,, și <foo/> sunt marcaje sau text:

Exemplu confuz: <foo/>

Soluția pe termen lung la această problemă sunt bazele de date care recunosc XML, în care marcajul efectiv e tratat diferit de elementele care doar par a fi marcaj. Dar, probabil vor fi întotdeauna probleme atunci când aplicații non-XML lucrează cu XML.

3.3.5 Generarea schemelor XML din scheme relaționale și invers

O întrebare care apare frecvent la transferul datelor între documente XML și baze de date este cum se generează scheme XML din scheme ale bazelor de date și invers. Înainte de a explica cum se face acest lucru, este bine de reținut faptul că aceasta este o operație design-time. Motivul pentru acest lucru este că majoritatea aplicațiilor centrate pe date, și cele mai multe aplicații pe verticală, lucrează cu un set cunoscut de scheme XML și scheme de baze de date. Astfel ele nu trebuie să genereze scheme în momentul rulării. În plus procedurile pentru generarea schemelor nu sunt perfecte. Aplicațiile care trebuie să rețină documente XML aleatoare într-o bază de date ar trebui să folosească o bază de date nativă XML în loc să genereze scheme la rulare.

Cea mai ușoară cale de a genera scheme relaționale din scheme XML și invers este de a codifica o cale prin maparea obiectual relațională, care are un număr de trăsături opționale.

O schemă relațională se generează dintr-o schema XML astfel:

Pentru fiecare tip complex de elemente trebuie creată o tabelă și o coloană cheie primară.

Pentru fiecare tip de elemente cu conținut mixt, trebuie creată o tabelă separată în care se va stoca PCDATA, legată de tabela părinte prin intermediul cheii primare din tabela părinte.

Pentru fiecare atribut cu o singură valoare a acelui tip de element, și pentru fiecare element descendent simplu care apare o singură dată trebuie creată o coloană în acel tabel. Dacă schema XML conține informația despre tipurile de date, atunci trebuie setate tipurile de date ale coloanelor la tipul corespunzător. Altfel, tipurile de date trebuie setate la un tip predeterminat, cum ar fi CLOB sau VARCHAR(255). Dacă tipul elementelor descendente sau al atributelor este opțional coloana trebuie să aibă posibilitatea de a fi setată nulă.

Pentru fiecare atribut cu mai multe valori și pentru fiecare element descendent simplu care apare de mai multe ori trebuie creată o tabelă separată pentru a stoca valorile, legată de tabela părinte prin intermediul cheii primare din tabela părinte.

Pentru fiecare element descendent complex, trebuie legată tabela tipului elementului părinte de tabela tipului elementului descendent prin intermediul cheii primare din tabela părinte.

O schema XML se generează dintr-o schemă relațională astfel:

Pentru fiecare tabelă se generează un tip de element

Pentru fiecare coloană care nu este cheie în acea tabelă, dar și pentru coloanele chei primare, se adaugă la model un atribut la tipul elementului sau un element descendent ce conține numai PCDATA.

La fiecare tabelă pentru care cheia primară este exportată, se adaugă un element descendent la model și se procesează tabela recursiv.

Pentru fiecare cheie străina, se adaugă un element descendent la model și se procesează tabela cu cheie străină recursiv.

Există câteva dezavantaje la aceste procedee. Multe dintre acestea se pot corecta ușor de către programator, cum ar fi coliziuni de nume și specificarea lungimilor și tipurilor de date ale coloanelor. DTD-urile nu conțin informații despre tipurile de date, deci nu este posibilă cunoașterea tipurilor de date care ar trebui folosite în baza de date. Tipurile de date și lungimile pot fi prevăzute dintr-o schemă XML.

O problemă mai importantă este aceea că modelul de date folosit de documentul XML este adesea diferit și de obicei mai complex decât cel mai eficient model pentru stocarea datelor în baza de date. De exemplu, se consideră următorul fragment XML:

<Nume>ABC Industries</Nume>

<Oras>Fooville</Oras>

</Adresa>

</Client>

Procedura pentru generarea unei scheme relaționale dintr-o schemă XML ar crea două tabele: una pentru clienți și una pentru adrese. Totuși în majoritatea cazurilor ar fi mai bine să se rețină adresa în tabela de clienți, și nu într-o tabelă separată.

Elementul <Adresa> este un bun exemplu pentru un element wrapper. Elementele wrapper sunt în general folosite din două motive. În primul rând, ele oferă structuri adiționale ceea ce face documentul mai ușor de înțeles. În al doilea rând, ele sunt de obicei folosite ca o formă de redactare a datelor. De exemplu, elementul <Adresa> ar putea fi trimis la o rutină care transformă toate adresele în obiecte Adresa, indiferent unde apar acestea.

Daca elementele wrapper sunt folositoare în XML, în general ele cauzează probleme atunci când sunt mapate la baza de date dacă acestea se găsesc sub forma extra-structurilor. Din această cauză, ele ar trebui eliminate din schema XML înaintea generării schemei relaționale. Din moment ce este puțin probabil că modificarea schemei XML ar trebui să fie permanentă, acest lucru duce la o neconcordanță între documentul existent și documentele presupuse de către soft-ul de transfer de date, din moment ce elementele wrapper nu sunt incluse în mapare. Acest lucru poate fi rezolvat prin transformarea documentelor la rulare cu XSLT: elementele wrapper sunt eliminate înaintea transferării datelor în baza de date și sunt inserate după transferul datelor din baza de date.

Cu toate aceste dezavantaje, procedurile de mai sus oferă în continuare un punct de pornire folositor pentru generarea schemelor XML din scheme relaționale și invers, în special în sisteme mari.

3.4 Stocarea și recuperarea documentelor

Pentru stocarea documentelor XML există două strategii de bază: stocarea lor în sistemul de fișiere sau ca un BLOB într-o bază de date relațională și acceptarea funcționalităților XML limitate, sau stocarea lor într-o bază de date nativă XML.

3.4.1 Stocarea documentelor în sistemul de fișiere

Dacă se lucrează cu un set simplu de documente, cum ar fi un set mic de documentație, cea mai ușoara cale de stocare este în sistemul de fișiere. Se pot folosi instrumente cum ar fi „grep” pentru interogarea lor, și „sed” pentru modificarea lor. Căutările complete de text în documentele XML sunt inexacte, pentru că ele nu pot distinge marcajul de text și nu pot înțelege folosirea entităților. Totuși, într-un sistem mic, aceste inexactități ar putea fi acceptabile. Dacă se dorește un simplu control al tranzacțiilor, documentele pot fi întreținute cu o versiune de control a sistemului cum ar fi CVS sau RCS.

3.4.2 Stocarea documentelor în BLOB-uri

O opțiune puțin mai sofisticată este stocarea documentelor ca BLOB-uri într-o bază de date relațională. Această modalitate oferă un număr de avantaje a bazelor de date: controlul tranzacțiilor, securitate, acces multiuser. În plus, multe baze de date au instrumente pentru căutări de text și pot face căutări complete de text, căutări aproximative, căutări sinonime și căutări fuzzy. Unele dintre aceste instrumente sunt construite pentru a recunoaște XML, ceea ce va elimina problemele care apar la căutările documentelor XML ca simplu text.

Atunci când se stochează documente XML ca BLOB-uri, se pot implementa ușor indexări simple care recunosc XML, chiar dacă baza de date nu poate indexa XML. O modalitate de a face acest lucru este crearea a două tabele, o tabelă index și o tabelă document. Tabela document conține o cheie primară și o coloană BLOB în care este reținut documentul. Tabela index conține o coloană în care se găsește valoarea ce va fi indexată și o cheie străină care duce la cheia primară a tabelei document.

Atunci când documentul este stocat în baza de date, el este căutat pentru toate instanțele elementului sau atributului care este indexat. Fiecare instanța este stocată în tabela index, împreuna cu cheia primara a documentului. Coloana de valori este apoi indexată, și permite unei aplicații să efectueze o căutare rapidă a unei anumite valori a unui element sau atribut și să recupereze documentul corespunzător.

De exemplu, se consideră un set de documente cu următorul DTD și se dorește construirea unui index de autori:

<!ELEMENT Brosura (Titlu, Autor, Continut)>

<!ELEMENT Titlu (#PCDATA)>

<!ELEMENT Autor (#PCDATA)>

<!ELEMENT Continut (%Inline;)> <!– Inline entity from XHTML –>

Acestea ar putea fi stocate în următoarele tabele:

Autori Brosuri

–––––––- –––

Autor VARCHAR(50) BrosurID INTEGER

BrosuraID INTEGER Brosura LONGVARCHAR

Când se inserează o broșură în baza de date, aplicația inserează broșura în tabela Broșuri, apoi caută elementele <Autor>, reținând valorile acestora și ID-ul broșurii din tabela Autori. Aplicația poate recupera broșurile în funcție de autor cu o simplă fraza SELECT. De exemplu, pentru a recupera toate broșurile scrise de autorul „Chen”, aplicația execută următoarea interogare:

SELECT Brosura

FROM Brosuri

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

O tabelă de indecși mai sofisticată ar conține patru coloane: numele atributului sau elementului, tipul, valoarea și ID-ul documentului. Aceasta tabelă ar putea stoca valorile marcajelor multiple și ar trebui indexată după nume, tip, și valoare. Scrierea unei aplicații generice SAX pentru a popula o astfel de tabelă ar fi relativ ușoară.

3.4.3 Baze de date native XML

Dacă sunt necesare mai multe caracteristici decât cele oferite de unul din sistemele de mai sus, trebuie luată în considerare o bază de date nativă XML. Bazele de date native XML sunt baze de date construite special pentru a stoca documente XML. Ca și alte baze de date, acestea suportă tranzacții, securitate, acces multiuser, API-uri programatice, limbaje de interogare. Singura diferență față de alte baze de date este aceea că modelul lor interior este bazat pe XML și nu pe altceva, ca în cazul modelului relațional.

Bazele de date native XML sunt de obicei folosite pentru a stoca documente centrate pe documente. Principalul motiv este că oferă suport pentru limbaje de interogare XML, care oferă posibilitatea adresării unor întrebări de forma: „Extrage toate documente în care al treilea paragraf de la începutul secțiunii conține un cuvânt îngroșat”, sau oferă posibilitatea limitării căutărilor complete de text la anumite porțiuni din document. Asemenea interogări sunt dificil de scris într-un limbaj ca SQL. Un alt motiv este acela că bazele de date native XML păstrează ordinea documentelor, instrucțiunile de procesare, și comentarii, și adesea păstrează secțiuni CDATA, folosirea entităților, și altele, pe când bazele de date ce permit folosirea XML nu posedă aceste caracteristici.

Bazele de date native XML sunt de obicei folosite pentru a integra date. Integrarea datelor a fost făcută cu baze de date relaționale federate, dar acestea necesitau ca toate resursele de date să fie mapate la modelul relațional. Această modalitate nu funcționează pentru mai multe tipuri de date și modelul de date XML oferă o flexibilitate mai mare. Bazele de date native XML tratează modificările schemelor mai ușor decât bazele de date relaționale și pot trata și date care nu au schemă. Ambele considerații sunt importante pentru integrarea datelor din surse care nu se află sub control direct.

Al treilea caz de utilizare major al bazelor de date native XML este pentru datele semistructurate, așa cum se găsesc în finanțe, în biologie, date care se schimbă atât de des încât nu este posibilă definirea unor scheme definitive. Datorită faptului că bazele de date native XML nu necesită scheme, ca bazele de date relaționale, ele pot să trateze acest tip de date, deși aplicațiile adesea necesită procesarea acestor date de către oameni.

Ultima utilizare majora a bazelor de date native XML este tratarea evoluției schemelor. Chiar dacă bazele de date native XML nu oferă soluții complete, ele oferă o flexibilitate mai mare decât bazele de date relaționale. De exemplu, bazele de date native XML nu necesită ca datele existente să fie mutate într-o altă schemă, ele pot trata modificări ale schemelor pentru care nu există nicio cale a migrației, și pot stoca date chiar dacă acestea aparțin unei versiuni necunoscute a unei scheme.

Alte utilizări ale bazelor de date native XML includ punerea la dispoziție de cache pentru date și metadate pentru tranzacții lungi, operarea cu documente mari și date ierarhice, și comportarea ca un intermediar între date și cache (mid-tier data cache).

3.4.3.1 Ce este o bază de date nativă XML?

Termenul „bază de date nativă XML” a apărut prima dată în campania de marketing a Tamino, o bază de date nativă XML dezvoltată de Software AG. Probabil datorită succesului acestei campanii, termenul a fost acceptat de către companiile care dezvoltau produse similare. Dezavantajul acestui termen este că fiind un termen de marketing, nu a avut niciodată o definiție formală tehnică.

O definiție posibila (dezvoltată de membrii XML:DB) este aceea că o bază de date nativă XML are următoarele caracteristici:

Definește un model logic pentru un document XML – spre deosebire de datele din acel document – și stochează și recuperează documente conform acelui model. Modelul trebuie să includă minim elemente, atribute, PCDATA, și ordinea documentelor. Exemple de astfel de modele sunt modelul de date Xpath, XML Infoset, și modelele conținute de DOM și evenimentele din SAX 1.0.

Are ca unitate fundamentală de stocare logică un document XML, așa cum o bază de date relațională are ca unitate de bază de stocare logică o linie dintr-o tabelă.

Nu este necesar un model fizic special de stocare a datelor. De exemplu, acesta poate fi construit pe o bază de date relațională, ierarhică, sau orientată pe obiecte, sau se poate folosi un format de stocare particular cum ar fi fișierele comprimate indexate.

Prima parte a acestei definiții este similară cu definițiile altor tipuri de baze de date, și se concentrează pe modelul folosit de baza de date. Nu are nicio importanță faptul că o anumită bază de date nativă XML ar putea stoca mai multe informații decât conține modelul folosit de baza de date. De exemplu, ar putea suporta interogări bazate pe modelul Xpath, dar să stocheze documente ca text. În acest caz, secțiunile CDATA și folosirea entităților sunt stocate în baza de date dar nu sunt incluse în model.

A doua parte a definiției spune că unitatea de bază de stocare într-o bază de date nativă XML este un document XML. Deși poate părea posibil ca o bază de date nativă XML ar putea atribui acest rol fragmentelor de documente, bazele de date native XML sunt populate cu documente complete.

Unitatea de bază de stocare este nivelul elementar de context în care se potrivește un anumit element de date, și este echivalent cu o linie într-o bază de date relațională. Existența acestei unități de bază nu împiedică recuperarea unor unități mai mici de date, cum ar fi fragmente de documente sau elemente individuale, și nu exclude nici posibilitatea combinării fragmentelor dintr-un document cu fragmente din alt document. În termeni relaționali, acest lucru este echivalent cu faptul că existența liniilor nu împiedica recuperarea individuală a valorilor din coloane sau crearea unor linii noi din altele existente deja.

A treia parte a definiției spune că formatul de stocare nu este important. Acest lucru este adevărat, și este analog cu faptul că formatul fizic de stocare folosit de o bază de date relațională nu are legătură cu faptul ca baza de date este relațională.

3.4.3.2 Arhitecturile bazelor de date native XML

Arhitecturile bazelor de date native XML se clasifică în două categorii: bazate pe text și bazate pe modele.

Baze de date native XML bazate pe text

O bază de date nativă XML bazată pe text stochează XML ca text. Acesta ar putea fi un fișier într-un sistem de fișiere, un BLOB într-o bază de date relațională, sau un format de text particular. Nu are nicio importanță faptul că o bază de date relațională care a adăugat procesarea ce recunoaște XML a coloanelor CLOB (Character Large Object) este, de fapt, o bază de date nativă XML având în vedere aceste abilități.

Toate bazele de date native XML bazate pe text au în comun indecșii, care oferă posibilitatea motorului de interogare să sară ușor în orice punct din orice document XML. Acest lucru dă o viteză extraordinară la recuperarea documentelor întregi sau a fragmentelor de documente. Acest lucru se întâmpla deoarece baza de date poate executa o singură căutare indexată, poate poziționa capul de citire o singură dată, și, presupunând că fragmentul necesar este stocat continuu pe disc, poate recupera întregul document sau fragment cu o singură citire. Spre deosebire de aceasta modalitate, reasamblarea unui document din fragmente, cum se face în cazul bazelor de date relaționale și unele baze de date native XML bazate pe modele, necesită căutări indexate multiple și mai multe citiri ale discului.

În acest sens, o bază de date nativă XML bazată pe text este similară cu bazele de date ierarhice, amândouă având performanțe mai bune decât bazele de date relaționale la recuperarea și returnarea datelor în funcție de o ierarhie predefinită. La fel ca bazele de date ierarhice, bazele de date native XML bazate pe text ar putea întâmpina dificultăți la recuperarea și returnarea datelor în orice altă formă, cum ar fi inversarea ierarhiei sau a unor porțiuni ale ei. Acest lucru nu a fost dovedit încă, dar predominanța bazelor de date relaționale, care folosesc pointeri logici ce permit ca toate interogările de aceeași complexitate să fie executate cu aceeași viteză, pare să indice că așa se va întâmpla.

Baze de date native XML bazate pe modele

A doua categorie de baze de date native XML este cea bazată pe modele. În loc să stocheze documentul XML ca text, aceste baze de date construiesc un model obiectual intern din document și stochează acest model. Modalitatea reținerii acestui model depinde de baza de date. Unele baze de date stochează modelul într-o bază de date relațională sau orientată obiect. De exemplu, stocarea DOM-ului într-o bază de date relațională ar putea duce la obținerea unor tabele cum ar fi Elements, Attributes, PCDATA, Entities, și EntityReferences. Alte baze de date folosesc un format de stocare particular optimizat pentru modelul lor.

Un exemplu de bază de date simplă nativă XML bazată pe un model construită pe o bază de date relațională este cea descrisa de Mark Birbeck la XML-L în decembrie 1998. Sistemul folosește cinci tabele – definirea atributelor, asocierile dintre elemente/atribute, definirea conținutului modelului, valorile atributelor, și valorile elementelor (PCDATA sau pointeri la alte elemente) – și un model care include numai elemente, atribute, text, și ordinea documentelor.

Bazele de date native XML bazate pe modele construite pe alte baze de date vor avea performanțe similare cu acele baze de date la recuperarea documentelor pentru că ele se bazează pe acele sisteme pentru a recupera datele. Totuși, designul bazei de date, în special pentru bazele de date native XML construite pe baze de date relaționale poate varia destul de mult. De exemplu, o bază de date care folosește o mapare obiectual-relațională directă a DOM-ului ar putea duce la un sistem care necesită executarea frazelor SELECT separat pentru a recupera descendenții fiecărui nod. Pe de altă parte, majoritatea acestor baze de date își optimizează modelul de stocare și softul de recuperare. De exemplu, Richard Edwards a descris un sistem de stocare a DOM-ului într-o bază de date relațională care poate recupera orice fragment de document (inclusiv întregul document) cu o singură fraza SELECT.

Este probabil că bazele de date native XML bazate pe modele care folosesc un format de stocare particular să aibă performanțe similare cu cele native XML bazate pe text la recuperarea datelor în ordinea în care au fost stocate. Acest lucru se întâmplă deoarece majoritatea acestor baze de date folosesc pointeri fizici între noduri, ceea ce ar trebui să ducă la o performanță similară cu recuperarea textului. (Rapiditatea unei metode sau alteia depinde și de formatul de ieșire. Sistemele bazate pe text sunt mai rapide la returnarea documentelor ca text, pe când sistemele bazate pe modele sunt mai rapide la returnarea documentelor ca arbori DOM, presupunând că modelul lor se mapează ușor la DOM.)

Ca și bazele de date native XML bazate pe text, e probabil că și cele bazate pe modele să întâmpine probleme de performanță la recuperarea și returnarea datelor într-un formular, altul decât cel în care sunt stocate, cum ar fi inversarea ierarhiei sau a unor porțiuni a ei. Nu se știe dacă aceste baze de date vor fi mai rapide sau nu decât cele bazate pe text.

3.4.3.3 Caracteristici ale bazelor de date native XML

În această secțiune sunt prezentate un număr de caracteristici ale bazelor de date native XML.

Colecții de documente

Multe baze de date native XML suportă noțiunea de colecție. Acestea au un rol similar cu cel al tabelelor în bazele de date relaționale sau cu cel al directoarelor într-un sistem de fișiere. De exemplu, dacă se folosește o bază de date nativă XML pentru stocarea unor ordine de vânzare, ar trebui definită o colecție de ordine de vânzare astfel încât interogările cu privire la ordinele de vânzare să poată fi limitate la documentele din acea colecție.

Ca un alt exemplu, dacă se stochează manualele pentru toate produsele unei companii într-o bază de date nativă XML, ar trebui definită o ierarhie de colecții, o colecție pentru fiecare produs, și în acea colecție, câte o colecție pentru fiecare capitol din fiecare manual.

Limbaje de interogare

Aproape toate bazele de date native XML suportă unul sau mai multe limbaje de interogare. Cel mai popular este Xpath (cu extensii pentru interogări asupra mai multor documente) și Xquery, deși numeroase limbaje de interogare particulare sunt suportate de asemenea.

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

Updatări și ștergeri

Bazele de date native XML au o varietate de strategii pentru actualizarea și ștergerea documentelor, de la simpla înlocuire sau ștergere a documentului existent până la modificarea arborelui DOM, până la limbaje care specifică cum să se modifice fragmente ale unui document. Majoritatea acestor metode sunt particulare. Totuși, au apărut două limbaje întrucâtva standardizate pentru actualizarea documentelor XML:

XUpdate, de la XML:DB Initiative, este un limbaj bazat pe XML. Folosește XPath pentru a identifica un set de noduri, apoi specifică dacă să se insereze sau să se șteargă aceste noduri, sau să insereze noduri noi înaintea sau după acestea. XUpdate a fost implementat în mai multe baze de date native XML.

Un set de extensii ale XQuery a fost propus de membrii grupului W3C XQuery și Patrick Lehti. Variații asupra acestor extensii au fost implementate în mai multe baze de date native XML și pare probabil că acestea vor forma bazele sintaxei pentru actualizare în XQuery.

În ciuda acestor limbaje, este probabil ca abilitățile de actualizare să rămână fragmentate până când va fi adăugată formal o sintaxă de actualizare la XQuery.

Tranzacții, blocări, și concurență

Aproape toate bazele de date native XML suportă tranzacții (și probabil suportă și întoarceri). Totuși, blocarea se face adesea la nivelul întregului document, și nu la nivelul unui nod individual, de aceea concurența multi-user este relativ redusă. Dacă aceasta este o problemă depinde de aplicație și ceea ce constituie un „document”. De exemplu:

Un document este un capitol al unui ghid al utilizatorului și scriitorii editează capitolele. Este puțin probabil ca blocarea la nivel de document să cauzeze probleme de concurență, deoarece este improbabil ca doi scriitori să actualizeze același capitol în același moment.

Un document stochează toate datele despre toate vânzările și vânzătorii adaugă informații despre noile vânzări. Este probabil ca blocarea la nivel de document să determine probleme de concurență, deoarece șansele ca doi vânzători să actualizeze informații în același timp este destul de mare. Din fericire, acest lucru poate fi rezolvat cel puțin parțial prin crearea unui document de vânzare pentru fiecare client.

Un document conține datele folosite într-un flux, cum ar fi un contract financiar. Fiecare pas al fluxului citește date dintr-un computer și adaugă datele proprii. De exemplu, un pas ar putea face o verificare de credit și ar adăuga un credit la document. Un alt pas ar putea căuta balanțe în așteptare în alte contracte ale aceluiași client și ar putea adăuga totalul balanțelor. Dacă blocarea la nivel de nod este folosită, unii dintre acești pași ar putea fi executați în paralel. Dacă este folosită blocarea la nivel de document, acești pași ar trebui executați secvențial pentru a evita conflicte de scriere. Acest lucru ar putea aduce întârzieri inacceptabile în aplicații mari.

Problema blocării la nivel de nod este implementarea acesteia. Blocarea unui nod necesită de obicei blocarea părintelui său, ceea ce necesită blocarea părintelui acestuia, și așa până la rădăcină, blocând efectiv întregul document. Pentru a vedea de ce acest lucru este adevărat, se consideră o tranzacție care citește un nod frunză. Dacă tranzacția nu are blocări pe strămoșii nodului frunză, o altă tranzacție poate șterge un nod strămoș al frunzei, astfel ștergând și nodul frunză. Totuși, o altă tranzacție ar trebui să poată actualiza acele părți ale documentului care nu sunt pe calea directă de la rădăcină la nodul frunză.

O soluție parțială a acestei probleme este propusă de Stijn Dekeyser În timp ce problema blocării strămoșilor unui nod țintă nu a fost total ocolită, aceste blocări au fost făcute mai flexibile prin adnotarea lor cu definirea prin interogare a căii de la nodul blocat până la nodul țintă. Acest lucru permite altor tranzacții să determine dacă sunt în conflict cu alte tranzacții. Deoarece evaluarea interogărilor pentru a obține blocări este foarte costisitoare, schema actuală este întrucâtva mai limitată decât a fost descrisă aici, dar acesta este principiul de funcționare.

În viitor, majoritatea bazelor de date native XML vor oferi probabil posibilitatea blocării la nivel de nod.

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

Majoritatea bazelor de date native XML oferă API-uri programatice. Acestea sunt de obicei sub forma unei interfețe asemănătoare ODBC, cu metode pentru legarea la baza de date, explorarea metadatelor, executarea interogărilor, și recuperarea rezultatelor. Rezultatele sunt de obicei returnate ca un șir XML, un arbore DOM, sau un Parser SAX, sau un XMLReader peste documentul returnat. Dacă interogările pot returna documente multiple, atunci metodele pentru parcurgerea rezultatelor sunt de asemenea disponibile. Deși majoritatea bazelor de date native XML oferă API-uri particulare au fost dezvoltate două API-uri independente (iulie 2004):

API-ul XML:DB al XML:DB.org care este independent de limbajul de programare, și folosește XPath ca limbajul său de interogare, și este extins pentru a suporta XQuery. A fost implementat pentru mai multe baze de date native XML și se poate să fi fost implementat și pentru baze de date care nu sunt native XML.

JSR 225: XQuery API pentru Java (XQJ) este bazat pe JDBC și folosește XQuery ca limbaj de interogare. Este dezvoltat de către Java Community Process (JCP) de la Sun. Deoarece această inițiativa este condusă de IBM și Oracle este probabilă răspândirea ei la scară largă.

Majoritatea bazelor de date native XML oferă de asemenea posibilitatea executării interogărilor și returnarea rezultatelor prin HTTP.

Round-Tripping

O caracteristică importantă a bazelor de date native XML este că pot efectua un „round-trip” al documentelor XML. Acest lucru înseamnă că se poate stoca un document XML într-o bază de date nativă și se poate recupera din baza de date același document. Acest lucru este important pentru aplicațiile centrate pe documente, pentru care secțiunile CDATA, folosirea entităților, comentariile și procesarea instrucțiunilor sunt o parte integrantă a documentului. De asemenea este foarte important pentru multe aplicații medicale și legale, care sunt obligate prin lege sa păstreze copii fidele ale documentelor.

Round-tripping-ul este mai puțin important pentru aplicațiile centrate pe date, pentru care de obicei contează elementele, atributele, textul, și ordinea ierarhică. Toate softurile care transferă date între documente XML și baze de date pot executa acest procedeu cu aceste date. Aceleași operații pot fi aplicate și unor ordonări similare (ordinea elementelor și a PCDATA în părintele lor) într-un număr limitat de cazuri care sunt importante pentru aplicațiile centrate pe date. Totuși deoarece nu pot face aceste operații în toate cazurile, și nici asupra instrucțiunilor de procesare, comentariilor, și structurilor fizice (referințele către entități, secțiuni CDATA), nu sunt potrivite pentru aplicații centrate pe documente.

Toate bazele de date native XML pot aplica round-tripping-ul la nivelul elementelor, al atributelor, al PCDATA, și al ordinii documentelor. Cât de mult se poate aplica acest procedeu depinde de baza de date. Ca o regulă generală, bazele de date native XML bazate pe text aplică acest procedeu pe documentele XML exact, în timp ce bazele de date native XML bazate pe modele aplică acest procedeu asupra documentelor XML la nivelul modelului. În cazul modelelor minimale de documente, acest procedeu se face la un nivel mai mic decât XML-ul canonic.

Din moment ce nivelul de round-tripping depinde de fiecare aplicație, și alegerea bazei de date native XML potrivite poate varia.

Date aflate la distanță

Unele baze de date native XML pot include date aflate la distanță în documente stocate în baza de date. De obicei aceste date sunt recuperate dintr-o bază de date relațională cu ODBC, OLE DB, sau JDBC și sunt modelate folosind maparea bazată pe tabele sau maparea relațional-obiectuală. Daca aceste date sunt “live” – adică dacă actualizările documentului din baza de date nativă XML sunt reflectate în baza de date aflată la distanță – depinde de baza de date nativă XML. În viitor majoritatea bazelor de date native XML vor suporta date “live” aflate la distanță.

Indecși

Toate bazele de date native XML suportă indecși ca o modalitate de a mări viteza de interogare. Exista trei tipuri de indecși. Indecșii valoare indexează text și valori ale atributelor și sunt folosiți pentru a rezolva interogări de forma: „Găsește toate elementele sau atributele ale căror valori sunt ‘Santa Cruz’.” Indecșii structurali indexează locația elementelor și atributelor și sunt folosiți pentru a rezolva interogări de forma: „Găsește toate elementele adresă.” Indecșii valoare și structurali sunt combinați pentru a rezolva interogări de forma: „Găsește toate elementele orașe ale căror valori sunt ‘Santa Cruz’.” Indecșii full-text indexează semnele individuale din text și valorile atributelor și sunt folosiți pentru a rezolva interogări de forma: „Găsește toate documentele care conțin cuvintele ’Santa Cruz’.” sau în conjuncție cu indecșii structurali :”Găsește toate documentele care conțin cuvintele ‘Santa Cruz’ într-un element adresă.”

Majoritatea bazelor de date native XML suportă atât indecși valoare cât și indecși structurali. Unele baze de date native XML suportă indecși full-text.

Stocarea entităților externe

O problemă dificilă care apare la stocarea documentelor XML este tratarea entităților externe. Adică, ar trebui extinse și valorile lor stocate împreuna cu restul documentului, sau ar trebui ca referințele la entități să fie lăsate la locul lor? Această întrebare nu are răspuns unic.

De exemplu, se consideră că un document include o entitate externă generală care apelează un program CGI pentru prognoza meteo. Dacă documentul este folosit ca o pagina Web care oferă prognoza meteo, ar fi o greșeală extinderea referinței la entitate, deoarece pagina de Web nu ar mai returna date ‘live’. Pe de altă parte, dacă documentul ar fi o parte a unei colecții de date despre vreme mai vechi, ar fi o greșeală să nu se extindă referința, deoarece documentul ar recupera întotdeauna datele curente și nu le-ar mai reține pe cele vechi.

Ca un alt exemplu, se consideră un manual al unui produs care nu conține altceva decât referințe la entități externe care trimit la capitolele manualului. Daca unele dintre aceste capitole ar fi folosite în alte documente, ca manualele pentru diferite modele ale aceluiași produs, ar fi o greșeală extinderea acestor referințe, pentru ca ar duce la copii multiple ale acelorași capitole.

3.4.3.4 Normalizare, integritate referențială și scalabilitate

Pentru mulți, în special pentru cei ce poseda cunoștințe despre baze de date relaționale, bazele de date native XML ridică un număr de probleme controversate, în special cu privire la problemele de stocare a datelor (spre deosebire de documente). Unele dintre aceste probleme sunt dezbătute în secțiunile următoare.

Normalizarea

Normalizarea se referă la procesul de proiectare a schemei unei baze de date în care un anumit set de date sunt reprezentate o singură dată. Normalizarea are câteva avantaje clare, cum ar fi reducerea spațiului necesar pe disc și eliminarea posibilității apariției inconsistențelor, care se pot găsi atunci când un set de date este stocat în mai multe locuri. Aceasta este una din pietrele de temelie a tehnologiei relaționale și este un punct aprins în discuțiile despre stocarea datelor în baze de date native XML.

Normalizarea nu este o problemă pentru documente centrate pe documente. De exemplu, se consideră o colecție de documente ce descrie produsele unei companii. În multe asemenea colecții, există puține date comune tuturor documentelor – notificări de copyright, adresele corporațiilor și numere de telefon, logo-uri ale produselor – și aceste date sunt prea puține relativ la total încât normalizarea acestora nu se ia în calcul. Pe de altă parte, alte seturi de documentații au părți comune importante între documente și se merită normalizarea lor.

Ca și în cazul bazelor de date relaționale, normalizarea bazelor de date native XML nu este obligatorie. De aceea este importantă proiectarea atentă a structurii documentelor înainte de stocarea lor într-o bază de date nativă XML. Bazele de date native XML au un avantaj față de bazele de date relaționale. Din moment ce bazele de date native XML nu au scheme, se pot stoca documente similare în baza de date cu mai multe scheme la un anumit moment. Chiar dacă este necesară reproiectarea interogărilor și convertirea documentelor existente, acest lucru ar putea ușura procesul de tranziție.

Normalizarea datelor pentru o bază de date nativă XML este aproximativ la fel ca normalizarea unei baze de date relaționale: documentele trebuie proiectate astfel încât datele să nu se repete. O diferență între bazele de date native XML și bazele de date relaționale este aceea ca XML suportă proprietăți multi-valoare în timp ce majoritatea bazelor de date relaționale nu. Aceasta face posibilă normalizarea datelor într-o bază de date nativă XML într-o manieră care nu este posibilă într-o bază de date relațională.

De exemplu, se consideră un ordin de vânzare. Acesta constă în informațiile din antet, cum ar fi numărul ordinului, data, numărul clientului, și unul sau mai mulți itemi care conțin un număr curent, cantitatea, și prețul total. Într-o bază de date relațională, informația din antet trebuie stocată într-o tabelă separată față de itemi, deoarece sunt mai multe linii în fiecare antet. Într-o bază de date nativă XML, această informație poate fi stocată într-un singur document fără redundanțe, deoarece natura ierarhică a XML permite unui element părinte să aibă mai mulți descendenți.

Din nefericire, normalizarea pe cazuri concrete nu este atât de simplă. De exemplu, ce se întâmplă atunci când se dorește ca ordinul de vânzare să conțină informații despre client, cum ar fi nume de contact și adresa de expediere și facturare? Exista două variante. Prima, se pot duplica informațiile despre client în fiecare ordin de vânzare pentru acel client, ducând la date redundante și toate problemele care apar cu acestea. A doua variantă, se pot stoca informațiile despre client separat și fie adăugat un XLink în documentul ordinului de vânzare către documentul clientului, fie unite cele două documente atunci când datele sunt interogate. Acest lucru presupune că fie legăturile XLink sunt suportate (în majoritatea cazurilor nu sunt), fie limbajul de interogare suportă uniri (de asemenea nu se întâmplă întotdeauna).

În practică nu există soluții clare. Datele relaționale din lumea reală sunt adesea nenormalizate din motive de performanță. Dacă se stochează documente centrate pe documente și acestea se pot normaliza până la un anumit grad – cum ar fi stocarea capitolelor sau procedurilor ca documente separate și unirea lor pentru a crea documente end-user – atunci o bază de date nativă XML este o soluție bună, în special pentru că va oferi caracteristici precum limbaje de interogare XML care nu se găsesc în alte baze de date. Dacă se stochează documente centrate pe date și o bază de date nativă XML îmbunătățește performanța aplicației sau oferă stocarea datelor semi-structurate, facilități care nu se găsesc în alte baze de date atunci această bază de date ar trebui folosită.

Integritatea referențială

Integritatea referențială este strâns legată de normalizare. Aceasta se referă la validitatea pointerilor la datele legate și sunt o parte necesară a menținerii consistenței bazei de date. De exemplu nu este de niciun folos un număr de client dintr-un ordin de vânzare care nu are o înregistrare a clientului corespondentă. Departamentul de expediere nu va ști unde să trimită marfa și departamentul de contabilitate nu va ști unde să trimită factura.

Într-o bază de date relațională, integritatea referențială înseamnă asigurarea că se face legătura corectă între cheile străine și cheile primare – adică, verificarea că linia cheii primare ce corespunde oricărei chei străine există. Într-o bază de date nativă XML, integritatea referențială înseamnă asigurarea că pointerii în documentul XML trimit la documente valide sau fragmente de documente.

Pointerii din documentele XML sunt de mai multe feluri: atribute ID/IDREF, câmpuri key/keyref (așa cum sunt definite în scheme XML), legături XLink, și diferite mecanisme particulare. Cele din urma includ elemente și atribute de referire într-un limbaj specific, cum ar fi atributul ‘ref’ al elementului <element> în schemele XML, și mecanisme de legături specifice bazelor de date. În timp ce elementele și atributele de referire într-un limbaj specific sunt destul de des întâlnite, mecanismele de legături specifice bazelor de date sunt mai rare.

Integritatea referențială într-o bază de date nativă XML poate fi împărțită în două categorii: integritatea pointerilor interni (pointeri dintr-un document) și integritatea pointerilor externi (pointeri dintre documente). Integritatea referențială a pointerilor interni care folosesc mecanisme non-standard nu este forțată, deoarece bazele de date native XML nu pot identifica acești pointeri. Integritatea referențială a pointerilor interni care folosesc un mecanism standard, cum ar fi ID/IDREF sau key/keyref, este cel puțin parțial suportată prin validare.

Motivul pentru care acest suport este parțial este că majoritatea bazelor de date native XML execută validări numai când un document este introdus în baza de date. Astfel, dacă sunt efectuate actualizări la nivel de document – prin ștergeri și apoi înlocuiri a unui document – validarea este suficientă pentru a asigura integritatea pointerilor interni. Dar dacă sunt efectuate actualizări la nivel de nod – inserări, modificări și ștergeri de noduri individuale – atunci baza de date trebuie să mai facă operații în plus, cum ar fi validarea tuturor modificărilor, pentru a garanta integritatea referențială a pointerilor interni.

Integritatea refențială a pointerilor externi nu este suportată, nici de puținele baze de date care suportă pointeri externi. Dacă un pointer extern trimite la o resursă stocată în altă parte în baza de date, nu există motiv pentru a nu se impune integritatea pointerului. Totuși, dacă un pointer trimite la o resursă din afara bazei de date nu este obligatorie impunerea integrității. De exemplu, se presupune că un document conține o legătură XLink care trimite la un document pe un site web extern. Baza de date nu are nici un control asupra existenței documentului extern și astfel nu se poate impune integritatea legăturii XLink.

În viitor, majoritatea bazelor de date native XML probabil vor suporta integritatea referențială a pointerilor interni care folosesc mecanisme standard. Multe baze de date native XML vor suporta anumite tipuri de pointeri externi, ca și pointerii externi care trimit la resurse stocate în aceeași bază de date. Deocamdată în majoritatea cazurilor aplicațiile impun integritatea pointerilor atât interni cât și externi.

Scalabilitate

Ca și bazele de date ierarhice și relaționale, bazele de date native XML folosesc indecși pentru a localiza date. Acest lucru înseamnă că localizarea documentelor și a fragmentelor de documente este legată de dimensiunile indecșilor, nu de dimensiunile documentelor sau de numărul de documente, și de faptul că aceste baze de date pot localiza începutul unui document sau fragment la fel de repede ca și alte baze de date care folosesc aceeași tehnologie de indexare. Astfel, bazele de date native XML vor scala la fel de bine ca și alte baze de date.

Ca și bazele de date ierarhice, dar spre deosebire de cele relaționale, multe baze de date native XML leagă fizic datele înrudite. În special, bazele de date native XML bazate pe text grupează fizic datele înrudite și bazele de date native XML bazate pe modele care folosesc sisteme de stocare particulare folosesc adesea pointeri pentru a grupa date înrudite. Bazele de date native XML bazate pe modele construite pe baze de date relaționale folosesc ca și acestea legături logice.

Deoarece legăturile fizice sunt mai rapide decât cele logice, bazele de date native XML, ca și cele ierarhice, pot recupera date mai repede decât bazele de date relaționale. Astfel, ele ar trebui să scaleze bine din punctul de vedere al recuperării datelor. De fapt, ar trebui să se comporte mai bine decât bazele de date relaționale, deoarece scalabilitatea este legată de o singură căutare indexată inițială, spre deosebire de multiplele căutări necesare în cazul bazelor de date relaționale.

Din păcate, această scalabilitate este limitată. Ca și bazele de date ierarhice, legăturile fizice în bazele de date native XML se aplică numai asupra anumitor ierarhii. Recuperarea datelor în ierarhia în care sunt stocate este foarte rapidă, dar recuperarea acelorași date într-o ierarhie diferită este mai înceată. De exemplu, se presupune că informațiile despre clienți sunt stocate în fiecare ordin de vânzare. Recuperarea acestor ordine de vânzare va fi foarte rapidă, deoarece acesta este ordinul în care datele sunt stocate. Recuperarea unei alte vederi a datelor, cum ar fi o listă cu ordinele de vânzare pentru un anumit client, va fi mult mai înceată, deoarece legăturile fizice nu se mai folosesc.

Pentru a rezolva parțial această problema, bazele de date native XML folosesc foarte mulți indecși, adesea indexând toate elementele și atributele. Dacă acest lucru ajută la scăderea timpului de recuperare a datelor, totuși crește timpul de actualizare, pentru că întreținerea acestor indecși poate fi costisitoare. Aceasta nu este o problemă în medii read-only, dar poate cauza probleme în medii în care se folosesc multe tranzacții.

În cele din urmă, bazele de date native XML scalează mai slab decât cele relaționale în căutarea datelor neindexate. Ambele tipuri de baze de date trebuie să caute secvențial datele în acest caz, dar în cazul bazelor de date native XML este mai greu datorită normalizării mai puțin complete. De exemplu, se caută toate ordinele de vânzări cu o anumită dată și datele nu sunt indexate. Într-o bază de date relațională, aceasta înseamnă citirea tuturor valorilor din coloana OrderDate. Într-o bază de date nativă XML, acest lucru înseamnă citirea fiecărui ordin de vânzare în întregime și căutarea elementului <OrderDate>. Nu numai că se citește conținutul fiecărui element <OrderDate>, dar se citește și conținutul tuturor celorlalte elemente. În bazele de date native bazate pe text, textul trebuie analizat și convertit la formatul dată calendaristică înainte de a putea fi comparat cu data căutată.

Aici se încheie descrierea bazelor de date native XML. Următoarele doua secțiuni tratează două tipuri specializate de baze de date native XML: DOM-uri persistente și sisteme de management ale conținuturilor.

3.4.4 DOM-uri persistente (PDOM-uri)

Un DOM persistent sau PDOM este un tip specializat de bază de date nativă XML care implementează DOM-ul peste un tip de stocare persistentă. Spre deosebire de majoritatea bazelor de date native XML, care pot returna documente ca arbori DOM, arborele DOM returnat de un PDOM este activ (live). Adică, modificările făcute arborelui DOM sunt reflectate direct în baza de date. Dacă modificările sunt făcute imediat sau în urma apelării unei metode ‘commit’ depinde de baza de date. În majoritatea bazelor de date native XML, arborele DOM returnat aplicației este o copie, și modificările sunt făcute în baza de date prin intermediul unui limbaj de actualizare XML sau prin înlocuirea întregului document.

Deoarece arborii PDOM sunt activi, baza de date este de obicei locală, adică este în același spațiu de procesări ca și aplicația, sau cel puțin pe aceeași mașină, deși acest lucru nu este neapărat necesar. Acest lucru este făcut pentru eficiență, deoarece un PDOM peste o bază de date aflată la distanță ar necesita cereri frecvente la un server aflat la depărtare.

PDOM-urile au același rol pentru aplicațiile DOM ca și bazele de date orientate obiect pentru aplicațiile orientate obiect: ele oferă stocare persistentă pentru datele aplicației, și servesc și drept memorie virtuala pentru aplicație. Al doilea rol este foarte important pentru aplicațiile DOM care operează cu documente mari, deoarece arborii DOM pot ușor să depășească documentele XML ca mărime.

3.4.5 Sisteme de management ale conținuturilor

Sistemele de management ale conținuturilor sunt un alt tip specializat de baze de date native XML. Acestea sunt proiectate pentru operarea cu documente scrise de oameni, cum ar fi manualele de utilizare, și sunt construite peste baze de date native XML. Baza de date este în general ascunsă de utilizator în spatele unui ”front end” care oferă caracteristici precum:

Control al versiunilor și al accesului

Motoare de căutare

Editoare XML/SGML

Motoare de publicare pe hârtie, CD sau pe Web

Separarea conținuturilor și a stilurilor

Extinderea în scripturi și programare

Integrarea datelor din baza de date

Termenul de sistem de management al conținuturilor spre deosebire de sistem de management al documentelor reflectă faptul că asemenea sisteme permit în general împărțirea documentelor în fragmente cu conținut discret, cum ar fi exemple, proceduri, capitole, dar și metadate cum ar fi numele autorilor, datele reviziilor, și numerele documentelor, decât să opereze cu fiecare document ca un întreg. Nu numai că astfel se simplifică coordonarea lucrului mai multor scriitori la același document, dar permite și asamblarea unor documente noi din componente care există deja.

CAPITOLUL IV

CONSTRUIREA DOCUMENTELOR XML

4.1 Sintaxa XML

XML este format de fapt din două metalimbaje, ambele descrise în același document. Primul este un set de reguli pentru realizarea de documente XML construite corect, în timp ce al doilea este un set de reguli pentru realizarea unei definiții a tipului documentului XML, sau DTD (Document Type Definition), care permite ca structura documentului XML să se supună unor constrângeri și să fie validată față de acele constrângeri. Distincția dintre aceste două limbaje este deseori neclară, deoarece un document XML complet presupune măcar existența opțională a unui DTD, indiferent dacă acesta este de fapt prezent sau nu. Pentru a complica și mai mult lucrurile, un DTD poate fi compus din două părți, o submulțime internă și o submulțime externă. Aceasta parte studiază documentul XML fără a insista prea mult asupra DTD-ului, deoarece un document XML poate fi creat și fără a face referiri la un DTD. Din motive de performanță, multe documente XML vor fi utilizate fără a le valida în raport cu DTD-ul, chiar dacă DTD-ul este disponibil. În cazul conexiunilor lente, citirea dintr-un DTD situat pe un alt sistem poate fi foarte înceată, iar datorită faptului că un DTD poate conține referințe la alte documente, rezolvarea tuturor referințelor externe poate dura exagerat de mult chiar și în cazul conexiunilor de mare viteză. Utilizatorii sunt obișnuiți ca documentele HTML să fie încărcate incremental, deci pot citi înainte ca documentul să fie încărcat în totalitate, dar analizatoarele XML de validare nu permit afișarea documentului decât în cazul în care acesta este valid, deci documentul va apărea pe ecranul utilizatorului numai în momentul în care este încărcat în totalitate. Acest lucru poate fi supărător. Totuși, fiecare document este creat având în minte un DTD, indiferent dacă DTD-ul este explicit sau nu. Chiar și la crearea documentelor fără un DTD, trebuie să avut în vedere un fel de DTD empiric pe măsură ce este creat documentul, deoarece un DTD descrie o structură de date.

4.2 Descrierea de vocabulare noi cu XML

XML are o natură duală: un metalimbaj care permite descrierea de noi structuri de documente și vocabulare și un limbaj utilizat ca să exprime acea structură și acel vocabular în cazul unui document. Există o diferență clară între un document XML, care poate avea sau nu asociat un DTD exprimat în metalimbajul XML, și un DTD XML. Ele utilizează sintaxe complet diferite pentru a descrie un document XML, unul prin exemplu iar celălalt prescriptiv.

Definițiile tipului documentului XML (DTD-urile) descriu instanțe ale limbajului XML, numite uneori vocabulare XML. Dcumentele XML sunt create utilizând acele limbaje. Din păcate, această diferență se pierde uneori în exprimarea neoficială, iar vocabularele XML particulare și DTD-urile asociate sunt descrise inexact ca ” XML”. Utilizatorul unui limbaj sau vocabular XML poate că nu va vedea niciodată sau poate că nici nu îi pasă de DTD-ul utilizat pentru a descrie aplicația sa, la fel cum miilor de persoane care lucrează în design Web utilizând HTML nu le pasă de W3C HTML 4.0 SGML DTD utilizat în descrierea HTML. De fapt, un DTD poate să nu existe. Nu are o importanță chiar așa mare la nivelul aplicației.

4.3 Avantajele definiției tipurilor documentului

Cu toate că DTD-urile sunt opționale deoarece un procesor XML poate conduce un DTD convenabil dintr-o instanță a XML, existența unui DTD oferă multe avantaje:

• Un DTD descrie organizarea unui document într-un mod care poate fi distribuit cu ușurință.

• Un DTD permite unui proiectant să creeze o transformare robustă dintr-un anumit tip de document XML într-un alt format, pentru afișare sau transfer. Deoarece cu un DTD se cunoaște absolut orice despre documente, se vor putea trata structuri care este posibil să nu existe într-un anumit exemplu, dar sunt permise de tipul documentului, chiar dacă nu au fost întâlnite niciodată până acum.

• Un DTD permite unui analizor care validează să determine dacă un anumit document este sau nu creat în conformitate cu regulile stabilite de autorul specificației. Acest lucru este extrem de important pentru EDI (Electronic Data Interchange – schimb electronic de date) și alte aplicații în care documentele vor fi partajate și utilizate și de alte procese.

• Fără un DTD, un mediu de creare XML nu poate oferi sugestii despre elementele care sunt necesare sau opționale într-un anumit loc și despre atributele pe care le poate conține un anumit element. Meniurile contextuale sau sugestiile pot fi de mare ajutor în accelerarea dezvoltării documentelor și în prevenirea erorilor.

• Fără un DTD, autorul unui manual de creație sau al unui document de stil nu are de unde să știe cum ar trebui construit documentul definit. Un manual de creație este o întrupare a informației exprimate într-un DTD, cu toate că nu este un DTD în sine.

• Specificarea DTD-ului utilizat într-un document identifică versiunea standardului folosit la crearea sa. Când documentele se dezvoltă în funcționalitate și sintaxă, acesta poate fi un indiciu într-o situație nouă.

4.4 Combaterea dezavantajelor definiției tipurilor documentului

Cu toate avantajele lor, DTD-urile ridică și probleme. Ele utilizează o sintaxă diferită de XML, deci construirea unui DTD necesită un alt set de abilități. În plus ca orice descriere tehnică, implicarea în proiectarea unui DTD neavând în vedere aspectul structurii datelor în document poate duce la împotmolirea în detalii atunci când este nevoie de atenție la structura generală. Multe persoane proiectează documente XML utilizând vocabularul XML destinat și apoi utilizează un instrument de extragere automată de DTD-uri pentru a genera un DTD pe baza documentului. După realizarea acestui lucru, DTD-ul poate fi reglat prin adăugări la codul sursă sau prin ajustarea acestuia.

Dar DTD au și următoarele dezavantaje:

• Cu un DTD, un agent utilizator XML care validează necesită cel puțin încă o operație de citire pentru a accesa locația unde este disponibil DTD-ul. Cu toate că plasarea în cache poate reduce performanțele pentru unii utilizatori din rețea, multe utilizări previzibile ale documentelor XML vor face imposibilă utilizarea stocării în cache.

• Un DTD crește cu mult complexitatea analizorului necesar pentru a determina dacă un document poate fi afișat. Pentru unele dispozitive, este posibil ca acest lucru să fie realizabil.

• Unele medii de creare care validează și utilizează un DTD îngreunează salvarea spațiului de lucru la sfârșitul zilei sau restaurarea sa în ziua următoare, cu excepția cazului în care documentul se află într-o stare validă.

• Din punct de vedere teoretic, un DTD este capabil să continue nelimitat citiri externe, deoarece un DTD poate conține alte DTD-uri sau mulțimi de entități. Este posibil ca pentru afișarea unor documente complexe să fie nevoie de foarte mult timp atunci când se utilizează un analizor care validează.

Decizia utilizării unui DTD este un compromis între abilitatea de utilizare fără restricții, obișnuită în HTML – posibilitate de a face aproape tot ce se dorește – și un mediu mult mai structurat. În multe situații, cum sunt cele în care se realizează documente care trebuie să fie general disponibile și sunt create distribuit, trebuie să se respecte strict regulile și este de dorit folosirea unui DTD. În alte cazuri, cum ar fi atunci când se dezvolta un tip de document XML nou, nu este nevoie sau nu este dorită constrângerea strictă și se poate realiza fără un DTD, cel puțin în timpul proiectării inițiale.

Dar după ce dezvoltarea a devenit un produs stabil, este de dorit ca proiectul să poată fi distribuit cu ușurință. Chiar dacă se dorește crearea unui manual de utilizare, un DTD este o metodă simplă de a permite utilizatorilor să își testeze propriile documente pentru a se asigura că au respectat indicațiile pe care le-au citit în manual. În acel moment, se poate considera că DTD-urile oferă o flexibilitate prea mare.

4.5 XML, doar un alt HTML?

XML este un limbaj cu etichete și atribute asemănător cu HTML, dar un HTML transformat atât de mult, încât nu mai poate fi recunoscut. XML este mult mai structurat decât HTML. În timp ce procesoarele HTML acceptă în mod curent cod incorect și diform și încearcă să îi dea sens pe ecran, XML trebuie să se oprească atunci când găsește o eroare fatală, care poate fi aproape orice tip de eroare. Aceasta este într-un fel o întoarcere la primele zile ale prelucrării datelor, când orice eroare din cod era pedepsită cu un vidaj de memorie, (core dump) lângă care se puteau petrece ore întregi în încercarea de a-l descifra.

Totuși pe lângă acest comportament necruțător, XML este cu mult mai puternic. În timp ce HTML se mulțumește cu un număr relativ mic de etichete, XML are un număr de etichete aproape infinit, structurate în aproape orice fel se dorește. Oricum, fundamentele au rămas aceleași, XML reprezentând un pas evolutiv al HTML. Nu numai că un HTML bine făcut este foarte aproape de XHTML – un înlocuitor al HTML care respectă XML – dar un cod HTML 4.0 curat este destul de lizibil ca XHTML 1.0. Deoarece HTML 4.0 a fost structurat ca o aplicație SGML, iar XML este o submulțime a SGML, acest lucru este logic. Diferențele sintactice minore dintre XHTML, un vocabular XML, și HTML, un vocabular SGML, pot fi ajustate automat dacă este nevoie. Autorul unui document XML oferă de obicei un manual de creare sau codare (sau o foaie, pentru DTD-uri mici) descriind etichetele utilizate în aplicația XML, atributele lor, valorile posibile și modul lor de imbricare. Urmărirea unui astfel de manual de codare nu este mai dificilă decât reținerea faptului că o linie de tablou <tr> trebuie să fie imbricată în interiorul unui tablou <table> și nu are, sau nu ar trebui să aibă, sens în afara acelui context. Pentru majoritatea situațiilor, acest lucru este suficient. XML este capabil să ofere autorilor suficient ajutor în învățarea modului de utilizare a unei anumite aplicații, deoarece aceștia sunt încurajați să dea etichetelor nume sugestive, care să fie ușor de reținut. Autorul unei aplicații ar trebui să furnizeze un manual de creare care să explice în termeni simpli modul de utilizare a aplicației.

Cu toate că orice procesor XML poate spune despre o porțiune de cod dacă este sau nu construit corect, iar un manual poate ajuta la construirea unui document valid, DTD-ul permite verificarea fără ambiguități a codului. Totuși, în funcție de tipul de creare utilizat, acesta poate fi un pas diferit de procesul de editare.

Codul îndeplinește acest ideal în funcție de utilizarea dată numelor etichetelor, totuși între anumite limite:

• Numele de etichete care încep cu șirul “xml”, indiferent de tipul literelor, sunt rezervate; adică, indiferent de situație, nu este permisa crearea lor.

• Numele de etichete care conțin caracterul două puncte pot fi interpretate ca identificatori având asociată o zonă de nume, deci utilizarea celor două puncte în numele etichetelor este puternic combătută și poate fi chiar interzisă.

• Un nume de etichetă trebuie să înceapă cu o “literă”, care în acest context este orice literă sau ideogramă Unicode/ISO/IEC 10646, sau cu o liniuță de subliniere

În continuare, numele unei etichete poate conține orice “literă”, ideogramă sau cifră Unicode/ISO/IEC 10646, caractere de combinare, caractere de extindere, puncte, cratime, spații sau două puncte. De altfel, puține limbi de pe glob au caractere cu care să nu poată începe un nume corect în limba respectivă. Aceste caractere sunt excluse din lista de caractere dacă se află într-o poziție în care pot fi văzute ca “primele” după o cratimă sau un alt separator logic de cuvinte.

Caracterul thailandez mai yamok (arată ca un f întors și fără liniuță), de exemplu, arată ca o literă, dar nu poate fi folosit ca primă literă a unui cuvânt deoarece el semnifică repetarea literei anterioare.

Caracterele de combinare sunt caractere speciale, folosite pentru a accentua un alt caracter, multe dintre ele fiind normalizate la un singur caracter cu accent. Acesta este un avantaj pentru intrările de la tastatură deoarece multe limbi care conțin caractere accentuate permit introducerea utilizând caractere accent speciale “de lățime zero” care se pot atașa la orice alt caracter.

Caracterele de extindere sunt diverse semne de punctuație, cum ar fi (în limbile europene) middle dot, triangular colon și half-triangular colon. Caracterele extinse sunt similare în alte scrieri din lume; nu sunt exacte din punct de vedere alfabetic dar se potrivesc pe undeva.

4.6 Startul în XML

Acest subiect evidențiază mulțimea de deprinderi necesare pentru XML și clarifică numeroasele asemănări dintre XML și HTML:

• XML este sensibil la tipul literelor deoarece majusculele nu reprezintă un concept universal – Dacă s-ar trata literele mari și mici ca fiind echivalente, ar trebui să se facă la fel pentru mii de alte variante de litere în alte limbi, o operație împovărătoare. Unele limbi nici nu au tipuri de litere. De exemplu, în limba ebraică nu există litere mici, iar limba arabă nu face distincție între forma inițială, de mijloc și finală a literelor. Pentru cei care preferă să scrie etichetele cu majuscule și atributele cu litere mici, pentru a le evidenția, aceasta este o știre teribilă. Dar editoarele de cod moderne nu mai acordă o importanță așa de mare acestui lucru ca înainte. De exemplu, precizarea anumitor culori pentru a marca etichete este un lucru obișnuit, deci utilizarea majusculelor este întrucâtva un anacronism istoric, asemenea numerelor de linii în COBOL.

• XML este foarte precis cu privire la imbricarea corectă a etichetelor –Etichetele nu se pot încheia într-un context diferit de cel de început. Deci, dacă se dorește <bold><italics>, fraza evidențiată trebuie închisă cu </italics></bold>, pentru a evita o eroare fatală. Deoarece XML poate referi și include documente XML și fragmente de documente oriunde pe Web, fiecare document XML trebuie să se supună acelorași reguli pentru a nu strica documentele altora.

• XML nu este bine protejat împotriva recursivității – Cu toate că este posibilă stabilirea excluderilor explicite la un anumit nivel, la o structură complexă a unui document este dificilă menținerea acelor excluderi la un nivel redus, mai ales atunci când se utilizează etichete care pot fi aplicate la orice nivel. Deci, interdicția HTML referitoare la includerea unei etichete ancoră <a> în interiorul altei etichete ancoră există și în XML, dar nu este impusă dincolo de includerea directă.

• XML obligă la închiderea fiecărei etichete, chiar și a etichetelor vide – Deoarece este posibila crearea unui document XML care să nu utilizeze un DTD, un procesor XML nu are de unde să știe dacă o etichetă este sau nu vidă. Deoarece toate documentele XML trebuie să fie construite corect, etichetele vide trebuie marcate cu o sintaxă specială care spune unui procesor XML că eticheta este vidă și închisă. Acest lucru se realizează plasând un spațiu și un caracter slash la sfârșitul etichetei, astfel:

Există o sintaxă alternativă, care este la fel de bună pentru procesoarele XML reale, dar blochează frecvent browserele Web atunci când este utilizată cu XHTML; aceasta cere ca o etichetă vidă, cum ar fi , să fie închisă cu , astfel:

Din păcate, este prea periculoasă pentru a fi utilizată în siguranță. Multe browsere actuale și majoritatea celor moștenite nu recunosc eticheta de închidere non- HTML și fac lucruri ciudate cu ea. Navigator 4.7, de exemplu, poate zăpăci afișarea atunci când se împiedică de o etichetă . Comportamentul exact poate diferi în funcție de poziția în cod și de eticheta vidă care se închide. Pe scurt, această sintaxă este predispusă la erori și ar trebui evitată.

• XML necesită încadrarea valorilor atributelor fie între apostrofuri, fie între ghilimele – Acolo unde HTML este indulgent, mai ales în ceea ce privește numerele și aproape orice șir fără spații în interior, XML tratează totul ca șir de caractere și lasă aplicația să își dea seama singură de toate acestea.

• XML recunoaște mai multe limbi – Spre deosebire de HTML, seturile de caractere extinse utilizate în multe limbi europene nu sunt pe deplin recunoscute în mod prestabilit. Există un mecanism simplu pentru includerea acestora, precum și a întregului set de caractere Unicode (cunoscut, de asemenea, și ca ISO/IEC 10646) care are peste un milion de caractere, deci suportul pentru chineză, arabă și multe alte limbi mai exotice ale lumii este un lucru ușor. În afară de diferențele menționate în această listă, XML este foarte asemănător cu HTML din punctul de vedere al marcării etichetelor, al argumentării atributelor și al trecerii conținutului între perechi de etichete.

Limbajul XML a fost proiectat astfel încât să fie transparent la utilizare pentru a putea fi înțeles și utilizat cu ușurință. Descrierile XML succinte sau complicate din majoritatea documentelor sunt greu de înțeles în efortul de a fi explicit într-un mod în care programatorii să îl poată translata cu ușurință în aplicații care să funcționeze.

4.7 Definirea unui document XML ca întreg

Un document XML este o colecție de entități care pot fi sau nu analizate. Datele care nu sunt înțelese de un procesor XML, date binare sau date care au sens numai pentru alte aplicații, reprezintă date neanalizate. Datele înțelese de XML, fie ca și caractere fie ca marcaje, sunt date analizate.

Un document XML trebuie să fie construit corect. În Recomandarea XML 1.0 a W3C această situație este descrisă concis prin următoarele cerințe:

• Luat ca întreg, corespunde producției etichetate ca document.

• Satisface toate constrângerile de construire corectă din această specificație (Recomandarea XML 1.0)

• Fiecare entitate analizată, referită direct sau indirect în cadrul documentului, este construită corect.

Prima constrângere spune că pentru a fi construit corect, un document XML trebuie să respecte toate regulile care descriu un document în Recomandarea XML 1.0. Acele reguli spun în primul rând că un document XML trebuie să conțină un prolog și un singur element care formează elementul rădăcină al documentului, împreună cu comentarii opționale și instrucțiuni de prelucrare la sfârșitul documentului, dar, din păcate, analizorul XML nu are cum să spună dacă aceste comentarii și instrucțiuni de prelucrare atașate sunt sau nu atașate documentului. Deoarece ele pot sa fie plasate după eticheta de încheiere, un analizor XML nu poate să spună nici dacă instrucțiunile de prelucrare și comentariile atașate au fost sau nu recepționate. Aceasta contravine regulii generale din XML care spune că un analizor trebuie să fie capabil să indice dacă un document este sau nu complet. Dacă se utilizează instrucțiuni de prelucrare sau comentarii, este preferabilă trecerea lor în prolog unde sunt mult mai în siguranță și nu se pot pierde.

Cea de a doua constrângere spune că documentul respectă constrângerile construirii corecte descrise în document. Una din constrângerile construirii corecte este că entitățile analizate recursiv sunt interzise. Recursivitatea din această interdicție se referă la formarea unei bucle de entități în care o entitate se încorporează pe ea însăși sau o altă entitate care se încorporează pe ea însăși indiferent de nivelul de indirectare. Aceasta mai înseamnă și că un document nu se poate referi la el însuși, nici măcar indirect printr-o entitate externă. El se poate referi la o entitate externă numai dacă aceasta nu se referă la ea însăși, chiar și indirect. Este posibil ca analizoarele care nu validează să nu depisteze această eroare, dar aceasta este totuși o eroare. Din punct de vedere logic este evident că dacă documentul A conține documentul B, definindu-l pe B ca și când l-ar conține pe A se generează o buclă infinită. Bucla infinită este interzisă.

În termeni XML, construcția corectă este o altă modalitate de a spune că un document XML formează un arbore, sau o ramură a unui arbore, adică este complet în sine. Acest lucru este necesar deoarece XML permite construirea de documente mai mari din unele mai mici și reprezintă o cheie a posibilității de utilizare a XML pe Web.

Deși construirea corectă poate fi considerată suficientă deoarece un document construit corect are un DTD care îl descrie, pot fi construite un număr infinit de DTD-uri care, de asemenea, să îl descrie. Deci, pentru validitate totală, un DTD asociat este necesar. Producția documentului este definită în numai două afirmații, preluate din nou din Recomandarea XML 1.0:

• Conține unul sau mai multe elemente.

• Există un singur element, numit rădăcină sau element document, care să nu aibă nici o parte a sa în conținutul oricărui alt element. Pentru toate celelalte elemente, dacă eticheta de pornire se află în conținutul unui alt element, atunci și eticheta de încheiere se află în conținutul aceluiași element. Exprimat mai simplu, elemente delimitate de etichete de pornire și încheiere sunt imbricate corect unele în altele.

Prima afirmație spune că într-un document trebuie să existe cel puțin un element sau, altfel spus, un document construit corect nu poate fi vid.

Cea de a doua afirmație spune că, într-un sens restrâns, un document trebuie să fie un arbore. El nu poate fi o rețea conectată arbitrar sau să aibă orice altă topologie care nu se reduce la un arbore simplu. El trebuie să fie complet pentru a putea vedea diferența dintre o descărcare reușită și una parțială.

Din punct de vedere tehnic, un arbore este un graf conex care nu conține circuite. Cu alte cuvinte, un arbore se ramifică de la rădăcina sa fără a se mai conecta la el însuși, deci nu conține muchii multiple sau bucle. Orice lucru care conține bucle sau muchii multiple, nu este un arbore, ci altceva, și nu poate fi reprezentat în XML. Un efect secundar interesant este acela că într-un arbore se poate alege arbitrar un punct, și se poate transforma un nod într-o rădăcină, reorganizând arborele într-un alt arbore, cu o altă ordine de parcurgere. Aceasta ilustrează caracterul capricios al schemelor de clasificare.

O descărcare parțială este posibilă în HTML, deoarece HTML nu are nevoie de eticheta de încheiere </html>, sau nu are nevoie de aproape nici o etichetă de încheiere. Uneori browserul poate detecta întreruperea, dar acest lucru nu este garantat. Aceasta însemnă că un document parțial se poate deghiza într-unul complet, iar utilizatorul nu are de unde să știe acest lucru până când în text nu apare o eroare evidentă. XML previne aceste probleme, lucru care poate fi important în cazul în care un utilizator reclamă ulterior că o convenție de acordare a licenței, de exemplu, nu a fost afișată în întregime. Insistând asupra unui arbore complet, un astfel de exemplu fiind prezentat în Figura 1, se elimină aceste probleme posibile.

Figura 1

Pe de altă parte, un graf care nu formează un arbore nu poate fi transformat într-un document XML decât dacă graful poate fi simplificat, eliminând toate caracteristicile care nu sunt reprezentative pentru arbori. În Figura 2, de exemplu, graful din stânga poate fi simplificat prin eliminarea unei căi de la frunza de sus către un nod. În aceeași figură, grafului din partea dreaptă trebuie să i se elimine o rădăcină deoarece un document XML poate avea o singură rădăcină.

4.8 Prologul: declarația XML

Fiecare document XML, ar trebui să înceapă cu o declarație XML care identifică fișierul ca fiind un fișier XML și identifică, de asemenea, versiunea XML utilizată în documentul respectiv. Caracterul opțional este datorat numai faptului că pe Web există multe fișiere HTML și SGML care corespund perfect unui document XML construit corect. De asemenea, declarația XML este locul unde se declară codificarea și dacă documentul este sau nu autonom. Ordinea din fragmentul următor este obligatorie cu toate că atributele encoding și standalone sunt ambele opționale.

<?xml version=”1.0” encoding=”ISO-8859-1” standalone=”yes”>

Codificările permit identificarea cărui dintre multiplele seturi de caractere va fi utilizat în document. Acest lucru este important deoarece, spre deosebire de HTML, care implică ASCII, și obligă la folosirea numelor ASCII, XML permite vorbitorilor de Hindi, de exemplu, să utilizeze codificarea lor și să facă textul și mediul de editare lizibil și pentru persoanele obișnuite care pot fi autori XML. Sau, un autor chinez poate să prefere caracterele chinezești în etichete și în conținut cu câteva limitări bazate pe regulile limbajului în sine, se pot utiliza moduri de scriere și ideograme atât în numele etichetelor cât și în conținut.

4.9 Documente autonome

În conformitate cu Recomandarea XML 1.0 a W3C, “Documentele autonome nu au declarații de marcare externe care să afecteze informația XML transferată de procesorul XML unei aplicații”. Acesta este un mod extraordinar de succint și obscur de a spune că standalone=”yes” înseamnă că:

• Într-un DTD extern nu există valori prestabilite declarate ale atributelor care să nu fie setate explicit în document.

• Nu sunt utilizate alte entități în afară de &, <, >, ', și ", care nu au fost declarate local sau poate citite prin referință dintr-un fișier.

• Nu există elemente care să aibă ca și conținut numai spații albe de orice natură.

• Nu există atribute externe care trebuie normalizate, deci conținutul atributelor nu poate conține spații albe, caractere sau referințe la entități. Aceasta nu înseamnă că documentul nu are nimic extern. Aceasta înseamnă în special că, indiferent de locul în care un procesor XML care nu validează se oprește din citirea documentelor externe, se oprește prelucrarea tuturor declarațiilor. Toate aceste lucruri se pot face dacă și numai dacă sunt puse în submulțimea DTD-ului intern. Datele externe care nu sunt marcaje nu fac subiectul acestei afirmații. Deci, pot exista fișiere grafice, fișiere text incluse și orice altceva, atât timp cât ele nu sunt marcaje și au fost declarate în submulțimea DTD-ului intern. După toate acestea, procesorul XML nu trebuie să anunțe aplicația dacă documentul este sau nu autonom. De fapt, procesorul nu trebuie să facă nimic cu această informație și nici să se comporte într-un anumit fel atunci când întâlnește această informație.

În mod fundamental, proiectantul DTD-ului trebuie să descifreze dacă documentul creat utilizând acel DTD poate fi sau nu autonom și să comunice acest lucru oamenilor inclusiv autorilor. Autorii care știu că DTD a fost proiectat pentru a fi autonom sau cei care au convertit un document care nu a fost proiectat să fie autonom în acest format, pot insera stanalone=”yes” în declarația lor XML ca o documentație a acelui fapt:

<?xml version=”1.0” standalone=”yes” ?>

Documentele care nu sunt autonome pot fi convertite prin algoritmi la documente autonome, automat, presupunând că este disponibilă o facilitate care să realizeze acest lucru, sau manual în caz contrar.

4.10 Construirea prologului unui document XML: Declarația tipului documentului (Document Type Declaration)

Prologul unui document XML conține mai multe instrucțiuni. Prima, declarația XML, afirmă că documentul următor este XML. Cea de a doua, declarația tipului documentului (Document Type Declaration), este metoda utilizata pentru a identifica definiția tipului documentului (Document Type Definition – DTD) folosită de un anumit document. Faptul că acronimul DTD poate fi aplicat la Document Type Declaration este o coincidență nefericită. DTD se referă numai la Document Type Definition. Într-un document XML poate exista o singură declarație a tipului documentului, deci este introdusă chiar în instanța documentului. Deoarece pot fi combinate mai multe DTD-uri pentru a forma un singur document, aceasta permite controlul încărcării DTD-urilor în fiecare document.

Declarația tipului documentului (DOCTYPE) are două părți, ambele opționale. Prima se referă la un DTD extern, și utilizează cuvinte cheie PUBLIC sau SYSTEM pentru a identifica o intrare dintr-un catalog, respectiv un URI. În cazul în care cataloagele nu sunt implementate în procesorul XML, se pot specifica ambele părți deodată, fără cel de al doilea cuvânt cheie:

<!DOCTYPE nume-document PUBLIC “{catalog id}”>

<!DOCTYPE nume-document PUBLIC “{catalog id}” “{uri}”>

<!DOCTYPE nume-document SYSTEM “{uri}”>

Cea de a doua parte opțională a declarației DOCTYPE permite introducerea submulțimii interne a unui DTD direct în document. Există restricții severe cu privire la genul de informație care poate fi introdusă în DTD-ul intern, dar oricum se pot face destul de multe. Submulțimea internă a unui DTD este încadrată între paranteze drepte, astfel:

<!DOCTYPE nume-document [ {declarațiile DTD-ului intern} ]>

De asemenea, cele două pot fi combinate, permițând adăugarea anumitor tipuri de declarații și entități aproape în orice mod:

<!DOCTYPE nume-document PUBLIC “{catalog id}” “{uri}” [ {declarațiile DTD-ului intern} ]>

Pentru claritate, submulțimea internă este evidențiată ca mai jos:

<!DOCTYPE nume-document PUBLIC “{catalog id}” “{uri}” [

{declarațiile DTD-ului intern}

]>

Declarația DOCTYPE trebuie să utilizeze numele elementului rădăcină al DTD-ului fie acesta intern sau extern, ca fiind câmpul etichetat nume-document din exemplele anterioare. Deci dacă numele elementului rădăcină al DTD-ului este Dave, declarația DOCTYPE ar trebui să înceapă astfel:

<!DOCTYPE Dave …>

Manualul de codare indică autorilor ce trebuie trecut în DOCTYPE. Un proiectant DTD ar trebui să furnizeze un astfel de document sau o foaie de codare fiecărui autor. De asemenea, se poate crea un DTD master care apelează părțile DTD necesare, lucru care seamănă cu comenzile dintr-un meniu. Atunci când se obține o combinație de funcționalități care permite crearea structurii documentului de care este nevoie, se poate publica DTD-ul rezultat și înlătura neplăcerea refacerii pentru fiecare document nou.

4.10.1 Crearea corpului documentului

Un document XML este alcătuit din text, care de obicei este format dintr-un amestec de marcaje și date caracter. Prologul conține numai marcaje, dar nu aceasta este partea interesantă, deoarece este nevoie de date care să însoțească marcajele care, altfel, nu ar fi decât niște cutii goale ce așteaptă să fie umplute. Corpul documentului conține aproape tot ceea ce contează din perspectiva unei aplicații împrăștiate generos în cadrul marcajelor.

4.10.2 Date caracter

Un DTD poate declara multe tipuri de date care să poată fi utilizate într-un document, dar tipul de date prestabilit este întotdeauna CDATA, pentru date obișnuite de tip caracter. Foaia sau manualul de codare indică ce tip de dată poate fi introdus în fiecare atribut sau câmp cu conținut element. Presupunând că tipul de date este CDATA, în câmp se poate pune aproape orice se dorește atât timp cât nu conține un marcaj în afara unei secvențe escape.

Este pe deplin posibilă construirea unui DTD care să nu conțină text în interiorul elementelor. În schimb, se pot pune datele semnificative în interiorul atributelor asociate fiecărui element, care pot fi toate declarate ca fiind vide sau având numai conținut element. Acest lucru se face uneori pentru a converti un document utilizând un standard de codificare cum ar fi MARC, care este în esență un format binar, la XML.

4.10.3 Marcajul

Marcajul este format din ansamblu de date non-caracter dintr-un fișier XML. Diversele forme pe care le poate lua un marcaj sunt prezentate în tabelul următor:

Tabel 1 Sintaxa marcajului XML

Toate celelalte sunt date de tip caracter.

Marcajul începe întotdeauna fie cu caracterul <, caz în care se încheie întotdeauna cu caracterul >, fie cu caracterul &, caz în care se încheie întotdeauna cu caracterul “;”.

4.10.4 Formarea structurilor logice în XML

Imbricarea elementelor este singurul mecanism utilizat pentru a arăta structura logică dintr-un document XML. Etichetele de pornire și încheiere din fluxul de text spun procesorului XML că a fost întâlnit un nod. Dacă procesorul XML întâlnește o altă etichetă de pornire înainte de eticheta de încheiere corespunzătoare, atunci procesorul știe că acesta este fie un nod nou în arbore, fie o frunză. Dacă nu găsește o nouă etichetă de pornire și întâlnește o etichetă de încheiere, atunci procesorul știe că aceasta este o frunză și că poate acționa iterativ la acel nivel al arborelui până când întâlnește o altă etichetă de pornire sau de încheiere. Prelucrarea acționează treptat, bazându-se pe această regulă simplă. Dacă procesorul validează documentul, atunci fiecărui nod i se poate asocia o regulă care să determine ce tip de conținut poate apărea în el. O etichetă vidă este, prin definiție, o frunză, deoarece nu poate avea nici un conținut.

Majoritatea structurilor de date conținute într-un document XML pot fi accesate secvențial fără a construi structura în memorie. O etichetă de pornire începe un nod sau o frunză, iar eticheta de încheiere corespunzătoare îl(o) încheie. Orice etichete întâlnite între o etichetă de încheiere corespunzătoare ei încep un nod sau o frunză nouă. Acest principiu reprezintă baza lui SAX și a altor procesoare XML conduse prin evenimente.

Restul structurii logice a documentului este definit prin atributele asociate fiecărui element. În plus, structura logică poate diferi în funcție de conținutul secțiunilor condiționale din cadrul documentului sau al componentelor sale.

4.10.5 Cum formează XML structurile fizice

Imbricarea entităților este singurul mecanism utilizat pentru a arăta structura fizică dintr-un document XML. Definițiile de entități întâlnite în fluxul de text îi comunică procesorului XML că a fost găsită o altă entitate.

Există multe tipuri de entități, de la entitățile mici care formează caractere individuale, cum ar fi:   (spațiu), până la entitățile externe care permit încorporarea într-un document porțiuni din alte documente XML sau includerea într-un document a referințelor la date neanalizate, cum ar fi fișiere multimedia pentru redarea ulterioară de către un agent utilizator.

Un document XML este o colecție de astfel de entități. Fiecare din aceste subentități trebuie să fie completă în sine. Aceasta înseamnă că, deoarece structura documentului ca întreg trebuie să fie un arbore simplu, fiecare subentitate trebuie să fie un singur nod sau trebuie să fie, de asemenea, un arbore simplu. Structuri mai mari se pot construi prin adăugarea nodurilor sau a arborilor subentitate ca porțiuni ale arborelui mai mare.

4.10.6 Etichete de pornire și etichete de încheiere

În XML sunt utilizate două tipuri de etichete, etichete cu conținut și etichete vide. Etichetele cu conținut trebuie să aibă o etichetă de pornire și o etichetă de încheiere. Eticheta de pornire conține numele elementului încadrat între paranteze unghiulare, având opțional atribute ca argumente. Eticheta de încheiere conține numele elementului precedat de caracterul slash, totul fiind încadrat între paranteze unghiulare. În eticheta de încheiere nu puteți trece atribute. Codul următor reprezintă o etichetă cu conținut:

<titlu subtitlu=”0 călătorie acasă” >Dus-întors</titlu>

Seamănă mult cu etichetele HTML standard și nu ar trebui să ridice alte probleme în afara celei de construire corectă, care cere ca ele să se imbrice într-adevăr una în cealaltă. Nu pot exista etichete care să alterneze între ele ca în acest exemplu greșit construit:

<bold><italic>TEXT ACCENTUAT</bold></italic>

Cu toate că este o eroare obișnuită în HTML, XML este cu mult mai pretențios și nu va permite această construcție. Etichetele trebuie imbricate corect, după cum se vede în exemplul următor:

<bold><italic>TEXT ACCENTUAT</italic></bold>

Acum etichetele sunt imbricate corect. Trebuie închisă fiecare etichetă care începe în contextul unei anumite etichete (sau a mai multor etichete) înainte de închiderea contextului etichetei respective.

Etichetele vide au disponibil un format special, cu toate că aceeași schemă, etichetă de pornire/ etichetă de încheiere, poate fi utilizată atâta timp cât se ține cont de faptul că nu trebuie pus nici un fel de conținut între eticheta de pornire a elementului vid și eticheta de încheiere care urmează imediat după ea. De asemenea, poate exista preocuparea că este posibil ca documentul XML să fie vizualizat cu un browser Web obișnuit, deoarece etichetele de încheiere pentru elementele care arată ca etichete HTML vide pot duce la blocarea browserului sau la un comportament ciudat al acestuia. Totuși, pentru utilizare generală, formatul special este mnemonic în sine, un avantaj deoarece se poate vedea că eticheta este vidă și nu blochează aproape nici un browser. De obicei, etichetele vide sunt pornite și încheiate în cadrul aceleiași perechi de paranteze unghiulare, plasând după numele elementului și toate atributele sale posibile un spațiu, un caracter slash și apoi paranteza unghiulară închisă:

4.10.7 Normalizarea

Normalizarea este un cuvânt excentric pentru aducerea lucrurilor la cel mai mic numitor comun și punerea lor într-un fel de formă canonică. În contextul XML, el se referă la procesul rezolvării referințelor la entități în locații în care pot apărea astfel de referințe, la aranjarea rândurilor noi pentru a lua în considerare diversele metode de tratare a lor de către diferite sisteme de operare și la ordonarea altor lucruri care trebuie făcute în anumite situații.

Proiectantul rareori trebuie să se preocupe de normalizare, excepție făcând cazurile negative. Analizorul XML ar trebui să realizeze toate normalizările necesare, deci singurul lucru la care trebuie să se gândească creatorul documentului este dacă normalizarea va afecta sau nu datele sale atunci când se va face trecerea de la forma nenormalizată și invers. S-a dovedit că există două locuri în care pot fi întâlnite spații albe: în datele de tip caracter din cadrul documentului și în datele de tip caracter atribuite atributelor elementelor. În primul caz, în entitățile analizate este dificil să se facă distincție între spațiile albe “semnificative” și cele nesemnificative. Pentru proiectanți, cea mai bună cale pare să fie transferul către aplicație al tuturor spațiilor albe împreună cu cea mai bună presupunere a procesorului, bazată pe DTD, referitoare la datele care sunt în mod sigur nesemnificative și la cele nesigure. Acest transfer de răspundere are sens deoarece aplicația este cea în măsură să știe cum să procedeze cu spațiile albe suplimentare.

Procesorul XML poate numai să presupună care spațiu alb este semnificativ și care nu, bazându-se pe ceea ce a fost definit în DTD sau în orice alt limbaj de scheme utilizat. O aplicație trebuie să fie pregătită să trateze presupunerile eronate. Cu tratarea sfârșiturilor de linie, o altă formă de spații albe, există o altă problemă. Liniile noi sunt tratate diferit pe sisteme diferite. Alternativele generale sunt un salt la linie nouă (UNIX), un return (MacOS) și atât un return cât și saltul la linie nouă (MS Windows). Un alt lucru obișnuit pentru aplicații este, de asemenea, inserarea de secvențe contradictorii cu oricare dintre acestea, în orice ordine, atunci când întâlnesc un fișier dintr-un sistem străin. W3C a hotărât că nu poate face totul și a ales un set rezonabil de reguli. Dacă analizorul întâlnește fie 
 (return , salt la linie nouă), fie (return), el le înlocuiește cu &#0A; (salt la linie nouă), caracterul de linie nouă UNIX.

Microsoft și Apple au ales mecanisme diferite pentru separarea liniilor, Microsoft alegând tehnica “curea și bretele” obișnuită pentru teleimprimatoare, utilizând un return și apoi un salt la linie nouă pentru a indica o linie nouă. Apple a hotărât că saltul la linie nouă era redundant și a considerat că un singur return este suficient, modelat probabil după comportamentul unei mașini de scris obișnuite. UNIX a utilizat de la început un singur salt la linie nouă pentru a realiza același lucru, iar acesta a fost standardul convenit pentru XML. În atribute există o secvență de transformare standard și apoi o prelucrare

adăugată special pentru orice în afară de CDATA:

• Referințele la caractere sunt prelucrate prin adăugarea caracterului referit la valoarea de ieșire a atributului.

• Referințele la entități sunt procesate prin prelucrarea recursivă a textului de înlocuit al entității.

• Spațiile albe, #x20 (spațiu), #x0D (retur de car), #x0A (salt de linie nouă) și #x09 (tab orizontal) sunt prelucrate prin adăugarea lui #x20 (spațiu) la valoarea normalizată a ieșirii excepție făcând faptul că se adaugă un singur #x20(spațiu) pentru secvența “#x0D#x0A” (retur de car, salt la linie nouă), care este parte a unei entități externe analizate sau valoarea entității literale a unei entități analizate interne.

• Celelalte caractere sunt prelucrate prin adăugarea lor la valoarea normalizată a ieșirii.

• Dacă tipul de dată al atributului nuI este CDATA, cel prestabilit, atunci se aplică încă o transformare. Spațiile din față și din spate sunt eliminate, iar spațiile multiple sunt comasate într-un singur spațiu. Diferența dintre cele două tipuri de normalizare constă în faptul că se pot transfera în mod convenabil șiruri lungi într-un atribut, restrânge linii astfel încât să încapă în pagină, iar în final conținutul elementului să rămână relativ curat.

4.10.8 Tipuri de elemente

În mod surprinzător, la validare nu este o eroare utilizarea unui element de un tip care nu a fost declarat, cu toate că este posibil ca analizorul să emită un advertisment. De fapt, permițând în interiorul unor elemente alte tipuri de elmente nedeclarate, indiferent de ceea ce spune modelul lor de conținut, se poate suplimenta DTD-ul unui document cu elemente din alte zone de nume. Deci, tot ce rămâne de făcut este utilizarea elementului nedeclarat într-o manieră exactă, construită corect, identificând pe cât posibil zona de nume de unde provine. În termeni XML, a fi construit corect este un alt mod de a spune că acel element formează un arbore sau o ramură a unui arbore care este completă în sine. Acest lucru este necesar deoarece XML permite construirea de documente mai mari din unele mai mici și este un element cheie pentru utilizarea XML pe Web. Fiecare element dintr-un document XML valid a fost definit în DTD-ul asociat acelui document prin declarația DOCTYPE. DTD-ul declară următoarele:

• Numele efective ale elementelor

• Regulile utilizate pentru a determina care elemente se pot imbrica în alte elemente și în ce ordine

• Atributele posibile și valorile lor prestabilite sau constante

• Valorile caracter ale tipurilor enumerate

• Entitățile neanalizate utilizate în document și modul în care sunt referite prin nume

• Codificările de limbă utilizate în document

• Alte informații importante pentru prelucrarea și redarea documentului

Respectând aceste reguli se pot crea documente în concordanță cu șablonul pe care proiectantul documentului l-a avut în minte atunci când a creat DTD-ul. Într-un mediu care nu validează se pot crea etichete și atribute pe măsura înaintării. Foaia sau manualul de codare afișează toate acestea într-un format ușor de citit și înțeles, dacă autorul DTD-ului și-a făcut treaba corect. Când se creează un document XML sau se corectează o eroare, este posibil să nu se beneficieze de avantajul unui mediu de creare complet. Este întotdeauna importantă păstrarea la îndemână a documentației de codare pentru cazul în care apar defecțiuni.

4.10.9 Entități neanalizate

O entitate neanalizată este orice lucru care nu poate fi recunoscut de un procesor XML, fie date binare, cum ar fi un fișier imagine sau audio, fie text care trebuie să fie transferat unei aplicații fără a fi prelucrat în vreun fel. HTML utilizează comentarii pentru a ascunde un astfel de text de browserul HTML, dar XML are câteva mecanisme care funcționează mult mai sigur.

O entitate neanalizată trebuie mai întâi să fie declarată ca NOTATION, o declarație specială care numește o aplicație de asistență care știe cum să lucreze cu entități de un anumit tip. Notației îi este dat un nume, un identificator public opțional și apoi numele mai puțin opțional al aplicației de asistență, ca în una din variantele următoare:

<! NOTATION nume-mnemonic PUBLIC “identificator-public”>

<! NOTATION nume-mnemonic PUBLIC “identificator-public” “nume-aplicație.exe”>

<! NOTATION nume-mnemonic SYSTEM “nume-aplicație.exe”>

Prima opțiune funcționează numai dacă există un catalog. Nu se poate pune baza pe un catalog deoarece acesta funcționează indiferent dacă există sau nu catalog. Nu se poate baza pe un catalog deoarece acesta este un instrument SGML pe care multe procesoare XML actuale l-au moștenit implicit de la predecesoarele lor SGML. Studierea catalogului nu este specificată în recomandarea W3C și nu se poate conta niciodată pe ea. Dacă este posibil, se recomandă utilizarea ultimele două versiuni. Pe de altă parte, codarea hard a informațiilor despre locația și identitatea aplicației de asistență în absolut fiecare DTD este un anacronism predispus la erori pe Web.

Prin redefinirea comportamentului script-urilor în prezența comentariilor, proiectanții XML-ului au introdus o problemă de incompatibilitate între XML și HTML. După toate probabilitățile, procesoarele XML vor continua să transfere comentarii la aplicații deoarece multe pagini se vor întrerupe dacă nu vor avea acest comportament. De asemenea, procesoarelor le este permis transferul informației comentate prin același limbaj prin care li se permite să nu o facă. După ce o notație a unei entități neanalizate a fost definită, ea trebuie să fie declarată ca o entitate, astfel:

<! ENTITY nume-mnemonic NDATA nume-mnemonic>

și apoi trecută ca un atribut într-un element pentru a o putea utiliza:

<! ELEMENT name EMPTY>

<! ATTLIST name type NOTATION “mnemonic”

…>

Numele mnemonice nu împart aceeași zonă de nume, deci nu are importanță dacă ele sunt identice. În acest moment se poate utiliza tipul de date definit astfel. Tipul de date poate fi utilizat numai ca atribut al unui element declarat ca fiind de acel tip sau având acel tip disponibil într-o enumerare. Celelalte atribute adună informațiile de care are nevoie aplicația de asistență externă pentru a fi capabilă să prelucreze datele. O aplicație tipică poate fi un fișier imagine:

Acest element va necesita în DTD următoarele declarații:

<! NOTATION gif89a PUBLIC “-//CompuServe//NOTATION Graphics Interchange

Format 89a//EN” “explorer.exe”>

<! ENTITY gif89a NDATA gif89a >

<! ELEMENT image EMPTY>

<! ATTLIST image source CDATA #REQUIRED

alt CDATA #IMPLIED

type NDATA gif89a >

Pentru majoritatea instrumentelor, nu va avea importanță dacă formatul este specificat ca gif87a sau ca gif89a, deoarece aceleași instrumente manevrează ambele formate.

Notațiile vor fi mult îmbunătățite o dată cu adăugarea facilităților oferite de XLink/XPointer care ajută la urmărirea locațiilor asistenților. Cu instabilitatea generală a Web-ului la nivelul său actual și cu larga varietate de facilități și arhitecturi de pe sistemele utilizatorilor, orice ajutor care poate fi obținut de către utilizator va face mai ușoară configurarea instrumentelor XML. DTD-ul, în forma sa actuală, necesită mult prea multă ajustare în stil UNIX a fișierelor pentru a fi pe placul utilizatorilor obișnuiți. XLink și XPointer încearcă să învingă limitările tehnologiei pointer actuale. Permit toate tipurile de relații, inclusiv pointeri inverși care să fie generați pe loc în documente fără acces la scriere, realizând-uși efectul chiar asupra copiei afișate, și nu prin inserarea fizică brută a etichetelor în conținut.

Cerințele XML pentru notații, în forma actuală, sunt extrem de severe.

Posibilitatea de a indica locația unde se află aplicația de asistență poate fi comodă pentru notații neobișnuite sau foarte specializate. Totuși, este de așteptat ca agentul utilizator să știe cum să afișeze multe dintre tipurile mai obișnuite, cum ar fi GIF-uri, JPEG-uri, PNGuri, WAV-uri și alte tipuri de fișiere binare mai mult sau mai puțin standard, utilizate pe Web. Iată o listă a notațiilor obișnuite:

<! NOTATION eps PUBLIC “+//ISBN Ǿ-201-18127-4::Adobe//NOTATION

Postscript Language Reference Manual//EN”>

<! NOTATION tex PUBLIC “+//ISBN Ǿ-201-13448-9::Knuth//NOTATION The

TeXbook//EN”>

<! NOTATION cmgchar PUBLIC “ISO 8632/2//NOTATION Character encoding //EN” >

<! NOTATION cmgbinary PUBLIC “ISO 8632/3//NOTATION Binary encoding //EN” >

<! NOTATION cmgclear PUBLIC “ISO 8632/4//NOTATION Clear text encoding //EN” >

<! NOTATION tiff PUBLIC “ISO 12083:1994//NOTATION TIFF-1 //EN” >

<! NOTATION jpeg PUBLIC “ISO/IEC 10918:1983//NOTATION Digital Compresion and Encoding of

Continuous –tone Still Images (JPEG)//EN” >

<! NOTATION gif87a PUBLIC “-//CompuServe //NOTATION Graphics Interchange Format 87a//EN”

>

<! NOTATION gif89a PUBLIC “-//CompuServe //NOTATION Graphics Interchange Format 89a//EN”

>

<! NOTATION fax PUBLIC “-//USA-DOD//NOTATION CCITT Group 4 Facsimile Type 1 Untiled

Raster//EN” >

Desigur, va trebui să se adauge un ID sistem pentru a le putea utiliza, fie ca pointer la o aplicație de asistență locală, fie în fișierul catalog care centralizează locațiile acestor aplicații, dacă este disponibil pentru instrumentele folosite.

4.10.10 Aplicații din lumea reală

S-au văzut deja, mai sus, unele dintre instrumentele care pot fi utilizate pentru a crea un document XML, dar unde se pot găsi DTD-urile? Multe DTD-uri se află în domenii publice sau sunt disponibile ca standarde de la ISO, ANSI sau de la alte organisme de standardizare. Câteva dintre aplicațiile mai importante ale XML care se afirmă în lumea de azi sunt:

• Health Level-7 (HL7), Standardul informatic de sănătate (Health Informatics Standard) a fost introdus în anul 1987 pentru a dezvolta standarde pentru schimbul electronic de informații clinice, financiare și administrative între sistemele de calcul din domeniul sănătății. HL7 s-a concentrat asupra utilizării SGML și XML ca mecanisme de transport între diferite sisteme informatice din domeniul sănătății.

• Real Estate Transaction Standard (RETS – standardul de tranzacții imobiliare) este o metodă bazată pe XML pentru schimbul de informații referitoare la tranzacțiile imobiliare. Un standard concurent este Real Estate Markup Language (RELML – limbajul de marcare pentru domeniul imobiliar) care utilizează DTD-urile XML pentru a prezenta listinguri cu spații pentru locuințe, spații comerciale și terenuri virane, pentru publicarea lor pe Web.

• RosettaNet, limbajul comun pentru afaceri, este o inițiativă EDI/E-Commerce destinată intermedierilor în domeniul calculatoarelor.

• MathML și CML sunt două standarde XML științifice care permit matematicienilor să editeze ecuații, iar chimiștilor să prezinte formule chimice.

• SMIL, the Synchronized Multimedia Integration Language (limbajul de integrare multimedia sincronizat), este HyTime for Everyman (HyTime pentru fiecare), un limbaj de marcare multimedia care permite furnizorilor de conținut să realizeze prezentări audio și video complexe.

• ICE, Information and Content Exchange (schimb de informații și conținut), cu toate că nu este chiar o aplicație XML, fiind de fapt un mecanism de transport, permite schimbul de investiții on-line și informații personale pe Web.

• SAE J2008 este un sistem de comenzi și inventariere bazat pe XML pentru industria auto; MISTI, the Missile Industry Supply-chain Transaction Infrastructures, face același lucru pentru industria spațială.

• Chinese DTDs furnizează structura specializată necesară pentru publicarea în limba chineză. DTD-uri similare există pentru japoneză, coreeană, vietnameză și multe alte limbi.

• GedML, un standard XML genealogic, încurajează fluxul liber pe Web al datelor genealogice. Există deja programe pentru conversia fișierelor standard Genealogical Data COMmunication (GEDCOM) la GedML. Fiecare producător de browsere are standarde propuse, despre care ceilalți se plâng că sunt îndreptate împotriva lor. Așa cum războaiele browserelor au dus la dezvoltarea unor “extensii” patentate la HTML, care tindeau (sau încercau) să blocheze celelalte browsere, creând un turn Babel de metode incompatibile, XML va fi într-o continuă schimbare pentru o bună perioadă de timp. Totuși, bazele există deja, iar o comunitate de utilizatori cerând din ce în ce mai insistent standarde deschise conduce diferitele propuneri spre convergență. Multe dintre succesele majore au fost standarde ale ISO și ANSI, care vând documentația pentru a-și finanța eforturile în crearea de standarde, dar asigură un teren neutru pentru toți partenerii. Pentru prețul documentației, de obicei câteva sute de dolari, toți pot concura la același nivel.

CAPITOLUL V

PREZENTAREA APLICAȚIEI

“ElectronX” este o aplicație „e-commerce”, un site web ce reprezintă un magazin virtual de electronice care se adresează tuturor persoanelor care doresc să achiziționeze diverse produse, în cazul de față electronice, prin intermediul internetului accesând un magazin virtual din confortul propriei locuințe, comerțul electronic mondial având o dinamică ascendentă pe măsură ce tot mai mulți consumatori și tot mai multe afaceri se conectează la web, acest tip de comerț câștigând din ce în ce mai mult teren și în România.

Aplicația se dorește a fi o unealtă folositoare utilizatorilor, avându-se în vedere dezvoltarea interfeței pentru a fi user-friendly, dorindu-se a fi o aplicație cât mai ușor de folosit, eventualele neajunsuri și opinii putând fi aduse la cunoștința administratorului site-ului prin adresele de e-mail puse la dispoziția utilizatorilor în pagina de contact.

Tehnologiile folosite pentru realizarea aplicației sunt PHP pentru generarea dinamică paginilor XHTML și interogarea bazelor de date , și MySql pentru gestionarea bazelor de date, totul rulând pe suportul oferit de serverul Apache.

Realizarea acestui site presupune utilizarea unei baze de date care să conțină atât date despre utilizatori cât și date despre produsele puse în vânzare și date despre comenzile efectuate de către utilizatori. Baza de date va conține șapte tabele cuprinzând informațiile necesare bunei funcționări a aplicației.

5.1 Cerințe hardware

Aplicația nu necesită componente hardware performante.

Cerințele hardware pentru server sunt:

Procesor Pentium IV 2600 MHz

Memorie RAM 512 Mb

Hard Disk 120 Gb

Minimul cerințelor hardware pentru utilizatori consta in:

Procesor Pentium III (AMD Athlon), 800 MHz

Memorie RAM 128 Mb

5.2 Cerințe software

Cerințele software pentru aplicație sunt:

Pentru server:

Wampserver 5, versiunea 1.6.4

Un editor PHP

Pentru client:

Internet Explorer 5.0 si versiunile următoare sau Mozilla Firefox 1.0.7

5.3 Funcționalitățile aplicației

La accesarea site-ului se va deschide pagina principală unde utilizatorul se va putea autentifica prin intermediul unui nume de utilizator și a unei parole. Dacă nu are cont își va putea crea unul nou.

După autentificare utilizatorul poate să modifice datele personale sau parola deschizându-se un formular predefinit unde se pot efectua schimbările dorite.

Utilizatorul poate să acceseze pagina de prezentare a produselor oferite de site de unde își poate alege unul sau mai multe produse pentru a le cumpăra. Produsele alese vor fi adăugate într-un coș de cumpărături acestea putând fi comandate. La trimiterea comenzii datele utilizatorului și produsele comandate sunt reținute în baza de date.

Se poate de asemenea efectua o căutare după nume a produselor, fiind afișate rezultatele căutării în baza de date.

5.4 Proiectarea bazei de date

Baza de date conține șapte tabele.

Tabela Utilizatori conține informații despre utilizatorii înregistrați în sistem.

Tabela Itemi reține datele despre produsele oferite la vânzare.

În tabela Caracteristici sunt reținute caracteristicile fiecărui produs din tabela Itemi

În tabela Categorii sunt stocate datele categoriilor definite pentru ierarhia produselor.

În tabela Coș sunt reținute produsele pe care un utilizator logat dorește să le comande la un moment dat. După trimiterea comenzii sau la ieșirea din cont înregistrările din această tabelă sunt șterse.

Tabela Comenzi conține informații despre toate comenzile efectuate de către utilizatori.

Tabela Itemi_Comanda stochează datele despre produsele comandate.

Structura bazei de date este descrisă în schema conceptuală următoare:

Schema fizică a bazei de date se prezintă astfel:

Utilizatori

Itemi

Caracteristici

Categorii

Coș

Comenzi

Itemi_comanda

5.5 Implementarea codului

După crearea bazei de date, următorul pas este generarea paginilor web ale aplicației folosind codul HTML/PHP.

Pentru editarea codului am folosit utilitarul PHPEdit versiunea 2.10.0.4616 dezvoltate de compania WaterProof Software, acest utilitar putând fi descărcat de pe internet de la adresa http://www.waterproof.fr/ cu o licență de utilizare gratuită pe o perioada de 30 de zile. Acest editor de cod este destinat în special creării scripturilor PHP oferind suport și pentru alte limbaje: HTML, CSS, XML, XSLT, Javascript, SQL.

Sistemul complet are două tipuri de componente: fișiere HTML și fișiere PHP. Interfața aplicației este realizată cu ajutorul paginilor HTLM, iar scripturile PHP gestionează interacțiunea dintre paginile HTML și baza de date prin intermediul serverului Apache.

Inregistrare.php

Atunci când un client nou dorește să achiziționeze unul din produsele oferite de siteul „ElectronX” trebuie să își creeze mai întâi un cont de utilizare. Clientul trebuie să introducă datele personale (nume, prenume, CNP, vârsta, adresa de e-mail, telefon, adresă, oraș, județ ) într-un formular, precum și un nume de utilizator și o parolă. Datele vor fi folosite înregistrarea comenzilor și pentru a deține o evidență a utilizatorilor site-ului. Contul nu va fi creat dacă nu sunt completate toate câmpurile considerate obligatorii. După inserarea datelor în tabela Utilizatori se creează și fișierul clienți.xml în care sunt stocate toate datele clienților înregistrați în baza de date.

$_SESSION['user'] = $_POST['user'];

$_SESSION['parola1'] = $_POST['parola1'];

$_SESSION['parola2'] = $_POST['parola2'];

$_SESSION['nume'] = $_POST['nume'];

$_SESSION['prenume'] = $_POST['prenume'];

$_SESSION['cnp'] = $_POST['cnp'];

$_SESSION['varsta'] = $_POST['varsta'];

$_SESSION['email'] = $_POST['email'];

$_SESSION['telefon'] = $_POST['telefon'];

$_SESSION['adresa'] = $_POST['adresa'];

$_SESSION['sector'] = $_POST['sector'];

$_SESSION['cod_postal'] = $_POST['cod_postal'];

$_SESSION['oras'] = $_POST['oras'];

$_SESSION['judet'] = $_POST['judet'];

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

($_SESSION['parola2'] != $_SESSION['parola1']) || ($_SESSION['nume'] == '')

|| ($_SESSION['prenume'] == '') || ($_SESSION['varsta'] == '') ||

(!is_numeric($_SESSION['varsta'])) || (strlen($_SESSION['varsta']) < 2) ||

($_SESSION['cnp'] == '') ||($_SESSION['email'] == '') || ($_SESSION['telefon'] == '') ||

($_SESSION['adresa'] == '') || ($_SESSION['oras'] == ''))

{

echo '<html>

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>

<center>Va multumim.

Datele au fost introduse cu succes in baza de date.

Pentru a va autentifica apasati <a href= "autentificare.php"> aici </a>.</center>

</body>

</html>';

$cerereSQL = "INSERT INTO `utilizatori` (`utilizator`, `parola`, `nume`, `prenume`, `cnp`,

`email`, `telefon`, `varsta`, `adresa`, `sector`, `cod_postal`, `oras`, `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ă existența numelui de utilizator în baza de date și corectitudinea parolei, și în caz de eroare, aceasta se semnalează. Autentificarea se realizează prin intermediul sesiunilor, reținându-se pentru fiecare utilizator o instanță unică de sesiune.

$_SESSION['user'] = $_POST['user'];

if(($_POST['user'] == '') || ($_POST['parola'] == ''))

{

echo '<html>

<center>Pentru a va accesa contul trebuie sa completati casutele.

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

</center>

</body>

</html>';

}

else

{

$cerereSQL = "SELECT * FROM `utilizatori` WHERE utilizator=' ".htmlentities($_POST['user'])."' AND parola=' ". md5($_POST['parola'])."'";

$rezultat = mysql_query($cerereSQL);

if(mysql_num_rows($rezultat) == 1)

{

while($rand = mysql_fetch_array($rezultat))

{

$_SESSION['logat'] = 'Da';

echo '<META HTTP-EQUIV=Refresh CONTENT="0; URL=pagina.php">';

}

else

{

echo '<html>

Eroare!

<center> Date incorecte.

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

</center>

</body>

</html>';

Pagina.php

După ce utilizatorul s-a autentificat se deschide pagina de administrare a contului de utilizare. În acest script utilizatorul are la dispoziție mai multe opțiuni: modificarea datelor personale, modificarea parolei, sunt afișate toate comenzile trimise de către utilizator, și poate accesa unul din link-urile care duc către paginile de prezentare a produselor, afișare a statisticilor vânzărilor, afișare a coșului de cumpărături sau pentru ieșirea din cont.

Vezimagazin.php

În acest script sunt prezentate toate categoriile și toate produsele existente în baza de date. La deschiderea paginii apare o listă de link-uri cu toate categoriile de produse, iar dacă utilizatorul selectează o categorie se vor afișa toate produsele din acea categorie, pentru fiecare dintre acestea afișându-se numele, prețul și o mică imagine de prezentare.

$get_cats = "select cat_id, nume_cat, desc_cat from categorii order by nume_cat";

$get_cats_res = mysql_query($get_cats) or die(mysql_error()) ;

if (mysql_num_rows($get_cats_res)<1) {

$display_block = " Nu exista categorii de vizualizat ";

} else {

while($cats = mysql_fetch_array($get_cats_res)){

$cat_id = $cats[cat_id];

$cat_title = strtoupper(stripslashes($cats[nume_cat]));

$cat_desc = stripslashes($cats[desc_cat]);

$display_block .= "

<a href=\"$_SERVER[PHP_SELF]?cat_id= $cat_id\"> $cat_title </a>

$cat_desc ";

if ($_GET[cat_id] == $cat_id) {

$get_items = "select item_id, nume_item, pret, imagine from itemi where cat_id=$cat_id order by nume_item"; $get_items_res = mysql_query($get_items) or die(mysql_error());

if (mysql_num_rows($get_items_res) <1) {

$display_block = " Nu exista produse in aceasta categorie ";

} else {

$display_block .= "<ul>";

while($items = mysql_fetch_array($get_items_res)) {

$item_id = $items[item_id];

$item_title = stripslashes($items[nume_item]);

$item_price = $items[pret];

$item_image = $items[imagine];

$display_block .= " <li>

<tr>

<th><a href=\"showitem.php?item_id=$item_id\"> $item_title</a></th>

</tr>

<tr>

</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 afișare a produselor nu face decât sa afișeze toate informațiile referitoare la câte un produs. Aceste informații sunt introduse automat într-un formular. În acest formular utilizatorul mai poate să aleagă numărul produselor pe care dorește să le comande și apoi dacă dorește să-l adauge la coș trebuie să apese pe butonul „Adaugă la coș”.

Aratacos.php

În această pagină este prezentat conținutul coșului de cumpărături. Produsele existente în coș sunt afișate într-un tabel, pentru fiecare fiind afișate numele, producătorul, modelul, prețul, cantitatea, prețul total și un link pentru scoaterea produsului respectiv din coș. Pe pagină mai sunt prezente valoarea totală a produselor adăugate în coș și link-urile către pagina de afișare a produselor și către pagina de comandă.

Comanda.php

Pagina de comandă conține un formular în care sunt afișate numele, prenumele, CNP-ul utilizatorului, adresa, orașul, județul, aceste câmpuri putând fi modificate în cazul în care utilizatorul dorește livrarea comenzii la o altă adresa decât cea din cont și valoarea totală a comenzii. La apăsarea butonului „Trimite comanda” se inserează în tabela comenzi datele despre comandă, iar în tabela itemi_comanda se inserează produsele comandate. După inserarea datelor în tabele se creează fișierul comenzi.xml în care sunt stocate toate comenzile din tabelă.

if(!isset($_POST['adresa'])) $_SESSION['adresa'] = '';

else $_SESSION['adresa'] = $_POST['adresa'];

if(!isset($_POST['sector'])) $_SESSION['sector'] = '';

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>

<center><h4>Nu ai introdus noua adresa de livrare sau orasul.

Apasa <a href="comanda.php">aici</a> pentru a te intoarce la pagina anterioara.</h4></center>

</body>

</html>';

}

else

{

echo '<html>

<center><h4>Va multumim.

Comanda a fost trimisa cu succes.

Inapoi la magazin <a href="seestore.php">aici</a>.</h4></center>

</body>

</html>';

$cerereSQL = "INSERT INTO `comenzi` (`data_c`, `nume_c`, `adresa`, `oras`, `cod_postal`,

`judet`, `sector`, `valoare`, `mod_plata`, `status`)

VALUES (now(), '".addentities($_SESSION['user'])."',

'".addentities($_SESSION['adresa'])."', '".addentities($_SESSION['oras'])."',

'".addentities($_SESSION['cod_postal'])."', '".addentities($_SESSION['judet'])."',

'".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'];

$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ă secțiune are drept scop prezentarea modului de interacționare al utilizatorului cu aplicația.

La accesarea site-ului se va deschide pagina principală unde utilizatorul are doua posibilități:

Dacă are un cont creat va accesa link-iul care trimite la pagina de autentificare.

În cazul în care nu are un cont trebuie să acceseze link-ul de înregistrare care va deschide o pagina ce conține un formular de înscriere.

De asemenea pe aceasta pagina, ca de altfel pe toate paginile aplicației, există mai multe secțiuni:

1. Un meniu cu următoarele link-uri:

Home – face legătura cu pagina principală

Contul meu – deschide pagina de administrare a contului personal

Produse – sunt afișate categoriile și produsele existente în baza de date

Coșul de cumpărături – conține produsele adăugate în coș de către utilizator

Statistici vânzări – sunt prezentate vânzările totale și pe categorii în termen de o săptămâna și o lună, precum și cel mai bine vândute produse din fiecare categorie și categoria cu cele mai mari vânzări

Contact – sunt prezentate opțiunile de a lua legătura cu sediul societății

Termeni și condiții – conține drepturile și obligațiile utilizatorilor si societății

Ieșire din cont – dezautentificarea utilizatorului

2. O secțiune de căutare unde utilizatorul poate să introducă unul sau mai multe cuvinte ce vor fi căutate în baza de date

3. O secțiune în care sunt afișate toate categoriile de produse

4. O secțiune ce conține un top ale celor mai vândute cinci produse din magazin

Pentru crearea unui cont trebuie accesat link-ul de înregistrare și se va deschide o pagina cu un formular de înscriere. Apoi utilizatorul va completa datele cerute și va apăsa butonul Înregistrează. Astfel se va crea un cont și se va confirma înregistrarea contului, afișându-se și un link către pagina de autentificare. În cazul în care nu mai dorește înscrierea va apăsa butonul Resetează pentru a șterge toate informațiile introduse.

La pagina de autentificare utilizatorul trebuie să introducă numele de utilizator și parola. După aceasta trebuie să apese butonul Login și se va deschide pagina „Contul meu” unde utilizatorul va putea modifica datele personale sau parola, va putea vizualiza produsele, coșul de cumpărături și va vizualiza comenzile efectuate de el anterior.

În pagina de prezentare a produselor sunt afișate toate categoriile și toate produsele existente în magazin. Pe pagină apare o listă de link-uri cu toate categoriile de produse. La selectarea unei categorii se vor afișa toate produsele din acea categorie, pentru fiecare dintre acestea afișându-se numele, prețul și o mică imagine de prezentare.

Pentru a vizualiza un produs se apasă fie pe numele produsului fie pe link-ul „Cumpără acest produs” și se va deschide pagina de prezentare a produselor care afișează toate informațiile referitoare la câte un produs. Utilizatorul mai poate să aleagă numărul produselor pe care dorește să le comande și apoi dacă dorește să-l adauge la coș trebuie să apese pe butonul „Adaugă la coș”.

În pagina de vizualizare a coșului de cumpărături este prezentat conținutul acestuia. Produsele existente în coș sunt afișate într-un tabel, pentru fiecare fiind afișate numele, producătorul, modelul, prețul, cantitatea, prețul total și un link pentru scoaterea produsului respectiv din coș. Pe pagină mai sunt afișate valoarea totală a produselor adăugate în coș și link-urile către pagina de afișare a produselor și către pagina de comandă.

Pentru a comanda produsele din cont se apasă butonul de comanda și se va deschide pagina de comandă în care sunt afișate numele, prenumele, CNP-ul utilizatorului, adresa, orașul, județul, aceste câmpuri putând fi modificate de către utilizator dacă acesta dorește livrarea la altă adresă și valoarea totală a comenzii și apoi va apăsa pe butonul „Trimite Comanda” după care utilizatorul va primi confirmarea înregistrării comenzii.

5.7 Concluzii

Odată cu începuturile Internetului un nou tip de afacere s-a profilat din ce în ce mai pronunțat pe plan internațional: comerțul online. Au apărut nenumărate site-uri și firme care se ocupă cu vânzările en-gros de produse prin Internet, cu furnizarea accesului contracost la pagini cu informații, într-un cuvânt abordează o formă sau alta de comerț electronic, un domeniu aflat în plină expansiune. Avantajul comerțului online este evident: piața pe Internet crește exponențial de la un an la altul. Un site bine lucrat, cunoscut și care oferă produse de calitate la prețuri bune va avea mai mulți vizitatori, mai motivați și mai înzestrați financiar decât multe magazine convenționale.

Având în vedere proiectarea, implementarea și testarea acestui tip de aplicații resursele de hardware, software, de timp, cele umane și cele materiale sunt reduse, și în același timp această aplicație are un potențial mare de succes.

Aplicația „ElectronX” are ca scop prezentarea unui model de magazin virtual care să conțină funcționalitățile de bază specifice unei aplicații de acest gen: gestionarea conturilor unui utilizator, prezentarea categoriilor și produselor, căutarea în baza de date, adăugarea produselor într-un coș de cumpărături, trimiterea comenzilor. Aceste funcționalități pot fi îmbunătățite și de asemenea pot fi adăugate și altele atât la nivelul aspectului interfeței cât și la nivelul operațiilor ce pot fi efectuate astfel încât să asigure o funcționare optimă a site-ului.

Dezvoltarea fără precedent din ultimele două decenii a tehnologiilor informaționale determinate de necesitatea stocării și a transmiterii rapide a informațiilor cu cele mai mici costuri, a revoluționat comerțul global, comerțul direct sau cu amănuntul.

Bibliografie

[1] Peter Buneman, Susan Davidson, Gerd Hillebrand, Dan Suciu, A Query Language and Optimization Techniques for Unstructured Data, Proceedings of ACM-SIGMOD International Conference on Management of Data, Montreal, Canada,June, 1996, pages 505-516
[2]The internet movie database
[3] S. Abiteboul, D. Quass, J. McHugh, J. Widom, J. Weiner, The lorel query language for semistructured data, Journal of Digital Libraries,Vol 1 number 1, 1997
[4] L. V. S. Lakshmanan, F. Sadri, I. N. Subramanian,A declarative language for querying and restructuring the world-wide-web, Post-ICDE IEEE Workshop on Research Issues in Data Engineering (RIDE-NDS'96),New Orleans, February,1996
[5] A. O. Mendelzon, G. A. Mihaila, T. Milo, Querying the world Wide Web, Proc. PIDS '96, December, 1996
[6] M. P. Consens, A. O. Mendelzon, Expressing Structural Hypertext Queries in Graphlog, Proc. 2nd ACM Conference on Hypertext, Pittsburgh, November, 1989
[7] S. Cluet, G. Moerkotte, Query processing in the schemaless and semistructured context, INRIA, 1997
[8] Mary Fernandez, Daniela Florescu, Jaewoo Kang, Alon Levy, Dan Suciu, STRUDEL: A Web Site Management System, Proc. of the 16th ACM SIGMOD Symposium on Principles of Database Systems,Tucson, Arizona, May, 1997
[9] Sudarshan Chawathe, Hector Garcia-Molina, Joachim Hammer, Kelly Ireland, Yannis Papakonstantinou, Jeffrey Ullman, Jennifer Widom, The {TSIMMIS} Project:{Integration} of Heterogenous Information Sources, October, 1994, Tokyo, Japan, Proceedings of the Information Processing Society of Japan Conference
[10] Yannis Papakonstantinou, Hector Garcia-Molina, Jennifer Widom, Object Exchange Across Heterogenous Information Sources, Proceedings of IEEE International Conference on Data Engineering, March, 1995, 251-260
[11]J. McHugh, S. Abiteboul, R. Goldman, D. Quass and J. Widom, Lore: A database management system for semistructured data, Stanford University Database Group, February,1997
[12] S. Abiteboul, D. Quass, J. McHugh, J. Widom, J. Weiner,The lorel query language for semistructured data,Journal of Digital Libraries,Vol 1 number 1, 1997
[13] A. Levy, A. Rajaraman, J. J. Ordille, Querying Heterogeneous Information Sources Using Source Descriptions ,Proc. 22nd International Conference on VLDB, Mumbai, India, 1996,
[14] Arbor Software, Multidimensional Analysis: Converting Corporate Data into Strategic Information,White Paper
[15] J. Xenakis, editor, Mutlidimensional Databases, Application Development Strategies, April, 1994
[16] J. Gray, A. Bosworth, A. Layman, H. Pirahesh, Data Cube: A Relational aggregation Operator Generalizing Group-By, Cross-Tab and Sub-Totals, Microsoft, MSR-TR-95-22
[17] A. Gupta, V. Harinarayan, D. Quass, Aggregate Query Processing in Data Warehousing Environments, Proc. of the 21st International VLDB Conference,P 358-369,1995
[18] V. Harinarayan, A. Rajaraman, J. Ullman, Implementing Data Cubes Efficiently, Proc. ACM SIGMOD, Montreal, Canada, June, 1996
[19] J. R. Smith, Dynamic Assembly of Views in Data Cubes, Proc. of the International VLDB Conference (to appear), New York, USA, 1998
[20] A. J. Bonner, M. Kifer, An overview of transaction logic, Theoretical Computer Science, vol 133, pp 205-265, October, 1994
[21] A. J. Bonner, Transaction Datalog: a Compositional Language for Transaction Programming, Proc. 6th International Workshop on Database Programming Languages, Estes Park, Colorado, August, 1997

Sabin Buraga – Tehnologii XML, Editura Polirom, Bucuresti, 2006

Julie C. Meloni – Învață singur PHP, MySQL și Apache, Editura Corint, Bucuresti, 2005

Patricia Ju – Databases on the web, designing and programing for network access, Editura M&T Books, New York, 1997

Sabin Buraga – Tehnologii Web, Editura Matrix Rom, București, 2001

Mark Campbell – Web Design Garage, Editura Prentice Hall, 2005

Larry Ullman – PHP și MySql pentru site-uri de web dinamice, Editura Teora, Bucuresti, 2006

Ronald Bourret – XML and Databases, www.rpbourret.com/xml/XMLAndDatabases.html

Valentin Ivașcu – Inițiere în PHP și MySql, http://www.oriceon.com/tutorial/

Byte.ro – http://www.byte.ro/byte98-05/bd.htm

Biblioteca.ase.ro – www.biblioteca.ase.ro/downres.php?tc=5952

Builder.com – http://builder.com.com/5100-6388-5035149.html#Listing%20A

Devshed.com – http://www.devshed.com/c/a/PHP/Serializing-XML-With-PHP/5/

W3Schools – http://www.w3schools.com/

Web developers notes – http://www.webdevelopersnotes.com/

Domo.ro – http://www.domo.ro/

Copyright Notice

© Licențiada.org respectă drepturile de proprietate intelectuală și așteaptă ca toți utilizatorii să facă același lucru. Dacă consideri că un conținut de pe site încalcă drepturile tale de autor, te rugăm să trimiți o notificare DMCA.

Acest articol: . Aplicatii ale Xml In Baze de Date (ID: 148952)

Dacă considerați că acest conținut vă încalcă drepturile de autor, vă rugăm să depuneți o cerere pe pagina noastră Copyright Takedown.

. Aplicatii ale Xml In Baze de Date

Copyright Notice

Soluții Informatice Privind Gestiunea Electronică a Cărților Dintr O Bibliotecă

Implеmеntarеa Sistеmului Еrp Sap R 3 la Еnеl Еnеrgiе Muntеnia

Testarea Aplicatiilor Software. Studiu Privind Managementul Procesului Decizional

. Bazele de Date In Romania

Proiectarea Unui Portal Web Educational

Detectia Vehiculelor Si Procesarea Informatiilor

Copyright Notice

Similar Posts