Benchmark


Riccardo Cinus
Lorena Shestani
2790600
3665720
Benchmark
Una procedura di test standard utilizzata
per valutare le prestazioni di un qualsiasi
dispositivo
Definizione

Benchmarking: banco di prova, test
effettuato quando si confrontano due
programmi progettati per svolgere la
stessa serie di compiti o due elaboratori
per valutarne le prestazioni. Il test è anche
un controllo della macchina rispetto alle
prestazioni dichiarate dal costruttore.
Problematiche relative ai
benchmark

Trovare un modo appropriato di
valutazione di un programma o di un
apparecchio hardware
Le specificazioni di
benchmark

Sono stati sviluppati vari benchmark con
regole specifiche perché nessuna singola
metrica può misurare la performance dei
sistemi dei computer per tutte le
applicazioni. Il Benchmark Handbook ha
applicato questi quattro criteri chiave per
un benchmark con regole specifiche:

Relevance: Il Benchmark deve catturare le
caratteristiche del sistema per essere
misurato.

Portability: Il Benchmark deve essere
capace di essere implementato su diversi
sistemi.

Scalability: Il Benchmark deve essere
capace di testare vari database su diversi
sistemi di computer.

Simplicity: Il Benchmark deve essere
significativo; diversamente non sarà
credibile.
Un benchmark è usato per testare la massima
performance di un sistema.
Diversi aspetti di un sistema hanno varie
importanze a seconda dei diversi domini.
Ci sono tanti benchmark ed ogniuno di essi
può avere regole specifiche.
Alcuni benchmark: Wisconsin
benchmark

Il Wisconsin benchmark si usa per testare
la performance dei sistemi dei query
relazionali con semplici operatori
relazionali
Alcuni benchmark: Il AS3AP

Il AS3AP benchmark provvede ad una
valutazione più completa dei sistemi di
database relazionali incorporando delle
caratteristiche come: testare funzioni utili,
mucchio misto, query interattive e test
multiutenti
Altri Benchmark




Il Set Query benchmark valuta l’abilità dei
sistemi per procedere query complessi
Lo OO7 si usa per i database objectoriented
BUCKY per i database object-relational
TCP-W benchmark per l’ e- commerce.
Questo è il Benchmark più recente
Benchmark e XML
Il disegno di un benchmark per valutare
XML management systems è un nontrivial
task.
L’obbiettivo del benchmark è di focalizzare
gli aspetti del query-processing di XML.
Benchmark e XML
Gli strumenti del query-processing XML
sono valutati nel modo più semplice
possibile; infatti, vengono usati dati locali
per la valutazione, e questa viene
effettuata su una singola macchina.
Benchmark Data Set
La struttura del data set di un apposito
benchmark deve essere abbastanza
complesso per catturare tutte le
caratteristiche di una rappresentazione
dati di XML.
Benchmark Data Set
XML prevede a una ordinazione implicita dei
suoi elementi. Prevede inoltre anche a
referenze, deep nesting, hyperlink.
La base di dati del benchmark deve, inoltre
catturare anche le caratteristiche del documento
(es. l’ordine implicito degli elementi) e della
navigazione (le referenze)
Benchmark Data Set
Le ‘scalability’ di un sistema possono
essere misurate usando data set di vari
misure.
Siccome XML si può rappresentare come
un albero, questo si può archiviare come
segue:
Benchmark Data Set

La profondità del albero si può controllare
variando il numero delle ripetizioni degli
elementi ricorsivi.

L’ampiezza del albero si può aggiustare
col variare del cardinalità di alcuni
elementi
Benchmark Queries
In XML, la performance dei ‘linguaggi
query’ dipendono soprattutto dalla
funzionalità che loro provedono di fare e
dalla potenza delle espressioni.
Benchmark Queries
Il consorzio W3C XML Query Language Working
Group hanno pubblicato una lista di requisiti atti
a soddisfare le prestazioni delle query. Questa
lista è composta da 21 regole che sono
diventate il punto di riferimento nella valutazione
delle prestazioni di query.
Questi requisiti stabiliscono le capacità di
valutazione relative a: dati, documenti, e
navigazione.
Le regole

