Dimensione e fatto per le stesse entità?

Sono piuttosto nuovo nella progettazione DW e sto lavorando su un DW per modellare alcune infrastrutture IT.

Il problema / domanda principale a questo punto è come modellare le informazioni sull'unità.

Raccoglieremo dati aggregati su file e cartelle e dati separati su unità fisiche. Le informazioni sull'unità includeranno almeno lo spazio totale e libero e verranno aggiornate più volte alla settimana.

Una delle domande di business a cui dovrà essere data risposta è come l'utilizzo dell'azionamento tende nel tempo. Le informazioni sull'unità verranno utilizzate anche in una gerarchia che porta anche al livello del file / cartella.

Le opzioni che posso vedere ora sono:

1. Implementare DRIVEcome una dimensione

   • Semplifica la progettazione della gerarchia
   • Ciò causerà problemi con la segnalazione? Mi sembra controintuitivo riportare i dati limitati nel tempo solo su una dimensione
   • Sembra anche problematico avere una dimensione che SAPI cambierà ogni volta che aggiorni i tuoi dati

2. Implementare DRIVEcome una tabella dei fatti

   • Semplifica i rapporti
   • Gerarchia dei complicati (?): Userò Driveper mappare i dati su un server o computer specifico. È corretto utilizzare una tabella dei fatti come livello intermedio in una gerarchia? Non penso lo sia.

3. Implementare DRIVEsia un fatto che una dimensione

   • Il fatto conterrà solo la chiave, la data e i fatti sullo spazio
   • La dimensione includerà altri dati non additivi come il computer in uso, ecc.
   • Sembra risolvere entrambi i problemi, ma è un anti-schema?

Mi aspetto di avere una tabella dei fatti drive_usage con un collegamento a una dimensione temporale dell'istantanea, una dimensione dell'unità, una dimensione del computer e i vari fatti numerici sull'unità in quell'istante nel tempo.

Probabilmente non dovrebbe esserci nulla che cambi regolarmente nella dimensione dell'unità - immagino che dipenda dalla tua definizione di unità - è un'unità fisica o un'unità logica o cosa. Forse l'unità "C" ha un numero seriale e viene sostituita, quindi la dimensione scadrà e verrà aggiunta una nuova dimensione. Queste cose su una dimensione non sono in realtà "fatti", sono attributi. Ciò non influirebbe sui rapporti perché i dati per il computer X, l'unità C hanno continuità. Allo stesso modo se il computer X viene aggiornato da dual core a quad core e quindi c'è una modifica alla dimensione (supponendo che qualcosa oltre il numero di core non venga tracciato in una tabella dei fatti, come una revisione della scheda madre). La capacità di un disco sarebbe nella tabella dei fatti, quindi le modifiche a questo nel tempo sono solo nuovi fatti con nuove date. A volte puoi persino modellare le modifiche all'appartenenza come fatti. vale a dire se un giorno le unità fisiche 1-5 si trovano nell'unità logica C e le unità fisiche 1-6 si trovano nell'unità logica C il giorno successivo, ciò potrebbe essere solo un cambiamento di fatto nella tabella dei fatti di appartenenza all'unità fisica. Questi sono ciò che alcune persone chiamano tabelle dei fatti privi di fatto, poiché l'unico fatto è l'esistenza della riga mostra l'appartenenza: non c'è molto da fare se non il totale o il conteggio.

Quando entri nelle cartelle, modellare la gerarchia può essere molto più complicato a seconda di ciò che stai cercando di ottenere con i rollup.

C'è molta arte nella modellazione DW nei domini che non sono scenari comuni.