JP2002157158A - データベースシステムにおけるデータ管理方法 - Google Patents

Abstract

(57)【要約】 【課題】複数データベース間のデータ管理において、更
新処理の同期を行うにあたり同期タイミングの相違によ
る不整合性発生を防止することでシステムの利便性を向
上する。 【解決手段】主データベースにおいてデータの更新を管
理し、１つ以上の従データベースへ更新データを同期す
るデータベース間の同期方法として、即時、或いは遅延
の何れかの同期タイミングを設定しておき、その設定条
件に従って同期処理を行うにあたって、要求される即時
処理の内容と遅延処理としてログに記録された更新デー
タを関連付けることによって、必要な更新データを一括
した同期データを生成し、前記同期データを従データベ
ースへ同期する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、データベースシス
テムにおけるデータベース間のデータ同期を実現するデ
ータ管理方法に関するもので、特に、第１のサーバにお
いてデータを一元的に管理し、更新データを同期設定に
基づいて第２のサーバが管理するデータに同期すること
を行うデータ管理方法及びデータ管理システムに関す
る。

【０００２】

【従来の技術】企業情報システムなどの大規模情報シス
テムにおいては、社員の個人データ、組織データなどを
管理するため、あるいは業務関連の情報の蓄積や共有の
ために広くデータベースが用いられている。このような
目的で使用されるデータベースの１つとして、ディレク
トリシステムが挙げられる。

【０００３】例えばディレクトリシステムは、電子メー
ルの送信相手の姓名などからメールアドレスを検索す
る、所謂電子電話帳機能として利用されている。

【０００４】ディレクトリシステムは、人、組織、ネッ
トワーク機器など管理対象となる情報を木構造で表現す
る。この木構造データモデルは、ディレクトリシステム
に関する標準として、ＣＣＩＴＴの勧告であるＸ．５０
０（ＩＳＯ９５９４）によって規定されたものである。
木構造の枝葉に相当する箇所には、ディレクトリエント
リが配置され、これが人や組織を表すデータ単位とな
る。各々のエントリは、ディレクトリツリーのルートか
らのパスを示す名称であるＤＮ（Ｄｉｓｔｉｎｇｕｉｓ
ｈｅｄ Ｎａｍｅ）によって一意に識別される。さら
に、各々のエントリはユーザのメールアドレスに加え、
姓名、電話番号、ＦＡＸ番号など、様々な情報を属性と
して記憶可能である。

【０００５】また、Ｘ．５００はディレクトリシステム
をクライアント・サーバシステムとして規定しており、
ディレクトリクライアントは、前記ディレクトリデータ
に対してＤＮによる読み出し及び更新、ディレクトリエ
ントリのデータである属性をキーとした検索が可能であ
る。このデータの読み出しや更新、検索の時に使用され
るクライアント・サーバ間の通信プロトコルとして、Ｏ
ＳＩ（Ｏｐｅｎ Ｓｙｓｔｅｍｓ Ｉｎｔｅｒｃｏｎｎｅ
ｃｔｉｏｎ）の７レイヤーモデルに基づくＤＡＰ（Ｄｉ
ｒｅｃｔｏｒｙ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ）が
規定されている。しかし、このＤＡＰはＯＳＩスタック
を必要とする負荷の高いプロトコルであることから、そ
の使用が倦厭されてきた。

【０００６】そこで、アメリカのミシガン大学が、より
軽量なディレクトリアクセス用のプロトコルとしてＬＤ
ＡＰ（Ｌｉｇｈｔｗｅｉｇｈｔ Ｄｉｒｅｃｔｏｒｙ
Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ）（ＲＦＣ２２５１）
を開発した。ＬＤＡＰはＤＡＰのサブセットであり、Ｔ
ＣＰ／ＩＰスタック上で動作し、インターネット標準化
団体であるＩＥＴＦ（Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅ
ｅｒｉｎｇ ＴａｓｋＦｏｒｃｅ）により標準化され
た。

【０００７】ところで、昨今の企業情報システムにおい
ては、様々な業務を行うために必要に応じて電子メール
システムをはじめ、ネットワークＯＳやグループウェア
など、種々のアプリケーションが導入されている。しか
し、これらのアプリケーションは、ユーザ情報、組織情
報などのデータを個別に管理する必要があった。そのた
め、システム管理者は人事異動や組織改編などのデータ
更新の度に、情報システム内で更新を必要とする全ての
アプリケーションのデータを管理しなければならず、そ
の運用負荷は増大する一方であった。

【０００８】例えば、人事データベースとグループウェ
アの双方で社員氏名、社員コードを管理するなど、情報
システム内の各アプリケーションが管理するデータには
重複した属性が多く存在するが、これらの属性を管理す
るアプリケーションの多くは、ユーザ情報を独自のデー
タベースを用いて独自の形式で管理しているのが現状で
あった。

【０００９】そのため、運用対象となる複数のアプリケ
ーションデータを一元管理するメタディレクトリシステ
ムが注目されている。メタディレクトリシステムは、デ
ィレクトリシステムに対して行われた更新を自動的にア
プリケーションのデータベースへ反映させることによ
り、ディレクトリシステムに登録されているユーザ情
報、組織情報をはじめとする各種資源情報と、各アプリ
ケーションのデータベースに登録されている情報との同
期をとる。これにより、ユーザがパスワードの変更を行
う時に全てのアプリケーションに対して変更処理を行う
といった複数のアプリケーションに重複した属性の個別
管理の必要がなくなり、ユーザのデータ管理負荷を軽減
できる。

【００１０】前記メタディレクトリシステムは、同期対
象となる複数のアプリケーションやアプリケーションが
管理する属性に対して個別に同期タイミングを設定可能
である。

【００１１】このようなデータの一貫性管理方法の従来
技術として特開平１１−２１９３０９号公報が挙げられ
る。

【００１２】前記一貫性管理方法においては、主データ
ベースと複数の従データベースの間で、全ての処理に対
するデータの同期を即時に行うことで厳格な一貫性管理
を行うか、或いは遅延して同期することにより厳格性を
緩和した一貫性管理を行うかを選択可能である。

