Utilizarea Limbajului Xml In Calitate de Baza de Date (pe Exemplul Unui Magazin Online de Tehnica de Calcul)

Informatica

Utilizarea Limbajului Xml In Calitate de Baza de Date (pe Exemplul Unui Magazin Online de Tehnica de Calcul)

Byadmin ianuarie 1, 2024

Utilizarea limbajului XML în calitate de bază de date (pe exemplul unui magazin online de tehnica de calcul)

CUPRINS

INTRODUCERE

1. TEHNOLOGII DE BAZĂ ALE XML

1.1. Limbajul XML

1.1.1. Declararea XML

1.1.2. Elemente XML

1.1.3. Atribute XML

1.1.4. Referințe la entități

1.1.5. Comentarii

1.1.6. Secțiuni CDATA și instrucțiuni de prelucrare

1.1.7. Ordonarea

1.2. Bazele modelelor relaționale

1.3. DTD și XML schema

1.3.1 Definirea tipului de document (Document Type Definition – DTD)

1.3.2. Schema XML

1.3.3. Neajunsurile XML DTD față de XML Schema

1.3.4. XML Schema – standardul industrial de descriere a documentelor XML

1.3.5. Stabilirea corespondenței între XML Schema și document

1.4. Domenii de utilizare a XML

1.4.1. XML pe partea clientului (client-side)

1.4.2. XML pe partea serverului (server-side)

1.4.3. Utilizarea XML pentru păstrarea datelor

1.5. Utilizarea XSLT cu XPath pentru afișarea documentelor XML

1.5.1. Utilizarea XSLT

1.5.2. XML Path Language – limbaj pentru adresarea fragmentelor XML

1.7. Descrierea structurilor de date cu ajutorul XML

1.6. Avantaje și neajunsuri XML

1.6.1. Avantaje XML

1.6.2. Neajunsuri XML

2. XML CA BAZĂ DE DATE

2.1. Compararea datelor XML cu date relaționale

2.2. Metode de păstrare a datelor XML

2.2.1. Păstrarea XML în niște sisteme de fișiere

2.2.2. Construirea soluției proprii

2.2.3. Utilizarea XML cu bazele de date clasice

2.2.4. Obținerea XML din bazele de date relaționale

2.2.5. Transferarea XML în bazele de date relaționale

2.2.6. Baze de date XML native

2.2.7. Analiza comparativă a bazelor de date relaționale și baze de date native XML

3. APLICAȚIA WEB „MAGAZIN ONLINE”

3.1. Descrierea domeniului de cercetare a unui magazin online

3.1.1. Funcțiile de bază ale unui magazin online

3.1.2. Avantajele oferite de un magazin online:

3.1.3. Arhitectura unui magazin online

3.2. Analiza comparativă a diferitor medii de dezvoltare a aplicațiilor web

3.3. Web server

3.4. Structura generală a aplicației

3.5. Proiectarea și realizarea programată a magazinului online

3.5.1. Principii de dezvoltare a interfeței

3.5.2. Realizarea programată

3.6. Interfața magazinului online

3.6.1. Interfața componentei utilizator

3.6.2. Interfața componentei de administrare

CONCLUZII

ANEXE

INTRODUCERE

Odată cu creșterea numărului de calculatoare și a utilizatorilor Internet crește corespunzător și volumul de informații create, transmise, interschimbate și stocate. Pe lângă stocarea datelor în sistemele de gestionare a bazelor de date relaționale, în atenție notabilă printre dezvoltatorii web se află limbajul XML (Extensible Markup Language).

Un număr mare de diferite baze de date nu permite transferarea directă a conținutului unei baze de date în alta. Pentru rezolvarea acestei probleme există programe-convertoare, care conversează un format de bază de date în altul. De regulă, convertoare există numai pentru cele mai populare formate de baze de date, ceea ce nu permite transformarea unui format învechit în unul modern. Utilizarea a două convertoare nu este rațională, de aceea o soluție optimală ar fi în calitate de etapa intermediară de păstrat baze de date în niște fișiere XML.

XML-fișiere și fișiere de alte extensii, bazate pe tehnologia XML, se bucură de o răspândire foarte largă, practic orice sistem de operare contemporan susține acest format de fișiere. În fișiere XML pot fi păstrate cele mai diverse date – de la setările unor aplicații până la baze de date. Fișiere pe baza XML se utilizează pentru schimbul de informații în Internet și între programe (pentru această limbajul dat și a fost creat inițial). Deoarece fișiere de formatul XML conțin date textuale, ele pot fi ușor redactate în orice editorul de texte, la fel poate fi indicată orișice codificarea de date comodă utilizatorului. În afară de această există un număr mare de generatoare de documente XML.

Toate cele expuse anterior ne vorbesc despre actualitatea temei tezei, căci dezvoltatorul aplicației nu va avea nevoie să utilizeze softuri specializate, inclusiv cele cu licență cu plată, pentru a elabora o aplicație web, ci numai programele standard oferite de orice sistem de operare, cum ar fi programul NotePad.

Scopul principal al lucrării de față este cercetarea posibilităților de utilizare a limbajului XML în calitate de baza de date pe exemplul unui magazin online de tehnica de calcul.

Obiectul cercetării este limbajul XML.

Pentru atingerea scopului propus e necesar de rezolvat următoarele sarcini:

Cercetarea surselor bibliografice referitor la tema tezei;

Evidențierea avantajelor și neajunsurilor utilizării XML;

Analiza comparativă a datelor XML cu date relaționale;

Cercetarea metodelor de păstrare a datelor XML;

Cercetarea domeniului de utilizare a magazinului online;

Cercetarea instrumentelor de elaborare a aplicației;

Elaborarea aplicației magazinului online, construite pe datele XML.

În calitate de instrument de demonstrare a posibilităților utilizării XML ca o baza de date va servi un magazin online de tehnica de calcul, construit pe datele XML. Cercetând diferite magazine online, am ajuns la concluzia că majoritatea acestora sunt construite pe sisteme clasice de gestiune a bazelor de date, cum ar fi de exemplu MySQL, SQL Server, Oracle, etc. Aplicația elaborată în această lucrare n-are analog în rețea Internet, prin faptul că este construită în totalitate pe o bază de date XML.

Teza dată constă din introducere, trei capitole, concluzii, lista bibliografică și anexe.

Primul capitol, denumit „Tehnologii de bază ale XML”, ne prezintă o introducere în limbajul XML. Aici se vorbește despre sintaxa limbajului, element și atribute utilizate în el, metode de verificare a corectitudinii structurii unui document XML (Document Type Definition (DTD) și XML schema) și analiza lor comparativă. Tot aici se vorbește despre domenii de utilizare a limbajului XML (în componenta client și în componenta server), despre instrumente de afișare a documentelor XML, se scoate în relief avantaje și neajunsuri ale XML și se descriu diferite structuri de date prin intermediul acestui limbaj.

În capitolul al doilea, denumit „XML ca bază de date”, se efectuează compararea datelor XML cu date relaționale și se descriu diferite metode de păstrare a datelor XML. Printre acestea putem menționa păstrarea datelor XML într-un sistem de fișiere, utilizarea XML cu bazele de date clasice, obținerea XML din bazele de date relaționale, transferarea XML în bazele de date relaționale și baze de date XML native.

Al treilea capitol reprezintă descrierea domeniului de cercetare a unui magazin online aplicației, motivarea alegerii instrumentelor de dezvoltare a magazinului online elaborat, proiectarea și realizarea programaturii și interfeței magazinului online.

În anexe sunt aduse codurile fișierelor care prelucrează conținutul fișierului marfa.xml, acestea sunt: get_cat.php, care afișează mărfuri din baza de date marfa.xml după categoria aleasă de cumpărător; add_marfa.php, care adaugă o marfă nouă în baza de date XML; del_marfa.php, care șterge o marfă din fișierul bazei de date marfa.xml. Tot aici este descris fragmentul conținutului fișierlui marfa.xml și conținutul fișierului XML-schemei (marfa.xsd) de verificare a corectitudinii fișierlui marfa.xml.

1. TEHNOLOGII DE BAZĂ ALE XML

1.1. Limbajul XML

XML (eXtensible Markup Language – limbajul de marcare extensibil) reprezintă o submulțime a limbajului SGML (Standard Generalized Markup Language – limbajul standard generalizat de marcare).

1.1.1. Declararea XML

Documentele XML încep cu o declarare neobligatorie a XML, care în exemplul adus conține notația versiunii XML, utilizată de autorul documentului (1.0) și sistemul de codificare (UTF-8 corespunde standardului Unicode), de asemenea, conține informația despre prezența în document a referinței la declarările exterioare a marcajelor (standalone = ‘yes’ indică faptul că în documentul lipsesc declarările exterioare ale marcajelor). Exemplu:

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

1.1.2. Elemente XML

Elemente XML, denumite altfel și descriptori, reprezintă o formă de marcare utilizată pe larg. Primul element al unui document XML trebuie să fie un element numit rădăcină, care poate să conțină alte elemente (sub-elemente). Fiecare document XML trebuie să aibă un element rădăcină. Orice element începe cu descriptorul de deschidere și se termină cu descriptorul de închidere a elementului. Elemente XML sunt case sensitive, astfel elementul <DOC> diferă de elementul <doc>. Un element poate fi vid, în acest caz el poate fi reprezentat în forma scurtă printr-un singur descriptor, de exemplu <DOC/>. Elemente trebuie să fie corect imbricate (incluse unul în altul) [14].

1.1.3. Atribute XML

Atribute reprezintă perechi “nume-valoare”, care conțin informația de descriere a unui element. Atributele se plasează în interiorul descriptorului de deschidere după numele corespunzător al elementului, iar valoarea atributului se include între ghilimele. Fiecare atribut concret poate să apară într-un descriptor numai o dată, dar sub-elemente pot să se repete. De exemplu, declararea atributului: <Doc id = “id111”>.

1.1.4. Referințe la entități

O entitate se numește un element al documentului XML, care realizează următoarele funcții de bază:

Servesc în calitate de prescurtări pentru însemnarea unui text des repetat sau permit includerea în document a conținutului unui fișier extern;

Se utilizează pentru inserarea în text a oricăror caractere în Unicode (de exemplu, pentru reprezentarea caracterelor, care nu pot fi introduse direct de pe tastatura);

Permit să diferențieze caracterele rezervate și conținutul. De exemplu, paranteza unghiulară de stânga (<) înseamnă începutul descriptorului de deschidere sau de închidere al unui element. Pentru a diferenția acest caracter de marcare de caracterul respectiv din conținutul elementului, în limbajul XML există entitatea lt, care înlocuiește caracterul <.

Fiecare entitate trebuie să posede un nume unicat și utilizarea ei în cadrul unui document XML se numește referință la entitate. Orice referință la entitate începe cu caracterul ampersand (&) și se termină cu caracterul punct și virgulă (;), de exemplu <

Tabelul 1. Referințe la entități [9]

1.1.5. Comentarii

Comentarii se includ în descriptori <! – și – > și pot conține orice date în afară de șirul de caractere “–”. Comentariile pot fi amplasate între descriptori de marcare în orice loc al documentului XML, însă procesorul XML nu este obligat să transfere comentariile în aplicația.

1.1.6. Secțiuni CDATA și instrucțiuni de prelucrare

O secțiune CDATA reprezintă un indicator pentru procesorul XML, care arată că procesorul trebuie să ignore caracterele de marcare conținute în această secțiune și să transfere textul inclus în ea, fără interpretare, direct aplicației. Pentru transferarea aplicației a unei informații adiționale pot fi utilizate și instrucțiuni de prelucrare. O instrucțiune de prelucrare servește pentru a indica aplicației cum trebuie de prelucrat elementele documentului și conținutul său. O instrucțiune de prelucrare are sintaxa:

<?target …instruction… ?>,

unde (target) – reprezintă orice identificator admis în XML, care indică aplicația cărei este adresată instrucțiunea, instrucțiunea poate fi oricare.

Deoarece instrucțiuni depind de aplicația, orice document XML poate să conțină mai multe instrucțiuni de prelucrare, care permit transmiterea către diferite aplicații a comenzilor de executare a aceleiași acțiuni, dar, posibil, prin diferite modalități.

1.1.7. Ordonarea

În limbajul XML elemente sunt considerate ca ordonate, astfel următoarele două fragmente în limbajul XML, cu elementele interschimbate FNAME și LNAME se consideră diferite:

<NAME>

<LNAME>White</LNAME>

</NAME>

<NAME>

<LNAME>White</LNAME>

</NAME>

Însă atributele în XML nu suntnghiulară de stânga (<) înseamnă începutul descriptorului de deschidere sau de închidere al unui element. Pentru a diferenția acest caracter de marcare de caracterul respectiv din conținutul elementului, în limbajul XML există entitatea lt, care înlocuiește caracterul <.

Fiecare entitate trebuie să posede un nume unicat și utilizarea ei în cadrul unui document XML se numește referință la entitate. Orice referință la entitate începe cu caracterul ampersand (&) și se termină cu caracterul punct și virgulă (;), de exemplu <

Tabelul 1. Referințe la entități [9]

1.1.5. Comentarii

Comentarii se includ în descriptori <! – și – > și pot conține orice date în afară de șirul de caractere “–”. Comentariile pot fi amplasate între descriptori de marcare în orice loc al documentului XML, însă procesorul XML nu este obligat să transfere comentariile în aplicația.

1.1.6. Secțiuni CDATA și instrucțiuni de prelucrare

O secțiune CDATA reprezintă un indicator pentru procesorul XML, care arată că procesorul trebuie să ignore caracterele de marcare conținute în această secțiune și să transfere textul inclus în ea, fără interpretare, direct aplicației. Pentru transferarea aplicației a unei informații adiționale pot fi utilizate și instrucțiuni de prelucrare. O instrucțiune de prelucrare servește pentru a indica aplicației cum trebuie de prelucrat elementele documentului și conținutul său. O instrucțiune de prelucrare are sintaxa:

<?target …instruction… ?>,

