WO2017078158A1 - データ管理システム - Google Patents

Abstract

【課題】関連する複数のデータをDBサーバに登録するに際し、一部のデータの登録に失敗した場合でもロールバック処理を行う必要のない技術の実現。 【解決手段】APサーバ12とDBサーバ14を備えたデータ管理システム10。APサーバ12は、業務データをDBサーバ14に送信して登録を依頼する。業務データは、相互に関連性を有する親データと複数の子データとの組合せからなり、各子データは親データのIDを備える。業務データの登録に際し、APサーバ12はまず各子データの登録を試行し、DBサーバ14から全ての子データに係る登録完了通知が届いた時点で親データの登録を依頼する。所定時間内に何れかの子データの登録完了通知が届かない場合、APサーバ12は親データの登録を中止する。業務データの参照に際し、APサーバ12は関連する親データの登録のある子データのみを対象とし、親データの登録のない子データは対象外とする。

Description

データ管理システム

　この発明はデータ管理システムに係り、特に、APサーバによって生成された各種業務データを、DBサーバに格納して管理する技術に関する。

[1] APサーバによって生成された各種業務データを、DBサーバに設けられたテーブルに保存しておき、必要に応じてこれらのデータを参照することが広く行われているが、一定の関連性を有する複数のデータを登録するに際し、一部のデータのみが登録され、残りのデータが何らかの原因によって登録されないと、データの利用時に不正な状態が生じるため、DBサーバによってトランザクション処理が実行される（非特許文献１参照）。

　例えばオンラインショッピングサイトにおいて、ユーザから３種類の商品についての注文を受け付けたAPサーバは、図１４に示すように、注文ID、カスタマID、注文日時等のデータ項目を備えた１件の注文データを生成すると共に、商品毎に注文明細ID、注文ID、アイテムID、数量等のデータ項目を備えた注文明細データ(1)、注文明細データ(2)、注文明細データ(3)を生成した後、DBサーバに各データを送信し、対応テーブルへの登録を依頼する。
　因みに、各注文明細データは注文データの「注文ID」を共通に有しており、この注文IDによって一つに束ねられているため、注文データを「親データ」と、また注文明細データを「子データ」と観念することができる。

　これら４件のデータの登録を依頼されたDBサーバは、注文データを注文テーブルに、また注文明細データ(1)、注文明細データ(2)、注文明細データ(3)を注文明細テーブルに順に登録していき、全ての登録が完了した時点で、トランザクション完了の電文をAPサーバに送信する。APサーバ側では、このトランザクション完了の電文を受け取った時点で、各データを読み込みの対象とする。

　これに対し、DBサーバによるデータの登録過程において、何らかの理由によって何れかの注文明細データの登録に失敗した場合、DBサーバは登録が完了したデータについての登録を取り消し、登録に失敗した旨の電文をAPサーバに送信する。
　これを受けたAPサーバは、注文データ、注文明細データ(1)、注文明細データ(2)注文明細データ、(3)を再度DBサーバに送信し、データの登録処理を最初からやり直す。

　このように、相互に関連性を有する複数のデータを一トランザクションとしてまとめておき、全てのデータの登録が完了しない限りデータの登録を取り消すロールバック処理を実行することにより、一部が欠損した不完全なデータを読み込むダーティーリードがなくなり、データの読み取り一貫性を担保することが可能となる。

　しかしながら、このようなトランザクション処理はDBサーバ側の機能として提供されるものであるため、一トランザクションに含まれる全てのデータを共通のDBサーバに送信する必要性があった。
　このため、複数のDBサーバを用いた負荷分散化の要請には対応することが出来ないという問題があった。
　また、ロールバック処理を実現するためには、DBサーバ側に更新ログを確実に残す仕組みを設けると共に、更新ログを用いて元の状態に復旧するという複雑な処理を強いることとなり、DBサーバの負荷を増大させる原因となっていた（非特許文献２参照）。
　さらに、APサーバ側ではDBサーバから登録完了通知が届くまで待機する必要があり、処理の効率化に反する結果となっていた。

[2] また、DBサーバはAPサーバから発行されるSQL文に応じて、業務データの登録、更新、削除、抽出処理を実行することとなるが（非特許文献３参照）、上記のようにDBサーバを介して業務データの更新や削除を実行してしまうと、後で更新前あるいは削除前のデータを参照する必要性が生じた場合に対応できないという問題が生じる。
　例えば、人事系のマスタファイルの管理に関し、これまで結婚等によって名字に変更の生じた社員については氏名の上書更新で対応してきたシステムにおいて、途中で旧姓を参照する要件が追加された場合、失われた旧姓のデータを復旧することは容易ではない。
　また、退職した社員についてはデータを削除することで対応してきた場合、後で退職社員のデータを参照する必要性が生じた際にも同様の問題が生じる。

　もちろん、最初から社員属性データに名字の変遷を記録するためのデータ項目を設けておいたり、退職の場合には「退職」のデータ項目に退職のフラグを立てるように準備したりしておけばよいのであるが、データ設計の際に将来の必要性を完全に予測することは困難であり、データ構造の冗長性にも繋がるため、現実的な対応策とはいえない。

[3] また、DBサーバに蓄積されたデータに基づき、一定の間隔でバッチ処理を実行するシステムにおいては、バッチ処理の対象期間内に属するデータと、対象期間外に属するデータを明確に分離しておかなければならず、システム構成の複雑化や運用手順の煩雑化といった問題が生じていた。

トランザクション処理　インターネットURL：http://www.weblio.jp/content/%E7%A7%BB%E5%8B%95　検索日：２０１５年１０月２０日 「ROLLBACK」を実行すると何が行われるのか？　インターネットURL：http://itpro.nikkeibp.co.jp/article/COLUMN/20071129/288388/　検索日：２０１５年１０月２０日 SQLサーバの参照／挿入／更新／削除　インターネットURL：http://www.server-world.info/query?os=Windows_Server_2012&p=sql2012&f=21　検索日：２０１５年１１月４日

　この発明は、このような現状に鑑みて案出されたものであり、関連する複数のデータをDBサーバに登録するに際し、一部のデータについて登録の失敗が生じた場合でも、ロールバック処理を行う必要のないデータ管理技術の実現を第１の目的としている。
　また、システムの運用途中で過去のデータの参照が必要となった場合にも、柔軟に対応可能なデータ管理技術の実現を第２の目的としている。
　さらに、バッチ処理の対象データと対象外のデータを分離することなく、データの蓄積と並行してバッチ処理の実行を可能とするデータ管理技術の実現を第３の目的としている。

　上記の目的を達成するため、請求項１に記載したデータ管理システムは、APサーバとDBサーバを備えたデータ管理システムであって、上記APサーバは、業務処理の結果生じた業務データを上記DBサーバに送信し、対応のテーブルへの登録を依頼する機能を備え、上記業務データは、相互に関連性を有する親データと、複数の子データとの組合せからなり、上記の各子データは、子データ固有のIDの他に、上記親データのIDを外部キーとして備えており、上記業務データの登録に際し、上記APサーバは、まず上記DBサーバに対して各子データの登録を依頼し、上記DBサーバから全ての子データに係る登録完了通知が届いた時点で親データの登録を上記DBサーバに依頼し、一定の時間内に何れかの子データの登録完了通知が届かない場合には、親データの登録を中止し、また登録済みの業務データの参照に際し、上記APサーバは、関連する親データの登録のある子データのみを参照の対象とし、関連する親データの登録のない子データについては参照の対象外とすることを特徴としている。

　請求項２に記載したデータ管理システムは、請求項１のシステムであって、さらに、複数のDBサーバを備えており、上記親データの登録に際し、上記APサーバは、上記子データの登録を依頼したDBサーバとは別個のDBサーバに対して登録を依頼することを特徴としている。

　請求項３に記載したデータ管理システムは、請求項１のシステムであって、さらに、同一のデータを格納する共通のテーブルをそれぞれ備えた複数のDBサーバを備えており、上記業務データの登録に際し、上記APサーバは、まず上記の各DBサーバに各子データの登録を依頼し、全ての子データについて、何れかのDBサーバから登録完了通知が届いた時点で親データの登録を上記の各DBサーバに依頼し、一定の時間内に何れかの子データの登録完了通知が何れのDBサーバからも届かない場合には、親データの登録を中止することを特徴としている。

　請求項４に記載したデータ管理システムは、請求項３のシステムであって、さらに、上記DBサーバのテーブルには、レコードの参照及び追加のみが許容され、削除及び更新が禁止される制約が設けられていることを特徴としている。

　請求項５に記載したデータ管理システムは、請求項４のシステムであって、さらに、上記APサーバは、既存の業務データを削除する必要がある場合に、取消対象となる業務データのIDをセットするデータ項目を備えたデータ取消用データを生成すると共に、このデータ取消用データを各DBサーバに設けられた取消専用のテーブルに追加登録させることにより、既存の業務データを実質的に無効化することを特徴としている。

　請求項６に記載したデータ管理システムは、請求項４または５のシステムであって、さらに、上記の各業務データには、それぞれ業務処理時のタイムスタンプが刻印されており、上記APサーバは、既存の業務データを更新する必要がある場合に、当該業務データと同じIDを有すると共に、修正後の値及び修正時のタイムスタンプを備えた更新用業務データを新たに生成し、この更新用業務データを上記の各DBサーバに設けられた該当のテーブルに追加登録させることにより、既存の業務データを実質的に更新することを特徴としている。

　請求項７に記載したデータ管理システムは、請求項６のシステムであって、さらに、上記APサーバは、相互に関連性を有する既存の複数の子データを同時に更新する必要がある場合に、各子データの固有のIDと、相互に共通する親データのIDと、それぞれの修正後の値と、相互に共通する修正時のタイムスタンプを備えた更新用子データを新たに生成すると共に、上記親データのIDと、上記タイムスタンプを備えた更新管理データを生成し、まず上記の各DBサーバに対して各更新用子データの登録を依頼し、全ての更新用子データについて、何れかのDBサーバから登録完了通知が届いた時点で更新管理データの登録を上記の各DBサーバに依頼し、一定の時間内に何れかの子データの登録完了通知が何れのDBサーバからも届かない場合には、更新管理データの登録を中止し、また更新用子データの参照に際し、各更新用子データに係る親データのID及びタイムスタンプを備えた更新管理データの登録のある更新用子データのみを参照の対象とし、上記更新管理データの登録のない更新用子データについては参照の対象外とすることを特徴としている。

