スタースキーマ横断検索をSQLで一度に取得する場合

方式CはRDMSにおいて処理を実施し、さらに中間テーブルの利用をなくした方法です。この方式は標準的なSQLの新しい拡張機能によって実施可能となります。動作としては、一つのSQLですべてを実施することになります。

スタースキーマ横断検索SQLの実装としては、2つの検索結果の結合から構成されます。"COALESCE"もしくは"NVL関数"が値の集約に利用されます。例えば以下のようになります。

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

SQLとしては非常に入り組んで理解しにくい構成となっています。二つのインラインビューが存在していてordres_query, shipments_queryと別名がつけられています。この2つのクエリーがPhase1のスタースキーマ横断検索に相当するものです。このインラインビューを共通項目（ここではproduct）で結合しています。メインクエリーがPhase2処理に相当しています。

このSQLでは、DBAと議論の対象となる中間テーブル（一時的な表）が不要となっています。しかしながら、DBMSとしての処理負荷（オーバーヘッド）残っています。明示的に中間テーブルの作成、結合、削除といったことが行われていませんが、DBMS内部では同様の操作が行われています。アプリケーションがその対応を行う必要があるか無いかというのが違いです。

ツールでスタースキーマ横断検索が利用できない場合

レポーティングツールやBIツールにおいてスキーマ横断検索がサポートされていない場合がありますが、この場合の多くはキューブ(Cube)を利用することを前提としたツールといえます。（OLAPツールの多くは一つのキューブだけを同時するのが前提になっています）

レポート作成時に横断検索の利用が出来ない場合においても、対策はあります。つまり、横断検索の前に結果を新しいファクトテーブルやキューブに格納してしまうという方法です。そのファクトテーブルを利用して比較を実施します。元となるファクトテーブルは個々の業務での分析で利用します。

横断検索において受注と出荷の2つのプロセスを一つのファクトテーブルに格納した例を見てきました。この例において例えば受注だけの分析を行う場合、”０”の値により混乱を生じさせましたが、横断検索としては十分利用することが可能です。

[TIP] 利用するツールが横断検索をサポートしない場合や、レポート作成に性能的な問題を抱える場合、事前に分析粒度をそろえたサマリーテーブルを作成すること推奨します。データロード時に作成するなどでクエリー実行時に都度、検索が実行されることを防ぐことが可能です。

この横断検索用ファクトテーブルやサマリテーブルは業務固有のファクトテーブルを補完するものとなります。データロード時の追加作業が必要となりますが、検索実行時にめりとが発揮されます。仮にツールが横断検索をサポートする場合においてはパフォーマンス向上に寄与します。

このサマリ表は、トランザクションDBからの連携データではなく、業務固有のファクトテーブルをデータソースとして作成されます。このテーブルについて「サマリテーブル」「派生(derived)テーブル（注：訳が思いつかない…）」という呼び方をします。これ自体は多次元データモデルだけでなく、キューブにおいても利用されます。このことについては後程、紹介する予定です。

これまでのまとめ

本章では、多次元データモデル（スタースキーマ）における基本構成からさらに進めて、より複雑な（現実世界に近い）形の場合について解説してきました。

別々の業務プロセスのファクトテーブルはそれぞれで定義する。
二つの業務プロセスを別に扱うべきか判断に迷う場合、そのプロセスが異なるタイミングで発生するのか、扱う粒度が異なるのかというのを確認する。もし該当するのであれば別々の業務プロセスと判断できる。
別々の業務プロセスを同一のファクトテーブルで扱う場合、個別プロセスの分離時に問題が発生する。
複数のファクトテーブルのデータを比較する場合、直接結合や共通のディメンションを利用する場合、二重集計などの結果不正をもたらす。
スタースキーマを横断する検索を行う最も適切な方法は、2つのフェーズで実施することとなる。第1フェーズで、スターから同粒度でそれぞれのデータを別々に集約を実施する。第2フェーズで第1フェーズの結果のマージを行う。
スタースキーマ横断検索の方法は複数存在する。どの方法も利用ツールがサポートしていない場合、事前にサマリテーブルを作成しておくことで対応する。

ここで見てきたように、個別プロセス分析（一つのスタースキーマ分析）やプロセス横断分析（スタースキーマ横断分析）を自在に行うにはは多次元データモデルの適切な設計が必要となります。そのために、ディメンションテーブルの設計とその値の保持方法というのが重要になります。次回、ディメンション設計での重要な考え方となる「整合性のとれたディメンションテーブル(conformed dimensiton)」について解説を進める予定です。