JP7064333B2 - 知識集約型データ処理システム - Google Patents

Description

関連出願の相互参照
本願は、２０１５年３月２３日に出願され、「知識集約型データ処理システム」と題された米国特許出願第１４／６６５１７１号の利益を主張し、その開示の全体が引用により本明細書に援用される。

背景
クラウドサービスの管理、履行センタの監督、グリッドの管理、科学の進歩、患者の治療などの複雑な応用は、巨大量のデータの構築処理を管理するアプリケーションを必要とする可能性がある。一例として、ＳＬＡ（Service Level Agreement）の準拠は、多くのクラウド運用にとって重要な要件である。ＳＬＡ違反を回避する操作を可能にするまたは違反が発生した場合に問題の解決案をより迅速に提供するように、ＳＬＡの準拠は、重要な性能基準の連続監視および切迫してくるＳＬＡ違反を検出する予測診断機能を必要とする。このようなクラウド運用は、管理者側および／または顧客側のプライベートクラウド、パブリッククラウドおよびハイブリッドクラウド内のデータセンタ、ネットワーク、サーバマシン、仮想マシン、オペレーティングシステム、データベース、ミドルウェアおよびアプリケーションなどの数百万個のハードウェア要素およびソフトウェア要素を監視、診断および管理する必要がある。

従来の情報技術（ＩＴ）運用の反応性異常検出および手動診断技術は、大変な労働集約的ものであり、広範囲分野の専門知識を必要とし、応答が非常に遅いため、異常を生じた構成要素を分離および特定するではなく、システム内の大量の部品の再起動を含む不適切な応答を引き起こし、クラウドに適切に拡張できないことがある。効果的なクラウドシステムの運用は、重要な生命徴候（vital sign）の連続測定、時系列分析、多変量システム状態モデル、システム応答モデル、予知異常検出、機械学習に基づく分類、自動診断および予後、判定支援、および様々な制御能力を必要とする。

簡単な要約
本明細書に記載の実施形態は、ビッグデータ（big data）および関連技術を用いて、低価値データから高価値データを取得および抽出することによって、大量の複雑な大容量および高速データを管理および処理するための様々な技術を提供する。本明細書に記載された例示的なデータベースシステムは、高価値データを抽出または生成すると共に、データを収集および処理することができる。高価値データは、多時間性、出所、フラッシュバックおよび登録クエリなどの機能を提供するデータベースに利用されてもよい。いくつかの例において、コンピューティングモデルおよびシステムを実装することによって、データ駆動状況を認識するコンピューティングシステム内のほぼリアルタイムのデータ処理フレームワークに、知識およびプロセス管理特徴を組み入れることができる。

いくつかの実施形態において、本明細書に記載の技術は、多時間データベースを保存および更新し、多時間データベースに基づいてフィルタクエリを評価し、フィルタクエリの評価に基づいてデータ変換処理を呼び出すことができる。データストリーム、ビッグデータおよび他の生入力データからの入力データを受信して、多時間データベースに格納することができる。式フィルタ、登録クエリ、トリガ、連続クエリ通知などのデータベース構成物を含むフィルタクエリは、更新された多時間データに基づいて、特定されてもよい。フィルタクエリおよび／またはデータトランザクションプロセスは、現在のデータ状態および１つ以上の過去のデータ状態に基づいて実行されてもよく、複数の実行の間の差は、評価されてもよい。異なるフィルタクエリおよび／または異なる時間およびデータ状態に対応するデータトランザクションプロセスの結果間の差を用いて、追加のデータトランザクションプロセスおよび／またはループアプリケーションインスタンスを呼び出すことができる。

本発明の１つ以上の実施形態に従って、データ駆動型変換ループアプリケーションの実行モデルの例示的なインスタンスを示すブロック図である。 本発明の１つ以上の実施形態に従って、データ駆動型アプリケーションを実行するクラウドベースコンピュータシステムの高次要素を示すブロック図である。 本発明の１つ以上の実施形態に従って、多時間データベース内のフィルタクエリに基づいて、データオブジェクト変換を呼び出すためのプロセスを示すフローチャートである。 本発明の１つ以上の実施形態に従って、ループデータ変換アプリケーションの実行の例示的なインスタンスを示すフローチャートである。 本発明の１つ以上の実施形態に従って、多時間データベース内の有効データ項目対時間のグラフを示す図である。 本発明の様々な実施形態を実現することができる例示的な分散システムの構成要素を示すブロック図である。 本発明の実施形態によって提供されたサービスをクラウドサービスとして提供することができるシステム環境の構成要素を示すブロック図である。 本発明の実施形態を実現することができる例示的なコンピュータシステムを示すブロック図である。 本発明の１つ以上の実施形態に従って、データ、知識およびプロセスを管理するための例示的なモデルを示すブロック図である。 本発明の１つ以上の実施形態に従って、実体モデルを示すブロック図である。 本発明の１つ以上の実施形態に従って、ＣＡＲＥ定義の例を示すブロック図である。 本発明の１つ以上の実施形態に従って、ＣＡＲＥ定義の例を示すブロック図である。 本発明の１つ以上の実施形態に従って、ＣＡＲＥ定義の例を示すブロック図である。 本発明の１つ以上の実施形態に従って、ＣＡＲＥ定義の例を示すブロック図である。 本発明の１つ以上の実施形態に従って、ＣＡＲＥ定義の例を示すブロック図である。 本発明の１つ以上の実施形態に従って、例示的なＫＩＤＳループにおける注釈付きＦＰＨＤデータおよびＣＡＲＥデータを示すブロック図である。 本発明の１つ以上の実施形態に従って、関連する実体セット間の様々なタイプの情報の情報融合を示すブロック図である。 本発明の１つ以上の実施形態に従ったＣＡＲＥループの実装を示すブロック図である。

詳細な説明
以下の記載において、説明の目的で、本発明の様々な実施形態を完全に理解できるようにするために、多くの具体的な詳細を記載する。しかしながら、これらの具体的な詳細がなくても本発明を実施できることは、当業者には明らかであろう。場合によって、一部の周知の構造および装置は、ブロック図で示される。

以下の記載は、例示的な実施形態を提供するもののみであり、本開示の範囲、適用性または構成を限定するものではない。むしろ、例示的な実施形態の以下の記載は、例示的な実施形態を実施可能な説明を当業者に提供する。理解すべきことは、添付の特許請求の範囲に記載された発明の精神および範囲から逸脱することなく、要素の機能および要素の配置にさまざまな変更を加えることができることである。

本発明の実施形態を完全に理解するために、以下の記載において、具体的な詳細を説明した。しかしながら、当業者には、これらの具体的な詳細がなくても、本発明の実施形態を実施できることが理解されるであろう。例えば、不必要な詳細で実施形態を不明瞭にしないように、回路、システム、ネットワーク、プロセスおよび他の構成要素をブロック要素として示してもよい。他の例において、実施形態を不明瞭にしないように、不必要な詳細なしで、周知の回路、プロセス、アルゴリズム、構造および技術を示してもよい。 また、留意すべきことは、各々の実施形態は、フローチャート、フロー図、データフロー図、構造図、またはブロック図として示された処理として説明されていることである。フローチャートは、操作を順次処理として説明しているが、多くの操作は、並行でまたは同時に実行することができる。さらに、操作の順序を再配置してもよい。処理は、その操作が完了した時点で終了するが、図に示されていない追加のステップを含んでもよい。処理は、メソッド、関数、プロシージャ、サブルーチン、サブプログラムなどに対応することができる。処理が関数に対応する場合、その終了は、呼び出し関数またはメイン関数の戻りに対応することができる。

「コンピュータ読取可能な媒体」という用語は、命令および／またはデータを記憶、格納または搬送することができる非一時的媒体、例えば、可搬型または固定型記憶装置、光記憶装置、およびさまざまな他の媒体を含むが、これらに限定されない。コードセグメントまたはコンピュータ実行可能な命令は、プロシージャ、関数、サブプログラム、プログラム、ルーチン、サブルーチン、モジュール、ソフトウェアパッケージ、クラス、もしくは命令、データ構造またはプログラム文の任意の組合せを表すことができる。コードセグメントは、情報、データ、引数、パラメータ、またはメモリ内容を転送および／または受信することによって、別のコードセグメントまたはハードウェア回路に結合されてもよい。情報、引数、パラメータおよびデータなどは、メモリ共有、メッセージ転送、トークン転送、ネットワーク送信などの任意の適切な手段を介して、伝達され、転送され、または送信されてもよい。

さらに、実施形態は、ハードウェア、ソフトウェア、ファームウェア、ミドルウェア、マイクロコード、ハードウェア記述言語、またはそれらの任意の組み合わせによって実施されてもよい。ソフトウェア、ファームウェア、ミドルウェアまたはマイクロコードに実施される場合、必要な作業を実行するプログラムコードまたはコードセグメントは、コンピュータ読取可能な媒体に格納されてもよい。プロセッサは、必要な作業を実行することができる。

本明細書は、ビッグデータおよび関連技術を用いて、低価値データから高価値データを取得および抽出することによって、大量の複雑な高速データを管理および処理するための様々な技術（例えば、方法、システムおよび１つ以上のプロセッサによって実行可能な複数の命令を格納する非一時的なコンピュータ読取可能な記憶メモリ）を記載する。本明細書に記載された例示的なデータベースシステムは、高価値データを抽出または生成すると共に、データを収集および処理することができる。高価値データは、多時間性、出所、フラッシュバックおよび登録クエリなどの機能を提供するデータベースに利用されてもよい。いくつかの例において、コンピューティングモデルおよびシステムを実装することによって、データ駆動状況を認識するコンピューティングシステム内のほぼリアルタイムのデータ処理フレームワークに、知識およびプロセス管理特徴を組み入れることができる。

本明細書に記載の技術は、多時間データベースを保存および更新し、多時間データベース上のフィルタクエリを評価し、フィルタクエリの評価に基づいてデータ変換処理を呼び出すことができる。データストリーム、ビッグデータおよび他の生入力データからの入力データを受信して、多時間データベースに格納することができる。式フィルタ、登録クエリ、トリガ、連続クエリ通知などのデータベース構成物を含むフィルタクエリは、更新された多時間データに基づいて、特定されてもよい。フィルタクエリおよび／またはデータトランザクションプロセスは、現在のデータ状態および１つ以上の過去のデータ状態に基づいて実行されてもよく、複数の実行の間の差は、評価されてもよい。異なるフィルタクエリおよび／または異なる時間およびデータ状態に対応するデータトランザクションプロセスの結果間の差を用いて、追加のデータトランザクションプロセスおよび／またはループアプリケーションインスタンスを呼び出すことができる。

図１を参照して、図１は、データ駆動型変換ループアプリケーションの実行モデルを示すブロック図である。実行モデル１００は、データベースシステムまたは他のコンピューティングシステム内の実行エンジンによって実装されてもよい。以下で説明するように、このような実行エンジンは、実行モデル１００内の様々な要素をインスタンス化し、追跡および制御するためのデータ駆動型プロセスを実装するように構成された専用ハードウェア、ソフトウェアおよび／またはネットワーク要素を含むことができる。

この例において、実行モデル１００は、３つの異なるカテゴリのオブジェクト、すなわち、データオブジェクト、変換オブジェクトおよびフィルタを含む。データオブジェクトは、ファクト、イベントストリーム、関係、ＸＭＬ（Extensible Markup Language）文書、テキストなどの構造化コンテンツ、半構造化コンテンツおよび非構造化の未処理コンテンツを表すことができる。また、データオブジェクトは、カテゴリ、タグ、関係およびコンテナなどのメタデータを表すことができ、および／または、ユーザインターフェイスフォーム、処方箋フォームおよび通知テンプレートなどの取得プロセスによって取り込まれたコンテンツを表すことができる。変換オブジェクトは、アルゴリズム、スクリプト、プロセス、クエリ、ＲＤＦ（Resource Description Framework）公理、生産ルール、決定木、サポートベクトルマシン、神経ネットワーク、ベイジアンネットワーク、隠れマルコフモデル、ホップフィールドモデル、人間の暗黙知識、および種々の変換データを表すことができる。また、変換オブジェクトは、データオブジェクトを追加、変更または削除するために、これらのデータオブジェクトに適用できるデータを含む。フィルタは、１つ以上のデータオブジェクトおよび変換オブジェクトの環境に評価され得る経路式（path expression）および／またはブール演算式（Boolean expression）に対応する。例えば、フィルタは、データオブジェクトおよび／または変換オブジェクトの変更インスタンスを検出するデータベースシステムに登録された１つ以上のクエリを含むことができる。このようなフィルタは、データベーストリガ、リアルタイムジャーナル解析および／または多時間または双時間データベースシステム上に登録されたクエリを用いて、実装することができる。

図１に示すように、例示的な実行モデル１００は、データ変換ループアプリケーションに対応し得る。このデータ変換ループアプリケーションは、潜在的に反復するループプロセスおよび／または不定のループプロセスであってもよい。この例および他の関連する実施形態において、異なるタイプのデータオブジェクトの各々は、異なる属性または特性を有する異なるデータを表すことができ、異なるタイプの変換オブジェクトの各々は、１つのタイプのデータオブジェクトを別のタイプのデータオブジェクトに変換する異なるアルゴリズムまたはシステムの実装であってもよい。例示的な実行モデル１００は、４つのタイプのデータオブジェクトおよび４つのタイプの変換オブジェクトを含むが、理解すべきことは、異なる実装例において、異なる数のデータオブジェクトおよび変換オブジェクト（例えば、２つのデータオブジェクトおよび２つの変換オブジェクト、３つのデータオブジェクトおよび３つの変換オブジェクト、．．．、５つのデータオブジェクトおよび５つの変換オブジェクト）を使用することができることである。また、理解すべきことは、異なる実施形態においてより多くのフィルタオブジェクトまたはより少ないフィルタオブジェクトを実装してもよく、特定の実施形態において一部のフィルタまたは全てのフィルタを実装しなくてもよいことである。

実行モデル１００において、第１タイプのデータオブジェクト１０３、１０４および１２０は、計算システムに入力された生の入力を表すことができる。これらの入力は、例えば、Java（登録商標）仮想マシン（ＪＶＭ）内のガベージコレクタからのデータストリーム、定期的なスレッドダンプからのスタックトレース、メモリヒープダンプ、データベースＡＷＲレポートなどを含んでもよい。第１タイプのデータオブジェクト１０３、１０４および１２０は、非構造化会話、フォーム入力、装置から収集された定量的な測定値、イベントストリームデータ、ＸＭＬ文書またはテキスト文書などであってもよい。第２タイプのデータオブジェクト１０７、１０８および１１０は、第１タイプのデータオブジェクトに基づいて推定された観測結果または予測結果の定性的な説明を表すことができる。いくつかの実施形態において、第２タイプのデータオブジェクト１０７、１０８および１１０は、４つの異なるサブタイプのデータオブジェクト、すなわち、観測オブジェクト、予測オブジェクト、ノルムオブジェクトおよび目的オブジェクトのうち、１つ以上を含むことができる。観測オブジェクトは、ファクトを離散値に個別化することができる。例えば、データベースの接続をブロックするためのスレッドの強度（数字）というファクトを、正常、保護、厳格または重要などの定性値を有する観測オブジェクトに個別化することができる。予測オブジェクトは、変化する条件から予測された定性値を表すことができる。予測オブジェクトは、例えばシミュレーションを介して、観察モデルによって内挿または外挿された定性値を表すことができる。ノルムオブジェクトは、歴史的なベースラインの定性値を表すことができる。目的オブジェクトは、全体的な目的および解決を達成するために、観察オブジェクトおよび予測オブジェクトを求めるための目標定性値を表すことができる。第３タイプのデータオブジェクト１１２および１１４は、第２タイプのデータオブジェクト（例えば、観察オブジェクトおよび／または予測オブジェクト）に基づいて推定された診断または原因を表すことができる。例えば、ロードバランサの故障によって、２つのサーバクラスタのうち、第１サーバにおいてスレッドクラスのスレッド強度を高血圧状態（標準よりも有意に高い強度）に分類し、第２サーバにおいて当該スレッドのスレッド強度を低血圧状態（標準よりも有意に低い強度）に分類することは、第３タイプのデータオブジェクト１１２または１１４のドメイン特有例であってもよい。第４タイプのデータオブジェクト１１６および１１８は、第３タイプのデータオブジェクトに基づいて推定された行う予定の行動セットを表すことができる。例えば、ヒープダンプを捕捉するまたはメモリ管理ポリシーを構成するための一連の命令は、第４タイプのデータオブジェクト１１６または１１８のドメイン特有例であってもよい。

各変換オブジェクトは、ハードウェアおよびソフトウェアからなるコンピュータシステム上で実行される自動化ソフトウェアプログラム、アルゴリズム、技術、プロセス、または方法として具現化された抽象化知識を表すことができる。データオブジェクトと同様に、変換オブジェクトは、データベースシステム、ファイルに基づく記憶システム、または任意のデータストアに格納されてもよい。格納された変換オブジェクトを検索し、様々なデータオブジェクトに適用することによって、実行モデル内で様々なタイプのデータを計算することができる。

例えば、実行モデル１００において、第１タイプの変換オブジェクト１０５および１０６は、例えば、第１タイプのデータオブジェクトに対応するプールまたは生データストリームから取り出した重要なデータを示すコンパクト表現を生成することによって、第１タイプのデータオブジェクトに基づいて、第２タイプのデータオブジェクトを計算するための技術を具体化することができる。第２タイプの変換オブジェクト１１１は、第２タイプのデータオブジェクトに基づいて、第３タイプのデータオブジェクトを計算するための技術を具体化することができる。第３タイプの変換オブジェクト１１５は、第３タイプのデータオブジェクトに基づいて、第４タイプのデータオブジェクトを計算するための技術を具体化することができる。例えば、第３タイプの変換オブジェクト１１５は、基準から逸脱する観測結果または予測結果の度合に基づいて、指令を開発するための技術を含むことができる。第４タイプの変換オブジェクト１１９は、第４タイプのデータオブジェクトに基づいて、第１タイプのデータオブジェクトを計算するための技術を具体化することができる。例えば、第４タイプの変換オブジェクト１１９は、仮説（例えば、第３タイプのデータオブジェクト）に応答し且つ追加の生入力（例えば、第１タイプのデータオブジェクト）を捕捉するように設計されてもよい。

実行モデル１００内の様々なフィルタオブジェクト１０１、１０２、１０９、１１３および１１７は、データオブジェクトと同様に、例えばデータベースまたは他の記憶システムに格納されたデータとして、または変換オブジェクトと同様に、例えば自動化ソフトウェアプログラム、アルゴリズムまたは技術などとして、またはデータとプログラムの組み合わせとして実装されてもよい。場合によって、フィルタオブジェクト１０１、１０２、１０９、１１３および１１７は、データオブジェクトのどの程度の変化が変換オブジェクトを呼び出すのに十分であるかを決定するための最小データ変更閾値を実装することができる。追加的または代替的に、フィルタオブジェクト１０１、１０２、１０９、１１３および１１７は、データオブジェクトのどの特性が変換オブジェクトを呼び出すのに十分であるかを決定するための条件、極性またはデータの組み合わせによって、最小信頼レベルを実装することができる。上述したように、フィルタは、データベーストリガ、リアルタイムジャーナル解析および／または多時間または双時間データベースシステム上に登録されたクエリを含むことができる。

データオブジェクトおよび変換オブジェクトは、例えば、データオブジェクトからノイズを除去し、異常値データを検出および抽出し、周期性動向を検出および修正するためのメカニズムを実装することができる。例えば、周期性動向トランスフォーマは、持続性データオブジェクトのデータ変化の周期性増加動向を検出し、平滑化強度および平滑化強度増加率を更新して、強度の増加動向を予測することができる。この例において、予測された強度の正規化残差をトランスフォーマとして用いて、測定される強度が予期強度から逸脱していることを表す異常値を検出することができる。さらに、複数の独立のトランスフォーマは、データの推定を追跡することと並列して、異なる時間スケールで、処理を実行することができる。時間スケールに応じて、これらの並列トランスフォーマは、周期性動向、長期容量需要、短期エンドポイント（メモリ不足エラー）などを予測するための複数のポリシーとして機能することができる。

データオブジェクトと同様に、変換オブジェクトは、データ駆動型監視制御ループの実行中に動的に変化することができる。いくつかの実施形態において、監視制御ループは、様々な技術（例えば、非線形回帰）を実行することによって、システム内のJava（登録商標）仮想マシン例の変換パラメータおよび周期ファクタを推定することができる。このような例において、監視制御ループは、（例えば、HotspotまたはJRockit計測器と共にMBeanを使用する）各Java仮想マシンに埋め込まれた１つ以上の変換基準／変換プログラムを更新するために、変換パラメータおよび周期ファクタを変換オブジェクトに組み込むことができる。

１つ以上の実行エンジンを用いて、実行モデル１００によって具体化されるアプリケーションなどのデータ駆動型ループアプリケーションを開始、追跡および制御することができる。データオブジェクト、トランスフォーメーションオブジェクトまたはフィルターオブジェクトが動的に更新されるたびに、実行エンジンは、例えば、図示の実行モデル１００内の各オブジェクトをインスタンス化し、次いで各オブジェクトによって実行される様々なプロセスを実行および監視すると共に、実行プロセスを制御することができる。実行エンジンは、（例えば、オブジェクト指向クラスを介して）様々なオブジェクトをインスタンス化した後、実行モデル１００内のデータオブジェクトのうち１つのデータオブジェクトの新しいデータおよび／または更新されたデータを検出することができる。新しいデータまたは更新されたデータを検出した後、実行エンジンは、適切なフィルタオブジェクトを呼び出すまたはフィルタ（例えば、式フィルタまたは反復クエリ）を自動的に実行することによって、データを分析および／または修正することができ、後続の変換オブジェクトを呼び出すべきか否かを決定することができる。必要に応じて、実行エンジンは、変換オブジェクトを呼び出すことによって、ループ内の次のダウンストリームデータオブジェクトを更新する、例えば第１タイプのデータオブジェクトに対する更新に基づいて、第２タイプのデータオブジェクトを更新することができる。したがって、フィルタまたは変換オブジェクトが後続のデータオブジェクトを更新すべきでないと判断するまで、ループアプリケーションを継続することができる。

