目次


IBM 連合データベース・テクノロジー

Comments

はじめに

大規模な近代的エンタープライズでは、組識のさまざまな部門が異なるデータベース管理システムを使用して重要なデータを保管し検索することが、ほとんど避けられない状態です。競争、進化するテクノロジー、合併、買収、地理的分散、成長の集中を排除する不可避な傾向は、すべてこの多様性の要因です。一方、これらシステムからの情報を組み合わせることによってのみ、企業は所有するデータの価値を最大限引き出せます。

たとえば、金融業界では、企業合併はめずらしいことではありません。新たに作成される企業体は企業の合併前のデータ・ストアーを継承します。これらのデータ・ストアーの多くはリレーショナル・データベース管理システムですが、往々にして異なるベンダー製であったりします。たとえば、一方が主に Sybase を使用し、もう一方が Informix IDS を使用するといった具合です。両社はローンのコピーなどのテキスト文書の保管用に、Documentum や IBM Content Manager などの文書管理システムをそれぞれ 1 つ以上備えているかもしれません。また、重要な情報 (特定の顧客に対するローン・リスクなど) を計算したり、顧客の購買パターンに関する情報をマイニングするアプリケーションを、各社がそれぞれ持っているかもしれません。

合併後、両社の店舗から全顧客情報をアクセスし、既存および新規アプリケーションを用いて新規ポートフォリオを分析し、そして一般的に、共通インターフェースを通して両社の合体したリソースを使用できなければなりません。両社に共通の顧客について、各社はこれまでまったく異なる識別キーを使用して識別していましたが、その共通顧客を識別して口座を統合する必要があります。連合テクノロジーは、統一されたインターフェースを多様なデータに提供することにより、このような状況での痛みを大幅に緩和できます。

IBM は連合テクノロジーに大きな投資をしてきており、それがデータ管理製品ポートフォリオ全体にわたる市場最先端の機能につながりました。現在、連合機能によって、あらゆる情報ストアーに保管された (構造化形式であろうと非構造化形式であろうと) いかなる形式のいかなるデジタル情報に対しても、統一されたアクセスができます。連合機能は、DB2 UDB (および DB2 リレーショナル・コネクト)、DB2 DataJoiner、および IBM Enterprise Information Portal (EIP) を含む多様な IBM 製品を通して提供されています。今後もこの連合テクノロジー一式の機能強化は続き、これら製品へのお客様の投資は本物のビジネス価値を引き続き生み出します。

この文書では、IBM ソフトウェアからの次世代の情報連合拡張を表す「ガーリック」というコード名で呼ばれるテクノロジーを通して実装された、先進的なデータベース連合機能に特に焦点を当てます。この機能拡張により、クライアントは広範囲のリレーショナルおよび非リレーショナル・データ・ソースの専用演算機能とデータにアクセスして統合できます。ガーリック・テクノロジーは、連合テクノロジー提供する IBM ソフトウェア・オファリングのすべてに次第に組み込まれます。お客様には、既存製品に対するこれまでの投資が保護されるばかりか、将来どの製品を選択しようと、本書で解説する先進機能を活用できることが保証されます。

IBM の連合データベース・システムは、複数のデータ・ソースからの情報を組み合わせる強力な仕組みを提供します。以前の製品 DB2 DataJoiner [3] からの最新鋭テクノロジーを基に構築され、ガーリック研究プロジェクト [2] からの拡張性およびパフォーマンスのための最新鋭機能で強化されており、IBM の連合データベース機能は業界でも希有な機能です。DB2 DataJoiner は、複数の異種混合リレーショナル・データ・ソースをまとめて連合させることによって作成した仮想データベースの概念を導入しました。DB2 DataJoiner のユーザーは、データ・ロケーション、データ・ストアーの SQL ダイアレクト、あるいはこれらストアーの機能などを気にせずに、連合システム内の任意の場所に保管されたデータに対して自由な照会ができました。そして、ユーザーは連合内の任意のデータに対して DB2 のフル機能を使用できました。ガーリック・プロジェクトは、このアイデアを拡張し、非リレーショナル・データ・ソースも含めた多様なデータ・ソースの照会機能を効果的に活用する連合データベース・システムを構築することの実現可能性を示しました。現在の DB2 で実施しているのと同様に、これらシステムの両方で、ミドルウェア照会プロセッサーは最適化された実行プランを策定し、データ・ソースに欠けている機能があればそれを補完します。

