JP6400191B2 - アプリケーションデータモデルに従って指定されたオブジェクトを更新するよう設計されたルールを実現する命令セットの生成 - Google Patents

Description

優先権主張
本特許出願は、全文が本明細書に援用される以下の同時係属出願に関連し、その優先権を主張する：
Ａ．２０１４年９月９日に出願された、本特許出願と同一の出願人の名義の、「金融アプリケーションのビジネスオブジェクトを更新するよう設計されたビジネスルールを実現する命令セットの生成（Generating Instruction Sets Implementing Business Rules Designed To Update Business Objects Of Financial Applications）」と題されるインド特許出願連続番号第４４２１／ＣＨＥ／２０１４号；および
Ｂ．２０１５年１月１３日に出願された、本特許出願と同一の出願人の名義の、「金融アプリケーションのビジネスオブジェクトを更新するよう設計されたビジネスルールを実現する命令セットの生成（Generating Instruction Sets Implementing Business Rules Designed To Update Business Objects Of Financial Applications）」と題される米国特許本出願連続番号第１４／５９５，２２３号。

背景
技術分野
本開示は、企業アプリケーションサーバに関し、より具体的には、アプリケーションデータモデルに従って指定されたオブジェクトを更新するよう設計されたルールを実現する命令セットの生成に関する。

関連技術
アプリケーションは、データを処理して、対応する所望の機能を提供するために使用される。金融アプリケーションは、クレジットカード、ローン、銀行口座などの金融手段の管理に関するアプリケーションのクラスである。関連技術で周知であるように、金融アプリケーションは、銀行、保険会社、証券会社などの多様なビジネス企業で使用されている。

アプリケーションは、しばしば、データモデル（「アプリケーションデータモデル」）に基づいて開発され、当該データモデルは、データを記憶するためのデータモデルとは異なっている可能性がある。例えば、データは、リレーショナルデータベースモデルに従って表の形式で記憶されてもよいのに対して、アプリケーションは、アプリケーションデータモデルに従って指定されたオブジェクト（以下、「データオブジェクト」）に基づいて開発されてもよい。データオブジェクトは、さまざまな属性を含むように定義され、データオブジェクトのインスタンス（「オブジェクトインスタンス」）は、それぞれの属性の対応する値を有する。

アプリケーションデータモデルに従って指定されたデータオブジェクトを更新するために、アプリケーションにおいてルールが利用される。ルールは、マシンが動作可能なレベル（例えば、プログラミング言語、ＳＱＬクエリなど）に近い対応するインプリメンテーションに精通していないかもしれないユーザ（例えば、管理者、マネージャ、アナリスト、経営幹部など）が理解できる概念レベルである。

データオブジェクトの更新は、当該データオブジェクトのそれぞれのオブジェクトインスタンスの１つ以上の属性の対応する値の変更を意味する。単純な事例として、銀行は、顧客の信用格付けのさまざまなレベル（高リスク、中リスクおよび低リスク）およびローンのタイプ（例えば、住宅ローン、自動車ローン、個人ローンなど）によって金利を更新するルールを有し得る。容易に理解できるように、ルールを実行することにより、複数のオブジェクトインスタンスが変更される。一般に、複雑なルールは、いくつかのより多くの変数／次元、複数の属性の更新、および／または、更新された属性の値の複雑な計算を伴う。

ルールは、マシンでの実行にとってより適切な等価の命令セットに変換される。例えば、データオブジェクトがリレーショナルデータベースシステムに記憶されるとすると、命令セットは、リレーショナルデータベースシステムの表に向けられるＳＱＬ（構造化照会言語）クエリを含む。

本開示の局面は、アプリケーションデータモデルに従って指定されたオブジェクトを更新するよう設計されたルールを実現する命令セットを生成することに向けられる。

以下で簡単に説明する添付の図面を参照して、本開示の例示的な実施例について説明する。

図中、同様の参照番号は、一般に、同一の要素、機能的に類似した要素、および／または、構造的に類似した要素を示す。要素が最初に登場する図面は、対応する参照番号における最上位桁によって示される。

本開示のいくつかの局面を実現できる例示的な環境を示すブロック図である。 本開示の局面に従った、アプリケーションデータモデルに従って指定されたオブジェクトを更新するよう設計されたルールを実現する命令セットが生成される態様を示すフローチャートである。 一実施例における、実行のためにルールが指定される態様を示す。 一実施例における本開示のいくつかの局面に従った、ルールが処理される態様を示す。 一実施例における、併合に適していると判断されたルールのサブセットが表示される態様を示す。 一実施例における、ルールのサブセットの併合結果がユーザに表示される態様を示す。 適切なソフトウェア命令の実行によって本開示のいくつかの局面が機能するデジタル処理システムの詳細を示すブロック図である。

例示的な実施例の説明
１．概要
本開示の局面では、アプリケーションデータモデルに従って指定されたオブジェクトを更新するよう設計されたルールを実現する命令セットを生成する。一実施例では、オブジェクトを更新するよう設計されたルールは、各バケットが実行順序の点で相互依存性をもたないルールを含むように（ルールの）バケットのセットを形成するように処理される。次いで、各バケットについて、共通の（データ）オブジェクトを更新するよう設計されたルールのサブセットが決定され、各々の決定されたルールのサブセットについて、対応する単一の命令セットが生成される。次いで、各バケットに含まれるルールのサブセットについて生成された命令セットは、同時に実行される。

共通のオブジェクトを更新するルールの各サブセットについて、（例えば、最終的に単一のＳＱＬクエリに変換される）単一の命令セットを生成することによって、このような共通のオブジェクトがバケットのルールの処理に必要とされる合計時間を短縮することができる。このような更新中は（例えば、データベース内の表／列のロッキングを使用して）排他的アクセスがオブジェクトに提供されるものとすると、排他的アクセスの時間もそれに従って短縮され、それによって、他のアプリケーションが当該オブジェクトへの排他的アクセスを必要とする状態での同一のオブジェクトに対する相反する競合の確率が減少する。また、バケット内のルールに対応する命令セットを同時に実行することによって、少なくとも基礎をなす環境が十分なマルチプロセッシング機能を提供する場合に同様の効率を得ることができる。

本開示の別の局面によれば、バケット内で決定されたルールのサブセットは、ルールのサブセットの各々を併合できる（すなわち、単一の命令セットを生成できる）ことを示しながら、表示のために送信される。したがって、ルールのサブセットに対応する命令セットの生成は、ルールのサブセットの各々が併合対象であることを示す入力データがユーザから受信された場合にのみ、実行される。

したがって、（アプリケーションの）ユーザは、併合対象の特定のサブセット（および生成される単一の命令セット）を示し、どのサブセットが併合されないか（すなわち、各ルールごとの個々の命令セットが生成される）を示すことが容易になる。したがって、ルールのサブセットにおける特定のルールが併合から除外されることを、（ユーザから受信される）入力データが示す場合、当該ルールのサブセットについての対応する単一の命令セットは、当該特定のルールを除外して（すなわち、サブセットにおける他のルールについてのみ）生成される。その結果、ユーザは、ルールの併合に対する制御を向上させることができる。

本開示の１つ以上の局面によれば、各ルールの実行に先立って実行されるべきである対応するルールのセットを示す優先データが受信される。したがって、バケットは、対応するルールのセットが、ルールを含む同一のバケットに含まれないように形成される（なぜなら、当該ルールは、実行のための対応するルールのセットに対する依存性を有するからである）。

