リレーショナル・データ・ウェアハウス・サーバーに特化された要件

コンテンツ はじめに ウェアハウス・サーバー要件

はじめに
ほぼすべての業界で、企業はデータ・ウェアハウスを構築しています。データ・ウェアハウスは トランザクション処理および従来型運用システムから得られる大量の定量的ビジネス情報を統合化します。 この情報は洗浄され、変換されて完全で信頼できる形にされ、さらに収集・保持されて変化やトレンドの特定に活用されます。

ほとんどのデータ・ウェアハウス・アプリケーションでは、情報はクライアント/サーバ・ネットワーク、 ウェブ・ブラウザ、それに強力なクエリーおよび分析ツールを通じて、直接経営者やビジネス・アナリストに開示されます。
また他のアプリケーションでは、データ・ウェアハウスは「外部とは遮断された」システム内で他の運用アプリケーションとの 連携で機能し、高性能な在庫管理、再発注などの情報主導型機能を実行します。

データ・ウェアハウスは当初「データ・ストア」というイメージで捉えられており、 企業内のすべてのデータを格納した「データ・タンク」と見られてきました。初期この考え方が指向するのは、 企業の履歴データを保有する中央保管庫または運用上の格納場所（ストア）を1箇所に構築するというコンセプトでした。
今日、データ・ウェアハウスは、多くの場合、個別のビジネス・ニーズに対応して設計・ 構築されたサブジェクト指向型データベースに変わっています。一部の企業では、 これらサブジェクト指向型データベースは「データマート」と呼ばれており、 その規模は数ギガバイトからテラバイトまでに及んでいます。
通常、大部分の企業が採用している方法として、 多様なデータおよびユーザの要求条件を含んだ特定のビジネス問題に対応するため、複数のデータ・ウェアハウスまたは データマートが配備されます。

データ・ウェアハウス・システムは、クライアント分析およびレポーティング・ツール、レガシーシステムや トランザクション処理型データの抽出サブシステム、およびメタデータ管理ツール等の多数のコンポーネントで構成されています。
しかし、データ・ウェアハウスを構築する上で最も重要なコンポーネントは、多種・大量の情報を格納し、 幅広いビジネス上の問いにスピーディに信頼性の高い答を出すために使用されるリレーショナル・ データベース管理システム(RDBMS)サーバです。

オンライン・トランザクション・プロセシング(OLTP)環境に、アプリケーションの要求を満足するための 特化されたテクノロジが要求さるのと同様に、データ・ウェアハウス・アプリケーションでも特化されたテクノロジが 必要です。
OLTPシステムに必要な性能はますます高まっており、最先端システムでは毎秒1,000を超えるトランザクションが 実行されます。データ・ウェアハウス環境でも同様にパフォーマンスが重視されますが、パフォーマンスに対する 要求条件の質はまったく異なります。
たとえばデータ・ウェアハウスでは、大型データベースに1回クエリーを投入するだけで、 標準的なOLTPトランザクションの数千倍、数百万倍もの（質の異なる）作業が要求されます。
さらに、多くの場合、 データ・ウェアハウス・アプリケーションは、この負荷レベルの数十から数百ものクエリー操作を同時にサポートしなければなりません。

トランザクション性能の高さが要求されることに加え、OLTPシステムでは、トリガ、トランザクション・モニタ、 ロールバック・ロギングなどの作業の負荷に対応した特別な機能が必要です。
同様に、データ・ウェアハウス・システムには データ・ウェアハウスに特化した機能が要求されます。

本資料は、オープン・クライアント/サーバ・アクセス、ANSI標準SQL、マルチプロセッサ・サポートなど、 最新のデータベース・システムからの要求が素手に明らかな諸条件の一歩先に目を向け、データ・ウェアハウスRDBMSサーバが 特化されたパフォーマンスと機能性を提供しなければならない10分野にわたり、そこでの必要条件を検討します。

ウェアハウス・サーバー要件

