La struttura dati rappresentabile per mezzo di un formato XML può essere particolarmente complessa ed articolata con ripetizioni e nidificazioni la cui normalizzazione in un modello relazionale non sarebbero sempre realizzabili in modo efficace ed efficiente.
Per poter consentire, quindi, di fruire dei dati di un sistema come eXtraWay per mezzo di un approccio relazionale è necessario accettare alcune limitazioni, accettare che i dati possano essere rappresentati nel modo più somigliante a quanto richiesto dal modello relazionale senza snaturare il modello strutturato in XML.
Va da se che la complessità della struttura XML adottata dipende strettamente dall'uso che di tali dati si intende fare: la dove si progetti una base dati tesa ad un prevalente utilizzo per mezzo del linguaggio SQL, la base dati stessa può essere concepita con una struttura semplificata per sposare al meglio tale esigenza. Per poter fruire del linguaggio SQL in ogni occasione, però, alcune restrizioni dovranno essere ammesse. Vediamo di cosa si tratta.
Una forma intuitiva per identificare il modello relazionale di rappresentazione dei dati consiste nella distribuzione dei dati in tabelle composte da colonne. La colonna rappresenta quindi l'unità minima di rappresentazione del singolo dato e la combinazione di più colonne in una tabella produce un singolo record rappresentativo.
Nel modello strutturato implementato in eXtraWay, l'oggetto che maggiormente si accomuna al record è l'unità informativa. Essa è rappresentata da un elemento XML e da tutti gli elementi in esso contenuti (salvo nidificazione di unità informative).
La scelta di quale insieme di elementi ed attributi, identificabili appunto dall'elemento che li delimita, è argomento della progettazione della base dati eXtraWay. Come accennato in precedenza, essa può essere più o meno complessa ed articolata. Qualora l'applicazione (e quindi il data base) sia stata progettata per essere principalmente utilizzato via SQL, la sua struttura sarà presumibilmente semplice e, conseguentemente, la mappatura tra tale rappresentazione ed il modello relazionale sarà diretta.
Le componenti di un'unità informativa sono elementi ed attributi. Ad ognuno di essi viene associato un canale di ricerca che corrisponde, per sommi capi, ad una colonna nel modello relazionale. Ad ognuno di essi corrisponde, per altro, un percorso che identifica il canale di ricerca. In tale percorso gli elementi vengono rappresentati col loro nome mentre gli attributi vengono rappresentati con il nome preceduto dal carattere @.
Come sempre, un buon esempio vale più di mille parole. Partendo da un modello molto semplice procederemo per passi ad identificare modelli più complessi e quindi più vicini alla realtà di un'applicazione XML articolata.
Immaginiamo di creare un Data Base con una semplice tabella rubrica ed inserire in essa le colonne nome, cognome, indirizzo, cap, mansione e n_tel.
Senza che questo venga codificato per mezzo di search_alias (Vds. documentazione specifica sulla configurazione delle basi dati eXtraWay), la forma più semplice e diretta di rappresentazione di questo modello in XML sarebbe la seguente:
<rubrica> <nome>...</nome> <cognome>...</cognome> <indirizzo>...</indirizzo> <cap>...</cap> <mansione>...</mansione> <n_tel>...</n_tel> </rubrica>
Se pure il nostro file nomearchivio.conf.xml non risultasse configurato per nessun canale di ricerca dell'unità informativa nota come rubrica, dall'unità informativa riconosciuta verrebbero comunque identificati percorsi di ricerca quali:
XML,/rubrica/nome XML,/rubrica/cognome XML,/rubrica/indirizzo XML,/rubrica/cap XML,/rubrica/mansione XML,/rubrica/n_tel
Quindi, data la denominazione dell'unità informativa rubrica, la mappatura con il nome della tabella corrispondente avviene direttamente. Altrettanto dicasi per i nomi dei canali che da essa derivano la cui mappatura con il nome delle colonne avviene altrettanto direttamente.
In questo panorama, esprimendo nell'espressione SQL una richiesta come la seguente...
select nome, cognome from rubrica where mansione='direttore'
...si intende estrarre dalle unità informative rilevate da una ricerca, che altro non sono se non frammenti XML, le componenti /rubrica/nome e /rubrica/cognome dopo aver risolto la frase di ricerca in linguaggio nativo eXtraWay...
[XML,/rubrica/mansione]="direttore"
Provvediamo ora a complicare un po' le carte in tavola. Immaginiamo ora che il modello XML preveda che il nome ed il cognome non siano degli elementi contenuti in rubrica ma degli attributi dell'elemento rubrica stesso. Il formato XML cambia come segue...
<rubrica nome="..." cognome="..."> <indirizzo>...</indirizzo> <cap>...</cap> <mansione>...</mansione> <n_tel>...</n_tel> </rubrica>
...e per analogia i percorsi dei canali di ricerca subiscono la trasformazione seguente...
XML,/rubrica/@nome XML,/rubrica/@cognome XML,/rubrica/indirizzo XML,/rubrica/cap XML,/rubrica/mansione XML,/rubrica/n_tel
A questo punto il legame tra il canale XML,/rubrica/ e la colonna nome non è più diretto come in precedenza e altrettanto dicasi per la colonna cognome. Perché la mappatura abbia successo è necessario creare un opportuno alias di ricerca che consenta di ricollegare i due estremi: quello esprimibile con sintassi SQL e quello espresso dalla configurazione della Base Dati eXtraWay.
La configurazione degli alias di ricerca, nel file nomearchivio.conf.xml, ha il seguente aspetto...
<hw_fields> <search_alias search_name="rubrica.nome" search_key="XML,/rubrica/@nome/"/> <search_alias search_name="rubrica.cognome" search_key="XML,/rubrica/@cognome/"/> </hw_fields>
...ad indicare che il percorso che conduce ai due attributi viene riconosciuto al pari della dichiarazione relazionale per la colonna nome o cognome nella tabella rubrica. La stessa combinazione di alias di ricerca poteva essere espressa come...
<hw_fields> <search_alias search_name="nome" search_key="XML,/rubrica/@nome/"/> <search_alias search_name="cognome" search_key="XML,/rubrica/@cognome/"/> </hw_fields>
...senza l'indicazione dell'appartenenza alla tabella rubrica. Questa forma è valida se e solo se le colonne nome e cognome non sono presenti in alcun altra tabella
In sostanza, quindi, assumendo che nel modello relazionale ogni oggetto sia identificato dall'accoppiata tabella.colonna, la mappatura rispetta la seguente logica:
sempre dal primo elemento espresso.nodo direttamente discendente dell'elemento radice della stessa.Mentre alcune dichiarazioni possono quindi risultare omissibili, il fatto stesso che una struttura XML risulti articolata in diversi livelli di elementi (e non in una elencazione piatta di elementi nell'ambito dell'elemento radice) comporta l'obbligo di compilare doverosamente l'elenco degli alias di ricerca.
Mentre eXtraWay Server tollera, per il proprio linguaggio di ricerca la presenza di separatori, punti, spazi e caratteri speciali di varia natura nel nome dato all'alias di ricerca, quelli che vengono espressamente creati per la mappatura con il modello relazionale devono seguire semplici regole:
tabella ed il nome della colonna. Se presente per tale scopo non può apparire più di una volta.underscore). I nomi assegnati alle tabelle e delle colonne devono inziare con una lettera, maiuscola o minuscola.Nulla impedisce che, per le esigenze delle applicazioni native eXtraWay siano presenti altri alias di ricerca non sfruttati in SQL, purché non ambigui.
Qualora la stessa colonna appaia in tabelle diverse e si debba far ricorso agli alias di ricerca è opportuno creare un alias per ogni colonna dandole indicazione completa della tabella. E' ammissibile che uno (ed uno soltanto) degli alias non presenti la tabella (a patto che tutti gli altri la indichino) per evitare condizioni di indeterminazione.
In altri termini, se esistesse anche una tabella anagrafica ove sia presente il nome, il cognome e la matricola, con un modello XML più complesso, la dichiarazione degli alias potrebbe essere la seguente...
<hw_fields> <search_alias search_name="rubrica.nome" search_key="XML,/rubrica/@nome/"/> <search_alias search_name="rubrica.cognome" search_key="XML,/rubrica/@cognome/"/> <search_alias search_name="anagrafica.nome" search_key="XML,/anagrafica/dati_personali/@nome/"/> <search_alias search_name="anagrafica.cognome" search_key="XML,/anagrafica/dati_personali/@cognome/"/> </hw_fields>
...così come potrebbe essere...
<hw_fields> <search_alias search_name="rubrica.nome" search_key="XML,/rubrica/@nome/"/> <search_alias search_name="rubrica.cognome" search_key="XML,/rubrica/@cognome/"/> <search_alias search_name="nome" search_key="XML,/anagrafica/dati_personali/@nome/"/> <search_alias search_name="cognome" search_key="XML,/anagrafica/dati_personali/@cognome/"/> </hw_fields>
..o anche...
<hw_fields> <search_alias search_name="nome" search_key="XML,/rubrica/@nome/"/> <search_alias search_name="cognome" search_key="XML,/rubrica/@cognome/"/> <search_alias search_name="anagrafica.nome" search_key="XML,/anagrafica/dati_personali/@nome/"/> <search_alias search_name="anagrafica.cognome" search_key="XML,/anagrafica/dati_personali/@cognome/"/> </hw_fields>
...ma non potrebbe assolutamente essere...
<hw_fields> <search_alias search_name="nome" search_key="XML,/rubrica/@nome/"/> <search_alias search_name="cognome" search_key="XML,/rubrica/@cognome/"/> <search_alias search_name="nome" search_key="XML,/anagrafica/dati_personali/@nome/"/> <search_alias search_name="cognome" search_key="XML,/anagrafica/dati_personali/@cognome/"/> </hw_fields>
...in quanto la cosa sarebbe ambigua (e per altro non accettabile da eXtraWay).
Una volta che, con o senza l'ausilio degli alias di ricerca, si è completata la mappatura tra tabelle e colonne e le corrispondenti unità informative ed i canali di ricerca in esse identificati, si è pronti a compiere operazioni di varia natura.
Quanto detto sino ad ora non impedisce che si voglia concepire nel modello relazionale una colonna che non esiste, o per lo meno non esiste ancora, presso il modello strutturato in XML. Ovviamente, il tentativo di compiere ricerche avvalendosi di tale colonna è destinato al fallimento non rilevando presso la struttura del Data Base eXtraWay un corrispondente canale di ricerca. Per contro, le operazioni di inserimento, ad esempio, possono essere effettuate anche alimentando queste colonne. Esse verranno costituite come elementi (nodi figli) dell'elemento radice dell'unità informativa. Una volta create presso la prima unità informativa, il Server eXtraWay crea automaticamente un canale di ricerca anche per esse rendendo possibile compiere le selezioni.
Questo ci mostra come la mappatura sia assolutamente dinamica e dia un ampio grado di libertà a discapito di minori limitazioni. Sarà compito di chi progetta le applicazioni, basate sull'interfaccia nativa o su quella SQL, stabilire se e quali operazioni siano lecite e quindi quali interventi sulla struttura dei dati XML sia accettabile. Attualmente il server eXtraWay non è stato realizzato per imporre simili limitazioni ma non si esclude che ciò possa avvenire in seguito.
Parimenti, per l'uso corretto di un applicazione su entrambe i fronti, ovvero sia via SQL che per mezzo di un'applicazione eXtraWay è quanto mai importante che tutti gli estremi di configurazione vengano esplicitati in quanto sottintendere chiavi ed alias di ricerca può risolversi in un problema anche serio. Consulare, per maggior chiarezza, gli esempi di inserimento ed in particolare di modifica. (Vds. Esecuzione di operazioni di inserimento, modifica e cancellazione)
Una volta descritto come si compia la mappatura tra le unità informative delle basi dati eXtraWay e le tabelle di un DB relazionale ed, in esse, tra canali di ricerca e corrispondenti colonne si devono prendere in esame alcune altre limitazioni.
In particolare un'unità informativa non può essere denominata per mezzo di un elemento XML il cui nome inizi per una cifra. Questo è infatti contrario alle specifiche del'XML. Per convenzione, neppure le tabelle della mappatura SQL di una Base Dati eXtraWay possono essere identificate per mezzo di un nome che inizi per una cifra. Ne deriva che altrettanto deve potersi dire per i search alias adottati per rappresentare tabelle e colonne del Data Base.
A quanto detto va aggiunto che la sintassi SQL non prevede che il nome di una tabella possa contenere caratteri diversi da lettere, cifre ed il carattere '_' (underscore). La presenza di qualsiasi altro carattere comporta la necessità di usare negli statement SQL un meccanismo di aliasing.
Dal momento che nelle espressioni SQL dovrà essere possibile indicare degli identificatori di selezioni precedenti per operare, in sostanza, dei raffinamenti di su esse, si avrà la necessità di indicare il nome del file di selezione, la sola componente necessaria senza percorso o estensione. Essa, come avviene sin dall'origine dei programmi di 3D Informatica, è prefissata dalla cifra 3 e da 2 ulteriori caratteri che indicano la natura del file temporaneo e del suo contenuto. Ad esempio, i files aventi prefisso 3se sono comuni selezioni mentre il prefisso 3so identifica le selezioni sottoposte ad ordinamento.
Dal momento che, come detto, non è ammesso che una tabella sia denominata con un nome che inizia con una cifra, l'identificatore del file di selezione non può essere usato direttamente ma va racchiuso tra doppi apici.
Per analogia, una tabella che in eXtraWay fosse identificata da un nome che contenga un carattere non riconosciuto dal parser SQL dovrebbe a sua volta essere indicata tra doppi apici ed i canali ad essa associati dovrebbero essere identificabili tramite aliasing. In proposito su suggerisce di consultare la documentazione Sintassi SQL accettata da eXtraWay in materia di SELECT e nel dettaglio il paragrafo La Clausola FROM.
Di seguito, per convenzione, il server considererà un file di selezione ogni tabella che viene identificata con un nome che inizia col carattere 3.