この記事では、IBM の連合テクノロジーの主要な特性を解説します。特性には、透過性、異種性、高度な関数、基になる連合ソースの自律性、拡張性、オープン性、そして最適化されたパフォーマンスなどがあります。次に、覆いを除いて IBM のデータベース連合機能の仕組みを示します。さまざまなシナリオで連合機能をどのように使用できるかを示し、将来の方向性を導きます。

IBM 連合ソリューションの特長

透過性

連合システムが透過的であれば、基になるデータ・ソースの相違点、特異性、および実装をユーザーから隠ぺいできます。理想的には、ユーザーにとって連合ソース一式が単一システムのように見えることです。ユーザーはさまざまなことを気に留めずに済むべきです。たとえば、データの保管場所 (ロケーションの透過性)、データ・ソースによってサポートされる言語やプログラミング・インターフェース (起動の透過性)、SQL が使用されるならソースがサポートする SQL ダイアレクト (ダイアレクトの透過性)、データが物理的にいかに保管されているか、あるいは区分化やレプリケーションが行われているか (物理データの独立性、フラグメント化とレプリケーションの透過性)、使用されているネットワーキング・プロトコル (ネットワークの透過性) などです。ユーザーが目にするのは統一された 1 つのインターフェースだけで、エラー・コードも一式だけです (エラー・コードの透過性)。IBM はこれらすべての機能を提供しており、実際にはデータは異種混合のデータ・ソース・コレクションに保管されていたとしても、すべてのデータが単一データベースにあるかのようにアプリケーションを記述できます。

異種性

異種性は、さまざまなデータ・ソースの違いの度合いです。ソースは多くの点で異なります。異なるハードウェア上で稼動し、異なるネットワーク・プロトコルを使用し、異なるソフトウェアを使用してデータ・ストアーを管理することもあります。照会言語、照会機能、さらにはデータ・モデルも異なる場合があります。エラーの扱い方が違ったり、トランザクション・セマンティクスも異なることもあります。また、同一または異なるスキーマを使用して、一方は Oracle 8i が稼動し、もう一方が Oracle 9i が稼動するのと同程度に似ていることもあります。高性能リレーショナル・データベース、単純な構造化フラット・ファイル、URL の形式で照会を受け取って同じ DTD に従い半構造化された XML を戻す Web サイト、Web サービス、特定の関数呼び出し一式に応答するアプリケーションというように、ソースは非常に多様である場合もあります。IBM の連合データベースはこれらすべての違いに対処でき、シームレスで透過的な連合にこのようなシステムを包含します。

高度な機能

IBM の連合機能は、それぞれの優れた点をユーザーに提供します。すなわち、連合内のすべてのデータに対して、標準準拠の豊富な DB2 SQL 機能のすべてと、基になるデータ・ソースの全機能を提供します。DB2 の SQL には多くの複雑な照会機能のサポートが含まれます。これには、内部結合と外部結合、ネストされた副照会と表式、再帰、ユーザー定義関数、集計、統計分析、サマリー表、など、列挙できないほど多くのサポートが含まれます。多くのデータ・ソースがこれらすべての機能を提供しないかもしれません。しかし、ユーザーはこれらソースのデータについて DB2 SQL のフルパワーを活用できます。機能補完とは、データ・ソースが特定の照会機能を実施できない場合に、連合データベースが必要なデータを取り出してその機能を適用することを意味します。たとえば、ファイル・システムは、通常は自由なソートができません。しかし、ユーザーはソースからの特定のデータ (つまりファイルのサブセット) を特定の順序で取り出すことを要求したり、データから重複を排除するように要求できます。連合データベースは、単に適切なデータを取り出して連合データベース自体でソートするだけです。

