JPH11219309A - 分散型データベースシステムの一貫性管理方法およびその方法の各工程をコンピュータに実行させるためのプログラムを記録したコンピュータ読み取り可能な記録媒体 - Google Patents

Abstract

(57)【要約】 【課題】 トランザクションの種類に応じて異なる一貫
性管理を行うこと。 【解決手段】 各トランザクションの種類に一貫性管理
のレベルを表す第１レベル，第２レベルおよび第３レベ
ルのいずれかを設定し（Ｓ３００）、システム内におい
てトランザクションが発生した場合に（Ｓ３０１）、発
生したトランザクションの種類に基づいて一貫性管理の
レベルを判定し（Ｓ３０２，Ｓ３０３）、第１レベルの
場合に、厳格な一貫性管理方法を用いて一貫性管理を行
い、かつ、主サイトから各サイトへの更新伝播を即時行
い（Ｓ３０４）、第２レベルの場合に、厳格な一貫性管
理方法を用いて一貫性管理を行い、かつ、主サイトから
各サイトへの更新伝播を遅延させて行い（Ｓ３０５）、
第３レベルの場合に、弱い一貫性管理方法を用いて一貫
性管理を行い、かつ、主サイトから各サイトへの更新伝
播を遅延させて行う（Ｓ３０６）。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、分散型データベー
スシステムにおける複製データの一貫性管理方法に関
し、より詳細には、一貫性管理のレベルを複数段階に分
け、トランザクションの種類に応じて異なる一貫性管理
を行うことができるようにすることにより、分散型デー
タベースシステムの利便性の向上を図った分散型データ
ベースシステムの一貫性管理方法およびその方法の各工
程をコンピュータに実行させるためのプログラムを記録
したコンピュータ読み取り可能な記録媒体に関する。

【０００２】

【従来の技術】分散型データベースシステムにおいて
は、同一データについての複製データが複数のサイトに
それぞれ分散しており、かつ、複数のトランザクション
が並行して実行されることになるため、システム上に存
在する複製データ間の一貫性をいかに保つかが重要な課
題となっている。

【０００３】分散型データベースシステムにおける一貫
性管理方法の一例として、データの変更を直列化する操
作を行う強い一貫性管理と呼ばれる方法がある。この方
法によれば、直列化可能性を保証するが故に操作の並列
性を低下させ、一貫性管理のコストが増大するという短
所があるものの、直列化可能性が保証されるため、複製
データ間の矛盾が一切生じないという長所がある。この
強い一貫性管理は、銀行のＯＬＴＰ（Ｏｎ−Ｌｉｎｅ
Ｔｒａｎｓａｃｔｉｏｎ Ｐｒｏｃｅｓｓｉｎｇ）等に
適用されていることが多い。

【０００４】また、一貫性管理方法の他の例として、複
製データ間に矛盾が生じることを認める弱い一貫性管理
と呼ばれる方法がある。この弱い一貫性管理では、一つ
のトランザクションの中でシステム全体の一貫性を保証
するのではなく、別のトランザクションで更新伝播を行
う。この方法によれば、複製データ間に矛盾が生じてし
まうことがあるという短所があるものの、適用する応用
によってはその矛盾も問題とならない場合があり、一貫
性保持に要するコストを軽減することができるという長
所がある。この弱い一貫性管理は、データの更新が少な
い安定したシステムに適用されていることが多い。

【０００５】なお、弱い一貫性管理方式については各種
の研究がなされており、大別すると、（１）マルチバー
ジョン方式（Ｍｕｌｔｉ−ｖｅｒｓｉｏｎ Ｃｏｎｔｒ
ｏｌ）、（２）差異限定管理方式（Ｂｏｕｎｄｅｄ Ｄ
ｉｖｅｒｇｅｎｃｅ Ｃｏｎｔｒｏｌ）、および（３）
意味ベースの方式（Ｓｅｍａｎｔｉｃ−ｂａｓｅｄＣｏ
ｎｔｒｏｌ）に分類することができる。したがって、分
散型データベースシステムの規模やデータ内容を考慮し
て、どのような弱い一貫性管理方式を利用すべきかを決
定する必要がある。

【０００６】

【発明が解決しようとする課題】しかしながら、従来の
分散型データベースシステムの一貫性管理方法において
は、上述した強い一貫性管理および弱い一貫性管理のい
ずれか一方しか利用することができないため、複製デー
タの一貫性管理において不便な場合があるという問題点
があった。この問題点は、分散型データベースシステム
の規模・データ内容に応じて、トランザクションの種類
毎に強い一貫性管理および弱い一貫性管理を使い分けす
ることができる方が便利であるという要求に基づくもの
である。

【０００７】また、弱い一貫性管理を採用した従来の分
散型データベースシステムの一貫性管理方法において
は、一つのトランザクションの中でシステム全体の一貫
性を保証するのではなく、別のトランザクションで更新
伝播を行うため、更新伝播がいつ行われるかユーザは認
識することができないという問題点があった。すなわ
ち、更新伝播を行うタイミングはシステムに依存してお
り、ユーザの所望するタイミングで更新伝播を行うこと
ができるようにすることはできなかった。

【０００８】本発明は上記に鑑みてなされたものであっ
て、分散型データベースシステムの一貫性管理のレベル
を複数段階に分け、トランザクションの種類に応じて異
なる一貫性管理を行うことができるようにすることによ
り、分散型データベースシステムの利便性の向上を図る
ことを第１の目的とする。

【０００９】本発明は上記に鑑みてなされたものであっ
て、弱い一貫性管理を採用した場合に、更新伝播を行う
タイミングを設定できるようにすることにより、分散型
データベースシステムの利便性のさらなる向上を図るこ
とを第２の目的とする。

【００１０】

【課題を解決するための手段】上記目的を達成するた
め、請求項１の分散型データベースシステムの一貫性管
理方法は、任意のオブジェクトに対する複製データをそ
れぞれ有する第１のサイトと、前記複数の第１のサイト
における複製データの一貫性を集中管理する第２のサイ
トと、を備えた分散型データベースシステムの一貫性管
理方法において、予め前記複製データに対するリードま
たは更新を含む各トランザクションの種類に、一貫性管
理のレベルを表す第１レベル，第２レベルおよび第３レ
ベルのいずれかを設定する一貫性レベル設定工程と、シ
ステム内においてトランザクションが発生した場合に、
発生したトランザクションの種類に基づいて、前記一貫
性管理のレベルを判定する判定工程と、前記判定工程で
第１レベルであると判定された場合に、厳格な一貫性管
理方法を用いて一貫性管理を行い、かつ、第２のサイト
から複数の第１のサイトへの更新伝播を即時行う第１の
一貫性管理工程と、前記判定工程で第２レベルであると
判定された場合に、厳格な一貫性管理方法を用いて一貫
性管理を行い、かつ、第２のサイトから複数の第１のサ
イトへの更新伝播を遅延させて行う第２の一貫性管理工
程と、前記判定工程で第３レベルであると判定された場
合に、弱い一貫性管理方法を用いて一貫性管理を行い、
かつ、第２のサイトから複数の第１のサイトへの更新伝
播を遅延させて行う第３の一貫性管理工程と、を含むも
のである。

【００１１】また、請求項２の分散型データベースシス
テムの一貫性管理方法は、任意のオブジェクトに対する
複製データをそれぞれ有する第１のサイトと、前記複数
の第１のサイトにおける複製データの一貫性を集中管理
する第２のサイトと、を備えた分散型データベースシス
テムの一貫性管理方法において、予め前記複製データに
対するリードまたは更新を含む各トランザクションの種
類に、一貫性管理のレベルを表す第１レベル，第２レベ
ルおよび第３レベルのいずれかを設定する一貫性レベル
設定工程と、システム内においてトランザクションが発
生した場合に、発生したトランザクションの種類に基づ
いて、前記一貫性管理のレベルを判定する判定工程と、
前記判定工程で第１レベルであると判定された場合に、
ｒｅａｄ−ｏｎｌｙのトランザクションまたは更新を含
むトランザクションのいずれであっても、厳格な一貫性
管理方法を用いて一貫性管理を行い、第２のサイトから
複数の第１のサイトへの更新伝播を即時行う第１の一貫
性管理工程と、前記判定工程で第２レベルであると判定
された場合に、ｒｅａｄ−ｏｎｌｙのトランザクション
は緩和された一貫性管理方法を用いて一貫性管理を行
い、更新を含むトランザクションは厳格な一貫性管理方
法を用いて一貫性管理を行い、第２のサイトから複数の
第１のサイトへの更新伝播を遅延させて行う第２の一貫
性管理工程と、前記判定工程で第３レベルであると判定
された場合に、ｒｅａｄ−ｏｎｌｙのトランザクション
または更新を含むトランザクションのいずれであって
も、弱い一貫性管理方法を用いて一貫性管理を行い、第
２のサイトから複数の第１のサイトへの更新伝播を遅延
させて行う第３の一貫性管理工程と、を含むものであ
る。

【００１２】また、請求項３の分散型データベースシス
テムの一貫性管理方法は、請求項１または２に記載の分
散型データベースシステムの一貫性管理方法において、
前記第２および第３の一貫性管理工程における更新伝播
の遅延について、第２のサイトにおいて予め設定されて
いる更新伝播条件が満足された場合に更新伝播を行うこ
ととしたものである。

【００１３】また、請求項４の分散型データベースシス
テムの一貫性管理方法は、請求項１〜３のいずれか一つ
に記載の分散がデータベースシステムの一貫性管理方法
において、前記第２および／または第３の一貫性管理工
程における更新伝播の遅延とは、前記第１のサイトにお
いて前記トランザクション毎に更新伝播を行うタイミン
グを定めた更新伝播条件が設定され、第２のサイトにお
いて前記更新伝播条件を満足するように複数の第１のサ
イトへの更新伝播を行うこととしたものである。

【００１４】また、請求項５の分散型データベースシス
テムの一貫性管理方法は、請求項４に記載の分散型デー
タベースシステムの一貫性管理方法において、前記第２
および／または第３の一貫性管理工程が、少なくとも通
信回線および放送波を用いて第２のサイトから複数の第
１のサイトへの更新伝播を行うことができ、前記更新伝
播条件が、前記通信回線および放送波のいずれを用いて
更新伝播を行うかについての指定を含むものである。

【００１５】また、請求項６の分散型データベースシス
テムの一貫性管理方法は、請求項１〜５のいずれか一つ
に記載の分散型データベースシステムの一貫性管理方法
において、前記判定工程が、前記一貫性管理のレベルを
判定することに加えて、データの新規登録か否かを判定
し、前記新規登録であると判定した場合に、設定されて
いるレベルに関係なく、前記第３レベルと判定するもの
である。

【００１６】さらに、請求項７のコンピュータ読み取り
可能な記録媒体にあっては、前記請求項１〜６のいずれ
か一つに記載の分散型データベースシステムの一貫性管
理方法の各工程をコンピュータに実行させるためのプロ
グラムを記録したものである。

【００１７】

【発明の実施の形態】以下、本発明に係る分散型データ
ベースシステムの一貫性管理方法およびその方法の各工
程をコンピュータに実行させるためのプログラムを記録
したコンピュータ読み取り可能な記録媒体の実施の形態
について、添付の図面を参照しつつ詳細に説明する。

【００１８】〔実施の形態１〕実施の形態１に係る分散
型データベースシステムの一貫性管理方法においては、
複製データを有するサイトが超多地点に存在する分散型
データベースシステムに適用することを想定している。

【００１９】ここで、実施の形態１に係る分散型データ
ベースシステムの一貫性管理方法を説明するに先立っ
て、分散型データベースシステムを構築するために考慮
すべき二つの条件について説明する。

