WO2009147847A1

WO2009147847A1 - データベース並行編集方式

Info

Publication number: WO2009147847A1
Application number: PCT/JP2009/002491
Authority: WO
Inventors: 上村邦夫
Original assignee: 株式会社アテナテレコムラボ
Priority date: 2008-06-04
Filing date: 2009-06-03
Publication date: 2009-12-10
Also published as: WO2009147846A1; WO2009147704A1; WO2009147851A1; JPWO2009147705A1; WO2009147705A1

Abstract

従来はサーバーにデータベースが置かれ、複数の計算機がアクセスする運用が一般的であるが、本発明は計算機が永続的に複製ＤＢを保持する、いわば本格的な「並行ＤＢ編集」を提案する。計算機相互に複製ＤＢの編集情報を交換する事により、各計算機の複製ＤＢが同期する。全ての関係するＰＣは、各ＰＣにおけるローカルな編集の編集記録を、一意に特定される順番（サーバーへの到着順など）で取り出し、ローカル原本ＤＢを更新する。同じ内容の編集情報を、同じ順番で、同じロジックで処理して、ローカル原本ＤＢを更新するので、結果として得られる各ＰＣのローカル原本ＤＢも同期する。これは実時間でなく、編集記録の順番を共通の時間軸とした同期である。このため、頻繁に編集記録を取り込み更新する「ほぼオンライン運用」と、更新周期が長い「ほぼオフライン運用」が混在した運用が可能である。

Description

データベース並行編集方式

本発明はデータベース（以下「ＤＢ」）に対する並行編集（以下「並行ＤＢ編集」）を実現するものである。

ＤＢの代表的な運用形態として以下が挙げられる。

「単独ＤＢアクセス」
ひとつの計算機のみでＤＢを操作する運用。ＤＢに対する編集が行えるのはこの計算機のみであるので、アクセスの競合防止は容易であるが、複数の計算機がＤＢにアクセスする運用には適さない。

「サーバーＤＢアクセス」
サーバー計算機（以下「サーバー」）がＤＢを管理し、端末計算機（以下「ＰＣ」）はサーバーにアクセスしサーバーの処理を通じてＤＢにアクセスする運用。ＤＢに直接アクセスするのはひとつのＰＣのみであるので、アクセスの競合防止は容易で、ベシミステックロックカーソル（非特許文献１）やトランザクションのロック（非特許文献２）が用いられている。

筆者が指揮し開発したシステム「パワーアップ新聞販売」では閲覧のみに対して並行アクセスを許可している。しかし、編集前には「編集権」を取得する事とし、同時にはひとつのＰＣしか編集出来ない様にしている。これもロックである。

しかし、サーバーとの通信が不可能な状況ではデータへのアクセスは出来ないし、ロックの取得や返却も出来ない。移動体では通信不可能なケースが頻発するので、ＤＢ操作には大きな制限となる。災害時の救援、医療、金融などいわゆるミッションクリティカルな業務では通信不可能な状況下でも業務遂行が求められるが、これに応える事は出来ない。例え通信が確保出来ても、劣悪な通信環境では再送などによりサーバーの応答が極端に長くなり、実用とならない場合もある。

作業用の複製を作成して処理を行うキャシュの技術で、処理や通信の効率化を図る試みも行われている。マイクロソフトのADO.NETは、ＰＣに当面の作業に必要なデータをサーバーからコピーし、サーバーとの接続を切断してから編集作業を行う。編集後に改めてサーバーと接続し編集内容をサーバーに送る。もし編集対象の情報が既に他の端末計算機から変更されていれば、後からの（この）編集を無効にする。。「ロックが結果として失敗した場合にはその編集を無効とする」と考えれば、編集ロックの一種とも言える。これは「オプティミスティック同時実行制御」（非特許文献３および非特許文献４）と呼ばれている。しかし、時として以下に示す不都合が生じる事がある。

（１）編集毎にコピーを作成するので、そのコピー処理と通信がオーバーヘッドとなる。（非特許文献１のp19）これを少なくするには、コピーの範囲を制限する必要があるが、これにはアプリケーションが対象とする情報の構造を熟知する必要がある。

（２）キャシュの情報がいつまで有効かの推定が困難である。コピー能率優先でキャシュ量を少なくするほど、次の編集では使えない可能性が高い。「オプティミスティック同時実行制御」では、一カ所でも変更されていれば無効となるので、キャシュ量を大きくするのも問題である。

（３）あるＰＣが過去に操作（入力、修正、削除）した情報が他のＰＣの操作により変更（削除、再修正、再入力）された事を検出するのは困難である。この問題は「サーバーＤＢアクセス」にも「キャシュ」にも共通する問題である。このＰＣによる編集の有効無効の判定結果は、アップ時に判明するが、それ以前に入力され一度は有効と判定された情報が変更されたのを迅速に把握するのは困難である。

その他の調査結果を以下に示す。非特許文献５は、ファイルのキャシュに関する発明で、編集の衝突（本願での競合）を検出した場合は単純に編集を拒否（非特許文献５の７頁の右下から１０行目）し記録を作成する。特許文献１は、サーバーがＤＢ編集の衝突を検出すると、正しく更新されたサーバーのＤＢを送り込む（「解決手段」および３６段）。特許文献２では更新時刻が後の更新を有効とし、特許文献１では更新時刻が先の更新を有効としている。いずれも、上記の問題を解決するものでは無い。

特許文献３はデータベースの同期を起動する条件に関する発明であり、同期の方法については「更新情報を互いに通知し合って同期」と言う一般的な同期の概念を示しているにすぎない。

