by
fabio
at
05-11-2008 19:31
|
|
|
|
|
Il popolamento iniziale del DB è una attività delicata da eseguire nella fase di avviamento del sistema.
I modi per svolgerla sono essenzialmente due:
1) tramite file CSV, come indicato nel suo post e come descritto nei manuali di CMDBuild
2) tramite batch SQL scritti ad hoc per operare direttamente sul database
1) File CSV
Demandando al sistema CMDBuild la garanzia di correttezza dell'inserimento dati è la soluzione consigliata, ma richiede alcune condizioni favorevoli.
In particolare richiede la disponibilità di file CSV già congruenti con il modello dati di CMDBuild in termini di numero, tipo e sequenza delle colonne e di collegamenti alle altre tabelle (campi "lookup" e "reference").
Per quanto riguarda le relazioni, almeno per quelle 1:N che prevedano un attributo di tipo "reference", il caricamento CSV si preoccupa di crearle automaticamente specificando nella colonna CSV corrispondente all'attributo di tipo "reference" il valore dell'attributo "Code" presente nella classe riferita (che ovviamente dovrà già essere stata popolata).
Idem per gli attributi "lookup" in cui dovrà essere stata specificata la descrizione della relativa voce tabellata (che ovviamente dovrà già essere stata definita).
La sequenza delle attività di importazione è quindi critica non tanto fra classi e relazioni, quanto piuttosto nell'ambito delle dipendenze fra le classi, nel senso che in caso di relazione 1:N dovranno essere importati prima i dati della classe "lato 1" e poi quelli della classe "lato N" (mentre le relazioni N:N possono essere importate tutte alla fine).
2) Batch SQL
La seconda possibilità è quella di creare dei batch SQL di inserimento dati tramite passaggi di:
a - caricamento "grezzo" dei dati di origine (Excel, CSV, Access, ecc) in uno schema temporaneo del database PostgreSQL, tramite appositi tool di mercato
b - sviluppo di script SQL per l’inserimento dei dati nelle rispettive classi (includendo al loro interno sia la creazione implicite delle relazioni per i campi "reference" che la codifica dei campi "lookup" che ogni altra funzione di trasformazione o elaborazione) e per l'inserimento delle relazioni non associate a campi reference nelle rispettive tabelle
c - verifica dei dati importati ed eventuali ripetizioni dei due punti precedenti in caso di disponibilità di dati aggiornati o di correzioni al loro formato
d - ripetizione finale degli stessi passaggi nel momento immediatamente precedente all’avvio in produzione del sistema
E' una soluzione che richiede una conoscenza più approfondita del database e comprende il rischio di "rovinarlo" e dover ripartire da zero, ma è per contro più flessibile in quanto può accettare in ingresso qualunque formato di dati (sempre che ci siano regole non equivoche per metterli in join fra di loro) preoccupandosi poi lei di "spalmarli" con le giuste logiche sulle varie tabelle.
Un secondo vantaggio è quello di poterla rieseguire con un comando unico in qualsiasi momento (ed in particolare al momento del passaggio in produzione del sistema) avendo la sicurezza di ottenere gli stessi risultati già verificati al passaggio precedente (mentre nel caso CSV è richiesta una sequenza di attività manuali per il caricamento dei file CSV nella giusta sequenza).
Un terzo vantaggio è che potendo appunto essere attivata in modalità batch e non presentando problemi di scadenza della sessione è forse meno problematica da eseguire in caso di importazione di file particolarmente estesi.
Per i motivi sopra descritti è anche la soluzione che normalmente adottiamo quando aziende o enti pubblici richiedono un nostro intervento diretto come gestori del progetto per eseguire questo tipo di servizio ed essere così supportati nell'attivazione del sistema CMDBuild.
|