本開示のさらに別の局面によれば、アプリケーションデータモデルに従って指定されたオブジェクトは、リレーショナルデータベースサーバに記憶される。したがって、各ルールは、独立して実行されると、リレーショナルデータベースサーバに向けられる対応するＳＱＬ（構造化照会言語）コマンドとして実現されるであろう。また、対応する単一の命令セットは、リレーショナルデータベースサーバに向けられる単一のＳＱＬコマンドの形式で実現される。したがって、サブセットにおけるルールに対応して実行されるであろうさまざまなＳＱＬコマンドは、単一のＳＱＬコマンドに置換される。

例示のために、例を参照して本開示のいくつかの局面について以下で説明する。しかし、本開示は、具体的な詳細のうちの１つ以上がなくても、または他の方法、構成要素、材料などによっても実施できることを当業者は認識するであろう。他の例では、本開示の特徴を曖昧にすることを回避するために、周知の構造、材料またはオペレーションは詳細に示されていない。さらに、記載されている特徴／局面は、さまざまな組み合わせで実施できるが、簡潔にするために当該組み合わせの一部のみが本明細書に記載されている。

２．例示的な環境
図１は、本開示のいくつかの局面を実現できる例示的な環境を示すブロック図である。当該ブロック図は、エンドユーザシステム１１０Ａ〜１１０Ｚと、インターネット１２０と、イントラネット１３０と、サーバシステム１４０Ａ〜１４０Ｃと、管理者システム１５０と、データストア１８０Ａ〜１８０Ｂとを含むものとして示されている。

単に例示のために、典型的な数／タイプのシステムが図に示されているに過ぎない。環境が設計される目的に応じて、多くの環境は、数の点でもタイプの点でも、より多くのシステムを含んでいることが多い。図１の各システム／装置について以下でさらに詳細に説明する。

イントラネット１３０は、（点線の境界線によって示される）企業内に設けられるサーバシステム１４０Ａ〜１４０Ｃと管理者システム１５０とデータストア１８０Ａ〜１８０Ｂとの間の接続を提供するネットワークを表わす。インターネット１２０は、エンドユーザシステム１１０Ａ〜１１０Ｚなどの外部システムとのこれら（および企業の他のシステム）の接続を拡張する。イントラネット１４０およびインターネット１２０の各々は、関連技術で周知の伝送制御プロトコル（Transmission Control Protocol：ＴＣＰ）および／またはインターネットプロトコル（Internet Protocol：ＩＰ）などのプロトコルを使用して実現されてもよい。一般に、ＴＣＰ／ＩＰ環境では、トランスポートの基本単位としてＩＰパケットが使用され、パケットの発生源のソースシステムに割り当てられるＩＰアドレスにソースアドレスが設定され、パケットが最終的に送達される宛先システムのＩＰアドレスに宛先アドレスが設定される。

ＩＰパケットは、パケットの宛先ＩＰアドレスが宛先システムのＩＰアドレスに設定されると宛先システムに向けられ、その結果、パケットがネットワーク１２０および１３０によって最終的に宛先システムに送達されると考えられる。パケットは、宛先アプリケーションを指定するポート番号などのコンテンツを含む場合には、このようなアプリケーションにも向けられると考えることができる。宛先システムは、対応するポート番号を利用可能／オープンなままにして、対応する宛先ポートを用いてパケットを処理しなければならないであろう。インターネット１２０およびイントラネット１３０の各々は、有線または無線媒体の任意の組み合わせを使用して実現されてもよい。

データストア１８０Ａ〜１８０Ｂの各々は、サーバシステム１４０Ａ〜１４０Ｃおよび管理者システム１５０などの企業の他のシステムで実行される（金融アプリケーション、分析フレームワークなどの）企業アプリケーションによるデータの集合体の記憶および検索を容易にする不揮発性（永続的）ストレージを表わす。

データストア１８０Ａ〜１８０Ｂの各々は、リレーショナルデータベース技術を使用するデータベースサーバとして実現され、したがって、ＳＱＬ（構造化照会言語）などの構造化クエリを使用してデータの記憶および検索を行ってもよい。代替的に、データストア１８０Ａ〜１８０Ｂの各々は、関連技術で周知であるように、１つ以上のディレクトリとして編成されるファイルの形式でデータの記憶および検索を行うファイルサーバとして実現されてもよい。

一実施例では、データストア１８０Ａ〜１８０Ｂに維持されるデータに対しては、背景欄に上記したように、データオブジェクト、属性およびオブジェクトインスタンスを含む、（データストアの外部に設けられる）アプリケーションデータモデルに従ってアクセスが提供される。データオブジェクトは、リレーショナルデータベースシステムに記憶される場合には１つ以上の表に対応し得て、各属性は、このような表のそれぞれの列に対応し、各オブジェクトインスタンスは、このような表における行に対応する。各データオブジェクトは、ファイルサーバに記憶される場合には１つ以上のファイルに対応し得て、各オブジェクトインスタンスは、ファイル内の行のセットによって表わされ、各行はさらに、属性および対応する値を指定する。

エンドユーザシステム１１０Ａ〜１１０Ｚの各々は、企業の特定のシステムに向けられるユーザ要求を生成して送信するためにユーザによって使用される、パーソナルコンピュータ、ワークステーション、移動端末、携帯電話、コンピューティングタブレットなどのシステムを表わす。ユーザ要求は、適切なユーザインターフェイス（例えば、企業内で実行されるアプリケーションによって提供されるウェブページ）を使用して生成されてもよい。例えば、ユーザは、サーバシステム１４０Ａ〜１４０Ｃで実行される企業アプリケーションに対してさまざまなタスクを実行するためのユーザ要求を送信してもよい。

サーバシステム１４０Ａ〜１４０Ｃの各々は、エンドユーザシステム１１０Ａ〜１１０Ｚを使用するユーザによって要求されるタスクを実行することができる（金融アプリケーション、分析フレームワークなどの）企業アプリケーションを実行する、ウェブ／アプリケーションサーバなどのサーバを表わす。エンドユーザシステムから要求を受信したことに応答して、各サーバシステムは、当該要求に規定されるタスクを実行し、タスクの実行結果を、要求を行ったエンドユーザシステムに送信する。各サーバシステムは、内部に（例えば、サーバ内の不揮発性ストレージ／ハードディスクに）記憶されたデータ、（例えば、データストア１８０Ａ〜１８０Ｂに維持される）外部データ、および／または、このようなタスクを実行する際に外部ソースから（例えば、ユーザから）受信されるデータを使用し得る。

管理者システム１５０は、サーバシステム１４０Ａ〜１４０Ｃで実行されるさまざまな企業アプリケーションによってアクセスされる対応するデータをユーザが管理（作成、更新、削除）することを容易にする、ウェブ／アプリケーションサーバなどのサーバを表わす。一実施例では、管理者システム１５０で実行される分析フレームワークは、アプリケーションデータモデルに従って指定されたオブジェクトを更新するためのルールをユーザが指定することを容易にし、当該フレームワークは、次いで、当該ルールを、データストア１８０Ａ〜１８０Ｂのインプリメンテーションに適切であるように対応する命令セット（例えば、ＳＱＬクエリ）に変換する。このような分析フレームワークの一例は、本願の所期の譲受人であるオラクル社から入手可能なオラクル金融サービス分析アプリケーション（Oracle Financial Services Analytical Applications：ＯＦＳＡＡ）である。

