Università della Calabria

Transcript

1 Università della Calabria Facoltà d Ingegneria Dipartimento di Elettronica, Informatica e Sistemistica Tesi di Laurea Ingegneria Informatica Tecniche di gestione di Dati Semi Strutturati Relatore Prof. Luigi PALOPOLI Candidato Mike BARONE

2 Indice Introduzione. 1 CAPITOLO 1 Modelli per Dati Semi Strutturati Rappresentazione di Dati Semi Strutturati Database Relazionali e ad Oggetti Tipi e Sintassi Il Modello OEM Basi di Dati ad Oggetti e ODMG Altri Modelli DOM Data Guide S3 Graph CM Hypergraph e Scheme Tree EER e XGrammar ORA SS Terminologia CAPITOLO 2 XML Sintassi di Base di XML XML e Dati Semi Strutturati DTD e struttura di un Documento Definizioni di Grammatiche e Schemi in DTD Dichiarazione di Attributi in DTD Navigazione di documenti XML XPath XPointer.. 38 I

3 Indice XLink XML Schema Estrarre Informazioni da fonti XML CAPITOLO 3 Linguaggi di Interrogazione Espressioni di Percorso Lorel e UnQL Linguaggi per XML XQuery XML QL XSLT Relazioni tra Linguaggi Logica del Primo Ordine Crazione di Oggetti Ricorsione Bisimulation StruQL CAPITOLO 4 Schema per Dati Semi Strutturati Impiego dei Tipi Formalismo Logica e Datalog Simulation Confronto tra i due schemi Estrazione di uno Schema dai Dati Data Guides Estrarre regole Datalog dai Dati Deduzione di uno Schema dalle Queries Controllo sui Tipi II

4 Indice 4.6 Vincoli DB Relazionali e ad Oggetti Dati Semi Strutturati CAPITOLO 5 Elaborazione delle Queries Architettura Memorizzazione di Dati Semi Strutturati Indicizzazione di Dati Semi Strutturati Queries Distribuite Mediatori Esempi di Sistemi CAPITOLO 6 Web Semantico Cosa è il Semantic Web RDF e descrizione dei Dati Topic Maps Annotazioni e Ricerche OWL e Ontologie Servizi Web e Agenti Il Quadro Generale Conclusioni Bibliografia III

5 Introduzione Fino a pochi anni fa l uso di dati in formato elettronico era limitato esclusivamente ad aree tecniche o scientifiche. Al giorno d oggi invece molte persone utilizzano tali dati, per esempio attraverso documenti web, generati in gran parte in modo automatico da databases esistenti. Il web rappresenta uno strumento semplice ed universale per lo scambio d informazioni. Queste informazioni devono essere scomposte in unità più piccole in modo tale da poter essere identificate e trasmesse. Generalmente si parla di files creati da qualche utente che poi li condivide rendendoli disponibili agli altri utenti tramite un URL. Un documento web ha in ogni caso una sua struttura per quel che riguarda la sua visualizzazione e non solo. D altro canto da un punto di vista dei databases l informazione è strutturata secondo altri principi. Le persone che lavorano in tale ambito usano schemi e diagrammi di Entità Relazione per descrivere la struttura dati e in genere i sistemi di condivisione dell informazione usati sono abbastanza diversi da quelli del web, si ha a che fare con problemi di concorrenza o di recupero dei dati al fine di preservarne la loro integrità e struttura. Esiste dunque la necessità di un ponte tra questi due approcci per lo scambio dell informazione. XML rappresenta il primo passo di convergenza tra questi due punti di vista di strutturazione dell informazione in quanto risulta sintatticamente legato al linguaggio HTML, ma ha come scopo quello di descrivere la struttura dei dati e non la loro visualizzazione. Volendo essere più schematici possiamo dire che il web ci fornisce tecnologie per: Un infrastruttura globale e un insieme di standards per supportare lo scambio di documenti. Un formato di visualizzazione per ipertesto. Un interfaccia utente per il recupero dei documenti. Un nuovo formato, XML per lo scambio di dati con struttura. Dall altro lato le tecnologie per i database riguardano: Tecniche di immagazzinamento e linguaggi d interrogazioni che forniscono un accesso efficiente a grandi moli di dati fortemente strutturati. Modelli di dati e metodi per strutturare tali dati. Meccanismi per mantenere l integrità e la consistenza dei dati. Un nuovo modello, quello dei dati semi strutturati, il quale allenta i vincoli dei sistemi di database altamente strutturati. Dall incontro degli ultimi punti e cioè XML e dati semi strutturati stanno nascendo nuove tecnologie per la gestione dei dati sul web. I sistemi di database usano un modello con tre livelli di astrazione: il livello fisico che descrive le modalità attraverso cui i dati sono immagazzinati, il livello logico che si occupa delle queries ed infine esiste un terzo livello, chiamato livello esterno, che ha a che fare con l interfaccia tra l utente e i dati, ossia la visualizzazione di questi ultimi. 1

6 Introduzione In genere la distinzione tra livello fisico e livello logico nel caso del web non esiste in quanto vengono trattati pezzi d informazioni molto piccoli. XML, infatti, è usato per rappresentare sia fisicamente che logicamente i dati. Un altro aspetto molto importante è la diversità dei dati, ossia l eterogeneità della struttura delle differenti sorgenti di dati. XML e i suoi vari linguaggi d interrogazione, ancora una volta, rappresentano una buona soluzione per tale problematica. Volendo collocare XML nel processo di elaborazione dei dati sul web, risulta naturale sistemarlo in quello strato, chiamato middleware, che fa da ponte tra server e client, come illustra il seguente diagramma. client client client middleware XML server server Figura 1.1 Architettura di un applicazione web. Lo strato in basso rappresentato dai servers costituisce la sorgente dati, ossia database convenzionali o qualsiasi altra applicazione che produce dati. Nello strato più alto ci sono i clients ossia interfacce utenti e applicazioni varie. Lo strato centrale middleware si occupa di trasformare e integrare i dati. In questo strato, tra le altre cose, i dati memorizzati nei databases, secondo un certo schema, sono tradotti in un modello logico e formato comune, per esempio XML. Il modello di dati semi strutturati quindi gioca due ruoli fondamentali nei sistemi di database: 1. Serve come modello per l integrazione di database, in altri termini, per descrivere il contenuto in due o più database, i quali contengono dati simili ma con schemi diversi. 2. Serve come modello di documento in notazioni come XML, per condividere informazioni sul web. 2

