(57)【特許請求の範囲】
【請求項１】
オブジェクト・リレーショナル・データベース・エンジンの機能を拡張する方法であって、
前記オブジェクト・リレーショナル・データベース・エンジン及び半構造化／非構造化データを含むドメイン特有の拡張モジュールとの間で関連するオペレーションを行う汎用拡張モジュールを生成するステップと、
前記汎用拡張モジュールが、ドメイン特有のデータ・タイプを処理する、ドメイン特有の拡張モジュールを合成するステップであって、該汎用拡張モジュールが、
前記オブジェクト・リレーショナル・データベース・エンジン及び前記ドメイン特有の拡張モジュールと関連したオペレーションを可能にし、ドメイン特有の拡張モジュールの合成を行うための、データベース特有のスキーマ及びセマンティクスの少なくとも１つを含むメタ・データに従って、データベース特有の管理テーブル、管理コマンドおよびＡＰＩを生成することにより、ドメイン特有の拡張モジュールを合成するステップと、
照会を最適化して前記ドメイン特有の拡張モジュールに送信するステップと含む、
方法。
【請求項２】
前記半構造化データが拡張可能マークアップ言語データ及びハイパーテキスト・マークアップ言語データの少なくとも１つを含む、請求項１に記載の方法。
【請求項３】
前記非構造化データがベクトル・データ、格子データ、及びテキスト・データの少なくとも１つを含む、請求項２に記載の方法。
【請求項４】
前記ベクトル・データが線及び多角形の少なくと１つを含む、請求項３に記載の方法。
【請求項５】
前記格子データが１次元データ、２次元データ、２次元データ＋時間データ、３次元データ、及び３次元データ＋時間データの少なくとも１つを含む、請求項３に記載の方法。
【請求項６】
前記汎用拡張モジュールが照会構文解析、照会最適化、副照会ディスパッチ、及び照会結果結合の少なくとも１つを実行する、請求項１に記載の方法。
【請求項７】
前記汎用拡張モジュールがドメイン特有の拡張モジュールに対するプラグ・アンド・プレイ・インターフェースを含む、請求項１に記載の方法。
【請求項８】
階層構造を有するオブジェクト・リレーショナル・データベース・システムであって、
前記階層構造における１つの層として働くオブジェクト・リレーショナル・データベース・エンジンと、
前記オブジェクト・リレーショナル・データベース・エンジン及び半構造化／非構造化データを含むドメイン特有の拡張モジュールとの間で関連するオペレーションを行う汎用拡張モジュールを生成する手段と、
前記汎用拡張モジュールが前記階層構造における更に別の層として働き、ドメイン特有のデータ・タイプを処理する、ドメイン特有の拡張モジュールを合成する手段であって、該汎用拡張モジュールが、
前記オブジェクト・リレーショナル・データベース・エンジン及び前記ドメイン特有の拡張モジュールと関連したオペレーションを可能にし、ドメイン特有の拡張モジュールの合成を行うための、データベース特有のスキーマ及びセマンティクスの少なくとも１つを含むメタ・データに従って、データベース特有の管理テーブル、管理コマンドおよびＡＰＩを生成することにより、ドメイン特有の拡張モジュールを合成する手段と、
照会を最適化して前記ドメイン特有の拡張モジュールに送信する手段と含む、
を含むシステム。
【請求項９】
前記システムが、リレーショナル・データベースのオブジェクト指向拡張を行うソフトウェア・モジュールのための拡張可能構造を有する、請求項８に記載のシステム。
【請求項１０】
前記システムが、既存のソフトウェア・モジュールからエクステンダ・ラッパーを生成する、請求項８に記載のシステム。
【請求項１１】
前記システムが、非リレーショナル照会処理機能を有する拡張モジュールを構成する、請求項８に記載のシステム。
【請求項１２】
前記半構造化データが拡張可能マークアップ言語データまたはハイパーテキスト・マークアップ言語データを含む、請求項８に記載のシステム。
【請求項１３】
前記非構造化データがベクトル・データ、格子データ、及びテキスト・データの少なくとも１つを含む、請求項８に記載のシステム。
【請求項１４】
前記ベクトル・データが線及び多角形の少なくと１つを含む、請求項１３に記載のシステム。
【請求項１５】
前記格子データが１次元データ、２次元データ、２次元データ＋時間データ、３次元データ、及び３次元データ＋時間データの少なくとも１つを含む、請求項１３に記載のシステム。
【請求項１６】
前記汎用拡張モジュールが照会構文解析、照会最適化、副照会ディスパッチ、及び照会結果結合の少なくとも１つを実行する、請求項８に記載のシステム。
【請求項１７】
前記汎用拡張モジュールがドメイン特有の拡張モジュールに対するプラグ・アンド・プレイ・インターフェースを含む、請求項９に記載のシステム。
【請求項１８】
サーバ・コンピュータに対してクライアント・コンピュータが照会を依頼し、前記サーバ・コンピュータが階層構造に従って前記照会を処理するクライアント／サーバ・ベースのオブジェクト・リレーショナル・データベース・システムであって、
オブジェクト・リレーショナル・データベース・エンジンと、
前記オブジェクト・リレーショナル・データベース・エンジン及び半構造化／非構造化データを含むドメイン特有の拡張モジュールとの間で関連するオペレーションを行う汎用拡張モジュールを生成する手段と、
前記汎用拡張モジュールが、ドメイン特有のデータ・タイプを処理する、ドメイン特有の拡張モジュールを合成する手段であって、該汎用拡張モジュールが、
前記オブジェクト・リレーショナル・データベース・エンジン及び前記ドメイン特有の拡張モジュールと関連したオペレーションを可能にし、ドメイン特有の拡張モジュールの合成を行うための、データベース特有のスキーマ及びセマンティクスの少なくとも１つを含むメタ・データに従って、データベース特有の管理テーブル、管理コマンド及びＡＰＩを生成することにより、ドメイン特有の拡張モジュールを合成する手段と、
照会を最適化して前記ドメイン特有の拡張モジュールに送信する手段と含む、
を含むオブジェクト・リレーショナル・データベース・システム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、データベース管理システムに関し、詳しく云えば、リレーショナル及びオブジェクト・リレーショナル・データベース管理システムを拡張するための方法及び装置に関するものである。
【０００２】
【従来の技術】
データベース・システムは、通常、データベース・クライアントがネットワーク（例えば、インターネット、イントラネット等）を介して、データベース管理システム（ＤＢＭＳ）により管理される１つ又は複数のデータベース・サーバに接続したものから成る。そのような配置構成が図１に示される。図示のように、データベース・クライアント（コンピュータ・システム）１０２は、通信ネットワーク１０３を介して１つ又は複数のＤＢＭＳ（コンピュータ・システム）１０１−１乃至１０１−Ｎ（各ＤＢＭＳが１つ又は複数のデータベース・サーバを含む）に接続される。小売販売によって発生されるデータのようなデータベース・システムにより処理される仮想的にすべてのビジネス・データが構造化データのカテゴリに入るということは知られている。構造化データは、リレーショナル・データベース又はスプレッドシートにおけるデータ・テーブルのような構造化フォーマットで存在するデータである。非構造化データ（テキスト、時系列、イメージ、オーディオ、及びビデオのようなもの）及び半構造化データ（ハイパーテキスト・マークアップ言語（ＨＴＭＬ）、拡張可能マークアップ言語（ＸＭＬ）、及び他のタグ付きドキュメント）が普及し始めているので、これらのタイプのデータを効率的に管理するためには、データベース管理システムはそのアクセス及びサーチ機能をかなり変更しなければならない。
【０００３】
種々のデータ・タイプ及び事例の分類法が図２に示される。図２に示されるように、データ２００は、構造化２０２、非構造化２０４、及び半構造化２０６として分類され得る。上記のように、構造化データの一例は、リレーショナル・テーブル・スプレッドシートにおけるデータであり、一方、半構造化データの例は、ＸＭＬデータ及びＨＴＭＬデータを含む。非構造化データは、ベクトル２０８、格子２１０、及びテキスト２１２として更に分類され得る。ベクトルは、種々の地理情報システム（ＧＩＳ）において使用される線２１４及び多角形２１６を含み得る。格子データは、１次元データ２１８（オーディオ、時系列データのような）、２次元データ２２０（イメージ、写真のような）、２次元＋時間データ２２２（ビデオのような）、３次元データ２２４（磁気共鳴画像（ＭＲＩ）データ、コンピュータ断層撮影（ＣＴ）データ、地震データのような）、及び３次元＋時間データ２２６（気候モデル・シミュレーション出力データのような）を含み得る。
【０００４】
非構造化データ及び半構造化データのアクセス及び管理を容易にするために、データベース・ベンダは、処理及び管理可能なデータ・タイプを拡張及び強化するために、オブジェクト・リレーショナル方式を使用し始めている。オブジェクト・リレーショナル・データ・モデルは、リレーショナル・テーブルの属性が、複雑なデータ構造及びこれらの構造に対するアクセス方式の両方を含み得る抽象データ・タイプであることを可能にする。この方式は、アプリケーション組立プログラムが新たなデータ・タイプ及びアクセス方式に基づいてデータをリレーショナル・テーブルに記憶することを可能にする。図２において分類されたデータ・タイプのアクセスを容易にするために、事前定義されたデータ・タイプ及び方式を含むモジュールも開発されている。現在、商業的に入手可能な主要なオブジェクト・リレーショナル・データベースは、２層アーキテクチャ、即ち、
（１）リレーショナル・データベース・エンジン
（２）拡張モジュール
を提供している。拡張モジュールの例は、ＩＢＭ（Ｒ）社のＤＢ２データベースにおいて使用されるエクステンダ、オラクル（Ｒ）データベースによって使用されるデータ・カートリッジ、及びインフォーミックス（Ｒ）データベースによって使用されるデータブレードを含む。これらの拡張モジュールは、ユーザ定義のデータ・タイプ（及びデータベースの或る新しいバージョンにおける抽象データ・タイプ）、及びリレーショナル・データベース・エンジンの機能を拡張するためにデータベース・エンジンによってイネーブルされるユーザ定義の機能（ＵＤＦ）の両方を利用する。ほとんどの拡張モジュール（エクステンダ、データブレード、及びデータ・カートリッジ）は、イメージ、ビデオ、空間データ、テキスト、及び最近発生したＸＭＬデータのような非構造化及び半構造化データ管理の領域にある。
【０００５】
【発明が解決しようとする課題】
しかし、この方法は次のような欠点を有する。
（１）ＵＤＦに関連する照会最適化：
エクステンダ／データブレード／データ・カートリッジからのＵＤＦ関連の照会最適化は困難であり、コスト関数を見積もるための可能性が広範囲に変化するために不可能であることがある。一般的には、高い選択性及び低い計算コストを持つ副照会は、照会最適化時の低い選択性及び高い計算コストを持つ副照会より上に優先順位付けられる。この方法は、細かい制約（細かい範囲の照会を含む）に適用可能である。しかし、この最適化方法は、ファジー制約を扱うことが難しく、データベースにおけるすべてのオブジェクトが候補である類似照会を扱うことができない。特に、既存の如何なるオブジェクト・リレーショナル・データベースにおける照会最適化プログラムも、ファジー・デカルト演算子に関する照会を処理することができない。
【０００６】
（２）既存のサーチ・エンジンからの新たなエクステンダの開発：
現在、各オブジェクト・リレーショナル・データベースは、比較的精密なＡＰＩ（アプリケーション・プログラミング・インターフェース）を有し、既存のサーチ・エンジンをエクステンダ／データブレード／データ・カートリッジに変換するために必要な「グルー（ｇｌｕｅ）」を開発することが重要な努力すべき事項である。このグルーという用語及び「ラッパー（ｗｒａｐｐｅｒ）」という用語が、１セットのＡＰＩを他のセットのＡＰＩに変換するために必要なソフトウェア・コードであることは明らかである。標準的なサーチ・エンジンはそれ自身のＡＰＩを有し、それは、データベースにおいて使用されるプログラミング・モデルを監視しないことがあり得る。その結果、サーチ・エンジンから、データベースが必要とするソフトウェア環境にＡＰＩを変換するためには、ソフトウェア・ラッパー又はグルーが必要となる。
【０００７】
以下の説明では、第１の問題（照会最適化）に関して更に詳述する。図３は、イメージのような非構造化データを照会するという例を示す。最も粗い検索レベル（粗粒度アクセス）は、ブロック３０１に示されるようなイメージ全体のような非構造化ドキュメント全体である。ブロック３０２に示されるようなイメージの副領域（例えば、顔の領域）を検索することも可能である。多くの新しいアプリケーションは、ブロック３０３に示されるように、オブジェクト（例えば、木、自動車、人）レベル（微粒度アクセス）で検索することを必要とする。ドキュメントのサイズが益々大きくなるので、オブジェクト・レベルの検索も益々重要になるであろう。一般的なデータ・タイプとは異なるメタデータに基づくドキュメント、サブ・ドキュメント、又はオブジェクトの検索は、ユーザ定義のデータ・タイプ及びユーザ定義の機能の使用を必要とする。
【０００８】
ＩＢＭ社及びインフォーミックス社のものは、いずれも、この種のアクセスを行うために、それぞれ、エクステンダ及びデータブレードを有する。しかし、非構造化データのアクセスは、通常、ユークリッド距離のような類似性の基準に基づいている。これは、データベース内のすべてのエントリが候補として見なされ得ること、及び（リレーショナル・データベースにおいて使用されるものとは逆に）まったく異なる基準セットが、サーチ結果を簡潔にするために採用される必要があることを意味する。現在、既存のオブジェクト・リレーショナル・データベースはすべて、ＳＱＬ（Standard Query Language:標準照会言語）及び拡張モジュールからの照会結果を結合するために、次のようなプロセスを進めなければならない。
（１）非構造化データをアクセスする拡張モジュール（エクステンダ、データ・カートリッジ、又はデータブレード）からの所定数の結果（例えば、上位１０００）をリクエストする；
（２）類似性の基準（照会及び検索された結果の間のユークリッド距離のような）に基づいてその戻された結果をランクづけする；
（３）ＳＱＬを介して処理される他の副照会及びその戻された結果を結合する。
【０００９】
しかし、この作戦は、（各拡張モジュールによる早過ぎる簡潔化のために）複数のエクステンダからの結果を結合する必要がある時、正しい結果を生まないであろう。更に、リレーショナル・オペレーションからの結果を拡張モジュールからの結果と結合するプロセスは、正しい結果を生じることにおいて同じ困難に遭遇する。
【００１０】
図４は、既存のリレーショナル照会パラダイムに挑戦する種々の照会の分類法を示す。ここでは、４つのタイプの照会がリストされている。それらは、「結合（４０２として示される）」、「論理的合成（４０４として示される）」、「空間的合成（４０６として示される）」、及び「時間的合成（４０８として示される）」である。標準ＳＱＬ照会に基づく既存のリレーショナル機構は、既に、その表における精密照会４１０を処理することができる。しかし、その表におけるファジー照会４１２は、既存のリレーショナル・エンジンにはほとんど存在しない拡張を必要とする。
【００１１】
更に、空間的合成照会の一例が図５及び図６に示される。この照会は、３つの「サブ・オブジェクト」、即ち、シェール５０１；サンドストーン５０２；及びシルトストーン５０３を含む「デルタ・ローブ」と同様の「オブジェクト」をサーチしようとしている。この照会におけるこれらのサブ・オブジェクトの各々はイメージ・テクスチャによって定義される。更なる制約は、シェールがサンドストーンに隣接していなければならず、サンドストーンがシルトストーンから１０フィート（３.０４８メートル）内になければならないことを指定する。この照会は、実際には、多くの様式で存在する情報が結合される必要があるというほとんどの状況下では、図６に示されるように、副照会である。この場合、石油／ガス井戸６０１のボーリング穴に関するデータは次の事項を含む：
（１）ガンマ線、陽子密度、中性子密度等のようなパラメータを取り込んだ単一次元の級数である油井検層記録６０２；
（２）油井から抽出された岩芯のディジタル化イメージである岩芯写真６０３（これらの岩芯写真は可視光線及び紫外線の下で撮られる）；
（３）油井の抵抗性／導電性に関する１９２次元のセンサ読取り値であるＦＭＩ６０４；
（４）１つのエリアにおける油井の外観図及び地層が１つの油井から他の油井に続く状態を示す蓄積モデル６０５。
【００１２】
以前、ＩＢＭ社が、雑多なデータ源を統合するためにラッパーを使用するグローバル・ガーリック方式を提案した。この方法が図７に示される。ラッパーは、次のような雑多なデータ源からの必要な方式変換を提供する：
（１）イメージ記憶装置７０８を介してイメージ・アーカイブ７１１をアクセスするためのイメージ・ラッパー７０５；
（２）リレーショナルＤＢＭＳ７０９を介してリレーショナル・テーブル７１２をアクセスするためのリレーショナル・ラッパー７０６；
（３）ドキュメント記憶装置７１０を介してドキュメント・アーカイブ７１３をアクセスするためのドキュメント・ラッパー７０７。
【００１３】
このグローバル・ガーリック方式は、オブジェクト指向ミドルウェア７０３によって統合される。ミドルウェア７０３は、メタデータ記憶装置７０４に記憶されたそのグローバル方式に抗して照会／ブラウズ・ツール７０１又はＣ++ＡＰＩ７０２からの照会を最適化する責任を有する。「ＯＯ」ＳＱＬは、オブジェクト指向ＳＱＬを指す。このパラダイムは、ハイブリッド・ファジー及び精密な照会に適応すべく拡張されるようにその機能によって適切に制限される。新しい照会の各機能は、グローバル方式に対する最適化モジュールの修正を伴う。
【００１４】
個々のデータベース管理システムを統合データベース管理システムと統合するガーリックのような構造を介して照会機能を拡張することとは反対に、現在のオブジェクト・リレーショナル方式は、ＩＢＭ  ＤＢ２エクステンダ、オラクル・データ・カートリッジ、又はインフォーミックス・データブレードのような拡張モジュールを介して照会機能を拡張する。
【００１５】
【課題を解決するための手段】
本発明は、多層オブジェクト・リレーショナル・データベース・アーキテクチャを提供するための技法に関する。本発明の１つの実施例では、多層データベース・アーキテクチャは、最上層としてのオブジェクト・リレーショナル・データベース・エンジン、最下層としての１つ又は複数のドメイン特有の拡張モジュール、及び中間層としての１つ又は複数の汎用拡張モジュールを含む。最下層の個々の拡張モジュールは、１つ又は複数の汎用拡張モジュールと動作的に接続し、その汎用拡張モジュール自身は、データベース・エンジンと動作的に接続する。ドメイン特有の拡張モジュールは、イメージ、ビデオ、オーディオ、時系列、ウェブ・ページ、テキスト、ＸＭＬ、宇宙データ等のサーチ、インデックス、及び検索サービスを提供することが望ましい。ドメイン特有の拡張モジュールは、１つ又は複数のＩＢＭ社のＤＢ２エクステンダ、オラクル社のデータ・カートリッジ、及び（又は）インフォーミックス社のデータブレードを含み得るが、他のドメイン特有の拡張モジュールが使用されてもよい。
【００１６】
本発明の１つ又は複数の汎用拡張モジュールは、それぞれ次のような機能を実行し得る：
（１）照会構文解析：汎用拡張モジュールによって処理される必要がある副照会がユーザ定義の機能に組み込まれ、汎用拡張モジュールに送られる。しかる後、これらの副照会が汎用拡張モジュールの照会構文解析プログラムによって構文解析される。しかる後、その結果が汎用拡張モジュールの照会最適化プログラムに送られる。
（２）照会最適化：汎用拡張モジュールにおける照会最適化プログラムが照会最適化を行う。本願において説明されるように、本発明の照会最適化プログラムは、基本的なデータ・タイプのデータ・モデルにおける汎用拡張モジュールの部分に関してより良い理解が得られるので、一般的なエクステンダによって可能となる照会最適化よりも良好に照会最適化を行うことができる。特に、オブジェクト・リレーショナル方式がマルチメディア・オブジェクトの処理に適用される。
更に、グローバル照会を更に強化する必要がある場合、拡張モジュールにおいて副照会を処理するコストが、フィードバック機構を介して汎用データベース最適化プログラムに返送され得る。
（３）ドメイン特有の拡張モジュールに副照会をディスパッチする。照会最適化プログラムによって最適化される副照会が、汎用拡張モジュールを登録されているドメイン特有の拡張モジュールにディスパッチされる。
（４）汎用拡張モジュールに接続しているドメイン特有の拡張モジュールからの照会結果を結合し、その照会結果をデータベース・エンジン又は現在の拡張モジュールを呼び出した他の汎用拡張モジュールに戻す。
【００１７】
照会最適化機能の階層的分解は、汎用拡張モジュールが、オブジェクト・リレーショナル照会エンジンを修正する必要なく、マルチメディア・オブジェクトに関する照会に関して更に広範囲の照会最適化を行うことを可能にする。
【００１８】
１つの実施例では、本発明による汎用拡張モジュールのアプリケーション・プログラミング・インターフェース（ＡＰＩ）は、「プラグ・アンド・プレイ」インターフェースであってもよく、ＸＭＬに基づき「自己記述」機構を通して実装可能である。汎用拡張モジュールと特定のデータ・タイプを処理するドメイン特有の拡張モジュールとの間のソフトウェア・コード（例えば、グルー）が自動的に合成され、従って、既存のサーチ・エンジンを所与のオブジェクト・リレーショナル・データベースに適応させる仕事を大いに単純化する。
【００１９】
本発明の汎用拡張モジュールのためのプラグ・アンド・プレイ機能は、パーソナル・コンピュータ関連したプラグ・アンド・プレイの概念と同じである。パーソナル・コンピュータの場合、プラグ・アンド・プレイは、次のような動作に関連する：
（１）接続されているデバイス（例えば、プリンタ、ＣＤ−ＲＯＭ、モデム等）がどのポート又はスロットに接続されているかを識別し；
（２）その情報に基づいて、必要な資源（例えば、割込、Ｉ／Ｏ、メモリ等）を決定し且つ割り当て；
（３）これが最初の使用である場合、ドライバ・ライブラリから適切なドライバを見つけ、しかる後、必要なドライバをインストールする。
【００２０】
本発明の汎用拡張モジュールのためのプラグ・アンド・プレイはこれと同じである。エクステンダとしてデータベースにプラグ・インされる必要のある新しいサーチ・エンジンが存在する時にはいつも、そのサーチ・エンジンが識別され、必要な資源（例えば、メモリ）が割り当てられ、しかる後、そのサーチ・エンジンが認知されてデータベースにおいて呼び出されるようにインターフェースが登録される。
【００２１】
拡張モジュールがプラグ・アンド・プレイであるためには、その拡張モジュールは、それが受け入れる照会言語又はＡＰＩ、インデックスのロケーション（それが存在する場合）、及びリターン結果の構造を記述しなければならないということは明らかであろう。
【００２２】
上で使用した「自己記述」という用語は、データの性質を記述したメタデータが存在するという概念を指す。メタデータは、データベースのスキーマ及びセマンティクスを含み得る。
【００２３】
従って、本願において詳しく説明されるように、本発明は、リレーショナル・データベースのオブジェクト指向拡張を構成するために使用可能なソフトウェア・モジュールのための拡張可能な構造を提供する。更に、本発明は、既存のソフトウェア・モジュールからエクステンダ・ラッパーを自動的に合成する方法を提供する。更に、拡張モジュールを構成するための本発明の階層的アーキテクチャは、高性能の非リレーショナル照会処理機能を提供する
【００２４】
本発明に関するこれらの及び他のオブジェクト、フィーチャ、及び利点は、添付図面に関連して読まれるべき以下のような実施例の詳細な説明から明らかになるであろう。
【００２５】
【発明の実施の形態】
以下で詳細に説明されるように、本発明は、
（１）リレーショナル・データベースのオブジェクト指向拡張を構成するために使用され得るソフトウェア・モジュールのための拡張可能な構造；
（２）既存のソフトウェア・モジュールからエクステンダ・ラッパーを自動的に合成するための方法；
（３）高性能の非リレーショナル照会処理機能を与えるために拡張モジュールを構成するための階層的アーキテクチャ
を提供する。
【００２６】
以下の詳細な説明では、一例としてＩＢＭ社のデータベースＤＢ２を使用する望ましい実施例が示される。本発明では、図８に示されるＤＢ２エクステンダ構造が使用されるけれども、幾つかの名をあげるとすれば、オラクル社及びインフォーミックス社から得られるような他の任意のオブジェクト・リレーショナル・データベースに、本発明の原理が適用され得ることは明らかである。
【００２７】
図８乃至図２０は、ＤＢ２エクステンダの使用に関連したアーキテクチャ及びコーディングの例を示す。図８に示されるように、サーバ・サイドは、汎用データベース（ＵＤＢ）サーバ・コンピュータ・システム８０１を含み、そのＵＤＢサーバ・コンピュータ・システムは、ＡＰＩを介して１つ又は複数のエクステンダ・サーバ８０３に接続している。クライアント・サイドは、ＵＤＢクライアント・コンピュータ・システム８０２を含み、そのＵＤＢクライアント・コンピュータ・システムは、次のような３つの方法、即ち、
（１）管理コマンドを受け付けるコマンド・ライン・インタープリタ８０４；
（２）ＵＤＦ拡張を有するＳＱＬ照会を受け付けるＵＤＦ８０５；
（３）顧客のアプリケーションによって呼び出され得るアプリケーション・プログラミング・インターフェース（ＡＰＩ）８０６
を通して人間又はアプリケーション・プログラムとインターフェースすることができる。
【００２８】
１つの例としてＤＢ２エクステンダを使用すると、現在のところ、ＤＢ２  Ｖ７.１が、テキスト、マルチメディア、空間、及びＸＭＬエクステンダを提供している。
【００２９】
テキスト・エクステンダに関して、ＤＢ２テキスト・エクステンダ・サーバ及びテキスト・エクステンダ・クライアントの両方に対する使用可能なコマンド、即ち、コマンド・ライン・インタープリタ（図８における８０４）によって解釈され得るすべてのコマンドが図９（サーバ・サイド）及び図１０（クライアント・サイド）においてリストされる。クライアント・サイドのコマンドは、「エクステンダ・サーバに接続する（CONNECT）」、「テキスト・テーブルをイネーブルする（ENABLE TEXT TABLE）」、及び「テキスト・コラムをイネーブルする（ENABLE TEXT COLUMN）」のような機能を含む。サーバ・サイドのコマンドは、「テキスト・エクステンダ・インスタンスを作成する（TXICRT）」、「テキスト・エクステンダ・サーバを加える（TXNADD）」、及び「テキスト・エクステンダ・サービスを開始する（TXSTART）」のような機能を含む。ユーザ定義のデータ・タイプ（ＵＤＴ）及びユーザ定義の機能（ＵＤＦ）（図８では８０５として示される）がそれぞれ図１１及び図１２に示される。テキスト・エクステンダに関して定義されたＵＤＴは、DB2TEXTH、DB2TEXTFH、DB2TEXTHLISTP、及びDB2TEXTFHLISTP を含む。ＵＤＦは、CONTAINS、FILE、FORMAT、NO_OF_DOCUMENTS 等を含む。これらのＵＤＴ及びＵＤＦは、ＳＱＬ照会（一例が図１６に示され、説明されている）において使用され得る。Ｃ又はＣ++プログラムにサブルーチン・コールとして直接に組み込まれ得るプログラミングＡＰＩが図１３に示される。
【００３０】
テキスト・エクステンダＵＤＴの使用により純粋なリレーショナル・テーブルを拡張する例が図１４に示される。オリジナル・テーブル１２０１は、ドキュメント識別子（ＤＯＣＩＤ）及びコメントのような属性を含む。ＤＢ２テキスト・エクステンダの使用を伴う拡張テーブル１２０２は、もう１つの属性、コメント・ハンドルを加える。コメント・ハンドルは、
（１）ドキュメントＩＤ；
（２）関連のインデックスの名前及びロケーション；
（３）ドキュメント情報であるコード化された文字セットＩＤ（CCSID）、フォーマット、及び言語
を含む。
【００３１】
この拡張テーブルは、コマンド「テキスト・コラムをイネーブルする（ENABLE TEXT COLUMN）」を使用して作成される。更なるコメント・ハンドル・コラムに加えて、（図１５に示されるように）次のような２つの更なるテーブルが作成される：
（１）インデックス１３０１：「ENABLE TEXT COLUMN」 が呼び出される時、テキスト・コラムに対するインデックスが作成される。
（２）ログ・テーブル１３０２：ログ・テーブルは、テキスト・コラムに対する変更、即ち、挿入、更新、及び削除を記録するために使用される。挿入、更新、及び削除トリガは、ログ・テーブルを自動的に最新状態に保つためにテキスト・コラムに対して定義される。
【００３２】
テキスト・エクステンダを使用する２つのコード・サンプルが図１６に示される。第１部分１４０１は、コメント「圧縮する（compress）」を含むドキュメントの日付及び主題のリストを印刷する。DB2TX.CONTAINS はＵＤＦコールであることに留意してほしい。第２部分１４０２は、３つの属性、即ち、DATE、SUBJECT、及び MATCHES を含む中間結果（TEMPTABLE）を生成する。第１副照会は、各行がドキュメントからの次のような属性、即ち、日付、主題、及び「圧縮する（compress）」がドキュメントにおいて現れる回数を含むように、一時的なテーブルを形成する。第２副照会は、 MATCHES がゼロよりも大きい行を選択する。第２照会において使用されるＵＤＦは、DB2TX.NO_OF_MATCHES である。これらの２つの照会は、同様の結果を生成するであろう。
【００３３】
図１７は、イメージ・エクステンダでもって正規のテーブルを拡張するプロセスを示す。この場合、ユーザ・テーブル１５０１は、当初、ＩＤ及び名前（ＮＡＭＥ）を属性として含む。イメージ・エクステンダＵＤＴに基づいてイメージを記憶するための列が作成される時、そのイメージはユーザ・テーブルには記憶されない。その代わり、ハンドル（実際には、文字ストリングである）が作成され、ユーザ・テーブルに記憶される（HANDLE 1, HANDLE 2）。エクステンダは、オブジェクトを管理サポート・テーブル１５０２に記憶するか、或いは、そのオブジェクト内容がファイルにある場合にファイル識別子を管理サポート・テーブル１５０２に記憶する。エクステンダは、オブジェクトの属性及びハンドルも管理サポート・テーブル１５０２に記憶する。この方法では、エクステンダは、ユーザ・テーブルに記憶されたハンドルを管理サポート・テーブルに記憶されたオブジェクト情報とリンクすることができる。管理テーブルには、インポータ及びアップデータのような（媒体のタイプに無関係の）共通属性が管理サポート・テーブル１５０３に記憶され、一方、幅、高さ、帯域の数のような他の媒体特有の属性が第２管理サポート・テーブル１５０４に記憶される。
【００３４】
マルチメディア・エクステンダに対するＵＤＴ及びＵＤＦのリスト（イメージ、ビデオ、及びオーディオ）がそれぞれ図１８及び図１９に示される。ユーザ定義の機能を使用することに関するコード・サンプルが図２０に示される。第１の例１７０１は、カラー・ヒストグラム・フィーチャに対するデータ・ソース（この場合、"/tmp/img.gif"）を識別するプロセスを示す。第２の例１７０２は、「従業員」によって定義されるソースを介して「qHandle」によって定義されたイメージに関してサーチするプロセスを示す。
【００３５】
図２１は、本発明の１つの実施例に従って汎用拡張モジュールに対するフレームワークを示す。一般に、汎用拡張モジュール・フレームワーク１８００は、次のような４つの要素を含む：
（１）データ・タイプ：これは、例えば、テキスト、イメージ、ビデオ、ＸＭＬ、地球空間データ等であり得る；
（２）データ・モデル１８０２：これは、例えば、テキスト、トークン、フィーチャ、領域、セグメント、シーン、ショット等の集合体の説明である；
（３）変換方式１８０３：これらの方法は、例えば、ＪＰＥＧ（ジェイペグ：Joint Photographic Expert Group）からＧＩＦ（グラフィック交換形式：Graphic Interchange Format）への変換、又はＡＶＩ（オーディオ・ビデオ・インターリーブ：Audio Video Interleave）からＭＰＥＧ（エムペグ：Moving Picture Expert Group - ＭＰＥＧ−１、ＭＰＥＧ−２、及び  ＭＰＥＧ−４）への変換のような１つのフォーマットから他のフォーマットへの変換を行って、データからのフィーチャ抽出を行うために使用される；
（４）アクセス方式１８０４：例えば、「．．．と同様の上位Ｋ個の結果」等のようなデータをアクセスするためのアクセス方式が使用される。
【００３６】
第１の局面では、本発明は、種々の拡張モジュールの間で最大のインフラストラクチャ及びモジュールが共用されるようにクラス・ハイアラーキを構成するフレームワーク及び方法を含む。汎用拡張モジュール・フレームワークのクラス・ハイアラーキ１９００（オブジェクト指向プログラミング・センスにおける）が図２２に示される。種々のデータ形式（図２に示されるような）のアクセス機能を提供するための多くのエクステンダが、フィーチャ抽出、インデックス生成、及び類似の程度（結果評価のための距離測定基準）のような多くのインフラストラクチャを潜在的に共用し得る。しかし、既存のエクステンダ、データ・カートリッジ、又はデータブレードは、すべて、相互に無関係に構成され、従って、非常にわずかしかインフラストラクチャを共用しない。従って、すべてのエクステンダ及びサーチ・エンジンに共通のクラス・ハイアラーキを確立することは、ドメイン特有のエクステンダにおけるコンポーネントが更に共用可能であることを可能にする。換言すれば、汎用拡張モジュール・フレームワークが、クラス・ハイアラーキに基づいて、他のエクステンダを形成するための基礎を提供する。
【００３７】
しかし、このクラス・ハイアラーキを形成するための主要な要素を識別することは簡単ではない。これに対する挑戦は、エクステンダの機能の分解に関して深く理解することを含む。ベース・エクステンダ・クラス１９０１から、（図２において定義されたような）１つのデータ形式のサーチ及び検索に関連するエクステンダ・クラスの主要な要素は、
（１）フィーチャ抽出クラス１９０４；
（２）インデックス作成／検索クラス１９０５；
（３）スコアリング／距離メトリック・クラス１９０６；
（４）学習／反復純化クラス１９０７
等を含む。
【００３８】
これらのクラスも相関しており、次の幾つかの図と関連してこれを更に説明することにする。データ・タイプ１９０２及びデータ・モデル１９０３（ＭＰＥＧ−７  ＡＶ（オーディオ／ビジュアル）記述方式によって定義されたもののような）がこれらの基本クラスと関連して使用され、テキスト・エクステンダ・クラス１９０８、イメージ・エクステンダ・クラス１９０９、ビデオ・エクステンダ・クラス１９１０等を構成することができる。
【００３９】
図２３乃至図３１は、本発明の実施例に従ってオーディオ／ビジュアル・フィーチャ抽出モジュールを構成するプロセスの詳細図である。図２３に示されるように、フィーチャ抽出ベース・クラス２００１から始まり、テキスト・データのためのフィーチャ抽出クラス２００２、オーディオ／ビジュアル・データのためのフィーチャ抽出クラス２００３、時系列データのためのフィーチャ抽出クラス２００４、及び多次元データのためのフィーチャ抽出クラス２００５が汎用拡張モジュールのフィーチャ抽出モジュールに含まれ得る。
【００４０】
以下の説明は、（ＭＰＥＧ−７オーディオ・ビジュアル記述方式２００６によって定義されるような）データ・モデルを使用して、フィーチャ抽出ベース・クラスからオーディオ／ビジュアル・フィーチャ抽出モジュールを定義するプロセスを示す。Ｓがデータを表し、Ｍが抽出されるフィーチャのデータ・モデルを表すものと仮定すると、フィーチャ抽出のためのベース・クラスは、Ｆ＝抽出（Ｓ，Ｍ）として定義される。このクラスは、データ・セットＳからのデータ・モデルＭに基づいてフィーチャＦを抽出する。このクラスは、再帰的に定義され得るので、フィーチャがフィーチャから抽出され得るということに注意してほしい。
【００４１】
（図２において定義されたような）データは、（時系列又はオーディオのような）１次元、（イメージのような）２次元、（ビデオ、イメージ・シーケンスのような）２次元＋時間、又は（地震、ＭＲＩ、ＣＴのような）３次元のものである。フィーチャは、低レベルのフィーチャ（テクスチャ、カラー・ヒストグラム、又はイメージに対する形状；１次元信号に対する傾きのような）、又は高レベルのフィーチャ（データに関する意味の記述）を含み得る。
【００４２】
従って、データ形式に基づいて、時系列フィーチャ抽出、オーディオ・フィーチャ抽出、イメージ・フィーチャ抽出、ビデオ・フィーチャ抽出、医学画像フィーチャ抽出、及び地震データ・フィーチャ抽出のようなデータ特有のフィーチャ抽出を定義することが可能である。オーディオ／ビジュアル・フィーチャ抽出に関しては、データ・モデルを定義するために、ＭＰＥＧ−７仕様を使用することが可能である。
【００４３】
ＭＰＥＧ−７オーディオ／ビジュアル記述方式が図２４に示される。この方式は、シンタックス、セマンティックス、並びに、オーディオ、イメージ及びビデオ内のフィーチャを記述したメタ・データを定義するためのデータ・モデルである。ＭＰＥＧ−７オーディオ／ビジュアル記述方式（ＤＳ）２１０１の基本的コンポーネントは、構文体系記述方式２１０２（図２５）、意味体系記述方式２１０３（図２８）、構文体系／意味体系リンク記述方式２１０４（図２９）、モデル記述方式２１０５、サマリ記述方式２１０６、メタ情報記述方式２１０７（図３０）及びメディア情報記述方式２１０８（図３１）を含む。図２４乃至図３１における０、１、及び＊は、それらのエンティティのうちの或るものが他のエンティティのゼロ又は１に関連し得ることを示しているものと理解してほしい。一例として図２４を使用すると、構文体系ＤＳ（記述方式）は任意選択的なものである。それが存在する時、１つのインスタンスしか存在しない。従って、それは０、１として表される。同じシナリオが残りのＤＳにも適用される。図２５は、セグメントＤＳが任意選択的であり、必要なだけ多くのインスタンスを持ち得るという点でわずかに異なるシナリオを表す。図２７において、エンティティ・リレーションは任意選択的ではなく、１つ又は複数のインスタンスを持つことができる。一方、関係が必要であり、１つのインスタンスしか許されない。
【００４４】
図２５は構文体系構造記述方式２２０１を示し、この方式２２０１は、セグメント記述方式２２０２、領域記述方式２２０３（図２６）、及びイメージ又はビデオ・シーケンスにおけるセグメント／領域リレーション・グラフ記述方式２２０４（図２７）を含む。ＭＰＥＧ−７における用語「セグメント」が、任意の空間的又は時間的領域又は間隔を表すために使用され得る「サマリ」クラスであることに注意してほしい。
【００４５】
図２６においてブロック２３０１として示された領域記述方式は、時間記述方式２３０２、２次元図形記述方式２３０３、カラー／テクスチャ記述方式２３０４、モーション記述方式２３０５（ビデオ用）、変形記述方式２３０６、メタ情報記述方式２３０７（図３１において更に詳しく示される）、及びメディア情報記述方式２３０８（図３０において更に詳しく示される）を含む。
【００４６】
図２７は、セグメント／領域リレーション・グラフ記述方式２４０１を示し、その記述方式は、エンティティ・リレーション・ブロック２４０２を含む。エンティティ・リレーション・ブロック２４０２は、リレーション・ブロック２４０３、セグメントに対する参照ブロック２４０６、及び領域に対する参照ブロック２４０７を含む。図示のように、リレーション・ブロック２４０３は、タイプ２４０４及び名前２４０５によって定義される。
【００４７】
図２８は意味体系構造記述方式２５０１を示し、その記述方式は、イベント記述方式２５０２、オブジェクト記述方式２５０３、及びイベント／オブジェクト・リレーション・グラフ記述方式２５０４を含む。
【００４８】
オーディオ／ビジュアル・データの意味体系及び構文体系をリンクするための構造が図２９において定義される。図示のように、構文体系／意味体系リンク記述方式２６０１は、リンク・ソース２６０３及びリンク・ターゲット２６０４を含むリンク２６０２を含む。
【００４９】
図３０に示されるメディア情報記述方式２７０１は、１つ又は複数のメディア・プロファイル記述方式２７０２を含み、その記述方式２７０２の各々は、メディア・ハードウェア記述方式２７０３及び識別／ロケーション記述方式２７０４を含む。
【００５０】
図３１に示されるメタ情報記述方式２８０１は、各イメージ又はビデオと共通に関連するパラメトリック・データを含み、コンテント記述方式２８０２、クレジット記述方式２８０３、作成目的記述方式２８０４、権利記述方式２８０５、発行記述方式２８０６、及び金融情報記述方式２８０７を含む。コンテント記述方式２８０２は、イベント記述方式２８０８及び文字記述方式２８０９を含み、そ文字記述方式２８０９は物理的属性記述方式２８１０を含む。クレジット記述方式２８０３は、６−Ｗ記述方式２８１２を含む作成記述方式２８１１、技術スタッフ記述方式２８１３、及び物理的属性記述方式２８１５を含む芸術スタッフ記述方式２８１４、及び組織記述方式２８１６を含む。作成記述方式２８０４は、ターゲット記述方式２８１７及び分類記述方式２８１８を含む。発行記述方式２８０６は、放射記述方式２８１９、ユーザ／視聴者記述方式２８２０、及び編集記述方式２８２１を含む。金融記述方式２８０７は、コスト記述方式２８２２及び収入記述方式２８２３を含む。
【００５１】
図２４乃至図３１に示されたＭＰＥＧ−７記述方式に従って、図２４乃至図３１に示されたフィーチャ・データ・モデルに基づきメディア・データ（オーディオ又はビジュアル）からフィーチャを抽出するフィーチャ抽出モジュールを合成することが可能である。
【００５２】
次に図３２を参照すると、インデックス作成及び検索ベース・クラス２９０１（図２２において１９０５として示される）は、テキスト・インデックス２９０２、Ｂツリー２９０３、Ｒツリー２９０４、グリッド・ファイル２９０５、及び他のインデキシング方式２９０６に副分類され得る。他のインデキシング方式の例は、１９９９年７月２３日に出願された「線形最適化照会と共に使用するための多次元インデキシング構造（Multidimensional Indexing Structure for Use with Linear Optimizatin Queries）」という主題の米国特許出願第０９／３６０,３６６号において開示されている線形最適化照会を容易にするインデキシング構造、及び２０００年９月１９日に発行された「インデキシング及びサーチのための多次元データ・クラスタリング及び次元縮小（Multidimensional Data Clustering and Dimension Reduction for Indexing and Searching）」という主題の米国特許第６,１２２,６２８号において開示されているハイブリッド・クラスタリング及びＲツリー・インデキシング方式を含むが、それらに限定されない。
【００５３】
この場合、ベース・クラスにおける属性は、
（１）照会ｑ：照会ｑは、サーチ・インデックスに対するキーとして使用される；
（２）制約述語Ｃ：これは、ｑ＝（ｑ1，ｑ2）である場合、ａ1≦ｑ1≦ａ2、ｂ1≦ｑ2≦ｂ2のような精密な照会に対する範囲述語、又は類似照会に対する上位Ｋ個の候補となり得る；
（３）距離メトリックＤ：これは、同じキー・セットが異なって評価されることを可能にする（距離メトリックに関しては、更に詳細に後述する）。
【００５４】
類似性ベースの照会の例であるＱ（ｑ，Ｋ，Ｌ2）は、Ｌ2距離メトリックを使用して、照会ｑと同様の上位Ｋ個の候補をデータベースから検索する。別の方法として、制約ベースの照会Ｑ（ｑ，Ｃ）が制約述語Ｃを満足させる結果を検索するであろう。ベース・クラスにとって必要な方法は、一般に、
（１）照会Ｑ（ｑ，Ｃ，Ｄ）：制約述語Ｃを満足させる候補を検索する；
（２）挿入（ｑ）：キーｑを含むノードをインデックスに挿入し、ツリーの分離及び平衡化に関連する；
（３）削除（ｑ）：キーｑを含むノードをインデックスから削除し、ツリーの分離及び平衡化に関連する
を含む。
【００５５】
データ構造及び方法を含むこれらのベースクラスを使用して、種々のインデキシング・クラスが実装され得る。
【００５６】
種々の様式をアクセスするための拡張モジュールの多くは、データベースにおける候補とターゲットの間の類似性を計算するために或る形式の距離メトリックの使用を必要とする。２つのフィーチャ・ベクトル、ｘ＝［ｘ1，．．，ｘn］T、ｙ＝［ｙ1，．．，ｙn］Tは、次のような可能性を含む：
（１）Ｌ0：次式を使用して距離を計算する；
【数１】
0003996444.tif 000002
【００５７】
（２）Ｌ2：次式を使用して距離を計算する；
【数２】
0003996444.tif 000003
【００５８】
（３）Ｌp：次式を使用して距離を計算する；
【数３】
0003996444.tif 000004
【００５９】
（４）Ｌ ：次式を使用して距離を計算する；
【数４】
0003996444.tif 000005
【００６０】
（５）一般化した２次距離（ｘ−ｙ）TＭ（ｘ−ｙ）：この場合、マトリクスＭは、ウェイトがベクトルの種々のコンポーネントに割り当てられることを可能にする。
【００６１】
従って、ベクトルｘ及びｙの定義を含むｘ及びｙの間のベース・クラス距離メトリックを定義することが可能である。図３３に示されるように、スコアリング及び距離メトリック・ベース・クラス３００１（図２２に示された１９０６）がＬ1距離３００２、Ｌ2距離３００３、カイ二乗（ｃｈｉ−ｓｑｕａｒｅ）３００４、ハミング３００５等に副分類され得る。Ｌ2距離３００３は、更に、基本的ユークリッド３００６、及びウェート付けされたユークリッド３００７に副分類され得る。この構造は、テキスト、イメージ、及びビデオが構成される時、距離マトリクスの最大共用を可能にする。
【００６２】
学習及び反復純化（図２２に示された１９０７）のためのベース・クラス、即ち、Ｄnew＝Ｌｅａｒｎ（Ｅ，Ｄoriginal，Ｑ）は以下の事項を包含する：
（１）カテゴリ例Ｅ：これは、カテゴリの合計数が２よりも大きい時、単に、関係の及び無関係の回答の例及び各カテゴリの例である。ほとんどの場合、例のセットＥは、通常、やむを得ずＱからの照会結果から引き出す；
（２）Ｄnew：これは、例及び反証例に基づいて変換されたデータ・セットである；
（３）Ｄoriginal：これは、学習を通して変換されるべきデータ・セットである。
（４）Ｑ：これは、インデックス・ベース・クラスにおいて定義したように、所与の照会テンプレートに対する上位Ｋ個の候補を検索するための照会クラスである。
【００６３】
このクラスが再帰的に呼び出され得ること、即ち、各学習及び反復純化が新たなデータ・セットを生成することに注意してほしい。同じ照会が適用され得るし、照会結果の分類が再び学習のために使用され得る。反復純化プロセスは、各カテゴリに対する例が照会結果から引き出されるだけなので、通常は、データセット全体に比べて少ない数に限定される任意の適当な反復数を取り得る。このクラスに基づいて、距離メトリックのウェートを調節するアルゴリズム、及び１９９９年１月２６日に出願された「反復純化からの類似性検索のための方法及び装置（Method and Apparatus for Similarity Retrieval from Iterative Refinement）」という主題の米国特許出願番号第０９／２３７６４６号において開示されたアルゴリズムを含む種々の学習アルゴリズムが副分類され得る。なお、この米国特許出願におけるアルゴリズムは、学習プロセスを介して与えられた例及び反証例に基づいてフィーチャ空間を「ラップ」するために非線形多次元スケーリングを適用する。
【００６４】
第２の局面では、本発明は、拡張モジュールを自動的に合成するための方法を提供する。ワールド・ワイド・ウェブ協会によって標準化されているＸＭＬ方式のような相互運用可能なメタ・データを使用して、データ・モデル及びサーチ・エンジンと関連した方法が特定され得るという事実を認識することによって、本発明の方法は、そのようなメタ・データの処理を通してデータベース特有の管理テーブル、管理コマンド、ＡＰＩ、及びＵＤＦを自動的に生成する。
【００６５】
図３４は、本発明の実施例に従って自動拡張モジュール合成手順を示す。ステップ３１０２では、ＸＭＬ方式のデータ・モデル３１０１に基づいて、図１７に示されるような管理テーブルが作成される。これは、以下のようなステップに従って達成される。そのデータベース管理システムが、一般的なデータ（例えば、ファイルのロケーション）を記録するためのテーブル及び特定の情報（例えば、そのデータから抽出されたフィーチャ）を記録するためのテーブルのような必要な管理テーブルを定義する。サーチ・エンジンが、それらのフィーチャを記述した正確なデータ・モデル及びサーチ・エンジンのためのインデキシング方式を定義する。そのようなデータ・モデルの例は、図２５乃至図３１において定義されたオーディオ／ビジュアル記述方式を含む。データベース管理システムからの仕様及びサーチ・エンジンに基づいて、CREATE TABLE TABLE_NAME（Attribute1, Attribute2, Attribute3, .....,AttributeN）のようなコマンドが生成される。
【００６６】
次に、ステップ３１０３において、図９及び図１０おいて定義されたような管理ラッパーが、ＸＭＬ方式において定義されたメソッド記述に基づいて作成される。
【００６７】
データベース管理システムは、サーバ・サイドに関するエクステンダ・サーバ開始、サーバ停止、サーバ・ステータス、サーバ・トレース、サーバ検証、及びエクステンダ・クライアントのイネーブル／変更／ディセーブル、エクステンダ・クライアント・ステータスの照会等を含む必要な機能のタイプを指定する。サーチ・エンジンは、フィーチャを抽出するための機能、インデックスを作成するための機能、サーチを実行するために機能等の利用可能な機能を指定する。例えば、
（１）テキスト・フィーチャの抽出；
（２）テキスト・インデックスの作成；
（３）ログ・ファイルの作成
のような多数のクラスを呼び出す図１０に示された ENABLE TEXT COLUMN のようなプログラム・モジュールが作成される。
【００６８】
次に、ステップ３１０５において、図１１、図１２、図１８、及び図１９において定義されたようなＵＤＦラッパーがメソッド記述に基づいて作成される。サーチ・エンジン機能の仕様から、適正なサーチ機能（図１１、図１２、図１８、及び図１９において定義された）が作成されることを可能にするＵＤＦモジュールが作成される。
【００６９】
図３５は、本発明の上記自動合成プロセスを通して拡張モジュール３２１０に変換されるサーチ・エンジンの構造を示す。図３４において合成されたラッパーは自動合成されたグルー／ラッパー３２０１として示される。これらのラッパーを合成するためには、サーチ・エンジン３２０４は、それの方式３２０２及びサービス（ＵＤＦ）３２０３を明示的に指定する必要がある。
【００７０】
第３の局面において、本発明は、図３６に示されるように、汎用拡張モジュールが階層的に呼び出されるよう、拡張モジュール機能の階層的分解を行う。この場合、第１汎用拡張モジュール３３０２−１（図３６では、汎用エクステンダとして示される）がＤＢ２  ＵＤＢエンジン３３０１に動作関係に接続される。更なる汎用エクステンダ３３０２−２乃至３３０２−Ｎが、図示のように、第１拡張モジュールに階層的に接続され得る。汎用拡張モジュールのリーフ・ノードは、ドメイン特有の拡張モジュール（例えば、エクステンダ、データ・カートリッジ、データブレード等）であり、参照番号３３０４−１乃至３３０４−Ｐとして示される。ＵＤＢエンジン３３０１に直接に接続しているドメイン特有のエクステンダが参照番号３３０３−１乃至３３０３−Ｍとして示される。ネットワーク（図示されてない）を介してＵＤＢエンジン３３０１に結合されたＵＤＢクライアント３３０５は、図８に示されたＵＤＢクライアントと同様に、コマンド・ライン・インタープリタ３３０６、ＵＤＦ３３０７、及びＡＰＩ３３０８と共に構成され得る。図３６における種々の汎用エクステンダ及びドメイン特有のエクステンダが、１つ又は複数のエクステンダ・サーバ・コンピュータ・システム及び（又は）ＵＤＢエンジン搭載のサーバ・コンピュータ・システムにおいて実現され得る。
【００７１】
汎用拡張モジュールとドメイン特有の拡張モジュールとの間の１つの主要な相違点は、汎用拡張モジュールが照会をハイアラーキにおけるそれの親（例えば、ＵＤＢ、又はハイアラーキにおけるより高い他の汎用エクステンダ）から構文解析する機能、及び照会を１つ又は複数の副照会に分解してそれらの副照会を他の汎用エクステンダ又はドメイン特有のエクステンダに送ることを可能にする機能を有することである。従って、図３７に示されるように、各汎用拡張モジュール３３２０は、次のような機能の幾つか又はすべてを持つことが可能である。
【００７２】
（１）照会構文解析：他の汎用エクステンダ又はＵＤＢから送られた照会を構文解析する。これらの照会は、リレーショナル照会のために使用されるＳＱＬ照会シンタックスを遵守しないことがある。この照会構文解析機能は、照会構文解析プログラム３３２２に従って実装可能である；
（２）照会計画作成：照会から実行計画を作成する。照会計画作成機能は、照会計画作成プログラム３３２４に従って実装可能である；
（３）照会最適化：実行時間が最小になるように照会計画を再編成する。照会最適化機能は、照会最適化プログラム３３２６に従って実装可能である；
（４）副照会呼び出し：照会を下流の他の汎用エクステンダ又はドメイン特有のエクステンダに送る。副照会呼び出し機能は、副照会呼び出しプログラム３３２８に従って実装可能である；
（５）照会結果結合：汎用エクステンダ又は特定の汎用エクステンダに接続されたエクステンダからの結果を結合する。照会結果結合機能は、照会結果結合プログラム３３３０に従って実装可能である。
【００７３】
照会計画実行のうちの或るものは、照会計画の後戻りを伴うことが可能である。従って、上記ステップ（４）及び（５）が何回も呼び出されることがある。或る場合には、ＳＱＬ照会の或るものは汎用エクステンダ照会に組み込まれる必要があり得る。
【００７４】
汎用エクステンダ・モジュールは、テーブルを戻すことができなければならないので、そのモジュールは、ユーザ定義のテーブル機能として実装され得る。更に、汎用拡張モジュールは、それ自身の照会構文解析機構を有するので、使用可能な照会言語に関する制限はない。
【００７５】
図３８は、ＳＱＬを使用する汎用拡張呼び出しシーケンスの例を示す。ユーザ・テーブル３４０１は、オブジェクトＩＤ（一次キー）属性１、属性２等を含む。ユーザ定義のテーブル機能３４０２として実装される汎用拡張モジュールは、
UE(obj_1,color,obj_2,texture,left,100)
の形を有し、これは、左に並んだ２つのサブ・オブジェクトを含む上位１００個のオブジェクトを検索する。オブジェクト１（obj_1）がそれのカラーによって指定され、一方、オブジェクト２（obj_2）がそれのテクスチャによって指定される。更なるパラメータ制約、即ち、obj_1.attr1=a, obj_2.attr2=b も指定される。
【００７６】
図３９は、ＳＰＲＯＣアルゴリズムに基づく汎用拡張モジュール３５０３がＵＤＢ３５０４に結合されている例を示す。ＳＰＲＯＣアルゴリズムは、１９９９年１月２６日に出願された「複合オブジェクトのコンテント・ベースの検索に対する逐次処理のためのシステム及び方法（System and Method for Sequential Processing for Content-Based Retrieval of Composite Objects）」という主題の米国特許出願第０９/２３７,７３４号において開示されている。一方、汎用拡張モジュールは、イメージ・エクステンダ３５０１又は時系列エクステンダ３５０２を呼び出す。
【００７７】
上記ＳＰＲＯＣアルゴリズムは、そのバンドルされたサーチの問題に対する照会結果を作成するように設計される。バンドル・サーチは、複数の項目を可能な項目相互間の関係でもって同時にサーチすることである。それは、マルチ・モーダル信号検出及び情報融合における最も重要なイネーブル機構の１つである。例えば、ファジー・デカルト（バンドル・サーチ）照会が、石油／ガス調査データを記憶するイメージ・データベースにおいてボーリング穴のイメージに跨る岩層構造を見つけることができる。この例では、層テンプレートは、Ａ、Ｂ、及びＣとして名称を付けられた３つの岩層から成る。よくマッチしている時にはその層順序が維持されであろうが、必ずしも隣接する層の間でその間隔の量を維持するものではない。例えば、層構造Ａ、Ｂ、Ｄ、及びＣは、層Ｂ及びＣの間の間隔が大きい過ぎない場合、依然として受容可能であろう。ボーリング穴のイメージにおいて、各層が異なるテクスチャ又はカラーを示すことにより数十又は数百の岩層が存在することがある。岩のイメージのマッチングは、領域の類似性に関する信頼を表すためにゼロから１までの範囲にファジー・スコアを割り当てることが多い。ファジーの特徴化によって、領域は、Ａに対する０.８及びＢに対する０.２のような複数のテンプレートに対して複数のスコアを持ち得る。
【００７８】
層のマッチングにおけるファジー・デカルト問題は、テンプレートに比べて最高のスコアを有する上位Ｋ個の構造を選択することである。任意の３つの異なるイメージ領域に関して、上部領域のＡに対するファジー・スコア、中間領域のＢに対するスコア、及び下部領域のＣに対するスコアを計算することが可能である。これらのスコアは、上部及び中間部の間の距離、及び中間部及び下部の間の距離をウェート付けしてファジー・スコアと結合される。
【００７９】
次に図４０を参照すると、本願において詳しく説明された本発明による１つ又は複数の汎用拡張モジュールを実装するに適したコンピュータ・システムの一般的なハードウエア・アーキテクチャを表すブロック図が示される。コンピュータ・システムは、１つ又は複数のドメイン特有の拡張モジュール及びデータベース・エンジンを実装することも可能である。更に、コンピュータ・システムは、データベース・システムのサーバ・サイド全体を実装し得るし、データベース・クライアントを実装するために使用される１つ又は複数の同様のコンピュータ・システムにも接続され得る。そのようなコンピュータ・システムは、ネットワーク（例えば、インターネット、イントラネット等）を介しても接続され得る。
【００８０】
図４０に示されるように、コンピュータ・システムは、プロセッサ３６０２、メモリ３６０４、及びＩ／Ｏ装置３６０６を含み得る。本願において使用される「プロセッサ」という用語が、例えば、ＣＰＵ（中央処理装置）及び（又は）他の処理回路を含む処理装置のような任意の処理装置を含むことを意図されることは明らかである。プロセッサは、その分野において周知であるディジタル信号プロセッサも含み得る。本願において使用される「メモリ」という用語は、例えば、ＲＡＭ、ＲＯＭ、固定メモリ装置（例えば、ハードディスク・ドライブ）、取り外し可能メモリ装置（例えば、ディスケット）、フラッシュ・メモリ等のようなプロセッサ又はＣＰＵと関連したメモリを含むことを意図される。更に、本願において使用される「入出力装置」又は「Ｉ／Ｏ装置」という用語は、例えば、処理装置にデータを入れるための１つ又は複数の入力装置（例えば、キーボード、マウス等）及び（又は）処理装置と関連した結果を与えるための１つ又は複数の出力装置（例えば、ＣＲＴディスプレイ、プリンタ等）を含むことを意図される。また、「プロセッサ」という用語が複数の処理装置を指し得ること及び１つの処理装置と関連した種々の素子が他の処理装置によって共用され得ることも明らかである。
【００８１】
従って、本発明の方法を実行するための命令及びコードを含むソフトウェア・コンポーネントは、１つ又は複数の関連のメモリ装置（例えば、ＲＯＭ、固定又は取り外し可能メモリ）において記憶され得るし、利用される準備ができている時、部分的に又は全体的に（例えば、ＲＡＭに）ロードされ得るし、ＣＰＵによって実行され得る。
【００８２】
添付図面を参照して本発明の実施例が本願において開示されたけれども、本発明が実施例そのものに限定されないこと、本発明の技術的範囲及び精神から逸脱することなく、種々の変更及び修正が当業者により行われ得ることは明らかである。
【００８３】
まとめとして、本発明の構成に関して以下の事項を開示する。
【００８４】
（１）オブジェクト・リレーショナル・データベース・エンジンの機能を拡張する方法にして、
１つ又は複数のドメイン特有の拡張モジュールが前記オブジェクト・リレーショナル・データベース・エンジンと関連して使用するために設けられ、前記１つ又は複数のドメイン特有の拡張モジュールは、前記オブジェクト・リレーショナル・データベース・エンジンがドメイン特有のデータ・タイプを処理することを可能にするための１つ又は複数の機構を提供するシステムにおいて、
前記オブジェクト・リレーショナル・データベース・エンジンと前記１つ又は複数のドメイン特有の拡張モジュールの少なくとも１つとの間に少なくとも１つの汎用拡張モジュールを操作可能に設けるステップを含み、
前記少なくとも１つの汎用拡張モジュールは、前記オブジェクト・リレーショナル・データベース・エンジン及び前記少なくとも１つのドメイン特有の拡張モジュールと関連した１つ又は複数のオペレーションを実質的に容易にし、少なくとも１つの他のドメイン特有の拡張モジュールのその後の追加を実質的に容易にする、方法。
（２）前記１つ又は複数のドメイン特有の拡張モジュールの少なくとも１つが半構造化データの処理を行う、上記（１）に記載の方法。
（３）前記半構造化データが拡張可能マークアップ言語データ及びハイパーテキスト・マークアップ言語データの少なくとも１つを含む、上記（２）に記載の方法。
（４）前記１つ又は複数のドメイン特有の拡張モジュールの少なくとも１つが非構造化データの処理を行う、上記（１）に記載の方法。
（５）前記非構造化データがベクトル・データ、格子データ、及びテキスト・データの少なくとも１つを含む、上記（４）に記載の方法。
（６）前記ベクトル・データが線及び多角形の少なくと１つを含む、上記（５）に記載の方法。
（７）前記格子データが１次元データ、２次元データ、２次元データ＋時間データ、３次元データ、及び３次元データ＋時間データの少なくとも１つを含む、上記（５）に記載の方法。
（８）前記少なくとも１つの汎用拡張モジュールが照会構文解析、照会最適化、副照会ディスパッチ、及び照会結果結合の少なくとも１つを実行するように動作可能である、上記（１）に記載の方法。
（９）前記少なくとも１つの汎用拡張モジュールの使用が前記照会最適化機能の階層的分解を可能にする、上記（８）に記載の方法。
（１０）前記少なくとも１つの汎用拡張モジュールが少なくとも１つ又は複数のドメイン特有の拡張モジュールに対するプラグ・アンド・プレイ・インターフェースを含む、上記（１）に記載の方法。
（１１）前記少なくとも１つの汎用拡張モジュールが前記データベースの方式及び意味体系の少なくとも１つを含むメタ・データに従って実装される、上記（１）に記載の方法。
（１２）多層構造を有するオブジェクト・リレーショナル・データベース・システムにして、
前記多層構造における１つの層として働くオブジェクト・リレーショナル・データベース・エンジンと、
前記多層構造における別の層として働き、前記オブジェクト・リレーショナル・データベース・エンジンと関連して使用するための１つ又は複数のドメイン特有の拡張モジュールであって、前記オブジェクト・リレーショナル・データベース・エンジンがドメイン特有のデータ・タイプを処理することを可能にするための１つ又は複数の機構を提供する、ドメイン特有の拡張モジュールと、
前記多層構造における更に別の層として働き、前記オブジェクト・リレーショナル・データベース・エンジンと前記１つ又は複数のドメイン特有の拡張モジュールの少なくとも１つとの間に操作可能に設けられた少なくとも１つの汎用拡張モジュールであって、前記オブジェクト・リレーショナル・データベース・エンジン及び前記少なくとも１つのドメイン特有の拡張モジュールと関連した１つ又は複数のオペレーションを実質的に容易にし、少なくとも１つの他のドメイン特有の拡張モジュールのその後の追加を実質的に容易にする、少なくとも１つの汎用拡張モジュールと、
を含むシステム。
（１３）前記システムが、リレーショナル・データベースのオブジェクト指向拡張を行う１つ又は複数のソフトウェア・モジュールのための拡張可能構造を提供する、上記（１２）に記載のシステム。
（１４）前記システムが、１つ又は複数の既存のソフトウェア・モジュールから１つ又は複数のエクステンダ・ラッパーを自動的に合成する、上記（１２）に記載のシステム。
（１５）前記システムが、１つ又は複数の高機能非リレーショナル照会処理機能を提供する１つ又は複数の拡張モジュールを構成する、上記（１２）に記載のシステム。
（１６）前記１つ又は複数のドメイン特有の拡張モジュールの少なくとも１つが半構造化データの処理を行う、上記（１２）に記載のシステム。
（１７）前記半構造化データが拡張可能マークアップ言語データ及びハイパーテキスト・マークアップ言語データの少なくとも１つを含む、上記（１６）に記載のシステム。
（１８）前記１つ又は複数のドメイン特有の拡張モジュールの少なくとも１つが非構造化データの処理を行う、上記（１２）に記載のシステム。
（１９）前記非構造化データがベクトル・データ、格子データ、及びテキスト・データの少なくとも１つを含む、上記（１８）に記載のシステム。
（２０）前記ベクトル・データが線及び多角形の少なくと１つを含む、上記（１９）に記載のシステム。
（２１）前記格子データが１次元データ、２次元データ、２次元データ＋時間データ、３次元データ、及び３次元データ＋時間データの少なくとも１つを含む、上記（１９）に記載のシステム。
（２２）前記少なくとも１つの汎用拡張モジュールが照会構文解析、照会最適化、副照会ディスパッチ、及び照会結果結合の少なくとも１つを実行するように動作可能である、上記（１２）に記載のシステム。
（２３）前記少なくとも１つの汎用拡張モジュールの使用が前記照会最適化機能の階層的分解を可能にする、上記（２２）に記載のシステム。
（２４）前記少なくとも１つの汎用拡張モジュールが少なくとも１つ又は複数のドメイン特有の拡張モジュールに対するプラグ・アンド・プレイ・インターフェースを含む、上記（１２）に記載のシステム。
（２５）前記少なくとも１つの汎用拡張モジュールが前記データベースの方式及び意味体系の少なくとも１つを含むメタ・データに従って実装される、上記（１２）に記載のシステム。
（２６）データベース・システムに従って使用するための製造物にして、
前記データベース・システムは、オブジェクト・リレーショナル・データベース・エンジン及び前記オブジェクト・リレーショナル・データベース・エンジンと関連して使用するために１つ又は複数のドメイン特有の拡張モジュールを含み、前記１つ又は複数のドメイン特有の拡張モジュールは、前記データベース・エンジンがドメイン特有のデータ・タイプを処理することを可能にするための１つ又は複数の機構を提供するシステムにおいて、
前記オブジェクト・リレーショナル・データベース・エンジンと前記１つ又は複数のドメイン特有の拡張モジュールの少なくとも１つとの間に少なくとも１つの汎用拡張モジュールを操作可能に設けて、前記オブジェクト・リレーショナル・データベース・エンジン及び前記少なくとも１つのドメイン特有の拡張モジュールと関連した１つ又は複数のオペレーションを実質的に容易にし、少なくとも１つの他のドメイン特有の拡張モジュールのその後の追加を実質的に容易にするステップを実行時に実装した１つ又は複数のプログラムを有するマシン可読媒体を含む製造物。
（２７）前記少なくとも１つの汎用拡張モジュールが照会構文解析、照会最適化、副照会ディスパッチ、及び照会結果結合の少なくとも１つを実行するように動作可能である、上記（２６）に記載の製造物。
（２８）前記少なくとも１つの汎用拡張モジュールの使用が前記照会最適化機能の階層的分解を可能にする、上記（２７）に記載の製造物。
（２９）少なくとも１つのサーバ・コンピュータに対してクライアント・コンピュータが照会を依頼し、前記少なくとも１つのサーバ・コンピュータが多層構造に従って前記照会を処理するクライアント／サーバ・ベースのオブジェクト・リレーショナル・データベース・システムにして、
オブジェクト・リレーショナル・データベース・エンジンと、
前記オブジェクト・リレーショナル・データベース・エンジンと関連して使用するための１つ又は複数のドメイン特有の拡張モジュールであって、前記オブジェクト・リレーショナル・データベース・エンジンがドメイン特有のデータ・タイプを処理することを可能にするための１つ又は複数の機構を提供する、ドメイン特有の拡張モジュールと、
前記オブジェクト・リレーショナル・データベース・エンジンと前記１つ又は複数のドメイン特有の拡張モジュールの少なくとも１つとの間に操作可能に設けられた少なくとも１つの汎用拡張モジュールであって、前記オブジェクト・リレーショナル・データベース・エンジン及び前記少なくとも１つのドメイン特有の拡張モジュールと関連した１つ又は複数のオペレーションを実質的に容易にし、少なくとも１つの他のドメイン特有の拡張モジュールのその後の追加を実質的に容易にする、少なくとも１つの汎用拡張モジュールと、
を含むオブジェクト・リレーショナル・データベース・システム。
【図面の簡単な説明】
【図１】データベース・クライアントがネットワークを介して１つ又は複数のデータベース管理システムに接続していることを示すブロック図である。
【図２】データベース管理システムによって管理される必要がある種々のデータ・タイプの分類法である。
【図３】種々のシナリオに対するアクセス粒度を示す。
【図４】結合、論理的合成、空間的合成、及び時間的合成のための高精度照会及びファジー照会の両方を示す。
【図５】各々がイメージ・フィーチャによって定義される複数の領域の空間的合成を必要とするシナリオを示す。
【図６】石油貯留モデルを構成するために、データに関する複数の形態（コア・イメージ、ＦＭＩデータ、さく井検層データ)がサーチ及び融合される必要がある場合を示す。
【図７】ラッパーを介して異種のデータ・ソースをアクセスするためのＩＢＭ社のガーリック（Ｇａｒｌｉｃ)方法を示す。
【図８】ＩＢＭ社のＤＢ２／ＵＤＢのためのクライアント・サーバ構造を示す。
【図９】サーバに対するＤＢ２テキスト・エクステンダ・コマンドを示す。
【図１０】クライアントに対するＤＢ２テキスト・エクステンダ・コマンドを示す。
【図１１】ＤＢ２テキスト・エクステンダのユーザ定義のデータタイプを示す。
【図１２】ＤＢ２テキスト・エクステンダのユーザ定義の機能を示す。
【図１３】ＤＢ２テキスト・エクステンダのプログラミングＡＰＩを示す。
【図１４】カラムがテキスト・エクステンダに対してイネーブルされる前及び後のテーブルを示す。
【図１５】テキスト・カラム・イネーブル・プロセスを示す。
【図１６】テキスト・エクステンダを使用するためのコード例を示す。
【図１７】イメージ・エクステンダによりユーザ・テーブルをイネーブルするための管理テーブルを示す。
【図１８】イメージ・エクステンダに対するユーザ定義のデータ・タイプを示す。
【図１９】イメージ・エクステンダに対するユーザ定義の機能を示す。
【図２０】イメージ・エクステンダ使用するコード例を示す。
【図２１】本発明の一実施例に従って汎用拡張モジュールのためのフレームワークを示す。
【図２２】ベース・エクステンダ・クラスを種々のエクステンダに副分類するためのクラス・ハイアラーキを示す。
【図２３】ＭＰＥＧ−７記述方式によるベース・フィーチャ拡張クラスをオーディオ／ビジュアル抽出クラスに拡張するプロセスを示す。
【図２４】ＭＰＥＧ−７オーディ／ビジュアル記述方式を示す。
【図２５】ＭＰＥＧ−７構文体系構造記述方式を示す。
【図２６】ＭＰＥＧ−７領域記述方式を示す。
【図２７】ＭＰＥＧ−７セグメント／領域関連グラフ記述方式を示す。
【図２８】ＭＰＥＧ−７意味体系構造記述方式を示す。
【図２９】ＭＰＥＧ−７構文体系／意味体系リンク記述方式を示す。
【図３０】ＭＰＥＧ−７メディア情報記述方式を示す。
【図３１】ＭＰＥＧ−７メタ情報記述方式を示す。
【図３２】インデックス作成及び検索ベース・クラスを種々のインデキシング・クラスに副分類するプロセスを示す。
【図３３】スコアリング及び距離メトリック・ベースクラスを種々の距離機能に副分類するプロセスを示す。
【図３４】拡張モジュールとしてＤＢ２にプラグインされるべきサーチ・エンジンに対するラッパーを合成するプロセスを示す。
【図３５】自動的に合成されたラッパーを有する拡張モジュールとしてサーチ・エンジンの構造を示す。
【図３６】本発明に従って新しいオペレータ及びサーチ機能を処理するための汎用拡張モジュールの階層的分解を示す。
【図３７】本発明の実施例に従って汎用拡張モジュールと関連付けられた機能的コンポーネントのブロック図を示す。
【図３８】汎用拡張モジュールをテーブル関数として読み出すコード・サンプルを示す。
【図３９】追加のエクステンダを呼び出すＳＰＲＯＣ汎用拡張モジュールの構造を示す。
【図４０】本発明の種々の局面を実装するためのコンピュータ・システムの一般的なハードウェア・アーキテクチャを示すブロック図である。
【図１】
0003996444.tif 000006
【図２】
0003996444.tif 000007
【図３】
0003996444.tif 000008
【図４】
0003996444.tif 000009
【図５】
0003996444.tif 000010
【図６】
0003996444.tif 000011
【図７】
0003996444.tif 000012
【図８】
0003996444.tif 000013
【図９】
0003996444.tif 000014
【図１０】
0003996444.tif 000015
【図１１】
0003996444.tif 000016
【図１２】
0003996444.tif 000017
【図１３】
0003996444.tif 000018
【図１４】
0003996444.tif 000019
【図１５】
0003996444.tif 000020
【図１６】
0003996444.tif 000021
【図１７】
0003996444.tif 000022
【図１８】
0003996444.tif 000023
【図１９】
0003996444.tif 000024
【図２０】
0003996444.tif 000025
【図２１】
0003996444.tif 000026
【図２２】
0003996444.tif 000027
【図２３】
0003996444.tif 000028
【図２４】
0003996444.tif 000029
【図２５】
0003996444.tif 000030
【図２６】
0003996444.tif 000031
【図２７】
0003996444.tif 000032
【図２８】
0003996444.tif 000033
【図２９】
0003996444.tif 000034
【図３０】
0003996444.tif 000035
【図３１】
0003996444.tif 000036
【図３２】
0003996444.tif 000037
【図３３】
0003996444.tif 000038
【図３４】
0003996444.tif 000039
【図３５】
0003996444.tif 000040
【図３６】
0003996444.tif 000041
【図３７】
0003996444.tif 000042
【図３８】
0003996444.tif 000043
【図３９】
0003996444.tif 000044
【図４０】
0003996444.tif 000045