JPH10222409A - 分散データ管理システム - Google Patents

Abstract

(57)【要約】 （修正有） 【課題】 情報の整合性を保持しつつ、全体としての効
率化を図る。 【解決手段】 サーバを階層的に接続し、共通情報とそ
れ以外の個別情報とに分類して管理する。全国共通、支
社内共通及び個別に分類した顧客情報を保有する顧客情
報データベース１８、サーバ内で更新した共通顧客情報
の更新内容を集信用顧客情報ファイル２２に書き込み本
社サーバへ転送する集信処理部１１、本社サーバで各サ
ーバから送られてきた上記更新内容を集約した配信用全
国又は支社内共通顧客情報ファイル２３，２４を受け取
り、顧客情報データベース１８に個々に反映する配信処
理部１２、他支社系列が保有する顧客情報を取り込む配
信要求処理部１３、並びに不要と思われる他支社系列の
顧客情報を顧客情報データベース１８から自動削除する
情報削除処理部１４を有し、分散した共通顧客情報の整
合性を保持する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は分散データ管理シス
テム、特に階層的に接続されたシステムを構成する各サ
ーバへの効率的な情報の管理形態に関する。

【０００２】

【従来の技術】従来から、全国的に散在するビルに設置
されたエレベータや冷暖房等の設備を遠隔地から監視す
るシステムがある。このような監視システムでは、設備
に関する情報を一括管理して各ビルの保守等に活用して
いる。そのため、このような集中型の監視システムは、
通常、大型の汎用機を導入して各種情報を集中管理して
いる。

【０００３】図１２は、従来の集中型監視システムの構
成を示した概略図である。汎用機は、公衆網を介してビ
ル毎若しくは一定の地域に属するビル単位に設置された
端末を接続する。また、汎用機は、各端末から入力され
た情報を受け取り、全て保有するためのデータベースを
有している。保有する情報としては、例えば障害発生等
のクレーム情報、新規建築ビル情報等の営業情報、交換
部品の調達先等の設備管理情報、契約に関する情報等が
ある。

【０００４】一方、近年では、上記汎用機の負荷を分散
するなどの目的で分散型の監視システムを構築する場合
が増えてきている。この分散型監視システムでは、一定
の地域に属するビルを管理する営業所若しくは支社単位
に小規模な計算機（サーバ）を導入して地域毎に上記情
報を集中管理している。そして、各サーバは、複数のサ
ーバの上位に位置し上記汎用機に相当する主計算機並び
に各地域のサーバと保有している情報の交換を必要に応
じて行っている。

【０００５】

【発明が解決しようとする課題】しかしながら、上記集
中型監視システムは、数百から数十万箇所にも及ぶビル
設備に関する情報を公衆網を介して接続された端末から
の入力情報を受け取ることになるので、通信コストの増
大を招き、また、多数の設備の情報を一括して管理する
ことから排他制御の増加に伴うレスポンスの劣化等の問
題が発生する。

【０００６】一方、上記分散型監視システムは、集中型
監視システムで発生する諸問題の発生を防止しうるもの
の、各サーバがそれぞれに顧客情報を保持することにな
るので、各サーバがシステム全体において統一された情
報を共有することが整合性の面からも困難である。ま
た、他のサーバが管理している情報を自サーバで受け取
り保持することは可能であるが、その情報を保持したま
までいると情報が無用に蓄積してしまい、ディスク容量
が膨大となってしまい好ましくない。

【０００７】本発明は以上のような問題を解決するため
になされたものであり、その目的は、情報の整合性を保
持しつつコスト面並びに運用面からシステム全体として
の効率化を図る分散データ管理システムを提供すること
にある。

【０００８】

【課題を解決するための手段】以上のような目的を達成
するために、第１の発明に係る分散データ管理システム
は、データベースを有するサーバを階層的に接続した分
散データ管理システムにおいて、前記各サーバは、シス
テム内で扱う情報を、前記サーバにおいて共通して使用
する共通情報とそれ以外の個別情報とに分類して管理す
る情報レベル情報を保持し、前記共通情報と各サーバが
管理すべき前記個別情報とを前記データベースに保有す
るものである。

【０００９】第２の発明に係る分散データ管理システム
は、第１の発明において、前記各サーバは、内部で更新
した前記共通情報の更新内容に基づき集信用更新情報を
生成し、階層最上位に位置する情報集配信サーバに送出
する集信処理手段と、前記情報集配信サーバが生成した
配信用更新情報に基づき前記データベース内の共通情報
を更新する配信処理手段とを有し、前記情報集配信サー
バは、前記サーバから送られてきた前記集信用更新情報
を収集する集信用更新情報収集手段と、収集した前記集
信用更新情報に基づき全ての前記共通情報の更新内容を
集約して前記配信用更新情報を生成する配信用更新情報
生成手段と、前記配信用更新情報を全ての前記サーバに
分配する更新情報分配手段とを有し、全ての前記サーバ
が個々に保有する前記共通情報の整合性を図るものであ
る。

【００１０】第３の発明に係る分散データ管理システム
は、第２の発明において、前記各サーバは、前記共通情
報を、全サーバに共通する全サーバ共通情報とシステム
の階層構造を構成するサーバ系列毎に共通するサーバ系
列共通情報とに分類して管理する情報レベル情報を保持
し、前記配信用更新情報生成手段は、前記全サーバ共通
情報の更新内容を集約した配信用共通更新情報と、前記
サーバ系列共通情報の更新内容をサーバ系列毎に集約し
た配信用サーバ系列共通更新情報とを前記配信用更新情
報として生成し、前記更新情報分配手段は、前記配信用
共通更新情報を全ての前記サーバに、前記各配信用サー
バ系列共通更新情報を対応するサーバ系列内の前記各サ
ーバに分配するものである。

【００１１】第４の発明に係る分散データ管理システム
は、第２の発明において、前記配信処理手段は、上位の
前記サーバから送られてきた前記配信用更新情報を接続
された下位の前記サーバへ送出するものである。

