Tesi Michele Freschi e Donato Ferrante

Università diPisa
Facoltà di Scienze Matematiche Fisiche e Naturali
Corso di Laurea in Informatica
Relazione di tirocinio
Completamento Compilazione
ed Esecuzione Query in XPeer
Donato Ferrante e Michele Freschi
Tutore accademico
Prof. Giorgio Ghelli
Anno Accademico 2005/2006

1
...a Zio Olly e Zia Ida

Indice
1 Introduzione 1
1.1 I Sistemi Peer To Peer . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Il Sistema XPeer . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2.1 Descrizione . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2.2 Interrogazioni . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 Organizzazione della Relazione . . . . . . . . . . . . . . . . . . 4
2 Architettura del Sistema 6
2.1 Cenni Generali . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2 L’ACL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3 Invio Messaggi . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4 Ricezione Messaggi . . . . . . . . . . . . . . . . . . . . . . . . 7
2.5 ACL in Dettaglio . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.5.1 Communication Layer . . . . . . . . . . . . . . . . . . 8
2.5.2 Identifier Layer . . . . . . . . . . . . . . . . . . . . . . 9
2.5.3 Queue Layer . . . . . . . . . . . . . . . . . . . . . . . . 9
2.5.4 Message Layer . . . . . . . . . . . . . . . . . . . . . . . 10
2.6 Protocolli . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.6.1 MetaSearch . . . . . . . . . . . . . . . . . . . . . . . . 10
2.6.2 MetaUpdate . . . . . . . . . . . . . . . . . . . . . . . . 11
2.6.3 SchemaUpdate . . . . . . . . . . . . . . . . . . . . . . 12
2.7 Cloning e Splitting . . . . . . . . . . . . . . . . . . . . . . . . 13
2.7.1 Cloning . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.7.2 Splitting . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3 Modello dei Dati 16
3.1 XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.1.1 Documenti XML . . . . . . . . . . . . . . . . . . . . . 16
3.1.2 Elementi . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.1.3 Altri Costrutti . . . . . . . . . . . . . . . . . . . . . . 19
3.2 XML Schema 1.1 . . . . . . . . . . . . . . . . . . . . . . . . . 20
i

INDICE ii
3.2.1 Struttura . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.2.2 Tipi di Dato . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2.3 Namespace . . . . . . . . . . . . . . . . . . . . . . . . 24
3.3 XPath . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.3.1 XPath Datamodel . . . . . . . . . . . . . . . . . . . . . 25
3.3.2 Valutazione . . . . . . . . . . . . . . . . . . . . . . . . 26
3.3.3 Espressioni . . . . . . . . . . . . . . . . . . . . . . . . 27
3.4 XQuery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.4.1 Le espressioni FLWOR . . . . . . . . . . . . . . . . . . 29
4 Compilazione 33
4.1 Algebra di Interrogazione . . . . . . . . . . . . . . . . . . . . . 33
4.1.1 Modello dati . . . . . . . . . . . . . . . . . . . . . . . . 33
4.1.2 Operatori . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.2 Protocollo di Compilazione . . . . . . . . . . . . . . . . . . . . 36
4.3 Tree-Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.3.1 Filtri di Bloom . . . . . . . . . . . . . . . . . . . . . . 40
4.3.2 Liste di Valori . . . . . . . . . . . . . . . . . . . . . . . 42
4.3.3 Unione Tree-guide . . . . . . . . . . . . . . . . . . . . 42
4.4 Albero Logico . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.5 Algoritmo di Schema Matching . . . . . . . . . . . . . . . . . 45
5 Esecuzione 47
5.1 Protocollo di Esecuzione . . . . . . . . . . . . . . . . . . . . . 47
5.1.1 Riscrittura dell’ Albero Logico . . . . . . . . . . . . . . 48
5.1.2 Decomposizione dell’ Albero Logico . . . . . . . . . . . 49
6 Risultati Sperimentali 52
6.1 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
6.2 Ambiente di Sperimentazione . . . . . . . . . . . . . . . . . . 52
6.3 Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
6.4 Verifica dei Risultati . . . . . . . . . . . . . . . . . . . . . . . 54
6.5 Risultati . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
6.6 Strumenti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
7 Conclusioni 57
A Frammenti XML 58
B Insieme Query 59

INDICE iii
C Algebra di Interrogazione 60
C.1 Modello dei Dati . . . . . . . . . . . . . . . . . . . . . . . . . 60
C.2 Funzioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
C.3 Env . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
C.4 Operatori di Supporto . . . . . . . . . . . . . . . . . . . . . . 61
C.5 Operatori di Base . . . . . . . . . . . . . . . . . . . . . . . . . 61
C.6 Operatori sulle Locazioni . . . . . . . . . . . . . . . . . . . . . 61
C.7 Path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
C.7.1 Grammatica degli Input Filter . . . . . . . . . . . . . . 62
C.7.2 Path . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
C.8 Return . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
C.8.1 Grammatica degli Output Filter . . . . . . . . . . . . . 63
C.8.2 Return . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

Capitolo 1
Introduzione
1.1 I Sistemi Peer To Peer
Il paradigma Peer-to-Peer (P2P) ha ridisegnato la concezione di sistema distribuito,
concezione che sin dalle origini era legata prevalentemente ad un
modello client-server.
Il nucleo di un sistema Peer-to-Peer è costituito da un insieme di nodi
(detti peer ) interconnessi mediante una struttura: l’ overlay network,chepermette
loro di condividere risorse e comunicare mediante scambio di messaggi.
Si possono distinguere principalmente due famiglie di network Peer-to-
Peer in base a quanto si distaccano dal modello client-server in cui le comunicazioni
sono intermediate da un server centrale, ovvero:
- Peer-to-Peer puro, in cui si perde la nozione di client e server come
entità separate, ovvero tutti i nodi del network svolgono un doppio ruolo
comportandosi al contempo come client e server per gli altri peer.
- Peer-to-Peer ibrido, in cui vengono utilizzati aspetti del modello
client-server affiancati da aspetti ricavati dall’ approccio Peer-to-
Peer puro. Ad esempio nel ricorrere all’utilizzo di server esterni che
1

CAPITOLO 1. INTRODUZIONE 2
permettono ai peer di ricavare informazioni sulle risorse attualmente
disponibili nella rete.
Alcuni dei vantaggi offerti dell’approccio Peer-to-Peer sono:
- Elevata scalabilità: i colli di bottiglia presenti nei modelli clientserver,
ovvero i server, non sono più presenti come parte fondamentale
del sistema;
- Autonomia: ogni peer è un’entità autonoma;
- Bassi costi di amministrazione: l’amministrazione è delegata ai
client stessi.
Su questa infrastruttura si colloca il progetto XPeer del Dipartimento di
Informatica dell’Università di Pisa. Progetto che cerca di sfruttare i benefici
derivati dall’utilizzo di un architettura Peer-to-Peer allo scopo di creare un
database distribuito affidabile e robusto.
1.2 Il Sistema XPeer
1.2.1 Descrizione
XPeer è un Database Distribuito XML Peer-to-Peer, che presenta le seguenti
caratteristiche:
- gestisce dati in formato XML;
- i dati sono interrogabili mediante l’utilizzo di FLWR un sottoinsieme
di XQuery;
-è in grado di funzionare in ambienti fortemente dinamici.
Ogni peer del sistema XPeer condivide un proprio database XML locale
ed in aggiunta fornisce risorse computazionali al sistema stesso.
L’ overlay network è una struttura gerarchica ad albero ad n livelli:

CAPITOLO 1. INTRODUZIONE 3
- livello 0, occupato dai peer ;
- livello i dove i in (0, n), occupato dai superpeer, che possono avere
solo figli di livello i-1.
- livello n, occupato dalla root.
Figura 1.1: Architettura di XPeer
In questa struttura ad albero le foglie sono i processi gestori dei database
locali mentre i nodi interni, compresa la radice, sono processi che si fanno
carico della corretta evoluzione e gestione della rete.
Una particolarità che distingue XPeer rispetto agli altri sistemi P2P consiste
nel sapersi auto-amministrare senza interventi esterni, adattandosi automaticamente
a cambiamenti nella topologia e nel carico di lavoro.
Per garantire la robustezza, la scalabilità e il bilanciamento del carico sono
stati introdotti due meccanismi di gestione del sistema: cloning e splitting.

CAPITOLO 1. INTRODUZIONE 4
Il cloning permette di limitare il carico di elaborazione dei nodi della rete
mediante un processo che porta i nodi sovraccarichi a clonarsi ed a formare
insiemi di cloni (cloneset), mentre lo splitting permette di ridurre il carico
dovuto alla sincronizzazione interna ai cloneset, questi due meccanismi sono
descritti in dettaglio nel capitolo 2.
1.2.2 Interrogazioni
Un’altra caratteristica di XPeer consiste nella gestione delle interrogazioni
in due fasi distinte: compilazione ed esecuzione. Mediante la compilazione
la rete dei superpeer identifica i peer con dati rilevanti per l’interrogazione
sottomessa.
Nella seconda il peer che ha inoltrato l’interrogazione,coordina l’esecuzione
sui peer remoti. Questa scelta si discosta dai sistemi P2P tradizionali in
cui l’interrogazione viene eseguita contemporaneamente alla sua propagazione.
La scelta adottata migliora la selettività dell’interrogazione poichè ladisseminazione
delle query è decisa a livello di sistema e non localmente dal
peer, e permette al peer che la ha inoltrata, di applicare ottimizzazioni sul
piano di accesso.
1.3 Organizzazione della Relazione
La presente relazione è stata strutturata come segue:
- Capitolo 2: si descrive l’architettura del sistema XPeer.
- Capitolo 3: si descrive il modello dati del sistema XPeer.
- Capitolo 4: si descrive la fase di compilazione delle query nel sistema
XPeer.

