Lucrare Aplicatii Ale Xml In Baze De Date

  • Nota 10.00
  • 0 comentarii
  • Publicat pe 07 August 2021

Descriere Lucrare

EXTRAS DIN DOCUMENT

        NOI MODELE DE DATE ŞI APLICAŢIILE LOR
        1.1 Interogarea World-Wide-Web-ului 
    Există surse de date, ca de pildă World-Wide-Web-ul, pe care am dori să le interogăm ca baze de date, dar care nu pot fi constrânse de o schemă. Majoritatea interogărilor web-ului folosesc tehnici de regăsire a informaţiei pentru a găsi pagini după conţinut. Există însă puţine posibilităţi de formulare a interogărilor în vederea exploatării structurii web-ului şi, deoarece aceasta nu este conformă cu nici un model de date standard, este necesară o metodă de descriere a acestei structuri. 
    Modelul de date semistructurat a fost propus în vederea satisfacerii acestei necesităţi. Ideea centrală în modelul semistructurat este de a reprezenta datele sub forma unui graf etichetat. Structura documentelor hipertext este capturată interpretând arcele grafului drept legături. O reprezentare posibilă este cea introdusă în proiectul UnQL[1]. Etichetele arcurilor pot fi atât valori (de tip întreg, şir de caractere şi alte tipuri de bază, precum şi de tip de date abstract, ca video, audio, etc.) cât şi nume de atribute (Film, Titlu, Regizor, Actor), etc. modelând de exemplu cunoscuta bază de date cinematografică IMDB [2]. 
    Există numeroase limbaje de interogare pentru modelul semistructurat. Toate aceste limbaje sunt construite pe baza ideii de expresii asociate căilor (path expressions).     Acestea sunt expresii regulate ce exprimă căi generice în graful etichetat, permiţând astfel traversarea grafului şi colecţionarea tuturor etichetelor ce satisfac o anumită condiţie de selecţie. 
    Limbajele semistructurate pot fi clasificate în două categorii, după strategia de calcul adoptată. Prima categorie, dezvoltată oarecum ad-hoc, se bazează pe modelarea grafurilor în modelul relaţional şi apoi pe interogarea lor într-un limbaj relaţional de tip SQL. Câteva exemple prezentate în literatură sunt [3], [4], [5], [6], [7] 
    A doua categorie porneşte de la un limbaj bazat pe o noţiune formală de calcul cu date semistructurate: limbajul UnQL este reprezentantul acestei categorii [1]. Acest limbaj porneşte de la recursivitatea structurală, forma naturală de recursivitate asociată cu tipul de date grafuri etichetate. Datorită bazei sale teoretice, UnQL este capabil de restructurări complexe, în adâncime, spre deosebire de limbajele din prima categorie, care se limitează la scoaterea la suprafaţă a datelor din graf, fără însă a crea noi structuri. 
    Această capacitate de restructurare stă la baza proiectului STRUDEL[8] care propune limbajul StruQL de gestiune a sit-urilor de web. Un alt avantaj al bazei teoretice a limbajelor UnQL şi StruQL este posibilitatea efectuării optimizărilor specifice acestui nou model de date. Limbajele din prima categorie pot beneficia doar de optimizările specifice modelului relaţional, deci dezvoltate pentru alt model de date şi în consecinţă nu atât de folositoare. 
        1.2 Integrarea surselor de date eterogene
    Integrarea datelor provenind din surse eterogene (cu scheme disparate sau, mai grav, modelate diferit), este un domeniu de cercetare care, deşi consacrat de mai bine de un deceniu, continuă să rămână în centrul atenţiei multor cercetători. Cercetarea în acest domeniu este motivată de absenţa unui model de date atotcuprinzător, fapt ce îngreunează dezvoltarea de software care converteşte date între două modele diferite.
    O complicaţie adiţională este reprezentată de faptul că majoritatea datelor stocate electronic nu se află în baze de date convenţionale, ci în sisteme de fişiere, programe de bibliotecă, de poştă electronică, foi de calcul etc., care prezintă capacităţi de interogare limitate.
    Ultima observaţie a reprezentat punctul de plecare al proiectului Tsimmis [9][10] de la Stanford. Proiectul Tsimmis îşi propune integrarea atât a surselor de date care sunt conforme cu modelele de date standard (relaţional, orientat pe obiecte), cât şi a surselor de date cu capacităţi de interogare limitate. Aceste surse neconvenţionale sunt împachetate în aşa-numiţi wrappers (ambalaje). Un astfel de ambalaj asigură interfaţa între sursa de date cu capacităţi de interogare limitate şi aplicaţia care o interoghează. Aplicaţia trimite către sursă interogări într-un limbaj expresiv cum ar fi SQL sau OQL şi aşteaptă rezultatul într-un format numit OEM (Object Exchange Model). 
    OEM foloseşte grafuri etichetate, ca structură de date, care capturează majoritatea datelor folosite în aplicaţii de baze de date. În acelaşi timp, toate celelalte structuri de date pot fi codificate ca grafuri OEM.
