TRADUZIONE DI SCHEMI ENTITA/RELAZIONI` SPAZIO …sdesabba/docs/TraduzioneER-XMLSchema.pdf ·...

UNIVERSITA DEGLI STUDI DI UDINE

Facolta di Scienze Matematiche Fisiche e Naturali

Corso di Laurea Triennale in Informatica

Tesi di Laurea

TRADUZIONE DI SCHEMI

ENTITA/RELAZIONISPAZIO-TEMPORALI IN SCHEMI XML

Relatore: Laureando:Prof. ANGELO MONTANARI STEFANO DE SABBATA

Correlatore:Dott. DONATELLA GUBIANI

ANNO ACCADEMICO 2004-2005

Indice

1 Introduzione 9

2 Il modello E/R 112.1 I costrutti del modello E/R . . . . . . . . . . . . . . . . . . . . . 11

2.1.1 Entita . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.1.2 Attributo . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.1.3 Relazione . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.1.4 Entita debole . . . . . . . . . . . . . . . . . . . . . . . . . 152.1.5 La relazione di specializzazione . . . . . . . . . . . . . . . 17

2.2 Il modello spazio-temporale ChronoGeoGraph . . . . . . . . . . . 192.2.1 Estensione spaziale . . . . . . . . . . . . . . . . . . . . . . 202.2.2 Estensione temporale . . . . . . . . . . . . . . . . . . . . . 33

3 XML ed XML Schema 453.1 L’eXtensible Markup Language . . . . . . . . . . . . . . . . . . . 453.2 DTD - Document Type Definition . . . . . . . . . . . . . . . . . . 483.3 XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

3.3.1 Tipi di dato complessi . . . . . . . . . . . . . . . . . . . . 553.3.2 Namespace . . . . . . . . . . . . . . . . . . . . . . . . . . 59

3.4 Linguaggi di interrogazione . . . . . . . . . . . . . . . . . . . . . . 603.4.1 XPath . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 603.4.2 XQuery . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

3.5 GML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 663.5.1 Elementi spaziali . . . . . . . . . . . . . . . . . . . . . . . 67

4 Metodologie di traduzione 734.1 Traduzione degli schemi E/R . . . . . . . . . . . . . . . . . . . . . 73

4.1.1 Il documento di schema . . . . . . . . . . . . . . . . . . . 744.1.2 Entita e attributi . . . . . . . . . . . . . . . . . . . . . . . 74

3

4 INDICE

4.1.3 Relazioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . 824.1.4 Specializzazioni . . . . . . . . . . . . . . . . . . . . . . . . 88

4.2 Traduzione di schemi ChronoGeoGraph . . . . . . . . . . . . . . . 914.2.1 Trattamento dei dati spaziali . . . . . . . . . . . . . . . . 924.2.2 Trattamento dei dati temporali . . . . . . . . . . . . . . . 97

5 Un algoritmo di traduzione 1115.1 Definizione dell’algoritmo principale . . . . . . . . . . . . . . . . . 1115.2 Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1145.3 Codifica dell’algoritmo . . . . . . . . . . . . . . . . . . . . . . . . 118

5.3.1 La classe “traduttoreCggXsd” . . . . . . . . . . . . . . . . 1185.3.2 La classe “cggList” . . . . . . . . . . . . . . . . . . . . . . 1405.3.3 La classe “cggSchema” . . . . . . . . . . . . . . . . . . . . 1425.3.4 La classe “xsDoc” . . . . . . . . . . . . . . . . . . . . . . . 152

5.4 Un caso di studio . . . . . . . . . . . . . . . . . . . . . . . . . . . 1575.4.1 Operazioni eseguite dall’algoritmo . . . . . . . . . . . . . . 1585.4.2 Documento XML Schema ottenuto . . . . . . . . . . . . . 161

6 Conclusioni 175

Elenco delle figure

2.1 Entita studente e professore . . . . . . . . . . . . . . . . . . . . . 122.2 Entita studente e professore con attributi . . . . . . . . . . . . . . 132.3 Attributi composti, multivalore, opzionali e chiave . . . . . . . . . 132.4 Esempio di attributo derivato . . . . . . . . . . . . . . . . . . . . 142.5 Relazione tra professore e dipartimento . . . . . . . . . . . . . . . 152.6 Vincoli di cardinalita e di partecipazione . . . . . . . . . . . . . . 162.7 Relazione multipla . . . . . . . . . . . . . . . . . . . . . . . . . . 172.8 Esempio di entita debole . . . . . . . . . . . . . . . . . . . . . . . 172.9 Esempio di specializzazione totale disgiunta . . . . . . . . . . . . 182.10 Tipi di specializzazione . . . . . . . . . . . . . . . . . . . . . . . . 192.11 Notazione per le specializzazioni in ChronoGeoGraph . . . . . . . 202.12 L’entita georeferenziata “regione” . . . . . . . . . . . . . . . . . . 212.13 Tipi di entita georeferenziate . . . . . . . . . . . . . . . . . . . . . 222.14 Tipi di relazioni topologiche . . . . . . . . . . . . . . . . . . . . . 232.15 Esempio di relazione topologica . . . . . . . . . . . . . . . . . . . 242.16 Esempi di specializzazione cartografica . . . . . . . . . . . . . . . 282.17 Esempio di aggregazione spaziale . . . . . . . . . . . . . . . . . . 292.18 Esempio di aggregazione . . . . . . . . . . . . . . . . . . . . . . . 302.19 Tipi di campionamento . . . . . . . . . . . . . . . . . . . . . . . . 312.20 Esempio di operatore derivato da un campo . . . . . . . . . . . . 322.21 Esempio di territorio di schema . . . . . . . . . . . . . . . . . . . 332.22 Chronon, istante ed evento . . . . . . . . . . . . . . . . . . . . . . 342.23 Diagramma a stati predefinito . . . . . . . . . . . . . . . . . . . . 372.24 Esempio di entita con lifespan . . . . . . . . . . . . . . . . . . . . 382.25 Esempio di attributi e collezione di attributi con tempo di validita 392.26 Esempio di entita e collezione di attributi con tempo di transazione 402.27 Tempo dell’evento e tempo di disponibilita delle collezioni di at-

tributi e del lifespan delle entita . . . . . . . . . . . . . . . . . . . 41

5

6 ELENCO DELLE FIGURE

2.28 Tempo dell’evento e tempo di disponibilita delle relazioni . . . . . 412.29 Tipi di relazioni di sincronizzazione . . . . . . . . . . . . . . . . . 422.30 Esempio di relazione di sincronizzazione . . . . . . . . . . . . . . 432.31 Esempio di relazione con cardinalita lifespan . . . . . . . . . . . . 43

3.1 Struttura gerarchica di un libro . . . . . . . . . . . . . . . . . . . 46

4.1 Entita “Impiegato” . . . . . . . . . . . . . . . . . . . . . . . . . . 774.2 Entita “Impiegato”, con chiave “nome” e “cognome” . . . . . . . 804.3 Entita “Impiegato” e “Dipartimento” . . . . . . . . . . . . . . . . 824.4 Relazione multipla . . . . . . . . . . . . . . . . . . . . . . . . . . 874.5 Esempio di specializzazione totale disgiunta . . . . . . . . . . . . 894.6 Esempio di specializzazione parziale con sovrapposizione . . . . . 90

5.1 Schema ChronoGeoGraph “analisiSanitaria” relativo al caso distudio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159

Elenco delle tabelle

2.1 Le relazioni topologiche in ChronoGeoGraph (parte 1) . . . . . . 252.2 Le relazioni topologiche in ChronoGeoGraph (parte 2) . . . . . . 262.3 Possibili operatori per attributi derivati legati a campi . . . . . . 32

3.1 Tipi di dato predefiniti . . . . . . . . . . . . . . . . . . . . . . . . 533.2 Restrizioni sui tipi di dato . . . . . . . . . . . . . . . . . . . . . . 543.3 Restrizioni applicabili ai tipi di dato . . . . . . . . . . . . . . . . . 55

7

8 ELENCO DELLE TABELLE

Capitolo 1

Introduzione

L’implementazione di basi di dati con linguaggi XML va imponendosi come signi-ficativo tema di ricerca e sviluppo. Tale linea di ricerca e sicuramente alimentatadal sempre maggiore utilizzo di XML nelle applicazioni collegate al Web, dall’u-tilizzo di XML come strumento di esportazione e trasferimento dei dati da partedi molti programmi di vario genere, dal supporto a questo linguaggio fornito dasistemi quali, ad esempio, Oracle e dalla disponibilita di nuovi strumenti che neaumentano la semplicita di utilizzo e la precisione nella definizione dei documen-ti.Esistono diversi lavori sull’utilizzo di XML per la definizione di basi di dati. Inparticolare, e stato evidenziato come XML possa risolvere alcuni problemi riscon-trati nelle basi di dati relazionali per quanto riguarda la gestione di informazionitemporali. E inoltre interessante rilevare la presenza di applicazioni come GMLche sfruttano l’XML per la costruzione di Sistemi Informativi Geografici (GIS).In questo lavoro viene proposta una metodologia di traduzione di schemi con-cettuali spazio-temporali, ovvero di schemi che comprendano sia la definizionedi dati geografici (come avviene nei GIS) sia il trattamento di aspetti tempora-li (inclusi quelli relativi all’evoluzione temporale delle informazioni geografiche)in XML. Il punto di partenza della presente trattazione sono gli schemi En-tita/Relazioni [4], arricchiti con informazioni spazio-temporali. Quale modelloconcettuale spazio-temporale di riferimento viene adottato il modello Chrono-GeoGraph [3]. L’applicazione della metodologia proposta porta alla costruzionedi schemi per la definizione di documenti in formato XML che uniscono concettie tecniche tipiche delle basi di dati relazionali, come il riferimento a chiave, astrutture piu simili a quelle usate nelle basi di dati gerarchiche.La tesi e organizzata nel seguente modo. Nel Capitolo 2 vengono introdotti i

9

10 CAPITOLO 1. INTRODUZIONE

due modelli che costituiscono il punto di partenza del presente lavoro: il model-lo Entita/Relazioni ed una sua estensione spazio-temporale, ovvero il modelloChronoGeoGraph. Di entrambi vengono descritti i costrutti fondamentali ed illoro utilizzo. Nel Capitolo 3 viene introdotto il linguaggio XML, che e statoscelto, per le sue peculiari caratteristiche, quale strumento per la definizione dibasi di dati spazio-temporali della traduzione proposta. In particolare, vengonointrodotti due linguaggi per la definizione di grammatiche XML (DTD ed XMLSchema) e due linguaggi di interrogazione per documenti XML (XPath ed XQue-ry). Nel Capitolo 4 viene illustrata la metodologia proposta per la traduzione deicostrutti dei modelli Entita/Relazioni e ChronoGeoGraph. Partendo dalla codi-fica dei semplici costrutti del modello Entita/Relazioni si giunge alla trattazionedegli aspetti spaziali e temporali del modello ChronoGeoGraph, descrivendo inmodo dettagliato le diverse soluzioni analizzate discutendo le limitazioni dellatraduzione proposta. Nel Capitolo 5 si presenta in dettaglio l’algoritmo di tradu-zione in pseudo-codice degli schemi Entita/Relazioni spazio-temporali in schemiXML. Infine, viene riportato un esempio di applicazione dell’algoritmo ad unoschema ChronoGeoGraph relativo ad un sistema di analisi dei dati nel contestosanitario.Nelle conclusioni vengono riassunti i principali risultati raggiunti e vengono de-lineati i possibili sviluppi futuri del lavoro.

Capitolo 2

Il modello E/R

In questo capitolo viene introdotto il modello concettuale Entita/Relazioni, checostituisce il punto di partenza del lavoro di tesi.Un modello concettuale e un’insieme di costrutti che consentono di definire, alivello concettuale e quindi in maniera astratta, la realta che si vuole codificareall’interno di una base di dati. L’utilizzo di questo modello permette di lasciaread una fase successiva della progettazione il compito di decidere come codificarei dati in strutture adatte ad un calcolatore. Un modello concettuale si occupasemplicemente di descrivere cosa interessa codificare, a prescindere dalle moda-lita di organizzazione e memorizzazione.Tale modello permette di descrivere in modo relativamente semplice il dominiodi interesse mediante diagrammi, i quali vengono creati combinando le rappre-sentazioni grafiche dei diversi costrutti.Nella prima sezione di questo capitolo descriveremo i costrutti fondamentali delmodello E/R quali ,le entita, gli attributi e le relazioni. Introdurremo inoltre uncostrutto aggiuntivo, disponibile nel modello comunemente chiamato EER (En-hanced E/R), quale la specializzazione. Una trattazione piu dettagliata di questiargomenti si puo trovare in [1].La seconda sezione sara, invece, dedicata ad una recente estensione spazio-temporale del modello E/R , denominata ChronoGeoGraph.

2.1 I costrutti del modello E/R

Il modello E/R e stato il primo modello concettuale per la definizione di basi didati proposto da Chen in [4] ed e diventato un punto di riferimento universal-

11

12 CAPITOLO 2. IL MODELLO E/R

mente riconosciuto per la sua semplicita di utilizzo. Tale modello e composto datre costrutti fondamentali:

• entita;

• attributo;

• relazione.

Questi costrutti consentono di modellare, tramite semplici diagrammi, la realtache si intende gestire con la base di dati.Nel resto della sezione descriveremo brevemente i costrutti dell’E/R, la lorosemantica ed il loro utilizzo.

2.1.1 Entita

L’entita e uno dei due costrutti da cui prende il nome il modello. Le entitarappresentano classi di oggetti di interesse per l’applicazione. Come il nomestesso suggerisce, ogni “entita del mondo reale” che vogliamo inserire nel modellova codificata con questo costrutto. Un semplice esempio e quello di una basedi dati per universita in cui si voglia memorizzare i dati riguardanti studentie professori. Gli studenti (ma non i professori) verranno identificata dalla loromatricola; i professori (ma non gli studenti) dal codice del loro ufficio (assumendoche ogni professore disponga di un proprio ufficio).La notazione grafica per le entita e costituita da dei rettangoli al cui interno sitrova il nome dell’entita stessa. In Figura 2.1 sono rappresentate le entita delprecedente esempio.

Figura 2.1: Entita studente e professore

2.1.2 Attributo

Come accennato, per ognuna delle istanze delle entita si vuole tener traccia dialcuni dati. Ad esempio, nome, cognome, matricola e corso di laurea frequenta-to nel caso degli studenti e nome, cognome, numero dell’ufficio e dipartimento

2.1. I COSTRUTTI DEL MODELLO E/R 13

Figura 2.2: Entita studente e professore con attributi

Figura 2.3: Attributi composti, multivalore, opzionali e chiave

per i professori. Il costrutto che permette di codificare queste informazioni el’attributo.Per ciascuna delle proprieta sopra introdotte, viene definito un attributo, rappre-sentato da una ellisse, contenente il nome della proprieta, collegato alla relativaentita (Figura 2.2). Oltre agli attributi semplici ed a singolo valore, come quellidi Figura 2.2, il modello E/R mette a disposizione vari tipi di attributo, condiverse caratteristiche:

• Attributi composti. Gli attributi composti sono attributi strutturati, chepossono essere decomposti in un insieme di altri attributi. Supponendo, adesempio, di voler conoscere l’indirizzo di ogni studente, possiamo immagi-nare di utilizzare un attributo composto indirizzo, costituito da citta, viae numero civico (Figura 2.3).


• Attributi multivalore. Gli attributi multivalore sono attributi che possonoassumere uno o piu valori contemporaneamente. Nello schema di Figura2.3, l’attributo multivalore “telefono” consente di memorizzare, per ognistudente, uno o piu numeri di telefono.

• Attributi opzionali. Gli attributi opzionali sono attributi il cui valore peruna specifica istanza di un’entita puo non essere specificato. Nello schemadi Figura 2.3, l’utilizzo di un attributo “data di nascita” di tipo opzionale,indicato da un valore di cardinalita 0:1 (minimo 0, massimo 1) che etichettal’arco che collega l’attributo all’entita, permette di specificare o meno ladata di nascita di uno studente.

• Attributi derivati. Gli attributi derivati sono degli attributi i cui valorivengono calcolati a partire dai valori di altri attributi. Ad esempio, il valoredell’attributo “eta” di un’entita persona puo essere derivato a partire dalvalore dell’attributo “data di nascita”. Graficamente, gli attributi derivativengono rappresentati come in Figura 2.4, con un ellisse tratteggiata e laregola di derivazione accanto.

La chiave di un’entita e definita come un insieme di attributi che identificanounivocamente ogni istanza dell’entita. Nel caso dell’entita studente di Figura2.3 l’attributo matricola sottolineato e l’attributo chiave, ovvero un valore uni-voco che identifica ciascuna delle istanze dell’entita (ogni studente e identificatounivocamente dal suo numero di matricola).

Figura 2.4: Esempio di attributo derivato


Figura 2.5: Relazione tra professore e dipartimento

2.1.3 Relazione

Le relazioni sono il secondo tassello fondamentale del modello E/R. Rappresen-tano legami tra due o piu entita, rilevanti dal punto di vista dell’applicazione.Immaginando di aggiungere un’entita dipartimento, con attributi nome e sede,l’informazione, espressa nello schema precedente dall’attributo “dipartimento”dell’entita “professore” (vedi Figura ??), puo essere espressa da una relazione“afferisce”, come mostrato in Figura 2.5.

Tale relazione definisce un legame tra le istanze delle entita professore e di-partimento. Ad ogni relazione sono associati dei vincoli di cardinalita e di par-tecipazione che l’istanza della relazione deve rispettare. Nell’esempio di Figura2.5 i vincoli impongono che ogni professore afferisca a ad un unico dipartimento(minimo 1, massimo 1) e che ogni dipartimento abbia uno o piu professori che viafferiscono (minimo 1, massimo N). In Figura 2.6 vengono riportati i diversi casidi vincoli di cardinalita e di partecipazione.

E possibile associare attributi anche alle relazioni, nello stesso modo in cuivengono associati alle entita.Inoltre, e possibile definire relazioni che coinvolgono piu di due entita, comemostrato in Figura 2.7. Questo diagramma modella un esempio di relazionenella quale un fornitore puo fornire un certo numero di componenti ad un certonumero di progetti.

2.1.4 Entita debole

Un entita si definisce debole se non e possibile effettuare un’identificazione uni-voca di ogni sua istanza basandosi unicamente sul valore di uno o piu attributi.Nello schema mostrato in Figura 2.8 sono presenti le entita “albergo”, con at-


Figura 2.6: Vincoli di cardinalita e di partecipazione


Figura 2.7: Relazione multipla

Figura 2.8: Esempio di entita debole

tributo chiave “nome”, e “camera”, con attributo “numero”. In questo caso,dato che due camere, di due diversi alberghi, possono avere lo stesso numero, peridentificare univocamente una camera serve, oltre al numero, anche il nome del-l’albergo. Tale identificazione e resa possibile della relazione “in”, che associa adogni camera uno ed un solo albergo. In questo caso, la relazione “in” si definisceidentificante.

2.1.5 La relazione di specializzazione

Negli anni successivi all’introduzione del modello E/R sono state proposte diverseestensioni, una delle quali ha introdotto, con particolare successo, il costrutto dispecializzazione.

Le specializzazioni

La relazione si specializzazione permette di definire, a partire da una entita “pa-dre” (o superclasse), delle entita “figlie” (o sottoclassi) che ereditano dalla prima


tutti gli attributi e le relazioni. Alle entita “figlie” si possono poi aggiungeredegli attributi e delle relazioni specifiche.Ad esempio, in Figura 2.9 e una entita persona, la cui chiave e il codice fiscale,con due specializzazioni (bambino ed adulto) differenziate dal fatto che l’entitaadulto possiede l’attributo tessera elettorale, che ogni adulto ha ma che un bam-bino non possiede. In questo caso, la specializzazione risulta totale e disgiunta:

Figura 2.9: Esempio di specializzazione totale disgiunta

tutte le persone sono o bambini (sotto i 18 anni) o adulti (sopra i 18 anni); allostesso modo, ogni istanza dell’entita persona deve essere istanza di una ed unasola delle due sottoclassi. Graficamente, come mostrato in Figura 2.9, la disgiun-zione e rappresentata inserendo una “d” all’interno del cerchio ed il vincolo dispecializzazione totale riempiendo lo spazio tra le due linee che collegano l’entitapadre a tale cerchio.In modo piu dettagliato, possiamo suddividere le specializzazioni sulla base di

quattro diverse tipologie:

1. specializzazione totale disgiunta, quando tutte le istanze dell’entita padredevono essere istanze di una ed una sola entita figlia (come nell’esempioprecedente);

2. specializzazione totale con sovrapposizione, quando tutte le istanze dell’en-tita padre devono essere istanza di almeno una delle entita figlie (posso-no esistere delle istanze appartenenti a piu entita figlie, ad esempio unapersona puo essere sia lavoratore sia studente);

2.2. IL MODELLO SPAZIO-TEMPORALE CHRONOGEOGRAPH 19

Figura 2.10: Tipi di specializzazione

3. specializzazione parziale disgiunta, quando ogni istanza dell’entita padrepuo essere istanza di al piu una entita figlia (puo anche non apparteneread alcune delle entita figlie);

4. specializzazione parziale con sovrapposizione, quando ogni istanza dell’en-tita padre puo essere istanza di una, piu di una o nessuna entita figlia.

2.2 Il modello spazio-temporale ChronoGeoGra-

ph

Per la costruzione di schemi concettuali per basi di dati spazio-temporali, adot-teremo il modello ChronoGeoGraph. Tale modello estende il modello GeoGraph,un modello E/R esteso con primitive per la descrizione di informazioni spazialiproposto in [12], con un insieme di costrutti per la modellazione di informazionitemporali. Una descrizione dettagliata di ChronoGeoGraph e fornita in [3].In tale modello alcune delle notazioni grafiche precedentemente descritte assu-mono alcune variazioni, in particolare:


Figura 2.11: Notazione per le specializzazioni in ChronoGeoGraph

• la nuova notazione prevede la segnalazione della cardinalita dell’attributosulla linea di collegamento tra l’entita e quest’ultimo, anche per gli attributimultivalore ([1:N] o [0:N] se l’attributo e anche opzionale), al posto dellarappresentazione classica;

• cambia la rappresentazione grafica delle specializzazioni come riportato inFigura 2.11.

Di seguito vengono introdotti i costrutti proposti dall’estensione ed il loro utilizzo.

2.2.1 Estensione spaziale

Questa estensione riprende in gran parte le notazioni e le strutture descritte in[12] e in [13] ma il modello di riferimento continua ad essere quello introdotto in[3].

Entita georeferenziate

Definizione 2.1 Le entita georeferenziate sono particolari entita aventi un at-tributo geografico, ovvero nelle quali uno degli attributi descrive la geometria chesi associa all’entita stessa come descrizione geografica di quest’ultima.

Cio permette di modellare entita georeferenziate (o spaziali), ossia entita cherappresentano oggetti di cui interessa memorizzare la locazione geografica; tali


entita sono associate ad una precisa forma geometrica [12].

Nel modello ChronoGeoGraph le entita georeferenziate sono rappresentate,

Figura 2.12: L’entita georeferenziata “regione”

come mostrato in Figura 2.12, introducendo, nel rettangolo dell’entita, l’iconadella forma geometrica di riferimento. L’esempio considera il caso di un’entitaregione con quattro attributi: nome, che ne e chiave, data di costituzione, capo-luogo, e geometria, con dominio multipoligono, indicata dall’icona posta sopra ilnome dell’entita.In Figura 2.13 sono riportati i diversi tipi di entita georeferenziate che possonoessere utilizzate nei diagrammi ChronoGeoGraph.

Il fatto di vedere la geometria come un tipo particolare di attributo ha dueimportanti conseguenze:

• la geometria puo essere la chiave di una entita, per rappresentare tale casoracchiuderemo l’icona della geometria all’interno di un quadrato nero;

• vi possono essere entita puramente geografiche, aventi quale unico attributola loro geometria.

Relazioni topologiche

Definizione 2.2 Una relazione topologica e una relazione spaziale caratterizzatadalla proprieta di essere invariante rispetto a trasformazioni topologiche quali latraslazione, la rotazione e la variazione del rapporto di scala [6].


Figura 2.13: Tipi di entita georeferenziate

Date due entita georeferenziate A e B, l’insieme completo e minimale dellepossibili relazioni topologiche tra A e B e il seguente [5]:

1. A e B sono disgiunti;

2. A tocca B;

3. A e uguale a B;

4. A contiene B;

5. A e contenuto in B;

6. A copre B;

7. A e coperto da B;

8. A e B si sovrappongono con i bordi disgiunti;

9. A e B si sovrappongono con intersezione dei bordi.

Come si puo notare, queste nove relazioni possono essere ridotte a sette, datoche A e contenuto in B si puo riformulare come B contiene A e A e coperto da Bsi puo riformulare come B copre A. Dunque, i sette tipi di relazioni topologichetra due entita georeferenziate, le cui icone sono mostrate in Figura 2.14, sono leseguenti:

1. disgiunzione;

2. adiacenza;


3. uguaglianza;

4. inclusione;

5. copertura;

6. sovrapposizione con bordi disgiunti;

7. sovrapposizione con intersezione dei bordi.

Figura 2.14: Tipi di relazioni topologiche

Vediamo un esempio di definizione di una relazione topologica tra due entita geo-referenziate. Immaginiamo di voler modellare gli stati e le loro citta situate. Unapossibile scelta e modellare gli stati come entita georeferenziate di tipo MULTI-POLYGON e le citta come entita di tipo POINT. Tra le due entita intercorrela relazione topologica di inclusione. Ogni stato puo contenere nessuna o moltecitta, ogni citta e situata in esattamente uno stato. Il diagramma che modellaquesto semplice esempio e mostrato in Figura 2.15.In [10], si evidenzia come non tutte le relazioni topologiche che possono inter-

correre tra le geometrie di due entita abbiano un significato; solo un sottoinsiemedi esse puo considerarsi semanticamente corretto. Tale sottoinsieme dipende daltipo di entita geometriche coinvolte nella relazione topologica. L’esempio di se-guito riportato consentira di mettre meglio a fuoco la questione.Si considerino due oggetti geometrici di tipo poligono e punto, rispettivamente esi consideri la relazione topologica contiene applicata alla coppia ordinata (poli-gono, punto). Il significato della relazione topologica e: ogni poligono contieneun certo numero di punti.


Figura 2.15: Esempio di relazione topologica

Si consideri la stessa relazione applicata alla coppia ordinata (punto, poligono).In questo caso si ottiene la semantica seguente: ogni punto contiene un certonumero di poligoni.Risulta chiaro che la prima relazione spaziale ha un significato. Ha, infatti, sensochiedersi se un punto e o non e contenuto in un poligono. Viceversa, nel secon-do caso, la stessa relazione topologica e priva di ogni significato. Non ha sensochiedersi se un punto contiene un poligono perche e geometricamente impossi-bile che un punto possa contenere un poligono. Una tale possibilita deve esserestrutturalmente esclusa dal modello concettuale.Inoltre, alcune relazioni topologiche risultano essere “ridondanti”. Ad esempio,le relazioni spaziali di adiacenza e copertura sono ridondanti quando vengonoapplicate alla coppia ordinata (poligono, punto). Infatti, entrambe le relazionirappresentano lo stesso legame topologico: il punto si trova sul bordo del poligo-no. La scelta di ChronoGeoGraph di non eliminare le relazioni ridondanti facilital’utente che in questo modo non deve ricordare quali particolari relazioni sonopermesse tra due entita e quali no.Le entita georeferenziate che possono imporre delle restrizioni alle relazioni to-pologiche che le coinvolgono sono: point, multipoint, line, multiline, polygon emultipolygon. I tipi geometrici collection e other geometry non impongono alcu-na condizione sulle relazioni. Cio e dovuto al fatto che non si conosce a priori latipologia delle istanze di tali entita.

Le Tabelle 2.1 e 2.2 mostra le relazioni topologiche permesse, suddivise in basealla tipologia delle coppie ordinata di entita georeferenziate. Per una descrizionedettagliata di tutte le possibili configurazioni si rimanda a [5].


Tabella 2.1: Le relazioni topologiche in ChronoGeoGraph (parte 1)

Entita geometriche Relazioni topologiche possibili1a 2a

POINT disgiunzione, uguaglianzaLINE disgiunzione, adiacenza

POINT POLYGON disgiunzione, adiacenzaMULTIPOINT disgiunzione, adiacenza, uguaglianzaMULTILINE disgiunzione, adiacenza

MULTIPOLYGON disgiunzione, adiacenzaPOINT disgiunzione, inclusioneLINE tutte

LINE POLYGON disgiunzione, adiacenza, sovrapposizionecon bordi disgiunti, sovrapposizione conintersezione dei bordi

MULTIPOINT disgiunzione, adiacenza, inclusione, coper-tura, sovrapposizione con bordi disgiunti,sovrapposizione con intersezione dei bordi

MULTILINE tutteMULTIPOLYGON disgiunzione, adiacenza, sovrapposizione

con bordi disgiunti, sovrapposizione conintersezione dei bordi

POINT disgiunzione, adiacenza, inclusioneLINE disgiunzione, adiacenza, inclusione, coper-

tura, sovrapposizione con bordi disgiunti,sovrapposizione con intersezione dei bordi

POLYGON POLYGON tutteMULTIPOINT disgiunzione, adiacenza, inclusione, coper-


MULTILINE disgiunzione, adiacenza, inclusione, coper-tura, sovrapposizione con bordi disgiunti,sovrapposizione con intersezione dei bordi

MULTIPOLYGON tutte


Tabella 2.2: Le relazioni topologiche in ChronoGeoGraph (parte 2)

Entita geometriche Relazioni topologiche possibili1a 2a

POINT disgiunzione, adiacenza, uguaglianza, co-pertura

LINE disgiunzione, adiacenzaMULTIPOINT POLYGON disgiunzione, adiacenza, sovrapposizione


MULTIPOINT disgiunzione, adiacenza, uguaglianza, in-clusione, copertura, sovrapposizione conintersezione dei bordi

MULTILINE disgiunzione, adiacenzaMULTIPOLYGON disgiunzione, adiacenza, sovrapposizione


POINT disgiunzione, inclusioneLINE tutte

MULTILINE POLYGON disgiunzione, adiacenza, sovrapposizionecon bordi disgiunti, sovrapposizione conintersezione dei bordi

MULTIPOINT disgiunzione, adiacenza, inclusioneMULTILINE tutte

MULTIPOLYGON disgiunzione, adiacenza, sovrapposizionecon bordi disgiunti, sovrapposizione conintersezione dei bordi

POINT disgiunzione, adiacenza, inclusioneLINE disgiunzione, adiacenza, inclusione, coper-


MULTIPOLYGON POLYGON tutteMULTIPOINT disgiunzione, adiacenza, inclusione, coper-


MULTILINE disgiunzione, adiacenza, inclusione, coper-tura, sovrapposizione con bordi disgiunti,sovrapposizione con intersezione dei bordi

MULTIPOLYGON tutte


Specializzazione cartografica

La specializzazione (o generalizzazione) cartografica e stata introdotta in [12] permodellare variazioni di forma o di scala di un’entita georeferenziata.

Definizione 2.3 La generalizzazione cartografica e utilizzata per rappresentareun’entita (superclasse) che puo essere definita secondo forme diverse rispetto allastessa scala o a scale diverse.

Le sottoclassi possiedono forme geometriche che differiscono da quelle della su-perclasse, ma ereditano gli attributi alfanumerici della superclasse.La primitiva di generalizzazione cartografica e un caso particolare di generaliz-zazione che consente di catturare rappresentazioni multiple di un oggetto e dicaratterizzare le relazioni topologiche associate alle varie rappresentazioni. Laforma con la quale e rappresentata un’entita influenza, infatti, i tipi di relazionetopologica cui puo partecipare.La notazione adottata per la generalizzazione cartografica si distingue da quelladella generalizzazione generica per la presenza di un quadrato, e non di un trian-golo, quale collegamento tra una superclasse e le sue sottoclassi.

La generalizzazione cartografica puo essere di due tipi: basata su variazioni diforma o basata su variazioni di scala.

• La variazione di forma e utilizzata per rappresentare diverse possibili formegeometriche di una stessa entita alla stessa scala. La descrizione geometri-ca della superclasse si deduce a partire dalle sue sottoclassi. Un esempio edato dall’entita cimitero, che puo essere rappresentata da un poligono, chedefinisce l’area occupata dal cimitero, e dal simbolo cartografico delle croci(vedi Figura 2.16).

• La specializzazione basata sulla variazione di scala e utilizzata per rap-presentare diverse forme geometriche di una stessa entita rispetto a scalediverse. Ad esempio, una citta puo essere rappresentata da un poligono inuna scala piu fine e da un punto in una scala piu grossolana.

Entrambi i tipi di specializzazioni cartografiche sono sempre totali e con so-vrapposizione: totali perche ogni istanza della superclasse deve essere istanza di


almeno una sottoclasse per essere georeferenziata, con sovrapposizione perche,in entrambi i tipi di specializzazione cartografica, ogni istanza della superclassepuo avere forme alternative di rappresentazione, che potranno essere visualizzatesingolarmente, nel caso della specializzazione basata sulla variazione di scala, ocontemporaneamente, nel caso della specializzazione basata sulla variazione diforma.

Figura 2.16: Esempi di specializzazione cartografica

Aggregazione spaziale

In [12] si introduce anche la nozione di aggregazione spaziale.

Definizione 2.4 Un aggregazione spaziale permettono associa due o piu (istanzedi) entita georeferenziate - parti - ad una (istanza di) entita georeferenziata -intero - in cui la geometria di ogni parte e interamente contenuta nella geometriadell’intero. Inoltre, non e permessa sovrapposizione fra le parti, e la geometriadell’intero e pienamente coperta dalla geometria delle parti. (L’insieme delleparti costituisce una parte dell’intero.)

Un esempio di aggregazione spaziale e riportato in Figura 2.17. Un’entita georefe-renziata “regione” di tipo “poligono” puo essere modellata come un’aggregazionespaziale di istanze, sempre di tipo “poligono”, dell’entita georeferenziata “pro-vincia”. Cio significa che ogni istanza di “regione” e descritta da una geometria,la quale puo essere partizionata nelle geometrie delle corrispondenti istanze del-l’entita “provincia”.


Poiche risulta geometricamente impossibile concepire che, ad esempio, una geo-

Figura 2.17: Esempio di aggregazione spaziale

metria di tipo punto sia composta da un insieme di poligoni, anche a questo tipodi aggregazioni sono stati imposti dei vincoli.

Le regole per stabilire la validita di una aggregazione spaziale tra due entitageoreferenziate sono specificate dai punti seguenti:

• un’entita di tipo Point non puo mai rappresentare un’aggregazione di altreentita georeferenziate, poiche ha dimensione zero;

• un’entita di tipo Multipoint puo essere definita come l’unione geometricadi entita di tipo Point o Multipoint;

• un’istanza dell’entita Line puo essere formata da altre istanze dello stessotipo geometrico, di cui risulta essere l’aggregazione;

• un’entita Multiline puo essere definita come aggregazione spaziale di entitadi tipo Multiline o Line;

• un’istanza dell’entita Polygon puo essere suddivisa solo in istanze dellostesso tipo;

• un’entita Multipolygon puo essere definita come aggregazione spaziale dientita di tipo Polygon e Multipolygon.

Poiche le entita di tipo Collection e Other Geometry comprendono istanze di cuinon e possibile conoscere a priori la forma e la dimensione geometrica, le aggre-gazioni spaziali che coinvolgono tali entita sono considerate sempre valide [12].In [13], vengono aggiunte al modello altre tipologie di aggregazione: l’aggrega-zione fra entita non georeferenziate (aggregazione non spaziale) e l’aggregazionesemantica.


• L’aggregazione non spaziale rappresenta una relazione parte/intero fra dueo piu entita la quale specifica che un’entita intero e composta da una o piuentita parte (anche di natura eterogenea). E possibile indicare dei vincolidi cardinalita sulla partecipazione delle parti all’aggregazione.E possibile, ad esempio, specificare che una squadra di baseball deve es-sere composta da almeno 9 e al piu 15 giocatori, da esattamente un al-lenatore ed, eventualmente da un assistente, come mostrato in Figura2.18. Inoltre, in ChronoGeoGraph l’aggregazione puo svolgere il ruolo di

Figura 2.18: Esempio di aggregazione

relazione identificante.

• L’aggregazione semantica e un particolare tipo di aggregazione spazialemolto flessibile che non deve necessariamente rispettare i vincoli prece-dentemente descritti. Essa consente di codificare aggregazioni particolari,quali aggregazioni in la somma delle geografia delle istanze delle entitaparte e solamente inclusa nella geometria dell’istanza intero. Tale tipo diaggregazione e trattato estesamente in [8].

Campi

Utilizzare gli oggetti geografici quale unico strumento per modellare le informa-zioni spaziali e insufficiente. Esistono, infatti, proprieta dello spazio che sono


indipendenti da un qualsivoglia oggetto esistente o definibile dall’uomo. Asso-ciare un oggetto spaziale a concetti quali la temperatura o l’altitudine e unaforzatura [3]. Per modellare tali informazioni e stata proposta la cosiddetta vi-sione a campi.La visione a campi non vede lo spazio come una superficie occupata da varioggetti, ma come superficie continua.

Definizione 2.5 La visione a campi rappresenta lo spazio come una superficiecontinua sulla quale le entita georeferenziate variano in modo continuo.

Per modellare un campo specifica il suo territorio di schema (vedi 2.6) o l’entitageoreferenziata cui e collegato ed il tipo di campionamento effettuato (campio-namento irregolare di punti, campionamento regolare di punti, isolinee, poligoni,griglia regolare di celle, o rete triangolare irregolare). Graficamente, l’arco utiliz-zato per indicare l’appartenenza di un campo ad un’entita georeferenziata o adun territorio di schema termina con un cerchietto nero sul lato del territorio dischema/entita (vedi Figura 2.21).I campi possono essere utilizzati per definire delle quantita derivate per le entita

Figura 2.19: Tipi di campionamento

georeferenziate. Ad esempio, e possibile tenere traccia la temperatura media suivari punti della superficie definita della geometria delle istanze di una partico-lare entita. Tali quantita sono assimilabili ad attributi derivati e, di fatto, sonodeterminati da una funzione del campo, il cui dominio e delimitato dalla geome-tria dell’entita. Il valore della funzione viene calcolato solo sui dati campionati


Figura 2.20: Esempio di operatore derivato da un campo

all’interno della geometria dell’entita.La notazione prevede che l’operatore sia rappresentato come un attributo deri-vato di un’entita georeferenziata, seguito da una linea verticale e dalla funzioneda calcolare sul campo. Gli operatori disponibili per il calcolo di tali attributiderivati dipendono dal dominio del campo e sono riportati, suddivisi per domi-nio, in Tabella 2.3.In Figura 2.20 e fornito un esempio di tale struttura.

Tabella 2.3: Possibili operatori per attributi derivati legati a campi

Operatore Dom. numerico Dom. data e ora Dom. testuale Dom. booleano> Massimo Piu recente< Minimo Meno recenteAVG Media↑ Piu frequente↓ Meno frequenteΣ SommatoriaΠ Produttoria∧ Congiunzione∨ Disgiunzione⊕ Disg. Esclusiva

Territorio di schema

Definizione 2.6 Il territorio di schema rappresenta il dominio spaziale della ba-se di dati e la sua geometria include quella di tutte le entita georeferenziate e di


Figura 2.21: Esempio di territorio di schema

tutte le aree di campionamento dei campi definiti nello schema.

Un territorio di schema e, dunque, un’entita georeferenziata particolare, privadi chiave, la cui unica istanza corrente ammissibile definisce il dominio spazialedello schema nel quale una o piu entita georeferenziate e uno o piu campi vengonodefiniti. Tutte le entita georeferenziate e tutti i campi devono appartenere alterritorio di schema. Questa definizione modella implicitamente una relazionetopologica di inclusione fra entita georeferenziate e il territorio di schema. Inoltre,indica che il campionamento di un dato campo e limitato al territorio di schemacui il campo appartiene.Dal punto di vista grafico, come mostrato in Figura 2.21, il territorio di schema erappresentato tramite un rettangolo con un icona sopra il nome, il quale e semprepreceduto dalla sigla “TS” tra parentesi quadre.

2.2.2 Estensione temporale

Prima di descrivere i costrutti messi a disposizione da ChronoGeoGraph per lamodellazione concettuale di basi di dati temporali e spazio-temporali, introdu-


ciamo alcuni concetti fondamentali.

Definizione 2.7 Il “chronon” e il piu breve intervallo di tempo supportato dalsistema [18].

Sulla base della nozione di “chronon”, il dominio temporale di una base didati (temporale) puo essere visto come una serie di punti equidistanti dispostisu un asse (tempo “discreto”). Un istante e un singolo punto od un singolo“chronon” [18]. Un evento e associato ad un istante t se e accaduto durante il“chronon” che rappresenta t [18].

Figura 2.22: Chronon, istante ed evento

Definizione 2.8 Un intervallo finito e il tempo che intercorre tra due even-ti e puo essere descritto come una successione finita di “chronon”, o istanti.Solitamente l’intervallo e rappresentato dai suoi due istanti estremi. [18]

Definizione 2.9 Il tempo di validita (VT, o valid time) di un fatto e l’intervallodi tempo durante il quale il fatto e vero nella realta modellata [9].

Definizione 2.10 Il tempo di esistenza (existence time) di un oggetto e l’inter-vallo di tempo durante il quale l’oggetto esiste. Equivalentemente, il tempo diesistenza di un oggetto puo essere definito come l’intervallo di validita del fatto“l’oggetto esiste”. Il tempo di esistenza e stato definito anche come valid-timelifespan [19].

Il significato del tempo di esistenza e simile a quello del tempo di vali-ditassociato agli attributi di un’entita, e semanticamente serve a mantenere infor-mazioni sull’esistenza di un entita all’interno dell’universo modellato (esiste/non


esiste). Il tempo di esistenza, da solo, non cattura tuttavia alcuni aspetti impor-tanti del ciclo di esistenza di un oggetto. E possibile, ad esempio, che l’utentedella base di dati voglia modellare tutti i possibili stati in cui si puo trovare unoggetto durante l’arco di tempo preso in considerazione[3].

In modo piu generale, il lifespan di un’entita puo essere definito come una fun-zione dal dominio temporale ad un insieme di stati. Tali stati descrivono le variesituazioni in cui l’entita puo trovarsi nel corso della sua esistenza. L’entita puopassare da uno stato all’altro secondo regole definite.

Definizione 2.11 Il tempo dell’evento (ET, o event time) di un fatto e il tempodi occorrenza di un evento del mondo reale che inizia o termina l’intervallo divalidita del fatto.

Definizione 2.12 Il tempo di transazione (TT, o transaction time) di un fattoe l’intervallo di tempo durante il quale il fatto e corrente nella base di dati e puoessere recuperato [9].

Definizione 2.13 Il tempo di disponibilita (AT, o availability time) di un fattoe l’intervallo di tempo durante il quale il fatto e conosciuto e ritenuto correttodal sistema informativo cui la base di dati appartiene [7].

ChronoGeoGraph fornisce ai diversi costrutti due tipi di supporto temporale,che variano al variare del tipo di costrutto (entita, attributo, relazione, aggrega-zione o campo).Il supporto fornito alle entita comprende:

• lifespan;

• tempo di transazione;

• tempo dell’evento;

• tempo di disponibilita.

Il supporto relativo ad attributi, relazioni, aggregazioni e campi comprende:

• tempo di validita;

• tempo di transazione;


• tempo dell’evento;

• tempo di disponibilita;

In modo piu formale, le dimensioni temporali associate ai vari costrutti possonoessere specificate nel seguente modo. Nel caso delle entita si ha:

< entitytime >::= ε|< lifespan > |< lifespan > / < transactiontime > |< lifespan > / < eventtime > |< lifespan > / < transactiontime > |< lifespan > / < transactiontime > / < eventtime > |< lifespan > / < transactiontime > / < availabilitytime > |< lifespan > / < transactiontime > / < eventtime > / < availabilitytime > |< transactiontime > / < availabilitytime >

Nel caso degli attributi, delle relazioni, delle aggregazioni ed dei campi si ha:

< facttime >::= ε|< validtime > |< validtime > / < transactiontime > |< validtime > / < eventtime > |< validtime > / < transactiontime > |< validtime > / < transactiontime > / < eventtime > |< validtime > / < transactiontime > / < availabilitytime > |< validtime > / < transactiontime > / < eventtime > / < availabilitytime > |< transactiontime > / < availabilitytime >

Lifespan

Il lifespan indica lo stato in cui si trova l’oggetto del mondo reale che si vuo-le descrivere. Per tale ragione la sua definizione comprende la specifica di undiagramma di stati. In mancanza di una definizione esplicita viene associatoall’oggetto un diagramma predefinito (mostrato in Figura 2.23). La notazioneutilizzata e la seguente: < lifespan >::= LS|LS<diagram>

In Figura 2.24 e riportato un esempio di entita con lifespan.


Figura 2.23: Diagramma a stati predefinito

Tempo di validita

Il tempo di validita puo essere associato a relazioni, aggregazioni, campi, attributie collezioni di attributi. La notazione utilizzata e la seguente: < validtime >::=V . L’unica restrizione imposta e che gli attributi facenti parte della chiave nonpossono avere un tempo di validita poiche devono descrivere univocamente l’iden-tita dell’istanza e il loro valore non puo variare nel tempo[3] (o, equivalentemente,hanno un intervallo di validita che copre l’intero lifespan dell’entita).

Tempo di transazione

Il tempo di transazione puo essere associato ad entita, relazioni, aggregazioni,campi, attributi e collezioni di attributi. Nel caso delle entita, come mostratoin Figura 2.26, si fa riferimento al tempo di transazione del lifespan dell’entitastessa.La notazione utilizzata e la seguente: < transactiontime >::= T .

Come nel caso del tempo di validita, anche il tempo di transazione non puoessere associato ad attributi chiave o ad altri attributi invarianti nel tempo [3].


Figura 2.24: Esempio di entita con lifespan

Tempo dell’evento e tempo di disponibilita

il tempo dell’evento e il tempo di disponibilita possono essere associate ad entita,collezioni di attributi, relazioni, aggregazioni e campi. La notazione utilizzata ela seguente: < eventtime >::= E < avaieabilitytime >::= A.Mentre un’entita ammette il tempo dell’evento solo se e temporale (cioe dotatadi lifespan). Una collezione, una relazione, un campo, e un territorio di schemapossono ammettere il tempo dell’evento solo se hanno associato un tempo divalidita. Un oggetto puo ammettere il tempo di disponibilita solo se ha associatoun tempo di transazione. [3]

Eventi

Il costrutto Evento, introdotto in [2], e collegato ad un oggetto dello schematramite un arco etichettato in modo particolare. Gli eventi assumono diversisignificati a seconda del tipo di oggetto cui sono collegati e del tipo di etichettapresente sull’arco.Qualora l’oggetto, cui l’evento e collegato, sia una collezione temporale, unarelazione o un campo, l’etichetta e una lista di simboli (indicatori di evento),sottoinsieme di {ETi, ETt, ATi, ATt}, dove:

• ETi indica che l’evento determina l’inizio del periodo di validita;

• ETt indica che l’evento determina la fine del periodo di validita;


Figura 2.25: Esempio di attributi e collezione di attributi con tempo di validita

• ATi indica che l’evento coincide con l’istante iniziale del periodo di disponi-bilita dei fatti associati al lifespan di un’entita o associati ad una collezionetemporale, una relazione, un campo, o un territorio di schema;

• ATtindica che l’evento coincide con l’istante finale del periodo di disponibi-lita dei fatti associati al lifespan di un’entita o associati ad una collezionetemporale, una relazione, un campo, o un territorio di schema.

Qualora si tratti di un evento collegato ad un’entita temporale E che utilizzaun diagramma degli stati ∆, gli indicatori di evento sono un sottoinsieme di{σ1 → σ2 | σ1, σ2 ∈ ∆} ∪ {ATi, ATt} dove:

• un indicatore nella forma σ1 → σ2 indica che l’evento determina il passaggiodell’entita E dallo stato σ1 allo stato σ2;

• ATi e ATt indicano che l’evento coincide con l’istante iniziale o finale delperiodo di disponibilita dei fatti associati alle informazioni registrate nellabase di dati.

Si noti che se ad un entita, una collezione, una relazione, una aggregazione, uncampo o un territorio di schema non e associato un tempo di validita, allora nonvi possono essere eventi, relativi al tempo dell’evento, associati ad uno di talicostrutti; inoltre, a nessun oggetto che non ammetta il tempo di transazione puopuo essere associato un evento relativo al tempo di disponibilita. [3]


Figura 2.26: Esempio di entita e collezione di attributi con tempo di transazione

Relazioni di sincronizzazione

In questo paragrafo ci limiteremo ad indicare quali tipi di relazioni di sincroniz-zazione sono supportati dal modello ChronoGeoGraph, evitando una discussioneapprofondita che il lettore puo trovare in [3]. Le relazioni di sincronizzazionesono dei vincoli definibili tra gli intervalli di attivita, o tra gli istanti iniziali e/ofinali di tali intervalli, di due entita.Nel modello ChronoGeoGraph sono previsti tredici tipi di relazioni di sincroniz-zazione, mostrati in Figura 2.29.

Ad esempio, si consideri una relazione di sincronizzazione fra l’entita Sovrac-carico e l’entita Attenuazione nella gestione di una base di dati per un impiantotermonucleare. Si vuole che l’azione di controllo sulla temperatura del nocciolosia avviata prima dell’effettivo insorgere di un sovraccarico; e si vuole che le barredi carbonio aggiuntive vengano tolte non prima che la situazione di sovraccaricosia rientrata [3].

La Figura 2.30 mostra la situazione descritta dall’esempio. E importante sot-tolineare come le relazioni di sincronizzazione non possano essere temporali.


Figura 2.27: Tempo dell’evento e tempo di disponibilita delle collezioni diattributi e del lifespan delle entita

Figura 2.28: Tempo dell’evento e tempo di disponibilita delle relazioni


Figura 2.29: Tipi di relazioni di sincronizzazione

Cardinalita snapshot e lifespan

La cardinalita definita nella parte relativa agli schemi E/R (vedi sezione 2.1.3)puo essere definita come cardinalita snapshot. Accanto ad essa e stata introdottala nozione di cardinalita lifespan (vedi [3]).

Gli attributi delle entita temporali possono avere una cardinalita lifespan, cherappresenta il minimo e il massimo numero di valori che possono assumere nell’ar-co di vita dell’entita. Per annotare un attributo definendo i vincoli di cardinalitalifespan si introduce la coppia [min:max] dove min e max sono il minimo e il mas-simo numero di valori che l’attributo puo assumere nell’arco di vita dell’entita.Se non indicata, la cardinalita lifespan e per definizione [0:M]. Devono valerele seguenti disuguaglianze minls = minss ≤ maxss ≤ maxls (dove le annotazio-ni “ls” e “ss” a pedice rappresentano, rispettivamente, la cardinalita lifespan esnapshot).La distinzione tra cardinalita snapshot e cardinalita lifespan si applica natural-mente a relazioni ed aggregazioni temporali. La cardinalita snapshot specifica unvincolo sul numero massimo e minimo di istanze di relazione cui ogni istanza diun’entita coinvolta nella relazione puo partecipare in un dato istante di tempo.La cardinalita lifespan specifica un vincolo di partecipazione sul numero massi-mo e minimo di istanze di relazione a cui ogni istanza dell’entita puo parteciparenel tempo. In Figura 2.31 e mostrato un esempio di relazione con cardinalitalifespan.


Figura 2.30: Esempio di relazione di sincronizzazione

Figura 2.31: Esempio di relazione con cardinalita lifespan

Capitolo 3

XML ed XML Schema

Questo capitolo e interamente dedicato ad una panoramica su XML.La prima sezione introduce il “linguaggio” XML, mentre nella seconda e nellaterza sezione verranno introdotti gli strumenti messi a disposizione per la defini-zione di schemi di documenti XML (DTD e XML Schema). Nella quarta sezionesono invece descritti i linguaggi con cui e possibile eseguire interrogazioni su talidocumenti (XPath e XQuery).Infine, l’ultima sezione analizza un’applicazione pratica di questi strumenti (GML),sviluppata per la gestione di dati spaziali in XML.

3.1 L’eXtensible Markup Language

L’eXtensible Markup Language, comunemente noto come XML, non e un lin-guaggio di programmazione nel senso comune del termine, ma un meta-linguaggioche consente di definire strutture per la creazione documenti formattati.Un documento XML e un file di testo che contiene una serie di tag, attributi etesto secondo regole sintattiche definite da una struttura ad albero (noto come“document tree”), il cui elemento radice (il “root element”) contiene l’insiemedegli altri elementi del documento. Questa struttura gerarchica e basata su com-ponenti denominati elementi, ognuno dei quali rappresenta un componente logicodel documento e puo contenere altri elementi (sottoelementi) o del testo. Aglielementi possono, inoltre, essere associate altre informazioni che ne descrivono leproprieta; tali informazioni vengono chiamate attributi.Ad esempio questo tesi e stata scritta in LATEX, uno strumento atto a definirela struttura di documenti. La struttura gerarchica (semplificata) e quella rap-presentata in Figura 3.1. La radice, denominata “libro”, contiene una lista di

45

46 CAPITOLO 3. XML ED XML SCHEMA

Figura 3.1: Struttura gerarchica di un libro

elementi che rappresentano i vari capitoli della tesi, ciascuno dei quali, a sua vol-ta, contiene del testo o delle immagini oltre a possedere uno specifico attributo“titolo”, analogamente alla radice.Come si puo vedere il LATEXformatta il documento, imponendogli una precisastruttura: un libro contiene vari capitoli, ma non puo esserci un capitolo checontiene uno o piu libri. XML serve esattamente a questo: dare una precisastruttura ai documenti di testo, ma, come vedremo piu avanti, risulta molto piuadattabile alle diverse esigenze.La traduzione in XML della struttura definita in Figura 3.1 puo essere la seguente:

<?xml ve r s i on = ’ ’1 .0 ’ ’ ?>< l i b r o t i t o l o = ’ ’ T i to l o de l l i b r o ’ ’><c ap i t o l o t i t o l o = ’ ’ T i to l o de l primo cap i t o l o ’ ’><t e s to>Blocco d i t e s t o de l primo c ap i t o l o</te s to>

</cap i t o l o ><c ap i t o l o t i t o l o = ’ ’ T i to l o de l secondo cap i t o l o ’ ’><t e s to>Blocco d i t e s t o de l secondo c ap i t o l o</te s to><immagine f i l e = ’ ’ immagine1 . jpg ’ ’></immagine><t e s to>Altro b locco d i t e s t o</te s to>

3.1. L’EXTENSIBLE MARKUP LANGUAGE 47

. . .

</ l i b r o >

La prima riga del documento lo identifica come un documento XML e ne specificala versione (in questo caso la versione 1.0):

<?xml ve r s i on = ’ ’1 .0 ’ ’ ?>

Il corpo vero e proprio del documento segue la prima riga e rappresenta gli ele-menti tramite tag, cioe sequenze di caratteri delimitate dai segni “minore” e“maggiore” proprio come avviene per l’HTML.Per quanto riguarda il contenuto, un documento XML puo contenere potenzial-mente qualsiasi carattere dell’alfabeto latino, cifre e punteggiatura. Normalmentevengono accettati come caratteri validi in un documento XML i primi 128 ca-ratteri della codifica ASCII (lettere dell’alfabeto latino minuscole e maiuscole,cifre, segni di punteggiatura, ecc.). Se un documento contiene caratteri che nonrientrano tra questi (ad esempio, lettere accentate, simboli di valuta, ecc.) e ne-cessario specificare lo schema di codifica utilizzato. Lo schema di codifica ed altreinformazioni dirette al software incaricato di elaborare il documento XML sonoindicate tramite elementi speciali detti “processing instruction”. Ad esempio, laseguente “processing instruction”:

<?xml ve r s i on = ’ ’1 .0 ’ ’ encoding = ’ ’ i so −8859−1’’?>

abilita l’uso del set di caratteri noto come “Latin 1”, contenente le lettere ac-centate ed altri simboli. Per ulteriori dettagli sui contenuti di un documentoconsultare [21].Ogni documento deve seguire alcune regole, che sono quelle imposte ai tag cheesso utilizza (proprio come avviene per l’HTML). Se un documento rispetta tut-te le regole definite dalla “grammatica” cui fanno riferimento i tag che utilizzaviene detto “valido” o “ben formato”. Tutti i documenti XML devono essereben formati (“well formed”) e tale concetto e in qualche modo paragonabile allacorrettezza ortografica di una lingua.Inoltre, un documento XML si definisce ben formato se e soltanto se rispetta leseguenti regole:

• ogni documento XML deve contenere un unico elemento di massimo livello


(root) che contenga tutti gli altri elementi del documento. Le sole parti diXML che possono stare all’esterno di questo elemento sono i commenti ele direttive di elaborazione (per esempio, la dichiarazione della versione diXML);

• tutti gli elementi devono avere un tag di chiusura o, se vuoti, possonoprevedere la forma abbreviata ( / seguito dal “minore”);

• gli elementi devono essere opportunamente nidificati, cioe i tag di chiusuradevono seguire l’ordine inverso dei rispettivi tag di apertura;

• XML fa distinzione tra maiuscole e minuscole, per cui i nomi degli elementie degli attributi devono coincidere nei tag di apertura e chiusura ancherispetto a cio;

• Un tag puo iniziare con un lettera o un underscore e puo contenere lettere,numeri, il punto, l’underscore o il trattino. Non sono ammessi spazi o altricaratteri.

Le regole che un documento XML deve seguire sono molto rigide, ma il linguaggioXML permette a ciascuno di definire la propria grammatica, il proprio insieme diregole che i documenti sono tenuti a rispettare per poter essere considerati benformati.Di seguito sono descritte due metodologie, abbastanza simili ma di diversa poten-za espressiva, introdotte appositamente per definire grammatiche XML: i DTDe gli XML Schema.

3.2 DTD - Document Type Definition

Da un punto di vista cronologico, il primo approccio alla definizione di gram-matiche per documenti XML e quello basato sulla Document Type Definition(DTD).Un documento DTD e composto da un insieme di regole che descrivono i tag inun documento XML, la loro relazione reciproca rispetto alla struttura del docu-mento e altre informazioni sugli attributi di ciascun tag. La sintassi di un DTDsi basa principalmente sulla presenza di due dichiarazioni:

<!ELEMENT> e <!ATTLIST>

3.2. DTD - DOCUMENT TYPE DEFINITION 49

La prima definisce gli elementi utilizzabili nel documento e la struttura del docu-mento, la seconda definisce la lista di attributi per ciascun elemento. Ad esempio,la dichiarazione

<!ELEMENT l i b r o ( c ap i t o l o+)>

indica che l’elemento “libro” ha come sottoelemento uno o piu elementi “ca-pitolo”. Il carattere ’+’, dopo il nome del sottoelemento, indica il numero dioccorrenze consentito all’interno di un documento. Per caratterizzare la car-dinalita (dell’insieme di sottoelementi) viene utilizzato un insieme di caratterispeciali:

• + indica che l’elemento e presente una o piu volte;

• * indica che l’elemento e presente zero o piu volte;

• ? indica che l’elemento e presente zero o una sola volta.

La definizione:

<!ELEMENT cap i t o l o ( immagine ∗ , t e s t o+)>

indica che l’elemento “capitolo” contiene una sequenza di elementi “immagine”e “testo”. L’elemento “immagine” puo essere presente zero o piu volte, mentre“testo” deve essere presente almeno una volta.Per la definizione dei tag che non contengono sottoelementi e necessario distin-guere il caso dei tag vuoti dai tag che racchiudono testo. Nel caso di tag vuoto,come accade per “immagine”, la definizione e:

<!ELEMENT immagine EMPTY>

Nel caso di elementi che racchiudono testo, la definizione e la seguente:

<!ELEMENT te s t o (#PCDATA)>

E anche possibile definire elementi il cui contenuto non sia definito a priori,ossia elementi che possono essere vuoti o contenere altri elementi senza vincoliparticolari. Questi elementi si definiscono nel seguente modo:

<!ELEMENT elemento ANY>


Gli attributi degli elementi vengono, invece, definiti con dichiarazioni del tipo:

<!ATTLIST l i b r o t i t o l o CDATA #REQUIRED>

il quale indica che l’elemento “libro” prevede un attributo “titolo” che puo ave-re come valore una qualsiasi combinazione di caratteri (CDATA). L’indicazio-ne ]REQUIRED indica che la presenza dell’attributo e obbligatoria. Valorialternativi a ]REQUIRED sono:

• ]IMPLIED, che indica che l’attributo e opzionale;

• ]FIXED, che indica che il valore dell’attributo e fisso e corrisponde al valorespecificato.

Se un attributo prevede valori alternativi predefiniti e necessario specificarli alposto di CDATA, come accade per l’attributo “tipo” del tag “capitolo”:

<!ATTLIST cap i t o l ot i t o l o CDATA #REQUIREDt ipo ( i n t r oduc t i on | abs t r a c t | b i b l i o g r a f i a ) #IMPLIED>

In questo caso vengono definiti due attributi per l’elemento “capitolo” facendoseguire alla definizione del primo attributo (titolo) quella del secondo (tipo).L’attributo tipo, opzionale, puo assumere uno tra i valori introduction, abstracte bibliografia.Un esempio che riporta il DTD completo di un documento che descrive un libroanalogo a quello visto negli esempi precedenti, e il seguente:

<!ELEMENT l i b r o ( c ap i t o l o+)><!ELEMENT cap i t o l o ( immagine ∗ , t e s t o +, cod i c e ∗)>

<!ELEMENT immagine EMPTY><!ELEMENT te s t o (#PCDATA)>

<!ATTLIST l i b r o t i t o l o CDATA #REQUIRED><!ATTLIST cap i t o l ot i t o l o CDATA #IMPLIEDt ipo ( ab s t r a c t | b i b l i o g r a f i a | note ) #IMPLIED><!ATTLIST immagine f i l e CDATA #REQUIRED>

3.2. DTD - DOCUMENT TYPE DEFINITION 51

Un DTD definisce la grammatica per un linguaggio di markup.Una volta definito un DTD e necessario mettere in relazione un documento XMLcon il DTD, in modo che un parser XML possa verificare non soltanto la strutturaben formata del documento, ma anche la sua validita rispetto alla grammaticaspecificata.Esistono due modi per indicare il DTD cui un documento XML fa riferimento.Il primo modo prevede la presenza del DTD all’interno del documento XML,come nel seguente esempio:

<?xml ve r s i on = ’ ’1.0 ’ ’ ><!DOCTYPE l i b r o [. . . D e f i n i z i o n i de l DTD. . .]>

<l i b r o >. . . Contenuto de l documento XML. . .</ l i b r o >

La dichiarazione <!DOCTY PE > indica che il documento individuato dall’ele-mento root “libro” segue le regole definite tra le parentesi quadre.Il secondo modo prevede che il DTD sia definito in un file esterno ed il documentoXML abbia un riferimento a tale file, come nel seguente esempio:

<?xml ve r s i on = ’ ’1.0 ’ ’ ><!DOCTYPE l i b r o SYSTEM ’ ’ l i b r o . dtd ’ ’>

In questo caso si fa riferimento al file DTD “libro.dtd”.

Tuttavia l’uso dei DTD per definire la grammatica di un linguaggio di mar-kup non sempre e del tutto soddisfacente. I DTD non consentono di specificareun tipo di dato da associare agli attributi, ne di specificare il numero minimo omassimo di occorrenze di un tag in un documento (oltre ad altre caratteristicheche in determinati contesti permetterebbero di ottenere un controllo ancora piuaccurato sulla validita di un documento XML).


3.3 XML Schema

Le limitazioni dell’approccio basato sui DTD, di cui si e discusso nella sezioneprecedente, hanno stimolato la proposta di approcci alternativi alla definizionedi grammatiche per documenti XML. Tra questi approcci il piu noto e XMLSchema.In XML Schema e possibile definire due tipi di dati: quelli semplici che non pos-sono contenere altri elementi ne attributi e quelli complessi che sono compostida altri elementi (semplici o complessi a loro volta) e da attributi. Entrambisono definibili a partire dai tipi di dato “classici” e possono essere personalizzatitramite composizioni e restrizioni.La Tabella 3.1 descrive i tipi di dato predefiniti che possono essere utilizzati,come riportati in [21].

La dichiarazione:

<xs : element name= ’ ’ quant ita ’ ’ type = ’ ’ xs : i n t ege r ’ ’ />

consente di definire l’elemento quantita in un documento XML che puo assu-mere soltanto un valore di tipo intero. In altre parole, sara considerato validol’elemento

<quantita >123</quantita>

ma non l’elemento

<quantita>uno</quantita >.

XML Schema prevede, inoltre, la possibilita di definire tipi di dato semplicipersonalizzati come derivazione di quelli predefiniti. In Tabella 3.2 sono riportarele diverse restrizioni che si possono definire sui tipi di dato predefiniti, mentrela Tabella 3.3 riporta, per ogni tipo di dato predefinito, le relative restrizioniapplicabili.Se, ad esempio, si vuole limitare il valore che puo essere assegnato all’elemento“quantita”, e possibile definirlo nel seguente modo:

<xs : element name= ’ ’ quant ita ’ ’ ><xs : simpleType><xs : r e s t r i c t i o n base = ’ ’ xs : i n t ege r ’ ’>

3.3. XML SCHEMA 53

Tabella 3.1: Tipi di dato predefiniti

Name DescriptionStringhestring A stringnormalizedString A string that does not contain line feeds, carriage returns,

or tabstoken A string that does not contain line feeds, carriage returns,

tabs, leading or trailing spaces, or multiple spacesDate e tempodate Defines a date valuedateTime Defines a date and time valueduration Defines a time intervalgDay Defines a part of a date - the day (DD)gMonth Defines a part of a date - the month (MM)gMonthDay Defines a part of a date - the month and day (MM-DD)gYear Defines a part of a date - the year (YYYY)gYearMonth Defines a part of a date - the year and month (YYYY-MM)time Defines a time valueNumericibyte A signed 8-bit integerdecimal A decimal valueint A signed 32-bit integerinteger An integer valuelong A signed 64-bit integernegativeInteger An integer containing only negative values ( .., -2, -1.)nonNegativeInteger An integer containing only non-negative values (0, 1, 2, ..)nonPositiveInteger An integer containing only non-positive values (.., -2, -1, 0)positiveInteger An integer containing only positive values (1, 2, ..)short A signed 16-bit integerunsignedLong An unsigned 64-bit integerunsignedInt An unsigned 32-bit integerunsignedShort An unsigned 16-bit integerunsignedByte An unsigned 8-bit integerdoublefloat


Name DescriptionBinarihexBinarybase64BinaryBooleaniboolean

Tabella 3.2: Restrizioni sui tipi di dato

Constraint Descriptionenumeration Defines a list of acceptable valuesfractionDigits Specifies the maximum number of decimal places allowed.

Must be equal to or greater than zerolength Specifies the exact number of characters or list items

allowed. Must be equal to or greater than zeromaxExclusive Specifies the upper bounds for numeric values (the value

must be less than this value)maxInclusive Specifies the upper bounds for numeric values (the value

must be less than or equal to this value)maxLength Specifies the maximum number of characters or list items

allowed. Must be equal to or greater than zerominExclusive Specifies the lower bounds for numeric values (the value

must be greater than this value)minInclusive Specifies the lower bounds for numeric values (the value

must be greater than or equal to this value)minLength Specifies the minimum number of characters or list items

allowed. Must be equal to or greater than zeropattern Defines the exact sequence of characters that are accepta-

ble totalDigits Specifies the exact number of digits allowed.Must be greater than zero

whiteSpace Specifies how white space (line feeds, tabs, spaces, andcarriage returns) is handled

3.3. XML SCHEMA 55

Tabella 3.3: Restrizioni applicabili ai tipi di dato

Data type ConstrainsStringhe enumeration, length, maxLength, minLength, pattern,

whiteSpace.Date e tempo enumeration, maxExclusive, maxInclusive, minExclusive,

minInclusive, pattern, whiteSpaceNumerici enumeration, fractionDigits, maxExclusive, maxInclusive,

minExclusive, minInclusive, pattern, totalDigits, whiteSpa-ce

Binari enumeration, length, maxLength, minLength, pattern,whiteSpace

Booleani pattern, whiteSpace

<xs : min Inc lu s ive va lue = ’ ’1 ’ ’ /><xs : maxInc lus ive va lue = ’ ’100 ’ ’ />

</xs : r e s t r i c t i o n ></xs : simpleType>

</xs : element>

La dichiarazione indica che l’elemento e di tipo semplice e prevede una restrizionesul tipo di dato intero predefinito accettando valori compresi tra 1 e 100.

3.3.1 Tipi di dato complessi

I tipi di dato complessi si riferiscono ad elementi che possono contenere altrielementi e possono avere attributi. Lo schema generale per la definizione di unelemento di tipo complesso e il seguente:

<xs : element name= ’ ’NOME−ELEMENTO’ ’><xs : complexType>

. . . D e f i n i z i on e de l t i po complesso . . .

. . . D e f i n i z i on e d e g l i a t t r i b u t i . . .</xs : complexType>

</xs : element>

Se l’elemento puo contenere altri elementi, bisogna definire la sequenza di ele-menti che possono stare al suo interno utilizzando uno dei costruttori di tipi


complessi previsti:

• < xs : sequence > che consente di definire una sequenza ordinata disottoelementi;

• < xs : choice > che consente di definire un elenco di sottoelementi alter-nativi;

• < xs : all > che consente di definire una sequenza non ordinata di sottoe-lementi.

Per ciascuno di questi costruttori e per ciascun elemento, e possibile definire ilnumero di occorrenze previste utilizzando gli attributi minOccurs e maxOccurs.Ad esempio, la condizione che stabilisce che l’elemento testo puo essere presenteuna o un numero arbitrario di volte all’interno di un capitolo si puo esprimerenel seguente modo:

<xs : element name= ’ ’ cap i t o l o ’ ’><xs : complexType><xs : element name= ’ ’ t e s to ’ ’ minOccurs = ’ ’1 ’ ’

maxOccurs= ’ ’unbounded ’ ’/></xs : complexType>

</xs : element>

In questo caso il valore unbounded indica che non e stabilito un numero massimodi elementi testo che possono stare all’interno di un capitolo.La definizione della struttura di un elemento puo contenere la definizione di ognielemento che appartiene alla struttura.Per gli elementi vuoti e prevista una definizione basata sul seguente schema:

<xs : element name= ’ ’NOME−ELEMENTO’ ’><xs : complexType><xs : complexContent><xs : ex t ens i on base = ’ ’ xs : anyType ’ ’ />. . . D e f i n i z i on e d e g l i a t t r i b u t i . . .

</xs : complexContent></xs : complexType>

</xs : element>

In altri termini, un elemento vuoto e considerato un elemento di tipo complessoil cui contenuto non si basa su nessun tipo predefinito.

3.3. XML SCHEMA 57

La definizione degli attributi e basata sull’uso del tag “xs:attribute”, come mo-strato nel seguente esempio:

<xs : a t t r i bu t e name= ’ ’ t i t o l o ’ ’ type = ’ ’ xs : s t r i ng ’ ’use = ’ ’ requ i red ’ ’ />

L’attributo use consente di specificare alcune caratteristiche, quali la presenzaobbligatoria (required) o un valore predefinito (default) in combinazione conl’attributo value. Ad esempio, la seguente definizione indica un attributo il cuivalore di predefinito e test:

<xs : a t t r i bu t e name= ’ ’ t i t o l o ’ ’ type = ’ ’ xs : s t r i ng ’ ’use = ’ ’ de fau l t ’ ’ va lue = ’ ’ t e s t ’ ’ />

Bisogna tener presente che se non si specifica esplicitamente l’obbligatorieta del-l’attributo, esso e considerato opzionale. Il seguente codice presenta uno XMLSchema relativo al linguaggio di descrizione di articoli tecnici mostrato nei variesempi. Vediamo di seguito un esempio di XML Schema che definisce, come negliesempi precedenti, una grammatica per la definizione di libri:

<?xml ve r s i on = ’ ’1.0 ’ ’? ><xs : schema xmlns : xs = ’ ’ http ://www.w3 . org /2001/XML Schema ’ ’>

<xs : element name= ’ ’ l i b r o ’ ’><xs : complexType>

<xs : sequence>

<xs : element name= ’ ’ cap i t o l o ’ ’maxOccurs= ’ ’unbounded ’ ’>

<xs : complexType><xs : a l l maxOccurs= ’ ’unbounded ’ ’>

<xs : element name= ’ ’ immagine ’ ’ minOccurs= ’ ’0 ’ ’><xs : complexType>

<xs : a t t r i bu t e name= ’ ’ f i l e ’ ’use = ’ ’ requ i red ’ ’>

<xs : simpleType><xs : r e s t r i c t i o n base = ’ ’ xs : s t r i ng ’ ’/>

</xs : simpleType></xs : a t t r i bu t e >


</xs : complexType></xs : element>

<xs : element name= ’ ’ t e s to ’ ’/>

</xs : a l l >

<xs : a t t r i bu t e name= ’ ’ t i t o l o ’ ’ type = ’ ’ xs : s t r i ng ’ ’use = ’ ’ opt iona l ’ ’/>

<xs : a t t r i bu t e name= ’ ’ t ipo ’ ’ use = ’ ’ opt iona l ’ ’><xs : simpleType>

<xs : r e s t r i c t i o n base = ’ ’ xs : s t r i ng ’ ’><xs : enumeration value = ’ ’ in t roduct i on ’ ’/><xs : enumeration value = ’ ’ abst ract ’ ’/><xs : enumeration value = ’ ’ b i b l i o g r a f i a ’ ’/>


</xs : a t t r i bu t e >


</xs : sequence>

<xs : a t t r i bu t e name= ’ ’ t i t o l o ’ ’ type = ’ ’ xs : s t r i ng ’ ’use = ’ ’ requ i red ’ ’/>


</xs : schema>

Questo XML Schema e equivalente al DTD definito nella sezione precedente.

XML Schema prevede consente di rendere modulare la definizione della strut-tura di un documento XML tramite la dichiarazione di tipi e di elementi. E,infatti, possibile dichiarare separatamente ogni elemento, definendo i necessaritipi di dato semplici e complessi, ognuno dei quali puo richiamare al suo interno,come “type” di un sotto-elemento, uno dei tipi di dato definiti. In questo modosi passa da una struttura ad albero in cui ogni nodo “contiene” i nodi figli aduna struttura a grafo in cui ogni nodo contiene dei riferimenti ad altri nodi del

3.3. XML SCHEMA 59

grafo creatosi.Si puo definire un tipo complesso in base al seguente schema:

<xs : complexType name= ’ ’nome−t ipo ’ ’>. . .</xs : complexType>

Il riferimento ad una dichiarazione di tipo viene fatta come se fosse un tipopredefinito, come mostrato nel seguente esempio:

<xs : element name= ’ ’nome−elemento ’ ’ type = ’ ’nome−t ipo ’ ’ />

La possibilita di dichiarare elementi e tipi di dato implica l’esistenza di un ambitodi visibilita, o contesto, dei componenti dichiarati. I componenti di uno schemadichiarati al livello massimo, cioe come sottoelementi diretti dell’elemento root,sono considerati dichiarati a livello globale e possono essere utilizzati nel restodello schema. Nella dichiarazione di un tipo complesso e possibile fare riferimen-to ad elementi gia esistenti dichiarati a livello globale oppure si possono definirenuovi elementi. La definizione di nuovi elementi all’interno di una definizione ditipo o di elemento costituisce una dichiarazione a livello locale. Cio vuol dire chel’utilizzo di questi elementi e limitato alla definizione del tipo complesso in cuisono dichiarati e non possono essere utilizzati in altri punti dello schema.A partire da una grammatica definita tramite un XML Schema, e possibile sfrut-tare un parser XML (validatore) per verificare la validita di un documento XML.Il parser avra bisogno, quindi, sia del documento XML da validare, sia delloschema XML rispetto a cui effettuare la validazione.

3.3.2 Namespace

Un namespace e un insieme di nomi di elementi e di nomi di attributi ai qualie associato un identificatore univoco, che consente di distinguere tali elementida elementi omonimi appartenenti ad altri namespace. Per fare un esempio, senell’ambito di una grammatica per descrivere dei dati anagrafici e stato defini-to un elemento indirizzo, questo nome potrebbe essere confuso con l’elementoindirizzo definito nell’ambito di una grammatica che descrive messaggi di postaelettronica. L’identificatore del relativo namespace consente di distinguere i dueelementi omonimi.In un documento XML si fa riferimento ad un namespace utilizzando un attri-


buto speciale (xmlns) associato al root element, come nel seguente esempio:

< l i b r o xmlns= ’ ’ http ://www. dominio . i t /xml/ l i b r o ’ ’>

Questo indica che l’elemento libro ed i suoi sottoelementi utilizzano i nomi definitinel namespace identificato dall’identificatore “http://www.dominio.it/xml/libro”.L’identificatore di un namespace puo essere rappresentato da una qualsiasi strin-ga, purche sia univoca. Proprio per garantirne l’univocita, e prassi ormai con-solidata utilizzare un URI (Uniform Resource Identifier) come identificatore. Ebene evidenziare che non e necessario che l’indirizzo specificato come identifica-tore di namespace corrisponda ad un file pubblicato sul Web. Esso e utilizzatosemplicemente come identificatore ed il parser non accedera al Web per verificarel’esistenza dell’URI.L’attributo xmlns:xsi specifica la modalita con cui viene indicato il riferimentoallo schema, mentre l’attributo xsi:schemaLocation indica il namespace ed il filein cui e definito il relativo XML Schema separati da uno spazio. Per maggioridettagli si puo consultare [21].

3.4 Linguaggi di interrogazione

Di seguito sono descritti brevemente due linguaggi, XPath ed XQuery, apposi-tamente creati per analizzare ed eseguire interrogazioni su documenti XML, cherisulteranno indispensabili per la messa in opera di una base di dati basata sudocumenti XML.

3.4.1 XPath

Il linguaggio XPath consente di formulare espressioni dichiarative, chiamateespressioni XPath o pattern, che individuano i vari nodi dell’albero di rappre-sentazione di un documento XML.La sintassi, molto semplice e vicina a quella utilizzata all’interno di file systemper indicare il percorso di file e cartelle, utilizza il simbolo “/” come root element.Facendo riferimento al seguente documento XML, l’espressione “/” rappresental’elemento libro:

3.4. LINGUAGGI DI INTERROGAZIONE 61

<?xml ve r s i on = ’ ’1 .0 ’ ’ ?>< l i b r o t i t o l o = ’ ’ ’ ’><c ap i t o l o t i t o l o = ’ ’ T i to l o de l primo cap i t o l o ’ ’><t e s to>Blocco d i t e s t o de l primo c ap i t o l o</te s to><immagine f i l e = ’ ’ immagine1 . jpg ’ ’></immagine>

</cap i t o l o ><c ap i t o l o t i t o l o = ’ ’ T i to l o de l secondo cap i t o l o ’ ’><t e s to>Blocco d i t e s t o de l secondo c ap i t o l o</te s to><t e s to>Altro b locco d i t e s t o</te s to>

</cap i t o l o ></ l i b r o >

Per individuare l’elemento “testo” all’interno dell’esempio di documento XML enecessario specificare il seguente percorso:

/ l i b r o / c ap i t o l o / t e s t o

Se si e interessati all’attributo titolo dell’elemento capitolo e possibile specificarlonel modo seguente:

/ l i b r o / c ap i t o l o / @t i t o l o

Queste espressioni, pero, individuano il primo elemento che corrisponde al per-corso, e volendo selezionare uno specifico elemento, ad esempio il capitolo contitolo “Titolo del secondo capitolo”, diventa necessario utilizzare la seguenteespressione:

/ l i b r o / c ap i t o l o / [ @t i t o l o =’ T i to l o de l secondo cap i t o l o ’ ]

In pratica, all’interno delle parentesi quadre si specifica la condizione che deveessere soddisfatta dall’attributo (o elemento).Di seguito sono raccolte alcune delle molte funzioni di utilita messe a disposizione


da XPath:

• count() restituisce il numero di elementi relativi all’espressione passatacome argomento;

• concat() concatena le stringhe passate come parametro;

• ends-with() restituisce true se il primo parametro e di tipo stringa e finiscecon la stringa passata come secondo parametro;

• last() specifica l’ultima posizione di una sequenza di elementi;

• number() converte il valore passato come parametro in un numero;

• position() specifica la posizione di un elemento;

• round() arrotonda un numero all’intero piu vicino;

• starts-with() restituisce true se il primo parametro di tipo stringa e iniziacon la stringa passata come secondo parametro;

• string-length() restituisce il numero di caratteri che compongono la stringaspecificata come parametro;

• substring() restituisce una sottostringa selezionata sulla base dei parametrispecificati.

Le due espressioni seguenti specificano rispettivamente il secondo capitolo el’ultimo capitolo del libro:

/ l i b r o / c ap i t o l o [ p o s i t i o n ()=2]/ l i b r o / c ap i t o l o [ p o s i t i o n ()= l a s t ( ) ]

Gli esempi di pattern visti rappresentano percorsi assoluti, cioe individuano unelemento partendo dall’elemento root, ma spesso risulta necessario fare riferi-mento a cammini non assoluti ma relativi.In questo caso, in XPath, il nodo corrente viene indicato con il punto “.”, mentreil nodo genitore del nodo corrente viene indicato con i due punti “..” . La doppiabarra “/ /” consente di individuare tutti i discendenti di un particolare elemento.Ad esempio, l’espressione

/ l i b r o / c ap i t o l o / /immagine


individua tutti gli elementi “immagine” contenuti nell’elemento “capitolo”, aqualsiasi livello. Per individuare tutti i sottoelementi di un certo elemento e pos-sibile utilizzare l’asterisco. Per selezionare tutti gli elementi del secondo capitolosi puo scrivere la seguente espressione XPath:

/ l i b r o / c ap i t o l o [ p o s i t i o n ()=2]/∗

Esistono numerose altre possibilita per costruire espressioni XPath, soprattuttosfruttando le numerose funzioni predefinite che XPath mette a disposizione, chesono descritte in [21].

3.4.2 XQuery

Essendo questo lavoro orientato all’utilizzo di XML Schema come linguaggio perla definizione di strutture di basi di dati, di seguito si introduce un strumentoXML con il quale e possibile “interrogare” un documento, scritto conformementead una grammatica definita in XML Schema, riguardo i dati in esso contenuti.

XML Query language (XQuery) nasce con l’intento di realizzare un linguaggioper eseguire interrogazioni su un documento XML, ossia di definire una sorta di“SQL per XML”. XQuery e un linguaggio basato su XML ed e definito attraversouna sintassi semplice e facilmente leggibile che consente di formulare, nel modopiu agevole possibile, le interrogazioni sui dati.Prima descrivere brevemente il linguaggio XQuery, viene di seguito introdotto ildocumento XML di esempio utilizzato per le interrogazioni di esempio.Si consideri un documento XML (chiamato arch-libri.xml) nel quale sono memo-rizzate informazioni relative ad un archivio contenente numerosi libri, che, perogni libro, struttura l’informazione nel seguente modo (per semplicita si riportasolamente la struttura base):

<l i b r o ><t i t o l o >Tito lo−del−l i b r o </t i t o l o ><autore>Autore−del−l i b r o </autore><ed i to r e >Editore−del−l i b r o </ed i to r e ><prezzo>Prezzo−del−l i b r o </prezzo></ l i b r o >


Un’interrogazione in XQuery e costituita da un’espressione che legge una sequen-za di nodi XML od un singolo valore e restituisce come risultato una sequenza dinodi od un singolo valore. Le espressioni XQuery sono composte da espressioniXPath per individuare i nodi da analizzare e da alcune funzionalita aggiuntivespecifiche di XQuery per il recupero delle informazioni.Ad esempio per ricercare all’interno del documento tutti i nodi “libro” che hannoun prezzo maggiore di 50 e ordina il risultato in funzione del nome dell’autore,si utilizza la seguente interrogazione:

document ( ’ ’ arch− l i b r i . xml ’ ’ ) / / l i b r o [ prezzo > 50 ]SORTBY ( autore )

L’espressione principale utilizzata in XQuery, per formulare interrogazioni com-plesse, e quella che viene chiamata espressione FLWR (For-Let-Where-Return).Questa espressione costituisce una generalizzazione del costrutto SELECT-FROM-HAVING-WHERE del linguaggio SQL.Si consideri il seguente esempio:

FOR $e IN document ( ’ ’ arch− l i b r i . xml ’ ’ ) / / ed i t o r eLET $ l := document ( ’ ’ arch− l i b r i . xml ’ ’ ) / / l i b r o [ e d i t o r e=$e ]WHERE count ( $ l ) > 5RETURN<r i s u l t a t o >{$e}</ r i s u l t a t o >

la prima istruzione crea una lista (associata alla variabile “e”) contenente tuttigli editori presenti nell’archivio. La seconda riga associa a ciascun editore, lalista dei libri da lui editi (variabile “l”), andando a creare una lista ordinata dituple formate da (e,l). Tramite la terza riga, si impone un filtro sulla rispostaandando a considerare solamente gli editori hanno pubblicato piu di cinque libri.L’ultima istruzione (RETURN) crea il risultato inserendo all’interno di un ele-mento chiamato “risultato”, i nodi “editore” che soddisfano i criteri specificatinell’interrogazione.La funzione count() presente nell’esempio e una delle funzioni che XQuery mat-te a disposizione per operare sulle liste di elementi. Le funzioni principali cheXQuery offre sono:

• avg() che calcola il valor medio dei valori degli elementi;


• count() che restituisce il numero di elementi presenti;

• union(), intersection(), e difference() che realizzano operazioni insiemistichesugli elementi.

Costrutti particolari

XQuery supporta anche il costrutto IF-THEN-ELSE all’interno delle sue espres-sioni. Ad esempio:

FOR $ l IN document ( ’ ’ arch− l i b r i . xml ’ ’ ) / / l i b r oRETURN<r i s u l t a t o >{IF ( $ l / e d i t o r e =’Editore1 ’ )THEN $ l / t i t o l oELSE $ l / autore}</ r i s u l t a t o >

Il risultato di questa interrogazione contiene i titoli dei libri in cui l’editore e’Editore1’, mentre per le altre case editrici restituisce il nome degli autori.Altri due costrutti molto utili in XQuery sono SOME-IN-SATISFIES e EVERY-IN-SATISFIES, che permettono di verificare determinate proprieta sugli elementicontenuti in una lista.Ad esempio:

FOR $ l IN document ( ’ ’ arch− l i b r i . xml ’ ’ ) / / l i b r oWHERE SOME $t IN $ l / t i t o l o SATISFIES ( conta in s ( $t , ’ ’XML’ ’ )AND conta in s ( $t , ’ ’ t u t o r i a l ’ ’ ) )RETURN<r i s u l t a t o >{ $ l / t i t o l o }</ r i s u l t a t o >

FOR $ l IN document ( ’ ’ arch− l i b r i . xml ’ ’ ) / / l i b r oWHERE EVERY $t IN $ l / t i t o l o SATISFIES conta in s ( $t , ’ ’XML’ ’ )RETURN<r i s u l t a t o >


{ $ l / t i t o l o }</ r i s u l t a t o >

La prima interrogazione restituisce come risultato il titolo di tutti i libri nei qualicompare contemporaneamente sia la stringa ’XML’ che la stringa ’tutorial’, men-tre la seconda interrogazione restituisce, invece, i titoli dei libri che contengonoin esso la stringa ’XML’.

Bisogna sottolineare il fatto che uno strumento come XQuery, combinando lecapacita dell’SQL ad alcune delle funzionalita tipiche di un linguaggio di pro-grammazione, fornisce una modalita di interrogazione relativamente semplicema molto potente, oltre a risultare fondamentale per la messa in opera di basidi dati costruiti con le modalita descritte nel presente lavoro.Per ulteriori informazioni su XQuery e possibile consultare [21].

3.5 GML

GML e un sistema di codifica per informazioni geografiche basato su un insiemedi tag definiti in XML Schema. Sviluppato da OpenGIS Consortium a partiredal 2000, e ora giunto alla versione 3.1 (per maggiori informazioni [14] e [15]).Questo riferimento, essendo un chiaro esempio di come sia possibile definire datigeometrici e geografici in XML ed essendo stato creato seguendo i modelli astrattiutilizzati da tutte le basi di dati spaziali, sara un’utile base per la definizione didocumenti XML Schema adatti allo scopo del progetto in discussione.GML e infatti costituito un insieme di documenti XML Schema che definiscono lecomponenti necessarie per la gestione di dati spaziali, in particolare le componentigeometrici di base, come punti, linee e poligoni, che possono essere utilizzati perla costruzione di complessi schemi geometrici. Disponendo le geometrie su unpiano cartesiano, GML definisce le seguenti componenti di base:

• il punto e definito come una coppia di coordinate;

• la linea spezzata e definita come una serie di punti che descrivono, presi acoppie, i diversi segmenti che compongono la linea;

• la linea chiusa e descritta da almeno tre punti distinti, la prima coordinatae l’ultima devono coincidere (quindi almeno quattro coordinate in tutto);

3.5. GML 67

• il poligono e descritto dal suo contorno esterno (definito come la lineachiusa) ed uno o piu contorni interni (anch’essi definiti come la linea chiusa)che ne descrivono i buchi;

• il rettangolo e visto come un qualsiasi poligono ma senza la possibilita didefinire buchi interni;

• l’arco e il cerchio sono descritti da tre punti;

• e infine possibile definire delle “GeometryCollection”, ovvero un insieme diuna o piu geometrie.

Di seguito presentiamo panoramica sulle definizioni in XML Schema date daGML i alcune semplici geometrie che potranno essere presi a modello nelladefinizione delle strutture dati che verranno trattate nel Capitolo 4.2.1.

3.5.1 Elementi spaziali

GML 3.1 prevede tre diversi modi per indicare una posizione nel sistema di coor-dinate, ma due di questi (“coord” e “coordinates”) sono residuati delle precedentiversioni e il loro utilizzo e sconsigliato dagli sviluppatori di GML stesso.Tuttavia, “coord” e un sistema relativamente semplice ed una possibile validaopzione per la definizione di coordinata. Questo sistema e infatti costruito comeun insieme di tre valori decimali, di cui gli ultimi due sono opzionali, che e quindiutilizzabile per la costruzione di sistemi di riferimento da una e tre dimensioni:

<element name= ’ ’ coord ’ ’><complexType><sequence><element name= ’ ’X’ ’ type = ’ ’ decimal ’ ’/><element name= ’ ’Y’ ’ type = ’ ’ decimal ’ ’ minOccurs= ’ ’0 ’ ’/><element name= ’ ’Z ’ ’ type = ’ ’ decimal ’ ’ minOccurs= ’ ’0 ’ ’/>

</sequence></complexType>

</element>

La nuova struttura introdotta per descrivere le coordinate e l’elemento “pos”.“pos” e definito da una lista di valori reali (double) separati da uno spazio(utilizza il costrutto di XML Schema list):


<element name= ’ ’ pos ’ ’><simpleType name= ’ ’ doubleLis t ’ ’>< l i s t itemType= ’ ’ double ’ ’/>

</simpleType></element>

In realta questa e una versione semplificata dell’elemento “pos”, il quale in realtacomprende anche una serie di attributi, di uso opzionale, di riferimento ad unsistema di coordinate:

<attr ibuteGroup name= ’ ’ SRSReferenceGroup ’ ’><a t t r i b u t e name= ’ ’ srsName ’ ’ type = ’ ’anyURI ’ ’

use = ’ ’ opt iona l ’’></ a t t r i bu t e ><a t t r i b u t e name= ’ ’ srsDimension ’ ’ type = ’ ’ p o s i t i v e I n t e g e r ’ ’

use = ’ ’ opt iona l ’’></ a t t r i bu t e ><attr ibuteGroup r e f = ’ ’gml : SRSInformationGroup ’ ’/>

</attr ibuteGroup>

La seguente trattazione riporta le definizioni date ad GML dei costrutti basedelle geometrie. Tutte le seguenti definizioni saranno rese prive di riferimenti atipi astratti, come sono nel documento originale, ma raggruppando la definizionein un unico elemento e considerando le semplificazioni sopra citate: quelle cheriporteremo non saranno le esatte definizioni di GML ma daranno un’idea precisadi come queste sono strutturate.

Definizioni delle geometrie in GML

Punto In GML il punto viene definito come un contenitore per un elemento“pos” nel seguente modo:

<element name= ’ ’ Point ’ ’><simpleType name= ’ ’PointType ’ ’><element r e f = ’ ’gml : pos ’ ’/>

</simpleType></element>

3.5. GML 69

Linea Una linea spezzata e definita come una sequenza di almeno due elementi“pos”:

<element name= ’ ’ L ineStr ing ’ ’><simpleType><element r e f = ’ ’gml : pos ’ ’ minOccurs = ’ ’2 ’ ’

maxOccurs= ’ ’unbounded ’ ’/></simpleType>

</element>

Linea chiusa Una linea chiusa e definita come una sequenza di almeno quattroelementi “pos”:

<element name= ’ ’ LinearRing ’ ’><simpleType><element r e f = ’ ’gml : pos ’ ’ minOccurs = ’ ’4 ’ ’

maxOccurs= ’ ’unbounded ’ ’/></simpleType>

</element>

Il primo e l’ultimo punto devono essere uguali. Questo aspetto non viene codifi-cato ma imposto per costruzione degli elementi.

Poligono e rettangolo Un poligono e definito da massimo una linea chiusache definisce il perimetro esterno e da zero, uno o piu linee chiuse che definisconoil perimetro dei buchi interni:

<element name= ’ ’Polygon ’ ’><complexType><sequence><element r e f = ’ ’gml : e x t e r i o r ’ ’ type = ’ ’gml : LinearRing ’ ’

minOccurs= ’ ’0 ’ ’/><element r e f = ’ ’gml : i n t e r i o r ’ ’ type = ’ ’gml : LinearRing ’ ’

minOccurs = ’ ’0 ’ ’ maxOccurs= ’ ’unbounded ’ ’/></sequence>

</complexType></element>


Come vediamo il poligono e composto da massimo una linea chiusa che definisceil perimetro esterno e da zero, uno o piu linee chiuse che definiscono il perimetrodei buchi interni. Il rettangolo e un caso particolare di poligono, che ha unadefinizione simile senza, pero, la possibilita di introdurre buchi:

<element name= ’ ’ Rectangle ’ ’><complexType><sequence><element r e f = ’ ’gml : e x t e r i o r ’ ’ type = ’ ’gml : LinearRing ’ ’

minOccurs= ’ ’0 ’ ’/></sequence>

</complexType></element>

Si noti come questa definizione differisca da quella tipica, adottata anche daGML nelle sue versioni precedenti, in cui un rettangolo e definito dai suoi angoliin basso a sinistra ed in alto a destra, andando quindi a definire un semplicepoligono privo di buchi e non un rettangolo (che e comunque codificabile conquesto costrutto).

Arco e cerchio L’arco e definito come una serie di tre punti, il primo e l’ultimodei quali rappresentano gli estremi dell’arco stesso:

<element name= ’ ’Arc ’ ’><simpleType><element r e f = ’ ’gml : pos ’ ’

minOccurs = ’ ’3 ’ ’ maxOccurs= ’ ’3 ’ ’/></simpleType>

</element>

La definizione del cerchio e simile a quella dell’arco, cio cambia e l’interpretazionedei tre punti:

<element name= ’ ’ C i r c l e ’ ’><simpleType><element r e f = ’ ’gml : pos ’ ’

minOccurs = ’ ’3 ’ ’ maxOccurs= ’ ’3 ’ ’/></simpleType>

</element>

3.5. GML 71

Questi infatti vengono interpretati come i tre punti necessari ad individuare unacirconferenza univoca.

Capitolo 4

Metodologie di traduzione

In questo capitolo sara proposta una metodologia che descrive come si possa tra-sformare uno schema ChronoGeoGraph (vedi Capitolo 2) in XML Schema (vediCapitolo 3), che possa poi essere istanziato per dare forma ad una base di dati.La scelta di utilizzare XML Schema e di fatto una scelta obbligata, vista l’assen-za nei DTD di costrutti che consentano di definire vincoli appropriati (e viste lepotenzialita e la flessibilita di XML Schema).La prima sezione sara dedicata al trattamento dei costrutti del modello En-tita/Relazioni e del costrutto di specializzazione del modello Entita/RelazioniEsteso.La seconda sezione avra quale oggetto i costrutti introdotti dal modello Chrono-GeoGraph, partendo da quelli relativi alla modellazione dei dati spaziali, per poipassare a quelli relativi alla gestione delle dimensioni temporali dei dati.

4.1 Traduzione degli schemi E/R

Nonostante la presenza in XML Schema di un costrutto quale “attribute”, talecostrutto non verra utilizzato per codificare gli attributi delle entita. La sceltadel costrutto “element” consente infatti di definire adeguatamente attributi sem-plici, composti e multivalore.Anche l’eventualita, suggerita dalla struttura modulare di XML Schema, di defi-nire una relazione come un elemento di tipo complesso, i cui componenti rappre-sentino gli insiemi delle istanze delle diverse entita tra loro in relazione, non puoessere utilizzata come unica metodologia di traduzione. In tal caso, infatti, nonsarebbe possibile tradurre un’entita che partecipi a due o piu relazioni, perche lesue istanze dovrebbero appartenere contemporaneamente a due o piu elementi

73

74 CAPITOLO 4. METODOLOGIE DI TRADUZIONE

XML.Di seguito si descrive in dettaglio la codifica di ogni costrutto del modello ER inschemi XML Schema.

4.1.1 Il documento di schema

Il documento che si andra a costruire dovra rispettare tutte le norme imposteai documenti XML Schema e dovra, inoltre, contenere un elemento simbolicoconvenzionale che fungera da contenitore per l’intero schema.

<?xml ve r s i on = ‘ ‘1.0 ’ ’? ><xs : schema xmlns= ‘ ‘ http ://www.w3 . org /2001/XML Schema ’ ’targetNamespace = ‘ ‘ er−example ’ ’ xmlns : e r = ‘ ‘ er−example ’ ’elementFormDefault = ‘ ‘ q u a l i f i e d ’ ’>

<xs : element name= ‘ ‘Schema ’ ’><xs : complexType><xs : sequence>. . . d e f i n i z i o n e d e g l i e l ement i d e l l o schema . . .</xs : sequence>


</xs : schema>

Le prime 4 e l’ultima riga, rispettivamente, indicano l’inizio e la fine dello schemaXML Schema (vedi Capitolo 3).

4.1.2 Entita e attributi

Per creare un documento XML Schema che rappresenti uno schema ER di par-tenza, per ogni entita dello schema ER si puo definire un “element”, dichiaratocome “complexType”, il cui “name” sia quello dell’entita.Supponendo di avere un entita Impiegato, i cui attributi sono: nome, cognome,stipendio. L’entita puo essere definita come segue:

<xs : element name= ‘ ‘ impiegato ’ ’minOccurs=”0” maxOccurs= ‘ ‘unbounded ’ ’>

<xs : complexType>. . .

4.1. TRADUZIONE DEGLI SCHEMI E/R 75


Per ogni entita tradotta e necessario specificare, una cardinalita minima pari azero ed una cardinalita massima illimitata, altrimenti lo schema consentira lapresenza di un’unica istanza di tale elemento (e ovviamente possibile forzare loschema imponendo altre cardinalita minime, ad esempio 1, o massime). In XMLSchema un elemento di tipo complesso (padre) viene definito come una sequenzadi sotto-elementi (figli) e quindi ogni attributo dell’entita puo essere definitocome uno degli “element” interni di “sequence”.


<xs : complexType><xs : sequence><xs : element name= ‘ ‘nome ’ ’ type = ‘ ‘ xs : s t r i ng ’ ’ /><xs : element name= ‘ ‘ cognome ’ ’ type = ‘ ‘ xs : s t r i ng ’ ’ /><xs : element name= ‘ ‘ s t ipend io ’ ’ type = ‘ ‘ xs : i n t ege r ’ ’ />

</xs : sequence></xs : complexType>

</xs : element>

Gli attributi derivati non sono codificabili direttamente in XML Schema poi-che non c’e modo di imporre il loro aggiornamento automatico. L’unica alter-nativa rimane quella di tradurli come attributi semplici e gestirne la modificamanualmente. Se tali attributi vengono codificati come attributi normali pos-sono creare incongruenze, come accadrebbe nell’esempio mostrato in Figura ??: in questo caso, infatti, un tale attributo necessiterebbe di un aggiornamentocostante. Cio avviene in quanto essi costituiscono un’informazione ridondante,ma proprio per la stessa ragione l’impossibilita di codificare gli attributi derivatipuo essere considerata non grave.

La definizione degli attributi sopra data e abbastanza libera, tuttavia XMLSchema permette di dichiarare in modo piu preciso gli elementi semplici, co-me ad esempio “stipendio”, introducendo delle restrizioni sui valori che possonoassumere. E possibile infatti sostituire, ad esempio, la riga:

<xs : element name= ‘ ‘ s t ipend io ’ ’ type = ‘ ‘ xs : i n t ege r ’ ’ />


con una definizione piu restrittiva dell’elemento:

<xs : element name= ‘ ‘ s t ipend io ’ ’><xs : simpleType><xs : r e s t r i c t i o n base = ‘ ‘ xs : i n t ege r ’ ’><xs : min Inc lu s ive va lue = ‘ ‘0 ’ ’/>


</xs : element>

Allo stesso modo e possibile inserire, all’interno delle definizioni degli attributidell’entita altre restrizioni per assicurare la consistenza dei dati inseriti.Con XML Schema e possibile codificare in modo relativamente semplice gli attri-buti composti. Volendo aggiungere all’entita “impiegato” l’attributo “indirizzo”composto da “via”, “numero” e “C.A.P.”, basta inserire nella definizione del tipocomplesso “impiegato” il seguente elemento:

<xs : element name= ‘ ‘ i n d i r i z z o ’ ’><xs : complexType><xs : sequence><xs : element name= ‘ ‘ via ’ ’ type = ‘ ‘ xs : s t r i ng ’ ’/><xs : element name= ‘ ‘numero ’ ’ type = ‘ ‘ xs : i n t ege r ’ ’/><xs : element name= ‘ ‘ cap ’ ’ type = ‘ ‘ xs : s t r i ng ’ ’/>


</xs : element>

Si puo inoltre dichiarare un numero minimo ed un numero massimo di occorrenzedi un sotto-elemento.Se si volesse modellare il numero di cellulare come attributo opzionale, e sufficientedefinire un elemento interno in questo modo:

<xs : element name= ‘ ‘ t e l e f o n oCe l l u l a r e ’ ’ type = ‘ ‘ xs : s t r i ng ’ ’minOccurs= ‘ ‘0 ’ ’/>

Allo stesso modo diventa possibile modellare un attributo multivalore. Ad esem-pio i possibili numeri di telefono fisso associati all’impiegato, sono cosı descrivibili:


<xs : element name= ‘ ‘ t e l e f onoF i s s o ’ ’ type = ‘ ‘ xs : s t r i ng ’ ’maxOccurs= ‘ ‘unbounded ’ ’/>

se l’attributo non e opzionale, oppure:

<xs : element name= ‘ ‘ t e l e f onoF i s s o ’ ’ type = ‘ ‘ xs : s t r i ng ’ ’minOccurs = ‘ ‘0 ’ ’ maxOccurs= ‘ ‘unbounded ’ ’/>

se l’attributo e opzionale.

Partendo, dunque, dall’esempio di schema ER in Figura 4.1 il documento che

Figura 4.1: Entita “Impiegato”

andremo a definire sara il seguente:


<xs : element name= ‘ ‘ SchemaImpiegato ’ ’>



</xs : schema>

Vincolo di chiave

Una trattazione a parte merita l’argomento delle chiavi. In XML Schema epossibile definire delle vere e proprie chiavi composte da uno o piu attributidell’entita a cui si riferiscono.La sintassi e la seguente:

<xs : key name = ‘ ‘ . . . ’ ’ ><xs : s e l e c t o r xpath = ‘ ‘ . . . ’ ’ / ><xs : f i e l d xpath = ‘ ‘ . . . ’ / ’ >

. . .<xs : f i e l d xpath = ‘ ‘ . . . ’ ’ / >

</xs : key>

Questa dichiarazione deve essere esterna all’elemento a cui la chiave si riferisce(nel nostro caso “Impiegato”) e richiama quest’ultimo indicandone il nome nel-l’attributo “xpath” del “selector”. Diversamente da quest’ultimo, che e unicoall’interno della dichiarazione della chiave, “key” puo contenere piu “field” chefanno riferimento ai sotto-elementi dell’elemento indicato dal “selector”, e cheper noi sono gli attributi dell’entita a cui si riferisce la chiave.Per completare l’esempio precedente, supponendo che “Impiegato” abbia comechiave “nome” e “cognome”, si dovra aggiungere all’interno dello “schema”, maall’esterno dell’elemento “Impiegato”, la dichiarazione “key” nel seguente modo:


<xs : element name= ‘ ‘ SchemaImpiegato ’ ’><xs : complexType><xs : sequence>


Figura 4.2: Entita “Impiegato”, con chiave “nome” e “cognome”


. . .</xs : element>

<xs : key name= ‘ ‘ ChiaveImpiegato ’ ’ ><xs : s e l e c t o r xpath= ‘ ‘ impiegato ’ ’/><xs : f i e l d xpath= ‘ ‘nome’ ’/><xs : f i e l d xpath= ‘ ‘ cognome ’ ’/></xs : key>


</xs : schema>

In questo modo sarebbe possibile dichiarare piu chiavi per la stessa entita, sem-plicemente aggiungendo le relative dichiarazioni “key”.

Altri vincoli

Nella definizione dello schema di una base di dati e spesso utile inserire ulteriorivincoli al fine di mantenere la coerenza dei dati inseriti. Di seguito vengono


riportati alcuni utili vincoli disponibili in XML Schema:

• unique - Con questo vincolo si puo richiedere l’unicita dei valori di un datoelemento (o di un insieme di elementi) all’interno di un campo di validita:

<xs : unique name = ‘ ‘ . . . ’ ’ ><xs : s e l e c t o r xpath = ‘ ‘ . . . ’ ’ / ><xs : f i e l d xpath = ‘ ‘ . . . ’ ’ / >

. . .<xs : f i e l d xpath = ‘ ‘ . . . ’ ’ / >

</xs : unique>

La sintassi e la semantica sono del tutto simile a quella del vincolo di chiaveed anche la posizione richiesta e la stessa (all’esterno del elemento che fungeda campo di validita).

• nillable - Questo vincolo esprime un valore opposto rispetto al vincolo“not null” presente in SQL:

<xs : element name = ‘ ‘ . . . ’ ’ type = ‘ ‘ . . . ’ ’n i l l a b l e = ‘ ‘ true ’ ’/>

Il valore di default e “false”, quindi, se non specificato, ogni elemento deveavere un valore. Specificando il valore “true” l’elemento puo assumere ilvalore nullo (ovvero, non e necessario inserire un valore per ogni istanza).

• default - Con questo vincolo e possibile definire un valore di default chel’elemento assume in mancanza di un valore specifico dato all’istanza. L’ar-gomento di “default” e una stringa.

<xs : element name = ‘ ‘ . . . ’ ’ type = ‘ ‘ . . . ’ ’d e f au l t = ‘ ‘ . . . ’ ’ / >

Si possono in oltre esprimere altri tipi di vincoli (oltre a quelli sopra citati, chesono i piu usati nel campo delle basi di dati) come abstract, block, final, fixed edaltri piu complessi, tutti inseriti nella dichiarazione dell’elemento come “nillable”e “default”, che qui non verranno approfonditi.


4.1.3 Relazioni

Grazie ad alcuni costrutti introdotti in XML Schema, la definizione delle rela-zioni risulta sufficientemente semplice e piuttosto simile a quella adottata nelpassaggio da schemi ER a schemi relazionali. Tuttavia XML permette di adot-tare tecniche diverse, non applicabili agli schemi relazionali.Usando il costrutto “keyref” e possibile dichiarare che alcuni sotto-elementi sonoriferimenti ad una specifica chiave di un altro elemento. Si definisce quindi unachiave esterna.Riprendendo l’esempio dell’entita “Impiegato”, arricchito con l’entita “Diparti-mento” e la relazione “Lavora” come in Figura 4.3.Il documento XML Schema relativo risulta essere il seguente:

Figura 4.3: Entita “Impiegato” e “Dipartimento”




<xs : complexType>


Tuttavia, questo non e l’unico modo in cui si puo descrivere lo schema ER inFigura 4.3. Di seguito si puo vedere com’e possibile tradurre lo schema ER,inserendo l’intero elemento “impiegato” all’interno dell’elemento “dipartimento”mantenendo intatti tutti i vincoli:



<xs : element name= ‘ ‘ dipart imento ’ ’minOccurs=”0” maxOccurs= ‘ ‘unbounded ’ ’>


<xs : element name= ‘ ‘nome ’ ’ type = ‘ ‘ xs : s t r i ng ’ ’/>

<xs : element name= ‘ ‘ impiegato ’ ’ maxOccurs= ‘ ‘unbounded ’ ’><xs : complexType><xs : sequence>. . .</xs : sequence></xs : complexType></xs : element>

<xs : key name= ‘ ‘ ChiaveImpiegato ’ ’ ><xs : s e l e c t o r xpath= ‘ ‘ impiegato ’ ’/><xs : f i e l d xpath= ‘ ‘nome’ ’/><xs : f i e l d xpath= ‘ ‘ cognome ’ ’/>

</xs : key>


<xs : key name= ‘ ‘ ChiaveDipartimento ’ ’ >


<xs : s e l e c t o r xpath= ‘ ‘ dipart imento ’ ’/><xs : f i e l d xpath= ‘ ‘nome’ ’/>

</xs : key>


</xs : schema>

In questo modo ogni “dipartimento” ha al suo interno uno o piu impiegati. Nelcaso in cui, nell’istanza della base di dati definita, sia necessario registrare uncambio di dipartimento da parte di un impiegato si sarebbe obbligati “spostare”l’istanza dell’entita “impiegato” all’interno dell’istanza dell’entita “dipartimen-to” che rappresenta il nuovo dipartimento a cui tale impiegato appartiene. Nonsarebbe possibile, pero, delineare un tale schema nel caso in cui l’entita “impie-gato” partecipasse alla relazione solo parzialmente, e vi sia la possibilita che cisiano impiegati che non fanno parte di alcun dipartimento.Date le cardinalita di partecipazione di due entita ad una relazione, e possibileidentificare diversi tipi di relazioni, come descritto in Figura 2.6, e per ognunodefinire un’adatta metodologia di traduzione.

• casi 1 e 2 - Si puo tradurre le relazioni in due modi, come nell’esempioprecedente, o con una chiave esterna in A riferita a B o includendo A in B.In particolare nel caso 2, se si usa una chiave esterna (il primo metodo), enecessario dichiarare “unique”, rispetto ad A, il sotto-elemento che formala chiave esterna, per mantenere il vincolo di cardinalita massima pari ad 1per le istanze di B (il vincolo non esprime il limite minimo di partecipazionealla relazione, pari ad 1, per le istanze di B). Riguardo il secondo metodo,nel caso 1 e necessario specificare l’occorrenza massima come “unbounded”.Nel caso 2, inoltre, e possibile definire un elemento per R (minOccurs “0”,maxOccurs “unbounded”) che conterra un sottoelemento per A ed uno perB, entrambi unici ed obbligatori.

• casi 3 e 4 - E necessario l’utilizzo di una chiave esterna in A riferitaa B, dato che B partecipa in maniera parziale ad R. Inoltre, nel caso 3,sara necessario dichiarare “unique”, rispetto ad A, l’elemento che forma lachiave esterna per mantenere il vincolo di cardinalita 0:1; in alternativa epossibile includere A in B come nei casi precedenti, specificando pero unaoccorrenza minima pari a 0.


• casi 5 e 6 - Si puo inserire una chiave esterna in A riferita a B. In tali casi,l’elemento che funge da chiave esterna deve avere “maxOccurs” pari ad“unbounded” (in questo caso, se la chiave dell’entita B e composta da piuattributi e possibile dichiarare in A un elemento astratto come contenitoredegli elementi della chiave) Nel caso 5 e inoltre necessario dichiarare “uni-que”, rispetto ad A, l’elemento che forma la chiave esterna per mantenereil vincolo di cardinalita 0:1.

• caso 7 - E molto simile ai due casi precedenti, ma essendo necessario spo-stare la relazione su una delle due entita (per esempio A), tramite un vincolodi chiave esterna (in questo caso riferita dunque a B), uno dei due vincolidi cardinalita non risulta codificabile rispetto al limite minimo (ovvero, ilvincolo non esprime il limite minimo di partecipazione alla relazione, pa-ri ad 1, per le istanze di B). Una soluzione a quest’ultimo problema puoessere l’utilizzo di riferimenti incrociati: una chiave esterna in A riferita aB ed una chiave esterna in B riferita ad A. Questo risolve il problema, madiventa piu difficile da gestire, in quanto introduce una ridondanza.

• casi 8, 9 e 10 - Si puo inserire una chiave esterna in una delle due entita chefaccia riferimento all’altra all’altra oppure si puo anche creare un elementoR (specificando minOccurs=0 e maxOccurs=“unbounded” ) composto daun sotto-elemento per A ed uno per B, dichiarando quest’ultimo “unique”se l’entita partecipa con cardinalita 0:1 (entrambe nel caso 8).

Entita deboli

La gestione di entita deboli risulta di facile gestione. Le relazioni identificanti,collegate all’entita deboli, hanno, infatti, sempre un collegamento con cardinalita1:1 ed un collegamento con cardinalita 0:n o 1:n, rientrando quindi in uno dei casiprecedentemente identificati come 1 e 4. Riducendoci, dunque, alle traduzioniprecedentemente descritte, rimane semplicemente da inserire l’elemento che fungeda chiave esterna all’interno della lista di elementi del costrutto “key” dell’entitadebole. Anche il metodo “dell’inclusione” risulta essere particolarmente sempliceed efficace nella traduzione di questi costrutti.In una situazione simile a quella dell’esempio “Impiegato-Dipartimento” (vedianche caso 1 Figura 2.6), se si utilizza il secondo metodo, l’entita debole e partedell’elemento che fornisce l’identificatore esterno, ed essendo quindi integrata nonnecessita di ulteriori modifiche.


Figura 4.4: Relazione multipla

, che, in una struttura cosı definita, non possono esistere al di fuori dell’entitada cui dipendono.

Relazioni multiple

Per la gestione delle relazioni multiple (che coinvolgono piu di 2 entita), la soluzio-ne piu semplice e quella di creare un elemento apposito che codifichi la relazionestessa cercando di mantenere il piu possibile i vincoli imposti nello schema ER.Per codificare, ad esempio, lo schema proposto in Figura 4.4, si puo creare unelemento “fornisce” che contiene un sotto-elemento per ciascuna delle entita coin-volte. Ciascuno dei sotto-elementi deve essere dichiarato come “keyref”, e devecontenere i riferimenti agli attributi che compongono la chiave di ciascuna entita.In fine, bisogna aggiungere la definizione della chiave di “fornisce” per mantenerei vincoli di integrita.Lo schema in Figura4.4, rappresenta la situazione in cui, per ogni coppia progetto-componente si avra un solo fornitore che fornisce quella componente a quel pro-getto. La nostra chiave sara quindi la coppia progetto-componente, data la qualepotremo identificare univocamente un solo fornitore.

Una alternativa puo essere quella di spostare l’intera relazione su una delleentita coinvolte, usando comunque dei riferimenti a chiave (keyref). Si potreb-be, ad esempio, aggiungere all’elemento “progetto” un sotto-elemento “fornitore”(con cardinalita massima “unbounded” e dichiarato keyref), il quale a sua voltaconterrebbe un sotto-elemento “componente”(con cardinalita massima “unboun-ded” e dichiarato keyref); si verrebbe cosı a creare un albero che partendo dalsingolo progetto descriverebbe, per ogni fornitore, i componenti che esso fornisceal progetto stesso. Allo stesso modo, si potrebbe ampliare la definizione di “for-


nitore” con un sotto-elemento “progetto” (con cardinalita massima “unbounded”e dichiarato keyref), che a sua volta conterrebbe un sotto-elemento “componen-te” (con cardinalita massima “unbounded” e dichiarato keyref); in questo casol’albero avrebbe come nodo di partenza il fornitore.La scelta tra queste ultime due opzioni dipende dall’utilizzo della base di dati;a seconda di chi e come lo utilizza si puo rivelare piu conveniente l’una o l’altraopzione.Lo stesso tipo di metodologia si puo anche utilizzare includendo gli elementi gliuni dentro gli altri, invece che utilizzando i riferimenti alle chiavi, facendo peroattenzione al fatto che nessuna delle entita definite come sotto-elementi non siaa partecipazione parziale.

Attributi delle relazioni

L’aggiunta di attributi alle relazioni e di semplice soluzione:

• se si utilizzano riferimenti a chiavi, basta aggiungere un sotto-elemento, cherappresenta l’attributo della relazione;

• se si utilizza il metodo dell’inclusione, l’attributo puo essere spostato sul-l’entita “inclusa”.

4.1.4 Specializzazioni

In una relazione di specializzazione, le entita figlie ereditano dall’entita padretutti gli attributi. La specializzazione puo essere totale o parziale oltre che di-sgiunta o con sovrapposizione.In generale le specializzazioni verranno tradotte aggiungendo gli attributi del-le entita figlie all’entita padre. Di seguito vengono trattati i diversi casi dispecializzazione.

Specializzazione disgiunta

Le istanze dell’entita padre sono suddivise in insiemi disgiunti e tutte le istanzedell’entita padre appartengono a uno di tali insiemi. In un caso come quellorappresentato in Figura 4.5, puo essere utilizzato il costrutto xs:choice, che cipermette di elencare una serie di sotto-elementi mutualmente esclusivi. Si puoquindi utilizzare il seguente schema:


Figura 4.5: Esempio di specializzazione totale disgiunta

<xs : element name= ‘ ‘ persona ’ ’minOccurs=”0” maxOccurs= ‘ ‘unbounded ’ ’>

<xs : complexType><xs : sequence><xs : element name= ‘ ‘ c od i c eF i s c a l e ’ ’ type = ‘ ‘ xs : s t r i ng ’ ’/><xs : cho ice><xs : element name= ‘ ‘uomo’ ’/><xs : element name= ‘ ‘donna ’ ’/>

</xs : cho ice></xs : sequence></xs : complexType>

</xs : element>

Per semplicita, nell’esempio, “Uomo” e “Donna” non hanno attributi ne tipo,e potrebbero sembrare di poca utilita, ma anche cosı danno la possibilita diaggiungere un tag:

<uomo/> oppure <donna/>

che identifichi le varie istanze di persona come appartenenti all’uno o all’altro in-sieme. Diventa naturalmente semplice aggiungere attributi o vincoli all’interno


Figura 4.6: Esempio di specializzazione parziale con sovrapposizione

delle entita figlie, dichiarandole come per ogni altro elemento; e inoltre possi-bile definire gli elementi all’interno di “choice” in modo da creare relazioni lacui partecipazione sia riservata agli elementi di uno solo dei due insiemi, oppuredichiarare le relazioni al di fuori di “choice” in modo tale che tutte le istanzedell’entita padre “Persona” vi possano partecipare.

Se la specializzazione e disgiunta ma parziale, ovvero non tutte le istanze del-l’entita padre appartengono ad una delle entita figlie, basta definire opzionale ilcostrutto “choice”, che diventera:

<xs : cho i c e minOccurs= ‘ ‘0 ’ ’>. . .</xs : cho ice>

Specializzazione con sovrapposizione

Nella specializzazione con sovrapposizione, la possibilita che un’istanza partecipia nessuna, una o piu di una delle entita figlie, impedisce di utilizzare il costrutto“choice”. Non rimane che dichiarare dei sotto-elementi opzionali, perdendo perola possibilita di distinzione tra specializzazioni totali e parziali.In Figura 4.6 e rappresentata una specializzazione parziale con sovrapposizione

4.2. TRADUZIONE DI SCHEMI CHRONOGEOGRAPH 91

che puo essere tradotta come segue:

<xs : element name= ‘ ‘ persona ’ ’minOccurs=”0” maxOccurs= ‘ ‘unbounded ’ ’>

<xs : complexType><xs : sequence><xs : element name= ‘ ‘ c od i c eF i s c a l e ’ ’ type = ‘ ‘ xs : s t r i ng ’ ’/><xs : element name= ‘ ‘ l avo ra to r e ’ ’

minOccurs=”0” maxOccurs= ‘ ‘unbounded ’ ’><xs : complexType><xs : sequence><xs : element name= ‘ ‘ dataAssunzione ’ ’ type = ‘ ‘ xs : date ’ ’/>


</xs : element><xs : element name= ‘ ‘ studente ’ ’

minOccurs=”0” maxOccurs= ‘ ‘unbounded ’ ’/><xs : complexType><xs : sequence><xs : element name= ‘ ‘ matr ico la ’ ’ type = ‘ ‘ xs : i n t ege r ’ ’/>


</xs : element>


</xs : element>

Ogni persona puo essere dichiarata come lavoratore, come studente, come studente-lavoratore oppure puo non appartenere a nessuno dei due insiemi.Purtroppo, non e possibile vincolare lo schema in modo che sia presente almenouna delle due dichiarazioni come chiesto nel caso di una specializzazione totale.

4.2 Traduzione di schemi ChronoGeoGraph

In questa sezione la metodologia di traduzione in XML Schema proposta saraestesa ai costrutti del modello ChronoGeoGraph. La prima parte trattera gliaspetti spaziali, mentre la seconda si concentrera su quelli temporali.


4.2.1 Trattamento dei dati spaziali

Entita georeferenziate

Le entita georeferenziate si differenziano dalle entita semplici, precedentementetrattate, per la presenza di una attributo di tipo geometrico.Come visto nella sezione 3.5, GML propone uno standard per la definizione digeometrie in XML. In particolare mette a disposizione strutture per la codificain XML di punti, linee, poligoni, ed altre geometrie di base, che possono essereutilizzate per la traduzione delle entita georeferenziate.Un’entita georeferenziata puo, dunque, essere tradotta in modo analogo a quellodelle entita non georeferenziate. A tale traduzione, infatti, e sufficiente aggiunge-re un xs:element che faccia riferimento alla definizione della geometria specificatanello schema concettuale. In particolare, nei seguenti esempi, tali elementi ver-ranno raccolti in un sottoelemento chiamato “geometry” (il cui nome e del tuttoarbitrario), che raccogliera tutti i dati riguardanti la definizione dell’attributo ditipo geometrico.Prendendo ad esempio, un’entita georeferenziata “fiume”, la cui geometria e unalinea, si andrebbe ad effettuare la seguente traduzione:

<element name= ’ ’ fiume ’ ’minOccurs=”0” maxOccurs= ‘ ‘unbounded ’ ’>

<xs : complexType><xs : sequence><xs : element name= ‘ ‘ geometry ’ ’><xs : complexType><xs : sequence><xs : element r e f = ‘ ‘gml : L ineStr ing ’ ’/>


</xs : element></xs : sequence></xs : complexType>

</xs : element>

Se la geometria dell’entita “fiume” fosse “multiline” sarebbe necessario modificarela definizione del relativo elemento nel seguente modo:

<xs : element name= ’ ’ fiume ’ ’minOccurs=”0” maxOccurs= ‘ ‘unbounded ’ ’>


<xs : complexType><xs : sequence><xs : element name= ‘ ‘ geometry ’ ’><xs : complexType><xs : sequence><xs : element r e f = ‘ ‘gml : Mult iL ineStr ing ’ ’ />

</xs : sequence></complexType>


</xs : element>

GML fornisce, infatti, costrutti atti a definire insiemi di geometrie come “gml:MultiPoint”,“gml:MultiLineString”, “gml:MultiPolygon” e “gml:MultiCurve”. Per quanto ri-guarda, invece, attributi geometrici di tipo “collection”, GML propone il costrut-to “gml:MultiGeometry”, definito come un insieme di tutti i tipi di geometriepreviste da GML stesso. Con quest’ultimo costrutto e anche possibile codificareil tipo “other”, previsto dal modello ChronoGeoGraph.

<xs : element name= ‘ ‘ geometry ’ ’><xs : complexType><xs : sequence><xs : element r e f = ‘ ‘gml : MultiGeometry ’ ’ />


</xs : element>

Per poter inserire i riferimenti ai tipi geometrici definiti da GML, e necessariodefinire i namespace XML come segue:

<xs : schema xmlns= ‘ ‘ http ://www.w3 . org /2001/XML Schema ’ ’xmlns : gml= ‘ ‘ http ://www. openg i s . net /gml ’ ’>

Inoltre, e necessario dichiarare l’importazione delle definizioni dei tipi geometrici:

<import namespace= ‘ ‘ http ://www. openg i s . net /gml ’ ’schemaLocation = ‘ ‘ . . / geometryComplexes . xsd ’ ’ /


Relazioni topologiche

Allo stato dell’arte, i controlli necessari alla verifica dei vincoli topologici esulanodalle capacita di un validatore XML, e non sono quindi codificabili. Si tratterebbedi effettuare il calcolo della geometria di ogni istanza e di controllare i vincoliimposti su ognuna di esse.L’unico sistema di traduzione e quello di definire delle relazioni semplici, sullequali sara poi necessario effettuare dall’esterno un controllo di validita. In questocontesto, per differenziare i vari tipi di relazione topologica, puo essere aggiunto,come sottoelemento obbligatorio all’elemento che rappresenta la relazione, unodei seguenti costrutti:

<xs : element name=”d i s g i un z i on e ”/>

<xs : element name=”adiacenza”/>

<xs : element name=”uguag l ianza”/>

<xs : element name=” i n c l u s i o n e ”/>

<xs : element name=”copertura”/>

<xs : element name=”sov rappo s i z i oneBord iD i s g iun t i ”/>

<xs : element name=”sov r appo s i z i on e In t r s e z i on eBo rd i ”/>

Ogni istanza ha quindi al suo interno lo stesso tag che contraddistingue il tipodi relazione topologica, ad esempio:

<d i s g i un z i on e/>

Specializzazione cartografica

La traduzione di questi costrutti non differisce da quella data nel capitolo pre-cedente. In particolare si descrivono di seguito le metodologie di traduzioneutilizzabili nei due casi di specializzazione cartografica.

• Variazione di forma: in questo caso e possibile utilizzare la metodologiaindicata per le specializzazioni totali sovrapposte; imponendo l’obbligato-


rieta degli elementi che codificano le geometrie, in modo che l’entita lecomprendera necessariamente entrambe.

• Variazione di scala: in questo caso e possibile utilizzare la metodologiaindicata per le specializzazioni totali disgiunte; in tal modo ogni istanzapotra comprendere una sola delle geometrie delle sottoclassi.

Aggregazione

L’aggregazione di tipo semplice puo essere tradotta attraverso dei riferimenti allachiave o includendo le definizioni delle entita parti come sottoelementi dell’en-tita intero. Ad esempio un’aggregazione come quella in Figura 2.18 puo esserecodificata aggiungendo all’elemento “squadra” i seguenti sottoelementi:

• “giocatore”, con “minOccurs” pari a 9 e “maxOccurs” pari a 15;

• “allenatore”, obbligatorio (“minOccurs” 1, “maxOccurs” 1);

• “assistente”, opzionale (“minOccurs” 0, “maxOccurs” 1).

La metodologia di traduzione dell’aggregazione spaziale e uguale alla precedente,e cio vale anche per l’aggregazione semantica, in quanto la verifica del rispettodei vincoli geometrici, imposti all’aggregazione spaziale, deve essere verificata“dall’esterno”.

Territorio di schema

Il territorio di schema puo essere tradotto come un elemento direttamente discen-dente dell’elemento che rappresenta lo schema che puo avere un unica istanza.Tale elemento ha una geometria definita in modo analogo a quanto visto per leentita georeferenziate e, come per i casi precedenti, il vincolo di inclusione dellegeometrie dello schema rispetto alla geometria del territorio di schema non eimponibile con i soli costrutti di XML Schema.Di seguito viene riportata la traduzione del territorio di schema in Figura 2.21.

<xs : element name= ’ ’ t sF r i u l iVene z i aG iu l i a ’ ’><xs : complexType><xs : sequence><xs : element name= ‘ ‘ geometry ’ ’>. . . d e f i n i z i o n e d e l l a geometr ia . . .</xs : element>



</xs : element>

Campi

I campi possono essere trattati come dei sottoelementi dell’entita a cui si riferi-scono o del territorio di schema. La relazione di inclusione imposta alle geometrieche definiscono i campi rispetto al territorio di schema o all’entita a cui fanno rife-rimento, come tutte le altre relazioni topologiche, non puo essere gestita in XMLschema e nel caso fossero definiti attributi derivati dai campi, come descritto nelCapitolo 2.2.1, il valore di tali attributi non potra essere gestito automaticamentesalvo utilizzo di strumenti esterni.La traduzione di un campo “Temperatura” associato all’entita “Provincia” comequello descritto in Figura 2.21 puo essere la seguente:

<xs : element name= ’ ’ prov inc ia ’ ’minOccurs=”0” maxOccurs= ‘ ‘unbounded ’ ’>

<xs : complexType><xs : sequence>. . .<xs : element name= ‘ ‘ campoTemperatura ’ ’><xs : complexType><xs : sequence><xs : element name= ‘ ‘ sample ’ ’

maxOccurs= ‘ ‘unbounded ’ ’><xs : complexType><xs : sequence><xs : element name= ‘ ‘ value ’ ’><xs : simpleType><xs : r e s t r i c t i o n base=”xs : double”><xs : min Inc lu s ive va lue=”−273.15”/></xs : r e s t r i c t i o n >

</xs : simpleType></xs : element><xs : element name= ‘ ‘ geometry ’ ’><xs : element r e f = ‘ ‘gml : Point ’ ’/>

</xs : element></xs : sequence>


</complexType></xs : element>


</xs : element>. . .

<xs : element name= ‘ ‘ temperatura ’ ’>. . . d e f i n i z i o n e de l l ’ a t t r i bu t o ‘ ‘ der ivato ’ ’ temperatura . . .</xs : element>. . .


</xs : element>

Il sottoelemento che rappresenta il campo contiene una serie (a cui e possibileovviamente imporre dei limiti di cardinalita) di “sample” (dall’inglese “campio-ne”, come per altri casi la scelta del nome e del tutto arbitraria) a loro voltacomposti da un valore associato ad una geometria.Nell’esempio, la temperatura era campionata da un insieme irregolare di punti,quindi “campoTemperatura” raccoglie un insieme di “sample” per ognuno deiquali la “geometry” e definita da un punto (definito come per le entita geome-triche), mentre il “value” e un “double”. Se il campo fosse stato definito da“isolinee”, la geometria di ogni “sample” sarebbe stata la linea, come nel casodelle TIN; nel caso dei poligoni e della griglia regolare di celle la geometria basesarebbe stata il poligono.I vincoli sottintesi nel tipo di campionamento applicato ai campi, come nel cam-pionamento regolare di punti, nelle poligoni e nelle celle non possono essere co-dificati direttamente ma necessitano di un controllo esterno. Nel caso di campidefiniti sul territorio di schema (non relativi, quindi, ad una singola entita), questipossono essere inclusi come sottoelementi dell’elemento rappresentante lo stessoterritorio di schema.

4.2.2 Trattamento dei dati temporali

In questa sono presi in considerazione i costrutti temporali introdotti dal modelloChronoGeoGraph.E importante sottolineare che tutti i vincoli temporali come, ad esempio, il fattoche l’istante iniziale sia precedente all’istante finale di un certo intervallo, nonsono codificabili.


Entita con supporto temporale

Alle entita possono essere associati diverse dimensioni temporali: il lifespan, iltempo di transazione,il tempo dell’evento ed il tempo di disponibilita.

Lifespan Nel caso in cui ad una entita sia associato un lifespan, e necessariodefinire un sottoelemento dell’elemento che rappresenta l’entita, che descrive ildiagramma di stato associato:

<xs : element name= ‘ ‘ l i f e s p an ’ ’><xs : complexType><xs : sequence><xs : element name= ‘ ‘ h i s t o r i c a lVa l u e ’ ’

maxOccurs= ‘ ‘unbounded ’ ’><xs : complexType><xs : sequence>

<xs : element name= ‘ ‘ value ’ ’><xs : simpleType><xs : r e s t r i c t i o n base=”xs : s t r i n g”><xs : enumeration value=”Scheduled”/><xs : enumeration value=”Active”/><xs : enumeration value=”Ina c t i v e ”/><xs : enumeration value=”Dead”/>


</xs : element>


</xs : element><xs : a t t r i bu t e name= ‘ ‘ startTime ’ ’

type = ‘ ‘ xs : dateTime ’ ’/><xs : a t t r i bu t e name= ‘ ‘endTime ’ ’

type = ‘ ‘ xs : dateTime ’ ’ use = ‘ ‘ opt iona l ’ ’/></xs : sequence></xs : complexType>

</xs : element>


L’elemento “lifespan” contiene al suo interno una serie di sottoelementi “histo-ricalValue” che memorizzano i diversi stati in cui l’entita si puo trovare durantela sua vita. Ogni “historicalValue” e a sua volta composto da un sottoelemento“value”, che indicano il valore dello stato. Gli attributi dell’elemento “historical-Value” indica rispettivamente l’istante di inizio e l’istante di fine dell’intervallodi tempo in cui l’entita si trova in tale stato nella realta modellata. Il diagrammadescritto nell’esempio e quello di “default”, nel caso in cui ad una data entita consupporto temporale lifespan sia collegato uno specifico diagramma di stati, ba-stera sostituire i nomi degli stati quelli dello specifico diagramma. E importantesottolineare che tale definizione non permette pero di monitorare la correttezzadel passaggio da uno stato ad un altro secondo le regole definite dal diagrammaa stati.

Tempo di transazione Il tempo di transazione indica l’intervallo di tempo incui, nella base di dati, una data entita si trova in un certo stato. Tale aspettotemporale puo essere tradotto memorizzando l’istante in cui il valore dello statoviene modifica nella base di dati.Si devono quindi aggiungere, nella definizione dell’elemento “historicalValue” dueattributi: il primo per memorizzare l’istante in cui tale valore viene inserito; ilsecondo, dichiarato opzionale in quanto non definibile per il valore corrente dellostato, per memorizzare l’istante in cui lo stato dell’entita viene modificato ed ilvalore in questione non e piu valido nella base di dati.

<xs : element name= ‘ ‘ l i f e s p an ’ ’><xs : complexType><xs : sequence>

<xs : element name= ‘ ‘ h i s t o r i c a lVa l u e ’ ’maxOccurs= ‘ ‘unbounded ’ ’>

<xs : complexType><xs : sequence><xs : element name= ‘ ‘ value ’ ’>. . . d e f i n i z i o n e de i v a l o r i . . .</xs : element>

</xs : sequence><xs : a t t r i bu t e name= ‘ ‘ startTime ’ ’



type = ‘ ‘ xs : dateTime ’ ’ use = ‘ ‘ opt iona l ’ ’/><xs : a t t r i bu t e name= ‘ ‘ t t i ’ ’

type = ‘ ‘ xs : dateTime ’ ’ /><xs : a t t r i bu t e name= ‘ ‘ t t f ’ ’

type = ‘ ‘ xs : dateTime ’ ’ use = ‘ ‘ opt iona l ’ ’ /></xs : complexType>

</xs : element>


</xs : element>

I nomi “tti” e “ttf” si riferiscono rispettivamente all’istante iniziale e all’istantefinale del tempo di transazione e sono del tutto arbitrari.Nel caso in cui all’entita siano associati solo il tempo di transazione ed il tempodi disponibilita, questi devono essere tradotti come attributi XML dell’elementoche modella l’entita (non essendoci l’elemento che modella il lifespan).

Tempo dell’evento ed eventi Se l’entita e fornita di supporto temporale peril tempo dell’evento, e necessario specificare, per ogni valore assunto dal lifespan,l’istante in cui si e verificato l’evento che ha portato (nell’universo modellato)l’entita in un particolare stato e l’evento che ha portato l’entita ad uscire dellostato in cui era. Tale situazione puo essere codificata nel seguente modo:



<xs : element name= ‘ ‘ value ’ ’><xs : simpleType><xs : r e s t r i c t i o n base=”xs : s t r i n g”>

. . . s t a t i . . .</xs : r e s t r i c t i o n >

</xs : simpleType></xs : element>


<xs : element name= ‘ ‘ startEvent ’ ’><xs : complexType><xs : a t t r i bu t e name= ‘ ‘ t ipo ’ ’ type = ‘ ‘ xs : s t r i ng ’ ’

minOccurs = ‘ ‘0 ’ ’ /><xs : a t t r i bu t e name= ‘ ‘ eventTime ’ ’

type = ‘ ‘ dateTime ’ ’ /></xs : complexType>

</xs : element>

<xs : element name= ‘ ‘ endEvent ’ ’ minOccurs= ‘ ‘0 ’ ’><xs : complexType><xs : a t t r i bu t e name= ‘ ‘ t ipo ’ ’ type = ‘ ‘ xs : s t r i ng ’ ’

use = ‘ ‘ opt iona l ’ ’/><xs : a t t r i bu t e name= ‘ ‘ eventTime ’ ’


</xs : element>



type = ‘ ‘ xs : dateTime ’ ’ use = ‘ ‘ opt iona l ’ ’/></xs : complexType>


</xs : element>

Nell’esempio, l’attributo XML Schema “tipo” e dichiarato opzionale in quanto,secondo la definizione di tempo dell’evento, non e necessario specificare il tipodell’evento. L’evento finale e dichiarato opzionale in quanto puo non essere co-nosciuto per lo stato attuale.Tale costrutto e definito come stringa senza restrizioni, ma all’occorrenza, quandosono modellati gli eventi, puo essere imposta una restrizione simile a quella usataper definire gli stati, in modo che il sistema accetti solo gli eventi dello schema.Viene di seguito riportato un esempio di definizione che permette di specificaregli eventi in modo tale che solo certi eventi possano dare inizio o porre fine adun certo stato (vengono presi come esempio due degli stati del diagramma di“default”):




<xs : cho ice>

<xs : element name= ‘ ‘ scheduled ’ ’><xs : complexType><xs : sequence>

<xs : element name= ‘ ‘ startEvent ’ ’><xs : complexType><xs : a t t r i bu t e name= ‘ ‘ t ipo ’ ’ use = ‘ ‘ opt iona l ’ ’><xs : simpleType><xs : r e s t r i c t i o n base=”xs : s t r i n g”>. . . t i p i d i ev en t i che possonodare i n i z i o a l l o s t a t o scheduled . . .</xs : r e s t r i c t i o n ></xs : simpleType>

</xs : a t t r i bu t e ><xs : a t t r i bu t e name= ‘ ‘ eventTime ’ ’

type = ‘ ‘ dateTime ’ ’ /></xs : complexType></xs : element><xs : element name= ‘ ‘ endEvent ’ ’><xs : complexType><xs : a t t r i bu t e name= ‘ ‘ t ipo ’ ’ use = ‘ ‘ opt iona l ’ ’><xs : simpleType><xs : r e s t r i c t i o n base=”xs : s t r i n g”>. . . t i p i d i ev en t i che possonoporre f i n e a l l o s t a t o scheduled . . .</xs : r e s t r i c t i o n ></xs : simpleType>


type = ‘ ‘ dateTime ’ ’ />



<xs : element name= ‘ ‘ ac t ive ’ ’><xs : complexType><xs : sequence>

<xs : element name= ‘ ‘ startEvent ’ ’><xs : complexType><xs : a t t r i bu t e name= ‘ ‘ t ipo ’ ’ use = ‘ ‘ opt iona l ’ ’><xs : simpleType><xs : r e s t r i c t i o n base=”xs : s t r i n g”>. . . t i p i d i ev en t i che possonodare i n i z i o a l l o s t a t o a c t i v e . . .</xs : r e s t r i c t i o n ></xs : simpleType>


type = ‘ ‘ dateTime ’ ’ /></xs : complexType></xs : element><xs : element name= ‘ ‘ endEvent ’ ’><xs : complexType><xs : a t t r i bu t e name= ‘ ‘ t ipo ’ ’ use = ‘ ‘ opt iona l ’ ’><xs : simpleType><xs : r e s t r i c t i o n base=”xs : s t r i n g”>. . . t i p i d i ev en t i che possonoporre f i n e a l l o s t a t o a c t i v e . . .</xs : r e s t r i c t i o n ></xs : simpleType>


type = ‘ ‘ dateTime ’ ’ /></xs : complexType></xs : element>


</xs : element>

</xs : cho ice>




type = ‘ ‘ xs : dateTime ’ ’ use = ‘ ‘ opt iona l ’ ’/></xs : complexType>


</xs : element>

In tale modo “historicalValue” potra contenere uno a scelta degli stati, ognunodei quali comprendera un evento iniziale ed un evento finale a scelta tra quelliappositamente specificati per ogni stato.Come detto non c’e modo di controllare (se non “dall’esterno”) il vincolo cheimpone la non sovrapposizione e l’incongruenza degli intervalli indicati come“eventTime” di “startEvent” e “endEvent”.

Tempo di disponibitita Il tempo di disponibitita puo essere tradotto ag-giungendo degli “xs:attribute” (attributi XML Schema) che indichino l’istante diinizio e di fine del tempo di disponibilita. Supponendo di voler memorizzare iltempo di disponibilita dell’entita “impiegato”, la traduzione e la seguente:


<xs : complexType><xs : sequence>. . . d e f i n i z i o n e d e g l i a t t r i b u t i . . .</xs : sequence><xs : a t t r i bu t e name= ‘ ‘ t t i ’ ’

type = ‘ ‘ xs : dateTime ’ ’ /><xs : a t t r i bu t e name= ‘ ‘ t t f ’ ’

type = ‘ ‘ xs : dateTime ’ ’ use = ‘ ‘ opt iona l ’ ’ /><xs : a t t r i bu t e name= ‘ ‘ a t i ’ ’

type = ‘ ‘ xs : dateTime ’ ’ /><xs : a t t r i bu t e name= ‘ ‘ at f ’ ’

type = ‘ ‘ xs : dateTime ’ ’ use = ‘ ‘ opt iona l ’ ’ /></xs : complexType>

</xs : element>


I nomi “ati” e “atf” si riferiscono rispettivamente all’istante iniziale e all’istantefinale del tempo di disponibilita e sono del tutto arbitrari. L’istante finale deltempo di disponibilita e dichiarato opzionale in quanto puo essere indefinito peri valore attuale.Nel caso in cui all’entita sia associato il supporto lifespan, sia il tempo di tran-sazione che il tempo di disponibilita devono essere tradotti come attributi XMLdell’elemento che modella il lifespan.

Attributi con supporto temporale

Un attributo con supporto temporale puo essere codificato in modo simile a quel-lo utilizzato per il lifespan delle entita, in questo caso, pero, i dati riguardanti iltempo di validita, il tempo di transazione ed il tempo di disponibilita (quando ri-chiesti dallo schema) vengono tradotti come attributi XML Schema dell’elemento“historicalValue”. Nel caso in cui si voglia specificare il supporto temporale peril tempo dell’evento si procedera aggiungendo i sottoelementi “startEvent” ed“endEvent” sempre all’interno di “historicalValue”.Ad esempio, la traduzione di un attributo “stipendio”, che potrebbe apparte-nere ad un’entita “impiegato”, di cui si voglia memorizzare tutte le dimensionitemporali precedentemente descritte, sarebbe la seguente:

<xs : element name= ‘ ‘ s t ipend io ’ ’><xs : complexType><xs : sequence>

<xs : element name= ‘ ‘ h i s t o r i c a lVa l u e ’ ’maxOccurs= ‘ ‘unbounded ’ ’>


<xs : element name= ‘ ‘ value ’ ’type = ‘ ‘ xs : i n t ege r ’ ’ />

<xs : element name= ‘ ‘ startEvent ’ ’><xs : complexType><xs : a t t r i bu t e name= ‘ ‘ t ipo ’ ’ use = ‘ ‘ opt iona l ’ ’><xs : simpleType><xs : r e s t r i c t i o n base=”xs : s t r i n g”>. . . t i p i d i ev en t i i n i z i a l i . . .</xs : r e s t r i c t i o n ></xs : simpleType>




</xs : element><xs : element name= ‘ ‘ endEvent ’ ’ minOccurs= ‘ ‘0 ’ ’><xs : complexType><xs : a t t r i bu t e name= ‘ ‘ t ipo ’ ’ use = ‘ ‘ opt iona l ’ ’><xs : simpleType><xs : r e s t r i c t i o n base=”xs : s t r i n g”>. . . t i p i d i ev en t i f i n a l i . . .</xs : r e s t r i c t i o n ></xs : simpleType>



</xs : element>

</xs : sequence>

<xs : a t t r i bu t e name= ‘ ‘ vt i ’ ’type = ‘ ‘ xs : dateTime ’ ’ />

<xs : a t t r i bu t e name= ‘ ‘ vt f ’ ’type = ‘ ‘ xs : dateTime ’ ’ use = ‘ ‘ opt iona l ’ ’ />

<xs : a t t r i bu t e name= ‘ ‘ t t i ’ ’type = ‘ ‘ xs : dateTime ’ ’ />

<xs : a t t r i bu t e name= ‘ ‘ t t f ’ ’type = ‘ ‘ xs : dateTime ’ ’ use = ‘ ‘ opt iona l ’ ’ />

<xs : a t t r i bu t e name= ‘ ‘ a t i ’ ’type = ‘ ‘ xs : dateTime ’ ’ />

<xs : a t t r i bu t e name= ‘ ‘ at f ’ ’type = ‘ ‘ xs : dateTime ’ ’ use = ‘ ‘ opt iona l ’ ’ />



</xs : element>


L’istante finale del tempo di validita e dichiarato opzionale in quanto puo nonessere conosciuto per i valore attuale. La definizione sopra data presupponeche l’attributo abbia cardinalita snapshot [1:1] e cardinalita lifespan [1:n]. Perquanto riguarda la cardinalita lifespan ( la gestione della cardinalita snapshotdegli attributi e gia stata trattata nel Capitolo 4.1.2):

• la cardinalita minima non implica nessun trattamento particolare in quantostrettamente collegata alla cardinalita snapshot;

• la cardinalita massima propone tre sottocasi:

– il caso in cui si ha massimo snapshot 1 e massimo lifespan illimitatopuo essere trattato come nell’esempio sopra;

– il caso in cui si ha massimo snapshot 1 e massimo lifespan 1 puo esseretradotto non specificando l’attributo “maxOccurs” nella definizionedell’elemento “historicalValue” (che in tal caso prende il valore 1 di“default”), in questo modo puo esserci un solo valore storico;

– il caso in cui si ha massimo snapshot illimitato e massimo lifespanillimitato puo essere tradotto (come descritto nel Capitolo 4.1.2 pergli attributi multivalore) indicando “unbounded” come valore “ma-xOccurs” nella definizione dell’elemento che rappresenta l’attributostesso.

Questa gestione degli attributi con supporto temporale vale anche per gli attri-buti di tipo geografico: diventa dunque possibile gestire in modo relativamen-te semplice geometrie tempo-varianti. Non c’e modo, pero, di controllare (senon “dall’esterno”) il vincolo che impone la non sovrapposizione degli intervallitemporali.

Relazioni e aggregazioni con supporto temporale

In caso di relazioni con supporto temporale risulta impossibile utilizzare il metododi traduzione indicato nei precedenti capitoli come “inclusione”. Diventerebbeinfatti necessario, al cambio di una relazione gestire due memorizzazioni dellastessa istanza.Utilizzando il metodo del riferimento a chiave, la gestione delle dimensioni tempo-rali delle relazioni risulta del tutto simile a quella vista per gli attributi, compresala gestione della cardinalita lifespan. E, dunque, necessario definire l’elemento“value” (per differenziare le due situazioni si potrebbe chiamare questo elemento


“reference”) come riferimento a chiave e non piu l’elemento principale della rela-zione.Ad esempio, supponendo di aggiungere alla relazione “Lavora” dello schema inrappresentato Figura 4.3, il supporto per tutte le dimensioni previste dal model-lo ChronoGeoGraph all’interno dell’elemento “impiegato”, la traduzione di talerelazione, ovvero il sottoelemento “dipartimento”, sarebbe:

<xs : element name= ‘ ‘ dipart imento ’ ’><xs : complexType><xs : sequence>

<xs : element name= ‘ ‘ h i s t o r i c a lVa l u e ’ ’><xs : complexType>

<xs : sequence>

<xs : element name= ‘ ‘ value ’ ’type = ‘ ‘ xs : s t r i ng ’ ’ />

<xs : element name= ‘ ‘ startEvent ’ ’><xs : complexType><xs : a t t r i bu t e name= ‘ ‘ t ipo ’ ’ minOccurs= ‘ ‘0 ’ ’><xs : simpleType><xs : r e s t r i c t i o n base=”xs : s t r i n g”>. . . t i p i d i ev en t i i n i z i a l i . . .</xs : r e s t r i c t i o n ></xs : simpleType>



</xs : element>

<xs : element name= ‘ ‘ endEvent ’ ’ minOccurs= ‘ ‘0 ’ ’><xs : complexType><xs : a t t r i bu t e name= ‘ ‘ t ipo ’ ’ minOccurs= ‘ ‘0 ’ ’><xs : simpleType><xs : r e s t r i c t i o n base=”xs : s t r i n g”>. . . t i p i d i ev en t i f i n a l i . . .</xs : r e s t r i c t i o n >


</xs : simpleType></xs : a t t r i bu t e ><xs : a t t r i bu t e name= ‘ ‘ eventTime ’ ’


</xs : element>

</xs : sequence>

<xs : a t t r i bu t e name= ‘ ‘ vt i ’ ’type = ‘ ‘ xs : dateTime ’ ’ />

<xs : a t t r i bu t e name= ‘ ‘ vt f ’ ’type = ‘ ‘ xs : dateTime ’ ’ use = ‘ ‘ opt iona l ’ ’ />

<xs : a t t r i bu t e name= ‘ ‘ t t i ’ ’type = ‘ ‘ xs : dateTime ’ ’ />

<xs : a t t r i bu t e name= ‘ ‘ t t f ’ ’type = ‘ ‘ xs : dateTime ’ ’ use = ‘ ‘ opt iona l ’ ’ />

<xs : a t t r i bu t e name= ‘ ‘ a t i ’ ’type = ‘ ‘ xs : dateTime ’ ’ />

<xs : a t t r i bu t e name= ‘ ‘ at f ’ ’type = ‘ ‘ xs : dateTime ’ ’ use = ‘ ‘ opt iona l ’ ’ />



</xs : element>

e la dichiarazione del riferimento a chiave diventerebbe la seguente:

<xs : k ey r e f name= ‘ ‘ RefDipartimento ’ ’r e f e r = ‘ ‘ ChiaveDipartimento ’ ’>

<xs : s e l e c t o r xpath= ‘ ‘ dipart imento ’ ’/><xs : f i e l d xpath= ‘ ‘ value ’ ’/>

</xs : keyre f>

Lo stesso tipo di traduzione si puo essere utilizzata nei casi di aggregazioni ditipo temporale.


Campi con supporto temporale

Per quanto riguarda la traduzione di questo costrutto con supporto temporale,essa non si differenzia di molto da quella utilizzata per attributi e relazioni.In particolare si deve inserire, come sottoelemento dell’elemento che rappresentail costrutto, la dichiarazione di “historicalValue”, come e stato fatto precedente-mente: “historicalValue” avra, a seconda di quanto specificato nello schema dipartenza, una serie di attributi, da zero ad al massimo sei (“vti”, “vtf”, “tti”,“ttf”, “ati”, “atf”), e, se necessario, due sotto elementi (“startEvent”, “endE-vent”), che descriveranno le diverse dimensioni temporali. Inoltre, “historical-Value” deve contenere un sottoelemento “sample” (con l’adeguata cardinalitamassima, solitamente “unbounded”) definito come visto nel Capitolo 4.2.1.

Relazioni di Sincronizzazione

Le relazioni di sincronizzazione, imponendo vincoli a livello di gestione della basedi dati, non sono traducibili utilizzando i costrutti forniti da XML Schema, pertanto non verranno perse in considerazione nella presente trattazione.

Capitolo 5

Un algoritmo di traduzione

Viene ora presentato un algoritmo, estensione dell’algoritmo di traduzione dischemi Entita/Relazioni in schemi XML proposto in [16], per generare schemiXML Schema da schemi ChronoGeoGraph. In particolare, questo algoritmoinclude istruzioni per la gestione dei seguenti costrutti:

• attributi sulle relazioni;

• specializzazioni cartografiche;

• territori di schema, campi ed entita georeferenziate;

• relazioni topologiche;

• aggregazioni (spaziali, semplici e semantiche);

• tempo di validita (per gli attributi, le relazioni, le aggregazioni ed i campi)o lifespan (per le entita), tempo di transazione, tempo di disponibilita etempo dell’evento.

La traduzione di questi costrutti viene fatta seguendo la metodologia descrittanel Capitolo 4.

5.1 Definizione dell’algoritmo principale

Definiamo preliminarmente una struttura dati utilizzata dall’algoritmo (un parti-colare tipo di liste) e le condizioni necessarie che un’entita deve soddisfare nel casoin cui si utilizzi la metodologia di traduzione per la relazione precedentementedefinita come “inclusione”.

111

112 CAPITOLO 5. UN ALGORITMO DI TRADUZIONE

Le liste L’algoritmo utilizza due liste definibili come una sequenza di coppiedi valori, il primo dei quali e un riferimento ad una entita o ad una relazionementre il secondo indica se tale costrutto e gia stato codificato o meno. La listapuo essere utilizzata tramite tre operazioni: la prima legge le coppie di valoripartendo dalla testa della lista stessa; la seconda modifica il secondo valore diuna data coppia; la terza inserisce un dato elemento in coda alla lista.

Condizioni di Inclusione (C.I.) Per modellare una relazione del tipo uno-a-uno o uno-a-molti mediante l’inclusione di un’entita come sotto-elemento dell’al-tra, devono essere soddisfatte le seguenti condizioni:

• l’entita non deve essere segnalata come “codificata”;

• l’entita deve partecipare alla relazione con cardinalita 1:1;

• l’entita non deve essere debole, a meno che la relazione in questione nonsia la relazione identificante;

• l’entita non deve partecipare in qualita di sottoclasse in nessuna specializ-zazione;

• l’entita non deve essere stata identificata come first level entity1;

• la relazione (o aggregazione) non deve avere alcun supporto temporale.

L’algoritmo e composto da una procedura principale, descritta di seguito, e daalcune procedure, descritte in modo dettagliato nella sezione 5.2. La proceduraprincipale e cosı descritta2:

1. Inizializzare due liste (definite come descritto precedente): una per le entitaed una per le relazioni.

2. Definire i costrutti XML Schema principali, il namespace all’interno del-l’elemento xs:schema ed un elemento radice che funga da contenitore sim-bolico dello schema da definire. Se necessario, inserire la definizione diimportazione dei tipi geometrici di GML.

1Vedi algoritmo, Punto 42 Ove non specificato, con cardinalita si intende riferirsi alla cardinalita snapshot.

5.1. DEFINIZIONE DELL’ALGORITMO PRINCIPALE 113

3. Se lo schema ChronoGeoGraph e di tipo spaziale definire l’elemento rela-tivo al territorio di schema. Se al territorio di schema sono collegati deicampi, per ciascuno di essi inserire il sottoelemento relativo ed eseguire laprocedura campi.

4. Definire un insieme di first level entities che verranno codificate come ele-menti diretti discendenti del nodo radice definito al Passo 2. Tale listasara composta da tutte le entita che non partecipano ad alcuna relazionebinaria con cardinalita minima e massima pari a 1 e che non partecipanoin qualita di sottoclassi in alcuna specializzazione. Inserire tali entita nel-la lista relativa alle entita e segnalare tutte le entita presenti come “noncodificata”.

5. Definire una lista di tutte le relazioni e segnalare tutte le relazioni come“non codificata”.

6. Per ogni relazione binaria in cui entrambe le entita partecipanti soddisfinole C.I. :

i. Segnalare la relazione come “codificata”.

ii. Creare un elemento, diretto discendente dell’elemento contenitore delloschema, con il nome delle relazione, con cardinalita minima pari a “0”e massima pari ad “unbounded”.

iii. Per ognuna delle entita che partecipano alla relazione, inserire l’entitanella lista delle entita creare un sottoelemento con cardinalita minima“1” e massima “1” ed eseguire la procedura entita.

iv. Se la relazione e di tipo temporale eseguire la procedura dimensionitemporali. Se la relazione e di tipo topologico eseguire la procedurarelazioni topologiche.

7. LOOP. Concludere l’algoritmo se tutti gli elementi della lista delle entitasono segnalati come “codificata”. Altrimenti prendere in considerazioneil primo elemento segnalato come “non codificata”: creare la strutturadell’elemento, definire la sua cadinalita ed eseguire la procedura entita.

Se l’algoritmo e stato eseguito correttamente, alla conclusione le due liste de-vono contenere rispettivamente tutti le entita e tutte le relazioni, tutte segnalatecome “codificata”.


5.2 Procedure

Di seguito sono descritte le procedure aggiuntive richiamate dalla procedura prin-cipale.

Procedura entita

Procedura per la codifica delle entita, che richiama, quando e necessario, le pro-cedure per la codifica delle relazioni, delle aggregazioni e degli aspetti spaziali etemporali delle entita.

1. Segnalare come “codificata” l’elemento della lista che rappresenta l’entitain questione.

2. Se l’entita e di tipo temporale eseguire la procedura dimensioni tempo-rali.

3. Per ogni attributo, definire la struttura principale e l’adeguata cardinalita(considerando anche, ove specificato, la cardinalita lifespan). Se l’attri-buto e di tipo temporale eseguire la procedura dimensioni temporali,altrimenti definire il tipo di valore.

4. Se l’entita e georeferenziata eseguire la procedura entita georeferenziate.

5. Per ogni relazione binaria a cui l’entita partecipa, se la relazione e segnalatacome “non codificata”, eseguire la procedura relazioni.

6. Per ogni relazione n-aria a cui l’entita partecipa con cardinalita massimapari ad 1, se la relazione e segnalata come “non codificata”, eseguire laprocedura relazioni n-arie.

7. Per ogni aggregazione a cui l’entita partecipa in qualita di “intero”, eseguirela procedura aggregazioni.

8. Se l’entita e superclasse in una specializzazione eseguire la procedura spe-cializzazioni.

9. Definire i vincoli di chiave.

5.2. PROCEDURE 115

Procedura relazioni

Procedura per la codifica delle relazioni binarie. Se le C.I. sono soddisfatte vie-ne utilizzato il metodo dell’inclusione, altrimenti viene utilizzato il metodo diriferimento a chiave.

1. Se l’altra entita coinvolta partecipa con cardinalita 1:1 ed i requisiti di in-clusione (C.I.) sono soddisfatti: segnalare la relazione come “codificata”,inserire un sottoelemento interno che rappresenti tale entita, con l’adegua-ta cardinalita (considerando anche, ove specificato, la cardinalita lifespan),inserire l’entita nella relativa lista come “non codificata” ed eseguire laprocedura entita. Se, invece, i requisiti di inclusione (C.I.) non sono sod-disfatti inserire l’altra l’entita coinvolta dalla relazione nella relativa listacome “non codificata”.

2. Se l’altra entita coinvolta non partecipa con cardinalita 1:1, segnalare la re-lazione come “codificata”. Se l’altra entita e segnalata come “non codifica-ta” eseguire la procedura entita per tale entita. Inserire un sottoelementointerno che rappresenti il riferimento alla chiave di tale entita, definire lacardinalita (considerando anche, ove specificato, la cardinalita lifespan) edi vincoli necessari al rispetto dei vincoli imposti dalla relazione e definire ilvincolo di chiave esterna.

3. Se la relazione prevede attributi, codificarli e nel caso in cui questi sianotemporali eseguire la procedura dimensioni temporali.

4. Se la relazione e di tipo temporale eseguire la procedura dimensionitemporali.

5. Se la relazione e topologica eseguire la procedura relazioni topologiche.

Procedura relazioni n-arie

Procedura per la codifica delle relazioni n-arie. Per ragioni di semplicita delloschema XML prodotto, viene sempre utilizzato il metodo del riferimento a chiave(e comunque possibile implementare la procedura in modo che utilizzi, quandopossibile, il metodo dell’inclusione.)

1. Segnalare la relazione come “codificata”. Se alcune delle entita coinvoltesono segnalate come “non codificata” eseguire la procedura entita per talientita. Inserire un sottoelemento che rappresenti la relazione ed inserire


in maniera appropriata i sottoelementi che rappresentano i riferimenti allechiavi delle altre entita coinvolte. Definire le cardinalita (considerando an-che, ove specificato, la cardinalita lifespan) ed i vincoli necessari al rispettodei vincoli imposti dalla relazione e definire il vincolo di chiave esterna.

2. Se la relazione prevede attributi, codificarli e nel caso in cui questi sianotemporali eseguire la procedura dimensioni temporali.

3. Se la relazione e di tipo temporale eseguire la procedura dimensionitemporali.

Procedura specializzazioni

Procedura per la codifica dei costrutti di specializzazione. Questa procedura vienesempre richiamata dall’entita superclasse (padre), mai dalle sottoclassi (figlie).

1. Definire l’adeguato costrutto a seconda del tipo di specializzazione.

2. Per ciascuna delle specializzazioni, inserire la sottoclasse nella lista re-lativa alle entita come “non codificata” ed eseguire la procedura entitageoreferenziate.

Procedura aggregazioni

Procedura per la codifica delle aggregazioni. Questa procedura viene semprerichiamata dall’entita intero, mai dalle entita parti.

1. Se sono soddisfatte le C.I, inserire le entita parti come sottoelementi dell’en-tita intero, altrimenti codificare l’aggregazione con il metodo del riferimentoa chiave.

2. Definire le cardinalita (considerando anche, ove specificato, la cardinalitalifespan) ed i vincoli di chiave esterna.

3. Se l’aggregazione e di tipo temporale eseguire la procedura dimensionitemporali.

Procedura entita georeferenziate

Procedura per la codifica dell’attributo geometrico delle entita georeferenziate.Inserire il costrutto “geometry” e definire adeguatamente i vincoli di cardinalia

5.2. PROCEDURE 117

(considerando anche, ove specificato, la cardinalita lifespan) ed il tipo di geome-tria richiesto tramite riferimenti ai costrutti di GML. Se l’attributo geometrico edi tipo temporale (geometrie tempo-varianti) eseguire la procedura dimensionitemporali. Se all’entita sono collegati dei campi, per ciascuno di essi inserire lisottoelemento relativo ed eseguire la procedura campi.

Procedura campi

Procedura per la codifica dei campi collegati ad una entita o al territorio di sche-ma. Se il campo e di tipo temporale, eseguire la procedura dimensioni tempo-rali, altrimenti inserire il costrutto “sample” e definire adeguatamente i vincolidi cardinalia ed il tipo di geometria richiesto tramite riferimenti ai costrutti diGML.

Procedura relazioni topologiche

Procedura per la codifica del costrutto di segnalazione del tipo di relazione topo-logica. Inserire l’elemento adeguato per il riconoscimento del tipo di relazionetopologica.

Procedura dimensioni temporali

Procedura per la codifica dei costrutti temporali di entita, attributi, relazioni,aggregazioni e campi.

1. Se il costrutto richiede il supporto per il lifespan, definire il relativo sottoe-lemento considerando il tipo di diagramma di stati specificato. Se e specifi-cato il supporto del tempo dell’evento codificare adeguatamente l’elementoinserendovi la specifica dei sottoelementi “startEvent” e “endEvent”.

2. Se il costrutto e un attributo o una relazione, aggiungere la definizione deicostrutti “historicalValue” e “value”.

3. Se il costrutto e un campo, aggiungere la definizione del costrutto “hi-storicalValue” e definire al suo interno l’elemento “sample”, i vincoli dicardinalia ed il tipo di geometria richiesto tramite riferimenti ai costruttidi GML.

4. Se il costrutto richiede il supporto per il tempo dell’evento, codificare ade-guatamente l’elemento inserendovi la specifica dei sottoelementi “startE-vent” e “endEvent”.


5. Se il costrutto richiede tempo di validita, tempo di transazione o tempo didisponibilita inserire i relativi attributi XML Schema.

5.3 Codifica dell’algoritmo

Viene qui proposta una codifica dell’algoritmo precedentemente descritto in pseudo-codice 3. Le funzionalita dell’algoritmo sono suddivise in quattro classi definitecome segue.

• traduttoreCggXsd. E la classe principale, la quale implementa sia l’al-goritmo principale che le procedure aggiuntive.

• cggList. E la classe che implementa le liste utilizzate dell’algoritmo prin-cipale.

• cggSchema. E la classe che svolge il ruolo di interfaccia tra l’algoritmo elo schema ChronoGeoGraph da tradurre.

• xsDoc. E la classe che svolge il ruolo di interfaccia tra l’algoritmo e ildocumento XML Schema che sara il risultato della traduzione.

Le classi “cggSchema” e “xsDoc” sono codificate solo parzialmente, lasciandole funzioni base di lettura e scrittura indipendenti dal contesto di una futuraimplementazione pratica.

5.3.1 La classe “traduttoreCggXsd”

c l a s s traduttoreCggXsd ( ){

//dichiarazione delle var iabi l i globalicggSchema cgg ;xsDoc xsd ;cggL i s t en tL i s t ;c ggL i s t r e l L i s t ;

//procedura principale dell ’ algoritmo

3Il tipo di pseudo-codice utilizzato non e quello standard, ma una sua versione piu vici-na al linguaggio Java. Questa scelta e stata effettuata con l’intento di rendere piu semplicel’integrazione con l’applicazione ChronoGeoGraph (scritto in Java).

5.3. CODIFICA DELL’ALGORITMO 119

main ( St r ing args [ ] ) {

//come primo argomento viene passato i l nome del f i l e//che contiene lo schema ChronoGeoGraph in forma// leggibi le per la classe cggSchemacgg=new cggSchema ( args [ 0 ] ) ;//come secondo argomento viene passato i l nome del// f i l e su cui i l traduttore andra ‘ a scriverexsd=new xsDoc ( args [ 1 ] ) ;

//Passo 1// l i s t a per le entita ‘en tL i s t=new cggL i s t ( cgg . entsNum ( ) ) ;// l i s t a per le relazionir e l L i s t=new cggL i s t ( cgg . relsNum ( ) ) ;

//Passo 2//costrutti i n i z i a l i del documento XMLxsd . insertXSDef ( ) ;//elemento radicexsd . beginXScomplexElement ( cgg .Name( ) , ‘ ‘ 1 ’ ’ , ‘ ‘ 1 ’ ’ ) ;xsd . beginXSsequence ( ) ;

//Passo 3//codif ica del terr itor io di schemai f ( cgg . t s ( ) ) then {xsd . beginXScomplexElement ( cgg . tsName ( ) , ‘ ‘ 1 ’ ’ , ‘ ‘ 1 ’ ’ ) ;xsd . beginXSsequence ( ) ;xsd . beginXScomplexElement ( ‘ ‘ geometry ’ ’ , ‘ ‘ 1 ’ ’ , ‘ ‘ 1 ’ ’ ) ;xsd . beginXSsequence ( ) ;

//codif ica del tipo di geometriaxsd . insertGMLgeometry ( cgg . tsGeo ( ) ) ;

//codif ica dei campi col legat i al//terr itor io di schemaSt r ing [ ] cmps=cgg . cmpsTS ( ) ;f o r each i then {campi ( cgg . cmps [ i ] ) ;}


xsd . endXSsequence ( ) ;xsd . endXScomplexElement ( ) ;xsd . endXSsequence ( ) ;xsd . endXScomplexElement ( ) ;}

//Passo 4// f i r s t−level−entit iesSt r ing [ ] ent=cgg . ents ( ) ;f o r each i {i f ( cgg . f i r s t L e v e lEn t i t y ( ent [ i ] ) then {// inserire nella l i s t aen tL i s t . i n s e r t ( ent [ i ] ) ;}}

//Passo 5// l i s t a delle relazioniSt r ing [ ] r e l=cgg . r e l s ( ) ;f o r each i {r e l L i s t . i n s e r t ( r e l [ i ] ) ;}

//Passo 6//per ogni relazionef o r each i {//se e ‘ binaria e le entita ‘ coinvolte//soddisfano le C. I .i f ( cgg . b i na r i a ( r e l [ i ] ) and

f o r each en t i t y in r e l a t i o n s h i pincludeC ( ent i ty , r e l ) ) then {

//segnalare come codif icatar e l L i s t . s e tCod i f ( r e l [ i ] ) ;//codif ica dell ’ elemento relativo al la relazionexsd . beginXScomplexElement ( r e l [ i ] , ‘ ‘ 0 ’ ’ , ‘ ‘ unbounded ’ ’ ) ;xsd . beginXSsequence ( ) ;i f ( topo log ( r e l [ i ] ) ) then {r e l a i z i o n iTopo l o g i c h e ( r e l [ i ] ) ;}

St r ing [ ] r e lEn t i t y s=cgg . r e lL i nk s ( r e l [ i ] ) ;


//codif ica dei sottoelementi re lat iv i a l l e entita ‘f o r each j {en tL i s t . i n s e r t ( r e lEn t i t y s [ j ] ) ;e n t i t a ( r e lEn t i t y s [ j ] , ‘ ‘ 1 ’ ’ , ‘ ‘ 1 ’ ’ ) ;}

//fine elementoxsd . endXSsequence ( ) ;xsd . endXScomplexElement ( ) ;}

//Passo 7St r ing toDo ;//finche ‘ non sono state codif icate//tutte le entita ‘ della l i s t awhi le ( ! en tL i s t . thEnd ( ) ) {//codif ica della prossima entita ‘toDo=entL i s t . readNext ( ) ;e n t i t a ( toDo , ‘ ‘ 0 ’ ’ , ‘ ‘ unbounded ’ ’ ) ;}

//chiusura dell ’ elemento radicexsd . endXSsequence ( ) ;xsd . endXScomplexElement ( ) ;xsd . c loseXSdef ( )}

//Metodi//(procedure aggiuntive dell ’ algoritmo)

//Metodo per la codif ica delle entita ‘void en t i t a ( S t r ing ent , S t r ing min , S t r ing max){//segnalare l ’ entita ‘ come codif icataen tL i s t . s e tCod i f ( ent ) ;//elemento relativo al l ’ entita ‘xsd . beginXScomplexElement ( ent , min , max ) ;xsd . beginXSsequence ( ) ;//codif ica degli attributiSt r ing [ ] a t t=cgg . a t t s ( ent ) ;f o r each i then {


a t t r i b u t i ( ent , a t t [ i ] , cgg . opz ( ent , a t t [ i ] ) ,cgg . mVal( ent , a t t [ i ] ) , cgg . comp( ent , a t t [ i ] ) ) ;

}//codif ica delle entita ‘ georeferenziatei f ( cgg . spaz ( ent ) ) then {en t i t aGeo r e f ( ent ) ;}

//codif ica delle relazioniSt r ing [ ] r e l=cgg . r e l sEnt ( ent ) ;f o r each i {//relazioni binarie associate//al l ’ entita ‘ non ancora codif icatei f ( cgg . b i na r i a ( r e l [ i ] ) ) then {i f ( ! r e l L i s t . readCodi f ( r e l [ i ] ) ) then {r e l a z i o n i ( ent , r e l [ i ] ) ;}}

//relazioni n−arie associate//al l ’ entita ‘ non ancora codif icatei f (n−a r i a ( ent , r e l [ i ] ) ) then {i f ( ! r e l L i s t . readCodi f ( r e l [ i ] ) ) then {r e l a z i o n iNa r i e ( ent , r e l [ i ] ) ;}}

//codif ica delle aggregazioni//a cui l ’ entita ‘ partecipa come interoSt r ing [ ] agr s=cgg . agrs ( ent ) ;f o r each i {}agg r egaz i on i ( ent , agrs [ i ] ) ;}

//codif ica delle special izzazioni//a cui l ’ entita ‘ partecipa come superclasseSt r ing [ ] spcs=cgg . spcs ( ent ) ;i f ( spcs [ ] . l enght >0) then {s p e c i a l i z z a z i o n i z i o n i ( ent , spcs [ ] ) ;}

//sono necessarie due chiamate al metodo//dimensioniTemporali per consentire la//codif ica sia nel caso in cui l ’ entita ‘ abbia supporto//li fespan sia nel caso in cui non ne sia fornitadimensioniTemporal i ( cgg . l s ( ent ) , ent , cgg . t t ( ent ) ,


f a l s e , cgg . e t ( ent ) , cgg . at ( ent ) ) ;xsd . endXSsequence ( ) ;d imens ioniTemporal i ( cgg . l s ( ent ) , ent , cgg . t t ( ent ) ,

f a l s e , cgg . e t ( ent ) , cgg . at ( ent ) ) ;xsd . endXScomplexElement ( ) ;

//nel caso di attributi , realzioni , aggregazioni e campi//sono necessarie due chiamate//la prima per codif icare i l tempo dell ’ evento//la seconda per le altre dimensioni temporali

//codif ica della chiaveSt r ing keyName=ent . ‘ ‘ Key ’ ’ ;S t r ing [ ] keyAtts=cgg . tota lKey ( ent ) ;xsd . insertXSkeyDef (keyName , ent , keyAtts [ ] ) ;}

//codif ica delle relazionivoid r e l a z i o n i ( S t r ing ent , S t r ing r e l ){St r ing min=cgg . cardMin ( ent , r e l ) ;S t r ing max=cgg . cardMax ( ent , r e l ) ;S t r ing other=cgg . othersName ( ent , r e l ) ;//veri f ica delle C. I .i f ( inc ludeC ( other , r e l ) ) then {//se C. I . soddisfatte//inclusioner e l L i s t . s e tCod i f ( r e l ) ;i f ( ! topo log ( r e l ) ) then {//se la relazione non e ‘ topologicaen t i t a ( other , ‘ ‘ 1 ’ ’ , ‘ ‘ 1 ’ ’ ) ;} e l s e {//se la relazione e ‘ topologica//elemento relativo al la relazionexsd . beginXScomplexElement ( r e l , ‘ ‘ 1 ’ ’ , ‘ ‘ 1 ’ ’ ) ;xsd . beginXSsequence ( ) ;r e l a i z i o n iTopo l o g i c h e ( r e l ) ;//codif ica dell ’ entita ‘en t i t a ( other , ‘ ‘ 1 ’ ’ , ‘ ‘ 1 ’ ’ ) ;//fine elementoxsd . endXSsequence ( ) ;xsd . endXScomplexElement ( ) ;


}} e l s e {//C. I . non soddisfatte//a meno che ‘ ‘ ent ’ ’ non partecipi con//cardinalita ‘ minima 0 e//l ’ altra entita ‘ partecipi con//cardinalita ‘ minima 1i f ( ! ( ( otherMin = ‘ ‘1 ’ ’ ) and (min= ‘ ‘0 ’ ’ ) ) ) then {//Si ut i l i zza una cggList per considerare l ’ altra entita ‘cggL i s t o t h e r sL i s t=new cggL i s t ( 1 ) ;o t h e r sL i s t . i n s e r t ( other ) ;//segnalare al relazione come codif icatar e l L i s t . s e tCod i f ( r e l ) ;//codif ica della relazione con riferimento a chiavere lSupport ( o the r sL i s t , ent , min , max , r e l ) ;}

//in caso contrario la codif ica r isulta migliore//se effettuata a partire dall ’ altra entita ‘}}

//codif ica delle relazioni n−arievoid r e l a z i o n iNa r i e ( S t r ing ent , S t r ing r e l ){St r ing min=cgg . cardMin ( ent , r e l ) ;S t r ing max=cgg . cardMax ( ent , r e l ) ;S t r ing [ ] o the r s=cgg . othersName ( ent , r e l ) ;//Utilizziamo una cggList per considerare le entita ‘//partecipanti una al la voltacggL i s t o t h e r sL i s t=new cggL i s t ( o the r s [ ] . l enght ) ;f o r each i {o th e r sL i s t . i n s e r t ( o the r s [ i ] ) ;}

r e l L i s t . s e tCod i f ( r e l ) ;//codif ica della relazione con riferimento a chiavere lSupport ( o the r sL i s t , ent , min , max , r e l ) ;}

void s p e c i a l i z z a z i o n i ( S t r ing ent , S t r ing [ ] spcs ){St r ing min ;//Specializzazione disgiunta


i f ( spcDisg ( ent ) ) then {i f ( specTot ( ent ) ) then {//specializzazione totalemin= ‘ ‘1 ’ ’} e l s e {//specializzazione parzialemin= ‘ ‘0 ’ ’}xsd . beginXSchoiceDef (min ) ;f o r each i {//codif ica delle sottoclass ien t i t a ( spcs [ i ] , ‘ ‘ 1 ’ ’ , ‘ ‘ 1 ’ ’ )}

xsd . endXSchoiceDef ( ) ;}

//Specializzazione con sovrapposizionei f ( spcSvrp ) then {f o r each i {//codif ica delle sottoclass ien t i t a ( spcs [ i ] , ‘ ‘ 0 ’ ’ , ‘ ‘ 1 ’ ’ )}}}

void agg r egaz i on i ( S t r ing ent , S t r ing agr ){//entita ‘ partiSt r ing [ ] par t s=cgg . agrParts ( ent , agr ) ;f o r i form 1 to par t s [ ] . l enght {i f ( inc ludeC ( other , agr ) ) then {//se C. I . soddisfatte//inclusioneSt r ing min=cgg . partMinCardMin ( ent , arg , par t s [ i ] ) ;S t r ing max=cgg . partMaxCard ( ent , arg , par t s [ i ] ) ;e n t i t a ( par t s [ i ] , min , max ) ;} e l s e {//C. I . non soddisfatte//Si ut i l i zza una cggList per considerare le//entita ‘ partecipanti una al la voltacggL i s t o th e rL i s t=new cggL i s t ( 1 ) ;o th e rL i s t . i n s e r t ( par t s [ i ] ) ;


St r ing min=cgg . partMinCard ( ent , arg , par t s [ i ] ) ;S t r ing max=cgg . partMaxCard ( ent , arg , par t s [ i ] ) ;S t r ing max=cgg . partMaxCardLS ( ent , arg , par t s [ i ] ) ;//codif ica dell ’ agggregazione con riferimento a chiavere lSupport ( o the rL i s t , ent , min , max , agr ) ;}}}

//codif ica degli aspetti spazia l i del le entita ‘void en t i t aGeo r e f ( S t r ing ent ){//tipo di geometriaSt r ing type=cgg . geoType ( ent )i f ( ! cgg . tempE( ent ) ) then {//entita ‘ non temporale//elemento relativo al la geometriaxsd . beginXScomplexElement ( ‘ ‘ geometry ’ ’ , ‘ ‘ 1 ’ ’ , ‘ ‘ 1 ’ ’ ) ;xsd . beginXSsequence ( ) ;//tipo di geoemtriaxsd . insertGMLgeometry ( type ) ;//campi col legat i al l ’ entita ‘St r ing [ ] cmps=cgg . cmps ( ent ) ;f o r each i {campi ( cmps [ i ] ) ;}

xsd . endXSsequence ( ) ;xsd . endXScomplexElement ( ) ;} e l s e {//entita ‘ temporale//elemento relativo al la geoemtriaxsd . beginXScomplexElement ( ‘ ‘ geometry ’ ’ , ‘ ‘ 1 ’ ’ , ‘ ‘ 1 ’ ’ ) ;xsd . beginXSsequence ( ) ;//supporto temporalexsd . beginXScomplexElement ( ‘ ‘ h i s t o r i c a lVa l u e ’ ’ ,

‘ ‘ 1 ’ ’ , ‘ ‘ unbounded ’ ’ , ) ;xsd . beginXSsequence ( ) ;//tipo di geometriaxsd . insertGMLgeometry ( type ) ;//dimensioni temporalidimensioniTemporal i ( f a l s e , ‘ ‘ ’ ’ , f a l s e ,

f a l s e , cgg . e t ( geo ) , f a l s e ) ;


xsd . endXSsequence ( ) ;d imens ioniTemporal i ( f a l s e , ‘ ‘ ’ ’ , cgg . vt ( geo ) ,

cgg . t t ( geo ) , f a l s e , cgg . at ( geo ) ) ;xsd . endXScomplexElement ( ) ;//campi col legat i al l ’ entita ‘St r ing [ ] cmps=cgg . cmps ( ent ) ;f o r each i {campi ( cmps [ i ] ) ;}

xsd . endXSsequence ( ) ;xsd . endXScomplexElement ( ) ;}}

//codif ica dei campivoid campi ( S t r ing cmp){St r ing name=cgg . cmpName(cmp ) ;S t r ing cmptype=cgg . cmpType(cmp ) ;S t r ing type ;i f ( ! cgg . tempCampo(cmp) ) then {//campo non temporale//elemento relativo al campoxsd . beginXScomplexElement (name , ‘ ‘ 1 ’ ’ , ‘ ‘ 1 ’ ’ ) ;xsd . beginXSsequence ( ) ;//elemento relativo al campionamentoxsd . beginXScomplexElement ( ‘ ‘ sample ’ ’ , ‘ ‘ 0 ’ ’ , ‘ ‘ unbounded ’ ’ ) ;xsd . beginXSsequence ( ) ;//tipo di campionamentoswitch ( cmptype ) {case ‘ ‘ campionamento i r r e g o l a r e d i punti ’ ’ : type=point ;case ‘ ‘ campionamento r e g o l a r e d i punti ’ ’ : type=point ;case ‘ ‘ i s o l i n e e ’ ’ : type=l i n e ;case ‘ ‘ po l i gon i ’ ’ : type=polygon ;case ‘ g r i g l i a r ego l a r e ‘ ’ ’ : type=polygon ;case ‘ ‘ r e t e t r i a n g o l a r e i r r e g o l a r e ’ ’ : type=polygon ;}

xsd . insertGMLgeometry ( type ) ;xsd . endXSsequence ( ) ;xsd . endXScomplexElement ( ) ;xsd . endXSsequence ( ) ;xsd . endXScomplexElement ( ) ;


} e l s e {//campo temporale//elemento relativo al campoxsd . beginXScomplexElement ( ‘ ‘ geometry ’ ’ , ‘ ‘ 1 ’ ’ , ‘ ‘ 1 ’ ’ ) ;xsd . beginXSsequence ( ) ;//supporto temporalexsd . beginXScomplexElement ( ‘ ‘ h i s t o r i c a lVa l u e ’ ’ ,

‘ ‘ 1 ’ ’ , ‘ ‘ unbounded ’ ’ , ) ;xsd . beginXSsequence ( ) ;//elemento relativo al campionamentoxsd . beginXScomplexElement ( ‘ ‘ sample ’ ’ , ‘ ‘ 0 ’ ’ , ‘ ‘ unbounded ’ ’ ) ;xsd . beginXSsequence ( ) ;//tipo di campionamentoswitch ( cmptype ) {case ‘ ‘ campionamento i r r e g o l a r e d i punti ’ ’ : type=point ;case ‘ ‘ campionamento r e g o l a r e d i punti ’ ’ : type=point ;case ‘ ‘ i s o l i n e e ’ ’ : type=l i n e ;case ‘ ‘ po l i gon i ’ ’ : type=polygon ;case ‘ g r i g l i a r ego l a r e ‘ ’ ’ : type=polygon ;case ‘ ‘ r e t e t r i a n g o l a r e i r r e g o l a r e ’ ’ : type=polygon ;}

xsd . insertGMLgeometry ( type ) ;xsd . endXSsequence ( ) ;xsd . endXScomplexElement ( ) ;//dimensioni temporalidimensioniTemporal i ( f a l s e , ‘ ‘ ’ ’ , f a l s e ,

f a l s e , cgg . e t ( a t t ) , f a l s e ) ;xsd . endXSsequence ( ) ;d imens ioniTemporal i ( f a l s e , ‘ ‘ ’ ’ , cgg . vt ( a t t ) ,

cgg . t t ( a t t ) , f a l s e , cgg . at ( a t t ) ) ;xsd . endXScomplexElement ( ) ;xsd . endXSsequence ( ) ;xsd . endXScomplexElement ( ) ;}}

//codif ica delle relazioni topologichevoid r e l a z i on iTopo l o g i c h e ( S t r ing r e l ){//tipo di relazione topologicaSt r ing type=cgg . topolType ( r e l ) ;//elemento di segnalazione del


//tipo di relazione topologicaxsd . insertXSemptyElement ( type , ‘ ‘ 1 ’ ’ , ‘ ‘ 1 ’ ’ ) ;}

//codif ica delle dimensioni temporalivoid dimensioniTemporal i ( boolean l s , S t r ing ent ,

boolean vt , boolean tt , boolean et , boolean at ){//traduzione delle dimensioni temporali//per entita ‘ con li fespani f ( l s ) then {St r ing [ ] s t a t e s=lsDiagramStates ( ent ) ;//elemento relativo al l i fespanxsd . beginXScomplexElement ( ‘ ‘ l i f e s p an ’ ’ , ‘ ‘ 1 ’ ’ , ‘ ‘ 1 ’ ’ ) ;xsd . beginXSsequence ( ) ;xsd . beginXScomplexElement ( ‘ ‘ h i s t o r i c a lVa l u e ’ ’ ,

‘ ‘ 1 ’ ’ , ‘ ‘ unbounded ’ ’ , ) ;xsd . beginXSsequence ( ) ;//tempo dell ’ eventoi f ( e t ) {St r ing [ ] events=cgg . events ( cons t r ) ;//definizione degli stat i se non ci sono eventi//col legat i al l ’ entita ‘i f ( events [ ] . l enght=0) then {xsd . beginXSsimpleElement ( ‘ ‘ value ’ ’ , ‘ ‘ 1 ’ ’ , ‘ ‘ 1 ’ ’ ) ;xsd . beg inXSre s t r i c t i onDe f ( ‘ ‘ xs : s t r i ng ’ ’ ) ;f o r each i {//enumerazione degli stat ixsd . insertXSenumerationDef ( s t a t e s [ i ] ) ;}

xsd . endXSres t r i c t i onDe f ( ) ;xsd . endXSsimpleElement ( ) ;//istante in i z i a l e del etxsd . beginXScomplexElement ( ‘ ‘ s tartEvent ’ ’ , ‘ ‘ 1 ’ ’ , ‘ ‘ 1 ’ ’ ) ;xsd . i n s e r tXSa t t r i bu t e ( ‘ ‘ eventTime ’ ’ , ‘ ‘ xs : dateTime ’ ’ ) ;xsd . endXScomplexElement ( ) ;//istante f inale del etxsd . beginXScomplexElement ( ‘ ‘ endEvent ’ ’ , ‘ ‘ 0 ’ ’ , ‘ ‘ 1 ’ ’ ) ;xsd . i n s e r tXSa t t r i bu t e ( ‘ ‘ eventTime ’ ’ , ‘ ‘ xs : dateTime ’ ’ ) ;xsd . endXScomplexElement ( ) ;} e l s e {//definizione degli stat i se c i sono eventi


//col legat i al l ’ entita ‘xsd . beginXSchoiceDef ( ‘ ‘ 1 ’ ’ ) ;f o r each i {//per ogni statoxsd . insertXScomplexElement ( s t a t e s [ i ] , ‘ ‘ 1 ’ ’ , ‘ ‘ 1 ’ ’ )xsd . beginXSsequence ( ) ;//evento in i z i a l exsd . beginXScomplexElement ( ‘ ‘ s tartEvent ’ ’ , ‘ ‘ 1 ’ ’ , ‘ ‘ 1 ’ ’ ) ;xsd . i n s e r tXSa t t r i bu t e ( ‘ ‘ eventTime ’ ’ , ‘ ‘ xs : dateTime ’ ’ ) ;//se ci sono eventi che posso essere// i n i z i a l i per questo statoi f ( cgg . s ta r tOf ( s t a t e s [ i ] ) ) then {xsd . startXScomplexAttr ibute ( ‘ ‘ t ipo ’ ’ ) ;xsd . beg inXSre s t r i c t i onDe f ( ‘ ‘ xs : s t r i ng ’ ’ ) ;f o r each j {//t ip i di eventi i n i z i a l ii f ( cgg . eventStartOf ( events [ j ] ) , s t a t e s [ i ] ) then {xsd . insertXSenumerationDef ( events [ j ] ) ;}}}

xsd . endXScomplexAttribute ( ) ;xsd . endXScomplexElement ( ) ;//evento f inalexsd . beginXScomplexElement ( ‘ ‘ endEvent ’ ’ , ‘ ‘ 0 ’ ’ , ‘ ‘ 1 ’ ’ ) ;xsd . i n s e r tXSa t t r i bu t e ( ‘ ‘ eventTime ’ ’ , ‘ ‘ xs : dateTime ’ ’ ) ;//se ci sono eventi che posso essere// f i na l i per questo statoi f ( cgg . endOf ( s t a t e s [ i ] ) ) then {xsd . startXScomplexAttr ibute ( ‘ ‘ t ipo ’ ’ ) ;xsd . beg inXSre s t r i c t i onDe f ( ‘ ‘ xs : s t r i ng ’ ’ ) ;

f o r each j {//t ip i di eventi f i na l ii f ( cgg . eventEndOf ( events [ j ] ) , s t a t e s [ i ] ) then {xsd . insertXSenumerationDef ( events [ j ] ) ;}}}

xsd . endXScomplexAttribute ( ) ;xsd . endXScomplexElement ( ) ;//chiusura dell ’ elemento relativo al lo stato


xsd . endXSsequence ( ) ;// in iz io e f ine di validita ‘ dello statoxsd . i n s e r tXSa t t r i bu t e ( ‘ ‘ startTime ’ ’ , ‘ ‘ xs : dateTime ’ ’ ) ;xsd . i n s e r tXSa t t r i bu t e ( ‘ ‘ endTime ’ ’ , ‘ ‘ xs : dateTime ’ ’

‘ ‘ opt iona l ’ ’ ) ;xsd . endXScomplexElement ( ) ;}

xsd . endXSchoiceDef ;//chiusura codif ica et}}

xsd . endXSsequence ( ) ;//attributi dell ’ elemento historicalValue//tempo di transazione dell ’ entita ‘ con lifespani f ( t t ) then {xsd . i n s e r tXSa t t r i bu t e ( ‘ ‘ t t i ’ ’ , ‘ ‘ xs : dateTime ’ ’ ) ;xsd . i n s e r tXSa t t r i bu t e ( ‘ ‘ t t f ’ ’ , ‘ ‘ xs : dateTime ’ ’

‘ ‘ opt iona l ’ ’ ) ;}

//tempo di disponibil ita ‘ dell ’ entita ‘ con lifespani f ( at ) then {xsd . i n s e r tXSa t t r i bu t e ( ‘ ‘ a t i ’ ’ , ‘ ‘ xs : dateTime ’ ’ ) ;xsd . i n s e r tXSa t t r i bu t e ( ‘ ‘ a t f ’ ’ , ‘ ‘ xs : dateTime ’ ’

‘ ‘ opt iona l ’ ’ ) ;}

//chiusura dell ’ elemento historicalValuexsd . endXScomplexElement ( ) ;//chiusura dell ’ elemento relativo al l i fespanxsd . endXSsequence ( ) ;xsd . endXScomplexElement ( ) ;} e l s e {//traduzione delle dimensioni temporali//per attributi , relazioni , aggregazioni , campi ,//ed entita ‘ senza supporto li fespan

//tempo dell ’ eventoi f ( e t ) then {St r ing [ ] events=cgg . events ( cons t r ) ;i f ( events [ ] . l enght=0) then {xsd . beginXScomplexElement ( ‘ ‘ s tartEvent ’ ’ , ‘ ‘ 1 ’ ’ , ‘ ‘ 1 ’ ’ ) ;xsd . i n s e r tXSa t t r i bu t e ( ‘ ‘ eventTime ’ ’ , ‘ ‘ xs : dateTime ’ ’ ) ;


xsd . endXScomplexElement ( ) ;xsd . beginXScomplexElement ( ‘ ‘ endEvent ’ ’ , ‘ ‘ 0 ’ ’ , ‘ ‘ 1 ’ ’ ) ;xsd . i n s e r tXSa t t r i bu t e ( ‘ ‘ eventTime ’ ’ , ‘ ‘ xs : dateTime ’ ’ ) ;xsd . endXScomplexElement ( ) ;} e l s e {xsd . beginXSchoiceDef ( ‘ ‘ 1 ’ ’ ) ;//evento in i z i a l exsd . beginXScomplexElement ( ‘ ‘ s tartEvent ’ ’ , ‘ ‘ 1 ’ ’ , ‘ ‘ 1 ’ ’ ) ;xsd . i n s e r tXSa t t r i bu t e ( ‘ ‘ eventTime ’ ’ , ‘ ‘ xs : dateTime ’ ’ ) ;i f ( cgg . s ta r tOf ( c o s t r ) ) then {xsd . startXScomplexAttr ibute ( ‘ ‘ t ipo ’ ’ ) ;xsd . beg inXSre s t r i c t i onDe f ( ‘ ‘ xs : s t r i ng ’ ’ ) ;f o r each j {i f ( cgg . eventStartOf ( events [ j ] ) , c o s t r ) then {xsd . insertXSenumerationDef ( events [ j ] ) ;}}}

xsd . endXScomplexAttribute ( ) ;xsd . endXScomplexElement ( ) ;//evento f inalexsd . beginXScomplexElement ( ‘ ‘ endEvent ’ ’ , ‘ ‘ 0 ’ ’ , ‘ ‘ 1 ’ ’ ) ;xsd . i n s e r tXSa t t r i bu t e ( ‘ ‘ eventTime ’ ’ , ‘ ‘ xs : dateTime ’ ’ ) ;i f ( cgg . endOf ( c o s t r ) ) then {xsd . startXScomplexAttr ibute ( ‘ ‘ t ipo ’ ’ ) ;xsd . beg inXSre s t r i c t i onDe f ( ‘ ‘ xs : s t r i ng ’ ’ ) ;f o r each j {i f ( cgg . eventEndOf ( events [ j ] ) , c o s t r ) then {xsd . insertXSenumerationDef ( events [ j ] ) ;}}}

xsd . endXScomplexAttribute ( ) ;xsd . endXScomplexElement ( ) ;xsd . endXSchoiceDef ( ) ;}//chiusura tempo dell ’ evento}

//tempo di validita ‘i f ( vt ) then {xsd . i n s e r tXSa t t r i bu t e ( ‘ ‘ vt i ’ ’ , ‘ ‘ xs : dateTime ’ ’ ) ;


xsd . i n s e r tXSa t t r i bu t e ( ‘ ‘ vt f ’ ’ , ‘ ‘ xs : dateTime ’ ’‘ ‘ opt iona l ’ ’ ) ;

}//tempo di transazionei f ( t t ) then {xsd . i n s e r tXSa t t r i bu t e ( ‘ ‘ t t i ’ ’ , ‘ ‘ xs : dateTime ’ ’ ) ;xsd . i n s e r tXSa t t r i bu t e ( ‘ ‘ t t f ’ ’ , ‘ ‘ xs : dateTime ’ ’

‘ ‘ opt iona l ’ ’ ) ;}

//tempo di disponibil ita ‘i f ( at ) then {xsd . i n s e r tXSa t t r i bu t e ( ‘ ‘ a t i ’ ’ , ‘ ‘ xs : dateTime ’ ’ ) ;xsd . i n s e r tXSa t t r i bu t e ( ‘ ‘ a t f ’ ’ , ‘ ‘ xs : dateTime ’ ’

‘ ‘ opt iona l ’ ’ ) ;}}}

//definizione delle condizioni di inclusione (C. I . )boolean includeC ( St r ing other , S t r ing r e l ){//ritorna true se le C. I . sono soddisfatteboolean includeCond=true ;i f ( r e l L i s t . readCodi f ( r e l ) ) then {includeCond=f a l s e ;}

i f ( ! ( ( cgg . cardMin ( other , r e l )= ‘ ‘1 ’ ’ )and ( cgg . cardMax ( other , r e l )= ‘ ‘ 1 ’ ’ ) ) ) then {

includeCond=f a l s e ;}

i f ( ! cgg . i s I dRe l ( other , r e l ) ) then {includeCond=f a l s e ;}

i f ( i sSubClas s ( other ) ) then {includeCond=f a l s e ;}

i f ( f i r s t L e v e l En t i t y ( other ) ) then {includeCond=f a l s e ;}

i f ( tempR( r e l ) ) then {includeCond=f a l s e ;


}re turn includeCond ;}

//Metodi aggiuntivi

//codif ica degli attributivoid a t t r i b u t i ( S t r ing cos t r , S t r ing att , boolean opz ,

boolean mVal , boolean comp){//codif ica degli attributi di un costruttoSt r ing min ;S t r ing max ;S t r ing type=attType ( a t t )i f ( opz ) then { min= ‘ ‘0 ’ ’ ; }i f (mVal) then { max= ‘ ‘unbounded ’ ’ ; }i f ( ! cgg . tempA( at t ) ) then {//attributi non temporalii f ( ! comp) then {//attributi non compostixsd . insertXSelement ( att , type , min , max ) ;} e l s e {//attributi compostixsd . beginXScomplexElement ( att , min , max ) ;xsd . beginXSsequence ( ) ;S t r ing [ ] comps=cgg . comps ( cos t r , a t t ) ;f o r each i {a t t r i b u t i ( cos t r , comps [ i ] , cgg . opz ( cos t r , comps [ i ] ) ,

cgg . mVal( cos t r , comps [ i ] ) , cgg . comp( cos t r , comps [ i ] ) ) ;}

xsd . endXSsequence ( ) ;xsd . endXScomplexElement ( ) ;}} e l s e {//attributi temporalixsd . beginXScomplexElement ( att , min , max ) ;xsd . beginXSsequence ( ) ;xsd . beginXScomplexElement ( ‘ ‘ h i s t o r i c a lVa l u e ’ ’ , ‘ ‘ 1 ’ ’ ,

cgg . attCardMaxLS ( cos t r , a t t ) ) ;xsd . beginXSsequence ( ) ;i f ( ! comp) then {


//attributi non compostixsd . insertXSelement ( ‘ ‘ value ’ ’ , type , ‘ ‘ 1 ’ ’ , ‘ ‘ 1 ’ ’ ) ;} e l s e {//attributi compostixsd . beginXScomplexElement ( ‘ ‘ value ’ ’ , ‘ ‘ 1 ’ ’ , ‘ ‘ 1 ’ ’ ) ;xsd . beginXSsequence ( ) ;S t r ing [ ] comps=cgg . comps ( cos t r , a t t ) ;f o r each i {a t t r i b u t i ( cos t r , comps [ i ] , cgg . opz ( cos t r , comps [ i ] ) ,

cgg . mVal( cos t r , comps [ i ] ) , cgg . comp( cos t r , comps [ i ] ) ) ;}

xsd . endXSsequence ( ) ;xsd . endXScomplexElement ( ) ;}

//codif ica delle dimensioni temporali degli attributidimensioniTemporal i ( f a l s e , ‘ ‘ ’ ’ , f a l s e , f a l s e ,

cgg . e t ( cos t r , a t t ) , f a l s e ) ;xsd . endXSsequence ( ) ;d imens ioniTemporal i ( f a l s e , ‘ ‘ ’ ’ , cgg . vt ( cos t r , a t t ) ,

cgg . t t ( cos t r , a t t ) , f a l s e , cgg . at ( cos t r , a t t ) ) ;xsd . endXScomplexElement ( ) ;xsd . endXSsequence ( ) ;xsd . endXScomplexElement ( ) ;}}

//metodo di supporto per relazioni e aggregazionivoid re lSupport ( cggL i s t o the r sL i s t , S t r ing ent ,

S t r ing min , S t r ing max , S t r ing c o s t r ){//leggere la prima delle altre entita ‘//che partecipano al la relazioneSt r ing other=o th e r sL i s t . readNext ( ) ;i f ( ! o t h e r sL i s t . theEnd ( ) and i sRe l ( c o s t r ) ) then {St r ing otherMin=cgg . cardMin ( other , c o s t r ) ;S t r ing otherMax=cgg . cardMax ( other , c o s t r ) ;

}//se tale entita ‘ non e ‘ ancora stata codif icatai f ( ! e n tL i s t . readCodi f ( other ) ) then {//mantenere in memoria la posizione//di scrittura e saltare


xsd . setReturn ( ) ;//codif ica dell ’ entita ‘en t i t a ( other , ‘ ‘ 0 ’ ’ , ‘ ‘ unbounded ’ ’ ) ;//recuperare la posizione di scrittura precedentexsd . getReturn ( ) ;}

i f ( ! cgg . tempR( c o s t r ) ) then {//relazione o aggregazione di tipo non temporale//elemento per i l riferimento al l ’ altra entita ‘xsd . beginXScomplexElement ( other , min , max ) ;xsd . beginXSsequence ( ) ;//se i l costrutto e ‘ una relazionei f ( i sRe l ( c o s t r ) ) then {i f ( ! topo log ( c o s t r ) ) then {//codif ica della relazione topologica

r e l a i z i o n iTopo l o g i c h e ( c o s t r ) ;}}

//codif ica degli attributi chiave dell ’ altra entita ‘St r ing [ ] otherEntKeys=cgg . key ( other ) ;f o r each k {a t t r i b u t i ( other , otherEntKeys [ k ] , f a l s e ,

f a l s e , cgg . comp( other , otherEntKeys [ k ] ) ) ;//relazioni ident i f icant i dell ’ altra entita ‘St r ing [ ] i d r e l s=cgg . idRe l s ( other ) ;i f ( i d r e l s [ ] . l enght >0) then {r e l a z i o n i I d e n t i f i c a n t i ( other , i d r e l s [ ] ) ;}}

//segnalare l ’ entita ‘ come codif icata nella l i s t a//delle entita ‘ che partecipano al la relazioneo th e r sL i s t . s e tCod i f ( other ) ;//se non sono ancora state codi f i cat i tutti// i riferimenti a l l e entita ‘ parteciapantii f ( ! o t h e r sL i s t . theEnd ( ) ) then {re lSupport ( o the r sL i s t , other , otherMin ,

otherMax , c o s t r ) ;}

//se e ‘ una relazione , codif ica degli attributi//della relazionei f ( i sRe l ( c o s t r ) ) then {


St r ing [ ] a t t=cgg . r e lA t t s ( c o s t r ) ;f o r each i then {a t t r i b u t i ( cos t r , a t t [ i ] , cgg . opz ( cos t r , a t t [ i ] ) ,

cgg . mVal( cos t r , a t t [ i ] ) , cgg . comp( cos t r , a t t [ i ] ) ) ;}}

//chiusura dell ’ elemento di riferimento al l ’ entita ‘xsd . endXSsequence ( ) ;xsd . endXScomplexElement ( ) ;//riferimento a chiaveSt r ing [ ] otherEntTotalKeys=cgg . tota lKey ( other ) ;refName=ent . ‘ ‘ RefTo ’ ’ . o ther . ‘ ‘ InRel ’ ’ . c o s t r ;keyToRef=ent . ‘ ‘ Key ’ ’ ;xsd . in se r tXSkeyre fDe f ( refName , keyToRef ,

other , otherEntTotalKeys [ ] )//codif ica del vincolo di cardinalita ‘ minima 1i f ( otherMax= ‘ ‘ 1 ’ ’ ) then {uniqueName= ‘ ‘ unique ’ ’ . o ther ;xsd . insertXSuniqueDef ( uniqueName , other ,

otherEntKeys [ ] )}} e l s e {//relazioni o aggregazioni di tipo temporalexsd . beginXScomplexElement ( other , min , max ) ;xsd . beginXSsequence ( ) ;//cardinalita ‘ l i fespani f ( i sRe l ( c o s t r ) ) then {St r ing maxLS=cgg . cardMaxLS( ent , c o s t r ) ;

} e l s e {St r ing maxLS=cgg . partMaxCardLS ( ent , arg , par t s [ i ] ) ;}

xsd . beginXScomplexElement ( ‘ ‘ h i s t o r i c a lVa l u e ’ ’ , min ,max ) ;

xsd . beginXSsequence ( ) ;//se i l costrutto e ‘ una relazione topologica//definizione del tipoi f ( i sRe l ( c o s t r ) ) then {

i f ( topo log ( c o s t r ) ) then {r e l a i z i o n iTopo l o g i c h e ( c o s t r ) ;

}}


//codif ica degli attributi chiave dell ’ altra entita ‘//che partecipa al la relazione o aggregazioneSt r ing [ ] otherEntKeys=cgg . key ( other ) ;f o r each k {a t t r i b u t i ( other , otherEntKeys [ k ] , f a l s e ,

f a l s e , cgg . comp( other , otherEntKeys [ k ] ) ) ;//relazioni ident i f icant i dell ’ altra entita ‘St r ing [ ] i d r e l s=cgg . idRe l s ( other ) ;i f ( i d r e l s [ ] . l enght >0) then {r e l a z i o n i I d e n t i f i c a n t i ( other , i d r e l s [ ] ) ;}}

//tempo dell ’ eventodimensioniTemporal i ( f a l s e , ‘ ‘ ’ ’ , f a l s e , f a l s e ,

cgg . e t ( c o s t r ) , f a l s e ) ;//se i l costrutto e ‘ una relazionei f ( i sRe l ( c o s t r ) ) then {//altre entita ‘ partecipanti a l la relazioneo th e r sL i s t . s e tCod i f ( other ) ;i f ( ! o t h e r sL i s t . theEnd ( ) ) then {re lSupport ( o the r sL i s t , other , otherMin , otherMax , c o s t r ) ;}}

//attributi della relazioneSt r ing [ ] a t t=cgg . r e lA t t s ( c o s t r ) ;f o r each i then {a t t r i b u t i ( cos t r , a t t [ i ] , cgg . opz ( cos t r , a t t [ i ] ) ,

cgg . mVal( cos t r , a t t [ i ] ) , cgg . comp( cos t r , a t t [ i ] ) ) ;}

xsd . endXSsequence ( ) ;//altre dimensioni temporalidimensioniTemporal i ( f a l s e , ‘ ‘ ’ ’ , cgg . vt ( c o s t r ) ,

cgg . t t ( c o s t r ) , f a l s e , cgg . at ( c o s t r ) ) ;xsd . endXScomplexElement ( ) ;xsd . endXSsequence ( ) ;xsd . endXScomplexElement ( ) ;//riferimento a chiaveSt r ing [ ] otherEntTotalKeys=cgg . tota lKeys ( other ) ;refName=ent . ‘ ‘ RefTo ’ ’ . o ther . ‘ ‘ InRel ’ ’ . c o s t r ;keyToRef=ent . ‘ ‘ Key ’ ’ ;xsd . in se r tXSkeyre fDe f ( refName , keyToRef , ‘ ‘ h i s t o r i c a lVa l u e ’ ’ ,


otherEntTotalKeys [ ] )//codif ica del vincolo di cardinalita ‘ minima 1i f ( otherMax= ‘ ‘ 1 ’ ’ ) then {uniqueName= ‘ ‘ unique ’ ’ . o ther ;xsd . insertXSuniqueDef ( uniqueName , ‘ ‘ h i s t o r i c a lVa l u e ’ ’ ,

otherEntKeys [ ] )}}}

//relazione di supporto per la definizione di riferimenti//a chiave di entita ‘ debolivoid r e l a z i o n i I d e n t i f i c a n t i ( S t r ing other , S t r ing [ ] i d r e l s ){//per ogni relazione o aggregazione identif icantef o r each a {//se e ‘ una relazionei f ( i sRe l ( i d r e l s [ a ] ) ) {St r ing [ ] idEnt=cgg . othersName ( other , i d r e l s [ a ] )//per ogni altra entita ‘ che partecipa al la relazionef o r each b {St r ing [ ] otherIdEntKeys=cgg . key ( idEnt [ b ] ) ;xsd . beginXScomplexElement ( idEnt [ b ] , ‘ ‘ 1 ’ ’ , ‘ ‘ 1 ’ ’ ) ;xsd . beginXSsequence ( ) ;//per ogni attributo dell ’ entita ‘ fortef o r each c {a t t r i b u t i ( idEnt [ b ] , otherEntKeys [ c ] , f a l s e ,

f a l s e , cgg . comp( other , otherEntKeys [ c ] ) ) ;i f ( topo log ( i d r e l s [ a ] ) ) then {r e l a i z i o n iTopo l o g i c h e ( d r e l s [ a ] ) ;}

St r ing [ ] o t h e r I d r e l s=cgg . idRe l s ( idEnt [ b ] ) ;i f ( o t h e r I d r e l s [ ] . l enght >0) then {r e l z i o n i I d e n t i f i c a n t i ( idEnt [ b ] , o t h e r I d r e l s [ ] ) ;

xsd . endXSsequence ;xsd . endXScomplexElement ( ) ;}} e l s e {//se e ‘ una aggregazioneSt r ing whole=cgg . wholeName( other , i d r e l s [ a ] )//data l ’ entita ‘ interoSt r ing [ ] wholeIdEntKeys=cgg . key ( whole ) ;


xsd . beginXScomplexElement ( whole , ‘ ‘ 1 ’ ’ , ‘ ‘ 1 ’ ’ ) ;xsd . beginXSsequence ( ) ;//per ogni attributo dell ’ entita ‘ interof o r each c {a t t r i b u t i ( whole , wholeEntKeys [ c ] , f a l s e ,

f a l s e , cgg . comp( whole , wholeEntKeys [ c ] ) ) ;//relazioni ident i f icant i dell ’ entita ‘ interoSt r ing [ ] o t h e r I d r e l s=cgg . idRe l s ( whole ) ;i f ( o t h e r I d r e l s [ ] . l enght >0) then {r e l z i o n i I d e n t i f i c a n t i ( whole , o t h e r I d r e l s [ ] ) ;}

xsd . endXSsequence ;xsd . endXScomplexElement ( ) ;}}

5.3.2 La classe “cggList”

c l a s s cggL i s t {

//classe per le l i s t e

i n t l a s t ;i n t read ;i n t t o t a l ;S t r ing names [ ] ;boolean c od i f [ ] ;

L i s t ( i n t num){names [ ] = new St r ing [num ] ;c o d i f [ ] = new boolean [num ] ;read=0;l a s t =1;t o t a l=num;}

//inserimento nella l i s t avoid i n s e r t ( S t r ing name){


i f ( ! i nL i s t (name ) ) {names [ l a s t ]=name ;c od i f [ l a s t ]= f a l s e ;l a s t++;}}

boolean i nL i s t ( S t r ing name){boolean i n l i s t=f a l s e ;f o r i from 1 to t o t a li f (name=names [ i ] ) {i n l i s t=true ;}

re turn i n l i s t ;}

//lettura dalla l i s t aSt r ing readNext ( ){boolean cont inue=true ;S t r ing next ;whi l e ( cont inue ) {read++;next=names [ read ] ;cont inue=readCodi f ( next ) ;}

re turn next ;}

//leggere se codif icatoboolean readCodi f ( S t r ing name){i n t toRead ;f o r i from 1 to t o t a l {i f names [ i ]=name then toRead=i ;}

re turn c od i f [ toRead ] ;}

//segnalare come codif icatos e tCod i f ( S t r ing name){i n t toSet ;f o r i from 0 to t o t a l {


i f names [ i ]=name then { toSet=i ; }}

c od i f [ toSet ]= true ;}

//leggere se tutti g l i elementi//sono codi f i cat itheEnd ( ){boolean end=true ;f o r i from 0 to t o t a li f c o d i f [ i ]= f a l s e then end=f a l s e ;

r e turn end ;}

}

5.3.3 La classe “cggSchema”

c l a s s cggSchema{

//Si presuppone che questa classe possa leggere lo//schema ChronoGeoGraph in questione//o una sua esportazione in forma testuale (o altro ) .

//Schema

cggSchema ( St r ing schema ){//la classe pu leggere dallo schema specif icato}

i n t entNum(){//ritorna i l numero totale delle entita ‘}

i n t relNum (){//ritorna i l numero totale delle relazioni}


St r ing Name(){//ritorna i l nome dello schema}

//Territorio di schema

boolean t s ( ){//ritorna true se lo schema contiene un//terr itor io di schema}

St r ing tsName ( ){//ritorna i l nome del terr itor io di schema}

St r ing tsGeo ( ){//ritorna i l tipo di geometria del terr itor io di schema}

//Entita ‘ ed attributi

St r ing [ ] ents ( ){//ritorna un elenco delle entita ‘ ordinate per nome}

St r ing [ ] key ( S t r ing ent ){//ritorna un elenco degli attributi che//formano la chiave dell ’ entita ‘//non tenendo conto delle relazioni ident i f icant i//ordinati per nome}

St r ing [ ] tota lKey ( St r ing ent ){//richiama key(ent) se l ’ entita ‘ non e ‘ debole ,//nel caso di entita ‘ deboli//ritorna un elenco degli attributi che formano la//chiave parziale dell ’ entita ‘ ordinati per nome//e poi ( se l ’ entita ‘ non e ‘ stata codif icata come


//sottoelemento dell ’ entita ‘ forte ) i nomi delle//entita ‘ collegate al l ’ entita ‘ speci f icata//da relazioni o aggregazioni ident i f icant i per l ’ entita ‘//speci f icata ordinati per nome}

St r ing [ ] i dRe l s ( S t r ing ent ){//ritorna un elenco delle relazioni e/o aggregazioni// ident i f icant i dell ’ entita ‘ speci f icata}

boolean i s I dRe l ( S t r ing ent , S t r ing c o s t r ){//ritorna true se la relazione speci f icata e ‘//identif icante per l ’ entita ‘ in questioneboolean i s i d r e l=f a l s e ;S t r ing [ ] i d r e l s=idRe l s ( ent ) ;f o r each i {i f ( i d r e l s [ i ]= co s t r ) then { i s i d r e l=true ; }}

re turn i s i d r e l ;}

boolean spaz ( St r ing ent ){//ritorna true se l ’ entita ‘ speci f icata e ‘ georeferenziata}

St r ing geoType ( St r ing ent ){//ritorna tipo di geometria di una entita ‘ georeferenziata}

boolean tempE( St r ing ent ){boolean temp=f a l s e ;i f ( l s ( ent ) ) then { temp=true ; }i f ( t t ( ent ) ) then { temp=true ; }i f ( e t ( ent ) ) then { temp=true ; }i f ( at ( ent ) ) then { temp=true ; }re turn temp ;}

boolean f i r s t L e v e l En t i t y ( S t r ing ent ){boolean f l e=true ;


St r ing [ ] r e l=re lEnt s ( ent ) ;f o r each i {i f ( ( cardMin ( ent , r e l [ i ] )=1)

and ( cardMax ( ent , r e l [ i ] )=1)) then {f l e=f a l s e ;}

i f ( i sSubClas s ( ent ) ) then { f l e=f a l s e ; }re turn f l e ;}

boolean tempA( St r ing at t ){boolean temp=f a l s e ;i f ( vt ( a t t ) ) then { temp=true ; }i f ( t t ( a t t ) ) then { temp=true ; }i f ( e t ( a t t ) ) then { temp=true ; }i f ( at ( a t t ) ) then { temp=true ; }re turn temp ;}

St r ing [ ] a t t s ( S t r ing ent ){//ritorna un elenco degli attributi dell ’ entita ‘//speci f icata ordinati per nome}

St r ing [ ] r e lA t t s ( S t r ing r e l ){//ritorna un elenco degli attributi della//relazione speci f icata ordinati per nome}

//Si suppone che ad ogni attributo sia associato//uno dei t ip i sotto indicatiSt r ing attType ( St r ing at t ){//ritorna ritorna i l tipo dell ’ attributo//integer , double , date , time , string}

boolean opzn ( St r ing cos t r , S t r ing at t ){//ritorna true se l ’ attributo indicato relativo al//costrutto specif icato speci f icata e ‘ opzionale}


boolean mVal( S t r ing cos t r , S t r ing at t ){//ritorna true se l ’ attributo indicato relativo al//costrutto specif icato speci f icata e ‘ multivalore}

i n t attCardMaxLS ( St r ing cos t r , S t r ing at t ){// i l valore della cardinalita ‘ massima lifespan//dell ’ attributo del costrutto specif icato}

boolean comp( St r ing cos t r , S t r ing at t ){//ritorna true se l ’ attributo indicato relativo al//costrutto specif icato speci f icata e ‘ composto}

St r ing [ ] comps ( St r ing cos t r , S t r ing at t ){//ritorna un elenco dei sottoattributi dell ’ attributo//del costrutto specif icato ordinati per nome//nullo se l ’ attributo non e ‘ composto}

//Relazioni e Aggregazioni

St r ing [ ] r e l s ( ){//ritorna un elenco delle relazioni dello schema//ordinate per nome}

St r ing [ ] r e l sEnt ( S t r ing ent ){//ritorna un elenco delle relazioni a cui//l ’ entita ‘ speci f icata partecipa ordinate per nome}

St r ing [ ] r e l L i nk s ( S t r ing r e l ){//ritorna un elenco delle entita ‘ che partecipano//al la relazione ordinate per nome}

boolean tempR( St r ing c o s t r ){//ritorna true se i l costrutto


//( relazione o aggregazione)//e ‘ di tipo temporale}

boolean topo log ( St r ing r e l ){//ritorna true se la relazione e ‘ topologica}

St r ing topolType ( St r ing r e l ){//ritorna i l tipo di relazione topologica}

boolean b ina r i a ( S t r ing r e l ){//ritorna true se la relazione indicata//e ‘ binaria}

boolean n−a r i a ( S t r ing ent , S t r ing r e l ){//ritorna true se la relazione indicata e ‘ n−aria}

i n t cardMin ( St r ing ent , S t r ing r e l ){// i l valore della cardinalita ‘ minima snapshot//con cui l ’ entita ‘ partecipa al la relazione}

i n t cardMax ( St r ing ent , S t r ing r e l ){// i l valore della cardinalita ‘ massima snapshot//con cui l ’ entita ‘ partecipa al la relazione}

i n t cardMaxLS( St r ing ent , S t r ing r e l ){// i l valore della cardinalita ‘ massima lifespan//con cui l ’ entita ‘ partecipa al la relazione}

St r ing [ ] othersName ( St r ing ent , S t r ing r e l ){//ritorna la l i s t a delle altre entita ‘ che partecipano//ad una relazione


//ordinate per nome dell ’ entita ‘}

boolean i sRe l ( S t r ing c o s t r ){//ritorna true se i l costrutto e ‘ una relazione}

St r ing [ ] agrs ( S t r ing ent ){//ritorna un elenco delle aggregazioni (di ogni tipo )//a cui l ’ entita ‘ speci f icata partecipa in qualita ‘ di//intero (con un quals iasi ordine per ident i f i cat iv i )}

St r ing wholeName( St r ing ent , S t r ing agg ){//ritorna i l nome delle entita ‘ intero//dell ’ aggregazione speci f icata}

St r ing [ ] agrParts ( S t r ing ent , S t r ing agr ){//ritorna un elenco delle entita ‘ che partecipano//in qualita ‘ di parti a l l ’ aggregazione a cui//l ’ entita ‘ speci f icata partecipa come intero}

St r ing partMinCard ( St r ing ent , S t r ing agr , S t r ing part ){//ritorna la cardinalita ‘ minima con cui la//part partecipa al l ’ intero}

St r ing partMaxCard ( St r ing ent , S t r ing agr , S t r ing part ){//ritorna la cardinalita ‘ massima con cui la//part partecipa al l ’ intero}

St r ing partMaxCardLS ( St r ing ent , S t r ing agr , S t r ing part ){//ritorna la cardinalita ‘ massima lifespan con cui la//part partecipa al l ’ intero}

//Specializzazioni


St r ing [ ] spcs ( S t r ing ent ){//ritorna un elenco delle sottoclass i della//specializzazione a cui l ’ entita ‘ speci f icata//partecipa in qualita ‘ di superclasse ordinate per nome//lunghezza 0 se non ci sono sottoclass i}

boolean i sSubClas s ( S t r ing ent ){//ritorna true se l ’ entita ‘ e ‘ sottoclasse in//una specializzazioneboolean i s s u b c l a s s=f a l s e ;S t r ing [ ] e n t i t i e s=ents ( ) ;f o r each i {St r ing [ ] subClass=spec ( e n t i t i e s [ i ] ) ;f o r each j {i f ( subClass [ j ]= ent ) then { i s s u b c l a s s=true ; }}}

re turn i s s u b c l a s s ;}

boolean spcDisg ( S t r ing ent ){//ritorna true se la specializzazione e ‘ disgiunta}

boolean spcSvrp ( St r ing ent ){//ritorna true se la specializzazione//e ‘ con sovrapposizione}

boolean spcTot ( St r ing ent ){//ritorna true se la specializzazione//e ‘ totale}

//Campi

St r ing [ ] cmps ( S t r ing ent ){//ritorna un elenco dei campi col legat i a l l ’ entita ‘


//speci f icata ordinati per nome}

St r ing [ ] cmpsTS(){//ritorna un elenco dei campi col legat i al//terr itor io di schema ordinati per nome}

boolean tempCampo( St r ing cmp){//ritorna true se i l campo ha supporto//temporale}

St r ing cmpName( St r ing cmp){//ritorna i l nome del campo}

St r ing cmpType( St r ing cmp){//ritorna i l tipo di campo}

//Dimensioni temporali

St r ing [ ] l sDiagramStates ( S t r ing ent ){//ritorna la l i s t a degli stat i del diagramma//legato al l i fespan dell ’ entita ‘//se non specif icato viene perso in considerazione// i l diagramma di default}

boolean l s ( S t r ing ent ){//ritorna true se l ’ entita ‘ speci f icata ha//li fespan}

boolean vt ( S t r ing cos t r , S t r ing at t ){//ritorna true se l ’ attributo del costrutto ha//tempo di validita ‘}


boolean t t ( S t r ing cos t r , S t r ing at t ){//ritorna true se l ’ attributo del costrutto ha//tempo di transazione}

boolean et ( S t r ing cos t r , S t r ing at t ){//ritorna true se l ’ attributo del costrutto ha//tempo dell ’ evento}

boolean at ( S t r ing cos t r , S t r ing at t ){//ritorna true se l ’ attributo del costrutto ha//tempo di transazione}

boolean vt ( S t r ing c o s t r ){//ritorna true se i l costrutto specif icato ha//tempo di validita ‘}

boolean t t ( S t r ing c o s t r ){//ritorna true se i l costrutto specif icato ha//tempo di transazione}

boolean et ( S t r ing c o s t r ){//ritorna true se i l costrutto specif icato ha//tempo dell ’ evento}

boolean at ( S t r ing c o s t r ){//ritorna true se i l costrutto specif icato ha//tempo di transazione}

//Eventi

St r ing [ ] events ( c o s t r ){//rest ituisce un elenco degli eventi col legat i//al costrutto ordinati per nome


}

boolean eventStartOf ( event , c o s t r ){//rest ituisce true se l ’ evento pu indicare//l ’ in iz io dello stato o della relazione}

boolean eventEndOf ( event , c o s t r ){//rest ituisce true se l ’ evento pu indicare//la f ine dello stato o della relazione}

boolean s ta r tOf ( c o s t r ){//rest ituisce true se ci sono eventi che//possono segnare l ’ in iz io dello stato//o della relazione}

boolean endOf ( c o s t r ){//rest ituisce true se ci sono eventi che//possono segnare la f ine dello stato//o della relazione}

}

5.3.4 La classe “xsDoc”

c l a s s xsDoc{

//Si presuppone che questa classe possa scrivere su un//documento di testo poi salvato come// . xsd (XML Schema Document)

xsDoc ( St r ing f i l e ){//la classe pu scrivere sul f i l e speci f icato// i l punto di inserimento e ‘ la prima riga del f i l e}


void printXSD ( St r ing s t r i n g a ){//scrive sul documento la stringa speci f icata nel punto//di inserimento attuale ;//con \n va a capo spostando i l testo seguente//e creando una nuova riga per l ’ inserimento ;//concatenazione con i l punto// le var iabi l i inser ite nella concatenazione vengono//valutate formando una stringa unica}

//Si presuppone che , nello scrivere i l documento s i possano//usare due funzioni che utilizzando una pila possano//memorizzare e leggere dei punti di inserimento del//testo al l ’ interno del documento stesso .

setReturn ( ){//inserisce in cima al la pila un indicatore// r i f e r i to a l la riga attuale// e va a capo senza scrivere nulla}

getReturn ( ){//preleva dalla l ’ indicatore in cima al la pila// i l punto di inserimento delle stringhe diventa//quello indicato}

St r ing xsType ( St r ing t ){switch ( t ) {case ‘ ‘ i n t ege r ’ ’ : r e turn ‘ ‘ xs : i n t ege r ’ ’ ;case ‘ ‘ double ’ ’ : r e turn ‘ ‘ xs : double ’ ’ ;case ‘ ‘ date ’ ’ : r e turn ‘ ‘ xs : date ’ ’ ;case ‘ ‘ time ’ ’ : r e turn ‘ ‘ xs : dateTime ’ ’ ;case ‘ ‘ s t r i ng ’ ’ : r e turn ‘ ‘ xs : s t r i ng ’ ’ ;}}

void insertXSDdef ( ){printXSD( ’<?xml ve r s i on = ‘ ‘1 .0 ’ ’? > ’ .\n ) ;printXSD(’< schema


xmlns : xs = ‘ ‘ http ://www.w3 . org /2001/XML Schema ’ ’xmlns : gml= ‘ ‘ http ://www. openg i s . net /gml ’ ’ > ’ .\n ) ;

printXSD(’< import namespace= ‘ ‘ http ://www. openg i s . net /gm’ ’schemaLocation = ‘ ‘ . . / geometrycomplexes . xsd ’ ’ / > ’) ;

}

void insertXSDdef ( ){printXSD( ’<?xml ve r s i on = ‘ ‘1 .0 ’ ’? > ’ .\n ) ;printXSD(’<xs : schemaxmlns= ‘ ‘ http ://www.w3 . org /2001/XML Schema ’ ’xmlns : gml= ‘ ‘ http ://www. openg i s . net /gml ’ ’ > ’ .\n ) ;

printXSD(’< import namespace= ‘ ‘ http ://www. openg i s . net /gm’ ’schemaLocation = ‘ ‘ . . / geometrycomplexes . xsd ’ ’ / > ’) ;

}

void c loseXSdef ( ){printXSD( ’</schema > ’ .\n ) ;}

void endXScomplexEelement ( ){printXSD( ’</ xs : complexType > ’ .\n ) ;printXSD( ’</ xs : element > ’ .\n ) ;}

void beginXSsimpleElement ( S t r ing name ,S t r ing minO , St r ing maxO){

printXSD(’<xs : element name= ‘ ‘ ’ . name . ’ ’ ’minOccurs = ‘ ‘ ’ .minO . ’ ’ ’ maxOccurs = ‘ ‘ ’ .maxO. ’ ’ ’ > ’ .\n ) ;

printXSD(’<xs : simpleType > ’ .\n ) ;}

void endXSsimpleEelement ( ){printXSD( ’</ xs : simpleType > ’ .\n ) ;printXSD( ’</ xs : element > ’ .\n ) ;}

void insertXSelement ( S t r ing name , S t r ing type ,S t r ing minO , St r ing maxO){

St r ing t=xsType ( type ) ;printXSD(’<xs : element name= ‘ ‘ ’ . name . ’ ’ ’ type = ‘ ‘ ’ . t . ’ ’ ’

minOccurs = ‘ ‘ ’ .minO . ’ ’ ’ maxOccurs = ‘ ‘ ’ .maxO. ’ ’ ’ / > ’.\n ) ;


}

void insertXSemptyElement ( S t r ing name ,S t r ing minO , St r ing maxO){

printXSD(’<xs : element name= ‘ ‘ ’ . name . ’ ’ ’minOccurs = ‘ ‘ ’ .minO . ’ ’ ’ maxOccurs = ‘ ‘ ’ .maxO. ’ ’ ’ / > ’.\n ) ;

}

void beginXSsequence ( ){printXSD(’<xs : sequence > ’ .\n ) ;}

void endXSsequence ( ){printXSD( ’</ xs : sequence > ’ .\n ) ;}

void i n s e r tXSa t t r i bu t e ( S t r ing name , S t r ing type ){printXSD(’<xs : a t t r i bu t e name= ‘ ‘ ’ . name . ’ ’ ’

type = ‘ ‘ ’ . type . ’ ’ ’ / > ’.\n ) ;}

void i n s e r tXSa t t r i bu t e ( S t r ing name , S t r ing type , S t r ing use ){printXSD(’<xs : a t t r i bu t e name= ‘ ‘ ’ . name . ’ ’ ’

type = ‘ ‘ ’ . type . ’ ’ ’ use = ‘ ‘ ’ . use . ’ ’ ’ / > ’.\n ) ;}

void startXScomplexAttr ibute ( S t r ing name){printXSD(’<xs : a t t r i bu t e name= ‘ ‘ ’ . name . ’ ’ ’ > ’.\n ) ;printXSD(’<xs : simpleType > ’ .\n ) ;}

void endXScomplexAttribute ( ){printXSD( ’</ xs : simpleType > ’ .\n ) ;printXSD( ’</ xs : a t t r i bu t e > ’ .\n ) ;}

void insertGMLgeometry ( S t r ing type ){switch ( type ) {case ‘ ‘ point ’ ’ :

printXSD(’<xs : element r e f = ‘ ‘gml : Point ’ ’ / > ’.\n ) ;case ‘ ‘ l i n e ’ ’ :


printXSD(’<xs : element r e f = ‘ ‘gml : L ineStr ing ’ ’ / > ’.\n ) ;case ‘ ‘ polygon ’ ’ :

printXSD(’<xs : element r e f = ‘ ‘gml : Polygon ’ ’ / > ’.\n ) ;case ‘ ‘ mult ipo int ’ ’ :

printXSD(’<xs : element r e f = ‘ ‘gml : MultiPoint ’ ’ / > ’.\n ) ;case ‘ ‘ mu l t i l i n e ’ ’ :

printXSD(’<xs : element r e f = ‘ ‘gml : Mult iL ineStr ing ’ ’ / > ’.\n ) ;case ‘ ‘ mult ipolygon ’ ’ :

printXSD(’<xs : element r e f = ‘ ‘gml : MultiPolygon ’ ’ / > ’.\n ) ;case ‘ ‘ c o l l e c t i o n ’ ’ :

printXSD(’<xs : element r e f = ‘ ‘gml : MultiGeometry ’ ’ / > ’.\n ) ;case ‘ ‘ other ’ ’ :

printXSD(’<xs : element r e f = ‘ ‘gml : MultiGeometry ’ ’ / > ’.\n ) ;}}

void insertXSkeyDef ( S t r ing name ,S t r ing s e l e c t o r , S t r ing [ ] f i e l d ){

printXSD(’<xs : key name= ‘ ‘ ’ . name . ’ ’ ’ > ’.\n ) ;printXSD(’<xs : s e l e c t o r xpath = ‘ ‘ ’ . s e l e c t o r . ’ ’ ’ > ’.\n ) ;f o r i from 1 to f i e l d [ ] . l enght doprintXSD(’<xs : f i e l d xpath = ‘ ‘ ’ . f i e l d [ i ] . ’ ’ ’ > ’.\n ) ;

printXSD( ’</ xs : key > ’ .\n ) ;}

void inse r tXSkeyre fDe f ( S t r ing name , S t r ing r e f e r ,S t r ing s e l e c t o r , S t r ing [ ] f i e l d ){

printXSD(’<xs : k ey r e f name= ‘ ‘ ’ . name . ’ ’ ’r e f e r = ‘ ‘ ’ . r e f e r . ’ ’ ’ > ’.\n ) ;

printXSD(’<xs : s e l e c t o r xpath = ‘ ‘ ’ . s e l e c t o r . ’ ’ ’ > ’.\n ) ;f o r i from 1 to f i e l d [ ] . l enght doprintXSD(’<xs : f i e l d xpath = ‘ ‘ ’ . f i e l d [ i ] . ’ ’ ’ > ’.\n ) ;

printXSD( ’</ xs : keyre f > ’ .\n ) ;}

void insertXSuniqueDef ( S t r ing name , S t r ing s e l e c t o r ,S t r ing f i e l d ){

printXSD(’<xs : unique name= ‘ ‘ ’ . name . ’ ’ ’ > ’.\n ) ;printXSD(’<xs : s e l e c t o r xpath = ‘ ‘ ’ . s e l e c t o r . ’ ’ ’ > ’.\n ) ;f o r i from 1 to f i e l d [ ] . l enght doprintXSD(’<xs : f i e l d xpath = ‘ ‘ ’ . f i e l d [ i ] . ’ ’ ’ > ’.\n ) ;

5.4. UN CASO DI STUDIO 157

printXSD( ’</ xs : unique > ’ .\n ) ;}

void beginXSchoiceDef ( S t r ing minO){printXSD(’<xs : cho i c e minOccurs = ‘ ‘ ’ .minO . ’ ’ ’

maxOccurs= ‘ ‘1 ’ ’ / > ’.\n ) ;}

void endXSchoiceDef ( ){printXSD( ’</ xs : cho ice > ’ .\n ) ;}

void beg inXSre s t r i c t i onDe f ( S t r ing base ){printXSD(’<xs : r e s t r i c t i o n base = ‘ ‘ ’ . base . ’ ’ ’ > ’.\n ) ;}

void endXSres t r i c t i onDe f ( ){printXSD( ’</ xs : r e s t r i c t i o n > ’ .\n ) ;}

void insertXSenumerat ionDef ( S t r ing value ){printXSD(’<xs : enumeration value = ‘ ‘ ’ . va lue . ’ ’ ’ / > ’.\n ) ;}

}

5.4 Un caso di studio

Il caso di studio preso in esame ha come obiettivo l’implementazione di una basedi dati spazio-temporale per l’analisi della domanda di prestazioni nel camposanitario locale. In particolare, la base di dati e orientata allo studio della distri-buzione territoriale degli assistiti e delle richieste di prestazioni e della migrazionedella domanda di prestazioni.

Lo schema ChronoGeoGraph, mostrato in Figura 5.1, modella la realta descrittacome segue:

• per ogni assistito si tiene traccia del nome, del cognome, del codice fiscale,del comune di residenza (modellato come entita georeferenziata di tipo


poligono) e dell’indirizzo (modellato come entita georeferenziata di tipopunto);

• per ogni richiesta effettuata (modellata come relazione) si tiene tracciadell’assistito richiedente, del prescrittore (modellato come entita) e dellaprescrizione effettuata;

• per ogni prescrizione effettuata si tiene traccia del codice e del tipo di pre-scrizione, della sua denominazione e della struttura erogatrice (modellatocome entita georeferenziata di tipo punto, situata in un certo comune);

• per ogni ASL italiana (l’Italia e modellata come territorio di schema) sitiene traccia del codice dell’ASL, dei comuni che la compongono (modellaticome entita georeferenziata di tipo poligono) e dei dottori che vi afferiscono(entita “prescrittore”);

• si tiene inoltre traccia dei trasferimenti (modellati come eventi) di resi-denza degli assistiti, dei trasferimenti (modellati come eventi) dei dottoriad un’altra ASL e del pensionamento (modellato come evento) dei dottoristessi.

Nelle prossime sezioni sono presentati una descrizione discorsiva dell’applica-zione dell’algoritmo allo schema ChronoGeoGraph relativo al caso di studio e ildocumento XML Schema ottenuto.

5.4.1 Operazioni eseguite dall’algoritmo

Ottenuto in input lo schema ChronoGeoGraph, mostrato in Figura 5.1, l’algo-ritmo esegue il primo passo, istanziando le variabili globali, ed il secondo passo,inserendo nel documento le definizioni XML Schema principali e l’elemento conte-nitore “analisiSanitaria”. Al terzo passo viene dichiarato il territorio di schema“Italia”. Il quarto passo identifica le first-level-entity e le aggiunge alla lista“entList”, la quale alla fine del quarto passo contiene i seguenti valori:

[ a s l , non c o d i f i c a t a ] ;[ comune , non c o d i f i c a t a ] .

Il quinto passo inserisce nella lista “relList” tutte le relazioni, mentre il sestopasso non viene eseguito, data la mancanza di relazioni binarie in cui entrambele entita coinvolte partecipino con cardinalita 1:1.


Figura 5.1: Schema ChronoGeoGraph “analisiSanitaria” relativo al caso di studio


Il settimo passo da inizio alla codifica delle entita, partendo dalla prima indicatada “entList” come non codificata, ovvero “asl”. Vengono creati l’elemento rap-presentante l’entita ed i sottoelementi relativi agli attributi. Dopo aver creatoil sottoelemento “geometry” relativo alla geometria di tipo poligono dell’entita,viene richiamato il metodo “relazioni” con argomenti “asl” e “afferisce” per lacodifica della relazione “afferisce”.La chiamata al metodo “relSupport”, effettuata dal metodo “relazioni” per tra-durre la relazione “afferisce” tramite la metodologia del riferimento a chive, fa asua volta iniziare la codifica dell’entita “prescrittore”, che non risulta ancora co-dificata. Data la particolare struttura dello schema ChronoGeoGraph analizzato,il procedimento si ripete “a catena” (inserendo le entita nella lista entList, primadi richiamare la relativa procedura di codifica, quando non sono presenti) fino aquando l’algoritmo, traducendo l’entita “prestazione” non richiama la proceduradi codifica della relazione “richiesta”, essendo, quest’ultima, gia stata codificata.In particolare, traduzioni vengono richiamate nel seguente ordine:

• relazione “afferisce”;

• entita “prescrittore”;

• relazione “richiesta”;

• entita “assistito” (prima in ordine alfabetico tra le entita che partecipanoalla relazione “richiesta” oltre all’entita “prescrittore”);

• relazione “risiede”;

• entita “luogo”;

• relazione “include”;

• entita “comune”;

• relazione “situato”;

• entita “strutturaErogatrice”;

• relazione “eroga”;

• entita “prestazione”;


Quest’ultima entita, non essendo collegata ad alcuna relazione non ancora codi-ficata, puo essere codificata del tutto. L’algoritmo ripercorre quindi al contrariola sequenza sopra descritta, concludendo la definizione degli elementi relativi alleentita e relazioni che incontra, fino alla conclusione della traduzione dell’entita“assistito”. A tal punto, essendo gia stata codificata l’entita prestazione, conclu-de la codifica della relazione “richiesta”, dell’entita “prescrittore, della relazione“afferisce” e, in fine, dell’entita “asl”.Il controllo ritorna, quindi, al metodo principale, che, constatando che tuttele entita sono state codificate conclude l’esecuzione dell’algoritmo chiudendo ladefinizione dell’elemento radice.

5.4.2 Documento XML Schema ottenuto

Viene di seguito presentato il documento analisiSanitaria.xsd, risultato del-l’applicazione dell’algoritmo di traduzione allo schema mostrato in Figura 5.1.

<?xml ve r s i on = ‘ ‘1.0 ’ ’? ><xs : schema xmlns= ‘ ‘ http ://www.w3 . org /2001/XML Schema ’ ’

xmlns : gml= ‘ ‘ http ://www. openg i s . net /gml ’ ’><import namespace= ‘ ‘ http ://www. openg i s . net /gml ’ ’

schemaLocation = ‘ ‘ . . / geometrycomplexes . xsd ’ ’ />

<xs : element name= ‘ ‘ a n a l i s i S a n i t a r i a ’ ’ minOccurs = ‘ ‘1 ’ ’maxOccurs= ‘ ‘1 ’ ’>


<!−− Te r r i t o r i o d i Schema ‘ ‘ I t a l i a ’ ’ −−><xs : element name= ‘ ‘ t s I t a l i a ’ ’ minOccurs = ‘ ‘1 ’ ’

maxOccurs= ‘ ‘1 ’ ’><xs : complexType><xs : sequence><xs : element name= ‘ ‘ geometry ’ ’ minOccurs = ‘ ‘1 ’ ’

maxOccurs= ‘ ‘1 ’ ’><xs : complexType><xs : sequence><xs : element r e f = ‘ ‘gml : MultiPolygon ’ ’ />

</xs : sequence>




<!−− Entita ‘ ‘ ‘ a s l ’ ’ −−><xs : element name= ‘ ‘ a s l ’ ’ minOccurs = ‘ ‘0 ’ ’


<xs : element name= ‘ ‘ codiceASL ’ ’ type = ‘ ‘ xs : s t r i ng ’ ’minOccurs = ‘ ‘1 ’ ’ maxOccurs= ‘ ‘1 ’ ’ />

<xs : element name= ‘ ‘ geometry ’ ’ minOccurs = ‘ ‘1 ’ ’maxOccurs= ‘ ‘1 ’ ’>

<xs : complexType><xs : sequence><xs : element r e f = ‘ ‘gml : MultiPolygon ’ ’ />


<!−− Relaz ione ‘ ‘ a f f e r i s c e ’ ’ −−><xs : element name= ‘ ‘ p r e s c r i t t o r e ’ ’ minOccurs = ‘ ‘1 ’ ’

maxOccurs= ‘ ‘unbounded ’ ’><xs : complexType><xs : sequence><xs : element name= ‘ ‘ codicePR ’ ’ type = ‘ ‘ xs : s t r i ng ’ ’

minOccurs = ‘ ‘1 ’ ’ maxOccurs= ‘ ‘1 ’ ’ /><xs : element name= ‘ ‘ startEvent ’ ’ minOccurs = ‘ ‘1 ’ ’

maxOccurs= ‘ ‘1 ’ ’><xs : complexType><xs : a t t r i bu t e name= ‘ ‘ eventTime ’ ’ type = ‘ ‘ xs : dateType ’ ’ /><xs : a t t r i bu t e name= ‘ ‘ t ipo ’ ’ /><xs : simpleType><xs : r e s t r i c t i o n base = ‘ ‘ xs : s t r i ng ’ ’ ><xs : enumeration value = ‘ ‘ t ra s f e r imento ’ ’ />

</xs : r e s t r i c t i o n >


</xs : simpleType></xs : a t t r i bu t e >

</xs : complexType></xs : element><xs : element name= ‘ ‘ endEvent ’ ’ minOccurs = ‘ ‘0 ’ ’

maxOccurs= ‘ ‘1 ’ ’><xs : complexType><xs : a t t r i bu t e name= ‘ ‘ eventTime ’ ’ type = ‘ ‘ xs : dateType ’ ’ /><xs : a t t r i bu t e name= ‘ ‘ t ipo ’ ’ /><xs : simpleType><xs : r e s t r i c t i o n base = ‘ ‘ xs : s t r i ng ’ ’ ><xs : enumeration value = ‘ ‘ t ra s f e r imento ’ ’ /><xs : enumeration value = ‘ ‘ pensione ’ ’ />

</xs : r e s t r i c t i o n ></xs : simpleType></xs : a t t r i bu t e >



<xs : k ey r e f name= ‘ ‘ a s lR e fTop r e s c r i t t o r e I nRe l a f f e r i s c e ’ ’r e f e r = ‘ ‘ p r e s c r i t t o r eKey ’ ’ >

<xs : s e l e c t o r xpath= ‘ ‘ p r e s c r i t t o r e ’ ’ ><xs : f i e l d xpath= ‘ ‘ codicePR ’ ’ >

</xs : keyre f>

<xs : unique name= ‘ ‘ un i qu ep r e s c r i t t o r e ’ ’ ><xs : s e l e c t o r xpath= ‘ ‘ p r e s c r i t t o r e ’ ’ ><xs : f i e l d xpath= ‘ ‘ codicePR ’ ’ >

</xs : unique>

<!−− Aggregazione d i ‘ ‘ comune ’ ’ −−><xs : element name= ‘ ‘comune ’ ’ minOccurs = ‘ ‘1 ’ ’


<xs : element name= ‘ ‘ codiceISTAT ’ ’ type = ‘ ‘ xs : s t r i ng ’ ’minOccurs = ‘ ‘1 ’ ’ maxOccurs= ‘ ‘1 ’ ’ />



<xs : k ey r e f name= ‘ ‘ aslRefTocomuneInRelcomune ’ ’r e f e r = ‘ ‘comuneKey ’ ’ >

<xs : s e l e c t o r xpath= ‘ ‘comune ’ ’ ><xs : f i e l d xpath= ‘ ‘ codiceISTAT ’ ’ >

</xs : keyre f>


<xs : key name= ‘ ‘ aslKey ’ ’ ><xs : s e l e c t o r xpath= ‘ ‘ a s l ’ ’ ><xs : f i e l d xpath= ‘ ‘ codiceASL ’ ’ >

</xs : key>

<!−− Entita ‘ ‘ ‘ p r e s c r i t t o r e ’ ’ −−><xs : element name= ‘ ‘ p r e s c r i t t o r e ’ ’ minOccurs = ‘ ‘0 ’ ’


<xs : element name= ‘ ‘ codicePR ’ ’ type = ‘ ‘ xs : s t r i ng ’ ’minOccurs = ‘ ‘1 ’ ’ maxOccurs= ‘ ‘1 ’ ’ />

<xs : element name= ‘ ‘cognomeP ’ ’ type = ‘ ‘ xs : s t r i ng ’ ’minOccurs = ‘ ‘1 ’ ’ maxOccurs= ‘ ‘1 ’ ’ />

<xs : element name= ‘ ‘ laurea ’ ’ type = ‘ ‘ xs : s t r i ng ’ ’minOccurs = ‘ ‘1 ’ ’ maxOccurs= ‘ ‘unbounded ’ ’ />

<xs : element name= ‘ ‘nomeP ’ ’ type = ‘ ‘ xs : s t r i ng ’ ’minOccurs = ‘ ‘1 ’ ’ maxOccurs= ‘ ‘1 ’ ’ />

<!−− Relaz ione ‘ ‘ r i c h i e s t a ’ ’ −−><xs : element name= ‘ ‘ a s s i s t i t o ’ ’ minOccurs = ‘ ‘1 ’ ’



<xs : k ey r e f name= ‘ ‘ luogoRefTocomuneInRelinclude ’ ’r e f e r = ‘ ‘comuneKey ’ ’ >

<xs : s e l e c t o r xpath= ‘ ‘comune ’ ’ ><xs : f i e l d xpath= ‘ ‘ codiceISTAT ’ ’ >

</xs : keyre f>


<xs : key name= ‘ ‘ luogoKey ’ ’ ><xs : s e l e c t o r xpath= ‘ ‘ luogo ’ ’ ><xs : f i e l d xpath= ‘ ‘ i n d i r i z z o ’ ’ ><xs : f i e l d xpath= ‘ ‘comune ’ ’ >

</xs : key>

<!−− Entita ‘ ‘ ‘ comune ’ ’ −−><xs : element name= ‘ ‘comune ’ ’ minOccurs = ‘ ‘0 ’ ’


<xs : element name= ‘ ‘ codiceISTAT ’ ’ type = ‘ ‘ xs : s t r i ng ’ ’minOccurs = ‘ ‘1 ’ ’ maxOccurs= ‘ ‘1 ’ ’ />

<xs : element name= ‘ ‘nomeComune ’ ’ type = ‘ ‘ xs : s t r i ng ’ ’minOccurs = ‘ ‘1 ’ ’ maxOccurs= ‘ ‘1 ’ ’ />


<xs : complexType><xs : sequence><xs : element r e f = ‘ ‘gml : MultiPolygon ’ ’ />


<!−− Relaz ione ‘ ‘ s i tua to ’ ’ −−><!−− I n c l u s i o n e de l l ’ Entita ‘

‘ ‘ s t ru t tu raEroga t r i c e ’ ’ −−><xs : element name= ‘ ‘ s t ru t tu raEroga t r i c e ’ ’


minOccurs = ‘ ‘1 ’ ’ maxOccurs= ‘ ‘unbounded ’ ’><xs : complexType><xs : sequence>

<xs : element name= ‘ ‘ codiceSE ’ ’ type = ‘ ‘ xs : s t r i ng ’ ’minOccurs = ‘ ‘1 ’ ’ maxOccurs= ‘ ‘1 ’ ’ />

<xs : element name= ‘ ‘ tipoSE ’ ’ type = ‘ ‘ xs : s t r i ng ’ ’minOccurs = ‘ ‘1 ’ ’ maxOccurs= ‘ ‘1 ’ ’ />


<xs : complexType><xs : sequence><xs : element r e f = ‘ ‘gml : Point ’ ’ />


<!−− Relaz ione ‘ ‘ eroga ’ ’ −−><xs : element name= ‘ ‘ p r e s taz i one ’ ’ minOccurs = ‘ ‘1 ’ ’

maxOccurs= ‘ ‘unbounded ’ ’><xs : complexType><xs : sequence><xs : element name= ‘ ‘ codiceP ’ ’ type = ‘ ‘ xs : s t r i ng ’ ’

minOccurs = ‘ ‘1 ’ ’ maxOccurs= ‘ ‘1 ’ ’ /></xs : sequence><xs : a t t r i bu t e name= ‘ ‘ vt i ’ ’ type = ‘ ‘ xs : dateTime ’ ’ /><xs : a t t r i bu t e name= ‘ ‘ vt f ’ ’ type = ‘ ‘ xs : dateTime ’ ’

use = ‘ ‘ opt iona l ’ ’/></xs : complexType></xs : element>

<xs : k ey r e fname= ‘ ‘ s t ru t turaErogat r i c eRe fTopre s taz i one InRe l e roga ’ ’r e f e r = ‘ ‘ p r e s taz i one ’ ’ >

<xs : s e l e c t o r xpath= ‘ ‘ p r e s taz i one ’ ’ ><xs : f i e l d xpath= ‘ ‘ codiceP ’ ’ >

</xs : keyre f>

<xs : unique name= ‘ ‘ un iquepres taz ione ’ ’ ><xs : s e l e c t o r xpath= ‘ ‘ p r e s taz i one ’ ’ >

Capitolo 6

Conclusioni

In questo lavoro di tesi abbiamo esplorato la possibilita di utilizzare il linguaggioXML per definire lo schema logico di una base di dati spazio-temporale costruitoa partire da uno schema concettuale spazio-temporale. In particolare, abbiamomesso in evidenza le differenze tra schemi logici espressi in XML e i tradizionalischemi logici relazionali.In alcuni recenti lavori XML e stato proposto quale formalismo alternativo perla sintesi di schemi logici di basi di dati definiti a partire da schemi E/R. Nelpresente lavoro tale approccio e stato esteso a modelli E/R arricchiti con dimen-sioni spaziali e temporali.La metodologia di traduzione proposta prova come sia possibile, a partire daschemi Entita/Relazioni spazio-temporali, definire schemi XML che catturanoadeguatamente la struttura della corrispondente base di dati spazio-temporale.Tali schemi XML vengono generati in modo automatico dall’algoritmo propostosenza la necessita di modificare alcun costrutto degli schemi Entita/Relazioni.Inoltre, l’approccio proposto consente di risolvere alcuni problemi di ridondanzatipici delle basi di dati temporali relazionali.Per quanto riguarda i limiti della soluzione proposta, va rilevato che alcune li-mitazioni del linguaggio XML non consentono di definire in modo appropriatoalcuni dei vincoli previsti dal modello E/R spazio-temporale. Come nel caso del-le basi di dati relazionali, la verifica di tali vincoli puo essere effettuata solo permezzo di controlli esterni.Per quanto riguarda gli sviluppi futuri del presente lavoro, e in corso l’integra-zione dell’algoritmo proposto con uno strumento per la sintesi grafica di schemiconcettuali spazio-temporali, basato sul modello ChronoGeoGraph, in fase direalizzazione presso il laboratorio di Basi di Dati e Sistemi Multimediali del Di-

175

176 CAPITOLO 6. CONCLUSIONI

partimento di Matematica e Informatica dell’Universita di Udine [3].Tale strumento, scritto in Java, consente di costruire, per mezzo di una serie dioperatori visuali, uno schema ChronoGeoGraph. Lo schema cosı generato vie-ne preso in input dall’algoritmo, che genera automaticamente il corrispondentedocumento XML Schema. Tale documento definisce lo schema logico secondo ilquale vanno costruiti i documenti XML che compongono la base di dati.

Bibliografia

[1] Azteni Paolo, Ceri Stefano, Paraboschi Stefano e Torlone Riccardo. Basidi dati, Modelli e linguaggi di interrogazione. McGraw-Hill, Milano,2002.

[2] Bolgan Maristella. Un modello concettuale esteso per basi di datitemporali Multidimensionali. Tesi di laurea in Informatica, Universitadegli Studi di Udine, 2003.

[3] Burigo Erik. Un modello concettuale per la progettazione di basidi dati spazio-temporali. Tesi di laurea in Informatica, Universita degliStudi di Udine, (in preparazione).

[4] Chen Peter Pin-Shan. The entity-relationship model, toward a unifiedview of data. ACM Transaction on Database System, vol. 1, n. 1, pagg9-36, 1976.

[5] Chiesa Carlo. Sistemi informativi geografici: uno strumento per latrasformazione di schemi concettuali in schemi logici. Tesi di laureain Informatica, Universita degli Studi di Udine, 2002.

[6] Clementini Eliseo, Di Felice Paolino e van Oosteron Peter. A small set offormal topological relationship suitable for end-user interaction. InThird International Symposium in Advances in Spatial Database (SSD’93),Singapore, 1993.

[7] Combi Carlo e Montanari Angelo. Data Models with Multiple Tempo-ral Dimensions: Completing the Picture. In Proceeding of the 13th

International Conference on Advanced Information Systems Engineering,(CAiSE 2001), Springer, Berlin Heidelberg, pagg 187-202, 2001.

[8] De Fent Iginia, Gubiani Donatella, Montanari Alberto. Granular Geo-Graph: a Multi-Granular Conceptual Model for Spatial Data. In

177

178 BIBLIOGRAFIA

Proceedings of 13th Italian Symposium on Advanced Database Systems(SEBD2005), pp. 368-379, Bressanone, June 2005.

[9] Dyreson Curtis E. e Jensen Christian S. The Consensus Glossary ofTemporal Database Concepts. Temporal Databases Research andPractice, LNCS 1399, Springer, Berlin Heidelberg, pagg 367-405, 1998.

[10] Egenhofer Max J. e Herring John R. Categorizing binary topologicalrelations between regions, lines and points in geographics data-bases. Tecnical report, Department of surveying Engineering University ofMaine, Orono, ME, 1991.

[11] ElMasri Ramez A. e Navathe Shamkant B. Fundamentals of Databa-se Systems. Second edition Benjamin-Cummings, Menlo Park, California,1994.

[12] Frappa Alberto. Uno strumento per la progettazione concettuale disistemi informativi geografici. Tesi di laurea in Informatica, Universitadegli Studi di Udine, 2002.

[13] Gubiani Donatella. Un modello concettuale per il trattamento di datispaziali a diverse granularita in sistemi informativi geografici. Tesidi laurea in Informatica, Universita degli Studi di Udine, 2002.

[14] Gubiani Donatella. Geography Markup Language. Seminario, Diparti-mento di Scienze, Universita degli Studi G. D’Annunzio di Chieti-Pescara,2005.

[15] Kravanja Antonella. GML: uno strumento per la modellazione e l’a-nalisi di dati spaziali Tesi di laurea in Informatica, Universitacdegli Studidi Udine, 2003.

[16] Pigozzo Paolo ed Quintarelli Elisa. An algorithm for generating XMLSchemas from ER Schemas. In proceeding of 13th Italian Synposiumon Advanced Database Systems (SEBD 2005), pagg 192-199, Bressanone(Italy), June 2005.

[17] Rigaux Philippe, Scholl Michel e Voisard Agnes. Spatial Databases withapplication to GIS. Academic Press, San Diego, California, 2002.

BIBLIOGRAFIA 179

[18] Tansel Abdullah Uz, Clifford James, Gadia Shashi, Jajodia Sushil, SegevArie e Snodgrass Richard. Temporal Databases, theory, design endimplementation Benjamin-Cummings, Menlo Park, California, 1993.

[19] Tryfona Nectaria e Jensen Christian. Conceptual Data Modeling forSpatiotemporal Applications. CHOROCHRONOS Technical ReportSeries, Deartment of Computer Science, Aalborg University, 1998.

[20] Wang Fusheng, Zhou Xin e Zaniolo Carlo. Temporal Information Ma-nagement using XML Department of Computer Science, University ofCalifornia, Los Angeles, California.

[21] W3C. Manuali on-line del “World Wide Web Consor-tium”. www.w3schools.com “www.w3.org/TR/xquery” e“www.w3.org/TR/xqueryx” .

TRADUZIONE DI SCHEMI ENTITA/RELAZIONI` SPAZIO …sdesabba/docs/TraduzioneER-XMLSchema.pdf ·...

Documents

Transcript of TRADUZIONE DI SCHEMI ENTITA/RELAZIONI` SPAZIO …sdesabba/docs/TraduzioneER-XMLSchema.pdf ·...