今、DBに注目する理由―Oracle 11g R2、その実力を解剖する Part 2

桑原里恵 - 2009年11月10日(火) 09:00

企業システムの変化で問われるDB技術

Oracle Databaseは11g R2でまた、大きく進化した。長寿命のDB製品が、なぜこれほどまでに機能強化を重ねるのか？実現像が変わり、DBのあり方が変われば、求められる製品技術も変わる。企業システムの視点から今日のDBが直面する課題と技術の関係を考える。

業務プロセスとITの一体化は、今日の企業システムに共通する重点課題である。企業は業務プロセスを通して、ビジネス・モデルや戦略を具現化し、日常業務に定着させる。業務プロセスの強さは事業競争力に直結する。

IT化にとっては、事業に貢献するシステムの具体像であり実現目標として、「業務プロセスとの一体化」がある。

事業の視点で業務プロセスを描き、そこに必要な機能を組み合わせていく。システムの単位には縛られない。そして、顧客や担当者の利用場面に合わせて、業務に密着した機能を用意する。

実現像へのこだわりが明らかになれば、システムに求める姿や特性にも違いが見えてくる。システム像が変われば、求める技術も変わってくる。こうした変化の構図を、今もっとも顕著に感じるのがデータベースである。

事業視点の業務プロセスは組織やシステムの垣根を超えて流れる。複数のシステムで発生する「モノ」や「コト」の動きをきめ細かにデータにし、時差なく情報として共有することで、業務プロセス全体が可視化する。

その情報を基点に機能が連鎖して、業務プロセスが一貫化する。離れた場所にいる人が、あたかも隣にいるかのように連携しあう。業務プロセスや役割分担の変更にも、情報によって業務プロセスの動きが共有できているからこそ、柔軟に対応できる。

今日の業務プロセスは情報の力に強く依存している。業務プロセスを可視化し、情報を基点としたしくみを確立することが、ITを駆使した業務プロセスの基礎になる。それだけに、情報を担うデータベースの存在感は大きい。業務プロセスとの一体化が進むことでもっとも強く影響を受け、変化が求められているのはデータベースである。

言い換えれば、データベースの充実度によって、企業システムの成長が左右される。改めて、データベースの重要性を認識し、あり方を問い直さなければならない。そこに、新しいDB技術の価値と必然性もあるはずだ。

業務密着で問われるDBのスピード

Web上の画面から顧客が直接注文を登録する。その場でシステムが注文内容をチェックし、在庫を引き当て、納期を回答する。確定した注文データは即座に後続のプロセスに引き継がれる。顧客の注文から出荷まで、リアルタイムに業務プロセスが流れていく。

最近増えているアプリケーションの姿である。顧客や営業担当者が自ら画面に向かい、システムと対話しながら注文のプロセスを実行する（図2-1）。

図2-1（画像をクリックで拡大）
　「確定後入力」から「確定前入力」に変化するシステム。業務と密着したシステムは、人が仕事をするタイミングで動く。図は受注入力の例。従来は確定後のデータを入力するため、事前に多くの手作業を要した（上段）。今日では、受注申込から確定に至る一連の判断と事務作業を支援している（下段）

従来のシステムでは、確定後のデータを登録していた。注文を決める手順はすべて人手に頼っている。システムが担う機能は後方の一部にすぎない。

一方、最近のアプリケーションでは、人の動きに合わせて、システムを業務の最前線に位置づけている。業務プロセスとの一体感が強い。注文データの確定に至る過程をシステムが支援することで、顧客や担当者の体験をそのままデータとして記録し、業務プロセスの可視化や支援機能に役立てられる。

こうしたアプリケーションは、注文データをつくる部分と、確定した注文を登録する部分の2つの要素で構成される。基幹系の入力アプリケーションに、高度な分析や検索を組み込む形だ。

分析といっても、シミュレーションや一般的なBIのように人が読み判断するものではない。データの妥当性をチェックし、論理値を算出するアプリケーション内部の処理だ。構成確認や代案の誘導、リコメンデーションなど。入力時のデータチェックとは、使うデータ量もロジックの複雑さも次元が異なる。

何よりも、圧倒的に速くなければならない。対話型の入力に耐えられる速度が必要だ。分析には多回数のデータ読み込みがある。データベースの速さが肝になる。しかも、1つのデータが多様なロジックに使われる。データをスタンバイするにも限界がある。まずは、シンプルなデータの読み書きが速いこと。DB技術の基本性能が問われる。

ここで1つ注意したいのは、データ確定前の分析部分にも、多数のデータの書き込みがあることだ。問われているのは、データを読み分析する速さだけではない。これには3つの理由がある。

まず第1に、業務プロセスを可視化し、顧客や担当者の動きを記録するには、きめ細かなデータが必要になる。

2つめは、注文の申込から確定までには複数のステップがあり、複数のロジックが組み合わさっていることである。ステップやロジックごとの結果は途中状況のデータとして持つ。すべてのデータが整ったところで、「完全なデータ」となって、確定入力に流れる。3つめは、分析ロジックや処理の自律性を高め、プログラムの巨大化や複雑化を避けるためである。これはSOAを考えると分かりやすい。サービスごとの結果をデータに返していくことで、サービスが自律し、組み替えが自由になる。

