PR
図1●従来のBIシステム<BR>複数のデータ・モデルが存在しており,それぞれ課題があった。
図1●従来のBIシステム<BR>複数のデータ・モデルが存在しており,それぞれ課題があった。
[画像のクリックで拡大表示]
図2●統合ディメンション・モデルによる新たなBI&lt;BR&gt;従来は複数あったデータ・モデルを統一できる。
図2●統合ディメンション・モデルによる新たなBI<BR>従来は複数あったデータ・モデルを統一できる。
[画像のクリックで拡大表示]
表1●RDBと多次元キューブ(OLAP)の比較
表1●RDBと多次元キューブ(OLAP)の比較
[画像のクリックで拡大表示]
図3●統合ディメンション・モデルを作ったところ&lt;BR&gt;多対多のリレーションを組んだファクト・テーブルを持てることで,これまで以上に柔軟なスキーマの作成が可能になっている。
図3●統合ディメンション・モデルを作ったところ<BR>多対多のリレーションを組んだファクト・テーブルを持てることで,これまで以上に柔軟なスキーマの作成が可能になっている。
[画像のクリックで拡大表示]
図4●UDMでは多次元キューブの「属性」を持たせることも可能&lt;BR&gt;新たに属性を多次元キューブ内に持つことで,属性を利用して,複数の既存ディメンションをまたいだディメンションを後から作成可能になった。
図4●UDMでは多次元キューブの「属性」を持たせることも可能<BR>新たに属性を多次元キューブ内に持つことで,属性を利用して,複数の既存ディメンションをまたいだディメンションを後から作成可能になった。
[画像のクリックで拡大表示]
図5●属性による分析軸の変更例&lt;BR&gt;「西暦」-「四半期」-「月名」の「階層」を持ったディメンションの四半期の後ろに,「製品部門」の属性を追加することで,新たにディメンションを追加せずに分析軸を変更している。
図5●属性による分析軸の変更例<BR>「西暦」-「四半期」-「月名」の「階層」を持ったディメンションの四半期の後ろに,「製品部門」の属性を追加することで,新たにディメンションを追加せずに分析軸を変更している。
[画像のクリックで拡大表示]
表2●SQL Server 2005がBI機能で備える7つのストレージ・タイ
表2●SQL Server 2005がBI機能で備える7つのストレージ・タイ
[画像のクリックで拡大表示]
図6●ストレージの変更や,プロアクティブ・キャッシュの設定も非常に容易に行える
図6●ストレージの変更や,プロアクティブ・キャッシュの設定も非常に容易に行える
[画像のクリックで拡大表示]

▼SQL Serverは,データベース・エンジンに加え,OLAP(オンライン分析処理)やデータ・マイニング,レポーティング機能を搭載することで,データの管理と活用の基盤としての実績を積んでいる。SQL Server 2005ではそれをさらに強化する。
▼今回は,SQL Server 2005のビジネス・インテリジェンス(BI)機能で提供されるUDM(統合ディメンション・モデル)を中心に,データ管理と活用の基盤としての強化点をまとめる。

 SQL Serverのビジネス・インテリジェンス(BI)機能の発展は,1997年にSQL Server 7.0がOLAP*(オンライン分析処理)機能を備えたところから始まった。2000年にリリースしたSQL Server 2000では,データ・マイニング*機能が備わり,2004年にレポーティング機能が追加サービスとして提供されている。こうした着実な強化により,SQL Serverは,単なるトランザクション処理のデータベース管理システムだけでなく,保存したデータをユーザーが業務の意思決定に使える「情報」を作成・活用できるシステムの基盤として実績を積んできた。

 待望のメジャー・バージョンアップであるSQL Server 2005では,これまで提供してきたBI機能を拡張し,「これから」の,つまり「第二幕」のBIを提案する。この新版の機能強化は,(1)可用性の向上,(2)新データ・モデルの提供,(3)ユーザー・フレンドリ——という3つの観点で実施されている。

