JP4392042B2 - エンティティに基づく構成可能データの管理システム及び方法 - Google Patents

Description

本発明は、概して、データをアーカイブするシステム及び方法に関し、特に、高度に構成可能なデータ保存ポリシーに基づいてデータをアーカイブするシステム及び方法に関する。

コンピュータ・システムに格納されたデータは、種々の理由のため、削除または、別のストレージ装置への移動を含む定期的なアーカイブを典型的に必要とする。定期的なアーカイブを、任意の指定された時間期間にすることができる。この期間管理の基準は、カンパニーのデータ保存ポリシー、エンド・ユーザ要件、システム容量及び性能を含む様々な要因によってしばしば影響を及ぼされる。

あるカンパニーが多くのその他のカンパニーまたは組織（例えば、政府機関、部門、部署、異なるカスタマなど）の代わりにデータを制御または管理する状況では、適切なデータ・オブジェクトの識別及びデータ・オブジェクトのアーカイブの管理は問題となる。同様に、例えば、場合によって多様なカスタマ・ベースのため、カンパニーが、別個の異なったオブジェクトとしてデータを分離し管理するためのビジネス上の理由を有する状況では、異なる定期的なアーカイブのすべてを考慮する一貫したアーカイブ・ポリシーを計画し実行すること、並びに、アーカイブのデータ・オブジェクトを識別することは、かなり難問であって複雑になることがある。

この複雑性を組み立てることを、ビジネス関係または政府の政策のために生じることが多い契約上の協定または義務によって課される要件とすることがある。これら要件は、他のものとかなり異なることがある。カンパニーが、このような関係または政策の代わりに、またはその結果としてデータを管理することに従事している場合、多くの異なるアーカイブ要件は、定期的なアーカイブを実行する義務があるカンパニーを容易に圧倒することがある。異なる要件のすべてが満足される準拠を追跡し保証することは、困難な作業となることがある。

更に、今日の大部分のアーカイブ・プログラムは、共通の機能に対処するため、一貫性なく追加費用で典型的に開発されている。すなわち、各アーカイブ・プログラムは、特定の開発目的によるアーカイブまたは削除などの候補であるデータ・セットを識別することに典型的に対処し、異なるデータ・セットに対してもアーカイブ機能を実行しようとすることがあるその他のいかなるアーカイブ・プログラムに関係なく一方的に関連の性能問題に対処する。各々が特定タイプまたはカテゴリのデータを典型的にターゲットにしている多くの異なるアーカイブ・プログラムを含むことがあるこの一方的なアーカイブ状況は、コンピュータ・システムの処理能力及び性能を酷使し、主要な非アーカイブ・アプリケーションの有効性または適時性に影響を及ぼすことがある。これらプログラムの大部分は、（構成を高価にする）内部にコード化された管理ルール、または、構成制御用に開発された独自手段を有する。

本発明の一側面では、データを制御する方法を提供する。この方法は、１つ以上のデータ・オブジェクトのデータ保存ポリシーと関連する１つ以上のデータ管理ルールを定義し、１つ以上のデータ管理ルールの各々が、１つ以上のデータ・オブジェクトに関連するアプリケーション・プログラム・システムと、１つ以上のデータ・オブジェクトを識別するパラメータと、１つ以上のデータ・オブジェクトのアーカイブ管理を実行するソフトウェア・モジュールとを指定するステップを含む。この方法は、イベントが生じるとソフトウェア・モジュールを実行し、イベントが、アーカイブ管理をパラメータと、指定したアプリケーション・システムとに基づいて制御するために１つ以上のデータ管理ルールの少なくとも１つを識別し、指定したアプリケーション・システムが、１つ以上のデータ管理ルールによって識別された１つ以上のデータ・オブジェクトに対してアーカイブ管理動作を実行するステップを更に含む。

一実施形態では、この方法は、データ保存ポリシーと関連する１つ以上のデータ管理ルール・タイプを定義するステップを含み、１つ以上のデータ管理ルールは各々データ管理ルール・タイプのインスタンスを定義し、１つ以上のデータ・ルール・タイプは、エンティティ・タイプのデータ保存ポリシーを記述する名前付きルール・タイプを指定し、１つ以上のデータ・ルール・タイプは、アーカイブ管理を制御するのに用いる以下の属性、すなわち、
ｉ） アプリケーションＩＤ
ｉｉ） アプリケーション・システムＩＤ
ｉｉｉ） コーポレーションＩＤ
ｉｖ） 管理対象エンティティ名
ｖ） 制御エンティティ名
ｖｉ） 役割ＣＤ
ｖｉｉ） 制御日付カラムＩＤ、または、
ｖｉｉｉ） データ保存ポリシーＩＤ
の１つ以上を有する。

一実施形態では、エンティティ・タイプは、一意的に識別される人、場所、事柄、概念またはイベントを定義し、名前属性及び記述属性の少なくとも１つを有し、エンティティ・タイプに対して完全なキーを構成する属性を定義する関連のエンティティ・キー属性を有する。

一実施形態では、この方法は、アーカイブ管理を制御するのに用いる以下の属性、すなわち、
ｉ） インストール済みアプリケーションＩＤ
ｉｉ） エンティティ・キー
ｉｉｉ） アクション前の時間
ｉｖ） 測定の時間単位
ｖ） コミット数
ｖｉ） 最大反復
ｖｉｉ） データ保存タイプ、または、
ｖｉｉｉ） イベント名
の１つ以上を定義し、１つ以上のデータ管理ルールと関連付ける。

一例として、１つ以上のデータ管理ルールを、インストール済みアプリケーションＩＤと、ビジネス機能コード、アプリケーション・システムＩＤ及びインストール済みアプリケーション記述の少なくともいずれか１つとを有するインストール済みアプリケーション・エンティティに関連付けることができる。

一実施形態では、この方法は、１つ以上のデータ・オブジェクトを識別し、エンティティ名及びエンティティ記述を含む属性を有する１つ以上のエンティティ・タイプと、エンティティ・キー属性とを定義するステップを含む。

エンティティ・キー属性は、エンティティ名、エンティティ・キー・シーケンス及びキー属性名を含む属性を有することができる。

一実施形態では、１つ以上のエンティティ・タイプの１つのインスタンスを生成することによって呼び出されるときに固有の識別子を構成する連続するアルゴリズム・セットを各々定義する１つ以上のエンティティ・ビルダを定義することができる。

一実施形態では、１つ以上のコンピュータ・ジョブ・エンティティを含む１つ以上の属性を有する作業単位エンティティを定義する。

一実施形態では、この方法は、エンティティ・キーによって識別された１つ以上のデータ・オブジェクトの少なくとも１つのアーカイブ管理を制御するため、インストール済みアプリケーションＩＤ、データ管理ルール名、エンティティ・キー、作業単位開始日付、作業単位終了日付及び作業単位状態の少なくともいずれか１つを含む作業単位エンティティの１つ以上の属性を定義するステップを含む。