【００１３】例えば、アプリケーションでユーザ認証に
用いられるパスワードなどの属性は本人認証の度に使用
する緊急性の高い属性であるため、この属性が更新され
た場合にその更新内容は即時に同期する一方で、新入社
員の入社や人事異動などに伴い大量のユーザ情報の登
録、更新を行う必要がある場合には、同期の即時性より
も１日の更新データを夜間バッチ処理により一括して同
期することでネットワーク負荷を軽減することが可能で
ある。

【００１４】

【発明が解決しようとする課題】しかしながら、上記の
ようなデータベースシステムの一貫性管理方法において
は、更新処理の種類或いは更新対象の属性に対応したデ
ータベース間のデータ同期のタイミングを設定すること
は可能であったが、以下に述べるように、データベース
間のデータの整合性が保証されないという問題があっ
た。

【００１５】例えば、追加・変更・削除といった更新種
別や、その更新対象の属性によって情報システムにおけ
る緊急性が異なるため、それぞれ適切な同期タイミング
の設定を行った場合に、同期タイミングの相違により主
データベースと従データベース上のデータ間が不整合と
なることがあった。その結果、システム管理者からの整
合性回復作業が必要となり、また、ユーザはデータベー
ス間で異なるデータに基づいて誤った業務を遂行してし
まう可能性があり、利便性の面で問題があった。

【００１６】具体的に、ユーザや組織などの追加処理に
ついてはネットワーク負荷を低く押さえるために日次で
一括して従データベースへ同期し、パスワードなどの緊
急性の高いデータの更新処理については即時に同期した
いというケースについて説明する。

【００１７】この場合、主データベース上にユーザが初
期登録された時にはデフォルトのパスワードが付与さ
れ、同ユーザが直ちにパスワードの変更を要求すると、
同ユーザの更新されたパスワードを従データベースへ即
時に同期することとなる。しかし、この時点では主デー
タベース上に追加されたユーザ情報が従データベースに
同期されていないため、従データベース上には当該ユー
ザ情報が格納されておらず、パスワードの同期処理を実
行することができない。

【００１８】本発明の目的は、ディレクトリシステムを
はじめとしたデータベースシステムにおいて、複数のデ
ータベースが稼働している環境における整合性を保証し
たデータ同期方法を提供してデータベースシステムの利
便性の向上を図ることである。

【００１９】

【課題を解決するための手段】上記の目的を達成するた
め、本発明は、複数のサーバが伝送媒体を介して相互に
接続された環境でデータベース間の更新内容に対応する
同期タイミングをあらかじめ設定可能なデータベースシ
ステムにおいて、データベースへの更新処理に対するデ
ータベース間の整合性管理方針を主データベースに決定
しておき、更新処理の発生時に設定に基づいて更新処理
種別と処理の対象となるオブジェクト、及び属性を関連
付け、主データベースから従データベースへ更新データ
の同期を行うデータ管理方法を提供する。

【００２０】かかるデータ管理方法を用いることによ
り、データベースシステムにおける更新データの同期方
法として、即時、或いは遅延の何れかの同期タイミング
を設定しておき、設定された同期方法を基に、主データ
ベースに要求される即時処理の内容と既に要求された処
理が遅延処理としてログに記録された更新データを関連
付けることによって、必要な更新データを一括した同期
データを生成すると共に従データベースへ同期して、デ
ータベース間の整合性を保証した同期処理を実現する。

【００２１】また、本発明は、上記主データベースで行
われたデータ更新を従データベースに同期する方式を設
定するために、主データベースに、同期対象データベー
ス毎に個別の設定を行うための同期データベース管理を
行うと同時に、更新処理の種別、処理の対象となる属性
毎に適用する同期タイミングを記憶するテーブル手段
と、データの遅延同期を行うために遅延同期の対象とし
て設定された更新処理の内容を記録するログ手段と、主
データベースに対して行われた更新データを従データベ
ースに同期するための更新データの生成手段と、前記更
新データの従データベースに対する同期処理を実行する
手段を有するデータベースシステムにおいて、主データ
ベースに対して発生した更新処理種別と処理対象となる
属性、同期対象オブジェクト、及び同期タイミングを関
連付ける手段を有するデータ管理方法を提供する。

【００２２】かかるデータ管理システムを用いることに
より、前記データベース間の整合性を保証した同期処理
を実現するデータ管理方法を提供することが可能とな
る。

【００２３】さらに、前記データ管理方法を提供するに
あたって、更新処理の発生時に設定に基づいて更新処理
種別と処理の対象となるオブジェクト、及び属性を関連
付け、主データベースから従データベースへ更新データ
の同期を行うデータ管理手段をクライアントが有するデ
ータ管理方法を提供する。

【００２４】かかるデータ管理システムを用いることに
より、データ更新時の主データベースの負荷を軽減する
ことが可能となる。

【００２５】

【発明の実施の形態】以下、本発明の実施の形態につい
て図面を用いて詳細に説明する。以下の図中において、
同一の部分には同一の符号を付与する。

【００２６】本実施例においては、本発明を適用するデ
ータベースシステムとして、主データベースとして動作
する共通リポジトリにおいてデータを一元管理すると共
に、共通リポジトリに対して行われた更新データを従デ
ータベースとして動作するアプリケーションサーバへ同
期するデータ管理システムについて説明するが、本実施
例以外にも、複数のサーバにデータを分散して管理する
分散データベースシステムに対しても適用可能である。

【００２７】図１は本発明を実現するデータ管理システ
ムの機能構成図である。

【００２８】ＬＡＮなどの伝送媒体２２により共通リポ
ジトリ１０、アプリケーションサーバ２０、クライアン
ト４０が接続されている。

【００２９】共通リポジトリ１０は管理するデータをＤ
Ｂ１００に記憶し、アプリケーションサーバ２０は独自
の処理に必要なデータをＤＢ２１に記憶する。

【００３０】共通リポジトリ１０は、クライアント４０
やアプリケーションサーバ２０との通信処理を実行する
通信制御部２３、ユーザからの入力、及びユーザへの出
力処理を制御するユーザインタフェース制御部２４、同
期方式に関する設定を記憶する同期管理テーブル２、受
信した処理の内容を解析するアクセス要求解析部１、処
理の内容に従ってＤＢ１００を更新するＤＢ制御部２
５、遅延同期する更新データを記録しておく遅延更新ロ
グ６、更新処理の解析結果、同期管理テーブル２の同期
設定、及び遅延更新ログ６に記録された更新内容を基
に、同期処理の整合性を保証して適切な同期方式を決定
する同期整合性管理部３、アプリケーションサーバ２０
へ同期するデータを生成し遅延更新ログ６に対して生
成、書き込み、削除などの処理を行う更新データ生成部
４、生成された同期データをアプリケーションサーバ２
０に同期するために通信制御部２３に同期データを通知
する同期制御部５を有する。