Permette i processi di query su tutti i tipi di
dati e colleziona i possibili documenti XML
multipli (R1)

Permette i data-oriented, documentoriented, e le query miste (R2)

Accetta i dati in streaming (R3)
Le regole

Supporta le operazioni su vari modelli di
dati (R4)

Permette condizioni su elementi del testo
(R5)

Supporta query sequenziali e gerarchiche
(R6)
Le regole

Manipola i valori null (R7)

Supporta i quantificatori nelle query (R8)

Permette alle query di combinare parti di
piu documenti (R9)
Le regole

Supporta per l’aggregazione (R10)

Capacità di generare risultati con tipo
(R11)

Supporta la composizione di operazioni
(R12)
Le regole

Permette la navigazione (R13)

E’ capace di usare le informazioni
dell’ambiente come parti delle query (R14)

Capace di supportare aggiornamenti XML
se il modello dei dati lo permette (R15)
Le regole

Supporta tipi di coercizione (R16)

Preserva la struttura dei documenti (R17)

Trasforma e crea le strutture XML (R18)
Le regole

Supporta la creazione degli ID (R19)

Ricorrenza strutturale (R20)

Ordinamento degli elementi (R21)
XML e SQL
Al pari di di SQL per i database relazionali;
XML deve essere espressivo come un
linguaggio query strutturato
Alcuni XMS possono avere dei limiti nelle
capacita di ‘query-processing’ ed è possibile
che alcuni benchmark non possono eseguiti
in questi sistemi. Questo problema può
essere risolto avendo dei benchmark query
separati, testando ognuno un diverso tipo di
aggregazione.
Questa scelta deve essere affrontata inoltre
dalla grande possibilità di scelta di funzioni
che un utente può usare-avere bisogno-.
Questo permette di semplificare l’analisi dei
resultati, evidenziandone le caratteristiche.
CONFRONTI TRA BENCHMARK
Prendiamo in esame 3 benchmark di XML.
I Benchmark considerati sono: XOO7,
XMach-1, Xmark ; attraverso i quali
valuteremo le caratteristiche del queryprocessing di XML.
XOO7 benchmark
XOO7 benchmark si basa sullo OO7
benchmark.
Lo XOO7 benchmark ne è una versione
per XML e contiene nuove funzionalità;
tra cui nuove query.
XOO7 benchmark
Lo XOO7 benchmark testa le stesse
caratteristiche del XML, che lo OO7.
Anche la struttura dati di base del XOO7
benchmark deriva dallo OO7 benchmark.
XOO7 benchmark
I parametri e i valori corrispondenti che
sono usati per controllare la dimensione
dei dati XML dello XOO7 benchmark sono:
I parametri del XOO7 Database
Parametri
NumAtomic
PerCompo
site
NumConne
ctionPerAto
mic
Document
Size(bytes)
Piccoli
20
Medi
200
Grandi
2000
3,6,9
3,6,9
3,6,9
500
1000
1000
I parametri del XOO7 Database
Parametri
Piccoli
ManualSize 2000
(bytes)
NumComp 50
ositePerMo
dule
NumAssem 3
blyPerAsse
mbly
Medi
Grandi
4000
4000
50
500
3
3
I parametri del XOO7 Database
NumAssem 5
blyLevels
5
7
NumComp 3
ositePerAs
sembly
NumModul 1
es
3
3
1
1
Differenze tra XOO7 e OO7
Ci sono alcune importanti differenze fra i
parametri del database in XOO7,
confrontate con quelle del OO7
benchmark :
Differenze tra XOO7 e OO7

Nello OO7 benchmark ci sono 7 livelli nei
grandi database, mentre nei piccoli e nei medi
database, a causa di restrizioni degli strumenti
di XML, ci sono solo 5 livelli.