一実施形態では、この方法は、１つ以上のデータ管理ログ・エンティティを、実行されるとアーカイブ管理の活動をロギングする１つ以上のコンピュータ・ジョブ・エンティティと関連付けるステップを含み、１つ以上のデータ管理ログ・エンティティは、インストール済みアプリケーションＩＤ、データ管理ルール名、エンティティ・キー、作業単位開始日付、作業単位終了日付、ジョブ番号、ログ・タイムスタンプ、活動状態、ログ済みメッセージ及び取引数の少なくともいずれか１つを含む属性を有する。

一実施形態では、実行するステップを開始するため、イベントが定期的に生じ、イベント名を１つ以上のデータ管理ルールに供給する。

本発明の別の側面では、データ管理を制御する方法を提供する。この方法は、コントローラのインスタンスを生成し、イベント名をコントローラに供給するステップと、イベント名と関連するルールにアクセスするステップとを含む。この方法は、ルールと関連するルール・タイプと関連する制御データを獲得するステップと、少なくとも作業単位定義を含む制御データによって定義された１つ以上のデータ・オブジェクトについてアーカイブ機能を実行するプログラムを実行するステップとを更に含む。

一実施形態では、作業単位定義は、開始日付及び終了日付のパラメータを含む。

一実施形態では、制御データは、アプリケーション・システム、１つ以上のデータ・オブジェクトと関連するエンティティ名、制御エンティティ名及び最大反復の少なくともいずれか１つを定義する。

一実施形態では、アーカイブ機能は、データの削除、データのパージ、及び、ストレージ用の１つのシステムから別のシステムへのデータの移動の少なくともいずれか１つを含む。

本発明の別の側面では、データを管理するシステムを提供する。このシステムは、コントローラのインスタンスを生成し、イベント名をコントローラに供給する手段と、イベント名によって識別されたルール・タイプと関連する制御データを獲得する手段とを含む。このシステムは、少なくとも作業単位定義を含む制御データによって定義された１つ以上のデータ・オブジェクトについてアーカイブ機能を実行するプログラムを実行する手段を更に含む。

一実施形態では、作業単位定義は、開始日付及び終了日付のパラメータを含む。

一実施形態では、制御データは、アプリケーション・システム、１つ以上のデータ・オブジェクトと関連するエンティティ名、制御エンティティ名及び最大反復の少なくともいずれか１つを定義する。

一実施形態では、アーカイブ機能は、データの削除、データのパージ、及び、ストレージ用の１つのシステムから別のシステムへのデータの移動の少なくともいずれか１つを含む。

一実施形態では、このシステムは、アーカイブ機能を制御するのに用いる以下の属性、すなわち、
ｉ） インストール済みアプリケーションＩＤ
ｉｉ） エンティティ・キー
ｉｉｉ） アクション前の時間
ｉｖ） 測定の時間単位
ｖ） コミット数
ｖｉ） 最大反復
ｖｉｉ） データ保存タイプ、及び、
ｖｉｉｉ） イベント名
の１つ以上を有するルール・タイプのインスタンスを生成し供給する手段を含む。

一実施形態では、ルール・タイプは、インストール済みアプリケーションＩＤと、ビジネス機能コード、アプリケーション・システムＩＤ及びインストール済みアプリケーション記述の少なくともいずれか１つとを含む属性を有するインストール済みアプリケーション・エンティティに関連する。

一実施形態では、作業単位定義のインスタンスは生成され、作業単位定義は、ルール・タイプと関連する１つ以上のオブジェクトを識別するために制御パラメータをプログラムに供給する。

一実施形態では、このシステムは、イベント名によって開始されたプログラムの実行と関連する情報をロギングする手段を含む。

本発明の別の側面では、コンピュータ使用可能媒体を含むコンピュータ・プログラム製品であって、媒体内には、可読プログラム・コードが統合されているコンピュータ・プログラム製品を提供し、このコンピュータ・プログラム製品は、１つ以上のデータ・オブジェクトのデータ保存ポリシーと関連する１つ以上のデータ管理ルールを定義し、１つ以上のデータ管理ルールの各々が、複数のデータ・オブジェクトに関連するアプリケーション・プログラム・システムと、１つ以上のデータ・オブジェクトを識別するパラメータと、１つ以上のデータ・オブジェクトのアーカイブ管理を実行するソフトウェア・モジュールとを指定する少なくとも１つの構成要素を含む。少なくとも１つの構成要素は、イベントが生じるとソフトウェア・モジュールを実行し、イベントが、アーカイブ管理をパラメータと、指定したアプリケーション・システムとに基づいて制御するために１つ以上のデータ管理ルールの少なくとも１つを識別するようにも構成されている。

添付図面を参照して例示の目的のみで本発明の好適な実施形態を次に説明する。

好適な実施形態によれば、本発明は、概して、アーカイブ・ルール基準の高度に構成可能なアーティキュレーションを行うシステム及び方法であって、アーティキュレートされたアーカイブ・ルール基準を用いて特定のデータを管理するプログラムを実行する一貫した処理のためのシステム及び方法に関する。コンピュータ媒体に格納されたデータは、ほとんどの場合、保存期間周期を有し、典型的に、無期限に格納されるものと期待されていない。この保存期間は、組織のデータ保存ポリシー・ステートメントまたは計画によって記述されることが多く、アプリケーション・システムによって様々な方法で典型的に実装される。好適な実施形態によれば、開示されたシステム及び方法は、少なくとも、
− 組織の保存ポリシーを獲得することと、
− これらポリシーをどのように特定タイプのデータに適用することができるかを定義することと、
− 定義したデータ・セットに対して特定の保存ルールを定義することと、
− これらルールを様々なアプリケーション・システムにおいて管理することと
を達成する一貫した処理を提供する。

データ管理に対して責務を有する組織によって実装された後、継続している一貫した高信頼性のアーカイブ結果を実現することができ、広範囲のデータ・タイプ及びシステム環境に対処するように柔軟に構成可能である。このことは、１つ以上のポリシー設定組織によって必要とされるポリシーまたは契約によって定義されたアーカイブ目標が満足される高度の信頼性を可能にする。

図１〜４は、本発明の好適な実施形態によって提供、管理または使用される様々なタイプのエンティティ（データ）を示し、符号１００で広く示された論理ブロック図である。図１は上位の様々なエンティティを示すのに対して、図２〜４は、エンティティ及び関連の属性の更なる詳細を提供する。３つの一般的な分類、すなわち、データのポリシー及びルール・タイプ１０５、特定ルール１１５及び実行管理１２５に組織化されたデータ管理の論理エンティティを示す。これらエンティティを定義しインスタンスを生成してデータ管理処理を達成することができる。あるいはまた、図１〜４を、図示の様々なエンティティを定義し、または生成し、あるいはその両方を行うステップとすることもできる。

データ保存ポリシー１０８は、異なる組織ごとに保存ポリシーを必要とすることができる組織の保存ポリシーを記述する。例えば、組織「Ａ」は、短期、中期及び長期ストレージを必要とするとデータを定義することができるのに対して、組織「Ｂ」は、処分可能及び不可欠であるとデータを定義することができる。これら定義は通常、関連または特定あるいはその両方の「年齢」を含む。例えば、「短期」を、「このデータを６ヶ月間格納する」と定義することができるのに対して、「不可欠なデータ」を、「７年間格納すべきである」と定義することができる。

