SQL Server 2005 のビジネス インテリジェンスおよびデータ ウェアハウジング概要

トピック

	はじめに
	SQL Server 2005 ベータ 1 を使い始めるには
	リレーショナル データ ウェアハウジング
	ETL (抽出、変換、ロード)
	Analysis Services
	Reporting Services
	まとめ
	付録 A: コード サンプル

はじめに

Microsoft SQL Server 2005 は、従来型および最新技術に基づく分析アプリケーションの双方を開発するための様々な特長、ツール、機能を備えた、完全なビジネス インテリジェンス (BI) プラットフォームです。 このドキュメントでは、分析アプリケーションの開発に使用するツールを紹介し、複雑な BI システムを容易に開発、管理するための新しい機能について解説します。

次の表は、ビジネス インテリジェンス システムのコンポーネント、および対応する Microsoft SQL Server 2000 and SQL Server 2005 コンポーネントの一覧です。

SQL Server 2005 には、Reporting Services、BI Development "Workbench"、および SQL "Workbench" の 3 つの新コンポーネントが搭載されます。 その他にも主要な BI コンポーネントである DTS、Analysis Services OLAP、Analysis Services Data Mining が、SQL Server 2005 で大幅に変更、強化されています。SQL Server 2005 リレーショナル データベースには、いくつかの特徴的な新機能があります。 Microsoft Office クエリおよびポータル ツールは SQL Server には含まれませんが、現行リリースは SQL Server 2005 でも引き続き対応して機能します。Office ツールの BI 機能は、Office 製品のリリース サイクルの中で今後も技術開発を継続します。

SQL Server 2005 ビジネス インテリジェンスのツールセットは、エンド ツー エンドの BI アプリケーション統合を可能にします。

SQL Server 2005 ビジネス インテリジェンス コンポーネントの目標は、ビジネス インテリジェンスの開発および利用をあらゆる規模の企業でサポートすること、さらに幹部やアナリストなど一部のスタッフに限らず実務スタッフや社外の関連スタッフを含むあらゆる従業員に対してサポートすることです。 このような目標のために、SQL Server 2005 は完成度が高く扱いやすい統合プラットフォームとして開発されており、Web サービスとしてデータを発行し、市販のハードウェアで優れたパフォーマンスを発揮します。 また、最先端の分析アプリケーション開発に利用できる様々な新機能を備えています。

ページのトップへ

SQL Server 2005 ベータ 1 を使い始めるには

SQL Server 2005 をインストールして最初に気付くのは、インストールのエクスペリエンスが統合されていることです。 したがって、Analysis Services などの機能を分けてインストールする必要がありません。 Reporting Services などの機能をインストールできない場合は、使用しているコンピュータがその機能のインストール条件を満たしていません。 機能に必要な条件については Readme を参照してください。 マシン構成があらゆるインストール条件を満たす場合は、インストール時にすべての既定を許可して、次のような主な機能をすべてインストールします。

Reporting Services には、IIS がインストールされ正しく構成されていることが必要です。 Reporting Services は SQL Server 2005 ビジネス インテリジェンス機能セットに欠かせないコンポーネントなので、この構成およびインストール手順は十分慎重に実行してください。

Analysis Services を使い慣れているユーザーは、Analysis Services メタデータ レポジトリがないことを不思議に思うかもしれません。 SQL Server 2000 では Analysis Services レポジトリは Microsoft Access データベースとして提供されていますが、Analysis Services 2005 にはメタデータ レポジトリは含まれません。 その代わり、Analysis Services データベース メタデータ情報が XML ファイルとして保存されており、Analysis Services によって管理されます。 この XML ファイルは必要に応じてソース コントロール下に置くことができます。

BI データベース オブジェクトの開発には BI "Workbench" を使用し、BI データベース オブジェクトの運用管理には SQL "Workbench" を使用することをお勧めします。 DTS パッケージおよび Analysis Services キューブおよびマイニング モデルは SQL "Workbench" でデザインできますが、BI "Workbench" ではより優れた BI アプリケーションのデザインおよびデバッグを体験することができます。

ベータ 1 では、既存の DTS パッケージまたは Analysis Services データベースのアップグレードから始めるよりも、新規アプリケーションから始める方がより多くを学習できます。 既存のパッケージまたはデータベースがある場合はそれを「再作成」するのが便利かもしれませんが、新しい機能、特性、概念に親しんでから、既存オブジェクトのアップグレードを試みてください。

多くの顧客ユーザーは SQL Server ツールを使って、DTS を用いた１つまたは複数のソース システムの、最近では一般的になっているビジネス インテリジェンス構造を備えたシステムを開発して、ディメンション リレーショナル データ ウェアハウスにデータを供給することになるでしょう。 さらには、このシステムを Analysis Services データベースへのデータ格納に使用することができます。 しかし SQL Server 2005 は、異なるコンポーネントを解消または仮想化することによって、この基本設計を超越するための多くのオプションを用意しています。

ページのトップへ

リレーショナル データ ウェアハウジング

SQL Server 2005 リレーショナル データベース エンジンは、データ ウェアハウス スタイルのアプリケーション設計および保守にとって注目すべき複数の機能を含んでいます。 これらの機能には、以下が含まれます。

レポートサーバー

