F O
C
U
S
XML
XML
Archiviare
Con l’esplosione del formato XML si è aperta
una nuova frontiera nel mondo dei Database.
Prontamente, tutti i maggiori produttori
di Basi di Dati hanno raccolto la sfida...
i dati XML
nel Database
[email protected] di Massimo Ruocchio
È laureato in matematica ed è certificato Oracle
come Application Developer. Si occupa di analisi,
progettazione e sviluppo di applicazioni software in
ambiente relazionale Oracle ed XML Tamino.
L’
36
CP 109
XML si diffonde a macchia d’olio. Il
W3C (http://www.w3.org), ente predisposto alla definizione degli standard in
ambito Internet, chiarisce sempre meglio
come utilizzare XML, uniformando l’utilizzo dei
Namespace e del DOM, il linguaggio di query, ecc.
Molti cercano di entrare nel business del mondo
XML. Tra questi, ovviamente, i produttori di database. Tutti tentano di fornire la migliore soluzione
per l’archiviazione dei dati in formato XML. La
situazione è ancora molto incerta e nessuno è riuscito a conquistare questo nuovo mercato.
Al momento si distinguono tre diverse strategie
d’approccio al problema “Archiviazione XML”.
Prima di tutto c’è chi ha pensato di convertire il
suo esistente database in un nuovo prodotto, lanciandosi a capofitto nel mercato XML per dimenticare le difficoltà del passato.
Poi c’è chi ha esteso le funzionalità del prodotto
esistente, cercando di utilizzare l’importanza del proprio nome per sbancare anche il nuovo mercato.
Infine c’è chi ha scommesso tutto sulla nuova
tecnologia, investendo uomini e mezzi per la crea-
zione di un nuovo prodotto che gestisca in modo
nativo i dati XML.
Nei prossimi paragrafi analizzeremo un prodotto,
ed un produttore, per ognuna delle tre categorie
elencate. Cominceremo con Excelon ed il suo Extensible Information Server, continueremo con Oracle e
le sue XML extension nelle versioni 8i e 9i, concluderemo con Software AG ed il suo Tamino.
Excelon: dall’Object Oriented all’XML
Nel 1999 Object Design, un’azienda americana
con base non lontano da Boston, nel Massachusetts, ha cambiato il proprio nome in Excelon
(http://www.exceloncorp.com), trasformando il proprio OODBMS, chiamato ObjectStore, in un database per l’archiviazione di documenti XML. Al neonato prodotto è stato attribuito il nome di Extensible Information Server (XIS).
Intorno al database, Excelon ha costruito una piattaforma completa, denominata XML Platform, per la
gestione di progetti in XML. In Figura 1 è rappresentata schematicamente la struttura di XML Platform.
La trasformazione di una struttura ad oggetti
per gestire l’XML è abbastanza naturale. Un
OODBMS è basato su un modello gerarchico
che consente di gestire semplicemente l’ereditarietà degli oggetti. Ovviamente questo approccio
si adatta perfettamente alla struttura, anch’essa
gerarchica, di un documento XML. In particolare
XIS archivia i documenti XML usando una struttura simile all’albero di decomposizione DOM.
monopolizzato il mercato
dei database XML
Business Process Manager
B2B Communication
Partner Interaction
Business Process Automation
J2EE Integration
XML API and Transformation
XML Repository
Administration Tools
Nessuno ha ancora
FIGURA 1 L’architettura di Excelon XML Platform
XML Development Tools
Questa tecnica di archiviazione consente sia di
caricare in memoria solo gli oggetti necessari per
eseguire le operazioni richieste, sia di migliorare
l’indicizzazione del documento. Gli oggetti richiamati vengono messi in cache per migliorare l’accesso concorrente e le performance complessive
dell’applicazione, seguendo una tecnica denominata distributed caching mechanism.
Il nucleo fondamentale di XIS è il Dynamic
XML Engine (DXE). DXE ha il compito di fornire
le principali caratteristiche del database, tra cui
il parsing dell’XML (che consente la gestione dei
documenti in formato DOM), l’indicizzazione, la
realizzazione delle query e degli update. XIS consente di indicizzare singoli elementi, o gruppi di
elementi, con tre tipologie di indici: value indexes
per la ricerca in dati numerici e stringhe, text
indexes per ricerche lessicali, structural indexes per
ricerche basate su strutture.
Per quanto riguarda le query, è possibile effettuare ricerche su uno o più documenti e salvare
le query effettuate nel DB. Il linguaggio di query
segue lo standard XPath 1.0.
È possibile effettuare operazioni di update dei singoli nodi e salvare nel database dei trigger, scritti
in Java, che scattano in seguito alle operazioni di
update.
Synchronization Framework
Message Adapters
DATA/APP Adapters
Extensible Information Server
Dal punto di vista tecnico, nasce spontanea una
perplessità a proposito dell’archiviazione dei documenti in formato simile al DOM. Non è chiaro se
questo approccio sia stato scelto perché considerato il migliore possibile oppure perché consente
di sfruttare il motore ad oggetti presente nel vecchio ObjectStore. Questo tipo di archiviazione fa
sì che siano comunque necessarie un’operazione di
parsing ed un’operazione di composizione dell’XML
anche quando il documento viene utilizzato esclusivamente nella sua interezza. Per documenti di
grosse dimensioni, questo approccio può causare
problemi di performance sia in fase di caricamento
sia in fase di lettura dei dati. Si tratta dello
stesso problema, sebbene dimezzato nell’entità, che
affligge i database relazionali con estensioni XML,
ma questo lo vedremo nel prossimo paragrafo.
Oracle: un nome, una garanzia
Mediante la componente XConnects è possibile
collegarsi ad altre sorgenti di dati di svariate tipologie. In particolare è possibile collegarsi a database
relazionali mediante ODBC ed OLE DB.
Altri punti di forza di XIS sono l’interfaccia grafica (XML Explorer) con cui possono essere gestiti
i documenti XML in maniera estremamente intuitiva ed il tool, denominato Manager, che fornisce
tutte le funzionalità classiche di amministrazione
della base dati.
Per agevolare la distribuzione del prodotto in
tutto il mondo, Excelon ha stipulato un accordo
commerciale con EDS.
Nonostante tutte le buone funzionalità fornite
dal prodotto, il mercato non pare riporre grande
fiducia nelle possibilità di successo di XIS. Le principali perplessità sono dovute alla struttura non particolarmente grande dell’azienda, che potrebbe non
essere in grado di reggere la concorrenza dei grandi
nomi del settore. Alcuni credono che il futuro di
Excelon sia l’acquisizione da parte di un’azienda più
grande che abbia l’infrastruttura adatta alla battaglia per la conquista del mercato.
Anche i grandi produttori di database si sono tuffati nel mondo XML per assicurarsi una posizione
di rilievo nel nuovo mercato. I più diffusi DB relazionali - quali Oracle8i, DB2, SQLServer7 – sono
stati dotati di estensioni per la gestione dell’XML.
Tra i database nominati, Oracle8i ha avuto il vantaggio di partire da una base non completamente
relazionale, ma che già implementava principi di
object orientation. Ciò è risultato molto utile per la
gestione dell’XML.
L’archiviazione di un documento XML in Oracle8i
può avvenire in tre modi. Per scegliere la giusta
tecnica di archiviazione bisogna determinare se
il documento è Data-Centric, Document-Centric
oppure un misto dei due.
Un documento XML è considerato Data-Centric
quando sono molto importanti, e molto variabili, i
singoli dati presenti nel documento. In questo caso,
Oracle propone l’archiviazione dei singoli dati in
tabelle relazionali e la costruzione di object view che
consentono di strutturare in maniera gerarchica i
dati archiviati. Alternativamente è possibile inserire i dati direttamente in object table. Per comple-
37
CP 109
F O
C
U
S
XML
FIGURA 2 Le componenti fondamentali di Tamino Server
38
CP 109
tezza ricordo che una object table è un nuovo tipo
di tabella introdotto a partire dalla versione 8 di
Oracle per la gestione di oggetti nel database. Una
object view sta ad una object table esattamente come
una view relazionale sta ad una tabella relazionale.
Per archiviare un documento Data-Centric in un
database relazionale bisogna, insomma, effettuare
una doppia trasformazione. Dapprima bisogna effettuare il mapping da struttura XML a struttura oggetto,
sostanzialmente lo stesso visto nel paragrafo precedente. Poi bisogna creare la corrispondenza tra struttura oggetto e tabelle relazionali.
Un documento XML è considerato DocumentCentric quando ciò che conta è il documento nel
suo complesso, e non i singoli dati contenuti. In
questo caso si propone l’archiviazione del documento in un campo di tipo BLOB o CLOB, la differenza dei due è che il CLOB contiene dati in formato ASCII mentre il BLOB contiene dati in formato binario.
Se il documento XML da archiviare è un misto
delle due tipologie viste, si può procedere all’archiviazione singola dei dati elementari importanti,
all’archiviazione complessiva del restante XML ed
alla creazione di object view per avere una visione di
insieme dei dati.
Veniamo ora alle funzionalità offerte ed ai limiti
dei tipi di archiviazione proposti.
In caso di archiviazione dei singoli campi in
object table, oppure in tabelle relazionali consultate
mediante object view, è possibile effettuare la ricerca
delle informazioni mediante il linguaggio di query
SQL99, nato in Oracle8 come estensione dell’SQL
per l’interrogazione degli oggetti. SQL99 ovviamente non risponde allo standard XPath descritto
dal W3C per la navigazione di documenti XML. In
più c’è il problema del grosso numero di join che
sono necessarie per effettuare una query sui dati
“scomposti”. I dati possono essere anche inseriti e
modificati mediante le object view solo in particolari
condizioni, come l’assenza di join e di campi calcolati nella select che definisce la view. Per ovviare
a questo grosso limite è stato introdotto un nuovo
tipo di database trigger, INSTEAD OF, il cui codice
PL/SQL scatta al posto del comando DML che era
stato originariamente inviato al DBMS. Per i documenti Data-Centric c’è un altro grosso problema.
Le eventuali modifiche di struttura del documento
XML, variazioni del DTD, possono causare un vero
e proprio terremoto nella struttura dati soggiacente.
Oracle consiglia di creare una nuova struttura dati
per ogni modifica della DTD oppure di implementare trasformazioni del documento XML, magari
mediante XSL, per creare nuovamente la corrispondenza tra il documento e la struttura dati.
Per quanto riguarda le prestazioni, non ci sono
problemi per documenti XML di semplice struttura, mentre c’è qualche problema con documenti
complessi a causa delle multiple join e delle limitazioni nella costruzione degli indici.
Nel caso di archiviazione dei documenti XML
in campi CLOB o BLOB, le funzioni di ricerca ed
indicizzazione sono garantite da Oracle Intermedia. Gli indici possono essere solo di tipo testuale.
Questo tipo di archiviazione è stato migliorato in
Oracle9i, mediante l’introduzione di un apposito
datatype, denominato XMLType, che inserisce il
documento XML in un campo di tipo CLOB. Con
XMLType non sono state introdotte nuove tecniche di indicizzazione ma sono comparse nuove funzioni (ExistsNode, Extract) che avvicinano il linguaggio di query allo standard XPath.
Tamino fornisce una
interfaccia grafica per la
manipolazione dei dati
Oltre alle funzionalità per l’archiviazione dei documenti XML, Oracle fornisce XDK (XML Developer’s Kit) per Java, JavaBeans, C, C++ e PL/SQL
che include parser, processori, generatori di classi e
schema processor. Mediante XDK versione 9i, Oracle
si è allineata alle versioni 2.0 degli standard di manipolazione per documenti XML DOM e SAX.
Da questa panoramica risulta evidente che l’adattamento di un DB relazionale (sebbene fornito di
estensioni OO) per la gestione dell’XML incontra
varie difficoltà. Queste sono generate tutte dal problema di fondo che l’XML è gerarchico. Non tutte
le strutture si possono adattare perfettamente ad un
relazionale e, comunque, alla fine bisogna denormalizzare la struttura dati per migliorare le performance. Ma c’è un aspetto fondamentale che avvantaggia i “grandi nomi” rispetto ai meno famosi concorrenti che abbiamo visto nel paragrafo prece-
dente e vedremo nel successivo. Il mercato riconosce, comunque, un credito a chi possiede una
struttura, tecnica e commerciale, molto più grande,
stabile e soprattutto molto conosciuta. Inoltre pochi
si fidano delle integrazioni tra piattaforme diverse.
Perché dovrei archiviare i documenti XML in un
database XML nativo e continuare a conservare
tutti gli altri dati nel mio fidato RDBMS quando
posso mettere tutto in Oracle9i? A questa domanda
cercano di rispondere i produttori di database XML
nativi, tra i quali s’è messa particolarmente in luce
la tedesca Software AG che conosceremo nel prossimo paragrafo.
Software AG: “the XML company”
Software AG (http://www.softwareag.com) è una
azienda tedesca, con sede a Darmstadt e filiali in
più di 70 paesi nel mondo, specializzata nella produzione di software di sistema. Fino a due anni fa i
prodotti di punta di Software AG erano Adabas, un
database gerarchico, e Natural, il corrispondente
ambiente di sviluppo. Nel 1999 Software AG ha
raccolto la sfida dell’XML scegliendo di dedicarsi
quasi completamente a questa nuova tecnologia.
Oggi il prodotto di punta di Software AG è Tamino
che, fonte IDC, ha già conquistato il 40,5% del
mercato dei database XML. Ma Tamino non è solo
un database, è una piattaforma completa per lo
sviluppo di applicazioni XML, completo di editor,
parser e processor XML nonché di un ambiente di
sviluppo Java denominato Bolero.
In Figura 2 sono raffigurate le componenti
fondamentali di Tamino Server. La componente
principale è X-Machine, il motore del Database.
X-Machine ha il compito fondamentale di archiviare ed estrarre l’XML. Bisogna subito notare che
Tamino consente l’archiviazione dei dati, oltre che
nel proprio XML Data Store, anche in un Database
relazionale interno e in database esterni accessibili
mediante ODBC e OLE DB. Per l’accesso a datasource esterne si utilizza la componente X-Node,
componente nato per l’integrazione con altri mondi.
L’utilizzo di X-Node è assolutamente trasparente
all’utente, un singolo documento XML estratto da
Tamino può essere composto da dati elementari
estratti da multipli database esterni.
Il Data Map, l’analogo del Data Dictionary negli
RDBMS, fornisce le struttura dei dati e degli indici
in Tamino. Lo stesso Data Map è strutturato in
formato XML e può essere interrogato dall’utente
mediante semplici query eseguite con X-Query, il
linguaggio di interrogazione del database. Tamino
include anche un RDBMS, detto SQL Engine, ed un
tool grafico di amministrazione, chiamato Tamino
Manager.
Il primo passo da compiere per utilizzare Tamino
è la descrizione dei documenti XML che si intendono gestire. Alla versione attuale (2.3.1), Tamino
accetta la descrizione mediante DTD, ma è già previsto il pieno supporto di XML Schema quando
questo sarà perfettamente formalizzato dal W3C.
Documenti XML non descritti preventivamente
possono essere comunque archiviati in Tamino.
La descrizione dei documenti XML avviene fuori
di Tamino, mentre nel DB bisogna definire la struttura dei dati che viene conservata, come abbiamo
visto, nel Data Map. Per la definizione della struttura dati in Tamino è disponibile uno Schema Editor
grafico, oppure è possibile utilizzare un apposito
linguaggio detto Schema Language. I dati vengono
strutturati a tre livelli: Collection, Doctype e Nodi.
Una Collection include più Doctype ognuno dei quali
include più nodi. La collection è un insieme di tipi di
documenti, può essere associata ad un intero database classico. Un doctype è un tipo di documento
e può essere assimilato ad una tabella relazionale.
Il nodo è il dato elementare e può essere associato
ad una colonna dei DB relazionali. Ma un nodo può
FIGURA 3 Tamino Interactive Interface, per la manipolazione dei dati XML
39
CP 109
F O
C
U
S
XML
essere anche composto da altri nodi, consentendo
di creare documenti XML di qualsivoglia complessità. Tamino fornisce anche la possibilità di associare dei Datatype ai nodi elementari in fase di definizione dello schema.
Una volta definita la struttura dei dati, si può
cominciare ad utilizzare il DB caricando, modificando
e cancellando dati. Tamino fornisce una interfaccia
grafica per la manipolazione dei dati, il cui nome è
Tamino Interactive Interface, mostrata in Figura 3.
Mediante Interactive Interface è possibile caricare,
modificare e cancellare dati, eseguire query, definire
e cancellare schemi dati e collection. Le stesse funzionalità possono essere ottenute anche inviando, a
mezzo HTTP, dei comandi alla X-Machine.
Ogni documento XML caricato in Tamino è
automaticamente indicizzato. È possibile personalizzare l’indicizzazione per ottenere risultati migliori
in alcune particolari query. I parametri di indicizzazione sono conservati nel Data Map. Per ogni nodo,
può essere indicizzato il valore, per migliorare le
ricerche testuali su quel nodo, oppure l’intera struttura che da esso discende, per migliorare le ricerche
che navigano quella struttura.
Il linguaggio di interrogazione in Tamino si chiama
X-Query. X-Query è basato sulle regole di navigazione standard in XML definite dal W3C mediante
XPath. Un esempio di query è il seguente:
http://localhost/tamino/mydb/Magazzino/ordine
?_XQL=/ordine/cliente[Cognome=’Rossi’]/
indirizzo
40
CP 109
Nell’esempio ci siamo connessi al database mydb
presente in locale, abbiamo individuato la collection
Magazzino ed il DocType ordine. Abbiamo richiesto l’indirizzo del cliente il cui cognome è ‘Rossi’. Il
risultato delle query è sempre espresso in formato
XML. È possibile anche utilizzare X-Query per
ricercare documenti XML archiviati senza struttura, effettuando la query sulla collection di sistema
ino:etc, oppure per ottenere informazioni sulla struttura del database, effettuando una query sulla collection di sistema ino:collection.
In fase di query è possibile ordinare i risultati
mediante sortby, un comando non presente nello
standard XPath. Alla versione attuale Tamino non
supporta join in fase di query. È possibile definire
nella struttura dati dei Doctype che pescano i propri
dati da diversi Doctype appartenenti alla stessa collection. Le join vanno dunque progettate in anticipo. Software AG dichiara che nelle future versioni di X-Query sarà aggiunta la possibilità di effettuare join in fase di query.
Questa limitazione sulle join e l’impossibilità di
estrarre dati singoli non in formato XML sono, al
momento, i due principali difetti di Tamino.
Per incrementare la propria presenza sul mercato,
Software AG ha stipulato varie partnership. In par-
ticolare sono molto importanti gli accordi con HP,
IBM e Bea Systems per la distribuzione di Tamino
con gli application server Bluestone, Websphere e
Weblogic.
Molti ricorderanno la scommessa, finita male, dei
database ad oggetti a metà degli anni ’90. Imparando dagli errori commessi in quel periodo dai
produttori di OODBMS, Software AG ha stabilito
che lo scopo di Tamino non deve essere la sostituzione dei database esistenti, ma la loro integrazione, al fine di ottenere una gestione ottimale dei
documenti XML, rendendo trasparente all’utente
la distribuzione dei dati in diverse datasource.
Conclusioni
Anche se non abbiamo potuto approfondire
molto la descrizione dei tre prodotti presentati,
appare evidente che, dal punto di vista tecnico, i
prodotti di Excelon e Software AG sembrano dare
migliori funzionalità. Ma abbiamo visto che ci sono
validi motivi anche per scegliere Oracle oppure
un altro DBMS molto diffuso ed adattato per la
gestione dell’XML. Almeno per ora nessuno ha
monopolizzato il mercato dei database XML e
questo potrebbe essere un vantaggio per lo sviluppo
della tecnologia. Possiamo farci un’idea di come si
sta orientando il mercato guardando i risultati degli
award assegnati dai lettori dell’XML-Journal. L’importante rivista specializzata ha condotto un sondaggio tra esperti che si è concluso con l’affermazione di Tamino con il 41,2% dei voti. Al secondo
posto si è piazzato Oracle8i distanziato di circa
8 punti percentuali. Terzo e quarto sono giunti,
rispettivamente, IBM DB2 ed Excelon Extensible
Information Server. Per maggiori informazioni è
possibile consultare il sito http://www.sys-con.com/
xml/readerschoice/index_d.html.
BIBLIOGRAFIA
[1] E. X. Dejesus - “XML enters the DBMS Arena”,
Computerworld, 2000.
[2] M. Leon - “Find a home for your XML data”,
Infoworld, 2001.
[3] R. Bourret - “XML Database Products”,
www.rpbourret.com/xml/index.htm, 2001.
[4] R. Bourret - “XML And Databases”,
www.rpbourret.com/xml/index.htm, 2001.
[5] eXcelon - “Extensible Information Server”, White
Paper, 2001.
[6] S. Muench - “Using XML and Relational Databases for Internet Appl.”, Oracle corp., 2000.
[7] Oracle - “Using XML in Oracle Database Applications”, White Paper, 2001.
[8] L. Di Palma - “L’XML di Software Ag a caccia di
Java-partner”, Week.it, 2001.
[9] SoftwareAG - “Tamino 2.3.1”, Documentazione
tecnica, 2001.