データ管理ルール・タイプ・エンティティ１１０Ａ〜１１０Ｆは全体として、データ保存ポリシー１０８を、アプリケーション・システム内で検出された特定のエンティティと関連付けるデータである。一例として、データ管理ルール・タイプ１１０Ａを、「ウェブ支払い要求」（ＷＰＲ）と称されるアプリケーション・システム１１０Ｃによって管理することができる「サプライヤ入力のインボイス」とすることができる。このルール・タイプは「サプライヤ・インボイス」エンティティ・タイプ１１０Ｂの管理を記述し、これらインボイスは、エンティティ・キー属性１１０Ｄ、例えば、「インボイスＩＤ」によって識別される。このルール・タイプは、エンティティ・タイプ１１０Ｂ、すなわち、特定のデータ管理ルールを記述する際に別の粒度レベルを定義することに用いられる「制御エンティティ」をも定義する。様々な論理構成要素及び関連の属性を以下に更に記述する。

エンティティ・タイプ１１０Ｂ
このエンティティは、ビジネス活動をサポートするためにビジネス組織が情報を必要とする人、場所、事柄、概念またはイベントを定義する。このエンティティを、エンティティ・タイプ１１０Ｂの属性であって、例えば、ＥＭＰＬＯＹＥＥ、ＷＯＲＫ ＬＯＣＡＴＩＯＮ、ＩＴＥＭ、ＰＵＲＣＨＡＳＥ ＯＲＤＥＲまたはＰＲＯＣＥＳＳ ＨＩＳＴＯＲＹのような、エンティティのタイプに与えられた固有の名前を定義するエンティティ・タイプ名によって一意的に識別することができる。

エンティティ・キー属性１１０Ｄ
このエンティティは、エンティティ・タイプに対して、完全なキーまたは固有の識別子を構成する属性を定義する。この情報によって、システムは、構成に基づいてエンティティ識別子の種類を自動的に構成することができ、この情報は、以下の属性を有することができる。

エンティティ・タイプ名
この属性は、宣言された属性を識別するエンティティ・タイプの名前を定義する。

エンティティ・キー・シーケンス番号
この属性は、エンティティ・タイプのインスタンスを一意的に識別するため、キー属性タイプが用いられることになっている順序を定義する。

キー属性タイプ名
この属性は、エンティティ・タイプの固有の識別子を構成する属性タイプに与えられた名前を定義する。システムは、このデータを用いて、エンティティの識別子のインスタンスを動的に獲得するためにオブジェクトと通信する。これら属性の例として以下の例が挙げられる。

エンティティ・タイプ「ＥＭＰＬＯＹＥＥ」（エンティティ・タイプ名）を、属性タイプ「ＨＲ ＳＹＳＴＥＭ ＩＤ」及び「ＥＭＰＬＯＹＥＥ ＩＤ」の順序でこれらによって一意的に識別することができ、これらは、それぞれ１及び２のエンティティ・キー・シーケンス番号を有するキー属性タイプ名である。

エンティティ・タイプ「ＣＯＭＰＡＮＹ」を、属性タイプ「ＣＯＵＮＴＲＹ ＣＤ」及び「ＣＯＭＰＡＮＹ ＣＤ」の順序でこれらによって一意的に識別することができる。

エンティティ・タイプ「ＣＯＭＰＡＮＹ ＣＯＭＭＯＤＩＴＹ」を、属性タイプ「ＣＯＵＮＴＲＹ ＣＤ」、「ＣＯＭＰＡＮＹ ＣＤ」及び「ＣＯＭＭ ＣＤ」の順序でこれらによって一意的に識別することができる。

エンティティ・ビルダ１１０Ｅ
このエンティティは、エンティティ・タイプのインスタンスを生成する際、固有の識別子を正確かつ完全に構成するために呼び出すことができる連続するアルゴリズム・セットを定義することができる。これらアルゴリズムは、固有キーを構成するのに用いられるデータを既存のソースから取り出し、これによって、参照整合性のフォームを実装する。参照整合性は、エンティティ間の関係が完全かつ正確であることを確実にする。例えば、ＣＯＭＰＡＮＹは、親エンティティに存在するＣＯＲＰＯＲＡＴＩＯＮを意味する場合に限り、関係「ＣＯＭＰＡＮＹは、１つのＣＯＲＰＯＲＡＴＩＯＮにのみ属する」は、「良好な整合性」を有する。

データ管理ルール・タイプ１１０Ａ
このエンティティは、単一タイプのエンティティに対して、コーポレーションのデータ保存ポリシーを記述する名前付きルール・タイプを定義する。このルール・タイプは、同じエンティティ・タイプに対して特定ルールの確立を管理し、以下の属性の１つ以上を有することができる。

データ管理ルール名
この属性は、ルール・タイプを一意的に識別するのに用いられる名前を定義する。

アプリケーションＩＤ
この属性は、ビジネス・データ・セットを削除、移動または要約するような実際のデータ管理アクションを自動化する任意のプログラミング言語で書かれたアプリケーション・プログラムを一意的に識別する名前を定義する。データ管理ルール・タイプは、このプログラムによって実装される。

アプリケーション・システムＩＤ
この属性は、管理すべきビジネス・データについて動作し、これを格納するアプリケーション・システムのタイプの名前を定義する。このタイプのアプリケーション・システムのインスタンスは２つ以上存在しうる。例えば、ＣＡＡＰＳは、ラテンアメリカ、ヨーロッパ及びアジア太平洋で１つずつ実行する３つのインスタンスを有する調達システムに与えられた名前である。各インスタンスは、同じフォーマットで、かつ同じ種類のビジネス・データについて動作し、これを格納する。アプリケーション・システムＩＤを有するこのアプリケーション・システムに対してデータ管理ルール・タイプが確立される。

コーポレーションＩＤ
この属性は、幾つかの小規模な法律上のエンティティ（すなわち、カンパニー）から成ることができる法律上のビジネス・エンティティの名前を定義する。データ管理ルール・タイプは、このコーポレーションによって定義される。

管理対象エンティティ・タイプ名
この属性は、このデータ管理ルール・タイプによってビジネス・データが管理されていることを定義する。例えば、エンティティ・タイプ「ＦＩＮＡＮＣＩＡＬ ＩＮＶＯＩＣＥ ＰＯＳＴＩＮＧ」を、所定のルール・タイプの対象とすることができる。

制御エンティティ・タイプ名
この属性は、ビジネス・データをセグメント化し、もっと具体的なポリシー要件を適用できるようにエンティティ・タイプが用いられることを定義する。例えば、フランスのビジネス・データ・ポリシーは、アメリカ合衆国（すなわち、エンティティ・タイプ「ＣＯＵＮＴＲＹ」）のビジネス・データ・ポリシーと異なることができる。この属性を、ルールに選択することができるエンティティを管理するため特定のデータ管理ルールを構成する際に用いることができる。

制御カラム名
この属性は、幾つかのアクション（例えば、削除、要約など）に対する適格性を決定するのに用いられるように（管理対象エンティティ・タイプ名によって名付けられた）ビジネス・データ内に存在する日付またはタイムスタンプ・データの名前を定義する。