また、多時間データベースのリポジトリ１２１は、低価値データおよび高価値データの両方を含むことができる。例えば、リポジトリ１２１は、（ＦＳＤ∪特徴）に対応するデータを含むことができる。（ガードとも呼ばれる）フィルタ１０１、１０２、１０９、１１３および１１７は、データベース内のフィルタ基準またはプロセスを実行し、異なる時間状態のフィルタ基準／プロセス間の差を評価するために、リポジトリ１２１内のデータに対してクエリを行うことによって、現在のデータ状態および／または過去のデータ状態を検索することができる。

また、データ駆動型ループアプリケーションの実行中に、任意の時点で任意のデータオブジェクトに対して追加のデータ更新を行うことができる。例えば、変換オブジェクト１１５がデータオブジェクト１１６を更新する実行の最中に、別のデータオブジェクト１０３が異なるプロセスのデータベーストランザクションまたは新しいデータストリームデータの到着などによって動的に更新されることができる。この例において、実行エンジンは、変換オブジェクト１１５の実行を完了した後、フィルタリング１０１および／または変換オブジェクト１０５を呼び出すことによって、事実上、ループアプリケーションの命令ポインタを実行モデル１００の完全に異なる部分に変更することができる。別の例において、実行エンジンは、変換オブジェクト１１５の実行完了を待たずに、フィルタ１０１および／または変換オブジェクト１０５を呼び出すことによって、事実上、ループアプリケーションの複数の命令ポインタを実行モデル１００の異なる部分で非同期に動作させることができる。任意の時点で任意のデータオブジェクトに対して追加のデータ更新を行うことができるが、実行モデル１００内のデータオブジェクト１０３、１０４、１１０、１１４および１１８は、一貫した状態を表すことができる。

実行モデル１００の様々な実装において、異なるデータオブジェクト、異なる変換オブジェクトおよび／または異なるフィルタオブジェクトをデータベースまたは他のデータストアに格納することができ、様々なデータベース技術を用いて、実行モデル１００および本明細書に開示された他の技術を実装することができる。例えば、実行モデル１００内の一部または全部カテゴリのオブジェクトに対して、オブジェクト指向クラス、例えば、データオブジェクトクラスおよび変換オブジェクトクラスを確立することができる。実装された各親クラスから、タイプ特有のサブクラス、例えば、第１タイプのデータオブジェクトサブクラス、第２タイプのデータオブジェクトサブクラス、第３タイプのデータオブジェクトサブクラスおよび第４タイプのデータオブジェクトサブクラス、並びに、第１タイプの変換オブジェクトサブクラス、第２タイプの変換オブジェクトサブクラス、第３タイプの変換オブジェクトサブクラスおよび第４タイプの変換オブジェクトサブクラスを導出することができる。各クラスおよびサブクラスの実装には、適用可能なオブジェクトのカテゴリおよびタイプに適したラベルおよび属性を与えることができる。例えば、実行エンジンは、第１タイプのデータオブジェクトをインスタンス化し、そのデータオブジェクトに関連する属性値を格納することができる。同様に、第１タイプの変換オブジェクトをインスタンス化し、その変換オブジェクトに関連する属性値を格納することができる。以下同様。これらのオブジェクトの各々の定義およびこれらのオブジェクトの全てのインスタンスは、１つ以上のアプリケーションに関連するデータストアに格納されてもよい。例えば、データ駆動型変換ループアプリケーションの実行エンジンは、様々なデータベース技術を用いて、データオブジェクト、変換オブジェクトおよびフィルタオブジェクトの定義およびインスタンスを格納することができる。各インスタンスの履歴を取り出すことができるように、双方向および／または多時間データベースを用いて、各オブジェクトの各インスタンスの複数のバージョンを維持することができる。さらに、いくつかの実施形態において、実行エンジンは、オブジェクトのマッピング（クラス、サブクラスなどのインスタンス化）を生成し、格納することができる。

いくつかの実施形態において、エージェントオブジェクト（またはアクターオブジェクト）は、実行モデル１００に含まれてもよく、および／または実行エンジンによって生成および制御されてもよい。エージェントオブジェクトは、自動化エージェントに対応してもよく、個体、個体群または組織を表してもよい。エージェントオブジェクトは、オブジェクト指向プログラミングオブジェクトとしてインスタンス化することができ、プロファイルおよび出所環境などの属性を有することができる。自動化エージェントの例示として、アルゴリズムプロセスをカプセル化するソフトウェア、例えば、ワークフロー、シミュレーション、サポートベクトルマシン、神経ネットワーク、ベイジアンネットワークなどを挙げることができる。自動化エージェントは、エージェントの能力を示すプロファイルを有することができる。エージェントオブジェクトは、組織環境、スキルプロファイル、知識プロファイル、関心プロファイル、嗜好プロファイルなどの属性を有することができる。知識プロファイルは、エージェントオブジェクトに関連付けられ、システムが一般にエンコードしない暗黙知識を表すことができる。エージェントオブジェクトが個体を表す場合、エージェントオブジェクトは、そのオブジェクトによって表される個体のリアルタイム存在および／またはリアルタイム活動を特定することができる。実行エンジンは、エージェントオブジェクトの属性に基づいて、エージェントオブジェクトを実行保留中の特定の変換オブジェクトに割り当てることができる。

以下でさらに説明するように、実行モデル１００は、特殊のアルゴリズムを進化させることができる。これらの特殊のアルゴリズムを用いて、分類（classification）、評価（assessment）、解決（resolution）および実施（enactment）のような変換を実行することによって、環境のデータまたは状態を変換することができる。変換オブジェクトは、直接に同時に動作する必要のない特殊のアルゴリズムを表すことがある。データ駆動型プロセスの実行エンジンは、変換オブジェクトの多様なアルゴリズムを別々に開発し、これらのアルゴリズムを、標準化データモデルを介して相間作用する様々なタイプの変換オブジェクト（例えば、第１タイプから第４タイプの変換オブジェクト）としてカプセル化することによって、共通アプリケーションとして進化できる単一のシステムに統合することができる。システム内の様々なアルゴリズムは、相互に補完し、強化することができる。また、実行モデル１００内の一部の構成要素は、エージェントオブジェクトのインスタンスと情報を交換するユーザインターフェイスおよびメッセージ通信システムを含むことができる。実行モデル１００は、データオブジェクトインスタンスの変化を連続的に照会し、従属の変換オブジェクトの実行を開始することによって、情報交換を駆動する。さらに、変換オブジェクトのアップグレード（例えば、アルゴリズムの更新、新しいバージョンのソフトウェアのリリースなど）は、その変換オブジェクトによる変換を既に適用したデータオブジェクトインスタンスの遡及処理をトリガすることができる。この場合、新しい変換オブジェクト／更新された変換オブジェクトを展開した直後、変換オブジェクトによる変換を適用することができる。

図２を参照して、データ駆動型アプリケーションを実行するコンピュータシステムを示すブロック図が示される。例示のシステム２００は、クラウドベースシステムのコンピュータ高次構成を表すことができる。このシステムを用いて、ビッグデータの解析問題を処理するように設計されたデータ駆動型アプリケーションの実装および実行の管理を行うことができる。そのような問題は、非常に巨大なデータ量、高いデータ速度、複雑なデータタイプを含み、ほぼリアルタイムで複雑なイベントを処理する能力を必要とする。この例において、システム２００は、HADOOPソフトウェアフレームワークを用いて、データ駆動型アプリケーションを起動および管理するためのシステムに対応する。理解すべきことは、他の例において、HADOOPの代わりに、他のソフトウェアフレームワークを使用することができることである。例示的なシステム２００に示された様々な構成要素、例えば、双時間データベース２１０、オーケストレーションエンジン２２０、リソースマネージャ２３０および計算クラスタ２４０は、ハードウェア要素とソフトウェア要素とネットワーク要素との特殊な組み合わせを含む個別コンピュータシステムまたは共有コンピュータシステムに実装されてもよい。

この例において、双時間データベース２１０は、本明細書に記載のハードウェア要素、ソフトウェア要素およびネットワーク要素を含む様々なデータベースサーバおよび技術に実装することができる。双時間（または他の多時間）データベーススキーマを使用するデータベース２１０の場合、データベース２１０内に格納された様々な異なるオブジェクト（例えば、データオブジェクト、変換オブジェクトおよびフィルタクエリなど）は、データが永続的になるまたは回復可能になるまたは他の回復可能なトランザクションに可視になるときのトランザクション時間を用いて、タイムスタンプを付けることができる。その後、有効時間およびトランザクション時間からなる双時間クエリを用いて、これらのオブジェクトを呼び出すことができる。双時間データベース２１０におけるこれらの物象化関係に基づいて、データに明示された任意のイベント、例えば、データオブジェクト、変換オブジェクトまたはフィルタの更新に対して、変更を引き起こした原因を判断することができる。例えば、双時間データベース２１０内の関係は、特定の時間間隔内に第１タイプのデータのインスタンスが１種類の問題として分類され、問題を解決するために、特定の修正がビッグデータシステム内で制定されたことを示すことができる。この例において、双時間データベース２１０は、データの変更が発生した理由を判断するために、各修正を決定および制定した時間順に、制定された複数の異なる修正をオーケストレーションエンジン２２０または他のシステム要素に提供することができる。他の実施形態において、他の多時間データベース、例えば、決定タイムに対応するデータ項目の追加タイムラインまたは時間データを含む多時間データベースを使用することができる。

専用のハードウェア要素、ソフトウェア要素およびネットワーク要素の組み合わせを用いて、オーケストレーションエンジン２２０を実装することによって、ビッグデータ解析システム用のアプリケーションを作成および管理することができる。オーケストレーションエンジン（または実行エンジン）２２０は、双時間データベース２１０と共に同一のデータベースシステムに実装されてもよく、別個の制御サーバとして実装されてもよい。いずれの場合でも、オーケストレーションエンジン２２０は、複雑な時間で登録されたフラッシュバッククエリおよび式フィルタのような、双時間データベース２１０に関連するデータベース技術を活用するように設計することができる。オーケストレーションエンジン２２０は、データ変換ループアプリケーションをHADOOPリソースマネージャ２３０（例えば、HADOOP YARNリソースマネージャ）などのリソースマネージャに割り当てることができる。その割り当てに応答して、HADOOPリソースマネージャ２３０は、HADOOPクラスタ２４０を備える計算ノードを選択し、選択したHADOOPクラスタ２４０内のデータ変換ループアプリケーションのために、アプリケーションマスタ（ＡＭ）２４１を起動することができる。場合によって、アプリケーションマスタ２４１は、HADOOPリソースマネージャ２３０と交渉することによって、ループアプリケーションのデータ変換を実行するためのコンテナを得ることができる。ビッグデータ解析の場合、このようなデータ変換行動は、例えば、機械学習行動、大量の生データを使用する分類行動、ベイジアン信念ネットワーク（ＢＢＮ）エンジン、非線形回帰プロセス、周期性動向プロセスを含んでもよい。いくつかの実施形態において、データ変換ループアプリケーションのアプリケーションマスタ２４１は、長時間実行するプロセスであってもよい。しかしながら、アプリケーションのループ処理（例えば、実行モデル１００）の実行を停止または中断したときに、HADOOPクラスタ２４０内のコンテナを再使用することができる。オーケストレーションエンジン２２０は、各データ変換ループアプリケーションの各アプリケーションマスタ２４１の状態を管理することができ、各アプリケーションマスタ２４１は、関連するデータ変換インスタンス２４２の状態を管理することができる。アプリケーションマスタ２４１およびデータ変換インスタンス２４２は、１つ以上の高価値データオブジェクトを双時間データベース２１０内の対応するデータに同期させることができる。

特定の例において、システム２００は、クラウドベースSaaSシステム用のビッグデータ解析アプリケーションに対応することができる。例えば、パブリッククラウド内の各テナント型アプリケーションSaaSシステムは、１つ以上の仮想化技術を使用するポッドまたは仮想マシンとデータベースインスタンスとの集合体として実装することができる。アプリケーションSaaSのポッド規模のモデルは、マシンデータの論理的なクラスタリングを可能にし、同一ポッド内のデータストリームを結合および相関させるためのデータ局所性を利用することができるという解析利点を有する。この環境において、各ポッドのデータストリーム（各センサが１つのデータストリームを提供する）の数は、ポッドの数が連続的に増加することにつれて、増加する。データストリームは、例えば、WebLogicサーバログ、Java仮想マシン（ＪＶＭ）ガベージコレクタログ、ＪＶＭスレッドダンプログ、ＨＴＴＰアクセスログ、オペレーティングシステム監視ログ、ネットワークデバイスログ、データベースログなどを含むことができる。データストリームは、例えば、一組のHBaseテーブルおよびHDFSフォルダに格納することができる。いくつかの例において、横行キーのプレフィックスにおけるポッド名の３２桁のＭＤ５摘要を用いて、HBaseテーブル内の領域を分割することによって、各ポッドの全てのデータストリームを同一HBase領域サーバに併置することができる。縦列セル内のデータストリームは、閾値より大きくなると、HDFSファイルにオフロードされてもよい。抽出変換ロード（ＥＴＬ）操作は、MapReduceのマッパーによって実行され、マッパーとHBase領域サーバとの間のデータローカル類似性によって、同一ポッドのHDFSファイルとHBase領域を同一のデータノードまたはHBase領域サーバの同一場所に配置することができる。この例で説明するデータ編成は、ループアプリケーション、データ変換操作、HBase領域およびHDFSデータノード用のアプリケーションマスタ２４１の間のデータローカルおよび比較的小さい比率のラックローカル計算を可能にすることができる。さらに、このような例において、オーケストレーションエンジン２２０およびアプリケーションマスタ２４１は、動的実体モデルを用いて、HADOOPクラスタ２４０を有する計算ノードを選択して、データローカルアプリケーションマスタ２４１およびコンテナを起動することができる。

上記の例におけるアプリケーションSaaSの動的実体モデルは、顧客ポッドと、仮想マシンに配置されたアプリケーションと、サーバのクラスタ内の物理計算ノードに配置された仮想マシンと、サーバ内の物理データノードに配置されたデータベースと、スレッドセグメント、スレッドクラスおよび／またはスレッドクラス間の依存関係に従って定期的なスレッドダンプ内の高強度スタックトレースの動的分類によって発見された実体との間の関係を表すことができる。依存関係は、スレッド間のスレッド間およびプロセス間の交信を取り込むことができる。したがって、スタックトレース分類モデルを実体モデルに追加することができる。上述したように、動的実体モデルは、時間データベース（例えば、双時間データベースまたは他の多時間データベース）によって管理されてもよい。

図３を参照して、多時間データベース内のフィルタクエリに基づいて、データオブジェクト変換処理を呼び出すためのプロセスを示すフローチャートが示される。以下で説明するように、このプロセスにおけるステップは、システム２００内の１つ以上の構成要素、例えば、双時間データベース２１０、オーケストレーションエンジン２２０およびリソースマネージャ２３０などによって実行されてもよい。しかしながら、理解すべきことは、多時間データベースの維持および更新、多時間データベース上のフィルタクエリの評価およびフィルタクエリ評価に基づく変換処理の呼び出しを含む本明細書に記載の技術は、上述した特定のシステムおよびハードウェア実装に限定される必要がなく、ハードウェア要素、ソフトウェア要素およびネットワーク要素の他の組み合わせを含む他のハードウェアおよびシステム環境内に行うこともできることである。さらに、例示では、データベースデータの更新に基づいてプロセス３００を実行するが、変換オブジェクトおよび／またはフィルタオブジェクトに対する更新に応答して、同様のプロセスおよび技術を実行することもできる。

ステップ３０１において、例えば、データ駆動型アプリケーションに関連するデータストアおよび／またはデータ管理装置から、データベースの更新を受信することができる。例えば、１つ以上のデータ更新を含むデータベーストランザクションは、双時間データベース２１０上で開始されてもよく、オーケストレーションエンジン２２０、HADOOPクラスタ２４０または他のデータソースを介して受信されてもよい。ステップ３０１で受信した更新データは、図１のデータオブジェクトを参照して上述した様々なデータタイプ（例えば、非構造化対話、フォーム入力、装置から収集された量的な測定値、イベントストリームデータ、ＸＭＬ、またはテキストドキュメント）のいずれかに対応する構造化、非構造化および／または半構造化データを含むことができる。様々な実施形態において、受信したデータは、例えば、Java仮想マシンのガベージコレクタからのデータストリーム、定期的なスレッドダンプからのスタックトレース、メモリヒープダンプ、およびデータベースＡＷＲレポートなどを表すことができる。

ステップ３０２において、ステップ３０１で受信したデータ更新を反映するように、１つ以上の多時間データベースを更新することができる。例えば、双時間データベース２１０において、更新データは、更新データのトランザクション時間および／または有効時間を含む適切なデータベース構造に書き込むことができる。受信データに関連するトランザクション時間は、データが真であると考えられる１つ以上の時間範囲に対応することができる。有効時間は、受信データがモデル化されたシステムに対して実際に真である時間範囲に対応することができる。例えば、トランザクション時間および有効時間の一方または両方は、ステップ３０１で受信したデータに含まれてもよい。代替的には、トランザクション時間および／または有効時間は、例えば、オーケストレーションエンジン２２０によって、受信データに対して動的に決定されてもよい。場合によって、受信データの有効時間は、データに関連するオブジェクトのライフサイクルまたはデータベースのライフサイクルによって、定められてもよい。さらに、特定のオブジェクトは、複数の有効時間を含むことができる。例えば、特徴ベクトルは、異なっており且つ潜在的に重畳する有効時間を有する複数の特徴を含むことができる。この場合、特徴ベクトルの有効時間は、全ての関連特徴の有効時間の共通部分であってもよい。

いくつかの実施形態において、本明細書に記載のシステム、ソフトウェアフレームワークおよび／または実行モデルは、各データオブジェクト（例えば、図１に示す全ての第１タイプから第４タイプのデータオブジェクト）の有効時間、およびデータが永続的になるまたは回復可能になるまたは他の回復可能なトランザクションに可視になるときのトランザクション時間を追跡することができる。これらのシステムは、有効時間およびトランザクションの両方を追跡することによって、異なる時間でデータオブジェクトインスタンスのデータ値を決定することができ、データオブジェクトインスタンスに行われた過去変更の理由を決定することができる。例えば、第４タイプのデータオブジェクト（例えば、指令タイプのデータオブジェクト）の場合、第４タイプのデータオブジェクトの基礎となっている異なる第１タイプ～第３タイプのデータオブジェクトは、形式上、第４タイプのデータオブジェクトに関連する可能性がある。したがって、オーケストレーションエンジン２２０または他のシステム要素は、第４タイプのデータオブジェクトの現在のバージョンを生成した時点で、第４タイプのデータオブジェクトに関連する利用可能な第１タイプ～第３タイプデータオブジェクトを遡及的に決定することができる。時間経過と共に、新しいデータは、実行モデル内の様々な第１タイプ～第４タイプのデータオブジェクトに対する更新の形で、潜在的にはループアプリケーション内に以前に生成された指令および類似データの結果として利用可能である。この新しいデータは、新しいデータが利用可能になる（例えば、回復可能になるまたは他の回復可能なトランザクションに可視になる）ときの異なるトランザクション時間における過去の有効時間で、異なるオブジェクト／データ状態に遡及的に適用することができる。

したがって、過去データに基づいて後続の変換処理を実行した後にデータに生じた任意の変更／更新は、非因果的なものとして分離することができ、変換処理に形式上関連する有効時間でデータ変更を遡及的に適用できるとしても、データ変更のトランザクション時間を用いて記述することができる。後に取得され、データ変換処理の能力に影響を与える可能性のあるデータ更新は、取得する前に既に存在した場合、データ変換処理の非因果的ものとして明確に特定することができる。これらの後に取得されたデータ更新は、様々なデータビュー、レポートまたは解析から除去され、データ変換処理結果の基礎となる基礎データに混乱を招くことはない。システムは、任意の時点で、特定のデータ変換処理を開始した理由、および結果（例えば、更新した第２タイプのデータオブジェクトインスタンス）を生成するためにデータ変換処理（例えば、１つ以上の第１タイプのデータオブジェクトインスタンス）に利用可能な基礎データを推定することができる。これらの遡及解析は、後のトランザクション時間でデータを修正する前に、先のトランザクション時間で様々なデータをコールすることによって、行うことができる。特定の実施形態において、双時間出所性能は、特定の規制要件を満たすために使用され得る。

ステップ３０３において、ステップ３０２で多時間データベースに対して行われた更新に基づいて、１つ以上のフィルタクエリを特定する。フィルタクエリは、多時間データベース内のデータ変更状態を追跡および管理するために使用される任意の技術およびメカニズムを含むことができる。例えば、フィルタクエリは、双時間データベース２１０内の式フィルタ、登録クエリ、トリガおよび連続クエリ通知などのデータベース構成を含むことができる。また、フィルタクエリは、オーケストレーションエンジン２２０および／または他のシステム要素内に実装された前方連鎖データおよび／または後方連鎖データの抽出ルールを含むことができる。これらの前方連鎖データおよび／または後方連鎖データは、複数の推論エンジンおよび／または時系列アルゴリズムを統合することができる。一部のフィルタクエリ、例えば、式フィルタおよび登録クエリは、１つ以上のデータベースシステム内に完全に実装されてもよく、他のフィルタクエリ、例えば、オーケストレーションエンジン２２０または他のシステム要素の内部に実行するデータベースアクセスソフトウェアは、データベースの外部に部分的または全体的に実装されてもよい。

