JP2015536001A - 連続クエリをチェーン接続するための機構 - Google Patents

Abstract

連続クエリをチェーン接続するための機構を実装する技術が提供される。いくつかの例において、第１の連続クエリの結果はデータオブジェクトに格納し得る。たとえば、第１の連続クエリは、ビジネスイベントデータを処理し結果をデータオブジェクトに格納するように構成し得る。加えて、次に第２の連続クエリを、データオブジェクトに格納されている結果に少なくとも一部基づいて処理し得る。

Description

関連出願の相互参照
本願は、２０１３年３月１４日に出願され「Mechanism to Chain Continuous Queries（連続クエリをチェーン接続するための機構）」と題された米国特許出願第１３／８３０，７３５号（代理人整理番号８８３２５−８５９８２１（１２８０８０ＵＳ））、および、２０１２年９月２８日に出願され「Real-time Business Event Analysis and Monitoring（リアルタイムビジネスイベント分析およびモニタリング）」と題された米国仮出願第６１／７０７，６４１号に基づく優先権と利益を主張し、すべての目的のために各出願の内容全体を本明細書に引用により援用する。

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

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

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

概要
連続クエリをチェーン接続するための技術が提供される。少なくとも１つの例に従うと、システムは、複数の命令を格納するためのメモリと、このメモリにアクセスするように構成された１つ以上のプロセッサとを含み得る。いくつかの例において、上記１つ以上のプロセッサは、上記複数の命令を実行することにより、第１の連続クエリの結果をデータオブジェクトに少なくとも格納するように構成し得る。第１の連続クエリは、ビジネスイベントデータ（たとえば、特定のビジネスエンティティに関連する動作、イベント、および／またはトランザクションのログ情報）を処理するように構成し得る。いくつかの例において、ビジネスイベントデータは、トランザクションを記録するように作成された記録を含み得るがこれに限定されない。この記録は場合によってはタイムスタンプを含み得る。加えて、いくつかの例において、上記１つ以上のプロセッサはさらに、上記複数の命令を実行することにより、第２の連続クエリを、データオブジェクトに格納されている結果に少なくとも一部基づいて、少なくとも処理するように構成し得る。さらに、いくつかの例において、上記１つ以上のプロセッサはさらに、上記複数の命令を実行することにより、データオブジェクトに格納されている結果を少なくとも監査するように構成し得る。データオブジェクトは、ストリームデータオブジェクトとして構成してもよく、場合によって、ストリームデータオブジェクトは、挿入動作しか実行しないように構成してもよい。加えて、いくつかの例において、上記１つ以上のプロセッサはさらに、複数の命令を実行することにより、データオブジェクトを可視化（visualization）に対して少なくともマッピングしてもよく、および／またはビジネスイベントデータに関連するユーザのユーザインターフェイスによる表示のために上記可視化を準備するように構成してもよい。いくつかの例において、第１の連続クエリの結果は、少なくとも第１の期間データオブジェクトに格納してもよく、第２の連続クエリは、第１の期間の終了の前に処理してもよく、および／または、第１の期間は、パフォーマンス基準に少なくとも一部基づいて決定してもよい。さらに、いくつかの例において、上記１つ以上のプロセッサはさらに、上記複数の命令を実行することにより、データオブジェクトの修正を少なくとも可能にするように構成してもよい。

少なくとも１つの例に従うと、コンピュータ読取可能なメモリは、１つ以上のプロセッサによって実行されるときに、この１つ以上のプロセッサに、ユーザに関連するビジネスイベントデータに対する第１の連続クエリを初期化することにより、ある時間間隔の間、第１の結果を収集することと、第１の結果を、データオブジェクトとしてメモリに格納することと、トリガを受けたことに少なくとも一部基づいて、データオブジェクトの第１の結果を第２の連続クエリに提示することと、および／または、第２の連続クエリからの第２の結果に少なくとも一部基づいて、警告をユーザに与えることとを行なわせる命令を、格納し得る。いくつかの例において、ユーザに関連するビジネスイベントデータは、ストリームに、または、ストリームに関連するアーカイブされたリレーションに対応し得る。加えて、いくつかの例において、第１の結果は、ムービングウィンドウ（moving window）に基づいて収集してもよい。いくつかの例において、上記ムービングウィンドウおよび上記時間間隔のうちの少なくとも一方は、ユーザが決定してもよい。さらに、いくつかの例において、上記トリガは、データオブジェクトに格納されている第１の結果の変化を示し得る。これに代えて、上記命令を実施するコンピュータ読取可能なプログラムを提供することができる。

少なくとも１つの例に従うと、コンピュータにより実装される方法は、ユーザに関連するビジネスイベントデータに対する第１の連続クエリを実装することにより、ある時間間隔の間、第１の結果を収集することと、第１の結果をデータオブジェクトとしてメモリに格納することと、トリガを受けたことに少なくとも一部基づいて、データオブジェクトの第１の結果を第２の連続クエリに与えることと、ユーザのユーザインターフェイスによる表示のために、第１の結果および第２の結果のうちの少なくとも一方の、可視化に対するマッピングを与えることと、および／または、第２の連続クエリからの第２の結果に少なくとも一部基づいて、警告をユーザに与えることとを含み得る。いくつかの例において、第１の連続クエリは、ストリームからまたはアーカイブされたリレーションからデータを受けるように構成してもよい。加えて、場合によって、アーカイブされたリレーションは、ストリームに関連する、順序付けられておらず経時変化する一組のタプルとして、および／または、このタプルを含むように構成してもよい。いくつかの局面において、上記マッピングは、第１の結果および第２の結果のうちの少なくとも一方の変化のリアルタイムの可視化を与えるように構成してもよい。さらに、いくつかの例において、データオブジェクトは、「挿入」命令しか処理しないように構成してもよい。