Nello OO7 benchmark ci sono 10 moduli in un
grande database. XOO7 benchmark, invece,
supporta solamente un modulo; questo perché
l’elemento modulo è stato scelto come radice
del documento XML
Differenze tra XOO7 e OO7

Siccome i dati in XML si possono essere
rappresentati in albero, la dimensione dei
dati può essere cambiata in 2 direzioni:
PROFONDITA e AMPIEZZA .
Profondità e Ampiezza
La profondità dell’ albero può variare con il
cambiamento del valore del
NumAssemblyLevels, mentre l’ampiezza
dell’albero può essere controllato dal
valore di un NumAtomicPerComposite o
NumCompositePerModule . L’utente può
variare questi valori.
Le OO7 QUERIES
Le queries generate dal OO7 benchmark
non coprono tutte le funzionalità delle
queries XML.
Infatti la maggiore parte delle queries dello
OO7 benchmark si focalizzano nella
capacità delle query data-centric nei
sistemi object-oriented database
Le XOO7 QUERIES
LO XOO7 benchmark copre più
funzionalità delle queries, rispetto allo
OO7 benchmark
Differenze tra XOO7 e OO7
QUERIES
Infatti la maggiore parte delle queries dello
OO7 benchmark si focalizzano nella
capacità delle data-centric nei sistemi
object-oriented database.
Invece lo XOO7 benchmark copre più
funzionalità.
Differenze tra XOO7 e OO7
QUERIES
Le queries nello XOO7 sono divise in ben 3
gruppi:



Il primo gruppo consiste nelle query tradizionali
dei database.
Il gruppo 2 consiste nelle navigational queries.
Il gruppo 3 consiste nelle query del documento.
Le XOO7 QUERIES
Le queries generate dal OO7 benchmark
non coprono tutte le funzionalità delle
queries XML.
La maggiore parte delle queries dello OO7
benchmark si focalizzano nella capacità
delle query data-centric nei sistemi objectoriented database.
Le XOO7 QUERIES
Alcuni XMS supportano la maggior parte
delle query
Tali XMS sono considerati portatili.
Gli utenti possono sempre scegliere il
subset di query più appropriato per testare
le caratteristiche delle loro applicazioni.
Xmach-1 benchmark
Il Xmach-1 è un benchmark multiuso
progettato per le applicazioni B2B.
Analizziamo ora, solo i casi speciali del
benchmark Xmach-1 adoperato da un
singolo utente in una stessa macchina.
Xmach-1 DATABASE
L’Xmach-1 benchmark limita i dati XML, per
poterli adoperare in una forma semplice e con
valori di piccola dimensione.
Supporta XMS schema-based e schema-less e
permette l’implementazione di alcune
funzionalità sul livello di applicazione.
Xmach-1 DATABASE
Tutti i file XML simulano un articolo con
elementi come
titolo,capitolo,sezione,paragrafo, etc.
I dati di testo sono presi dal linguaggio
naturale.
Xmach-1 DATABASE
L’utente può cambiare la misura del file
XML modificando il numero degli elementi
dell’articolo.
Variando il numero dei file XML, controlla
la misura del database; tuttavia Xmach-1
assume che le modifiche apportate ai file
dei dati sul web siano minime .
Le Xmach-1 Queries
L’Xmach-1 valuta le carateristiche di
linguaggi standard e linguaggi non
standard; quali l’Inserimento, la
cancellazione, le interrogazioni URL e le
operazioni di aggregazione.
Le Xmach-1 Queries
Questo Benchmark consiste in 8 query e 2
operazioni di aggiornamento.
Per migliorare il confronto, dividiamo le
query in 4 gruppi basandosi sulle
caratteristiche che “catturano”.
Le Xmach-1 Queries

1 gruppo consiste in semplici selezioni e in
progettazioni delle query, confrontando il
valore dell’attributo.

2 gruppo chiede ai sistemi di usare
l’ordine degli elementi per estrarre i
risultati.
Le Xmach-1 Queries

