データ・ウェアハウス: 意思決定の高度化・スピードアップを実現

コンテンツ あらまし はじめに データ・ウェアハウス

あらまし
競合の荒波を越えるために意志決定を下さなくてはならない企業の幹部にとって、まず、分析しなくてはならないのが現在のビジネス状況です。
ところがビジネスについての実態を知ろうとすると、そのデータはオンライン・ トランザクション(OLTP)システムという、構築目的の異なるシステム内に存在する事がしばしばです。

本資料では、まずOLTP向けに設計されたシステムが本質的に意思決定支援照会・検索に不適切な理由を説明します。
次に、データ・ウェアハウスに特化されたデータベース要件との比較検討を試みます。
このデータ・ウェアハウスこそ、 現在のビジネス分析に最適化されたソリューションです。

続いて、レッドブリック社(Red Brick Systems, Inc.)の提供するデータ・ウェアハウスに特化したリレーショナル・ データベース管理システム(RDBMS)製品Red Brick Warehouseについて説明します。
Red Brick Warehouseとは、真のデータ・ウェアハウスRDBMSの基本であり極めて厳格な ユーザ要件に対応した唯一のソリューションです。ユーザ要件は下記の3つです。

• ビジネス上のいかなる質問でも自由にシステムへ投入できること
• 企業内のいかなるデータでも、自由に分析に取り込めること
• システムのパフォーマンスに対する制約は一切ないこと。

論文の最後には、データ中心のシステムから情報中心のシステムへの移行状況について概観します。
今日の事業展開の中心にあるもの、それは情報です。

はじめに
情報へのアクセス: 競争力の鍵
急激に変貌していく今日の市場において、企業のデシジョン・メーカは、競争力を発揮するための解を 常に見出さなければなりません。
複雑で困難な問題に対する明確で有為な解答提示が 求められており、しかもその答は迅速に出さなければなりません。

健全なビジネス分析を行ううえで必要となる生データは、階層構造のデータベース、フラット・ ファイルやCOBOLデータベースなど、いろいろな場所に各様な形式で格納されています。
さらに、多くの場合、 事実関係のデータは日常業務の自動化を目的としたシステムにより取り込まれ、格納・管理されます。 このオンライン・トランザクション(OLTP)システムは、データを驚異的な速度でデータベースに投入・更新していき、 ある予測では、OLTPシステムが収集した累積データ量は2年で倍に膨らみます。
それにもかかわらず、 従来から存在する貴重な知識ベースは、企業デシジョン・メーカの手の届かないところに置き去りにされています。

日常業務の自動化に対応した従来型のOLTPシステムは、データベースへ迅速、安全、効率的に データを投入するのは得意ですが、有意の分析を実行するのは得意としません。
なぜなら事実の検索に 時間がかかり過ぎるのです。ごく普通のランダムなレポートのコンテンツをMIS機構に指示・投入するのに 何日もかかり、結果が出るまでにはさらに時間がかかります。
ところがデシジョン・メーカがバッチ処理 されたレポート一式を受け取り、他のレポートと比較して検索ウィンドウが開くのをもう一日待っていては事態は 変わってしまいます。
ビジネスの力学は日々、変化します。企業の競争力をさらに高めるために、 相互に関連した情報を必要な形でデシジョン・メーカに提示しなれればならないようなケースでは、 動作の遅いSQLクエリーを使用した日常のバッチ形式の報告・分析ではもはや間に合いません。

現実の問題として、OLTPシステムがビジネスを分析するうえでの事実・履歴データのレポジトリ（保管庫） になり得ない大きな理由が2つあります。
まず、OLTPシステムはデータを迅速、安全、効率的にデータベースへ 格納できますが、ランダムな質問に対しては、迅速に解答を出せないばかりか、全く解答を出せないケースもあります。 OLTPに合わせてシステムを細かく調整しても、その本質からスピーディな検索はほとんど不可能です。

もう1つの問題は、OLTPデータベースに格納されたデータには一貫性がなく、常時変化していることにあります。 二重にデータを入力していたり、リバース・トランザクションがなされたりするため、企業アナリストが拠り所と するデータの安定状態を崩してしまいます。
またOLTPデータベースでは履歴データに欠損がある場合も多く、 トレンド分析には活用できません。