【００３１】アクセス要求解析部１は、共通リポジトリ
１０に対して要求された更新処理の発生をトリガに要求
された処理の内容を解析し、更新処理であるかどうかを
判別する。その結果が更新処理であった場合には、更新
種別を判別する。

【００３２】本実施例は、図１のような機能構造を有す
るデータ管理方法を実現するデータ管理システムであ
る。

【００３３】図２は本実施例のデータ管理システムのシ
ステム構成である。

【００３４】共通リポジトリ１０は、中央演算装置ＣＰ
Ｕ３４、ハードディスクなどの２次記憶媒体（以下、磁
気ディスクという）３３、主記憶装置メモリ（以下、主
メモリという）３１、データバス３２、表示装置などの
出力装置（以下、ディスプレイという）３５、入力装置
（以下、キーボード３６、マウス３７という）から構成
される。

【００３５】図２のＤＢ１００は、データを磁気ディス
ク３３上に格納する。また、遅延更新ログ６、同期管理
テーブル２も同様に磁気ディスク３３上に格納する。

【００３６】主メモリ３１には、通信制御プログラム２
３、ユーザインタフェースプログラム２４、アクセス要
求解析プログラム１、同期制御プログラム５、同期整合
性管理プログラム３、更新データ生成プログラム４、Ｄ
Ｂ制御プログラム２５が格納される。これらのプログラ
ムは、磁気ディスク３３に格納されており、必要に応じ
て主メモリ３１に転送された後、ＣＰＵ３４で実行され
る。

【００３７】続いて、本実施例における同期管理テーブ
ル２、及び遅延更新ログ６について図３を用いて説明す
る。

【００３８】同期管理テーブル２は、共通リポジトリ１
０とアプリケーションサーバ２０との同期方法に関する
設定を記憶するテーブルであり、１つの同期アプリケー
ション毎に１テーブルを有する配列構造をなし、同期対
象アプリケーション数のテーブルから成る。各テーブル
は同期ＡＰ管理領域２００、オブジェクト更新種別管理
テーブル２１０、同期属性管理テーブル２２０から構成
される。

【００３９】同期ＡＰ管理領域２００は、同期対象アプ
リケーションの種別と同期処理に使用するＩＤを設定す
る記憶領域であり、同期ＡＰ種別２０１と識別ＩＤ２０
２を記憶する２つの領域から構成される。同期アプリケ
ーション種別２０１にはアプリケーションの種類やその
名称などのデータが格納され、識別ＩＤ２０２には同期
処理において設定を参照する時にアプリケーションの識
別を可能にするために一意の整数値が格納される。

【００４０】オブジェクト更新種別管理テーブル２１０
は、更新種別とそれに対応する同期タイミングを設定す
るテーブルであり、前記テーブル２１０の各レコード
は、更新種別２１１、及び同期方式２１２から構成され
る。更新種別２１１には、共通リポジトリ１０のＤＢ１
００に対する更新処理であるデータの追加（ａｄｄ）、
削除（ｄｅｌｅｔｅ）の何れか１つが設定される。同期
方式２１２は、更新種別２１１に対して適用する同期タ
イミングを設定する項目であり、即時同期または遅延同
期の何れかが設定される。同期方式２１２には「０」か
「１」が格納され、それぞれ即時同期、遅延同期を表す
ものとする。

【００４１】同期属性管理テーブル２２０は、共通リポ
ジトリ１０のＤＢ１００に格納されるオブジェクトが保
持する属性について、属性の種類と更新種別毎に同期タ
イミングを設定するテーブルである。同期属性管理テー
ブル２２０の各レコードは、同期属性種別２２１、更新
種別２２２、及び同期方式２２３から構成される。同期
属性種別２２１には、オブジェクトが保持する属性が設
定される。例えば、名前、メールアドレス、パスワード
などである。更新種別２２２には、同期属性種別２２１
に設定された属性に対する更新処理である属性の追加
（ａｄｄ）、変更（ｒｅｐｌａｃｅ）、削除（ｄｅｌｅ
ｔｅ）が設定される。同期方式２２３は、同期属性種別
２２１、及び更新種別２２２に設定された属性とそれに
対応する更新種別に対する更新処理発生時の同期タイミ
ングを設定する項目であり、オブジェクト更新種別管理
テーブル２１０の同期方式２１２の項目と同じである。

【００４２】遅延更新ログ６は、配列構造１１０をな
し、遅延更新処理の内容を複数格納可能である。遅延更
新ログ６は、更新履歴番号の記憶領域１１１、更新対象
エントリの名称の記憶領域１１２、更新種別の記憶領域
１１３、更新内容の記憶領域１１４からなる。ここで、
更新履歴番号１１１とは、各更新データを一意に識別す
るための整数値であり、更新処理が実行された順番に１
つずつ増加していく。遅延更新ログ６内のレコードは、
更新履歴番号１１１の小さい順に並んでいる。遅延更新
ログ６のデータ例を１１５に示す。

【００４３】次に、同期管理テーブル２の設定操作例を
説明する。

【００４４】同期管理テーブル２の各項目の設定操作に
当たっては、ユーザは共通リポジトリ１０のディスプレ
イ３５、キーボード３６、マウス３７などを使用する。

【００４５】ユーザは新規にアプリケーションサーバ２
０を同期対象とする時には、当該アプリケーションサー
バ２０をＧＵＩなどで提供される設定手段を用いて登録
する。この時、同期ＡＰ管理領域２００内の同期ＡＰ種
別２０１にはアプリケーション名称が登録され、新規に
アプリケーション名称が登録されるに伴って、自動的に
一意の整数値である識別ＩＤが登録される。