【００１２】第５の発明に係る分散データ管理システム
は、第２の発明において、前記各サーバは、自己が保有
せず他のサーバが保有している情報の配信要求を前記情
報集配信サーバに送出するとともに配信要求に応じて返
答された情報を前記データベースに書き込む配信要求処
理手段を有し、前記情報集配信サーバは、前記サーバか
らの前記配信要求に従い該当する情報を配信要求をした
前記サーバへ送出する要求情報送出手段を有するもので
ある。

【００１３】第６の発明に係る分散データ管理システム
は、第５の発明において、前記各サーバは、配信要求に
より受け取った情報を一定期間経過後に削除する情報削
除手段を有するものである。

【００１４】

【発明の実施の形態】以下、図面に基づいて、本発明の
好適な実施の形態について説明する。本実施の形態で
は、本発明に係る分散データ管理システムを、全国規模
に散在する監視対象のビルに設置されたエレベータや冷
暖房等の設備を遠隔地から監視するシステムに適用した
例で説明する。

【００１５】図１は、本発明に係る分散データ管理シス
テムの一実施の形態を示したシステム全体構成図であ
る。１台の本社サーバは、広域網を介して５台の支社サ
ーバを接続している。支社サーバのうちＡ支社サーバ
は、４台の営業所サーバを接続し、Ｄ支社サーバは、５
台の支店サーバを接続している。更に、Ｄ３支店サーバ
は、３台の営業所サーバを接続している。本実施の形態
におけるシステム形態は、図１に示したように本社サー
バ、各支社サーバ、各支店サーバ及び各営業所サーバ
は、それぞれ広域網を介して階層的に接続されている。
なお、各サーバは、顧客の契約、人事、経理等処理する
情報によって複数の計算機から構成することも可能であ
るが、ここでは各サーバを便宜上１台の計算機で構成す
るものとする。また、図１に示した支社、営業所等のサ
ーバ台数やシステム形態は、一例であることはいうまで
もない。

【００１６】図２は、本実施の形態における各サーバの
機能ブロック構成図である。本実施の形態におけるサー
バは、基本的には全て同じ構成なのでまとめて説明し、
階層上の位置によって異なる場合は、逐次説明を付記す
る。

【００１７】サーバ１０は、ＣＰＵ、メモリ、ディスク
装置等を搭載する一般的な計算機で実現され、所定のア
プリケーションを実行することで集信処理部１１、配信
処理部１２、配信要求処理部１３、情報削除処理部１４
及び情報入出力処理部１５がそれぞれが持つ処理機能を
発揮する。

【００１８】集信処理部１１は、集信処理手段として設
けられ、内部で更新した共通情報の更新内容に基づき集
信用更新情報（本実施の形態における集信用顧客情報）
を生成し、階層最上位に位置する情報集配信サーバすな
わち本社サーバへ送出する。なお、本実施の形態におい
て取り扱う顧客情報としては、共通情報としての全国共
通顧客情報及び支社内共通顧客情報と、それ以外の個別
顧客情報とがあるが、この詳細については後述する。ま
た、本社サーバにおける集信処理部１１は、更に集信用
更新情報収集手段としても機能し、各サーバから送られ
てきた集信用更新情報を収集する。

【００１９】配信処理部１２は、配信処理手段として設
けられ、本社サーバが生成した配信用更新情報（本実施
の形態における配信用全国共通顧客情報及び配信用支社
内共通顧客情報）に基づき顧客情報データベース１８内
の共通情報を更新する。また、本社サーバにおける配信
処理部１２は、更に配信用更新情報生成手段並びに更新
情報分配手段としても機能し、収集した集信用顧客情報
に基づき全ての共通情報の更新内容を集約して上記配信
用更新情報を生成するとともに、その配信用更新情報を
全てのサーバに分配する。

【００２０】配信要求処理部１３は、配信要求処理手段
として設けられ、自己が保有せず他のサーバが保有して
いる情報の配信要求を本社サーバへ送出するとともに配
信要求に応じて返答された情報を顧客情報データベース
１８に書き込む。本実施の形態においては、ここでいう
他のサーバというのは他支社系列のサーバに相当する。
また、本社サーバにおける配信要求処理部１３は、更に
要求情報送出手段としても機能し、いずれかのサーバか
らの配信要求に従い該当する顧客情報を配信要求をした
サーバへ送出する。すなわち、いずれかのサーバからの
配信要求に応えて要求された顧客情報をそのサーバに代
わって収集して届けることになる。

【００２１】情報削除処理部１４は、情報削除手段とし
て設けられ、上記配信要求により受け取った顧客情報を
一定期間経過後に削除する。本実施の形態においては、
本社サーバにおける情報削除処理部１４が抽出した削除
対象となる顧客情報の識別情報を各サーバが受け取り、
その識別情報に基づいて各サーバにおいて該当する顧客
情報を削除することになる。

【００２２】更に、情報入出力処理部１５は、顧客情報
の表示、配信要求の設定入力、レポート報告などを端末
やプリンタに行うための手段である。

【００２３】また、サーバ１０は、マスタファイル１
６、種々のワークファイル１７、顧客情報データベース
１８を有している。マスタファイル１６は、本社サーバ
のみが保有しており、サーバ管理情報、未集信サーバＩ
Ｄ情報及び削除開始情報を記憶している。図３は、本実
施の形態で使用するマスタファイル１６のデータ構成の
内容例である。サーバ管理情報は、本システム内に接続
された各サーバに関する情報であり、サーバ名、サーバ
ＩＤ等少なくとも各支社等に配置されたサーバを識別す
るための情報を含んでいる。未集信サーバＩＤ情報に
は、集信処理において更新情報を受け取っていないサー
バのサーバＩＤが記録される。削除開始情報には、各サ
ーバにおいて他サーバから読み込んだ顧客情報を削除す
るタイミングが設定されている。