【００２０】一つ目は、システム内に存在する複製デー
タの更新を行うことができるサイトはどこかということ
であり、これには集中方式と分散方式とがある。集中方
式は、分散型データベースシステムにおける複数のサイ
トを主サイトと主サイト以外のサイトに分類し、主サイ
トでのみシステム内に存在する複製データの更新を可能
とし、他のサイトではその更新を行うことができないよ
うにするものである。一方、分散方式は、どのサイトで
もシステム内の複製データの更新を可能とし（Ａｎｙｓ
ｉｔｅ Ｗｒｉｔａｂｌｅ）、更新を行うサイトが全て
の複製データとの調整を行うというものである。

【００２１】二つ目は、一時的なデータ矛盾を認めるか
否かということであり、これには従来技術で説明した強
い一貫性管理と弱い一貫性管理とがある。強い一貫性管
理は、システム内に存在する複製データ間の矛盾を認め
ず、一つのトランザクションの中で全ての複製データ間
の整合性を保証するものである。例えば、２相コミット
プロトコルがこの方式に該当する。一方、弱い一貫性管
理は、応用の内容に特化して考えることにより、システ
ム内に存在する複製データ間の矛盾を一時的に認めるも
のである。この方式では、一つのトランザクションの中
で全ての複製データ間の一貫性が保証されるのではな
く、更新の伝播は別のトランザクションで行われる。

【００２２】図１は、集中管理または分散管理と、強い
一貫性管理または弱い一貫性管理との組み合わせによっ
て、分散型データベースシステムを構築した場合の長所
および短所が変化することを示した説明図である。実施
の形態１に係る分散型データベースシステムの一貫性管
理方法においては、後述するようにトランザクションの
種類に応じて強い一貫性管理および弱い一貫性管理を設
定できるようにするために、プロトコルが簡単な集中管
理方式を採用することにする。

【００２３】図２は、実施の形態１に係る分散型データ
ベースシステムの一貫性管理方法を実現するための分散
型データベースシステムの概念構成図である。図２に示
す分散型データベースシステムは、複数のサイトからな
り、複数のサイトは、任意のオブジェクトから生成した
複製データをそれぞれ有するサイトＤＢＳ₁ ，サイトＤ
ＢＳ₂ ，サイトＤＢＳ₃ ，・・・，サイトＤＢＳ_n と、
複製データの一貫性を集中管理する主サイトＤＢＳ
_P と、から構成されている。なお、以下の説明におい
て、サイトＤＢＳ₁ ，サイトＤＢＳ₂ ，サイトＤＢ
Ｓ₃ ，・・・，サイトＤＢＳ_n をまとめて示す場合には
サイトＤＢＳと記述するものとする。

【００２４】ここで、主サイトＤＢＳ_P が管理する情報
には、システム内に存在する複製データに対する各オブ
ジェクト毎に、対象オブジェクトＩＤ（いずれのオブジ
ェクトに対する複製データかを特定するためのものであ
り、各サイトＤＢＳが保有する複製データにも共通のも
のが付与されている），オブジェクトの最新値，最終更
新タイムスタンプ，最終更新サイトＩＤ，最終更新トラ
ンザクションＩＤ等がある。一方、各サイトＤＢＳは、
システム内に存在する全てのオブジェクトの複製データ
を有していなければならないというわけではない。さら
に、各オブジェクトのマスターデータについては、主サ
イトＤＢＳ_P が集中管理しても良いし（主サイトＤＢＳ
_P が管理している「オブジェクトの最新値」をマスター
データととらえても良い）、各サイトＤＢＳ毎に管理す
ることにしても良い。

【００２５】なお、図２には、主サイトＤＢＳ_P の下に
サイトＤＢＳを設けた様子のみが示されているが、各サ
イトＤＢＳの下にもさらに複数のサイトＤＢＳを設けて
階層構造を形成することもできる。このような場合にお
いては、上位のサイトＤＢＳを下位のサイトＤＢＳの主
サイトとして動作させることもできる。

【００２６】また、実施の形態１に係る分散型データベ
ースシステムの一貫性管理方法においては、一貫性管理
のレベルとしてレベルＡ〜Ｃを用意し、トランザクショ
ンの種類に応じて、異なるレベルの一貫性管理を行うこ
とができるようにしている。

【００２７】レベルＡ（本発明の第１レベルに該当す
る）は、ｒｅａｄ−ｏｎｌｙのトランザクションまたは
更新を含むトランザクションのいずれであっても、厳格
な一貫性管理方法を用いて複製データの一貫性管理を行
い、主サイトＤＢＳ_P から各サイトＤＢＳへの更新伝播
を即時行うというものである。

【００２８】換言すれば、レベルＡは、一つのトランザ
クションの中で各サイトＤＢＳへの更新伝播まで実行す
ることによって複製データの一貫性管理を行うものであ
って、トランザクションの直列可能性を保証するもので
ある。

【００２９】また、レベルＢ（本発明の第２レベルに該
当する）は、ｒｅａｄ−ｏｎｌｙのトランザクションに
ついては緩和された一貫性管理方法を用いて複製データ
の一貫性管理を行い、更新を含むトランザクションにつ
いては厳格な一貫性管理方法を用いて複製データの一貫
性管理を行い、主サイトＤＢＳ_P から各サイトＤＢＳへ
の更新伝播を遅延させて行うというものである。

【００３０】レベルＢにおいては、ある複製データの更
新処理を行う場合に、複数のトランザクションに分散し
て、主サイトＤＢＳ_P から各サイトＤＢＳへの更新伝播
が行われる。データアクセスに際しては、１コピー直列
化可能性は保証する（Ｐ．Ａ．Ｂｅｒｎｓｔｅｉｎ，
Ｖ．Ｈａｄｚｉｌａｃｏｓ，ａｎｄ Ｎ．Ｇｏｏｄｍａ
ｎ： Ｃｏｎｃｕｒｒｅｎｃｙ Ｃｏｎｔｒｏｌ ａｎ
ｄ Ｒｅｃｏｖｅｒｙｉｎ Ｄａｔａｂａｓｅ Ｓｙｓ
ｔｅｍｓ，Ａｄｄｉｓｏｎ−Ｗｅｓｌｅｙ，１９８
７）。１コピー直列化可能である場合、データ更新の際
には同一データに対する複数の複製データの中から最新
バージョンを探し、同一データに対する更新処理が競合
しないように処理するが、読み出しだけの際には、多少
データが古くても良いのでローカルデータをそのまま読
むという処理を行う。

【００３１】さらに、レベルＣ（本発明の第３レベルに
該当する）は、ｒｅａｄ−ｏｎｌｙのトランザクション
または更新を含むトランザクションのいずれであって
も、弱い一貫性管理方法を用いて一貫性管理を行い、主
サイトＤＢＳ_P から各サイトＤＢＳへの更新伝播を遅延
させて行うというものである。

【００３２】レベルＣは、複製データ間の一時的な一貫
性の崩壊を認め、各サイトＤＢＳ毎に複製データの更新
を可能とするものである。更新結果は複数のトランザク
ションとなって主サイトＤＢＳ_P から各サイトＤＢＳへ
伝播される。この場合、同一データに対する複製データ
についての更新の競合（衝突）が検出された場合の解決
法が問題となる。レベルＣにおいては、後述するよう
に、コミットした後に更新の競合を検出する処理が行わ
れるため、通常の方法のアボートはできない。更新の競
合が生じた場合については、後に説明することにする。

【００３３】なお、上述したレベルＡ〜Ｃは、後述する
ように、ｒｅａｄ−ｏｎｌｙまたは更新を含むトランザ
クションの種類に応じて設定される。

【００３４】続いて、実施の形態１に係る分散型データ
ベースシステムの一貫性管理方法を具体的に説明する。
図３（ａ）は一貫性管理のレベルを設定する手順を、図
３（ｂ）は図３（ａ）に示すようにして設定した一貫性
管理のレベルに基づいて一貫性管理方法を実行する手順
を示すフローチャートである。ここでは、図３（ａ）お
よび図３（ｂ）を用いて一貫性管理手順の概略を説明し
た後、レベルＡ〜Ｃの一貫性管理方法について具体的に
説明する。

【００３５】（一貫性管理手順の概略）まず、図３
（ａ）に示すように、分散型データベースシステムの規
模・データ内容等を考慮し、システム内で発生するトラ
ンザクションの種類に応じて予め一貫性管理のレベルを
設定する（Ｓ３００：本発明の一貫性レベル設定工程に
該当する）。すなわち、各トランザクションの種類に対
して、レベルＡ〜Ｃが設定される。なお、一貫性管理の
レベルは、分散型データベースシステムのセットアップ
時に設定することができ、また、トランザクションの発
生時に設定することもできる。

【００３６】図３（ａ）のステップＳ３００においてレ
ベルＡ〜Ｃを設定した後、図３（ｂ）に示すように、分
散型データベースシステム内にトランザクションが発生
すると（Ｓ３０１）、発生したトランザクションに設定
されている一貫性管理のレベルの判定処理を実行する
（Ｓ３０２：本発明の判定工程に該当する）。

【００３７】そして、ステップＳ３０２における判定処
理の結果に基づいて、発生したトランザクションに設定
された一貫性管理のレベルがレベルＡ，レベルＢおよび
レベルＣのいずれであるかを判定する（Ｓ３０３：本発
明の判定工程に該当する）。ステップＳ３０３におい
て、レベルＡであると判定した場合には、レベルＡの一
貫性管理方法を実行し（Ｓ３０４：本発明の第１の一貫
性管理工程に該当する）、レベルＢであると判定した場
合には、レベルＢの一貫性管理方法を実行し（Ｓ３０
５：本発明の第２の一貫性管理工程に該当する）、さら
に、レベルＣであると判定した場合には、レベルＣの一
貫性管理方法を実行する（Ｓ３０６：本発明の第３の一
貫性管理工程に該当する）。

【００３８】（レベルＡの一貫性管理方法）次に、レベ
ルＡによる一貫性管理方法について、強い一貫性管理方
法の概略について説明した後、実施の形態１のレベルＡ
による強い一貫性管理方法を具体的に説明することにす
る。

【００３９】強い一貫性管理方法としては、２相ロッ
ク，楽観的２相ロック，グローバルタイムスタンプに基
づく楽観的方法，ベーシックタイムスタンプオーダリン
グ等の各種があり、これらによって一つのトランザクシ
ョンの中で全ての複製データを更新する場合には直列化
可能となる。なお、「完全に複製されたシステムでは、
楽観的２相ロックが最も適している」と述べている論文
がある（Ｍ．Ｊ．Ｃａｒｅｙ ａｎｄ Ｍ．Ｌｉｖｎ
ｙ： “Ｃｏｎｆｌｉｃｔ ｄｅｔｅｃｔｉｏｎｔｒａ
ｄｅｏｆｆｓ ｆｏｒ ｒｅｐｌｉｃａｔｅｄ ｄａｔ
ａ，" ＡＣＭ ＴＯＤＳ，Ｖｏｌ．１６，Ｎｏ．４，ｐ
ｐ．７０３−７４６，Ｄｅｃ．１９９１：シミュレーシ
ョンでパフォーマンス評価を行った代表的論文であ
る）。

【００４０】上記強い一貫性管理方法のうち、楽観的制
御方式ではコミット時までロックを行わずにプライベー
ト領域（ワークエリア）にのみ複製データの更新結果を
保存しておき、コミット時になって初めてトランザクシ
ョン間の競合があったかどうかを調べる。

【００４１】ここで、あるデータに対する複数の複製デ
ータがシステム内に存在する場合の楽観的２相ロック方
式の代表例な処理の例を以下に示す（ＩＣＤＣＳ９５の
Ｊｉｎｇのアルゴリズム）。 （１）ｒｅａｄとｗｒｉｔｅに対しては、全複製データ
Ｘ０，Ｘ１，・・・，ＸｎをＲｌｏｃｋ（ｒｅａｄモー
ドのロック）する（Ｒｌｏｃｋはトランザクションが複
製データを利用していることを示すためのものであ
る）。 （２）トランザクションの終了時に、ｗｒｉｔｅした複
製データをＷｌｏｃｋ（ｗｒｉｔｅモードのロック）す
る。Ｗｌｏｃｋできればトランザクションをコミット
し、そうでなければアボートする。 （３）全ロックを解除する。

