JP4402891B2 - データベースシステム - Google Patents
データベースシステム Download PDFInfo
- Publication number
- JP4402891B2 JP4402891B2 JP2003041587A JP2003041587A JP4402891B2 JP 4402891 B2 JP4402891 B2 JP 4402891B2 JP 2003041587 A JP2003041587 A JP 2003041587A JP 2003041587 A JP2003041587 A JP 2003041587A JP 4402891 B2 JP4402891 B2 JP 4402891B2
- Authority
- JP
- Japan
- Prior art keywords
- data
- user
- database
- time
- update
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Landscapes
- Storage Device Security (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、データベースシステムに関し、特に、複数の部門のユーザによるデータの連続的な参照・更新を許容するデータベースシステムに関する。
【０００２】
【従来の技術】
従来、データベース（以下、ＤＢと称す）の最新データに対して複数の異なる部門に属するユーザがそれぞれ独立して連続アクセスによる更新処理を行い、その更新内容をそれぞれあるタイミングで他の部門に公開して、互いのデータをマージするには、各部門用のＤＢをそれぞれ用意し、あるタイミングでＤＢのサービスを一時的に停止し、バッチ処理によってマージを行っていた。その際、マージ処理において、データの主キー属性の一意性など制約条件を保持することは障害の一つとなっていた。
【０００３】
連続無停止のデータベース管理システム（以下、ＤＢＭＳと称す）においてＤＢの内容を更新する方法として、特許文献１に記載のように、ＤＢの更新要求に対しては直ちに対象情報を更新する一方、更新前の情報を時系列情報とともに保持しておき、検索要求に対しては、時系列情報に基づいて該当時点の情報を検索する方法があった。過去のある時点のＤＢの内容に対して更新処理を行う場合には、従来は、ある時点においてＤＢの内容を別ファイルにコピーして、それを更新していた。一方、特許文献２には、ＤＢの記憶領域を、最新データを記憶するためのエリアと、過去のデータを記憶するためのエリアと、過去のデータを更新したデータを記憶するためのエリアとに分割し、それぞれのエリアに目的別のデータを保存しておくことによって、別ファイルにコピーすることなく過去のある時点のＤＢの内容を更新せしめるＤＢＭＳが記載されている。
【０００４】
【特許文献１】
特開平６−３５７７４号公報
【特許文献２】
特開平１０−１４３４１１号公報
【０００５】
【発明が解決しようとする課題】
特許文献１に記載の技術では、過去のある時点のＤＢの内容に対するデータの検索を行うことは可能であるが、過去のデータを直接更新することはできない。また、特許文献２に記載の技術では、過去のデータに対して、複数の異なる部門に属するユーザが連続アクセスによって更新処理を行うことは可能であるが、それぞれの部門で更新されたデータを効率よく他の部門に対して公開することはできない。加えて、特許文献２に記載の技術では、最新データは常に通常業務を行う各ユーザに対して公開されることになるため、複数の異なる部門に属するユーザがそれぞれ最新データを作成し、しかもそれぞれのデータを他の部門に対して一定期間隠蔽したいというような場合には、効率的な対応はできない。
【０００６】
本発明は、このような従来技術の問題点に鑑み、ある時点のデータベースの内容を別ファイルにコピーすることなく、異なる複数の部門に属するユーザが最新データに対する更新処理を行う上で、更新内容を他の部門に属するユーザに対して任意期間隠蔽可能なデータベースシステムを提供することを目的とする。
【０００７】
【課題を解決するための手段】
上記目的を達成するために、本発明では、データベースにおいては、データを登録したユーザが他のユーザ群にそのデータを公開する時刻を記憶するための記憶領域と、他のユーザ群によるデータ更新内容を自ユーザ用のデータに反映させるか否かという設定情報（自分のデータに他ユーザによる干渉を許すか否かという意味で、干渉許可設定と称す）を記憶するための記憶領域とを備え、データベース管理システムにおいては、自ユーザに対して公開されているデータを読み出す手段と、データの公開時刻とともにデータをデータベースの記憶領域に書き込む手段と、キー属性の一意性制約などの制約条件が、公開されているデータのみならず、未公開データをも含めて満たされることを検証する手段（制約条件検証手段）と、前述の干渉許可設定を更新する手段とを有することを特徴とする。
【０００８】
更に、本発明は、前述の制約条件を検証する手段などを実現するために、データの公開・未公開に関係なく全てのデータを対象としてデータを検索する手段を有することを特徴とする。また、検索効率を向上させ、同時にデータベースの記憶領域の容量を節約し、結果としてシステム全体のパフォーマンス向上を図るために、新しいデータが全てのユーザに対して公開されたことによって、どのユーザからも参照されることが無くなった過去のデータ（不要データと称す）をデータベースの記憶領域から削除する手段（不要データ削除手段と称す）を有することを特徴とする。
【０００９】
すなわち、本発明によるデータベースシステムは、データを記憶するデータベース及びデータベースを管理するデータベース管理システムを含むデータベースシステムにおいて、データベースは、データ及び当該データをユーザに対して公開する公開時刻の情報を記憶していることを特徴とする。
【００１０】
公開時刻の情報は、複数のユーザ群のそれぞれに対して記憶している。また、公開時刻の情報は、各データを格納するレコードのヘッダ部分に記憶することができる。
【００１１】
データベースは、また、第１のユーザによるデータの更新内容を第１のユーザと異なる第２のユーザ用のデータに反映させるか否かの干渉許可の情報を記憶することもできる。この干渉許可はデータ単位で設定することもできるし、複数のデータを含むテーブル単位で設定することもできる。干渉許可の設定が第１のユーザによるデータの変更内容を第２のユーザ用のデータに反映させることを許可していないとき、データベース管理システムは、第１のユーザが更新したデータの第２のユーザへの公開時刻として実用上無限の未来を表す時刻を設定する。
【００１２】
データベース管理システムは、データベースにアクセスしたユーザからのデータ要求に対して、当該ユーザへの公開時刻に達している該当データのうち更新時刻が最も新しいデータを現在のデータとして出力する。
【００１３】
本発明によるデータベースシステムは、また、データを記憶するデータベース及びデータベースを管理するデータベース管理システムを含むデータベースシステムにおいて、データベースは、データ及び当該データをユーザに対して公開する公開時刻の情報を記憶しており、データベース管理システムは、アプリケーションプログラムからの検索要求によって呼び出されるデータ検索手段と、データ検索手段によって呼び出される全データ対象検索手段及び公開データ取得手段を備え、全データ対象検索手段は、公開時刻の情報を無視してデータ検索手段から渡された検索条件を満たすデータベースのデータを全て検索し、公開データ取得手段は、全データ対象検索手段が検索したデータのうちデータ検索手段を呼び出したユーザへの公開時刻に達しているデータの中で更新時刻が最も新しいデータを検索結果として取得することを特徴とする。
【００１４】
本発明によるデータベースシステムは、また、データを記憶するデータベース及びデータベースを管理するデータベース管理システムを含むデータベースシステムにおいて、データベースは、データ及び当該データをユーザに対して公開する公開時刻の情報及びデータに対する制約条件を記憶しており、データベース管理システムは、データ更新手段と、制約条件検証手段と、データ書込手段とを備え、データの更新に際し、データ更新手段はデータ検索手段を呼び出し全データ対象検索手段によって更新対象のデータを検索し、制約条件検証手段は検索されたデータに対してデータの更新によって制約条件が破られるか否かを検証し、制約条件が保たれるときデータ書込手段によって更新データを当該データの公開時刻とともに前記データベースに書き込むことを特徴とする。
【００１５】
このデータベースシステムは、新しいデータが全てのユーザに対して公開されたことによって、どのユーザからも参照されることが無くなった過去のデータをデータベースから削除する不要データ削除手段を備えてもよい。
【００１６】
本発明によれば、複数のユーザ群によって更新されるデータと、それらのデータを他のユーザ群に対して公開する時刻の情報とを１個のデータベースの記憶領域において時系列的に一元管理するので、従来のように別ファイルにコピーすることなく、それぞれのユーザ群内において、データベースの更新内容を一定期間隠蔽することができ、しかも、それぞれの更新内容をマージした結果を容易に得ることができる。また、データベース内に重複したデータを持つ必要がないので、データの管理が容易になる、データの格納効率が良いなどの利点がある。加えて、緊急を要するデータなどについては直ちに他のユーザ群に対して公開し、吟味を要するデータなどについては公開までに時間をかけるなどの調整を容易に実現できる。更に、他のユーザの更新内容と、自分の更新内容とを互いに遮断した独立環境を容易に構築できるので、本番環境におけるテスト作業などでも効率よくデータベースを利用できる。また、システムの設定によっては、システム時刻を操作するだけで、過去のデータベースの状態を容易に復元できるようにすることもでき、統計処理やバックアップ処理を容易に行えるようにすることができる。
【００１７】
【発明の実施の形態】
以下、図面を参照して本発明の実施の形態を説明する。
図１は、本発明によるデータベースシステムの構成例を示す図である。このデータベースシステムは、中央処理装置１、データベース（ＤＢ）２、それぞれがデータベース利用端末となるＡ，Ｂ，Ｃの３群に分かれたユーザ群５，６，７、及びシステム管理者端末８を備える。中央処理装置１は、アプリケーションプログラム３及び連続無停止データベース管理システム（ＤＢＭＳ）４を含む。アプリケーションプログラム３は各ユーザによるトランザクションを処理し、ＤＢの参照及び更新要求をＤＢＭＳ４に引き渡す。ＤＢＭＳ４は、アプリケーションプログラム３からの参照及び更新要求に応じてＤＢ２にアクセスする制御部である。
【００１８】
ＤＢ２は、データ及びそのデータの各ユーザ群に対する公開時刻の情報を記憶するためのデータ・公開時刻記憶領域１０１、他のユーザ群によるデータの更新内容を自ユーザ群用のデータに反映させるか否かという設定情報を記憶するための干渉許可設定記憶領域１０２、及びデータ更新時における制約条件を記憶するための制約条件記憶領域１０３を備える。図１の構成においては、各データを記憶するレコードのヘッダ部分に公開時刻の情報を記憶させるため、データ記憶領域と公開時刻記憶領域とを１個の領域に統合させている。
【００１９】
ユーザ群Ａ，Ｂ，Ｃ（５，６，７）は、データベースシステムのユーザ端末を所属部門やシステムの使用目的によって、１又は複数からなるグループに分割したものである。それぞれのユーザ群に属するユーザ端末は、それぞれアプリケーションプログラム３を介してＤＢＭＳ４に対してデータの参照要求や更新要求を出すことができる。なお、本実施の形態においては、公開時刻の設定や干渉許可設定はユーザ群単位で行う。図１ではユーザ群を３群に分けているが、４群以上の分割又は２群の分割も可能である。システム管理者端末８は各ユーザ群から独立しており、アプリケーションプログラム３を介して又はＤＢＭＳ４に直接アクセスして、ＤＢ２及びＤＢＭＳ４の総合的な管理をすることができる。
【００２０】
図２は、ＤＢＭＳ４とＤＢ２の構成例を示す図である。ＤＢＭＳ４は、データ検索手段１１１、データ更新手段１１２とそこから分化した登録手段１１３及び更新・削除手段１１４、干渉許可設定変更手段１１５、不要データ削除手段１１６、全データ対象検索手段１２１、公開データ取得手段１２２、制約条件検証手段１２３、データ読み出し制御手段１３１、データ書き込み制御手段１３２、干渉許可設定読み出し制御手段１３３、干渉許可設定書き込み制御手段１３４、及び制約条件読み出し・書き込み制御手段１３５を備える。図中の矢印は各手段の制御経路を示す。各手段の具体的な動作については後述する。アプリケーションプログラム３は、データ検索手段１１１、データ更新手段１１２、及び干渉許可設定変更手段１１５を呼び出す要求手段を有している。不要データ削除手段１１６は、他の手段とは異なり、アプリケーションプログラム３の要求によって呼び出されるのではなく、システム管理者８の要求によって又はシステムによって定期的に呼び出される。
【００２１】
ここで、データの公開時刻について説明する。データの公開時刻とは、あるユーザが更新したデータが、他のユーザ群に対して公開される時刻である。データの公開時刻は対象のユーザ群ごとに設定することが可能であり、その情報は各レコードのヘッダ部に記憶される。公開時刻はデータを更新するユーザがデータ更新要求時に設定できるが、予めシステムにおいて公開時刻の既定値を設定しておき、それによって自動設定することもできる。既定値としては、データ登録時のシステム時刻に対してあるオフセット時間を加算した時刻や、例えば「翌日の９時」など、ある固定された時刻などを設定できる。
【００２２】
図３は、各データの公開時刻によってデータが公開される仕組みを説明する図である。ここでは、更新データは、そのデータを更新したユーザ群には直ちに公開されるが、他のユーザ群に対しては更新後一定の時間の後に公開されるものとして説明する。
【００２３】
本システムでは、時系列管理機能を持つ従来のＤＢＭＳと同様に、あるデータが更新された場合、以前のデータはＤＢのデータ・公開時刻記憶領域１０１に残しておき、更新後データを最新データとして新たに記憶する。図３（ａ）はデータ更新前の状態を示している。この状態では、どのユーザ群に属するユーザにもデータ３１が公開されていて、参照可能になっている。図３（ｂ）はデータ更新直後の状態を示している。この状態では、データを更新したユーザの属するユーザ群には更新後データ３２が直ちに参照可能となるが、他のユーザ群に対しては、以前のデータ３３が参照可能となっており、更新後データ３２は参照できない。図３（ｃ）はシステム時刻が他のユーザ群への公開時刻に到達した後の状態を示している。この状態では、更新後データ３４が他のユーザ群に対して公開されるので、どのユーザ群も更新後データ３４を参照可能となる。図３（ｃ）の状態において、データ３５はどのユーザからも参照できない。従って、データ３５は不要データである。また、データが不要データとなる時刻を不要データ化時刻と称する。あるデータが不要データか否かを判定するためには、データ更新時に以前のデータの不要データ化時刻を計算しておき、それを各データのヘッダ部に記憶しておくことによって、容易に判定できるようになる。
【００２４】
図４は、ＤＢにおいて、データとその公開時刻を記憶させるための領域を有するレコードの例を示す図である。ヘッダ部には、データを更新したユーザを記憶する領域と、データを更新した時刻を記憶する領域と、そのデータを各ユーザに公開する時刻を記憶する領域とがある。データを各ユーザに公開する時刻を記憶する領域は１個のデータに対してシステムで定義されているユーザ群の数だけ作られ、それぞれが公開時刻記憶領域と公開時刻退避領域とに分かれていている。
【００２５】
図５は、公開時刻記憶領域と退避領域に時刻が記憶される様子を示す説明図である。この２つの領域への時刻の記憶状態は、ユーザ群間における干渉許可設定の情報と密接に結びついている。
【００２６】
図５（ａ）は、ユーザＡがデータを更新していて、ユーザＡからユーザＢへの干渉を許可している場合のヘッダ部の例を示す図である。この場合、ユーザＢに対する公開時刻記憶領域には、ユーザＡが設定した公開時刻がそのまま記憶される。公開時刻退避領域には何も記憶されない。図５（ｂ）は、ユーザＡがデータを更新していて、ユーザＡからユーザＢへの干渉が不許可になっている場合のヘッダ部の例を示す図である。この場合、ユーザＡが設定した公開時刻は退避領域に退避され、公開時刻記憶領域には、９９９９年１２月３１日といった実用上無限の未来と考えられるような時刻（以下、無限未来時刻という）が記憶される。退避領域に退避された時刻は、干渉許可設定が不許可から許可に変更されたときに利用される。
【００２７】
図６は、干渉許可設定記憶領域１０２に記憶されているユーザ間の干渉に関するデータ例を示す図である。干渉許可設定は、ＤＢのテーブル単位で設定することも可能であるし、データ単位で設定することも可能である。干渉許可をテーブル単位で設定する場合は、図６（ａ）のように、干渉許可設定を行うテーブル名と、各ユーザ間の干渉許可設定を記憶する領域を作成する。図中、例えば「ユーザＡ→Ｂ」は、ユーザＡからユーザＢへの干渉許可設定の状態を示す。この領域に記憶される値は、「許可」又は「不許可」のいずれかである。ユーザ間の干渉許可をデータ単位で設定する場合は、図６（ｂ）に示すように、テーブル名と対象データの主キーの属性値によって干渉許可設定を行うデータを特定し、そのデータに対して上記と同様に各ユーザ間の干渉許可設定、すなわち「許可」又は「不許可」を記憶する。
【００２８】
図７は、ユーザ群Ａ，Ｂ，Ｃに対して設定された公開時刻及び干渉許可設定と、ユーザ群が参照可能なデータの関係を例によって具体的に説明する図である。図７（ａ）は、あるデータに対してユーザ群ＡあるいはＢに属するユーザが延べ４回更新した例を、データ４０１〜４０４のヘッダ部を抜粋して示している。太枠は、それぞれのユーザが参照可能なデータの公開時刻の部分を示す。なお、データを更新したユーザが属するユーザ群自身への公開時刻としては、データ更新時刻そのものを用いる。
【００２９】
図７（ａ）において、システム時刻２００２年６月２０日１２時の時点では、ユーザ群Ａは最新のデータ４０４を参照可能である。ユーザ群Ｂは、システム時刻がデータ４０４の公開時刻（２００２年６月２１日９時）に至っていないのでデータ４０４は参照できないが、データ４０３の公開時刻（２００２年６月１９日１７時１０分１５秒）は過ぎているのでデータ４０３が参照可能である。同様に、ユーザ群Ｃは、システム時刻が未だデータ４０３，４０４の公開時刻に至っていないのでデータ４０３，４０４は参照できず、ユーザ群Ｃへの公開時刻が過ぎたデータ４０２が参照可能である。ここで、データ４０３のユーザ群Ａに対する公開時刻はデータ４０４の公開時刻よりも遅くなっているが、本システムには、システム時刻が公開時刻に到達しているデータが複数存在する場合、更新時刻が最も新しいデータを参照可能にするというルールがあり、データ４０３はユーザ群Ａに対して公開されない。このルールは、最新データを更新したにも関わらず、その情報を自分で参照することができないという状態に陥るのを防ぐために存在する。
【００３０】
図７（ｂ）は、対象のデータにおいて、ユーザ群Ｂからユーザ群Ａへの干渉許可設定を「不許可」に設定している例を示している。干渉許可設定を「不許可」にすると、それ以降、対象のデータに対して相手のユーザ群による更新内容が反映されなくなり、自分だけの独自環境を作ることができる。逆に、「許可」に設定すると、相手のユーザ群の更新内容が反映されるようになる。干渉許可設定は、通常は「許可」の状態になっている。干渉許可設定はユーザ群の組み合わせごとに設定可能である。干渉許可設定は、テストデータやシミュレーションデータを作る場合などに有効である。
【００３１】
図７（ｂ）において、ユーザ群Ｂによる更新内容はユーザ群Ａには反映されないため、ユーザ群Ｂが更新したデータ４１２，４１３の公開時刻は既に過ぎているが、ユーザ群Ａが参照可能なデータは自分自身が更新したデータ４１１である。ユーザ群Ｂ及びユーザ群Ｃは、干渉許可設定が通常の状態（許可）になっているため、最新データ４１３を参照可能である。なお、実際のシステムにおいては図５（ｂ）にて説明したように、データ４１２，４１３のヘッダ部では、ユーザ群Ａへの公開時刻の情報は別領域に退避されていて、その代わりに、実用上無限の未来とみなせるような無限未来時刻が、ユーザ群Ａへの公開時刻として記憶されている。
次に、図８から図１７のフローチャートを参照して、ＤＢＭＳ４を構成する各手段の処理について説明する。
【００３２】
図８は、データ検索手段１１１の処理手順を示すフローチャートである。アプリケーションプログラム３からある検索条件が与えられてデータ検索手段１１１が呼び出されると、全データ対象検索手段１２１を呼び出し、与えられた検索条件を満たすデータを、ユーザに対する公開時刻に関係なく全て読み出す（ステップ１１１１）。次に、公開データ取得手段１２２を呼び出し、得られたデータｄの更新前データ及び更新後データを調べ、当該手段を呼び出したユーザに公開されているデータｄ’を読み出す（ステップ１１１２）。次に、データｄとデータｄ’が等しいかを判定し（ステップ１１１３）、等しければ、判定結果はデータｄが公開されていることを意味するので、データｄを検索結果として採用する（ステップ１１１４）。一方、等しくなければ、判定結果はデータｄが公開されていないことを意味するので、データｄを検索結果から除外する（ステップ１１１５）。そして、ステップ１１１１で得られた全てのデータに対してステップ１１１２〜１１１５の処理が終了すると、アプリケーションプログラム３に制御を戻す。
【００３３】
図９は、データ更新手段１１２の処理手順を示すフローチャートである。まず、データ検索手段１１１を呼び出し、更新対象のデータｄを検索して読み出す（ステップ１１２１）。なお、ステップ１１２１は、データを更新又は削除を行う場合に実行され、データの登録を行う場合には実行されない。次に、制約条件検証手段１２３を呼び出し、データｄの更新によってＤＢの制約条件が破られるか否かを調べる（ステップ１１２２）。制約条件が破られるという判定結果が得られた場合は、それ以上ＤＢ２へのアクセスは行わずに、アプリケーションプログラム３に制御を戻す。一方、制約条件が破られないという判定結果が得られると、データの登録を行う場合にはデータ登録手段１１３を呼び出してＤＢ２にデータを登録し（ステップ１１２３）、データの更新又は削除を行う場合にはデータ更新・削除手段１１４を呼び出して、ＤＢ２に記憶されているデータを更新し（ステップ１１２４）、その後、アプリケーションプログラム３に制御を戻す。
【００３４】
図１０は、データ更新手段１１２のサブルーチンであるデータ登録手段１１３の処理（図９のステップ１１２３）を説明するフローチャートである。図１０において、まず、干渉許可設定書き込み制御手段１３４を呼び出し、登録対象のデータｄの干渉許可設定をＤＢ２の干渉許可設定記憶領域１０２に記憶させる（ステップ１１３１）。次に、公開時刻の修正を伴うデータ更新処理２０１（図１７参照）を呼び出し、データｄをＤＢ２のデータ・公開時刻記憶領域１０１に記憶させる（ステップ１１３２）。以上の処理が終了した後、データ更新手段１１２に制御を戻す。なお、データｄの実体よりも干渉許可設定の方を先に記憶させている理由は、公開時刻の修正を伴うデータ更新処理２０１において、データｄの公開時刻の設定に干渉許可設定を反映させる際、ＤＢ２の干渉許可設定記憶領域１０２に記憶されているデータｄの干渉許可設定を参照するためである。
【００３５】
図１１は、データ更新手段１１２のサブルーチンであるデータ更新・削除手段１１４の処理（図９のステップ１１２４）を説明するフローチャートである。図１１において、まず、当該手段を呼び出したユーザのユーザ群と、更新対象のデータｄの作成者のユーザ群が等しいか調べる（ステップ１１４１，１１４２）。ここで、データｄの作成者とは、過去にデータ更新手段１１２を用いて、データｄを更新後データとしてＤＢ２に記憶せしめたユーザを意味する。判定結果が「等しい」の場合は、データｄの作成者のユーザ群以外でデータｄを参照可能なユーザ群が存在するか否かを調べる（ステップ１１４３）。そして、参照可能なユーザ群が他に存在しない場合は、公開時刻の修正を伴うデータ更新処理２０１を呼び出し、データｄに対して更新後データｄ’をＤＢ２に上書き記憶させる（ステップ１１４４）。一方、ステップ１１４２における判定結果が「等しくない」の場合及びステップ１１４３における判定結果が「存在する」の場合は、データｄの更新後も他のユーザ群から更新前のデータが参照される可能性があるため、データｄをデータ・公開時刻記憶領域１０１に残しておく必要がある。そこで、公開時刻の修正を伴うデータ更新処理２０１を呼び出し、データｄをコピーしてデータ記憶領域１０１に残し、更新後データｄ’を新しいデータとして記憶させる（ステップ１１４５）。ステップ１１４４あるいはステップ１１４５の処理が終了した後、データ書き込み制御手段１３２を呼び出し、更新前データの不要データ化時刻を再計算し、それを上書き記憶させる（ステップ１１４６）。ここでは、不要データ化時刻は、当初の更新前データｄのみならず、他の過去のデータに対しても修正する。以上の処理が終了した後、データ更新手段１１２に制御を戻す。なお、ステップ１１４３の判定は、対象データｄの不要データ化時刻と、データｄの作成者のユーザ群以外に対する最も早い公開時刻をそれぞれシステム時刻と比較することによって、容易に判定できる。
【００３６】
ステップ１１４４において、データを上書きする理由は、今後に渡って更新前のデータｄが他のユーザ群から参照されることはなく、代わりに更新後データｄ’が参照されることになるため、更新前のデータｄをデータ・公開時刻記憶領域１０１に残しておく必要が無いからである。逆に、データ更新後も他のユーザ群から更新前のデータｄが参照される可能性がある場合は、ステップ１１４５を実行して、更新前データをデータ・公開時刻記憶領域１０１に残す仕組みである。ステップ１１４６において、不要データ化時刻の計算は、厳密に計算すると、計算量がかなり多くなる。しかし、例えば、最新データの最も遅い公開時刻をそれ以前の全てのデータの不要データ化時刻として採用するなど、概算的な手法を用いることによって、計算量を減らすことができる。ただし、概算的な手法を用いた場合は、あるデータが不要データか否かを判定するときの精度が落ちるため、結果としてシステムのパフォーマンスが落ちる場合がある。従って、ここは、それぞれの処理におけるパフォーマンスのトレードオフの問題となる。
【００３７】
図１２は、干渉許可設定変更手段１１５の処理手順を示すフローチャートである。まず、データ検索手段１１１を呼び出し、設定変更対象のデータｄを検索して読み出す（ステップ１１５１）。次に、設定変更内容によって場合分けし（ステップ１１５２）、「不許可」から「許可」への変更の場合は、データ書き込み制御手段１３２を呼び出し、データ・公開時刻記憶領域１０１において、データｄ及びその更新前・更新後データについて、設定変更対象のユーザ群に対する公開時刻（無限未来時刻になっている）を、退避領域に記憶させておいた正規の公開時刻で上書き記憶させる（ステップ１１５３）。次に、干渉許可設定書き込み制御手段１３４を呼び出し、データｄの新しい干渉許可設定を干渉許可設定記憶領域１０２に記憶させる（ステップ１１５４）。一方、「許可」から「不許可」への変更の場合は、データ・公開時刻記憶領域１０１にはアクセスせず、干渉許可設定書き込み制御手段１３４を呼び出し、データｄの新しい干渉許可設定を干渉許可設定記憶領域１０２に記憶させる。以上の処理が終了した後、アプリケーションプログラム３に制御を戻す。
【００３８】
図１３は、不要データ削除手段１１６の処理手順を示すフローチャートである。この処理では、データ書き込み制御手段１３２を呼び出し、システム時刻が不要データ化時刻に到達しているデータをデータ・公開時刻記憶領域１０１から全て削除し（ステップ１１６１）、その後、アプリケーションプログラム３に制御を戻す。この不要データ削除手段１１６を実行することによって、データ・公開時刻記憶領域１０１の記憶容量が節約でき、また、余分なデータが少なくなるので検索手段の処理効率が向上し、結果として、システム全体のパフォーマンスが向上する。なお、テストなどのために、過去のシステムの状態を再現したい場合は、不要データ削除手段１１６を呼び出す前に不要データのバックアップを取るなど、従来の技術に頼ればよい。あるいは、不要データ削除手段を呼び出さないようにしておけば、システム時刻を過去の時刻に戻し、検索時にはシステム時刻以降に作成されたデータを無視することにより、過去のシステムの状態を容易に再現できる。従って、不要データ削除手段１１６をどのように利用するかは、システムの管理方針や運用状態などを考慮した上で決める必要がある。
【００３９】
図１４は、全データ対象検索手段１２１の処理手順を示すフローチャートである。この処理においては、データ読み出し制御手段１３１を呼び出し、呼び出し元の処理によって与えられた検索条件と、不要データでないという検索条件とを満たす全てのデータを公開時刻に関係なく読み出し（ステップ１２１１）、該当するデータを取得した後、呼び出し元の処理に制御を戻す。
【００４０】
図１５は、公開データ取得手段１２２の処理手順を示すフローチャートである。図１５において、まず、データ読み出し制御手段１３１を呼び出し、対象データｄ及びその更新前・更新後データにおいて、システム時刻が当該手段を呼び出したユーザに対する公開時刻に到達しているという条件と、前述の条件を満たすデータのうち最新のものであるという条件とを満たすデータｄ’を読み出し（ステップ１２２１）、該当するデータを取得した後、呼び出し元の処理に制御を戻す。
【００４１】
図１６は、制約条件検証手段１２３の処理手順を示すフローチャートである。まず、制約条件読み出し・書き込み制御手段１３５を呼び出し、更新対象のデータｄが関係する制約条件を制約条件記憶領域１０３より取得する（ステップ１２３１）。次に、全データ対象検索手段１２１を呼び出し、データｄの制約条件の検証に必要な全てのデータを、公開時刻に関係なく読み出す（ステップ１２３２）。次に、得られたデータに更新後データを一時的に追加して、その中で対象の制約条件が保たれるかを調べ（ステップ１２３３）、制約条件が保たれれば、制約条件は破られないという検証結果を呼び出し元の処理に返す（ステップ１２３４）。一方、保たれなければ、制約条件が破られるという検証結果を呼び出し元の処理に返す（ステップ１２３５）。この制約条件検証手段１２３がシステムに存在するために、各ユーザ群の間で未公開のデータが多数存在しても、主キー属性の衝突などの致命的な事故がどのユーザ群の環境においても起こらないようになっている。
【００４２】
図１７は、データ登録手段１１３及びデータ更新・削除手段１１４のサブルーチンである、公開時刻の修正を伴うデータ更新処理２０１（図１０のステップ１１３２及び図１１のステップ１１４５）の処理手順を示すフローチャートである。図１７において、まず、干渉許可設定読み出し制御手段１３３を呼び出し、更新対象のデータｄに対する干渉許可設定を干渉許可設定記憶領域１０２より取得する（ステップ２０１１）。次に、データｄを更新するユーザが属するユーザ群からあるユーザ群ｕへの干渉許可設定を調べ（ステップ２０１２）、「不許可」であれば、ヘッダ情報記憶用の一時記憶領域において、ユーザ群ｕに対する正規の公開時刻は退避用領域に記憶させ、無限未来時刻をユーザ群ｕに対する公開時刻として記憶させる（ステップ２０１３）。一方、「許可」であれば、ヘッダ情報記憶用の一時記憶領域において、ユーザ群ｕに対する正規の公開時刻をそのまま公開時刻として記憶させる（ステップ２０１４）。全てのユーザ群に対してこの処理を繰り返し、最終的に一時記憶領域に記憶されたヘッダ情報（公開時刻の情報を含む）とともにデータｄをデータ・公開時刻記憶領域１０１に記憶させるために、データ書き込み制御手段１３２を呼び出し（ステップ２０１５）、ＤＢ２にアクセスせしめた後、呼び出し元の処理に制御を戻す。
【００４３】
次に、データ・公開時刻記憶領域１０１に記憶されるデータのデータ形式について説明する。データ・公開時刻記憶領域１０１に記憶されるデータは、データ本体の他に、公開時刻の情報やデータの更新・削除に関する情報をヘッダ情報として含んでおく必要がある。
【００４４】
図１８は、データ・公開時刻記憶領域１０１に記憶される具体的なデータ形式の一例を示す図である。図１８では、ヘッダ部は連番５１１、フラグ類５１２、不要データ化時刻５１３、データを更新したユーザ群のＩＤ５１４、公開時刻記憶領域５１５、公開時刻退避領域５１６から構成され、データ部はレコード５２１のみから構成される。連番５１１はデータが更新される度に加算される番号であり、データの新しさを判断する基準となる。フラグ類５１２には削除フラグなどが含まれ、データ更新の種別を判断する基準となる。データを削除する場合は、削除フラグをオンにしたデータをデータ・公開時刻記憶領域１０１に記憶させることになる。不要データ化時刻５１３は、図１３などでも説明したように、そのデータが不要データか否かを判断するために用いられる。データを更新したユーザ群のＩＤ５１４は、図１１で説明したデータ更新手段１１４などで用いられる。公開時刻記憶領域５１５は各ユーザ群への公開時刻を記憶するための領域である。公開時刻退避領域５１６は、図１７のステップ２０１３の説明にあったように、干渉許可設定が「不許可」のユーザに対する公開時刻を退避させておくために用いられる。なお、従来のリレーショナルデータベースでは、主キー属性によってレコードが一意に識別できるが、本システムにおけるデータ・公開時刻記憶領域１０１では、レコード５２１の主キー属性と、ヘッダ部の連番５１１との組み合わせによって、データが一意に識別できる。従って、例えば、制約条件検証手段１２３において、データの一意性を検証する場合、これらの組み合わせを参照することによって検証することが可能である。
【００４５】
図１９は、互いに異なる２個のデータが、他のユーザ群に公開される例を時間軸によって示す図である。図１９では、時刻６０１において、ユーザ群Ａに属するユーザがデータ６１を登録し、その後、時刻６０２において、同じユーザが別のデータ６２を登録している。ところが、ユーザ群Ｂに対する公開時刻は、データの登録とは逆に、データ６２の方がより早く（時刻６０３）、データ６１の方がより遅く（時刻６０４）設定されていた。公開時刻の順序を逆に設定した理由としては、データ６２の内容を緊急にデータ群Ｂに対して公開しなければならなかったとか、データ６１の内容を公開する前にユーザ群Ａの間でよく吟味する必要があったとか、色々と考えられる。いずれにせよ、その結果、ユーザ群Ｂからは、データ６１よりもデータ６２の方が先に登録されたように見えることになった。このように、ユーザによってＤＢの時系列情報が見かけ上変化するようなことは、単純にＤＢの時系列情報を保存するような従来の方法では実現され得ない。また、このような特異な現象が発生した場合でも、本発明のシステムでは、制約条件検証手段１２３が働くため、ＩＤの衝突のような致命的な事故を防ぐことができ、安定したシステム運用を実現できる。
【００４６】
【発明の効果】
本発明によれば、データベースを利用する他のユーザ群に対してＤＢの更新内容を一定期間隠蔽することができ、しかも、それぞれの更新内容をマージした結果を容易に得ることができる。
【図面の簡単な説明】
【図１】本発明によるデータベースシステムの構成例を示す図。
【図２】本発明によるデータベース管理システムとデータベースの構成例及び各処理の関連を示す図。
【図３】データの公開時刻の設定によってデータが公開される仕組みの説明図。
【図４】データとその公開時刻を記憶させるためのレコードの例を示す図。
【図５】公開時刻記憶領域と退避領域に時刻が記憶される様子を示す図。
【図６】干渉許可設定記憶領域に記憶されているユーザ間の干渉に関するデータ例を示す図。
【図７】公開時刻及び干渉許可設定の設定例と参照可能なデータの関係を示す図。
【図８】データ検索手段の処理手順を示すフローチャート。
【図９】データ更新手段の処理手順を示すフローチャート。
【図１０】データ登録手段の処理を示すフローチャート。
【図１１】データ更新・削除手段の処理を示すフローチャート。
【図１２】干渉許可設定変更手段の処理手順を示すフローチャート。
【図１３】不要データ削除手段の処理手順を示すフローチャート。
【図１４】全データ対象検索手段の処理手順を示すフローチャート。
【図１５】公開データ取得手段の処理手順を示すフローチャート。
【図１６】制約条件検証手段の処理手順を示すフローチャート。
【図１７】公開時刻の修正を伴うデータ更新処理の処理手順を示すフローチャート。
【図１８】データ・公開時刻記憶領域に記憶されるデータ形式の一例を示す図。
【図１９】２個のデータが公開される例を示す図。
【符号の説明】
１…中央処理装置、２…データベース（ＤＢ）、３…アプリケーションプログラム、４…データベース管理システム（ＤＢＭＳ）、１０１…データ・公開時刻記憶領域、１０２…干渉許可設定記憶領域、１０３…制約条件記憶領域、１１１…データ検索手段、１１２…データ更新手段、１１５…干渉許可設定変更手段、１１６…不要データ削除手段、１２１…全データ対象検索手段、１２２…公開データ取得手段、１２３…制約条件検証手段
【発明の属する技術分野】
本発明は、データベースシステムに関し、特に、複数の部門のユーザによるデータの連続的な参照・更新を許容するデータベースシステムに関する。
【０００２】
【従来の技術】
従来、データベース（以下、ＤＢと称す）の最新データに対して複数の異なる部門に属するユーザがそれぞれ独立して連続アクセスによる更新処理を行い、その更新内容をそれぞれあるタイミングで他の部門に公開して、互いのデータをマージするには、各部門用のＤＢをそれぞれ用意し、あるタイミングでＤＢのサービスを一時的に停止し、バッチ処理によってマージを行っていた。その際、マージ処理において、データの主キー属性の一意性など制約条件を保持することは障害の一つとなっていた。
【０００３】
連続無停止のデータベース管理システム（以下、ＤＢＭＳと称す）においてＤＢの内容を更新する方法として、特許文献１に記載のように、ＤＢの更新要求に対しては直ちに対象情報を更新する一方、更新前の情報を時系列情報とともに保持しておき、検索要求に対しては、時系列情報に基づいて該当時点の情報を検索する方法があった。過去のある時点のＤＢの内容に対して更新処理を行う場合には、従来は、ある時点においてＤＢの内容を別ファイルにコピーして、それを更新していた。一方、特許文献２には、ＤＢの記憶領域を、最新データを記憶するためのエリアと、過去のデータを記憶するためのエリアと、過去のデータを更新したデータを記憶するためのエリアとに分割し、それぞれのエリアに目的別のデータを保存しておくことによって、別ファイルにコピーすることなく過去のある時点のＤＢの内容を更新せしめるＤＢＭＳが記載されている。
【０００４】
【特許文献１】
特開平６−３５７７４号公報
【特許文献２】
特開平１０−１４３４１１号公報
【０００５】
【発明が解決しようとする課題】
特許文献１に記載の技術では、過去のある時点のＤＢの内容に対するデータの検索を行うことは可能であるが、過去のデータを直接更新することはできない。また、特許文献２に記載の技術では、過去のデータに対して、複数の異なる部門に属するユーザが連続アクセスによって更新処理を行うことは可能であるが、それぞれの部門で更新されたデータを効率よく他の部門に対して公開することはできない。加えて、特許文献２に記載の技術では、最新データは常に通常業務を行う各ユーザに対して公開されることになるため、複数の異なる部門に属するユーザがそれぞれ最新データを作成し、しかもそれぞれのデータを他の部門に対して一定期間隠蔽したいというような場合には、効率的な対応はできない。
【０００６】
本発明は、このような従来技術の問題点に鑑み、ある時点のデータベースの内容を別ファイルにコピーすることなく、異なる複数の部門に属するユーザが最新データに対する更新処理を行う上で、更新内容を他の部門に属するユーザに対して任意期間隠蔽可能なデータベースシステムを提供することを目的とする。
【０００７】
【課題を解決するための手段】
上記目的を達成するために、本発明では、データベースにおいては、データを登録したユーザが他のユーザ群にそのデータを公開する時刻を記憶するための記憶領域と、他のユーザ群によるデータ更新内容を自ユーザ用のデータに反映させるか否かという設定情報（自分のデータに他ユーザによる干渉を許すか否かという意味で、干渉許可設定と称す）を記憶するための記憶領域とを備え、データベース管理システムにおいては、自ユーザに対して公開されているデータを読み出す手段と、データの公開時刻とともにデータをデータベースの記憶領域に書き込む手段と、キー属性の一意性制約などの制約条件が、公開されているデータのみならず、未公開データをも含めて満たされることを検証する手段（制約条件検証手段）と、前述の干渉許可設定を更新する手段とを有することを特徴とする。
【０００８】
更に、本発明は、前述の制約条件を検証する手段などを実現するために、データの公開・未公開に関係なく全てのデータを対象としてデータを検索する手段を有することを特徴とする。また、検索効率を向上させ、同時にデータベースの記憶領域の容量を節約し、結果としてシステム全体のパフォーマンス向上を図るために、新しいデータが全てのユーザに対して公開されたことによって、どのユーザからも参照されることが無くなった過去のデータ（不要データと称す）をデータベースの記憶領域から削除する手段（不要データ削除手段と称す）を有することを特徴とする。
【０００９】
すなわち、本発明によるデータベースシステムは、データを記憶するデータベース及びデータベースを管理するデータベース管理システムを含むデータベースシステムにおいて、データベースは、データ及び当該データをユーザに対して公開する公開時刻の情報を記憶していることを特徴とする。
【００１０】
公開時刻の情報は、複数のユーザ群のそれぞれに対して記憶している。また、公開時刻の情報は、各データを格納するレコードのヘッダ部分に記憶することができる。
【００１１】
データベースは、また、第１のユーザによるデータの更新内容を第１のユーザと異なる第２のユーザ用のデータに反映させるか否かの干渉許可の情報を記憶することもできる。この干渉許可はデータ単位で設定することもできるし、複数のデータを含むテーブル単位で設定することもできる。干渉許可の設定が第１のユーザによるデータの変更内容を第２のユーザ用のデータに反映させることを許可していないとき、データベース管理システムは、第１のユーザが更新したデータの第２のユーザへの公開時刻として実用上無限の未来を表す時刻を設定する。
【００１２】
データベース管理システムは、データベースにアクセスしたユーザからのデータ要求に対して、当該ユーザへの公開時刻に達している該当データのうち更新時刻が最も新しいデータを現在のデータとして出力する。
【００１３】
本発明によるデータベースシステムは、また、データを記憶するデータベース及びデータベースを管理するデータベース管理システムを含むデータベースシステムにおいて、データベースは、データ及び当該データをユーザに対して公開する公開時刻の情報を記憶しており、データベース管理システムは、アプリケーションプログラムからの検索要求によって呼び出されるデータ検索手段と、データ検索手段によって呼び出される全データ対象検索手段及び公開データ取得手段を備え、全データ対象検索手段は、公開時刻の情報を無視してデータ検索手段から渡された検索条件を満たすデータベースのデータを全て検索し、公開データ取得手段は、全データ対象検索手段が検索したデータのうちデータ検索手段を呼び出したユーザへの公開時刻に達しているデータの中で更新時刻が最も新しいデータを検索結果として取得することを特徴とする。
【００１４】
本発明によるデータベースシステムは、また、データを記憶するデータベース及びデータベースを管理するデータベース管理システムを含むデータベースシステムにおいて、データベースは、データ及び当該データをユーザに対して公開する公開時刻の情報及びデータに対する制約条件を記憶しており、データベース管理システムは、データ更新手段と、制約条件検証手段と、データ書込手段とを備え、データの更新に際し、データ更新手段はデータ検索手段を呼び出し全データ対象検索手段によって更新対象のデータを検索し、制約条件検証手段は検索されたデータに対してデータの更新によって制約条件が破られるか否かを検証し、制約条件が保たれるときデータ書込手段によって更新データを当該データの公開時刻とともに前記データベースに書き込むことを特徴とする。
【００１５】
このデータベースシステムは、新しいデータが全てのユーザに対して公開されたことによって、どのユーザからも参照されることが無くなった過去のデータをデータベースから削除する不要データ削除手段を備えてもよい。
【００１６】
本発明によれば、複数のユーザ群によって更新されるデータと、それらのデータを他のユーザ群に対して公開する時刻の情報とを１個のデータベースの記憶領域において時系列的に一元管理するので、従来のように別ファイルにコピーすることなく、それぞれのユーザ群内において、データベースの更新内容を一定期間隠蔽することができ、しかも、それぞれの更新内容をマージした結果を容易に得ることができる。また、データベース内に重複したデータを持つ必要がないので、データの管理が容易になる、データの格納効率が良いなどの利点がある。加えて、緊急を要するデータなどについては直ちに他のユーザ群に対して公開し、吟味を要するデータなどについては公開までに時間をかけるなどの調整を容易に実現できる。更に、他のユーザの更新内容と、自分の更新内容とを互いに遮断した独立環境を容易に構築できるので、本番環境におけるテスト作業などでも効率よくデータベースを利用できる。また、システムの設定によっては、システム時刻を操作するだけで、過去のデータベースの状態を容易に復元できるようにすることもでき、統計処理やバックアップ処理を容易に行えるようにすることができる。
【００１７】
【発明の実施の形態】
以下、図面を参照して本発明の実施の形態を説明する。
図１は、本発明によるデータベースシステムの構成例を示す図である。このデータベースシステムは、中央処理装置１、データベース（ＤＢ）２、それぞれがデータベース利用端末となるＡ，Ｂ，Ｃの３群に分かれたユーザ群５，６，７、及びシステム管理者端末８を備える。中央処理装置１は、アプリケーションプログラム３及び連続無停止データベース管理システム（ＤＢＭＳ）４を含む。アプリケーションプログラム３は各ユーザによるトランザクションを処理し、ＤＢの参照及び更新要求をＤＢＭＳ４に引き渡す。ＤＢＭＳ４は、アプリケーションプログラム３からの参照及び更新要求に応じてＤＢ２にアクセスする制御部である。
【００１８】
ＤＢ２は、データ及びそのデータの各ユーザ群に対する公開時刻の情報を記憶するためのデータ・公開時刻記憶領域１０１、他のユーザ群によるデータの更新内容を自ユーザ群用のデータに反映させるか否かという設定情報を記憶するための干渉許可設定記憶領域１０２、及びデータ更新時における制約条件を記憶するための制約条件記憶領域１０３を備える。図１の構成においては、各データを記憶するレコードのヘッダ部分に公開時刻の情報を記憶させるため、データ記憶領域と公開時刻記憶領域とを１個の領域に統合させている。
【００１９】
ユーザ群Ａ，Ｂ，Ｃ（５，６，７）は、データベースシステムのユーザ端末を所属部門やシステムの使用目的によって、１又は複数からなるグループに分割したものである。それぞれのユーザ群に属するユーザ端末は、それぞれアプリケーションプログラム３を介してＤＢＭＳ４に対してデータの参照要求や更新要求を出すことができる。なお、本実施の形態においては、公開時刻の設定や干渉許可設定はユーザ群単位で行う。図１ではユーザ群を３群に分けているが、４群以上の分割又は２群の分割も可能である。システム管理者端末８は各ユーザ群から独立しており、アプリケーションプログラム３を介して又はＤＢＭＳ４に直接アクセスして、ＤＢ２及びＤＢＭＳ４の総合的な管理をすることができる。
【００２０】
図２は、ＤＢＭＳ４とＤＢ２の構成例を示す図である。ＤＢＭＳ４は、データ検索手段１１１、データ更新手段１１２とそこから分化した登録手段１１３及び更新・削除手段１１４、干渉許可設定変更手段１１５、不要データ削除手段１１６、全データ対象検索手段１２１、公開データ取得手段１２２、制約条件検証手段１２３、データ読み出し制御手段１３１、データ書き込み制御手段１３２、干渉許可設定読み出し制御手段１３３、干渉許可設定書き込み制御手段１３４、及び制約条件読み出し・書き込み制御手段１３５を備える。図中の矢印は各手段の制御経路を示す。各手段の具体的な動作については後述する。アプリケーションプログラム３は、データ検索手段１１１、データ更新手段１１２、及び干渉許可設定変更手段１１５を呼び出す要求手段を有している。不要データ削除手段１１６は、他の手段とは異なり、アプリケーションプログラム３の要求によって呼び出されるのではなく、システム管理者８の要求によって又はシステムによって定期的に呼び出される。
【００２１】
ここで、データの公開時刻について説明する。データの公開時刻とは、あるユーザが更新したデータが、他のユーザ群に対して公開される時刻である。データの公開時刻は対象のユーザ群ごとに設定することが可能であり、その情報は各レコードのヘッダ部に記憶される。公開時刻はデータを更新するユーザがデータ更新要求時に設定できるが、予めシステムにおいて公開時刻の既定値を設定しておき、それによって自動設定することもできる。既定値としては、データ登録時のシステム時刻に対してあるオフセット時間を加算した時刻や、例えば「翌日の９時」など、ある固定された時刻などを設定できる。
【００２２】
図３は、各データの公開時刻によってデータが公開される仕組みを説明する図である。ここでは、更新データは、そのデータを更新したユーザ群には直ちに公開されるが、他のユーザ群に対しては更新後一定の時間の後に公開されるものとして説明する。
【００２３】
本システムでは、時系列管理機能を持つ従来のＤＢＭＳと同様に、あるデータが更新された場合、以前のデータはＤＢのデータ・公開時刻記憶領域１０１に残しておき、更新後データを最新データとして新たに記憶する。図３（ａ）はデータ更新前の状態を示している。この状態では、どのユーザ群に属するユーザにもデータ３１が公開されていて、参照可能になっている。図３（ｂ）はデータ更新直後の状態を示している。この状態では、データを更新したユーザの属するユーザ群には更新後データ３２が直ちに参照可能となるが、他のユーザ群に対しては、以前のデータ３３が参照可能となっており、更新後データ３２は参照できない。図３（ｃ）はシステム時刻が他のユーザ群への公開時刻に到達した後の状態を示している。この状態では、更新後データ３４が他のユーザ群に対して公開されるので、どのユーザ群も更新後データ３４を参照可能となる。図３（ｃ）の状態において、データ３５はどのユーザからも参照できない。従って、データ３５は不要データである。また、データが不要データとなる時刻を不要データ化時刻と称する。あるデータが不要データか否かを判定するためには、データ更新時に以前のデータの不要データ化時刻を計算しておき、それを各データのヘッダ部に記憶しておくことによって、容易に判定できるようになる。
【００２４】
図４は、ＤＢにおいて、データとその公開時刻を記憶させるための領域を有するレコードの例を示す図である。ヘッダ部には、データを更新したユーザを記憶する領域と、データを更新した時刻を記憶する領域と、そのデータを各ユーザに公開する時刻を記憶する領域とがある。データを各ユーザに公開する時刻を記憶する領域は１個のデータに対してシステムで定義されているユーザ群の数だけ作られ、それぞれが公開時刻記憶領域と公開時刻退避領域とに分かれていている。
【００２５】
図５は、公開時刻記憶領域と退避領域に時刻が記憶される様子を示す説明図である。この２つの領域への時刻の記憶状態は、ユーザ群間における干渉許可設定の情報と密接に結びついている。
【００２６】
図５（ａ）は、ユーザＡがデータを更新していて、ユーザＡからユーザＢへの干渉を許可している場合のヘッダ部の例を示す図である。この場合、ユーザＢに対する公開時刻記憶領域には、ユーザＡが設定した公開時刻がそのまま記憶される。公開時刻退避領域には何も記憶されない。図５（ｂ）は、ユーザＡがデータを更新していて、ユーザＡからユーザＢへの干渉が不許可になっている場合のヘッダ部の例を示す図である。この場合、ユーザＡが設定した公開時刻は退避領域に退避され、公開時刻記憶領域には、９９９９年１２月３１日といった実用上無限の未来と考えられるような時刻（以下、無限未来時刻という）が記憶される。退避領域に退避された時刻は、干渉許可設定が不許可から許可に変更されたときに利用される。
【００２７】
図６は、干渉許可設定記憶領域１０２に記憶されているユーザ間の干渉に関するデータ例を示す図である。干渉許可設定は、ＤＢのテーブル単位で設定することも可能であるし、データ単位で設定することも可能である。干渉許可をテーブル単位で設定する場合は、図６（ａ）のように、干渉許可設定を行うテーブル名と、各ユーザ間の干渉許可設定を記憶する領域を作成する。図中、例えば「ユーザＡ→Ｂ」は、ユーザＡからユーザＢへの干渉許可設定の状態を示す。この領域に記憶される値は、「許可」又は「不許可」のいずれかである。ユーザ間の干渉許可をデータ単位で設定する場合は、図６（ｂ）に示すように、テーブル名と対象データの主キーの属性値によって干渉許可設定を行うデータを特定し、そのデータに対して上記と同様に各ユーザ間の干渉許可設定、すなわち「許可」又は「不許可」を記憶する。
【００２８】
図７は、ユーザ群Ａ，Ｂ，Ｃに対して設定された公開時刻及び干渉許可設定と、ユーザ群が参照可能なデータの関係を例によって具体的に説明する図である。図７（ａ）は、あるデータに対してユーザ群ＡあるいはＢに属するユーザが延べ４回更新した例を、データ４０１〜４０４のヘッダ部を抜粋して示している。太枠は、それぞれのユーザが参照可能なデータの公開時刻の部分を示す。なお、データを更新したユーザが属するユーザ群自身への公開時刻としては、データ更新時刻そのものを用いる。
【００２９】
図７（ａ）において、システム時刻２００２年６月２０日１２時の時点では、ユーザ群Ａは最新のデータ４０４を参照可能である。ユーザ群Ｂは、システム時刻がデータ４０４の公開時刻（２００２年６月２１日９時）に至っていないのでデータ４０４は参照できないが、データ４０３の公開時刻（２００２年６月１９日１７時１０分１５秒）は過ぎているのでデータ４０３が参照可能である。同様に、ユーザ群Ｃは、システム時刻が未だデータ４０３，４０４の公開時刻に至っていないのでデータ４０３，４０４は参照できず、ユーザ群Ｃへの公開時刻が過ぎたデータ４０２が参照可能である。ここで、データ４０３のユーザ群Ａに対する公開時刻はデータ４０４の公開時刻よりも遅くなっているが、本システムには、システム時刻が公開時刻に到達しているデータが複数存在する場合、更新時刻が最も新しいデータを参照可能にするというルールがあり、データ４０３はユーザ群Ａに対して公開されない。このルールは、最新データを更新したにも関わらず、その情報を自分で参照することができないという状態に陥るのを防ぐために存在する。
【００３０】
図７（ｂ）は、対象のデータにおいて、ユーザ群Ｂからユーザ群Ａへの干渉許可設定を「不許可」に設定している例を示している。干渉許可設定を「不許可」にすると、それ以降、対象のデータに対して相手のユーザ群による更新内容が反映されなくなり、自分だけの独自環境を作ることができる。逆に、「許可」に設定すると、相手のユーザ群の更新内容が反映されるようになる。干渉許可設定は、通常は「許可」の状態になっている。干渉許可設定はユーザ群の組み合わせごとに設定可能である。干渉許可設定は、テストデータやシミュレーションデータを作る場合などに有効である。
【００３１】
図７（ｂ）において、ユーザ群Ｂによる更新内容はユーザ群Ａには反映されないため、ユーザ群Ｂが更新したデータ４１２，４１３の公開時刻は既に過ぎているが、ユーザ群Ａが参照可能なデータは自分自身が更新したデータ４１１である。ユーザ群Ｂ及びユーザ群Ｃは、干渉許可設定が通常の状態（許可）になっているため、最新データ４１３を参照可能である。なお、実際のシステムにおいては図５（ｂ）にて説明したように、データ４１２，４１３のヘッダ部では、ユーザ群Ａへの公開時刻の情報は別領域に退避されていて、その代わりに、実用上無限の未来とみなせるような無限未来時刻が、ユーザ群Ａへの公開時刻として記憶されている。
次に、図８から図１７のフローチャートを参照して、ＤＢＭＳ４を構成する各手段の処理について説明する。
【００３２】
図８は、データ検索手段１１１の処理手順を示すフローチャートである。アプリケーションプログラム３からある検索条件が与えられてデータ検索手段１１１が呼び出されると、全データ対象検索手段１２１を呼び出し、与えられた検索条件を満たすデータを、ユーザに対する公開時刻に関係なく全て読み出す（ステップ１１１１）。次に、公開データ取得手段１２２を呼び出し、得られたデータｄの更新前データ及び更新後データを調べ、当該手段を呼び出したユーザに公開されているデータｄ’を読み出す（ステップ１１１２）。次に、データｄとデータｄ’が等しいかを判定し（ステップ１１１３）、等しければ、判定結果はデータｄが公開されていることを意味するので、データｄを検索結果として採用する（ステップ１１１４）。一方、等しくなければ、判定結果はデータｄが公開されていないことを意味するので、データｄを検索結果から除外する（ステップ１１１５）。そして、ステップ１１１１で得られた全てのデータに対してステップ１１１２〜１１１５の処理が終了すると、アプリケーションプログラム３に制御を戻す。
【００３３】
図９は、データ更新手段１１２の処理手順を示すフローチャートである。まず、データ検索手段１１１を呼び出し、更新対象のデータｄを検索して読み出す（ステップ１１２１）。なお、ステップ１１２１は、データを更新又は削除を行う場合に実行され、データの登録を行う場合には実行されない。次に、制約条件検証手段１２３を呼び出し、データｄの更新によってＤＢの制約条件が破られるか否かを調べる（ステップ１１２２）。制約条件が破られるという判定結果が得られた場合は、それ以上ＤＢ２へのアクセスは行わずに、アプリケーションプログラム３に制御を戻す。一方、制約条件が破られないという判定結果が得られると、データの登録を行う場合にはデータ登録手段１１３を呼び出してＤＢ２にデータを登録し（ステップ１１２３）、データの更新又は削除を行う場合にはデータ更新・削除手段１１４を呼び出して、ＤＢ２に記憶されているデータを更新し（ステップ１１２４）、その後、アプリケーションプログラム３に制御を戻す。
【００３４】
図１０は、データ更新手段１１２のサブルーチンであるデータ登録手段１１３の処理（図９のステップ１１２３）を説明するフローチャートである。図１０において、まず、干渉許可設定書き込み制御手段１３４を呼び出し、登録対象のデータｄの干渉許可設定をＤＢ２の干渉許可設定記憶領域１０２に記憶させる（ステップ１１３１）。次に、公開時刻の修正を伴うデータ更新処理２０１（図１７参照）を呼び出し、データｄをＤＢ２のデータ・公開時刻記憶領域１０１に記憶させる（ステップ１１３２）。以上の処理が終了した後、データ更新手段１１２に制御を戻す。なお、データｄの実体よりも干渉許可設定の方を先に記憶させている理由は、公開時刻の修正を伴うデータ更新処理２０１において、データｄの公開時刻の設定に干渉許可設定を反映させる際、ＤＢ２の干渉許可設定記憶領域１０２に記憶されているデータｄの干渉許可設定を参照するためである。
【００３５】
図１１は、データ更新手段１１２のサブルーチンであるデータ更新・削除手段１１４の処理（図９のステップ１１２４）を説明するフローチャートである。図１１において、まず、当該手段を呼び出したユーザのユーザ群と、更新対象のデータｄの作成者のユーザ群が等しいか調べる（ステップ１１４１，１１４２）。ここで、データｄの作成者とは、過去にデータ更新手段１１２を用いて、データｄを更新後データとしてＤＢ２に記憶せしめたユーザを意味する。判定結果が「等しい」の場合は、データｄの作成者のユーザ群以外でデータｄを参照可能なユーザ群が存在するか否かを調べる（ステップ１１４３）。そして、参照可能なユーザ群が他に存在しない場合は、公開時刻の修正を伴うデータ更新処理２０１を呼び出し、データｄに対して更新後データｄ’をＤＢ２に上書き記憶させる（ステップ１１４４）。一方、ステップ１１４２における判定結果が「等しくない」の場合及びステップ１１４３における判定結果が「存在する」の場合は、データｄの更新後も他のユーザ群から更新前のデータが参照される可能性があるため、データｄをデータ・公開時刻記憶領域１０１に残しておく必要がある。そこで、公開時刻の修正を伴うデータ更新処理２０１を呼び出し、データｄをコピーしてデータ記憶領域１０１に残し、更新後データｄ’を新しいデータとして記憶させる（ステップ１１４５）。ステップ１１４４あるいはステップ１１４５の処理が終了した後、データ書き込み制御手段１３２を呼び出し、更新前データの不要データ化時刻を再計算し、それを上書き記憶させる（ステップ１１４６）。ここでは、不要データ化時刻は、当初の更新前データｄのみならず、他の過去のデータに対しても修正する。以上の処理が終了した後、データ更新手段１１２に制御を戻す。なお、ステップ１１４３の判定は、対象データｄの不要データ化時刻と、データｄの作成者のユーザ群以外に対する最も早い公開時刻をそれぞれシステム時刻と比較することによって、容易に判定できる。
【００３６】
ステップ１１４４において、データを上書きする理由は、今後に渡って更新前のデータｄが他のユーザ群から参照されることはなく、代わりに更新後データｄ’が参照されることになるため、更新前のデータｄをデータ・公開時刻記憶領域１０１に残しておく必要が無いからである。逆に、データ更新後も他のユーザ群から更新前のデータｄが参照される可能性がある場合は、ステップ１１４５を実行して、更新前データをデータ・公開時刻記憶領域１０１に残す仕組みである。ステップ１１４６において、不要データ化時刻の計算は、厳密に計算すると、計算量がかなり多くなる。しかし、例えば、最新データの最も遅い公開時刻をそれ以前の全てのデータの不要データ化時刻として採用するなど、概算的な手法を用いることによって、計算量を減らすことができる。ただし、概算的な手法を用いた場合は、あるデータが不要データか否かを判定するときの精度が落ちるため、結果としてシステムのパフォーマンスが落ちる場合がある。従って、ここは、それぞれの処理におけるパフォーマンスのトレードオフの問題となる。
【００３７】
図１２は、干渉許可設定変更手段１１５の処理手順を示すフローチャートである。まず、データ検索手段１１１を呼び出し、設定変更対象のデータｄを検索して読み出す（ステップ１１５１）。次に、設定変更内容によって場合分けし（ステップ１１５２）、「不許可」から「許可」への変更の場合は、データ書き込み制御手段１３２を呼び出し、データ・公開時刻記憶領域１０１において、データｄ及びその更新前・更新後データについて、設定変更対象のユーザ群に対する公開時刻（無限未来時刻になっている）を、退避領域に記憶させておいた正規の公開時刻で上書き記憶させる（ステップ１１５３）。次に、干渉許可設定書き込み制御手段１３４を呼び出し、データｄの新しい干渉許可設定を干渉許可設定記憶領域１０２に記憶させる（ステップ１１５４）。一方、「許可」から「不許可」への変更の場合は、データ・公開時刻記憶領域１０１にはアクセスせず、干渉許可設定書き込み制御手段１３４を呼び出し、データｄの新しい干渉許可設定を干渉許可設定記憶領域１０２に記憶させる。以上の処理が終了した後、アプリケーションプログラム３に制御を戻す。
【００３８】
図１３は、不要データ削除手段１１６の処理手順を示すフローチャートである。この処理では、データ書き込み制御手段１３２を呼び出し、システム時刻が不要データ化時刻に到達しているデータをデータ・公開時刻記憶領域１０１から全て削除し（ステップ１１６１）、その後、アプリケーションプログラム３に制御を戻す。この不要データ削除手段１１６を実行することによって、データ・公開時刻記憶領域１０１の記憶容量が節約でき、また、余分なデータが少なくなるので検索手段の処理効率が向上し、結果として、システム全体のパフォーマンスが向上する。なお、テストなどのために、過去のシステムの状態を再現したい場合は、不要データ削除手段１１６を呼び出す前に不要データのバックアップを取るなど、従来の技術に頼ればよい。あるいは、不要データ削除手段を呼び出さないようにしておけば、システム時刻を過去の時刻に戻し、検索時にはシステム時刻以降に作成されたデータを無視することにより、過去のシステムの状態を容易に再現できる。従って、不要データ削除手段１１６をどのように利用するかは、システムの管理方針や運用状態などを考慮した上で決める必要がある。
【００３９】
図１４は、全データ対象検索手段１２１の処理手順を示すフローチャートである。この処理においては、データ読み出し制御手段１３１を呼び出し、呼び出し元の処理によって与えられた検索条件と、不要データでないという検索条件とを満たす全てのデータを公開時刻に関係なく読み出し（ステップ１２１１）、該当するデータを取得した後、呼び出し元の処理に制御を戻す。
【００４０】
図１５は、公開データ取得手段１２２の処理手順を示すフローチャートである。図１５において、まず、データ読み出し制御手段１３１を呼び出し、対象データｄ及びその更新前・更新後データにおいて、システム時刻が当該手段を呼び出したユーザに対する公開時刻に到達しているという条件と、前述の条件を満たすデータのうち最新のものであるという条件とを満たすデータｄ’を読み出し（ステップ１２２１）、該当するデータを取得した後、呼び出し元の処理に制御を戻す。
【００４１】
図１６は、制約条件検証手段１２３の処理手順を示すフローチャートである。まず、制約条件読み出し・書き込み制御手段１３５を呼び出し、更新対象のデータｄが関係する制約条件を制約条件記憶領域１０３より取得する（ステップ１２３１）。次に、全データ対象検索手段１２１を呼び出し、データｄの制約条件の検証に必要な全てのデータを、公開時刻に関係なく読み出す（ステップ１２３２）。次に、得られたデータに更新後データを一時的に追加して、その中で対象の制約条件が保たれるかを調べ（ステップ１２３３）、制約条件が保たれれば、制約条件は破られないという検証結果を呼び出し元の処理に返す（ステップ１２３４）。一方、保たれなければ、制約条件が破られるという検証結果を呼び出し元の処理に返す（ステップ１２３５）。この制約条件検証手段１２３がシステムに存在するために、各ユーザ群の間で未公開のデータが多数存在しても、主キー属性の衝突などの致命的な事故がどのユーザ群の環境においても起こらないようになっている。
【００４２】
図１７は、データ登録手段１１３及びデータ更新・削除手段１１４のサブルーチンである、公開時刻の修正を伴うデータ更新処理２０１（図１０のステップ１１３２及び図１１のステップ１１４５）の処理手順を示すフローチャートである。図１７において、まず、干渉許可設定読み出し制御手段１３３を呼び出し、更新対象のデータｄに対する干渉許可設定を干渉許可設定記憶領域１０２より取得する（ステップ２０１１）。次に、データｄを更新するユーザが属するユーザ群からあるユーザ群ｕへの干渉許可設定を調べ（ステップ２０１２）、「不許可」であれば、ヘッダ情報記憶用の一時記憶領域において、ユーザ群ｕに対する正規の公開時刻は退避用領域に記憶させ、無限未来時刻をユーザ群ｕに対する公開時刻として記憶させる（ステップ２０１３）。一方、「許可」であれば、ヘッダ情報記憶用の一時記憶領域において、ユーザ群ｕに対する正規の公開時刻をそのまま公開時刻として記憶させる（ステップ２０１４）。全てのユーザ群に対してこの処理を繰り返し、最終的に一時記憶領域に記憶されたヘッダ情報（公開時刻の情報を含む）とともにデータｄをデータ・公開時刻記憶領域１０１に記憶させるために、データ書き込み制御手段１３２を呼び出し（ステップ２０１５）、ＤＢ２にアクセスせしめた後、呼び出し元の処理に制御を戻す。
【００４３】
次に、データ・公開時刻記憶領域１０１に記憶されるデータのデータ形式について説明する。データ・公開時刻記憶領域１０１に記憶されるデータは、データ本体の他に、公開時刻の情報やデータの更新・削除に関する情報をヘッダ情報として含んでおく必要がある。
【００４４】
図１８は、データ・公開時刻記憶領域１０１に記憶される具体的なデータ形式の一例を示す図である。図１８では、ヘッダ部は連番５１１、フラグ類５１２、不要データ化時刻５１３、データを更新したユーザ群のＩＤ５１４、公開時刻記憶領域５１５、公開時刻退避領域５１６から構成され、データ部はレコード５２１のみから構成される。連番５１１はデータが更新される度に加算される番号であり、データの新しさを判断する基準となる。フラグ類５１２には削除フラグなどが含まれ、データ更新の種別を判断する基準となる。データを削除する場合は、削除フラグをオンにしたデータをデータ・公開時刻記憶領域１０１に記憶させることになる。不要データ化時刻５１３は、図１３などでも説明したように、そのデータが不要データか否かを判断するために用いられる。データを更新したユーザ群のＩＤ５１４は、図１１で説明したデータ更新手段１１４などで用いられる。公開時刻記憶領域５１５は各ユーザ群への公開時刻を記憶するための領域である。公開時刻退避領域５１６は、図１７のステップ２０１３の説明にあったように、干渉許可設定が「不許可」のユーザに対する公開時刻を退避させておくために用いられる。なお、従来のリレーショナルデータベースでは、主キー属性によってレコードが一意に識別できるが、本システムにおけるデータ・公開時刻記憶領域１０１では、レコード５２１の主キー属性と、ヘッダ部の連番５１１との組み合わせによって、データが一意に識別できる。従って、例えば、制約条件検証手段１２３において、データの一意性を検証する場合、これらの組み合わせを参照することによって検証することが可能である。
【００４５】
図１９は、互いに異なる２個のデータが、他のユーザ群に公開される例を時間軸によって示す図である。図１９では、時刻６０１において、ユーザ群Ａに属するユーザがデータ６１を登録し、その後、時刻６０２において、同じユーザが別のデータ６２を登録している。ところが、ユーザ群Ｂに対する公開時刻は、データの登録とは逆に、データ６２の方がより早く（時刻６０３）、データ６１の方がより遅く（時刻６０４）設定されていた。公開時刻の順序を逆に設定した理由としては、データ６２の内容を緊急にデータ群Ｂに対して公開しなければならなかったとか、データ６１の内容を公開する前にユーザ群Ａの間でよく吟味する必要があったとか、色々と考えられる。いずれにせよ、その結果、ユーザ群Ｂからは、データ６１よりもデータ６２の方が先に登録されたように見えることになった。このように、ユーザによってＤＢの時系列情報が見かけ上変化するようなことは、単純にＤＢの時系列情報を保存するような従来の方法では実現され得ない。また、このような特異な現象が発生した場合でも、本発明のシステムでは、制約条件検証手段１２３が働くため、ＩＤの衝突のような致命的な事故を防ぐことができ、安定したシステム運用を実現できる。
【００４６】
【発明の効果】
本発明によれば、データベースを利用する他のユーザ群に対してＤＢの更新内容を一定期間隠蔽することができ、しかも、それぞれの更新内容をマージした結果を容易に得ることができる。
【図面の簡単な説明】
【図１】本発明によるデータベースシステムの構成例を示す図。
【図２】本発明によるデータベース管理システムとデータベースの構成例及び各処理の関連を示す図。
【図３】データの公開時刻の設定によってデータが公開される仕組みの説明図。
【図４】データとその公開時刻を記憶させるためのレコードの例を示す図。
【図５】公開時刻記憶領域と退避領域に時刻が記憶される様子を示す図。
【図６】干渉許可設定記憶領域に記憶されているユーザ間の干渉に関するデータ例を示す図。
【図７】公開時刻及び干渉許可設定の設定例と参照可能なデータの関係を示す図。
【図８】データ検索手段の処理手順を示すフローチャート。
【図９】データ更新手段の処理手順を示すフローチャート。
【図１０】データ登録手段の処理を示すフローチャート。
【図１１】データ更新・削除手段の処理を示すフローチャート。
【図１２】干渉許可設定変更手段の処理手順を示すフローチャート。
【図１３】不要データ削除手段の処理手順を示すフローチャート。
【図１４】全データ対象検索手段の処理手順を示すフローチャート。
【図１５】公開データ取得手段の処理手順を示すフローチャート。
【図１６】制約条件検証手段の処理手順を示すフローチャート。
【図１７】公開時刻の修正を伴うデータ更新処理の処理手順を示すフローチャート。
【図１８】データ・公開時刻記憶領域に記憶されるデータ形式の一例を示す図。
【図１９】２個のデータが公開される例を示す図。
【符号の説明】
１…中央処理装置、２…データベース（ＤＢ）、３…アプリケーションプログラム、４…データベース管理システム（ＤＢＭＳ）、１０１…データ・公開時刻記憶領域、１０２…干渉許可設定記憶領域、１０３…制約条件記憶領域、１１１…データ検索手段、１１２…データ更新手段、１１５…干渉許可設定変更手段、１１６…不要データ削除手段、１２１…全データ対象検索手段、１２２…公開データ取得手段、１２３…制約条件検証手段
Claims (4)
- データを記憶するデータベース及び前記データベースを管理するデータベース管理システムを含むデータベースシステムにおいて、
前記データベースは、データ及び当該データをユーザに対して公開する公開時刻の情報と、第１のユーザによるデータの更新内容を前記第１のユーザと異なる第２のユーザ用のデータに反映させることを「許可」するか「不許可」にするかを示す干渉許可情報を記憶しており、
前記データベース管理システムは、前記データベースに格納されているデータを更新するデータ更新手段と、アプリケーションプログラムからの検索要求によって呼び出されるデータ検索手段と、前記データ検索手段によって呼び出される全データ対象検索手段と、公開データ取得手段と、を備え、
前記データベースに格納されているデータに変更を加えて更新する場合、前記データ更新手段は、前記干渉許可情報が「許可」を示しているときには、前記第２のユーザに対して公開するデータとして更新後のデータのみを前記データベースに保存し、前記干渉許可情報が「不許可」を示しているときには、前記第２のユーザに対して公開するデータとして更新前データを保持し、さらに前記第１のユーザに対して公開するデータとして更新後データを前記データベースに登録し、
前記データベースに格納されているデータを検索して読み出す場合、前記全データ対象検索手段は、前記公開時刻の情報を無視して前記データ検索手段から渡された検索条件を満たす前記データベースのデータを全て検索し、
前記公開データ取得手段は、前記干渉許可情報が「許可」の場合、前記全データ対象検索手段が検索したデータのうち前記データ検索手段を呼び出したユーザへの公開時刻に達しているデータの中で更新時刻が最も新しいデータを前記第１及び第２のユーザに対して公開するための検索結果として取得し、前記干渉許可情報が「不許可」の場合、前記第２のユーザに対して公開するための検索結果としては前記更新前データ又は前記第２のユーザ自身が更新したデータを取得し、前記第１のユーザに対して公開するための検索結果としては前記更新時刻が最も新しいデータを取得することを特徴とするデータベースシステム。 - 請求項１に記載のデータベースシステムにおいて、前記データベース管理システムは、さらに、ユーザによって入力された指示に従って、前記干渉許可情報を変更する干渉許可設定変更手段を備えることを特徴とするデータベースシステム。
- 請求項１又は２に記載のデータベースシステムにおいて、前記干渉許可情報が「不許可」を示しているとき、前記データベース管理システムは、前記第１のユーザが更新したデータの前記第２のユーザへの公開時刻として実用上無限の未来を表す時刻を設定することを特徴とするデータベースシステム。
- 請求項１乃至３いずれか１項に記載のデータベースシステムにおいて、前記データベース管理システムは、前記データベースにアクセスしたユーザからのデータ要求に対して、当該ユーザへの公開時刻に達している該当データのうち更新時刻が最も新しいデータを現在のデータとして出力することを特徴とするデータベースシステム。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003041587A JP4402891B2 (ja) | 2003-02-19 | 2003-02-19 | データベースシステム |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003041587A JP4402891B2 (ja) | 2003-02-19 | 2003-02-19 | データベースシステム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2004252671A JP2004252671A (ja) | 2004-09-09 |
| JP4402891B2 true JP4402891B2 (ja) | 2010-01-20 |
Family
ID=33025126
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2003041587A Expired - Fee Related JP4402891B2 (ja) | 2003-02-19 | 2003-02-19 | データベースシステム |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP4402891B2 (ja) |
-
2003
- 2003-02-19 JP JP2003041587A patent/JP4402891B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2004252671A (ja) | 2004-09-09 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US8655896B2 (en) | Apparatus and methods for organizing data items having time of life intervals | |
| US8527556B2 (en) | Systems and methods to update a content store associated with a search index | |
| KR101738647B1 (ko) | 데이터 유지 시스템 | |
| JP2002503000A (ja) | ウェブサイトを開発するためのシステムと方法 | |
| JPH0916607A (ja) | データベース管理システムにおけるインデクス管理方法 | |
| US8959096B2 (en) | Apparatus and methods for organizing data items by directed acyclic graphs | |
| US11151081B1 (en) | Data tiering service with cold tier indexing | |
| US20120185500A1 (en) | Data storage and management system | |
| US7269589B2 (en) | Database managing method and system having data backup function and associated programs | |
| US20060004877A1 (en) | Method and system for data processing with data replication for the same | |
| US10585918B2 (en) | Overlay dataset | |
| JP4402891B2 (ja) | データベースシステム | |
| US7693883B2 (en) | Online data volume deletion | |
| JP3484440B2 (ja) | 分散型データベース更新方法 | |
| JP3239924B2 (ja) | リレーショナルデータベースアクセス制御方式 | |
| JP3769775B2 (ja) | 分散リンク情報維持方法 | |
| JP2643811B2 (ja) | データベース再編成方式 | |
| US8706769B1 (en) | Processing insert with normalize statements | |
| JPH08106473A (ja) | データベース管理システム | |
| JP3245047B2 (ja) | バージョン管理装置及び方法 | |
| JPH11110262A (ja) | 情報管理システム | |
| US8452823B2 (en) | Method for coordinating relationships between multiple physical entities | |
| JP3005476B2 (ja) | ハッシュテーブルの動的変更システム | |
| JPH05158777A (ja) | データ管理システム | |
| JP2006040064A (ja) | データベースアクセス装置 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20050615 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20080919 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20081202 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20090202 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20090804 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20091002 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20091027 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20091030 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121106 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121106 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20151106 Year of fee payment: 6 |
|
| LAPS | Cancellation because of no payment of annual fees |