7 Capitolo 1. Modelli per Dati Semi Strutturati. Se si volesse spiegare in poche parole cosa sono i dati semi strutturati, si potrebbe dire che sono dati né completamente strutturati né strettamente tipizzati come accade nei database convenzionali. Volendo essere pù precisi però, dovremmo elencare le principali proprietà che caratterizzano tali tipi di dati, vale a dire: Struttura Irregolare In molte applicazioni i dati memorizzati sono spesso eterogenei. Alcuni elementi possono essere incompleti. Altri possono invece contenere informazioni aggiuntive, come ad esempio dei commenti. Tipi diversi possono essere utilizzati per memorizzare lo stesso tipo d informazione: un medesimo tipo di dato può essere strutturato in alcuni punti come una stringa ed in altri come una tupla. Struttura Implicita A volte, nonostante la struttura esista, è implicita. Spesso i documenti in formato elettronico consistono di un testo e di una grammatica. Il processo di parsing del documento permette di isolare pezzi d informazione e scoprire relazioni tra essi ed in alcuni casi l interpretazione di queste relazioni può essere costosa. Inoltre sovente non si ha uno schema, perciò la struttura è considerata implicita, vale a dire fornita esplicitamente dai tag. Struttura Parziale Avere dei dati strutturati al cento per cento è quasi impossibile. Alcuni dei propri dati possono non avere struttura, spesso le applicazioni mantengono alcune informazioni al di fuori dei database. Il caricamento, l analisi e l integrazione all interno del database di questi dati esterni sono operazioni da svolgersi in maniera efficiente. Struttura Indicativa Nei database standard i dati sono strettamente tipizzati. Per altri tipi di applicazioni questo tipo di politica è troppo restrittiva. Per questo è possibile utilizzare, al posto di uno schema rigido, delle linee guida che forniscono delle informazioni indicative sull uso di volta in volta dei tipi di dati. Definizione di uno schema a posteriori I database system tradizionali sono basati sull ipotesi che lo schema è fisso e deve essere definito a priori, prima dell introduzione dei dati. Nei dati semi strutturati la nozione di schema è spesso posteriore all esistenza dei dati stessi. Schema Grande L avere una grande mole di dati eterogenei porta alla conseguente crescita dello schema. Questo aspetto è in contrasto con i database relazionali in cui ci si aspetta che lo schema sia di qualche ordine di grandezza inferiore rispetto ai dati che essi contengono. 3

8 Capitolo 1 Modelli per Dati Semi Strutturati Per questo motivo, trattando di dati semi strutturati, non è detto che l utente conosca tutti i dettagli dello schema. Quindi effettuare query sullo schema è importante quanto effettuare query sui dati. Schema in rapida Evoluzione Tipo di dati Variabile Un altro aspetto dei dati semi strutturati è che la struttura degli elementi può dipendere dal modo in cui sono stati acquisiti. Distinzione tra Schema e Dati non netta Nei dati semi strutturati non esiste quella netta differenza tra schema e dati che possiamo invece ritrovare nelle applicazioni relazionali: sono frequenti gli aggiornamenti dello schema, nell inserimento di nuovi dati è possibile violare alcune regole dello schema stesso, quest ultimo può essere molto grande e gli stessi aggiornamenti possono essere effettuati sia sui dati che sulla grammatica. Inoltre nei dati semi strutturati bisogna tenere in considerazione alcuni aspetti importanti come: Modelli e Linguaggi È necessario scegliere un modello adeguato per descrivere e per utilizzare i dati e dei linguaggi appropriati. In questo caso si intendono sia i linguaggi di interrogazione sia quelli per integrare dati provenienti da differenti fonti. Si possono incontrare delle difficoltà in quanto esiste una parziale conoscenza della struttura, la quale può essere anche ciclica. Estrazione ed utilizzo della struttura L idea principale è, partendo da un insieme di dati non strutturati o con una struttura non completamente esplicitata, quella di applicare tecniche di data mining per estrarre informazioni strutturate. 1.1 Rappresentazione di Dati Semi Strutturati. Una caratteristica dei dati semi strutturati, spesso messa in evidenza, è quella che non esiste una descrizione separata dei tipi o della struttura dati, cioè sono auto descrittivi o senza schema. Tipicamente quando memorizziamo dei dati, per prima cosa ne descriviamo la struttura, cioè tipi e schema, dopodicchè creiamo delle istanze di questi tipi. Nei dati semi strutturati invece descriviamo i dati direttamente tramite una semplice sintassi. Per esempio possiamo rappresentare una tupla con una coppia etichetta valore: { nome: {proprio: Mario, cognome: Rossi }, tel: , m.rossi@ .com } 4

9 Capitolo 1 Modelli per Dati Semi Strutturati In questo caso, per esempio, l etichetta è cognome mentre il valore è Rossi. Possiamo anche usare una rappresentazione grafica come in figura 1.2 dove i nodi rappresentano gli oggetti e gli archi le etichette. Sulle foglie ci sono i valori. nome tel m.rossi@ .com proprio cognome Mario Rossi Figura 1.2 Struttura rappresentata tramite un grafo. Possiamo anche duplicare le etichette rendendo quindi la sintassi più facile per descrivere insiemi di tuple come: { persona: {nome: Mario, telefono: }, persona: {nome: Giorgio, telefono: } } Non siamo costretti a formare le tuple persona tutte dello stesso tipo, questo è uno dei punti forti dei dati semi strutturati che hanno l abilità di accomodare variazioni nelle strutture. Tale diversificazione consiste tipicamente nella mancanza di dati, campi duplicati o variazioni minori nella rappresentazione, come in: { persona: {nome: Mario, telefono: }, persona: {nome: {proprio: Giorgio, cognome: Verdi }, tel: , g.verdi@ .com }, persona: {nome: Antonio, Altezza: 181 } } 5

10 Capitolo 1 Modelli per Dati Semi Strutturati Nei dati semi strutturati quindi è come se ci dimenticassimo dei tipi e non facciamo altro che accompagnare ogni dato con una sua descrizione ( da ciò deriva il termine autodescrittivi ). Ovviamente questo modo di fare produce un notevole spreco di spazio, poiché dobbiamo ripetere tali descrizioni per ogni dato, ma d altro canto ci guadagniamo in flessibilità. 1.2 Database Relazionali e ad Oggetti. Un database Relazionale di solito è descritto da uno schema del tipo r1(a,b,c) r2(c,d) dove r1 e r2 rappresentano i nomi delle relazioni, mentre a,b,c e c,d rappresentano i nomi delle colonne delle relazioni. Di solito le istanze di questi schemi sono visualizzate in delle tabelle tramite delle righe, come in figura 1.3. r1 : a b c r2 : c d a1 b1 c1 a2 b2 c2 Figura 1.3 Esempio di Relazioni. c2 c3 c4 d2 d3 d4 Utilizzando la rappresentazione etichetta valore, le relazioni r1 e r2 ci appaiono nel seguente modo: { r1: {riga: {a: a1, b: b1, c: c1 }, riga: {a: a2, b: b2, c: c2 } }, r1: {riga: {c: c2, d: d2 }, riga: {c: c3, d: d3 }, riga: {c: c4, d: d4 } }, } Ovviamente è possibile rappresentare le tuple anche tramite un albero come in figura 1.4 6

