ターミナルでのコンテナの入口と出口を追跡する累積スナップショットファクトテーブルがあります。

コンテナーは3つの異なる方法で出入りできるので、これら3つの可能な方法（列車、船舶、またはトラック）をリストする特定のディメンションテーブルを作成することを考えました。

それから私はこのテクニックを間違っていると基本的に言っているこの記事を読みました、しかし私はその理由を理解できません。

最初の記事：

ファクトテーブルに、個々の行にまばらに入力されているファクトの長いリストがある場合、ファクトテーブル行をメジャータイプディメンションで識別される単一の汎用ファクトに折りたたむメジャータイプディメンションを作成したくなることがあります。通常、この方法はお勧めしません。空のファクト列はすべて削除されますが、ファクトテーブルのサイズに各行の占有列の平均数が乗算され、列内の計算がはるかに困難になります。この手法は、潜在的なファクトの数が（数百単位で）極端な場合に許容されますが、特定のファクトテーブル行に適用できるのは一握りではありません。

「メジャータイプディメンション」がトランザクションファクトテーブルに実装されている場合、この他の記事にあるような問題が発生する可能性があることは理解していますが、スナップショットファクトの蓄積に使用してもマイナス面は見られません。

2番目の記事：（ 「メジャータイプディメンション」の実装のいくつかの欠点）

1. [...]「メジャータイプディメンション」を使用すると、この分析能力が失われます。1つのメジャーが他のメジャーと互換性がない場合、それらを合計することはできません。
2. [...]レポートを作成するためにSQLが実行する必要のあるパスの数が多いほど、レポートは遅くなります。
3. [...] BIツールでメジャータイプフィルターを配置しない場合、ユーザーが「ゴミ情報」を取得する危険があります。使いやすさの観点から見ると、このデザインはごみです。

Mark Storey-Smithの回答への応答

とても素敵なアプローチ、私はそれについて考えたことはなかったでしょう。

もう1つ：コンテナをターミナルに持ち込む車両のすべての出入り口には一意のIDがあり、次のような情報が得られます。車両の到着予定、実際の到着、船の場合はドック、トラックの場合は料金所、他の多くの情報...

これらは3つの異なるファクトテーブルであり、何らかの方法でコンテナファクトテーブルにリンクする必要があります。

航海のIDはであると思った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）を追加する必要があるかどうかです。

私の疑問が明確になれば幸いです、ありがとう。

ガイダンスはメジャー値の大部分がnullである幅広いファクトテーブルを参照していると思います。

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別ジャンク次元で互いに一列のような任意の他の縮退データ項目とともに（トラックの識別子を、等を訓練します）。

この1つのファクトにVesselVoyage、TruckVoyageおよびの3つの新しいディメンションTrainVoyageと6つの航海キー（インバウンド/アウトバウンド）を追加します（6つの新しいキーであり、6つの追加行ではありません）。その後、配置のオプション持たDockおよびTollbooth適切な航海次元のを。一般的なデータをこれらのディメンション（VesselFlag、TruckCapacity）に保持し、特定のデータをジャンクディメンション（VesselName、VesselMMSI）に保持すると、サイズが爆発することはありません。