ミッション・クリティカルに対応

 まず可用性の向上について説明しよう。これまで,BIシステムは,情報系であり,1日数時間であれば停止しても問題ないとされていた。また,1日もしくは1週間おきに多次元データベース*(MDDB)が更新されていれば十分使えるものとされていた。

 しかし,昨今,BIシステムの価値が理解されてきた。マイクロソフトは,一般の従業員が各自の仕事にデータベースの情報を活用する「BI for the MASS(すべてのユーザーに対するビジネス・インテリジェンス)」という方法を提案している。これにより,企業内でBIシステムのユーザーが大幅に増え,「ミッション・クリティカル・システム並みの高可用性」が必要になっている。

 SQL Server 2005では,基本的なOLAPはもちろん,データ・マイニング,レポーティングまで含めてすべてが,フェイル・オーバー・クラスタ*マルチインスタンス*に対応している。また,分析サービス・オブジェクトおよびデータのバックアップと復元を新たにサポートすることにより可用性が向上する。

 データ・ウエアハウス*として,SQL Server 2005を利用する際は,このフェイル・オーバー・クラスタに加えて,連載第1回「高可用性データベースの実現」の記事で説明したデータベース・ミラーリングという機能を利用できる。

 また,連載第2回「パフォーマンス向上と管理性の強化」で解説したパーティション分割を利用することで,検索やバッチ処理,バックアップの時間を削減できる。

 こうした機能拡張により,「ミッション・クリティカル」なBIシステムの構築を強力に支援している。

