J'ai une table de faits instantanés accumulée qui suit l' entrée et la sortie des conteneurs dans un terminal .

Les conteneurs peuvent entrer et sortir de 3 façons différentes , j'ai donc pensé à créer un tableau de dimensions spécifiques qui répertorie ces 3 voies possibles ( train, bateau ou camion ).

Ensuite, j'ai lu cet article qui dit essentiellement que cette technique est erronée, mais je ne comprends pas pourquoi.

Premier article:

Parfois, lorsqu'une table de faits contient une longue liste de faits peu peuplés dans une ligne individuelle, il est tentant de créer une dimension de type de mesure qui réduit la ligne de la table de faits à un seul fait générique identifié par la dimension de type de mesure. Nous ne recommandons généralement pas cette approche. Bien qu'il supprime toutes les colonnes de faits vides, il multiplie la taille de la table de faits par le nombre moyen de colonnes occupées dans chaque ligne et rend les calculs intra-colonnes beaucoup plus difficiles. Cette technique est acceptable lorsque le nombre de faits potentiels est extrême (par centaines), mais moins d'une poignée serait applicable à une ligne de table de faits donnée.

Je comprends que si une " dimension de type de mesure " est implémentée pour une table de faits de transaction, cela peut créer des problèmes comme le dit cet autre article , mais je ne vois aucun inconvénient si elle est utilisée pour un fait de capture instantanée .

Deuxième article: (quelques inconvénients de la mise en œuvre d'une "dimension de type de mesure")

1. [...] Si nous optons pour une "dimension de type mesure", nous perdrons cette capacité d'analyse. Si une mesure n'est pas compatible avec les autres mesures, nous ne pouvons pas les additionner.
2. [...] Plus le nombre de passes que notre SQL doit exécuter pour produire un rapport est important, plus le rapport est lent.
3. [...] Sur l'outil BI, si vous ne placez pas le filtre de type de mesure, vous risquez que l'utilisateur obtienne des "informations de détritus". Du point de vue de la convivialité, cette conception est une poubelle.

Réponse à la réponse de Mark Storey-Smith

Très belle approche, je n'y aurais jamais pensé.

Une autre chose: chaque entrée et sortie d'un véhicule qui amène un conteneur dans le terminal a un identifiant unique qui me donne d'autres informations comme: l'arrivée prévue du véhicule, l'arrivée réelle, si c'est un navire le quai, si c'est un camion le péage et beaucoup d'autres informations ...

Il s'agit de 3 tables de faits différentes et elles doivent être liées d'une manière ou d'une autre à la table de faits du conteneur.

Je pensais que l'ID du voyage était un degenerate dimension, donc il irait directement dans la table de faits des conteneurs. Donc, mon doute est le suivant: dois-je ajouter 6 champs différents dans la table de faits sur les conteneurs (navire_voyage_in_key, navire_voyage_out_key, train_voyage_in_key, train_voyage_out_key, truck_voyage_in_key, truck_voyage_out_key) ou juste 2 autres champs (voyage_in, voyage_out) qui sont liés dynamiquement aux différentes tables de voyage?

J'espère que mon doute est clair, merci.

Je pense que les indications font référence à un large tableau de faits où la majorité des valeurs de mesure sont nulles:

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
);

La suggestion est que certaines personnes verront toutes les valeurs nulles et décideront de le faire à la place:

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
);

Pas bon.

Dans votre scénario, je pense que je regarderais quelque chose comme ça, qui est très différent du scénario décrit dans les articles que vous avez référencés.

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;

Aux questions supplémentaires ...

J'ajouterais ExpectedEntryDate, ExpectedExitDateau Container/InventoryFact. Moins sûr, sans visibilité de tous les éléments de données, je mettrais probablement EntryVoyageIdet ExitVoyageIddans une dimension indésirable séparée ensemble comme une ligne avec tous les autres éléments de données dégénérés (identificateurs pour le camion, le train, etc.).

J'ajouterais 3 nouvelles dimensions pour VesselVoyage, TruckVoyageet TrainVoyageet 6 clés de voyage (entrantes / sortantes) à ce seul fait (c'est 6 nouvelles clés, pas 6 lignes supplémentaires). Vous avez alors la possibilité de placer Docket Tollboothdans la dimension Voyage appropriée. Si vous conservez les données génériques dans ces dimensions ( VesselFlag, TruckCapacity) et les données spécifiques dans une dimension indésirable ( VesselName, VesselMMSI), leur taille n'explosera pas.