OLTPだけに依存していると、各種の副作用が発生します。データ分析に余りに時間がかかり過ぎることで トランザクション性能が妨げられ、日常業務がパンクしてしまうケースもあります。
さらに、 よく見るとOLTPデータは依然生データであり、そのままの形ではデシジョン・メーカが事実を理解するのは容易ではありません。
OLTPデータは常時変化し、あちこちに分散されており、ほとんどの場合に一貫性がなく、また通常はコードや 専門的な用語などの認識不能な形で記述されています。OLTPデータは、デシジョン・メーカが健全なビジネス分析を 行ううえで必要とする豊富な事実関係の詳細データ・情報を提供するにはほど遠い存在です。

データ・ウェアハウス
情報検索に特化したRDBMS
データ・ウェアハウス・アプリケーションの中心となるのは、トランザクション処理システムへの ニーズではなく、デシジョン・メーカのニーズに特に対応するよう設計されたRDBMSです。
OLTPシステムとは 違って、データ・ウェアハウスは情報の迅速・容易な検索・分析に特化されたシステムです。

両システム間にはいくつかの類似した部分もありますが、表1から理解できるとおり、まったく別々のシステムです。

表1　類似点と相違点

データ・ウェアハウジングとは、業務データを抽出し、それを情報データに変形して一元的な データ格納庫「ウェアハウス」にロードするプロセスのことです。
ウェアハウスにロードされて初めて、 デシジョン・メーカは各種のデスクトップ検索・分析ツールを使用しこの情報データに容易にアクセス できるようになるのです。

情報データベースというコンセプトを意思決定支援に具現化するため、データ・ウェアハウスの ソフト/ハード・ソリューションは、1つの基本的な考え方を忠実に実行しなければなりません − データウェアハウス・ユーザは企業内のいかなるビジネス・データに関するいかなる質問でも検索可能であり、 解答を素早く得られ、意思決定プロセスが中断されることのない情報データベースを求めています。

ビジネス上のいかなる質問でも検索可能
トランザクション処理システムの世界では、データそのものへの質問より、 たとえば次のように情報システムに関する指示が多く出されます。

• 野球ボール300個の発注記録を挿入せよ。
• この旅客の予約を更新せよ。
• この業者の買掛金勘定を閉めよ。

さらに時々発生する、問い合わせ（クエリー）といっても情報システム内の特定のレコードの所在を探し、 そのレコードを作成して更新を行うか、または簡単なアグリゲーションを実行する程度に限定されています。

• この顧客の現在の勘定残高はいくら?

一方、デシジョン・メーカの発行する検索は、トランザクション処理に対応した質問とは全く異質の問いです。
なぜなら、データの分析・処理を通じて結論や推奨事項を得るというビジネス上の必要性から発生するからです。 したがって質問は複雑であり、期間、製品ファミリ、世界の中でのエリアといった、一般にOLTPシステムがタッチ していないような次元に及びます。

• 中部地域で最も売れ筋の製品はどれ、人口統計データとの相関関係は?
• 前四半期の販促は昨年同期より効果があったか?
• この証券の5日間の値動きは実際の価格に比べて先行それとも後追い?

どの質問もデシジョン・メーカの業績改善という要求範囲から出されるものです。このような相関関係の見極め、 クロスリファレンス（相互参照）、計算や精細化といった仕事を引き受けるのがデータ・ウェアハウスです。

企業内のどのようなデータでも収容可能
デシジョン・メーカが出す質問は、発注システムや在庫管理システムに格納されたデータの枠内に 納まらないこともしばしばです。多くの場合、期待される精度を伴った結果を得るためには、企業のあらゆる データを取り込んだ上での問いが必要になります。

現実の意思決定支援に対応できる情報ウェアハウスを生成可能にするためには、 雑多な情報源から得られたデータを正しく格納しなければなりません。
そのデータがIMS、OracleやCOBOLなど、どんなレガシー・システムに格納されている場合でも、 それが確実に意思決定支援に供されるためにはウェアハウス・エンジンがそれを利用可能でなければなりません。 同様に、Sybase、Informix他から出荷されているデータベース内のトランザクション関連データも、 同じくウェアハウス・アーキテクチャにアクセス可能でなければなりません。

その源がどこであれ、データ・ウェアハウス・システムはビジネス・アナリストに必要な OLTPサブセットを統合し、不要な詳細事項を切り捨て、複雑きわまるコードや重複のある表などを分解します。 OLAPデータをウェアハウスのデータベースに移設またはロードするこの過程は、データ・ウェアハウスと いうコンセプトに必要不可欠な一部です。