11 Capitolo 1 Modelli per Dati Semi Strutturati r1 r2 riga riga riga riga riga a c a c c d c d c d b b a1 b1 c1 a2 b2 c2 c2 d2 c3 d3 c4 d4 Figura 1.4 Rappresentazione ad albero di Relazioni. Oltre al modello relazionale, le moderne applicazioni di database utilizzano anche il modello ad Oggetti. Tali dati possono ugualmente essere rappresentati come dati semistrutturati. Consideriamo per esempio la collezione di tre oggetti persona in cui Maria ha due figli, Giovanni e Gloria. { persona: &o1{nome: Maria, età: 40, figlio: &o2, figlio: &o3 }, persona: &o2{nome: Giovanni, età: 18, parenti: {madre: &o1, sorella: &o3} }, persona: &o3{nome: Gloria, paese: Italia, madre: &o1 }, } Quando si ha a che fare con strutture che utilizzano dei riferimenti tra oggetti, bisogna che tali oggetti abbiano un identità, perciò si utilizzano degli identificatori, chiamati più precisamente Identità degli Oggetti, come nel nostro caso &o1, &o2 e &o3 che legano queste etichette alle relative strutture. Tutto ciò ci permette di costruire dei grafi con sottostrutture condivise e con dei cicli come mostrato in figura

12 Capitolo 1 Modelli per Dati Semi Strutturati persona persona persona figlio &o1 figlio &o2 madre &o3 nome età nome parenti età nome paese Maria 40 Giovanni 18 Gloria Italia madre sorella Figura 1.5 Una struttura ciclica. I dati quindi sono rappresentati come un grafo in cui ogni nodo ha il suo oid unico. Questi identificatori, oid, non sono altro che stringhe o interi ma comunque il loro significato è ristretto ad un certo dominio. Oltre ad un significato logico è importante capire anche cosa denotino fisicamente. Per esempio per dati caricati in memoria, un oid rappresenta un puntatore ad una locazione di memoria, mentre per dati presenti su un disco rappresenta magari un indirizzo del disco. In un contesto di scambio di dati sul web un oid fa parte di uno spazio globale quindi per estrarre un oggetto da un database è probabile che la query sia preceduta da un URL. E possibile tuttavia che oid di diversi domini coesistano in uno stesso ambito e siano tradotti durante la fase di scambio dei dati. 8

13 Capitolo 1 Modelli per Dati Semi Strutturati 1.3 Tipi e Sintassi. Volendo ricapitolare la sintassi sviluppata fino ad ora, possiamo chiamare le espressioni dei dati semi strutturati come espressione dss. Assumendo una sintassi standard per etichette e tipi atomici e rappresentando gli identificatori di oggetti con il prefisso &, avremo: <espr dss> ::= <valore> oid<valore> oid <valore> ::= valoreatomico <valorecomplesso> <valorecomplesso> ::= {etichetta:<espr dss>,..., etichetta:<espr dss>} Affermeremo che un identificatore d oggetti o è definito in un espressione dss s se s è della forma o v per qualche valore di v oppure se s è della forma {l 1 :e 1,...,l n :e n } e o è definito in una delle e 1 e n. Se o è presente in qualsiasi altro modo in s, diremo che esso è usato in s. Un espressione dss s per essere consistente deve soddisfare le seguenti proprietà: Ogni identificatore di oggetti è definito al massimo una volta in s. Se un identificatore di oggetti o è usato in s, allora deve essere definito in s. Per quel che riguarda i tipi base, negli esempi visti, si sono usati numeri ( 135, 2.7, ecc. ), stringhe ( Giorgio, g.verdi@ .com, ecc. ), ed etichette ( nome, altezza, ecc. ). Questi tipi sono distinguibili grazie alla sintassi usata: un numero inizia con una cifra, una stringa con le virgolette e via discorrendo. Ovviamente si possono usare tanti altri tipi come: il tipo data, tipo immagine gif, tipo audio wav, ecc. purché siano adeguatamente codificati. 1.4 Il modello OEM. Il formato dati auto descrittivo è stato usato per molto tempo per lo scambio di dati tra applicazioni. L uso per lo scambio tra sistemi eterogenei è più recente. Il modello OEM, [McH97] la cui sigla sta per Object Exchange Model ovvero modello di scambio degli oggetti, fu sviluppato proprio in un contesto d integrazione di sorgenti dati eterogenei. La sua presentazione originale era la seguente: Un oggetto OEM è una quadrupla del tipo (etichetta, oid, tipo, valore), dove etichetta è una stringa di caratteri, oid è un identificatore di oggetti, tipo può essere complesso o denotare un tipo atomico ( intero, stringa, ecc. ). Quando il tipo è complesso, allora l oggetto è chiamato oggetto complesso, e valore è un insieme di oid. Altrimenti l oggetto è un oggetto atomico e valore è un valore atomico di quel tipo. I dati in OEM sono raffigurati essenzialmente da un grafo con le etichette sui nodi invece che sui rami. Molti sistemi in realtà usano etichettare i rami invece che i nodi e questo rappresenta il modello di uso prevalente nell ambito di dati semi strutturati. Un tipico esempio di diagramma OEM è quello di figura 1.6 dove si può notare che gli oggetti 9

14 Capitolo 1 Modelli per Dati Semi Strutturati atomici sono le foglie del diagramma, mentre gli oggetti complessi sono i nodi intermedi. L oggetto complesso con identificatore &e3, per esempio, ha la seguente tupla: ( corso, &e3, oggetto complesso, {(studente, &e4), (codice, &e5), (titolo, &e6)} ) Un oggetto atomico invece ( per esempio &e9 ) ha la seguente tupla : ( voto, &e9, oggetto atomico, 30 ) dipartimento nome &e1 corso &e2 &e3 Ingegneria studente codice titolo &e4 &e5 &e6 nome id voto INF Informatica &e7 &e8 &e9 Rossi Figura 1.6 Esempio di diagramma OEM. Un modello OEM quindi indica la struttura degli oggetti e fornisce una rappresentazione sia grafica che testuale. Tale modello comunque (come altri) non riesce a distinguere tra elementi ed attributi, come si vedrà con XML. 1.5 Basi di Dati ad Oggetti e ODMG. Sempre più applicazioni usano un modello dati orientato agli oggetti e la maggior parte di quest ultimi seguono le specifiche ODMG [Cat94]. Vediamo come è possibile rappresentare dati in ODMG nel formato semi strutturato. Di seguito è riportato uno schema ODMG espresso in ODL, il linguaggio di definizione degli oggetti di ODMG: 10