特許文献４は、編集の競合が起きた際に「全ての更新データを保持する」ことを目的とした発明である。競合が無いときにのみ原本を更新するのであり、本発明とは目的も内容も異なる。特許文献５、特許文献６、特許文献７、特特許文献８、特許文献９についても調査したが、いずれも本発明とは異なる。
特開平９－９１１８４号広報特開２００４－１３８６７号広報特開２００４－８６８００号広報特開２００６－２８４９９８号広報特開平１１－１６１５３５号公報特表２００５－５０３６０６号公報特表２００５－５０８０５０号公報特開平８－１６４４７号公報特表２０００－５０１５３２号公報 William R. Vaughn, 株トップスタジオ訳、伊藤由紀子監修、Windows （登録商標）データベースプログラミング ADO.NET専修講座 VB.NET 編、2003年８月４日初版発行、翔泳社超図解ＳＱＬハンドブック、Ｃ＆Ｒ研究所、２００５年８月１２日初版発行「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

本格的な並行ＤＢアクセスを明らかにし、キャシュを前提とした従来の並行ＤＢ編集の問題を解決する。

本発明を以下の例を用いて説明する。

（１）準備
複数のＰＣに、原本ＤＢ（以下「グローバル原本ＤＢ」）の初期状態の複製ＤＢ（以下「ローカル原本ＤＢ」）を置く。このローカル原本ＤＢには初期のバージョン、つまり更新の順番を識別する順序数、を設定する事が出来る。バージョンを用いて編集の有効性を判定が可能である。

（２）ローカル編集
各ＰＣはそのローカル原本ＤＢに対するローカルな編集を行う。この編集の前にローカル原本ＤＢの作業用の複製を作成し、編集はこの複製に対して行う。また、編集時にはその編集内容を記録した「編集記録」を作成する。この編集記録には少なくとも「編集内容」が記録されるが、これに加え「編集バージョン」などを記録しても良い。

「編集内容」はどの情報をどの様に変更したか、どの情報を追加したか、どの情報を削除したか、などの一般的な編集内容である。「編集バージョン」は編集対象のローカル原本ＤＢのバージョン、厳密に言えば、編集対象の作業ＤＢの複製元となったローカル原本ＤＢのバージョン、である。

（３）サーバーへの編集記録の送信
各ＰＣは「編集記録」をサーバーに送信する。「編集記録」と「編集バージョン」を分けて記録している場合には、「編集記録」との対応を明示して「編集バージョン」も送信する。なお、「編集記録」の中に「編集バージョン」を記録する運用が、簡単で現実的と思われる。

（４）サーバーによる編集記録の受信
サーバーは、ＰＣから到着した編集記録を、その到着の順番と共に記録しておく。

（５）サーバーからの編集記録の受信
ＰＣはサーバーに対して、未受信の編集記録の送信を要求し、これらの編集記録、その（サーバーへの到着の）順番を受信する。編集記録に編集バージョンが指定されていれば、これも受信する。

（６）ローカル原本ＤＢの更新
ＰＣは指定された順番で編集記録を取り出し、その有効性を判定し、その内容に基づき、「ローカル原本ＤＢ」の更新を試みる。バージョンが設定されている場合はローカル原本ＤＢのバージョンを更新する。

全てのＰＣの初期のローカル原本ＤＢが同じで、各ＰＣにおけるローカルな編集の編集記録を、サーバーへの到着順で取り出し、ローカル原本ＤＢを更新する。同じ内容の編集情報を、同じ順番で、同じロジックで処理して、ローカル原本ＤＢを更新するので、結果として得られる各ＰＣのローカル原本ＤＢも同じになる。サーバーでグローバル原本ＤＢを更新しなくても各ＰＣのローカル原本ＤＢが同期するのはこの仕掛けによる。

ここで、各ＰＣで作成した編集記録にユニークな順番を付けるのがポイントである。ここではサーバーにアップした順番を用いているが、この順番を変更する事も、他の方法で順番を付けても良い。サーバーにアップされた順番を独自の判断基準（例えば操作者の優先権など）で変更してもかまわない。全ての関係するＰＣで取り出しローカル原本ＤＢを更新する順番が同じであれば良い。

編集記録の順番を付ける他の方法として、例えば、サーバーや特定のＰＣが編集記録の順番（または時間）を決定し（編集記録を作成または保持するＰＣに）通知し、編集記録を作成又は保持するＰＣはこの順番を編集記録に記入し、編集記録を互いに通知し合う方法でも良い。全ての関係するＰＣで取り出しローカル原本ＤＢを更新する順番が同じであれば良い。

各ＰＣはそれぞれの都合の良い時に複製ＤＢの更新を行うので、実時間で見ると、各ＰＣのローカル原本ＤＢとの更新の進みは様々であるが、特定の編集記録で更新された後のローカル原本ＤＢの状態は同じである。つまり、編集記録の順番を共通の時間軸とし各ＰＣのローカル原本ＤＢが同期する。

なお、「有効性の判定基準」と「ローカル原本ＤＢの更新処理方法」は、関係する全てのＰＣで同一である必要がある。しかし、同じであればその処理に制限は無い。同じ基準で、編集記録毎にその全部又は一部が有効または無効と判定されて、同じにローカル原本ＤＢを更新していれば、編集記録の順番を共通の時間軸とし各ＰＣのローカル原本ＤＢが同期する。

あるＰＣに注目した一連の動作例を説明する。このＰＣがサーバーから最新の編集記録を受信し、ローカル原本ＤＢを更新したとする。そしてこのＰＣがこのローカル原本ＤＢに対して編集を行い、その編集記録をアップする。なお、この編集の間に、別の計算機から編集記録がサーバーにアップされた可能性がある。

先の編集記録のアップの後で、それまでの（未受信の）編集記録をサーバーから受信し、編集記録を指定された順番で取り出し、ローカル原本ＤＢの更新を試みる。この過程でいくつかの編集は有効と判定されローカル原本ＤＢが更新される。