【００４２】上記楽観的２相ロック方式においては、確
認相で全てのサイトＤＢＳにロックをかけなければなら
ないことが問題である。すなわち、実際には全てのサイ
トＤＢＳにロックをかけることは難しいため、楽観的２
相ロック方式は障害に弱いといえる。

【００４３】その理由について、集中管理に基づく２相
ロック方式と比較して説明する。集中管理に基づく２相
ロック方式の場合は、トランザクションがｒｅａｄした
いとき、マスターデータに対してＲｌｏｃｋをかけてか
ら、ローカルデータを読み出す。ｗｒｉｔｅの場合も同
様で、マスターデータにＷｌｏｃｋをかけてから全複製
データをｗｒｉｔｅする。したがって、マスターデータ
のみをロックすれば良いため、負荷を軽減できる。とこ
ろが、楽観的２相ロック方式の場合には、全てのサイト
でｗｒｉｔｅできなければアボートしなくてはならない
ため、障害に弱いといえる。

【００４４】また、ダウンしている（参加できない）サ
イトがあっても、処理が続けられるようにするために、
以下の２つの方式が考えられる。

【００４５】第１の方式は、重み付き投票方式（Ｇｉｆ
ｆｏｒｄによって提案されたもの）である。重み付き投
票方式においては、以下の条件を満たす一定数のサイト
が参加すれば、その中に必ず最新版の値が含まれること
が保証されている。

【００４６】 Ｒｅａｄ−ｑｕｏｒｕｍ＋Ｗｒｉｔｅ−ｑｕｏｒｕｍ＞ｎ Ｗｒｉｔｅ−ｑｕｏｒｕｍ＋Ｗｒｉｔｅ−ｑｕｏｒｕｍ＞ｎ ここで、ｎは複製データの数を表す。

【００４７】第２の方式は、集中管理に基づくタイムス
タンプベースの楽観的方式（ＰＴＯ：Ｐｒｉｍａｒｙ−
ｂａｓｅｄ Ｔｉｍｅｓｔａｍｐ Ｏｐｔｉｍｉｓｔｉ
ｃＣｏｎｔｒｏｌ）である。ＰＴＯ方式は集中管理方式
であるため、ダウンしているサイトについては無視する
ことができる。

【００４８】具体的に、集中管理方式では、更新が承認
された複製データの最新の値が主サイトＤＢＳ_P に保持
される。よって楽観的制御方式の確認相（ｖａｌｉｄａ
ｔｉｏｎ ｐｈａｓｅ）において一貫性のチェックを行
う場合に主サイトＤＢＳ_P に問い合わせるだけで済み、
他の複製データにＷｌｏｃｋをかけにいく必要はなくな
る。切断していたサイトが再接続した場合の制御も同じ
で良い。ＰＴＯ方式において複数種類の複製データにア
クセスするトランザクションにあっては、ローカルサイ
トにそれらの複製を作成してから実行を始めることとす
る。

【００４９】実施の形態１に係る分散型データベースシ
ステムの一貫性管理方法を超多地点にわたる分散型デー
タベースシステムに適用することを想定した場合には、
重み付き投票方法よりＰＴＯ方式の方が優れていると考
えられる。なぜなら、ＰＴＯ方式の場合、一貫性のチェ
ックを行う場合に主サイトＤＢＳ_P に問い合わせるだけ
で済むため、主サイトＤＢＳ_P がダウンしない限り、通
信コストの削減を図ることができるからである。

【００５０】そこで、実施の形態１に係る分散型データ
ベースシステムの一貫性管理方法においては、レベルＡ
の一貫性管理方法としてＰＴＯ方式を採用することに
し、以下にレベルＡの一貫性管理方式を具体的に説明す
る。ここでは、サイトＤＢＳ₁でｒｅａｄ−ｏｎｌｙま
たはｒｅａｄ−ｏｎｌｙ以外の更新を含むトランザクシ
ョンＴが発生するものとする。

【００５１】なお、以下の説明において、複製データは
オブジェクトＯに対してｎ個あると仮定し、それを
Ｏ₁ ，・・・，Ｏ_n と表すと共に、主サイトＤＢＳ_P が
有するオブジェクトＯの複製データをＯ₀ と表す。オブ
ジェクトＯの最後に更新された時刻を表すタイムスタン
プをｔ（Ｏ）とし、またトランザクションＴが保持する
オブジェクトＯの最終更新タイムスタンプをｔ（Ｏ，
Ｔ）と表すことにする。

【００５２】サイトＤＢＳ₁ は、トランザクションＴが
発生すると、そのトランザクションＴに設定されている
一貫性管理のレベルを判定する処理を行う。発生したト
ランザクションＴがレベルＡの場合、レベルＡの一貫性
管理方法が実行される。

【００５３】（１）更新を含むトランザクションの場合 読み出し相 サイトＤＢＳ₁ は、ローカルデータ、即ち複製データＯ
_i にアクセスし、複製データＯ_i をプライベート領域
（ワークエリア）に読み出す。そして、プライベート領
域に読み出された複製データＯ_i についてｒｅａｄおよ
びｗｒｉｔｅが行われる。複製データＯ_i をプライベー
ト領域に読み出す際には、複製データＯ_iの最後に更新
された時刻を表すタイムスタンプｔ（Ｏ_i ）をトランザ
クションＴが保持する複製データＯ_i の最終更新タイム
スタンプに設定し、ｔ（Ｏ_i ，Ｔ）とする。

【００５４】 確認相 サイトＤＢＳ₁ は、主サイトＤＢＳ_P に対してレベルＡ
の一貫性管理方法の要求を含むＲＥＱＵＥＳＴメッセー
ジを送信する。図４は、ＲＥＱＵＥＳＴメッセージを示
す説明図であり、図４に示すデータがＲＥＱＵＥＳＴメ
ッセージに設定され、主サイトＤＢＳ_P に対して送信さ
れる。なお、ＲＥＱＵＥＳＴメッセージには、メッセー
ジの送信元であるサイトＤＢＳのサイトＩＤ，トランザ
クションＩＤ，さらに、トランザクションＴがアクセス
した複製データＯｉ毎に、操作（ｒｅａｄまたはｗｒｉ
ｔｅ），対象オブジェクトＩＤ，タイムスタンプｔ（Ｏ
ｉ，Ｔ）および更新後の値が設定される。

【００５５】主サイトＤＢＳ_P は、ＲＥＱＵＥＳＴメッ
セージを受信し、トランザクションＴにレベルＡが設定
されていると判定して、受信したＲＥＱＵＥＳＴメッセ
ージを待ち行列に入力する。待ち行列に入力されたＲＥ
ＱＵＥＳＴメッセージは、入力された順番で処理され
る。

【００５６】ここで、主サイトＤＢＳ_P は、サイトＤＢ
Ｓ₁ によってアクセスされた複製データＯ_i の全てにつ
いて、

【数１】 の条件を満たすか否か危険領域（ｃｒｉｔｉｃａｌ ｓ
ｅｃｔｉｏｎ）内で判定する。

【００５７】上記条件を満たすと判定した場合、サイト
ＤＢＳ₁ で更新された複製データＯ _i に該当する複製デ
ータＯ₀ をＲＥＱＵＥＳＴメッセージ中の更新後の値を
用いて更新し（更新後の値を保持する）、そのタイムス
タンプをｔ（Ｏ₀ ）＝Ｃｌｏｃｋ（現在時刻のタイムス
タンプ）に変更した後、図５に示すコミットメッセージ
を全てのサイトＤＢＳ（サイトＤＢＳ₁ ，サイトＤＢＳ
₂ ，サイトＤＢＳ₃ ，・・・，サイトＤＢＳ_n ：更新さ
れた複製データＯｉに該当する複製データを有するサイ
トＤＢＳ）に送信する。このコミットメッセージは、Ｒ
ＥＱＵＥＳＴメッセージに基づいて生成され、ＲＥＱＵ
ＥＳＴメッセージの送信元であるサイトＤＢＳのサイト
ＩＤ，トランザクションＩＤ，さらに、複製データＯｉ
毎に、対象オブジェクトＩＤ，タイムスタンプｔ
（Ｏ₀ ）および更新後の値が設定される。

【００５８】すなわち、更新を含むトランザクションの
場合、主サイトＤＢＳ_P はそのトランザクション内でサ
イトＤＢＳ₁ ，サイトＤＢＳ₂ ，サイトＤＢＳ₃ ，・・
・，サイトＤＢＳ_n の全てに更新情報の伝播を行う。た
だし、２相コミット方式とは異なり、サイトＤＢＳ₁ ，
サイトＤＢＳ₂ ，サイトＤＢＳ₃ ，・・・，サイトＤＢ
Ｓ_n からの返事は必要としない。つまり、ダウンしてい
るサイトＤＢＳがあっても無視して処理を進めることが
できる。

【００５９】なお、ダウンしているサイトＤＢＳが復旧
した場合、そのサイトＤＢＳは、主サイトＤＢＳ_P に対
して何らかのトランザクションを実行することにより、
最新の更新状態を知ることができる。また、復旧した後
に、主サイトＤＢＳ_P に対して最新の更新状態を問い合
わせることができるようにすることもできる。

【００６０】一方、上記条件を満たさないと判定した場
合、図６に示すアボートメッセージをサイトＤＢＳ₁ に
送信する。このアボートメッセージは、ＲＥＱＵＥＳＴ
メッセージに基づいて生成され、ＲＥＱＵＥＳＴメッセ
ージの送信元であるサイトＤＢＳのサイトＩＤ，トラン
ザクションＩＤ，さらに、複製データＯｉ毎に、対象オ
ブジェクトＩＤ，タイムスタンプｔ（Ｏ₀ ）および現在
の値Ｏ₀ が設定される。

【００６１】 書き込み相 サイトＤＢＳ₁ ，サイトＤＢＳ₂ ，サイトＤＢＳ₃ ，・
・・，サイトＤＢＳ_nは、コミットメッセージを受信し
た場合、コミットメッセージに含まれている更新後の値
およびそのタイムスタンプ値を用いて該当する複製デー
タを更新する。

【００６２】一方、サイトＤＢＳ₁ は、アボートメッセ
ージを受信した場合、トランザクションＴをアボート
し、アボートメッセージに含まれている最新値およびタ
イムスタンプ値を用いて複製データＯ_i およびそのタイ
ムスタンプｔ（Ｏ_i ）を更新する。

【００６３】（２）ｒｅａｄ−ｏｎｌｙのトランザクシ
ョンの場合 続いて、ｒｅａｄ−ｏｎｌｙのトランザクションの場合
について説明する。サイトＤＢＳ₁ は、ローカルデー
タ、即ち複製データＯ_i にアクセスし、複製データＯ_i
をプライベート領域（ワークエリア）に読み出す。ここ
で、複製データＯ _i をプライベート領域に読み出す際に
は、複製データＯ_i のタイムスタンプｔ（Ｏ_i ）をトラ
ンザクションＴが保持する複製データＯ_i のタイムスタ
ンプに設定し、ｔ（Ｏ_i ，Ｔ）とする。

【００６４】サイトＤＢＳ₁ は、主サイトＤＢＳ_P に対
してレベルＡの一貫性管理方法の要求を含むＲＥＱＵＥ
ＳＴメッセージを送信する。このＲＥＱＵＥＳＴメッセ
ージは図４に示したものと同様であるが、ｒｅａｄ−ｏ
ｎｌｙのトランザクションであるため、更新後の値は除
かれる。

【００６５】主サイトＤＢＳ_P は、ＲＥＱＵＥＳＴメッ
セージを受信し、トランザクションＴにレベルＡが設定
されていると判定して、受信したＲＥＱＵＥＳＴメッセ
ージを待ち行列に入力する。待ち行列に入力されたＲＥ
ＱＵＥＳＴメッセージは順番に処理される。

