У меня есть таблица фактов накопительного снимка, которая отслеживает вход и выход контейнеров в терминале .

Контейнеры могут входить и выходить тремя различными способами , поэтому я подумал о создании определенной таблицы измерений, в которой перечислены эти 3 возможных пути ( поезд, судно или грузовик ).

Затем я прочитал эту статью, в которой в основном говорится, что эта техника неправильна, но я не могу понять, почему.

Первая статья:

Иногда, когда таблица фактов содержит длинный список фактов, которые редко заполняются в какой-либо отдельной строке, возникает соблазн создать измерение типа меры, которое сворачивает строку таблицы фактов до одного общего факта, идентифицируемого измерением типа меры. Мы обычно не рекомендуем такой подход. Хотя он удаляет все пустые столбцы фактов, он умножает размер таблицы фактов на среднее число занятых столбцов в каждой строке и значительно усложняет вычисления внутри столбцов. Этот метод является приемлемым, когда число потенциальных фактов является предельным (в сотнях), но к любой данной строке таблицы фактов будет применимо меньше, чем несколько.

Я понимаю, что если для таблицы фактов транзакции реализовано « Измерение типа измерения », это может создать проблемы, как в этой статье , но я не вижу никаких недостатков, если использовать их для факта накапливающегося снимка .

Вторая статья: (некоторые недостатки реализации «Измерения типа измерения»)

1. [...] Если мы будем использовать «Измерение типа измерения», мы потеряем эту аналитическую способность. Если одна мера не совместима с другими мерами, мы не можем их сложить.
2. [...] Чем больше проходов нужно выполнить нашему SQL для создания отчета, тем медленнее будет отчет.
3. [...] В инструменте BI, если вы не включите фильтр типа меры, вы рискуете получить «мусорную информацию». С точки зрения удобства использования этот дизайн - мусор.

Ответ на ответ Марка Стори-Смита

Очень хороший подход, я бы никогда не подумал об этом.

Другое дело: каждый въезд и выезд транспортного средства, которое доставляет контейнер в терминал, имеет уникальный идентификатор, который дает мне другую информацию, такую ​​как: ожидаемое прибытие транспортного средства, фактическое прибытие, если это судно, стоянка в доке, если это грузовик, сборная и много другой информации ...

Это 3 разные таблицы фактов, и они должны быть как-то связаны с таблицей фактов контейнера.

Я думал, что идентификатор рейса - это a degenerate dimension, поэтому он напрямую попадет в таблицу фактов контейнера. Итак, я сомневаюсь: нужно ли мне добавить 6 различных полей в таблицу фактов контейнера (vessel_voyage_in_key, vessel_voyage_out_key, train_voyage_in_key, train_voyage_out_key, truck_voyage_in_key, truck_voyage_out_key) или только 2 других поля (voyage_in, Voyage_out, Voyage_out)?

Я надеюсь, что мои сомнения ясны, спасибо.

Я полагаю, что руководство ссылается на широкую таблицу фактов, где большинство значений показателей равны нулю:

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

Предполагается, что некоторые люди увидят все нули и решат сделать это вместо этого:

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

Фигово.

В вашем сценарии я думаю, что я смотрю на что-то подобное, что сильно отличается от сценария, описанного в статьях, на которые вы ссылались.

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;

К дополнительным вопросам ...

Я бы добавил ExpectedEntryDate, ExpectedExitDateк Container/InventoryFact. Менее уверенный, без видимости всех элементов данных, я бы, вероятно, поместил бы EntryVoyageIdи ExitVoyageIdв отдельном мусорном измерении вместе в одну строку вместе с любыми другими вырожденными элементами данных (идентификаторы для грузовика, поезда и т. Д.).

Я хотел бы добавить 3 новых размеров для VesselVoyage, TruckVoyageи TrainVoyageи 6 Voyage ключей (входящий / исходящий) к этому один факт (это 6 новых ключей, а не 6 дополнительных строк). Затем у вас есть возможность размещения Dockи Tollboothв соответствующем измерении Voyage. Если вы сохраните общие данные в этих измерениях ( VesselFlag, TruckCapacity) и специфические в ненужном измерении ( VesselName, VesselMMSI), они не будут расти в размерах.