JPH0916448A - 情報管理システム - Google Patents

Abstract

(57)【要約】 【目的】バージョン管理機能適用時の情報管理システム
に関し、バージョン関係情報を参照して、媒体移動又は
削除の操作を実行するものを提供することを目的とす
る。 【構成】バージョン管理情報を含む情報に基づいて、あ
るデータ群の中から一つ又は複数の動作対象データを決
定する第一の機能実現手段と、動作対象データに対して
予め登録された処理を行う第二の機能実現手段と、処理
済み動作対象データを媒体移動し、あるいは削除する第
三の機能実現手段とを具備して構成する。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、情報保存機能を有する
システム上で提供されるバージョン（ｖｅｒｓｉｏｎ）
管理機能に係り、そのバージョン管理機能適用時のデー
タ（ｄａｔａ）を保存し、管理するシステムに関する。

【０００２】

【従来の技術】保存庫内に保存されるデータにバージョ
ン管理機能が適用されている場合、該保存庫が保存を要
する情報量（データ量）は、バージョン管理機能未適用
のデータ群のみを保存する場合と比較して飛躍的に増大
する。

【０００３】ここで、バージョン管理機能とは、あるデ
ータが変更される場合、該当データの変更後の状態のみ
ではなく、将来的な使用を予想してデータの旧状態（あ
るいはこれを復元可能な情報）をも併せて保存しておく
機能、及び保存されている旧状態（あるいはこれに類す
る情報）を用いてその時点で使用されているデータに代
わって、指定された旧状態を使用可能な状況にする機
能、である。

【０００４】その時点で使用されていない旧データも、
将来的に使用される可能性を含んでおり、後にデータの
旧状態が必要になる場合がある。従って、たとえ、古い
情報、使用頻度の低い情報であっても安易に削除できな
い。

【０００５】通常であれば、このような、同時には使用
されない多量のデータを保存・管理するために、三次記
憶装置や階層型記憶装置を用いる。三次記憶というの
は、光磁気ディスク（ＭＯ）、磁気テープ（ｔａｐｅ）
等の記憶媒体とその管理装置を意味する。一般的特性と
して大容量であるが、アクセスに比較的長時間を要す
る。ちなみに、代表的な一次記憶はメモリであり、二次
記憶はディスクである。

【０００６】階層型記憶装置というのは、性能の異なる
複数の保存庫（記憶装置）の特性を生かして階層的に
（例えばアクセス所要時間順に）配置したものである。
アクセス頻度や日付等、各種の属性情報を参照すること
により、指定された条件を満たすデータを、階層間（媒
体）で移動することを可能としている。

【０００７】特に階層型記憶装置は、今回保存対象とし
たバージョン機能の適用されたデータ群のように、保存
される情報自体は多量であるが、使用頻度には片寄りが
見られるものに対して有効である。

【０００８】

【発明が解決しようとする課題】ここで一つの問題を取
り挙げる。バージョン間が特殊な関係を保持するとき、
あるデータの特定のバージョンの保存庫の決定に連動さ
せて、他のバージョンの保存庫を決定しなければならな
い場合がある点である。この場合、データの保存庫の移
動は、バージョン間の特殊な関係を考慮したものとする
必要がある。

【０００９】例えば、あるデータを一部変更して新状態
のデータを作成したとき、新状態、旧状態の二つのデー
タをそのまま保存しても良いが、双方をそのまま保存す
るよりも、一方をそのまま保存し、他方については先に
保存されたものと比較した場合の相違（差分）のみを保
存した方が記憶空間の使用効率が良い。

【００１０】バージョン適用されたデータの保存装置で
は、必要とされる記憶容量が増大する。この増大を可能
な限り回避するために保存情報に対する差分管理技術な
どが適用されている。このような差分方式を採用した場
合、後者の差分は前者の情報と同時に使用される。従っ
て、アクセス効率（時間効率）を考えると二つの情報の
保存場所は同一箇所である方が望ましい。

【００１１】また、保存庫の移動に関する問題もある。
保存庫の移動は、記憶領域の効率的な利用を図るために
有効であるが、全体から見たデータ量が減少するわけで
はない。保存庫の移動によって、主たるデータの保存領
域に存在するデータ量が減少することはあるものの、他
の保存領域のデータ量は、抑制されているものの相変わ
らず増加傾向にある。

【００１２】そこで、例えば使用頻度が小さい、あるい
は将来性が見られないにもかかわらず削除には至らない
情報を対象とし、保存庫の移動が行われる場合がある。
そして、この移動に際して、なんらかの処理を希望する
こともある。例えば、データの圧縮保存等を行う場合が
ある。この場合には、より時間性能の劣る場所へ保存庫
を移動し、同時に自動的に該当データの圧縮が要求され
る。

【００１３】本発明は、従来の記憶装置間のデータの移
動方式に加えて、バージョン関係情報を参照し、これを
条件判断要因として処理対象データ群と処理内容を決定
し、移動先保存庫を決定し、また、この決定に基づく操
作を実行する情報管理システムを提供することを目的と
する。

【００１４】

【課題を解決するための手段】本発明によれば、上述の
目的は、前記特許請求の範囲に記載した手段にて達成さ
れる。

【００１５】すなわち、請求項１の発明は、バージョン
管理情報を含む情報に基づいて、あるデータ群の中から
一つ又は複数の動作対象データを決定する第一の機能実
現手段と、動作対象データに対して予め登録された処理
を行う第二の機能実現手段と、処理済み動作対象データ
を媒体移動し、あるいは削除する第三の機能実現手段と
を具備する情報管理システムである。バージョン管理情
報を含む情報には、バージョン・ナンバー、導出関係等
を表すバージョン管理情報の他、環境、各資源の状態等
を表すシステム情報や、データ名、所有者等を表す一般
的なデータ情報もある。

【００１６】また、請求項２の発明は、バージョン管理
情報を含む情報に基づいて、あるデータ群の中から一つ
又は複数の動作対象データを決定する第一の機能実現手
段と、バージョン管理情報を含む情報に基づき、及び必
要に応じて動作対象データに基づいて、ある処理群の中
から特定の処理を決定する第二の機能実現手段と、動作
対象データに対してこの特定の処理を行う第三の機能実
現手段と、処理済み動作対象データを媒体移動し、ある
いは削除する第四の機能実現手段とを具備する情報管理
システムである。

【００１７】また、請求項３の発明は、指定を受けた一
つ又は複数の動作対象データに対して予め登録された処
理を行う第一の機能実現手段と、処理済み動作対象デー
タを媒体移動し、あるいは削除する第二の機能実現手段
とを具備する情報管理システムである。

【００１８】また、請求項４の発明は、バージョン管理
情報を含む情報に基づき、及び必要に応じて指定を受け
た動作対象データに基づいて、ある処理群の中から特定
の処理を決定する第一の機能実現手段と、指定を受けた
動作対象データに対してこの特定の処理を行う第二の機
能実現手段と、処理済み動作対象データを媒体移動し、
あるいは削除する第三の機能実現手段とを具備する情報
管理システムである。

【００１９】また、請求項５の発明は、あるデータ群の
中から、媒体移動され、あるいは削除されたデータを見
つけ、そのデータを復元し、あるいは再構成する機能実
現手段を具備する情報管理システムである。

【００２０】また、請求項６の発明は、媒体移動され、
あるいは削除された前記動作対象データを復元し、ある
いは再構成する機能実現手段を具備する情報管理システ
ムである。