CAPITOLO 1. INTRODUZIONE 5
- Capitolo 5: si descrive la fase di esecuzione delle query nel sistema
XPeer.
- Capitolo 6: si descrivono i risultati sperimentali ottenuti e si descrivono
alcuni degli strumenti utilizzati.
- Capitolo 7: si riportano le nostre conclusioni.

Capitolo 2
Architettura del Sistema
2.1 Cenni Generali
I nodi che fanno parte della rete ad albero, del sistema XPeer sono di due
tipi: peer e superpeer virtuale. I primi mettono a disposizione i dati e permettono
all’utente di effettuare interrogazioni al sistema, i secondi sono invece
delegati alla gestione della rete.
Un superpeer virtuale è un cloneset di cardinalità maggiore o uguale ad
uno.
Ad ogni nodo della rete sia esso un peer o un superpeer virtuale è associato
un id virtuale, il quale permette di identificare univocamente un nodo
peer o superpeer virtuale. Inoltre èpresenteunid fisico per permette di
effettuare un ulteriore identificazione dei nodi peer e superpeer.
Per permettere l’interazione tra i moduli peer e superpeer che compongono
il sistema si è definito un livello sottostante, l’ACL, ovvero un modulo
di basso livello delegato ad instradare le comunicazioni tra i moduli di livello
superiore.
6

CAPITOLO 2. ARCHITETTURA DEL SISTEMA 7
2.2 L’ACL
L’ACL costituisce l’infrastruttura di comunicazione basata sullo scambio di
messaggi utilizzata dai moduli di livello superiore per interagire tra loro,
fornendo le primitive di invio e ricezione dei messaggi. Inoltre l’ACL provvede
ricorrendo all’utilizzo di code al corretto instradamento dei messaggi da/verso
entità del sistema.
2.3 Invio Messaggi
Un modulo che vuole inviare un messaggio invoca il metodo di invio fornito
dall’ interfaccia dell’ ACL specificando il messaggio, il destinatario ed inoltre
la coda a cui il messaggio è destinato.
Non appena l’ACL riceve una richiesta di invio, in modo del tutto trasparente
al modulo mittente, provvede a recapitare il messaggio inviato al
modulo di comunicazione del destinatario.
2.4 Ricezione Messaggi
Quando un messaggio viene depositato (via ACL) nella coda di un modulo
di comunicazione, il modulo di livello superiore, sia questo peer o superpeer,
provvederà a richiederlo al livello sottostante.
Potrebbe succedere che due moduli richiedano in contemporanea un messaggio
sulla stessa coda al livello di comunicazione ma l’ACL ricorrendo al
campo destinatario del messaggio riesce sempre a discriminare quale sia il
vero destinatario tra i richiedenti.

CAPITOLO 2. ARCHITETTURA DEL SISTEMA 8
2.5 ACL in Dettaglio
La struttura dell’ACL è la seguente:
i. Communication Layer, rappresenta l’interfaccia di comunicazione
per i moduli superiori.
ii. Identifier Layer, gestisce le relazioni indirizzo logico / indirizzo ip
porta, dei nodi.
iii. Queue Layer, livello delegato alla gestione delle code.
iv. Message Layer, livello incaricato delle comunicazioni TCP/IP.
Di seguito sono descritte le caratteristiche principali dei livelli riportati
sopra.
2.5.1 Communication Layer
Fornisce l’interfaccia di invio/ricezione dei messaggi ai moduli di livello superiore.
Alcuni dei metodi di invio offerti dall’interfaccia sono:
- SendToAny, che permette di inviare un messaggio ad un indirizzo
virtuale. Nel caso in cui quel nodo sia un superpeer virtuale per cui è
definito un cloneset il nodo destinatario viene scelto in maniera casuale
tra quelli appartenenti al cloneset;
- SendToAll, che permette di inviare un messaggio ad un indirizzo virtuale.
Nel caso un cui il nodo destinatario sia un superpeer virtuale per
cui è definito un cloneset, viene effettuato un broadcast del messaggio
a tutti i nodi del cloneset. Se il nodo mittente appartiene al cloneset
del destinatario il nodo mittente è escluso dal broadcast.
- SendAnswer, che permette di inviare un messaggio ad un indirizzo
fisico.

CAPITOLO 2. ARCHITETTURA DEL SISTEMA 9
Per effettuare le conversioni da identificatore virtuale ad identificatore fisico
si ricorre ad una funzione VirtualToPhysycalMap che provvede, dato un
id virtuale, a restituire un insieme di id fisici ad esso relativi.
I metodi invece relativi alla ricezione esposti dall’interfaccia sono:
- Receive, che permette di recuperare un messaggio da una coda specifica.
- RepeatReceive, che permette di ricevere un numero arbitrario di
messaggi in contemporanea.
2.5.2 Identifier Layer
La funzione principale dell’Identifier Layer consiste nel trasformare un identificatore
fisico in una coppia: indirizzo ip, porta.
2.5.3 Queue Layer
A questo livello vengono gestite le code dell’ACL e vengono implementati i
criteri relativi alla manipolazione dei messaggi sulle code.
Ad ogni modulo peer o superpeer sono associate un certo numero di code
che sono distinte sulla base del tipo di messaggi che possono contenere.
Su ogni coda è attivo un processo che si occupa di eliminare tutti i messaggi
presenti da troppo tempo, ovvero il cui tempo trascorso in coda supera
la soglia ammissibile (TTSIQ).
TTSIQ
Il Time To Spend In Queue, in breve TTSIQ, è un valore che indica quanto
tempo un messaggio può trascorrere in una coda prima di essere scartato.

CAPITOLO 2. ARCHITETTURA DEL SISTEMA 10
Questo meccanismo è stato introdotto per evitare che messaggi vecchi
restino in coda per troppo tempo e per fissare un limite superiore al numero
di “hops” che un messaggio può effettuare nella rete.
2.5.4 Message Layer
È il livello più basso dell’ACL e provvede ad instradare i messaggi basandosi
sul protocollo TCP/IP. La trasmissione è effettuata serializzando l’oggetto
messaggio e quindi procedendo al suo invio, mentre la ricezione provvede a
deserializzare il messaggio ricevuto.
2.6 Protocolli
Nel sistema XPeer sono definiti un certo numero di protocolli, alcuni di questi
richiedono che il nodo ricevente invii una risposta al termine dell’elaborazione
del messaggio, altri invece richiedono la semplice elaborazione senza alcun
riscontro.
Tra i protocolli teniamo a mettere in evidenza i seguenti:
- MetaSearch;
- MetaUpdate;
- SchemaUpdate.
Di seguito vengono descritti in dettaglio.
2.6.1 MetaSearch
Appartiene alla famiglia dei meta protocolli ed è delegato alla ricerca di risorse
nella rete. Ad esempio, ricercare nodi che hanno dati rilevanti ai fini di
un interrogazione.

CAPITOLO 2. ARCHITETTURA DEL SISTEMA 11
Questo protocollo di ricerca può potenzialmente visitare l’intera rete per
portare a termine il suo compito. Il nodo che avvia il protocollo prende il
nome di invoker.
Il protocollo è descritto dalle seguenti fasi:
i. Elaborazione Locale, in cui vengono determinati i nodi a cui inoltrare
il messaggio.
ii. Valutazione Tempo Trascorso In Coda (TTSIQ), incuiviene
aggiornato il valore TTSIQ del messaggio da propagare.
iii. Definizione Destinatari, in cui viene verificata la tabella di routing
del messaggio definita in fase di elaborazione locale nel caso in cui questa
risulti vuota viene inizializzata a valori di default: vengono aggiunti alla
tabella gli eventuali figli del nodo ed il suo padre omettendo il nodo
mittente.
iv. Risposta, se durante la fase di elaborazione locale sono stati riscontrati
valori utili allora si provvede a comunicarli all’invoker.
v. Propagazione, seilTTSIQ del messaggio è valido (cioè maggiore di
0) si provvede ad inoltrare il messaggio ai nodi riportati nella tabella
di routing definita nella fase elaborazione locale.
2.6.2 MetaUpdate
Questo protocollo è utilizzato principalmente per gestire la corretta sincronizzazione
dello stato del sistema. A differenza del protocollo MetaSearch
questo effettua un numero limitato di comunicazioni, dal momento che queste
sono effettuate risalendo l’albero di padre in padre, fino alla root.

CAPITOLO 2. ARCHITETTURA DEL SISTEMA 12
Ad esempio se la comunicazione originaria era al fine di ricercare un superpeer
che adottasse un nuovo peer, una volta che il superpeer decide di
adottare il peer che sta propagando il messaggio, inoltra il messaggio ricevuto
al padre con lo scopo di comunicare un aggiornamento del suo schema
(procedura di SchemaUpdate descritta in seguito).
Il protocollo è il seguente:
i. Elaborazione Locale, il messaggio viene elaborato localmente, in
base al tipo di informazione contenuta.
ii. Invio Ack, teminata la fase i viene inviato un ack al nodo che ha
inviatolarichiesta.
iii. Inoltro a Padre, il messaggio eventualmente modificato viene inviato
al padre.
iv. Attesa Ack da Padre, il nodo resta in attesa di ricevere un ack dal
nodo padre che comunica l’avvenuta elaborazione del messaggio che gli
è stato inoltrato.
2.6.3 SchemaUpdate
Il protocollo di SchemaUpdate si basa sul protocollo di MetaUpdate il suo
scopo è quello di comunicare modifiche allo schema locale associato ad un
nodo del sistema.
A livello di peer il protocollo si innesca a seguito di una modifica alla
base di dati locale, questo provvede a comunicare al proprio nodo padre il
suo nuovo schema mediante un messaggio di SchemaUpdate.
A livello di superpeer virtuale è innescato a seguito di una modifica dell’unione
degli schemi dei figli relativi ad un superpeer virtuale, modifica indotta

