JPWO2008149552A1

JPWO2008149552A1 - データベース矛盾解消方式

Info

Publication number: JPWO2008149552A1
Application number: JP2009517725A
Authority: JP
Inventors: 上村　邦夫; 邦夫上村
Original assignee: 株式会社アテナテレコムラボ
Priority date: 2007-06-06
Filing date: 2008-06-04
Publication date: 2010-08-19
Anticipated expiration: 2028-06-04
Also published as: CN102216910A; US20130226886A1; US9678996B2; CN101765831B; US20110082833A1; US20100198789A1; JP4573277B2; CN101765831A; US20110161292A1; WO2008149552A1; CN102216910B

Abstract

データベースのレコード間の参照関係を変更するデータベース操作方法である。レコードを取り出し（０３０１）、レコードに記録されている参照先レコードを特定し（０３０２）、参照先レコードに記録されている参照先変更情報を特定し（０３０３）、参照先変更情報に対応する参照先変更処理を起動し（０３０４）、得られた新しい参照先を先に取り出したレコードの新たな参照先とする（０３０５）。

Description

本発明はデータベースに記録された情報の構造的矛盾を解消するものである。

＜一般的な背景技術＞
データベース（以下DB）は情報（以下レコード）の集合で、レコードには他のレコードへの参照が記録される事が多い。リレーショナルデータベース（以下ＲＤＢ）では、参照に関する整合性を「参照整合性」（非特許文献１参照）と呼ぶが、オブジェクト指向DBなどの各種のDBにも「参照される側の情報」と「参照する側の情報」があり、参照はレコード間の関連を表現する、各種ＤＢに共通する一般的な概念である。

DBには、参照整合性保持機能として、レコードの変更や削除に関連して他のレコードを変更する「連鎖更新機能」、削除する「連鎖削除機能」や、参照されているレコードの削除をブロックする機能、などが実装されている事が多い。

しかし、参照整合性保持機能により、意図した様にはＤＢが変更できない事や、逆に予期せぬ情報まで削除される事もある。ＤＢが実装した参照整合性保持機能を無効にし、ＤＢを利用する側のプログラムで、参照整合性保持機能に相当する処理を独自のタイミングで行う事も可能であるが、レコードを編集する毎に関連する可能性のある全レコードを調査するなど、その処理負荷は大きい。

＜ＤＢの運用形態＞
本明細書では説明のため、ＤＢの運用形態を以下の３つに分類する。

単独ＤＢアクセス：ひとつの計算機のみでＤＢを操作する運用。

サーバーＤＢアクセス：サーバー（計算機）がＤＢを管理し、他の（端末）計算機はまずサーバーにアクセスしサーバーの処理を通じてＤＢのレコードにアクセスする運用。ＤＢに直接アクセスするのはひとつの計算機のみである点で、単独ＤＢアクセスと同じである。

平行ＤＢアクセス：原本ＤＢを複数の計算機に複製し、複数の計算機で平行して複製DBを編集し、その結果を原本ＤＢに反映する運用。原本ＤＢはサーバーや管理業務を行う特定の計算機などに置くのが一般的である。実質的に複数の計算機で平行してＤＢにアクセスする点で、「単独ＤＢアクセス」や「サーバーＤＢアクセス」と大きく異なる。なお、複製を作成する範囲はＤＢ全体の場合や、当面の作業に必要な部分のみの場合がある。ＤＢ全体を複製する場合でも、あらかじめ原本DBを細分化しておけば、複製ＤＢの更新作業、つまり複製ＤＢの内容を最新の原本DBの内容に一致させる作業、の処理が軽減できる。

＜ＤＢの構造的矛盾＞
処理の高速化のために参照整合性の検査を省略すると、「レコードが参照する先のレコードが存在しない」、「誤った参照が設定されている」などの構造的矛盾が発生する。このまま放置すると、プログラム処理がこの矛盾に遭遇した時点で処理の継続が不可能になる。この状況は、上記のＤＢの運用形態の全てにおいて発生する可能性がある。

平行ＤＢアクセスの場合では、ひとつの複製ＤＢの内容を変更する時に、他の計算機の複製ＤＢに対して加えられた編集内容まで調査する事は出来ないので、構造的な矛盾の発生は宿命とも言える。例えば、他の計算機のレコードが参照しているレコードを削除や変更してしまう可能性がある。これらの各計算機での編集内容を原本ＤＢに反映し、この原本ＤＢを各計算機で新たに複製する事により、これらの矛盾は複数の計算機の複製ＤＢに伝搬してゆく。

平行ＤＢアクセスでは、さらに、同じレコードを複数の計算機で平行して編集する場合がある。これらの編集内容を原本ＤＢに反映する過程で矛盾が顕在化する。これも「データベースに記録された情報の構造的な矛盾」である。

＜平行ＤＢアクセスの現状＞
筆者が指揮し開発したシステム「パワーアップ新聞販売」では閲覧のみに対して平行アクセスを許可している。編集前には「編集権」を取得する事とし、同時にはひとつの計算機しか編集出来ない様にしている。これを本明細書では「編集ロック」と呼ぶ。

平行ＤＢアクセスに関する調査結果を以下に説明する。MVCC（非特許文献１）と呼ばれるオンラインＤＢでは閲覧用の（ＤＢの一部の）複製を作成するが、編集の競合に関しては編集ロックがあるのみである（非特許文献２、非特許文献３）。OODB製品のCache（非特許文献４）とObjectStore（非特許文献５）、も平行書き込みを防止する編集ロックが用意されているだけである。RDBのPostgreSQLでは「同時に起こりうる更新を避けるためには、 SELECT FOR UPDATE文や、適切なLOCK TABLE 文を使用する」（非特許文献６）とあり、これも編集ロックである。特許文献１も編集ロックである。

特許文献２、特許文献３、特許文献４、特許文献５、特許文献６についても調査したが、いずれもＤＢの平行編集による矛盾の解決には適用出来ない。

マイクロソフトのADO.NETの技術は、サーバーＤＢアクセスの運用から平行ＤＢアクセスに一歩踏み出し、端末計算機に当面の作業に必要なデータをサーバーからコピーし、サーバー計算機との接続を切断してから編集作業を行う。編集後に改めてサーバー計算機と接続し編集内容をサーバー計算機に送る。もし編集対象が既に他の端末計算機から変更されていれば、後からの（この）編集を無効にする。これは「オプティミスティック同時実行制御」（非特許文献７および非特許文献８）と呼ばれている。

