MSDN Authoring Template

Document Sample
MSDN Authoring Template Powered By Docstoc
					MICROSOFT OLAP SERVICES 7.0 SP1 と ORACLE EXPRESS 6.3.0
                     の比較評価




            222 THIRD STREET, SUITE 3130, CAMBRIDGE, MA 02142
            voice: 617.492.3555  fax: 617.492.3508  url: www.dsslab.com
目次

目次 ...........................................................................................................II

エグゼクティブサマリ ...................................................................................... 1

イントロダクション ......................................................................................... 1

OLAP 製品の比較 .............................................................................................................................................................. 2

ドキュメント概要 .............................................................................................................................................................. 2

ケーススタディ概要 .......................................................................................................................................................... 3

用語に関する注記 .............................................................................................................................................................. 3


デザイン概要 .................................................................................................3

ディメンション............................................................................................... 4

OLAP Services 論理仕様 – ディメンション設計 ............................................................................................................ 4
  メンバの識別.................................................................................................................................................................. 5
  階層と配列 ..................................................................................................................................................................... 5
  時間ディメンション...................................................................................................................................................... 5
  メンバの配列.................................................................................................................................................................. 6
  ディメンションのサイズ .............................................................................................................................................. 6

Express 論理仕様 – ディメンション設計: ....................................................................................................................... 7
  ディメンションと階層の表現 ...................................................................................................................................... 7
  ディメンションのサイズ .............................................................................................................................................. 8
  メンバのデータ型.......................................................................................................................................................... 8
  時間ディメンション...................................................................................................................................................... 8
  メンバの識別.................................................................................................................................................................. 9
  コンジョイントとコンポジット ディメンション ..................................................................................................... 9

比較:ディメンション設計 .............................................................................................................................................. 9

OLAP Services の手順 - データベースの初期設定とディメンションの設計 ........................................................... 10
  ディメンションの作成とテーブル リンクの確立 ................................................................................................... 10
  ディメンション情報のローディング ........................................................................................................................ 11

Express の手順 - データベースの初期設定とディメンションの設計 ....................................................................... 11
  ディメンションの作成 ................................................................................................................................................ 12
  テーブル リンクの確立 ............................................................................................................................................... 12

比較:ディメンションの作成と設置............................................................................................................................. 13

OLAP Services 論理仕様 – メンバ属性.......................................................................................................................... 14
  レベルに関連付けられたメンバ属性 ........................................................................................................................ 14
  仮想ディメンション:総計で用いる属性 ................................................................................................................ 14
                                                                                                                                                                                  ii
    複数の階層-ディメンション内のメンバ属性 ........................................................................................................... 15

Express 論理仕様 – メンバ属性 ...................................................................................................................................... 15


変数とキューブ............................................................................................. 16

OLAP Services 論理仕様 – 変数とキューブ .................................................................................................................. 16
  変数 ............................................................................................................................................................................... 16
  キューブ構造................................................................................................................................................................ 16
  キューブ計算フロー.................................................................................................................................................... 17

Express 論理仕様 – 変数とキューブ .............................................................................................................................. 17
  変数 ............................................................................................................................................................................... 17
  キューブ構造................................................................................................................................................................ 17
  Express 変数におけるディメンションの配列と希薄性 ........................................................................................... 18
  キューブ計算フロー (変数とフォーミュラ) ........................................................................................................... 20
  Express フォーミュラ .................................................................................................................................................. 20

比較:変数とキューブの設計 ........................................................................................................................................ 20
 異なるディメンションが設定された変数同士の間におけるデータの適用範囲 ................................................ 21

OLAP Services の手順 – 変数とキューブ ...................................................................................................................... 22
  テーブル結合と、キューブディメンションレベルの抑制に関する追記 ............................................................ 23
  リンクに関する追記.................................................................................................................................................... 24

Express の手順 – 変数とキューブ .................................................................................................................................. 24
  Express の手順 – キューブをテーブルへリンク....................................................................................................... 24
  増分ローディングの設計 ............................................................................................................................................ 25

OLAP Services に関する追記.......................................................................................................................................... 26

比較:キューブ設計手順 ................................................................................................................................................ 26


物理的なパーティション分割 ............................................................................ 26

OLAP Services 論理仕様 - データベースのパーティショニング............................................................................... 27

Express 論理仕様 - データベースのパーティショニング ........................................................................................... 28

OLAP Services の手順 - データベースのパーティショニング................................................................................... 29


一括のローディングと集計処理 ......................................................................... 29

OLAP Services 論理仕様 - 一括のローディングと集計処理....................................................................................... 29

Express 論理仕様 - 一括のローディングと集計処理 ................................................................................................... 30
  Express へのデータの取り込み .................................................................................................................................. 31
  AGGMAP を使用した集計処理の設計 ...................................................................................................................... 31

OLAP Services の手順 - 一括のローディングと集計処理........................................................................................... 31
  処理とパーティションの概要 .................................................................................................................................... 31
  処理とパーティションの詳細 .................................................................................................................................... 32

                                                                                                                                                                                          iii
Express の手順 - 一括のローディングと集計処理 ....................................................................................................... 32
  一括ローディングに対する構造とプログラムの開発 ............................................................................................ 32
  プログラムの実行........................................................................................................................................................ 32

一括のローディングと集計処理に関する比較の要約 ................................................................................................. 32


付加的な計算機能 .......................................................................................... 33

計算機能の概要 ................................................................................................................................................................ 34
 OLAP Services の計算機能の概要 .............................................................................................................................. 34
 Express の計算機能の概要 .......................................................................................................................................... 34

サポートされる計算機能 ................................................................................................................................................ 35
 OLAP Services............................................................................................................................................................... 35
 Express ........................................................................................................................................................................... 35

フォーミュラの優先順位 ................................................................................................................................................ 35
 OLAP Services............................................................................................................................................................... 35
 Express ........................................................................................................................................................................... 36

フォーミュラに関するアプリケーションの範囲 ......................................................................................................... 36
 OLAP Services............................................................................................................................................................... 36
 Express ........................................................................................................................................................................... 36

未知のデータと適用不能データ .................................................................................................................................... 37
 OLAP Services............................................................................................................................................................... 37
 Express ........................................................................................................................................................................... 37

計算処理での順序付けの使用 ........................................................................................................................................ 37
 OLAP Services............................................................................................................................................................... 37
 Express ........................................................................................................................................................................... 37

外部定義の関数 ................................................................................................................................................................ 38
 OLAP Services............................................................................................................................................................... 38
 Express ........................................................................................................................................................................... 38

計算機能の比較サマリ .................................................................................................................................................... 38


クエリ ........................................................................................................ 39

言語 .................................................................................................................................................................................... 39

クエリ API ........................................................................................................................................................................ 39

クエリの指定機能 ............................................................................................................................................................ 40
 ディメンションの指定 ................................................................................................................................................ 40
 計算処理 ....................................................................................................................................................................... 41
 クエリモデル................................................................................................................................................................ 44
 ユーザー定義のメンバセット .................................................................................................................................... 45


使用したハードウェアとソフトウェア ................................................................. 51



                                                                                                                                                                                             iv
エグゼクティブ サマリ
OLAP テクノロジは、数多くの用途がある中でも、データマートやデータ ウェアハウスに収
集された履歴情報の分析を目的に益々盛んに利用されています。本書は、Microsoft SQL
Server 7.0 OLAP Services Service Pack1と Oracle Express 6.3.0 について、リレーシ
ョナルデータ ウェアハウスに基づく OLAP システムを軸に比較します。比較を行うには共通
のフレームワークが必要となるため、DSS Lab は機能的に同等な MOLAP データベースを設
計して両製品に実装し、設計の容易さや、各ステップに必要とされる知識と手間といった要
素について、可能な限り定量化を試みました。
データ型のサポートや、損失データの取扱、および外部関数ライブラリの各項目については、
両製品とも互角でしたが、全体としてはマイクロソフトの OLAP Services に明らかに分が
あります。というのも、この OLAP Services は、豊富な論理ディメンション構造や、計算
モデルのシンプル性、実装デザインに対する論理デザインの相似性、およびディメンション
計算のサポートを備えているためです。
更に OLAP Services は、操作が遥かに容易であるだけでなく、データベースを実業務運用
へと移すために必要な時間と専門技術が大幅に低減しています。全てのディメンションや、
キューブ、属性、計算を作成するのに、SQL Server 7.0 OLAP Services では 1 日半もか
かりませんでした。これとは対照的に、Oracle Express の場合は、同等の構造を設計して
実装するのに 5 日を要したのです。
本書ではこれより、比較に用いるデータベースの設計とステップについて詳述します。その
次に控えているのは、同様のフレームワークを当てはめての、新しい SQL Server 2000 分
析サービスの比較となります。

はじめに
これまでの 7 年間に渡って、OLAP は情報の組織化と分析を行うための特定のアプローチを
表す言葉として取り入れられてきました。そして OLAP サーバーと関連ツールの明確な市場
が発展を遂げてきたのです。OLAP サーバー市場に最も早くから参入している製品はおおむ
ね Oracle の Express で、その登場はリレーショナルデータベースにさえ先行しています。
対照的に、同市場への最も新しい参入者の 1 社がマイクロソフトです。マイクロソフトは、
SQL Server 7 OLAP Services (以降 OLAP Services と略記) を 1998 年末に投入しまし
た。
OLAP テクノロジには数多くの用途があります。非常に大規模で、現在も成長を続けている
分野の 1 つは、データマートやデータ ウェアハウスに収集された履歴情報の分析での利用で
す。コンピュータにトランザクション情報を収集するほぼ全ての企業が、履歴データベース
を構築し、OLAP を用いてそこから鍵となる情報を導き出すことに、大きな意義を見出すこ
とができます。しかし、こうしたタスクを実行するツールの機能は製品によって全く異なる
ことがあり、それでも同一のアプリケーションをサポートすることとなるため、ツールの比
較は大掛かりな作業となります。
本書は、Microsoft OLAP Services と Oracle Express がサポートする OLAP システム向け
機能をリレーショナルデータ ウェアハウスに基づいて比較します。両製品とも多数の機能を
サポートしていますが、DSS Lab は比較の範囲を限定すると共に、両製品に実装できるケー
ススタディを作成して、各製品が特定のタスクを扱う方法について具体的な比較を行いまし
た。
本書の情報は、原稿執筆時の最新バージョンである OLAP Services 7.0 SP1 と Express
6.3.0 に基づいています。
OLAP 製品の比較
OLAP サーバーにはいくつか種類があります。アーキテクチャと開発経緯の点や、サポート
するアプリケーションの面からすると、それぞれの製品が全く異なっているにも関わらず、
データの組織化や操作機能の面では類似しています。共通のサーバーモデルもなければ、製
品間での共通用語も実際にはほとんどないため、2 つの非常に異なる製品が実際には類似し
ていると見なせても、裏を返せば 2 つの非常に類似した製品は全く異なる製品であるとも言
えます。そのため、比較を行うには共通のフレームワークが必要となるのです。
OLAP システムの分野の中で、マイクロソフト OLAP Services と Oracle Express は非常
に異なった製品であり、両製品が類似していると考える人はいないでしょう。Express はこ
れまで 30 年以上に渡って開発が行われてきました。もちろんその歳月によって価値が低下
したと捉えるべきではありません (ジェットエンジンを考えてみてください) 。逆に OLAP
Services は、遥かに新しい製品です。これら 2 つのシステムは、コンセプト的にも、また
プロシージャ的にも全く異なるレベルの方針を掲げているため、有効な比較が困難です。実
際あまりにも異なるため、比較に用いる有益な共通フレームワークを構築するには相当な努
力を要します。1つのフレームワークとなるのは、製品をあらゆる面からみた包括的な製品
レベルの特徴と機能リストを、あらゆる OLAP ツールに当てはめることのできる言語で記述
することです。こういったフレームワークは非常に有用ではあるものの、製品の性能を容易
には把握できません。もう 1 つのフレームワークは、各製品で同等の環境を構築し、その環
境のニーズを各製品がどのようにサポートするかを調べるものです。本書では後者を採用し
ました。本フレームワークは、ストーリー性の強いアプローチを作成するのと同時に、最初
に挙げたフレームワークで強調されている一部の重要な詳細質問を利用します。
今回の調査における具体的な比較材料は、データ ウェアハウスのデータを詳細に OLAP 分析
する必要のある顧客中心の販売業務としています。また抽象的な比較材料は、DSS Lab の一
般的な OLAP 評価基準に基づいています。この OLAP 評価基準は、www.dsslab.com の公
開ページから入手できます。
我々の主たる興味はデザインの測定にあり、設計の容易さや、各ステップに必要とされる知
識と手間といった要素について、可能な限り定量化します。これらを単純な数値に表すこと
ができる場合もあれば、「以上/以下」といった比較結果になることもあります。
DSS Lab は、評価対象を OLAP サーバーに絞り、マイクロソフト OLAP Services または
Oracle Express に 付 属 す る そ の 他 の ツ ー ル は テ ス ト に 加 え ま せ ん で し た 。 例 え ば 、
Microsoft SQL Server 7 とその関連ツールには必ず OLAP Services が付属し、また
Oracle Financial Analyzer と Oracle Sales Analyzer 製品は、Oracle Express 上で構築
されているツールです。

ドキュメント概要
アプリケーションの構築にあたって、データベース開発者は最初にデータベースを設計する
必要があります。これが OLAP システムであれば、分析用のディメンションと変数をどうす
るか、変数はキューブ間でどのように分割するか、そしてディメンションの構造をどう取る
かといった項目を決定することになります。設計の進行に伴って、焦点はより論理的な事項
からより物理的な事項へと移ります。ただし物理的な要因によっては、論理構造の実装と最
適化を別の方法で行う必要が生じる場合もあります。データベースへのデータのロードが完
了したら、システムへのクエリ発行や、分析およびレポートの実装が行えます。ユーザーが
システムを利用している間も、新規データのロードが行われます。
こうしたデータベースのライフサイクルの中において、初期段階では論理的な事項が優勢を
占め、その一方で物理的な事項がその後になって多くの割合を占めることとなります。DSS
Lab はこの後、製品に関して体系的に記述し、評価に伴って表出する質問について秩序だっ
て進行していきます。
ケーススタディ概要
今回の比較の基盤とするアプリケーションは、販売、返品、および在庫の事実情報によるデ
ータマートスキーマで構成されます。製品および顧客のディメンション テーブルは、高度に
スノーフレーク化されています。販売の論理ディメンションは、顧客、時間、製品、プロモ
ーション、および支払方法です。返品の論理ディメンションは、顧客、時間、製品、プロモ
ーション、支払方法、および返品理由です。そして在庫の論理ディメンションは、倉庫、製
品、時間です。
本ケーススタディでは、OLAP データベースの設計と実装方法だけでなく、データの保守方
法についても説明します。時間の経過と共に、データ ウェアハウス管理の大半が、データの
保守と更新に費やされます。我々が作成した実施内容として、ライフサイクル中の新規ファ
クトデータと新規ディメンション メンバを取り入れましたが、ディメンションの変更につい
ては取り入れませんでした。
データベースの規模は適度に大きいサイズです。全体として、返品ファクトテーブルには
4,482,804 行、37,584,000 の在庫行、および 56,030,229 の販売行を設定しました。
アプリケーション開発ツールは、2 台の Dell PowerEdge 6300 サーバー上で実行されまし
た。同サーバーは、4GB の RAM と 4 つの 400 MHz PII Xeon プロセッサを搭載し、
Windows NT 4.0 Enterprise Edition、SP4 および 5 がインストールされました。1 台の
サーバーは OLAP 処理の専用マシンとしました。もう 1 台は RDBMS を動作させるもので、
Clariion FC5700 ファイバチャネルディスクアレイに接続して、ソースデータを収容しまし
た。
リレーショナルデータベースを想定し、DSS Lab は目的の分析を行えるよう、機能上同等の
OLAP データベースを設計して、Microsoft OLAP Services と Oracle Express の両方に実
装しました。実装する必要のあるものとして、各製品で MOLAP ストレージモードを用いて
顧客および製品レベルの分析を詳細に実行できる機能などがありました。我々は、種々の基
準に基づいて最初と最後にランクされた個別の顧客を選択できること、そしてまた最初と最
後にランクされた SKU を選択できることを望みました。また、いくつかの基準に則して、
時間、顧客、製品に関する数量と親への割合/全体への割合のパーセンテージを記録できるよ
うにしたいとも考えました。また OLAP Services のクエリ性能を評価する目的で、C++ に
クエリハーネスを実装しました。

用語に関する注記
製品を比較する際は、できる限り一般的な用語を用いるよう努めています。表面上異なる分
野をサポートする製品は、しばしば比較に値するものです。例えば、統計パッケージ、リレ
ーショナルデータベース、および OLAP データベースは、データ編成とサポートされている
計算能力の面で、有効に相互比較を行うことができます。異なる製品は、別々の用語を用い
て同一のコンセプトを表していることがしばしばあります。そこで、製品に依存しない中立
的な用語については、その初出時に強調して表示します。

デザイン概要
分析用に一組のデータキューブをデザインする場合、ディメンションと変数を検討し、それ
に対する論理的および物理的なデザインを作成する必要があります。 (変数という用語は計
算におけるソースとターゲットのデータ型を、また ディメンションという用語は変数を編成
するデータ型を、それぞれ表します。OLAP Services では、変数をメジャーと呼んでいます。
Express では、変数とフォーミュラの両方が変数として機能します。) ビジネス分析は、ツ
ールのニーズではなく、ビジネスのニーズに従って行われます。OLAP システムがモデル化
の直接の対象となるビジネスデータ環境に近くなればなるほど、データベースとアプリケー
ションの設計と実装のタスクがより容易なものとなります。
こうしたデータのモデル化とシステム実装のタスクは、OLAP Services と Oracle Express
とでは非常に異なっています。
我々のデータベースは、スノーフレーク スキーマとして既にデータ ウェアハウスに存在し、
ファクトテーブルにそれ自身の列として存在する各メジャーと、明確な 1 組のレベルを表す
各ディメンションが備わっています。更にこの場合においては、DSS Lab はメジャー内に階
層を作成することについては関心がありません。我々は、ディメンションとキューブの構造
について決定する必要があります。

ディメンション
アプリケーションの設計で最初に検討するべきデータベース構造は、ディメンションです。
ディメンションと変数は相補的なものであるため、どちらを最初に検討しても構いませんが、
一般にはディメンションから始める方が良いでしょう。OLAP アプリケーションの処理上お
よび操作上の大部分の構造は、ディメンションによって組織され、またこれを活用します。
ディメンションについて考える場合、論理モデルが OLAP システムでどのようにサポートさ
れているかに注意します。例えば、階層や追加メンバ情報 (データ ウェアハウスの用語で属
性) のサポート方法といったことです。
本アプリケーションは、製品および顧客ディメンションに対していくつかのテーブルを持っ
ているスノーフレーク スキーマをベースとします。いくつかのメンバに NULL が設定されて
いるメンバ属性がある一方で、ディメンションは SQL レポーティングを容易にするために、
明確に名付けられたレベルの中に既に手配されました。
スタースキーマは、次の 7 つのディメンションに対してディメンション テーブルを用意しま
した。そのディメンションとは、時間、顧客、製品、プロモーション、倉庫、支払い条件、
および返品理由です。またレポートでは、属性ベースの集計が (異なるメジャーセットに対
して) 次の 8 つの属性で行えるようになっていることが要求されます。その 8 つとは、顧客
の性別、学歴、子供の数、配偶者の有無、そして製品の構造、色、ケースサイズです。製品
ディメンションでは、製品のカテゴリとメーカーという 2 つの明確なレポーティング階層が
必要となります。時間軸をベースとしたレポーティングは、週と月-4 半期-年の集合を含
む必要があります。 ディメンション/階層毎のレベルの数は、倉庫などのディメンションに
対して 2 (リーフと「全部」) から、5 (製品-カテゴリ階層で) までの範囲です。

OLAP Services 論理仕様 – ディメンション設計
OLAP Services アプリケーションが扱うディメンションの主なタイプは、レギュラーとメジ
ャー1 です。OLAP Services は、レギュラー ディメンションをマルチレベルの階層構造と
して定義します。レギュラー ディメンションは、複数のキューブが共有できるように定義す
ることができ、共有されると、「適合したディメンション」のデータウェアハウジングコン
セプトにぴったりと合致します。これは我々のデータ ウェアハウスと論理定義に非常にしっ
くりと収まります。
OLAP Services では、メジャー ディメンションを除く全てのディメンションは階層的にな
っており、1 組のレベルに関して定義されています。そこではルートの下の各メンバは、ル
ートレベルに繋がる親メンバを持たなければなりません。 (こうした連結性の度合いは、デ
ータベースに常にあるわけではありませんが、今回のケーススタディでは当てはまります。)
我々の分析ディメンションも同じく階層的であるため、この重要なニーズを満たすよう、ツ
ールを直接利用できることになります。DSS Lab は全部で 7 つの論理ディメンションを定
義しました。その中には小さい論理ディメンション (6 つの支払タイプと、6 つの製品返品
理由、および 12 の倉庫) がある一方で、製品ディメンションは 1 万 4,500 種類の製品が収
容され、また顧客ディメンションは 150 万人以上に増大しました。
今回のアプリケーションでは、ディメンション、階層、および階層毎のレベルのセットに関
する必要条件がありました。ディメンションの内部ロジックと物理的な特性について何らか
の決断を下す必要がありましたが、ディメンションの構造についてはさほど多くの事項を検

1
    3 番目のディメンション型(バーチャル)については後述します。
討する必要はありませんでした。最初にディメンション設計の論理パートについて説明し、
次いで手順面について解説します。

