JP2016500168A - アーカイブされたリレーションを有する連続クエリの管理 - Google Patents

Abstract

アーカイブされたリレーションを有する連続クエリを管理する技術が提供される。いくつかの例において、少なくともデータストリームを含むクエリを識別し得る。加えて、履歴データの少なくとも一部を用いてクエリを初期化し得る。さらに、いくつかの例において、データストリームおよび履歴データの少なくとも一部に少なくとも一部基づいてクエリを評価し得る。

Description

関連出願の相互参照
本願は、２０１３年３月１４日に出願され「Managing Continuous Queries with Archived Relations（アーカイブされたリレーションを有する連続クエリの管理）」と題された米国特許出願第１３／８２９，９５８号（代理人整理番号８８３２５−８５９８１３（１２８０１０ＵＳ））、２０１３年３月１４日に出願され「Configurable Data Windows for Archived Relations（アーカイブされたリレーションのための構成可能なデータウィンドウ）」と題された米国特許出願第１３／８３０，１２９号（代理人整理番号８８３２５−８５９８１４（１２８０２０ＵＳ））、および、２０１２年９月２８日に出願され「Real Time Business Event Analysis and Monitoring（リアルタイムビジネスイベント分析およびモニタリング）」と題された米国仮出願第６１／７０７，６４１号に基づく優先権と利益を主張し、すべての目的のために各出願の内容全体を本明細書に引用により援用する。

背景
従来のデータベースシステムにおいて、データは、通常はテーブルの形態で１つ以上のデータベースに格納される。格納されたデータはその後、構造化照会言語（ＳＱＬ）等のデータ管理言語を用いてクエリされ操作される。たとえば、ＳＱＬクエリは、データベースに格納されているデータのうちの関連データを識別するために定義し実行することができる。したがって、ＳＱＬクエリは、データベースに格納されている有限集合のデータに対して実行される。さらに、ＳＱＬクエリが実行されるとき、ＳＱＬは有限のデータ集合に対して一度実行されて有限の静的結果をもたらす。このように、データベースは、格納されている有限のデータ集合に対してクエリが実行されるよう最適に作成されている。

しかしながら、数多くの現代のアプリケーションおよびシステムは、データを、有限のデータ集合ではなく連続データまたはイベントストリームの形態で生成する。このようなアプリケーションの例は、センサーデータアプリケーション、財務表示機、ネットワークパフォーマンス測定ツール（たとえば、ネットワークモニタリングおよびトラフィック管理アプリケーション）、クリックストリーム分析ツール、自動車交通モニタリング等を含むが、これらに限定されない。このようなアプリケーションによって、データストリームを処理することが可能な新たな種類のアプリケーションの必要性が生じた。たとえば、温度センサを、温度測定値を発信するように構成することができる。

イベントストリームに基づくこれらの種類のアプリケーションの場合のデータの管理および処理は、時間を強く重視してデータ管理およびクエリ機能を構築することを含む。連続する無限のデータ集合に対する長時間のクエリ実行を含む、異なる種類のクエリ機構が必要である。現在イベントストリーム処理に適した製品一式を提供している販売業者はあるが、これら製品が提供するものは依然として、現代のイベント処理のニーズに対処するのに必要な処理の柔軟性に欠けている。

概要
いくつかの例において、連続クエリの中のアーカイブされたリレーションを管理するためのシステムが提供される。このシステムは、メモリと、このメモリにアクセスし命令を実行することにより、少なくともデータストリームを識別するクエリを識別するように構成された１つ以上のプロセッサとを含み得る。上記命令を実行することにより、履歴データの少なくとも一部を用いて上記クエリを初期化してもよい。加えて、上記命令を実行することにより、上記データストリームおよび上記履歴データの一部に少なくとも一部基づいて上記クエリを評価してもよい。場合によっては、上記クエリは、到来する上記データストリームのリアルタイムデータまたは上記データストリームのアーカイブされたリレーションを処理するように構成された連続クエリを含み得る。上記リアルタイムデータは、少なくともビジネスイベントデータを含み得る。加えて、いくつかの例において、上記データストリームは、ウィンドウを用いて構成されたリレーションを含み得る。ウィンドウは、このウィンドウの中のデータストリームの一部を参照するためのものである。上記ウィンドウは、時間の経過とともにデータストリームに沿って移動するように構成してもよい。いくつかの局面において、上記履歴データは、上記クエリの初期化後のある時点におけるデータストリームに含まれなくてもよい。上記クエリはさらに上記履歴データを識別してもよい。加えて、上記履歴データは、上記クエリの初期化前のある時点におけるデータストリームからのビジネスイベントデータを含み得る。いくつかの局面において、上記クエリを評価することは、クエリの演算子を表わすノードを用いてクエリグラフを少なくとも形成することを含み得る。加えて、上記１つ以上のプロセッサはさらに、上記複数の命令を実行することにより、上記クエリグラフをトポロジーの順序で少なくともトラバースするように構成されてもよい。加えて、上記１つ以上のプロセッサはさらに、上記複数の命令を実行することにより、上記クエリグラフにおいて識別された最下位のステートフル（stateful）演算子における少なくとも履歴データを用いて上記クエリを少なくとも初期化するように構成されてもよい。

加えて、いくつかの例において、コンピュータ読取可能な媒体が提供されてもよい。この媒体は、１つ以上のプロセッサにより実行可能な複数の命令を格納し得る。この命令は、いくつかの例において、データストリームを処理するように構成された連続クエリを受けることを含み得る。この連続クエリは、上記データストリームの識別子および履歴データの識別子のうちの少なくとも一方を含み得る。上記命令はまた、上記連続クエリに少なくとも一部基づいてクエリグラフを生成することを含み得る。いくつかの局面において、上記命令はまた、履歴データの少なくとも一部を用いて上記連続クエリを初期化すること、および／または、上記データストリームに関して上記履歴データに少なくとも一部基づいて上記連続クエリを評価することを含み得る。いくつかの例において、上記データストリームおよび上記履歴データのうちの少なくとも一方を、上記連続クエリのデータ定義言語アノテーション（DDL annotation）によって識別してもよい。加えて、上記データ定義言語アノテーションは、上記履歴データの場所、上記データストリームのソース、上記データストリームに関連するデータオブジェクト、上記連続クエリの処理に関連する動作情報、上記履歴データに対応するデータベースの関連する１つ以上の列、上記連続クエリの出力に対応するデータオブジェクト、および、上記連続クエリの出力を提供するための場所のうちの少なくとも１つを識別してもよい。さらに、上記クエリグラフは、上記連続クエリの演算子を表わす少なくともノードを含んでいてもよく、および／または、上記連続クエリを、上記クエリグラフをトポロジーの順序でトラバースする間に、上記クエリグラフのステートフル演算子における上記履歴データの少なくとも一部を用いて初期化してもよい。これに代えて、上記命令を実施するコンピュータ読取可能なプログラムが提供されてもよい。

さらに、いくつかの例において、方法が提供されてもよい。この方法は、ビジネスイベントデータのストリームを処理するように構成された連続クエリを受けるように構成されてもよく、この連続クエリは、上記ストリームの識別子と上記ストリームに関連する履歴データの識別子とを含み得る。いくつかの局面において、上記方法はまた、上記連続クエリに少なくとも一部基づいてクエリグラフを生成するように構成されてもよい。このクエリグラフは、上記連続クエリの演算子を表わす少なくともノードを含み得る。加えて、上記方法はまた、上記クエリグラフをトラバースして最下位のステートフル演算子を識別するように構成されてもよい。上記方法はまた、上記識別された最下位のステートフル演算子における履歴データの少なくとも一部を用いて上記連続クエリを初期化するように、および／または上記ストリームに関して上記履歴データに少なくとも一部基づいて上記連続クエリを評価するように構成されてもよい。加えて、いくつかの例において、上記履歴データは、上記ストリームの前の時点からのビジネスイベントデータを含み得る。この方法はまた、上記連続クエリの演算子に少なくとも一部基づいて上記連続クエリを初期化するために用いる上記履歴データの最適量を決定するように構成されてもよい。さらに、上記ステートフル演算子は、上記連続クエリの少なくとも１つのノードの評価に少なくとも一部基づいて識別してもよい。

構成可能なデータウィンドウを有するアーカイブされたリレーションがある場合の連続クエリが提供されてもよい。いくつかの例において、システムが提供されてもよく、このシステムは、命令を格納するメモリ、および／または、このメモリにアクセスし命令を実行することにより少なくともデータストリームを識別するクエリを少なくとも識別するように構成されたプロセッサを、含み得る。このシステムはまた、上記命令を実行することにより、構成可能なウィンドウサイズを識別してもよい。加えて、いくつかの例において、このシステムは、上記命令を実行することにより、履歴データの少なくとも一部を用い上記ウィンドウサイズに少なくとも一部基づいて上記クエリを初期化してもよい。さらに、このシステムはまた、上記命令を実行することにより、上記データストリームおよび上記履歴データの一部に少なくとも一部基づいて上記クエリを評価するように構成されてもよい。いくつかの局面において、上記クエリは、到来する上記データストリームのリアルタイムビジネスイベントデータを処理するように構成された連続クエリを含み得る。上記クエリの評価は、上記クエリを、上記データストリームに対して、上記構成可能なウィンドウサイズに少なくとも一部基づいて適用することを含み得る。加えて、いくつかの例において、上記データストリームは、第２のウィンドウの中の上記データストリームの一部を参照するための第２の構成可能なウィンドウサイズを用いて構成されたリレーションを含み得る。上記第２のウィンドウのサイズは、第２の構成可能なウィンドウサイズに少なくとも一部基づく。

加えて、いくつかの例において、上記第２のウィンドウは、時間の経過とともに上記データストリームに沿って移動するように構成してもよい。上記履歴データは、上記クエリの初期化後のある時点においてデータストリームに含まれなくてもよい。また、上記履歴データは、上記クエリの初期化前のある時点におけるデータストリームからのビジネスイベントデータを含み得る。いくつかの例において、上記システムはまた、上記命令を実行することにより、上記クエリを、上記クエリの演算子を表わすノードを用いてクエリグラフを少なくとも形成することにより、少なくとも評価するように構成されてもよい。加えて、上記ノードのうちの少なくとも１つがウィンドウサイズを識別してもよい。さらに、いくつかの局面において、このシステムは、上記命令を実行することにより、上記クエリグラフをソースからトポロジーに従って少なくともトラバースするように構成されてもよい。上記１つ以上のプロセッサはまた、上記命令を実行することにより、上記クエリグラフにおいて識別された最下位のステートフル演算子における少なくとも履歴データを用いて、上記クエリを少なくとも初期化するように構成されてもよい。

加えて、いくつかの例において、コンピュータ読取可能なメモリが提供されてもよい。このメモリは、アーカイブされたリレーションを処理するように構成された連続クエリを受けることを１つ以上のプロセッサに行なわせる命令を格納するように構成されてもよい。この連続クエリは、データストリームの識別子および履歴データの識別子のうちの少なくとも一方を含む。また、上記命令により、上記連続クエリに少なくとも一部基づいてクエリグラフを生成することを上記プロセッサに行なわせてもよい。加えて、いくつかの例において、上記命令により、上記アーカイブされたリレーションに関連するエンティティからウィンドウサイズを受けることを上記プロセッサに行なわせてもよい。いくつかの局面において、上記命令により、履歴データの少なくとも一部を用いて上記連続クエリを初期化することを上記プロセッサに行なわせてもよい。さらに、いくつかの例において、上記命令により、上記連続クエリを、上記アーカイブされたリレーションおよびウィンドウサイズに関して、クエリグラフに少なくとも一部基づいて評価することを、上記１つ以上のプロセッサに行なわせてもよい。上記アーカイブされたリレーションは、上記履歴データに少なくとも一部基づいていてもよい。いくつかの局面において、上記アーカイブされたリレーションおよび上記履歴データのうちの少なくとも一方を、上記連続クエリのデータ定義言語アノテーションによって識別してもよい。このデータ定義言語アノテーションは、上記履歴データの場所、上記アーカイブされたリレーションのソース、上記アーカイブされたリレーションに関連するデータオブジェクト、上記連続クエリの処理に関連する動作情報、上記履歴データに対応するデータベースの関連する１つ以上の列、上記連続クエリの出力に対応するデータオブジェクト、および、上記連続クエリの出力を与える場所のうちの少なくとも１つを識別してもよい。加えて、いくつかの例において、上記複数の命令はさらに、ウィンドウサイズに少なくとも一部基づいて上記連続クエリを初期化するために用いる履歴データの量を決定することを、上記１つ以上のプロセッサに行なわせる命令を含み得る。さらに、上記連続クエリを、上記クエリグラフを上記クエリグラフのソースからトポロジーに従ってトラバースする間に上記クエリグラフのステートフル演算子における上記履歴データの少なくとも一部を用いて初期化してもよい。

さらに、いくつかの例において、コンピュータにより実装可能な方法が提供されてもよい。この方法は、ビジネスイベントデータに関連するアーカイブされたリレーションを処理するように構成された連続クエリを受けるように構成されてもよく、この連続クエリは、上記アーカイブされたリレーションの識別子と上記ストリームに関連する履歴データの識別子とを含む。加えて、この方法は、処理するアーカイブされたリレーションの有界範囲を識別するように構成されたウィンドウサイズを受けるように構成されてもよい。この方法はまた、上記連続クエリに少なくとも一部基づいてクエリグラフを生成するように構成されてもよく、このクエリグラフは、上記連続クエリの演算子を表わす少なくともノードを含む。加えて、いくつかの局面において、この方法は、上記クエリグラフをこのクエリグラフのソースノードからトポロジーに従ってトラバースすることにより、ステートフル演算子を識別するように構成されてもよい。この方法はまた、上記連続クエリを、上記識別されたステートフル演算子における履歴データの少なくとも一部を用いて初期化するように、および／または、上記連続クエリを、上記アーカイブされたリレーションに関して、ウィンドウサイズに少なくとも一部基づいて評価するように構成されてもよい。いくつかの局面において、上記履歴データは、上記連続クエリの初期化よりも前の、上記アーカイブされたリレーションのある時点からのビジネスイベントデータを含み得る。加えて、いくつかの局面において、この方法はまた、上記連続クエリの演算子に少なくとも一部基づいて上記連続クエリを初期化するために用いる上記履歴データの最適量を決定するように構成されてもよい。さらに、この方法はまた、ウィンドウサイズに少なくとも一部基づいて上記連続クエリを初期化するために用いる上記履歴データの最適量を決定するように構成されてもよい。

少なくとも１つの例に従うと、システムは、少なくともデータストリームを識別するクエリを識別するための手段と、履歴データの少なくとも一部を用いて上記クエリを初期化するための手段と、データストリームおよび上記履歴データの一部に少なくとも一部基づいて上記クエリを評価するための手段とを含み得る。

ここまで述べてきたことは、以下の明細書、請求項、および添付の図面を参照すると、他の特徴および実施形態とともに、より明らかになるであろう。

添付の図面を参照しながら詳細な説明を行なう。図面において、参照番号の左端の桁は、その参照番号が最初に示されている図面の番号である。異なる図面で使用される同一の参照番号は、同様または同一のアイテムを示す。

少なくとも１つの例に従うアーカイブされたリレーションを有する連続クエリを管理するためのアーキテクチャの一例を示す簡略ブロック図である。 少なくとも１つの例に従う本明細書に記載のアーカイブされたリレーションを有する連続クエリの管理の少なくともいくつかの特徴を示す簡略ブロック図である。 少なくとも１つの例に従う本明細書に記載のアーカイブされたリレーションを有する連続クエリの管理の少なくともいくつかの他の特徴を示す簡略ブロック図である。 少なくとも１つの例に従う本明細書に記載のアーカイブされたリレーションを有する連続クエリの管理の少なくともいくつかの他の特徴を示す簡略ブロック図である。 少なくとも１つの例に従う本明細書に記載のアーカイブされたリレーションを有する連続クエリの管理の少なくともいくつかの他の特徴を示す簡略ブロック図である。 少なくとも１つの例に従う本明細書に記載のアーカイブされたリレーションを有する連続クエリの管理の少なくともいくつかの特徴を示す簡略プロセスフローである。 少なくとも１つの例に従う本明細書に記載のアーカイブされたリレーションを有する連続クエリの管理の少なくともいくつかの特徴を示す別の簡略プロセスフローである。 少なくとも１つの例に従う本明細書に記載のアーカイブされたリレーションを有する連続クエリの管理の少なくともいくつかの特徴を示す別の簡略プロセスフローである。 少なくとも１つの例に従う本明細書に記載のアーカイブされたリレーションを有する連続クエリの管理の少なくともいくつかの特徴を示す別の簡略プロセスフローである。 少なくとも１つの例に従う本明細書に記載のアーカイブされたリレーションを有する連続クエリの管理の少なくともいくつかの特徴を示す別の簡略プロセスフローである。 少なくとも１つの例に従う本明細書に記載のアーカイブされたリレーションを有する連続クエリの管理の少なくともいくつかの特徴を示す別の簡略プロセスフローである。 少なくとも１つの例に従う本明細書に記載のアーカイブされたリレーションを有する連続クエリの管理の少なくともいくつかの特徴を示す別の簡略プロセスフローである。 少なくとも１つの例に従う本明細書に記載のアーカイブされたリレーションを有する連続クエリの管理の少なくともいくつかの特徴を示す別の簡略プロセスフローである。 少なくとも１つの例に従う本明細書に記載のアーカイブされたリレーションを有する連続クエリの管理の少なくともいくつかの特徴を示す別の簡略プロセスフローである。 少なくとも１つの例に従う本明細書に記載のアーカイブされたリレーションを有する連続クエリを管理する実施形態に従って使用され得るシステム環境の構成要素を示す簡略ブロック図である。 少なくとも１つの例に従う本明細書に記載のアーカイブされたリレーションを有する連続クエリを管理する実施形態に従って使用され得るコンピュータシステムを示す簡略ブロック図である。 少なくとも１つの例に従う本明細書に記載のアーカイブされたリレーションを有する連続クエリの管理の少なくともいくつかの特徴を示す別の簡略プロセスフローである。 少なくとも１つの例に従う本明細書に記載のアーカイブされたリレーションを有する連続クエリの管理の少なくともいくつかの特徴を示す別の簡略プロセスフローである。 少なくとも１つの例に従う本明細書に記載のアーカイブされたリレーションを有する連続クエリの管理の少なくともいくつかの特徴を示す別の簡略プロセスフローである。

詳細な説明
以下の説明では、さまざまな実施形態が説明される。これら実施形態が十分に理解されるよう、特定の構成および詳細事項が説明のために記載される。しかしながら、これらの具体的な詳細事項がなくとも実施形態を実行し得ることも当業者には明らかであろう。さらに、記載されている実施形態が不明瞭にならぬよう、周知の特徴は省略または簡略化される場合がある。

いくつかの例において、１つ以上のアーカイブされたリレーションを有する連続クエリ言語（continuous query language）（ＣＱＬ）クエリ（「クエリステートメント」とも呼ばれる）をサポートする機構を提供し得る。上記アーカイブされたリレーションは、たとえばＣＱＬリレーションを含むがこれに限定されない。これは、作成された時点において空でなくてもよい。たとえば、シナリオによっては、ＣＱＬリレーションを、ストリーム上にウィンドウを適用することによって定義してもよい。言い換えると、リレーションは有界のデータ集合であってもよい。たとえば、あるイベントストリームに対して、リレーションを先ずウィンドウによって定義してもよく、このウィンドウは（たとえばこのウィンドウの中の）ストリームの特定の数の要素またはストリームの特定の集合の要素を含む。しかしながら、リレーションを場合によっては空の状態で作成してもよい。すなわち、ウィンドウを定義してもよいが、リレーションにイベントが含まれていない場合がある。一方、アーカイブされたリレーションは、作成時にイベントデータを含み得る。いくつかの例において、アーカイバ（archiver）または他のデータオブジェクトは、アーカイブされたリレーションの作成において利用されるリアルタイムデータの管理を担当してもよく、および／またはこのデータをアーカイブされたリレーションを生成するかそうでなければ管理するように構成されたエンジンに与えてもよい。