この例において、多時間データベースにおける一組の基礎データの変更に応答して、通知を提供しおよび／または特定の処理を実行するように、フィルタクエリを設計および実装することができる。場合によって、フィルタクエリは、関係データベーステーブルの１つ以上の列に関連する条件式に対応してもよい。例えば、フィルタクエリは、目標の行を特定するために、ステップ３０３のデータ更新による入来データと、データベースの列に格納された式とをマッチングすることができる。場合によって、フィルタクエリは、単純化ＳＱＬクエリの基礎データがデータベース内で変化するたびに、通知を提供するまたは機能を実行する単純化ＳＱＬクエリに対応してもよい。例えば、ＳＱＬクエリの結果がデータベース内の４つの別々の基礎データ要素に依存する場合、フィルタクエリは、いずれかの基礎データ要素がデータベース内で変化するたびに、通知を生成しまたはプロセスを実行することができる。場合によって、フィルタクエリは、ＳＱＬクエリまたは他のデータ駆動型プロセスの結果が変化したことを確実に判定するのでなく、結果の基礎となるデータの変化により、ＳＱＬクエリまたは他のデータ駆動型プロセスが潜在的に変化し得ることを判定することができる。別の場合において、次回に更新データを用いてＳＱＬクエリまたは他のデータ駆動型プロセスを実行するときに、フィルタクエリは、ＳＱＬクエリまたは他のデータ駆動型プロセスの結果が確実に変化することを判定することができる。

ステップ３０４において、多時間データベース内の更新データに関連する１つ以上のフィルタクエリを特定した後、現在時間状態の多時間データを用いて、フィルタクエリを実行することができる。したがって、ステップ３０１で受信した更新データおよび現在データ状態の他の多時間データベースに基づいて、フィルタクエリを実行することができる。

ステップ３０５において、過去時間状態の多時間データを用いて、ステップ３０４に実行された同様の１つ以上のフィルタクエリを実行してもよい。場合によって、過去時間状態は、関連する変換動作（または処理）を過去に実行した過去時間に対応してもよい。上述したように、フィルタクエリは、変換動作または他の自動化処理に関連付けられてもよい。例えば、例示的な実行モデル１００において、フィルタクエリ１０１および１０２は、変換オブジェクト１０５および１０６を各々呼び出す時間を判断するためのガードとして機能することができる。同様に、フィルタクエリ１０９は、変換オブジェクト１１１を呼び出す時間を判断することができる。したがって、データ変換オブジェクトのインスタンスに関連付けられたフィルタクエリの場合、ステップ３０５で決定された過去時間状態は、データ変換オブジェクトを実行した最新時間である。ステップ３０５でフィルタクエリの実行に対応する過去時間状態を決定した後、データベースに記憶された双時間データ（例えば、トランザクション時間および有効時間）を用いて、過去時間のデータベースの正確なデータ状態を生成することができる。場合によって、ステップ３０５においてフィルタクエリを実行せず、過去時間に決定されたフィルタクエリの過去実行結果を読み出し、ステップ３０５に使用してもよい。

ステップ３０６において、現在時間状態のデータを用いて実行した１つ以上のフィルタクエリの結果（ステップ３０４）と、過去時間状態のデータを用いて実行した同様のフィルタクエリの結果（ステップ３０５）とを比較し、結果間の差を所定の閾値と比較する。特定の実施形態において、ファクト、知覚、仮説または指令の変更は、所定の閾値条件、方向性、特性または値を用いて、定性化または定量化することができる。閾値条件は、変換の結果を変更することができる変換オブジェクトの変更、例えば、アルゴリズムの新バージョン、バグ修正、モデルパラメータの個別化を含むことができる。フィルタクエリの実行結果の間の差が閾値に等しいまたは閾値を超える場合（３０６：Ｙｅｓ）、ステップ３０７でデータ変換処理を呼び出すことができる。このデータ変換処理は、図１の変換オブジェクトを参照して上記に説明したものと同様である。例えば、ステップ３０７で呼び出されたデータ変換処理は、例示的な実行モデル１００の第１タイプ～第４タイプの変換オブジェクトのインスタンスに対応してもよい。

したがって、各フィルタクエリは、関連する変換処理を実行する時間を判断するために使用されるファクト、認知結果、仮説または指令の変化の１つ以上の閾値条件、方向性、特性または値を有することができる。閾値条件、方向性、特性または値の変化が高いほど、基礎となる時間データにおける変更がより多くなり、関連する変換処理をより少なめに実行する。フィルタクエリに関連する閾値条件、方向性、特性または値は、特定の実施形態において、例えば、頻繁なデータ更新または連続的なデータ更新を受信するビッグデータ解析および他のビッグデータ駆動型アプリケーションにおいて有利であり得る。例えば、WebLogicサーバログ、Java仮想マシン（ＪＶＭ）ガベージコレクタログ、ＪＶＭスレッドダンプログ、ＨＴＴＰアクセスログ、オペレーティングシステム監視ログ、ネットワークデバイスログ、およびデータベースログなどの大規模なデータストリームを受信し且つ解析するように実装されたループアプリケーションにおいて、システムに受信した全ての更新データに対して変換処理を実行することは、非効率的である。この場合、フィルタクエリおよび関連する閾値条件、方向性、特性または値は、ループアプリケーション内に実行されるデータ変換処理を制限するガードとして機能することができる。その結果、基礎データがダウンストリームデータオブジェクトの著しく変更を引き起こす可能性のある程度まで変化した場合に限り、データ変換処理を行うことができる。

いくつかの実施形態において、例示のプロセス３００の様々なステップは、異なるデータベーストランザクションにおよび／または非同期的に実行されてもよい。例えば、大量のストリーミングデータまたは他の頻繁なデータ更新を受信し且つ解析するデータ駆動型アプリケーションにおいて、一方のトランザクションで、ステップ３０２の多時間データベースを更新し、他方のトランザクションで、ステップ３０７のデータ変換処理を実施することが有利であり得る。以下で説明するように、ステップ３０７のデータ変換処理は、追加の反復的なループデータ更新および／または追加の変換処理を実行させる可能性がある。したがって、外部から受信したデータを用いてデータベースを更新するトランザクション（例えば、ステップ３０１～３０２）またはアプリケーションループインスタンスを開始した他のイベントを実行するトランザクションとは別個の１つ以上のトランザクション内に、データ変換および更新を行うアプリケーションループ（例えば、ステップ３０７および／または後続のステップ４０１～４１６）を実行することによって、一部のシステムの性能および安定性を強化することができる。したがって、いくつかの実装例において、プロセス３００のステップ３０１および３０２は、１つの専用データベーストランザクションに実行されてもよく、ステップ３０３～３０７（およびこれらのステップに基づいて行われる後続のプロセス４０１～４１６）は、１つ以上の別個のトランザクションに実行されてもよい。さらに、いくつかの実施形態において、（例えば、データベースエンジンの非同期実行モードにおいて）潜在的に低速または長時間実行するループアプリケーションを非同期的に実行することができる。

図４を参照して、ループデータ変換アプリケーションの実行を示すフローチャートが示される。プロセス４００内のステップは、システム２００内の１つ以上の構成要素、例えば、双時間データベース２１０、オーケストレーションエンジン２２０およびリソースマネージャ２３０によって実行されてもよい。しかしながら、理解すべきことは、本明細書に記載の技術は、上述した特定のシステムおよびハードウェア実装に限定される必要がなく、ハードウェア要素、ソフトウェア要素およびネットワーク要素の他の組み合わせを含む他のハードウェアおよびシステム環境内に行うこともできることである。

図４に示す例示的なプロセス４００は、オーケストレーションエンジン２２０または他のシステム要素によって実装された実行モデルであって、上述した図１の実行モデル１００と同様である。この例において、例示のループプロセス４００は、実行モデル１００と同様に、意図しない不確定なループの発生を回避するために、各データ変換処理を行う前にフィルタおよび閾値を実行するが、潜在的に反復するデータ変換ループおよび／または不確定なデータ変換ループであってもよい。例示的なプロセス４００に使用された異なるデータオブジェクト（例えば、第１タイプの～第４タイプのデータオブジェクト）は、異なる属性または特性を有する異なるタイプのデータオブジェクトに対応してもよく、異なる変換オブジェクト（例えば第１タイプ～第４タイプの変換オブジェクト）は、１つのタイプのデータオブジェクトを別のタイプのデータオブジェクトに変換するための異なるアルゴリズムまたはシステムの実装に対応してもよい。さらに、例示的なプロセス４００は、４つのタイプのデータオブジェクトおよび４つのタイプの変換オブジェクトを含むが、理解すべきことは、異なる実装例において、異なる数のデータオブジェクトおよび変換オブジェクト（例えば、２つのデータオブジェクトおよび２つの変換オブジェクト、３つのデータオブジェクトおよび３つの変換オブジェクト、．．．、５つのデータオブジェクトおよび５つの変換オブジェクト）を使用することができることである。

プロセス４００は、ステップ４０１で開始することができる。ステップ４０１は、上述した変換処理を呼び出すステップ３０７に対応することができる。しかしながら、他の例において、プロセス４００は、ステップ４０１で開始する必要がなく、データ変換を呼び出すステップのいずれか（例えば、ステップ４０１、４０５、４０９または４１３）、データを生成および記憶するステップのいずれか（例えば、ステップ４０２、４０６、４１０または４１４）、またはフィルタを実行するステップのいずれか（例えば、ステップ４０３、４０７、４１１または４１５）で開始することができる。上述したように、データ駆動型ループアプリケーション処理は、多時間データベース２１０内のデータ状態の変更、変換オブジェクトの変更（例えば、アルゴリズムの更新、新しいバージョンのソフトウェアのリリースなど）、またはフィルタオブジェクトの変更（例えば、式フィルタクエリの更新など）に基づいて開始されてもよい。データ変換オブジェクトおよび／またはフィルタクエリの更新は、古いバージョンの変換オブジェクトおよび／またはフィルタを用いて過去に計算したデータの再計算をトリガすることができる。したがって、システムデータ、変換処理またはフィルタのうち１つ以上に対する更新は、アプリケーションループ処理４００の実行を開始することができる。また、場合によって、フィルタおよび／または変換オブジェクトに関連する閾値を動的に更新することができる。更新された閾値に応答して、閾値決定（例えば、ステップ４０４、４０８、４１２および４１６）のうち１つを動的に再実行することによって、アプリケーションループ処理４００を起動することができる。

図５を参照して、いくつかの例示的なデータ項目の有効時間を特定するグラフが示される。グラフ５００のｘ軸は、時間に対応する。グラフ５００に標記された時間（ｔ１～ｔ８）の各々は、システムに発生したイベント、例えば、（例えば、変換オブジェクトインスタンスを介した）データ変換処理の実行、（例えば、データオブジェクトインスタンスを介した）データベースデータの更新、もしくは変換処理またはフィルタの更新に対応する。グラフ５００のｙ軸は、多時間データベースにおける別個のデータ項目、例えば、上述した１つ以上のデータオブジェクトタイプのインスタンスに対応する。グラフ５００の線分は、各データ項目の有効時間の範囲を示す。例えば、データＤ１は、時間ｔ３とｔ５との間の有効データに対応し、データＤ２は、時間ｔ１とｔ２との間の有効データに対応し、以下も同様である。この例のデータが双時間データであるため、複数の異なるデータ項目Ｄ１～Ｄ８は、異なる時間における同一のデータ（例えば、同一のデータオブジェクトインスタンス）を表すことができる。例えば、データ項目Ｄ１は、時間ｔ３から時間ｔ５までのデータオブジェクトインスタンスを表し、データ項目Ｄ８は、時間ｔ５から時間ｔ８までの同一のデータオブジェクトインスタンスを表すことができる。

グラフ５００に示された有効時間データを用いて、例えば、上述したステップ３０５の遡及解析を実行することができる。データ変換処理の再呼び出しまたは再実行を行うためにおよび／またはデータ駆動型ループアプリケーションに使用されるデータ、プロセスまたはフィルタを遡及的に変更するために、多時間データベース内の有効時間データを用いて、マルチデータベースの任意の過去データ状態を検索することができる。例えば、データ駆動型ループアプリケーションは、多時間データベース２１０内のデータ状態および／または現在時間（例えば、ｔ８）における変換処理またはフィルタの結果および過去時間（例えば、ｔ６）における同様のデータまたは処理を比較することができる。この例において、現在時間（ｔ８）のデータ状態は、データ項目Ｄ３、Ｄ５、Ｄ７およびＤ８で構成され、過去の有効時間（ｔ６）のデータ状態は、データ項目Ｄ３、Ｄ４、Ｄ５、Ｄ６およびＤ８で構成される。したがって、対応するフィルタクエリおよびデータ変換処理などは、現在時間および過去時間に実行された変換処理および処理を駆動した基礎データの状態を正確に反映することができる。

図６を参照して、本発明の様々な実施形態を実現することができる例示的な分散システムの構成要素を示すブロック図が示される。図示の実施形態において、分散システム６００は、１つ以上のネットワーク６１０を介して、ウェブブラウザまたは専用クライアント（例えば、Oracle（登録商標）フォーム）などのようなクライアントアプリケーションを実行および作動するように構成された１つ以上のクライアントコンピューティング装置６０２、６０４、６０６および６０８を含む。サーバ６１２は、ネットワーク６１０を介して、リモートクライアントコンピューティング装置６０２、６０４、６０６および６０８と通信可能に接続されてもよい。

さまざまな実施形態において、サーバ６１２は、システムの１つ以上のコンポーネントによって提供される１つ以上のサービスまたは１つ以上のソフトウェアアプリケーションを実行するように構成されることができる。いくつかの実施形態において、これらのサービスは、ウェブサービスまたはクラウドサービスとして、またはSaaS（Software as a Service）モデルに基づいて、クライアントコンピューティング装置６０２、６０４、６０６および／または６０８のユーザに提供されてもよい。よって、クライアントコンピューティング装置６０２、６０４、６０６および／または６０８を操作するユーザは、１つ以上のクライアントアプリケーションを用いて、サーバ６１２と情報を交換することによって、これらのコンポーネントによって提供されたサービスを利用することができる。

図示の構成において、システム６００のソフトウェア要素６１８、６２０および６２２は、サーバ６１２上に実装されている。他の実施形態において、システム６００の１つ以上の構成要素および／またはこれらのコンポーネントによって提供されたサービスは、１つ以上のクライアントコンピューティング装置６０２、６０４、６０６および／または６０８によって実現されてもよい。クライアントコンピューティング装置を操作するユーザは、１つ以上のクライアントアプリケーションを用いて、これらのコンポーネントによって提供されたサービスを利用することができる。これらの構成要素は、ハードウェア、ファームウェア、ソフトウェア、またはこれらの組み合わせで実現されてもよい。理解すべきことは、分散システム６００と異なるさまざまなシステム構成が可能であることである。したがって、図示された実施形態は、実施形態のシステムを実現するための分散システムの一例であり、限定することを意図していない。

クライアントコンピューティング装置６０２、６０４、６０６および／または６０８は、例えば、Microsoft Windows Mobile（登録商標）のようなソフトウェア、および／またはｉＯＳ、Windows（登録商標）フォン、アンドロイド（登録商標）、ブラックベリー（登録商標）１０およびパームＯＳなどのさまざまなモバイルオペレーティングシステムを実行することができ、インターネット、電子メール、ショートメッセージサービス（ＳＭＳ）、ブラックベリー（登録商標）または他の通信プロトコルが有効化された手持ち式携帯装置（例えば、iPhone（登録商標）、携帯電話、Ipad（登録商標）、タブレット、携帯情報端末（ＰＤＡ）または着用できる装置（Google Glass（登録商標）ヘッドマウントディスプレイ）であってもよい。クライアントコンピューティング装置は、例示として、Microsoft Windows（登録商標）オペレーティングシステム、Apple Macintosh（登録商標）オペレーティングシステムおよび／またはＬｉｎｕｘ（登録商標）オペレーティングシステムのさまざまなバージョンを実行するパーソナルコンピュータおよび／またはラップトップコンピュータを含む汎用のパーソナルコンピュータであってもよい。クライアントコンピューティング装置は、例えば、さまざまなGNU/Ｌｉｎｕｘオペレーティングシステム、例えば、Google（登録商標）Chrome OSを含むがこれに限定されない市販のＵＮＩＸ（登録商標）またはＵＮＩＸに類似するさまざまなオペレーティングシステムを動かすワークステーションコンピュータであってもよい。代替的にまたは追加的には、クライアントコンピューティング装置６０２、６０４、６０６および６０８は、ネットワーク６１０を介して通信可能なシンクライアントコンピュータ、インターネット対応のゲームシステム（例えば、Kinect（登録商標）ジェスチャ入力装置を備えるまたは備えないMicrosoft Xboxゲームコンソール）、および／またはパーソナルメッセージング装置などの他の電子機器であってもよい。

例示の分散システム６００は、４つのクライアントコンピューティング装置を備えると示されているが、任意の数のクライアントコンピューティング装置をサポートすることができる。他の装置、例えばセンサを有する装置は、サーバ６１２と情報を交換することができる。

分散システム６００のネットワーク６１０は、ＴＣＰ／ＩＰ（伝送制御プロトコル／インターネットプロトコル）、ＳＮＡ（システムネットワークアーキテクチャ）、ＩＰＸ（インターネットパケット交換）、Apple Talkなどを含むがこれらに限定されないさまざまな市販プロトコルのいずれかを使用してデータ通信をサポートすることができ、当業者に熟知される任意種類のネットワークであってもよい。単なる例示として、ネットワーク６１０は、イーサネット（登録商標）、トークンリングおよび／またはその他に基づくローカルエリアネットワーク（ＬＡＮ）であってもよい。ネットワーク６１０は、広域ネットワークまたはインターネットであってもよい。ネットワーク６１０は、仮想プライベートネットワーク（ＶＰＮ）を含むがこれに限定されない仮想ネットワーク、イントラネット、エクストラネット、公衆交換電話ネットワーク（ＰＳＴＮ）、赤外線ネットワーク、無線ネットワーク（例えば、ＩＥＥＥ（Institute of Electrical and Electronic Engineers）８０２．１１プロトコルスイート、Bluetooth（登録商標）、および／または任意の他の無線プロトコルの下で動作するネットワーク）および／またはこれらのネットワークと他のネットワークの組み合わせを含むことができる。

サーバ６１２は、１つ以上の汎用コンピュータ、専用サーバコンピュータ（例示として、ＰＣ（パーソナルコンピュータ）サーバ、ＵＮＩＸ（登録商標）サーバ、ミッドレンジサーバ、メインフレームコンピュータ、ラックマウントサーバを含む）、サーバファーム、サーバクラスタ、または任意の他の適切な構成および／または組み合わせから構成されてもよい。さまざまな実施形態において、サーバ６１２は、前述の開示に記載された１つ以上のサービスまたはソフトウェアアプリケーションを動かすように構成することができる。例えば、サーバ６１２は、本開示の実施形態に従って上記に説明した処理を実行するためのサーバに対応することができる。

サーバ６１２は、上述したものいずれかを含むオペレーティングシステム、および任意の市販サーバオペレーティングシステムを動かすことができる。また、サーバ６１２は、ＨＴＴＰ（ハイパーテキスト転送プロトコル）サーバ、ＦＴＰ（ファイル転送プロトコル）サーバ、ＣＧＩ（共通ゲートウェイインターフェイス）サーバ、Java（登録商標）サーバ、データベースサーバなどを含むさまざまな追加サーバアプリケーションおよび／または中間層アプリケーションのいずれかを動かすことができる。例示的なデータベースサーバは、Oracle（登録商標）、Microsoft（登録商標）、Sybase（登録商標）、IBM（登録商標）などの会社から市販されているものを含むがこれらに限定されない。

いくつかの実現例において、サーバ６１２は、クライアントコンピューティング装置６０２、６０４，６０６および６０８のユーザから受信したデータフィードおよび／またはイベント更新を分析および統合する１つ以上のアプリケーションを含んでもよい。例示として、データフィードおよび／またはイベント更新は、Twitter（登録商標）フィード、Facebook（登録商標）更新または１つ以上の第３情報源および連続データストリームから受信したリアルタイム更新を含むがこれらに限定されない。リアルタイム更新は、センサデータアプリケーション、金融相場表示機、ネットワーク性能測定ツール（例えば、ネットワーク監視およびトラフィック管理アプリケーション）、ページ遷移（Clickstream）解析ツール、自動車交通監視装置などに関連するリアルタイムイベントを含むことができる。また、サーバ６１２は、クライアントコンピューティング装置６０２、６０４、６０６および６０８の１つ以上の表示装置を介して、データフィードおよび／またはリアルタイムイベントを表示するための１つ以上のアプリケーションを含むこともできる。

また、分散システム６００は、１つ以上のデータベース６１４および６１６を含むこともできる。データベース６１４および６１６は、さまざまな場所に常駐することができる。例示として、１つ以上のデータベース６１４および６１６は、サーバ６１２の近く（および／またはその中）の非一時記憶媒体に常駐することができる。代替的には、データベース６１４および６１６は、リモートサーバ６１２から離れており、ネットワークに基づく接続または専用接続を介して、サーバ６１２と通信している。一組の実施形態において、データベース６１４および６１６は、記憶領域ネットワーク（ＳＡＮ）に常駐することができる。同様に、サーバ６１２に寄与する機能を実行するための任意の必要なファイルは、必要に応じて、サーバ６１２上に／またはサーバ６１２から離れた場所に保存されてもよい。一組の実施形態において、データベース６１４および６１６は、例えば、Oracleにより提供されたデータベースなどの関係データベースを含むことができる。これらの関係データベースは、ＳＱＬフォーマット命令に応じて、データを取得、保存および更新するように構成されている。