リレーショナル機能的なレポートをトランザクション データベースから切り離すための一般的な手法は、レポート サーバーを運用することです。 レポートサーバーは、トランザクション データベースのイメージをある程度の遅延とともに保持し、多くの場合に前日時点のイメージとなります。 レポートサーバーは、ほとんどのレポート機能およびデータ ウェアハウス抽出のために使用します。

Microsoft SQL Server 2005 は、レポート サーバーの作成および運用を格段に容易にする、2 つの新しい機能を加えています。 SQL Server レポート サーバーの遅延は、1 日を大幅に下回ることが可能です。 さらにレポート サーバーは、トランザクション システムのスタンバイ システムとして機能するように設計されています。

レポート サーバーを作成するには、まずデータベース ミラーを作成します。 これは SQL Server 2005 の新しい機能で、高可用性のためにすぐに利用できるスタンバイ システムを実現します。 詳しくは、SQL Server Books Online の「データベース ミラー化の概念」を参照してください。 データベース ミラーに直接問い照会することはできず、そこに別の新機能の出番があります。

ミラー上で、データベース ビューを作成します。 データベース ビューは、ある時点でのデータベースの読み取り専用コピーです。 データベース ビューは、データベースの完全なコピーではなく、空間をきわめて効率的に利用します。 複数のデータベース ビューを併存できますが、データベース ビューを維持することはそのデータベース ビューの元になるトランザクション データベースにある程度影響します。 詳しくは、SQL Server Books Online の「データベース ビューについて」を参照してください。

データベース ビューをデータベース ミラー上に作成することにより、システムの可用性を高めるスタンバイ サーバーを容易に作成でき、レポート サーバーのように二重の役割を担います。

テーブルパーティション

パーティション テーブルおよびパーティション インデックスのデータは、水平単位に分割されているので、行のグループを個別のパーティションにマッピングできます。 クエリなどデータ上で行われる操作は、テーブル全体またはインデックス全体があたかも単一のエンティティであるかのように実行されます。

パーティションには次のような効果があります。

リレーショナル データ ウェアハウスでは、ファクト テーブルはテーブル パーティションの代表例であり、パーティション作成の戦略としては日付範囲によるパーティションが最も一般的です。

パーティション テーブルを定義するには次の 3 段階のステップがあります。 (詳しくは、SQL Server Books Online の「パーティションテーブルおよびインデックスの作成」を参照してください。)

複数のテーブルで同じパーティション スキームを使用できます。

このドキュメントでは、ファクト テーブルの範囲パーティションのみについて解説しており、テーブルのパーティション作成についてすべてを説明することは目的としていません。 パーティション作成の詳細については、SQL Server Books Online を参照してください。

最も一般的なパーティション スキームは、年、四半期、月、または日などの日付範囲によってファクト テーブルにパーティションを作成することです。 多くのシナリオでは、大規模なファクト テーブルに日付によるパーティションを作成することにより、管理機能上のメリットを得られます。 クエリ パフォーマンスを強化するには、同じパーティション スキームを使って時間ディメンション テーブルにパーティションを作成します。

テーブルパーティションによる高速データロード

大抵のデータ ウェアハウス アプリケーションでは、増加し続ける大容量のデータを小規模な (縮小しつつある) ロード ウィンドウにロードすることに苦労しています。 典型的なプロセスは、複数のソース システムからデータを抽出することに始まり、続いてこれらのシステムのデータをクレンジング、変換、合成、合理化します。 データ管理アプリケーションは、抽出、変換、およびロード プロセスをロード ウィンドウ内で完了することに限定されます。 通常はシステムのビジネス ユーザーは、データウェアハウスが照会に対応しない時間が最小限になるように、システムに対して強く要求します。 新規データが既存のデータ ウェアハウスに挿入される、データ管理アプリケーションの「書き込み」手順は、必ずユーザーへの影響を最小にするために迅速に行われるように設計します。

データを可能な限り高速にロードするには、データベースのリカバリ モデルが Bulk Logged または Simple となり、テーブルは「空」または「データを含みインデックスがない」状態となることが必要です。 これらの条件に一致すると、non-logged (ログなし) ロードが可能となります。 SQL Server 2000 では、パーティション作成済みテーブルが存在しないうちは、これらの条件は通常初期の履歴データ ウェアハウスのロードだけで一致します。 大規模なデータウェアハウスをともなうユーザーの場合、別の物理テーブル上に UNION ALL ビューを構築することにより疑似パーティション構造を作成している場合があり、これらの物理テーブルは non-logged (ログなし) 手法によって各ロード サイクルごとにデータが格納されます。 このアプローチにはまだ完成度を高める余地があり、SQL Server 2005 のパーティション済みテーブルはさらに高度な機能を提供します。

SQL Server 2005 では、non-logged (ログなし) ロードを直接パーティションに実行できませんが、疑似パーティションと呼ばれる別のテーブルにロードできます。 条件によっては、疑似パーティションをきわめて迅速に発生するメタデータ機能としてパーティション済みテーブルに切り替えることができます。 この手法は、次の 2 つの条件を満たします。

さらに、疑似パーティションを別のテーブルとしてバックアップでき、システムの管理機能を強化します。

テーブルパーティションによる高速なデータ削除

多くのデータ ウェアハウスでは、詳細データのスライド ウィンドウをアクティブな状態に維持しています。 たとえば、ファクト テーブルはデータを 3 年、5 年、場合によっては 10 年間維持しており、定期的に最も古いデータをテーブルから削除します。 余分なデータを常に取り除く主な理由は、クエリ パフォーマンスを高めてストレージのコストを最小限にするためです。