3 gruppo testa le funzioni di
aggregazionee usano le informazione dei
metadati.

4 gruppo sono operazioni di
aggiornamento
L’ Xmark benchmark
L’Xmark benchmark simula uno scenario ,
anche molto specializzato, che contiene
elementi e attributi che possono essere
difficilmente capibili dall’utente
L’Xmark database



Le entità principali del database sono:
articoli, persone, categorie, etc.
Gli articoli sono gli oggetti che sono in
vendita o sono già venduti. Le persone
contengono sottoelementi quali nome,
indirizzo, e-mail.
Le categorie hanno un nome e una
descrizione.
L’Xmark queries
Xmark prevede 20 query che sono state
analizzate in una ricerca interna del
prototipo
Xmark sono divisi in 4 gruppi basandosi
nella funzionalità dei query
L’Xmark queries
Xmark sono divisi in 4 gruppi basandosi nella
funzionalità dei query :

Il gruppo 1 contiene le query relazionali piu
semplici; abbiamo quindi confronti dei vari tipi di
valori di dati.

Il gruppo 2 sono query su documenti che
preservano l’ordine degli elementi.
L’Xmark queries

Il gruppo 3 contiene le query
navigazionali.

Le query del gruppo 4 richiedono la cura
della aggregazione e l’ordinamento delle
operazioni.
CONCLUSIONI
Lo XOO7, Xmach-1 e Xmark
benchmarcks sono stati progettati per
testare la performance di XMS diversi.
Tutti questi 3 benchmarks catturano le
caratteristiche essenziale dei dati XML e la
varietà dei valori.
CONCLUSIONI

Xmark e XOO7 coprono più funzionalità.
Xmach-1 copre meno funzionalità.

Osserviamo che XOO7 e Xmach-1 danno
query semplici che danno 1 o 2 funzioni;
invece la maggior parte delle query fatte
con Xmark sono complesse e coprono più
caratteristiche.
CONCLUSIONI
E possibile che alcune query Xmark non
possono essere eseguite o applicabili
perché il sistema che si sta testando
supporta solo un subset delle
caratteristiche.
CONCLUSIONI



XOO7 permette agli utenti di cambiare la
dimensione del file in profondità e in ampiezza.
Xmark cambia la dimensione del database di un
certo fattore
Xmach-1 assume che i file XML sono piccoli,
cambiando il numero dei file XML cambia la
dimensione del database. Tale dimensione e più
piccola .
CONCLUSIONI





Come abbiamo già visto la qualità di un
XMS benchmark può essere analizzata
rispettando i 4 criteri:
SIMPLICITY
RELEVANCE
PORTABILITY
SCALABILITY
Microbenchmark
Un aspetto che i benchmark XML correnti
non possono focalizzare è la performance
della valutazione delle operazioni
elementari come: la selezione, join,
aggregazione. C’è un micro-benchmark
che può evidenziare la performance di
questi operazioni elementari, e può essere
in aiuto del sviluppatore del database.
Microbenchmark
Una pubblicazione stimolante del disegnare
qualche benchmark, è la scelta del data set che
si usa.
Il data set del benchmark deve essere
abbastanza complesso da incorporare le
caratteristiche dei dati. Nello stesso tempo la
data set del benchmark deve essere anche
semplice in modo che le queries possano
guidare l’utente del benchmark.
Related Work (Simili lavori)
Sono state fatte tante proposte per generare
XML data sintetiche. Aboulnaga et al. propose
un generatore di dati che accetta 20 parametri
per permettere all’utente di controllare le
proprietà del data generato.
Barbosa et al. propose un generatore di dati per
XML, che genera multipla sintonie di data sets.
Lavori simili
In contrasto a questi, il generatore di dati
nel Michigan benchmark produce un XML
data sets progettato per testare diverse
caratteristiche del XML data.
Poi ci sono i tre benchmark proposti per
valutare la performance del XML data
managemnet systems: Xmach-1, Xmark e
XOO7.
Benchmark Data set

