データベース・フェデレーション （連合）による データ・インテグレーション

データベース・フェデレーション
（連合）による
データ・インテグレーション
L. M. Haas
E. T. Lin
M. A. Roth
共著
現代の大企業では、組織内の異なる部署が、重要
なデータを作成、保存、検索するのに、それぞれ
別のシステムを使うという事態をまず避けること
ができません。それでも、企業は、こうした多様
まなシステムからの情報を結合することにより、
所有するデータの価値を完全に生かせるのです。
データベース・フェデレーション（連合）は、リ
レーショナル・データベース管理システムから成
るミドルウェアが、多くの異種データ・ソースに
対して、一様なアクセスを提供する、データ・イ
ンテグレーションへの1つのアプローチです。本稿
では、データベース・フェデレーションの基本を
述べ、データベース・フェデレーションのスタイ
ル例を紹介します。そして、各フェデレーション
のスタイルを、どのような条件時に使うべきかの
概略を述べます。データベース技術に基づいたイ
ンフォメーション・インテグレーション・ソリュ
ーションの利点を述べ、データベース・フェデレ
ーションのアプローチの有効性を、IBMのDB2製品
が関与する多様な利用シナリオを通じて示します。
現代の大企業では、組織内の異なる部署が、重要
なデータを作成、保存、検索する際に、それぞれ
別のシステムを使用する事態をほとんど避けられ
ません。このデータ・ソースの多様化は、企業内
の部署間の連携不足、新技術導入スピードの違い、
吸収合併、さらに協力関係にあるグループが地理
的に隔たっているなど、多くの原因により発生し
ます。それでも、企業は、これら多種多様なシス
テムの情報を結合することによってのみ、所有す
るデータの価値を完全に生かせるのです。
金融業界では、合併はほぼ日常的な出来事です。
合併により誕生した会社は、元の会社のデータ・
ストアを引き継ぎます。これらのストアの多くは
リレーショナル・データベース管理システムです
が、違うメーカーのシステムである場合もありま
す。一方の会社は、主にSybase, Inc. の製品を使っ
て き た の に 対 し 、 も う 一 方 の 会 社 は 、 Informix
Software, Inc.のものを使ってきたかもしれません。
ま た 、 両 社 と も 、 Documentum1 や IBM Content
Manager2 など、テキスト文書の保存に、1つか複数
の文書管理システムを使ってきたかもしれません。
両社は、重要な情報（例えば、あるお客様への融
資を承認するリスクなど）を計算するアプリケー
ション、あるいはお客様の購買パターンについて
の情報マイニングを行うアプリケーションを使っ
ていたかもしれません。
既存のそして新規のアプリケーションを用いて新
しいポートフォリオを解析したり、また、一般的
に両社の結合したリソースを共通のインターフェ
ースを通して使用するために、合併後、新会社は
両データ・ストアの顧客情報にアクセスできなけ
ればなりません。たとえ顧客データが、異なるデ
ータベースに異なるフォーマットで保存されてい
ても、新会社は、共通の顧客を見つけ出し、その
口座を統合しなければなりません。さらに、既存
のデータをWeb上で得られるか、またはビジネス・
パートナーから得られる新しいデータと結合する
こともできなければなりません。これらは、全て
データ・インテグレーション3の持つ一側面であり、
各々大きな課題を提起しています。

