JPH07152633A

JPH07152633A - 版数管理方式

Info

Publication number: JPH07152633A
Application number: JP5296322A
Authority: JP
Inventors: Naomi Yoshizawa; 直美吉沢; Hiroshi Ishikawa; 博石川
Original assignee: Fujitsu Ltd
Current assignee: Fujitsu Ltd
Priority date: 1993-11-26
Filing date: 1993-11-26
Publication date: 1995-06-16
Anticipated expiration: 2014-03-03
Also published as: US5734899A; JP2863805B2

Abstract

(57)【要約】【目的】１つの既存のデータの一部を修正して作成さ
れるデータに対してバージョン管理を適用するための版
数（バージョン）管理方式に関し、バージョン機能未適
用のシステムにおいて後天的にバージョン機能を適用可
能とする。【構成】バージョン管理適用対象データに共通の管理
情報を保存するオブジェクト１と、オブジェクト１によ
って管理され、複数の対象データのそれぞれに対応し、
対象データの全てのバージョンに共通の管理情報を保存
する複数のオブジェクト２と、オブジェクト２によって
それぞれ管理され、各対象データの複数の各バージョン
に対応し、各バージョンに固有の管理情報を保存するオ
ブジェクト３とを備えるように構成する。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、例えばデータベースシ
ステムのようなデータやプログラムを保存、管理するデ
ータ管理方式に係り、更に詳しくは例えば１つの既存の
データを一部修正して作成されるバージョンのデータに
対してバージョン管理を適用するためのバージョン（版
数）管理方式に関する。

【０００２】

【従来の技術と発明が解決しようとする課題】データや
プログラムに対するバージョン概念は既に多数のシステ
ムにおいて導入され、実用的に広範に用いられている。
しかしながら、これらのシステムで実現された機能は、
例えばデータに対してバージョン情報を付加し、データ
とバージョン情報とを一体化させて、そのバージョン情
報をデータと合わせて管理するものであった。

【０００３】従ってバージョン機能が提供されていない
システムにおいて、バージョン機能を新たに適用するこ
とは困難であった。またバージョン機能を実現するに当
たっては、システムの構成に依存する部分が多く、ユー
ザによるカスタマイズを行うことも困難であると言う問
題点があった。

【０００４】更に従来のシステムでは、バージョンに関
する２つの概念が全く別々に考慮されていた。この２つ
の概念の１つは一般的に経時的に順次作成された複数の
バージョンのうちのいずれを使用するかと言う概念であ
り、もう１つは時間的経過とは無関係に、複数の候補と
してのバージョンの中から特定の１つを選択するという
概念である。

【０００５】本発明は、このバージョンに関する２つの
概念を統合し、これらの概念の差を意識することなく同
一操作によってデータに対するバージョン管理を可能と
することと、バージョン機能が適用されていなかったシ
ステムにおいて後天的にバージョン機能を適用可能にす
ることを目的とする。

【０００６】

【課題を解決するための手段】図１は本発明の原理構成
ブロック図である。同図はオブジェクト指向データの保
存、および操作を可能とするオブジェクト指向データベ
ースシステムにおける版数管理方式の原理構成ブロック
図である。

【０００７】図１において、全体共通情報保存オブジェ
クト１は、例えばバージョンコントロールクラスのオブ
ジェクトであり、バージョン（版数）管理が適用される
全てのオブジェクト指向データに共通のバージョン管理
情報を保存、管理するものである。

【０００８】バージョン共通情報保存オブジェクト２は
全体共通情報保存オブジェクト１によって管理されるオ
ブジェクトであり、バージョン管理が適用される複数の
オブジェクト指向データのそれぞれに対応して、そのデ
ータの全てのバージョンに共通のバージョン管理情報を
保存、管理するものであり、例えばヒストリカルクラス
のオブジェクトである。

【０００９】バージョン固有情報保存オブジェクト３は
バージョン共通情報保存オブジェクト２によって管理さ
れるものであり、各オブジェクト指向データの複数のバ
ージョンのそれぞれに対応して、各バージョンにそれぞ
れ固有のバージョン管理情報を保存、管理するものであ
り、例えばバージョンクラスのオブジェクトである。

【００１０】

【作用】本発明においては、バージョン管理が適用され
るオブジェクト指向データＡの複数のバージョンに対し
て、例えばＡ〔１〕，Ａ〔２〕，Ａ〔３〕，・・・のよ
うに、例えば生成順に記号が付けられる。

【００１１】このオブジェクトＡの個々のバージョンＡ
〔ｎ〕に固有のバージョン情報がバージョン固有情報保
存オブジェクト３、例えばバージョンクラスのオブジェ
クトＶ〔Ａｎ〕に保持される。この固有のバージョン管
理情報としては、そのバージョンの親オブジェクトがど
のバージョンか、子オブジェクトがどのバージョンかな
どの情報が含まれる。

【００１２】オブジェクトＡの全てのバージョンＡ
〔１〕，Ａ〔２〕，Ａ〔３〕，・・・に共通のバージョ
ン管理情報はバージョン共通情報保存オブジェクト２、
例えばヒストリカルクラスのオブジェクトＨ〔Ａ〕に保
持れる。ここに保持される情報としては、例えばオブジ
ェクトＡの所有者、オブジェクトＡの最初のバージョン
の生成時刻などがある。

【００１３】複数のオブジェクト指向データＡ，Ｂ，
Ｃ，・・・のそれぞれに対してバージョン共通情報保存
オブジェクト２、例えばＨ〔Ａ〕，Ｈ〔Ｂ〕，Ｈ
〔Ｃ〕，・・・が用意され、これらのオブジェクトによ
ってそれぞれのオブジェクトの複数のバージョンに対す
るバージョン固有情報保存オブジェクト３が管理され
る。

【００１４】ヒストリカルクラスのオブジェクトＨ
〔Ａ〕，Ｈ〔Ｂ〕，Ｈ〔Ｃ〕，・・・を管理するオブジ
ェクトが全体共通情報保存オブジェクト１であり、これ
は例えばバージョンコントロールクラスのオブジェクト
Ｖｃである。このオブジェクトにはバージョン管理が適
用される全てのオブジェクト指向データＡ，Ｂ，Ｃ，・
・・に共通のバージョン管理情報が保存され、全てのオ
ブジェクト指向データの管理が行われる。

【００１５】このように本発明においては、バージョン
管理情報が管理の対象となるデータとは独立に保存さ
れ、更にそのバージョン管理情報が３段階のオブジェク
トに分割されて管理されることによって、各種の対応が
容易となる。

【００１６】

【実施例】図２は本発明の版数管理方式を用いるオブジ
ェクト指向データベースシステム（ＯＯＤＢ）の全体構
成ブロック図である。同図においてシステムはデータベ
ース１０とデータの加工等を行うＣＰＵ１１とから構成
されている。

【００１７】データベース１０内には、本発明の特徴を
成すバージョン管理情報、バージョン管理が適用れるデ
ータ、およびバージョン管理が適用されないデータ等が
オブジェクトとして格納されているオブジェクトデータ
格納部１２、ユーザまたはＣＰＵ１１の指示に応じてオ
ブジェクトデータ格納部１２内のデータにアクセスし、
データをサーチするアクセス・サーチ部１３が備えられ
ている。ここでアクセス・サーチ部１３はＣＰＵ１１の
機能の一部を取り出したものとも考えられる。

【００１８】本発明では、version 管理機能が必要とす
る情報を、version 機能の適用対象となるobject gro
up中の全objectに関係する情報、version 機能の適用
単位となるデータに固有の情報、および各version 機
能適用単位となるデータの特定の１version にのみ関係
する情報の３種類に分割し、これを保存するobjectを、
version 機能の提供を希望するシステムにおいて新たに
定義し、又、ここで保存された情報を操作する機能を用
意することにより、version 管理機能を後天的に実現
し、更に、version 操作に関係する各種ユーザ定義の追
加手続きの簡易化を可能とする。この追加手続きの簡易
化等についてはさらに後述する。

【００１９】また、これらのobject、及びversion 機能
適用対象となったデータを図３の様に構成することによ
り、特に、各version 機能適用単位となるobjectの特定
の１version にのみ関係する情報を保存するobjectをla
ttice に構成することにより、version 概念の内包する
２つの機能、即ち、複数候補の選択と新旧版の選択と、
例えばＶ〔Ａｎ〕を単一のversion 管理機構により実現
可能となる。

【００２０】version 機能適用以前のシステムにおいて
は、同一名称のobjectが複数存在することは不可能であ
る。従って、あるobjectＡをversion 機能の適用対象と
した場合、このobjectはシステム内では適当な形に変換
され（単なるrenameのみの場合、圧縮され、別の形式に
変換される場合など各種）、Ａ〔１〕，Ａ〔２〕，Ａ
〔３〕，・・・の様にそれぞれ異なる名前を持つことに
なる。

【００２１】この各objectＡ〔ｎ〕に関するversion 情
報を、本発明ではＡ〔ｎ〕自体にではなく、「各versio
n 機能適用単位となるobjectの特定の１version にのみ
関係する情報を保存するためのobject」、Ｖ〔Ａｎ〕に
保持させる。Ｖ〔Ａｎ〕に保持される情報としては、例
えば、Ａ〔ｎ〕の親object（Ａ〔ｎ〕がＡの既存versio
n の修正により作成された場合、その修正された側のob
ject）の一覧、子object（Ａ〔ｎ〕に変更を与えること
によりobjectＡの別のversion が生成された場合、その
新たに生成された方のobject）の一覧などが考えられ
る。Ｖ〔Ａｎ〕にはＡ〔ｎ〕を特定可能な情報が含まれ
ているものとする。