メンバの識別
最初に検討を要したのは、メンバの特定方法でした。これはデータのロードや計算の実行、
およびクエリへの回答を行う際に、メンバの身元を照会するために必要となります。OLAP
Services は、メンバ名を内部 ID とは別にしています。その名前は、クエリにあるような文
字コンテキストで ID を定義するために用いられ、一方内部 ID は、内部コンテキストで用い
られます。この選択に対しては、物理的および論理的な意味合いの 2 つのコンポーネントが
あります。レベル毎に、その全メンバの ID (メンバキーと呼ばれる) が一意であるかどうか
について OLAP に指定することができます。そこで一意でなくても、親メンバの下で一意で
ありさえすれば問題ありません。キーがファクトテーブルの細かなレベルにおいて一意であ
り、なおかつファクトテーブルへの結合キーと同一である場合は、重要な最適化が行えるよ
うになります (「OLAP Services のプロシージャ-変数とキューブ」の節で説明) 。これと
は別に、MDX クエリやその他の文字参照で用いるための名前が識別キーと異なるかどうか
を指定することができます。
今回のデータベースでは、各ディメンションのメンバ行それぞれに対して、一意な整数 ID
キーを割当てました。これはメンバ名よりサイズが小さく、常に一意です。これについては
時間ディメンションでも同様としました。この事実の下、ウェアハウスデータベース ID キ
ーをメンバキーとして、またウェアハウスメンバ名をメンバ名として用い、メンバが各ディ
メンションの各レベルで一意であるように指定しました。例えば、各 SKU レベルのメンバ
は、データベース ID キーをその一意な SKU レベルのメンバキーとして設定し、その名前は
製品名を用いたり、また各ブランドレベルのメンバは、データベース ID キーをそのメンバ
キーとして設定し、その名前はブランド名を用いたりするなどでした。メンバキーには、レ
ベル単位でデータ型を割当てることができます。そこでメンバキーには基底になっているデ
ータベースキーのデータ型を与えましたが、たまたま例外なく整数となりました。メンバ名
は常にテキストで格納され、そのストレージに関する選択肢はありません。

階層と配列
2 番目に検討を要したのは、階層についてでした。時間ディメンションと製品ディメンショ
ンにそれぞれ 2 つの階層を作成する必要があった (時間ディメンションの 2 つは、週と月と
の間における不規則なマッピングを処理するためのもの) のですが、OLAP Services は、デ
ータベースのディメンション毎に階層を 1 つだけしか持てません。そこで、関連した名前を
持つ別々のディメンションに対して、クライアント レイヤで複数の階層があるかのように見
せかけます。単一の論理ディメンションにおけるこれらの別々の階層は、共通のメンバを持
つ必要は一切ありません (リーフレベルでも同様) 。複数のディメンションを複数の階層と
して表現するためには、ディメンション名にドット (’.’) を挿入する必要がありました。つま
り デ ィ メ ン シ ョ ン を 、 Time.ByWeek 、 Time.ByMonth 、 Product.ByFamily 、 お よ び
Product.ByManuf としたのです。 (特定の階層として用いられるディメンションを、階層-
ディメンションと呼びます。) これによって、メンバ属性とキューブを設計する際に扱う必
要のあるディメンションが 2 つ余分にできてしまい、ビジネス モデルとデータベース モデ
ルとの間に違いが生じました。
全ての単一階層のディメンションで必要なのは、レベルを識別することだけで、これによっ
てそれ以外のディメンションを処理しました。

時間ディメンション
OLAP Services では、任意または複数のディメンションに「時間」ディメンションとしてタ
グ付けを、またその内部のレベルには様々な時間レベル (週、年など) としてタグ付けを行
うことができます。これを用いるのは、クライアント クエリにデフォルト値を返すためだけ
で、どのディメンションにも「時間」としてタグ付けする必要は一切ありません。 OLAP
Services の時間ディメンションは、構成方法について、ともすればその他全てのディメンシ
ョンと同一になります。このため、そのメンバと階層的なリレーションシップを明示的に指
定しなければなりません。また任意のカスタムカレンダーを含むこともできます。キューブ
内の複数のディメンションが「時間」型としてタグ付けされると、クライアント クエリのデ
フォルトが、時間ディメンションが1つしかない場合のようにはうまく機能しないことがあ
ります。 (時間デフォルトに依存しないクエリは引き続き機能します。) 時間の階層-ディメ
ンションの内、時間ディメンションとして有効にタグ付けできたのは 1 つだけだったため、
それを区別するために Time.ByMonth を選択しました。

メンバの配列
全ての親の子は、相互と比較して配列されます。レベル毎に、メンバ名やメンバ「キー」
(これはメンバの特定に用いられる値) のいずれかを基準にして配列を決めることができます。
全体的には、これによって結果として、全ディメンションに対するトポロジ上の配列が定義
されます。この効果の1つは、各レベルのメンバが相互と比較した上で配列されるというこ
とです。非時間ディメンションでは、メンバを名前順で配列することにしました。その理由
は、最終的にクエリ結果の分析がより容易になるためです。唯一時間ディメンションだけが、
全体の配列が重要な検討事項となりました。これは時系列計算が問題となったのです。理想
的には各レベルを日付印でソートするように指定したかったのですが、整数 ID キーで識別
しました。しかし別個に配列している列に配列を指定することはできません。各レベル内の
メンバそれぞれに対して、各カレンダーレベルの ID 値を 1 ずつ増加しました。これによっ
て ID キーを日付印と全く同じ方法で配列しました。各時間ディメンションの各レベル内で
はキー順で配列することにしました。

ディメンションのサイズ
3 番目に検討を要したのは、ディメンションのサイズでした。我々のデータベースには比較
的大きい顧客ディメンションが含まれています (顧客数は 150 万人以上にまで増大) 。
OLAP Services は、非常に大きいディメンション (100 万人以上のメンバ) を処理すること
ができますが、親の下に持てる子の数には 6 万 4,000 という制限があります。顧客レベル
の分析を行いたいと考え、また我々のウェアハウス顧客ディメンションは顧客を市に直接配
置しています。幸運なことに、シカゴに 13 万 1,000 人、またマイアミとサンアントニオに
も同等数の顧客が設定されています。
これを扱うため、ダミーの市レベルメンバをいくつか設定し、それに適合するよう階層を変
更する必要がありました。またこれらのダミーを隠すためのストラテジについても決定する
必要がありました。それらのダイナミックな計算を後から作成し、クライアント レイヤで見
せかけのメンバを隠すよう試みることもできましたが、これでは具合が悪いため、その代わ
りに OLAP データベースに見せかけのレベルを加えて、この後に物理的な掛かり合いを処理
するというアプローチを取りました。この追加レイヤの内部にそれぞれ 2 件の追加メンバを
作成し、3 件のシカゴ関連メンバ、3 件のマイアミ関連メンバ、そして 3 件のサンアントニ
オ関連メンバとしました。 (これほど多くの顧客数を抱える市は他にはありませんが、長期
的には監視しておく必要があります。) このレベルは残念ながら全ての顧客に見えるように
なっていて、ディメンション内では配列が親の下に子が置かれた階層構造となるため、これ
らの見せかけのメンバがクライアントにおけるメンバのビューに影響を与えることになりま
す。顧客を名前 (顧客 ID) のアルファベット順でソートすると、ソートされた顧客セットが
「実際の」シカゴの下に 3 つ別々にできあがります。幸運にも、顧客 ID をレポートするこ
とはさほど面白いものではなく、エンドユーザーが見る際は、顧客名またはその他のプロパ
ティで増加、ソートされます。しかしクエリを組み立てる場合は、余分なレベル回避するよ
う注意を払う必要があります。
Express 論理仕様 – ディメンション設計:
Oracle Express でディメンションを設計したとき、1 組の異なる検討事項に遭遇しました。
これには主に次の 4 つの要因があります。
1. Express のディメンションは、本質的に単一レベルのオブジェクトです。Express は、
   ディメンションに内部構造 (階層を含む) を設けることのできる特別な構造と機能性を持
   っていますが、かえって開発者が考慮しなければならない事項が益々増えてしまうこと
   になります。
2. Express のディメンションにはデータ型があります (固定および可変文字列、整数、日
   付けなど) 。
3. Express で提供されるリレーションは、非常に柔軟な構造になっています。これによっ
   て任意のディメンションを、それ自身または任意の数のその他のディメンションに 1-N
   リレーションシップで関係付けることができるため、階層を作成することができます。
4. Express の変数 (後にキューブの説明で詳細に扱います) は、1 組のディメンションセッ
   トによってのみ、ディメンションを設定することができます。つまり、2 つまたはそれ
   以上の単一レベルのディメンションが、レベル分けされた階層に関係付けられている所
   では、変数はこれらのレベルの 1 つに対してのみ定義されます。これは、ストレージ設
   計や、キューブを構成する Express 変数の数の決定、およびディメンションの構造方法
   といったディメンションとキューブの設計に数多く関わってきます。
要因 1 と 4 が重なると、検討事項に多くの違いが生じます。
またコンジョイントやコンポジット ディメンションなど、Express ディメンションが有する
いくつかの特色についても扱う必要がありました。これらについては、その扱いと併せて後
述します。コンジョイントでもコンポジットでもないディメンションは、 ベーシックという
用語で表現します。

ディメンションと階層の表現
全メンバが階層に完全に結びつけられているレギュラー レベルからすると、我々のデータベ
ースのディメンションは既にモデル化されています。Express のベーシック ディメンション
は、配列された単一のメンバセットです。階層のモデル化には 2 つの別個の方法があり、そ
れぞれ異なるディメンションセットを導きます。ディメンションを 1 組決定するには、ディ
メンションと階層、そして変数がどのように相互に作用するのかについて理解しておく必要
があります。
Express 階層を構築する上では、リレーション データ構造の利用が鍵となります。リレーシ
ョンは、ベース ディメンションの各メンバをターゲットディメンションのメンバへとマッピ
ングすることで、ターゲットからベースへの 1-N リレーションシップを作成します。任意の
2 つのディメンションを関係付けることができるのはもちろん、リレーションは最初に指定
されるエンティティであるため、任意の 2 つのディメンション間に複数のリレーションを設
定することができます。また各レベルに別々のディメンションを持たせることもできます
(例えば、別々の SKU、ブランド、サブカテゴリ、カテゴリ、およびファミリのディメンシ
ョンで、論理製品ファミリ階層を構成) 。しかし、これら全てのレベルで販売データを格納
したい場合は、SKU-販売変数やブランド-販売変数などを作成し、また全体-製品値を保存す
る場所が欲しい場合は、1 メンバの製品-全体ディメンションを作成する必要があるでしょう。
時間ディメンションでも同一のアプローチに従えば、SKU-日-販売変数や、SKU-月-販売変
数など、それぞれ適切なディメンションを組合せて作成する必要があります。しかしこれは
維持していけるソリューションではありません。 (単に SKU-日データを格納し、要求に応
じてそれを集計することはできません。何故なら、各クエリに対応するには、あまりに多く
の集計を行う必要が生じるためです。)
ターゲットとベースのディメンションが同一 (セルフ リレーション) である場合、そのディ
メンション上のレギュラー階層またはイレギュラー階層は、単一のディメンション (埋め込
み-トータル ディメンションと呼ばれます) を用いて記述できます。Express のイレギュラ
ー階層は、任意に不規則な構成 (ルートメンバから数えたリーフメンバの深さに関して) を
取り、また分離される (メンバがより高いレベルまたはより低いレベルのメンバに結びつく
必要がないという意味で) ことができます。埋め込み-トータル ディメンションの全レベル
中のメンバは全て、それに関連する階層情報と共に、単一のディメンション構造の中に置か
れます。これにより、1 つの論理変数に対するデータを全て集計して単一の Express 変数に
関係付けることができます。その他にも重要な集計機能など、これらのセルフ リレーション
のディメンションだけを扱う機能セットがあります。こうした意味で、Express は必要な階
層を直接サポートしていますが、調整と保守の必要な追加オブジェクト (セルフ リレーショ
ンをはじめとして) も明るみに出ています。我々は、埋め込み-トータル ディメンションが
必要な集計機能を利用したかったため、また全てのデータを論理的に複数レベルの変数に格
納したいがために、データベースの全ての論理ディメンションを埋め込み-トータル ディメ
ンションとして実装することにしました。
Express リレーションは、それ自身を多次元とすることができます。これは通常 Express
に複数の階層を実装するために用いられ、ディメンションの階層セットをそれ自身のディメ
ンションとして表現します。例えば、PROD_HIER ディメンションは、‘Standard’ ( 製品フ
ァミリ毎にデフォルト階層を表現) と ‘ByManuf’ の 2 つのメンバを伴って作成されました。
‘ByManuf’ 階層-メンバに関連する製品セルフ リレーションは全てメーカー階層を表し、そ
の一方で ‘Standard’ 階層-メンバに関連する製品セルフ リレーションは全て製品カテゴリ
階層を表します。全てのメンバは Express ディメンションの中でただ 1 度だけ存在し、そ
れが何個の階層上に存在するかは関係ありません。我々のデータベース モデルには、論理ビ
ジネス モデルディメンションの階層を記述するための追加ディメンションが含まれています
が、各ビジネス モデルディメンションは、対応する Expresss ディメンションを、階層毎に
1 つではなく、ただ 1 つだけ持っています。

ディメンションのサイズ
Expresss ディメンションのメンバ数は 264-1 を上限としていますが、Expresss のディメン
ションまたはリレーションの中では、レベルの数や親毎の子の数に制限はありません。この
ため、顧客-市のリレーションシップを、見せかけの中間レベルやその他の構造を用いること
なく表現することができました。

メンバのデータ型
また、ディメンションの型を選択する必要もありました。Express のベーシック ディメンシ
ョンのメンバはデータ型があり、テキストや、ID (固定幅テキスト形式) 、整数、日付など
の型をユーザーが指定する必要があります。これは、メンバ名の付け方や、メンバをディメ
ンションに追加または削除する方法に影響を及ぼします。ID (8 文字の名前) のディメンシ
ョン型が最も効率的ですが、メンバを記述する追加データと一緒に用いられない限り、これ
はアプリケーションにとって最低限の表現方法となります。テキスト ディメンションは、そ
の幅を固定または可変とすることができます。表現と効率的に組合せるために、我々は各デ
ィメンションで固定幅のテキストを採用しました。固定幅のテキストは、可変幅よりも遥か
に効率的にアクセスできます。しかも名前に対する未使用スペースの量も所定の幅よりずっ
と少なくて済みます。しかし名前は 8 文字より長くしました。

時間ディメンション
時間ディメンションは、日、週、月、四半期、および年のレベルを持つことができ、一般の
時間基準と正確に対応します。Express は、周期や開始日に基づいて、これらのレベルを自
動的に相互に関係付けることができます。しかし、各時間レベルに対して日、週、月、四半
期、および年のディメンションを採用したとしたら、ここでも各時間レベル-ディメンション
に変数セットを 1 組ずつ、全部で 5 セットを作成しなければならなかったでしょう。そこで、
全ての適切なメンバと親子関係がリレーショナルデータベースの中で引き続き存在するよう、
時間ディメンションをテキスト ディメンションとして明示的に構築することにしました。

メンバの識別
Express はディメンション自身の中でメンバキーからメンバ ID を分離することはありませ
ん。通常、メンバ名はキーとして見ることができ、関連変数はより説明的な度合いの強い名
前を持つことができます。
データベースのキーは整数でしたが、整数のディメンション型は今回の目的には不適当です。
単にデータベースキーをテキストに変換しても、各レベルでキーの範囲が重複してしまうた
め、うまく機能しないでしょう。例えば製品ディメンションでは、それぞれ 100 のキーが設
定された SKU とブランドがありました。これらをテキストに変換すると共に、各レベルに
対してプレフィックスを用いて (例えば SKU は ‘SK’、ブランドは ‘Br’ として、‘Sku100’
と ‘Br100’ を作成) 、それぞれを一意に設定することもできたはずです。これが、実在する
SKU やブランド名と重複する名前をこしらえるシンプルな方法であると考えて、単にメンバ
名を Express の中の ID キーとして用いることにしました。

コンジョイントとコンポジット ディメンション
Express のベーシック ディメンションは、配列された 1 組のメンバセットです。ディメン
ションを分割するとその中のデータ量が希薄 (スパース) になりますが、この問題に対処す
るため、コンジョイントとコンポジットの 2 つのディメンション型が利用できるようになっ
ています。コンジョイント ディメンションは、1 つまたはそれ以上のディメンションで構成
され、その要素は、明示的に定義されたメンバをそのコンポーネント ディメンションのそれ
ぞれから組合せたものです。 (同じ組合せは 1 つのコンジョイント内で複数回存在すること
はできません。) ベーシック ディメンションのように、コンジョイント ディメンション内の
メンバは配列されています。コンジョイント ディメンション内のコンジョイントメンバは、
個別に、およびディメンション参照プリミティブによって参照することができ、ベーシック
ディメンションと同様に、コンジョイント ディメンションと他のディメンションとの間にリ
レーションを設定することができます。
コンポジット ディメンションは、そのコンポーネント ディメンション間で指名された連係
です。コンポジットの要素を明示的に追加したり、削除することはできません。というのも、
コンポジットは作成されると、コンポーネント ディメンションのメンバのあらゆる可能な組
合せを論理的に含むことになるためです。コンポジットは、物理デバイスとして主に存在し、
関連ディメンション全体に散在するデータのコントロールをサポートします。コンポジット
はそれ単独で論理構造として維持されることはほとんどないため、そこにリレーションを設
定したり、ディメンション参照プリミティブを用いてクエリをコンポジットの特定の範囲に
限定することはできません。
ディメンション型 (ベーシック、コンジョイント、コンポジット) の選択は、データベース
を構築する際にデータベース設計者が判断するべき基本的な事項であり、無視することはで
きません。計算およびクエリに関連して重要なそれぞれに対して、物理的およびプロシージ
ャ的な意味合いと可能性があります (ストレージの意味合い、要素の参照に用いられる構文
の種類、クエリの作成に用いられる構文の種類など) 。これらについてはそれぞれの項目に
おいて後述します。

比較:ディメンション設計
ディメンションについて論理的に検討するレベルでは、異なる機能セットを持つ 2 つの製品
に、いくつかの重要な共通点があります。
両製品とも、希望どおりに複数の変数セットで共有できるディメンションをサポートします。
これは、我々の環境で収集および分析するデータについて公正な概念モデルを形成する上で
重要な機能です。しかし、両製品の違いは、このポイントを過ぎて直ぐに明らかになります。
最も顕著な相違点は、本質的な構造にあります。OLAP Services は、本質的にマルチレベル
の階層構造となっている単一の論理ディメンション構成です。しかしそれは単一の階層に限
られ、その階層も整ったレベルで構成されていなければなりません。Express は、本質的に
シングルレベルの複数ディメンション構成です。しかし Express は、多数の階層と、更に任
意の不規則な階層で構成されているため、それらを扱うための機能サポートを加えました。
OLAP Services のディメンションを設計する際に、変数とキューブについて検討する必要は
ほとんどありません。実際に、我々が扱いたいと考えている変数をディメンションが実際に
組織化しているという情報を得る以外に、論理的または物理的においても、この時点で変数
について検討する必要は一切ありませんでした。
しかし、Express のディメンションを設計する際は、変数について様々な面を検討する必要
がありました。それは特に物理面において顕著で、ストレージの影響があったり、ある特定
の方法でディメンションが組織されていないとある機能が使用できないという事実などがあ
りました。異なる設計手段でコスト効果の高い分析を実現するためには、OLAP Services よ
りも更に程度の高い経験が開発者に求められ、また開発時間も長くなります。
全体的に、ディメンションの設計プロセスは、Express よりも OLAP Services の方が幾分
容易でした。というのも OLAP Services は、選択するべきものが少なく、リレーショナル
データストアのマッピングがより明確で、ディメンションの利用方法について必要な知識も
少なくて済んだためです。ただし OLAP Services で複数の階層を複数のディメンションと
して扱うことだけは、直観に反するように思えました。


判定基準                        勝者
複数の変数が論理的に共有するディメンション       (引き分け)
豊富な論理ディメンション構造              OLAP Services
変数とキューブ上の論理ディメンションの物理 OLAP Services
的な影響
複数の階層サポート                   Express


OLAP Services の手順 - データベースの初期設定とデ
 ィメンションの設計
データベースを初期設定してディメンションを設計するにあたっては、マイクロソフトが
OLAP Services に組み込んでいる OLAP マネージャ インタフェースを使用しました。
OLAP Services データベースは、ディメンションやキューブ、関連定義といった全ての
OLAP 関連オブジェクトを収容するコンテナとしての役割を論理的に果たします。各データ
ベースは論理的かつ完全に相互に独立しているため、アプリケーション プログラムを除けば、
データベースを相互に連動させることはできません。
データベースを初期設定するには、サーバーノードで右クリックします。コンテキスト メニ
ューが表示されたら、そこで「新規データベース」を選択し、次いでデータベース名を入力
します。OLAP マネージャを用いた場合は、ディメンションの作成と、それをソーステーブ
ルにリンクする作業が一緒に行われます。全体的に、各ディメンションに対するプロセスは
全て同一でした。

ディメンションの作成とテーブル リンクの確立
ディメンションの作成は、ディメンションウィザードインタフェースから行いました (操作
の順序はディメンションエディタインタフェースとほぼ同等) 。まず、テーブル、またはデ
ィメンションを形成するテーブルセットを選択しました。テーブルが複数あった場合は、テ
ーブル間を結合しました。次いで、ディメンションにレベルを加えました。各レベルに対し
て、メンバキーとメンバ名をデータベースの列にマッピングし、そのディメンションのメン
バを一意にするかどうかを指定しました。キーのタイプとサイズも選択できたのですが、
OLAP マネージャがデータベースからタイプを選定したため、それを変更する必要はありま
せんでした。
例えば Product.ByFamily ディメンションに対しては、レベルを設定する 5 つのテーブルを
選び出して、そのテーブル間に結合キーを指定し、次いで各レベルに対するメンバキーを形
成する列を選択しました。 (ウィザードで行えるのは、1 つの列を選択して、レベルを定義
することだけです。1 つまたはそれ以上の列から抽出する必要がある場合は、エディタでこ
れを変更します。) 次に OLAP Services はディメンションエディタへと進み、そこで名前の
微調整 (テーブル列上の名前をベースに) と各レベルに対するメンバ名列の設定 (デフォルト
ではキーと同じ) を行うと共に、メンバを一意とするオプションを「有効」に設定しました。
またディメンションエディタは、1つの「全体」メンバを持つディメンションに対してデフ
ォルトで「全体」レベルを1つ加えます。全てのディメンションに対してこの設定を使用し
ました。
1 箇所だけ、メンバ名として用いる列式を適用した所がありました。市テーブルの市名はそ
れぞれ、Portland や Springfield など、そのままの名前を用いました。市と州をカンマで連
結したビューを作成する代わりに、ディメンション定義でこの連結を指定しました。
OLAP Services では、テーブル内の列式がメンバ名を定義できます。このため、データベー
スの日付印をメンバ名に変換する式を利用することを検討に加えることができました。しか
し結局この機能は使用しませんでした。時間ディメンション テーブル内の名前が既に我々の
要件を満たすようフォーマットされていたためです。