　請求項８に記載したデータ管理システムは、APサーバとDBサーバを備えたシステムであって、上記DBサーバのテーブルには、レコードの参照及び追加のみが許容され、削除及び更新が禁止される制約が設けられており、上記APサーバは、業務処理の結果生じた業務データにデータ生成時刻をタイムスタンプとして追加した上で、上記DBサーバに送信して対応のテーブルへの登録を依頼する機能と、既存の業務データを削除する必要がある場合に、取消対象となる業務データのIDをセットするデータ項目を備えたデータ取消用データを生成すると共に、これを上記DBサーバに設けられた取消専用のテーブルに追加登録させることにより、既存の業務データを実質的に無効化する機能と、既存の業務データを更新する必要がある場合に、当該業務データと同じIDを有すると共に、修正後の値及び修正時のタイムスタンプを備えた更新用業務データを新たに生成すると共に、この更新用業務データを上記DBサーバに設けられた該当のテーブルに追加登録させることにより、既存の業務データを実質的に更新する機能と、過去の特定時点における業務データを参照する必要がある場合に、上記テーブルに格納された各業務データのタイムスタンプに記録された時刻に基づいて該当の業務データを抽出する機能を備えたことを特徴としている。

　請求項９に記載したデータ管理システムは、請求項８のシステムであって、さらに上記APサーバは、上記テーブルに格納された業務データの中で、特定の期間内に生成された業務データに基づいて所定のバッチ処理を実行する機能を備え、このバッチ処理に際し、上記テーブルに格納された各業務データのタイムスタンプに記録された時刻に基づいて、バッチ処理の対象となる業務データと、対象外の業務データとを識別することを特徴としている。

　請求項１に記載したデータ管理システムにあっては、全ての子データについてDBサーバにおける登録が完了しない限り親データの登録がなされない仕組みを備えており、またデータ参照時には「対応する親データの登録がない子データは対象外とする」というルールが適用されるため、一部の子データについての登録が失敗した場合であっても、登録に成功した残りの子データをロールバック処理によって削除する必要がない。
　また、DBサーバによるロールバック処理が不要となる結果、従来のように一つのトランザクションに含まれる複数のデータについては同一のDBサーバが登録処理を担当しなければならないという制約から開放される。
　さらに、従来のロールバックを前提としたトランザクション処理においては、全データの登録完了時にDBサーバからトランザクション成功の電文（コミット）が発行されるため、APサーバ側ではこの電文を受け取るまで待機する必要があった。これに対し、このシステムの場合にはDBサーバから各データの登録完了通知が届くだけであり、トランザクション完了の電文が発行されることがないため、その分、システム全体でのデータ通信量を削減することができると共に、APサーバの待ち時間を削減することが可能となる。

　請求項２に記載したデータ管理システムによれば、親データと子データの登録が別個のDBサーバで処理されるため、システム全体の負荷分散を図ることが可能となる。

　請求項３に記載したデータ管理システムの場合、並列化された複数のDBサーバの少なくとも一つから各子データの登録完了通知が届けば親データの登録に移行できるため、システム全体の負荷分散と処理の迅速化を図ることが可能となる。

　請求項４に記載したデータ管理システムの場合、各DBサーバに対するレコードの更新及び削除が禁止されるため、何れかのDBサーバにトラブルが発生した場合に、他のDBサーバから差分データをコピーするだけで簡単に復旧可能となる利点を有している。
　この場合でも、請求項５及び６に記載の仕組みを用いることにより、業務データの実質的な削除や更新を実現することができる。

　ところで、相互に関連性を有する複数の子データについて、請求項６の仕組みを用いて同時に値を更新するに際し、一部の子データについて登録に失敗した場合、当該子データに係る親データの登録は既に存在しているため、親データの不存在を理由に無効化するルールが適用できない。
　これに対し、請求項７に記載の仕組みを用いれば、同じタイムスタンプ及び親データのIDを備えた更新管理データの不存在を理由に、このような不正な子データを実質的に無効化することが可能となる。

　請求項８に記載のデータ管理システムの場合、APサーバによって生成される業務データには、データ生成時刻がタイムスタンプとして刻印されており、かつ、一旦生成された業務データは削除及び更新もされることなく、半永久的にDBサーバのテーブルに保存されることとなる。このため、想定外のデータ参照要求が後日に生じた場合であっても柔軟に対応できる利点を有している。

　請求項９に記載のデータ管理システムの場合、APサーバが一定の間隔でバッチ処理を実行する場合でも、各業務データのタイムスタンプを参照することにより、バッチ処理の対象データと対象外データを識別できるため、バッチ処理の対象データと対象外のデータを分離することなく、データの蓄積と並行してバッチ処理を実行することが可能となる。

　図１は、この発明に係る第１のデータ管理システム10の全体構成図である。
　まず、東京に配置された第１のデータセンター12内には、第１のAPサーバ14と、第１のDBサーバ16と、第２のDBサーバ18が設置されている。
　また、大阪に配置された第２のデータセンター20内には、第２のAPサーバ22と、第３のDBサーバ24と、第４のDBサーバ26が設置されている。

　上記の各APサーバやDBサーバの中、同一のデータセンター内に配置されたものについては、それぞれが物理的に独立したマシン（独立したIPアドレスを有する）によって構成される必要はない。
　すなわち、同一のサーバ（同一のIPアドレス）上に複数のNUMAノード（別Port番号）を指定するDeployment（配置）を行うことにより、複数のAPサーバ（APノード）やDBサーバ（DBノード）として構成してもよい。

　第１のAPサーバ14及び第２のAPサーバ22は、それぞれ同一のアプリケーションプログラムを備えており、インターネット等の通信ネットワーク27経由でクライアント端末28から送信されたリクエストに対し、同一の業務処理を実行する機能を有する。

　図示の便宜上、第１のAPサーバ14及び第２のAPサーバ22のみが描かれているが、実際には各データセンター内には同一機能を備えた複数のAPサーバが設置され、図示しないロードバランサを介して負荷分散が図られている。
　このように、同一データセンター内に複数のAPサーバを設けておけば、何れかのAPサーバの計画停止時あるいは計画外停止時おいても、他のデータセンター内のAPサーバに切り替えることなく同一データセンター内の残りのAPサーバで代替可能となり、ダウンタイムを最小化することができる。
　DBサーバの数にも限定はなく、３台以上のDBサーバを各データセンター内に設置することができる。

　第１のDBサーバ16、第２のDBサーバ18、第３のDBサーバ24及び第４のDBサーバ26は、それぞれ共通のテーブルを備えており、各テーブルには同一のデータが格納されている。
　ここでは、図２は示すように、注文テーブル40、注文取消テーブル41、注文明細テーブル42及び注文明細取消テーブル43を、各DBサーバは共通に備えている。

　注文テーブル40には、注文ID（主キー）、カスタマID（外部キー）、タイムスタンプのデータ項目が設定されている。
　また、注文取消テーブル41には、注文ID（主キー／外部キー）、タイムスタンプのデータ項目が設定されている。

　注文明細テーブル42には、注文明細ID（主キー）、注文ID（外部キー）、アイテムID（外部キー）、数量のデータ項目が設定されている。
　また、注文明細取消テーブル43には、注文明細ID（主キー／外部キー）、タイムスタンプのデータ項目が設定されている。

　上記の注文ID及び注文明細IDには、人工キーによるユニークな識別コードが格納される（詳細は後述）。

　第１の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サーバは普段から同一内容のデータを相互に保持しておく必要がある。
　また、同一データセンター内にも同一のデータを備えた複数のDBサーバが設置されているため、データを参照する際にAPサーバは任意のDBサーバにデータの抽出を依頼することができ、負荷分散を図ることができる。

　データセンターの数は２つに限定されるものではなく、可能な限り多くのデータセンターを各地に設けると共に、同一機能を備えた複数のAPサーバをそれぞれに設置し、各データセンター内に設置された全DBサーバと通信ネットワーク経由で接続するように構成することが望ましい。

　図３は、第１のAPサーバ14及び第２のAPサーバ22の内部構成を示すものであり、それぞれ業務処理部30と、人工キー管理部32と、データ制御部34と、複数のDB連絡部38とを備えている。

　業務処理部30は、クライアント端末28からのリクエストに応じてデータの生成処理や演算処理、DBサーバへの登録処理等を実行するものであり、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は、人工キー管理部32に対して、テーブルを指定して人工キーの発行を要求する（Ｓ10）。上記の注文テーブル40に格納するデータを生成するケースであれば、「注文ID」用の人工キーの発行を要求することとなる。

　これを受けた人工キー管理部32は、同じデータセンター内に設置されたDBサーバに格納されている人工キー管理テーブル46を参照する（Ｓ12）。

　図５に示すように、人工キー管理テーブル46は、「テーブルID」、「APサーバID」、「次のキー値」のデータ項目を備えており、「テーブルID」＋「APサーバ」単位で最新の人工キー（次のキー値）が管理されている。

　ここで「人工キー」とは、所定の長さ（例えば32bitまたは64bit）を備えた数値よりなる。
　また、数値の下一桁（末尾）には、データを生成したAPサーバを特定するための識別符号（０～９の何れかの数値）がセットされている。

　具体的には、人工キーの下一桁管理テーブル47において、各APサーバのIDと０～９の数値との関連性が定義されている。
　また、APサーバ管理テーブル48及びデータセンター管理テーブル49において、各APサーバとデータセンターとの関連性が定義されている。
　これら人工キーの下一桁管理テーブル47、APサーバ管理テーブル48、データセンター管理テーブル49も、人工キー管理テーブル46と同じく、同一データセンター内のDBサーバに格納されている。

　人工キー管理部32は、注文テーブル40に係る「次のキー値」の値を更新すると共に、最新の人工キー（更新前の値）を業務処理部30に通知する（Ｓ14）。
　上記の更新に際し人工キー管理部32は、当該APサーバに係る注文テーブル40の「次のキー値」に対して、「直前の値（上記の最新値）の中で、末尾の識別符号を除いた部分で構成される数値に、１を加算した値」をセットする。

　ただし、人工キーの最新値の更新方法としては、このような「昇順」に限定されるものではなく、「直前の値（上記の最新値）の中で、末尾の識別符号を除いた部分で構成される数値から１を減算した値」をセットする「降順」であってもよい。APサーバの識別符号も上記のような「０～９」の数値に限定されるものではなく、他の文字種を用いてもよい。また、人工キーの先頭に識別符号を挿入してもよい。
　さらには、人工キー管理テーブル46の「次のキー値」にAPサーバの識別符号を除いた数値のみを格納しておき、人工キーの発行時点で人工キー管理部32が対応の識別符号を上記数値の末尾等に付加して業務処理部30に発行することもできる。