最後に先程アップした編集記録を取り出し、その不変確認範囲を調査し有効性の判定を行う。もし無効と判定されたなら、このＰＣの操作者は、無効となった事実とその理由を確認し、必要が有れば（最新の情報に対して）再度の編集を試みる。無効になった元の入力の記録があれば、その内容を再び入力するのは容易である。

ＰＣの操作者にとって、「自分の入力した情報が有効となったか否か」「どの様な状況で無効となったか」を正確に知るこが必要である。並行ＤＢアクセスにおいてオフライン編集した場合は、編集が有効であるか否かは即時ではなく、次の同期の時に判明するので、これらの情報は極めて重要である。情報が無効となった場合でも、全ての編集記録がＰＣに有り、その有効性の判定やローカル原本ＤＢの更新の様子も全てこのＰＣ内部で見ることが出来るので、再度入力する事も、入力を放棄するも、その状況から判断する事が出来る。

本発明の基本となる要点を箇条書きすると以下である。
（更新１）各ＰＣは未受信の編集記録を順番に受信する。
（更新２）受信した編集記録を指定の順番で用いて、ローカル原本ＤＢの更新を行う。
（編集１）各ＰＣはローカル原本ＤＢに対する更新を行い、この編集記録をサーバーにアップする。
（前提１）各ＰＣの初期のローカル原本ＤＢの内容は同じ。
（前提２）各ＰＣでローカル原本ＤＢの更新に用いる編集記録の内容が同じ。
（前提３）各ＰＣでローカル原本ＤＢの更新に用いる編集記録の順番が同じ。
（前提４）各ＰＣでローカル原本ＤＢの更新に用いるロジックが同じ。

以上の説明ではグローバル原本ＤＢの更新については説明していない。実はグローバル原本ＤＢはローカル原本ＤＢの初期値としてのみ存在するとしても問題は無い。ＰＣのプログラムで初期値のＤＢが作成出来るなら、サーバーが初期値を持つ必要も無い。各ＰＣのローカル原本ＤＢは互いに同期するので、仮想の（実在しない）グローバル原本ＤＢと同期していると言うことが出来る。もちろん、以上の手順に加えて、実際にグローバル原本ＤＢが有り、編集情報で更新しても良い。万が一、あるＰＣのローカル原本ＤＢが破損した場合には、グローバル原本ＤＢをコピーしても良いし、他のＰＣのローカル原本ＤＢをコピーしても良い。初期のグローバル原本ＤＢとそれまでの全ての編集記録から最新のローカル原本ＤＢを再作成する事も可能である。

（ほぼオンライン運用）
本発明では、編集記録の有効性の判定基準やローカル原本ＤＢの更新手順を特に規定するものではないが、一般に、古い情報に基づく編集を無効と判定するのは常識的と考えられる。従って、編集を行うＰＣが、その編集が無効と判定される可能性を出来るだけ少なくするには、編集の直前に最新の編集記録まで受信してローカル原本ＤＢを更新し、この最新のローカル原本ＤＢに対して編集を行い、編集後は速やかに編集記録をアップすると良い。頻繁に更新を行えば、ローカル原本ＤＢは常に最新の状態に保たれるので、「ほぼオンライン運用」と言う事が出来る。

（ほぼオフライン運用）
しかし、編集の競合が稀な情報を扱う場合には、（更新１）および（更新２）によるローカル原本ＤＢの更新から、（編集１）による編集のアップまでの時間を長くしても、編集が無効となる可能性は少ない。例えば、会社の組織ごとに支払伝票を入力するケースでは、レコードを修正するのは入力ミスや処理ミスを発見した場合であり、修正するとしてもレコードを入力した計算機で行う事が多い。この様なケースでは、更新から編集アップまでの期間を極端に長くした「ほぼオフライン運用」で問題は無い。たとえインターネット接続が出来ない状況でも支払伝票をゆっくり入力し、決算や検査の近くなってからまとめてアップすれば良い。

（改良－１）編集記録の内容の拡大
「編集内容」には、先に説明した一般的な編集内容や「編集バージョン」に加え、あとで詳しく説明する「バージョン設定範囲」や「不変確認範囲」を編集内容に含めることが出来る。ＤＢの部分（複数可）にバージョンを設定する場合には、どの部分のバージョンを扱っているかを示す必要が有り、これを示すのが「バージョン設定範囲」である。

編集内容に、一般的な編集内容に加え、編集バージョン、バージョン設定範囲、不変確認範囲、を記録するとこれらの情報の扱いが単純になるが、必ずしも編集内容に記録する必要は無い。分けて記録してもこれらの対応が他の計算機で把握できれば良い。

（改良－２）不変確認範囲の導入
「不変確認範囲」は、この編集に影響を与える範囲であり、この範囲の情報の値が変更されることは、この編集が無意味になる事を示している。「不変確認範囲」はＤＢが扱う情報、特にその編集する対象の情報の特性に応じて様々な指定が可能であるが、編集対象の情報を「不変確認範囲」に入れるのは自然である。リレーショナルＤＢ（以下「ＲＤＢ」）の場合には、編集対象のテーブル、編集対象と論理的に関連しているテーブル群、そのなかの一部のレコード、またはＤＢ全体などが想定される。

（改良－３）編集記録とその順番の操作
サーバーに記録する編集記録とその順番は、必ずしもＰＣがアップしたままの内容と順番である必要は無い。編集記録とその順番が全てのＰＣで同じであれば、これらの編集記録を適用したローカル原本ＤＢは編集記録の順番を共通の時間軸として同期する。

