Ho una tabella dei fatti che accumula istantanee che traccia l' ingresso e l'uscita dei contenitori in un terminale .

I container possono entrare e uscire in 3 modi diversi , quindi ho pensato di creare una tabella dimensionale specifica che elenchi questi 3 modi possibili ( treno, nave o camion ).

Poi ho letto questo articolo che dice sostanzialmente che questa tecnica è sbagliata, ma non riesco a capire il perché.

Primo articolo:

A volte, quando una tabella dei fatti ha un lungo elenco di fatti che sono scarsamente popolati in ogni singola riga, si è tentati di creare una dimensione del tipo di misura che comprime la riga della tabella dei fatti in un singolo fatto generico identificato dalla dimensione del tipo di misura. In genere non consigliamo questo approccio. Sebbene rimuova tutte le colonne dei fatti vuote, moltiplica le dimensioni della tabella dei fatti per il numero medio di colonne occupate in ciascuna riga e rende molto più difficili i calcoli all'interno della colonna. Questa tecnica è accettabile quando il numero di fatti potenziali è estremo (in centinaia), ma meno di una manciata sarebbe applicabile a una determinata riga della tabella dei fatti.

Capisco che se una " Dimensione del tipo di misura " è implementata per una tabella dei fatti di transazione, può creare problemi come dice questo altro articolo , ma non vedo alcun aspetto negativo se usato per un fatto di accumulazione di istantanee .

Secondo articolo: (alcuni aspetti negativi dell'implementazione di una "Dimensione del tipo di misura")

1. [...] Se andiamo con una "Misura del tipo di dimensione" perderemo questa capacità analitica. Se una misura non è compatibile con le altre misure, non possiamo sommarle.
2. [...] Maggiore è il numero di passaggi che il nostro SQL deve eseguire per produrre un report, più lento sarà il report.
3. [...] Sullo strumento BI, se non si inserisce il filtro del tipo di misura, si rischia che l'utente ottenga "informazioni spazzatura". Dal punto di vista dell'usabilità, questo design è una spazzatura.

Risposta alla risposta di Mark Storey-Smith

Approccio molto bello, non ci avrei mai pensato.

Un'altra cosa: ogni entrata e uscita di un veicolo che porta container nel terminal ha un ID univoco che mi dà altre informazioni come: arrivo previsto del veicolo, arrivo effettivo, se è una nave il molo, se è un camion il casello e molte altre informazioni ...

Queste sono 3 diverse tabelle dei fatti e devono essere collegate in qualche modo alla tabella dei fatti del contenitore.

Ho pensato che l'ID del viaggio fosse un degenerate dimension, quindi andrebbe direttamente nella tabella dei fatti del contenitore. Quindi, il mio dubbio è: dovrei aggiungere 6 diversi campi nella tabella dei fatti del contenitore (vaso_voyage_in_key, vaso_voyage_out_key, train_voyage_in_key, train_voyage_out_key, truck_voyage_in_key, truck_voyage_out_key) o solo altri 2 campi (voyage_in, voyage_out) che linkano alla pagina?

Spero che il mio dubbio sia chiaro, grazie.

Credo che la guida si riferisca a un'ampia tabella dei fatti in cui la maggior parte dei valori di misura sono nulli:

CREATE TABLE dbo.SparseFact
(
    Dim1Key     INT NOT NULL
    , Dim2Key   INT NOT NULL
    , Dim3Key   INT NOT NULL
    , Dim4Key   INT NOT NULL
    , Dim5Key   INT NOT NULL
    , Value1    INT NULL
    , Value2    INT NULL
    , Value3    INT NULL
    , Value4    INT NULL
    , Value5    INT NULL
    , Value6    INT NULL
    , Value7    INT NULL
    , Value8    INT NULL
    ..
    , Value101  INT NULL
    , Value102  INT NULL
    , Value103  INT NULL
);

Il suggerimento è che alcune persone vedranno tutti i valori null e decideranno invece di farlo:

CREATE TABLE dbo.DontDoThisFact
(
    Dim1Key             INT NOT NULL
    , Dim2Key           INT NOT NULL
    , Dim3Key           INT NOT NULL
    , Dim4Key           INT NOT NULL
    , Dim5Key           INT NOT NULL
    , MeasureTypeKey    INT NOT NULL
    , Value             INT NOT NULL
);

Non bene.

Nel tuo scenario penso che starei guardando qualcosa di simile, che è molto diverso dallo scenario descritto negli articoli a cui hai fatto riferimento.

CREATE TABLE dbo.InventoryFact
(
    ContainerKey        INT NOT NULL
    , TransportTypeKey  TINYINT NOT NULL
    , EntryDateTime     DATETIME NULL
    , ExitDateTime      DATETIME NULL
);

CREATE TABLE dbo.TransportType
(
    TransportTypeKey    TINYINT IDENTITY(1,1) NOT NULL
    , EntryTransport    CHAR(10) NOT NULL
    , ExitTransport     CHAR(10) NOT NULL
);

INSERT
    dbo.TransportType
SELECT
    EntryTransport
    , ExitTransport
FROM
    (
    SELECT EntryTransport = 'Train'
    UNION
    SELECT EntryTransport = 'Truck'
    UNION
    SELECT EntryTransport = 'Vessel'
    UNION
    SELECT EntryTransport = 'N/A'
    UNION
    SELECT EntryTransport = 'Unknown'
    ) en
CROSS JOIN
    (
    SELECT ExitTransport = 'Train'
    UNION
    SELECT ExitTransport = 'Truck'
    UNION
    SELECT ExitTransport = 'Vessel'
    UNION
    SELECT ExitTransport = 'N/A'
    UNION
    SELECT ExitTransport = 'Unknown'
    ) ex;

Alle domande aggiuntive ...

Vorrei aggiungere ExpectedEntryDate, ExpectedExitDateal Container/InventoryFact. Meno sicuro, senza visibilità di tutti gli elementi di dati, probabilmente metterei EntryVoyageIde ExitVoyageIdin una dimensione spazzatura separata insieme come una riga insieme a qualsiasi altro elemento di dati degenerato (identificatori per camion, treno, ecc.).

Vorrei aggiungere 3 nuove dimensioni per VesselVoyage, TruckVoyagee TrainVoyagee 6 tasti Voyage (in entrata / uscita) a questo fatto (è 6 nuove chiavi, non 6 righe aggiuntive). Hai quindi la possibilità di posizionare Docke Tollboothnella dimensione di viaggio appropriata. Se mantieni i dati generici in queste dimensioni ( VesselFlag, TruckCapacity) e quelli specifici in una dimensione spazzatura ( VesselName, VesselMMSI) non esploderanno in termini di dimensioni.