ある従前のアプローチでは、分析フレームワークは、各ルールを対応する命令セットに変換する（すなわち、命令セットの数は、ルールの数に等しい）。したがって、最適な（より少ない）数の命令セットが所与のルールのセットについて生成されることが望ましい。本開示のいくつかの局面に従って拡張される管理者システム１５０は、例を用いて以下で説明するように、アプリケーションデータモデルに従って指定されたオブジェクトを更新するよう設計されたルールを実現するこのような最適な命令セットの生成を容易にする。

３．ルールを実現する命令セットの生成
図２は、本開示の局面に従った、アプリケーションデータモデルに従って指定されたオブジェクトを更新するよう設計されたルールを実現する命令セットが生成される態様を示すフローチャートである。当該フローチャートは、単に例示のために、図１、特に管理者システム１５０に関して記載されている。しかし、本明細書において提供されている開示を読むことによって当業者に明らかであるように、特徴のうちの多くは、本開示のいくつかの局面の範囲および精神から逸脱することなく、他の環境でも（場合によっては、他のタイプのシステム／サーバを使用しても）実現可能である。

また、当業者に明らかであるように、ステップのうちのいくつかは、特定の環境に適合させるように、以下に示されるシーケンスとは異なるシーケンスで実行されてもよい。このようなインプリメンテーションの多くは、本開示のいくつかの局面によって包含されるよう意図される。フローチャートはステップ２０１から開始し、制御は直ちにステップ２１０に進む。

ステップ２１０において、管理者システム１５０は、アプリケーションデータモデルに従って指定されたデータオブジェクトを更新するよう設計されたルールを受信する。したがって、各ルールは、オペレータとオペランドとを含み、オペランドのうちの少なくとも１つは、データオブジェクトまたは対応する属性である。ルールは、エンドユーザシステム１１０Ａ〜１１０Ｚのうちの１つを使用するユーザから受信されてもよい。

ステップ２２０において、管理者システム１５０は、各バケットにおけるルールが実行順序の点で相互依存性をもたないようにルールのバケットを形成する。相互依存性は、当該実行順序で先立つルールの実行が完了して初めて後続のルールの実行が開始することを求められる場合に存在すると考えられる。このような相互依存性がない場合、両方のルールは場合によっては同時に実行可能である。

以下で説明する実施例では、ユーザは、優先データ／順序付け（すなわち、所与のルールを実行するためにどの先立つルールを完了させなければならないかということの手動表示）を指定するが、このようなまたは他の依存性は、各ルールについて指定される入力および出力を調べることによって推測されてもよい。このようなシナリオでは、管理者システム１５０は、先立つルールが、所与のルールを含むバケットに確実に含まれないようにする。

ステップ２３０において、管理者システム１５０は、ステップ２２０において形成された１つ以上のバケットからバケットを選択する。特に、（以下で説明するステップ２４０〜２７０に従って）ルールが未処理のバケットが選択される。このような未処理のバケットの選択は、公知の方法で実行されてもよい。例えば、各バケットは、対応するバケットが処理済みである（第１の値）か未処理である（第２の値）かを示すフラグに関連付けられてもよい。したがって、管理者システム１５０は、フラグが第２の値に設定されるバケットを選択することができる。

ステップ２４０において、管理者システム１５０は、選択されたバケットの各ルールによって更新されるデータオブジェクト（および対応する属性）を識別する。更新されるデータオブジェクトの識別は、分析フレームワークによって維持されるメタデータを調べることによって決定されてもよい。

ステップ２５０において、管理者システム１５０は、同一のデータオブジェクトを更新するルールのサブセットを決定する。言い換えれば、同一のデータオブジェクトを更新するバケットにおけるルールは、同一のサブセットに含まれる。実施例では、決定されたルールのサブセットは、ルールのサブセットの各々を併合できる（すなわち、単一の命令セットを生成できる）ことを示しながら、（エンドユーザシステム１１０Ａ〜１１０Ｚのうちの１つに関連付けられる）ディスプレイユニットでの表示のために送信される。ユーザは、併合対象の特定のサブセットおよび／または各サブセットにおける特定のルールを選択することが可能になる。全てのルールのサブセットが併合対象であることを示す入力データがユーザから受信されるものとして説明を続ける。

ステップ２６０において、管理者システム１５０は、ルールの各サブセットについて単一の命令セットを生成する。サブセットについて生成される単一の命令セットは、（当該サブセットに対応する）データオブジェクトの属性の、（サブセットにおけるルールによって決定される）値の更新を実行するよう設計される。実施例では、単一の命令セットは、単一のＳＱＬステートメントとして、例えば更新のために複数の列を有する「ＭＥＲＧＥ」ステートメントとして形成される。

ステップ２７０において、管理者システム１５０は、同時実行のために、（さまざまなルールのサブセットについて生成された）さまざまな命令セットをマークする。言い換えれば、ステップ２５０において４つのルールのサブセットが形成されると、対応する４つの命令セットを同時に実行することができる。

ステップ２８０において、管理者システム１５０は、処理すべきより多くのバケットがあるか否か（すなわち、どのフラグが第２の値に設定されるか）を確認する。このような確認に先立って、管理者システム１５０は、まず、選択されたバケットが処理済みであることを示すために、選択されたバケットに関連付けられるフラグを第１の値に設定する。より多くのバケットがある場合、制御はステップ２３０に進んで（まだ未処理の）新たなバケットが選択される。そうでなければ（全てのバケットが処理された後）、制御はステップ２９９に進む。フローチャートは、ステップ２９９で終了する。

したがって、所与のルールのセットのうちのどれを組み合わせて単一の命令セットにすることができるかを識別することによって、データオブジェクトを更新するよう設計された所与のルールのセットについて最適な命令セットを生成することができる。さらに、（高い概念レベルで操作を行うマネージャなどの）ユーザが併合対象の特定のルールを選択できるようにすることによって、データオブジェクトの基本的なインプリメンテーションではなくビジネス／金融上の検討事項に基づいてルールの選択を実行できるということが理解できる。

図２に従って管理者システム１５０が命令セットの生成を実行することができる態様について、例を用いて以下で説明する。

４．例示的な例
図３Ａ〜図３Ｂおよび図４Ａ〜図４Ｂは、ともに、一実施例における、アプリケーションモデルに従って指定されたオブジェクトを更新するよう設計されたルールを実現する命令セットが生成される態様を示す。図の各々について以下で詳細に説明する。

図３Ａは、一実施例における、実行のためにルールが指定される態様を示す。例示のために、当該ルールは、（行と列とを有する）表の形式で指定されるものとして示されている。しかし、代替的な実施例では、当該ルールは、適切なユーザインターフェイスを使用して、任意の都合のよい態様で指定されてもよい。ルールを指定するための例示的なユーザインターフェイスは、「データベースに記憶されたデータ項目のグループ分けの簡略化（SIMPLIFYING GROUPING OF DATA ITEMS STORED IN A DATABASE）」と題される米国特許第８，８５６，１２６号に詳細に記載されている。

したがって、表３１０は、エンドユーザシステム１１０Ａ〜１１０Ｚのうちの１つを使用するユーザによって分析フレームワークに規定される、（データオブジェクトを更新するよう設計された）ルールのセットを示す。列３１１（「ルールＩｄ」）は、ルールの固有の識別子（Ｒ１，Ｒ２など）を指定し、列３１２（「階層／ドメイン」）は、ルールによって入力として使用される対応する値のセット（Ｈ１，Ｈ２などと称される）を指定し、列３１３（「程度／範囲」）は、ルールによって更新されるＭ１，Ｍ２などの（さまざまなデータオブジェクトの）属性を指定する。

