この記事は、前回書いたデータモデリングの９つのことの６つ目です。
crmprogrammer38.hatenablog.com
ファクトテーブルは、DWHでは一番件数が多くなるテーブルなので、1レコードで数バイトの違いが、最終的に数ギガバイトの違いになって現れてきます。
なので、必要最低限の項目、限りなくサイズを小さくできる型でデータを保持するように設計します。
業務システムでよくある項目の、レコード作成日、レコード更新日、レコード作成者、レコード更新者などよくある項目は不要項目の筆頭です。
※でも、ディメンションと１：Nで結合するためにあえて冗長に持っている項目は必要です。
後、その時点の情報が必要という業務要件を満たすために、ファクトにその時点のマスタ属性を持つのも極力さけたいところです。ディメンション側で履歴管理を検討します。履歴管理する場合はファクトの項目に基準となる日付項目が必要です。
もちろん業務要件を満たすことが一番なので、無理やりファクトの項目を少なく・小さくする必要はありませんが、業務要件を満たすことができるなら、どんどんファクトの項目を少なく・小さくしていきましょう！