【００２１】本発明は、上記構成によって、複数のデー
タ保存庫の使用と保存庫間のデータ移動とこれに伴うデ
ータ処理を、各データのバージョン特性を考慮して行う
機能を提供する。基本的にはこの機能は、複数のデータ
保存庫を用意して、動作対象のデータ群をある記憶媒体
から、容量面で問題の生じていない（生じにくい）別の
媒体へ移動させる機能、を提供するものである。動作対
象のデータ群は、容量の面で問題が発生した、あるいは
近い将来発生する可能性のあるデータ保存庫中に存在す
る、（使用頻度が非常に低い、使用時期が遠い将来であ
る、等の理由で）当座の必要性が低いにもかかわらず完
全消去には不安があるデータ群などが考えられる。

【００２２】この際、バージョン特性を考慮することに
より、移動対象として候補となるデータ群より、移動す
べきデータ群を導出し、必要に応じて何等かの処理を行
った上で実際の移動を行う。また、移動操作に連動すべ
き各種の処理を自動的に行う。これにより、三次記憶装
置あるいは階層型記憶装置の利点をバージョン機能適用
時のデータ状態に適応した、しかも、より強力な形で、
提供することが可能となる。

【００２３】三次記憶装置あるいは階層型記憶装置で
は、元の記憶媒体上からは限界量以上のデータが存在す
ることなく重要性の低いデータは消滅する。にもかかわ
らず、別の記憶媒体に保存されている（たとえその記憶
媒体が性能上の問題等により通常の使用は避けられてい
るものであったとしても）ため、移動元・移動先の対応
関係、及び、この対応関係を参照して移動先に存在する
データを移動元に復元する機能（あるいはこれに類する
機能）、を提供することにより、該当データの必要時の
再使用が可能となる。

【００２４】上記請求項１の発明は、このようなデータ
群移動操作における基本型である。ユーザ、あるいはベ
ース・システムにより指定された入力と各種の情報を用
いて条件保存部に予め設定された条件に合致するデータ
群を動作対象として選択し、これを対象として登録され
ている処理を行う。ここでいう処理には、各種のデータ
変換、付加などの他に、該当データ群の削除や記憶媒体
の移動（移動元と同一の媒体も許容する）等の階層型記
憶装置により実現される部分を含んでいる。

【００２５】以下の機構を使用する。 ・条件保存部（条件を保存する。） ・条件判断部（条件保存部に保存されている条件を用い
て、指定されたデータ群中に移動・削除対象となるもの
が存在するか否かの判断、及び、必要に応じて処理方式
（移動先と移動形態、等）の読み出し、を実行する。） ・処理保存部（条件判断部が処理を必要と判断したデー
タ群に適用する処理方式と移動先（の記述）を保存す
る。） ・処理部（条件判断部より与えられた判断結果（処理対
象データ群と処理方式）を元に、処理を必要とするデー
タ群を対象として与えられた処理（移動、削除を含む）
を実行する。）

【００２６】なお、条件保存部に条件を保存するにあた
り使用される条件入力機構、は当システム外の機能とし
て別途存在する。処理保存部に保存される保存方式（記
述）に関しても同様である。また、処理部が実行する各
種の処理に関しては、当発明が動作するベース・システ
ム上で、あるいはそのアプリケーション機能として提供
されているものとする。

【００２７】請求項２の発明は、請求項１の発明では固
定されていた処理方式を動的に決定するものである。指
定されたデータ群より条件保存部に予め設定された条件
を満たすデータ群を抽出し（この際、必要に応じて環境
情報、及びデータに付随するバージョン関係情報を使用
する）、データ群、及びこの時点の環境情報、バージョ
ン関係情報を与えることにより、処理方式、及び記憶媒
体（移動元と同一の媒体も許容する。また消去を含む）
を動的に決定し、先に抽出されたデータ群（及び必要に
応じてその関係情報）を対象として、ここで決定された
処理方式、及び記憶媒体移動（移動元と同一の媒体も許
容する。また消去も含む）を実行する。

【００２８】バージョン関係情報はここでは対象決定要
因としてのみではなく、処理決定要因としても使用され
る。以下の機構を使用する。 ・処理方式決定部（処理保存部に保存されている処理方
式決定条件、及び状態取得機能より与えられる各種のパ
ラメータ（引数）を用いて、条件判断部が操作対象とし
て抽出したデータ群に対して適用される処理方式（削
除、移動の別、移動先、移動形態、移動にあたって行う
処理、等）を決定する。） ・状態取得機能。処理方式決定部が処理保存部に保存さ
れている処理方式決定条件を用いて処理方式を一意に決
定する際に使用される各種のパラメータ（引数）の取得
機能。）

【００２９】この場合には処理保存部は、処理方式や対
象データの移動先そのものではなく、与えられたパラメ
ータを用いて、これらを決定できる条件を保存する。ま
た、処理部は、処理方式決定部により決定された処理形
式を対象データ群に対して適用する。処理部の実行内容
は請求項１の発明の場合と同様である。

【００３０】請求項３の発明は、請求項１で用いられた
条件保存部と条件判断部を使用する変わりに、当発明の
外部に位置する機能を用いて行われた判断を用いる。処
理範囲データ群を明示的に指定されると、これらを対象
として、処理保存部に保存されている予め決定されてい
る処理内容を実行するものである。

【００３１】処理対象データ群の直接指定にあたり使用
される入力機構は、当発明の外の機能として別途存在す
る。処理部はここで与えられたデータ群を対象として処
理保存部に保存されている処理方式を実行する。なお、
条件保存部と条件判断部はこの場合には存在しなくとも
よい。

【００３２】請求項４の発明は、請求項２の発明で用い
られた条件保存部と条件判断部を使用する変わりに、ユ
ーザ又はベース・システム上の当発明の外部に位置する
機能を用いて行われた判断を用いる。処理範囲データ群
を明示的に指定されると、これらを対象として、処理方
式決定部が決定した処理方式を実行するものである。

【００３３】処理対象データ群の直接指定にあたり使用
される入力機構は、請求項３と同様当発明の外の機能と
して別途存在する。処理部はここで明示的に与えられた
データ群を対象として、処理方式決定部により決定され
た処理方式を適用する。なお、条件保存部と条件判断部
が存在しなくともよいのは、請求項３の発明の場合と同
様である。

【００３４】さらに、上記方式により処理された、デー
タの復元操作を提供する。請求項５の発明は、請求項１
より請求項４のいずれかの発明の処理対象となったデー
タを対象とする。移動元と移動先の対応づけ可能な情報
の保存（移動された情報に付加する、対応情報のみを移
動元に存続させるなど方法は様々）、及び処理内容を示
す情報の保存を行うことにより、対象データが指定され
た場合に、該当データの移動元と移動先、必要に応じて
復元のために要する処理内容を把握し、これを用いて該
当データを移動元に再移動（復元）させる機能である。

【００３５】必要に応じて処理を行った上での記憶媒体
の移動、という操作自体は、当発明も根本的にはこれま
でに提示された請求項１より請求項４の発明と変わらな
い。ただし、ここで復元対象となるデータ群に関して
は、請求項１より請求項４のいずれかの機能が適用され
ており、この適用時に実行された処理として、復元の際
に要する情報（移動元、処理内容等）を保存して、対象
データ群との対応関係を持つ、という操作が必須にな
る。

【００３６】指定されたデータ群の存在を検索し、発見
されたデータ群の付属情報を参照して復元方法と移動元
を特定し、予め用意されている復元処理の実行と移動元
への再移動を行う。

【００３７】請求項６の発明は、上記請求項１より請求
項４の内一つ以上の機能と、請求項５の機能を組み合わ
せ、情報保存管理機能に組み入れたものである。上記請
求項１より請求項４の発明の少なくとも一つと、請求項
５の発明の他、以下の機構を使用する。