オプティミスティック同時実行制御は平行ＤＢアクセスの一種であるが、問題点として以下の二点があげられる。ひとつは、レコードの参照整合性の矛盾が発生する可能性を無視している事である。例えば、ある時点でサーバーからレコード（Ｒ）を端末計算機にコピーしそれを削除して１０秒後にサーバーに通知したとする。この１０秒間に他の端末計算機からＲの修正情報が送られていなかったならば、オプティミスティック同時実行制御の仕掛けからこのＲの削除は有効になる。しかし、他のレコードからＲへの参照が残っていれば、または上記１０秒の間に新たに参照が設定されていれば、構造的な矛盾が発生する。

もう一つの問題点は、最新情報を基にした判断が無効となるケースの存在である。最新情報を基にした判断はその時点での最善の可能性が高いので、これが無効になると実際の運用においては問題となる。

例えば、計算機Ａの操作者は朝９時に「この顧客は冷やかしなので、親切な対応は不要」と書き込みその後しばらく放置したとします。一方計算機Ｂの操作者は、お昼の１２時に「この顧客から高額な取引の提案有り」との情報を得て、「契約に向け、最大限の接待を行う」と書き込み、サーバーにアップしたとします。しかし、その１分前に計算機Ａからの編集がアップされると、計算機Ｂの編集のアップは後からとなり無効になります。これは、計算機Ｂの操作者の気まぐれな操作に、計算機Ａが対抗出来ない状況です。

特許文献７では、複製データベースでの編集時刻を基に、競合する編集のバージョンを、「時刻の早い順から値が増えるようにコンテンツのバージョンをふり直す（ステップＳ６０４）」（特許文献７の段落００６５、段落００７９）、そして「日時が最も古いコンテンツ情報を最新のバージョンに更新する」（段落００９７）としている。つまり、先に編集した方を優先としている。

編集の実行時間が早い方を優先しても問題が生じる場合がある。例えば、ある時点（例えば１年前）の編集結果がある計算機の中にのみ存在しており、ある日突然サーバーにアップされて有効になると、他の計算機によって過去１年間に編集されアップされていた編集内容が全て無効になってしまう。この様な運用は通常は許されないと思われる。

＜従来技術の限界＞
編集ロックはレコードに対する編集の競合を防ぐものであり、平行ＤＢアクセスにおいて発生する「レコードが参照する先のレコードが存在しない」、「誤った参照が設定されている」などの構造的矛盾は防止できない。編集時間やサーバーへのアップ時間で有効な編集を決定する方法でもこの構造的矛盾は防止できないし、以上に説明した様に、操作者の期待に反する編集が有効にされるなどの問題が発生する。

＜参照整合性に関する従来技術＞
参照整合性について従来技術を調査した。特許文献８では、情報を一括入力する時に一時的に参照整合性の制約を外し、その後で参照整合性を検査する。特許文献９では「計算機が編集を行っている途中で発生する一時的な参照整合性が壊れた状態を別の計算機が読込むことを防止する」ための工夫である。いずれも、本発明の課題には適用出来ない。

特許文献１０では、主テーブルの変更する場合には、その変更に関係するレコードを持つ計算機に即時に通知する。しかしこの通知の複雑な処理よりもサーバーＤＢアクセスの運用の方が単純明快であるので、平行ＤＢアクセスと組み合わせ、あえて用いる価値は無いと思われる。
特開平１１−２７２５３４号公報特開平１１−１６１５３５号公報特表２００５−５０３６０６号公報特表２００５−５０８０５０号公報特開平８−１６４４７号公報特表２０００−５０１５３２号公報特開２００５−２１６１６７号公報特開２００６−７９２６０号広報特許３１８５７１８号明細書特許３６１２４４９号明細書「主な機能とメリット」、[online]、2007年4月22日検索、インターネット（URL:http://www.sonicsoftware.co.jp/products/object_store/function.html）「MVCC（多版型同時実行制御）9.1. はじめに」、[online]、2007年4月22日検索、インターネット（URL:http://www.postgresql.jp/document/pg721doc/user/ mvcc.html #MVC C-INTRO）「9.5. アプリケーションレベルでのデータの一貫性チェック」、[online]、2007年4月22日検索、インターネット（http://www.postgresql.jp/document/pg721doc/user/applevel-consistency.html）「Cache Technology Guide」、[online]、2007年4月22日検索、インターネット（URL: http://www.intersystems.co.jp/cache/technologyguide/technologyguide.html）「主な機能とメリット」、[online]、2007年4月22日検索、インターネット（URL:http://www.sonicsoftware.co.jp/products/object_store/function.html）「9.5. アプリケーションレベルでのデータの一貫性チェック」、[online]、2007年4月22日検索、インターネット（http://www.postgresql.jp/document/pg721doc/user/applevel-consistency.html）「ADO.NET におけるデータ同時実行制御の概要」、2007年１月、MSDNサブスクリプションライブラリー（msdn subscriptions Library）、ディスクファイル（URL:ms-help://MS.MSDNQTR.v80.ja/MS.MSDN.v80/MS.VisualStudio.v80.ja/dv_raddata/html/d5293098-4a88-4110-abd2-34d9e6661664.htm）「チュートリアル : 同時実行例外の処理」、2007年１月、MSDNサブスクリプションライブラリー（msdn subscriptions Library）、ディスクファイル（URL: ms-help://MS.MSDNQTR.v80.ja/MS.MSDN.v80/MS.VisualStudio.v80.ja/dv_raddata/html/73ee9759-0a90-48a9-bf7b-9d6fc17bff93.htm）「参照整合性とは」、［online］、2007年１月、［2007年6月6日検索］、インターネット（URL:http://www.leasekin.com/rodan/makepos/02ac2kintro/table_kihon/p01_0130_sansyouseigousei.htm）

処理速度向上のために、レコード間の参照関係を十分に調査すること無くＤＢを編集すると「データベースに記録された情報の構造的な矛盾」が生じる。これは、単独ＤＢアクセス、サーバーＤＢアクセス、平行ＤＢアクセスに共通した問題である。

平行ＤＢアクセスにおける情報の編集では、参照整合性の矛盾や、レコードに対する編集の衝突など、ＤＢの構造的な矛盾の発生は必然と言える。複数の計算機で平行してテーブルに情報を追加すれば、これらの情報に付与される主キーの値が重なる可能性もある。これも構造的な矛盾である。

それでも、平行ＤＢアクセスを実現したいのには理由がある。単独ＤＢアクセスでは他の計算機とのデータ共有に問題があるし、サーバーＤＢアクセスでは「サーバーとの通信が不可能な状況ではデータにアクセスする事は出来ない」という致命的な欠陥がある。移動体では通信不可能なケースが頻発するし、いわゆるミッションクリティカルな業務では通信不可能な状況下でも業務遂行が求められる。サーバーと通信によるレスポンスの遅さも問題である。

