1

皆さん、

顧客から受け取ったファイルの情報を保持する DIM_FILE というディメンション テーブルがあります。各ファイルには、FACT テーブル CUST_DETAIL を構成する詳細レコードがあります。メイン プロセスでは、ファイルはいくつかの段階を経て、各段階でステータスがタグ付けされます。要するに、私は多対多の関係を持っています。スター スキーマのディメンション モデリングに関するアイデア。顧客レコードは単一のファイルにのみ属し、ファイルは複数のステータスを持つことができます。

FACT
----
CustID
FileID
AmountDue


DIM_FILE
--------
FileID
FileName
DateReceived

FILE_STATUS
-----------
FileID
StatusDateTime
StatusCode
4

1 に答える 1

2

これを次元モデル/スター スキーマと組み合わせるためにできることがいくつかあります。

  1. 2 つのスターを構築します (おそらく、それらは異なるデータマートに配置される可能性があります)。1 つにはファクト テーブルとして FACT があり、もう 1 つのスターにはファクトとして FILE_STATUS があります (これはトランザクション粒度のファクト テーブルと見なすことができます)。これを機能させるには、おそらく非正規化して CustId を FILE_STATUS にも追加します
  2. FILE_STATUS を扱っているので、FACT を累積スナップショットファクト テーブルに変えることができます。このモデルでは、FACT に追加の列の個別のセットを用意して、各ステータス遷移に属するすべての情報を記録します。少なくとも、特定のステータスに達したときに記録する日付/時間ディメンションの列が必要です。ETL では、ファクト テーブルを更新して、ファイルの状態がどのように進行するかを記録する必要があります。この設計は、ステータスの数が有限で比較的少ない場合にのみ機能します。さらに、ステータスの進行の多かれ少なかれ明確なパスが存在する必要があります (顧客の注文の場合のように: 受領 -> ピッキング -> 梱包 -> 出荷 -> 支払い済み)。
  3. ステータスのいわゆる多値ディメンションを作成します。FACT はこの新しいディメンションへのキーを取得し、この新しいディメンションは実際には FACT テーブルの行に適用されるステータスのコレクションを表します。
  4. あなたはブリッジテーブルを持つことができます（私はそれがこの主題に当てはまるとは思いませんが、確かではありません）

参考文献:

スナップショットの蓄積: http://blog.chrisadamson.com/2007/03/accumulating-snapshot-use-accumulating.html

多値ディメンションとブリッジ テーブル: http://www.kimballgroup.com/data-warehouse-business-intelligence-resources/kimball-techniques/Dimension-modeling-techniques/multivalued-dimension-bridge-table/

于 2010-01-06T21:17:00.837 に答える