【００６６】主サイトＤＢＳ_P は、サイトＤＢＳ₁ によ
ってアクセスされた複製データＯ_iについて、

【数２】 の条件を満たすか否か危険領域（ｃｒｉｔｉｃａｌ ｓ
ｅｃｔｉｏｎ）内で判定する。

【００６７】上記条件を満たすと判定した場合、図５に
示したコミットメッセージをサイトＤＢＳ₁ に送信す
る。ただし、ｒｅａｄ−ｏｎｌｙのトランザクションで
あるため、更新後の値は除かれる。一方、上記条件を満
たさないと判定した場合、図６に示したアボートメッセ
ージをサイトＤＢＳ₁ に送信する。

【００６８】サイトＤＢＳ₁ は、コミットメッセージを
受信した場合、厳格に一貫性が保たれているとしてｒｅ
ａｄ−ｏｎｌｙのトランザクションをコミットする。一
方、サイトＤＢＳ₁ は、アボートメッセージを受信した
場合、ｒｅａｄ−ｏｎｌｙのトランザクションをアボー
トし、アボートメッセージに含まれている最新値および
タイムスタンプ値を用いて複製データＯ_i およびそのタ
イムスタンプｔ（Ｏ_i）を更新する。

【００６９】（レベルＢの一貫性管理方法）つぎに、レ
ベルＢによる一貫性管理方法について説明する。レベル
Ａでは一つのトランザクションの中で全てのサイト（サ
イトＤＢＳ₁ ，サイトＤＢＳ₂ ，サイトＤＢＳ₃ ，・・
・，サイトＤＢＳ_n ）への更新を行うことにしている
が、レベルＢでは、別のトランザクションで更新を伝播
させることにする。つまり、即時に更新を伝播させるの
ではなく、後述する各種の差異限定制約条件（本発明の
更新伝播条件に該当する）を設け、その条件が満足され
た場合に更新伝播を行うという処理を行う。

【００７０】ここでは、サイトＤＢＳ₁ でｒｅａｄ−ｏ
ｎｌｙまたはｒｅａｄ−ｏｎｌｙ以外の更新を含むトラ
ンザクションＴが発生するものとして、レベルＢの一貫
性管理方法を具体的に説明する。

【００７１】サイトＤＢＳ₁ は、トランザクションＴが
発生すると、そのトランザクションＴに設定されている
一貫性管理のレベルを判定する処理を行う。発生したト
ランザクションＴがレベルＢの場合、レベルＢの一貫性
管理方法が実行される。

【００７２】（１）更新を含むトランザクションの場合 読み出し相 サイトＤＢＳ₁ は、ローカルデータ、即ち複製データＯ
_i にアクセスし、複製データＯ_i をプライベート領域
（ワークエリア）に読み出す。そして、プライベート領
域に読み出された複製データＯ_i についてｒｅａｄおよ
びｗｒｉｔｅが行われる。ここで、複製データＯ_i をプ
ライベート領域に読み出す際には、複製データＯ_i の最
後に更新された時刻を表すタイムスタンプｔ（Ｏ_i ）を
トランザクションＴが保持する複製データＯ_i の最終更
新タイムスタンプに設定し、ｔ（Ｏ _i ，Ｔ）とする。

【００７３】 確認相 サイトＤＢＳ₁ は、主サイトＤＢＳ_P に対してレベルＢ
の一貫性管理方法の要求を含むＲＥＱＵＥＳＴメッセー
ジを送信する。このＲＥＱＵＥＳＴメッセージは、図４
に示したものと同様のものである。

【００７４】主サイトＤＢＳ_P は、ＲＥＱＵＥＳＴメッ
セージを受信し、トランザクションＴにレベルＢが設定
されていると判定して、受信したＲＥＱＵＥＳＴメッセ
ージを待ち行列に入力する。待ち行列に入力されたＲＥ
ＱＵＥＳＴメッセージは、入力された順番で処理され
る。

【００７５】ここで、主サイトＤＢＳ_P は、サイトＤＢ
Ｓ₁ によってアクセスされた複製データＯ_i の全てにつ
いて、

【数３】 の条件を満たすか否か危険領域（ｃｒｉｔｉｃａｌ ｓ
ｅｃｔｉｏｎ）内で判定する。

【００７６】上記条件を満たすと判定した場合、サイト
ＤＢＳ₁ で更新された複製データＯ _i に該当する複製デ
ータＯ₀ をＲＥＱＵＥＳＴメッセージ中の更新後の値に
更新し（更新後の値を保持する）、そのタイムスタンプ
をｔ（Ｏ₀ ）＝Ｃｌｏｃｋ（現在時刻のタイムスタン
プ）に変更した後、図５に示したコミットメッセージを
サイトＤＢＳ₁ に送信する。加えて、主サイトＤＢＳ_P
は、上記トランザクションで更新された更新情報をキュ
ーに入れておき、差異限定制約条件が満足された場合
に、この更新情報を別のトランザクションにおいて他の
サイトＤＢＳ（サイトＤＢＳ₂ ，サイトＤＢＳ₃ ，・・
・，サイトＤＢＳ_n ）に送信することによって更新伝播
を行う。なお、ＲＥＱＵＥＳＴメッセージを送信して来
たサイトＤＢＳ（ここではサイトＤＢＳ₁ ）に対して
は、通信コストを下げるために更新伝播を行わないよう
にする。

【００７７】一方、上記条件を満たさないと判定した場
合、図６に示したアボートメッセージをサイトＤＢＳ₁
に送信する。

【００７８】ここで、上記差異限定制約条件について説
明する。差異限定制約条件としては、例えば、以下の
ａ）〜ｅ）等を挙げることができる。

【００７９】ａ）リフレッシュする周期を設定し、設定
した周期毎に更新伝播を行う。主サイトＤＢＳ_P は、一
定の周期毎に、他の全てのサイトＤＢＳ（サイトＤＢＳ
₂ ，サイトＤＢＳ₃ ，・・・，サイトＤＢＳ_n ）に更新
情報を送信することにより、更新伝播を行う。主サイト
ＤＢＳ_P は、データ更新情報をキューに入れておき、周
期毎にそれを送り出す。受け側のサイトＤＢＳ（サイト
ＤＢＳ₂ ，サイトＤＢＳ₃ ，・・・，サイトＤＢＳ_n ）
はこの更新情報が送られてくることにより、主サイトＤ
ＢＳ_P がダウンしていないことを知ることができる。

【００８０】ｂ）キューにたまっている更新情報の数が
一定数を超えた場合に更新伝播を行う。例えば限度数を
３とした場合は、更新情報がキューに３つたまったとこ
ろで更新伝播が行われる。

【００８１】ｃ）更新伝播を行う基準となるデータの領
域を決めておき、その領域のデータが更新された場合に
更新伝播を行う。例えば、書誌情報のうち、タイトルお
よび作者の２つの属性が更新された場合は即時に更新伝
播を行うというものであり、直ちに更新情報を公知にす
る必要があるときに有効である。スキーマの属性とし
て、オブジェクトやその属性に即時更新伝播フラグをつ
けておき、それがＯＮになっている情報に更新があった
場合は即時に更新伝播を行うようにする。ただし、この
条件を設定する場合には、他の条件と共に設定する必要
がある。

【００８２】ｄ）更新伝播を行う基準となる閾値を設定
し、設定した閾値を超えた場合に更新伝播を行う。デー
タの更新の度合いに対して閾値を設定しておく。例え
ば、コンテンツの１／２０以上が更新された場合に更新
伝播するというような絶対的な値を設定し、または、参
照された回数が１００を超えたら即時更新伝播するとい
うような設定を行う。後者の場合、本や番組で人気が出
たものはそれを参照する人が多いことを示しているた
め、即時に情報行進を行うほうが良いという考えに基づ
くものである。

【００８３】ｅ）バージョンが大きく変わった場合に更
新伝播を行う。本の改訂版等でマイナーな誤字の直し程
度であれば更新伝播を待つようにするが、大幅な修正が
加えられた改訂版が出たような場合には、直ちに更新伝
播を行うことにするというものである。

【００８４】なお、上記ａ）〜ｅ）の差異限定制約条件
は組み合わせて設定することができる。

【００８５】次に、差異限定制約条件を用いた更新伝播
手順について説明する。図７（ａ）は差異限定制約条件
を設定する手順を示すフローチャートである。図７
（ａ）に示すように、システムのセットアップ時におい
て、上記ａ）〜ｅ）に示した差異限定制約条件を単独ま
たは組み合わせて主サイトＤＢＳ_P に設定する（Ｓ７０
０：本発明の更新伝播設定工程に該当する）。

【００８６】なお、差異限定制約条件を設定する際に
は、主サイトＤＢＳ_P を操作して設定しても良いし、サ
イトＤＢＳ₁ ，サイトＤＢＳ₂ ，サイトＤＢＳ₃ ，・・
・，サイトＤＢＳ_n から設定することもできる。

【００８７】また、差異限定制約条件は、上記ステップ
Ｓ７００の処理を再び行うことによって後に変更するこ
とも可能であるが、図３（ａ）に示したステップＳ３０
０において一貫性管理のレベルを設定する際にいずれか
の差異限定制約条件を設定しておく必要がある。

【００８８】さらに、サイトＤＢＳ毎に異なる差異限定
制約条件を設定することもできる。例えば、サイトＤＢ
Ｓ₁ については差異限定制約条件ａ）で更新伝播を行
い、サイトＤＢＳ₂ については差異限定制約条件ｂ）で
更新伝播を行うように主サイトＤＢＳ_P に対して設定す
ることもできる。この場合、主サイトＤＢＳ_P は、各サ
イトＤＢＳ毎に設定された差異限定制約条件を管理し、
各サイト毎に異なる差異限定制約条件を用いて更新伝播
を行うことになる。

【００８９】図７（ｂ）は図７（ａ）に示すようにして
設定した差異限定制約条件に基づいて更新伝播を行う手
順を示すフローチャートである。主サイトＤＢＳ_P は、
常にまたは定期的にキューに入れられた更新情報につい
て、差異限定制約が満足されたか否かを判定する（Ｓ７
０１）。

【００９０】そして、ステップＳ７０１において差異限
定制約が満足されたと判定した場合には、キューに入れ
られた更新情報をサイトＤＢＳ₁ ，サイトＤＢＳ₂ ，サ
イトＤＢＳ₃ ，・・・，サイトＤＢＳ_n に送信すること
によって更新伝播処理を行う（Ｓ７０２）。

【００９１】 書き込み相 サイトＤＢＳ₁ は、コミットメッセージを受信した場
合、コミットメッセージに含まれている更新後の値およ
びそのタイムスタンプ値を用いて該当する複製データを
更新する。

【００９２】また、サイトＤＢＳ₂ ，サイトＤＢＳ₃ ，
・・・，サイトＤＢＳ_n は、主サイトＤＢＳ_P から更新
伝播を受信した場合、更新後の値およびそのタイムスタ
ンプ値を用いて該当する複製データを更新する。この
際、２相コミット方式とは異なり、サイトＤＢＳ₁ ，サ
イトＤＢＳ₂ ，サイトＤＢＳ₃ ，・・・，サイトＤＢＳ
_n からの返事は必要としない。つまり、ダウンしている
サイトがあっても無視して処理を進めることができる。

【００９３】なお、ダウンしているサイトＤＢＳが復旧
した場合、そのサイトＤＢＳは、主サイトＤＢＳ_P に対
して何らかのトランザクションを実行することにより、
最新の更新状態を知ることができる。また、復旧した後
に、主サイトＤＢＳ_P に対して最新の更新状態を問い合
わせることができるようにすることもできる。

【００９４】一方、サイトＤＢＳ₁ は、アボートメッセ
ージを受信した場合、トランザクションをアボートし、
アボートメッセージに含まれている最新値およびタイム
スタンプ値を用いて複製データＯ_i およびそのタイムス
タンプｔ（Ｏ_i ）を更新する。