サーバー又は、管理業務を担当するＰＣが編集記録の内容を分析し、エラーとなって無効とされる部分や、冗長な（結局は何もしないのと同じ）部分を削除しても良い。エラーの編集記録や冗長な編集記録を削除し、結果としてその編集記録が削除されても問題は無い。編集記録の順番を変更しても、全てのＰＣでの（ローカル原本ＤＢの更新）処理に用いる順番が同じなら、編集記録の順番を共通の時間軸として各ＰＣのローカル原本ＤＢが同期する。

（改良－４）バージョン設定範囲の導入
バージョンを付与し編集を管理する単位は実際のＤＢである必要は無い。情報修正の影響が密接に関係している部分を特定して「バージョン設定範囲」とし、これ毎にバージョンを設定すれば、その範囲に関する編集とバージョンの推移を管理するのが容易になる。

バージョン設定範囲の設定はＤＢが扱う情報の構造や内容に依存するので、これらの知識無くして決定する事は出来ないが、ＲＤＢの場合にはレコード、テーブル、テーブルと論理的に関連しているテーブル群、そのなかの特定のレコード群、ＤＢ全体などが想定される。

ＤＢをバージョン設定範囲と読み替える事により、本明細書で説明した手順をそのまま適用する事が出来る。なお、複数のバージョン設定範囲に対する編集の記録が、ひとつの編集記録の中に一緒に記載されていても問題は無い。バージョン設定範囲毎に「編集内容」「編集バージョン」「不変確認範囲」などが記載されていれば良い。

医療の個人情報を例に説明する。医療情報のＤＢで、個人の医療記録の固まりをバージョン設定範囲の設定として設定する。テーブルの１行又は数行が個人の情報なら、これに対してバージョンを設定する。ＤＢには、多数の個人情報があり、それぞれにバージョンを設定する。編集記録には、個人に対応する「編集内容」「編集バージョン」「不変確認範囲」のセットが単数または複数存在する。「不変確認範囲」はこの個人記録全体でも、修正した情報（ＲＤＢならレコード）に限定しても、修正内容に応じて適切に設定すれば良い。個人情報毎にテーブルを構成していれば、テーブル毎にバージョンが設定される。

医療情報だけでなく、社会保証や銀行口座やローンなどの情報を個人毎に管理する事にも利用出来る。複数の部署で編集すると思われる犯罪者情報の管理にも使える。さらには、住民みずから一部のデータの編集が可能な「発展した形態の住民基本台帳の管理」など、個人対応の情報を扱う場合にも便利である。「（改良－８）ローカル原本ＤＢの守備範囲の限定」で説明する様に、ＰＣ毎にその権限で読み込める範囲の個人情報についてのローカル原本ＤＢを作成する事として、権限の範囲内の情報のみがこのＰＣに送られるなら、権限外の情報がハッキングされる恐れも無い。

なお、特定のＰＣ（の操作者）にとってはサーバーに集められた編集記録の多くは必要無い場合は、ローカル原本ＤＢがグローバル原本ＤＢの一部のみと同期していれば十分である。これに対応するには、ＰＣで全ての編集記録を受信した後で、不要な編集記録をスキップするのがひとつの方法である。サーバー側でＰＣ毎に必要な編集記録を抜いて送ると通信量が少なくなる。不必要な編集記録が混ざっていてもＰＣ側の処理で除外すれば問題は無い。編集情報に記録されたバージョン設定範囲を元にして、サーバーの管理する編集記録を分類しておくとＰＣに送るべき編集記録を迅速に判定する事が出来る。

（改良－５）バージョン付与のタイミング
ＤＢ原本（グローバル原本ＤＢ又はローカル原本ＤＢ）の全体又はやバージョン設定範囲に対してバージョンが付与されるが、その付与方法は、扱う情報の特性や運用の都合に応じて選択する事が出来る。

実際にローカル原本ＤＢの内容が更新された場合にバージョンを更新しても良いし、有効な更新の有無に関係なく、変更記録で原本ＤＢの変更を試みる毎にバージョンを更新しても良い。

（改良－６）編集のサーバー受け付け時刻をバージョンとする発展
サーバーが編集を受け付けた時刻をバージョンとして利用しても良い。本明細書で説明したバージョンはこの受け付け時刻と読み替える事になる。先に、バージョンは一連の順番を識別するための順序数と説明したが、時刻も順序を表すので何ら問題は無い。

（改良－７）サーバーへの同期アクセス時刻をバージョンとする発展
ＰＣが、サーバーにアクセスし、未受信の編集記録の有無を確認した時刻を（サーバーなどから）取得し、その時刻をバージョンとする方法も可能である。この確認毎に、未受信の編集記録が無くてもローカル原本ＤＢの新たなこの時刻をバージョンとして設定する。未受信の編集記録が有れば、これらを受信しこれらを用いてローカル原本ＤＢを更新し、そしてこの時刻をローカル原本ＤＢのバージョンとして設定する。より同期アクセスがより新しいローカル原本ＤＢに対する編集が優先されるので、一つのＤＢを競争で操作する関係者にとって理解しやすくまた納得出来るルールである。

（改良－８）ローカル原本ＤＢの守備範囲の限定
ローカル原本ＤＢが、（仮想の又は実在する）グローバル原本ＤＢの全体と同期すると仮定すると、説明は簡単である。しかし、ローカル原本ＤＢが扱う範囲はグローバル原本ＤＢ一部分とした方が、実用的である。医療情報に限らず、一般にＤＢ全体は巨大であるが、前記「（改良－４）バージョン設定範囲の導入」で説明した様に、個々の個人情報毎の集合体である。患者自身の計算機のローカル原本ＤＢはこの患者の情報のみが有れば良いし、医師の計算機のローカル原本ＤＢは受け持ちの患者の情報のみがあれば良い。つまり、ローカル原本ＤＢは、グローバル原本ＤＢ全体と同期している必要は無く、その必要な一部分と同期していれば十分である。これにより、ローカル原本ＤＢのサイズは小さくなり、その同期（内容を最新に保つ）操作は軽快になる。