役割ＣＤ
この属性は、ルール・タイプに対して生成された特定ルールの構成を変更するために人に割り当てなければならない役割を定義する。

アプリケーション・システム１１０Ｃ
このエンティティは、カンパニー・ポリシーに従って管理すべきデータを「所有する」アプリケーション・システムのタイプを定義する。

パラメータ・タイプ１１０Ｆ
このエンティティは、必要ならば、「アーカイバ」（アーカイブ機能を実行するプログラム）アプリケーションが、データ管理アクションに対してビジネス文書（例えば、取引）の適格性を確立するために必要とするパラメータのタイプを定義する。

図１〜４に関して、更に、特定ルール１１５は、制御エンティティに対する特定のデータ管理ルールを全体として記述する構成要素である。例えば、「ビジネス単位」（例えば、「カンパニーＡ一般調達」または「カンパニーＢパーソナル・システム部門」）を、制御エンティティの一例とすることができる。制御エンティティを、「北アメリカ」（地理的領域）のような上位にすることができ、または、エンタープライズ・リソース・プランニング（ＥＲＰ）システムの特定のインストールとすることができる「ＣＡＡＰＳ６３１０３」のような全く異なるエンティティとすることができる。特定ルール１１５の構成要素は以下のエンティティを含むことができる。

イベント１２０Ａ
このエンティティは、時間起動イベントまたは別のコンピュータ・ジョブの完了のような名前付きイベントを定義する。

データ管理ルール１２０Ｂ
このエンティティは、アーカイブまたはパージなどされる適格なビジネス文書を識別する実行中に用いられるデータ管理ルール・タイプ１１０Ａのインスタンスを定義する。このエンティティは、ファミリーであるデータを収容する特定のアプリケーション・インスタンス、アクションがとられる前に、含まれるビジネス文書の日付またはタイムスタンプに関連する経過しなければならない日数（または、その他の時間期間）、この「アクション前の時間」属性の測定単位、作業単位内（すなわち、アクションがデータベースにコミットされる前）で処理すべき文書の最大数、または、適格な文書をルールの単一実行中にシークすることができる回数の最大数のような制御属性を含む。

インストール済みアプリケーション１２０Ｃ
このエンティティは、管理されるデータを「所有する」アプリケーション・システムの特定のインスタンスを定義する。例えば、インストール済みアプリケーションＩＢＭＳＡＰＧＰ０及びＩＢＭＳＡＰＧＰ１は、アプリケーション・システム（タイプ）「ＳＡＰ」の２つのインスタンスである。

パラメータ１２０Ｄ
このエンティティは、データ管理に関してビジネス文書の適格性を決定するために「アーカイバ」によって用いられるデータの特定のタグ付き部分を定義する。

図１〜４に関して、更に、実行管理１２５は全体として、定義済みルールの管理を可能にするデータである。これによって、中央制御構成要素は、特定の作業単位の状態及び完全性を追跡することができる。実行管理１２５の構成要素を以下で更に詳細に説明する。

作用単位１３０Ａ
このエンティティは、データ管理アクションに対して適格であるビジネス文書セットを定義する。この文書セットを、特に文書の年齢によって識別することができる。

コンピュータ・ジョブ１３０Ｂ
このエンティティは、プログラムまたはプログラム群の識別可能な単一実行を定義する。

データ管理ログ１３０Ｃ
このエンティティは、ロギングまたは監査目的のデータベースを定義する。

図５は、符号２００で広く示された本発明の一実施形態の機能ブロック図である。この実施形態は、データ管理コントローラ（ＤＭＣ）２０５、１つ以上の「ブラック・ボックス」プログラム２１０Ａ〜２１０Ｃ（その中には、これらプログラムの複数の反復１〜Ｎがある）、及び、場合によって特定のシステム例えば「システムＡ」と関連するアーカイブ処理を必要とするデータ（例えば、インボイス・データ、金融データ、企業データ、レジューム・データなどのいずれか１つまたは任意の組み合わせ）を有するデータベース２１５を含む。構成及びロギング用のデータベース２２０、及び、別の特定のシステム例えば「システムＢ」と関連付けることができるアーカイブを必要とするその他のデータを有するデータベース２２５も含まれる。

ＤＭＣ２０５は、
ｉ） 処理を起動した名前付きイベントと関連する特定のデータ管理ルールを検出することと、
ｉｉ） 「作業単位」を決定することと（「ＵＯＷ（作業単位）幅」は、処理すべきデータの開始日付と終了日付との範囲の年齢である）、
ｉｉｉ） 「アーカイバ」プログラムを呼び出し、この時点で作用すべき取引または「オブジェクト」の最大数（作業量）、ＵＯＷ日付、及び、処理すべきデータを更に限定する任意のパラメータを受け渡すことと、
ｉｖ） 定義された反復回数に従って作業量が最大数を超えた場合、「アーカイバ」プログラムを再び呼び出すことと、
ｖ） 各ＵＯＷの状態を追跡することと、
ｖｉ） 「コンピュータ・ジョブ」に関する一般統計（例えば、所要時間、実行履歴）をロギングすることと、
を含む１つ以上の活動に対して責務を有する。

引き続き図２に関して、機能構成要素２３０Ａ〜２３０Ｃは、様々なソフトウェア・ルーチンによって達成することができるＤＭＣ２０５が実行する前述の機能ステップ及びその他の機能ステップを示す。例えば、機能ブロック２３０Ａは、ＤＭＣが１つ以上のプログラム（例えば、２１５、２２０または２２５）、システム（例えば、システムＡ）、制御エンティティ、及び、管理されるデータを定義または識別あるいはその両方を行うことを示す。機能ブロック２３０Ｂは、特定の制御エンティティに対して、ＤＭＣ２０５が作業単位（ＵＯＷ）幅、作業量、反復回数、及び、アーカイブ処理を起動するイベントを識別または定義することを示す。機能ブロック２３０Ｃは、（イベント２３５のような）特定のイベントによって起動される適切な「アーカイバ」プログラム（例えば、２１０Ａ〜２１０Ｃ）を呼び出すことと、ＵＯＷ状態を追跡することと、一般統計をロギングすることとを含む、ＤＭＣ２０５によってとることができる例示的なアクションを示す。イベント２３５は、例えば月に２度のような予め決定された頻度で生じることができる。

この実施形態２００は、例えば、データベース２１５に常駐することができるインボイス・データのような、プログラムＡと関連するデータのアーカイブ処理に「アーカイバ」プログラムＡ ２１０Ａを用いることができることも示す。プログラムＢ ２１０Ｂは、一例としてレジューム・データとすることができ、この場合もデータベース２１５に常駐することができる関連のデータを処理することを例示的に示す。しかし、一実施形態では、プログラムＢ ２１０Ｂは、データベース２２０に活動を直接にロギングすることもできる。その他の実施形態では、ＤＭＣ２０５は、符号２１７によって示されるように「アーカイバ」プログラムの代わりにロギング機能を実行することができる。例えば、プログラムＣ ２１０Ｃは、符号２２５によって示されるようにシステムＢと関連するデータを処理することができ、符号２１７によって示されるようにデータベース２２０の代わりにログオンすることをＤＭＣ２０５に任せる。