Una discussione sulle caratteristiche
dei dati
Le caratteristiche primarie dei Dati sono:
la selezione degli attributi e la selezione
degli join.
Benchmark Data set

Depth and Fanout
Depth e Fanout sono 2 parametri
strutturali importanti per l’albero dei dati.
La profondità dell’albero dei dati ha un
impatto significativo nella performance
quando si compiono relazioni tra padre e
figli.
Benchmark Data set
Un modo per testare la profondità e il
fanout è il generare un numero distinto di
data sets con valori diversi per ogni valore
di questi parametri.
Bisogna notare che un numero grande di
data set influenza il lavoro del benchmark
creando delle difficoltà nel suo
funzionamento e nel capirlo.
Benchmark Data set
Il fanuot è il numero dei figli per ogni nodo,
che può variare secondo il livello. Per
esempio, in un albero con 16 livelli, ogni
livello ha un fanout di 2, eccetto i livelli
5,6,7 e 8. I livelli 5,6,7 hanno un fanout di
13 invece, il livello 8 ha un fanout di 1/13
(nel livello 8 ogni 13 nodi si ha un solo
figlio).
Benchmark Data set

Data Set Granularity
Per tenere il benchmark semplice, si sceglie un
grande albero del documento come data set
default.
Il documento ‘granularity’ può modificare il data
set del benchmark per separare ogni nodo di un
livello come radice di un documento distinto.
Inoltre, può confrontare la performance delle
queries del data set modificato con quelle del
data set originale.
Benchmark Data set

Scaling
Un buon benchmark ha bisogno di essere
scalato in ordine, per misurare la
performance dei databases in piattaforme
diverse. Con XML ci sono tanti opzioni per
scalare, come: aumentando il numero dei
nodi, la profondità e fanout.
Benchmark Data set
Nel progetto del benchmark data set, il
fanout degli ultimi livelli dell’albero si
mantiene costante. Questo progetto
implica che la percentuale dei nodi nei
livelli più bassi è quasi costante per tutti i
data sets.
Benchmark Data set

Lo schema del Benchmark data
La costruzione del benchmark data è
centralizzato nel tipo del elemento BaseType.
Ogni elemento BaseType ha alcuni attributi
come:


aUnique1: attributo che serve come
identificatore dell’elemento.
aUnique2: un intero generato casualmente.
Benchmark Data set




aLevel: un intero set per inserire il livello
del nodo.
aFour: un intero set di aUnique2 mod 4.
aSixteen: un intero set di aUnique1 +
aUnique2 mod16.
aSixtyfFour: un intero set per aUnique2
mod 64.
Benchmark Data set

aString: una stringa approssimata in una
lunghezza di 32 bytes.
Il contenuto del ogni elemento BaseType è
una lunga stringa approssimata in una
lunghezza di 512 byte.
Benchmark Data set

Benchmark Queries
Di più ci interessa valutare il costo dei parti
individuali delle funzionalità delle queries che
valutare la performance composta. Inoltre, è
conveniente riferirsi alle query come ‘selection
query’, ’join query’, etc. usando la
decomposizione delle queries.
Benchmark Data set

Selezione (Selection)
La selezione XML è l operazione più
complessa e più importante per la
gestione della struttura dell’albero.
Benchmark Data set

Struttura di ritorno(Returned Structure)
In una relazione, una volta selezionata
una tupla, viene restituita proprio quella
tupla. Invece, in XML, una volta
selezionato un elemento, può tornare
l’elemento, oppure l’elemento e i suoi
figli, oppure il sottoalbero con radice
l’elemento.
Benchmark Data set

Selezione semplice (Simple selection)
Le XML queries coinvolgono solo un
elemento e un singolo predicato può
mostrare diversi risultati considerabili.
Benchmark Data set

Selezione strutturale (Structural selection)
La selezione in XML è spesso basata su
patterns. Le queries devono essere
costruite in modo tale che considerano
anche patterns multinodi. Queste patterns
spesso hanno una condizione di
selezione.
Benchmark Data set