【００２２】更に、「version 機能の適用単位となるデ
ータに固有の情報を保存するためのobject」、Ｈ〔Ａ〕
を用意し、objectＡの全version 、即ちＡ〔１〕，Ａ
〔２〕，・・・に共有の情報をここに保存する。ここに
保持される情報としては、例えばobjectＡの所有者、ob
jectＡの生成時刻が考えられる。先に使用されたobjec
t、すなわち旧バージョンに対する情報Ｖ〔Ａ１〕，Ｖ
〔Ａ２〕，Ｖ〔Ａ３〕，・・・に関してもこのＨ〔Ａ〕
中で管理される。

【００２３】以上のようにして、あるobject group（例
えばシステム）中におけるversion機能適用対象となっ
たobjectの個数だけＨ〔ｏ〕が生成される。これらの一
連のobject、Ｈ〔ｏ〕は「version 機能の適用対象とな
るobject group中の全objectに関係する情報を保存する
ためのobject」、objectＶｃを用意して、ここで管理さ
れる。

【００２４】以上の管理関係は図３に示されている。図
３において、例えばオブジェクトＡ３はオブジェクトＡ
１を一部修正し、またＡ４はＡ３を一部修正して経時的
に作成されたもので、新旧バージョンを表わす。これに
対して例えばＡ５，Ａ７はＡ１とは独立して作成された
もので、新旧バージョンというよりもデータとしての選
択肢、または候補節を表わすものである。このように本
発明ではバージョンに関する前述の異なる２つの概念が
統一的に１つのバージョン管理機構によって取り扱われ
る。

【００２５】このように、version 関係情報をデータと
は独立に保存し、更に３段階に分割管理することによ
り、各種の対応が可能になる。次に、version 管理機能
を実際のオブジェクト指向データベース（object-Orien
ted DtatBase, 以後ＯＯＤＢ）上でimplement した場合
のobject構成と、これにより変更されるデータobject操
作手順に関して説明する。

【００２６】まず、各objectに対して以下の様にclass
名を与える。Version Control は前述のversion 機能
の適用対象となるobject group中の全objectに関係する
情報を保存するためのobjectのクラス名、Historicalは
version 機能の適用単位となるデータに固有の情報を
保存するためのobjectのクラス名、Version は各versio
n 機能適用単位となるデータの特定の１version にのみ
関係する情報を保存するためのobjectのクラス名であ
る。

【００２７】version 管理機能とは、複数の実現手段の
同一仕様のデータを保存・管理し、必要に応じて、参照
・再利用を行うことを可能とする機能である。基本的に
は、data（object指向におけるobject）の保存機能とve
rsion の変更機能より構成される。また、動作version
を検索・特定するためのデータ検索機能が併せて提供さ
れていることが多い。その構造に関しては、各種考えら
れるが、一例を図４に示す（なお、この図においてobje
ct情報の保存機能１８とversion 関係情報の保存機能１
９がそれぞれ分離表示されていることは、当発明の特徴
の１つとなっている。通常はこれらの情報は一体化して
いる）。

【００２８】version 管理機能は例えば以下の３つの機
能より構成される。第１の機能は、データの保存形式へ
の変換機能であり、これは同一仕様の複数のデータを保
存するために、データに対して何らかの変換操作を加
え、表面的には同一仕様と認識されるものを、システム
内部的にはそれぞれ別のものと認識させるための変換操
作である。

【００２９】第２の機能はデータの保存形式から通常形
式への復元機能であり、これは上記変換の結果得られる
保存形式情報の通常形式への復元操作である。第１と第
２の機能は図４のブロック１５によって実現される。

【００３０】第３の機能はobject情報・version 関係情
報保存機能である。これは上記の変換操作の結果得られ
る保存形式のobject情報をそのversion 関係情報と共に
保存する機能であり、ブロック１６によって実現され
る。なお、この３つの機能に加えて、図４には第１、第
２の機能による変換・復元の対象を特定するデータの特
定機能１７が示されている。

【００３１】バージョン機能適用単位となるデータに関
しては、後述するように特定のdatatype を対象としな
い、という点が本発明の特徴の１つであるため、具体例
は存在しない。システムにより、また、ユーザ定義によ
りdataとして、schema, class, instance, slot, metho
d, file 等、あらゆるものがdataとして認識されること
が可能である。