ディメンション情報のローディング
各ディメンションの保存後、それを処理 (データを読み出して、OLAP Services のディメン
ションのバージョンを形成) し、完了しました。各ディメンションに対して更なる処理を施
しましたが、これについては後述します。
プロシージャ上は、こうしたディメンション定義は全てエディタ内だけでもできたはずです
が (あるいはカスタムプログラムを作成) 、各ディメンションに対して行った以上の作業は
必要ありませんでした。全ディメンションの初期定義に要した時間はおよそ 1 時間半でした。
またディメンションのローディングにおよそ 10 分を費やし、その内 7 分 39 秒はカスタム
ディメンションの初期作成でした。

Express の手順 - データベースの初期設定とディメンシ
  ョンの設計
Express は、データベースの操作用として 2 つの主要なインタフェースを備えています。1
つは Express Administrator GUI。もう 1 つはコマンドインタフェースで、それ自身はも
ちろん Administrator 内からもアクセスできます。コマンドラインインタフェースからデー
タベース全体を定義することもできましたが、Administrator を用いてディメンションを作
成すると、数多くのサポート構造が追加されます (階層-ディメンション、レベル-ディメン
ション、および関連機能などの構造で、埋め込み-トータル ディメンション内でのナビゲー
トと参照をサポート) 。そのため、今回は Administrator を使用することとしました。
Express データベースは、ディメンションや変数、公式、およびプログラムといったデータ
ベースオブジェクトを収容するコンテナとしての役割を果たします。OLAP Services とは異
なり、1 つのデータベースのオブジェクトは、他のデータベースのオブジェクトと相互に連
携することができます。例えば、あるデータベース内に作成されたプログラムが、他のデー
タベース内のディメンションやオブジェクトを参照することができます。ある特定のディメ
ンションで組織されている全てのオブジェクト (つまりキューブやその他の計算オブジェク
ト) は、そのディメンションとして同一のデータベース内で定義されなければなりませんが、
その境界を結ぶ方法があります。この特定のアプリケーションでは、全てのオブジェクトを
単一のデータベースに置くこととしました。
データベースの初期設定の手順として、ファイル | 新規データベースを選択し、データベー
スの名前とディレクトリを入力するなどしました。

ディメンションの作成
各ディメンションの作成は、データベースブラウザのディメンションノードで右クリックし、
コンテキスト メニューから「新規…」を選択して行います。ディメンションのデータ型とし
てテキストを選択し、またそれぞれのサイズと、ディメンションプレフィックスを選択しま
した。ディメンションプレフィックスは、Administrator が作成する関連オブジェクトの全
てに対する名前の一部として使用されます。Express 内のオブジェクト名は最長 16 文字に
制限されているため、プレフィックスはこれに従って短くなります。
作 成 し た 分 析 デ ィ メ ン シ ョ ン の そ れ ぞ れ ( 時 間 、 顧 客 な ど ) に 対 し て 、 Express
Administrator は 2 つのディメンションを追加作成しました。 (ディメンションのディメン
ションプレフィックスは xx とします。) 1 つ目のディメンション xx.hierdim は、自身のデ
ィメンション上に作成されている階層のリストを、また 2 つ目の xx.leveldim は、自身の全
階層にある全てのレベルを、それぞれ自身のメンバ用として持っています。
Express Administrator はまた、いくつかのメタデータ変数を作成します。プログラマが使
用するのは次の 3 つです。
   xx.leveldepth (階層とレベル毎) -各レベルに対するルートからの深さを保持
   xx.leveldesc (レベルと言語毎) -レベルの説明
   xx.order (ディメンションとその階層毎) -ディメンション メンバの配列を表現
Express はまた、レベルディメンションに関係付けられた xx.levelrel という名前のメタリ
レーションを作成します (ディメンションとその xx.hierdim ディメンション) 。これによっ
て各メンバをそのレベルへと関係付けることができます。メンバをディメンションにロード
する際は、これらの種々の抽出されたリレーションと変数を再計算する必要があります。

テーブル リンクの確立
こうしたプロセスを経てディメンション定義を作成しましたが、ディメンションをテーブル
へと結びつけたり、そこにメンバを入れたりする作業は一切ありませんでした。Express デ
ィメンションとそのリレーションは、完全にそれ自体で定義されます。そこにデータを入れ
るためには、手作業で全ての値を入力するか、あるいは SPL プログラムを作成して情報をロ
ードするか、どちらかを実行する必要があります。そのため、データベースへのリンクは、
手順を踏んで行われます。

メンバの配列と効率
ロードプロセスを設計する際に、各ディメンジョンにおけるメンバの配列に注意する必要が
ありました。前述のように、ディメンションは配列された 1 組のメンバセットです。この配
列は、データのローディングとクエリの実施にとって重要な意味を持つことがあります。と
いうのも、そのディメンションを利用する変数に対し、配列がデータの物理的なレイアウト
を部分的に定義しているためです。ディメンション内の最初や最後、あるいは中間辺りにメ
ンバを加え、ディメンションのメンバは後から任意に格納することができます。
自動ローディングを行うには、優れたパフォーマンスを発揮するためのある簡単なテクニッ
クが必要でした。我々の環境で多勢を占める動作の特質は、セルデータのローディングと検
索を行うことです。そこである 1 つのレベルで全てのディメンション値を加えてから、次の
下位レベルに対してディメンション値を加えることとしました。1 つのレベルの中でのディ
メンション値の配列は、例えば「親の親」、それに続いて全ての親、更に続いて全ての子と
いった順序に合致するよう設定されています。こうした配列は、ロールアップまたはドリル
ダウンで発生するページングを最小限に抑えることに役立ちます (少なくともディメンショ
ン値の初期セットに対して) 。時間ディメンションの複数の階層もまた同様に、この原理に
従って、各レベルで時系列の順序でロードすることができます。製品ディメンションでは、
配列する階層としてカテゴリ階層を任意に選択し、またメーカー階層は比較的未整理のまま
にしておきました (ただし 2 つの階層における SKU の間では引き続き適正な相互関係を維
持) 。設定されている主キーを用いて、一貫した配列を保証しました。
全てのディメンション値のロードは、ディメンションでのリレーション設定前に実行しまし
た。これは、値の初期セットに対して連続したストレージを確保し、ディメンションの処理
効率を高めるためです。

一括ロードの構造とプログラムの実装
Express Administrator は、フラットファイルからディメンションを構築できるよう、ロー
ダープログラムを作成するウィザードを備えています。しかし、リレーショナルデータスト
アからディメンション (またはその他のエンティティ) を作成するためのウィザードや他の
支援ツールは一切ありません。我々の OLAP システムは1つのリレーショナルデータベース
から調達したため、ローディングを行う独自のプログラムを作成しなければなりませんでし
た。このプログラムの開発にあたっては、SQL のコーディングを含め、コーディングとテス
ト、およびデバッグを行う必要がありました。
非メジャー ディメンションとそのリレーションをロードするプログラムは全部で 1,800 行
に及びました。このコードは、SQL クエリ、エラーチェックコード、ディメンションとリレ
ーションを作成する実際のステートメント、そしていくつかのコメントライン (15 行のコー
ド毎におよそ 1 つのコメント) などが含まれたものです。ディメンションの初期作成と増分
更新 (例えば新規顧客のみの読み取り) の両方を処理する単一のプログラムセットが作成さ
れました。データベースの初期作成に続いいて、これらのプログラムは、将来の運用では新
規ディメンションレコードの追加だけが行えるようエディットしました。
ディメンションの設計、およびディメンションとそのリレーションをロードするプログラム
の設計、実装、テストに、丸 3 日に相当する時間を要しました。

比較:ディメンションの作成と設置
ディメンションを設計し、これをデータ ウェアハウスへと結びつけるプロセスは、製品によ
って全く異なります。
OLAP Services では、ディメンションの設計とこれを基底の RDBMS へ結びつけるプロセ
スは同一となっています。GUI は、ディメンション構造の制約の範囲内で、ディメンション
設計とテーブル リンクの作成の両方で利用可能なオプションをカバーします。名前とキーの
テーブル列へのマッピングは、ある程度柔軟に行えます。リンクについては完全な定義が必
要となります。そのため、結果として得られるディメンションの物理面に影響を与えること
はありません。また、テーブルに結び付いていないディメンションを定義することはできま
せん。ユーザーがディメンションを追加または変更できる環境では、基底のテーブルを変更
する外部ロジックを組み込む必要があります。
Express では、ディメンションはデータベースに独立して存在し、データソースとしてのテ
ーブルに依存する必要はありません。テーブルとディメンション間の結び付きを定義するプ
ロセスは、全体的に手作業で行われ、プログラムのコーディングを伴います。今回のような
大規模データベースでは、最大のパフォーマンスを引き出せるよう、内部ストレージと処理
動作について理解しておく必要があります。
Express では、論理ディメンションの作成に伴う副産物として、更に多くの支援ディメンシ
ョンとリレーションを作成しました。これらを維持して利用する必要があります。これらの
ディメンションの大部分は、保守が不要です (例えば、時間レベルの数を変更することはま
ずありません) 。しかし、16 文字の制限のあるグローバルネーム領域が唯 1 つだけあるため、
ディメンションとリレーションを管理し、特定の使用に対して適切なものを選択するタスク
は、プロセスの中で比較的困難になります。
全体的には、ディメンションを実際に実装、設置するプロセスは、OLAP Services の方がシ
ンプルです。ディメンション定義への GUI サポートは、ほぼ同等です。しかし Express で
もプログラムの設計と開発に 1 日半を要し、これに伴って Express がディメンションに対
してキューブを内部的にどのように組織しているのか、そして計算でどのようにキューブが
使用されるのかについて理解する必要がありました。


判定基準                      勝者
基底テーブルへのリンクの容易さ           OLAP Services
テーブル構造に対するディメンションの独立性     Express
論理設計と実装設計の差異の僅少性          OLAP Services
ディメンションの開発とツールへの実装に要す OLAP Services
る時間


OLAP Services 論理仕様 – メンバ属性
今回のアプリケーションにおいて、我々はメンバだけでなく、メンバ属性についても提供す
る必要がありました。属性の利用方法は次の 3 つ、すなわち、クエリ結果での表示、クエリ
におけるメンバセットの選択の支援、およびレポートでデータを集計する基礎として利用す
ることです。例えば、製品ディメンションの SKU レベルでは、色および構造属性がありま
す。レポートの中には、構造のクロスタブを色によって指定するものがあります。データベ
ースにおけるメンバ属性のサブセットだけが、OLAP システムに実際に格納されます。

レベルに関連付けられたメンバ属性
OLAP Services は、メンバ属性 (メンバプロパティと呼ばれます) をディメンションのレベ
ルに関連付けます。各レベルはそれ自身の属性セットを持つことができると共に、異なるレ
ベルに同一の名前を持つ属性を与えることができます。全てのメンバ属性は、文字列値とし
て OLAP Services ディメンションストレージに格納されます。それらは文字列として保持
されますが、計算を行う際は数字やその他のデータ型に変換することができます。例えば、
SKU レベルにおけるケースサイズのメンバ属性は 10 進数として格納されていますが、
OLAP Services ではこれを文字列としてのみ処理します。メンバ名やキーのように、メンバ
属性値を列式から抽出することができます。顧客ディメンションでは、例えば苗字と名前を
カンマで連結することで、顧客名属性を作成しました。それ以外は、単に属性を定義して、
列に値を挿入しました (顧客の配偶者の有無や、子供の数、人口統計/ライフスタイルコード、
製品構造、ケースのサイズ、色など) 。

仮想ディメンション:総計で用いる属性
OLAP Services では、メンバ属性をレポートの集計と分析に用いることができるよう、マイ
クロソフトがバーチャルディメンションと呼んでいるものを作成することができます。バー
チャルディメンションは、レギュラー ディメンションのメンバに代替集計パスを提供し、ク
ライアントアプリケーションとアプリケーションデザイナはこれを独立したディメンション
として、ベースとなっているディメンションと共に使用することができます (メンバ属性列
もそれ自身のレギュラー ディメンションのベースになり得ることに注意してください) 。バ
ーチャルディメンションには次のようないくつかの重要な制限があります。すなわちバーチ
ャルディメンションでは、全てのレベルとリーフレベルを列挙された属性値でしか構成する
ことができない、メタデータにおいて属性から関係メンバへと掘り下げる手段がない、そし
てメンバ数に 760 の上限値があるなどです。今回は顧客ディメンションですらも、総計して
この限界を越えるような属性は全くありませんでした (例えば 51 のライフスタイルコード
と、3 つの配偶者状況など) 。集計するべき属性に対してマルチレベルの階層形式を取らせ
る唯一の方策は、クライアントプログラムが各ディメンションを階層の 1 つのレベルとして
提示することです。例えば、ライフスタイルコードから配偶者状況へと降りる 1 つの階層形
態を作成するためには、ライフスタイルレベルのセルが内部的にライフスタイルとして全体-
配偶者状況スライスから参照されることになる一方で、ライフスタイルに対して配偶者状況
へと掘り下げると、配偶者状況のそれぞれがそのライフスタイルを参照することになります。
バーチャルディメンションの主な利点は、ディメンション自身が占有するストレージの量が
極めて小さく、キューブにおいてもストレージを作成することにはならないことです。 (そ
の代わり、このディメンションからメンバを選択するクエリに対する応答時間が長くなりま
す。)

複数の階層-ディメンション内のメンバ属性
複数のディメンションとして複数の階層を設定している場合、メンバ属性の設定にやや問題
が生じることがあります。例えば、製品について 2 つの異なる階層があり、必要な属性とし
て色、ケースサイズ、構造、および出荷従量が設定されています。クライアントアプリケー
ションからどちらか一方の階層の色または構造にアクセスできるようにするためには、双方
の階層に別々に属性を加える必要があります。更に、2 つのディメンションから任意に 1 つ
を選び、これをバーチャルディメンションのベースとするか、あるいは複数の冗長バーチャ
ルディメンションを作成するか、どちらかを行う必要があります。今回の環境では、この問
題については明快な解決策がありました。Product.ByFamily と Product.ByManuf ディメ
ンションの両方の SKU レベルについてメンバプロパティを定義したことで、SKU レベルの
クエリが正しく機能できました。全てのキューブが製品階層を用い、また今回のケースでは
各階層の SKU レベルはそのメンバが同一です。そのため、我々は Product.ByFamily メン
バプロパティに関してバーチャルディメンションを定義しました。

Express 論理仕様 – メンバ属性
Express は、ディメンション、変数、およびリレーションの 3 つの論理構造となっています。
メンバ属性は本質的に 1 次元変数ですが、時に多次元として取り扱いたい場合があります。
Express では、メンバ属性をディメンションまたは変数のどちらにするかを選択する必要が
あります。
この選択は、メンバ属性をどのように活用したいかによって左右されます。属性の値を格納
し、それをクエリで検索するだけであれば、変数としてメンバ属性を実装できます。またメ
ンバ属性毎に集計したい場合や、メンバ属性に基づいて効率的にメンバを選択したい場合は、
ディメンションとして実装し、そのメンバ値を関連ディメンションに関係付ける必要があり
ます。 (メンバ属性を変数とディメンションの両方として実装しても問題ありません。)
我々が OLAP システムへ組み込みたいと考えている属性のそれぞれは、全て集計に利用され
ます。そのため、属性をディメンションとして実装し、これらのディメンションとベース デ
ィメンションの間にリレーションを設定しました (顧客と製品) 。基底となっているデータ
ベースにテキストとして格納されている属性 (配偶者状況、子供の数、色、構造など) に対
しては、単にテキスト ディメンションを作成しました。ケースサイズと出荷従量の属性は、
基底データベースでは数値として格納されました。つまり、Express は値が実数のディメン
ションを持たず、その整数ディメンションは、ばらばらの整数値セットを保持するようには
設計されていません。そのため、これらをテキストに変換して、同じくテキスト ディメンシ
ョンに格納しました。
Express データベースのリレーションは、属性定義の一部として Administrator からタグを
付けることができます。これについて Express サーバーでの使用方法は文書化されていませ
んが、Express ディメンション メンバセレクタ GUI からこれを用いて、メンバを関連属性
値に基づいて選出することができます。
変数とキューブ
ディメンションで組織化されるデータを論じる上では、変数とキューブを区別することとし
ます。変数 (データウェアハウジングの用語ではメジャーとも呼ばれます) は、ディメンシ
ョンで組織化された個々のデータ型のことです。一方キューブは比較的大まかに定義された
コンセプトで、複数の変数を含んでいる場合もあれば、含んでいない場合もあります。
今回の環境の論理モデルでは、種々の変数セットが種々のディメンションセットによって自
然に組織化されています。例えば、販売は製品、顧客、時間、プロモーション、および支払
タイプで、また在庫は倉庫、製品、および時間で編成されています。これらはファクトテー
ブルによってそれぞれ表現されています。
OLAP Services と Express はどちらも、必ずしも全ての変数に対して単一のディメンショ
ンを作成する必要はありません。
SQL Server 7 はテーブル内での物理的なパーティション分割をサポートしていないため、
我々のデータベースでは販売と返品をそれぞれ年毎に 1 つのファクトテーブルに分割してい
ます (tx_returns1996、tx_returns1997 など) 。在庫に関する全レコードが格納されてい
るのは在庫テーブル 1 つのみです。

OLAP Services 論理仕様 – 変数とキューブ
変数
OLAP Services では、変数 (メジャーと呼ばれる) は数値として内部に格納されます。変数
は、4 または 8 バイト整数、4 (単精度) または 8 バイト (倍精度) 浮動小数点、あるいは 8
バイト値の形態を取り、日付印として解釈されます。各メジャーのデータ型は、他のメジャ
ーのデータ型と無関係であるため、適宜異なる型を使用することができます。
今回は、ユニットメジャーなど、各キューブのメジャーそれぞれのデータ型として、倍精度
浮動小数点を指定しました。

キューブ構造
一般に、同一のディメンションが設定された変数セットは、結局単一のキューブとなります。
(これはまた、単一のファクトテーブルまたはファクトビューを介して利用できる変数によっ
て異なる。) OLAP Services のキューブは、1 つまたはそれ以上の階層的なマルチレベルデ
ィメンションによって組織化されている 1 組のメジャーセットの論理的な集合です。
OLAP Services は実際には、レギュラーとバーチャルの 2 つのキューブ型を定義します。
レギュラー キューブは、格納データを保存する場合があります。またバーチャル キューブ
は、レギュラー キューブに関して定義され、それ自身では格納データを持ちません。その代
わりに、基底となっているレギュラー キューブの一種の結合ビューとして機能します。各キ
ューブ (レギュラーとバーチャル) は、そのキューブに対して定義されている全メジャーセ
ットを含むメジャー ディメンションを持ちます。
ディメンションは 1 組のレベルと共に定義できますが、それを使用するキューブは全て、そ
の 1 組のレベルのサブセットしか表示できません。 (任意のサブセットではなく、任意のレ
ベルからその下のリーフレベルまでのレベルが、キューブでは使用されないままになりま
す。) バーチャル キューブは、ディメンションレベルに関して、そのベース キューブが用い
るレベルとは別にそれ自身の定義を持つことができます。
ロジスティクス上の面では、在庫は週単位でのみレポートされるため、時間ディメンション
の日レベルを在庫キューブに含めることは意味がありませんでした。そのため、各在庫キュ
ーブで日ディメンションを無効にしました。これらのキューブに関する限り、最も低位の時
間レベルは、Time.ByWeek ディメンションでは週に、そして Time.ByMonth ディメンシ
ョンでは月となりました。
キューブ計算フロー
本環境では、販売、返品、在庫の分析をサポートするためのベーシックキューブが必要です。
最初の検査によって、販売と返品それぞれで単一のベーシックキューブが必要になることが
判明します。それらのメジャー (ユニット数、総販売量、総返品量) は、時間を含めた全て
のディメンション上での総計となります。論理的に在庫変数は単一のキューブを形成するも
のですが、後述するロジスティクス上および物理的な理由のため、在庫を 1 組のキューブセ
ットに分割しました。
各キューブ内で、OLAP Services はメジャーの定義に基づいて自動的に入力メジャーを集計
します。集計の物理的な性質についてはデータベース管理者がコントロールすることとなり
ますが、アプリケーションにとっては、集計は自動かつ透過的に行われます。その他全ての
計算は、集計に基づいてクエリ時に実行されます。
ベースメジャーは、キューブが使用する全ディメンションのリーフレベルで入力されなけれ
ばならず、また任意のより高位のレベルでの集計として表示されます。使用できる関数は、
SUM、COUNT、MIN、および MAX のみとなっています (これは、OLAP Services アーキ
テクチャがこれらの相互的かつ分配的な性質を利用しているためです) 。
在庫キューブの設計にあたっては、在庫変数の性質を検討する必要がありました。変数の中
には、時間の経過に沿って増加する変数 (追加点数、出荷点数) がありますが、それらをキ
ューブへマッピングするのは難しくありません。その他の変数は時間が経過しても総和が取
られることはありません。これらに対して必要となったのは、期間終了値をサポートするこ
とでした。時間階層を用いてある 1 ヵ月をその決算残高に関係付けるという方法があったも
のの、満足のゆく選択肢でありませんでした。それをサポートするためには、日レベルを月
間在庫に含ませると共に、月の最後の 7 日間から適切な決算日を定める必要があります。
(クエリ式でこれを行う方法は複数あります。) 各月をその月の最終週に関係付けるマッピン
グテーブルを別々に用意し、月間在庫変更キューブから独立した月間在庫状況キューブ (各
月の週全体でレコードの集計だけを実行) を作成することは、遥かに簡単に行えました。た
だしこれには妥協が伴い、月および四半期レベルにおいて、月の最終週および四半期の最終
週が読み込まれるまでは、決算残高が集計できません。少なくとも、月毎の時間に対して、
そしてまた週毎の時間に対しても、状況と変更の別々のキューブが必要となりました。また
週毎および月毎の状況キューブを別にする必要がありました (月の決算週のマッピングに起
因して) 。週毎および月毎の変更キューブは、ファクトレコードが正確に集計されるよう、
同一のキューブに含める候補として挙がっていました。

