capo articolo
4.2.7 Una architettura esistente
Il modello descritto `e stato implementato all’interno di [2] in un prototipo di sistema per la gestione di una collezione di atti normativi soggetti a variazioni
4.2 Modello di atto normativo 61 nel corso del tempo. In tale sistema `e prevista l’interrogazione dei documen-ti memorizzadocumen-ti in formato XML tramite l’esplicitazione di requisidocumen-ti testuali e temporali.
Quel prototipo di sistema `e stato implementato utilizzando un approccio a strato (che chiameremo stratum, si veda anche [8]) e supporta:
1. la memorizzazione di testi normativi che variano nel tempo rappresentati come documenti XML conformi ad un particolare XML Schema
2. la modifica di testi normativi precedentemente memorizzati
3. l’interrogazione dei testi normativi memorizzati con la possibilit`a di ricerca tramite keyword e vincoli temporali
Fra le operazioni supportate si tratter`a approfonditamente l’interrogazione. Ogni query viene trasformata dallo stratum in una espressione equivalente in modo che possa essere passata ad un XML Engine. Quando l’Engine ha svolto le ope-razioni che gli sono state richieste nell’interrogazione, questo riporta i risultati ottenuti allo stratum, che compie ulteriori elaborazioni prima di riportarli all’u-tente. Possiamo dire che i risultati che l’XML Engine riporta allo stratum dopo l’esecuzione di una query sono solo risultati parziali; infatti lo stratum esegue la ricostruzione di tali documenti attraverso l’utilizzo dell’operatore const-tree() prima di riportarli all’utente come risultati finali.
Questo approccio si basa completamente sui metodi messi a disposizione dal-l’Engine, compresa l’ottimizzazione della query. Nell’implementazione trattata in [2] `e stato utilizzato Oracle 9i sia come Engine che come Repository.
Gli Engine esistenti non conoscono la semantica temporale espressa nella que-ry di esempio (ricordiamo che TSQL2 non `e uno standard), quindi allo stratum `e lasciata la gestione degli aspetti temporali del modello adottato, in modo da provvedere ad un completo supporto per la gestione di atti normativi che muta-no nel tempo. L’architettura utilizzata in [2] `e rappresentata in figura 4.10; lo stratum consiste nei componenti Preprocessing, Query Processor e Update Pro-cessor. I documenti XML sono memorizzati all’interno dell’XML Repository in una tabella che ha lo schema riportato in figura 4.11. Ogni tupla appartenente
62 4. Introduzione ai testi normativi ed al modello adottato
Figura 4.10: Architettura adottata nell’approccio a stratum tnorms ( ID, XML-DOC, TYPE, PUBLICATION, VT-START,
VT-END, ET-START, ET-END, TT-START, TT-END)
Figura 4.11: Relazione adottata in nell’approccio a stratum
a tale relazione rappresenta un documento XML temporale, il cui testo `e intera-mente memorizzato all’interno del campo XML-DOC in forma non strutturata (cio`e testo semplice). La tabella contiene anche attributi addizionali che rappresen-tano la temporalit`a, essi sono: PUBLICATION, VT-START, VT-END, ET-START, ET-END, TT-START e TT-ENDe sono rappresentativi dell’intera temporalit`a del-l’atto normativo. Infatti nel modello trattato in [2] i tempi relativi ad ogni livello della gerarchia sono interamente contenuti all’interno dei tempi degli elementi ancestor. E’ quindi possibile dire che gli attributi nella relazione contengono quelli di ogni altro elemento, perch`e soddisfano l’operatore CONTAINS di TSQL2. Inoltre, per rendere pi`u efficiente le query testuali, `e stato creato un inverted index sul testo contenuto all’interno degli elementi titolo e comma.
Quando una query di tipo XQuery come quella in figura 4.9 viene sottoposta al sistema, il Query Processor all’interno dello stratum la traduce nella corri-spettiva query SQL (figura 4.12) da passare all’Engine adottata. All’interno di quella query i vincoli temporali dell’interrogazione originale sono stati tra-dotti nei corrispettivi vincoli SQL sulle colonne della relazione adottata (figura 4.11), mentre il vincolo strutturale viene passato all’XML Engine attraverso
4.2 Modello di atto normativo 63 SELECT L.XML-DOC.extract(’articolo//comma’).getStringVal() FROM tnorms L WHERE (VT-START <= ’2000-12-31’) AND (VT-END >= ’1970-01-01’) AND (TT-START <= ’1980-01-01’) AND (TT-END >= ’1980-01-01’)
AND CONTAINS (L.XML-DOC, inquinamento WITHIN comma) > 0 Figura 4.12: Esempio di query con XQuery
l’utilizzo della funzione extract() richiamato sull’apposito campo XML-DOC. A questo punto l’interrogazione viene eseguita e, quando lo stratum riceve i ri-sultati, si effettua l’operazione detta temporal slicing (attraverso la ricostruzio-ne con const-tree()) in modo da poter restituire all’utente documenti XML consistenti alle specifiche temporali.
L’approccio adottato in [2] presenta tuttavia dei punti deboli. Dai test con-dotti utilizzando il prototipo sviluppato si `e visto che al crescere del numero dei documenti interessati dalla query aumenta il tempo necessario per la risoluzione dell’interrogazione in modo sub-lineare per la selezione delle tuple e lineare per la ricostruzione dei documenti. Tale tempistica risulta comunque inaccettabile per query su grandi collezioni di documenti XML. Inoltre, il metodo di risolu-zione adottato in [2] `e interamente basato sull’utilizzo della main memory: una volta che la query (come quella descritta precedentemente) `e stata tradotta nel corrispondente SQL dallo stratum, tutte le tuple che fanno match (ognuna delle quali contiene un intero documento XML) vengono riportate allo stratum stesso che applica su ognuna l’operatore di ricostruzione const-tree(). Allo spazio in memoria utilizzato per contenere temporaneamente le tuple restituite dal DB si somma un ulteriore spazio per una successiva elaborazione; infatti l’opera-tore const-tree() effettua la ricostruzione di una tupla per volta (quindi di un documento XML per volta) e per ognuna necessita del corrispettivo albero DOM, la cui creazione pu`o richiedere fino a quattro volte dello spazio di memoria occupato dal documento testuale.
All’utilizzo della memoria centrale appena descritto, consegue che per rispon-dere a molte richieste in contemporanea, quel sistema ricorrer`a inevitabilmente
64 4. Introduzione ai testi normativi ed al modello adottato all’utilizzo della memoria virtuale (su disco fisso) con un drammatico calo delle prestazioni.