| At line 1 changed 59 lines |
| [{TableOfContents }] |
|
| ! Provocazione |
| Attualmente in CUBE.up sono gestite bene: |
| * Le gerarchie |
| * Le estrazioni |
| I dati estratti sono completati mediante la £D9C ecc e salvati in membri dei file D9WKDT e D9WKDS, il Primo contenente i dati in formato CSV contenenti per ogni oggetto le gerarchie richieste a livello di tabella e il secondo la struttura del cubo utilizzata per la creazione degli indici. |
| |
| Ora si pongono le seguenti domande: |
| * Perchè non facciamo vedere tali dati in LOOC.up? |
| * Possiamo migliorare / ottimizzare il processo di creazione dei cubi |
| |
| Supponiamo ad esempio le ipotesi seguenti: |
| * L'estrazione porta sul file solo gli oggetti primari e i valori |
| * Salva l'insieme di tutti gli oggetti trattati e per ogni oggetto salva: |
| ** Attributi propri (gerarchia richiesta) |
| ** Puntatori ai record in cui si tratta l'oggetto |
| ** Totali dei valori (diciamo più record per oggetto. Ad esempio totali e numero righe per poter calcolare media ecc.) |
| * Salvo inoltre le informazioni sugli oggetti primari e sul significato dei valori |
| |
| A questo punto potrei procedere a salvare anche i totali sugli oggetti ottenuti associando attributi agli oggetti primari. |
| |
| Vediamo cosa potrei ottenere in una scheda |
| # Dati riepilogativi del cubo (Quando è stato creato, tempo di costruzione, numero di righe, chi lo ha creato, fonte e dati della fonte, ecc.) |
| # Tipi di oggetto trattati |
| # Lista degli oggetti di un tipo (con decodifica e numero di righe dettaglio presenti) |
| # Dettaglio di un tipo |
|
| ! Modalità dell'intervento |
| * Estensione delle modalità di salvataggio della D9B (oltre DATABEACON, EXCEL,) |
| * Modifica della COPY. |
| ## Salviamo direttamente le schiere £9K, £9A, £9V |
| ## Salviamo le impostazioni di base e i dati statistici |
| * Richiamo di un programma di costruzione che esegue i passi seguenti: |
| ## Oggetti (potrei anche rileggere N volte il file, una per oggetto base |
| ## Puntatori (riordino la schiera e salvo un record per oggetto diverso su un file con oggetto e 30.000 caratteri (tipo JADOCU) che comunque accetta più righe (quindi ad esempio se il puntatore è di 7 caratteri in ogni record ne contengo oltre 4.000 ma posso avere più righe. |
| ## Costruzione dei totali ancora nel file precedente sempre con puntatore al totale di ogni oggetto |
| ## Costruzione delle gerarchie e dei totali per gerarchia |
|
| ! Vantaggi / Svantaggi |
| # Vantaggi |
| * Tempi di costruzione comunque migliori |
| * Potrei utilizzare questa struttura come partenza per costruire il cubo |
| * Potrei facilemnte decidere a posteriori le aggregazioni e le gerarchie |
| * Potremmo cercare tutti i cubi in cui si parla di un oggetto (esempio dato un cliente vedo che si parla di lui nel fatturato 2007, budget, scadenze ecc..) |
| # Svantaggi |
| * Avremmo comunque dei limiti: |
| ** Limiti preesistenti |
| ### Numero di oggetti base |
| ### Numero di valori |
| ** Limiti non vincolanti ma di buon senso |
| ### 200.000 righe di dettaglio |
| ### 10.000 oggetti diversi per ogni tipo ammesso |
| * Non si prevedono gli incroci in modo libero |
| * Tendenzialmente dovremmo accedere al cubo partendo da un oggetto |
|
| ! Passaggio al costruttore |
| Se fisso un oggetto posso portare il dettaglio nel "costruttore 03". A questo punto il dettaglio può essere facilmente manipolato a piacere, riaggregando totalizzando, guardando l'incidenza, l'ABC ecc. ecc. |
| |
| ![BI in Looc.up] |
| ![Pentaho BI Suite] |