CAPITOLO 2. ARCHITETTURA DEL SISTEMA 13
a causa dell’aggiunta/rimozione di un peer dall’insieme dei figli del SPV padre
oppure a seguito di una notifica di modifica allo schema associato ad un
nodo figlio.
Questo protocollo basato, come accennato, sul protocollo di MetaUpdate
segue anch’esso la propagazione in risalita verso la root.
2.7 Cloning e Splitting
In questa sezione sono descritti due meccanismi molto importanti al fine di
mantere il sistema sempre e costantemente in condizioni di carico ottimali.
2.7.1 Cloning
Il meccanismo di cloning si attiva non appena si verifica un degrado delle
prestazioni del sistema, il quale provvede a riportarsi in condizioni di normalità
attraverso un processo che porta i superpeer virtuali sovraccarichi a
clonarsi.
Figura 2.1: Nella figura è mostrato un SPV prima (a) e dopo (b) della
clonazione
Nel processo di cloning viene aggiunto un nuovo superpeer al cloneset del
superpeer virtuale sovraccarico, in altre parole il cloning provvede ad aumen-

CAPITOLO 2. ARCHITETTURA DEL SISTEMA 14
tare la cardinalità diuncloneset.
Le entità all’interno del cloneset hanno il compito di comunicare a tutte
le altre eventi di interesse comune, ovvero eventi relativi a modifiche topologiche
della rete. Ad esempio, in seguito alla registrazione/deregistrazione di
un peer o all’aggiornamento dello schema dello stesso.
Il meccanismo di cloning può essere descritto dai seguenti passi:
i. ricerca un nuovo superpeer mediante un apposito protocollo;
ii. il nuovo superpeer viene aggiunto al cloneset;
iii. vengono aggiornati gli ACL relativi al padre ed ai figli del nuovo clone.
2.7.2 Splitting
Il meccanismo di splitting provvede a ridurre i costi di sincronizzazione tra
i superpeer di un cloneset dividendo il cloneset in due. Questo processo
viene attivato non appena i costi di sincronizzazione all’interno del cloneset
superano una certa soglia.
Figura 2.2: Nella figura è mostrato un SPV prima (a) e dopo (b) dello
splitting, mettendo in evidenza la ridistribuzione dei peer
Inoltre durante la ripartizione dei peer del cloneset originale si cerca di
assegnare peer con schemi simili allo stesso insieme in modo da ottenere suc-

CAPITOLO 2. ARCHITETTURA DEL SISTEMA 15
cessivamente in fase di compilazione delle interrogazioni, un miglioramento
in temini di comunicazioni.
Il processo di splitting è riassunto nelle seguenti fasi:
i. Si ricerca all’interno del superpeer virtuale (SPV) un clone a cui delegare
la procedura di splitting. La selezione è effettuata a livello di
ACL.
ii. Se il clone selezionato ha troppi figli si cerca di far adottare i figli in
eccesso ad altri superpeer virtuali. La scelta dei figli da far adottare è
effettuata di modo da rispettare caratteristiche di omogeneità tra i figli
restanti.
iii. Se la fase di adozione risolve il sovraccarico si termina qui. Al contrario
si procede con lo splitting vero e proprio (fase iv).
iv. Vi sono due possibili scenari:
i. Il SPV è un nodo intermedio: si creano due nuovi cloneset a
partire dal SPV di partenza e viene loro assegnato come padre lo
stesso del SPV che sta effettuando lo splitting.
ii. Il SPV èlaroot: si crea una nuova radice e a questo punto si
effettua la divisione del cloneset e si procede come riportato nella
fase iv-i.

Capitolo 3
Modello dei Dati
3.1 XML
L’Extensible Markup Language (XML) sviluppato dal W3C a partire dal
1996, è un metalinguaggio di annotazione (markup) derivatodaSGML (ISO
8879). Attualmente il formato XML è usato per molteplici scopi, di cui uno
dei principali è sicuramente lo scambio di dati fra sistemi informativi diversi,
interconnessi via Internet. Molti linguaggi di successo sono basati su XML
come SVG, XHTML, GML e RSS.
XML si è imposto come standard de facto per lo scambio di informazioni
semi-strutturate.
3.1.1 Documenti XML
Un documento XML è costituito da due parti: il prologo eilcorpo, entrambe
opzionali. Il prologo è a sua volta composto dalla dichiarazione XML ela
dichiarazione del tipo di documento.
La dichiarazione XML indica a quale versione della specifica XML il documento
è conforme, può inoltre specificare la codifica di carattere utilizzata:
16

CAPITOLO 3. MODELLO DEI DATI 17
La dichiarazione del tipo di documento (Document Type Declaration,
DTD) definisce la struttura che il documento XML deve rispettare. In
particolare:
- definisce i soli elementi leciti all’interno del documento;
- definisce la struttura di ogni elemento: cosa può contenere, l’ordine,
la quantità di elementi che possono comparire e se sono opzionali o
obbligatori;
- dichiara una serie di attributi ammissibili per ogni elemento e quali
valori possono o devono assumere.
Durante il processo di validazione il documento XML viene confrontato
con il DTD e se tutte le regole all’interno del DTD sono state rispettate il
documento si dice valido. La dichiarazione di tipo del documento può essere
inclusa direttamente nel file XML (inline) o può contenere un riferimento ad
un documento esterno.
Il corpo di un documento XML è costituito da un insieme di tag di diversi
tipi:
- Tag di apertura, che ha la seguente sintassi:
Sono specificati un nome ed un insieme di coppie nomeAttributo-valore.
- Tag di chiusura:

CAPITOLO 3. MODELLO DEI DATI 18
- Tag vuoto:
I nomi dei tag non sono imposti dalla specifica XML, possono essere scelti
liberamente per consentire la massima flessibilità nell’uso del linguaggio.
3.1.2 Elementi
Un elemento è tutto ciò cheècompreso fra un tag di apertura e il corrispondente
tag di chiusura. Il contenuto è tutto ciò che si trova fra i due tag.
Gli elementi possono essere classificati in base al loro contenuto:
- complesso: se il contenuto è un insieme di altri elementi;
- semplice: se il contenuto è semplice testo;
- misto: se il contenuto è una combinazione di elementi e testo;
- vuoto: quando non ha elementi figli nè testo.
Se l’elemento è vuoto può essere espresso da un tag vuoto invece che da
un tag di apertura seguito da uno di chiusura.
La specifica XML impone una serie di restrizioni sugli elementi:
- il tag di chiusura di un elemento deve avere lo stesso nome del tag di
apertura dello stesso;
- ad ogni tag di apertura deve corrispondere un tag di chiusura all’interno
del documento;
- gli elementi devono essere correttamente annidati, ovvero il tag di
chiusura di un elemento deve essere dichiarato all’interno dello stesso
elemento che contiene il corrispettivo tag di apertura;

CAPITOLO 3. MODELLO DEI DATI 19
- all’interno di un tag di apertura o di un tag vuoto può comparire una
sola coppia nomeAttributo-Valore con il medesimo nomeAttributo.
Un’ulteriore restrizione consiste nel fatto che ogni documento XML debba
dichiarare un elemento radice (document element) che contiene tutti gli altri.
3.1.3 Altri Costrutti
Oltre agli elementi il documento XML può contenere altri costrutti come i
commenti, leistruzioni di elaborazione elesezioni CDATA.
I commenti permettono di inserire informazioni all’interno del documento
che l’elaboratore XML ignorerà completamente ed hanno la seguente
sintassi:
Le istruzioni di elaborazione permettono al documento di contenere
istruzioni per i programmi:
Il parametro Target permette di identificare l’applicazione a cui le istruzioni
sono indirizzate.
Una sezione CDATA permette di delimitare una parte del contenuto di
un elemento affinchè venga processata dal parser XML come testo normale,
ovvero senza interpretare in alcun modo la parte selezionata. Una sezione
CDATA è espressa con la seguente sintassi:
Le sezioni CDATA sono ad esempio utili per includere nel documento XML
frammentidicodicecometesto.

CAPITOLO 3. MODELLO DEI DATI 20
3.2 XML Schema 1.1
L’XML Schema è un linguaggio di descrizione di documenti XML che permette
di esprimere un insieme di vincoli e regole, che prende appunto il nome
di schema, applicabili ad un documento XML.
I vincoli possono riguardare quali elementi sono permessi, quali tipi di
dati sono ad essi associati e quale relazione gerarchica hanno fra loro gli elementi
contenuti in un documento XML. La creazione di questo schema di
fatto comporta la definizione di un modello che il documento XML di riferimento
deve rispettare.
La validazione è il processo mediante il quale si verifica se un determinato
documento XML rispetta o meno le regole del modello ad esso associato, nel
qual caso si dice che il documento XML è valido.
Una istanza di schema XML èunXML Schema Definition (XSD) ed è
di solito contenuto in un file con l’estensione “.xsd”.
Per associare ad un documento XML uno schema si utilizzano degli attributi
associati al namespace XSI (XML Schema Instance) sull’elemento
radice, ad esempio:
Basi di Dati Laboratorio
6
AA023
Giorgio Ghelli
Carlo Sartiani

CAPITOLO 3. MODELLO DEI DATI 21
Il corrispondente file XSD potrebbe essere il seguente:
3.2.1 Struttura
La struttura di un documento XML viene esplicitata in XML Schema mediante
la definizione di tipi complessi a contenuto complesso e misto.
I tipi complessi a contenuto complesso, costituiti da altri elementi
ma senza nodi testo, sono definiti mediante l’utilizzo dell’elemento xs:complexType
specificando all’interno quali elementi devono comparire e con quale ordine.
Esistono diverse modalità di composizione degli elementi:
- sequenza (xs:sequence), definisce una lista ordinata di elementi che
devono comparire all’interno dell’elemento complesso;