図７を参照して、サービスをクラウドサービスとして提供することができるシステム環境の構成要素を示すブロック図が示される。図示の実施形態において、システム環境７００は、１つ以上のクライアントコンピューティング装置７０４、７０６および７０８を含む。ユーザは、クライアントコンピューティング装置を用いて、クラウドサービスを提供するクラウドインフラストラクチャシステム７０２と情報を交換することができる。クライアントコンピューティング装置は、ウェブブラウザ、専用クライアントアプリケーション（例えば、Oracleフォーム）または他のアプリケーションなどのクライアントアプリケーションを作動するように構成されることができる。ユーザは、クライアントアプリケーションを用いてクラウドインフラストラクチャシステム７０２と情報を交換することによって、クラウドインフラストラクチャシステム７０２により提供されたサービスを利用することができる。

理解すべきことは、図示のクラウドインフラストラクチャシステム７０２は、図示された構成要素以外の構成要素を備えてもよいことである。さらに、図示の実施形態は、本発明の実施形態を組み込むことができるクラウドインフラストラクチャシステムの一例に過ぎない。いくつかの他の実施形態において、クラウドインフラストラクチャシステム７０２は、図示よりも多いまたは少ない構成要素を有してもよく、２つ以上の構成要素を組み合わせてもよく、または異なる構成または配置の構成要素を有してもよい。

クライアントコンピューティング装置７０４、７０６および７０８は、上述したクライアントコンピューティング装置６０２、６０４、６０６および６０８と同様であってもよい。

例示的なシステム環境７００は、３つのクライアントコンピューティング装置を備えると示されているが、任意の数のクライアントコンピューティング装置をサポートすることができる。他の装置、例えば、センサを有する装置は、クラウドインフラストラクチャシステム７０２と情報を交換することができる。

ネットワーク７１０は、クライアント７０４、７０６および７０８とクラウドインフラストラクチャシステム７０２との間のデータの通信および交換を促進することができる。各ネットワークは、上記でネットワーク１３１０に関して説明したプロトコルをさまざまな市販プロトコルのいずれかを用いてデータ通信をサポートすることができ、当業者に熟知する任意種類のネットワークであってもよい。

クラウドインフラストラクチャシステム７０２は、上記でサーバ１３１２に関して説明した構成要素を含み得る１つ以上のコンピュータおよび／またはサーバを含むことができる。

特定の実施形態において、クラウドインフラストラクチャシステムによって提供されたサービスは、需要に応じて、クラウドインフラストラクチャシステムからユーザに提供できるオンラインデータの記憶およびバックアップ、ウェブベースの電子メールサービス、ホストされたオフィススイートおよび文章連携サービス、データベース処理、管理できる技術サポートサービスなどの多くのサービスを含んでよい。クラウドインフラストラクチャシステムによって提供されるサービスは、ユーザのニーズを満たすように動的に拡張できる。クラウドインフラストラクチャシステムによって提供されたサービスの特定の例示は、本明細書において、「サービスインスタンス」と呼ばれる。一般的には、インターネットなどの通信ネットワークを介して、クラウドサービスプロバイダのシステムからユーザに提供できる任意のサービスは、「クラウドサービス」と呼ばれる。典型的には、パブリッククラウド環境において、クラウドサービスプロバイダのシステムを構成するサーバおよびシステムは、顧客のオンプレミスサーバおよびシステムとは異なる。たとえば、クラウドサービスプロバイダのシステムは、アプリケーションをホストすることができ、ユーザは、必要に応じて、インターネットなどの通信ネットワークを介して、アプリケーションを注文し、使用することができる。

いくつかの例において、コンピュータネットワーククラウドインフラストラクチャ内のサービスは、保護されたコンピュータネットワークのストレージアクセス、ホストされたデータベース、ホストされたウェブサーバ、ソフトウェアアプリケーション、またはクラウドベンダによってユーザに提供された他のサービス、または当該技術分野に知られている他のサービスを含むことができる。たとえば、サービスは、インターネットを介して、クラウド上のリモートストレージに対して、パスワードにより保護されたアクセスを含むことができる。別の例として、サービスは、ウェブサービスにホストされている関係データベースおよびネットワーク上の開発者により私的使用のためのスクリプト言語ミドルウェアエンジンを含むことができる。別の例として、サービスは、クラウドベンダのウェブサイト上でホストされている電子メールソフトウェアアプリケーションに対するアクセスを含むことができる。

特定の実施形態において、クラウドインフラストラクチャシステム７０２は、セルフサービスのサブスクリプションに基づく、柔軟なスケーラビリティ、信頼性、高可用性および安全性を有する方法で、顧客に提供できる一連のアプリケーション、ミドルウェアおよびデータベースサービスを含むことができる。このようなクラウドインフラストラクチャシステムの例示として、本願譲受人により提供されたOracleパブリッククラウドが挙げられる。

さまざまな実施形態において、クラウドインフラストラクチャシステム７０２は、顧客から申込んだクラウドインフラストラクチャシステム７０２のサービスを自動的に提供、管理および追跡するように構成されることができる。クラウドインフラストラクチャシステム７０２は、さまざまな展開モデルを介して、クラウドサービスを提供することができる。たとえば、サービスは、クラウドサービスを販売する組織に所有された（たとえば、Oracleに所有された）クラウドインフラストラクチャシステム７０２を有するパブリッククラウドモデルで提供され、一般人または異なる業界の企業に利用されることができる。別の例として、サービスは、単一の組織に専用されたクラウドインフラストラクチャシステム７０２を有するプライベートクラウドモデルで提供され、組織内の１つ以上の実体に利用されることができる。また、クラウドサービスは、集団クラウドモデルで提供されてもよい。よって、クラウドインフラストラクチャシステム７０２およびクラウドインフラストラクチャシステム７０２により提供されたサービスは、関連する集団内の複数の組織によって共有される。また、クラウドサービスは、２つ以上の異なるモデルの組み合わせからなるハイブリッドクラウドモデルで提供されてもよい。

いくつかの実施形態において、クラウドインフラストラクチャシステム７０２によって提供されたサービスは、SaaS（Software as a Service）カテゴリ、PaaS（Platform as a Service）カテゴリ、IaaS（Infrastructure as a Service）カテゴリ、またはハイブリッドサービスを含む他のカテゴリのサービスに準拠して提供された１つ以上のサービスを含むことができる。顧客は、サブスクリプションの申込みによって、クラウドインフラストラクチャシステム７０２によって提供された１つ以上のサービスを注文することができる。これに応じて、クラウドインフラストラクチャシステム７０２は、顧客のサブスクリプション申込書に含まれたサービスを提供する処理を行う。

いくつかの実施形態において、クラウドインフラストラクチャシステム７０２によって提供されたサービスは、アプリケーションサービス、プラットフォームサービスおよびインフラストラクチャサービスを含むがこれらに限定されない。いくつかの例において、アプリケーションサービスは、SaaSプラットフォームを介して、クラウドインフラストラクチャシステムによって提供されてもよい。SaaSプラットフォームは、SaaSカテゴリに準拠するクラウドサービスを提供するように構成されてもよい。たとえば、SaaSプラットフォームは、統合の開発および展開プラットフォーム上でオンデマンドアプリケーションのスイートを構築し、提供するように、機能することができる。SaaSプラットフォームは、SaaSサービスを提供するために、基礎のソフトウェアおよびインフラストラクチャを管理し、制御することができる。SaaSプラットフォームにより提供されたサービスを利用することによって、顧客は、クラウドインフラストラクチャシステム上で動作するアプリケーションを利用することができる。顧客は、別々のライセンスおよびサポートを購入する必要なく、アプリケーションサービスを取得することができる。さまざまな異なるSaaSサービスを提供することができる。例示としては、販売実績管理、企業統合、および大規模組織のビジネス柔軟性に対する解決策を提供するサービスを含むがこれらに限定されない。

いくつかの実施形態において、プラットフォームサービスは、PaaSプラットフォームを介してクラウドインフラストラクチャシステムによって提供されてもよい。PaaSプラットフォームは、PaaSカテゴリに準拠するクラウドサービスを提供するように構成されてもよい。プラットフォームサービスの例としては、共有されている共通アーキテクチャ上で既存のアプリケーションを統合する能力、およびプラットフォームにより提供された共有サービスを活用する新規アプリケーションを構築する能力を組織（たとえば、Oracle）に与えるサービスを含むがこれに限定されない。PaaSプラットフォームは、PaaSサービスを提供するために、基礎のソフトウェアおよびインフラストラクチャを管理し、制御することができる。顧客は、クラウドインフラストラクチャシステム上で動作するアプリケーションを利用することができる。顧客は、別々のライセンスおよびサポートを購入する必要なく、アプリケーションサービスを取得することができる。さまざまな異なるSaaSサービスを提供することができる。プラットフォームサービスの例としては、Oracle Javaクラウドサービス（ＪＣＳ）、Oracleデータベースクラウドサービス（ＤＢＣＳ）およびその他を含むがこれらに限定されない。

PaaSプラットフォームにより提供されたサービスを利用することによって、顧客は、クラウドインフラストラクチャシステムにサポートされているプログラミング言語およびツールを利用することができ、展開されたサービスを制御することができる。いくつかの実施形態において、クラウドインフラストラクチャシステムによって提供されるプラットフォームサービスは、データベースクラウドサービス、ミドルウェアクラウドサービス（たとえば、Oracle Fusionミドルウェアサービス）、およびJavaクラウドサービスを含むことができる。一実施形態において、データベースクラウドサービスは、データベースリソースを蓄積する能力を組織に与えることができる共有サービス展開モデルをサポートすることができ、DBaaS（Database as a Service）をクラウドデータベースとして顧客に提供することができる。ミドルウェアクラウドサービスは、クラウドインフラストラクチャシステム上でさまざまなビジネスアプリケーションを開発および展開するためのプラットフォームを顧客に提供することができ、Javaクラウドサービスは、クラウドインフラストラクチャシステム上でJavaアプリケーションを展開するためのプラットフォームを顧客に提供することができる。

種々の異なるインフラストラクチャサービスは、IaaSプラットフォームによって、クラウドインフラストラクチャシステムに提供されてもよい。これらのインフラストラクチャサービスは、SaaSプラットフォームおよびPaaSプラットフォームにより提供されたサービスを利用する顧客のために、ストレージ、ネットワークおよびその他の基本的なコンピューティングリソースとしての基礎コンピューティングリソースの管理と制御を容易にする。

特定の実施形態において、クラウドインフラストラクチャシステム７０２はまた、クラウドインフラストラクチャシステムを利用する顧客に、さまざまなサービスを提供するために使用されるリソースを提供するためのインフラストラクチャリソース７３０を含むことができる。一実施形態において、インフラストラクチャリソース７３０は、PaaSプラットフォームおよびSaaSプラットフォームによって提供されたサービスを実行するために、事前に統合され且つ最適化されたサーバリソース、ストレージリソースおよびネットワークリソースなどのハードウェアの組み合わせを含んでもよい。

いくつかの実施形態において、クラウドインフラストラクチャシステム７０２内のリソースは、複数のユーザに共有されることができ、各々の需要に応じて動的に再割当てることができる。また、リソースは、異なるタイムゾーンでユーザに割当てることができる。たとえば、クラウドインフラストラクチャシステム７３０は、指定時間内でクラウドインフラストラクチャシステムのリソースを第一時間帯における第一グループのユーザに利用させ、その後、同様のリソースを異なる時間帯における別のグループのユーザに再配分することができ、リソースを最大に利用する。

特定の実施形態において、複数の内部共有サービス７３２は、提供され、クラウドインフラストラクチャシステム７０２の異なる構成要素またはモジュールに共有されおよびクラウドインフラストラクチャシステム７０２によって提供されたサービスに共有されることができる。これらの内部共有サービスは、安全性および識別サービス、統合サービス、企業リポジトリサービス、企業管理サービス、ウイルススキャンおよびホワイトリストサービス、高可用性のバックアップおよびリカバリサービス、クラウドサポートを可能にするサービス、メールサービス、通知サービス、およびファイル転送サービスなどを含むがこれらに限定されない。

特定の実施形態において、クラウドインフラストラクチャシステム７０２は、クラウドインフラストラクチャシステム内のクラウドサービス（たとえば、SaaSサービス、PaaSサービスおよびIaaSサービス）を包括的に管理する機能を提供することができる。一実施形態において、クラウド管理機能は、クラウドインフラストラクチャシステム７０２などによって受信した顧客のサブスクリプションを提供、管理、および追跡する機能を含んでもよい。

一実施形態において、図示のように、クラウド管理機能は、１つ以上のモジュール、たとえば、オーダー管理モジュール７２０、オーダーオーケストレーションモジュール７２２、オーダー支給モジュール７２４、オーダー管理および監視モジュール７２６、およびＩＤ管理モジュール７２８によって提供される。これらのモジュールは、１つ以上のコンピュータおよび／またはサーバを含んでもよく、これらを用いて形成されてもよい。これらのコンピュータおよび／またはサーバは、汎用コンピュータ、専用サーバコンピュータ、サーバファーム、サーバクラスタ、または任意の他の適切な配置および／またはこれらの組み合わせであってもよい。

例示的な操作７３４において、顧客は、クライアント装置、たとえば、クライアント装置７０４、７０６または７０８を使用して、クラウドインフラストラクチャシステム７０２により提供された１つ以上のサービスをリクエストし、クラウドインフラストラクチャシステム７０２によって提供された１つ以上のサービスをオーダーすることによって、クラウドインフラストラクチャシステム７０２と情報を交換することができる。特定の実施形態において、顧客は、クラウドユーザインターフェイス（ＵＩ）、クラウドＵＩ７１２、クラウドＵＩ７１４および／またはクラウドＵＩ７１６にアクセスし、これらのＵＩを介して、サブスクリプションをオーダーすることができる。クラウドインフラストラクチャシステム７０２が顧客のオーダーに応答して受信したオーダー情報は、顧客と、クラウドインフラストラクチャシステム７０２により提供され、顧客が購読しようとする１つ以上のサービスとを識別する情報を含むことができる。

顧客がオーダーした後、オーダー情報は、クラウドＵＩ７１２、７１４および／または７１６を介して受信される。

操作７３６において、オーダーは、オーダーデータベース７１８に保存される。オーダーデータベース７１８は、クラウドインフラストラクチャシステム７１８によって操作され、または他のシステム要素と連動して操作されるいくつかのデータベースのうち１つであってもよい。

操作７３８において、オーダー情報は、オーダー管理モジュール７２０に転送される。いくつかの例において、オーダー管理モジュール７２０は、オーダーに関連する請求および会計機能、たとえば、オーダーの確認、および確認後オーダーの記入を実行するように構成されてもよい。

操作７４０において、オーダーに関する情報は、オーダーオーケストレーションモジュール７２２に伝達される。オーダーオーケストレーションモジュール７２２は、オーダー情報を利用して、顧客がオーダーしたサービスおよびリソースの提供を用意する。いくつかの例において、オーダーオーケストレーションモジュール７２２は、オーダー支給モジュール７２４のサービスを用いて、オーダーしたサービスをサポートするように、リソースの提供を用意することができる。

特定の実施形態において、オーダーオーケストレーションモジュール７２２は、各オーダーに関連したビジネスプロセスを管理することができ、ビジネスロジックを適用することによって、オーダーに対して支給をするか否かを判断することができる。操作７４２において、新規サブスクリプションのオーダーを受信すると、オーダーオーケストレーションモジュール７２２は、リソースを割当て、サブスクリプションオーダーを満たすために必要なリソースを構成するように、リクエストをオーダー支給モジュール７２４に送信する。オーダー支給モジュール７２４は、顧客がオーダーしたサービス用のリソースを割当てることができる。オーダー支給モジュール７２４は、クラウドインフラストラクチャシステム７００により提供されたクラウドサービスと、リクエストされたサービスを提供するためのリソースを供給するために使用される物理的な実装層との間の抽象化レベルを形成する。このように、オーダーオーケストレーションモジュール７２２は、たとえば、サービスおよびリソースをその場で支給するかまたは事前に支給するか、リクエストに応じて割当てる／与えるかなどの実装詳細から単離することができる。

操作７４４において、サービスおよびリソースを支給した後、クラウドインフラストラクチャシステム７０２のオーダー支給モジュール７２４は、提供されるサービスの通知をクライアント装置７０４、７０６および／または７０８の顧客に送信することができる。

操作７４６において、オーダー管理および監視モジュール７２６は、顧客のサブスクリプションオーダーを管理および追跡することができる。いくつかの例において、オーダー管理および監視モジュール７２６は、サブスクリプションオーダー内のサービスの利用統計、たとえば、ストレージの使用量、データの転送量、ユーザの数、システムの起動時間およびシステムの停止時間を収集するように構成されることができる。

特定の実施形態において、クラウドインフラストラクチャシステム７００は、ＩＤ管理モジュール７２８を含むことができる。ＩＤ管理モジュール７２８は、クラウドインフラストラクチャシステム７００に、識別サービス、たとえば、アクセス管理および認可サービスを提供するように構成することができる。いくつかの実施形態において、ＩＤ管理モジュール７２８は、クラウドインフラストラクチャシステム７０２によって提供されたサービスを利用したい顧客に関する情報を制御することができる。このような情報は、顧客のＩＤを承認する情報、およびさまざまなシステムリソース（たとえば、ファイル、ディレクトリ、アプリケーション、通信ポート、メモリセグメントなど）に対して許可された顧客の実行権限を記載する情報を含むことができる。ＩＤ管理モジュール７２８は、各顧客に関する記述情報、記述情報にアクセスおよび変更する方法、および記述情報にアクセスおよび変更した顧客に対する管理を含むことができる。

図８を参照して、本発明の実施形態を実施することができる例示的なコンピュータシステムを示すブロック図が示される。コンピュータシステム８００を用いて、上述したコンピュータシステムのいずれかを実現することができる。図示のように、コンピュータシステム８００は、バスサブシステム８０２を介して、複数の周辺サブシステムと連通する処理ユニット８０４を含む。周辺サブシステムは、処理加速ユニット８０６と、Ｉ／Ｏサブシステム８０８と、記憶サブシステム８１８と、通信サブシステム８２４とを含むことができる。記憶サブシステム８１８は、有形コンピュータ可読記憶媒体８２２と、システムメモリ８１０とを含む。

バスサブシステム８０２は、コンピュータシステム８００のさまざまな構成要素およびサブシステムが必要に応じて相互通信させるための機構を形成する。バスサブシステム８０２を単一のバスとして概略的に示しているが、代替的な実施形態において、バスサブシステムは、複数のバスを利用してもよい。バスサブシステム８０２は、メモリバスまたはメモリコントローラ、周辺バス、およびさまざまなバスアーキテクチャのいずれかを使用するローカルバスを備えるいくつかの種類のバス構造のいずれかを有してもよい。たとえば、このようなアーキテクチャは、業界標準アーキテクチャ（ＩＳＡ）バス、マイクロチャネルアーキテクチャ（ＭＣＡ）バス、拡張ＩＳＡ（ＥＩＳＡ）バス、ビデオエレクトロニクス規格協会（ＶＥＳＡ）ローカルバス、および周辺構成要素相互接続（ＰＣＩ）バスを含むことができる。これらのバスは、IEEE P1386.1規格に準拠した製造されたメザニンバスとして実装することができる。

１つ以上の集積回路（たとえば、従来のマイクロプロセッサまたはマイクロコントローラ）として実装することができる処理ユニット８０４は、コンピュータシステム８００の操作を制御する。処理ユニット８０４は、１つ以上のプロセッサを含むことができる。これらのプロセッサは、シングルコアプロセッサであってもよく、マルチコアプロセッサであってもよい。特定の実施形態において、処理ユニット８０４は、各々シングルコアプロセッサまたはマルチコアプロセッサを備える１つ以上の独立した処理ユニット８３２および／または８３４として実装されてもよい。他の実施形態において、処理ユニット８０４は、２つのデュアルコア（dual-core）プロセッサを単一のチップに集積することにより形成されたクアッドコア（Quad-core）処理ユニットとして実装されてもよい。

さまざまな実施形態において、処理ユニット８０４は、プログラムコードに応じてさまざまなプログラムを実行することができ、複数のプログラムまたはプロセスを同時に実行することができる。任意の時点で、実行されるプログラムコードの一部または全てをプロセッサ８０４および／または記憶サブシステム８１８に常駐することができる。適切なプログラミングによって、プロセッサ８０４は、上述したさまざまな機能を提供することができる。コンピュータシステム８００は、デジタルシグナルプロセッサ（DSP）および専用プロセッサなどを含むことができる処理加速ユニット８０６をさらに備えてもよい。