【００２４】本実施の形態において使用される主なワー
クファイル１７としては、前回抽出日時情報ファイル２
１、集信用顧客情報ファイル２２、配信用全国共通顧客
情報ファイル２３、配信用支社内共通顧客情報ファイル
２４、集信済サーバＩＤ情報ファイル２５及び削除対象
顧客情報ファイル２６がある。集信用顧客情報ファイル
２２には、集信処理において各サーバ内において更新さ
れた顧客情報が書き込まれ、本社サーバへ転送される。
前回抽出日時情報ファイル２１には、各サーバにおいて
集信処理が行われるべき日時が設定される。配信用全国
共通顧客情報ファイル２３は、配信処理において本社サ
ーバによって作成され、全支社サーバへ転送されるファ
イルであり、そのファイルには集信処理において受け取
った集信用顧客情報ファイル２２に含まれている更新さ
れた顧客情報のうち、未配信の全国共通顧客情報に相当
する情報が書き込まれる。配信用支社内共通顧客情報フ
ァイル２４は、配信処理において本社サーバによって支
社サーバ毎に別個に作成され、各支社サーバへ転送され
るファイルであり、そのファイルには集信処理において
受け取った集信用顧客情報ファイル２２に含まれている
更新された顧客情報のうち、未配信の支社内共通顧客情
報に相当する情報が書き込まれる。なお、上位のサーバ
から配信用全国共通顧客情報ファイル２３及び配信用支
社内共通顧客情報ファイル２４を受け取った各サーバ
は、更にそれらのファイルを接続された下位のサーバへ
転送する。集信済サーバＩＤ情報ファイル２５は、本社
サーバのみに用いられ、集信処理において集信用顧客情
報ファイル２２の送信元のサーバＩＤを記録する。削除
対象顧客情報ファイル２６は、削除顧客情報抽出処理に
おいて本社サーバによって作成され、下位のサーバへ分
配されるファイルである。

【００２５】顧客情報データベース１８には、顧客リス
ト情報と３種類に大別できる顧客情報とが格納されてい
る。顧客リスト情報には、本システムにおける顧客、事
業所、部署リストが登録されている。このリストを参照
することによって各サーバの利用者は、本システムにお
ける顧客を知ることができる。顧客情報は、全国共通顧
客情報、支社内共通顧客情報及び個別顧客情報の３種類
に大別された情報で基本的に構成されている。

【００２６】全国共通顧客情報というのは、例えばビル
監視の契約をした顧客（会社）のビルが全国規模に散在
しており地域毎のサーバにそれぞれ情報を持たせておく
より全サーバ共通の情報として共有した方が業務上効率
的であると思われる情報である。このため、全国共通顧
客情報は、全サーバで保有され、かつその内容は同一と
なる。

【００２７】支社内共通顧客情報というのは、全国共通
顧客情報と同趣旨であるが、顧客のビルが全国的でなく
一支社が管理する地域内に散在する程度の地域性を有し
ている情報である。各支社は、それぞれ支社内共通顧客
情報を保有しているが、その情報の内容は支社毎に異な
る。また、支社内共通顧客情報は、各支社の系列内に属
するサーバ、すなわち一サーバ系列内に属する支社サー
バ及びその支社サーバの下位層に属する支店サーバ又は
営業所サーバにおいてそれぞれ保有され、かつその内容
は同一となる。このように、同一サーバ系列内に属する
各サーバは、それぞれ一つの支社内共通顧客情報を保有
することになるが、本社サーバだけは、全支社内共通顧
客情報すなわち支社の数だけの支社内共通顧客情報を保
有することになる。なお、Ｄ３支店サーバのように、更
に下位に営業所サーバが接続されるような場合は、Ｄ３
支店サーバを最上位とした支店内共通顧客情報が作成さ
れ、本社サーバ、Ｄ支社サーバ、Ｄ３支店サーバ及び下
位の各営業所サーバが更に支店内共通顧客情報を保有す
ることになるが、これは、以下の説明を簡略にするため
に省略する。

【００２８】個別顧客情報というのは、共通情報すなわ
ち全国共通顧客情報及び支社内共通顧客情報以外の顧客
情報であり、複数のサーバで共有しない各サーバ個別の
顧客情報である。基本的には各系列の最下位に位置する
サーバが保有することになる。

【００２９】上記３種類の顧客情報は、実際のデータの
内容が異なるだけでその構成は同じである。図４は、そ
の顧客情報の構成を示した概略図である。顧客情報は、
会社情報ファイル、事業所情報ファイル及び部署情報フ
ァイルで構成されている。会社情報ファイルには、各会
社の識別情報である取引先コード、会社の名称等各顧客
（会社）に関する情報が登録されている。事業所情報フ
ァイルには、各事業所の識別情報である取引先事業所コ
ード、事業所名等ある会社に属する事業所レベルの情報
が登録されている。同様に、部署情報ファイルには、各
部署の識別情報である取引先部署コード、部署名等ある
会社のある事業所に属する部署レベルの情報が登録され
ている。会社に対して複数の事業所又は部署が存在する
場合、複数の事業所情報ファイル又は部署情報ファイル
が用意されることになる。また、各顧客情報ファイルに
共通して情報を更新した日時、所属コード及びサーバＩ
Ｄが記録される。図４に示した情報の内容は、あくまで
例示であり、通常は業務に即した、あるいは扱う顧客の
業種等に従いより詳細な情報を持たせることになる。

【００３０】図５は、会社情報ファイルに設定される情
報レベル情報の設定例を示した図であり、情報レベル情
報は、システム内で扱う情報を、サーバにおいて共通し
て使用する共通情報とそれ以外の個別情報とに分類して
管理するための情報である。本実施の形態では、顧客情
報を全国、支社、個別というレベルに分類している。

