(57)【特許請求の範囲】
【請求項１】
データベースの複製（以下「複製データベース」）の編集方法であって、
（１）該複製データベースに対してバージョン（該複製データベースの更新に伴い更新される順序数）が記録され、
（２）該複製データベースの作業用コピーを対象とした編集の記録（以下「編集記録」）に対して、該作業用コピーを作成した時点の該複製データベースの該バージョンの値（以下「編集バージョン」）が記録され、
（３）該複製データベースを更新する複数の編集記録には、該データベースの他の複製に対する編集記録が含まれ、
さらに
（工程Ａ）既に該複製データベースの更新に用いられていた編集記録に対し記録されていた編集バージョンの値と、新たな編集記録（以下「新編集記録」）に対して記録されている編集バージョンの値（以下「新バージョン」）を比較し、
（工程Ｂ）該「新バージョン」の方が新しい場合に、該「新編集記録」を用いて該複製データベースを更新し、該複製データベースに対して記録されていた該バージョンを更新し、
（工程Ｃ）該「新バージョン」の方が古い場合には、該「新編集記録」を用いた該複製データベースの更新は行わない、
一連の工程を特徴とする方法。
【請求項２】
データベースの複製（以下「複製データベース」）の編集方法であって、
（１）該複製データベースに対してバージョン（該複製データベースの更新に伴い更新される順序数）が記録され、
（２）該複製データベースの作業用コピーを対象とした編集の記録（以下「編集記録」）に対して、該作業用コピーを作成した時点の該複製データベースの該バージョンの値（以下「編集バージョン」）が記録され、
（３）該複製データベースを更新する複数の編集記録には、該データベースの他の複製に対する編集記録が含まれ、
さらに
（工程Ａ）該複製データベースの更新に用いる編集記録（以下「新編集記録」）に対して指定されていた情報の範囲（以下「不変確認範囲」）に対し、それまでに適用された編集記録に対して記録されていた編集バージョンの値と、該新編集記録に対して記録されていた編集バージョンの値（以下「新バージョン」）を比較し、
（工程Ｂ）該「新バージョン」の方が新しい場合に、該「新編集記録」を用いて該複製データベースを更新し、該複製データベースに対して記録されていた該バージョンを更新し、
（工程Ｃ）該「新バージョン」の方が古い場合には、該「新編集記録」を用いた該複製データベースの更新は行わない、
一連の工程を特徴とする方法。
【請求項３】
データベースの複製（以下「複製データベース」）の編集方法であって、
（１）該複製データベースの一部分の情報（以下「バージョン設定範囲」）に対してバージョン（該バージョン設定範囲の内容の更新に伴い更新される順序数）が記録され、
（２）該複製データベースの作業用コピーを対象とした編集の記録（以下「編集記録」）に対して、該作業用コピーを作成した時点の該バージョン設定範囲の該バージョンの値（以下「編集バージョン」）が記録され、
（３）該複製データベースを更新する複数の編集記録には、該データベースの他の複製に対する編集記録が含まれ、
さらに
（工程Ａ）既に該複製データベースの更新に用いられていた編集記録に対し記録されていた編集バージョンの値と、新たな編集記録（以下「新編集記録」）に対して記録されている編集バージョンの値（以下「新バージョン」）を比較し、
（工程Ｂ）該「新バージョン」の方が新しい場合に、該「新編集記録」を用いて該複製データベースを更新し、該「バージョン設定範囲」の内容が変更された場合には、該「バージョン設定範囲」に対して記録されていた該バージョンを更新し、
（工程Ｃ）該「新バージョン」の方が古い場合には、該「新編集記録」を用いた該複製データベースの更新は行わない、
一連の工程を特徴とする方法。
【請求項４】
データベースの複製（以下「複製データベース」）の編集方法であって、
（１）該複製データベースに対してバージョン（該複製データベースの更新に伴い更新される時刻情報）が記録され、
（２）該複製データベースの作業用コピーを対象とした編集の記録（以下「編集記録」）に対して、該作業用コピーを作成した時点の該複製データベースの該バージョンの値（以下「編集バージョン」）が記録され、
（３）該編集記録を、編集記録を中継する装置（以下「サーバー」）へ送信し、
（４）未受信の編集記録を該サーバーより受信し、これら未受信の編集記録の有無を該サーバーに確認した時刻をサーバーから受信し、該データベースの該バージョンの値とし、
さらに
（工程Ａ）既に該複製データベースの更新に用いられていた編集記録に対し記録されていた編集バージョンの値と、新たな編集記録（以下「新編集記録」）に対して記録されている編集バージョンの値（以下「新バージョン」）を比較し、
（工程Ｂ）該「新バージョン」の方が新しい場合には、該「新編集記録」を用いて該複製データベースを更新し、該「新バージョン」を該複製データベースの該バージョンの値として設定し、
（工程Ｃ）該「新バージョン」の方が古い場合には、該「新編集記録」を用いた該複製データベースの更新は行わない、
一連の工程を特徴とする方法。
【請求項５】
データベースの複製（以下「複製データベース」）の編集方法であって、
（１）該複製データベースの全体または一部分に対してバージョン（該複製データベースの更新に伴い更新される順序数）が記録され、
（２）該複製データベースの作業用コピーを対象とした編集の記録（以下「編集記録」）に対して、該作業用コピーを作成した時点の該複製データベースの該バージョンの値（以下「編集バージョン」）が記録され、
（３）該複製データベースを更新する複数の編集記録には、該データベースの他の複製に対する編集記録が含まれ、
さらに
（工程Ａ）既に該複製データベースの更新に用いられていた編集記録に対し記録されていた編集バージョンの値と、新たな編集記録（以下「新編集記録」）に対して記録されている編集バージョンの値（以下「新バージョン」）を比較し、
（工程Ｂ）該「新バージョン」の方が新しい場合に、該「新編集記録」を用いて該複製データベースを更新し、該複製データベースに対して記録されていた該バージョンの値を更新する、
一連の工程を特徴とする方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はデータベース（以下「ＤＢ」）の、複数の複製に対して、並行して編集（以下「並行ＤＢ編集」）が行われた場合に発生する、編集の競合を解決するものである。
【背景技術】
【０００２】
一般的にはサーバー計算機（以下「サーバー」）にデータベースが置かれ、複数の端末計算機（以下「ＰＣ」）がアクセスする運用が行われている。アクセスの競合を防ぐため、ベシミステックロックカーソル（非特許文献１）やトランザクションのロック（非特許文献２）が用いられている。【０００３】
MVCC（非特許文献３）も編集ロック（非特許文献４、非特許文献５）を用い、OODB製品のCache（非特許文献６）とObjectStore（非特許文献７）も編集ロックを用いている。リレーショナルＤＢ（RDB）のPostgreSQLでは「同時に起こりうる更新を避けるためには適切なLOCK TABLE 文を使用する」（非特許文献５）とあり、これも編集ロックである。特許文献１も編集ロックである。【０００４】
作業用の複製を作成して処理を行うキャシュの技術で、処理や通信の効率化を図る試みも行われている。マイクロソフトのADO.NETは、ＰＣに当面の作業に必要なデータをサーバーからコピーし、サーバーとの接続を切断してから編集作業を行う。編集後に改めてサーバーと接続し編集内容をサーバーに送る。もし編集対象の情報が既に他のＰＣから変更されていれば、後からの（この）編集を無効にする。これは「オプティミスティック同時実行制御」（非特許文献８および非特許文献９）と呼ばれている。「ロックが結果として失敗した場合にはその編集を無効とする」と考えれば、編集ロックの一種とも言える。本願では、他の方法との比較のため、この方法を「先着優先」と呼ぶ。この「先着優先」では、時として以下に示す不都合が生じる事がある。【０００５】
（１）最新情報を基にした編集が無効となるケースが存在する。最新情報を基にした編集はその時点での最善の判断の可能性が高いので、これが無効になると実際の運用においては問題となる。【０００６】
例えば、ＰＣ−Ｘの操作者は朝９時に必要なデータをサーバーからコピーし、「この顧客は冷やかしなので、親切な対応は不要」と書き込みその後しばらく放置したとする。一方ＰＣ−Ｙの操作者は、お昼の１２時に「この顧客から高額な取引の提案有り」との情報を得て、「契約に向け、最大限の接待を行う」と書き込み、サーバーにアップしたとする。しかし、その１分前にＰＣ−Ｘからの編集がアップされると、ＰＣ−Ｙの編集のアップは後からなので無効となる。最新情報を元にしたＰＣ−Ｙの編集が、ＰＣ−Ｘの操作者の気まぐれな操作で妨害されている。【０００７】
（２）編集毎にコピーを作成（非特許文献１のp19）するので、そのコピー作成の処理と通信がオーバーヘッドとなる。このオーバーヘッドを少なくするには、コピーの範囲を制限する必要があるが、これにはアプリケーションが対象とする情報の構造を熟知している必要がある。これはキャシュに基づく方法に共通する問題である。【０００８】
特許文献２でも、指定した範囲のレコードが更新されていると後からの更新を無効としている。具体的には、引用発明の頁（６）の下部に「他の処理によって当該レコードを更新されている事が判明すると・・・更新は拒否され」とある。これは「先着優先」であり、ＡＤＯ.ＮＥＴと同じ問題を抱えている。【０００９】
特許文献３では、複製ＤＢでの編集時刻を基に、競合する編集のバージョンを、「時刻の早い順からバージョンをふり直す（ステップＳ６０４）」（特許文献３の段落００６５、段落００７９）、そして「日時が最も古いコンテンツ情報を最新のバージョンに更新する」（段落００９７）としている。つまり、先に編集した方を優先としている。本願では、他の方法との比較のため、この方法を「先編集優先」  と呼ぶ。【００１０】
「先編集優先」でも問題が生じる場合がある。例えば、ある時点（例えば１年前）の編集結果があるＰＣの中に存在しており、ある日突然サーバーにアップされて有効になると、他のＰＣによって過去１年間に編集されアップされていた編集内容が全て無効になってしまう。この様な運用は通常は許されないと思われる。なお、特許文献４も更新時刻が先の更新を有効としており、同じ問題を抱えている。【００１１】
特許文献５では更新時刻が後の更新を有効としている。本願では、他の方法との比較のため、この方法を「無条件上書き」と呼ぶ。この文献ではＰＣでの修正がほぼリアルタイムに他のＰＣに伝わる運用を前提としているので、後からの編集はそれまでの編集状況を全て把握した上での修正と推定される。この条件ならば「無条件上書き」でも問題は無いと思われる。【００１２】
しかし本願の様に、複数のＰＣが並行して、それぞれが保持する複製ＤＢの内容を変更するケースでは、他のＰＣでの編集状況が即時には伝わらない。この状況、単に更新時刻が後であれば常に上書きする「無条件上書き」を適用するならば、ＰＣの操作者には直接は理解出来ない理由で編集の有効性が決定される事になる。編集の時刻を決定するＰＣ毎の時計がずれる事も、意図的にずらされる可能性も考える必要がある。「無条件上書き」を並行編集に適用するには、検討を要する多くの問題がある。【００１３】
その他の調査結果を以下に示す。特許文献６はデータベースの同期を起動する条件に関する発明であり、同期の方法については「更新情報を互いに通知し合って同期」と言う一般的な同期の概念を示しているにすぎない。平行して作成された更新（本願では「編集記録」）を互いに通知するだけでは、様々な理由（エラー再送などによる遅れ、送信タイミングのずれ等）により、ＤＢに適用する順番がＰＣ毎に異なる可能性があり、それぞれの複製ＤＢの内容が異なるという重大な問題が予想される。しかし、これについての対策は示されていない。【００１４】
特許文献７は、編集の競合が起きた際に「全ての更新データを保持する」ことを目的とした発明である。競合が無いときにのみ原本を更新するのであり、本発明とは目的も内容も異なる。【００１５】
非特許文献１０は、ファイルのキャシュに関する発明で、編集の衝突（本願での競合）を検出した場合は単純に編集を拒否する（非特許文献１０の７頁の右下から１０行目）のみであり、本願の様に衝突した編集のうちどれを有効にするかの判定は行わない。【００１６】
特許文献８、特許文献９、特許文献１０、特特許文献１１、特許文献１２についても調査したが、いずれも本願の目的である、並行ＤＢ編集による矛盾の解決には適用出来ない。
【特許文献１】特開平１１−２７２５３４号公報
【特許文献２】特開昭６１−１３４８５３号公報
【特許文献３】特開２００５−２１６１６７号公報
【特許文献４】特開平９−９１１８４号広報
【特許文献５】特開２００４−１３８６７号広報
【特許文献６】特開２００４−８６８００号広報
【特許文献７】特開２００６−２８４９９８号広報
【特許文献８】特開平１１−１６１５３５号公報
【特許文献９】特表２００５−５０３６０６号公報
【特許文献１０】特表２００５−５０８０５０号公報
【特許文献１１】特開平８−１６４４７号公報
【特許文献１２】特表２０００−５０１５３２号公報
【非特許文献１】William R. Vaughn, 株トップスタジオ訳、伊藤由紀子監修、Windows（登録商標）データベースプログラミング ADO.NET専修講座 VB.NET 編、2003年８月４日初版発行、翔泳社
【非特許文献２】超図解ＳＱＬハンドブック、Ｃ＆Ｒ研究所、２００５年８月１２日初版発行
【非特許文献３】「主な機能とメリット」、[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）
【非特許文献８】「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）
【非特許文献１０】「世界規模分散ファイルシステムSKINNY 」、情報処理学会研究報告, 95-OS-70, (学術刊行物  情処研報 Vol. 95, No.79 ISSN 0919-6072
【発明の開示】
【発明が解決しようとする課題】
【００１７】
本願の目的は、ＤＢ複製が複数のＰＣに有り、これらに対して並行して並行ＤＢ編集が行われた場合に発生する、「編集の競合」を解決する事にある。キャシュ技術の延長である「先着優先」、「先編集優先」、「無条件上書き方式」を検討したが、これらには様々な問題があった。各ＰＣが保持する複製ＤＢは、キャシュとしての一時的な複製として位置付けられ、多少の問題は無視する割り切りと推定される。本願では、各ＰＣが永続的に複製ＤＢを保持する、いわば本格的な「並行ＤＢ編集」を提案するとともに、これに適した、編集の競合の解決方法を明らかにする。また、キャシュ技術への適用も検討する。
【課題を解決するための手段】
【００１８】
本発明では、並行ＤＢ編集における編集の衝突を「より最新の情報に基づく編集を優先」する方針で解決する。そして本格的な並行ＤＢ編集に用いたケースや、キャシュ技術への適用を説明する。以下では一つの適用例に基づいて説明する。【００１９】
（１）準備
複数のＰＣに、原本ＤＢ（以下「グローバル原本ＤＢ」）の初期状態の複製ＤＢ（以下「ローカル原本ＤＢ」）を置く。このローカル原本ＤＢには初期のバージョン、つまり更新の順番を識別する順序数、が設定されている。【００２０】
この順序数の簡単な実現例は整数で、初期値として「０」を設定するのが自然である。本願ではこのバージョンを用いて衝突の解決が行う。各ＰＣはそれぞれの（多分操作者の）都合の良い時に複製ＤＢの更新を行い、バージョンを更新する。この詳細を以下で説明する。【００２１】
（２）ローカル編集
各ＰＣはそれが保持するローカル原本ＤＢに対するローカルな編集を行う。この編集の前にローカル原本ＤＢの作業用の複製を作成し、編集はこの複製に対して行う。また、編集時にはその「編集記録」を作成する。この編集記録には「編集内容」「編集バージョン」「不変確認範囲」などが記録される。【００２２】
「編集内容」はどの情報をどの様に変更したか、どの情報を追加したか、どの情報を削除したか、などの一般的な編集内容である。「編集バージョン」は編集対象のローカル原本ＤＢのバージョン、厳密に言えば、編集対象の作業ＤＢの複製元となったローカル原本ＤＢのバージョン、である。【００２３】
「不変確認範囲」はこの編集が前提とする情報の範囲である。もしこの編集が確定する前にこの範囲の情報の変更されてしまえば、この編集は無意味になる事を示している。「不変確認範囲」はＤＢが扱う情報、特にその編集する対象の情報の特性に応じて様々な指定が可能である。一般的な運用では、編集対象の情報は「不変確認範囲」にはいると思われるが、必ず入れる必要は無い。リレーショナルＤＢ（以下「ＲＤＢ」）の場合には、編集対象のテーブル、編集対象と論理的に関連しているテーブル群、そのなかの一部のレコード、またはＤＢ全体などが考えられる。【００２４】
情報の性質に応じて適切な不変確認範囲が設定する事により、ＤＢの使い勝手が良くなる。「不変確認範囲」が小さければ多くの並行編集が問題なく行えるので、必要不可欠な最小限の情報（の組み合わせ）を不変範囲として設定するのが良い。【００２５】
（３）サーバーへの編集記録の送信
各ＰＣは「編集記録」をサーバーに送信する。「編集記録」と「編集バージョン」および「不変確認範囲」を分けて記録している場合には、「編集記録」との対応を明示して「編集バージョン」および「不変確認範囲」も送信する。なお、「編集記録」の中に「編集バージョン」と「不変確認範囲」も、さらには後で説明する「バージョン設定範囲」も、記録しておくと、通信手順が簡単になる。【００２６】
（４）サーバーによる編集記録の受信
サーバーは、ＰＣから到着した編集記録を、その到着の順番と共に記録しておく。【００２７】
（５）サーバーからの編集記録の受信
ＰＣはサーバーに対して、未受信の編集記録の送信を要求し、これらの編集記録、と対応する編集バージョン、必要なら不変確認範囲やバージョン設定範囲を受信する。同時に編集記録のサーバーへの到着の順番を受信する。サーバーがＰＣから到着した編集記録にその到着の順番を記録すると、通信手順が簡単になる。【００２８】
（６）ローカル原本ＤＢの更新
ＰＣは指定された順番でサーバーから受信した編集記録を取り出し、編集記録の有効性を判定する。この判定手順の詳細は後の「有効性の判定手順」で説明する。そしてローカル原本ＤＢを更新してそのバージョンを更新する。バージョンが整数なら初期値の「０」から順番に１個ずつ上げていくのが自然である。なお、ＰＣは指定された編集記録を全て最後まで処理する（途中で新たな編集作業は入れない）。従って、サーバーから受信した最後の編集記録まで一気にローカル原本ＤＢを更新しその後での後で（処理した編集記録の数だけ）バージョンを更新しても良い。【００２９】
＜  バージョンと言う時間での同期  ＞
全てのＰＣは、各ＰＣにおけるローカルな編集の編集記録を、サーバーへの到着順で取り出し、ローカル原本ＤＢを更新しそのバージョンを更新する。同じ情報を同じ順番で用いて、同じロジックで処理するので、結果として得られる各ＰＣのローカル原本ＤＢとそのバージョンは同期する。グローバル原本ＤＢを更新しなくても、グローバル原本ＤＢが存在しなくても、各ＰＣのローカル原本ＤＢが同期するのはこの仕掛けによる。【００３０】
各ＰＣはそれぞれの都合の良い時に、それぞれのローカル原本ＤＢの更新を行うので、実時間で見ると、各ＰＣのローカル原本ＤＢのバージョンの進み方は様々である。しかし、バージョンが更新される順番は同じであり、同じバージョンならローカル原本ＤＢの内容は同じである。つまり、バージョンが、並行ＤＢアクセスにおける各ＰＣに共通の時間に相当する。つまり本発明ではバージョンと言う時間で各ＰＣのローカル原本ＤＢが同期する。【００３１】
ＤＢ全体に対してひとつのバージョンを設定する場合の説明は以上であるが、後で説明する、情報のグループを「バージョン設定範囲」として設定する場合は、その範囲の情報が更新（追加、変更、削除）された時に、その範囲のバージョンを更新し、それぞれの範囲に対してバージョンを記録する。【００３２】
＜  有効性の判定手順  ＞
「編集記録の有効性の判定」が本発明の重要な部分である。編集記録（Ｙ）により「ローカル原本ＤＢ」の更新を試みる場合には、まず、Ｙに指定された「不変確認範囲」の情報を更新した過去の編集記録を調査し、これらの全てに対してＹが有効と判定された時に、Ｙを有効と判定する。ここで説明のため、Ｙに指定された「不変確認範囲」の情報を更新した過去の編集記録のひとつをＸとし、以下の記号を用いる。
ｙ：Ｙの編集バージョン＝Ｙの編集対象であった「ローカル原本ＤＢ」のバージョン。
ｘ：Ｘの編集バージョン＝Ｘの編集対象であった「ローカル原本ＤＢ」のバージョン。
ｎｘ：Ｘに基づく更新により設定された原本のバージョン。当然「ｘ＜ｎｘ」。【００３３】
ＹがＸに対して無効である条件は、以下二つのどれかを満たした場合である。なお、少なくとも一つのＸに対して無効であれば、Ｙは無効と判定され、Ｙによるローカル原本ＤＢの更新は実行されない。【００３４】
（Ｙが無効となる条件１）ＸがＹの「不変確認範囲」の情報を更新しており、かつ「ｙ＜ｘ」。つまり、Ｙの編集バージョンがＸより古いので、Ｙを無効と判定する。【００３５】
（Ｙが無効となる条件２）ＸがＹの「不変確認範囲」の情報を更新しており、かつ「ｙ＝ｘ」。つまり、編集バージョンが一致した場合は、先着のＸを有効としＹを無効と判定する。【００３６】
従来の「先着優先」や「先編集優先」の方法では、古い情報に基づく編集が最新の情報に基づく編集よりも優先される問題があったが、本発明では以上の２条件でこれらの問題を排除している。【００３７】
逆に、ＹがＸに対して有効である条件は以下２つのどれかを満たした場合である。なお、全てのＸに対して有効な場合にＹが有効となり、Ｙによるローカル原本ＤＢの更新は実行される。【００３８】
（Ｙが有効となる条件１）ＸがＹの「不変確認範囲」の情報を更新していない場合は、この条件だけでＹはＸに対して有効。【００３９】
（Ｙが有効となる条件２）ＸがＹの「不変確認範囲」の情報を更新しており、かつ「ｘ＜ｙ」の場合、ＹはＸに対して有効となる。【００４０】
全てのＸに対して有効な場合にＹが有効となり、Ｙによりローカル原本ＤＢを更新する。編集バージョンが新しい編集を優先する原則を厳密に適用する場合には、ｙとｎｘの関係によりその更新手順が分かれる。【００４１】
「（ｘ＜）ｎｘ＜=ｙ」の場合：Ｙの編集対象のローカル原本ＤＢにはＸの変更が含まれている。従って、Ｘによる更新を生かしたままＹによる更新を実行する。【００４２】
「（ｘ＜）ｙ＜ｎｘ」の場合：Ｘの変更が含まれていないローカル原本ＤＢに対してＹが行われでいる。従って「より最新の情報に基づく編集を優先」する思想を厳密に適用するならば、Ｘによる更新を取り消した後にＹによる更新を実行する。なお、「（ｘ＜）ｙ＜ｎｘ」の条件を、Ｘの「編集の取り消し条件」と呼ぶ。【００４３】
実は、上記の（Ｙが有効となる条件２）でＹが有効となった場合に、上記「（ｘ＜）ｙ＜ｎｘ」の条件の確認を行わず、直ちに、Ｘによる更新を生かしたままＹによる上書き更新を実行する方法が実用的である。当然、「編集バージョンが新しい編集を優先する」原則に外れる場合が生じる可能性があるが、一度適用された更新が取り消される事は無いのは運用上都合が良い。有効性の判定手順が単純明快で並行ＤＢアクセスの関係者にとってデータベースの動作に対する理解が容易であるし、システムの開発も容易になる。なお「更新の取り消しが有る運用」の詳細については後で説明する。【００４４】
＜一般的な動作の流れ＞
あるＰＣに注目した一連の動作例を以下で説明する。このＰＣがサーバーから最新の編集記録を受信し、ローカル原本ＤＢを更新したとする。その後、他のＰＣから編集記録がサーバーにアップされた後に、このＰＣがローカル原本ＤＢに対する編集を行ったとする。これを編集記録Ｙとしてサーバーにアップし、次にそれまでの（未受信の）編集記録をサーバーから受信し、編集記録を指定された順番で取り出し、ローカル原本ＤＢの更新を試みる。この過程でいくつかの編集（例えば編集Ｘ）は有効と判定されローカル原本ＤＢが更新される。【００４５】
最後に先程アップした編集記録Ｙが取り出され、その不変確認範囲を調査し、編集Ｘなどとの関係を「有効性の判定手順」で評価する。一つのＸに介して無効ならＹは無効と判定される。このＰＣの操作者は、無効となった事実とその理由を確認し、必要が有れば（最新の情報に対して）再度の編集を試みる。無効になった元の入力の記録があれば、その内容を再び入力するのは容易である。有効なら編集記録Ｙでローカル原本ＤＢを更新する。【００４６】
＜ほぼオンライン運用とほぼオフライン運用＞
ＰＣの操作者は「古い情報に基づく編集は無効と判定される可能性が高い」事を理解していれば良い。編集を行うＰＣが、その編集が無効と判定される可能性を出来るだけ少なくするには、編集の直前に最新の編集記録まで受信してローカル原本ＤＢを更新し、この最新のローカル原本ＤＢに対して編集を行い、編集後は速やかに編集記録をアップすると良い。頻繁に更新を行えば、ローカル原本ＤＢは常に最新の状態に保たれるので、「ほぼオンライン運用」と言う事が出来る。【００４７】
しかし、編集の競合が稀な情報を扱う場合には、ローカル原本ＤＢの更新から編集のアップまでの時間を長くしても編集が無効となる可能性は小さい。例えば、会社の組織ごとに支払伝票を入力するケースでは、レコードを修正するのは入力ミスや処理ミスを発見した場合であり、修正するとしてもレコードを入力した計算機で行う事が多い。この様なケースでは、更新から編集アップまでの期間を極端に長くした「ほぼオフライン運用」でも問題は無い。たとえインターネット接続が出来ない状況でも支払伝票をゆっくり入力し、決算や検査の近くなってからまとめてアップすれば良い。【００４８】
＜＜  課題を解決するための手段の全容  ＞＞
発明の全容を実施例のバリエーションも含めて以下で説明する。【００４９】
（１）編集記録とその順番の操作
サーバーがＰＣに伝える編集記録とその順番は、必ずしもＰＣがアップした内容である必要も、アップの順番を守る必要も無い。編集記録とその順番が全てのＰＣで同じであれば、これらのローカル原本ＤＢは同期する。【００５０】
サーバー又は管理業務を担当するＰＣが編集記録の内容を分析し、エラーとなって無効とされる部分や、冗長（結局は何もしないのと同じ）な部分を削除しても良い。エラーの編集記録や冗長な編集記録を削除して、編集記録の順番を詰めても問題は無い。操作者の優先順位などを考慮して意図的に編集記録の順番を変更したとしても、ローカル原本ＤＢは同期する。【００５１】
（２）サーバーによるグローバル原本ＤＢの更新
先の例では、サーバーから受け取った一連の編集を用いて「ローカル原本ＤＢ」を更新している。「ローカル原本ＤＢ」の初期値が同じ、それに適用する編集記録の順番とその内容が同じ、かつ同じロジックで「ローカル原本ＤＢ」の更新を行う事により、同じ編集記録まで受信したＰＣの「ローカル原本ＤＢ」の内容は一致する。「グローバル原本ＤＢ」は存在しないが、各ＰＣの「ローカル原本ＤＢ」は同期している。仮想のグローバル原本ＤＢと同期していると言える。【００５２】
グローバル原本ＤＢを実際にサーバーに置き、サーバーがこのグローバル原本ＤＢを更新する運用も可能である。その要点は以下である。
（a）グローバル原本ＤＢがサーバーに有り、各ＰＣはその複製であるローカル原本ＤＢを持っている。
（b）各ＰＣはそのローカル原本ＤＢに対して編集を行う際には、編集記録を作成しサーバーに送る。
（c）サーバーは、ＰＣからの編集記録の到着順に、編集の競合を確認し、有効と判定された編集でグローバル原本ＤＢを更新し、そのバージョンを更新する。
（d）サーバーからの情報で、各ＰＣはそれぞれのローカル原本ＤＢとバージョンを更新、つまり同期、する。【００５３】
原本ＤＢをサーバーに置くと処理の説明は簡単だが、実際の処理は逆に複雑になる。ひとつは、処理過程をＰＣに通知するのが困難、つまり、どの編集が無効と判定され、それがどの様にして無効と判定されたかを、その編集を行ったＰＣの操作者に伝えるのが困難な事である。先の「ローカル原本ＤＢ」を各ＰＣが更新する方法ならば、各ＰＣの内部で全ての編集の有効または無効の状況が把握出来るが、サーバーが原本ＤＢを更新する場合は、その状況を詳しく各ＰＣに伝えるには複雑な処理が必要である。【００５４】
サーバーがグローバル原本ＤＢを更新する運用なら「サーバーの処理プログラムの更新で更新処理のアップグレード出来る」長所があるが、以上の処理の複雑さとのバランスを考え、扱うデータの特性や利用者の便宜などを考え、適切な運用を選択する事になる。【００５５】
（２．１）ＰＣへの通知
グローバル原本ＤＢを更新する場合は、最新のグローバル原本ＤＢと各ローカル原本ＤＢを同期する必要がある。グローバル原本ＤＢのデータ量が多いと考えるのが常識的であり、その全体を送るのは非現実的である。編集記録（とその順番）を各ＰＣに送れば、各ＰＣでローカル原本ＤＢを更新するのと同じであり、グローバル原本ＤＢをサーバーが更新するメリットは小さい。結局、グローバル原本ＤＢ更新の差分情報を送るのが現実的である。【００５６】
（２．２）キャシュへの適用
キャシュ技術を用いて「各ＰＣにおける編集の前に、サーバーからグローバル原本ＤＢの必要な部分のコピーを作成し、このコピーに対して編集を行う」方法に対しても、本願の「より最新の情報に基づく編集を優先」する方法が適用出来る。編集に必要なコピーを作成するときに、グローバル原本ＤＢのバージョンも取得する。編集記録にはこのバージョンを編集バージョンとして設定しサーバーに送る。サーバーはこの編集バージョンを元に有効性を判定する。これにより、ＡＤＯ．ＮＥＴで見られたような、古いバージョンに対する編集の突然のアップによって最新のバージョンに対する編集が妨害されるケースは排除される。【００５７】
（３）サーバー機能の配置
先に説明した、各ＰＣが「ローカル原本ＤＢ」を更新する方法では、編集記録をサーバーに集めた。サーバーがグローバル原本ＤＢを更新する方法も説明した。どちらのサーバーも必要な機能が提供できるなら専用サーバーでもレンタルサーバーでも良い。本明細書でのＰＣのひとつが、同時に本明細書のサーバーの機能を提供しても何ら問題は無い。【００５８】
（４）バージョン設定範囲の導入
バージョンを付与し編集を管理する単位が実際のＤＢである必要は無い。情報修正の影響が密接に関係している部分を「バージョン設定範囲」とし、これ毎にバージョンを設定すれば、その範囲に関する編集とバージョンの推移が管理できる。【００５９】
最適なバージョン設定範囲の設定は、扱う情報の構造や内容に依存する。ＲＤＢの場合にはレコード、テーブル、テーブルと論理的に関連しているテーブル群、そのなかの特定のレコード群、又はＤＢ全体などが想定される。【００６０】
以上で説明した手順は、ＤＢをバージョン設定範囲と読み替える事により、適用出来る。なお、複数のバージョン設定範囲に対する編集がひとつの編集記録に記載されていても問題は無い。バージョン設定範囲毎に「編集内容」「編集バージョン」「不変確認範囲」などが記載されていれば良い。【００６１】
医療の個人情報を例に説明する。医療情報のＤＢで、個人の医療記録をバージョン設定範囲として設定する。テーブルの１行又は数行が個人の情報なら、これの固まりに対してバージョンを設定する。ＤＢには、多数の個人情報があり、それぞれにバージョンが設定される。編集記録には、個人毎の「編集内容」「編集バージョン」「不変確認範囲」のセットが単数または複数存在する。「不変確認範囲」はこの個人記録全体でも、修正した情報（ＲＤＢならレコード）でも、修正内容と目的に応じて適切に設定すれば良い。個人情報毎にテーブルを構成していれば、テーブル毎にバージョンが設定される。【００６２】
医療情報だけでなく、社会保証や銀行口座やローンなどの情報を個人毎に管理する事にも利用出来る。複数の部署で編集すると思われる犯罪者情報の管理にも使える。さらには、住民みずから一部のデータの編集が可能な「発展した形態の住民基本台帳の管理」など、個人対応の情報を扱う場合にも便利である。「（５）ローカル原本ＤＢの複製範囲」で説明する様に、ＰＣ毎にその権限で読み込める範囲の個人情報についてのローカル原本ＤＢを作成する事として、権限の範囲内の情報のみがこのＰＣに送られるなら、権限外の情報がハッキングされる恐れも無い。【００６３】
（４．１）  バージョン付与のタイミング
ＤＢ原本（グローバル原本ＤＢ又はローカル原本ＤＢ）全体、またはその中の「バージョン設定範囲」に対してバージョンが付与されるが、その付与方法は、扱う情報の特性や運用の都合に応じて選択する事が出来る。【００６４】
「有効とされた編集でバージョンを更新」する方法は、有効と判定された変更記録で、原本ＤＢまたはバージョン設定範囲が変更された時に、バージョンを更新する。次に有効な編集記録で更新されるまでは同じバージョンであり、この期間に同期されたローカル原本ＤＢのバージョンは同じである。【００６５】
有効な変更記録で原本ＤＢの内容が変更されなくても、バージョンを更新するのが「有効または無効に関わらず全ての編集記録でバージョンを更新」する方法である。無効な編集のアップの前後でバージョンが異なり、原本ＤＢの内容が同じでも後から同期されたローカル原本ＤＢのバージョンの方が進んでいる。【００６６】
（４．２）  編集のサーバー受け付け時刻への発展
サーバーが編集記録を受け付けた時刻をバージョンとして利用する方法も可能である。以上で説明したバージョンはこの受け付け時刻と読み替える事になる。バージョンは一連の順番を識別するための順序数と説明したが、時刻も順序を表すので何ら問題は無い。【００６７】
（４．３）  サーバーへの同期アクセス時刻への発展
ＰＣが、サーバーにアクセスし、未受信の編集記録の有無を確認した時刻をサーバーから取得し、その時刻を原本ＤＢのバージョンとする方法も可能である。ローカル原本ＤＢを更新する場合では、各ＰＣは（未受信の編集の有無、およびその有効性に関係なく）サーバーに問い合わせた時刻（例えばサーバーが通知した時刻）をローカル原本ＤＢのバージョンとする。【００６８】
サーバーがグローバル原本ＤＢを更新する場合は、あるＰＣからアクセスが有った時にその時刻を原本ＤＢのバージョンとし、（必要ならば）そのＰＣのローカル原本ＤＢとグローバル原本ＤＢと同期し、同時にバージョン（つまり直近のアクセス時刻）も同期する。同期アクセスがより新しいローカル原本ＤＢに対する編集が優先されるので、一つのＤＢを競争で操作する関係者にとって理解しやすくまた納得出来るルールである。【００６９】
（５）ローカル原本ＤＢの複製範囲
本願の説明を簡単にするには、ローカル原本ＤＢが（仮想の又は実在する）グローバル原本ＤＢの全体と同期すると都合が良い。しかし実際の利用を考えると、ローカル原本ＤＢはグローバル原本ＤＢ一部と同期する方が現実的である。例えば、先に説明した医療情報のＤＢは多数の個人情報を持っている。このうち、ＰＣ毎にその権限で読み込める範囲の個人情報についてのローカル原本ＤＢを作成すれば十分であり、ローカル原本ＤＢがグローバル原本ＤＢ全体と同期する必要は無い。医者の計算機には担当の（複数の）患者の情報を保持するローカル原本ＤＢが存在し、個人の計算機にはその人の個人情報のみを保持するローカル原本ＤＢが存在する。【００７０】
ローカル原本ＤＢがグローバル原本ＤＢの一部のみと同期している場合は、特定のＰＣにとってはサーバーに集められた編集記録の多くは必要無い。ＰＣで全ての編集記録を受信した後で、不要な編集記録をスキップするのがひとつの方法である。サーバー側でＰＣ毎に必要な編集記録を抜いて送ると通信量が削減されるし、権限外の情報へのハッキングも防げる。たとえ、不必要な編集記録が残っていてもＰＣ側の処理で除外すれば良い。編集情報に記録されたバージョン設定範囲を元にして、サーバーの管理する編集記録を分類しておくとＰＣに送るべき編集記録を迅速に判定する事が出来る。【００７１】
（６）  更新の取り消しが有る運用
先の説明では「更新の取り消しが無い運用」を扱っていたが、編集バージョンが新しい編集を優先する原則を厳密に適用すると、（Yが有効となる条件２）において、Yによる「ローカル原本ＤＢ」の更新の前に、Xによる更新を取り消す場合が有る。これは「（x＜）y＜nx」の「編集の取り消し条件」が成立した場合である。【００７２】
（６．１）更新の取り消しの分析その１
Yにより、過去の更新（上記X）が取り消されるのは、少なくとも以下の全ての条件を満たす必要が有る。なお、以下の（Xの更新の取り消し条件３と４）は上記の「編集の取り消し条件」に相当する。
（Xの更新の取り消し条件１）別の編集記録によっても、Yは無効とならない。
（Xの更新の取り消し条件２）Yの不変確認範囲をXが更新していた。
（Xの更新の取り消し条件３）「x＜y」。Yの編集バージョンがXの後。なお、これが成立しない場合はＹが無効であり、Ｘの取り消し要因とはならない。
（Xの更新の取り消し条件４）「y＜nx」。Xによるバージョンの更新が伝わる前に、Yの編集対象のローカル原本ＤＢの（yへの）更新が行われた。【００７３】
Xが取り消されるのは、この条件に加えてさらにYのサーバーへのアップのタイミングが関係する。もしYのアップがXのアップ（nx）よりも前なら、Xによる「ローカル原本ＤＢ」の更新の際に、Xは無効と判定され、取り消しには至らない。【００７４】
（Xの更新の取り消し条件１）により、Xを無効にする更新記録は限定される。つまり、編集バージョンが古く無効と判定された編集は、それまでの編集を取り消す要因にはならない。【００７５】
（Xの更新の取り消し条件２）は、不変確認範囲の指定が更新の取り消しの可能性を左右する事を示している。不変確認範囲を不用意に大きくしない事により、更新取り消しの可能性を小さくする事が出来る。【００７６】
（Xの更新の取り消し条件３と４）は、Xの編集期間、つまり「Xの編集対象のローカル原本ＤＢのバージョンが（xに）更新されてから、Xがサーバーにアップされる間」に、「ローカル原本ＤＢ」のバージョンが（yに）更新され、これがYの編集対象となったケースである。XのＰＣによる編集（X）のアップを迅速に行う事により、Ｘの取り消しの可能性を小さくできる。【００７７】
（６．２）  更新の取り消し防止方法
データベースの構造を変更するなど、更新の取り消しを防止したいケースがある。【００７８】
（更新の取り消し防止方法その１：アップ禁止）
Ｘの編集期間に他のＰＣからの編集がアップされなければ、この期間に他のＰＣがそのローカル原本ＤＢを更新（Ｙ）してもバージョンはｘになるだけで、ｘより後になる事は無い。つまり（Xの更新の取り消し条件３）が成立しない。Ｘのアップ（ｎｘ）の後のローカル原本ＤＢの更新（Ｙ）なら、（Xの更新の取り消し条件４）が成立しない。つまり、Ｘの編集期間に他のＰＣからアップを禁止すれば、Ｘが取り消しは防止出来る。【００７９】
（更新の取り消し防止方法その２：更新禁止）
Ｘの編集期間に他のＰＣからの編集がアップされても、他のＰＣがローカル原本ＤＢを更新するのを禁止すれば、Ｘの取り消しは防止出来る。サーバーから編集記録を送らないのもひとつの方法であり、編集記録を送ったとしてもその編集記録によるローカル原本ＤＢの更新（Ｙ）を禁止する方法でも良い。【００８０】
Ｘのアップ後は再び、どのＰＣもローカル原本ＤＢの更新試みる事が出来る。この時、サーバーから取り込まれる編集記録にはＸが含まれるので、取り込んだ編集記録の最後まで用いてローカル原本ＤＢを更新すれば、そのバージョンはｎｘ以降となる。ローカル原本ＤＢの更新が禁止れさていたＰＣでは、Ｘ到着後にこの禁止が解除され、Ｘまで用いてローカル原本ＤＢを更新しバージョンはｎｘ以降となる。従って、これらに対する編集記録のバージョンは nx＜yとなり、「編集の取り消し条件」は発生しない。【００８１】
「サーバーへの同期アクセス時刻」をバージョンとして用いる方法の場合は、ＰＣからの要求に対して、サーバーから「アクセスロック中」を返して、アクセス時刻の通知を行わない事で、同じ効果が得られる。【００８２】
（更新の取り消し防止方法その３：編集禁止）
Ｘの編集期間に他のＰＣからの編集がアップされ、他のＰＣがローカル原本ＤＢを更新しても、この更新したローカル原本ＤＢに対する編集を禁止すれば、Ｘの取り消しは防止出来る。サーバーから編集記録を送った時などに、その編集記録により更新したローカル原本ＤＢに対する編集の禁止を通知する。【００８３】
（６．３）更新の取り消しの分析その２
ある編集記録（上記のＸ）による更新が取り消しになった場合、この取り消しを完璧に行うには、以下の処理が必要になる。
（取り消から派生する処理１）Ｘにより無効とされた編集記録の有無を調査し、あれば有効か無効化の再評価を行う。
（取り消から派生する処理２）操作者がＸにより無効とされた編集記録を参照し再度入力した情報があるなら、その入力を見直す。
（取り消から派生する処理３）Ｘによる更新を前提とした編集、つまりＸによる更新で設定されたバージョン以降を編集バージョンとする編集記録の有効性を再評価する。【００８４】
上記（処理１）と（処理３）の一部を自動的に実行する事は可能である。しかし、（処理２）など、操作者の協力が必要な部分が有るので完全な自動実行は困難である。Ｘの取り消しの後、上記（処理１）（処理２）（処理３）の派生処理は実行せず、Ｘの取り消し事実を正確に操作者に伝え、その後は操作者の判断により再入力にゆだねるのが現実的である。無効になった事実、その対象と理由が明確に伝われば、操作者は合理的に対応する事が出来る。【００８５】
取り消しの派生処理を行わない事により、Ｘを無効とした判定が再度覆る事は無い。従って、これに対応して、操作者は再入力などの適切な操作を行う事が出来る。【００８６】
（７）  情報の追加と削除
情報が新規に作成されたときも、編集記録を作成し、その時点の対象ＤＢのバージョンを編集バージョンとして記録する。ＤＢの情報の削除においても「削除対象、削除の事実、影響範囲、バージョン」を編集記録とする。この編集（削除）は無効になる可能性があるので、この段階ではローカル原本ＤＢから実際に削除する事は出来ない。有効と判定された後ならば実際に削除する事も可能である。【００８７】
（７．１）  情報追加に関する補足
ＲＤＢにおいてレコードに主キー（ＩＤ）を設定するには、他のレコードとキーが重複してはならない。並行ＤＢアクセスではこのための配慮必要である。つまり、複数のＰＣが並行してレコードを追加する事により、同じ主キーのレコードが存在する事態を引き起こしてはならない。【００８８】
サーバーがグローバル原本ＤＢを更新する場合なら、各ＰＣが新規レコードに与えた主キーが衝突した場合は、重複が無い様に付け替えることで問題は解決する。ＰＣが手元の複製ＤＢを原本ＤＢと同期する事により、新しい主キーの情報が伝わる。【００８９】
グローバル原本ＤＢを置かず、各ＰＣがローカル原本ＤＢを更新する場合には、主キーの衝突を回避する方法がいくつか存在する。【００９０】
（主キー重複回避方法１）
あらかじめ、サーバーや管理ＰＣから各ＰＣに、新規に割り当て可能な主キーの範囲を有り当てておく事により、新規レコードの主キーの衝突を回避する事が出来る。主キーをＵＵＩＤにして、衝突を防止する方法も可能である。【００９１】
（主キー重複回避方法２）
次の主キーを記録しておくレコード（Ｋ）をＤＢ内に設定する。新規に作成するレコード（Ｚ）の主キーにこのＫの値を用い、その後Ｋの値を更新する。Ｋの更新が「より最新の情報を対象にした編集を優先する」ルールに照らして有効とされればレコードの追加は完了だが、無効と判断された場合はＫの値の更新が無効になり、レコード（Ｚ）の追加も無効として処理する。【００９２】
（主キー重複回避方法３）
編集記録による「ローカル原本ＤＢ」の更新時に、新規レコードの主キーの衝突を検出した場合、編集バージョンの新しい編集記録のものを採用する。これは、編集バージョンの確認により有効と判定されても、さらに内容チェックにより無効と判定されるケースが存在する事を意味する。情報の整合性を保証するためには、さらなる検討が必要である。【００９３】
＜＜出願時の請求項との対応＞＞
各ＰＣがそれぞれのローカル原本ＤＢを更新するケースとサーバーによるグローバル原本ＤＢを更新するケースでも原本ＤＢ（グローバル原本ＤＢまたはローカル原本ＤＢ）を更新する処理は共通である。これを請求項１に示す。グローバル原本ＤＢ、その複製ＤＢ、ローカル原本ＤＢ、作業ＤＢなどを包含する概念としてデータベースと言う言葉を用いている。これの方法「より最新の情報に基づく編集を優先」する方法であり、計算機が永続的に複製ＤＢを保持する本格的な「並行ＤＢ編集」のみならず、計算機が一時的に複製ＤＢを保持するケースでも有効である。【００９４】
データベースのバージョン更新処理を明記したのが請求項２である。バージョン設定範囲の概念を明記したのが請求項３である。ここでは単に「指定された情報の範囲」としているが、あらかじめシステムで事前に指定されている場合や、編集記録に指定されている場合など、様々な指定方法を想定しており、特定の指定方法に限定するものではない。【００９５】
請求項４は、バージョンの代わりに、サーバーが編集記録を受け付けた時刻を利用する方法や、サーバーへの同期アクセス時刻を利用する方法に対応する。これは「指定された時刻」の指定方法を限定するものではない。請求項５は更新の取り消しが有る運用に対応するもので、工程ＢとＣの間に工程ＤとＥが挿入れさている。請求項１に「不変確認範囲」の概念を明記したのが請求項６である。【００９６】
サーバーにおいてグローバル原本ＤＢを更新するケースに対応するのが請求項７であり、請求項１に加え、サーバーから各ＰＣに更新されたグローバル原本ＤＢの情報を送信する工程Ｆが追加されている。編集記録がサーバーに到着した時刻をデータベースのバージョンとするのが、請求項８である。【００９７】
請求項２をベースに、サーバーへの同期アクセス時刻をローカル原本ＤＢのバージョンとする事を加えたのが請求項９である。請求項１０はサーバーから編集記録をダウンロードした時刻を更新されたローカル原本ＤＢのバージョンとする事を加えたものである。請求項１をベースに、他の計算機に「編集の停止、または編集アップの停止、またはローカル原本ＤＢの更新停止」を通知する工程を加えたのが請求項１１である。
【発明の効果】
【００９８】
従来のキャシュ技術の延長で並行ＤＢ編集お行おうとすると、編集毎にコピーを作成するので、そのコピーの処理と通信がオーバーヘッドとなる問題があった。ＰＣ毎のローカル原本ＤＢを永続的に利用する方法により、この問題を解決する。ローカル原本ＤＢは各ＰＣが作成した編集記録に基づき更新される。なお、膨大なＤＢの全てを複製したローカル原本ＤＢを作成する必要は無く、計算機に必要な部分のみを保持するローカル原本ＤＢで十分である。【００９９】
従来のキャシュの技術に基づく「先着優先」方法では、最新情報を基にした判断が無効となるケースが存在したが、本発明の「より最新の情報に基づく編集を優先」する方針に基づいた方法でこれらの問題が解決される。【０１００】
従来の「先編集優先」の方法では、ある時点で有効と判定された編集が、後から到着した編集により無効とされるケースが有り運用上問題であった。しかし本願の「更新の取り消しが無い運用」を用いれば問題は無い。なお、本願の「更新の取り消しが有る運用」でも、取り消しが発生するのはごく限られた状況である。ローカル原本ＤＢを同期して編集して編集記録をアップする周期を短くする事により、取り消しの可能性を小さくする事が出来る。【０１０１】
本発明の「より最新の情報に基づく編集を優先」する基準は、「より最新の情報に基づく判断はより確からしい」と考える思想であり、データを扱う人間に受け入れやすい基準である。【０１０２】
本発明のバージョン設定範囲の概念により、ＤＢを実際に分割する事なく、ＤＢを分割したのと同様に、情報の更新の管理が明確になる。さらに「不変確認範囲」の概念により、本当に解決すべき競合のみを的確に検出できる。【０１０３】
ローカル原本ＤＢのバージョンを、（最後に）適用した編集記録がサーバーで受け付けられた日時、または、計算機が（最後に）編集記録の有無を確認した日時とする事により、「より最新の情報に基づく編集を優先」をより重視した運用が可能になる。【０１０４】
本発明ではさらに、編集、編集アップ、ローカル原本ＤＢの更新の停止により、更新の取り消しを防止する仕掛けを明らかにした。
【図面の簡単な説明】
【０１０５】
【図１】一般的な計算機の構成
【図２】ＰＣのローカル原本ＤＢを更新するケース
【図３】ローカル原本ＤＢの更新手順（その１）
【図４】ローカル原本ＤＢの更新手順（その２）
【図５】サーバーのグローバル原本ＤＢを更新するケース
【図６】グローバル原本ＤＢの更新手順（その１）
【図７】グローバル原本ＤＢの更新手順（その２）
【図８】アップ禁止をサーバーからＰＣに伝える手順
【図９】編集禁止をサーバーからＰＣに伝える手順
【図１０】単純化した実施例
【符号の説明】
【０１０６】
0100    計算機
0102    通信装置
0103    演算装置
0104    主記憶装置
0105    主記憶装置内のＤＢ（データベース）
0106    二次記憶装置
0107    入出力装置
0108    表示装置
0109    バス
0110    通信網
0111    二次記憶装置内のＤＢ（データベース）
0201      ＰＣ
0202      インターネットなどの通信網
0203      サーバー
0204      （ＰＣの）記憶装置
0205      （サーバーの）記憶装置
0206      ローカル原本ＤＢ
0207      グローバル初期原本ＤＢ
0208      編集記録
0209      作業ＤＢ
0210      編集記録ｎ
0210      編集記録ｎ＋１
0211      編集記録ｍ
0213      編集手段
0214      更新手段
0215      送信手段
0216      受信手段
0217      送受信管理手段
0218      編集記録１
0219      編集記録ｍ
0220      送信手段
0221      受信手段
0222      送受信管理手段
0301      未受信の編集記録を受信
0302      未処理の編集記録のリストにいれる
0303      未処理の編集記録リストからひとつ編集記録（Ｙ）を取り出し
0304      処理対象の編集記録（Ｙ）から編集バージョン（y）と不変確認範囲を取り出す
0305      不変確認範囲の情報を変更した過去の編集記録（Ｘ）を取り出す
0401      過去の編集記録（Ｘ）の編集バージョン（ｘ）と処理対象の編集記録（Ｙ）の編集バージョン（y）を比較する
0402      ｘとｙを比較
0403      不変確認範囲の情報を変更した過去の編集記録（Ｘ）を（再び）順に取り出す
0404      取り出した過去の編集記録（Ｘ）により、更新されたローカル原本ＤＢのバージョン（ｎｘ）を特定する
0405      ｎｘとｙを比較
0406      取り出した過去の編集バージョン（Ｘ）によるローカル原本ＤＢの更新を取り消す
0407      処理対象の編集記録（Ｙ）でローカル原本ＤＢを更新する
0408      ローカル原本ＤＢのバージョンを更新
0501      ＰＣ
0502      インターネットなどの通信網
0503      サーバー
0504      （ＰＣの）記憶装置
0505      （サーバーの）記憶装置
0506      ローカル原本ＤＢ
0507      グローバル原本ＤＢ
0508      編集記録
0509      作業ＤＢ
0510      ローカル原本ＤＢ更新情報
0511      編集手段
0512      更新手段
0513      送信手段
0515      受信手段
0515      送受信管理手段
0516      ローカル原本ＤＢ更新情報
0517      更新手段
0518      送信手段
0519      受信手段
0520      送受信管理手段
0601      編集記録を受信
0602      処理対象の編集記録（Ｙ）から編集バージョン（y）と不変確認範囲を取り出す
0603      不変確認範囲の情報を変更した過去の編集記録（Ｘ）を取り出し
0604      取り出した過去の編集記録（Ｘ）の編集バージョン（ｘ）と処理対象の編集記録（Ｙ）の編集バージョン（y）を比較する
0605      ｘとｙを比較
0701      不変確認範囲の情報を変更した過去の編集記録を再び順に取り出す
0702      取り出した過去の編集記録（Ｘ）により、更新されたクローバル原本ＤＢのバージョン（ｎｘ）を特定する
0703      ｎｘとｙを比較
0704      取り出した過去の編集バージョン（Ｘ）によるクローバル原本ＤＢの更新を取り消す
0705      処理対象の編集記録（Ｙ）でローカル原本ＤＢを更新する
0706      クローバル原本ＤＢのバージョンを更新する    
0801      編集記録の送信要求（前回最終番号付き）を受信
0802      アップ禁止中の確認
0803      アップ禁止を通知
0804      未送信、つまり前回最終番号以降の、編集記録のリストを作成
0805      送信
0806      完了通知
0901      編集記録の送信要求（前回最終番号付き）を受信
0902      未送信の編集記録のリストを作成
0903      送信
0904      編集禁止中の判定
0905      編集禁止を通知
0906      完了通知
1002    ＰＣ−Ａ
1003    ＰＣ−Ｂ
1004    初期ＤＢ
1005    （ＰＣ−Ａの）ローカル原本ＤＢ更新
1006    （ＰＣ−Ｂの）ローカル原本ＤＢ更新
1008    （ＰＣ−Ａの）レコードＺの複製
1009    （ＰＣ−Ｂの）レコードＺの複製
1010    （ＰＣ−Ａによる）グローバル初期原本ＤＢの取得
1011    （ＰＣ−Ｂによる）グローバル初期原本ＤＢの取得
1012    （ＰＣ−Ａによる）同期
1013    （ＰＣ−Ａの操作者による）編集
1014    （ＰＣ−Ａによる）編集の送信。つまり編集のアップ。
1016    （ＰＣ−Ａへの）確認（通知）と（ＰＣ−Ａによる）同期。なお、同期とは新たな編集とその順番の取得であり、他の記号の説明においても同じである。
1017    （ＰＣ−Ｂによる）同期
1018    （ＰＣ−Ｂの操作者による）編集
1019    （ＰＣ−Ｂによる）編集の送信。つまり編集のアップ。
1021    （ＰＣ−Ｂへの）確認（通知）と（ＰＣ−Ｂによる）同期。
1022    （ＰＣ−Ｂによる）同期
1023    （ＰＣ−Ｂの編集に基づくＰＣ−ＡのレコードＺの複製の）修正
【発明を実施するための最良の形態】
【０１０７】
本発明の方法は計算機のプログラムとして実現出来る。図１に典型的な計算機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と区別せず議論するので、図２および図５では単に、記憶装置0204, 0205, 0504, 0505の中のＤＢとして表示する。【０１１０】
複数のＰＣ0201が作成した編集記録をサーバー0203集め、ＰＣ0201がサーバーに集められた編集記録を受信し、ＰＣのローカル原本ＤＢ0206を更新するケースを図２で説明する。ＰＣ0201がインターネットなどの通信網0202を介して、サーバーと接続している。一般にＰＣは複数存在するが、図２では１台のみを示している。【０１１１】
ＰＣ0201には記憶装置0204が有り、ローカル原本ＤＢ0206が記録されている。ローカル原本ＤＢ0206の初期値は、サーバー0203の記憶装置0205のグローバル初期原本ＤＢ0207をコピーしたものである。ＰＣ0201の操作者の指示を受けて編集手段0213が編集を行うが、この時にはローカル原本ＤＢ0206を直接編集する事はせず、編集結果を作業ＤＢ0209とする。同時に編集記録0208を作成する。この編集記録には、編集バージョンつまり、ローカル原本ＤＢに設定されているバージョンが記録される。【０１１２】
編集記録0208は送信手段0215により通信網0202を介してサーバー0203に送られる。サーバー0203は受信手段0221により受信し、編集記録１0218, 編集記録ｍ0219の列に加えられる。編集記録には編集バージョンなどが記録されているとする。もし、編集記録とは別に編集バージョンがサーバーに送られてきた場合には、サーバーは両者の対応を記録する。【０１１３】
ＰＣ0201がローカル原本ＤＢ0206の更新試みる場合は、まずサーバーに未受信の編集記録の送信を要求する。ＰＣ0201がそれまでに受信した編集記録の最後のバージョンを通知すると、送受信管理手段がそれ以降の編集記録を選別し、送信手段0220によりサーバーから送る。ＰＣの送信の受信の協調作業は送受信管理手段0217により行われ、サーバーの送信の受信の協調作業は送受信管理手段0222により行われる。【０１１４】
ＰＣ0201が受信手段0216により受信した編集記録0210, 2011, 0212は記憶装置0204に記録される。更新手段0214がこれらを順番に取り出して、有効性を判定してローカル原本ＤＢ0206を更新し、そのバージョンを更新する。【０１１５】
図２のＰＣ0201の更新手段0214による、ローカル原本ＤＢ0206の更新手順を図３と図４に示す。ＰＣ0201はまず「未受信の編集記録を受信」0301しては、「未処理の編集記録のリストにいれる」0302。これを全ての未受信の編集記録に対して繰り返す。未処理の編集記録のリストが図２の編集記録ｎ0210, 編集記録ｎ＋１0211, 編集記録ｍ0212に相当する。【０１１６】
次に「未処理の編集記録リストからひとつ編集記録（Ｙ）を取り出し」0303、この「処理対象の編集記録（Ｙ）から編集バージョン（y）と不変確認範囲を取り出す」0304、そしてこの「不変確認範囲の情報を変更した過去の編集記録（Ｘ）を取り出す」0305、「過去の編集記録（Ｘ）の編集バージョン（ｘ）と処理対象の編集記録（Ｙ）の編集バージョン（y）を比較する」0401。「ｘとｙを比較」0402し、ｙ＜ｘまたはｙ＝ｘの場合は処理対象の編集記録（Ｙ）を無効とし、更新処理は行わない。そして次の未処理の編集記録に移る（0303に移る）。【０１１７】
ｙ＞ｘの場合は、このＸに対してＹが有効なので次の過去の編集記録の調査に移る（0305に移る）。「不変確認範囲の情報を変更した過去の編集記録（Ｘ）を特定」0305が全て完了して、全てに対して未処理の編集記録（Ｙ）が有効な時、有効と判定され次の処理に移る（0403に移る）。【０１１８】
次に「不変確認範囲の情報を変更した過去の編集記録を編集記録（Ｘ）を（再び）順に取り出す」0403。有れば「取り出した過去の編集記録（Ｘ）により、更新されたローカル原本ＤＢのバージョン（ｎｘ）を特定する」0404。「ｎｘとｙを比較」0405し、ｙ＜ｎｘの場合に「取り出した過去の編集バージョン（Ｘ）によるローカル原本ＤＢの更新を取り消す」0406。【０１１９】
「不変確認範囲の情報を変更した過去の編集記録を再び取り出す」0403で全ての過去の編集記録を取り出し処理が完了した後で、「処理対象の編集記録（Ｙ）でローカル原本ＤＢを更新」0407し、「ローカル原本ＤＢのバージョンを更新」0408する。【０１２０】
バージョン設定範囲が指定されており、不変確認範囲と一致する場合は、以下の手順となる。なお、バージョン設定範囲は編集記録に指定されているものとする。「取り出した過去の編集記録（Ｘ）の編集バージョン（ｘ）と処理対象の編集記録（Ｙ）の編集バージョン（y）を特定する」0401処理では、処理対象の編集記録（Ｙ）に指定されているバージョン設定範囲について「過去の編集記録（Ｘ）の編集バージョン（ｘ）と処理対象の編集記録（Ｙ）の編集バージョン（y）を特定する」。そしてこれ以降のバージョンの比較はこれに対して行われる。【０１２１】
サーバーが編集記録を受け付けた時刻をバージョンとする運用の場合は、サーバーが編集記録にその受付時間を記録する。そしてＰＣは「ローカル原本ＤＢのバージョンを更新」0408において、更新に用いた編集記録に記録されている受付時間を、更新されたローカル原本ＤＢのバージョンとして記録する0408。【０１２２】
ＰＣが、サーバーにアクセスし、未受信の編集記録の有無を確認した時刻をサーバーから取得し、その時刻を原本ＤＢのバージョンとする運用の場合は、「未受信の編集記録を受信」0301と「未処理の編集記録のリストにいれる」0302の前後または途中で、サーバーへのアクセス時間を取得する。ＰＣ毎の時間のズレを考えると、この時間はサーバーから貰うのが望ましい。そしてこの時間を記録しておき、受信した編集記録の最後の編集記録で「ローカル原本ＤＢを更新」0407した後、記録しておいた時間をローカル原本ＤＢのバージョンとして記録する0408。【０１２３】
サーバーでグローバル原本ＤＢを更新するケースを図５で説明する。ＰＣ0501がインターネットなどの通信網0502を介して、サーバー0503と接続している。一般にＰＣは複数存在するが、図５では１台のみを示している。【０１２４】
ＰＣ0501には記憶装置0504が有り、ローカル原本ＤＢ0506が記録されている。ＰＣ0501の操作者の指示を受けて編集手段0511が編集を行うが、この時にはローカル原本ＤＢ0506を直接編集する事はせず、編集結果を作業ＤＢ0509とする。同時に編集記録0508を作成する。この編集記録には、編集バージョンつまり、ローカル原本ＤＢに設定されているバージョンが記録される。【０１２５】
編集記録0508は送信手段0513により通信網0502を介してサーバー0503に送られる。サーバー0503は受信手段0519により受信し、編集記録に記録されていたバージョンで有効性を判定し、グローバル原本ＤＢ0507を更新する。この時、ローカル原本ＤＢ更新情報0516を作成する。ローカル原本ＤＢ更新情報0516はサーバーの送信手段0518によりＰＣ0501に送られ、受信手段0514により受信され、記憶装置0504に記録される。更新手段0512はこのローカル原本ＤＢ更新情報0510を用いて、ローカル原本ＤＢ0506を更新する。ＰＣの送信の受信の協調作業は送受信管理手段0515により行われ、サーバーの送信の受信の協調作業は送受信管理手段0520により行われる。【０１２６】
サーバー0503でグローバル原本ＤＢを更新する手順を図６と図７に示す。ＰＣ0501からの「編集記録を受信」0601し、この「処理対象の編集記録（Ｙ）から編集バージョン（y）と不変確認範囲を取り出す」0602。そしてこの「不変確認範囲の情報を変更した過去の編集記録（Ｘ）を取り出し」0603、「取り出した過去の編集記録（Ｘ）の編集バージョン（ｘ）と処理対象の編集記録（Ｙ）の編集バージョン（y）を比較する」0604。「ｘとｙを比較」0605し、ｙ＜ｘまたはｙ＝ｘの場合は処理対象の編集記録（Ｙ）を無効とし、更新処理は行わない。【０１２７】
ｙ＞ｘの場合は、このＸに対してＹが有効なので次の過去の編集記録の調査に移る（0603に移る）。「不変確認範囲の情報を変更した過去の編集記録（Ｘ）を取り出す」0603が全て完了して、全てに対して未処理の編集記録（Ｙ）が有効な時、有効と判定され次の処理に移る（0701に移る）。【０１２８】
次に、「不変確認範囲の情報を変更した過去の編集記録を再び順に取り出す」0701。有れば「取り出した過去の編集記録（Ｘ）により、更新されたグローバル原本ＤＢのバージョン（ｎｘ）を特定する」0702。「ｎｘとｙを比較」0703し、ｙ＜ｎｘの場合に「取り出した過去の編集バージョン（Ｘ）によるグローバル原本ＤＢの更新を取り消す」0704。【０１２９】
「不変確認範囲の情報を変更した過去の編集記録を再び取り出す」0701で全ての過去の編集記録を取り出し処理が完了した後で、「処理対象の編集記録（Ｙ）でローカル原本ＤＢを更新」0705し、「クローバル原本ＤＢのバージョンを更新」0706する。【０１３０】
更新の取り消し防止のための「アップ禁止」をサーバーからＰＣに伝える手順を説明したのが図８である。ＰＣから「編集記録の送信要求（前回最終番号付き）を受信」0801したとき、サーバーは「アップ禁止中」0802であるかを判定する。あるＰＣからの要請に基づき、サーバーがアップ禁止中の状態であれば、編集記録の送信要求したＰＣに対して「アップ禁止を通知」0803する。アップ禁止中でなければ「未送信、つまり前回最終番号以降の、編集記録のリストを作成」0804し、これらをＰＣに対して「送信」0805し、最後に「完了通知」0806を送る。【０１３１】
更新の取り消し防止のための「編集禁止」をサーバーからＰＣに伝える手順を説明したのが図９である。ＰＣから「編集記録の送信要求（前回最終番号付き）を受信」0901すると、サーバーは「未送信（つまり前回最終番号以降）の編集記録のリストを作成」0902し、これらをＰＣに対して「送信」0903する。この後で、サーバーは「（ローカル原本ＤＢの）編集禁止中」0904であるかを判定する。あるＰＣからの要請に基づき、更新禁止中であれば、編集記録の送信要求をしたＰＣに対して「編集禁止を通知」0905し、最後に「完了通知」0906を送る。【０１３２】
＜単純化した実施例＞
図１０にもう一つの実施例を示す。図１０のＤＢはＲＤＢで、バージョン設定範囲をＤＢ全体、バージョンは整数、不変確認範囲は編集したレコードのみとし、「更新の取り消しを行わない運用」としている。【０１３３】
また、レコード毎にこのレコードを編集した時点の編集バージョンを「レコードバージョン」として記録している。これにより編集解消のレコードのバージョンと処理対象の編集記録（Ｙ）の編集バージョン（y）を比較するだけで、「不変確認範囲の情報を変更した過去の編集記録（Ｘ）を取り出す」0305と「過去の編集記録（Ｘ）の編集バージョン（ｘ）と処理対象の編集記録（Ｙ）の編集バージョン（y）を比較する」0401 の処理が行える。【０１３４】
この様に単純化されているが、バージョンの移り変わりを見るには都合が良い。図１０ではサーバーに、グローバル初期原本ＤＢ、編集記録とその到着順（アップ順）が記録されている。サーバーの縦軸はその時点で最も新しい編集を示している。【０１３５】
ＰＣ−Ａ1002とＰＣ−Ｂ1003はそれぞれグローバル初期原本ＤＢ1004を取得1010, 1011し、それぞれのローカル原本ＤＢ1005, 1006としている。サーバーのグローバル初期原本ＤＢ1004をコピーしているので、どちらもベースバージョンは０である。その後、サーバー1001に編集１から編集６がアップされているが、これはＰＣ−Ａ1002、ＰＣ−Ｂ1003以外のＰＣ−がアップした編集である。【０１３６】
図２では、ＰＣ−Ａ1002はもう一度サーバーにアクセスしその時の最新の編集しその順番を取得している1012。このとき、編集１を取り込むので、ローカル原本ＤＢ1005のバージョンは１になる。【０１３７】
さて、ＰＣ−Ａ1002の操作者が、ローカル原本ＤＢ1005内のレコードＺの複製1008を編集したとする1013。この時、ローカル原本ＤＢ1005のベースバージョンが1なので、編集された「レコードＺの複製1008」のレコードバージョンが１にセットされる。この編集記録がサーバーにアップされ1014、編集７として記録される。この直後に、ＰＣ−Ａ1002は、（既に取得してある）編集１より後にアップされた、編集２から編集６を取得し、さらにＰＣ−Ａ1002先のアップ1014が編集７となった事を確認する。あらかじめ指定された「編集の有効性の判定」に基づき編集７までを順番に調査し、ローカル原本ＤＢ1005を更新する。ここでは、編集７が有効と判定されたとし、ローカル原本ＤＢ1005のベースバージョンが７になる。【０１３８】
一方、ＰＣ−Ｂ1003はサーバー1001から、編集１から（この同期1017時点での最新の）編集６を取得し1017、ローカル原本ＤＢ1006を更新してベースバージョンを６とする。その後ＰＣ−Ｂ1003の操作者が、「レコードＺの複製1009」を編集した1018とする。この時、「レコードＺの複製1009」のレコードバージョンが６になり、編集記録がサーバーにアップされ1019、編集８として記録される。【０１３９】
その後別のＰＣ−から編集９がアップされた後、ＰＣ−Ａ1002がサーバー1001にアクセスし、（既に取得してある）編集７より後にアップされた編集８と編集９を取得する1022。そしてローカル原本ＤＢ1008に編集８と編集９を順番に適用し、「編集の有効性の判定」を行い、ローカル原本ＤＢ1008を更新する。ここでローカル原本ＤＢ1008に編集９が反映されるので、製ＤＢ1008のベースバージョンが９になる。この時点で、先にＰＣ−Ｂ1003が編集したレコードＺの複製1009の内容がＰＣ−Ａ1002のローカル原本ＤＢ1005で有効になり、先にＰＣ−Ａ1002が編集したレコードＺの複製1008内容が無効になった事が（ＰＣ−Ａ1002で）判明する。
【産業上の利用可能性】
【０１４０】
データベースを複数の計算機から並行して編集出来ると使い勝手は良いが、並行編集の競合解消が問題である。本願の競合解消方法は「より最新の情報に基づく編集を優先」する仕組みであり、計算機が永続的に複製ＤＢを保持する本格的な「並行ＤＢ編集」においても、計算機が一時的に複製ＤＢを保持するケースにおいても有効である。この方法には「古い情報に基づく編集は無効と判定される」特徴がある。競合が予想される情報を編集する場合は「最新の情報との同期、編集、編集記録の送信」を迅速に行う「ほぼオンライン運用」により、この編集が無効となる可能性を小さくする事が出来る。逆に競合が予想されない情報を編集する場合は、情報の同期の後でゆっくり編集を行い、編集記録をまとめて送信する「ほぼオフライン運用」で良い。本願の方法により、幅広い応用分野でのデータベースの並行編集が可能となった。
【図１】
0005543918.tif 000002
【図２】
0005543918.tif 000003
【図３】
0005543918.tif 000004
【図４】
0005543918.tif 000005
【図５】
0005543918.tif 000006
【図６】
0005543918.tif 000007
【図７】
0005543918.tif 000008
【図８】
0005543918.tif 000009
【図９】
0005543918.tif 000010
【図１０】
0005543918.tif 000011