（改良－９）編集記録の順番付与のバリエーション
順番を管理するサーバー（又はＰＣ）を置く。編集記録を作成したＰＣはこのサーバーに順番を問い合わせ、指定された順番を編集記録に書き込む。編集記録自体はＰＣの間で直接送信したとしても、ここに書かれている順番はユニーク（一意）である。順番の替わりに時間を編集記録に記入して、順番として用いても良い。なお、ＰＣ毎の時間のずれが生じる事を考え、特定のＰＣが時間を管理するなどの工夫が必要である。

（改良－１０）編集の一時的な禁止
ＤＢのデータ構造自体を変更するなど、他の計算機と並行して編集を行う事が出来ない場合には、他の編集を一時的に禁止すると都合が良い。以下では説明のため、ある編集（Ｘ）について、この編集との並行編集を禁止する状況を想定する。つまりＸの編集開始からＸの編集が完了してサーバーにアップされるまでの期間を、他のＰＣの「編集禁止期間」とする。Ｘのサーバーへのアップの後で、この編集記録（Ｘ）記録を取り込んだ後のローカル原本ＤＢに対する並行ＤＢ編集から禁止が解除される。

ひとつの方法は、サーバーがこの禁止区間にアップされた編集を無効とする方法である。Ｘの編集を生かし、かつ矛盾を起こさない確実な方法である。しかし、この無効とされた編集を作成した側の労力は無駄になる。

禁止区間であることを伝えるのが、もうひとつの方法である。編集Ｘを行うＰＣから他のＰＣに直接伝えても良いし、編集Ｘを行うＰＣから、サーバーに伝えて、サーバーから各ＰＣに伝えても良い。

編集Ｘを行うＰＣは、編集Ｘを行う前に最新の編集記録をサーバーに要求する時点で、他のＰＣの編集禁止をサーバーに伝えておく。最新の編集記録をサーバーに要求したＰＣに対し、サーバーから編集禁止を通知しても、未受信の編集記録の問い合わせなどに対する応答と一緒に通知しても良い。

「サーバーから編集禁止が通知された場合」には、このＰＣはローカル原本ＤＢの更新を行っても、編集は行わない。そして、改めて、最新の編集記録をサーバーに要求し、それに対して編集記録Ｘまでが送られ、これと同時に編集禁止解除が通知される。このＰＣは編集記録Ｘでローカル原本ＤＢを更新した後、これに対する編集を開始する。

＜出願時の請求項との対応＞
本明細書の並行編集とは、（実在の又は仮想の）グローバル原本ＤＢ（直感的にはＤＢ原本）の情報の全部または一部の複製を、ＰＣの内部にローカル原本ＤＢ（直感的には「複製ＤＢ」）として保持し、これに対して編集を行う事である。各ＰＣが保持する複製ＤＢに対する編集情報を、ＰＣが相互に交換してそれぞれの複製ＤＢを更新する。なぜ各ＰＣの複製ＤＢが同期するかと言うと、各ＰＣが同じ編集情報を同じ順番で用いてそれぞれの複製ＤＢを更新するからである。これを表現したのが請求項１である。請求項２は請求項１を装置で表現したものである。

請求項１の工程Ｄに編集記録の有効性を確認する手順を加えたのが請求項３である。請求項４は編集に影響を与える「不変確認範囲」の概念を請求項３追加し、これを用いて、編集記録の有効性確認を行う事を示したものである。請求項５は複製ＤＢのバージョンの概念を請求項３追加し、これを用いて、編集記録の有効性確認を行う事を示したものである。請求項６はバージョンが複製ＤＢの一部の情報又は情報の組み合わせに指定されている場合のものである。

請求項７は請求項５をベースに、有効性が否定されても複製ＤＢのバージョンの更新を行う事を追加したものである。請求項８は請求項５をベースに、アップされた編集記録にサーバーがアップ日時を記入するし、ＰＣはこれを複製ＤＢのバージョンとする方法である。請求項９は請求項５をベースに、ＰＣがサーバーにアクセスした時間を（サーバーから貰い）複製ＤＢのバージョンとする方法である。

サーバーＤＢアクセスでは、サーバーとの通信が不可能な状況ではデータへのアクセスは出来ないも問題があった。移動体では通信不可能なケースが頻発しＤＢ操作に大きな制限となる。災害時の救援、医療、金融などいわゆるミッションクリティカルな業務では通信不可能な状況下でも業務遂行が求められるが、これに応える事は出来ない。

この問題を解決するのが並行ＤＢ編集であるが、キャシュの技術をベースにした方法にはいくつかの問題が指摘されていた。

本願では、仮想の又は実在のグローバル原本ＤＢ、と同期したローカル原本ＤＢを作成し、永続的なキャシュとして用いる。そして、ローカル原本ＤＢに対する編集を行う直前など、必要な時にローカル原本ＤＢをグローバル原本ＤＢと同期する。これにより、編集毎にコピーを作成する従来の方法のオーバーヘッドやキャシュ有効性の判定などの問題が解決される。

また、あるＰＣが過去に操作した情報が他のＰＣの操作により変更された事を検出するのは、従来の方法では困難であったが、この本格的な「並行ＤＢアクセス編集」で容易に検出する事が可能になった。情報の編集状況を操作者が精査した上で、適切な対応を取ることが出来る。無効になったデータを再入力する事も、一部修正して再入力することも、最新のデータを修正する事も、無効とされたことを受け入れることも可能である。