La selezione condizionale (conditional
selectivity) in XML è complicata perché
diversi attributi possono non essere nello
stesso elemento.
Benchmark Data set
Un Value-Based Join funziona
confrontando i valori di due diversi nodi.
La struttura di ritorno è un albero con le
coppie collegate (join-pair). Ogni albero ha
uno join-nodo come radice e due figli, uno
corrispondendo ad ogni elemento
partecipante nello join.
Benchmark Data set

Join con indicazione (Pointer-Based Join)
I Pointer-Based Joins sono semi-join
queries. Gli elementi che ritornano sono
solo i nodi selezionati, non quelli puntati.
Benchmark Data set

Aggregazione (Aggregation)
Le queries aggregate sono molto
importanti per le applicazioni di
deposizione del Data ‘data-warehousing’.
Benchmark Data set

Aggiornamenti (Updates)
Gli aggiornamenti sono: inserimento
(insert), cancellazione (delete) etc.
Confronto tra vari database
Memorizzazione dei documenti
XML
Introduzione
Il numero dei documenti XML crescerà
rapidamente in futuro, data la crescente
importanza di questo linguaggio.
Un problema da notare è come aggiungere i
documenti XML mentre si stano salvando le loro
strutture; permettendo, inoltre, accessi efficienti
per le parti dei documenti strutturati.
Introduzione
Ci sono vari sistemi di base di dati
standard; ‘relational’, ‘object-oriented’,
‘object-relational’, come ‘directory servers’
e ultimamente le così dette ‘native XML
database’.
Introduzione
Per fare i confronti fra i sistemi di base di dati, è
stato usato il DOM (Document Object Model).
DOM indirizza i documenti XML costruendo
degli alberi. Gli elementi di un documento
diventano nodi interni del albero DOM, invece gli
attributi, commenti, testi, enti e notazioni
formano le foglie dell’ albero.
I modelli dei dati per i
documenti XML

L’implementazione senza tipo del DOM
In una ‘nontyped DOM implementation’, per ogni
interfaccia del DOM è definita una classe.
Le classi, tra altri attributi contengono anche
parentNomeInterfaccia , childNomeInterfaccia
per implementare l’albero e per permettere la
navigazione da un nodo dell’albero ai suoi figli e
il contrario.
I modelli dei dati per i
documenti XML
Inoltre, implementa anche i metodi
predefiniti come firstChild, lastChild e così
via.
I modelli dei dati per i
documenti XML
Questi metodi fanno si che costruire ed
attraversare l’albero. Infine, usando il
DOM tutto il documento XML è contenuto
in un gruppo di istanze appartenenti alle
classe che implementano le interfacce.
Sono proprio le istanze quelle che
contengono l’informazione del documentspecific e non le classe
I modelli dei dati per i
documenti XML

L’implementazione con tipo del DOM
Come una estensione del ‘nontyped
implementation’, ogni classe che implementa
una interfaccia può avere delle sottoclassi
definite per ogni tipo di elemento di un
documento XML. Queste classi sono in
relazione con gli altri elementi, attributi
rappresentati con composizioni(associazione).
I modelli dei dati per i
documenti XML
La differenza fra questi due approcci è che
nel primo approccio la struttura del
documento è riprodotto solo negli stati
delle istanze. Invece, nel secondo
approccio, la struttura del documento è
mostrato dalla composizione gerarchico
delle classe.
Base di dati per inserire i
Documenti XML
Anche se i documenti XML sono di testo e
questi possono essere inseriti su files,
sono chiamati dati semi-strutturati poichè
hanno bisogno di essere accessi
attraverso la struttura.
Base di dati per inserire i
Documenti XML

Relational databases
L’inserimento dei documenti XML con
relational databases vuol dire descrivere le
strutture ‘tree-type’, con relazioni in modo
gerarchico.
Questo è reso possibile attraverso due
alternative di modelli di dati per documenti
XML:
Base di dati per inserire i
Documenti XML