【００３１】本実施の形態では、支社毎に使用フラグを
設定するようにした。図５のようにＡ支社及びＣ支社に
フラグが設定されている場合、この会社に関する顧客情
報は、Ａ支社サーバ及びＣ支社サーバにおける支社内共
通顧客情報となり、Ｂ支社サーバには保有されない。ま
た、全ての支社の使用フラグが設定されている場合が全
国共通顧客情報となり、全ての支社の使用フラグが設定
されていない場合が個別共通顧客情報となる。なお、図
５に示した情報レベル情報の設定方法は、一例であり、
全国共通顧客情報用の使用フラグを用意したり、個別顧
客情報を示す営業所レベルの使用フラグを設けたりして
もよい。また、本実施の形態では、会社情報ファイル内
に設定したが、顧客リスト情報として設けたり別ファイ
ルとしてサーバに持たせるようにしてもよい。

【００３２】以上のように、本実施の形態では、顧客情
報データベース１８を統合して一括管理するのではなく
顧客情報をレベルに応じて各サーバに共通する顧客情報
とそうでない個別の顧客情報とに分類し、各サーバにお
いて自己のサーバに関係のない他のサーバの顧客情報を
持たせないようにした。これにより、その分の通信デー
タ量並びに保有データ量が削減されるため通信コストの
削減並びにディスク容量の削減を図ることができる。そ
の一方で、各サーバは、全国又は支社レベルで共通する
顧客情報を保有しているので、統一された情報をサーバ
に共有することが論理的に可能となる。

【００３３】次に、本実施の形態において特徴的な集信
処理、配信処理、一時的に受け取った顧客情報の削除処
理及び各サーバが主体的に行う配信要求処理について説
明する。

【００３４】本実施の形態では、各サーバにおいて、上
述した顧客情報データベース１８を逐次更新しつつ、そ
の顧客情報データベース１８に格納された情報に基づき
各地域においてビルの監視や営業、集金等の業務を行う
ことになる。本実施の形態では、同一内容の全国共通顧
客情報や支社内共通顧客情報を複数のサーバに持たせる
ことになるので、その整合性を保持する必要がある。そ
こで、本実施の形態では、顧客情報の集信処理及び配信
処理を日毎に行い、各サーバが保有する顧客情報データ
ベース１８の整合性を少なくとも日単位で保持するよう
にしている。集信処理というのは、下位のサーバから上
位のサーバに向けて情報を集める処理をいい、配信処理
というのは、上位のサーバから下位のサーバに向けて情
報を流す処理をいう。本実施の形態においては、下位の
サーバによって更新された情報を集信処理によって本社
サーバが一括して集約し、その集約した更新情報を配信
処理によって本社サーバから各サーバに直接又は間接的
に分配することで整合性を保持するようにしている。

【００３５】まず、本実施の形態における集信処理につ
いて図６、７に示したフローチャートを用いて説明す
る。集信処理は、下位のサーバから上位のサーバに向け
て情報を集める処理であるが、より具体的には、実際に
情報を更新した営業所サーバ等が本社サーバに対してそ
の更新した内容を通知する処理である。論理的には、営
業所サーバ等は、更新した内容を上位の支社サーバ等を
介さずに本社サーバに直接送信することになる。集信処
理は、集信処理部１１が行うが、配信要求処理について
は、配信要求処理部１３が行う。

【００３６】図６に示した処理は、情報を更新したサー
バによって日毎に実行される。従って、最下層の営業所
サーバ等のみならず顧客情報を更新しうる中間層の支社
サーバや最上層の本社サーバによっても実行される。

【００３７】まず、顧客情報データベース１８から顧客
情報を読む（ステップ１０１）。本実施の形態では、顧
客情報を会社情報ファイル、事業所情報ファイル及び部
署情報ファイルに分割して保有しているので、各ファイ
ル単位に読み込むことになる。読み取った顧客情報が本
日付けである場合、更新された顧客情報（会社情報ファ
イル等）をワークファイルである本日分の更新情報ファ
イルに書き込むことによって生成する（ステップ１０
２，１０３）。サーバ利用者によって顧客情報（会社情
報ファイル等）が更新される際、更新日時、更新した者
の所属コード及び更新がされたサーバのサーバＩＤも同
時に更新されるので、本日更新された顧客情報であるか
どうかは、この更新日時を参照することによって判断す
ることができる。なお、更新された顧客情報としては、
既存の顧客情報のみならず新規に契約された顧客に関す
る情報などもある。また、配信要求があった場合、その
要求に基づいて更新情報ファイルを生成する（ステップ
１０４，１０３）。配信要求というのは、サーバ利用者
が参照若しくは変更したい顧客情報を現在サーバ内に保
有されていないため他サーバから取ってくるよう指示さ
れたことに応えて本社サーバへの該当する顧客情報の配
信を要求することであるが、この処理の詳細については
後述する。

【００３８】更に、顧客情報データベース１８から顧客
情報を読み込み、参照していない顧客情報がなくなるま
で上記処理（ステップ１０２〜１０４）を繰り返し行う
（ステップ１０５，１０６）。

【００３９】次に、過去の集信処理において未転送の更
新情報ファイルの有無を調べ（ステップ１０７）、無い
場合は、本日分の更新情報ファイルに基づいて集信用顧
客情報ファイル２２を作成し（ステップ１０８）、有る
場合は本日分及び過去の未転送の更新情報ファイルに基
づいて集信用顧客情報ファイル２２を作成する（ステッ
プ１０９）。なお、処理が正常にされている限り、未転
送の更新情報ファイルはない。このように、集信用顧客
情報ファイル２２には、更新された顧客情報（会社情報
ファイル等）と、更に自己のサーバＩＤが少なくとも設
定される。但し、この際、図４、５に示した情報レベル
情報を参照することによって全国又は支社内の共通顧客
情報のみを書き込むようにする。このようにして作成さ
れた集信用顧客情報ファイル２２は、本社サーバへ転送
される（ステップ１１０）。転送したサーバは、その
後、本社サーバからの返答待ち状態になる。

【００４０】一方、本社サーバにおいては、図７に示し
たように、集信用顧客情報ファイル２２を受け取ると、
順次保存する（ステップ１１３）。そして、受け取った
集信用顧客情報ファイル２２の送信元サーバのサーバＩ
Ｄを集信済サーバＩＤ情報ファイル２５に記録する（ス
テップ１１３）。この処理が正常に終了すると、その旨
を当該送信元に通知する（ステップ１１５）。