SQL Server 2005 のパーティションによって、パーティションが作成されている大規模なファクト テーブルから古いデータを取り除きやすくなります。 「空」の疑似パーティションを上記のように作成して、それをパーティション テーブルに切り替えます。 パーティション テーブルには、以前データをともなうパーティションがあった場所に空のパーティションがあります。 疑似パーティションには、以前データが「空」だった場所にデータがあります。 疑似パーティションは、必要に応じてバック アップ、切り捨て、削除が可能です。

オプションで、パーティション関数を再定義して、左側 (空) のパーティションをすべて 1 つにまとめることができます。

Transact-SQL の強化

新しいデータ型

データ ウェアハウスに便利な、次のような重要な型が新たに用意されています。

新しい分析関数

いくつかの新しい分析的な関数は、Transact-SQL の枠内で基本的な分析機能を提供します。 これらの関数は、Analysis Services のみによるのでなくリレーショナル データベースへのユーザー クエリを許可するデータ ウェアハウスに便利です。 また、これらの複雑な計算は、一般的に有効なデータ属性を開発するためにデータ ステージングで利用されます。

ROW_NUMBER。 結果セットのシーケンシャルな行番号を返します。

RANK。 結果セットの行のランクを返します。 RANK は順位セットの ROW_NUMBER と同一ですが、結合する行の処理にのみ対応します。 同じ順位値をともなうすべての行は、同じ RANK を受け取ります。 次の RANK は、再び ROW_NUMBER と一致します。 つまり、最初の位置に双方向の結合がある場合は、行 1 および行 2 が RANK=1 を受け取り、行 3 が ANK=3 を受け取ります。 RANK=2 を受ける行はありません。

DENSE_RANK。 結果セットの行のランクを返します。 DENSE_RANK 関数は RANK に似ていますが、RANK 関数に残されていたギャップをなくします。 上記のサンプルでは、行 1 および行 2 が RANK=1 を受け取り、行 3 が RANK=2 を受け取ります。

NTILE。 順位セットを、指定のグループ数にほぼ同じサイズで分割します。

これらの分析関数は、SQL Server 2005 Beta 1 には含まれていません。

PIVOT および UNPIVOT 演算子

PIVOT 演算子は、クエリにある break 値に従って結果セットを回転することにより、クロス集計レポートの生成を可能にします。 たとえば、テーブルが "Actuals" および "Budgets" のデータを別個の行に含む場合、PIVOT 演算子を使って [Actuals] および [Budgets] という名称の列をともなうクロス集計レポートを生成できます。

同様に、UNPIVOT 演算子を使うことにより 1 つの行を複数に分割できます。 この例では、[Actuals] および [Budgets] をともなう行セットを複数の行に変換してこれらの値をタグ付けできます。

SQL Server の以前のバージョンでは、複雑な Transact-SQL SELECT 文を記述してデータを回転することが可能でした。 PIVOT および UNPIVOT 演算子は、直接的にデータを回転するためのメカニズムとして利用できます。

再帰クエリ

「再帰クエリ」がきわめて役立つ複数のシナリオが考えられます。 SQL Server 2005 の新しい機能は、再帰クエリを可能に (場合によっては容易に) します。

再帰クエリは、自己結合をともなうテーブル上のクエリです。 2 つの代表的な例として、従業員および管理者についての情報を持つテーブル、および部品表テーブルがあります。 自己結合をともなうテーブルは、AdventureWorks データベースの Employee (従業員) テーブルに示されています。

直接的な関係について自己結合をともなうテーブルにクエリを実行すること、たとえばある管理者に直属の従業員数を照会することなどは、これまでも比較的容易でした。 一方、「その管理者が統括している部門の従業員数は何名？」という質問に答えるのは、さらに難しくなります。

このような問題に対処する SQL Server 2005 リレーショナル データベースの機能は、「再帰的な共通テーブル式 (Recursive common table expressions)」と呼ばれます。 このドキュメントの末尾にある「付録」には、上記に定義した質問に答える再帰クエリの例が含まれています。 詳細については、SQL Server Books Online の「WITH <common_table_expression>」を参照してください。

ページのトップへ

ETL (抽出、変換、ロード)

データ変換サービス (DTS) は、SQL Server 2005 ではまったく新しくなっています。DTS は SQL Server 2000 でよく使用されている機能ですが、DTS 2005 は企業向け ETL プラットフォームとなるように再設計されています。 DTS は幅広い機能、きわめて高いスケール パフォーマンスといった、企業クラスの ETL アプリケーション作成に必要な要素を提供します。 DTS は、完全なプログラム可能、組み込み可能、拡張可能な特性を備えており、ETL プラットフォームに理想的です。

次の表は、DTS 2005 の機能一覧です。 ETL システム開発に DTS を応用する詳細については、SQL Server Books Online を参照してください。

パッケージ開発

制御フロー

データフロー

開発およびデバッグ

DTS 2000 開発者にとっての DTS 2005

DTS 2000 ユーザーは、複雑な処理を実行するためにある種の裏技を開発してきました。 このような裏技 (特に自己編集パッケージの作成) は、DTS 2005 では不要になります。DTS 2005 では、変数および構成インフラストラクチャを使うことにより動的なパッケージを開発できるので、自己編集パッケージを作成する必要はありません。