データ・ウェアハウスへ効率よくデータをロードする作業が重要な要件であることが 明らかにされてきました。さらに新データのローディングは定期的に行われ、決まったやり方がないとはいえ、 意思決定支援活動が行われていないときにその時間枠内で容易に完了できるものでなければなりません。
また、データのロードには、データ・ウェアハウス環境に適合したいくつかのメリットが伴わなければなりません。

• 新規または変更後のデータだけに限って選択的に追加ロードできること。
• EBCDIC、ASCII、整数データなど、データ型の変換が可能なこと。
• 固定長レコード、非固定長レコード、バイナリ・フィールドなど、柔軟なファイル・フォーマットに対応していること。
• サマリー・レコードのアップデートや自動アグリゲーションなどの取り決めがなされること。

検索性能に制約のないこと
究極的には、ビジネス・アナリストは、簡単なキー入力で即座の応答や情報入手を望んでいます。
MISの要求に従った形式や、ハードコピーに出力されたレポートは求めていません。デシジョン・メーカは 自分のPCから質問を入力し、たいていは数百万ものデータ・レコードを使って、複雑な相関関係付けや分析を実行させ、 それを角度を変えて2度、3度行なう必要があっても、やる気を失わない程度に迅速に処理できる - これが理想的な環境です。

リアルタイム対話形式での質問ができることは、意思決定支援の成否を左右する重要な要素です。 反射的に情報が返ってくれば、そこからインスピレーションが生まれ、さらに先へとクエリーおよび分析を展開できます。

このデータ分析への「ドリルダウン」型アプローチは、OLTPシステムの「ポイント・アンド・チェンジ」 アクションとは根本的に異なります。
しかし、両システムとも、そのアプローチは高速で効率が高いことが要求されます。 OLTPシステムの場合、数千名のデータ入力用員が入力する、定義された個別作業単位という小型のアプリケーション処理を 迅速に実行することが要求されます。
これに対しデータ・ウェアハウス・システムでは、ナレッジ・ワーカーによる大型・ 複雑でランダムなクエリーの高速処理が要求されます。

データ・ウェアハウスRDBMSに必要な条件
「どんな質問でも、どんなデータでもスピーディに処理」という要件に対応するには、OLTPと、 データ・ウェアハウジング・モデルを使用した意思決定支援アクティビティを分離して考えなければなりません。
いくつかの別々のソースからのデータを統合しなければならないこと、また実現されなければならない性能を考えれば、 これら2つのワークロードは1つのデータベース内に同時に存在することはできません。

さらに、データ・ウェアハウス・データベースは、OLAP対応のデータベースとはアーキテクチャが異なっています。 関連をもったテーブルを迅速にジョインし、大型のデータベースを走査するには、 新たなアプローチとして異なるクエリー・セットおよびシンタックスがサポートされなければなりません。
また、その他各種の管理業務も、データ・ローディング・アルゴリズムも異なります。 単にOLTPデータベースをコピーしても、真のデータ・ウェアハウスの基準を満足することはできません。

Red Brick Warehouse
データ・ウェアハウス・アプリケーションに特化したソリューション
レッドブリックは、データ・ウェアハウス・アプリケーションに特化された唯一のRDBMSを提供しています。 この特化されたRDBMSはRed Brick Warehouseという製品として、下記3つを主要構成要素を持っています。

• ANSI規格SQLと、RISQL(R)と呼ばれる意思決定拡張機能をサポートするデータベース・サーバ
• Table Management Utility(TMU)と呼ばれる高性能ロード・システム
• ウェアハウスへのクライアント/サーバ型アクセスをサポートするゲートウェイ・テクノロジ

Tこれら3つの構成要素はデータ・ウェアハウジングに特化されており、 情報データベースへの効率的なロード、データベースの管理とオープン・アクセスを提供します。

データ・ウェアハウス・サーバ
Red Brick Warehouseは、情報データベース向けの一元化されたストレージと管理サービスを提供します。 検索専用に設計された特別なインデックスを使用し、ANSI標準SQLインタフェースを拡張した強力な言語を通じて、 他に類を見ないクエリー性能を実現しています。