【００４１】図６において、返答待ち状態であったサー
バは、本社サーバから本社サーバにおける処理が正常終
了した旨の通知を受け取ると（ステップ１１１）、送信
済みの集信用顧客情報ファイル２２並びに集信用顧客情
報ファイル２２の生成のために参照された更新情報ファ
イルを削除する（ステップ１１２）。

【００４２】以上のようにして、本実施の形態によれ
ば、各サーバにおいて更新された顧客情報を本社サーバ
に集信することになるが、この際、本社サーバに対して
共通顧客情報であって更新された情報を含む該当ファイ
ルのみを送信するようにしたので、通信時間の短縮に基
づく通信コストの削減並びに処理時間の短縮を図ること
ができる。一方、本社サーバにおいては、処理すべきデ
ータ量が少なくなるので、システムを構成するサーバ数
が増えたとしても排他制御の増加に伴うレスポンスの劣
化等から免れることができる。また、正常処理終了時に
送信元サーバにおけるワークファイルを削除するように
したので、ディスク容量が膨大になることから防止する
ことができる。

【００４３】なお、本実施の形態では、会社情報ファイ
ルや事業所情報ファイルなどのファイル単位に更新日時
の情報を設けたので、上記集信処理では、そのファイル
単位に更新の有無を調べるようにしたが、更新されたデ
ータのみ、例えば部署名等が更新された旨を別途記録し
て集信用顧客情報ファイル２２に設定することも可能で
ある。その分の情報を蓄積するためのディスク容量や処
理が複雑になるが、データ転送量を更に削減することが
できる。これは、取り扱う情報の種類、量によっていず
れを重視するかなどは設計事項の範囲である。

【００４４】ここで、上記配信要求処理について詳述す
る。

【００４５】サーバ利用者は、そのサーバが保有してい
ない顧客情報を参照、変更したいときに顧客情報の取得
要求を出すことによって当該顧客情報をサーバに取り込
むことができる。この処理について図８に示した顧客情
報参照（変更）、配信要求処理のフローチャートに基づ
いて説明する。

【００４６】サーバ利用者は、端末に表示された所定の
画面から参照又は変更したい顧客情報を取引者コード等
を入力することで指定する（ステップ１５１）。なお、
サーバ利用者は、顧客情報データベース１８に登録され
ている顧客リスト情報により本システムで扱う顧客を知
ることができる。指定された顧客情報が既にサーバ内に
保有している情報、すなわち全国共通若しくは自社系列
内の顧客情報（ステップ１５２）又は過去の配信要求処
理で既に取得済みの他サーバの顧客情報であれば（ステ
ップ１５３）、該当する顧客情報を顧客情報データベー
ス１８から読み出し表示する（ステップ１５４）。一
方、それ以外の自己のサーバが取得していない顧客情報
であれば、その顧客情報を取得するための配信要求情報
を生成し、一時保存する（ステップ１５３，１５５）。
配信要求情報には、顧客情報を特定しうる取引先コード
などが少なくとも含まれる。なお、表示画面から顧客情
報を変更すると（ステップ１５６）、顧客情報データベ
ース１８にその変更データで更新され、更新日時等が記
録される（ステップ１５７）。

【００４７】以上のことから、前述した集信処理におけ
る配信要求の有無の判断（図６に示したステップ１０
４）は、配信要求情報の有無により判断され、ステップ
１０５においては、取引先コード等を更新情報ファイル
に所定の形式で書き込まれることになる。また、配信処
理における配信要求の有無の判断（図９に示したステッ
プ１２９）は、集信用顧客情報ファイル２２に配信要求
が所定の形式で書き込まれているかどうかで判断でき
る。

【００４８】なお、本実施の形態における配信要求処理
は、集信処理及び後述する配信処理と同様に日毎に行う
バッチ処理なので、配信要求を集配信処理の一部に組み
入れることにし、そのため、集信用顧客情報ファイル２
２に配信要求を書き込み単一のファイルのみを本社サー
バに送出するようにしたが、リアルタイム処理にした
り、集配信処理と個別の処理としても実現することも可
能である。

【００４９】各サーバにおいて、いったん他のサーバの
顧客情報を取り込むと、他のサーバの顧客情報であって
も変更可能となる。例えば、Ａ支社サーバがＢ支社サー
バの情報を取り込むと、Ａ支社サーバは、Ｂ支社サーバ
の顧客情報を参照のみならずＡ支社内において変更する
ことができる。このとき、Ａ支社が変更した内容は、集
信処理において本社サーバへ送られ、Ｂ支社サーバの情
報を更新することになる。実際には、このようなケース
はごく稀であるだろうが、情報の整合性を保持するため
にこの処理は必須である。

【００５０】次に、本社サーバに集信された顧客情報を
整合性保持のために所定のサーバへ配信をしなければな
らない。配信処理では、本社サーバによって作成された
情報更新用のファイルが上位層から下位層のサーバへ順
次送られ、当該ファイルを受け取った各サーバは、その
ファイルを参照して各自が保有する顧客情報データベー
ス１８を更新することになる。この配信処理は、日毎に
行う定時処理であり、日毎の集信処理後に実行される。
まず、本社サーバにおいて実行される処理について図９
に示したフローチャートを用いて説明する。

【００５１】集信処理において集められた集信用顧客情
報ファイル２２を順次読み込む（ステップ１２１）。こ
の読み込む順番は、更新日時の新しい順あるいはサーバ
ＩＤ順などで予め決めておく。次のステップ１２２，１
２３については後述する。集信用顧客情報ファイル２２
を読み込むと、その内容すなわち会社情報ファイル等に
よって本社サーバの顧客情報データベース１８を更新す
る（ステップ１２４）。この更新は、ファイル単位に行
われる。そして、以降の処理で下位層の各サーバの情報
更新のために使用される配信用更新情報を生成する。

