ファクトテーブルの外部キーがnullですか？

私はデータマートの設計に不慣れで、いくつかの概念をクリアする必要があります。

ファクトテーブルにディメンションテーブルへの外部キー参照が格納されていることがわかるディメンションモデリングについて少し読んだことがあります。

ここで、phonenumberディメンションテーブルとphone_extensionディメンションテーブルがあるとします。（これらの表は、詳細が異なるため、組み合わせることができません）

私が理解しているように、これらの両方のディメンションテーブルには、パフォーマンスを向上させるための整数主キーがあり、ファクトテーブルには独自の整数主キーがあり、これらのディメンションテーブルへの外部キー参照も格納されます。

しかし、すべての電話番号に関連するphone_extensionがあるわけではない状況があるとします。（一部の電話番号には内線が必要ありません）

内線番号を持つ電話番号の場合、ファクトテーブルには両方のディメンションテーブルへの外部キー参照がありますが、電話番号のみで内線番号がない（およびその逆、つまり電話番号のない内線番号）状況をどのようにキャプチャしますか？

値とphone_extension外部キーがnullであるファクトテーブルの電話番号FKでこのような情報をキャプチャする必要がありますか？または、そのような非関連オブジェクトがファクトテーブルに記録されていませんか？

また、このデータマートのレポートを生成する必要があります。それでは、まずファクトテーブルをクエリしてディメンションキーの値を取得するか、ディメンションテーブルから直接レポートを作成しますか？

これを読んでくれてありがとう！
助けてくれてありがとう!!

一部のディメンションが不明または該当しない場合は、一部のディメンションテーブルのFKをNULLのままにすることができます。レポートクエリを実行するときは、外部結合を使用することを忘れないでください。

または、データマートディメンションの「なし」または「n / a」ディメンションレコードを作成し、NULLを使用するのではなく、ファクトテーブルのFKにデータを入力してこれらを指すようにする人もいます。外部結合を嫌うので、このアプローチのようにこれを行う人々。

実際にテーブルでNULL FKを使用する人は、通常、外部結合にバージョンを持っている人を嫌います。;）（言い換えれば、これは宗教戦争を引き起こす可能性がある文体の問題です）

私はどちらでもいいと言いますが、一つのアプローチを選び、熱心にそれに従います。

倉庫やマートにヌルを置かないでください。

ウェアハウスは十分に正規化されている必要があり（少なくともBCNF）、したがってNULLを除外する必要があります。Nullは、データソースに存在する場合はステージングテーブルに保持されますが、ウェアハウス自体では必要ありません。

マートは、プレゼンテーションツールとユーザークエリをサポートするように設計する必要があります。Nullは表示されず、ユーザークエリがより複雑でエラーが発生しやすくなるため、特に結合の対象となることが多い外部キー列では、Nullはそれらの邪魔になります。

ファクトのディメンションキーはnullであってはならず、エンドユーザー、レポートなどによる左外部結合の必要性を排除するために、ディメンションにfkを持っている必要があります。ファクトのすべてのロードは、ディメンションへの左外部結合を実行し、デフォルトで0キーまたはキーはまったくなく、失敗します。ディメンションへの結合を行うよりも失敗し、一部のユーザーが最終的にそれを見つけるまで（実際に行が見落とされるまで）、行を逃したことがわからない

phone_extensionディメンションに「n / a」レコードを作成し、それにリンクします。

私のthembのルールは、dwhの最後のデータマートでnullを使用できる唯一の値であるという事実自体です。そのため、avgなどの集約関数は引き続き機能します。