DB2 SQL の全機能を提供しないソースは数多くありますが、多くのソースは IBM 連合データベースに欠ける専門的な機能を持っている場合もあります。たとえば、文書管理システムはスコアリング機能を備えていることがよくあります。この機能を使用すると、ユーザーは検索と取り出された文書との関連性を測ることができます。金融業界では、時系列データは特に重要で、専門的な手法で時系列データを比較、プロット、分析、サブセット化できるシステムもあります。製薬業界では、新薬は特定のプロパティーを持つ既存の化合物をベースにします。専用システムで化学構造を比較したり、2 つの分子の結合をシミュレートしたりできます。このような機能は直接実装することもできますが、データ・ソースやアプリケーション・システムにすでに存在する機能を活用した方が、より効率的で費用対効果に優る場合がよくあります。IBM の連合システムでは、ユーザーは連合ソースから関心のある機能を識別して照会で使用できます。こうすることで、連合システムのユーザーはソースの機能を失わずに済みます。

連合の拡張性とオープン性

あらゆるシステムは、時とともに進化する必要があります。連合システムでは、ユーザー・ビジネスの常に変化するニーズを満たすために、新しいソースが必要になる場合があります。IBM は新規ソースを追加しやすくしています。連合データベース・エンジンは、ラッパーとして知られるソフトウェア・コンポーネント経由でソースをアクセスします。新たな種類のデータ・ソースのアクセスは、そのソース用のラッパーを取得するか作成するかして実施されます。ラッパー・アーキテクチャーでは、新規ラッパーの作成が可能です。ラッパーが存在すれば、進行中の照会やトランザクションを中断しなくても、簡単なデータ定義 (DDL) ステートメントでソースを動的に連合に追加できます。

いかなるデータ・ソースもラップできます。IBM は ANSI SQL/MED 標準 [1] (MED とは Management of External Data の略) をサポートします。この標準は、連合サーバーが外部データ・ソースとの通信に使用するプロトコルを記述しています。ラッパーが SQL/MED インターフェースに従って記述されたものであれば、IBM の連合データベースと共に使用できます。したがって、ラッパーは IBM だけでなくサード・パーティーも作成でき、IBM の連合データベースと一緒に使用できます。

データ・ソースの自律性

通常、データ・ソースには既存のアプリケーションがありユーザーがいます。したがって、連合に組み込まれても、ソースの操作が影響されることがあってはなりません。IBM の連合データベースは、既存データ・ソースのローカル操作を妨げません。既存アプリケーションは無修正で稼動し、データは移動も変更もされず、インターフェースも変わりません。連合システムに対するグローバル照会が多くの異なるデータ・ソースに触れることはあったとしても、データ・ソースがデータ要求を処理する方法がそれらグローバル照会の実行で影響されることはありません。同様に、データ・ソースが連合に加わったり抜けたりする際に、ローカル・システムの一貫性に影響はありません。唯一の例外は、連合に参加するソースに対する連合 2 相コミット処理中です。(DB2 V7 では使えませんが、連合 2 相コミットは、DataJoiner で使用されていました。) 同じ作業単位に含まれるデータ・ソースはコミット処理に加わる必要があり、必要であれば関連する変更をロールバックすることが求められます。

他の製品とは異なり、ラッパー・アーキテクチャーではデータ・ソースをホストするマシン上にソフトウェアをインストールする必要はありません。データ・ソースとは、ソースの通常のクライアントを使用して、クライアント/サーバー・アーキテクチャーを介して通信します。このように、IBM の連合データ・ソースは、ソースにとってもう 1 つのアプリケーションのように見えます。

最適化されたパフォーマンス

オプティマイザーはリレーショナル・データベース管理システムのコンポーネントで、各照会の実行に最良の方法を決定します。リレーショナル照会は非手続き型で、各リレーショナル操作の実装方法が通常は数種類あり、照会実行において操作の順序も多くの中から選べます。オプティマイザーによっては、発見的ルールを使用して実行ストラテジーを選択するものもあれば、IBM の連合データベースはさまざまなストラテジーを考慮して、各ストラテジーのコスト見積りをモデル化し、最小コストのものを選びます (通常、コストは消費されるシステム・リソースに関して計測されます)。