　人工キー管理部32から最新の人工キーを受け取った業務処理部30は、当該人工キーをIDとして主キーや外部キーにセットしたデータを生成する（Ｓ18）。
　このデータは、データ制御部34及びDB連絡部38を介して全DBサーバに送信され、それぞれに設けられた対応のテーブル（注文テーブル40や注文明細テーブル42等）に追加登録される。

　上記のように、人工キーは「APサーバ×テーブル」単位でユニーク性が担保され、各APサーバはデータセンター管理テーブル49において特定のデータセンターと紐付けされている。このため、各APサーバにおいてそれぞれ独自に人工キーが発行されたとしても、下一桁の数値に独自性が確保されており、重複する人工キーが発行される危険性がないことから、各データのユニーク性は確実に担保される。

　なお、APサーバの業務処理部30から発せられた人工キー発行のリクエストは、一旦キューに溜められた上で、FIFO（先入れ先出し）のルールに則って処理されるため、後から発生したデータに対して誤って値の小さい人工キーが発行される危険性はなく、順序性が担保される。

　各APサーバの業務処理部30によって生成されたデータは、上記のように各DBサーバ内のテーブルに格納されることになるが、各テーブルには、削除（デリート）禁止及び更新（アップデート）禁止の制約が予め課せられている。
　要するに、このシステム10においては、各テーブルに対する追加（インサート）と参照（セレクト）のみが許容されることになる。

　このため、既存のデータを無効にする必要が生じた場合には、レコードを削除する代わりに、他のテーブルに新たなレコードを追加することで同等の状態を実現する。
　例えば、図２に示した注文テーブル40に格納された特定の注文データを無効化するには、同図の注文取消テーブル41に注文取消データを追加する。
　この注文取消データの主キーには、取消対象となる注文データの注文IDが充填されているため、業務処理部30は注文テーブル40に登録された各注文データの中で、その注文IDが注文取消テーブル41に登録されているものについては、対象外として無視する。

　同様に、注文明細データを無効化する場合には、注文明細取消テーブル43に注文明細取消データを追加する。
　この注文明細取消データの主キーには、取消対象となる注文明細データの注文明細IDが充填されているため、業務処理部30は注文明細テーブル42に登録された注文明細データの中で、その注文明細IDが注文明細取消テーブル43に登録されているものについては、対象外として無視する。

　また、このシステム10において登録データの修正が必要な場合には、既存レコードをアップデートする代わりに、修正後のデータを備えたレコードを新規に登録することで対応する。
　例えば、ある注文明細データの「数量」を修正する場合、同一の注文明細ID、注文ID、アイテムIDで数量のみを変更した注文明細データを注文明細テーブル42に追加する。
　なお、修正前のデータと修正後のデータは同じ注文明細IDを備えていても、各データにはデータ生成時の時刻がミリ秒精度でタイムスタンプに記録されているため、業務処理部30は集計時に最新のデータを間違いなく特定することができる。

　つぎに、図６のフローチャートに従い、このデータ管理システム10におけるデータの登録手順について説明する。
　まず、クライアント端末28からAPサーバ12に対して、以下の商品注文リクエストが送信されたとする。
　(1) ネコ砂（アイテムID：55555501）・・・10袋
　(2) ダイエットコーラ（アイテムID：33333302）・・・12本
　(3) ノンアルコールビール（アイテムID：22222203）・・・15本

　これを受けた業務処理部30は（Ｓ20）、人口キー管理部32から必要な人工キーの発行を受けた上で、図７に示すように、３件の注文明細データ（第１の注文明細データ61～第３の注文明細データ63）と、１件の注文データ64を生成する（Ｓ22）。
　注文データ64は親データとして機能するものであり、独自の注文IDの他、ユーザのカスタマID、注文日時、タイムスタンプのデータ項目を備えている。
　また、各注文明細データは子データとして機能するものであり、独自の注文明細IDの他、親データの注文ID、アイテムID、数量のデータ項目を備えている。

　つぎに業務処理部30は、最初に３件の注文明細データをデータ制御部34に渡し、各DBサーバへの登録を依頼する（Ｓ24）。
　これを受けたデータ制御部34は、各注文明細データを４件分にコピーし、図８に示すように、各DB連絡部38を介して第１のDBサーバ16～第４のDBサーバ26に登録させる。
　この際、各注文明細データの到達順序が問われることはなく、DBサーバ毎に順番が先後しても構わない。

　各DBサーバは、DB連絡部38からデータを受け取って自身のメモリに格納した時点で、DB連絡部38に対して登録完了通知を送信し、その後、ハードディスクやSSD等の外部記憶装置内に設けられたテーブルに対応のレコードを格納する（詳細は後述）。

　このDBサーバから送信された登録完了通知は、各DB連絡部38及びデータ制御部34を経由して業務処理部30に到達する（Ｓ26）。
　業務処理部30は、第１の注文明細データ61、第２の注文明細データ62、第３の注文明細データ63の全てについて、何れかのDBサーバから登録完了通知が返ってきた時点で（Ｓ28／Ｙ）、親データとしての注文データ64をデータ制御部34に渡し、各DBサーバへの登録を依頼する（Ｓ30）。

　これを受けたデータ制御部34は、注文データを４件分にコピーした上で、各DB連絡部38を介して第１のDBサーバ16～第４のDBサーバ26に送信し、それぞれの注文テーブル40に登録させる。
　各DBサーバは、DB連絡部38からデータを受け取って自身のメモリに格納した時点で、DB連絡部38に対して登録完了通知を送信し、その後、ハードディスクやSSD等の外部記憶装置内に設けられたテーブルに対応のレコードを格納する。
　このDBサーバから送信された登録完了通知は、各DB連絡部38及びデータ制御部34を経由して業務処理部30に到達する（Ｓ32）。

　なお、何らかの理由により、所定の時間内に特定の注文明細データについて何れのDBサーバからも登録完了通知が返ってこない場合（Ｓ28／Ｎ）、業務処理部30はタイムアウトと認定し、上記注文データ64（親データ）の登録を見送る（Ｓ34）。
　この場合、業務処理部30は、別の注文IDを備えた注文データと、別の注文明細IDを備えた第１の注文明細データ～第３の注文明細データを生成した後、改めて第１の注文明細データ～第３の注文明細データの登録を試みる。そして、各注文明細データについて何れかのDBサーバから登録完了通知が届いた時点で、新たな注文データを各DBサーバに登録させる。

　このシステム10では、このように子データである全ての注文明細データについて、何れかのDBサーバにおける登録が完了しない限り、親データである注文データの登録がなされない仕組みを備えている。
　このため、「データの参照時に、対応する親データの登録がない子データは対象外とする」というルールを採用することにより、仮に一部の注文明細データについての登録が失敗した場合であっても、登録に成功した残りの注文明細データを明示的に無効化する必要がなくなる。

　以下、図９に基づいて具体的に説明する。
　まず、業務処理部30が親データβのIDを備えた子データＤ、子データＥ、子データＦの登録を試みたところ、何らかの理由によって子データＤについての登録が完了することなくタイムアウトとなった場合、親データβの登録は見送られる。

　その代わりに業務処理部30は、親データβと実質的に同じ内容を備え、IDが変更された親データβ'を生成すると共に、先の子データＤ、子データＥ、子データＦと実質的に同じ内容で、新しいIDと親データβ'のIDとを備えた子データＤ'、子データＥ'、子データＦ'を生成し、各子データのDBサーバへの登録を試みる。そして、各子データの登録が完了した時点で、業務処理部30は親データβ'を登録させる。

　以上の結果、先に登録が完了していた子データＥ及び子データＦは、そのままDBサーバのテーブル上に残されることとなる。
　しかしながら、本システム10においては上記の通り「対応する親データの登録がない子データは処理の対象外とする」というルールに準拠しているため、業務処理部30がデータの集計等を行う際には、対応する親データβの登録がない子データＥ及び子データＦを参照の対象外として扱われる。
　このため、ロールバック処理によって子データＥ及び子データＦを明示的に無効化しなくても、これらの不整合なデータが参照されるという不都合は生じない。

　もっとも、上記のように並列化された複数のDBサーバに対して同一子データの登録を同時に依頼し、何れか一つのDBサーバから登録完了通知が届けば当該子データの登録を認定する仕組みを備えている限り、子データの登録がなされないという事態の発生は比較的レアなケースといえる。
　これに対し、この発明を１台のDBサーバのみで運用される環境に適用した際には、マシントラブルや通信障害によって子データの登録に失敗する事態の発生が想定される。

　また、DBサーバによるロールバック処理が不要となる結果、従来のように一つのトランザクションに含まれる複数のデータについては同一のDBサーバが登録処理を担当しなければならないという制約から開放される。
　このため、親データと子データの登録を別個のDBサーバで処理させることにより、負荷分散を図ることも可能となる。

　従来のロールバックを前提としたトランザクション処理においては、全データの登録完了時にDBサーバからトランザクション成功の電文（コミット）が発行されるため、APサーバ側ではこの電文を受け取るまで待機する必要があった。
　これに対し、このシステム10の場合にはDBサーバから各データの登録完了通知が届くだけであり、トランザクション完了の電文が発行されることがないため、その分、システム全体でのデータ通信量を削減することができると共に、APサーバの待ち時間を削減することが可能となる。

　因みに、上記のＳ30において親データである注文データ登録を各DBサーバに依頼したところ、一定の時間内に何れのDBサーバからも登録完了通知が返ってこないという事態の発生もあり得る。
　しかしながら、この場合には上記ルールの適用により、先に登録された各子データ（注文明細データ）は参照の対象外となっているため、ダーティーリードの問題は生じない。
　そこで業務処理部30は、親データの登録が完了するまで、Ｓ30の処理を何度でも繰り返すことができる。

　上記においては、オンライン通販というトランザクション系のデータ処理にこのシステム10を適用した例を示したが、社員や顧客の属性管理といったマスタ系のデータ処理にも応用することができる。

　図１０は、このような場合に各DBサーバに格納されるテーブルの一例を示すものであり、ユーザテーブル70と、ユーザ取消テーブル71と、氏名テーブル72と、氏名取消テーブル73と、住所テーブル74と、住所取消テーブル75と、電話番号テーブル76と、電話番号取消テーブル77と、Ｅメールテーブル78と、Ｅメール取消テーブル79とを、各DBサーバは共通に備えている。

　ユーザテーブル70には、ユーザID（主キー）及びタイムスタンプのデータ項目が設定されている。
　また、ユーザ取消テーブル71には、ユーザID（主キー／外部キー）及びタイムスタンプのデータ項目が設定されている。