閲覧のみでなく編集まで含めた平行ＤＢアクセスが理想とされながらも、いままで実用的なシステムが現れなかったのは、ＤＢ編集の結果生じる「データベースの構造的な矛盾」を解決する合理的な方法が示されていなかったためである。本発明では「データベースに記録された情報の構造的矛盾」の一時的な発生を許容し、必要なときに合理的に解決する方法を開示する。

＜参照先変更情報の導入＞
ＤＢの操作者は、レコード間の参照関係をどの様に変更するかについて明確な意図を持ち、その意図に従ってＤＢを編集する。その意図どおりに、関係する全ての参照を変更すれば矛盾は生じない。この作業を、従来の様にＤＢの編集する度に行うと処理負荷が膨大となるので、変更対象のレコードに「参照先変更情報」を指定（記載）しておく。このレコードへの参照を検出したときに、（プログラムが）この「参照先変更情報」の指示に従い参照先を変更する。具体的な説明を以下に示す。

参照先変更情報の設定とは、このレコードを参照していた（他の）レコードが新たに参照すべきレコードの指定である。この時、参照先変更情報を設定したレコードには「削除マーク」を付ける。削除マークのついたレコードを表示しなければ、操作者にとっては削除されたのと同じであり、新規に参照される事も無い。

たとえば、「東京」というレコードに削除マークを付け、その「参照先変更情報」として、「東京」の上位概念である「日本」というレコードを指定する。なお、参照先変更情報をどの様に指定するかは、操作者の判断事項（またはプログラム設計者の判断事項）である。「無指定」というレコードを新たに定義して、これを参照先として「参照先変更情報」に指定しても良い。

いままで「東京」を参照していたレコードを（プログラムで）処理する時に、「参照先変更情報」に従い参照先を「日本」（又は「無指定」）に変更すれば、処理が必要なレコード毎に徐々に矛盾が解消されてゆく。

ＲＤＢでは参照されるレコードの集合を主テーブルと呼ぶが、参照先変更情報として同じ主テーブルの別のレコードを指定しても良いし、別の主テーブルのレコードを指定しても良い。参照先変更の無限ループを避けるためには、新たな主テーブルを作成しそのレコードに参照先を変更するのも一案である。

参照先変更情報の発展形として「復活」を指定することが出来る。あるレコードに削除マークが付いており、その「参照先変更情報」として「復活」が指定されていたとする。このレコードを参照するレコードを検出した時には、削除マークを消去することによりレコードを復活させる。

以上でのレコードの削除は、削除マークを付けるだけの論理的な削除であり実際には削除されていないので復活が可能となる。レコードの本当の削除作業を行うのは、長期間の運用により削除マークが付いたレコードが多量になりメモリを圧迫する状況になってからで良い。

実際のレコード削除までに参照先の変更が完了していれば問題ないが、もしも未変更のレコードが残ったとしても、参照先が実際に削除された事を検出したプログラムが表示するメッセージに対応して、操作者が参照先を改めて指定しても（数が少なければ）大きな問題とはならない。本当の削除の実行は処理負荷の少ない時に行う事とし、この削除に際し関連する情報を完全に調査して必要な参照先変更をもれなく実行すれば問題は起きない。

レコードを修正しても他のレコードから参照を修正する必要が無いなら、特に「参照先変更情報」を指定する必要はない。例えば全国の都市名を表示するレコードにおいて、「東京」を「東京都」に変更してもこれを参照するレコードを変更する必要は無い。

以上では、参照整合性の矛盾が一時的に発生する事を許容し、必要なときに徐々に解決していく例を説明した。

＜編集の衝突の解決＞
平行ＤＢアクセスではさらに、同じレコードに関する編集が衝突する可能性がある。参照先変更情報の適用との関係も含めて対応を明らかにする必要があるが、まずは単純な衝突の解決方法を示す。

「オプティミスティック同時実行制御」や特許文献７では、サーバーへのアップ時間や編集時間の前後で採用する編集を決定していたが、本発明では「より最新の情報に対する編集を優先」する仕掛けを提示する。

具体的には、（ａ）原本ＤＢが更新される毎にそのＤＢのバージョンを更新し、（ｂ）計算機に原本ＤＢを複製する際には、そのバージョンを編集の対象となる複製ＤＢのベースバージョンとして記録する。（ｃ）複製ＤＢを編集した計算機がその編集結果を、原本DBを管理する計算機（例えばサーバー）にアップする（送る）際には、そのベースバージョンも通知する。（ｄ）アップした編集内容が別の端末計算機からのアップ内容と衝突した場合には、より新しいベースバージョン（の複製ＤＢへ）の編集を採用する。（ｅ）同じベースバージョンに対する編集ならは先にアップされた方を採用する。上記（ｄ）（ｅ）の処理は、原本DBを管理する計算機（例えばサーバー）で行うのが素直な実装であるが、同じ結果が得られるならば、別の計算機で行っても良いし、複数の計算機で分担して行っても良い。

編集を行う計算機は「（Step 1）原本ＤＢをコピーして複製ＤＢを作成、又は複製ＤＢを最新の原本ＤＢと同期し、（Step 2）複製ＤＢを編集し、（Step 3）複製ＤＢに対する編集内容を複製ＤＢのバージョンと共に原本DBを管理する計算機にアップ」の、一連の処理を行う。（Step 3）の後、原本DBを管理する計算機で前記の（ｄ）（ｅ）の基準で編集の採否が決定される。なお、（Step 2）の間は原本DBを管理する計算機との接続を確保しておく必要は無い。

計算機Ａによる（Step 1）と（Step 3）の処理の間に、もしも別の計算機Ｂからの編集のアップが行われた場合は、とりあえずＢの編集内容が採用され原本ＤＢのバージョンが上がる。その後、計算機Ａの編集内容がアップされると、Ｂの編集とどちらを優先するかの判定が行われる。Ｂの編集のベースバージョンとＡの編集のベースバージョンを比較して、より新しい方が採用される。もし編集Ａが採用されれば、その時点で編集Ｂは無効となる。両方のベースバージョンが同じなら、逆に先にアップされた編集Ｂが採用され、編集Ａは無効となる。

編集内容のアップ時点の原本DBのバージョンが、編集のベースバージョンよりも新しくなっている場合は、より新しいベースバージョンの（つまりより新しいＤＢの複製に対する）編集が、後からアップされ、それが有効になる可能性を示している。

逆に、編集のアップ時点の原本DBのバージョンが、編集のベースバージョンと同じなら、より新しいベースバージョンの編集が、後からアップされる事は無い。またこのアップは同じベースバージョンの編集の中での最初のアップである。従って、このアップが採用され、原本ＤＢが更新され、その結果バージョンがひとつだけ更新される。

