Diventare una XML Company
E' un tema su cui vorrei fare qualche considerazione, che amplierò nel tempo.
Premetto solo, per brevità, che l'XML è uno standard che consente di strutturare le informazioni presenti in un file, che può essere un normale file di testo, una pagina web, un messaggio, ecc.
Maggiori informazioni si possono trovare sul sito del World Wide Web Consortium.
Per un'Azienda, il termine "XML company" significa adottare una ben precisa strategia come foundation della propria politica di IT governance.
In termini pratici, significa adottare l'XML come standard di base per:
Normalmente tutti questi dati sono gestiti dalle applicazioni utilizzando database relazionali. Si tratta sicuramente di un approccio efficente, ed adatto alla gestione "concorrente" (ovvero quando più operatori o lavori interagiscono contemporaneamente con gli stessi dati), ma pone qualche problema.
La rappresentazione relazionale dei dati richiede infatti una normalizzazione della struttura del dato per adattarla alla forma di tabella, tale operazione comporta spesso una certa rigidità nella struttura.
Facciamo l'esempio del classico ordine: in un database relazionale avrò una tabella con le testate (numero e data, dati del cliente, ecc.), ed una tabella con le righe (dettaglio dei prodotti). Se però la mia azienda ha una struttura di prodotti complessa, rappresentare "1 prodotto = 1 riga d'ordine" può essere problematico: potrei ad esempio avere dei prodotti con una configurazione (es. un PC con 2 hard disk, 3 banchi di memoria, monitor LCD, scheda modem, ecc.), oppure avere dei servizi collegati a singole righe d'ordine, ecc. ecc.
Usando l'XML per rappresentare il "documento ordine" posso invece trarre beneficio da una struttura dati molto più flessibile, che può essere facilmente espansa ed adattata nel tempo al mutare delle esigenze dell'azienda.
Questo approccio non significa passare "tutti" i propri dati in formato XML: generalmente è buona norma rappresentare in tale formato i dati di tipo documentale o transazionale (ovvero quelle strutture dati che hanno un loro ciclo di vita ben definito, o che rappresentano un documento, una transazione contabile o commerciale, ecc.). I dati di riepilogo, saldo, controllo, ecc. è invece opportuno che rimangano nei database relazionali, strettamente integrati con le applicazioni che li gestiscono. Sempre nell'esempio precedente, la giacenza dei prodotti, il saldo del credito del cliente, sono dati che vanno gestiti in un database, in modo da essere prontamente interrogabili ed aggiornabili con sicurezza.
... continua ...
Premetto solo, per brevità, che l'XML è uno standard che consente di strutturare le informazioni presenti in un file, che può essere un normale file di testo, una pagina web, un messaggio, ecc.
Maggiori informazioni si possono trovare sul sito del World Wide Web Consortium.
Per un'Azienda, il termine "XML company" significa adottare una ben precisa strategia come foundation della propria politica di IT governance.
In termini pratici, significa adottare l'XML come standard di base per:
- l'integrazione fra applicazioni
- la memorizzazione dei dati di riferimento
- l'archiviazione dei dati consolidati
Normalmente tutti questi dati sono gestiti dalle applicazioni utilizzando database relazionali. Si tratta sicuramente di un approccio efficente, ed adatto alla gestione "concorrente" (ovvero quando più operatori o lavori interagiscono contemporaneamente con gli stessi dati), ma pone qualche problema.
La rappresentazione relazionale dei dati richiede infatti una normalizzazione della struttura del dato per adattarla alla forma di tabella, tale operazione comporta spesso una certa rigidità nella struttura.
Facciamo l'esempio del classico ordine: in un database relazionale avrò una tabella con le testate (numero e data, dati del cliente, ecc.), ed una tabella con le righe (dettaglio dei prodotti). Se però la mia azienda ha una struttura di prodotti complessa, rappresentare "1 prodotto = 1 riga d'ordine" può essere problematico: potrei ad esempio avere dei prodotti con una configurazione (es. un PC con 2 hard disk, 3 banchi di memoria, monitor LCD, scheda modem, ecc.), oppure avere dei servizi collegati a singole righe d'ordine, ecc. ecc.
Usando l'XML per rappresentare il "documento ordine" posso invece trarre beneficio da una struttura dati molto più flessibile, che può essere facilmente espansa ed adattata nel tempo al mutare delle esigenze dell'azienda.
Questo approccio non significa passare "tutti" i propri dati in formato XML: generalmente è buona norma rappresentare in tale formato i dati di tipo documentale o transazionale (ovvero quelle strutture dati che hanno un loro ciclo di vita ben definito, o che rappresentano un documento, una transazione contabile o commerciale, ecc.). I dati di riepilogo, saldo, controllo, ecc. è invece opportuno che rimangano nei database relazionali, strettamente integrati con le applicazioni che li gestiscono. Sempre nell'esempio precedente, la giacenza dei prodotti, il saldo del credito del cliente, sono dati che vanno gestiti in un database, in modo da essere prontamente interrogabili ed aggiornabili con sicurezza.
... continua ...
