Tengo una tabla de hechos de instantáneas acumuladas que rastrea la entrada y salida de contenedores en una terminal .

Los contenedores pueden entrar y salir de 3 formas diferentes , por lo que pensé en crear una tabla de dimensiones específica que enumere estas 3 formas posibles ( tren, barco o camión ).

Luego leí este artículo que básicamente dice que esta técnica es incorrecta, pero no puedo entender por qué.

Primer artículo:

A veces, cuando una tabla de hechos tiene una larga lista de hechos que está escasamente poblada en cualquier fila individual, es tentador crear una dimensión de tipo de medida que colapsa la fila de la tabla de hechos en un solo hecho genérico identificado por la dimensión de tipo de medida. Generalmente no recomendamos este enfoque. Aunque elimina todas las columnas de hechos vacías, multiplica el tamaño de la tabla de hechos por el número promedio de columnas ocupadas en cada fila, y hace que los cálculos dentro de una columna sean mucho más difíciles. Esta técnica es aceptable cuando el número de hechos potenciales es extremo (en cientos), pero menos de un puñado sería aplicable a cualquier fila de la tabla de hechos.

Entiendo que si se implementa una " Dimensión de tipo de medida " para una tabla de hechos de transacción, puede crear problemas como dice este otro artículo , pero no puedo ver ningún inconveniente si se usa para un hecho de instantánea acumulada .

Segundo artículo: (algunas desventajas de implementar una "Dimensión de tipo de medida")

1. [...] Si optamos por una "Dimensión de tipo de medida", perderemos esta capacidad analítica. Si una medida no es compatible con las otras medidas, no podemos sumarlas.
2. [...] Cuantos más pases necesite ejecutar nuestro SQL para producir un informe, más lento será el informe.
3. [...] En la herramienta de BI, si no coloca el filtro de tipo de medida, está arriesgando que el usuario obtenga "información basura". Desde el punto de vista de la usabilidad, este diseño es una basura.

Respuesta a la respuesta de Mark Storey-Smith

Muy buen enfoque, nunca hubiera pensado en eso.

Otra cosa: cada entrada y salida de un vehículo que lleva el contenedor a la terminal tiene una identificación única que me brinda otras informaciones como: llegada esperada del vehículo, llegada real, si es un barco, el muelle, si es un camión, el peaje y muchas otras informaciones ...

Estas son 3 tablas de hechos diferentes y deben vincularse de alguna manera a la tabla de hechos del contenedor.

Pensé que la identificación del viaje es un degenerate dimension, por lo que iría directamente a la tabla de hechos del contenedor. Por lo tanto, mi duda es: ¿debo agregar 6 campos diferentes en la tabla de hechos del contenedor (vessel_voyage_in_key, vessel_voyage_out_key, train_voyage_in_key, train_voyage_out_key, truck_voyage_in_key, truck_voyage_out_key) o solo 2 otros campos (voyage_in, voyage_out) a los diversos dinámicos?

Espero que mi duda sea clara, gracias.

Creo que la guía se refiere a una amplia tabla de hechos donde la mayoría de los valores de medida son nulos:

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 sugerencia es que algunas personas verán todos los valores nulos y decidirán hacer esto en su lugar:

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

No está bien.

En su escenario, creo que estaría viendo algo como esto, que es muy diferente al escenario descrito en los artículos a los que hizo referencia.

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;

A las preguntas adicionales ...

Yo agregaría ExpectedEntryDate, ExpectedExitDatea la Container/InventoryFact. Menos seguro, sin visibilidad de todos los elementos de datos, probablemente juntaría EntryVoyageIdy ExitVoyageIden una dimensión basura separada juntos como una fila junto con cualquier otro elemento de datos degenerados (identificadores para el camión, tren, etc.).

Agregaría 3 nuevas dimensiones para VesselVoyage, TruckVoyagey TrainVoyage6 claves de viaje (entrantes / salientes) a este hecho (son 6 nuevas claves, no 6 filas adicionales). Luego tiene la opción de colocar Docky Tollboothen la dimensión de Viaje apropiada. Si mantiene los datos genéricos en estas dimensiones ( VesselFlag, TruckCapacity) y los específicos en una dimensión basura ( VesselName, VesselMMSI) no explotarán en tamaño.