1. ロード・パフォーマンス
多くの場合、データ・ウェアハウスの更新（全データのロード）は、数十ギガバイト(GB)・ 数億行という大きな規模で実行され、通常、狭いバッチ・ウィンドウ内で行われなければなりません。 たとえば、毎月発生するPOSレポートは、深夜の数時間を使って分析に使うためロードされなければなりません。
新しいアプリケーションが使用されたり、詳細レベルにわたりデータ管理が行われる場合は、 更新の規模も頻度も増加しますが、だからと言って1日は24時間しかありません。

その結果、データ・ウェアハウスを成功させ発展させるためには、極めて高速のロード性能が クリティカルな要素になります。つまりRDBMSの「ローダ」サブシステムには、フォーマット変換、 整合性チェックおよびインデックス付けを含む完全なデータ・ローディングおよび準備を実行する能力が必要ですし、 さらに、RDBMSはこれら諸段階を1時間に数億行・ギガバイトの速さで達成しなければなりません。
この時間を可能な限り短縮し、短いバッチ・ウィンドウ内で完了するため、RDBMSローダは、 大型並列プロセッサ・システムの全処理能力の活用を含め、あらゆるシステム資源を有効に活用しなければなりません。

また、障害が発生した場合、復旧および再始動プロセスも迅速に行われなければなりません。 狭いバッチ・ウィンドウ内で更新が完了できるよう、復旧および再始動は数分以内に達成できなくてはなりません。

2. ロード処理
データ・ウェアハウス内に格納されているほぼすべてのデータは、外部システムから取り込まれたものです。 例を挙げれば、小売店の端末から収集されたPOSデータ、電話局の通話接続詳細記録、政府の統計などの購入データ、 さらに、在庫管理、製造、財務など社内システムから収集された企業トランザクション・データなどです。
これらのデータをデータ・ウェアハウスにすべて取り込み、使用できる状態に整備していくことが、 データ・ウェアハウス・システムを更新する際の最重要ポイントです。

通常データ・ウェアハウスは、データの更新はバッチ処理として、毎日または週単位で定期的に スケジュールに従って実施されます。バッチ処理は10ギガバイト以上もの極めて大きな規模で行われ、 数千万から数億の新レコードまたは更新レコードが含まれている場合もあります。

生の外部ソースデータをエンドユーザがアクセス可能な、またはビジネス上の意思決定に使用可能な 形の情報へ変換するには、多くのステップが必要です。

• データは、ディスクファイル、ネットワーク、メインフレーム・チャネル・ノード、 磁気テープなど各種のソースから直接読み込まれなければなりません。
• データは、固定・可変長レコード、文字形式、バイナリ形式、IBM EBCDICデータ、 パック化10進・ゾーン化10進数など各種外部表現形式からデータベースの内部フォーマットへ形式変換されなければなりません。
• データは、無効データ値、重複キーやその他の不都合なレコードを排除するためにフィルタリングされなければなりません。
• レコードは、外部フラットファイル表現形式から、データ・ウェアハウスのリレーショナル・スキーマへ適合するよう再構成されなければなりません。
• レコードは、既存のデータベースとの照合によりチェックされ、テーブル・レベルの整合性およびグローバル整合性が確保され、また完全な参照整合性が維持されなければなりません。
• レコードは、データのセグメント化、物理デバイスへの入力、ディスク間の平行維持などの構成上の必要条件を満たしたうえで物理的記憶装置へ書き込まれなければなりません。
• レコードは、完全にインデックス付けされなければなりません。さらに、
• システム・メタデータが更新されなければなりません。

データ・ウェアハウスの更新は、これらのステップがすべて完了してはじめて完全に 実行されたことになります。このためには、これらアクティビティを統一されたプロセスとしてガイドし、 必要な管理と復旧機能を提供するローディング/データ作成ツールが必要になります。

OLTPトランザクション同様に、データ・ウェアハウスの更新にはエラーまたはシステム障害が 発生した場合の回復・再始動手段が必要です。ただし、従来型OLTPの障害回復手法は、この要件を満足していません。
それはOLTPで使用するトランザクション・ログやロールバック機構では通常のデータ・ウェアハウスの 更新時に発生するデータ数やデータ量には、とてもＸＸＸできないからです。データ・ウェアハウスの 更新をサポートするには、データベース内に特化された回復・再始動手法が設けられていなければなりません。