【００４６】また、ユーザはＧＵＩなどの提供された手
段を用いて同期管理テーブル２に登録されているアプリ
ケーションサーバ２０の一覧から設定を所望するアプリ
ケーションサーバ２０を選択し、オブジェクト更新種別
管理テーブル２１０、及び同期属性管理テーブル２２０
の内容を設定する。この設定に基づいてアプリケーショ
ンサーバ２０毎に適用される同期方法が決定される。同
様に、ユーザはＧＵＩなどの手段を用いて、オブジェク
ト更新種別管理テーブル２１０については、選択したア
プリケーションサーバ２０に対して更新種別である追加
（ａｄｄ）と削除（ｄｅｌｅｔｅ）に対してそれぞれ即
時同期、或いは遅延同期を適用することを選択する。ま
た、同期属性管理テーブル２２０については、同期対象
であるアプリケーションサーバ２０が管理する同期属性
種別毎にその更新種別である、追加（ａｄｄ）、変更
（ｒｅｐｌａｃｅ）、削除（ｄｅｌｅｔｅ）に対してそ
れぞれ即時同期、遅延同期を選択する。各同期方式の項
目には、即時同期として設定された項目には整数値
「０」が、遅延同期に設定された項目には整数値「１」
が格納される。

【００４７】次に、本実施例における、共通リポジトリ
１０に対する更新要求発生時の処理の流れについて図１
２を用いて説明する。

【００４８】図１２は、ＤＢ１００に登録されたデータ
の更新を要求する複数の処理が発生した時の処理シ−ケ
ンスである。

【００４９】クライアント４０が発行したデータの追加
要求９１を共通リポジトリ１０が受信すると、同期整合
性管理部３はその更新内容を解析して整合性判定を行
う。その結果が遅延同期であった場合には更新内容を遅
延更新ログ６に書き込む。また、共通リポジトリ１０は
ＤＢ１００のデータを更新し、クライアントに追加応答
９２を返す。

【００５０】次に、クライアント４０が発行したデータ
の変更要求９３を共通リポジトリ１０が受信すると、共
通リポジトリ１０はＤＢ１００のデータを更新すると共
に、同期整合性管理部３がその更新内容を解析して整合
性判定を行う。その結果が即時同期であった場合には更
新内容と遅延更新ログ６を読み込み、更新データ生成部
４がこれらの要求を一括して同期するための同期データ
を生成する。この時、即時同期処理である変更要求９３
を同期するためには遅延同期処理として遅延更新ログ６
に記録されている追加要求９１が必要な処理であるとい
う関連性が検出され、追加要求９１は変更要求９３の即
時同期に伴い一括して同期処理が行われる。

【００５１】従って、共通リポジトリ１０からアプリケ
ーションサーバ２０へ追加要求９４と変更要求９５が要
求され、アプリケーションサーバ２０は受信した更新要
求に従ってデータの更新を行い、共通リポジトリ１０へ
追加応答９６と変更応答９７を返す。共通リポジトリ１
０は、アプリケーションサーバ２０からの前記応答９
６、９７を受けてクライアント４０へ変更応答９８を返
す。

【００５２】この時、共通リポジトリ１０のログにおい
ては、追加要求９１、変更要求９３のそれぞれについて
クライアント４０より更新要求を受信してＤＢ１００を
更新した時点で、その記録がログに書き込まれているこ
とが確認できる。一方、アプリケーションサーバ２０に
おいては、共通リポジトリ１０からの同期要求として追
加要求９４、及び変更要求９５が一括して受信されるた
め、アプリケーションサーバ２０のログを参照すること
によって、２つの更新要求９４、９５が一括して処理さ
れたことが確認可能である。

【００５３】従って、これらログを参照することによっ
て、共通リポジトリ１０に対する要求発生においては時
間差が存在した２つの更新要求９１、９３に関して、変
更要求９３の発生をトリガに同要求９３に伴って追加要
求９１に関しても同期処理がなされ、アプリケーション
サーバ２０においては追加要求９４及び変更要求９５が
一括して同期データとして反映され、ＤＢ２１に対する
データ更新が行われることは明らかである。

【００５４】また、本実施例の提供する機能について
は、製品などにおいては一般にマニュアルなどに記載さ
れることからも本発明の適用は明らかである。

【００５５】以下に、本実施例におけるデータ管理シス
テムの動作を説明する。

【００５６】図４は、クライアント４０から共通リポジ
トリ１０へ発行された要求の解析に関する動作を表すフ
ローチャートである。

【００５７】共通リポジトリ１０の通信制御部２３がク
ライアント４０からの要求を受信すると、アクセス要求
解析部１が更新要求であるか否かを判別し（Ｓ４０
１）、受信した要求が更新要求であれば、要求された更
新種別により処理を分岐する（Ｓ４０２からＳ４０
４）。

【００５８】更新要求種別の解析の結果、追加要求であ
れば追加処理（Ｓ４０５）、変更要求であれば変更処理
（Ｓ４０６）、削除要求であれば削除処理（Ｓ４０
７）、前記以外の処理である場合は各々に対応した処理
を実行する（Ｓ４０８）。

【００５９】図５は、追加処理（図４のＳ４０５）の動
作を表すフローチャートである。

【００６０】まず、同期整合性管理部３はステップＳ５
０１において同期管理テーブル２を取得し、ステップＳ
５０２において、ＤＢ制御部２５は更新要求に従って共
通リポジトリ１０のＤＢ１００へオブジェクトを追加す
る。

【００６１】次に、同期整合性管理部３は、取得した同
期管理テーブル２内の先頭のテーブルに記載の同期アプ
リケーションに対して、ステップＳ５０３においては要
求された更新種別に対応する同期設定に基づいて処理を
分岐する。更新種別が即時同期処理の対象か、遅延同期
処理の対象であるかについては、ステップＳ４０１で取
得した更新種別を基にしてステップＳ５０１で取得した
同期管理テーブル２内のオブジェクト更新種別管理テー
ブル２１０を参照することによって判定する。

【００６２】即時同期を適用する設定の場合、ステップ
Ｓ５０５において同期整合処理を実行して整合性を保証
した同期データを生成する。そして、ステップＳ５０６
においては生成された同期データを同期制御部５がアプ
リケーションサーバ２０へ同期する。

【００６３】一方、ステップＳ５０３において遅延同期
設定として判定された場合、ステップＳ５０４において
更新データ生成部４は遅延更新ログに当該更新情報を追
加する。