【００９５】（２）ｒｅａｄ−ｏｎｌｙのトランザクシ
ョンの場合 レベルＢの場合は、差異限定制約条件に基づいて更新伝
播を行うため、主サイトＤＢＳ_P を除き、サイトＤＢＳ
₁ ，サイトＤＢＳ₂ ，サイトＤＢＳ₃ ，・・・，サイト
ＤＢＳ_n の複製データは最新バージョンではない可能性
が常にある。それをｒｅａｄ−ｏｎｌｙのトランザクシ
ョンにおいて許可するかしないかでレベルＡとレベルＢ
との差が生じる。

【００９６】レベルＢにおけるｒｅａｄ−ｏｎｌｙのト
ランザクション場合では、ローカルサイト（サイトＤＢ
Ｓ₁ ，サイトＤＢＳ₂ ，サイトＤＢＳ₃ ，・・・，サイ
トＤＢＳ_n ）の複製データをそのままｒｅａｄするよう
にして、直列可能性チェックを緩和する。つまりｒｅａ
ｄ−ｏｎｌｙのトランザクションであれば、他のサイト
ＤＢＳとの調整を行うことなくローカルに実行してしま
うことにする。このようにした場合であっても、１コピ
ー直列化は保証される。つまり、他の更新が起こる前に
ｒｅａｄしていたと考えることで直列化できる。

【００９７】（レベルＣの一貫性管理方法）レベルＢに
よる一貫性管理方法は、更新を含むトランザクションに
対しては厳格、つまり強い一貫性管理を採用している。
これに対し、レベルＣによる一貫性管理方法において
は、システム全体の処理効率を更に向上させるため、更
新を含むトランザクションも緩和して弱い一貫性管理を
行うことにする。

【００９８】そこで、レベルＣの一貫性管理方法を説明
する。ここでは、サイトＤＢＳ₁ でｒｅａｄ−ｏｎｌｙ
またはｒｅａｄ−ｏｎｌｙ以外の更新を含むトランザク
ションＴが発生するものとする。

【００９９】サイトＤＢＳ₁ は、トランザクションＴが
発生すると、そのトランザクションＴに設定されている
一貫性管理のレベルを判定する処理を行う。発生したト
ランザクションＴがレベルＣの場合、レベルＣの一貫性
管理方法が実行される。

【０１００】（１）更新を含むトランザクションの場合 読み出し相 サイトＤＢＳ₁ は、ローカルデータ、即ち複製データＯ
_i にアクセスし、複製データＯ_i をプライベート領域
（ワークエリア）に読み出す。そして、プライベート領
域に読み出された複製データＯ_i についてｒｅａｄおよ
びｗｒｉｔｅが行われる。ここで、レベルＣの一貫性管
理方法においては、弱い一貫性管理を採用することによ
り、主サイトＤＢＳ_P を介することなく、サイトＤＢＳ
₁ ，サイトＤＢＳ₂ ，サイトＤＢＳ₃ ，・・・，サイト
ＤＢＳ_n 毎に単独で複製データの更新を行うことができ
る。そのため、サイトＤＢＳ₁ は、読み出した複製デー
タＯ _i を更新し、更新を含むトランザクションをコミッ
トする。

【０１０１】 確認相 サイトＤＢＳ₁ は、上記コミット時に主サイトＤＢＳ_P
宛てに承認リクエストメッセージ（更新ログ）を送信す
る。承認リクエストメッセージは、図４に示したＲＥＱ
ＵＥＳＴメッセージと同様のものである。

【０１０２】主サイトＤＢＳ_P は、サイトＤＢＳ₁ から
の承認リクエストメッセージに対して承認または非承認
を与える。承認・非承認の判定条件はＰＴＯ方式の中で
説明した通常のタイムスタンプ方式によるものである。

【０１０３】ここで、承認・非承認を判定する際に、サ
イトＤＢＳ₁ の承認リクエストメッセージと競合する他
のサイトＤＢＳの承認リクエストメッセージが存在しな
い場合には、サイトＤＢＳ₁ において行われた更新が承
認される。その結果、主サイトＤＢＳ_P の該当する複製
データが更新される（更新後の値を保持し、タイムスタ
ンプを変更）と共に、レベルＢで説明したように、その
更新情報がキューに入れられ、差異限定制約条件が満足
された場合に、この更新情報をサイトＤＢＳ（サイトＤ
ＢＳ₁ ，サイトＤＢＳ₂ ，サイトＤＢＳ₃ ，・・・，サ
イトＤＢＳ_n ）に送信することによって更新伝播が行わ
れる。なお、差異限定制約条件については、レベルＢで
説明した通りであるため、ここでは説明を省略する。ま
た、レベルＢの場合と同様に、承認リクエストメッセー
ジを送信して来たサイトＤＢＳ（ここではサイトＤＢＳ
₁ ）に対しては、通信コストを下げるために更新伝播を
行わないようにする。

【０１０４】一方、例えば、サイトＤＢＳ₁ およびサイ
トＤＢＳ₂ の承認リクエストメッセージが競合したもの
とする。具体的には、サイトＤＢＳ₁ およびサイトＤＢ
Ｓ₂で同一の複製データＯ_i を保持していて、両方のト
ランザクションで同時刻に複製データＯ_i を更新し、両
方のトランザクションがコミットされた後、承認リクエ
ストメッセージ（更新ログ）が主サイトに届いたものと
する。主サイトＤＢＳ _P は、承認リクエストメッセージ
が先に届いたサイトの更新を承認し、後から届いた方の
更新は承認しない。ここで、サイトＤＢＳ₂ の承認リク
エストメッセージがサイトＤＢＳ₁ の承認リクエストメ
ッセージより先に主サイトＤＢＳ_P に届いたものとする
と、サイトＤＢＳ₁ の更新は承認されないことになる。
この場合、主サイトＤＢＳ_P は、サイトＤＢＳ₁ に対し
てアボートメッセージを送信する。

【０１０５】 書き込み相 更新が承認された場合、サイトＤＢＳ₁ は、既に複製デ
ータを更新するためのトランザクションはコミットされ
ているため何ら処理を行う必要はない。一方、他のサイ
トＤＢＳは、差異限定制約条件によって更新情報が伝播
されて来るため、その更新情報に基づいて複製データを
更新する。この際、２相コミット方式とは異なり、サイ
トＤＢＳ₁ ，サイトＤＢＳ₂ ，サイトＤＢＳ₃ ，・・
・，サイトＤＢＳ_n からの返事は必要としない。つま
り、ダウンしているサイトがあっても無視して処理を進
めることができる。

【０１０６】なお、ダウンしているサイトＤＢＳが復旧
した場合、そのサイトＤＢＳは、主サイトＤＢＳ_P に対
して何らかのトランザクションを実行することにより、
最新の更新状態を知ることができる。また、復旧した後
に、主サイトＤＢＳ_P に対して最新の更新状態を問い合
わせることができるようにすることもできる。

【０１０７】一方、アボートメッセージを受信した場合
は、既にトランザクションはコミットにより完了してし
まっているため通常のアボートを行うことはできない。
そこで、レベルＣにおいては、他のサイトＤＢＳから必
要なバージョンの複製データをコピーすることにより更
新してしまった複製データを回復することにする。

【０１０８】ここで、上記承認リクエストメッセージ中
の複製データのうち、主サイトＤＢＳ_P から更新されて
いる値をコピーする処理、つまりトランザクション自身
がアボート用にデータを格納しておき、このデータを用
いて更新してしまった複製データを回復するという処理
も考えられる。しかしながら、マルチメディアデータは
一般にサイズが大きいため、トランザクションの中で複
製を作ることはコストがかかり問題となる。また、更新
頻度の小さい応用においては更新が衝突する可能性が少
ないため、そのような応用においてアボート用にデータ
の複製を作ることは効率的ではない。

【０１０９】よって、アボートメッセージを受信した場
合の処理として、記憶容量およびコピーに要する時間の
点からも他のサイトＤＢＳから必要なバージョンの複製
データをコピーして回復する処理を行う方が効率的であ
るといえる。

【０１１０】（２）ｒｅａｄ−ｏｎｌｙのトランザクシ
ョンの場合 レベルＣにおけるｒｅａｄ−ｏｎｌｙのトランザクショ
ン場合では、ローカルサイト（サイトＤＢＳ₁ ，サイト
ＤＢＳ₂ ，サイトＤＢＳ₃ ，・・・，サイトＤＢＳ_n ）
の複製データをｒｅａｄするようにして、直列可能性チ
ェックを緩和する。つまりｒｅａｄ−ｏｎｌｙのトラン
ザクションであれば、他のサイトとの調整を行うことな
くローカルに実行してしまうことにする。このようにし
た場合であっても１コピー直列化は保証される。つま
り、他の更新が起こる前にｒｅａｄしていたと考えるこ
とで直列化できる。

【０１１１】ここで、レベルＣの応用例として、検索エ
ージェント（人間に代わって複数のＤＢサイトを縦断検
索してくれるようなプログラム）のＤＢを考える。従来
のデータベースはオブジェクト値を永続的に格納するこ
とを目的としていた。ところが、検索エージェントのよ
うな応用を考えた場合、その記憶としてデータベースを
使うならば、永続的というよりは「少々間違っていても
良く、間違っていることが判定できれば良い。そして、
間違っていたら正しい値に更新すれば良い。」という特
徴を持つ。検索サイト名等を格納している場合におい
て、もし、そのサイトが移動したとしても、そのサイト
にアクセスしたときに初めて「そのサイトが移動してい
たこと」がわかれば良い。人間の記憶の変わりにＤＢを
利用とする場合、このような「多少間違ったデータでも
良い」という応用例を多く見出すことができる。

【０１１２】なお、以上説明した一貫性管理のレベルＡ
〜Ｃの特徴を一つにまとめると、図８のようになる。

【０１１３】このように、実施の形態１に係る分散型デ
ータベースシステムの一貫性管理方法によれば、分散型
データベースシステムの一貫性管理のレベルとしてレベ
ルＡ〜Ｃを設け、トランザクションの種類に応じてレベ
ルＡ〜Ｃによる異なる一貫性管理を行うことにより、複
製データの一貫性管理における利便性の向上を図ること
ができる。

【０１１４】また、実施の形態１に係る分散型データベ
ースシステムの一貫性管理方法を用いることにより、そ
れぞれ異なる一貫性管理のレベルでトランザクションを
実行することができ、トランザクションの種類に応じて
最適な複製データの一貫性管理を行うことができる。

【０１１５】さらに、レベルＢおよびレベルＣの場合
は、差異限定制約が満足された場合に更新伝播を行うこ
とにしたことにより、更新がある毎に更新伝播を行う必
要をなくすことができ、複製データの一貫性保持のコス
トを削減することができる。

【０１１６】〔実施の形態２〕つぎに、実施の形態２に
係る分散型データベースシステムの一貫性管理方法につ
いて説明する。例えば、電子図書館等の応用において
は、新規の書誌データを一括して登録することが多く、
また、大学等でも新入生や新人のデータ登録を一括して
行うことが多い。こうした新規登録トランザクション
は、既にあるデータを参照しないで独立に処理すること
が可能であることから、他のトランザクションとの競合
の確認処理を省略しても何ら問題は発生せず、むしろ処
理の効率化を図る上で好ましい。そのため、実施の形態
２に係る分散型データベースシステムの一貫性管理方法
においては、実施の形態１で説明した処理に加えて、一
貫性管理のレベルを判定する際に新規登録トランザクシ
ョンか否かを判定し、新規登録トランザクションである
場合には、他のトランザクションとの競合の確認処理を
省略して、そのまま登録処理を行うことができるように
するものである。