Rolul ambalajului constă în: interceptarea interogării şi identificarea acelor părţi ale acesteia care pot fi efectuate de către sursă, translatarea acestor părţi în limbajul specific sursei, recepţionarea şi prelucrarea rezultatelor intermediare în vederea reconstituirii rezultatului interogării originale, codificarea rezultatului final în formatul OEM şi transmiterea acestuia către aplicaţie.
    Evident, dacă interogarea originală este prea complexă, este posibil să nu poată fi efectuată pornind de la capabilităţile limitate ale sursei. Ambalajul detectează această situaţie şi anunţă sursa că nu îi poate satisface cererea. Cu cât creşte capacitatea de evaluare a interogărilor în cadrul ambalajului (de exemplu, capacitatea de a efectua operaţii de tip join, proiecţii, selecţii, etc.), cu atât se extinde clasa de interogări pe care le poate satisface combinaţia sursă-ambalaj.
Un proiect similar, cu scopul interogării surselor de date structurate din web este [13].
Se remarcă similaritatea dintre modelul OEM şi cel semistructurat. Într-adevăr, Lore [11],[12] este un sistem de interogare a datelor semistructurate, foarte similar cu UnQL, utilizând un model de date inspirat de OEM.
        1.3 Navigare în Internet 
    În anumite situaţii este avantajos să privim bazele de date convenţionale ca fiind semistructurate. Un exemplu este activitatea de navigare în Internet. 
    În general, utilizatorul nu poate interoga o bază de date fără a-i cunoaşte schema.     Din nefericire însă, aceasta este adeseori greu de înţeles, datorită mărimii exagerate (zeci de tabele, de exemplu) şi a terminologiei opace, nestandard, folosite de către proiectanţii bazei de date.
    Descifrarea schemei ar fi considerabil uşurată de facilitatea de a interoga datele având doar o înţelegere parţială a structurii lor. De exemplu, în cazul bazei de date cinematografice din World-Wide Web[2], următoarele interogări ar fi de folos:
  • În care atribut găsim şirul de caractere Casablanca?
  • Există în baza de date întregi mai mari decât 216?
  • Ce obiecte din baza de date au un atribut al cărui nume începe cu act?
    Şi în acest domeniu, modelul semistructurat se dovedeşte a fi folositor. Spre deosebire de modelele de date convenţionale, care diferenţiază între schema (tipul, structura) şi instanţa (valoarea) datelor, modelul de date semistructurat reprezintă cele două tipuri de informaţie în mod uniform, permiţând interogarea lor simultană. Din acest motiv, datele semi-structurate se numesc şi autodescriptive.
