XML. Archiviare. nel Database di Massimo Ruocchio. i dati XML. L XML si diffonde a macchia d olio. Il

Transcript

1 Con l esplosione del formato si è aperta una nuova frontiera nel mondo dei Database. Prontamente, tutti i maggiori produttori di Basi di Dati hanno raccolto la sfida... Archiviare i dati nel Database mruocchio@programmers.net 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 Tamino. L si diffonde a macchia d olio. Il W3C ( ente predisposto alla definizione degli standard in ambito Internet, chiarisce sempre meglio come utilizzare, uniformando l utilizzo dei Namespace e del DOM, il linguaggio di query, ecc. Molti cercano di entrare nel business del mondo. Tra questi, ovviamente, i produttori di database. Tutti tentano di fornire la migliore soluzione per l archiviazione dei dati in formato. 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. Prima di tutto c è chi ha pensato di convertire il suo esistente database in un nuovo prodotto, lanciandosi a capofitto nel mercato 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 creazione di un nuovo prodotto che gestisca in modo nativo i dati. 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 extension nelle versioni 8i e 9i, concluderemo con Software AG ed il suo Tamino. 36 Excelon: dall Object Oriented all Nel 1999 Object Design, un azienda americana con base non lontano da Boston, nel Massachusetts, ha cambiato il proprio nome in Excelon ( trasformando il proprio OODBMS, chiamato ObjectStore, in un database per l archiviazione di documenti. Al neonato prodotto è stato attribuito il nome di Extensible Information Server (XIS). Intorno al database, Excelon ha costruito una piattaforma completa, denominata Platform, per la gestione di progetti in. In Figura 1 è rappresentata schematicamente la struttura di Platform. La trasformazione di una struttura ad oggetti per gestire l è 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. In particolare XIS archivia i documenti usando una struttura simile all albero di decomposizione DOM.

2 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 Engine (DXE). DXE ha il compito di fornire le principali caratteristiche del database, tra cui il parsing dell (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. Nessuno ha ancora monopolizzato il mercato dei database Development Tools FIGURA 1 L architettura di Excelon Platform B2B Communication Business Process Manager Partner Interaction Business Process Automation J2EE Integration API and Transformation Repository 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 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, ma questo lo vedremo nel prossimo paragrafo. Administration Tools 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 ( Explorer) con cui possono essere gestiti i documenti 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. Oracle: un nome, una garanzia Anche i grandi produttori di database si sono tuffati nel mondo 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. 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. L archiviazione di un documento 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 è 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

3 38 FIGURA 2 Le componenti fondamentali di Tamino Server 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 a struttura oggetto, sostanzialmente lo stesso visto nel paragrafo precedente. Poi bisogna creare la corrispondenza tra struttura oggetto e tabelle relazionali. Un documento è considerato Document- Centric 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 da archiviare è un misto delle due tipologie viste, si può procedere all archiviazione singola dei dati elementari importanti, all archiviazione complessiva del restante 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. 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, 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, 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 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 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 Type, che inserisce il documento in un campo di tipo CLOB. Con Type 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, Oracle fornisce XDK ( 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 DOM e SAX. Da questa panoramica risulta evidente che l adattamento di un DB relazionale (sebbene fornito di estensioni OO) per la gestione dell incontra varie difficoltà. Queste sono generate tutte dal problema di fondo che l è 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-

4 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 in un database 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 nativi, tra i quali s è messa particolarmente in luce la tedesca Software AG che conosceremo nel prossimo paragrafo. Software AG: the company Software AG ( è 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 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. Ma Tamino non è solo un database, è una piattaforma completa per lo sviluppo di applicazioni, completo di editor, parser e processor 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. Bisogna subito notare che Tamino consente l archiviazione dei dati, oltre che nel proprio 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 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 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 che si intendono gestire. Alla versione attuale (2.3.1), Tamino accetta la descrizione mediante DTD, ma è già previsto il pieno supporto di Schema quando questo sarà perfettamente formalizzato dal W3C. Documenti non descritti preventivamente possono essere comunque archiviati in Tamino. La descrizione dei documenti 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 39

5 40 essere anche composto da altri nodi, consentendo di creare documenti 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 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 definite dal W3C mediante XPath. Un esempio di query è il seguente: Rossi ]/ indirizzo 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. È possibile anche utilizzare X-Query per ricercare documenti 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 sono, al momento, i due principali difetti di Tamino. Per incrementare la propria presenza sul mercato, Software AG ha stipulato varie partnership. In particolare 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, 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. Almeno per ora nessuno ha monopolizzato il mercato dei database 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 -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 xml/readerschoice/index_d.html. BIBLIOGRAFIA [1] E. X. Dejesus - enters the DBMS Arena, Computerworld, [2] M. Leon - Find a home for your data, Infoworld, [3] R. Bourret - Database Products, [4] R. Bourret - And Databases, [5] excelon - Extensible Information Server, White Paper, [6] S. Muench - Using and Relational Databases for Internet Appl., Oracle corp., [7] Oracle - Using in Oracle Database Applications, White Paper, [8] L. Di Palma - L di Software Ag a caccia di Java-partner, Week.it, [9] SoftwareAG - Tamino 2.3.1, Documentazione tecnica, 2001.