連合システムでは、オプティマイザーは照会に関わるさまざまな操作が連合サーバーで実施されるべきか、あるいはデータが保管されているソースで実施されるべきかを決定する必要があります。また、操作の順序と、照会のローカル部分の実施にどのインプリメンテーションを使用するかを決定する必要があります。これらの意思決定を行うために、オプティマイザーは各データ・ソースが何ができ、どれだけコストがかかるかを知る手段を持っていなければなりません。たとえば、データ・ソースがファイルの場合、それが高機能であると仮定してソートの実施や特定の機能の適用を依頼するのは、理にかないません。一方、ソースがリレーショナル・データベース・システムで述部の適用や結合の実施ができる場合、ソースで実施した方が連合エンジンに戻されるべきデータ量が削減されるのなら、ソースのパワーを活用した方がいいかもしれません。これは通常、個々の照会の詳細に依存します。IBM オプティマイザーは照会に関与するさまざまなソース用のラッパーと共に作用して、可能性を評価します。実行ストラテジーの決定の善し悪しの違いは、パフォーマンスが何桁も違う結果になることがよくあります。ラッパーと共に機能して多様なソースにわたる連合照会のコストをモデル化できる IBM の連合データベースの機能は、業界でも独特なものです。結果的に、ユーザーは可能な限り最高のパフォーマンスを連合システムから期待できます。

パフォーマンスをさらに改善するために、各ラッパー・インプリメンテーションは、ソースのネイティブ API を使用して各データ・ソースが提供する操作ノブを活用します。たとえば、複数の結果行を 1 つのメッセージにブロッキングすること (ブロック・フェッチとして知られています) は、一般的なパフォーマンス・ノブです。照会コンパイラーはラッパーとやりとりして、どの照会フラグメントがブロック・フェッチを利用でき、照会セマンティクスに無駄がなく実行時に最高のパフォーマンスを実現できるかを示唆します。

IBM の連合機能の仕組み

アーキテクチャー

図 1 は IBM の連合データベース・アーキテクチャーを示しています。アプリケーションは、サポートされる任意のインターフェース (ODBC、JDBC、あるいは Web サービス・クライアントを含む) を使用して、連合サーバーとやりとりします。連合サーバーは、ラッパーと呼ばれるソフトウェア・モジュールを使用して、データ・ソースと通信します。

図 1. IBM 連合システムのアーキテクチャー
図 1. IBM 連合システムのアーキテクチャー
図 1. IBM 連合システムのアーキテクチャー

連合システムを構成する

連合システムは、連合エンジンをインストールしてデータ・ソースと通信できるように構成することで、作成されます。連合システムに新規データ・ソースを追加するには、いくつかのステップを実施します。まず、新しいソース用のラッパーをインストールし、そのラッパーの場所を IBM の連合データベースに知らせる必要があります。これは CREATE WRAPPER ステートメントを使用して行います。同じタイプの複数ソースが必要な場合でも、必要なラッパーは 1 つだけです。たとえば、連合システムに (場合によっては異なるマシン上の) 5 つの Oracle データベース・インスタンスが含まれる場合でも、必要な Oracle ラッパーは 1 つだけなので、CREATE WRAPPER ステートメントも 1 つだけ必要になります。しかし、個々のソースは、それぞれシステムに識別されなければなりません。これは CREATE SERVER ステートメントで実施されます。Oracle データベース・インスタンスが 5 つある場合、5 つの CREATE SERVER ステートメントが発行されなければなりません。

たとえば、Web サイト・アクセス用のラッパー 1 つと、ユーザーがデータをアクセスしたい特定のサイトがあるとします。連合データベースは、次のようなステートメントを介してラッパーについて報告されます。

 
CREATE WRAPPER web_wrapper
LIBRARY "/u/haas/wrappers/libweb.a"

このステートメントは、基本的に web_wrapper のコードの場所を連合データベースに知らせます。次に、連合データベースは、web_wrapper に関連付けられたサーバーとして識別することで、使用される実際の Web サイトについて知らせを受けることができます。

 
CREATE SERVER weather_server
WRAPPER web_wrapper OPTIONS (URL 'http://www.weatherforecast.com')

OPTIONS 文節により、基本 CREATE SERVER ステートメントは、このデータ・ソース・タイプのインスタンスのアクセスにラッパーが必要とする情報でカスタマイズできます。

ラッパーとサーバーが定義された後で、連合ミドルウェアのデータ・モデルに関して、リモート・ソースでデータが記述される必要があります。ここで説明する連合データベースはオブジェクト・リレーショナルなデータ・モデルをサポートするので、外部ソースからの各データ・コレクションは、適切なタイプの列を持つ表として連合エンジンに対して記述されなければなりません。表としてモデル化された外部データ・コレクションは、ニックネームと呼ばれ、その表名と列名はアプリケーションによって連合へサブミットされる SQL で使用されます。ニックネームは CREATE NICKNAME ステートメントを介して定義されます。次のステートメントは、天気についての情報コレクションにニックネームを設定し、照会で使用できる「列」を識別します。

 
CREATE NICKNAME weather
      (zone integer, climate varchar(10),  yearly_rainfall float)
      SERVER weather_server  OPTIONS (QUERY_METHOD 'GET')