【００５２】まず、読み込んだ集信用顧客情報ファイル
２２の顧客情報が全国共通であるかを判断する（ステッ
プ１２５）。これは、会社情報ファイルの情報レベル情
報の設定を参照することで判断できる。全国共通の顧客
情報であれば、その情報を配信用更新情報として配信用
全国共通顧客情報ファイル２３に書き込む（ステップ１
２６）。また、顧客情報が支社内共通の顧客情報であれ
ば、その情報を配信用更新情報として配信用支社内共通
顧客情報ファイル２４に書き込む（ステップ１２７，１
２８）。配信用支社内共通顧客情報ファイル２４は、支
社毎に設けられているので、会社情報ファイルの情報レ
ベル情報の設定を参照して、該当する支社用の配信用支
社内共通顧客情報ファイル２４にのみ書き込むようにす
る。次に、集信用顧客情報ファイル２２に配信要求が含
まれていた場合、その要求に対応する顧客情報を顧客情
報データベース１８から読み込んで、該当する支社用の
配信用支社内共通顧客情報ファイル２４に書き込む（ス
テップ１２９，１３０）。例えば、Ａ支社からの集信用
顧客情報ファイル２２にＣ支社用の支社内共通顧客情報
にのみ登録されている顧客情報を取り込みたいという要
求があれば（例えば、当該顧客の取引先コードが配信要
求として指定されている）、その顧客の顧客情報がＡ支
社用の配信用支社内共通顧客情報ファイル２４に書き込
まれることになる。以上の処理を全ての集信用顧客情報
ファイル２２に対して繰り返し行う（ステップ１３１，
１３２）。なお、仮に本日以前に集信された集信用顧客
情報ファイル２２が何らかの理由で処理されずに残って
いる場合は、上記の本日の配信処理において共に処理さ
れることになる。どの日時までの処理が終了しているか
は、前回抽出日時情報ファイル２１に書き込まれている
日時を参照することによって知ることができる。また、
集信用顧客情報ファイル２２が配信処理開始までに本社
サーバに送られてこなかった場合は、マスタファイル１
６の未集信サーバ情報にそのサーバのサーバＩＤが書き
込まれ、必要に応じて報告される。

【００５３】ここで、ステップ１２２，１２３について
説明する。本社サーバでは、集信用顧客情報ファイル２
２を順番に読み込んで顧客情報の更新を実行するが、複
数の支社等で同一の顧客情報、正確には顧客情報を構成
する同一の会社情報ファイル等に対して同日に更新され
る場合もあり得る。例えば、２支社から同一部署の名称
の変更がされたり、一方の支社が部署名を他方の支社が
部署電話番号を変更したりする場合である。このような
場合、ファイル単位で更新を行うと、先に更新した内容
が後処理の情報で上書きされ更新済みの情報が元に戻さ
れてしまうことになる。そこで、同じ配信処理で既に更
新がされている場合、後に読み込んだ集信用顧客情報フ
ァイル２２による自動更新は行わずに、その旨とその更
新内容を出力するなどして報告のみ行うようにしてい
る。これが、ステップ１２２，１２３の処理である。

【００５４】以上の処理により配信用全国共通顧客情報
ファイル２３及び配信用支社内共通顧客情報ファイル２
４が作成されると、次に、情報削除処理部１４が行う削
除顧客情報抽出処理（ステップ１３３）により削除対象
顧客情報ファイル２６が作成される。この処理を図１０
に示したフローチャートを用いて説明する。この処理
は、更新の有無に関係なく全顧客情報に対して行われ
る。

【００５５】まず、マスタファイル１６の削除開始情報
から削除開始日数を読み込む（ステップ１４１）。削除
開始日数には、例えば「３０日」と指定されている。次
に、顧客情報を構成する会社情報等の各ファイルに記録
されている更新日時と本社サーバのシステム時刻との差
を取り、更新されてからの経過日数を得る（ステップ１
４２）。この求めた経過日数は、システム内においてい
ずれのサーバによっても情報の更新がされていない日数
であることを意味する。経過日数が削除開始日数を超え
ていた場合、その顧客情報の識別情報を削除対象顧客情
報ファイル２６に書き込む（ステップ１４３，１４
４）。

【００５６】なお、本実施の形態における削除顧客情報
抽出処理においては、全サーバに共通する単一の削除開
始日数を設定したが、支社毎に設定したり、顧客情報の
更新日時のみならず参照日時等のデータも取るなどして
より細かな処理にすることも可能である。

【００５７】以上のようにして、配信用全国共通顧客情
報ファイル２３、配信用支社内共通顧客情報ファイル２
４並びに削除対象顧客情報ファイル２６が生成される
と、各支社へ該当するファイルを転送することになる
（ステップ１３４）。すなわち、例えば、Ａ支社には配
信用全国共通顧客情報ファイル２３、削除対象顧客情報
ファイル２６及びＡ支社用の配信用支社内共通顧客情報
ファイル２４が、Ｂ支社には配信用全国共通顧客情報フ
ァイル２３、削除対象顧客情報ファイル２６及びＢ支社
用の配信用支社内共通顧客情報ファイル２４がそれぞれ
転送される。転送後、本社サーバは、各支社サーバから
の返答待ち状態になる。

【００５８】次に、配信用全国共通顧客情報ファイル２
３等が送られてきた各支社サーバにおける配信処理につ
いて図１１を用いて説明する。

【００５９】ここでの処理は、本社サーバが受け取った
集信用顧客情報ファイル２２に基づいて顧客情報データ
ベース１８を更新する処理と基本的に同様である。すな
わち、支社サーバが受け取った配信用全国共通顧客情報
ファイル２３に含まれている顧客情報（会社情報ファイ
ル等）に基づき顧客情報データベース１８の全国共通顧
客情報を更新し、受け取った配信用支社内共通顧客情報
ファイル２４に含まれている顧客情報（会社情報ファイ
ル等）に基づき顧客情報データベース１８の支社内共通
顧客情報を更新することになる（ステップ１５１）。仮
に本日以前に受け取った配信用全国共通顧客情報ファイ
ル２３等が何らかの理由で処理されずに残っている場合
は、本社サーバと同様に本日分とまとめて処理されるこ
とになる。また、配信要求によって取得した顧客情報も
配信要求処理部１３によって顧客情報データベース１８
に書き込まれる。