3. データの品質管理
データ・ウェアハウスから得られる洞察は、ウェアハウス内に格納されている情報の品質の レベルを超えることはできませんが、多くの場合、ソース・データの供給源は汚れていて予測不能な 場合がほとんどです。
データ・ウェアハウス・サーバは入力データを洗浄しフィルタリングし、 さらには全データの品質を継続的に保証するメカニズムを備えていなければなりません。

データ・ウェアハウス・アプリケーションでは、ローカル・コンシステンシとして個々の データ・アイテムの有効性および有意性が要求され、またグローバル・コンシステンシとして、 ウェアハウス全体にわたる各種データ・アイテムの自己整合性が要求されます。たとえば、 カナダ西部の州であるはずの「サスカチェワン」が米国の州の名前テーブル内に出てきたり、 現在の在庫数をトラックするテーブルに負の値が混じっているような場合は、 ローカル・コンシステンシ・エラーということになります。
また、POSの明細レポートに、 西部地域店舗の7月25日分販売データが見当たらないような場合は、グローバル・コンシステンシ・エラーということになります。 データベース・サーバはローカル・コンシステンシを強制的にチェックし、グローバル・コンシステンシ全体から 矛盾点を検出しなければなりません。

データ・ウェアハウス・スキーマには通常、相互に参照され、クエリーへの解答に備えて SQLジョイン演算を使用し統合・マッチングされる多数のテーブルが格納されています。たとえば、 トランザクション詳細テーブル内の顧客ID番号が記載されたカラムは、顧客情報テーブル内の顧客ID番号マッチング・ カラムを参照することになりますから、正確なクエリー結果を得るには、テーブル間の全リファレンスが 常時有効でなければなりません。
この属性を、参照整合性と呼びます。データベース・サーバは常時参照整合性を 強制チェックし、全体としての参照整合性に違反するダーティ・データや間違った更新を許容してはなりません。
ロード更新、SQL DELETE操作、およびウェアハウス内のデータを変更するその他の操作に際し、 参照整合性をチェックし強制しなければなりません。

4. 検索性能
データ・ウェアハウス・アプリケーションには、高度対話型アドホック分析システムから 複雑な情報主導型業務運用系システムまでと広範な種類があり、在庫管理や価格設定などのビジネスに 非常に重要な活動をサポートしています。

真に効果的な対話型クエリー・アプリケーションであるためには、リアルタイムに近い高速性が必要です。
と、言うのもエンドユーザのアナリストは、自分の思考過程にマッチしたペースで流動的に質問を投入し、解答を引き出し、さらにフォローアップのための質問を追加投入したいと考えるでしょうし、さらにアナリストには、異なる角度からの照会、異なる観点から情報を見ること、それに異なる詳細レベルのドリルアップ/ドリルダウンが可能でなければなりません。
このような環境下では、分単位や時間単位のクエリー応答時間では通用しません。 これではアナリストの思考過程は中断され、創造的な情報資源探索にかかるコストが大きすぎて実現不可能になってしまいます。
したがって対話型クエリー・アプリケーションの応答時間は、詳細レベルやデータベース規模を問わず、 秒単位のものでなければなりません。しかも、この高速性能は複数ユーザ環境でも維持されなければなりません。

次に、応答時間のもう一端に目を向けましょう。そこには、数百万あるいは数十億行に及ぶ詳細 データが駆動する極度に複雑な業務運用クエリーがあります。
多くの場合、これらクエリー集約型の アプリケーションは業務運用系ビジネス・システムと共に「クローズド・ループ」を形成し、 エンドユーザの介在しない一連のビジネス・アクティビティを始動させることがあります。
たとえば、「クローズド・ループ」アプリケーションは過去の販売データに基づいてインテリジェントな 在庫補充を行ったり、またはマーケット・バスケットまたは購買履歴データに基づいてターゲット 顧客プールを選択するといったケースもあります。このクラスの洗練された高度アプリケーションを実現するには、 その着手段階からの超高速の検索性能が必要です。
3日もかかるようなクエリーに基づいて日々の在庫発注を 実行することなど不可能だからです。この種のアプリケーションでは、最大級のデータベースの最大級の クエリーでさえも、数分から数時間以内に完了することが要求されます。