洗練された変数および構成インフラストラクチャは、サブパッケージの複雑なシステムを作成する必要性を減らします。 デザインが優れていれば、単一パッケージで様々なニーズに対応できます。 たとえば単一パッケージは、ディメンショナルなデータウェアハウスに多数のディメンション テーブルをロードするための異なる構成で再利用できます。 DTS 2000 では、DTS パッケージの複雑なネットワークには 50〜100 のパッケージが含まれる場合がありますが、DTS 2005 では複雑なネットワークに含まれるパッケージはわずか 10 ほどです。

ページのトップへ

Analysis Services

SQL Server 2000 Analysis Services は、相互に補完する 2 つの主要な機能、すなわち OLAP (オンライン分析処理) およびデータ マイニングから構成されていました。 これらのコンポーネントは、Analysis Services 2005 にも分析アプリケーションの要として残っています。

Analysis Services 2005 OLAP 機能における強化は、2 グループに大別できます。

分析データベースの構築には、主要なパスが次の 2 種類あります。

いずれのアプローチでも、基本的なシステム デザインは、ディメンショナル リレーショナル データ ウェアハウスにデータを供給する１つまたは複数のソース システムの、最近では一般的になっているビジネス インテリジェンス構造を前提にしており、これを Analysis Services データベースへのデータ格納に使用します。 しかし SQL Server 2005 は、異なるコンポーネントを解消または仮想化することによって、この基本設計を超越するための多くのオプションを用意しています。 新たなシステムについては、以降の「統一ディメンション モデル」の項を参照してください。

既存のソースからカスタムデータベースを作成する

Analysis Services データベースを作成する最初の方法は、SQL Server 2000 ユーザーに最も馴染み深い方法です。 任意の構造によるソース データベースから始めます。

標準化されたデータベースからデータを取得する機能は、Analysis Services 2000 とは大きく異なる点です。 Analysis Services 2000 では、スター、スノーフレーク、またはフラットいずれかのディメンション構造が必要です。 この特長によって、きわめて低遅延な BI アプリケーションの開発が容易になります。

多くのユーザーは、最初から正式なデータ ウェアハウスは作成せずに、Analysis Services データベースを直接トランザクション データベースに作成することによって、最もシンプルかつコスト効率的に要件を満たすことができます。 ユーザーのデータを利用可能にするために最小限の変換、クレンジング、統合が必要な場合は、既存のリレーショナル レポートを補完するか、リレーショナル レポートの代わりとして Analysis Services データベースの利用をご検討ください。 Analysis Services の機能性およびインタラクティブな特性を活かすことにより、トランザクション システム上のロードを管理しやすくなります。

Analysis Services データベースを直接トランザクション システムから作成、維持することが可能ですが、企業における多くの分析条件は、まずリレーショナル データ ウェアハウスを作成することにより最も理想的に満たすことができます。 複雑なデータ統合およびデータ変更管理の問題は、クエリおよび分析エンジンとして動作する Analysis Services データベースを使う、古典的なデータ ウェアハウス アーキテクチャによって最も有効に解決できます。

データソースおよびデータソースビュー

新しい分析アプリケーションを作成するための最初の手順は、新規の Analysis Services プロジェクトを BI "Workbench" で作成することです。 空白のプロジェクトを作成した後に、データ ソースを作成してソース データベースと接続します。 ソース データベースは、任意のサポートされるリレーショナル データベース管理システムにあります。 ベータ 1 では、ソースとして　SQL Server 2000 または SQL Server 2005 リレーショナル データベースから始めることをお勧めします。

データ ソースは、ソース データと接続するための情報を格納します。 データ ソース ビューには、ソース データベースにあるテーブルの関連サブセットについての情報が含まれます。 この情報はソース データベースにあるテーブルの物理的な構造に限らず、関係、テーブルと列の覚えやすい名前、計算される列、名前付きクエリなどの情報を加えることができます。

データ ソース ビューは、BI プロジェクトおよび DTS プロジェクト間で共有できます。 データ ソース ビューはいつでも役に立ちますが、とりわけ次の場合に利用価値があります。

データ ソース ビューの評価を高めてよい関係を築くために投資を惜しまなければ、分析アプリケーションの開発がより容易になります。

ディメンションおよびキューブの作成

データ ソース ビューを作成した後は、 [Solution Explorer] ペインの [Cubes] アイコンを右クリックして、[New cube] を選択します。 IntelliCube による検出および提言を有効にするオプションが示されます。 IntelliCube の使を選択する場合は、ピボットまたはレポートのいずれに最適化されたキューブを作成するかを決める必要があります。 IntelliCube 技術は、データソースビューのデータベースおよびデータ濃度関係を調査して、テーブルをファクト テーブル、ディメンション テーブル、または多対多の関係を解決するディメンションおよびファクト間のブリッジ テーブルとして特徴づけます。 ベータ 1 では、ピボットまたはレポートのどちらに対してキューブおよびディメンションを最適化するかの選択による違いは、ほとんどありません。 唯一の違いは、IntelliCube がディメンションの属性の中で階層的な関係を作成しようとするかどうかにあります。 しかし階層は作成と削除がきわめて容易なので、上述の選択に時間をかける必要はありません。