各々の階層／ドメインは、データオブジェクトの属性に記憶できる対応する可能な値のセットを表わす。可能な値は、当該技術分野で周知のツリーデータ構造の形式で編成される。各々の程度は、関連付けられる計算のセットを実行した結果として更新される（データオブジェクトにおける）対応する１つ以上の属性を表わす。データオブジェクトがリレーショナルデータベースシステムに記憶される場合、各々の階層は、データベースシステム内の列に記憶できる可能な値を表わし、各々の程度は、データベースシステム内の（表の）列を表わす。

表３１０の行の各々は、企業アプリケーションのデータオブジェクトを更新するために利用される対応するルールを指定する。一般に、各ルールは、階層／ドメインの値（列３１２への入力）のさまざまな組み合わせについて、対応する計算を指定し、当該計算の結果として生じる値は、（列３１３における）程度／範囲に記憶される。例えば、行３１８は、「Ｒ３」という名前によって固有に識別されるルールが、階層Ｈ４およびＨ５における値のさまざまな組み合わせについて、対応する計算を指定し、当該計算の結果として生じる値が程度Ｍ４において更新されることを示す。同様に、他の行は、対応するルールの詳細を指定する。

表３２０は、典型的には分析フレームワークの開発者／管理者によって分析フレームワークに規定される程度のセットを示す。列３２１（「程度Ｉｄ」）は、程度の固有の識別子（Ｍ１，Ｍ２など）を指定し、列３２２（「オブジェクト」）および３２３（「属性」）は、程度によって表わされる対応するデータオブジェクトおよび属性を指定する。

表３２０の行の各々は、分析フレームワークに規定されるルールによって更新され得る対応する程度を指定する。例えば、行３２８は、（行３１８によって示されるルールＲ３によって更新される）程度Ｍ４が、データオブジェクトＢ１に含まれる属性Ａ５およびＡ６に対応することを示す。同様に、他の行は、分析フレームワークにおいて使用される対応する程度の詳細を指定する。

表３３０は、分析フレームワークにおいて実行定義の一部として定義されるプロセスのセットを示す。実行定義は、（シーケンシャルな順序で実行される）プロセス／ステップのシーケンスの形式で指定されるアプリケーションプロセスフローを表わす。ユーザは、分析フレームワークによって提供される（ルールなどの）１つ以上のコンポーネントを実行定義におけるプロセスとして示してもよい。以下の説明では、実行定義のさまざまなプロセスは、ルールのみを示すものとする。

したがって、表３３０は、エンドユーザシステム１１０Ａ〜１１０Ｚのうちの１つを使用するユーザによって分析フレームワークに規定されるプロセスステップのセットを示す。列３３１（「プロセスＩｄ」）は、プロセスステップのためのプロセスの識別子（Ｐ１，Ｐ２など）を指定する。なお、複数の行に規定される対応するプロセスステップが同一のプロセスの一部であることを示すために、同一のプロセス識別子が複数の行において繰返されてもよい。列３３２（「ルールＩｄ」）は、プロセスステップとして実行されるルールの識別子を指定し、列３３３（「優先度」）は、対応するプロセスステップに規定されるルールを実行するためにどの先立つルールを完了しなければならないかを示す。先立つルールの欠如（記号「−」によって示される）は、ルール（Ｒ１，Ｒ２，Ｒ３など）を同時に実行できることを意味する。

表３３０の行の各々は、プロセス（Ｐ１，Ｐ２）のシーケンスを指定し、各プロセスは、対応するルールのセットを実行するために示される。例えば、プロセスＰ１は、対応するプロセスステップとしてルールＲ１，Ｒ２，Ｒ４，Ｒ６，Ｒ３，Ｒ５およびＲ９を実行するために、（列３３１における同一の識別子Ｐ１に基づいて）示される。ルールのうちのいくつかは、先立つルールに対して相互依存性を有するものとして（列３３３に）示され、これは、１つ以上の先立つルールの実行が完了して初めてルールの実行が開始されることを意味する。例えば、行３３８は、ルールＲ４がルールＲ２に対して相互依存性を有することを示し、ルールＲ２の実行が完了して初めてルールＲ４の実行を開始できることを意味する。

上記のシーケンスおよび優先度はルール間の実行順序を徹底する、ということが理解できる。本明細書における開示では、ユーザは、相互依存性を生じさせ得るさまざまな条件を調べて、ルール間に存在する条件に従ってシーケンスを指定するものとする。例えば、ユーザは、２つのルールが、同一のデータオブジェクトにおける同一の属性にマッピングされる程度を更新するか否かを調べ、それに従って、当該２つのルール間に相互依存性が存在することを指定してもよい。代替的な実施例では、実行順序の点でのこのような相互依存性は、各ルールによって更新されるさまざまな程度を検証することによって管理者システム１５０によって判断されてもよい。

したがって、ユーザは、アプリケーションデータモデルに従って指定されたオブジェクトの属性に対応する所望の程度、程度（および対応してデータオブジェクトの属性）を更新するためのルール、ならびに所望の実行順序に従って実行されるルールのシーケンスを指定する実行定義を指定することが可能になる。ユーザがルールを指定した態様は、例を用いて以下で説明するように、最適な命令セットを生成するように管理者システム１５０によって処理されてもよい。

５．処理ルール
図３Ｂは、一実施例における、ルールが処理される態様を示す。特に、プロセスＰ１について図３Ａで指定されたルールの処理が図３Ｂに示され、以下で詳細に説明する。

管理者システム１５０は、表３３０の実行定義を受信したことに応答して、まず、各バケットにおけるルールが実行順序の点で相互依存性をもたないようにプロセスＰ１のためのルールのバケットを形成する。一般に、列３３３の優先データに（記号「−」によって）示される、先立つルールを持たないルールは、共通のバケットにグループ分けされる。次いで、優先データに示される、先立つルールを有するルールはいずれも、先立つルールが属しているバケットに基づいて、他のバケットにグループ分けされる。特に、先立つルールは、グループ分けされているルールと同一のバケットには含まれない。

表３４０は、受信した実行定義（表３３０）のプロセスＰ１におけるルールのために形成されるバケットのセットを指定する。各々のバケット（♯１，♯２など）は、ルールの対応するグループ／セット（｛Ｒ１，Ｒ２，Ｒ３，Ｒ９｝および｛Ｒ４，Ｒ５，Ｒ６｝など）を含むものとして示されている。なお、バケット♯１は、（表３３０に「−」によって示される）優先ルールを持たないルールから形成される。他のルールＲ４，Ｒ５およびＲ６は、バケット♯２にグループ分けされるものとして示されている。なぜなら、当該ルールは全て、同一のバケット♯１に属する対応する優先ルールを有しているからである。

その後、管理者システム１５０は、ルールの各バケットを処理し得る。表３５０および３５５はともに、バケット♯１におけるルールが処理される態様を示し、表３６０および３６５はともに、バケット♯２におけるルールが処理される態様を示す。バケット♯１におけるルールが処理される態様について以下で詳細に説明する。