このようなアプリケーションのパフォーマンス要件は、そのままデータ・ウェアハウス・サーバに課せられることになります。 したがってデータ・ウェアハウスRDBMSには、毎秒数千トランザクションのOLTP性能を生み出したクエリー性能最適化に 近い機能が組み込まれていなければなりません。ウェアハウス環境では、パフォーマンス最適化機能は、 ジョイン、ソートやグルーピングといった、クエリー処理における集中的に演算を実行する側面に総合的に 対応しなければなりません。

5. テラバイト級のスケーラビリティ

今日のデータ・ウェアハウスは大部分が数ギガバイトから数百ギガバイト・クラスまでですが、 データ・ウェアハウス規模は急速に拡大化の一途を辿っており、多くのユーザが、近い将来、テラバイトを 超えるデータ・ウェアハウスが必要になると予想しています。この驚くばかりの伸びは、 詳細トランザクション・レベルのデータの蓄積（POS、クレジットカード利用、通話明細記録など）、 長期間のデータ保存（5年分の履歴データ保存など）、機能間を越えるデータの統合化 （販売、出荷、在庫、財務データの同一データ・ウェアハウス内への組み込み）の増加により牽引されています。

集計テーブル単位でデータ・ウェアハウスが大型化しているばかりでなく、 一部の個別テーブルも大型化しています。時にはデータ・ウェアハウスRDBMSは、10億〜20億以上の レコードを格納した詳細データ・テーブルを経常的にサポートしなければなりません。 このようにデータ・ウェアハウスの大規模化により、リレーショナル・データベース・システムに課される特化要件も多くなります。

• 最も基本的なレベルで、RDBMSアーキテクチャ上の限界がアプリケーションのサイズ要件とほぼ同じでは使えません。 サーバは数テラバイトの物理ストレージに対応しそれを管理し、何十億行ものテーブルをもつプロセスを首尾よく 処理できる能力を備えていなければなりません。ジョイン、アグリゲーション、ソート、インデックス化、 その他のデータベース操作はすべてこのサイズのテーブル上でサポートされなければなりません。
• 通常5GBのデータを管理しているデータベース管理者(DBA)の作業は、テラバイト級の データベースでは役に立ちません。5GBデータベースなら45分しかかからない単純なデータベース再構成も、 テラバイト級データベースでは完了までに一週間もかかるからです。大型データ・ウェアハウス用データベースは、明らかに、ストレージ管理に別のアプローチが必要です。

a. まず、データベースはいくつかを除いて、ストレージ管理作業を全て用にしなければなりません。 たとえば一週間かかるデータ再構成を4日で終わるように高速化しても、それでは十分とは言えません。
そもそもデータベースはデータ再構成が一切不要にされなければならないのです。

b. DBAの作業として残るものついては、データベースがモジュール化された並列管理をサポート できなければなりません。モジュール化された管理とは、グローバル・コンシステンシを維持しつつ、 アンロード、バックアップ、リストアなどのDBA作業を一度にテーブルの一部に対して実行可能であることを意味します。
並列管理とは、マルチプロセッサ・システム上で、データベースの異なる部分に対して一度に同じ管理操作を 適用できることを意味します。