　氏名テーブル72には、氏名ID（主キー）、ユーザID（外部キー）、氏名及びタイムスタンプのデータ項目が設定されている。
　また、氏名取消テーブル73には、氏名ID（主キー／外部キー）及びタイムスタンプのデータ項目が設定されている。

　住所テーブル74には、住所ID（主キー）、ユーザID（外部キー）、住所及びタイムスタンプのデータ項目が設定されている。
　また、住所取消テーブル75には、住所ID（主キー／外部キー）及びタイムスタンプのデータ項目が設定されている。

　電話番号テーブル76には、電話番号ID（主キー）、ユーザID（外部キー）、電話番号及びタイムスタンプのデータ項目が設定されている。
　また、電話番号取消テーブル77には、電話番号ID（主キー／外部キー）及びタイムスタンプのデータ項目が設定されている。

　Ｅメールテーブル78には、ＥメールID（主キー）、ユーザID（外部キー）、メールアドレス及びタイムスタンプのデータ項目が設定されている。
　また、Ｅメール取消テーブル79には、ＥメールID（主キー／外部キー）及びタイムスタンプのデータ項目が設定されている。

　つぎに、図１１のフローチャートに従い、ユーザの属性データの登録手順について説明する。
　まず、クライアント端末28からAPサーバ12に対して、以下の属性を備えたユーザの新規登録リクエストが送信されたとする。
　(1)氏名：山田太郎
　(2)住所：東京都港区虎ノ門…
　(3)電話番号：03-3508…
　(4)メールアドレス：t-yamada@…

　これを受けた業務処理部30は（Ｓ40）、人口キー管理部32から必要な人工キーの発行を受けた上で、図１２に示すように、４件の属性データ（氏名データ80、住所データ81、電話番号データ82、Ｅメールデータ83）と、１件のユーザデータ84を生成する（Ｓ42）。
　ユーザデータ84は親データとして機能するものであり、独自のユーザID及びタイムスタンプのデータ項目を備えている。
　また、各属性データは子データとして機能するものであり、独自のID（氏名ID、住所ID、電話番号ID、ＥメールID）の他、親データのユーザID、属性（氏名／住所／電話番号／メールアドレス）、タイムスタンプのデータ項目を備えている。
　各データのタイムスタンプには、同じ時刻がミリ秒単位で記述されている。

　つぎに業務処理部30は、最初に４件の属性データをデータ制御部34に渡し、各DBサーバへの登録を依頼する（Ｓ44）。
　これを受けたデータ制御部34は、各属性データを４件分にコピーし、各DB連絡部38を介して第１のDBサーバ16～第４のDBサーバ26に登録させる。
　この際、各属性データの到達順序が問われることはなく、DBサーバ毎に順番が先後しても構わない。

　各DBサーバは、DB連絡部38からデータを受け取って自身のメモリに格納した時点で、DB連絡部38に対して登録完了通知を送信し、その後、ハードディスクやSSD等の外部記憶装置内に設けられたテーブルに対応のレコードを格納する。

　このDBサーバから送信された登録完了通知は、各DB連絡部38及びデータ制御部34を経由して業務処理部30に到達する（Ｓ46）。
　業務処理部30は、氏名データ80、住所データ81、電話番号データ82、Ｅメールデータ83の全てについて、何れかのDBサーバから登録完了通知が返ってきた時点で（Ｓ48／Ｙ）、親データとしてのユーザデータ84をデータ制御部34に渡し、各DBサーバへの登録を依頼する（Ｓ50）。

　これを受けたデータ制御部34は、ユーザデータ84を４件分にコピーした上で、各DB連絡部38を介して第１のDBサーバ16～第４のDBサーバ26に送信し、それぞれのユーザテーブル70に登録させる。
　各DBサーバは、DB連絡部38からデータを受け取って自身のメモリに格納した時点で、DB連絡部38に対して登録完了通知を送信し、その後、ハードディスクやSSD等の外部記憶装置内に設けられたテーブルに対応のレコードを格納する。
　このDBサーバから送信された登録完了通知は、各DB連絡部38及びデータ制御部34を経由して業務処理部30に到達する（Ｓ52）。

　なお、何らかの理由により、所定の時間内に特定の属性データについて何れのDBサーバからも登録完了通知が返ってこない場合（Ｓ48／Ｎ）、業務処理部30はタイムアウトと認定し、上記ユーザデータ84の登録を見送る（Ｓ54）。
　この場合、業務処理部30は、新しいユーザIDを備えたユーザデータと、別の氏名ID等及び新しいユーザIDを備えた属性データを生成した後、改めて各DBサーバへの登録を試みる。そして、各属性データについて何れかのDBサーバから登録完了通知が届いた時点で、新たなユーザデータを各DBサーバに登録させる。

　このように、子データである全ての属性データについて、何れかのDBサーバにおける登録が完了しない限り、親データであるユーザデータ84の登録がなされない仕組みを備えているため、「データの参照時に、対応する親データの登録がない子データは対象外とする」というルールを採用することにより、仮に一部の属性データについての登録が失敗した場合であっても、登録に成功した残りの属性データを明示的に無効化する必要がなくなる。

　ユーザ登録完了後に、結婚等によってユーザの氏名に変更が生じた場合には、上記氏名ID、ユーザIDを有すると共に、新しい氏名を備えた更新氏名データが業務処理部30によって生成され、各DBサーバに登録される。
　この場合でも、業務処理部30は新旧両氏名データのタイムスタンプを比較することにより、最新の氏名を識別できる。
　また、氏名テーブル72には古い氏名データもそのまま残されているため、後になって当該ユーザの旧姓を参照する必要性が生じた場合にも対応できる。

　ユーザが退会する際には、ユーザ取消テーブル71に上記ユーザIDを備えたユーザ取消データを登録することにより、当該ユーザに係る全データを無効化することができる。
　この場合にも、ユーザテーブル70や氏名テーブル72、住所テーブル74等にはデータがそのまま残されているため、事後的に退会ユーザについてのデータを参照することができる。

　ユーザが引っ越しを行い、住所と電話番号が同時に変更された場合には、上記住所ID及びユーザIDと、新しい住所を備えた更新住所データが生成されると共に、上記電話番号ID及びユーザIDと、新しい電話番号を備えた更新電話番号データが業務処理部30によって生成され、各DBサーバへの登録が実行される。

　この際、両更新データについて無事に登録が完了すれば問題ないが、何れか一方の更新データ（例えば更新住所データ）の登録が完了し、他方の更新データ（例えば更新電話番号データ）の登録に失敗した場合には問題が生じる。
　すなわち、この時点ではすでに両更新データの親データであるユーザデータが存在しているため、業務処理部30は登録に成功した更新住所データを無効扱いにすることができない。
　この結果、更新電話番号データの登録が完了するまでの間、当該ユーザの属性データを表示する際には、新住所と旧電話番号が併記されるという不正な状況（ダーティリード）が生じる。

　このような不都合を回避するためには、図１３(a)に示すように、更新管理テーブル85を事前に各DBサーバに設けておくことが有効である。
　この更新管理テーブル85は、ユーザIDと、タイムスタンプのデータ項目を備えている。

　ここで、上記のようにユーザの住所と電話番号が同時に変わった場合、図１３(b)に示すように、更新住所データ86と更新電話番号データ87及び更新管理データ88が業務処理部30によって生成される。

　更新住所データ86は、従前の住所IDとユーザID、及び変更後の住所とタイムスタンプを備えている。
　また更新電話番号データ87は、従前の電話番号IDとユーザID、及び変更後の電話番号とタイムスタンプを備えている。
　更新管理データ88は、ユーザIDと、タイムスタンプを備えている。
　上記更新住所データ86、更新電話番号データ87及び更新管理データ88の各タイムスタンプには、同じ時刻が記録されている。

　つぎに業務処理部30は、データ制御部34及び各DB連絡部38を介して更新住所データ86及び更新電話番号データ87を各DBサーバに送信し、登録を依頼する。
　これを受けた各DBサーバは、更新住所データ86を住所テーブル74に、また更新電話番号データ87を電話番号テーブル76に格納する。

　つぎに業務処理部30は、何れかのDBサーバから更新住所データ86と更新電話番号データ87について登録が完了した旨の通知が送信された時点で、データ制御部34及び各DB連絡部38を介して更新管理データ88を各DBサーバに送信し、登録を依頼する。

　これに対し、何らかの理由により、更新住所データ86及び更新電話番号データ87の少なくとも一方、例えば更新住所データ86について何れのDBサーバからも登録完了通知が届かない場合、業務処理部30は更新管理データ88の送信を保留する。
　そして、タイムアウトした後、業務処理部30は新しく更新住所データ、更新電話番号データ、更新管理データを生成し、再び更新住所データ及び更新電話番号データの登録を試みる。

　この場合、登録に成功した最初の更新電話番号データ87がDBサーバ側に残されることとなるが、業務処理部30が各属性データを取り扱う際に、以下のルールを適用することにより、ロールバック処理によって更新電話番号データ87を明示的に無効化しなくても、これを実質的に無効化することが可能となる。

(1) 親データのID及び子データのIDを共通にする複数の子データが存在している場合、対応する親データの登録の有無をチェックし、登録のあるものは有効とし、登録のないものは無効とする。
(2) ルール(1)の適用後に有効な子データが複数残された場合、タイムスタンプが最古の子データ（新規登録時の子データ）を除き、更新データと認定する。
(3) 更新データについては、同じタイムスタンプを備えた更新管理データの登録の有無をチェックし、登録のあるものは有効とし、登録のないものは無効とする。

　このシステム10の場合、上記のように各DBサーバには同一のデータが格納されており、また各APサーバは同一の業務処理を実行する機能を備えているため、多数のクライアント端末28に対して同時並行的にサービスを提供することが可能となり、システム10全体の負荷分散が可能となる。

　また、親データの登録に先立ち、複数の子データの登録を各DBサーバに依頼した際には、各データについて少なくとも一つのDBサーバから登録完了通知が届いた時点で親データの登録に移行でき、全てのDBサーバからの登録完了通知を待つ必要がないため、処理の迅速化が図れる。

　なお、何れかのDBサーバから一定時間を経過しても登録完了通知が返って来ない場合、データ制御部34は通信障害あるいはマシントラブルが発生したものと認定し、当該DBサーバをオフラインモードに移行させる。
　具体的には、当該DBサーバを一時的にシステム10から切り離し、残りのDBサーバのみに基づく運用形態に移行する。