管理者システム１５０は、まず、バケット♯１における各ルールによって更新されるデータオブジェクト（および属性）を識別する。識別は、まず、表３１０に基づいて、各ルールによって更新される程度を識別し、その後、表３２０に基づいて、更新された程度に対応する特定の属性／データオブジェクトを決定することによって実行されてもよい。表３５０は、バケット♯１におけるルール（すなわち、｛Ｒ１，Ｒ２，Ｒ３，Ｒ９｝）について管理者システム１５０によって識別されるデータオブジェクト（Ｂ１およびＢ２）ならびに対応する属性（Ａ１，Ａ２など）を示す。

次いで、管理者システム１５０は、同一のデータオブジェクトを更新するルールのサブセットを決定する。表３５５は、バケット♯１について決定されたさまざまなルールのサブセットを示す。ルールＲ１，Ｒ３およびＲ９は、これらのルールが全て同一のデータオブジェクトＢ１を更新するので第１のサブセットに含まれるように示されており、ルールＲ２は、ルールＲ２が異なるデータオブジェクトＢ２を更新するので第２のサブセットに含まれるように示されていることが分かる。

次いで、管理者システム１５０は、ルール｛Ｒ１，Ｒ３，Ｒ９｝について単一の命令セットを生成し、ルール｛Ｒ２｝について別の命令セットを生成する。同様に、管理者システム１５０は、バケット♯２におけるルール（すなわち、｛Ｒ４，Ｒ５，Ｒ６｝）を（表３６０および３６５に示されるように）処理し、サブセット｛Ｒ４，Ｒ６｝および｛Ｒ５｝についてそれぞれの命令セットを生成する。プロセスＰ１について決定される４つのルールのサブセットに対応して、命令セットが４つだけ生成されることが分かる。これは、上記の従前のアプローチにおいて（プロセスＰ１における７つのルールに対応して）生成されたであろう７つの命令セットとは対照的である。

表３８０は、決定されたルールのサブセットが実行定義の一部としてユーザに提供される態様を示す。表３８０は表３３０と同様であり、したがって、簡潔にするために共通の要素の説明はここでは繰返さない。ルールの各サブセットは、実行定義における対応するプロセス（Ｐ１，Ｐ２）のもとでのサブプロセス（Ｓ１１，Ｓ１２，Ｓ２１など）として示されていることが分かる。各々のサブプロセスは、管理者システム１５０によってサブセット内にあるように決定されるさまざまなルールを含むように示されている。例えば、サブプロセスＳ１１は、（表３５５に示される）バケット♯１について管理者システム１５０によって決定されたルールのサブセット｛Ｒ１，Ｒ３，Ｒ９｝に対応する。

一実施例では、管理者システム１５０は、サブプロセスの一部として指定されるさまざまなルールについて単一の命令セットを生成する。したがって、併合対象である決定されたルールのサブセットは、対応するサブプロセスとして表３８０に示される。しかし、代替的な実施例では、サブプロセスは、単にサブセットを視覚的に表わすために使用されてもよい。次いで、管理者システム１５０は、さまざまなサブセットに属するルールを示すさらなるデータ（例えば、サブセットを示す番号）を記憶し、それに従って、当該さらなるデータに基づいて単一の命令セットを生成し得る。

本開示の局面に従って、決定されたルールのサブセットは、例えばエンドユーザシステム１１０Ａ〜１１０Ｚのうちの１つに関連付けられるディスプレイユニット（図１には図示せず）上でユーザに表示される。ルールのサブセットの併合（単一の命令セットの生成）は、（対応するサブセットの）このような併合が実行される予定であることを示す、（ユーザから受信される）入力データに応答して初めて実行される。管理者システム１５０が決定されたサブセットを表示して、（エンドユーザシステム１１０Ａ〜１１０Ｚを使用する）ユーザから入力データを受信し得る態様について、例を用いて以下で説明する。

６．併合のためのルールの表示
図４Ａは、一実施例における、併合に適していると判断されたルールのサブセットがユーザに表示される態様を示す。本明細書における例示的な環境は銀行／金融アプリケーションに対応するが、本明細書に記載されている特徴は、同様のアーキテクチャを利用する他の環境にも適用可能である。

表示領域４００は、エンドユーザシステム１１０Ａ〜１１０Ｚのうちの１つ（例示のために１１０Ａであると想定される）に関連付けられるディスプレイユニット（図１には図示せず）に設けられたユーザインターフェイスの一部を示す。一実施例では、表示領域４００は、管理者システム１５０によって提供されるそれぞれのウェブページを表示するブラウザに対応する。ウェブページは、エンドユーザシステム１１０Ａにおけるブラウザを使用してユーザが（例えば、対応するＵＲＬを指定することによって）適切な要求を送信したことに応答して提供される。

特に、表示領域４００のユーザインターフェイスは、ユーザ／マネージャがプロセス／実行定義の詳細を閲覧する（および編集する）ことを容易にする。表示領域４１０は、プロセス定義の名前、タイプ、バージョンなどの詳細を提供する。表示領域４２０は、プロセス定義の一部として指定されるプロセスステップの階層を示す。特に、表示領域４２０は、プロセスが「Ｎｏｎ−Ｓｅｃ移行前ＲＷＡ−ＥＬ」および「Ｎｏｎ−Ｓｅｃ移行前ＲＷＡ−ＵＬ」と称される２つのステップを含むことを示す。

表示領域４３０は、プロセス定義に規定されるプロセスステップの各々の詳細を指定する。特に、表示領域４３０は、（表示領域４２０のものと同一の）各オブジェクト／プロセスステップの固有の識別子、（対応するステップの実行前にどの先立つステップ／オブジェクト／ルールを実行すべきかを示す）オブジェクトの優先度、およびオブジェクトのタイプを示す。オブジェクトもプロセスステップも、そのオブジェクトタイプは計算ルールであるように示されていることが分かる。

２つのオブジェクト／ルールのサブセットを併合できる（および単一の命令セットを生成できる）ことを示しながら、（対応するチェック欄を選択することによって）両方のオブジェクトが選択されるように示されていることがさらに分かる。なお、代替的な実施例では、併合できる特定のルールのサブセットを示すために、（同一の色、フォントの使用などの）任意の適切な視覚的強調が使用されてもよい。例えば、併合できないルールは全て、共通の色で表示されてもよく、ルールの各サブセットは、（当該共通の色とは異なる）対応する固有の色で表示されてもよい。

したがって、ユーザは、表示領域４００のユーザインターフェイスを使用して、併合対象の特定のサブセットを示すことが可能になる。例えば、ユーザは、（対応するチェック欄の選択を解除することによって）サブセットにおけるルールを除外してもよい。また、ユーザは、サブセットにおける他のルールによって更新される共通のデータオブジェクトを特定のルールが更新しないことに鑑みて、当該特定のルールがルールのサブセットに含まれないことに、（サブセットの表示／視覚的強調に基づいて）気付くことができる。したがって、ユーザは、特定のルールを修正して、（共通のデータオブジェクトを更新する）修正ルールを形成し、次いで、当該修正ルールがサブセットに含まれ（および表示領域４３０に表示され）るようにサブセットの決定を実行することができる。