Copyright 2002 by International Business Machines
Corporation. Copying in printed form for private use is permitted
with-out payment of royalty provided that (1) each reproduction
is done without alteration and (2) the Journal reference and IBM
copy-right notice are included on the first page. The title and
abstract, but no other portions, of this paper may be copied or
distributed royalty free without further permission by
computer-based and other information-service systems.
Permission to republish any other portion of this paper must be
obtained from the Editor.
IBM SYSTEMS JOURNAL, VOL 41, NO 4, 2002 0018-8670/02/$5.00  2002 IBM
HAAS, LIN, AND ROTH
1
時には、データ・インテグレーションの必要性は、
センサーからデータを読み取り（例えば、製造プ
ロセスにおけるある工程の温度など）、データベ
ースに蓄積されている履歴データから導かれるベ
ースライン値と比較するという程度の単純なもの
かもしれません。あるいは、スプレッドシートの
データと実験結果を含むいくつかのデータベース
からのデータを比較したり、多額のクレジットカ
ード未払い残高があり、かつ、収入がある基準値
を下回る顧客を抽出するといったケースもあるで
しょう。今日のビジネスの世界では、データ・イ
ンテグレーションのニーズは至るところにありま
す。
データを統合するメカニズムは数多くあります。
例えば、アプリケーション固有のソリューション、
アプリケーションを統合するフレームワーク、ワ
ークフロー（あるいはビジネス・プロセスの統合）
のフレームワーク、ポータル・スタイルかメタ検
索エンジンの統合を伴うデジタル・ライブラリー、
データウェアハウス、データベース・フェデレー
ションなどです。それぞれを、簡単に説明しまし
ょう。
おそらく、最も一般的なデータ・インテグレーシ
ョンの方法は、アプリケーション自体が、対象と
なるソースに直接アクセスし、それらソースから
得られたデータを結合する、特定用途のアプリケ
ーションによるものでしょう。この方法はいつで
も上手くいくのですが、高価で（時間とスキル両
方の意味で）、壊れやすく（基礎となっているデ
ータ・ソースを変更すると、いとも簡単にアプリ
ケーションを破壊することがあります）、また、
展開が困難です（新しいデータ・ソースには新し
いコードを作成しなければなりません）。
アプリケーション統合のフレームワーク 4,5 かコン
ポーネント・ベースのフレームワーク6を使えば、
より確実なアプローチが可能です。このようなシ
ス テ ム は 一 般 的 に 、 CORBA** （ Common Object
Request Broker Architecture ） や J2EE** （ Java 2
Platform, Enterprise Edition）などの、標準のデータ
かプログラミングのモデルを採用します。これら
のシステムでは、データや他のアプリケーション
にアクセスするための、また、新しいデータ・ソ
ースを追加する（通常、フレームワークのアダプ
ター・インターフェースに適合する、データ・ソ
ースのためのアダプターを作成することにより）
ための、アプリケーションへの明確なインターフ
ェースが提供されます。これらのフレームワーク
は、データ・ソース内の変更からある程度アプリ
ケーションを保護します（ソースが変更された場
合、アダプターを変更する必要があるかもしれま
せんが、アプリケーションには影響がありません）。
新しいソースの追加もより簡単でしょう（新しい
アダプターが必要になるかもしれませんが、変更
はより隔離されたものになり、また、アダプター
がすでに存在していて、購入できる場合もありま
す）。アプリケーション・プログラマーはシステ
ムの詳細な知識を必要としないので、アプリケー
2 HAAS, LIN, AND ROTH
ションは一般的にはより簡単に作成できます。し
かし、このようなシステムがデータ・インテグレ
ーションの問題を解決するとは限りません。もし、
種々のソースから得られたデータの組み合わせ、
解析、比較などが必要になった場合、アプリケー
ション開発者は、そのためのコードを作成しなけ
ればなりません。
同様に、ワークフロー・システム7はプログラミン
グの対象をより高度に抽象化して、アプリケーシ
ョン開発者に提供しますが、よりプロセス指向の
モデルを使用します。ここでも、これらのシステ
ムはアプリケーションを環境の変化からある程度
保護するだけでなく、1つのソースから他のソース
への型どおりの結果をサポートします。しかし、
これらも依然として、データの比較や操作に対し
ては限定的な動作しかしません。
ユーザーの要求に応えて、複数の異なるデータ・
ソースから結果を収集する、デジタル・ライブラ
リーはもう1つのデータ・インテグレーションの形
です。例えば、スタンフォードのInfoBusアーキテ
クチャー8はいくつかの参考文献リポジトリーを検
索して、単一の結果リストを返す文献検索サービ
スを提供しています。通常、これら検索対象とな
るソースは機能的に似通っています。例えば、全
てのソースが、テキスト文書のみ、文献目録のみ、
URL（Uniform Resource Locator）のみ、イメージ
のみを含むなど。これらの「メタ検索エンジン」
の多くは、適合率や書式の正規化はするかもしれ
ませんが、結果の結合はせず、全ての結果は、お
そらく推定適合率で並べ替えられ単一のリストの
一部として返されます。同様に、 ポータル も全く
異なるデータ・ソースから情報を集め、ユーザー
がまとめて見られるように結果を同時に表示する
方法を提供します。異なる検索による結果は通常
インターフェースの異なる領域に表示されますが、
実際は、ポータル・フレームワークでは、その他
のやり方で結果を組み合わせるようアプリケーシ
ョンのコードを作成することも可能です。ポータ
ルは、ある種のアプリケーション統合フレームワ
ーク上に構築することが多いのですが、多様な情
報に素早くアクセスする、単純でおどろくほど強
力な方法を提供します。例えば、IBMのEnterprise
Information Portalはテキスト検索エンジン、文書管
理システム、イメージ・ストア、そしてリレーシ
ョナル・データベースに及ぶ広範なリポジトリー
からの、各種タイプのデータを取得できます9。し
かし、この場合も、より高度な解析、比較あるい
は統合が必要な場合は、アプリケーション開発者
がコードを作成しなければなりません。
これに対し、データウェアハウスやデータベース・
フェデレーションは、結合、比較、解析かデータ
の操作に使用できる、強力で高度な照会言語を提
供します。照会の最適化技術により、たとえ照会
が非手続型でも、効率的に回答が得られることが
確実になり、アプリケーション開発がきわめて容
易になります。データウェアハウスは、1つか複数
のソースから、データをリレーショナル・データ
IBM SYSTEMS JOURNAL, VOL 41, NO 4, 2002
ベース内に新たに定義したスキーマにロードする
ことにより構築します。データはロードの過程で
クレンジングされ、変換されることもあります。
基礎となるデータ・ソースへの変更はロード・プ
ロセスの変更を招くかもしれませんが、アプリケ
ーション内のデータ解析に関係する部分は保護さ
れます。新しいデータ・ソースは、新しいデータ
を定義するために、新しいロード・プロセスが必
要となり、スキーマの変更を招くかもしれません。
SQL（構造化照会言語）ビューはそのような進化
から、さらにアプリケーションを保護できます。
しかし、リレーショナル・データベース管理シス
テムの標準的部分ではないデータ・ソースの機能
はすべて、ウェアハウス内かアプリケーションの
一部として、再実装しなければなりません。
ウェアハウスだけに基づいたソリューションは、
種々の理由で、不可能かあるいはコスト効率が悪
い可能性があります。例えば、データを元の場所
からデータウェアハウスに移動するのは、常に適
切であるとは限りません。また、前述のように、
ウェアハウスを扱うには、ウェアハウス自体の保
守と実装のコストが必要になります。データベー
ス・フェデレーション（文献によっては「 メディ
エーション（仲介）」と呼ぶこともあります）は、
データを必ずしも移動しなくてもよい、仮想デー
タウェアハウスを提供します。従って、ウェアハ
ウスの利点に加えて、「生」のデータと機能にア
クセスできます。単一の任意の複合照会により、
たとえソース自体がこのような照会に答えるのに
必要な全ての機能を備えていなかったとしても、
異なるタイプの複数のソースのデータを効果的に
結合できます。言い換えれば、連合データベース・
システムは、照会を最適化し、データ・ソースに
不足しているSQLの機能を補足するということで
す。さらに、照会はデータ・ソース特有の機能を
利用でき、連合システムを介したソースに対する
アクセスで失われる機能はありません。
もちろん、データベース・フェデレーションはク
ライアント・アプリケーションとデータの間に、
もう1つコンポーネントを追加することにため、こ
の余分なレイヤーが性能に影響を与えます。実際、
新しいレイヤーの追加により、単一の連合データ・
ソースのアクセス時間が短縮されると考えるべき
ではありません。データベース・フェデレーショ
ンによりもたらされる主要な性能の利点は、単一
のSQLステートメントで 複数の ソースのデータを
効果的に結合できる能力です。連合サーバーの2つ
のコンポーネントには次の機能があります。つま
り、照会の書き換えとコストに基づく最適化です
10-12
。連合サーバーの照会書き換えコンポーネント
は、ユーザーの照会を意味的に等価でより効率的
に実行できるものに積極的に書き換えます。コス
トに基づくオプティマイザーは、広範なアクセス
戦略を検索し、照会に含まれるローカル・テーブ
ルと連合データ・ソース両方にとり最適なグロー
バル実行プランを選択します。
高度な照会処理エンジンを持つ連合サーバーに対
して出された照会が、データ・ソースそのものに
対して直接出された同じ照会よりも実際に性能が
よいという場合もあることに注目してください。
照会書き換えフェーズでは、連合データ・ソース
がユーザーによる元の照会を与えられたときより
も、より効率的な実行プランを選べるように、ユ
ーザーの照会を書き換えます。
この論稿の目的は、データベース・フェデレーシ
ョンが、データ・インテグレーションの基本的な
ツールであることを示すことです。論稿の残りの
部分は、次のように構成されています。次のセク
ションでは、データベース・フェデレーションを
より詳しく述べ、DB2 データベース・フェデレー
ションの体系について述べます。データベース・
フェデレーションにはいくつかのスタイルがあり、
以下のセクションで紹介します。また、どのよう
な場合に各スタイルの連合を使うべきかも述べま
す。その次のセクションでは、データベース技術
の上に統合ソリューションを構築する利点を述べ、
続くセクションでは、多くの利用シナリオを通じ、
このアプローチの有効性を示します。最後に、ま
とめと将来の研究への考察を記します。
データベース・フェデレーションの基礎
「データベース・フェデレーション」という言葉
は、リレーショナル・データベース管理システム
から成るミドルウェアが、多くの異種データ・ソ
ースに一様なアクセスを可能とする体系を指しま
す。データ・ソースが連合化されたというのは、
データベース管理システムにより、それらデータ・
ソースが統一されたシステムへと互いにリンクさ
れたということです。システムは、ソースが何か、
どのようなハードウェアやソフトウェアを実行さ
れているのか、どのようにアクセスするのか（ど
のようなプログラミング・インターフェースか言
語を通して）、あるいはこれらのソースに格納さ
れたデータがどのようにモデル化され管理されて
いるのか、などをユーザーに対して不可視にしま
す。これはまた、アプリケーション開発者にとっ
ても、データベース・フェデレーションは単一の
データベース管理システムのように見えるのです。
ユーザーは、SQL言語の全ての機能を使用し情報
を検索し操作できます。単一の照会で複数のソー
スのデータにアクセスでき、それらデータの結合、
制限、集約、解析が思いのままにできます。しか
も、ソースはデータベース・システムである必要
も全くありません。実際、ソースはセンサーから
フラット・ファイル、アプリケーション・プログ
ラム、XML（Extensible Markup Language）まで、
何でも可能です。
IBM SYSTEMS JOURNAL, VOL 41, NO 4, 2002 0018-8670/02/$5.00  2002 IBM
HAAS, LIN, AND ROTH
3
多くの研究プロジェクトといくつかの商用システ
ムで、データベース・フェデレーションの概念が
実装され、進展してきました。パイオニア的研究
プロジェクトには、TSIMMIS13 とHERMES14 があり
ます。これらのプロジェクトでは、「メディエー
ター」と呼ばれる、特定のデータ・ソースを統合
するための、非手続型仕様を持った、特別用途の
照会エンジンを実装するデータベース概念を利用
しました。DISCO15 とPegasus16は本当のデータベー
ス・フェデレーションの感覚により近づいたもの
です。DISCOは、多くの異種データ・ソースへの
拡張設計に注力しました。Pegasusは独自のデータ・
モデルと照会言語を持ち、データ・ソースのモデ
リングに非常に大きな柔軟性を与える、機能オブ
ジェクト・モデルを持っていました。これらは、
それぞれ独自のデータベース管理システムをゼロ
から作りました。Garlic17 は、標準のリレーショナ
ル・データベース（DB218）が持つ全ての機能を利
用するために行われた最初の研究プロジェクトで
すが、言語とデータ・モデルをある程度のオブジ
ェクト指向の機能をサポートできるよう拡張しま
した。Garlicのラッパー・アーキテクチャー 19 とソ
ース間照会最適化20は、いまやIBM連合データベー
ス・オファリングの基本要素となっています。
一方、商業分野における連合への最初のステップ
には「ゲートウェイ」がありました。ゲートウェ
イはデータベース管理システムが照会を他のデー
タベース・システムに転送できるようにしました。
当初、ゲートウェイ製品は同種のソース、しかも
多くの場合同じメーカーのものに対するアクセス
しかできず、照会は1つのデータ・ソースのデータ
しか参照できませんでした。時が経つと、iWay
SoftwareのEDA/SQL Gateways21 のような、より精巧
なゲートウェイ製品が登場しました。これらの製
品では、Open Database Connectivity（ODBC）ドラ
イバー22を持つ、異種のリレーショナル・システム
と非リレーショナル・システムに対するアクセス
が可能になりました。DB2 DataJoiner*23は商用シス
テムとしては初めて、実際にデータベース・フェ
デレーションを使用したものです。DataJoinerは単
一の照会で複数の異種リレーショナル・ソースか
らデータを結合する機能と、良好な性能を得るた
めに照会を最適化する機能を持つ、完全なデータ
ベース・エンジンを備えていました。Microsoftの
Access24 はより多くの種類のデータ・ソースにアク
セスできましたが、DataJoinerがサポートするよう
な大企業の主幹業務用アプリケーションではなく、
より小規模のアプリケーション向けに開発された
ものです。
DataJoiner と Garlic は 一 緒 に 「 成 長 」 し ま し た 。
DataJoinerでは、限定された、ほとんどの場合リレ
ーショナルなソースに対して、堅牢で効率的な照
会に注力しました。一方、Garlicはより多種多様な
ソースへの拡張性に注力しました。今日、両方の
プロジェクトから得られた最高のアイデアが、
DB225に取り入れられています。DB2でも単純なデ
ータ・ソースを「連合」するユーザー定義関数を
使用できます26。このことから、DB2は、データ・
インテグレーションに活用できる、非常に豊富な
4 HAAS, LIN, AND ROTH
データベース・フェデレーションの概念をサポー
トできます。例えば、DiscoveryLink*27は、ライフ・
サイエンスのデータ統合にDB2技術を応用したIBM
のソリューションです。
IBMのデータベース・フェデレーション・オファリ
ングでは、いくつかの目標を追及してきました。
最も基本的な目標は「 透過性 」です。これには、
基礎となっているデータ・ソースの相違点、特異
性、実装形態などをユーザーには不可視にする必
要があります。この機能で、実際にはデータが多
様なデータ・ソースの集まりの中に保存されてい
ても、あたかも全てのデータが単一のデータベー
スに入っているかのようにアプリケーションを作
成できるようになります。2番目の主要な目標は、
「 多様性のサポート 」です。言い換えれば、ハー
ドウェア、ソフトウェア、データ・モデル、イン
ターフェースかプロトコルなどの制限なしに、広
範なデータ・ソースに適応する機能です。「 高度
機能 」では、両方のよい点、つまり、連合内の全
てのデータに対する、豊富な標準仕様準拠のDB2
SQL機能だけでなく、連合エンジンには不足してい
る、データ・ソースが有する機能を活用する機能
も同時に提供されます。
4番目の目標は「拡張性」です。変化し続けるビジ
ネス・ニーズに応えるため、新しいデータ・ソー
スをダイナミックに追加できる機能です。「 オー
プンネス」は重要な必然の結果です。DB2製品は標
準規格に準拠したコンポーネントを使用し連合を
確実に拡張できるようにするため、該当する標準
規格28,29をサポートします。連合への統合を進める
ことにより、各データ・ソースの「 自律性 」を損
なってはなりません。既存のアプリケーションは
変更なしで実行でき、データは移動も変更もされ
ず、インターフェースも同じでなければなりませ
ん。最後に決して忘れてならない目標は、DB2デー
タベース・フェデレーションの技術が「 性能向上
のために照会を最適化する 」ということです。リ
レーショナル照会は非手続型です。リレーショナ
ル照会が複数のデータ・ソースにまたがる場合、
実行方法に関する誤った決定はリソース面で高く
つくことになります。従って、DB2連合エンジンで
は、連合データ・ソースを含む照会を扱えるよう、
従来までのオプティマイザー12の機能を拡張してい
ます。
データベース・フェデレーションのためのDB2ア
ーキテクチャー 本稿の残りの部分では、DB2のデ
ータベース・フェデレーション機能を重点的に取
り上げます。図1はDB2データベース・フェデレー
ションのアーキテクチャー全体を示したものです。
ユ ー ザ ー は 、 ど の よ う な DB2 イ ン タ ー フ ェ ー ス
（ CLI [Call Level Interface], ODBC, JDBC** [Java**
Database Connectivity]など）を通してでも連合にア
クセスできます。このアーキテクチャーの主要な
コンポーネントはDB2連合エンジンそのものです。
このエンジンは、SQL照会をコンパイルし、最適化
するStarburstスタイルの照会プロセッサー30、照会
を実行するラン・タイム・インタープ
IBM SYSTEMS JOURNAL, VOL 41, NO 4, 2002
図1 データベース・フェデレーションのためのDB2アーキテクチャー
リター、ローカル・ストアを制御するデータ・マ
ネージャー、そして「 ユーザー定義関数 」や「 ラ
ッパー 」をはじめとする外部データへのアクセス
を可能にするいくつかの拡張機能などから成りま
す。
ユーザー定義関数（UDF）はアプリケーション開
発者が作成し、データベースに登録するルーチン
です。ユーザー定義関数は、入力パラメーターを
取得し、スカラーの結果か表データのいずれかを
返します。これらの関数は、データベースにより
すでにサポートされている関数と組み合わせるた
め、あるいは、外部ソースにより提供される特定
の関数に対するアクセスを提供するために使用さ
れます。
ラッパーはDB2エンジンと1つかそれ以上のデータ・
ソースの間を取り持つものであり、ソースのデー
タ・モデルをDB2のデータ・モデルにマッピング
し、DB2データ・オペレーションをソースが扱え
る要求に変換します。DB2はInformix、Oracle、MS
SQLサーバー25など多くの一般的なデータ・ソース
用、さらにDocumentumやBLAST31 などの特化した
データ・ソースのためのラッパーも提供します。
また、お客様やサード・パーティー・ベンダーが
自社のソース用にラッパーを作成するためのツー
ルキットもあります。
当然ながら、このアーキテクチャーで可能な異な
る連合のスタイルもあります。次のセクションで
は、これらの各スタイルをより詳細に検討し、そ
れぞれのスタイルがどの場合に適しているのかと
いうガイドラインを示します。
IBM SYSTEMS JOURNAL, VOL 41, NO 4, 2002 DB2の連合のスタイル
図2に示すように、DB2の連合化されたアーキテク
チャーでは、単純なスカラーのユーザー定義関数
から、柔軟なDB2ラッパー・アーキテクチャーに
いたるまで、連合の広範な選択肢が提供されます。
図は、連合の度合いと、連合を達成するために要
する労力の間に本質的に存在するトレード・オフ
を示したものです。このセクションでは、ここに
示された範囲の要点について述べ、与えられた統
合シナリオに対して、どのタイプの連合が最適か
を明らかにする決定木を提供します。
スカラー型UDF：関数の連合化 UDFの最も単純
な形はスカラー関数です。この関数は周りにある
SQLステートメントから入力としてデータを取得
し、単一のスカラーの結果を生成します。スカラ
ーUDFはDB2のデータを使って、単一のステート
メントで一方のソースのデータを、もう一方のソ
ースの提供する関数と組み合わせることにより、
関数 を連合化する方法を提供します。UDFはクラ
イアント・アプリケーションに次のような2つの主
要な利益をもたらします。つまり、(1) 単純なプロ
グラミング・モデル、 (2) 呼び出し側アプリケーシ
ョン、データ、関数間のネットワーク・トラフィ
ックとパスの長さを低減することにより得られる
性能の向上の2つです。
例えば、DB2にはユーザー定義関数db2mq.mqsend()が
組み込まれており、これを使用するとユーザーは
MQSeries32のキューにメッセージを送ることができ
ます。例えば以下のように、 SELECT ステートメン
ト内でこの関数を起動することにより、クライア
ント・アプリケーションがキューに直接アクセス
することなく、データベース・テーブルからMQの
キューにデータを移動することができます。
HAAS, LIN, AND ROTH
5
SELECT db2mq.mqsend(a.headline)
FROM Articles a
WHERE a.article_timestamp >= CURRENT TIMESTAMP
図2 連合のいくつかのスタイル
スカラー関数を、エンジンにデータを運ぶ簡単な
方法としても使えます。例えば、 db2mq.mqreceive()
関数は、キューにある次のメッセージを引き出す
のに使用できます。この関数はUDFとして実装さ
れているため、複合照会内で、メッセージを他の
連合データと結合するのに使用できます。
テーブルUDF：データの連合化 テーブル関数は
より高度なUDFであり、出力としてテーブルを生
成し、SQLステートメント内でテーブルを参照で
きる場所ならどこにでも表示可能です。行関数は、
テーブル関数の特殊な場合で1行の値を返します。
テーブル関数では、データの集合を取得して、行
と列に並べ直せるため、外部データを連合化する
簡単な方法として使えます。テーブル関数はテー
ブルを表示できる場所ならどこにでも表示可能な
ため、結果のデータにSQLのすべての機能を適用
できます。さらに、クライアント・アプリケーシ
ョンに対して外部データをより一層ローカル・テ
ーブルのように見せるために、UDFの上にビュー
を作成することができます。
例えば、 addressbook() と呼ばれるテーブル関数は、
営業取引先情報の入ったLotus Notes*データベース
のアドレス帳にアクセスするのに使用できます。
例えば次のように、総収入が5千万ドル以上の金融
会社の営業取引先を返すために、関数呼び出しの
結果と会社概要を含むローカル・テーブルとを結
合する照会内でこの関数を呼び出すことができま
す。
SELECT a.first, a.last, a.phone, a.email
FROM TABLE (addressbook( )) AS a, Company_Profiles c
WHERE c.industry = 'FINANCIAL' AND c.revenue >
50,000,000 AND c.name = a.company_name
テーブル関数はテーブルのように扱えますが、ど
ちらかというと関数に見えます。テーブル関数で
は、返すデータを制限するために引数を取ること
ができます。例えば、ローカル・ディスク上のフ
ァイルに関する情報を得る関数では、第1の引数と
して、検索するディレクトリーを指定する引数、
第2の引数として、対象となるファイル・タイプを
指定する引数などを取ることができます。しかし、
テーブル関数はテーブル関数が扱えるように設計
された述部によってのみフィルター操作ができま
す 。 例 え ば 、 次 に 示 す 照 会 で は 、 dir() 関 数 を
last_modified_dateの列の述部に受け渡すことはできま
せん。
6 HAAS, LIN, AND ROTH
SELECT f.filename, f.author, f.last_modified_date
FROM TABLE (dir('\laura\papers', '.pdf')) AS f
WHERE f.last_modified_date > '07/04/2002'
幸いにも、DB2エンジンはテーブル関数が返す結
果に対し、他のいかなる述部関数でも適用できま
す。この例では、エンジンはテーブル関数の結果
をフィルターにかけて、2002年7月以降に変更され
たものだけを返します。
ラッパー：関数とデータの連合化 ラッパー・ア
ーキテクチャーは連合の最も強力で柔軟なインフ
ラストラクチャーを提供します33。ラッパー・アー
キテクチャーは連合のレベルを単一の関数やデー
タの集合から、全外部データ・ソースのレベルに
引き上げ、関数とデータの両方を統合する方法を
提供します。クライアント・アプリケーションは、
これら外部ソースの管理データに対する照会言語
の全機能を、DB2自体がデータを管理しているか
のように、透過的に使用できます。
例えば、新薬発見の研究所で働く大学の科学者た
ちを考えてみてください。科学者たちは、Oracleデ
ータベースに化合物のデータと実験結果を保存し
ています。大学からは、複数のWeb検索サイトに
ま た が る 検 索 が 可 能 な Web 検 索 エ ン ジ ン Lotus
Extended Search34 （LES）にもアクセスできます。
科学者たちは、他者の研究に関する記事を入手す
るためにこの検索エンジンを使っています。DB2
からラッパーを介せば、Oracleデータベースと検索
エンジンの両方に透過的にアクセスできます。こ
の機能により、科学者たちは両方のソースからの
データと機能を結合する単一の照会を作成できま
す。
IBM SYSTEMS JOURNAL, VOL 41, NO 4, 2002
Oracleラッパーは、Oracleに保存されている化合物
のデータと実験結果のテーブルをニックネームに
マッピングします。このニックネームはSQL照会
内でテーブルを表示できる場所ならどこにでも表
示できます（例えば、 FROM 文節内など）。LESラ
ッパーは、検索可能な記事のリストにニックネー
ムをつけます。各記事には題名、主題、URLがあ
ります。検索機能自体はSQL関数としてマッピン
グされます。SQL関数は、検索する記事のセクシ
ョン（題名、主題、あるいはその両方）とキーワ
ードの集合という2つの引数を取り、記事の適合度
を示す点数を返します。例えば、科学者が日常行
う作業は、実験で一定の結果をもたらした化合物
に関する他の研究レポートを見たいなどというも
のでしょう。それには、次のような照会を用いま
す。
SELECT c.name, a.URL
FROM Compounds c, Experiments e, Articles a
WHERE e.result < 1.1e-9 and e.id = c.id and
search (a.subject, c.name) > 0
Oracle自体もリレーショナル・データベースであり、
DB2オプティマイザーは、「 Experiments 」テーブル
の 述 部 （ e.result < 1.1e-9 ） と 、 「 Compounds 」 と
「 Experiments 」テーブルの結合（ e.id = c.id ）の両方
をOracleデータベースに実行させるためにプッシュ
ダウンするというプランを選択できます。その結
果、該当するテスト結果を持つ化合物だけがDB2
に返されます。その後、DB2は一致した化合物の
名前をLESに転送します。LESは関連する記事を取
得し、そのURLをDB2に返します。
DB2では、多様なリレーショナル・ソースと非リ
レーショナル・ソース18に対するラッパーを用意し
ています。また、サード・パーティー・ベンダー
やお客様が自分のデータ・ソース用にラッパーを
開発する17,19ためのツールキットも提供しています。
ラッパー・ツールキットにはラッパー・アーキテ
クチャーへの外部インターフェースが含まれ、開
発者が新しいタイプのデータ・ソースを連合化で
きるようになっています。ラッパー・アーキテク
チャーにより次のような連合機能が可能となりま
す。
y マルチサーバー統合 UDFと異なり、ラッパー
を使用すると、複数の特定の外部ソースに簡単
にアクセスできます。DB2エンジンは交通巡査
のように動作します。各サーバーの状態情報を
保守し、接続を管理し、照会を各サーバーの扱
える断片に分解し、サーバー間のトランザクシ
ョンを管理します。
y マルチデータ・セット統合とマルチ・オペレー
ション統合 テーブルUDFは単一の外部オペレ
ーションとデータの集合を連合に統合するのに
IBM SYSTEMS JOURNAL, VOL 41, NO 4, 2002 適しています。ラッパー・アーキテクチャーは
複数のデータ・セットと複数のオペレーション
をモデル化するインフラストラクチャーを提供
することにより、この機能を拡張します。デー
タ・セットはニックネームとしてモデル化さ
れ、このニックネームはSQLステートメント内
でテーブルを表示できる場所ならどこにでも表
示できます。オペレーションには、照会、挿
入、更新、削除などがあります。ラッパーはこ
れらのオペレーションの計画と実行に関与し、
また、これらのオペレーションを対応するサー
バーのオペレーションに変換します。
マルチデータ・セットとマルチ・オペレーショ
ン機能により、外部ソースに対する共通照会フ
レームワークという概念が導入されます。共通
照会フレームワークは、ラッパー・アーキテク
チャーを使用して高度な機能目標を達成する方
法です。フレームワークが達成する機能の目標
とは、(1) SQLで表現できる、外部ソースのデー
タに対するオペレーションの全機能、 (2) DB2
がネイティブにはサポートしていないが、外部
ソースがサポートすることにより、照会内で呼
び出せる特殊関数の2つです。
最初の目標は機能補償により達成されます。も
し、外部ソースがDB2のSQLの全機能をサポー
トしていなくとも、クライアント・アプリケー
ションはこれらのデータに対する照会の機能を
失うことは全くありません。なぜならDB2が自
動的に、DB2の機能と、外部ソースの機能の間
の違いを補償するからです。例えば、データ・
ソースが「ORDER BY」をサポートしていない場
合、DB2がソースからデータを取得して、ソー
トを実行します。
第二の目標は機能マッピングにより達成されま
す。機能マッピングを使うと、外部ソースがサ
ポートする機能を、DB2照会言語を通して宣言
することにより公開できます。例えば、化学構
造のストアには構造的に似通った化学物質を見
つける機能があります。この機能はDB2には存
在しませんが、この機能がどのソースに実装さ
れているのかをDB2に対して示すマッピングが
ある限り、DB2の照会でこの機能を利用するこ
とができます。
外部ソースが新しい機能を実装した場合、ラッ
パーそのものを変更する必要はないでしょう。
ただし、これは、データ・ソースやラッパーが
機能をマッピングする際に実行する内容にもよ
ります。新機能を述部において呼び出すソース
の場合は、データベース管理者（DBA）が新し
い機能のマッピングを登録するだけで済みます。
新機能は、DB2照会でただちに使用できるよう
になります。
HAAS, LIN, AND ROTH
7
y 最適化 DB2エンジンの外で実行されるオペレ
ーションには、そのオペレーションが含まれる
照会のコストに大きな影響を与える可能性があ
ります。そして、この照会の実行戦略を選択す
る際には、DB2がこの可能性を認識することが
重要です。ラッパー・アーキテクチャーには、
ラッパーの作成者が、DB2照会オプティマイザ
ーに、外部オペレーションに掛かるコストや返
すデータのサイズに関する情報を入力できる、
柔軟なフレームワークがあります。このフレー
ムワークでは、照会コンパイル時のオプティマ
イザーとラッパーの対話が含まれ、ラッパーの
作成者は照会の即値コンテキストに基づいた情
報を提供することができます。
図3 使用する連合のスタイルの決定
この情報は、オプティマイザーがソース間オペ
レーションの代替案を検討しなければならない
ときに特に重要になります。なぜなら、これら
のタイプのオペレーションでは、可能な実行戦
略の数が爆発的に増加するからです。参考文献
11では、一方がもう一方に比べ、非常にコスト
のかかる、2種類のイメージ検索をサポートす
るイメージ・サーバーの例を紹介しています。
ラッパーがこの情報をDB2オプティマイザーに
渡すことができるため、オプティマイザーは、
他の述部がデータの大半をフィルター操作で取
り除いた後に、コストの掛かるオペレーション
を適用するというプランを選択できます。
y トランザクションの統合 DB2は、外部ソース
に対して実行するオペレーションのトランザク
ション・マネジャーとして動作します。また、
ラッパー・アーキテクチャーは、ラッパーを
DB2トランザクションにおけるリソース・マネ
ジャーとして関与させるインフラストラクチャ
ーを提供します。DB2はトランザクションに関
与したラッパーのリストを管理し、トランザク
ションをコミットしたりロールバックしたりす
る際に、ラッパーに確実に通知するようにして
います。これにより、ラッパーには外部ソース
に対して適切なルーチンを呼び出すタイミング
が与えられます。
使用するデータベース・フェデレーションのスタ
イルの決定 特定の統合に関する課題に対し、ど
のレベルの連合が適切かを決定するには、統合作
業に対して必要な特性と目的を明確にすることが
重要です。UDFは簡単に実装できますが、データ・
モデリングに対しては限られたサポートしか得ら
れず、トランザクションの統合は全くサポートさ
れません。ラッパーは強力ですが、外部ソースの
より高度な機能に依存しており、実装にはより高
度なスキルが要求されます。
8 HAAS, LIN, AND ROTH
アプリケーションは多種多様ですが、異なる連合
の選択肢を使用することにより、どのアプリケー
ションの課題も「わずかなプログラミング」で解
決できます。しかし、ほとんどの場合、ある与え
られた課題に対し1つの選択肢が他の選択肢よりも
適しているというのは事実です。図3に特定の統合
に関する課題に対して、最適な連合のスタイルを
判断する決定木を示します。
決定木は、一連のはい／いいえで答えられる質問
から成ります。質問に「いいえ」と答え続けると
いうことは、統合に関する課題は十分抑えられて
おり、最適のソリューションはおそらくUDFであ
ろうということを示しています。「はい」という
答えの場合は、統合に関する課題はラッパー・ア
ーキテクチャーで扱うのが最適であるという性質
を示しています。決定木は課題の特性に対応する、
ラッパー・アーキテクチャーの機能を指し示して
います。次に、決定木のノードについてより詳し
く見ていくことにします。
1.
統合に関する課題は、複数の同種のデータ・
ソースに対するアクセスを必要とするか？ もしそうなら、そのようなサーバーをモデル
化する利点があるか？
IBM SYSTEMS JOURNAL, VOL 41, NO 4, 2002
もしサーバーの概念が統合に関する課題のキーな
らば、ラッパー・アーキテクチャーが妥当なソリ
ューションです。例えば、オンラインの温度計か
ら温度を取得する機能には、サーバーの概念など
必要ありません。従って、ラッパーによるソリュ
ーションはやり過ぎでしょう。一方、目標が複数
のLotus Notesデータベースの統合である場合を考
えてみましょう。複数のデータベースにアクセス
するUDFを 作成することは可能です。しかし、
UDF開発者には、データベースを引数として認識
するための適切な情報を取得すること、データベ
ースへの接続を管理すること、そして状態に関す
るあらゆる情報を保存するスクラッチパッドを使
用することなどの負荷が掛かります。さらに、そ
のスクラッチパッドの寿命は1ステートメント内の
ため、別のステートメントからのUDFの呼び出し
には独自の接続が必要となります。この統合に関
する課題には、接続管理機能を持つラッパー・ア
ーキテクチャーによる、マルチサーバー・サポー
トを使用すると、これらデータベースに対するア
クセスを適切に管理できるようになります。
2.
統合に関する課題では、トランザクションの
整合性は重要か？
UDFアーキテクチャーでは、トランザクションの
整合性はサポートされませんが、ラッパー・アー
キテクチャーでは1フェーズと、（将来のリリース
で）2フェーズ両方のコミットがサポートされます。
もし、トランザクションの整合性が統合に関する
課題で重要であり、必要なデータや機能を持った
ソースがトランザクションのリソースとして関与
できるなら、このレベルのサポートを提供できる
選択はラッパー・アーキテクチャー以外にありま
せん。
3.
アクセスの対象に、複数の独立したデータ・
セットがあるか？ 連合化の対象に、複数の
独立したオペレーションがあるか？
オペレーションとは、統合しようとするデータに
対して実行できる特定の外部動作です。オペレー
ションの例として、データ取得、検索、挿入、更
新および削除などがあります。テーブルUDFは単
一の外部オペレーションとデータの集合をDB2に
統合するのに適しています。複数のデータ・セッ
トまたは複数のオペレーション（あるいは両方）
を含む場合は、ラッパー・アーキテクチャーを使
うと、これらデータ・セットとオペレーションを
モデル化するインフラストラクチャーを簡単に提
供できます。これは、複数のオペレーションの結
合の仕方に制限がある場合、あるいはコストの予
想が結合の仕方に依存する場合に、特に当てはま
ります。ラッパー・アーキテクチャーを使用する
場合は、データ・セットは異なるニックネームと
なり、柔軟な照会プランニングと照会実行コンポ
ーネントによりラッパー作成者はラッパーがサポ
ートするオペレーションを制御でき、これらのオ
ペレーションをどのように実行するのかを制御で
IBM SYSTEMS JOURNAL, VOL 41, NO 4, 2002 きます。さらに、ラッパー・アーキテクチャーに
はAPI（アプリケーション・プログラミング・イン
ターフェース）が含まれ、ラッパー作成者はオペ
レーションごとに最適化情報を提供できます。ラ
ッパー作成者は、データ・ソースがオペレーショ
ンのどの部分を実行できるのかを判断するため、
実行しようとしているオペレーションを調べるこ
とができます。ラッパーはこの情報について報告
し、オペレーション、パラメーター、システム・
カタログに保存されている固定コスト情報、ラッ
パーに保存されている状態情報に基づき、コスト
とカーディナリティーの推定値を提供します。こ
のコストに関する情報により、DB2オプティマイ
ザーは最適な実行プランを決定できます。
4.
連合オペレーションに高度なコスト・モデル
が付随しているか？
UDFアーキテクチャーも静的なコスト情報の提供
をある程度サポートします。オペレーションが通
常単純な単一のテーブル照会の一部として実行さ
れる場合、テーブル関数が連合の適切な媒介手段
となるでしょう。しかし、もしオペレーションが
より複雑な照会の一部として呼び出されたり、照
会プラン内の位置が照会の性能に大きな影響を与
えそうな場合には、柔軟なコスト・インフラスト
ラクチャーを使用するためだけでも、このオペレ
ーションを連合化するのにラッパー・アーキテク
チャーを使う価値はあります。
上記の質問への回答がすべて「いいえ」だった場
合には、UDFが連合の最適な選択です。この場合、
最後の質問は、統合されたオペレーションがスカ
ラー値を返すか、複数行の集合を返すかというも
のです。オペレーションがスカラー値を返す場合
は、スカラーUDFが正しい選択であり、結果の集
合を返す可能性がある場合は、テーブルUDFが適
切な選択です。
いずれかの質問に対する答えが「はい」の場合は、
ラッパー・アーキテクチャーの少なくとも1つは統
合に関する課題の何らかの側面に対して役立つ機
能を提供できます。従って、その機能を利用する
ためにラッパーの作成を検討してみる価値があり
ます。アーキテクチャーが柔軟に設計されている
ため、ラッパーの重要な部分は、ラッパーを完全
に作成しなくても実装できるということに注目し
てください。例えば、統合しようとする関数が実
際には単純なスカラーUDFでも、トランザクショ
ンの統合がキーとなる場合には、トランザクショ
ンのアーキテクチャーを利用し、データ・モデリ
ングや照会最適化については最低限の実装のみに
する単純なラッパー内にその関数を実装すること
も可能です。一方、データ・ソースに対するオペ
レーションが、コスト面で大きな影響を持つ高度
の読み出し専用関数である場合は、最適化コンポ
ーネントを重視し、トランザクションの機能には
全く触れないラッパーを作成することも可能です。
HAAS, LIN, AND ROTH
9
なぜ、データ・インテグレーションに
データベース・エンジンを使うのか？
データベース・フェデレーションの中心にはリレ
ーショナル・データベース・エンジンがあります。
エンジンはデータを統合するための本質的な構成
要素です。なぜなら、エンジンがアプリケーショ
ン開発者のために抽象度を非常に高めてくれるか
らです。アプリケーション開発者は、個別のソー
スにどのようにして、またどのような順番でアク
セスするかという詳細に関与するかわりに、強力
な非手続型言語、データ保全性のサポート、固定
データやメタ・データが必要になった場合に使用
するローカル・ストア、「一般的」なリレーショ
ナル・システムのために作成済みの多くのツール
やアプリケーションの利用（あるいは再利用）な
どの恩恵を受けられます。このセクションでは、
これらの恩恵についてより詳しく見ていきます。
SQLとリレーショナル・データ・モデルの利点は、
その発明された1960年代後半から1970年代の前半
より、賞賛されてきました35-37。そうした利点の中
でも、最も賞賛されているのは、モデルの単純さ
と言語が非手続型であるということです。この2つ
を併せて、アプリケーション開発者は、 どのよう
なデータが必要で、どのようにして データを見つ
けるかを定義することができるのです。システム
は個々の関連パスを自動的に検出し、所望の結果
を返すために、どのようにしてそれらを結合する
かを決定します。1970年代の後半に照会最適化が
発明され12、システムはいくつかある実行戦略から
的確に最適のものを選択できるようになり、性能
を大幅に向上し、システムが効率的に扱える照会
の範囲を拡大しました。その後、年とともに、言
語は新しい構成により継続的に改善されてきまし
た。いまや、再帰的な照会、統計的解析の実行、
仮想テーブルの即時定義、デフォルトの設定、取
得したデータに基づく動作の分岐などを記述でき
るようになりました38。ユーザー定義関数やストア
ド・プロシージャーにより、アプリケーション・
ロジックの大部分を、最大効率を得るためにデー
タにできる限り近い、データベース内で実行でき
るようになりました。データベース・フェデレー
ションにより、ローカル・ストアに保存されてい
ないデータでもこの利点は得られます。いまや、
分散データを必要とするアプリケーションも、
SQLの全機能を利用して、単一ソース用アプリケ
ーションと同様簡単に作成できます。
リレーショナル・システムのもう1つの基本的な側
面は、システムがデータの完全性を保護するとい
うことです。トランザクションのサポート39は更新
に対して全てかゼロかのセマンティクスを保証し
ます。コミット・プロトコルの分散環境40への拡張
10 HAAS, LIN, AND ROTH
は正しく理解されており、データベース・システ
ムの多くが1フェーズか、2フェーズのコミット・
プロトコルを実装しています。当然これらの機能
により、いくつかのソースからデータを統合する
際に、完全性保証の提供が可能となり、ユーザー
のシステムに対する信頼が築かれることにより、
大きな価値が付加されます。高度な保全性のため
の制約41や、さまざまな制約を強制する積極的メカ
ニズム42も、連合データ間の関係を保護するために
拡張されるでしょう。データ統合エンジンを何か
別のプラットフォーム上に作るとしたら、これら
の事柄をすべてゼロから構築しなければならない
でしょう。
連合データ上のアプリケーションにとり、ローカ
ル・ストアはより重要な支援手段となります。デ
ータを扱ういかなるアプリケーションも、特に多
様なソースからの分散データを扱う場合、使用す
るデータに関する情報を蓄えておく場所を必要と
します。ローカル・ストアは、これらのメタ・デ
ータ（データに関するデータ）の保存に便利な場
所です。このストアや、データに関する基本的な
事実の自動カタログ機能がなければ、アプリケー
ション開発者は手動でこれらの情報を追跡し、そ
の一貫性を保証しなければならないでしょう。ロ
ーカル・ストアの2番目の使用法は、データの実体
化です。データは例えば、照会処理の一部として
一時的に、あるいはより長期的には、短期のキャ
ッシュから恒久的なコピーとして、さらには連合
アプリケーションに固有なデータの長期ストアと
して、実体化する必要があるかもしれません。
実体化ビュー43はローカル・ストアを使用するSQL
の高度な機能です。本来は、複数の照会に対する
大容量のデータを集約するコスト低減の方法とし
て考え出され、実体化ビュー（DB2では自動サマ
リー・テーブル、あるいはASTと呼ばれる）によ
り、照会結果の保存版が作成されます。ASTの定
義に一致する新規照会が発生すると、再計算せず
に、保存されている結果に自動的に「転送」しま
す44。ビューの定義が外部データを参照できる場合
には、連合化されたソースのデータからも保存版
サマリーを作成できます。照会プランニング中に
サマリー・テーブルを検討する際、DB2はローカ
ル・サマリー・テーブルから直接データを取り出
すコストと、リモート照会を再計算するコストを
比較して、コストの小さい戦略を選択します。こ
れは、データベース・フェデレーションにおいて
は簡単で自然な動作ですが、他の統合化アプロー
チでこれを真似しようとすると多大の努力を要す
るでしょう。なぜなら、この機能はデータベース・
エンジンのアプローチの複数の機能に大きく依存
するからです。
IBM SYSTEMS JOURNAL, VOL 41, NO 4, 2002
図4 リレーショナル・データベースを含むDB2データベース・フェデレーション
データベース・エンジンをデータの統合に使う意
味として、最後に決して忘れてならないのが、リ
レーショナル・データベースのために数年来開発
されてきた、全てではないにしろ多くのツールや
アプリケーションを変更せずに分散データに対し
て使用できるということです。例えば、Cognos45や
Brio46 の よ う な 照 会 ビ ル ダ ー 、 IBM
WebSphere*Studio47 、 IBM VisualAge*48 や Microsoft
Visual C++**49 、WebGain VisualCafe**50 のようなア
プリケーション開発環境、あるいはレポート・ジ
ェネレーターやビジュアル化ツールなどです。同
様に、お客様も単一データベース用のアプリケー
ションを開発済みかもしれません。これらのアプ
リケーションは、ローカル・テーブルの名前をリ
モート・テーブルの名前に置き換えたり、リモー
ト・データを利用するためにビューの定義を変更
したりするだけで、連合環境内で簡単に再利用で
きます。
要するに、標準のリレーショナル・データベース・
システムに提供される利点の多くは、データベー
ス・フェデレーションでも同様に得られるという
ことです。データベース・フェデレーションのア
プローチは、データ・インテグレーションの作業
に対して豊かなサポート環境を提供します。次の
セクションでは、いくつかの代表的な利用シナリ
オを通して、これらの利点のいくつかについて説
明します。
DB2連合の利用シナリオ
このセクションでは、どのようにしてデータベー
ス・フェデレーションを多様なソースからのロー
カル・データとリモート・データの統合に使える
のかを示す、いくつかのシナリオを示します。ソ
ースとしては、リレーショナル・データ、
IBM SYSTEMS JOURNAL, VOL 41, NO 4, 2002 Microsoft Excelのスプレッドシート、XML文書、
Webサービス、メッセージ・キューなどを取り上
げます。さらに、これらのシナリオにより、デー
タベースを統合エンジンとして使用することによ
り、ビジネス・アプリケーションが連合データ上
のSQLの全機能を利用できるということを示しま
す。機能としては、複合照会と複合ビュー、自動
サ マ リ ー ・ テ ー ブ ル 、 OLAP （ On-line Analytical
Processing）機能、DB2 Spatial Extender、複製、キ
ャッシングなどを取り上げます。
分散データの連合化 全国規模のデパート・チェ
ーンが国内のいくつかの地域に店舗を持っていま
す。各店舗は、在庫記録や顧客取引の管理をリレ
ーショナル・データベースに依存しています。し
かし、デパートはいくつかの技術革新を行ってき
ているため、すべての店舗が同じデータベース製
品を使っているわけではありません。サンフラン
シスコ店とニューヨーク店は、いずれも業務取引
の記録をOracleデータベースで行っています。一方、
本社は最近DB2に移行しました。
各店舗はTransactionsテーブルを管理しており、それ
には顧客取引時にスキャンされた各商品のエント
リーが保存されています。各店舗は、このテーブ
ルの情報を元に、店舗単位の売り上げレポートを
簡単に作成できます。図4は、本社オフィスが、ど
のようにして 全 店舗にまたがる売り上げレポート
の作成に、DB2技術を使えるかを示したものです。
サンフランシスコ店とニューヨーク店はいずれも
Oracleを使用しているため、本社はDB2とともに提
供されるOracleラッパーにより、両店舗のデータベ
ースにアクセスできます。同様に、本社は他の店
舗のデータベースにも、それぞれのデータベース
に適したラッパーによりアクセスできます。各店
舗から同じ情報を引き出すように照会を定式化で
HAAS, LIN, AND ROTH
11
きる限り、各データベースのスキーマは同一であ
る必要はないことに注意してください。
各店舗のデータベースは、本社のデータベースに
サーバーとして登録され、本社がアクセスするテ
ーブルは、ニックネームとして登録されます。例
えば、各店舗のTransactionsテーブルがニックネーム
として登録されます。ニックネームが登録された
ら、全社にわたる取引を表示する連合ビューは次
のように定義されます。
CREATE VIEW National_Transactions (store_id, tran_date,
tran_id, item_id) AS
SELECT store_id, tran_date, tran_id , item_id
FROM sf.Transactions
UNION ALL
SELECT store_id, tran_date, tran_id , item_id
FROM ny.Transactions
デパート・チェーンにさらに店舗が追加されても、
本社はビジネス・アプリケーションを変更する必
要がないということに注目してください。そのか
わり、 National_Transactions ビュー定義を、新店舗の
情報が含まれるように更新します。このビューが
あれば、本社は社内の全店舗における1カ月当たり
の売り上げ商品数の合計を示す全国売り上げレポ
ートを生成する単一照会を、次のようにして実行
できます。
SELECT MONTH(tran_date), item_id, COUNT(*)
FROM National_Transactions
WHERE YEAR(tran_date)-2001
GROUP BY MONTH(tran_date), item_id
さらに本社は、変更の可能性の少ない前年の取引
情報を、ローカルにキャッシュするために連合ビ
ュー上に自動サマリー・テーブルとして作成でき
ます。この実体化ビュー作成に、次のステートメ
ントを使用できます。
CREATE TABLE Past_Sales AS (
SELECT YEAR(tran_date) AS year, MONTH(tran_date) AS
month, item_id, COUNT(*) AS sales
FROM National_Transactions
WHERE YEAR(tran_date) < = 2001
GROUP BY YEAR(tran_date), MONTH(tran_date), item_id)
DATA INITIALLY DEFERRED REFRESH DEFERRED
Past_Salesサマリー・テーブルがローカルに保存され
た結果、テーブルに対するインデックスを作成で
き、照会の性能を向上するための統計情報を収集
できるようになります。さらに、与えられた照会
が（リモートの）ニックネームに対してではなく、
（ローカルの）サマリー・テーブルに対して実行
できないかを、自動的にDB2に確認させる特別な
12 HAAS, LIN, AND ROTH
レジスターをセットできます。その場合、DB2は、
情報を取得して結果を計算するためのリモート要
求を各地域店舗に送信するプランに加え、Past_Sales
サマリー・テーブルから直接情報を抽出するプラ
ンも検討します。この解析は透過的に行われ、元
の照会を変更する必要はありません。
非リレーショナル構造化データの連合化 図5は、
デパート・チェーンの本社が、非リレーショナル・
データ・ソースにも同様にアクセスするのに、
DB2データベース・フェデレーションをどのよう
に使えるかを示したものです。例えば、調達部署
が2001年度のベスト・セラー・テレビのメーカー
と供給元を知りたいとします。商品と供給元の情
報はExcelのスプレッドシートに保存されており、
DB2からExcelラッパーを使ってアクセスできます。
商品のスプレッドシートは Items ニックネームにマ
ッピングされ、供給元のスプレッドシートは
Suppliersニックネームとしてマッピングされます。
スプレッドシートに含まれるデータは次に示す
SQLを使用して取得できます。
SELECT i.mfg, s.id
FROM Items i, Suppliers s
WHERE i.id = s.id AND i.id = (SELECT g.id
FROM (SELECT g.id, COUNT(*), ROWNUMBER( )
OVER (ORDER BY COUNT(*) DESC) AS rownum
FROM National_Transactions g, Items it
WHERE it.cat='television' AND g.id = it.id AND
YEAR(tran_date) = 200 1
GROUP BY g.id) AS tv_total_2001
WHERE rownum = 1)
上記の照会では、 COUNT(*) の結果を、2001年度の
テレビの全モデル別売り上げの全国合計に従い降
順に並べ替えるのに、OLAPのROWNUMBER関数
が使われています。そして、最もよく売れたテレ
ビの識別子（ID）を見つけるために第1行が選択さ
れます。この例は、DB2データベース・フェデレ
ーション技術を使うことにより、データが各拠点
で異なる方法で保存され、あるいは表現されてい
ても、本社は単一の（複合）SQLステートメント
を使って、店舗間と本社の情報を相関させること
ができるということを示しています。
半構造化データの連合化 このデパート・チェー
ンは、お客様用のオンライン・ショッピングも提
供しています。顧客データは本社にあるデータベ
ース内のCustomersテーブルに保存されており、注文
はWebアプリケーションによってXML文書として
生 成 さ れ ま す 。 こ れ ら の XML 文 書 も DB2 Life
Sciences Data Connect31 に添付されているXMLラッ
パーを使って本社データベースからアクセスでき
ます。
IBM SYSTEMS JOURNAL, VOL 41, NO 4, 2002
図5 リレーショナルと、非リレーショナル・データ・ソースを含むDB2データベース
XML文書はニックネームにマッピングされ、XML
文書の要素はニックネームの列にマッピングされ
ます。単一XML文書の複数のニックネームへのマ
ッピングも可能です。ニックネームに付属するオ
プションにより、照会内でXML文書の位置を特定
できます。ニックネーム列定義に関するXPATHオ
プションで、ニックネーム列をXML文書内の列の
位置にマッピングします。例えば、注文文書は注
文と商品の両方の情報を含みます。その結果、文
書はOrdersニックネームとOrder_itemsニックネームに
マッピングされ、特定の注文からの商品を含む照
会はこれら2つのニックネームの結合として表現で
きます。
注文処理の一部として、Webアプリケーションは
顧客に最も近い配送センターを決定して、注文を
手配しなければなりません。本社は以下に示すよ
うに、各配送センターの地理的位置情報付きの所
在地を Distribution_Centers テーブルに保存し、顧客の
住 所 に 地 理 的 位 置 情 報 を 付 け 、 DB2 Spatial
Extender関数 db2gse.st_distance( ) を用いて顧客に最も
近い配送センターを見つけます。
SELECT s.store_id, db2gse.st_distance(GEOCODE(o.street,
o.city,o.state,o.zip), s.location, 'mile') AS distance
FROM Distribution_Centers s, Orders o
WHERE o.order = '/home/customers/order5795.xml' AND
o.transaction_id = '12AV56BG90'
ORDER BY distance
Webサービスの連合化 小規模の家具会社が、全
IBM SYSTEMS JOURNAL, VOL 41, NO 4, 2002 国に広がるいくつかの小売店にその製品を卸して
います。小売店はWebアプリケーションを通して
家具を発注し、家具会社は注文を処理し、家具を
小売店に発送します。配送が生産コストのかなり
の比率を占めるため、家具会社はいくつかの配送
会社と契約を結び、それぞれの配送を入札に付し
ています。図6は、注文処理システムとしてDB2を
使ったシステム構成を示したものです。新規注文
はMQシリーズのキューに置かれます。バックエン
ドの注文処理システムがキューから注文を取り出
し、配送に対して各社からの入札を要請します。
注文処理システムは、現在処理中の注文のリスト
をPending_Ordersテーブルを使用し管理します。各注
文には、自動生成された固有の注文番号とに注文
情報を含むXML文書が割り当てられます。家具会
社は、配送の入札を要請するための、一般的な
Webサービス・インターフェースをサポートする、
社内用の配送会社のUDDIレジストリーを管理して
います。このレジストリーはラッパーを通して注
文処理システムからアクセスでき、ラッパーのサ
ポートする Freight_Shippers ニックネームが入札Web
サービスに対応している配送会社のURLと名前を
出力します。 bid() と呼ばれるUDFが、配送会社の
URLと注文のXML記述を取り込み、URLで指定さ
れた会社から注文に対する入札価格を取得するよ
うにWebサービスに対して要求を送信し、入札価
格を返します。Bidsテーブルには、注文番号、入札
に応じた配送会社名、入札そのものを含む、注文
に対して得られた入札のリストが保存されます。
HAAS, LIN, AND ROTH
13
図6 Webサービスとその他のソースを含むDB2データベース・フェデレーション
家具会社は、注文プロセスの多くの部分をDB2の
連合機能を使って自動化できます。例えば、次に
示すステートメントを使えば、注文をMQシリーズ
のキューから取り出し (UDFのdb2mq.mqreceive( )を
通して）、これに固有の注文番号を割り振り、
Pending_Ordersテーブルに挿入することができます。
INSERT INTO Pending_Orders
VALUES(GENERATE_UNIQUE( ), db2mq.mqreceive( ))
さらに、Pending_Ordersテーブルで定義されたトリガ
ーにより、新しい注文がテーブルに挿入されたと
きに、自動的に入札プロセスを起動できます。
CREATE TRIGGER Get.Bids
AFTER INSERT ON Pending_Orders
REFERENCING NEW AS order
FOR EACH ROW MODE DB2SQL
INSERT INTO Bids
SELECT Order.ordernum, s.name, bid(s.url, order.orderxml)
FROM Freight_Shippers S
このSQLステートメントは、データの統合に対す
るデータベース・フェデレーション・ソリューシ
ョンの高い能力を示しています。単純な挿入ステ
ートメントが、ユーザー定義関数（db2mq.mqreceive()
とbid()）とラッパーによる連合（Freight_Shippersニッ
クネーム）を介して透過的に結合された連合デー
タ上で実行されるトリガーを生成しています。
14 HAAS, LIN, AND ROTH
データベース・フェデレーションを使った異種複
製 企業の多くは、データウェアハウス、耐障害
性、フェイルオーバー・シナリオなどの種々の用
途に向けて、データのコピーを複数持っています。
アメリカ全国に系列小売店のある大手小売業者が、
各々の場所からのデータを地域データ・センター
でバックアップしています。独立した購入判断に
より、小売店はあるリレーションナル・データベ
ース管理システムを利用する一方、データ・セン
ターは別のシステムを使用することもあります。
複製プロセスは比較的すっきりしたもので、小売
店のデータベースからデータを取り出し、場合に
よっては加工か集計、あるいはその両方を行い、
データ・センターのデータベースに挿入します。
図7は、小売店からデータ・センターへデータを転
送する際の抽出／変形の手段としてDB2技術を使
用する2つのアプローチを示したものです。図7の
アプローチ1は、データ・センターがDB2データベ
ースを使用している場合、データ転送は次の形の
単純なステートメントで実行できることを示して
います。
IBM SYSTEMS JOURNAL, VOL 41, NO 4, 2002
図7 データベース・フェデレーションによる異種複製
I NSERT INTO <data center local_table>
SELECT...FROM <outlet nickname>....
図7のアプローチ2は、たとえデータ・センターが
他のリレーショナル・データベース製品を使用し
ていても、同じ INSERT ステートメントをデータベ
ースの配置に使用できることを示しています。違
いは、連合データベースではニックネームに対し
てデータを挿入するということだけです。
INSERT INTO <data center nickname>
SELECT , , , FROM <outlet nickname>....
どちらのアプローチを使用しても、 SELECT ステー
トメントは任意に複合化でき、アプリケーション
の構文に従って、データの選択的な取得、変形、
集計などに使用できることに注目してください。
DB2 DataPropagator*51は、DB2連合技術をデータの
複製に利用したIBMの製品です。DataPropagatorは
リモート・システム間のデータのコピーを自動化
し、自動変更伝搬、柔軟なスケジューリング、そ
の他のカスタマイズ機能を提供します。
DataPropagatorは上で示したリモート挿入／更新／
削除機能を使用して、非DB2ソースを含む全ての
リレーショナル・ソースを透過的に変更します。
動的データ・キャッシング。図8に示すように、典
型的なe-commerce WebアプリケーションはWebサ
ーバー層、アプリケーション・サーバー層、デー
タ層という3層構造を持っています。ユーザーの要
求は複数のWebサーバーの1つに転送され、Webサ
ーバーは処理のためにアプリケーション・サーバ
ーの1つにユーザーの要求を転送します。次いで、
アプリケーション・サーバーが単一のバックエン
ド・データベースから製品データを取り出し、注
文情報をそのバックエンド・データベースに挿入
します。
IBM SYSTEMS JOURNAL, VOL 41, NO 4, 2002 トラフィックが増加すると、バックエンド・デー
タベースがすぐにボトルネックになるということ
は、図から見ても明らかです。DBCACHE52, 53 はデ
ータ層の拡張容易性を提供する連合技術により構
築された研究用の試作品です。各アプリケーショ
ン・サーバーのノードにはフロントエンド・デー
タベース・サーバー、すなわちDBCACHEという
「キャッシュ」を設置できます。DBCACHEによっ
て、データベース管理者はバックエンド・データ
ベースの一部を複数のフロントエンド・データベ
ースに複製し、クライアントの要求がフロントエ
ンド・データベースに転送されるようにすること
ができます。このトポロジーは巨大な単一パラレ
ル・システムに比べて安価であり、耐障害性レイ
ヤーも提供します。1つのデータベースがクラッシ
ュしても、データベース全体が動作不能になるこ
とはありません。
図9に、DBCACHE技術を用いた、e-commerceアプ
リケーションを示します。アプリケーション・テ
ーブルは、キャッシュ付きとキャッシュなしとい
う2つのカテゴリーに分けられます。キャッシュ付
きテーブルはほとんどが読み出し専用で、複数の
ユーザーがアクセスします。この種のテーブルで
は、厳密な一貫性の管理は必要でなく、失効した
データの読み出しも許容できます。オンライン・
ショップのお客様から見れば、製品カタログのデ
ータは読み出し専用です（例えば、図9の照会Q1）。
更新は頻繁に起こるわけではなく、たいてい計画
された展開シナリオに沿って行われます（決して、
オンライン・ショップのお客様が行うことはあり
ません）。また、お客様が数秒古い製品情報を見
たからといって、重大なロスになるわけでもあり
ません。さらに、全てのお客様は購入前に製品カ
タログを参照するので、製品カタログは頻繁にア
クセスされます。
HAAS, LIN, AND ROTH
15
図8 e-commerceアプリケーションの3層アーキテクチャー
キャッシュなしテーブルは通常読み出し／書き込
み可能です。これらのテーブルでは、厳密な一貫
性管理が重要であり、失効したデータに対するア
クセスは許容できません。キャッシュなしテーブ
ルに保存されるデータの例としては注文情報が挙
げられます。 お客様から見れば、注文情報はほと
んど書き込み専用です（例えば、図9の照会Q2）。
この情報は、オンライン注文処理の一部として捉
えられ、バックエンドの注文処理アプリケーショ
ンと注文状況を確認したいお客様だけが読み出し
ます。注文は金銭授受につながるため、データの
正確なビューを提供することが重要です。
図9に示すように、Productsバックエンド・テーブル
はDataPropagator（図9のData Prop）により、DBA
の定義するスケジュールに従い、自動的に複数の
フロントエンドにまたがるキャッシュ付きテーブ
ルに複製されます。 Productsテーブルの読み出しは
透過的にフロントエンド・データベースの1つに転
送される一方、書き込み（もし発生した場合）は
バックエンド・データベースに直接転送されます。
Ordersバックエンド・テーブルはフロントエンド・
データベース内ではニックネームとして表現され、
読み出しと書き込みはいずれもDB2連合技術を用
いてバックエンド・データベースに渡されます。
クライアント・アプリケーションはデータの単一
ビューを参照します。製品情報に対する照会（図9
の照会Q1）をフロントエンド・データベースのキ
ャッシュ付きテーブルのうちの1つに動的に転送す
ることにより、これら頻繁にアクセスされるデー
タに、負荷の平準化と耐障害性を提供します。
16 HAAS, LIN, AND ROTH
Orders テーブルへの挿入ステートメント（図9の照
会Q2）は、直接バックエンド・テーブルに転送さ
れます。ステートメントは、キャッシュ付きとキ
ャッシュなしの両テーブルにまたがることができ
ます。例えば、注文状況を確認する照会（図9の照
会Q3）は、Ordersニックネームからの情報をProducts
テーブルと結合できます。
結論
本稿では、データベース・フェデレーションがデ
ータを統合する強力なツールであることを示して
きました。データベース・フェデレーションはデ
ータベース・エンジンを利用して、いくつかの、
おそらくは多数の、異種で分散したデータ・スト
アから仮想データベースを作成します。本稿では
データベース・フェデレーションの3つのスタイル
を明らかにしました。それらの全てで、データベ
ース・エンジンは主要な駆動力となりますが、デ
ータや機能を連合に取り込む方法はそれぞれ異な
ります。連合の各スタイルをどのようなときに使
用するべきかについては、以下のようなガイドラ
インを示しました。すなわち、ユーザー定義関数
は比較的単純な統合作業に最適であり、一方ラッ
パー・アーキテクチャーはより広範で複雑な作業
をサポートします。データベース技術がなぜこれ
ほどデータ・インテグレーションにとって重要な
のか、また、いかに多くのリレーショナル・デー
タベースの機能が分散環境に応用でき、複数のデ
ータ・ソースにまたがる新規アプリケーションの
開発を簡単にするのかを述べました。最後に、多
くの適用事例を通じて、どのようにしてビュー、
IBM SYSTEMS JOURNAL, VOL 41, NO 4, 2002
図9 DBCACHEを用いたe-commerceアプリケーション
AST、OLAP機能、結合、合併、集約などの広範な
デ ー タ ベ ー ス 機 能 を 、 MQ キ ュ ー 、 XML 文 書 、
Excelスプレッドシート、Webサービス、リレーシ
ョナル・データベース管理システムなど多様なソ
ースからのデータを統合する複数の連合スタイル
とともに利用するのかを示しました。連合がどの
ようにして、レポート収集、ウェアハウス・ロー
ディングと複製、さらにはキャッシングといった
機能の基礎になりうるのかを示しました。この技
術の応用の多様性は、データの統合されるべき方
法の多様性を反映したものであり、広範な課題に
対するデータベース・フェデレーションの適応性
はデータ・インテグレーションにおけるその重要
性を示すものです。
もちろん、データベース・フェデレーションは万
能薬ではありません。ある種の統合シナリオでは、
データベース・フェデレーションは行き過ぎとな
るかもしれません。あるいは、データ・インテグ
レーションの種々のアプローチのうち別のアプロ
ーチの方がより簡単ということもあるでしょう。
しかし、私たちはデータベース・フェデレーショ
ンが全ての統合ソリューションの基礎になると固
IBM SYSTEMS JOURNAL, VOL 41, NO 4, 2002 く信じています。将来の努力目標はこの技術の使
いやすさの向上です。堅牢で効率的なラッパーを、
素早く最小の労力で開発できるツールが必要でし
ょう。照会の最適化やオプティマイザーが使える
実行戦略などを改良し、システムの性能向上を続
けます。現代におけるさらなる課題としては、す
べての場所で非同時性を扱えるようにすること、
XML機能のより優れた統合、XML照会に対してネ
イティブ・サポートを取り込むことなどが挙げら
れます。お客様が技術を実際に使用するうちに、
セマンティック・メタ・データのより充実したサ
ポートと連合システムの管理をさらに自動化する
ことが役立つということが分かってきました。こ
のような強化により、データベース・フェデレー
ションがデータ・インテグレーションの土台とし
て広く認められるようになるものと期待していま
す。
*International Business Machines Corporation の 商 標 ま
たは登録商標
**Object Management Group、Sun Microsystems, Inc.、
Microsoft Corporation、WebGain, Inc.の商標または登録
商標
HAAS, LIN, AND ROTH
17
Principles," Proceedings of the 1993 ACM SIGMOD
International Conference on Management of Data,
本文中で参照された参考文献
1.
2.
3.
4.
5.
6.
7.
8.
Documentum, Inc., Content Management:
Documentum
Products,
http://www.documentum.com/
content-management_Products.html.
IBM Corporation, Content Manager,
http://www.ibm.com/software/data/cm/.
M. A. Roth, D. C. Wolfson, J. C. Kleewein, and C. J.
Nelin, "Information Integration: ANew Generation of
Information Technology," IBM Systems Journal 41,
No. 4, 563-577 (2002, this issue).
IBM Corporation, WebSphere Application Server,
http://www.3.ibm.com/software/webservers/appserv/
enterprise.html.
LION Bioscience AG, LION DiscoveryCenter,
http://www.lionbioscience.com/solutions/
discoverycenter/.
middleAware.com, Component Focus,
http://www.middleware.net/components/index.html.
F. Leymann and D. Roller, "Using Flows in
Information Integration," IBM Systems Journal 41,
No. 4, 732-742 (2002, this issue).
M. Roscheisen, M. Baldonado, C. Chang, L. Gravano,
S. Ketchpel, and A. Paepcke, "The Stanford InfoBus
and Its Service Layers: Augmenting the Internet with
Higher-Level Information Management Protocols,"
Digital Libraries in Computer Science: The MeDoc
Approach, Lecture Notes in Computer Science, No.
1392, Springer, New York (1998), pp. 213-230.
9. IBM Corporation, Enterprise Information Portal,
http://www-3.ibm.com/software/data/eip.
10. H. Pirahesh, J. Hellerstein, and W. Hasan,
"Extensible Rule-Based Query Rewrite Optimization
in Starburst," Proceedings of the 1992 ACM SIGMOD
International Conference on Management of Data,
San Diego, CA, June 2-5, 1992, ACM, New York
(1992), pp. 39-48.
11. M. Tork Roth, F. Ozcan, and L. Haas, "Cost Models
DOMatter: Providing Cost Information for Diverse
Data Sources in a Federated System," Proceedings of
the Conference on Very Large Data Bases (VLDB),
Edinburgh, Scotland, September 1999, Morgan
Kaufmann Publishers, San Mateo, CA(1999), pp.
599-610.
12. P. Selinger, M. Astrahan, D. Chamberlin, R. Lorie,
and T. Price, "Access Path Selection in a Relational
Database Management System," Proceedings of the
1979 ACMSIGMOD International Conference on
Management of Data, Boston, MA, 1979, ACM, New
York (1979), pp. 23-34.
13. H. Garcia-Molina, J. Hammer, K. Ireland, Y.
Papakon-stantinou, J. Ullman, and J. Widom,
"Integrating
and
Accessing
Heterogeneous
Information Sources in TSIMMIS," Proceedings of
the AAAI Symposium on Information Gathering,
Stanford, CA, March 1995, AAAI Press (1995), pp.
61-64.
14. S. Adali, K. Candan, Y. Papakonstantinou, and V. S.
Sub-rahmanian, "Query Caching and Optimization in
Distributed Mediator Systems," Proceedings of the
ACM SIGMOD Conference on Management of Data,
Montreal, Canada, June 1996, ACM, New York
(1996), pp. 137-148.
15. A. Tomasic, L. Raschid, and P. Valduriez, "Scaling
Heterogeneous Databases and the Design of DISCO,"
Proceedings of the 16th International Conference on
Distributed Computer Systems, May 1996, Hong
Kong, IEEE, New York (1996), pp. 449-457.
16. M.-C. Shan, "Pegasus Architecture and Design
18 HAAS, LIN, AND ROTH
Washington, D.C., May 1993, ACM, New York
(1993), pp. 422-425.
17. M. Tork Roth, P. Schwarz, and L. Haas, "An
Architecture for Transparent Access to Diverse Data
Sources," Component Database Systems, K. R.
Dittrich, A. Geppert, Editors, Morgan-Kaufmann
Publishers, San Mateo, CA (2001), pp. 175-206.
18. IBM Corporation, DB2 Product Family,
http://www-3.ibm.com/software/data/db2/.
19. M. Tork Roth and P. Schwarz, "Don't Scrap It, Wrap
It! A Wrapper Architecture for Legacy Data Sources,"
Proceedings of the Conference on Very Large Data
Bases (VLDB), Athens, Greece, August 1997, Morgan
Kaufmann Publishers, San Mateo, CA (1997), pp.
266-275.
20. L. Haas, D. Kossmann, E. Wimmers, and J. Yang,
"Optimizing Queries Across Diverse Data Sources,"
Proceedings of the Conference on Very Large Data
Bases (VLDB), Athens, Greece, August 1997, Morgan
21.
22.
23.
24.
25.
26.
Kaufmann Publishers, San Mateo, CA (1997), pp.
276-285.
iWay Software, iWay Adapters and Connectors,
http://www.iwaysoftware.com/products/e2e_integrati
on_products.html.
Microsoft Corporation, Microsoft ODBC,
http://www.microsoft.com/data/odbc/.
IBM Corporation, DataJoiner,
http://www.software.ibm.com/data/datajoiner/.
Microsoft Corporation, Access 2002 Product Guide,
http://www.microsoft.com/office/access/default.asp.
IBM Corporation, DB2 Relational Connect,
http://www-3.ibm.com/software/data/db2/relconnect
/.
B. Reinwald, H. Pirahesh, G. Krishnamoorthy, G.
Lapis, B. Tran, and S. Vora, "Heterogeneous Query
Processing Through SQL Table Functions,"
Proceedings of the 15th International Conference on
Data Engineering, March 1999, Sidney, Australia,
IEEE, New York (1999), pp. 366-373.
27. L. M. Haas, P. M. Schwarz, P. Kodali, E. Kotlar, J. E.
Rice, and W. C. Swope, "DiscoveryLink: A System for
Integrated Access to Life Sciences Data Sources,"
IBM Systems Journal 40, No. 2, 489-511 (2001),
http://www.research.ibm.com/journal/sj/402/haas.ht
ml.
28. ISO/IEC 9075-2:2000, Information technology
-Database languages-SQL-Part 2: Foundation
(SQL/Foundation), International Organization for
Standardization, Geneva, Switzerland (2000).
29. ISO/IEC 9075-9:2000, Information technology
-Database languages-SQL-Part 9: Management of
External
Data
(SQL/MED),
International
Organization
for
Standardization,
Geneva,
Switzerland (2000).
30. L. Haas, J. Freytag, G. Lohman, and H. Pirahesh,
"Extensible Query Processing in Starburst,"
Proceedings of the 1989 ACM SIGMOD International
Conference on Management of Data, Portland, OR,
May 31-June 2, 1989, ACM, New York (1989), pp.
377-388.
31. IBM Corporation, DB2 Life Sciences Data Connect,
http://www-3.ibm.com/software/data/db2/lifescience
sdataconnect/.
32. IBM Corporation, IBM MQSeries Integrator V2.0:
The
Next
Generation
Message
Broker,
http://www-3.ibm.com/software/ts/mqseries/library/
whitepapers/mqintegrator/msgbrokers.html.
33. V. Josifovski, P. Schwarz, L. Haas, and E. Lin,
IBM SYSTEMS JOURNAL, VOL 41, NO 4, 2002
34.
35.
36.
37.
38.
39.
40.
"Garlic: A New Flavor of Federated Query Processing
for DB2," Proceedings of the ACM SIGMOD
Conference on Management of Data, Madison, WI,
June 2002, ACM, New York (2002).
IBM Corporation, Lotus Extended Search,
http://www.lotus.com/products/des.nsf/wdocs/home.
E. F. Codd, "A Relational Model of Data for Large
Shared Data Banks," Communications of the ACM
13, No. 6, 377-387 (June 1970).
E. F. Codd, The Relational Model for Database
Management, Version 2, Addison-Wesley Publishing
Co., Reading, MA (1990).
C. J. Date and H. Darwen, A Guide to SQL Standard,
4th Edition, Addison-Wesley Publishing Co.,
Reading, MA (1997).
D. Chamberlin, A Complete Guide to DB2 Universal
Database, Morgan Kaufmann Publishers, San Mateo,
CA (1998).
J. Gray and A. Reuter, Transaction Processing:
Concepts and Techniques, Morgan Kaufmann
Publishers, San Mateo, CA (1993).
I. Traiger, J. Gray, C. Galtieli, and B. Lindsay,
Transactions and Consistency in Distributed
Database Systems, Research Report RJ2555, IBM
Almaden Research Center, San Jose, CA 95120
(1979).
41. M. Stonebraker, "Implementation of Integrity
Constraints and Views by Query Modification,"
Proceedings of the 1975 ACM SIGMOD Conference
on Management of Data, ACM, New York (1975), pp.
65-78.
42. Rules in Database Systems, T. K. Sellis, Editor,
Applications," Proceedings of the 27th International
Conference on Very Large Data Bases, September
11-14, 2001, Roma, Italy, Morgan Kaufmann
Publishers, San Mateo, CA (2001).
53. Q. Luo, S. Krishnamurthy, C. Mohan, H. Pirahesh, H.
Woo, B. Lindsay, and J. Naughton, "Middle-Tier
Database Caching for e-Business," Proceedings of the
ACM SIGMOD Conference on Management of Data,
Madison, WI, June 2002, ACM, New York (2002).
Accepted for publication July 22, 2002.
Laura M. Haas IBM Software Group, Silicon Valley
Laboratory, 555 Bailey Avenue, San Jose, California
95141 (electronic mail: [email protected]). Dr. Haas
is a Distinguished Engineer and senior manager in the
IBM Software Group, where she is responsible for the
DB2 Query Compiler development, including key
technologies for DiscoveryLink TM and Xperanto. Dr.
Haas, who joined the IBM Almaden Research Center in
1981, has made significant contributions to database
research and has led several research projects,
including R*, Starburst, and Garlic. She has received
an IBM Outstanding Technical Achievement Award for
her work on R* and DiscoveryLink, an IBM
Outstanding Contribution Award for Starburst, a
YWCA Tribute to Women in Industry (TWIN) Award,
and an ACM SIGMOD Outstanding Contribution
Award.
Proceedings of the Second International Workshop
(RIDS '95), Glyfada, Athens, Greece, September
25-27, 1995, Lecture Notes in Computer Science, No.
985, Springer, New York (1995).
43. D. Srivastava, S. Dar, H. V. Jagadish, and A. Levy,
"Answering Queries with Aggregation Using Views,"
Proceedings of the 22nd International Conference on
Very Large Data Bases (VLDB '96), Morgan
Kaufmann Publishers, San Mateo, CA (1996), pp.
318-329.
44. M. Zaharioudakis, R. Cochrane, G. Lapis, H.
Pirahesh, and M. Urata, "Answering Complex SQL
Queries Using Automatic Summary Tables,"
Proceedings of the 2000 ACM SIG-MODInternational
Conference on Management of Data, ACM, New York
(2000), pp. 105-116.
45. Cognos Incorporated, Business Intelligence Products,
http://www.cognos.com/products/index.html.
46. Brio Software, Inc., Business Intelligence solution for
data query and analysis,
http://www.brio.com/products/overview.html.
47. IBM Corporation, WebSphere Studio Application
Developer,
http://www-3.ibm.com/software/ad/studioappdev/.
48. IBM Corporation, VisualAge C++,
http://www-3.ibm.com/software/ad/vacpp/.
49. Microsoft Corporation, Visual C++ .NET,
http://msdn.microsoft.com/visualc/.
50. WebGain, Inc., Visual Cafe´,
http://www.webgain.com/products/visual_cafe/.
51. IBM Corporation, DB2 Universal Database, DB2 Data
Propagator,
http://www-3.ibm.com/software/data/dpropr/.
52. C. Mohan, "Caching Technologies for Web
IBM SYSTEMS JOURNAL, VOL 41, NO 4, 2002 Eileen T. Lin IBM Software Group, Silicon Valley
Laboratory, 555 Bailey Avenue, San Jose, California
95141 (electronic mail: [email protected]). Dr. Lin is a
Senior Technical Staff Member and lead architect for
DB2 database federation. She joined IBM in 1990 after
receiving her Ph.D. degree from the Georgia Institute
of Technology in Atlanta. She was the lead architect
for DataJoiner query processing and led the team that
merged Data-Joiner and Garlic technology into DB2
for UNIXÒ and WindowsÒ. She is currently a lead
architect responsible for the delivery of database
federation technology in DB2 and Xperanto.
Mary A. Roth IBM Software Group, Silicon Valley
Laboratory, 555 Bailey Avenue, San Jose, California
95141 (electronic mail: [email protected]). Ms.
Roth is a senior engineer and manager in the Database
Technology Institute for e-Business at IBM's Silicon
Valley Lab. She has over 12 years of experience in
database research and development. As a researcher
and member of the Garlic project at IBM's Almaden
Research Center, she contributed key advances in
heterogeneous data integration techniques and
federated query optimization and led efforts to transfer
Garlic support to DB2. Ms. Roth is leading a team of
developers to deliver a key set of components for
Xperanto, IBM's information integration initiative for
distributed data access and integration.
HAAS, LIN, AND ROTH
19
本資料中で参照されているIBM製品またはサービスは、IBMが事業を営む全ての
国でこれらを利用可能にする意図があることを示すわけではありません。
International Business Machines Corporationはこの資料を現状のまま提供しま
す。権利の不侵害、商品性および特定目的への適合性に関する黙示の保証を含
め、いかなる保証も提供されません。
本書に記載されている情報には技術的に不正確な記述やタイプミスが含まれて
いる場合があります。IBMは予告なしに、随時、この文書に記載されている製品
またはプログラム、あるいはその両方に対して、改良または変更、あるいはそ
の両方を行うことができます。
本資料に記載されているすべてのパフォーマンス・データは制限された環境で
測定されたものであり、それぞれのお客様固有の動作環境で得られる結果とは
大きく異なる可能性があります。一部の測定値は開発レベルのシステムで得ら
れたものである場合もあり、通常利用可能なシステムで同じ測定値が得られる
ことを保証するものではありません。また、一部の測定値は、外挿によって推
定されている場合があり、実際の結果は異なる可能性があります。
IBM以外の製品に関する情報は、これらの製品の供給者、出版物、 もしくはそ
の他の公に利用可能なソースから入手したものです。IBM は、それらの製品の
テストは行っておりません。また、IBM以外の 製品に関するパフォーマンスの
正確性、互換性、またはその他の要求は確証できません。IBM以外の製品の性能
に関する質問は、それらの製品の供給者にお願いします。
20 HAAS, LIN, AND ROTH
IBM SYSTEMS JOURNAL, VOL 41, NO 4, 2002