一般に、「アーカイバ」プログラムは、以下の責務を有する。例えば、
ｉ） ＵＯＷ日付、パラメータとして受け渡された基準、及び、受け渡される作業量（例えば、取引数）への制限に基づいてプログラムが書かれたデータに作用する。
ｉｉ） 監査目的のビジネス制御数（例えば、データ管理ログ）をロギングする。

しかし、当然のことながら、「アーカイバ」プログラムは、追加の責務を含むことができる。

システムの活動を調整するため、データ管理アーキテクチャの共通のアーカイブ・フレームワーク及び実装（アーキテクチャの一例のプロトタイプは表１、２及び３を参照して以下に提示する）は典型的に以下の基本ルールを含む。すなわち、
ｉ） 「アーカイバ」アプリケーションは、（以下に示すように）アーカイバ・インターフェースを実装する必要がある。このインターフェースで定義される典型的に１つのメソッドは、ルールが呼び出される際にＤＭＣによって呼び出される。
ｉｉ） 「アーカイバ」アプリケーションは、（以下で定義する）ＲｅｓｕｌｔＤａｔａクラスのインスタンスを介してコントローラに返信する。
ｉｉｉ） 「アーカイバ」アプリケーションは、（以下で定義する）パラメータ・インターフェースを実装することによって構成情報を獲得することができる。
ｉｖ） すべての「アーカイバ」アプリケーションは、ａｒｃｈｉｖｅｒｓ．ｘｍｌファイルを介してコントローラで登録する必要がある。エントリは「アーカイバ」アプリケーションごとに存在する。また、このファイルは、パラメータ・インターフェースの任意の実装のクラス名をコントローラに提供する。
ｖ） コントローラは、前の作業単位（以後、ＵＯＷと称する）が未完了であるかどうかを（ルールごとに）検査する。未完了のＵＯＷが存在する場合、このＵＯＷに、完了したとマークすることができ、新たなＵＯＷを前の実行と同じ日付範囲で生成することができる。
ｖｉ） コントローラは、「アーカイバ」アプリケーションによって必要とされる任意の追加のデータを収集することができるようにａｒｃｈｉｖｅｒｓ．ｘｍｌファイルに定義されたパラメータ・インターフェースの実装を呼び出す。
ｖｉｉ） コントローラは、アーカイブ動作を次に実行する関連の「アーカイバ」アプリケーションの「ｐｅｒｆｏｒｍＡｒｃｈｉｖａｌ」メソッドを呼び出す。
ｖｉｉｉ） 「アーカイバ」から返還されたＲｅｓｕｌｔＤａｔａオブジェクトを、状態について「アーカイバ」からクエリーすることができる。失敗状態が返信された場合、「アーカイバ」アプリケーションは、ルール表に構成された反復回数だけ呼び出される。
ｉｘ） 成功状態が獲得された場合、ＵＯＷに、完了したとマークすることができる。

アーカイバ・インターフェースの一例を表１に示す。このインターフェースを、すべての「アーカイバ」アプリケーションによって実装することができる。この例では、ＤＭＣは、「ｐｅｒｆｏｒｍＡｒｃｈｉｖａｌ」メソッドを介して制御を、処理される特定ルールを処理する「アーカイバ」アプリケーションに受け渡す。

表２は、「アーカイバ」アプリケーションとＤＭＣとの間でメッセージを送信するのに用いることができる「ＲｅｓｕｌｔＤａｔａ」クラスの一例である。

この例では、すべての「アーカイバ」プログラムは、このタイプのオブジェクトを返信し、プログラムがすべてのデータに対してアーカイブを首尾良く実行したかどうかを示す状態を最小限度に設定することができる。また、このクラスは、ロギング及びメッセージ送信を高めるために用いることができるタイプ「ＥｘｅｃｕｔｉｏｎＲｅｓｕｌｔ」のオブジェクトを返信する機能を提供することができる。複数の実施形態では、このオブジェクトを用いて、ロギングをＤＭＣ自体によって行うことができる。

表３は、構成を「アーカイバ」アプリケーションに受け渡すパラメータ・インターフェースの一例である。

この例示的なインターフェースを用いて構成を「アーカイバ」アプリケーションに受け渡すことができる。また、インストール済みアプリケーションＩＤ、エンティティ、コミット数及び関連日付を受け渡すことができるデフォルト実装が提供される。「アーカイバ」アプリケーションは、このインターフェースをも実装して、必要に応じて適切に変更されるその他の「構成」データをも受け渡すことができる。

図６は、本発明を用い、ステップ３００から開始するステップを示す本発明の一実施形態の流れ図である。図６〜９は、本発明のステップを実装する好適な実施形態の構成要素のブロック図を等しく示すことができる。図６〜９を、適切なハードウェアと組み合わせてコンピュータ・プログラム・コードに実装することができる。このコンピュータ・プログラム・コードを、読み取り専用メモリ（ＲＯＭ）またはランダム・アクセス・メモリ（ＲＡＭ）のような１つのメモリ・ストレージ装置またはメモリ・ストレージ装置の集合と同様に、ディスケット、ハード・ディスク、ＣＤ‐ＲＯＭ、ＤＶＤ‐ＲＯＭまたはテープのようなストレージ媒体に格納することができる。更に、コンピュータ・プログラム・コードを、インターネットまたはその他の何らかのタイプのネットワークを介してワークステーションに転送することができる。

引き続き図６に関して、ステップ３０５において、複数のデータ・オブジェクトに対して１つ以上のルールを定義することができる。ステップ３１０において、ルールごとに制御エンティティを指定することができる。ステップ３１５において、アプリケーションを指定し、各データ・オブジェクトと関連付けることができる。ステップ３２０において、アーカイブ、別のストレージ・システムへのデータ・オブジェクトの移動などの管理機能を実行するソフトウェア・モジュールを指定することができる。ステップ３２５において、作用されるべき適格性を有するデータ・オブジェクトを更に正確に識別するパラメータを指定することができる。例えば、金融文書は「パージされる準備ができている」ことを示す状態コードのリストを列挙することができる。

ステップ３３０において、例えば、保存期間、ストレージ・サイズまたはその他の処理限度のようにルールごとに１つまたは複数の基準を定義することができる。ステップ３３５において、ルールごとにイベントを指定することができる。ステップ３４０において、イベントが生じる際にアプリケーション（例えば、「アーカイバ」）を呼び出すことができる。ステップ３４５において、データの移動、データの削除、新たなストレージ装置へのデータの格納のいずれか１つまたは任意の組み合わせのようなアーカイブ管理機能をルールごとに実行し、ルール及びルール・タイプに対して定義されたパラメータを用いてエンティティを関連付けることができる。処理はステップ３５０において終了する。

図７〜９は、本発明を用い、ステップ４００から開始する例示的なステップを示す一実施形態の流れ図である。ステップ４０５において、コントローラがインスタンスを生成したかどうか検査を行う。コントローラがインスタンスを生成した場合、ステップ４１５において、アーカイブまたはデータ保存処理を開始するためのイベント名を有するコントローラにメッセージを供給する。処理はステップ４２０に続く。しかし、コントローラにインスタンスが生成されていない場合、ステップ４１０において、コントローラを開始し、アーカイブまたはデータ保存処理を開始するイベント名をコントローラに供給する。ステップ４２０において、名前付きイベントと関連するルールにアクセスする。ステップ４２５において、関連のルール・タイプ表からルールに対する制御を獲得する。