ユーザは、併合対象のサブセットを選択した後、「併合ルール」リンク／ボタン４５０をクリック／選択して、選択されたルールのサブセット（ここでは、「Ｎｏｎ−Ｓｅｃ移行前ＲＷＡ−ＥＬ」および「Ｎｏｎ−Ｓｅｃ移行前ＲＷＡ−ＵＬ」）が併合対象であることを示す。これに応答して、管理者システム１５０は、（ユーザから受信される入力データによって、表示領域４３０に）併合対象であるように示されるルールのサブセットの各々に対応するサブプロセスを作成する。次いで、管理者システム１５０は、以下で詳細に説明するように、作成されたサブプロセスをユーザに表示し得る。

図４Ｂは、一実施例における、ルールのサブセットの併合結果がユーザに表示される態様を示す。特に、図４Ｂは、図４Ａにおける「併合ルール」リンク４５０をユーザがクリックしたことに応答した結果を示す。

表示領域４７０は、対応するルールのサブセットの併合後のプロセスステップの階層を示す。表示領域４７０は、「併合後Ｅｘｅサブプロセス」と称される新たなプロセスステップが作成され、当該新たなプロセスステップの下に、「Ｎｏｎ−Ｓｅｃ移行前ＲＷＡ−ＥＬ」および「Ｎｏｎ−Ｓｅｃ移行前ＲＷＡ−ＵＬ」という以前の２つのステップが表示されることを示すことが分かる。表示領域４８０は、「併合後Ｅｘｅサブプロセス」という新たなプロセスステップが（タイプによって示されるように）サブプロセスであることを示す。

したがって、ユーザは、プロセス定義のさまざまなサブプロセスの形式でルールのサブセットの併合結果が表示される。その後、ユーザは、「保存」ボタン４９０をクリック／選択し得て、併合対象のさまざまなルールのサブセットを含むプロセス定義がプロセス定義の一部として保存／記憶されることを示す。（図４Ｂの）保存されたプロセス／実行定義を実行したことに応答して、管理者システム１５０は、「併合後Ｅｘｅサブプロセス」というプロセスステップについて単一の命令セットを生成し、次いで、対応する計算に基づいて特定の程度を更新するように（他の単一の命令セットと同時に）当該単一の命令セットを実行する。

一実施例では、企業アプリケーションによって使用されるデータオブジェクトは、リレーショナルデータベースサーバに記憶される。したがって、各ルールは、独立して実行されると、リレーショナルデータベースサーバに向けられる対応するＳＱＬ（構造化照会言語）コマンドとして実現される。付表Ａは、「Ｎｏｎ−Ｓｅｃ移行前ＲＷＡ−ＥＬ」というルールが独立して実行される場合に管理者システム１５０によって生成および実行され得るＳＱＬコマンドを示す。同様に、付表Ｂは、「Ｎｏｎ−Ｓｅｃ移行前ＲＷＡ−ＵＬ」というルールのために生成され得るＳＱＬコマンドを示す。単一の命令セットも、実行時に、リレーショナルデータベースサーバに向けられる単一のＳＱＬコマンドの形式で実現される。付表Ｃは、「併合後Ｅｘｅサブプロセス」という併合されたルール／サブプロセスのサブセットについての単一の命令セットとして生成され得るＳＱＬコマンドを示す。次いで、ＳＱＬコマンドが実行され、概要欄に上記した効率のうちの１つ以上が場合によっては実現される。

上記の特徴は、ハードウェア、実行可能なモジュールおよびファームウェアのうちの１つ以上の所望の組み合わせとしてさまざまな実施例において実現可能であるということがさらに理解されるべきである。実行可能なモジュールにおける命令が実行されたときにさまざまな特徴が機能する実施例に関して説明を続ける。

７．デジタル処理システム
図５は、適切なソフトウェア命令の実行によって本開示のいくつかの局面が機能するデジタル処理システム５００の詳細を示すブロック図である。デジタル処理システム５００は、管理者システム１５０に対応する。

デジタル処理システム５００は、（中央処理装置（central processing unit：ＣＰＵ）５１０などの）１つ以上のプロセッサと、ランダムアクセスメモリ（random access memory：ＲＡＭ）５２０と、二次メモリ５３０と、グラフィックスコントローラ５６０と、ディスプレイユニット５７０と、ネットワークインターフェイス５８０と、入力インターフェイス５９０とを含み得る。ディスプレイユニット５７０以外のコンポーネントは全て、通信経路５５０を介して互いに通信することができ、当該通信経路５５０は、関連技術で周知であるようにいくつかのバスを含み得る。図５のコンポーネントについて以下でさらに詳細に説明する。

ＣＰＵ５１０は、本開示のいくつかの特徴を提供するように、ＲＡＭ５２０に記憶された命令を実行し得る。ＣＰＵ５１０は、複数の処理ユニットを含んでいてもよく、各処理ユニットは、場合によっては、特定のタスク向けに設計される。代替的に、ＣＰＵ５１０は、単一の汎用処理ユニットのみを含んでいてもよい。ＲＡＭ５２０は、通信経路５５０を使用して二次メモリ５３０から命令を受信し得る。

ＲＡＭ５２０は、共有環境５２５および／または（金融アプリケーション、分析フレームワークなどの）ユーザプログラム５２６を構成するソフトウェア命令を現在のところ含むものとして示されている。共有環境５２５は、ユーザプログラムによって共有されるユーティリティを含み、このような共有ユーティリティは、ユーザプログラム５２６を実行するための（共通の）ランタイム環境を提供する、オペレーティングシステム、デバイスドライバ、仮想マシン、フローエンジンなどを含む。

グラフィックスコントローラ５６０は、ＣＰＵ５１０から受信されるデータ／命令に基づいて、ディスプレイユニット５７０に対する（例えば、ＲＧＢフォーマットの）表示信号を生成する。ディスプレイユニット５７０は、（図４Ａ〜図４Ｂのユーザインターフェイスの部分などの）表示信号によって定義される画像を表示するためのディスプレイ画面を含む。入力インターフェイス５９０は、（図４Ａ〜図４Ｂのユーザインターフェイスにおいて所望の入力などを指定するなど）さまざまな入力を提供するために使用可能なキーボードおよびポインティング装置（例えば、タッチパッド、マウス）に対応し得る。ネットワークインターフェイス５８０は、（例えば、インターネットプロトコルを使用して）ネットワークとの接続を提供し、（サーバシステム１３０Ａ〜１３０Ｃ、データストア１８０Ａ〜１８０Ｂなどの）他の接続されたシステムとの通信に使用可能である。

二次メモリ５３０は、ハードドライブ５３５と、フラッシュメモリ５３６と、リムーバブルストレージドライブ５３７とを含み得る。二次メモリ５３０は、非一時的な媒体を表わし、デジタル処理システム５００が本開示に従ったいくつかの特徴を提供することができるようにデータ（例えば、図３Ａ〜図３Ｂに示されるデータの部分）および（例えば、図２のステップを実行するための）ソフトウェア命令を記憶し得る。二次メモリ５３０に記憶されるコード／命令は、実行速度の高速化のために、ＣＰＵ５１０による実行に先立ってＲＡＭ５２０にコピーされてもよく、またはＣＰＵ５１０によって直接実行されてもよい。