　この間、切り離されたDBサーバについて点検がなされ、必要な復旧対策が施される。例えば、通信機器の故障が原因で登録完了通知が届いていなかったと判明した場合、新しい通信機器に交換した上で、当該DBサーバをライトモード（データの書込のみが許容され、データの参照が禁止される状態）に設定し、同一データセンター内に設置された他のDBサーバから差分データをコピーする。

　このシステム10の場合、上記の通り、各業務データは追加のみが許容され、削除や更新が認められないルールが適用されているため、データの復旧が極めて容易となる。
　すなわち、データの削除や更新が許容されることを前提とした場合、データを復旧させるためにはDBサーバが保持している更新履歴情報に基づき、一定の時点からデータの追加や削除、更新を順番に再現する必要があり、これに長い時間と大きな負荷を要することになる。また、更新ログを確実に保存する仕組みをDBサーバ側に設ける必要がある。

　これに対し、このシステム10のようにデータの追加のみが許容され、削除と更新が禁止される前提の場合、他の正常なDBサーバに登録されたデータと障害が発生したDBサーバに登録されたデータを比較し、単純に足りないデータをコピーするだけで済む。

　そして、格納データが最新の状態に追い着いた時点で、当該DBサーバはリード／ライトモード（データの書込及び参照が許容される状態）に設定され、システム10に再接続される。
　以後、データ制御部34は、当該DBサーバを担当しているDB連絡部38を介して、データの送受信を再開する。

　また、このシステム10にあっては、上記のようにDB連絡部38から送信されたデータがDBサーバのメモリに格納された時点で、DBサーバから登録完了通知がAPサーバに発行されるため、極めて短時間の中に業務処理部30は当該データを読み込みの対象とすることができる。

　これまでの常識では、メモリは揮発性の記憶手段であり、電源供給が停止された時点でデータが喪失してしまうため、不揮発性の記憶手段（ハードディスク等）にデータが格納された時点で完了通知が返されるべきとなる。
　これに対し、このシステム10の場合には、あるDBサーバでデータの欠損が発生しても、単純に隣接するDBサーバから不足データをコピーするだけで追い着くことができるため、データがハードディスク等に格納されるまで待機する必要がない。

　上記の各種業務データ（注文データ、注文明細データ、属性データ、ユーザデータ等）には、上記のように業務処理部30によってミリ秒精度のタイムスタンプが刻印されているため、人工キーの値がMAXに達し、発行済のIDと重複するIDの再発行（リサイクル）がなされた場合でも、業務処理部30はタイムスタンプを比較することで新旧データの判定が可能となる。

　あるいは、同種テーブルを一定の期間単位で細分化し、この期間が経過する都度、データの格納先を物理的に分離された新しいテーブルに変更するように運用することにより、上記人工キーの重複問題を有効に解決することができる。
　例えば、上記注文明細テーブル42を、「2016年８月の注文明細テーブル」、「2016年９月の注文テーブル」…のように細分化することが該当する。
　なお、１ヶ月以内に人工キーの値がMAXに達してしまうような場合には、週毎あるいは日毎に同種の新テーブルに移行するように運用すればよい。

　この発明の実現においては、必ずしも複数のAPサーバと複数のDBサーバの存在が必須要件ではなく、少なくとも１台のAPサーバと１台のDBサーバを備えた環境下であれば有効に機能し得る。

　図１５は、この発明に係る第２のデータ管理システム210の全体構成図であり、DBサーバ212と、第１のAPサーバ214と、第２のAPサーバ216と、第３のAPサーバ218とを備えている。
　DBサーバ212と、第１のAPサーバ214、第２のAPサーバ216、第３のAPサーバ218との間は、それぞれ通信ネットワークを介して接続されている。

　DBサーバ212の外部記憶装置内には、例えば、仕入テーブル220と、仕入取消テーブル222と、販売価格テーブル224と、販売価格取消テーブル226とが設けられている。

　図１６(a)に示すように、仕入テーブル220には、仕入ID、仕入先ID、商品ID、数量、価格及びタイムスタンプの各データ項目が設定されている。
　また、仕入取消テーブル222には、図１６(b)に示すように、仕入ID及びタイムスタンプの各データ項目が設定されている。
　販売価格テーブル224には、図１６(c)に示すように、販売価格ID、商品ID、価格及びタイムスタンプの各データ項目が設定されている。
　販売価格取消テーブル226には、図１６(d)に示すように、販売価格ID及びタイムスタンプの各データ項目が設定されている。

　このシステム210において、各テーブルには、削除（デリート）禁止及び更新（アップデート）禁止の制約が予め課せられている。
　すなわち、このシステム210においては、各テーブルに対する追加（インサート）と参照（セレクト）のみが許容されることになる。

　このため、既存のデータを無効にする必要が生じた場合には、レコードを削除する代わりに、他のテーブルに新たなレコードを追加することで同等の状態を実現する。
　例えば、図１６(a)に示した仕入テーブル220に格納された特定の仕入データを無効化するには、同図(b)の仕入取消テーブル222に仕入取消データを追加する。
　この仕入取消データの主キーには、取消対象となる仕入データの仕入IDが充填されているため、このデータを利用するに際しAPサーバは、仕入テーブル220に登録された各仕入データの中で、その仕入IDが仕入取消テーブル222に登録されているものについては、対象外として無視する。

　同様に、図１６(c)に示した販売価格テーブル224に格納された特定の販売価格データを無効化するには、同図(d)の販売価格取消テーブル226に販売価格取消データを追加する。
　この販売価格取消データの主キーには、取消対象となる販売価格データの販売価格IDが充填されているため、このデータを利用するに際しAPサーバは、販売価格テーブル224に登録された販売価格データの中で、その販売価格IDが販売価格取消テーブル226に登録されているものについては、対象外として無視する。

　また、このシステム210において登録データの修正が必要な場合には、既存レコードをアップデートする代わりに、修正後のデータを備えたレコードを新規に登録することで対応する。
　例えば、ある仕入データの「数量」を修正する場合、APサーバは同一の仕入ID、仕入先ID、商品ID、価格で、数量のみを変更した仕入データを新たに生成してDBサーバ212に送信し、仕入テーブル220に追加登録させる。
　なお、修正前の仕入データと修正後の仕入データは同じ仕入IDを備えていても、各データ生成時の時刻がミリ秒精度でタイムスタンプに記録されているため、APサーバは参照時に最新のデータを間違いなく特定することができる。

　上記第１のAPサーバ214は、各地に配属された仕入担当スタッフ228の操作するクライアント端末230から送信された仕入データや仕入取消データを受け付けると共に、各データの内容に対応するSQL文をDBサーバ212に発行し、仕入テーブル220や仕入取消テーブル222に登録させる機能を担っている。

　上記第２のAPサーバ216は、前日に発生した仕入データに基づき、バッチ処理によって翌日分の販売価格データを生成する機能を担うものである。
　以下、図１７のフローチャートに従い、第２のAPサーバ216の処理内容を説明する。

　まず、第２のAPサーバ216は、仕入テーブル220から前日分の仕入データを読み込む（Ｓ210）。バッチ処理の実行日が１０月２２日の場合、１０月２１日に生成された仕入データが該当する。

　図１８ (a)に示すように、各仕入データのタイムスタンプには、データ生成時刻がミリ秒単位で記録されているため、仕入テーブル220に対して第１のAPサーバ214からの仕入データが随時登録される環境下であっても、第２のAPサーバ216はタイムスタンプを参照することにより、バッチ処理の対象データ（１０月２１日に生成されたデータ）と対象外データ（１０月２１日以前または１０月２２日に生成されたデータ）を明確に区別することができる。

　つぎに第２のAPサーバ216は、仕入取消テーブル222を参照し、バッチ処理の対象となる前日分の仕入データの中で、仕入取消テーブルに仕入IDの登録があるものを無効な仕入データとして排除する（Ｓ212）。

　つぎに第２のAPサーバ216は、有効な各仕入データの仕入価格及び数量を商品毎に集計し、各商品の前日における平均仕入価格を算出する（Ｓ214）。
　つぎに第２のAPサーバ216は、この平均仕入価格に所定の利益を上乗せすることにより、各商品の翌日（１０月２３日）分の販売価格を算出する（Ｓ216）。
　第２のAPサーバ216は、各商品の翌日分の販売価格データを、当日（１０月２２日）中に販売価格テーブル224に格納する（Ｓ218）。

　なお、何らかの理由によって誤った販売価格データを登録してしまった場合、第２のAPサーバ216は、当該販売価格データの販売価格IDを備えた販売価格取消データをDBサーバ212に送信し、販売価格取消テーブル226に登録させる

　第３のAPサーバ218は、一般ユーザ232の操作するクライアント端末230から商品価格の提示リクエストが送信されると、販売価格テーブル224及び販売価格取消テーブル226を参照して当日有効な各商品の販売価格を導出し、クライアント端末230に送信する機能や、商品の注文を受け付ける機能を担っている。

　ここで、第３のAPサーバ218にとって当日有効な販売価格とは、第２のAPサーバ216によって前日（１０月２２日）に生成された販売価格データの中で、対応の販売価格取消データが販売価格取消テーブル226に登録されていないものを意味している。

　図１８(b)に示すように、各販売価格データのタイムスタンプには、第２のAPサーバ216によるデータ生成時刻がミリ秒単位で記録されているため、各商品に係る過去の販売価格データが販売価格テーブル224に混在しているとしても、第３のAPサーバ218は当日提示すべき各商品の販売価格を正確に識別することができる。

　上記のように、このシステム210の各APサーバによって生成されるデータには、データ生成時刻がタイムスタンプとして刻印されており、かつ、一旦生成されたデータは削除及び更新もされることなく、半永久的に各テーブルに保存されることとなる。
　このため、例えば、ある商品の仕入価格や販売価格の推移を分析する必要性が後日に生じた場合でも、各テーブルに格納された過去のデータを集計することで柔軟に対応できる。

　上記においては、このシステム210を１台のDBサーバ212によって構成した例を示したが、並列化された複数のDBサーバを用いることもできる。
　図１９は、第１のAPサーバ214、第２のAPサーバ216、第３のAPサーバ218の他に、第１のDBサーバ212及び第２のDBサーバ212'によってシステム210を構成した例を示している。
　ただし、DBサーバの数は２台に限定されるものではなく、さらに多くのDBサーバを設置することが望ましい。