少なくとも１つの例に従うと、システムは、イベントストリームに対する第１の連続クエリを処理するための手段と、第１の連続クエリの結果をデータオブジェクトに格納するための手段とを含み得る。第１の連続クエリは、イベントストリームのビジネスイベントデータを処理するように構成し得る。加えて、このシステムは、第２の連続クエリを、データオブジェクトに格納されている結果に少なくとも一部基づいて処理するための手段を含み得る。さらに、いくつかの例において、このシステムはさらに、データオブジェクトに格納されている結果を監査するための手段を含み得る。データオブジェクトは、ストリームデータオブジェクトとして構成してもよく、場合によって、ストリームデータオブジェクトは、挿入動作しか実行しないように構成してもよい。加えて、いくつかの例において、このシステムはさらに、データオブジェクトを可視化に対してマッピングするためおよび／またはビジネスイベントデータに関連するユーザのユーザインターフェイスによって表示するための可視化を準備するための手段を含む。いくつかの例において、第１の連続クエリの結果は、少なくとも第１の期間データオブジェクトに格納してもよく、第２の連続クエリは、第１の期間の終了の前に処理してもよく、および／または、第１の期間は、パフォーマンス基準に少なくとも一部基づいて決定してもよい。さらに、いくつかの例において、このシステムはさらに、データオブジェクトの修正を可能にするための手段を含み得る。

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

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

少なくとも１つの例に従う連続クエリに関連するサブクエリの管理および／またはチェーン接続技術のためのアーキテクチャの一例を示す簡略ブロック図である。 少なくとも１つの例に従う本明細書に記載の連続クエリに関連するサブクエリの管理および／またはチェーン接続技術の少なくともいくつかの特徴を示す簡略ブロック図である。 少なくとも１つの例に従う本明細書に記載の連続クエリに関連するサブクエリの管理および／またはチェーン接続技術の少なくともいくつかのその他の特徴を示す簡略フロー図である。 少なくとも１つの例に従う本明細書に記載の連続クエリに関連するサブクエリの管理および／またはチェーン接続技術の少なくともいくつかのその他の特徴を示す簡略フロー図である。 少なくとも１つの例に従う本明細書に記載の連続クエリに関連するサブクエリの管理および／またはチェーン接続技術の少なくともいくつかの特徴を示す簡略プロセスフローである。 少なくとも１つの例に従う本明細書に記載の連続クエリに関連するサブクエリの管理および／またはチェーン接続技術の少なくともいくつかの特徴を示す別の簡略プロセスフローである。 少なくとも１つの例に従う本明細書に記載の連続クエリに関連するサブクエリの管理および／またはチェーン接続技術の少なくともいくつかの特徴を示すもう１つの簡略プロセスフローである。 少なくとも１つの例に従う本明細書に記載の連続クエリに関連するサブクエリの管理および／またはチェーン接続技術の少なくともいくつかの特徴を示す簡略プロセスフローである。 少なくとも１つの例に従う本明細書に記載の連続クエリに関連するサブクエリの管理および／またはチェーン接続技術の少なくともいくつかの特徴を示すもう１つの簡略プロセスフローである。 少なくとも１つの例に従う本明細書に記載の連続クエリに関連するサブクエリの管理および／またはチェーン接続技術の少なくともいくつかの特徴を示すもう１つの簡略プロセスフローである。 少なくとも１つの例に従う本明細書に記載の連続クエリに関連するサブクエリの管理および／またはチェーン接続技術の実施の形態に従い使用し得るシステム環境の構成要素を示す簡略ブロック図である。 少なくとも１つの例に従う本明細書に記載の連続クエリに関連するサブクエリの管理および／またはチェーン接続技術の実施の形態に従い使用し得るコンピュータシステムを示す簡略ブロック図である。

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

いくつかの例において、１つ以上の連続サブクエリを伴う連続クエリ言語（continuous query language）（ＣＱＬ）クエリ（「クエリステートメント」とも呼ばれる）をサポートする機構を提供し得る。上記サブクエリは、たとえば、ネストされたサブクエリ、ある時間間隔にわたって機能するサブクエリ、ストリーミングまたはリレーションデータにクエリするサブクエリ等を含むがこれらに限定されない。たとえば、シナリオによっては、クエリは、ストリーム、リレーション、またはアーカイブされたリレーションからデータを収集するサブクエリに依拠する場合がある。このときクエリはサブクエリの結果を利用して実行し得る。加えて、いくつかの例において、クエリおよび／またはデータオブジェクト（ＤＯ）のチェーン接続（「デイジーチェーン接続」とも呼ばれる）をサポートする機構を提供し得る。たとえば、連続クエリは、ストリームまたはリレーションからデータを収集しそのデータをデータオブジェクトに格納し得る。データオブジェクトは、更新可能であってもよく、分析され、および／または表示されてもよい。データオブジェクトに対して追加の監査を行なってもよい。加えて、いくつかの例において、追加の連続クエリがＤＯに依拠してもよい。

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

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

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

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

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

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

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

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

いくつかの例において、ビジネスインテリジェンス（ＢＩ）は、特定の間隔で（たとえば週単位の間隔等）ビジネスオペレーションを推進し最適化するのを支援し得る。データ中心の従来のＢＩシステムと異なり、アクティビティ中心の新たな種類のシステムは、オペレーショナルビジネスインテリジェンス、リアルタイムビジネスインテリジェンス、またはオペレーショナルインテリジェンス（ＯＩ）を含み得る。オペレーショナルインテリジェンスは、ビジネスアクティビティをリアルタイムでモニタリングするのに使用されるので、以下の構成要素、すなわち、ビジネスアクティビティモニタリング（ＢＡＭ）、ＢＰＭ、および、複合イベント処理（ＣＥＰ）を含むことが多い。たとえば、ＢＩは、履歴データの周期的クエリを重視するものであってもよい。したがって、これは過去を振り返ることを重視したものであってもよい。しかしながら、ＢＩと組合わされるＯＩシステム（たとえばＢＡＭ／ＣＥＰ／ＢＰＭ）は、オペレーショナルアプリケーションの中に置くことができ、したがって、単なる戦略的分析ツールから、ビジネスオペレーションの第一線まで拡張することができる。このため、ＢＡＭは、イベントストリームを分析し総計をリアルタイムで計算するように構成してもよい。

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

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

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

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

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

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