【００３２】前述の保存された情報を操作する機能と
は、version 関係情報( ここでは３階層に分割・管理さ
れている）の書き込み、検索・読み出し機能、objectと
version 機能適用時のobject保存形式との間の変換・復
元機能１５のことである。

【００３３】version 管理機能が必要とする情報は３階
層に分割され、これを保存する機能が提供されている。
当然のことながら、保存された情報を利用する部分が必
要になる。これをここでは操作機能と呼んでいる。

【００３４】また各種ユーザ定義の追加手続きに関して
は、その具体的方法はシステム依存であり、ここで特定
することは不可能である。が、この機能は、version 関
係情報を適用対象objectとは独立に、また、その影響範
囲を考慮して階層分割して（ここでは３階層）おり、更
に、この方式をobject指向データの保存・管理を可能と
するＤＢに適用することにより可能とされる。

【００３５】例えば、version 関係情報としてそのvers
ion の生成原因をユーザが追加したいと希望する場合、
この情報は、objectの特定version にのみ関係する情報
であるから、それ以外の部分（即ち、object groupに関
係する情報の保存部分、適用対象objectに固有の情報の
保存部分）には一切影響を与えずに、特定version に関
係する情報の保存部分のみを（例えばobjectの継承機能
を用いることにより）変更すれば良い。即ち、version
の生成原因を保持する部分を特定version に関係する情
報の保存機能にのみ追加することがそのまま、この機能
を有効にすることになる。

【００３６】ここでobjectと呼ばれているのは、バージ
ョン情報の集合、あるいは、このバージョン情報を保存
する機能を持つcellであり、それぞれは保持されている
情報の内容という点に違いが見られる。

【００３７】従って、各種のobjectの具体例としては、
保持されている情報を提示することが適当と考えられ
る。この保持されている情報を前述の３段階に対応させ
て説明する。まずのクラスであるバージョンコントロ
ールを構成するスロット（データ項目）を以下に示す。
なおここではスロットのみを示し、メソッド機能の記述
を省略した。これは各オブジェクトの機能としてスロッ
トへのデータ保存が主であり、これらのデータのゲット
／セット機能以外のメソッドを持たないためである。〔slot名〕Version Flag 〔許容値〕ＯＮ，ＯＦＦ〔意味〕システム全体に対してversion 機能が適用さ
れているか否かを判断するためのflag。ＯＮ（version
機能適用時）、ＯＦＦ（version 機能適用中断時）の何
れかの値を取る。〔注意点〕対象システムがversion 機能の非適用状態
にある場合には、このobject（instance）そのものが存
在しないので、この状態flagがそれを表現する必要はな
い。〔slot名〕Version Object List 〔許容値〕ＮＵＬＬ，hashlistへのpointer 〔意味〕その時点でversion 機能の適用対象となって
いるobjectの一覧が保存される。〔注意点〕当モデルでは、version 機能をシステムに組
み込むのではなく、後天的にその機能を提供することに
より実現している。従って、version 関係情報もやはり
object中に保存される。また、当モデルではversion 機
能の適用状態にあるobjectと非適用状態にあるobjectと
の混在を可能とする。このため、object単位でversion
機能の適用対象objectと非適用対象objectとの区別を可
能にするための機能が必要である。このlistはこれを可
能とする。なお、許容値としてのハッシュリストへのポ
インタは、多数のバージョンオブジェクトの高速検索に
用いられるハッシュリストへのポインタである。〔slot名〕Deleted Object List 〔許容値〕ＮＵＬＬ，hashlistへのpointer 〔意味〕その時点で削除指示が出されているobjectの
一覧が保存される。ユーザによる削除指示が出された
後、何らかの理由により対象objectの物理的削除が望ま
しくない場合には、対象objectをVersion Object List
よりこのDeleted Object List に移動して、ここに保存
する。

【００３８】次に、のクラスであるヒストリカルを構
成するスロットを以下に示す。〔slot名〕Objectd Name 〔許容値〕version 機能適用対象object 〔意味〕このobjectが管理しているversion 情報の元
となったdata object を特定するための情報を保存す
る。〔slot名〕Version Flag 〔許容値〕ＯＮ，ＯＦＦ〔意味〕管理対象となっているobjectがその時点でve
rsion 機能適用対象とされているか否かを判断するため
のflag。ＯＮ（version 機能適用時）、ＯＦＦ（versio
n 機能適用中断時）の何れかの値を取る。提供されるve
rsion 機能は、このobjectに対してはflagがＯＮ状態に
ある場合に限り適用される。ＯＦＦ状態になっている場
合の更新操作は全て修正（versionupを伴わない）と認
識される。〔注意点〕このflagは、version 機能適用対象であった
objectを一時的に適用対象外にする場合などに使用され
る。従って、ある時点で、version 機能の適用対象外と
なるobjectには、Historical object により管理され、
かつこのflagがＯＦＦになっているものと、data objec
t のみが存在しHistorical object に対応付けられてい
ないものの２通りが存在する。逆に、ある時点でversio
n 機能の適用対象となるobjectは、Historical object
により管理され、かつ、このflagがＯＮとなっているも
ののみである。〔slot名〕Version Control Object 〔許容値〕Version Control objectへのpointer 〔意味〕このHistorical object を管理しているVers
ion Control instanceへのlinkを保持する。〔slot名〕Version Child List 〔許容値〕ＮＵＬＬ，object List へのpointer 〔意味〕対象objectの導出関係（version における親
子関係）を保持するためのlist。なお、各version の親
子関係については対象objectの各version に分散させて
保持するものとし、ここでは、親を持たないversion に
ついてのみ、それへのlinkを保持する。〔slot名〕Version Top 〔許容値〕Version instanceへのpointer 〔意味〕生成時順で先頭にある（即ちversion no. ＝
１）objectを管理しているclass Version のinstanceを
保持する。〔slot名〕Last Version 許容値〕Version instanceへのpointer 〔意味〕管理対象となっているdata object の、その
時点での最新のversionを管理しているVersion instanc
eを保持する。〔slot名〕Default Version 〔許容値〕Version instanceへのpointer 〔意味〕管理対象となっているobjectの、特にversio
n を指定されずobject名のみが指定された場合に、対象
となるversion を管理しているVersion instanceを保持
する。〔slot名〕Active Version 〔許容値〕Version instanceへのpointer 〔意味〕管理対象となっているobjectの、その時点で
動作対象となっているversion のobjectを管理している
Version instanceを保持する。〔slot名〕Owner 〔許容値〕version 機能適用対象システムが許容してい
るユーザのＩＤ〔意味〕管理対象objectのowner のＩＤを保持する。
objectのowner は本来ＤＢシステムが定義しているもの
であるが、version 機能が適用された場合に特有のアク
セス制御法則が存在するのであれば、ここで保存された
情報を用いて行う。〔注意点〕状況に応じて、このslotにはowner 名をStri
ngとして与えてもよい。〔slot名〕 Group 〔許容値〕version 機能適用対象システムが許容してい
るグループのＩＤ〔意味〕管理対象objectの groupのＩＤを保持する。
objectの groupは本来ＤＢシステムが定義しているもの
であるが、version 機能が適用された場合に特有のアク
セス制御法則が存在するのであれば、ここで保存された
情報を用いて行う。このグループに関してはさらに後述
する。

【００３９】さらに、のクラスであるバージョンを構
成するスロットは以下の通りである。〔slot名〕Version No 〔許容値〕１以上の整数〔意味〕このobjectが管理しているdata object のve
rsion no. （生成時順）を保存する。〔slot名〕Data Object 〔許容値〕Objectへのpointer 〔意味〕このobjectが管理しているdata object （差
分管理機能を適用している場合にはその差分管理デー
タ）を保持する。この差分管理についてはさらに後述す
る。〔slot名〕Version Parent List 〔許容値〕Historicalへのpointer 、object List への
pointer 〔意味〕後述のVersion Child Listと共に、対象のob
jectの導出関係( version における親子関係）を保持す
るためのlist。ここでは導出関係のうち、対象version
がどのversion の更新により作成されたものであるかを
記憶する。なお、親が存在しない場合（対象version が
全く独自に生成された場合）にはこのlistは、このVers
ion instanceを管理しているHistorical instance を要
素とする。当モデルでは、version の導出関係を表現す
るversion graphをlattice 構造と定義している。即
ち、あるobjectに着目した場合、そのobjectの親objec
t、子objectは共に複数個の存在が許容される。従っ
て、ここで保存されるのもobjectのlistである。〔slot名〕Version Child List 〔許容値〕ＮＵＬＬ，object list へのpointer 〔意味〕前述のVersion Parent List と共に、対象ob
jectの導出関係( version における親子関係）を保持す
るためのlist。ここでは導出関係のうち、対象version
の更新によりどのversion が作成されたかを記憶する。
更に、必要であれば、このobjectよりの進化の許可、禁
止の別をここに保存することも可能である。当モデルで
は、version の導出関係を表現するversion graph をla
ttice 構造と定義している。即ち、あるobjectに着目し
た場合、そのobjectの親object、子object、は共に複数
個の存在が許容される。〔slot名〕Pre Version 〔許容値〕Version instanceへのpointer 、Historical
instance へのpointer 〔意味〕対象objectの時間的に１つ前に作成されたob
jectを管理するVersioninstanceを保持する。対象objec
tがversion no. ＝１である場合には、このVersion ins
tanceを管理するclass Historicalのinstanceが入れら
れる。〔slot名〕Next Version〔許容値〕Version instanceへ
のpointer,ＮＵＬＬ〔意味〕対象objectの時間的に１つ後に作成されたob
jectを管理するVersioninstanceを保持する。対象objec
tが最新のものである場合には、ＮＵＬＬが入れられ
る。〔slot名〕Last Version Flag 〔許容値〕ＴＲＵＥ，ＦＡＬＬＳ〔意味〕管理対象となっているobjectがその時点で最
新のversion のものであるか否かを示す。ＴＲＵＥ（対
象version が該当objectの最新version である場合）、
ＦＡＬＬＳ（対象objectは該当objectの最新version で
はない時）の何れかの値を取る。〔slot名〕Default Version Flag 〔許容値〕ＴＲＵＥ，ＦＡＬＬＳ〔意味〕管理対象となっているobjectがdefault vers
ion であるか否かを示す。ＴＲＵＥ（対象version が該
当objectのdefault version である場合）、ＦＡＬＬＳ
（対象objectは該当objectのdefault version ではない
時）の何れかの値を取る。〔注意点〕これと等価の情報がhistorical object 中に
用意されているので、必須情報ではない。〔slot名〕Active Version Flag 〔許容値〕ＴＲＵＥ，ＦＡＬＬＳ〔意味〕このversion objectの管理対象となるversio
n がactive version（その時点での動作対象version ）
であるか否かを判断する。ＴＲＵＥ（対象version が該
当objectのactive versionである場合）、ＦＡＬＬＳ
（対象objectは該当objectのactive versionではない
時）何れかの値を取る。〔slot名〕Owner 〔許容値〕version 機能適用対象システムが許容してい
るユーザのＩＤ〔意味〕objectの特定version のowner のＩＤを保持
する。管理対象となったversion の更新者、access許可
範囲、等の限定に使用される。objectのowner は本来Ｄ
Ｂシステムが定義・管理しているものであるが、versio
n 機能が適用された場合に特有のアクセス制御法則が存
在するのであれば、ここで保存された情報を用いて行
う。〔slot名〕Group 〔許容値〕version 機能適用対象システムが許容してい
るグループのＩＤ〔意味〕管理対象objectの groupＩＤを保持する。管
理対象となったversion の更新者、access許可範囲、等
の限定に使用される。objectの groupは本来ＤＢシステ
ムが定義・管理しているものであるが、version 機能が
適用された場合に特有のアクセス制御法則が存在するの
であれば、ここで保存された情報を用いて行う。〔slot名〕Create Time 〔許容値〕type time を満たす時刻情報〔意味〕該当objectの生成・変更時刻を保持する。〔slot名〕Comment 〔許容値〕任意の文字列〔意味〕該当objectの生成・変更理由、各種コメント
を保存する。生成時刻、更新制約など、各種の情報の保
存を必要とする場合には、このslotの定義を以下のよう
にしてもよい。 instance：struct comment * Comment； struct｛ String Cstring ； time Ctime ；：｝ comment 以上、〜の３段階の各クラスを構成するスロットの
内容について詳しく説明したが、ここではシステム中の
version 機能適用対象となる全objectを１つのobject g
roupとして扱っており、class Version Control はこ
れに関係する情報を保存するためのobject type を定義
したものである。class Historicalはversion 管理機
能の適用対象となるobjectそれぞれに関係する情報の保
存を行うためのobjectである。class Version は各適用
対象objectのそれぞれのversionに固有の情報の保存を
行うためのobjectである。

【００４０】例えば、システム中に保存するclass Ａに
対してversion 機能の適用がなされた場合、システム中
にclass Ａというversion 機能適用class が存在すると
いう情報は、システム全体に関係することであるから、
Version Control(object）instance中に記憶される。cl
ass Ａにversion 機能が適用されているという情報は、
class Ａに固有の情報でるから、これはHistorical obj
ect 中に保存される。また、このclass の各version の
情報（version.3 がいつ誰の手によりどのversion に変
更を与えることにより生成されたか、等）は、そのvers
ion に固有の情報であるので、Version objectに保存さ
れる。

【００４１】前述のクラスヒストリカルの最後（クラ
スバージョン内も同様）にある“グループ”はＵＮＩ
Ｘにおけるファイルへのアクセス制御のために使用され
る概念である。即ち、あるfileのread,write,executeを
owner 単位で許可する機能に加えて、 groupとして指定
されたグループに属するusers に対する許可を示すこと
を可能とする。

【００４２】例えば、ＵＮＩＸ上ではfile version.def
ine に関する情報が以下の様なformatで示される。 -rwxr-x--x yosizawa mmdb 2533 Mar８ 09：45 versio
n.define これは、このfileのowner がyosizawaであり、 groupと
してmmdbが指定されていることを示す。access制御項目
として -rwxr-x--x が指定されているため、このfile
は、owner であるuser yosizawa はread(r) 、write
(w)、実行(x) 可能、グループmmdbに属しているuserはr
ead(r) 、実行(x) 可能、それ以外のuserは実行(x) の
み可能、ということになる。

【００４３】前述のclass 定義は、完全にシステム依存
であり、我々が今回当version 管理機能を実現したシス
テム（computer−ＯＳはＵＮＩＸ−program はＣ，及び
Ｃ＋＋）の為のものである。 groupに関しても、今回ve
rsion 機能を実現しているシステムがグループの概念を
持っており、この概念をversion 管理機能に拡張するた
めに、即ち、version 機能適用対象単位であるobjectに
適用されていた groupの概念と同等のものを各version
単位に適用可能とするために、指定されている。

【００４４】従って、異なるシステムでは異なる定義が
なされることになり、当然のことながら適用対象システ
ム中にグループの概念が存在しない場合には、この項も
存在しない。

【００４５】次に、クラスのバージョンの〔データオ
ブジェクト〕のスロットに対する〔意味〕中の差分管理
機能について説明する。version 管理とは、同一仕様の
複数のデータの存在を認め、それらを有効に利用するこ
とである。この機能を後天的に付加した場合、システム
は同一仕様の複数のデータを認める構造になっていない
ため、何らかのデータ変換を行う必要がある。

【００４６】例えば、objectＡをＡ.1，Ａ.2，Ａ.3，・
・・の様に保存し、必要に応じて動作対象となるものを
renameしてＡとする方法もる。また、全てのversion を
情報保存用objectＶｓに保存し、この中で管理する方法
もある。

【００４７】掲示された例では、この保存方式として、
差分管理も採用可能としている。差分管理機能とは、複
数のobjectの保存を必要とする場合にあるobjectを基準
とし、別のobjectに関する情報を基準objectとの差のみ
を保持することで保存する方法である。例えば、Ａ.1が
更新されＡ.2が作成された場合、この更新原因があるsl
otの追加であったような場合、Ａ.1に加えて、Ａ.2は
Ａ.1にslotを追加したものであるという情報のみを保存
しても、Ａ.1，Ａ.2の双方を保存するのと同様の効果が
得られる。

【００４８】今回version 管理機能のimplement を行っ
たcomputerの記憶容量に限界があるため、多数のobject
の複数のversion をそのまま保持する方式では将来的に
問題が発生すると予想され、そのため、可能な限りデー
タ総量を縮小させる方法を検討した結果、データの保存
形式として差分管理も適用可能とした。

【００４９】続いて本発明におけるバージョン管理機能
の適用過程を説明する。この機能はＯＯＤＢに対して後
天的に付加される機能であるから、先ず、version 機能
の適用を指示する。これによりVersion Control instan
ceが生成され、システム内のobject状態は図５の様にな
る。

【００５０】図５においてobjectＶｃはこの機能の提供
のために新たに用意されたinstanceであり、Ｏ１〜Ｏｎ
はこの時点で既にシステム内に存在していたobjectであ
る。version 機能は提供を開始されたのみで、適用対象
となっているobjectは未だ存在しないことに注意する必
要がある。

【００５１】更に、version 機能の適用対象となるobje
ctが存在して初めてhsitorical instance が生成され
る。class Ａに対してversion が適用された場合を図６
に示す。図６において、version 機能の適用対象となっ
ているのはclass Ａのみであり、これ以外には存在しな
い。またclass Ａに関しては１version のみが存在し、
旧版の保存はこの時点ではなされていない。これはシス
テム内で以下の操作が行われたことを示している。 class Ａのversion 情報を管理するobjectＨ〔Ａ〕
が生成され、Ｖｃはこれを参照可能とする。Ｈ〔Ａ〕に
はＡに関係するversion 情報が保存される。 version 機能が適用されると定義されているclass
Ａは必然的にclass Ａのversion no.1となる。即ち、Ａ
〔１〕に変換される。Ａ〔１〕に関係する情報を保存するためのobjectＶ
〔Ａ１〕が生成されＨ〔Ａ〕はこれを参照可能とする。Ｖ〔Ａ１〕はＡ〔１〕へのpointer を保持する。

【００５２】更に、このobjectＡの複数のversion が揃
った状態を図７、図８に示す。図７はclass Ａのversio
n がno.7まで存在している状態であり、図８はversion
no.8が新たに追加された状態である。また、図７でシス
テム中にはclass Ａの他に、Ｂ，Ｃというobjectが新た
にversion 機能の適用対象となっており、これらのvers
ion 関係情報を管理するobject，Ｈ〔Ｂ〕，Ｈ〔Ｃ〕
が、存在している。Ｈ〔Ｂ〕，Ｈ〔Ｃ〕もＨ〔Ａ〕と同
様、その下にはlattice 構造を取る１つ以上のＶ〔on〕
と、それぞれをversion 情報とするobject、Ｂ〔ｎ〕，
Ｃ〔ｎ〕が存在している。図８によって、あるversion
機能適用対象objectをversion upする場合、そのdata o
bject と、そのdataに関するversion 関係情報を管理す
るobjectＶのinstance、の２つのobjectが１組となっ
て、システム内に追加されていくことがわかる。

【００５３】version が増加する度にobjectＶ〔ｎ〕が
１つづつ増加していくことがわかる。前述の各クラス
〜におけるスロットを用いて、本発明ではversion の
親子関係を、親、子、共に多対多対応で保存可能として
おり、ここでもＡ〔７〕がＡ〔４〕とＡ〔６〕の２つの
version を親としてこれをmerge して生成されたことが
version objectＶ〔Ａ７〕中に記録されている。なお、
図５〜図８においては図３と異なり各バージョンＡ
〔ｎ〕とそれに対応する管理情報保存オブジェクトＶ
〔Ａｎ〕とが近接して示されている。

【００５４】図９は図８と同様にバージョンNo.8まで作
成された状態において、バージョン管理機能のために新
たに作成された部分を強調したものである。なお、図９
は図３に対応するものであり、図８とはその内容が一部
異なっている。

【００５５】以上で、本発明におけるバージョン管理機
能の全体的な基本事項の説明を終わり、続いて、このバ
ージョン管理機能のその他の重要な特徴を順次説明す
る。その第１はバージョン適用対象となるデータに関す
る特徴であり、本発明ではこのデータのタイプに関する
制約を持たないことを特徴とする。すなわち、本発明で
は適用対象となるデータに関する判断を一切行わず、デ
ータタイプに関する制約を持たないversion 管理機構を
提供することにより、１つのシステム中で複数の異なる
タイプのversion 機能適用対象データを許容するもので
ある。

【００５６】これにより、単一システム内における、デ
ータ（objectに代表される）に対して適用されるversio
n 機能とデータ group（schemaに代表される）に対して
適用されるversion 機能、を同一の機構により実現する
ことが可能になる。

【００５７】従って本発明では、version 機能適用対象
objectとして、instance, class, schema の３種類を考
慮し、システム全体を１つのobject groupとて、単一の
Version Control objectで管理する。即ち、このシステ
ムにおいてはversion 機能の適用対象となる全てのobje
ctはこの１つのVersion Control objectにより管理され
ることになる。

【００５８】本発明では、version 機能適用対象となる
データとversion 関係情報を保存するobjectは独立であ
る。従って、version 情報はデータに関係せず、従っ
て、class （type class）とそこに属するinstance（ty
pe instance)群、schema（typeschema)とそれを構成す
るclass(type class）群、に代表される、構成level の
異なる異種データ群に対して同一のversion 管理機構を
適用することが可能になる。

【００５９】また、データの属性がversion 情報に影響
を及ぼす場合でも、version 情報はその影響範囲を考慮
して３段階に分割管理されているため、該当データ（デ
ータ属性に影響を受けたversion 情報）を必要とする範
囲にのみ新たに保持させればよい。この特長もまた、複
数のデータタイプを同一機構で管理することを可能とす
るための必要条件となっている。この特長については、
さらに後述する。

【００６０】「複数レベルのデータタイプ」としては、
前述のように例えば、schema、class 、instance、が挙
げられる。この場合、レベル数は３である。schemaはcl
assを内包し、class はinstanceを内包する。従って、
それぞれは対等ではなく、このような場合をレベルが異
なる、と表現している。

【００６１】schema、class 、instanceの関係を図１０
に示す。スキーマはクラス間の関係を表現したもの、ク
ラスはオブジェクト構造の定義を示したもの、インスタ
ンスは一般的な意味でのデータ保存セルである。

【００６２】schema、class 、instanceの例としては、
それぞれ複数のデータの測定より構成される実験手順、
各測定データformatと測定方式、測定されるデータが挙
げられる。schemaはclass の一覧とそのclass 間の関係
を把握しており、上記の例で言えば、ある測定の後にど
の測定を行うか、ある測定を行うためにはどの測定デー
タの入手を必要とするか、等の情報の認識を行ってい
る。class はdata format の定義を表現したものであ
り、ここでは測定式とデータformatの定義となる。測定
をどのように行うか、どのようなデータを取得すればよ
いか、が示される。instanceはclass のformatに従った
個々のdataである。ここでは、測定データそのものに当
たる。従って、同一条件の測定を複数回行った場合に
は、測定回数分だけinstanceが生成され、それぞれの測
定結果がそれぞれのinstanceに保存される。

【００６３】この例の関係を図１１に示す。スキーマの
中には実験手順が、各フェーズの関係も含めて記述され
ており、クラスは各実験フェーズ、それぞれの手順、測
定すべきデータの一覧、データフォーマットであり、イ
ンスタンスは測定データの保存セルである。

【００６４】次に、前述の「データ属性がバージョン情
報に影響を及ぼす場合」と「複数のデータタイプを同一
機構で管理することを可能とするための必要条件」につ
いてさらに説明する。

【００６５】例えば、開発中のprogram 、開発中のprog
ram で利用するapplication program という２つのtype
のobjectに対してversion 機能を適用する場合を考え
る。ここで上記に挙げられた２種類のprogram のversio
n upの意味を考える。

【００６６】開発中のprogram のversion upの原因はユ
ーザによる更新である。従って、ユーザが保存を希望す
るversion 関係情報としては、更新時刻、更新理由、更
新箇所（前version との差異）等が考えられる。従っ
て、このversion 関係情報を保持するobjectにはこれら
の項を保存する機能が必要になる。

【００６７】それに対して、開発中のprogram で利用す
るapplication program ではユーザは更新箇所などの情
報の保存機能を必要としない。従って、これら２つのob
ject type に固有のversion 関係情報はそれぞれ異なっ
ており、図９に見られるobjectＶ〔Ａｎ〕として異なっ
たformatのものを用意する必要がある。

【００６８】これが「データの属性がバージョン情報に
影響を及ぼす場合」である。但しこの場合にも、その影
響範囲は図９に見られるＶ〔Ａｎ〕のみであり、それ以
外（Ｖｃ，Ｈ）に対する影響は見られない。

【００６９】即ち、例えば、開発中のprogram 、開発中
のprogram で利用するapplicationprogram の他にも、p
rogram の実行結果、実行に関する測定結果等、「複数
のデータタイプ（この例では４種）を同一機構で管理す
ること」を可能としている、と言うことになる。

【００７０】本発明の重要な特徴の第２は前述のバージ
ョンデータ親子関係の保持である。すなわち、本発明に
おいてはデータの変更元情報として複数の既存データを
認識することにより、現実に沿ったデータの（version
graph 上における）親子関係をversion 管理機構に認識
させるものである。

【００７１】これによりmerge 等、複数の既存version
を親（変更元）データとして新たなversion のデータを
作成した場合に、その関係をシステムが管理することに
よって、ユーザの記憶によらず認識することが可能にな
る。

【００７２】第２の特徴は対象version の親子関係情報
を保持する部分を用意することにより実現される。この
情報は各objectの特定version にのみ固有のものである
と考えられるため、前述のようにＶ〔Ａｎ〕中にこのた
めのobjectが用意される。すなわち、バージョン関係情
報の一部である、既存のバージョンと新規バージョンの
関係、すなわち導出関係は、既存バージョン、又は、新
規バージョンのバージョン関係情報として認識される。

【００７３】従って既存version の関係情報保存objec
t、又は新規version の関係情報保存object、のいずれ
か一方、又は双方にこの関係が保存される。（前述のcl
ass Version 中のslot Verstion Parent List 、slot V
ersion Child List 参照。）この場合には、双方に関係
が保存される方式となっている。即ち、Ａのversion.3
がＡのversion １より導出された場合、Ａのversion.3
の関係情報を保存するobject内に「このversion はvers
ion.1 より導出された」と言う情報が保存され、Ａのve
rsion.1 の関係情報を保存するobject内に「このversio
n はversion.3 を導出した」と言う情報が保存される。

【００７４】本発明の重要な特徴の第３はシステム内の
データの一貫性保持のためのものであり、予想されるob
jectの変更内容を関係objectに通知し、この変更による
影響を予め確認することにより、システム内における一
貫性の保持が不可能となるような変更を不許可とする、
あるいは成された変更元に戻すための機能である。

【００７５】この機能は、通常の変更伝播機能に対し
て、変更操作と一貫性の確認操作の順番を交換すること
により、objectに対する変更とobject groupの一貫性の
優先度を逆転させたもの、ということが出来る。

【００７６】この機能の実現のためには、以下の〜
の機能が必要とされる。これらは図１２の各ブロック２
０〜２４によって実現される。なお、図１２はこれらの
各機能間のデータの流れを示す図である。 objectの変更通知機能この通知メカニズムとしてはobject更新時の変更通知メ
カニズムが存在する。但し、ここでは通知タイミングと
して、対象objectの内容の変更の他に、後述する動作対
象version の変更も考慮する。データの整合条件の取得機能整合条件の評価機能整合性の復元制約を保持する機能復元制約の実行機能また、必要に応じて変更取り消し機能、等を追加する必
要がある。

【００７７】あるobjectに対して変更指示が発生した場
合、まずobject名とその変更指示内容が関係objectへ通
知される。通常の変更伝播機能との違いはこの時点で変
更は行われておらず、変更通知機能が通知するのは変更
予定内容であることである。この変更予定内容を通知さ
れたobjectは、その変更が整合性を崩すものであるか否
か、特に自objectとの間に非一貫性が発生したかどうか
を確認する。この確認は、整合条件の取得機能２１を用
いて得られた整合条件を評価することにより行う。

【００７８】この結果、非一貫性が発生していない場合
には、その旨通知元objectへ返信する。非一貫性が発生
しており、ここでの修正を必要とされる場合には、改め
て、整合性の復元制約を読み出し、この制約に基づいて
objectの変更操作を行いその成否を変更元objectに返信
する。

【００７９】変更元objectはその変更予定を通知した全
てのobjectより、非一貫性が発生していない、あるいは
この非一貫性を修復可能であった（その結果、変更操作
が成功する）旨の通知を受け取った場合にのみ、その変
更内容を実現する。

【００８０】通知先のobjectの変更内容が２次的な変更
伝播の原因となることが考えられるが、このような場合
には、通常の変更伝播操作が最初のobject変更関係objectへの変更通知関係objectの変更関係objectに関係しているobjectへの変更通知《関係objectが存在するかぎり、へ》の様な手順
で伝播していくのに対し、第３の特徴としての一貫性保
持方式では関係objectへの変更予定内容通知関係objectでの整合性の確認（整合性保持のために関係objectに対する変更操作
が必要と確認された場合のみ）関係objectに関係してい
るobjectへの変更予定内容通知《手順より手順を再起的に実行》関係objectに関係しているobjectの整合性保持のた
めの変更が全て成功した場合、又は、関係objectに関係
しているobjectでは変更を必要としない場合、関係obje
ctの変更実行（関係objectの変更が成功した場合）通知元objectの
変更実行の様になる。

【００８１】第３の特徴の一貫性保持方式では、object
を更新する場合に、関係するobjectとの整合性・一貫性
が取れるように考慮が成される。但し、ここでは、整合
性が取れない場合でも、整合性が取れるように何とか復
元を試み、それも不可能な場合に限り変更対象objectを
変更禁止とする、という方法を取っている。

【００８２】ここでこの復元の方法が問題となる。基本
的に、ＤＢ内の整合性は取れているものとして考える
と、整合性の破壊はその時対象となった変更が原因であ
る。しかし、この直接的原因をそのまま解消することは
望ましくない。それは即ち、変更を全く行わないことと
同等だからである。

【００８３】そこで別の部分をこの更新に合わせて変更
する必要がある。多数の関係objectのどの部分をどのよ
うに変更するか、その優先順位、変更条件、その他変更
の際の動作を示すものが、ここでいう復元制約である。

【００８４】objectの変更操作の正否の判定に関して
は、図１２中の整合条件の評価機能２２より与えられ
る。object更新指示、又は更新不許可のflagにより行
う。具体的にはシステム依存であるのでここに一般的に
記述することは不可能であるが、当機能の実現program
がＣである場合には、制約条件評価関数の復帰値（retu
rn) により判断する（そのようにprogramming する）。

【００８５】次に前述の第３の特徴としての一貫性保持
方式における手順〜の具体例として、２つだけのク
ラスが関係する単純な場合を考える。あるシステムの設
計に当たり、各class をシステム構成する部品データの
保存機能とする。

【００８６】この中に２つのclass が存在し、１つは、
ある回路データを保存するためのobject Circuit、もう
１つをそれを覆うための箱に関するデータを保存するた
めのobject Boxとする。

【００８７】Circuit、Box class のobject構成を以下
の様に仮定する。 i) class Box 〔slot名〕縦〔許容値〕20cm以下。〔意味〕箱の縦サイズ。他の部品との関係上20cm以下
に押さえること。〔slot名〕横〔許容値〕10cm以下。〔意味〕箱の横サイズ。他の部品との関係上10cm以下
に押さえること。〔slot名〕高さ、〔許容値〕２cm以下。〔意味〕箱の高さサイズ。他の部品との関係上２cm以
下に押さえること。〔slot名〕材質〔許容値〕金属〔意味〕箱の材質。 ii) class Circuit 〔slot名〕縦〔許容値〕Box.縦以下。〔意味〕回路の縦サイズ。〔slot名〕横〔許容値〕Box.横以下。〔意味〕回路の横サイズ。〔slot名〕高さ〔許容値〕Box.高さ以下。〔意味〕回路の高さサイズ。〔slot名〕構成素子。〔許容値〕回路素子を要素とするlist。〔意味〕使用されている回路素子の一覧・・・ここで実際のBox 情報object Box１の変更を考える。 B
ox１はBox の定義の通り構成されている。これに対し、
Box１．横：＝８cmという変更を試みる。システムはこの変更指示を受けobject Box1 の関係
objectの検索を行う。これにより Circuit１が得られ
る。