OPTIONS 文節は、この場合はニックネームに対する照会を処理するために、ラッパーが必要とする情報を渡す手段です。

データを保管する以外に、多くのデータ・ソースは特別な検索やその他の演算を実施する機能を備えています。このような機能はユーザー定義関数として SQL で表すことができます。たとえば、あるユーザーは、エアコン販売対象の顧客を識別するために、場所と日付に基づく気温予測を実施したいとします。

 
SELECT c.Name, c.Address
FROM customers c, stores s, weather w
WHERE temp_forecast(w.zone, :DATE) >= 85 AND
		c.ShopsAt = s.id and s.location = w.zone

ここで、関数 temp_forecastは、ニックネーム weather に対する気温予測を実施する、データ・ソースの機能を表すために使用されます。これはマップ済み関数として外部データ・ソースによって実装されたユーザー定義関数です。マップ済み関数は、DDL ステートメントを介して連合システムに対してもう一度識別されます。CREATE FUNCTION ステートメントは、連合データベースに対して、これが SELECT ステートメントに使用できる関数であることを知らせます。

 
CREATE FUNCTION temp_forecast (integer, date) RETURNS float AS TEMPLATE
 DETERMINISTIC NO EXTERNAL ACTION

AS TEMPLATE 文節は連合データベースに対して、関数のローカル・インプリメンテーションのないことを知らせます。次に、CREATE FUNCTION MAPPING ステートメントは、連合データベースに対して、どのサーバーが関数を評価できるかを知らせます。いくつかの関数マッピングが同一関数用に作成されることもあります。この記事の例では、次のステートメントがマッピングを実施します。

 
CREATE FUNCTION MAPPING tf1 for temp_forecast SERVER weather_server

DDL ステートメントは、ニックネームとマップ済み関数のシグニチャーに関する情報を記述したメタデータを生成します。このメタデータは、連合照会処理エンジンによって使用され、連合データベースのグローバル・カタログに保管されます。

照会処理

連合システムが構成された後は、アプリケーションは SQL で記述された照会を連合サーバーにサブミットできます。連合サーバーは、個々のデータ・ソースで実行できるフラグメントに照会を分解する実行プランを策定し、照会を最適化します。前述のとおり、照会の分解方法は数多くあり、オプティマイザーは総リソース消費見積りが最低であることを基準に、多くの選択肢の中から選びます。プランが選択されると、連合データベースは実行を駆動し、ラッパーを起動してそのラッパーに割り当てられたフラグメントを実行します。フラグメントを実行するために、ラッパーは必要なデータ・ソース操作があれば実行します (たとえば、一連の関数呼び出しや、データ・ソースにネイティブの照会言語でデータ・ソースにサブミットされた照会など)。結果のデータ・ストリームは連合サーバーに戻され、連合サーバーがそれらを結合し、データ・ソースで実施できなかった付加的処理を実施し、最終結果をアプリケーションに返します。

IBM の連合照会処理に対するアプローチの中心には、連合サーバーのオプティマイザーとラッパーが一緒に照会実行用プランに作用する方法があります[4]。オプティマイザーは、考え得る照会プランのスペースを探る役目を担います。動的プログラミングは結合の列挙で使われるデフォルト方式であり、オプティマイザーが最初に単一表アクセス用に、次に 2 方向結合用にプランを生成します。各レベルで、オプティマイザーはさまざまな結合順序と結合方式を考慮し、すべての表が共通のデータ・ソースに位置するときはデータ・ソースか連合サーバーかのどちらで結合を実施するかを検討します。このプロセスを図 2 に示します。

図 2. 結合のための照会プランニング
図 2. 結合のための照会プランニング
図 2. 結合のための照会プランニング

オプティマイザーはリレーショナル・ラッパーと非リレーショナル・ラッパーとでは動作が異なります。オプティマイザーは、ラッパーで提供された情報を使用して、リレーショナル・ソースを詳細にモデル化し、ソースに期待することを表すプランを生成します。