Red Brick Warehouseのアーキテクチャは、500ギガバイトを超える、 あるいは単一テーブル内に数十億のレコードを収容したウェアハウスを取り扱い可能で、 オンデマンドで並列処理を実行します。
したがってクエリーの実行にはパラレル・スキャン、 パラレル・ジョイン、およびパラレルSuperScanなどの機能を使用して、 あらゆるデータ・ウェアハウスの成功に重要な時間軸データ管理をサポートします。

データ・ウェアハウスに特化されたインデックス技術
インデックスとはデータの所在場所の検出をスピードアップするために使用される内部機構です。 意思決定支援を目的に構築されたデータベースはどれも、より多くのクエリーを高速化するために複数の インデックスを搭載することになるでしょう。
異なるタイプのインデックス化機構を収容する自由度の高さが、 IBM Red Brick Warehouseサーバの強みとなっています。データベースの設計者は、B-Tree、STAR、 およびTARGETインデックスの中から選択し、特定の検索環境を最適化・カスタマイズ可能です。

B-Treeインデックスはほとんどのリレーショナル・データベースに共通して使用されており、 迅速に情報の所在場所をつきとめるための一つのコンポーネントです。 IBM Red Brick Warehouseは標準B-Treeインデックスをサポートしていますが、STARとTARGET両インデックスを 提供することで、さらに一歩先まで進んでいます。

STARindexはテーブル作成時に自動的に構築されます。STARindexはプライマリ・キーと 外部キー(foreign key)との間の関係を維持する、IBM Red Brick Warehouseサーバだけが持つ機能です。 STARindexを使用すれば、クエリー実行時のジョイン処理は大幅にスピードアップされます。

TARGETindexは、大型でワイド・テーブルからの超高速レコード選定能力が要求されるクエリーに、対応したビットマップ・インデックスの一種です。TARGETindexはIBM Red Brick Warehouse RDBMS エンジンのコアに完全に内蔵されており、広範囲にわたるドメイン、または各属性に対して一意に与えられた 数値が存在するデータ・カラムに適用可能です。

IBM Red Brick Warehouseを使用すれば、最適な型のインデックスを割り当て、 クエリー内でのインデックスを混在させ適合させることができます。その結果データ・ ウェアハウスRDBMS内で最も自由度の高い最高のクエリー性能が実現されます。

標準SQLおよびSQL対応のRISQL拡張機能
IBM Red Brick WarehouseはANSI標準SQLだけでなく、デシジョン・メーカがよりパワフルな 質問を投じることができるように特別に設計され、最適化された拡張機能セットをサポートしています。 これら拡張機能はRed Brick Intelligent SQL(RISQL)と呼ばれており、多様な付加価値を提供します。

• 順次、計算を実行するビジネス分析機能
• 文字列および数値を取り扱うための数値機能および文字列機能
• 繰り返し使用されるSQLや計算を単純化するマクロ構築機能

クエリーを単純化しその性能を一段と高めるRISQLのパワーは、多くの場合、 意思決定支援の世界で発揮されます。
たとえば、製品の販売データと時間および販売先市場の ディメンションが格納されたデータベースについて考えてみましょう。下記の質問は、 大部分のOLTPデータベースでの実行が不可能ではないにしても困難な質問です。

1993年度の第2四半期に販売されたトップ10製品は、また売上金額および販売数量換算でのランキングは?

IBM Red Brick Warehouseに実装された標準RISQL拡張機能を使用すれば、この質問の投入は簡単です。

be asked:

SELECT product, RANK (dollars),RANK (units)
FROM product, market, time, facts
WHERE quarter = 2
AND year = 1993
WHEN RANK (dollars) <= 10

ビジネスの世界では、ごく、ありふれたこの種の分析も、SQLだけでは実行できません。 RISQLのランク機能を使用しなければ、ビジネス・アナリストはより多数のクエリーを発行し、 ランキングを実行するために複雑なスプレッドシートのダウンロード手続きを強いられる可能性が 極めて高くなります。
意思決定プロセス全体の時間が長くなるだけでなく、 適切なツールがないとタスクそのものが実行不能になる場合もあり得ます。

ランク以外にもRISQL機能を使用して、順次データの実行合計、移動平均、移動和、 年度別の販売実績比較など、各種の計算を実行することができます。

高性能ローダ
ウェアハウス用のデータベースは、通常、最初から数億・数十億のデータ・ レコードを格納した超大型データベース(VLDB)として構築されます。このデータは様々な 生産系から収集されますので、履歴ベースが構築され、多くの場合ビジネス・アナリストはこれを利用します。