ステップ４３０において、前の作業単位（ＵＯＷ）がルールに対して完了したかどうか検査を行う。完了した場合、ステップ４６０において、新たなＵＯＷパラメータを、残りのデータに対して適切であるように計算することができる。ステップ４６５において、ルールと関連する適切な「アーカイバ」プログラムを、新たなパラメータを用いて開始する。しかし、ステップ４３０において、前のＵＯＷが完了していない場合、ステップ４３５において、ルールに対して適切な「アーカイバ」プログラムを、前のＵＯＷパラメータを用いて開始する。ステップ４４０において、「アーカイバ」からインターフェース・パラメータごとに実行結果をロギングするため、ログ・エントリを入力することができる。ステップ４４５において、最大量のデータまたはデータ行（すなわち、処理すべき最大数のビジネス文書）が処理されたかどうか検査を行う。処理された場合、ステップ４５０において、ＵＯＷに「完了」とマークし、処理はステップ４５５を続ける。処理されていない場合、処理はステップ４５５を続ける。

ステップ４５５において、現在の名前付きイベントに対して最大反復が行われたかどうか検査を行う。最大反復が行われていない場合、ステップ４６５において、この反復に対してパラメータ（例えば、ＵＯＷパラメータ、処理すべき最大文書など）を用いて「アーカイバ」プログラムを開始し、処理はステップ４４０を続ける。しかし、反復の最大数が達成された場合、ステップ４７０において、名前付きイベントに対するルールがこれ以上存在するかどうか検査を行う。ルールが存在する場合、処理は、ステップ４２５において新たなルールを用いて再開する。そうでなければ、名前付きイベントに対して更なるルールがない場合、処理はステップ４８０において終了する。

使用例
具体的な例として、以下の場合を仮定する。ＨＡＬＣＯは、世界中で３２の異なるカンパニーから成る。これらカンパニーの３つは、「ＣＡＡＰＳ」システムの２つのインスタンスを用いて、アメリカ合衆国及びドイツにおける買掛金取引を処理する（サプライヤ・インボイスを支払う）。これら２つのシステム「ＣＡＡＰＳＵＳ」及び「ＣＡＡＰＳＤＥ」は、支払いがクリアされた２０日後にプロダクション・システムからアーカイブ・データベースに移動された取引データを必要とする。アーカイブ・データベースは、「ＡＰＢＤＷ」データ・ウェアハウス・システムと称される。これら支払い文書を、アメリカ合衆国のカンパニーに対して支払いがアーカイブされた２年後に、かつ、ドイツのカンパニーに対しては３年後に「ＡＰＢＤＷ」システムから削除する必要がある。「クリアされた」という定義は、２国家間でわずかに異なることができる。この差は、文書上で検出される２つの交わる状態コード・セットとして表される。

企業に関わる役割のグローバル管理者はルール・タイプを以下のように確立することができる。すなわち、
ｉ） 論理エンティティＣＡＡＰＳ＿ＣＯＭＰＡＮＹは、システムに対して、Ｃｏｕｎｔｒｙ＿Ｃｏｄｅ及びＣｏｍｐａｎｙ＿Ｃｏｄｅの２つのパーティ・キーを有すると定義される。
ｉｉ） ＡＰ．ＴＣＯＭＰＡＮＹ＿ＴＢＬ ＤＢ２（登録商標）表を、カンパニーをインストール済みアプリケーション・システムと関連付けるシステム・インターフェース制御表と結合することによってＡＰ．ＴＣＯＭＰＡＮＹ＿ＴＢＬ ＤＢ２（登録商標）表からＣｏｕｎｔｒｙ＿Ｃｏｄｅのサブセットを最初に識別するエンティティ「ビルド」ロジックが生成される。この関係は、「ＣＡＡＰＳ」インストールのみを含む。ビルド・ロジックの第２部分は、「ＣＡＡＰＳ」インストールを用いるカンパニーに、（エンド・ユーザによって典型的に与えられる）指定国家内のカンパニーのリストを提供する。
ａ． 第１ビルド・ロジックの結果は、関係データ・セットすなわち、
１． ＵＳ‐アメリカ合衆国
２． ＤＥ‐ドイツ
である。
ｂ． 第２ビルド・ロジックの結果は、セットすなわち、
１． ＵＳ‐ＣＯ０１‐アメリカ合衆国商業部門
２． ＤＥ‐ＣＯ０２‐ドイツ商業部門
３． ＤＥ‐ＣＯ０３‐ドイツ住宅部門
である。
ｉｉｉ） これら例示的な３カンパニーに対して、以下の事を示す２つのデータ管理ルール・タイプを生成することができる。すなわち、
ａ． アーカイブ・アクションに対して、
１． ルール・タイプ名（例えば、「ＣＡＡＰＳ＿ＰＡＹＭＥＮＴＳ＿ＡＲＣＨＩＶＥ」）
２． アーカイブを処理するプログラム（例えば、「ＣＰ１３４Ａ１００」）
３． これは「ＣＡＡＰＳ」システム・ルールであるという事実
４． このルールはＨＡＬＣＯコーポレーションのカンパニーに対するものであるという事実
５． 「ＰＡＹＭＥＮＴ」文書は管理されているという事実
６． 制御エンティティとしてのＣＡＡＰＳ＿ＣＯＭＰＡＮＹの使用
７． 管理者のルールは、実際のルール（例えば、国家管理）を生成し維持する必要がある。
ｂ． 削除アクションに対して、
１． ルール・タイプ名（例えば、「ＣＡＡＰＳ＿ＰＡＹＭＥＮＴ＿ＰＵＲＧＥ」）
２． パージを処理するプログラム（例えば、「ＰＡＹＰＵＲＧＥ」）
３． これは「ＡＰＢＤＷ」システム・ルールであるという事実
４． このルールはＨＡＬＣＯコーポレーションのカンパニーに対するものであるという事実
５． 「ＰＡＹＭＥＮＴ」文書は管理されているという事実
６． 制御エンティティとしてのＣＡＡＰＳ＿ＣＯＭＰＡＮＹの使用
７． 管理者のルールは、実際のルール（例えば、「国家管理」）を生成し維持する必要がある。「国家管理」のルールは、管理者が、認定された（複数の）国家内のこれらのカンパニーのみにルールを定義することができるということを暗に示す。
ｉｖ） 国家管理者が、「クリアされた」支払いを表す状態コードを記述することができるように単一パラメータ・タイプを定義することができる。「ＣＡＡＰＳ＿ＰＡＹＭＥＮＴ＿ＡＲＣＨＩＶＥ」ルール・タイプに対する支払い文書「ヘッダ」を収容するＤＢ２（登録商標）表「ＡＰ．ＴＰＡＹ＿ＨＤＲ」に対してパラメータ・タイプ「ＰＡＹ＿ＳＴ＿ＣＤ」は生成される。