[1] prezintă un elegant limbaj de interogare care permite exprimarea concisă a acestor interogări.
        1.4 Cubul de date şi OLAP
    Sistemele de suport pentru decizii (Decision support systems) sunt utilizate de către companiile moderne pentru integrarea într-o bază de date centrală numită data warehouse (magazia centrală de date), a datelor provenind din baze de date mici operaţionale folosite în diferite domenii de activitate/filiale ale companiei.
    Datele astfel acumulate sunt analizate în timp real (OLAP: On-Line Analitical Processing) pentru a asista conducerea companiei în luarea deciziilor strategice de dezvoltare [14] (de exemplu, analizând vânzările unui anumit produs pe trimestru şi zonă geografică, se poate stabili o nouă strategie de marketing pentru acest produs).     Datele din magazia centrală de date sunt modelate sub forma unui (hiper)cub de date multidimensional [15]) care poate fi analizat la nivelul subcuburilor de granularitate arbitrară. Subcuburile se obţin prin agregarea cuburilor din care provin.
    De exemplu, prin însumarea vânzărilor trimestriale pentru fiecare zonă, cubul de date tridimensional reprezentând vânzările pe trimestru şi zona geografică poate fi redus la un subcub bidimensional (plan) reprezentând vânzările pe zona geografică.     Agregarea este o operaţie costisitoare, efectuarea ei eficientă pe un volum mare de date reprezentând ţelul principal al cercetării în acest domeniu ([16],[17],[18],[19]).
        1.5 Noi modele tranzacţionale
    În mod tradiţional, tranzacţiile modelează unităţi de lucru atomice şi izolate, efectuate asupra datelor sistemului de gestiune a bazelor de date.
    Izolarea tranzacţiilor nu permite crearea tranzacţiilor complexe, mari, din tranzacţii simple. Acest model a avut succes atâta vreme cât tranzacţiile efectuau un număr mic de operaţii simple asupra datelor cu structură simplă.
    Din păcate, modelul tranzacţiilor simple nu satisface cerinţele aplicaţiilor complexe, în care tranzacţiile trebuiesc combinate şi coordonate pentru a colabora la realizarea unui scop complex. Aplicaţii ca proiectarea asistată de calculator, automatizarea activităţii de birou, controlul producţiei, gestiunea activităţilor necesită noi modele tranzacţionale, noi metode de gestiune a tranzacţiilor, şi noi limbaje de specificare a tranzacţiilor. Limbajele tranzacţionale sunt limbaje de nivel înalt, de obicei inspirate din logica cu predicate de ordinul întâi.
    Dacă limbajele tradiţionale specificau interogări şi actualizări, noile limbaje tranzacţionale se concentrează asupra relaţiei dintre tranzacţii, exprimând dependenţe de tipul tranzacţia T2 nu poate porni înainte ca T1 să se termine, sau T2 poate începe dacă T1 întoarce o valoare mai mare ca 25. [20] prezintă o clasificare şi analiza detailată a noilor limbaje tranzacţionale.
    Un excelent exponent al noii generaţii de limbaje tranzacţionale este Transaction Datalog [21], un limbaj deductiv care menţine în acelaşi timp toate proprietăţile tranzacţiilor clasice, cum ar fi: persistenţă, atomicitate, izolare, terminare şi rollback (revenire).
    Limbajul este însoţit de un model teoretic natural şi de o teorie sigură pentru demonstraţii, permiţând astfel demonstrarea echivalenţei între diverse expresii din acest limbaj. Acest fapt este crucial pentru optimizare - care constă din înlocuirea unei planificări cu o alta echivalentă din punct de vedere al efectului său asupra datelor, dar mai eficientă din punct de vedere al costului execuţiei. Mai mult, faptul că putem demonstra că efectul unei tranzacţii complexe asupra setului de date este sau nu cel scontat, asigură consistenţa datelor. 
        1.6 Optimizări
    Optimizarea limbajelor de interogare a bazelor de date nu este un domeniu nou, ci dimpotrivă, există încă de la apariţia acestora. Datorită importanţei sale, acest domeniu va fi întotdeauna la modă în cercetarea bazelor de date.
    Apariţia unui nou model de date atrage după sine o efervescenţă în activitatea de cercetare a posibilităţilor de optimizare a limbajului de interogare asociat noului model. Referinţele bibliografice introduse în secţiunea anterioară prezintă şi primele încercări de optimizare a noilor limbaje de interogare.

CUPRINS