Express 論理仕様 – 変数とキューブ
変数
Express は、変数のデータ型として 4 バイト整数、2 バイト整数、4 バイト浮動小数点、8
バイト浮動小数点、論理、テキスト文字列、および日付をサポートします。各変数は、それ
ぞれ異なるデータ型を取ることができます。変数の主な用途は、幾つかのディメンションセ
ット毎にデータを組織化することですが、変数はディメンションを利用する必要はなく、こ
の場合も典型的な 3GL の変数とほとんど同じように機能します。

キューブ構造
Express では、キューブは本質的にディメンションセットによって組織される Express 変
数またはフォーミュラです。 (フォーミュラは計算されるだけであるのに対して、変数は格
納されます。これについては後述します。) 任意の変数とフォーミュラを、計算またはクエ
リで一緒に用いることができ、その際に統一構造を定義する必要もありません (OLAP
Services ではバーチャル キューブが必要でした) 。これらは共通のディメンション上で自
動的に結合します。
キューブは、Express 変数で単一の論理変数を表現するために定義されることもあれば、単
一の Express 変数で関連する論理変数セットを表現するために定義されることもあります。
その場合、明示的なメジャー ディメンション (つまり「勘定科目」ディメンション) は、そ
のキューブに対するメジャーを列挙します。メジャー ディメンションは、任意の数のキュー
ブ同士で共有できます。Express アプリケーションにおいては、開発者の作業項目の一つと
して、同一のディメンションが設定された同一データ型の Express 変数セットを、同一のデ
ィメンションが設定された変数セット、あるいはメジャー ディメンションを用いる 1 つの変
数として実装することについてモデル化する方法を決定しなければなりません。例のごとく、
その決定に伴って、利用できるパフォーマンスセットが犠牲になります。つまり、独立した
変数が多くなればなるほど、特にそれらが一緒に用いられる傾向がある場合、アクセスと計
算のパフォーマンス低下が著しくなります。それとは対照的に、一緒に用いられる傾向にな
ければ、パフォーマンスが向上します。しかし、各 Express 変数は単体で存在します。その
ため、OLAP Services の「メジャー ディメンション」に相当するような、類似したディメ
ンションが設定された Express 変数セットを収集する方法はありません。
For our implementation, since we had multiple measures per logical cube, we
created 今回の実装では、論理キューブ毎に複数のメジャーを取り入れたため、各メジャー
セットに対してメジャー ディメンションを作成しました (埋め込み-トータルモデルに続い
て) 。例えば、Meas_Sales ディメンションは、時間、顧客、製品などに加えて、このディ
メンションで用いられる「ユニット」、「トータル」、および販売変数が含まれています。
同一のディメンションを設定した UnitsSold と TotalSales の別個の変数を作成することも
できましたが、パフォーマンス上の理由からこれらを統合しました。在庫の場合は、時間の
経過に伴って増加する追加的なメジャーもあれば、そうでないものもあり、またそれぞれに
対して別々のストレージを用いたかったため、メジャーセットを分割し、在庫キューブに 2
組のメジャーセットを持たせました。これは OLAP Services の実装で採用したアプローチ
とほぼ同等です。
Express で変数のディメンションを定義することは、ある非常に重要な物理的な意味合いが
あります。初期設計段階において、それらのディメンションを扱う必要はありませんでした
が、事前に変数を実装しなければなりませんでした。

Express 変数におけるディメンションの配列と希薄性
Express の変数定義におけるディメンション配列の問題は、それ単体で取り上げるべき重要
なトピックです。Express で採用されている MOLAP ストレージは多次元アレイ概念に基づ
くもので、1 つの 1 次元アレイストレージにマッピングされます。データをこれらのアレイ
にパッキングすることは、ストレージ領域とクエリ/計算時間の両面で優れた効果を達成する
上で、重要な機能となっています。Express 変数を定義する際、それに対してリストされて
いるディメンションの配列が、1 次元アレイにマッピングされる複数のディメンションの配
列を定義します。リスト中の最初のディメンションが最も速く反復するディメンションで、
その次のディメンションが 2 番目に速く反復、以降も同様ということになります。これによ
って幾つかの重要な結果が導かれます。最初に、計算に 2 つの変数が伴う場合、ことによる
と 3 番目の変数が割当てられ、同一配列のディメンションと異なる配列のディメンションと
の差異が、数桁にのぼる可能性があり、RAM に収まる関与変数量によって左右されます。こ
れは、Express の内部反復が物理的な配列によって制御されているためです。その結果、ア
プリケーションのディメンションは、おおよそ標準的な配列となります。例えば、通例メジ
ャーが最初のディメンションで、その次が製品、次いで顧客、次に倉庫、それから時間とい
う順序になります。
これとは別に、データベースの密度希薄性のパターンを理解することも重要です。キューブ
によっては、あるディメンションの組合せが、別のディメンションの組合せと比較して希薄
である場合があります。一般にパフォーマンスが最高となるのは、リストの記載が変数に対
して緻密なディメンションから (より素早く変化) 希薄なディメンションへという順番にな
っている場合です。 (これが、通常メジャーが最初にリストされる理由です。今回のアプリ
ケーションのキューブと同様に、時としてそれだけが緻密ディメンションとなります。) コ
ンポジット ディメンションは、共通部分が希薄と見込まれるディメンションの集合です。複
数の変数やリレーションは、希薄性のパターンが同じである場合、同じ名前が付けられたコ
ンポジットを共有するべきです。変数とリレーションは、単に希薄ディメンションを持つも
のとして作成される場合があり、それによってフードの下にアノニマスコンポジットが作成
されます。コンポジットは、それ自身ではディメンションとして論理的にほとんど成り立た
ず、主に希薄な組合せを定義するために存在します。データベースの実装に先立って、適切
なコンポジットセットを決定する必要があります。こうした余分なステップを踏むには、デ
ータベースの操作とデータパターンの両方についての知識が求められます。
今回実装したベーシック変数は、Sales (販売) 、Returns (返品) 、Inventory_Agg (在庫
集計) 、および Inventory_NonAgg (在庫非集計) で、これらに対するメジャー ディメンシ
ョ ン は 、 そ れ ぞ れ MEAS_SALES 、 MEAS_RETURNS 、 MEAS_INV_AGG 、 お よ び
MEAS_INV_NONAGG でした。各 Express 変数の未加工ディメンションは次のとおりです。
変数                 ディメンション
Sales               Meas_Sales, Time, Years, Product, Customer, Promotion,
                   Paym_Method
Returns             Meas_Returns,   Return_Reason    Paym_Method   Product
                   Customer Time Years
Inventory_Agg      Meas_Inv_Agg Warehouse Product Time Years
Inventory_Nonagg   Meas_Inv_Nonagg Warehouse Product Time Years

販売と返品は全体的なディメンション領域に関してそれぞれ希薄です。非メジャーの任意の
組合せにとっては、メジャーは緻密ですが、その他全てのディメンションは相互と比較して
希薄となります。アクティブと見なされる全ての SKU が毎週それぞれの保管倉庫のデータ
ウェアハウスに記録されると、在庫はより緻密になります。
変数毎に、ディメンションにどんな配列を割当てるべきでしょうか?クエリにとってベスト
な配列について、我々は優先順位の推定すらできません。しかし、我々はデータのローディ
ングから開始することができます。定期的にデータのバッチをロードし、データのそれぞれ
のバッチは特定範囲の時間と緊密に相関するでしょう。他のディメンションの内部深くに時
間をネストしたら、ロードされるデータに対する場所の一貫性がほとんどなくなります。そ
のため時間 (年とサブ年時間) を最も外側に移す必要があります。一方メジャーは変数毎に
緻密となるため、最も内側に置かれます。それ以外は、任意に選択できます。そのため、次
の配列をディメンションに割当てました。
変数                 ディメンションの配列
Sales              Meas_Sales Paym_Method Promotion Product Customer Time
                   Years
Returns            Meas_Returns Return_Reason Paym_Method Product Customer
                   Time Years
Inventory_Agg      Meas_Inv_Agg Warehouse Product Time Years
Inventory_Nonagg   Meas_Inv_Nonagg Warehouse Product Time Years

ようやく非メジャー ディメンションからコンポジット ディメンションを作成しました。
Rollup コマンド (Express の本バージョンにおける唯一のガイドライン) による集計パフォ
ーマンスが最大となるのは、変数毎にコンポジット ディメンションが 1 つだけある場合です。
単にこれらのディメンションをスパースとなるよう宣言し、次いでその希薄性の処理を透過
的に行うこともできましたが、割当て操作 (変数の計算に利用) がより一層極めて効率的に
行えるのは、名付けられた1つのコンポジットを操作で使用する場合です。我々は、増分ロ
ーディングにこの操作を用います。また我々は、データ集計の際に在庫変数が希薄性の種々
のパターンを共有することについても検討しました。時間の経過と共に加算される変数は、
そうでない変数において共有されない集計セルを持ちます。そのため、名付けられた 4 つの
コンポジットを作成し、内 2 つの在庫コンポジットは、同一のディメンションを持ちます。
コンポジット名             ディメンション (配列順)
Salesc_Mopcty       Paym_Method Promotion Product Customer Time Years
Returnsc_Rmpcty     Return_Reason Paym_Method Product Customer Time Years
Inventoryc_Wpty     Warehouse Product Time Years
Inven_Na_C_Wpty     Warehouse Product Time Years

そして最後に、変数は次のように定義されました。
変数                 ディメンションの配列
Sales              Meas_Sales   Salesc_Mopcty< … >
Returns            Meas_Returns   Returnsc_Rmpcty< … >
Inventory_Agg      Meas_Inv_Agg   Inventoryc_Wpty< … >
Inventory_Nonagg   Meas_Inv_Nonagg   Inven_Na_C_Wpty< … >

(コンポジットを用いて変数を定義する場合は、コンポジットのディメンションをリストア
ップしなくてはなりません。これについて上の表では省いていますが、< … > でリストされ
ている所を示します。)
重要な点として、ディメンション定義の後、そして変数の作成前に、我々は各変数の希薄性
パターンと、データのロード順、クエリに関するあらゆる情報、そしてデータを計算するプ
ロセスについて検討する必要がありました。これには全面的に、データ、アプリケーション、
Express を理解する上で徹底した知識が必要でした。

キューブ計算フロー (変数とフォーミュラ)
Express 変数はデータを格納するだけのもので、様々な方法で計算することができます。そ
の方法については、本書で後述します (Express の計算概要のセクション) 。データは、変
数内部の任意の場所に入れることができ、また計算結果として変数の任意のセルに格納する
こともできます。フォーミュラは、データの計算のみ行います。

Express フォーミュラ
Express フォーミュラは、その値が参照される時にのみ動的に計算が行われる数式です。セ
ル値の計算に用いられる場合、フォーミュラはキューブのビューと、1 つまたはそれ以上の
キューブの操作について描写します。フォーミュラの定義は、結果のディメンションを定義
します。フォーミュラは何度も階層化することができます。この機能によって、精密な結果
と複雑度を達成することができます。
Express フォーミュラの重要な特長の 1 つは、キューブ結果の計算だけでなく、様々な状況
で利用できることです。アプリケーションで頻繁に見られる利用の 1 つは、メンバ名セット
を計算することです。

比較:変数とキューブの設計
これら 2 つのシステム間において、一般に用いられているデータ型はほぼ同等です。重要な
点として、OLAP Services は、4 バイト整数が場合によってはオーバーフローすることがあ
るため、8 バイト整数をサポートします。OLAP 分析は、その大多数が数値情報に対して行
われますが、一部のアプリケーションにとっては論理と文字のデータ型が重要となるため、
こ れ ら の デ ー タ 型 を 提 供 す る Express は 有 意 義 で す 。 例 え ば 、 論 理 変 数 は 、 今 回 の
Express 実装におけるデータローディングロジックのサポートに用いられます。OLAP アプ
リケーションは、通常クライアントベースのアクティビティのサポートを必要とします。
Express で は追加のデータ型が含まれているため、そのサポートを別の構造ではなく
Express データベースに格納することができます。
Express と OLAP Services のどちらも、列挙値やオブジェクトといったユーザー定義のデ
ータ型はサポートしません。
両製品は、キューブのコンセプトに関していくつかの根本的な違いがあり、これがそれぞれ
の特徴となっています。OLAP Services は、キューブをメジャーの集合として扱い、格納さ
れている複数のキューブを一緒に用いるためには、それらを 1 つのバーチャル キューブに集
めて、任意の定義された計算を繰り返さなければなりません。一方 Express は、各変数とフ
ォーミュラをそれ自身のキューブとして扱い、データベース管理者が関与することなく、こ
れらの任意の組合せを一緒に用いることができます。
OLAP Services のレギュラー キューブは、論理的なマルチレベルの多次元データ領域を表
し、プロシージャ上は、ファクトデータの集計値を表します。そのため、ファクトテーブル
に結び付けずにキューブを定義したり、キューブ内の中間レベルにデータを入力したりする
ことはできません。Express 変数は、自由形式の多次元構造です。一切の外部データソース
への本質的な結び付きを持たず、内部の任意のデータポイントを自由な手段でそれに割当て
ることができます。
OLAP Services レギュラー キューブの設計では、各ディメンションの各レベルに対するス
トレージとテーブルの結合についての問題がありますが、キューブはデータベース内のディ
メンションの設計には全く影響しません。一方 Express では、変数の設計時に、その全ての
ディメンションを共有する他の変数全てを検討することが重要であり、変数を効率的に実装
するためには、少なくとも部分的に冗長なディメンションの全く新しいセットを実装する必
要のある場合があります。
OLAP データの論理的および物理的な性質は、Express よりも OLAP Services において、
より大きく分離されています。そのため OLAP Services では、開発者はキューブを定義す
る際、データストレージの問題を考慮する必要がありません (それが影響することはありま
せん) 。しかし、データソースとデータ利用の性質は、Express の方がより大きく分離され
ています。Express では、変数とキューブはそれぞれ、データのあらゆるソースから完全に
独立しており、開発者は 2 つの間の結び付きを作成することになります。

異なるディメンションが設定された変数同士の間におけ
るデータの適用範囲
OLAP Services では、あらゆるレギュラー キューブ内において、ディメンションが全ての
メジャーに同じように設定されます。バーチャル キューブ内では、全てのメジャーが、メタ
データの中でバーチャル キューブの全ディメンションによってディメンションが設定される
ことになるのに対して、データ値はベース キューブのディメンションに対応する領域の中だ
けにあります。
Express では、変数とフォーミュラはそれぞれハイパーキューブ (多次元超立方体) を表現
します。そのコンポーネント変数またはフォーミュラの1つとしてディメンションを組み込
んでいるフォーミュラまたはその他の等式は、ディメンションの中でデータがアクセスされ
る場所とは無関係に、そのデータにはアクセスしません。
例えば表 1 は、返品理由ディメンション全体で返品変数と組合わさった場合の、販売変数の
適用範囲を示しています。OLAP Services では、販売は返品理由ディメンションの全返品理
由メンバでのみ利用可能になっていますが、Express では、同一の販売値が返品理由の全て
にわたってコピーされています。
OLAP Services における適用範囲
             全返品理由            傷あり                     サイズ違い
             販売       返品      販売             返品       販売      返品
1999 年 1 月   2519     137                    37               100
1999 年 2 月   1033     75                     45               30
1999 年 3 月   1180     48                     21               27


Express における適用範囲
              全返品理由         傷あり               サイズ違い
              販売      返品    販売       返品       販売     返品
1999 年 1 月    2519    137   2519     37       2519   100
1999 年 2 月    1033    75    1033     45       1033   30
1999 年 3 月    1180    48    1180     21       1180   27
表1 返品と組み合わさった場合の販売変数の適用範囲

組合わされたデータの消費者にとってこれは何を意味するでしょうか?各システムにはそれ
ぞれの長所と短所があります。OLAP Services において、返品理由から販売量を結合できる
ようにしたい場合は、特別にそれを参照する必要があります (通常、これを目的とするマイ
クロソフトの ValidMeasure () 関数を使用) 。Express では、これを行う必要はありませ
ん。しかし Express では、返品ディメンション全体に渡って販売値を参照している時、販売
もまた返品理由ディメンションによるディメンション設定がなされていないことについて
(メタデータへ戻ること以外) 全く見当がつきません。


判定基準                               勝者
データ型サポート                           引き分け (差異は相殺)
論理と物理のキューブ/変数の性質を分離                OLAP Services
マルチレベル論理構造としての変数                   OLAP Services
基底のテーブル構造におけるキューブ構造 Express
の依存性
キューブ編成の柔軟性                         Express
キューブ構造の設計に要する時間と知識                 OLAP Services


OLAP Services の手順 – 変数とキューブ
OLAP Services の各キューブを設計するにあたって、最初に OLAP マネージャ GUI とキュ
ーブウィザードを用いました。各キューブに対して、次のステップに取り掛かりました。
キューブのメジャーを取り出すためのファクトテーブルを選択しました。開発中、最初に
我々はキューブ毎にファクトテーブルを 1 つだけ用いてデータのサブセットを扱い、それに
よってテーブルを選択しました (例えば返品キューブに対しては tx_returns テーブルを選
択) 。
ファクトテーブルの全数値列セットから、キューブへメジャーを提供する列を選択しました。
例えば返品テーブルでは、Units と Return_Value 列を選択しました。 (1 つの列が複数の
メジャーのベースとなる時が往々にしてあります。このインタフェースからは1度だけメジ
ャーを選択できますが、後からキューブエディタでメジャーを追加することができます。)
次いで、キューブが使用するべきディメンションを選択しました。全てのディメンション
(リアルとバーチャル) が表示され、各キューブに適切なセットを選出しました。OLAP
Services が選択されたディメンションに対して、ファクトテーブルとディメンション テー
ブルとの間に全ての結合を作成しようと試みたところ、これができないとのメッセージが出
ると共に、キューブ名の入力を促すプロンプトが表示されました。キューブ名を入力したと
ころ、キューブエディタが表示されました。
キューブエディタを用いて、ディメンション テーブルからファクトテーブルのディメンショ
ン列への結合を指定しました。時として、1つのディメンション テーブルセットから複数の
ディメンションが供給されることがありました。テーブル結合を作成したことで、これらの
テーブルから供給された全てのディメンションに対してリレーションがセットアップされま
した。例えば返品キューブにおいて、Product.ByFamily と Product.ByManuf ディメンシ
ョンは、両方とも製品ディメンション テーブルから定義されました。また Sku Color、Sku
Fabric、およびその他の製品関連のバーチャルディメンションも同様です。
またキューブエディタを用いて、結合の最適化とデータが入るキューブのレベルについても
指定しました。例えば、各ファクトテーブルに対して、全く同一の製品 SKU 結合キー値を
持つファクトテーブルの prod_id 列を用いて、製品ディメンション テーブルの各 Sku-レベ
ルメンバの一意な ID を定義しました。Product.ByFamily と Product.ByManuf ディメン
ション両方の Sku レベルに対するキューブのプロパティにおいては、「メンバキー列」はデ
フォルトでディメンション テーブルの Sku-レベルメンバキー列に設定されています。ファ
クトテーブルの prod_id 列をメンバキー列となるよう選択することにより、OLAP Services
は大部分の状況下で、ディメンション テーブルをファクトテーブルへ結合することを回避で
きます。 (時間ディメンションに対してこれを指定しましたが、キューブは時間でパーティ
ション分割されたため、OLAP Services は、時間スライスに基づいて時間行を限定できるよ
う、時間テーブルへの結合も生成しました。) キューブエディタのメニュー機能であるツー
ル | 最適化スキーマは、全キューブテーブル間の結合と各ディメンションでの一意なメンバ
の設定の分析を行うと共に、必要だったかもしれない結合を最大限に削除します。
結合テーブルの必要性が最適化され、それが削除されてもされなくても、全テーブル列間で
結合がグラフィカルに描写されることに注意してください。しかし OLAP Services が SQL
を発行すると、必要なメンバキーの取得に求められるテーブルだけが実際に結合されます。

テーブル結合と、キューブディメンションレベルの抑制
に関する追記
在庫テーブルは、週の最終日に対する日キーを用いて、週単位でデータを追跡しますが、今
回のアプリケーションでは、月末値 (その月の最終週における週末値として定義) などの月
間在庫を追跡する必要がありました。ウェアハウス内では、補助テーブルが各月の最終週を
追跡します。月間在庫状況キューブに対しては、キューブエディタから、
Last_week_of_month テーブルを追加し、そこからメインの時間テーブルへの結合を定義
しました。 (ウェアハウスのデータベース管理者がこれに対するビューを定義することもで
きましたが、我々はこれを処理する OLAP システム性能の素晴らしさを評価しました。) ま
た、この last_week_of_month テーブルの month_id 列からメンバキー値を取り出せるよ
う、キューブの Time.ByMonth ディメンションの月レベルを定義しました。データを正確
にキューブに入れるために、キューブの Time.ByMonth 日レベルへ移って、無効プロパテ
ィを Yes にセットする必要もありました。これを行わなかったら、キューブが日レベルにも
結合し、毎日一度これが繰り返されることとなったでしょう。これをセットすることで、キ
ューブの Time.ByMonth ディメンションのリーフレベルが月レベルとなりました。
図2 月間在庫状況キューブのレコードを制限するために結合テーブルを挿入
これと関連して、在庫テーブルは週データしか追跡しないため、2 つの週間在庫キューブに
対して日レベルを無効とするようマークすると共に、キューブの Time.ByWeek ディメンシ
ョンの週レベルメンバキーをそのまま時間テーブルの週 ID キーとして残しました。

