データベース管理装置及び情報配信システム及びデータベース管理方法及びプログラム
【課題】データベース内で依存関係のあるデータが更新された場合、その更新後のデータをいつでも確実に整合性の取れたデータとして提供する。
【解決手段】データベース１０２は、データごとに、データの内容が変更される度に割り当てられる世代番号と、内容が変更されたデータとを対応付けて記憶する。操作受付部１１１は、データベース１０２に記憶された複数のデータの内容を変更する操作を受け付ける。イベント番号付加部１１２は、操作に対してイベント番号を割り当てる。世代管理テーブルは、イベント番号と内容が変更された複数のデータのデータ識別子と新たに割り当てられた複数の世代番号とを対応付けて記憶する。データセット検索部１１５は、イベント番号が入力されると、対応する複数のデータ識別子と複数の世代番号とを世代管理テーブルから取得し、対応するデータの内容をデータベース１０２から取得する。
【解決手段】データベース１０２は、データごとに、データの内容が変更される度に割り当てられる世代番号と、内容が変更されたデータとを対応付けて記憶する。操作受付部１１１は、データベース１０２に記憶された複数のデータの内容を変更する操作を受け付ける。イベント番号付加部１１２は、操作に対してイベント番号を割り当てる。世代管理テーブルは、イベント番号と内容が変更された複数のデータのデータ識別子と新たに割り当てられた複数の世代番号とを対応付けて記憶する。データセット検索部１１５は、イベント番号が入力されると、対応する複数のデータ識別子と複数の世代番号とを世代管理テーブルから取得し、対応するデータの内容をデータベース１０２から取得する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データベース管理装置及び情報配信システム及びデータベース管理方法及びプログラムに関するものである。
【背景技術】
【０００２】
昨今の社会では、情報配信技術及び情報共有技術が必須となっており、データの集中化とともに、登録されたデータを複数のシステムへリアルタイムに配信を行うことが求められている。具体的には、マスタとなるデータベースに対して、クライアントからデータベースの登録を行った際に、データベースに登録された内容を複数の配信先へ即時に配信することが要求されている。
【０００３】
従来、登録された情報に番号を割り当て、その番号の情報が、正しく各配信先へ配信されているかを確認し、正しく配信されていなければ再配信を行う情報配信システムがある（例えば、特許文献１参照）。また、データベースに記憶されたデータのうち、更新がなされた更新データに対して、同報ネットワークを介して送信を行うのに必要な資源を割り当て、資源の割当量に従って、更新データそのもの又は更新がなされたことを示す更新報知情報を、同報ネットワークを介して送信する情報配信システムがある（例えば、特許文献２参照）。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００５−１５７６４７号公報
【特許文献２】特開平１０−３０３９８３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
データベースに登録される情報１件１件の間に依存関係が存在する場合を考える。なお、ここでいう依存関係のあるデータとは、「（１）個人１を登録」、「（２）組織１を登録」、「（３）配属１（個人１を組織１に配属）を登録」といったデータを投入する順序に制約があるような、１件のデータベース操作だけでは意味をなさない一連のデータのことを指す。
【０００６】
従来の情報配信システム（配信技術）では、依存関係のあるデータを登録し、各配信先へ配信している途中で、配信対象のデータに対し再度更新を実行した場合、配信先へ送信されるデータの整合性が保障されない。
【０００７】
例えば、Ａ、Ｂ、Ｃという各データ間に依存関係があるデータをデータベースに登録し、各配信先へ配信する場合を考える。このとき、全ての配信先へＡ、Ｂ、Ｃの配信が完了する前に、Ａを再度更新した場合、一部配信先へは、更新前のＡが配信されず、配信後のデータの整合性が取れなくなってしまう。
【０００８】
この問題への単純な対処方法としては、データベースの更新後、各配信先へ配信が行われるまではデータベースへの更新を受け付けない（データベースをロックする）手段が考えられる。しかし、この方法では配信情報量や配信先が増えるに従ってデータベースがロックされる時間が長くなってしまうため、リアルタイム性が損なわれてしまう。
【０００９】
また、複数の配信先のうち、一部のみが配信失敗となってしまった場合、単純に更新内容に番号を割り当てただけでは、どの配信先への配信を行えばいいのか特定できない。
【００１０】
本発明は、例えば、データベース内で依存関係のあるデータが更新された場合、その更新後のデータをいつでも確実に整合性の取れたデータとして提供することを目的とする。また、例えば、複数のクライアントからのデータベース操作要求の受付と、各配信先への情報配信をデータベースにロックをかけずに並行して実行し、かつ、依存関係のあるデータ群を投入した場合でも、データベースの世代管理を行うことにより、整合性を保ったまま各配信先への配信を行えるように、データの保障性の高い整合性の取れたリアルタイム情報配信の実現を目的とする。
【課題を解決するための手段】
【００１１】
本発明の一の態様に係るデータベース管理装置は、
過去に内容が変更されたデータ群を記憶するデータベースであり、データ群に含まれるデータごとに、データの内容が変更される度に割り当てられる世代番号と、変更された内容とを対応付けて記憶するデータベースを管理するデータベース管理装置であって、
前記データベースに記憶されたデータ群に含まれる複数のデータの内容を変更する操作を入力装置によりイベントとして受け付ける操作受付部と、
前記操作受付部で受け付けられたイベントに対して一意のイベント識別子を処理装置により割り当てるイベント識別子割当部と、
前記操作受付部で受け付けられたイベントに基づいて前記データベースに記憶された複数のデータの内容を変更し、内容を変更したデータごとに、新たな世代番号を処理装置により割り当てて前記データベースに記憶させるデータ操作部と、
前記イベント識別子割当部で割り当てられたイベント識別子と、前記データ操作部で内容が変更された複数のデータを各々識別する複数のデータ識別子と、前記データ操作部で当該複数のデータに各々割り当てられた複数の世代番号とを対応付けて記憶装置により記憶する世代管理部と、
前記イベント識別子割当部で割り当てられたイベント識別子を出力装置により出力するイベント通知部と、
前記イベント通知部から出力されたイベント識別子が入力されると、入力されたイベント識別子に対応する複数のデータ識別子と複数の世代番号とを前記世代管理部から取得し、前記データベースを検索して、取得した複数のデータ識別子の各々に対応するデータの内容のうち、取得した複数の世代番号の各々に対応する内容を取得するデータセット検索部とを有する。
【発明の効果】
【００１２】
本発明の一の態様によれば、データベース内で依存関係のあるデータが更新された場合、その更新後のデータをいつでも確実に整合性の取れたデータとして提供することが可能となる。
【図面の簡単な説明】
【００１３】
【図１】実施の形態１に係る情報配信システムの構成を示すブロック図。
【図２】実施の形態１に係る情報配信システムのハードウェア構成の一例を示す図。
【図３】実施の形態１に係る情報配信システムの動作を示すフローチャート。
【図４】実施の形態１に係るクライアントシステムから要求される操作内容、イベント種別対応表の例を示す図。
【図５】実施の形態１に係る操作受付部からイベント番号付加部へ流れるデータ、イベント番号付加部からデータ操作部へ流れるデータの例を示す図。
【図６】実施の形態１に係るデータベースで保持される配属情報のテーブルの例を示す図。
【図７】実施の形態１に係る世代管理テーブル、イベント番号付加部からイベント通知部へ通知されるデータの例を示す図。
【図８】実施の形態１に係る配信先情報管理表、イベント受信部から配信管理部へ流れるデータの例を示す図。
【図９】実施の形態１に係る配信履歴テーブル、整合性検索要求部からデータ送信部へ流れるデータ、配信情報の例を示す図。
【図１０】実施の形態１に係る情報配信システムによる再配信の動作を示すフローチャート。
【図１１】実施の形態２に係る情報配信システムの構成を示すブロック図。
【図１２】実施の形態２に係るイベント種別対応表、配信先情報管理表の例を示す図。
【図１３】実施の形態３に係る情報配信システムの構成を示すブロック図。
【図１４】実施の形態３に係る情報配信システムの動作を示すフローチャート。
【図１５】実施の形態４に係る情報配信システムの構成を示すブロック図。
【図１６】実施の形態４に係る情報配信システムによる再配信の動作を示すフローチャート。
【発明を実施するための形態】
【００１４】
以下、本発明の実施の形態について、図を用いて説明する。
【００１５】
実施の形態１．
図１は、本実施の形態に係る情報配信システム１００の構成を示すブロック図である。
【００１６】
図１において、情報配信システム１００は、データベース１０２、データベース管理装置１１０、イベント制御装置１２０を備える。情報配信システム１００は、クライアントシステム１０１から受け付けた依存関係のあるデータの操作要求に対し、データベース管理装置１１０によりデータベース１０２の操作を行った後に、イベント制御装置１２０により操作結果を各配信先システム１０３へと配信するシステムである。
【００１７】
図１には示していないが、情報配信システム１００は、処理装置、記憶装置、入力装置、出力装置等のハードウェアを備える。ハードウェアは、データベース１０２や、後述するデータベース管理装置１１０及びイベント制御装置１２０の各部によって利用される。例えば、処理装置は、データや情報の演算、加工、読み取り、書き込み等を行うために利用される。記憶装置は、そのデータや情報を記憶するために利用される。また、入力装置は、そのデータや情報を入力するために、出力装置は、そのデータや情報を出力するために利用される。
【００１８】
クライアントシステム１０１は、データベース１０２の登録・更新等の操作を要求するシステムである。情報配信システム１００に接続するクライアントシステム１０１の数が複数あってもよい。
【００１９】
データベース１０２は、マスタとなるデータベースである。データベース１０２の形式としては関係データベース、階層型データベース等、任意の形式を使用してよい。ここでは、便宜上、関係データベースを使用しているものとする。
【００２０】
配信先システム１０３は、データベース１０２で登録・更新等の操作がされた情報を受信するシステムである。配信先システム１０３の数は、必要に応じて任意の数をとる。図１では、複数の配信先システム１０３を配信先１、・・・、配信先ｎとして表している。配信先システム１０３の形態はデータベースや、受信した情報を基にメールを送信するメールサーバや、受信した情報を基にファイル構成を変更するようなシステム等である。
【００２１】
データベース管理装置１１０は、クライアントシステム１０１からの操作要求を受け付ける機能、データベース１０２へ登録、更新、削除、検索等の操作を行う機能を持つ。データベース管理装置１１０は、操作受付部１１１、イベント番号付加部１１２（イベント識別子割当部の一例）、データ操作部１１３、イベント通知部１１４、データセット検索部１１５を有する。
【００２２】
操作受付部１１１は、クライアントシステム１０１からのデータベース１０２の操作要求を受け付け、要求元のクライアントシステム１０１と操作内容によりイベント種別（例えば、依存関係のあるデータの一括登録、一括更新、一括削除）を判断する。
【００２３】
イベント番号付加部１１２は、操作受付部１１１より受信したデータに対しイベント番号（イベント識別子の一例）を付加する機能と、イベント番号とデータをデータ操作部１１３に送信する機能と、イベント通知部１１４へイベント番号とイベント種別とを含むイベント情報を送信する機能を持つ。
【００２４】
データ操作部１１３は、イベント番号付加部１１２より受信したイベント番号とデータを、データベース１０２へ投入する。
【００２５】
イベント通知部１１４は、イベント番号付加部１１２より送信されたイベント情報をイベント制御装置１２０へと送付する機能を持つ。
【００２６】
データセット検索部１１５は、イベント制御装置１２０からの要求を基にデータベース１０２の検索を行う。
【００２７】
イベント制御装置１２０は、データベース管理装置１１０からのイベント通知により、各配信先システム１０３への配信情報を取得し、配信状況を確認する機能を持つ。イベント制御装置１２０は、イベント受信部１２１、整合性検索要求部１２２（検索要求部の一例）、データ送信部１２３、配信管理部１２４を有する。
【００２８】
イベント受信部１２１は、イベント通知部１１４からのイベント情報を受け付ける機能を持つ。
【００２９】
整合性検索要求部１２２は、配信先情報管理表（イベント種別ごとに、データの配信先、配信項目、検索順序等を定めたテーブル）を基に、配信先システム１０３への情報配信内容に整合性が取れるようにデータベース１０２に対し検索要求を出す機能を有する。
【００３０】
データ送信部１２３は、検索されたデータを配信先情報管理表により指定された送信先へ送信する。
【００３１】
配信管理部１２４は、イベント受信部１２１で受け付けたイベント番号を登録する機能と、登録されたイベント番号の配信状況を監視する機能を持つ。
【００３２】
図２は、情報配信システム１００のハードウェア構成の一例を示す図である。
【００３３】
図２において、情報配信システム１００は、コンピュータであり、ＬＣＤ９０１（Ｌｉｑｕｉｄ・Ｃｒｙｓｔａｌ・Ｄｉｓｐｌａｙ）、キーボード９０２（Ｋ／Ｂ）、マウス９０３、ＦＤＤ９０４（Ｆｌｅｘｉｂｌｅ・Ｄｉｓｋ・Ｄｒｉｖｅ）、ＣＤＤ９０５（Ｃｏｍｐａｃｔ・Ｄｉｓｃ・Ｄｒｉｖｅ）、プリンタ９０６といったハードウェアデバイスを備えている。これらのハードウェアデバイスはケーブルや信号線で接続されている。ＬＣＤ９０１の代わりに、ＣＲＴ（Ｃａｔｈｏｄｅ・Ｒａｙ・Ｔｕｂｅ）、あるいは、その他の表示装置が用いられてもよい。マウス９０３の代わりに、タッチパネル、タッチパッド、トラックボール、ペンタブレット、あるいは、その他のポインティングデバイスが用いられてもよい。
【００３４】
なお、情報配信システム１００のうち、データベース管理装置１１０とイベント制御装置１２０とが別々のコンピュータとして実現されていても構わない。
【００３５】
情報配信システム１００は、プログラムを実行するＣＰＵ９１１（Ｃｅｎｔｒａｌ・Ｐｒｏｃｅｓｓｉｎｇ・Ｕｎｉｔ）を備えている。ＣＰＵ９１１は、処理装置の一例である。ＣＰＵ９１１は、バス９１２を介してＲＯＭ９１３（Ｒｅａｄ・Ｏｎｌｙ・Ｍｅｍｏｒｙ）、ＲＡＭ９１４（Ｒａｎｄｏｍ・Ａｃｃｅｓｓ・Ｍｅｍｏｒｙ）、通信ボード９１５、ＬＣＤ９０１、キーボード９０２、マウス９０３、ＦＤＤ９０４、ＣＤＤ９０５、プリンタ９０６、ＨＤＤ９２０（Ｈａｒｄ・Ｄｉｓｋ・Ｄｒｉｖｅ）と接続され、これらのハードウェアデバイスを制御する。ＨＤＤ９２０の代わりに、フラッシュメモリ、光ディスク装置、メモリカードリーダライタ、あるいは、その他の記録媒体が用いられてもよい。
【００３６】
ＲＡＭ９１４は、揮発性メモリの一例である。ＲＯＭ９１３、ＦＤＤ９０４、ＣＤＤ９０５、ＨＤＤ９２０は、不揮発性メモリの一例である。これらは、記憶装置の一例である。通信ボード９１５、キーボード９０２、マウス９０３、ＦＤＤ９０４、ＣＤＤ９０５は、入力装置の一例である。また、通信ボード９１５、ＬＣＤ９０１、プリンタ９０６は、出力装置の一例である。
【００３７】
通信ボード９１５は、ＬＡＮ（Ｌｏｃａｌ・Ａｒｅａ・Ｎｅｔｗｏｒｋ）等に接続されている。通信ボード９１５は、ＬＡＮに限らず、ＩＰ−ＶＰＮ（Ｉｎｔｅｒｎｅｔ・Ｐｒｏｔｏｃｏｌ・Ｖｉｒｔｕａｌ・Ｐｒｉｖａｔｅ・Ｎｅｔｗｏｒｋ）、広域ＬＡＮ、ＡＴＭ（Ａｓｙｎｃｈｒｏｎｏｕｓ・Ｔｒａｎｓｆｅｒ・Ｍｏｄｅ）ネットワークといったＷＡＮ（Ｗｉｄｅ・Ａｒｅａ・Ｎｅｔｗｏｒｋ）、あるいは、インターネットに接続されていても構わない。ＬＡＮ、ＷＡＮ、インターネットは、ネットワークの一例である。
【００３８】
ＨＤＤ９２０には、オペレーティングシステム９２１（ＯＳ）、ウィンドウシステム９２２、プログラム群９２３、ファイル群９２４が記憶されている。プログラム群９２３のプログラムは、ＣＰＵ９１１、オペレーティングシステム９２１、ウィンドウシステム９２２により実行される。プログラム群９２３には、本実施の形態の説明において「〜部」として説明する機能を実行するプログラムが含まれている。プログラムは、ＣＰＵ９１１により読み出され実行される。ファイル群９２４には、本実施の形態の説明において、「〜データ」、「〜情報」、「〜ＩＤ（識別子）」、「〜フラグ」、「〜結果」として説明するデータや情報や信号値や変数値やパラメータが、「〜ファイル」や「〜データベース」や「〜テーブル」の各項目として含まれている。「〜ファイル」や「〜データベース」や「〜テーブル」は、ＲＡＭ９１４やＨＤＤ９２０等の記録媒体に記憶される。ＲＡＭ９１４やＨＤＤ９２０等の記録媒体に記憶されたデータや情報や信号値や変数値やパラメータは、読み書き回路を介してＣＰＵ９１１によりメインメモリやキャッシュメモリに読み出され、抽出、検索、参照、比較、演算、計算、制御、出力、印刷、表示といったＣＰＵ９１１の処理（動作）に用いられる。抽出、検索、参照、比較、演算、計算、制御、出力、印刷、表示といったＣＰＵ９１１の処理中、データや情報や信号値や変数値やパラメータは、メインメモリやキャッシュメモリやバッファメモリに一時的に記憶される。
【００３９】
本実施の形態の説明において用いるブロック図やフローチャートの矢印の部分は主としてデータや信号の入出力を示す。データや信号は、ＲＡＭ９１４等のメモリ、ＦＤＤ９０４のフレキシブルディスク（ＦＤ）、ＣＤＤ９０５のコンパクトディスク（ＣＤ）、ＨＤＤ９２０の磁気ディスク、光ディスク、ＤＶＤ（Ｄｉｇｉｔａｌ・Ｖｅｒｓａｔｉｌｅ・Ｄｉｓｃ）、あるいは、その他の記録媒体に記録される。また、データや信号は、バス９１２、信号線、ケーブル、あるいは、その他の伝送媒体により伝送される。
【００４０】
本実施の形態の説明において「〜部」として説明するものは、「〜回路」、「〜装置」、「〜機器」であってもよく、また、「〜ステップ」、「〜工程」、「〜手順」、「〜処理」であってもよい。即ち、「〜部」として説明するものは、ＲＯＭ９１３に記憶されたファームウェアで実現されていても構わない。あるいは、「〜部」として説明するものは、ソフトウェアのみ、あるいは、素子、デバイス、基板、配線といったハードウェアのみで実現されていても構わない。あるいは、「〜部」として説明するものは、ソフトウェアとハードウェアとの組み合わせ、あるいは、ソフトウェアとハードウェアとファームウェアとの組み合わせで実現されていても構わない。ファームウェアとソフトウェアは、プログラムとして、フレキシブルディスク、コンパクトディスク、磁気ディスク、光ディスク、ＤＶＤ等の記録媒体に記憶される。プログラムはＣＰＵ９１１により読み出され、ＣＰＵ９１１により実行される。即ち、プログラムは、本実施の形態の説明で述べる「〜部」としてコンピュータを機能させるものである。あるいは、プログラムは、本実施の形態の説明で述べる「〜部」の手順や方法をコンピュータに実行させるものである。
【００４１】
図３は、情報配信システム１００の動作（本実施の形態に係る情報配信方法（データベース管理方法を含む））を示すフローチャートである。以下、情報配信システム１００の動作について図３を用いて説明する。
【００４２】
ここで、データベース１０２は、個人情報、組織情報、配属情報といったデータ群を記憶する。一例として、データベース１０２は、個人情報として、企業の従業員等である個人１、個人２、・・・の名前、年齢、住所、電話番号等を、個人を一意に識別する個人ＩＤ（識別子）ごとに記憶する。また、データベース１０２は、組織情報として、企業の部署等である組織１、組織２、・・・の名称、所在地、電話番号等を、組織を一意に識別する組織ＩＤごとに記憶する。また、データベース１０２は、配属情報として、個人１、個人２、・・・が組織１、組織２、・・・のいずれに配属されているかを示す配属１、配属２、・・・を記憶する。
【００４３】
また、データベース１０２は、データ群に含まれるデータごとに、データの内容が変更される度に割り当てられる世代番号と、内容が変更されたデータとを対応付けて記憶する。例えば、新たなデータがデータベース１０２に登録される際には、世代番号として世代１が割り当てられ、そのデータと対応付けてデータベース１０２に記憶される。それ以降、データが更新される度に、最後に割り当てられた世代番号を１つインクリメントした世代番号が割り当てられ、更新されたデータと対応付けてデータベース１０２に記憶される。例えば、登録後、データが初めて更新された場合、世代番号として世代２が割り当てられ、更新されたデータと対応付けてデータベース１０２に記憶される。つまり、このとき、登録時のデータと世代１との組み合わせ、及び、更新されたデータと世代２との組み合わせがデータベース１０２に記憶されることになる。なお、更新されたデータ全体ではなく、変更された内容のみと世代２との組み合わせがデータベース１０２に記憶されてもよい。この場合、ある世代のデータを取得したいときは、その世代以前のデータの変更履歴を辿ってデータを復元する必要があるが、データベース１０２に記憶するデータ量の増大を抑制することができる。
【００４４】
図４は、クライアントシステム１０１から要求される操作内容１３１、データ操作の種類（データ操作内容）やデータの種類とイベント種別の対応を示したイベント種別対応表１３２，１３２ａの例を示す図である。図５は、操作受付部１１１からイベント番号付加部１１２へ流れるデータ１３３、イベント番号付加部１１２からデータ操作部１１３へ流れるデータ１３４の例を示す図である。
【００４５】
まず、ステップＳ１０１において、クライアントシステム１０１は、データベース１０２に記憶されたデータ群に含まれる複数のデータの内容を変更する操作を行う。具体的には、クライアントシステム１０１は、データベース１０２への整合性の取れた（依存関係のある）データの操作要求をデータベース管理装置１１０の操作受付部１１１へ出す。この際、操作内容１３１（図４参照）としては、データベース１０２へのレコードの追加（新規登録）、削除、更新、検索、参照等の操作が考えられるが、本実施の形態では、複数のレコードの追加、削除、更新といった操作が対象となる。
【００４６】
一例として、クライアントシステム１０１は、配属１のレコード（配属情報）（第１のデータの一例）と、データベース１０２において配属１のレコードから参照される個人１のレコード（個人情報）及び組織１のレコード（組織情報）（いずれも第２のデータの例）とを更新する操作（例えば、個人１の年齢、組織１の名称、個人１の配属先の変更）を行う。本実施の形態は、このような参照整合性（参照制約）が要求される（即ち、依存関係にある）データの内容を変更する場合に、特に効果を奏する。なお、例えばデータベース１０２が関係データベースではなく、階層型データベースであれば、本実施の形態は、存在整合性（存在制約）が要求されるデータの内容を変更する場合に、特に効果を奏する。
【００４７】
ステップＳ１０２において、操作受付部１１１は、クライアントシステム１０１による操作を入力装置によりイベントとして受け付ける。具体的には、操作受付部１１１は、クライアントシステム１０１からの要求を受け付け、イベント種別対応表１３２（図４参照）からイベント種別を決定し、イベント番号付加部１１２へイベント種別とデータ内容等を含むデータ１３３（図５参照）を通知する。このとき、操作受付部１１１は、依頼元（クライアントシステム１０１）ごとに設定されるイベント種別対応表１３２ａ（図４参照）を利用しても構わない。そして、操作受付部１１１は、補足情報として、どのクライアントシステム１０１から依頼を受けたのかという依頼元情報や、その他の情報を付加したデータ１３３を通知しても構わない。
【００４８】
一例として、操作受付部１１１は、記憶装置に予め記憶されたイベント種別対応表１３２を参照して、個人情報、組織情報、配属情報を更新する操作に対応するイベント種別が一括更新であると判断し、この操作を１つのイベントとして受け付ける。そして、操作受付部１１１は、イベント種別として一括更新を示し、データ内容として個人１のレコード、組織１のレコード、配属１のレコードの更新内容（例えば、個人１の年齢、組織１の名称、個人１の配属先）を含むデータ１３３をイベント番号付加部１１２に渡す。
【００４９】
ステップＳ１０３において、イベント番号付加部１１２は、操作受付部１１１で受け付けられたイベントに対して一意のイベント番号を処理装置により割り当てる。具体的には、まず、イベント番号付加部１１２では、操作受付部１１１より受信したデータ１３３のまとまりに対して、共通の番号（イベント番号）を付加する。このイベント番号は、全ての操作要求に対して連番をつけることが基本であるが、図４のイベント種別対応表１３２ａの依頼元名のように、クライアントシステム１０１の種別や操作内容ごとに「クライアント１−１」、「データ削除−１」のような形式で割り当てることも可能である。イベント番号としては、番号以外にも記号や漢字等の文字も、イベント番号間で重複するものがなければ、割り当てることが可能である。共通のイベント番号を付加する対象は、データベース１０２にコミットする単位、即ちデータ間に整合性の取れている範囲とする。なお、データ１件で整合性が取れている場合（例えば、既存の個人の新たな配属先として既存の組織を指定する場合）は、１件の単位でイベント番号を付加することも可能である。次に、イベント番号付加部１１２は、イベント番号を付加したデータ１３４（図５参照）をデータ操作部１１３へ送付する。
【００５０】
一例として、イベント番号付加部１１２は、操作受付部１１１で受け付けられたイベントに対してイベント番号「１」を処理装置により割り当てる。そして、イベント番号付加部１１２は、イベント番号として「１」を示し、データ内容として個人１のレコード、組織１のレコード、配属１のレコードの更新内容（例えば、個人１の年齢、組織１の名称、個人１の配属先）を含むデータ１３４をデータ操作部１１３に渡す。
【００５１】
図６は、データベース１０２で保持される配属情報のテーブル１３５，１３５ａの例を示す図である。図７は、イベント番号と対象レコード（データ識別子の一例）と世代番号の対応を示した世代管理テーブル１３６（世代管理部の一例）、イベント番号付加部１１２からイベント通知部１１４へ通知されるデータ１３７の例を示す図である。
【００５２】
データベース１０２で保持される配属情報のテーブル１３５（図６参照）では、個人１、個人２、・・・の１件１件のユーザに対し、更新があった際に、更新履歴を世代として記録しておく。なお、配属情報の全体において１件のユーザ（１人の個人）でも更新があった場合、世代が変わったとする管理方式でテーブル１３５ａ（図６参照）を構成しても構わない。
【００５３】
ステップＳ１０４において、データ操作部１１３は、操作受付部１１１で受け付けられたイベントに基づいてデータベース１０２に記憶された複数のデータの内容を変更する。そして、データ操作部１１３は、内容を変更したデータごとに、新たな世代番号を処理装置により割り当ててデータベース１０２に記憶させる。具体的には、データ操作部１１３は、イベント番号付加部１１２から受信したデータ１３４を基に、データベース１０２に対して操作を行う。データベース１０２の操作の際は、操作内容の結果のみをデータベース１０２として登録するのではなく、更新後の情報とともに、更新前の情報の履歴を世代としてデータベース１０２に保存する。世代の管理単位は、レコード単位（図６のテーブル１３５）、テーブル単位（図６のテーブル１３５ａ）等、システムの状況に合わせ設定することが可能である。なお、ここでは、「レコード」という語を、配属情報のテーブル１３５に含まれる個人ごとのデータという意味で用いている（個人情報、組織情報についても同様である）。例えば、個人１の配属先が組織１（世代１）から組織２（世代２）に変わり、再び組織１（世代３）に戻ったことを示すデータ全体が１つの「レコード」である。また、ここで「テーブル単位」というとき、「テーブル」という語を、配属情報のテーブル１３５ａに含まれる更新時点ごとのデータという意味で用いている。例えば、個人１の配属先が組織１から組織２に変わった時点における個人１、個人２、・・・のデータ（世代２）全体が１つの「テーブル」であり、個人１の配属先が再び組織１に戻った時点における個人１、個人２、・・・のデータ（世代３）全体が１つの「テーブル」である。
【００５４】
一例として、データ操作部１１３は、データベース１０２に記憶された個人１のレコード、組織１のレコード、配属１のレコードを更新する（例えば、個人１の年齢、組織１の名称、個人１の配属先を更新する）。そして、データ操作部１１３は、更新後の個人１のレコード、更新後の組織１のレコード、更新後の配属１のレコードのそれぞれに対して、新たな世代番号を処理装置により割り当ててデータベース１０２に記憶させる（例えば、個人１の配属先が組織１になったことを示すデータを、世代３に対応付けて配属情報のテーブル１３５に記憶させる）。
【００５５】
次に、世代管理テーブル１３６（図７参照）は、イベント番号付加部１１２で割り当てられたイベント番号と、データ操作部１１３で内容が変更された複数のデータを各々識別する複数のデータ識別子と、データ操作部１１３で当該複数のデータに各々割り当てられた複数の世代番号とを対応付けて記憶装置により記憶する。具体的には、データ操作部１１３は、データそのものの登録だけでなく、世代管理テーブル１３６に、あるイベント番号の操作によって、どのレコードのどの世代を配信対象とすればよいのかを登録する。このように、世代管理テーブル１３６には、入手したイベント番号に対し、どの配信対象のどの世代のレコードを配信すべきかが記載される。
【００５６】
一例として、世代管理テーブル１３６は、イベント番号「１」と、個人１のレコードを識別するデータ識別子と、更新された個人１のレコードに割り当てられた世代２とを対応付けて記憶する。また、世代管理テーブル１３６は、イベント番号「１」と、組織１のレコードを識別するデータ識別子と、更新された組織１のレコードに割り当てられた世代２とを対応付けて記憶する。また、世代管理テーブル１３６は、イベント番号「１」と、配属１（個人１の配属先）のレコードを識別するデータ識別子と、更新された配属１のレコードに割り当てられた世代３とを対応付けて記憶する。
【００５７】
ステップＳ１０５において、イベント通知部１１４は、イベント番号付加部１１２で割り当てられたイベント番号を出力装置により出力する。具体的には、イベント番号付加部１１２は、データベース１０２へのデータのコミットが行われた後に、イベント通知部１１４へイベント通知を要求するデータ１３７（図７参照）を出す。その後、イベント通知部１１４は、イベント制御装置１２０のイベント受信部１２１へイベントを（例えば、図７のデータ１３７と同様の形式で）通知する。
【００５８】
一例として、イベント通知部１１４は、イベント番号として「１」を示し、イベント種別として一括更新を示すイベント情報（データ１３７と同様）をイベント受信部１２１に渡す。
【００５９】
図８は、イベント種別と、配信先、プロトコル（形式）、配信する内容（配信項目１，２，・・・）、検索順序との対応を示した配信先情報管理表１４１、イベント受信部１２１から配信管理部１２４へ流れるデータ１４２の例を示す図である。
【００６０】
ステップＳ１０６において、イベント受信部１２１は、イベント通知部１１４から出力されたイベント番号を受信する。具体的には、イベント受信部１２１は、イベント通知部１１４からイベント情報（データ１３７と同様）を受信した後、配信管理部１２４にイベント番号及びイベント種別を含むデータ１４２（図８参照）を送信し、配信が開始されることを通知する。このとき、イベント受信部１２１は、予めどの配信先へ配信が行われるかを配信先情報管理表１４１（図８参照）により抽出し、イベント番号、配信先、イベント種別の組み合わせを通知してもよい。また、イベント番号、配信先、イベント種別の組み合わせに対し番号を割り当ててもよい。イベント受信部１２１は、整合性検索要求部１２２、データ送信部１２３に対し、イベント種別を基に配信先情報管理表１４１で示された配信先へ配信する情報（配信項目等）を取得し、配信するように要求する。このとき、イベント受信部１２１は、イベント番号と配信先の情報及び配信先に適用される検索ルールを用いるように要求する。
【００６１】
図９は、イベント番号とそのイベント番号の配信の結果との対応を示した配信履歴テーブル１４３，１４３ａ、整合性検索要求部１２２からデータ送信部１２３へ流れるデータ１４４、配信先システム１０３へと配信される配信情報１４５の例を示す図である。
【００６２】
ステップＳ１０７において、配信管理部１２４は、イベント受信部１２１で受信されたイベント番号を記憶装置により記憶する。具体的には、配信管理部１２４は、配信履歴テーブル１４３（図９参照）に、イベント番号とイベント種別の情報を登録する。なお、配信管理部１２４は、配信先情報や配信番号等の情報を追加した配信履歴テーブル１４３ａ（図９参照）を管理してもよいし、確実にリカバリ配信を実現できるのであれば（配信先が１つのみの場合等）、イベント番号のみを配信履歴テーブル１４３に記録してもよい。
【００６３】
ステップＳ１０８において、整合性検索要求部１２２は、イベント受信部１２１で受信されたイベント番号をデータベース管理装置１１０のデータセット検索部１１５に入力する。具体的には、整合性検索要求部１２２は、イベントを受け付けた際に、配信先情報管理表１４１を基にして、該当する検索順序及び配信項目で検索するようデータセット検索部１１５に要求する。なお、データセット検索部１１５への要求は、検索順序の１番目から１つずつ順番に行ってもよいし（この場合、検索順序を通知しなくてよい）、一括で行ってもよい（この場合、検索順序を通知しなければならない）。なお、検索順序とは、各配信先システム１０３において、その順序でデータが登録、更新、削除等されなければ、データの整合性が取れなくなる等の問題が生じるものをいう。
【００６４】
ステップＳ１０９〜Ｓ１１１において、データセット検索部１１５は、イベント通知部１１４から出力されたイベント番号が入力されると、入力されたイベント番号に対応する複数のデータ識別子と複数の世代番号とを世代管理テーブル１３６から取得する。そして、データセット検索部１１５は、データベース１０２を検索して、世代管理テーブル１３６から取得した複数のデータ識別子の各々に対応するデータの内容のうち、世代管理テーブル１３６から取得した複数の世代番号の各々に対応する内容を取得する。具体的には、データセット検索部１１５は、ステップＳ１０９で要求を受け付け、ステップＳ１１０で要求に見合う形でデータベース１０２の検索を行う。この際に、世代管理テーブル１３６を参照し、取得したイベント番号の対象となる世代のレコードから情報を取得する。データセット検索部１１５は、ステップＳ１１１で検索結果を、イベント制御装置１２０の整合性検索要求部１２２に通知する。
【００６５】
一例として、データセット検索部１１５は、イベント番号「１」に対応するデータ識別子と世代番号との組み合わせとして、個人１のレコードを識別するデータ識別子と世代２との組み合わせ、組織１のレコードを識別するデータ識別子と世代２との組み合わせ、配属１（個人１の配属先）のレコードを識別するデータ識別子と世代３との組み合わせを、世代管理テーブル１３６から取得する。そして、データセット検索部１１５は、データベース１０２を検索して、世代２の個人１のレコード、世代２の組織１のレコード、世代３の配属１のレコードを取得する。このとき、データセット検索部１１５は、データベース１０２を、整合性検索要求部１２２から指定された検索順序で検索して、レコードを取得する度に、取得したレコードを即時に整合性検索要求部１２２へ返信する。例えば、データセット検索部１１５は、世代２の個人１のレコード、世代２の組織１のレコード、世代３の配属１のレコードを、順番に１つずつ取得するのと同時に整合性検索要求部１２２へ送信する。これにより、リアルタイム（即ち、高速な）配信を可能とする。
【００６６】
ステップＳ１１２において、整合性検索要求部１２２は、データベース１０２に記憶された複数のデータの内容のうち、データセット検索部１１５で取得された内容を受信する。具体的には、整合性検索要求部１２２は、検索結果を受信しデータ送信部１２３へ配信対象となるデータ内容とイベント番号を含むデータ１４４（図９参照）を通知する。このとき、整合性検索要求部１２２は、検索結果を受信する度に、そのデータ内容を含むデータ１４４を即時にデータ送信部１２３に渡す。これにより、リアルタイム（即ち、高速な）配信を可能とする。
【００６７】
ステップＳ１１３において、データ送信部１２３は、整合性検索要求部１２２で受信された内容を複数の配信先システム１０３へ配信する。具体的には、データ送信部１２３は、受け付けたデータを、配信先情報管理表１４１の配信先を基に、該当する配信先システム１０３へと整合性の取れた配信情報１４５（図９参照）に変換した上で配信する。この際に、データ送信部１２３は、配信先の通信プロトコルに合わせてデータを変換する。また、このとき、データ送信部１２３は、整合性検索要求部１２２で受信された内容を、整合性検索要求部１２２から受け取る度に、即時に配信する。即ち、データ送信部１２３は、整合性検索要求部１２２で受信された内容を、データベース１０２に記憶された複数のデータ間で予め定められた順序で配信する。これにより、リアルタイム（即ち、高速な）配信を可能とする。
【００６８】
ステップＳ１１４において、配信先システム１０３は、配信情報１４５を受信し、自身のシステムへ反映させる。前述したように、配信先の形態は、データベース、データ受信とともにメールを送信するようなメールサーバ、データ受信後に任意ファイルを操作するようなシステム等、どのようなものでもよい。
【００６９】
ステップＳ１１５において、データ送信部１２３は、配信先システム１０３への配信結果（「配信成功」／「配信失敗」／「配信一部失敗」／「通信不可」等）を、配信管理部１２４に通知し、配信管理部１２４は配信結果を配信履歴テーブル１４３へ記入する。
【００７０】
図１０は、情報配信システム１００による再配信の動作を示すフローチャートである。以下、配信に失敗したイベントに対する再配信の動作について図１０を用いて説明する。
【００７１】
ステップＳ１２０〜Ｓ１２２において、配信管理部１２４は、記憶装置により記憶したイベント番号に対応する複数のデータの内容が正常に配信されたかどうかを処理装置により判定する。具体的には、ステップＳ１２０で、配信管理部１２４は、配信履歴テーブル１４３の中から、配信結果が「配信失敗」又は一定時間以上「配信中」となっている等、配信が成功になっていないイベント番号及び配信先の組み合わせの配信があるかどうかを検索する。なお、リカバリを実行するタイミングは、ステップＳ１１５で配信に失敗した直後でもよいし、決まった時間に自動起動してもよいし、外部からの要求を受け付けたタイミングでもよい。ステップＳ１２１で、配信管理部１２４は、上記検索の結果に基づき、再配信する必要のある配信情報１４５があるか判定する。配信対象が存在した場合、ステップＳ１２２において、配信管理部１２４は、整合性検索要求部１２２に対し、イベント番号を通知する。
【００７２】
この後の具体的な動作は、ステップＳ１０８〜Ｓ１１５と同様である。つまり、配信管理部１２４（配信履歴テーブル１４３）に記憶されたイベント番号に対応する複数のデータの内容が複数の配信先システム１０３のいずれかへ正常に配信されなかったと配信管理部１２４で判定された場合、整合性検索要求部１２２は、当該イベント番号をデータベース管理装置１１０のデータセット検索部１１５に再び入力する。そして、整合性検索要求部１２２は、データベース１０２に記憶された複数のデータの内容のうち、データセット検索部１１５で取得された内容を再び受信する。データ送信部１２３は、整合性検索要求部１２２で再び受信された内容を、当該内容が正常に配信されなかったと配信管理部１２４で判定された配信先システム１０３へ配信する。
【００７３】
以上のように、本実施の形態によれば、データベース１０２内で依存関係のあるデータが更新された場合、その更新後のデータをいつでも確実に整合性の取れたデータとして提供することが可能となる。また、複数のクライアントシステム１０１からのデータベース１０２の操作要求の受付と、各配信先システム１０３への情報配信をデータベース１０２にロックをかけずに並行して実行することができる。また、依存関係のあるデータ群を投入した場合でも、データベース１０２の世代管理を行うことにより、整合性を保ったまま各配信先システム１０３への配信を行える。つまり、本実施の形態では、データベース１０２を世代管理し、世代番号と配信のイベント番号を対応させることにより、クライアントシステム１０１から受け付けた整合性のあるデータ操作要求に対し、データベース１０２の操作の実行、及び、操作結果に対し整合性を保った状態での各配信先システム１０３への配信が可能である。
【００７４】
以上説明したように、本実施の形態に係る情報配信システム１００は、データそのものだけでなくデータ変更の履歴情報を登録したデータベース１０２と、データベース１０２へのコミットのタイミングで番号をデータに割り振るイベント番号付加部１１２と、データベース１０２に登録内容と内容に対応した世代番号を登録するデータ操作部１１３と、イベント番号に対応した世代のデータを検索するデータセット検索部１１５と、配信するデータセットに配信すべき順序が存在する場合にその順序どおりに検索を実行するよう要求する整合性検索要求部１２２と、配信に失敗したイベント番号を基に再配信の要求を行う配信管理部１２４とを兼ね備える。
【００７５】
このように、本実施の形態では、データ更新要求がクライアントシステム１０１から来たタイミングで単純に番号を割り当てるのではなく、データベース１０２へコミットする単位で共通のイベント番号を付加する。なお、前述したように、番号付けも全受付を対象にして連番にさせる必要はなく、クライアントの種別や操作内容等によってイベント番号の割り付けを変更させることも可能である。
【００７６】
その後、実際に付加されたイベント番号に紐付けられたデータをデータベース１０２に投入する際に、データの履歴情報（世代）も同時に登録する。
【００７７】
単純にイベント番号を付加するだけでは、配信最中のデータに対して更新が行われた際に、配信先システム１０３で受け取るデータの整合性が保障されない。一方、本実施の形態の手法では、配信中にデータの更新が行われたとしても、配信途中のデータに関しては更新前の世代のデータを配信し、その後、改めて更新後のデータを配信することで、最終的に配信されるデータの整合性を保つことが可能である。
【００７８】
また、従来のように、配信すべき対象があるかどうかを、配信を行うシステムがデータベース１０２やデータベース１０２の更新情報が記載された場所に都度確認を取りにいくのでは、リアルタイム配信を実現できない。本実施の形態では、更新内容の配信先システム１０３への配信のトリガをイベント通知にすることで、リアルタイム性を保障する。
【００７９】
また、付加したイベント番号と配信先システム１０３について配信結果の管理を行うことで、無駄のないリカバリ配信が可能となる。
【００８０】
実施の形態２．
本実施の形態について、主に実施の形態１との差異を説明する。
【００８１】
図１１は、本実施の形態に係る情報配信システム１００の構成を示すブロック図である。
【００８２】
図１１において、イベント制御装置１２０は、イベント受信部１２１、整合性検索要求部１２２、データ送信部１２３の組み合わせ、即ち、配信ルート２２１を複数有する。配信ルート２２１は、配信先システム１０３、配信するデータの種類等に応じて使い分けられる。図１１では、複数の配信ルート２２１を配信ルート１、・・・、配信ルートｎとして表している。また、必須ではないが、データベース管理装置１１０は、操作受付部１１１を複数有する。図１１では、複数の操作受付部１１１を操作受付部１、・・・、操作受付部ｎとして表している。
【００８３】
このように、本実施の形態において、情報配信システム１００は、実施の形態１と異なり、操作受付部１１１、配信ルート２２１が複数となる構成となる。
【００８４】
データベース管理装置１１０の操作受付部１１１は、クライアントシステム１０１からのデータベース１０２の操作要求を受け付け、要求元のクライアントシステム１０１と操作内容だけでなく、受付ＵＲＬ（Ｕｎｉｆｏｒｍ・Ｒｅｓｏｕｒｃｅ・Ｌｏｃａｔｏｒ）によりイベント種別（例えば、依存関係のあるデータの一括登録、一括更新、一括削除）を判断する。操作受付部１１１は、それぞれ予め設定された受付ＵＲＬに対応する受信口を持っており、この受付ＵＲＬはデータ操作内容及びデータの種類によって定まる個数だけ存在する。
【００８５】
データベース管理装置１１０のイベント通知部１１４は、イベント番号付加部１１２より送信されたイベント情報を基に、複数ある配信ルート２２１のうちどの配信ルート２２１に対しイベント番号を送付するのかを判定し、対象となる配信ルート２２１へ、イベント番号を送付する機能を持つ。
【００８６】
以下、情報配信システム１００の動作について図３を用いて説明する。
【００８７】
図１２は、依頼元のクライアントシステム１０１（依頼元名）と受付ＵＲＬとの組み合わせごとに、データ操作の種類（データ操作内容）やデータの種類とイベント種別との対応を示したイベント種別対応表１３２ｂ、配信ルート２２１ごとに、イベント種別と、配信先、プロトコル（形式）、配信する内容（配信項目１，２，・・・）、検索順序との対応を示した配信先情報管理表１４１ａの例を示す図である。
【００８８】
ステップＳ１０１において、クライアントシステム１０１は、データベース１０２への整合性の取れた（依存関係のある）データの操作要求をデータベース管理装置１１０の操作受付部１１１のいずれかへ出す。この際、操作内容１３１（図４参照）としては、データベース１０２へのレコードの追加（新規登録）、削除、更新、検索、参照等の操作が考えられるが、本実施の形態でも、実施の形態１と同様に、複数のレコードの追加、削除、更新といった操作が対象となる。クライアントシステム１０１は、どの受付ＵＲＬへ要求を送信するのかを、データベース１０２の操作内容や操作するデータの種類により決定する。なお、操作受付部１１１の数、及び、それぞれの操作受付部１１１が持つ受付ＵＲＬの数は、データ操作内容、データの種類、クライアントシステム１０１の種別等により任意に決めることができる。
【００８９】
ステップＳ１０２において、操作受付部１１１は、クライアントシステム１０１からの要求を受け付け、イベント種別対応表１３２ｂ（図１２参照）からイベント種別を決定し、イベント番号付加部１１２へイベント種別とデータ内容等を含むデータ１３３（図５参照）を通知する。このとき、操作受付部１１１は、補足情報として、どのクライアントシステム１０１から依頼を受けたのかという依頼元情報や、その他の情報を付加したデータ１３３を通知しても構わない。
【００９０】
ステップＳ１０３において、まず、イベント番号付加部１１２では、操作受付部１１１より受信したデータ１３３のまとまりに対して、共通の番号（イベント番号）を付加する。このイベント番号は、全ての操作要求に対して連番をつけることが基本であるが、図１２のイベント種別対応表１３２ｂの依頼元名のように、クライアントシステム１０１の種別や操作内容ごとに「クライアント１−１」、「データ削除−１」のような形式で割り当てることも可能である。イベント番号としては、番号以外にも記号や漢字等の文字も、イベント番号間で重複するものがなければ、割り当てることが可能である。共通のイベント番号を付加する対象は、データベース１０２にコミットする単位、即ちデータ間に整合性の取れている範囲とする。なお、データ１件で整合性が取れている場合（例えば、既存の個人の新たな配属先として既存の組織を指定する場合）は、１件の単位でイベント番号を付加することも可能である。次に、イベント番号付加部１１２は、イベント番号を付加したデータ１３４（図５参照）をデータ操作部１１３へ送付する。
【００９１】
ステップＳ１０４において、データ操作部１１３は、イベント番号付加部１１２から受信したデータ１３４を基に、データベース１０２に対して操作を行う。データベース１０２の操作の際は、操作内容の結果のみをデータベース１０２として登録するのではなく、更新後の情報とともに、更新前の情報の履歴を世代としてデータベース１０２に保存する。次に、データ操作部１１３は、データそのものの登録だけでなく、世代管理テーブル１３６（図７参照）に、あるイベント番号の操作によって、どのレコードのどの世代を配信対象とすればよいのかを登録する。
【００９２】
ステップＳ１０５において、イベント番号付加部１１２は、データベース１０２へのデータのコミットが行われた後に、イベント通知部１１４へイベント通知を要求するデータ１３７（図７参照）を出す。その後、イベント通知部１１４は、イベント種別の情報を基にして、配信先情報管理表１４１ａ（図１２参照）より、イベント制御装置１２０のどの配信ルート２２１へイベントを通知するのかを決定し、通知すべき配信ルート２２１全てのイベント受信部１２１へイベントを（例えば、図７のデータ１３７と同様の形式で）通知する。
【００９３】
ステップＳ１０６において、イベント受信部１２１は、イベント通知部１１４からイベント情報（データ１３７と同様）を受信した後、配信管理部１２４にイベント番号及びイベント種別を含むデータ１４２（図８参照）を送信し、配信が開始されることを通知する。また、イベント受信部１２１は、整合性検索要求部１２２、データ送信部１２３に対し、イベント種別を基に配信先情報管理表１４１ａで示された配信先へ配信する情報（配信項目等）を取得し、配信するように要求する。このとき、イベント受信部１２１は、イベント番号と配信先の情報及び配信先に適用される検索ルールを用いるように要求する。
【００９４】
ステップＳ１０７において、配信管理部１２４は、配信履歴テーブル１４３（図９参照）に、イベント番号とイベント種別の情報を登録する。このとき、配信管理部１２４は、配信履歴テーブル１４３に、さらに、どの配信ルート２２１でイベントを受け付けたか等の情報を登録することが望ましい。なお、配信管理部１２４は、確実にリカバリ配信を実現できるのであれば（配信先が１つのみの場合等）、イベント番号のみを配信履歴テーブル１４３に記録したり、イベント番号と配信ルート２２１に関する情報のみを配信履歴テーブル１４３に記録してもよい。
【００９５】
ステップＳ１０８において、整合性検索要求部１２２は、イベントを受け付けた際に、配信先情報管理表１４１ａを基にして、自身の所属する配信ルート２２１に対応する検索順序及び配信項目で検索するようデータセット検索部１１５に要求する。なお、データセット検索部１１５への要求は、検索順序の１番目から１つずつ順番に行ってもよいし（この場合、検索順序を通知しなくてよい）、一括で行ってもよい（この場合、検索順序を通知しなければならない）。
【００９６】
データセット検索部１１５は、ステップＳ１０９で要求を受け付け、ステップＳ１１０で要求に見合う形でデータベース１０２の検索を行う。この際に、世代管理テーブル１３６を参照し、取得したイベント番号の対象となる世代のレコードから情報を取得する。データセット検索部１１５は、ステップＳ１１１で検索結果を、イベント制御装置１２０の整合性検索要求部１２２に通知する。
【００９７】
ステップＳ１１２において、整合性検索要求部１２２は、検索結果を受信しデータ送信部１２３へ配信対象となるデータ内容とイベント番号を含むデータ１４４（図９参照）を通知する。
【００９８】
ステップＳ１１３において、データ送信部１２３は、受け付けたデータを、配信先情報管理表１４１ａの配信先を基に、該当する配信先システム１０３へと整合性の取れた配信情報１４５（図９参照）に変換した上で配信する。この際に、データ送信部１２３は、配信先の通信プロトコルに合わせてデータを変換する。
【００９９】
ステップＳ１１４において、配信先システム１０３は、配信情報１４５を受信し、自身のシステムへ反映させる。前述したように、配信先の形態は、データベース、データ受信とともにメールを送信するようなメールサーバ、データ受信後に任意ファイルを操作するようなシステム等、どのようなものでもよい。
【０１００】
ステップＳ１１５において、データ送信部１２３は、配信先システム１０３への配信結果（「配信成功」／「配信失敗」／「配信一部失敗」／「通信不可」等）を、配信管理部１２４に通知し、配信管理部１２４は配信結果を配信履歴テーブル１４３へ記入する。
【０１０１】
以下、配信に失敗したイベントに対する再配信の動作について図１０を用いて説明する。
【０１０２】
ステップＳ１２０で、配信管理部１２４は、配信履歴テーブル１４３の中から、配信結果が「配信失敗」又は一定時間以上「配信中」となっている等、配信が成功になっていないイベント番号及び配信先の組み合わせの配信があるかどうかを検索する。なお、リカバリを実行するタイミングは、ステップＳ１１５で配信に失敗した直後でもよいし、決まった時間に自動起動してもよいし、外部からの要求を受け付けたタイミングでもよい。ステップＳ１２１で、配信管理部１２４は、上記検索の結果に基づき、再配信する必要のある配信情報１４５があるか判定する。配信対象が存在した場合、ステップＳ１２２において、配信管理部１２４は、整合性検索要求部１２２に対し、イベント番号を通知する。
【０１０３】
この後の具体的な動作は、ステップＳ１０８〜Ｓ１１５と同様である。
【０１０４】
以上のように、本実施の形態では、各配信先システム１０３への配信処理をパラレルに実行することが可能なので、配信の待ち時間が減少し、より即時性の高い配信が実現される。
【０１０５】
配信用のルートが１本しか存在しないのでは、配信先システム１０３の数が多くなるにつれ、各配信先システム１０３間でのデータ受領のタイミングの差が大きくなってしまう。上記のように、本実施の形態では、配信ルート２２１を複数用意することによって、各配信先システム１０３への配信処理をパラレルに実行することが可能なので、配信の待ち時間が減少される。
【０１０６】
実施の形態３．
本実施の形態について、主に実施の形態２との差異を説明する。
【０１０７】
図１３は、本実施の形態に係る情報配信システム１００の構成を示すブロック図である。
【０１０８】
本実施の形態では、実施の形態２と異なり、イベント制御装置１２０が配信先システム１０３へデータを配信するのではなく、イベント制御装置１２０は配信先システム１０３へイベント番号のみを通知し、配信先システム１０３がイベント番号を基にデータベース管理装置１１０に情報を要求する。
【０１０９】
図１４は、情報配信システム１００の動作（本実施の形態に係る情報配信方法（データベース管理方法を含む））を示すフローチャートである。以下、情報配信システム１００の動作について図１４を用いて説明する。
【０１１０】
ステップＳ３０１〜Ｓ３１０については、実施の形態２のステップＳ１０１〜Ｓ１１０と同様である。
【０１１１】
ステップＳ３１１において、データセット検索部１１５は、ステップＳ３１０でデータベース１０２の検索を行った結果を、イベント制御装置１２０の整合性検索要求部１２２に通知する代わりに、記憶装置により保持しておく。データセット検索部１１５は、整合性検索要求部１２２には、検索が完了したことのみを通知する。
【０１１２】
ステップＳ３１２において、整合性検索要求部１２２は、検索完了の通知を受け、データ送信部１２３へイベント番号を送信する。データ送信部１２３は、配信先システム１０３へイベント番号を送信する。
【０１１３】
ステップＳ３１３において、配信先システム１０３は、イベント番号を取得する。ステップＳ３１４において、配信先システム１０３は、データベース管理装置１１０のデータセット検索部１１５にイベント番号を通知してデータを要求する。
【０１１４】
ステップＳ３１５において、データセット検索部１１５は、要求を受け付ける。ステップＳ３１６において、データセット検索部１１５は、保持していた検索結果を配信先システム１０３へ配信する。
【０１１５】
ステップＳ３１７において、配信先システム１０３は、データを取得する。ステップＳ３１８において、配信先システム１０３は、配信結果をイベント制御装置１２０のデータ送信部１２３へ返す。
【０１１６】
ステップＳ３１９において、データ送信部１２３は、配信管理部１２４へ配信結果を通知する。
【０１１７】
本実施の形態では、リカバリについても、実際のリカバリ対象のデータをイベント制御装置１２０に通すのではなく、配信先システム１０３が直接データベース管理装置１１０のデータセット検索部１１５とやり取りすることにより実現される。
【０１１８】
以上により、データベース管理装置１１０、イベント制御装置１２０が複数のサーバで構成されている場合、必要以上のサーバ間データの受け渡し量を削減することが可能となり、サーバシステムの負荷を減らすことが可能となる。
【０１１９】
配信すべきデータ量が多くなった場合、システムのサーバ内で配信情報の受け渡しをすると、システム中を流れるデータ量が多くなりサーバに負荷がかかる。そこで、本実施の形態では、配信先システム１０３には更新が行われたことのみを通知し、データの取得は配信先システム１０３がデータベース管理装置１１０に要求することで、サーバへの負荷を減らすことが可能となる。
【０１２０】
実施の形態４．
本実施の形態について、主に実施の形態２との差異を説明する。
【０１２１】
図１５は、本実施の形態に係る情報配信システム１００の構成を示すブロック図である。
【０１２２】
本実施の形態では、リカバリ配信を行う際に、配信失敗となった配信ルート２２１に再配信要求を出すのではなく、情報配信システム１００が別に持つ再配信用の配信ルートであるリカバリ配信ルート４５１に再配信要求を出す。
【０１２３】
図１５において、リカバリ要求元４５０は、リカバリ配信ルート４５１にリカバリ配信を要求する。リカバリ要求元４５０には、情報配信システム１００の管理者、クライアントシステム１０１（のユーザ）、配信先システム１０３（のユーザ）等がなり得る。
【０１２４】
リカバリ配信ルート４５１は、リカバリ受付部４５２のほか、他の配信ルート２２１と同様の整合性検索要求部１２２とデータ送信部１２３とを有する。なお、リカバリ配信ルート４５１は、リカバリ対象となるイベント種別や配信先システム１０３ごとに用意することも可能である。
【０１２５】
リカバリ受付部４５２は、リカバリ要求元４５０からのリカバリ要求を受け付ける。
【０１２６】
情報配信システム１００の通常の配信動作については、図３に示した実施の形態２のものと同様である。
【０１２７】
図１６は、情報配信システム１００による再配信の動作を示すフローチャートである。以下、配信に失敗したイベントに対する再配信の動作について図１６を用いて説明する。
【０１２８】
ステップＳ４０１において、リカバリ要求元４５０は、リカバリ配信ルート４５１のリカバリ受付部４５２に対しリカバリ配信を要求する。この際、リカバリ受付に対してどの配信ルート２２１のリカバリを要求するのかをリカバリ要求元４５０で指定してもよいし、全てのリカバリ対象のリカバリ配信を要求してもよい。
【０１２９】
ステップＳ４０２において、リカバリ受付部４５２は、配信管理部１２４に対してリカバリ対象の検索を要求する。リカバリ受付部４５２は、外部からのリカバリ要求の受付以外にも、予め指定された時刻や、通常の配信に失敗した直後等も動作してよい。
【０１３０】
ステップＳ４０３において、配信管理部１２４は、配信履歴テーブル１４３ａの中で、今回のリカバリ対象となるイベントのうち、配信結果が「配信失敗」又は一定時間以上「配信中」となっている等、配信が成功になっていないイベント番号及び配信先の組み合わせの配信があるかどうかを検索する。ステップＳ４０４において、配信管理部１２４は、上記検索の結果に基づき、再配信する必要のある配信情報１４５があるか判定する。配信対象が存在した場合、配信管理部１２４は、整合性検索要求部１２２に対し、イベント番号を通知する。
【０１３１】
この後の具体的な動作及びステップＳ４０５〜Ｓ４１１については、実施の形態２のステップＳ１０８〜Ｓ１１５と同様である。
【０１３２】
上記のように、本実施の形態では、イベント制御装置１２０が、整合性検索要求部１２２とデータ送信部１２３との組み合わせを少なくとも２つ（配信ルート２２１及びリカバリ配信ルート４５１）有する。そして、配信管理部１２４（配信履歴テーブル１４３）に記憶されたイベント番号に対応する複数のデータの内容が複数の配信先システム１０３のいずれかへ正常に配信されなかったと配信管理部１２４で判定された場合と、それ以外の場合（正常に配信ができた場合）とで、使用する整合性検索要求部１２２とデータ送信部１２３との組み合わせを切り換える。このように、本実施の形態では、リカバリ配信ルート４５１を通常の配信ルート２２１と別に設けることで、通常の配信の邪魔をせずに並行して（通常の配信に影響を与えることなく）リカバリ配信を実現することが可能となる。
【０１３３】
以上、本発明の実施の形態について説明したが、これらのうち、２つ以上の実施の形態を組み合わせて実施しても構わない。あるいは、これらのうち、１つの実施の形態を部分的に実施しても構わない。あるいは、これらのうち、２つ以上の実施の形態を部分的に組み合わせて実施しても構わない。
【符号の説明】
【０１３４】
１００ 情報配信システム、１０１ クライアントシステム、１０２ データベース、１０３ 配信先システム、１１０ データベース管理装置、１１１ 操作受付部、１１２ イベント番号付加部、１１３ データ操作部、１１４ イベント通知部、１１５ データセット検索部、１２０ イベント制御装置、１２１ イベント受信部、１２２ 整合性検索要求部、１２３ データ送信部、１２４ 配信管理部、１３１ 操作内容、１３２，１３２ａ，１３２ｂ イベント種別対応表、１３３，１３４，１３７，１４２，１４４ データ、１３５，１３５ａ テーブル、１３６ 世代管理テーブル、１４１，１４１ａ 配信先情報管理表、１４３，１４３ａ 配信履歴テーブル、１４５ 配信情報、２２１ 配信ルート、４５０ リカバリ要求元、４５１ リカバリ配信ルート、４５２ リカバリ受付部、９０１ ＬＣＤ、９０２ キーボード、９０３ マウス、９０４ ＦＤＤ、９０５ ＣＤＤ、９０６ プリンタ、９１１ ＣＰＵ、９１２ バス、９１３ ＲＯＭ、９１４ ＲＡＭ、９１５ 通信ボード、９２０ ＨＤＤ、９２１ オペレーティングシステム、９２２ ウィンドウシステム、９２３ プログラム群、９２４ ファイル群。
【技術分野】
【０００１】
本発明は、データベース管理装置及び情報配信システム及びデータベース管理方法及びプログラムに関するものである。
【背景技術】
【０００２】
昨今の社会では、情報配信技術及び情報共有技術が必須となっており、データの集中化とともに、登録されたデータを複数のシステムへリアルタイムに配信を行うことが求められている。具体的には、マスタとなるデータベースに対して、クライアントからデータベースの登録を行った際に、データベースに登録された内容を複数の配信先へ即時に配信することが要求されている。
【０００３】
従来、登録された情報に番号を割り当て、その番号の情報が、正しく各配信先へ配信されているかを確認し、正しく配信されていなければ再配信を行う情報配信システムがある（例えば、特許文献１参照）。また、データベースに記憶されたデータのうち、更新がなされた更新データに対して、同報ネットワークを介して送信を行うのに必要な資源を割り当て、資源の割当量に従って、更新データそのもの又は更新がなされたことを示す更新報知情報を、同報ネットワークを介して送信する情報配信システムがある（例えば、特許文献２参照）。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００５−１５７６４７号公報
【特許文献２】特開平１０−３０３９８３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
データベースに登録される情報１件１件の間に依存関係が存在する場合を考える。なお、ここでいう依存関係のあるデータとは、「（１）個人１を登録」、「（２）組織１を登録」、「（３）配属１（個人１を組織１に配属）を登録」といったデータを投入する順序に制約があるような、１件のデータベース操作だけでは意味をなさない一連のデータのことを指す。
【０００６】
従来の情報配信システム（配信技術）では、依存関係のあるデータを登録し、各配信先へ配信している途中で、配信対象のデータに対し再度更新を実行した場合、配信先へ送信されるデータの整合性が保障されない。
【０００７】
例えば、Ａ、Ｂ、Ｃという各データ間に依存関係があるデータをデータベースに登録し、各配信先へ配信する場合を考える。このとき、全ての配信先へＡ、Ｂ、Ｃの配信が完了する前に、Ａを再度更新した場合、一部配信先へは、更新前のＡが配信されず、配信後のデータの整合性が取れなくなってしまう。
【０００８】
この問題への単純な対処方法としては、データベースの更新後、各配信先へ配信が行われるまではデータベースへの更新を受け付けない（データベースをロックする）手段が考えられる。しかし、この方法では配信情報量や配信先が増えるに従ってデータベースがロックされる時間が長くなってしまうため、リアルタイム性が損なわれてしまう。
【０００９】
また、複数の配信先のうち、一部のみが配信失敗となってしまった場合、単純に更新内容に番号を割り当てただけでは、どの配信先への配信を行えばいいのか特定できない。
【００１０】
本発明は、例えば、データベース内で依存関係のあるデータが更新された場合、その更新後のデータをいつでも確実に整合性の取れたデータとして提供することを目的とする。また、例えば、複数のクライアントからのデータベース操作要求の受付と、各配信先への情報配信をデータベースにロックをかけずに並行して実行し、かつ、依存関係のあるデータ群を投入した場合でも、データベースの世代管理を行うことにより、整合性を保ったまま各配信先への配信を行えるように、データの保障性の高い整合性の取れたリアルタイム情報配信の実現を目的とする。
【課題を解決するための手段】
【００１１】
本発明の一の態様に係るデータベース管理装置は、
過去に内容が変更されたデータ群を記憶するデータベースであり、データ群に含まれるデータごとに、データの内容が変更される度に割り当てられる世代番号と、変更された内容とを対応付けて記憶するデータベースを管理するデータベース管理装置であって、
前記データベースに記憶されたデータ群に含まれる複数のデータの内容を変更する操作を入力装置によりイベントとして受け付ける操作受付部と、
前記操作受付部で受け付けられたイベントに対して一意のイベント識別子を処理装置により割り当てるイベント識別子割当部と、
前記操作受付部で受け付けられたイベントに基づいて前記データベースに記憶された複数のデータの内容を変更し、内容を変更したデータごとに、新たな世代番号を処理装置により割り当てて前記データベースに記憶させるデータ操作部と、
前記イベント識別子割当部で割り当てられたイベント識別子と、前記データ操作部で内容が変更された複数のデータを各々識別する複数のデータ識別子と、前記データ操作部で当該複数のデータに各々割り当てられた複数の世代番号とを対応付けて記憶装置により記憶する世代管理部と、
前記イベント識別子割当部で割り当てられたイベント識別子を出力装置により出力するイベント通知部と、
前記イベント通知部から出力されたイベント識別子が入力されると、入力されたイベント識別子に対応する複数のデータ識別子と複数の世代番号とを前記世代管理部から取得し、前記データベースを検索して、取得した複数のデータ識別子の各々に対応するデータの内容のうち、取得した複数の世代番号の各々に対応する内容を取得するデータセット検索部とを有する。
【発明の効果】
【００１２】
本発明の一の態様によれば、データベース内で依存関係のあるデータが更新された場合、その更新後のデータをいつでも確実に整合性の取れたデータとして提供することが可能となる。
【図面の簡単な説明】
【００１３】
【図１】実施の形態１に係る情報配信システムの構成を示すブロック図。
【図２】実施の形態１に係る情報配信システムのハードウェア構成の一例を示す図。
【図３】実施の形態１に係る情報配信システムの動作を示すフローチャート。
【図４】実施の形態１に係るクライアントシステムから要求される操作内容、イベント種別対応表の例を示す図。
【図５】実施の形態１に係る操作受付部からイベント番号付加部へ流れるデータ、イベント番号付加部からデータ操作部へ流れるデータの例を示す図。
【図６】実施の形態１に係るデータベースで保持される配属情報のテーブルの例を示す図。
【図７】実施の形態１に係る世代管理テーブル、イベント番号付加部からイベント通知部へ通知されるデータの例を示す図。
【図８】実施の形態１に係る配信先情報管理表、イベント受信部から配信管理部へ流れるデータの例を示す図。
【図９】実施の形態１に係る配信履歴テーブル、整合性検索要求部からデータ送信部へ流れるデータ、配信情報の例を示す図。
【図１０】実施の形態１に係る情報配信システムによる再配信の動作を示すフローチャート。
【図１１】実施の形態２に係る情報配信システムの構成を示すブロック図。
【図１２】実施の形態２に係るイベント種別対応表、配信先情報管理表の例を示す図。
【図１３】実施の形態３に係る情報配信システムの構成を示すブロック図。
【図１４】実施の形態３に係る情報配信システムの動作を示すフローチャート。
【図１５】実施の形態４に係る情報配信システムの構成を示すブロック図。
【図１６】実施の形態４に係る情報配信システムによる再配信の動作を示すフローチャート。
【発明を実施するための形態】
【００１４】
以下、本発明の実施の形態について、図を用いて説明する。
【００１５】
実施の形態１．
図１は、本実施の形態に係る情報配信システム１００の構成を示すブロック図である。
【００１６】
図１において、情報配信システム１００は、データベース１０２、データベース管理装置１１０、イベント制御装置１２０を備える。情報配信システム１００は、クライアントシステム１０１から受け付けた依存関係のあるデータの操作要求に対し、データベース管理装置１１０によりデータベース１０２の操作を行った後に、イベント制御装置１２０により操作結果を各配信先システム１０３へと配信するシステムである。
【００１７】
図１には示していないが、情報配信システム１００は、処理装置、記憶装置、入力装置、出力装置等のハードウェアを備える。ハードウェアは、データベース１０２や、後述するデータベース管理装置１１０及びイベント制御装置１２０の各部によって利用される。例えば、処理装置は、データや情報の演算、加工、読み取り、書き込み等を行うために利用される。記憶装置は、そのデータや情報を記憶するために利用される。また、入力装置は、そのデータや情報を入力するために、出力装置は、そのデータや情報を出力するために利用される。
【００１８】
クライアントシステム１０１は、データベース１０２の登録・更新等の操作を要求するシステムである。情報配信システム１００に接続するクライアントシステム１０１の数が複数あってもよい。
【００１９】
データベース１０２は、マスタとなるデータベースである。データベース１０２の形式としては関係データベース、階層型データベース等、任意の形式を使用してよい。ここでは、便宜上、関係データベースを使用しているものとする。
【００２０】
配信先システム１０３は、データベース１０２で登録・更新等の操作がされた情報を受信するシステムである。配信先システム１０３の数は、必要に応じて任意の数をとる。図１では、複数の配信先システム１０３を配信先１、・・・、配信先ｎとして表している。配信先システム１０３の形態はデータベースや、受信した情報を基にメールを送信するメールサーバや、受信した情報を基にファイル構成を変更するようなシステム等である。
【００２１】
データベース管理装置１１０は、クライアントシステム１０１からの操作要求を受け付ける機能、データベース１０２へ登録、更新、削除、検索等の操作を行う機能を持つ。データベース管理装置１１０は、操作受付部１１１、イベント番号付加部１１２（イベント識別子割当部の一例）、データ操作部１１３、イベント通知部１１４、データセット検索部１１５を有する。
【００２２】
操作受付部１１１は、クライアントシステム１０１からのデータベース１０２の操作要求を受け付け、要求元のクライアントシステム１０１と操作内容によりイベント種別（例えば、依存関係のあるデータの一括登録、一括更新、一括削除）を判断する。
【００２３】
イベント番号付加部１１２は、操作受付部１１１より受信したデータに対しイベント番号（イベント識別子の一例）を付加する機能と、イベント番号とデータをデータ操作部１１３に送信する機能と、イベント通知部１１４へイベント番号とイベント種別とを含むイベント情報を送信する機能を持つ。
【００２４】
データ操作部１１３は、イベント番号付加部１１２より受信したイベント番号とデータを、データベース１０２へ投入する。
【００２５】
イベント通知部１１４は、イベント番号付加部１１２より送信されたイベント情報をイベント制御装置１２０へと送付する機能を持つ。
【００２６】
データセット検索部１１５は、イベント制御装置１２０からの要求を基にデータベース１０２の検索を行う。
【００２７】
イベント制御装置１２０は、データベース管理装置１１０からのイベント通知により、各配信先システム１０３への配信情報を取得し、配信状況を確認する機能を持つ。イベント制御装置１２０は、イベント受信部１２１、整合性検索要求部１２２（検索要求部の一例）、データ送信部１２３、配信管理部１２４を有する。
【００２８】
イベント受信部１２１は、イベント通知部１１４からのイベント情報を受け付ける機能を持つ。
【００２９】
整合性検索要求部１２２は、配信先情報管理表（イベント種別ごとに、データの配信先、配信項目、検索順序等を定めたテーブル）を基に、配信先システム１０３への情報配信内容に整合性が取れるようにデータベース１０２に対し検索要求を出す機能を有する。
【００３０】
データ送信部１２３は、検索されたデータを配信先情報管理表により指定された送信先へ送信する。
【００３１】
配信管理部１２４は、イベント受信部１２１で受け付けたイベント番号を登録する機能と、登録されたイベント番号の配信状況を監視する機能を持つ。
【００３２】
図２は、情報配信システム１００のハードウェア構成の一例を示す図である。
【００３３】
図２において、情報配信システム１００は、コンピュータであり、ＬＣＤ９０１（Ｌｉｑｕｉｄ・Ｃｒｙｓｔａｌ・Ｄｉｓｐｌａｙ）、キーボード９０２（Ｋ／Ｂ）、マウス９０３、ＦＤＤ９０４（Ｆｌｅｘｉｂｌｅ・Ｄｉｓｋ・Ｄｒｉｖｅ）、ＣＤＤ９０５（Ｃｏｍｐａｃｔ・Ｄｉｓｃ・Ｄｒｉｖｅ）、プリンタ９０６といったハードウェアデバイスを備えている。これらのハードウェアデバイスはケーブルや信号線で接続されている。ＬＣＤ９０１の代わりに、ＣＲＴ（Ｃａｔｈｏｄｅ・Ｒａｙ・Ｔｕｂｅ）、あるいは、その他の表示装置が用いられてもよい。マウス９０３の代わりに、タッチパネル、タッチパッド、トラックボール、ペンタブレット、あるいは、その他のポインティングデバイスが用いられてもよい。
【００３４】
なお、情報配信システム１００のうち、データベース管理装置１１０とイベント制御装置１２０とが別々のコンピュータとして実現されていても構わない。
【００３５】
情報配信システム１００は、プログラムを実行するＣＰＵ９１１（Ｃｅｎｔｒａｌ・Ｐｒｏｃｅｓｓｉｎｇ・Ｕｎｉｔ）を備えている。ＣＰＵ９１１は、処理装置の一例である。ＣＰＵ９１１は、バス９１２を介してＲＯＭ９１３（Ｒｅａｄ・Ｏｎｌｙ・Ｍｅｍｏｒｙ）、ＲＡＭ９１４（Ｒａｎｄｏｍ・Ａｃｃｅｓｓ・Ｍｅｍｏｒｙ）、通信ボード９１５、ＬＣＤ９０１、キーボード９０２、マウス９０３、ＦＤＤ９０４、ＣＤＤ９０５、プリンタ９０６、ＨＤＤ９２０（Ｈａｒｄ・Ｄｉｓｋ・Ｄｒｉｖｅ）と接続され、これらのハードウェアデバイスを制御する。ＨＤＤ９２０の代わりに、フラッシュメモリ、光ディスク装置、メモリカードリーダライタ、あるいは、その他の記録媒体が用いられてもよい。
【００３６】
ＲＡＭ９１４は、揮発性メモリの一例である。ＲＯＭ９１３、ＦＤＤ９０４、ＣＤＤ９０５、ＨＤＤ９２０は、不揮発性メモリの一例である。これらは、記憶装置の一例である。通信ボード９１５、キーボード９０２、マウス９０３、ＦＤＤ９０４、ＣＤＤ９０５は、入力装置の一例である。また、通信ボード９１５、ＬＣＤ９０１、プリンタ９０６は、出力装置の一例である。
【００３７】
通信ボード９１５は、ＬＡＮ（Ｌｏｃａｌ・Ａｒｅａ・Ｎｅｔｗｏｒｋ）等に接続されている。通信ボード９１５は、ＬＡＮに限らず、ＩＰ−ＶＰＮ（Ｉｎｔｅｒｎｅｔ・Ｐｒｏｔｏｃｏｌ・Ｖｉｒｔｕａｌ・Ｐｒｉｖａｔｅ・Ｎｅｔｗｏｒｋ）、広域ＬＡＮ、ＡＴＭ（Ａｓｙｎｃｈｒｏｎｏｕｓ・Ｔｒａｎｓｆｅｒ・Ｍｏｄｅ）ネットワークといったＷＡＮ（Ｗｉｄｅ・Ａｒｅａ・Ｎｅｔｗｏｒｋ）、あるいは、インターネットに接続されていても構わない。ＬＡＮ、ＷＡＮ、インターネットは、ネットワークの一例である。
【００３８】
ＨＤＤ９２０には、オペレーティングシステム９２１（ＯＳ）、ウィンドウシステム９２２、プログラム群９２３、ファイル群９２４が記憶されている。プログラム群９２３のプログラムは、ＣＰＵ９１１、オペレーティングシステム９２１、ウィンドウシステム９２２により実行される。プログラム群９２３には、本実施の形態の説明において「〜部」として説明する機能を実行するプログラムが含まれている。プログラムは、ＣＰＵ９１１により読み出され実行される。ファイル群９２４には、本実施の形態の説明において、「〜データ」、「〜情報」、「〜ＩＤ（識別子）」、「〜フラグ」、「〜結果」として説明するデータや情報や信号値や変数値やパラメータが、「〜ファイル」や「〜データベース」や「〜テーブル」の各項目として含まれている。「〜ファイル」や「〜データベース」や「〜テーブル」は、ＲＡＭ９１４やＨＤＤ９２０等の記録媒体に記憶される。ＲＡＭ９１４やＨＤＤ９２０等の記録媒体に記憶されたデータや情報や信号値や変数値やパラメータは、読み書き回路を介してＣＰＵ９１１によりメインメモリやキャッシュメモリに読み出され、抽出、検索、参照、比較、演算、計算、制御、出力、印刷、表示といったＣＰＵ９１１の処理（動作）に用いられる。抽出、検索、参照、比較、演算、計算、制御、出力、印刷、表示といったＣＰＵ９１１の処理中、データや情報や信号値や変数値やパラメータは、メインメモリやキャッシュメモリやバッファメモリに一時的に記憶される。
【００３９】
本実施の形態の説明において用いるブロック図やフローチャートの矢印の部分は主としてデータや信号の入出力を示す。データや信号は、ＲＡＭ９１４等のメモリ、ＦＤＤ９０４のフレキシブルディスク（ＦＤ）、ＣＤＤ９０５のコンパクトディスク（ＣＤ）、ＨＤＤ９２０の磁気ディスク、光ディスク、ＤＶＤ（Ｄｉｇｉｔａｌ・Ｖｅｒｓａｔｉｌｅ・Ｄｉｓｃ）、あるいは、その他の記録媒体に記録される。また、データや信号は、バス９１２、信号線、ケーブル、あるいは、その他の伝送媒体により伝送される。
【００４０】
本実施の形態の説明において「〜部」として説明するものは、「〜回路」、「〜装置」、「〜機器」であってもよく、また、「〜ステップ」、「〜工程」、「〜手順」、「〜処理」であってもよい。即ち、「〜部」として説明するものは、ＲＯＭ９１３に記憶されたファームウェアで実現されていても構わない。あるいは、「〜部」として説明するものは、ソフトウェアのみ、あるいは、素子、デバイス、基板、配線といったハードウェアのみで実現されていても構わない。あるいは、「〜部」として説明するものは、ソフトウェアとハードウェアとの組み合わせ、あるいは、ソフトウェアとハードウェアとファームウェアとの組み合わせで実現されていても構わない。ファームウェアとソフトウェアは、プログラムとして、フレキシブルディスク、コンパクトディスク、磁気ディスク、光ディスク、ＤＶＤ等の記録媒体に記憶される。プログラムはＣＰＵ９１１により読み出され、ＣＰＵ９１１により実行される。即ち、プログラムは、本実施の形態の説明で述べる「〜部」としてコンピュータを機能させるものである。あるいは、プログラムは、本実施の形態の説明で述べる「〜部」の手順や方法をコンピュータに実行させるものである。
【００４１】
図３は、情報配信システム１００の動作（本実施の形態に係る情報配信方法（データベース管理方法を含む））を示すフローチャートである。以下、情報配信システム１００の動作について図３を用いて説明する。
【００４２】
ここで、データベース１０２は、個人情報、組織情報、配属情報といったデータ群を記憶する。一例として、データベース１０２は、個人情報として、企業の従業員等である個人１、個人２、・・・の名前、年齢、住所、電話番号等を、個人を一意に識別する個人ＩＤ（識別子）ごとに記憶する。また、データベース１０２は、組織情報として、企業の部署等である組織１、組織２、・・・の名称、所在地、電話番号等を、組織を一意に識別する組織ＩＤごとに記憶する。また、データベース１０２は、配属情報として、個人１、個人２、・・・が組織１、組織２、・・・のいずれに配属されているかを示す配属１、配属２、・・・を記憶する。
【００４３】
また、データベース１０２は、データ群に含まれるデータごとに、データの内容が変更される度に割り当てられる世代番号と、内容が変更されたデータとを対応付けて記憶する。例えば、新たなデータがデータベース１０２に登録される際には、世代番号として世代１が割り当てられ、そのデータと対応付けてデータベース１０２に記憶される。それ以降、データが更新される度に、最後に割り当てられた世代番号を１つインクリメントした世代番号が割り当てられ、更新されたデータと対応付けてデータベース１０２に記憶される。例えば、登録後、データが初めて更新された場合、世代番号として世代２が割り当てられ、更新されたデータと対応付けてデータベース１０２に記憶される。つまり、このとき、登録時のデータと世代１との組み合わせ、及び、更新されたデータと世代２との組み合わせがデータベース１０２に記憶されることになる。なお、更新されたデータ全体ではなく、変更された内容のみと世代２との組み合わせがデータベース１０２に記憶されてもよい。この場合、ある世代のデータを取得したいときは、その世代以前のデータの変更履歴を辿ってデータを復元する必要があるが、データベース１０２に記憶するデータ量の増大を抑制することができる。
【００４４】
図４は、クライアントシステム１０１から要求される操作内容１３１、データ操作の種類（データ操作内容）やデータの種類とイベント種別の対応を示したイベント種別対応表１３２，１３２ａの例を示す図である。図５は、操作受付部１１１からイベント番号付加部１１２へ流れるデータ１３３、イベント番号付加部１１２からデータ操作部１１３へ流れるデータ１３４の例を示す図である。
【００４５】
まず、ステップＳ１０１において、クライアントシステム１０１は、データベース１０２に記憶されたデータ群に含まれる複数のデータの内容を変更する操作を行う。具体的には、クライアントシステム１０１は、データベース１０２への整合性の取れた（依存関係のある）データの操作要求をデータベース管理装置１１０の操作受付部１１１へ出す。この際、操作内容１３１（図４参照）としては、データベース１０２へのレコードの追加（新規登録）、削除、更新、検索、参照等の操作が考えられるが、本実施の形態では、複数のレコードの追加、削除、更新といった操作が対象となる。
【００４６】
一例として、クライアントシステム１０１は、配属１のレコード（配属情報）（第１のデータの一例）と、データベース１０２において配属１のレコードから参照される個人１のレコード（個人情報）及び組織１のレコード（組織情報）（いずれも第２のデータの例）とを更新する操作（例えば、個人１の年齢、組織１の名称、個人１の配属先の変更）を行う。本実施の形態は、このような参照整合性（参照制約）が要求される（即ち、依存関係にある）データの内容を変更する場合に、特に効果を奏する。なお、例えばデータベース１０２が関係データベースではなく、階層型データベースであれば、本実施の形態は、存在整合性（存在制約）が要求されるデータの内容を変更する場合に、特に効果を奏する。
【００４７】
ステップＳ１０２において、操作受付部１１１は、クライアントシステム１０１による操作を入力装置によりイベントとして受け付ける。具体的には、操作受付部１１１は、クライアントシステム１０１からの要求を受け付け、イベント種別対応表１３２（図４参照）からイベント種別を決定し、イベント番号付加部１１２へイベント種別とデータ内容等を含むデータ１３３（図５参照）を通知する。このとき、操作受付部１１１は、依頼元（クライアントシステム１０１）ごとに設定されるイベント種別対応表１３２ａ（図４参照）を利用しても構わない。そして、操作受付部１１１は、補足情報として、どのクライアントシステム１０１から依頼を受けたのかという依頼元情報や、その他の情報を付加したデータ１３３を通知しても構わない。
【００４８】
一例として、操作受付部１１１は、記憶装置に予め記憶されたイベント種別対応表１３２を参照して、個人情報、組織情報、配属情報を更新する操作に対応するイベント種別が一括更新であると判断し、この操作を１つのイベントとして受け付ける。そして、操作受付部１１１は、イベント種別として一括更新を示し、データ内容として個人１のレコード、組織１のレコード、配属１のレコードの更新内容（例えば、個人１の年齢、組織１の名称、個人１の配属先）を含むデータ１３３をイベント番号付加部１１２に渡す。
【００４９】
ステップＳ１０３において、イベント番号付加部１１２は、操作受付部１１１で受け付けられたイベントに対して一意のイベント番号を処理装置により割り当てる。具体的には、まず、イベント番号付加部１１２では、操作受付部１１１より受信したデータ１３３のまとまりに対して、共通の番号（イベント番号）を付加する。このイベント番号は、全ての操作要求に対して連番をつけることが基本であるが、図４のイベント種別対応表１３２ａの依頼元名のように、クライアントシステム１０１の種別や操作内容ごとに「クライアント１−１」、「データ削除−１」のような形式で割り当てることも可能である。イベント番号としては、番号以外にも記号や漢字等の文字も、イベント番号間で重複するものがなければ、割り当てることが可能である。共通のイベント番号を付加する対象は、データベース１０２にコミットする単位、即ちデータ間に整合性の取れている範囲とする。なお、データ１件で整合性が取れている場合（例えば、既存の個人の新たな配属先として既存の組織を指定する場合）は、１件の単位でイベント番号を付加することも可能である。次に、イベント番号付加部１１２は、イベント番号を付加したデータ１３４（図５参照）をデータ操作部１１３へ送付する。
【００５０】
一例として、イベント番号付加部１１２は、操作受付部１１１で受け付けられたイベントに対してイベント番号「１」を処理装置により割り当てる。そして、イベント番号付加部１１２は、イベント番号として「１」を示し、データ内容として個人１のレコード、組織１のレコード、配属１のレコードの更新内容（例えば、個人１の年齢、組織１の名称、個人１の配属先）を含むデータ１３４をデータ操作部１１３に渡す。
【００５１】
図６は、データベース１０２で保持される配属情報のテーブル１３５，１３５ａの例を示す図である。図７は、イベント番号と対象レコード（データ識別子の一例）と世代番号の対応を示した世代管理テーブル１３６（世代管理部の一例）、イベント番号付加部１１２からイベント通知部１１４へ通知されるデータ１３７の例を示す図である。
【００５２】
データベース１０２で保持される配属情報のテーブル１３５（図６参照）では、個人１、個人２、・・・の１件１件のユーザに対し、更新があった際に、更新履歴を世代として記録しておく。なお、配属情報の全体において１件のユーザ（１人の個人）でも更新があった場合、世代が変わったとする管理方式でテーブル１３５ａ（図６参照）を構成しても構わない。
【００５３】
ステップＳ１０４において、データ操作部１１３は、操作受付部１１１で受け付けられたイベントに基づいてデータベース１０２に記憶された複数のデータの内容を変更する。そして、データ操作部１１３は、内容を変更したデータごとに、新たな世代番号を処理装置により割り当ててデータベース１０２に記憶させる。具体的には、データ操作部１１３は、イベント番号付加部１１２から受信したデータ１３４を基に、データベース１０２に対して操作を行う。データベース１０２の操作の際は、操作内容の結果のみをデータベース１０２として登録するのではなく、更新後の情報とともに、更新前の情報の履歴を世代としてデータベース１０２に保存する。世代の管理単位は、レコード単位（図６のテーブル１３５）、テーブル単位（図６のテーブル１３５ａ）等、システムの状況に合わせ設定することが可能である。なお、ここでは、「レコード」という語を、配属情報のテーブル１３５に含まれる個人ごとのデータという意味で用いている（個人情報、組織情報についても同様である）。例えば、個人１の配属先が組織１（世代１）から組織２（世代２）に変わり、再び組織１（世代３）に戻ったことを示すデータ全体が１つの「レコード」である。また、ここで「テーブル単位」というとき、「テーブル」という語を、配属情報のテーブル１３５ａに含まれる更新時点ごとのデータという意味で用いている。例えば、個人１の配属先が組織１から組織２に変わった時点における個人１、個人２、・・・のデータ（世代２）全体が１つの「テーブル」であり、個人１の配属先が再び組織１に戻った時点における個人１、個人２、・・・のデータ（世代３）全体が１つの「テーブル」である。
【００５４】
一例として、データ操作部１１３は、データベース１０２に記憶された個人１のレコード、組織１のレコード、配属１のレコードを更新する（例えば、個人１の年齢、組織１の名称、個人１の配属先を更新する）。そして、データ操作部１１３は、更新後の個人１のレコード、更新後の組織１のレコード、更新後の配属１のレコードのそれぞれに対して、新たな世代番号を処理装置により割り当ててデータベース１０２に記憶させる（例えば、個人１の配属先が組織１になったことを示すデータを、世代３に対応付けて配属情報のテーブル１３５に記憶させる）。
【００５５】
次に、世代管理テーブル１３６（図７参照）は、イベント番号付加部１１２で割り当てられたイベント番号と、データ操作部１１３で内容が変更された複数のデータを各々識別する複数のデータ識別子と、データ操作部１１３で当該複数のデータに各々割り当てられた複数の世代番号とを対応付けて記憶装置により記憶する。具体的には、データ操作部１１３は、データそのものの登録だけでなく、世代管理テーブル１３６に、あるイベント番号の操作によって、どのレコードのどの世代を配信対象とすればよいのかを登録する。このように、世代管理テーブル１３６には、入手したイベント番号に対し、どの配信対象のどの世代のレコードを配信すべきかが記載される。
【００５６】
一例として、世代管理テーブル１３６は、イベント番号「１」と、個人１のレコードを識別するデータ識別子と、更新された個人１のレコードに割り当てられた世代２とを対応付けて記憶する。また、世代管理テーブル１３６は、イベント番号「１」と、組織１のレコードを識別するデータ識別子と、更新された組織１のレコードに割り当てられた世代２とを対応付けて記憶する。また、世代管理テーブル１３６は、イベント番号「１」と、配属１（個人１の配属先）のレコードを識別するデータ識別子と、更新された配属１のレコードに割り当てられた世代３とを対応付けて記憶する。
【００５７】
ステップＳ１０５において、イベント通知部１１４は、イベント番号付加部１１２で割り当てられたイベント番号を出力装置により出力する。具体的には、イベント番号付加部１１２は、データベース１０２へのデータのコミットが行われた後に、イベント通知部１１４へイベント通知を要求するデータ１３７（図７参照）を出す。その後、イベント通知部１１４は、イベント制御装置１２０のイベント受信部１２１へイベントを（例えば、図７のデータ１３７と同様の形式で）通知する。
【００５８】
一例として、イベント通知部１１４は、イベント番号として「１」を示し、イベント種別として一括更新を示すイベント情報（データ１３７と同様）をイベント受信部１２１に渡す。
【００５９】
図８は、イベント種別と、配信先、プロトコル（形式）、配信する内容（配信項目１，２，・・・）、検索順序との対応を示した配信先情報管理表１４１、イベント受信部１２１から配信管理部１２４へ流れるデータ１４２の例を示す図である。
【００６０】
ステップＳ１０６において、イベント受信部１２１は、イベント通知部１１４から出力されたイベント番号を受信する。具体的には、イベント受信部１２１は、イベント通知部１１４からイベント情報（データ１３７と同様）を受信した後、配信管理部１２４にイベント番号及びイベント種別を含むデータ１４２（図８参照）を送信し、配信が開始されることを通知する。このとき、イベント受信部１２１は、予めどの配信先へ配信が行われるかを配信先情報管理表１４１（図８参照）により抽出し、イベント番号、配信先、イベント種別の組み合わせを通知してもよい。また、イベント番号、配信先、イベント種別の組み合わせに対し番号を割り当ててもよい。イベント受信部１２１は、整合性検索要求部１２２、データ送信部１２３に対し、イベント種別を基に配信先情報管理表１４１で示された配信先へ配信する情報（配信項目等）を取得し、配信するように要求する。このとき、イベント受信部１２１は、イベント番号と配信先の情報及び配信先に適用される検索ルールを用いるように要求する。
【００６１】
図９は、イベント番号とそのイベント番号の配信の結果との対応を示した配信履歴テーブル１４３，１４３ａ、整合性検索要求部１２２からデータ送信部１２３へ流れるデータ１４４、配信先システム１０３へと配信される配信情報１４５の例を示す図である。
【００６２】
ステップＳ１０７において、配信管理部１２４は、イベント受信部１２１で受信されたイベント番号を記憶装置により記憶する。具体的には、配信管理部１２４は、配信履歴テーブル１４３（図９参照）に、イベント番号とイベント種別の情報を登録する。なお、配信管理部１２４は、配信先情報や配信番号等の情報を追加した配信履歴テーブル１４３ａ（図９参照）を管理してもよいし、確実にリカバリ配信を実現できるのであれば（配信先が１つのみの場合等）、イベント番号のみを配信履歴テーブル１４３に記録してもよい。
【００６３】
ステップＳ１０８において、整合性検索要求部１２２は、イベント受信部１２１で受信されたイベント番号をデータベース管理装置１１０のデータセット検索部１１５に入力する。具体的には、整合性検索要求部１２２は、イベントを受け付けた際に、配信先情報管理表１４１を基にして、該当する検索順序及び配信項目で検索するようデータセット検索部１１５に要求する。なお、データセット検索部１１５への要求は、検索順序の１番目から１つずつ順番に行ってもよいし（この場合、検索順序を通知しなくてよい）、一括で行ってもよい（この場合、検索順序を通知しなければならない）。なお、検索順序とは、各配信先システム１０３において、その順序でデータが登録、更新、削除等されなければ、データの整合性が取れなくなる等の問題が生じるものをいう。
【００６４】
ステップＳ１０９〜Ｓ１１１において、データセット検索部１１５は、イベント通知部１１４から出力されたイベント番号が入力されると、入力されたイベント番号に対応する複数のデータ識別子と複数の世代番号とを世代管理テーブル１３６から取得する。そして、データセット検索部１１５は、データベース１０２を検索して、世代管理テーブル１３６から取得した複数のデータ識別子の各々に対応するデータの内容のうち、世代管理テーブル１３６から取得した複数の世代番号の各々に対応する内容を取得する。具体的には、データセット検索部１１５は、ステップＳ１０９で要求を受け付け、ステップＳ１１０で要求に見合う形でデータベース１０２の検索を行う。この際に、世代管理テーブル１３６を参照し、取得したイベント番号の対象となる世代のレコードから情報を取得する。データセット検索部１１５は、ステップＳ１１１で検索結果を、イベント制御装置１２０の整合性検索要求部１２２に通知する。
【００６５】
一例として、データセット検索部１１５は、イベント番号「１」に対応するデータ識別子と世代番号との組み合わせとして、個人１のレコードを識別するデータ識別子と世代２との組み合わせ、組織１のレコードを識別するデータ識別子と世代２との組み合わせ、配属１（個人１の配属先）のレコードを識別するデータ識別子と世代３との組み合わせを、世代管理テーブル１３６から取得する。そして、データセット検索部１１５は、データベース１０２を検索して、世代２の個人１のレコード、世代２の組織１のレコード、世代３の配属１のレコードを取得する。このとき、データセット検索部１１５は、データベース１０２を、整合性検索要求部１２２から指定された検索順序で検索して、レコードを取得する度に、取得したレコードを即時に整合性検索要求部１２２へ返信する。例えば、データセット検索部１１５は、世代２の個人１のレコード、世代２の組織１のレコード、世代３の配属１のレコードを、順番に１つずつ取得するのと同時に整合性検索要求部１２２へ送信する。これにより、リアルタイム（即ち、高速な）配信を可能とする。
【００６６】
ステップＳ１１２において、整合性検索要求部１２２は、データベース１０２に記憶された複数のデータの内容のうち、データセット検索部１１５で取得された内容を受信する。具体的には、整合性検索要求部１２２は、検索結果を受信しデータ送信部１２３へ配信対象となるデータ内容とイベント番号を含むデータ１４４（図９参照）を通知する。このとき、整合性検索要求部１２２は、検索結果を受信する度に、そのデータ内容を含むデータ１４４を即時にデータ送信部１２３に渡す。これにより、リアルタイム（即ち、高速な）配信を可能とする。
【００６７】
ステップＳ１１３において、データ送信部１２３は、整合性検索要求部１２２で受信された内容を複数の配信先システム１０３へ配信する。具体的には、データ送信部１２３は、受け付けたデータを、配信先情報管理表１４１の配信先を基に、該当する配信先システム１０３へと整合性の取れた配信情報１４５（図９参照）に変換した上で配信する。この際に、データ送信部１２３は、配信先の通信プロトコルに合わせてデータを変換する。また、このとき、データ送信部１２３は、整合性検索要求部１２２で受信された内容を、整合性検索要求部１２２から受け取る度に、即時に配信する。即ち、データ送信部１２３は、整合性検索要求部１２２で受信された内容を、データベース１０２に記憶された複数のデータ間で予め定められた順序で配信する。これにより、リアルタイム（即ち、高速な）配信を可能とする。
【００６８】
ステップＳ１１４において、配信先システム１０３は、配信情報１４５を受信し、自身のシステムへ反映させる。前述したように、配信先の形態は、データベース、データ受信とともにメールを送信するようなメールサーバ、データ受信後に任意ファイルを操作するようなシステム等、どのようなものでもよい。
【００６９】
ステップＳ１１５において、データ送信部１２３は、配信先システム１０３への配信結果（「配信成功」／「配信失敗」／「配信一部失敗」／「通信不可」等）を、配信管理部１２４に通知し、配信管理部１２４は配信結果を配信履歴テーブル１４３へ記入する。
【００７０】
図１０は、情報配信システム１００による再配信の動作を示すフローチャートである。以下、配信に失敗したイベントに対する再配信の動作について図１０を用いて説明する。
【００７１】
ステップＳ１２０〜Ｓ１２２において、配信管理部１２４は、記憶装置により記憶したイベント番号に対応する複数のデータの内容が正常に配信されたかどうかを処理装置により判定する。具体的には、ステップＳ１２０で、配信管理部１２４は、配信履歴テーブル１４３の中から、配信結果が「配信失敗」又は一定時間以上「配信中」となっている等、配信が成功になっていないイベント番号及び配信先の組み合わせの配信があるかどうかを検索する。なお、リカバリを実行するタイミングは、ステップＳ１１５で配信に失敗した直後でもよいし、決まった時間に自動起動してもよいし、外部からの要求を受け付けたタイミングでもよい。ステップＳ１２１で、配信管理部１２４は、上記検索の結果に基づき、再配信する必要のある配信情報１４５があるか判定する。配信対象が存在した場合、ステップＳ１２２において、配信管理部１２４は、整合性検索要求部１２２に対し、イベント番号を通知する。
【００７２】
この後の具体的な動作は、ステップＳ１０８〜Ｓ１１５と同様である。つまり、配信管理部１２４（配信履歴テーブル１４３）に記憶されたイベント番号に対応する複数のデータの内容が複数の配信先システム１０３のいずれかへ正常に配信されなかったと配信管理部１２４で判定された場合、整合性検索要求部１２２は、当該イベント番号をデータベース管理装置１１０のデータセット検索部１１５に再び入力する。そして、整合性検索要求部１２２は、データベース１０２に記憶された複数のデータの内容のうち、データセット検索部１１５で取得された内容を再び受信する。データ送信部１２３は、整合性検索要求部１２２で再び受信された内容を、当該内容が正常に配信されなかったと配信管理部１２４で判定された配信先システム１０３へ配信する。
【００７３】
以上のように、本実施の形態によれば、データベース１０２内で依存関係のあるデータが更新された場合、その更新後のデータをいつでも確実に整合性の取れたデータとして提供することが可能となる。また、複数のクライアントシステム１０１からのデータベース１０２の操作要求の受付と、各配信先システム１０３への情報配信をデータベース１０２にロックをかけずに並行して実行することができる。また、依存関係のあるデータ群を投入した場合でも、データベース１０２の世代管理を行うことにより、整合性を保ったまま各配信先システム１０３への配信を行える。つまり、本実施の形態では、データベース１０２を世代管理し、世代番号と配信のイベント番号を対応させることにより、クライアントシステム１０１から受け付けた整合性のあるデータ操作要求に対し、データベース１０２の操作の実行、及び、操作結果に対し整合性を保った状態での各配信先システム１０３への配信が可能である。
【００７４】
以上説明したように、本実施の形態に係る情報配信システム１００は、データそのものだけでなくデータ変更の履歴情報を登録したデータベース１０２と、データベース１０２へのコミットのタイミングで番号をデータに割り振るイベント番号付加部１１２と、データベース１０２に登録内容と内容に対応した世代番号を登録するデータ操作部１１３と、イベント番号に対応した世代のデータを検索するデータセット検索部１１５と、配信するデータセットに配信すべき順序が存在する場合にその順序どおりに検索を実行するよう要求する整合性検索要求部１２２と、配信に失敗したイベント番号を基に再配信の要求を行う配信管理部１２４とを兼ね備える。
【００７５】
このように、本実施の形態では、データ更新要求がクライアントシステム１０１から来たタイミングで単純に番号を割り当てるのではなく、データベース１０２へコミットする単位で共通のイベント番号を付加する。なお、前述したように、番号付けも全受付を対象にして連番にさせる必要はなく、クライアントの種別や操作内容等によってイベント番号の割り付けを変更させることも可能である。
【００７６】
その後、実際に付加されたイベント番号に紐付けられたデータをデータベース１０２に投入する際に、データの履歴情報（世代）も同時に登録する。
【００７７】
単純にイベント番号を付加するだけでは、配信最中のデータに対して更新が行われた際に、配信先システム１０３で受け取るデータの整合性が保障されない。一方、本実施の形態の手法では、配信中にデータの更新が行われたとしても、配信途中のデータに関しては更新前の世代のデータを配信し、その後、改めて更新後のデータを配信することで、最終的に配信されるデータの整合性を保つことが可能である。
【００７８】
また、従来のように、配信すべき対象があるかどうかを、配信を行うシステムがデータベース１０２やデータベース１０２の更新情報が記載された場所に都度確認を取りにいくのでは、リアルタイム配信を実現できない。本実施の形態では、更新内容の配信先システム１０３への配信のトリガをイベント通知にすることで、リアルタイム性を保障する。
【００７９】
また、付加したイベント番号と配信先システム１０３について配信結果の管理を行うことで、無駄のないリカバリ配信が可能となる。
【００８０】
実施の形態２．
本実施の形態について、主に実施の形態１との差異を説明する。
【００８１】
図１１は、本実施の形態に係る情報配信システム１００の構成を示すブロック図である。
【００８２】
図１１において、イベント制御装置１２０は、イベント受信部１２１、整合性検索要求部１２２、データ送信部１２３の組み合わせ、即ち、配信ルート２２１を複数有する。配信ルート２２１は、配信先システム１０３、配信するデータの種類等に応じて使い分けられる。図１１では、複数の配信ルート２２１を配信ルート１、・・・、配信ルートｎとして表している。また、必須ではないが、データベース管理装置１１０は、操作受付部１１１を複数有する。図１１では、複数の操作受付部１１１を操作受付部１、・・・、操作受付部ｎとして表している。
【００８３】
このように、本実施の形態において、情報配信システム１００は、実施の形態１と異なり、操作受付部１１１、配信ルート２２１が複数となる構成となる。
【００８４】
データベース管理装置１１０の操作受付部１１１は、クライアントシステム１０１からのデータベース１０２の操作要求を受け付け、要求元のクライアントシステム１０１と操作内容だけでなく、受付ＵＲＬ（Ｕｎｉｆｏｒｍ・Ｒｅｓｏｕｒｃｅ・Ｌｏｃａｔｏｒ）によりイベント種別（例えば、依存関係のあるデータの一括登録、一括更新、一括削除）を判断する。操作受付部１１１は、それぞれ予め設定された受付ＵＲＬに対応する受信口を持っており、この受付ＵＲＬはデータ操作内容及びデータの種類によって定まる個数だけ存在する。
【００８５】
データベース管理装置１１０のイベント通知部１１４は、イベント番号付加部１１２より送信されたイベント情報を基に、複数ある配信ルート２２１のうちどの配信ルート２２１に対しイベント番号を送付するのかを判定し、対象となる配信ルート２２１へ、イベント番号を送付する機能を持つ。
【００８６】
以下、情報配信システム１００の動作について図３を用いて説明する。
【００８７】
図１２は、依頼元のクライアントシステム１０１（依頼元名）と受付ＵＲＬとの組み合わせごとに、データ操作の種類（データ操作内容）やデータの種類とイベント種別との対応を示したイベント種別対応表１３２ｂ、配信ルート２２１ごとに、イベント種別と、配信先、プロトコル（形式）、配信する内容（配信項目１，２，・・・）、検索順序との対応を示した配信先情報管理表１４１ａの例を示す図である。
【００８８】
ステップＳ１０１において、クライアントシステム１０１は、データベース１０２への整合性の取れた（依存関係のある）データの操作要求をデータベース管理装置１１０の操作受付部１１１のいずれかへ出す。この際、操作内容１３１（図４参照）としては、データベース１０２へのレコードの追加（新規登録）、削除、更新、検索、参照等の操作が考えられるが、本実施の形態でも、実施の形態１と同様に、複数のレコードの追加、削除、更新といった操作が対象となる。クライアントシステム１０１は、どの受付ＵＲＬへ要求を送信するのかを、データベース１０２の操作内容や操作するデータの種類により決定する。なお、操作受付部１１１の数、及び、それぞれの操作受付部１１１が持つ受付ＵＲＬの数は、データ操作内容、データの種類、クライアントシステム１０１の種別等により任意に決めることができる。
【００８９】
ステップＳ１０２において、操作受付部１１１は、クライアントシステム１０１からの要求を受け付け、イベント種別対応表１３２ｂ（図１２参照）からイベント種別を決定し、イベント番号付加部１１２へイベント種別とデータ内容等を含むデータ１３３（図５参照）を通知する。このとき、操作受付部１１１は、補足情報として、どのクライアントシステム１０１から依頼を受けたのかという依頼元情報や、その他の情報を付加したデータ１３３を通知しても構わない。
【００９０】
ステップＳ１０３において、まず、イベント番号付加部１１２では、操作受付部１１１より受信したデータ１３３のまとまりに対して、共通の番号（イベント番号）を付加する。このイベント番号は、全ての操作要求に対して連番をつけることが基本であるが、図１２のイベント種別対応表１３２ｂの依頼元名のように、クライアントシステム１０１の種別や操作内容ごとに「クライアント１−１」、「データ削除−１」のような形式で割り当てることも可能である。イベント番号としては、番号以外にも記号や漢字等の文字も、イベント番号間で重複するものがなければ、割り当てることが可能である。共通のイベント番号を付加する対象は、データベース１０２にコミットする単位、即ちデータ間に整合性の取れている範囲とする。なお、データ１件で整合性が取れている場合（例えば、既存の個人の新たな配属先として既存の組織を指定する場合）は、１件の単位でイベント番号を付加することも可能である。次に、イベント番号付加部１１２は、イベント番号を付加したデータ１３４（図５参照）をデータ操作部１１３へ送付する。
【００９１】
ステップＳ１０４において、データ操作部１１３は、イベント番号付加部１１２から受信したデータ１３４を基に、データベース１０２に対して操作を行う。データベース１０２の操作の際は、操作内容の結果のみをデータベース１０２として登録するのではなく、更新後の情報とともに、更新前の情報の履歴を世代としてデータベース１０２に保存する。次に、データ操作部１１３は、データそのものの登録だけでなく、世代管理テーブル１３６（図７参照）に、あるイベント番号の操作によって、どのレコードのどの世代を配信対象とすればよいのかを登録する。
【００９２】
ステップＳ１０５において、イベント番号付加部１１２は、データベース１０２へのデータのコミットが行われた後に、イベント通知部１１４へイベント通知を要求するデータ１３７（図７参照）を出す。その後、イベント通知部１１４は、イベント種別の情報を基にして、配信先情報管理表１４１ａ（図１２参照）より、イベント制御装置１２０のどの配信ルート２２１へイベントを通知するのかを決定し、通知すべき配信ルート２２１全てのイベント受信部１２１へイベントを（例えば、図７のデータ１３７と同様の形式で）通知する。
【００９３】
ステップＳ１０６において、イベント受信部１２１は、イベント通知部１１４からイベント情報（データ１３７と同様）を受信した後、配信管理部１２４にイベント番号及びイベント種別を含むデータ１４２（図８参照）を送信し、配信が開始されることを通知する。また、イベント受信部１２１は、整合性検索要求部１２２、データ送信部１２３に対し、イベント種別を基に配信先情報管理表１４１ａで示された配信先へ配信する情報（配信項目等）を取得し、配信するように要求する。このとき、イベント受信部１２１は、イベント番号と配信先の情報及び配信先に適用される検索ルールを用いるように要求する。
【００９４】
ステップＳ１０７において、配信管理部１２４は、配信履歴テーブル１４３（図９参照）に、イベント番号とイベント種別の情報を登録する。このとき、配信管理部１２４は、配信履歴テーブル１４３に、さらに、どの配信ルート２２１でイベントを受け付けたか等の情報を登録することが望ましい。なお、配信管理部１２４は、確実にリカバリ配信を実現できるのであれば（配信先が１つのみの場合等）、イベント番号のみを配信履歴テーブル１４３に記録したり、イベント番号と配信ルート２２１に関する情報のみを配信履歴テーブル１４３に記録してもよい。
【００９５】
ステップＳ１０８において、整合性検索要求部１２２は、イベントを受け付けた際に、配信先情報管理表１４１ａを基にして、自身の所属する配信ルート２２１に対応する検索順序及び配信項目で検索するようデータセット検索部１１５に要求する。なお、データセット検索部１１５への要求は、検索順序の１番目から１つずつ順番に行ってもよいし（この場合、検索順序を通知しなくてよい）、一括で行ってもよい（この場合、検索順序を通知しなければならない）。
【００９６】
データセット検索部１１５は、ステップＳ１０９で要求を受け付け、ステップＳ１１０で要求に見合う形でデータベース１０２の検索を行う。この際に、世代管理テーブル１３６を参照し、取得したイベント番号の対象となる世代のレコードから情報を取得する。データセット検索部１１５は、ステップＳ１１１で検索結果を、イベント制御装置１２０の整合性検索要求部１２２に通知する。
【００９７】
ステップＳ１１２において、整合性検索要求部１２２は、検索結果を受信しデータ送信部１２３へ配信対象となるデータ内容とイベント番号を含むデータ１４４（図９参照）を通知する。
【００９８】
ステップＳ１１３において、データ送信部１２３は、受け付けたデータを、配信先情報管理表１４１ａの配信先を基に、該当する配信先システム１０３へと整合性の取れた配信情報１４５（図９参照）に変換した上で配信する。この際に、データ送信部１２３は、配信先の通信プロトコルに合わせてデータを変換する。
【００９９】
ステップＳ１１４において、配信先システム１０３は、配信情報１４５を受信し、自身のシステムへ反映させる。前述したように、配信先の形態は、データベース、データ受信とともにメールを送信するようなメールサーバ、データ受信後に任意ファイルを操作するようなシステム等、どのようなものでもよい。
【０１００】
ステップＳ１１５において、データ送信部１２３は、配信先システム１０３への配信結果（「配信成功」／「配信失敗」／「配信一部失敗」／「通信不可」等）を、配信管理部１２４に通知し、配信管理部１２４は配信結果を配信履歴テーブル１４３へ記入する。
【０１０１】
以下、配信に失敗したイベントに対する再配信の動作について図１０を用いて説明する。
【０１０２】
ステップＳ１２０で、配信管理部１２４は、配信履歴テーブル１４３の中から、配信結果が「配信失敗」又は一定時間以上「配信中」となっている等、配信が成功になっていないイベント番号及び配信先の組み合わせの配信があるかどうかを検索する。なお、リカバリを実行するタイミングは、ステップＳ１１５で配信に失敗した直後でもよいし、決まった時間に自動起動してもよいし、外部からの要求を受け付けたタイミングでもよい。ステップＳ１２１で、配信管理部１２４は、上記検索の結果に基づき、再配信する必要のある配信情報１４５があるか判定する。配信対象が存在した場合、ステップＳ１２２において、配信管理部１２４は、整合性検索要求部１２２に対し、イベント番号を通知する。
【０１０３】
この後の具体的な動作は、ステップＳ１０８〜Ｓ１１５と同様である。
【０１０４】
以上のように、本実施の形態では、各配信先システム１０３への配信処理をパラレルに実行することが可能なので、配信の待ち時間が減少し、より即時性の高い配信が実現される。
【０１０５】
配信用のルートが１本しか存在しないのでは、配信先システム１０３の数が多くなるにつれ、各配信先システム１０３間でのデータ受領のタイミングの差が大きくなってしまう。上記のように、本実施の形態では、配信ルート２２１を複数用意することによって、各配信先システム１０３への配信処理をパラレルに実行することが可能なので、配信の待ち時間が減少される。
【０１０６】
実施の形態３．
本実施の形態について、主に実施の形態２との差異を説明する。
【０１０７】
図１３は、本実施の形態に係る情報配信システム１００の構成を示すブロック図である。
【０１０８】
本実施の形態では、実施の形態２と異なり、イベント制御装置１２０が配信先システム１０３へデータを配信するのではなく、イベント制御装置１２０は配信先システム１０３へイベント番号のみを通知し、配信先システム１０３がイベント番号を基にデータベース管理装置１１０に情報を要求する。
【０１０９】
図１４は、情報配信システム１００の動作（本実施の形態に係る情報配信方法（データベース管理方法を含む））を示すフローチャートである。以下、情報配信システム１００の動作について図１４を用いて説明する。
【０１１０】
ステップＳ３０１〜Ｓ３１０については、実施の形態２のステップＳ１０１〜Ｓ１１０と同様である。
【０１１１】
ステップＳ３１１において、データセット検索部１１５は、ステップＳ３１０でデータベース１０２の検索を行った結果を、イベント制御装置１２０の整合性検索要求部１２２に通知する代わりに、記憶装置により保持しておく。データセット検索部１１５は、整合性検索要求部１２２には、検索が完了したことのみを通知する。
【０１１２】
ステップＳ３１２において、整合性検索要求部１２２は、検索完了の通知を受け、データ送信部１２３へイベント番号を送信する。データ送信部１２３は、配信先システム１０３へイベント番号を送信する。
【０１１３】
ステップＳ３１３において、配信先システム１０３は、イベント番号を取得する。ステップＳ３１４において、配信先システム１０３は、データベース管理装置１１０のデータセット検索部１１５にイベント番号を通知してデータを要求する。
【０１１４】
ステップＳ３１５において、データセット検索部１１５は、要求を受け付ける。ステップＳ３１６において、データセット検索部１１５は、保持していた検索結果を配信先システム１０３へ配信する。
【０１１５】
ステップＳ３１７において、配信先システム１０３は、データを取得する。ステップＳ３１８において、配信先システム１０３は、配信結果をイベント制御装置１２０のデータ送信部１２３へ返す。
【０１１６】
ステップＳ３１９において、データ送信部１２３は、配信管理部１２４へ配信結果を通知する。
【０１１７】
本実施の形態では、リカバリについても、実際のリカバリ対象のデータをイベント制御装置１２０に通すのではなく、配信先システム１０３が直接データベース管理装置１１０のデータセット検索部１１５とやり取りすることにより実現される。
【０１１８】
以上により、データベース管理装置１１０、イベント制御装置１２０が複数のサーバで構成されている場合、必要以上のサーバ間データの受け渡し量を削減することが可能となり、サーバシステムの負荷を減らすことが可能となる。
【０１１９】
配信すべきデータ量が多くなった場合、システムのサーバ内で配信情報の受け渡しをすると、システム中を流れるデータ量が多くなりサーバに負荷がかかる。そこで、本実施の形態では、配信先システム１０３には更新が行われたことのみを通知し、データの取得は配信先システム１０３がデータベース管理装置１１０に要求することで、サーバへの負荷を減らすことが可能となる。
【０１２０】
実施の形態４．
本実施の形態について、主に実施の形態２との差異を説明する。
【０１２１】
図１５は、本実施の形態に係る情報配信システム１００の構成を示すブロック図である。
【０１２２】
本実施の形態では、リカバリ配信を行う際に、配信失敗となった配信ルート２２１に再配信要求を出すのではなく、情報配信システム１００が別に持つ再配信用の配信ルートであるリカバリ配信ルート４５１に再配信要求を出す。
【０１２３】
図１５において、リカバリ要求元４５０は、リカバリ配信ルート４５１にリカバリ配信を要求する。リカバリ要求元４５０には、情報配信システム１００の管理者、クライアントシステム１０１（のユーザ）、配信先システム１０３（のユーザ）等がなり得る。
【０１２４】
リカバリ配信ルート４５１は、リカバリ受付部４５２のほか、他の配信ルート２２１と同様の整合性検索要求部１２２とデータ送信部１２３とを有する。なお、リカバリ配信ルート４５１は、リカバリ対象となるイベント種別や配信先システム１０３ごとに用意することも可能である。
【０１２５】
リカバリ受付部４５２は、リカバリ要求元４５０からのリカバリ要求を受け付ける。
【０１２６】
情報配信システム１００の通常の配信動作については、図３に示した実施の形態２のものと同様である。
【０１２７】
図１６は、情報配信システム１００による再配信の動作を示すフローチャートである。以下、配信に失敗したイベントに対する再配信の動作について図１６を用いて説明する。
【０１２８】
ステップＳ４０１において、リカバリ要求元４５０は、リカバリ配信ルート４５１のリカバリ受付部４５２に対しリカバリ配信を要求する。この際、リカバリ受付に対してどの配信ルート２２１のリカバリを要求するのかをリカバリ要求元４５０で指定してもよいし、全てのリカバリ対象のリカバリ配信を要求してもよい。
【０１２９】
ステップＳ４０２において、リカバリ受付部４５２は、配信管理部１２４に対してリカバリ対象の検索を要求する。リカバリ受付部４５２は、外部からのリカバリ要求の受付以外にも、予め指定された時刻や、通常の配信に失敗した直後等も動作してよい。
【０１３０】
ステップＳ４０３において、配信管理部１２４は、配信履歴テーブル１４３ａの中で、今回のリカバリ対象となるイベントのうち、配信結果が「配信失敗」又は一定時間以上「配信中」となっている等、配信が成功になっていないイベント番号及び配信先の組み合わせの配信があるかどうかを検索する。ステップＳ４０４において、配信管理部１２４は、上記検索の結果に基づき、再配信する必要のある配信情報１４５があるか判定する。配信対象が存在した場合、配信管理部１２４は、整合性検索要求部１２２に対し、イベント番号を通知する。
【０１３１】
この後の具体的な動作及びステップＳ４０５〜Ｓ４１１については、実施の形態２のステップＳ１０８〜Ｓ１１５と同様である。
【０１３２】
上記のように、本実施の形態では、イベント制御装置１２０が、整合性検索要求部１２２とデータ送信部１２３との組み合わせを少なくとも２つ（配信ルート２２１及びリカバリ配信ルート４５１）有する。そして、配信管理部１２４（配信履歴テーブル１４３）に記憶されたイベント番号に対応する複数のデータの内容が複数の配信先システム１０３のいずれかへ正常に配信されなかったと配信管理部１２４で判定された場合と、それ以外の場合（正常に配信ができた場合）とで、使用する整合性検索要求部１２２とデータ送信部１２３との組み合わせを切り換える。このように、本実施の形態では、リカバリ配信ルート４５１を通常の配信ルート２２１と別に設けることで、通常の配信の邪魔をせずに並行して（通常の配信に影響を与えることなく）リカバリ配信を実現することが可能となる。
【０１３３】
以上、本発明の実施の形態について説明したが、これらのうち、２つ以上の実施の形態を組み合わせて実施しても構わない。あるいは、これらのうち、１つの実施の形態を部分的に実施しても構わない。あるいは、これらのうち、２つ以上の実施の形態を部分的に組み合わせて実施しても構わない。
【符号の説明】
【０１３４】
１００ 情報配信システム、１０１ クライアントシステム、１０２ データベース、１０３ 配信先システム、１１０ データベース管理装置、１１１ 操作受付部、１１２ イベント番号付加部、１１３ データ操作部、１１４ イベント通知部、１１５ データセット検索部、１２０ イベント制御装置、１２１ イベント受信部、１２２ 整合性検索要求部、１２３ データ送信部、１２４ 配信管理部、１３１ 操作内容、１３２，１３２ａ，１３２ｂ イベント種別対応表、１３３，１３４，１３７，１４２，１４４ データ、１３５，１３５ａ テーブル、１３６ 世代管理テーブル、１４１，１４１ａ 配信先情報管理表、１４３，１４３ａ 配信履歴テーブル、１４５ 配信情報、２２１ 配信ルート、４５０ リカバリ要求元、４５１ リカバリ配信ルート、４５２ リカバリ受付部、９０１ ＬＣＤ、９０２ キーボード、９０３ マウス、９０４ ＦＤＤ、９０５ ＣＤＤ、９０６ プリンタ、９１１ ＣＰＵ、９１２ バス、９１３ ＲＯＭ、９１４ ＲＡＭ、９１５ 通信ボード、９２０ ＨＤＤ、９２１ オペレーティングシステム、９２２ ウィンドウシステム、９２３ プログラム群、９２４ ファイル群。
【特許請求の範囲】
【請求項１】
過去に内容が変更されたデータ群を記憶するデータベースであり、データ群に含まれるデータごとに、データの内容が変更される度に割り当てられる世代番号と、変更された内容とを対応付けて記憶するデータベースを管理するデータベース管理装置であって、
前記データベースに記憶されたデータ群に含まれる複数のデータの内容を変更する操作を入力装置によりイベントとして受け付ける操作受付部と、
前記操作受付部で受け付けられたイベントに対して一意のイベント識別子を処理装置により割り当てるイベント識別子割当部と、
前記操作受付部で受け付けられたイベントに基づいて前記データベースに記憶された複数のデータの内容を変更し、内容を変更したデータごとに、新たな世代番号を処理装置により割り当てて前記データベースに記憶させるデータ操作部と、
前記イベント識別子割当部で割り当てられたイベント識別子と、前記データ操作部で内容が変更された複数のデータを各々識別する複数のデータ識別子と、前記データ操作部で当該複数のデータに各々割り当てられた複数の世代番号とを対応付けて記憶装置により記憶する世代管理部と、
前記イベント識別子割当部で割り当てられたイベント識別子を出力装置により出力するイベント通知部と、
前記イベント通知部から出力されたイベント識別子が入力されると、入力されたイベント識別子に対応する複数のデータ識別子と複数の世代番号とを前記世代管理部から取得し、前記データベースを検索して、取得した複数のデータ識別子の各々に対応するデータの内容のうち、取得した複数の世代番号の各々に対応する内容を取得するデータセット検索部と
を有することを特徴とするデータベース管理装置。
【請求項２】
前記操作受付部は、第１のデータと前記データベースにおいて前記第１のデータから参照される第２のデータとを含む複数のデータの内容を変更する操作を１つのイベントとして受け付け、
前記イベント識別子割当部は、前記操作受付部で受け付けられた１つのイベントに対して１つのイベント識別子を割り当てることを特徴とする請求項１のデータベース管理装置。
【請求項３】
請求項１又は２のデータベース管理装置と、イベント制御装置とを備え、
前記イベント制御装置は、
前記イベント通知部から出力されたイベント識別子を受信するイベント受信部と、
前記イベント受信部で受信されたイベント識別子を前記データセット検索部に入力して、前記データベースに記憶された複数のデータの内容のうち、前記データセット検索部で取得された内容を受信する検索要求部と、
前記検索要求部で受信された内容を複数の配信先システムへ配信するデータ送信部と
を有することを特徴とする情報配信システム。
【請求項４】
前記イベント制御装置は、前記イベント受信部と前記検索要求部と前記データ送信部との組み合わせを複数有することを特徴とする請求項３の情報配信システム。
【請求項５】
前記イベント制御装置は、さらに、前記イベント受信部で受信されたイベント識別子を記憶装置により記憶し、記憶したイベント識別子に対応する複数のデータの内容が正常に配信されたかどうかを処理装置により判定する配信管理部を有し、
前記検索要求部は、前記配信管理部に記憶されたイベント識別子に対応する複数のデータの内容が前記複数の配信先システムのいずれかへ正常に配信されなかったと前記配信管理部で判定された場合、当該イベント識別子を前記データセット検索部に入力して、前記データベースに記憶された複数のデータの内容のうち、前記データセット検索部で取得された内容を再び受信し、
前記データ送信部は、前記検索要求部で再び受信された内容を、当該内容が正常に配信されなかったと前記配信管理部で判定された配信先システムへ配信することを特徴とする請求項３の情報配信システム。
【請求項６】
前記イベント制御装置は、前記検索要求部と前記データ送信部との組み合わせを少なくとも２つ有し、前記配信管理部に記憶されたイベント識別子に対応する複数のデータの内容が前記複数の配信先システムのいずれかへ正常に配信されなかったと前記配信管理部で判定された場合と、それ以外の場合とで前記組み合わせを切り換えることを特徴とする請求項５の情報配信システム。
【請求項７】
前記データ送信部は、前記検索要求部で受信された内容を、前記データベースに記憶された複数のデータ間で予め定められた順序で配信し、
前記データセット検索部は、前記データベースを前記順序で検索することを特徴とする請求項３から６のいずれかの情報配信システム。
【請求項８】
過去に内容が変更されたデータ群を記憶するデータベースであり、データ群に含まれるデータごとに、データの内容が変更される度に割り当てられる世代番号と、変更された内容とを対応付けて記憶するデータベースを管理するデータベース管理方法であって、
コンピュータが、前記データベースに記憶されたデータ群に含まれる複数のデータの内容を変更する操作を入力装置によりイベントとして受け付け、
コンピュータが、受け付けたイベントに対して一意のイベント識別子を処理装置により割り当て、
コンピュータが、受け付けたイベントに基づいて前記データベースに記憶された複数のデータの内容を変更し、内容を変更したデータごとに、新たな世代番号を処理装置により割り当てて前記データベースに記憶させ、
コンピュータが、割り当てたイベント識別子と、内容を変更した複数のデータを各々識別する複数のデータ識別子と、当該複数のデータに各々割り当てた複数の世代番号とを対応付けて記憶装置により記憶し、
コンピュータが、割り当てたイベント識別子を出力装置により出力し、
コンピュータが、出力したイベント識別子が入力されると、入力されたイベント識別子に対応する複数のデータ識別子と複数の世代番号とを記憶装置から取得し、前記データベースを検索して、取得した複数のデータ識別子の各々に対応するデータの内容のうち、取得した複数の世代番号の各々に対応する内容を取得することを特徴とするデータベース管理方法。
【請求項９】
過去に内容が変更されたデータ群を記憶するデータベースであり、データ群に含まれるデータごとに、データの内容が変更される度に割り当てられる世代番号と、変更された内容とを対応付けて記憶するデータベースに接続されたコンピュータを、
前記データベースに記憶されたデータ群に含まれる複数のデータの内容を変更する操作を入力装置によりイベントとして受け付ける操作受付部と、
前記操作受付部で受け付けられたイベントに対して一意のイベント識別子を処理装置により割り当てるイベント識別子割当部と、
前記操作受付部で受け付けられたイベントに基づいて前記データベースに記憶された複数のデータの内容を変更し、内容を変更したデータごとに、新たな世代番号を処理装置により割り当てて前記データベースに記憶させるデータ操作部と、
前記イベント識別子割当部で割り当てられたイベント識別子と、前記データ操作部で内容が変更された複数のデータを各々識別する複数のデータ識別子と、前記データ操作部で当該複数のデータに各々割り当てられた複数の世代番号とを対応付けて記憶装置により記憶する世代管理部と、
前記イベント識別子割当部で割り当てられたイベント識別子を出力装置により出力するイベント通知部と、
前記イベント通知部から出力されたイベント識別子が入力されると、入力されたイベント識別子に対応する複数のデータ識別子と複数の世代番号とを前記世代管理部から取得し、前記データベースを検索して、取得した複数のデータ識別子の各々に対応するデータの内容のうち、取得した複数の世代番号の各々に対応する内容を取得するデータセット検索部
として機能させるためのプログラム。
【請求項１】
過去に内容が変更されたデータ群を記憶するデータベースであり、データ群に含まれるデータごとに、データの内容が変更される度に割り当てられる世代番号と、変更された内容とを対応付けて記憶するデータベースを管理するデータベース管理装置であって、
前記データベースに記憶されたデータ群に含まれる複数のデータの内容を変更する操作を入力装置によりイベントとして受け付ける操作受付部と、
前記操作受付部で受け付けられたイベントに対して一意のイベント識別子を処理装置により割り当てるイベント識別子割当部と、
前記操作受付部で受け付けられたイベントに基づいて前記データベースに記憶された複数のデータの内容を変更し、内容を変更したデータごとに、新たな世代番号を処理装置により割り当てて前記データベースに記憶させるデータ操作部と、
前記イベント識別子割当部で割り当てられたイベント識別子と、前記データ操作部で内容が変更された複数のデータを各々識別する複数のデータ識別子と、前記データ操作部で当該複数のデータに各々割り当てられた複数の世代番号とを対応付けて記憶装置により記憶する世代管理部と、
前記イベント識別子割当部で割り当てられたイベント識別子を出力装置により出力するイベント通知部と、
前記イベント通知部から出力されたイベント識別子が入力されると、入力されたイベント識別子に対応する複数のデータ識別子と複数の世代番号とを前記世代管理部から取得し、前記データベースを検索して、取得した複数のデータ識別子の各々に対応するデータの内容のうち、取得した複数の世代番号の各々に対応する内容を取得するデータセット検索部と
を有することを特徴とするデータベース管理装置。
【請求項２】
前記操作受付部は、第１のデータと前記データベースにおいて前記第１のデータから参照される第２のデータとを含む複数のデータの内容を変更する操作を１つのイベントとして受け付け、
前記イベント識別子割当部は、前記操作受付部で受け付けられた１つのイベントに対して１つのイベント識別子を割り当てることを特徴とする請求項１のデータベース管理装置。
【請求項３】
請求項１又は２のデータベース管理装置と、イベント制御装置とを備え、
前記イベント制御装置は、
前記イベント通知部から出力されたイベント識別子を受信するイベント受信部と、
前記イベント受信部で受信されたイベント識別子を前記データセット検索部に入力して、前記データベースに記憶された複数のデータの内容のうち、前記データセット検索部で取得された内容を受信する検索要求部と、
前記検索要求部で受信された内容を複数の配信先システムへ配信するデータ送信部と
を有することを特徴とする情報配信システム。
【請求項４】
前記イベント制御装置は、前記イベント受信部と前記検索要求部と前記データ送信部との組み合わせを複数有することを特徴とする請求項３の情報配信システム。
【請求項５】
前記イベント制御装置は、さらに、前記イベント受信部で受信されたイベント識別子を記憶装置により記憶し、記憶したイベント識別子に対応する複数のデータの内容が正常に配信されたかどうかを処理装置により判定する配信管理部を有し、
前記検索要求部は、前記配信管理部に記憶されたイベント識別子に対応する複数のデータの内容が前記複数の配信先システムのいずれかへ正常に配信されなかったと前記配信管理部で判定された場合、当該イベント識別子を前記データセット検索部に入力して、前記データベースに記憶された複数のデータの内容のうち、前記データセット検索部で取得された内容を再び受信し、
前記データ送信部は、前記検索要求部で再び受信された内容を、当該内容が正常に配信されなかったと前記配信管理部で判定された配信先システムへ配信することを特徴とする請求項３の情報配信システム。
【請求項６】
前記イベント制御装置は、前記検索要求部と前記データ送信部との組み合わせを少なくとも２つ有し、前記配信管理部に記憶されたイベント識別子に対応する複数のデータの内容が前記複数の配信先システムのいずれかへ正常に配信されなかったと前記配信管理部で判定された場合と、それ以外の場合とで前記組み合わせを切り換えることを特徴とする請求項５の情報配信システム。
【請求項７】
前記データ送信部は、前記検索要求部で受信された内容を、前記データベースに記憶された複数のデータ間で予め定められた順序で配信し、
前記データセット検索部は、前記データベースを前記順序で検索することを特徴とする請求項３から６のいずれかの情報配信システム。
【請求項８】
過去に内容が変更されたデータ群を記憶するデータベースであり、データ群に含まれるデータごとに、データの内容が変更される度に割り当てられる世代番号と、変更された内容とを対応付けて記憶するデータベースを管理するデータベース管理方法であって、
コンピュータが、前記データベースに記憶されたデータ群に含まれる複数のデータの内容を変更する操作を入力装置によりイベントとして受け付け、
コンピュータが、受け付けたイベントに対して一意のイベント識別子を処理装置により割り当て、
コンピュータが、受け付けたイベントに基づいて前記データベースに記憶された複数のデータの内容を変更し、内容を変更したデータごとに、新たな世代番号を処理装置により割り当てて前記データベースに記憶させ、
コンピュータが、割り当てたイベント識別子と、内容を変更した複数のデータを各々識別する複数のデータ識別子と、当該複数のデータに各々割り当てた複数の世代番号とを対応付けて記憶装置により記憶し、
コンピュータが、割り当てたイベント識別子を出力装置により出力し、
コンピュータが、出力したイベント識別子が入力されると、入力されたイベント識別子に対応する複数のデータ識別子と複数の世代番号とを記憶装置から取得し、前記データベースを検索して、取得した複数のデータ識別子の各々に対応するデータの内容のうち、取得した複数の世代番号の各々に対応する内容を取得することを特徴とするデータベース管理方法。
【請求項９】
過去に内容が変更されたデータ群を記憶するデータベースであり、データ群に含まれるデータごとに、データの内容が変更される度に割り当てられる世代番号と、変更された内容とを対応付けて記憶するデータベースに接続されたコンピュータを、
前記データベースに記憶されたデータ群に含まれる複数のデータの内容を変更する操作を入力装置によりイベントとして受け付ける操作受付部と、
前記操作受付部で受け付けられたイベントに対して一意のイベント識別子を処理装置により割り当てるイベント識別子割当部と、
前記操作受付部で受け付けられたイベントに基づいて前記データベースに記憶された複数のデータの内容を変更し、内容を変更したデータごとに、新たな世代番号を処理装置により割り当てて前記データベースに記憶させるデータ操作部と、
前記イベント識別子割当部で割り当てられたイベント識別子と、前記データ操作部で内容が変更された複数のデータを各々識別する複数のデータ識別子と、前記データ操作部で当該複数のデータに各々割り当てられた複数の世代番号とを対応付けて記憶装置により記憶する世代管理部と、
前記イベント識別子割当部で割り当てられたイベント識別子を出力装置により出力するイベント通知部と、
前記イベント通知部から出力されたイベント識別子が入力されると、入力されたイベント識別子に対応する複数のデータ識別子と複数の世代番号とを前記世代管理部から取得し、前記データベースを検索して、取得した複数のデータ識別子の各々に対応するデータの内容のうち、取得した複数の世代番号の各々に対応する内容を取得するデータセット検索部
として機能させるためのプログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【公開番号】特開２０１２−１８１６４２（Ｐ２０１２−１８１６４２Ａ）
【公開日】平成２４年９月２０日（２０１２．９．２０）
【国際特許分類】
【出願番号】特願２０１１−４３６５２（Ｐ２０１１−４３６５２）
【出願日】平成２３年３月１日（２０１１．３．１）
【出願人】（０００００６０１３）三菱電機株式会社 (33,312)
【Ｆターム（参考）】
【公開日】平成２４年９月２０日（２０１２．９．２０）
【国際特許分類】
【出願日】平成２３年３月１日（２０１１．３．１）
【出願人】（０００００６０１３）三菱電機株式会社 (33,312)
【Ｆターム（参考）】
[ Back to top ]