さらに、ローカル原本ＤＢが保持し同期する対象はグローバル原本ＤＢの全体である必要は無く、その計算機に必要な一部の情報のみで良い。例えば、医療情報なら患者の計算機のローカル原本ＤＢはこの患者個人の医療情報のみを保持し、医者の計算機のローカル原本ＤＢには担当患者の医療情報のみを保持する。これにより、従来の方法で問題であったキャシュの適正量の問題も解決される。

「編集記録の有効性の判定」と「ローカル原本ＤＢの更新」などの処理をサーバーで無くＰＣで行う事の長所として、以下が挙げられる。
（１）必要な編集記録とその順番を取り込んでしまえば、サーバーとの通信が不要なので、その後の利用者の操作に対応するレスポンスが早くなる。
（２）ローカル原本ＤＢを更新する処理がこのＰＣで行われるので、特定の編集から影響を受ける情報（レコード）の範囲をきめ細かく調査する事ができる。また、操作者の要求に応じてより詳しい情報を表示する事が出来る。
（３）一般に、個々の計算機の計算能力は余っている事が多く、処理負荷が集中するサーバーに処理を置くよりも処理が高速になる。上記（１）との相乗効果で利用者の操作に対応するレスポンスが早くなる。

また、ローカル原本ＤＢの更新の間隔を調整する事により、「ほぼオンライン運用」から「ほぼオンライン運用」まで、自由に選択出来る。編集アクセスの多い情報を扱う場合は頻繁にローカル原本ＤＢの更新を行う「ほぼオンライン運用」を行えば良いし、支払伝票の入力の様に、修正が無いか修正があってもデータを入力した計算機で行う事が多い場合には、ローカル原本ＤＢの更新の間隔を極端に延ばした「ほぼオフライン運用」で問題は無い。決算や検査が近くなってから編集をアップしても問題は無い。

複数のＰＣがそれぞれの事情に応じて「ほぼオンライン運用」か「ほぼオンライン運用」が選択でき、両者が混在して運用出来るのも都合が良い。

一般的な計算機の構成ＰＣとサーバーの関係ローカル原本ＤＢに対して行った編集の記録をサーバーにアップする工程編集記録をサーバーから受信する工程編集記録でローカル原本ＤＢを更新する工程単純化した実施例

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      このバージョン設定範囲のバージョンを取得し編集記録に記入
0305      編集対象の情報に対応する不変確認範囲を特定し編集記録に記入
0306      編集対象の情報を特定する情報、編集の中身を編集記録に記入
0307      ローカル原本ＤＢに上記編集を適用した作業ＤＢを作成
0308      サーバーに編集記録を送る
0401      サーバーに前回の最終編集記録を通知
0402      サーバーから前回より後の編集記録のリストを受信
0403      編集記録を受信
0404      受信した編集記録を未処理編集記録リストにいれる
0405      編集禁止中を問い合わせる
0501      未処理の編集記録リストから編集記録を取り出し
0502      この編集記録の不変確認範囲と編集バージョンにより、現在のローカル原本ＤＢに対して有効かを判定
0503      ローカル原本ＤＢを更新
0504      ローカル原本ＤＢのバージョンを更新
0602    ＰＣ－Ａ
0603    ＰＣ－Ｂ
0604    初期ＤＢ
0605    （ＰＣ－Ａの）ローカル原本ＤＢ更新
0606    （ＰＣ－Ｂの）ローカル原本ＤＢ更新
0608    （ＰＣ－Ａの）レコードＺの複製
0609    （ＰＣ－Ｂの）レコードＺの複製
0610    （ＰＣ－Ａによる）グローバル初期原本ＤＢの取得
0611    （ＰＣ－Ｂによる）グローバル初期原本ＤＢの取得
0612    （ＰＣ－Ａによる）同期
0613    （ＰＣ－Ａの操作者による）編集
0614    （ＰＣ－Ａによる）編集の送信。つまり編集のアップ。
0616    （ＰＣ－Ａへの）確認（通知）と（ＰＣ－Ａによる）同期。なお、同期とは新たな編集とその順番の取得であり、他の記号の説明においても同じである。
0617    （ＰＣ－Ｂによる）同期
0618    （ＰＣ－Ｂの操作者による）編集
0619    （ＰＣ－Ｂによる）編集の送信。つまり編集のアップ。
0621    （ＰＣ－Ｂへの）確認（通知）と（ＰＣ－Ｂによる）同期。
0622    （ＰＣ－Ｂによる）同期
0623    （ＰＣ－Ｂの編集に基づくＰＣ－ＡのレコードＺの複製の）修正

本発明の方法は計算機のプログラムとして実現出来る。図１に典型的な計算機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の中のＤＢとして表示する。

サーバー0203に編集記録0218, 0219を置き、ＰＣ0201がこの編集記録を受信し、ＰＣのローカル原本ＤＢ0206を更新するケースを図２で説明する。ＰＣ0201がインターネットなどの通信網0202を介して、サーバー0203と接続している。一般にＰＣは複数存在するが、図２では１台のみを示している。

ＰＣ0201には記憶装置0204が有り、ローカル原本ＤＢ0206が記録されている。ローカル原本ＤＢ0206の初期値は、サーバー0203の記憶装置0205のグローバル初期原本ＤＢ0207をコピーしたものである。操作者の指示を受けて編集手段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を更新し、そのバージョンを更新する。

図３に、ＰＣが保持するローカル原本ＤＢに対して行った編集の記録（つまり「編集記録」）をサーバーにアップする工程を示す。まず「編集記録（のメモリエリア）を確保」0301する。「ローカル原本ＤＢ内の編集対象情報を特定」0302し、「この情報が属するバージョン設定範囲を特定し編集記録に記入する」0303。さらに、「このバージョン設定範囲のバージョンを取得し編集記録に記入」0304し、「編集対象の情報に対応する不変確認範囲を特定し編集記録に記入」0305し、「編集対象の情報を特定する情報、編集の中身を編集記録に記入する」0306。そして「ローカル原本ＤＢに、上記編集を適用した作業ＤＢを作成」0307し、「サーバーに編集記録を送る」0308。