• 現在のハードウェア・テクノロジでは、1テラバイトのデータベースには500〜1,000以上の 物理ディスク・ドライブが、さらに最高100以上のディスク・コントローラと関連ハードウェアが必要です。 これではいかにハードウェアの信頼性が高くとも、ハードウェア障害は避けられません。 同時にデータベースはある部分に障害が発生していても、全体として継続利用できなければなりません。 障害の影響を受けた部分の修理・復旧作業中もユーザは、データベースのその他の影響外部分へは引き続き アクセスが可能で、単一テーブルにも引き続きアクセスできなければなりません。
• 超大型のウェアハウス用データベースの場合、障害からの復旧管理には基本的に特別なアプローチが必要です。 従来型OLTPシステムでは、変更されたデータのイメージを格納した大型ジャーナルまたはログ・ファイルを作成します。 これらログは慎重に管理されて、障害発生時にはデータベースを元の状態に普及するために使用されます。 たしかにこの手法は、データベースが小型で、トランザクションで同時変更されるレコード数が小さい場合にはうまく働きます。 しかし、データ・ウェアハウスでは更新の規模は極度に大きくなります。ロード・プロセス1回だけで数億もの 新レコードがデータベースに入力され、数ギガバイト以上が占有されるケースや、1回のUPDATE文の実行で数億もの 行が影響を受け、ALTER TABLE ADD COLUMN文により20億行のテーブルの全行が更新されることもあります。
• 数百または数十億行に影響する1回の更新にトランザクション・ログの作成は不可能です。 そこで大規模データ・ウェアハウスでは、変更された行すべてのコピー保存という方法に依存しない、 復旧に対して根本的に異なるメカニズムが必要です。データ・ウェアハウスRDBMS製品は、 中断された操作がクリーンに迅速に再開・完了できるよう、それら操作のチェックポイントおよび 高速の再開を実現しなければなりません。
• 古いデータは価値はあるものの、一般に最新のデータに比べてアクセス頻度は落ちますから、 多くの場合、古いデータはより低価格のストレージ媒体に移設することが望まれます。コスト効率のよい ストレージを実現するため、データ・ウェアハウス・サーバは光ディスクなどのオンライン大容量ストレージ・ デバイス、ならびに「ジュークボックス」や他のロボティック・ストレージ・システムを使用した 階層型ストレージ管理(HSM)環境のサポートが必要です。また、データベース・サーバはオフライン・ デバイスにデータをファイルおよび追跡し、古いデータを低コストの光デバイスや他のHSMデバイスに 移設するための、自動化されたメカニズムを提供しなければなりません。サーバは、必要なデータがSQL クエリーを通じて参照される時点で、そのデータを自動的にステージングおよびオンライン化することにより、 ユーザにトランスペアレントなHSMデータへのアクセスを可能にしなければなりません。
• データ・ウェアハウスが大型化しても、個々のクエリーに必要なデータ量は必ずしもそれに比例 して増える訳ではありません。個別テーブルの増加、利用者数増大、またはデータベース全体の大型化によって 検索性能がペナルティを受けないことは極めて重要です。データ・ウェアハウジングの要件として、 検索性能は、データベースの大きさではなく、クエリーの複雑さに左右されるということです。 たとえば、当月の製品販売に関する情報を選別するクエリーは、ウェアハウス内に蓄積されているデータの 合計月数には何の影響も受けるべきではありません。一方、テーブル内の各レコードを合計するクエリーは、 データ量が増大すればその影響を受けることになります。

6. ユーザ数増加のスケーラビリティ

データ・ウェアハウスおよび意思決定支援システムは、もはや企業内の限られた数名の幹部や アナリストだけが必要とする、間口の狭いテクノロジではありません。多数のエンドユーザがデータ・ ウェアハウスを使用するようになったトレンドを以下に示します。

• 組織のフラット化が進んでいること、
• 機能分化された複数部署間で共有データへのアクセスが要求されていること、加えて、
• 互いに関連する複数企業間で共有データに依存する傾向がいっそう高まってきたこと。

ウェアハウス・サーバ内のデータにアクセスする社内部門の増加に伴い、ボトムラインとして さらに個人によるアクセスが増加し、またさらに多くの職責・職能レベルがデータにアクセスするように なってきました。
各種の意思決定権限が極めて多くのユーザ・コミュニティに分散されていく状況下で、 ファクト（事実）に基づく意思決定は絶対条件になっています。

事実に基づくビジネス情報が広範なユーザに求められるようになってきたと言うことは、 言い換えれば、データ・ウェアハウスRDBMSサーバは、合格水準の検索性能を維持しながら、 数百、数千のユーザを同時にサポートできなければならないということです。
そのためには、 サーバには下記の能力が必要になります。

• I/Oボトルネックを最小限に抑えるために、効果的なデータ・キャッシングおよびデータの共有化をサポートする能力、
• 同時実行されている数百のクエリー間で効率の高いタスク切替を実行する能力、
• 需要に見合ったマルチプロセッサおよび大型メモリ環境をフルに活用する能力。