データ・ウェアハウス自体も、新鮮で正確であり続けるため、新データの入力で常時更新されていきます。 このリフレッシュ・サイクルは高速・高効率で、また自動化されていなければなりません。 さもないとデータ・ウェアハウスの究極的な価値が失われることになります。

Table Management Utility (TMU)と呼ばれるRed Brick Warehouseローダは、 データ・ウェアハウジングに必要な種類のロードおよびインデックス作成性能を提供します。 TMUは、全データをスクラッチから、または規則的にデータの履歴上に暫時追加する形で、ウェアハウスへのロードを完全に自動で行なう機能を提供します。

TMUは異種データ混合環境からの移動のために、データ形式を自動変換する機能を提供します。 以下のデータ型などに対応しています。

• EBCDICからASCIIへの変換
• ゾーン化/パック化された10進数
• IBM浮動小数点
• 整数
• 日付

またTMUは、データ・ウェアハウス・スキーマへの適応性を高めるため、 入力されるOLTPデータの変換機能に対応しています。たとえば、ロード・プロセスでは不要なカラム・ データを無視することができます。
また、入力フィールドをマージして、多くの場合にOLTPシステムで 要求されるデータの分離化を抑えることができます。

TMUオプション機能として、大量データ対応の並列ロード・タイプTMU、 それにロード・プロセス中に自動的にデータ・アグリゲーションを実行するタイプも出荷しています。

ゲートウェイ
デスクトップ・プラットフォームの選択幅を広げるためにも、ゲートウェイは、 データ・ウェアハウス・システムを成功させるアーキテクチャ上の重要なコンポーネントです。 ビジネス・アナリストは、ウェアハウス・データを取得可能なPCが空くまで待って仕事をする訳にはいきませんし、 しようともしないはずです。データはアナリスト1人1人に、当人が必要な時間に開示されていなければなりません。

Red Brick Warehouseアーキテクチャは、端末からのアクセスとクライアント/サーバ・モデルの両方に 対応したゲートウェイ・テクノロジを装備しています。クライアント/サーバ型は、意思決定支援環境を完全に 自分に合わせて仕立て上げるために頻繁にグラフィック・ワークステーションの能力が必要になるアナリストに 好まれるアクセス・タイプです。

ゲートウェイ・テクノロジは、普及版OSが動作するパソコンを使用したクライアント/サーバ型の通信に使用可能です。 このように各種アクセス・タイプがカバーされているので多種多様な普及版ツールから任意にツールを選んで、 Red Brick Warehouseサーバから検索されたデータの分析を行うことができます。

業界も一巡
情報システムは、次々に新しいものへと変化していきます。1950年代に登場したデータベースは、 事業を運営するための日常業務の自動化支援を目的に編成されていました。買掛金、総勘定元帳、 人件費や発注入力それぞれが、ビジネス・プロセスでコンピュ−タやデータベースの利用メリットを 引き出す機会を提供していました。

1970年代後半、リレーショナル・データベース管理システムの登場に伴い、企業はリレーショナル・ モデルにより確立された「行とカラム」だけのシンプルな新しいタイプのアプリケーション作成が可能に なるものと信じていました。
このことは数百の履歴データ・ポイントの分析、表間の相関関係の見極めや 各種演算を可能にする意思決定支援システム実現を約束するものでした。

しかし、リレーショナル・システムはこのミッションを果たすことなく、 従来型OLTPの処理速度調整に終始することになり、意思決定支援機能の利用者には煩雑な アップロード/ダウンロード、ファイル転送やデータ変換作業が残されることになったのです。

そして今日、業界は既に一巡しています。データ・ウェアハウジングにより、 リレーショナル・モデルが再びデシジョン・メーカの手に戻ってきました。
今、情報システムの明確な分化の時期が訪れています。OLTPアプリケーションは今後も成長を続け、 ビジネスを動かすためのデータ管理を受け持つでしょう。一方でデータ・ウェアハウス・アプリケーションは、 貴社ビジネスを分析するためのデータ管理という、まったく別の使命をもって機能します。
最終的には、この機能によりアナリストや企業組織は、現在のレベルを超えた意思決定をスピーディに行うことができます。 この潜在可能性を実現するには、デシジョン・メーカのニーズに特化された、専用のRDBMS無くして実現できません。

上に戻る