キューブ ウィザードの初期画面の直後に [Finish] ボタンを押すのが有益です。 Analysis Services データベース、ディメンション、階層、属性、キューブがすべて定義されます。 このデザインは編集可能ですが、通常はウィザードを進む過程で最良の選択を指定する方がより効果的です。

キューブ ウィザードの作業後は、ディメンション ウィザードを使って複雑なディメンションを 1 つずつ作成すると良いでしょう。ディメンション ウィザードは、 [Solution Explorer] ペインの [Dimensions] を右クリックすると起動します。 製品、顧客、時間などの大規模なディメンションを慎重に定義した後に、キューブ ウィザードを立ち上げてあらかじめ定義したディメンションが適切に含まれていることを確認します。

構築と展開

これまでの手順は、単にディメンションとキューブの定義および構造を XML ファイルとして開発用マシンに作成しました。 BI "Workbench" および Configuration Manager を使うことにより、対象サーバー上にプロジェクトを構築、展開するプロセスを実行できます。 既定では、「開発」対象サーバーはユーザーのローカル サーバーとなります。 展開の別の構成を、異なる環境に作成することもできます。 対象サーバー名やデータ ソース接続文字列など、プロジェクトの主要なプロパティは、構成ごとに異なります。

開発サイクルの間にキューブおよびディメンションをプレビュー、テストするために、メイン BI "Workbench" メニューから [Deploy] を選択して、指定の対象サーバーにプロジェクトを構築、展開します。 代わりに、F5 キーを押すか、またはメイン BI "Workbench" メニューから [Debug... Start] を選択することもできます。 [Deploy] を選択するとき何を実行するかに応じて、複数あるデバッグおよびブラウズ ツールの 1 つが立ち上がります。 この前後関係に従って、展開プロセスはキューブ ブラウザ、MDX スクリプト デバッガ、または KPI ブラウザを立ち上げます。

プロトタイプ システムのディメンション、メジャー、キューブを定義した後に、プロトタイプ システムを表示できます。 比較的小量のデータをともなう開発データベースに対するプロセスを行い、データおよび構造が予想通りに動作するかを検証します。

プロトタイプの中では、Analysis Services データベース、KPI (主要業績評価指標)、アクション、計算のより複雑なコンポーネントを部分的にデザインできます。 ユーザーのデータベースを、異なるデータ ビューに関心を持つ異なるユーザーのコミュニティが使用する場合は、Perspectives および新たなセキュリティ計画について検討するべきでしょう。 データベースを、言語が異なるユーザーを対象にして国際的に展開する場合は、変換機能によってローカライズされたオブジェクト名を表示できます。 さらにプロトタイプでは、パーティションおよび異なるプロアクティブ キャッシュのオプションなど、別の物理構成を必ず評価します。

Analysis Service データベースを開発した後は、データベース オブジェクトを最終テスト、ステージングまたは生産サーバーに展開します。 構築ステージの間に作成されるプロジェクトの結果は、Analysis Services 展開ユーティリティへの入力データとして利用できます。 このユーティリティは、データベースの展開およびプロセスに役立ちます。

テンプレートによるカスタマイズ可能なデータベースの作成

これまで、カスタムな Analysis Services データベースを既知のソースから作成する基本的な手順について説明しました。 Cube Wizard および Dimension Wizard を利用するこの方法は、Analysis Services 2000 データベースを作成する標準的な方法と似ています。

SQL Server 2005 分析アプリケーションを作成するもう 1 つの方法は、キューブ ウィザードの 2 番目の画面で "Design BI model without data source (データ ソースなしに BI モデルを設計する)" のオプションを選択することです。 ウィザードからこの方法を選ぶことは、SQL Server 2000 Accelerator for Business Intelligence のデザイン エクスペリエンスと似ています。 このデザイン エクスペリエンスは、テンプレートから完全なカスタマイズ可能アプリケーションを生成し、リッチなディメンショナル構造および分析機能、さらにオプションでリレーショナル データ ウェアハウスおよび DTS パッケージが含まれます。 テンプレートは、マイクロソフト、インテグレータ、独立系ソフトウェア ベンダから提供されます。

「ソース データベースから作成する方法」または「テンプレートから作成する方法」のいずれかをウィザードから選択することにより、同じ Analysis Services データベースをデザインできます。 最初の方法を選択する場合は、完全にカスタムなシステムを作成することが前提となります。 オブジェクト名および構造は完全にカスタマイズ可能となり、初期デザインはソース データベースにある名前および構造から生まれます。 テンプレートを使う方法もカスタマイズ可能なデータベースを作成できますが、初期デザインは専門的なサブジェクト エリア テンプレートから生まれます。

多くのユーザーは、2 種類の手法を組み合わせて使うでしょう。 最も一般的なシナリオは、Analysis Services データベースの大部分を既存のソースから作成しますが、時間ディメンションはテンプレートから生成します。

統一ディメンションモデル

Analysis Services 2005 では、リレーショナルとマルチディメンション OLAP データベースの境界線が曖昧になります。 OLAP データベースはこれまで一貫して、主に次のような分析アプリケーションの多大な優位性を提供してきました。

これまでは、これらの優位性を得るにはコストがかかりました。 Analysis Services 2000 などの OLAP データベースでは、次のような内容を実現するのが難しいことが判明しています。