【０１１７】ところで、楽観的制御においては、読み出
し相，確認相および書き込み相からなる処理を行う必要
がある。ところが新規登録のみのトランザクションで
は、他のトランザクションと競合する可能性は全くない
ため、トランザクションが競合するか否かの確認を省略
し、読み出し相の処理が終わった後、直接書き込み相の
処理を実行することができる。

【０１１８】そこで、実施の形態２に係る分散型データ
ベースシステムの一貫性管理方法においては、既存のデ
ータと独立なデータを新規登録する場合について、独自
のトランザクションレベル（例えば、新規登録処理フラ
グを設定する）を設け、そのレベルのトランザクション
については一切競合チェックを行わないことにする。

【０１１９】新規登録トランザクションは、実施の形態
１で説明したレベルＡ〜Ｃのいずれ対しても適用するこ
とができる。ただし、効率を考えた場合には、各サイト
ＤＢＳ単位で更新を行うことができるレベルＣに適用す
ることが最も優れている。そのため、実施の形態２にお
いては、この新規登録トランザクションをレベルＣに適
用することを前提として、処理の概略を説明する。図９
（ａ）は一貫性管理のレベルおよび新規登録トランザク
ションを設定する手順を、図９（ｂ）は図９（ａ）に示
すようにして設定した一貫性管理のレベルおよび新規登
録トランザクションの設定に基づいて一貫性管理方法お
よび新規登録を実行する手順を示すフローチャートであ
る。

【０１２０】まず、図９（ａ）に示すように、トランザ
クションの種類に応じて一貫性管理のレベルを設定し
（実施の形態１参照）、かつ、データの新規登録のため
のトランザクションを新規登録トランザクションとして
設定する（Ｓ９００）。

【０１２１】図９（ａ）のステップＳ９００で新規登録
トランザクションについての一貫性管理レベルを設定し
た後、図９（ｂ）に示すように、分散型データベースシ
ステム内にトランザクションが発生すると（Ｓ９０
１）、発生したトランザクションに設定されている一貫
性管理のレベルの判定処理およびトランザクションが新
規登録トランザクションか否かの判定処理を実行する
（Ｓ９０２：本発明の判定工程に該当する）。

【０１２２】そして、ステップＳ９０２において、トラ
ンザクションが新規登録トランザクションであると判定
した場合、設定されているレベルに関係なく、レベルＣ
と判定する（Ｓ９０３：本発明の判定工程に該当す
る）。そして、ステップＳ９０６に進み、レベルＣの一
貫性管理方法を実行する。

【０１２３】なお、レベルＣで新規登録トランザクショ
ンを実行する場合においては、他のサイトＤＢＳにおけ
るトランザクションとの競合の可能性がないことから、
承認リクエストメッセージを用いた競合のチェックは省
略される。

【０１２４】このように、実施の形態２に係る分散型デ
ータベースシステムの一貫性管理方法によれば、データ
の新規登録を行うためのトランザクションを実行する場
合において、他のトランザクションとの競合をチェック
する処理を省略することにしたため、データを新規登録
する際の処理効率を向上させることができる。

【０１２５】ただし、ＩＮＳＥＲＴ操作の中には既存の
データと意味的に関連付けられているものがある。例え
ば、ｒｅａｄした２つの値の平均値を求め、その値を使
ってＩＮＳＥＲＴするようなトランザクションの場合で
ある。このような場合には、既存のデータと意味的に関
連があるため、そのトランザクションは新規登録トラン
ザクションではない。

【０１２６】〔実施の形態３〕上述したレベルＢおよび
レベルＣの一貫性管理方法においては、主サイトＤＢＳ
_P に予め設定された差異限定制約条件が満足された場合
に、主サイトＤＢＳ_Pから各サイトＤＢＳに対して更新
情報を送信し、更新伝播を行うことにしている（図７参
照）。実施の形態３においては、更新伝播を行うタイミ
ングとして、主サイトＤＢＳ_P に設定された差異限定制
約条件が満足された場合に加え、トランザクションが発
生したサイトＤＢＳ側でコンテンツの内容に応じて更新
伝播を行うタイミングを設定することができるようにす
る。このようにするのは、コンテンツによっては早期に
公開すべきものや多少公開が遅れても良いとされるもの
があり、例えば、台風情報等のように早期に公開すべき
情報については５分以内に全てのサイトＤＢＳに更新伝
播を完了したいという要請に答えることができるように
するためである。

【０１２７】図１０は、本発明の実施の形態３に係る分
散型データベースシステムの一貫性管理方法を実現する
ための分散型データベースシステムの概念構成図であ
る。図１０に示す分散型データベースシステムは、図２
に示した構成に加えて、更新伝播を行う際に、衛星１０
００を用いた放送を利用して主サイトＤＢＳ_P から各サ
イトＤＢＳに更新情報を配信できるようにしたものであ
る。一般に衛星１０００等を利用して情報を配信するこ
とは例えばインターネットを利用する場合と比べてコス
トが高いが、緊急に全てのサイトＤＢＳに更新伝播を行
いたい場合等において放送により更新情報を配信するこ
とにより、全てのサイトＤＢＳに対して更新情報を短時
間にかつ一度に配信することができるという利点があ
る。

【０１２８】なお、図１０において、１００１ａ〜１０
０１ｅは、放送波を用いて更新情報を送信または受信す
るためのアンテナを、１００２は実施の形態１および２
で既に説明した各種情報を送受信するための通信回線を
それぞれ示している。

【０１２９】また、図１０には、衛星１０００を用いた
放送により情報やり取りを行うことができる分散型デー
タベースシステムを一例として示したが、これに加え
て、または代えて地上波等、情報を送信可能な他の手段
を用いることにしても良い。

【０１３０】次に、実施の形態３に係る分散型データベ
ースシステムの一貫性管理方法について、サイトＤＢＳ
₁ でレベルＣの一貫性管理方法が設定されたトランザク
ションが発生した場合を例にとって説明する。なお、こ
こではレベルＣの場合について説明するが、レベルＢの
場合にも同様に適用できることは明らかである。また、
実施の形態１および２で既に説明した事項については、
簡単に説明することにする。

【０１３１】図１１は、更新伝播タイミング設定処理を
示すフローチャートである。サイトＤＢＳ１のユーザ
は、複製データの更新を行う際に、例えば、予め用意さ
れた入力欄等に以下に説明する情報を設定する（Ｓ１１
０１）。

【０１３２】ステップＳ１１０１においては、緊急度，
公開指定日時，伝播遅延許容日時，伝播方式が設定され
るものとする。緊急度には例えば以下のようなレベルが
あり、これらのレベルは予めシステム構築者が設定す
る。したがって、ユーザは設定されている緊急度レベル
の中から所望のレベルを選択し、緊急度の項目に設定す
るすることになる。

【０１３３】 ・緊急度１：１０分以内に更新伝播を行う。 ・緊急度２：６０分以内に更新伝播を行う。 ・緊急度３：１日以内に更新伝播を行う。 ・緊急度４：３日以内に更新伝播を行う。

【０１３４】公開指定日時の項目は、例えば報道ニュー
ス等には明朝１０時までは情報を公開してはならないと
いう要求があることから設けられたものである。したが
って、ユーザはこの項目に対して所望の日時を設定す
る。なお、この公開指定日時が指定された場合、主サイ
トＤＢＳ_P は、公開指定日時が経過した後に更新された
複製データに関する情報について更新伝播を行うように
する。また、これに代えて、公開指定日時の経過前に更
新伝播を行うことにしても良い。いずれを用いるかにつ
いては、後述する更新伝播のスケジュールを設定する際
（図１３のステップＳ１３０４参照）に決定すれば良
い。ただし、公開指定日時の経過前に更新伝播を行うこ
とにする場合、各サイトＤＢＳにおいて公開指定日時が
経過する前に該当する更新後のデータを公開しないよう
にする手法を確立しておくことが必要となる。

【０１３５】伝播遅延許容日時の項目には、更新伝播の
遅れが許される最大限の日時を設定する。

【０１３６】さらに、配信方式の項目には、通信（通信
回線１００２を用いる），衛星放送，地上波放送等のい
ずれの方式を用いて更新伝播を行うかを設定する。

【０１３７】そして、ここではレベルＣであるため、サ
イトＤＢＳ１においてトランザクションをコミットする
かアボートするかが判定され、コミットの場合はサイト
ＤＢＳ₁ の該当する複製データが更新される。なお、実
施の形態２で説明した新規登録トランザクションの場合
には、他のトランザクションとの競合のチェック処理は
省略される。

【０１３８】コミットの場合、サイトＤＢＳ₁ は、上述
したように承認リクエストメッセージを主サイトＤＢＳ
_P に通信回線１００２を介して送信するが、その際、図
１２（ａ）および図１２（ｂ）に例として示すデータを
承認リクエストメッセージ（図４に示したＲＥＱＵＥＳ
Ｔメッセージと同一内容：レベルＢの場合も同様）に添
付する。その結果、図１１のステップＳ１１０１で設定
した緊急度等は、属性値として承認リクエストメッセー
ジに設定されることになる。

【０１３９】主サイトＤＢＳ_P は、サイトＤＢＳ₁ から
承認リクエストメッセージを受信すると、他のサイトＤ
ＢＳで行われた更新処理と競合しないか否かを判定し、
競合しないと判定した場合は以下の更新伝播管理処理を
実行する。なお、新規登録トランザクションの場合は競
合のチェック処理は省略される。また、競合のチェック
処理と並行して更新伝播管理処理を実行することにして
も良いが、他のサイトの更新処理と競合すると判定され
た場合は更新伝播管理処理を途中で終了することにな
る。

【０１４０】図１３は、主サイトＤＢＳ_P による更新伝
播管理処理を示すフローチャートである。主サイトＤＢ
Ｓ_P は、サイトＤＢＳ₁ から受信した承認リクエストメ
ッセージから依頼元ＩＤ（サイトＩＤ），依頼日時，更
新ＯＩＤリスト，緊急度，公開指定日時，更新遅延許容
日時および配信方式をコピーし（Ｓ１３０１）、さら
に、依頼到着日時（主サイトＤＢＳ_P が承認リクエスト
メッセージを受信した日時），データサイズ（送るべき
データのサイズ）を計測・設定し（Ｓ１３０２）、図１
４に示すような更新伝播管理情報を生成する。この更新
伝播管理情報は、課金のためのデータとして利用するこ
とができる。

【０１４１】なお、ステップＳ１３０２において、承認
リクエストメッセージに伝播遅延許容日時が設定されて
いない場合には、 依頼到着日時＋指定された緊急度の許容時間（緊急度１
なら１０分） という計算を行い、伝播遅延許容日時を設定する。

【０１４２】更新伝播管理情報を生成した後、主サイト
ＤＢＳ_P は、指定された緊急度が許容可能か否かについ
て、以下の基準に基づいて判定する（Ｓ１３０３）。

【０１４３】 ・［依頼到着日時＋指定された緊急度の許容時間］＞伝
播遅延許容日時の場合 ・［公開指定日時＋指定された緊急度の許容時間］＞伝
播遅延許容日時の場合 ・（データサイズ×送付サイト数）の値が大きすぎる場
合 なお、ここで、送付サイト数は、例えばサイトＤＢＳ₁
が更新を行った複製データ（オブジェクト）と同一のオ
ブジェクトに対する複製データを有する他のサイトＤＢ
Ｓの数であり、どのサイトＤＢＳが送付サイトに該当す
るかは主サイトＤＢＳ_P が判断する。

【０１４４】更新伝播管理情報中の値が上記３つの条件
の少なくとも一つを満たすような場合、主サイトＤＢＳ
_P は、指定された緊急度が許容可能ではないと判定し、
許容不可能メッセージを生成してサイトＤＢＳ₁ （依頼
元のサイト）に送信し、図１２に示したデータのみを再
度送信するように要求する（Ｓ１３０７）。