15 Capitolo 1 Modelli per Dati Semi Strutturati class Regione (extent regioni){ attribute string rcodice; attribute string rnome; attribute Citta capoluogo; relationship set<citta> citta in inverse Citta::regione di; } class Citta (extent citta){ attribute string ccodice; attribute string cnome; relationship Regione regione di inverse Regione::citta in; } Dallo schema precedente si evince che ODMG possiede già alcuni tipi come liste, insiemi, array, ecc.. Inoltre fornisce anche una sorte di legame con gli oggetti nel database, infatti nel nostro caso regioni e citta non sono altro che un insieme di oggetti e sono definito come extent rispettivamente delle classi Regione e Citta. Gli insiemi regioni e citta contengono tutti gli oggetti creati dai loro costruttori, i quali sono definiti tramite un linguaggio esterno tipo C++ o Java e non tramite ODL. Se prendiamo come esempio l oggetto Citta noteremo che contiene oltre a normali attributi, come ccodice e cnome, anche una sorta di attributo relazione chiamato relationship che ha lo scopo di creare una reciproca relazione tra le due classi. Il fatto che citta in e regione di sono ognuna il reciproco dell altra ci permette di dire che per ogni oggetto r di tipo Regione e ogni oggetto c di tipo Citta che si trova in r.citta in allora c.regione di risulta essere uguale a r. Il passaggio da ODMG ad una rappresentazione semi strutturata è diretto e lo vediamo di seguito: {regioni: {regione: &r1{rcodice: CAL, rnome: Calabria, capoluogo: &c1, citta in:{citta: &c1,citta: &c3, } }, regione: &r2{rcodice: LOM, rnome: Lombardia, capoluogo: &c2, citta in:{citta: &c2, } },... } citta: {lacitta: &c1{ccodice: CS, cnome: Cosenza, regione di: &r1} 11

16 Capitolo 1 Modelli per Dati Semi Strutturati } lacitta: &c2{ccodice: MI, cnome: Milano, regione di: &r2} lacitta: &c3{ccodice: CZ, cnome: Catanzaro, regione di: &r1}... } Si noti come ogni attributo, in questo caso oggetto, possiede un identificatore per distinguerli dagli altri. Dal punto di vista semi strutturato, sia i tipi che le reciproche relazioni diventano una forma speciale di vincoli. 1.6 Altri Modelli. Esistono tanti altri modelli per dati semi strutturati, con caratteristiche più o meno diverse, qui di seguito passiamo in rassegna alcuni tra i più importanti DOM Il Modello DOM ( Document Object Model ) [App98] descrive l istanza di un documento XML come un albero. Ogni nodo rappresenta un oggetto che contiene una delle componenti di una struttura XML. I tipi di nodi più comuni sono tre: nodo elemento, nodo attributo e nodo testo. Come illustrato dalla figura 1.7(a) si può notare che i nodi testo non hanno un nome ma comunque contengono del testo come per esempio il nodo con testo Informatica. I nodi attributo hanno invece sia un nome e sia un testo, per esempio il nodo con testo Ingegneria., infine il nodo elemento ha un nome con magari dei figli come il nodo corso. Gli archi tra i nodi rappresentano le relazioni tra i nodi. Un albero DOM descrive l istanza di un documento mostrando la struttura gerarchica degli elementi e le relazioni implicite tra gli elementi. E possibile distinguere tra elementi ed attributi, comunque poiché DOM rappresenta un istanza di un documento XML, non fornisce direttamente informazioni sullo schema, come la cardinalità dell insieme delle relazioni, non permette di distinguere tra elementi ordinati e disordinati o capire se un attributo appartiene ad un insieme di relazioni o a un insieme di elementi. 12

17 Capitolo 1 Modelli per Dati Semi Strutturati dipartimento nome corso Ingegneria studente codice titolo INF dipartimento nome corso codice titolo studente nome id voto nome id voto (b) Rossi Informatica (a) Figura 1.7 (a) Diagramma DOM (b) DataGuide Data Guide Un Data Guide [Gol97] modella lo schema di un istanza di un grafo OEM descrivendo ogni percorso attraverso le istanze solo una volta. Considerando per esempio il grafo OEM di figura 1.6, il relativo Data Guide è raffigurato in figura 1.7(b). Dal dataguide risultano facilmente visibile le istanze degli insiemi degli elementi. Gli oggetti dipartimento, corso e studente sono oggetti complessi ( in particolare degli oggetti corso e studente avremo occorrenze multiple ) mentre gli altri, come nome, codice, titolo, ecc. sono oggetti atomici. Questo modello come quello OEM raffigura soltanto gerarchicamente gli elementi e non distingue tra elementi e attributi. Torneremo a parlare di Data Guide più avanti nel capitolo S3 Graph Un S3 Graph ( Semi Structured Schema Graph ) [LLD05] è un grafo dove ogni nodo può essere classificato come un nodo entità o un nodo riferimento. Un nodo entità rappresenta un entità, la quale può essere di tipo atomico ( tipo una stringa ) oppure complesso ( tipo uno studente ). Un nodo riferimento è un nodo che punta ad un nodo entità. Ad ogni arco 13

18 Capitolo 1 Modelli per Dati Semi Strutturati nel grafo è associato un tag che rappresenta la relazione tra il nodo sorgente e il nodo destinazione. Il tag può avere un suffisso *, mentre esistono tre tipi di archi: 1. Arco Componente Un nodo V 1 è connesso ad un nodo V 2 tramite un arco componente con un tag T se V 2 è un componente di V 1. Se il tag T possiede il suffisso *, la relazione è interpretata come il tipo entità rappresentato da V 1 ha T multipli altrimenti V 1 possiede al massimo una T. 2. Arco Riferimento Un nodo V 1 è connesso ad un nodo V 2 tramite un arco riferimento se V 1 punta all entità rappresentata dal nodo V Arco Radice Un nodo V 1 è puntato da un arco radice con un tag T se il tipo entità rappresentato da V 1 è posseduto dal database. V 1 rappresenta il nodo radice. La figura 1.8 mostra un esempio di S3 Graph. dipartimento nome #1 corso* #2 #3 stringa studente* codice titolo #4 #5 #6 nome id voto stringa stringa #7 #8 #9 stringa intero intero Figura 1.8 Esempio di S3 Graph. Un S3 Graph è capace quindi di catturare la struttura gerarchica dell insieme degli elementi e fornisce inoltre riferimenti. 14