従来の OLAP 分析およびリレーショナル レポートの最も優れた点を組み合わせることにより、Analysis Services 2005 は単一の統一的なディメンション モデルを実現して、双方のニーズに応えます。 SQL Server 2005 で定義されるキューブおよびディメンションのセットは、統一ディメンション モデル (UDM) と呼ばれます。 UDM の特長およびフレキシビリティは、デザインに大きな変化をもたらします。 これまで BI の設計者は、二者択一のインフラストラクチャのメリットおよびコストを重視しながら、リレーショナルまたは OLAP を選択していました。 これからは、設計者は UDM をデザインした後に、これら従来の両極 (リレーショナルおよび OLAP) 間にあるどの地点に Analysis Services システムの論理的なデザインおよび物理的な構成を位置付けるかを判断するようになります。

属性ベースのディメンション

Analysis Services 2005 は、ディメンション「階層」ではなくディメンション「属性」を中心にキューブを構成します。 Analysis Services 2000 では、ディメンション デザインは {Year、Month、Day} または {Country、Region、City} といった階層に支配されています。 このような階層では、レベル間に強力なデータ関係が必要です。 メンバ プロパティおよび仮想ディメンションとして表された属性は、低く見られていました。 物理ディメンションに属性を設定することは可能でしたが、パフォーマンス面を考慮するとこの手法を広く応用するメリットはありませんでした。 リレーショナル構造に慣れているユーザーは、OLAP データベースで階層がきわめて重視される点に戸惑っていました。

Analysis Services 2005 の構造は、リレーショナルなディメンション構造により近くなっています。 ディメンションには多くの属性が含まれ、それぞれをクエリのスライスおよびフィルタ処理に利用でき、またデータ関係にかかわらずそれぞれの属性を階層に組み合わせることができます。

OLAP の背景に詳しいユーザーは、強力な階層の価値を理解できるでしょう。 そこでは確実に、City が Regions および Country に手際よくロールアップします。 このような自然な階層は引き続き存在し、必要に応じて定義する必要があります。 クエリ パフォーマンスのメリットは、階層の使い方次第で得られるのです。

例として、Customer (顧客) ディメンションについて考えます。 リレーショナル ソース テーブルには、次の 8 列があります。

対応する Analysis Services ディメンションには、7 つの属性があります。

{Country、Region、City、Customer} 上のデータには、自然な階層があります。 アプリケーション開発者は、ナビゲーションを意識して {Age、Gender} 上に第 2 階層を作成することを選択できます。 企業ユーザーは、これら 2 階層の行動の違いを認識しませんが、自然な階層には、ユーザーには見えず階層関係を理解するインデックス構造のメリットがあります。

新しいディメンション構造の最も重要な長所には、次の点があります。

ディメンションの種類

Analysis Services 2000 のディメンションには、通常階層型と親子ディメンションの 2 種類があります。 Analysis Services 2005 は新たに重要なディメンション構造を加えています。 そのいくつかは奇妙な名前に見えますが、 BI の世界では通用しています。

Measure Groups および Perspectives

Analysis Services 2005 は、Measure Groups (メジャー グループ) および Perspectives を導入して、分析データベースの設計と展開を簡素化しています。 Analysis Services 2000 では、ユーザーは複数の物理的なキューブ作成を作ることが求められました。 それぞれのキューブは特定の次元に対応し、通常は特定のリレーショナル ファクト テーブルにも対応します。 仮想キューブは、ビジネス ユーザーに意識されない方法で複数のファクトテーブルを組み合わせましたが、開発者にとってはその定義が無意味に複雑な作業となっていました。

SQL Server 2005 では、最も一般的なシナリオは、いくつかのメジャー グループを含む単一の物理的なキューブをともないます。 メジャー グループにあるファクト データには、ディメンション階層の交差部分によって定義される特定の精度があります。 クエリは、必要に応じて異なるメジャー グループに自動的に送られます。 物理レベルでは、パーティション (Analysis Services 2000 のパーティションに近い) はメジャー グループで定義されます。

大規模なアプリケーションは、多数のディメンション、メジャー グループ、メジャーをユーザーに提示でき、ナビゲーションにも挑戦します。 キューブ エディタの Perspective タブで定義される Perspective は、キューブのサブセット "ビュー" を作成します。 ある程度のパーソナライズを行うには、セキュリティ ロールをそのロールに対する perspectives アプリケーションのセットと関連付けることができます。

多くの Analysis Services 2005 データベースが、複数のメジャー　グループおよび perspectives をともなう単一キューブを含むことが考えられます。

キューブ ファクト構造およびクエリ パフォーマンスに対するその他の重要な強化点には、次があります。

計算と分析

Analysis Services などの分析サーバーを使用することに関する主な議論には、複雑な計算を集中的に定義する能力があります。 Analysis Services は常に充実した分析機能を実現してきましたが、複雑な概念については実現が困難な場合もありました。

複雑な概念の 1 つには、semi-additive メジャーの概念があります。 [Sales] などの最も一般的なメジャーは、すべてのディメンションに沿って手際よく集計を行います。 全期間に渡る [Total Sales] であれば全製品、全顧客、全期間の売上げを集計します。 これとは対照的に、semi-additive メジャーは対象となる一部ディメンションの付加的なメジャーとなり、対象以外のディメンションには該当しません。 最も一般的なシナリオは、倉庫内にある品目数などの残高です。 昨日と今日の残高総額は、当然ながら昨日の残高と今日の残高の総和ではありません。 おそらくは期末残高であり、または期首残高の場合もあります。 Analysis Services 2000 では、正しいメジャーを実現するために複雑な MDX の計算を定義する必要がありました。 Analysis Services 2005 では、期首残高および期末残高はネイティブの集計タイプになります。