二次メモリ５３０は、ハードドライブ５３５と、フラッシュメモリ５３６と、リムーバブルストレージドライブ５３７とを含み得る。データおよび命令の一部または全ては、リムーバブルストレージユニット５４０に提供されてもよく、データおよび命令は、リムーバブルストレージドライブ５３７によって読み出されてＣＰＵ５１０に提供されてもよい。リムーバブルストレージユニット５４０は、リムーバブルストレージドライブ５３７がデータおよび命令を読み出すことができるように、リムーバブルストレージドライブ５３７に適合した媒体およびストレージフォーマットを使用して実現されてもよい。したがって、リムーバブルストレージユニット５４０は、コンピュータソフトウェアおよび／またはデータが記憶されたコンピュータ読取可能な（記憶）媒体を含む。しかし、コンピュータ（または、一般に機械）読取可能な媒体は、他の形態（例えば、非リムーバブル、ランダムアクセスなど）であってもよい。

本文献では、「コンピュータプログラム製品」という語は、概してリムーバブルストレージユニット５４０またはハードドライブ５３５にインストールされたハードディスクを指すように用いられる。これらのコンピュータプログラム製品は、デジタル処理システム５００にソフトウェアを提供するための手段である。ＣＰＵ５１０は、ソフトウェア命令を検索し、命令を実行して、上記の本開示のさまざまな特徴を提供してもよい。

本明細書で用いられる「記憶媒体」という語は、特定の態様でマシンを動作させるデータおよび／または命令を記憶する任意の非一時的な媒体を指す。このような記憶媒体は、不揮発性媒体および／または揮発性媒体を含み得る。不揮発性媒体は、例えば、ストレージメモリ５３０などの、光ディスク、磁気ディスク、またはソリッドステートドライブを含む。揮発性媒体は、ＲＡＭ５２０などのダイナミックメモリを含む。記憶媒体の共通の形態は、例えば、フロッピー（登録商標）ディスク、フレキシブルディスク、ハードディスク、ソリッドステートドライブ、磁気テープまたはその他の磁気データ記憶媒体、ＣＤ−ＲＯＭ、その他の光学式データ記憶媒体、穴のパターンを有する任意の物理的媒体、ＲＡＭ、ＰＲＯＭおよびＥＰＲＯＭ、フラッシュＥＰＲＯＭ、ＮＶＲＡＭ、その他のメモリチップまたはカートリッジを含む。

記憶媒体は、伝送媒体とは別であるが、伝送媒体と併用されてもよい。伝送媒体は、記憶媒体間で情報を転送することに関与する。例えば、伝送媒体は、バス５５０を備えるワイヤを含む、同軸ケーブル、銅線および光ファイバを含む。また、伝送媒体は、電波および赤外線データ通信中に生成されるような音波または光波の形態をとってもよい。

本明細書全体を通して「一実施例」、「実施例」または同様の言い回しに言及することは、当該実施例に関連して記載される特定の特徴、構造または特性が本開示の少なくとも１つの実施例に含まれることを意味する。したがって、本明細書全体を通じた「一実施例では」、「実施例では」という句および同様の言い回しの登場は、全てが同一の実施例を指してもよいが、必ずしも同一の実施例を指すとは限らない。

さらに、本開示の記載されている特徴、構造または特性は、１つ以上の実施例において任意の好適な態様で組み合わせられてもよい。上記の説明では、本開示の実施例の完璧な理解を提供するために、プログラミング、ソフトウェアモジュール、ユーザ選択、ネットワークトランザクション、データベースクエリ、データベース構造、ハードウェアモジュール、ハードウェア回路、ハードウェアチップなどの例などの多数の具体的な詳細が提供されている。

８．結論
本開示のさまざまな実施例について上記してきたが、それらは限定的ではなく単に一例として提示されているということが理解されるべきである。したがって、本開示の広さおよび範囲は、上記の例示的な実施例のうちのいずれかによって限定されるべきではなく、以下の特許請求の範囲およびそれらの等価物に従ってのみ規定されるべきである。

本開示の機能および利点を強調する添付物に示される図面および／またはスクリーンショットは、単に例示的な目的で提示されているということが理解されるべきである。本開示は、十分に柔軟性があり、構成可能であるので、添付の図面に示されている態様以外の態様で利用できる。

さらに、以下の要約書の目的は、特許庁および公衆、一般におよび特に、特許または法律用語または語法に精通していない当該技術分野における科学者、技術者および専門家が、本願の技術的開示の性質および本質を大まかな検証により素早く判断できるようにすることである。要約書は、本開示の範囲について限定的であるよう意図されたものでは決してない。

Claims (15)

1. コンピュータによって実行される方法であって、
   複数のルールを受信するステップを備え、各ルールは、アプリケーションデータモデルに従って指定された対応するオブジェクトのセットを更新するよう設計され、各オブジェクトは、前記アプリケーションデータモデルに従ってそれぞれの属性を有しており、前記方法はさらに、
   バケットのセットを形成するステップを備え、各バケットは、前記複数のルールのうち、実行順序の点で相互依存性をもたないルールを含み、前記実行順序の点で相互依存性をもつルールは、前記相互依存性をもたないルールとは分離して、前記バケットのセットの異なるバケットに配置され、前記方法はさらに、
   前記バケットのセットの各バケットについて、
   前記バケットに含まれるルールの複数のサブセットを決定するステップを備え、ルールの各サブセットのルールは、前記アプリケーションデータモデルに従って共通のオブジェクトのそれぞれ異なる属性を更新するよう設計され、
   前記ルールの複数のサブセットの各サブセットについて、対応する単一の命令セットを生成するステップと、
   前記バケットに含まれる前記ルールの複数のサブセットについて生成された前記命令セットを同時に実行するステップとを備える、方法。
2. 前記決定するステップは、前記バケットのセットの第１のバケットにおけるルールの第１の複数のサブセットを決定することを含み、前記ルールの第１の複数のサブセットは、ルールの第１のサブセットを含み、前記方法はさらに、
   前記ルールの第１の複数のサブセットの各々を併合できることを示しながら、前記ルールの第１のサブセットを含む前記ルールの第１の複数のサブセットを表示のために送信するステップを備え、
   前記生成するステップは、前記ルールの第１のサブセットが併合対象であることを示す入力データがユーザから受信された場合にのみ、前記ルールの第１のサブセットに対して実行される、請求項１に記載の方法。
3. 前記ルールの第１の複数のサブセットは、ルールの第２のサブセットをさらに含み、
   前記入力データは、前記ルールの第２のサブセットの第１のルールが併合から除外されることを示し、
   前記生成するステップは、前記第１のルールを除く前記ルールの第２のサブセットについて前記対応する単一の命令セットを生成することを含む、請求項２に記載の方法。
4. 前記ルールの第１の複数のサブセットは、第３のオブジェクトを更新するよう設計されたルールの第３のサブセットを含み、前記第１のバケットの第３のルールも、前記第３のルールが前記第３のオブジェクトを更新しないことに鑑みて、前記ルールの第３のサブセットに含まれず、前記方法はさらに、
   前記第３のルールの修正ルールを受信するステップを備え、前記修正ルールは、前記第３のオブジェクトを更新するよう設計され、
   前記決定するステップおよび前記生成するステップは、前記修正ルールを前記ルールの第３のサブセットに含めるため、および、前記修正ルールを含むように前記ルールの第３のサブセットについての前記対応する単一の命令セットを生成するために、再び実行される、請求項２または３に記載の方法。
5. 第１のルールおよび第２のルールは、前記実行順序に従って前記第１のルールの実行が完了して初めて前記第２のルールの実行が開始することを求められる場合に、相互依存性を有すると見なされ、前記第１のルールおよび前記第２のルールは、前記複数のルールに含まれ、
   前記形成するステップは、前記第１のルールを第１のバケットに含めることと、前記第２のルールを前記第１のバケットとは異なる第２のバケットに含めることとを含み、前記第１のバケットおよび前記第２のバケットは、前記バケットのセットに含まれる、請求項１〜４のいずれか１項に記載の方法。