次に、国家管理者は、国家管理者の制御範囲内でカンパニーに必要な数だけ特定ルールを生成することできる。例えば、管理者は、ルール・タイプに指定されたアプリケーション・システムに基づいてルールが生成されているインストール済みアプリケーション・システムを選択することができ、次に、ルールを適用する国家及びカンパニーを選択する（エンティティ・ビルド・ロジックは、有効な国家及びカンパニー・セットを動的に生成する）。「ＣＡＡＰＳ＿ＰＡＹＭＥＮＴ＿ＡＲＣＨＩＶＥ」及び「ＣＡＡＰＳ＿ＰＡＹＭＥＮＴＳ＿ＰＵＲＧＥ」ルール・タイプに対して、３つのルールがある。

ＣＡＡＰＳ＿ＰＡＹＭＥＮＴ＿ＡＲＣＨＩＶＥ
１． アメリカ合衆国商業部門（ＵＳ‐ＣＯ０１）の「ＣＡＡＰＳＵＳ」システムに関する「ＣＡＡＰＳ＿ＰＡＹＭＥＮＴ＿ＡＲＣＨＩＶＥ」
ｉ） アクション前の時間：２０
ｉｉ） 測定単位：日
ｉｉｉ） コミット数：５０００（５０００文書ごとに、より多くの同時アクセスを可能にするためデータベースに作業をコミットする。プログラムが少数の適格な文書に遭遇する場合、コミットが実行され、作業単位が完了する。）
ｉｖ） 反復の最大数：４（アーカイブすべき５０００文書の４セットまで可能とする。）
ｖ） データ保存タイプ：「不可欠」（このカンパニーはデータの２つの分類を可能にさせる。処分可能なデータよりも長い期間、不可欠なデータを保持する必要がある。このことは、典型的に文書のみである。）
ｖｉ） イベント名：「２×／Ｍｏｎｔｈ」（この名前は、ルール及び関連のプログラムが月に２度ファイルされるということを暗に示す。特定のスケジュールを実装しこの名前を適切なときに受け渡すのはスケジューリング・ソフトウェア次第である。）
ｖｉｉ） 頻度ＳＱＬロジック：この例では、適用できない
２． ドイツ商業部門（ＤＥ‐ＣＯ０２）の「ＣＡＡＰＳＵＳ」システムに関する「ＣＡＡＰＳ＿ＰＡＹＭＥＮＴ＿ＡＲＣＨＩＶＥ」
ｉ） アクション前の時間：２０
ｉｉ） 測定単位：日
ｉｉｉ） コミット数：２０００
ｉｖ） 反復の最大数：１０
ｖ） データ保存タイプ：「不可欠」
ｖｉ） イベント名：「Ｗｅｅｋｌｙ」
３． ドイツ住宅部門（ＤＥ‐ＣＯ０３）の「ＣＡＡＰＳＵＳ」システムに関する「ＣＡＡＰＳ＿ＰＡＹＭＥＮＴ＿ＡＲＣＨＩＶＥ」
ｉ） アクション前の時間：２０
ｉｉ） 測定単位：日
ｉｉｉ） コミット数：１０００（このカンパニーは、少数の文書を有する。）
ｉｖ） 反復の最大数：５
ｖ） データ保存タイプ：「不可欠」
ｖｉ） イベント名：「Ｗｅｅｋｌｙ」

ＣＡＡＰＳ＿ＰＡＹＭＥＮＴ＿ＰＵＲＧＥ
１． アメリカ合衆国商業部門（ＵＳ‐ＣＯ０１）の「ＡＰＢＤＷ」システムに関する「ＣＡＡＰＳ＿ＰＡＹＭＥＮＴ＿ＰＵＲＧＥ」
ｉ） アクション前の時間：２
ｉｉ） 測定単位：年
ｉｉｉ） コミット数：１００００
ｉｖ） 反復の最大数：２０
ｖ） データ保存タイプ：「不可欠」
ｖｉ） イベント名：「Ｍｏｎｔｈｌｙ」
２． ドイツ商業部門（ＤＥ‐ＣＯ０２）の「ＡＰＢＤＷ」システムに関する「ＣＡＡＰＳ＿ＰＡＹＭＥＮＴ＿ＰＵＲＧＥ」
ｉ） アクション前の時間：２
ｉｉ） 測定単位：年
ｉｉｉ） コミット数：１００００
ｉｖ） 反復の最大数：２０
ｖ） データ保存タイプ：「不可欠」
ｖｉ） イベント名：「Ｍｏｎｔｈｌｙ」
３． ドイツ住宅部門（ＤＥ‐ＣＯ０３）の「ＡＰＢＤＷ」システムに関する「ＣＡＡＰＳ＿ＰＡＹＭＥＮＴ＿ＰＵＲＧＥ」
ｉ） アクション前の時間：２
ｉｉ） 測定単位：年
ｉｉｉ） コミット数：１００００
ｉｖ） 反復の最大数：２０
ｖ） データ保存タイプ：「不可欠」
ｖｉ） イベント名：「Ｍｏｎｔｈｌｙ」

更に、定義済みルールごとに、「クリアされた」支払いを区別するパラメータを、ルール・タイプに対して定義したＰＡＹ＿ＳＴ＿ＣＤについて生成することができる。「ＣＡＡＰＳ＿ＰＡＹＭＥＮＴ＿ＡＲＣＨＩＶＥ」アメリカ合衆国ルールに対してパラメータ・リストを「ＣＬ」及び「ＰＳ」とすることができ、ドイツに対してリストを「ＣＬ」、「ＢＬ」及び「ＡＣ」とすることができる。これら変数は、パージされる適格性を有するビジネス文書セット（例えば、支払い）を更に記述するために「アーカイバ」アーカイブ及びパージ・プログラムによって用いられる。パージすべき支払い文書のみが、「クリアされた」支払い文書である。状態コードのこのリストは、アーカイバ・プログラムに「クリアされた」定義を行う。

複数の実施形態に関して本発明を説明したが、当業者は、請求項の意図及び範囲内で変更を加えて本発明を実施することができることを認識するであろう。

本発明の好適な実施形態によって提供、管理または使用される様々なタイプのエンティティを示す論理ブロック図である。 本発明の好適な実施形態によって提供、管理または使用される様々なタイプのエンティティを示す論理ブロック図である。 本発明の好適な実施形態によって提供、管理または使用される様々なタイプのエンティティを示す論理ブロック図である。 本発明の好適な実施形態によって提供、管理または使用される様々なタイプのエンティティを示す論理ブロック図である。 本発明の一実施形態の機能ブロック図である。 本発明を用いるステップを示す本発明の一実施形態の流れ図である。 本発明を用いるステップを示す一実施形態の流れ図である。 本発明を用いるステップを示す一実施形態の流れ図である。 本発明を用いるステップを示す一実施形態の流れ図である。

Claims (14)