加えて、いくつかの例において、本開示では、ダッシュボードのカスタマイズおよび／または個別化について説明することができる。ＣＥＰエンジンは、リアルタイム情報および履歴データの高度な連続分析を含むように構成し得る。ビジネスプロセスモデル（ＢＰＭ）は、ＢＰＭ表記（ＢＰＭＮ）モデルとして定義されたポリシーおよびプロセスの、モデルによって推進される実行を行なうことを含み得る。キー結果インジケータ（ＫＲＩ）を利用して、ユーザに、大局的またはクリティカルサクセスファクター（ＣＳＦ）においてどのように実行したかを伝えてもよい。たとえば、多数の動作に対する結果を提供してもよく、キーパフォーマンスインジケータ（ＫＰＩ）よりも長い期間をカバーしてもよく、および／または月毎もしくは３ヶ月毎に見直されてもよい。結果インジケータ（ＲＩ）を利用して、ユーザに、何をなしたかを伝えてもよい。たとえば、アクティビティおよび財務パフォーマンス測定を要約してもよく、および／または、毎日、毎週、もしくは毎月更新してもよい。さらに、いくつかの局面において、パフォーマンスインジケータ（ＰＩ）を利用して、ユーザに、どのアクションを起こすべきかを伝えてもよく、または、少なくとも助言を与えてもよい。加えて、非財務情報を含んでもよく、場合によってはＫＰＩを補完してもよい。

いくつかの局面において、ＰＩは、週７日２４時間、毎日、週一回、またはそれよりも少ない周期で見直してもよい。場合によっては、ＫＰＩは、組織の現在および将来の成功に最も重要な一組の測定を含み得る。いくつかのＫＰＩは毎日かまたは週７日２４時間更新してもよく、一方で、残りの情報は毎週報告してもよい。ＫＰＩ通知の例は、飛行機もしくはその他のサービス車両が遅れたか否かまたはトレイラーが前日重量不足のものを配送会社に送ったか否か（たとえばトラックのより適切な利用を発見するため）の通知を含み得るが、これに限定されない。

いくつかの例において、リアルタイムビジネスイベントを管理するための実施形態は、ビジネスアクティビティのモニタリング、複合イベント処理、およびビジネスインテリジェンスを（たとえばシームレスに）統合して、複合かつリアルタイムの一組のオペレーショナル情報を提供することを含み得る。加えて、ビジネスイベントの連続モニタリングを利用して、ビジネスプロセスおよび／またはワークフローのリアルタイムの可視化を得てもよい。いくつかの例において、ＯＩは、従来のビジネスインテリジェンスで補完してもよい。このため、オペレーショナルインテリジェンスは、上記のように、よりデータ中心の、ビジネスオペレーション対ＢＩについてのより深い洞察を与え得る。たとえば、ＯＩはビジネスがリアルタイム方式で如何に遂行されているか判断するための洞察を取得し得る。一方、ＢＩは、データウェアハウス化（たとえば事後情報の表示）に、より類似していてもよい。

ＫＰＩの例は、リアルタイムコール処理時間を含み得る。たとえば、ユーザは、リアルタイムＫＰＩを、週または日に対し、１５分に設定してもよい。このため、ユーザが直ちに行動を起こすようにすることができる。さらに、ＢＩウェアハウスからの履歴（データ中心）情報を現在のリアルタイムデータと結合することにより、ユーザは、現在の状態で（連続して更新されるストリーミングデータを含む）ビジネスが如何に実行されているか見ることができるであろう。いくつかの例において、リアルタイム情報の高度な連続分析は、データ処理に含まれていてもよい。加えて、増分計算を実施し、ディスプレイ、可視化、ユーザインターフェイス（ＵＩ）等に含めてもよい。

いくつかの例において、サブクエリをサポートしてもよい。加えて、ＣＱＬおよび／またはＣＱＬエンジンは、ネストされたおよび／またはその他の種類のクエリ集合をサポートしてもよく、増分計算を提供してもよい。さらに、いくつかの例において、緩やかに変化するディメンションテーブルを利用してもよいが、ＣＱＬエンジンはそれでもなお効率的な処理を行なうことができる。ある例では、ファクトテーブルを緩やかに変化するディメンションテーブルと結合する一方、１つ以上の結合演算子はインスタンス化されないようにしてもよい。このようにして、メモリ使用量を大幅に減じることができる。

いくつかの局面において、増分計算は、特定のクエリについてのリレーショナルソース（すなわちウェアハウスデータ）および／またはストリーミングデータすべてをメモリに入れないことを含み得る。たとえば、クエリによって利用されるまたは参照される特定のディメンション（たとえばソフトウェア製品に関連するデータソース）について、データは非常に頻繁に変化する訳ではないかもしれない（たとえば一カ月に一度ぐらい）。このため、すべてのクエリに対してソース全体をメモリにロードする必要はないことがある。よって、場合によってはデータをディメンションテーブルとしてインポートすればよい。その場合、ディメンションテーブルに変化が生じたときは常に、実行時に例外をスローすればよい。場合によっては例外をＣＱサービスが受けて処理すればよい。この例外は既知であり理解されているという表示に少なくとも一部基づいて、ＣＱサービスはそれならばクエリを再発行すればよい。言い換えると、例外は、ディメンションの変化を考慮するためにクエリを再発行しなければならないことをＣＱサービスに対して示す特別な例外としてフォーマットすればよい。そうでなければ、その他の従属因子、ストリーム、データまたはクエリツリー分岐は、正確でないまたはディメンションテーブルのデータに同期していないかもしれない。いくつかの例において、サブクエリは、ストリームまたはリレーションに対してクエリされるように構成された連続サブクエリであってもよい。

いくつかの例において、クエリツリーに少なくとも一部基づいて、親演算子（たとえば、複数の他の演算子からのデータまたはツリーの分岐に従属し得る結合またはその他の演算子）は、クエリの生成および／または実行の開始を担い得る。すなわち、ステートフル（stateful）演算子は、ステートを、適切なリレーショナルデータ、ストリーミングデータ、またはリレーションデータをロードすることにより、初期化し得る。加えて、親演算子は（どの演算子がディメンションテーブルを含むかに少なくとも一部基づいて）子演算子のうちの１つに委託してもよく、他の子演算子には委託しない。さらに、演算子のうちの１つがディメンションを含むということが（たとえば、それがディメンションであることを示すリレーショナルソースに関連するメタデータに少なくとも一部基づいて）わかると、親演算子を、ディメンションテーブルの変化を検出しようとするように構成してもよい。上記のように、ディメンションテーブルの変化が発見されたとき、例外またはそれ以外の表示を与えることにより、ＣＱサービスにクエリを再始動するよう伝えてもよい。これに代えて、親演算子に、ディメンションテーブルの変化を直接知らせることにより、クエリを再発行および／または再初期化しなければならないことを伝えてもよい。