リンクに関する追記
キューブとファクトテーブルのそれぞれに対し、リンクは列の中でメジャーが表現されてい
る「タイプ1」テーブルの解析のみ行えます。全てのリンクは宣言する必要があります。そ
のためキューブの定義にプロシージャ的な側面を指定する方法はありません。各リンクは列
式に基づくため、定義内で計算を行うよう指定することができます。任意の結合を OLAP
Services に指定し、テーブルを1つに結ぶことができますが、ディメンションキーとファク
トテーブルとして用いられるテーブルを結ぶ結合だけが使用されます。

Express の手順 – 変数とキューブ
我々は Express Administrator を用いてもう1度変数を定義しました。データベースのメ
タデータツリーにおいて、変数ノード上を右クリックし、「新規…」を選択して、各変数に
対する名前、データ型、そしてディメンションを入力しました。数値変数に対しても、数値
フォーマット化を指定できました。しかし、これは意味がありませんでした。というのも、
Express 変数は、その一部はユニットとして、また一部は通貨値など、いくつかの異なる論
理変数を表していたためです。
繰り返しますが、中核要素 (ここではキューブ) を定義するプロセスはシンプルでした。し
かし、変数をデータへと結ぶ必要が依然として残っています。

Express の手順 – キューブをテーブルへリンク
Oracle Express は、SQL データソースとテキストデータファイルからディメンションと変
数を持ち出すことができます。Express では、データベース管理者がファクトレコードを取
得する SQL を作成します。またデータベース管理者は、カーソルを開いたり、結果行をルー
プさせたり、データを変数へ入れたりするスクリプトを作成する必要があります。こうした
スクリプトは、最小でもおよそ 30 行ほどで、すぐに 100 行を超えるものとなります。例え
ば、我々がウェアハウスからファクトデータをロードするために実装したスクリプトは、75
行から 200 行の間でした (初期ローディングのコードは 400 行) 。
スクリプトで実行されるタスクの量は、データベース管理者次第です。例えば、1 つの SQL
コマンドで多数の別個の変数をロードする場合などがあります。SQL は完全な任意裁量性が
あり、必要な任意のテーブルセットを 1 つに結合することができます (これとは対照的に、
OLAP Services では、パーティション毎にファクトテーブルをただ 1 つだけ利用し、同一
の列名が各パーティションで利用できるようになっている必要があります) 。また、クエリ
の列から返された値は、値やメンバ名として自由に扱うことができるため、ノーマルでない
テーブルを簡単に配置換えすることが可能です。例えば、1 度の在庫検査で全ての週間在庫
値を 2 つの変数 (1 つは時間加算的なメジャー、もう 1 つは時間加算的でないメジャー) に
読み込み、次いでその 2 つを別個に集計することができます。OLAP Services でこれを行
うには、在庫テーブル上に 3 つの別々のパスが必要でした。これは処理されるキューブ毎に
1つずつとなります。
Express では、リーフレベルでデータをロードする必要はありません。今回の調査では、販
売と返品のデータが日レベルでロードされました。しかし前述のように、在庫データは日
(またはリーフ) レベルでは存在せず、その代わりに週レベルで測定されました。そのため、
我々のデータロードプログラムはそれを直接高位レベルにロードしました。時間ディメンシ
ョンが 2 つの階層を持っていたことを思い出してください。1つは日、月、四半期による標
準階層、もう 1 つは日、週、および全週により週階層です。在庫データは、週レベルでロー
ドされました。追加および出荷された在庫量は、週から月まで合計され、直接月レベルでロ
ードされました。在庫の開始カウントと終了カウント、および終了値は、月の最終週からデ
ータを引き出すことで、月レベルでロードされました。
増分ローディングの設計
データの初期ロードを行おうとしていた方法に基づいて変数とディメンションを設計する他
にも、データの定期更新について、そしてその処理にあたって構成を追加する必要があるの
かどうかについても検討する必要がありました。データベースは、大規模となる最初の一括
ロードを経て、次いで定期バッチ更新が行われます。各更新は、新規のセルデータに加えて、
既存情報 (差分の形態で) への訂正が含まれることが想定され、また潜在的に大容量データ
も含まれます (ある期間にわたって最大 100 万行) 。我々は、既存データとユーザーセッシ
ョンにおける入力データの影響を考慮し、増分更新プロセスを設計する必要がありました。
増分更新プロセスは、データの読み取りと集計の両方を伴うことになります。我々は、2 つ
の取り得る処理テクニックを検討しました。新しい行を上述の変数に読み込む場合、その値
をデータベースから読み込まれている値に設定する必要はありませんが、その値をデータベ
ースから読み込まれている値だけ加算する必要があります (補正トランザクションを読み込
んでいる場合があるため) 。そして、この処理が適用された先行セルの全てを再集計するこ
とができました。これを行う際は、データベースの多量のデータへアクセスすることになり
ます。例えば年レベル集計の再計算を行うためには、最終的にその年の全ての日レベル値に
アクセスする必要があります。
2 番目の取り得る方法は、新しい値を別個の変数に読み込み、この変数を集計し、次いでメ
インの変数内で影響のあったセルを増加させるというものでした。これに伴うデータの読み
込み作業や集計作業は比較的少なく、逆に増加ステップはより大きいものとなります。ある
一定期間中に、顧客の小さなサブセットのみが購入を行い、また全製品のあるサブセットの
みが販売されているような場合があります。更にバッチは、予測できないほど長い時間がか
かる場合があります。増分更新のコントロールにおいて、如何なる方法でも指定コンポジッ
トを利用することはできません (例えば、値が増分変数内に存在しているメインの変数値を
増加させるだけ) 。そこで我々は、顧客、時間、および製品のディメンションを設定した 3
つの論理変数を別々に加えて、増分レコードが実際に読み出される場所に目印をつけました。
これらを用いて、メイン変数の増加が実際に行われたディメンション領域を制限します。更
新を効率的に促進するために、これらの増分更新変数がメイン変数と同一のディメンション
(指定のコンポジット ディメンションなど) を用いるよう宣言します。そのため、以下につ
いても定義しました。


変数                 ディメンション
Sales_Incr         Meas_Sales Salesc_Mopcty <…>
Returns_Incr       Meas_Returns Returnsc_Rmpcty <…>
Invent_Agg_Incr    Meas_Inv_Agg Inventoryc_Wpty <…>
Invent_Nona_Incr   Meas_Inv_Nonagg Inventoryc_Wpty <…>

今回定義した論理:
変数                 ディメンション
Years_Wi_Data      <Years>
Time_Wi_Data       <Time>
Cust_Wi_Data       <Customer>
Prod_Wi_Data       <Product>

もし OLAP システムのリーフレベルがデータの詳細度よりも細かかったとしたら (例えば、
日レベルのファクトテーブルなのに月レベルの時間ディメンション) 、我々は更に、変数の
入力に SQL 集計を実行するべきか、あるいはファックとレベルのデータを Express に読み
込んで内部で集計するべきかについて検討したでしょう。
初期ローディングのコード 400 行に加えて、増分ローディングのコードが更に 500 行とな
りました。

OLAP Services に関する追記
特記に値することとして、OLAP Services では、キューブの定義が基底のテーブル構造から
分離されていません。そのため、基底のテーブルとは別にメジャーとディメンションを定義
することができませんでした。例えば、所定の論理キューブに対する 2 セットのメジャーが
2 つの別々のテーブルからのものであったとすると、これらのテーブルをビューで結合する
か、あるいは 2 つの別個の物理キューブを 1 つのバーチャル キューブに作成、結合する必
要があります。
全てのキューブは、パーティション分割されていない状態であっても、データの論理ストレ
ージをいくつか持ちます。ストレージ面については、物理パーティション分割のセクション
で論じますが、実際にはこの段階で最初にそれを扱う機会が訪れました。

比較:キューブ設計手順
MOLAP データストアを基底のデータ ウェアハウスへと結びつけるプロセスは、 OLAP
Services の方が遥かにシンプルです。その GUI インタフェースは簡単に操作でき、またキ
ューブ-テーブル間のリンク定義を宣言できました。一方 Express は、プログラムの開発に
数日を要しました。
キューブの設計と実装のプロセスで求められる知識の多さは、Express で顕著でした。デー
タの希薄性をうまく扱うためには、RDBMS におけるデータのパターンを理解する必要があ
りました。また、ディメンションの配列に関して全てのキューブを相互に関連付ける必要も
あったため、これらの変数を使うときは常に留意するべき更なる要素が浮上しました。
Express キューブを RDBMS からどのように引き出すかについて定義する際、データのロー
ドの方法だけでなく、更新方法についても定義する必要はありませんでした。更新プロセス
の作成には、バッチロードプロセスよりも多くのコード設計が伴いました。この作業は全て、
プログラミングに関する詳細な知識と長時間を要しました。


判定基準                          勝者
キューブ構造とテーブルへのリンクの作成に要する OLAP Services
時間と知識


物理的なパーティション分割
これだけの規模を持つアプリケーションでは、可能であれば、データベースの物理的なパー
ティションを作成することが望まれます。最適化技法を使えば、別のサブキューブ領域や、
場合によっては別のサブディメンション領域まで、独立した物理ディスクに格納することが
できます。これによって、更新やクエリ処理を局所化することができ、また、複数パーティ
ションにアクセスする必要があるクエリでは、ディスクへの並列アクセスが可能となる場合
もあります。OLAP Services と Express は共に、データベースを複数の別の物理ディスク
にまたがって格納する何らかの機能は提供していますが、最適化機能についてはまだ十分で
はありません。それでもなお、両製品のパーティショニング機能には十分な利用価値があり
ます。
OLAP Services 論理仕様 - データベースのパーティシ
 ョニング
OLAP Services でデータベースの物理的なパーティション分割を検討する際は、データの論
理的な分割と物理ストレージの両方を考慮する必要があります。
OLAP Services では、各キューブの格納データを複数パーティションに分けることができま
す。各パーティションには、独自のストレージ (MOLAP/ROLAP/ハイブリッド) を設定す
ることができます。ROLAP パーティションの場合は、各パーティションの格納データを、
そのパーティションデータの元となるデータベースのデフォルトのテーブルスペースに置く
ことができます。このデフォルトのテーブルスペースは、適切な RDBMS を使えば、データ
ベース管理者が指定する任意のファイルセットに (場合によっては、OLAP サーバーとは全
く別のサーバーにも) 置くことができるため、このストレージの設置場所についてはほとん
ど制限がありません。MOLAP ストレージ、および全てのデータベースに対する実際のハイ
ブリッド集計は全て、OLAP サーバーにおけるファイルシステム内の 1 個のディレクトリツ
リーに格納されます。キューブの各パーティションが、他の全てのキューブに含まれる全て
のパーティションとは別のファイルセットに格納されることによって、クエリや更新での参
照が局所化される可能性が大きくなります。しかし、全てのファイルが強制的に 1 個の論理
デバイスに収容されるため、ストレージに複数の物理ディスクを RAID 構成で使用するしか
方法はありません。MOLAP の全てのキューブパーティションは、キューブを示す単一ディ
レ クトリ に個別の ファイル セット として格 納されま す。こ のため、 システム 管理者 が
Windows 2000 の機能を使用して、ディスクをファイルシステム内の OLAP Services のデ
ィレクトリ名にマップすることができたとしても、キューブのパーティションは同じデバイ
スに残ります。
OLAP Services のシステムでは、時間をベースにして各キューブのパーティションを作成し
ました。最初にキューブを設計したときに、代表的なテーブル構造をアクセスしました。
SQL Server では、実際の元のファクトテーブル (在庫だけは除く) は年をベースにパーテ
ィション作成されていました。時間の細かさは任意に選択できましたが (例えば、月や四半
期ベースのパーティションなど) 、管理のしやすさと単純さから、年をベースにしてキュー
ブのパーティションを作成しました。こうして、キューブへの 1999 年の新しい 1 週間分の
データの追加は常に 1999 年のパーティションに対して行い、2000 年のデータについても
独自のパーティションに格納しました。パーティション作成のディメンションには複数の階
層があるため、クエリ処理ではパーティション作成の利点は得られません。2
 (OLAP Services には、パーティションをマルチディメンションの階層に定義する機能があ
りますが、残念ながらバグのためにこの機能は使用できませんでした。そのため、時間のデ
ィメンションに複数の階層を置くことをあきらめ、一つの時間ディメンションに
Time_ByMonth、もう一方のディメンションに Time_ByWeek という名前を付けまし
た。)
我々は最初に、アプリケーションの構築には MOLAP ストレージを使用することにしました。
ディスクストレージは少し余分に必要になりますが、顧客や製品など全てのレベルの分析を
行うときには、これがクエリの性能を最も高くする方法です。使用を予定していた先行集計
の率は選択できますが、その率と実際に作成される集計処理の関係は明確には定義されてい
ません。これについては、実際にパーティション作成を実行するときに調べることにします。

2
 理想としては、1 年分のデータへのクエリではそのパーティションのデータだけをアクセ
スし、年と年を比較するクエリでは該当する 2 パーティションだけを対象とすることが望ま
れます。しかし、今回パーティション分割したディメンションには 2 つの階層があるため、
これを行うことは困難です。通常は、月の階層の特定メンバに対してデータが要求されると、
全週のメンバが参照されます。全週のメンバを得るには、週を含む各パーティション(つま
り、すべてのパーティション)を探すしかありません。しかし、カスタムクライアントのい
くつかのケースでは、月の階層にある特定の年のデータに対するクエリを実行するときには、
週の階層にある特定の年に対するクエリも発行できます。
マイクロソフトが提供しているガイドライン3では 30%から始めることが提案されており、
今回はこれに従いました。
各キューブのパーティションを作成するときのベースの決定、および各パーティションに対
する先行集計率の初期概算の他に、検討すべき項目がもう一つありました。顧客ディメンシ
ョンに架空都市のレベルを作成したとき、キューブパーティションのストレージに影響が出
ることは想定していませんでした。サブ都市から都市への入力数は、かなり少ないと考えら
れます。ニューヨーク市の 800 万住民の全てが顧客になった場合は、全員を収容するのに約
125 のサブ都市が必要になります (125 のサブ都市 × サブ都市当たり 6 万 4,000 人の顧客
= 800 万人の顧客) 。全体としてはサブ都市から都市への入力数は極めて少ないため、集計
処理の最適化で採用する 1/3 ルールによれば、この程度の数では格納される物理的な集計処
理の数が増えることはありません。OLAP Services での集計処理の受信でこのレベルを禁止
することもできましたが、現時点での必要性はなく、将来も支障となることはありません。

Express 論理仕様 - データベースのパーティショニング
Oracle Express のデータベースのパーティション分割機能は、全く異なっています。この
違いは、Express では全ての操作がセッションコンテキスト内で発生し、各セッションが複
数のデータベースで動作できるということから来ています。
各データベースは最低でも 1 個のファイルから構成され、そのデータベースの主要 (初期)
ファイルはファイルシステムの任意のディスクに存在できます。Express データベースのフ
ァイルは 2GB 以下のサイズであり、データベースがそれより大きくなると、Express では
番号付きの拡張子を持った拡張ファイルが作成されます (各ファイルがさらに 2GB まで大き
くなると、別のファイルが作成されます) 。初期ファイルは任意の場所に存在できますが、
拡張ファイルはラウンドロビン方式によって、名前付きの拡張ディレクトリのセットに追加
されます。こうして、与えられた個々のデータベースは、論理的にも物理的にも複数のディ
スクに存在することができます。しかし、特定のデータベースオブジェクト (変数、または
変数のサブキューブなど) を個々のデータベースファイルに関連付けることは現実的ではあ
りません。従って、データベース内のアクセスはほぼディスク全体にわたり、あるディスク
に参照を局所化することはできません。ディメンションを使用する全てのオブジェクト (変
数、フォーミュラ、モデル、その他) は、そのディメンションと同じデータベースに存在す
る必要があります。
しかし、1 個の Express データベース内のオブジェクト (フォーミュラ、プログラム、その
他) は、他の複数の Express データベース内に格納されているデータへアクセスすることが
できます。1 個の論理データベースのパーティションを、データベース全体のサブセットを
個々に持つ物理的な複数のデータベース上に設定し、1 個の統合データベースがフォーミュ
ラのセットを使用してクエリを適切な物理データベースに分けるようにすることができます
(この統合データベースをキャップストーンデータベースと呼ぶことがあります) 。これらの
フォーミュラを使用すると、データ検索のオーバーヘッドが増し、大規模な開発の追加が必
要になります。また、各物理データベースを個々に管理する必要性も生じます。
例えば仮に、Express のシステムでパーティションを年をベースにすることにし、1996 年
から 2000 年までをそれぞれ 1 個のデータベースとすることに決めたとします。複数のデー
タベースが 1 個のセッションに結合されたとき、2 個以上のデータベースに同じ名前のディ
メンションまたは変数があった場合は、Express ではそれらの参照に混乱が発生します。従
って各データベースには、その名前に _1996 ~ _2000 を付けるなどして、ディメンショ
ン、変数、フォーミュラの独自のセットが必要となります。データベースを保守するプログ
ラムはこの処理を汎用的に作成する必要があり、要求された年に対応した正しい変数をアク
セスするフォーミュラのセットを生成する必要があります。大規模な Express システムの構