しかし、非リレーショナル・ソースには共通操作一式または共通データ・モデルがないため、これらソースではもっと柔軟な調整が必要です。したがって、オプティマイザーは非リレーショナル・ラッパーと一緒に次のように機能します。

  1. 照会フラグメントを単一ソースに適用する場合、IBM 連合データベースは「requests (要求)」と呼ばれる候補の照会フラグメントをラッパーにサブミットします。
  2. 非リレーショナル・ラッパーが要求を受け取ると、(もしあれば) 対応する照会フラグメントのどの部分をデータ・ソースで実行できるかを見極めます。
  3. ラッパーは、受け入れたフラグメント部分を記述した応答を返します。応答には、生成される行数予測、合計実行時間予測、およびラッパー・プランを含みます。ラッパー・プランとは、受け入れたフラグメント部分を実行するためにラッパーが知るべき情報をすべてカプセル化して表現したものです。
  4. 連合データベース・オプティマイザーは応答をグローバル・プランに組み込み、ラッパーで受け入れられなかったフラグメント部分を補うために必要に応じて追加演算子を導入します。応答からのコストとカーディナリティー情報は、プランの総コスト見積りに使用され、数多くの候補の中から総コストが最小のプランが選択されます。プランが選択されても、即時実行は必要ありません。データベース・カタログに保管しておいて、後で何度でも照会実行に使用できます。プランが即座に使用される場合でも、作成されたのと同じプロセスで実行される必要はありません (図 3 参照)。
図 3. 非リレーショナル・ソースのコンパイルおよびランタイム
図 3. 非リレーショナル・ソースのコンパイルおよびランタイム
図 3. 非リレーショナル・ソースのコンパイルおよびランタイム

たとえば、取引、始値/終値、出来高などを含む株式に関する情報をエクスポートする Web サイトを想定します。Web サイトはあるフォームで検索でき、多くの場合、そのフォームによって属性の (全部ではありませんがいくつかの) 値が制約されます。次のような照会を考えてみます。

 
SELECT TickerSymbol, StockName
FROM Stocks
WHERE Exchange='NYSE' AND Closing - Opening > 5

これは単一表照会なので、結合方式や順番を考える必要はなく、照会全体で構成されるただ 1 つのフラグメントが Web データ・ソース用のラッパーにサブミットされます。フォームでユーザーが基になるデータの「Exchange」属性の一致する値を指定できても、始値と終値の違いを指定する方法が提供されない場合、ラッパーは「Exchange」に関する述部は受け入れるが「Closing - Opening > 5」述部を却下する応答を生成します。オプティマイザーは連合サーバーで後者の述部を評価する演算子を導入することで補います。一般的に、ラッパーは SELECT リストで要求されたどの列の値も返せなければなりませんが、任意の述部や、より複雑な SELECT リスト式を却下することもできます。

「Exchange」述部だけがデータ・ソースによって評価されることを示すほか、応答は、応答で表される照会の実行に十分な情報を含むラッパー・プランを含みます。たとえば、ラッパー・プランは、ユーザーが手作業で照会フォームを記入した場合にブラウザーが生成するのと同同等の、パラメーター化された URL を含む場合があります。実行時に、連合サーバーはこのプランをラッパーに戻し、ラッパーが URL を抽出してそれを Web サイトへサブミットし、結果のデータ・ストリームを構文解析して要求された値を連合サーバーへ戻します。

連合データベース・システムの使用

連合システムはなぜ便利なのでしょうか。ユーザーは連合機能をどのように使用するのでしょう。一般的に、複数のデータ・ソースと、これら多様なソースからの情報を組み合わせる必要のあるあらゆる状況において、連合システムは有用です。このセクションでは、現在 IBM の連合テクノロジーを使用してビジネス上の問題を解決している顧客事例を、いくつか紹介します。

分散操作: 大手製薬会社