加えて、いくつかの例において、クエリおよび／またはＤＯチェーン接続を提供し得る。ライトバック（Write Back）ＤＯは、特殊化されたデータオブジェクトであってもよく、永続性を有するように構成することができる。これは、分析／監査できるようＣＱＬクエリの出力イベントを格納するのに使用してもよく、または、別のＣＱＬが上に位置するようにデイジーチェーン方式で使用してもよい。いくつかの例において、第１のクエリは、ＤＯに対して実行し出力イベントをライトバックＤＯに挿入してもよい。そうすると、ユーザは、監査目的でライトバックＤＯを調べ、これを可視化に対してマッピングする、または、ライトバックＤＯに対し別のクエリを書くことができる。

いくつかの局面において、ライトバックＤＯを用いて、クエリをチェーン接続してもよく、または、可視化にバインドしてもよい。ライトバックＤＯは、（アーカイブされた）ストリーム／アーカイブされたリレーションＤＯいずれかであってもよい。加えて、いくつかの例において、中にサブクエリを有する複合クエリを２つの別個のクエリに分割することができる。デイジーチェーンクエリは次のようにして得られる。

（Ｑ１→ＷＢ ＤＯ１→Ｑ２→ＷＢ ＤＯ２）
・この例において、クエリ１は、時間間隔ベースで（たとえば１０分毎、２０分毎等）、ムービングウィンドウに（たとえば最後の６０分間、３０分間等の移動平均実行時間）少なくとも一部基づいて、データを収集する。
・クエリの出力はＤＯ１に入ってもよく、変更データ制御（ＣＤＣ）が有効になりＱ２が消費するようデルタをＣＱＬエンジンに送ってもよい（たとえばパターン検出）。
・Ｑ２が実行パターンマッチクエリである場合（すなわち、一行において少なくとも数回、傾向が毎回１０％上昇し続ける）、オペレータに警告を出力してもよい。
この手法の場合、Ｑ１は、イベントをメモリに保存する必要はない。その代わりに、数分（たとえば１０分以上）毎に実行し得る計画的クエリとして構成してもよい。これによって、連続クエリの複合トポロジを、既存のクエリを再配置することなく動的に作成することができ、容易に拡張することができる。

いくつかの例において、連続クエリは、一度登録してもよく、（少なくとも終了するよう命令されるまで）長時間実行してもよい。この連続クエリは、入ってくるイベントを受け、メモリにおいて計算を実行する（たとえばパターンマッチング、集計関数デルタ、移動平均計算等）。これはまた、レンジ（ムービングウィンドウ）およびスライド（出力スロットル）の概念を有し得る。たとえば次の通りである。

レンジが増すと、メモリ占有面積は、すべてのこれらイベントをメモリ内で保存する必要があるので、大きくなり得る。イベントは、レンジの大きさを超えると終了し得る。クエリの数の増加に伴い、メモリ占有面積はさらに大きくなり得る。少なくともこれらの理由により、ライトバックＤＯおよびチェーン接続クエリの強化は、メモリの利用を最適化し得る。

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

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

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

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

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

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

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

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

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

次にメモリ１３６の内容の詳細について述べる。メモリ１３６は、オペレーティングシステム１４６と、サブクエリモジュール１４８および／またはクエリチェーンモジュール１４９を少なくとも含む、本明細書に開示される特徴を実装するための、１つ以上のアプリケーションプログラムまたはサービスとを含み得る。本明細書で使用されるモジュールは、サービスの一部であるサーバまたはサーバのクラスタによって実行されるプログラミングモジュールであってもよい。この特定の文脈において、モジュールを、サービスプロバイダコンピュータ１０６の一部であるサーバまたはサーバのクラスタによって実行してもよい。いくつかの例において、サブクエリモジュール１４８は、サブクエリ１５２、１５４（たとえば連続および／または計画的サブクエリ）を含み得る１つ以上の連続クエリ１５０を、受ける、識別する、生成する、そうでなければ提供するように構成し得る。たとえば、連続クエリ１５０（たとえばストリームまたはリレーションに対して実行されるように構成されたクエリ）は、クエリが置かれる（すなわちクエリが従属する）、１つ以上のサブクエリ１５２、１５４またはネストされたサブクエリ１５４を含み得る。より具体的には、連続クエリ１５０は、サブクエリ１５４（たとえば第１のサブクエリ１５２内にネストされている）を含み得るサブクエリ１５２を含み得る。希望に応じて他のシナリオが可能であり、たとえば、連続クエリ１５０が、ネストされたサブクエリ１５４等がない２つ以上のサブクエリ１５２を含んでいてもよい。

いくつかの例において、ＣＱＬエンジンは、１つ以上のクエリを別のクエリにビュー（view）の機構を介してネストするおよび／または埋込むことをサポートし得る。たとえば、以下のＣＱＬコードを利用して、サブクエリを含むこのようなクエリを構成してもよい。

いくつかの局面において、この手法は、モジュラリティおよび再利用を提供し得る。加えて、これは、view sales_v1に対するクエリq0の従属性をもたらし得る。よって、場合によっては、view sales_v1の定義は、従属する連続クエリがある限り、変更しなくてもよい。新たなビューの定義が合致する（すなわち、たとえばプロジェクトリストは、アイテムの数、データタイプ、およびアイテムの位置が変わらない）場合であっても、クエリ各々の置換を動的に要求し得る。それに代えてまたはそれに加えて、設定されたクエリに対し、非標準的な表記を利用してもよい（たとえば＜view＞UNION＜view＞）。この種の構文は、ＡＮＳＩに準拠していないが、ＣＱサービスおよび／またはＣＱエンジンはこれを処理するように構成し得る。さらに、いくつかの局面において、いくつかのクエリは、一連のワークフローステップを通して生成してもよく、および／またはオンザフライで削除（destroy）してもよい。このような場合、ビュー機構は、クライアントが従属性を知っていることを要求するので、実際は可能ではないことがある。