【００６４】上記一連の処理終了後、ステップＳ５０７
において同期管理テーブル２を基に未だ同期処理を行っ
ていない同期対象アプリケーションが存在するか否かを
判定し、存在する場合にはステップＳ５０３から同様の
処理を繰り返し実行する。

【００６５】図６は、変更処理（図４のＳ４０６）の動
作を表すフローチャートである。

【００６６】まず、ステップＳ６０１において同期整合
性管理部３は同期管理テーブル２を取得し、ステップＳ
６０２において共通リポジトリ１０のＤＢ制御部２５は
更新要求に従ってＤＢ１００に格納された対象オブジェ
クトデータを変更する。

【００６７】次に、同期整合性管理部３は、取得した同
期管理テーブル２の先頭のテーブルに記載された同期ア
プリケーションに対して、ステップＳ６０３においては
要求された処理内容と遅延更新ログの内容を基に遅延更
新最適化処理を行う。

【００６８】続いて、ステップＳ６０４においては、要
求された更新種別による同期設定に基づいて処理を分岐
する。更新種別が即時同期処理の対象か、或いは遅延同
期処理の対象であるかについては、ステップＳ４０１で
取得した更新種別を基にしてステップＳ６０１で取得し
た同期管理テーブル２のオブジェクト更新種別管理テー
ブル２１０を参照することによって判定する。

【００６９】即時同期を適用する設定の場合、ステップ
Ｓ６０６において同期整合処理を実行して整合性を保証
した同期データを生成する。そして、ステップＳ６０７
においては、ステップＳ６０６において生成された同期
データを同期制御部５がアプリケーションサーバ２０へ
同期する。

【００７０】一方、ステップＳ６０４において遅延同期
設定と判定された場合、ステップＳ６０５において更新
データ生成部４は遅延更新ログ６に当該更新情報を追加
する。

【００７１】上記一連の処理終了後、ステップＳ６０８
において同期管理テーブル２を基に未だ同期処理を行っ
ていない同期対象アプリケーションが存在するか否かを
判定し、存在すればステップＳ６０３から同様の処理を
実行する。

【００７２】図７は、削除処理（図４のＳ４０７）の動
作を表すフローチャートである。

【００７３】まず、ステップＳ７０１において同期整合
性管理部３は同期管理テーブル２を取得し、ステップＳ
７０２においては共通リポジトリ１０のＤＢ制御部２５
が更新要求に従ってＤＢ１００に格納された対象オブジ
ェクトデータを削除する。次に、同期整合性管理部３は
ステップＳ７０３において、取得した同期管理テーブル
２の先頭のテーブルに記載された同期アプリケーション
に対して、要求された処理内容と遅延更新ログ６の内容
を基に遅延更新最適化処理を行う。

【００７４】続いて、ステップＳ７０４においては、要
求された更新種別に対応した同期設定に基づいて処理を
分岐する。更新種別が即時同期処理の対象か、或いは遅
延同期処理の対象であるかについては、ステップＳ４０
１で取得した更新種別を基にしてステップＳ７０１で取
得した同期管理テーブル２のオブジェクト更新種別管理
テーブル２１０を参照することによって判定する。

【００７５】即時同期を適用する設定の場合、ステップ
Ｓ７０６において処理内容を基に更新データ生成部４が
生成した同期データを同期制御部５がアプリケーション
サーバ２０へ同期する。

【００７６】一方、ステップＳ７０４において遅延同期
設定と判定された場合、ステップＳ７０５において更新
データ生成部４は遅延更新ログに当該更新情報を追加す
る。

【００７７】上記一連の処理終了後、ステップＳ７０７
において同期管理テーブル２を基に未だ同期処理を行っ
ていない同期対象アプリケーションが存在するか否かを
判定し、存在すればステップＳ７０３から同様の処理を
実行する。

【００７８】図８は、同期整合処理（図５のＳ５０５、
図６のＳ６０６）の動作を表すフローチャートである。

【００７９】同期整合性管理部３は、ステップＳ８０１
では遅延更新ログ６を読み込み、ステップＳ８０２にお
いてステップＳ４０１で取得した更新対象のオブジェク
トと同一のオブジェクトに対する遅延更新データが遅延
更新ログ６内に記録されているか否かを検索する。

【００８０】次に、ステップＳ８０３においてはステッ
プＳ８０２で実行した検索処理の結果を用いて、処理対
象として同一オブジェクトが存在するか否かを判定す
る。

【００８１】同一オブジェクトが存在する場合、ステッ
プＳ８０４において遅延更新ログ６から該当するログを
抽出し、続いてステップＳ８０５において前記遅延更新
ログ６より抽出した更新種別が追加処理であるか変更処
理であるかを判定する。

【００８２】ステップＳ８０５における判定の結果が追
加処理であった場合、ステップＳ８０６において関連オ
ブジェクト操作処理を行う。

【００８３】一方、ステップＳ８０５における判定の結
果が変更処理であった場合、ステップＳ８０７において
は、ステップＳ４０１とステップＳ８０４において取得
した変更内容を基に同一属性に対する変更処理が存在す
るか否かを判定する。

【００８４】ステップＳ８０７において変更処理の対象
に同一属性が存在すると判定された場合、ステップＳ８
０８において遅延更新データ内の該当データを削除す
る。一方、同一属性が存在しないと判定された場合は特
別に処理は行わない。

【００８５】また、ステップＳ８０３において同一オブ
ジェクトが存在しないと判定された場合、ステップＳ８
０９において関連オブジェクト操作処理を行う。

【００８６】そして、最後にステップＳ８１０において
更新データ生成部４が同期データを生成する。

【００８７】図９は、関連オブジェクト操作処理（図８
のＳ８０６、Ｓ８０９、図９のＳ９０３）の動作を表す
フローチャートである。

【００８８】まず、同期整合性管理部３は、ステップＳ
９０１において、ステップＳ４０１で取得した更新処理
の内容とステップＳ８０１で取得した遅延更新ログ６の
内容から更新対象のオブジェクト間の関連性を取得す
る。ここで言う関連性について、本実施例のデータ管理
システムの一例としてディレクトリシステムを挙げて説
明する。