A Simple Nontyped DOM Implementation
Usando il DOM, queste strutture sono
state trasformate in alberi, grazie alle
classe che implementano le interfacce del
DOM.
Base di dati per inserire i
Documenti XML
L’albero viene formato da due
associazioni:


l’associazione dei childNodes e del
ParentNode.
L’associazione dei childNodes è
multivalore la quale crea relazioni fra nodi
(one-to-many).
Base di dati per inserire i
Documenti XML
Inoltre, ogni elemento riceve un numero di
identificazione che si usa come una key.
Base di dati per inserire i
Documenti XML

The Typed DOM Implementation
L’implementazione di tipo DOM definisce
una classe per ogni elemento e inserisce
le istanze di una classe in una tabella con
lo stesso nome.
Base di dati per inserire i
Documenti XML
La localizzazione dei elementi, che si
realizza dalla composizione, neccessita di
un numero di identificazione, chiamato
key.
Base di dati per inserire i
Documenti XML

Object-Oriented database
Le base di dati di tipo Object-Oriented
inseriscono gli alberi DOM senza aver
bisogno dell’indirizzamento degli
oggetti e le loro relazioni con altri
concetti di dati.
Base di dati per inserire i
Documenti XML
Le varianti dell’implementazione del DOM
sono riflesse su degli schemi che verranno
valutati confrontandoli con altri.
Gli sistemi di base di dati object-oriented,
permettono anche l’adattamento dinamico
dello schema.
Base di dati per inserire i
Documenti XML
Siccome questo rappresenta la struttura
del documento, una piccola modificazione
può portare ad una invalidazione dei
documenti, che seguono il DTD
originale,modificati.
Queste modificazioni hanno degli effetti
svantaggianti.
Base di dati per inserire i
Documenti XML
I sistemi di base di dati object-oriented,
hanno un metodo per indicizzare i ‘node
set’ ed avere così un modo più veloce per
accedere ai nodi figli di un elemento.
Base di dati per inserire i
Documenti XML

Directory servers
‘Directory servers’ può essere un altro
database molto interessante.
Vengono memorizzati dati strutturati.
Gli accessi in lettura sono molto veloci,mentre
l’accesso per la scrittura dei dati è lento.
Base di dati per inserire i
Documenti XML
Un'altra caratteristica importante è che i
dati vengono organizzati in un albero.
Base di dati per inserire i
Documenti XML
‘Directory servers’ sono estesi come
indirizzi delle base di dati che sono
accessibili usando il LDAP (Lightweight
Directory Access Protocol), un semplice
variante del X.500 ISO standard. LDAP
directory contiene informazioni su oggetti
come dipartimenti, persone in una società,
risorse etc.
Base di dati per inserire i
Documenti XML
‘Directory servers’ sono stati sviluppati per
offrire un ‘libro’ centrale di indirizzi.
Tale libro contiene una serie di nomi degli
attributi che possono essere inclusi in un
oggetto di una classe, per esempio: “o”
per “organizzazione”, “cn” per “cognome”.
Base di dati per inserire i
Documenti XML
Lo schema delle directory servers è
definito usando le classi con delle relazioni
tra di loro.
Base di dati per inserire i
Documenti XML

Native XML databases
Le native XML databases sono specializzate
per inserire e per processare i documenti
XML.
Il sistema del basi di dati che si usa deve
conoscere il DTD. Usando DTD, il sistema
crea lo schema del base di dati.
Le specificazioni di Benchmark
In questa parte vedremo come le directory
servers si usano come ‘XML data
management systems’ e vedremo anche
un confronto fra i sistemi di database
relational, object-oriented, e native XML.
Le specificazioni di Benchmark
Salvo il sistema native XML database che
include un proprio linguaggio di query per
accedere al database, dobbiamo implementare
l’accesso su ogni altro database.
La standardizzazione del linguaggio query XML
è completa, però mancano alcune
implementazioni nella versione finale.
Ci affidiamo allora ai requisiti generali che la
memoria dei documenti XML incontrerà in
avanti.
Le specificazioni di Benchmark
I documenti XML devono essere inseriti in
un base di dati e devono avere la
possibilità di essere modificati in parti.
I linguaggi dei query XML devono, inoltre,
contenere questi requisiti:
Le specificazioni di Benchmark