業務プロセスとの一体化によって、データベースが扱うデータは一気に増加する。アプリケーション途中のデータ読み書きの頻度は、従来の確定後入力のアプケーションとは比較にならない。大量のデータを使った分析をし、大量のデータを書き込んでいく。データベースの速さが、業務プロセスとの一体化の前提条件になっている。

データベースの経済性に対する具体策

分析と確定入力では、本来、データベースに求める特性が異なる。かつては、業務支援のシステムを独立して、非同期で基幹系のシステムにデータ連動する形も多かった。しかし実際には、在庫引き当てや価格算出のように、リアルタイムに基幹系のデータベースを見る場面が多く、そう単純に2つに分けることはできない。しかも、データを書き込む頻度が増えている。大量のデータを読み分析すると同時に、細かな単位でデータを書く。分析と入力がシームレスに1つにつながる。

それには、異なる2つの要素を1つのデータベースで対応するか、あるいは、情報共有と分析に特化したデータベースを、入力系のデータベースとリアルタイムに統合するかのどちらかだ。前者には、入力と分析を両立するDB技術、後者にはリアルタイム連携のDB統合の技術が必要になる（図2-2）。

図2-2　複数システムのデータを共有する「リアルタイムDWH」。この例では、SOAのコンポジット・アプリケーション技術を使い、DWHの分析やアラートとERPパッケージの入力を組み合わせている

もう1つ、業務プロセスとの一体化を進めるには、急激に巨大化するデータベースに対する「規模の経済性」への具体策が求められる。従来、特に基幹系のデータベースは信頼性が第1で、費用が少しくらい高くても、手厚い構成を組むという考え方が多かった。確定後のデータだけであれば、事業の成長に比例した増加だけなので、ある程度費用を読むこともできていた。

しかし今は、業務プロセスとITの一体化が進むのに合わせて、データが広がっていく。顧客や取引先との接点や協業関係のIT化もある。業務プロセスの進化によって、10倍、20倍といった単位でデータが増えていく。拡張性への強さも経済性の武器になる。

もちろん、信頼性に対する厳しさは変わらない。むしろ、確定後の処理に比べて、業務プロセスに直接関係する分だけ、事業への影響が大きい。

規模の経済性と信頼性の両立。これもまた、今日のデータベースに必須の技術課題である。DB技術のHA構成によって、スケールアウト型のHW環境を使うことなど、システム全体を見渡した具体策が求められる。

業務プロセスの一貫化は信頼性が生命線になる

業務プロセスとの一体化では、もう1つ顕著なアプリケーションの変化がみられる。先の注文のしくみを例にすれば、注文の入力時点で後続プロセスに対するデータのチェックを完了し、クリーンな確定データとして流通することである。「前品質」とか「コミット・ベース・プロセス」と呼ばれる。

従来は、注文入力の時点では受注に必要な最小限のチェックをするだけで、後続のプロセスで段階的にデータを追記し、正確性を高めていく形がとられていた。モノやコトの動きに合わせてデータを確定していく。時には、受注時点で顧客と納期や納品形態を約束しても、実際に処理をしてみると対応できないなどということも起きる。

前品質のプロセスは、発生時点のシステム負担が重い。しかし、ここでデータをクリーンにし、確定状態にすることで、業務プロセス全体の想定データができあがる。あとは、データに基づきプロセスを遂行していくだけだ。

前品質のプロセスを可能にしているのは、リアルタイムの情報共有である。情報がなければ、後品質と同じくモノの動きを待つしかない。ITとの一体化によって、初めて成立する業務プロセスであるとも言える。

それだけに、前品質におけるデータベースの信頼性への要求は桁違いに高い。しかも、前品質のプロセスには、複数のデータベースが関わる。複数のデータベースの連携を前提とした信頼性と運用能力の確保が前提となる。

DBの自律性を高めDB技術を基盤化する

業務プロセスとITの一体化を進めるには、データベースの力を高めなければならない。それに向けて優先度が高い、3つの取り組み課題を考えた。

1つは、変化する企業システムの姿を整理し、それに対するデータベース全体像を描くことである。データベースのリストをつくるだけでは足りない。データベース同士の位置関係と役割分担を明らかにし、清流となる流れを定める。静的な全体像ではなく、動的な流れに重点がある。物理配置との関係も大切だ。

2つめはデータベースの自律性を高めることである。複数のデータベースが連携して動くシステム像では、個々のデータベースの自律性が欠かせない。それによって、アプリケーションへの依存度を下げ、システム全体をシンプルにする。DB技術によって、自律性の範囲は広がっている。複数データベース間の統合技術もある。自律性をキーワードにDB技術を極めたい。

最後は、データベースにも基盤化が必要であるということだ（図2-3）。共通技術の基盤化は、現在のIT化の優先課題である。しかし、データベースに対しては、あまりにも早くからDBMSを使ってきたために、個別の構築に任せるだけで共通基盤化を怠ってきた。