図４に、ローカル原本ＤＢに対する編集記録と、これらに指定された順序を、サーバーから受信する工程を示す。まず「サーバーに前回の最終編集記録を通知」0401し、「サーバーから前回より後の編集記録のリストを受信」0402する。このリストに従って、「編集記録を受信」0403し、「受信した編集記録を未処理編集記録リストにいれる」0404。最後に「編集禁止中を問い合わせる」0405。編集禁止中でも、図５のサーバーから受信した編集記録でローカル原本ＤＢを更新する手段0214は起動するが、編集手段0213（および図３の手順）によるローカル原本ＤＢ0206に対する編集とサーバーへの編集記録の送信は行わない。

図５に、サーバーから受信した編集記録でローカル原本ＤＢを更新する更新手段0214の処理工程を示す。「未処理の編集記録リスト（編集記録ｎ0210, 編集記録ｎ＋１2011, 編集記録ｍ0212のリスト）から編集記録を取り出し」0501、「この編集記録の不変確認範囲と編集バージョンにより、現在のローカル原本ＤＢに対して有効かを判定」0502し、有効ならば「ローカル原本ＤＢを更新」0503し、「ローカル原本ＤＢのバージョンを更新」0504する。これを未処理の編集記録リストの全ての編集記録に対して行う。

編集記録に、サーバーがこの編集記録を受け付けた時間がその編集バージョンとして記録されていれば、これを更新されたローカル原本ＤＢのバージョンとする。サーバーに未受信の編集記録の有無を問い合わせた日時をバージョンとする場合は、図４の工程でサーバーから時間を取得し、図５の工程の最後（終了の直前）でその時間をローカル原本ＤＢのバージョンとして設定する。

ある実施例におけるバージョンの変化を図６で説明する。図６のＤＢはＲＤＢで、バージョン設定範囲をＤＢ全体、バージョンは整数、不変確認範囲は編集したレコードのみとしている。また、レコード毎にこのレコードを編集した時点の編集バージョンを「レコードバージョン」として記録し、これを用いて編集の有効性を確認している。

ＰＣ－Ａ0602とＰＣ－Ｂ0603はそれぞれグローバル初期原本ＤＢ0604を取得0610, 0611し、それぞれのローカル原本ＤＢ0605, 0606としている。サーバーのグローバル初期原本ＤＢ0604をコピーしているので、どちらもベースバージョンは０である。その後、サーバー0601に編集１から編集６がアップされているが、これはＰＣ－Ａ0602、ＰＣ－Ｂ0603以外のＰＣ－がアップした編集である。図２では、ＰＣ－Ａ0602はもう一度サーバーにアクセスしその時の最新の編集しその順番を取得している0612。このとき、編集１を取り込むので、ローカル原本ＤＢ0605のバージョンは１になる。

さて、ＰＣ－Ａ0602の操作者が、ローカル原本ＤＢ0605内のレコードＺの複製0608を編集したとする0613。この時、ローカル原本ＤＢ0605のベースバージョンが1なので、編集された「レコードＺの複製0608」のレコードバージョンが１にセットされる。この編集結果がサーバーにアップされ0614、編集７として記録される。この直後に、ＰＣ－Ａ0602は、（既に取得してある）編集１より後にアップされた、編集２から編集６を取得し、さらにＰＣ－Ａ0602先のアップ0614が編集７となった事を確認する。あらかじめ指定された「編集の有効性の判定」に基づき編集７までを順番に調査し、ローカル原本ＤＢ0605を更新する。ここでは、編集７が有効と判定されたとし、ローカル原本ＤＢ0605のベースバージョンが７になる。

一方、ＰＣ－Ｂ0603はサーバー0601から、編集１から（この同期0617時点での最新の）編集６を取得し0617、ローカル原本ＤＢ0606を更新してベースバージョンを６とする。その後ＰＣ－Ｂ0603の操作者が、「レコードＺの複製0609」を編集した0618とする。この時、「レコードＺの複製0609」のレコードバージョンが６になり、編集としてサーバーにアップされ0619、編集８として記録される。

その後別のＰＣから編集９がアップされた後、ＰＣ－Ａ0602がサーバー0601にアクセスし、（既に取得してある）編集７より後にアップされた編集８と編集９を取得する0622。そしてローカル原本ＤＢ0608に編集８と編集９を順番に適用し、「編集の有効性の判定」を行い、ローカル原本ＤＢ0608を更新する。ここでローカル原本ＤＢ0608に編集９が反映されるので、製ＤＢ0608のベースバージョンが９になる。この時点で、先にＰＣ－Ｂ0603が編集したレコードＺの複製0609の内容がＰＣ－Ａ0602のローカル原本ＤＢ0605で有効になり、先にＰＣ－Ａ0602が編集したレコードＺの複製0608内容が無効になった事が（ＰＣ－Ａ0602で）判明する。

サーバーにデータベースが置かれ、複数の計算機がアクセスする運用が一般的に行われているが、サーバーにアクセス出来ないと編集が出来ないなどの問題もある。本発明は計算機が永続的に複製ＤＢを保持する、いわば本格的な「並行ＤＢ編集」を提案しており、サーバーとの接続が不可能なケースが頻発する移動体や、災害時の救援、医療、金融などいわゆるミッションクリティカルな業務に用いる事が出来る。

Claims

