ディメンションテーブルの整合性(conformed dimensions) (7)
ディメンションの重複関係による整合性(conformed rollups)
ディメンションテーブルの整合性は、テーブルの共有以外によっても担保することができます。以下の条件を持っている場合は、実体として別のテーブルであっても整合性を確保することが可能です。
- 片方のディメンションテーブル属性がもう片方のディメンションテーブルのサブセット（準拠関係）である場合
- 共通のディメンション項目が同一定義でデータが同一であること
これらの条件を満たす場合、これらのディメンションテーブルは整合性が保たれている（準拠している）ことになり、スタースキーマ間の業務横断検索が可能となります。これらの2つのディメンションのうち小さい（包含される）方を整合性のある重複(conformed rollup)以降、準拠しているロールアップ
とよび、大きい（包含する）方を基本ディメンション(base dimension)と呼びます。
前回説明した上図において、「月(month)」と「地区(territory)」テーブルは「日(day)」「販売員(salesrep)」の整合性のあるロールアップになっています。「月」テーブルのすべての項目は「日」に存在し、「地区」テーブルのすべての項目は「販売員」に存在しています。整合性のある包含は基本ディメンションに存在しない1つのカラム、つまりサロゲートキーを持ちます。
ディメンション属性の共有についてはデータ内容についてさらに精査が必要となります。まず、同じ方法で登録されたデータであることが重要です。
この図において、月に関する情報は「日(day)」「月(month)」ディメンションテーブルに存在していて、"January", "February"と整合性のある状態で保持されています。また、地域に関する情報は「販売員(salesrep)」「地域(territory)」に"North", "South"という形で整合性が保たれています。これらの整合性により業務横断検索のPhase2においてデータのマージが可能になっています。
この共通項目に存在するデータの組み合わせについても同一であることが必要となります。例えば、日(day)テーブルに「monthにJanuary」「yearに2009」をもつ場合、月(month)テーブルにおいても同じ組み合わせのデータを持つ必要があります。そうでなければ、検索の組み合わせを作成するクエリー(Browse query)によって、同一データを作成することができないことになります。
この整合性のあるロールアップ(conformed rollup)を保証するベストな方法は、この基本ディメンション項目作成の流れでrollupデータを作成してしまうことです。これにより、ソースデータに基づくデータの作成が保証されます。開発者は基本ディメンション作成処理を先に確認して、新規行もしくは変更のあった行についてrollupデータについての確認を行います。もしくは、ソースデータでの変更から一連の流れとしてbaseとrollupの作成までを同時に実施してしまうことです。 some開発者は正規化データを保持するステージングエリアデータを使うことでデータ変更を検知した後に、基本ディメンションとロールアップへの適用を行います。
ETL開発者は整合性のあるロールアップについての副作用を見つけることがあります。type1アプリケーションの変更において、複数の行データをロールアップディメンションにマージすることが必要となります。この問題については、すでにあるファクトテーブルのレコードから参照されるサロゲートキーを持つ行が統合（マージ）することになるため、ファクトテーブルのサロゲートキー項目（ディメンションへの外部参照キー）の更新が必要となります。この種の処理を避けるために、準拠したロールアップとするために、サロゲートキーは別のものではあるが同一属性の行を複数保持することを許容させます。
ディメンションテーブルの整合性(conformed dimensions) (6)
ディメンションの整合性(準拠性)
ディメンションテーブルが横断検索が可能な条件を持っている場合、整合性があるディメンションといいます。（conformedをあえて、「整合性」と表しています）同一のディメンションを利用している場合は当然、整合性があることになりますが、それ以外においても整合性を持つことは可能です。ファクトテーブルと整合性のあるディメンションの関係は、将来の拡張実装で使用できるように整理しておく必要があります。
ディメンション整合性のタイプ
ここでは横断検索を可能にするか、妨げるかというディメンションテーブルの整合性について分類分けを行います。これまで見てきたようにディメンションテーブルの整合性にはいくつかのパターンがあります。今まで、「ディメンションの共有」「集約単位に整合性がある」という2つのパターンについて見てきました。ディメンションの非正規化(degenerate)もまた整合性のパターンです。「オーバーラッピングディメンション」と呼ばれる4つ目のパターンについては、あまり一般的ではありません。
ディメンションテーブルの共有
もっとも一般的なディメンションの整合性は二つのスターが同一のディメンションテーブルを利用することです。このディメンションの共有は「同一のテーブルを利用する」もしくは「二つ以上の同一構成のテーブルを利用する」というものがあります。2つ以上のテーブルを利用した実装の場合、ディメンションの共有は以下に従う必要があります。 * テーブルは同一の構成であること * テーブル内のデータ内容が同一であること
複数のディメンションがこれらの特徴を持っている場合、テーブルは整合性があるといえます。このタイプについてはすでに見てきています。
この受注と出荷の例において、「日」「商品」「顧客」ディメンションが共有されています。これまで見てきたように、これらのスタースキーマは同一のデータベースに存在する必要はなく、さらには別ベンダーのデータベースに存在していても問題はありません。ディメンションテーブルの構造とデータ内容が同一である限り受注と出荷の比較が可能です。
このディメンションテーブルが物理的に別のテーブルにある場合、ソースデータからのデータ取り込みについて、一つのETLプロセスで実施する必要があります。マスターとなるディメンションテーブルを最初に更新して、別の場所にあるディメンションにレプリケーションを行います。このレプリケーション（複製）手法をとることで、データの同期の手間を省き、分析の際に正確なデータであることを保証します。ただし、巨大なテーブルについては現実的ではありません。この場合、ETLプロセスは行の変更を判断し、更新キーを判断して各レプリケーションに反映を行う必要があります。
レプリケーションが別々に実施された場合、二つのディメンションのバージョンが同一であることを保証するのが難しくなります。それぞれのディメンションはソースデータから緩やかに変化するディメンション(Slowly Changing Dimensions) ルールに従い、同一の行データを持つ必要があります。データの比較を可能とするために同一のキー値を持つことも重要です。これまでに見てきたように、データのルールがバラバラの場合はデータの非互換につながります。
個別のデータロードプロセスは開発者にこれらの原則が必要であるという統制が難しくなり、片方に含む行がもう片方に含まれない状況や、同一のキー値をもたないということにつながります。それによりデータ分析における障害となります。不正確な複製データによりデータ分析が不正確なものとなります。データウェアハウスが不正確なデータを提供するとなると、誰も使わないものとなってしまいます。
次回は包含関係にあるディメンションテーブルについてです。 （続く）
ディメンションテーブルの整合性(conformed dimensions) (5)
同一のディメンションテーブルである必要はない
前回の受注と返品の例において、商品ディメンションテーブルが「同一の構造」「同一の内容」であったとしてもまだ問題が残っています。ディメンションテーブルが完全に同一でないとき、データ互換性の程度を表します。つまりディメンションテーブルにデータ粒度の違いがあるときに問題となります。
ある会社における、販売計画で管理されている販売目標(sales goal)aと受注を比較する場合を例にとります。販売目標は販売計画のバージョン（計画立案の単位）ごとに「月」と「販売地区」であらわされます。この時のスタースキーマを以下に示します。受注と返品の例と異なり、ここに登場するファクトテーブルは共通のディメンションは持たず、データ粒度が異なっています。
これらの違いがあるにもかかわらず、このスタースキーマは共通のディメンション「属性(attributes)」を持っています。共通のディメンション項目は図でハイライトされています。例えば、販売目標は月ごとのデータを「月(month）」ディメンションとしてデータを保持しています。受注テーブルは月ごとのデータを「日(day)」ディメンションで保持しています。これにより二つのデータを月ごとに集計を行い比較することが可能です。
実際のところ、「月」ディメンションの属性は「日」ディメンションテーブルでも表すことが可能です。この共通のディメンションにより受注と販売目標を集計して（横断検索のPhase1）、それぞれの結果を集約（横断検索Phase2)することが可能です。同様に、地区(territory)ディメンションの属性は販売員(salesrep)ディメンションの属性と同一です。業務横断検索においては、これらの共通のディメンション属性を利用するのが基本となります。以下の図は具体例を示しています。
上図における最終結果では、月と地区ごとの受注と販売目標を比較しています。ここでは今まで説明してきた2フェーズの横断検索が実施されています。Phase1において、それぞれのスタースキーマから共通の次元（「月」と「地区」）ごとに別々の問い合わせを実施しています。Phase2において、この中間結果をマージして2つの結果の割合を計算しています。この過程において、2つのスタースキーマで共通のディメンションテーブルがなくても横断検索が実施可能なことを示しています。
続く
ディメンションテーブルの整合性(conformed dimensions) (4)
ディメンションテーブルのデータの違い
前回も紹介した図において、商品テーブルのデータそのものについても違いからくる問題点が存在しています。
- データフォーマットの違い(商品名と分類) 受注(order)スターの商品(prduct)についての商品名(product name)と分類(category)については大文字小文字が混在しています。返品(retuen)スターの商品テーブルについては大文字に統一されています。また、区切り(カンマ)の扱い方も異なります。これらの違いは横断検索時にこれらの値を利用したマージ段階で問題となります。横断検索フェーズ2
- 商品名について統一されていない。"SKU 3333-01"は受注スターにおいては"9 x 12 bubble mailer"であり、返品スターにおいては"STANDARD MAILER"になっています。商品名の変更についてTYPE 1変更によるデータの上書きが受注スターにおいて実施されており、返品スターにおいては無視（実施されていない）されていることが推測されます。この名称の不一致は商品名を含む検索結果をマージするタイミングで問題となることになります。
- 受注スターにおける商品テーブルのナチュラルキー(SKU)"4444-22"は１行ですが、返品スターでは２行該当しています。このことは、受注スターで商品分類(category)の変更はTYPE1変更（つまり上書き）で実施されており、返品スターではTYPE2変更による新規レコード追加で実施されたと推測できます。
- "SKU 6666-22"について、受注スターには存在していますが、返品スターには含まれていません。これは横断検索で問題となることはないのですが、この２つのスター間におけるデータ管理の違いがあることを示唆しています。
- "SKU 5555-22"について２つのスターにサロゲートキーの違いが存在しています。これについての配慮がテーブル結合時に必要です。
繰り返しますが、上記のようなデータ上の制限のいくつかは暫定的な対応により回避することが可能ですが、レポート処理（つまり集計処理）における違いについては回避することができません。例えば、１つ目の違い（大文字小文字/カンマの扱い)については、集計時に文字の変換（大文字に統一、カンマを取り除く）を行うことで対応可能です、データの集約前にこれらの変換処理を行うため性能上においても不利なものとなります。しかしながら"SKU 333-01"といったように商品名が違う場合については対応することができません。
これらのスター間のディメンションテーブルのデータ内容が違うという制約については、それぞれのスターに対して検索を行い、一方のスターのディメンションテーブルの値を「正」としてディメンションの値を決定させます。これをそれぞのスターの集約結果をマージするタイミングで実施することになります。繰り返しになりますがこの対応についてもパフォーマンスに影響を与えます。またレポート作成におけるこの手の対応については経験豊富な技術者の対応が必要となることからBIツールによるクイックな横断検索の実装といったことを妨げることになります。さらにこの手法についても、片方のスターのディメンションテーブルから特定商品のデータが欠落していたり、複数のレコードが存在する場合においては対応することができません。
ここまで説明してきたような一時的な対応についてデータ利用という点で妨げになることは間違いありません。
- 受注と返品の商品データが異なる場合にどのように比較すればよいのか。
- レポート作成上どちらの商品名を利用するのが正しいのか。
- 比較にあたってもう片方ではどのような商品名が使われているのか。
2,3については直接的には横断検索に影響は与えないのですが、２つのスターの分析をするにあたって該当の商品がもう片方のスターと誤って関連付けてしまうことによる誤りが発生する可能性が残ります。
データ整合性(データ準拠)の前提条件
横断検索（二つのスターのデータ比較）を行うにあたって、設計では先ほどの図にあったような不整合を避ける必要があります。 この二つの商品ディメンションテーブルの不整合という問題は、二つのテーブルを同一のものとして扱うことによって対応することができます。データの整合性を考えるにあたって「構造(テーブル定義)」「データ内容」という２つの前提が存在します。
同一の構造
構造とはディメンションテーブルにて同一の列定義（つまりテーブル定義）を持つことを意味します。このことは、別スターのデータを集約する際の欠落を防ぐことになります。（図でいうところの返品(retuen)商品ディメンションの商品タイプ(type)が該当します）この同一定義とした列は、同一の項目データであることを明確に示すよう名称も同一である必要があります。また、データ内容が同一であることを意味するようデータ型につても同一にする必要があります。
これらの構造の同一性は業務横断検索のフェーズ1で関連します。ディメンションテーブルの列はファクトテーブルの集約方法（集約単位）に依存します。業務横断検索のフェーズ1ではファクトテーブルの検索はディメンション項目についてここで紹介した「データ整合性のための個別対応」を行ことなしに検索を実施できます。しかし、フェーズ2検索におけるデータのマージにを行う際に（データの同一性も需要ではあるのですが）構造の同一性が役に立ちます。
同一のデータ内容
データの内容についてもディメンションテーブルの列定義は同一である必要があります。商品名の定義(SKU 3333-01)において、受注スターの定義が「9 x 12 bubble mailer」であれば返品スターにおいても「9 x 12 bubble mailer」である必要があります。このデータの同一性は２つのスターの検索結果（中間結果）を結合してマージを行う業務横断検索のフェーズ2にて有用となります。同一のデータが利用されていると、不要データの除去やデータの変換の実行が不要になるため、中間結果のマージ処理が容易になります。
テーブル構造に同一性がある場合データ取得時方法順番を入れ替えたとしても問題がなくなります。ディメンションテーブルのデータ同一性という観点でいうと、「同一のサロゲートキーで識別される列の集合を保持」して、「同一の緩やかな変更ルールを持つ」ということになります。これらの要件があったとしても、ディメンションテーブルのデータ粒度の違いがある場合はさらに問題が残ることになります。
（つづく）
ディメンションテーブルの整合性(conformed dimensions) (3)
横断分析とディメンションテーブルの関係
業務プロセスを横断して分析をする際の重要な要素となるのがディメンションテーブルです。ディメンションテーブルのデータ保持方法や内容が異なる場合に横断分析が出来なくなることで、お互いのデータによるシナジーが失われることになります。横断分析を行うためにディメンションテーブルの内容が全く同一である必要はありません。二つのディメンションテーブルの内容がサブセット（準拠した内容）となっていても横断分析は実行可能です。
失敗の原因は何か
ファクトテーブルの比較（すなわち横断分析）においてディメンションテーブルのデータ内容が中心的な役割を果たします。横断分析は次のような手順で行われます。フェーズ１：ディメンションテーブルはファクトテーブルの集約レベルを定義し集計が行われます。フェーズ2：それぞれのクエリー結果をマージします。この時、ディメンションテーブルの不整合がある場合に分析出来ないという結果をもたらします。その時の問題について以下の図で説明します。
この図は受注(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などによる検索結果の自動作成という対応を妨げることになる。
この手のすべての構造上の欠陥（互換性）が一時的な回避策で対応できるわけではありません。二つのスタースキーマが異なる商品定義であった場合は非常に困難なものとなります。データを取り入れるタイミングについても重要となります。もし片方のスタースキーマデータが月次で収集していて、もう片方が週次による収集だとした場合、実質的にこの２つを比較することはできません。週次と月次の違いにより共通的な比較を行うための集計ができないことになります。
これらの回避策は二つ存在しているディメンションのデータ内容が整合性がとられていることを前提としています。もしデータの内容そのものに違いがある場合この構造上の欠陥のための回避策による対応をとることが不可能になります。
（つづく）
ディメンションテーブルの整合性(conformed dimensions) (2)
複数のススタースキーマがもたらす効果
多次元データモデルは個別に作成されることがほとんどです。どのデータウェアハウスアーキテクチャにおいても、全社レベルのデータを完全に考慮(包含)した一つのデータセットを用意するというプロジェクトとは非現実的なものです。現実のプロジェクトスコープは全社レベルから目的別レベルの部分を範囲とする例がほとんどです。
新しいスタースキーマが作成されるにつれて、その企業にとってデータ分析上のメリットが2つあります。一つ目は （当たり前ですが）そのスタースキーマを利用して業務分析が可能となることです。当事者として、責任者として、また興味がある者として業務活動による数値を見ることが可能になります。例えば「販売/売上」データについては全従業員が関心を持つデータでもあります。
2つ目の利点については初めから意識する場合もありますが必ずしもそうでない場合もあります。作成したスタースキーマは新しい業務プロセス分析を可能とするだけでなく、ほかのプロセスとの比較を可能にするということです。つまり、関係者だけでなくより上位層（経営層）にとっての分析が可能となります。 以前紹介した下の図において、営業活動、営業提案、受注、配送といった多くのプロセセスを比較しています。このような業務プロセスを分析を組み合わせたレポートは営業責任者、経営層、投資家にとっても有用な情報です。
またこのレポートでは成約率（営業活動と注文実績の比率）が示されています。この数値も特定の担当者にとっては重要な数値(KPI)ですが、プロセス横断検索をすることでようやく取得できる数値です。スタースキーマの設計者は業務プロセス間で求める値（例えば先ほどの成約率）について明文化しておく必要があります。この数値はテーブルに値を持っているわけではないので、ドキュメント化されていないと容易に失ってしまうからです。
すべての業務は他の業務とリンクすることで行われていて、例えば商品開発や買収、顧客基盤の買収、収益を合わせて積み上げといったことから始まる場合もあります。この種のリンクはミクロ/マクロレベル双方において存在します。例えば販売といった目的別データにおいても先ほどの図のように複数の業務が連携しています。販売はマクロレベルにおいても商品開発、販売促進、顧客サポート、会計といった連携も存在します。
そのぞれの業務プロセスを表すスタースキーマは共通ディメンションによってお互いが連携（関連付け）されます。これを表現しているのが以下の図です。
受注、発送などの各種スタースキーマが一連のディメンションによって関連付けられています。図の中心にあるこれらのディメンションが業務プロセス間の分析をフレームワークのように機能します。同一ディメンションによって連結された2つのファクトテーブルは前回紹介した横断分析手法によって比較分析することが理論的に可能となります。
論理的モデルにおいて、複数のスタースキーマが共通のディメンションを利用する場合のディメンションを整合性のあるディメンション(conformed dimensions)と呼びます。前回提示したようにディメンションテーブルは物理的に同一である必要はありません。物理的に分離していたとしても、整合性が取れているのであれば業務横断分析は可能です。
ディメンションが整合性をとれていない場合、データ分析としての短期の目的は満たすことができますが、長期的な視点では足かせとなります。受注と出荷のスタースキーマの例において、別々に導入した場合の例を考えてみます。それぞれのシステムが稼働を迎えた後、そのデータの分析を行いたい関係者が増えていくことを意味します。そしてこの2つのシステム実装が別々に行われているという事実はデータ分析実装を行うデータウェアハウスチームにも影響していくことになります。もしそれぞれのスタースキーマが顧客、製品についての共通の情報を利用していなければ、データ分析としては個別最適化というレベルにとどまることになります。つまり、受注や出荷の分析はできたとしても、その2つの比較はできないという事態となることになります。単なる機会損失だけならまだ良いほうで最悪はデータ分析基盤(analytic infrastructure)そのものに対する不信につながることになります。
次回以降説明していきますが、ディメンションの整合性については様々な方法が存在します。この整合性は先ほどの図のようなER図によって表現されることになりますが、このような図による表現は次第に作成とそれを理解をするのが難しいものになってしまいます。この整合性に対する基本的な概念についてはもっと別の方法で表現をおこないます。
データ利用の長期視点の成功を考えたときに、ディメンションの整合性(conforming dimensions)は多次元データモデルを利用するどのデータウェアハウスアーキテクチャであっても重要な要素となります。整合性を保つ方法やその実装についての具体的な話をする前に、業務横断検索でどうなっていれば利用可能となるのかという点と、ディメンションの整合性がどのように個別対応ではなく横断検索をもたらすなるかというのを見ていきます。
次回は業務横断分析におけるディメンションの役割についてです。 （つづく）
ディメンションテーブルの整合性(conformed dimensions) (1)
業務プロセス（スタースキーマ）をまたがった分析というのは非常に有用なものといえます。このことは、エンタープライズ、目的別(subject area)データウェアハウスをまたがる検索についても同様です。前回まで業務プロセス（受注、出荷等のプロセス）を中心としてたデータ分析については業務プロセスごとのファクトテーブルが必要であり、業務プロセスをまたいだ分析（データの比較）は、それぞれの結果を組み合わせることで実行する必要があることを説明しました。この種の検索はプロセス横断検索(drilling across)と呼びますが、この時ディメンションテーブルの設計が非常に重要になります。
参考：
データウェアハウスアーキテクチャ(1) - DB Stories
データウェアハウスアーキテクチャ(2) - DB Stories
今回、このプロセス横断検索で重要となるディメンションテーブルの整合性(conformed dimension)について解説を行います。正しいディメンション設計とデータを利用すると、スタースキーマの横断検索だけでなく、エンタープライズデータベースと目的別データウェアハウス間の比較についても可能になります。ディメンションテーブルの整合性が取れていないとそれが実現できないことになり、不効率なstovepipe（サイロ型のデータモデル）になってしまいます。
ディメンションテーブルの整合性というのはルールの集合でもあります。このルールの設定を盲目的に暗記することもできますが、ディメンション設計を学ぶ上では「なぜ」という部分が当然ながら重要になります。「整合性」についての条件を挙げていく前に、ディメンションテーブルとスタースキーマ横断検索との関係について注目します。
ここでは「整合性(conformance)」は様々な面で使われる言葉ですが、今回はディメンションテーブルの整合性について説明を行います。
整合性のとれたディメンションテーブルはプロセス横断検索をより容易にし、企業における分析力の向上をもたらします。コーポレートインフォメーションファクトリ、多次元データウェアハウス、個別データマートといったデータベースモデルそれぞれについてこの整合性についてみていきます。
（つづく）
