Salve,
avrei da porvi una questione tecnica relativa al popolamento del CMDB ovvero,
avendo progettato un CMDB con più classi ciascuna delle quali ha un numero elevato di occorrenze (nell'ordine delle centinaia di migliaia) e di relazioni avrei necessità di capire quale strategia adottare nella fase di implementazione e popolamento massivo:
1- creare le classi e le relazioni - importare i dati da file csv
2- creare le clasii - importare i dati - creare le relazioni
la domanda deriva da una serie di valutazioni che si basano sulle best practices quando si opera su DB.
Grazie
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.
Buongiorno,
grazie per la sollecita risposta in merito ma ho ancora il seguente dubbio:
supposto di:
1 avere i file csv perfettamente allineati alle classi a cui fanno riferimento
2 aver creato tutte le lookup table
3 avere su carta definito tutte le relazioni fra classi
4 di voler utilizzare la funzione di import del cmdbuild
è più conveniente la strategia di:
1 effettuare l'import dei file CSV relativi alle varie classi
2 definire le relazioni qualunque ne sia la cardinalià
oppure
1 definire le relazioni
2 effettuare l'import dei file CSV
Grazie
Come indicato nella precedente risposta l'import da file CSV crea automaticamente le relazioni 1:N a cui siano associati dei campi "reference" (il caso di gran lunga più diffuso durante le operazioni di caricamento iniziale del database) popolando le relative tabelle, ed è quindi chiaramente preferibile averle già definite nel modello dati ed aver già inserito nel file CSV da importare le corrispondenti colonne "reference" che il sistema utilizzerà per il link.
Per quanto riguarda le relazioni N:N, dovendo essere popolate manualmente o tramite script SQL è indifferente definirle prima o dopo il caricamento dei file CSV.
Grazie per le indicazioni.