【００３８】・条件判断部に与えられるデータ群を自動
的に（ユーザの指定無しに）決定する機構と、ここで決
定されたデータ群を対象として、請求項１より請求項４
の発明のいずれかの機能を呼び出す機構。 ・あるデータが要求された場合に、必要とされたデータ
群が存在するか否か、及び存在する場合の状態（本来の
形式で存在するか、なんらかの処理が行われて本来とは
異なる形態で、あるいは異なる場所に存在するか）を判
断する機能。 ・要求されたデータが本来の形態で本来の場所に存在し
ないことが確認された場合には、該当データを対象とし
て請求項５の発明を呼び出す機構。

【００３９】

【作用】上記、請求項１より請求項５の発明を実施する
ためのシステム構成例を図１に示す。請求項６に関して
は、上記の構成を使用した応用例であるので、これを内
包したものとなる。

【００４０】請求項１の発明は、図１に示されるよう
に、該当システムが起動される場合、対象となるデータ
群よりある一定条件を満たすデータ群を抽出し、該当デ
ータ群を対象として移動、削除、圧縮後移動、等のデー
タ処理を実行する。データは、いずれかの情報保存部３
２，３３，３４に保存される。

【００４１】ここで、ある一定の条件を満たしているか
否かが判断されるデータ範囲は、システム１０の起動と
共に、条件判断部２０に与えられる。条件保存部３０に
は予め条件が保存されている。条件判断部２０は、この
条件を読み込み、当システム１０の起動時に与えられた
データ範囲より、条件に合致するものを限定する機能を
持つ。条件判断部２０は、その時点のシステム状態、デ
ータ種別、バージョン関係情報を用いることにより実行
される。

【００４２】バージョン関係情報とは、通常データの更
新により消滅するデータの旧状態をなんらかの方法で保
存し、必要に応じて再度使用可能とするものである。従
って、同一のデータ名を持つ複数のデータが（新旧併せ
て）存在することになる。これらのデータを区別するた
めにはデータ名以外になんらかの識別子を必要とする。
この識別子としてバージョンＩＤ、あるいはバージョン
・ナンバーが使用される。従ってバージョン機能の適用
されたデータは本来のデータの他に、この識別子を保持
する。

【００４３】データ処理は、条件に合致したデータに対
して実行される。処理方式に関しては、処理保存部３１
に予め設定されているものとする。なお、図１において
は、条件保存部３０と、処理保存部３１は分割されてい
るが、双方の保存を併せて行う保存庫を用意し、条件と
処理の組み合わせを保存してもよい。

【００４４】逆に言えば、この識別を用いることによ
り、データの特定の（あるいは一定範囲の）バージョン
を決定することが可能となる。これ以外にも、各バージ
ョン間の関係、更新時刻等、バージョン機能の適用によ
り付加される情報が存在する。これらをバージョン関係
情報と呼ぶ。

【００４５】請求項２の発明では、該当システム１０が
起動される場合、対象となるデータ群よりある一定条件
を満たすデータ群を抽出する。そして、その時点の各種
状況を変数（決定要因）とし、決定関数を用いて処理方
式を一意に決定する。抽出されたデータ群を対象とし
て、該当する処理方式に基づいたデータ処理を実行す
る。状態取得機能２３は、処理決定のためのパラメータ
を与える。

【００４６】請求項２の発明では、請求項１の発明のよ
うに、実行される処理が事前に特定されるものと異な
り、処理方式をその状況に応じて様々に変化させること
が可能である。ここで、条件を満たしているかどうかを
判断されるデータ範囲は、システム１０の起動と共に条
件判断部２０に与えられるのは請求項１の発明の動作と
同様である。さらに、条件保存部３０に保存されている
条件を読み込み、その時点のシステム状態、データ種
別、バージョン関係情報等を用いて判断し、当システム
１０の起動時に与えられたデータ範囲より、条件に合致
するものを限定する点も、請求項１の発明の場合に等し
い。

【００４７】この場合、処理保存部３１に保存されてい
るものは、それのみで決定可能な処理方式（の記述）で
はない。条件、及び条件に合致したデータに対する処理
方式を、その場で生成するための、一種の関数である。
この関数は、各種の状況を引数とする。ここで、一意に
決定された処理が、先に条件に合致したデータ群を対象
として実行される。

【００４８】請求項３の発明では、該当システム１０が
起動される場合、処理対象となるデータ群は、外部１１
〜１５からの要因、例えばユーザ指定やシステム呼び出
しにより直接指定される。ここで指定されたデータ群を
対象として一定の処理が実行される。これにより、ユー
ザ、あるいはベース・システムの指示により、予め設定
された条件成立時以外にも任意の時点で、当システムを
呼び出せる。

【００４９】請求項３の発明では、処理対象に関する判
断は実行されない。指定されたデータ範囲がそのまま処
理対象データ範囲となる。この範囲に属するデータ群に
対して保存されている処理方式がそのまま適用される。
このシステムは、請求項１の発明による情報管理システ
ムの特殊な場合、即ち設定された条件が与えられたデー
タ群の全てを対象とするというものであった場合、と考
えることもできる。

【００５０】請求項４の発明では、該当システム１０が
起動される場合、処理対象となるデータ群は外部からの
要因により直接指定される。その時点の状況を変数（決
定要因）とする決定関数を用いて、一意に決定された処
理方式が示す処理内容を、指定されたデータ群を対象と
して実行する。

【００５１】これにより、任意の時点で、その状況に応
じた操作を行うことを可能とする。これは請求項２の発
明の特殊な形と考えることも出来る。処理対象に関する
判断は実行されない点、指定された範囲がそのまま処理
対象となる点は請求項３の発明の場合と同様である。

【００５２】ここで処理保存部３１に保存されているの
は、請求項２の発明と同様、それのみで決定可能な処理
方式（の記述）ではなく、条件、及び条件に合致したデ
ータに対して適用する処理方式をその場で生成するため
の、一種の関数（各種の状況を引数とする）である。

【００５３】処理決定部２１は、この関数を元に、与え
られたデータ群とその時点の状態を示す情報（システム
情報、バージョン関係情報、等）を用いて処理方式を決
定する。外部より直接与えられたデータ群と、処理決定
部２１により決定された処理方式は、そのまま処理部２
２に送られ、決定された処理が実行される。

【００５４】請求項５の発明は、請求項１より請求項４
のいずれかのシステムにより処理されたデータを、移動
元と処理方式が確認可能である状態に保つ（即ち処理と
して、処理前の状態を識別可能な情報の付加操作を含め
る）。これにより、データの移動元と移動先、その復元
方式を把握する。そして、この情報を用いて、移動先の
データを再び移動元に、移動前の形式を伴って、戻すシ
ステムである。

【００５５】これにより、何等かの理由で一旦移動した
データを再度移動元に復元し、過去の状態と変わらない
データを使用可能とする。移動先から移動元へ、データ
に付随した情報により一意に決定される復元操作を行
う、と考えると請求項２又は請求項４の発明の特殊なも
のと考えることも可能である。

【００５６】請求項５のシステムを使用する場合に、請
求項１より請求項４に示したデータ処理機能を使用する
際には、可能であればその処理内容をデータに対応付け
て保存する。可能であればとしたのは、処理として考え
られる操作に、例えば削除のように元の情報自体が保存
されないものが存在するからである。操作の取り消し
（復元）が不可能な場合には、復元を前提とした処理内
容の保存そのものが無意味となるためである。

【００５７】なお、データに付属して保存される処理内
容に代えて復元方式、あるいはこれと同程度の効果が得
られる方式、又はこれを示す情報、例えば別の場所に存
在する情報へのポインタ等を保存してもよい。処理方式
と復元方式の組み合わせに関しては、当システムで認識
しているものとする。

【００５８】それから、請求項５の発明は、このような
処理内容を併せて保持しているデータ、即ち先の請求項
１より請求項４の発明の適用対象となったものを処理対
象とする。処理対象となるデータ群は当システム１０の
起動と共に与えられる。指定方式は、処理前の状態を示
す情報、処理後の状態を示す情報のいずれか、あるいは
双方である。採用される選択肢は、適用システムにより
異なり、また、いずれの方法を選択するかをユーザに選
択させるシステムも構築可能である。