【００８８】Circuit１へ Box１の変更予定とその内容
を送信する。通知を受けたobject Circuit１は Circuitの通り構
成されている。この時点での Circuit１の状態を以下の
とおりとする。

【００８９】Circuit１．縦：＝18cm Circuit１．横：＝9.5cm Circuit１．高：＝1.5cm ここで整合性の確認を行う。システムは、 Circuitを検
索し、slot Circuit. 横はBox との関係を持っており、
その関係は値の大小関係であること、を認識し、Box1.
横：＝８cmの変更が与えられた場合にこの制約を満たし
続けるか否かを確認する。

【００９０】ここでは制約を満たさないため、（Box.横
＜ Circuit. 横、となる）この旨、返送する。これを受
けたシステムは今回の変更、Box1. 横の値の変更を許可
しない。ここで操作が終了される。《以下は、Box1. 横：＝10cmとしてこの制約を満たした
場合である。》制約を満たす場合には、その旨、元の変
更対象objectに送信する。この例では、変更対象object（Box1) の関係object
(Circuit１) は関係するobjectを持たないのでこの項は
必要とされない。この例では、変更対象object（Box1) は関係object
として Circuit以外を持たないので、それ以外に対する
同様な操作を行うためのこの項を必要としない。関係object( Circuit １）が変更対象objectが受け
た変更（この場合はBox1. 横：＝10cm) により影響を受
け、変更を必要とするのであれば、ここで行う。今回の
例では必要ない。システムは関係objectは変更対象objectに与えられ
た変更を許容していることを認識し（関係objectからの
送信による）、これを受けて、この変更を実行する。