ネストされたサブクエリ（インラインクエリまたはサブセレクトとしても知られている）は、ソースリレーション／ストリームが指定されるクエリのＦＲＯＭ句におけるサブクエリを指定することによって実装し得る。サブクエリのサポートは設定されたオペレーションクエリにも拡張されるであろう。以下のＣＱＬコードのセットは、少なくとも３つの例を示すが、これらに限定されない。

いくつかの例において、式を含むサブクエリのＳＥＬＥＣＴ句（またはプロジェクトリスト）における各アイテムは、明確にエイリアス化してもよい。これは、プロジェクトリストが式を有する場合にビューの定義があるのと同様である。このように式には名称がない場合があるので、<expr> AS <name>を用いて明示的に名称を付けるまたはエイリアス化することが便利であろう。加えて、下記のものにおいてプロジェクトリストをエイリアス化する必要がない場合がある。

この中でｃｉは（ベースストリーム、リレーション、または別のサブクエリであってもよい）ソースの属性を示す。これは、暗示的に導出してもよく（＊表記の場合）、または、各式がベース属性しか指していないときは自明であるかもしれない。ＳＦＷクエリ（select-from-whereを含むクエリ）の場合、サブクエリ自体もエイリアス化してもよい。しかしながら、いくつかの例では、明示的なエイリアスを指定しないのは誤りであろう。設定されたオペレーションについて、場合によっては、サブクエリはエイリアス化しなくてもよい。しかしながら、式を有するプロジェクトアイテムはエイリアス化されるように要求してもよい。残ったクエリの選択アイテムの名称は、設定されたオペレーション全体の名称として機能し得る。いくつかの例において、サブクエリは、クエリのＦＲＯＭ句においてサポートされるだけであってもよい。しかしながら、その他の例において、サブクエリはクエリのいずれかの句においてサポートされてもよい。さらに、場合によっては、ネストの深さに理論上の限界がなくてもよい。しかしながら、ネストの量は、ホスト計算システムの利用できるメモリ量の影響を受ける可能性がある。

さらに、いくつかの例において、ＳＦＷクエリは、可能な句およびその組合わせを有する非常に包括的な構造であってもよい。これら句各々は、（たとえばｆｒｏｍ句の）リレーションおよびストリームの場合とほぼ同じようにサブクエリの「属性」を意味し得る。サブクエリをサポートし得る句は、ＧＲＯＵＰ ＢＹ、ＯＲＤＥＲ ＢＹ、ＭＡＴＣＨ＿ＲＥＣＯＧＮＩＺＥ、ＪＯＩＮ、ＳＥＬＥＣＴ、ＷＨＥＲＥ、ＡＲＣＨＩＶＥＤ ＲＥＬＡＴＩＯＮ、および／またはＶＡＬＵＥ ＷＩＮＤＯＷを含むが、これらに限定されない。

加えて、いくつかの例において、クエリチェーンモジュール１４９は、クエリチェーンおよび／またはクエリ集合を可能にするように構成し得る。たとえば、クエリチェーン１５６は、第１のクエリ（たとえば連続クエリ）１５８、データオブジェクト（たとえばライトバックＤＯ）１６０、および／または第２のクエリ（たとえば別の連続クエリ）１６２を含み得る。上記のように、いくつかの局面において、第１のクエリ１５８は、ストリーム、リレーション、またはデータベースに対してクエリされてもよく、また、結果をデータオブジェクト１６０に格納してもよい。続くクエリ（たとえば第２のクエリ１６２）は次にＤＯ１６０に対してクエリされ第２の結果を得る。

上記のように、いくつかの例において、ライトバックデータオブジェクトは、特殊化されたＤＯであってもよく、永続性を有するように構成してもよい。これは、分析および／または監査できるようＣＱＬクエリ（たとえば第１のクエリ１５８）の出力イベントを格納するのに利用してもよく、または、別のＣＱＬクエリ（たとえば第２のクエリ１６２）が上に位置するようにデイジーチェーン方式で利用してもよい。第１のクエリ１５８は、最初のＤＯ（たとえば、ストリーム、リレーション、データベース、別のデータ構造他）に対して実行してもよく、出力イベントをライトバックＤＯ１６０に挿入してもよい。そうすると、ユーザは、監査目的でライトバックＤＯ１６０を調べ、これを可視化に対してマッピングする、または、ライトバックＤＯ１６０に対し別のクエリ１６２を書くことを選択することができる。

限定されない少なくとも１つの例において、パフォーマンスＤＯがあってもよい。加えて、クエリをパフォーマンスＤＯに対して書くことにより、ある間隔で特定の種類のプロセスの移動平均処理時間を計算し、その結果を別のライトバックＤＯに「平均処理時間」として出力してもよい。次に、このＤＯに対して棒グラフを作成して履歴値を示してもよい。これに代えてまたはこれに加えて、別のパターンマッチクエリをこのライトバックＤＯに対して書くことにより、傾向分析を実行してもよい。傾向分析のクエリについて、第１のかつ主要な要件は、データソースが、挿入のみであってもよくかつライトバックＤＯが属するストリームデータソースであることであってもよい。このように、場合によっては、ライトバックＤＯは、常にストリームＤＯ（すなわち、挿入のみであり、削除、アップサート（upsert）、または更新がない）であってもよく、永続性を有するようにまたは有さないように構成することができる。永続性が構成されないとき、フレックス（flex）テーブルは作成されず、「挿入」イベントがメモリ内の永続性によって処理されＣＱサービスに向けて送られる。

データを設計する役割を有するユーザ１０２は、ライトバックＤＯを作成する能力を有し得る。ライトバックＤＯは、連続クエリテンプレート等に表わされてもよい。また、ユーザ１０２がライトバックデータオブジェクトを任意のステップとして選択できるようにしてもよい。また、ユーザは、選択リストをライトバックＤＯにマッピングするおよび／またはライトバックＤＯを殆どの他のＤＯと同じように修正する能力を有し得る。ライトバックＤＯの定義後、ＣＱＬクエリが開始されたときに、出力イベントを、永続性に、ｊａｖａ（登録商標）メッセージングサービス（ＪＭＳ）ツール等を介して送ってもよい。場合によっては、これは、ＪＭＳアダプタアプリケーションプログラミングインターフェイス（ＡＰＩ）を強化して挿入イベントをサービスプロバイダコンピュータ１０６の永続性ツールに送ってもよい。