編集を行う計算機で、（Step 1）から（Step 3）までの処理を短時間で行うほど、別の編集結果が割り込んでアップされる可能性は極めて小さくなる。（Step 3）の後で、複製ＤＢを原本ＤＢと同期し、原本ＤＢのバージョンを取得して複製ＤＢのベースバージョンとする。この時に、ベースバージョンが一つだけ更新されていれば、先の編集結果が有効になった事が（この計算機から）確認できる。逆に二つ以上後ならば、アップが無効となっているか、又はこれから無効になる可能性がある。

（Step 1）から（Step 3）までの処理を短時間で行うと、オンライン運用（サーバーＤＢアクセス相当）に極めて近い運用となり、編集の競合が予想されるレコードの編集に有効である。

逆に、編集が競合する可能性が極めて少ないレコードを扱う場合は、（Step 2）の期間を極端に長くし、入力や編集に十分な時間をかけ、そのあとで（Step 3）を実行しても良い。もちろん（Step 2）の間は原本ＤＢを管理する計算機（例えばサーバーなど）と接続しておく必要は無い。

例えば、会社の組織ごとに支払伝票を入力するケースでは、レコードを修正するのは入力ミスや処理ミスを発見した場合であり、修正するとしてもレコードを入力した計算機で行う事が多い。この様なケースでは、（Step 2）の期間を極端に長くしたオフライン運用で問題は無い。たとえインターネット接続が出来ない状況でも支払伝票をゆっくり入力し、決算や検査の近くなってからまとめてアップ（Step 3）すれば良い。

万が一、平行編集によるＤＢの構造的矛盾が発生したとしても、本発明の方法を（これ以降に説明される方法も含めて）適用する事により、必要な時に矛盾が解消されてゆく。

以上に述べた様に、オンラインに近い運用か、オフラインに近い運用かの選択が（Step 1）（Step 2）（Step 3）の実行周期だけで選択できて、かつ両方の運用が混在できるのが、本発明の「より最新の情報に対する編集を優先」による「編集の衝突の解決」のひとつの長所である。つまり、端末計算機が（Step 1）（Step 2）（Step 3）の実行周期を変更するだけで、ある時はほぼオンライン運用を、またある時はほぼオフライン運用を行う事が出来る。また、ある端末計算機はほぼオンライン運用、別の端末計算機はほぼオフライン運用と言う混在も可能である。

「オプティミスティック同時実行制御」や特許文献７の方法では、先に説明した様に、「ほぼオフライン運用」の計算機からアップされた情報が、「ほぼオンライン運用」の計算機からの情報のアップを妨害する事があった。しかし、本発明の「より最新の情報に対する編集を優先」による「編集の衝突の解決」なら、同じレコードに対する編集は「ほぼオンライン運用」の編集結果が優先される。編集結果を有効にしたければ「ほぼオンライン運用」を行えば良いし、編集の競合が少ないレコードを扱い、かつ通信の手間を省略したい場合には「ほぼオフライン運用」を行えば良い。

「編集結果を有効にしたい場合は、（Step 1）から（Step 3）までの処理を短時間で行えば良い」との指針は人間にとって理解し易いのは、「より最新の情報を基にした判断（編集）が優先される」事は人間の感覚に近くいからである。これは多くの人間がかかわる実際のＤＢ運用に適した特性であり、本発明の「より最新の情報に対する編集を優先」による「編集の衝突の解決」のもうひとつの長所である。

以上に述べた仕組みで、単純な衝突、つまり参照される事がないレコードに対する編集の競合は解決される。なお、以上では、原本ＤＢに対してバージョンを付与していたが、原本DBのテーブルやレコードに対してバージョンを付与して管理しても良い。これは原本ＤＢを細分化したのと同じである。

＜参照先変更情報の衝突の解決＞
参照される可能性のあるレコードに対する編集が衝突するケースについてはさらに考察が必要である。説明のため、編集Ｘと編集Ｙが衝突、つまり両者が同じレコードに対し異なる「参照先変更情報」を設定し、「より最新の情報に対する編集を優先する」仕掛けにより、編集Ｘが採用されたと仮定する。

問題は、編集Ｙが無効と判定される前に、編集Ｙによって設定された「参照先変更情報」により、一部のレコードの参照先が変更されてしまう事である。例えば、編集Ｙを行った計算機の中で、その「参照先変更情報」に従って一部のレコードの参照先の変更を行い、その後、編集Ｙをアップしたところ、（編集Ｘが有効と判定されて）編集Ｙが無効になった場合である。編集Ｙによる参照先変更の後に編集Ｘによる参照先変更を行った結果が、編集Ｘのみによる参照先変更結果と同じになる保証は無い。

この問題を解決する手順を以下に示す。参照される可能性のあるレコードを計算機で編集したら、この計算機内部で参照先変更情報に基づく参照の変更処理を行う前に、編集情報をアップし、最新の原本ＤＢに複製ＤＢを同期させ、複製ＤＢのベースバージョンを更新する。ベースバージョンが一つだけ更新されていれる事を確認した後で、つまりこの編集が採用された事を確認した後で、参照先変更情報に基づく参照の変更を行う。

先の例ならば、編集Ｘを送った計算機は編集Ｘが採用された事を確認して、これに基づいて参照の変更処理を行う。編集Ｙを送った計算機は編集Ｙが無効になり、編集Ｘが採用されている事が確認できるので、必要ならば改めて編集を行う。編集Ｘに基づく参照先変更を行っても良い。

また、あるレコードに対する参照先変更情報が複数回変更されている場合に、途中の参照先変更情報を飛ばして最後の参照先変更情報のみで参照先を変更すると、矛盾が生じる。そこで、参照を設定した時点、又は参照を確認した時点の（複製ＤＢの）ベースバージョンを記録しておく。

ひとつのレコードが複数の参照を持つ場合、個々の参照毎にベースバージョンを記録する事も可能だが、レコードに記録する情報量が多く管理も煩雑になる欠点がある。そこでレコード毎に、レコードバージョン（レコードに記録するバーション）として記録する。

レコードが新規に作成されたとき、又はレコードの内容が一部でも変更された時に、その時点の（複製ＤＢの）ベースバージョンをレコードバージョンに記録・更新する。参照先の設定・変更も内容の変更であるので、レコードバージョンを更新する。また（少なくとも一つの）参照先を変更した時、またはそれ以外の変更を行った時は、そのレコードの全ての参照をチェックし、参照先に参照先変更情報が設定されていれば、それに従って参照先を変更する。この結果、このレコードのすべての参照は、レコードバーションに記録されたベースバージョンの複製ＤＢで更新または確認されたものとなる。