【００８９】ディレクトリシステムにおいては人、組
織、ネットワーク機器などサービスに関する情報を木構
造で管理するため、或るエントリを追加するためにはそ
の親となるエントリが存在する必要があるということが
挙げられる。ディレクトリツリー構造を現実の組織階層
構造に模して設計する場合、或る企業組織において総務
部庶務課に所属するユーザ「山田」をエントリとして追
加するためには、組織「庶務課」がエントリとして既に
ディレクトリ上に存在していなければならない。これを
ＤＮで表現すると、ユーザ「山田」のＤＮは一例として
「ｃｎ＝山田，ｏｕ＝庶務課，ｏｕ＝総務部．．．」と
して表現され、組織「庶務課」のＤＮは「ｏｕ＝庶務
課，ｏｕ＝総務部．．．」として表現される。従って、
ＤＮにおける「ｏｕ＝庶務課，ｏｕ＝総務部．．．」の
部分に関しては両エントリにおいて共通の名称となる。
ステップＳ９０１においては、このような関係を検出し
て更新内容の関連性を取得することを行う。

【００９０】次に、ステップＳ９０１の結果を基に、ス
テップＳ９０２においては関連オブジェクトが存在する
かどうかを判定する。

【００９１】関連オブジェクトが存在すると判定された
場合、ステップＳ９０１において検出された関連エント
リに対して、ステップＳ９０３において関連オブジェク
ト操作を実行する。

【００９２】ステップＳ９０４においては、更新データ
生成部４は遅延更新ログ６に記録された当該関連オブジ
ェクトに関する更新内容を基に同期データを生成する。
そして、ステップＳ９０５においては、ステップＳ９０
４において生成された同期データの内容を遅延更新ログ
６より削除する。

【００９３】一方、ステップＳ９０２において関連オブ
ジェクトが存在しないと判定された場合にはそのまま関
連オブジェクト操作処理を終了する。

【００９４】図１０は、遅延更新最適化処理（図６のＳ
６０３、図７のＳ７０３）の動作を表すフローチャート
である。

【００９５】まず、ステップＳ１００１においては、遅
延更新ログ６を読み込み、ステップＳ１００２において
はステップＳ４０１で取得した更新処理の対象オブジェ
クトと同一のオブジェクトに対する更新処理が遅延更新
ログ６内に存在するかを検索する。

【００９６】次に、ステップＳ１００３においては、ス
テップＳ１００２の結果を基に同一オブジェクトに対す
る更新処理が存在するか否かを判定する。

【００９７】判定の結果、同一オブジェクトに対する更
新が遅延更新ログ６に記録されている場合、ステップＳ
１００４においてはステップＳ４０１で判定した更新種
別を基に処理を分岐する。

【００９８】ステップＳ１００４において変更処理と判
定された場合には、ステップＳ１００５において遅延更
新ログ６より更新処理の内容を抽出する。

【００９９】さらに、ステップＳ１００６においては、
ステップＳ１００４において抽出した変更内容と同一の
属性に対する変更が記録されているか否かを判定する。

【０１００】判定の結果同一の属性が存在する場合、ス
テップＳ１００７において該当する更新データを遅延更
新ログ６から削除する。一方、ステップＳ１００６にお
いて変更処理の対象に同一の属性がないと判定された場
合には、そのまま遅延更新最適化処理を終了する。

【０１０１】また、ステップＳ１００３において同一オ
ブジェクトに対する更新処理が存在しないと判定された
場合、及びステップＳ１００４において更新種別が削除
処理であると判定された場合についても、同様に遅延更
新最適化処理を終了する。

【０１０２】次に、遅延同期処理について説明する。遅
延同期処理は共通リポジトリ１０内に蓄積された遅延更
新ログ６の内容を、あらかじめ設定された遅延同期条件
に基づいてアプリケーションサーバ２０に同期する処理
である。

【０１０３】図１１は、遅延同期処理の動作を表すフロ
ーチャートである。

【０１０４】遅延同期処理ではあらかじめ設定された遅
延同期条件が満たされた時に、共通リポジトリ１０から
アプリケーションサーバ２０へ同期処理が行われる。遅
延同期条件とは、例えば以下のような条件が設定可能で
ある。（１）時間条件。時間、日、週、月、年単位など
の決まった時間単位毎に同期を実行する条件であり、例
えば毎週日曜日の２２：００から同期処理を開始すると
いった条件設定が挙げられる。（２）データ量。遅延更
新ログ６の更新データのレコード数が一定数以上になっ
た時、遅延更新ログのファイルサイズが一定サイズ以上
の大きさになった時などの条件が挙げられる。設定可能
な同期条件は拡張可能であり、前記２つの条件以外の条
件も適用可能である。

【０１０５】同期制御部５は、ステップＳ１１０１にお
いて同期条件が満たされたか否かを監視し、同期設定条
件が満たされたと判定した時、ステップＳ１１０２にお
いては更新データ生成部４が遅延更新ログ６を取得して
同期データを生成する。

【０１０６】ステップＳ１１０２において生成された同
期データについては、ステップＳ１１０３において同期
制御部５がアプリケーションサーバ２０へ同期する。な
お、同期対象となる遅延同期情報は、遅延更新ログ６に
記録された全ての更新データである。

【０１０７】最後に、ステップＳ１１０３の同期処理の
終了後、ステップＳ１１０４において、更新データ生成
部４は遅延更新ログ６を共通リポジトリ１０上から削除
する。遅延更新ログ６は、遅延同期処理が実行される度
に削除され、再び共通リポジトリ１０に更新処理が発生
することで生成される。

【０１０８】以上で本発明のデータ管理方法における第
１の実施例を説明した。かかるデータ管理方法によっ
て、主データベースから従データベースへのデータ同期
を行う際に、更新要求の種別、また更新処理の対象とな
る属性についての同期タイミングの関連付けを可能にす
ると共に、オブジェクト間の関連付けを可能にすること
によって、主データベースと従データベース間のデータ
整合性を保証する同期機能を提供することが可能であ
る。

【０１０９】次に、第２の実施例この実施例は理解でき
ない。アプリケーションサーバは検索要求を受けたとき
に何故対象の同期が遅延されていることがわかるのか？
について、図１３から図１５を用いて説明する。但し、
第１の実施例との相違点に限り説明する。