　ここで、第１のDBサーバ212と第２のDBサーバ212'は、それぞれ仕入テーブル220、仕入取消テーブル222、販売価格テーブル224、販売価格取消テーブル226を備えており、各テーブルには同一のデータが重複して格納されている。
　このために、第１APサーバ214が仕入データ等を登録する際には、同じ内容のSQL文を複数生成し、第１のDBサーバ212及び第２のDBサーバ212'に対して同時に同一データの登録を依頼する。
　同様に、第２のAPサーバ216が販売価格データ等を登録する際には、同じ内容のSQL文を複数生成し、第１のDBサーバ212及び第２のDBサーバ212'に対して同時に同一データの登録を依頼する。

　これに対し、第２のAPサーバ216あるいは第３のAPサーバ218がデータを参照する際には、第１のDBサーバ212及び第２のDBサーバ212'の何れに対してもデータの抽出を依頼することができる。

　なお、何れかのDBサーバから一定時間を経過しても登録完了通知が返って来ない場合、APサーバは通信障害あるいはマシントラブルが発生したものと認定し、当該DBサーバをオフラインモードに移行させる。
　具体的には、当該DBサーバを一時的にシステム10から切り離し、残りのDBサーバのみに基づく運用形態に移行する。

　この間、切り離されたDBサーバについて点検がなされ、必要な復旧対策が施される。例えば、通信機器の故障が原因で登録完了通知が届いていなかったと判明した場合、新しい通信機器に交換した上で、当該DBサーバをライトモード（データの書込のみが許容され、データの参照が禁止される状態）に設定し、他のDBサーバから差分データをコピーする。

　このシステム210の場合、上記の通り、各業務データは追加のみが許容され、削除や更新が認められないルールが適用されているため、データの復旧が極めて容易となる。
　すなわち、データの削除や更新が許容されることを前提とした場合、データを復旧させるためにはDBサーバが保持している更新履歴情報に基づき、一定の時点からデータの追加や削除、更新を順番に再現する必要があり、これに長い時間と大きな負荷を要することになる。また、更新ログを確実に保存する仕組みをDBサーバ側に設ける必要がある。

　これに対し、このシステム210のようにデータの追加のみが許容され、削除と更新が禁止される前提の場合、他の正常なDBサーバに登録されたデータと障害が発生したDBサーバに登録されたデータを比較し、単純に足りないデータをコピーするだけで済む。

　そして、格納データが最新の状態に追い着いた時点で、当該DBサーバはリード／ライトモード（データの書込及び参照が許容される状態）に設定され、システム210に再接続される。

　図２０は、この発明をユーザデータの管理業務に適用した第３のデータ管理システム250を示すものであり、DBサーバ252と、APサーバ254とによって構成されている。
　DBサーバ252は、ユーザテーブル256と、ユーザ取消テーブル258を備えている。図示の便宜上、１台のDBサーバ252のみが描かれているが、上記と同様、相互に共通のテーブルを備えた複数のDBサーバを用いることもできる。

　図２１(a)に示すように、ユーザテーブル256には、ユーザID、氏名、住所、電話番号、メールアドレス、タイムスタンプ等のデータ項目が設定されている。
　また、ユーザ取消テーブル258には、図２１(b)に示すように、ユーザID及びタイムスタンプのデータ項目が設定されている。

　APサーバ254は、ユーザ260の操作するクライアント端末262から新規ユーザ登録のリクエストが送信されると、ユーザID、氏名、住所、電話番号、メールアドレス、タイムスタンプ等のデータ項目を備えたユーザデータを生成し、ユーザテーブル256への登録をDBサーバ252に依頼する。

　この場合も、ユーザテーブル256には削除（デリート）禁止及び更新（アップデート）禁止の制約が予め課せられている。
　このため、登録データの修正が必要な場合には、既存レコードをアップデートする代わりに、修正後のデータを備えたレコードを新規に登録することで対応する。

　例えば、図２２(a)に示すように、新規登録時のユーザデータＹ（氏名：斉藤花子）について、氏名を変更する必要性が生じた場合、APサーバ254は、同一のユーザID、住所、電話番号、メールアドレスを備え、氏名のみを「海野花子」に変更したユーザデータＹ'を新たに生成してDBサーバ252に送信し、ユーザテーブル256に追加登録させる。
　この場合、修正前のユーザデータＹと修正後のユーザデータＹ'は同じユーザID（00012346）を備えていても、各データ生成時の時刻がミリ秒精度でタイムスタンプに記録されているため、APサーバ254は参照時に最新のデータを間違いなく特定することができる。

　同様に、新規登録時のユーザデータＸ（住所：東京都江東区…／電話番号：03-5606…）について、住所と電話番号を変更する必要性が生じた場合、APサーバ254は、同一のユーザID、氏名、メールアドレスを備え、住所を「東京都三鷹市…」に、電話番号を「0422-45…」に変更したユーザデータＸ'を新たに生成してDBサーバ252に送信し、ユーザテーブル256に追加登録させる。

　また、ユーザの退会によって特定のユーザデータを削除する必要性が生じた場合、図２２(b)に示すように、APサーバ254はその都度、対象となるユーザデータのユーザIDを備えたユーザ取消データＡ～ＣをDBサーバ252に送信し、ユーザ取消テーブル258に登録させることで対応する。

　図示の通り、ユーザデータについて実質的（論理的）な更新や削除を行った後でも、元のユーザデータ自体はそのままユーザテーブル256に残されているため、後でユーザの旧姓や旧住所を参照する必要性が生じた場合や、退会ユーザにアクセスする必要性が生じた場合でも、他の記録を用いてデータの復旧を行うことなく、APサーバ254は即座に検索や集計等を実行することができる。

　例えば、「海野花子」の旧姓を調べる必要性が生じた場合、APサーバ254はユーザデータＹ'のユーザIDと合致するユーザデータの中で、タイムスタンプに記録された日時が古いユーザデータＹを抽出することにより、旧姓が「斉藤」であったことを即座に導くことができる。

　また、退会したユーザに対して新しいサービスの告知を行う必要性が生じた場合、APサーバ254はユーザ取消テーブル258に登録されたユーザIDに係るユーザデータをユーザテーブル256から抽出し、各ユーザデータのメールアドレスに宛てて販促メールを送信することができる。

　図２３は、この発明に係る口座データ管理システム310の全体構成を示すものであり、APサーバ312と、入金管理用DBサーバ314と、口座管理用DBサーバ316と、出金管理用DBサーバサーバ318を備えている。

　APサーバ312には、Webサーバ320を介してPC等よりなる複数のクライアント端末322が接続されている。
　また、APサーバ312には、ATMサーバ324を介して複数のATM端末326が接続されている。
　図示は省略したが、APサーバ312は、ロードバランサを介した多重化により、負荷分散が図られている。

　入金管理用DBサーバ314には、少なくとも入金テーブル330と、入金／送金テーブル332と、送金受付テーブル334が設けられている。
　入金テーブル330には、入金ID、口座番号、金額等のデータ項目を備えたレコードが格納されている。
　また、入金／送金テーブル332には、入金ID、送金ID等のデータ項目を備えたレコードが格納されている。
　送金受付テーブル334には、送金ID等のデータ項目を備えたレコードが格納されている。

　口座管理用DBサーバ316には、少なくとも口座テーブル336が設けられている。
　この口座テーブル336には、口座番号、暗証番号、預金種別、口座名義等のデータ項目を備えたレコードが格納されている。

　出金管理用DBサーバ318には、少なくとも出金テーブル338と、出金／送金テーブル340と、送金テーブル342と、送金完了テーブル344が設けられている。
　出金テーブル338には、出金ID、口座番号、金額等のデータ項目を備えたレコードが格納されている。
　また、出金／送金テーブル340には、出金ID、送金ID等のデータ項目を備えたレコードが格納されている。
　送金テーブル342には、送金ID等のデータ項目を備えたレコードが格納されている。
　送金完了テーブル344には、送金ID等のデータ項目を備えたレコードが格納されている。

　入金管理用DBサーバ314としては、同じテーブル（入金テーブル330、入金／送金テーブル332、送金受付テーブル334）を備えた複数のDBサーバ314', 314"…が設けられており、各DBサーバ314に対してはAPサーバ312から同時に同一データが送信され、各テーブルへの追加登録が重複実行される。
　また、出金管理用DBサーバ318としても、同じテーブル（出金テーブル338、出金／送金テーブル340、送金テーブル342、送金完了テーブル344）を備えた複数のDBサーバ318', 318"…が用意されており、各DBサーバ318に対してはAPサーバ12から同時に同一データが送信され、各テーブルへの追加登録が重複実行される。

　このように、それぞれ同じデータを格納した入金管理用DBサーバ314と出金管理用DBサーバ318が複数用意されているため、APサーバ312はデータの参照時には何れのDBサーバからでも自由にデータを読み出すことが可能となり、データ参照処理の効率化が図れる。
　また、同じ内容を備えた一部のDBサーバを遠隔地に配置することにより、地震等の大規模災害に備えることも可能となる。

　さらに、入金管理用DBサーバ314と出金管理用DBサーバ318には、データの追加と参照のみが許容され、データの更新や削除が禁止されるという制約が予め設定されている。

　すなわち、一般的なDBサーバのようにデータの更新や削除を認めるとなると、一部のDBサーバに障害が発生した場合に、そのデータを復旧させるためには当該DBサーバが保持している更新ログに基づき、一定の時点からデータの追加や削除、更新を順番に再現する必要があり、これに多大な時間を要するのみならず、更新ログを確実に保存する仕組みをDBサーバ側に設ける必要性も生じる。

　これに対し、データの登録に関しては「追加」のみが許容されるのであれば、他の正常に動作しているDBサーバに登録されたデータと比較し、その差分を単純にコピーするだけで追い付くことができるため、更新ログの保存が不要となり、復旧までの時間も大幅に短縮可能となる。

　また、このようにデータの復旧が容易であるため、複数のDBサーバに同一データを重複格納するに際し、「２相コミット」と称するDBサーバ間での面倒な調停方式を踏襲する必要がなくなり、各DBサーバに対して単純に同一データの追加登録を依頼し、それぞれから完了通知が返ってきた時点で当該データを読み取り可能とすることができる（いわゆるオートコミットの実現）。

　銀行のユーザは、ATM端末326やクライアント端末322を操作することにより、自己の口座に現金を預金したり、自己の口座から現金を引き出したりすることができる。
　例えば、ユーザがATM端末326のディスプレイに表示されたサービスメニューから「預け入れ」を選択した後、キャッシュカードを挿入し、口座の暗証番号を入力すると、ATMサーバ324経由でAPサーバ312に口座番号と暗証番号が送信される。
　これを受けたAPサーバ312は、口座管理用DBサーバ316の口座テーブル336を参照し、該当の口座番号及び暗証番号の正当性をチェックする。