CAPITOLO 3. MODELLO DEI DATI 22
- scelta (xs:choice), definisce una lista di elementi di cui uno deve comparire
all’interno dell’elemento complesso;
- tutti (xs:all), definisce una lista non ordinata di elementi che devono
tutti comparire all’interno dell’elemento complesso.
Le modalità sequenza e scelta permettono anche di specificare le cardinalità
minime e massime dei vari elementi attraverso l’uso degli attributi
minOccurs e maxOccurs, che possono assumere un qualsiasi valore numerico
intero maggiore o uguale di zero oppure il valore speciale unbounded per
indicare un numero illimitato:
La modalità tutti permette di specificare solo l’attributo minOccurs con
valore zero, considerato che tutti gli elementi al suo interno possono comparire
al massimo una volta.
I tipi complessi a contenuto misto sono in grado di contenere sia nodi
testuali che altri elementi e la loro definizione è uguale a quella di elemento
a contenuto complesso tranne che per l’utilizzo dell’attributo mixed settato
a true.
Gli attributi, analogamente agli elementi, sono fortemente tipati ed è
possibile specificare l’obbligatorietà oppure il valore predefinito:
...

CAPITOLO 3. MODELLO DEI DATI 23
3.2.2 Tipi di Dato
XML Schema mette a disposizione un’ampia gamma di tipi di dati primitivi,
per citare solo i più usati:string, integer, long, double, date, time efornisce
gli strumenti per la creazione di nuovi tipi a partire dai tipi predefiniti; tale
operazione prende il nome di derivazione.
La creazione di un nuovo tipo semplice,utilizzato per rappresentare il
contenuto di un attributo o di un nodo testuale (per differenziarlo dai tipi
complessi), può avvenire in tre modi differenti:
- per restrizione quando vengono applicati dei vincoli ai tipi predefiniti;
- per lista quando il tipo derivato è definito come una lista di un tipo
pre-esistente;
- per unione quando il tipo derivato è definito dall’unione di due tipi
pre-esistenti.
La definizione di un tipo semplice avviene utilizzando l’elemento xs:simpleType.
La derivazione per restrizione èforselaformapiùcomune e semplice
di creazione di un nuovo tipo. Le restrizioni agiscono su tre livelli differenti:
- a livello della gestione degli spazi bianchi;
- a livello lessicale;

CAPITOLO 3. MODELLO DEI DATI 24
- a livello dei valori che il tipo può assumere.
La derivazione per lista crea un tipo derivato costituito da più istanze
di un tipo pre-esistente separate da spazi bianchi; la sintassi è la seguente:
La derivazione per unione invece permette di definire nuovi tipi unendo
gli spazi dei valori di alcuni tipi già esistenti ed utilizza l’elemento xs:union
il cui attributo memberTypes permette di definire i tipi, separati da uno
spazio, che entreranno a far parte dell’unione:
3.2.3 Namespace
I namespace rappresentano un insieme di elementi e attributi che appartengono
ad un medesimo contesto.
Un elemento potrebbe infatti assumere un significato differente, e di conseguenza
anche una struttura differente, a seconda del contesto di appartenenza.

CAPITOLO 3. MODELLO DEI DATI 25
Per risolvere eventuali conflitti sono stati introdotti i namespace. I namespace
vengono definiti all’interno di un documento XML mediante l’attributo
xmlns (XML namespace) la cui sintassi è:
xmlns:prefisso="URI"
dove l’uri identifica univocamente il namespace ed il prefisso serve a
riconoscere il namespace di appartenenza dei vari elementi all’interno del
documento XML.
3.3 XPath
XML Path Language (XPath) 2.0 è un linguaggio di espressioni che permette
di selezionare porzioni di un documento XML. Illinguaggio XPath è basato
su una rappresentazione logica ad albero (XPath and XQuery Datamodel)
del documento XML e fornisce gli strumenti per navigare l’albero e selezionare
i singoli nodi secondo una varietà di criteri.
3.3.1 XPath Datamodel
XPath opera su un modello astratto, rappresentato da un albero di nodi,
ognuno dei quali è la rappresentazione di un costrutto XML dichiarato nel
documento XML.
Ad ogni nodo dell’albero sono associate un insieme di informazioni (alcune
comuni, altre proprie di un certo tipo di nodo) dette proprietà.
Ad esempio, i nodi di tipo radice ed elemento hanno la proprietà children,
una lista ordinata di nodi figli. Tutti i nodi, eccetto la radice, hanno la
proprietà parent che indica il nodo padre, che deve essere un nodo elemento
o radice. Un nodo radice o elemento è il padre di tutti i nodi contenuti nella

CAPITOLO 3. MODELLO DEI DATI 26
sua lista dei figli. I discendenti di un nodo sono i figli del nodo e i loro (dei
figli) discendenti, ovvero tutto il sottoalbero radicato nel nodo che stiamo
considerando.
Fra i nodi è definito un ordinamento, corrispondente all’ordine in cui
le rappresentazioni dei rispettivi nodi sono state dichiarate nel documento
XML. Quindi il nodo radice sarà il primo nodo; un nodo elemento precederà
i suoi figli e i suoi discendenti. Il nodo namespace segue l’elemento a cui è
associato, i nodi attributo seguono l’eventuale nodo namespace.
I nodi dell’albero possono essere di tipi differenti:
- radice, è la radice dell’albero e corrisponde logicamente all’elemento
radice;
- elemento, incapsula un elemento XML;
- testo, incapsula un contenuto di tipo testuale;
- attributo, è la rappresentazione di un attributo del nodo a cui è
associato;
- namespace, indica il namespace del nodo a cui è associato.
3.3.2 Valutazione
La valutazione di una espressione XPath produce un oggetto che può essere
di quattro tipi diversi:
- un insieme di nodi (una collezione non ordinata di nodi senza duplicati);
- un valore booleano;
-unnumero;

CAPITOLO 3. MODELLO DEI DATI 27
- una stringa.
La valutazione di un’espressione XPath dipende dal contesto in cui agisce l’
espressione. Il contesto è costituito dai seguenti elementi:
-unnodo(il nodo di contesto);
- la posizione del nodo di contesto nell’ordine del documento (context
position);
- un insieme di legami di variabile (variable bindings);
- una libreria di funzioni.
I legami di variabile consistono in una funzione di mapping da nomi di variabile
ai relativi valori.
La libreria di funzioni consiste in una funzione di mapping da nomi di
funzioni a funzioni. Ogni funzione prende zero o più elementi e restituisce
un singolo risultato.
3.3.3 Espressioni
Esistono diversi tipi di espressioni, le più importanti sono quelle primarie e
quelle di cammino.
Primarie
Sono le espressioni di base, a partire da cui vengono poi costruite espressioni
più complesse, comprendono i letterali, i riferimenti a variabile, le chiamate
di funzione e le parentesi per controllare l’ordine di valutazione.
Cammino(Location path)
Un location path è un’espressione XPath che consente di selezionare un insieme
di nodi relativi al nodo di contesto. La valutazione di un’espressione

CAPITOLO 3. MODELLO DEI DATI 28
di un location path produce un insieme di nodi contenenti i nodi specificati
dal location path stesso.
Un location path può contenere, in modo ricorsivo, espressioni che consentono
di filtrare l’insieme di nodi. La sintassi di un location path ècomposta
da uno o più location step separati l’uno dall’altro da una barra (“/”):
step1/step2/step3
Ogni location step, inoltre, consente di selezionare un set di nodi relativo
al nodo di contesto, ovvero al nodo selezionato dal location step precedente.
Un location path espresso in questo modo è un location path relativo. Un
location path assoluto inizia con l’elemento principale che può essere “/”,
nelqualcasoilcontestoinizialeèrappresentato dal nodo radice, o “//” che
inizializza il contesto a tutti i nodi dell’albero.
I location step di un location path vengono valutati da sinistra a destra.
Il primo location step a sinistra consente di selezionare un set di nodi relativi
al nodo di contesto. Tali nodi, quindi, diventano il contesto utilizzato per
poter elaborare il location step successivo. L’elaborazione dei singoli location
step e l’aggiornamento dei nodi di contesto vengono ripetuti fino a quando
non saranno elaborati tutti i location step.
Un location step è composto da tre parti:
-unasse (axis), che specifica la relazione di parentela all’interno dell’albero
tra il nodo di contesto ed i nodi che si vogliono selezionare;
-unnode-test, che specifica il tipo di nodo che vogliamo selezionare;
- zero o più predicati per filtrare ulteriormente l’insieme di nodi selezionati.

CAPITOLO 3. MODELLO DEI DATI 29
La sintassi per un location step è la seguente:
axis-name::node-test[pred-expression]
L’insieme di nodi selezionato dal location step è l’insieme di nodi generati
dall’axis edalnode-test filtrati da tutte le espressioni di filtro che seguono.
Axes
XPath mette a disposizione una grande varietà di metodi per selezionare i
nodi all’interno di un albero; riportiamo solo i principali:
- figlio (child), seleziona i figli del nodo di contesto;
- discendenti (descendant), seleziona i discendenti del nodo di contesto,
da notare che sono esclusi i nodi di tipo attributo e namespace;
- padre (parent) seleziona il padre del nodo di contesto, se esiste;
- antenato (ancestor) seleziona gli antenati del nodo di contesto;
- se stesso (self ), seleziona il solo nodo di contesto.
3.4 XQuery
La grande diffusione dello standard XMLharesonecessariolacreazionedi
strumenti e tecniche per interrogare i dati XML. XQuery nasce da queste
esigenze ed è il linguaggio standard di interrogazione per XML. XQuery condivide
con XPath sia il modello dei dati che l’intero insieme delle espressioni;
inoltre mette a disposizione altre espressioni, di cui le più importanti sono le
espressioni FLWOR.
3.4.1 Le espressioni FLWOR
Le espressioni FLWOR derivano il proprio nome dalle cinque clausole che le
compongono: For, Let, Where, Order by e Return. Una espressione FLWOR