6. 前記受信するステップは、前記複数のルールの各ルールの実行に先立って実行されなければならない対応するルールのセットを示す優先データをさらに受信することを含み、
   前記優先データは、前記第１のルールが前記第２のルールに先立って実行されなければならないことを示す、請求項５に記載の方法。
7. 前記アプリケーションデータモデルに従って指定された前記オブジェクトは、リレーショナルデータベースサーバに記憶され、
   前記複数のルールの各々は、独立して実行されると、前記リレーショナルデータベースサーバに向けられる対応するＳＱＬ（構造化照会言語）コマンドとして実現され、
   前記対応する単一の命令セットは、前記実行するステップ時に、前記リレーショナルデータベースサーバに向けられる単一のＳＱＬコマンドの形式で実現される、請求項１〜６のいずれか１項に記載の方法。
8. システムがルールの管理をサポートすることを可能にするための命令の１つ以上のシーケンスを含むコンピュータプログラムであって、前記システムに含まれる１つ以上のプロセッサによる前記１つ以上の命令の実行は、前記システムが動作を実行することを可能にし、前記動作は、
   複数のルールを受信する動作を含み、各ルールは、アプリケーションデータモデルに従って指定された対応するオブジェクトのセットを更新するよう設計され、各オブジェクトは、前記アプリケーションデータモデルに従ってそれぞれの属性を有しており、前記動作はさらに、
   バケットのセットを形成する動作を含み、各バケットは、前記複数のルールのうち、実行順序の点で相互依存性をもたないルールを含み、前記実行順序の点で相互依存性をもつルールは、前記相互依存性をもたないルールとは分離して、前記バケットのセットの異なるバケットに配置され、前記動作はさらに、
   前記バケットのセットの各バケットについて、
   前記バケットに含まれるルールの複数のサブセットを決定する動作を含み、ルールの各サブセットのルールは、前記アプリケーションデータモデルに従って共通のオブジェクトのそれぞれ異なる属性を更新するよう設計され、
   前記ルールの複数のサブセットの各サブセットについて、対応する単一の命令セットを生成する動作と、
   前記バケットに含まれる前記ルールの複数のサブセットについて生成された前記命令セットを同時に実行する動作とをさらに含む、コンピュータプログラム。
9. １つ以上のプロセッサにより実行されることで、請求項１〜７のいずれか１項に記載の方法を実施するコンピュータプログラム。
10. デジタル処理システムであって、
    プロセッサと、
    ランダムアクセスメモリ（ＲＡＭ）と、
    １つ以上の命令を記憶するための機械読取可能な媒体とを備え、前記１つ以上の命令は、前記ＲＡＭに取り出されて前記プロセッサによって実行されたときに、前記デジタル処理システムにルールを処理させ、前記デジタル処理システムは、
    複数のルールを受信する動作を実行し、各ルールは、アプリケーションデータモデルに従って対応するオブジェクトのセットを更新するよう設計され、各オブジェクトは、前記アプリケーションデータモデルに従ってそれぞれの属性を有しており、前記デジタル処理システムはさらに、
    バケットのセットを形成する動作を実行し、各バケットは、前記複数のルールのうち、実行順序の点で相互依存性をもたないルールを含み、前記実行順序の点で相互依存性をもつルールは、前記相互依存性をもたないルールとは分離して、前記バケットのセットの異なるバケットに配置され、前記デジタル処理システムはさらに、
    前記バケットのセットの各バケットについて、
    前記バケットに含まれるルールの複数のサブセットを決定する動作を実行し、ルールの各サブセットのルールは、前記アプリケーションデータモデルに従って共通のオブジェクトのそれぞれ異なる属性を更新するよう設計され、
    前記ルールの複数のサブセットの各サブセットについて、対応する単一の命令セットを生成する動作を実行し、
    前記バケットに含まれる前記ルールの複数のサブセットについて生成された前記命令セットを同時に実行する動作を実行する、デジタル処理システム。
11. 前記決定する動作のために、前記デジタル処理システムは、前記バケットのセットの第１のバケットにおけるルールの第１の複数のサブセットを決定し、前記ルールの第１の複数のサブセットは、ルールの第１のサブセットを含み、前記デジタル処理システムはさらに、
    前記ルールの第１の複数のサブセットの各々を併合できることを示しながら、前記ルールの第１のサブセットを含む前記ルールの第１の複数のサブセットを表示のために送信する動作を実行し、
    前記デジタル処理システムは、前記ルールの第１のサブセットが併合対象であることを示す入力データがユーザから受信された場合にのみ、前記ルールの第１のサブセットに対して前記生成する動作を実行する、請求項１０に記載のデジタル処理システム。
12. 前記ルールの第１の複数のサブセットは、ルールの第２のサブセットをさらに含み、
    前記入力データは、前記ルールの第２のサブセットの第１のルールが併合から除外されることを示し、
    前記デジタル処理システムは、前記第１のルールを除く前記ルールの第２のサブセット
    について前記対応する単一の命令セットを生成する、請求項１１に記載のデジタル処理システム。
13. 前記ルールの第１の複数のサブセットは、第３のオブジェクトを更新するよう設計されたルールの第３のサブセットを含み、前記第１のバケットの第３のルールも、前記第３のルールが前記第３のオブジェクトを更新しないことに鑑みて、前記ルールの第３のサブセットに含まれず、前記デジタル処理システムはさらに、
    前記第３のルールの修正ルールを受信する動作を実行し、前記修正ルールは、前記第３のオブジェクトを更新するよう設計され、
    前記デジタル処理システムは、前記修正ルールを前記ルールの第３のサブセットに含めるため、および、前記修正ルールを含むように前記ルールの第３のサブセットについての前記対応する単一の命令セットを生成するために、前記決定する動作および前記生成する動作を再び実行する、請求項１１または１２に記載のデジタル処理システム。
14. 第１のルールおよび第２のルールは、前記実行順序に従って前記第１のルールの実行が完了して初めて前記第２のルールの実行が開始することを求められる場合に、相互依存性を有すると見なされ、前記第１のルールおよび前記第２のルールは、前記複数のルールに含まれ、
    前記デジタル処理システムは、前記複数のルールの各ルールの実行に先立って実行されなければならない対応するルールのセットを示す優先データをさらに受信し、前記優先データは、前記第１のルールが前記第２のルールに先立って実行されなければならないことを示し、
    前記デジタル処理システムは、前記第１のルールを第１のバケットに含めるとともに、前記第２のルールを前記第１のバケットとは異なる第２のバケットに含め、前記第１のバケットおよび前記第２のバケットは、前記バケットのセットに含まれる、請求項１０〜１３のいずれか１項に記載のデジタル処理システム。
15. 前記オブジェクトは、リレーショナルデータベースサーバに記憶され、
    前記複数のルールの各々は、独立して実行されると、前記リレーショナルデータベースサーバに向けられる対応するＳＱＬ（構造化照会言語）コマンドとして実現され、
    前記対応する単一の命令セットは、前記実行する動作時に、前記リレーショナルデータベースサーバに向けられる単一のＳＱＬコマンドの形式で実現される、請求項１０〜１４のいずれか１項に記載のデジタル処理システム。