ファクトテーブルでのさまざまなタイプの処理
OLTPデータベースからデータを取得するデータウェアハウスを構築しようとして、初めて次元モデリングで作業しています。これで何をすべきかを理解するのに問題があります。シナリオのタイプ。データベースは寄付を財団に追跡します。「粒度」が単一の寄付、つまり「トランザクション」レベルであるようなファクトテーブルが欲しいのです。寄付はさまざまなタイプの寄付者から来ることができます。たとえば、実際には4つの関連カテゴリがありますが、それらは個人や企業に由来します。ソースデータには、これらのドナータイプごとにテーブルがあります。したがって、individualsテーブルとcompaniesテーブル。個人と会社の属性は大きく異なります。一般的なレポート要件は、すべてのタイプの寄付の合計を確認し、寄付者のタイプごとに寄付を深く掘り下げることです。私の最初の考えは、そのようなスキーマを構築することでした
（色は意味がありませんが、強調表示されたテーブルが選択されたときにたまたまスクリーンショットを撮っただけです）
企業と個人は非常に異なる属性を持っているので、アイデアはそれらを独自のテーブルに保持し、それらをディメンションにすることでした。 （実際には、このようなタイプが4つ以上あることに注意してください）。
しかし、これはファクトテーブルに多数のNULL外部キーが存在することを意味するため、明らかに良い方法ではありません。私はこれがノーノーであることを読みました（理由はわかりませんが）。
別のオプションは、CompanyおよびUsersテーブルを1つの大きなドナーテーブルに結合することです。
これにより、ディメンションテーブルが単純になる代わりに、ファクトテーブルからNULL外部キーが削除されます。ドナーディメンションテーブルは非常に広くなり、null属性のロットが含まれます（ここでも、表現されるドナーには4種類以上あることに注意してください） 、それぞれに固有の属性があります）。
最後に、CompanyテーブルとIndividualテーブルを参照するドナーディメンションを持つオプションがあります。これは次のようになります。
これで、すべてのnull外部キーがドナーディメンションテーブルにあります。もちろん、これはもはやスタースキーマではありません。
私はこのような状況に対処するためのいくつかの一般原則を見つけるために、考えられるあらゆる場所を検索してきましたが、私は足りません。これはデータウェアハウジングの標準的な問題であるように思われるため、これに対処する標準的な方法があるかどうか疑問に思っています。
私は3つのオプションを避けます。スタースキーマの代わりにスノーフレークと呼ばれています。これは、必要なときに使用できるかなり高度なソリューションですが、独自の欠点もあります。いつものように、データウェアハウス設計のヒントを探すときは、キンボールを参照してください。
これは、彼らが言うことです スノーフレーク、アウトリガー、およびブリッジ ：
通常、スノーフレーキングではなく、多対1の階層関係を単一のディメンションテーブルで処理することをお勧めします。スノーフレークは、経験豊富なOLTPデータモデラーには最適に見えますが、DW/BIクエリのパフォーマンスには最適ではありません。リンクされたスノーフレークテーブルは、テーブル構造に直接さらされているユーザーに複雑さと混乱をもたらします。ユーザーがテーブルからバッファリングされている場合、スノーフレークにより複雑さが増します
1または2に関しては、レポートの要件次第であり、ディメンションメンバー（ディメンション内のレコード）をレポート対象の1つの "軸"と見なす必要があります。複数の種類のレコードを1つのディメンションに組み合わせることでメリットが得られる場合があります（パフォーマンスを改善するために階層と属性の関係を定義するなど）。ただし、この場合は、エンティティごとに別々のディメンションを使用します。
繰り返しますが、キンボールはこれを 次元モデリングの基本 で説明しますが、このテーマについての記事はもっとあります。
ルール＃1：詳細なアトミックデータを次元構造にロードします。
ルール＃2：ビジネスプロセスを中心に次元モデルを構造化します。
ルール＃8：ディメンションテーブルが代理キーを使用していることを確認します。
ファクトテーブルの外部キーのNULL値については、いずれにせよsurrogate keysを使用して解決する必要があります。
私は ここで関連する質問に答えました ですが、基本的には Nullのデフォルト値の選択 に戻ります。これは、ディメンションの欠落データを処理する方法を説明しています。
Nullを回避する必要がある最初のシナリオは、ETLプロセス中にファクトテーブル行の外部キーとしてnull値が発生した場合です。ファクトテーブルの外部キーフィールドの実際のnull値は参照整合性に違反するため、この場合は何かを行う必要があります。
ある意味では「NULLはノーノー」と解釈できますが、実際には「N/Aなどのダミーレコードをディメンションに挿入し、そのレコードのサロゲートキーをファクトテーブルの外部キーフィールドで使用する」という意味です。
@TomVはすでにこれでうまく答えました。基本的に各ケースを個別のディメンションに分割したい場合は、代理キーでダミーレコードを作成します。ビジネスケースに適しているかどうかはわかりませんが、よくあることです。
完全を期すために、ファクトテーブルのNULLに関するキンボールの言葉を次に示します。
Null値の測定は、ファクトテーブルで正常に動作します。集約関数（SUM、COUNT、MIN、MAX、およびAVG）はすべて、nullファクトで「正しいこと」を実行します。ただし、ファクトテーブルの外部キーではnullを回避する必要があります。これらのnullは自動的に参照整合性違反を引き起こすためです。 nullの外部キーではなく、関連付けられたディメンションテーブルには、不明または適用されない条件を表す既定の行（および代理キー）が必要です。