CAPITOLO 3. MODELLO DEI DATI 30
deve specificare almeno una clausola let o for e necessariamente una clausola
return.
for $var1 in expr1 , $var2 in expr2
let $var2 := expr2 ,$var3 := expr3
where condizione
order by ordinamento
return expr3
Le clausole for e let generano un flusso di tuple, dove ogni tupla mantiene dei
legami tra un nome di variabile e una sequenza di item. La clausola where
filtra le tuple che vengono poi ordinate dalla clausola order by. Infine la clausola
return viene eseguita per ogni tupla prodotta e i risultati concatenati
per ottenere il risultato dell’espressione FLWOR.
In dettaglio la clausola for contiene una o più variabili, ognuna con una
espressione associata (il cui valore è chiamato binding sequence). La clausola
for itera su ogni variabile nella binding sequence, il flusso di tuple risultante
contiene una tupla per ogni combinazione di valori nelle rispettive binding
sequence. Ad esempio:
for $i in (1, 2), $j in (3, 4)
Il flusso generato dalla clausola for soprastante sarebbe la seguente:
($i = 1, $j = 3)
($i = 1, $j = 4)
($i = 2, $j = 3)
($i = 2, $j = 4)
Una clausola let può contenereunaopiùvariabili, ognuna associata ad una
espressione. Diversamente da una clausola for, la clausola let lega ogni variabile
all’intera binding sequence, ovvero non è presente iterazione. I legami

CAPITOLO 3. MODELLO DEI DATI 31
di variabile così generati sono aggiunti ad ogni tupla generata dalla clausola
for. Nel caso non siano presenti clausole for, viene generata una sola tupla
contenente i legami di variabile della clausola let.
Sebbene entrambe le clausole for e let generino dei legami di variabile, il
modo con cui sono legate è molto differente; per chiarirlo ricorriamo ad un
esempio, supponiamo di avere la seguente espressione:
let $s := (, , )
return {$s}
il risultato è il seguente:
Consideriamo la stessa espressione utilizzando al posto di una clausola let
una clausola for:
for $s in (, , )
return {$s}
Il risultato, molto differente dal precedente, è il seguente:

CAPITOLO 3. MODELLO DEI DATI 32
L’espressione nella clausola where viene valutata per ognuna delle tuple nel
flusso. Se il valore dell’espressione è false la tupla viene scartata.

Capitolo 4
Compilazione
Il capitolo introduce l’algebra di interrogazione per poi spiegare in dettaglio
le fasi di compilazione ed interrogazione.
4.1 Algebra di Interrogazione
L’algebra di interrogazione è una evoluzione dell’algebra per dati XML centralizzati
descritta in (Sar03). Il modello dei dati è stato esteso per poter
modellare il concetto di dati distribuiti tra più peer, e di conseguenza è stata
introdotta una nuova classe di operatori per la sua gestione.
4.1.1 Modello dati
Un documento XML ben-formato può essere rappresentato come un albero
di nodi etichettati, detto istanza del modello dei dati.
I nodi interni sono etichettati col loro nome, mentre le foglie col loro contenuto.
Ad ogni nodo è inoltre associato un identificatore unico (oid), locale
ad ogni singolo peer, ed un identificatore del peer (location, abbreviato loc).
Da ora in poi utilizzeremo la stessa scrittura loci perindicaresialalocation
che identifica un peer, sia le istanze del modello dei dati da esso pubblicato.
33

CAPITOLO 4. COMPILAZIONE 34
Le istanze del modello dei dati sono rappresentate come termini, generate
dalla grammatica riportata in [Appendice C.1]. Consideriamo un peer identificato
dalla location loc1 e supponiamo che pubblichi il seguente documento
XML:
IDA Pro
Halvar
2005
Disassembling
Kaspersky
2007
La corrispettiva istanza di modello sarebbe la seguente:
Figura 4.1: Istanza del modello.
Ad ogni nodo sono quindi associate tre funzioni:

CAPITOLO 4. COMPILAZIONE 35
- label(n): restituisce l’etichetta associata al nodo n
- oid(n): restituisce l’oid associataalnodon
- loc(n): restituisce la location associata al nodo n
4.1.2 Operatori
Gli operatori algebrici manipolano strutture intermedie (Env) di tipo relazionale
che servono a collezionare i binding di variabile generati durante la
valutazione dell’interrogazione.
Una struttura Env rappresenta un insieme di tuple, dove ogni tupla mantiene
un insieme di associazioni tra nomi di variabile e una sequenza di nodi,
identificati tramite la coppia: oid, loc.
Gli operatori possono essere suddivisi in tre classi: di bordo, tradizionali
e quelli sulle locazioni.
OperatoridiBordo
Path L’operatore pathf(t) data una istanza del modello dei dati t ed un
input filter f produce una nuova struttura Env le cui tuple e binding
di variabili sono creati come specificato nell’input filter. L’input filter
indica quali nodi devono essere estratti dall’istanza dei dati e a quali variabili
devono essere legati. Un input filter è descritto dalla grammatica
riportata in [Appendice C.7.1];
Return L’operatore Return returnof(e) svolge l’operazione complementare
all’operatore Path, ovvero riceve in ingresso una struttura Env e
produce un frammento XML. La struttura del frammento è specificata
da un output filter. La grammatica dell’ output filter è riportata in
[Appendice C.8.1].

CAPITOLO 4. COMPILAZIONE 36
Operatori Tradizionali
Sigma (Selezione) L’operatore di selezione σpred(e) prende in ingresso una
struttura Env e, e ne produce una nuova contenente le sole tuple che
soddisfano il predicato P eliminando le altre.;
Union L’operatore Union prende in ingresso due strutture Env e1 ee2, con
la medesima struttura delle tuple, e produce una nuova struttura Env
contenente l’unione delle tuple in e1 ed e2.
Operatori su Location
L’operatore LocUnion, specificato come loc1 • loc2, produce l’unione delle due
sequenze di termini ottenute dalla valutazione di loc1 eloc2. Questo operatore
permette di specificare interrogazioni i cui dati provengono da molteplici peer,
è quindi fondamentale nell’ambiente distribuito di XPeer.
4.2 Protocollo di Compilazione
L’immisione di una interrogazione da parte di un utente innesca il protocollo
di compilazione. Lo scopo del protocollo di compilazione è trovare in modo
selettivo, tra i peer della rete, quelli che possiedono i dati interessanti per la
query sottomessa, escludendo quelli che sicuramente non hanno dati interessanti.
Questo approccio permette di limitare significativamente il numero di
peer contattati per l’esecuzione della query, ma non esclude totalmente che
si possano contattare peer che non producono alcun dato per l’interrogazione
corrente.
Per raggiungere questo scopo ad ogni peer viene associato uno schema,
o tree-guide. Questa struttura dati descrive in modo compatto il documento
XML pubblicato. Analogamente, ad ogni superpeer è associato un superschema
ottenuto per unione dei tree-guide dei suoi figli, siano essi peer o

CAPITOLO 4. COMPILAZIONE 37
superpeer. Ogni superpeer inoltre memorizza anche i singoli schemi dei figli.
Il protocollo di compilazione è una istanza del protocollo di MetaSearch.
Il protocollo è innescato da un peer, il quale invia un messaggio contenente
l’intero albero logico rappresentante l’interrogazione.
Ogni superpeer che riceve un messaggio di compilazione identifica quali figli
possiedono uno schema compatibile con l’interrogazione e li notifica al peer
di origine; se i figli sono superpeer il messaggio viene inoltrato ai soli con
schema compatibile.
Figura 4.2: Esempio Compilazione
Quando lo schema di un superpeer figlio non è compatibile significa che
nessun peer discendente contiene dati interessanti. L’effetto finale è che vengono
“potati” interi sottoalberi che non verrano mai raggiunti dalla richiesta
di compilazione, limitando quindi il carico sul sistema.
Il peer che ha inoltrato l’interrogazione attende di ricevere le risposte dai
superpeer per un certo intervallo di tempo, ovvero attende fino allo scattare
di un timeout, momento in cui il protocollo di compilazione termina e l’elen-

CAPITOLO 4. COMPILAZIONE 38
co dei peer con schema compatibile viene utilizzato per completare l’albero
logico relativo all’interrogazione.
Una caratteristica del sistema è che ogni messaggio di richiesta di compilazione
raggiunge sempre il superpeer radice dell’overlay network. La radice
inoltre è a conoscenza del super-schema relativo all’intero database distribuito
del sistema. Lo svantaggio implicito dell’ approccio utilizzato èchequesto
comporta un enorme carico sulla radice, la quale quindi, per evitare problemi
relativi a sovraccarico, deve essere opportunamente clonata in modo da
ridistribuire il carico nel suo cloneset.
4.3 Tree-Guide
Il tree-guide è una foresta di alberi di nodi etichettati, dove ogni albero descrive
tutte le navigazioni possibili su un singolo documento XML di origine,
ovvero che danno risultato non vuoto.
Per ogni cammino di un albero del tree-guide, dalla radice a ogni altro nodo,
esiste almeno un cammino nel documento XML dalla radice a un nodo
interno (non foglia) con la stessa sequenza di etichette del cammino.
Il tree-guide è inferito automaticamente dal documento XML con un algoritmo
che visita l’intera istanza del modello dei dati, raggruppando in un
unico nodo del tree-guide tutti gli elementi figli, di uno stesso elemento, che
hanno etichetta uguale.
Ad esempio dato il seguente frammento XML
Basi di Dati Laboratorio

CAPITOLO 4. COMPILAZIONE 39
Giorgio Ghelli
BDL
Architetture Parallele e Distribuite
Marco Vanneschi
ASE
il tree-guide associato è riportato in figura [4.3].
Figura 4.3: Tree-Guide
Ad ogni foglia è associato un nodo di tipo filtro, che non viene considerato
ai fini della navigazione ma che contiene informazioni aggiuntive sui valori
posseduti dalla foglia nel documento XML. Le informazioni sono memorizzate
in modo compatto facendo ricorso a due strutture dati differenti: i filtri di
Bloom eleliste di valori. Entrambe le strutture vengono create ed associate
al nodo foglia al momento del caricamento dei dati, contestualmente alla
creazione del tree-guide.
In aggiunta alla descrizione dei valori, il nodo filtro specifica anche il