加えて、いくつかの例において、アーカイブされたリレーションを有するＣＱＬクエリをサポートするための機構はまた、アーカイブされたリレーションの特定のデータウィンドウの構成を可能にし得る。これらデータウィンドウは、ユーザによって、管理者によって、またはアーカイブされたリレーションおよび／またはユーザのイベントデータ（たとえばビジネスイベントデータ）に関連するその他のエンティティによって、構成、生成、管理、更新、および／または操作されてもよい。さらに、いくつかの例において、連続クエリの中のアーカイブされたリレーションは、変更通知の見落としおよび／または二重カウントを回避するように実装してもよい。たとえば、クエリを実行するときは、クエリを最初にデータオブジェクト補助記憶装置に対して実行してクエリの現在の状態を確立し、その後、このデータオブジェクトからの変更通知をリッスンし（listen for）処理してもよい。しかしながら、クエリを実装する複合イベント処理（ＣＥＰ）が最初のクエリを実行している間、変更通知が見落とされる場合がある。加えて、変更通知は、変更が最初のクエリに既にある場合は二重カウントされる場合もある。しかし、いくつかの例において、変更通知の見落としおよび／または二重カウントは、最初のクエリの前にリスナー（listener）を確立し、および／またはトランザクション識別子（ＴＩＤ）、コンテキスト識別子（ＣＩＤ）、もしくは変更イベントを管理するための他の機構を利用することによって、回避し得る。

一般的に、連続データストリーム（イベントストリームとも呼ばれる）は、明確な終わりがない連続するまたは本質的に無限であるデータまたはイベントのストリームを含み得る。論理的に、イベントまたはデータストリームは、一連のデータ要素（イベントとも呼ばれる）であってもよく、各データ要素は関連するタイムスタンプを有する。連続イベントストリームは、論理的には要素（ｓ，Ｔ）のバッグ（bag）またはセットで表わすことができ、「ｓ」はデータ部分を表わし「Ｔ」は時間ドメインにある。「ｓ」部分は一般的にタプルまたはイベントと呼ばれる。イベントストリームはしたがってタイムスタンプされた一連のタプルまたはイベントであってもよい。

いくつかの局面において、あるストリーム内のイベントに関連するタイムスタンプは、クロック時間と同等であり得る。しかしながら、他の例において、あるイベントストリーム内のイベントに関連する時間は、アプリケーションドメインによって定義してもよく、クロック時間に対応しなくてもよいが、たとえばその代わりに連続番号によって表わしてもよい。したがって、あるイベントストリーム内のイベントに関連する時間情報は、数字、タイムスタンプ、または時間の概念を表わす他の情報によって表わすことができる。入力イベントストリームを受けるシステムでは、イベントは、タイムスタンプが増す順序でシステムに到着する。同一のタイムスタンプを有する２つ以上のイベントがあってもよい。

いくつかの例において、あるイベントストリーム内のイベントは、世の中の何らかのイベントの発生（たとえば、温度センサの値が新たな値に変化したとき、株式銘柄の価格が変化したとき）を表わしてもよく、このイベントに関連する時間情報が、データストリームイベントによって表わされる上記世の中のイベントが発生した時間を示してもよい。

イベントストリームを介して受けるイベントについては、イベントに関連する時間情報を用いて、イベントストリーム内のイベントが、タイムスタンプの値が増す順序で到着することを保証してもよい。これにより、受けるイベントストリーム内のイベントを、それぞれのイベントに関連する時間情報に基づいて並べることができる。このように並べることを可能にするためには、後で生成されたイベントが、先に生成されたイベントよりも後のタイムスタンプを有するように、タイムスタンプを、イベントストリーム内のイベントと、タイムスタンプが減少しないやり方で関連付ければよい。別の例として、連続番号を時間情報として用いるのであれば、後に生成されたイベントに関連する連続番号を、先に生成されたイベントに関連する連続番号よりも大きくすればよい。いくつかの例において、たとえば、データストリームイベントで表わされる世の中のイベントが同時に発生するときには、複数のイベントを、同一のタイムスタンプまたは連続番号と関連付けてもよい。同一のイベントストリームに属するイベントは通常、関連する時間情報によってイベントに課される順序で処理すればよく、先のイベントは後のイベントよりも前に処理される。

イベントストリーム内のイベントに関連する時間情報（たとえばタイムスタンプ）は、ストリームのソースによって設定されてもよく、その代わりに、このストリームを受けるシステムによって設定されてもよい。たとえば、いくつかの実施形態において、イベントストリームを受けるシステム上でハートビート（heartbeat）を管理してもよく、イベントに関連する時間が、ハートビートによって測定される、システムへのイベントの到着時間に基づいていてもよい。あるイベントストリーム内の２つのイベントが同一の時間情報を有することが起こり得る。なお、タイムスタンプの順序条件は、１つのイベントストリームに特有のものであるが、異なるストリームのそれぞれのイベントは、任意で交互配置してもよい。

イベントストリームには、関連するスキーマ「Ｓ」があり、スキーマは、時間情報と、名前付きの１つ以上の属性からなる一組の属性とを含む。特定のイベントストリームに属するすべてのイベントは、この特定のイベントストリームに関連するスキーマに従う。したがって、イベントストリーム（ｓ，Ｔ）の場合、このイベントストリームは、スキーマ「Ｓ］を、（＜time_stamp＞，＜attribute(s)＞）として有し得る。＜attributes＞は、スキーマのデータ部分を表わし１つ以上の属性を含み得る。たとえば、株式相場表示機のイベントストリームについてのスキーマは、＜株式銘柄＞および＜株価＞という属性を含み得る。このようなストリームを介して受ける各イベントは、１つのタイムスタンプと上記２つの属性とを有する。たとえば、株式相場表示機のイベントストリームは、以下のイベントおよび関連するタイムスタンプを受けることができる。

...
（＜ｔｉｍｅｓｔａｍｐ＿Ｎ＞，＜ＮＶＤＡ，４＞）
（＜ｔｉｍｅｓｔａｍｐ＿Ｎ＋１＞，＜ＯＲＣＬ，６２＞）
（＜ｔｉｍｅｓｔａｍｐ＿Ｎ＋２＞，＜ＰＣＡＲ，３８＞）
（＜ｔｉｍｅｓｔａｍｐ＿Ｎ＋３＞，＜ＳＰＯＴ，５３＞）
（＜ｔｉｍｅｓｔａｍｐ＿Ｎ＋４＞，＜ＰＤＣＯ，４４＞）
（＜ｔｉｍｅｓｔａｍｐ＿Ｎ＋５＞，＜ＰＴＥＮ，５０＞）
...
上記ストリームにおけるストリーム要素（＜ｔｉｍｅｓｔａｍｐ＿Ｎ＋１＞，＜ＯＲＣＬ，６２＞）の場合、イベントは、「stock_symbol」（株式銘柄）および「stock_value」（株価）という属性を有する＜ＯＲＣＬ，６２＞である。このストリーム要素に関連するタイムスタンプは「ｔｉｍｅｓｔａｍｐ＿Ｎ＋１」である。このように、連続イベントストリームは、イベントのフローであり、各イベントは同じ一連の属性を有する。

上記のように、ストリームは、ＣＱＬクエリが機能する対象であるデータの根本的ソースであってもよい。ストリームＳは、要素（ｓ，Ｔ）のバッグ（「マルチセット」とも呼ばれる）であってもよく、「ｓ」はＳのスキーマにあり、「Ｔ」は時間ドメインにある。加えて、ストリーム要素は、タイムスタンプされた一連のタプル挿入として表わすことができるタプル−タイムスタンプ対であってもよい。言い換えると、ストリームは、一連のタイムスタンプされたタプルであってもよい。場合によっては、同一のタイムスタンプを有するタプルが２つ以上ある可能性がある。また、入力ストリームのタプルは、タイムスタンプが増す順序でシステムに到着することが要求される場合がある。これに代えて、リレーション（「経時変化するリレーション」とも呼ばれ、リレーショナルデータベースからのデータを含み得る「リレーショナルデータ」と混同されてはならない）は、時間ドメインからスキーマＲのタプルの無限のバッグへのマッピングであってもよい。いくつかの例において、リレーションは、順序化されていない経時変化するタプルのバッグ（すなわち瞬間的リレーション）であってもよい。場合によっては、時間の各インスタンスにおいてリレーションは有界集合であってもよい。またこれは、リレーションの変化する状態を捕捉するための挿入、削除、および／または更新を含み得る、タイムスタンプを有する一連のタプルとして表わすことができる。ストリームと同様、リレーションは、リレーションの各タプルが従い得る固定スキーマを有し得る。さらに、本明細書で使用されるように、連続クエリは通常、ストリームおよび／またはリレーションのデータを処理することができる（クエリすることができる）。加えて、このリレーションはストリームの参照データであってもよい。

いくつかの例において、ビジネスインテリジェンス（ＢＩ）は、特定の間隔で（たとえば場合によっては毎日）ビジネスオペレーションを推進し最適化するのを支援し得る。このタイプのＢＩは通常、オペレーショナルビジネスインテリジェンス、リアルタイムビジネスインテリジェンス、またはオペレーショナルインテリジェンス（ＯＩ）と呼ばれる。いくつかの例において、オペレーショナルインテリジェンスは、ＢＩとビジネスアクティビティモニタリング（ＢＡＭ）との間の線引を曖昧にする。たとえば、ＢＩは、履歴データの周期的クエリを重視するものであってもよい。したがって、これは過去を振り返ることを重視したものであってもよい。しかしながら、ＢＩは、オペレーショナルアプリケーションの中に置くこともでき、したがって、単なる戦略的分析ツールから、ビジネスオペレーションの第一線まで拡張することができる。このため、ＢＩシステムは、イベントストリームを分析し総計をリアルタイムで計算するように構成してもよい。

いくつかの例において、連続クエリ言語サービス（ＣＱサービス）は、ＢＩ分析サーバを拡張することにより、連続クエリを扱うとともにリアルタイムの警告を可能にするよう、構成し得る。ＣＱサービスは、いくつかの局面において、ＢＩ分析サーバおよびＣＱＬエンジンとの統合をもたらし得る。一例にすぎないが、ＢＩ分析サーバは、連続クエリをＣＱサービスに委託してもよく、ＣＱサービスは、ＣＱＬエンジンに対する論理データベース（ＤＢ）ゲートウェイとして機能してもよい。このようにして、ＣＱＬエンジンは、ＢＩ分析サーバを、その分析機能およびセマンティックモデリングについて強化することができるであろう。

いくつかの例において、ＣＱサービスは、とりわけ以下の機能を提供し得る。
・ＢＩ分析サーバに対するサービスをＣＱＬエンジンゲートウェイとしてリモート処理する。
・イベントソース／シンクアダプタ。
・論理的ＳＱＬに加えてＣＱＬ拡張からデータ定義言語（ＤＤＬ）を生成する。
・すべての種類の連続クエリおよび実装選択に対して統一されたモデルを提供する。
・メタデータを維持し再始動能力をサポートする。
・高アベイラビリティおよびスケーラビリティのサポート。

加えて、いくつかの例において、ＯＩは、可視性およびビジネスオペレーションに対する洞察を与えることができる、リアルタイムの動的なビジネス分析論の一形態である。ＯＩは、ＢＩまたはリアルタイムＢＩに、どちらも大量の情報の意味を解明するのを支援するという点において、関連付けられるかまたはこれと比較されることが多い。しかしながら、根本的な相違があり、ＯＩは主としてアクティビティ中心であり得るのに対し、ＢＩは主としてデータ中心であり得る。加えて、パターンを識別するための、事後のかつ報告に基づく手法として従来使用されているＢＩと異なり、ＯＩは、発展途上の状況（たとえば傾向およびパターン）を検出しこれに対応するのにより適している。

いくつかの例において、ビジネスイベント分析およびモニタリング（ＢＥＡＭ）システムは、インフライト（in-flight）データを処理しおよび／または受けるＣＱＬエンジンを含み得る。たとえば、ＣＱＬエンジンは、入ってくるリアルタイム情報（たとえばＢＩまたはＯＩ）をクエリするかそうでなければ処理するように構成されたインメモリリアルタイムイベント処理エンジンであってもよい。ＣＱＬエンジンは、時間のセマンティクスを利用または理解することができ、データのウィンドウの定義を処理できるように構成し得る。ＣＱＬエンジンの利用は、場合によっては、入ってくるデータに対してクエリを常に実行することを必要とし得る。

いくつかの局面において、ＣＱＬエンジンは、あらゆる特性を備えたクエリ言語を含み得る。このため、ユーザは、クエリという点から計算を指定し得る。加えて、ＣＱＬエンジンは、メモリを最適化し、クエリ言語の特徴、オペレータシェアリング、豊富なパターンマッチング、豊富な言語構築等を利用するように、設計してもよい。加えて、いくつかの例において、ＣＱＬエンジンは、履歴データおよびストリーミングデータ双方を処理してもよい。たとえば、ユーザは、カリフォルニアの売上高がある目標を超えたときに警告を送るようにクエリを設定してもよい。このように、いくつかの例において、警告は、履歴売上高データおよび入ってくる生（すなわちリアルタイム）の売上高データに少なくとも一部基づき得る。

いくつかの例において、ＣＱＬエンジンまたは以下で説明する概念のその他の特徴は、履歴に関する文脈（すなわちウェアハウスデータ）を、入ってくるデータとリアルタイム方式で組合わせるように、構成してもよい。したがって、場合によっては、本開示は、データベース格納情報およびインフライト情報の境界について説明することがある。データベース格納情報およびインフライト情報はいずれもＢＩデータを含み得る。このため、データベースは、いくつかの例において、ＢＩサーバであってもよく、または、何らかの種類のデータベースであってもよい。さらに、いくつかの例において、本開示の特徴により、上記特徴を、ユーザがコードをプログラムする、そうでなければ書込む方法を知らない状態で、実現することができる。言い換えると、上記特徴は、特徴が豊富なユーザインターフェイス（ＵＩ）に与えられてもよい、または、履歴データとリアルタイムデータの組合わせを非開発者が実現できるようにする他の手法に与えられてもよい。

いくつかの例において、上記概念を利用することにより、複合イベント処理に関連する豊かなリアルタイムの連続イベント処理機能を強化してもよい。これに限定される訳ではないがアーカイブされたリレーション等のいくつかの特徴をサポートしてもよい。このため、このような特徴（たとえば豊かなリアルタイムの連続イベント処理）を強化するために、システムを、リレーショナルデータの始動状態および実行時状態を透明に扱うように構成してもよい。言い換えると、システムを、作成の時点で空でないクエリ（すなわちアーカイブされたリレーション）を管理するように構成してもよい。

いくつかの例において、アーカイブされたリレーションを利用してもよい。このため、ＣＱＬエンジンが見るクエリが、このクエリがアーカイブされたリレーションに基づくことを示すとき、このアーカイブされたリレーションも、たとえば履歴コンテキストについてクエリするためにコールできる何等かのエンティティが存在することを示し得る。いくつかの例において、データ定義言語（ＤＤＬ）は、アーカイブされたリレーションに関するアノテーションを示し得る。これは、如何にしてクエリを実行するか、何がテーブル内で重要な列か、および／または何処に残りのデータを送るか等であるが、これらに限定されない。いくつかの例において、ＣＱＬエンジンにおいて（たとえばグラフとして）クエリが構築されると、システムはこのクエリグラフを分析することができる。加えて、いくつかの局面において、「distinct」、「group aggr」、「pattern」、および／または「group by」のようなステートフルな特定の演算子がある。しかしながら、ステートレスな演算子は、入力を取込んで、親、たとえば下流の演算子に、送るだけでよい。このため、このテーブル全体をここで格納することが１つの手法である。しかしながら、システムは、アーカイブされたリレーションを利用して、クエリグラフを分析し、アーカイブにクエリするのに使用できる最下位のステートフル演算子がどれかを判断することができる。いくつかの例において、システム（またはコンピュータにより実装される１つ以上の方法）は、グラフをトラバースしている間に到達した最下位のステートフル演算子における状態を取出せばよい。たとえば、クエリグラフを、ソースからトポロジーの順序で分析してもよい。この第１のステートフル演算子に少なくとも一部基づいて、ＣＱＬエンジンは次に、アーカイブされたリレーションに対して定義されたクエリの演算子の状態を初期化するために、フェッチすべきデータの最適量を決定してもよい。

限定されない少なくとも１つの例において、トポロジーに従ったトラバースにおいて、リレーションおよび／またはソースのようなソース演算子は最初に来るが、クエリ出力および／またはルートは最後に来る。たとえば、ＣＱＬクエリが、ｓｅｌｅｃｔ ｓｕｍ（ｃ１） ｆｒｏｍ Ｒ１ ｗｈｅｒｅ ｃ２＞ｃ２５のようなものである場合、このクエリについてのプランは、ＲｅｌａｔｉｏｎＳｏｕｒｃｅ→ＳＥＬＥＣＴ→ＧｒｏｕｐＡｇｇｒのようなものであろう。したがって、トポロジーの順序に従うと、ＲｅｌａｔｉｏｎＳｏｕｒｃｅおよびＳＥＬＥＣＴはいずれもステートレスなので、最下位のステートフル演算子は、ＧｒｏｕｐＡｇｇｒであろう。このようにして、クエリのステートフル演算子（この例ではＧｒｏｕｐＡｇｇｒ）により、クエリエンジンは、ストリーミングデータを受ける前に、データ記憶装置からの履歴データをクエリエンジンに投入することができるであろう。これは、クエリがアーカイブされたリレーションを分析しておりアーカイブされたリレーションがそのようなものとして示されていることに少なくとも一部基づいて、可能になるであろう。

いくつかの例において、所与のアーカイブリレーションについてのウィンドウサイズは、ユーザが指定してもよい。いくつかの局面において、アーカイブされたリレーションに関するウィンドウは、入ってくるストリーミングされた内容を分析するかそうでなければ評価するクエリグラフにおけるノードを含み得る。言い換えると、ウィンドウは、クエリエンジンによって分析されるおよび／または処理されるストリーミングされた内容の量、および／またはアーカイブされたリレーションに含まれる履歴データの量を定めることができる。

高いレベルでは、ウィンドウがストリームに適用されると、これはリレーションになり、次に、リレーショナルデータベースと同様に、通常のリレーショナルロジックを適用すればよい。タプルがウィンドウに届いてウィンドウから出るとき、想定しているリレーションは、これに対してコンパイルされたクエリとともに変化し、同時に結果を出力する。ＣＱＬは、ＲＡＮＧＥ（ナノ秒の細分性まで）、ＲＯＷＳ、ＰＡＲＴＩＴＩＯＮ ＢＹおよび拡張可能なウィンドウをサポートし得る。これらウィンドウは、ストリーム−リレーション演算子の例である。一方、ＩＳＴＲＥＡＭ（すなわち挿入ストリーム）、ＤＳＴＲＥＡＭ（すなわち削除ストリーム）およびＲＳＴＲＥＡＭ（すなわちリレーションストリーム）は、リレーション−ストリーム演算子である。いくつかの例において、ユーザ、開発者、および／または管理者は、クエリエンジンによってまたはクエリエンジンを機能させるもしくはホストする１つ以上の計算システムによって（たとえばＵＩを介して）与えられるウィンドウサイズを設定してもよい。いくつかの例において、ストリーム上のウィンドウは、時間に基づく範囲ウィンドウであってもよい。たとえば、アーカイブされたリレーションに対する構成可能な値のウィンドウは、ウィンドウサイズおよびウィンドウの計算の元になる属性を用いて指定してもよい。アーカイブされたリレーションの上に指定された構成可能な値のウィンドウがある場合、スナップショットクエリを計算してもよく、ウィンドウの境界内にあるスナップショットタプルを出力してもよい。加えて、状態の初期化後、値のウィンドウを、入ってくるアクティブデータに適用してもよい。いくつかの例では、入ってくるアクティブデータのみが、そのウィンドウ属性の値が現在のイベント時間と異なるウィンドウに、ウィンドウサイズよりも短い間、挿入されるであろう。