【００５９】処理前の状態を指定することにより対象デ
ータ群の特定を行う場合には、処理前のデータが存在す
る場所に処理後の該当データ、あるいはこれを処理した
ものの記憶場所を示す情報が存在するものとする。ま
た、処理後の該当データ群に関する情報を使用する場合
には、その情報そのものが現在該当データ群が存在する
場所を示しているはずである。

【００６０】従って、いずれにせよ処理後のデータに到
達することが可能である。このデータを用いて、復元法
あるいは復元法を導出可能な情報を取得可能である。取
得された復元法を用いてデータを処理以前の状態に復元
する。

【００６１】請求項６の発明は、請求項１より請求項４
のシステムの内一つ以上、及び請求項５の発明を用い
て、データの処理と復元を自動的に行うデータの保存・
管理機能を提供するものである。先に示した請求項１よ
り請求項５のシステムで定義された機能は一般的にはこ
のような形で使用されるものと考える。

【００６２】

【実施例】ここでは、適用対象システムとして、バージ
ョン管理機能を提供するオブジェクト指向データベース
（ＯＯＤＢ）を考える。同時に、平成５年特許願第２９
６３２２号（以下、先願という）で提示したバージョン
管理モデルの使用を仮定する。このシステムは、存在す
るオブジェクト群中より、任意のものをバージョン管理
機能の適用対象として指定することを可能とする。バー
ジョン管理機能が適用されたオブジェクトのそれぞれの
バージョンを識別するために、ここでは、オブジェクト
名に加えてバージョン・ナンバーを識別子として使用す
る。

【００６３】オブジェクトＡに対してバージョン機能が
適用される場合、Ａという同一名称を持つ複数のオブジ
ェクト群が存在する。これを識別するためにバージョン
・ナンバーを採用する。バージョン・ナンバーは最小値
を‘１’とし、増分を‘１’として、同一名称を持つオ
ブジェクトに順番に付される。

【００６４】ここでは何回かのバージョン・アップが生
じて、Ａのバージョン・ナンバー１よりバージョン・ナ
ンバーＮまでが存在する状況を考える。これらを以下で
は、Ａ［１］、Ａ［２］、・・・、Ａ［Ｎ］のように表
記する。最新版はＡ［Ｎ］である。

【００６５】図２は、削除前のオブジェクト状態を示す
図である。図２には、保存庫中のオブジェクトＡにバー
ジョン管理機能が適用されている状態を示されている。
Ａの最新バージョンは、バージョン・ナンバー８、すな
わちＡ［８］である。但し、この時点でＡとして動作対
象となっているのはバージョン・ナンバー７のものであ
ることが示されている。なお、同一保存庫内に存在する
Ｂ，Ｃ，Ｄは、バージョン管理機能の適用対象とはなっ
ていないオブジェクトである。

【００６６】図２において、保存庫には、Ａに関するデ
ータ・オブジェクトのほか、丸い図形で示され、バージ
ョン管理機能提供のために新たに用意されたオブジェク
トも保存されている。四角い図形は、本来のデータ・オ
ブジェクトであり、このオブジェクトは、バージョン管
理機能を提供するために新たに用意されたそれ以外のオ
ブジェクトとは独立に存在している。

【００６７】バージョン管理機能が存在するシステム
は、バージョン管理機能の存在しないシステムと比較し
た場合に、必要に応じて過去の時点の情報、Ａ［１］、
・・・、Ａ［Ｎ−１］を使用可能である、という長所を
持つ。一方、旧情報の保存のためにより大きな容量を要
する、という短所も見られる。

【００６８】バージョン管理機能が存在するシステムに
必要とされる記憶容量は、バージョン数の増加に伴い増
大するので、何等かの処置を取ることが必要である。即
ち保存されるオブジェクトを減らすことである。本来で
あれば、各バージョンの必要度はユーザが認識している
はずである。よって、後に詳述するように、ユーザがそ
れぞれのバージョンを認識し、必要とされないバージョ
ンを削除することが望ましい。しかし、この方法は、ユ
ーザに対する負荷を高めることにもなる。そこで、条件
を付加し、条件に合致するものを対象として自動的に削
除指示を発するシステムを提供する。

【００６９】このようなシステムを実現する場合に、希
望する動作とそのために各部に保存される条件・処理方
式、の組み合わせ例を以下に示す。 〔動作概要〕対象オブジェクトをＡとして、オブジェク
トＡの、登録時の状態、即ちバージョン・ナンバー１、
及び最新よりＬ個分のみを保存する。 〔指定データ群〕Ａという名称を持つ全てのオブジェク
ト、即ちＡ［＊］を指定する。 〔対象条件〕Ｘ［２］〜Ｘ［ｌａｓｔ−Ｌ］（ｌａｓｔ
≧Ｌ＋２）、Ｘは任意のオブジェクト。 〔処理方式〕削除。

【００７０】外部より何等かの要因、ユーザによる直接
指定、登録されたタイミングに自動起動、等により当シ
ステムが起動される。起動と同時に指定データ群として
Ａ［＊］、即ちそのバージョン・ナンバーによらずオブ
ジェクト名がＡである全てのものが指定される。

【００７１】このデータ群が条件判断部に送られると、
判断部は条件保存部より処理対象となるための条件を呼
び出す。条件保存部には条件が保存されている。この条
件が条件判断部により実行され、ここでの処理対象が、
Ａ［２］〜Ａ［Ｎ−Ｌ］に限定される。

【００７２】次に処理方式を呼び出す。処理方式は処理
保存部に保存されている。上記の動作概要には、対象デ
ータの削除実行を記述しているので、処理部は、先に限
定されたデータ群を対象として削除処理を行う。なお、
以上の操作の際に必要な条件、処理、の記述形式の一例
を以下に示す。

【００７３】 /*削除実行*/ defineProcedure EX01 J:Jouken(data) object data ; VObj = data.GetversionObject() ; /* version関係情報保存objectを取得 */ if(VObj.VersionNo == 1) return(FALSE) ; else if(VObj.VersionNo =< VObj.Historical.Lastversion - GetNoForStorage()) /* GetNoForStorage()はユーザ指定の保存個数の取得 */ return(TRUE) ; else return(FALSE) ; ; defineProcedure EX01 S:Syori(data) object data ; data.delete() ; /* 削除設定 */ ;

【００７４】 defineProcedure Sousa(data group) object set data group ; data group.open() ; if(data group.eoi()) element = data group.get() ; /* data group群の要素それぞれに対して */ if(EX01 J:Jouken(element) != TRUE) /* 条件に合わなければ以下の処理を実行せずに次のdataを参照する */ continue() ; ; EX01 S:Syori(element) ; /* 処理実行 */ else data group.close() ; ; ;

【００７５】ＥＸ０１＿Ｊ：Ｊｏｕｋｅｎ（ｄａｔａ）
は条件保存部に保存される条件記述の一例であり、動作
対象を決定する機能である。また、ＥＸ０１＿Ｓ：Ｓｙ
ｏｒｉ（ｄａｔａ）は処理保存部に保存される処理記述
の一例であり、削除を実行する機能である。Ｓｏｕｓａ
（ｄａｔａ＿ｇｒｏｕｐ）は上記機能を制御する機能で
ある。

【００７６】図３は、削除処理後のオブジェクト状態を
示す図である。ここでは、保存庫中のオブジェクトＡに
対して削除操作が為され、旧バージョンのいくつかが削
除された後の状態を示している。最新五個（Ａ［４］よ
りＡ［８］まで）と作成時の状態（Ａ［１］）を除く全
バージョン（Ａ［２］，Ａ［３］）が削除されているこ
とがわかる。