今日の多くの企業は、世界中に分散する複数の拠点でのアクティビティー調整の必要性を抱えたグローバル企業です。たとえば、ある製薬会社では、ヨーロッパと米国の両方に研究所があります。それぞれの研究所には、特定の疾病と戦う新薬を研究する多くの科学者を抱えています。科学者はみな、化合物の特定の特性や化学構造 (構造的類似性) によって検索できる専門システムに保管された化学化合物データベースにアクセスできます。どちらの研究所でも、科学者はさまざまな被験生物に対する効果を実験するために、スループットに優れた化合物スクリーニングを実行します。実験結果は、各研究所にあるリレーショナル・データベースに保管されます。科学者によってアクセスされるその他のデータ・ソースには、ゲノムおよびプロテオミクス情報の大規模フラット・ファイル、特許データベース、データおよび分析のスプレッドシート、イメージ、テキスト文書などがあります。

2 つの研究所の科学者は、異なる使命を担い、探求する治療方法や処置は異なります。つまり、実施する実験も異なるわけで、焦点を当てる化合物集合も異なります。ただし、異なるターゲットに対して同じ化合物が有用な場合もよくあり、時には 1 つの実験が他の実験結果の優れたインジケーターになることもあります。したがって、労力の重複をなくすためにも、一方の研究所の科学者が他方の研究所で生成されるデータにアクセスできることが重要です。これはすべての化合物データと実験結果を含む大規模ウェアハウスを構築することで実現することもできますが、そのアプローチにはいくつか欠点があります。まず、大西洋の両側から毎日大量のレコードが追加されるので、実験結果データはめまぐるしく変わり、保守は非常に困難です。2 番目に、ウェアハウスは両サイトで複製される必要があります。そうしないと、一方のサイトはデータ・アクセスのパフォーマンスがかなり遅くなってしまいます。レプリケーションはソリューションの付加的コストとなり、保守の複雑性も増します。3 番目に、現在は専用リポジトリーに保管されている複合データをリレーショナル・ベースへ移行する必要があり、検索アルゴリズムや既存アプリケーションを実装し直す必要があります。

連合ソリューションは以上のような問題を排除します。データは既存のデータ・ソースに残ったままで、データ・ソースにネイティブなアクセス・パスが使用され、現行のアプリケーションは無修正で稼動します。ただし、位置する大陸に関係なく任意のソースからのデータをアクセスできる新規アプリケーションを作成することも簡単です。迅速なアクセスを実現するために、ローカル・データはローカルに留まりまります。使用頻度の低いリモート・データは必要に応じてアクセスでき、可能な限り効率的に取り出されるように、照会は連合サーバーによって最適化されます。両研究所で頻繁にアクセスされるデータ部分については、必要であればレプリケーションも使用できます。

異種混合レプリケーション

多くのビジネスはデータの複数コピーを保持することを選択しています。たとえば、全米にアウトレットを持つある大手小売業者は、地域ウェアハウスにあるデータをさまざまなロケーションからバックアップしています。小売アウトレットはあるリレーショナル・データベース管理システムを使用し、ウェアハウスはもっと拡張性のある別の DBMS を使用して実装されています。しかし、ここでソースからウェアハウスへのデータ転送方法について問題が提示されます。IBM の連合テクノロジーは、ソースからデータを選択してウェアハウスに挿入するデータ移動だけでなく、ウェアハウスへの挿入前にさまざまなアウトレットからのデータを集計してデータを新たな形に整えることも容易にします。

IBM は DB2 DataPropagator™ というレプリケーション製品を提供します。これは、連合データベースの機能を使用して、リレーショナル・データベース間のデータを複製することにより、分散データベース環境の統合に貢献します。DataPropagator はリモート・システム間のデータ・コピーを自動化し、手作業によるデータベースのアンロードおよびロードの必要性を回避しています。DB2 以外のリレーショナル・ソースについては、ソースに対する変更をキャプチャーしてステージング表へ書き込むために Capture トリガーが定義されます。IBM 連合データベース・サーバー上で稼動する Apply プログラムは、ステージング表にニックネームを使用して、ステージング表から IBM 連合データベース内または DB2 以外のリレーショナル・データベース内のコピー先の表へ変更内容をコピーします。連合テクノロジーを活用することによって、異種混合レプリケーションが容易になります。

分散データ・ウェアハウス

可用性を高め総コストを低く抑えるために、分散データ・ウェアハウスの実装が提唱されました。企業は、ウェアハウスから派生したデータのハイレベルな要約だけを保管するデータ・マートをいくつか作成できます。IBM の連合テクノロジーを使用すれば、データ・マートとウェアハウスを別々のシステムに置きながらも、データ・マートのユーザーはローカル・レベルの要約からウェアハウスへ簡単にドリルダウンできます。連合テクノロジーは、仮想データ・ウェアハウスを提供することによって、データ・ウェアハウスが分散されていることを知る必要のないユーザーを保護します。

