DB Stories

DBに関する過去、現在、未来の話題をプロフェッショナルの視点で紹介

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

横断分析とディメンションテーブルの関係

業務プロセスを横断して分析をする際の重要な要素となるのがディメンションテーブルです。ディメンションテーブルのデータ保持方法や内容が異なる場合に横断分析が出来なくなることで、お互いのデータによるシナジーが失われることになります。横断分析を行うためにディメンションテーブルの内容が全く同一である必要はありません。二つのディメンションテーブルの内容がサブセット(準拠した内容)となっていても横断分析は実行可能です。

失敗の原因は何か

ファクトテーブルの比較(すなわち横断分析)においてディメンションテーブルのデータ内容が中心的な役割を果たします。横断分析は次のような手順で行われます。フェーズ1:ディメンションテーブルはファクトテーブルの集約レベルを定義し集計が行われます。フェーズ2:それぞれのクエリー結果をマージします。この時、ディメンションテーブルの不整合がある場合に分析出来ないという結果をもたらします。その時の問題について以下の図で説明します。

f:id:good-value:20180228222713j:plain

この図は受注(order)と返品(retuen)という2つの業務プロセスを示しています。それぞれについて別の部署にて別のデータベースに保存されています。単独であればこれらのスタースキーマより適切な分析結果を得ることが可能です。この2つは「日(day)」「顧客(customer)」「商品(product)」というディメンションテーブルが含まれています。ディメンションテーブルに共通性があることからこの2つは横断分析可能であると期待できます。例えば、ある期間における商品別の受注と返品の割合を取得したい場合、以下の2段階で実施することになります。

  • クエリはそれぞれのファクトテーブルに対して実施して中間結果を生成する。
  • 中間結果は共通の商品名(product name)でマージし、受注数(quantity ordered)と返品数(quantity returned)を計算する。

同様方法で別のディメンション項目である商品カテゴリ、や別のディメンションテーブルである日付(day)、顧客(customer)、販売担当(salesperson)についても実施することになります。

残念ながら、この手法にて商品分析する際に問題が発生します。商品(product)テーブルの構造と内容が異なるためです。

ディメンションテーブルの構成の違い

図における二つの商品ディメンションテーブルについての違いが横断検索を妨げることになります。まず初めにディメンションテーブルの構成の違いについてです。

  • 返品(retuen)スタースキーマの商品ディメンションテーブルには「タイプ(type)」属性が存在してますが、受注(order)スタースキーマには存在していません。そのため受注と返品の商品タイプによる比較ができません。
  • 同一の項目を定義している列について異なる名前で定義されています。例えば、商品名項目について受注スタースキーマにおいてはproductで返品スタースキーマにおいてはprod_nameとなっています。同様のことは商品カテゴリについても言えます。これらの違いが横断検索の運用にも影響してきます。

これらの対応として、経験のある開発者は一時的な回避策(work around)で対応するという選択肢も取れないことはありません。商品タイプは受注スタースキーマの商品ディメンションには存在しないのですが、返品スタースキーマの商品ディメンションから取得することはできなくもありません。業務キーであるSKUを利用してテーブル結合を利用するという方法が考えれらます。これにより受注データについて商品カテゴリーによる集約が可能になります。

同様に、商品カテゴリーで分析する際にカラム名の違い(受注スターのproduct.categoryと返品スターのproduct.prod_catについても一時的な対応をすることも可能です。しかしながらこの種の一時的な回避がまさに「ゆでがえる(boining the frog)」につながることになります。設計時の考慮不足を分析実行時に強引に回避することで単純に考えればよいことが複雑なものになってしまいます。この種の運用回避と呼ばれるものが以下のような複雑な運用を生むことになります。

  • 横断検索を行うにあたっての特殊な知識が必要となる。
  • 運用回避策を知っている経験者だけが分析を行うことができる。
  • この運用回避策を間違うと正しくない結果を取得してしまう。
  • BIなどによる検索結果の自動作成という対応を妨げることになる。

この手のすべての構造上の欠陥(互換性)が一時的な回避策で対応できるわけではありません。二つのスタースキーマが異なる商品定義であった場合は非常に困難なものとなります。データを取り入れるタイミングについても重要となります。もし片方のスタースキーマデータが月次で収集していて、もう片方が週次による収集だとした場合、実質的にこの2つを比較することはできません。週次と月次の違いにより共通的な比較を行うための集計ができないことになります。

これらの回避策は二つ存在しているディメンションのデータ内容が整合性がとられていることを前提としています。もしデータの内容そのものに違いがある場合この構造上の欠陥のための回避策による対応をとることが不可能になります。

(つづく)