レコードの追加に際して、そのレコードに与える主キー（ＩＤ）も以上の仕組みを応用して設定する事も出来る。具体的には次の主キーを記録しておくレコード（Ｋ）をＤＢ内に設定する。新規に作成するレコード（Ｚ）の主キーにこのＫの値を用い、その後Ｋの値を更新する。Ｋの更新が「より最新の情報を対象にした編集を優先する」ルールに照らして有効とされればレコードの追加は完了だが、無効と判断された場合はＫの値の更新が無効になり、レコード（Ｚ）の追加も無効として処理する。

しかし、レコードの追加を確定するには「（Step 1）から（Step 3）を速やかに行う」必要があり、「ほぼオフライン運用」の適用範囲を狭める事になる。従って「ほぼオフライン運用」を重視する場合は、各計算機がレコードに付与する主キー（ＩＤ）の範囲が重ならない様に、あらかじめ指定しておく方法が望ましい。

本発明の、参照先変更情報を用いた方法により、一時的に発生する参照整合性の矛盾は必要な時に徐々に解消されていく。これにより、ＤＢ編集毎に行う参照整合性の検査が不要となり、編集処理が高速になる。

また、「より最新の情報を対象にした編集を優先」する方法により、平行ＤＢアクセスでの編集の衝突を合理的に解消する事が出来る。この方法では扱う情報の性質に応じて、オンラインに近い運用か、オフラインに近い運用かの切り替えが自由に行える。異なる運用（オンラインに近い運用、又はオフラインに近い運用）の計算機がサーバーを介して一緒に運用出来るのも大きな特徴であり、複数の計算機がＤＢを共有するケースに大きな自由度を与える。

「参照先変更情報を用いた方法」と「より最新の情報を対象にした編集を優先」する方法を組み合わせる事により、平行ＤＢアクセスでの編集により発生する矛盾を合理的に解消する事が出来る。特に「参照される可能性のあるレコードを編集」する場合に効力を発揮する。

平行ＤＢアクセスには「ＤＢを介して他の計算機と情報交換が可能」、しかも「外部との通信が不可能な場合でもＤＢの操作を行う事が出来る」、「サーバーと通信によるレスポンスの遅れも無い」などの長所があるが、必然的に発生するデータベースの構造的矛盾を解消する方法が無いため、編集を平行して行う事は困難であった。しかし、本発明によりこれらの問題が解決され、実用的な平行ＤＢアクセスのシステムが可能になった。移動体によるＤＢアクセスやミッションクリティカルな業務への適用が期待される。また、常に通信網との接続する手間や費用を省きたいケースにも有効である。

一般的な計算機の構成プログラムにより実現された機能を提供する手段の集合としての計算機の構成参照先を変更する手順参照先変更情報を設定する手順「より最新の情報に対する編集を優先」するための端末計算側の処理「より最新の情報に対する編集を優先」するためのサーバー計算側の処理他のレコードから参照される可能性のあるレコードを編集する端末計算側の処理参照先変更の実施例１、２、３参照先変更の実施例４参照先変更の実施例５ＤＢのバージョン管理の実施例

符号の説明

0100 計算機
0102 通信装置
0103 演算装置
0104 主記憶装置
0105 主記憶装置内のＤＢ（データベース）
0106 二次記憶装置
0107 入出力装置
0108 表示装置
0109 バス
0110 通信網
0111 二次記憶装置内のＤＢ（データベース）
0201 送信手段
0202 受信手段
0203 参照先変更手段
0204 参照先変更情報指定手段
0205 ＤＢ（データベース）
0206 編集の有効性判定手段
0301 レコードを取り出す処理
0302 このレコードに記録されている参照先レコードを特定する処理
0303 この該参照先レコードに記録されている参照先変更情報を特定する処理
0304 この参照先変更情報に対応する参照先変更処理を起動する処理
0305 得られた新しい参照先を先に取り出した(0301)レコードの新たな参照先とする処理
0401 レコードを取り出す処理
0402 参照先変更情報を指定する処理
0501 複製ＤＢを原本ＤＢに同期させる処理
0502 原本ＤＢのバージョンを複製ＤＢのベースバージョンとして記録する処理
0503 複製DBの編集
0504 判定
0505 編集内容と編集対象ＤＢのベースバージョンをサーバーに送る処理
0601 編集されアップされたレコードを順番に取り出す処理
0602 このレコードのレコードバージョン（NRV）を特定する処理
0603 このレコードに対応する原本レコードのレコードバージョン（ORV）を特定する処理。
0604 レコードバージョンの比較
0605 新たにアップされたレコードを原本ＤＢで有効とする処理
0606 原本ＤＢのバージョンをひとつ更新する処理
0701 参照される可能性のあるレコードを編集する処理
0702 編集内容とベースバージョン（BV1）をサーバーに送る処理
0703 複製DBを原本ＤＢに同期させる処理
0704 新たなベースバージョン(BV2)を取得し記録する処理
0705 BV2とBV1の比較
0801 従テーブル
0802 主テーブルＡ
0803 主テーブルＢ
0804 項目ｎ
0901 参照先レコードのラベルを取り出す処理
0902 あらかじめ指定された「本社」の文字列が含まれるかをチェックする処理
0903 判定
0904 参照先を変更する処理
1001 ノードＰ
1002 ノードＲ
1003 ノードＱ
1004 ノードを特定する処理
1005 テーブルとレコードが指定されているかを確認する処理
1006 参照元レコードの参照先を変更する処理
1007 上位レコードを特定する処理
1101 サーバー
1102 計算機Ａ
1103 計算機Ｂ
1104 原本ＤＢ
1105 複製ＤＢ（Ａの内部）
1106 複製ＤＢ（Ｂの内部）
1107 レコードＸの原本
1108 レコードＸの複製（Ａの内部）
1109 レコードＸの複製（Ｂの内部）
1110 同期（Ａの複製ＤＢを新規作成）
1111 同期（Ｂの複製ＤＢを新規作成）
1112 同期（Ａの複製ＤＢの更新その１）
1113 （ＡによるＸの複製に対する）編集
1114 （Ａからサーバーへの）編集の送信
1115 Ｘの原本の更新（計算機Ａの修正の反映）
1116 （Ａの修正が有効との）確認と同期
1117 同期（Bの複製ＤＢを更新）
1118 （BのＸの複製に対する）編集
1119 （Ｂからサーバーへの）編集の送信
1120 Ｘの原本の更新（計算機Bの修正の反映）
1121 （Ｂの修正が有効との）確認と同期
1122 同期（Ａの複製ＤＢの更新その２）
1123 Ｘの原本の修正（原本に反映された計算機Bの修正の反映）