いくつかの例において、複合ＣＱＬクエリを、ライトバックＤＯを間に挟んで２つの別個のクエリに変換することにより、大幅にパフォーマンスを省力化することができる。たとえば、以下のサブクエリ部分において、クエリは、最後の（移動）６０分でクローズされ結果を１０分毎に出力するコールについて最大コール処理時間を計算する連続クエリ（たとえばアーカイブされたリレーションを有する）を実行していることに注目されたい。このクエリにおいて、最後の６０分のすべてのイベントはメモリに格納され時間が動くのにしたがって個々に終了する。このため、６０分毎に２０，０００イベントが来るのであれば、ＣＱＬエンジンは、２０，０００イベントをメモリに任意の時点で格納し、最大処理時間は、イベントがシステムに入力される度に再計算されている。最後に、１０分間隔で、最大処理時間は挿入ストリームとして出力されている。加えて、クエリの第２部において、クエリはサブクエリからの出力を取込んでおり、上昇傾向を検出しているパターンマッチを実行する（現在の測定は最後の測定よりも７％大きくこのパターンは１行において７回検出された）。

第１のクエリにより多くのメモリが消費されていることに注目されたい。代わりに、ライトバックＤＯおよびＣＱＬスケジューリングされたクエリでは、以下のものを得ることができる（たとえば、第１のクエリは１０分毎に出力するだけなのでクエリをリライトすることができるためである）。

この場合、ＣＱＬは、このクエリを１０分毎に実行し、このクエリを実行している間メモリは占有されない。次に、このクエリの出力はストリームベースのライトバックＤＯに入る。この時点で、第２のクエリ（傾向のためのパターンマッチ）が次にこの中間ライトバックＤＯに与えられる。この手法を用いると、メモリ消費は、ライトバックＤＯからの最後の７つのイベントを追跡する傾向クエリのみである。加えて、サブクエリモジュール１４８、クエリチェーンモジュール１４９、および／またはサービスプロバイダコンピュータ１０６の動作の２、３の例について以下で詳細に説明する。

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

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

図２は簡略ブロック図２００を示し、これを用いて、サブクエリが存在するときの連続クエリの管理の特徴を説明することができる。上記のように、いくつかの例において、サブクエリモジュール１４８は、図１のサービスプロバイダコンピュータ１０６によって実行してもよく、１つ以上のサブクエリ１５２に依拠する１つ以上の連続クエリ１５０を含み得る。限定されないある例において、連続クエリ１５０は、サブクエリ１５２の結果によって決まり得る。このため、サブクエリは最初に、図１のストリーミングデータソースコンピュータ１１０によって与えてもよくそうでなければ管理してもよいストリーム２０２に対してクエリしてもよい。しかしながら、その他の例では、サブクエリ１５２は、リレーション、データオブジェクト、またはデータベース（たとえばリレーショナルデータベース等）に対してクエリしてもよい。加えて、いくつかの例において、論理プランを、サブクエリ１５２に少なくとも一部基づいて生成してもよくそうでなければ構築してもよい。サブクエリから少なくとも１つの結果が得られると、連続クエリ１５０は、サブクエリ１５２の結果を利用してストリーム２０２に対してクエリしてもよい。このようにして、ストリーム２０２のまたは別のストリームのデータには、実際のキーのうちのいくつかについての知識がなくともアクセス可能であろう。たとえば、サブクエリ１５２は、連続クエリ１５０によって利用されることが可能な結果を、ストリーム２０２に対するクエリのためのキーとして取出してもよい。さらに、いくつかの局面において、サブクエリ１５２を記載する論理（または物理）プランを、連続クエリ１５０に少なくとも一部基づくプランと（たとえば論理層で）マージしてもよい。たとえば、連続クエリ１５０（すなわちこの例では親クエリ）がＦＲＯＭソース（たとえばストリーム、リレーション等）を予想する場合、サブクエリ１５２を実装するための論理プランが含まれ得る。このため、論理層の外では、連続クエリ１５０がいずれかのサブクエリ１５２を含んでいたか否か見分けがつかないであろう。このようにして、同一のサブクエリ１５２を含む連続クエリ１５０は同一のプラン演算子を自動的に共有し得る。

さらに、上記のように、いくつかの例において、緩やかに変化するディメンションテーブルを利用してもよい（たとえばサブクエリ１５２がリレーショナルソースに対してクエリするとき）。リレーショナルソースは、ストリーミングデータと対照的に、履歴および／またはウェアハウス内のデータを提供し得る。このため、サブクエリ１５２によって取得されたデータのうちのいくつかは頻繁に変化しない可能性がある。それでもなお、変化するときは、連続クエリ１５０が、連続クエリ１５０が依拠している結果を更新するかそうでなければリフレッシュするために、サブクエリ１５２の再実装を要求すればよい。

図３は、一例に従い、サブクエリがあるときの連続クエリの管理を実装するための１つ以上の技術３００を示す簡略フロー図を示す。図３において、ここでも、サービスプロバイダコンピュータ１０６は、ユーザ１０２および／またはユーザ装置１０４とネットワーク１０８を介して通信することが示されている。加えて、いくつかの例において、サービスプロバイダコンピュータ１０６は、１つ以上のストリーム／リレーションコンピュータ３０２を含み得るまたは１つ以上のストリーム／リレーションコンピュータ３０２と（たとえばネットワーク１０８を介して）通信し得る。図３では技術３００が（任意の連続番号を含む）特定の順序で示されているが、特定の順序は不要であることおよび技術３００の１つ以上のステップまたは部分を省略、スキップ、および／または並べ替えることができることが、理解されるはずである。限定されない少なくとも１つの例において、図１および図２を参照しながら先に説明した１つ以上のサービスプロバイダコンピュータ１０６は、ユーザ装置１０４から、サブクエリを有する連続クエリを受けることができる。連続クエリは、データベースデータ（たとえばデータベースに格納されているデータ）、ストリーミングイベントデータ（たとえばストリーム／リレーションコンピュータ３０２からリアルタイムで受けているデータ）、および／またはリレーションデータ（たとえばストリーム／リレーションコンピュータ３０２から受けるリレーション）の処理（たとえば取出し、格納、削除等）を要求するように構成し得る。

