Download - Utilizarea XML in Baze de Date
Vizitati www.tocilar.ro ! Arhiva online cu diplome, cursuri si referate postate de utilizatori.
Utilizarea XML in baze de date
INTRODUCERE
Formatul de date XML devine formatul comun acceptat în industrie pentru schimbul
de informaţii dintre diverse sisteme eterogene. Din acest motiv, este important ca o bază de
date să fie capabilă să stocheze informaţiile nu doar în formatele tradiţionale, relaţionale, ci şi
în format XML. Stocând datele XML în format nativ se câştigă foarte mult în performanţă,
aceasta materializându-se în costuri reduse. Un plus de performanţă la o tehnologie de baze
de date înseamnă o infrastructură redusă, servere cu mai puţine procesoare, deci un sistem
informatic ceva mai ieftin, costuri mai mici pentru licenţiere, deci per total o economie de
bani.
Standardul industrial al datelor în format XML prezintă o serie de avantaje şi
dezavantaje. Avantajul major este acela că este adoptat de toţi producătorii de tehnologie din
industrie, dar în schimb are dezavantajul că este un format nu foarte eficient din punct de
vedere al stocării datelor. De aceea devine foarte util ca baza care stochează aceste date sa
aibă capabilităţi de compresie, care să ducă la scăderea spaţiului şi resurselor de stocare
necesare pentru a păstra date în format XML.
Lucrarea de faţă îşi propune să prezinte în capitolele sale câteva noi direcţii de
dezvoltare în domeniul bazelor de date, modelul de date semistructurat şi tehnologia XML ca
o nouă bază de date.
Capitolul I prezintă necesitatea apariţiei modelului semistructurat al datelor, datorită
nevoii de interogare a unor surse de date care nu au o schemă predefinită sau a unor date care
provin din surse diferite şi au scheme diferite. Modelul semistructurat al datelor reprezintă
schema (tipul, structura) şi instanţa (valoarea) datelor în mod uniform, permiţând interogarea
lor simultană spre deosebire de modelele de date convenţionale, care diferenţiază între cele
două tipuri de informaţie.
Capitolul II detaliază modelul semistructurat al datelor definind conceptul de date
neconvenţionale din mai multe perspective şi pe cel de date semistructurate prezentând
avantajele acestui tip de date, modelarea acestor date şi limbajele de interogare a acestora, şi
Pagina 1 din 97
Vizitati www.tocilar.ro ! Arhiva online cu diplome, cursuri si referate postate de utilizatori.
prezintă în detaliu tipul de date MPEG-21 ca suport pentru integrarea datelor în aplicaţii
multimedia distribuite.
Capitolul III prezintă legătura dintre tehnologia XML şi bazele de date încercând să
clarifice în ce măsură este XML-ul o bază de date, reprezentarea datelor şi documentelor,
stocarea şi recuperarea datelor, stocarea datelor în baze de date native XML, generarea
schemelor XML din scheme relaţionale şi invers, stocarea documentelor în sistemul de fişiere
şi în BLOB-uri, detaliază bazele de date native XML, şi prezintă noţiunile de DOM
(Document Object Model) persistent şi sisteme de management ale conţinuturilor.
Capitolul IV se ocupă de construirea documentelor XML prezentând sintaxa XML,
descrierea de vocabulare noi cu XML, avantajele definiţiei tipurilor documentului,
combaterea dezavantajelor definiţiei tipurilor documentului, definirea unui document XML
ca întreg, declaraţia XML, documentele autonome, construirea unui document XML,
declaraţia tipului documentului şi prezintă câteva aplicaţii din lumea reală a declaraţiei tipului
documentului.
Capitolul V constă în prezentarea aplicaţiei – magazinul virtual „ElectronX” - şi
prezintă scopul acestei aplicaţii, cerinţele minime hardware şi software ale aplicaţiei,
funcţionalităţile de bază ale acestui website, proiectarea bazei de date conţinând schema
conceptuală a structurii bazei şi schema fizică a fiecărei tabele, implementarea codului în care
sunt explicate fişierele cele mai importante ale aplicaţiei cu exemplificări din codul sursă, un
manual de utilizare al aplicaţiei în care e descris modul de funcţionare al acesteia şi concluzii
asupra aplicaţiei.
CAPITOLUL I
NOI MODELE DE DATE ŞI APLICAŢIILE LOR
1.1 Interogarea World-Wide-Web-ului
Există surse de date, ca de pildă World-Wide-Web-ul, pe care am dori să le interogăm
ca baze de date, dar care nu pot fi constrânse de o schemă. Majoritatea interogărilor web-ului
folosesc tehnici de regăsire a informaţiei pentru a găsi pagini după conţinut. Există însă
puţine posibilităţi de formulare a interogărilor în vederea exploatării structurii web-ului şi,
deoarece aceasta nu este conformă cu nici un model de date standard, este necesară o metodă
de descriere a acestei structuri.
Modelul de date semistructurat a fost propus în vederea satisfacerii acestei necesităţi.
Ideea centrală în modelul semistructurat este de a reprezenta datele sub forma unui graf
Pagina 2 din 97
Vizitati www.tocilar.ro ! Arhiva online cu diplome, cursuri si referate postate de utilizatori.
etichetat. Structura documentelor hipertext este capturată interpretând arcele grafului drept
legături. O reprezentare posibilă este cea introdusă în proiectul UnQL[1]. Etichetele arcurilor
pot fi atât valori (de tip întreg, şir de caractere şi alte tipuri de bază, precum şi de tip de date
abstract, ca video, audio, etc.) cât şi nume de atribute (Film, Titlu, Regizor, Actor), etc.
modelând de exemplu cunoscuta bază de date cinematografică IMDB [2].
Există numeroase limbaje de interogare pentru modelul semistructurat. Toate aceste
limbaje sunt construite pe baza ideii de expresii asociate căilor (path expressions). Acestea
sunt expresii regulate ce exprimă căi generice în graful etichetat, permiţând astfel traversarea
grafului şi colecţionarea tuturor etichetelor ce satisfac o anumită condiţie de selecţie.
Limbajele semistructurate pot fi clasificate în două categorii, după strategia de calcul
adoptată. Prima categorie, dezvoltată oarecum ad-hoc, se bazează pe modelarea grafurilor în
modelul relaţional şi apoi pe interogarea lor într-un limbaj relaţional de tip SQL. Câteva
exemple prezentate în literatură sunt [3], [4], [5], [6], [7]
A doua categorie porneşte de la un limbaj bazat pe o noţiune formală de calcul cu date
semistructurate: limbajul UnQL este reprezentantul acestei categorii [1]. Acest limbaj
porneşte de la recursivitatea structurală, forma naturală de recursivitate asociată cu tipul de
date grafuri etichetate. Datorită bazei sale teoretice, UnQL este capabil de restructurări
complexe, în adâncime, spre deosebire de limbajele din prima categorie, care se limitează la
scoaterea la suprafaţă a datelor din graf, fără însă a crea noi structuri.
Această capacitate de restructurare stă la baza proiectului STRUDEL[8] care propune
limbajul StruQL de gestiune a sit-urilor de web. Un alt avantaj al bazei teoretice a limbajelor
UnQL şi StruQL este posibilitatea efectuării optimizărilor specifice acestui nou model de
date. Limbajele din prima categorie pot beneficia doar de optimizările specifice modelului
relaţional, deci dezvoltate pentru alt model de date şi în consecinţă nu atât de folositoare.
1.2 Integrarea surselor de date eterogene
Integrarea datelor provenind din surse eterogene (cu scheme disparate sau, mai grav,
modelate diferit), este un domeniu de cercetare care, deşi consacrat de mai bine de un
deceniu, continuă să rămână în centrul atenţiei multor cercetători. Cercetarea în acest
domeniu este motivată de absenţa unui model de date atotcuprinzător, fapt ce îngreunează
dezvoltarea de software care converteşte date între două modele diferite.
O complicaţie adiţională este reprezentată de faptul că majoritatea datelor stocate
electronic nu se află în baze de date convenţionale, ci în sisteme de fişiere, programe de
bibliotecă, de poştă electronică, foi de calcul etc., care prezintă capacităţi de interogare
limitate.
Pagina 3 din 97
Vizitati www.tocilar.ro ! Arhiva online cu diplome, cursuri si referate postate de utilizatori.
Ultima observaţie a reprezentat punctul de plecare al proiectului Tsimmis [9][10] de
la Stanford. Proiectul Tsimmis îşi propune integrarea atât a surselor de date care sunt
conforme cu modelele de date standard (relaţional, orientat pe obiecte), cât şi a surselor de
date cu capacităţi de interogare limitate. Aceste surse neconvenţionale sunt împachetate în
aşa-numiţi wrappers (ambalaje). Un astfel de ambalaj asigură interfaţa între sursa de date cu
capacităţi de interogare limitate şi aplicaţia care o interoghează. Aplicaţia trimite către sursă
interogări într-un limbaj expresiv cum ar fi SQL sau OQL şi aşteaptă rezultatul într-un format
numit OEM (Object Exchange Model).
OEM foloseşte grafuri etichetate, ca structură de date, care capturează majoritatea
datelor folosite în aplicaţii de baze de date. În acelaşi timp, toate celelalte structuri de date pot
fi codificate ca grafuri OEM.
Rolul ambalajului constă în: interceptarea interogării şi identificarea acelor părţi ale
acesteia care pot fi efectuate de către sursă, translatarea acestor părţi în limbajul specific
sursei, recepţionarea şi prelucrarea rezultatelor intermediare în vederea reconstituirii
rezultatului interogării originale, codificarea rezultatului final în formatul OEM şi
transmiterea acestuia către aplicaţie.
Evident, dacă interogarea originală este prea complexă, este posibil să nu poată fi
efectuată pornind de la capabilităţile limitate ale sursei. Ambalajul detectează această situaţie
şi anunţă sursa că nu îi poate satisface cererea. Cu cât creşte capacitatea de evaluare a
interogărilor în cadrul ambalajului (de exemplu, capacitatea de a efectua operaţii de tip join,
proiecţii, selecţii, etc.), cu atât se extinde clasa de interogări pe care le poate satisface
combinaţia sursă-ambalaj.
Un proiect similar, cu scopul interogării surselor de date structurate din web este [13].
Se remarcă similaritatea dintre modelul OEM şi cel semistructurat. Într-adevăr, Lore
[11],[12] este un sistem de interogare a datelor semistructurate, foarte similar cu UnQL,
utilizând un model de date inspirat de OEM.
1.3 Navigare în Internet
În anumite situaţii este avantajos să privim bazele de date convenţionale ca fiind
semistructurate. Un exemplu este activitatea de navigare în Internet.
În general, utilizatorul nu poate interoga o bază de date fără a-i cunoaşte schema. Din
nefericire însă, aceasta este adeseori greu de înţeles, datorită mărimii exagerate (zeci de
tabele, de exemplu) şi a terminologiei opace, nestandard, folosite de către proiectanţii bazei
de date.
Pagina 4 din 97
Vizitati www.tocilar.ro ! Arhiva online cu diplome, cursuri si referate postate de utilizatori.
Descifrarea schemei ar fi considerabil uşurată de facilitatea de a interoga datele având
doar o înţelegere parţială a structurii lor. De exemplu, în cazul bazei de date cinematografice
din World-Wide Web[2], următoarele interogări ar fi de folos:
În care atribut găsim şirul de caractere Casablanca?
Există în baza de date întregi mai mari decât 216?
Ce obiecte din baza de date au un atribut al cărui nume începe cu act?
Şi în acest domeniu, modelul semistructurat se dovedeşte a fi folositor. Spre deosebire
de modelele de date convenţionale, care diferenţiază între schema (tipul, structura) şi instanţa
(valoarea) datelor, modelul de date semistructurat reprezintă cele două tipuri de informaţie în
mod uniform, permiţând interogarea lor simultană. Din acest motiv, datele semi-structurate se
numesc şi autodescriptive.
[1] prezintă un elegant limbaj de interogare care permite exprimarea concisă a acestor
interogări.
1.4 Cubul de date şi OLAP
Sistemele de suport pentru decizii (Decision support systems) sunt utilizate de către
companiile moderne pentru integrarea într-o bază de date centrală numită data warehouse
(magazia centrală de date), a datelor provenind din baze de date mici operaţionale folosite în
diferite domenii de activitate/filiale ale companiei.
Datele astfel acumulate sunt analizate în timp real (OLAP: On-Line Analitical
Processing) pentru a asista conducerea companiei în luarea deciziilor strategice de dezvoltare
[14] (de exemplu, analizând vânzările unui anumit produs pe trimestru şi zonă geografică, se
poate stabili o nouă strategie de marketing pentru acest produs). Datele din magazia centrală
de date sunt modelate sub forma unui (hiper)cub de date multidimensional [15]) care poate fi
analizat la nivelul subcuburilor de granularitate arbitrară. Subcuburile se obţin prin agregarea
cuburilor din care provin.
De exemplu, prin însumarea vânzărilor trimestriale pentru fiecare zonă, cubul de date
tridimensional reprezentând vânzările pe trimestru şi zona geografică poate fi redus la un
subcub bidimensional (plan) reprezentând vânzările pe zona geografică. Agregarea este o
operaţie costisitoare, efectuarea ei eficientă pe un volum mare de date reprezentând ţelul
principal al cercetării în acest domeniu ([16],[17],[18],[19]).
1.5 Noi modele tranzacţionale
În mod tradiţional, tranzacţiile modelează unităţi de lucru atomice şi izolate, efectuate
asupra datelor sistemului de gestiune a bazelor de date.
Pagina 5 din 97
Vizitati www.tocilar.ro ! Arhiva online cu diplome, cursuri si referate postate de utilizatori.
Izolarea tranzacţiilor nu permite crearea tranzacţiilor complexe, mari, din tranzacţii
simple. Acest model a avut succes atâta vreme cât tranzacţiile efectuau un număr mic de
operaţii simple asupra datelor cu structură simplă.
Din păcate, modelul tranzacţiilor simple nu satisface cerinţele aplicaţiilor complexe,
în care tranzacţiile trebuiesc combinate şi coordonate pentru a colabora la realizarea unui
scop complex. Aplicaţii ca proiectarea asistată de calculator, automatizarea activităţii de
birou, controlul producţiei, gestiunea activităţilor necesită noi modele tranzacţionale, noi
metode de gestiune a tranzacţiilor, şi noi limbaje de specificare a tranzacţiilor. Limbajele
tranzacţionale sunt limbaje de nivel înalt, de obicei inspirate din logica cu predicate de
ordinul întâi.
Dacă limbajele tradiţionale specificau interogări şi actualizări, noile limbaje
tranzacţionale se concentrează asupra relaţiei dintre tranzacţii, exprimând dependenţe de tipul
tranzacţia T2 nu poate porni înainte ca T1 să se termine, sau T2 poate începe dacă T1 întoarce
o valoare mai mare ca 25. [20] prezintă o clasificare şi analiza detailată a noilor limbaje
tranzacţionale.
Un excelent exponent al noii generaţii de limbaje tranzacţionale este Transaction
Datalog [21], un limbaj deductiv care menţine în acelaşi timp toate proprietăţile tranzacţiilor
clasice, cum ar fi: persistenţă, atomicitate, izolare, terminare şi rollback (revenire).
Limbajul este însoţit de un model teoretic natural şi de o teorie sigură pentru
demonstraţii, permiţând astfel demonstrarea echivalenţei între diverse expresii din acest
limbaj. Acest fapt este crucial pentru optimizare - care constă din înlocuirea unei planificări
cu o alta echivalentă din punct de vedere al efectului său asupra datelor, dar mai eficientă din
punct de vedere al costului execuţiei. Mai mult, faptul că putem demonstra că efectul unei
tranzacţii complexe asupra setului de date este sau nu cel scontat, asigură consistenţa datelor.
1.6 Optimizări
Optimizarea limbajelor de interogare a bazelor de date nu este un domeniu nou, ci
dimpotrivă, există încă de la apariţia acestora. Datorită importanţei sale, acest domeniu va fi
întotdeauna la modă în cercetarea bazelor de date.
Apariţia unui nou model de date atrage după sine o efervescenţă în activitatea de
cercetare a posibilităţilor de optimizare a limbajului de interogare asociat noului model.
Referinţele bibliografice introduse în secţiunea anterioară prezintă şi primele încercări de
optimizare a noilor limbaje de interogare.
Pagina 6 din 97
Vizitati www.tocilar.ro ! Arhiva online cu diplome, cursuri si referate postate de utilizatori.
CAPITOLUL II
MODELE DE REPREZENTARE A DATELOR NECONVENŢIONALE
2.1 Definirea conceptului de date neconvenţionale
În literatura de specialitate există o serie de definiri ale conceptului de date
neconvenţionale şi a altor concepte asociate acestuia:
• Datele neconvenţionale sunt datele care nu au nici unul din tipurile standard: întreg,
real etc. [Blanken, 2002]
• Structura de date neconvenţională este structura de date care nu este în uzul curent al
aplicaţiilor; aceasta poate fi structura produsă de datele semistructurate, cea definită noilor
tipuri de date folosite în aplicaţii şi date cu structuri ce se modifică în mod dinamic. [GSIHT,
2005]
• A patra generaţie a tehnologiilor bazelor de date este prezentată în [Mannino, 2004]
ca fiind o extensie a tehnologiilor bazelor de date cu datele neconvenţionale şi Internetul.
Sistemele celei de-a patra generaţii pot stoca şi manipula tipuri de date neconvenţionale cum
sunt: imaginile, secvenţele video, hărţile, sunetele şi animaţiile şi permit accesul la bazele de
date Web.
• Unul din obiectivele sistemelor de gestiune a bazelor de date orientate obiect este
prezentat ca fiind extinderea flexibilităţii cu datele neconvenţionale şi procedurile de
prelucrare asociate acestora, inclusiv text, grafică şi voce, date care nu pot fi manipulate şi
integrate de sistemele de baze de date convenţionale.
La University of Southern California din Los Angeles (USC) există un laborator de
informare numit InfoLAB al cărui scop este investigarea de noi metode pentru gestiunea
tipurilor de date neconvenţionale cu arhitecturi atipice. Principalele zone de cercetare sunt:
• Gestiunea fluxurilor de date multidimensionale în arhitecturi de tip punct la punct
(peer-to-peer),
• Analiza datelor multidimensionale,
• Gestiunea datelor peer-to-peer,
• Prelucrarea interogărilor de stream-uri,
• Baze de date spaţio-temporale.
Descrierea datelor neconvenţionale se realizează folosind metadate. Metadatele sunt
folosite pentru descrierea altor date, cu o structură complexă sau nestructurate. Metadatele
pot fi privite din diferite perspective, în funcţie de producătorul sau sursa metadatelor:
Pagina 7 din 97
Vizitati www.tocilar.ro ! Arhiva online cu diplome, cursuri si referate postate de utilizatori.
- Din perspectiva producătorului de conţinut, metadatele sunt utilizate pentru stocarea
informaţiilor bibliografice ale resurselor, ca de exemplu: numele autorului, titlul, data creării,
formatul resursei etc.
- Din perspectiva furnizorilor de servicii, metadatele oferă informaţii descriptive cu
valoare adăugată (majoritatea în format XML), care reduc informaţiile necesare regăsirii
datelor. Metadatele conţin informaţii despre diferitele formate în care este disponibilă o
resursă şi informaţii semantice asociate acesteia. Aceste informaţii sunt utile pentru realizarea
interogării datelor.
- Din perspectiva consumatorului, metadatele oferă informaţii suplimentare care
descriu preferinţele consumatorului şi resursele disponibile pentru utilizarea datelor.
Metadatele permit personalizarea consumului mediilor şi trebuie luate în considerare de
producători. Metadatele sunt utile pentru distribuirea datelor în Internet sau în reţele mobile
permiţând accesul la resurse în cele mai bune condiţii posibile; de exemplu, metadatele pot fi
folosite pentru descrierea modului în care difuzarea secvenţelor video este adaptată la
scăderea lărgimii de bandă disponibilă la un moment dat.
2.2 Modelul semistructurat ale datelor
Modelele relaţional şi orientat-obiect au fost folosite mult timp pentru modelarea
datelor nu neapărat pentru că erau cele mai naturale soluţii, ci pentru că au în spate un
formalism bine definit. În timp însă, datorită dezvoltării Internetului şi datorită necesităţii
integrării datelor descrise folosind scheme diferite, modelele tradiţionale s-au dovedit a nu
mai fi suficiente şi a devenit acută necesitatea utilizării unui alt model de date, modelul
semistructurat al datelor.
În plus, aplicaţiile Internet realizează operaţii care nu sunt curente în aplicaţiile
tradiţionale cu baze de date cum ar fi: transformări ale datelor, interpretarea interogărilor,
transportul datelor şi prelucrarea bazată pe fluxuri.
Datele semistructurate au devenit un important subiect de studiu din mai multe
motive:
În primul rând, există surse de date pe care am vrea să le tratăm ca baze de date dar
cărora nu le putem impune constrângeri având la bază o schemă, ca în cazul bazelor de date
tradiţionale [Buneman, 1997]. Chiar şi datele structurate, au structură care poate să difere de
la o aplicaţie la alta sau au structură modificabilă în timp. Dezvoltările din domeniul
multimediei au dus la necesitatea de a introduce noi tipuri de date în domeniul tehnologiei
bazelor de date convenţionale. Unele tehnologii necesită doar extensii ale modelelor de date
existente, prin optimizarea tehnicilor de manipulare şi interogare a noilor tipuri de date, dar
Pagina 8 din 97
Vizitati www.tocilar.ro ! Arhiva online cu diplome, cursuri si referate postate de utilizatori.
altele nu pot fi încadrate în modelele clasice de gestiune a datelor. Cel mai evident exemplu
de date care nu pot fi încadrate într-o schemă sunt datele manipulate prin intermediul Web-
ului. Majoritatea interogărilor Web exploatează tehnicile de regăsire a datelor pentru a
determina paginile individuale care au conţinut ce corespunde criteriului solicitat. Dar numai
o mică parte din resursele Web sunt structurate astfel încât să permită rezolvarea
interogărilor, Web-ul nefiind conform nici unui model standard. Astfel că se simte nevoia de
a găsi o metodă pentru descrierea structurii datelor Web în vederea rezolvării acestei
probleme.
Al doilea motiv este dat de necesitatea schimbului de date între aplicaţii care folosesc
formate diferite de stocare şi gestiune a datelor necesitând astfel transformarea datelor. Nici
unul din modelele de date existente nu este acceptabil din toate punctele de vedere şi în plus
este dificil să convertim datele dintr-un model în altul. Astfel, s-a simţit nevoia să se dezvolte
un model care să lege cele două lumi diferite: relaţională şi orientată obiect, acesta este
modelul semistructurat al datelor.
În plus, datele în format electronic se află în medii diferite, interconectate care trebuie
să comunice între ele. Dar şi când se folosesc datele structurate poate fi util ca acestea să fie
privite ca date semistructurate, din motive care ţin de manipularea acestora, fiind util să existe
un format flexibil pentru schimbul de date între diferite tipuri de baze de date. [Buneman,
1997]
O parte din aceste date se găsesc sub forma datelor nestructurate, ca de exemplu
sunetele, imaginile, secvenţele video şi chiar unele documente text, iar altă parte sub forma
datelor structurate, memorate în baze de date relaţionale sau orientate obiect. În general, un
utilizator nu poate scrie o interogare pentru o bază de date fără să cunoască schema de
organizare a datelor, iar aceasta este netransparentă pentru utilizatori şi raţionamentul folosit
la proiectarea ei este adesea greu de determinat. Au fost dezvoltate limbaje care permit
interogarea simultană a datelor şi a schemelor de organizare a bazelor de date, dar aceste
limbaje nu au flexibilitatea să manipuleze constrângeri complexe.
2.2.1 Conceptul de date semistructurate
În general, prin termenul de date semistructurate sunt denumite datele care nu
respectă formate stricte cum ar fi cele impuse de modelele bazelor de date relaţionale sau
orientate obiect. În mod evident o astfel de definiţie este imprecisă. Datele sunt
semistructurate dacă: nu au o structură rigidă (de exemplu datele Web, datele sunt combinate
din câteva surse eterogene - ca în cazul depozitelor de date), nu au o structură implicită
Pagina 9 din 97
Vizitati www.tocilar.ro ! Arhiva online cu diplome, cursuri si referate postate de utilizatori.
asociată datelor, sau au o structură parţial specificată [Abiteboul, 1997]. Modelele orientat-
obiect şi relaţional au o schemă fixă pentru fiecare clasă sau fiecare relaţie. Datele
semistructurate permit o flexibilitate sporită, fiind o combinaţie a celor două concepte: clasa
şi relaţia.
Datele semistructurate conţin informaţii despre schema lor şi această schemă poate
diferi, în timp, în cadrul unei singure baze de date. Acest model care nu se bazează pe nici o
schemă, are un rol special în sistemele bazelor de date.
În acest model datele sunt autoreferite, acest lucru însemnând că schema este ataşată
datelor. Combinarea unor date dintr-o bază de date relaţională cu altele dintr-o bază de date
orientată-obiect se poate realiza prin conectarea celor două baze de date, prin intermediul
unei interfeţe, translatând datele de la fiecare sursă în date semistructurate.
În modelul semistructurat al datelor, informaţiile care sunt în mod normal asociate
unei scheme sunt incluse în interiorul datelor. În aceste baze de date nu există o distincţie
clară între date şi schemă, iar gradul de structurare depinde de aplicaţie. În anumite forme ale
modelului semistructurat există o schemă distinctă, în altele nu.
Avantajele modelului semistructurat al datelor sunt următoarele:
• Flexibilitatea - simplifică integrarea bazelor de date care au scheme diferite. Spre
deosebire de alte modele, care au o schemă de descriere a datelor, modelul semistructurat este
fără schemă, ceea ce justifică flexibilitatea sa. Flexibilitatea reprezintă un instrument util
pentru integrarea datelor, mai ales în cazul problemelor legate de moştenirea bazei de date.
• Îmbunătăţirea eficienţei regăsirii datelor publicate în Internet
• Posibilitatea integrării datelor
Documentele HTML şi cele stocate în biblioteci digitale sunt semistructurate. Spre
deosebire de fluxurile nestructurate de date (precum imagini, sunete, video), datele
semistructurate au o structură şi spre deosebire de datele structurate (bazele de date
relaţionale sau orientate-obiect), datele semistructurate nu au o schemă absolută sau o clasă
fixă, fiecare obiect conţinând propria schemă. Iregularitatea structurală nu implică inexistenţa
similarităţilor structurale între obiecte. Din contră, în mod obişnuit, obiectele semistructurate
care descriu acelaşi tip de date au structură similară.
Modelul datelor semistructurate este un model pentru integrarea bazelor de date. Este
folosit pentru descrierea datelor aflate în două sau mai multe baze de date care conţin date
similare în diferite scheme de organizare.
2.2.2 Modelarea datelor semistructurate
Pagina 10 din 97
Vizitati www.tocilar.ro ! Arhiva online cu diplome, cursuri si referate postate de utilizatori.
Datele semistructurate sunt modelate, în general, sub forma structurilor de tip graf sau
arbore, în noduri având reprezentate obiecte iar arcele reprezentând atributele obiectelor. În
plus, arcele modelează natural relaţiile de subordonare dintre două obiecte. [Reveiu, 2003]
Modelul de facto pentru datele semistructurate este OEM (Object Exchange Model),
model propus în proiectul pentru integrarea datelor numit TSIMMIS şi descris pentru prima
dată în lucrarea Multimedia database systems – Design and implementation Strategies. OEM
este un model autodescriptibil, nefiind necesară definirea anterioară a structurii unui obiect şi
nici nu există o schemă fixă de reprezentare a datelor. Fiecare obiect reprezentat conţine
propria lui schemă.
Fiecare obiect din OEM poate avea un identificator (Id), o etichetă, un tip şi o valoare.
Id-urile obiectelor pot fi simboluri cu sau fără înţelesuri speciale. De exemplu, dacă un obiect
este o pagină Web, URL-ul paginii poate fi folosit ca id-ul obiectului. Etichetele nodurilor
sunt şiruri care explicitează rolul obiectului pentru utilizator şi pentru aplicaţii. Eticheta joacă
aici două roluri: identifică un obiect şi dă sens obiectului. Obiectele pot fi atomice sau
complexe (seturi de obiecte). Valorile obiectelor atomice au tipuri atomice (valori întregi,
reale, şiruri de caractere, imagine, sunet etc.), iar cele complexe au ca valori seturi de obiecte,
reprezentate prin perechi de tipul atribut-obiect. Prin urmare, un obiect complex va avea o
definire recursivă deoarece valoarea unui obiect este parte a sa. Nodurile frunză au asociate
întotdeauna valori atomice.
Etichetele arcelor reprezintă atribute, sunt descrise prin şiruri de caractere şi
reprezintă un set de proprietăţi descriptive. O proprietate poate fi folosită într-un arc pentru a
descrie nodurile învecinate.
Pagina 11 din 97
Vizitati www.tocilar.ro ! Arhiva online cu diplome, cursuri si referate postate de utilizatori.
În figura 1 este prezentată exemplificarea modelării unei părţi dintr-o bază de date
multimedia folosind OEM.
Figura 1 – Modelul OEM al unei părţi dintr-o bază de date multimedia
Informaţii: &o1
{film: &o21
{titlu: &o30 “Titanic”,
actor principal: &o31
{nume: &o41 “DiCaprio”,
prenume: &o42 “Leonadro”},
regizor: &o32
{nume: &44 “Cameron”,
prenume: &o45 “James”},
{ actor principal: &o33,
nume: &o46 “Kate”,
prenume: &o47 “Winslet”},
premii obţinute: &o48 “11 Oscaruri”},
melodie: &o22
{titlu: &49 “My heart will go on”,
interpretă: &o34
{nume: &o50 “Dion”,
Pagina 12 din 97
Vizitati www.tocilar.ro ! Arhiva online cu diplome, cursuri si referate postate de utilizatori.
prenume: &o51 “Celine”},
premii: & o35
{an: &o52 “1998”,
nume: “Oscar pentru cea mai bună coloană sonoră”},
coloană sonoră: &o22}}
Datele stocate în baze de date relaţionale pot fi descrise cu uşurinţă folosind OEM. În
plus, OEM asigură o flexibilitate mai mare în descrierea datelor tolerând lipsa unor atribute
pentru anumite înregistrări sau existenţa mai multor valori pentru acelaşi atribut în cadrul
unei singure înregistrări.
OEM poate fi considerat mai apropiat de modelul orientat-obiect decât de cel
relaţional, în care două obiecte distincte chiar dacă au valori identice, au existenţă de sine
stătătoare, reprezentând instanţe diferite.
Scheme de organizare a datelor semistructurate
Flexibilitatea în descrierea informaţiilor adusă de modelarea datelor semistructurate
are şi dezavantaje, şi anume dificultatea formulării unei interogări relevante. S-a încercat
asocierea unor scheme în modelarea datelor semistructurate, în acest sens existând două
abordări:
• scheme flexibile – descriu aprioric datele; schemele flexibile fiind concepute astfel
încât să permită flexibilitate în descrierea datelor; se foloseşte tipul void pentru manipularea
oricărui tip de dată.
• scheme rigide – descriu cu exactitate datele şi sunt folosite pentru analiza datelor;
schema este refăcută ori de câte ori se produce o modificare a informaţiei memorate.
2.2.3 Limbaje de interogare a datelor semistructurate
Principalele elemente caracteristice ale unui limbaj de interogare pentru datele
semistructurate sunt:
• Putere de expresie: pentru reprezentarea datelor relaţionale sub forma datelor
semistructurate, limbajul semistructurat trebuie să acopere operaţiile corespunzătoare unui
limbaj relaţional standard, dar în plus trebuie să dispună de facilităţi de reorganizare a datelor,
astfel încât aceeaşi informaţie să poată fi regăsită sub o altă structură;
• Semantică: cererile trebuie optimizate astfel încât să poată ţine cont de semantica
datelor, fiind necesară o semantică precisă pentru transformarea şi optimizarea cererilor;
• Schematizare: limbajul trebuie să poată recunoaşte structurile definite pentru a le
putea manipula;
Pagina 13 din 97
Vizitati www.tocilar.ro ! Arhiva online cu diplome, cursuri si referate postate de utilizatori.
• Compunere: datele obţinute în urma unei interogări pot fi folosite ca date de intrare
în alte interogări, motiv pentru care limbajele trebuie să fie transparente.
Au fost propuse, într-o serie de proiecte de cercetare pe această temă, câteva limbaje
de interogare pentru datele semistructurate. Două dintre acestea sunt: limbajul orientat-obiect
Lorel, derivat din OQL (Object Query Language) şi limbajul UnQL (Unstructured Query
Language).
Domeniul datelor semistructurate este unul în studiu şi va avea un impact mare asupra
unei multitudini de aplicaţii, dar mai ales asupra aplicaţiilor multimedia şi a celor dezvoltate
pentru mediul Internet.
2.3 MPEG-21 – Suport pentru integrarea datelor în aplicaţii multimedia distribuite
În ciuda descrierilor complete şi detaliate ale tipurilor datelor multimedia
implementate în MPEG-7, aspecte legate de organizarea datelor şi de infrastructura unui
sistem multimedia distribuit nu pot fi descrise doar folosind metadate. Astfel că a fost iniţiat
un nou standard, MPEG-21 cu scopul de a oferi mecanisme de proiectare a sistemelor
multimedia distribuite, de a crea un mediu unic, universal accesibil pentru livrarea şi
utilizarea resurselor multimedia în diferite condiţii, ca de exemplu diferite tipuri de utilizatori,
reţele cu diferite caracteristici, terminale cu caracteristici diferite etc.
2.3.1 Prezentare generală
MPEG-21 este un standard ISO/IEC21000 al MPEG (Moving Picture Experts Group)
care defineşte un cadru de lucru deschis pentru multimedia. Forţa MPEG-21 este dată de
următoarea situaţie: există multe resurse mutimedia ce pot fi folosite la construirea unei
infrastructuri pentru distribuirea şi utilizarea conţinutului multimedia, dar nu există nici o
arhitectură pentru descrierea modului în care aceste elemente interacţionează între ele. Scopul
standardului MPEG-21 este să definească un cadru de lucru deschis pentru multimedia care
să permită utilizarea transparentă şi la performanţe bune a resurselor multimedia folosind
reţele şi dispozitive periferice diverse. Se urmăreşte gestiunea conţinutului multimedia,
gestiunea proprietăţii intelectuale şi adaptarea conţinutului la resursele disponibile prin
intermediul diferitelor clase de servicii. MPEG-21 oferă un suport deschis pentru distribuirea
şi utilizarea datelor multimedia. [Kosch, 2004]
MPEG acoperă întregul conţinut multimedia din punctul de vedere al canalelor de
distribuţie folosite, al modalităţilor de creare a conţinutului, din punct de vedere al modalităţii
de producţie, în vederea personalizării, consumului, prezentării şi comercializării acestuia.
Pentru realizarea acestui lucru, MPEG-21 propune norme pentru un standard deschis pentru
Pagina 14 din 97
Vizitati www.tocilar.ro ! Arhiva online cu diplome, cursuri si referate postate de utilizatori.
crearea, distribuirea şi utilizarea datelor multimedia. Acest standard se referă la toţi actorii
implicaţi, de la creatorii de conţinut, producători, distribuitori şi furnizorii de servicii.
MPEG-21 standardizează fluxul informaţiilor şi serviciilor multimedia de la crearea
conţinutului până la livrarea către utilizatorii finali. Pentru a realiza acest lucru, conţinutul
trebuie identificat, descris, gestionat şi protejat. Transportul şi livrarea conţinutului poate
avea loc peste diferite reţele, între o varietate de terminale.
Există o serie de arhitecturi apărute ca răspuns la varietatea tipurilor de aplicaţii care
utilizează conţinutul multimedia. Există trei modele principale folosite pentru gestiunea,
descrierea şi regăsirea resurselor multimedia şi anume Dublin Core, SMPTE şi MPEG-7.
Pentru a evita recomandarea unui model în defavoarea altuia, în mod nejustificat, MPEG-21
propune descrierea suportului multimedia sub forma unei arhitecturi generice. [ISO, 2001]
MPEG-21 se bazează pe două concepte esenţiale: definirea unei unităţi fundamentale
de distribuţie şi tranzacţionare - elementul digital şi utilizatorii care interacţionează cu
elementele digitale. Elementul digital este un obiect digital, structurat care are o reprezentare
standard, ce poate fi identificat şi care are asociate metadate. Elementele digitale conţin atât
resursele multimedia (conţinutul) cât şi metadatele asociate resurselor sau întregului element
digital. În accepţiunea MPEG-21, utilizatorul este orice entitate care interacţionează cu
mediul MPEG-21 sau care foloseşte un element digital, ca de exemplu un consumator al
datelor multimedia, o organizaţie, sau un alt standard ce foloseşte resursele multimedia. Un
utilizator poate folosi conţinutul în mai multe feluri: prin publicare sau prin livrare şi poate
avea drepturi şi responsabilităţi specifice în funcţie de modalităţile de interacţiune cu alţi
utilizatori în cadrul MPEG-21.
Principalele elementele folosite în definirea arhitecturii MPEG-21 sunt:
• Elementul digital - este un container ierarhic de resurse eterogene (video, audio, text
etc.), metadate şi alte elemente digitale. Un element digital este o unitate elementară de
distribuţie şi tranzacţionare;
• Declararea elementului digital – defineşte un set de termeni folosiţi la declararea
elementelor digitale;
• Identificarea şi descrierea elementului digital – presupune identificarea şi descrierea
elementului digital, natura lui, tipul sau granularitatea (film, scenă sau cadru);
• Gestiunea şi utilizarea conţinutului – oferă interfeţe şi protocoale care permit
crearea, manipularea, căutarea, accesarea, stocarea, livrarea şi reutilizarea conţinutului de-a
lungul canalelor de distribuţie şi consum;
Pagina 15 din 97
Vizitati www.tocilar.ro ! Arhiva online cu diplome, cursuri si referate postate de utilizatori.
• Protejarea şi gestiunea proprietăţii intelectuale – permite gestiunea conţinutului şi
protejarea elementelor digitale într-o serie de reţele şi dispozitive;
• Terminale şi reţele – oferă instrumente ce permit accesul transparent la conţinut prin
intermediul reţelelor şi terminalelor, realizând inclusiv controlul calităţii serviciului;
• Reprezentarea conţinutului – cum sunt reprezentate resursele media;
• Raportarea evenimentelor – conţine metrici şi interfeţe ce permit utilizatorilor să
evalueze performanţele tuturor evenimentelor raportabile din cadrul sistemului.
Structura MPEG-21
În prezent sunt definite 18 părţi ale MPEG-21: [ISO/IEC 21000-1-18] :
Partea 1: Tehnologiile şi strategia MPEG-21,
Partea 2: Declararea elementului digital (DID)
Partea 3: Identificarea elementului digital (DII)
Partea 4: Gestiunea şi protecţia proprietăţii intelectuale (IPMP)
Partea 5: Limbajul de reprezentare a drepturilor (REL)
Partea 6: Dicţionar de drepturi ale datelor (RDD)
Partea 7: Adaptarea elementului digital (DIA),
Partea 8: Software de referinţă
Partea 9: Formate de fişiere pentru stocarea şi regăsirea elementelor digitale ale
MPEG-21
Partea 10: Prelucrarea elementelor digitale
Partea 11: Asocieri persistente
Partea 12: Testare distribuirii resurselor MPEG-21
Partea 13: Codarea secvenţelor video scalabile
Partea 14: Conformanţa
Partea 15: Raportarea evenimentelor
Partea 16: Formatul binar
Partea 17: Identificarea fragmentelor
Partea 18: Streaming-ul elementului digital
2.3.2 Declararea elementelor digitale
Declararea elementului digital presupune definirea unui set de termeni şi concepte
folosite la definirea elementelor digitale, la descrierea sintaxei şi semanticii fiecărui element
digital şi a schemei de reprezentare în XML.
Declararea unui element digital se realizează în 3 etape:
- Crearea modelului abstract,
Pagina 16 din 97
Vizitati www.tocilar.ro ! Arhiva online cu diplome, cursuri si referate postate de utilizatori.
- Reprezentarea modelului abstract în XML,
- Crearea schemei XML.
• Modelul abstract – defineşte un set de termeni şi concepte care formează un model
pentru declararea elementelor digitale. Modelul abstract permite reprezentarea elementelor
digitale în diferite moduri. Modelul abstract defineşte entităţile necesare declarării
elementului digital.
Un prim set de entităţi este format din elementele de bază folosite pentru declararea
elementelor digitale:
- resursa – este un flux de date identificabil, ca de exemplu un fişier video, imagine,
secvenţă audio sau text.
- componenta – are rolul de a lega una sau mai multe resurse de un set de descriptori
ce conţin informaţii secundare referitoare la resursele componentei. Componenta este folosită
doar pentru gruparea resurselor şi a datelor secundare transmise printr-un descriptor.
- elementul digital – reprezintă conectarea unuia sau mai multor elemente sau
componente la un descriptor. Se pot crea elemente digitale individuale şi elemente compuse.
- descriptorul – introduce un mecanism extensibil care poate fi folosit pentru asocierea
informaţiilor cu alte entităţi ale modelului abstract. Un descriptor asociază informaţii
textuale, secundare entităţii incluse.
- containerul – reprezintă asocierea unuia sau mai multor elemente digitale şi/sau
container(e) la un descriptor. Containerele sunt folosite pentru gruparea elementelor digitale.
Descriptorul conţine informaţii despre containerul reprezentat.
Pentru rafinarea descrierii resurselor se foloseşte următorul set de entităţi:
- fragmentul – identifică un anumit punct sau interval din cadrul unei resurse
(secvenţă video, audio etc.). Fragmentele sunt specifice tipului resursei.
- ancora – conectează descriptori de un fragment. În acest caz, descriptorii conţin
informaţii despre fragmentele ancorei. Ancora este folosită pentru gruparea fragmentelor şi
descriptorilor. Exemplu de ancoră: un moment de timp al unei resurse video, o formă
poligonală din cadrul unei resurse de tip imagine.
- adnotarea – permite adăugarea de informaţii la o entitate a modelului fără a modifica
entitatea.
- alternativa – este o opţiune din mai multe existente; ca de exemplu, alternativa unei
conexiuni la Internet la o lărgime de bandă mare sau alternativa unei conexiuni prin dial-up.
- selecţia – este opţiunea utilizatorului din alternativele disponibile.
Pagina 17 din 97
Vizitati www.tocilar.ro ! Arhiva online cu diplome, cursuri si referate postate de utilizatori.
- condiţia – pe baza selecţiei utilizatorului, pot fi satisfăcute (sau nu) condiţiile
asociate unei entităţi a elementului digital şi entitatea elementului digital poate deveni
disponibilă (sau nu).
• Reprezentarea modelului abstract în XML – presupune descrierea sintaxei XML
pentru fiecare entitate definită în modelul abstract. Această sintaxă formează limbajul de
declarare a elementului digital al MPEG-21 (DIDL – Digital Item Declaration). Declararea
elementelor digitale reprezentate în conformitate cu sintaxa DIDL formează documentul
DIDL.
DIDL defineşte câteva elemente suplimentare care nu corespund entităţilor modelului
abstract:
- Elementul DIDL ca rădăcină a documentului DIDL,
- Elementul Referinţă - reprezintă o legătură la un alt element al documentului DIDL
şi include conţinutul elementul referenţiat în elementul referit. Referinţele se pot face la
elemente din acelaşi document DIDL sau la elemente din alt document DIDL. O referinţă
internă permite păstrarea unei singure surse pentru un element care apare în documentul
DIDL în mai multe locuri. Referinţa externă permite unui document DIDL să fie împărţit în
mai multe documente DIDL conectate.
- Elementul Declaraţii este folosit pentru definirea elementelor documentului DIDL,
fără a le instanţia. Un element declarat poate fi instanţiat folosind elementul Referinţă.
• Schema XML – specifică sintaxa DIDL şi constrângerile pentru structura
documentelor DIDL.
Relaţia dintre modelul abstract MPEG-21 şi DIDL este prezentată în figura 4.2.
Figura 2 - Relaţia dintre modelul abstract MPEG-21 şi DIDL
În continuare sunt prezentate componentele de bază ale schemei de declarare a
elementelor digitale. Aceste elemente se folosesc în schemele documentelor XML.
Pagina 18 din 97
Vizitati www.tocilar.ro ! Arhiva online cu diplome, cursuri si referate postate de utilizatori.
• Schema de declarare a elementului digital
Schema de declarare a unui element digital numit ElementDigital care are la primul
nivel un container sau un alt element digital este:
<xsd:schema targetNamespace = "urn:mpeg:mpeg21:2002:01-
DIDL-NS" xmlns = "urn:mpeg:mpeg21:2002:01-DIDL-NS"
xmlns:xsd = "http://www.w3.org/2001/XMLSchema"
version = "0.01">
<xsd:element name = "ElementDigital">
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="Declaratii" minOccurs="0"/>
<xsd:choice>
<xsd:element ref="Container"/>
<xsd:element ref="Element"/>
</xsd:choice>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:schema>
• Container
Containerul are o structură ierarhică, iar definirea sa se realizează recursiv:
<xsd:element name="Container">
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="Descriptor" minOccurs="0"
maxOccurs="unbounded"/>
<xsd:choice>
<xsd:element ref="Referinta"/>
<xsd:sequence>
<xsd:element ref="Container" minOccurs="0"
maxOccurs="unbounded"/>
<xsd:element ref="Element" minOccurs="0"
maxOccurs="unbounded"/>
Pagina 19 din 97
Vizitati www.tocilar.ro ! Arhiva online cu diplome, cursuri si referate postate de utilizatori.
</xsd:sequence>
</xsd:choice>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
De exemplu, dacă într-un element digital vor fi grupate mai multe elemente ce conţin
câte o secvenţă video, atunci pentru fiecare secvenţă se va folosi câte un container ce conţine
declararea elementului.
• Declararea descriptorului elementului digital compus este:
<ElementDigital>
<Container>
<Descriptor>
<Declarare mimeType = "video/avi">Secventele Video</Declarare>
</Descriptor>
<Element id = "Secventa1">
</Element>
<Element id = "Secventa2">
</Element>
</Container>
</ElementDigital>
2.3.3 Adaptarea conţinutului utilizând MPEG-21
Standardul MPEG-21 facilitează dezvoltarea de soluţii de adaptare a conţinutului
distribuit în funcţie de caracteristicile tehnice ale terminalelor folosite pentru receptarea
datelor, de caracteristicile tehnice ale mediului de comunicaţie folosit sau în funcţie de
preferinţele utilizatorului.
Pentru adaptarea conţinutului multimedia este necesară existenţa unei descrieri a
mediului de lucru, pe lângă descrierea conţinutului propriu-zis. În vederea adaptării
conţinutului multimedia trebuie să existe o descriere a sa, folosind unul din standardele
adecvate, ca de exemplu Dublin Core, SMPTE sau MPEG-7. Partea a şaptea a MPEG-21,
denumită Adaptarea elementului digital (DIA) este dedicată descrierii caracteristicilor
mediului şi adaptării elementelor digitale la aceste caracteristici.
Pagina 20 din 97
Vizitati www.tocilar.ro ! Arhiva online cu diplome, cursuri si referate postate de utilizatori.
DIA defineşte doar instrumentele necesare în procesul de adaptare, nu realizează şi
adaptarea conţinutului.
Categoriile de instrumente descriptive folosite sunt:
• Instrumentele pentru descrierea mediului – au rolul de a descrie caracteristicile
semnificative ale contextului şi anume:
- caracteristicile terminalului folosit pentru receptarea sau crearea conţinutului
multimedia: posibilităţile de codare/decodare ale terminalului, facilităţile/dispozitivele de
intrare-ieşire conectate, alte caracteristici relevante;
- caracteristicile reţelei: capacitatea reţelei, tipul conexiunii etc.;
- caracteristicile utilizatorului: informaţii despre utilizator, preferinţele utilizatorului,
un istoric al datelor utilizate, preferinţe legate de prezentarea informaţiilor, caracteristici de
accesibilitate şi localizarea acestuia;
- caracteristici ale mediul natural: atributele audiovizuale măsurabile ale mediului
natural, care afectează modalitatea în care conţinutul multimedia este livrat şi/sau consumat
de utilizator: nivelul zgomotului, intensitatea luminii, fusul orar, locaţia.
• Instrumentele de adaptare a resurselor sunt folosite pentru descrierea datelor
structurale, ale fluxurilor de biţi şi a datelor despre adaptabilitatea metadatelor şi se foloseşte
pentru aceasta Binary Syntax Description Language. Descrierea se bazează pe împărţirea
fluxului de biţi în componente logice, ca de exemplu împărţirea unei secvenţe video în cadre.
Fluxul de biţi este apoi transformat de un motor pentru adaptarea resursei elementului digital
într-un descriptor al sintaxei fluxului (BSD), transformare care poate fi făcută sub controlul
XSLT (Extensible Stylesheet Language Transformations). Descriptorul este de dorit să fie
independent de un format media ceea ce permite realizarea adaptării resurselor binare în orice
locaţie.
• Instrumentele pentru adaptarea metadatelor – identifică datele care pot fi utilizate
pentru reducerea complexităţii instanţelor XML de adaptare a metadatelor. Specificaţiile se
referă la filtrarea şi scalarea conţinutului şi la integrarea a două sau mai multe instanţe ale
descrierilor.
Legăturile dintre principalele componente ale DIA sunt prezentate în figura 3.
Pagina 21 din 97
Vizitati www.tocilar.ro ! Arhiva online cu diplome, cursuri si referate postate de utilizatori.
Figura 3– Adaptarea elementului digital şi instrumente pentru DIA
Declararea unui DIA pentru descrierea caracteristicilor statice şi dinamice ale unei
reţele se poate face:
<DIA xmlns="urn:mpeg:mpeg21:dia:schema:2003"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<Descriere xsi:type="UtilizareaMediului">
<Retea>
<Capacitate Maxima="384000" MinimaGarantata="32000"/>
</Retea>
</Descriere>
</DIA>
Caracteristicile monitorului unui terminal se pot descrie:
<DIA xmlns="urn:mpeg:mpeg21:dia:schema:2003"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
Pagina 22 din 97
Vizitati www.tocilar.ro ! Arhiva online cu diplome, cursuri si referate postate de utilizatori.
<Terminal>
<Monitor>
<Caracteristici bitiPerPixel="24" Culori="32biti" RataRefresh="70">
<Rezolutia Orizontala="1024" Verticala="768"/>
</Caracteristici>
</Monitor>
</Terminal>
</DIA>
CAPITOLUL III
XML CA BAZĂ DE DATE
3.1 Este XML-ul o bază de date?
Înainte de a discuta despre XML şi baze de date trebuie să răspundem la întrebarea
„Este XML-ul o bază de date?”
Un document XML este o bază de date în sensul cel mai strict al cuvântului şi anume
este o colecţie de date. Se poate considera că aceste documente nu sunt diferite de orice alt tip
de fişiere – în fond, toate fişierele conţin anumite tipuri de date. Având formatul unei baze de
date documentele XML prezintă anumite avantaje. De exemplu este auto-descris (tag-urile
descriu structura şi numele tipurilor de date, dar nu şi semantica), este portabil (Unicode), şi
poate descrie date în structuri de arbori sau grafuri. De asemenea are şi dezavantaje. De
exemplu, este prolixs(neclar) şi accesul la date este greoi datorită analizării şi conversiei
textului.
Putem considera şi că XML şi tehnologiile asociate constituie o bază de date în sensul
mai larg al cuvântului – adică, un sistem de gestiune a bazelor de date (SGBD). XML oferă
multe din avantajele bazelor de date: stocare (documente XML), scheme (DTD-uri, scheme
XML, RELAX NG, ş.a,), limbaje de interogare (XQuery, XPath, XQL, XML-QL, QUILT,
etc.), interfeţe de programare (SAX, DOM, JDOM). Totuşi multe componente ale bazelor de
date convenţionale: stocare eficientă, indecşi, securitate, tranzacţii şi integritatea datelor,
accesul multi-user, triggere, interogări făcute pe mai multe documente ş.a.
Astfel, se pot folosi documente XML ca o bază de date într-un mediu cu cerinţe
modeste şi date puţine, dar această soluţie nu este viabilă într-un mediu pentru producţie în
masă, unde există mulţi utilizatori, cerinţe stricte de integritate a datelor şi nevoia de o
performanţă bună.
Pagina 23 din 97
Vizitati www.tocilar.ro ! Arhiva online cu diplome, cursuri si referate postate de utilizatori.
3.2 Date şi documente
Cel mai important factor în alegerea unei baze de date este ce va stoca aceasta: date
sau documente. XML-ul poate fi folosit doar pentru a transporta date între baza de date şi o
aplicaţie sau poate fi folosit integral ca în cazul documentelor XHTML şi DocBook. Scopul
utilizării XML este important deoarece toate documentele centrate pe date au anumite
caracteristici comune, la fel se întâmpla şi în cazul informaţiilor centrate pe documente, şi
aceste caracteristici influenţează felul cum XML-ul este stocat în baza de date.
3.2.1 Documente centrate pe date
Documentele centrate pe date sunt documente care folosesc XML-ul pentru
transportul datelor. Aceste documente sunt folosite de către aplicaţii şi nu are nici o
importanţă faptul că informaţiile folosite au fost reţinute pentru o perioadă de timp în
documente XML. Exemple de documente centrate pe date sunt ordine de plată, programarea
zborurilor, date ştiinţifice.
Documente centrate pe date au o structură regulată, datele sunt atomice (cea mai mică
unitate independenta de date este un element sau un atribut). Ordinea elementelor care apar în
document nu este importantă, decât în momentul validării documentului.
Informaţiile care există în documentele centrate pe date pot proveni din baza de date
(caz în care se doreşte extragerea lor în fişiere XML), dar şi din afara bazei de date (caz în
care se doreşte stocarea acestora în baza de date). Un exemplu de informaţii care provin dintr-
o bază de date sunt cantităţile de date stocare în bazele de date relaţionale, iar un exemplu de
informaţii care se doresc a fi introduse într-o bază de date pot fi considerate datele ştiinţifice
obţinute de un sistem de măsurători şi convertite în XML.
De exemplu următorul ordin de vânzare este un document centrat pe date:
<OrdinVanzari NumarOV="12345">
<Client NumarClient="543">
<NumeClient>ABC Industries</NumeClient>
<Strada>123 Main St.</Strada>
<Oras>Chicago</Oras>
<Stat>IL</Stat>
<CodPostal>60609</CodPostal>
</Client>
<DataOrdin>981215</DataOrdin>
<Item NumarItem="1">
Pagina 24 din 97
Vizitati www.tocilar.ro ! Arhiva online cu diplome, cursuri si referate postate de utilizatori.
<Parte NumarParte="123">
<Descriere>
<p><b>Cheie reglabila:</b><br />
Hotel inoxidabil,
Garantie pe viata.</p>
</Descriere>
<Pret>9.95</Pret>
</Parte>
<Cantitate>10</Cantitate>
</Item>
<Item NumarItem="2">
<Parte NumarParte="456">
<Descriere>
<p><b>Separator:<b><br />
Aluminiu, un an garantie.</p>
</Descriere>
<Pret>13.27</Pret>
</Parte>
<Cantitate>5</Cantitate>
</Item>
</OrdinVanzari>
Pe lângă documentele centrate pe date cu structura asemănătoare cu documentul din
exemplul anterior, multe documente care conţin şi text adiţional sunt centrate pe date. Spre
exemplu să considerăm o pagină web care conţine informaţii despre o carte. Deşi pagina
conţine în mare parte text, structura acelui text este regulată, şi o parte din acel text este
comună tuturor paginilor care descriu cărţi, fiecare porţiune de text specific având dimensiuni
limitate. Astfel pagina ar putea fi construită dintr-un document XML simplu, centrat pe date
care conţine informaţii despre o singură carte şi este obţinut dintr-o bază de date şi un
stylesheet XSL care adaugă textul care leagă informaţiile din XML. În general orice site web
care construieşte documente HTML dinamic prin completarea unui template cu informaţii
dintr-o bază de date poate fi înlocuit cu mai multe documente XML centrate pe date şi unul
sau mai multe stylesheet-uri XSL.
De exemplu, să considerăm următorul document care descrie un zbor:
Pagina 25 din 97
Vizitati www.tocilar.ro ! Arhiva online cu diplome, cursuri si referate postate de utilizatori.
<InfoZbor>
<LinieAeriana>ABC Airways</LinieAeriana> ofera <Numar>trei</Numar>
zboruri zilnice non-stop din <Origine>Dallas</Origine> spre
<Destinatie>Fort Worth</Destinatie>. Orele de plecare sunt
<Plecare>09:15</Plecare>, <Plecare>11:15</Plecare>,
and <Plecare>13:15</Plecare>. Sosirile sunt cateva minute mai tarziu.
</InfoZbor>
Acesta ar putea fi construit dintr-un fişier XML şi un stylesheet simplu:
<Zboruri>
<LinieAeriana>ABC Airways</LinieAeriana>
<Origine>Dallas</Origine>
<Destinatie>Fort Worth</Destinatie>
<Zbor>
<Plecare>09:15</Plecare>
<Sosire>09:16</Sosire>
</Zbor>
<Zbor>
<Plecare>11:15</Plecare>
<Sosire>11:16</Sosire>
</Zbor>
<Zbor>
<Plecare>13:15</Plecare>
<Sosire>13:16</Sosire>
</Zbor>
</Zboruri>
3.2.2 Informaţii centrate pe documente
Documentele care folosesc viziunea centrată pe documente sunt, de obicei, acele
documente care sunt destinate folosirii de către utilizatori. Exemple de astfel de documente
sunt cărţile, email, anunţuri publicitare şi aproape orice document XHTML scris de mână.
Acestea sunt caracterizate de o structură mai puţin regulată, datele nu sunt atomice (cea mai
mică unitate independentă de informaţie poate fi formată dintr-un element îmbinat cu alte
informaţii din document). Ordinea elementelor care apar în document este aproape
întotdeauna importantă.
Pagina 26 din 97
Vizitati www.tocilar.ro ! Arhiva online cu diplome, cursuri si referate postate de utilizatori.
Aceste tipuri de documente sunt de obicei scrise manual în XML sau în alte formate
cum ar fi RTF, PDF sau SGML şi apoi sunt transformate în XML. Spre deosebire de
documentele centrate pe date aceste documente nu pot proveni din baze de date.
Spre exemplu următorul document ce conţine descrierea unui produs este centrat pe
documente:
<Produs>
<Intro>
<NumeProdus>Cheie reglabila</NumeProdus> de la <Producator>Full
Fabrication Labs,Inc.</Producator>este<Sumar>ca o cheie universala,
dar mai mica.</Sumar>
</Intro>
<Descriere>
<Paragraf>Cheia universala, care are <i> doua versiuni stanga si dreapta </i>, este
confectionata din <b>cel mai fin hotel inoxidabil
</b>. Manerul cauciucat se adapteaza la mainile dumneavoastra
chiar si in cele mai aluneacoase situatii. Se poate regla
prin mai multe discuri.</Paragraf>
<Paragraf>Puteti:</Paragraf>
<Lista>
<Item><Link URL="Comanda.html">comanda propria dumneavoastra
cheie reglabila </Link></Item>
<Item><Link URL="Wrenches.htm">Cititi mai multe despre chei</Link></Item>
<Item><Link URL="Catalog.zip">Descarcati catalogul</Link></Item>
</Lista>
<Paragraf>Cheia reglabila costa <b>doar 44.90 RON</b> si, daca veti
comanda acum, veti primi un <b>ciocan</b>
cadou.</Para>
</Descriere>
</Produs>
3.2.3 Date, documente şi baze de date
În realitate diferenţa dintre documentele centrate pe date şi cele centrate pe documente
nu este întotdeauna clară. Astfel de documente sunt cele legale sau medicale, care sunt scrise
Pagina 27 din 97
Vizitati www.tocilar.ro ! Arhiva online cu diplome, cursuri si referate postate de utilizatori.
ca text dar conţin şi porţiuni de date cum ar fi nume, date, proceduri şi de multe ori trebuiesc
stocate în întregime din cauze legale.
Cu toate acestea clasificarea documentelor ca fiind centrate pe date sau pe documente
poate determina tipul bazei de date necesare stocării informaţiilor din aceste documente. De
obicei datele sunt stocate într-o bază de date tradiţională cum sunt cele relaţionale sau
orientate-obiect. Documentele sunt stocate într-o bază de date nativă XML (o bază de date
destinată stocării XML) sau un sistem de gestionare a conţinuturilor (content management
system) – o aplicaţie destinată administrării documentelor şi construită peste o bază de date
nativă XML.
Totuşi aceste reguli nu sunt stricte. Datele – în special datele semistructurate – pot fi
stocate în baze de date native XML şi documentele pot fi stocate în baze de date tradiţionale
atunci când nu sunt necesare foarte multe caracteristici specifice XML. În plus, graniţele
dintre bazele de date tradiţionale şi cele native XML devin din ce în ce mai neclare, deoarece
la bazele de date tradiţionale se adaugă facilitaţi native XML şi bazele de date native XML
suportă stocarea fragmentelor de documente în baze de date, de obicei relaţionale, externe.
3.3 Stocarea şi recuperarea datelor
Pentru transferarea datelor între documente XML şi o bază de date, este necesară
maparea schemei documentului XML (DTD, Scheme XML, RELAX NG, etc.) pe schema
bazei de date. Software-ul pentru transferul de date este construit peste această mapare.
Software-ul poate folosi un limbaj de interogare XML (cum ar fi XPath, XQuery) sau poate
transfera direct date conform cu maparea (echivalentul în XML al interogării SELECT *
FROM Tabelă).
În al doilea caz, structura documentului şi structura necesară pentru mapare trebuie să
fie identice. Deoarece acest lucru se întâmplă destul de rar, produsele care folosesc această
strategie sunt adesea folosite împreună cu XSLT. Astfel, înainte de transferarea datelor în
baza de date, documentul este întâi adus la structura necesară mapării şi apoi datele sunt
transferate. Similar după transferarea datelor din baza de date, documentul obţinut este adus
la structura folosită de către aplicaţie.
3.3.1 Maparea schemelor documentelor pe schemele bazelor de date
Mapările între schemele documentelor şi schemele bazelor de date sunt efectuate pe
tipurile elementelor, atribute, şi text. Aproape întotdeauna se omit structurile fizice (cum ar fi
entităţile şi informaţia codificată) şi unele structuri logice (cum ar fi instrucţiunile de
procesare, comentariile). Aceste omiteri nu au o influenţă prea mare, deoarece baza de date şi
aplicaţia sunt interesate numai de datele din documentul XML.
Pagina 28 din 97
Vizitati www.tocilar.ro ! Arhiva online cu diplome, cursuri si referate postate de utilizatori.
O consecinţă a acestor transformări – adică stocarea datelor dintr-un document într-o
bază de date şi apoi reconstruirea documentului din datele existente în baza de date – este
obţinerea unui document diferit. Dacă acest lucru este acceptabil depinde de cerinţele fiecărui
proiect şi poate influenţa alegerea softului.
De obicei sunt folosite două metode pentru a mapa schema unui document XML pe
schema unei baze de date: maparea bazată pe tabele şi maparea obiectual-relaţională.
3.3.1.1 Maparea bazată pe tabele
Maparea bazată pe tabele este folosită de multe produse care efectuează transferul de
date între un document XML şi o bază de date relaţională. Aceasta modelează un document
XML ca o singură tabelă sau ca un set de tabele. Structura documentului XML este arătată în
exemplul următor.
<bazadedate>
<tabela>
<linie>
<coloana1>...</coloana1>
<coloana2>...</coloana2>
</linie>
<linie>
</linie>
</tabela>
<tabela>
</tabela>
</bazadedate>
În funcţie de software datele din coloane pot fi stocate ca elemente descendente sau ca
atribute. În plus, produsele care folosesc mapări bazate pe tabele de multe ori includ metadate
fie la începutul documentului fie ca atribute asociate fiecărui element din tabelă sau coloană.
Pagina 29 din 97
Vizitati www.tocilar.ro ! Arhiva online cu diplome, cursuri si referate postate de utilizatori.
Maparea bazată pe tabele este utilizată pentru serializarea datelor relaţionale, ca în
cazul transferării datelor între două baze de date relaţionale. Dezavantajul acestei mapări este
că nu poate fi folosită pentru un document XML care nu respectă formatul din exemplu.
3.3.1.2 Maparea obiectual-relaţională
Maparea obiectual-relaţională este folosită de către toate bazele de date relaţionale
care suportă XML şi anumite produse middleware. Aceasta modelează datele din documentul
XML ca un arbore de obiecte care sunt specifice datelor din document. În acest model,
tipurile de elemente cu atribute sunt în general modelate în clase. Tipurile de elemente
simple, atributele, şi PCDATA sunt modelate ca proprietăţi scalare. Modelul este apoi mapat
pe bazele de date relaţionale folosind tehnici de mapare obiectual-relaţionale tradiţionale.
Astfel clasele sunt mapate pe tabele, proprietăţile scalare pe coloane, şi proprietăţile cu valori
obiect sunt mapate pe perechi de chei primare/chei străine.
Denumirea de „mapare obiectual-relaţională” este de fapt un termen impropriu,
deoarece arborele de obiecte poate fi mapat direct pe baze de date orientate obiect şi
ierarhizate. Totuşi este folosit pentru că majoritatea produselor care folosesc această mapare
folosesc baze de date relaţionale şi acest termen este bine cunoscut.
Este importantă înţelegerea faptului că modelul obiectual din această mapare nu este
modelul DOM (Document Object Model). DOM-ul modelează chiar documentul şi este
acelaşi pentru toate documentele XML, în timp ce modelul descris mai sus modelează datele
din document şi este diferit pentru fiecare set de documente XML care corespund unei
scheme XML de date. De exemplu ordinul de vânzări din secţiunea 3.2.1 ar putea fi modelat
ca un arbore de obiecte format din 4 clase – OrdineVânzări, Client, Item, şi Parte – aşa cum
se arată în diagrama de mai jos:
OrdineVânzări
/ | \
Client Item Item
| |
Parte Parte
Dacă ar trebui să construim un arbore DOM din acelaşi document, acesta ar fi compus
din obiecte cum ar fi Element, Atribut şi Text.
Pagina 30 din 97
Vizitati www.tocilar.ro ! Arhiva online cu diplome, cursuri si referate postate de utilizatori.
Element ------ Atribut
(OrdineVânzări) (Număr OV)
_________/ / \ \_____
/ / \ \
Element Text Element Element
(Client) (Data ordinului) (Item) (Item)
| | |
etc. etc. etc.
Instanţierea obiectelor din model depinde de produsul folosit. Unele produse dau
posibilitatea generării claselor în model şi apoi folosirea obiectelor din aceste clase în
aplicaţii. În cazul folosirii acestor produse, datele sunt transferate între documentul XML şi
aceste obiecte, şi între aceste obiecte şi baza de date. Alte produse folosesc aceste obiecte
numai pentru a vizualiza maparea şi transferul de date direct între documentul XML şi baza
de date.
Felul în care maparea obiectual-relaţională este suportată variază de la produs la
produs. De exemplu:
Toate produsele suportă maparea tipurilor complexe de elemente pe clase şi a tipurilor
simple de elemente şi atribute pe proprietăţi.
Toate produsele dau posibilitatea desemnării unui element rădăcină care nu este
mapat pe modelul obiect sau pe baza de date. Acest element este folositor atunci când se
doreşte stocarea obiectelor cu mai multe nivele în acelaşi document XML.
Majoritatea produselor oferă posibilitatea specificării dacă proprietăţile sunt mapate
pe atribute sau pe elemente descendente în documentul XML. Unele produse permit
combinarea atributelor cu elementele descendente; altele cer folosirea numai a elementelor
descendente sau a atributelor.
Majoritatea produselor permit folosirea numelor diferite în documentul XML şi baza
de date, dar sunt anumite produse care necesită folosirea aceloraşi nume atât în documentul
XML cât şi în baza de date.
Majoritatea produselor permit specificarea ordinii în care elementele descendente apar
în părintele lor, dar care face imposibilă construirea mai multor modele pentru conţinut. Din
fericire, modelele pentru conţinut suportate sunt suficiente pentru majoritatea documentelor
centrate pe date (ordinea este importantă numai dacă se face validarea documentului).
3.3.2 Limbaje de interogare
Pagina 31 din 97
Vizitati www.tocilar.ro ! Arhiva online cu diplome, cursuri si referate postate de utilizatori.
Multe produse transferă date direct conform cu modelul pe care sunt construite.
Deoarece structura documentului XML este de obicei diferită de structura bazei de date,
aceste produse deseori conţin sau sunt folosite cu XSLT. Acesta dă posibilitatea utilizatorilor
să transforme documente la structura modelului înaintea transferării datelor în baza de date, şi
invers. Deoarece procesarea XSLT poate fi scumpă, unele produse conţin un număr limitat de
transformări în mapările lor.
Soluţia pe termen lung la această problemă este implementarea unor limbaje de
interogare care returnează XML. În prezent cele mai multe asemenea limbaje se bazează pe
fraze SELECT integrate în şabloane. Se presupune că această situaţie se va schimba atunci
când XQuery şi SQL/XML vor fi finalizate, acestea aflându-se în lucru. Aproape toate
limbajele de interogare XML sunt deocamdată read-only, deci vor fi necesare metode diferite
pentru inserarea, actualizarea şi ştergerea datelor (în viitor aceste facilitaţi vor fi adăugate).
3.3.2.1 Limbaje de interogare bazate pe şabloane
Cele mai des întâlnite limbaje de interogare care returnează XML din baze de date
relaţionale sunt cele bazate pe şabloane. În aceste limbaje, nu există o mapare predefinită
între document şi baza de date. Frazele SELECT sunt integrate într-un şablon şi rezultatele
sunt procesate de către software-ul care transfera date. De exemplu, următorul template
foloseşte elementele <SelectStmt> pentru a include fraze SELECT şi numele coloanelor
pentru a determina unde trebuiesc plasate rezultatele:
<?xml version="1.0"?>
<InfoZbor>
<Introducere> Urmatoarele zboruri sunt diponibile:</Introduction>
<SelectStmt>SELECT Airline, FltNumber,
Depart, Arrive FROM Flights</SelectStmt>
<Zbor>
<LinieAeriana>$Airline</LinieAeriana>
<NumarFlt>$FltNumber</NumarFlt>
<Plecare>$Depart</Plecare>
<Sosire>$Arrive</Sosire>
</Zbor>
<Concluzie>Speram ca unul dintre ele va este de folos</Concluzie>
</InfoZbor>
Pagina 32 din 97
Vizitati www.tocilar.ro ! Arhiva online cu diplome, cursuri si referate postate de utilizatori.
Rezultatul procesării unui asemenea şablon ar putea fi:
<?xml version="1.0"?>
<InfoZbor>
<Introducere> Urmatoarele zboruri sunt diponibile:</Introduction>
<Zboruri>
<Zbor>
<LinieAeriana>ACME</LinieAeriana>
<NumarFlt>123</NumarFlt>
<Plecare>Dec 12, 1998 13:43</Plecare>
<Sosire>Dec 13, 1998 01:21</Sosire>
</Zbor>
</Zboruri>
<Concluzie>Speram ca unul dintre ele va este de folos</Concluzie>
</InfoZbor>
Limbajele de interogare bazate pe şabloane pot fi foarte flexibile. Deşi setul de
caracteristici variază de la un produs la altul, există unele caracteristici comune:
Abilitatea de a plasa seturi de rezultate oriunde în documentul de ieşire, incluzând ca
parametrii şi frazele SELECT .
Construcţii cum ar fi cicluri FOR şi instrucţiuni IF.
Definiri de variabile şi funcţii
Parametrizarea frazelor SELECT prin intermediul parametrilor HTTP.
Limbajele de interogare bazate pe şabloane sunt folosite aproape exclusiv pentru a
transfera date din baze de date relaţionale în documente XML. Deşi unele produse care
folosesc limbaje de interogare bazate pe şabloane pot transfera date din documente XML în
baze de date relaţionale, ele nu folosesc şabloanele numai pentru acest lucru. În schimb ele
folosesc o mapare bazată pe tabele, aşa cum este descrisă anterior.
3.3.2.2 Limbaje de interogare bazate pe SQL
Limbajele de interogare bazate pe SQL folosesc fraze SELECT modificate, iar
rezultatele sunt transformate în XML. Există câteva limbaje particulare de acest tip şi cel mai
simplu dintre acestea foloseşte fraze SQL imbricate (nested), care sunt transformate direct în
XML imbricat (nested) conform cu maparea relaţional-obiectuală. Un alt limbaj de acest tip
Pagina 33 din 97
Vizitati www.tocilar.ro ! Arhiva online cu diplome, cursuri si referate postate de utilizatori.
foloseşte obiecte SQL 3, de asemenea transformate direct în XML. Un alt limbaj foloseşte
fraze OUTER UNION şi marcaje speciale pentru a determina cum sunt transformate
rezultatele în XML.
În plus faţa de limbajele particulare, un număr de companii s-au reunit în 2000 pentru
a standardiza extensiile XML la SQL. Rezultatele lor fac parte acum din specificaţia ISO
SQL şi este cunoscută ca SQL/XML. SQL/XML introduce un tip de date XML şi adaugă un
număr de funcţii la SQL, aşa că este posibilă construirea elementelor XML şi a atributelor din
date relaţionale.
De exemplu, următoarea interogare:
SELECT Orders.SONumber,
XMLELEMENT(NAME "Order",
XMLATTRIBUTES(Orders.SONumber AS SONumber),
XMLELEMENT(NAME "Date", Orders.Date),
XMLELEMENT(NAME "Customer", Orders.Customer)) AS xmldocument FROM
Orders
construieşte un set de rezultate cu două coloane. Prima coloană conţine numărul
ordinului de vânzări şi a doua coloană conţine un document XML. Există un document XML
pe fiecare linie, construit din datele din linia corespunzătoare în tabelul de comenzi. De
exemplu documentul pentru linia pentru ordinul de vânzare 123 ar putea fi:
<Ordin NumarOV="123">
<Data>04/29/07</Data>
<Client>Gallagher Industries</Client>
</Ordin>
3.3.2.3 Limbaje de interogare XML
Spre deosebire de limbajele de interogare bazate pe şabloane sau bazate pe SQL, care
pot fi folosite numai cu baze de date relaţionale, limbajele de interogare XML pot fi folosite
pentru orice document XML. Pentru a folosi acest tip de limbaje cu baze de date relaţionale,
datele din baza de date trebuie să fie modelate ca XML.
Cu XQuery, poate fi folosită fie maparea bazată pe tabele fie maparea obiectual
relaţională. Dacă este folosită o mapare bazată pe tabele, fiecare tabelă este tratată ca un
document separat şi în fiecare interogare sunt specificate uniri între tabele, ca în SQL. Dacă
este folosită o mapare obiectual-relaţională atunci ierarhiile de tabele sunt tratate ca un singur
document şi sunt specificate uniri în mapare. Se preconizează că mapările bazate pe tabele
Pagina 34 din 97
Vizitati www.tocilar.ro ! Arhiva online cu diplome, cursuri si referate postate de utilizatori.
vor fi utilizate în majoritatea implementărilor, în detrimentul bazelor de date relaţionale,
deoarece se consideră că sunt mai uşor de implementat şi mai bine cunoscute de utilizatorii
SQL.
Cu XPath, o mapare obiectual-relaţională trebuie să fie folosită pentru a executa
interogări peste mai multe tabele. Aceasta se întâmplă deoarece XPath nu suportă unirile între
documente. Astfel, dacă ar fi folosită o mapare bazată pe tabele, ar fi posibilă interogarea
unei singure tabele la un moment dat.
3.3.3 Stocarea datelor în baze de date native XML
De asemenea este posibilă stocarea datelor în documente XML într-o bază de date
nativă XML. Acest lucru se face din mai multe motive. Primul ar fi acela când datele sunt
semistructurate, adică acestea au o structură regulată, dar acea structură variază destul încât
maparea ei la o bază de date relaţională duce fie la un număr mare de coloane cu valori nule
(care ocupă spaţiu inutil), fie la un număr mare de tabele (care este ineficient). Deşi datele
semistructurate pot fi stocate în baze de date ierarhizate orientate-obiect, se poate alege
stocarea lor într-o bază de date nativă XML sub forma unui document XML.
Al doilea motiv pentru stocarea datelor într-o bază de date nativă XML este viteza de
recuperare a datelor. În funcţie de cum sunt stocate datele în baza de date nativă XML, ar
putea fi posibilă recuperarea datelor mult mai repede decât într-o bază de date relaţională.
Acest lucru se poate întâmpla deoarece unele strategii de stocare folosite de către bazele de
date native XML reţin fizic documente întregi sau folosesc pointeri fizici (şi nu logici) între
părţile documentelor. Acestea permit ca documentele să fie recuperate fie fără uniri fie
folosind uniri fizice, ambele fiind mai rapide decât unirile logice folosite în bazele de date
relaţionale.
De exemplu se consideră ordinul de vânzare prezentat mai sus. Într-o bază de date
relaţională, acesta ar fi stocat în patru tabele – OrdineVânzări, Itemi, Clienţi, şi Parte – şi
recuperarea documentului ar necesita uniri între aceste tabele. Într-o bază de date nativă
XML, întreg documentul ar putea fi stocat într-o singură locaţie pe disc, aşa că recuperarea
lui sau a unui fragment din el necesită o singură căutare indexată şi o singură citire pentru
recuperarea datelor. O bază de date relaţională necesită patru căutări indexate şi cel puţin
patru citiri pentru a recupera datele.
Dezavantajul în acest caz este acela că viteza de recuperare este mare numai atunci
când datele din comandă sunt stocate pe disc. Dacă se doreşte recuperarea altor date, cum ar
fi o listă a clienţilor şi ordinele de vânzare ale lor, atunci performanta va fi mai slabă decât
într-o bază de date relaţională. Astfel, stocarea datelor într-o bază de date nativă XML se
Pagina 35 din 97
Vizitati www.tocilar.ro ! Arhiva online cu diplome, cursuri si referate postate de utilizatori.
recomandă din motive de performanţa atunci când predomină o singură vedere asupra
datelor.
Al treilea motiv pentru stocarea datelor într-o bază de date nativă XML este
exploatarea capacităţilor specifice XML, cum ar fi executarea interogărilor XML. Deoarece
relativ puţine aplicaţii centrate pe date au nevoie de acestea şi bazele de date relaţionale
implementează limbaje de interogare XML, acest motiv nu este foarte important.
O problemă cu stocarea datelor într-o bază de date nativă XML este că majoritatea
acestor baze de date pot returna datele numai ca XML. (Puţine baze de date suportă legarea
elementelor sau atributelor de variabilele dintr-o aplicaţie.) Dacă o aplicaţie are nevoie de
date într-un alt format (ceea ce este posibil), aceasta trebuie să analizeze XML-ul înainte de a
folosi datele. Acesta este un dezavantaj pentru aplicaţiile locale care folosesc o bază de date
nativă XML în locul unei baze de date relaţionale.
3.3.4 Tipuri de date, valori nule, seturi de caractere
Această secţiune se ocupă de anumite probleme legate de stocarea datelor din
documente XML în baze de date tradiţionale. Problemele legate de tipurile de date şi datele
binare apar şi în cazul stocării datelor în baze de date native XML. În general utilizatorul nu
poate alege modalitatea în care sotf-ul care transferă datele rezolvă aceste probleme, dar
atunci când se alege un anumit soft trebuie ţinut cont de faptul că aceste probleme există.
3.3.4.1 Tipuri de date
XML nu suportă prea multe tipuri de date. Cu excepţia entităţilor neanalizate, toate
datele dintr-un document XML sunt text, chiar dacă reprezintă alt tip de date, cum ar fi datele
calendaristice sau integer. În general soft-ul de transfer date va transforma textul (din
documentul XML) în alte tipuri de date (în baza de date) şi invers.
Softul determină ce conversii sunt necesare şi există două metode pentru efectuarea
acestora. Prima metodă constă în determinarea de către software a tipurilor de date din
schema bazei de date, deoarece aceasta este accesibilă la rulare. (Schema XML nu este
neapărat accesibilă la rulare sau s-ar putea sa nu existe.) În a doua metodă utilizatorul
specifică tipul de date. Acesta poate fi scris de către utilizator sau generat automat dintr-o
schemă a unei baze de date sau dintr-o schemă XML. Atunci când sunt generate automat,
tipurile de date pot fi recuperate din schemele bazelor de date şi din anumite tipuri de scheme
XML.
Pagina 36 din 97
Vizitati www.tocilar.ro ! Arhiva online cu diplome, cursuri si referate postate de utilizatori.
Formatele de text recunoscute în momentul conversiilor pot constitui o problemă
atunci când se transferă date din XML, la fel şi formatele care se pot crea atunci când se
transferă date către XML. În cele mai multe cazuri, numărul de formate de text care sunt
suportate de un tip de dată este limitat la unul anume sau la cele suportate de driverul JDBC.
Datele pot cauza multe probleme pentru că gama de formate posibile este foarte mare, iar
numerele cu diferitele lor formate internaţionale pot cauza de asemenea probleme.
3.3.4.2 Date binare
Datele binare se pot stoca în documente XML în trei feluri: codificare Base64 (o
codificare MIME care mapează datele binare pe un subset al US-ASCII [0-9, a-z, A-Z,+,/]),
codificarea hexazecimală (fiecare octet binar este codificat cu două caractere reprezentând
cifre hexazecimale [0-9,a-f,A-F]), şi entităţi neanalizate (datele binare sunt stocate într-o
entitate fizică separată de restul documentului XML).
Cea mai mare problemă cu datele binare este că multe dintre produsele care transferă
date nu suportă acest tip de date. O problemă secundară apare dacă sunt folosite entităţi
neanalizate şi constă în faptul că majoritatea produselor nu stochează notaţii şi declaraţii de
entităţi. Astfel, notaţia asociată cu o anumită entitate va fi pierdută atunci când datele sunt
transferate dintr-un document XML într-o bază de date.
3.3.4.3 Date vide
În domeniul bazelor de date, date vide sunt numite datele care nu există. Acestea sunt
foarte diferite de valoarea 0 (pentru numere), sau lungimea zero (pentru un string). De
exemplu, se ia în considerare o colecţie de date de la o staţie meteo. Dacă termometrul nu
funcţionează, în baza de date este stocată o valoare nulă şi nu valoarea zero, care ar însemna
cu totul altceva.
XML suportă de asemenea conceptul de date vide prin tipuri de elemente şi atribute
opţionale. Dacă valoarea unui tip sau atribut opţional este nulă acesta nu este inclus în
document. În cazul bazelor de date, atributele care conţin şiruri de caractere cu lungimea zero
sau elemente nule nu sunt vide, valoarea lor este un şir cu lungimea zero.
La maparea structurii unui document XML la baza de date şi invers, tipurile de date şi
atributele opţionale sunt mapate ca şi coloane vide. Dacă nu se procedează în acest mod s-ar
putea inserarea o eroare (atunci când se transferă date în baza de date), sau la un document
invalid (atunci când se transferă date din baza de date).
Pagina 37 din 97
Vizitati www.tocilar.ro ! Arhiva online cu diplome, cursuri si referate postate de utilizatori.
3.3.4.4 Seturi de caractere
Un document XML poate conţine orice caracter Unicode cu excepţia unor caractere
de control. Din nefericire, multe baze de date oferă suport limitat sau nu oferă suport deloc
pentru Unicode şi necesită o configuraţie specială pentru caracterele non-ASCII.
3.3.4.5 Instrucţiuni de procesare şi comentarii
Instrucţiunile de procesare şi comentariile nu fac parte din datele dintr-un document
XML şi majoritatea soft-urilor de transfer de date nu le pot manipula. Totuşi ele pot apărea
aproape oriunde într-un document XML şi de aceea nu se integrează uşor în mapările bazate
pe tabele şi cele obiectual relaţionale. O soluţie total ineficientă într-o bază de date relaţională
este adăugarea unor tabele pentru instrucţiuni de procesare şi comentarii, adăugarea de chei
străine la aceste tabele pentru toate celelalte tabele, şi verificarea acestor tabele de fiecare
data când se procesează o altă tabelă. Astfel majoritatea soft-urilor de transfer de date le
înlătură.
3.3.4.6 Stocarea marcajelor
În anumite situaţii este indicată stocarea elementelor cu conţinut mixt în baza de date
fără a se efectua analiza completă. Când este realizat acest lucru, marcajul este realizat cu
caractere de marcare. Totuşi apare o problemă la stocarea caracterelor de marcare care nu
sunt folosite pentru marcaj. În fişierul XML, acestea sunt stocate folosind entitatile lt, gt,
amp, quot, şi apos. Acest lucru poate fi făcut şi în baza de date. De exemplu următoarea
descriere:
<descriere>
<b>Exemplu confuz:</b> <foo/>
</descriere>
poate fi stocată în baza de date ca:
<b>Exemplu confuz:</b> <foo/>
Totuşi apare o problemă, limbajele de interogare non-XML, cum ar fi SQL, nu caută
în coloane marcaje sau folosirea de entităţi şi le interpretează ca atare. Astfel, dacă se caută
şirul „<foo/>” cu SQL, de fapt trebuie căutat şirul „<foo/>”.
Pagina 38 din 97
Vizitati www.tocilar.ro ! Arhiva online cu diplome, cursuri si referate postate de utilizatori.
Pe de altă parte, dacă referinţele la entităţi sunt extinse, software-ul de transfer de date
nu poate distinge între marcaj şi folosirea entităţilor. De exemplu, dacă descrierea de mai sus
este stocată în baza de date în forma următoare, soft-ul nu poate spune dacă <b>,</b>, şi
<foo/> sunt marcaje sau text:
<b>Exemplu confuz:</b> <foo/>
Soluţia pe termen lung la această problemă sunt bazele de date care recunosc XML, în
care marcajul efectiv e tratat diferit de elementele care doar par a fi marcaj. Dar, probabil vor
fi întotdeauna probleme atunci când aplicaţii non-XML lucrează cu XML.
3.3.5 Generarea schemelor XML din scheme relaţionale şi invers
O întrebare care apare frecvent la transferul datelor între documente XML şi baze de
date este cum se generează scheme XML din scheme ale bazelor de date şi invers. Înainte de
a explica cum se face acest lucru, este bine de reţinut faptul că aceasta este o operaţie design-
time. Motivul pentru acest lucru este că majoritatea aplicaţiilor centrate pe date, şi cele mai
multe aplicaţii pe verticală, lucrează cu un set cunoscut de scheme XML şi scheme de baze
de date. Astfel ele nu trebuie să genereze scheme în momentul rulării. În plus procedurile
pentru generarea schemelor nu sunt perfecte. Aplicaţiile care trebuie să reţină documente
XML aleatoare într-o bază de date ar trebui să folosească o bază de date nativă XML în loc să
genereze scheme la rulare.
Cea mai uşoară cale de a genera scheme relaţionale din scheme XML şi invers este de
a codifica o cale prin maparea obiectual relaţională, care are un număr de trăsături opţionale.
O schemă relaţională se generează dintr-o schema XML astfel:
Pentru fiecare tip complex de elemente trebuie creată o tabelă şi o coloană cheie
primară.
Pentru fiecare tip de elemente cu conţinut mixt, trebuie creată o tabelă separată în care
se va stoca PCDATA, legată de tabela părinte prin intermediul cheii primare din tabela
părinte.
Pentru fiecare atribut cu o singură valoare a acelui tip de element, şi pentru fiecare
element descendent simplu care apare o singură dată trebuie creată o coloană în acel tabel.
Dacă schema XML conţine informaţia despre tipurile de date, atunci trebuie setate tipurile de
date ale coloanelor la tipul corespunzător. Altfel, tipurile de date trebuie setate la un tip
predeterminat, cum ar fi CLOB sau VARCHAR(255). Dacă tipul elementelor descendente
sau al atributelor este opţional coloana trebuie să aibă posibilitatea de a fi setată nulă.
Pagina 39 din 97
Vizitati www.tocilar.ro ! Arhiva online cu diplome, cursuri si referate postate de utilizatori.
Pentru fiecare atribut cu mai multe valori şi pentru fiecare element descendent simplu
care apare de mai multe ori trebuie creată o tabelă separată pentru a stoca valorile, legată de
tabela părinte prin intermediul cheii primare din tabela părinte.
Pentru fiecare element descendent complex, trebuie legată tabela tipului elementului
părinte de tabela tipului elementului descendent prin intermediul cheii primare din tabela
părinte.
O schema XML se generează dintr-o schemă relaţională astfel:
Pentru fiecare tabelă se generează un tip de element
Pentru fiecare coloană care nu este cheie în acea tabelă, dar şi pentru coloanele chei
primare, se adaugă la model un atribut la tipul elementului sau un element descendent ce
conţine numai PCDATA.
La fiecare tabelă pentru care cheia primară este exportată, se adaugă un element
descendent la model şi se procesează tabela recursiv.
Pentru fiecare cheie străina, se adaugă un element descendent la model şi se
procesează tabela cu cheie străină recursiv.
Există câteva dezavantaje la aceste procedee. Multe dintre acestea se pot corecta uşor
de către programator, cum ar fi coliziuni de nume şi specificarea lungimilor şi tipurilor de
date ale coloanelor. DTD-urile nu conţin informaţii despre tipurile de date, deci nu este
posibilă cunoaşterea tipurilor de date care ar trebui folosite în baza de date. Tipurile de date şi
lungimile pot fi prevăzute dintr-o schemă XML.
O problemă mai importantă este aceea că modelul de date folosit de documentul XML
este adesea diferit şi de obicei mai complex decât cel mai eficient model pentru stocarea
datelor în baza de date. De exemplu, se consideră următorul fragment XML:
<Client>
<Nume>ABC Industries</Nume>
<Adresa>
<Strada>123 Main St.</Strada>
<Oras>Fooville</Oras>
<Stat>CA</Stat>
<Tara>USA</Tara>
<CodPostal>95041</CodPostal>
</Adresa>
</Client>
Pagina 40 din 97
Vizitati www.tocilar.ro ! Arhiva online cu diplome, cursuri si referate postate de utilizatori.
Procedura pentru generarea unei scheme relaţionale dintr-o schemă XML ar crea două
tabele: una pentru clienţi şi una pentru adrese. Totuşi în majoritatea cazurilor ar fi mai bine să
se reţină adresa în tabela de clienţi, şi nu într-o tabelă separată.
Elementul <Adresa> este un bun exemplu pentru un element wrapper. Elementele
wrapper sunt în general folosite din două motive. În primul rând, ele oferă structuri adiţionale
ceea ce face documentul mai uşor de înţeles. În al doilea rând, ele sunt de obicei folosite ca o
formă de redactare a datelor. De exemplu, elementul <Adresa> ar putea fi trimis la o rutină
care transformă toate adresele în obiecte Adresa, indiferent unde apar acestea.
Daca elementele wrapper sunt folositoare în XML, în general ele cauzează probleme
atunci când sunt mapate la baza de date dacă acestea se găsesc sub forma extra-structurilor.
Din această cauză, ele ar trebui eliminate din schema XML înaintea generării schemei
relaţionale. Din moment ce este puţin probabil că modificarea schemei XML ar trebui să fie
permanentă, acest lucru duce la o neconcordanţă între documentul existent şi documentele
presupuse de către soft-ul de transfer de date, din moment ce elementele wrapper nu sunt
incluse în mapare. Acest lucru poate fi rezolvat prin transformarea documentelor la rulare cu
XSLT: elementele wrapper sunt eliminate înaintea transferării datelor în baza de date şi sunt
inserate după transferul datelor din baza de date.
Cu toate aceste dezavantaje, procedurile de mai sus oferă în continuare un punct de
pornire folositor pentru generarea schemelor XML din scheme relaţionale şi invers, în special
în sisteme mari.
3.4 Stocarea şi recuperarea documentelor
Pentru stocarea documentelor XML există două strategii de bază: stocarea lor în
sistemul de fişiere sau ca un BLOB într-o bază de date relaţională şi acceptarea
funcţionalităţilor XML limitate, sau stocarea lor într-o bază de date nativă XML.
3.4.1 Stocarea documentelor în sistemul de fişiere
Dacă se lucrează cu un set simplu de documente, cum ar fi un set mic de
documentaţie, cea mai uşoara cale de stocare este în sistemul de fişiere. Se pot folosi
instrumente cum ar fi „grep” pentru interogarea lor, şi „sed” pentru modificarea lor. Căutările
complete de text în documentele XML sunt inexacte, pentru că ele nu pot distinge marcajul
de text şi nu pot înţelege folosirea entităţilor. Totuşi, într-un sistem mic, aceste inexactităţi ar
putea fi acceptabile. Dacă se doreşte un simplu control al tranzacţiilor, documentele pot fi
întreţinute cu o versiune de control a sistemului cum ar fi CVS sau RCS.
3.4.2 Stocarea documentelor în BLOB-uri
Pagina 41 din 97
Vizitati www.tocilar.ro ! Arhiva online cu diplome, cursuri si referate postate de utilizatori.
O opţiune puţin mai sofisticată este stocarea documentelor ca BLOB-uri într-o bază
de date relaţională. Această modalitate oferă un număr de avantaje a bazelor de date:
controlul tranzacţiilor, securitate, acces multiuser. În plus, multe baze de date au instrumente
pentru căutări de text şi pot face căutări complete de text, căutări aproximative, căutări
sinonime şi căutări fuzzy. Unele dintre aceste instrumente sunt construite pentru a recunoaşte
XML, ceea ce va elimina problemele care apar la căutările documentelor XML ca simplu
text.
Atunci când se stochează documente XML ca BLOB-uri, se pot implementa uşor
indexări simple care recunosc XML, chiar dacă baza de date nu poate indexa XML. O
modalitate de a face acest lucru este crearea a două tabele, o tabelă index şi o tabelă
document. Tabela document conţine o cheie primară şi o coloană BLOB în care este reţinut
documentul. Tabela index conţine o coloană în care se găseşte valoarea ce va fi indexată şi o
cheie străină care duce la cheia primară a tabelei document.
Atunci când documentul este stocat în baza de date, el este căutat pentru toate
instanţele elementului sau atributului care este indexat. Fiecare instanţa este stocată în tabela
index, împreuna cu cheia primara a documentului. Coloana de valori este apoi indexată, şi
permite unei aplicaţii să efectueze o căutare rapidă a unei anumite valori a unui element sau
atribut şi să recupereze documentul corespunzător.
De exemplu, se consideră un set de documente cu următorul DTD şi se doreşte
construirea unui index de autori:
<!ELEMENT Brosura (Titlu, Autor, Continut)>
<!ELEMENT Titlu (#PCDATA)>
<!ELEMENT Autor (#PCDATA)>
<!ELEMENT Continut (%Inline;)> <!-- Inline entity from XHTML -->
Acestea ar putea fi stocate în următoarele tabele:
Autori Brosuri
---------------------- ---------
Autor VARCHAR(50) BrosurID INTEGER
BrosuraID INTEGER Brosura LONGVARCHAR
Când se inserează o broşură în baza de date, aplicaţia inserează broşura în tabela
Broşuri, apoi caută elementele <Autor>, reţinând valorile acestora şi ID-ul broşurii din tabela
Autori. Aplicaţia poate recupera broşurile în funcţie de autor cu o simplă fraza SELECT. De
Pagina 42 din 97
Vizitati www.tocilar.ro ! Arhiva online cu diplome, cursuri si referate postate de utilizatori.
exemplu, pentru a recupera toate broşurile scrise de autorul „Chen”, aplicaţia execută
următoarea interogare:
SELECT Brosura
FROM Brosuri
WHERE BrosuraID IN (SELECT BrosuraID FROM Autori WHERE Autor= 'Chen')
O tabelă de indecşi mai sofisticată ar conţine patru coloane: numele atributului sau
elementului, tipul, valoarea şi ID-ul documentului. Aceasta tabelă ar putea stoca valorile
marcajelor multiple şi ar trebui indexată după nume, tip, şi valoare. Scrierea unei aplicaţii
generice SAX pentru a popula o astfel de tabelă ar fi relativ uşoară.
3.4.3 Baze de date native XML
Dacă sunt necesare mai multe caracteristici decât cele oferite de unul din sistemele de
mai sus, trebuie luată în considerare o bază de date nativă XML. Bazele de date native XML
sunt baze de date construite special pentru a stoca documente XML. Ca şi alte baze de date,
acestea suportă tranzacţii, securitate, acces multiuser, API-uri programatice, limbaje de
interogare. Singura diferenţă faţă de alte baze de date este aceea că modelul lor interior este
bazat pe XML şi nu pe altceva, ca în cazul modelului relaţional.
Bazele de date native XML sunt de obicei folosite pentru a stoca documente centrate
pe documente. Principalul motiv este că oferă suport pentru limbaje de interogare XML, care
oferă posibilitatea adresării unor întrebări de forma: „Extrage toate documente în care al
treilea paragraf de la începutul secţiunii conţine un cuvânt îngroşat”, sau oferă posibilitatea
limitării căutărilor complete de text la anumite porţiuni din document. Asemenea interogări
sunt dificil de scris într-un limbaj ca SQL. Un alt motiv este acela că bazele de date native
XML păstrează ordinea documentelor, instrucţiunile de procesare, şi comentarii, şi adesea
păstrează secţiuni CDATA, folosirea entităţilor, şi altele, pe când bazele de date ce permit
folosirea XML nu posedă aceste caracteristici.
Bazele de date native XML sunt de obicei folosite pentru a integra date. Integrarea
datelor a fost făcută cu baze de date relaţionale federate, dar acestea necesitau ca toate
resursele de date să fie mapate la modelul relaţional. Această modalitate nu funcţionează
pentru mai multe tipuri de date şi modelul de date XML oferă o flexibilitate mai mare. Bazele
de date native XML tratează modificările schemelor mai uşor decât bazele de date relaţionale
şi pot trata şi date care nu au schemă. Ambele consideraţii sunt importante pentru integrarea
datelor din surse care nu se află sub control direct.
Pagina 43 din 97
Vizitati www.tocilar.ro ! Arhiva online cu diplome, cursuri si referate postate de utilizatori.
Al treilea caz de utilizare major al bazelor de date native XML este pentru datele
semistructurate, aşa cum se găsesc în finanţe, în biologie, date care se schimbă atât de des
încât nu este posibilă definirea unor scheme definitive. Datorită faptului că bazele de date
native XML nu necesită scheme, ca bazele de date relaţionale, ele pot să trateze acest tip de
date, deşi aplicaţiile adesea necesită procesarea acestor date de către oameni.
Ultima utilizare majora a bazelor de date native XML este tratarea evoluţiei
schemelor. Chiar dacă bazele de date native XML nu oferă soluţii complete, ele oferă o
flexibilitate mai mare decât bazele de date relaţionale. De exemplu, bazele de date native
XML nu necesită ca datele existente să fie mutate într-o altă schemă, ele pot trata modificări
ale schemelor pentru care nu există nicio cale a migraţiei, şi pot stoca date chiar dacă acestea
aparţin unei versiuni necunoscute a unei scheme.
Alte utilizări ale bazelor de date native XML includ punerea la dispoziţie de cache
pentru date şi metadate pentru tranzacţii lungi, operarea cu documente mari şi date ierarhice,
şi comportarea ca un intermediar între date şi cache (mid-tier data cache).
3.4.3.1 Ce este o bază de date nativă XML?
Termenul „bază de date nativă XML” a apărut prima dată în campania de marketing a
Tamino, o bază de date nativă XML dezvoltată de Software AG. Probabil datorită succesului
acestei campanii, termenul a fost acceptat de către companiile care dezvoltau produse
similare. Dezavantajul acestui termen este că fiind un termen de marketing, nu a avut
niciodată o definiţie formală tehnică.
O definiţie posibila (dezvoltată de membrii XML:DB) este aceea că o bază de date
nativă XML are următoarele caracteristici:
Defineşte un model logic pentru un document XML – spre deosebire de datele din
acel document – şi stochează şi recuperează documente conform acelui model. Modelul
trebuie să includă minim elemente, atribute, PCDATA, şi ordinea documentelor. Exemple de
astfel de modele sunt modelul de date Xpath, XML Infoset, şi modelele conţinute de DOM şi
evenimentele din SAX 1.0.
Are ca unitate fundamentală de stocare logică un document XML, aşa cum o bază de
date relaţională are ca unitate de bază de stocare logică o linie dintr-o tabelă.
Nu este necesar un model fizic special de stocare a datelor. De exemplu, acesta poate
fi construit pe o bază de date relaţională, ierarhică, sau orientată pe obiecte, sau se poate
folosi un format de stocare particular cum ar fi fişierele comprimate indexate.
Pagina 44 din 97
Vizitati www.tocilar.ro ! Arhiva online cu diplome, cursuri si referate postate de utilizatori.
Prima parte a acestei definiţii este similară cu definiţiile altor tipuri de baze de date, şi
se concentrează pe modelul folosit de baza de date. Nu are nicio importanţă faptul că o
anumită bază de date nativă XML ar putea stoca mai multe informaţii decât conţine modelul
folosit de baza de date. De exemplu, ar putea suporta interogări bazate pe modelul Xpath, dar
să stocheze documente ca text. În acest caz, secţiunile CDATA şi folosirea entităţilor sunt
stocate în baza de date dar nu sunt incluse în model.
A doua parte a definiţiei spune că unitatea de bază de stocare într-o bază de date
nativă XML este un document XML. Deşi poate părea posibil ca o bază de date nativă XML
ar putea atribui acest rol fragmentelor de documente, bazele de date native XML sunt
populate cu documente complete.
Unitatea de bază de stocare este nivelul elementar de context în care se potriveşte un
anumit element de date, şi este echivalent cu o linie într-o bază de date relaţională. Existenţa
acestei unităţi de bază nu împiedică recuperarea unor unităţi mai mici de date, cum ar fi
fragmente de documente sau elemente individuale, şi nu exclude nici posibilitatea combinării
fragmentelor dintr-un document cu fragmente din alt document. În termeni relaţionali, acest
lucru este echivalent cu faptul că existenţa liniilor nu împiedica recuperarea individuală a
valorilor din coloane sau crearea unor linii noi din altele existente deja.
A treia parte a definiţiei spune că formatul de stocare nu este important. Acest lucru
este adevărat, şi este analog cu faptul că formatul fizic de stocare folosit de o bază de date
relaţională nu are legătură cu faptul ca baza de date este relaţională.
3.4.3.2 Arhitecturile bazelor de date native XML
Arhitecturile bazelor de date native XML se clasifică în două categorii: bazate pe text
şi bazate pe modele.
Baze de date native XML bazate pe text
O bază de date nativă XML bazată pe text stochează XML ca text. Acesta ar putea fi
un fişier într-un sistem de fişiere, un BLOB într-o bază de date relaţională, sau un format de
text particular. Nu are nicio importanţă faptul că o bază de date relaţională care a adăugat
procesarea ce recunoaşte XML a coloanelor CLOB (Character Large Object) este, de fapt, o
bază de date nativă XML având în vedere aceste abilităţi.
Toate bazele de date native XML bazate pe text au în comun indecşii, care oferă
posibilitatea motorului de interogare să sară uşor în orice punct din orice document XML.
Acest lucru dă o viteză extraordinară la recuperarea documentelor întregi sau a fragmentelor
Pagina 45 din 97
Vizitati www.tocilar.ro ! Arhiva online cu diplome, cursuri si referate postate de utilizatori.
de documente. Acest lucru se întâmpla deoarece baza de date poate executa o singură căutare
indexată, poate poziţiona capul de citire o singură dată, şi, presupunând că fragmentul necesar
este stocat continuu pe disc, poate recupera întregul document sau fragment cu o singură
citire. Spre deosebire de aceasta modalitate, reasamblarea unui document din fragmente, cum
se face în cazul bazelor de date relaţionale şi unele baze de date native XML bazate pe
modele, necesită căutări indexate multiple şi mai multe citiri ale discului.
În acest sens, o bază de date nativă XML bazată pe text este similară cu bazele de date
ierarhice, amândouă având performanţe mai bune decât bazele de date relaţionale la
recuperarea şi returnarea datelor în funcţie de o ierarhie predefinită. La fel ca bazele de date
ierarhice, bazele de date native XML bazate pe text ar putea întâmpina dificultăţi la
recuperarea şi returnarea datelor în orice altă formă, cum ar fi inversarea ierarhiei sau a unor
porţiuni ale ei. Acest lucru nu a fost dovedit încă, dar predominanţa bazelor de date
relaţionale, care folosesc pointeri logici ce permit ca toate interogările de aceeaşi
complexitate să fie executate cu aceeaşi viteză, pare să indice că aşa se va întâmpla.
Baze de date native XML bazate pe modele
A doua categorie de baze de date native XML este cea bazată pe modele. În loc să
stocheze documentul XML ca text, aceste baze de date construiesc un model obiectual intern
din document şi stochează acest model. Modalitatea reţinerii acestui model depinde de baza
de date. Unele baze de date stochează modelul într-o bază de date relaţională sau orientată
obiect. De exemplu, stocarea DOM-ului într-o bază de date relaţională ar putea duce la
obţinerea unor tabele cum ar fi Elements, Attributes, PCDATA, Entities, şi EntityReferences.
Alte baze de date folosesc un format de stocare particular optimizat pentru modelul lor.
Un exemplu de bază de date simplă nativă XML bazată pe un model construită pe o
bază de date relaţională este cea descrisa de Mark Birbeck la XML-L în decembrie 1998.
Sistemul foloseşte cinci tabele – definirea atributelor, asocierile dintre elemente/atribute,
definirea conţinutului modelului, valorile atributelor, şi valorile elementelor (PCDATA sau
pointeri la alte elemente) – şi un model care include numai elemente, atribute, text, şi ordinea
documentelor.
Bazele de date native XML bazate pe modele construite pe alte baze de date vor avea
performanţe similare cu acele baze de date la recuperarea documentelor pentru că ele se
bazează pe acele sisteme pentru a recupera datele. Totuşi, designul bazei de date, în special
pentru bazele de date native XML construite pe baze de date relaţionale poate varia destul de
mult. De exemplu, o bază de date care foloseşte o mapare obiectual-relaţională directă a
Pagina 46 din 97
Vizitati www.tocilar.ro ! Arhiva online cu diplome, cursuri si referate postate de utilizatori.
DOM-ului ar putea duce la un sistem care necesită executarea frazelor SELECT separat
pentru a recupera descendenţii fiecărui nod. Pe de altă parte, majoritatea acestor baze de date
îşi optimizează modelul de stocare şi softul de recuperare. De exemplu, Richard Edwards a
descris un sistem de stocare a DOM-ului într-o bază de date relaţională care poate recupera
orice fragment de document (inclusiv întregul document) cu o singură fraza SELECT.
Este probabil că bazele de date native XML bazate pe modele care folosesc un format
de stocare particular să aibă performanţe similare cu cele native XML bazate pe text la
recuperarea datelor în ordinea în care au fost stocate. Acest lucru se întâmplă deoarece
majoritatea acestor baze de date folosesc pointeri fizici între noduri, ceea ce ar trebui să ducă
la o performanţă similară cu recuperarea textului. (Rapiditatea unei metode sau alteia depinde
şi de formatul de ieşire. Sistemele bazate pe text sunt mai rapide la returnarea documentelor
ca text, pe când sistemele bazate pe modele sunt mai rapide la returnarea documentelor ca
arbori DOM, presupunând că modelul lor se mapează uşor la DOM.)
Ca şi bazele de date native XML bazate pe text, e probabil că şi cele bazate pe modele
să întâmpine probleme de performanţă la recuperarea şi returnarea datelor într-un formular,
altul decât cel în care sunt stocate, cum ar fi inversarea ierarhiei sau a unor porţiuni a ei. Nu
se ştie dacă aceste baze de date vor fi mai rapide sau nu decât cele bazate pe text.
3.4.3.3 Caracteristici ale bazelor de date native XML
În această secţiune sunt prezentate un număr de caracteristici ale bazelor de date
native XML.
Colecţii de documente
Multe baze de date native XML suportă noţiunea de colecţie. Acestea au un rol
similar cu cel al tabelelor în bazele de date relaţionale sau cu cel al directoarelor într-un
sistem de fişiere. De exemplu, dacă se foloseşte o bază de date nativă XML pentru stocarea
unor ordine de vânzare, ar trebui definită o colecţie de ordine de vânzare astfel încât
interogările cu privire la ordinele de vânzare să poată fi limitate la documentele din acea
colecţie.
Ca un alt exemplu, dacă se stochează manualele pentru toate produsele unei companii
într-o bază de date nativă XML, ar trebui definită o ierarhie de colecţii, o colecţie pentru
fiecare produs, şi în acea colecţie, câte o colecţie pentru fiecare capitol din fiecare manual.
Limbaje de interogare
Aproape toate bazele de date native XML suportă unul sau mai multe limbaje de
interogare. Cel mai popular este Xpath (cu extensii pentru interogări asupra mai multor
Pagina 47 din 97
Vizitati www.tocilar.ro ! Arhiva online cu diplome, cursuri si referate postate de utilizatori.
documente) şi Xquery, deşi numeroase limbaje de interogare particulare sunt suportate de
asemenea.
În viitor, majoritatea bazelor de date native XML vor suporta XQuery din W3C.
Updatări şi ştergeri
Bazele de date native XML au o varietate de strategii pentru actualizarea şi ştergerea
documentelor, de la simpla înlocuire sau ştergere a documentului existent până la modificarea
arborelui DOM, până la limbaje care specifică cum să se modifice fragmente ale unui
document. Majoritatea acestor metode sunt particulare. Totuşi, au apărut două limbaje
întrucâtva standardizate pentru actualizarea documentelor XML:
XUpdate, de la XML:DB Initiative, este un limbaj bazat pe XML. Foloseşte XPath
pentru a identifica un set de noduri, apoi specifică dacă să se insereze sau să se şteargă aceste
noduri, sau să insereze noduri noi înaintea sau după acestea. XUpdate a fost implementat în
mai multe baze de date native XML.
Un set de extensii ale XQuery a fost propus de membrii grupului W3C XQuery şi
Patrick Lehti. Variaţii asupra acestor extensii au fost implementate în mai multe baze de date
native XML şi pare probabil că acestea vor forma bazele sintaxei pentru actualizare în
XQuery.
În ciuda acestor limbaje, este probabil ca abilităţile de actualizare să rămână
fragmentate până când va fi adăugată formal o sintaxă de actualizare la XQuery.
Tranzacţii, blocări, şi concurenţă
Aproape toate bazele de date native XML suportă tranzacţii (şi probabil suportă şi
întoarceri). Totuşi, blocarea se face adesea la nivelul întregului document, şi nu la nivelul
unui nod individual, de aceea concurenţa multi-user este relativ redusă. Dacă aceasta este o
problemă depinde de aplicaţie şi ceea ce constituie un „document”. De exemplu:
Un document este un capitol al unui ghid al utilizatorului şi scriitorii editează
capitolele. Este puţin probabil ca blocarea la nivel de document să cauzeze probleme de
concurenţă, deoarece este improbabil ca doi scriitori să actualizeze acelaşi capitol în acelaşi
moment.
Un document stochează toate datele despre toate vânzările şi vânzătorii adaugă
informaţii despre noile vânzări. Este probabil ca blocarea la nivel de document să determine
probleme de concurenţă, deoarece şansele ca doi vânzători să actualizeze informaţii în acelaşi
timp este destul de mare. Din fericire, acest lucru poate fi rezolvat cel puţin parţial prin
crearea unui document de vânzare pentru fiecare client.
Pagina 48 din 97
Vizitati www.tocilar.ro ! Arhiva online cu diplome, cursuri si referate postate de utilizatori.
Un document conţine datele folosite într-un flux, cum ar fi un contract financiar.
Fiecare pas al fluxului citeşte date dintr-un computer şi adaugă datele proprii. De exemplu, un
pas ar putea face o verificare de credit şi ar adăuga un credit la document. Un alt pas ar putea
căuta balanţe în aşteptare în alte contracte ale aceluiaşi client şi ar putea adăuga totalul
balanţelor. Dacă blocarea la nivel de nod este folosită, unii dintre aceşti paşi ar putea fi
executaţi în paralel. Dacă este folosită blocarea la nivel de document, aceşti paşi ar trebui
executaţi secvenţial pentru a evita conflicte de scriere. Acest lucru ar putea aduce întârzieri
inacceptabile în aplicaţii mari.
Problema blocării la nivel de nod este implementarea acesteia. Blocarea unui nod
necesită de obicei blocarea părintelui său, ceea ce necesită blocarea părintelui acestuia, şi aşa
până la rădăcină, blocând efectiv întregul document. Pentru a vedea de ce acest lucru este
adevărat, se consideră o tranzacţie care citeşte un nod frunză. Dacă tranzacţia nu are blocări
pe strămoşii nodului frunză, o altă tranzacţie poate şterge un nod strămoş al frunzei, astfel
ştergând şi nodul frunză. Totuşi, o altă tranzacţie ar trebui să poată actualiza acele părţi ale
documentului care nu sunt pe calea directă de la rădăcină la nodul frunză.
O soluţie parţială a acestei probleme este propusă de Stijn Dekeyser În timp ce
problema blocării strămoşilor unui nod ţintă nu a fost total ocolită, aceste blocări au fost
făcute mai flexibile prin adnotarea lor cu definirea prin interogare a căii de la nodul blocat
până la nodul ţintă. Acest lucru permite altor tranzacţii să determine dacă sunt în conflict cu
alte tranzacţii. Deoarece evaluarea interogărilor pentru a obţine blocări este foarte
costisitoare, schema actuală este întrucâtva mai limitată decât a fost descrisă aici, dar acesta
este principiul de funcţionare.
În viitor, majoritatea bazelor de date native XML vor oferi probabil posibilitatea
blocării la nivel de nod.
Interfeţe de programare a aplicaţiilor (API-uri)
Majoritatea bazelor de date native XML oferă API-uri programatice. Acestea sunt de
obicei sub forma unei interfeţe asemănătoare ODBC, cu metode pentru legarea la baza de
date, explorarea metadatelor, executarea interogărilor, şi recuperarea rezultatelor. Rezultatele
sunt de obicei returnate ca un şir XML, un arbore DOM, sau un Parser SAX, sau un
XMLReader peste documentul returnat. Dacă interogările pot returna documente multiple,
atunci metodele pentru parcurgerea rezultatelor sunt de asemenea disponibile. Deşi
majoritatea bazelor de date native XML oferă API-uri particulare au fost dezvoltate două
API-uri independente (iulie 2004):
Pagina 49 din 97
Vizitati www.tocilar.ro ! Arhiva online cu diplome, cursuri si referate postate de utilizatori.
API-ul XML:DB al XML:DB.org care este independent de limbajul de programare, şi
foloseşte XPath ca limbajul său de interogare, şi este extins pentru a suporta XQuery. A fost
implementat pentru mai multe baze de date native XML şi se poate să fi fost implementat şi
pentru baze de date care nu sunt native XML.
JSR 225: XQuery API pentru Java (XQJ) este bazat pe JDBC şi foloseşte XQuery ca
limbaj de interogare. Este dezvoltat de către Java Community Process (JCP) de la Sun.
Deoarece această iniţiativa este condusă de IBM şi Oracle este probabilă răspândirea ei la
scară largă.
Majoritatea bazelor de date native XML oferă de asemenea posibilitatea executării
interogărilor şi returnarea rezultatelor prin HTTP.
Round-Tripping
O caracteristică importantă a bazelor de date native XML este că pot efectua un
„round-trip” al documentelor XML. Acest lucru înseamnă că se poate stoca un document
XML într-o bază de date nativă şi se poate recupera din baza de date acelaşi document. Acest
lucru este important pentru aplicaţiile centrate pe documente, pentru care secţiunile CDATA,
folosirea entităţilor, comentariile şi procesarea instrucţiunilor sunt o parte integrantă a
documentului. De asemenea este foarte important pentru multe aplicaţii medicale şi legale,
care sunt obligate prin lege sa păstreze copii fidele ale documentelor.
Round-tripping-ul este mai puţin important pentru aplicaţiile centrate pe date, pentru
care de obicei contează elementele, atributele, textul, şi ordinea ierarhică. Toate softurile care
transferă date între documente XML şi baze de date pot executa acest procedeu cu aceste
date. Aceleaşi operaţii pot fi aplicate şi unor ordonări similare (ordinea elementelor şi a
PCDATA în părintele lor) într-un număr limitat de cazuri care sunt importante pentru
aplicaţiile centrate pe date. Totuşi deoarece nu pot face aceste operaţii în toate cazurile, şi nici
asupra instrucţiunilor de procesare, comentariilor, şi structurilor fizice (referinţele către
entităţi, secţiuni CDATA), nu sunt potrivite pentru aplicaţii centrate pe documente.
Toate bazele de date native XML pot aplica round-tripping-ul la nivelul elementelor,
al atributelor, al PCDATA, şi al ordinii documentelor. Cât de mult se poate aplica acest
procedeu depinde de baza de date. Ca o regulă generală, bazele de date native XML bazate pe
text aplică acest procedeu pe documentele XML exact, în timp ce bazele de date native XML
bazate pe modele aplică acest procedeu asupra documentelor XML la nivelul modelului. În
cazul modelelor minimale de documente, acest procedeu se face la un nivel mai mic decât
XML-ul canonic.
Pagina 50 din 97
Vizitati www.tocilar.ro ! Arhiva online cu diplome, cursuri si referate postate de utilizatori.
Din moment ce nivelul de round-tripping depinde de fiecare aplicaţie, şi alegerea
bazei de date native XML potrivite poate varia.
Date aflate la distanţă
Unele baze de date native XML pot include date aflate la distanţă în documente
stocate în baza de date. De obicei aceste date sunt recuperate dintr-o bază de date relaţională
cu ODBC, OLE DB, sau JDBC şi sunt modelate folosind maparea bazată pe tabele sau
maparea relaţional-obiectuală. Daca aceste date sunt “live” – adică dacă actualizările
documentului din baza de date nativă XML sunt reflectate în baza de date aflată la distanţă –
depinde de baza de date nativă XML. În viitor majoritatea bazelor de date native XML vor
suporta date “live” aflate la distanţă.
Indecşi
Toate bazele de date native XML suportă indecşi ca o modalitate de a mări viteza de
interogare. Exista trei tipuri de indecşi. Indecşii valoare indexează text şi valori ale atributelor
şi sunt folosiţi pentru a rezolva interogări de forma: „Găseşte toate elementele sau atributele
ale căror valori sunt ‘Santa Cruz’.” Indecşii structurali indexează locaţia elementelor şi
atributelor şi sunt folosiţi pentru a rezolva interogări de forma: „Găseşte toate elementele
adresă.” Indecşii valoare şi structurali sunt combinaţi pentru a rezolva interogări de forma:
„Găseşte toate elementele oraşe ale căror valori sunt ‘Santa Cruz’.” Indecşii full-text
indexează semnele individuale din text şi valorile atributelor şi sunt folosiţi pentru a rezolva
interogări de forma: „Găseşte toate documentele care conţin cuvintele ’Santa Cruz’.” sau în
conjuncţie cu indecşii structurali :”Găseşte toate documentele care conţin cuvintele ‘Santa
Cruz’ într-un element adresă.”
Majoritatea bazelor de date native XML suportă atât indecşi valoare cât şi indecşi
structurali. Unele baze de date native XML suportă indecşi full-text.
Stocarea entităţilor externe
O problemă dificilă care apare la stocarea documentelor XML este tratarea entităţilor
externe. Adică, ar trebui extinse şi valorile lor stocate împreuna cu restul documentului, sau
ar trebui ca referinţele la entităţi să fie lăsate la locul lor? Această întrebare nu are răspuns
unic.
De exemplu, se consideră că un document include o entitate externă generală care
apelează un program CGI pentru prognoza meteo. Dacă documentul este folosit ca o pagina
Web care oferă prognoza meteo, ar fi o greşeală extinderea referinţei la entitate, deoarece
pagina de Web nu ar mai returna date ‘live’. Pe de altă parte, dacă documentul ar fi o parte a
Pagina 51 din 97
Vizitati www.tocilar.ro ! Arhiva online cu diplome, cursuri si referate postate de utilizatori.
unei colecţii de date despre vreme mai vechi, ar fi o greşeală să nu se extindă referinţa,
deoarece documentul ar recupera întotdeauna datele curente şi nu le-ar mai reţine pe cele
vechi.
Ca un alt exemplu, se consideră un manual al unui produs care nu conţine altceva
decât referinţe la entităţi externe care trimit la capitolele manualului. Daca unele dintre aceste
capitole ar fi folosite în alte documente, ca manualele pentru diferite modele ale aceluiaşi
produs, ar fi o greşeală extinderea acestor referinţe, pentru ca ar duce la copii multiple ale
aceloraşi capitole.
3.4.3.4 Normalizare, integritate referenţială şi scalabilitate
Pentru mulţi, în special pentru cei ce poseda cunoştinţe despre baze de date
relaţionale, bazele de date native XML ridică un număr de probleme controversate, în special
cu privire la problemele de stocare a datelor (spre deosebire de documente). Unele dintre
aceste probleme sunt dezbătute în secţiunile următoare.
Normalizarea
Normalizarea se referă la procesul de proiectare a schemei unei baze de date în care
un anumit set de date sunt reprezentate o singură dată. Normalizarea are câteva avantaje
clare, cum ar fi reducerea spaţiului necesar pe disc şi eliminarea posibilităţii apariţiei
inconsistenţelor, care se pot găsi atunci când un set de date este stocat în mai multe locuri.
Aceasta este una din pietrele de temelie a tehnologiei relaţionale şi este un punct aprins în
discuţiile despre stocarea datelor în baze de date native XML.
Normalizarea nu este o problemă pentru documente centrate pe documente. De
exemplu, se consideră o colecţie de documente ce descrie produsele unei companii. În multe
asemenea colecţii, există puţine date comune tuturor documentelor – notificări de copyright,
adresele corporaţiilor şi numere de telefon, logo-uri ale produselor – şi aceste date sunt prea
puţine relativ la total încât normalizarea acestora nu se ia în calcul. Pe de altă parte, alte seturi
de documentaţii au părţi comune importante între documente şi se merită normalizarea lor.
Ca şi în cazul bazelor de date relaţionale, normalizarea bazelor de date native XML
nu este obligatorie. De aceea este importantă proiectarea atentă a structurii documentelor
înainte de stocarea lor într-o bază de date nativă XML. Bazele de date native XML au un
avantaj faţă de bazele de date relaţionale. Din moment ce bazele de date native XML nu au
scheme, se pot stoca documente similare în baza de date cu mai multe scheme la un anumit
moment. Chiar dacă este necesară reproiectarea interogărilor şi convertirea documentelor
existente, acest lucru ar putea uşura procesul de tranziţie.
Pagina 52 din 97
Vizitati www.tocilar.ro ! Arhiva online cu diplome, cursuri si referate postate de utilizatori.
Normalizarea datelor pentru o bază de date nativă XML este aproximativ la fel ca
normalizarea unei baze de date relaţionale: documentele trebuie proiectate astfel încât datele
să nu se repete. O diferenţă între bazele de date native XML şi bazele de date relaţionale este
aceea ca XML suportă proprietăţi multi-valoare în timp ce majoritatea bazelor de date
relaţionale nu. Aceasta face posibilă normalizarea datelor într-o bază de date nativă XML
într-o manieră care nu este posibilă într-o bază de date relaţională.
De exemplu, se consideră un ordin de vânzare. Acesta constă în informaţiile din antet,
cum ar fi numărul ordinului, data, numărul clientului, şi unul sau mai mulţi itemi care conţin
un număr curent, cantitatea, şi preţul total. Într-o bază de date relaţională, informaţia din antet
trebuie stocată într-o tabelă separată faţă de itemi, deoarece sunt mai multe linii în fiecare
antet. Într-o bază de date nativă XML, această informaţie poate fi stocată într-un singur
document fără redundanţe, deoarece natura ierarhică a XML permite unui element părinte să
aibă mai mulţi descendenţi.
Din nefericire, normalizarea pe cazuri concrete nu este atât de simplă. De exemplu, ce
se întâmplă atunci când se doreşte ca ordinul de vânzare să conţină informaţii despre client,
cum ar fi nume de contact şi adresa de expediere şi facturare? Exista două variante. Prima, se
pot duplica informaţiile despre client în fiecare ordin de vânzare pentru acel client, ducând la
date redundante şi toate problemele care apar cu acestea. A doua variantă, se pot stoca
informaţiile despre client separat şi fie adăugat un XLink în documentul ordinului de vânzare
către documentul clientului, fie unite cele două documente atunci când datele sunt interogate.
Acest lucru presupune că fie legăturile XLink sunt suportate (în majoritatea cazurilor nu
sunt), fie limbajul de interogare suportă uniri (de asemenea nu se întâmplă întotdeauna).
În practică nu există soluţii clare. Datele relaţionale din lumea reală sunt adesea
nenormalizate din motive de performanţă. Dacă se stochează documente centrate pe
documente şi acestea se pot normaliza până la un anumit grad – cum ar fi stocarea capitolelor
sau procedurilor ca documente separate şi unirea lor pentru a crea documente end-user –
atunci o bază de date nativă XML este o soluţie bună, în special pentru că va oferi
caracteristici precum limbaje de interogare XML care nu se găsesc în alte baze de date. Dacă
se stochează documente centrate pe date şi o bază de date nativă XML îmbunătăţeşte
performanţa aplicaţiei sau oferă stocarea datelor semi-structurate, facilităţi care nu se găsesc
în alte baze de date atunci această bază de date ar trebui folosită.
Integritatea referenţială
Pagina 53 din 97
Vizitati www.tocilar.ro ! Arhiva online cu diplome, cursuri si referate postate de utilizatori.
Integritatea referenţială este strâns legată de normalizare. Aceasta se referă la
validitatea pointerilor la datele legate şi sunt o parte necesară a menţinerii consistenţei bazei
de date. De exemplu nu este de niciun folos un număr de client dintr-un ordin de vânzare care
nu are o înregistrare a clientului corespondentă. Departamentul de expediere nu va şti unde să
trimită marfa şi departamentul de contabilitate nu va şti unde să trimită factura.
Într-o bază de date relaţională, integritatea referenţială înseamnă asigurarea că se face
legătura corectă între cheile străine şi cheile primare – adică, verificarea că linia cheii primare
ce corespunde oricărei chei străine există. Într-o bază de date nativă XML, integritatea
referenţială înseamnă asigurarea că pointerii în documentul XML trimit la documente valide
sau fragmente de documente.
Pointerii din documentele XML sunt de mai multe feluri: atribute ID/IDREF, câmpuri
key/keyref (aşa cum sunt definite în scheme XML), legături XLink, şi diferite mecanisme
particulare. Cele din urma includ elemente şi atribute de referire într-un limbaj specific, cum
ar fi atributul ‘ref’ al elementului <element> în schemele XML, şi mecanisme de legături
specifice bazelor de date. În timp ce elementele şi atributele de referire într-un limbaj specific
sunt destul de des întâlnite, mecanismele de legături specifice bazelor de date sunt mai rare.
Integritatea referenţială într-o bază de date nativă XML poate fi împărţită în două
categorii: integritatea pointerilor interni (pointeri dintr-un document) şi integritatea
pointerilor externi (pointeri dintre documente). Integritatea referenţială a pointerilor interni
care folosesc mecanisme non-standard nu este forţată, deoarece bazele de date native XML
nu pot identifica aceşti pointeri. Integritatea referenţială a pointerilor interni care folosesc un
mecanism standard, cum ar fi ID/IDREF sau key/keyref, este cel puţin parţial suportată prin
validare.
Motivul pentru care acest suport este parţial este că majoritatea bazelor de date native
XML execută validări numai când un document este introdus în baza de date. Astfel, dacă
sunt efectuate actualizări la nivel de document – prin ştergeri şi apoi înlocuiri a unui
document – validarea este suficientă pentru a asigura integritatea pointerilor interni. Dar dacă
sunt efectuate actualizări la nivel de nod – inserări, modificări şi ştergeri de noduri
individuale – atunci baza de date trebuie să mai facă operaţii în plus, cum ar fi validarea
tuturor modificărilor, pentru a garanta integritatea referenţială a pointerilor interni.
Integritatea refenţială a pointerilor externi nu este suportată, nici de puţinele baze de
date care suportă pointeri externi. Dacă un pointer extern trimite la o resursă stocată în altă
parte în baza de date, nu există motiv pentru a nu se impune integritatea pointerului. Totuşi,
dacă un pointer trimite la o resursă din afara bazei de date nu este obligatorie impunerea
Pagina 54 din 97
Vizitati www.tocilar.ro ! Arhiva online cu diplome, cursuri si referate postate de utilizatori.
integrităţii. De exemplu, se presupune că un document conţine o legătură XLink care trimite
la un document pe un site web extern. Baza de date nu are nici un control asupra existenţei
documentului extern şi astfel nu se poate impune integritatea legăturii XLink.
În viitor, majoritatea bazelor de date native XML probabil vor suporta integritatea
referenţială a pointerilor interni care folosesc mecanisme standard. Multe baze de date native
XML vor suporta anumite tipuri de pointeri externi, ca şi pointerii externi care trimit la
resurse stocate în aceeaşi bază de date. Deocamdată în majoritatea cazurilor aplicaţiile impun
integritatea pointerilor atât interni cât şi externi.
Scalabilitate
Ca şi bazele de date ierarhice şi relaţionale, bazele de date native XML folosesc
indecşi pentru a localiza date. Acest lucru înseamnă că localizarea documentelor şi a
fragmentelor de documente este legată de dimensiunile indecşilor, nu de dimensiunile
documentelor sau de numărul de documente, şi de faptul că aceste baze de date pot localiza
începutul unui document sau fragment la fel de repede ca şi alte baze de date care folosesc
aceeaşi tehnologie de indexare. Astfel, bazele de date native XML vor scala la fel de bine ca
şi alte baze de date.
Ca şi bazele de date ierarhice, dar spre deosebire de cele relaţionale, multe baze de
date native XML leagă fizic datele înrudite. În special, bazele de date native XML bazate pe
text grupează fizic datele înrudite şi bazele de date native XML bazate pe modele care
folosesc sisteme de stocare particulare folosesc adesea pointeri pentru a grupa date înrudite.
Bazele de date native XML bazate pe modele construite pe baze de date relaţionale folosesc
ca şi acestea legături logice.
Deoarece legăturile fizice sunt mai rapide decât cele logice, bazele de date native
XML, ca şi cele ierarhice, pot recupera date mai repede decât bazele de date relaţionale.
Astfel, ele ar trebui să scaleze bine din punctul de vedere al recuperării datelor. De fapt, ar
trebui să se comporte mai bine decât bazele de date relaţionale, deoarece scalabilitatea este
legată de o singură căutare indexată iniţială, spre deosebire de multiplele căutări necesare în
cazul bazelor de date relaţionale.
Din păcate, această scalabilitate este limitată. Ca şi bazele de date ierarhice, legăturile
fizice în bazele de date native XML se aplică numai asupra anumitor ierarhii. Recuperarea
datelor în ierarhia în care sunt stocate este foarte rapidă, dar recuperarea aceloraşi date într-o
ierarhie diferită este mai înceată. De exemplu, se presupune că informaţiile despre clienţi sunt
stocate în fiecare ordin de vânzare. Recuperarea acestor ordine de vânzare va fi foarte rapidă,
deoarece acesta este ordinul în care datele sunt stocate. Recuperarea unei alte vederi a datelor,
Pagina 55 din 97
Vizitati www.tocilar.ro ! Arhiva online cu diplome, cursuri si referate postate de utilizatori.
cum ar fi o listă cu ordinele de vânzare pentru un anumit client, va fi mult mai înceată,
deoarece legăturile fizice nu se mai folosesc.
Pentru a rezolva parţial această problema, bazele de date native XML folosesc foarte
mulţi indecşi, adesea indexând toate elementele şi atributele. Dacă acest lucru ajută la
scăderea timpului de recuperare a datelor, totuşi creşte timpul de actualizare, pentru că
întreţinerea acestor indecşi poate fi costisitoare. Aceasta nu este o problemă în medii read-
only, dar poate cauza probleme în medii în care se folosesc multe tranzacţii.
În cele din urmă, bazele de date native XML scalează mai slab decât cele relaţionale
în căutarea datelor neindexate. Ambele tipuri de baze de date trebuie să caute secvenţial
datele în acest caz, dar în cazul bazelor de date native XML este mai greu datorită
normalizării mai puţin complete. De exemplu, se caută toate ordinele de vânzări cu o anumită
dată şi datele nu sunt indexate. Într-o bază de date relaţională, aceasta înseamnă citirea tuturor
valorilor din coloana OrderDate. Într-o bază de date nativă XML, acest lucru înseamnă citirea
fiecărui ordin de vânzare în întregime şi căutarea elementului <OrderDate>. Nu numai că se
citeşte conţinutul fiecărui element <OrderDate>, dar se citeşte şi conţinutul tuturor celorlalte
elemente. În bazele de date native bazate pe text, textul trebuie analizat şi convertit la
formatul dată calendaristică înainte de a putea fi comparat cu data căutată.
Aici se încheie descrierea bazelor de date native XML. Următoarele doua secţiuni
tratează două tipuri specializate de baze de date native XML: DOM-uri persistente şi sisteme
de management ale conţinuturilor.
3.4.4 DOM-uri persistente (PDOM-uri)
Un DOM persistent sau PDOM este un tip specializat de bază de date nativă XML
care implementează DOM-ul peste un tip de stocare persistentă. Spre deosebire de
majoritatea bazelor de date native XML, care pot returna documente ca arbori DOM, arborele
DOM returnat de un PDOM este activ (live). Adică, modificările făcute arborelui DOM sunt
reflectate direct în baza de date. Dacă modificările sunt făcute imediat sau în urma apelării
unei metode ‘commit’ depinde de baza de date. În majoritatea bazelor de date native XML,
arborele DOM returnat aplicaţiei este o copie, şi modificările sunt făcute în baza de date prin
intermediul unui limbaj de actualizare XML sau prin înlocuirea întregului document.
Deoarece arborii PDOM sunt activi, baza de date este de obicei locală, adică este în
acelaşi spaţiu de procesări ca şi aplicaţia, sau cel puţin pe aceeaşi maşină, deşi acest lucru nu
este neapărat necesar. Acest lucru este făcut pentru eficienţă, deoarece un PDOM peste o
bază de date aflată la distanţă ar necesita cereri frecvente la un server aflat la depărtare.
Pagina 56 din 97
Vizitati www.tocilar.ro ! Arhiva online cu diplome, cursuri si referate postate de utilizatori.
PDOM-urile au acelaşi rol pentru aplicaţiile DOM ca şi bazele de date orientate obiect
pentru aplicaţiile orientate obiect: ele oferă stocare persistentă pentru datele aplicaţiei, şi
servesc şi drept memorie virtuala pentru aplicaţie. Al doilea rol este foarte important pentru
aplicaţiile DOM care operează cu documente mari, deoarece arborii DOM pot uşor să
depăşească documentele XML ca mărime.
3.4.5 Sisteme de management ale conţinuturilor
Sistemele de management ale conţinuturilor sunt un alt tip specializat de baze de date
native XML. Acestea sunt proiectate pentru operarea cu documente scrise de oameni, cum ar
fi manualele de utilizare, şi sunt construite peste baze de date native XML. Baza de date este
în general ascunsă de utilizator în spatele unui ”front end” care oferă caracteristici precum:
Control al versiunilor şi al accesului
Motoare de căutare
Editoare XML/SGML
Motoare de publicare pe hârtie, CD sau pe Web
Separarea conţinuturilor şi a stilurilor
Extinderea în scripturi şi programare
Integrarea datelor din baza de date
Termenul de sistem de management al conţinuturilor spre deosebire de sistem de
management al documentelor reflectă faptul că asemenea sisteme permit în general
împărţirea documentelor în fragmente cu conţinut discret, cum ar fi exemple, proceduri,
capitole, dar şi metadate cum ar fi numele autorilor, datele reviziilor, şi numerele
documentelor, decât să opereze cu fiecare document ca un întreg. Nu numai că astfel se
simplifică coordonarea lucrului mai multor scriitori la acelaşi document, dar permite şi
asamblarea unor documente noi din componente care există deja.
CAPITOLUL IV
CONSTRUIREA DOCUMENTELOR XML
4.1 Sintaxa XML
XML este format de fapt din două metalimbaje, ambele descrise în acelaşi document.
Primul este un set de reguli pentru realizarea de documente XML construite corect, în timp ce
al doilea este un set de reguli pentru realizarea unei definiţii a tipului documentului XML, sau
DTD (Document Type Definition), care permite ca structura documentului XML să se
supună unor constrângeri şi să fie validată faţă de acele constrângeri. Distincţia dintre aceste
Pagina 57 din 97
Vizitati www.tocilar.ro ! Arhiva online cu diplome, cursuri si referate postate de utilizatori.
două limbaje este deseori neclară, deoarece un document XML complet presupune măcar
existenţa opţională a unui DTD, indiferent dacă acesta este de fapt prezent sau nu. Pentru a
complica şi mai mult lucrurile, un DTD poate fi compus din două părţi, o submulţime internă
şi o submulţime externă. Aceasta parte studiază documentul XML fără a insista prea mult
asupra DTD-ului, deoarece un document XML poate fi creat şi fără a face referiri la un DTD.
Din motive de performanţă, multe documente XML vor fi utilizate fără a le valida în raport
cu DTD-ul, chiar dacă DTD-ul este disponibil. În cazul conexiunilor lente, citirea dintr-un
DTD situat pe un alt sistem poate fi foarte înceată, iar datorită faptului că un DTD poate
conţine referinţe la alte documente, rezolvarea tuturor referinţelor externe poate dura exagerat
de mult chiar şi în cazul conexiunilor de mare viteză. Utilizatorii sunt obişnuiţi ca
documentele HTML să fie încărcate incremental, deci pot citi înainte ca documentul să fie
încărcat în totalitate, dar analizatoarele XML de validare nu permit afişarea documentului
decât în cazul în care acesta este valid, deci documentul va apărea pe ecranul utilizatorului
numai în momentul în care este încărcat în totalitate. Acest lucru poate fi supărător. Totuşi,
fiecare document este creat având în minte un DTD, indiferent dacă DTD-ul este explicit sau
nu. Chiar şi la crearea documentelor fără un DTD, trebuie să avut în vedere un fel de DTD
empiric pe măsură ce este creat documentul, deoarece un DTD descrie o structură de date.
4.2 Descrierea de vocabulare noi cu XML
XML are o natură duală: un metalimbaj care permite descrierea de noi structuri de
documente şi vocabulare şi un limbaj utilizat ca să exprime acea structură şi acel vocabular în
cazul unui document. Există o diferenţă clară între un document XML, care poate avea sau nu
asociat un DTD exprimat în metalimbajul XML, şi un DTD XML. Ele utilizează sintaxe
complet diferite pentru a descrie un document XML, unul prin exemplu iar celălalt
prescriptiv.
Definiţiile tipului documentului XML (DTD-urile) descriu instanţe ale limbajului
XML, numite uneori vocabulare XML. Dcumentele XML sunt create utilizând acele limbaje.
Din păcate, această diferenţă se pierde uneori în exprimarea neoficială, iar vocabularele XML
particulare şi DTD-urile asociate sunt descrise inexact ca ” XML”. Utilizatorul unui limbaj
sau vocabular XML poate că nu va vedea niciodată sau poate că nici nu îi pasă de DTD-ul
utilizat pentru a descrie aplicaţia sa, la fel cum miilor de persoane care lucrează în design
Web utilizând HTML nu le pasă de W3C HTML 4.0 SGML DTD utilizat în descrierea
HTML. De fapt, un DTD poate să nu existe. Nu are o importanţă chiar aşa mare la nivelul
aplicaţiei.
4.3 Avantajele definiţiei tipurilor documentului
Pagina 58 din 97
Vizitati www.tocilar.ro ! Arhiva online cu diplome, cursuri si referate postate de utilizatori.
Cu toate că DTD-urile sunt opţionale deoarece un procesor XML poate conduce un
DTD convenabil dintr-o instanţă a XML, existenţa unui DTD oferă multe avantaje:
• Un DTD descrie organizarea unui document într-un mod care poate fi distribuit cu
uşurinţă.
• Un DTD permite unui proiectant să creeze o transformare robustă dintr-un anumit
tip de document XML într-un alt format, pentru afişare sau transfer. Deoarece cu un DTD se
cunoaşte absolut orice despre documente, se vor putea trata structuri care este posibil să nu
existe într-un anumit exemplu, dar sunt permise de tipul documentului, chiar dacă nu au fost
întâlnite niciodată până acum.
• Un DTD permite unui analizor care validează să determine dacă un anumit
document este sau nu creat în conformitate cu regulile stabilite de autorul specificaţiei. Acest
lucru este extrem de important pentru EDI (Electronic Data Interchange – schimb electronic
de date) şi alte aplicaţii în care documentele vor fi partajate şi utilizate şi de alte procese.
• Fără un DTD, un mediu de creare XML nu poate oferi sugestii despre elementele
care sunt necesare sau opţionale într-un anumit loc şi despre atributele pe care le poate
conţine un anumit element. Meniurile contextuale sau sugestiile pot fi de mare ajutor în
accelerarea dezvoltării documentelor şi în prevenirea erorilor.
• Fără un DTD, autorul unui manual de creaţie sau al unui document de stil nu are de
unde să ştie cum ar trebui construit documentul definit. Un manual de creaţie este o întrupare
a informaţiei exprimate într-un DTD, cu toate că nu este un DTD în sine.
• Specificarea DTD-ului utilizat într-un document identifică versiunea standardului
folosit la crearea sa. Când documentele se dezvoltă în funcţionalitate şi sintaxă, acesta poate
fi un indiciu într-o situaţie nouă.
4.4 Combaterea dezavantajelor definiţiei tipurilor documentului
Cu toate avantajele lor, DTD-urile ridică şi probleme. Ele utilizează o sintaxă diferită
de XML, deci construirea unui DTD necesită un alt set de abilităţi. În plus ca orice descriere
tehnică, implicarea în proiectarea unui DTD neavând în vedere aspectul structurii datelor în
document poate duce la împotmolirea în detalii atunci când este nevoie de atenţie la structura
generală. Multe persoane proiectează documente XML utilizând vocabularul XML destinat şi
apoi utilizează un instrument de extragere automată de DTD-uri pentru a genera un DTD pe
baza documentului. După realizarea acestui lucru, DTD-ul poate fi reglat prin adăugări la
codul sursă sau prin ajustarea acestuia.
Dar DTD au şi următoarele dezavantaje:
Pagina 59 din 97
Vizitati www.tocilar.ro ! Arhiva online cu diplome, cursuri si referate postate de utilizatori.
• Cu un DTD, un agent utilizator XML care validează necesită cel puţin încă o
operaţie de citire pentru a accesa locaţia unde este disponibil DTD-ul. Cu toate că plasarea în
cache poate reduce performanţele pentru unii utilizatori din reţea, multe utilizări previzibile
ale documentelor XML vor face imposibilă utilizarea stocării în cache.
• Un DTD creşte cu mult complexitatea analizorului necesar pentru a determina dacă
un document poate fi afişat. Pentru unele dispozitive, este posibil ca acest lucru să fie
realizabil.
• Unele medii de creare care validează şi utilizează un DTD îngreunează salvarea
spaţiului de lucru la sfârşitul zilei sau restaurarea sa în ziua următoare, cu excepţia cazului în
care documentul se află într-o stare validă.
• Din punct de vedere teoretic, un DTD este capabil să continue nelimitat citiri
externe, deoarece un DTD poate conţine alte DTD-uri sau mulţimi de entităţi. Este posibil ca
pentru afişarea unor documente complexe să fie nevoie de foarte mult timp atunci când se
utilizează un analizor care validează.
Decizia utilizării unui DTD este un compromis între abilitatea de utilizare fără
restricţii, obişnuită în HTML – posibilitate de a face aproape tot ce se doreşte – şi un mediu
mult mai structurat. În multe situaţii, cum sunt cele în care se realizează documente care
trebuie să fie general disponibile şi sunt create distribuit, trebuie să se respecte strict regulile
şi este de dorit folosirea unui DTD. În alte cazuri, cum ar fi atunci când se dezvolta un tip de
document XML nou, nu este nevoie sau nu este dorită constrângerea strictă şi se poate realiza
fără un DTD, cel puţin în timpul proiectării iniţiale.
Dar după ce dezvoltarea a devenit un produs stabil, este de dorit ca proiectul să poată
fi distribuit cu uşurinţă. Chiar dacă se doreşte crearea unui manual de utilizare, un DTD este o
metodă simplă de a permite utilizatorilor să îşi testeze propriile documente pentru a se asigura
că au respectat indicaţiile pe care le-au citit în manual. În acel moment, se poate considera că
DTD-urile oferă o flexibilitate prea mare.
4.5 XML, doar un alt HTML?
XML este un limbaj cu etichete şi atribute asemănător cu HTML, dar un HTML
transformat atât de mult, încât nu mai poate fi recunoscut. XML este mult mai structurat
decât HTML. În timp ce procesoarele HTML acceptă în mod curent cod incorect şi diform şi
încearcă să îi dea sens pe ecran, XML trebuie să se oprească atunci când găseşte o eroare
fatală, care poate fi aproape orice tip de eroare. Aceasta este într-un fel o întoarcere la primele
zile ale prelucrării datelor, când orice eroare din cod era pedepsită cu un vidaj de memorie,
(core dump) lângă care se puteau petrece ore întregi în încercarea de a-l descifra.
Pagina 60 din 97
Vizitati www.tocilar.ro ! Arhiva online cu diplome, cursuri si referate postate de utilizatori.
Totuşi pe lângă acest comportament necruţător, XML este cu mult mai puternic. În
timp ce HTML se mulţumeşte cu un număr relativ mic de etichete, XML are un număr de
etichete aproape infinit, structurate în aproape orice fel se doreşte. Oricum, fundamentele au
rămas aceleaşi, XML reprezentând un pas evolutiv al HTML. Nu numai că un HTML bine
făcut este foarte aproape de XHTML – un înlocuitor al HTML care respectă XML – dar un
cod HTML 4.0 curat este destul de lizibil ca XHTML 1.0. Deoarece HTML 4.0 a fost
structurat ca o aplicaţie SGML, iar XML este o submulţime a SGML, acest lucru este logic.
Diferenţele sintactice minore dintre XHTML, un vocabular XML, şi HTML, un vocabular
SGML, pot fi ajustate automat dacă este nevoie. Autorul unui document XML oferă de obicei
un manual de creare sau codare (sau o foaie, pentru DTD-uri mici) descriind etichetele
utilizate în aplicaţia XML, atributele lor, valorile posibile şi modul lor de imbricare.
Urmărirea unui astfel de manual de codare nu este mai dificilă decât reţinerea faptului că o
linie de tablou <tr> trebuie să fie imbricată în interiorul unui tablou <table> şi nu are, sau nu
ar trebui să aibă, sens în afara acelui context. Pentru majoritatea situaţiilor, acest lucru este
suficient. XML este capabil să ofere autorilor suficient ajutor în învăţarea modului de
utilizare a unei anumite aplicaţii, deoarece aceştia sunt încurajaţi să dea etichetelor nume
sugestive, care să fie uşor de reţinut. Autorul unei aplicaţii ar trebui să furnizeze un manual
de creare care să explice în termeni simpli modul de utilizare a aplicaţiei.
Cu toate că orice procesor XML poate spune despre o porţiune de cod dacă este sau
nu construit corect, iar un manual poate ajuta la construirea unui document valid, DTD-ul
permite verificarea fără ambiguităţi a codului. Totuşi, în funcţie de tipul de creare utilizat,
acesta poate fi un pas diferit de procesul de editare.
Codul îndeplineşte acest ideal în funcţie de utilizarea dată numelor etichetelor, totuşi
între anumite limite:
• Numele de etichete care încep cu şirul “xml”, indiferent de tipul literelor, sunt
rezervate; adică, indiferent de situaţie, nu este permisa crearea lor.
• Numele de etichete care conţin caracterul două puncte pot fi interpretate ca
identificatori având asociată o zonă de nume, deci utilizarea celor două puncte în numele
etichetelor este puternic combătută şi poate fi chiar interzisă.
• Un nume de etichetă trebuie să înceapă cu o “literă”, care în acest context este orice
literă sau ideogramă Unicode/ISO/IEC 10646, sau cu o liniuţă de subliniere
În continuare, numele unei etichete poate conţine orice “literă”, ideogramă sau cifră
Unicode/ISO/IEC 10646, caractere de combinare, caractere de extindere, puncte, cratime,
spaţii sau două puncte. De altfel, puţine limbi de pe glob au caractere cu care să nu poată
Pagina 61 din 97
Vizitati www.tocilar.ro ! Arhiva online cu diplome, cursuri si referate postate de utilizatori.
începe un nume corect în limba respectivă. Aceste caractere sunt excluse din lista de
caractere dacă se află într-o poziţie în care pot fi văzute ca “primele” după o cratimă sau un
alt separator logic de cuvinte.
Caracterul thailandez mai yamok (arată ca un f întors şi fără liniuţă), de exemplu,
arată ca o literă, dar nu poate fi folosit ca primă literă a unui cuvânt deoarece el semnifică
repetarea literei anterioare.
Caracterele de combinare sunt caractere speciale, folosite pentru a accentua un alt
caracter, multe dintre ele fiind normalizate la un singur caracter cu accent. Acesta este un
avantaj pentru intrările de la tastatură deoarece multe limbi care conţin caractere accentuate
permit introducerea utilizând caractere accent speciale “de lăţime zero” care se pot ataşa la
orice alt caracter.
Caracterele de extindere sunt diverse semne de punctuaţie, cum ar fi (în limbile
europene) middle dot, triangular colon şi half-triangular colon. Caracterele extinse sunt
similare în alte scrieri din lume; nu sunt exacte din punct de vedere alfabetic dar se potrivesc
pe undeva.
4.6 Startul în XML
Acest subiect evidenţiază mulţimea de deprinderi necesare pentru XML şi clarifică
numeroasele asemănări dintre XML şi HTML:
• XML este sensibil la tipul literelor deoarece majusculele nu reprezintă un concept
universal – Dacă s-ar trata literele mari şi mici ca fiind echivalente, ar trebui să se facă la fel
pentru mii de alte variante de litere în alte limbi, o operaţie împovărătoare. Unele limbi nici
nu au tipuri de litere. De exemplu, în limba ebraică nu există litere mici, iar limba arabă nu
face distincţie între forma iniţială, de mijloc şi finală a literelor. Pentru cei care preferă să
scrie etichetele cu majuscule şi atributele cu litere mici, pentru a le evidenţia, aceasta este o
ştire teribilă. Dar editoarele de cod moderne nu mai acordă o importanţă aşa de mare acestui
lucru ca înainte. De exemplu, precizarea anumitor culori pentru a marca etichete este un lucru
obişnuit, deci utilizarea majusculelor este întrucâtva un anacronism istoric, asemenea
numerelor de linii în COBOL.
• XML este foarte precis cu privire la imbricarea corectă a etichetelor –Etichetele nu
se pot încheia într-un context diferit de cel de început. Deci, dacă se doreşte <bold><italics>,
fraza evidenţiată trebuie închisă cu </italics></bold>, pentru a evita o eroare fatală. Deoarece
XML poate referi şi include documente XML şi fragmente de documente oriunde pe Web,
fiecare document XML trebuie să se supună aceloraşi reguli pentru a nu strica documentele
altora.
Pagina 62 din 97
Vizitati www.tocilar.ro ! Arhiva online cu diplome, cursuri si referate postate de utilizatori.
• XML nu este bine protejat împotriva recursivităţii – Cu toate că este posibilă
stabilirea excluderilor explicite la un anumit nivel, la o structură complexă a unui document
este dificilă menţinerea acelor excluderi la un nivel redus, mai ales atunci când se utilizează
etichete care pot fi aplicate la orice nivel. Deci, interdicţia HTML referitoare la includerea
unei etichete ancoră <a> în interiorul altei etichete ancoră există şi în XML, dar nu este
impusă dincolo de includerea directă.
• XML obligă la închiderea fiecărei etichete, chiar şi a etichetelor vide – Deoarece
este posibila crearea unui document XML care să nu utilizeze un DTD, un procesor XML nu
are de unde să ştie dacă o etichetă este sau nu vidă. Deoarece toate documentele XML trebuie
să fie construite corect, etichetele vide trebuie marcate cu o sintaxă specială care spune unui
procesor XML că eticheta este vidă şi închisă. Acest lucru se realizează plasând un spaţiu şi
un caracter slash la sfârşitul etichetei, astfel:
<break />
Există o sintaxă alternativă, care este la fel de bună pentru procesoarele XML reale,
dar blochează frecvent browserele Web atunci când este utilizată cu XHTML; aceasta cere ca
o etichetă vidă, cum ar fi <br>, să fie închisă cu </br>, astfel: <br></br>
Din păcate, este prea periculoasă pentru a fi utilizată în siguranţă. Multe browsere
actuale şi majoritatea celor moştenite nu recunosc eticheta de închidere non- HTML şi fac
lucruri ciudate cu ea. Navigator 4.7, de exemplu, poate zăpăci afişarea atunci când se
împiedică de o etichetă </br>. Comportamentul exact poate diferi în funcţie de poziţia în cod
şi de eticheta vidă care se închide. Pe scurt, această sintaxă este predispusă la erori şi ar trebui
evitată.
• XML necesită încadrarea valorilor atributelor fie între apostrofuri, fie între ghilimele
– Acolo unde HTML este indulgent, mai ales în ceea ce priveşte numerele şi aproape orice şir
fără spaţii în interior, XML tratează totul ca şir de caractere şi lasă aplicaţia să îşi dea seama
singură de toate acestea.
• XML recunoaşte mai multe limbi – Spre deosebire de HTML, seturile de caractere
extinse utilizate în multe limbi europene nu sunt pe deplin recunoscute în mod prestabilit.
Există un mecanism simplu pentru includerea acestora, precum şi a întregului set de caractere
Unicode (cunoscut, de asemenea, şi ca ISO/IEC 10646) care are peste un milion de caractere,
deci suportul pentru chineză, arabă şi multe alte limbi mai exotice ale lumii este un lucru
uşor. În afară de diferenţele menţionate în această listă, XML este foarte asemănător cu
HTML din punctul de vedere al marcării etichetelor, al argumentării atributelor şi al trecerii
conţinutului între perechi de etichete.
Pagina 63 din 97
Vizitati www.tocilar.ro ! Arhiva online cu diplome, cursuri si referate postate de utilizatori.
Limbajul XML a fost proiectat astfel încât să fie transparent la utilizare pentru a putea
fi înţeles şi utilizat cu uşurinţă. Descrierile XML succinte sau complicate din majoritatea
documentelor sunt greu de înţeles în efortul de a fi explicit într-un mod în care programatorii
să îl poată translata cu uşurinţă în aplicaţii care să funcţioneze.
4.7 Definirea unui document XML ca întreg
Un document XML este o colecţie de entităţi care pot fi sau nu analizate. Datele care
nu sunt înţelese de un procesor XML, date binare sau date care au sens numai pentru alte
aplicaţii, reprezintă date neanalizate. Datele înţelese de XML, fie ca şi caractere fie ca
marcaje, sunt date analizate.
Un document XML trebuie să fie construit corect. În Recomandarea XML 1.0 a W3C
această situaţie este descrisă concis prin următoarele cerinţe:
• Luat ca întreg, corespunde producţiei etichetate ca document.
• Satisface toate constrângerile de construire corectă din această specificaţie
(Recomandarea XML 1.0)
• Fiecare entitate analizată, referită direct sau indirect în cadrul documentului, este
construită corect.
Prima constrângere spune că pentru a fi construit corect, un document XML trebuie să
respecte toate regulile care descriu un document în Recomandarea XML 1.0. Acele reguli
spun în primul rând că un document XML trebuie să conţină un prolog şi un singur element
care formează elementul rădăcină al documentului, împreună cu comentarii opţionale şi
instrucţiuni de prelucrare la sfârşitul documentului, dar, din păcate, analizorul XML nu are
cum să spună dacă aceste comentarii şi instrucţiuni de prelucrare ataşate sunt sau nu ataşate
documentului. Deoarece ele pot sa fie plasate după eticheta de încheiere, un analizor XML nu
poate să spună nici dacă instrucţiunile de prelucrare şi comentariile ataşate au fost sau nu
recepţionate. Aceasta contravine regulii generale din XML care spune că un analizor trebuie
să fie capabil să indice dacă un document este sau nu complet. Dacă se utilizează instrucţiuni
de prelucrare sau comentarii, este preferabilă trecerea lor în prolog unde sunt mult mai în
siguranţă şi nu se pot pierde.
Cea de a doua constrângere spune că documentul respectă constrângerile construirii
corecte descrise în document. Una din constrângerile construirii corecte este că entităţile
analizate recursiv sunt interzise. Recursivitatea din această interdicţie se referă la formarea
unei bucle de entităţi în care o entitate se încorporează pe ea însăşi sau o altă entitate care se
încorporează pe ea însăşi indiferent de nivelul de indirectare. Aceasta mai înseamnă şi că un
document nu se poate referi la el însuşi, nici măcar indirect printr-o entitate externă. El se
Pagina 64 din 97
Vizitati www.tocilar.ro ! Arhiva online cu diplome, cursuri si referate postate de utilizatori.
poate referi la o entitate externă numai dacă aceasta nu se referă la ea însăşi, chiar şi indirect.
Este posibil ca analizoarele care nu validează să nu depisteze această eroare, dar aceasta este
totuşi o eroare. Din punct de vedere logic este evident că dacă documentul A conţine
documentul B, definindu-l pe B ca şi când l-ar conţine pe A se generează o buclă infinită.
Bucla infinită este interzisă.
În termeni XML, construcţia corectă este o altă modalitate de a spune că un document
XML formează un arbore, sau o ramură a unui arbore, adică este complet în sine. Acest lucru
este necesar deoarece XML permite construirea de documente mai mari din unele mai mici şi
reprezintă o cheie a posibilităţii de utilizare a XML pe Web.
Deşi construirea corectă poate fi considerată suficientă deoarece un document
construit corect are un DTD care îl descrie, pot fi construite un număr infinit de DTD-uri
care, de asemenea, să îl descrie. Deci, pentru validitate totală, un DTD asociat este necesar.
Producţia documentului este definită în numai două afirmaţii, preluate din nou din
Recomandarea XML 1.0:
• Conţine unul sau mai multe elemente.
• Există un singur element, numit rădăcină sau element document, care să nu aibă nici
o parte a sa în conţinutul oricărui alt element. Pentru toate celelalte elemente, dacă eticheta de
pornire se află în conţinutul unui alt element, atunci şi eticheta de încheiere se află în
conţinutul aceluiaşi element. Exprimat mai simplu, elemente delimitate de etichete de pornire
şi încheiere sunt imbricate corect unele în altele.
Prima afirmaţie spune că într-un document trebuie să existe cel puţin un element sau,
altfel spus, un document construit corect nu poate fi vid.
Cea de a doua afirmaţie spune că, într-un sens restrâns, un document trebuie să fie un
arbore. El nu poate fi o reţea conectată arbitrar sau să aibă orice altă topologie care nu se
reduce la un arbore simplu. El trebuie să fie complet pentru a putea vedea diferenţa dintre o
descărcare reuşită şi una parţială.
Din punct de vedere tehnic, un arbore este un graf conex care nu conţine circuite. Cu
alte cuvinte, un arbore se ramifică de la rădăcina sa fără a se mai conecta la el însuşi, deci nu
conţine muchii multiple sau bucle. Orice lucru care conţine bucle sau muchii multiple, nu este
un arbore, ci altceva, şi nu poate fi reprezentat în XML. Un efect secundar interesant este
acela că într-un arbore se poate alege arbitrar un punct, şi se poate transforma un nod într-o
rădăcină, reorganizând arborele într-un alt arbore, cu o altă ordine de parcurgere. Aceasta
ilustrează caracterul capricios al schemelor de clasificare.
Pagina 65 din 97
Vizitati www.tocilar.ro ! Arhiva online cu diplome, cursuri si referate postate de utilizatori.
O descărcare parţială este posibilă în HTML, deoarece HTML nu are nevoie de
eticheta de încheiere </html>, sau nu are nevoie de aproape nici o etichetă de încheiere.
Uneori browserul poate detecta întreruperea, dar acest lucru nu este garantat. Aceasta
însemnă că un document parţial se poate deghiza într-unul complet, iar utilizatorul nu are de
unde să ştie acest lucru până când în text nu apare o eroare evidentă. XML previne aceste
probleme, lucru care poate fi important în cazul în care un utilizator reclamă ulterior că o
convenţie de acordare a licenţei, de exemplu, nu a fost afişată în întregime. Insistând asupra
unui arbore complet, un astfel de exemplu fiind prezentat în Figura 1, se
elimină aceste probleme posibile.
Figura 1
Pe de altă parte, un graf care nu formează un arbore nu poate fi transformat într-un
document XML decât dacă graful poate fi simplificat, eliminând toate caracteristicile care nu
sunt reprezentative pentru arbori. În Figura 2, de exemplu, graful din stânga poate fi
simplificat prin eliminarea unei căi de la frunza de sus către un nod. În aceeaşi figură,
grafului din partea dreaptă trebuie să i se elimine o rădăcină deoarece un document XML
poate avea o singură rădăcină.
Pagina 66 din 97
Vizitati www.tocilar.ro ! Arhiva online cu diplome, cursuri si referate postate de utilizatori.
4.8 Prologul: declaraţia XML
Fiecare document XML, ar trebui să înceapă cu o declaraţie XML care identifică
fişierul ca fiind un fişier XML şi identifică, de asemenea, versiunea XML utilizată în
documentul respectiv. Caracterul opţional este datorat numai faptului că pe Web există multe
fişiere HTML şi SGML care corespund perfect unui document XML construit corect. De
asemenea, declaraţia XML este locul unde se declară codificarea şi dacă documentul este sau
nu autonom. Ordinea din fragmentul următor este obligatorie cu toate că atributele encoding
şi standalone sunt ambele opţionale.
<?xml version=”1.0” encoding=”ISO-8859-1” standalone=”yes”>
Codificările permit identificarea cărui dintre multiplele seturi de caractere va fi
utilizat în document. Acest lucru este important deoarece, spre deosebire de HTML, care
implică ASCII, şi obligă la folosirea numelor ASCII, XML permite vorbitorilor de Hindi, de
exemplu, să utilizeze codificarea lor şi să facă textul şi mediul de editare lizibil şi pentru
persoanele obişnuite care pot fi autori XML. Sau, un autor chinez poate să prefere caracterele
chinezeşti în etichete şi în conţinut cu câteva limitări bazate pe regulile limbajului în sine, se
pot utiliza moduri de scriere şi ideograme atât în numele etichetelor cât şi în conţinut.
4.9 Documente autonome
În conformitate cu Recomandarea XML 1.0 a W3C, “Documentele autonome nu au
declaraţii de marcare externe care să afecteze informaţia XML transferată de procesorul XML
Pagina 67 din 97
Vizitati www.tocilar.ro ! Arhiva online cu diplome, cursuri si referate postate de utilizatori.
unei aplicaţii”. Acesta este un mod extraordinar de succint şi obscur de a spune că
standalone=”yes” înseamnă că:
• Într-un DTD extern nu există valori prestabilite declarate ale atributelor care să nu
fie setate explicit în document.
• Nu sunt utilizate alte entităţi în afară de &, <, >, ', şi ", care
nu au fost declarate local sau poate citite prin referinţă dintr-un fişier.
• Nu există elemente care să aibă ca şi conţinut numai spaţii albe de orice natură.
• Nu există atribute externe care trebuie normalizate, deci conţinutul atributelor nu
poate conţine spaţii albe, caractere sau referinţe la entităţi. Aceasta nu înseamnă că
documentul nu are nimic extern. Aceasta înseamnă în special că, indiferent de locul în care
un procesor XML care nu validează se opreşte din citirea documentelor externe, se opreşte
prelucrarea tuturor declaraţiilor. Toate aceste lucruri se pot face dacă şi numai dacă sunt puse
în submulţimea DTD-ului intern. Datele externe care nu sunt marcaje nu fac subiectul acestei
afirmaţii. Deci, pot exista fişiere grafice, fişiere text incluse şi orice altceva, atât timp cât ele
nu sunt marcaje şi au fost declarate în submulţimea DTD-ului intern. După toate acestea,
procesorul XML nu trebuie să anunţe aplicaţia dacă documentul este sau nu autonom. De
fapt, procesorul nu trebuie să facă nimic cu această informaţie şi nici să se comporte într-un
anumit fel atunci când întâlneşte această informaţie.
În mod fundamental, proiectantul DTD-ului trebuie să descifreze dacă documentul
creat utilizând acel DTD poate fi sau nu autonom şi să comunice acest lucru oamenilor
inclusiv autorilor. Autorii care ştiu că DTD a fost proiectat pentru a fi autonom sau cei care
au convertit un document care nu a fost proiectat să fie autonom în acest format, pot insera
stanalone=”yes” în declaraţia lor XML ca o documentaţie a acelui fapt:
<?xml version=”1.0” standalone=”yes” ?>
Documentele care nu sunt autonome pot fi convertite prin algoritmi la documente
autonome, automat, presupunând că este disponibilă o facilitate care să realizeze acest lucru,
sau manual în caz contrar.
4.10 Construirea prologului unui document XML: Declaraţia tipului documentului
(Document Type Declaration)
Prologul unui document XML conţine mai multe instrucţiuni. Prima, declaraţia XML,
afirmă că documentul următor este XML. Cea de a doua, declaraţia tipului documentului
(Document Type Declaration), este metoda utilizata pentru a identifica definiţia tipului
documentului (Document Type Definition - DTD) folosită de un anumit document. Faptul că
acronimul DTD poate fi aplicat la Document Type Declaration este o coincidenţă nefericită.
Pagina 68 din 97
Vizitati www.tocilar.ro ! Arhiva online cu diplome, cursuri si referate postate de utilizatori.
DTD se referă numai la Document Type Definition. Într-un document XML poate exista o
singură declaraţie a tipului documentului, deci este introdusă chiar în instanţa documentului.
Deoarece pot fi combinate mai multe DTD-uri pentru a forma un singur document, aceasta
permite controlul încărcării DTD-urilor în fiecare document.
Declaraţia tipului documentului (DOCTYPE) are două părţi, ambele opţionale. Prima
se referă la un DTD extern, şi utilizează cuvinte cheie PUBLIC sau SYSTEM pentru a
identifica o intrare dintr-un catalog, respectiv un URI. În cazul în care cataloagele nu sunt
implementate în procesorul XML, se pot specifica ambele părţi deodată, fără cel de al doilea
cuvânt cheie:
<!DOCTYPE nume-document PUBLIC “{catalog id}”>
<!DOCTYPE nume-document PUBLIC “{catalog id}” “{uri}”>
<!DOCTYPE nume-document SYSTEM “{uri}”>
Cea de a doua parte opţională a declaraţiei DOCTYPE permite introducerea
submulţimii interne a unui DTD direct în document. Există restricţii severe cu privire la genul
de informaţie care poate fi introdusă în DTD-ul intern, dar oricum se pot face destul de multe.
Submulţimea internă a unui DTD este încadrată între paranteze drepte, astfel:
<!DOCTYPE nume-document [ {declaraţiile DTD-ului intern} ]>
De asemenea, cele două pot fi combinate, permiţând adăugarea anumitor tipuri de
declaraţii şi entităţi aproape în orice mod:
<!DOCTYPE nume-document PUBLIC “{catalog id}” “{uri}” [ {declaraţiile DTD-
ului intern} ]>
Pentru claritate, submulţimea internă este evidenţiată ca mai jos:
<!DOCTYPE nume-document PUBLIC “{catalog id}” “{uri}” [
{declaraţiile DTD-ului intern}
]>
Declaraţia DOCTYPE trebuie să utilizeze numele elementului rădăcină al DTD-ului
fie acesta intern sau extern, ca fiind câmpul etichetat nume-document din exemplele
anterioare. Deci dacă numele elementului rădăcină al DTD-ului este Dave, declaraţia
DOCTYPE ar trebui să înceapă astfel:
<!DOCTYPE Dave …>
Manualul de codare indică autorilor ce trebuie trecut în DOCTYPE. Un proiectant
DTD ar trebui să furnizeze un astfel de document sau o foaie de codare fiecărui autor. De
asemenea, se poate crea un DTD master care apelează părţile DTD necesare, lucru care
seamănă cu comenzile dintr-un meniu. Atunci când se obţine o combinaţie de funcţionalităţi
Pagina 69 din 97
Vizitati www.tocilar.ro ! Arhiva online cu diplome, cursuri si referate postate de utilizatori.
care permite crearea structurii documentului de care este nevoie, se poate publica DTD-ul
rezultat şi înlătura neplăcerea refacerii pentru fiecare document nou.
4.10.1 Crearea corpului documentului
Un document XML este alcătuit din text, care de obicei este format dintr-un amestec
de marcaje şi date caracter. Prologul conţine numai marcaje, dar nu aceasta este partea
interesantă, deoarece este nevoie de date care să însoţească marcajele care, altfel, nu ar fi
decât nişte cutii goale ce aşteaptă să fie umplute. Corpul documentului conţine aproape tot
ceea ce contează din perspectiva unei aplicaţii împrăştiate generos în cadrul marcajelor.
4.10.2 Date caracter
Un DTD poate declara multe tipuri de date care să poată fi utilizate într-un document,
dar tipul de date prestabilit este întotdeauna CDATA, pentru date obişnuite de tip caracter.
Foaia sau manualul de codare indică ce tip de dată poate fi introdus în fiecare atribut sau
câmp cu conţinut element. Presupunând că tipul de date este CDATA, în câmp se poate pune
aproape orice se doreşte atât timp cât nu conţine un marcaj în afara unei secvenţe escape.
Este pe deplin posibilă construirea unui DTD care să nu conţină text în interiorul
elementelor. În schimb, se pot pune datele semnificative în interiorul atributelor asociate
fiecărui element, care pot fi toate declarate ca fiind vide sau având numai conţinut element.
Acest lucru se face uneori pentru a converti un document utilizând un standard de codificare
cum ar fi MARC, care este în esenţă un format binar, la XML.
4.10.3 Marcajul
Marcajul este format din ansamblu de date non-caracter dintr-un fişier XML.
Diversele forme pe care le poate lua un marcaj sunt prezentate în tabelul următor:
Tabel
1 Sintaxa marcajului XML
Toate celelalte sunt date de tip caracter.
Pagina 70 din 97
Vizitati www.tocilar.ro ! Arhiva online cu diplome, cursuri si referate postate de utilizatori.
Marcajul începe întotdeauna fie cu caracterul <, caz în care se încheie întotdeauna cu
caracterul >, fie cu caracterul &, caz în care se încheie întotdeauna cu caracterul “;”.
4.10.4 Formarea structurilor logice în XML
Imbricarea elementelor este singurul mecanism utilizat pentru a arăta structura logică
dintr-un document XML. Etichetele de pornire şi încheiere din fluxul de text spun
procesorului XML că a fost întâlnit un nod. Dacă procesorul XML întâlneşte o altă etichetă
de pornire înainte de eticheta de încheiere corespunzătoare, atunci procesorul ştie că acesta
este fie un nod nou în arbore, fie o frunză. Dacă nu găseşte o nouă etichetă de pornire şi
întâlneşte o etichetă de încheiere, atunci procesorul ştie că aceasta este o frunză şi că poate
acţiona iterativ la acel nivel al arborelui până când întâlneşte o altă etichetă de pornire sau de
încheiere. Prelucrarea acţionează treptat, bazându-se pe această regulă simplă. Dacă
procesorul validează documentul, atunci fiecărui nod i se poate asocia o regulă care să
determine ce tip de conţinut poate apărea în el. O etichetă vidă este, prin definiţie, o frunză,
deoarece nu poate avea nici un conţinut.
Majoritatea structurilor de date conţinute într-un document XML pot fi accesate
secvenţial fără a construi structura în memorie. O etichetă de pornire începe un nod sau o
frunză, iar eticheta de încheiere corespunzătoare îl(o) încheie. Orice etichete întâlnite între o
etichetă de încheiere corespunzătoare ei încep un nod sau o frunză nouă. Acest principiu
reprezintă baza lui SAX şi a altor procesoare XML conduse prin evenimente.
Restul structurii logice a documentului este definit prin atributele asociate fiecărui
element. În plus, structura logică poate diferi în funcţie de conţinutul secţiunilor condiţionale
din cadrul documentului sau al componentelor sale.
4.10.5 Cum formează XML structurile fizice
Imbricarea entităţilor este singurul mecanism utilizat pentru a arăta structura fizică
dintr-un document XML. Definiţiile de entităţi întâlnite în fluxul de text îi comunică
procesorului XML că a fost găsită o altă entitate.
Există multe tipuri de entităţi, de la entităţile mici care formează caractere individuale,
cum ar fi:   (spaţiu), până la entităţile externe care permit încorporarea într-un
document porţiuni din alte documente XML sau includerea într-un document a referinţelor la
date neanalizate, cum ar fi fişiere multimedia pentru redarea ulterioară de către un agent
utilizator.
Un document XML este o colecţie de astfel de entităţi. Fiecare din aceste subentităţi
trebuie să fie completă în sine. Aceasta înseamnă că, deoarece structura documentului ca
întreg trebuie să fie un arbore simplu, fiecare subentitate trebuie să fie un singur nod sau
Pagina 71 din 97
Vizitati www.tocilar.ro ! Arhiva online cu diplome, cursuri si referate postate de utilizatori.
trebuie să fie, de asemenea, un arbore simplu. Structuri mai mari se pot construi prin
adăugarea nodurilor sau a arborilor subentitate ca porţiuni ale arborelui mai mare.
4.10.6 Etichete de pornire şi etichete de încheiere
În XML sunt utilizate două tipuri de etichete, etichete cu conţinut şi etichete vide.
Etichetele cu conţinut trebuie să aibă o etichetă de pornire şi o etichetă de încheiere. Eticheta
de pornire conţine numele elementului încadrat între paranteze unghiulare, având opţional
atribute ca argumente. Eticheta de încheiere conţine numele elementului precedat de
caracterul slash, totul fiind încadrat între paranteze unghiulare. În eticheta de încheiere nu
puteţi trece atribute. Codul următor reprezintă o etichetă cu conţinut:
<titlu subtitlu=”0 călătorie acasă” >Dus-întors</titlu>
Seamănă mult cu etichetele HTML standard şi nu ar trebui să ridice alte probleme în
afara celei de construire corectă, care cere ca ele să se imbrice într-adevăr una în cealaltă. Nu
pot exista etichete care să alterneze între ele ca în acest exemplu greşit construit:
<bold><italic>TEXT ACCENTUAT</bold></italic>
Cu toate că este o eroare obişnuită în HTML, XML este cu mult mai pretenţios şi nu
va permite această construcţie. Etichetele trebuie imbricate corect, după cum se vede în
exemplul următor:
<bold><italic>TEXT ACCENTUAT</italic></bold>
Acum etichetele sunt imbricate corect. Trebuie închisă fiecare etichetă care începe în
contextul unei anumite etichete (sau a mai multor etichete) înainte de închiderea contextului
etichetei respective.
Etichetele vide au disponibil un format special, cu toate că aceeaşi schemă, etichetă de
pornire/ etichetă de încheiere, poate fi utilizată atâta timp cât se ţine cont de faptul că nu
trebuie pus nici un fel de conţinut între eticheta de pornire a elementului vid şi eticheta de
încheiere care urmează imediat după ea. De asemenea, poate exista preocuparea că este
posibil ca documentul XML să fie vizualizat cu un browser Web obişnuit, deoarece etichetele
de încheiere pentru elementele care arată ca etichete HTML vide pot duce la blocarea
browserului sau la un comportament ciudat al acestuia. Totuşi, pentru utilizare generală,
formatul special este mnemonic în sine, un avantaj deoarece se poate vedea că eticheta este
vidă şi nu blochează aproape nici un browser. De obicei, etichetele vide sunt pornite şi
încheiate în cadrul aceleiaşi perechi de paranteze unghiulare, plasând după numele
elementului şi toate atributele sale posibile un spaţiu, un caracter slash şi apoi paranteza
unghiulară închisă:
<image source=”pozamea.jpeg” type=”JPEG” />
Pagina 72 din 97
Vizitati www.tocilar.ro ! Arhiva online cu diplome, cursuri si referate postate de utilizatori.
4.10.7 Normalizarea
Normalizarea este un cuvânt excentric pentru aducerea lucrurilor la cel mai mic
numitor comun şi punerea lor într-un fel de formă canonică. În contextul XML, el se referă la
procesul rezolvării referinţelor la entităţi în locaţii în care pot apărea astfel de referinţe, la
aranjarea rândurilor noi pentru a lua în considerare diversele metode de tratare a lor de către
diferite sisteme de operare şi la ordonarea altor lucruri care trebuie făcute în anumite situaţii.
Proiectantul rareori trebuie să se preocupe de normalizare, excepţie făcând cazurile
negative. Analizorul XML ar trebui să realizeze toate normalizările necesare, deci singurul
lucru la care trebuie să se gândească creatorul documentului este dacă normalizarea va afecta
sau nu datele sale atunci când se va face trecerea de la forma nenormalizată şi invers. S-a
dovedit că există două locuri în care pot fi întâlnite spaţii albe: în datele de tip caracter din
cadrul documentului şi în datele de tip caracter atribuite atributelor elementelor. În primul
caz, în entităţile analizate este dificil să se facă distincţie între spaţiile albe “semnificative” şi
cele nesemnificative. Pentru proiectanţi, cea mai bună cale pare să fie transferul către
aplicaţie al tuturor spaţiilor albe împreună cu cea mai bună presupunere a procesorului,
bazată pe DTD, referitoare la datele care sunt în mod sigur nesemnificative şi la cele
nesigure. Acest transfer de răspundere are sens deoarece aplicaţia este cea în măsură să ştie
cum să procedeze cu spaţiile albe suplimentare.
Procesorul XML poate numai să presupună care spaţiu alb este semnificativ şi care
nu, bazându-se pe ceea ce a fost definit în DTD sau în orice alt limbaj de scheme utilizat. O
aplicaţie trebuie să fie pregătită să trateze presupunerile eronate. Cu tratarea sfârşiturilor de
linie, o altă formă de spaţii albe, există o altă problemă. Liniile noi sunt tratate diferit pe
sisteme diferite. Alternativele generale sunt un salt la linie nouă (UNIX), un return (MacOS)
şi atât un return cât şi saltul la linie nouă (MS Windows). Un alt lucru obişnuit pentru
aplicaţii este, de asemenea, inserarea de secvenţe contradictorii cu oricare dintre acestea, în
orice ordine, atunci când întâlnesc un fişier dintr-un sistem străin. W3C a hotărât că nu poate
face totul şi a ales un set rezonabil de reguli. Dacă analizorul întâlneşte fie 

(return , salt la linie nouă), fie 
(return), el le înlocuieşte cu �A; (salt la linie nouă),
caracterul de linie nouă UNIX.
Microsoft şi Apple au ales mecanisme diferite pentru separarea liniilor, Microsoft
alegând tehnica “curea şi bretele” obişnuită pentru teleimprimatoare, utilizând un return şi
apoi un salt la linie nouă pentru a indica o linie nouă. Apple a hotărât că saltul la linie nouă
era redundant şi a considerat că un singur return este suficient, modelat probabil după
comportamentul unei maşini de scris obişnuite. UNIX a utilizat de la început un singur salt la
Pagina 73 din 97
Vizitati www.tocilar.ro ! Arhiva online cu diplome, cursuri si referate postate de utilizatori.
linie nouă pentru a realiza acelaşi lucru, iar acesta a fost standardul convenit pentru XML. În
atribute există o secvenţă de transformare standard şi apoi o prelucrare
adăugată special pentru orice în afară de CDATA:
• Referinţele la caractere sunt prelucrate prin adăugarea caracterului referit la valoarea
de ieşire a atributului.
• Referinţele la entităţi sunt procesate prin prelucrarea recursivă a textului de înlocuit
al entităţii.
• Spaţiile albe, #x20 (spaţiu), #x0D (retur de car), #x0A (salt de linie nouă) şi #x09
(tab orizontal) sunt prelucrate prin adăugarea lui #x20 (spaţiu) la valoarea normalizată a
ieşirii excepţie făcând faptul că se adaugă un singur #x20(spaţiu) pentru secvenţa
“#x0D#x0A” (retur de car, salt la linie nouă), care este parte a unei entităţi externe analizate
sau valoarea entităţii literale a unei entităţi analizate interne.
• Celelalte caractere sunt prelucrate prin adăugarea lor la valoarea normalizată a
ieşirii.
• Dacă tipul de dată al atributului nuI este CDATA, cel prestabilit, atunci se aplică
încă o transformare. Spaţiile din faţă şi din spate sunt eliminate, iar spaţiile multiple sunt
comasate într-un singur spaţiu. Diferenţa dintre cele două tipuri de normalizare constă în
faptul că se pot transfera în mod convenabil şiruri lungi într-un atribut, restrânge linii astfel
încât să încapă în pagină, iar în final conţinutul elementului să rămână relativ curat.
4.10.8 Tipuri de elemente
În mod surprinzător, la validare nu este o eroare utilizarea unui element de un tip care
nu a fost declarat, cu toate că este posibil ca analizorul să emită un advertisment. De fapt,
permiţând în interiorul unor elemente alte tipuri de elmente nedeclarate, indiferent de ceea ce
spune modelul lor de conţinut, se poate suplimenta DTD-ul unui document cu elemente din
alte zone de nume. Deci, tot ce rămâne de făcut este utilizarea elementului nedeclarat într-o
manieră exactă, construită corect, identificând pe cât posibil zona de nume de unde provine.
În termeni XML, a fi construit corect este un alt mod de a spune că acel element formează un
arbore sau o ramură a unui arbore care este completă în sine. Acest lucru este necesar
deoarece XML permite construirea de documente mai mari din unele mai mici şi este un
element cheie pentru utilizarea XML pe Web. Fiecare element dintr-un document XML valid
a fost definit în DTD-ul asociat acelui document prin declaraţia DOCTYPE. DTD-ul declară
următoarele:
• Numele efective ale elementelor
Pagina 74 din 97
Vizitati www.tocilar.ro ! Arhiva online cu diplome, cursuri si referate postate de utilizatori.
• Regulile utilizate pentru a determina care elemente se pot imbrica în alte elemente şi
în ce ordine
• Atributele posibile şi valorile lor prestabilite sau constante
• Valorile caracter ale tipurilor enumerate
• Entităţile neanalizate utilizate în document şi modul în care sunt referite prin nume
• Codificările de limbă utilizate în document
• Alte informaţii importante pentru prelucrarea şi redarea documentului
Respectând aceste reguli se pot crea documente în concordanţă cu şablonul pe care
proiectantul documentului l-a avut în minte atunci când a creat DTD-ul. Într-un mediu care
nu validează se pot crea etichete şi atribute pe măsura înaintării. Foaia sau manualul de
codare afişează toate acestea într-un format uşor de citit şi înţeles, dacă autorul DTD-ului şi-a
făcut treaba corect. Când se creează un document XML sau se corectează o eroare, este
posibil să nu se beneficieze de avantajul unui mediu de creare complet. Este întotdeauna
importantă păstrarea la îndemână a documentaţiei de codare pentru cazul în care apar
defecţiuni.
4.10.9 Entităţi neanalizate
O entitate neanalizată este orice lucru care nu poate fi recunoscut de un procesor
XML, fie date binare, cum ar fi un fişier imagine sau audio, fie text care trebuie să fie
transferat unei aplicaţii fără a fi prelucrat în vreun fel. HTML utilizează comentarii pentru a
ascunde un astfel de text de browserul HTML, dar XML are câteva mecanisme care
funcţionează mult mai sigur.
O entitate neanalizată trebuie mai întâi să fie declarată ca NOTATION, o declaraţie
specială care numeşte o aplicaţie de asistenţă care ştie cum să lucreze cu entităţi de un anumit
tip. Notaţiei îi este dat un nume, un identificator public opţional şi apoi numele mai puţin
opţional al aplicaţiei de asistenţă, ca în una din variantele următoare:
<! NOTATION nume-mnemonic PUBLIC “identificator-public”>
<! NOTATION nume-mnemonic PUBLIC “identificator-public” “nume-
aplicaţie.exe”>
<! NOTATION nume-mnemonic SYSTEM “nume-aplicaţie.exe”>
Prima opţiune funcţionează numai dacă există un catalog. Nu se poate pune baza pe
un catalog deoarece acesta funcţionează indiferent dacă există sau nu catalog. Nu se poate
baza pe un catalog deoarece acesta este un instrument SGML pe care multe procesoare XML
actuale l-au moştenit implicit de la predecesoarele lor SGML. Studierea catalogului nu este
specificată în recomandarea W3C şi nu se poate conta niciodată pe ea. Dacă este posibil, se
Pagina 75 din 97
Vizitati www.tocilar.ro ! Arhiva online cu diplome, cursuri si referate postate de utilizatori.
recomandă utilizarea ultimele două versiuni. Pe de altă parte, codarea hard a informaţiilor
despre locaţia şi identitatea aplicaţiei de asistenţă în absolut fiecare DTD este un anacronism
predispus la erori pe Web.
Prin redefinirea comportamentului script-urilor în prezenţa comentariilor, proiectanţii
XML-ului au introdus o problemă de incompatibilitate între XML şi HTML. După toate
probabilităţile, procesoarele XML vor continua să transfere comentarii la aplicaţii deoarece
multe pagini se vor întrerupe dacă nu vor avea acest comportament. De asemenea,
procesoarelor le este permis transferul informaţiei comentate prin acelaşi limbaj prin care li
se permite să nu o facă. După ce o notaţie a unei entităţi neanalizate a fost definită, ea trebuie
să fie declarată ca o entitate, astfel:
<! ENTITY nume-mnemonic NDATA nume-mnemonic>
şi apoi trecută ca un atribut într-un element pentru a o putea utiliza:
<! ELEMENT name EMPTY>
<! ATTLIST name type NOTATION “mnemonic”
…>
Numele mnemonice nu împart aceeaşi zonă de nume, deci nu are importanţă dacă ele
sunt identice. În acest moment se poate utiliza tipul de date definit astfel. Tipul de date poate
fi utilizat numai ca atribut al unui element declarat ca fiind de acel tip sau având acel tip
disponibil într-o enumerare. Celelalte atribute adună informaţiile de care are nevoie aplicaţia
de asistenţă externă pentru a fi capabilă să prelucreze datele. O aplicaţie tipică poate fi un
fişier imagine:
<image source =”uri” alt =”graphic description” type=”gif89a”>
Acest element va necesita în DTD următoarele declaraţii:
<! NOTATION gif89a PUBLIC “-//CompuServe//NOTATION Graphics Interchange
Format 89a//EN” “explorer.exe”>
<! ENTITY gif89a NDATA gif89a >
<! ELEMENT image EMPTY>
<! ATTLIST image source CDATA #REQUIRED
alt CDATA #IMPLIED
type NDATA gif89a >
Pentru majoritatea instrumentelor, nu va avea importanţă dacă formatul este specificat
ca gif87a sau ca gif89a, deoarece aceleaşi instrumente manevrează ambele formate.
Notaţiile vor fi mult îmbunătăţite o dată cu adăugarea facilităţilor oferite de
XLink/XPointer care ajută la urmărirea locaţiilor asistenţilor. Cu instabilitatea generală a
Pagina 76 din 97
Vizitati www.tocilar.ro ! Arhiva online cu diplome, cursuri si referate postate de utilizatori.
Web-ului la nivelul său actual şi cu larga varietate de facilităţi şi arhitecturi de pe sistemele
utilizatorilor, orice ajutor care poate fi obţinut de către utilizator va face mai uşoară
configurarea instrumentelor XML. DTD-ul, în forma sa actuală, necesită mult prea multă
ajustare în stil UNIX a fişierelor pentru a fi pe placul utilizatorilor obişnuiţi. XLink şi
XPointer încearcă să învingă limitările tehnologiei pointer actuale. Permit toate tipurile de
relaţii, inclusiv pointeri inverşi care să fie generaţi pe loc în documente fără acces la scriere,
realizând-uşi efectul chiar asupra copiei afişate, şi nu prin inserarea fizică brută a etichetelor
în conţinut.
Cerinţele XML pentru notaţii, în forma actuală, sunt extrem de severe.
Posibilitatea de a indica locaţia unde se află aplicaţia de asistenţă poate fi comodă
pentru notaţii neobişnuite sau foarte specializate. Totuşi, este de aşteptat ca agentul utilizator
să ştie cum să afişeze multe dintre tipurile mai obişnuite, cum ar fi GIF-uri, JPEG-uri,
PNGuri, WAV-uri şi alte tipuri de fişiere binare mai mult sau mai puţin standard, utilizate pe
Web. Iată o listă a notaţiilor obişnuite:
<! NOTATION eps PUBLIC “+//ISBN Ǿ-201-18127-4::Adobe//NOTATION
Postscript Language Reference Manual//EN”>
<! NOTATION tex PUBLIC “+//ISBN Ǿ-201-13448-9::Knuth//NOTATION The
TeXbook//EN”>
<! NOTATION cmgchar PUBLIC “ISO 8632/2//NOTATION Character encoding
//EN” >
<! NOTATION cmgbinary PUBLIC “ISO 8632/3//NOTATION Binary encoding
//EN” >
<! NOTATION cmgclear PUBLIC “ISO 8632/4//NOTATION Clear text encoding
//EN” >
<! NOTATION tiff PUBLIC “ISO 12083:1994//NOTATION TIFF-1 //EN” >
<! NOTATION jpeg PUBLIC “ISO/IEC 10918:1983//NOTATION Digital
Compresion and Encoding of
Continuous –tone Still Images (JPEG)//EN” >
<! NOTATION gif87a PUBLIC “-//CompuServe //NOTATION Graphics Interchange
Format 87a//EN”
>
<! NOTATION gif89a PUBLIC “-//CompuServe //NOTATION Graphics Interchange
Format 89a//EN”
>
Pagina 77 din 97
Vizitati www.tocilar.ro ! Arhiva online cu diplome, cursuri si referate postate de utilizatori.
<! NOTATION fax PUBLIC “-//USA-DOD//NOTATION CCITT Group 4 Facsimile
Type 1 Untiled
Raster//EN” >
Desigur, va trebui să se adauge un ID sistem pentru a le putea utiliza, fie ca pointer la
o aplicaţie de asistenţă locală, fie în fişierul catalog care centralizează locaţiile acestor
aplicaţii, dacă este disponibil pentru instrumentele folosite.
4.10.10 Aplicaţii din lumea reală
S-au văzut deja, mai sus, unele dintre instrumentele care pot fi utilizate pentru a crea
un document XML, dar unde se pot găsi DTD-urile? Multe DTD-uri se află în domenii
publice sau sunt disponibile ca standarde de la ISO, ANSI sau de la alte organisme de
standardizare. Câteva dintre aplicaţiile mai importante ale XML care se afirmă în lumea de
azi sunt:
• Health Level-7 (HL7), Standardul informatic de sănătate (Health Informatics
Standard) a fost introdus în anul 1987 pentru a dezvolta standarde pentru schimbul electronic
de informaţii clinice, financiare şi administrative între sistemele de calcul din domeniul
sănătăţii. HL7 s-a concentrat asupra utilizării SGML şi XML ca mecanisme de transport între
diferite sisteme informatice din domeniul sănătăţii.
• Real Estate Transaction Standard (RETS – standardul de tranzacţii imobiliare) este o
metodă bazată pe XML pentru schimbul de informaţii referitoare la tranzacţiile imobiliare.
Un standard concurent este Real Estate Markup Language (RELML – limbajul de marcare
pentru domeniul imobiliar) care utilizează DTD-urile XML pentru a prezenta listinguri cu
spaţii pentru locuinţe, spaţii comerciale şi terenuri virane, pentru publicarea lor pe Web.
• RosettaNet, limbajul comun pentru afaceri, este o iniţiativă EDI/E-Commerce
destinată intermedierilor în domeniul calculatoarelor.
• MathML şi CML sunt două standarde XML ştiinţifice care permit matematicienilor
să editeze ecuaţii, iar chimiştilor să prezinte formule chimice.
• SMIL, the Synchronized Multimedia Integration Language (limbajul de integrare
multimedia sincronizat), este HyTime for Everyman (HyTime pentru fiecare), un limbaj de
marcare multimedia care permite furnizorilor de conţinut să realizeze prezentări audio şi
video complexe.
• ICE, Information and Content Exchange (schimb de informaţii şi conţinut), cu toate
că nu este chiar o aplicaţie XML, fiind de fapt un mecanism de transport, permite schimbul
de investiţii on-line şi informaţii personale pe Web.
Pagina 78 din 97
Vizitati www.tocilar.ro ! Arhiva online cu diplome, cursuri si referate postate de utilizatori.
• SAE J2008 este un sistem de comenzi şi inventariere bazat pe XML pentru industria
auto; MISTI, the Missile Industry Supply-chain Transaction Infrastructures, face acelaşi lucru
pentru industria spaţială.
• Chinese DTDs furnizează structura specializată necesară pentru publicarea în limba
chineză. DTD-uri similare există pentru japoneză, coreeană, vietnameză şi multe alte limbi.
• GedML, un standard XML genealogic, încurajează fluxul liber pe Web al datelor
genealogice. Există deja programe pentru conversia fişierelor standard Genealogical Data
COMmunication (GEDCOM) la GedML. Fiecare producător de browsere are standarde
propuse, despre care ceilalţi se plâng că sunt îndreptate împotriva lor. Aşa cum războaiele
browserelor au dus la dezvoltarea unor “extensii” patentate la HTML, care tindeau (sau
încercau) să blocheze celelalte browsere, creând un turn Babel de metode incompatibile,
XML va fi într-o continuă schimbare pentru o bună perioadă de timp. Totuşi, bazele există
deja, iar o comunitate de utilizatori cerând din ce în ce mai insistent standarde deschise
conduce diferitele propuneri spre convergenţă. Multe dintre succesele majore au fost
standarde ale ISO şi ANSI, care vând documentaţia pentru a-şi finanţa eforturile în crearea de
standarde, dar asigură un teren neutru pentru toţi partenerii. Pentru preţul documentaţiei, de
obicei câteva sute de dolari, toţi pot concura la acelaşi nivel.
CAPITOLUL V
PREZENTAREA APLICAŢIEI
“ElectronX” este o aplicaţie „e-commerce”, un site web ce reprezintă un magazin
virtual de electronice care se adresează tuturor persoanelor care doresc să achiziţioneze
diverse produse, în cazul de faţă electronice, prin intermediul internetului accesând un
magazin virtual din confortul propriei locuinţe, comerţul electronic mondial având o
dinamică ascendentă pe măsură ce tot mai mulţi consumatori şi tot mai multe afaceri se
conectează la web, acest tip de comerţ câştigând din ce în ce mai mult teren şi în România.
Aplicaţia se doreşte a fi o unealtă folositoare utilizatorilor, avându-se în vedere
dezvoltarea interfeţei pentru a fi user-friendly, dorindu-se a fi o aplicaţie cât mai uşor de
folosit, eventualele neajunsuri şi opinii putând fi aduse la cunoştinţa administratorului site-
ului prin adresele de e-mail puse la dispoziţia utilizatorilor în pagina de contact.
Pagina 79 din 97
Vizitati www.tocilar.ro ! Arhiva online cu diplome, cursuri si referate postate de utilizatori.
Tehnologiile folosite pentru realizarea aplicaţiei sunt PHP pentru generarea dinamică
paginilor XHTML şi interogarea bazelor de date , şi MySql pentru gestionarea bazelor de
date, totul rulând pe suportul oferit de serverul Apache.
Realizarea acestui site presupune utilizarea unei baze de date care să conţină atât date
despre utilizatori cât şi date despre produsele puse în vânzare şi date despre comenzile
efectuate de către utilizatori. Baza de date va conţine şapte tabele cuprinzând informaţiile
necesare bunei funcţionări a aplicaţiei.
5.1 Cerinţe hardware
Aplicaţia nu necesită componente hardware performante.
Cerinţele hardware pentru server sunt:
Procesor Pentium IV 2600 MHz
Memorie RAM 512 Mb
Hard Disk 120 Gb
Minimul cerinţelor hardware pentru utilizatori consta in:
Procesor Pentium III (AMD Athlon), 800 MHz
Memorie RAM 128 Mb
5.2 Cerinţe software
Cerinţele software pentru aplicaţie sunt:
Pentru server:
Wampserver 5, versiunea 1.6.4
Un editor PHP
Pentru client:
Internet Explorer 5.0 si versiunile următoare sau Mozilla Firefox 1.0.7
5.3 Funcţionalităţile aplicaţiei
La accesarea site-ului se va deschide pagina principală unde utilizatorul se va putea
autentifica prin intermediul unui nume de utilizator şi a unei parole. Dacă nu are cont îşi va
putea crea unul nou.
După autentificare utilizatorul poate să modifice datele personale sau parola
deschizându-se un formular predefinit unde se pot efectua schimbările dorite.
Utilizatorul poate să acceseze pagina de prezentare a produselor oferite de site de
unde îşi poate alege unul sau mai multe produse pentru a le cumpăra. Produsele alese vor fi
adăugate într-un coş de cumpărături acestea putând fi comandate. La trimiterea comenzii
datele utilizatorului şi produsele comandate sunt reţinute în baza de date.
Pagina 80 din 97
Vizitati www.tocilar.ro ! Arhiva online cu diplome, cursuri si referate postate de utilizatori.
Se poate de asemenea efectua o căutare după nume a produselor, fiind afişate
rezultatele căutării în baza de date.
5.4 Proiectarea bazei de date
Baza de date conţine şapte tabele.
Tabela Utilizatori conţine informaţii despre utilizatorii înregistraţi în sistem.
Tabela Itemi reţine datele despre produsele oferite la vânzare.
În tabela Caracteristici sunt reţinute caracteristicile fiecărui produs din tabela Itemi
În tabela Categorii sunt stocate datele categoriilor definite pentru ierarhia produselor.
În tabela Coş sunt reţinute produsele pe care un utilizator logat doreşte să le comande
la un moment dat. După trimiterea comenzii sau la ieşirea din cont înregistrările din această
tabelă sunt şterse.
Tabela Comenzi conţine informaţii despre toate comenzile efectuate de către
utilizatori.
Tabela Itemi_Comanda stochează datele despre produsele comandate.
Structura bazei de date este descrisă în schema conceptuală următoare:
Schema fizică a bazei de date se prezintă astfel:
Pagina 81 din 97
Vizitati www.tocilar.ro ! Arhiva online cu diplome, cursuri si referate postate de utilizatori.
Itemi Tip Nul Setare de bază Setări extra Cheie
Pagina 82 din 97
Utilizatori
Câmp
Tip N
ul
Setare de bază Setări extra Cheie
id int(11) D
a
NULL Auto_incremen
t
primară
utilizator char(60) D
a
-
parola char(60) D
a
-
nume char(30) D
a
-
prenume char(30) D
a
-
cnp varchar(13) D
a
-
varsta char(3) D
a
-
email varchar(50) D
a
-
telefon varchar(25) D
a
-
adresa varchar(255
)
D
a
-
sector varchar(2) D
a
-
cod_post
al
varchar(10) D
a
-
oras char(30) D
a
-
judet varchar(25) D
a
-
Vizitati www.tocilar.ro ! Arhiva online cu diplome, cursuri si referate postate de utilizatori.
Câmp
item_id int(11) Da NULL Auto_increment Primara
cat_id int(11) Da -
nume_item varchar(75) Da -
Prêt float(8,2) Da -
descriere varchar(200) Da -
imagine varchar(50) Da -
Caracteristici
Câmp
Tip Nul Setare de
bază
Setări extra Cheie
Id_item int(11) Da -
producator varchar(25) Da -
Model varchar(25) Da -
Categorii
Câmp
Tip Nul Setare de bază Setări extra Cheie
cat_id int(11) Da NULL Auto_increment primară
nume_cat varchar(50) Da -
desc_cat varchar(200) Da -
Coş
Câmp
Tip Nul Setare de bază Setări extra Cheie
Id int(11) Da NULL Auto_increment primara
Id_sesiune char(60) Da -
Id_item_v int(11) Da -
Cant int(11) Da -
producator varchar(25) Da -
Model varchar(25) Da -
data_ad datetime Da -
Comenzi
Câmp
Tip Nul Setare de
bază
Setări extra Cheie
id_c Int(11) Da NULL Auto_increment primara
Pagina 83 din 97
Vizitati www.tocilar.ro ! Arhiva online cu diplome, cursuri si referate postate de utilizatori.
data_c datetime Da -
Nume_c varchar(100) Da -
adresa varchar(255) Da -
Oras varchar(50) Da -
cod_postal varchar(10) Da -
Judet varchar(25) Da -
sector varchar(2) Da -
valoare float(8,2) Da -
mod_plata varchar(20) Da -
Status enum('procesata',
'asteptare')
Da -
Itemi_comanda
Câmp
Tip Nul Setare de bază Setări extra Cheie
Id int(11) Da NULL Auto_increment primară
Id_comanda int(11) Da
Id_item int(11) Da
Cant int(11) Da
producator varchar(25) Da
Model varchar(25) Da
Prêt float(8,2) Da
5.5 Implementarea codului
După crearea bazei de date, următorul pas este generarea paginilor web ale aplicaţiei
folosind codul HTML/PHP.
Pentru editarea codului am folosit utilitarul PHPEdit versiunea 2.10.0.4616 dezvoltate
de compania WaterProof Software, acest utilitar putând fi descărcat de pe internet de la
adresa http://www.waterproof.fr/ cu o licenţă de utilizare gratuită pe o perioada de 30 de zile.
Acest editor de cod este destinat în special creării scripturilor PHP oferind suport şi pentru
alte limbaje: HTML, CSS, XML, XSLT, Javascript, SQL.
Sistemul complet are două tipuri de componente: fişiere HTML şi fişiere PHP.
Interfaţa aplicaţiei este realizată cu ajutorul paginilor HTLM, iar scripturile PHP gestionează
interacţiunea dintre paginile HTML şi baza de date prin intermediul serverului Apache.
Pagina 84 din 97
Vizitati www.tocilar.ro ! Arhiva online cu diplome, cursuri si referate postate de utilizatori.
Inregistrare.php
Atunci când un client nou doreşte să achiziţioneze unul din produsele oferite de siteul
„ElectronX” trebuie să îşi creeze mai întâi un cont de utilizare. Clientul trebuie să introducă
datele personale (nume, prenume, CNP, vârsta, adresa de e-mail, telefon, adresă, oraş, judeţ )
într-un formular, precum şi un nume de utilizator şi o parolă. Datele vor fi folosite
înregistrarea comenzilor şi pentru a deţine o evidenţă a utilizatorilor site-ului. Contul nu va fi
creat dacă nu sunt completate toate câmpurile considerate obligatorii. După inserarea datelor
în tabela Utilizatori se creează şi fişierul clienţi.xml în care sunt stocate toate datele clienţilor
înregistraţi în baza de date.
$_SESSION['user'] = $_POST['user'];
$_SESSION['parola1'] = $_POST['parola1'];
$_SESSION['parola2'] = $_POST['parola2'];
$_SESSION['nume'] = $_POST['nume'];
$_SESSION['prenume'] = $_POST['prenume'];
$_SESSION['cnp'] = $_POST['cnp'];
$_SESSION['varsta'] = $_POST['varsta'];
$_SESSION['email'] = $_POST['email'];
$_SESSION['telefon'] = $_POST['telefon'];
$_SESSION['adresa'] = $_POST['adresa'];
$_SESSION['sector'] = $_POST['sector'];
$_SESSION['cod_postal'] = $_POST['cod_postal'];
$_SESSION['oras'] = $_POST['oras'];
$_SESSION['judet'] = $_POST['judet'];
if(($_SESSION['user'] == '') || ($_SESSION['parola1'] == '') ||
($_SESSION['parola2'] != $_SESSION['parola1']) || ($_SESSION['nume'] == '')
|| ($_SESSION['prenume'] == '') || ($_SESSION['varsta'] == '') ||
(!is_numeric($_SESSION['varsta'])) || (strlen($_SESSION['varsta']) < 2) ||
($_SESSION['cnp'] == '') ||($_SESSION['email'] == '') || ($_SESSION['telefon'] == '')
||
($_SESSION['adresa'] == '') || ($_SESSION['oras'] == ''))
{
Pagina 85 din 97
Vizitati www.tocilar.ro ! Arhiva online cu diplome, cursuri si referate postate de utilizatori.
echo '<html>
<head></head>
<body text="#1A1A8C">
<font color="#C9003F" size="+3">Eroare!</font><br><br>
<center><font size="+1">Nu ai introdus date in formular sau cele introduse nu sunt
corecte. <br>
Apasa <a href="inregistrare.php">aici</a> pentru a te intoarce la pagina
anterioara.</font></center>
</body>
</html>';
}
else
{
echo '<html>
<head></head>
<body text="#1A1A8C">
<br><br><br>
<center><font size="+1">Va multumim. <br>
Datele au fost introduse cu succes in baza de date. <br>
Pentru a va autentifica apasati <a href= "autentificare.php"> aici
</a>.</font></center>
</body>
</html>';
$cerereSQL = "INSERT INTO `utilizatori` (`utilizator`, `parola`, `nume`, `prenume`,
`cnp`,
`email`, `telefon`, `varsta`, `adresa`, `sector`, `cod_postal`, `oras`, `judet`)
VALUES ('".addentities($_SESSION['user'])."', ' " .md5($_SESSION['parola1'])." ',
'".addentities($_SESSION['nume'])."', '".addentities($_SESSION['prenume'])."',
'".addentities($_SESSION['cnp'])."', '".addentities($_SESSION['email'])."',
'".addentities($_SESSION['telefon'])."', '".addentities($_SESSION['varsta'])."',
'".addentities($_SESSION['adresa'])."', '".addentities($_SESSION['sector'])."',
'".addentities($_SESSION['cod_postal'])."', '".addentities($_SESSION['oras'])."',
'".addentities($_SESSION['judet'])."')";
Pagina 86 din 97
Vizitati www.tocilar.ro ! Arhiva online cu diplome, cursuri si referate postate de utilizatori.
mysql_query($cerereSQL);
Autentificare.php
Odată ce contul de utilizare a fost creat utilizatorul trebuie sa se autentifice pentru a
avea acces la paginile de administrare a contului personal, pentru a putea face comenzi. În
acest script se verifică existenţa numelui de utilizator în baza de date şi corectitudinea parolei,
şi în caz de eroare, aceasta se semnalează. Autentificarea se realizează prin intermediul
sesiunilor, reţinându-se pentru fiecare utilizator o instanţă unică de sesiune.
$_SESSION['user'] = $_POST['user'];
if(($_POST['user'] == '') || ($_POST['parola'] == ''))
{
echo '<html>
<head></head>
<body text="#1A1A8C">
<br><br><center><font size=+1>Pentru a va accesa contul trebuie sa completati
casutele. <Br>
Apasati <a href="autentificare.php">aici</a> pentru a va intoarce la pagina
precedenta.
</font></center>
</body>
</html>';
}
else
{
$cerereSQL = "SELECT * FROM `utilizatori` WHERE utilizator='
".htmlentities($_POST['user'])."' AND parola=' ". md5($_POST['parola'])."'";
$rezultat = mysql_query($cerereSQL);
if(mysql_num_rows($rezultat) == 1)
{
while($rand = mysql_fetch_array($rezultat))
{
$_SESSION['logat'] = 'Da';
echo '<META HTTP-EQUIV=Refresh CONTENT="0; URL=pagina.php">';
Pagina 87 din 97
Vizitati www.tocilar.ro ! Arhiva online cu diplome, cursuri si referate postate de utilizatori.
}
}
else
{
echo '<html>
<head></head>
<body text="#1A1A8C">
<font color="#C9003F" size="+3">Eroare!</font><br><br>
<center><Br> <font size=+1>Date incorecte. <Br>
Apasati <a href="autentificare.php">aici</a> pentru a va intoarce la pagina
precedenta.
</font>
</center>
</body>
</html>';
Pagina.php
După ce utilizatorul s-a autentificat se deschide pagina de administrare a contului de
utilizare. În acest script utilizatorul are la dispoziţie mai multe opţiuni: modificarea datelor
personale, modificarea parolei, sunt afişate toate comenzile trimise de către utilizator, şi poate
accesa unul din link-urile care duc către paginile de prezentare a produselor, afişare a
statisticilor vânzărilor, afişare a coşului de cumpărături sau pentru ieşirea din cont.
Vezimagazin.php
În acest script sunt prezentate toate categoriile şi toate produsele existente în baza de
date. La deschiderea paginii apare o listă de link-uri cu toate categoriile de produse, iar dacă
utilizatorul selectează o categorie se vor afişa toate produsele din acea categorie, pentru
fiecare dintre acestea afişându-se numele, preţul şi o mică imagine de prezentare.
$get_cats = "select cat_id, nume_cat, desc_cat from categorii order by nume_cat";
$get_cats_res = mysql_query($get_cats) or die(mysql_error()) ;
if (mysql_num_rows($get_cats_res)<1) {
$display_block = "<p> <em> Nu exista categorii de vizualizat </em> </p>";
Pagina 88 din 97
Vizitati www.tocilar.ro ! Arhiva online cu diplome, cursuri si referate postate de utilizatori.
} else {
while($cats = mysql_fetch_array($get_cats_res)){
$cat_id = $cats[cat_id];
$cat_title = strtoupper(stripslashes($cats[nume_cat]));
$cat_desc = stripslashes($cats[desc_cat]);
$display_block .= "<p><strong>
<a href=\"$_SERVER[PHP_SELF]?cat_id= $cat_id\"> $cat_title </a></strong>
<br> $cat_desc </p>";
if ($_GET[cat_id] == $cat_id) {
$get_items = "select item_id, nume_item, pret, imagine from itemi where
cat_id=$cat_id order by nume_item"; $get_items_res = mysql_query($get_items) or
die(mysql_error());
if (mysql_num_rows($get_items_res) <1) {
$display_block = "<p> <em> Nu exista produse in aceasta categorie </em> </p>";
} else {
$display_block .= "<ul>";
while($items = mysql_fetch_array($get_items_res)) {
$item_id = $items[item_id];
$item_title = stripslashes($items[nume_item]);
$item_price = $items[pret];
$item_image = $items[imagine];
$display_block .= " <li>
<table border=1 width=50%>
<tr>
<th><a href=\"showitem.php?item_id=$item_id\"> $item_title</a></th>
</tr>
<tr>
<th height=180 width=180><img src=\"$item_image\" alt=\"poza\" border=0></th>
</tr>
<tr>
<th>$item_price RON (Pretul contine TVA)</th>
</tr>
<tr>
<th><a href=\"showitem.php?item_id=$item_id\"> Cumpara acest produs</a></th>
Pagina 89 din 97
Vizitati www.tocilar.ro ! Arhiva online cu diplome, cursuri si referate postate de utilizatori.
</tr>
</table><br>";
}
$display_block .= "</ul>";
}
}
}
}
Arataprodus.php
Pagina de afişare a produselor nu face decât sa afişeze toate informaţiile referitoare la
câte un produs. Aceste informaţii sunt introduse automat într-un formular. În acest formular
utilizatorul mai poate să aleagă numărul produselor pe care doreşte să le comande şi apoi
dacă doreşte să-l adauge la coş trebuie să apese pe butonul „Adaugă la coş”.
Aratacos.php
În această pagină este prezentat conţinutul coşului de cumpărături. Produsele existente
în coş sunt afişate într-un tabel, pentru fiecare fiind afişate numele, producătorul, modelul,
preţul, cantitatea, preţul total şi un link pentru scoaterea produsului respectiv din coş. Pe
pagină mai sunt prezente valoarea totală a produselor adăugate în coş şi link-urile către
pagina de afişare a produselor şi către pagina de comandă.
Comanda.php
Pagina de comandă conţine un formular în care sunt afişate numele, prenumele, CNP-
ul utilizatorului, adresa, oraşul, judeţul, aceste câmpuri putând fi modificate în cazul în care
utilizatorul doreşte livrarea comenzii la o altă adresa decât cea din cont şi valoarea totală a
comenzii. La apăsarea butonului „Trimite comanda” se inserează în tabela comenzi datele
despre comandă, iar în tabela itemi_comanda se inserează produsele comandate. După
inserarea datelor în tabele se creează fişierul comenzi.xml în care sunt stocate toate comenzile
din tabelă.
if(!isset($_POST['adresa'])) $_SESSION['adresa'] = '';
else $_SESSION['adresa'] = $_POST['adresa'];
if(!isset($_POST['sector'])) $_SESSION['sector'] = '';
Pagina 90 din 97
Vizitati www.tocilar.ro ! Arhiva online cu diplome, cursuri si referate postate de utilizatori.
else $_SESSION['sector'] = $_POST['sector'];
if(!isset($_POST['cod_postal'])) $_SESSION['cod_postal'] = '';
else $_SESSION['cod_postal'] = $_POST['cod_postal'];
if(!isset($_POST['oras'])) $_SESSION['oras'] = '';
else $_SESSION['oras'] = $_POST['oras'];
if(!isset($_POST['judet'])) $_SESSION['judet'] = '';
else $_SESSION['judet'] = $_POST['judet'];
if(($_SESSION['adresa'] == '') || ($_SESSION['oras'] == ''))
{
echo '<html>
<head></head>
<body text="#1A1A8C">
<center><h4>Nu ai introdus noua adresa de livrare sau orasul. <br>
Apasa <a href="comanda.php">aici</a> pentru a te intoarce la pagina
anterioara.</h4></center>
</body>
</html>';
}
else
{
echo '<html>
<head></head>
<body text="#1A1A8C">
<center><h4>Va multumim. <br>
Comanda a fost trimisa cu succes. <br>
Inapoi la magazin <a href="seestore.php">aici</a>.</h4></center>
</body>
</html>';
$cerereSQL = "INSERT INTO `comenzi` (`data_c`, `nume_c`, `adresa`, `oras`,
`cod_postal`,
`judet`, `sector`, `valoare`, `mod_plata`, `status`)
VALUES (now(), '".addentities($_SESSION['user'])."',
'".addentities($_SESSION['adresa'])."', '".addentities($_SESSION['oras'])."',
'".addentities($_SESSION['cod_postal'])."', '".addentities($_SESSION['judet'])."',
Pagina 91 din 97
Vizitati www.tocilar.ro ! Arhiva online cu diplome, cursuri si referate postate de utilizatori.
'".addentities($_SESSION['sector'])."',
'".addentities($_SESSION['afis_price_prod'])."',
'".$_POST['plata']."', 'asteptare' )";
mysql_query($cerereSQL);
$cid=mysql_insert_id();
$cerereSQL1 = "SELECT cos.id_sesiune, cos.id_item_v, cos.cant, cos.producator,
cos.model, itemi.item_id, itemi.pret FROM cos left join itemi on cos.id_item_v =
itemi.item_id WHERE id_sesiune ='$_SESSION[user]'";
$rezultat1 = mysql_query($cerereSQL1);
while($rand1 = mysql_fetch_array($rezultat1))
{
$cidit=$rand1['id_item_v'];
$ccant=$rand1['cant'];
$cproducator=$rand1['producator'];
$cmodel=$rand1['model'];
$cpret=$rand1['pret'];
$cerereSQL = "insert into itemi_comanda ( id_comanda, id_item, cant,
producator,model, pret ) values ( '$cid', '$cidit', '$ccant',
'$cproducator', '$cmodel', '$cpret' )";
mysql_query($cerereSQL);
}
$cerereSQL2 = "delete from cos where id_sesiune='$_SESSION[user]'";
mysql_query($cerereSQL2) or die(mysql_error());
}
5.6 Manual de utilizare
Această secţiune are drept scop prezentarea modului de interacţionare al utilizatorului
cu aplicaţia.
La accesarea site-ului se va deschide pagina principală unde utilizatorul are doua
posibilităţi:
Dacă are un cont creat va accesa link-iul care trimite la pagina de autentificare.
În cazul în care nu are un cont trebuie să acceseze link-ul de înregistrare care va
deschide o pagina ce conţine un formular de înscriere.
Pagina 92 din 97
Vizitati www.tocilar.ro ! Arhiva online cu diplome, cursuri si referate postate de utilizatori.
De asemenea pe aceasta pagina, ca de altfel pe toate paginile aplicaţiei, există mai
multe secţiuni:
1. Un meniu cu următoarele link-uri:
Home – face legătura cu pagina principală
Contul meu – deschide pagina de administrare a contului personal
Produse – sunt afişate categoriile şi produsele existente în baza de date
Coşul de cumpărături – conţine produsele adăugate în coş de către utilizator
Statistici vânzări – sunt prezentate vânzările totale şi pe categorii în termen de o
săptămâna şi o lună, precum şi cel mai bine vândute produse din fiecare categorie şi categoria
cu cele mai mari vânzări
Contact – sunt prezentate opţiunile de a lua legătura cu sediul societăţii
Termeni şi condiţii – conţine drepturile şi obligaţiile utilizatorilor si societăţii
Ieşire din cont – dezautentificarea utilizatorului
2. O secţiune de căutare unde utilizatorul poate să introducă unul sau mai multe
cuvinte ce vor fi căutate în baza de date
3. O secţiune în care sunt afişate toate categoriile de produse
4. O secţiune ce conţine un top ale celor mai vândute cinci produse din magazin
Pentru crearea unui cont trebuie accesat link-ul de înregistrare şi se va deschide o
pagina cu un formular de înscriere. Apoi utilizatorul va completa datele cerute şi va apăsa
butonul Înregistrează. Astfel se va crea un cont şi se va confirma înregistrarea contului,
afişându-se şi un link către pagina de autentificare. În cazul în care nu mai doreşte înscrierea
va apăsa butonul Resetează pentru a şterge toate informaţiile introduse.
La pagina de autentificare utilizatorul trebuie să introducă numele de utilizator
şi parola. După aceasta trebuie să apese butonul Login şi se va deschide pagina „Contul meu”
unde utilizatorul va putea modifica datele personale sau parola, va putea vizualiza
Pagina 93 din 97
Vizitati www.tocilar.ro ! Arhiva online cu diplome, cursuri si referate postate de utilizatori.
produ
sele, coşul de cumpărături şi va vizualiza comenzile efectuate de el anterior.
În pagina de prezentare a produselor sunt afişate toate categoriile şi toate produsele
existente în magazin. Pe pagină apare o listă de link-uri cu toate categoriile de produse. La
selectarea unei categorii se vor afişa toate produsele din acea categorie, pentru fiecare dintre
acestea afişându-se numele, preţul şi o mică imagine de prezentare.
Pentru a vizualiza un produs se apasă fie pe numele produsului fie pe link-ul
„Cumpără acest produs” şi se va deschide pagina de prezentare a produselor care afişează
toate informaţiile referitoare la câte un produs. Utilizatorul mai poate să aleagă numărul
produselor pe care doreşte să le comande şi apoi dacă doreşte să-l adauge la coş trebuie să
apese pe butonul „Adaugă la coş”.
Pagina 94 din 97
Vizitati www.tocilar.ro ! Arhiva online cu diplome, cursuri si referate postate de utilizatori.
În pagina de vizualizare a coşului de cumpărături este prezentat conţinutul acestuia.
Produsele existente în coş sunt afişate într-un tabel, pentru fiecare fiind afişate numele,
producătorul, modelul, preţul, cantitatea, preţul total şi un link pentru scoaterea produsului
respectiv din coş. Pe pagină mai sunt afişate valoarea totală a produselor adăugate în coş şi
link-urile către pagina de afişare a produselor şi către pagina de comandă.
Pagina 95 din 97
Vizitati www.tocilar.ro ! Arhiva online cu diplome, cursuri si referate postate de utilizatori.
Pentru a comanda produsele din cont se apasă butonul de comanda şi se va deschide
pagina de comandă în care sunt afişate numele, prenumele, CNP-ul utilizatorului, adresa,
oraşul, judeţul, aceste câmpuri putând fi modificate de către utilizator dacă acesta doreşte
livrarea la altă adresă şi valoarea totală a comenzii şi apoi va apăsa pe butonul „Trimite
Comanda” după care utilizatorul va primi confirmarea înregistrării comenzii.
5.7 Concluzii
Odată cu începuturile Internetului un nou tip de afacere s-a profilat din ce în ce mai
pronunţat pe plan internaţional: comerţul online. Au apărut nenumărate site-uri şi firme care
se ocupă cu vânzările en-gros de produse prin Internet, cu furnizarea accesului contracost la
pagini cu informaţii, într-un cuvânt abordează o formă sau alta de comerţ electronic, un
domeniu aflat în plină expansiune. Avantajul comerţului online este evident: piaţa pe Internet
creşte exponenţial de la un an la altul. Un site bine lucrat, cunoscut şi care oferă produse de
calitate la preţuri bune va avea mai mulţi vizitatori, mai motivaţi şi mai înzestraţi financiar
decât multe magazine convenţionale.
Având în vedere proiectarea, implementarea şi testarea acestui tip de aplicaţii
resursele de hardware, software, de timp, cele umane şi cele materiale sunt reduse, şi în
acelaşi timp această aplicaţie are un potenţial mare de succes.
Pagina 96 din 97
Vizitati www.tocilar.ro ! Arhiva online cu diplome, cursuri si referate postate de utilizatori.
Aplicaţia „ElectronX” are ca scop prezentarea unui model de magazin virtual care să
conţină funcţionalităţile de bază specifice unei aplicaţii de acest gen: gestionarea conturilor
unui utilizator, prezentarea categoriilor şi produselor, căutarea în baza de date, adăugarea
produselor într-un coş de cumpărături, trimiterea comenzilor. Aceste funcţionalităţi pot fi
îmbunătăţite şi de asemenea pot fi adăugate şi altele atât la nivelul aspectului interfeţei cât şi
la nivelul operaţiilor ce pot fi efectuate astfel încât să asigure o funcţionare optimă a site-ului.
Dezvoltarea fără precedent din ultimele două decenii a tehnologiilor informaţionale
determinate de necesitatea stocării şi a transmiterii rapide a informaţiilor cu cele mai mici
costuri, a revoluţionat comerţul global, comerţul direct sau cu amănuntul.
Pagina 97 din 97