本発明の請求項に記載された方法は計算機のプログラムとして実現されるのが一般的である。図１に典型的な計算機0101の構成を示す。演算装置0103、主記憶装置0104、二次記憶装置0106、入出力装置0107、表示装置0108がバス0109で接続されている。他の計算機とデータを交換する場合は通信装置0102を介して通信網0101に接続する。各請求項で言及している「データベース」が、二次記憶装置0106内のＤＢ0111又は主記憶操作0104の内部のＤＢ0105である。

プログラムは二次記憶装置0106に記録され、起動されると主記憶操作0104に展開され、プログラムに指定された手順で演算装置0103が動作する。この結果として計算機は、プログラム開発者が意図した動作を実現する手段の集合体に再構成される。請求項に記載された方法を実現する機能構成を図２に示す。

プログラムによるＤＢの操作は、ＤＢの全体または一部を主記憶操作0104に展開してから行うのが一般的である。二次記憶装置0106内のＤＢ0111の全部又は一部を主記憶操作0104に展開したＤＢ0105を操作し、その編集結果を二次記憶装置0106内のＤＢ0111に書き込む。しかし通常は、ＤＢは二次記憶装置0106内に有るとし、主記憶操作0104に展開したＤＢ0105と区別せず議論するので、図２では両者を統合した概念としてのＤＢ0205を示している。

「参照先変更手段0203」は請求項１の「レコードに対して記録された情報に基づき該レコードへの参照を別のレコードへの参照に変更する工程」または請求項２「削除マークの付いたレコードに対する参照を検出したら、削除マークを消去する工程」を実現する。

「参照先変更情報指定手段0204」は請求項３の「レコードへの参照を別のレコードへの参照に付け替える情報を、該レコードに対して記録する工程」を実現する。

「編集の有効性判定手段0206」は請求項４の『複数の「複製に対する編集内容と、この複製が作成された時の原本データベースのバージョンの組み合わせ」の中で、より新しいバージョンに対する編集内容を有効とし、原本データベースに反映する工程』、を実現する。これは編集の有効性を判定する処理を実装する計算機（例えばサーバーなど管理機能を実装する計算機）に存在する必要がある。送信手段0201と受信手段0202は、計算機間の通信に用いられる。

図３から図７は請求項１から請求項５の手順を説明したものである。請求項１に相当する処理手順が図３である。レコードを取り出し0301、このレコードに記録されている参照先レコードを特定0302し、該参照先レコードに記録されている参照先変更情報を特定し0303、この参照先変更情報に対応する「参照先変更処理」を起動する0304、得られた新しい参照先を先に取り出した(0301)レコードの新たな参照先とする0305。この「参照先変更処理」の内容は、ここまでの説明では単に指定されている参照先を取得するだけであるが、これ以外の例については実施例で説明する。

図３は請求項２の処理にも対応する。レコードを取り出し0301、このレコードに記録されている参照先レコードを特定し0302、該参照先レコードに記録されている参照先変更情報を特定し0303、この参照先変更情報に対応する「参照先変更処理」を起動する0304。「復活」を検出すれば、該参照先レコードの削除マークを消去する。このケースでは、参照先に変更は無いので「得られた新しい参照先を先に取り出した(0301)レコードの新たな参照先とする」0305で行う事は無い。

請求項３に相当する処理手順が図４である。まずレコードを取り出す0401。該レコードへの参照を別のレコードへの参照に付け加える情報を該レコードに指定する処理が「参照先変更情報を指定する」処理0402である。

本発明の「より最新の情報に対する編集を優先」する方法を実現するために、編集を行う計算機では図５に示す処理を行う。まず複製ＤＢを原本ＤＢに同期させる0501。実際には状況に応じて、新規に複製ＤＢを作成する場合や差分情報を取得して複製ＤＢを更新する場合がある。同時に原本ＤＢのバージョンを複製ＤＢのベースバージョンとして記録する0502。その後、複製DBの編集0503を必要なだけ0504繰り返し、その後アップする0505。ここでアップとは、サーバーなど原本DBを管理する機能を実装する計算機へ編集内容と編集対象ＤＢのベースバージョンを送る事である。

請求項４はアップされた編集の有効・無効を判定する処理である。「より新しいバージョンの編集を特定する」ひとつの実施方法として、レコード毎にレコードバージョンを記録する。レコードが作成された時、その時点の（複製DBの）ベースバージョンをレコードバージョンとして記録する。また、レコードの内容が一部でも修正された時には、その時点の（複製DBの）ベースバージョンをレコードバージョンとして記録する。

このレコードバージョンを用いて請求項４の処理を詳細に説明したのが図６である。編集され新たにアップされたレコードを順番に取り出す0601。このレコードのレコードバージョン（NRV）を特定し0602、このレコードに対応する原本レコードのレコードバージョン（ORV）を特定し0603、これらのレコードバージョンを比較する0604。NRV > ORV ならば、新たにアップされたレコードを原本DBで有効とし0605、NRV = ORV 又は NRV < ORVならば新たにアップされたレコードを無効とし次のレコードの処理に移る。編集され新たにアップされたすべてのレコードについて以上の処理が完了したら、原本ＤＢのバージョンをひとつだけ更新する0606。なお、バージョン管理については実施例６で詳細に説明する。

請求項５は、他のレコードから参照される可能性のあるレコードを編集する場合の手順であり、その流れを図７に示す。まずは、図５の手順と同様に、計算機の複製ＤＢを原本ＤＢに同期する0501。同時に原本ＤＢのバージョンを複製ＤＢのベースバージョンとして記録する0502。

その後、参照される可能性のあるレコードの編集0701を行い、編集内容とベースバージョン（BV1）をサーバーに送る0702。その後速やかに、複製DBを原本ＤＢに同期させ0703、原本DBの新たにバージョンを、新たなベースバージョン(BV2)として取得し、記録する0704。BV2がBV1の次の値ならば0705、参照される可能性のあるレコードの編集は完了したので、次の処理に移る事が出来る。この次の処理で扱うレコードの参照先に「参照先変更情報」があれば、これに従い参照先を変更する。BV2がBV1の次の値で無い場合は0705、参照される可能性のあるレコードの編集0701を再度試みる事ができる。

＜参照先が変更されない例＞
図８を用いて、参照先変更情報の設定と変更処理の具体例を示す。図８の従テーブル0801に複数のレコードが記録されており、「項目ｎ」0804に主テーブルＡ0802のレコードへの参照が記録されている。