加えて、いくつかの例において、本開示の特徴は、ＣＱＬエンジンおよび／またはＣＥＰエンジンの連続クエリ処理機能を強化してリアルタイムデータ分析をサポートしてもよい。いくつかの局面において、ＣＱＬエンジンおよび／またはＣＥＰエンジンは、従来はストリーム指向分析エンジンであったであろうが、永続的記憶装置によって支援されるストリーム指向データ（たとえば上記アーカイブされたリレーション）をサポートするように拡張してもよい。たとえば、本開示は、永続的記憶装置（データベースおよび／またはテーブル）であるデータオブジェクト（ＤＯ）の概念を裏付けることができる特徴を説明している。ＤＯに対して修正がなされると、変更通知が、対象のリスナーにブロードキャストされて、事実上データストリームが作成されるであろう。このデータストリームは、実行しているクエリをサポートするＣＱＬエンジンおよび／またはＣＥＰエンジンによって消費されるであろう。しかしながら、ＣＱＬエンジンおよび／またはＣＥＰエンジンは、ＤＯ補助記憶装置における既存のデータを考慮するように設計されてはいないかもしれない。たとえば、ＣＱＬエンジンおよび／またはＣＥＰエンジンは、ＣＱＬエンジンおよび／またはＣＥＰエンジンにおいて実行しているクエリの初期状態が、現在ＤＯ補助記憶装置にあるすべてのデータを含むＤＯの現在の状態を反映することを、要求するかもしれない。このクエリがそのように初期化されると、ＣＱＬエンジンおよび／またはＣＥＰエンジンは、従来のストリーム指向方式におけるこの点からのＤＯ変更通知のストリームを扱うだけでよい。

いくつかの局面において、ＣＱＬエンジンおよび／またはＣＥＰエンジンは、従来はストリームまたはアーカイブされていないリレーションを処理するものであろうため、初期状態はないかもしれない。たとえば、クエリがロードされる場合、これは、実行および変化をリッスンすること等を開始するであろう。場合によっては、棒グラフによる州ごとの売上をユーザが要求しその後誰かによる新たな売上があったとすると、テーブルは更新され、ユーザは、出されたグラフに変化がみられることを予想するであろう。しかしながら、彼らがダッシュボードを閉じて一週間後に戻り売上を報告した場合、ユーザは、合計された売上データのテーブルに示された売上の合計が得られることを予想するであろう。言い換えると、クエリは、アーカイブの状態に引上げられてからアクティブな変更をリッスンする必要があるであろう。

たとえば、いくつかの局面において、ＣＱＬエンジンは、アーカイブされたデータを用いて予め初期化されてもよい。初期化されると、ＣＱＬエンジンは、（たとえば挿入、削除等についてのＡＰＩコール、アーカイブからのデータに少なくとも一部基づく）変更通知があるか否か知るためにＪａｖａ（登録商標）メッセージングサービス（ＪＭＳ）またはその他のメッセンジャーをリッスンするであろう。したがって、サービスはリッスンすることができ、ＪＭＳが、リスニングサービスがリッスンしているのと同じトピックに関する発行を行なうと、データを受けることができる。サービスは、誰が発行しているのかまたは発行しているか否か知る必要はない。リスニングサービスはリッスンするだけでよく、何かが生じた場合にリスニングサービスはそれを聞けばよい。いくつかの例では、このようにして永続性がたとえばそのコンシューマから切離される。加えて、いくつかの例において、警告エンジンが、聞いたものに基づいて警告を発してもよく、場合によってはさらに、ＳＱＬエンジンが、リスナーに関連するプロセスクエリをリッスンしてもよい。

いくつかの例において、クエリは、ＣＱＬ、ＳＱＬ、および／またはＣＥＰエンジンにおいて開始されてもよく、命令は、アーカイブデータを（たとえばポンプ（pump）するために）取得した後にこれらＪＭＳメッセージをリッスンし始めるように構成されてもよい。しかしながら、多数の挿入、削除等があるので、これは大量の情報を含み得る。加えて、リスナーがメッセージを聞く前に時間のずれがある可能性があり、いくつかの例において、リッスンすることは、割込み、アーカイブにクエリし、戻り、リッスンを開始することであろう。このため、イベントの見落としおよび／または二重カウントの可能性がある。

加えて、エンジンがクエリを実行するだけであれば、エンジンがクエリを実行している間に、事実がＪＭＳに入りエンジンがリッスンしていなかったところで発行されることがある。そこで、エンジンを、先ずリスナーをセットアップしアーカイブクエリを実行した後に戻って実際にキュー（queue）から出始めるように構成すれば、何の見落としもないであろう。このように、ＪＭＳは、事実をキューにしてもよく、エンジンがクエリを実行している間事実のバックアップがあればそれでよい。なぜなら、後で追い付くことが可能であり同期しているか否か心配する必要がないからである。もしここになければ、リッスン中、見落としはなく、リスナーが確立されている限り、エンジンが戻るまでキューにするだけでよい。

加えて、いくつかの例において、システム列をユーザのデータに追加してもよい。このシステム列は、二重カウントおよび／または見落としという動作上の問題に対処する試みにおいて、トランザクションＩＤを示すためのものであってもよい。しかしながら、他の例において、システムは、トランザクションコンテキストテーブルを提供するかそうでなければ生成してもよい。加えて、２つの追加列としてＴＲＡＮＳＡＣＴＩＯＮ＿ＣＩＤおよびＴＲＡＮＳＡＣＴＩＯＮ＿ＴＩＤがあってもよい。コンテキストテーブルは、最後にコミットされたトランザクションＩＤのスレッド（コンテキスト）性を知るために、永続性サービスによって常に維持されていてもよい。トランザクションＩＤは、スレッド（コンテキスト）に対して昇順でコミットされることが保証されてもよい。たとえば、サーバは、立上ったときに、永続性サービスを実行してもよい。各々は、予め初期化された情報のデータがＪＭＳを通過したデータすべてを含むか否か判断するために、コンテキストＩＤとトランザクションＩＤのセットを割当ててもよい。加えて、場合によっては、（ＪＴＡに準拠するおよび／または高アベイラビリティ（ＨＡ）を実現する）複数の出力サーバを利用してもよく、各サーバは、その他のサーバによって管理されるその他のテーブルと全く別の一組のコンテキスト／トランザクションテーブルを管理してもよい。

上記および下記技術は、多数のやり方でおよび多数の文脈において実装し得る。以下において詳細に説明する、実装および文脈のいくつかの例を下記図面を参照しながら示す。しかしながら、以下の実装および文脈は、数あるうちのほんの一部にすぎない。

図１は、アーカイブされたリレーションを有する連続クエリを管理するための技術を実装し得るシステムまたはアーキテクチャ１００の簡略化された例を示す。アーキテクチャ１００において、１人以上のユーザ１０２（たとえば口座所有者）は、ユーザの計算装置１０４（１）〜１０４（Ｎ）（まとめて「ユーザ装置１０４」とする）を利用して、１つ以上のサービスプロバイダコンピュータ１０６に、１つ以上のネットワーク１０８を介してアクセスし得る。いくつかの局面において、サービスプロバイダコンピュータ１０６も、１つ以上のストリーミングデータソースコンピュータ１１０および／または１つ以上のデータベース１１２とネットワーク１０８を介して通信し得る。たとえば、ユーザ１０２は、サービスプロバイダコンピュータ１０６を利用して、ストリーミングデータソースコンピュータ１１０および／またはデータベース１１２のデータにアクセスし得る、そうでなければこのデータを管理し得る（たとえば、クエリは、１１０、１１２のうちいずれかまたは双方に対して実行し得る）。データベース１１２は、リレーショナルデータベース、ＳＱＬサーバ等であってもよく、いくつかの例では、履歴データ、イベントデータ、リレーション、アーカイブされたリレーション等を、ユーザ１０２に代わって管理し得る。加えて、データベース１１２は、ストリーミングデータソースコンピュータ１１０から提供されるデータを受けることができ、そうでなければ格納することができる。いくつかの例において、ユーザ１０２は、ユーザ装置１０４を利用して、サービスプロバイダコンピュータ１０６と、クエリ（「クエリステートメント」とも呼ばれる）を与えることによりまたはデータ（たとえば履歴イベントデータ、ストリーミングイベントデータ等）に対する他の要求を与えることにより、対話し得る。このようなクエリまたは要求は次に、データベース１１２のデータおよび／またはストリーミングデータソースコンピュータ１１０から入ってくるデータを処理するサービスプロバイダコンピュータ１０６によって実行し得る。さらに、いくつかの例において、ストリーミングデータソースコンピュータ１１０および／またはデータベース１１２は、サービスプロバイダコンピュータ１０６に関連付けられた、一体化された分散環境の一部であってもよい。

いくつかの例において、ネットワーク１０８は、ケーブルネットワーク、インターネット、無線ネットワーク、セルラーネットワーク、イントラネットシステム、および／またはその他の私的および／または公的ネットワーク等の、複数の異なる種類のネットワークのうちの１つまたはこれらを組合わせたものを含み得る。示されている例はユーザ１０２がネットワーク１０８を通してサービスプロバイダコンピュータ１０６にアクセスすることを示しているが、記載されている技術は、ユーザ１０２が、１つ以上のサービスプロバイダコンピュータ１０６と、１つ以上のユーザ装置１０４を介し固定電話を通して、またはキオスクを介して、または他のやり方で、対話する場合に、等しく適用し得る。また、記載されている技術は、他のクライアント／サーバ構成（たとえばセットトップボックス等）においても、および、非クライアント／サーバ構成（たとえばローカル格納アプリケーション等）においても、適用し得ることが注目される。

ユーザ装置１０４は、携帯電話、スマートフォン、携帯情報端末（ＰＤＡ）、ラップトップコンピュータ、デスクトップコンピュータ、シンクライアント（thin-client）装置、タブレットＰＣ等の、任意の種類の計算装置であればよいが、これらに限定されない。いくつかの例において、ユーザ装置１０４は、サービスプロバイダコンピュータ１０６と、ネットワーク１０８を介してまたはその他のネットワーク接続を介して通信し得る。さらに、ユーザ装置１０４はまた、処理するデータベース１１２（またはその他のデータ記憶装置）のデータを要求するための、１つ以上のクエリまたはクエリステートメントを与えるように構成し得る。

いくつかの局面において、サービスプロバイダコンピュータ１０６はまた、モバイル、デスクトップ、シンクライアント、および／またはサーバ等のクラウド計算装置といった、任意の種類の計算装置であればよいが、これらに限定されない。いくつかの例において、サービスプロバイダコンピュータ１０６は、ユーザ装置１０４と、ネットワーク１０８を介してまたはその他のネットワーク接続を介して通信し得る。サービスプロバイダコンピュータ１０６は、おそらくは、クラスタに、サーバファームとして、または、互いに関連がない個々のサーバとして配置された、１つ以上のサーバを含み得る。これらサーバは、本明細書に記載の特徴を実行するように、そうでなければホストするように、構成し得る。上記特徴は、本明細書に記載の、アーカイブされたリレーションの管理、アーカイブされたリレーションに関連する構成可能なデータウィンドウ、および／またはアーカイブされたリレーションの管理に関連する変更イベントの正確なカウントを含むが、これらに限定されない。加えて、いくつかの局面において、サービスプロバイダコンピュータ１０６は、ストリーミングデータソースコンピュータ１１０および／またはデータベース１１２を含む、一体化された分散計算環境の一部として構成し得る。

例示としてのある構成において、サービスプロバイダコンピュータ１０６は、少なくとも１つのメモリ１３６と、１つ以上の処理部（またはプロセッサ）１３８とを含み得る。プロセッサ１３８は適宜、ハードウェア、コンピュータにより実行可能な命令、ファームウェア、またはこれらの組合わせにおいて実装し得る。コンピュータにより実行可能な命令またはファームウェアによる、プロセッサ１３８の実装は、記載されているさまざまな機能を実行するために、何らかの適切なプログラミング言語で書かれた、コンピュータにより実行可能なまたはマシンにより実行可能な命令を含み得る。

メモリ１３６は、プロセッサ１３８にロード可能でかつプロセッサ１３８において実行可能なプログラム命令と、これらプログラムの実行中に生成されるデータとを格納し得る。サービスプロバイダコンピュータ１０６の構成および種類に応じて、メモリ１３６は、揮発性（ランダムアクセスメモリ（ＲＡＭ）等）であってもよくおよび／または不揮発性（読出専用メモリ（ＲＯＭ）、フラッシュメモリ他等）であってもよい。サービスプロバイダコンピュータ１０６またはサーバはまた、着脱可能な記憶装置および／または着脱不能な記憶装置を含み得る、その他の記憶装置１４０を含み得る。その他の記憶装置１４０は、磁気記憶装置、光ディスク、および／またはテープ記憶装置を含み得るがこれらに限定されない。ディスクドライブおよびこれらディスクドライブに関連するコンピュータ読取可能な媒体は、計算装置のための、コンピュータ読取可能な命令、データ構造、プログラムモジュール、およびその他のデータの、不揮発性記憶装置を提供し得る。実装によっては、メモリ１３６は、スタティックランダムアクセスメモリ（ＳＲＡＭ）、ダイナミックランダムアクセスメモリ（ＤＲＡＭ）、またはＲＯＭ等の、複数の異なる種類のメモリを含み得る。

着脱可能および着脱不能な、メモリ１３６およびその他の記憶装置１４０はすべて、コンピュータ読取可能な記録媒体の例である。たとえば、コンピュータ読取可能な記録媒体は、コンピュータ読取可能な命令、データ構造、プログラムモジュール、またはその他のデータ等の、情報の格納のための何等かの方法または技術において実装される、揮発性または不揮発性で着脱可能または着脱不能な媒体を含み得る。メモリ１３６およびその他の記憶装置１４０はすべて、コンピュータ記録媒体の例である。

サービスプロバイダコンピュータ１０６はまた、アイデンティティインターフェイスコンピュータ１２０が、格納されているデータベース、別の計算装置もしくはサーバ、ユーザ端末、および／またはネットワーク１０８上のその他の装置と通信できるようにする、通信接続１４２を含み得る。サービスプロバイダコンピュータ１０６はまた、キーボード、マウス、ペン、音声入力装置、タッチ入力装置、ディスプレイ、１つ以上のスピーカ、プリンタ他等の、入出力（Ｉ／Ｏ）装置１４４を含み得る。

次にメモリ１３６の内容の詳細について述べる。メモリ１３６は、オペレーティングシステム１４６と、アーカイブリレーションモジュール１４８、構成可能ウィンドウモジュール１５０、および／またはイベントカウントモジュール１５２を少なくとも含む、本明細書に開示される特徴を実装するための、１つ以上のアプリケーションプログラムまたはサービスとを含み得る。本明細書で使用されるモジュールは、サービスの一部であるサーバまたはサーバのクラスタによって実行されるプログラミングモジュールであってもよい。この特定の文脈において、モジュールを、サービスプロバイダコンピュータ１０６の一部であるサーバまたはサーバのクラスタによって実行してもよい。いくつかの例において、アーカイブリレーションモジュール１４８は、１つ以上のイベントストリームエントリｓ１、ｓ２、…ｓＮへの参照を含み得る１つ以上のアーカイブされたリレーション１５４を、受ける、識別する、生成する、そうでなければ提供するように構成し得る。たとえば、アーカイブされたリレーションは、これらエントリ（すなわちｓ１〜ｓＮ）を含むストリームにウィンドウを適用することによって定義してもよい。このため、アーカイブされたリレーションは、これらエントリを含む有界のデータ集合であってもよい。しかしながら、これらエントリは生成時に空でない場合がある。これには、限定ではないが、永続性または履歴データのその他のデータベースから予めロードされたリレーションのエントリのうちの１つ以上（たとえばｓ１および／またはｓ２、これよりも多いまたは少ないエントリ）を有することが含まれる。このため、これら予めロードされたエントリは履歴データを含み得る。リレーションの残りは入ってくるストリーミングデータを含み得る。いくつかの例において、アーカイブされたリレーション１５４は、最初に｛ｓ３，ｓ４｝として識別されるかもしれない。しかしながら、ウィンドウがｗ１からｗ２に移動すると、アーカイブされたリレーション１５４は、｛ｓ４，ｓ５｝として識別されｓ３の削除および／またはｓ５の挿入によって変更されているかもしれない。

先に述べたように、アーカイブされたリレーション１５４は、その作成の「瞬間」において（おそらくは）空でないＣＱＬリレーションであってもよい。これは、作成された「瞬間」において内容が空である「通常の」ＣＱＬリレーションと対照的である。いくつかの例において、アーカイブされたリレーション１５４の内容がその作成の瞬間において「時間の始まり」から存在していたと仮定する（Ｌｏｎｇ．ＭＩＮ＿ＶＡＬＵＥ）。ＢＥＡＭコンテキストにおいては、ＣＱＬエンジン１５６のオブジェクト（いくつかの例ではすべてのオブジェクト）をサーバの起動の度に作成し得る点に注目するのが有用である。いくつかの点で、アーカイブされたリレーション１５４は、「通常の」ＣＱＬ内部リレーションに似ていることがある。特に、演算（ＪＯＩＮ、ＧＲＯＵＰ ＡＧＧＲ、ＯＲＤＥＲ ＢＹ ＴＯＰ Ｎのようなリレーション−リレーション演算、および、Ｉ／Ｄ／ＲＳＴＲＥＡＭのようなリレーション−ストリーム演算）は、「通常の」ＣＱＬ内部リレーションに対して有するのと同一のセマンティクスを保持し得る。加えて、いくつかの例において、「アーカイバ」は、ＣＱＬエンジン１５６との特定のコントラクトを実装するＪａｖａ（登録商標）クラスであってもよい。これは、アーカイバを可能にする機能を有するＩＡｒｃｈｉｖｅｒインターフェイスまたはその他のインターフェイスを実装し得る。この「アーカイバ」は、アーカイブされたリレーション１５４に対応する「アーカイバ」によって管理される論理エンティティの識別子（たとえばデータオブジェクトの名称）とともに、アーカイブされたリレーション１５４を作成するのに使用されるＤＤＬステートメントの一部として指定されてもよい。

いくつかの局面において、アーカイバは、ＣＱＬエンジン１５６とのコントラクトに少なくとも一部基づいて実装されることにより、アーカイブされたリレーション１５４の内容をその作成時に少なくとも提供してもよい。加えて、アーカイバは、自身の（たとえばＣＱＬエンジン１５６の外部の）アーカイブされたリレーション１５４の「経時変化する」内容を維持すると予想できる。しかしながら、いくつかの例において、アーカイバはステートレスであってもよい。この例において、アーカイバは、アーカイブされたリレーションのフレームワークによって渡されたクエリを実行する方法（たとえば「execute()」）を実装し得る。アーカイバは次に、この方法が実行されると内容をアーカイブされたリレーションのフレームワークに返してもよい。アーカイバはまた、アーカイブされたリレーション１５４に対するクエリ機能（たとえばＳＱＬ−９９クエリとして表現される）を提供するように構成されてもよい。加えて、いくつかの例において、「アーカイバ」に提示されるクエリにおけるＦＲＯＭ句のアイテムは、「アーカイバ」エンティティの名称および／またはデータオブジェクトの名称（たとえば永続的記憶装置上で維持される）であってもよい。ＦＲＯＭ句のアイテムがデータオブジェクトの名称の場合、これらは、作成ＤＤＬにおけるアーカイブされたリレーションにマッピングしてもよい。これに加えてまたはこれに代えて、アーカイバの名称を用いてアーカイバインスタンス（２つ以上のアーカイバがある可能性がある）をルックアップしてから、このアーカイバインスタンスに対する実行（クエリ）をコールしてもよい。クエリにおいて使用される属性名は、希望に応じて、ＣＲＥＡＴＥ ＡＲＣＨＩＶＥＤ ＲＥＬＡＴＩＯＮ ＤＤＬまたはその他適切なＤＤＬにおいて指定される列の名称であってもよい。クエリを実行する間、「アーカイバ」は、ｔｘｎ Ｔ＿ｎの時点でコミットされた変更を含むデータオブジェクトのスナップショット上でクエリを実行してもよい。上記Ｔ＿ｎは、データオブジェクトに対するイベントがストリーミング入力として提示された最新のトランザクションよりも前である。特に、「後の」トランザクションに対応する入力として与えられたストリーミングデータオブジェクトイベントはないであろう。