　つぎに、ユーザがATM端末326に現金を投入すると、ATM端末326からAPサーバ312に入金額が送信される。
　これを受けたAPサーバ312は、入金データ（入金ID、口座番号、金額等）を入金管理用DBサーバ314に送信する。
　入金管理用DBサーバ314は、この入金データを入金テーブル330に追加登録する。

　また、上記のサービスメニューからユーザが「引き出し」を選択し、金額の指定を行うと、ATMサーバ324経由でAPサーバ312に引き出し金額が送信される。

　これを受けたAPサーバ312は、まず当該口座の残高を算出する（残高の算出方法については後述）。
　そして、残高が引き出し金額を上回っている場合には、現金払い出しの指示データをATM端末326に送信すると共に、対応の出金データ（出金ID、口座番号、金額等）を生成し、出金管理用DBサーバ318に送信する。
　出金管理用DBサーバ318は、この出金データを出金テーブル338に追加登録する。

　ユーザは、自宅や職場に置かれたクライアント端末322からWebサーバ320経由でAPサーバ312にアクセスし、電子マネーカードを用いた預け入れや引き出し（チャージ）を行うこともできる。

　つぎに、図２４のフローチャートに従い、このシステム310を用いた口座間での送金方法について説明する。
　まず、ユーザがATM端末326のディスプレイに表示されたサービスメニューから「振り込み」を選択した後、金額の指定、振込先口座番号の指定を行うと、ATMサーバ324経由でAPサーバ312に送金依頼データが送信される。この送信依頼データには、ユーザの口座番号、振込先の口座番号及び金額が含まれている。

　これを受けたAPサーバ312は（Ｓ310）、ユニークな送金ID及び出金IDを生成すると共に、送金データ（送金ID等）、出金データ（出金ID、ユーザの口座番号、金額等）、出金／送金データ（出金ID、送金ID等）を生成し、これらを出金管理用DBサーバ318に送信して、送金テーブル342、出金テーブル338、出金／送金テーブル340への登録を依頼する（Ｓ312）。

　これを受けた出金管理用DBサーバ318では、送金テーブル342、出金テーブル338、出金／送金テーブル340に対して、送金データ、出金データ、出金／送金データが、一つのトランザクションとして一括して追加される。

　出金管理用DBサーバ318から各テーブルに対する登録完了通知を受け取ったAPサーバ312は（Ｓ314）、ATMサーバ324経由でATM端末326に送金完了を通知する（Ｓ316）。

　つぎにAPサーバ312は、ユニークな入金IDを生成した上で、送金受付データ（送金ID等）、入金データ（入金ID、振込先の口座番号、金額等）、入金／送金データ（入金ID、送金ID等）を生成し、これらを入金管理用DBサーバ314に送信して、送金受付テーブル334、入金テーブル330、入金／送金テーブル332への登録を依頼する（Ｓ318）。

　これを受けた入金管理用DBサーバ314では、送金受付テーブル334、入金テーブル330、入金／送金テーブル332に対して、送金受付データ、入金データ、入金／送金データが、一つのトランザクションとして一括して追加される。

　入金管理用DBサーバ314からの登録完了通知を受け取ったAPサーバ312は（Ｓ320）、送金完了データ（送金ID等）を出金管理用DBサーバ318に送信し、送金完了テーブルへの登録を依頼する（Ｓ322）。

　この送金完了テーブルに送金IDが登録された時点で、一連の送金処理が無事に完了したこととなるため、APサーバ312は定期的に送金テーブル342と送金完了テーブル344をチェックし、送金テーブル342に送金IDが登録されていない送金処理が存在する場合、入金データ、入金／送金データ、送金受付データを入金管理用DBサーバ314に再送する処理をバックグランドで実行する。

　何らかの原因によって最初の依頼が到達していなかった場合、入金管理用DBサーバ314は再送された登録依頼に基づき、改めて各データの一括追加を完了させた後、登録完了通知をAPサーバ312に送信する。
　入金管理用DBサーバ314からの登録完了通知を受け取ったAPサーバ312は、送金完了データを出金管理用DBサーバ318に送信し、送金完了テーブルへの登録を依頼する。

　これに対し、最初の依頼に基づいて各データの追加登録が完了しており、ただ通信障害等によって登録完了通知がAPサーバ312に届いていなかったような場合、入金管理用DBサーバ314は２回目以降の登録依頼に基づいてデータを重複登録することはせずに、登録完了通知を再送する。

　これは、同一IDを備えたデータの重複登録を自動的に排除するDBサーバ本来の機能に基づいて実現される。
　すなわち、入金データ及び入金／送金データのプライマリキーである「入金ID」としては、入金データの再送毎に新規のIDが払い出されることになるが、送金受付データのプライマリキーには当初の「送金ID」が充填されているため、この送金IDをチェックすることでDBサーバはデータの重複登録を回避することが可能となる。

　つぎに、図２５のフローチャートに従い、このシステム310を用いた口座の残高照会の手順について説明する。
　まず、ユーザがATM端末326のディスプレイに表示されたサービスメニューから「残高照会」を選択すると、ATMサーバ324経由でAPサーバ312に口座番号を伴う残高照会依頼が送信される。

　これを受けたAPサーバ312は（Ｓ330）、上記口座番号を出金管理用DBサーバ318に送信し、当該口座番号に関連付けられた出金データの抽出を依頼する（Ｓ332）。
　そして、出金管理用DBサーバ318から該当の出金データが送信されると、APサーバ312は、各出金データの金額を加算し、その合計金額を求める（Ｓ334）。

　つぎにAPサーバ312は、上記口座番号を入金管理用DBサーバ314に送信し、当該口座番号に関連付けられた入金データの抽出を依頼する（Ｓ336）。
　そして、入金管理用DBサーバ314から該当の入金データが送信されると、APサーバ312は各入金データの金額を加算し、その合計金額を求める（Ｓ338）。

　つぎにAPサーバ312は、入金データの上記合計金額から出金データの上記合計金額を減算することにより、現時点における残高を導出する（Ｓ340）。
　この残高データは、ATMサーバ324を経由してATM端末326に送信され（Ｓ342）、ディスプレイに表示される。

　上記においては、ATM端末326上でユーザが残高照会を選択した場合について説明したが、引き出しや振り込みの前処理として口座の残高を確認する場合であっても、APサーバ312は同様の処理手順によって口座の残高を算出する。

　このように、口座の残高を管理する専用のテーブルをDBサーバ側に設けることなく、必要に応じて計算によって算出する方式を採用することにより、送金という口座間を跨る処理を行う際に、送金元口座からの出金処理と、送金先口座への入金処理とを切り離すことが可能となる。

　すなわち、従来のように残高テーブルを設けて残高の管理を行うとなると、送金処理に際し送金元口座からの出金と送金先口座への入金を同時に行い、その結果を両者の残高に反映させる必要が生じ、複数のDBサーバ間におけるタイミングの調整（２相コミット）が不可欠となる。
　また、万が一何れか一方の処理が失敗した場合には、各テーブルの状態を元に戻す処理（ロールバック）が必要となる。

　もちろん、残高確認の必要性が生じる都度、計算によって残高を算出するとなると、APサーバ312側の負荷が増大することは否めないが、上記のようにロードバランサを介してAPサーバ312を多重化したり、マルチコア化したサーバコンピュータでAPサーバ312を構成したりすることにより、十分に対応可能となる。仮にハードウェアの増強可能な範囲を超えてデータが発生する場合は、前日までの合算値をAPサーバ上にスナップショットとして保持する。スナップショットを日々更新する運用が生じるが、不変である過去の明細行を繰り返し合算する計算負荷を減らす効果がある。当日に生じたデータと前日までのスナップショットの合算により、明細行の履歴件数に依存しない残高確認の応答速度の維持が可能となる。

　ところで、多数のAPサーバやDBサーバを用い、地球規模で分散処理を行うシステムで、情報の一貫性をデータの書き込み時に担保し、読み取り時の一貫性を書き込み時の一貫性に依存させる方式だと、各サーバの設置されたタイムゾーンの相違に基づく時差や、サーバ毎の時計の狂い、あるいは通信環境の差異等により、タイムスタンプの時刻に誤差が生じるため、以下の参考文献１に示すように、これまでは原子時計やGPSを用いた大掛かりで厳密な時刻同期の仕組みを設ける必要があった。
［参考文献１］グーグル「Spanner」：地球大のリアルタイム・データベース
インターネットURL：http://wired.jp/2012/11/28/google-spanner-time/
　検索日：２０１６年１０月２８日

　これに対し、上記の口座データ管理システム310の場合には、APサーバ312が送金関連データ（送金データ、出金データ、出金／送金データ）の登録完了通知を出金管理用DBサーバ318から受け取った場合にのみ、対応の入金関連データ（送金受付データ、入金データ、入金／送金データ）がAPサーバ312から入金管理用DBサーバ314に送信される。そして、入金管理用DBサーバ314から登録完了通知が届き、出金管理用DBサーバ318の送金完了テーブル344に送金完了データが登録されるまで、APサーバ312から入金管理用DBサーバ314に対して入金関連データが何度も送信される仕組みを備えている。
　すなわち、送金関連データの登録と入金関連データの登録の順序性が、APサーバ312によって担保される仕組みを備えている。

　このため、入金テーブル330や出金テーブル338に様々なタイムゾーンに属する様々な条件下のAPサーバ312から送信されたデータが混在していても、APサーバ312は口座の残高集計時に各データのタイムスタンプを参照する必要がなく、現存する入金データの合計金額から現存する出金データの合計金額を減算することで、現時点における残高をシンプルに導くことができる。
　これはつまり、情報の一貫性の観点で言うと、書き込み時の一貫性に依拠しないシステム構成にして、かつ、読み取り時の一貫性を書き込み時の一貫性とは独立させることで、この口座データ管理システム310においては、各サーバの時計を地球規模で同期させる大掛かりな仕組みが不要となることを意味している。

　また、このシステム310の場合、上記のように入金管理用DBサーバ314及び出金管理用DBサーバ318に格納されるテーブルには、レコードの削除及び更新が禁止される制約が課せられており、単にレコードの追加と参照のみが許可される仕組みであるため、DBサーバ側の処理も効率化される利点がある。

　このシステム310によれば、送金処理において、出金側データの登録処理と入金側データの登録処理との間に若干のタイムラグが生じることは避けられないが、取引の実情を考慮すれば問題にならないレベルといえる。
　また、送金完了テーブル344に送金IDが登録されるまで、APサーバ312から入金管理用DBサーバ314に対して入金データ、入金／送金データ、送金受付データが再送される仕組みを備えているため、複数の入金管理用DBサーバ314…中の少なくとも１台と、複数の出金管理用DBサーバ318…中の少なくとも１台が稼働している限りにおいて結果的にデータの整合性が担保される利点を有している。