従テーブル0801のＩＤ＝ａのレコードは主テーブルＡ0802のＩＤ＝1のレコードを参照している。このレコードの「参照先変更情報」は「無指定」なので前記の従テーブルのレコードからの参照が変更される事は無い。

＜復活の例＞
図８の例では「表示=Fasle」の指定が「削除フラグ」に相当する。つまり
レコードが操作者画面に表示されなければ、利用者にとって削除されているのと同じである。主テーブルＡ0802ではＩＤ＝２，３，４のレコードが削除状態（表示=Fasle）にある。従テーブル0801のＩＤ＝ｂのレコードを処理する時に、主テーブルＡのＩＤ＝２のレコードの「参照先変更情報」を参照し、「復活」が指定されているので「表示=True」とする。以上により復活の作業を完了したので「復活」指定を「無指定」に変更する。

＜参照が変更される例＞
参照先変更情報が「変更先レコードＩＤ＝Ｘ」（Ｘは説明のための仮のＩＤ：主キー）の場合、対応する参照先変更処理は、このレコードへの参照を指定されたレコードへの参照に変更する。つまり、従テーブルからこのレコードへの参照が有ればこの参照をレコード＝Ｘへの参照に変更する。

図８の従テーブル0801のＩＤ＝ｃのレコードは当初、主テーブルＡ0802のＩＤ＝3のレコードを参照している。このレコードの「参照先変更情報」には「変更先レコード＝５」が指定されている。そこで、従テーブルのＩＤ＝ｃのレコードの参照先をＩＤ＝５に変更する事とし、従テーブルのＩＤ＝ｃのレコードの「項目ｎ」の（主テーブルＡのＩＤ）３を５に書き換える。

＜参照変更の循環防止＞
主テーブルを大幅に変更すると参照の変換に循環が起きる可能性がある。この場合は従来の主テーブルと新しい主テーブルの両方を用意しておいて、従来の主テーブルへの参照を新しい主テーブルへの参照に切り換えることにより循環参照が防止出来る

参照先変更情報が、「テーブル指定＝Ｓ」（Ｓは説明のための仮のテーブル名）＋「変更先レコード＝Ｙ」（Ｙは説明のための仮のＩＤ：主キー）の場合、対応する参照先変更処理は、このレコードへの参照を、指定されたテーブルＳの指定されたレコードＹへの参照に変更する。

図８の従テーブル0801のＩＤ＝ｄのレコードは当初、主テーブルＡ0802の４（ＩＤ＝４のレコード）を参照している。このレコードの「参照先変更情報」には「主テーブルＢ」「変更先レコード＝１」が指定されている。そこで参照先を主テーブルＢ0803のＩＤ＝1のレコードとし、従テーブルのＩＤ＝ｄのレコードの「項目ｎ」0804を書き換える。

なお、図８では説明のために「同じテーブルへの参照先変更」と「別のテーブルへの参照先変更」混在させているが、現状のＲＤＢでは、従テーブルのある項目が参照する主テーブルは一つと制限されている事が多い。従って、本発明を用いる際には、ＲＤＢが認識するテーブルは変換後の主テーブルのみとし、元の主テーブルは本発明に基づくプログラムだけがアクセスするのが現実的である。

＜変換先指定ロジック＞
「参照先変更情報」として「同じテーブルの別のレコード」+「変更先指定ロジック＝Ｚ」（Ｚは説明のための仮のロジック指定ラベル）が指定されている場合、または、「参照先変更情報」として「別テーブルのレコード」+「変更先指定ロジック＝Ｚ」が指定されている場合の参照先変更処理は以下である。従テーブルから主テーブルのこのレコードを参照した場合は、Ｚで特定される変更ロジックを起動し、その結果に従って、参照元レコードの参照先を変更する。

図９の従テーブルのＩＤ＝ｅのレコードは当初、主テーブルＡのＩＤ＝１１のレコードを参照している。このレコードの「参照先変更情報」には「同じテーブルの別のレコード」「変更先指定ロジック＝Ｚ」が指定されている。そこでロジックＺを起動する。

図９はロジックＺを以下の様に実装した例を示している。まず当初の参照先レコードのラベルを取り出す0901、この例では「本社屋」である。次に、あらかじめ指定された文字列、例えば「本社」、が含まれるかをチェック0902し、含まれる事を確認0903したら、従テーブルのＩＤ＝ｅのレコードの参照先を主テーブルＡのＩＤ＝１３のレコードへの参照に変更する0904。従テーブルのＩＤ＝ｆのレコードも当初は主テーブルＡのＩＤ＝１２のレコードを参照しているが、同様に主テーブルＡのＩＤ＝１３のレコードへの参照に変更される。この様にして、「本社屋」「本社管理部」「本社」と、同じ概念が異なるレコードで表現され、それぞれ別個に参照されていたが、「本社」レコードへの参照に統一される。

＜変更ツリーによる参照先変更＞
「参照先変更情報」として、「変更ツリーのノード＝Ｖ」（Ｖは説明のための仮のノードラベル）が指定されている場合、ノードＶに対して指定されているレコードに変更する。ノードＶに対して（参照変換先の）レコードが指定されていなければ、ノードＶの上位ノードを順にたどり最初に見つけたレコードに参照先を変更する。

図１０の従テーブルのＩＤ＝ｈのレコードは当初、主テーブルＡのＩＤ＝２１のレコードを参照している。このレコードの「参照先変更情報」には「変更ツリーのノード＝Ｐ」が指定されている。そこでノードＰ1001を特定し1004、テーブルとレコードが指定されているかを確認し1005、「主テーブルＢのＩＤ＝３２」が指定されているので、これを参照元レコードの参照先として書き換える1006。従テーブルのＩＤ＝ｉのレコードは当初、主テーブルＡのＩＤ＝２２のレコードを参照している。このレコードの「参照先変更情報」には「変更ツリーのノード＝Ｑ」が指定されている。そこでノードＱ1003を特定し1004、これにテーブルとレコードが指定されているかを確認1005する。ノードＱには指定が無いので、上位のノードつまりノードＲ1002を特定し1007、再度これにテーブルとレコードが指定されているかを確認し1005、「主テーブルＢのＩＤ＝３１」が記入されているので、これを参照元レコードの参照先とし1006、参照元レコードに書き込む。

「参照先変更情報」が指定されたレコードが新たに参照される事を防止するためには、表示しないのが良い。図１０では主テーブルＡは表示されず、新しい主テーブルである主テーブルＢのみが表示される。従って、操作者が主テーブルＡのレコードを参照先として選択する事はできない。図９の例では、ID=11, 12 のレコードは表示されず（表示＝Flase） ID＝13のレコードのみが表示される。つまり新たな参照先として設定出来るのは、「本社」のみである。