データベースの編集方法であって、
（Ａ）データベースの全部または一部分の複製を保持し、
（Ｂ）該複製に対して行った編集の編集記録を他の装置に送信する工程と、
（Ｃ）該複製に対する編集記録を他の装置から受信する工程と、
（Ｄ）編集記録に指定されている順番、又は外部から指定された順番で、編集記録を取り出し、該編集記録を用いてデータベースの該複製を更新する、一連の手順を実行する工程、
を有する事を特徴とする方法。
データベースの編集装置であって、
（Ａ）データベースの全部または一部分の複製を保持する手段と、
（Ｂ）該複製に対して行った編集の編集記録を他の装置に送信する手段と、
（Ｃ）該複製に対する編集記録を他の装置から受信する手段と、
（Ｄ）編集記録に指定されている順番、又は外部から指定された順番で、編集記録を取り出し、該編集記録を用いてデータベースの該複製を更新する、一連の手順を実行する手段、
を有する事を特徴とする方法。
データベースの編集方法であって、
データベースの編集方法であって、
（Ａ）データベースの全部または一部分の複製を保持し、
（Ｂ）該複製に対して行った編集の編集記録を他の装置に送信する工程と、
（Ｃ）該複製に対する編集記録を他の装置から受信する工程と、
（Ｄ１）編集記録に指定されている順番、又は外部から指定された順番で、編集記録を取り出し、該編集記録の有効性の判定を行い、有効と判定された該編集記録を用いてデータベースの該複製を更新する、一連の手順を実行する工程、
を有する事を特徴とする方法。
データベースの編集方法であって、
（Ａ）データベースの全部または一部分の複製を保持し、
（Ｂ１）該複製に対して行った編集の編集記録に、この編集に影響を与える情報の範囲を示した「不変確認範囲」を対応させ、該編集記録を他の装置に送信する工程と、
（Ｃ１）該複製に対する編集記録と、該編集記録に対応する不変確認範囲を、他の装置から受信する工程と、
（Ｄ２）編集記録に指定されている順番、又は外部から指定された順番で、編集記録を取り出し、該編集記録に対応した「不変確認範囲」を用いて該編集記録の有効性の判定を行い、有効と判定された該編集記録を用いてデータベースの該複製を更新する、一連の手順を実行する工程、
を有する事を特徴とする方法。
データベースの編集方法であって、
（Ａ）データベースの全部または一部分の複製を保持し、
（Ｂ２）該複製に対して行った編集の編集記録に、該複製に指定されたバージョンを対応させ、該編集記録を他の装置に送信する工程と、
（Ｃ２）該複製に対する編集記録と、該記録に対応するバージョンを、他の装置から受信する工程と、
（Ｄ３）編集記録に指定されている順番、又は外部から指定された順番で、編集記録を取り出し、該編集記録に対応したバージョンを用いて該編集記録の有効性の判定を行い、有効と判定された該編集記録を用いてデータベースの該複製を更新しバージョンを更新する、一連の手順を実行する工程、
を有する事を特徴とする方法。
データベースの編集方法であって、
（Ａ）データベースの全部または一部分の複製を保持し、
（Ｂ３）該複製に対して行った編集の編集記録に、該複製の一部の情報又は情報の組み合わせに指定されているバージョンを対応させ、該編集記録を他の装置に送信する工程と、
（Ｃ２）該複製に対する編集記録と、該記録に対応するバージョンを、他の装置から受信する工程と、
（Ｄ３）編集記録に指定されている順番、又は外部から指定された順番で、編集記録を取り出し、該編集記録に対応したバージョンを用いて該編集記録の有効性の判定を行い、有効と判定された該編集記録を用いてデータベースの該複製を更新しバージョンを更新する、一連の手順を実行する工程、
を有する事を特徴とする方法。
データベースの編集方法であって、
（Ａ）データベースの全部または一部分の複製を保持し、
（Ｂ２）該複製に対して行った編集の編集記録に、該複製に指定されたバージョンを対応させ、該編集記録を他の装置に送信する工程と、
（Ｃ２）該複製に対する編集記録と、該記録に対応するバージョンを、他の装置から受信する工程と、
（Ｄ４）編集記録に指定されている順番、又は外部から指定された順番で、編集記録を取り出し、該編集記録に対応したバージョンを用いて該編集記録の有効性の判定を行い、データベースの該複製のバージョンを更新し、有効と判定された該編集記録を用いてデータベースの該複製を更新する、一連の手順を実行する工程、
を有する事を特徴とする方法。
データベースの編集方法であって、
（Ａ）データベースの全部または一部分の複製を保持し、
（Ｂ２）該複製に対して行った編集の編集記録に、該複製に指定されたバージョンを対応させ、該編集記録を他の装置に送信する工程と、
（Ｃ３）該複製に対する編集記録と、該記録に対応する日時を、他の装置から受信する工程と、
（Ｄ５）編集記録に指定されている順番、又は外部から指定された順番で、編集記録を取り出し、該編集記録に対応したバージョンを用いて該編集記録の有効性の判定を行い、有効と判定された該編集記録を用いてデータベースの該複製を更新新し、該編集記録に指定された日時を該複製のバージョンとして設定する、一連の手順を実行する工程、
を有する事を特徴とする方法。
データベースの編集方法であって、
（Ａ）データベースの全部または一部分の複製を保持し、
（Ｂ２）該複製に対して行った編集の編集記録に、該複製に指定されたバージョンを対応させ、該編集記録を他の装置に送信する工程と、
（Ｃ４）該複製に対する編集記録と、該記録に対応するバージョンを、他の装置から受信し、さらに日時を受信する、一連の工程と、
（Ｄ３）編集記録に指定されている順番、又は外部から指定された順番で、編集記録を取り出し、該編集記録に対応したバージョンを用いて該編集記録の有効性の判定を行い、有効と判定された該編集記録を用いてデータベースの該複製を更新し、工程Ｃ４で受信した該日時を該複製のバージョンとして設定する、一連の手順を実行する工程、
を有する事を特徴とする方法。