【００７７】なお、機能の起動はシステム依存であり、
例えばバージョン・アップ機能中で呼び出す、あるいは
新規バージョンが生成されたことを示すシグナルをキャ
ッチするデーモンとして実行する、ユーザが陽にタイミ
ングを指定して実行させる、等の方法が存在する。

【００７８】前出のバージョン数をＬに抑える、という
目的の場合には、前者二つはバージョン・ナンバー（Ｌ
＋１）のものが生成された時点以後、バージョン・アッ
プの度に１オブジェクトずつ削除され、最後の方式の場
合にはその時点で存在するバージョン数を確認し、Ｌ個
を越えるものがまとめて削除される。

【００７９】ところで、複数の記憶媒体、即ち保存庫と
して使用可能なデータベース（ＤＢ）を考える。それぞ
れの保存庫の容量、性能、性質は異なっているものと仮
定する。すると、このデータベースの使用法としては以
下のような方法が望ましいと思われる。

【００８０】・情報の利用特性（使用頻度や重要性、最
新参照時刻等）を保存場所決定の１要因とする。用意さ
れている各保存庫はその特性に応じて使い分けがなされ
る。例えば、使用頻度の高いオブジェクトに関しては高
性能の、特に高速アクセス可能な保存庫に保存し、逆に
使用頻度の低いものに関しては低速保存庫に保存する。 ・情報の属性・性質を保存場所決定の１要因とする。例
えば、容量の大きい情報の保存のためには、容量の大き
い保存庫を選択する。また、１情報の容量が大きい場合
には必要に応じて容量圧縮手法を採用する。 ・その他、各保存庫の状況を保存場所の特定のための参
考にする。例えば、特に巨大なデータの保存が要求され
た場合には、残存量の大きい保存庫への保存を検討す
る。

【００８１】ここで、仮想削除と呼ばれる機能を導入す
る。仮想削除とは、ユーザにより削除指示が出された場
合にその時点で対象情報の削除を行わない、即ち、対象
の物理的削除操作を遅延させる機能である。ここでは、
情報間に複雑な関係があり、特に対象情報を陽に指定せ
ずに使用される状況が多発する場合に不用意な情報削除
が他の情報に与える悪影響を排除する、ことを目的とし
て使用される。

【００８２】先に説明した、請求項１の発明によった削
除操作の代わりに、この仮想削除機能を使用した場合を
考える。仮想削除の採用は、削除指示が出された情報を
使用せざるを得ない状況が発生することを考えてのこと
である。従って、一般的には、削除指示が出されている
ことを示す何等かの情報がオブジェクトに付加されてい
るのみで、情報自体に対する変更は生じていないと思わ
れる。

【００８３】しかし、ここではこの仮想削除対象となっ
た情報に対し、以下のような操作を行うことを仮定す
る。 ・一般データ（一定サイズ（しきい値）未満のオブジェ
クトを一般データとする。一般データは全ての保存庫中
でその時点の残存容量が一番大きいものに移動させ
る。） ・長大データ（一定サイズ（しきい値）以上のオブジェ
クトを長大データとする。長大データは長大データ用保
存庫の内その時点の残存容量が一番大きいものに移動さ
せる。移動が不可能な場合には元の保存庫にそのまま置
く。ただし圧縮保存する。）

【００８４】このような機構を請求項２の発明を用いて
実現する。この場合には、条件保存部に保存される条
件、処理保存部に保存される処理方式、は以下のように
なる。 〔動作概要〕請求項１の発明の場合と同様、登録時の状
態と最新よりＬ個分のみを正規保存、それ以外に関して
は削除機能が適用される。但し、ここで採用されるもの
は仮想削除であり、さらに、仮想削除対象が物理的削除
の対象となるタイミングに関しては取敢えず考えないも
のとする。 〔指定データ群〕ＤＢ１：Ａという名称を持つ全てのオ
ブジェクトを指定する。ここでＤＢ１：Ａは保存庫ＤＢ
１中に存在する情報名Ａのオブジェクト（の全バージョ
ン）を意味する。 〔対象条件〕Ｘ［２］〜Ｘ［ｌａｓｔ−Ｌ］（ｌａｓｔ
≧Ｌ＋２）、Ｘは任意のオブジェクト。 〔処理方式〕仮想削除 〔動作概要〕仮想削除対象となっているオブジェクトを
対象として記憶媒体移動を実行する。 〔指定データ群〕上記に同じ。ＤＢ１：Ａという名称を
持つ全てのオブジェクトを指定する。 〔対象条件〕Ｘ［ｘ］、但し、Ｘ［ｘ］．Ｄｅｌｅｔｅ
＝＝ＯＮ

【００８５】〔処理方式〕オブジェクトサイズが一定サ
イズ（しきい値）以上？ 長大データ用保存庫の内、一番容量の大きいものへ移動
可能？ 移動 それ以外の場合 圧縮 それ以外（オブジェクト・サイズが一定サイズ（しきい
値）未満）の場合、全保存庫の内、一番容量の大きいも
のへ移動可能？ 移動 それ以外の場合 無変化

【００８６】当システムが起動されると、まず条件判断
部は最初の記述を参照して、 対象：Ａ［２］〜Ａ［Ｎ−Ｌ］ 処理：Ａ［＊］．Ｄｅｌｅｔｅ＝ＯＮ を得る。

【００８７】処理部は、この操作（スロットへの値の設
定）を行う。仮想削除対象となったものに対する処理が
シグナル・キャッチ（デーモン起動を含む）されている
のであれば、直後にここでＤｅｌｅｔｅにＯＮと設定さ
れたオブジェクト群を対象として保存庫の変更が生じ
る。

【００８８】例えば、ここで複数の保存庫の性能が表１
のようになっていると仮定すると、オブジェクトＡが長
大データであるのなら、仮想削除対象となるオブジェク
ト（図中ではＡ［２］、Ａ［３］）は長大データ用保存
庫ＤＢ４、ＤＢ５の内空いている方（表を参照するとこ
こではＤＢ５）に移動され、一般データであればＤＢ３
に移動される。

【００８９】

【表１】

【００９０】なお、条件・処理の決定のため必要とされ
る情報は当発明が適用されているシステム上において取
得可能であるものとする。なお、適用対象がＯＯＤＢで
ある場合の複数保存庫の定義と状態取得に用いられるオ
ブジェクトの記述例を以下に示す。

【００９１】 defineClass DefineDB instance: String DBName ; /* 保存庫名 */ Integer Att ; /* 属性：ディスク＝０、ファイル＝１、光磁気ディス ク＝１０、・・・ */ Integer Speed ; /* アクセス速度：最高＝１０、最低＝０ */ Integer Space ; /* 記憶容量 */ Integer Purpose ; /* 目的：汎用＝０、バイナリー用＝１、長大デー タ用＝１０ */ Integer GetCapacity() ; /* 残存容量（余白）取得機能 */ ;

【００９２】 DefineDB:ins1 = DB1, 0, 10, 60Mbyte, 0) ; DefineDB:ins2 = DB2, 0, 8, 100Mbyte, 1) ; DefineDB:ins3 = DB3, 20, 3, 200Mbyte, 0) ; DefineDB:ins4 = DB4, 1, 5, 100Mbyte, 10) ; DefineDB:ins5 = DB5, 10, 3, 1Gbyte, 10) ;

【００９３】この記述は、システム上で使用可能な保存
庫とその性能の定義例である。容量、アクセス速度など
状況に寄らず一定のものに関してはその値が、その時点
の使用可能容量等、時間変化を生じるものに関しては関
数の形で定義されている。値を取得する、あるいは関数
を実行することにより対象ＤＢの性能・現状が取得可能
である。ＤＢの状態を条件、あるいは処理の決定要件と
する場合には、このような定義が、当発明の外部におい
て用意されていることが必要である。