「参照先変更情報」が指定され、表示＝Flaseとなっているレコードや、古い主テーブルも参照先変更情報を指定・変更する操作者には（当然）表示する。

参照先変更処理は従テーブルからの参照を行う（つまりプログラムで参照先の情報にアクセスする）ときに実行しても良いし、優先度の高い処理が実行されていない時にまとめて変更しておいても良い。

＜ＤＢのバージョン管理＞
本発明の「より最新の情報に対する編集を優先」する方法を実施するには、原本DBのバージョンと複製ＤＢのベースバージョンを管理する必要がある。この仕組みを図１１で説明する。

原本ＤＢ1104はサーバー1101に置かれ、計算機A1102がその複製ＤＢ1105を、計算機B1103も複製DB1106を持っている。原本ＤＢ1104の最初のバージョンは０で、その複製DBのベースバージョンもそれぞれ０である。なお請求項４に関し先に説明した様に、原本ＤＢおよび複製ＤＢ内部のレコードに毎にレコードバージョンを記録する。レコードバージョンはそのレコードが新規に作成された時、または一部でも修正された時のベースバージョンの記録である。図１０のレコードＸの原本および複製のレコードバージョンの初期値０である。

計算機Aは最初の同期1110で複製DBを作成し、計算機Bも最初の同期1111で複製DBを作成している。どちらもベースバージョンは０である。その後、原本DBのバージョンは０から６まで更新されているが、これは計算機Ａ、Ｂ以外の計算機から編集情報がサーバーにアップされた結果である。図１１では、計算機A1102はもう一度同期1112を行い複製DBのバージョンが１になっている。

さて、計算機Aは複製DB1105内のレコードＸの複製1108を編集1113したとする。この時、複製DBのベースバージョンが1なので、レコードＸの複製1108のレコードバージョンを１にする。この編集結果のレコードと複製DB1105のベースバージョンがサーバーにアップされ1114、サーバーで有効と判定されると原本DB1104が更新され、原本DBのバージョンが７に変わる。レコードＸの原本も計算機Aが編集した内容に更新1115される。サーバーからの「編集が有効になったとの確認」1116を計算機Ａが受けた後に同期1116を行い、計算機Ａの複製ＤＢのベースバージョンも７になる。

プログラムがレコードを処理する時にその参照先の参照先変更情報も確認し、参照先変更情報があれば参照先を変更する。この参照先の変更でもレコードの内容の一部が修正されるのでレコードバージョンはそのときのベースバージョンに設定される。つまり（レコードに記録された）レコードバージョンより前のバージョンで指定された参照先変更情報の確認は、このレコードでは完了している。新たに参照先変更情報による参照の変更を行う場合、記録されていたレコードバージョンより後に設定された参照先変更情報を古い方から順番に適用する。これにより参照先の変更が矛盾なく行われる。

一方、計算機Ｂは原本ＤＢ1104のバージョン６の時点で同期1117を行い、複製DB1106のバージョンが６になる。この後でレコードＸ（の複製）1109を編集1118する。この時、レコードバージョンが６になり、サーバーにアップされる1119。そして、サーバーの検査で、計算機Bが編集の直前に行った同期1117の後に、計算機Aによる（レコードＸに対する）修正がアップされているので、レコードＸに対する編集の衝突が検出される。

計算機Aの修正アップのベースバージョンは１（レコードＸの原本のレコードバージョンが１）で、計算機Ｂの修正アップのベースバージョンは６（計算機Ｂで修正されたレコードＸの複製のレコードバージョンが６）であるので、計算機Bの修正が採用され、レコードＸの原本は計算機Ｂが修正した内容に更新1119される。この時、原本DBのバージョンが８に変わる。サーバーからの「修正が有効になったとの確認」1121を計算機Bが受けて同期を行い、計算機Ｂの複製ＤＢのベースバージョンも８になる。

その後、計算機Aが原本ＤＢと同期をとったとする1120。この時点で、先に計算機Ｂが編集して有効になったレコードＸの内容が端末Ａの複製ＤＢに伝わる。つまり、先に計算機Ａが行った修正が、計算機A の複製ＤＢで（この時点で）無効になる。なお、以前の編集が無効になった事を操作者に伝えるには、別途そのための仕掛けが必要である。

ＤＢの編集処理が高速になるだけではなく、ＤＢの平行編集、つまり原本ＤＢを複数の計算機で複製（コピー）し、複数の計算機で平行して複製DBを編集し、その結果を原本ＤＢに反映する運用が可能となった。これは、サーバーとの接続が不可能な状況でも処理の継続が可能である事を意味し、移動体によるＤＢアクセスやミッションクリティカルな業務へ適用出来る。また常に通信網との接続する手間や費用を省きたい要求にも答えられる。また、オンライン運用に近い運用かオフライン運用に近い運用かを、計算機毎にそれぞれの処理内容に応じて選択できて、さらには、オンラインに近い運用の計算機や、オフラインに近い運用の計算機がサーバーを介して一緒に運用できるので、ＤＢ運用に大きな自由度を与える。

Claims

他のレコードから参照される可能性のあるレコードを含むデータベースを操作する方法であって、レコードに対して記録された情報に基づき該レコードへの参照を別のレコードへの参照に変更する工程、を特徴とするデータベース操作方法。
他のレコードから参照される可能性のあるレコードを含むデータベースを操作する方法であって、削除マークの付いたレコードに対する参照を検出したら、削除マークを消去する工程、を特徴とするデータベース操作方法。
他のレコードから参照される可能性のあるレコードを含むデータベースを操作する方法であって、該レコードへの参照を別のレコードへの参照に付け替える情報を、このレコードに対して設定する工程、を特徴とするデータベース操作方法。
原本データベースの全体または一部の複製に対して変更を加え、この変更を原本データベースに反映するデータベース管理方法であって、複数の「複製に対する編集内容と、この複製が作成された時の原本データベースのバージョンの組み合わせ」の中で、より新しいバージョンに対する編集内容を有効とし、原本データベースに反映する工程、を特徴とするデータベース操作方法。
請求項４のデータベース操作方法であって、（１）他のレコードから参照される可能性のあるレコードに、該レコードへの参照を別のレコードへの参照に付け替える情報を設定する編集を行い、（２）複数の「複製に対する編集内容と、この複製が作成された時の原本データベースのバージョンの組み合わせ」の中で、より新しいバージョンに対する編集内容を有効とすると言う基準で、該編集が有効とされた事を確認し、その後に（３）該レコードに対して記録された情報に基づき該レコードへの参照を別のレコードへの参照に変更する工程、を特徴とするデータベース操作方法。