ディメンションテーブルの整合性(conformed dimensions) (5)

同一のディメンションテーブルである必要はない

前回の受注と返品の例において、商品ディメンションテーブルが「同一の構造」「同一の内容」であったとしてもまだ問題が残っています。ディメンションテーブルが完全に同一でないとき、データ互換性の程度を表します。つまりディメンションテーブルにデータ粒度の違いがあるときに問題となります。

ある会社における、販売計画で管理されている販売目標(sales goal)aと受注を比較する場合を例にとります。販売目標は販売計画のバージョン（計画立案の単位）ごとに「月」と「販売地区」であらわされます。この時のスタースキーマを以下に示します。受注と返品の例と異なり、ここに登場するファクトテーブルは共通のディメンションは持たず、データ粒度が異なっています。

これらの違いがあるにもかかわらず、このスタースキーマは共通のディメンション「属性(attributes)」を持っています。共通のディメンション項目は図でハイライトされています。例えば、販売目標は月ごとのデータを「月(month）」ディメンションとしてデータを保持しています。受注テーブルは月ごとのデータを「日(day)」ディメンションで保持しています。これにより二つのデータを月ごとに集計を行い比較することが可能です。

実際のところ、「月」ディメンションの属性は「日」ディメンションテーブルでも表すことが可能です。この共通のディメンションにより受注と販売目標を集計して（横断検索のPhase1）、それぞれの結果を集約（横断検索Phase2)することが可能です。同様に、地区(territory)ディメンションの属性は販売員(salesrep)ディメンションの属性と同一です。業務横断検索においては、これらの共通のディメンション属性を利用するのが基本となります。以下の図は具体例を示しています。

上図における最終結果では、月と地区ごとの受注と販売目標を比較しています。ここでは今まで説明してきた2フェーズの横断検索が実施されています。Phase1において、それぞれのスタースキーマから共通の次元（「月」と「地区」）ごとに別々の問い合わせを実施しています。Phase2において、この中間結果をマージして2つの結果の割合を計算しています。この過程において、2つのスタースキーマで共通のディメンションテーブルがなくても横断検索が実施可能なことを示しています。

続く