unde (target) – reprezintă orice identificator admis în XML, care indică aplicația cărei este adresată instrucțiunea, instrucțiunea poate fi oricare.

Deoarece instrucțiuni depind de aplicația, orice document XML poate să conțină mai multe instrucțiuni de prelucrare, care permit transmiterea către diferite aplicații a comenzilor de executare a aceleiași acțiuni, dar, posibil, prin diferite modalități.

1.1.7. Ordonarea

În limbajul XML elemente sunt considerate ca ordonate, astfel următoarele două fragmente în limbajul XML, cu elementele interschimbate FNAME și LNAME se consideră diferite:

<NAME>

<LNAME>White</LNAME>

</NAME>

<NAME>

<LNAME>White</LNAME>

</NAME>

Însă atributele în XML nu sunt ordonate, de aceea următoarele două elemente XML sunt aceleași:

1.2. Bazele modelelor relaționale

Modelul relațional se bazează pe principii matematice, care decurg direct din teoria mulțimilor și logica predicatelor. Aceste principii pentru prima dată au fost aplicate în domeniul modelării datelor, la sfârșitul anilor 60, de către doctorul Edgar Frank Codd, în timp ce lucra la firma IBM, iar publicate – în anul 1970. Modelul relațional determină modul de reprezentare a datelor (structura de date), metode de protecție a datelor (integritatea datelor), și operații efectuate asupra datelor (manipularea datelor) [12].

În linii generale principiile de bază ale sistemelor relaționale de baze de date pot fi formulate astfel [12]:

Toate datele la nivelul conceptual se reprezintă ca o organizare ordonată, determinată în forma de linii și coloane, care se numește relație.

Toate valorile sunt scalare. Ceea ce înseamnă, că pentru orice linie și coloană a oricărei relații există o singură valoare.

Toate operațiile se efectuează asupra relației în întregime, și rezultatul efectuării acestor operații de asemenea este o relație. Acest principiu se numește închidere.

Operațiile de bază pot fi ușor definite în termenii algebrei universale. Algebra universală reprezintă o totalitate a tuturor valorilor posibile cu setul de operații, rezultatul cărora aparține aceleiași totalități. Aceste operații sunt:

Selecție: Printre seturi de date se aleg acele care satisfac unui predicat concret (el se construiește din niște predicate simple, ele reprezentând niște expresii logice la valorile atributelor).

Proiecție: Proiector se numește un operator, pătratul căruia este el însuși. Proiecția se realizează pe o submulțime a mulțimii atributelor. În cazul realizării proiecției e necesar să înlăturăm duplicate, ceea ce reprezintă o problemă de mare complexitate.

Produs: După efectuarea operației de produs se obține, de regulă, un tabel rezultant foarte mare.

Conexiune: Conexiune reprezintă o compoziție a produsului și a selecției și joacă un rol important în teoria bazelor de date. Această operație are doi operanzi, poate avea diferite forme în funcție de ceea ce se va întâmpla după. În loc de selecție poate avea loc compoziția cu proiecția.

Conexiune naturală: Această operație este importantă, deoarece pentru ea există un algoritm efectiv. Această operație ne permite să construim relații noi pe baza celor existente.

Alte operații permit construirea relațiilor netriviale, mari după dimensiuni.

1.3. DTD și XML schema

Deoarece XML reprezintă o metodă de descriere a datelor structurate, trebuie să existe mijloace de definire a structurii documentului XML. Printre aceste mijloace sunt Definirea Tipului de Document (DTD) și Schema XML. Ele se utilizează pentru a defini construcția corecta a blocurilor intr-un document XML cu lista elementelor admisibile.

1.3.1 Definirea tipului de document (Document Type Definition – DTD)

DTD constă din declarații de marcaje (markup declarations), care încep cu perechea de caractere <!. După aceste caractere urmează unul dintre cuvintele ELEMENT, ATTLIST, ENTITY, NOTATION, care indică ce anume se declară: un element, o listă de atribute, o entitate sau o notație. Declarația de marcaje se finisează cu caracterul ”>”. Structura DTD se reprezintă astfel:

<!DOCTYPE root_element [

<!ELEMENT element_name (component)>

other elements’ or attributes’ declarations

]>

Declararea tipului elementului

Fiecare element al documentului XML trebuie să fie descris în declararea tipului elementului (element type declaration). Declararea tipului unui element începe cu caractere <!ELEMENT, urmate de spațiu liber și numele elementului după care se declară conținutul său.

Cel mai simplu se declară un element vid – se notează cu cuvântul EMPTY. De exemplu: <!ELEMENT doc EMPTY>.