【００９１】本発明の重要な特徴の第４も、第３の特徴
と同様に一貫性の保持機能であるが、この機能は通常の
変更伝播機能に見られるような機能、即ちobjectの変更
時に他のobjectを併せて変化させ、object groupとして
の一貫性を保持させる機能を提供する代わりに、この時
点では直接変更指示の有ったもののみを変化させ、それ
以外のobjectが必要とする変更は、予め定められた特定
のタイミングでまとめて実行するものである。

【００９２】この機能は、システム内のデータの一貫性
保持のためのものであるが、特に、変更による影響がそ
れほど多くなく、またrealtimeでの処理を要求されない
場合に、有効である。すなわち、第４の特徴としての一
貫性保持機能は通常の変更伝播機能に見られる変更操作
時点での一貫性の確認操作を省略し、この代わりに指定
されたタイミングで動作するchecker を用意し、これを
用いて一貫性の保持を行うものである。

【００９３】必要な機能として、checker,checker の動
作指示機能、が挙げられる。objectの変更時には、変更
伝播を伴わず、最初に変更の有ったobjectのみを変更す
る。

【００９４】システムの一貫性保持のための機能、即ち
checker はobjectの変更タイミングとは独立に動作す
る。このタイミングはユーザ、あるいはシステムにより
決定され、このタイミングに従ってchecker 動作指示機
能はchecker に対して指示を下す。この指示に対応して
それまで成された変更がシステム内で伝播され、チェッ
カによる検査が行われる。