さらに、「アーカイバ」は、このクエリが実行されたトランザクションのＩＤを返してもよい。このＩＤは、後のトランザクションのＩＤが前のトランザクションのＩＤよりも大きくなるように単調に増加する数字（必ずしも連続しない）であってもよい。更新イベントの場合、「アーカイバ」は、ストリーミングイベントの一部として、ＯＬＤ値とＮＥＷ値を与えてもよい。これに加えてまたはこれに代えて、いくつかの例では、永続性サービスが、ＯＬＤ値およびＮＥＷ値双方についての変更通知をＣＱサービスに送ってもよい。このようにして、ＣＱサービスは、適切な動作をアーカイブされたリレーションに対して行なうことができるであろう。削除イベントの場合、「アーカイバ」は、削除イベントを、妥当性検査にパスした場合に（いくつかの例では「場合にのみ」）、ストリーミングイベントとして与えてもよい。いくつかの例において、アーカイバの機能は、クエリが処理しないデータオブジェクトイベントはないというシナリオを可能にし得る。ＣＱＬエンジン１５６も、すべてのデータオブジェクトイベントの処理をスキップすることによりイベントは重複して処理されないというシナリオを可能にし得る。この場合、トランザクション識別子＜＝「スナップショット」クエリの実行の一部として「アーカイバ」によって返されるトランザクション識別子である。いくつかの例において、アーカイバは永続性サービスと同等であり得る。これに代えてまたはこれに加えて、クエリの瞬間におけるスナップショット情報を、トランザクションコンテキストテーブルから得てもよい。このスナップショット情報は、ＣＱＬエンジンにおいて維持されてもよく、スナップショットＩＤ（増大する識別子）はこれと関連付けられてもよい。同じものを、このクエリのプランにおける選択されたいくつかの演算子の入力キューに設定してもよい。これらは、「コネクタ」演算子と呼ばれ、ローカルクエリプランがグローバル（全体）クエリプランに結合し得る場所を表わしてもよい。イベントがＣＱＬエンジンに達すると、このイベントに対し、スナップショットＩＤを、その中のコンテキストＩＤおよびトランザクションＩＤの値を用いて計算してもよい。スナップショットＩＤは、ＣＱＬエンジンにおいて維持されているスナップショット情報を用いて計算してもよい。イベントのスナップショットＩＤは次に、入力キューのスナップショットＩＤと比較してもよい。イベントのＩＤ＞キューのＩＤであれば、これを処理をしてもよく、そうでなければ、以前既に考慮されている可能性がありしたがって二重カウントを避けるために無視してもよい。

固有のＣＱＬコンセプトとしてアーカイブされたリレーション１５４を導入することによって、ＣＱＬエンジン１５６は、アーカイブされたリレーション１５４に対して定義されたクエリの演算子の状態を初期化するためにフェッチする必要があるデータの最適量を決定することができる。いくつかの例において、クエリのコンパイルの最終ステップとして、クエリプラン生成（および／またはグローバルプランとのマージ）に従い、状態初期化フェイズを導入して、「アーカイバ」に対して実行する必要があるクエリの最適セットを決定してもよい（たとえば演算子の状態の初期化のために）。場合によっては、クエリのセット（たとえば最適セット）を決定するために使用される状態初期化アルゴリズムは、ステートフル演算子に遭遇するまで、一連の演算子の状態化の実現を遅らせるかもしれない（これはデータを集計ししたがってメモリ内のすべての詳細／事実の実現と比較すると取出すデータは少ないかもしれない）。クエリ実行の第１ステップは、状態初期化クエリが実行される前であっても、スナップショットクエリの実行および／またはクライアントへの結果の送達であろう。いくつかの例において、スナップショットクエリ（「アーカイバクエリ」とも呼ばれる）は、演算子を結果の内容によって初期化し得る状態初期化の一部であってもよい。次に、これら結果を下流の演算子（たとえば下流の演算子すべて）に伝搬することによって、結果を出力してもよい。次に、状態初期化アルゴリズムによって決定されたクエリを実行してもよい。この第１ステップの終了時に、すべての演算子それぞれの状態は適切に初期化されクエリはストリーミングイベントを処理できる状態になっているであろう。

ＣＱＬクエリが、システム再起動中に、アーカイブされたリレーション１５４を参照するとき、ＣＱＬエンジン１５６は、クエリ内の実行演算子の状態がシャットダウン前に持っていた値に初期化されるというシナリオを可能にするように構成されてもよい。これに代えてまたはこれに加えて、クエリが（再）起動される度に、それがシャットダウンの一部であろうと自発的なものであろうと、クエリは、フレッシュなすなわち新たなアーカイバクエリを発行することによって状態を再び初期化してもよい。いくつかの例において、これは、ｔ０＋デルタの時点ではｔ０の時点と異なり得る。場合によっては、状態初期化アルゴリズムを、この機能を扱うように構成してもよい。いくつかの例において、各々（またはすべて）のアーカイブされたリレーション１５４は、リレーションを構成するイベントを追跡するアーカイバオブジェクトにマッピングしてもよく、自身に対して発行されたＳＱＬクエリ（データベーステーブルと同様）に答えてもよい。加えて、ＣＱＬクエリにおける実行演算子の状態の初期化は、ＣＱＬクエリが依存するアーカイブされたリレーション１５４にマッピングするアーカイバに対して適切なＳＱＬクエリを発行することと、戻された結果を使用して演算子の状態を初期化することとを少なくとも含む、２段階のプロセスであってもよい。（アーカイバから得た）イベントの実現を遅らせると、結果としてメモリおよび／または処理時間消費が削減されるかもしれない。これに加えてまたはこれに代えて、メモリの削減は、メモリを最小にする適切な演算子が発見されたためであるかもしれない。たとえば、集計された／要約されたデータをメモリに入れると、大幅なメモリの削減につながり得る。

いくつかの例において、状態初期化プロセス（これは、全体のプロセスの中の１ステップであってもよく、ＣＱＬクエリの起動時に実装されてもよく、アーカイブされたリレーション（複数可）を参照する）は、メタデータオブジェクトを用いてクエリの論理プランを取得することと、論理プランから物理プランを構築することと、ローカル物理プランをオプティマイザを用いて最適化することと、オペレーションを共有してグローバル物理プランを得ることと、補助構造（たとえばシノプシス、記憶、キュー等）を追加することと、クエリをインスタンス化すること（実行演算子を構築しおよび／または実行構造をサポートする）とを、含み得る。加えて、状態初期化アルゴリズムをコールする適切な場所は、ローカル物理プラン最適化の直後であってもよい。いくつかの例において、状態初期化アルゴリズムは、クエリがアーカイブされた１以上のリレーション１５４に依存するときにコールされるだけであってもよい。

いくつかの例において、バイナリ演算子の場合、子演算子をクエリ演算子としてマークしてもよい。また、クエリプラン全体のトラバース後にクエリ演算子が識別されない場合、ルートをクエリ演算子としてマークしてもよい。演算子がクエリ演算子として識別された後、インスタンス化フェイズの間にイズクエリ演算子（isQueryOperator）フラグがセットされた場合、構築されたアーカイバクエリを実行する方法が演算子ファクトリコードからコールされるであろう。次に、戻された結果セットをタプルのセットに変換すればよく、リストを実行演算子インスタンスにセットすればよい。このようにして、インスタンス化されると、状態を必要とする実行演算子は、その状態を初期化するのに十分であろうタプルのリストを有し得る。インスタンス化されると、これらタプルを用いて状態を初期化しこれを下流に伝搬する方法をコールするトポロジー順でクエリプランに対してもう１つのパスを行なえばよい。この方法は演算子固有であってもよく、および／または、初期化処理は、シノプシスの投入、内部データ構造の維持等と同様であってもよい。

いくつかの例において、「売上高」のアーカイブされたリレーション１５４の上の下記ＣＱＬクエリを実装してもよい。

いくつかの例において、ＣＱＬエンジン１５６においてコンパイルされたときのクエリプランは、次のように説明することができる。

いくつかの例において、ＣＱＬエンジン１５６は、上記クエリをコンパイルするとき、このクエリは、その起動時の状態は外部から利用することができ潜在的に大きい可能性があるリレーション（たとえばアーカイブされたリレーション１５４）に対して表現されると、判断し得る。ＣＱＬには、ステートフルな演算子（たとえばＧＲＯＵＰ ＢＹ、ＰＡＴＴＥＲＮ）のセットがある一方で、ステートフルでない演算子（たとえばＦＩＬＴＥＲ、ＰＲＯＪＥＣＴ、ＯＵＴＰＵＴ）があるであろう。状態初期化アルゴリズムは、考慮するシナリオに対して次のように機能し得る。すなわち、ＲＥＬ＿ＳＯＵＲＣＥ演算子は、アーカイブされたリレーションに対してステートレスなので、アーカイバのコールをスキップし得る。次のＦＩＬＴＥＲも、ステートレスなので、状態に対するアーカイバのコールをスキップし得る。次に、ＧＲＯＵＰ ＢＹ演算子に遭遇する可能性があり、これは、アーカイバを呼出し、下記ＳＱＬクエリ（希望に応じてアーカイバクエリはサブクエリに基づく手法を用いて形成されたクエリであってもよく下記のものよりも複雑であってもよい）を用いて、その状態を満たしてもよい。

なお、ユーザのクエリはＣＯＵＮＴ集計を含まないかもしれないが、ＧＲＯＵＰ ＢＹはＣＯＵＮＴ集計を有するＳＱＬクエリを発行し得る。その理由は次の通りである。この情報を、（その状態の一部としての）ＧＲＯＵＰ ＢＹ演算子によって要求して、グループ（この例では「ｐｒｏｄｕｃｔｉｄ」に対応する）が空になりグループに関連して使用し得る何等かのリソースを（メモリのように）解放するか否か、判断することができる。

次に、−ｖｅタプルが到着した状況について考える。上記シナリオにおいて、ＲＥＬ＿ＳＯＵＲＣＥは、状態を維持しないかもしれず、その場合、一連の演算子の中の次の演算子に判断させるであろう（「通常の」ＣＱＬリレーションのように例外をスローするのではなく）。ＦＩＬＴＥＲ演算子も、状態を維持しないかもしれず、その場合、同じようにするであろう。次に、ＧＲＯＵＰ ＢＹ演算子はタプルを見ることになるであろう。その状態は初期化されているので、対応するグループの位置を正しく確認し残りの処理を実行することができるであろう。たとえば、これが、ｒｅｇｉｏｎ＝「ＡＰＡＣ」でｐｒｏｄｕｃｔｉｄ＝「携帯電話」のタプルであれば、ＳＵＭ集計関数は、タプルに存在する額だけ、「携帯電話」のその時点までの合計を減じるであろう。

いくつかの例において、「売上高」のアーカイブされたリレーション１５４の上の下記ＣＱＬクエリを、上記例における合計ではなく中央値を求めるために実装してもよい。

いくつかの例において、ＣＱＬエンジン１５６においてコンパイルされたときのクエリプランは、次のように説明することができる。

いくつかの例において、状態初期化アルゴリズムは、考慮するシナリオに対して次のように機能する。ＲＥＬ＿ＳＯＵＲＣＥ演算子は、アーカイブされたリレーションに対してステートレスなので、アーカイバのコールをスキップし得る。次のＦＩＬＴＥＲも、ステートレスなので、状態に対するアーカイバのコールをスキップし得る。次に、ＧＲＯＵＰ ＢＹ演算子に遭遇する可能性がある。この演算子はステートフルなので状態の初期化を要求し得る。ここで、クエリは、少なくとも１つの包括的な（holistic）関数（ＭＥＤＩＡＮ）を必要とするので、集計された／要約状態をデータベースから得るだけでは十分でないかもしれない。ＭＥＤＩＡＮを計算する対象である値のセット全体を、ＧＲＯＵＰ ＢＹ状態に対して要求してもよい。

したがって、この段階では、最下位のステートフル演算子を識別しており、かつ、より詳細な事項を要求してその状態を構成すると判断しているので、演算子プランを逆方向（すなわち「下に」）トラバースすればよい。すなわち、このプランをこの段階からは上から下にトラバースすればよい。いくつかの例において、状態を構築する責任は、ツリーにおいて下方向に次の演算子にある。この演算子はこの場合ＦＩＬＴＥＲであり、これは、要求された値のセットをメモリに入れることができる以下のＳＱＬクエリを（「アーカイバ」に）発行し得る。

いくつかの例において、これらタプルが取出されると、ＦＩＬＴＥＲは、これら値を上流に伝搬してもよく、ＧＲＯＵＰ ＢＹは、その状態を、ツリーまたはグラフ（たとえば、限定されないが増強された赤黒ツリー等）を構成することによって構築してもよい。このデータ構造によって、次の（Ｏ（ｌｏｇ ｎ）時間）増分ＭＥＤＩＡＮ計算を非常に高速で行なうことができる。いくつかの例において、上記クエリにＦＩＬＴＥＲがない場合、状態を構築する責任はＲＥＬ＿ＳＯＵＲＣＥ演算子にあり、リレーションの全内容（最適化のように、クエリによってアクセスされる関連フィールドのみが、行全体ではなく各行に対して取出される。当然ながら、すべてのフィールドがアクセスされる場合は行全体がフェッチされる）がメモリに取込まれているであろう。

いくつかの局面において、アーカイブされたリレーション１５４に基づいてクエリに到達するマイナスイベントを処理するためには、他のサポートが有用であろう。結合のような射影、バイナリ演算子等のＣＱＬエンジン１５６演算子の中には、系統（lineage）シノプシスを維持するものがある。この系統シノプシスにおけるルックアップは、タプルＩＤに基づく。プラスタプルが届くと、これをシノプシスに挿入すればよい。この演算子にマイナスタプルが届くと、タプルＩＤに生じる系統シノプシスをルックアップする。アーカイブされたリレーション１５４のコンテキストに生じ得る問題は次の通りである。

１．クエリが起動したとき、系統シノプシスを維持する演算子はクエリ演算子として識別される場合があり、これは、アーカイバにクエリし返された結果をタプルに変換し系統シノプシスに入れる場合がある。

２．加えて、クエリが実行を開始したとき、これが受ける最初のタプルは、アーカイブされたプラスタプルのうちの１つに対応するマイナスタプルの場合がある。ここで、プラスおよびマイナスタプルのＩＤは一致しない場合があり、このことは、ルックアップの失敗および間違った結果につながる。

３．通常のリレーションの場合、リレーションソースは、プラスおよびマイナスタプルが同一のＩＤを確実に有するようにするのに役立つであろう。なぜならこれはシノプシスを維持し得るからである。しかしながら、アーカイブされる場合は、これが可能でないことがある。

このため、ＢＥＡＭ永続性レイヤはイベントＩＤを各イベントに割当てればよく、イベントの挿入（プラス）、削除（マイナス）、および更新通知はすべてこのＩＤの同一の値を有するであろう。この機能を利用することによって、上記問題を回避すればよい。したがって、もう一つの句をアーカイブされたリレーション１５４のＤＤＬに追加することにより、ＥＶＥＮＴ ＩＤＥＮＴＩＦＩＥＲ句を指定すればよい。これは、ＣＱＬ ｂｉｇｉｎｔ型の列であってもよく、この列は、イベントのプラス、マイナス、および更新タプルについて同じ値を有するであろう。

場合によっては、ＣＱＬエンジン１５６内で、ＥＶＥＮＴ ＩＤＥＮＴＩＦＩＥＲ句において指定された列を利用してもよい。たとえば、アーカイバがクエリされるとき、このフィールドは、選択リストに存在するように強制されてもよく、このフィールドの値を使用することにより、記録をタプルに変換する一方でタプルＩＤを設定してもよい。また、通常の入力イベントが来たとき（たとえばクエリが実行しているとき）、このフィールドにおける値には、タプルの値をリレーションソースコードのＩＴｕｐｌｅに変換する一方で、タプルＩＤが割当てられてもよい。こうすることにより、イベントのプラスおよびマイナスが確実に同じタプルＩＤを有するようにするための構成が可能になるであろう。

いくつかの例において、以下の構文をアーカイブされたリレーションのＤＤＬに利用してもよい。

アーカイブされたリレーションを作成するためのこのＤＤＬは、エンドユーザおよび他の構成要素からは見えない場合がある。たとえば、アーカイブされたリレーションの作成は、ＥＰＮがＣＱＬプロセッサノードに接続されたデータオブジェクトノードを含むときに、ＣＱＬプロセッサコードにより、「隠れて」処理することができる。たとえば以下のＥＰＮについて考える。

このＥＰＮコードは、ＣＱＬエンジン１５６において作成するアーカイブされたリレーションの列名としてデータオブジェクトのフィールド名を使用してもよい。そうすることにより、フィールドの名称とフィールドの順序が確実に一致する。

加えて、いくつかの例において、アーカイブされたストリームを、ＣＱＬエンジン１５６および／またはその他のエンジンを介して可能にしてもよい。概念上、アーカイブされたストリームは、アーカイブされたリレーションの特徴によく似ているかもしれない。しかしながら、ストリームとリレーションの間には意味の相違があるので、アーカイブされたリレーションの特徴との比較で、何らかの変更を、アーカイブされたストリームの設計および構文に行なえばよい。たとえば、リレーションの内容には、加算、更新、または削除が発生したときに、変化が生じ得る。このため、この内容は、時間の経過とともに、サイズが大きくまたは小さくなる可能性がある。しかしながら、ストリームの場合、定義により、更新および削除は不可能である。よって、ストリームのサイズは大きくなり続けるしかない。したがって、ストリームの過去の内容のサイズは非常に大きく、ほとんどの場合、ユーザは、アーカイバによって維持される直近の過去のサブセットにしか興味がない。

このため、以下の構文をアーカイブされたストリームのＤＤＬに利用してもよい。

ここで、ＡＲＣＨＩＶＥＲおよびＥＮＴＩＴＹ句は、アーカイブされたリレーション１５４と同じ意味を有し得る。しかしながら、ＥＶＥＮＴ ＩＤＥＮＴＩＦＩＥＲ句は必要でないかもしれない。なぜなら、これは一般的に、ストリームに対して入力として到来することができないマイナスイベントを扱うだけだからである。加えて、ＲＥＰＬＡＹ ＬＡＳＴ句によって、ユーザは、興味ある直近の過去の部分を指定することができる。ユーザはこれを、時間範囲として、または行の数によって指定することができる。よって、たとえば、ＲＥＰＬＡＹ句は、ＲＥＰＬＡＹ ＬＡＳＴ ３０ＭＩＮＵＴＥＳ（この場合過去３０分において到達した記録をアーカイバからフェッチすればよい）、または、ＲＥＰＬＡＹ ＬＡＳＴ ５０ＲＯＷＳ（この場合、到着時間で並べられた最新の５０記録をアーカイバからフェッチすればよい）であってもよい。

ＴＩＭＥＳＴＡＭＰ ＣＯＬＵＭＮ句は、アーカイバにクエリしている間に返されるであろう記録の識別に利用してもよい。これは、アーカイバクエリの結果セットの一部である記録を決定するアーカイバクエリのＷＨＥＲＥ句において使用してもよい。この列の値は、タイムスタンプをＣＱＬエンジン１５６内部のタプル（アーカイバにクエリすることによって得られる）に割当てる間に利用してもよい。この列の名称は、ＢＥＡＭ永続性によって割当てられた作成タイムスタンプを有するＤＯ内の列の名称である可能性がある。