Un documento o parti del documento
devono avere la possibilità di essere
raggiunti usando la struttura, il contenuto o
i valori degli attributi.
Un documento XML o parti di un
documento XML devono avere la
possibilità di essere estratti.
Le specificazioni di Benchmark



Un documento devono avere la possibilità di
essere ridotto in parti ottimizzando i
sottoelementi.
Alcuni parti devono avere la possibilità di essere
ristrutturate per creare un nuovo documento.
Gli elementi devono avere la possibilità di
essere combinati tra di loro per creare un
documento.
Le specificazioni di Benchmark

Benchmark su un Directory server
Per memorizzare un documento XML in
una directory server, si attraversa
l’albero DOM, si creano le entrate
(entries) e si inseriscono tutte
nell’albero delle informazioni del
directory.
Le specificazioni di Benchmark
L’estrazione di un documento XML si fa
selezionando le entrate (entries) nell’albero delle
informazioni della directory.
Il metodo di selezione del LDAP permette di
restituire tutto l’albero che però non è ordinato.
Inoltre, LDAP contiene dei metodi per cercare le
entrate (entries) basandosi nei loro nomi
distinguibili.
Le specificazioni di Benchmark

Benchmark su un Native XML database
Le basi di dati XML, assicurano dei
metodi per inserire un documento XML
sul database ed estrarre l’intero
documento dal database.
Le specificazioni di Benchmark
Questo implementa anche un query XML
e un linguaggio di updating che permette
di esprimere gli stati delle specifiche dei
benchmark.
Le specificazioni del Benchmark

Risultati di un test
I benchmark sono stati provati su un
server Intel Pentium III con 450MHz,
256MB RAM e due UW-SCSI hard disks.
La prova è stata fatta tra relational
DBMS, object-orientede BDMS,
directory server e native XML DBMS.
Le specificazioni del Benchmark
I documenti usati per la prova sono stati
generati automaticamente basandosi in una
DTD che definisce la struttura delle descrizioni
del progetto.
Il DTD contiene 26 elementi con un max di 8 e 4
attributi. I documenti XML basati su questo DTD
contengono informazioni su membri di un
progetto, come nome, indirizzo, etc.
Le specificazioni del Benchmark





Per confrontare i tipi diversi dei database, sono
stati fatti i seguenti test:
Memorizzare, inserire documenti XML
Estrarre interi documenti XML
Cancellare interi documenti XML
Estrarre parti dei documenti identificati dalla
posizione degli elementi sul documento.
Reinserire parti dei documenti
Le specificazioni del Benchmark

La valutazione della performance
Dopo aver fatto girare cinque volte i
benchmark sono venuti fuori questi
risultati:
La base di dati O-O è il migliore per
inserire i documenti XML, invece il
peggiore è relational database con tipo.
Le specificazioni del Benchmark
Per estrarre interi documenti, native database
ha dato i risultati migliori. Invece, i risultati
peggiori gli ha dato il relational database con
tipo.
Invece, per estrarre parti di documenti, tutte i
database hanno mostrato risultati simili, che
dipendono dalla dimensione del documento.
Però, il più veloce è il relational database.
Le specificazioni del Benchmark
I risultati peggiori gli ha dato O-O database,
causati dalla ricostruzione e la ricerca dell’albero
DOM.
Per il caso del reinserimento il più veloce è
relational database senza tipo e il peggiore è
O-O database lo stesso motivo di quello in
precedenza. Ce da notare che in questo caso il
database native XML subisce una grande
caduta di prestazione con l’aumento della
dimensione del documento.