SQL Server 2005 では Distinct count メジャーも大幅に強化されています。Distinct count メジャーは文字列データで定義でき、クエリは任意セットで Distinct Count を実行するように定義できます。 Analysis Services 2000 は、あらかじめ定義された階層構造上でのみ Distinct Count を実行しました。

"Time Intelligence" ウィザードは、この期間対前期間、移動平均、その他一般的な時間計算構造の計算を含む時間計算ディメンションを作成します。

MDX スクリプト

マルチディメンション式 (MDX) はきわめて強力な言語として、Analysis Services 2000 計算およびセキュリティ ルールを定義するために使われていました。 しかし MDX は強力であるほどに複雑でもあります。 Analysis Services 2005 は、簡素化された構成および構文を使用する MDX スクリプトによって、新しい計算モデルを定義します。

MDX は、Analysis Services システムへのクエリ言語でもあります。 Excel Pivot Tables などのクエリ ツールは、ユーザーのドラッグ アンド ドロップ行動に基づいて MDX クエリを生成します。 このような MDX の利用は、MDX スクリプトとは関係しません。 MDX スクリプトは、計算されるメンバおよびセル計算などサーバー定義によるオブジェクトに使用し、クエリには使用しません。

Analysis Services 2005 キューブを定義するとき、キューブは構造だけを含みデータをともないません。 MDX スクリプトはキューブ構造の一部となります。 1 つの既定 MDX スクリプト コマンドが常に定義され、既定の集計を計算します。 既定の MDX スクリプト コマンドは、単一のステートメントから構成されます。

Calculate;

キューブが完全に処理される場合でもこの既定 MDX スクリプトが適用される前は、キューブはリーフ レベルのデータを含んでいますが集計は含んでいません。 単一ステートメントの既定 MDX スクリプトを適用すると、集計が計算および格納されます。

MDX スクリプト ステートメントは、セミコロンによって区分される次のコマンドを含みます。

BI Developer "Workbench" のキューブ デザイン ユーザー インターフェイスでは、計算されるメンバおよび名前付きセットを含む MDX スクリプトを計算ビュー (Calculations view) で構築します。 MDX スクリプトは、構文についてのガイドを提供する既定の計算式ビューに表示するか、または計算スクリプト ビューに表示できます。 計算スクリプト ビューは、セミコロンで終端されるコマンド セットとして MDX スクリプトを提示します。 これらのビューを交互に切り替えて表示できますが、現在のところ計算式ビューに表示するにはスクリプト全体に正しい構文が必要となります。

MDX スクリプトには、主な特長がいくつかあります。

SCOPE ([Customers].[Country].[Country].[USA]); 
   [Measures].[Sales] = 100; 
END SCOPE;

ストアドプロシージャ

Analysis Services 2005 は、ストアド プロシージャを導入して、ユーザー定義関数 (UDF) が提供する機能を拡張しています。 ストアド プロシージャは、C++、VB、Cなど、各種の共通言語ラインタイム プログラミング言語で記述できます。 ストアド プロシージャは、共通コードを 1 回開発すればそれを 1 か所に格納して他のストアド プロシージャ、計算、ユーザー クエリに再利用できるので、データベース開発および実装を簡素化します。

ストアド プロシージャには、次の 2 種類があります。

ストアド プロシージャを使って、クライアント アプリケーションが実行可能なタスクを実行できます。

KPI

Analysis Services 2005 は、企業業績を評価する計算のサーバー側定義のために、KPI (主要業績評価指標) フレームワークを導入しています。 これらの KPI は、データ アクセス API およびマイクロソフト ツールまたはサードパーティ ツールを使うことにより、レポート、ポータル、ダッシュボードに表示できます。 ベータ 1 では、KPI を表示するクライアント ツールは用意されていません。

解説者やベンダによっては、「KPI」が意味する概念が異なる場合があります。 Microsoft SQL Server Analysis Services 2005 では、KPI は 4 つのステップによって規定されます。

次の Web ページには、いくつかの KPI の例が表示されています。

リアルタイムのビジネスインテリジェンス

データ ウェアハウスおよびビジネス インテリジェンス アプリケーションは、これまで「古い」または大きく遅れたデータを使っていました。 データは、毎月、毎週、または毎日ごとに刷新されます。 従来のデータを肯定するユーザーは、リアルタイム BI が矛盾した表現であり、戦略的な意志決定に必要なデータは毎日刷新されればそれで十分と指摘します。 このような論者が見落としがちなのは、ビジネス インテリジェンスは社内全体に行き渡る必要があり、純粋に戦略的な意志決定のために少数のアナリストまたは企業幹部に展開されればよいわけではないことです。 実務的なビジネス インテリジェンスには、遅れがないデータが必要です。

Analysis Services 2005 は、実務的なビジネス インテリジェンスの新しい処理オプションを提供します。 Analysis Services 2000 では、キューブは、そのストレージ モードまたはパーティション戦略にかかわらず、"Pull" モデルで処理されました。 Analysis Services プロセスが立ち上がると、ソース データベースに新しい情報を探し、詳細データを処理してオプションで格納し、集計を計算および格納しました。