意思決定権限を付与されたユーザが数百または数千にもなれば、DBAは個別に各ユーザ・ アカウントを管理することができなくなります。サーバは、アクセス特権、エンドユーザ・ セキュリティ・コントロール、性能上の優先度などがユーザ各個人または各ユーザ・グループに等しく適用されるよう、管理面での柔軟性を提供しなければなりません。

7. データ・ウェアハウスのネットワーク化
データ・ウェアハウスが単独で存在することはめったに無く、大きなデータ・ウェアハウス・ ネットワークの中で、複数のウェアハウス・システムが協働するというケースが増加しています。 大手企業では、多数のサブジェクト・エリア（事物分野別）ウェアハウスを導入したり、 また多数の部門・支社や支店にウェアハウスを配置する場合もあります。
ウェアハウスは、 いくつかのサブジェクト・エリア・データ・ウェアハウスからの詳細情報がまとめられ企業データ・ ウェアハウスに統合されているような階層構造の時代に入っているのかも知れません。

高度なアプリケーションになると、ウェアハウス・ネットワークが企業の境界を超えて展開されます。 たとえば、小売り店では統合化ウェアハウス・ネットワークの中でサプライヤと販売関連データを共有したい といった場合もあるでしょう。
同様に、電話会社が大口顧客と通話明細情報を共有する場合のように、 ベンダが顧客との情報共有を図るケースもあります。

データ・ウェアハウスのネットワークによる実現・管理により、ウェアハウスRDBMSには新たな要件が 課されることになります。それはウェアハウス間の情報移動を調停するツールのサーバへの組み込みです。 ウェアハウス内のデータ更新に通常は大型の定期バッチ処理が必要なのと同じように、ネットワーク化された ウェアハウス間の交換単位も通常はバッチです。
このためには、情報のまとまり（バッチ）を、 OLTP指向レプリケーション・サーバが提供するパラパラとした更新ではなく、自己整合性のとれた単位として 定義、抽出、移動、更新するツールが必要です。

ネットワーク化ウェアハウスの世界では、ユーザは1つのクライアント・ワークステーションから 多数のウェアハウスを監視したり、それらの上で作業を進めたりできなければなりません。そのためには ネットワーク全体を通じて位置の透過性が必要です。同様に、ウェアハウス管理者は1ヶ所からウェアハウス・ ネットワーク全体を管理することが必要になります。

8. ウェアハウスの管理
大規模リレーショナル・データベース管理システムに要求される数々の管理機能以上に、 データ・ウェアハウス・サーバには、特化されたニーズに対応するさらに多くの管理ツールが必要です。

データ・ウェアハウスの大きな存在価値は、一貫性をもった履歴データを維持していることにあります。 履歴データによりトレンド分析が可能になり、ユーザには時間の経過と共にビジネスの変化を見極め、 また探求していく能力が与えらるからです。
多くの場合、データ・ウェアハウスは時間巡回構造を採用しており、 最も古いデータは最新データのまとまりが追加される時点でウェアハウスから除去されます。

たとえば、ある小売り店で65週ローリングを使用しており、最旧週のデータが当週の売上げ 情報入力時に除去されるという仕組みのPOS情報を格納したファクト・テーブルを持つとします。
この時、時間巡回操作をサポートするには、RDBMSの管理機能がデータのタイム・グループのネーミング、 管理および一括格納をできなくてはなりません。

サーバは、簡単な専用操作で、データのデフラグメントまたは再構成を必要とせずに、 データ・ウェアハウスへのタイム・グループ付与、移動、および除去が可能でなければなりません。

個々のデータ・ウェアハウス・クエリー操作により、メモリ、プロセッサ、ディスクI/Oなどの システム資源が大量消費されるケースもあります。クエリーの実行頻度、タイミングおよび複雑さは、 通常、クライアント/サーバ環境でのエンドユーザのコントロール下にあります。
そこでウェアハウス管理者には、 集約的な、並列同時クエリー処理の影響を管理するツールが必要です。