【０１１０】第１の実施例においては、即時同期を適用
する更新内容と遅延同期としてログに記録された更新デ
ータを関連付けて、遅延データも併せて即時に同期する
ための同期データの生成、同期を行うことを可能とした
が、本実施例においては、即時同期を適用する更新要求
について遅延更新ログ６のデータと関連付けて併せて遅
延同期の対象として、同期条件が満たされた時に一括し
て同期する機能を提供するデータ管理システムである。

【０１１１】図１５は、共通リポジトリ１０のＤＢ１０
０に登録されたデータの更新を要求する複数の処理が発
生した時の処理シーケンスである。

【０１１２】クライアント４０が発行したデータの追加
要求８１を共通リポジトリ１０が受信すると、同期整合
性管理部３はその更新内容を解析して整合性判定を行
う。その結果が遅延同期であった場合には更新内容を遅
延更新ログ６に書き込む。また、共通リポジトリ１０の
ＤＢ１００のデータを更新し、クライアントに追加応答
８２を返す。

【０１１３】次に、クライアント４０が発行したデータ
の変更要求８３を共通リポジトリ１０が受信すると、共
通リポジトリ１０のＤＢ１００のデータを更新すると共
に、同期整合性管理部３はその更新内容を解析して整合
性判定を行う。その結果が即時同期であった場合には更
新内容と遅延更新ログ６を読み込み、変更要求８３に関
連する更新処理が既に遅延更新ログ６に記録されていた
時には、アプリケーションサーバ２０へは即時に同期せ
ず、変更要求８３の更新内容を遅延更新ログ６に書き込
むと共に、クライアント４０に変更応答８４を返す。

【０１１４】共通リポジトリ１０において同期条件が満
たされると、更新データ生成部４は遅延更新ログ６を基
に同期データを生成し、同期制御部５はアプリケーショ
ンサーバ２０へ遅延更新データを同期するために追加要
求８５と変更要求８６を発行する。

【０１１５】アプリケーションサーバ２０は共通リポジ
トリ１０からの追加要求８５及び変更要求８６を受信す
ると、要求に従って、ＤＢ２１への追加処理と変更処理
を行い、共通リポジトリ１０へ追加応答８７と変更応答
８８を返す。

【０１１６】本実施例における各種処理に関わる動作の
流れは第１の実施例とほぼ同様である。

【０１１７】但し、同期整合処理において同期整合処
理、及び関連オブジェクト操作処理が第１の実施例と異
なる。

【０１１８】図１３は、本実施例における同期整合処理
の動作を表すフローチャートである。

【０１１９】ステップＳ１３０３において、要求された
更新処理の対象であるオブジェクトが遅延更新ログ６に
記録された遅延更新に存在するか否かを判定する処理ま
では第１の実施例と同様である。

【０１２０】次に、ステップＳ１３０３において同一オ
ブジェクトが存在すると判定された場合には、同期整合
性管理部３によって即時同期として判定された即時にア
プリケーションサーバ２０へ同期する処理を行わず、更
新要求を遅延更新ログ６に書き込む。

【０１２１】一方、ステップＳ１３０３において同一オ
ブジェクトが存在しないと判定された場合には、ステッ
プＳ１３０４において関連オブジェクト操作処理を実行
する。

【０１２２】図１４は、本実施例における関連オブジェ
クト操作処理の動作を表すフローチャートである。

【０１２３】図１４のステップＳ１４０３において関連
オブジェクト操作処理が行われるところまでは、第１の
実施例と同様である。

【０１２４】ステップＳ１４０４においては、ステップ
Ｓ１４０２において関連オブジェクトが存在すると判定
されているため、同期整合性管理部３によって即時同期
として判定された更新要求を遅延更新ログ６に書き込
む。

【０１２５】以上説明した第２の実施例によると、即時
に同期する設定がなされた更新要求に対して、共通リポ
ジトリ１０において遅延同期を行うために遅延更新ログ
６に記録され更新データと関連付け共通リポジトリ１０
からアプリケーションサーバ２０への同期条件が満たさ
れた時に、併せて遅延同期処理を行うことで、データベ
ース間のデータ整合性を保証する同期機能を提供するこ
とが可能となる。

【０１２６】次に、第３の実施例について説明する。但
し、第１の実施例との相違点に限り説明する。

【０１２７】本実施例は、第１の実施例において共通リ
ポジトリ１０に組み込まれた更新データの整合性を管理
する機能をクライアント４０に組み込んだデータ管理シ
ステムである。本実施例のデータ管理システムは、第１
の実施例と異なり、クライアントがデータベースシステ
ムに対する全てのデータ更新を行う。

【０１２８】本実施例のデータ管理システムの機能構成
は、第１の実施例で説明した図１において、クライアン
ト４０が通信制御部２３、ユーザインタフェース制御部
２４、アクセス要求解析部１を有する。また、図３で説
明した同期管理テーブル２、遅延更新ログ６、同期整合
性管理部３、更新データ生成部４、同期制御部５につい
ては、共通リポジトリ１０は備えず、クライアント４０
が有する。

【０１２９】本実施例のクライアント４０のシステム構
成は、第１の実施例における図２における構成とほぼ同
様である。

【０１３０】但し、ＨＤＤ３３にＤＢ１００が存在しな
い点、及び主メモリ３１にＤＢ制御プログラム２５が存
在しない点において異なる。本実施例の共通リポジトリ
１０のシステム構成は、主メモリ３１にアクセス要求解
析プログラム１、ＤＢ制御プログラム２５、通信制御プ
ログラム２３のみが格納される点、及び磁気ディスク３
３にＤＢのみが格納される点を除けば、図２で示した第
１の実施例と同様である。

【０１３１】次に、第２の実施例における、データ管理
システム全体の処理の流れについて、クライアント４０
において共通リポジトリ１０のデータの更新を要求する
複数の処理が発生した時の処理シーケンスを説明する。

【０１３２】ユーザがクライアント４０を通じて共通リ
ポジトリ１０への追加要求を入力し、次に変更処理を要
求した時に、同期データを生成するまでは第１の実施例
と同様の処理をクライアント４０において行う。

【０１３３】同期データ生成後、クライアント４０はア
プリケーションサーバ２０へ同期要求を出し、アプリケ
ーションサーバ２０は受信した同期要求に従ってデータ
の更新を行い、クライアント４０へ同期応答を返す。

【０１３４】以下に、本実施例におけるデータ管理シス
テムの動作を説明する。