1. データ管理コントローラ及び該データ管理コントローラにより処理されるデータを有するデータベースを含むコンピュータシステムを用いてデータを制御する方法であって、
   前記データ管理コントローラが、前記データベースに記憶されている１つ以上のデータ・オブジェクトのデータ保存ポリシーと関連する１つ以上のデータ管理ルールを含む管理情報を定義するステップと、
   前記データ管理コントローラが、時間起動イベントまたはコンピュータ・ジョブの完了を含むイベントが生じたときに前記データ・オブジェクトを他の記憶システムに移動するためのソフトウェア・モジュールを実行するステップと、
   を含み、
   前記データ管理ルールの各々が、前記データ・オブジェクトに関連するアプリケーション・システムと、前記データ・オブジェクトを識別するパラメータと、前記データ・オブジェクトのアーカイブ管理を実行する前記ソフトウェア・モジュールとを指定し、
   前記データ管理ルールは、保存期間またはストレージ・サイズを含む処理制限が課せられ、
   前記パラメータが、前記１つ以上のデータ管理ルールに関連するデータ管理ルール名を指定するパラメータ・タイプのインスタンスと、エンティティ名と、属性名とを含むように構成され、
   前記イベントが、前記データ管理ルールに従って前記アーカイブ管理を制御するために前記データ管理ルールの少なくとも１つを識別し、前記データ管理ルールによって識別されたデータ・オブジェクトに対してアーカイブ管理動作を実行させ、
   前記管理情報が、前記データ保存ポリシーと関連し、かつエンティティ名を含むエンティティ・タイプのデータ保存ポリシーを記述する名前付きルール・タイプを指定する１つ以上のデータ管理ルール・タイプを含み、前記データ管理ルールが各々前記データ管理ルール・タイプのインスタンスを定義し、
   前記データ管理ルール・タイプが、少なくともコーポレーションＩＤ及びデータ保存ポリシーＩＤを属性として有する、
   方法。
2. 前記データ管理ルール・タイプが、前記アーカイブ管理を制御するのに用いる以下の属性、すなわち、
   i） アプリケーションＩＤ
   ii） アプリケーション・システムＩＤ
   iii） コーポレーションＩＤ
   iv） 管理対象エンティティ名
   v） 制御エンティティ名
   vi） 役割ＣＤ
   vii） 制御日付カラムＩＤ
   viii） データ保存ポリシーＩＤ
   を有する、請求項１に記載の方法。
3. 前記エンティティ・タイプが、一意的に識別される人、場所、事柄、概念またはイベントを定義し、名前属性及び記述属性の少なくとも１つを有し、前記エンティティ・タイプに対して完全なキーを構成する属性を定義する関連のエンティティ・キー属性を有する、請求項２に記載の方法。
4. 前記データ管理ルールが、前記アーカイブ管理を制御するのに用いる以下の属性、すなわち、
   i） インストール済みアプリケーションＩＤ
   ii） エンティティ・キー
   iii） アクション前の時間
   iv） 測定の時間単位
   v） コミット数
   vi） 最大反復
   vii） データ保存タイプ
   viii） イベント名
   を有する、請求項１に記載の方法。
5. 前記データ管理ルールが、インストール済みアプリケーションＩＤと、ビジネス機能コード、アプリケーション・システムＩＤ及びインストール済みアプリケーション記述の少なくともいずれか１つとを有するインストール済みアプリケーション・エンティティに関連する、請求項４に記載の方法。
6. 前記管理情報が、前記データ・オブジェクトを識別する１つ以上のエンティティ・タイプ及び前記エンティティ・タイプを識別するエンティティ・キー属性を含み、前記エンティティ・タイプが、エンティティ名及びエンティティ記述を含む属性を有する、請求項１に記載の方法。
7. 前記エンティティ・キー属性が、エンティティ・タイプ名、エンティティ・キー・シーケンス番号及びキー属性タイプ名を含む属性を有する、請求項６に記載の方法。
8. 前記管理情報が、１つ以上のエンティティ・ビルダを含み、前記エンティティ・ビルダの各々が、前記エンティティ・タイプの１つのインスタンスを生成することによって呼び出されるアルゴリズム・セットを定義し、前記アルゴリズム・セットが、エンティティの固有の識別子を構成する、請求項６または７に記載の方法。
9. 前記管理情報が、１つ以上の属性を有する作業単位エンティティ及びコンピュータ・ジョブ・エンティティを更に含む、請求項１〜８のいずれか一項に記載の方法。
10. 前記エンティティ・キーによって識別された前記データ・オブジェクトの少なくとも１つの前記アーカイブ管理を制御するため、前記作業単位エンティティが、インストール済みアプリケーションＩＤ、データ管理ルール名、エンティティ・キー、作業単位開始日付、作業単位終了日付及び作業単位状態の少なくともいずれか１つを属性として含む、請求項９に記載の方法。
11. 前記管理情報が、前記アーカイブ管理の活動をロギングするために前記コンピュータ・ジョブ・エンティティと関連付けられるデータ管理ログ・エンティティを更に含み、前記データ管理ログ・エンティティが、インストール済みアプリケーションＩＤ、データ管理ルール名、エンティティ・キー、作業単位開始日付、作業単位終了日付、ジョブ番号、ログ・タイムスタンプ、活動状態、ログ済みメッセージ及び取引数の少なくともいずれか１つを含む属性を有する、請求項９に記載の方法。
12. データ管理コントローラ及び該データ管理コントローラにより処理されるデータを有するデータベースを含むコンピュータシステムに、
    前記データベースに記憶されている１つ以上のデータ・オブジェクトのデータ保存ポリシーと関連する１つ以上のデータ管理ルールを含む管理情報を定義するステップと、
    時間起動イベントまたはコンピュータ・ジョブの完了を含むイベントが生じたときに前記データ・オブジェクトを他の記憶システムに移動するためのソフトウェア・モジュールを実行するステップと、
    を実行させ、
    前記１つ以上のデータ管理ルールの各々が、前記データ・オブジェクトに関連するアプリケーション・システムと、前記データ・オブジェクトを識別するパラメータと、前記データ・オブジェクトのアーカイブ管理を実行する前記ソフトウェア・モジュールとを指定し、
    前記１つ以上のデータ管理ルールは、保存期間またはストレージ・サイズを含む処理制限が課せられ、
    前記パラメータが、前記１つ以上のデータ管理ルールに関連するデータ管理ルール名を指定するパラメータ・タイプのインスタンスと、エンティティ名と、属性名とを含むように構成され、
    前記イベントが、前記データ管理ルールに従って前記アーカイブ管理を制御するために前記データ管理ルールの少なくとも１つを識別し、前記データ管理ルールによって識別されたデータ・オブジェクトに対してアーカイブ管理動作を実行させ、
    前記管理情報が、前記データ保存ポリシーと関連し、かつエンティティ名を含むエンティティ・タイプのデータ保存ポリシーを記述する名前付きルール・タイプを指定する１つ以上のデータ管理ルール・タイプを含み、前記データ管理ルールが各々前記データ管理ルール・タイプのインスタンスを定義し、
    前記データ管理ルール・タイプが、少なくともコーポレーションＩＤ及びデータ保存ポリシーＩＤを属性として有する、
    コンピュータ・プログラム。
13. 請求項１〜１１のいずれか一項に記載の方法を実行する手段を含むシステム。
14. 前記１つ以上のデータ管理ルールが前記１つ以上のデータ・オブジェクトがアーカイブされるかパージされるかを特定するように構成される請求項１〜１１のいずれか一項に記載の方法。

Images