加えて、いくつかの例において、サービスプロバイダコンピュータ１０６はまた、連続クエリ内で発見されたサブクエリを、ストリーム／リレーションコンピュータ３０２のリレーションまたはストリームに対してこれをクエリすることにより、処理してもよい。しかしながら、他の例において、サブクエリの処理は、サブクエリを実装するための論理および／または物理プランの生成を含み得る。このようにして、サブクエリそのものは、連続クエリが処理されるまで、データソースに対して処理しなくてもよい。論理プランが生成されると、この論理プランを、連続クエリの実装のために生成されたプランとマージすればよい。たとえば、上記のように、論理プランは、連続クエリのＦＲＯＭステートメントに含まれ得る。これに対し、サービスプロバイダコンピュータ１０６は、サブクエリに少なくとも一部基づいてデータを受けてもよく、または、サブクエリに関連するデータは、マージ後、連続クエリがデータソース（たとえばリレーション、ストリーム、またはその他のソース）に対して適用されたときに、受けてもよい。上記のように、連続クエリは次にリレーションまたはストリームに対して適用してもよいが、サブクエリを介して受けた結果を含む。このため、連続クエリを、サブクエリの結果に少なくとも一部基づいて、ストリーム／リレーションコンピュータ３０２のストリームまたはリレーションに対してクエリしてもよい。加えて、いくつかの例において、サービスプロバイダコンピュータ１０６は次に、連続クエリパラメータおよびサブクエリの結果に少なくとも一部基づいて、ストリーム／リレーションコンピュータ３０２からデータを受けてもよい。さらに、サービスプロバイダコンピュータ１０６は次に、結果をユーザ装置１０４に与えてもよい。加えて、ユーザ装置１０４および／または可視化情報に警告を与えてもよい。

図４は簡略ブロック図を示し、これを用いてクエリをチェーン接続するための機構の特徴を説明することができる。上記のように、いくつかの例において、クエリチェーンモジュール１４９は、図１のサービスプロバイダコンピュータ１０６によって実行されてもよく、１つ以上の連続クエリ４０２、４０４および／または１つ以上のデータオブジェクト４０６を含み得る。限定されない１つの例において、第２の連続クエリ４０４は、データオブジェクト４０６に従属し得る、またはデータオブジェクト４０６に対してクエリし得る。しかしながら、ＤＯ４０６は、第１の連続クエリ４０２を介して取得された結果を含み得る。このため、第１の連続クエリ４０２は最初に、図１のストリーミングデータソースコンピュータ１１０によって与えられてもよくそうでなければ管理されてもよいストリーム４０８に対してクエリし得る。しかしながら、他の例において、第１の連続クエリ４０２は、リレーション、データオブジェクト、またはデータベース（たとえばリレーショナルデータベース等）に対してクエリしてもよい。第１の連続クエリ４０２が少なくとも１つの結果を得ると、このデータをＤＯ４０６に格納すればよい。いくつかの例において、ＤＯ４０６はストリームＤＯ（たとえば挿入句のみを利用する）であってもよく、任意の種類のＤＯであってもよい。

第１の連続クエリ４０２によって収集された（すなわち取得された）データがＤＯ４０６に格納されると、ユーザまたはその他のエンティティはＤＯ４０６にアクセスすればよい。たとえば、ＤＯ４０６のデータは、監査、表示、編集、そうでなければ管理してもよい。このため、ＤＯ４０６のデータは、ユーザインターフェイス４１０に与えることができる。加えて、後続のクエリ（たとえば第２の連続クエリ４０４）はその後にＤＯ４０６に対してクエリすればよい。このようにして、複数の連続クエリ（または計画的クエリ）を互いにチェーン接続することができ、この接続において、後続のクエリはＤＯ４０６を介して前のクエリに依拠する、そうでなければ従属する。

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

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

いくつかの例において、図１〜図３に示される（たとえば図１の少なくともサブクエリモジュール１４８を利用する）１つ以上のサービスプロバイダコンピュータ１０６は、図５のプロセス５００を実行し得る。プロセス５００は、５０２で、少なくとも１つのサブクエリ（たとえば連続サブクエリまたは計画的サブクエリ）を含む連続クエリを識別することを含むことから始まり得る。いくつかの例において、プロセス５００はまた、５０４で、サブクエリを処理することによりサブクエリを実装するための論理プラン（たとえば論理プランはサブクエリを有するデータソースに対してクエリするためのステップを含み得る）を取得することを含み得る。プロセス５００はまた、５０６で、論理プランと連続クエリ論理プランとのマージに少なくとも一部基づいて連続クエリ（たとえばサブクエリを含むクエリ）を処理することを含み得る。たとえば、連続クエリ（または連続クエリを実装するための論理プラン）のＦＲＯＭステートメントで、論理サブクエリプランを含めてもよい。いくつかの局面において、これは、サブクエリからの第１の結果を利用して、データソース（たとえばサブクエリがクエリした対象と同じデータソースまたは別のデータソース）に対してクエリすることを含み得る。プロセス５００は、５０８で、第２の結果をユーザのユーザインターフェイスに与えることを含み得る。さらに、プロセス５００は、５１０で、サブクエリのデータが変化したという表示に少なくとも一部基づいてサブクエリを再度処理することを含むことで、終了し得る。

図６は、本明細書に記載のサブクエリが存在するときの連続クエリの管理を実装するためのプロセス６００を示すフロー図の一例を示す。図１〜図３に示される（たとえば図１の少なくともサブクエリモジュール１４８を利用する）１つ以上のサービスプロバイダコンピュータ１０６は、図６のプロセス６００を実行し得る。プロセス６００は、６０２で、１つ以上のネストされたサブクエリを含む連続クエリステートメントを受けることを含むことから始まり得る。ネストされたサブクエリを有する連続クエリは、いくつかの例ではユーザから受けてもよい。プロセス６００は、６０４で、ネストされたサブクエリを処理することにより、ネストされたサブクエリ（たとえばネストされたサブクエリのうちの少なくとも１つおよび／または少なくとも最も深くネストされたサブクエリ）を実装するための論理プランを取得することを含み得る。上記のように、クエリおよび／またはサブクエリの処理は、データソースを、クエリまたはサブクエリそれぞれを用いてクエリすることを含み得る。加えて、いくつかの例において、プロセス６００は、６０６で、連続クエリを（たとえばネストされたサブクエリからの）論理プランのマージに少なくとも一部基づいて処理することにより、ビジネスイベント結果を取得することを含み得る。さらに、プロセス６００は、６０８で、ディメンションテーブルが変化したとき例外を受けることを含むことで、終了し得る。たとえば、ディメンションテーブルは、サブクエリの結果に関連する属性または列を定義し得る。下にあるデータ（すなわち連続クエリが従属するデータ）が変化すると、例外は、クエリエンジンに、サブクエリをリフレッシュまたは再度処理するよう伝えてもよい。