【００９４】ところで、ユーザが陽にタイミングを指定
して実行させるのであれば、後者の操作は続けて実行さ
れることも、次の機会に譲られることも考えられる。な
お、ここではユーザが必要性を認識した場合の情報の復
元、及び、これを可能とするための、準備に関しては言
及されていないが、通常、この機能は、請求項５の発明
で指定された機能と組にして使用され、情報の移動や変
更に先立ち、あるいは同時に、そのための準備がなされ
ることになる。なお、この際システムは各保存庫の条件
取得機能を保持しているものとする。

【００９５】以上で、指定された範囲より予め設定され
た条件を満たすオブジェクトに対してある操作を行う機
能について提示した。しかし、実際には、条件判断をシ
ステムが行う以上にユーザがユーザの知識・認識を用い
て実行した方が効率のよい場合、特定の情報を指定する
ことにより、指定オブジェクトのみを対象として操作を
行う方が都合のよい場合が存在する。このような場合に
は、請求項１の代わりに請求項３の発明を、請求項２の
代わりに請求項４の発明を使用する。

【００９６】請求項１の発明の例では、機能の起動は即
ち、最新Ｌ個分及び生成時の状態以外のものの自動的削
除であった。しかし、複数のバージョンの重要性や使用
頻度は、ユーザが陽に認識し考えられる。バージョン・
アップの動機を最終的に認識しているのはユーザであ
る。あるオブジェクトのバージョン・アップが同一のプ
ロジェクトに属する人間の変更を受けた重要なものであ
るのか、それとも登録ミス（例えば、単なるタイプ・ミ
スによるオーバライトをバージョンとして登録してしま
った、等）なのかはユーザのみが判断可能である。

【００９７】従って、登録された条件判断文を使用せ
ず、処理対象となるオブジェクトをユーザが陽に指定す
る方が効率のよい場合が存在する。この場合には、各種
条件判断を行うことなくユーザが陽に特定のものを、例
えば、｛Ａ［５］、Ａ［６］｝のように指定し、これの
みを処理、即ちオブジェクト削除、の対象とする。

【００９８】先に請求項２の発明に関する説明でも述べ
たが、保存庫間における情報の移動は再度の移動、即ち
移動元への復帰を前提としたものが多い。この復帰機能
としては請求項５の発明が存在する。例えば、仮想削除
操作であるが、この機能は、本来削除されるべきである
が、将来的な使用の可能性を否定できないもの、を対象
とする。

【００９９】従って、通常操作における使用頻度は小さ
く、この場合にはユーザの認識外の記憶場所（もちろ
ん、システムは把握している）に保存されていても良い
が、必要と確認された場合には以前の状態で使用可能で
あることが必須である。このような、言い換えれば、オ
ブジェクト単位のバックアップ／リストア機能、を提供
することが必要になる。請求項５の発明は、このリスト
ア機能として使用可能である。

【０１００】バックアップ機能としては先の請求項２の
発明を使用する。請求項２の発明で使用される処理には
復元を前提として移動元を始めとする復元情報をオブジ
ェクトに付随させる操作が組み入れられる。移動先と移
動元を対応付けるための情報、及び移動時に行われた処
理に関する情報を対応させる操作である。

【０１０１】請求項２の発明は、オブジェクトＤＢ１：
Ａ［２］、ＤＢ１：Ａ［３］に対して適用されている。
この際、処理判断としては以下のものが保存されていた
とする。 処理：保存形態は無変化、ＤＢ３への移動。（この場合
には復元するために要する情報は以下の通りである。） 対象データがＤＢ１中に存在し、ＤＢ３へ移動したとい
うこと。対象データは圧縮、暗号化等の処理をなんら受
けていないこと。

【０１０２】これらの情報は元のオブジェクトと対応し
ていればよく、移動元を含んだ情報が移動先でオブジェ
クトと共に存在することも、また、移動先を含んだ情報
が移動元に保存されていても良い。ここでは、この保存
媒体の移動機能はバージョン管理機能に組み入れられて
いるものとし、移動先と移動元を対応付ける情報もバー
ジョン関係情報の一部として保持されている。

【０１０３】請求項２の発明が起動されると、システム
はＡ［２］、Ａ［３］は仮想削除されるべきであり、結
果的にＤＢ３に移動されるべきであると認識する。シス
テムは、Ａ［２］、Ａ［３］、それぞれに対し、付属情
報として移動先がＤＢ３であるという事実、移動時にな
んら変更を加えられていないという情報を保存する。も
ちろん、移動元がＤＢ１であるという情報も必要であ
る。

【０１０４】図４では、この移動元を示す情報を追加す
る代わりに、バージョン関係情報をそのままＤＢ１に残
すことにしている。図４のオブジェクト状態は、ＤＢ中
のオブジェクトＡに対して請求項４の発明が作用し、旧
バージョンのいくつかが仮想削除対象となった状態を示
す。最新五個（Ａ［４］よりＡ［８］まで）と作成時の
状態（Ａ［１］）を除く全バージョン（Ａ［２］とＡ
［３］）を仮想削除対象とする。

【０１０５】これで請求項５の発明が使用可能となる。
例えば、ユーザがＡ［２］の参照を希望する、あるいは
他のオブジェクトがＡのこのバージョン・ナンバー２の
参照を希望する場合を考える。システムはまず情報の記
憶場所の確認を行う。ここでは該当するオブジェクトが
移動されていることがわかる。

【０１０６】確認手段としては、移動されたオブジェク
トの一覧が存在し、該当オブジェクトがその中に記録さ
れている。移動元に残されていたバージョン関係情報中
に移動を示す値が記録されている。該当オブジェクトの
移動後の場所にアクセス可能であり、これに移動前の場
所が示されている。等が存在する。

【０１０７】図４の例では、仮想削除、即ち記憶媒体移
動であるから、これを示すフラグ、ＤｅｌｅｔｅｄがＯ
Ｎになっていることにより認識される。これと共に移動
後の場所が認識される。ここではＳｔｏｒａｇｅ＝ＤＢ
３である。さらに、これに対しては移動時にそれ以外の
変化を生じておらず、これを復元するためにはそのまま
移動元に戻すのみで済むことがわかる。

【０１０８】システムは、ＤＢ３を検索し、希望するオ
ブジェクトのＡ［２］を発見し、これのＤＢ１への再移
動を行う。なお、ここでは必要なかったが、なんらかの
処理も必要であればこの時点で行う。その場合に使用さ
れる圧縮操作、復元操作等に関してはシステムで提供さ
れているものとする。請求項２の発明を用いて行った移
動と、請求項５の発明を用いた復元操作を行うための三
つの条件記述例を以下に示す。

【０１０９】 /* 仮想削除実行 */ defineProcedure EX01:Jouken(data) object data ; VObj = data.GetversionObject() ; /* バージョン関係情報保存オブジェク トを取得 */ if(VObj.VersionNo == 1) return(FALSE) ; else if(VObj.VersionNo =< VObj.Historical.Lastversion - GetNoForStor age()) /* ＧｅｔＮｏＦｏｒＳｔｏｒａｇｅ（）はユーザ指定の保存個数の取得 */ return(TRUE) ; else return(FALSE) ; ; defineProcedure EX1:Syori(data, VObj) object data ; object Vobj ; VObj.Deleted = ON ; /* 仮想削除設定 */ ;

【０１１０】 defineProcedure Sousa(data group) object set data group ; data group.open() ; if(data group.eoi()) element = data group.get() ; /* data group群の要素それぞれに対し て */ if(Jouken(element) != TRUE) /* 条件に合わなければ以下の処理を実行せずに次のデータを参照 する */ continue() ; ; VObj = element.GetversionObject() ; /* バージョン関係情報保存オ ブジェクトを取得 */ Syori(element, VObj) ; /* 処理実行 */ /* 但し実行にあたり VObj に示されたバージョン関係情報を必要とす る */ else data group.close() ; ;

