ファクトテーブルの外部キーがnullですか？
私はデータマートの設計に不慣れで、いくつかの概念をクリアする必要があります。
ファクトテーブルにディメンションテーブルへの外部キー参照が格納されていることがわかるディメンションモデリングについて少し読んだことがあります。
ここで、phonenumberディメンションテーブルとphone_extensionディメンションテーブルがあるとします。 （これらの表は詳細が異なるため、組み合わせることができません）
私が理解しているように、これらの両方のディメンションテーブルには、パフォーマンスを向上させるための整数の主キーがあり、ファクトテーブルには独自の整数の主キーがあり、これらのディメンションテーブルへの外部キー参照も格納されます。
しかし、すべての電話番号に関連するphone_extensionがあるわけではない状況があるとします。 （一部の電話番号には内線番号が必要ありません）
内線番号のある電話番号の場合、ファクトテーブルには両方のディメンションテーブルへの外部キー参照がありますが、電話番号のみで内線番号がない場合（およびその逆、つまり電話番号のない内線番号）の状況をキャプチャするにはどうすればよいですか。 ？
値とphone_extension外部キーがnullであるファクトテーブルの電話番号FKでこのような情報をキャプチャする必要がありますか？または、そのような非関連オブジェクトはファクトテーブルに記録されていませんか？
また、このデータマートのレポートを生成する必要があります。それでは、まずファクトテーブルをクエリしてディメンションキーの値を取得するか、ディメンションテーブルから直接レポートを作成しますか？
これを読んでくれてありがとう！
感謝します!!
一部のディメンションが不明または該当しない場合は、一部のディメンションテーブルのFKをNULLのままにすることができます。レポートクエリを実行するときは、外部結合を使用することを忘れないでください。
または、データマートディメンションの「なし」または「n/a」ディメンションレコードを作成し、NULLを使用するのではなく、ファクトテーブルのFKにデータを入力してこれらを指すようにする人もいます。外部結合を嫌うので、このアプローチのようにこれを行う人々。
実際にテーブルでNULL FKを使用する人は、通常、外部結合にバージョンを持っている人を嫌います。 ;）（言い換えれば、これは宗教戦争を引き起こす可能性がある文体の問題です）
私はどちらでもいいと言いますが、一つのアプローチを選び、熱心にそれに固執します。
倉庫やマートにヌルを置かないでください。
ウェアハウスは十分に正規化されている必要があり（少なくともBCNF）、したがってヌルを除外する必要があります。 Nullは、データソースに存在する場合はステージングテーブルに保持されますが、ウェアハウス自体では必要ありません。
マートは、プレゼンテーションツールとユーザークエリをサポートするように設計する必要があります。 Nullは表示されないため、それらの邪魔になるだけで、ユーザークエリがより複雑でエラーが発生しやすくなります。
ファクトのディメンションキーはnullであってはならず、エンドユーザー、レポートなどによる左外部結合の必要性を排除するために、ディメンションにfkを持っている必要があります。ファクトのすべてのロードは、ディメンションへの左外部結合を行い、デフォルトで0キーまたはキーはまったくなく、失敗します。ディメンションへの結合を行うよりも失敗し、実際に行を逃したことがわからないまま、一部のユーザーが最終的にそれを見つけるまで（それが発生した場合）
phone_extensionディメンションに「n/a」レコードを作成し、それにリンクします。
私のthembのルールは、dwhの最後のデータマートでnull値を許容する唯一の値であるという事実自体です。そのため、avgのような集約関数は引き続き機能します。