0

現在、データマート設計に取り組んでいます。ディメンションテーブルには多くのの外部キーがあります。外部キーのディメンションフィールドにNULLを許可するか、または-1NULL値を表すかどうかを検討しています。データマートの外部キー列にNULLがあることにパフォーマンスに影響はありません

Kimballはデフォルトの行をNULLの値に保つことを提案しています。 http://www.kimballgroup.com/data-warehouse-business-intelligence-resources/kimball-techniques/dimensional-modeling-techniques/fact-table-null/

私の主導では、NULLNULLとすることを推奨します。

NULLを外部キーフィールドに保存するとパフォーマンスに影響はありますか?

答えて

2

キンボールは正しいです(彼が通常そうです)。 NULLを使用するデフォルト値を使用します。

なぜですか?ディメンションへの結合によって、誤って行がフィルタされることはありません。さまざまなクエリの結果を調整しようとすると、多くの時間がかかります。結合が成功することを保証することは、このような相違を減らす1つの方法です。

あなたのアドバイスに従わない場合は、NULLを使用して保存してください。 -1のような値は、データベースが外部キー制約を強制しないため、特に悪いことです。

+0

私はあなたの意見に同意します。 NULLの場合は-1を使用します。 –

1

GordonがカバーしていないNULLを使用しないようにする別の理由は、NULLが何を意味するのか不明です。

ETLまたはソース・システムで問題が発生しNULLが発生したため、データ・マートまたはデータ・ウェアハウスにNULLがあることがあります。その列がその特定の行に適用されないため、NULLを持っている場合もあります。または、累積スナップショット表のようなものの場合は、報告されているプロセスがまだその列が移入される時点に達していないため、その列にはまだデータが移入されていないためです。

1つのデフォルト値ではなく、複数設定することができます。たとえば、欠損値に使用できる「不明」を示す行と、値が適用されない場合の「該当なし」を示す行を持つように各ディメンションを設定できます。私はこれらのキーを負の整数で設定する傾向があります(-1はUnknown、-2はN/Aなど)。これにより、すべてのテーブルでこれらの行に同じキーを使用できるようになります。しかし、KimballとGordonの両方が示しているように、あなたは実際にあなたの次元でそれらの行を作成すべきです。

これは、データ品質チェックを実行して、何かが間違っている場合を探すのがとても簡単です。レポートツールや分析ツールに意味のある値を表示できるため、必要に応じて完全にデータが取り込まれていない行をフィルタリングしたり、データ管理者がこれらのツールを使用して問題のあるデータを探すことができます。または、次元の1つが適用されない行を具体的に探したいと思うかもしれません。

データが「間違った」順序でロードされることがある(つまり、ファクト表にデータが取り込まれたが、関連するディメンション・メンバーにディメンションがまだ追加されていない)場合は、これを使用して行をチェックすることもできますあなたのETLで更新が必要で、問題を修正するのを自動化する必要があります。それらは常にNULLを持つため、更新が必要ない行を繰り返し更新する必要はありません。

他の誰かがこのデータマートのサポートを引き継ぐときに、その行の下に、NULLまたは-1が問題を示しているかどうかにかかわらず、膨大な時間を費やす必要がないときは本当に感謝します。

関連する問題