Ｉ／Ｏサブシステム８０８は、ユーザインターフェイス入力装置と、ユーザインターフェイス出力装置とを含むことができる。ユーザインターフェイス入力装置は、キーボード、マウスまたはトラックボールなどのポインティング装置、ディスプレイに組み込まれたタッチパッドまたはタッチスクリーン、スクロールホイール、クリックホイール、ダイヤル、ボタン、スイッチ、キーパッド、音声命令認識システムを備える音声入力装置、マイクロフォン、および他の種類の入力装置を含んでもよい。また、ユーザインターフェイス入力装置は、たとえば、Microsoft Kinect（登録商標）モーションセンサのようなモーション検知および／またはジェスチャ認識装置を含んでもよい。Microsoft Kinect（登録商標）モーションセンサは、ジェスチャおよび音声命令を利用する自然ユーザインターフェース（ＮＵＩ）を介して、Microsoft Xbox（登録商標）３６０ゲームコントローラなどの入力装置を制御することができ、それと対話することができる。また、ユーザインターフェイス入力装置は、Google Glass（登録商標）瞬き検出器のような眼球ジェスチャ認識装置を含むことができる。Google Glass（登録商標）瞬き検出器は、ユーザの眼球活動（たとえば、写真を撮るときおよび／またはメニューを選択するときの「瞬き」）を検出し、眼球活動を入力装置（たとえば、Google Glass（登録商標））に入力する入力に変換する。さらに、ユーザインターフェイス入力装置は、音声命令を介してユーザと音声認識システム（たとえば、Siri（登録商標）ナビゲータ）との対話を可能にする音声認識検出装置を含んでもよい。

また、ユーザインターフェイス入力装置は、三次元（３Ｄ）マウス、ジョイスティックまたはポインティングスティック、ゲームパッド、グラフィックタブレット、スピーカなどのオーディオ／ビジュアル装置、デジタルカメラ、デジタルビデオカメラ、ポータブルメディアプレーヤ、ウェブカメラ、イメージスキャナ、指紋スキャナ、バーコードリーダ、３Ｄスキャナ、３Ｄプリンタ、レーザ距離計、および視線追跡装置を含むがこれらに限定されない。さらに、ユーザインターフェイス入力装置は、たとえば、コンピュータ断層撮影装置、磁気共鳴像装置、超音波放射断層撮影装置、および医療用超音波装置などのような医用画像入力装置を含んでもよい。また、ユーザインターフェイス入力装置は、たとえば、ＭＩＤＩキーボードおよび電子楽器などの音声入力装置を含んでもよい。

ユーザインターフェイス出力装置は、ディスプレイサブシステム、インジケータライト、またはオーディオ出力装置などの非視覚ディスプレイを含んでもよい。ディスプレイサブシステムは、たとえば、陰極線管（ＣＲＴ）、液晶ディスプレイ（ＬＣＤ）またはプラズマディスプレイを使用するフラットパネル装置、投射装置またはタッチスクリーンであってもよい。一般に、「出力装置」という用語を使用する場合、コンピュータシステム８００から情報をユーザまたは他のコンピュータに出力するためのすべての可能な種類の装置および機構を含むことを意図している。たとえば、ユーザインターフェイス出力装置は、文字、画像およびオーディオ／ビデオ情報を視覚的に伝達するさまざまな表示装置、たとえば、モニタ、プリンタ、スピーカ、ヘッドフォン、カーナビゲーションシステム、プロッタ、音声出力装置、およびモデムを含むがこれらに限定されない。

コンピュータシステム８００は、記憶サブシステム８１８を含むことができる。記憶サブシステム８１８は、ソフトウェア要素を備え、図示では、これらのソフトウェア要素は、システムメモリ１５１０内に配置されている。システムメモリ８１０は、処理ユニット８０４にロード可能且つ実行可能なプログラム命令、およびこれらのプログラムの実行により生成されたデータを記憶することができる。

コンピュータシステム８００の構成および種類に応じて、システムメモリ８１０は、揮発性メモリ（たとえば、ランダムアクセスメモリ（random access memory：ＲＡＭ））であってもよく、および／または、不揮発性メモリ（たとえば、読取り専用メモリ（read-only memory：ＲＯＭ）、フラッシュメモリ）であってもよい。一般に、ＲＡＭは、処理ユニット８０４がすぐにアクセス可能なデータおよび／またはプログラムモジュール、および／または、処理ユニット８０４によって現在操作および実行されているデータおよび／またはプログラムモジュールを収容する。いくつかの実現例では、システムメモリ８１０は、スタティックランダムアクセスメモリ（static random access memory：ＳＲＡＭ）またはダイナミックランダムアクセスメモリ（dynamic random access memory：ＤＲＡＭ）などの複数の異なる種類のメモリを含み得る。いくつかの実現例では、始動中などにコンピュータシステム８００内の要素間で情報を転送することを助ける基本ルーチンを含む基本入力／出力システム（basic input/output system：ＢＩＯＳ）が、一般にROMに格納され得る。一例としておよび非限定的に、システムメモリ８１０は、クライアントアプリケーション、ウェブブラウザ、中間層アプリケーション、関係データベース管理システム（relational database management system：ＲＤＢＭＳ）などを含み得るアプリケーションプログラム８１２、プログラムデータ８１４およびオペレーティングシステム８１６も示す。一例として、オペレーティングシステム８１６は、マイクロソフトウィンドウズ（登録商標）、Apple Macintosh（登録商標）および／もしくはＬｉｎｕｘ（登録商標）オペレーティングシステムのさまざまなバージョン、さまざまな市販のＵＮＩＸ（登録商標）もしくはＵＮＩＸライクオペレーティングシステム（さまざまなGNU／Ｌｉｎｕｘオペレーティングシステム、Google Chrome（登録商標）OSなどを含むが、これらに限定されるものではない）、ならびに／または、ｉＯＳ、Windows（登録商標）Phone、Android（登録商標）OS、BlackBerry（登録商標）10 OSおよびパーム（登録商標）OSオペレーティングシステムなどのモバイルオペレーティングシステムを含み得る。

また、記憶サブシステム８１８は、いくつかの実施例の機能を提供する基本的なプログラミングおよびデータ構造を格納するための有形のコンピュータ可読記憶媒体を提供し得る。プロセッサによって実行されたときに上記の機能を提供するソフトウェア（プログラム、コードモジュール、命令）が記憶サブシステム８１８に格納され得る。これらのソフトウェアモジュールまたは命令は、処理ユニット８０４によって実行され得る。また、記憶サブシステム８１８は、本発明に従って使用されるデータを格納するためのリポジトリを提供し得る。

また、記憶サブシステム８１０は、コンピュータ可読記憶媒体８２２にさらに接続可能なコンピュータ可読記憶媒体リーダ８２０を含み得る。コンピュータ可読記憶媒体８２２は、システムメモリ８１０と共に、または必要に応じてシステムメモリ８１０と組み合わせて、コンピュータ可読情報を一時的および／または永久に収容、格納、送信および検索するための記憶媒体に加えて、リモート記憶装置、ローカル記憶装置、固定的な記憶装置および／または取外し可能な記憶装置を包括的に表すことができる。

また、コードまたはコードの一部を含むコンピュータ可読記憶媒体８２２は、当該技術分野において公知のまたは使用される任意の適切な媒体を含み得て、当該媒体は、情報の格納および／または送信のための任意の方法または技術において実現される揮発性および不揮発性の、取外し可能および取外し不可能な媒体などであるが、これらに限定されるものではない記憶媒体および通信媒体を含む。これは、ＲＡＭ、ＲＯＭ、電子的消去書き込み可能なＲＯＭ（electronically erasable programmable ROM：ＥＥＰＲＯＭ）、フラッシュメモリもしくは他のメモリ技術、ＣＤ－ＲＯＭ、デジタル多用途ディスク（digital versatile disk：ＤＶＤ）、または他の光学式記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置もしくは他の磁気記憶装置、または他の有形のコンピュータ可読媒体などの非一時的な有形のコンピュータ可読記憶媒体を含み得る。また、これは、データ信号、データ送信などの無形のコンピュータ可読媒体、または、所望の情報を送信するために使用可能であり且つコンピュータシステム８００によってアクセス可能なその他の媒体を含み得る。

一例として、コンピュータ可読記憶媒体８２２は、取外し不可能な不揮発性磁気媒体から読取るまたは当該媒体に書込むハードディスクドライブ、取外し可能な不揮発性磁気ディスクから読取るまたは当該ディスクに書込む磁気ディスクドライブ、ならびに、ＣＤ ＲＯＭ、ＤＶＤおよびブルーレイ（登録商標）ディスクまたは他の光学式媒体などの取外し可能な不揮発性光学ディスクから読取るまたは当該ディスクに書込む光学式ディスクドライブを含み得る。コンピュータ可読記憶媒体８２２は、ジップ（登録商標）ドライブ、フラッシュメモリカード、ユニバーサルシリアルバス（universal serial bus：ＵＳＢ）フラッシュドライブ、セキュアデジタル（secure digital：ＳＤ）カード、ＤＶＤディスク、デジタルビデオテープなどを含み得るが、これらに限定されるものではない。また、コンピュータ可読記憶媒体８２２は、フラッシュメモリベースのＳＳＤ、企業向けフラッシュドライブ、ソリッドステートＲＯＭなどの不揮発性メモリに基づくソリッドステートドライブ（solid-state drive：ＳＳＤ）、ソリッドステートＲＡＭ、ダイナミックＲＡＭ、スタティックＲＡＭなどの揮発性メモリに基づくＳＳＤ、ＤＲＡＭベースのＳＳＤ、磁気抵抗ＲＡＭ（magnetoresistive RAM：ＭＲＡＭ）ＳＳＤ、およびＤＲＡＭとフラッシュメモリベースのＳＳＤとの組み合わせを使用するハイブリッドＳＳＤを含み得る。ディスクドライブおよびそれらの関連のコンピュータ可読媒体は、コンピュータ可読命令、データ構造、プログラムモジュールおよび他のデータの不揮発性記憶装置をコンピュータシステム８００に提供し得る。

通信サブシステム８２４は、他のコンピュータシステムおよびネットワークとのインターフェイスを提供する。通信サブシステム８２４は、他のシステムからデータを受信したり、コンピュータシステム８００から他のシステムにデータを送信するためのインターフェイスの役割を果たす。たとえば、通信サブシステム８２４は、コンピュータシステム８００がインターネットを介して１つ以上の装置に接続することを可能にし得る。いくつかの実施例では、通信サブシステム８２４は、（たとえば３Ｇ、４ＧまたはＥＤＧＥ（enhanced data rates for global evolution）などの携帯電話技術、高度データネットワーク技術を用いて）無線音声および／またはデータネットワークにアクセスするための無線周波数（radio frequency：ＲＦ）トランシーバ構成要素、ＷｉＦｉ（ＩＥＥＥ１６０２．１１ファミリ標準または他のモバイル通信技術またはそれらの任意の組み合わせ）、全地球測位システム（global positioning system：ＧＰＳ）レシーバ構成要素、および／または、他の構成要素を含み得る。いくつかの実施例では、通信サブシステム８２４は、無線インターフェイスに加えて、または無線インターフェイスの代わりに、有線ネットワーク接続（たとえばイーサネット）を提供し得る。

また、いくつかの実施例において、通信サブシステム８２４は、コンピュータシステム８００を使用し得る１人以上のユーザを代表して、構造化されたおよび／または構造化されていないデータフィード８２６、イベントストリーム８２８、イベント更新８３０などの形態で入力通信を受信し得る。

一例として、通信サブシステム８２４は、ツイッター（登録商標）フィード、フェースブック（登録商標）更新、リッチ・サイト・サマリ（Rich Site Summary：ＲＳＳ）フィードなどのウェブフィードなどのデータフィード８２６をリアルタイムでソーシャルネットワークおよび／または他の通信サービスのユーザから受信し、および／または、１つ以上の第三者情報源からリアルタイム更新を受信するように構成され得る。

また、通信サブシステム８２４は、連続的なデータストリームの形態でデータを受信するように構成され得て、当該データは、連続的である場合もあれば本質的に明確な端部を持たない状態で境界がない場合もあるリアルタイムイベントのイベントストリーム８２８および／またはイベント更新８３０を含み得る。連続的なデータを生成するアプリケーションの例としては、たとえばセンサデータアプリケーション、金融ティッカ、ネットワーク性能測定ツール（たとえばネットワークモニタリングおよびトラフィック管理アプリケーション）、クリックストリーム分析ツール、自動車交通モニタリングなどを含み得る。

また、通信サブシステム８２４は、構造化されたおよび／または構造化されていないデータフィード８２６、イベントストリーム８２８、イベント更新８３０などを、コンピュータシステム８００に結合された１つ以上のストリーミングデータソースコンピュータと通信し得る１つ以上のデータベースに出力するように構成され得る。

コンピュータシステム８００は、手持ち式携帯機器（たとえばiPhone（登録商標）携帯電話、Ｉｐａｄ（登録商標）計算タブレット、ＰＤＡ）、ウェアラブル装置（たとえばGoogle Glass（登録商標）ヘッドマウントディスプレイ）、ＰＣ、ワークステーション、メインフレーム、キオスク、サーバラックまたはその他のデータ処理システムを含むさまざまな種類のうち、１つであってもよい。

コンピュータおよびネットワークが絶え間なく進化し続けるため、図示されているコンピュータシステム８００の説明は、特定の例として意図されているにすぎない。図に示されているシステムよりも多くのまたは少ない数の構成要素を有する多くの他の構成が可能である。例えば、ハードウェア、ファームウェア、（アプレットを含む）ソフトウェア、または組み合わせにおいて、カスタマイズされたハードウェアも使用されてもよく、および／または、特定の要素が実装されてもよい。さらに、ネットワーク入力／出力装置などの他の計算装置への接続が利用されてもよい。本明細書で提供される開示および教示に基づいて、当業者は、さまざまな実施例を実現するための他の手段および／または方法を理解するであろう。

上記の説明において、例示の目的のために、特定の順序で方法を記載した。代替の実施形態において、記載された順序と異なる順序で方法を実行してもよい。また、上述した方法は、ハードウェア構成要素によって実行されてもよく、または一連の機械実行可能な命令で具体化されてもよい。機械実行可能な命令を用いて、汎用または専用プロセッサもしくは命令でプログラムされたロジック回路に指示して、方法を実行することができる。これらの機械実行可能な命令は、１つ以上の機械可読媒体またはメモリ素子、例えば、ＣＤ－ＲＯＭまたは他の種類の光ディスク、フロッピー（登録商標）ディスク、ＲＯＭ、ＲＡＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、磁気または光カード、フラッシュメモリ、または電子命令の記憶に適した他の種類の機械可読媒体またはメモリ素子を含む。代替的に、これらの方法は、ハードウェアおよびソフトウェアの組み合わせによって実行されてもよい。

本明細書において本発明の例示的且つ現在好適な実施形態を詳細に説明してきたが、理解すべきことは、本発明の概念は、様々な形で具体化され使用されてもよく、添付の特許請求の範囲は、先行技術によって制限されるものを除き、これらの変形例を含むことを意図していることである。

例示的な実施形態
図９を参照して、図９は、相乗的な一貫性且つ体系化である方法で、データ、知識およびプロセスを管理するための知識集約型データベースシステム（Knowledge-Intensive Database System：ＫＩＤＳ）モデルの例を示している。以下で説明するように、このモデルは、定量ファクトを捕捉し、ファクトを分類することによってコンパクトな定性情報を導出し、導出した情報を評価することによって１つ以上の仮説を確立し、およびこれらの仮説を使用することによって指令を策定する（または禁止指令を決定する）。得られた指令を実施することによって、新しいファクトを作成することができる。以下同様。

知識の観点から図９のＫＩＤＳモデルを見ると、ＣＡＲＥループ（分類（Classification）、評価（Assessment）、解決（Resolution）および実施（Enactment））は、４つの異なるカテゴリの知識からなる。これらの４つの異なるカテゴリの知識は、特定カテゴリのデータに作用し、特定カテゴリのデータを生成する。ＣＡＲＥループは、正規化ワークフローを表す。データの観点から同様のモデルを見ると、ＦＰＨＤループ（ファクト（Fact）、認知結果（Perception）、仮説（Hypothesis）および指令（Directive））は、４つのタイプのデータを表す。データは、区別することなく、最新のデータベースシステムに保存されているものを記述する。形式知識は、知識を最も使用する時間および相互作用を区別することなく、記事、書籍、アプリケーションコード、ワークフロー、事件管理システムまたは判定支援システムに保存される。この欠点を補うために、ＣＡＲＥ／ＦＰＨＤループは、アプリケーションに非常に必要とされるデータ、知識、プロセス間の相互作用構造を形成する。

この実施形態において、ＫＩＤＳは、ＫＩＤＳモデル自体、ＫＩＤＳツールおよびＫＩＤＳインフラストラクチャを含むことができる。このＫＩＤＳインフラストラクチャは、４つのカテゴリのデータ、４つのカテゴリの知識、および正規化処理構造に基づいた知識およびデータの起動を管理するように設計される。現実世界で見られるように、ＫＩＤＳモデルは、データ、知識およびプロセスを相互に結び付けることができる。ＫＩＤＳモデルは、知識およびプロセスが互いに且つデータから離れて別々の世界に存在する現在モデルと異なる。ＫＩＤＳツールを使用することによって、ユーザは、ＫＩＤＳモデルに基づいて、アプリケーションを開発することができる。これらのツールは、様々な構成要素で利用可能な既存のツールを活用し、ＫＩＤＳモデルに準拠するためにサポート（制約）を追加する。ＫＩＤＳインフラストラクチャは、ルール、記憶クエリ、モデル、データ変換手順および知識の使用を制御するワークフローの形で、アプリケーションの実行、データおよび知識を管理するための既存技術、特に最新のデータベースおよびアプリケーションサーバを活用する。

ＫＩＤＳは、データの管理時に、進化する２つのビッグデータ技術およびＣＥＰ技術を結び付けることができる。（アドホック／バッチ環境では）ビッグデータ技術または（リアルタイム環境では）ＣＥＰ技術を用いて、ＣＡＲＥループの分類を実装することができるが、ＫＩＤＳは、これらのデータおよび知識表現を分類し、これらの技術を最新のアプリケーション構造に組み込むことによって、ビッグデータ技術およびＣＥＰ技術のうちのいずれよりも進歩している。すなわち、ビッグデータおよびＣＥＰは、ＦＳＤ（フレキシブルスキーマデータ）、多時間データベース、出所、ＩＬＭ（Information Life Cycle Management：情報ライフサイクル管理）、登録クエリおよびＯＬＡＰデータキューブなどを含むＫＩＤＳの重要な技術の中で２つの重要な基本要素である。

様々な実施形態において、ＫＩＤＳは、以下のもの、すなわち、
・データ、知識、プロセスをより良く管理するように、アプリケーションを構造化するためのモデル、
・各対が相互作用構造に特定の目的を果たす４対の相補的カテゴリを導入することによって、データ、知識および相互作用の正規化、
・ビッグデータおよびＣＥＰの包括的な環境、
・全ての構成要素の宣言仕様、
・状態追跡、時間変遷、および出所機能、
・インフラストラクチャの改良、ユーザ規格の進化およびデータからの知識発見を介して、アプリケーションを継続的に進化させるためのモデルを提供する。

使用事例－クラウド運用
クラウド運用にとって、ＳＬＡ（Service Level Agreement）の準拠が重要な要件であり得る。ＳＬＡ違反を回避する操作を可能にするまたは違反が発生した場合に問題の解決案をより迅速に提供するように、ＳＬＡの準拠は、重要な性能基準の連続監視および切迫してくるＳＬＡ違反を検出する予測診断機能を必要とする。典型的なクラウド運用は、理者側および／または顧客側のプライベートクラウド、パブリッククラウドおよびハイブリッドクラウドに位置するデータセンタ、ネットワーク、サーバマシン、仮想マシン、オペレーティングシステム、データベース、ミドルウェアおよびアプリケーションなどの数百万個のハードウェア要素およびソフトウェア要素を監視、診断および管理する必要がある。従来のＩＴ運用のの反応性異常検出および手動診断技術は、大変な労働集約的ものであり、広範囲分野の専門知識を必要とし、応答が非常に遅いため、異常を生じた構成要素を分離および特定するではなく、システム内の大量の部品の再起動を含む不適切な応答を引き起こし、クラウドに適切に拡張できないことがある。クラウド運用は、周期サイクル、負荷傾向、負荷急増、システム応答特性および一時的グリッチのダイナミクス、劣化および老化の早期警告、および環境内の数百万個の構成要素の性能変遷を得るために、図９に示すＣＡＲＥ／ＦＰＨＤループのようなＫＩＤＳループの快速な反復によって成長できる分野である。このようなシステムは、コンピュータ化ＫＩＤＳループを介して、重要な生命徴候の連続測定、時系列分析、多変量システム状態モデル、システム応答モデル、予知異常検出、機械学習に基づく分類、自動診断および予後、判定支援、および制御能力を必要とする。

クラウドコンピューティングの基本的な前提は、物理リソースの統合およびプール化による規模効果、および、動的リソース管理によって実質的に無制限のリソースを提供することである。制御システムは、動的リソース管理のほかに、動的実体モデルを管理することによって、新しいソフトウェアの頻繁なリリース、バグを修正するためのパッチ、ハードウェアのアップグレード、容量の拡張によって変化するシステムの正確な認識を提供する必要がある。

この部分では、システム正常性を示す重要な生命徴候を含む大量のマシンデータと共に、実体モデルの複雑性を説明する。ビッグデータ解析およびリアルタイムＣＥＰ技術は、この分野の問題を解決するために、大きな注目を集めている。各技術自体は、この分野の問題を解決するのに不十分であるが、殆どの場合、２つの技術は、切り離されている。２つの技術を統合し且つ大規模な状態管理を行うための他の必須技術を追加するためのフレームワーク、例えばＫＩＤＳが必要とされる。必須技術の例として、例えば、双時間データベース、式フィルタ、登録クエリ、およびＲＥＴＥ、ＢＢＮ、ＭＳＥＴ、ＳＶＭ、神経ネットワーク、ＯＷＬおよび種々の時系列アルゴリズムなどの多くの推論エンジンを統合するための前方連鎖オーケストレーションエンジンおよび後方連鎖オーケストレーションエンジンが挙げられる。