【０１４５】そして、サイトＤＢＳ₁ （依頼元のサイ
ト）からメッセージに対する応答として図１２に示した
データが送信され、そのデータを受信した場合（Ｓ１３
０８）、主サイトＤＢＳ_P はステップＳ１３０１に戻っ
て再度更新伝播管理処理を実行する。

【０１４６】一方、ステップＳ１３０３において、指定
された緊急度が許容可能と判定した場合、主サイトＤＢ
Ｓ_P は、更新伝播管理情報中の更新遅延許容日時より前
に更新情報を各サイトＤＢＳに配信できるように、更新
伝播を行うスケジュールを設定する（Ｓ１３０４）。例
えば、主サイトＤＢＳ_P は、実施の形態１で説明した差
異限定制約条件を用いて更新伝搬を行うスケジュールを
設定する。いずれの差異限定制約条件を用いるかについ
ては、例えば、図１４に示した更新伝播管理情報中の伝
播遅延許容日時に更新伝播が間に合うことを第１の基準
とし、これに加えて更新伝播のコストが低いものはどれ
かを第２の基準として判断する。そして、主サイトＤＢ
Ｓ_P は、選択した差異限定制約条件を用いて更新伝播を
行うスケジューリングを行い、伝播遅延許容日時を守れ
るか否かを判定し、守れないと判定した場合には、より
早い時期に更新伝播を行うことができる差異限定制約条
件を用いて再度更新伝播を行うスケジューリングを行
う。換言すれば、更新遅延伝播ルールとして各種の差異
限定制約条件があるが、指定された緊急度を守ることが
できない可能性がある差異限定制約条件は採用しないこ
とにする。

【０１４７】その後、主サイトＤＢＳ_P は、ステップＳ
１３０４で設定したスケジュールに従い、更新伝播を実
行する（Ｓ１３０５）。更新伝播は、更新伝播管理情報
中に設定されている配信方式に従って更新情報を各サイ
トＤＢＳに配信する。例えば、配信方式として「衛星」
が設定されている場合は、衛星１０００を用いて放送に
より更新情報を各サイトＤＢＳに配信する。また、配信
方式として「通信」が設定されている場合は、通信回線
１００２を介して更新情報を各サイトＤＢＳに配信す
る。なお、通信回線１００２を介して更新情報を各サイ
トＤＢＳに配信する場合、承認リクエストメッセージを
送信して来たサイトＤＢＳ（ここではサイトＤＢＳ₁ ）
に対しては、通信コストを下げるために更新情報の配信
は行わないようにする。

【０１４８】そして、主サイトＤＢＳ_P は、更新伝播の
開始日時および完了日時のログと配信の遅れに関する情
報とを更新伝播管理情報中に設定する（Ｓ１３０６）。
配信の遅れに関する情報とは、更新伝播管理情報中の伝
播遅延許容日時からどれくらい遅れて配信されたかを示
し、 伝播完了日時−伝播遅延許容日時 で計算される。計算した結果が正の場合は、伝播遅延許
容日時から遅れて更新伝播が行われたことを示し、その
値を更新伝播管理情報中の「配信の遅れ」に設定する。
一方、計算した結果が負の場合は、伝播遅延許容日時の
前に更新伝播が完了したことを示し、負の場合は配信の
遅れは生じていないため、「０」を更新伝播管理情報中
の「配信の遅れ」に設定する。

【０１４９】このように、実施の形態３に係る分散型デ
ータベースシステムの一貫性管理方法によれば、コンテ
ンツの内容に適したタイミングで更新結果を各サイトＤ
ＢＳに配信することができるため、分散型データベース
システムの利便性の向上を図ることができる。

【０１５０】また、更新結果を各サイトＤＢＳに配信す
る方法として、衛星１０００を用いた放送による配信方
法や通信回線１００２を用いた通信による配信方法等を
選択することができるため、緊急度に応じて適切な配信
方法を選択でき、分散型データベースシステムの利便性
の向上を図ることができる。

【０１５１】なお、詳細な説明については省略するが、
レベルＡの場合においても、放送により図４に示したコ
ミットを配信することにしても良い。

【０１５２】以上説明した実施の形態１〜３に係る分散
型データベースシステムにおいては、トランザクション
の種類毎に一貫性管理レベルについてレベルＡ〜Ｃのい
ずれかを設定し、設定したレベルで一貫性管理を行うこ
とにしたが、例えば、レベルＣの一貫性管理レベルのみ
が利用可能なシステムやレベルＡおよびレベルＣの一貫
性管理レベルが利用可能なシステム等、分散型データベ
ースシステムをどのように運用するかによって、様々な
設計・変更が可能なことは明らかである。

【０１５３】また、実施の形態１〜３に係る分散型デー
タベースシステムの一貫性管理方法は、図３〜図５なら
びに図１１および図１３に示したフローチャートの手順
に従って、予め用意されたプログラムをコンピュータで
実行することによって実現される。このプログラムは、
ハードディスク，フロッピーディスク，ＣＤ−ＲＯＭ，
ＭＯ，ＤＶＤ等のコンピュータで読み取り可能な記録媒
体に記録され、コンピュータによって記録媒体から読み
出されることによって実行可能である。また、このプロ
グラムは、上記記録媒体を介して、またはネットワーク
を介して配布することができる。

【０１５４】〔適用可能な応用分野〕以上説明した実施
の形態１〜３に係る分散型データベースシステムの一貫
性管理方法は、以下に説明するような応用分野に適用す
ることができる。ただし、本発明の分散型データベース
システムの一貫性管理方法を適用する応用分野を以下に
説明するものに限定するものではない。

【０１５５】本発明の分散型データベースシステムの一
貫性管理方法は、（１）マルチメディアのコンテンツを
提供し、その視聴に対して課金を行うシステムであり、
（２）コンテンツの更新には時間的遅れを許し、（３）
システム内に構築されるＤＢ（データベース）として
は、コンテンツＤＢ・インデックス情報ＤＢ（２次情
報）・利用者統計情報ＤＢ・課金情報ＤＢという種類を
有する分散型データベースシステムに適用することがで
きる。

【０１５６】上記ＤＢの特徴としては、以下のように考
えられる。まず、コンテンツＤＢとしては、（１）デー
タのサイズが超大で、データはマルチメディアのＢＬＯ
Ｂ（Ｂｉｎａｒｙ Ｌａｒｇｅ Ｏｂｊｅｃｔ）であ
り、（２）複製データが多数必要であり（コンテンツが
マルチメディアであるため、サイズが大きく、アクセス
コストを下げるためには複製データを多数生成すること
が必要）、（３）読み出す情報は多少古くても良く、
（４）読み出し頻度は大であるものである。（５）更新
伝播は遅延しても良い、というものが考えられる。

【０１５７】インデックス情報ＤＢとしては、（１）複
製データは多数必要であり、（２）複製データデータの
サイズは小〜中であり、（３）読み出す情報は多少古く
ても良く、（４）読み出し頻度は大で、（５）更新伝播
は遅延しても良い、というものが考えられる。

【０１５８】利用者統計情報ＤＢおよび課金情報ＤＢと
しては、（１）複製データの数は少なくても良く、
（２）データのサイズはシステムに依存し、（３）読み
出す情報は多少古くても良く、（４）読み出し頻度は小
であり、（５）更新伝播は遅延しても良く、集計する側
への伝播は遅延しても良い、というものが考えられる。
ただし、利用者情報は紛失してもあまり問題とならない
が、更新中に課金情報が紛失または欠落することは許さ
れない。

【０１５９】上記分散型データベースシステムにおいて
発生する典型的なトランザクションとしては、（１）利
用者によるコンテンツ検索（アクセス頻度大）、（２）
コンテンツ提供者によるコンテンツの新規追加および修
正（更新頻度は小）、（３）コンテンツ提供者によるイ
ンデックス情報の新規追加および修正（更新頻度は
小）、（４）課金情報の収集（各利用者に対する課金収
集は頻度が小さいが、利用者数が膨大であるため、大き
くなる）、および、（５）利用統計情報の収集（各利用
者に対する課金収集は頻度が小さいが、利用者数が膨大
であるため、大きくなる）、が考えられる。

【０１６０】上記条件を満たすシステム例としては、
（１）電子図書館システム（コンテンツは書籍，雑誌，
ＣＤ−ＲＯＭ，ビデオ等。インデックス情報は書誌情
報。）、（２）ビデオ・オン・デマンド（ＶＯＤ）シス
テム（コンテンツはビデオ。インデックス情報はビデオ
の各種属性。）、（３）カラオケシステム（コンテンツ
はＭＩＤＩ等の音楽情報，動画情報および歌詞の文字情
報等。インデックス情報は曲に関する各種属性。）、等
が考えられる。

【０１６１】

【発明の効果】以上説明したように、本発明の分散型デ
ータベースシステムの一貫性管理方法（請求項１）によ
れば、予め複製データに対するリードまたは更新を含む
各トランザクションの種類に、一貫性管理のレベルを表
す第１レベル，第２レベルおよび第３レベルのいずれか
を設定する一貫性レベル設定工程と、システム内におい
てトランザクションが発生した場合に、発生したトラン
ザクションの種類に基づいて、一貫性管理のレベルを判
定する判定工程と、判定工程で第１レベルであると判定
された場合に、厳格な一貫性管理方法を用いて一貫性管
理を行い、かつ、第２のサイトから複数の第１のサイト
への更新伝播を即時行う第１の一貫性管理工程と、判定
工程で第２レベルであると判定された場合に、厳格な一
貫性管理方法を用いて一貫性管理を行い、かつ、第２の
サイトから複数の第１のサイトへの更新伝播を遅延させ
て行う第２の一貫性管理工程と、判定工程で第３レベル
であると判定された場合に、弱い一貫性管理方法を用い
て一貫性管理を行い、かつ、第２のサイトから複数の第
１のサイトへの更新伝播を遅延させて行う第３の一貫性
管理工程と、を含むことにより、トランザクションの種
類に応じて最適なレベルの一貫性管理を行うことができ
るため、分散型データベースシステムの利便性の向上を
図ることができる。

【０１６２】また、本発明の分散型データベースシステ
ムの一貫性管理方法（請求項２）によれば、予め複製デ
ータに対するリードまたは更新を含む各トランザクショ
ンの種類に、一貫性管理のレベルを表す第１レベル，第
２レベルおよび第３レベルのいずれかを設定する一貫性
レベル設定工程と、システム内においてトランザクショ
ンが発生した場合に、発生したトランザクションの種類
に基づいて、一貫性管理のレベルを判定する判定工程
と、判定工程で第１レベルであると判定された場合に、
ｒｅａｄ−ｏｎｌｙのトランザクションまたは更新を含
むトランザクションのいずれであっても、厳格な一貫性
管理方法を用いて一貫性管理を行い、第２のサイトから
複数の第１のサイトへの更新伝播を即時行う第１の一貫
性管理工程と、判定工程で第２レベルであると判定され
た場合に、ｒｅａｄ−ｏｎｌｙのトランザクションは緩
和された一貫性管理方法を用いて一貫性管理を行い、更
新を含むトランザクションは厳格な一貫性管理方法を用
いて一貫性管理を行い、第２のサイトから複数の第１の
サイトへの更新伝播を遅延させて行う第２の一貫性管理
工程と、判定工程で第３レベルであると判定された場合
に、ｒｅａｄ−ｏｎｌｙのトランザクションまたは更新
を含むトランザクションのいずれであっても、弱い一貫
性管理方法を用いて一貫性管理を行い、第２のサイトか
ら複数の第１のサイトへの更新伝播を遅延させて行う第
３の一貫性管理工程と、を含むことにより、トランザク
ションの種類に応じて最適なレベルの一貫性管理を行う
ことができるため、分散型データベースシステムの利便
性の向上を図ることができる。

【０１６３】また、本発明の分散型データベースシステ
ムの一貫性管理方法（請求項３）によれば、請求項１ま
たは２に記載の分散型データベースシステムの一貫性管
理方法において、第２および第３の一貫性管理工程にお
ける更新伝播の遅延について、第２のサイトにおいて予
め設定されている更新伝播条件が満足された場合に更新
伝播を行うこととしたことにより、更新が起こる毎に更
新伝播を行う必要をなくすことができるため、データの
一貫性保持のコストを削減することができる。