Următoarea declarație poate fi considerată ca antiteza a declarației unui element gol: <!ELEMENT book ANY>. Un element cu conținutul textual obișnuit și fără elemente incluse se declară în felul următor: <!ELEMENT author (#PCDATA)>. Cuvântul #PCDATA (Parsed Character DATA) înseamnă un șir de caractere, vizualizat de către programul-analizator al documentului XML.

Dacă elementul declarat conține elemente incluse, atunci declarația trebuie să conțină în paranteze lista denumirilor acestora, enumerate prin virgula. Elemente incluse trebuie să urmeze în documentul XML în acea ordine în care ele sunt enumerate în declarația. În afară de elemente incluse în interiorul unui element poate fi întâlnit un text simplu. Același element inclus poate fi întâlnit de mai multe ori. Faptul că elementul inclus poate fi înscris în elementul declarat de mai multe ori se notează prin asterisc (*), plus (+) sau semnul întrebării (?) [14]. În așa fel:

Operatorul * înseamnă că element poate să se repete de un număr arbitrar de ori sau să lipsească.

Operatorul + înseamnă că element trebuie să fie prezent cel puțin o dată.

Operatorul ? înseamnă că element poate să fie absent sau utilizat numai o dată.

Pentru modelarea listei de elemente se utilizează operatorul listei, care reprezintă o pereche de paranteze rotunde, în cadrul cărora sunt enumerate prin virgula elementele respective.

În afară de această în definirea unor elemente în DTD se admite utilizarea operatorului de selecție |, care separă elemente și admite prezența numai unuia între elemente participate în expresia cu acest operator.

Declararea atributelor

Atributele unui element se declară după declararea elementului propriu zis. Toate atributele unui element se declară simultan într-o singură listă. Lista începe cu caractere <!ATTLIST, urmate de spațiu liber și numele elementului, la care se referă atributele. Apoi urmează declarații de atribute. Lista se finisează cu caracterul “ > ” [14].

Pentru fiecare atribut se introduce numele, tipul și semnul obligatoriu. Tipul atributului se înscrie utilizând notațiile ce urmează [9].

CDATA – un șir de caractere.

ID – un identificator unicat, care determină univoc elementul concret, unde a fost întâlnit acest atribut, valorile unui asemenea atribut nu trebuie să se repete în cadrul documentului.

IDREF – un identificator, care conține una din valorile atributelor de tip ID, se utilizează în calitate de referință la alte elemente.

IDREFS – un identificator, care conține un set de valori ale atributelor de tipul ID, enumerate prin spații libere; de asemenea se utilizează în calitate de referință simultan la mai multe elemente.

ENTITY – numele entității care nu se controlează de către analizator.

ENTITIES – numele entităților necontrolabile.

NMTOKEN – cuvântul, care conține numai caractere utilizate în denumiri.

NMTOKENS – cuvintele enumerate prin spații libere.

NOTATION – notația.

Lista valorilor atributului enumerate între paranteze prin bara verticală.

Atributele de tipul ID se utilizează în același scop ca și cheile primare din tabelele bazelor de date. Ele permit diferențierea elementelor și indexarea lor.

Declararea atributului se finalizează cu semnul de prezența obligatorie a acestuia în cadrul elementului sau valoarea implicită a atributului. Semnul obligatoriu reprezintă unul din trei cuvinte, care indică dacă este obligatoriu de înscris atributul și ce va fi dacă el va lipsi în element [10]:

#REQUIRED – atributul trebuie obligatoriu înscris în element.

#IMPLIED – atributul nu este obligatoriu și n-are valoarea implicită.

#FIXED – atributul poate avea numai o singură valoare, care se înscrie tot aici prin spațiu liber.

Declararea entităților

Toate entitățile pot fi separate în trei grupe [10]:

Entități interne – se specifică în declararea entității.

Entități externe – se conțin în fișiere separate sau sunt încorporate în programul-analizator.

Entități parametrizate – se utilizează numai în interiorul descrierii DTD.

Declararea entității interne (entity declaration) începe cu caractere <!ENTITY, urmate de spațiu liber și numele entității și prin spațiu liber se înscrie însăși entitate, adică valoarea ei între ghilimele [10].

După o asemenea declarație programul-analizator observând într-un document codul de entitate &nume_entității, îl poate aplica imediat, în descrierea DTD. Așa entități se numesc interne (internal entities), deoarece pentru declararea lor nu se cere nici un obiect extern.

Pentru entități externe (external entities) se indică numai locul lor de amplasare în forma adresei URI (Uniform Resource Identifier – identificator unificat de resursa). Înaintea indicării adresei se înscrie unul din cuvinte SYSTEM sau PUBLIC. Diferența între SYSTEM și PUBLIC constă în faptul că după cuvântul PUBLIC urmează o declarare cu acces public la ea. De obicei aici se înscrie o referință cunoscută, introdusă de consorțiul W3C sau altă organizație. Dacă programul-analizator nu va găsi această referința, atunci el se va folosi de adresa URI, urmată după referința [3].

Declararea entităților parametrizate (parametric entities), utilizate numai în interiorul descrierii DTD, se efectuează la fel ca și declararea entităților interne și externe, numai între începutul declarării <!ENTITY și numele entității se inserează semnul %, separat din ambele părți de spații libere. Referința la o entitate parametrizată începe cu semnul procentului (%) [10].

Declararea notațiilor

O notație (notation) se declară asemănător unei entități. Notațiile de asemenea pot fi interne și externe. În cazul declarării notațiilor interne după caracterele <!NOTATION se înscrie numele notației, urmat de descifrarea sa inclusă între ghilimele.

În cazul declarării notațiilor externe se utilizează marcaje SYSTEM sau PUBLIC și după cuvântul nu trebuie să urmeze în mod obligatoriu o referință binecunoscută, în așa fel cuvintele SYSTEM și PUBLIC în acest caz sunt identice.

1.3.2. Schema XML

Schema de date (Schemas) reprezintă o modalitate alternativă de creare a regulilor de construire a documentelor XML. Comparativ cu DTD, schemele posedă niște mijloace mai puternice pentru definirea structurilor de date complexe, asigură un mod mai intuitiv de descriere a gramaticii limbajului, sunt capabile de a se actualiza și de a se extinde ușor. Avantajul incontestabil al schemelor este faptul că ne permit să descriem regulile pentru un document XML utilizând mijloacele XML. De exemplu, prin mijloacele DTD noi nu putem stabili anumite condiții (exemplu: cantitatea produselor nu se vinde dacă este nulă și reprezintă un număr întreg) pentru atribute, în schimb cu schema XML acest lucru este posibil [14].

Însă aceasta nu înseamnă, că schemele pot înlocui total pe descrierile DTD, acest mod de definire a gramaticii limbajului se utilizează curent practic de către toate analizatoare de control ale XML, mai mult ca atât, schemele înșiși fiind elemente XML obișnuite, de asemenea se descriu prin DTD.

Pentru a aprecia avantajele schemelor XML față de DTD, vom precauta neajunsurile de bază a DTD, care au fost rezolvate cu succes în schemele XML.

1.3.3. Neajunsurile XML DTD față de XML Schema [9]

Sintaxa limbajului diferită de XML. Adică DTD nu este XML. În legătura cu aceasta pot să apară diferite probleme de codificare și verificare a documentelor XML.

Lipsește controlul tipurilor de date. În XML DTD există numai un singur tip de date – șir de caractere. În legătura cu aceasta, de exemplu, dacă într-un câmp numeric va fi un text, documentul va trece verificarea cu succes, deoarece XML DTD nu poate verifica tipul de date.

Este imposibil să punem în corespondența unui document XML mai mult de o descriere DTD. Adică verificarea documentului poate fi efectuată numai cu o singură descriere DTD. Dacă acestea sunt mai multe, atunci va apare necesitatea de a reface toate descrierile și de a le cumula pe toate într-un singur fișier, ceea ce creează incomodități.

Toate aceste neajunsuri au fost rezolvate cu succes în standardul de descriere a documentelor XML Schema.

1.3.4. XML Schema – standardul industrial de descriere a documentelor XML

XML Schema realizează următoarele funcții:

Descrie denumirile tuturor elementelor și atributelor (dicționar).

Descrie legătura între elementele și atributele, la fel, și structura lor (modelul conținutului).

Descrie tipurile de date.

O schemă XML reprezintă o metodă universală de descriere a gramaticii datelor și poate fi utilizată nu numai pentru verificarea documentelor XML, dar și la descrierea bazelor de date etc. În așa fel, domeniul de utilizare a schemelor este foarte vast [8].

În continuare vom prezenta un exemplu simplu de o schemă XML utilizată în această lucrare.

Exemplu de schema XML pentru validarea unui document XML

1 <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">

2 <xs:element name="marfa" type="Marfa" />

3 <xs:complexType name="Marfa">

4 <xs:sequence>

5 <xs:element name="type" type="xs:string" />

6 <xs:element name="name" type="xs:string" />

7 <xs:element name="descriere" type="xs:string" />

8 <xs:element name="foto" type="xs:string" />

9 <xs:element name="price" type="xs:decimal" />

10 <xs:element name="cantitate" type="xs:integer" />

11 </xs:sequence>

12 </xs:complexType>

13 </xs:schema>

Prin intermediul acestei scheme se poate de validat un document XML cu următorul conținut:

1 <marfa xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation = "marfa.xsd">

2 <type>Calculatoare</type>

3 <name>Calculator HP-210</name>

4 <descriere>proc. 2,5 Ghz, RAM 2 GO, HD 500 GO</descriere>

5 <foto>http://MyShop.me/catalog/Calculatoare3.jpg</foto>

6 <price>6000</price>

7 <cantitate>6</cantitate>

4 </marfa>

După cum se observă, pentru crearea schemelor XML se utilizează limbajul XML. Unica diferență constă în faptul că în schemele XML elementele sunt deja definite spre deosebire de limbajul XML. În legătură cu aceasta se utilizează așa numite spații de nume. În cazul de față un spațiu de nume obligatoriu va fi «http://www.w3.org/2001/XMLSchema», care va fi indicată prin intermediul prefixului «xs».

1.3.5. Stabilirea corespondenței între XML Schema și document

O caracteristică specifică a XML Schema este faptul că ea descrie nu însăși document, ci spațiul de nume. De aceea, cel mai des nici o mențiune despre aceasta în documentul nu există. Parser-ul singur pune în corespondență schema XML necesară, fără niciun fel de instrucțiuni în XML document.

În cazul în care, parser-ul nu știe unde se află schema, putem specifica unde să caute. Această se efectuează cu ajutorul unui atribut special ”schemaLocation”. Deoarece acest atribut aparține unui spațiu de nume diferit, înainte de utilizare a atributului este necesar să se specifice acest spațiu. Pentru claritate, considerăm un exemplu.

XML Schema

1 <?xml version="1.0" ?>

2 <xsd:schema xmlns:xsd=http://www.w3.org/2001/XMLSchema

3 targetNamespace=http://www.site.com

4 …

XML-документ

1 <?xml version="1.0" ?>

2 <my:product xmlns:my=http://www.site.com

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

4 xsi:schemaLocation=http://www.site.com/product.xsd

5 …

În continuare vom cerceta fiecare rând al codului.

targetNamespace="http://www.site.com" – indicăm pentru care spațiul de nume se utilizează aceasta XML Schema.

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" – conectăm spațiul de nume în care este descris atributul «schemaLocation».

xsi:schemaLocation="http://www.site.com/product.xsd" – indicăm unde poate fi găsită schema în cazul dacă parser-ul nu știe unde aceasta se află. Dacă documentul XML nu aparține niciunui spațiu de nume, și deci și în schema lipsește adresa acestuia, atunci atributul «schemaLocation» se înlocuiește cu «noNamespaceSchemaLocation» (indicarea unei scheme fără definirea spațiilor de nume).

1.4. Domenii de utilizare a XML

XML poate fi utilizat atât în componenta server-side, cât și în cea client-side [10]. În continuare vom precauta principii de utilizare a XML în fiecare din aceste domenii, la fel și pentru păstrarea datelor.

1.4.1. XML pe partea clientului (client-side)

Pe partea clientului XML permite atingerea unui nivel înalt de corespundere condițiilor concrete de reprezentare a datelor, care este destul de greu sau chiar imposibil de atins utilizând HTML. De exemplu, pentru așa dispozitive cum ar fi PDA (Personal Digital Assistant – calculatorul de buzunar, destinat executării unor funcții speciale) sau telefonul mobil, se cere ca paginile să fie formatate diferit față de browser-e web standard. Însă datorită datelor structurate ale documentului XML, în care conținutul este separat de indicații de formatare, totul ce ne rămâne să facem pentru aducerea paginii în corespundere cu dispozitivul care o afișează este aplicarea datelor din document a unui tabel de stiluri necesar [10].

1.4.2. XML pe partea serverului (server-side)

În prezent XML are o influență mare asupră organizării lucrului serverului. Unul din moduri de utilizare a XML pe partea serverului este transmiterea mesajelor (messaging), adică schimbul de informații între aplicații sau calculatoare [10]. Pentru ca aplicații și calculatoare să poată interschimba informații pentru acestea e necesar să fie definit un format al mesajelor unic pentru ele. În acest scop poate fi cu succes utilizat limbajul XML. Cauza principală fiind simplitatea XML. Limbajul XML este subordonat unui standard strict determinat, nu este legat nici de un sistem de operare sau producător, este compatibil cu un număr mare de mijloace instrumentale și aplicații, care au fost elaborate pe parcursul anilor pentru SGML. Cerința corespunderii stricte a documentelor XML standardelor, stabilite pentru documente corect formatate (well-formed), asigură că orice analizator XML va fi în stare să citească și să interpreteze corect orice document XML. În afară de această, cu mult mai mulți oameni sunt cunoscuți cu limbaje de marcare, decât cu formatele de mesaje, necesare pentru construirea sistemelor EDI. Datorită XML formatul mesajelor poate elabora oricine capabil să alcătuiască un document XML formatat corect [10].

Alt domeniu de utilizare a XML în documentele web este definirea meta-conținutului. Meta-conținutul sau informații despre conținut permite a face lucrul motoarelor de căutare mult mai efectiv. De exemplu, fie că e necesar să găsim niște mesaje despre ultimele evenimente în orașul Iași statului România. Atunci indicăm motorului de căutare următoarele cuvinte:

Iași România evenimente

Deoarece majoritatea motoarelor de căutare în prezent pur și simplu indexează tot conținut al sitului, există o mare probabilitate că în rezultatul așa unui criteriu de căutare ne va fi propusă o mulțime de documente de prisos, găsite din cauza unei simple coincidențe. Dacă paginile consacrate evenimentelor din Iași, ar fi fost scrise și păstrate în forma documentelor structurate XML, căutarea lor ar fi cu mult mai corectă, de exemplu am putea indica următorii parametri:

City = Iași, State = RO, StoryType = News.

1.4.3. Utilizarea XML pentru păstrarea datelor

XML poate fi utilizat pentru crearea bazelor de date. Într-un document XML se utilizează structura ierarhică arborescentă de păstrare a datelor. Pe de o parte păstrarea datelor în forma documentelor XML nu este prea efectivă, pe de altă parte așa un mod de păstrare are un șir de avantaje. Ca și în cazul transmiterii mesajelor, cel mai mare avantaj este simplitatea. Structura arborescentă reprezintă o modalitate intuitiv clară și cunoscută de organizare a datelor. În afară de această, aproape orice tip al structurii arborescente, de la baze de date relaționale până la baze de date orientate pe obiect și structurile ierarhice, poate fi reprezentat cu ajutorul arborelui de date XML. Alt avantaj esențial al utilizării XML pentru păstrarea datelor constă în aceea că XML susține set de caractere Unicode. Prin urmare orice caracter al oricărui alfabet poate fi inclus în documente XML [10].

Unicode reprezintă o cale de realizare a setului de caractere universal (Universal Character Set, UCS), definit de Organizația Internațională de Standardizare (International Standards Organization, ISO); cu alte cuvinte, Unicode este un standard universal de codificare a caracterelor pentru reprezentarea electronică a textului și prelucrarea a acestuia cu ajutorul calculatorului. Pentru transformarea codificărilor caracterelor într-un set faptic de biți se utilizează formate de transformare UCS, sau prescurtat UTF (UCS Transformation Formats).

Specificarea XML cere ca procesoarele XML să susțină două formate UTF: UTF-8 și UTF-16. În UTF-16 se utilizează doi octeți pentru reprezentarea fiecărui caracter. În UTF-8 pentru caracterele ASCII se utilizează codificarea ASCII, care ocupă un octet, iar pentru caractere care nu fac parte din ASCII, codificarea de o lungime variabilă. Formatul UTF-8 este util dacă este necesar să susțină compatibilitatea cu ASCII. Neajunsul acestui format constă în faptul că pentru reprezentarea restului caracterelor (care nu fac parte din ASCII) în el poate să apară necesitatea în de la 1 până la 3 octeți [10]. Dacă textul nostru constă preponderent din caracterele ASCII, UTF-8 ne va permite să economisim volumul de memorie. Dacă utilizăm ale caractere, atunci acest format dimpotrivă va cere cheltuieli de prisos ale memoriei. În mod implicit în XML se utilizează formatul UTF-8. Codificarea documentului se declară în prologul documentului XML cu ajutorul atributului special de codificare (encoding), după cum este prezentat în exemplul următor:

<?xml version="1.0" standalone='no' encochng="UTF-8"?>.

1.5. Utilizarea XSLT cu XPath pentru afișarea documentelor XML

1.5.1. Utilizarea XSLT

XSLT este un limbaj de nivel înalt care conține 35 de elemente definite de Consorțiul World Wide Web [4]. XSLT reprezintă un limbaj declarativ, care se utilizează pentru transformarea documentelor (sursă) XML în alte documente XML care pot fi afișate într-un navigator Internet, pe ecranul unui telefon mobil, pe hârtie imprimată etc.

O foaie de stiluri XSLT este un fișier XML care permite integrarea datelor XML într-un template (model), în aceeași manieră în care se inserează adresele într-o scrisoare tip. Foile de stiluri CSS permit afișarea numai informațiilor declarate în documentul XML [9].

Foile de stiluri XSLT permit formatarea și afișarea atributelor și elementelor XML.

În sfârșit, foile de stiluri XSLT permit manipularea, reorganizarea și afișarea datelor de o manieră dinamică [9], ceea ce este imposibil de efectuat cu foile de stiluri CSS.

O foaie de stiluri XSLT (XSL) este un fișier text cu extensia .xsl. Fișierul de stiluri conține un set de reguli template. La rândul ei, o regulă template definește un „pattern” (element țintă), care corespunde elementelor din arborele sursă și un „template” [9]. Elementul template permite definirea modului de transformare și de afișare a nodurilor de date XML, sau elementele specificate prin atributul match al modelului [9].

1.5.2. XML Path Language – limbaj pentru adresarea fragmentelor XML

„Limbajul (de transformare XML) XSLT utilizează limbajul XPath pentru adresarea fragmentelor unui document XML” (extras din recomandarea W3C). XSLT permite crearea și aplicarea template-urilor (modelelor) unor documente sursă XML. Cu limbajul XPath (XML Path Language) este posibil de a selecta un nod (o resursă) al unui document XML pentru a-i aplica o transformare. Este posibil de a crea expresii XPath pentru a selecta datele XML. XSLT și XPath facilitează crearea unor transformări specifice. Este posibil de selectat elementele unui document XML pentru a le copia în documentul rezultant. Se poate sorta, selecta și manipula elementele în funcție de următoarele caracteristici: numele elementului, numele atributului, valoarea atributului, prezența unui element fiu/părinte particular [9].

Cu alte cuvinte XPath este un limbaj de expresii care se utilizează pentru a extrage porțiuni dintr-un document XML sau pentru a calcula diferite valori (șiruri de caractere, numere, sau valori logice) pe baza conținutului unui document XML. Versiunea actuală a limbajului este XPath 2.0, dar cea mai întâlnită versiune în prezent este versiunea 1.0 [2].

Limbajul XPath este structurat sub formă de arbore a documentului XML, oferind posibilitatea de a naviga în acest arbore, prin selecția nodurilor XML care satisfac diferite criterii. Cu alte cuvinte, XPath este un mic limbaj de interogare, iar anumite părți ale sale sunt folosite în specificațiile W3C pentru XML Schema și XForms [2].

1.7. Descrierea structurilor de date cu ajutorul XML

Limbajul XML este un limbaj structurat care permite descrierea majorității structurilor de date utilizate în prezent. În continuare vom propune scheme de descriere cu ajutorul XML a diferitor structuri de date.

Mulțime (SET):

<?xml version="1.0" encoding="Windows-1251"?>

<!– Mulțime –>

<Mulțime>

<Element_mulțime id="1">

</Element_mulțime>

<Element_mulțime id="2">

</Element_mulțime>

<!– . . . –>

<Element_mulțime id="N">

</Element_mulțime>

</Mulțime>

Vector (ARRAY):

<?xml version="1.0" encoding="Windows-1251"?>

<!– Vector –>

<Element_vector numar="1">

</Element_vector>

<Element_vector numar="2">

</Element_vector>

<!– . . . –>

<Element_vector numar="n">

</Element_vector>

</Vector>

Descrierile vectorului și mulțimii nu se deosebesc unul de altul. Elementele unui vector pot fi ordonate conform ordinii în descriere sau conform valorii atributului număr. Într-o mulțime ordinea nu este principială.

Arbore:

<?xml version="1.0" encoding="Windows-1251"?>

<!– Arbore –>

<Rădăcina>

<Arbore_11>

<Arbore_21>

</Arbore_21>

<Arbore_22>

</Arbore_22>

</Arbore_11>

<Arbore_12>

</Arbore_12>

</Rădăcina>

Structurile arborescente (fig. 1.1.) sunt naturale pentru modelul de date XML.

Fig. 1.1. Structura arborescentă.

Tabelul relațional:

<?xml version="1.0" encoding="Windows-1251"?>

<!– Tabel –>

<Tabelul_1>

<Înregistrare>

<Câmpul_cheie>Valoarea câmpului cheie</Câmpul_cheie>

<Câmpul_1>Valoarea câmpului 1</Câmpul_1>

<Câmpul_2>Valoarea câmpului 2</Câmpul_2>

</Înregistrare>

<!– . . . –>

<Înregistrare>

<Câmpul_cheie>Valoarea câmpului cheie</Câmpul_cheie>

<Câmpul_1>Valoarea câmpului 1</Câmpul_1>

<Câmpul_2>Valoarea câmpului 2</Câmpul_2>

</Înregistrare>

</Tabelul_1>

Un tabel conține o consecutivitate de înregistrări. Câmpurile înregistrării pot fi reprezentate în forma elementelor sau atributelor. Lucrul cu datele relaționale în formatul XML poate fi executat practic în orice tehnologie de lucru cu bazele de date, de exemplu ADO.NET.

În cazul schimbului cu datele relaționale în formatul XML poate să apară problema legată cu încărcarea cheilor primare și externe.

Tabele relaționale cu chei:

<?xml version="1.0" encoding="Windows-1251"?>

<Tabelul_1>

<Înregistrare>

<Cheia_primară>1</Cheia_primară>

<Câmpul_1>Valoarea câmpului 1</Câmpul_1>

<Câmpul_2>Valoarea câmpului 2</Câmpul_2>

</Înregistrare>

<!– . . . –>

</Tabelul_1>

<Tabel_subordonat>

<Înregistrare>

<Cheia_primară>1</Cheia_primară>

<Câmpul_3>Valoarea câmpului 3</Câmpul_3>

<Cheia_externă_a_tabelului_1>1</Cheia_externă_a_tabelului_1>

</Înregistrare>

<Înregistrare>

<Cheia_primară>2</Cheia_primară>

<Câmpul_3>Valoarea câmpului 3</Câmpul_3>

<Cheia_externă_a_tabelului_1>1</Cheia_externă_a_tabelului_1>

</Înregistrare>

<!– . . . –>

</Tabel_subordonat>

</Baza_de_date>

Așa o structură poate fi încărcată numai într-un SGBD, care permite înscrierea datelor în câmpurile cheie (această posibilitate nu au toate SGBD).

În cazul salvării tabelelor corelate în formatul XML e mai bine să le salvăm în forma unui arbore fără cheile primare și externe.

Tabele relaționale fără câmpuri chei:

<?xml version="1.0" encoding="Windows-1251"?>

<Baza_de_date>

<Tabelul_1>

<Înregistrare>

<Câmpul_1>Valoarea câmpului 1</Câmpul_1>

<Câmpul_2>Valoarea câmpului 2</Câmpul_2>

<Tabel_subordonat>

<Înregistrare>

<Câmpul_3>Valoarea câmpului 3</Câmpul_3>

</Înregistrare>

<Înregistrare>

<Câmpul_3>Valoarea câmpului 3</Câmpul_3>

</Înregistrare>

<!– . . . –>

</Tabel_subordonat>

</Înregistrare>

<!– . . . –>

</Tabelul_1>

</Baza_de_date>

În cazul încărcării într-o baza de date cheile e necesar să se genereze automat.

În cazul încărcării datelor în MS SQL Server pot fi utilizate așa numite scheme de adnotare.

Scheme de adnotarea reprezintă o extensie a schemelor XML. În schemele de adnotare se admit niște adnotări speciale, care stabilesc legătura datelor cu entitățile structurii relaționale: tabele, câmpuri, chei primare și externe, relații între tabele, datorită acestui fapt datele care se păstrează în MS SQL Server, pot fi apelate în forma unui document XML. De asemenea este posibilă încărcarea documentului pe baza unei scheme de adnotare.

Graful (legăturile se stabilesc în vârfuri):

<?xml version="1.0" encoding="Windows-1251"?>

<Vârful id="1">

<Date_despre_vârf/>

<Ieșiri>

<Ieșirea="2"/>

<Ieșirea="3"/>

</Ieșiri>

</Vârful>

<Vârful id="2">

<Date_despre_vârf/>

<Ieșiri>

<Ieșire vârful="1">

<Date_despre_legătură/>

</Ieșire>

</Ieșiri>

</Vârful>

<Vârful id="3">

<Date_despre_vârf/>

</Vârful>

</Graful>

Fig. 1.2. Graful (legăturile se stabilesc în vârfuri).

În loc de ieșiri pot fi utilizate intrări. Pentru grafurile neorientate e necesar de făcut referințe de la un vârf la altul.

În mod analog pot fi descrise și grafurile bipartite. Într-un graf bipartit există două clase de vârfuri și fiecare vârf este legat numai cu vârfuri de alt tip.

Putem utiliza descrierea grafului, în care vârfurile și legăturile se stabilesc aparte unul de altul.

Graful (vârfurile și legăturile se stabilesc în secții aparte ale documentului):

<?xml version="1.0" encoding="Windows-1251"?>

<Vârfuri>

<Vârf id="1">

<Date_despre_vârf/>

</Vârf>

<Vârf id="2"/>

<Vârf id="3"/>

</Vârfuri>

<Legături>

<Legătura vârful_1="1" vârful_2="2">

<Date_despre_legătura/>

</Legătura>

<Legătura vârful_1="1" vârful_2="3"/>

<Legătura vârful_1="2" vârful_2="1"/>

</Legături>

</Graful>

Așa o descriere e comod de utilizat atât pentru un graf orientat cât și un graf neorientat.

Pentru descrierea grafurilor este elaborată o specificarea separată GraphML.

Astfel, prin intermediul modelului de date XML este destul de simplu de descris majoritatea structurilor de date.

1.6. Avantaje și neajunsuri XML

Pe parcursul utilizării tehnologiei XML de către dezvoltatorii siturilor web au fost elucidate mai multe avantaje și neajunsuri ale acestei tehnologii, care pot ajuta unui începător să se orienteze în posibilitățile de utilizare a acestui limbaj. În continuare vom prezenta avantajele și neajunsurile de bază ale XML.

1.6.1. Avantaje XML [13]

XML (orientat la om) – reprezintă un format înțeles în același timp și omului și calculatorului.

XML susține codificarea Unicode.

În formatul XML pot fi descrise structuri de date complexe, cum ar fi înregistrări, liste și arbore.

XML – reprezintă un format de auto-documentare, care descrie atât structura și denumirile câmpurilor cât și valorile câmpurilor.

XML posedă o sintaxă strict determinată și anumite cerințele față de parsing-ul, ceea ce îi permite să rămână facil, efectiv și consecvent.

XML se utilizează pe larg pentru păstrarea și prelucrarea documentelor online și offline.

XML – reprezintă un format bazat pe standarde internaționale.

Structura ierarhică a XML este adecvată pentru a descrie aproape orice tip de document.

XML reprezintă un text simplu, liber de licențiere și oarecare alte restricții.

XML nu depinde de platformă.

XML reprezintă o submulțime a SGML. Deja este acumulată o experiență bogată de lucru cu acest limbaj și sunt create aplicații specializate.

XML nu impune cerințe privind amplasarea caracterelor într-un șir de caractere.

Unul dintre avantajele evidente ale XML este abilitatea de a-l folosi ca un limbaj universal de interogare a depozitelor de informații. Mai mult decât atât, XML-documentele pot servi drept o metodă de stocare a datelor, care include atât mijloace pentru parsarea informației cât și prezentarea ei pe partea de client (client-side).

XML permite efectuarea controlului corectitudinii datelor păstrate în documente, verificarea relațiilor ierarhice în interiorul documentului și stabilirea standardului unic pentru structura documentelor, conținutul cărora poate să difere. De aici rezultă faptul că îl putem utiliza pentru construirea sistemelor informaționale complexe, în care o întrebare preponderentă ar fi schimbul de informații între diferite aplicații care conlucrează în același sistem. Creând structura mecanismului de interschimbare a informațiilor de la începutul elaborării proiectului, manager poate să se debaraseze în viitor de multe probleme legate cu incompatibilitatea formatelor de date utilizate de diferite componente ale sistemului.

1.6.2. Neajunsuri XML [13]

Sintaxa XML este redundantă.

Mărimea documentului XML este mult mai mare decât reprezentarea binară a acelorași date (undeva de 10 ori).

Mărimea documentului XML este mult mai mare decât a unui document într-un format textual alternativ de transmitere a informației (de exemplu JSON) și îndeosebi în formate de date optimizate pentru utilizarea într-un caz concret.

Redundanța XML poate influența eficacitatea aplicației. Crește costul păstrării, prelucrării și transmiterii datelor.

Pentru un număr mare de probleme nu este necesară toată puterea sintaxei XML și se poate utiliza unele soluții mult mai simple și performante.

XML nu conține suportul tipurilor de date încorporat în limbaj. În el lipsesc noțiuni cum ar fi «numere întregi», «șir de caractere», «data», «valori logice» etc.

Modelul ierarhic al datelor propus de XML este mărginit în comparație cu modelul relațional și grafuri orientate pe obiect.

Spațiu de nume al XML este dificil de utilizat și de realizat în parsere XML.

Există alte formate textuale de date asemănătoare după posibilități cu XML, care sunt mai lizibile pentru om (YAML, JSON, SweetXML).

2. XML CA BAZĂ DE DATE

2.1. Compararea datelor XML cu date relaționale

Înainte de a precauta utilizarea XML în baze de date contemporane, vom efectua o comparație între structura datelor relaționale și date XML.

Într-o bază de date relațională informația se păstrează în forma de tabele, care constă din linii și coloane. Într-o coloană se păstrează date de un anumit tip pentru toate înregistrările tabelului. Fiecare înregistrare a tabelului este prezentată printr-o linie. Ordinea liniilor în tabel nu este legată cu ordonarea datelor spre deosebire de XML, în care ordinea internă a documentului influențează, de exemplu date întoarse de către așa o funcție XPath cum ar fi position() [2].

Numai date relaționale elementare pot fi păstrate într-un tabel; o bază de date relațională tipică are o mulțime de tabele cu relații logice complexe între ele. Date din diferite tabele sunt corelate cu ajutorul cheilor. De exemplu, în tabelul Customer poate să apară câmpul (sau coloana) CustomerID. Identificarea comenzilor unui utilizator concret se facilitează utilizând o valoare corespunzătoare din coloana CustomerID a tabelului Orders [2].

Relații între date pot fi “unu-la-unu” (de exemplu, un copil poate să aibă un singur tata), “unu-la-mulți” (un copil poate avea doi părinți (mama și tata), un client – mai multe comenzi) sau “mulți-la-mulți” (o marfă poate fi în mai multe comenzi, în fiecare comandă pot fi diferite mărfuri) [12]. Fiecare din aceste relații poate fi reprezentată prin păstrarea datelor în două sau mai multe tabele corelate. Baze de date relaționale de obicei nu au ierarhii spre deosebire de documente XML, care au ierarhizarea interioară, după cum ilustrează modelul de date XPath, DOM sau XML Infoset. Datele XML sunt ordonate interior, după cum se arată în următorul exemplu.

</Orders>

Ierarhia interioară a XML este o condiție, determinată de către criteriu de construire corectă a documentului XML. Păstrarea chiar și acestor date elementare într-un tabel relațional va duce la pierderea ordonării lor.

2.2. Metode de păstrare a datelor XML

Necesitatea păstrării datelor XML nu a apărut eventual. Până la invenția XML a fost acumulat un volum enorm de date păstrate și majoritatea acestor date a fost păstrată în baze de date clasice.

2.2.1. Păstrarea XML în niște sisteme de fișiere

Însăși ideea documentului XML presupune păstrarea informației pe disc asemănător păstrării oricăror alte documente, de exemplu, pe masa de lucru. Multe aplicații întotdeauna păstrează documentele XML în forma de fișiere. Păstrarea documentelor XML în forma de fișiere este naturală din motiv că organizarea ierarhică a sistemului de fișiere se aseamănă mult cu organizarea ierarhică a documentului XML. Se observă o asemănare între sintaxa URL sau calea fișierelor și expresii elementare XPath [11].

În continuare vom precauta unele limitări de păstrare a documentelor XML într-un sistem de fișiere.

Mărimea documentului

Păstrarea documentelor XML pe disc are sens în cazul când avem de lucrat pe WWW cu niște documente statice de mărime mică. Sisteme de fișiere contemporane pot să servească ca un suport efectiv pentru fișiere de mărime GO (Giga Octeți); astfel, cunoscând calea spre un document XML, putem obține un acces efectiv către informația păstrată în acesta. Dacă întotdeauna avem nevoie de conținutul întregului document, acest sistem lucrează destul de bine. Însă, în cazul când avem nevoie numai de o parte a informației dintr-un document mare, prin intermediul DOM sau XPath, atunci vor apărea mari probleme legate cu cheltuieli de prisos ale memoriei în legătura cu necesitatea citirii întregului document înainte de a extrage din acesta a părții necesare. În afară de aceasta, va fi necesară și o analiză a acestor documente de fiecare dată, când ne adresăm la acestea prin DOM sau XPath [2].

Dacă totul de ce avem nevoie reprezintă un lucru simplu cu un document XML, fără modificarea sau transformarea a acestuia în WWW, atunci e mai comod să-l pregătim de lucru în forma XML.

Actualizări

Următoarea problemă importantă apărută în cazul păstrării documentelor XML pe disc este actualizări. Dacă gestionarea documentelor XML se realizează manual pe desktop sau web-server, probleme cu actualizări nu prezintă mari greutăți [2]. Dar în cazul asigurării posibilității introducerii actualizărilor automat, de către aplicația sau mai mulți utilizatori, vom avea necesitatea de a întreprinde un șir de măsuri adăugătoare pentru efectuarea actualizărilor. Una din metode de rezolvare a acestei probleme este păstrarea documentelor în repozitoriu WebDAV, care rezolvă probleme de blocare în cazul adresării paralele. Pentru utilizarea acestei metode poate fi utilizat un sistem de gestionare a versiunilor, cum ar fi Subversion (http://subversion.tigris.org/).

Subversion poate funcționa ca repozitoriu WebDAV și pune la dispoziție toate posibilitățile de gestionare a versiunilor, inclusiv fixarea istoriei modificărilor documentelor. Pentru un set de aplicații aceasta este o posibilitate importantă. Ce n-am face pentru actualizarea documentelor, vom precauta întrebările detalierii informației. Dacă majoritatea actualizărilor lucrează cu porțiuni mici ale documentelor mari, vom avea mari cheltuieli de prisos ale memoriei din motivul necesității înlocuirii unui document întreg cu versiunea sa actualizată. În aplicațiile tranzacționale, acest lucru înseamnă, de asemenea, că, atunci când se actualizează unul dintre nodurile, urmează să fie blocat întreg documentul, dar aceasta poate provoca consecințe grave pentru productivitatea aplicațiilor [2].

Indecși

Ultima problemă care poate să apară în cazul păstrării documentelor pe disc este interogări. De exemplu, dacă într-o colecție mare de documente se cere de găsit toate documentele scrise de un anumit autor, va apărea necesitatea realizării indexării de un anumit fel.

Dacă pentru indexarea se utilizează mai multe câmpuri predefinite, în calitatea de index poate fi utilizată structura de cataloage: pentru indexarea autorilor fiecare autor are catalogul propriu. Dacă în plus se cere indexarea după data, se poate de adăugat legăturile simbolice pentru crearea cataloagelor virtuale pentru date.

Pentru a crește numărul de câmpuri sau să ofere sprijin pentru căutare full-text, va trebui să utilizeze o altă metodă de indexare. Dacă se utilizează un sistem de control al versiunii așa cum este descris în secțiunea anterioară, se poate de profitat de oportunitățile care oferă un astfel de sistem. De exemplu, atunci când se utilizează Subversion, se poate de obținut cu ușurință o listă de documente pentru o anumită versiune cu modificările efectuate de un anumit utilizator, modificările efectuate dintre oarecare două date, etc. [2]. Un avantaj al Subversion îl constituie faptul că comenzile acestui sistem de gestionare a aversiunilor au opțiuni pentru formatarea rezultatelor în forma XML; iar aceasta înseamnă, la rândul său, că rezultatele obținute pot fi formatate cu ajutorul XSLT pentru reprezentarea pe pagina web.

Dacă, în primul rând, pe noi ne interesează căutarea full-text, putem să utilizăm mecanismul de căutare asemănător cu Lucene (http://lucene. apache.org/ ). Lucene se livrează împreună cu API, care permite de a defini, ce elemente ar trebui să fie indexate și modul în care acestea ar trebui să fie tratate. Acesta susține eficient o colecție mare de documente și oferă posibilități cunoscute pentru majoritatea utilizatorilor (deoarece aceste posibilități sunt aceleași ca și la cele mai multe motoare de căutare în WWW) [2].

Așa instrument ca XQuery de asemenea poate funcționa cu colecțiile documentelor XML păstrate pe disc, de exemplu XQEngine (http://xqengine.sourceforge.net/).

2.2.2. Construirea soluției proprii

Deși cele mai multe dintre întrebările pot fi rezolvate, stocarea documentelor XML pe un disc cu acces de scriere și indecșii necesită un volum mare de lucru, îndeosebi de lucru legat de integrarea. Baze de date XML în acest sens reprezintă o soluție mult mai integrată.

Desigur, această integrare este un compromis, astfel încât vom putea găsi baza de date XML ca fiind o soluție mai rea decât cea care o putem dezvolta în conformitatea cu cerințele noastre. În calitate de exemplu, putem lua sistemul de gestionare a versiunii: bazele de date XML de obicei nu au toate oportunitățile care există în sistemele de gestionare a versiunii, și nu există nici căutarea full-text. Pe de altă parte, utilizarea unei baze de date XML sigure, în loc de elaborarea programaturii pentru aceeași funcționalitate în cazul păstrării documentelor în sistemul de fișiere, poate să ducă la economisirea timpului.

2.2.3. Utilizarea XML cu bazele de date clasice

Baze de date relaționale reprezintă unul din cele mai populare moduri de păstrare a datelor. Ele sunt bine adaptate pentru păstrarea datelor structurate, păstrează un volum enorm de informații și sunt bine cunoscute majorității dezvoltatorilor. Toate acestea arată pe SGBD ca fiind niște instrumente destul de bune pentru utilizarea în comun cu XML.

2.2.4. Obținerea XML din bazele de date relaționale

Un număr mare de situri web HTML și XHTML utilizează, în mod direct sau indirect, date relaționale. În acest domeniu se utilizează pe scară largă combinație de PHP cu baze de date MySQL sau ASP.NET cu SQL Server sau Microsoft Access. Acestea sunt de obicei păstrate ca tabele relaționale, iar programatorul scrie cod pentru a crea un HTML sau XHTML, uneori cu utilizarea XML ca un pas intermediar [2].

XHTML reprezintă limbajul aplicației XML. Crearea de pagini web XHTML din date relaționale demonstrează unul dintre modurile în care aceste date pot fi utilizate pentru a produce un cod XML pentru prezentarea de date. Prevalența acestei tehnologii este cea mai bună dovadă a posibilității de mapare a datelor relaționale în structura ierarhică XML și transferul acestor structuri utilizatorului. De exemplu, dacă utilizați PHP pentru a extrage date din mai multe tabele în MySQL pentru prezentarea lor utilizatorului, sub forma unei pagini web, dezvoltatorul mai degrabă n-ar vrea să prezinte date sub formă de tabel, similar cu structura bazei de date. Cel mai probabil, acesta va transforma structura dezordonată, neierarhică a datelor relaționale în ceva, cel puțin ordonat și ierarhic, deoarece aceste date pot fi reprezentate cu succes sub formă de pagini web HTML și XHTML, care sunt ele însele ierarhice.

Dacă unii programatori găsesc modalități de a transforma date relaționale în XML, nu este nimic surprinzător în faptul că dezvoltatorii de diferite baze de date au găsit, de asemenea, o oportunitate de a intra pe piața în creștere a XML și de a oferi o posibilitatea de a exporta datele relaționale stocate în XML. De fapt, multe baze de date relaționale permit utilizatorilor să obțină XML din date stocate în tabele relaționale [2].

2.2.5. Transferarea XML în bazele de date relaționale

În mod similar, multe SGBD au capacitatea de a obține date XML de la utilizatori, să le transforme în forma relațională și apoi să le salveze în tabele relaționale. În funcție de faptul se salvează sau nu metadatele legate cu ordonare în procesul de transformare a XML în informația prelucrabilă de o bază de date relațională, poate fi posibil să se recupereze ulterior documentul XML original. În majoritatea cazurilor așa o recuperare fixă a documentului nu este necesară [11].

Corelarea datelor

Scheme de corelare a datelor, dat fiind faptul că în cadrul aplicațiilor trebuie să coexiste mai multe reprezentări ale acelorași date, automatizează maparea dintre aceste reprezentări. Reprezentări, sprijinite de cele mai multe ori de scheme de corelare a datelor, sunt XML, baze de date SQL și obiecte. Scheme de corelare a datelor care pot mapa direct reciproc XML și baze de date SQL, includ ADO.NET (http://msdn.microsoft.com/data/ref/adonet/) în lumea Microsoft și Castor (http://www.castor.org/) în comunitatea de software Java cu open source. Ei sunt foarte flexibile, pot fi configurate în moduri diferite și sunt o soluție bună la problema de reprezentare a conținutului bazelor de date existente în formatul XML [2].

În plus la astfel de corelări directe a XML și a bazelor de date relaționale, pot fi întâlnite și scenarii mai complexe, cum ar fi scenarii în cazul în care baza de date relațională se utilizează ca bază pentru obiectele, care, la rândul său generează documente XHTML sau XML. Asemenea scenarii se bazează doar pe schema de corelare a datelor utilizată pentru maparea bazelor de date relaționale pe obiecte. În funcție de situație XML sau XHTML se generează manual cu ajutorul șabloanelor sau altei biblioteci de corelare a datelor.

2.2.6. Baze de date XML native

Bazele de date XML native se utilizează pentru păstrarea datelor în formatul XML. O bază de date XML nativă poate realiza XML cu utilizarea modelului de felul XML Infoset, XML DOM, XPath sau Simple API for XML (SAX). Ea, de asemenea păstrează și diferite aspecte ale documentului XML, cum ar fi ordinea în document [2].

Tehnologia bazelor de date relaționale în prezent este bine dezvoltată, are o bază teoretică solidă, mai multe decenii de aplicare practică în produsele program lard răspândite. Bazele de date XML native în schimb reprezintă un produs destul de nou; ei n-au așa o baza teoretică bogată ca a bazelor de date relaționale, ei se află în etapa de dezvoltare și se vor afla în aceasta încă cel puțin câți-va ani. Care n-ar mecanismul de păstrare a informației, ce stă la baza acestor baze de date, baza de date XML nativă pune în corespondența unui document XML un model de stocare. Această corespondența poate diferenția serios în diferite baze de date, de exemplu să depindă de detaliile de conversie a documentului XML într-un relațional.

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 [2].

Bazele de date native XML sunt de obicei folosite pentru a stoca documente centrate pe documente [1]. 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 [1].

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 [1].

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ă nici o 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).

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. [1].

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 nici o 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ă.

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 nici o 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 [1].

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ă [1]. 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.

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 [1].

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.

Actualiză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” [1]. 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 [1].

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.

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 [1].

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 [1].

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 [1].

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.

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.

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.

2.2.7. Analiza comparativă a bazelor de date relaționale și baze de date native XML

3. APLICAȚIA WEB „MAGAZIN ONLINE”

3.1. Descrierea domeniului de cercetare a unui magazin online

Magazinul online, elaborat în cadrul tezei date, servește drept instrument de demonstrare a posibilităților XML, utilizat în calitate de bază de date. Cu alte cuvinte, magazinul elaborat poate fi considerat mai degrabă ca un exemplu de studiu, decât o aplicație reală, utilizată în scopuri comerciale.

3.1.1. Funcțiile de bază ale unui magazin online

Sistemul de automatizare a magazinului reprezintă un mijloc efectiv, care permite de a controla și a gestiona operativ procesul de rulare a mărfurilor într-un magazin separat. Automatizarea magazinului este necesară pentru ridicarea nivelului de deservire a cumpărătorilor și, facilitarea lucrului colaboratorilor magazinului: depozitari, casieri, director etc.

În rezultat, a fost proiectată o componentă a sistemului de automatizare în forma unui magazin online, care facilitează activitatea cumpărătorului prin comoditatea efectuării cumpărăturilor, fără necesitatea de a fi prezenți în oficiul magazinului, ci având numai accesul la Internet oriunde și oricând. Acest serviciu permite cumpărătorului de a economisi timpul prețios, de a studia cu atenție caracteristicile mărfurilor necesare ș.a. Internet-magazin este una din cele mai plăcute și utile servicii ale Internet-ului.

3.1.2. Avantajele oferite de un magazin online:

– lucrează non-stop, fără zile de odihnă și fără prânz;

– dezvoltarea dispozitivelor mobile pentru accesul la Internet (telefon mobil, laptop etc.).

– un magazin online poate funcționa autonom, practic fără deservire;

– magazinul online permite amplasarea în el, fără limite, a mărfurilor oferite;

– proprietarul magazinului online poate da în arenda suprafețele sale virtuale;

– termenul și costul creării unui magazin online este cu mult mai mic decât a unui magazin obișnuit;

– pentru lansarea unui magazin online nu se cere obținerea permisiunilor și licențelor, nu este nevoie de control din partea autorităților etc.

3.1.3. Arhitectura unui magazin online

Arhitectura magazinului online trebuie să asigure o navigare mai comodă și mai rapidă a vizitatorilor, în scopul căutării informației necesare, și funcțiile de administrare a magazinului. În așa fel, arhitectura magazinului online constă din componenta client, accesibilă vizitatorilor sitului, componenta program pentru automatizarea operațiilor în cadrul magazinului online și componenta de administrare a magazinului (fig. 3.1).

Fig. 3.1. Arhitectura magazinului online

Componenta operațională

Componenta program a arhitecturii magazinului online reprezintă legătura biunivocă între componenta operațională și componenta server.

În componenta operațională se cercetează mediul de dezvoltare a magazinului online.

Magazinul online este elaborat, utilizând limbajul PHP. Pentru a justifica alegerea, a fost efectuată o analiză comparativă a PHP cu așa medii, cum ar fi Perl, ASP.NET, ColdFusion și Java.

Baza de date, utilizată în magazinul online, practic, totalmente reprezintă o listă XML. Pentru a justifica alegerea a fost efectuată analiza lui comparativă cu baza de date SQL.

3.2. Analiza comparativă a diferitor medii de dezvoltare a aplicațiilor web

РНР și Perl

Limbajul Perl reprezintă un interpretator și a apărut mult mai devreme decât Web. Cu apariția internetului, limbajul Perl s-a dovedit a fi un instrument comod pentru crearea paginilor Web dinamice. A cunoscut o largă răspândire datorită prezenței sale pe fiecare serverul Web, deoarece, practic toate acestea au funcționat sub gestiunea UNIX, și o alternativă a acestui limbaj o constituia numai limbajul С.

РНР are o sintaxă comparativ mai simplă decât Perl și, în plus, oferă aceeași funcționalitate. În afară de această limbajul Perl este mai redundant, datorită faptului, că a fost conceput pentru elaborarea diferitor aplicații, ci PHP a fost conceput din start pentru internet.

РНР и Java

În general, se deosebesc limbajul Java și tehnologia Java. Limbajul Java reprezintă un limbaj asemănător cu С și a fost elaborat ca „C++ îmbunătățit”. Tehnologia Java include componenta client și componenta server, oferă acces la baze de date, de aceea e mai corect să facem comparație tehnologiei Java cu grupul Apache/PHP/MySQL. Avantajele principale ale acestei tehnologii sunt: portabilitate cross-platformă și limbaj orientat pe obiect care permite crearea aplicațiilor complexe. Printre neajunsuri pot fi evidențiate: executarea lentă, consumul mare de memorie și complexitatea dezvoltării aplicațiilor Web comparativ cu РНР. Cu toate acestea, РНР practic nu se deosebește de Java în ce privește flexibilitatea și scalabilitatea aplicației și reprezintă un mediu de programare free.

РНР и ASP.NET

ASP (Active Server Pages) reprezintă un limbaj de scriptare de la Microsoft. Limbajul ASP a fost inferior РНР după mai multe parametri, unul din ei fiind timpul de executare a scriptului, această problemă a fost rezolvată cu apariția tehnologiei ASP.NET.

Principal avantaj a ASP.NET constă în posibilitatea de a utiliza toată puterea interfeței Windows pentru dezvoltarea aplicațiilor Web. ASP.NET este integrat în tehnologia NET a companiei Microsoft și oferă posibilitatea de a utiliza orice limbaj de programare a mediului de execuție NET. Codul aplicației Web pe baza ASP.NET se compilează într-un limbaj intermediar MSIL (Microsoft Intermediate Language). Spre deosebire de Java ASP.NET nu asigură portabilitate cross-platform, însă asigură independență de limbajul de programare, dezavantajul fiind imposibilitatea rulării aplicațiilor în alte sisteme de operare decât Windows, dar aplicații Web uneori chiar este imposibil de utilizat fără navigatorul Internet Explorer. De aceea în sensul portabilității РНР are avantaje față de ASP.NET. Alt avantaj fiind posibilitatea corectării rapide a erorilor depistate. Încă un avantaj a РНР este facilitatea acestuia pentru dezvoltatorii începători a aplicațiilor Web.

În așa fel, alegând între ASP.NET și РНР trebuie să reiese din problema în cauza. Dacă pentru o rețea Intranet corporativă, unde majoritatea stațiilor server și client funcționează sub gestiunea sistemului Windows, e mai convenabil de utilizat ASP.NET, atunci pentru dezvoltarea unui sit Web, plasat în Internet, e mai comod de folosit РНР.

РНР и ColdFusion

Pachetul ColdFusion este elaborat de firma Allaire și este destinat pentru dezvoltarea rapidă a documentelor Web interactive și dinamice prin prelucrarea informației, obținute din baza de date. Neajunsul ColdFusion constă în portabilitate joasă. РНР funcționează practic pe toate platforme, iar ColdFusion numai pe patru: Win32, Solaris, HP/UX și Linux. În plus, ColdFusion, la fel ca și ASP, reprezintă un produs comercial. ColdFusion spre deosebire de РНР cere mai multe resurse. Avantajul ColdFusion îl constituie un mediu de dezvoltare bine integrat și, ca urmare, un limbaj mai simplist, decât în РНР.

Utilizarea listei XML în calitate de baza de date

În calitate de catalogul mărfurilor a magazinului online se utilizează o bază de date, bazată pe XML. Multe avantaje ale XML au fost deja menționate în această lucrare, acum vom aminti unele din acestea:

– permite ușor de păstrat documente cu numărul mare de diferite formate;

– reproduc exact documentul XML original;

– asigură performanțe înalte pentru interogări, dacă rezultatele lor vin în concordanța cu structura ierarhică a datelor XML;

– suportă limbaje de interogare, care iau în considerație stiluri XML.

Neajunsuri:

– lipsa multor funcții de gestiune și administrare, care sunt în orice SGBD relațional;

– dificultăți de integrare cu tipuri de date non-XML;

– o performanță joasă pentru interogări, care necesită sumarea datelor sau sunt corelate cu date care sunt în exteriorul ierarhiei XML;

– API speciale pentru formarea interogărilor și programarea.

Spre deosebire de baze de date relaționale SQL, într-o bază de date ierarhică XML reprezentarea informației este în forma de text, ceea ce permite editarea ei comodă prin intermediul Notepad-ului standard, aplicația MS Excel sau orice alt editor. Facilitatea utilizării acestui limbaj și posibilitatea transformării informației din formatul XML în practic orice alt format de bază de date a implicat folosirea lui în calitate de bază de date pentru aplicația dată.

3.3. Web server

Componenta server conține amplasarea magazinului online pe situl provider-ului, tehnologiile necesare, utilizate pentru dezvoltarea magazinului online. Pentru dezvoltarea și testarea inițială a magazinului se va utiliza un server local, care va facilita semnificativ sistemul de depanare a funcționării magazinului.

Denwer reprezintă un pachet de programe pentru dezvoltarea unui sit pe calculatorul local, fără acces la Internet. Proiectul Denwer include:

– Apache, SSI, mod_rewrite, mod_php;

– PHP cu susținerea GD și MySQL;

– MySQL cu susținerea tranzacțiilor (mysqld-max);

– sistemul de gestiune a host-urilor virtuale, bazat pe template-uri;

– sistemul de gestiune a lansării și stopării;

– phpMyAdmin – sistemul de gestiune MySQL prin interfața Web;

– nucleul Perl fără biblioteci standard;

– emulator sendmail, permite funcționarea în comun cu PHP și Perl;

– instalator.

Principalul avantaj al Denwer îl constituie o instalare ușoară și comodă, simplitatea utilizării. Fără asemenea pachete ar fi necesară instalarea separată a fiecărei din programe enumerate și configurarea lor pentru interacțiune corectă între ele. În plus, nu e nevoie de cheltuieli pentru hosting în timpul dezvoltării aplicațiilor Web, deoarece toate lucrările de testare și depanare a sitului se efectuează pe calculatorul local.

3.4. Structura generală a aplicației

Componenta de administrare

Administrarea conține instrumente de control al magazinului online și include setări generale ale magazinului:

– setări generale ale magazinului: denumirea magazinului, adresa, telefon, adresa e-mail etc.;

– setări formei de înregistrare a clientului în magazinul online;

– setări generale de livrare și ambalare a mărfii;

– setările depozitului;

– setările logo-urilor, fișierelor, în care se va înscrie informația de serviciu;

– setări ale formatului de afișare a mărfii în magazinul online;

– setări ale catalogului de mărfuri, adică adăugarea, ștergerea, editarea mărfii și categoriei de mărfuri, etc.;

– gestionarea comenzilor și clienților;

– adăugarea, ștergerea, modificarea cursului valutar;

– rapoarte statistice referitoare la funcționarea magazinului online;

– copierea de rezervă a bazei de date, comenzi nefinisate, interogări de căutare, etc.

În teza dată componenta de administrare oferă administratorului posibilitatea de a gestiona cu conținutul catalogului mărfurilor – adăugarea și ștergerea mărfurilor, descrierilor și fotografiilor lor, modificare costului mărfurilor.

Componenta client

În componenta client a arhitecturii se elaborează interfața cu clientul potențial care trebuie să fie prietenoasă, clară, ușor de utilizat.

Analizând funcționarea altor magazine online, deja funcționale, a fost făcută concluzia, ce trebuie de realizat obligatoriu în cadrul proiectului.

Vitrina magazinului va fi proiectată astfel, încât cumpărătorul să poată ușor să găsească marfa necesară și informația despre ea (poza, descriere).

Mărfuri vor fi divizate în grupe, va fi asigurată posibilitatea căutării mărfurilor pe categorii.

Informația despre mărfuri se va încărca dintr-un fișier XML.

Pentru comoditate va fi adăugată o secție specială, care va conține mărfuri, grupate după popularitate. Această secțiune se va afișa pe pagina principală a sitului.

La crearea comenzii cumpărătorul introduce informația de contact: nume, prenume, adresa livrării și telefon. După înregistrare cumpărătorului i se va afișa o fereastră de confirmare a cumpărăturii și date salvate.

Elaborarea algoritmului de funcționare a magazinului online

Accesând situl magazinului online, se deschide pagina principală, unde este afișată categoria celor mai populare mărfuri.

Trecerea de la o categorie la altă este posibilă prin intermediul meniului «Catalogul mărfurilor», la fel și cu ajutorul meniului orizontal, în partea de sus a ferestrei, în care se afișează cele mai populare categorii.

După alegerea mărfii, clientului i se propune oformarea cumpărăturii, în care scop se cere completarea formularului cu informația de contact, cu indicarea numelui, prenumelui, adresei de livrare și a telefonului cumpărătorului. După verificarea datelor este necesar de a confirma comanda.

Informația despre comanda efectuată se prelucrează de către managerul magazinului și se transmite spre executare.

3.5. Proiectarea și realizarea programată a magazinului online

3.5.1. Principii de dezvoltare a interfeței

Interfețele Web sunt comode prin faptul că oferă posibilitatea colaboratorilor, care sunt în diferite oficii, de a lucra în comun.

Interfața reprezintă o frontieră între niște obiecte independente care interacționează. Interfața determină parametri, proceduri și caracteristici de interacțiune a obiectelor.

Interfața utilizatorului, la rândul său, reprezintă niște elemente și componente ale programului care sunt capabile să influențeze interacțiunea utilizatorului cu soft-ul. Și anume:

mijloace de afișare a informației, informația afișată, formate și coduri;

regimuri de comandă, limbajul utilizator-interfață;

instrumente și tehnologii de introducere a datelor;

dialoguri, interacțiunea și tranzacții între utilizator și calculator;

feed-back cu utilizator;

suport de luare a deciziilor într-un domeniu concret;

ordinea de utilizare a programului și documentației acesteia.

Există câteva reguli simple, care permit interfeței magazinului să fie clară pentru vizitator:

Cu cât mai simplu cu atât mai bine. Acest principiu presupune că trebuie să fiu utilizat minimum necesar de materiale pentru cunoașterea vizitatorului cu oferta magazinului. Nu se recomandă de utilizat secvențe sonore și animația, în scopul măririi vitezei de încărcare a sitului. Grafică trebuie să fie rapid încărcabilă, clară, textul scris cu un font comod de citit, etc.;

Cumpărătorul fără greutăți trebuie să găsească marfa, care îl interesează, și informația despre el (descriere, poze). Pe pagina principală ar fi binevenită amplasarea informației despre activitatea magazinului și informații de contact;

Mărfuri trebuie divizate în grupuri. Pentru fiecare marfă trebuie de prevăzut descrierea și poze.

Lucrul atent cu culori. Culori incorect aplicate pot să influențeze negativ lucrul utilizatorului cu program, pe când culorile aplicate corect fac lucru cu programul comod și plăcut.

Conducându-se de aceste principii, s-a hotărât de a pune accent pe simplitatea și informativitatea interfeței. În așa fel, cumpărătorul potențial, nimerind pe sit, obține informația despre marfa, despre metoda de achitare a comenzii, despre condiții și termenii de livrare etc.

În magazinul online se cere să se realizeze o căutare rapidă și comodă a mărfii necesare, în scopul economisirii timpului cumpărătorului, o navigare comodă prin sit.

Gama de culori va corespunde tematicii tehnicii de calcul, care se vinde în magazinul online. Pozele mărfurilor vor avea mărimea necesară pentru a transmite claritatea imaginilor și detaliile mărfurilor corespunzătoare.

3.5.2. Realizarea programată

Întreagă funcționare a sitului este susținută de câteva zeci de fișiere cu codul sursă. Ierarhia fișierelor este prezentată în figura 3.2.

Fig. 3.2. Ierarhia fișierelor sursă.

În catalogul rădăcină a sitului se află două fișiere: index.php și marfa.xml. Primul se încarcă nemijlocit în navigator, când utilizatorul intră pe sit, și determină toată funcționalitatea sitului. Al doilea reprezintă catalogul mărfurilor.

Dosarul catalog conține poze pentru toate mărfurile, reprezentând niște fișiere grafice cu extensiile .jpg, .gif, .bmp, .png.

În dosarul includes se află fișiere, care asigură funcționarea sitului: conțin funcții logice de procesare a evenimentelor, funcții de conectare a altor fișiere, constante de inițializare și informația despre sit.

În dosarul img se află fișiere grafice, utilizate pentru design-ul sitului: fundaluri, pictograme ale butoanelor, pictograma sitului. În dosarul style sunt plasate fișiere cu tabele de stiluri ale aplicației. Pentru modificarea stilului interfeței magazinului online, este destul să schimbe numai aceste fișiere și să încarce în dosarul img alte imagini.

În dosarul admin se află fișiere care asigură funcționarea componentei administrative a sitului.

Realizarea componentei utilizatorului

Pentru asigurarea funcționării magazinului online, orientate la clienții acestuia, se utilizează toate fișierele proiectului cu excepția dosarului admin. În continuare vom descrie fișierele de bază, care formează logica proiectului și conțin diferite elemente ale paginilor proiectului.

index.php

Fișier index.php determină amplasarea vizuală a elementelor sitului și locul în care trebuie plasate diferite componente și module. Fișier reprezintă o combinare a PHP și HTML.

În partea PHP se descriu tipul codificării și stilul paginilor, se inițializează conectarea funcțiilor utilizate:

include("./includes/functions.php");

În partea HTML se descrie marcarea paginilor. Între taguri <head></head> sunt amplasate hiperlegături către fișierele conectate, fișier cu tabelul de stiluri CSS, titlul sitului, afișat în fila navigatorului:

<head>

<title>MyShop</title>

</head>

În blocul <body> este amplasat blocul antetului sitului header. Prin acesta este afișat titlul sitului pe un fundal anume și meniul orizontal.

Urmează blocul panoului din stânga sitului, în care prin constanta PAGE_MENU se încarcă meniul vertical al sitului cu categoriile mărfurilor:

</div>

Se deschide cel mai principal bloc al conținutului, în care se schimbă dinamic informația afișată în dependență de acțiunile cumpărătorului. În acest bloc se încarcă fișierul main.php, care va fi descris în acest paragraf:

<?php include("./includes/main.php"); ?>

</div>

Afișarea blocului footer, destinat pentru amplasarea informației despre dreptul de autor și hiperlegătura cu pagina principală a sitului:

<b style="color:#3399FF; margin-bottom:auto;">@Created by Cebanu Constantin in 2015</b>

</div>

marfa.xml

În acest fișier se păstrează în formatul XML catalogul mărfurilor oferite de magazinul online. Conținutul fișierului are următoarea formă:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>

<?xml-stylesheet type="text/css" href="style/bootstrap.min.css"?>

<?xml-stylesheet type="text/xml" href="style/xml-style.css"?>

<marfa>

<type>Monitoare</type>

<descriere>18.5" AOC LED e970Swn Black (5ms, 20M:1, 200cd, 1366×768, VESA)</descriere>

<foto>http://MyShop.me/catalog/Monitoare2.jpg</foto>

</marfa>

…

</Table>

Aici este descris tabelul mărfurilor cu câmpurile, incluse între tagurile corespunzătoare: <type>, <name>, <descriere>, <foto>, <price> și <cantitate>. Acest fișier poate fi editat și într-un editor de textte și prin intermediul tabelelor electronice, de exemplu, Microsoft Excel. În continuare vom descrie mai detaliat principiile de lucru a administratorului cu acest fișier prin componenta administratorului.

functions.php

Acest fișier inițiază conectarea fișierelor cu funcții pentru prelucrarea evenimentelor și fișierul config.php.

config.php

Fișierul config.php se utilizează pentru definirea constantelor, utilizate în index.php, în texte ale mesajelor poștei electronice și în informația despre situl.

main.php

Fișierul main.php prelucrează evenimente și definește modurile de comportare a sitului în cazul diferitor acțiuni ale cumpărătorului.

În așa fel, la selectarea unui punct al unuia din meniuri se inițiază acțiunea list și se transmite controlul în funcția get_cat_xml(). În calitate de parametrul acestei funcții servește denumirea categoriei selectate. În mod analog cu acțiunile buy și multum:

$action = $_GET['act'];

if ($action == 'list'){ get_cat_xml($_GET['cat']); };

if ($action == 'buy') { shop_buy($_GET['item'],$_GET['price']); };

if ($action == 'multum') { shop_say_multum (

$_POST['item'],

$_POST['price'],

$_POST['name'],

$_POST['addr'],

$_POST['phone'],

$_POST['cantitate'] );

};

În cazul altor activități se transmite controlul în funcția get_cat_xml(), în calitate de parametru se transmite categoria default – cele mai populare mărfuri.

ELSE { get_cat_xml('default'); };

get_cat.php

Acest fișier conține funcția get_cat_xml(), care inițiază ieșirea la pagina tabelului de mărfuri, corespunzător categoriei care se indică ca parametru. Aici se descrie forma de afișare a informației despre marfa: la început denumirea cu preț între taguri de titlu <h2></h2>, mai departe – poze și descriere. Toate valorile datelor despre marfa se încarcă din fișierul bazei de date marfa.xml:

$marfa_base = simplexml_load_string(implode('',file('./marfa.xml')));

Tot aici, la stânga fiecărei mărfuri, se afișează butonul „Cumpar”, utilizat pentru inițierea acțiunii buy.

shop_buy.php

Fișierul shop_buy.php conține funcția cu același nume pentru prelucrarea evenimentului buy. Aici se descrie forma comenzii și se indică, că la trecerea de la această pagină activând butonul „Cumpar” se inițiază acțiunea multum cu trecerea ulterioară către funcția shop_say_multum():

…

</div>

shop_say_multum.php

În acest fișier se află funcția shop_say_multum() care prelucrează parametrii obținuți și, în dependență de acestea, execută una din două acțiuni:

dacă măcar unul din parametri name, addr sau phone nu conține informația:

if ($name == '' OR $addr == '' OR $phone == '')

afișează un mesaj cu avertizare despre faptul că nu toate datele sunt introduse în forma comenzii;

dacă toți parametrii sunt introduși, atunci inițiază funcția shop_mail() și afișează un mesaj cu confirmarea comenzii și propune cumpărătorului să treacă la pagina principală.

shop_mail.php

În fișierul shop_mail.php funcția cu același nume formează textul mesajului către managerul magazinului despre cumpărarea unei mărfuri și trimite acest mesaj prin poșta electronică, utilizând în calitate de adresa magazinului și destinatarului constantele respective, descrise în fișierul config.php.

În cazul utilizării serverului local Apache în componența proiectului Denwer, mesaje se formează în dosarul C:\WebServers\tmp\!sendmail în forma fișierelor cu extensia .eml. În denumirea fișierului de mesaj se indică data și ora completă de transmitere a mesajului.

menu.txt și menu_2.txt

Aceste fișiere conțin listele ambelor meniuri ale sitului și determină corespunderea lor cu categoriile mărfurilor, care se conțin în câmpul type a fișierului marfa.xml.

info.txt

Între taguri <p></p> în acest fișier se păstrează informația despre magazin, descrierea sa și unele momente legate cu deservirea clienților:

Realizarea componentei de administrare

Funcționarea componentei de administrare asigură fișiere din dosarul admin. Ierarhia fișierelor din acest dosar este prezentată în figura 3.3.

Fig. 3.3. Ierarhia fișierelor din dosarul admin.

În dosarul includes se află fișiere care asigură funcționarea componentei administrative a sitului. Acestea conțin funcții logice pentru prelucrarea evenimentelor, conectează alte fișiere, inițiază constante și informația despre această pagină a sitului. În continuare vom descrie mai detaliat aceste fișiere.

Dosarele css, fonts și js conțin fișiere pentru design-ul interfeței componentei de administrare. Pentru a modifica stilul interfeței e destul să schimbăm conținutul acestor fișiere.

index.php

Fișierul index.php determină amplasarea vizuală a elementelor sitului și în care bloc trebuie plasate diferite componente și module. Acest fișier conform structurii se aseamănă cu cel descris pentru componenta clientului. Fișierul reprezintă o combinare a PHP și HTML.

În PHP se descrie tipul codificării și stilul paginilor, se inițiază conectarea funcțiilor necesare:

include("./includes/functions.php");

În HTML se descrie marcajul paginilor. Între taguri <head></head> sunt elemente asemănătoare celor din fișierul index.php descris în paragraful precedent, la fel și în blocul <body>.

Se deschide blocul panoului din stânga, în care prin intermediul constantei ACTS se încarcă din fișierul left.txt lista acțiunilor permise administratorului asupra catalogului de mărfuri:

<?php echo ACTS; ?>

<?php echo ACTS2; ?>

<a href="http://myshop.me/"></i> Back to Nevis-T</a>

</li>

</ul>

</div>

Se deschide cel mai important bloc al conținutului, în care informația se schimbă dinamic în dependență de acțiunile administratorului. În acest bloc se încarcă fișierul main.php:

<?php include("./includes/main.php"); ?>

</div>

Afișarea blocului footer, destinat amplasării informației despre drepturi de autor și hiperlegturii la pagina principală a sitului.

functions.php

Acest fișier inițiază conectarea fișierelor cu funcțiile de prelucrare a evenimentelor și fișierul config.php.

config.php

În fișierul config.php se definesc constante, utilizate în index.php și admin.php.

main.php

Fișierul main.php prelucrează evenimente și determină variante de comportament a componentei de administrare, în cazul diferitor acțiuni ale administratorului.

Astfel, încercare de autorizare, acționând butonul Log inițiază actiunea salut și controlul se transmite către funcția salut(). În calitate de parametru al acestei funcții servește numele celui care încearcă să se logeze:

if ($action == 'salut') { salut($_POST['adminname']); };

La alegerea punctului Adaugă marfa se inițiază acțiunea add_tov, care transmite execuția funcției cu același nume. În mod analog cu punctul Șterge marfa:

if ($action == 'add_marfa') { add_marfa(); };

if ($action == 'del_marfa') { del_marfa(); };

Acțiunile add_marfa_xml și del_marfa_xml se inițiază în timpul executării funcțiilor add_marfa și del_marfa, în cazul acționării butoanelor corespunzătoare. Aceste acțiuni, la rândul său, transmit execuția funcțiilor add_marfa_xml() și del_marfa_xml(). În prima din ele, în calitate de parametri servesc datele mărfii care se adaugă – denumirea, prețul, categoria, descriere și cantitate, iar în cea dea doua – denumirea mărfii:

if ($action == 'add_marfa_xml') { add_marfa_xml(

$_POST['item'],

$_POST['price'],

$_POST['type'],

$_POST['descriere'],

$_POST['cantitate']);

};

if ($action == 'del_marfa_xml') { del_marfa_xml($_POST['item']);};

În cazul altor acțiuni în zona conținutului paginii se afișează mesajul „Pagina administratorului”:

ELSE { echo '<br/><h3> PAGINA ADMINISTRATORULUI </h3>'; };

admin.php

Acest fișier conține funcțiile authorize() și salut().

Funcția authorize() descrie stilul formei de autorizare în componenta de administrare. În caseta, pentru completare de pe tastatura, se propune săse introducă nume. Valoarea introdusă se păstrează în id casetei de introducere (adminname) și se transmite în calitate de parametru funcției salut(). Tot aici se indică, că în cazul încercării de a se loga cu numele introdus, la acționarea butonului Log in, se inițiază acțiunea salut și se transmite controlul funcției salut().

<br/>

</div>

</form>

Funcția salut() prelucrează valoarea obținută a numelui celui care încearcă să se logheze în componenta de administrare. Inițial se verifică dacă caseta nu este goală, dacă numele a fost introdus, funcția se execută în continuare.

Această funcție compară numele introdus cu numele indicat în constanta ADMIN, care definește numele administratorului adevărat. În caz de coincidență, în zona conținutului se afișează mesajul de salutare corespunzător. Numele administratorului în mesajul dat servește în calitate de hiperlegătura pentru trecerea la pagina principală a componentei de administrare.

Dacă numele introdus nu coincide cu numele administratorului, atunci în zona conținutului se afișează mesajul cu rugămintea de a părăsi situl dat.

add_marfa.php

Acest fișier conține funcțiile add_marfa() și add_marfa_xml().

Funcția add_marfa() descrie stilul formei de adăugare a mărfii noi. Pe această formă sunt casete de text pentru denumirea mărfii, prețul, descriere, cantitate și un combo box cu categoriile mărfurilor:

<option value="default">Populare</option>

<option value="Calculatoare">Calculatoare</option>

…

</select>

</td>

Toate valorile introduse se salvează după id elementului, în care au fost introduse, pentru transmiterea lor ulterioară, în calitate de parametri, funcției add_marfa_xml(). Tot aici se indică, că în cazul confirmării adăugării, acționând butonul Adaugă, se inițializează acțiunea add_marfa_xml cu trecerea ulterioară către funcția add_marfa_xml().

Funcția add_marfa_xml() înregistrează marfa nouă în fișierul marfa.xml. Parametrii obținuți de această funcție formează informația despre marfa adăugată. Datele introduse în codificarea windows-1251 se convertesc într-o altă codificare:

$item = iconv('windows-1251','UTF-8',$item);

$opisanie = iconv('windows-1251','UTF-8',$descriere);

Pentru a înregistra marfa în catalog el trebuie încărcat:

$marfa_base = simplexml_load_string (

implode('',file(' http://MyShop.me/marfa.xml'))

);

Urmează înscrierea în fișierul XML, în corespundere cu structura fiecărui parametru:

$marfa = $marfa_base->addChild('marfa');

$marfa->addChild('type', $type);

$marfa->addChild('name', $item);

$marfa->addChild('descriere', $descriere);

$marfa->addChild('foto', " http://MyShop.me/catalog/$type$i.jpg");

$marfa->addChild('price', $price);

$marfa->addChild('cantitate', $cant);

Se verifică dacă parametrii nu sunt goi, pentru a completa toate datele despre marfa. Dacă verificarea s-a soldat cu succes, fișierul marfa.xml salvează modificările și în zona conținutului se afișează mesajul corespunzător:

if ($item != '' AND $type != '' AND $descriere != '' AND $price != '' AND $cant != '') {

$marfa_base->asXML(' C:\WebServers\home\MyShop.me\www\marfa.xml');

echo '<br/><h3> Marfa a fost adaugata cu succes</h3>';

}

În caz contrar, salvarea informației în marfa.xml n-are loc și în zona conținutului se afișează mesajul despre caracterul incomplet al datelor introduse și propunere să se întoarcă înapoi pentru completarea datelor.

del_marfa.php

Acest fișier conține funcțiile del_marfa() și del_marfa_xml().

Funcția del_marfa() descrie design-ul formei de ștergere a mărfii după denumirea. Valoarea introdusă se păstrează după id casetei de text pentru transmiterea ulterioară, în calitate de parametru, funcției del_marfa_xml(). Tot aici se indică, că acționând butonul Șterge, se inițiază acțiunea del_marfa_xml cu trecerea ulterioară către funcția del_marfa_xml().

<br/>

</div>

</form>

Funcția del_marfa_xml() șterge marfa din fișierul marfa.xml. Parametrul obținut de această funcție se convertează în altă codificare. Se încarcă catalogul. Urmează căutarea înregistrărilor după valori cuprinse între taguri <name></name>, comparându-le cu valoarea variabilei $item, în cazul detectării unei coincidențe se realizează ștergerea întregului bloc respectiv <marfa></marfa> din fișierul XML. În plus, în zona conținutului paginii se afișează un mesaj despre ștergerea cu succes:

foreach ($marfa_base->marfa as $k) {

if ($marfa_base->marfa[$i]->name == $item) {

unset($marfa_base->marfa[$i]);

echo '<br/><h3> Marfa este inlaturata cu succes </h3>';

break;

Catalogul salvează modificările:

$marfa_base->asXML('C:\WebServers\home\MyShop.me\www\marfa.xml');

Dacă căutarea a eșuat, în zona conținutului apare un mesaj despre lipsa așa unei mărfuri în baza de date și propunere de a verifica corectitudinea denumirii introduse, revenindu-se înapoi.

left.txt

Între taguri <li></li> în acest fișier se indică punctele listei pentru alegerea acțiunilor admisibile administratorului. Alegând unul din puncte, se inițiază acțiunea corespunzătoare – add_marfa sau del_marfa:

<li><a href="./?act=add_marfa">Adaugă marfa</a></li>

<li><a href="./?act=del_marfa">Șterge marfa</a></li>

3.6. Interfața magazinului online

3.6.1. Interfața componentei utilizator

Pe figurile 3.4 și 3.5 este prezentată interfață paginii principale a magazinului online MyShop.me.

Pagina este divizată în patru părți:

antet (fig. 3.4), în care este amplasat meniul orizontal al magazinului, denumirea sa și un slide show cu pozele accesoriilor calculatoarelor;

conținut (fig. 3.5) reprezintă partea de bază a sitului care se schimbă în dependență de acțiunile utilizatorului;

subsol, cu semnul copyright și hiperlegătura la pagina principală a sitului;

panoul stâng (fig. 3.5), în care este amplasat meniul categoriilor mărfurilor. Această listă se încarcă din fișierul menu_2.txt.

În componenta utilizatorului este prezentat catalogul mărfurilor magazinului. Aceasta permite clienților să navigheze prin sit și să creeze comenzile necesare.

Mărfurile se grupează după categorii. Accesul la categorie se realizează prin meniul vertical din panoul din stânga.

Alegând denumirea categoriei, vizitatorul magazinului vizualizează lista mărfurilor din categoria respectivă (fig. 3.6).

Fig. 3.4. Antetul paginii principale a componentei utilizatorului.

Fig. 3.5. Pagina principală: meniul principal și zona de conținut.

Fig. 3.6. Pagina categoriei Monitoare.

Acționând butonul Cumpar, se afișează forma comenzii (fig. 3.7), în care cumpărătorul trebuie să indice numele, prenumele, adresa livrării și numărul de telefon.

Fig. 3.7. Forma Comenzii

Dacă toate câmpurile au fost completate, după acționarea butonului Comanda va apărea un mesaj de confirmare a comenzii de pe figura 3.8, în caz contrar va apărea un mesaj din figura 3.9, care va permite cumpărătorului să întoarcă înapoi prin butonul Back.

Fig. 3.8. Mesajul de confirmare a comenzii.

Fig. 3.9. Mesajul de eroare la completarea comenzii.

3.6.2. Interfața componentei de administrare

În figura 3.10 este prezentată pagina principală a componentei de administrare care oferă administratorului sitului una din trei opțiuni: adăugarea mărfii (fig. 3.11), ștergerea mărfii (fig. 3.14) sau întoarcerea la componenta utilizatorului (Back to Nevis-T).

Fig. 3.10. Pagina principală a administratorului.

Fig. 3.11. Forma de adăugare a mărfii.

Dacă, adăugând o nouă marfă, administratorul n-a completat un oarecare câmp cu informație din forma de adăugare a mărfii, atunci apare mesajul din figura 3.12. Dacă toate câmpurile au fost completate apare mesajul din figura 3.13.

Fig. 3.12. Mesajul de eroare la adăugarea mărfii.

Fig. 3.13. Mesajul de adăugare a mărfii cu succes.

Fig. 3.14. Forma de ștergere a mărfii.

CONCLUZII

În rezultatul elaborării tezei date au fost rezolvate următoarele sarcini:

Cercetarea surselor bibliografice referitor la tema tezei;

Evidențierea avantajelor și neajunsurilor utilizării XML;

Analiza comparativă a datelor XML cu date relaționale;

Cercetarea metodelor de păstrare a datelor XML;

Cercetarea domeniului de utilizare a magazinului online;

Cercetarea instrumentelor de elaborare a aplicației și alegerea instrumentelor mai raționale din punct de vedere financiar și comod pentru orice dezvoltator începător;

Elaborarea aplicației magazinului online, construite pe datele XML.

Din sarcinili rezolvate, enumerate anterior, putem menționa următoarele avantaje de bază ale limbajului XML:

XML (orientat la om) – reprezintă un format înțeles în același timp și omului și calculatorului;

În formatul XML pot fi descrise structuri de date complexe, cum ar fi înregistrări, liste și arbore;

XML – reprezintă un format de auto-documentare, care descrie atât structura și denumirile câmpurilor cât și valorile câmpurilor;

XML reprezintă un text simplu, liber de licențiere și oarecare alte restricții;

XML nu depinde de platformă;

De asemenea, putem evidenția următoarele neajunsuri principale ale limbajului XML:

XML nu conține suportul tipurilor de date încorporat în limbaj;

Modelul ierarhic al datelor propus de XML este mărginit în comparație cu modelul relațional și grafuri orientate pe obiect;

Există alte formate textuale de date asemănătoare după posibilități cu XML, care sunt mai lizibile pentru om (YAML, JSON, SweetXML).

Cercetarea efectuată în această lucrare ne permite să concludem următoarele:

Baze de date native XML suportă proprietăți multi-valoare, adică normalizarea nu se efectuează pe deplin, cum ea are loc în bazele de date relaționale;

Integritatea referențială înseamnă asigurarea că pointerii în documentul XML trimit la documente valide sau fragmente de documente;

Scalabilitatea suficientă la căutarea datelor indexate, practic ca în bazele de date relaționale, însă scalabilitatea joasă în căutarea datelor neindexate;

Pe baza de XML se poate de elaborat o aplicație web simplă și funcțională pentru, practic orice domeniu de activitate. Neajunsuri unei așa aplicații ar fi securitatea datelor scăzută.

Utilizarea XML în calitate de bază de date este destul de ușor de realizat pentru o aplicație simplă, pentru una de proporții mari informația trebuie protejată mai bine, utilizând sistemele de gestiune a bazelor de date clasice, care oferă mai multe nivele de protecție a datelor. Pentru a rezolva aceasta problemă, utilizând doar XML, pot fi utilizate baze de date XML native.

Lucrarea prezentată poate fi utilizată în calitate de un îndrumător pentru studenți și alți utilizatori interesați în studierea particularităților limbajului XML utilizat în calitate de baza de date.

Bibliografie

Buraga Sabin-Corneliu, Tehnologii XML. – Iași: Polirom, 2006. – 411 p.

David Hunter, Jeff Rafter, Joe Fawcett, et al. Beginning XML, 4th Edition. – M.: Williams, 2009. – 1344 p.

Extensible Markup Language (XML) 1.0 (Third Edition). http://www.w3.org/TR/2004/REC-xml-20040204/ (accesat 14.03.2015)

http://www.w3.org/Style/XSL/ – descrierea tehnologiei familiei XSL de pe situl consorțiului WWW. (accesat 15.04.2015)

http://www.w3.org/XML/ – descrierea limbajului XML de pe situl consorțiului WWW. (accesat 15.02.2015)

http://www.xmlsoft.org/ – situl cu o documentație de lucru pentru bibliotecile utilizate în lucru cu documentele XML. (accesat 15.03.2015)

https://sepforever.wordpress.com/studiu-http/. (accesat 17.04.2015)

Situl oficial al W3C pentru XML Schema. http://www.w3.org/XML/Schema. (accesat 16.04.2015)

XML. http://vechi.upg-ploiesti.ro/col/ldumitrascu/html/toc.jsp-id=3.htm. (accesat 13.02.2015)

Брогден Б., Минник К. Электронный магазин на Java и XML. Библиотека программиста. – СПб.: Питер, 2002.

Веселов В.В. Долженков А.Н. XML и технологии БАЗ ДАННЫХ. http://www.inftech.webservis.ru/it/internet/xml/ar2.html. (accesat 17.04.2015)

Грошев А.С. Основы работы с базами данных. http://www.intuit.ru/studies/courses/93/93/lecture/2811?page=3. (accesat 12.03.2015)

Обзор языка XML. http://web-dot.ru/wp-content/uploads/2010/12/XML_review.pdf. (accesat 14.03.2015)

Пинягина О.В., Технология XML и ее приложения: Учебное пособие / О.В. Пинягина – Казань: Казанский государственный университет, 2007. – 92 с.

Фримен Э., Фримен Э. Изучаем HTML, XHTML и CSS. – СПб.: Питер, 2010. – 656 с.: ил. – (Серия «Бестселлеры O’Reilly»).

Хабибуллин И. Ш. – Самоучитель XML. – СПб.: БХВ – Петербург, 2003. – 336 с.

Dr. Sabin Buraga. Tehnologii Web tehnologii XML – supliment. Baze de date native XML + interogări XQuery. http://profs.info.uaic.ro/~busaco/teach/courses/web/presentations/web-BazeNativeXML.pdf (accesat 17.04.2015)

ANEXE

Exemplu de schema XML pentru validarea unui document XML

Fișierul marfa.xsd

1 <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">

2 <xs:element name="marfa" type="Marfa" />

3 <xs:complexType name="Marfa">

4 <xs:sequence>

5 <xs:element name="type" type="xs:string" />

6 <xs:element name="name" type="xs:string" />

7 <xs:element name="descriere" type="xs:string" />

8 <xs:element name="foto" type="xs:string" />

9 <xs:element name="price" type="xs:decimal" />

10 <xs:element name="cantitate" type="xs:integer" />

11 </xs:sequence>

12 </xs:complexType>

13 </xs:schema>

Prin intermediul acestei scheme se poate de validat un document XML cu următorul conținut:

1 <marfa xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation = "marfa.xsd">

2 <type>Calculatoare</type>

3 <name>Calculator HP-210</name>

4 <descriere>proc. 2,5 Ghz, RAM 2 GO, HD 500 GO</descriere>

5 <foto>http://MyShop.me/catalog/Calculatoare3.jpg</foto>

6 <price>6000</price>

7 <cantitate>6</cantitate>

4 </marfa>

Fragmentul fișierului marfa.xml

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>

<Table>

<type>Calculatoare</type>

<name>Intel Pentium DualCore</name>

Intel Pentium DualCore E5200 2.5Ghz, 2GB DDR2, 160Gb HDD

</descriere>

<foto>http://MyShop.me/catalog/Calculatoare1.jpg</foto>

</marfa>

<type>Monitoare</type>

18.5" AOC LED e970Swn Black (5ms, 20M:1, 200cd, 1366×768, VESA)

</descriere>

<foto>http://MyShop.me/catalog/Monitoare2.jpg</foto>

</marfa>

<type>Hards</type>

<name>Western Digital WD3200AVVS AV-GP 320Gb</name>

Western Digital WD3200AVVS AV-GP 320Gb, 7200rpm, 8Mb, SATAII

</descriere>

<foto>http://MyShop.me/catalog/Hards4.jpg</foto>

</marfa>

…

</Table>

Fișierul get_cat.php

<?php

function get_cat_xml($type) {

$marfa_base = simplexml_load_string (implode ('',file('./marfa.xml')));

echo '<table width=100%>';

for($i = 0 ; $i != count($marfa_base->marfa); $i++ ) {

if ($marfa_base->marfa[$i]->type == $type) {

$marfa_base->marfa[$i]->name = iconv('UTF-8','windows-1251',$marfa_base->marfa[$i]->name);

$marfa_base->marfa[$i]->descriere = iconv('UTF-8','windows-1251',$marfa_base->marfa[$i]->descriere);

echo '

<p>

<tr>

<tr><h2>('.$marfa_base->marfa[$i]->cantitate.' buc.) '.$marfa_base->marfa[$i]->name.' -> <i style="color: #F00">'.$marfa_base->marfa[$i]->price.' lei.</i></h2></tr>

<img src="'.$marfa_base->marfa[$i]->foto.'" align="left" vspace="10" hspace="10" alt="Aici trebuie sa fie o imagine" width=140px style="border:1px solid #97CBDF;">

</td>

<td >'.$marfa_base->marfa[$i]->descriere.'</td>

<a href="./?act=buy&item='.$marfa_base->marfa[$i]->name.'&price='.$marfa_base->marfa[$i]->price.'" title="cumpar">cumpar!</a>

</td>

</table>

</tr>

</p><br/><br/><br/><br/>

';

};

echo '</table>';

};

?>

Fișierul add_marfa.php

<?php

function add_marfa() {

echo'

<h2>Adaugare marfii</h2>

<tr>

<strong>Marfa: </strong>

</td>

</td>

</tr><br/>

<tr>

<td align="right" valign="top"><strong>Categorie: </strong></td>

<option value="default">Populare</option>

<option value="Calculatoare">Calculatoare</option>

<option value="Monitoare">Monitoare</option>

<option value="Videos">Placi video</option>

<option value="Hards">Hard-discuri</option>

<option value="Printers">Imprimante</option>

<option value="Scanners">Scanere</option>

<option value="Web_cams">Web camere</option>

<option value="Keyboards">Tastaturi</option>

<option value="Mouses">Mouse-uri</option>

</select>

</td>

</tr><br/>

<tr>

<strong>Descriere: </strong>

</td>

</td>

</tr><br/>

<tr>

<input name="price" type="text" id="price" size="10" /> lei.

</td>

</tr><br/>

<tr>

<td align="right" valign="top"><strong>Cantitate: </strong></td>

<input name="cant" type="text" id="cant" size="10" /> buc.

</td>

</tr>

</table><br/>

</div>

</form>

';

};

function add_marfa_xml($item,$price,$type,$descriere,$cant) {

$marfa_base = simplexml_load_string(

implode('',file('http://MyShop.me/marfa.xml'))

);

$i = count($marfa_base->marfa)+1;

$item = iconv('windows-1251','UTF-8',$item);

$descriere = iconv('windows-1251','UTF-8',$descriere);

$marfa = $marfa_base->addChild('marfa');

$marfa->addChild('type', $type);

$marfa->addChild('name', $item);

$marfa->addChild('descriere', $descriere);

$marfa->addChild('foto', "http://MyShop.me/catalog/$type$i.jpg");

$marfa->addChild('price', $price);

$marfa->addChild('cantitate', $cant);

if ($item != '' AND $type != '' AND $descriere != '' AND $price != '' AND $cant != '') {

$marfa_base->asXML('C:\WebServers\home\MyShop.me\www\marfa.xml');

echo'<br/><h3>Marfa a fost adaugata cu succes</h3>';

}

ELSE{

echo'

<br/><h2>N-ati completat toate campurile la descrierea marfii. Va rugam sa va intoarceti si sa introduceti toata informatia despre marfa</h2><br/>

</a>

</div>

';

};

?>

Fișierul del_marfa.php

<?php

function del_marfa() {

echo '

<h2>Stergerea marfii</h2>

<tr>

<strong>Marfa: </strong>

</td>

</td>

</tr>

</table><br/>

</div>

</form>

';

};

function del_marfa_xml($item) {

$marfa_base = simplexml_load_string(

implode('',file('http://MyShop.me/marfa.xml'))

);

$item = iconv('windows-1251','UTF-8',$item);

$i = 1;

foreach ($marfa_base->marfa as $k) {

if ($marfa_base->marfa[$i]->name == $item) {

unset($marfa_base->marfa[$i]);

echo '<br/><h3>Marfa este inlaturata cu succes</h3>';

break;

}

$i++;

};

$marfa_base->asXML('C:\WebServers\home\MyShop.me\www\marfa.xml');

if ($i>count($marfa_base->marfa)) {

echo '

<br/>

<h2>Asa marfa nu exista in catalog. Verificati corectitudinea denumirii de marfa introduse de dvs</h2><br/>