コンフォームド・ディメンション(Conformed Dimensions)
当記事は、複数スタースキーマ の内容を理解している前提で記事を書いています。
Conformed Dimensions
プロセスを横断した分析は非常に強力である。特定のプロセスに焦点を当てた分析では、別々のファクトファクトテーブルが必要で、横断した分析では、ドリルアクロスを用いる。これが上手くいくかはディメンションの設計に左右される。
今回紹介するConformed Dimensionsを使えば、異なるファクトテーブルを比較可能になる。逆に失敗したディメンション設計の場合、ファクトの比較が難しいまたは不可能になる。
ディメンションとドリルアクロス
プロセス間の情報をまとめるためには、ディメンションが不可欠で、失敗するほとんど理由が、ディメンションの構造や値が異なる場合である。
失敗したディメンション
プロセスを跨いだ分析に失敗する例を見てみよう。プロセス間を比較する時は、最初に各ファクトテーブルを共通のディメンションで集約する。その次に、それらの結果をマージする。この時に使用するディメンションが非互換であった場合に混乱が生じる。
図1
dimensionについている_2は、ツールの都合上つけているが、それぞれ独立したテーブルとして見てほしい。
以下は、dimension_productsとdimension_products_2の内容である。
dimension_products
| product_key | product_id | product_name | category |
|---|---|---|---|
| 1110 | 1111-01 | Cable, A | Cable |
| 1135 | 2222-01 | Cable, B | Cable |
| 1233 | 3333-01 | IcCard | Card |
| 1311 | 4444-22 | Box, A | Box |
| 1400 | 5555-22 | Box, B | Box |
| 1578 | 6666-22 | Box, C | Box |
dimension_products_2
| product_key | product_id | product | prod_cat | type |
|---|---|---|---|---|
| 1110 | 1111-01 | CABLEA | CABLE | C |
| 1135 | 2222-01 | CABLEB | CABLE | C |
| 1233 | 3333-01 | STANDARD CARD | CARD | C |
| 1311 | 4444-22 | BOX | BOX | A |
| 1388 | 4444-22 | BOXA | BOX | A |
| 1422 | 5555-22 | BOXB | BOX | A |
図1のスタースキーマは、注文(fact_orders)と返品(fact_returns)の2つプロセスを表している。それぞれ注文スター、返品スターと呼ぶ。
それぞれ別々の部門で実装されたもので、物理的に独立したデータベースに存在している。両方のデータベースに、ディメンションテーブルの日(dimension_days)、顧客(dimension_customers)、製品(dimension_products)がある。これらのスタースキーマを比較したいケースはあるとする。例えば、特定期間の製品別の注文に対する返品率などである。これはドリルアクロスを使えば実現可能である。以下が手順である。
- 各ファクト・テーブルを製品ごとに集約する。
- 集約した結果をマージし、注文された数量と返却された数量の比率が計算する。
図1の製品ディメンションを使えば、同様の手順で他のディメンション属性で分析可能だが、残念ながらこのディメンションでは、ドリルアクロスはうまくいかないだろう。何故なら、製品ディメンションは構造的に違う上に、値が違うからである。
ディメンション構造が違う
2つの製品ディメンションには多くの違いが存在する。どういう違いがあるか見てみよう。
- 返品スターの製品ディメンジョンにはタイプ(
type)が含まれているが、注文スターの製品ディメンジョンには存在していない。当たり前だがタイプによる比較は不可能になる。 - スターごとにカラム名が違う。例えば、商品名が入るカラムが、注文スターでは
product_name、返品スターではproduct。カテゴリも同様のことが起きている。これらの違いは、ドリルアクロス手順を複雑にする。
この程度の違いであれば、俗に言う強い人なら、いい感じに回避してしまうだろう。足りない属性はクエリで解決したり、カラム名の違いを吸収したり、しかし待ってほしい。それは悪手だと断言する。
- 強い人以外、この回避策が使えないかもしれない。
- 回避策に一貫性がないため、似たようなレポートでも数値がズレる。
- BIツールでそのまま使えない様なデータ構造になる。
また、簡単なクエリで解決出来ないこともあるだろう。例えば、あるスターが月単位で集計しているが、他のスターが週単位で集計している場合などである。クエリによる回避策はディメンションに一定の一貫性があるかに依存している。
ディメンションの値が違う
実はまだ製品ディメンションには、以下のような問題がある。
- 商品名とカテゴリのフォーマットが異なっている。注文スターは大文字と小文字が混在し、読点で区切られている。返品スターはすべての大文字になっている。マージ時に値をどちらかのフォーマットに合わせる必要がある。
-
product_id3333-01の製品は、それぞれで名前が異なっている。同じ製品であっても、内容が異なっていると結合の条件に使えない。 -
product_id4444-22の製品は、注文スターに1行あるが、返品スターには2行ある。これはデータの保持方法が違うこによって発生している。どちらを使うべきか都度判断する必要がある。 -
product_id6666-22の製品は注文スターにはあるが、返品スターにはない。この程度の場合は、ドリルアクロスの障害にはならないが、このような欠損は不整合が起きるの兆候である。 -
product_id5555-22の製品は、それぞれで異なるサロゲートキーが割り当てられています。テーブルを結合する際には注意が必要になる。
上記の問題をクエリで解決するのは、非常に辛い。出来たとしてもボイラープレートなクエリが毎回必要になる。特に重要なのが、クエリを書く人によって結果が異なる可能性があることである。一貫性がない結果は混乱の元になる。
Conformed Dimensionに必要な要件
ドリルアクロスをしたい場合、図1のような非互換なディメンションを回避する必要がある。つまり、互換性のあるディメンションテーブルを用意すれば良い。具体的に言うと、構造が同じ、値が同じにする。
同一テーブルである必要はない
図1のテーブル設計を使える状態にするには、構造と値が同じ製品ディメンションを用意する必要がある。ちなみに、ディメンションテーブルは完全に同一ではなくも良い場合もある。これはディメンションテーブルが異なる粒度で保持されている場合に見かけることがある。例えば、注文管理している会社が、販売計画にある目標を記録しているとする。販売目標は、月ごとに販売地域別に決められていて、計画には様々なバージョンが存在している。図2にテーブル構成を示す。
図2
注文スター(fact_orders)と販売目標スター(fact_sale_goals)は、図1の注文スターと返品スターの例とは違って、ファクトテーブルの粒度が異なっている上に、共通のディメンションテーブルが存在しない。だが、これらはいくつかの共通ディメンションを持っている。
例えば、dimension_daysとdimension_monthsのmonth_numberは同じディメンションである。他にもdimension_sales_repsとdimension_territoriesのterritory_nameも同じである。ここから分かることは、注文スターと販売目標スターは、月(month_number)ごとや販売地域(territory_name)ごとの比較が可能であるということである。
物理的に同じテーブルでなくても、同じことを指しているディメンションがあるなら、ドリルアクロスは可能である。
ディメンションの月(month_number)と販売地域(territory_name)を使って、プロセス間分析する例を示す。
注文スターの注文金額(order_yens)を集計する。
| month_number | territory_name | order_yens |
|---|---|---|
| 1 | East | 125000 |
| 1 | West | 200000 |
| 2 | East | 200000 |
| 2 | West | 150000 |
販売目標スターの目標金額(goal_yens)を集計する。
| month_number | territory_name | goal_yens |
|---|---|---|
| 1 | East | 150000 |
| 1 | West | 150000 |
| 2 | East | 150000 |
| 2 | West | 150000 |
次に結果をマージし、目標に対しての達成度(percent_goal)を計算する。
| month_number | territory_name | order_yens | goal_yens | percent_goal |
|---|---|---|---|---|
| 1 | East | 125000 | 150000 | 83% |
| 1 | West | 200000 | 150000 | 133% |
| 2 | East | 200000 | 150000 | 133% |
| 2 | West | 150000 | 150000 | 100% |
ディメンションテーブルでドリルアクロスに必要な互換性を持っている場合、それはConformed Dimensionである。
Conformed Dimensionの設計パターン
Conformed Dimensionには、いくつかの設計がある。今回は、よくある2つの設計について紹介する。
その他の設計。
- Conforming Degenerate Dimensions
- Overlapping Dimensions
Shared Dimension
Conformed Dimensionで一番シンプルな設計は、複数のスタースキーマが、論理的または物理的に同じテーブルを共有しているShared Dimensionである。このディメンションには以下のような特徴がある。
- 同じ構造を共有している。
- 同じ値を共有している。
複数スタースキーマ に具体的な例があるため、気になる人は是非読んでほしい。
Conformed Rollups
同一のディメンションテーブルでなくても、以下の条件を満たしていれば、ドリルアクロスは可能である。
- あるテーブルのディメンジョン属性(Base Dimension)が、他のテーブルのディメンジョン属性のサブセット(Dimension Rollup)になっている。
- 共通のディメンジョン属性が、同じ構造と値を共有している。
上記2つの条件を満たすと、関連しているファクトテーブルは、共有ディメンション属性を使ってドリルアクロスが可能である。
図3
図3に具体的なディメンションテーブルの例を示した。2つのディメンションのうち、詳細度が高いものをBase Dimensionと呼び、詳細度が低いものConformed Rollupと呼ぶ。赤枠で囲ったディメンション属性は、同じディメンションを指している。
まとめ
Conformed Dimensionを使用すると、プロセスを跨いだ分析を可能にする。逆にディメンションの設計を誤ると、制限された範囲の分析しか出来ないだろう。ディメンションの出来が分析幅を決めるため、慎重に設計する必要がある。
参考文献
以下の本を参考に、私なりの理解を書いたものになります。ちゃんと理解を深めたい方は、自分で読むことをおすすめします。
Star Schema: The Complete Reference
Discussion