【０１６４】また、本発明の分散型データベースシステ
ムの一貫性管理方法（請求項４）によれば、請求項１〜
３のいずれか一つに記載の分散がデータベースシステム
の一貫性管理方法において、第２および／または第３の
一貫性管理工程における更新伝播の遅延とは、第１のサ
イトにおいてトランザクション毎に更新伝播を行うタイ
ミングを定めた更新伝播条件が設定され、第２のサイト
において更新伝播条件を満足するように複数の第１のサ
イトへの更新伝播を行うこととしたため、ユーザの所望
の更新伝播条件を設定することができる。したがって、
ユーザの所望の更新伝播条件を設定することができるた
め、更新伝播がいつ行われるかを容易に予測することが
でき、分散型データベースシステムの利便性のさらなる
向上を図ることができる。

【０１６５】また、本発明の分散型データベースシステ
ムの一貫性管理方法（請求項５）によれば、請求項４に
記載の分散型データベースシステムの一貫性管理方法に
おいて、第２および／または第３の一貫性管理工程が、
少なくとも通信回線および放送波を用いて第２のサイト
から複数の第１のサイトへの更新伝播を行うことがで
き、更新伝播条件が、通信回線および放送波のいずれを
用いて更新伝播を行うかについての指定を含むことによ
り、更新伝播条件に応じて適切な方法で更新伝播を行う
ことができるため、分散型データベースシステムの利便
性の向上を図ることができる。すなわち、緊急に更新伝
播を行う必要がある場合にはコストが高くても放送波を
用いて更新伝播を行うことにし、時間的に余裕がある場
合にはコストを抑えて通信回線を用いて更新伝播を行う
という選択を行うことができる。

【０１６６】また、本発明の分散型データベースシステ
ムの一貫性管理方法（請求項６）によれば、請求項１〜
５のいずれか一つに記載の分散型データベースシステム
の一貫性管理方法において、判定工程が、一貫性管理の
レベルを判定することに加えて、データの新規登録か否
かを判定し、新規登録であると判定した場合に、設定さ
れているレベルに関係なく、第３レベルと判定するた
め、データを新規登録する際の処理効率を向上させるこ
とができる。

【０１６７】さらに、本発明のコンピュータ読み取り可
能な記録媒体（請求項７）によれば、請求項１〜６のい
ずれか一つに記載の分散型データベースシステムの一貫
性管理方法の各工程をコンピュータに実行させるための
プログラムを記録したため、このプログラムをコンピュ
ータに実行させることにより、分散型データベースシス
テムの一貫性管理のレベルを複数段階に分け、トランザ
クションの種類に応じて異なる一貫性管理を行うことが
でき、分散型データベースシステムの利便性の向上を図
ることができる。

【図面の簡単な説明】

【図１】集中管理または分散管理と、強い一貫性管理ま
たは弱い一貫性管理との組み合わせによって、分散型デ
ータベースシステムを構築した場合の長所および短所が
変化することを示した説明図である。

【図２】本発明の実施の形態１に係る分散型データベー
スシステムの一貫性管理方法を実現するための分散型デ
ータベースシステムの概念構成図である。

【図３】本発明の実施の形態１に係る分散型データベー
スシステムの一貫性管理方法において、（ａ）は一貫性
管理のレベルを設定する手順を、（ｂ）は（ａ）に示す
ようにして設定した一貫性管理のレベルに基づいて一貫
性管理方法を実行する手順を示すフローチャートであ
る。

【図４】本発明の実施の形態１に係る分散型データベー
スシステムの一貫性管理方法において、各サイトから主
サイトに送信されるＲＥＱＵＥＳＴメッセージの説明図
である。

【図５】本発明の実施の形態１に係る分散型データベー
スシステムの一貫性管理方法において、主サイトから各
サイトに送信されるコミットメッセージの説明図であ
る。

【図６】本発明の実施の形態１に係る分散型データベー
スシステムの一貫性管理方法において、主サイトから各
サイトに送信されるアボートメッセージの説明図であ
る。

【図７】本発明の実施の形態１に係る分散型データベー
スシステムの一貫性管理方法において、（ａ）は差異限
定制約条件を設定する手順を、（ｂ）は（ａ）に示すよ
うにして設定した差異限定制約条件に基づいて更新伝播
を行う手順を示すフローチャートである。

【図８】本発明の実施の形態１に係る分散型データベー
スシステムの一貫性管理方法において、一貫性管理のレ
ベルＡ〜Ｃの特徴をまとめた説明図である。

【図９】本発明の実施の形態２に係る分散型データベー
スシステムの一貫性管理方法において、（ａ）は一貫性
管理のレベルおよび新規登録トランザクションを設定す
る手順を、（ｂ）は（ａ）に示すようにして設定した一
貫性管理のレベルおよび新規登録トランザクションの設
定に基づいて一貫性管理方法および新規登録を実行する
手順を示すフローチャートである。

【図１０】本発明の実施の形態３に係る分散型データベ
ースシステムの一貫性管理方法を実現するための分散型
データベースシステムの概念構成図である。

【図１１】本発明の実施の形態３に係る分散型データベ
ースシステムの一貫性管理方法において、更新伝播タイ
ミング設定処理を示すフローチャートである。

【図１２】本発明の実施の形態３に係る分散型データベ
ースシステムの一貫性管理方法において、更新伝播タイ
ミングをサイト側で設定する場合に、リクエストメッセ
ージに添付されるデータを示す説明図である。

【図１３】本発明の実施の形態３に係る分散型データベ
ースシステムの一貫性管理方法において、主サイトによ
る更新伝播管理処理を示すフローチャートである。

【図１４】本発明の実施の形態３に係る分散型データベ
ースシステムの一貫性管理方法において、主サイトによ
って管理される更新伝播管理情報の一例を示す説明図で
ある。

【符号の説明】

ＤＢＳ_P 主サイト ＤＢＳ₁ ，ＤＢＳ₂ ，ＤＢＳ₃ ，・・・，ＤＢＳ_n
サイト １０００ 衛星 １００１ａ〜１００１ｅ アンテナ １００２ 通信回線

───────────────────────────────────────────────────── フロントページの続き (51)Int.Cl.⁶ 識別記号 ＦＩ Ｇ０６Ｆ 15/401 ３４０Ａ (72)発明者 前田 薫 東京都大田区中馬込１丁目３番６号 株式 会社リコー内 (72)発明者 池田 哲也 東京都大田区中馬込１丁目３番６号 株式 会社リコー内

Claims (7)

【特許請求の範囲】
1. 【請求項１】 任意のオブジェクトに対する複製データ
   をそれぞれ有する第１のサイトと、前記複数の第１のサ
   イトにおける複製データの一貫性を集中管理する第２の
   サイトと、を備えた分散型データベースシステムの一貫
   性管理方法において、 予め前記複製データに対するリードまたは更新を含む各
   トランザクションの種類に、一貫性管理のレベルを表す
   第１レベル，第２レベルおよび第３レベルのいずれかを
   設定する一貫性レベル設定工程と、 システム内においてトランザクションが発生した場合
   に、発生したトランザクションの種類に基づいて、前記
   一貫性管理のレベルを判定する判定工程と、 前記判定工程で第１レベルであると判定された場合に、
   厳格な一貫性管理方法を用いて一貫性管理を行い、か
   つ、第２のサイトから複数の第１のサイトへの更新伝播
   を即時行う第１の一貫性管理工程と、 前記判定工程で第２レベルであると判定された場合に、
   厳格な一貫性管理方法を用いて一貫性管理を行い、か
   つ、第２のサイトから複数の第１のサイトへの更新伝播
   を遅延させて行う第２の一貫性管理工程と、 前記判定工程で第３レベルであると判定された場合に、
   弱い一貫性管理方法を用いて一貫性管理を行い、かつ、
   第２のサイトから複数の第１のサイトへの更新伝播を遅
   延させて行う第３の一貫性管理工程と、 を含むことを特徴とする分散型データベースシステムの
   一貫性管理方法。
2. 【請求項２】 任意のオブジェクトに対する複製データ
   をそれぞれ有する第１のサイトと、前記複数の第１のサ
   イトにおける複製データの一貫性を集中管理する第２の
   サイトと、を備えた分散型データベースシステムの一貫
   性管理方法において、 予め前記複製データに対するリードまたは更新を含む各
   トランザクションの種類に、一貫性管理のレベルを表す
   第１レベル，第２レベルおよび第３レベルのいずれかを
   設定する一貫性レベル設定工程と、 システム内においてトランザクションが発生した場合
   に、発生したトランザクションの種類に基づいて、前記
   一貫性管理のレベルを判定する判定工程と、 前記判定工程で第１レベルであると判定された場合に、
   ｒｅａｄ−ｏｎｌｙのトランザクションまたは更新を含
   むトランザクションのいずれであっても、厳格な一貫性
   管理方法を用いて一貫性管理を行い、第２のサイトから
   複数の第１のサイトへの更新伝播を即時行う第１の一貫
   性管理工程と、 前記判定工程で第２レベルであると判定された場合に、
   ｒｅａｄ−ｏｎｌｙのトランザクションは緩和された一
   貫性管理方法を用いて一貫性管理を行い、更新を含むト
   ランザクションは厳格な一貫性管理方法を用いて一貫性
   管理を行い、第２のサイトから複数の第１のサイトへの
   更新伝播を遅延させて行う第２の一貫性管理工程と、 前記判定工程で第３レベルであると判定された場合に、
   ｒｅａｄ−ｏｎｌｙのトランザクションまたは更新を含
   むトランザクションのいずれであっても、弱い一貫性管
   理方法を用いて一貫性管理を行い、第２のサイトから複
   数の第１のサイトへの更新伝播を遅延させて行う第３の
   一貫性管理工程と、 を含むことを特徴とする分散型データベースシステムの
   一貫性管理方法。
3. 【請求項３】 前記第２および第３の一貫性管理工程に
   おける更新伝播の遅延とは、第２のサイトにおいて予め
   設定されている更新伝播条件が満足された場合に更新伝
   播を行うことであることを特徴とする請求項１または２
   に記載の分散型データベースシステムの一貫性管理方
   法。
4. 【請求項４】 前記第２および／または第３の一貫性管
   理工程における更新伝播の遅延とは、前記第１のサイト
   において前記トランザクション毎に更新伝播を行うタイ
   ミングを定めた更新伝播条件が設定され、第２のサイト
   において前記更新伝播条件を満足するように複数の第１
   のサイトへの更新伝播を行うことであることを特徴とす
   る請求項１〜３のいずれか一つに記載の分散がデータベ
   ースシステムの一貫性管理方法。
5. 【請求項５】 前記第２および／または第３の一貫性管
   理工程は、少なくとも通信回線および放送波を用いて第
   ２のサイトから複数の第１のサイトへの更新伝播を行う
   ことができ、 前記更新伝播条件は、前記通信回線および放送波のいず
   れを用いて更新伝播を行うかについての指定を含むこと
   を特徴とする請求項４に記載の分散型データベースシス
   テムの一貫性管理方法。
6. 【請求項６】 前記判定工程は、前記一貫性管理のレベ
   ルを判定することに加えて、データの新規登録か否かを
   判定し、前記新規登録であると判定した場合に、設定さ
   れているレベルに関係なく、前記第３レベルと判定する
   ことを特徴とする請求項１〜５のいずれか一つに記載の
   分散型データベースシステムの一貫性管理方法。
7. 【請求項７】 前記請求項１〜６のいずれか一つに記載
   の分散型データベースシステムの一貫性管理方法の各工
   程をコンピュータに実行させるためのプログラムを記録
   したことを特徴とするコンピュータ読み取り可能な記録
   媒体。