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.