Pull モデルは Analysis Services 2005 でもサポートされますが、遅延の少ないビジネス インテリジェンスにとりわけ便利な新しいオプションによって Analysis Services 2005 とつながっています。

Analysis Services マルチディメンションストアのクエリ パフォーマンス特性は、リレーショナル ストレージを決定づけます。 したがって、クエリはマルチディメンション (MOLAP) ストレージに対して最高のパフォーマンスを発揮します。 マイナスの要素は、遅延です。 マルチディメンションストアは、そのリレーショナル ソースから下流にあります。 プロアクティブ キャッシュ技術のカギは、データ遅延および管理コストを最小にしながらクエリ パフォーマンスを最大にすることです。

プロアクティブ キャッシュ機能は、データの陳腐化を管理するプロセスを簡素化します。 ソース データベース上に新規ディメンション メンバまたは新規ファクト トランザクションなどのトランザクションが発生すると、すでにある「キャッシュ」が陳腐化します。 プロアクティブ キャッシュは、マルチディメンションキャッシュを再構築する頻度を決めて、キャッシュ再構築の間にクエリにどのように答えるかを指定し、管理者の介入なしにプロセスを立ち上げるための、調整可能なメカニズムを提供します。

プロアクティブ キャッシュにより、トランザクションが発生したときキューブのマルチディメンションキャッシュを自動的にリフレッシュするようにキューブを設定できます。 Analysis Services はデータをきわめて迅速に処理しますが、処理にはわずかでも時間を要します。 オプションで、マルチディメンションキャッシュ再処理が完了しない場合は、ユーザーのプロアクティブ キャッシュ構成が自動的にクエリをリレーショナル ストアにリダイレクトすることも可能です。

プロアクティブ キャッシュ構成をデザインするとき、プロアクティブ キャッシュをマルチディメンションパーティションごとに設定することが重要になります。 パーティションが 1 時間といった短い期間にデータを含むときは、キャッシュ リフレッシュ プロセスはきわめて短時間に発生することが考えられます。 最も複雑なプロアクティブ キャッシュ構成は、リレーショナル データベースから Analysis Services に対して更新が発生したことを伝える通知によって左右されます。 Microsoft SQL Server リレーショナル データベースは、このような通知をサポートします。 通知を送らないデータベースの場合、定義されたクエリに基づいて変更をポーリングするように Analysis Services を構成できます。

プロアクティブ キャッシュには、次のパラメータがあります。

データマイニング

概要

Microsoft SQL Server 2005 データ マイニングは、複雑な分析モデルを構築してそれらのモデルを業務に統合するために役立つ、ビジネス インテリジェンス技術です。 データ マイニング モデルは、次のような質問に答えます。

データ マイニング アプリケーションは、データ マイニングモデルを日常的な業務に統合します。 多くのデータ マイニング プロジェクトの目標は、ビジネス ユーザー、パートナー、顧客が毎日使用でき、アプリケーションの基底にある複雑な計算を意識せずに利用できる分析アプリケーションを構築することです。 この目標を達成するための主な 2 つのステップとして、データ マイニング モデルの構築、およびアプリケーションの構築があります。 SQL Server 2005 データ マイニングによって、これらのステップがこれまで以上に容易になります。

マイクロソフトの SQL Server 2005 におけるデータ マイニング機能の目標は、次の特長を持つツールを作成することです。

このホワイトペーパーをお読みの方々は、これまでにデータ マイニング アプリケーションを利用した経験がほぼ確実におありでしょう。 オンラインで書籍または音楽を購入したとき「人気商品」などの宣伝を受け取ったり、またはクレジットカード会社から疑わしい決済を確認するように要請されたり、スーパーマーケットで受け取ったレシートに個人的なクーポンが印刷されていたなどの経験があれば、データ マイニング アプリケーションを使用したこと、またはそのメリットを受けたことになります。 これまで、このようなアプリケーションの開発は、最大規模の企業における最大の課題として捉えられていました。 最大規模の企業でなければ、分析アプリケーションを開発できる稀少な人材を雇用して、データ マイニング アプリケーション作成に必要な高額な開発コストを支出できませんでした。 マイクロソフトは、同社の OLAP 技術が OLAP 市場の拡大に貢献したように、これまでデータ マイニング アプリケーションを開発できなかった企業および企業内の各部門にデータマイニング技術を広げようと考えています。

SQL Server 2005 データ マイニング ツールは、パターンについてデータセットを調べ、オプションでそれらのパターンを予想するために使用します。 調査、パターン発見、パターン予想が、データ マイニングの柱となる機能です。

データマイニングアルゴリズム

SQL Server 2005 Analysis Services を含むあらゆるデータマイニングツールは、複数のアルゴリズムを使用します。 Analysis Services は当然ながら拡張可能であり、サードパーティ ISV は Analysis Services データマイニングフレームワークへのシームレスなスナップ インが可能なアルゴリズムを開発できます。 データと目的に応じて各種の異なるアルゴリズムが考えられ、アルゴリズムはいずれも複数の問題に対して使用できます。

データ マイニング ツールは、多様な問題を解決することを得意とします。 ビジネスの問題を大別すると、以下の表のようになります。

SQL Server 2005 には、最もポピュラーなデータ マイニング アルゴリズムが搭載されています。