【００９５】checker は、図１３に示すように、基本的
にはデータの非一貫性検索機能２６、一貫性の復元制約
を保持する機能２７、復元制約の実行機能２８より構成
される。これは、object groupを検索し、整合性が破壊
されている部分を抽出し、発見された破壊部分に対応す
る復元制約を取得して、これに従って、整合性の復活を
行う機能である。

【００９６】第４の特徴としての一貫性保持機能におい
て、チェッカによって非一貫性が発見された場合には予
め指定された方式によって非一貫性状態の解消が試みら
れる。ここで「予め」とは、version 管理機能の起動以
前にシステムに登録されている、という意味であり、例
えば、ユーザとの対話による決定、無条件更新実行、登
録された優先度により優先度の高いほうの状況を優先
し、他方のversion をdownさせる、が考えられる。

【００９７】例えば、図１４に示されるclass 間関係を
持つclass Ａ、class Ｂがそれぞれ、version.3 、vers
ion.5 でchecker が起動された場合を考える。一貫性条
件としては、呼び出されているmethodと定義されている
methodの仕様の整合、が当然考えられる。

【００９８】図１４で２つのclass Ａ，Ｂが存在し、Ａ
はＢ中で定義されたmethodを呼び出すことにより、提供
機能を実現している。従って、この機能呼び出し（参
照）側と、機能提供（定義）側ではそのinterface をそ
ろえる必要がある。ここでは、このinterface が揃って
いる状態を（これのみに注目して）整合性が有ると言っ
ている。整合性を保つためには、Ａのversion.1,2 が使
用されている場合には、必ずＢのversion.1 を使用する
こと、Ａのversion.3 が使用される場合には、Ｂのvers
ion はversion.2,3,4 であること、Ａのversion.4,5,6
を選択した場合には、Ｂのversion.5 を使用することが
必要条件となる。

【００９９】非一貫性検索機能２６は、この条件を認識
し、この条件を各動作対象class が満たしているか否か
を調査する（以後、図１３参照）。この場合は、整合性
が乱されているのであるから、復元制約実行機能２８に
これを通知する。復元制約の実行は「予め指定された方
式」に基づいて行われる。復元制約実行機能２８が実際
に行う動作は、復元制約保持機能２７に保存されている
「予め指定された方式」に依存する。

【０１００】以下にこの場合の動作を幾つか挙げる。・ユーザとの対話を指示されている場合この場合、システムはユーザに対して、現在使用されて
いるのがclass Ａのversion.3 、class Ｂのversion.5
であること、非整合性が認識されたことを提示し、その
後の動作指示の入力待ちにはいる。その後の動作は、ユ
ーザ入力の内容に依存する。・優先度指定がなされており、Ａの方が高かった場合この場合、class Ｂはclass Ａのversion.3 に合わせら
れる。class Ｂに対してはそのversion を１つづつ下げ
ていき整合性が満たされるバージョンが検索され、結果
としてクラスＢのバージョンは４に変更される。

【０１０１】本発明の重要な特徴の第５は、ある時点に
おいて使用されていたデータとそのバージョンを記録し
ておくことにより、その時点における動作環境を復元す
る機能である。すなわち、特定時点で動作しているobje
ctとそのversion や、objectとそのversion の変更時刻
等の情報を保持する機能を付加し、ここに保存された情
報を用いることにより、任意の（過去の）時点で動作し
ていたversion を再度動作対象とするのみならず、その
時点で使用されていたデータ環境を再現することを可能
とするものである。

【０１０２】version 機能を導入した場合、ある環境を
復元するためにはその時点で使用されているobjectとそ
れらのobject間の関係に加えて、使用されているobject
のその時点で動作対象となっていたversion に関する情
報を必要とする。この機能は、以上の情報を記憶させ、
この状態をその後状態復活指示を出された時点で復元す
るためのものである。この機能は、前述の３段階のobje
ctの他にこの環境情報を保持するためのobjectを必要と
する。環境情報取得機能が起動されると、システムは、
object groupに属するclass 一覧や動作対象となってい
るversion の変更を禁止するよう、このobject groupに
対してlockをかける。その後以下の操作を再帰的に行
う。指定されたobjectのobject名と動作対象となってい
るversion ＩＤ（通常はversion no. で表現れる）を抽
出する。指定されたobjectと関係を持つobjectの一覧を検索
する。得られた各objectに対して環境情報取得機能を適用
する。

【０１０３】以上で抽出された情報を、この機能の実現
のために新たに定義された、環境情報を保持するための
objectに保存する。なお、上記の方法は、単一のobject
とそれに関係するobjectに関する情報のみを取得する方
法であり、あるobject group全体の環境を保持するため
には、上記の手順を group内の各object全てに対して適
用する必要がある。

【０１０４】環境情報取得機能によって実行される環境
保存処理は次の手順に従って行われる。環境保存ＩＤを得る。

【０１０５】このＩＤはシステム内で一意に決定される
番号である。これにより、保存される環境と１対１の関
係付けがなされている。指定objectの取得、その時点で使用されているobje
ctのversion no. を併せて保存する。指定objectのその時点で使用されているversion と
関係付けられているobjectの一覧を取得する。各objectに対して、で得られたＩＤを用いて環境
保存機能を適用する。

【０１０６】また、この環境の復元時にはここで保存さ
れた情報を１objectづつ読み出し、それぞれのobjectに
対して動作対象version の変更操作を行うことより実行
される。

【０１０７】図１５は環境情報の具体例の説明図であ
る。同図には時刻ｔ＝Ｔ₁，Ｔ₂，Ｔ ₃，・・・におい
て動作対象となっていたオブジェクトＡ，Ｂ，Ｃ，Ｄの
バージョンがテーブル形式で記録されており、このテー
ブルはシステム全体のオブジェクトグループに共通の情
報を保存するオブジェクトＶｃからポイントされる形と
なっている。図１６は図１５の環境情報を保存するため
に新たに定義されるオブジェクトＥｎｖ１、Ｅｎｖ２，
Ｅｎｖ３とオブジェクトＶｃとの関係をオブジェクト空
間内で示したものである。ここでは、この動作環境の影
響範囲はオブジェクトＶｃによって管理されるオブジェ
クトグループ内に限定されると考えられる。

【０１０８】本発明の重要な特徴の第６は、バージョン
機能が適用されているデータの１つのバージョンを、バ
ージョン機能が適用されていないデータ形式のままで保
存可能とすることである。この特徴はデータへのアクセ
ス効率を高めるうえで有効である。

【０１０９】version 管理機能は、version 機能適用対
象データに対して、同一名称を持つ複数のデータの存在
を認めるためのものである。従ってそのシステム内部で
は、データに対するrename操作等、何らかの変更が行わ
れていることが一般的である。しかし、この場合には必
要となったversion のデータを要求された時点で元のデ
ータタイプに変換することが要求される（この変換の内
容についてはさらに後述する）。そこで、同一名称のデ
ータの中から最大限１つをそのまま保存することによ
り、このデータが動作対象となった場合の変換動作を省
略するものである。

