UGISS Community

Salve dobbiamo migrare dei data mart sviluppati su Oracle verso SSAS 2005, ma non avendo esperienza in merito vorrei sapere se le dimensioni dei nostri DM sono tali da permettere un buon risultato in termini di prestazioni. La situazione attuale è la seguente:

1 DM con circa 25 dimensioni e 4 milioni di linee (una di queste dimensioni contiene 4 m di linee)

Gli altri 3 DM hanno tutti circa 5-8 dimensioni e contengono 7.5 m, 1.5m e 3.5 m di linee. 

Per unire le informazioni nei report oggi si utilizza un chiave comune a tutti i DM.

Come si comporterà SSAS? Si potrà utilizzare lo stesso sistema di chiave comune per poter effettuare statistiche con informazioni provenienti dai 4 DM?

Grazie per le risposte.

Per quei volumi il database risultante è considerato piccolo. Questo significa che si può gestire senza partizioni anche con la versione standard di SSAS.

Problemi di prestazioni non ce ne sono - al limite si possono fare membri calcolati particolarmente complessi che danno rallentamenti, e a questo proposito consiglierei di usare SSAS 2008 invece di SSAS 2005 proprio per evitare alcune situazioni che possono dare qualce problema. Ma per calcoli "nornali" grossi problemi non ce ne sono.

Per dare un'idea: un data mart medio ha tabelle dei fatti nell'ordine di qualche centinaio di milioni di righe, quelli grandi vanno dal miliardo in su.

Dal punto di vista della modellazione bisognerebbe fare alcune verifiche di merito, ma in linea di massima si può costruire un unico cubo con un measure group per ogni tabella dei fatti navigando così nei dati in modo integrato, sfruttando le dimensioni condivise.

Marco

Quindi come prima considerazione potrei dedurre che i miei 5 dm potrebbero diventare un unico "grande" cubo.

Per entrare nel merito del problema, oggi noi abbiamo un dm principale con gli incidenti d'auto e relative informazioni, il secondo prevede le informazioni sui veicoli coinvolti, il terzo le vittime ed il quarto le info sul conduttore. Riepilogando tu dici di creare un unico cubo con tutte le info accessorie di ogni singolo incidente.

Una cosa non mi è chiara tecnicamente su come risolvere un incidente.

La soluzione originale ed attualmente disponibile (dm su db relazionale, con star schema classico) prevede che il dm "vittime" abbia la granularità alla singola vittima. Io pensavo ad un'unica fact table "incidente" che prevede una tabella di collegamento per risolvere la relazione 1 incidente - n vittime. Con il relazionale non ci sono problemi. Con SSAS ed un unico cubo, si risolve tranquillamente questo problema? Sarà meglio usare un indicatore "Num vittime dell'incidente" ed una sola riga per ogni incidente oppure mantenere l'indicatore "Num vittime" sempre a 1, inserire n linee per ogni incidente in funzione delle vittime ed aggregare in fase di estrazione?

Un altra considerazione. La fact table unica, non avrà problemi con tutte queste dimensioni (circa una 30-35 sommando quelle attuali)?

Spero di essere stato chiaro.

Grazie.

Le dimensioni non sono tante per SSAS, come ti ho detto non vedo un problema prestazionale. Però sono tante per l'utente. Ho il dubbio che tu abbia meno dimensioni reali e alcuni attributi siano consolidabili in meno dimensioni (il che aiuta anche le prestazioni, tra l'altro).

Mentre è possibile che, soprattutto se sei alle prime armi con SSAS, sia la modellazione del tutto il vero problema, nel senso che alcune tecniche per rendere "intelligente" la navigazione nei dati possono richiedere alcuni artifici al di fuori di SSAS (come ETL o viste ad-hoc).

La granularità di measure group diversi può essere diversa, bisogna poi però ragionare sull'aggregabilità di alcune informazioni - ma se il database è creato come mi dici, è sufficiente far "scendere" le dimensioni dell'incidente sulle vittime per ottenere il risultato che hai con un DB relazionale attraverso delle join.

Ora, non possiamo fare l'analisi completa in questo thread ti invito magari a guardare il paper sulle many-to-many (http://www.sqlbi.com/manytomany.aspx) dove vedrai un po' di scenari di modellazione complessi, che tutto sommato sarebbero anche applicabili ai tuoi dati visti i volumi non elevati, e che possono offrire agli utenti dei meccanismi di analisi ancora più sofisticati.

Buon lavoro!

Marco

Molto chiaro e preciso.

Infatti il mio problema è proprio il fatto di non avere esperienza con SSAS. La modellazione dimensionale la conosco abbastanza bene, ma nel progetto non so fino a dove posso spingermi visto che sono qui come business analyst ed ho paura a spingermi oltre i miei compiti. Sto prendendo più info possibili proprio perché ho visto il progetto iniziale ed ho notato che c'erano molte anomalie. Mettendo insieme i tasselli, comincio a scoprire che chi ha fatto il modello proviene dal mondo transazionale e non aveva esperienza in BI.

Grazie ancora per l'aiuto.