【０１３５】本実施例における、クライアント４０にお
いて要求された処理の解析に関する動作は第１の実施例
の図４と同様である。

【０１３６】前記解析の結果、追加処理が要求された場
合、図５とほぼ同様の処理を行うが、ステップＳ５０２
のオブジェクトの追加処理にあたっては、共通リポジト
リ１０への追加要求を発行する。

【０１３７】変更処理が要求された場合、及び削除処理
が要求された場合についても同様の処理を行う。

【０１３８】以上説明した第３の実施例によると、共通
リポジトリ１０とアプリケーションサーバ２０の同期デ
ータの生成に関わる整合性判定処理、及び同期データ生
成処理を実行する機能をクライアント４０に持たせるこ
とで、データ更新時の共通リポジトリ１０の負荷を軽減
することが可能となる。

【０１３９】

【発明の効果】以上述べたように本発明によれば、複数
データベース間のデータ管理において、管理するデータ
ベース毎に更新対象属性と更新種別を基にそれぞれ同期
タイミングを設定し、データの更新処理発生時にシステ
ムが更新内容であるオブジェクト、及び属性間の関連付
けを行うことによって同期タイミングの相違に関わらず
整合性を保証したデータ管理が可能である。そのため、
ユーザがデータベース間で新旧の異なるデータを使用す
るために誤って業務を遂行してしまう状況に陥ることが
無くなり、また、不整合発生に伴うシステム管理者の整
合性回復作業を不要とすることでき、データベースシス
テムの利便性の向上を実現可能である。

【図面の簡単な説明】

【図１】本発明の第１の実施例の機能構成図である。

【図２】本発明の第１の実施例のシステム構成図であ
る。

【図３】本発明の同期管理テーブル、及び遅延更新ログ
のデータ構造図である。

【図４】本発明の実施例のアクセス要求解析処理に関わ
る動作の説明図である。

【図５】本発明の実施例の追加処理に関わる動作の説明
図である。

【図６】本発明の実施例の変更処理に関わる動作の説明
図である。

【図７】本発明の実施例の削除処理に関わる動作の説明
図である。

【図８】本発明の実施例の同期整合処理に関わる動作の
説明図である。

【図９】本発明の実施例の関連オブジェクト操作処理に
関わる動作の説明図である。

【図１０】本発明の実施例の遅延更新最適化処理に関わ
る動作の説明図である。

【図１１】本発明の実施例の遅延同期処理に関わる動作
の説明図である。

【図１２】本発明の第１の実施例の同期整合処理を伴う
データ処理における処理シーケンスを示す図である。

【図１３】本発明の第２の実施例の同期整合処理に関わ
る動作の説明図である。

【図１４】本発明の第２の実施例の関連オブジェクト操
作処理に関わる動作の説明図である。

【図１５】本発明の第２の実施例の同期整合処理を伴う
データ処理における処理シーケンスを示す図である。

【符号の説明】

１…アクセス要求解析部、２…同期管理テーブル、３…
同期整合性管理部、４…更新データ生成部、５…同期制
御部、６…遅延更新ログ、１０…共通リポジトリ、２０
…アプリケーションサーバ。

───────────────────────────────────────────────────── フロントページの続き (72)発明者 志賀 賢太 神奈川県川崎市麻生区王禅寺1099番地 株 式会社日立製作所システム開発研究所内 (72)発明者 由井 仁 神奈川県横浜市戸塚区戸塚町5030番地 株 式会社日立製作所ソフトウェア事業部内 Ｆターム(参考） 5B075 KK04 NR02 PP02 PP03 PQ02 PQ05 PR03 5B082 AA01 GA14 HA03

Claims (3)

【特許請求の範囲】
1. 【請求項１】 複数のサーバが伝送媒体を介して相互に
   接続され、第１のサーバを主データベースとしてデータ
   の更新を管理すると共に、第２のサーバを従データベー
   スとして、更新したデータを少なくとも１つの従データ
   ベースに管理されるデータに同期する機能を備え、 前記主データベースに格納されるデータの更新を要求す
   る処理種別に対応する同期方法として、更新処理発生時
   に即時に同期処理を行うか、或いは遅延して同期処理を
   行うかをあらかじめ設定しておくことで、その設定条件
   に従って主データベースから従データベースへのデータ
   の同期処理を行うデータベースシステムにおいて、 前記同期処理を実現するにあたって、設定された同期方
   法と要求される更新処理の内容を基に、即時同期設定と
   遅延同期設定の２つの異なる同期方法をもって処理され
   る複数の更新処理を関連付けることによって、 遅延同期処理の対象として主データベースに蓄積された
   更新データに関しても、即時同期処理の対象として主デ
   ータベースに要求された更新処理の同期に伴って一括し
   て同期処理を実行することを可能とし、データベース間
   の整合性を保証した同期処理を実現するデータ管理手段
   を有することを特徴とするデータ管理方法。
2. 【請求項２】 前記前記主データベースで行われたデー
   タ更新を従データベースに同期する方式を設定するため
   に、 主データベースに対して要求された更新種別を判定する
   アクセス要求解析手段と、前記主データベースへの更新
   処理の内容に対応する同期方法の設定を記憶する同期管
   理テーブル手段と、前記テーブルにおいて遅延同期方法
   を適用された更新内容を従データベースに同期するまで
   主データベース上に蓄積しておく遅延更新ログ手段、従
   データベースへの同期データを生成する更新データ生成
   手段と、前記更新データ生成手段によって生成されたデ
   ータを基に、設定された同期スケジュールに基づいて従
   データベースにデータを同期する同期制御手段を有する
   データベースシステムにおいて、 前記ログ手段及び前記テーブル手段の設定を基にして、
   主データベースに対して発生した更新処理種別と処理対
   象となる属性、同期対象オブジェクト、及び同期タイミ
   ングの関連付けを行う同期整合性管理手段を有すること
   を特徴とするデータ管理方法。
3. 【請求項３】 請求項１及び請求項２に記載のデータ管
   理方法において、 データベースに設定された同期方法と要求される更新処
   理の内容を基に、即時同期設定と遅延同期設定の２つの
   異なる同期方法をもって処理される複数の更新処理を関
   連付けることによって、データベース間の整合性を保証
   した同期処理を実現するデータ管理手段を、 クライアントに備えることを特徴とするデータ管理方
   法。