【０１１０】この機能はデータのversion の変更頻度が
それほど高くない場合には特に有効に作用する。この機
能では、各データobject、Ａ〔１〕，Ａ〔２〕，・・・
を全て同一のタイプとして、同一の操作を行う代わり
に、予め定められた方法により決定された特定の１vers
ion 、例えばデフォルトバージョンのみを優先的にＡと
して保持するものである。

【０１１１】object操作時に各objectを一律に扱う代わ
りに、先頭に条件判断を入れることにより、この機能は
実現される。なお、一番使用頻度の高い最新version の
ものを元のデータobjectそのままの形式で保存する場合
には、前述の図８は図１７に示す様に変更される。

【０１１２】図１７は現在class Ａの動作対象となって
いるversion はno.8であることを示している。class Ａ
はversion ８が最新であり、従って、Ａ〔１〕よりＡ
〔８〕が存在する。またこれとは別にclass Ａは存在
し、この図では、これはＡ〔８〕と等価となっている。

【０１１３】version 機能の主目的である動作対象の変
更は図１８の様に行われる。動作対象version の変更は
以下の手順で行われる。現時点での動作対象objectを削除する。

【０１１４】図１８ではobjectＡ（version ８が選択さ
れている）を一時的に削除する。現時点での動作対象objectを示す情報を削除し、新
規に動作対象とするversion を示す情報を追加する。

【０１１５】Historical object Ｈ〔Ａ〕中に存在する
動作対象objectのversion no. を保持するslot値の変
更、version objectＡ〔ｎ〕中に存在する該当version
がその時点で動作対象となっているか否かを示すflag
（この場合は、Ａ〔８〕，Ａ〔７〕のみを変更対象とす
る）の値の変更を行う。新規に動作対象とするversion を用いて対象object
を生成する。

【０１１６】objectＡの新たなversion （ここではＡ
〔７〕）を用いて新規にobjectＡを作成する（図１８中
ではＡ′）。前述のデータ要求時点での元のデータタイ
プへの変換についてさらに説明する。version 機能の提
供がなされていないシステムにおいて、同一objectの複
数のversion を保持することは不可能である。即ち、シ
ステムは同一物であると認識されるものを複数保存する
ことは不可能であり、逆に言えば、システム内に存在す
るobjectは全て異なるものと認識される。

【０１１７】従って、version 機能を後天的に提供する
場合、即ち外部的に同一物と認識されるものを複数個シ
ステム内に保存させる場合には、何らかのデータ変換を
行い、システム内部的には異なるものとして識別可能で
あるよう考慮することが必要である。

【０１１８】例えば、version 機能の適用により存在を
認められた複数のobjectＡに対し、Ａ.1, Ａ.2, Ａ.3,
・・・等のようにrenameを行う方法や、各Ａの情報を保
持する同一形式のobject、ＶＳ.a1,ＶＳ.a2,の様なobje
ctを生成し、これの中に情報を保存する方法がある。

【０１１９】従って、objectＡのversion.3 が動作対象
となっている状況で、Ａのversion.2 を動作対象とする
場合には、先ずＡのversion.2 の情報を保持しているの
がどれかを認識し（この時点でＡ.2なり、ＶＳ.a2 なり
が抽出される）、この情報をＡの形に戻す必要がある。

【０１２０】これが「必要となったバージョン（Ａのve
rsion.2 ）のデータ（Ａ.2またはＶＳ.a2 に保存されて
いる）を要求された時点で元のデータタイプ（Ａ）に変
換する」と言うことである。

【０１２１】本発明の重要な特徴の第７は、本発明の全
体的基本事項として説明したバージョン関係情報の分割
を３段階とする代わりに分割数を減らして、例えば２段
階とすることも可能なことである。すなわち、version
機能実現のために必要とされるversion 関係情報をその
役割毎に３種に分割し、それぞれを３つのタイプのobje
ctに保存する代わりに、２つ以下のobjectを用意し、こ
れにversion 関係情報を保存するものである。

【０１２２】この機能は、objectの増加がシステム性能
に悪影響を及ぼす場合に、特に有効である。この方式で
は、version 関係情報の分割が不完全なものになる可能
性があるが、version 機能提供のために新たに用意すべ
きobjectの個数を減少させて、ほぼ同様に機能を実現す
るためのものである。

【０１２３】一般に、data（object) groupに関係する
情報としてはversion 機能適用対象objectの一覧が考え
られる。従って、何らかの別の手段によりこの適用対象
objectの一覧が取得可能であれば、このdata（object）
groupに関係する情報を保存するobjectは必要ない。

【０１２４】例えば、object groupが１つしか存在しな
いような場合、図９の様に管理されているversion 関係
情報は図１９の様にその構造を変更して管理することが
可能になる。

【０１２５】図１９はversion 管理機能の変形model で
あり、階層を２段にした場合である。version 機能適用
対象objectに固有のversion 関係情報を保存するobject
Ｈに保持されたlink関係によりversion 機能適用対象ob
jectの一覧が得られる。これを用いて、object groupに
関係する情報の保存を行っていたobjectＶｃの代用とす
る。

【０１２６】本発明の重要な特徴の第８は、第７の特徴
とは逆にバージョン関係情報の分割を３段階より増やす
ことも可能なことである。すなわち、version 機能実現
のために必要とされるversion 関係情報をその役割毎に
４段以上の多階層に分割し、それぞれを異なるタイプの
objectに保存するものである。

【０１２７】全体的基本事項における説明でversion 関
係情報をデータ group、version 機能適用対象データ、
適用対象データの特定version 、の３階層に分割管理し
ていたのに対し、ここでは更に分割階層を増やして、ve
rsion 関係情報を管理することになる。

【０１２８】第８の特徴としてのバージョン関係情報の
４層以上の分割の例として例えば、マルチユーザ対応の
場合を図２０に示す。この図は、version 関係情報の階
層を４階層に分割・管理した場合の一例である。

【０１２９】図２０では、同一object group内のversio
n 関係情報を各ユーザ単位で共通の項を設けて分割・管
理している。図９では、version 関係に関する定義は、
同一object group内では等しいものであった、例えば、
あるユーザにとってのobjectＡのversion.3 は別のユー
ザにとってもversion.3 であった。しかし、特に開発・
試作段階においては、あるユーザにとってのversion の
認識が、他のユーザと共通する必要はない。

【０１３０】図２０では、ユーザ１はＡのそれぞれのve
rsion を全て認識しているが、ユーザ２はユーザ１にと
ってのversion.3 、及び、version.8 のみを認識してい
て、それぞれをＡのversion.1 、version.2 と認識して
いることを意味する。これはユーザ１がobjectＡの開発
を行い、ユーザ２は開発されたobjectの非提供者である
場合に、多く見られる状況である。

【０１３１】当発明は、version 管理機能の提供に当た
り、必要とされるversion 管理情報を階層的に分割・管
理することを特徴としており、基本的にはこの分割階層
を３に限定している。これは３階層、即ち、適用対象ob
ject、その特定version 、適用対象objectの groupの様
な分割が一般的と考えられるためである。

【０１３２】それに対してここでは、version 関係情報
を影響範囲に応じて階層化・分割して保存管理を行う、
という思想はそのままで、階層数を多（３以上）階層に
拡張している。

【０１３３】

【発明の効果】以上詳細に説明したように、本発明によ
ればあるデータに関する複数の候補の中から特定の１つ
を選択し、また必要に応じて別の候補を選択し直すこと
と、現在の時刻以前に使用された古いバージョンのデー
タを再び使用可能にすることとが単一のバージョン管理
機構によって実現可能となる。

【０１３４】また本発明によれば、バージョン関係情報
とバージョン機能適用対象データとを分離してバージョ
ン管理を行うことにより、バージョン管理機能と適用対
象システムとの相互の間の独立性が保持され、バージョ
ン機能未提供のシステムに対して後天的にバージョン管
理機能を実現することが可能となる。また各種のユーザ
定義機能の追加など、ユーザによるカスタマイズや、マ
ルチユーザによる使用など、各種の対応が可能となる。

【０１３５】更にある１つのデータに対して適用される
バージョン機能、データグループ、またはスキーマに対
して適用されるバージョン機能など、複数の異なるレベ
ルのデータに対して適用されるバージョン機能を同一の
バージョン管理機構によって実現することが可能とな
る。

【図面の簡単な説明】

【図１】本発明の原理構成ブロック図である。

【図２】本発明の版数管理方式を用いるオブジェクト指
向データベースシステムの全体構成を示すブロック図で
ある。

【図３】データベース内におけるバージョン関係情報保
存オブジェクトとデータオブジェクトの存在形式を示す
図である。

【図４】バージョン管理機能の構成例を示すブロック図
である。

【図５】バージョン機能適用開始時のシステム内のオブ
ジェクトの状態を示す図である。

【図６】クラスＡに対してバージョン機能が適用された
場合のオブジェクトの状態を示す図である。

【図７】クラスＡの複数のバージョンが生成された時の
オブジェクトの状態を示す図である。

【図８】クラスＡに対して新しいバージョン８が作成さ
れた時のオブジェクトの状態を示す図である。

【図９】オブジェクト空間においてバージョン管理機能
のために新たに作成された部分を示す図である。

【図１０】レベルの異なるオブジェクトとしてのスキー
マ、クラス、およびインスタンスの関係を示す図であ
る。

【図１１】スキーマ、クラスおよびインスタンスの具体
例を示す図である。

【図１２】データの一貫性保持のための各機能の間での
データの流れを示す図である。