　また、データ管理機能を入金管理用DBサーバ314と出金管理用DBサーバ318に二分した結果、分散処理による効率化が図れる。
　しかも、入金管理用DBサーバ314と出金管理用DBサーバ318を、それぞれ同一のテーブル、同一のデータを備えた複数のDBサーバによって多重化することにより、APサーバ312は複数のDBサーバから同時並行的にデータの抽出を行うことができ、さらなる処理の効率化が図れる。
　なお、サーバ間で時刻同期がされていることを前提とするシステム構成を採用していると、この多重化には、時刻同期システムの構成の見直しなどが必要となるが、本システムは、サーバ間で時刻同期がされていることを前提としていないので、その分、多重化を容易に行うことができる。

　上記においては、銀行の預金口座に係るデータ管理にこのシステム310を適用した例を示したが、この発明はこれに限定されるものではない。
　例えば、ユーザのポイントを管理する口座のデータ管理にこのシステム310を適用することが考えられる。
　この場合、「入金」は「ポイント追加」と、「出金」は「ポイント利用（適用）」と、「送金」は「ポイント譲渡」と、「残高」は「ポイント残高」と、「金額」は「ポイント数」と、「口座番号」は「アカウント」などと読み替えればよい。

この発明に係るデータ管理システムの全体構成図である。 各DBサーバに格納されるテーブルの一例を示す図である。 第１のAPサーバ及び第２のAPサーバの内部構成を示すブロック図である。 人工キーの発行手順を示すフローチャートである。 人工キー管理テーブル等の構造を示す図である。 このシステムを商品のオンライン通販業務に応用した場合の処理手順を示すフローチャートである。 注文明細データ（子データ）と注文データ（親データ）の具体例を示す図である。 複数の注文明細データを複数のDBサーバに登録する様子を示す模式図である。 対応する親データの有無によって子データの有効／無効が判定される様子を示す模式図である。 各DBサーバに格納されるテーブルの他の具体例を示す図である。 このシステムをユーザの属性データの管理業務に応用した場合の処理手順を示すフローチャートである。 ユーザの各種属性データ（子データ）とユーザデータ（親データ）の具体例を示す図である。 更新管理テーブルの具体例と、更新属性データ及び更新管理データの具体例を示す図である。 一般的なトランザクションの構成データを例示する図である。 第１のデータ管理システムの全体構成図である。 DBサーバに格納されるテーブルの一例を示す図である。 第２のAPサーバの処理内容を示すフローチャートである。 第２のAPサーバの処理内容を示すデータ構造図である。 複数のDBサーバを設置した例を示す図である。 第２のデータ管理システムの全体構成図である。 DBサーバに格納されるテーブルの一例を示す図である。 ユーザデータの実質的な更新方法及び実質的な削除方法を示す図である。 口座データ管理システムの全体構成を示す模式図である。 口座データ管理システムにおける送金処理の手順を示すフローチャートである。 口座データ管理システムにおける残高照会処理の手順を示すフローチャートである。

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　　注文明細取消テーブル
46　　人工キー管理テーブル
47　　人工キーの下一桁管理テーブル
48　　APサーバ管理テーブル
49　　データセンター管理テーブル
61　　第１の注文明細データ
62　　第２の注文明細データ
63　　第３の注文明細データ
64　　注文データ
70　　ユーザテーブル
71　　ユーザ取消テーブル
72　　氏名テーブル
73　　氏名取消テーブル
74　　住所テーブル
75　　住所取消テーブル
76　　電話番号テーブル
77　　電話番号取消テーブル
78　　Ｅメールテーブル
79　　Ｅメール取消テーブル
80　　氏名データ
81　　住所データ
82　　電話番号データ
83　　Ｅメールデータ
84　　ユーザデータ
85　　更新管理テーブル
86　　更新住所データ
87　　更新電話番号データ
88　　更新管理データ
210　　第１のデータ管理システム
212　　DBサーバ（第１のDBサーバ）
212'　　第２のDBサーバ
214　　第１のAPサーバ
216　　第２のAPサーバ
218　　第３のAPサーバ
220　　仕入テーブル
222　　仕入取消テーブル
224　　販売価格テーブル
226　　販売価格取消テーブル
228　　仕入担当スタッフ
230　　クライアント端末
232　　一般ユーザ
250　　第２のデータ管理システム
252　　DBサーバ
254　　APサーバ
256　　ユーザテーブル
258　　ユーザ取消テーブル
260　　ユーザ
262　　クライアント端末
310　　口座データ管理システム
312　　APサーバ
314　　入金管理用DBサーバ
316　　口座管理用DBサーバ
318　　出金管理用DBサーバサーバ
320　　Webサーバ
322　　クライアント端末
324　　ATMサーバ
326　　ATM端末
330　　入金テーブル
332　　入金／送金テーブル
334　　送金受付テーブル
336　　口座テーブル
338　　出金テーブル
340　　出金／送金テーブル
342　　送金テーブル
344　　送金完了テーブル

Claims (9)

1. 　APサーバとDBサーバを備えたデータ管理システムであって、
   　上記APサーバは、業務処理の結果生じた業務データを上記DBサーバに送信し、対応のテーブルへの登録を依頼する機能を備え、
   　上記業務データは、相互に関連性を有する親データと、複数の子データとの組合せからなり、
   　上記の各子データは、子データ固有のIDの他に、上記親データのIDを外部キーとして備えており、
   　上記業務データの登録に際し、上記APサーバは、まず上記DBサーバに対して各子データの登録を依頼し、上記DBサーバから全ての子データに係る登録完了通知が届いた時点で親データの登録を上記DBサーバに依頼し、一定の時間内に何れかの子データの登録完了通知が届かない場合には、親データの登録を中止し、
   　また登録済みの業務データの参照に際し、上記APサーバは、関連する親データの登録のある子データのみを参照の対象とし、関連する親データの登録のない子データについては参照の対象外とすることを特徴とするデータ管理システム。
2. 　複数のDBサーバを備えており、
   　上記親データの登録に際し、上記APサーバは、上記子データの登録を依頼したDBサーバとは別個のDBサーバに対して登録を依頼することを特徴とする請求項１に記載のデータ管理システム。
3. 　同一のデータを格納する共通のテーブルをそれぞれ備えた複数のDBサーバを備えており、
   　上記業務データの登録に際し、上記APサーバは、まず上記の各DBサーバに各子データの登録を依頼し、
   　全ての子データについて、何れかのDBサーバから登録完了通知が届いた時点で親データの登録を上記の各DBサーバに依頼し、一定の時間内に何れかの子データの登録完了通知が何れのDBサーバからも届かない場合には、親データの登録を中止することを特徴とする請求項１に記載のデータ管理システム。
4. 　上記DBサーバのテーブルには、レコードの参照及び追加のみが許容され、削除及び更新が禁止される制約が設けられていることを特徴とする請求項３に記載のデータ管理システム。
5. 　上記APサーバは、既存の業務データを削除する必要がある場合に、取消対象となる業務データのIDをセットするデータ項目を備えたデータ取消用データを生成すると共に、
   　このデータ取消用データを各DBサーバに設けられた取消専用のテーブルに追加登録させることにより、既存の業務データを実質的に無効化することを特徴とする請求項４に記載のデータ管理システム。
6. 　上記の各業務データには、それぞれ業務処理時のタイムスタンプが刻印されており、
   　上記APサーバは、既存の業務データを更新する必要がある場合に、当該業務データと同じIDを有すると共に、修正後の値及び修正時のタイムスタンプを備えた更新用業務データを新たに生成し、
   　この更新用業務データを上記の各DBサーバに設けられた該当のテーブルに追加登録させることにより、既存の業務データを実質的に更新することを特徴とする請求項４または５に記載のデータ管理システム。
7. 　上記APサーバは、相互に関連性を有する既存の複数の子データを同時に更新する必要がある場合に、各子データの固有のIDと、相互に共通する親データのIDと、それぞれの修正後の値と、相互に共通する修正時のタイムスタンプを備えた更新用子データを新たに生成すると共に、上記親データのIDと、上記タイムスタンプを備えた更新管理データを生成し、
   　まず上記の各DBサーバに対して各更新用子データの登録を依頼し、全ての更新用子データについて、何れかのDBサーバから登録完了通知が届いた時点で更新管理データの登録を上記の各DBサーバに依頼し、一定の時間内に何れかの子データの登録完了通知が何れのDBサーバからも届かない場合には、更新管理データの登録を中止し、
   　また更新用子データの参照に際し、各更新用子データに係る親データのID及びタイムスタンプを備えた更新管理データの登録のある更新用子データのみを参照の対象とし、上記更新管理データの登録のない更新用子データについては参照の対象外とすることを特徴とする請求項６に記載のデータ管理システム。
8. 　APサーバとDBサーバを備えたデータ管理システムであって、
   　上記DBサーバのテーブルには、レコードの参照及び追加のみが許容され、削除及び更新が禁止される制約が設けられており、
   　上記APサーバは、業務処理の結果生じた業務データにデータ生成時刻をタイムスタンプとして追加した上で、上記DBサーバに送信して対応のテーブルへの登録を依頼する機能と、
   　既存の業務データを削除する必要がある場合に、取消対象となる業務データのIDをセットするデータ項目を備えたデータ取消用データを生成すると共に、これを上記DBサーバに設けられた取消専用のテーブルに追加登録させることにより、既存の業務データを実質的に無効化する機能と、
   　既存の業務データを更新する必要がある場合に、当該業務データと同じIDを有すると共に、修正後の値及び修正時のタイムスタンプを備えた更新用業務データを新たに生成すると共に、この更新用業務データを上記DBサーバに設けられた該当のテーブルに追加登録させることにより、既存の業務データを実質的に更新する機能と、
   　過去の特定時点における業務データを参照する必要がある場合に、上記テーブルに格納された各業務データのタイムスタンプに記録された時刻に基づいて該当の業務データを抽出する機能と、
   　を備えたことを特徴とするデータ管理システム。
9. 　上記APサーバは、上記テーブルに格納された業務データの中で、特定の期間内に生成された業務データに基づいて所定のバッチ処理を実行する機能を備え、
   　このバッチ処理に際し、上記テーブルに格納された各業務データのタイムスタンプに記録された時刻に基づいて、バッチ処理の対象となる業務データと、対象外の業務データとを識別することを特徴とする請求項８に記載のデータ管理システム。

Images