加えて、いくつかの例において、構成ウィンドウモジュール１５０は、ＣＱＬエンジン１５６の１つ以上のアーカイブされたリレーション１５４を構成するためのウィンドウサイズ１５８を、生成する、受ける、および／または決定するように構成されてもよい。しかしながら、いくつかの例において、アーカイブされたリレーションに対して異なるウィンドウサイズを定めても、アーカイブされたリレーションの別々のインスタンスは作成されないかもしれない。むしろ、ウィンドウが適用されたとき、アーカイブされたリレーションのインスタンスは１つしかないかもしれず、ウィンドウは、特定のクエリにとって「興味」があるアーカイブされたリレーションにおけるデータを求めればよい。上記のように、ウィンドウサイズ１５８は、アーカイブされたリレーション１５４のウィンドウｗ１、ｗ２、および／またはｗＮのサイズを構成し得る。このようにして、ユーザは、ウィンドウサイズを制御することができ、希望に応じて、ビジネスイベントデータおよび／または個人的関心、ビジネスの目標、および／またはその他の要素に関連する情報に少なくとも基づいて、ウィンドウのサイズを指定すればよい。

さらに、いくつかの例において、イベントカウントモジュール１５２は、ＣＱＬエンジン１５６内で、または、ストリームもしくはアーカイブされたリレーション１５４の中の変更イベントを正しくカウントできるように構成されたその他のエンジン内で、１つ以上のリスニングサービス１６０を実装するように構成されてもよい。簡単に述べたように、連続クエリ１６２が、ＣＱＬエンジン１５６によって管理されるストリームおよび／またはアーカイブされたリレーション１６４に対する従属性を示すとき、ＣＱＬエンジン１５６はリスニングサービス１６０を実装してもよい。少なくともいくつかの例において、リスニングサービスを実装するタイミングにより、ストリーム／リレーション１６４の中の変更イベントが正しくカウントされるか否かを判断することができる。加えて、上記のように、いくつかの例において、連続クエリ１６２は、履歴および／またはウェアハウスデータのデータ記憶装置１６６に対してクエリすることによって、アーカイブされたリレーション１６４のデータを初期化するように、構成されてもよい。

いくつかの例において、クエリがＣＱＬエンジン１５６内で実行されるとき、これは、最初にクエリをデータオブジェクト補助記憶装置に対して実行することによってデータオブジェクトの現在の状態を確立してからデータオブジェクトからの変更通知をリッスンし処理する場合がある。そうすると２つの問題が生じる。すなわち、ＣＱＬエンジン１５６が最初のクエリを実行している間に変更通知が見落とされるかもしれないことであり、もう１つは、最初のクエリに変更が既にあった場合変更通知が二重カウントされるかもしれないことである。

変更通知の見落としは、最初のクエリが起動される前に変更通知リスナーを確立するが、アーカイバクエリ実行が完了するまでおよび／または状態初期化がなされるまでこれらを処理しないことによって、解消することができる。これら変更通知は、ＣＱＬエンジン１５６がこれらを処理する準備ができるまで、メッセージングサービス（ＪＭＳ）にバッファすればよい。場合によっては、変更通知の二重カウントの解消を、追加情報を永続性サービスに提供することで、どの変更通知が最初のクエリ結果に含まれどの変更通知がこれに含まれていないかＣＱＬエンジン１５６に判断させることにより、実行してもよい。

いくつかの例において、最後のトランザクションのトランザクションＩＤを含む各データオブジェクトに、その他の列を追加する（たとえばＤＡＴＡＯＢＪＥＣＴ＿ＩＤ）ことにより、このデータオブジェクトのインスタンス（行）に影響を及ぼしてもよい。しかしながら、他の例では、その他の列は追加せず、その代わりにトランザクションのコンテキストを利用してもよい。このトランザクションＩＤは、ＪＴＡのような他のトランザクション機構と混同されない内部ＢＥＡＭアーティファクトであってもよい。このトランザクションＩＤは、いくつかの例において、単調に増加する整数であってもよい。同一のＪＴＡトランザクションによって修正されるいくつか（またはすべて）のデータオブジェクトインスタンス（たとえば行）を、同一のトランザクションＩＤでタグ付けしてもよい。加えて、トランザクションＩＤを昇順でコミットしてもよい。この同じ列は、データオブジェクト変更通知に含まれていてもよい。上述のことから、クエリがＭＡＸ（ＤＡＴＡＯＢＪＥＣＴ＿ＴＩＤ）を含む場合、クエリ結果において最大のトランザクションＩＤはわかっているであろう。このため、変更通知におけるトランザクションＩＤの値を、最大値と比較すればよい。なぜなら、それよりも小さいかまたはそれに等しい値は無視すればよく（すなわち既にカウントされているであろうから）、それよりも大きな値を処理すればよい（まだカウントされていないであろうから）。

しかしながら、場合によっては、トランザクションＩＤを昇順でコミットするために、データオブジェクトトランザクションを順番に並べてもよい。しかしながら、これは同時性に不利益な影響を与え得る。それでも、同時性は、コンテキストＩＤの概念を導入することによって高めることができる。いくつかの例において、各コンテキストＩＤはそれ自身のトランザクションＩＤを維持してもよい。ＢＥＡＭデータオブジェクトに対して演算を実行するＪＴＡトランザクションが、ＢＥＡＭコンテキストへの包括的アクセスを得てもよい。次に、同じＢＥＡＭコンテキストを、上記ＪＴＡトランザクションによって実行される演算（たとえばすべての演算）に使用してもよく、最終的には、ＪＴＡトランザクションのコミットまたはロールバック時に解放すればよい。こうすれば、ＢＥＡＭコンテキストにおいて処理を並列に進めることができる。よって、同時性のレベルは、ＢＥＡＭコンテキストの割当てに釣合ったものになるであろう。その他の列（ＤＡＴＡＯＢＪＥＣＴ＿ＣＩＤ）を、各データオブジェクトに追加することにより、最後のコンテキストのＩＤを保持して、そのデータオブジェクトのインスタンス（行）を修正することができる。しかしながら、他の例では、その他の列は追加されず、その代わりにトランザクションコンテキストを利用してもよい。コンテキストＩＤは、トランザクションＩＤのように、データオブジェクトの変更通知に含まれてもよい。しかしながら、これにより、二重カウントを解消するためにコンテキストＩＤに対してＭＡＸ（ＤＡＴＡＯＢＪＥＣＴ＿ＴＩＤ）を取得することを必要とし得るという点において、クエリ側に対する要求が変化し得る。

いくつかの例において、同じレベルの同時性は、トランザクションコンテキストエンティティの概念が導入されるのであれば、データオブジェクトに他の列を追加することなく、得ることができる。次に、新たなＪａｖａクラスおよび関連するＪＰＡエンティティを作成してデータベースにおけるコンテキストＩＤの状態を維持してもよい。トランザクションコンテキストエンティティは、コンテキストＩＤと、関連する（最大、最後に使用された）トランザクションＩＤとを含み得る。コンテキストＩＤはシーケンスとして生成してもよく、エンティティに対する主キーであってもよい。

永続性サービスは、初期化されると、構成された数のトランザクションコンテキストインスタンスを作成してもよい。これらトランザクションコンテキストインスタンスは、この永続性サービスが単独使用するためのものであってもよい。別の永続性サービスが別のサーバ上で初期化される場合、これも、構成された数のトランザクションコンテキストインスタンスを作成してもよい。このやり方で、各永続性サービスがコンテキストの固有のセットを有することを保証してもよい。永続性サービスは、トランザクションコンテキストのインスタンスを作成してもよく、これらをＪＰＡを介して存続させてもよい。これはシーケンス状に並べられたエンティティでありこのシーケンスはコンテキストＩＤであるので、作成されたトランザクションコンテキストインスタンスは自動的に固有のものである。作成された各トランザクションコンテキストは次の連続番号を得るであろう。永続性サービスは、シャットダウンされるとき、作成したトランザクションコンテキストインスタンスを削除してもよい。場合によっては、これによってインスタンスがデータベースから削除されてもよい。

いくつかの例において、データオブジェクト演算（たとえばすべてのまたはいくつかのデータオブジェクト演算）は、最終的にはＥＪＢ法（たとえばプロセスデータオブジェクト演算と呼ばれる）によって行なってもよい。この方法は、挿入、更新、アップサート（upsert）、および／または削除に対する派生があるデータオブジェクト演算の集合体を利用してもよい。各データオブジェクト演算は、対象とするデータオブジェクトを、名称、特定の演算、およびこの演算に必要なデータによって、指定してもよい。データオブジェクト演算は、データオブジェクト演算の対象および／または任意の数のデータオブジェクトの組合わせを含み得る。データオブジェクト演算は、演算がデータオブジェクト演算に追加された順序で実行してもよい。プロセスデータオブジェクト演算法は、ＴｒａｎｓａｃｔｉｏｎＡｔｔｒｉｂｕｔｅＴｙｐｅ．ＲＥＱＵＩＲＥＤとして定義してもよく、これは、ＪＴＡトランザクション内でコールされた場合このトランザクションに参加し得ることを意味する。しかしながらＪＴＡトランザクション外でコールされた場合、アプリケーションサーバは、ＪＴＡトランザクションを、この方法のコールの期間中に起動してもよい。いくつかの例において、このことは、プロセスデータオブジェクト演算が常にＪＴＡトランザクション内で機能しているであろうことを意味する。加えて、データオブジェクトに対するすべてのまたはいくつかの演算は、ＪＴＡトランザクション内で発生し得る。

いくつかの例において、変更イベントの二重カウントの解消は、以下の動作によって可能になるであろう（これは希望に応じて任意の適切な順序で実行すればよい）。たとえば、プロセスデータオブジェクト演算がコールされたときに以下の動作を行なう（以下の動作には番号が付けられているが、これらの番号は、説明を助けるためのものに過ぎず、この一組の動作を特定の順序または必要な何らかの動作に限定するものではない）。

１．関連するＪＴＡトランザクションからトランザクションコンテキストをフェッチすることを試みてもよい。関連するトランザクションコンテキストがある場合はそれを使用すればよい。しかしながら、関連するトランザクションコンテキストがない場合は次のようにする。

ａ）起動時に永続性サービスによって作成された利用可能なトランザクションコンテキストインスタンスのセット（プール）からのトランザクションコンテキストインスタンスに対する排他ロックを取得してもよい。トランザクションコンテキストが利用可能でなければ、トランザクションコンテキストが利用可能になるまでコールをブロックしてもよい。このロックはＪａｖａおよび／またはデータベースにおいて行なってもよい。

ｂ）このトランザクションコンテキストにおけるトランザクションＩＤを、関連するＪＴＡトランザクションのトランザクションＩＤとなり得る、一連の数のうちの次の数に増分してもよい。

ｃ）トランザクションコンテキストインスタンスを、ＪＴＡトランザクションに、アプリケーションリソースとして「添付」してもよい。そうすることによって、この１つのＪＴＡトランザクションの中で複数のコールがなされた場合は、永続性サービスが、トランザクションコンテキストを、その関連するＪＴＡトランザクション（たとえば上記１の動作のもの）を取得することができるであろう。これによって、ＪＴＡトランザクションがＢＥＡＭサーバの中から開始されようとＢＥＡＭサーバなしで開始されようと、同じＪＴＡトランザクションの中で実行される動作に対して同じトランザクションコンテキストを使用できることを保証し得る。

ｄ）トランザクションコンテキストインスタンスを、トランザクション同期リスナーとして、関連するＪＴＡトランザクションに追加してもよい。これによって、永続性サービスに、ＪＴＡトランザクションがいつ完了したか知らせて、適切な動作を行なえるようにすることができる。

ｅ）増分されたトランザクションＩＤを有するトランザクションコンテキストエンティティをマージしてもよい。いくつかの例において、このデータベース更新は、関連するＪＴＡトランザクション内でも発生し得る。

２．指定されたデータオブジェクト動作を実行してもよい。トリガされた変更通知を、トランザクションコンテキストからのコンテキストＩＤおよびトランザクションＩＤでタグ付けしてもよい。

３．プロセスデータオブジェクト演算法のコールが終了し得る。
４．同じＪＴＡトランザクション内で他のコールがなされた場合、上記動作１は、添付された」トランザクションコンテキストをピックアップして動作２に進めばよい。

５．場合によって、ＪＴＡトランザクションがコミットするならば、
ａ）実行されたデータオブジェクト動作をデータベースにコミットしてもよい。

ｂ）データオブジェクトの変更通知を送ってもよい（ＪＭＳ）。
ｃ）トランザクションコンテキストのマージをコミットしてもよい。

ｄ）トランザクションが完了しトランザクションコンテキストを次のトランザクションによる使用のために解放してプールに戻し得ることを、永続性に通知してもよい。いくつかの局面において、これはコミット後のある時点で起こり得る。

６．場合によって、ＪＴＡトランザクションがロールバックするならば、
ａ）実行されたデータオブジェクト動作をロールバックしてもよい。

ｂ）データオブジェクトの変更通知を破棄してもよい（ＪＭＳ）。
ｃ）ＢＥＡＭトランザクションコンテキストのマージをロールバックしてもよい。

ｄ）トランザクションが完了したのでトランザクションコンテキストを次のトランザクションによる使用のために解放してプールに戻し得ることを、永続性に通知してもよい。いくつかの局面において、これはロールバック後に起こり得る。

ある例において、クエリを実行して初期状態をデータオブジェクト補助記憶装置から取得するとき、クエリを不可分的に実行することにより、ＵＮＩＯＮもトランザクションコンテキストテーブルに含めてもよい。このようにして、クエリ結果に加えて、クエリ結果におけるすべてのデータに対する各ＢＥＡＭコンテキストの最大のコミットされたトランザクションＩＤを受けることができる。トランザクションコンテキスト情報は、データオブジェクトの変更通知を検査し変更通知におけるＩＤをトランザクションコンテキストテーブルにおけるＩＤと突合せて検査することによって二重カウントを解消することを、可能にする。これに代えてまたはこれに加えて、クエリの瞬間におけるスナップショット情報を、トランザクションコンテキストテーブルから得てもよい。このスナップショット情報は、ＣＱＬエンジンにおいて維持されてもよく、スナップショットＩＤ（増大する識別子）はこれと関連付けられてもよい。同じものを、このクエリのプランにおける選択されたいくつかの演算子の入力キューに設定してもよい。これらは、「コネクタ」演算子と呼ばれ、ローカルクエリプランがグローバル（全体）クエリプランに結合し得る場所を表わしてもよい。イベントがＣＱＬエンジンに達すると、このイベントに対し、スナップショットＩＤを、その中のコンテキストＩＤおよびトランザクションＩＤの値を用いて計算してもよい。スナップショットＩＤは、ＣＱＬエンジンにおいて維持されているスナップショット情報を用いて計算してもよい。イベントのスナップショットＩＤは次に、入力キューのスナップショットＩＤと比較してもよい。イベントのＩＤ＞キューのＩＤであれば、これを処理をしてもよく、そうでなければ、以前既に考慮されている可能性がありしたがって二重カウントを回避するために無視してもよい。

いくつかの例において、永続性レイヤはコンテキストＩＤ（ワーカー（worker）識別子）およびトランザクションＩＤ（トランザクション識別子）に各変更イベント通知を与えてもよく、および／または、永続性レイヤはトランザクションコンテキストテーブルを維持してもよい。加えて、クエリ起動時に、ＣＱＬエンジンは、トランザクションコンテキストテーブルからの「スナップショット」情報（ワーカー識別子、トランザクション識別子対）にクエリし、増大するスナップショットＩＤをこれに関連付けてもよい。また、ＣＱＬエンジンは、起動時に「コネクタ」演算子の入力キューにスナップショットＩＤを設定してもよい。加えて、クエリ実行時に、ＣＱＬエンジンは、入力イベントにおけるワーカー識別子および／またはトランザクション識別子フィールドと、維持されている「スナップショット」情報を用いて、各入力イベントのスナップショットＩＤを計算してもよい。クエリ実行時に、ＣＱＬエンジンはまた、入力イベントのスナップショットＩＤを、（クエリ起動時の）入力キューにおいて設定されたものと比較することにより、イベントを処理するべきか無視すべきか判断してもよい。以下は、ワーカーおよびトランザクションＩＤ句のＤＤＬの一般的な形態の一例である。

いくつかの例において、アーカイバ（Archiver）はＣＱサービスによって維持されてもよく、エンティティ（Entity）は引用されたストリングとしてのデータオブジェクトの名称であってもよく、イベントＩＤ（Event ID）はこのリレーションに対して固有イベントＩＤ列として機能し得るロングタイプの列であってもよく、ワーカーＩＤ（Worker ID）は永続性の生成された変更通知におけるコンテキストＩＤ列にマッピングし得るロングタイプの列であってもよく、トランザクションＩＤ（Transaction ID）は、永続性の生成された変更通知におけるトランザクションＩＤ列にマッピングし得るロングタイプの列であってもよい。以下は実装例である。

同様に、いくつかの例において、これら２つの句を、アーカイブされたストリームのＲＥＰＬＡＹ句の後に追加してもよい。

先に述べたように、各データオブジェクトインスタンスを、これを修正した最新のコンテキストおよびトランザクションＩＤで実際にタグ付けする必要はないであろう。いくつかの例において、この情報は、代わりにトランザクションコンテキストエンティティから受けることができる。そうするための１つのやり方は、先に述べたように、データオブジェクトからの所望のデータおよびトランザクションコンテキストエンティティの内容双方に対して不可分的にクエリすることである。不可分性実現のために、これを１つのクエリのみを用いて実行してもよい。たとえば、ＵＮＩＯＮ句を用いることにより、２つの異種のクエリからの結果セットを１つのクエリに追加することができる。いくつかの例において、上記データオブジェクトおよび／または永続性サービスは、図１のデータ記憶装置１６６によって実現してもよい。

サービスプロバイダコンピュータ１０６および／またはユーザ装置１０４に存在し得るその他の種類のコンピュータ記録媒体（これも非一時的であってもよい）は、プログラマブルランダムアクセスメモリ（ＰＲＡＭ）、ＳＲＡＭ、ＤＲＡＭ、ＲＡＭ、ＲＯＭ、電気的に消去可能なプログラマブル読出専用メモリ（ＥＥＰＲＯＭ）、フラッシュメモリもしくはその他のメモリ技術、コンパクトディスク読出専用メモリ（ＣＤ−ＲＯＭ）、デジタル汎用ディスク（ＤＶＤ）もしくはその他の記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置もしくはその他の磁気記憶装置、または、所望の情報を格納するのに使用することができサービスプロバイダコンピュータ１０６および／またはユーザ装置１０４からアクセス可能なその他の媒体を含み得るがこれらに限定されない。上記のうちのいずれかを組合わせたものも、コンピュータ読取可能な媒体の範囲に含まれるはずである。

これに代えて、コンピュータ読取可能な通信媒体が、コンピュータ読取可能な命令、プログラムモジュール、または、搬送波等のデータ信号内で伝送されるその他のデータ、またはその他の伝送を含む場合がある。しかしながら、本明細書で使用されるコンピュータ読取可能な記録媒体は、コンピュータ読取可能な通信媒体を含まない。