【００６０】更新が終了すると、支社サーバは、上記処
理が正常に終了すると、その旨を本社サーバへ通知する
（ステップ１５２）。

【００６１】図９において、返答待ち状態であった本社
サーバは、各支社サーバから各支社サーバにおける処理
が正常終了した旨の通知を受け取ると（ステップ１３
５）、配信用全国共通顧客情報ファイル２３、配信用支
社内共通顧客情報ファイル２４及び削除対象顧客情報フ
ァイル２６を削除する（ステップ１３６）。なお、この
削除する処理（ステップ１３５，１３６）は、全支社か
らの返答を待ったり、返答のあった支社に対する配信用
支社内共通顧客情報ファイル２４を逐次削除し、全支社
サーバから返答があった時点で配信用全国共通顧客情報
ファイル２３を削除するなどしてもよい。この削除処理
の詳細な処理手順は、設計事項の範囲である。

【００６２】図１１に戻ると、支社サーバは、情報削除
処理部１４によって配信要求処理で過去に取り込んだ他
支社に関する顧客情報を削除する（ステップ１５３）。
これは、本社サーバから送られてきた削除対象顧客情報
ファイル２６を参照し、削除対象とされている顧客情報
のうち他支社に関する顧客情報のみを削除する。サーバ
内で本来保有すべき顧客情報は削除しない。本実施の形
態においては、一定期間本システム内で更新がされてい
ない顧客情報は、自己のサーバ内においても上記経過日
数の間更新しておらず、自己のサーバにおいて不要とな
った顧客情報であると判断して削除することにした。こ
れにより、一時的に必要であった顧客情報を一定期間経
過後に自動削除できるので、使用するディスク容量が膨
大となることから防止することができる。

【００６３】次に、支社サーバは、下位層にサーバが存
在するのであれば（ステップ１５４）、すぐ下位のサー
バに対して配信用全国共通顧客情報ファイル２３等を転
送する（ステップ１５５）。Ａ支社サーバであればＡ１
〜Ａ４営業所サーバに、Ｄ支社サーバであればＤ１〜Ｄ
５支店サーバにそれぞれ転送する。Ｃ支社サーバは、下
位層にサーバが存在しないので、ここでＣ支社系列にお
ける配信処理は終了する。転送後、支社サーバは、すぐ
下位のサーバからの返答待ち状態になる。

【００６４】この下位層におけるサーバの処理は、図１
１を用いて説明した支社サーバにおける配信処理と同じ
である。但し、本社サーバに対してでなくすぐ上位のサ
ーバに対して正常終了の通知が行われることになる。

【００６５】返答待ちであった支社サーバは、すぐ下位
のサーバからそのサーバにおける処理が正常終了した旨
の通知を受け取ると（ステップ１５６）、配信用全国共
通顧客情報ファイル２３等を削除するが（ステップ１５
７）、その削除処理の詳細は、本社サーバにおける削除
処理（ステップ１３５，１３６）と同様に行う。

【００６６】以上のような手順で配信処理を行うことに
よって、分散された共通顧客情報の整合性を保持するこ
とができる。

【００６７】以上説明した本実施の形態においては、自
己サーバが管理するビル（顧客）に関する情報は、その
サーバのみが保有することを基本的な考えとしている。
いわゆる分散型である。しかし、業務上複数のサーバで
共有した方がよいと考えられる顧客情報は、各サーバに
それぞれ持たせることで論理的に共有するようにした。
そして、前述した集信処理及び配信処理を行うことで現
実には物理的に分散した共有データの整合性を保持する
ようにした。このように、論理的な共通情報（全社、支
社内共通顧客情報）と分散した情報（個別顧客情報）と
を分類し、必要最小限と思われる顧客情報を各サーバに
持たせることによって、各サーバにおいて必要なディス
ク容量が削減できる。その一方、サーバ利用者は、サー
バ内における顧客情報が分類されたことを意識すること
なく利用することができる。また、更新した顧客情報の
みを集配信するようにしたので、通信コストの削減並び
に処理時間の短縮化を図ることができる。

【００６８】また、分散したことで通常保有していない
他のサーバの顧客情報については、要求を出すことによ
って取得することができるようにした。

【００６９】更に、取得した他のサーバの顧客情報は、
一定期間保持することで今後の再利用のために便宜を図
り、アクセスしない一定期間経過後に原則として自動削
除することでディスク容量の増大を防止することができ
る。

【００７０】なお、本実施の形態においては、共通情報
の整合性を保持するために行う集信、配信処理を日毎の
バッチ処理としたが、より短い周期としたり、あるいは
リアルタイムに集配信処理を行うようにすることもでき
る。

【００７１】また、本実施の形態では、複数サーバで共
通する顧客に関する顧客情報をまとめて共通顧客情報と
して扱ったが、それぞれの顧客情報が膨大な場合は、更
に顧客情報を一般的な情報と詳細情報とに分類し、一般
的な情報のみを共通情報として扱い、詳細情報に関して
は共通しない顧客情報として扱うなどの応用をすること
も可能である。

【００７２】また、本実施の形態では、全国規模に散在
する監視対象のビルに設置されたエレベータや冷暖房等
の設備を遠隔地から監視するシステムに適用した例で説
明したが、これに限られたものではなく、複数サーバで
共有する情報を取り扱う様々なシステムに適用すること
ができる。

【００７３】

【発明の効果】本発明によれば、情報をレベルに応じて
各サーバに共通する情報とそうでない個別の情報とに分
類し、各サーバにおいて自己のサーバに関係のない他の
サーバの情報を持たせないようにしたので、その分の保
有データ量が削減されるためディスク容量の削減を図る
ことができる。その一方で、統一された情報を論理的に
共有することができる。

