(57)【要約】      （修正有）【課題】処理の迅速性を犠牲にすることなく、業務データを地理的に離れた複数拠点に確実に保全する。【解決手段】第１のデータセンター12内に第１のAPサーバ14、第１のDBサーバ16、第２のDBサーバ18が設置されると共に、第２のデータセンター20内に第２のAPサーバ22、第３のDBサーバ24、第４のDBサーバ26が設置されたデータ管理システム10であり、全DBサーバは共通のテーブルを備え、各テーブルにはレコードの削除及び更新が禁止される制約が課せられている。各APサーバは、全DBサーバと接続されている。業務処理部30は、人工キー管理部32から発行された人工キーよりなるIDを主キーとする業務データを生成し、データ制御部34及び各DB連絡部38を介して各DBサーバに送信する。全DBサーバからの受取完了通知を受け取るまで、業務処理部30は当該業務データを参照外とする。【選択図】図２
2015165357.tif 000002
【特許請求の範囲】
【請求項１】
相互に所定の距離を隔てて設けられた複数のデータセンター内に、それぞれAPサーバと複数のDBサーバを設置したデータ管理システムであって、
上記の全DBサーバは、相互に共通するデータを格納するテーブルをそれぞれ備える共に、各テーブルにはレコードの削除及び更新が禁止される制約が設けられており、
上記の各APサーバは、同一データセンター内に設置された各DBサーバと接続されると共に、他のデータセンター内に設置された各DBサーバとも接続されており、
また各APサーバは、少なくとも一つの業務処理部と、人工キー管理部と、データ制御部と、複数のDB連絡部を備えており、
上記業務処理部は、業務処理の結果である業務データを生成するに際し、上記人工キー管理部に対して人工キーの発行を要求すると共に、この人工キー管理部によって発行されたユニークな人工キーよりなるIDを主キーとして備えた業務データを生成し、
上記人工キー管理部は、同一データセンター内に設置された人工キー管理テーブルを参照し、現時点で最新の人工キーの値を上記業務処理部に渡すと同時に、当該テーブルの値を更新させる処理を実行し、
上記データ制御部は、上記業務処理部から出力された業務データを複製して各DB連絡部に出力すると共に、各DB連絡部を介して各DBサーバからの受取完了通知が送信された際に、全DBサーバからの受取完了通知が揃っていることを確認した上で、上記業務処理部に登録完了通知を出力し、
上記の各DB連絡部には、それぞれ担当するDBサーバの特定情報が設定されており、
各DB連絡部は、上記データ制御部から業務データが出力された際に、自己の担当するDBサーバにSQLを発行してレコードの追加を求めると共に、当該DBサーバから受取完了通知が送信された場合には、これを上記データ制御部に出力する処理を実行し、
さらに、上記の各人工キーの所定の位置には、APサーバの識別符号が設定されており、
上記業務処理部は、上記データ制御部から登録完了通知が渡されるまでは当該業務データの参照を控えることを特徴とするデータ管理システム。
【請求項２】
上記業務データは、上記業務処理部による業務処理の結果として生成された、相互に関連性を有する複数の実体データと、各データを束ねるために生成された統合データの組合せよりなり、
この統合データは、人工キーよりなる統合IDを主キーとして格納するデータ項目のみを備え、
上記の各実体データは、当該実体データを格納するデータ項目と、人工キーよりなる独自のIDを主キーとして格納するデータ項目と、上記統合データのIDを外部キーとして格納するデータ項目を備えていることを特徴とする請求項１に記載のデータ管理システム。
【請求項３】
上記の各APサーバと各DBサーバとの間が、それぞれ複数のコネクションを介して接続されると共に、
各APサーバにはコネクション単位で上記のDB連絡部が設けられており、
上記業務データは、各DB連絡部及びコネクションを介して並列的に各DB サーバに送信されることを特徴とする請求項１または２に記載のデータ管理システム。
【請求項４】
上記業務処理部は、既存の業務データを更新する必要がある場合に、当該業務データのIDを格納するデータ項目と、人工キーからなる独自のIDを主キーとして格納するデータ項目と、修正後の実体データを格納するデータ項目を備えた業務データを新たに生成し、
上記データ制御部及び各DB連絡部を介してこの業務データを各DBサーバに設けられた既存のテーブルに追加登録させることにより、既存の業務データを実質的に更新することを特徴とする請求項１〜３の何れかに記載のデータ管理システム。
【請求項５】
上記業務処理部は、既存の業務データを削除する必要がある場合に、当該業務データのIDを格納するデータ項目と、人工キーからなる独自のIDを主キーとして格納するデータ項目を備えたデータ取消用の業務データを生成し、
上記データ制御部及び各DB連絡部を介してこのデータ取消用の業務データを各DBサーバに設けられた取消専用のテーブルに追加登録させることにより、既存の業務データを実質的に削除することを特徴とする請求項１〜４の何れかに記載のデータ管理システム。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、データ管理システムに係り、特に、APサーバの業務処理によって生成されたデータを、複数のDBサーバで重複管理する技術に関する。
【背景技術】
【０００２】
地震や津波、噴火等の大規模災害、あるいは原発事故やテロ等の人災によってデータベースが物理的に損壊する場合に備え、企業の基幹システムにおいては、業務データを遠隔地に設置したバックアップ用のデータベースに重複登録することが以前より行われている。
例えば、特許文献１においては、正制御装置のディスク装置にデータを登録した後、遠隔地に設置された副制御装置に同一データを送信し、その登録を求める技術が開示されている。
【特許文献１】特開平１１−８５４０８号
【非特許文献１】Webシステム入門／第１回  Webサイトの構成とJ2EEサーバ  インターネットURL：http://www.atmarkit.co.jp/fjava/rensai2/websys01/websys01.html  検索日：２０１４年１月３０日
【非特許文献２】２相コミット  インターネットURL：http://e-words.jp/w/2E79BB8E382B3E3839FE38383E38388.html  検索日：２０１４年１月３０日
【発明の開示】
【発明が解決しようとする課題】
【０００３】
このように、正副２台の制御装置によってデータを二重持ちすることにより、一方の地域において地震等が発生し、ディスク装置が物理的に破損した場合であっても、生き残った他方のディスク装置内のデータを活用することで、業務処理の連続性を担保することが可能となる。
【０００４】
ところで、複数のデータベースに対する更新処理を実行する際には、全てのデータベースに対するコミットが成立しないとデータ相互間に矛盾が生じるため、通常はXAインターフェースの２相コミットと称する調停方式が採用され、データベース相互間の整合性が担保される。
【０００５】
この２相コミットではまず、処理全体を司るマスターサーバが、対象となる各DBサーバに対し、コミットが実行可能であるかを問い合わせる。更新準備が整っているDBサーバは「準備完了」の応答を返し、すべてのDBサーバが準備を終えたことを確認した上で、マスターサーバはコミット開始を通知し、データベースが一斉に書き換えられる。書き換え中にいずれかのデータベースで異常が発生した場合、異常が生じたDBサーバは失敗を伝え、マスターサーバはすべてのサーバに処理撤回を通知して、データを復元する「ロールバック」処理を行うよう指示する（非特許文献２）。
【０００６】
このような２相コミットを採用することにより、DBサーバ間でのデータ整合性が確保され、不正なデータが発生することは確かに回避できる。
しかしながら、マスターサーバと遠隔地に設置されたDBサーバ間で何度もデータのやり取りを繰り返す必要があることから、処理の迅速性が犠牲とならざるを得なかった。このため、ATM取引のように数秒程度の待ち時間が生じても問題にならない業務処理に対しては有効であっても、例えばオンライントレードのように、コンマ何秒かの遅延も許されないような業務処理には適用できないという問題があった。
【０００７】
この発明は、このような現状に鑑みて案出されたものであり、処理の迅速性を犠牲にすることなく、大切な業務データを地理的に離れた複数拠点に確実に保全できる技術の実現を目的としている。
【課題を解決するための手段】
【０００８】
上記の目的を達成するため、請求項１に記載したデータ管理システムは、相互に所定の距離を隔てて設けられた複数のデータセンター内に、それぞれAPサーバと複数のDBサーバを設置したデータ管理システムであって、上記の全DBサーバは、相互に共通するデータを格納するテーブルをそれぞれ備える共に、各テーブルにはレコードの削除及び更新が禁止される制約が設けられており、上記の各APサーバは、同一データセンター内に設置された各DBサーバと接続されると共に、他のデータセンター内に設置された各DBサーバとも接続されており、また各APサーバは、少なくとも一つの業務処理部と、人工キー管理部と、データ制御部と、複数のDB連絡部を備えており、上記業務処理部は、業務処理の結果である業務データを生成するに際し、上記人工キー管理部に対して人工キーの発行を要求すると共に、この人工キー管理部によって発行されたユニークな人工キーよりなるIDを主キーとして備えた業務データを生成し、上記人工キー管理部は、同一データセンター内に設置された人工キー管理テーブルを参照し、現時点で最新の人工キーの値を上記業務処理部に渡すと同時に、当該テーブルの値を更新させる処理を実行し、上記データ制御部は、上記業務処理部から出力された業務データを複製して各DB連絡部に出力すると共に、各DB連絡部を介して各DBサーバからの受取完了通知が送信された際に、全DBサーバからの受取完了通知が揃っていることを確認した上で、上記業務処理部に登録完了通知を出力し、上記の各DB連絡部には、それぞれ担当するDBサーバの特定情報が設定されており、各DB連絡部は、上記データ制御部から業務データが出力された際に、自己の担当するDBサーバにSQLを発行してレコードの追加を求めると共に、当該DBサーバから受取完了通知が送信された場合には、これを上記データ制御部に出力する処理を実行し、さらに、上記の各人工キーの所定の位置には、APサーバの識別符号が設定されており、上記業務処理部は、上記データ制御部から登録完了通知が渡されるまでは当該業務データの参照を控えることを特徴としている。
【０００９】
請求項２に記載したデータ管理システムは、請求項１のシステムであって、さらに上記業務データが、上記業務処理部による業務処理の結果として生成された、相互に関連性を有する複数の実体データと、各データを束ねるために生成された統合データの組合せよりなり、この統合データは、人工キーよりなる統合IDを主キーとして格納するデータ項目のみを備え、上記の各実体データは、当該実体データを格納するデータ項目と、人工キーよりなる独自のIDを主キーとして格納するデータ項目と、上記統合データのIDを外部キーとして格納するデータ項目を備えていることを特徴としている。
【００１０】
請求項３に記載したデータ管理システムは、請求項１または２のシステムであって、さらに、上記の各APサーバと各DBサーバとの間が、それぞれ複数のコネクションを介して接続されると共に、各APサーバにはコネクション単位で上記のDB連絡部が設けられており、上記業務データが、各DB連絡部及びコネクションを介して並列的に各DB サーバに送信されることを特徴としている。
【００１１】
請求項４に記載したデータ管理システムは、請求項１〜３のシステムであって、さらに上記業務処理部が、既存の業務データを更新する必要がある場合に、当該業務データのIDを格納するデータ項目と、人工キーからなる独自のIDを主キーとして格納するデータ項目と、修正後の実体データを格納するデータ項目を備えた業務データを新たに生成し、上記データ制御部及び各DB連絡部を介してこの業務データを各DBサーバに設けられた既存のテーブルに追加登録させることにより、既存の業務データを実質的に更新することを特徴としている。
【００１２】
請求項５に記載したデータ管理システムは、請求項１〜４のシステムであって、さらに上記業務処理部が、既存の業務データを削除する必要がある場合に、当該業務データのIDを格納するデータ項目と、人工キーからなる独自のIDを主キーとして格納するデータ項目を備えたデータ取消用の業務データを生成し、上記データ制御部及び各DB連絡部を介してこのデータ取消用の業務データを各DBサーバに設けられた取消専用のテーブルに追加登録させることにより、既存の業務データを実質的に削除することを特徴としている。
【発明の効果】
【００１３】
請求項１に記載したデータ管理システムによれば、距離的に離れた複数のデータセンター内に、それぞれAPサーバと複数のDBサーバが設置され、APサーバによって生成された業務データが同一データセンター内に設置された複数のDBサーバのみならず、他のデータセンター内に設置された複数のDBサーバにも同時に送信されるため、業務データの保全性を高めることができる。
【００１４】
しかも、業務データについては障害発生時にデータの復旧に複雑な処理を要する削除や更新が禁止されており、単純に他のDBサーバから不足データをコピーするだけでデータの復旧が可能な追加登録のみが許容されているため、２相コミットのような厳格な調停方式を採用する必要がなく、各DBサーバから単純に受取通知が返ってきた時点で登録完了と認定することができる。この結果、APサーバとDBサーバ間における電文数を大幅に低減することが可能となり、データバックアップの迅速性を確保することができる。
【００１５】
各データセンターは、複数のDBサーバのみならず、APサーバも設置されており、平常時においても各データセンターにおいて業務処理が実行されるため、業務処理の負荷分散に貢献することができる。
各APサーバにおいて生成される業務データには、それぞれのAPサーバの識別符号を含む人工キーがIDとして割り振られているため、各データセンター内に設置された全DBサーバに各APサーバからバラバラに業務データが送信されても、IDが相互に重複することがなく、DBサーバ上でエラーとなる危険性はない。
【００１６】
請求項２に記載したデータ管理システムの場合、業務データが複数の実体データに細分化されているため、イーサネット（登録商標）のフレームサイズ内に収容し易くなり、APサーバとDBサーバ間の伝送効率を向上させることができる。
各実体データは、共通に保持している統合データのIDによって関連付けられているため、業務処理部は細分化された実体データを一連の業務データとして取り扱うことができる。
【００１７】
請求項３に記載したデータ管理システムの場合、APサーバと各DBサーバ間が複数のコネクションで接続されると共に、各コネクションを介して業務データが同時並列的に送信されるため、APサーバとDBサーバ間の伝送効率をさらに向上させることができる。
【００１８】
この発明の場合、DBサーバのテーブルにはレコードの削除及び更新が禁止される制約が設けられているが、請求項４及び５に記載の仕組みを用いることにより、業務データの実質的な削除や更新を実現することができる。
【発明を実施するための最良の形態】
【００１９】
図１は、この発明に係るデータ管理システム10の全体構成図である。
まず、東京に配置された第１のデータセンター12内には、第１のAPサーバ14と、第１のDBサーバ16と、第２のDBサーバ18が設置されている。
また、大阪に配置された第２のデータセンター20内には、第２のAPサーバ22と、第３のDBサーバ24と、第４のDBサーバ26が設置されている。
【００２０】
第１のAPサーバ14及び第２のAPサーバ22は、それぞれ同一のアプリケーションプログラムを備えており、インターネット等の通信ネットワーク27経由でクライアント端末28から送信されたリクエストに対し、同一の業務処理を実行する機能を有する。
【００２１】
なお、APサーバの数に限定はなく、同一機能を備えた複数のAPサーバを各データセンター内に設置し、図示しないロードバランサを介して負荷分散させることもできる。
このように、同一データセンター内に複数のAPサーバを設けておけば、何れかのAPサーバの計画停止時あるいは計画外停止時おいても、他のデータセンター内のAPサーバに切り替えることなく同一データセンター内の残りのAPサーバで代替可能となり、ダウンタイムを最小化することができる。
【００２２】
第１のDBサーバ16、第２のDBサーバ18、第３のDBサーバ24及び第４のDBサーバ26は、それぞれ共通のテーブルを備えている。
DBサーバの数にも限定はなく、３台以上のDBサーバを各データセンター内に設置することもできる。
【００２３】
第１のAPサーバ14は、LANを介して第１のDBサーバ16及び第２のDBサーバ18と接続されると共に、通信回線29を介して第２のデータセンター20内に設置された第３のDBサーバ24及び第４のDBサーバ26とも接続されている。
また、第２のAPサーバ22は、LANを介して第３のDBサーバ24及び第４のDBサーバ26と接続されると共に、通信回線29を介して第１のデータセンター12内に設置された第１のDBサーバ16及び第２のDBサーバ18とも接続されている。
【００２４】
平常時においては、東日本に設置されたクライアント端末28は第１のデータセンター12内に設置された第１のAPサーバ14に接続され、西日本に設置されたクライアント端末28は第２のデータセンター20内に設置された第２のAPサーバ22に接続される。
【００２５】
これに対し、例えば大規模な地震が首都圏で発生し、第１のデータセンター12が壊滅的な打撃を受けた場合には、DNSサーバ（図示省略）の設定変更により、東日本に設置されたクライアント端末28の接続先が第２のデータセンター20内に設置された第２のAPサーバ22に切り替えられるため、東日本のユーザに対するサービスの継続性が確保される。
同様に、第２のデータセンター20が被害を受けた場合には、西日本に設置されたクライアント端末28の接続先が第１のデータセンター12内に設定された第１のAPサーバ14に切り替えられる。
【００２６】
このように、各データセンターは平常時には近隣のクライアント端末28に対してサービスを提供する一方、災害時には全国のクライアント端末28に対してもサービスを提供することになるため、各DBサーバは普段から同一内容のデータを相互に保持しておく必要がある。
【００２７】
図２は、第１のAPサーバ14及び第２のAPサーバ22の内部構成を示すものであり、それぞれ業務処理部30と、人工キー管理部32と、データ制御部34と、複数のDB連絡部38とを備えている。
【００２８】
業務処理部30は、クライアント端末28からのリクエストに応じてデータの登録処理や検索処理等を実行するものであり、APサーバのCPUが専用のアプリケーションプログラムに従って動作することにより、実現される。
【００２９】
人工キー管理部32は、業務処理部30からのリクエストに応じて、人工キー（サロゲートキー）を発行する機能を備えている（詳細は後述）。この人工キー管理部32は、専用のミドルウェアに従ってAPサーバのCPUが動作することにより、実現される。
【００３０】
データ制御部34は、業務処理部30からデータ登録の指令を受けた際に、データをDBサーバの数だけ複製し、それぞれをDB連絡部38に渡す機能等を担うものであり、専用のミドルウェアに従ってAPサーバのCPUが動作することにより、実現される。
またデータ制御部34は、人工キー管理部32の指令を受け、同一データセンター内に設置された各DBサーバを担当するDB連絡部38に対して、人工キー管理データの更新を指令する機能をも備えている（詳細は後述）。
【００３１】
各DB連絡部38は、予め自己に割り当てられたDBサーバに対してSQL文を発行し、データの登録及び抽出を指令する機能等を果たすものであり、専用のミドルウェアに従ってAPサーバのCPUが動作することにより、実現される。
【００３２】
このシステム10において、業務処理部30によって生成されるデータは、以下の特徴を備えている。
(1) 各データは、ユニークな人工キーからなるIDを備えている。
(2) 業務処理の結果として生じた、業務上の意味を有する実体的なデータの項目数は、一つに限定される。したがって、業務処理の結果として相互に関連する複数項目のデータが発生した場合、それぞれ独立した複数件のデータとして細分化されることになる。
(3) 相互に関連する複数のデータには、各データを束ねる統合データ（親データ）のID（統合ID）を外部キーとして共通に持たせることにより、相互の関連性が表現される。
【００３３】
図３に基づいて、このデータの特徴について具体的に説明する。
例えば、クライアント端末28から予約のリクエストを受け付け、業務処理部30が対応の予約データを生成する場合、従来のシステムであれば、図３(b)に示すように、予約ID、店ID、顧客ID、金額、年月日の項目を備えた予約データ40が生成される。これらの店ID、顧客ID、金額、年月日の各項目には、１件の具体的な予約リクエストに対応する値が充填されており、相互に関連性を有している。
【００３４】
これに対し、このシステム10においては、同図(a)に示すように、１件の予約リクエストに対して、予約統合データ41、予約店データ42、予約顧客データ43、予約金額データ44、予約年月日データ45の５つのデータが、業務処理部30によって生成される。
【００３５】
「予約統合データ41」は、予約店データ42、予約顧客データ43、予約金額データ44、予約年月日データ45を束ねるための上位概念的な「親データ」であり、「予約統合ID」というユニークな人工キーが充填されるデータ項目のみをプライマリーキー（PK）として備えており、業務処理的に意味のある実体的なデータ項目は備えていない。
【００３６】
これに対し「予約店データ42」は、「予約店ID」というユニークな人工キーがプライマリーキー（PK）として充填されるデータ項目の他に、予約に係る店舗の特定情報が格納される「店ID」という実体的なデータ項目を備えている。また、「予約店データ42」には、自己の親データとなる予約統合IDを格納する「予約統合ID」のデータ項目が、外部キー（FK1）として設けられている。
【００３７】
同様に「予約顧客データ43」も、「予約顧客ID」というユニークな人工キーがプライマリーキー（PK）として充填されるデータ項目の他に、予約した顧客の特定情報が格納される「顧客ID」という実体的なデータ項目を備えている。また、「予約顧客データ43」にも、自己の親データとなる予約統合IDを格納する「予約統合ID」のデータ項目が、外部キー（FK1）として設けられている。
【００３８】
「予約金額データ44」も、「予約金額ID」というユニークな人工キーがプライマリーキー（PK）として充填されるデータ項目の他に、予約したサービスの金額が格納される「金額」という実体的なデータ項目を備えている。また、自己の親データとなる予約統合IDを格納する「予約統合ID」のデータ項目が、外部キー（FK1）として設けられている。
【００３９】
「予約年月日データ45」も、「予約年月日ID」というユニークな人工キーがプライマリーキー（PK）として充填されるデータ項目の他に、予約した日にちが格納される「年月日」という実体的なデータ項目を備えている。また、自己の親データとなる予約統合IDを格納する「予約統合ID」のデータ項目が、外部キー（FK1）として設けられている。
【００４０】
以上のように、予約店データ42、予約顧客データ43、予約金額データ44、予約年月日データ45は、それぞれ「予約統合ID」のデータ項目を外部キーとして有しており、それぞれに共通する予約統合IDが充填されるため、業務処理部30は各データの予約統合IDを参照することにより、細分化されたデータを統合し、相互に関連するデータからなる１件の予約データ（図３(b)参照）として取り扱うことが可能となる。
【００４１】
なお、予約統合データ41、予約店データ42、予約顧客データ43、予約金額データ44、予約年月日データ45は、第１のDBサーバ16、第２のDBサーバ18、第３のDBサーバ24及び第４のDBサーバ26に共通して設けられた予約統合テーブル50、予約店テーブル51、予約顧客テーブル52、予約金額テーブル53、予約年月日テーブル54に格納される。
【００４２】
ここで、図４のフローチャートに基づき、このシステム10における人工キー付与の仕組みについて説明する。
まず、業務処理の結果としてデータを生成する必要が生じた業務処理部30は、人工キー管理部32に対して、テーブルを指定して人工キーの発行を要求する（Ｓ10）。上記の予約データを生成するケースであれば、「予約統合ID」、「予約店ID」、「予約顧客ID」、「予約金額ID」、「予約年月日ID」用の人工キーの発行を要求することとなる。
【００４３】
これを受けた人工キー管理部32は、同じデータセンター内に設置されたDBサーバに格納されている人工キー管理テーブル56を参照し（Ｓ12）、それぞれの最新の人工キーを業務処理部30に通知する（Ｓ14）。
【００４４】
図５に示すように、人工キー管理テーブル56は、「テーブルID」、「APサーバID」、「次のキー値」のデータ項目を備えており、「テーブルID」＋「APサーバ」単位で最新の人工キー（次のキー値）が管理されている。
【００４５】
ここで「人工キー」とは、所定の長さ（例えば32bitまたは64bit）を備えた数値よりなる。
また、数値の下一桁（末尾）には、IDを発行したAPサーバを特定するための識別符号（０〜９の何れかの数値）がセットされている。
具体的には、図５に示すように、人工キーの下一桁管理テーブル57において、各APサーバのIDと０〜９の数値との関連性が定義されている。
また、APサーバ管理テーブル58及びデータセンター管理テーブル59において、各APサーバとデータセンターとの関連性が定義されている。
【００４６】
業務処理部30に対して人工キーの最新値を通知し終えた人工キー管理部32は、人工キー管理テーブル56の各レコードの値を更新させる（Ｓ16）。
具体的には、当該APサーバに係る予約統合テーブル50、予約店テーブル51、予約顧客テーブル52、予約金額テーブル53、予約年月日テーブル54の「次のキー値」に対して、「直前の値（上記の最新値）の中で、末尾の識別符号を除いた部分で構成される数値に、１を加算した値」をセットする。
【００４７】
ただし、人工キーの最新値の更新方法としては、このような「昇順」に限定されるものではなく、「直前の値（上記の最新値）の中で、末尾の識別符号を除いた部分で構成される数値から１を減算した値」をセットする「降順」であってもよい。APサーバの識別符号も上記のような「０〜９」の数値に限定されるものではなく、他の文字種を用いてもよい。また、人工キーの先頭に識別符号を挿入してもよい。
さらには、人工キー管理テーブル56の「次のキー値」にAPサーバの識別符号を除いた数値のみを格納しておき、人工キーの発行時点で人工キー管理部32が対応の識別符号を上記数値の末尾等に付加して業務処理部30に発行することもできる。
【００４８】
人工キー管理部32から最新の人工キーを受け取った業務処理部30は、当該人工キーをIDとしてプライマリーキーや外部キーにセットしたデータを生成する（Ｓ18）。
このデータは、データ制御部34及びDB連絡部38を介して全DBサーバに送信され、それぞれに設けられた対応のテーブルにインサートされる。
【００４９】
上記のように、人工キーは「APサーバ×テーブル」単位でユニーク性が担保され、各APサーバはデータセンター管理テーブル59において特定のデータセンターと紐付けされているため、各APサーバにおいてそれぞれ独自に人工キーが発行されたとしても、下一桁の数値に独自性が確保されているため、重複する人工キーが発行される危険性はなく、各データのユニーク性は確実に担保される。
【００５０】
なお、APサーバの業務処理部30から発せられた人工キー発行のリクエストは、一旦キューに溜められた上で、FIFO（先入れ先出し）のルールに則って処理されるため、後から発生したデータに対して誤って値の小さい人工キーが発行される危険性はなく、順序性が担保される。
【００５１】
各APサーバの業務処理部30によって生成されたデータは、上記のように各DBサーバ内のテーブルに格納されることになるが、各テーブルには、デリート（削除）禁止及びアップデート（更新）禁止の制約が予め課せられている。
要するに、このシステム10においては、各テーブルに対するインサート（挿入）とセレクト（参照）のみが許容されることになる。
【００５２】
このため、既存のデータを無効にする必要が生じた場合には、レコードを削除する代わりに、他のテーブルに新たなレコードをインサートすることで同等の状態を実現する。
【００５３】
例えば、図３に示した１件の予約データ（予約統合データ＋予約店データ＋予約顧客データ＋予約金額データ＋予約年月日データ）を無効化する場合には、図６(a)に示すように、取消統合データ60＋取消対象データ61＋取消年月日データ62からなる予約取消用の各データを、それぞれ取消統合テーブル63、取消対象テーブル64、取消年月日テーブル65にインサートする。
【００５４】
「取消統合データ60」は、取消対象データ61、取消年月日データ62を束ねるための上位概念的な「親データ」であり、「取消統合ID」というユニークな人工キーが充填されるデータ項目のみをプライマリーキー（PK）として備えており、業務処理的に意味のある実体的なデータ項目は備えていない。
【００５５】
これに対し「取消対象データ61」は、「取消対象ID」というユニークな人工キーがプライマリーキー（PK）として充填されるデータ項目の他に、取消対象となる予約データの予約統合IDが格納される「取消対象」という実体的なデータ項目を備えている。また、自己の親データとなる取消統合IDを格納する「取消統合ID」のデータ項目が、外部キー（FK1）として設けられている。
【００５６】
「取消年月日データ62」も、「取消年月日ID」というユニークな人工キーがプライマリーキー（PK）として充填されるデータ項目の他に、取消年月日が格納される「年月日」という実体的なデータ項目を備えている。また、自己の親データとなる取消統合IDを格納する「取消統合ID」のデータ項目が、外部キー（FK1）として設けられている。
【００５７】
以上のように、取消対象データ、取消年月日データは、それぞれ「取消統合ID」のデータ項目を外部キーとして有しており、それぞれに共通する取消統合IDが充填されるため、業務処理部30は各データの取消統合IDを参照することにより、細分化されたデータを統合し、相互に関連するデータからなる１件の予約取消データ66（図６(b)参照）として取り扱うことが可能となる。
【００５８】
そして、予約統合テーブル50、予約店テーブル51、予約顧客テーブル52、予約金額テーブル53、予約年月日テーブル54から予約データをセレクトした後に、取消統合テーブル63、取消対象テーブル64、取消年月日テーブル65を参照し、当該予約データの「統合取消ID」が取消対象データ61の「取消対象」に格納されている場合には、当該予約データを無効なものとして除外する。
【００５９】
なお、取消統合データ60、取消対象データ61、取消年月日データ62は、第１のDBサーバ16、第２のDBサーバ18、第３のDBサーバ24及び第４のDBサーバ26に共通して設けられた取消統合テーブル63、取消対象テーブル64、取消年月日テーブル65にそれぞれ格納される。
【００６０】
また、このシステム10において登録データの修正が必要な場合には、既存レコードをアップデートする代わりに、修正後のデータを備えたレコードを新規に登録することで対応する。
例えば、図７に示すように、予約店テーブルに格納された「予約店ID：12345678901」＋「予約統合ID：22345678901」＋「店ID：M012356」のレコード67に関して、店IDを「店ID：M012357」に変更する必要が生じた場合、業務処理部30は既存レコード67の値を変更する代わりに、修正後の店IDを含む新たなレコード68をインサートする。
【００６１】
この新しいレコード68は、予約統合IDとして既存のレコード67と等しい値が設定されている一方、既存の予約店IDよりも値の大きな予約店ID（22345678901）が割り振られているため、業務処理部30は新規レコード68が修正後の値を表していることを認識でき、レコードのインサートによって実質的にデータの更新を実現することが可能となる。
なお、図示の便宜上、図７においては「予約店ID：12345678901」、「予約統合ID：22345678901」、「予約店ID：24567890141」として実際に用いられる人工キーよりも短いものが例示されている。
【００６２】
業務処理部30によって生成されたデータは、データ制御部34によってDBサーバの数だけ複製された後、各DBサーバを専門に担当するDB連絡部38を介して全DBサーバに対し一斉に送信される。
図８においては、「(1)予約統合データ41」、「(2)予約店データ42」、「(3)予約顧客データ43」、「(4)予約金額データ44」、「(5)予約年月日データ45」が、第１のDBサーバ16〜第４のDBサーバ26に送信される様子が示されている。
【００６３】
この際、各データのDBサーバへの到達順序が問われることはなく、親データである「(1)予約統合データ41」よりも先に子データである「(5)予約年月日データ45」等がDBサーバに到達していてもエラーになることはない。
これは、各子データには「(1)予約統合データ41」の「予約統合ID」が外部キーとして割り振られているため、到達順序が先後しても業務処理部30は最終的に各データを正しく束ねることが可能だからである。
【００６４】
各DBサーバは、DB連絡部38からデータを受け取って自身のメモリに格納した時点で、DB連絡部38に対して受取完了通知を送信し、その後、ハードディスクやSSD等の外部記憶装置内に設けられたテーブルに対応のレコードを格納する。
【００６５】
このDBサーバから送信された受取完了通知は、各DB連絡部38を経由してデータ制御部34に集められる。
データ制御部34は、全てのDB連絡部38から「(1)予約統合データ41」、「(2)予約店データ42」、「(3)予約顧客データ43」、「(4)予約金額データ44」、「(5)予約年月日データ45」の全データについて受取完了通知が返ってきた時点で、業務処理部30に対して登録完了通知を出力する。
【００６６】
業務処理部30は、この登録信完了通知をデータ制御部34から受け取った時点で、上記データを読み込みの対象と認識する。逆に言えば、登録完了通知が返ってくるまでの間、業務処理部30は当該データを読み込みの対象外とすることで、各DBサーバにおける登録のタイミングがずれて不正なデータが読み込まれてしまう危険性を回避している。
【００６７】
ただし、何れかのDBサーバから一定時間を経過しても受取完了通知が返って来ない場合、データ制御部34は通信障害あるいはマシントラブルが発生したものと認定し、当該DBサーバをオフラインモードに移行させる。
具体的には、当該DBサーバを一時的にシステム10から切り離し、残りのDBサーバのみに基づく運用形態に移行する。
すなわち、切り離されたDBサーバ以外の全DBサーバから受取完了通知が届いていた場合、データ制御部34から業務処理部30に対して登録完了通知が出力され、登録データが読み取りの対象となる。
【００６８】
この間、切り離されたDBサーバについて点検がなされ、必要な復旧対策が施される。例えば、通信機器の故障が原因で受取完了通知が届いていなかったと判明した場合、新しい通信機器に交換した上で、当該DBサーバをライトモード（データの書込のみが許容され、データの参照が禁止される状態）に設定し、同一データセンター内に設置された他のDBサーバから差分データをコピーする。
【００６９】
そして、格納データが最新の状態に追い着いた時点で、当該DBサーバはリード／ライトモード（データの書込及び参照が許容される状態）に設定され、システム10に再接続される。
以後、データ制御部34は、当該DBサーバを担当しているDB連絡部38を介して、データの送受信を再開する。
【００７０】
このシステム10の場合、各業務データはインサートのみが許容され、デリートやアップデートが認められないルールが適用されているため、データの復旧が極めて容易となる。
すなわち、データの削除や更新が許容されることを前提とした場合、データを復旧させるためにはDBサーバが保持している更新履歴情報に基づき、一定の時点からデータの追加や削除、更新を順番に再現する必要があり、これに長い時間と大きな負荷を要することになる。また、更新ログを確実に保存する仕組みをDBサーバ側に設ける必要がある。
【００７１】
これに対し、このシステム10のようにデータのインサートのみが許容され、削除と更新が禁止される前提の場合、他の正常なDBサーバに登録されたデータと障害が発生したDBサーバに登録されたデータを比較し、単純に足りないデータをコピーするだけで済み、データの順序（先後関係）を考慮する必要がなくなる。
【００７２】
また、このシステム10にあっては、上記のようにDB連絡部38から送信されたデータがDBサーバのメモリに格納された時点で、DBサーバから受取完了通知がAPサーバに発行されるため、極めて短時間の中に業務処理部30は当該データを読み込みの対象とすることができる。
【００７３】
これまでの常識では、メモリは揮発性の記憶手段であり、電源供給が停止された時点でデータが喪失してしまうため、不揮発性の記憶手段（ハードディスク等）にデータが格納された時点で完了通知が返されるべきとなる。
これに対し、このシステム10の場合には、あるDBサーバでデータの欠損が発生しても、単純に隣接するDBサーバから不足データをコピーするだけで追い着くことができるため、データがハードディスク等に格納されるまで待機する必要がない。
【００７４】
また、このようにデータの復旧が容易であるため、複数のDBサーバに同一データを格納するに際し、従来のように２相コミットという面倒な手順を踏むことが求められず、各DBサーバに対して単純に登録を依頼し、それぞれから受取完了通知が返ってきた時点でリード可能とすることが可能となる（いわゆるオートコミットの実現）。
この結果、APサーバとDBサーバ間の電文のやり取りが激減し、全体的な処理速度を向上させることができる。
【００７５】
また、このシステム10の場合、上記のように業務処理部30によって生成される各データが細分化され、１件の送信データの容量が極小化されているため、イーサネット（登録商標）のフレームサイズ内に多くのデータを収容し易くなり、APサーバとDBサーバ間の伝送効率を向上させることができる。
【００７６】
さらに、図９に示すように、APサーバと各DBサーバとの間にそれぞれ複数のコネクション71〜75を形成し、それぞれのコネクションと専用のDB連絡部38を介して細分化されたデータを同時並列的に送信することも可能となり、APサーバとDBサーバ間の伝送効率をさらに高めることが可能となる。
【００７７】
ただし、このように業務処理部30によって生成されるデータがデータ項目単位に細分化され、多数のDB連絡部38を用いた並列処理が実行されるとなると、APサーバ側の処理が複雑化することは否めない。これについては、APサーバ側をマルチコア化することで対応可能となる。
【００７８】
すなわち、APサーバとして多数のCPUコアを搭載したコンピュータを採用すると共に、OSやミドルウェアの機能によって多数のスレッドを起動させ、各スレッドによって業務処理部30や人工キー管理部32、多数のDB連絡部38を実現するマルチタスク方式を採用することで、APサーバ側の処理を効率化することができる。
【００７９】
図１０は、CPUコア80とスレッド81との対応関係を表しており、各スレッド81にはスレッドプール82が設けられ、そこに配置された複数のタスク83をスレッド81が順次処理していくイメージが描かれている。
この図におけるスレッド81が、各APサーバの業務処理部30、人工キー管理部32、データ制御部34、DB連絡部38として機能し、これらの各機能構成部が実行する具体的な処理が、タスク83に相当する。
【００８０】
各スレッド81は、スレッドプール82に蓄積されたタスク83を古い順に次々と実行していき、自己のスレッドプール82が空になった場合には、他のスレッド81のスレッドプール82に蓄積されたタスク83を、新しい順に実行していく。
【００８１】
なお、この発明にとって業務データの細分化は必須の構成要件ではなく、相互に関連する複数の実体データを１件のデータとしてまとめ、これに人工キーよりなるIDを付加した業務データ（図３(b)及び図６(b)参照）を業務処理部30が生成し、これをデータ制御部34及び複数のDB連絡部38を介して各DBサーバに送信するように構成することもできる。
【００８２】
上記の各種業務データ（予約統合データ41、予約店データ42、予約顧客データ43、予約金額データ44、予約年月日データ45等）には、業務処理部30によってミリ秒精度のタイムスタンプが刻印されているため、人工キーの値がMAXに達し、発行済のIDと重複するIDの再発行（リサイクル）がなされた場合でも、業務処理部30はタイムスタンプを比較することで新旧データの判定が可能となる。
【００８３】
上記においては、APサーバとDBサーバが物理的に独立して存在していることを前提に説明を展開したが、同一データセンター内であれば、APサーバとDBサーバを同一筐体のサーバコンピュータによって構成することもできる。
【図面の簡単な説明】
【００８４】
【図１】この発明に係るデータ管理システムの全体構成図である。
【図２】第１のAPサーバ及び第２のAPサーバの内部構成を示すブロック図である。
【図３】予約データの構造を示す図である。
【図４】人工キーの発行手順を示すフローチャートである。
【図５】人工キー管理テーブル等の構造を示す図である。
【図６】予約取消データの構造を示す図である。
【図７】レコードを実質的に更新する様子を示す図である。
【図８】一連の関連データを各DBサーバに送信する様子を示す図である。
【図９】一連の関連データを複数のコネクションを介してAPサーバからDBサーバへ並列送信する様子を示す図である。
【図１０】CPUコアとスレッドとの対応関係を示す図である。
【符号の説明】
【００８５】
10   データ管理システム
12   第１のデータセンター
14   第１のAPサーバ
16   第１のDBサーバ
18   第２のDBサーバ
20   第２のデータセンター
22   第２のAPサーバ
24   第３のDBサーバ
26   第４のDBサーバ
27   通信ネットワーク
28   クライアント端末
29   通信回線
30   業務処理部
32   人工キー管理部
34   データ制御部
38   DB連絡部
40   予約データ
41   予約統合データ
42   予約店データ
43   予約顧客データ
44   予約金額データ
45   予約年月日データ
50   予約統合テーブル
51   予約店テーブル
52   予約顧客テーブル
53   予約金額テーブル
54   予約年月日テーブル
56   人工キー管理テーブル
57   下一桁管理テーブル
58   サーバ管理テーブル
59   データセンター管理テーブル
60   取消統合データ
61   取消対象データ
62   取消年月日データ
63   取消統合テーブル
64   取消対象テーブル
65   取消年月日テーブル
66   予約取消データ
70〜74   コネクション
80   CPUコア
81   スレッド
82   スレッドプール
83   タスク
【図１】
2015165357.tif 000003
【図２】
2015165357.tif 000004
【図３】
2015165357.tif 000005
【図４】
2015165357.tif 000006
【図５】
2015165357.tif 000007
【図６】
2015165357.tif 000008
【図７】
2015165357.tif 000009
【図８】
2015165357.tif 000010
【図９】
2015165357.tif 000011
【図１０】
2015165357.tif 000012