3
    OLAP   Services:   そ の ア ー キ テ ク チ ャ の 性                    能   評   価   (
http://msdn.microsoft.com/library/backgrnd/html/olapperf.htm)
築ではこの技法はよく使用されますが、今回のケーススタディは開発時間に制約があり、こ
の方法は見送りました。

OLAP Services の手順 - データベースのパーティショ
 ニング
OLAP Services でのキューブのパーティション分割は、次の手順で行いました。
各キューブに対して、キューブのパーティションセットを展開して、作成されたデフォルト
パーティションが見えるようにしました。各パーティションの定義には、パーティションウ
ィザードのインタフェースを使用しました。先頭のパーティションには (最初は、キューブ
の [Partition] アイコンを右クリックして [New] を選択) 、使用可能な全キューブの一覧か
らそのパーティション用のファクトテーブルを選択しました。その後、ディメンションツリ
ーセレクタから時間ディメンションを選択して、ファクトテーブルを各時間ディメンション
の適切なタイムスライスと関連付けました。例えば、返品キューブの最初の (1996 年) パー
ティションに対しては、tx_returns1996 テーブルを選択してから、ディメンションツリー
を使用して Time_ByWeek の 1996 年のメンバと Time_ByMonth の 1996 年のメンバを
取り出しました。この選択は、パーティションマネージャによって正常に処理されました。
1997 年 の パ ー テ ィ シ ョ ン に 対 し て は 、 tx_returns1997 テ ー ブ ル を 選 択 し て
Time_ByWeek の 1997 年のメンバと Time_ByMonth の 1997 年のメンバを取り出しまし
た。後も、同様です。
1999 年の各パーティションに対しては、そのパーティションの 1999 年のタイムスライス
との関連付以外に、[Advanced Settings] ダイアログを使用して WHERE 句とこのパーテ
ィションとの関連付けも行いました。この理由は、データの複数のバッチをそれぞれファク
トテーブルに格納する予定があったことから、キューブを完全に再処理するときに、実際に
どのバッチが転送されているかを管理したかったためです。これによって、集計結果に影響
を与えずに、他のバッチからのレコードがテーブルに格納されている間にも、キューブの処
理や使用を行うことが可能となりました。WHERE 句は実際には、キューブの増分処理では
さらに重要性を持ちました。これについては後で説明します。

一括のローディングと集計処理
データ ウェアハウスに基づく OLAP 分析システムで主に行う作業は、データを OLAP デー
タベースに送って集計することです。OLAP システムから大量のデータへアクセスできるだ
けでは不十分です。クエリでは通常、元となるデータの集計結果を使用するため、満足の行
くクエリの応答時間を得るためには、ある程度の先行集計を行うことが必要となります。
実際に、今回のケーススタディのようなアプリケーションでは、2 つの別個の一括ローディ
ング作業が発生します。顧客のディメンションはかなり大きく、ケーススタディを行ってい
る間も変化します。このディメンションのローディングは、いくつかの点で、ファクトデー
タのローディングとよく似た作業となります。

OLAP Services 論理仕様 - 一括のローディングと集計
 処理
ディメンション情報とキューブデータに対する一括のローディングと集計処理については、
ディメンションとパーティションを定義してしまえば、他には考慮することはほとんどあり
ません。OLAP 構造とリレーショナルな元データ間の全ての関係は、宣言により定義されま
す。キューブやディメンションを処理するときはいつでも、OLAP Services によって、SQL
の生成、構造の設定、集計処理の実行が行われます。
OLAP Services のキューブの各パーティションには、入力メジャーに対する集計データを格
納することができます。パーティションの定義の一部分は、集計されたメジャー値が格納さ
れる各ディメンションからのレベルの組合せのセットになっています。OLAP Services で格
納されるのはこれらの集計データだけであり、比率や差分、その他のデータは格納されませ
ん。レベルの組合せについては、任意のセットを格納することができます (ディメンション
の特定のレベルを含む全ての組合せを格納する、といった要求ではありません) 。OLAP
Services の内部処理として、ある集計処理が、最大 3 倍の行数からなる別の集計処理でカ
バーできるという予測が立った場合は、その集計処理は作成されません (これを 1/3 ルール
と呼びます) 。
OLAP Services の特長の一つは、最適化アルゴリズムによって、どういうレベル組合せの集
計値を計算するべきかについての概算セットが作成されることです。これは、パーティショ
ンに対するファクトテーブルの行数に基づいて計算されます。マイクロソフトはこれを行う
ための GUI を提供していませんが、プログラムから (1/3 ルールに従って) 特定の集計処理
の追加を指定することは可能です。さらにサーバーのログには、クエリからサーバーにアク
セスがあったレベル組合せが記録されます。この情報に基づいて、OLAP マネージャに付属
するツールによって、集計処理の新しいセットの計算が行われます。マイクロソフトがこれ
らの処理を行う目的は、データベースへの実際のアプリケーションからのフィードバックに
よって、データの先行集計と格納の割合を決定できるようにすることです。
OLAP Services の残念な欠点として、集計処理の新しいセットを定義したときに、MOLAP
パーティションに格納されている既存の集計処理から追加することができるにもかかわらず、
関連するデータストレージからパーティション全体を再集計する必要があるという点があり
ます。新しい集計データを、既存の集計データから単純に増分として加えることができませ
ん。
今回のケーススタディでは、各キューブに対して最初に 3 年、10 ヵ月分のレコードの大き
なローディングサイクルを実行してから、1 週間分の新規レコードをローディングするサイ
クルを 13 回実行しました。
OLAP Services は MOLAP ストレージのキューブパーティションを処理するとき、未集計の
ファクト行に対して SQL を発行します。OLAP Services は、全ての集計処理を独自に実行
します。これは OLAP キューブのリーフレベルがファクトテーブルと同じ細かさである場合
についてですが、ファクトテーブルのレベルの方が細かいときも、個々のファクトレコード
を要求します (例えば、ファクトレコードのレベルが日で、時間のリーフレベルが月の場
合) 。これは、膨大な量のファクトレコードの集計に対して、リレーショナルデータベース
のグループ単位の集計方式に頼るのではなく、OLAP Services に組み込まれた特殊な集計機
構を活用するためです。
元のディメンションやファクトレコードへの連結が完全に宣言で定義されるため、データベ
ース管理者が単純に「process」関数を呼び出すだけで、OLAP Services による SQL の生
成、行の取り出し、集計データの設定が実行されます。データベース管理者は、サーバー全
体にわたる集計処理に消費される RAM の容量を管理することはできますが、その他の集計
処理への影響は考慮する必要も権限もありません。既存のパーティションに新しいファクト
行が追加されたときも、同様の処理が行われます。新しいパーティションが作成され、パー
ティションに新しいデータが格納されてから、新しいパーティションが既存のパーティショ
ンとマージされます (このマージ処理が可能なのは、全ての集計データが可換の性質を持っ
ているためです) 。

Express 論理仕様 - 一括のローディングと集計処理
Oracle Express には一括のローディングや集計処理という概念はないため、独自にその処
理を設計して実現する必要がありました。データの一括ローディングは、カスタムプログラ
ムによって実現できます。Express には、固有の一括集計処理を支援するいくつかの基本命
令が用意されています。
Express へのデータの取り込み
Express へのデータ取り込みの論理的な作業は、主にキューブテーブルの連結と関連プログ
ラムの設計でした。これには、キューブの初期ローディングと増分更新が含まれます。

AGGMAP を使用した集計処理の設計
Express 6.3.0 で新たにサポートされた AGGREGATE コマンドと AGGREGATE 関数によ
って、変数の部分的な総和計算が可能となりました。これは、和が保持されるセルをディメ
ンション単位に指定し、和が保持されていないセルの和をトランスペアレントにその場で計
算することによって行われます。これは、ディメンションを通して完全な集計処理を実行し
ていた従来の ROLLUP コマンドの機能を拡張したものです。aggmap と呼ばれる構造によ
って、集計データを格納する場所についての各ディメンションの制約を定義します。
集計マップ、および AGGREGATE のコマンドと関数は新しい機能であるため、これらの一
般的な使用法や改善された良い使用例などはまだ確立されていません。オラクルは APB-1
ベンチマークの開発の中でこの機能の効率的な使用法を指摘しましたが、今回のアプリケー
ションにもこの方法を採用しました。集計マップの各ディメンションに対して、そのディメ
ンションに対するレベルのセットでディメンションが設定された論理変数を定義しました
(これは、埋め込み-トータルサポート構造の一つを利用した例です) 。論理は、そのディメ
ンションのどの階層レベルで集計データが格納されるかを示します。集計データは、この変
数が全て真であるレベルの組合せのときに格納され、この論理が一つでも偽のときには格納
されません。これは、リレーショナルウェアハウスでの集計テーブルマトリックスの作成と
よく似ています。
Express には、データベース管理者が集計データをどこに格納すべきか見積もるための機能
や、実行したクエリで集計データが実際にどのように使用されているかをフィードバックす
るための機能はありません。データベース管理者がこれを行うには、データの特性、発行す
べきクエリ、ディメンションの構造などに関する知識を使用する以外にありません。
Express システムの aggmap の作成では、主にディメンション内のレベルからレベルへの
メンバの入力数を検討し、そのディメンションをクエリで使用することを計画しました。先
行計算の基準としては、以下の点を考慮しました。親から子への出力数が少ない場合はその
場での集計処理が可能であり、多い場合は先行計算を行う。特定レベルのデータに頻繁なク
エリアクセスがある場合は、それを先行計算する。例えば、時間ディメンションでは、日、
週、月、および「全四半期」には独自にデータを格納するように指定しました。週、月は頻
繁に使用され、平均して約 30 日間で 1 ヵ月となります。しかし、四半期はわずか 3 ヵ月か
らなるため、これはその場で即時に計算可能、としました。
  注記: Express Administrator 6.3.0 では、まだ aggmap は認識されませんでした。従
  って、Administrator を省いてコマンドレベルで aggmap 仕様の作成と編集を行う必要
  がありました。集計マップを操作する最善の方法は、仕様やコマンドをテキストファイ
  ルに記述して、それを INFILE コマンドで読み込むことだということが分かりました。

OLAP Services の手順 - 一括のローディングと集計処
理
OLAP Services 内部では、ファクトデータの一括のローディングと集計処理は一つの操作で
実行されます。ローディングと集計処理を繰り返すサイクルを 13 回行いましたが、最初の
4 回は OLAP マネージャを通して、残りの 9 回はカスタムプログラムを通して実行しました。

処理とパーティションの概要
最初のサイクルでは、各キューブを完全に処理して、各キューブの各パーティションを完全
に作成しました。キューブを初期処理した後で、2 回目から 9 回目のサイクルで、1999 年
のパーティションに増分処理機能を適用しました。10 回目のサイクルでは、2000 年のキュ
ーブに新しいパーティションを追加して、そのパーティションの完全な処理を実行しました。
それから、11 ~ 13 回目のサイクルで、2000 年のパーティションに対して増分処理を実行
しました。

処理とパーティションの詳細
最初のローディングサイクルでは、データベースの全てのキューブに対してデータをローデ
ィングする必要がありました。簡単に行うために、データベース概要の [Cubes] ノードを
右クリックして、[Process All Cubes] を選択しました。
2 回目から 4 回目のサイクルでは、OLAP マネージャを使用してキューブに増分処理を実行
しました。この処理は、各キューブに対して簡単に実行できました。OLAP マネージャでキ
ューブを右クリックして [Process…] を選択し、増分処理の実行を選択しました。次に対象
のパーティション (1999 年) を指定し、そのパーティションの WHERE 句を編集して現在
のバッチの番号を反映させました。OLAP Services からは、パーティションの行の読み取り、
集計処理の計算、および内部の更新についての進捗が表示されました。処理が完了したとき、
パーティションを定義した WHERE 句は、増分更新に使用した WHERE 句が入った形で更新
されました。これによって、将来行う完全な再処理では全て同一のデータが使用されます。
OLAP Services の OLAP マネージャには、複数キューブの更新を指定する手段がなく、デ
ータベースの全キューブを完全に再処理するしかありません。一つのバッチで各キューブを
処理するのは時間がかかるため、指定に応じてキューブパーティションのセットを処理する
小さなアプリケーションを作成しました。このアプリケーションの作成とデバッグに全部で
約 2 日半を丸々費やし、DSO ライブラリや他のプログラミング言語 (この場合は Visual
Basic) の理解が必要でした。
5 回目から 9 回目のサイクルでは、この処理アプリケーションを使用して、新しいデータに
よる 1999 年のパーティションの増分更新を実行しました。10 回目のサイクルは 2000 年
の最初のデータだったため、OLAP マネージャを使用して新しいパーティションを追加し、
そのデータを処理しました。残りの 3 回のサイクルでは、作成した処理アプリケーションを
使用して増分処理を実行しました。

Express の手順 - 一括のローディングと集計処理
Express での一括のローディングと集計処理は、2 段階を踏む必要がありました。構造とプ
ログラムの開発、およびその実行です。

一括ローディングに対する構造とプログラムの開発
一括ローディングの開発には、プログラムのコーディング、テスト、およびデバッグを行う
必要がありました。
ファクトデータの初期ローディングと集計処理を実行するプログラムは全部で 400 行、また、
増分なローディングと集計処理を実行するプログラムは全部で 600 行になりました。
Express 開発者が、ローディングと集計処理を実行するプログラムの設計、作成、およびテ
ストを行い、データ構造をセットアップするのに丸 5 日かかりました (初期および増分、両
方のローディングと集計処理を含む) 。

プログラムの実行
プログラムを作成した後の操作は、Express のコマンドラインで、単にローディングのプロ
グラム名を入力して実行するだけでした。

一括のローディングと集計処理に関する比較の要約
OLAP Services には、すぐに使える適切なデータベース管理者用の機能が揃っています。し
かし、その処理をカスタマイズするには、外部のプログラミング言語やオブジェクトライブ
ラリ (今回は使用) を使用する必要があります。このカスタマイズは、データ ウェアハウス
を使った全てのシステムで、定型的な処理を自動化するために必要となります。マイクロソ
フトは、増分処理を定義できるデータ変換サービス (DTS:SQL Server 7 に付属のツール)
コンポーネントを提供していますが、自動処理に使用するためには同じようなプログラミン
グ上の問題があります。また、単純なカスタムプログラムと比較すると、DTS コンポーネン
トにはいくつかのトランザクションの制限があります。
Express には、データベース管理者がすぐに使える一括のローディングと集計用の機能はあ
りませんが、組合せて使える基本命令のすぐれたセットが揃っています。全てのプログラミ
ングは、Express SPL で行います。
Express では、ディメンションの構築と保守と同じように、データのローディングと集計処
理についてもきめ細かな管理が可能です。しかし、解決策の実現には、開発者のさらに大き
な努力が必要となります。
全体として、OLAP Services は Express と比較して、データベースの一括のローディング
と集計処理を格段に容易に実行できました。ローディングと集計処理のプログラム開発には、
全く時間をかける必要はありませんでした。これに対して Express では、一括のローディン
グと集計処理を行うプログラムの設計とコーディングに丸 5 日間かかりました。さらに
Express では、メインのデータベースに結合するために、データオブジェクトの追加セット
(論理変数と集計マップ) が必要となりました。
OLAP Services で、使用にあたって認識しておく必要があったのは、集計処理にどれだけの
性能向上のパーセンテージを希望するかという点だけでした。残念ながら、この数値と実際
の処理や使用されたストレージの関係は明確ではなかったため、実際の成果については推定
するしかありませんでした。プログラマが、作成された集計処理の一覧を入手して特定の集
計処理を作成することは可能ですが (または、サードパーティ製のツールも利用可能) 、
OLAP Services のこの点に関しての仕様は明確ではなく、性能を目的として最初から集計処
理をセットアップすることは不可能です。また、集計処理を調整するには、本来考えられる
以上のリソースが必要となります。つまり、集計処理の追加や削除を行ったときは、最初か
らパーティション全体を再処理する必要があります。これに対して Express では、集計処理
はローディングされたデータから (実際には適切な任意の集計処理から) 追加することが可
能です。


判定基準                            勝者
一括処理の柔軟性                        Express
一括のローディングと集計処理機能の開発と保守に要す OLAP Services
る時間と知識


付加的な計算機能
今回のケーススタディのアプリケーションでは大量のデータを扱ったにもかかわらず、必要
な計算機能はごく単純なものでした (和、差、および階層間の比率 - 例えば、親や祖先のパ
ーセンテージ) 。分析アプリケーションでは幅広い計算が必要となるため、OLAP サーバー
の計算機能は重要です。両製品の持つ計算機能の全てを説明するのは本書の範囲を超えてお
り、必要に応じてその場で各機能に触れることにします。本節では、ごく狭い範囲に焦点を
絞り、両製品の機能を概要のレベルで調べます。
計算機能の概要
OLAP Services の計算機能の概要
OLAP Services では OLAP 計算機能を、入力メジャーの集計処理と、その他全ての計算と
いう、基本的な 2 種類に分けています。入力メジャーの集計処理は、メジャーの定義に基づ
いて自動的に実行されます。データベース管理者は集計処理の物理的な特性は管理できます
が、集計処理は自動的に行われ、アプリケーションからは見えません。他の全ての計算は、
集計処理に基づいてクエリの時間に実行されます。
基本メジャーはキューブで使用される全てのディメンションのリーフレベルで入力される必
要があり、より高いレベルでは集計データとして現れます。使用できるフォーミュラは、
SUM、COUNT、MIN、および MAX だけです (これは、OLAP Services アーキテクチャが、
これらのフォーミュラの可換と分配の性質を利用しているためです) 。
OLAP Services では、基本メジャーの集計処理とは別に行われる全ての計算は、ディメンシ
ョン上の名前付きの計算対象メンバで記述されます。この計算の値はキューブには格納され
ず、計算はクエリの時間に実行されます。計算対象メンバは、代数式で記述されます。

Express の計算機能の概要
Oracle Express には、基本的な 5 種類の計算機能があります。そのうち 3 つは代数のフォ
ーミュラ、すなわち数式に基づいています。残りの 2 つ個は一括集計の演算です。
変数には、数式の計算結果を格納することができます (例えば、与えられた変数 profit、
sales、costs 間の profit = sales – costs という関係) 。計算が実行されると、値は格納さ
れたままとなります。
フォーミュラは、変数と同じく、ディメンションのセットに関連した数式です。フォーミュ
ラに対するデータ値は、常に計算が行われ、格納されることはありません。クエリや他の数
式の中では、フォーミュラは変数と全く同じように参照されます (フォーミュラは、OLAP
Services の計算対象メンバと、仮想キューブの両方の性質を持っています) 。フォーミュラ
は、Express のデータベースや付加されたデータベースの中の、任意のデータ値やプログラ
ムを参照できます。
モデルは、一つまたは複数ディメンションのメンバに対する数式の集合であり (メジャーや
フォーミュラは使いません) 、特定のメジャーを参照する必要はありません。モデルが 解釈
されると、特定の変数に適用が行われ、計算された値が格納されます。複数の数式が、1 個
または複数のディメンションの中にある 1 組のメンバに対する変数に適用されているときは、
その数式をモデルに投入すると、一度に 1 個の数式を使うことで変数計算の性能を向上させ
ることができます。モデルは、計算の対象であるメンバの名前を明示する必要があるため、
ある種の計算では有効ですが、変更の可能性のあるディメンションでの大規模な集計処理に
は役立ちません。
(モデルの利用法の一つに、制約条件付きのモデリングがあります。モデルの中の数式が互
いに依存関係にあり 1 組の連立方程式を構成するとき、Express はその数式を解いて、計算
結果の係数が対象となる変数に格納されます。)
数式を使った明示的な計算の他に、Express には ROLLUP および AGGREGATE という、格
納されたデータの和を作成する 2 つの方法があります。ROLLUP コマンドは、埋め込み-ト
ータル ディメンションとそのセルフ リレーションを使用することによって、データを総計
して変数に格納します。ROLLUP は一度に 1 個のディメンションを扱うため、複数ディメン
ションの変数を総計するには複数の ROLLUP コマンドを発行する必要があります。
ROLLUP には大きな欠点があり、オラクルは AGGREGATE コマンドでそれを解決しました。
それは、階層をさかのぼって、可能性のある全ての和が作成されてしまう点です。このため、
ディメンションの数が増加すると、データが爆発的に増加します。AGGREGATE では、追加
のデータ構造を使用することで、集計のサブセットだけを作成するようにしています。さら
に、AGGREGATE 関数は同じデータ構造と一緒に使用され、データ値を検索したり、必要な
場合は格納されたサブセットから実行時に和を計算したりします。
Express では、ディメンションの中に、実行時に計算される対象としての定義を含むことが
できません。実行時の計算は全て、フォーミュラまたは、クエリの一部である数式の中に記
述されます。

サポートされる計算機能
アプリケーションに対するサポートを評価する上で、両システムでサポートされる計算機能
のセットは重要な意味を持ちます。

OLAP Services
MDX には、基本的な算術演算機能、および、平均、カウント、相関係数、標準偏差、その
他からなる、集計機能と統計演算のセットがあります。金融関数や超越関数 (対数など) は
組み込みでは用意されていませんが、OLAP Services で構築されたアプリケーションは、外
部関数ライブラリを使ってこの機能を実現することができます (これについては後述しま
す) 。
マイクロソフトは論理演算に関して、MDX で指定することのできる if-else テスト関数を用
意しています (ただし、さらに機能の高い CASE 文はありません) 。比較演算子の基本セッ
トは用意されており、数字は数字と、文字列は文字列との比較が可能です。論理演算の結合
には、AND、OR、および NOT 演算子が使用できます。

Express
Express では、数値演算の大きなセットが組み込みで用意されています。この中には、正味
現在価値やローン返済計画などの金融関数、総計、平均、累計などの集計機能、および代表
的な超越関数が含まれています。Express ではまた、統計モデリング演算子、および予測モ
ジュールも提供されています。
Express でも、MDX と同じような if-else テスト関数が用意されています。AND、OR、お
よび NOT 演算子もサポートされています。ANY、EVERY、NONE 論理集計関数は、入力の
どれか一つが true の場合、全てが true の場合、いずれも true でない場合に、それぞれ
true を返します。

フォーミュラの優先順位
OLAP システムが代用的な表計算プログラムと比べて優れている点は、フォーミュラを一つ
記述すれば、複数ディメンションのモデルが関連する全領域にわたって値を計算できるとい
う機能です。例えば、Units Retained = Units Sold - Units Returned と定義すれば、セ
ル毎に定義しなくても、ディメンション領域の全体にわたって Units Retained が計算され
ます。Y2000 Pct Growth = (Y2000 - Y1999) / Y1999 と定義すれば、全てのメジャー
にわたって Y2000 Pct Growth が計算されます。この 2 つのフォーミュラを同時に実行す
る処理では、差の比率か、比率の差のどちらかの計算が必要であり、期待する計算結果を得
るためにはこの制御を行うことが重要です。
どちらの製品にも、和や差の後で比率を計算するなどの、ヒューリスティックスに基づいた
フォーミュラの優先順位を設定する機能はありません。

OLAP Services
OLAP Services では、全ての計算対象メンバに、関連する「解決順序」番号が付されていま
す。これらの解決順序番号は、計算を理論的に順序付けて一覧表を作るのに使用されます。
計算対象となるセルに対して、一番大きい番号を持つフォーミュラが計算に使用されます。
これらの番号は 0 ~ 231-1 の範囲にあり、サーバーで定義される計算とクライアントで定
義される計算の番号の範囲は同じです。番号が適切に割り振られているときは、これはレポ
ート作成には有効です。
例えば、サーバーで定義される全ての計算対象メンバ (重要な比率も含めて) が、10 以上の
解決順序番号を持っているとします。そして、あるクエリが実行時に、任意のユーザー定義
セットの集計処理を定義します。これらの実行時の集計処理に 0 または 1 の解決順序番号を
割当てることによって、サーバーで定義された比率は、クライアントの定義セットが集計さ
れた後で計算されます。これが可能ではあっても、クライアントの開発者とデータベース管
理者が、これらの解決順序番号について密接に連絡を取り合う必要性はあります。単純に
「このメンバをこのメンバの前に、またこの他のメンバの後に計算しなさい」とか「ディメ
ンション優先順位一覧表のここに挿入しなさい」といった指定はできません。

Express
Express には、実行時の集計処理以外に、ディメンションに対する実行時の計算機能はあり
ません。フォーミュラの優先順位は、フォーミュラ自体の依存関係によって決定されます。
フォーミュラはディメンションで実行時の計算を定義することができますが、それは新しい
キューブを作成することによって行うのであって、新しいディメンション作成を通してでは
ありません。
Express での変数の計算優先順位は、計算プログラムやユーザーとの対話によって処理され
ます。その方法は、各ディメンションのメンバの適切なセットを設定し、最初のディメンシ
ョンの計算を実行してから、制限を調整して 2 番目のディメンションの計算を実行します
(以下も同様です) 。この設定処理は、手動で行います。

フォーミュラに関するアプリケーションの範囲
フォーミュラに関しては、計算する必要がある場所と計算してはいけない場所があり、優れ
た OLAP システムにはフォーミュラがどこで有効かを指定する簡単な方法があります。例え
ば、企業内の違う部署では、収益性の計算に別のフォーミュラを使う場合があります。これ
は、ディメンションのフォーミュラの優先順位とは少し異なる問題です。というのは、名前
付きの計算が競合したときにどのように解決するかということではなく、単一の名前付き計
算に関する処理だからです。

OLAP Services
OLAP Services では、全ての計算対象メンバは、他の全てのディメンションにある全てのメ
ンバとの間で計算を行います。しかし、計算対象メンバは、他のディメンションにあるメン
バの状態に応じて別のフォーミュラを使用することができます。MDX とそれに対する マイ
クロソフトの拡張機能が提供する一連の基本命令を使えば、計算が実行されているセルのコ
ンテキストを作成することができ (その名前、現状のレベル、特定のレベルでの祖先メンバ、
その他) 、このコンテキストを IIF 関数でテストすることができます。

Express
Express での変数の計算はプロシージャ的に行われるため、別のキューブ領域の計算を他の
領域とは別の方法で行うことが極めて簡単に実現できます。適切な領域に対して、適切な数
式が 1 段階ずつ適用されます。必要な場合は、ある数式が他の数式の計算結果を単純に書き
換えることも可能です (これが望ましくないときは、禁止しておく必要があります) 。フォ
ーミュラはまた IF () を使用して、どのディメンション領域でどの数式を使用するかを決め
ることができます。
未知のデータと適用不能データ
計算を頻繁に使用するシステムで重要なのは、利用不可能なデータをどう扱うかという点で
す。
存在しないことと意味がないことを区別して処理するという点については、両製品は共に、
まだ開発の段階にあることが分かりました。両製品とも、適切に得られた解を、うまくつな
ぎ合わせることができるだけです。特に、どちらの製品も、利用不可能と適用不可能の状態
を区別することができません。このため、例えば、メーカーの製品の在庫がないとか、倉庫
から出荷されていないという報告で空のデータが返ってきたとき、その製品が売れていない
ためなのか、まだ発売されていないためなのかのどちらであるかが分かりません。両製品と
も、アプリケーション開発者が、それを識別できるなんらかの手段を考える必要があります。

OLAP Services
OLAP Services では、値が NULL かどうかを調べる計算が可能です。しかし、NULL と適用
不可能の区別はできません。セルや数式の計算結果が NULL かどうかを調べるには、
ISEMPTY 関数を使用します。計算のときに NULL 値が使用されると、デフォルトのロジッ
クが適用されて、結果を NULL にするかどうかが決定されます。例えば、NULL が NULL に
加えられた場合、結果は NULL になります。しかし、NULL が非 NULL 値と一緒に使用され
た場合は必ず、NULL は暗黙的に 0 として扱われます。従って、if (0 = NULL, 1, 0) は常
に 1 を返します。

Express
Express では、テストできる最初の値は NA (適用不能) です (すなわち if (sales eq NA)
となります) 。NULL (利用不可) と適用不能の区別はありません。
NA が計算処理で NA と 0 のどちらで使用されるかは、クライアントのデータベースセッシ
ョンの中にある NASKIP2 の設定値によります。この設定が false のときは、計算処理への
入力は必ず NA であり、結果は NA となります。NASKIP2 が true に設定されている場合は、
NA は 0 として扱われます。

計算処理での順序付けの使用
さまざまな分析を行う上では、計算処理で順序付けを使用することが重要です。時間をベー
スとするレポーティングでは、year-to-date または移動平均の計算を行うとき、時間メン
バが順番に並んでいることが前提となっています。順位をベースとする累積計算を行うとき
は、累積の対象となる顧客、製品、地域、または他のメンバが、累積される変数に関して順
番に並んでいることが前提となります。

OLAP Services
ディメンションから読み込まれるメンバの全てのサブセットは、そのディメンションで定義
された組み込みの順序付けを持っています。サブセットに複数レベルからのメンバが含まれ
ているときは、順序付けは位相的になり、元のデータベースで決定されます。計算処理では、
メンバまたはタプルの名前付きセットを任意の順序に定義して、一覧表の中でメンバを前に
または後に順番に参照することができます。しかし、これを行うための構文は複雑であり、
セットの数が増えると処理が遅くなります。

Express
Express での全てのディメンションの状態リストは、常にある任意でないの順序付けがして
あります。デフォルトでは、リストのメンバの順序は、ディメンションのメンバの順序と一
致します。しかしメンバは、状態の中の前面、中間、または後面に追加することができ、ま
た、状態を任意の基準で並べ替えることもできます。SPL ルーチンを使用すれば、ディメン
ションの状態の各メンバを次々に見ていって、累積などのある種類の演算を適用することが
できます。それによって、累積の加算が比較的効率よく、簡単にコーディングできます。

外部定義の関数
マイクロソフトとオラクルは共に、自社のエンジンの中に計算機能関数の大規模なセットを
持っていますが、用意されていない追加の関数がアプリケーションで必要になることがよく
あります。OLAP Services と Oracle Express の両製品とも、組み込みの計算機能を外部定
義の関数で拡張する機能を提供しています。

OLAP Services
OLAP Services では、外部の ActiveX 関数ライブラリを使用することができます。また、
外部関数にデータ値のセットを渡すための仕組みが提供されているため、広い範囲の追加関
数を使用することができます。追加のカスタム関数の作成は、Visual Basic などの言語を使
用して簡単に行うことができます。これらの関数は、スタンドアロンシステムだけでなく、
大規模なソフトウェアシステムとも連携することができます。OLAP Services ではライブラ
リ内に含まれるタイプライブラリが読み込まれるため、使用する関数を別に指定する必要は
ありません (また、その方法もありません) 。関数ライブラリは、クライアントアプリケー
ション (通常は、クライアントワークステーション) に PivotTable Service を提供する階層
と同じ場所にある必要があります。Microsoft Excel および Visual Basic for Applications
のライブラリには多数の関数セットが提供されており、この方法で使用することができます。
これらは OLAP Services 製品には含まれていませんが、一般に広く普及しています。
関数は、数値やテキスト値だけを返す場合や、テキスト、数値、または配列などの入力引数
だけを受け付ける場合があります。Null 値を関数に渡すことができる場合もあります。関数
が呼び出されるのは、クエリ要求に対する応答のときだけです。

Express
Express では、Windows のプラットフォームで DLL としてコンパイル済みの、外部関数ラ
イブラリに結合する機能が提供されています。Express に対して関数の引数を記述するには、
別の EXTCALL 定義が必要となります。ライブラリがデータベースとは別に大規模になった
場合には、これが保守上問題になります。Windows の環境では、関数は標準の C 関数とし
てしか呼び出すことができません (__declspec (dllexport) DLL エクスポート規則と
_cdecl 呼び出し規則を使用) 。開発者は、Express で必要となるデータ交換の仕組みを理解
して、コード中にオラクルのデータ型定義を使用する必要があります。ライブラリは、
Express サーバーの階層で利用可能になっている必要があります。
Express の外部関数は、テキストおよび数値を返す以外に、テキスト、数値、および論理の
引数を受取り、これらの引数値を変更することができます。こうすることによって、1 つの
外部関数が、1 回の呼び出しで複数の変数の値を変更することが可能となります。関数はク
エリの計算のときだけでなく、プログラムからも呼び出すことができます。

計算機能の比較サマリ
今回調査した詳細なレベルでは、両製品の計算機能は、用意したアプリケーションには十二
分なものです。Express には、統計モデリングや予測モジュールを含む、固有の計算機能の
大規模なセットが揃っています。Express のモデルは、モデリングアプリケーションの連立
方程式も解くことができます。OLAP の計算の大きな部分 (比率、差、時間ベースの遅延や
先行、その他) については、両製品の機能はほとんど同等です。順序付けが、格納順序では
なく、順位をベースにしているときは、累積平均や和の計算は、 Express の方が OLAP
Services より簡単です。しかし、Express の計算機能を使用するときは、数式かモデルか、
変数かフォーミュラかなど、検討すべき事項も数多くあります。aggmap で集計した変数に
対して Aggregate () 関数を使用した場合は、計算処理のセットがさらに複雑になり、計算
処理をどのように作成するかという点に大きな影響が出ます (このうちのいくつかについて
は、次の節で調べます) 。OLAP Services では、集計されたファクトデータに基づく全ての
計算は、均一に指定することができます。
両製品とも機能を拡張することができますが、開発者がより大きな努力を必要とするのは、
Express 関数とその利用方法の方です。Excel と VBA の関数ライブラリは OLAP Services
には含まれてはいませんが、一般に広く普及しており、インストールされていれば自動的に
利用できます。


判定基準                                勝者
サポートされている関数のセット                     Express
ディメンション計算のサポート                      OLAP Services
順序付けをベースとする計算                       Express
空データの処理                             (引き分け)
外部の関数ライブラリ                          (引き分け)
計算モデルの簡易性                           OLAP Services


クエリ
OLAP アプリケーションの目的は、もっぱらユーザーのクエリをサポートすることにありま
す。従って、データの問合せ (クエリの発行) に関連する項目は非常に重要です。

言語
OLAP Services では、MDX クエリ言語の拡張バージョンを使用しています。その仕様は、
OLE DB for OLAP 1.0 仕様書 (http://www.microsoft.com/data/download.htm で入
手可能) に記述されています (この言語は SQL と同じである、または SQL がベースになっ
ていると言う人もいますが、共通なのは 3 つのキーワードだけであり、全く独自の言語で
す) 。
MDX は、本質的に宣言的なクエリ言語と性格付けることができます。状態に影響を与える
いくつかの基本命令はありますが (CREATE SET や USE LIBRARY など) 、その他は全て、
宣言とクエリ文から成っています。一連の CREATE SET コマンドを別にすれば、全ての処
理は宣言によって定義され、順次処理を記述する方法はありません。
Express ではクエリにも、DDL と同じ SPL 言語を使用します。Express では、データベー
スへのクエリを専門に行うセッションと、データベース管理者の作業やデータの操作を専門
に行うセッションとの間には特に区別はなく、ただ、セッションが元のデータベースの永久
ストレージを更新できるかどうかが異なるだけです。このため、クライアントから、そのセ
ッションのクエリと計算処理を行うメタデータオブジェクトを簡単に定義して更新すること
が可能です。
クライアントから Express へのクエリの発行は、宣言による指定と手続き的な仕組みのどち
らも使用することができます。また、データに対する要求をクライアントが直接発行するこ
とも、サーバー上のプログラムを実行してからクライアントにセルデータを戻すことも、ど
ちらも可能です。必要であれば、効率的に実行するために、サポートされている手続き的な
仕組みでクエリを作成することもできます。

クエリ API
API を量的または質的に比較する作業は、本書の範囲を超えています。ここでは、API を簡
単に記述しておきます。
OLAP Services では、OLE DB for OLAP API を使用しています。これはマイクロソフトの
OLE DB の拡張版であり、OLAP 機能への追加サポートを提供します。OLAP メタデータは
レコードのセット (行セット) で記述され、また、OLAP クエリは基本的にスタースキーマと
なります。このスキーマには、セルのセットを検索してクライアントのメモリに格納する処
理に対して最適化されたアクセスメカニズムが含まれています。
基本的に、クライアントがメタデータを要求するときは、クライアントがデータを要求する
ときとは全く別の言語が使用されます。メタデータの要求は、完全に手続き的な手段を通し
て行われます。クライアントのプログラムが、対象とするメタデータの行セットに関連する
データ構造に値を設定してから、行セットから行データを読み込みます。クライアントは、
MDX クエリを使って、ディメンション メンバに関する情報を要求することができます。こ
れは、キューブの計算結果を要求するクエリを作成して、それを実行することによって行い
ますが、セルの計算結果と他のディメンションの計算結果は廃棄します。
OLE DB for OLAP が重要なのは、関連するデータ構造と技法のほとんどが、正規の OLE
DB と共通しているという点です。OLAP と、プログラム中のリレーショナルデータベース
アクセスルーチンの間で、コード技法を共通化することができます。データベースとの接続
を一つだけ確立して、それに対して SQL と MDX クエリの両方を発行することは、アーキテ
クチャ的には実行可能です。
Express では、クライアントのクエリを始めとする、クライアントとサーバー間の全ての通
信に SNAPI (構造化 N ディメンション API) を使用しています。SNAPI インタフェースの
ドキュメントは、製品に添付されている Oracle Express SNAPI ガイドにあります。テキス
ト形式のコマンドがサーバーに渡され、その中の FETCH コマンドによって、マルチディメ
ンションの計算結果構造が作成され、クライアントアプリケーションからのアクセスが可能
になります。
全てのメタデータとデータのクエリに、同じコマンドとデータ構造が使用されます。SNAPI
のインタフェースは、非常に簡単に使用できます。

クエリの指定機能
ディメンションの指定
OLAP システムの価値を決める鍵は、データのディメンション構成です。柔軟なディメンシ
ョン構成を取ることによって、値の比較や値の相互結合に、さまざまな便利な方法が使える
ようになります。ディメンション空間でのデータ参照の技法セットが強力であればあるほど、
ローディングした OLAP データベースに対して実行できるクエリと計算処理の種類は多くな
り、またそれらの開発も容易になります。
OLAP Services と Express のどちらにおいても、任意のディメンション参照機能が提供さ
れています。これには、名前、遅延や先行の関係、および階層の参照 (先祖や子孫の関係)
に基づくメンバ指定が含まれています。参照の基本命令は、任意につなげることができます。
OLAP Services のディメンションは内部の階層構造を持っているため、これらの命令は、デ
ィメンションのコンポーネントに対する演算として表現されます。階層構造は、Express の
ディメンションには元々備わっていません。そのため、階層的な参照を行うには、関係情報
と、通常は名前付け規則を通して結合された追加のディメンションを利用する必要がありま
す。また、サポートされている階層ディメンションとレベルディメンションの現在の状態を
そのまま保つことも必要となります。
Express では、ディメンションの参照と指定のための入力として、テキストのフォーミュラ
が使用できます。これを利用して、アプリケーション開発者は、カスタムのディメンション
参照関数を作成することができます。OLAP Services では、これらの参照を関数として実装
する方法はありませんが、各クエリで同等の参照を実行することは可能です。
OLAP Services では、別の階層を別のディメンションとして作成しようとすると、多階層デ
ィメンションの中の参照が想像以上に困難になります。実際に、単純な year-to-date の販
売の計算対象メンバを作成しようとしましたが、それは不可能でした。どのキューブにも、
時 間 の デ ィ メ ン シ ョ ン が あ り ま せ ん 。 代 わ り に 、 Time.ByMonth デ ィ メ ン シ ョ ン と
Time.ByWeek デ ィ メンション が存在します 。従って、 Weekly year-to-date および
Monthly year-to-date の販売メンバを作成する必要がありました。また、さらに拡張を予
定していた時間の階層に適合したメンバだけにクエリを出すことを覚えておく必要もありま
した。

計算処理
OLAP Services では、クエリ内の全ての計算処理が、計算対象メンバを通して実行される必
要があります。このメンバは、名前付きで、そのクエリ内部で定義できる必要があります。
計算対象メンバは、キューブの任意のディメンションで定義することができます。また、複
数のディメンションからの計算対象メンバが混在したときは、解決順序プロパティによって
フォーミュラが順序付けられ、ディメンションの優先順位が決定されます。
MDX 言語では、全てのディメンションが同等に扱われます。ただし OLAP Services では、
メジャー ディメンションは他のディメンションタイプとは区別され、メジャーによって集計
関数とデータ型が割当てられます。また、任意の計算処理は任意のディメンションに割当て
ることができ、全てのメンバとタプルの表現式を任意のディメンションに適用することがで
きます。例えば、順序付けクエリをメジャーメンバのセットに適用することが可能です。
Express では、クエリの全ての計算処理が、特定の名前付き変数 (または、変数と似ている
が実行時に計算される、フォーミュラ) を通して実行される必要があります。このように、
実行時の計算は Express でサポートされていますが、OLAP Services の場合より明確に指
定する必要があります。
例 え ば OLAP Services で は 、 特 定 の 時 期 に 対 す る ク エ リ の 中 に 計 算 対 象 メ ン バ
[YearAgoPctDiff] を定義して、1 年前の同じ時期に対する各メジャーのパーセンテージの
差を計算することが可能です。[YearAgoPctDiff] メンバは全てのメジャーで計算を行うた
め、1 個のクエリで、販売ユニット数と販売ドル額の year-to-year のパーセントの差を求
めることができます。これを実行する MDX クエリは、次のようになります。


WITH
MEMBER [Time.ByMonth].[YearAgoPctDiff] AS
‘ (     [Time].[ByMonth].[All Time].[1998]
  / ParallelPeriod     ([Time] .[ByMonth].[Year],
           [Time] .[ByMonth].[All Time].[1998], 1) )       – 1’
      , SOLVE_ORDER = 10
SELECT
{ [Time].[ByMonth].[All Time].[1998],
  [Time].[ByMonth] .[YearAgoPctDiff] } on columns,
{ [Measures].[Members] } on rows
from Sales
WHERE      ([Customer].[All Customer].[East Coast].[NY], ...)


                               1998                 YearAgoPctDiff
ユニット数                          100                  1.25
ドル                             250                  1.00
Express では、今回定義した販売キューブと返品キューブは、勘定科目 ディメンションで表
現されます。これにより、処理は簡単になります。つまり、各メジャーに対して別の計算処
理を要求する代わりに、YearAgoPctDiff を計算する 1 つのフォーミュラを指定することが
できます。次の SPL で示すように、クエリ内の (一般的には、実行時の) このような計算処
理は、時間ディメンションの新しい要素というより、新しい変数のように見えます。
limit customer to ‘NY’
REPORT down meas_sales across: a_sales       (year ‘1998’)   –
heading ‘YearAgoPctDiff’ lagpct       (a_sales   (year ‘1998’) , year, 1)


OLAP Services システムで、計算対象メンバ [Avg Price Per Unit] をクエリに追加した場
合は、次のクエリによって、ユニット当たりの平均単価と、ユニット当たりの平均単価のパ
ーセンテージの変化を求めることができます:
WITH
MEMBER [Measures].[Avg Price Per Unit] AS
‘[Measures].[Sales Dollars] / [Measures].[Units]’
  , SOLVE_ORDER = 5
MEMBER [Time.ByMonth].[YearAgoPctDiff] AS
‘ (     [Time].[ByMonth].[All Time].[1998]
  / ParallelPeriod     ([Time].[ByMonth].[Year],
                       [Time] .[ByMonth].[All Time].[1998], 1) )     – 1’
  , SOLVE_ORDER = 10
SELECT
{ [Time].[ByMonth].[All Time].[1998],
  [Time].[ByMonth].[YearAgoPctDiff] } on columns,
{ [Measures].[Members], [Measures.[Avg Price Per Unit] } on rows
from Sales
WHERE    ([Customer].[All Customer].[East Coast].[NY], ...)


次の計算結果のマトリックスが得られます:
                                1998              YearAgoPctDiff
ユニット数                           100               1.25
ドル                              250               1.00
ユニット当たりの平均単価                    2.5               0.80

しかし Express では、データベース管理者やアプリケーションの介在がない場合は、2 番目
のエッジでのこの追加の計算は 1 個のクエリでは実行することができません。介在がない場
合、1 個のクエリで要求できるのは、sales 変数、sales 変数に対する percentage-to-
year-ago の比率、ユニット当たりの平均単価、およびユニット当たりの平均単価に対する
percentage-to-year-ago の比率です。しかし、単純な表現を使って入手しようとしたとき
と全く同じ結果を得ることはできません:
limit customer to ‘NY’
REPORT down meas_sales –
across: a_sales            -
heading ‘YearAgoPctDiff               (sales) ’ –
     lagpct     (a_sales       (year ‘1998’ ) , year, 1)        -
heading ‘Avg Price’ –
      (    a_sales      (meas_sales ‘SalesDollars’ year ‘1998’)            –
      / a_sales        (meas_sales ‘Units’ year ‘1998’) )           -
heading ‘YearAgoPctDiff               (Avg Price) ’ –
     lagpct     (    a_sales     (meas_sales ‘SalesDollars’ year ‘1998’)       -
                / a_sales       (meas_sales ‘Units’ year ‘1998’) , year, 1)        )


                    1998       YearAgoPctDiff       Avg Price Per YearAgoPctDiff (Avg
                               (sales)              Unit          Price)
ユニット数               100        1.25                 2.5                 0.80
ドル                  250        1.00                 2.5                 0.80

その代わりに、2 つの別個のクエリを発行して、その結果をつなぎ合わせる必要があります。
これを行うには、クライアントプログラムで、クエリ生成と結果表示の両方に追加のコーデ
ィングが必要となります。
両製品とも、この結果を作成するのに、データベース管理者の助けを受けることも考えられ
ました。OLAP Services では、上で示したのとほとんど同じ定義を使って、Avg Price Per
Unit に対する計算対象メンバをキューブに加えることもできました。Express の場合は、こ
こでもこの計算の実行方法を選択できるため、メジャー ディメンションが良さそうに見えま
す。これらの方法では全て、メジャー ディメンションに「AvgPrice」のメンバが追加され
ます。
変数の値を先行計算するのに、一つの方法があります。units と sales の変数がローディン
グされ、集計されているときは、SPL で次のように簡単に計算できます:
sales        (Meas_Sales ‘AvgPrice’)         = -
     sales     (Meas_Sales ‘SalesDollars’)           –
      / sales       (meas_sales ‘Units’)         ACROSS SALESC_MOPCTY


しかし、Aggregate 関数を使用して sales メジャーの和を実行時に計算する場合は、さらに
ロジックを加えて、クライアントがより低いレベルの平均単価の和を見に行かないようにす
る必要があります。
もう一つは、常に値を計算する方法です。sales に対する実行時の集計処理は、利用しやす
いように既にフォーミュラにカプセル化してあります。フォーミュラのレイヤをもう一つ追
加 し て 、 要 求 さ れ て い る メ ジ ャ ー が 「 AvgPrice 」 の と き に 、 集 計 さ れ た ド ル の 金 額
(dollars) とユニット数 (units) の比率を計算することができます:
if        (meas_sales eq ‘AvgUnits’)         -
then         a_sales      (Meas_Sales ‘SalesDollars’)       –
          / a_sales       (meas_sales ‘Units’)       -
else a_sales
しかし、これによって既に格納されているデータが大きな影響を受けます。これらの比率は
格納したくないため、メジャー ディメンションを、その変数についても同じように希薄とす
るように宣言することはできます。しかし、ここに値が格納されることはないため、これに
よって希薄の考え方がある意味で損なわれます。これを解決するために、2 番目のメジャー
ディメンションを作成し、格納されたキューブのディメンションと関連付け、それを使って
アクセス式を設定するようにすれば、メジャー ディメンションの密度を保つことができます。
データの再ローディングを避けて、メジャー ディメンションにこの計算処理を追加する必要
がある場合は、ディメンション、関連付け、およびフォーミュラの追加が必要になります。
リードオンリーのセッションにあるアプリケーションも、これを実行することができます。
しかし、これを実現するには、相当高度な技術を持ったアプリケーション開発者が必要とな
ります。
この方法ではまた、ディメンションの優先順位は、単純に、他の参照を行っている 1 つのフ
ォーミュラまたは表現式によって処理されます。

クエリモデル
両製品のクエリモデルを詳細に記述することは、本書の範囲を超えています。両製品のクエ
リモデルはかなり異なっており、ここでは重要な相違点だけを取り上げて説明します。
MDX のクエリモデルは、元のデータベースから抽出されたものです。クエリには、タプル
の順序付けられたコレクションが入っています。ここで、タプルとは、1 つのディメンショ
ン内の 1 つのメンバ、または異なるディメンションにある個々のメンバの組合せです。この
意味では、タプルはディメンション メンバと同じように扱うことができます (例えば、タプ
ルに関する並べ替えやフィルタリング) 。タプルはまた、コレクションの中に複数回現れて
も構いません。タプルの大きさや構成の事前定義は、名前付きセットの中でクエリ単位に設
定されるだけであり、それ以外に行う必要は (また、方法も) ありません。タプルは、どん
な条件下でも、個々にフィルタによって取り除くことができます。この一例として、クエリ
の結果に関連データがないという条件でタプルをフィルタで除外するときは、MDX 言語の
一部としての特別な NON EMPTY キーワードを使用します。
OLAP Services のキューブクエリでは、新しい、キューブに似た結果が得られます。結果の
ディメンション (データベース ディメンションと区別するために、軸と呼ばれます) は、先
に述べたタプルで構成されています。
Express のクエリモデルは、もっと直接的に元のデータベースと対応しています。クエリか
らは、1 個または複数のデータベース ディメンションに応じた結果が返ってきます。結合デ
ィメンションを使用して、複数ディメンションのタプルを作ることができます。実際に、一
時的な結合ディメンションを使用して、クエリの結果に完全に空のタプルが現れないように
するといった動作を実現することができます。結合はクエリが実行される前に定義しておく
必要があるため、結合をクエリの動作の一部として定義するか、データベース管理者が事前
に定義しておくかのどちらかが必要です。
Express での全てのクエリは、各ディメンションの現在の状態に対して発行されます。この
状態は各ディメンションに対して個別に設定でき、増分によって変更することができます。
データ値が取り出されたときや、ディメンションを使用する変数やフォーミュラに対して計
算が実行されたとき、これらの動作はディメンションの状態の範囲を遷移するだけです。こ
れにより、クライアントは、同時に全てのキューブに対して、サーバーでのナビゲーション
状態を維持することができます。
MDX のクエリには、状態がありません。各クエリでは、他のクエリの結果とは独立な結果
セットが定義されます。MDX では、ディメンションの状態と同じような効果を持つ名前付
きセットが提供されていますが、それぞれの名前付きセットはキューブに特定され、それが
必要なときはクエリに明示する必要があります。
前に述べたように、MDX のクエリでは、計算処理は任意のディメンションに対するクエリ
の中に定義できます。これに対して、Express のクエリは、新しい変数と等価な変数を計算
できるだけです。

ユーザー定義のメンバセット
両製品とも、エンドユーザーが選択処理や計算処理で使用するためのメンバセットを定義す
る機能を持っています。OLAP Services では、これは名前付きセットを作成することによっ
て行われます。この名前付きセットは、その他の点では、クエリ中のタプルセットと同じよ
うな動作をします。Express では、これは値セットを作成することによって行われます。値
セットは、基本ディメンションまたは結合ディメンションのメンバセットであっても構いま
せん (ただし、合成ディメンションは除きます) 。これらには、極めてよく似た機能があり
ます。Express の値セットは、データベースの中に保存して、後で使用することができます。
エンドユーザーによって作成された名前付きセットは、OLAP Services のデータベースには
保存できません。データベースに保存するには、データベース管理者の機能が必要となりま
す。

サマリ
OLAP Services と Oracle Express は共に、今回作成した分析システムに必要な全ての機能
を備えた高機能 OLAP データベースです。
両製品は共に高度な機能セットを有していますが、その方向性はかなり異なっています。
Oracle Express は、OLAP データの基本命令については、小さなコアセットを提供してい
ます。これらの基本命令は多くのユーザーにとってレベルが低すぎるため、同じような機能
と追加の性能や関数を持つ、関連する OLAP 基本命令のより大きなセットもあります。また、
それらを組合せる方法に関する、オプションの大きなセットもあります。Express には、宣
言による計算と手続き的な機能の両方が提供されており、Express の環境で非常に幅広いア
プリケーションを直接開発することができます。その一方で、このプラットフォームを効率
的に使用するには、特に重要なアプリケーションでの使用には、与えられた環境や望ましい
アプリケーション特性の多くの面について、膨大な知識が要求されます。
これに対して、Microsoft OLAP Services で提供されている OLAP データ基本命令のコアセ
ットは、Express に比べてそれほど大きくはありませんが、内部構造に豊富な機能があり、
しかも操作が容易です。ディメンションとキューブは明確に分離され、開発者が検討しなけ
ればいけない論理的および物理的なトレードオフが緩和されています。ただしこの容易さは、
OLAP データベースのある側面においては、いくらか柔軟性の不足にも繋がっています。特
に、階層についての OLAP Services の概念は、多くのアプリケーションには単純すぎます。
さらに、OLAP Services が機能を提供しているのは、ファクトテーブル変数の集計処理とセ
ルをベースにした計算機能の領域だけです。従って、他の機能を必要とするアプリケーショ
ンを作成するには、他の環境や言語を取り入れる必要があります。OLAP Services の全体的
な計算機能やアプリケーション機能は、Express に比べると低いレベルにありますが、提供
している機能については非常に強力であり、また開発者にとっては概念的により簡潔であり
明解でもあります。
機能的な観点からみた場合、OLAP Services は、Express の開発者が明示的に処理する必
要のある作業の多くを、内部に組み込んでいます。例えば、OLAP 構造を設定するための
SQL の全生成作業は、宣言での関係性と OLAP メタデータプロパティへの応答として、
OLAP Services によって実行されます。OLAP Services のスキーマが変更された場合も
(例えば、新しいメンバ属性の追加) 、その変更は自動的に組み込まれます。これに対して、
Express での SQL の生成処理は手動で行います。OLAP 構造の設定も、OLAP Services の
内部で実行されます。Express の開発者は、SQL カーソルをオープンして、戻り行の参照を
繰り返し、OLAP 構造を更新するコードを手続き型のループで作成する必要があります。ア
プリケーションの構造が変更になると、この手続きのコードも保守する必要があります。こ
れに対して、OLAP Services には、検索データを使用したり、ディメンションやキューブを
設定したりするための処理ロジックが含まれています。機能的に等価なデータベースを作成
する開発日数としては、OLAP Services では、ディメンション、キューブ、属性、および計
算処理の全てに対して 1 日半もかかりませんでした。Express で同等の構造を設計して開発
するのには約 5 日を要しました。
データ型やプログラミング機能という点では、Express の方が開発者により大きな柔軟性を
与えるというケースもあり得ます。確かに、より多くのデータ型や演算の種類が提供されて
います。しかし、今回の場合、追加されたデータ型やプログラムを使用した主な目的は、た
だ単に、データのローディング、集計処理の計算、クエリ結果の検索など、処理の中心部分
を実現するためでした。OLAP Services の場合は、機能が内部に組み込まれているため、こ
れらの処理は必要ありません。
今回のケーススタディでは、あらゆる面で OLAP Services での開発の方が全体的に短時間
で済みました。この一つの理由は、OLAP Services では、ディメンションとキューブの設計
とローディングの主要な部分の必要な全てに GUI インタフェースが提供されていたのに対し
て、Express ではプログラムの開発が必要だったという点にあります。しかも Express で
の開発では検討すべき事項が常により多く存在しました。各ディメンションと変数の設計で
は、いくつかの内部決定が必要になっただけでなく、外部に依存する論理的または物理的な
問題も発生しました。Express の設計での多くの決定は、熟練した Express 開発者によっ
て迅速に行うことができますが、決定すべき問題や必要となる知識も多く、これが開発を遅
らせる要因になります。
今回は両製品を 1 組の特性を持った 1 アプリケーションのサポートという観点だけから見
てきました。アプリケーションの種類や、機能的および操作上での要件の多様性としては、
今回調査した項目以上に多くのものが存在します。しかし、報告や分析を行う多くのアプリ
ケーションが最初に選択するのはデータ ウェアハウスやデータマートであり、提供されるデ
ータに基づいた計算機能の多様なセットが必要とされると考えられます。今回の調査で判明
し た の は 、 こ の 考 え が 正 し い と す る と 、 計 算 と ク エ リ の 高 度 な 機 能 に よ っ て 、 OLAP
Services が非常に迅速な開発環境を提供しているという点です。
付録: 測定した性能指標
この付録では、測定されたデータベースの時間的な指標を簡単に説明します。ここで説明するの
は、キューブの処理時間とクエリ実行時間のサンプルの 2 つです。
ケーススタディのデータベースのキューブは、2 個の別個の OLAP データベースに作成されまし
た。片方のデータベースでは、キューブは全て 30%の集計処理サポートに最適化し、もう一方
は全て 45%のサポートに最適化しました。
最初の処理バッチでは、1999 年 11 月の第 1 週までのデータを含めて、全キューブの全パーテ
ィションを処理しました。バッチ 2 から 10 まではそれぞれ、1999 年のパーティションの増分
処理で、1999 年の末まで 1 個の新しい週のデータを組み込みました。バッチ 11 は、2000 年
第 1 週のデータの完全な処理時間を表し、バッチ 12 と 13 は、2000 年パーティションの 1 月
のデータに対する、さらに 2 回分の増分処理を表します。毎月の在庫状態キューブは、月の最終
週が記録されたときだけ処理されました。
各キューブに対して、そのキューブに対する各バッチを処理する時間と、処理バッチで読み込ま
れた行数を記録します。さらに、全体の処理時間 (仮想キューブの処理と処理の起動オーバーヘ
ッドは無視) と、処理バッチが終了したときのデータベースのサイズを記録します。全体のデー
タベースサイズには、全てのディメンション、キューブパーティション、および他のデータベー
ス関連のファイルが含まれます。
密度 30%、MOLAP ストレージでのキューブ処理
30 %
       キューブ
バッチ    販売                     返品                    在庫の変化
       時間         行数          時間        行数          時間        行数
1      16:48:46   47,141,96   0:48:39   3,730,628   1:13:15   34,800,00
                  3                                           0
2      0:24:49    794,200     0:01:37   20,246      0:02:26   174,000
3      0:25:09    794,899     0:01:49   39,526      0:02:28   174,000
4      0:25:18    797,233     0:02:06   62,274      0:02:28   174,000
5      0:26:01    791,119     0:02:10   63,596      0:02:30   174,000
6      0:32:59    1,119,013   0:02:15   63,491      0:02:33   174,000
7      0:37:32    1,355,121   0:02:18   65,308      0:02:31   174,000
8      0:38:06    1,357,708   0:02:57   100,787     0:02:31   174,000
9      0:27:18    727,584     0:03:05   108,320     0:02:36   174,000
10     0:16:18    116,403     0:03:05   91,366      0:02:37   174,000
11     0:05:39    241,570     0:00:55   36,627      0:02:07   174,000
12     0:06:42    240,607     0:01:04   16,944      0:02:10   174,000
13     0:07:01    241,297     0:01:06   19,025      0:02:11   174,000
30 %
       キューブ
バッチ    毎週の在庫                毎月の在庫                 全体のキュー 全 体 の デ ー
       状態                   状態                    ブ処理時間  タベースサ
                                                         イズ
       時間        行数         時間        行数          時間         バイト数
1      0:42:17   34,800,000 0:15:33   8,874,000   19:48:30   10,181,69
                                                             3,841
2      0:02:19   174,000    0:02:02   174,000     0:33:13    10,381,34
                                                             4,561
3      0:02:19   174,000                          0:31:45    10,581,70
                                                             0,112
4      0:02:22   174,000                          0:32:14    10,781,18
                                                             2,886
5      0:02:25   174,000                          0:33:06    10,984,79
                                                             4,800
6      0:02:25   174,000    0:02:02   174,000     0:42:14    11,229,69
                                                             5,469
7      0:02:23   174,000                          0:44:44    11,497,38
                                                             8,689
8      0:02:26   174,000                          0:46:00    11,774,93
                                                             8,299
9      0:02:26   174,000                          0:35:25    11,980,82
                                                             4,129
10     0:02:28   174,000    0:01:49   174,000     0:26:17    12,098,75
                                                             3,790
11     0:01:55   174,000                          0:10:36    12,216,42
                                                             0,833
12     0:01:58   174,000                          0:11:54    12,307,26
                                                             2,166
13     0:01:58   174,000                          0:12:16    12,423,90
                                                             6,894
密度 45%、MOLAP ストレージのキューブ処理
45 %
       キューブ
       販売                      返品                     在庫の変
                                                      化
バッチ    時間         行数           時間        行数           時間        行数
1      26:13:41   47,141,963   2:03:44   3,730,628    1:42:33   34,800,000
2      0:34:19    794,200      0:03:33   20,246       0:02:44   174,000
3      0:34:05    794,899      0:04:30   39,526       0:02:43   174,000
4      0:34:43    797,233      0:05:38   62,274       0:02:43   174,000
5      0:35:29    791,119      0:05:57   63,596       0:02:47   174,000
6      0:31:31    1,119,013    0:06:21   63,491       0:02:48   174,000
7      0:36:26    1,355,121    0:06:38   65,308       0:02:47   174,000
8      0:51:59    1,357,708    0:08:06   100,787      0:02:48   174,000
9      0:37:12    727,584      0:08:35   108,320      0:02:51   174,000
10     0:24:12    185,571      0:08:22   103,598      0:02:53   174,000
11     0:07:57    241,570      0:02:26   36,627       0:02:22   174,000
12     0:09:30    240,607      0:02:44   16,944       0:02:42   174,000
13     0:09:49    241,297      0:02:55   19,025       0:02:41   174,000


45 %
       キューブ
       毎週の在庫                   毎月の在                  全体のキュー 全 体 の デ ー
       状態                      庫状態                   ブ処理時間  タベースサ
                                                            イズ
バッチ    時間         行数           時間        行数          時間          バイト数
1      0:48:06    34,800,000   0:18:14   8,874,000 31:06:18      15,323,63
                                                                 8,491
2      0:02:25    174,000      0:02:07   174,000     0:45:08     15,567,91
                                                                 7,854
3      0:02:23    174,000                            0:43:41     15,819,39
                                                                 7,217
4      0:02:25    174,000                            0:45:29     16,110,09
                                                                 7,448
5      0:02:25    174,000                            0:46:38     16,404,82
                                                                 5,323
6      0:02:28    174,000      0:02:05   174,000     0:45:13     16,738,27
                                                                 0,040
7      0:02:25    174,000                            0:48:16     17,101,39
                                                         2,310
8      0:02:28   174,000                       1:05:21   17,463,69
                                                         0,709
9      0:02:27   174,000                       0:51:05   17,755,56
                                                         4,694
10     0:02:29   174,000   0:01:50   174,000   0:39:46   17,962,75
                                                         0,940
11     0:01:58   174,000                       0:14:43   18,338,15
                                                         6,049
12     0:02:20   174,000                       0:17:16   18,479,99
                                                         1,796
13     0:02:20   174,000                       0:17:45   18,664,62
                                                         8,135


クエリ処理
全体的なクエリの性能に影響を与える要因は多数あるため、特定のクエリの時間を見るより、
30%と 45%の相対的なクエリ性能を調べます。
各データベースに対して 80 個のクエリを連続して発行しました。これには、単純なクエリもあ
れば、かなり複雑なクエリもあります。各クエリはパラメータで表したテンプレートで定義され
ており、そのテンプレートには、クエリの発行時点で、特定のメンバやディメンションが割当て
られました。また、キューブを割当てたテンプレートもいくつかありました。複雑なクエリに分
類したのは、クエリに任意の種類の順序付け処理が含まれている場合です (TopCount () や
TopPercent () の使用) 。その他のクエリは、単純なクエリとしました。単純なクエリの例に
は、「任意のレベルの期間と任意の分類またはメーカーの製品に対して、出荷されたユニット数、
および、その製品メンバと時間メンバに対する period-to-period のパーセンテージの変化を抽
出する」、または「顧客の地域、期間、および製品のセットに対して、顧客の各地域に対する、
その期間と 1 年前の期間の総返品、および 1 年前に対するパーセンテージの変化、およびそれ
ら全ての総計を計算する」などがあります。複雑なクエリの例は、「与えられたセットの顧客の
各地域に対して、与えられた期間のその地域の販売額上位 3%を構成するブランドを、その期間
とその子の期間にわたって返す」、または「顧客の地域の与えられたセットに対して、ユニット
販売の period-to-year-ago のパーセントの増加に基づいて、上位 3%のメーカーブランドを、
その期間とその子の期間にわたって選択する」などがあります。合計では、クエリの実行には
10 種類があり、そのうち 6 種類が単純なクエリであり、4 種類が複雑なクエリでした。全体の
クエリ発行数は、複雑なクエリが 23 個、単純なクエリが 57 個でした。クエリの割合としては、
通常の OLAP レポーティングアプリケーションに比べて、複雑なクエリの方に重点を置きました。
注意する必要があるのは、各キューブに対するクエリの種類やそのときの現実的なパラメータの
考えられる全ての中から、ごく一部しか実行していないという点です。
PivotTable Service で提供される接続プロパティを使用して、クライアントに使用するキャッ
シュメモリを 10MB に制限しました。「大きいレベル」のしきい値が、1000 個のメンバに残っ
ていました。複雑なクエリのほとんどは、順序付けに基づいて個々の顧客または製品の大きなセ
ットから選択していたため、この設定の状態によって、これらのクエリがサーバーで解釈された
ことが分かります。クライアントと OLAP サーバーは、100Base-T ネットワークで接続しまし
た。
クエリの一連の発行において、クエリが発行された後で、それに関連するクエリが発行される例
がいくつかありました。 (例えば、同じ製品と同じ期間に対する同じクエリが、最初に 1 つの地
域に対して、次に別の地域に対して発行されるような場合です) 。これは、OLAP クエリがユー
ザーセッションで発行される通常の状況を作るためです。
クエリ処理の各実行では、OLAP Server のサービスを停止して再起動しました。これにより、
サーバーの全てのキャッシュが解放されます。後で実行したクエリの方が、先に実行したクエリ
より結果として速く実行される傾向にありました。これは、多くのセルデータがサーバーのキャ
ッシュ内に残るためです。
全般的には、密度 30%と 45%での集計処理サポートの増加は、複雑クエリより単純クエリの方
でかなり大きな効果がありました。クエリの測定は、秒単位で行いました。クエリの最初の実行
では、45%での単純クエリの実行は 30%に比べて、全体で 30%速くなりました。一方、複雑
クエリは、全体で 2.3%速くなりました。クエリ実行のほとんどが情報の取り出しにかかる単純
クエリに対して、この場合は集計処理を 50 % 増やしたことが、クエリの時間を 30%減らし、
または 1 秒当たりのクエリ数を約 50%増やしたという点は注目に値します。


                     全 ク エ リ ( 全 体 の 秒 複雑なクエリ (全体の秒 単純なクエリ (全体
                     数)                数)           の秒数)
30%                  2,042                 1,426                616
45%                  1,824                 1,393                431
速度向上の %              11%                   2.3%                 30%


使用したハードウェアとソフトウェア
OLAP サーバー
   Dell PowerEdge 6300
   4 x 400 MHz Pentium II Xeon プロセッサ (キャッシュ 512K)
   4 GB RAM (スワップファイルはなし)
   4 x 9.1 GB シングル RAID-5 構成の内蔵ディスクドライブ
   Windows NT 4.0 Server, Enterprise Edition, Service Pack 5
   Microsoft SQL Server OLAP Services SP1
   QLogic 2100A Fibre Channel アダプタカード
   OLAP データベースは、ストレージアレイの 57GB RAID-5 LUN に格納。
   OLAP サーバーの一時ファイルは、ストレージアレイの 32GB RAID-0 LUN に格納。
   OLAP サーバーの設定には、320MB の先読みバッファ、および 768MB の処理バッファを
    含む。
   OLAP サーバーのリポジトリは、同一マシンの MS Jet ファイルから SQL Server 7 データ
    ベースに移行。

SQL Server
   Dell PowerEdge 6300
   4 x 400 MHz Pentium II Xeon プロセッサ (キャッシュ 512K)
   4 GB RAM (スワップファイルはなし)
   4 x 9.1 GB シングル RAID-5 構成の内蔵ディスクドライブ
   Windows NT 4.0 Server, Enterprise Edition, Service Pack 4
   Microsoft SQL Server OLAP Services SP1
   QLogic 2100A ファイバチャネル アダプタカード
   テーブル用の SQL Server テーブルスペースは、ストレージアレイの 3 個の別個の RAID-
    5 LUN に格納。インデックス用の SQL Server テーブルスペースは、ストレージアレイの
    2 個の別個の RAID-0 LUN に格納。

ストレージアレイ
   Clariion FC5700 ファイバチャネル ストレージアレイ
   100 x 9.1 GB 10,000 RPM Seagate Cheetah ディスク

クエリ測定のためのクライアントワークステーション
   Compaq Professional Workstation AP400
   1 x 450 MHz Pentium III CPU
   320MB RAM (スワップファイル 256MB)
   Windows NT 4.0 Workstation, Service Pack 5
   OLAP Services SP1 クライアントコンポーネント

ネットワーク
   100Base-T ネットワーク
   3Com SuperStack 3300 スイッチ

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:21
posted:9/30/2012
language:Unknown
pages:56