地理情報アプリケーション

ある銀行は、新しい支店を開設する場所を選定する必要があります。その場所は、予想利益を最大化するものでなければなりません。そのために、銀行は周辺の人口統計 (人口統計はターゲットの顧客ベースに適合するかどうか)、その地域の犯罪発生率 (窓口業務には犯罪発生率が低いことが重要です)、主要高速道路への近接の度合い (隣接地域からの顧客を引きつけるため)、回避すべき既知の問題地域があれば、その地域との近接の度合い (付近のゴミ捨て場などの汚い特性はビジネスにマイナスの影響を与えかねません) などを考慮する必要があります。必要な情報の中には、銀行の独自データベースから得られるものもあれば、コミュニティーに関する情報の入った外部データ・ストアーから取り出すべき情報もあります。このアプリケーションは、地理情報データを従来型ビジネス・データと統合する必要性を示しています。相関するデータの先進的照会分析機能と、地理情報コンテキストでデータを視覚的に表示できるエンドユーザー・ツールを必要とします。

伝統的に、地理情報データは、特化した地図情報システム (GIS) によって対処されてきました。しかし、GIS では、空間的データを、企業の RDBMS や外部データ・ソースに保管されたその他のビジネス・データと統合できません。DB2 地理情報エクステンダーは、IBM パートナー Enveronmental Systems Research Institute (ESRI) とのコラボレーションの成果です。DB2 地理情報エクステンダーは IBM 連合データベースと共に機能して、両方の優れた点をユーザーに提供します。ユーザーは、連合システムから提供される広範なビジネス情報と DB2 地理情報エクステンダーに組み込まれた地理情報インテリジェンスを活用できます。これにより、組識は組識自体のビジネス理解を深め、既存データの価値を活用し、ビジネスの成功につながる洗練された新規アプリケーションを構築できます。

結論

研究機関からの大きな関心にもかかわらず、リレーショナルおよび非リレーショナルのデータ・ソースを 1 つの連合に統合する問題に対処する商用のデータベース管理システムは、ほとんどありません。IBM の連合機能によって、IBM はこの目標に向けて大きな進歩を遂げました。IBM の固有の連合照会処理テクノロジーを利用すると、ユーザーは個々のデータ・ソースのパワーと共に、DB2 SQL のすべてのパワーを活用できます。ユーザーには透過性、異種性、高度な機能、基になる連合ソースの自律性、拡張性、オープン性、最適化されたパフォーマンスといった、ありとあらゆる利点が提供されます。現在、連合は多くの重要なビジネス上の問題の解決に使用されています。

将来的にも、連合のパフォーマンスと機能性は改善されて行きます。たとえば、キャッシング様式は、自動サマリー表 (AST) 方式を使用してすでに実現されています。AST を使用すると、管理者は基になる表またはニックネーム一式に、データのマテリアライズされたビューを定義できます。照会の特定のクラスについて、基礎表をアクセスしなくても、データベースは AST を使用して照会に回答できるかどうかを自動的に判断できます。定常的なパフォーマンス改善のほか、IBM は連合システムの構成、チューニング、および管理を支援するツールにも取り組んでいます。非リレーショナル・ソースからのデータの統計情報を生成するツールや、連合システムの動作をモニターするツールは、開発途中です。ラッパー開発者を支援するツールも開発中です。

最後に、優れた設計の連合データベース管理システムと付随するツール一式でさえ、データ統合の大きな問題に対する部分的ソリューションにすぎません。包括的ソリューションは、データのみならずアプリケーションも統合する必要があり、データ品質、注釈、用語の違い、および情報を組み合わせるタイミングと方法を示すビジネス・ルールなど、より高度な課題に対処する必要があります。IBM はお客様がビジネス統合要件を満たせるように、より広範なこの一連の情報統合要件に焦点を当てており、データベース・スタイルの連合はまさに 1 つの鍵となる統合テクノロジーです。


ダウンロード可能なリソース


コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Information Management
ArticleID=323430
ArticleTitle=IBM 連合データベース・テクノロジー
publish-date=03012002