【０１１１】以上は、仮想削除操作の条件、及び処理方
式の記述例である。適用システムとしてオブジェクト指
向データベース（ＯＯＤＢ）を対象とする場合、条件、
処理等もオブジェクトとして定義可能である。この場合
には、条件、及び処理方式は同一オブジェクトＥＸ１上
に対になって存在している。このような場合には条件保
存部と、処理保存部が合体しており、条件、処理、共に
同一の保存領域を使用していることになる。すなわち、
条件保存部兼処理方式記述保存部がデータ保存庫と同様
オブジェクト記述を可能とする場合には、このオブジェ
クトＥＸ１がこの保存部内に存在する。

【０１１２】 /* 仮想削除対象の保存庫移動 */ defineProcedure EX2:Jouken(data) object data ; VObj = data.GetversionObject() ; /* バージョン関係情報保存オブジェク トを取得 */ if(VObj.Deleted == ON)/* 対象が仮想削除されている場合 */ return(TRUE) ; else return(FALSE) ; ; defineProcedure EX2:Syori(data group) object set data group ; data group.open() ; if(data group.eoi()) element = data group.get() ; /* data group群の要素それぞれに対し て */ if(Jouken(element) != TRUE) /* 条件に合わなければ以下の処理を実行せずに次のデータを参照 する */ continue() ; ; if(element.GetSize() > SIZE THRESHOLD) /* 長大データとして扱う */ MaxDB = Max(DB4.GetCapacity(),DB5.GetCapacity()) ; /* 一番残 量の大きいＤＢを選んで */ if(MaxDB.GetCapacity > element.GetSize()) /* 容量が充分であれば */ VObj = element.GetVersionObject() ; /* バージョン関係情 報保存オブジェクトを取得 */ VObj.Storage = MaxDB ; /* 移動先 */ VObj.Operation = NULL ; /* 処理内容 */ element.move(MaxDB) ; /* 移動 */ else /* 容量が足りない */ VObj = element.GetversionObject() ; /* バージョン関係情 報保存オブジェクトを取得 */ VObj.Storage = NULL ; /* 移動先なし */ VObj.Operation = “compress” ; /* 処理内容 */ element = element.compress() ; /* 処理 */ ; else /* 一般データとして扱う */ MaxDB = Max(DB1.GetCapacity(),DB2.GetCapacity(),...,DB5.GetC apacity()) ; if(MaxDB.GetCapacity > element.GetSize()) /* 容量が充分であれば */ VObj = element.GetVersionObject() ; /* バージョン関係情 報保存オブジェクトを取得 */ VObj.Storage = MaxDB ; /* 移動先 */ VObj.Operation = NULL ; /* 処理内容 */ element.move(MaxDB) ; /* 移動 */ else /* 容量が足りない */ VObj = element.GetversionObject() ; /* バージョン関係情 報保存オブジェクトを取得 */ VObj.Storage = NULL ; /* 移動先なし */ VObj.Operation = NULL ; /* 処理なし */ ; ; else data group.close() ; ; ;

【０１１３】以上は、仮想削除対象の記憶媒体移動の条
件、及び処理方式の記述例である。復元操作を前提とし
ているため、各種の情報保存を併せて行っている。条件
保存部が処理方式記述保存部を兼ねていることは先の記
述例の場合と同様である。即ち、条件保存部兼処理方式
記述保存部がオブジェクトＥＸ２を保持している。

【０１１４】 /* 仮想削除対象の復元 */ defineProcedure EX3 J:Jouken(data) object data ; VObj = data.GetversionObject() ; /* バージョン関係情報保存オブジェク トを取得 */ if(VObj.Deleted == ON) return(TRUE) ; else return(FALSE) ; ; defineProcedure EX3 S:Syori(data group) object set data group ; data group.open() ; if(data group.eoi()) element = data group.get() ; /* data group群の要素それぞれに対し て */ if((GetJouken(Syori = EX3 S))(element) != TRUE) /* 条件に合わなければ以下の処理を実行せずに次のデータを参照 する */ continue() ; ; VObj = element.GetVersionObject() ; /* バージョン関係情報保存オ ブジェクトを取得 */ if(VObj.Deleted == ON) /* 仮想削除対象となっているものを対象 */ data = element.remove(Vobj.Storage) ; /* elementを移動元にデ ータとして置く */ if(VObj.Operation != NULL) /* 処理がしてあれば */ data.Opposite(VObj.Operation) ; /* 処理を取り消し */ VObj.DataObject = data ; /* 復元されたデータにリンクを張 る */ VObj.Deleted = OFF ; /* 仮想削除も取り消し */ ; ; else data group.close() ; ; ;

【０１１５】以上は、先の二つの記述例に対応する復元
方式の記述例である。ここでは対象条件がオブジェクト
ＥＸ３＿Ｊに、処理方式記述がオブジェクトＥＸ３＿Ｓ
に、それぞれ保存されている。従って、条件保存部がＥ
Ｘ３＿Ｊを、処理保存部がＥＸ３＿Ｓをそれぞれ保存す
る。条件保存部と、処理方式保存部は、分割されて存在
する。それぞれにＥＸ３＿Ｊ、ＥＸ３＿Ｓが保存されて
いる。なお、与えられたデータ群より処理対象データ群
を選択するための条件と、この条件を満たすデータ群を
対象とする処理の対応は何等かの方法で付けておくもの
とする。ここでは、関数ＧｅｔＪｏｕｋｅｎ（ｓ）がこ
れにあたる。この関数は処理を与えることによりこれに
対応する条件を検索・抽出する機能を持つ。

【０１１６】なお、以上のような機能を組み入れたＯＯ
ＤＢは、それ自体が請求項６のシステムの実現例とな
る。先願で提示されたバージョン管理モデルの実装シス
テムに対し、当発明で提示された機能群を組み入れるこ
とにより、より必要記憶容量に配慮したものを作成可能
である。先願で提示したバージョン管理モデルを実現す
るために用意されたバージョン関係情報に対して、ここ
で提示されたバージョン単位の記憶媒体移動と復元機能
の実現の際に使用される情報群を組み入れた場合、のデ
ータ構造を図６に示す。

【０１１７】図６は、媒体移動を用いたオブジェクト退
避とその復元機能を提供した場合のバージョン関係情報
の一構成例である。図中、リストにおける‘Ｎ’は、
‘Ｎｉｌ’を表している。また、データ・オブジェクト
の‘ＨＯ’は、ヒストリカル・オブジェクト（Ｈｉｓｔ
ｏｒｉｃａｌ Ｏｂｊｅｃｔ）を示す。

【０１１８】また、ヒストリカルにおけるＨ１〜Ｈ１１
は、それぞれ、データ・オブジェクト・ネーム（Ｄａｔ
ａＯｂｊｅｃｔＮａｍｅ）、バージョン・ステート・フ
ラグ（ＶｅｒｓｉｏｎＳｔａｔｅＦｌａｇ）、バージョ
ン・コントロール・オブジェクト（ＶｅｒｓｉｏｎＣｔ
ｌＯｂｊｅｃｔ）、バージョン・チャイルド・リスト
（ＶｅｒｓｉｏｎＣｈｉｌｄＬｉｓｔ）、ファースト・
バージョン（ＦｉｒｓｔＶｅｒｓｉｏｎ）、ラスト・バ
ージョン（ＬａｓｔＶｅｒｓｉｏｎ）、デフォールト・
バージョン（ＤｅｆａｕｌｔＶｅｒｓｉｏｎ）、アクテ
ィブ・バージョン（ＡｃｔｉｖｅＶｅｒｓｉｏｎ）、デ
リート・フラグ（ＤｅｌｅｔｅＦｌａｇ）、オーナー
（Ｏｗｎｅｒ）、グループ（Ｇｒｏｕｐ）を表してい
る。