図２は簡略ブロック図２００を示し、これを用いて、アーカイブされたリレーションを有する連続クエリの管理の特徴を説明することができる。上記の、いくつかの例における、アーカイブされたリレーション、構成可能なアーカイブされたリレーションのウィンドウ、および／または変更イベントのカウントについて、本明細書で説明することができる。示されるように、図２は、（たとえば射影２０３に関連する）アーカイブされたリレーションを管理するための、ＣＱＬエンジン１５６および／またはＣＱサービス２０２の、少なくとも１つの実装例を示す。いくつかの例において、アーカイブされリレーションを含むクエリ（たとえば連続クエリ）１６２が識別されたとき（たとえば、射影２０３に関連するグループ化（Group By）演算子２０４および／または売上情報（Sales Info）演算子２０６が、ストリームまたは履歴データではなくアーカイブされたリレーションを参照する場合）、ＣＱＬエンジン１５６は、このクエリ１６２をパース（parse）してＣＱサービス２０２のアーカイバ２０８に送ってもよい。加えて、いくつかの例において、ＣＱＬエンジン１５６は、この場合クエリ演算子としてのＧｒｏｕｐＡｇｇｒ（またはグループ化２０４）演算子を識別してもよく、この演算子のためのアーカイバクエリを構成してもよい。このアーカイバクエリは次にアーカイバ２０８に送ってもよい。場合によっては、この時点で、ＣＱサービス２０２は外に出てスナップショットを得てもよい（たとえば永続的データ記憶装置１６６からおよび／またはＢＩサーバから）。また、永続性レイヤ（ＢＩ／ＤＢを含む）２１０は多数のエントリを有し得るが、（たとえばグループ化演算子２０４があるので）ＣＱサービス２０２は積の合計を取出すだけでよい。このため、ＣＱＬエンジン１５６は、変更イベント２１２と履歴データ１６６双方を受けることができる。そこで、出力２１４は、データ記憶装置１６６からの元の履歴データに加えて取出した変更イベント２１２を反映し得る。いくつかの例において、−１２，７５という変更イベントを受けると、＋１２，１２５は、出力２１４における更新された合計値を反映し得る。ＣＱＬサービス２０２を変更イベント２１２につなぐ、点線で示した矢印は、ＣＱＬサービス２０２が、変更イベントを、永続性レイヤ２１０から受けた後にＣＱＬエンジン１５６に送ることができることを示している。クエリ１６２における上向きの矢印は、クエリ１６２に関連するクエリプランにおけるイベントの流れを示すことを意図している。

図３は、本開示の実施形態を取入れることができるイベント処理システム３００の簡略化された高レベルの図を示す。イベント処理システム３００は、１つ以上のイベントソース（３０４，３０６，３０８）と、イベントストリームを処理するための環境を提供するように構成されたイベント処理サーバ（ＥＰＳ）３０２と、１つ以上のイベントシンク（３１０，３１２）とを含み得る。イベントソースは、ＥＰＳ３０２が受けるイベントストリームを生成する。ＥＰＳ３０２は、１つ以上のイベントストリームを１つ以上のイベントソースから受けることができる。たとえば、図３に示されるように、ＥＰＳ３０２は、入力イベントストリーム３１４をイベントソース３０４から受け、第２の入力イベントストリーム３１６をイベントソース３０６から受け、第３のイベントストリーム３１８をイベントソース３０８から受ける。１つ以上のイベント処理アプリケーション（３２０，３２２，３２４）をＥＰＳ３０２上で展開しＥＰＳ３０２によって実行することができる。ＥＰＳ３０２によって実行されるイベント処理アプリケーションは、１つ以上の入力イベントストリームをリッスンし、顕著なイベントとして入力イベントストリームから１つ以上のイベントを選択する処理ロジックに基づいて１つ以上のイベントストリームを介して受けたイベントを処理するように、構成されてもよい。顕著なイベントは次に、１つ以上の出力イベントストリームの形態の１つ以上のイベントシンク（３１０，３１２）に送ってもよい。たとえば、図３において、ＥＰＳ３０２は、出力イベントストリーム３２６をイベントシンク３１０に出力し、第２の出力イベントストリーム３２８をイベントシンク３１２に出力する。ある実施形態において、イベントソース、イベント処理アプリケーション、およびイベントシンクは、他の構成要素の変更を引起すことなくこれら構成要素のうちのいずれかを追加または削除することができるように、相互に切離される。

ある実施形態において、ＥＰＳ３０２は、共有サービスを有する、Ｅｑｕｉｎｏｘ ＯＳＧｉに基づくもののような、軽量Ｊａｖａアプリケーションコンテナを含むＪａｖａサーバとして実装してもよい。いくつかの実施形態において、ＥＰＳ３０２は、たとえば、イベントの処理における極めて高いスループットおよびマイクロ秒のレイテンシを、ＪＲｏｃｋｋｉｔ Ｒｅａｌ Ｔｉｍｅを使用することによってサポートし得る。ＥＰＳ３０２はまた、イベント処理アプリケーションを開発するためのツール（たとえばＯｒａｃｌｅ ＣＥＰ ＶｉｓｕａｌｉｚｅｒおよびＯｒａｃｌｅ ＣＥＰ ＩＤＥ）を含む開発プラットフォーム（たとえば完全リアルタイムエンドツーエンドＪａｖａイベント駆動アーキテクチャ（ＥＤＡ）開発プラットフォーム）を提供し得る。

イベント処理アプリケーションは、１つ以上の入力イベントストリームをリッスンし、１つ以上の入力イベントストリームから１つ以上の顕著なイベントを選択するためのロジック（たとえばクエリ）を実行し、選択された顕著なイベントを１つ以上のイベントソースに１つ以上の出力イベントストリームを介して出力するように、構成される。図３はこのようなイベント処理アプリケーション３２０に対するドリルダウンを提供する。図３に示されるように、イベント処理アプリケーション３２０は、入力イベントストリーム３１８をリッスンし、入力イベントストリーム３１８から１つ以上の顕著なイベントを選択するためのロジックを含むクエリ３３０を実行し、選択された顕著なイベントを出力イベントストリーム３２８を介してイベントシンク３１２に出力するように、構成されている。イベントソースの例は、限定されないが、アダプタ（たとえばＪＭＳ、ＨＴＴＰ、およびファイル）、チャネル、プロセッサ、テーブル、キャッシュ等を含む。イベントシンクの例は、限定されないが、アダプタ（たとえばＪＭＳ、ＨＴＴＰ、およびファイル）、チャネル、プロセッサ、キャッシュ等を含む。

図３のイベント処理アプリケーション３２０は、１つの入力ストリームをリッスンし選択されたイベントを１つの出力ストリームを介して出力するものとして示されているが、これは限定を意図したものではない。これに代わる実施形態において、イベント処理アプリケーションは、１つ以上のイベントソースから受けた複数の入力ストリームをリッスンし、モニタリングされたストリームからイベントを選択し、選択されたイベントを１つ以上の出力イベントストリームを介して１つ以上のイベントシンクに出力するように、構成されてもよい。同一のクエリを２つ以上のイベントシンクにおよび異なる種類のイベントシンクに関連付けることができる。

制約がないという性質があるので、イベントストリームを介して受けるデータの量は、一般的に非常に多い。結果として、クエリのためにすべてのデータを格納またはアーカイブすることは、一般的に実用的ではなく望ましくない。イベントストリームの処理では、イベントをＥＰＳ３０２が受けるときに、受けたイベントのデータすべてを格納しなくても、イベントをリアルタイムで処理することが、必要である。したがって、ＥＰＳ３０２は、イベントをＥＰＳ３０２が受けるときに受けたイベントすべてを格納しなくても、イベントを処理できるようにする特別なクエリ機構を提供する。

イベント駆動型アプリケーションはルール駆動型であり、これらルールは、入力ストリームを処理するのに使用される連続クエリの形態で表わすことができる。連続クエリは、受けたイベントに対して実行すべき処理を識別する命令（たとえばビジネスロジック）を含み得る。これは、クエリ処理の結果としてどのようなイベントを顕著なイベントとして選択し出力すべきかを含む。連続クエリは、データ格納装置に存続させ、イベントの入力ストリームを処理しイベントの出力ストリームを生成するために使用することができる。連続クエリは、典型的にはフィルタリングおよび集計関数を実行することにより、入力イベントストリームから顕著なイベントストリームを発見して抽出する。結果として、出力イベントストリームにおける外部へのイベントの数は一般的に、イベントを選択する元になった入力イベントストリームのイベントの数よりも遥かに少ない。

有限のデータ集合に対して一度実行されるＳＱＬクエリと異なり、特定のイベントストリームに対する、ＥＰＳ３０２にアプリケーションによって登録されている連続クエリは、このイベントストリームにおいてイベントを受ける度に実行し得る。連続クエリの実行の一部として、ＥＰＳ３０２は、受けたイベントを、連続クエリによって指定された命令に基づいて評価することにより、連続クエリ実行の結果として、１つ以上のイベントを顕著なイベントとして選択して出力するか否か判断する。

連続クエリは、異なる言語を用いてプログラムしてもよい。ある実施形態において、連続クエリは、Ｏｒａｃｌｅ社が提供するＣＱＬを用いて構成してもよく、Ｏｒａｃｌｅ社のＣｏｍｐｌｅｘ Ｅｖｅｎｔｓ Ｐｒｏｃｅｓｉｎｇ（ＣＥＰ）という製品によって使用してもよい。Ｏｒａｃｌｅ社のＣＱＬは、イベントストリームに対して実行できるクエリ（ＣＱＬクエリと呼ぶ）をプログラムするのに使用することができる宣言型言語である。ある実施形態において、ＣＱＬは、ストリーミングイベントデータの処理をサポートする構造が追加されたＳＱＬに基づく。

一実施形態において、イベント処理アプリケーションは、以下の構成要素タイプからなるものであってもよい。
（１）入力および出力ストリームならびにリレーションソースおよびシンクに対して直接インターフェイスする１つ以上のアダプタ。アダプタは、入力および出力ストリームプロトコルを理解するように構成され、イベントデータを、アプリケーションプロセッサによってクエリできる正規化された形態に変換する役割を果たす。アダプタは、正規化されたイベントデータを、チャネルまたは出力ストリームおよびリレーションシンクに送ってもよい。イベントアダプタは、さまざまなデータソースおよびシンクに対して定めることができる。
（２）イベント処理の終点として機能する１つ以上のチャネル。特に、チャネルは、イベントデータを、イベント処理エージェントがそれに対して働くことが可能になる時点まで、キューに入れておく役割を果たす。
（３）１つ以上のアプリケーションプロセッサ（またはイベント処理エージェント）が、チャネルからの正規化されたイベントデータを消費し、クエリを用いてこれを処理することで顕著なイベントを選択し、選択された顕著なイベントを出力チャネルに送る（またはコピーする）ように、構成される。
（４）１つ以上のビーン（bean）が、出力チャネルをリッスンするように構成され、出力チャネルへの新たなイベントの挿入によってトリガされる。いくつかの実施形態において、このユーザコードは、plain-old-Java-object（ＰＯＪＯ）である。ユーザアプリケーションは、一組の、ＪＭＳ、ウェブサービス、およびファイルライタ（writer）といった外部サービスを利用することによって、生成されたイベントを外部イベントシンクに送ることができる。
（５）イベントビーンは、出力チャネルをリッスンするために登録されてもよく、出力チャネルへの新たなイベントの挿入によってトリガされる。いくつかの実施形態において、このユーザコードは、Ｏｒａｃｌｅ ＣＥＰイベントビーンＡＰＩを用い、このビーンをＯｒａｃｌｅ ＣＥＰによって管理できるようにしてもよい。

一実施形態において、イベントアダプタは、イベントデータを入力チャネルに与える。入力チャネルは、入力チャネルによって与えられたイベントに対して機能する１つ以上のＣＱＬクエリに関連するＣＱＬプロセッサに接続される。ＣＱＬプロセッサは、クエリ結果が書込まれる出力チャネルに接続される。

いくつかの実施形態において、イベント処理アプリケーションに対して、このイベント処理アプリケーションのさまざまな構成要素、これら構成要素が如何にして相互に接続されるか、およびこのアプリケーションによって処理されるイベントタイプを記載した、アセンブリファイルを、与えてもよい。イベントを選択するための連続クエリまたはビジネスロジックを指定するために、別々のファイルを与えてもよい。

図３に示されるシステム３００は、図３に示されている構成要素以外の構成要素を有し得ることが理解されるはずである。さらに、図３に示される実施形態は、本開示の実施形態を取入れることができるシステムの一例に過ぎない。他のいくつかの実施形態では、システム３００の構成要素は図３に示されるものよりも多くても少なくてもよく、２つ以上の構成要素が組合わされてもよく、または構成要素の構成または配置が異なっていてもよい。システム３００は、パーソナルコンピュータ、ポータブルデバイス（たとえば携帯電話または装置）、ワークステーション、ネットワークコンピュータ、メインフレーム、キオスク、サーバ、またはそれ以外のデータ処理システムを含むさまざまな種類のものとすることができる。他のいくつかの実施形態では、システム３００を、システム３００の１つ以上の構成要素がクラウド内の１つ以上のネットワークに分散している分散システムとして構成してもよい。

図３に示される構成要素のうちの１つ以上を、ソフトウェア、ハードウェア、またはその組合わせにおいて実装してもよい。いくつかの実施形態において、ソフトウェアは、メモリ（たとえば非一時的なコンピュータ読取可能な媒体）、メモリデバイス、またはその他の物理メモリに格納されてもよく、１つ以上の処理ユニット（たとえば１つ以上のプロセッサ、１つ以上のプロセッサコア、１つ以上のＧＰＵ等）によって実行されてもよい。

図４は簡略ブロック図４００を示し、これを用いてアーカイブされたリレーションの管理の特徴を説明することができる。図４に示されるように、アーカイブされたリレーションは、クエリグラフ４０２として表わすことができる。いくつかの例において、クエリグラフ４０２は、クエリの演算子を表わすノードおよびクエリグラフ４０２の演算子間の経路を表わす頂点を含み得る。限定されない１つの例において、図４のクエリグラフ４０２は、射影演算子４０４と、グループ化演算子４０６と、リレーショナルソース演算子４０８とを含む。さらに、いくつかの例において、射影演算子４０４およびリレーショナルソース４０８はステートレスでもよく、グループ化演算子４０６はステートフルでもよい。場合によっては、ステートレス演算子は、状態を、追跡、管理、または要求しないが、ステートフル演算子は、状態を、追跡、管理、または要求する。上記のように、いくつかの例において、クエリグラフ４０２を、上から下へというやり方で分析または評価し４１０、ステートフル演算子（いくつかの例では第１のまたは最下位のステートフル演算子）における履歴データをインポートしてもよい。クエリグラフ４０２を分析する４１０間に、クエリグラフ４０２における第１のステートフル演算子を決定するように、サービスおよび／またはエンジン（たとえば図１〜図３を参照しながら説明したＣＱサービス２０２および／またはＣＱＬエンジン１５６）を構成してもよい。図４の例において、第１のステートフル演算子はグループ化４０６である。このため、４１２で、サービスが射影演算子４０４（この例ではステートレス）に達したとき、テーブルデータ（すなわち履歴データ）はインポートしなくてよい。しかしながら、４１４で、グループ化演算子４０６に達したとき、履歴、ウェアハウス、および／またはテーブルデータをインポートして、アーカイブされたリレーションを初期化すればよい。

これに代えてまたはこれに加えて、いくつかの例において、クエリグラフ４０２（プランとも呼ばれる）を、ソース（ここではリレーショナルソース演算子４０８）から初めてトポロジーの順にトラバースしてもよい。このため、この例において、トラバースは下から上へというやり方でもよい。このトラバースにおいて、第１のステートフル演算子に達したとき、これをクエリ演算子としてマークしてもよく、よって、グラフ４０２をこの分岐においてさらにトラバースする必要はない。なお、aggregate distinctのようないくつかのＣＱＬクエリの場合、クエリプランは２つ以上の分岐を有し得る。この例において、リレーショナルソース４０８はステートレスでもよく、そうすると、トラバースは上方向でありグループ化４０６を見ることになるであろう。グループ化４０６はステートフルなので、これは、クエリ演算子としてマークしてもよい。よって、トラバースは完了することができ、射影演算子４０４まで上る必要はないであろう。なぜなら、グループ化４０６はアーカイバにクエリし、その状態を埋め、また、スナップショット出力を射影４０４に伝搬しさらに下流の演算子があればそこに伝搬する。

図５は、（上記）ＴＲＡＮＳＡＣＴＩＯＮ＿ＣＩＤおよび／またはＴＲＡＮＳＡＣＴＩＯＮ＿ＴＩＤ等であるがこれらに限定されない１つ以上のテーブルＩＤを利用して、アーカイブされたリレーションに関連する変更イベントをカウントするための、限定されない少なくとも１つの例５００を示す。図５に示されるように、最初のトランザクションコンテキストテーブル５０２および挿入後のトランザクションコンテキストテーブル５０４が示されている。いくつかの例において、トランザクションＩＤを管理するように構成されたサーバを、初期化するかそうでなければ起動すればよい。永続性サービスは、このサーバによって起動されると、１組のトランザクションインスタンスを作成し得る。このため、トランザクションコンテキストテーブル５０２は、自身が使用するために１０のコンテキストインスタンスを作成した１つの永続性サービスの起動後の内容を示す。ＴＲＡＮＳＡＣＴＩＯＮ＿ＣＩＤ列はコンテキストＩＤを含み、ＴＲＡＮＳＡＣＴＩＯＮ＿ＴＩＤ列はこのコンテキストＩＤによってコミットされる最大トランザクションＩＤを含む。

限定されない１つの例において、この時点で、これも自身が使用するために１０のコンテキストインスタンスを作成した第２の永続性サービスが起動した場合、テーブル０２は、１１〜２０というＴＲＡＮＳＡＣＴＩＯＮ＿ＣＩＤの値を有する１０の新たなエントリを示し得る。この時点で、永続性サービスは実行しているので、データオブジェクト列データタイプ各々を１つずつ含む「アルファ」という名称のデータオブジェクトが作成されるであろう。いくつかの例において、データオブジェクトが作成される度に、永続性サービスはこのデータオブジェクトに対する永続性記憶装置を表わす、対応するデータベースビューを作成してもよい。ある例において、データオブジェクトが生成されると、挿入コマンドがこれに対して実行されてもよい。コンテキストおよびトランザクションＩＤの処理を最も適切に示すために、合計２４の挿入に対して１２のスレッドを用いる１スレッド当たり２つの挿入動作が行なわれてもよい。各スレッドは、ＪＴＡトランザクションを開始し、１つの挿入動作を実行し、第２の挿入動作を実行し、次にトランザクションをコミットしてもよい。複数のスレッドを用いる理由は、そうすれば、並列に実行する複数のＪＴＡトランザクションを作成し得るからであり、このことは、如何にしてコンテキストＩＤが機能するようになるかをより適切に示すであろう。これはまた、複数の（この例では１スレッド当たり２つ）データオブジェクト動作方法コールが同じＪＴＡトランザクションにおいてなされかつこのＪＴＡトランザクションが永続性の外で開始されコミットされたというシナリオを実証する。

この例の場合、１２のスレッドがコードを同時に実行しているであろう。各スレッドは、サーバの外側でトランザクションを開始し、２つの挿入コールを永続性に対して行ない、その後このトランザクションをコミットし得る。永続性は１０のコンテキストＩＤを割当てているので、これらスレッドのうち、１０個はコンテキストを取得するが、２個は最初にブロックされるであろう。２つのＪＴＡトランザクションを、別のＪＴＡトランザクションが完了しコンテキストを解放するまでブロックしてもよい。ブロックされたＪＴＡトランザクションは次に、解放されたコンテキストを捕捉し永続性ＡＰＩコールを処理すればよい。いくつかの例において、挿入動作の完了後、テーブル５０４（挿入後）の検査はまさにこの結果を示す。トランザクションコンテキスト１および２は、トランザクションＩＤ２を「最後にコミットされた」トランザクションＩＤとして示し、他のすべてのトランザクションコンテキストはトランザクションＩＤ１をこれらの最後にコミットされたトランザクションとして示す。

いくつかの例において、データオブジェクト変更通知は、この例において実行された挿入動作の結果としてＪＭＳを介してブロードキャストしてもよい。１つのＪＴＡトランザクション当たり２つの挿入が実行され、合計２４の挿入動作に対して１２のトランザクションが実行されたことを想起されたい。トランザクションコンテキスト１および２は、２つのトランザクション各々に対して使用されたので、２つの挿入についてのトランザクションＩＤ１およびその他２つの挿入についてのトランザクションＩＤ２を有するコンテキスト１および２からの４つの変更通知を見ることになるはずである。他のすべてのコンテキストは、トランザクション１つのみに対して使用されたので、いずれもトランザクションＩＤ１を有する２つの挿入を生成しているはずである。