19 Capitolo 1 Modelli per Dati Semi Strutturati CM Hypergraph e Scheme Tree Questo modello [Emb01] dati consiste di due diagrammi: L ipergrafo CM ( conceptualmodel ) e lo Scheme Tree. L ipergrafo CM modella i dati concettualmente, modellando l insieme di oggetti e di relazioni, mentre lo schema tree modella solo la struttura gerarchica del documento. Nell ipergrafo CM gli oggetti sono rappresentati come rettangoli con delle etichette, come nel caso di dipartimento, le relazioni sono rappresentate da archi. Un arco senza freccia rappresenta una relazione molti a molti, un arco con una freccia rappresenta invece una relazione molti a uno e un arco con entrambi le frecce alle estremità rappresenta una relazione uno a uno. Il simbolo o indica che l oggetto è opzionale. Lo scheme tree rappresenta le stesse informazioni rappresentate dal DataGuide. Vediamo in figura 1.9(a) un Ipergrafo CM e in figura 1.9(b) uno scheme tree. dipartimento nome corso studente codice titolo voto id nome (a) dipartimento, nome studente, id, nome corso, codice, titolo studente voto (b) Figura 1.9 (a) CM Hypergraph (b) Scheme Tree. Questo modello quindi è in grado di descrivere i dati, sia da un punto di vista concettuale e sia da un punto di vista della struttura gerarchica dello schema, non riesce comunque a rappresentare un istanza del documento. L ipergrafo CM può modellare sia relazioni binarie che con arietà superiore ma il numero di oggetti può crescere molto velocemente e rendere il grafo molto complesso. 15

20 Capitolo 1 Modelli per Dati Semi Strutturati EER e XGrammar Un linguaggio e un diagramma per modellare schemi XML fu definito in [Man01]. Il linguaggio chiamato XGrammar fu progettato con lo scopo di catturare le caratteristiche più importanti del linguaggio XML Schema. Il diagramma, chiamato EER ( Extended Entity Relationship ), oltre ad avere il potere espressivo del diagramma entità relazione riesce a catturare anche aspetti di relazioni gerarchiche e di ordinamento degli elementi. Le entità sono raffigurate come rettangoli e le relazioni come rombi. XGrammar è in grado di esprimere relazioni gerarchiche tra gli elementi, distinguere gli attributi dagli elementi utilizzando una tupla di cinque componenti {N,T,S,E,A} in cui: 1. N è l insieme di simboli non terminali che rappresentano le entità. 2. T è l insieme di simboli terminali, i quali rappresentano istanze di entità e attributi. 3. S è il simboli non terminale che rappresentano la radice. 4. E è l insieme di regole di produzione che descrivono le relazioni tra entità. 5. A è l insieme di regole di produzione che descrivono gli attributi. nome codice titolo Dipartimento (1,1) (1,*) ha Corso (1,*) ha voto (0,*) Studente id snome Figura 1.10 Esempio di EER. In figura 1.10 possiamo vedere una raffigurazione del diagramma EER per l esempio dipartimento usato in precedenza. Di seguito invece consideriamo il linguaggio XGrammar per lo stesso esempio: 16