INTRODUCERE 3
CAPITOLUL I 5
NOI MODELE DE DATE ŞI APLICATIILE LOR 5
1.1 INTEROGAREA WORLD-WIDE-WEB-ULUI 5
1.2 INTEGRAREA SURSELOR DE DATE ETEROGENE 6
1.3 NAVIGARE ÎN INTERNET 7
1.4 CUBUL DE DATE ŞI OLAP 8
1.5 NOI MODELE TRANZACTIONALE 8
1.6 OPTIMIZĂRI 9
CAPITOLUL II 12
MODELE DE REPREZENTARE A DATELOR NECONVENTIONALE 12
2.1 DEFINIREA CONCEPTULUI DE DATE NECONVENTIONALE 12
2.2 MODELUL SEMISTRUCTURAT ALE DATELOR 13
2.2.1 Conceptul de date semistructurate 15
2.2.2 Modelarea datelor semistructurate 16
2.2.3 Limbaje de interogare a datelor semistructurate 18
2.3 MPEG-21 – SUPORT PENTRU INTEGRAREA DATELOR ÎN APLICATII MULTIMEDIA DISTRIBUITE 19
2.3.1 Prezentare generală 19
2.3.2 Declararea elementelor digitale 22
2.3.3 Adaptarea continutului utilizând MPEG-21 26
CAPITOLUL III 29
XML CA BAZĂ DE DATE 29
3.1 ESTE XML-UL O BAZĂ DE DATE? 29
3.2 DATE ŞI DOCUMENTE 29
3.2.1 Documente centrate pe date 30
3.2.2 Informatii centrate pe documente 32
3.2.3 Date, documente şi baze de date 33
3.3 STOCAREA ŞI RECUPERAREA DATELOR 33
3.3.1 Maparea schemelor documentelor pe schemele bazelor de date 34
3.3.2 Limbaje de interogare 37
3.3.3 Stocarea datelor în baze de date native XML 40
3.3.4 Tipuri de date, valori nule, seturi de caractere 41
3.3.5  Generarea schemelor XML din scheme relationale şi invers 44
3.4 STOCAREA ŞI RECUPERAREA DOCUMENTELOR 47
3.4.1 Stocarea documentelor în sistemul de fişiere 47
3.4.2 Stocarea documentelor în BLOB-uri 47
3.4.3 Baze de date native XML 48
3.4.4 DOM-uri persistente (PDOM-uri) 62
3.4.5 Sisteme de management ale continuturilor 63
CAPITOLUL IV 64
CONSTRUIREA DOCUMENTELOR XML 64
4.1 SINTAXA XML 64
4.2 DESCRIEREA DE VOCABULARE NOI CU XML 64
4.3 AVANTAJELE DEFINITIEI TIPURILOR DOCUMENTULUI 65
4.4 COMBATEREA DEZAVANTAJELOR DEFINITIEI TIPURILOR DOCUMENTULUI 66
4.5 XML, DOAR UN ALT HTML? 67
4.6 STARTUL ÎN XML 69
4.7 DEFINIREA UNUI DOCUMENT XML CA ÎNTREG 70
4.8 PROLOGUL: DECLARATIA XML 74
4.9 DOCUMENTE AUTONOME 74
4.10 CONSTRUIREA PROLOGULUI UNUI DOCUMENT XML: DECLARATIA TIPULUI DOCUMENTULUI (DOCUMENT TYPE DECLARATION) 75
4.10.1 Crearea corpului documentului 76
4.10.2 Date caracter 76
4.10.3 Marcajul 77
4.10.4 Formarea structurilor logice în XML 77
4.10.5 Cum formează XML structurile fizice 78
4.10.6 Etichete de pornire şi etichete de încheiere 78
4.10.7 Normalizarea 79
4.10.8 Tipuri de elemente 81
4.10.9 Entităti neanalizate 82
4.10.10 Aplicatii din lumea reală 84
CAPITOLUL V 87
PREZENTAREA  APLICATIEI 87
5.1 CERINTE HARDWARE 87
5.2 CERINTE SOFTWARE 88
5.3 FUNCTIONALITĂTILE APLICATIEI 88
5.4 PROIECTAREA BAZEI DE DATE 88
5.5 IMPLEMENTAREA CODULUI 91
5.6 MANUAL DE UTILIZARE 97
5.7 CONCLUZII 100
BIBLIOGRAFIE 102
Descarca lucrare