CAPITOLO 4. COMPILAZIONE 40
tipo dei valori posseduti dal nodo foglia a cui è associato. Attualmente sono
supportati solo i tipi integer e string. L’informazione sul tipo viene ricavata
durante il processo di validazione, se al documento XML è stato associato
uno schema, altrimenti vengono inferiti durante il caricamento dei dati.
4.3.1 Filtri di Bloom
Un filtro di Bloom è una struttura dati di tipo probabilistico usata per testare
l’appartenenza di un elemento ad un insieme. Le caratteristiche principali
sono:
- consumo di memoria limitato;
- operazioni di inserzione ed interrogazione in tempo costante;
- assenza di falsi negativi.
Un filtro di Bloom è composto da un vettore di m bit, inizialmente settati
tutti a 0, e da k diverse funzioni di hash indipendenti h1(x),...,hk(x) che producono
un valore (si suppone distribuito uniformemente) nel range [1,...,m].
La probabilità di falsi positivi cresce all’aumentare degli elementi aggiunti
all’insieme, in dettaglio dopo l’inserzione di n elementi la probabilità P di un
falso positivo è data dalla seguente formula:
i. P = 1 − e kn/m k
La formula [i] raggiunge il suo minimo per valori di: k = ln2 ∗ m/n, nel
qual caso diventa:
ii. (1/2) k =(0.6185) m/n .