図１０を参照して、実体モデルが示される。この実体モデルは、顧客ポッドを含むOracle FusionアプリケーションSaaSに使用されるモデルである。このFusionアプリケーションは、仮想マシンに配置される。仮想マシンは、エクサロジック（Exalogic）ラックの物理計算ノードに配置され、データベースは、エクサデータ（Exadata）ラックの物理データベースノードに配置されている。この実体モデルは、スレッドセグメント、スレッドクラスおよびスレッドクラス間の依存関係による周期的なスレッドダンプ内の高強度スタックトレースの動的分類によって発見された実体で拡張される。依存関係は、スレッド間の通信およびプロセス間の通信を取得する。実体モデルにスタックトレース分類モデルを追加することは、システム生物学において、ヒトゲノム情報学を人体解剖モデルに追加することと非常に類似する。

スレッド強度は、システム機能の性能ホットスポットの「ホット性」（hotness）を測る統計的尺度を提供する。コードブロック（code block）のホット性は、コードブロックの呼び出し回数にコードブロックの実行時間を乗算することによって、定量化することができる。同様の尺度は、様々な性能解析ツール、例えば、Oracle Sun Studio 12 Performance Analyzer、Intel（登録商標）VTune Amplifier、AMD（登録商標）CodeAnalyst、Oracle Database Active Session History (ASH)、Oracle JRockit Flight Recorder、およびUNIX gprof commandに適用されている。

スレッドクラスは、セグメントクラスの有序集合である。例えば、ＣＲＭドメイン販売サーバＡＤＦアプリケーションスレッドは、１組のセグメントクラス（ＣＲＭドメイン、販売サーバ、ＡＤＦアプリケーション、およびＡＤＦウェブサービス呼び出し）によって表される。例示的なスレッド依存関係は、［（ＡＤＦウェブサービス呼び出し）→（ＡＤＦウェブサービス、ＡＤＦ－ＢＣ）］である。［（ＡＤＦウェブサービス呼び出し）→（ＡＤＦウェブサービス、ＡＤＦ－ＢＣ）］は、サブクラス［（ＣＲＭドメイン、販売サーバ、ＡＤＦアプリケーション、およびＡＤＦウェブサービス呼び出し）→（ＣＲＭドメイン、注文取得サーバ、ＡＤＦウェブサービス、ＡＤＦ－ＢＣ、データベース運用）］を有する。クラス（ＡＤＦウェブサービス、ＡＤＦ－ＢＣ）は、高強度クラス（ＣＲＭドメイン、注文取得サーバ、ＡＤＦウェブサービス、ＡＤＦ－ＢＣ、データベース運用）にドリルダウンされてもよく、スレッド依存関係を介して、データベーススレッド（データベース、Fusionアプリケーションスキーマ）にドリルして、その後、データベース内のコールグラフ、コールツリーまたは（ＳＱＬ実行プランと実行トレースを含む）コールスタックモデルを（データベース、Fusionアプリケーションスキーマ）スレッドの高強度サブクラスにドリルダウンされてもよい。

呼び出し連鎖に沿って伝達された実行環境ＩＤ（ＥＣＩＤ）を用いて、ミドルウェアおよびデータベース層の間で例外トレースを相関させることによって、個々の実行環境における問題の根本原因の解析を支援することができる。生命徴候を用いて、一定の時間間隔で採取された一連のスレッドダンプサンプルからの様々なクラスのスレッドおよびスレッドセグメントの強度統計値の測定値に基づいて、システム問題を診断することができる。スレッドのクラス間の依存関係情報を用いて、ミドルウェアおよびデータベース階層の間の発生率を相関させることによって、根本原因の解析を支援することができる。スレッド強度の統計は、分類階層をドリルダウンする能力を向上させ、スレッド階層の特定のサブクラスの強度を観察することができる。スレッド強度の統計は、スレッド間の通信チャネルまたはリソースプールのキューのトラフィック強度の可観測性、およびＳＬＡ問題の主要指標である小さな性能グリッチの感度を向上させる。

データキューブは、ロールアップ（roll-up）、ドリルダウン（drill-down）、スライスおよびダイス（slice and dice）、ピボット（pivot）、ドリルアクロス（drill-across）、およびドリルスルー（drill-through）などのＯＬＡＰ操作をサポートするように、実体モデル内の関係の「一部」を反映する寸法および概念束を用いて、定義される。予測診断ソリューションは、システム機能の生命徴候を構成する様々なシステム統計値の測定値を含むシステムの状態空間モデルを必要する。多変量状態推定技術（ＭＳＥＴ：Multivariate State Estimation Technique）は、関連する実体の集合から、時系列データを情報融合するのに特に有効である。逐次確率比試験（ＳＰＲＴ：Sequential Probability Ratio Test）と組み合わせたＭＳＥＴは、機械学習を予測異常検出に適用するロバストな分類モデルである。統計的尺度は、ビッグデータシステムのログから抽出され、データキューブに整理される。統計的尺度は、時系列フィルタによって導出された傾向情報および周期性情報を含む。Brown指数フィルタ、Holt二重指数フィルタ、Winters三重指数フィルタ、不規則な時間間隔に対応するWright拡張、短時間間隔のHanzak調整因子、および／または異常値の検出およびCauchy分布問題、特にＪＶＭ完全ＧＣ統計値の時系列解析におけるCauchy分布問題を克服するために異常値の切り捨ての適応性スケーリングを有する切取に基づいて、特定の時系列フィルタを実装することができる。レベル急増、レベル変遷、分散変化、異常値およびエンドポイント予測などの傾向を時系列データから抽出し、この定量傾向を低、正常または高などの定性値に変換することができる。

ＪＶＭ完全ＧＣ統計値および定期的なスレッドダンプを含むファクトデータを変換することによって、より高次の分類情報を抽出することができる。スレッドセグメントおよびスレッドは、トラフィック強度に応じて、増加するように分類される。スタックトレースは、高強度のスレッドセグメントおよびスレッドと、スレッドクラス間の依存関係およびセグメントクラスへのスレッドクラスのドリルダウンを含むより高次情報とに分類される。定期的なスレッドダンプの時系列データは、各スレッドクラスおよびセグメントクラスの強度に関する傾向情報、例えば、周期サイクル、線形傾向、分散変化、レベル急増、レベル変遷、異常値、飽和またはエンドポイント予測などを含む。観測時間に亘ってイベントの数を実質的な傾向変化の数に比例するによって、傾向情報は、大量の時系列データをより簡潔な一連のイベントに減らす。システム状態は、傾向情報を表す特徴ベクトルによって特定することができる。システム状態の遷移は、実質的な傾向変化を表すイベントによって定めることができる。

したがって、ＫＩＤＳモデルは、異なる分類知識によって推論された観察結果、目的、予測結果、シミュレーション結果および周期予測などの様々な特定タイプの情報の融合および関連する実体間の情報の融合を行うことができる。また、ＫＩＤＳモデルは、効果的なＫＩＤＳループをサポートすることによって、異常を検出し、根本原因を診断しおよび大規模なクラウド運用時のリソースを動的に管理するために必要とされる複雑性および異質性で、情報融合および状況認識を行うことができる。

使用事例－ソフトウェアおよびハードウェア製品のサポート
この使用事例は、システムの利用不可を最小限に抑えるために、サポートおよび顧客を対応する技術者による協調的および反復的な問題解決行動によって特徴付けることができる。これらの目標を達成するには、既知の問題を解決するために既存の（暗黙または明示）知識を検索および適用するために必要とされる時間、または新しい問題の改善策を見付けるために必要とされる時間を最小限に抑えることが重要である。既知の問題を処理する自動化程度を増加または最大化することによって、サポートおよび顧客を対応する技術者は、解放され、大量の人間経験および知識を必要とする新しく発生する問題に集中することができる。したがって、この分野に開発されたアプリケーションは、絶え間なく自動化要求によって、常に変化し得る。自動化要求によって、３つの課題、すなわち、１）経済的な自動化の実現、２）自動化の迅速な展開を可能にするアプリケーションの設計、３）解決された問題の正確な表現および出所を取得する方法という最大の非技術的な課題が生じる。経済的な自動化を実現するために、正確な表現および出所で、（バグデータベース、サポートチケット内の）製品ライフサイクルの全体に発生した製品問題に関するデータおよび知識を確実に取得することが不可欠である。これらのデータおよび知識は、正確な定義、正確且つ有効な因果関係、システム構成および技術者の貢献と一致した用語を含む。このような表現および出所は、問題再発の可能性および自動的にまたは半自動的に問題を認識して解決する際の複雑度に関する正確な統計を可能にする。次に、収集された出所データに基づいて、問題を診断するためのプロセスを標準化することができる。このような標準化の目的は、データの標準化収集、データの標準化解析および解釈、標準化診断、標準化修復法、および問題解決プロセス全体の標準化を確立することである。

自動化の迅速な展開を可能にするロバストなアプリケーションアーキテクチャを達成するために、自動化問題空間を整合的なモジュール要素に分割することができる。このような分割を達成するためには、空間の自動化複雑性は、均一ではなくてもよい。データ収集の自動化は、データ解析の自動化ほど複雑ではない。また、データ解析の自動化は、診断自動化ほど複雑ではない。また、修復の自動化は、より複雑で異なる。このような自動化複雑性のレベル変化は、問題空間を分割するための自然な境界を提供し得る。

使用事例－患者介護
患者介護は、各々の量および複雑性が絶えずに増加する捕捉データ、観察結果、知識および手順によって決められる要求の厳しいタスクであり得る。医療センサが主流になると、データおよび知識の量がさらに速く増加すると予想される。センサを使用することによって、患者が医師のオフィスにいるか否かに関わらず、医師は、常に患者を診断することができる。測定値、画像（および読取値）、観察結果、診断および治療を記述するデータの組み合わせであるＥＭＲ（電子医療記録：Electronic Medical Records）の収集が非常に重要であるが、これらの記録だけではまだ不十分である。ＥＭＲは、データを意味のあるカテゴリに編成せず、誰がいつでどのデータを見たのか、どの理由でどの診断を下したのか、どのコンピュータ化知識およびどのバージョンを用いてどの結論を出したのかを記載していない。また、医療費が膨大になり、医師の過失もしくは患者または弁護士の利欲によって引き起された誤診訴訟が絶え間なく続いている。

医師は、多くの方法を用いて、患者を介護する。頻繁に使用される用語の一部は、症例に基づく医療、介護基準、分別診断および個別／精密医療を含む。無数のアプリケーションを使用して、医師をサポートできるが、これらのアプリケーションは、一部の仕事しか行えず、さらに、これらのアプリケーションは、専有的で不明瞭であるため、実質的に大きな拡張、個別化および高速進化を行うことが不可能である。網羅的ではないが、全ての治療段階で医師を支援し、医師が医師の言語でシステムと通信し、測定値をコンパクトな形に変換し、厳密な出所を提供し、異常を警告し、大きな拡張および個別化を可能にし、永続的に進化するシステムが必要とされる。

患者介護は、ファクトおよび観察結果の形で取得される証拠の収集から始まる。ファクトは、生命徴候、血液化学および画像などの測定結果を含む。測定ファクトは、定量的である。分類を用いて、ファクトは、測定結果が基準から偏差する度合および画像の解釈などの認知結果に変換される。ファクトは、認知結果として扱われる観察結果によって補完される。認知結果を評価することによって、観察される病気の根本原因および関連する信頼性を判定する１つ以上の診断（仮説）に得ることができる。次のステップでは、介護基準に基づいて、指令をもたらす治療計画、例えば、特定の治療および／またはより多くの検査を行うことができる。指令の実施によって、より多くのファクトを生み出す。この循環は、目標が既に達成したかもしくはそれ以上何もすることがないまたはそれ以上何もできないという仮説が出るまで継続する。これは、分別診断の一例である。これらのステップの殆どは、コンピュータによりサポートされまたは次第にコンピュータによりサポートされるため、一定のファクトストリームに基づいて患者を永続的に監視することができる。新しいコンピュータ化知識は、検証およびリリースされると、すぐに使用されなければならない。サポートは、個別化に行う必要がある。個人またはチームの嗜好に基づいて、知識を適用する必要がある。ソーシャルネットワーキングおよび暗黙知識プロファイリングは、タスクに最も適任である人またはチームの特定に支援することができる。

この使用事例は、ファクトを認知結果に変換する必要性を強調している。患者は、約１０個の生命徴候を有する。これらの生命徴候は、患者の状況に依存して、様々な規模および範囲を有する。したがって、通知条件を指定することは、非常に困難である。医師は、多くのタイプのファクトに対して同一分類子を使用し、ファクトを分類することによって、通知条件を指定する。全ての生命徴候の可能な修飾子は、正常、監視、深刻および危篤である。実際の目的は、物事を直観的に表すために、少ない修飾子を使用することである。修飾子を使用して、少なくとも１つの危篤な生命徴候または２つの深刻な生命徴候を持つ全ての患者を教えてくださいというクエリを正規化および単純化することができる。医師は、時間と共に、進行値に悪化／改善などの注釈を追加する。変化速度を用いて、遅い悪化または速い悪化を議論することができる。明らかに、患者の生命徴候が安定しているか安定していないかなどの安定性値を議論することができる。認知結果は、直観的でコンパクトな言葉を使用するため、医師に好まれる。認知結果の曖昧さは、厳密な出所によって補償されなければならない。

単一値を分類する利点に加えて、一組の値または画像を分類するというより大きな必要がある。一例として、心停止のリスクは、数時間前の血液検査から判断することができる。残念なことに、この判断は、少なくとも１０個の数値の間の複雑な相互関係を理解する必要がある。これは、最も優秀な専門家にとっても不可能なことであるが、コンピュータならうまく行える。したがって、リアルタイムで大量のモデルを評価する必要がある。これによって、医師は、経験したことがないまたは知ったこともない潜在的なリスクを認識することができる。同様に、医師は、分類を閲覧するために、厳密な出所が必要である。

認知結果は、患者の現在状況の重要な特徴を時間に記述する必要がある。その理由として、医師は、現在何が起こっているのか、この状況がどのように進化したか、これからどのように進化するのかを知りたいからである。また、過去の状況も容易に利用可能にしなければならない。分類と併せて予測を使用することによって、医師は、患者の状況が期待通り進化しない場合、通知してくださいという非常に包括的な要求を明確に述べることができる。この要求は、特定の状況において特定の意味を有する。

ＫＩＤＳモデル－概念
ＫＩＤＳは、データ、知識およびプロセス管理に集中するアプリケーションを構造化するモデルを提供する（例えば、図９を参照）。データの管理は、現在、急速に進化している比較的成熟した技術である。ＫＩＤＳは、以下の４つの異なるデータカテゴリを定義して管理することによって、この進化に加えている。
・ファクト
ファクトは、世界で測定可能なデータである。人間の認知システムは、ファクトの数、速度および量的性質を直接に認知することが困難である。ＣＥＰおよびビッグデータなどの技術は、これらのデータを取得および処理する。
・認知結果
認知結果は、ファクト（および観察結果）のコンパクトで時間的且つ定性的な表現である。認知結果は、人間の認知システムによる使用のために最適化されている。認知結果は、ファクトから認識できる進化状況の最も重要な特徴を表している。認知結果は、情報を利用する利用者の視点に依存する。
・仮説
仮説は、ファクトおよび認知結果を説明する可能な根本原因を記述する。
・指令
指令は、特定のファクト、認知結果および仮説に応じて、取るべき措置を記述する。指令は、しばしばワークフローまたはプロセスの形で行動計画を指定する。明らかに、指令は、ファクトの進化に最も大きな影響を与えるだろう。

これらのカテゴリのデータのいずれかは、広範囲のデータタイプ／構造、拡張性、データタイプ／構造間の宣言型アクセス、時間の変遷、進化するデータ構造の柔軟性（構造化データをサポートすること、および、最初にデータをサポートし、その後構造をサポートするまたはサポートしないこと）、ＯＬＴＰおよび解析などを必要とする。また、（ファイングレイン）セキュリティ、出所およびＩＬＭなどの拡張機能が必要になる場合もある。重要な運用特徴は、災害復旧、高可用性、信頼性、拡張性、性能、および迅速な開発ツールを含み得る。場合によって、データの管理は、成熟して広く使用されているデータベースで利用可能な幅広い機能サポートおよび運用サポートを必要とする。ファクトの収集および管理は、古典的な取引モデルを必要とせず、データの限られた損失を許容することができる。成熟したデータベースは、ファクトの管理を最適化し、リソース消費を大幅に削減ようにサポートを提供することができる。

特定の実施形態において、４つのデータカテゴリを補完するように、知識を４つのカテゴリに、すなわち、分類（Classification）、評価（Assessment）、解決（Resolution）および実施（Enactment）に分けることができる。この４つのカテゴリは、各データカテゴリを処理するために必要な推論モードに基づいている。適切な計算モデルによって、知識の各カテゴリの実質的なサブセットを自動化することができる。
・（データを認知結果に変換する）分類知識は、主に演繹推論モードで表される。予測またはノルムを生成する一部の分類知識は、帰納推論を含み得る。分類を行うための計算モデルは、サポートベクトルマシン、ナイーブベイズネットワーク、神経ネットワーク、クラスタリング、関連ルール、決定木、多変量状態推定技術、認知演算などを含む。
・（認識結果を仮説に変換する）評価知識は、典型的に、認知結果から仮説を導出する発想推論によって実現される。評価を行うための計算モデルは、ベイジアン信念ネットワーク、逆問題に対する解の最小二乗最適化または回帰を含む。
・（仮説を指令に変換する）解決知識は、異なる結果の優劣および関連するペイオフ／コストを考慮して、結果の不確実性の下で判断を行う。解決を行うための計算モデルは、決定ノードおよびペイオフ／コストノードを用いて拡張され、影響図、デンプスター・シェイファー理論、決定木および残存有効寿命の予後として知られたベイジアン信念ネットワークを含む。
・（指令を行動（および新しいファクト）に変換する）実施知識は、スクリプト、計画、予定、ＢＰＥＬワークフロー、およびＢＰＭＮビジネスプロセスにコード化された制御構造を含む。

知識は、ＣＡＲＥループによって指定された適切な順序で適用されてもよい。場合によって、ＣＡＲＥループの全てのステップを実行する必要がない。（各バージョンを含む）知識をデータベースに保存することによって、完全な出所を提供し、洗練されたクエリ利用を可能にすることができる。知識は、アドホック且つリアルタイムで適用可能である。１つの使用事例として、新しい知識を用いて、データ（特にファクトおよび認知結果）を再訪することによって、欠落したものおよび過大評価されたものを発見することができる。

ビッグデータ／ＣＥＰをＫＩＤＳの環境に使用することによって、より包括的且つ体系的な手法を作り出すことができる。
・クエリ／モデルは、個々の要素ではなく知識として取り扱われる。知識を照会することができ、進化することができる。
・データおよび知識（クエリ、ルールおよびモデル）は、特定の性質を有する４つのカテゴリで互いに関連する。
・ファクトを認知結果に変換することは、状況に応じて、行動によって補完される。
・出所サポートは、どのバージョンの知識を適用して、どのバージョンのデータを導出したかを明確に記述する。

さらに、各カテゴリの形式知識は、人間の暗黙知識によって補完されてもよい。アプリケーションは、システム内の行為者の暗黙知識および社会的な嗜好をプロファイルできるソーシャルネットワーキングサービスを必要とする場合がある。したがって、最近の行動に基づいて暗黙知識プロファイルを調整することによって、タスクに最も適任である人またはチームを特定することができる。これによって、プロファイルができるだけ最新であることを保証することができる。

いくつかの実施形態において、アプリケーションは、継続改善を含むことができる。アプリケーションの継続改善は、知識を継続的に改善することによって達成することができる。継続改善を可能にする技術は、１）ユーザおよび分野専門家の識見を活用して、ルール、クエリ、モデルおよびコードを改善する技術、および、２）追加のデータまたは新しいアルゴリズムを用いて、モデルを再評価および再実行する技術を含む。

分野の専門家は、知識を交換することができる。この交換は、できるだけ正式に行われる。論文は、使用されたモデルまたは形式論を直感的に理解するのに役立つベン図（Venn Diagram）と同等なものであると考えられる。通常、新しい知識を使用する前に慎重に見直す必要がある。ＫＩＤＳは、進化する知識および既存の知識を同時に使用することができ、両方の結果を示すことができる。また、ＫＩＤＳは、新しい知識で既存のデータを見直することができ、以前に過大評価されたリスクおよび機会だけでなく、新たなリスクおよび機会を示すことができる。

ＫＩＤＳの形式モデル
ＫＩＤＳは、人間行為者、人間行為者に代わって行動するコンピュータプログラムまたはハードウェア素子（エージェント）、および／または観察、診断および処置される実体の間の相互作用を推進するエンジンを含むことができる。ＫＩＤＳの形式モデルは、システム内の行為者、エージェントおよび実体の間の相互作用を駆動するプロセス管理アプリケーションの実装を通知することによって、システム内の情報変更を能動的に管理することができる。

ＫＩＤＳの形式モデルは、多時間データベースシステム内に表されてもよい。モデル内のデータは、トランザクション時間（Ｔｘｎ時間）を有すると考えられるが、トランザクション時間は、モデルに明示的に表されなくてもよい。このルールの１つの例外は、フラッシュバックのクエリおよび出所をサポートするように、トランザクション時間を明示的に表す行動環境である。

有効時間（Valid Time）は、正式な定義における基本的なデータ構造のうちの２つであるＦＳＤデータおよび特徴データにおいて、明示的に示されてもよい。