管理性の良い新データ・モデルを採用

 次は新しく採用されたデータ・モデルについて説明したい。データ・モデルとはデータベースを効率良く構築し管理するために,データの種類や処理方法,共有するデータ間の関係によって構造化されたモデルである。代表的なものでは,リレーショナル型データ・モデルが挙げられる。

 SQL Server 2005では,統合ディメンション・モデル(UDM)という新しいデータ・モデルを搭載する。端的に言うと,リレーショナル型データ・モデル(RDB)とOLAPビューを統合したモデルである。

 まず,なぜUDMという新しいデータ・モデルが必要なのかについて,これまでの経緯に沿って説明しよう。

 BIシステムを構築する場合,現在は複数のデータ・モデルがあるが,それぞれに課題がある(図1[拡大表示])。

 最も初歩的なBIシステムでは,RDBに直接1対1でクライアントから接続し,クライアントごとにデータ・モデルを構築する。これは「BIアプリケーション参照」と呼ばれる。この場合,クライアントが複数のデータベースに接続する際,それぞれに対してデータ・モデルを作成する必要が出てくる。

 そこで,クライアントから複数のデータベースにアクセスできる集約型のデータ・モデルが登場した。これが「レポーティング・ツール参照」である。だが,この場合も,クライアントごとに複数のデータ・モデルが存在することに変わりはない。

 そこで登場したのが,OLAPである。OLAPは複数のデータ・ソースに対して1つのモデルを作成することで,それを複数のクライアントから利用できるようにした。「OLAPブラウザ参照」と呼ばれる。

 これにより,管理コストは大幅に減ったように見えたが,実際はそうではなかった。「データ・ソース」であるRDBや多次元キューブが複数存在していることは同じだったのだ。そこで,マイクロソフトが考えた「1つの解」がUDMである(図2[拡大表示])。

 UDMは,RDBと多次元キューブの「いいところ」のみを抜き出した,「全く新しいデータ・モデル」である。これにより,複数あったデータ・モデルを統一できる。具体的には,表1([拡大表示]を参照してほしい。

 RDBの特徴は,複数のファクト・テーブル*を持って,豊富な属性を保持可能なことだ。また,トランザクション・レベルのアクセスが可能,つまり「リアルタイム」にデータへアクセスでき,多対多の複雑なリレーションを組める。

 一方,多次元キューブは,複数のディメンション*を持つことができ,階層を持ったり,分かりやすい名前を付けたり,MDX*(マルチディメンション式)を利用した高度な計算を行えたりする。UDMは上記の双方が得意とする機能を盛り込み,双方の弱点を補っている。

 また,UDMではデータ・ソースを統合できる。具体的には「データ・ソース・ビュー」という機能によって,複数のデータ・ソースを1つに見立てられる。複数種類のデータベース,例えばSQL Serverだけでなく,OracleやDB2などOLE DB*ODBC*対応データベースからテーブルを引き出し,それらを1つのデータ・ソースとして見立てるビューを作成することもできる。

 テーブルにカラムを追加するような操作も可能である。これにより,「データ・モデル」と「データ・ソース」を区別して扱うことが不要になり,完全な単一化を実現している。

 実際の画面でUDMの特徴を確かめてみよう。図3([拡大表示])は「Adventure Works DW」という名前で作成したデータ・ウエアハウス向けデータ・ソース・ビューである。多対多のリレーションを組んだファクト・テーブルを持てることで,これまで以上に柔軟なスキーマの作成が可能になっている。また,前述のように,例えばOracleデータベース内のテーブルを持ってくることも可能である。

 UDMでは,多次元キューブに「階層」だけでなく通常RDBが持つ「属性」を持たせることも可能になっている(図4[拡大表示])。これまでは,いったん作成したディメンションが分析軸として不十分な場合は,別途ディメンションを構築する必要があった。UDMでは,新たに属性を多次元キューブ内に持つことで,属性を利用して,複数の既存ディメンションをまたいだディメンションを後から作成できる。これにより,管理すべきディメンション数を大幅に削減できる。例えば図5([拡大表示)では,「西暦」-「四半期」-「月名」の「階層」を持ったディメンションの四半期の後ろに,「製品部門」の属性を追加することで,新たにディメンションを追加せずに分析軸を変更している。

キャッシュでリアルタイム性を向上

 続いて,UDMでもう1つの重要な機能拡張となる「リアルタイム性」に関して説明しよう。SQL Server 2005は,BI機能において7つのストレージ・タイプを持っている(表2[拡大表示])。

 リアルタイムHOLAPから定期MOLAPまでが,SQL Server 2005で新たに追加された「プロアクティブ・キャッシュ」機能を利用するストレージ・タイプになる。プロアクティブ・キャッシュとは,多次元キューブをキャッシュしたり,ユーザーのコネクションを効率良く管理したりすることで,ユーザーがリアルタイムにデータを参照できるようにする仕組みだ。

 例えば,データ・ソースに何らかの変更があった際,クライアントのコネクションは,MOLAPからROLAPに切り替わり,ユーザーに最新のデータを参照させる。それと同時に最新の多次元キューブをキャッシュに格納しており,多次元キューブの更新が完了次第,ユーザーのコネクションをこのキャッシュに戻せる。どこまでリアルタイム性を望むか,また,どこまでクエリーのパフォーマンスを重要視するかで,ストレージを選択できる。ストレージの変更や,プロアクティブ・キャッシュの設定も非常に容易だ(図6[拡大表示)。

 管理および開発ツールも進化している。SQL Server 2000では,データベースの管理は,エンタープライズ・マネージャ,OLAPは分析マネージャ,クエリーはクエリー・アナライザとすべて別々に提供されていた。これがSQL Server 2005では,データの管理はすべて「SQL Server Management Studio」,BIの多次元キューブやレポートの作成は,「BI Development Studio」に統合される。

 BI Development Studioは,BIアプリケーションを開発・展開するための,完全に統合されたツールである。Visual Studio 2005と完全に統合されているので,チーム開発やソース・コントロール,バージョニング,オフラインでの多次元キューブの作成などを行える。開発,テスト,展開,変更,テストといったサイクルを効率良く管理できる上,ブレーク・ポイント*を設定することも容易だ。

前田 隆志

マイクロソフト
サーバープラットフォームビジネス本部
アプリケーションプラットフォームグループ
マネージャ