図６〜図８は、本明細書に記載のアーカイブされたリレーションを有する連続クエリの管理を実装するためのプロセス６００、７００、および８００をそれぞれ示すフロー図の例を示す。これらプロセス６００、７００、８００は、論理フロー図として示され、その各動作は、ハードウェア、コンピュータ命令、またはこれらの組合わせにおいて実装することができる一連の動作を表わす。コンピュータ命令という文脈において、動作は、１つ以上のプロセッサによって実行されるときに、記載されている動作を実行する１つ以上のコンピュータ読取可能な記録媒体に格納されているコンピュータにより実行可能な命令を表わす。一般的に、コンピュータにより実行可能な命令は、特定の機能を果たすまたは特定のデータタイプを実装する、ルーチン、プログラム、オブジェクト、構成要素、データ構造等を含む。動作を説明する順序は限定として解釈されることを意図しておらず、記載されている動作のいくつかを任意の順序でおよび／または並列に組合わせてプロセスを実装することができる。

加えて、プロセスのうちのいくつか、いずれか、またはすべてを、実行可能な命令とともに構成された１つ以上のコンピュータシステムの制御下で実行してもよく、１つ以上のプロセッサ上で、ハードウェアによって、またはこれらの組合わせによって一括で実行するコード（たとえば実行可能な命令、１つ以上のコンピュータプログラム、または１つ以上のアプリケーション）として実装してもよい。上記のように、コードは、たとえば１つ以上のプロセッサにより実行可能な複数の命令を含むコンピュータプログラムの形態で、コンピュータ読取可能な記録媒体に格納してもよい。コンピュータ読取可能な記録媒体は非一時的なものであってもよい。

いくつかの例において、少なくとも図１（およびその他の図面）に示される（たとえば少なくともアーカイブリレーションモジュール１４８を利用する）１つ以上のサービスプロバイダコンピュータ１０６は、図６のプロセス６００を実行し得る。プロセス６００は、６０２で、アーカイブされたストリームまたはアーカイブされたリレーションをデータソースとして識別するクエリを識別するおよび／または受けることを含むことから始まり得る。いくつかの例において、プロセス６００は、６０４で、履歴データを用いてクエリを初期化することを含み得る。プロセス６００は、６０６で、アーカイブされたストリームまたはアーカイブされたリレーションおよび履歴データに少なくとも一部基づいてクエリを評価することを含み得る。プロセス６００はまた、６０８で、クエリの演算子を表わすクエリグラフを形成することを含み得る。プロセス６００は、６１０で、クエリグラフをグラフの上から下にトラバースすることを含み得る。さらに、いくつかの例において、プロセス６００は、６１２で、クエリグラフにおいて識別された第１のステートフル演算子における履歴データを用いてクエリを初期化することを含むことで、終了し得る。

図７は、本明細書に記載のアーカイブされたリレーションを有する連続クエリの管理を実装するためのプロセス７００を示すフロー図の例を示す。少なくとも図１に示される（たとえば少なくともアーカイブリレーションモジュール１４８を利用する）１つ以上のサービスプロバイダコンピュータ１０６は、図７のプロセス７００を実行し得る。プロセス７００は、７０２で、連続クエリを受けて、データストリームまたは履歴データのＩＤを含むデータストリームまたはアーカイブされたリレーションを処理することを含むことから始まり得る。プロセス７００は、７０４で、受けた連続クエリに少なくとも一部基づいてクエリグラフを生成することを含み得る。加えて、いくつかの例において、プロセス７００は、履歴データの一部を用いて連続クエリを初期化することを含み得る。さらに、プロセス７００は、７０８で、データストリームまたはアーカイブされたリレーションに関して履歴データに少なくとも一部基づいて連続クエリを評価することを含むことで、終了し得る。

図８は、本明細書に記載のアーカイブされたリレーションを有する連続クエリの管理を実装するためのプロセス８００を示すフロー図の例を示す。少なくとも図１に示される（たとえば少なくともアーカイブリレーションモジュール１４８を利用する）１つ以上のサービスプロバイダコンピュータ１０６は、図８のプロセス８００を実行し得る。プロセス８００は、８０２で、連続クエリを受けて、ビジネスイベントデータに関連するストリームまたはアーカイブされたリレーションを処理することを含むことから始まり得る。プロセス８００は、８０４で、連続クエリに少なくとも一部基づいてクエリグラフを生成することを含み得る。プロセス８００は、８０６で、クエリグラフを、ソースからトポロジーに従ってトラバースして、最下位のステートフル演算子（たとえば最下位のステートフル演算子はトラバース中に識別される最後のステートフル演算子であってもよく、および／または、これは分岐の演算子であってもよい）。いくつかの例において、プロセス８００は、８０８で、クエリの演算子に少なくとも一部基づいて初期化のための履歴データの最適量を決定することを含み得る。プロセス８００は、８１０で、識別された最下位のステートフル演算子における履歴データを用いて連続クエリを初期化することを含み得る。さらに、いくつかの例において、プロセス８００は、８１２で、データストリームまたはアーカイブされたリレーションに関して履歴データに少なくとも一部基づいて連続クエリを評価することを含むことで、終了し得る。

図９〜図１１は、本明細書に記載の構成可能なデータウィンドウを有するアーカイブされたリレーションを実装するためのプロセス９００、１０００、および１１００をそれぞれ示すフロー図の例を示す。これらプロセス９００、１０００、１１００は、論理フロー図として示され、その各動作は、ハードウェア、コンピュータ命令、またはこれらの組合わせにおいて実装することができる一連の動作を表わす。コンピュータ命令という文脈において、動作は、１つ以上のプロセッサによって実行されるときに、記載されている動作を実行する１つ以上のコンピュータ読取可能な記録媒体に格納されているコンピュータにより実行可能な命令を表わす。一般的に、コンピュータにより実行可能な命令は、特定の機能を果たすまたは特定のデータタイプを実装する、ルーチン、プログラム、オブジェクト、構成要素、データ構造等を含む。動作を説明する順序は限定として解釈されることを意図しておらず、記載されている動作のいくつかを任意の順序でおよび／または並列に組合わせてプロセスを実装することができる。

加えて、プロセスのうちのいくつか、いずれか、またはすべてを、実行可能な命令とともに構成された１つ以上のコンピュータシステムの制御下で実行してもよく、１つ以上のプロセッサ上で、ハードウェアによって、またはこれらの組合わせによって一括で実行するコード（たとえば実行可能な命令、１つ以上のコンピュータプログラム、または１つ以上のアプリケーション）として実装してもよい。上記のように、コードは、たとえば１つ以上のプロセッサにより実行可能な複数の命令を含むコンピュータプログラムの形態で、コンピュータ読取可能な記録媒体に格納してもよい。コンピュータ読取可能な記録媒体は非一時的なものであってもよい。

いくつかの例において、少なくとも図１に示される（たとえば少なくとも構成可能ウィンドウモジュール１５０を利用する）１つ以上のサービスプロバイダコンピュータ１０６は、図９のプロセス９００を実行し得る。プロセス９００は、９０２で、データストリームまたはアーカイブされたリレーションを識別するクエリを識別するかそうでなければ受けることを含むことから始まり得る。プロセス９００は、９０４で、ユーザにより構成されたウィンドウサイズを識別することを含み得る。プロセス９００は、９０６で、履歴データを用いウィンドウサイズに少なくとも一部基づいてクエリを初期化することを含み得る。さらに、プロセス９００は、９０８で、履歴データおよびアーカイブされたストリームまたはアーカイブされたリレーションに少なくとも一部基づいてクエリを評価することを含むことで、終了し得る。

図１０は、本明細書に記載の構成可能なデータウィンドウを有するアーカイブされたリレーションを実装するためのプロセス１０００を示すフロー図の例を示す。少なくとも図１に示される（たとえば少なくとも構成可能ウィンドウモジュール１５０を利用する）１つ以上のサービスプロバイダコンピュータ１０６は、図１０のプロセス１０００を実行し得る。プロセス１０００は、１００２で、データストリームまたはアーカイブされたリレーションを処理するように構成された連続クエリを受けることを含むことから始まり得る。プロセス１０００は、１００４で、連続クエリに少なくとも一部基づいてクエリグラフを生成することを含み得る。プロセス１０００は、１００６で、データストリームまたはアーカイブされたリレーションを処理するように構成された連続クエリからウィンドウサイズを計算することを含み得る。いくつかの例において、プロセス１０００は、１００８で、ウィンドウサイズに少なくとも一部基づいて初期化のための履歴データの量を決定することを含み得る。プロセス１０００は、１０１０で、決定した履歴データを用いて連続クエリを初期化することを含み得る。さらに、プロセス１０００は、１０１２で、アーカイブされたストリームまたはアーカイブされたリレーション、およびウィンドウサイズに関して連続クエリを評価することを含み得る。

図１１は、本明細書に記載の構成可能なデータウィンドウを有するアーカイブされたリレーションを実装するためのプロセス１１００を示すフロー図の例を示す。少なくとも図１に示される（たとえば少なくとも構成可能ウィンドウモジュール１５０を利用する）１つ以上のサービスプロバイダコンピュータ１０６は、図１１のプロセス１１００を実行し得る。プロセス１１００は、１１０２で、アーカイブされたストリームまたはアーカイブされたリレーションを処理するように構成された連続クエリを受けることを含むことから始まり得る。１１０４で、連続クエリからウィンドウサイズを計算して、処理するストリームまたはアーカイブされたリレーションの有界範囲を識別することを含み得る。プロセス１１００は、１１０６で、連続クエリに少なくとも一部基づいてクエリグラフを生成することを含み得る。加えて、いくつかの局面において、プロセス１１００は、ステートフル演算子を識別するためにクエリグラフを下向きに（たとえば上から下へという手法）トラバースすることを含み得る。プロセス１１００は、１１１０で、初期化のための履歴データの最適量を決定することを含み得る。プロセス１１００は、１１１２で、識別されたステートフル演算子における履歴データを用いて連続クエリを初期化することを含み得る。さらに、いくつかの例において、プロセス１１００は、ストリームまたはアーカイブされたリレーションに関してウィンドウサイズに少なくとも一部基づいて連続クエリを評価することを含み得る。

図１２〜図１４は、本明細書に記載のアーカイブされたリレーションに関連するイベントカウントという特徴を実装するためのプロセス１２００、１３００、および１４００をそれぞれ示すフロー図の例を示す。これらプロセス１２００、１３００、１４００は、論理フロー図として示され、その各動作は、ハードウェア、コンピュータ命令、またはこれらの組合わせにおいて実装することができる一連の動作を表わす。コンピュータ命令という文脈において、動作は、１つ以上のプロセッサによって実行されるときに、記載されている動作を実行する１つ以上のコンピュータ読取可能な記録媒体に格納されているコンピュータにより実行可能な命令を表わす。一般的に、コンピュータにより実行可能な命令は、特定の機能を果たすまたは特定のデータタイプを実装する、ルーチン、プログラム、オブジェクト、構成要素、データ構造等を含む。動作を説明する順序は限定として解釈されることを意図しておらず、記載されている動作のいくつかを任意の順序でおよび／または並列に組合わせてプロセスを実装することができる。

加えて、プロセスのうちのいくつか、いずれか、またはすべてを、実行可能な命令とともに構成された１つ以上のコンピュータシステムの制御下で実行してもよく、１つ以上のプロセッサ上で、ハードウェアによって、またはこれらの組合わせによって一括で実行するコード（たとえば実行可能な命令、１つ以上のコンピュータプログラム、または１つ以上のアプリケーション）として実装してもよい。上記のように、コードは、たとえば１つ以上のプロセッサにより実行可能な複数の命令を含むコンピュータプログラムの形態で、コンピュータ読取可能な記録媒体に格納してもよい。コンピュータ読取可能な記録媒体は非一時的なものであってもよい。

いくつかの例において、少なくとも図１に示される（たとえば少なくともイベントカウントモジュール１５２を利用する）１つ以上のサービスプロバイダコンピュータ１０６は、図１２のプロセス１２００を実行し得る。プロセス１２００は、１２０２で、データオブジェクトを識別するクエリを識別することを含むことから始まり得る。プロセス１２００は、１２０４で、データオブジェクトに関連する履歴データに対してクエリを評価することを含み得る。プロセス１２００は、１２０６で、データオブジェクトにリスニングサービスを登録することを含み得る。プロセス１２００はまた、１２０８で、リスニングサービスによって識別された変更のトランザクションＩＤを受けることを含み得る。いくつかの例において、プロセス１２００は、１２１０で、トランザクションＩＤを履歴データの最大トランザクションＩＤと比較することを含み得る。プロセス１２００は、１２１２で、受けたトランザクションＩＤが最大トランザクションＩＤよりも大きい場合のみ変更を処理することを含み得る。プロセス１２００は、１２１４で、データオブジェクトおよび履歴データに少なくとも一部基づいてクエリを評価することを含むことで、終了し得る。

図１３は、本明細書に記載の構成可能なデータウィンドウを有するアーカイブされたリレーションを実装するためのプロセス１３００を示すフロー図の例を示す。少なくとも図１に示される（たとえば少なくともイベントカウントモジュール１５２を利用する）１つ以上のサービスプロバイダコンピュータ１０６は、図１３のプロセス１３００を実行し得る。プロセス１３００は、１３０２で、データオブジェクトを識別するかそうでなければ受ける連続クエリを受けることを含むことから始まり得る。プロセス１３００は、１３０４で、データオブジェクトに関連するリスニングサービスを登録することを含み得る。加えて、いくつかの例において、プロセス１３００は、１３０６で、リスニングサービスの登録後に連続クエリを履歴データに対して評価することを含み得る。プロセス１３００は、１３０８で、履歴データに対する評価後にリスニングサービスによって識別された変更を処理することを含み得る。プロセス１３００は、１３１０で、データオブジェクトに対して連続クエリを評価することを含むことで、終了し得る。

図１４は、本明細書に記載の構成可能なデータウィンドウを有するアーカイブされたリレーションを実装するためのプロセス１４００を示すフロー図の例を示す。少なくとも図１に示される（たとえば少なくともイベントカウントモジュール１５２を利用する）１つ以上のサービスプロバイダコンピュータ１０６は、図１４のプロセス１４００を実行し得る。プロセス１４００は、１４０２で、データオブジェクトを処理するように構成された連続クエリを受けることを含むことから始まり得る。プロセス１４００は、１４０４で、データオブジェクトにリスニングサービスを登録することを含み得る。プロセス１４００は、１４０６で、データオブジェクトに関連する履歴データに対して連続クエリを評価することを含み得る。いくつかの例において、プロセス１４００はまた、１４０８で、リスニングサービスによって識別された変更のトランザクションＩＤを受けることを含み得る。加えて、プロセス１４００は、１４１０で、受けたトランザクションＩＤを現在履歴データに関連する最大トランザクションＩＤと比較することを含み得る。プロセス１４００は、１４１２で、受けたＩＤが履歴データに関連する最大ＩＤよりも大きい場合に変更を処理することを含み得る。プロセス１４００は、１４１４で、データオブジェクトに関して連続クエリを評価することを含むことで、終了し得る。

連続クエリおよびスケジュールされたクエリの混成の実行を実装するための、例示としての方法およびシステムについては上記の通りである。これらシステムおよび方法のうちのいくつかまたはすべては、少なくとも上記図１〜図１４に示されるもののようなアーキテクチャおよびプロセスによって少なくとも部分的に実装し得るが、そうすることが必要な訳ではない。

図１５は、本開示の実施形態に従い使用し得るシステム環境１５００の構成要素を示す簡略ブロック図である。図に示されるように、システム環境１５００は、１つ以上のクライアントコンピューティング装置１５０２、１５０４、１５０６、１５０８を含み、これら装置は、ウェブブラウザまたは専用のクライアント（たとえばOracle Forms）等のクライアントアプリケーションを、（図１および図３のネットワーク１０８と同様のネットワーク等であるがこれに限定されない）１つ以上のネットワーク１５１０を通して操作するように構成されている。さまざまな実施形態において、クライアントコンピューティング装置１５０２、１５０４、１５０６、および１５０８は、ネットワーク１５１０を通してサーバ１５１２と情報をやり取りし得る。

クライアントコンピューティング装置１５０２、１５０４、１５０６、１５０８は、汎用のパーソナルコンピュータ（例として、さまざまなバージョンのMicrosoft Windows（登録商標）および／またはApple Macintoshオペレーティングシステムを実行するパーソナルコンピュータおよび／またはラップトップコンピュータを含む）、携帯電話もしくはＰＤＡ（Microsoft Windows Mobile等のソフトウェアを実行し、インターネット、電子メール、ＳＭＳ、ブラックベリー（Blackberry）、またはその他の通信プロトコルを使用可能）、および／またはさまざまな市販のＵＮＩＸ（登録商標）もしくはＵＮＩＸのようなオペレーティングシステム（さまざまなＧＮＵ／Ｌｉｎｕｘ（登録商標）オペレーティングシステムを含むがこれに限定されない）のいずれかを実行するワークステーションコンピュータであってもよい。これに代えて、クライアントコンピューティング装置１５０２、１５０４、１５０６、および１５０８は、ネットワーク（たとえば以下で説明するネットワーク１５１０）を通して通信可能なシンクライアントコンピュータ、インターネットを使用可能なゲーム機、および／またはパーソナルメッセージングデバイス等のその他の電子デバイスであってもよい。典型的なシステム環境１５００が４つのクライアントコンピューティング装置とともに示されているが、クライアントコンピューティング装置の数はいくつであってもそれらをサポートし得る。センサ等を有する装置等の他の装置がサーバ１５１２と情報をやり取りしてもよい。

システム環境１５００はネットワーク１５１０を含み得る。ネットワーク１５１０は、ＴＣＰ／ＩＰ、ＳＮＡ、ＩＰＸ、ＡｐｐｌｅＴａｌｋ等を含むがこれらに限定されないさまざまな市販のプロトコルのいずれかを用いたデータ通信をサポートできる、当業者によく知られているネットワークであれば、どのような種類のネットワークであってもよい。単なる例として、ネットワーク１５１０は、イーサネット（登録商標）ネットワーク、トークンリングネットワーク等のローカルエリアネットワーク（ＬＡＮ）、ワイドエリアネットワーク、バーチャルプライベートネットワーク（ＶＰＮ）を含むがこれに限定されないバーチャルネットワーク、インターネット、イントラネット、エクストラネット、公衆電話交換回線網（ＰＳＴＮ）、赤外線ネットワーク、ワイヤレスネットワーク（たとえば、IEEE 802.11プロトコル群のいずれかの下で動作するネットワーク、当該技術分野において公知のブルートゥース（登録商標）プロトコル、および／またはその他のワイヤレスプロトコル）、および／または、これらおよび／または他のネットワークの任意の組合わせであってもよい。

システム環境１５００はまた、１つ以上のサーバコンピュータ１５１２を含み、このサーバコンピュータは、汎用コンピュータ、専用サーバコンピュータ（例として、ＰＣサーバ、ＵＮＩＸサーバ、ミッドレンジサーバ、メインフレームコンピュータ、ラックマウント式（rack-mounted）のサーバ等を含む）、サーバファーム、サーバクラスタ、またはその他の適切な配置および／または組合わせであってもよい。さまざまな実施形態において、サーバ１５１２は、本願のこれまでの開示において説明された１つ以上のサービスまたはソフトウェアアプリケーションを実行するようにされていてもよい。たとえば、サーバ１５１２は、本開示の一実施形態に従う上記処理を実行するためのサーバに相当するものであってもよい。

サーバ１５１２は、上述したオペレーティングシステムのうちのいずれかおよび任意の市販のサーバオペレーティングシステムを含むオペレーティングシステムを実行してもよい。また、サーバ１５１２は、ＨＴＴＰサーバ、ＦＴＰサーバ、ＣＧＩサーバ、Ｊａｖａサーバ、データベースサーバ等を含むさまざまなその他のサーバアプリケーションおよび／またはミッドティア（mid-tier）アプリケーションのうちのいずれかを実行してもよい。典型的なデータベースサーバは、Ｏｒａｃｌｅ、Ｍｉｃｒｏｓｏｆｔ、Ｓｙｂａｓｅ、ＩＢＭ等から市販されているものを含むが、これらに限定されない。