ＦＳＤ⊆実体×値×有効時間×ＦＳＤタイプ
特徴⊆実体×値×有効時間×特徴タイプ
ベクトル＝｛特徴^ｎ｜ｎ＝１、２、．．．、Ｎ｝
ビッグベクトル＝｛ＦＳＤ^ｎ｜ｎ＝１、２、．．．、Ｎ｝∪ベクトル
ＦＳＤ（フレキシブルスキーマデータ）は、テキスト、オーディオ、ビデオ、空間、グラフ、ＸＭＬ、ＲＤＦおよびＪＳＯＮを含む、データベース内の任意の拡張性データであってもよい。したがって、ＦＳＤは、ファイルを表すことができる。関連するＦＳＤのタイプに応じて、ファイルは、患者介護ドメインにおいて、心電図、Ｘ線、ＣＴスキャン、ＭＲＩスキャンなどを含むことができ、クラウド運用ドメイン並びにソフトウェアおよびハードウェア製品サポートドメインにおいて、スレッドダンプ、ヒープダンプ、データベースＡＷＲスナップショット、データベーストレースなどを含むことができる。特徴は、症状または疾患の観察値範囲内で、低、正常および高などのカテゴリ値を表すことができる。関連する特徴のタイプに応じて、症状または疾患は、患者介護ドメインにおいて、呼吸器感染、急性気管支炎、喘息などを表すことができ、クラウド運用ドメイン並びにソフトウェアおよびハードウェア製品サポートドメインにおいて、高血圧、低血圧、インピーダンス不整合、コンボイ効果などを表すことができる。

有効時間およびＴｘｎ時間は、時間間隔である。時間間隔［ｔ１，ｔ２）は、集合｛ｔ｜ｔ＞＝ｔ１、ｔ＜ｔ２、且つｔ１＜ｔ２、ｔ、ｔ１、ｔ２∈日付時間｝を表す。瞬時ｔ１は、［ｔ１，ＮＡ）で表すことができる。２つの有効時間［ｔ１，ｔ２）および［ｔ２，ｔ３）を１つの有効時間［ｔ１，ｔ３）に合併することができる。
・有効時間＝［日付時間，日付時間∪｛∞．ＮＡ｝）
・Ｔｘｎ時間＝［日付時間，日付時間∪｛∞．ＮＡ｝）
ＫＩＤＳシステムは、７－タプル（行為者、エージェント、実体、ＣＡＲＥ、メタデータ、環境、プロファイル）であってもよい。行為者とは、人間行為者の集合であり、エージェントとは、人間行為者の代わりに動作するコンピュータプログラムまたはハードウェア要素の集合である。実体は、観察、診断および処理される実体の集合である。
・ＣＡＲＥ＝（データ、知識）
・データ＝（ファクト、認知結果、仮説、指令）
・知識＝（分類、評価、解決、実施）
・データは、２つの基本的なデータ構造ＦＳＤおよび特徴で示される。
・ファクト⊆ガード×行動×実体×ビッグベクトル×有効時間
・認知結果⊆ガード×行動×実体×ベクトル×有効時間×ＦｏＭ
・仮説⊆ガード×行動×実体×ベクトル×有効時間×ＦｏＭ
・指令⊆ガード×行動×実体×ベクトル×有効時間×ＦｏＭ
・状況＝ファクト∪認知結果∪仮説∪指令
状況は、ファクト、認知結果、仮説および指令の概括であってもよい。状況インスタンスは、ＣＡＲＥループインスタンス内の特定の行動インスタンスに関連付けられ、行動インスタンスに関連付けられたＫＦｕｎ関数の入力または出力を表す。状況インスタンスは、実体に関連付けられてもよく、関連する実体の状態の一部であり得るＦＳＤまたは特徴のベクトルを含む。すなわち、状況の実体は、有効なＪＰＱＬ経路式によって、状況内の各ＦＳＤまたは特徴の実体に関連付けることができる。ＦｏＭは、信頼水準、信頼区間、確率、スコア、二乗平均平方根誤差、ペイオフ／コストなどを表す性能指数の定量値または定性値である。

・Ｋｆｕｎは、分類、評価、解決、実施および症状解決の概括である。
・メタデータ＝（ＣＡＲＥループタイプ、行動タイプ、ＦＳＤタイプ、特徴タイプ、Ｋｆｕｎ定義）。
・ＣＡＲＥループタイプ⊆名前
・行動タイプ⊆名前
・ＦＳＤタイプ⊆名前×実体タイプ×暗号化×言語
・特徴タイプ⊆名前×実体タイプ×許容値
・Ｋｆｕｎ定義＝（事前条件、事後条件）
・事前条件⊆フィルタ定義^ｎ×Ｋｆｕｎ
・事後条件⊆Ｋｆｕｎ×フィルタ定義^ｎ
・フィルタ定義⊆（ＦＳＤタイプ∪特徴タイプ）×フィルタ×受任者
事前条件メタデータおよび事後条件メタデータは、Ｋｆｕｎ関数間の影響関係を捕捉することによって、（関連する実体セットの）ＦＳＤおよび特徴セットが同時に有効になり、Ｋｆｕｎ関数を呼び出すために必要な状況を満たす時間を検出する。フィルタは、ＪＰＱＬ経路式（path expression）で定義された述語である。必須物は、Ｋｆｕｎ関数を呼び出すために、入力または出力状況の一部でなければならない対応するＦＳＤタイプまたは特徴タイプを指定するブール演算式（Boolean expression）である。

環境は、５－タプル（ＣＡＲＥループ、分類、評価、解決、実施）である。
・ＣＡＲＥループ＝ＣＡＲＥループタイプ×実体×行為者×カウンタ×（分類×評価×解決×実施）^ｎ
ＣＡＲＥループインスタンスは、一連の行動の閉包（closure）であって、各行動インスタンスと共に、ＣＡＲＥ定義によって定義されたフィルタを評価するための環境を表す。カウンタは、ＣＡＲＥループインスタンスの状態の一部である０～ｎ内のループカウンタである。
・分類⊆行動タイプ×ファクト×（分類）^ｎ×認知結果×行為者×Ｔｘｎ時間×有効時間
・評価⊆行動タイプ×認知結果×（評価）^ｎ×仮説×行為者×Ｔｘｎ時間×有効時間
・解決⊆行動タイプ×仮説×（解決）×指令×行為者×Ｔｘｎ時間×有効時間
・実施⊆行動タイプ×指令×（実施）^ｎ×ファクト×行為者×Ｔｘｎ時間×有効時間
分類、評価、解決、または実施インスタンスは、分類、評価、解決、または実施機能の各々の実行環境を表すことができる。
・行動＝分類∪評価∪解決∪実施
・行動＝行動タイプ×状況×（ＫＦｕｎ）^ｎ×状況×行為者×Ｔｘｎ時間×有効時間
行動は、分類、評価、解決および実施の概括であってもよい。（それぞれが一対の入力／出力状況インスタンスを有する）多くの行動インスタンスを同一のＫＦｕｎ関数に関連付けることができる。ガードは、ＣＡＲＥループインスタンスまたは行動インスタンスの環境で評価される、ＪＰＱＬ経路式および必須のブール演算式で指定されたフィルタのセットから構成されたクエリである。
・プロファイルは、（行為者プロファイル、知識プロファイル、行動代理者、個人化）のトリプルである。
・行為者プロファイル⊆行為者→実体×特徴×有効時間×ＦｏＭ
・知識プロファイル⊆Ｋｆｕｎ→実体×特徴×有効時間×ＦｏＭ
・行動代理者⊆｛ｆ｜ｆ：行動→行為者｝×有効時間
・個別化：Ｋｆｕｎ×行為者→Ｋｆｕｎ
・個別化は、カレー演算子の観点から解釈できる。
・個別化（Ｋｆｕｎ、行為者）≡カレー（Ｋｆｕｎ）（行為者プロファイル（行為者））
ＫＩＤＳ実行モデル
この部分では、ＫＩＤＳ実行モデルの１つ以上の実施形態を説明する。ＣＡＲＥループインスタンスは、一連の行動（分類、評価、解決および実施）の閉包（closure）であってもよい。ＣＡＲＥループインスタンスは、過去に起きた行動、現在の行動または現在進行中の行動および将来起き得る行動からなる歴史的および意図的な環境を提供することができる。ＫＩＤＳは、各ＣＡＲＥループインスタンスのループカウンタを維持することができる。行動インスタンスは、現在のループカウンタの下で実行される場合、現在の行動インスタンスと見なされてもよい。現在の行動インスタンスは、行動インスタンスの入力状況が実質的に変更されたときに実行されると想定される。ループカウンタは、現在のループカウンタの下で全ての現在の解決行動インスタンスが実行されたときに、増加する。

ＣＡＲＥループインスタンスは、インスタンスタイプおよびインスタンス所有者を有することができる。インスタンスタイプは、類似するＣＡＲＥループインスタンスをグループ化する。インスタンスタイプを用いて、ＣＡＲＥループインスタンス内で実行される行動インスタンスをカスタマイズまたは制約することができる。ＣＡＲＥループタイプを初めて指定するときに、行為者（そのタイプの最初のインスタンスをインスタンス化した行為者またはこの行為者が指定した別の行為者）は、所有者としてそのタイプに関連付けられる。ＣＡＲＥループインスタンスの各行動インスタンスには、行動インスタンスの実行に適格な代理行為者がいる。行動インスタンスには代理人が存在しない場合、ＣＡＲＥループインスタンスの所有者は、行動インスタンスの代理人になる。また、ＣＡＲＥループインスタンスの明示的に指定された所有者がいない場合、タイプ所有者は、デフォルトでインスタンス所有者になる。インスタンス所有者または行動インスタンスの代理人は、指定された関数によって行動代理者から計算することができる。このような関数は、ＣＡＲＥループインスタンスの環境またはＣＡＲＥループインスタンス内の行動インスタンスで評価された経路式によって定義される。

ＣＡＲＥループインスタンスタイプの所有者は、ある種の全てのインスタンスの挙動を制約することができる。ＣＡＲＥループインスタンスの所有者は、タイプ所有者によって指定された制約内で、インスタンスの挙動をさらにカスタマイズすることもできる。ＣＡＲＥループインスタンスの所有者は、初期の行動インスタンスおよび任意の後続の行動インスタンスを作成することによって、実行中にＣＡＲＥループインスタンスの新しい行動インスタンスを定義することができる。また、ＣＡＲＥループインスタンスまたはタイプ所有者は、行動インスタンスの状況インスタンスのＦＳＤまたは特徴を作成する前に、新しいＦＳＤタイプまたは特徴タイプを作成することによって、ＣＡＲＥ定義メタデータを作成することもできる。行動インスタンスは、ＣＡＲＥ定義メタデータによって定義され、エンコードされた知識関数（ＳＶＭ、ＭＳＥＴ、ＢＢＮなどのマシン）によって実装することができる。ＣＡＲＥ定義のいくつかの例は、図１１Ａ～１１Ｅに示されている。

インデックス（例えば、ＣＡＲＥループ［ｉ］．分類、ＣＡＲＥループ［ｉ］．評価、ＣＡＲＥループ［ｉ］．解決およびＣＡＲＥループ［ｉ］．実施のインデックスｉ（ｉ＝０．．．ｎ））を用いて、ＣＡＲＥループインスタンスから、行動インスタンスを一意的に特定することができる。ＣＡＲＥループインスタンスの状態は、ＣＡＲＥループインスタンス内の行動インスタンスに関連付けられた状況インスタンス内のＦＳＤおよび特徴の集成、すなわち、経路式によって利用可能なＦＳＤおよび特徴の集成、例えば、ＣＡＲＥループ［２］．分類．認知結果．特徴［平均メモリ使用量］．実体を含む。多くの行動インスタンスをＫｆｕｎ関数およびＫｆｕｎ関数のＣＡＲＥ定義メタデータに関連付けることができる。ＫＩＤＳは、現在のループカウンタの下で実行される現在の行動インスタンスを選択することができる。現在の行動インスタンスの実行は、各行動インスタンスに指定されたガードを用いて制御される。ガードは、経路式および必須ブール演算式で指定された一連のフィルタ述語を含む。経路式、例えば、ＣＡＲＥループ［１］．解決．指示．特徴［より多くのメモリの割当］．値または認知結果．特徴［メモリ使用量の急増］．値は、ＣＡＲＥループインスタンスまたはＣＡＲＥループインスタンス内の行動インスタンスの環境で評価される。行動インスタンスが最新になると、ＫＩＤＳは、対応するガードを用いて、ＳＱＬクエリ文を作成する。このようなクエリの結果は、状況（ファクト、認知結果、仮説または指令）インスタンスである。オブジェクトの変更を検出するたびに、クエリを登録するこができる。ＦＳＤまたは特徴を更新または挿入する場合、ＫＩＤＳは、対応する行動インスタンスのＴｘｎ時間によって記録された最後のトランザクション時間で、登録した各クエリ文のフラッシュバッククエリを実行する。また、ＫＩＤＳは、現在のトランザクション時間でクエリを実行する。状況インスタンスが２つのトランザクション間で実質的に変化する場合、ＫＩＤＳは、更新された状況を用いて、行動インスタンスを起動することができる。これは、行動インスタンスに関連付けられたＫｆｕｎ関数の呼び出しである。Ｋｆｕｎ関数の呼び出しおよび入出力状況インスタンスを実行した後、ＫＩＤＳは、新しいトランザクション時間（Ｔｘｎ時間）を行動インスタンスに保存する。全ての必須ＦＳＤおよび特徴が入力状況の一部になるまで、ＫＩＤＳは、Ｋｆｕｎ関数の呼び出しを延期する。したがって、ＫＩＤＳは、ＣＡＲＥループ行動インスタンスの実行を調整し、ＣＡＲＥループのカウンタを増やす。

状況定義は、状況内のＦＳＤまたは特徴のＦＳＤタイプおよび特徴タイプを指定するフィルタ定義のリストを含むことができる。また、各フィルタ定義は、ＹＡＫ－Ｄｏｍ０．１２－ＯＶＭ．２２２＝特徴．実体．オラクルＶＭおよび特徴．名前＝ＥＳＳプロセス急増などのフィルタ述語も指定する。フィルタ定義によって指定されたフィルタ述語を用いて、Oracleデータベース式フィルタ表に式を登録することによって、現在のトランザクション内の新規ＦＳＤまたは特徴もしくは更新ＦＳＤまたは特徴によって影響され得る登録済のクエリ文を選択することができる。ＫＩＤＳは、影響されたクエリ文のみに対してフラッシュバッククエリを実行することによって、状況インスタンスの変更を検出する。フィルタに経路式を使用することによって、関連する実体セットのＦＳＤおよび特徴を状況インスタンスに集約することができる。経路式は、指定された実体モデルに対して有効にしなければならない。

ＫＩＤＳは、現在のループカウンタで２つ以上の現在行動の入力状況インスタンスに対する変化を検出した場合、分類＜評価＜解決＜実施という優先順位に従って、１つの行動を選択し、実行することができる。１つ以上の現在解決行動インスタンスの実行がループカウンタに達し、一連の新しい行動インスタンスがアクティブになるまで、現在行動の入力状況インスタンスが変化すると、現在行動を反復的に実行することができる。また、新しいバージョンのＫｆｕｎ関数を用いて、状況インスタンスを再評価し、行動インスタンスを再実行するために、ループカウンタを低い数値にリセットすることもできる。

したがって、大規模な状態管理、リッチデータモデルおよびデータタイプ、式フィルタ、フラッシュバッククエリおよび登録クエリの成熟したデータベース技術を用いて、ＫＩＤＳエンジンを実装することができる。

ＫＩＤＳ－クラウド運用の体験
ＫＩＤＳエンジンは、上述したＢＢＮ、ＲＥＴＥ、ＭＳＥＴ、ＳＶＮ等の様々な推論エンジンの相互作用を編成することができる。ＫＩＤＳデータベースは、図１２に示すように、ファクトデータ内のＦＰＨＤおよびＣＡＲＥデータを注釈することによって、出所データのＫＩＤＳループを実現することができる。ＫＩＤＳモデルは、ＩＴ運用時に、ログ解析システムおよびリアルタイム企業管理システム用のビッグデータシステムを統合することができる。この２つのシステムは、自動化島によって切断され、包囲されているビッグデータおよびＣＥＰを表す。ＫＩＤＳモデルは、動的実体モデル、ログ解析およびリアルタイム監視からの情報融合を行うことによって、リアルタイムでより高速なＯＯＤＡループを可能にすることができる。

ＫＩＤＳモデルは、異なる分類知識によって推論された様々な特殊種類の認知結果、例えば、観察結果、目的、予測結果およびシミュレーション結果などの情報融合を可能にし、関連する実体間の情報融合を可能にする。図１３に示す情報融合の例示的なシナリオにおいて、情報を収束する関連実体のセットは、Oracle VM、JAVA（登録商標） VM、Dom0ホスト、Dom0ホストに位置する他のOracle VMおよびJava VMを含む。動的実体モデルは、時間データベースによって管理される。

図１１Ａ～１１Ｃに示す例示的なシナリオにおいて、「メモリ使用量の急増」および「企業スケジューラサービスプロセスの急増」特徴は、ＯＳメモリおよびＯＳプロセスの測定における異常な傾向の分類の一部であり得る。図１１Ａおよび１１Ｃにおける「メモリ不足予測」特徴は、時系列フィルタによって生成された認知結果の一部である。「他のOracle VM内のＪＶＭのヒープを圧縮できる」および「他のOracle VMからメモリを再利用できる」などの追加機能は、Dom0内の全てのOracle VMに位置する全てのJava VMの平均負荷および周期性動向データを含むデータキューブに対するロールアップ操作によって予測された認知結果の一部である。ＫＩＤＳ実体モデルは、「Dom0に動作しているOracle VMの目録」、「各Oracle VMに動作しているJava VMの目録」、並びに「他のOracle VM内のJVMのヒープを圧縮できる」および「他のOracle VMからメモリを再利用できる」に関する認知結果に基づいて、状況認識を行うことができる。これらの認知結果の全ては、状況インスタンス内の共通有効時間間隔で一致する必要がある。

ＫＩＤＳモデルは、様々な推論エンジンに実装された知識関数の相互作用構造を取得することができる。図１４に示すＣＡＲＥループは、事実上、一連のネットワークであり、相互作用は、（行動インスタンスおよびガードインスタンスは、遷移を表し、状況インスタンスは、場所を表し、ＦＳＤおよび特徴は、トークンを表す）ペトリネット（Petri-Net）に類似する。評価関数の行動インスタンスは、図１５に示すベイジアン信念ネットワークによって実現される。相互作用モデルを使用することによって、ＫＩＤＳは、様々な推論エンジンに関与するモデルの実行を調整することができる。

図１５のＢＢＮによって示された評価知識「Oracle VMメモリの診断」は、与えられた認知結果を診断し、「Dom0は、OVMに割り当てるメモリを有する」および「Oracle VMにより多くのメモリを割り当てる必要がある」という仮説を導出することができる。同様のネットワークは、Dom0の指令に到達する仮説を「Dom0からのメモリをOVM2に割り当てる」に組み合わせる解決知識「Oracle VMメモリの解決」を含む。評価知識は、ＥＳＳジョブを処理した後、「OVMからメモリを再利用する必要がある」という仮説に到達することができる。影響図によって示された解決知識は、「Oracle VMからメモリを再利用する」というDom0の指令に到達する。「Dom0からのメモリをOracle VMに割り当てる」という指令は、同一のDom0に位置する他のOracle VMに動作しているJava VMの完全なガベージコレクション（ＧＣ）およびヒープ圧縮をトリガする実施関数によって実施される。Java VMのヒープ圧縮を行った後、実施関数は、Dom0に指示して、バルーン内のメモリを再利用するように、他のOracle VMのメモリバルーン（起動メカニズムの一部）を拡張することができる。これによって、Dom0は、ＥＳＳによって生成されたプロセスをサポートするように、弾性メモリをOracle VMに割り当てることができる。ＥＳＳプロセスが周期性を示すスケジュール行動であるため、実施機能によるＫＩＤＳの反応的且つ予測的な対応は、周期性行動の一部となる。

ＫＩＤＳの体験－ソフトウェアおよびハードウェア製品
以下は、ＫＩＤＳ設計の知識抽出および自動化体験の要約を説明する。この要約は、モジュラー製品サポートのトラブル対応行動をＣＡＲＥループにマッピングし、関与する人員の個人生産性と知識および出所の正確な結合とのバランスをとる方法を示している。知識および出所の正確な結合は、経済用語およびプロセスの標準化をもたらし、最終的には知識の自動化および迅速なアプリケーションの進化につながる。この方法は、協力的且つ生産性の高い実践共同体の育成に大きく貢献することができる。

以下のシナリオにおいて、自動インシデントまたは顧客による手動行為のいずれかは、ループインデックスｉ＝０で始まる新しいＣＡＲＥループインスタンスをインスタンス化する。この処理は、４つの段階、すなわち、問題の特定、問題の検証、原因の特定および解決策の提供から構成される。

・問題特定段階（ＩＩ－ｉ）
指令（ＩＩ－ｉ）は、顧客の担当者からの問題に関するデータを引き出すまたはテレメトリデータを収集し、問題またはメトリック値の収集に対する回答として、ファクト（ＩＩ－ｉ）を生成する行動計画である。

ファクト（ＩＩ－ｉ）を分類することによって、観察結果として知られる認知結果（ＩＩ）を得る。

認知結果（ＩＩ－ｉ）を評価することによって、潜在的な問題として知られる仮説（ＩＩ－ｉ）を得る。

仮説（ＩＩ－ｉ）を解決することによって、初期データ収集の行動計画として知られる指令（ＩＶ－ｉ＋１）を得る。

