(57)【特許請求の範囲】
【請求項１】
１または複数の購読者に、データベース・システム内の少なくとも１つのデータベース・テーブルＴの変化を通知する通知システムであって、
前記通知システムが、前記データベース・テーブルＴに関連付けられるメタデータ・テーブルの集合を含み、
前記メタデータ・テーブルの集合が、論理和標準形で指定される、前記データベース・テーブルＴの指定された変化に関する購読要求を、論理和標準形で記憶し、
前記通知システムが更に、前記データベース・テーブルＴに関連付けられ、前記データベース・テーブルＴの変化に応答するデータベース・トリガとして実現される、購読トリガを含み、
前記購読トリガは、当該購読トリガが応答する前記データベース・テーブルＴの変化に対応する当該データベース・テーブルＴのタプル及び前記メタデータ・テーブルの集合を参照するデータベース照会文により、前記データベース・テーブルＴの前記タプルがその内容を満たす全ての前記購読要求を決定し、
前記メタデータ・テーブルの集合は、前記データベース・テーブルＴの属性に適用可能な比較演算子のうち前記購読要求においてサポートされる比較演算子の集合に対応し、各メタデータ・テーブルは異なる比較演算子に関連付けられ、前記データベース照会文は、少なくともｎ（ここで、ｎは前記比較演算子の数）ウェイ結合を含み、
前記論理和標準形で指定される前記購読要求の各等位項は、前記各メタデータ・テーブル内の正しく１つのタプルに対応し、前記各メタデータ・テーブル内の各タプルの各要素は、当該メタデータ・テーブルに関連付けられた前記比較演算子と当該タプルに対応する前記購読要求の前記等位項に現れるアトミック表現式とに基づいて決定される値を有している、
通知システム。
【請求項２】
前記データベース照会文は、前記各メタデータ・テーブルの各タプルのうち、前記論理和標準形で指定される前記購読要求の同じ等位項に対応するタプルに対する条件の論理積を含む、請求項１記載の通知システム。
【請求項３】
前記購読トリガにより決定される前記記録の配信のための通知手段を含む、請求項１記載の通知システム。
【請求項４】
前記通知手段が前記データベース・システム内のユーザ定義機能である、請求項３記載の通知システム。
【請求項５】
前記通知が購読者データベースに記憶される、請求項１記載の通知システム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は通知システム及びメッセージ仲介の分野に関する。特に、本発明は通知の処理、とりわけ発行及び購読要求の分野に関する。
【０００２】
【従来の技術】
本発明は非常に一般的な適用範囲を有する。その基本的な概念は、あらゆる通知プロセスまたは仲介、特に発行及び購読プロセスが発生する任意の状況に当てはまる。
【０００３】
本発明はデータベース技術をこれらの関心事に導入する。本発明において、データベース・システムのデータ・モデルは、無関係である。また、データベース・システムはディスク上の持続データを管理してもよいし、主メモリ内のデータ、すなわち主メモリ・データベースを管理してもよい。それにも関わらず、ここでは依然として、リレーショナル・データベース・システムの用語が、単純化及び明瞭化のために使用される。
【０００４】
一般に、メッセージ・ブローカは、複数のメッセージ・ソースｍから複数のメッセージ・シンクｎに、ｍ／ｎなる関係において、メッセージが頻繁に、そして時に定期的に送信される状況において適用される機器である。そこでは１：ｍ及びｎ：１の特殊なケースも発生する。ソースは１つのメッセージだけを送信する必要があり、メッセージ・ブローカはそのメッセージの１つまたは複数のバージョンを１つ以上のシンクに配信するように、メッセージを'共有'する。ここでソースはしばしば任意の種類のプログラム・アプリケーションであり、シンクもまたしばしばアプリケーションである。メッセージ・ブローカ・システムの詳細については、R.Schulteによる"Message Brokers: A focused approach toapplication integration"、Gartner Group、Strategic Analysis Report SSAR-401-102、1996で見い出される。
【０００５】
より詳細には、メッセージ・ブローカはハブに似ており、そこにメッセージが入出力する。ブローカに入力するメッセージは、以下では発行される（published）と称され、ブローカから出力するメッセージは、購読される（subscribed）と称される。購読要求は、特定のアプリケーションが関心を寄せる全ての入来メッセージのサブセット、及びそれが購読者に提供されるときの形式を指定する。
【０００６】
例えば、様々な証券取引所が株式データを定期的に発行する。すなわち、株式データがメッセージ・ブローカに送信される。各証券取引所は異なる形式を用いて、そのデータを転送し得る。購読者は、例えば１０３ドルを超えるＩＢＭ（登録商標）株式データに関する全てのメッセージに登録しており、その配信をＸＭＬ形式で要求する。
【０００７】
発行／購読機能を提供する最新のメッセージ・ブローカでは、発行メッセージ及び購読を管理するために、多大な努力が払われている。この管理は一般に、自前の機構を用いることにより実行される。本発明はオブジェクト・リレーショナル・データベース技術を用いて、発行／購読機能を実現することを提案するものである。
【０００８】
最新のメッセージ・ブローカは一般に、発行されるメッセージ、及び購読者が知りたいメッセージを扱う。しかしながら、購読者は発行されるメッセージだけに関心がある訳ではなく、１つ以上のデータベース内の１つ以上のテーブルに記憶されるデータに対する変更にも関心があるかもしれない。本発明はオブジェクト・リレーショナル・データベース技術にもとづき、この機能の実現を可能にする。
【０００９】
従って、この大量のプログラミング、及びカストマイズの労力を軽減することが望ましい。前述の従来技術の引例は、メッセージ仲介のための基礎として使用されるデータベース技術の有用性を分析しようとする。しかしながら、結論的には、データベース・システムはメッセージ仲介のために必要な多くの機構、すなわちインタフェース・エンジン及びメッセージ・スイッチなどの、仲介を実行するために設計されたミドルウェアを欠く。従って、前述の引例においては、メッセージ仲介のための基礎としてのデータベース技術は、実現が余りに困難且つ複雑であり、性能的に遅いために、多かれ少なかれ拒絶されることになる。
【００１０】
データベース指向ビューを用いて、発行／購読技術の振舞いを分析するとき、次の所見が述べられる。すなわち、購読要求は照会に類似する。購読要求内で指定された内容にもとづき、メッセージはフィルタリングされて、その受信者に配信される。しかしながら、照会と購読との間には、基本的な動作上の違いが存在する。すなわち、購読は１度に、例えばメッセージ・ウェアハウスに記憶される全てのメッセージには作用せず、１つのメッセージにだけ、すなわちメッセージ・ブローカに丁度発行されたメッセージにだけ作用する。更に、一般に多くの購読がメッセージ・ブローカに登録される。すなわち、購読を照会と同一視すると、多くの照会が１つのメッセージに対して評価されなければならない状況となる。すなわち、この状況は、一般に照会システムにおいて見い出される状況、すなわち検査されるデータ項目の数が照会の数を大幅に上回る状況と逆になる。
【００１１】
発行／購読技術のために、オブジェクト・リレーショナル・データベース技術を使用する本発明の提案は、解決されなければならない２つの問題点に直面する。
【００１２】
第１は、発行に関連する操作データを効率的に識別する方法であり、第２は、外部化（externalized）データベース技術にもとづき、購読を効率的に実行する方法である。
【００１３】
第１の問題点は、ほとんどのメッセージ・ブローカがデータベース技術にもとづいて実現されておらず、また管理に関する企業データが普通に必要とされる事業環境において、例えば操作データの特定の変更が、しばしば外部アプリケーションにとって関連のある事象と見なされる事実に由来する。これが図１に示される。
【００１４】
例えば、新たなタプル（tuple）がテーブルに挿入される場合、ある人はこの事実に関して、対応する電子メールを介して知らされることを希望したり、或いはこのためにアプリケーションが呼び出されなければならなかったり、代わりにメッセージ・ブローカがこのデータを獲得したい購読者を有したりする。従って、データベースは発行のためのソースと見なされ得る。
【００１５】
特に、メッセージ・ブローカが、操作データの変化に対する購読要求を管理するために使用され、従って、操作データの変化がメッセージ・ブローカに発行される必要がある場合、発行の事前フィルタリングの重要性は明らかである。操作データの非常に多数の変化の各々が、メッセージ・ブローカにプッシュされ、ブローカが主題変化に関わる購読者が存在するか否かを判断する場合、たくさんのデータが不必要に処理され得る。これは資源の浪費である。従って、データベース・システム内に購読機能を提供することが、一般に便利である。
【００１６】
或いは、データベース・システムにおいて元来提供される購読機構を有さない場合、変更データはメッセージに変換されて、次に別々のメッセージ・ブローカに送信、すなわち発行されなければならない。そして、このメッセージ・ブローカが、全ての対応する購読者を決定しなければならない。このアプローチでは、データベースは単に発行者と見なされ、メッセージ・ブローカの購読エンジンが、任意の購読者が変更データに関心があるか否かを決定するために使用される。
【００１７】
どの購読者も、データベース・システムとメッセージ・ブローカ間の、関連するデータ変換などを含むこのデータ通信に関心がない場合、多くの作業及びトラフィックが無駄に実行され、不要な負荷を環境全体に課することになる。更に、別々の購読エンジンの使用は次の事実、すなわち別々のメッセージ・ブローカ・エンジンを必要とすることなく、データベース・システムの照会機能が購読を直接処理するために即時使用され得る。従って、効率を一層改善する事実を無視するものである。
【００１８】
第２の問題は、データベース技術そのものにもとづき、購読を実現する効率を取り扱う。今日、ほとんど全てのリレーショナル・データベース・システムが、トリガ機構をサポートする。トリガは、データの関連変更に関する登録済みの関心にもとづき、アクションを自動的に実行することを可能にする。トリガと購読の間の'自然の'適合を認識する、すなわち、各購読要求を対応するトリガに単にマップする提案が存在するものと思われる。
【００１９】
例えば、株式テーブルが会社名、その実際の株価、及び取引量を報告する行を含むものと仮定する。この時、変更された株式データの各購読が、このテーブル内の別々のトリガにマップされる。図２を参照すると、特定の購読のマッピング例が示される。Ｓ（Ｔ）人の購読者（ここでＴは'テーブル'の略語）が、所与のテーブルＴ上の変更に登録しており、１秒当たりｎ（Ｔ）の変更がこのテーブル上で発生する場合、テーブルＴに対して、１秒当たりＳ（Ｔ）×ｎ（Ｔ）のトリガが実行されなければならない。実際、２つ以上のテーブルが購読の対象となり得るので、この数は更に多くなる。株式テーブル上で１秒当たり１０の変更が発生し、１００の購読が存在する場合（これらは非常に適度な数と見なされる）、１０００のトリガがこの１つのテーブルに対して実行されなければならない。これは現データベース技術の範囲から逸脱している。
【００２０】
【発明が解決しようとする課題】
従って、本発明の目的は、通知、特に購読のために、データベース技術を効率的に使用する方法及びシステムを提供することである。
【００２１】
【課題を解決するための手段】
本発明のこれらの目的が、開示される独立クレームで述べられる機構により達成される。更に本発明の別の有利な構成及び実施例が、それぞれの従属クレームで述べられる。
【００２２】
本発明は一般に、購読の処理のために、アクティブ・データベース技術及び拡張可能データベース技術、すなわちトリガ及びユーザ定義機能を効率的に利用する方法を教示する。
【００２３】
本発明の第１の態様によれば、特定のテーブル上の、またはより一般的には複数のテーブル上の全ての購読を、それぞれこのテーブルまたはこれらのテーブル上の１つのトリガに統合するように提案される。これによりトリガ・ベースの効率が劇的に改善される。
【００２４】
本発明の第２の態様によれば、データベース・システムにより提供されるユーザ定義機能の設備を利用することにより、購読者が登録済みの情報を配信するように提案される。これは購読者に送信される情報の作成を、データベース・システムが実行中のアドレス空間から可能にし、このことが効率改善の別の根拠となる。
【００２５】
処理全体は、次のように要約される。すなわち、テーブルＴに対する最初の購読が登録されるとき、テーブルＴ上でこの種の"統合購読トリガ"が作成されて、テーブルＴに関する全ての購読を保持するのに好適な、いわゆるメタデータ・テーブルの集まりが作成される。これは図３に示されるように、イネーブル・テーブルと呼ばれる。この機能はまた、例えば管理者により呼び出される別個のユーティリティとして、明示的に実現され得る。
【００２６】
好適なメタデータ・テーブルを作成し、統合購読トリガを生成する好適な実施例について、以下で詳述する。
【００２７】
単一の購読の各々は、単にこれらの後者のメタデータ・テーブルに、適切なタプルを挿入することにより反映される。すなわち、本発明によれば、別々のトリガは生成されず、単一の購読トリガに変更が加えられる必要はない。
【００２８】
関連するメタデータ・テーブル内に、タプルとして購読を反映する好適な実施例について述べる。通常の従来型のメッセージ・ブローカにおける発行に対応して、タプルがテーブルＴ内で操作されるとき、対応するトリガが発生し、単一の呼び出しにおいて、操作されるタプルと、テーブルＴに関する全ての購読を保持するメタデータ・テーブルの集合とを参照する照会により、当該タプルの変更に関心を持つ全ての購読者を決定する。
【００２９】
単一の購読トリガにより、データベース・システムのトリガ機構を望み通り効率的に使用することは価値がある。すなわち、トリガ本体内の照会は、より複雑であるに違いないからである。なぜなら、それは関連する集合メタデータ・テーブル内で、基本的に全ての潜在的な購読者を探索しなければならないからである。本発明では、テーブルＴに関する購読要求をメタデータ・テーブルの集合内に各々論理和標準形で記憶する。メタデータ・テーブルの集合は、データベース・テーブルＴの属性に適用可能な比較演算子のうち購読要求においてサポートされる比較演算子の集合に対応し、各メタデータ・テーブルは異なる比較演算子に関連付けられる。本発明の実施例によれば、照会は少なくともｎウェイ結合を含み得る。ここでｎはターゲット・テーブルに対して、購読フィルタ内でサポートされる比較演算子の数である。しかしながら、実際上、照会システムは数１０年来、ｎウェイ結合を非常に効率的に実行するように、最適化されてきた。なお、論理和標準形で指定される購読要求の各等位項は、各メタデータ・テーブル内の正しく１つのタプルに対応し、各メタデータ・テーブル内の各タプルの各要素は、当該メタデータ・テーブルに関連付けられた比較演算子と当該タプルに対応する購読要求の等位項に現れるアトミック表現式とに基づいて決定される値を有している。
【００３０】
データベース・トリガにより開始される通知に関連して、本発明の概念はこの点で非常に一般的であると言える。通知は例えば、メッセージング・システムの意味において、メッセージが送信されたり、アクションがオブジェクト・サーバ上で管理されるオブジェクトに対して実行されたり、或いは電子メールが購読者に送信されることを意味する。通知は各購読者のために保持されるテーブルにも挿入されて、購読者がテーブルを照会することにより、適切な通知を検索することを可能にする。
【００３１】
前述の本発明の第２の態様に関連して、資格のある各購読者に送信される通知の実際の構成は、いわゆるユーザ定義機能（ここではＵＤＦとも呼ぶ）にもとづき達成される。すなわち、トリガ本体内の照会のフィルタが、資格のある購読者を決定する一方、照会のセレクト節が、各購読者への通知の配信を開始するユーザ定義機能を参照する。この配信ＵＤＦは資格のある各購読者に対して、データベース・システムにより、自動的に呼び出される。配信機能は、通知を構成するために必要な全てのデータ、例えばトリガの発生を生じた変更されたタプルの関連値や、受信者のアドレスなどを獲得する。またこれらは追加の結合を要求し得る。受け渡されたこのデータにもとづき、配信機能は通知を構成し、それをＭＱＳeriesのようなメッセージ照会システムや、電子メールなどを介して、受信者アドレスに送信する。配信ＵＤＦの好適な実施例については、以下で詳述する。
【００３２】
利点として、本発明は既存のデータベース機能に加えて、効率的な購読機構を構築することを可能にする。変更がデータベース・システムに加えられる必要は全くない。従って、本発明は標準のオブジェクト・リレーショナル・データベース・システムをそのまま使用して、発行／購読エンジンを実現することを可能にする。更に、ここで述べられる購読機構は、データベースを容易にメッセージの発行者に変じることを可能にする。
【００３３】
【発明の実施の形態】
好適な実施例の概論本発明の好適な実施例の要素について述べる前に、購読フィルタＰが論理和標準形（disjunct normalform）で指定されるものと仮定する。これは一般性を欠くものではない。なぜなら、各フィルタがこの形式に変換され得ること、及びその方法がよく知られているからである。
【００３４】
従って、購読フィルタＰはＰ＝Ｂ 1∨．．．∨Ｂkと記述され、ここで各Ｂjは次の形式を取る。
【数１】
Ｂj＝（Ａj1〜j1ｖj1∧．．．∧Ａjnj〜jnjｖjnj）
【００３５】
こうした表現式では、Ａjiは購読に対応するテーブルの属性であり、〜ijはＡjiのドメインに適用可能な比較演算子（例えば＞，≧，＜，≦，＝，≠，LIKE，．．．）である。またｖjiはＡjiのドメインからの値である。要するに、購読フィルタは次の形式を有する。
【数２】
Ｐ＝（Ａ11〜11ｖ11∧．．．∧Ａ1n1〜1n1ｖ 1n1）∨．．．∨（Ａk1〜k1ｖk1∧．．．∧Ａknk〜knk ｖknk）
【００３６】
購読を保持するために使用されるメタデータ・テーブルの実施例に従い、フィルタの構造に対して、更に別の制限が適用され得る。例えば、後述の実施例は、各等位項（conjunct）Ｂj＝（Ａj1〜j1ｖ j1∧．．．∧Ａjnj〜jnjｖjnj）内において、属性が特定の比較演算子と共に高々１度現れることを想定する。すなわち、
【数３】
∀１≦ｊ≦ｋ∀１≦ｘ,ｙ≦ｎj：Ａjx＝Ａjy∧ 〜jx⇒ｖjx＝ｖjy
【００３７】
図４を参照すると、テーブルＴ＝｛Ａ1，．．．，Ａq｝が購読のためにイネーブルされるとき、このテーブル上の全ての購読を保持するメタデータ・テーブルの集まりがセットアップされる。これらのメタデータ・テーブルの様々な代案が存在することが明らかであるが、本発明の基本的なアプローチは任意の特定の構造を想定しない。明瞭化のために、必要なメタデータ・テーブルを導出するために、次の処理が提案される。
【００３８】
イネーブル・テーブル機構が、例えばデータベース・ユーティリティまたは新たなＳＱＬ ＤＤＬ要素として提供され、イネーブルされるテーブルの名前Ｔを、購読においてサポートされる比較演算子｛〜1，．．．，〜m｝のリストと共に受諾する。新たに生成されるタプルに加え、タプルの更新または消去が発行として扱われる場合、別のパラメータがこの指定を可能にする。この入力にもとづき、イネーブル・テーブル要求は統合購読トリガの他に、メタデータ・テーブルの集まりを生成する。下記にイネーブル・テーブル要求の構文例を示す。
【数４】
ENABLE TABLE table-name,[list-of-comparisons],[list-of-triggering-pubs]
【００３９】
イネーブル・テーブル要求が実行されるときに発生する処理の実施例は、比較演算子のリスト内で指定される各比較演算子〜∈｛〜1，．．．，〜m｝に対して、テーブルＴ-〜＝｛購読者，Ａ1，．．．，Ａq，ANDID｝を作成する。テーブルＴ-〜は、購読フィルタの等位項の様々なアトミック表現式を反映するタプルを保持するために使用され、図５に関連して後述される。
【００４０】
この実施例で生成されるトリガは、図６に関連して詳述される。
【００４１】
図４を参照すると、購読のために、Stock ＝｛銘柄，価格，取引量｝へのタプルの挿入が、イネーブル・テーブル要求ENABLETABLE Stock,[EQ,NE,GT,L T],[INSERT]を介して可能になる。ここでＥＱは"equal"，ＮＥは"notequal"などを表す。図４は、この要求により生成されるメタデータ・テーブルStock-EQ，Stock-NE，Stock-GT，Stock-LTを示す。
【００４２】
図５を参照すると、購読が詳細に示され、またそれらがメタデータ・テーブル内の前述のタプルにマップされる様子が示される。
【００４３】
テーブルＴ＝｛Ａ1，．．．，Ａq｝のための購読フィルタは、次のように、図４の実施例のメタデータ・テーブルＴ-〜1，．．．，Ｔ-〜m内のタプルとして反映される。
【００４４】
購読者Ｓの購読要求のフィルタＰ＝Ｂ 1∨．．．∨Ｂkの各等位項Ｂj＝（Ａj1〜j1ｖj1∧．．．∧Ａjnj〜jnjｖjnj）は、各テーブルＴ- 〜1，．．．，Ｔ-〜m内の正しく１つのタプルに対応する。各テーブルＴ-〜iのカラムAND_IDは、整数値ｊを保持し、カラム購読者は値'Ｓ'（すなわち購読者に関する要求情報の固有の参照）を保持する。
【００４５】
各比較演算子〜iに対して、等位項Ｂj内に現れる全てのアトミック表現式Ａjp〜jpｖjpが決定され、ここで〜jp＝〜iである。
【００４６】
テーブルＴ-〜iの対応するカラムＡjpは、値ｖjpにセットされる。Ｂj内において、比較演算子〜i を有するアトミック表現式内に現れない属性Ａに対して、Ｂjに対応するＴ-〜i内のタプル内のＡの値がNULL にセットされる。
【００４７】
購読者Ｓのための購読フィルタの等位項Ｂ jが、比較演算子〜iを有するアトミック表現式を含まない場合、テーブルＴ-〜iはこの事実を反映するタプル（'Ｓ'，NULL，．．，NULL）を保持する。各購読フィルタＰ＝Ｂ1∨．．．∨Ｂkは、各メタデータ・テーブルＴ-〜1，．．．，Ｔ-〜m内に、正しくｋ個のタプルを生じる。
【００４８】
図６を参照すると、購読フィルタの例の集まりが示され、またそれらの各々が図４の実施例のメタデータ・テーブル内のタプルとして表される様子が示される。尚、図６では、Stock-EQ及びStock-GTメタデータ・テーブルだけが模範的に示される。
【００４９】
４人の購読者Frank、Peter、Don及びJanet が存在する。詳細には、購読者Frankは銘柄＝'ＩＢＭ'
を有する株式タプルに関心がある。購読フィルタは１つの等位項を含み、従って各メタデータ・テーブル内の１つのタプルが、このフィルタにマップされる。購読フィルタ内のどの表現式もＧＴ演算子（"＞"）を含まないので、タプル（'Frank'，NULL，NULL，NULL，1）がStock-GTに挿入される。比較演算子"＝"を有する等位項内に現れるStockからの属性は、銘柄だけである。すなわち、Stock-EQ内の結果のタプルは、（'Frank'，'IBM'，NULL，NULL，1）となる。
【００５０】
PeterはＩＢＭに関する株式情報を購読したが、株価が２００ドルを越える場合に限る。再度、このフィルタは１つの等位項を含む。すなわち、フィルタを表すのに、各メタデータ・テーブル内の１つのタプルで足りる。"＝"比較を含む唯一のアトミック表現式は"銘柄＝'ＩＢＭ'"であり、Stock-EQ内の対応するタプルは、（'Peter'，'IBM'，NULL，NULL，1）である。フィルタの１つの属性は、"＞"比較に関わり、すなわち属性"価格"に関して、価格＞２００である。この結果、Stock-GT内において、次のタプルすなわち（'Peter'，NULL，NULL，200，1）が生成される。DonはＩＢＭに関する株式情報を購読したが、株価が１９０ドルを越え、取引量が１００株より大きい場合に限る。再度、このフィルタは１つの等位項を含み、すなわちフィルタを表すのに、各メタデータ・テーブル内の１つのタプルで足りる。"＝"比較を含む唯一のアトミック表現式は"銘柄＝'ＩＢＭ'"であり、すなわちStock-EQ内の対応するタプルは、（'Don'，'IBM'，NULL，NULL，1）である。フィルタの２つの属性は"＞"比較に関わり、すなわち属性"価格"及び"取引量"に関して、価格＞１９０及び取引量＞２００である。この結果、Stock-GT内において、次のタプルすなわち（'Don'，NULL，190，200，1）が生成される。
【００５１】
Janetのフィルタは２つの等位項を含み、すなわち"銘柄＝'ＩＢＭ'且つ価格＞２００"及び"銘柄＝'ＳＡＰ'且つ価格＞１０００且つ取引量＞５００"である。第１の等位項はStock-EQテーブル内に、（'Janet'，'IBM'，NULL，NULL，1）を生成し、Stock-GTテーブル内に、（'Janet'，NULL，200，NULL，1）を生成する。第２の等位項は、Stock-EQ及びStock-GTテーブル内に、それぞれ（'Janet'，'SAP'，NULL，NULL，2）及び（'Janet'，NULL，1000，500，2）を生成する。
【００５２】
図７を参照して、購読トリガの生成に関して詳述する。図７は、本実施例にもとづき、株式（Stock）において、イネーブル・テーブル要求により生成されるトリガを示す。
【００５３】
トリガ本体はセレクト文を含み、これは図４及び図５に関連してそれぞれ前述したように、メタデータ・テーブルを生成し、これらのメタデータ・テーブル内において購読を表す実施例に対応する。
【００５４】
リレーショナル・データベース・システムによるこの文自体の処理は、よく知られており、本発明には無関係であるので、ここでは説明を省略する。
【００５５】
図８を参照して、本発明の第２の好適な態様、すなわちメッセージの配信のためのユーザ定義機能（ＵＤＦ）の使用について述べる。
【００５６】
テーブルＴ上の購読を反映するメタデータ・テーブルの特定の実施例とは独立に、本発明により提案される統合トリガは、図８に示される次の構造を有する。
【００５７】
発行として扱われるべきテーブルＴからの各変更のタイプ、すなわちタプルの挿入、消去、更新に対して、別々のトリガが生成される。
【００５８】
このトリガは、対応する変更がテーブルＴ上で実行されるとき常に発生される。（図８に１として示されるアイテムを参照）。
【００５９】
トリガが発生すると、基礎となるデータベース・システムがトリガの本体、すなわち図７に示されるケースではセレクト文を実行する。セレクト文のfrom -及びwhere-節は、メタデータ・テーブから、資格のある全ての購読者をフィルタリングする（図８のアイテム２を参照）。ここで具体的なfrom-及びwhere-節は、メタデータ・テーブルの特定の構造に依存する。
【００６０】
資格のある購読者の各々に対して、セレクト節内で指定されるdeliver-ＵＤＦが呼び出される（図８のアイテム３を参照）。ここで計算された結合からの任意のカラム値、すなわち特に購読者識別子が、パラメータとしてＵＤＦに渡される。
【００６１】
deliver-ＵＤＦは、図８のアイテム４で示されるように、各購読者の購読要求に従い、各購読者を処理し、このことはしばしば、購読応答をターゲット・ユーザ・キューに待ち行列化することを意味する。
【００６２】
deliver-ＵＤＦの多数の実施例が存在することが明らかである。例えば、１実施例は、新たに作成されたタプルをメッセージとして、購読者の特定のターゲット・キューに配信する。この目的のために、メタデータ・テーブルは各購読者のターゲット・キュー名を含む。このキュー名は完全な新たなタプルと共に、パラメータとしてdeliver-ＵＤＦに渡される。ＵＤＦはタプルからメッセージを構成し、基礎となるメッセージング・システム（例えばＭＱＳeries）のＰＵＴ要求を呼び出し、メッセージを購読者のキューに転送する。
【００６３】
別の実施例は、購読者識別子及び変更されたタプルの識別子を、システム特定の内部キューに配信する。定期的に、このキューは別々のプログラムにより処理され、プログラムは変更されたタプルを検索し、それらを購読者の宛先キューに提示する。
【００６４】
このアプローチの興味深い応用例は、データ・ウェアハウス環境における変更データの定期的な複製である。すなわち、購読者はその環境内の選択データの様々なコピーであり、購読フィルタは操作データのローカル・サブセットとして、関心の対象となるデータを表す。
【００６５】
別の実施例は、タプルを例えばＸＭＬストリームとして、各購読者に対して保持されるテーブル内に挿入する。これは購読者がこのテーブルを照会し、購読結果を獲得することを可能にする。
【００６６】
本発明の主な利点は、データベース・システムにより外部化（externalize）される機能を用いて、発行／購読エンジンを実現する効率的な方法を教示することである。例えば、所与のデータベース・エンジン自体を変更することにより、データベース・システム内から発行／購読エンジンを実現する、より効率的な方法が存在し得ることが主張される。
【００６７】
しかしながら、こうした実現は、特定のデータベース・エンジンのベンダにより実行されなければならない。多くのベンダが発行／購読ソルーションに近づきつつあり、複数のベンダが最近、Ｊａｖａ（登録商標）主導の下で、発行／購読インタフェースを標準化したので、データベース・エンジンに加え、効率的な実施例がたくさんの関心を集めるものと期待される。
【００６８】
前述の議論では、本発明は特定の典型的な実施例に関連して述べられた。しかしながら、本発明の趣旨及び範囲から逸れることなく、様々な変更及び変形が可能であることが明らかである。従って、前述の議論及び図面は、限定的な意味で掲げられたものではなく、例証的なものである。
【００６９】
例えば、配信機能は単に、資格のある購読者及び生成されるタプルに関する最低限の情報を、例えばその基本キーとして、別々のキューに転送する。このキューから、別のプログラムが第２のステップにおいて、資格のある購読者に配信されるメッセージを構成する。このプログラムはこのキュー入力にもとづき、購読者のリストを編成し、リストを記憶済みのプロシージャに受け渡す。すると、このプロシージャがメッセージをより効率的に構成し、実際にそれを購読者に配信する。
【００７０】
メッセージ・ブローカは一般に、発行された、すなわち新たに作成されたメッセージを処理する。従って、トリガの挿入が、この状況を捕獲する上で十分である。しかしながら、本発明で述べたリレーショナル・データベース技術上で構築された通知エンジンは、更新または消去されたデータすなわちメッセージも容易に処理することができる。新たなタプルが挿入されるときに発生する購読トリガを生成する代わりに、テーブル上の更新または消去による変更時に発生する同一の購読トリガが生成され得る。
【００７１】
更に、本発明の概念は任意のデータ保持システムに適用され得て、これは必ずしもオブジェクト・リレーショナル・データベースのように構成される必要はない。従って、用語'データベース'は、非常に一般的な意味において使用されるべきである。
【図面の簡単な説明】
【図１】本発明に従い発行者の役割を演じるデータベースの概略図である。
【図２】本発明に従い、購読をトリガにマップするＳＱＬコード例を示す図である。
【図３】本発明に従い、１テーブルにつき１購読トリガをセットアップし、使用する様子を示す概略図である。
【図４】本発明に従うメタ・テーブルの例を示す図である。
【図５】本発明に従い、購読をメタデータ・テーブル内のタプルにマップする様子を示す概略図である。
【図６】本発明に従い、購読をメタデータ・テーブル内のタプルにマップするテーブルの例の概略図である。
【図７】本発明に従う好適な購読トリガを示すＳＱＬコード例を示す図である。
【図８】本発明に従う統合トリガにおいて、配信ユーザ定義機能ＵＤＦの役割を示す概略図である。
【図１】
0003996328.tif 000002
【図２】
0003996328.tif 000003
【図３】
0003996328.tif 000004
【図４】
0003996328.tif 000005
【図５】
0003996328.tif 000006
【図６】
0003996328.tif 000007
【図７】
0003996328.tif 000008
【図８】
0003996328.tif 000009