DB Stories

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

ファクトテーブル(8)

スタースキーマ横断検索の実装

これまでに横断検索における考慮点について説明してきましたが、どのように実装していくかというのはまた別の視点が必要となります。自分でコードを実装する場合やBIツールによる自動検索実装化によっても異なります。以下に3つの実装方法の考え方について示します。

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

図の上部でスタースキーマ横断検索を実施して、下部でレポートの作成を行っています。横断検索の各フェーズについて(1)(2)で表示しています。検索結果の中間結果を途中のグレーの四角で示しています。Phase1は受注と出荷に対して商品別の検索をそれぞれ別に実施しています。Phase2において、Phase1の中間結果をマージして受注と出荷の比率を計算しています。

この図において、データベースとレポート作成処理のどちらで処理を実行しているのかというのを示しています。データベースについては一つのインスタンスもしくは別々の環境が想定され、レポート作成環境としては、デスクトップツールもしくはアプリケーションサーバでの実施が考えられます。

処理の分割

方式AはRDBMSとレポーティングツールで処理を分割する方法です。初めにそれぞれのスターに対して(つまり2回)検索を実行します。この検索においては同一のディメンションを利用して検索が実行されます。結果がレポーティングツールに帰ってきた後、Phase2が実行されます。レポーティングツールがデスクトップアプリケーションやAPサーバかということにかかわらず、Phase2はRDBMS側で実施されません。レポーティングツールにおいてレポート作成向けのマージ処理が実行されます。

このアプローチは、レポーティングツールにおける処理入力(ウィザード形式などによる)やBIツールによる自動処理によって実行されます。どの場合においても、二つのファクトテーブルを結合する際の問題点を避けることが可能です。

Phase2処理がRDBMSの外部で実施されることについて「非効率的である」という非難がなされる場合があります。「結合が得意なRDBMSではなく、ネットワークを経由してデータを取得したアプリケーション側で結合を実施する」という点がその論点となります。ここで注意してほしいのは、Phase2における結合というのは完全外部結合(full outer join)という点です。この完全外部結合はそれぞれのデータセットをソートをしてマージすることにより実施されます。アプリケーションからのSQL内にソート(order by)を記載した場合、ソート処理はRDBMSにおいて実施されるためあとはマージするだけとなります。そのマージ処理は非常にシンプルな処理です。実際にはRDBMS側の処理なしにも十分なパフォーマンスを得ることも可能な場合も多いです。

BIツールと横断検索における自動化

レポーティングツールはユーザーがクエリ実行や出力結果の自由な形式による結果の出力を可能にします。BIツールはこの概念をさらに広げたもので、DBに関する特別な知識なしに検索の実行を可能にしています。

これらのツールは「ビジネスビュー」「物理ビュー」という2つの情報ビューをマッピングすることで対応しています。ビジネスビューは「レポートに表示する項目」を示すもので、ユーザーはこのビューのみを利用します。その裏においては、ビジネスビューはDBの物理的スキーマにマッピングが行われています。この2つのビューのマッピングは技術開発者が実施することになります。

ユーザーがデータの要素をレポート設計画面にドラッグすると、ツールはビジネスビュート物理ビューのマッピング情報をもとにSQL実行に必要な情報を組み立てます。この物理ビューとのマッピング除法が定義されている、ビジネスビューの概念は「セマンティック(semantic)レイヤー」と呼ばれています。この概念はBusiness Objects社(現在はSAPの子会社)による特許で、多くのベンダーにおいても採用されています。

ここで紹介した横断検索におけ3つの概念はBIツールにおいて少なくとも一つは利用可能です。理論上は、BIツールでは複数のファクトが存在するということが把握できるので、実行に最適な方法を選択することが可能です。問題はBIツールにおいて自動で横断検索を実施するには特殊な設定が必要なことです。さらに混乱させるのはいくつかのツールにおいては限定的な場合においてのみ利用可能になるということです。不幸にして多くのベンダーは横断検索(drilling across)とは呼ばずに、ベンダー固有の名前がついています。また、どのように設定するかというのは技術開発者が扱うように隠ぺい化されています。このBI向けの設計については後で紹介します。

中間テーブルの利用

方式Bは方式Aと似ているのですが、RDBMSが2つの処理を実施するという天で異なります。Phase1においてそれぞれのスターに対して検索を実施しています。検索結果はレポーティング環境に転送しておらず、代わりにRDBMSの一時的なテーブルに格納しています。

Phase2において別の検索がRDBMSで実施されます。この検索が2つの一時表のマージと(必要があれば)比率の計算です。そして最後にその結果がレポーティング環境に転送されます。

このアプローチではデータをRDBMS上だけで扱えるという利点があります。レポーティング環境には最後の段階で初めてデータが転送されることになります。そのため、レポーティング環境上のリソース(CPU/Memory)は必要としませんが、RDBMS上処理のオーバーヘッドが必要となります。実際、データベース管理者(DBA)はこの手法についてはあまり良い顔をしません。この方法を実行するには十分な一時領域の確保、中間テーブルの結合で無駄なリソースを消費しないこと、DBログが大量に生成されないこと、アプリケーション処理完了後に中間テーブルの初期化(truncate/drop)を行うこと、などといったことを手事前に確認する必要があります。反面この方法はRDBMSの利点を最大限利用する方法とも言えます。

(続く)次回は方式Cとツールで横断検索ができない場合について解説します。