・問題検証ループ（ＩＶ－ｉ）
指令（ＩＶ－ｉ）を実施することによって、一連のログファイルおよびトレースファイルであるファクト（ＩＶ－ｉ）を生成する。

ファクト（ＩＶ－ｉ）を解析（分類）することによって、一連の観察結果である認知結果（ＩＶ－ｉ）を得る。

認知結果（ＩＶ－ｉ）を評価することによって、検証されたまたは検証されていない問題である仮説（ＩＶ－ｉ）を得る。

問題が検証された場合、原因決定に進み、指令（ＣＤ－ｉ＋１）を作成することによって原因（故障状態）を決定する。そうでない場合、指令（ＩＩ－ｉ＋１）を作成することによって問題特定に戻る。

・原因決定ループ（ＣＤ－ｉ）
指令（ＣＤ－ｉ）を実施することによって、追加のログファイル、トレースファイルおよび構成データの形で、ファクト（ＣＤ－ｉ）を生成する。

ファクト（ＣＤ－ｉ）を解析することによって、追加の観察結果である認知結果（ＣＤ－１）を得る。

認知結果（ＣＤ－ｉ）を評価することによって、故障状態として知られる仮説（ＣＤ－ｉ）を生成する。

高い信頼度をもって仮説（ＣＤ－ｉ）を発見した場合、指令（ＳＰ－ｉ＋１）（解決行動計画）を作成する。そうでない場合、更なるデータを収集するための指令（ＣＤ－ｉ＋１）を生成することによって、潜在的な原因をさらに究明する。

・解決案計画ループ（ＳＰ－ｉ）
指令（ＳＰ－ｉ）は、仮説の原因によって引き起こされた問題を修正し、解決策を検証するために追加データを収集する一連の行動である。これらの行動は、実施されると、ファクト（ＳＰ－ｉ）を生成する。

ファクト（ＳＰ－ｉ）を解析することによって、解決策の観察結果である認知結果（ＳＰ－ｉ）を得る。

認知結果（ＳＰ－ｉ）を評価することによって、解決策が問題を解決できるか否かを検証する仮説（ＳＰ－ｉ）を生成する。

仮説（ＳＰ－ｉ）が解決策を検証した場合、ＣＡＲＥループを終止させる指令（NO-OP-END）を提供する。そうでない場合、指示（ＣＤ－ｉ＋１）を作成することによって原因決定に戻り、または指示（ＳＰ－ｉ＋１）を作成することによって新たな解決案を試みる。

上述した特定のＣＡＲＥループ内のいずれかの行動は、プロセスの成熟度およびループを所有する支援チームの明示的知識ならびにドメインの複雑性に応じて、手動、部分自動化または完全自動化で実行されてもよい。ＫＩＤＳ解析サービスを利用して、部分自動化または完全自動化の準備が整った手動行動を適格にする。そのような行動は、十分な成熟度に達し、自動化するための経済的に妥当なＲＯＩを有しなければならない。データ収集の自動化は、製品に組み込まれた診断可能なフレームワークを介して達成され、重大な問題の最初の失敗データの取得およびより深い識見を得るためのオンデマンド計測を実現した。迅速な展開を実現するために、自動化要素は、宣言的な方法で指定され、検出は、完全に自動化され、自動化の迅速なターンアラウンドを保証する。ＫＩＤＳプラグインフレームワークを利用して、ドメイン特有サービスおよび知識、例えば、ドメイン特有オントロジーリポジトリ、解析モジュールの自動検出フレームワークをサポートするＸＭＬに基づく診断データ解析フレームワークを含むことができる。データ解析の自動化は、収集したデータをＸＭＬ正準表現に変換し、ＸＰＡＴＨルール内のデータ解析ルールを指定することによって達成される。ＸＰＡＴＨにおいて簡単に指定できない複雑なパターンについて、Ｊａｖａで再利用可能なデータ解析パターンのライブラリを開発することができる。診断を自動化するために、手動モデリングは、自動化のために実行可能な唯一の方法ある。また、ＫＩＤＳプラグインフレームワークを利用して、ベイジアン信念ネットワークに基づくモデリング、自動検出および自動化フレームワークを含むことができる。実際に、ＫＩＤＳ ＣＡＲＥループを利用して、これらのモデルの構築および検査を行うこともできる。ベイジアン信念ネットワーク（ＢＢＮ）を用いて、診断をモデル化することができる。ＢＢＮは、機械学習を妨げる問題空間の散生性質によって、理想的なパラダイムを提供した。ＢＢＮを構築することによって、診断結果の説明および不完全且つ異常な入力データの処理に役立つ。

また、手動行動の個人生産性をサポートするために、ガイド付きタグ付け、ハッシュタグ拡張およびインライン行動計画仕様の形のＫＩＤＳを個人生産性サービスに使用することができる。詳しくは、用語の標準化を可能にするために、ガイド付きタグ付けを利用することができる。パーソナル用語を定義するために、ハッシュタグ拡張を利用することができる。ＫＩＤＳを用いて、行動計画の取得および共有を行うために、インライン行動計画仕様を検討することができ、データ解析ルールセットの取得および共有を行うために、セルフサービス式個人データ解析の自動化を検討することができる。これらの様々な例は、一方では個人的な権限委譲を提供することができ、他方ではコミュニティの共有および合作を可能にする。例えば、タグ付けは、個人知識の組織化および検索を可能にする。ガイド付きタグ付けは、標準化タグセットに対するコミュニティの集中を可能にする。また、ハッシュタグ拡張ユーザ体験サービスは、テキスト文例集または用語定義を一度指定した後、個人レベルで複数回に再利用することを支援し、コミュニティがこれらの定義を共有できるようにすることを目的としている。最後に、インライン行動計画によって、個人レベルで再利用可能な行動計画を作成することができ、行動計画の行為者がチェックリストとして行動計画を活用することができる。行動計画は、コミュニティレベルで共有および交換することができる。全てのこのようなユーザ体験サービスは、個人的な権限委譲をサポートすると共に、行動コミュニティが最良行動および共通用語に集中することを支援する。

ＫＩＤＳの体験－患者介護
患者介護ＫＩＤＳプロジェクトの目的は、分類および出所にある。出所をサポートするために、全ての患者記録は、トランザクション時間データベースに管理される。登録クエリおよびモデルを用いて、分類を管理する。誤報を減らすために、医師は、分類を個体患者のレベルまで調整することができる。生命徴候について、正常、監視、深刻および危篤の分類を使用した。これらの分類を使用するように、登録クエリを表現することができる。その結果、医師は、自分の言語で、例えば、患者Ｘの少なくとも１つの生命徴候が２分以上に危篤になった場合、私に通知するという規則を定義することができる。このような規則は、分類の詳細とは独立しているため、少量でも十分であり、安定である。

さらに、非仮説駆動モデルを用いて、数時間後に心臓が停止する可能性を予測することができる。驚くべき結果は、生命徴候、特に最新のデータが利用可能な生命徴候は、「長期」予測には重要ではないことである。ＫＩＤＳ技術は、そのようなイベントまたは良好ではないエンドユーザの抽象化を示すことができる。インシデントオブジェクトという用語を使用できる。アイデアは、状況（状態）モデルに進化することができる。いくつかの実施形態は、単に、ファクト、分類および認知結果の管理に関与する。プロジェクトが完了した後、ＣＡＲＥループの他の要素を追加することができる。

ＫＩＤＳデータベースの仕様
いくつかの実施形態において、ＫＩＤＳモデルを実装するために使用されたデータベースは、特定の要件または仕様を満たす必要がある。場合によって、ＫＩＤＳデータベースは、ユーザがＣＡＲＥループインスタンスを照会できるように宣言型照会言語を提供することができる。ＳＱＬを使用して、宣言型言語モデルを提供することができる。しかしながら、ＳＱＬは、アトミックデータ（atomic data）しか照会できない。ＫＩＤＳを照会するために、ＣＡＲＥループインスタンスのセットを照会するようにＳＱＬを拡張する必要がある。ＳＱＬは、一次キー／外部キーを用いてデータ間のリンクを照会できるが、再帰グラフ走査（recursive graph traversal）に関与するＣＡＲＥループインスタンスおよび行動インスタンスの照会に制限される。ＳＱＬにおけるグラフ走査の宣言構成の最も近いサポートは、再帰クエリである。しかしながら、再帰クエリは、元の再帰構造から得られた結果ではなく、表形式で最終結果を提供する。したがって、ＫＩＤＳ照会言語によって、ユーザは、ＣＡＲＥループパスを照会および走査して、行動インスタンスが状況インスタンスにどのように依存しているかおよびＫｆｕｎ知識関数がどのように適用されているかを確認することができる。

また、ＫＩＤＳデータベースは、ＫＩＤＳ要素を操作するための宣言型操作言語を提供することができる。ＣＡＲＥループは、何が起こったのかを追跡することができる。しかしながら、ユーザは、ある種類の方法で、知識、例えば「what ifクエリ」を変更した場合、ＤＭＬを用いて、何が起こったのかまたは何が起きるかを断言することができる。したがって、ユーザは、新しい知識を用いて履歴データを評価することによって、履歴データから新しい識見を得ることができる。このことは、過去への時間トラバーサルと同様である。さらに、ユーザは、異なるバージョンの知識を用いて、複数のＣＡＲＥループをフォークすることによって、将来のデータを断言することができる。このことは、過去への時間トラバーサルと同様である。

ＫＩＤＳツールの仕様
ＫＩＤＳのツールセットは、ＫＩＤＳアプリケーションを構築する際にユーザを支援できると共に、基礎となるインフラストラクチャの様々な制御、すなわち、ユーザフィードバックに基づく知識の進化および新しいデータによる知識の再度特徴付けを指定することもできる。

ＫＩＤＳアプリケーションサーバ
ＫＩＤＳアプリケーションサーバは、データベースに格納されたＫＩＤＳデータ、知識およびプロセスモデルを用いて、ＫＩＤＳアプリケーションの実行をサポートすることができる。ＫＩＤＳアプリケーションサーバは、明白な出所を表す情報を伝達し、状態管理およびイベント処理をデータベースに委譲することができる。

ＫＩＤＳの最適化
ＫＩＤＳデータベースは、トランザクションのＡＣＩＤ特性をサポートするように設計されてもよい。ファクトの収集は、完全の耐久性または低下した耐久性を必要とするため、データモデルおよびタイプと共に、セキュリティ、圧縮、圧縮、タイムトラベルおよび出所などを全てサポートするデータベースサービスが必要である。耐久性は、ユーザの要求、例えば、データの全て＞ｘ％または出所の質問を回答できる十分高い精度によって制御されなければならない。また、このサービスは、高性能分類をサポートしなければならない。ＡＣＩＤ要件を緩和することによって、リソース消費を大幅に削減することができる。この目的のために、特別なデータベースを検討することができるが、全ての要件に対応できる機能を有する必要がある。したがって、一部の手法は、進化するパターンに応じて、既存のデータベースを最適化し、ハードウェアアクセラレーションを活用することを含む。

分散処理のためのＫＩＤＳサポート
いくつかの実施形態において、ＫＩＤＳは、基礎となるインフラストラクチャを活用するように、分散環境で動作することができる。

ソーシャルネットワーキングおよび個別化の統合
いくつかの実施形態において、ソーシャルネットワーキングは、ＫＩＤＳの不可欠な部分である。個別化は、特定分野に関わり、グループまたは個人の好みに基づいて知識を個別化することができる。例えば、患者介護の使用事例は、個別化の重要性を示している。

ＫＩＤＳの移行
移行サポートに関して、既存の機能を維持するために、既存のアプリケーションを続けて動作させることができるが、ＫＩＤＳモデルに基づいて、「シャドー」アプリケーションを作成することもできる。場合によって、「シャドー」アプリケーションは、クローリングすることによって、既存のシステムのデータを監視する。しかしながら、既存の技術の一部と共に、新しい機能をＫＩＤＳに実装することもできる。

Claims (12)

1. コンピュータシステムに格納されているデータの１つ以上の更新をコンピュータシステムにおいて受信するステップと、
   受信された前記更新に基づいて、コンピュータシステム内の１つ以上の多時間データ項目を更新するステップとを含み、
   前記１つ以上の多時間データ項目は、各データ項目のトランザクション時間および有効時間を含む双時間データ項目であり、前記トランザクション時間は、前記各データ項目が真であると考えられる１つ以上の時間範囲に対応し、前記有効時間は、前記各データ項目がモデル化されたシステムに対して実際に真である時間範囲に対応し、
   第１クエリが前記更新された多時間データ項目に依存するという判断に基づいて、前記コンピュータシステム内で前記第１クエリを特定するステップと、
   現在の時間に対応する多時間データを用いて、前記第１クエリの第１実行を行うステップと、
   前記第１クエリの過去実行に対応する過去時間に対応する多時間データを用いて、前記第１クエリの第２実行を行うステップと、
   前記第１クエリの前記第１実行の結果と前記第１クエリの前記第２実行の結果との差を決定するステップと、
   前記差を所定の閾値と比較するステップと、
   前記差が前記所定の閾値よりも大きいと判定した場合に、前記第１クエリに関連する第１データオブジェクトに対して第１変換処理を呼び出すステップとをさらに含み、
   前記第１変換処理は、連続データ変換ループアプリケーションの処理の一部であり、
   前記第１データオブジェクトに対する加工機能を含む変換オブジェクトの変更、または前記第１データオブジェクトに対して使用されるフィルタオブジェクトの変更に基づいて、前記連続データ変換ループアプリケーションの処理を開始するステップをさらに含む、方法。
2. コンピュータシステムに格納されているデータの１つ以上の更新をコンピュータシステムにおいて受信するステップと、
   受信された前記更新に基づいて、コンピュータシステム内の１つ以上の多時間データ項目を更新するステップとを含み、
   前記１つ以上の多時間データ項目は、各データ項目のトランザクション時間および有効時間を含む双時間データ項目であり、前記トランザクション時間は、前記各データ項目が真であると考えられる１つ以上の時間範囲に対応し、前記有効時間は、前記各データ項目がモデル化されたシステムに対して実際に真である時間範囲に対応し、
   第１クエリが前記更新された多時間データ項目に依存するという判断に基づいて、前記コンピュータシステム内で前記第１クエリを特定するステップと、
   現在の時間に対応する多時間データを用いて、前記第１クエリの第１実行を行うステップと、
   前記第１クエリの過去実行に対応する過去時間に対応する多時間データを用いて、前記第１クエリの第２実行を行うステップと、
   前記第１クエリの前記第１実行の結果と前記第１クエリの前記第２実行の結果との差を決定するステップと、
   前記差を所定の閾値と比較するステップと、
   前記差が前記所定の閾値よりも大きいと判定した場合に、前記第１クエリに関連する第１データオブジェクトに対して第１変換処理を呼び出すステップと、
   前記所定の閾値が更新されたことに基づいて、前記差を前記所定の閾値と比較するステップを動的に再実行するステップとをさらに含む、方法。
3. 前記第１変換処理は、HADOOPデータ処理クラスタの計算ノード内で実行されるデータ変換ループアプリケーションによって実行される、請求項１に記載の方法。
4. 前記第１変換処理は、機械学習プロセス、生データ処理の分類、サポートベクトルマシン、ナイーブベイズ分類器、神経ネットワーク、クラスタリング、関連ルール、決定木、単変量周期線形傾向、多変量状態推定技術、認知コンピューティング、ベイジアン信念ネットワーク、逆問題に対する解の最小二乗最適化または回帰、影響図、デンプスター・シェイファー理論、決定木、残存有効寿命の予後、スクリプト、計画、予定、ＢＰＥＬワークフロー、およびＢＰＭＮビジネスプロセスのうち、１つ以上を含む、請求項３に記載の方法。
5. 前記第１データオブジェクトに対する前記第１変換処理の結果に対応する第２データオブジェクトを格納するステップと、
   前記第２データオブジェクトと、前記第１変換処理の過去の呼び出しによって生成され且つ前記第２データオブジェクトと同一タイプの異なるデータオブジェクトとの間の差を決定するステップと、
   前記第２データオブジェクトと前記異なるデータオブジェクトとの間の前記差が第２所定の閾値よりも大きいという判定に基づいて、前記第２データオブジェクトに対して第２変換処理を呼び出すステップとを含む、請求項１に記載の方法。
6. 前記第２変換処理は、前記連続データ変換ループアプリケーションの一部であり、
   前記方法は、
   前記コンピュータシステムに格納されている前記多時間データの１つ以上の追加更新を受信するステップと、
   受信された前記追加更新に基づいて、一組の多時間データ項目を更新するステップと、
   前記多時間データの前記追加更新を用いて、前記第１クエリの第３実行を行うステップと、
   前記第１クエリの過去実行時間に対応する多時間データを用いて、前記第１クエリの第４実行を行うステップと、
   前記第１クエリの前記第３実行の結果と前記第１クエリの前記第４実行の結果との間の差を決定するステップと、
   前記差を前記所定の閾値と比較するステップと、
   前記差が前記所定の閾値よりも大きいと判定した場合に、前記第１変換処理を再度呼び出すステップとをさらに含む、請求項５に記載の方法。
7. 前記第１クエリを特定するステップは、前記コンピュータシステム内のフィルタテーブルにアクセスすることを含み、
   前記フィルタテーブルは、異なる変換処理にそれぞれ対応する複数のクエリを含む、請求項１～６のいずれかに記載の方法。
8. 前記第１クエリを特定するステップと、前記第１クエリの第１実行を行うステップと、前記第１クエリの第２実行を行うステップと、前記第１クエリの前記第１実行と前記第１クエリの第２実行との間の差を前記所定の閾値と比較するステップとは、前記１つ以上の多時間データ項目の更新として、第１トランザクションの外部で前記第１トランザクションと非同期的に実行され、
   前記第１データオブジェクトに対する前記第１変換処理の前記呼び出しは、前記第１トランザクションの外部で前記第１トランザクションと非同期的に実行される、請求項１～７のいずれかに記載の方法。
9. １つ以上のプロセッサを含む処理ユニットと、
   前記処理ユニットに連結され、前記処理ユニットによって読取可能であり、一連の命令セットを格納するメモリとを備え、前記命令は、前記処理ユニットによって実行される場合、前記処理ユニットに、以下のステップ、すなわち、
   コンピュータシシステムに格納されているデータの１つ以上の更新を受信するステップと、
   受信された前記更新に基づいて、コンピュータシステム内の１つ以上の多時間データ項目を更新するステップとを実行させ、
   前記１つ以上の多時間データ項目は、各データ項目のトランザクション時間および有効時間を含む双時間データ項目であり、前記トランザクション時間は、前記各データ項目が真であると考えられる１つ以上の時間範囲に対応し、前記有効時間は、前記各データ項目がモデル化されたシステムに対して実際に真である時間範囲に対応し、
   第１クエリが前記更新された多時間データ項目に依存するという判断に基づいて、前記コンピュータシステム内で前記第１クエリを特定するステップと、
   現在の時間に対応する多時間データを用いて、前記第１クエリの第１実行を行うステップと、
   前記第１クエリの過去実行に対応する過去時間に対応する多時間データを用いて、前記第１クエリの第２実行を行うステップと、
   前記第１クエリの前記第１実行の結果と前記第１クエリの前記第２実行の結果との差を決定するステップと、
   前記差を所定の閾値と比較するステップと、
   前記差が前記所定の閾値よりも大きいと判定した場合に、前記第１クエリに関連する第１データオブジェクトに対して第１変換処理を呼び出すステップとをさらに実行させ、
   前記第１変換処理は、連続データ変換ループアプリケーションの処理の一部であり、
   前記第１データオブジェクトに対する加工機能を含む変換オブジェクトの変更、または前記第１データオブジェクトに対して使用されるフィルタオブジェクトの変更に基づいて、前記連続データ変換ループアプリケーションの処理を開始するステップをさらに実行させる、システム。
10. １つ以上のプロセッサを含む処理ユニットと、
    前記処理ユニットに連結され、前記処理ユニットによって読取可能であり、一連の命令セットを格納するメモリとを備え、前記命令は、前記処理ユニットによって実行される場合、前記処理ユニットに、以下のステップ、すなわち、
    コンピュータシシステムに格納されているデータの１つ以上の更新を受信するステップと、
    受信された前記更新に基づいて、コンピュータシステム内の１つ以上の多時間データ項目を更新するステップとを実行させ、
    前記１つ以上の多時間データ項目は、各データ項目のトランザクション時間および有効時間を含む双時間データ項目であり、前記トランザクション時間は、前記各データ項目が真であると考えられる１つ以上の時間範囲に対応し、前記有効時間は、前記各データ項目がモデル化されたシステムに対して実際に真である時間範囲に対応し、
    第１クエリが前記更新された多時間データ項目に依存するという判断に基づいて、前記コンピュータシステム内で前記第１クエリを特定するステップと、
    現在の時間に対応する多時間データを用いて、前記第１クエリの第１実行を行うステップと、
    前記第１クエリの過去実行に対応する過去時間に対応する多時間データを用いて、前記第１クエリの第２実行を行うステップと、
    前記第１クエリの前記第１実行の結果と前記第１クエリの前記第２実行の結果との差を決定するステップと、
    前記差を所定の閾値と比較するステップと、
    前記差が前記所定の閾値よりも大きいと判定した場合に、前記第１クエリに関連する第１オブジェクトに対して第１変換処理を呼び出すステップと、
    前記所定の閾値が更新されたことに基づいて、再度、前記差を前記所定の閾値と比較するステップとをさらに実行させる、システム。
11. 請求項１～８のいずれかに記載の方法をコンピュータに実行させるためのプログラム。
12. 請求項１１に記載のプログラムを格納したメモリと、
    前記プログラムを実行するためのプロセッサとを備える、システム。

Images