特に、データ・ウェアハウスRDBMSは、ユーザに警告を発したり、または過度の資源を消費する クエリーを中止させるために、資源の制限管理方式を提供しなければなりません。システムは、 クエリー・コストをデータ・ウェアハウス・ユーザに割り当てるチャージバック会計方式、 および様々なユーザ・クラスやアクティビティのニーズを満足するクエリー優先順位付けを実施しなければなりません。
また、システムが作業負荷追跡ならびにチューニング機能を持つことで、DBAは最も多くの システム資源を消費しているクエリーがどれかを分析可能になり、スキーマ、アクセス通路および ディスクのレイアウトが最大限のパフォーマンスおよびスループットを発揮すべく最適化できます。

9. 統合化されたディメンショナル（次元）分析
データ・ウェアハウス・アプリケーションでは、製品、カテゴリ、地域、顧客および期間などの ビジネス・コンセプトを中心にして、ユーザに対し定量的またはその他の事実情報が組成されるデータの 「ディメンショナル」（次元）展望を与えます。
ユーザは、このデータを、週別・製品単位売上げ、 月別・地域別売上げなどの異なる視点から見られることを、さらにはこれらの視点を対話形式で切り替えられる ことを期待します。ユーザにとって、根源となる原因や異常性を把握するためには、異なる詳細レベルから 情報を観察し、サマリ・データ（週別・カテゴリ別売上げなど）を使用して洞察を試み、さらに詳細な レベル（日別店別製品別売上げなど）にまでドリルダウンする必要があります。

オンライン分析処理(OLAP)という用語は、これらディメンショナル・アプリケーションを 記述する場合に多用されています。オープンなクライアント/サーバ環境では、自己保持型多次元 データベース・システム(MDDBMS: self-contained multi-dimensional database system)および リレーショナル・データベース上に直接層を成す次元分析ツールという2つの汎用アプローチが 登場してきました。両手法とも、ツールとデータ・ウェアハウス間のシームレスな統合化が必要です。

MDDBMSシステムは、高度にサマライズされたデータのみを格納していますが、ピボッティング、 分析的演算などを通じてこのデータを探索する高性能ツールを多数提供します。しかし、MDDBMSユーザが さらに詳細レベルにまで「ドリルダウン」する必要がある場合、ユーザはMDDBMSから「エスケープ」して、 データ・ウェアハウス内で直接詳細データをクエリーしなければなりません。
一部のMDDBMS製品は、 データ・ウェアハウスにSQLクエリーを生成・提出して結果をMDDBMSインタフェース内に提示するための 「ドリルスルー・ポート」を提供します。

MDDBMSとデータ・ウェアハウス用RDBの効果的な統合を図るには、 RDBMSが本質的に次元性というコンセプトをサポートしなければなりません。すなわち、MDDBMS内で 使用されるものと同じディメンショナル機構が、RDBMSスキーマ内で利用可能でなければなりません。 さもないと、RDBMS内の詳細データはMDDBMS内のサマリ・データと一致せず、「ロールアップ」してサマリ・ データにマッチできません。同じく重要なポイントとして、アナリストが詳細データを掘り下げる（ドリルする）とき、 分析の連続性が維持されるよう、データ・ウェアハウスRDBMSはMDDBMSの性能にマッチしなければなりません。

シームレスな次元統合は、次元分析およびOLAPツールがリレーショナル・データベース上に 直接層を成している場合にいっそう重要になります。それは、この環境では、RDBMSがサマリ・ データと詳細データの両方に対する対話型クエリーすべてに解答しなければならないからです。 RDBMSは予め計算されたサマリの、高速・容易な生成・維持、また他のサマリの動的算出をサポートし、 さらに単一スキーマ機構内の全詳細データをサポートしなければなりません。サマリ作成の全レベルで 対話型パフォーマンスを維持することが必要です。

10. クエリーの高度化機能
データ・ウェアハウスの照会言語であるSQLは、パワフルで柔軟性に富んでいます。 SQLを使って、ユーザは、ソート、サマリ作成、算術計算を含め必要とするデータに対する要求を多彩・ 複雑な形で表現することができます。SQLがパワフルな理由は、「どのように」ではなく「何」という 質問形式で操作を表現するからです。
このため、データベース・サーバには、RDBMSが採用している 内部実行ストラテジをユーザが意識しないうちに、クエリー応答を高速化できる内部アルゴリズムを採用する、という自由が与えられます。SQLの価値は標準化によりさらに高まり、多くのベンダ製品が機能や 性能を競い合うことができます。