21 Capitolo 1 Modelli per Dati Semi Strutturati N = { Dipartimento, Corso, Studente, Ha } T = { dipartimento, corso, studente, ha, nome, codice, voto, titolo, id, snome } S = { Dipartimento } E = { Dipartimento > dipartimento(corso+), Corso > corso(ha*), Ha > ha(ε ), Studente > studente(ε )} A = { Dipartimento > dipartimento(@nome::string), Corso > corso(@codice::string,@titolo?::string), Ha > ha(@studenteref::idref Studente > studente(@id::string,@snome::string,)} I simboli ε, sono usati rispettivamente per esprimere sottoelementi vuoti, riferimenti e attributi. Osserviamo che l insieme N contiene i nomi degli insiemi entità Dipartimento, Corso, Studente e Ha. La relazione ha tra le entità Corso e Studente è modellata come un insieme entità in XGrammar perché possiede l attributo voto. XGrammar modella le relazioni molti a molti con un attributo come un entità separata. L insieme T contiene sia le entità che gli attributi mentre l insieme S contiene la radice Dipartimento. L insieme E specifica le relazioni tra le entità, per esempio la prima regola specifica che l entità Dipartimento possiede uno o più Corsi. Da notare come Dipartimento rappresenta l insieme delle entità, mentre dipartimento raffigura un istanza di Dipartimento. Gli attributi e i vincoli sono raccolti nell insieme A. Con EER e XGrammar è possibile rappresentare diversi concetti, quindi risulta essere un potente strumento, anche se non possiede mezzi per ciò che riguarda le istanze di un documento XML ORA SS Il modello dati ORA SS [Dob00] si avvale di quattro concetti base: Classi di Oggetti, Tipi di Relazione, Attributi e Riferimenti. Consiste inoltre di quattro diagrammi: Diagramma Schema, Diagramma Istanze, Diagramma delle Dipendenze Funzionale e il Diagramma Ereditarietà. Il Diagramma Schema descrive la struttura e i vincoli di un istanza, è un grafo in cui ogni nodo interno è una classe oggetto e ogni nodo foglia è un attributo complesso o meno. E molto simile ad un ipergrafo CM solo che ha una semantica più ricca. Un esempio è mostrato in figura 1.11(a). Il Diagramma Istanze è come un DOM Tree e serve a catturare le istanze di un documento. Tradizionalmente quando si progetta un database lo schema è creato utilizzando un modello concettuale e poi da questo si deriva lo schema del database. Con i dati semi strutturati l attenzione è focalizzata di più sull istanza da cui si deriva poi lo schema. Un diagramma istanza è un grafo i cui nodi interni sono gli oggetti e le foglie sono attributi con un valore. Ogni arco rappresenta una 17

22 Capitolo 1 Modelli per Dati Semi Strutturati relazione tra nodo padre e nodo figlio. Gli oggetti sono dei rettangoli con etichetta mentre gli attributi sono dei cerchi. Un esempio è mostrato in figura 1.11(b). Il Diagramma delle Dipendenze Funzionali cattura appunto le dipendenze funzionali che non possono essere espresse dal diagramma schema, come le relazioni non binarie. Esistono due tipi di dipendenze: il primo tipo contiene attributi di classi di oggetti e tipi relazione sul lato destro della dipendenza. Considerando la figura 1.11(a) avremo per esempio: codice titolo id snome codice, id voto Il secondo tipo di dipendenze invece coinvolge classe di oggetti che partecipano in un tipo relazione come: corso dipartimento In questo tipo di diagramma le classi degli oggetti sono rappresentati con dei rettangoli etichettati. Per i tipi relazione si usano dei rombi con etichette mentre sugli archi è riportata la cardinalità degli oggetti. Il Diagramma Ereditarietà cattura le relazioni ISA, ossia il fatto che un oggetto è una sottoclasse di un altro oggetto. Questo diagramma è utile per l organizzazione della memorizzazione dei dati. dipartimento dipartimento ingegneria, 2,1:n,1:1 nome corso informatica, 2,0:n,1:1 nome: ingegneria corso codice? titolo studente informatica codice: INF titolo: informatica studente? id snome voto id: snome: voto: Rossi 30 (a) (b) Figura 1.11 (a) Diagramma Schema (b) Diagramma Istanze. 18

23 Capitolo 1 Modelli per Dati Semi Strutturati Nel modello ORA SS, progettato esclusivamente per dati semi strutturati, esiste una netta distinzione tra classi di oggetti e attributi. Il punto forte di ORA SS è quello di essere in grado di modellare concetti importanti per dati semi strutturati come: riferimenti, ordinamento di oggetti e attributi, istanze di documenti e concetti importanti nei database tradizionali come per esempio le relazioni con arietà maggiore di due o ereditarietà tra classi. 1.7 Terminologia. La terminologia usata per descrivere i dati semi strutturati è essenzialmente quella che si usa per i grafi, con qualche lieve variazione. Di seguito un breve riepilogo: Un grafo(n,e) è costituito da un insieme di nodi N e da un insieme di archi E. Associato ad ogni arco e E esiste una coppia di nodi ordinata, il nodo sorgente s(e) e il nodo destinazione d(e). Un percorso è una sequenza di lati e 1,e 2,,e k tale che d(e i ) = s(e i+1 ), 1 i k 1. Il numero di lati in questo percorso corrisponde alla sua lunghezza. Il nodo r si dice che è radice del grafo(n,e) se esiste un percorso da r a n, per ogni n N, con n r. Un ciclo in un grafo è un percorso tra un nodo e se stesso. Un grafo con nessun ciclo è detto aciclico. Un grafo con radice è un albero se esiste un unico percorso da r a n per ogni n N con n r. In un albero un nodo è un nodo terminale o una foglia se esso non rappresenta la sorgente di nessun altro arco nell albero. Alcuni esempi di grafi sono riportati in figura 1.7. grafo ciclico senza grafo aciclico con albero radice radice Figura 1.7 Esempi di Grafi. Il modello di grafo che si usa per i dati semi strutturati è quello con le etichette sui rami. Per cui abbiamo una funzione di etichettatura del tipo F E : E L E con L E dominio delle etichette. 19

24 Capitolo 2. XML. XML ( Extensible Markup Language ) è uno standard [XML98] adottato dal consorzio World Wide Web ( W3C ) allo scopo di integrare HTML nello scambio di dati sul web. Con HTML si parla della presentazione dell informazione contenuta nel documento, ossia quale porzione deve essere visualizzata in corsivo, dove inserire un collegamento, dove visualizzare un immagine, una form e cose di questo tipo. Per esempio se voglio visualizzare una tabella con tre persone in HTML, basta scrivere il seguente codice: <h1> Persone del quarto Piano <h1> <p> <b>mario</b>, 42 anni, <i>mario@abc.com</i> </p> <p> <b>pietro</b>, 28 anni, <i>pietro@abc.com</i> </p> <p> <b>luana</b>, 32 anni, <i>luana@abc.com</i> </p> Il risultato di questo codice, in un browser, risulta molto leggibile per un essere umano, mentre se un programma ne volesse capire la struttura, al contrario, sarebbe un operazione ardua. Esistono applicazioni in grado di tirar fuori una struttura da una pagina web, ma hanno il grande inconveniente d essere inefficaci, quando vengono apportare anche piccole variazioni nel documento. XML pone rimedio a questo tipo di problema in quanto tiene conto del contenuto del documento più che della presentazione. XML quindi è un linguaggio a marcatori estremamente flessibile, derivato da SGML e nato per gestire la pubblicazione su larga scala di documenti elettronici tramite il web. In seguito, XML si è rivelato adatto a rappresentare dati in contesti estremamente eterogenei. Uno degli obbiettivi di XML era quello di poter contenere nel documento una semplice specifica della sua struttura e del suo significato, in modo di renderlo autocontenuto dal punto di vista della possibilità di interpretarlo. In sintesi quindi XML è: Un formato generale usabile in ogni contesto. Standardizzato da W3C. Leggibile sia per le applicazioni software che per l occhio umano. Semplice da analizzare in modo automatico. Semplice ed efficace nel dare semantica al testo. Indipendente da piattaforme e fornitori/venditori. Una tecnologia che non richiede grossi investimenti. XML inoltre differisce da HTML sostanzialmente per tre punti: 1. Possono essere definiti nuovi tags. 2. La struttura può essere innestata con una profondità arbitraria. 3. Un documento XML può contenere una descrizione opzionale della sua grammatica. 20

25 Capitolo 2 XML XML permette agli utenti di definire nuovi tags per indicare delle strutture. Per esempio la struttura racchiusa dal tag <persona>...</persona> potrebbe essere usata per descrivere una tupla persona. XML non dà alcun istruzione su come visualizzare tale tupla. Tale informazione può essere memorizzata separatamente in un foglio di stile ed usare un linguaggio come XSL per tradurre da XML a HTML. XML è quindi una semplice sintassi per trasmettere dati e scambiare informazioni tra diverse applicazioni. 2.1 Sintassi di base di XML. XML è una rappresentazione testuale dei dati. La componente base di XML è l elemento, in altre parole un testo delimitato da una coppia di tags come <persona> e </persona>. Dentro un elemento possiamo avere del semplice testo, altri elementi o una combinazione dei due. Considerando il seguente esempio XML: <persona> <nome> Mario </nome> <eta> 42 </eta> < > mario@abc.com </ > </persona> Un espressione come <persona> è chiamata start tag, mentre </persona> è chiamata end tag. Questi tags devono essere bilanciati, si dice che formano un markup, e sono scelti dall utente. Il testo racchiuso da questi due tags è detto element e le strutture comprese in esse sono dette content. Il termine subelement è usato per descrivere la relazione tra un elemento e i suoi elementi componenti, come nel caso di < > </ >, che risulta essere sottoelemento di <persona> </persona>. In un documento XML è naturale trovare molti elementi ripetuti con gli stessi tags come nell esempio seguente: <tabella> <descrizione> Persone del quarto Piano </descrizione> <persone> <persona> <nome> Mario </persona> <eta> 42 </eta> < > mario@abc.com </ > </persona> <persona> <nome> Pietro </persona> <eta> 28 </eta> < > pietro@abc.com </ > </persona> <persona> <nome> Luana </persona> 21

26 Capitolo 2 XML <eta> 32 </eta> < > luana@abc.com </ > </persona> </persone> </tabella > Si può notare come i dati di questo documento XML corrispondano con quelli del documento HTML, solo che ora ci siamo interessati a descriverne il contenuto piuttosto che la presentazione. Tutti i dati sono trattati come testo, per questo la parte della sintassi non racchiusa dalle parentesi < > è considerata il testo del documento, riferito come PCDATA ( Parsed Character Data ). XML usa caratteri nel formato Unicode, cosa che lo rende internazionale. Infine per i tag esiste un abbreviazione di questo tipo: <sposato> </sposato> Può essere abbreviato con: <sposato/> Un altro aspetto molto importante di XML è l uso d attributi associabili agli elementi. Per essere precisi, bisogna dire che, XML usa il termine attributo per ciò che delle volte è chiamato proprietà nei modelli di dati. Gli attributi sono definiti dalla coppia ( nome, valore ). Nell esempio seguente gli attributi sono usati per specificare la lingua o la valuta : <prodotto> <nome lingua= Italiano > Chitarra classica </nome> <prezzo valuta= Euro > </prezzo> <indirizzo> <via> Via della Repubblica, 45 </via> <CAP> </CAP><citta> Treviso </citta> <paese> Italia </paese> </indirizzo> </prodotto> Il valore di un attributo è sempre una stringa e deve essere racchiusa tra virgolette, inoltre può comparire solo una volta all interno di un tag. Delle volte si può avere qualche ambiguità su come rappresentare un informazione, nel senso che si può adoperare sia un elemento sia un attributo, come nel caso di: <persona> <nome> Mario </nome> <eta> 42 </eta> < > mario@abc.com </ > </persona> 22

27 Capitolo 2 XML Potrebbe essere rappresentata anche come: <persona nome= Mario eta= 42 = mario@abc.com > XML è stato pensato per essere usato in due modi diversi: 1. XML ben formato In questo caso l utente è libero di inventare i propri tags, come le etichette degli archi nei dati semi strutturati. Questo modo è più vicino ai dati semi strutturati, in quanto non esiste uno schema. Un documento comunque per essere ben formato deve soddisfare alcuni requisiti e vale a dire quello di aprire e chiudere i tag nell ordine giusto, realizzando così una certa struttura gerarchica, ed inoltre gli attributi devono essere unici. 2. XML valido In questo caso l utente deve fornire una grammatica, per descrivere il modo in cui i tags devono essere innestati. Si usa per questo scopo un DTD ( che vedremo più avanti ), quindi l utente non ha più la libertà che aveva prima. 2.2 XML e Dati Semi Strutturati. La sintassi base di XML si adatta perfettamente ai dati semi strutturati. Il semplice documento XML: <persona> <nome> Mario </nome> <eta> 42 </eta> < > mario@abc.com </ > </persona> Ha la seguente rappresentazione in un espressione di dati semi strutturati. {persona: {nome: Mario, eta: 42, mario@abc.com }} La traduzione da un espressione di dati semi strutturati a XML può essere facilmente automatizzata, per esempio con una semplice funzione che chiamiamo T. T(valoreatomico) = valoreatomico T({l 1 :v 1,,l n :v n }) = <l 1 >T[v 1 ]</l 1 > <l n >T[v n ]</l n > Malgrado ciò non è sempre facile far conciliare XML con i dati semi strutturati, oltre all ambiguità introdotta dagli attributi, ci sono altre differenze che qui vedremo. 23

28 Capitolo 2 XML Grafo XML Esiste una certa differenza nel rappresentare dati semi strutturati e nel rappresentare un documento XML, nel primo caso abbiamo dei grafi con delle etichette sui rami, mentre nel secondo caso, grafi con etichette sui nodi. La figura 2.1 ci aiuta a capire meglio questa differenza. persona persona nome eta Mario 42 mario@abc.com nome eta Mario 42 mario@abc.com (a) (b) Figura 2.1 Albero per (a) documento XML (b) dati semi strutturati. Quando abbiamo a che fare con un albero, risulta immediato convertire da un formato all altro. Per esempio, partendo da un albero XML, basta trasferire le etichette d ogni nodo sui rispettivi archi entranti. Nel caso di dati rappresentabili tramite un grafo, come vedremo più avanti, la distinzione tra i due modelli diventa più marcata. Riferimenti XML XML possiede dei meccanismi per usare dei riferimenti, che possono essere usati per descrivere dei grafi piuttosto che degli alberi. Il meccanismo consiste nell associare ad un elemento un identificatore unico che chiamiamo id. Nell esempio seguente, associamo l identificatore r2 all elemento <regione>. <regione id= r2 > <rcodice> CAL </rcodice> <rnome> Calabria </rnome> </regione> In seguito, possiamo puntare a quest elemento utilizzando l attributo idref. Per esempio: <citta id= c2 > 24

29 Capitolo 2 XML <ccodice> CS </ccodice > <cnome> Cosenza </cnome > <regione di idref= r2 /> </citta> L elemento <regione di> è vuoto, in quanto il suo unico scopo è quello di puntare ad un altro elemento. Questa tecnica ovviamente ci permette di rappresentare strutture cicliche e ricorsive, come si deduce dalla seguente figura 2.2. <geografia> <regioni> <regione id = r1 > <rcodice> TOS </rcodice> <rnome> Toscana </rnome> <capoluogo idref= c1 /> <citta in idref= c1 /><citta in idref= c3 /> </regione> <regione id = r2 > <rcodice> LOM </rcodice> <rnome> Lombardia </rnome> <capoluogo idref= c2 /> <citta in idref= c2 /> </regione>... </regioni> <listacitta> <citta id = c1 > <ccodice> FI </ccodice> <cnome> Firenze </cnome> <regione di idref= r1 /> </citta> <citta id = c2 > <ccodice> MI </ccodice> <cnome> Milano </cnome> <regione di idref= r2 /> </citta> <citta id = c3 > <ccodice> PI </ccodice> <cnome> Pisa </cnome> <regione di idref= r1 /> </citta>... </listacitta> </geografia> Figura 2.2 Rappresentazione XML di riferimenti incrociati. 25

30 Capitolo 2 XML Con i riferimenti, l analogia tra XML e dati semi strutturati, risulta essere meno evidente. Considerando l istanza di dati semi strutturati riportata in figura 2.3, notiamo che può essere codificata in XML nel seguente modo: <a><b id= &o123 > qualche stringa </b></a> <a c= &o123 /> Assumendo che l attributo c indica un riferimento, oppure nel seguente modo <a b= &o123 /> <a><c id= &o123 > qualche stringa </c></a> Assumendo ora b come riferimento. a a b c qualche stringa Figura 2.3 Semplice istanza di dati semi strutturati. Ordinamento Il modello di dati semi strutturati visto in precedenza, si basa su collezioni non ordinate, mentre XML è ordinato. Prendiamo in esame il seguente esempio: persona:{nome: Mario, cognome: Rossi } persona:{cognome: Verdi, nome: Franco } questi due pezzi di dati semi strutturati sono equivalenti, mentre il seguente documento XML non lo è. <persona><nome> Mario </nome> <cognome> Rossi </cognome></persona> <persona><cognome> Verdi </cognome> <nome> Franco </nome></persona> In aggiunta, gli attributi in XML non sono ordinati, quindi anche i due seguenti documenti XML sono equivalenti. <persona nome= Mario cognome= Rossi /> <persona cognome= Verdi nome= Franco /> 26

31 Capitolo 2 XML L enfasi sull ordinamento in XML deriva dalla sua natura di linguaggio a marcatori. Nei documenti, l ordine è fondamentale, mentre nelle applicazioni dati sono prevalenti i dati non ordinati. I dati non ordinati possono essere processati in modo molto efficiente, per esempio, i database moderni ottimizzano quest aspetto utilizzando degli indici che permettono di recuperare le informazioni in un ordine diverso da come sono memorizzate sul disco. Le applicazioni che adoperano XML come scambio dati molto probabilmente ignorano la questione dell ordinamento. Altri dettagli su XML XML ci permette di mescolare PCDATA e sotto elementi nel contesto di un elemento creando quindi un elemento misto: <persona> Questo è il mio migliore amico <nome> Mario </nome> <eta> 42 </eta> Non sono sicuro circa la seguente < > mario@abc.com </ > </persona> Dal punto di vista dei database questo sembra poco naturale, ma è ragionevole invece da un punto di vista del documento. XML possiede altri costrutti, per la verità, usati poco nello scambio dei dati. I commenti in XML si presentano come: <! questo è un commento > Un altro costrutto consiste nel poter inserire delle istruzioni nel documento, dette PI, che sono poi eseguite dalle applicazioni. Un PI ha una destinazione ( cioè il nome dell applicazione ) e del testo opzionale. Nell esempio che segue xml stylesheet è la destinazione e il resto è testo libero che è passato all applicazione, quindi non possiede una semantica precisa: <?xml stylesheet href= book.css type= text/css?> Ogni documento XML inizia con una riga che indica la versione di XML usata: <?xml version= 1.0?> Un terzo costrutto usato è CDATA ( Character Data ) che permette di inserire dei blocchi contenenti caratteri da non interpretare come markup. Una sezione CDATA inizia con <![CDATA[ e termina con ]]>, come in quest esempio: <![CDATA[<start> questo è errato </end>]]> 27

32 Capitolo 2 XML Un quarto costrutto è costituito dalle entità, che hanno la forma di una macro. Un tipo d entità è quella che inizia con &, seguita da un nome, e termina con ;. Per esempio < equivale ad un riferimento per il carattere <. In tabella 2.4 sono riportate alcune entità, l utente comunque può definirne delle nuove. < < > > & & &apos; " & carattere unicode Tabella 2.4 Esempi d entità. In fine, un documento XML può avere un DTD, ossia una definizione del tipo documento, che corrisponde in sostanza alla grammatica del documento. La forma che si usa è la seguente: <!DOCTYPE nome [dichiarazionimarkup]> Quindi, la definizione consiste nel nome del tag del documento radice, seguito opzionalmente da diverse dichiarazioni di markup allo scopo di definire i tags permessi nel documento. 2.3 DTD e struttura di un Documento. Per fare in modo che un computer sia in grado di processare automaticamente un documento XML, c è bisogno di una sorta di schema del documento. In pratica occorre sapere quali tags devono apparire nel documento e in che modo devono essere innestati. La descrizione di uno schema è data da un insieme di regole, con lo stile di una grammatica, chiamate DTD ( Document Type Definition ). Le compagnie o la comunità scientifica desidera condividere informazioni, quindi creare dei DTD che descrivono la struttura dei propri documenti, giungendo quindi ad una facile interpretazione da parte degli altri. Consideriamo il seguente documento XML con un numero arbitrario di persone: <db><persona><nome> Mario </nome> <eta> 42 </eta> < > mario@abc.com </ > </persona> <persona>...</persona>... </db> 28

33 Capitolo 2 XML Un DTD per tale documento potrebbe essere: <!DOCTYPE db [ <!ELEMENT db (persona*)> <!ELEMENT persona (nome,eta, )> <!ELEMENT nome (#PCDATA)> <!ELEMENT eta (#PCDATA)> <!ELEMENT (#PCDATA)> ]> La prima linea dice che l elemento radice è <db>. Le altre linee sono dichiarazioni di markup indicando il fatto che <db> può contenere un numero arbitrario d elementi <persona>, ognuno dei quali contiene gli elementi <nome>, <eta> e < >. Questi ultimi elementi contengono solo caratteri. L espressione regolare persona* sta a significare che possono essere presenti un numero qualsiasi d elementi persona. Altre espressioni regolari sono riportati in tabella 2.5. e* zero o più occorrenze e+ una o più occorrenze e? zero o una occorrenza e e alternanza e,e concatenazione Tabella 2.5 Esempi di espressioni regolari Definizione di Grammatiche e Schemi in DTD. Abbiamo detto che il DTD è una sorta di grammatica per il documento, in particolare nell esempio sopra si nota come gli elementi <nome>, <eta> e < > debbano apparire in tale ordine in <persona>. Le grammatiche possono essere ricorsive, come nel seguente DTD che descrive un albero binario: <!ELEMENT nodo (foglia (nodo,nodo))> <!ELEMENT foglia (#PCDATA)> Un esempio di documento XML per tale grammatica è: <nodo> <nodo> <nodo><foglia> 1 </foglia></nodo> <nodo><foglia> 2 </foglia></nodo> </nodo> <nodo> <foglia> 3 </foglia> </nodo> </nodo> 29