図７は、本明細書に記載のサブクエリが存在するときの連続クエリの管理を実装するためのプロセス７００を示すフロー図の一例を示す。図１〜図３に示される（たとえば図１の少なくともサブクエリモジュール１４８を利用する）１つ以上のサービスプロバイダコンピュータ１０６は、図７のプロセス７００を実行し得る。プロセス７００は、７０２で、ビジネスイベントデータに関連するユーザからの連続クエリステートメントを受けることを含むことから始まり得る。プロセス７００は、７０４で、連続クエリが連続サブクエリを含むか否か判断することを含み得る。場合によっては、連続クエリがサブクエリを含まないと判断されたとき、プロセス７００は、７０５で、連続クエリを処理してストリームまたはリレーションから結果を取得することを含むことで、終了し得る。しかしながら、他の例では、７０４で、連続クエリがサブクエリを含むと判断される場合がある。この例では、プロセス７００は代わりに、７０６で、サブクエリを処理することにより、ストリームまたはリレーションから第１の結果のセットを取得することを含み得る。プロセス７００はまた、７０８で、第１の結果のセットおよび／またはストリームもしくはリレーションデータを利用することにより、連続クエリを処理することを含み得る。加えて、プロセス７００は、７１０で、ディメンションテーブルのデータが変化するまで演算子のインスタンス化をスキップすることを含み得る。プロセス７００は、７１２で、（たとえばデータは頻繁に変化すると予想されないので）第１の結果のセットすべてよりも少ない第１の結果を連続クエリにロードすることを含み得る。さらに、プロセス７００は、７１４で、第１の結果のセットのうちのサブセットのみを、このサブセットのデータが変化する確率が低いときにロードすることを含み、プロセス７００はこの７１４で終了し得る。

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

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

いくつかの例において、少なくとも図１に示される（たとえば複合イベント処理エンジンの少なくとも一部として機能する図１の少なくともクエリチェーンモジュール１４９を利用する）１つ以上のサービスプロバイダコンピュータ１０６は、図８のプロセス８００を実行し得る。プロセス８００は、８０２で、第１の連続クエリの結果をデータオブジェクトに格納することを含むことから始まり得る。この結果は、第１の連続クエリを用いてストリームまたはリレーションに対してクエリした結果であってもよい。プロセス８００は、８０４で、第２の連続クエリを、データオブジェクトに格納されている結果に少なくとも一部基づいて処理することを含み得る。このため、第１および第２の連続クエリは、データオブジェクトによって互いにチェーン接続し得る。加えて、プロセス８００は、８０６で、データオブジェクトにおける結果を監査することを含み得る。警告を与えてもよく、および／または８０８で、プロセス８００は、データオブジェクトにおける結果をデータ可視化に対してマッピングすることを含み得る。プロセス８００はまた、８１０で、表示のために可視化を準備することを含み得る。さらに、プロセス８００は、８１２で、データオブジェクトにおける結果の修正を可能にすることを含むことで、終了し得る。

図９は、本明細書に記載の連続クエリをチェーン接続するための機構を実装するためのプロセス９００を示すフロー図の一例を示す。少なくとも図１に示される（たとえば複合イベント処理エンジンの少なくとも一部として機能する図１のクエリチェーンモジュール１４９の少なくとも１つを利用する）１つ以上のサービスプロバイダコンピュータ１０６は、図９のプロセス９００を実行し得る。プロセス９００は、９０２で、第１の連続クエリを初期化することにより、ある時間間隔の間、第１の結果を収集することを含むことで始まり得る。プロセス９００はまた、９０４で、データオブジェクト（たとえば連続クエリを互いにデイジーチェーン接続するように構成されたライトバックＤＯ）に第１の結果を格納することを含み得る。プロセス９００は、９０６で、トリガに少なくとも一部基づいて、データオブジェクトの第１の結果を第２の連続クエリに提示することを含み得る。加えて、プロセス９００は、９０８で、第２の連続クエリからの第２の結果に少なくとも一部基づいて、警告をユーザに与えることを含むことで、終了し得る。さらに、次のクエリによって使用されるように前のクエリの結果を格納するように構成された複数の異なるデータオブジェクトを利用することによって、複数のチェーンを実装し得る。

図１０は、本明細書に記載の連続クエリをチェーン接続するための機構を実装するためのプロセス１０００を示すフロー図の一例を示す。少なくとも図１に示される（たとえば複合イベント処理エンジンの少なくとも一部として機能する図１のクエリチェーンモジュール１４９の少なくとも１つを利用する）１つ以上のサービスプロバイダコンピュータ１０６は、図１０のプロセス１０００を実行し得る。プロセス１０００は、１００２で、ユーザのビジネスイベントデータに対する少なくとも第１の連続クエリを実装することにより第１の結果を収集することを含むことで始まり得る。プロセス１０００はまた、１００４でデータオブジェクトに関連するメモリに第１の結果を格納することを含み得る。プロセス１０００はまた、１００６でトリガに少なくとも一部基づいてデータオブジェクトに格納されている第１の結果を少なくとも第２の連続クエリに与えることを含み得る。プロセス１０００はまた、１００８で、表示のために、第１の結果および／または第２の結果をビジネスイベント可視化に対してマッピングすることを与えることを含み得る。さらに、プロセス１０００は、１０１０で、（たとえば許容レベル外またはしきい値に近づく）連続クエリからの第２の結果に少なくとも一部基づいて警告をユーザに与えることを含むことで、終了し得る。

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

図１１は、本開示の実施形態に従い使用し得るシステム環境１１００の構成要素を示す簡略ブロック図である。図に示されるように、システム環境１１００は、１つ以上のクライアントコンピューティング装置１１０２、１１０４、１１０６、１１０８を含み、これら装置は、ウェブブラウザまたは専用のクライアント（たとえば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