このようなパワーをもっているにも拘らず、SQLは高度ビジネス分析を表現・実施するうえでは 大きな欠点をもった言語です。標準SQLはセット指向型の言語なため、すべての操作が順序付 けされていないデータ、もっと正確に言えば順序づけがはっきりしていないデータに対して行われるよう 定義されています。
最終結果はソート可能ですが、標準SQLでは、ソート操作は他の処理がすべて完了した 後でしか実行できません。この制限はSQLの「どうではなく何」という構成の一部分ですが、残念ながら、 この制限があるため標準SQLは多くの有用なビジネス上の質問に解答を出すことができません。

たとえば、ビジネス分析で広く使用されている演算の1つとして移動平均という手法があります。 移動平均は、特に一定期間にわたるビジネス（業績）の傾向または変化を見る場合にソース・データの 変動性を平滑化するために使用されます。
単純平均を算出するのとは異なり、移動平均の算出は平均を 求めるデータの順序づけに左右される順序依存型の演算であり、標準SQLでは対応できません。

SQL標準とビジネス・アナリストのニーズとの間のこの溝は、データ・ウェアハウジングでは頻繁に発生します。 その他の例として、ランク付け計算やn-tile発注業務などがあります。順序依存型の演算は別にして、 標準SQLには、変動や標準偏差などのクリティカルな統計演算が含まれていません。

これらのSQLの欠陥は、クライアント・ワークステーションにも高度分析の問題を波及させます。 ここでは、所望の答を出すために、スプレッドシート、統計ツールまたはカスタム・プログラムを使用して、 データベース結果セット全体の処理が必要です。
この2段階のプロセスにより効果的な検索性能は大きくスローダウンし、 いくつかの異種ツールの使用が必要になり、さらには大量の生データが再処理用にクライアント・ ワークステーションに送信されるため、大幅なネットワーク容量アップが必要になります。

データ・ウェアハウス・サーバが効果的に機能を果たすには、アナリストの重要な質問に 答えるためのビジネス分析演算のフルセットが必要です。必要になる分析用演算には、コア・ シーケンシャルおよび上述の統計演算、それにデータ・ウェアハウスに求められるすべての解答を 出すために必要な、データ型固有・ビジネス分野固有の演算が含まれます。

当然、SQLの標準化は、クライアント・ツールとRDBMSサーバ間のアプリケーション移植性確保および基本インターオペラビリティ確保にとって依然として重要な作業です。 ウェアハウスRDBMSシステムが信頼性の高いものとなるためには、完全標準SQLを提供し、 他の妥協なしにフル・パフォーマンスで標準SQLを処理しなければなりません。

おわりに
これまで、データ・ウェアハウスで最も重要なコンポーネントは、多種大量のデータを格納し、 多岐にわたるビジネス上の質問に迅速に信頼できる解答を出すために使用されるRDBMSであることを示しました。

オンライン・トランザクション処理(OLTP)環境にアプリケーションの要求を満足するための特化された テクノロジが必要なのと同じように、データ・ウェアハウス環境にも特化されたテクノロジが必要です。

データ・ウェアハウスRDBMSの要件はクエリーおよび分析を行うためのデータのローディング および準備に始まります。この段階で製品が判定基準に適合できなければ、システムの残り部分は不正確で、 信頼できない、したがって利用価値のないものになってしまいます。

もちろんデータのローディングおよび準備は重要な段階ですが、それだけでは十分ではありません。 クエリーのスループットは、データ・ウェアハウス・アプリケーションの成功の度合いを測る尺度です。 解答可能な質問数が増えれば、アナリストはさらに創造的で洞察力をもった質問を投じることができます。

データ・ウェアハウス実現の最も顕著で測定可能な価値は、エンドユーザに制限のない創造的な データ・アクセスを提供することで実証されます。

今日のデータ・ウェアハウス・アプリケーションの特化された性能並びに機能性を提供するためには、 データ・ウェアハウスRDBMSサーバは以上で述べた10分野の要件を満足しなければなりません。

上に戻る