【図１３】チェッカの構成例のブロック図である。

【図１４】クラス間の整合性を説明する図である。

【図１５】環境情報の具体例の説明図である。

【図１６】環境情報を保存するために新たに定義される
オブジェクトのオブジェクト空間における位置を示す図
である。

【図１７】オブジェクト空間内で現在クラスＡの動作対
象となっているバージョンを示す図である。

【図１８】動作対象オブジェクトの変更を説明する図で
ある。

【図１９】２階層のバージョン管理情報を持つバージョ
ン管理機能の説明図である。

【図２０】４階層のバージョン管理情報を持つマルチユ
ーザ対応バージョン管理機能の説明図である。

【符号の説明】

１全体共通情報保存オブジェクト２バージョン共通情報保存オブジェクト３バージョン固有情報保存オブジェクト１０データベース１１中央処理装置（ＣＰＵ）１２オブジェクトデータ格納部１３アクセス・サーチ部１５オブジェクトと保存形式との間での変換・復元機
能１６データベース（オブジェクトおよびバージョン情
報の保存機能）１７データの特定機能２０オブジェクトの変更通知機能２１整合条件取得機能２２整合条件の評価機能２３整合条件の復元制約保持機能２４復元制約実行機能２６非一貫性検索機能２７復元制約保持機能２８復元制約実行機能２９一貫性条件の保存機能３０検証機能

Claims

【特許請求の範囲】

【請求項１】オブジェクト指向データの保存および操
作を可能とするオブジェクト指向データベースシステム
において、バージョン（版数）管理が適用される全てのオブジェク
ト指向データに共通のバージョン管理情報を保存、管理
する全体共通情報保存オブジェクト（１）と、該全体共通情報保存オブジェクト（１）によって管理さ
れ、バージョン管理が適用される複数のオブジェクト指
向データのそれぞれに対応し、該データの全てのバージ
ョンに共通のバージョン管理情報を保存、管理する複数
のバージョン共通情報保存オブジェクト（２）と、該複数のバージョン共通情報保存オブジェクト（２）に
よってそれぞれ管理され、前記各オブジェクト指向デー
タの複数のバージョンのそれぞれに対応し、該各バージ
ョンにそれぞれ固有のバージョン管理情報を保存、管理
する複数のバージョン固有情報保存オブジェクト（３）
とを備えたことを特徴とする版数管理方式。
【請求項２】前記オブジェクト指向データベースシス
テムにおいて、前記版数管理方式を実行するためのバー
ジョン管理機能を備え、該バージョン管理機能が、前記全体共通情報保存オブジ
ェクト（１）、バージョン共通情報保存オブジェクト
（２）、およびバージョン固有情報保存オブジェクト
（３）の全てに保存されているバージョン管理情報と、
バージョン管理が適用される全てのオブジェクト指向デ
ータとを格納するオブジェクトおよびバージョン情報の
保存機能（１６）と、前記オブジェクト指向データベースシステムの外部との
間で入出力されるデータの形式と、該オブジェクトおよ
びバージョン情報の保存機能（１６）に保存されるオブ
ジェクト指向データの形式との間での変換・復元を行う
オブジェクトと保存形式との間での変換・復元機能（１
５）と、該オブジェクトと保存形式との間での変換・復元機能
（１５）による変換・復元対象を特定するデータの特定
機能（１７）とを備えたことを特徴とする請求項１記載
の版数管理方式。
【請求項３】前記バージョン管理が適用されるオブジ
ェクト指向データのタイプが一定のデータタイプ、また
は該一定のデータタイプを要素として構成される複合デ
ータタイプ、または一方のデータタイプが他方のデータ
タイプを内包する形式のタイプのいずれかであり、該複
数のタイプのデータに対する版数管理を同一操作により
可能とすることを特徴とする請求項１記載の版数管理方
式。
【請求項４】前記複数のタイプがスキーマ、クラス、
およびインスタンスであることを特徴とする請求項３記
載の版数管理方式。
【請求項５】前記バージョン管理が適用されるオブジ
ェクト指向データの既存のバージョンの１つ以上を用い
て新規バージョンが作成されたことを示すバージョン関
係情報を、前記バージョン共通情報保存オブジェクト
（２）が保持することを特徴とする請求項１記載の版数
管理方式。
【請求項６】前記バージョン管理が適用されるオブジ
ェクト指向データの既存のバージョンの１つ以上を用い
て新規バージョンが作成されたことを示すバージョン関
係情報を、該既存のバージョンの１つ以上にそれぞれ対
応する前記バージョン固有情報保存オブジェクト
（３）、および／または該作成された新規バージョンに
対応するバージョン固有情報保存オブジェクト（３）が
保持することを特徴とする請求項１記載の版数管理方
式。
【請求項７】前記オブジェクト指向データベースシス
テムにおいて、関連するオブジェクトにおける一貫性が
保証される場合に限って、該関連するオブジェクトに影
響を与えるオブジェクトの変更を可能とすることを特徴
とする請求項１記載の版数管理方式。
【請求項８】前記オブジェクト指向データベースシス
テムにおいて、あらかじめ設定されたタイミングで動作
し、互いに関連するオブジェクト間での一貫性を確認す
るチェッカを更に備え、あるオブジェクトの変更が生じた時、該チェッカが該あ
るオブジェクトに関連するオブジェクトにおける一貫性
の確認を実行し、非一貫性が発見された場合にはあらか
じめ指定された方式に基づいて該非一貫性の解消を試み
ることを特徴とする請求項１記載の版数管理方式。
【請求項９】前記チェッカが、前記一貫性の条件を格
納する一貫性条件の保存機能（２９）と、前記非一貫性の解消を試みるためのあらかじめ指定され
た方式を格納する復元制約保持機能（２７）と、前記あらかじめ設定されたタイミングで、該一貫性条件
の保存機能（２９）に格納されている一貫性条件を用い
て一貫性の確認を実行する非一貫性検索機能（２６）
と、該非一貫性検索機能（２６）が非一貫性を発見した時、
前記復元制約保持機能（２７）に保持されている復元制
約を用いて該非一貫性の解消を試みる復元制約実行機能
（２８）と、該復元制約実行機能（２８）による非一貫性解消結果の
入力に応じて一貫性の検証を行う検証機能（３０）とを
備えたことを特徴とする請求項８記載の版数管理方式。
【請求項１０】前記オブジェクト指向データベースシ
ステムにおいて、前記全体共通情報保存オブジェクト
（１）によってポイントされ、指定時刻に使用されてい
るオブジェクト指向データ名の一覧と、該指定時刻にお
いて動作中の該オブジェクト指向データのバージョン番
号とを保存する指定時刻使用データ名およびバージョン
番号保存オブジェクトを更に備え、該指定時刻に使用されたデータと該データのバージョン
とを認識し、該指定時刻の動作状態を復元可能とするこ
とを特徴とする請求項１記載の版数管理方式。
【請求項１１】前記オブジェクト指向データベースシ
ステムにおいて、バージョン管理が適用されるオブジェ
クト指向データの一部のデータのそれぞれに対して、該
データの特定のバージョンをバージョン管理非適用状態
のままシステム内に保持することを特徴とする請求項１
記載の版数管理方式。
【請求項１２】前記オブジェクト指向データベースシ
ステムにおいて、前記全体共通情報保存オブジェクト
（１）、バージョン共通情報保存オブジェクト（２）、
およびバージョン固有情報保存オブジェクト（３）のう
ちの１つ以上のオブジェクトに保存される情報を、残る
２つ以下のオブジェクトに分散して保存、管理させるこ
とを特徴とする請求項１記載の版数管理方式。
【請求項１３】前記全体共通情報保存オブジェクト
（１）に保存されるべき情報を前記バージョン共通情報
保存オブジェクト（２）の全てに保存させ、該全てのバ
ージョン共通情報保存オブジェクト（２）の間にリンク
を張ることによりバージョン管理情報を２階層で管理す
ることを特徴とする請求項１２記載の版数管理方式。
【請求項１４】オブジェクト指向データの保存および
操作を可能とするオブジェクト指向データベースシステ
ムにおいて、バージョン（版数）管理が適用される全てのオブジェク
ト指向データに関するバージョン管理情報を階層的に分
割して保存、管理する複数のオブジェクトを備え、オブ
ジェクト指向データに関する版数管理を実現することを
特徴とする版数管理方式。
【請求項１５】前記複数のオブジェクトとして、バー
ジョン管理が適用される全てのオブジェクト指向データ
に共通のバージョン管理情報を保存、管理する全体共通
情報保存オブジェクトと、該全体共通情報保存オブジェクトによって管理され、前
記オブジェクト指向データベースシステムの複数のユー
ザにそれぞれ対応し、該各ユーザが使用する全てのオブ
ジェクト指向データに共通のバージョン管理情報を保
存、管理する複数のユーザ対応共通情報保存オブジェク
トと、該複数のユーザ対応共通情報保存オブジェクトによって
それぞれ管理され、該ユーザによって使用される複数の
オブジェクト指向データのそれぞれに対応し、該各デー
タの全てのバージョンに共通のバージョン管理情報を保
存、管理する複数のバージョン共通情報保存オブジェク
トと、該複数のバージョン共通情報保存オブジェクトによって
それぞれ管理され、前記各オブジェクト指向データの複
数のバージョンのそれぞれに対応し、該各バージョンに
それぞれ固有のバージョン管理情報を保存、管理する複
数のバージョン固有情報保存オブジェクトとを備えたこ
とを特徴とする請求項１４記載の版数管理方式。