また、システム環境１５００は１つ以上のデータベース１５１４、１５１６を含み得る。データベース１５１４、１５１６は、さまざまな場所に存在し得る。例として、データベース１５１４、１５１６のうちの１つ以上は、サーバ１５１２に対してローカルな（および／またはサーバ１５１２内に常駐している）非一時的な記録媒体に存在していてもよい。これに代えて、データベース１５１４、１５１６は、サーバ１５１２から離れていてネットワークベースまたは専用回線を介してサーバ１５１２と通信してもよい。一連の実施形態では、データベース１５１４、１５１６は、当業者によく知られているストレージエリアネットワーク（ＳＡＮ）に存在していてもよい。同様に、サーバ１５１２による機能を実行するために必要なファイルは、必要に応じて、サーバ１５１２に対してローカルにおよび／または遠隔で格納されてもよい。一組の実施形態において、データベース１５１４、１５１６は、ＳＱＬフォーマットのコマンドに応答してデータを格納し、更新し、取出すようにされている、Ｏｒａｃｌｅから提供されているデータベース等のリレーショナルデータベースを含み得る。

図１６は、本開示の実施形態に従い使用し得るコンピュータシステム１６００の簡略ブロック図である。たとえば、サービスプロバイダコンピュータ１０６を、システム１６００のようなシステムを用いて実装してもよい。バス１６０１を介して電気的におよび／または通信可能に結合し得るハードウェア構成要素を含むコンピュータシステム１６００が示されている。このハードウェア構成要素は、１つ以上の中央処理装置（ＣＰＵ）１６０２と、１つ以上の入力装置１６０４（たとえばマウス、キーボード等）と、１つ以上の出力装置１６０６（たとえばディスプレイ装置、プリンタ等）とを含み得る。また、コンピュータシステム１６００は、１つ以上の記憶装置１６０８を含み得る。例として、記憶装置１６０８は、ディスクドライブ、光学式記憶装置等の装置、ならびに、プログラム可能で、一瞬で更新可能で（flash-updateable）、および／またはそれと同じようなことが可能であるランダムアクセスメモリ（ＲＡＭ）および／または読出専用メモリ（ＲＯＭ）等のソリッドステート記憶装置を含み得る。

コンピュータシステム１６００は、さらに、コンピュータ読取可能記録媒体リーダ１６１２と、通信サブシステム１６１４（たとえばモデム、ネットワークカード（無線または有線）、赤外線通信装置等）と、ワーキングメモリ１６１８とを含み得る。ワーキングメモリ１６１８は、上記ＲＡＭおよびＲＯＭ装置を含み得る。いくつかの実施形態において、コンピュータシステム１６００は、デジタル信号プロセッサ（ＤＳＰ）、専用プロセッサ、および／またはそれと同様のものを含み得る処理加速部１６１６を含んでいてもよい。

コンピュータ読取可能記録媒体リーダ１６１２は、さらに、コンピュータ読取可能な記録媒体１６１０に接続し得る。コンピュータ読取可能記録媒体１６１０は、（任意に、記憶装置１６０８と組合わせて）リモート式、ローカル式、固定式および／または着脱交換式の記憶装置、および、一時的および／またはより永続的にコンピュータ読取可能な情報を収容するための記録媒体を総合的に意味している。通信システム１６１４によって、ネットワーク１６１２および／またはシステム環境１６００に関連する上述のその他のコンピュータと、データをやり取りすることが可能であってもよい。

また、コンピュータシステム１６００は、ワーキングメモリ１６１８内に現在位置しているものとして示されているソフトウェア構成要素を含み得る。このソフトウェア構成要素は、オペレーティングシステム１６２０、および／または、アプリケーションプログラム（クライアントアプリケーション、ウェブブラウザ、ミッドティアアプリケーション、ＲＤＢＭＳ等であってもよい）等のその他のコード１６２２を含む。典型的な実施形態において、ワーキングメモリ１６１８は、実行可能なコードと、上述のように証明書利用者およびオープン認可関連の処理に使用される関連のデータ構造とを含んでいてもよい。コンピュータシステム１６００の代替の実施形態には、上述のものの多くの変形例があり得ることが理解されるはずである。たとえば、カスタマイズされたハードウェアが用いられてもよく、および／または特定の構成要素がハードウェア、ソフトウェア（アプレット等のポータブルソフトウェアを含む）またはそれら両方において実装されてもよい。さらに、ネットワーク入出力装置等の他のコンピューティング装置への接続を用いてもよい。

図１７は、本明細書に記載のアーカイブされたリレーションを有する連続クエリの管理を実装するためのプロセス１７００を示すフロー図の別の例を示す。少なくとも図１に示される（たとえば少なくともアーカイブリレーションモジュール１４８を利用する）１つ以上のサービスプロバイダコンピュータ１０６は、図１７のプロセス１７００を実行し得る。プロセス１７００は、１７０２で、アーカイブされたリレーションに少なくとも一部基づいてクエリを識別することを含むことから始まり得る。プロセス１７００は、１７０４で、クエリの演算子を利用してクエリ演算子グラフを生成することを含み得る。加えて、いくつかの例において、プロセス１７００は、１７０６で、演算子グラフを（たとえばトポロジーに従って）ソートすることを含み得る。プロセス１７００は、１７０８で、グラフを分析しアーカイバにクエリし得る演算子を決定して状態（たとえばステートフル演算子）を初期化することを含み得る。プロセス１７００は、１７１０で、アーカイバに与える適切なクエリ（たとえばアーカイバクエリ）を構成することを含み得る。いくつかの例において、プロセス１７００は、１７１２で、オペレータシェアリングについて判断することを含み得る。プロセス１７００は、１７１４で、（たとえば上記のように）アーカイバクエリをＣＱサービスに対して発行することにより、決定された演算子の状態を初期化することを含み得る。プロセス１７００は、１７１６で、履歴結果を（たとえばＣＱサービスまたは永続性から）受けてもよい。さらに、プロセス１７００は、１７１８で、まだカウントされていない場合到来したイベントを履歴結果にクエリすることの一部として処理することを含むことで、終了し得る。

図１８は、本明細書に記載のアーカイブされたリレーションを有する連続クエリの管理を実装するためのプロセス１８００を示すフロー図の別の例を示す。少なくとも図１に示される（たとえば少なくとも構成可能ウィンドウモジュール１５０を利用する）１つ以上のサービスプロバイダコンピュータ１０６は、図１８のプロセス１８００を実行し得る。プロセス１８００は、１８０２で、アーカイバソースに対するアーカイバクエリを評価し１つ以上のスナップショット出力を取得することを含むことから始まり得る。プロセス１８００は、１８０４で、リレーションに対するウィンドウを、構成可能な２つのパラメータのうちの少なくとも１つを利用して、指定することを含み得る。構成可能なパラメータは、ウィンドウサイズおよび／またはリレーション属性を含む。加えて、いくつかの例において、プロセス１８００は、１８０６で、各スナップショットタプルについて、指定された属性の値を現在のイベント時間と比較することにより、タプルがウィンドウの中にあるか否かテストすることを含み得る。プロセス１８００は、１８０８で、スナップショットタプルがテストにパスしたか否か判断することを含み得る。いくつかの例において、テストにパスした場合、プロセス１８００は、１８１０で、タプルをウィンドウに挿入することを含み得る。しかしながら、いくつかの例において、テストにパスしなかった場合、プロセス１８００は、１８１２で、その代わりにタプルを無視することを含み得る。プロセス１８００は次に１８０２に戻り終了するかまたは、次のアーカイバクエリを評価することを含み得る。

図１９は、本明細書に記載のアーカイブされたリレーションを有する連続クエリの管理を実装するためのプロセス１９００を示すフロー図の別の例を示す。少なくとも図１に示される（たとえば少なくともイベントカウントモジュール１５２を利用する）１つ以上のサービスプロバイダコンピュータ１０６は、図１９のプロセス１９００を実行し得る。プロセス１９００は、１９０２で、状態演算子についてデータオブジェクトにクエリすることを含むことから始まり得る。プロセス１９００は、１９０４で、トランザクションコンテキストテーブルからスナップショット情報を得ることを含み得る。プロセス１９００は、１９０６で、スナップショット情報をＣＱＬエンジンにおいて維持し関連するスナップショットＩＤを増加させることを含み得る。プロセス１９００は、１９０８で、スナップショットＩＤをクエリプランの「コネクタ」演算子に設定することを含み得る。「コネクタ」演算子は、ローカルプランをグローバルプランに結合し得る。プロセス１９００は、１９１０で、到着するイベントのスナップショットＩＤを、イベントにおけるコンテキストＩＤ（ＣＩＤ）およびトランザクションＩＤ（ＴＩＤ）を用いて計算することを含み得る。プロセス１９００は、１９１２で、イベントのスナップショットＩＤを入力キューのスナップショットＩＤと比較することを含み得る。プロセス１９００は、１９１４で、イベントのＩＤが入力キューのＩＤよりも大きいか否か判断することを含み得る。いくつかの例において、１９１４でイベントＩＤがキューＩＤよりも大きい場合、プロセス１９００は、イベントを処理することを含み得る。しかしながら、いくつかの例において、１９１４でイベントＩＤがキューＩＤよりも大きくない場合、プロセスは１９１８でその代わりにイベントを無視することを含み得る。プロセス１９００は次に１９０２に戻って終了するかまたは再び開始する。

これに代えてまたはこれに加えて、クエリの瞬間におけるスナップショット情報を、トランザクションコンテキストテーブルから得てもよい。このスナップショット情報は、ＣＱＬエンジンにおいて維持されてもよく、スナップショットＩＤ（増大する識別子）はこれと関連付けられてもよい。同じものを、このクエリのプランにおける選択されたいくつかの演算子の入力キューに設定してもよい。これらは、「コネクタ」演算子と呼ばれ、ローカルクエリプランがグローバル（全体）クエリプランに結合し得る場所を表わしてもよい。イベントがＣＱＬエンジンに達すると、このイベントに対し、スナップショットＩＤを、その中のコンテキストＩＤおよびトランザクションＩＤの値を用いて計算してもよい。スナップショットＩＤは、ＣＱＬエンジンにおいて維持されているスナップショット情報を用いて計算してもよい。イベントのスナップショットＩＤは次に、入力キューのスナップショットＩＤと比較してもよい。イベントのＩＤ＞キューのＩＤであれば、これを処理をしてもよく、そうでなければ、以前既に考慮されている可能性がありしたがって二重カウントを避けるために無視してもよい。コードまたはコードの一部を収容するための記録媒体およびコンピュータ読取可能な媒体は、当該技術において公知のまたは使用されているあらゆる適切な媒体を含み得る。上記適切な媒体は記録媒体および通信媒体を含み、これら記録媒体および通信媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリもしくはその他のメモリ技術、ＣＤ−ＲＯＭ、デジタル汎用ディスク（ＤＶＤ）もしくはその他の光学記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置もしくはその他の磁気記憶装置、データ信号、データ伝送、または、所望の情報を格納もしくは伝送するために使用することができコンピュータによってアクセス可能なその他の媒体を含む、コンピュータ読取可能な命令、データ構造、プログラムモジュール、またはその他のデータ等の情報の、格納および／または伝送のための何等かの方法または技術において実装される、揮発性および不揮発性（非一時的）の着脱可能および着脱不能な媒体等であるが、これらに限定されない。

本開示の特定の実施形態について説明してきたが、さまざまな修正、変更、代替構成、および均等物も、本開示の範囲に包含される。上記さまざまな修正、変更、代替構成、および均等物は、開示されている特徴の妥当な組合わせを含む。本開示の実施形態は、ある特定のデータ処理環境内での動作に限定されるものではなく、複数のデータ処理環境内で機能することが可能である。加えて、本開示の実施形態について、特定の一連のトランザクションおよびステップを用いて説明してきたが、本開示の範囲が、記載されている一連のトランザクションおよびステップに限定されないことは、当業者には明らかなはずである。

さらに、本開示の実施形態について、ハードウェアとソフトウェアの特定の組合わせを用いて説明してきたが、ハードウェアとソフトウェアの他の組合わせも本開示の範囲内であることが認識されるはずである。本開示の実施形態は、ハードウェアのみで実装されてもよく、ソフトウェアのみで実装されてもよく、これらの組合わせを用いて実装されてもよい。

したがって、明細書および図面は、限定的な意味ではなく例示的な意味で考慮されねばならない。しかしながら、これに対し、追加、控除、削除、およびその他の修正および変更を、より広い精神および範囲から逸脱することなく行ない得ることは明らかであろう。本開示の特徴を示すための例示的な方法およびシステムは上述の通りである。これらのシステムおよび方法のうちのいくつかまたはすべては、上記図１〜図１２に示されるもののようなアーキテクチャによって、少なくとも部分的に実装し得るが、そうすることが必要な訳ではない。

実施形態について、構造的特徴および／または方法論的行為に特有の表現で説明してきたが、本開示は記載されている具体的な特徴または行為に必ずしも限定されないことが理解されるはずである。むしろ、この具体的な特徴および行為は、実施形態を実装する例示的な形態として開示されている。条件表現、特に「できる」または「してもよい」（「can」、「could」、「might」、または「may」）等は、特に明記されない限りまたは使用されている文脈の中で他の解釈がなされない限り、何らかの特徴、要素、および／またはステップを、ある実施形態は含み得るがそれ以外の実施形態は含まないことを示唆することを、概ね意図している。よって、このような条件表現は、特徴、要素、および／またはステップが、１つ以上の実施形態に多少なりとも必要であることを、または、これら特徴、要素、および／またはステップがいずれか特定の実施形態に含まれるのかまたはいずれか特定の実施形態において実施されるのかをユーザの入力または刺激の有無に関わらず判断するための論理を１つ以上の実施形態が必然的に含むことを、示唆することは、概ね意図していない。

Claims (26)

1. システムであって、
   少なくともデータストリームを識別するクエリを識別するための手段と、
   履歴データの少なくとも一部を用いて前記クエリを初期化するための手段と、
   前記データストリームおよび前記履歴データの一部に少なくとも一部基づいて前記クエリを評価するための手段とを備える、システム。
2. 前記クエリは、到来する前記データストリームのリアルタイムデータまたは前記データストリームのアーカイブされたリレーションを処理するように構成された連続クエリを含む、請求項１に記載のシステム。
3. 前記リアルタイムデータは、少なくともビジネスイベントデータを含む、請求項２に記載のシステム。
4. 前記データストリームは、ウィンドウを用いて構成されたリレーションを含み、前記ウィンドウは、前記ウィンドウの中の前記データストリームの一部を参照するためのものである、請求項１または３のいずれかに記載のシステム。
5. 前記ウィンドウは、時間の経過とともに前記データストリームに沿って移動するように構成される、請求項４に記載のシステム。
6. 前記履歴データは、前記クエリの初期化後のある時点における前記データストリームに含まれない、請求項１〜５のいずれか一項に記載のシステム。
7. 前記クエリはさらに前記履歴データを識別する、請求項１〜６のいずれか一項に記載のシステム。
8. 前記履歴データは、前記クエリの初期化前のある時点における前記データストリームからのビジネスイベントデータを含む、請求項１〜７のいずれか一項に記載のシステム。
9. 前記クエリを評価することは、前記クエリの演算子を表わすノードを用いてクエリグラフを少なくとも形成することを含む、請求項１〜８のいずれか一項に記載のシステム。
10. 前記ノードのうちの少なくとも１つはウィンドウサイズを識別する、請求項９に記載のシステム。
11. 複数の命令を実行することにより、前記クエリグラフをトポロジーの順序で少なくともトラバースするための手段をさらに備える、請求項９または１０に記載のシステム。
12. 前記クエリグラフにおいて識別された最下位のステートフル演算子における少なくとも前記履歴データを用いて前記クエリを初期化するための手段をさらに備える、請求項１１に記載のシステム。
13. 構成可能なウィンドウサイズを識別するための手段をさらに備える、請求項１１に記載のシステム。
14. 前記クエリは、前記構成可能なウィンドウサイズに少なくとも一部基づいて初期化される、請求項１３に記載のシステム。
15. 前記クエリを評価することは、構成可能なウィンドウサイズに少なくとも一部基づいて前記データストリームに対して前記クエリを少なくとも適用することを含む、請求項１に記載のシステム。
16. 前記データストリームは、第２のウィンドウの中の前記データストリームの一部を参照するための第２の構成可能なウィンドウサイズを用いて構成されたリレーションを含み、前記第２のウィンドウのサイズは、第２の構成可能なウィンドウサイズに少なくとも一部基づく、請求項１〜１５のいずれか一項に記載のシステム。
17. 第２のウィンドウは、時間の経過とともに前記データストリームに沿って移動するように構成される、請求項１に記載のシステム。
18. １つ以上のプロセッサにより実行可能な複数の命令を格納するコンピュータ読取可能なプログラムであって、前記複数の命令は、
    データストリームを処理するように構成された連続クエリを受けることを、前記１つ以上のプロセッサに行なわせる命令を含み、前記連続クエリは、前記データストリームの識別子および履歴データの識別子のうちの少なくとも１つを含み、
    前記連続クエリに少なくとも一部基づいてクエリグラフを生成することを、前記１つ以上のプロセッサに行なわせる命令と、
    履歴データの少なくとも一部を用いて前記連続クエリを初期化することを、前記１つ以上のプロセッサに行なわせる命令と、
    前記データストリームに関して前記履歴データに少なくとも一部基づいて前記連続クエリを評価することを、前記１つ以上のプロセッサに行なわせる命令とを含む、コンピュータ読取可能なプログラム。
19. 前記データストリームおよび前記履歴データのうちの少なくとも一方は、前記連続クエリのデータ定義言語アノテーションによって識別される、請求項１８に記載のコンピュータ読取可能なプログラム。
20. 前記データ定義言語アノテーションは、前記履歴データの場所、前記データストリームのソース、前記データストリームに関連するデータオブジェクト、前記連続クエリの処理に関連する動作情報、前記履歴データに対応するデータベースの関連する１つ以上の列、前記連続クエリの出力に対応するデータオブジェクト、および、前記連続クエリの出力を提供するための場所のうちの少なくとも１つを識別する、請求項１９に記載のコンピュータ読取可能なプログラム。
21. 前記クエリグラフは、前記連続クエリの演算子を表わす少なくともノードを含む、請求項１８に記載のコンピュータ読取可能なプログラム。
22. 前記連続クエリは、前記クエリグラフをトポロジーの順でトラバースする間に、前記クエリグラフのステートフル演算子における前記履歴データの少なくとも一部を用いて初期化される、請求項１８に記載のコンピュータ読取可能なプログラム。
23. 方法であって、
    ビジネスイベントデータのストリームを処理するように構成された連続クエリを受けることを含み、前記連続クエリは、前記ストリームの識別子と前記ストリームに関連する履歴データの識別子とを含み、
    前記連続クエリに少なくとも一部基づいてクエリグラフを生成することを含み、前記クエリグラフは、前記連続クエリの演算子を表わす少なくともノードを含み、
    前記クエリグラフをトラバースして最下位のステートフル演算子を識別することと、
    前記識別された最下位のステートフル演算子における履歴データの少なくとも一部を用いて前記連続クエリを初期化することと、
    前記ストリームに関して前記履歴データに少なくとも一部基づいて前記連続クエリを評価することとを含む、方法。
24. 前記履歴データは、前記ストリームの前の時点からのビジネスイベントデータを含む、請求項２３に記載の方法。
25. 前記連続クエリの演算子に少なくとも一部基づいて前記連続クエリを初期化するために用いる前記履歴データの最適量を決定することをさらに含む、請求項２３に記載の方法。
26. 前記ステートフル演算子は、前記連続クエリの少なくとも１つのノードの評価に少なくとも一部基づいて識別される、請求項２３に記載の方法。

Images