【０１１９】また、バージョンにおけるＶ１〜Ｖ１５
は、それぞれ、デプス・オン・トリー（ＤｅｐｔｈＯｎ
Ｔｒｅｅ）、バージョン・ナンバー（ＶｅｒｓｉｏｎＮ
ｏ）、データ・オブジェクト（ＤａｔａＯｂｊｅｃ
ｔ）、ヒストリカル・オブジェクト（Ｈｉｓｔｏｒｉｃ
ａｌＯｂｊｅｃｔ）、バージョン・ペアレント・リスト
（ＶｅｒｓｉｏｎＰａｒｅｎｔＬｉｓｔ）、バージョン
・チャイルド・リスト（ＶｅｒｓｉｏｎＣｈｉｌｄＬｉ
ｓｔ）、プレ・バージョン（ＰｒｅＶｅｒｓｉｏｎ）、
ネクスト・バージョン（ＮｅｘｔＶｅｒｓｉｏｎ）、デ
リーテッド（Ｄｅｌｅｔｅｄ）、ストレージ・プレース
（ＳｔｏｒａｇｅＰｌａｃｅ）、オペレーション（Ｏｐ
ｅｒａｔｉｏｎ）、オーナー（Ｏｗｎｅｒ）、グループ
（Ｇｒｏｕｐ）、クリエート・タイム（ＣｒｅａｔｅＴ
ｉｍｅ）、コメント（Ｃｏｍｍｅｎｔ）を表している。

【０１２０】図中、Ｖ９〜Ｖ１１のデリーテッド、スト
レージ・プレース、オペレーションが今回の機能を追加
するために用意され、変更された部分である。それぞれ
以下の意味を持つ。

【０１２１】デリーテッドは、当バージョン管理情報保
存オブジェクトが管理しているバージョンが仮想削除対
象となっているか否かを示す。ＯＮ（仮想削除対象、即
ち該当バージョンの本体は別の媒体に存在する）、ＯＦ
Ｆ（削除対象とはなっていない）のいずれかの値を取
る。

【０１２２】ストレージ・プレースは、当バージョン管
理情報保存オブジェクトが管理しているバージョンの本
体が媒体移動の対象となっている場合に使用される。媒
体名、あるいはＮＩＬ（記憶場所移動の対象となってい
ない）のいずれかの値を持つ。

【０１２３】オペレーションは、当バージョン管理情報
保存オブジェクトが管理しているバージョンの本体が媒
体移動の対象となっている場合に使用される。媒体移動
時に何等かの処理が為されている場合には、それを記述
する。ここに保存される値の候補としては、圧縮、暗号
化、ＮＩＬ（記憶場所移動の対象となっていない）等が
考えられる。

【０１２４】以上の他、ここで示された機能群の利用例
としては、例えば、業務文書の保存期間の設定と保存期
間外の文書の廃棄の自動化、が挙げられる。条件及び処
理として、その発行あるいは生成が該当機能実行時（そ
の時点の時刻）と比較して一定期間以前の時刻であると
いうことと削除を設定する。

【０１２５】条件判断部には全文書が与えられる。これ
に対して処理実行部に送信されるのは予め設定された条
件に該当するもの、即ち保存期間が過ぎているもの、の
みである。これら文書は削除されるべきであるから、対
象処理として削除が実行される。なお、削除対象となっ
た古い文書の再使用は考えられていないので、このよう
な操作の場合には復元を前提とした情報付加は行われな
い。

【０１２６】以上の操作を自動的に、定期的に起動する
機構を当発明の外部に用意することにより、文書の保存
期間の設定と自動廃棄を実現可能である。なお、この文
書廃棄の例の場合でも、現時点と比較して一定期間以前
のものを廃棄する場合には、このように請求項２の発明
を用いるが、日付を陽に指定して、それ以前のものを削
除するのであれば、請求項１の発明で十分である。

【０１２７】この他にも、一定期間全くアクセスされな
かった文書を性能の劣る媒体へ移動し、さらに一定期間
保存し必要とされない場合には該当情報を物理的に削除
する、等の操作を行うシステムを構成することが可能で
ある。

【０１２８】

【発明の効果】以上説明したように、本発明では、以下
の効果が期待できる。 ・情報保存空間（代表例としてディスク・スペース）の
有効活用、及びこれにあたってのユーザ負担の軽減。例
えば、バージョン機能の適用された情報管理システムに
対して、バージョン単位での情報の削除、他媒体（三次
記憶装置、他ディスクを含む）への退避、及び必要な時
点での退避解除を含む操作を導入することにより、効率
の良い空間使用を可能とする。 ・階層型記憶装置における保存方式のバージョン適用対
象に対する拡張。

【図面の簡単な説明】

【図１】本発明の一実施例を示す図である。

【図２】削除前のオブジェクト状態を示す図である。

【図３】削除後のオブジェクト状態を示す図である。

【図４】媒体移動前のオブジェクト状態を示す図であ
る。

【図５】媒体移動後のオブジェクト状態を示す図であ
る。

【図６】バージョン関係情報の説明図である。

【符号の説明】

１０ 情報管理システム １１〜１５ システム外部の機能 ２０ 条件判断機能 ２１ 処理方式決定機能 ２２ 保存情報処理機能 ２３ 状態取得機能 ３０ 条件保存部 ３１ 処理保存部 ３２〜３４ 情報保存部

Claims (6)

【特許請求の範囲】
1. 【請求項１】バージョン管理情報を含む情報に基づい
   て、あるデータ群の中から一つ又は複数の動作対象デー
   タを決定する第一の機能実現手段と、 動作対象データに対して予め登録された処理を行う第二
   の機能実現手段と、 処理済み動作対象データを媒体移動し、あるいは削除す
   る第三の機能実現手段とを具備することを特徴とする情
   報管理システム。
2. 【請求項２】バージョン管理情報を含む情報に基づい
   て、あるデータ群の中から一つ又は複数の動作対象デー
   タを決定する第一の機能実現手段と、 バージョン管理情報を含む情報に基づき、及び必要に応
   じて動作対象データに基づいて、ある処理群の中から特
   定の処理を決定する第二の機能実現手段と、 動作対象データに対してこの特定の処理を行う第三の機
   能実現手段と、 処理済み動作対象データを媒体移動し、あるいは削除す
   る第四の機能実現手段とを具備することを特徴とする情
   報管理システム。
3. 【請求項３】指定を受けた一つ又は複数の動作対象デー
   タに対して予め登録された処理を行う第一の機能実現手
   段と、 処理済み動作対象データを媒体移動し、あるいは削除す
   る第二の機能実現手段とを具備することを特徴とする情
   報管理システム。
4. 【請求項４】バージョン管理情報を含む情報に基づき、
   及び必要に応じて指定を受けた動作対象データに基づい
   て、ある処理群の中から特定の処理を決定する第一の機
   能実現手段と、 指定を受けた動作対象データに対してこの特定の処理を
   行う第二の機能実現手段と、 処理済み動作対象データを媒体移動し、あるいは削除す
   る第三の機能実現手段とを具備することを特徴とする情
   報管理システム。
5. 【請求項５】あるデータ群の中から、媒体移動され、あ
   るいは削除されたデータを見つけ、そのデータを復元
   し、あるいは再構成する機能実現手段を具備することを
   特徴とする情報管理システム。
6. 【請求項６】媒体移動され、あるいは削除された前記動
   作対象データを復元し、あるいは再構成する機能実現手
   段を具備する請求項１〜４いずれか１項に記載の情報管
   理システム。