【００７４】また、物理的には分散している共通情報を
更新した場合、更新した内容を情報集配信サーバに集約
し、その更新内容を各サーバに分配するようにしたの
で、共通情報の整合性を保持することができる。特に、
この集配信処理では、更新された情報のみを集配信する
ようにしたので、通信データ量を削減できるため、その
結果通信コストの削減を図ることができる。

【００７５】また、各サーバは、配信処理の際、上位か
ら送られてきた配信用更新情報を単に接続された下位の
サーバにのみ送出するようにしたので、各サーバにおけ
る配信処理は容易となる。

【００７６】また、配信要求をすることができるので、
通常自己で保有していないシステム内における情報を取
得することができる。

【００７７】また、本来的に常時保有しておかない配信
要求により受け取った情報を一定期間経過後に削除する
ようにしたので、ディスク使用量が無限に増大すること
から防止することができる。

【図面の簡単な説明】

【図１】 本発明に係る分散データ管理システムの一実
施の形態を示したシステム全体構成図である。

【図２】 本実施の形態における各サーバの機能ブロッ
ク構成図である。

【図３】 本実施の形態で使用するマスタファイルのデ
ータ構成の内容例である。

【図４】 本実施の形態で扱う顧客情報の構成を示した
概略図である。

【図５】 本実施の形態における情報レベル情報の設定
内容例を示した図である。

【図６】 本実施の形態における各サーバにおいて実行
される集信処理について示したフローチャートである。

【図７】 本実施の形態における本社サーバにおいて実
行される集信処理について示したフローチャートであ
る。

【図８】 本実施の形態における顧客情報参照（変
更）、配信要求処理を示したフローチャートである。

【図９】 本実施の形態における本社サーバにおいて実
行される配信処理について示したフローチャートであ
る。

【図１０】 本実施の形態における本社サーバにおいて
実行される削除顧客情報抽出処理について示したフロー
チャートである。

【図１１】 本実施の形態における各サーバにおいて実
行される配信処理について示したフローチャートであ
る。

【図１２】 従来の集中型監視システムの構成を示した
概略図である。

【符号の説明】

１０ サーバ、１１ 集信処理部、１２ 配信処理部、
１３ 配信要求処理部、１４ 情報削除処理部、１５
情報入出力処理部、１６ マスタファイル、１７ ワー
クファイル、１８ 顧客情報データベース、２１ 前回
抽出日時情報ファイル、２２ 集信用顧客情報ファイ
ル、２３ 配信用全国共通顧客情報ファイル、２４ 配
信用支社内共通顧客情報ファイル、２５ 集信済サーバ
ＩＤ情報ファイル、２６ 削除対象顧客情報ファイル。

Claims (6)

【特許請求の範囲】
1. 【請求項１】 データベースを有するサーバを階層的に
   接続した分散データ管理システムにおいて、 前記各サーバは、システム内で扱う情報を、前記サーバ
   において共通して使用する共通情報とそれ以外の個別情
   報とに分類して管理する情報レベル情報を保持し、前記
   共通情報と各サーバが管理すべき前記個別情報とを前記
   データベースに保有することを特徴とする分散データ管
   理システム。
2. 【請求項２】 前記各サーバは、 内部で更新した前記共通情報の更新内容に基づき集信用
   更新情報を生成し、階層最上位に位置する情報集配信サ
   ーバに送出する集信処理手段と、 前記情報集配信サーバが生成した配信用更新情報に基づ
   き前記データベース内の共通情報を更新する配信処理手
   段と、 を有し、 前記情報集配信サーバは、 前記サーバから送られてきた前記集信用更新情報を収集
   する集信用更新情報収集手段と、 収集した前記集信用更新情報に基づき全ての前記共通情
   報の更新内容を集約して前記配信用更新情報を生成する
   配信用更新情報生成手段と、 前記配信用更新情報を全ての前記サーバに分配する更新
   情報分配手段と、 を有し、 全ての前記サーバが個々に保有する前記共通情報の整合
   性を図ることを特徴とする請求項１記載の分散データ管
   理システム。
3. 【請求項３】 前記各サーバは、前記共通情報を、全サ
   ーバに共通する全サーバ共通情報とシステムの階層構造
   を構成するサーバ系列毎に共通するサーバ系列共通情報
   とに分類して管理する情報レベル情報を保持し、 前記配信用更新情報生成手段は、前記全サーバ共通情報
   の更新内容を集約した配信用共通更新情報と、前記サー
   バ系列共通情報の更新内容をサーバ系列毎に集約した配
   信用サーバ系列共通更新情報とを前記配信用更新情報と
   して生成し、 前記更新情報分配手段は、前記配信用共通更新情報を全
   ての前記サーバに、前記各配信用サーバ系列共通更新情
   報を対応するサーバ系列内の前記各サーバに分配するこ
   とを特徴とする請求項２記載の分散データ管理システ
   ム。
4. 【請求項４】 前記配信処理手段は、上位の前記サーバ
   から送られてきた前記配信用更新情報を接続された下位
   の前記サーバへ送出することを特徴とする請求項２記載
   の分散データ管理システム。
5. 【請求項５】 前記各サーバは、自己が保有せず他のサ
   ーバが保有している情報の配信要求を前記情報集配信サ
   ーバに送出するとともに配信要求に応じて返答された情
   報を前記データベースに書き込む配信要求処理手段を有
   し、 前記情報集配信サーバは、前記サーバからの前記配信要
   求に従い該当する情報を配信要求をした前記サーバへ送
   出する要求情報送出手段を有することを特徴とする請求
   項２記載の分散データ管理システム。
6. 【請求項６】 前記各サーバは、配信要求により受け取
   った情報を一定期間経過後に削除する情報削除手段を有
   することを特徴とする請求項５記載の分散データ管理シ
   ステム。