CAPITOLO 4. COMPILAZIONE 41
La scelta dei valori di k e m risulta quindi cruciale per il corretto ed
efficente funzionamento dei filtri di Bloom. Nella nostra implementazione
abbiamo scelto di usare 5 funzioni di hash e utilizzare un rapporto m/n di
valore 8 (facendo delle previsioni sul numero n di valori che ci aspettiamo
vengano inseriti), che ci garantisce una probabilità di falsi positivi di 0.0217.
Per inserire un elemento a si applicano in sequenza le k funzioni di hash
p1=h1(a),...,pk=hk(a) e si pongono ad 1 gli elementi pi all’interno del vettore
di bit. Un bit può essere posto ad 1 più volte, impedendo quindi la rimozione
di un elemento dall’insieme a meno di non sostituire il vettore di bit con un
vettore di contatori.
elemento a
h
h
h
h
a) = p
1( 1
a) = p
2( 2
a) = p
3( 3
a) = p
4( 4
Vettore di bit
Figura 4.4: La figura mostra un esempio di inserimento.
Per verificare che un generico elemento b appartenga all’insieme, le k
funzioni di hash p1=h1(b),...,pk=hk(b) vengono applicate a b. L’elemento b
appartiene all’insieme con una certa probabilità 1-P(sivedai)setuttiibit
nelle posizioni pi sono tutti posti ad 1, altrimenti l’elemento non appartiene
all’insieme.
1
1
1
1

CAPITOLO 4. COMPILAZIONE 42
4.3.2 Liste di Valori
Le liste di valori sono delle liste di valori posseduti dalla foglia nel documento
XML. Poichè il nodo filtro deve essere di dimensione limitata, non possono
essere inclusi tutti i valori presenti nel documento XML ma solo un estratto.
Inoltre è stata presa la decisione di memorizzare nelle liste solo valori di tipo
numerico.
4.3.3 Unione Tree-guide
L’operazione di unione di due tree-guide viene calcolata da un superpeer su
tutti i tree-guide dei suoi figli. L’unione di due tree-guide avviene con un
algoritmo che visita entrambi gli alberi e raggruppa in un unico nodo tutti
gli elementi dello stesso livello con etichetta uguale.
Figura 4.5: La figura mostra il tree-guide risultante (c) dall’unione di due
tree-guide (a) e (b)
L’unione di due o più nodi filtro comporta l’unione delle strutture dati in
essi contenute. L’unione di due filtri di Bloom è una semplice operazione di
or sui due vettori di bit (che devono avere necessariamente la stessa dimensione).
L’unione di due liste di valori comporta la creazione di una nuova
lista contenente gli elementi di entrambe senza ripetizioni.

CAPITOLO 4. COMPILAZIONE 43
In seguito all’unione di due filtri di Bloom viene verificato che la cardinalità
dei bit settati ad 1 non superi una certa soglia oltre la quale la probabilità
di un falso positivo risulta troppo elevata.
Analogamente per liste di valori viene verificato che la cardinalità della lista
risultante dalla unione non superi una certa soglia, oltre la quale la struttura
richiede un consumo di memoria troppo elevato.
In entrambi i casi in cui viene superata la soglia, la corrispettiva struttura
dati viene marcata come wildcard, ovveroècome se contenesse tutti i valori
possibili.
4.4 Albero Logico
Il primo passo della fase di compilazione consiste nel trasformare l’interrogazione
nell’albero logico corrispondente. Ad esempio la seguente query,
verrebbe tradotta nell’albero logico riportato in figura[4.6].
for $c in $db//course,
$t in $c/title
where $t="ASE"
return $c
L’albero logico come accade anche nei database tradizionali, è una struttura
dati intermedia che descrive la query in modo strutturato e permette di
manipolarla con facilità, ad esempio per applicare ottimizzazioni prima che
venga tradotto nell’albero fisico.
La radice di un albero logico è sempre un operatore Return, mentre le
foglie sono sempre operatori Path. L’operatore Path rappresenta le navigazioni
da fare sull’intero database distribuito. Poichè il database distribuito è
composto dall’insieme di tutti i documenti pubblicati dai peer, sarebbe sufficiente
assegnare ad ogni Path una funzione location ottenuta come unione di

CAPITOLO 4. COMPILAZIONE 44
Figura 4.6: Esempio di Albero Logico
tutte le funzioni location dei peer presenti nel sistema. Questa soluzione ha
l’ovvio svantaggio (non trascurabile) che nella fase successiva di esecuzione
verrebbero contattati anche peer che non hanno dati interessanti.
Lo scopo della fase di compilazione è appunto di determinare l’insieme
dei soli peer rilevanti ovvero tutti quelli che al momento dell’esecuzione produranno
qualche risultato.
La fase di compilazione termina quindi con il completamento dell’albero
logico, specificando per ogni nodo Path foglia, la funzione location da utilizzare,
costruita come l’unione (tramite l’operatore LocUnion) delle location
(operatore Location) corrispondenti ai peer compatibili.
Poichè per determinare esattamente quali peer sono interessanti sarebbe
necessario eseguire l’esecuzione su tutti i peer presenti nel sistema, di fatto
rendendo inutile la fase di compilazione distribuita, si preferisce determinare
l’insieme di peer che potrebbero produrre risultati.

CAPITOLO 4. COMPILAZIONE 45
Figura 4.7: Esempio di Albero Logico
4.5 Algoritmo di Schema Matching
L’algoritmo eseguito da ogni superpeer per verificare la compatibilità diun
interrogazione con gli schemi dei figli è chiamato schema matching. L’algoritmo
di schema matching consiste nell’esecuzione simulata dell’interrogazione
sullo schema.
L’esecuzione simulata inizia dall’operatore Path, che effettua una navigazione
all’interno del tree-guide producendo tuple, ad ognuna delle quali è
associato l’identificatore del nodo Path che l’ha generata.
Se viene prodotta almeno una tupla, significa che la corrispondente navigazione
effettuata sul documento XML di origine, posseduto da un peer,
produrrebbe almeno una tupla. Questo accade per via della proprietà pos-

CAPITOLO 4. COMPILAZIONE 46
seduta dal tree-guide enunciata precedentemente.
L’operatore Sigma ha il compito di filtrare le tuple in base ad un predicato
composto da più condizioni semplici, della forma var operatore-confronto
costante, collegate da operatori logici and e or.
La valutazione del predicato avviene valutando le condizioni nel seguente
modo:
i. dal nome di variabile contenuta nella condizione si risale, attraverso
i legami di variabile contenuti nella tupla, al nodo del tree-guide
associato;
ii. dal nodo precedentemente identificato si risale al nodo filtro associato
e si usano le informazioni contenuto in esso per valutare la consizione;
iii. in particolare i filtri di Bloom sono usati per i confronti con operatore
di uguaglianza, sia su tipi numerici che stringa. Le liste di valori invece
sono usate per disuguaglianza su tipi esclusivamente numerici. I casi
intermedi sono trattati utilizzando una combinazione delle precedenti.
Nel caso una delle strutture dati sia marcata come wildcard il confronto
da sempre esito positivo.
L’operatore Return si limita a restituire tutte le tuple che riceve. L’algoritmo
termina restituendo l’insieme degli identificatori dei nodi Path, estratto
dalle tuple ottenute con l’esecuzione simulata. Quindi, se qualche nodo viene
restituito c’è corrispondenza fra l’interrogazione e lo schema nel qual caso
il peer a cui è associato lo schema viene considerato interessante. Nel caso
l’albero sia composto da più operatori Path foglia composti tramite operatori
Union, quest’ultimo si limita a restituire al padre tutte le tuple che riceve
dagli operatori figli.

Capitolo 5
Esecuzione
5.1 Protocollo di Esecuzione
La fase immediatamente successiva a quella di compilazione è l’esecuzione.
In questa fase l’albero logico prodotto dalla compilazione è stato completato
aggiungendo le informazioni su come localizzare i peer (location) ainodi
Path. All’albero così ottenuto vengono applicate una serie di riscritture per
permetterne successivamente l’ottimizzazione eladecomposizione.
L’ ottimizzazione avviene applicando all’albero logico una serie di riscritture
volte a minimizzare il costo dell’interrogazione e permetterne la successiva
decomposizione.
La decomposizione consiste nell’individuare porzioni dell’albero logico (a
cui è dato il nome di pipe) la cui esecuzione può esseredelegataadunpeer
remoto. Il risultato della decomposizione è un albero di pipe, ognuna delle
quali associata al peer su cui deve essere eseguita. La fase finale consiste nel
tradurre ulteriormente l’albero di pipe in un piano di accesso in cui le pipe
destinate a peer remoti vengono sostituite da opportuni operatori il cui compito
è inviare la pipe al peer di appartenenza e ricevere in seguito i risultati.
47

CAPITOLO 5. ESECUZIONE 48
5.1.1 Riscrittura dell’ Albero Logico
Le riscritture attualmente implementate in XPeer sono la distribuzione delle
unioni el’anticipazione delle selezioni.
La distribuzione delle unioni traduce le unioni di locazioni sotto un
operatore Path in unioni di Path ognuno con una singola funzione location.
La proprietà utilizzata è la seguente:
∀l1,l2 ∈ loc : pathf((l1 • l2)(x)) = pathf(l1(x)) ∪ pathf(l2(x))
Figura 5.1: Distribuzione delle Unioni
L’anticipazione delle selezioni consiste nel portare le selezioni in fondo
all’albero facendo in modo che queste vengano eseguite dai peer remoti,
riducendo così laquantitàdidati inviati e di conseguenza alleggerendo le
computazioni che il peer locale deve eseguire. La proprietè usataèl’antici-

CAPITOLO 5. ESECUZIONE 49
pazione delle selezioni rispetto alle unioni:
∀e1,e2 : σP (e1 ∪ e2) =σP (e1) ∪ σP (e2)
Figura 5.2: Anticipazione delle Selezioni
5.1.2 Decomposizione dell’ Albero Logico
La decomposizione crea un albero binario di pipe. Ognuna di queste contiene
un frammento di albero logico e l’identificatore del peer su cui deve essere
eseguita. La radice dell’albero di pipe contiene al suo interno sempre un
operatore di tipo Return che viene eseguito sul peer da cui è partita la
richiesta di esecuzione(peer corrente). Tipicamente la pipe inviata ad un
peer remoto è costituita da un operatore di selezione, Sigma, seguito da un
operatore Path, la cui funzione location identifica proprio il peer remoto.
L’albero di pipe così formato viene poi trasformato nel piano di accesso
distribuito. In particolare a partire dalla radice viene visitato l’intero albero,

CAPITOLO 5. ESECUZIONE 50
Figura 5.3: La figura mostra un albero di pipe, evidenziando i frammenti di
albero logico.
ogni frammento di piano logico contenuto in una pipe assegnato al peer corrente
viene tradotto in un pezzo del piano d’accesso parziale. I vari frammenti
così creati vengono poi collegati tra loro rispettando la struttura dell’albero
di pipe.
Quando viene processata una pipe non assegnata al peer corrente viene
generato un operatore fisico (XMLExternalQueryOp) che si occupa all’inizio
dell’esecuzione di inviare il frammento contenuto nella pipe al peer
remoto e in seguito di richiedere e riceve i risultati dal suddetto peer. Il peer
remoto che riceve il frammento deve a sua volta tradurre il frammento in
un piano d’accesso la cui radice è un operatore di tipo XMLExternalResultOp,
che svolge le funzioni complementari a XMLExternalQueryOp,
ovvero riceve le richieste dei dati e si preoccupa di inviare i dati al peer che
ha richiesto l’esecuzione.

CAPITOLO 5. ESECUZIONE 51
Le comunicazioni fra questi due operatori sono vincolate da timeout per
evitare attese infinite da parte del peer corrente nell’eventualità incuisi
verifichino problemi di connessione o il peer remoto non sia più raggiungibile.
In questi casi l’esecuzione procede normalmente senza però ricevere le tuple
dai peer remoti interessati.

Capitolo 6
Risultati Sperimentali
6.1 Introduzione
Parte del nostro tirocinio è stata dedicata alla conduzione di esperimenti
mirati alla verifica della correttezza del protocollo di compilazione e alla
misurazione del grado di precisione raggiunto.
6.2 Ambiente di Sperimentazione
Gli esperimenti sono stati condotti su una rete composta da 5 nodi con
sistema operativo Linux con la seguente configurazione software:
- JDK versione 1.5.09;
- Ant 1.7.0
Prima di ogni esperimento sono stati sincronizzati (via NTP) tutti gli
orologi delle macchine sull’ora italiana per assicurarci che la rilevazione dei
tempi fosse quanto più accurata possibile.
52

CAPITOLO 6. RISULTATI SPERIMENTALI 53
6.3 Testing
Per simulare un ambiente di utilizzo quanto più reale possibile abbiamo ricreato
in laboratorio un tipico scenario medio-piccolo (imposto dalle risorse
a nostra disposizione) di utilizzo del sistema XPeer. Abbiamo quindi creato
manualmente (ovvero imponendo la struttura alla rete, senza lasciare che i
peers si connettessero liberamente) una rete a due livelli con 25 peers.
La costruzione della rete è stata guidata tramite uno strumento orchestratore
(xOrch) con cui è possibile creare e poi successivamente comandare
e monitorare, in modo distribuito, peer e superpeer.
Ad ogni peer è stato assegnato un frammento XML(si veda Appendice
A) estratto in modo casuale dal dataset University Courses XML. La scelta è
stata ancora una volta dettata dalla necessità di condurre gli esperimenti su
un ambiente quanto più reale possibile in cui tutti i nodi pubblicano qualche
informazione ma con un limitato grado di disomogeneità.
Contestualmente alla scelta del dataset di documenti XML sono state
create le interrogazioni da sottomettere al sistema (si veda Appendice B).
La creazione delle query è stata guidata in parte dalla necessità di verificare
la correttezza delle singole funzionalità come gli operatori di confronto stringhe/interi,
l’operatore unione; dall’altra di misurare la precisione del sistema.
L’intera lista di interrogazioni così formataèstata sottomessa da ogni
peer ( per confrontare i risultati della compilazione relativi a peer diversi) e
con varie modalità:
- una di seguito all’altra, un peer per volta;
- tutte contemporaneamente, un peer per volta;

CAPITOLO 6. RISULTATI SPERIMENTALI 54
- una di seguito all’altra da tutti i peer contemporaneamente;
- tutte contemporaneamente da tutti i peer contemporaneamente.
L’esperimento finora descritto è stato condotto più volte variando le dimensioni
dei filtridibloomedelle liste di valori per valutare il variare del
livello di precisione in relazione a quei due parametri.
6.4 Verifica dei Risultati
La correttezza dei risultati della compilazione è stata condotta in modo automatizzato
comparando i risultati ricavati dal sistema con quelli ottenuti
da un ben noto strumento per l’interrogazione e la validazione di documenti
XML: Galax.
Ogni interrogazione sottomessa al sistema è stata valutata con Galax su
ogni singolo documento XML presente nel sistema ed il risultato memorizzato.
La presenza di un risultato non vuoto indica che il documento XML
conteneva informazioni rilevanti per l’interrogazione.
Poichè siamo in grado di risalire dal documento XML al peer in suo possesso,
abbiamo ricavato, per ogni interrogazione, la lista esatta dei peer con
informazioni rilevanti. L’insieme di liste così ottenuta è stata utilizzata per
effettuare i confronti con le rispettive liste prodotte a partire dai risultati
delle compilazioni effettuate sul sistema.
I confronti ci hanno aiutato in un primo periodo nella correzione degli
errori e successivamente nella misurazione della precisione.

CAPITOLO 6. RISULTATI SPERIMENTALI 55
6.5 Risultati
Si è voluto valutare il riscontro delle query positive e l’errore assoluto di
compilazione per le query negative, dove l’errore di compilazione èricavato
valutando la differenza tra peer rilevati in fase di compilazione come possessori
di dati interessanti e quelli che effettivamente sono in possesso di dati
rilevanti.
Figura 6.1: La figura mostra la precisione delle query con e senza l’uso dei
filtri di Bloom (con diverse configurazioni).
Il risultato dei test ha mostrato come il sistema raggiunga un alto grado
di precisione ed inoltre dall’analisi dell’errore assoluto di compilazione non
sono stati riscontrati falsi positivi.

CAPITOLO 6. RISULTATI SPERIMENTALI 56
6.6 Strumenti
Per automatizzare il più possibile l’esecuzione degli esperimenti abbiamo sviluppato
un insieme di programmi che ci hanno aiutato, assieme all’orchestratore,
nella fase di setup delle varie macchine e poi nella verifica dei risultati.
Il primo strumento, realizzato in Python, ci ha aiutato a configurare tutte
le macchina a nostra disposizione nello stesso modo, evitanto di ripetere
manualmente la stessa procedura ogni volta che era necessario rieseguire l’esperimento.
Il programma è concettualmente semplicemente in quanto esegue, in parallelo
su tutte le macchine a nostra disposizione, una lista di comandi che
gli viene passata come parametro.
In dettaglio viene stabilita una connessione tramite il protocollo SSH e
su questo canale vengono inviati i comandi e restituiti i risultati.
La verifica dei risultati, come precedentemente descritta, è stata condotta
con l’aiuto di un insieme di script Python:
- generate-galax.py: genera per ogni interrogazione l’elenco esatto di peer
con informazioni interessanti e memorizza su file il risultato dell’interrogazione
stessa;
- generate-xpeer.py: analizza i dati prodotti dal sistema e genera per ogni
coppia peer-interrogazione la lista dei peer riportata dal protocollo di
compilazione;
- verify.py: confronta le liste dei singoli peer con quella esatta prodotta
da Galax e segnala eventuali differenze.

Capitolo 7
Conclusioni
In questa relazione sono stati presentati i principali aspetti progettuali e implementativi
che hanno riguardato il lavoro da noi svolto durante il tirocinio.
Tirocinio svolto nell’ambito del progetto di ricerca XPeer del gruppo di Basi
di Dati del Dipartimento di Informatica dell’Università diPisa.
Durante il tirocinio ci siamo occupati principalmente del completamento e
della verifica della fase di compilazione e di esecuzione delle query all’interno
del sistema.
Esperienze Acquisite
L’aspetto di maggiore complessità del lavoro svolto è stato il fatto di dover
intervenire su sistemi software preesistenti. L’esperienza formativa acquisita
è relativa alla progettazione e realizzazione di un sistema distribuito.
57

Appendice A
Frammenti XML
24224
E E
311
01
ELECTRONICS
3
M,W,F
9:10
SLOA
9
RINGO
0064
0033
58

Appendice B
Insieme Query
1. for $c in $db//course, $l in $c/level where $l = "U" return $c/title
2. for $c in $db//course, $en in $c/enrolled where $en >= 5 return $c/title
3. for $c in $db//course, $cr in union($c/credits, $c/credit) where
$cr > 6 return $c
4. for $r in $db/root, $inst in $r/institution, $c in $r//course,
$cr in $c/credits where $c/credits > 4 and $inst = "wsu" return $c
5. for $c in $db//course, $p in union($c/prefix, $c/subj) where $p =
"CHEM" return $c
6. for $c in $db//course where $c/instructor = "Parker" return $c
7. for $c in $db//course, $l in $c/lab, $li in $c/limit where $li
= 25 return $c
9. for $r in $db/root, $inst in $r/institution, $c in $r/course
where $inst = "Stanford" return $c
10. for $c in $db//course, $l in $c/level, $en in $c/enrolled where
$l = "U" and $en >= 25 return $c
59

Appendice C
Algebra di Interrogazione
In questa appendice è presentata la formalizzazione completa dell’algebra di interrogazione
di XPeer.
C.1 Modello dei Dati
C.2 Funzioni
1. label(n) =label;
2. oid(n) =oid;
3. loc(n) =loc;
t ::= t1,...,tm | n[t] | n alberi
n ::= (oid, loc)label nodi
dove label ∈ String.
4. contentp(db) = t1,...,tn tali che ti sono le istanze del modello dei dati
pubblicate dal peer p sotto il database db.
C.3 Env
Quattro operazioni di base sono definite sulle strutture Env e sulle tuple:
1. t.A = tj dove A = labelj (dove t è una tupla) (estrazione di campo);
2. t. →
A= {ti1,...,tip} dove →
A= {labeli1 ,...,labelip) (ripetuta estrazione di
campo);
60

APPENDICE C. ALGEBRA DI INTERROGAZIONE 61
3. t ↓ →
A= [labeli1 : ti1,...,labelip : tip] dove →
A= {labeli1 ,...,labelip);
4. ◦, un operatore di concatenazione tra tuple.
C.4 Operatori di Supporto
1. e[x] ={[x : t] | t ∈ e}
{}
2. child(t) =
{t1,...,tn}
se t = n
se t = n[t1,...,tn]
3. descendant(t) = child(t) ∪
ti∈child(t) descendant(ti)
4. self(t) ={t1,...,tn | t = t1,...,tn}
5. selfdescendant(t) =self(t) ∪ descendant(t)
6.
⎧
nav(op)(label)(t1,...,tn) =
⎨ {ti | label(ti) =label} se op =
{t
⎩
′ j ∈ n i=1 child(ti) | label(t ′ j )=label} se op = /
)=label} se op = /
{t ′ j ∈ n
i=1 selfdescendant(ti) | label(t ′ j
C.5 Operatori di Base
Map χe f = {f(t) | t ∈ e}
Join e1 ⊲⊳ f
pred e2 = {f(t1,t2) | t1 ∈ e1 & t2 ∈ e2 & pred(t1,t2)}
TupJoin e1 TupJoin prede2 = {t1 ◦ t2 | t1 ∈ e1 & t2 ∈ e2 & pred(t1,t2)}
DJoin e1 = {y ◦ x | y ∈ e1 & x ∈ e2(y)}
Selection σpred(e) ={t ∈ e | pred(t)}
Projection π→(e)
={t ↓→A
| t ∈ e}
A
C.6 Operatori sulle Locazioni
LocUnion (loc1 • loc2)(x) =loc1(x),loc2(x) doveloc1 e loc2 sono funzioni location.

APPENDICE C. ALGEBRA DI INTERROGAZIONE 62
C.7 Path
C.7.1 Grammatica degli Input Filter
C.7.2 Path
F ::= F1,...,Fn di giunzione
| F1 ∨ ...∨ Fn di disgiunzione
| (op,var,binder)label[F ] semplice
| ∅ vuoto
dove op ∈{/, //, }
var, label ∈ String ∪{ }
binder ∈{ , in, =}
1. Se f = f1,...,fm allora
path f(t) =path f1 (t) TupJoin true...TupJoin true path fm (t);
2. se f = f1 ∨ ...∨ fm allora
path f(t) =path f1 (t)OuterUnion...OuterUnion path fm (t);
3. se f =( , , binder)label[∅] allora
path f(t) ={};
4. se f =( , , binder)label[F ] allora
path f(t) =path F (nav( )(label)(t));
5. se f =(op, v, in)label[∅] allora
path f(t) =nav(op)(label)(t)[v];
6. se f =(op, v, =)label[∅] allora
path f(t) ={[v :nav(op)(label)(t)]};
7. se f =(op, v, in)label[F ]et = t1,...,tn allora
pathf(t) =
ti∈nav(op)(label)(t) {[v : ti]} TupJoin true pathF (ti);
8. se f =(op, v, =)label[F ]et = t1,...,tn allora
pathf(t) ={[v :nav(op)(label)(t)]} TupJoin true pathF (nav(op)(label)(t));
9. se f =(op, , )label[∅] et = t1,...,tn allora
path f(t) ={};
10. se f =(op, , )label[F ]et = t1,...,tn allora
path f(t) =path F (nav(op)(label)(t));
11. se f = ∅ e t = t1,...,tn allora
path f(t) ={}.

APPENDICE C. ALGEBRA DI INTERROGAZIONE 63
C.8 Return
C.8.1 Grammatica degli Output Filter
C.8.2 Return
dove
1. Se of = vB allora
returnof (e) = n
i=1 vB
dove e = {t1,...,tn};
OF ::= OF1,...,OFn
| label[OF] elementi
| @label[val] attributi
| val
val ::= vB | var | νvar valore o variabile
2. se of = var allora
returnof (e) ={t.var | t ∈ e};
3. se of = νvar allora
returnof (e) ={refreshoid(t.var) | t ∈ e};
4. se of =@label[val] allora
returnof (e) = n
i=1 @label[returnval({ti})]
dove e = {t1,...,tn};
5. se of = label[of ′ ] allora
returnof (e) = n i=1 label[returnof ′({ti})]
dove e = {t1,...,tn};
6. se of = of1,...,ofn allora
returnof (e) = n returnof1 ({ti}),...,returnofn i=1 ({ti})
dove e = {t1,...,tn};
1. refreshoid(t1,...,tn) =refreshoid(t1),...,refreshoid(tn);
2. refreshoid((oid, loc)label[t]) = (nu(oid),loc)label[refreshoid(t)];
3. refreshoid((oid, loc)@label[vB]) = (nu(oid),loc)label[vB];
4. refreshoid((oid, loc)label) =(nu(oid),loc)label.

Bibliografia
[SMGC04] Carlo Sartiani and Paolo Manghi and Giorgio Ghelli and Giovanni
Conforti. XPeer: A Self-organizing XML P2P Database
System, 2004.
[SMGC07] Carlo Sartiani and Paolo Manghi and Giorgio Ghelli and
Giovanni Conforti, 2007. Scalable Query Dissemination in
XPeer.
[Sar03] Carlo Sartiani. Efficient Management of Semistructured XML
Data, 2003.
[Gio05] Nicola Gioia. Un sistema Peer-to-Peer per l’interrogazione
distribuita di dati XML, 2005. Tesi di laurea.
[Bat05] Giovanni Battaglia. XPeer: robustezza rispetto ai fallimenti,
2005. Relazione di tirocinio.
[PT06] Pardini Giovanni, Paolo Tomei . XPeer: Modulo per la gestione
delle interrogazioni del sistema XPeer, 2006. Relazione di
tirocinio.
[Def07] Federico De Faveri. XPeer: ACL di XPeer, 2007. Relazione di
tirocinio.
[Par07] Pardini Luca. XPeer: un orchestratore per XPeer, 2007.
Relazione di tirocinio.
[BDB] Berkeley DB, Sleepycat Software. http://www.sleepycat.com.
[XML] World Wide Web Consortium. Extensible Markup
Language (XML) 1.0 (Third Edition).
http://www.w3.org/TR/2004/REC-xml-20040204.
[XPath] World Wide Web Consortium. XML Path Language (XPath)
Version 2.0. http://www.w3.org/TR/2005/CR-xpath20-
20051103.
64

BIBLIOGRAFIA 65
[Xml-Schema] World Wide Web Consortium. XML Schema Datatypes Version
1.1. http://www.w3.org/TR/2006/WD-xmlschema11-2-
20060217/.
[Xml-Schema] World Wide Web Consortium. XML Schema Structure Version
1.1. http://www.w3.org/TR/2006/WD-xmlschema11-1-
20060831/.
[XQuery] World Wide Web Consortium. XQuery 1.0: An XML Query
Language. http://www.w3.org/TR/2005/CR-xquery-20051103.
[Xdm] World Wide Web Consortium. XQuery 1.0 and XPath 2.0
Data Model (XDM). http://www.w3.org/TR/2005/CR-xpathdatamodel-20051103.
[mqp] Vassilis Papadimos and David Maier and Kristin Tufte. Distributed
Query Processing and Catalogs for Peer-to-Peer
Systems.
[Galax] Galax Team. http://www.galaxquery.org/.
[Python] Guido van Rossum. http://www.python.org/.
[Dataset] http://www.cs.washington.edu/research/xmldatasets/.