JP4152107B2 - データベース更新情報の反映システムおよびそのためのプログラム - Google Patents
データベース更新情報の反映システムおよびそのためのプログラム Download PDFInfo
- Publication number
- JP4152107B2 JP4152107B2 JP2002007803A JP2002007803A JP4152107B2 JP 4152107 B2 JP4152107 B2 JP 4152107B2 JP 2002007803 A JP2002007803 A JP 2002007803A JP 2002007803 A JP2002007803 A JP 2002007803A JP 4152107 B2 JP4152107 B2 JP 4152107B2
- Authority
- JP
- Japan
- Prior art keywords
- record
- update
- update information
- updated
- name
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
Images
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明はネットワークデータベース（ＮＤＢ）のデータ更新内容をリレーショナルデータベース（ＲＤＢ）へ反映するデータベース更新情報の反映システムそのためのプログラムに関する。
【０００２】
【従来の技術】
ビジネスにおいて通常の取引により発生するデータは、日毎等にまとめて基幹系のデータベースへ登録されることが一般的に行われている。基幹系のホストコンピュータで利用されるＤＢは、一般的にはネットワークデータベース（ＮＤＢ）である。
【０００３】
しかし、このようなデータを利用して何らかの分析を行なう場合には、情報系のデータベースであるリレーショナルデータベース（ＲＤＢ）の形式で格納されたデータの方が効率良く処理を行なえるため、ＮＤＢのデータをＲＤＢのデータとして扱えるように反映処理を行っている。ここで、ＮＤＢとＲＤＢの特徴を以下に記す。
【０００４】
ネットワークデータベース（ＮＤＢ）：
レコードを階層関係を基にポインタを利用してレコード間に１対ｎの親子関係（網構造）を設けて管理する。階層間のレコードの親子関係をセットという仕組みで保持している。プログラム／データの論理関係／データの物理的構造を独立して定義できる。階層関係に沿って処理するため階層関係にあるレコードに対して検索、更新スピードが速く、レスポンス重視の基幹系業務向きである。
【０００５】
リレーショナルデータベース（ＲＤＢ）：
レコードを二次元の表（テーブル）を用いて管理する。データ間の親子関係をキーでのみ表現する。各データに設けたキーを利用することにより、異なるテーブル間のデータを連携できるため、すなわちＮＤＢと異なりレコード間の関係付けが無いため、目的に応じた柔軟な検索が可能であり、情報系業務向きである。
【０００６】
このようなＮＤＢの更新データをＲＤＢへ反映させるとき、ＮＤＢの更新データの内容だけを見てもどのＲＤＢテーブルと対応しているか判定できない。このため、このような階層構造であるＮＤＢから表構造であるＲＤＢへデータを反映させる方式として、従来、下記の３つの方式の何れかがとられていた。
【０００７】
従来方式１：ＮＤＢの静態をＲＤＢへコピーする。コピーするための専用処理プログラム、すなわちＮＤＢ側の各レコードにキーを付けて対応するＲＤＢ側のテーブル内のデータを更新するプログラムを必要とする。
【０００８】
従来方式２：ＮＤＢの取引ログ（取引履歴）を利用してＲＤＢの更新時にＮＤＢの更新時の内容を再現してＲＤＢへ反映する。
【０００９】
従来方式３：ＮＤＢのデータがＲＤＢ内のどのアドレスに格納されているかを示す対応表（アドレステーブル）を用意し、ＮＤＢの更新ログにＲＤＢのアドレスを付加し、ＲＤＢの反映の際にこのアドレスに従ってＲＤＢを更新する（特開平７−２４４６０５参照）。
【００１０】
【発明が解決しようとする課題】
上記従来方式によるＮＤＢからＲＤＢへのデータの反映処理は、次のような問題がある。従来方式１では、ＮＤＢのレコードを全て読み込んで、複写しなければならず高負荷のため１日に１度程度しか反映処理を実施できない。従来方式２では、ＲＤＢを更新する段階でＮＤＢの更新と同様な処理を再度行わねばならず処理時間と負荷が２倍になる。従来方式３では、アドレステーブルを常に最新化し、管理しておく負担が発生する。このように、従来方式１〜３は何れもＮＤＢからＲＤＢへのデータの反映処理が高負荷となりもしくは長時間を要するという問題がある。
【００１１】
それゆえ、本発明は上記問題を解決し、ＮＤＢにおけるデータの更新を迅速かつ効率良くＲＤＢにおけるデータに反映させるデータベース更新情報の反映システムおよびそのためのプログラムを提供することを目的とする。
【００１２】
【課題を解決するための手段】
上記問題を解決する本発明によるデータベース更新情報の反映システムは、ネットワークデータベースにおけるレコードの更新をリレーショナルデータベースに反映させるデータベース更新情報の反映システムであって、リレーショナルデータベースに更新を反映させるネットワークデータベースのレコード名を格納する反映対象テーブルと、ネットワークデータベースのレコードのレコード名と、該レコードの最上位階層から当該レコードの階層までの各識別子と、追加、変更、削除、および、出力なしの何れかの更新区分と、該レコードの更新データの情報を含む該レコードの更新情報を蓄積格納する更新情報蓄積部と、前記ネットワークデータベースに格納される各レコードの更新時に、前記反映対象テーブルに、該更新対象のレコードのレコード名に一致するものがあった場合に、前記更新情報蓄積部内に該更新対象のレコードのレコード名および該レコードの最上位階層から当該レコードの階層までの各識別子と合致するものが存在するか検索する検索手段と、前記検索手段による検索の結果、前記更新情報蓄積部に前記更新対象のレコードのレコード名および該レコードの最上位階層から当該レコードの階層までの各識別子と合致するものが存在しない場合に、該更新対象のレコードのレコード名および該レコードの最上位階層から当該レコードの階層までの各識別子を含む該レコードの更新情報を前記更新情報蓄積部に蓄積格納する更新情報蓄積手段と、前記検索手段による検索の結果、前記更新情報蓄積部に前記更新対象のレコードのレコード名および該レコードの最上位階層から当該レコードの階層までの各識別子と合致するものが存在する場合に、該更新情報蓄積部に格納された該合致するレコードの更新情報に含まれた更新区分と該更新対象のレコードの更新区分について、前者が追加または変更で後者が変更である場合には、前者の更新データを後者の更新データに更新し、前者が追加で後者が削除である場合には、前者の更新区分を出力なしに更新し、前者が変更で後者が削除である場合には、前者の更新区分を削除に更新し、前者が削除で後者が追加である場合には、前者の更新区分を変更に更新し、前者の更新データを後者の更新データに更新する、塗替処理手段と、前記蓄積手段に蓄積された前記レコードの更新情報に含まれたレコード名と前記連結識別子とから、前記リレーショナルデータベース内のテーブルを特定し、該テーブルを前記レコードの更新情報で更新する更新手段と、を備えたことを特徴とする。
【００１４】
上記問題を解決する本発明によるデータベース更新情報の反映プログラムは、ネットワークデータベースにおけるレコードの更新をリレーショナルデータベースに反映させるデータベース更新情報の反映システムをコンピュータによって機能させるプログラムであって、前記データベース更新情報の反映システムは、リレーショナルデータベースに更新を反映させるネットワークデータベースのレコード名を格納する反映対象テーブルと、ネットワークデータベースのレコードのレコード名と、該レコードの最上位階層から当該レコードの階層までの各識別子と、追加、変更、削除、および、出力なしの何れかの更新区分と、該レコードの更新データの情報を含む該レコードの更新情報を蓄積格納する更新情報蓄積部と、を備え、前記プログラムは、コンピュータを、前記ネットワークデータベースに格納される各レコードの更新時に、前記反映対象テーブルに、該更新対象のレコードのレコード名に一致するものがあった場合に、前記更新情報蓄積部内に該更新対象のレコードのレコード名および該レコードの最上位階層から当該レコードの階層までの各識別子と合致するものが存在するか検索する検索手段と、前記検索手段による検索の結果、前記更新情報蓄積部に前記更新対象のレコードのレコード名および該レコードの最上位階層から当該レコードの階層までの各識別子と合致するものが存在しない場合に、該更新対象のレコードのレコード名および該レコードの最上位階層から当該レコードの階層までの各識別子を含む該レコードの更新情報を前記更新情報蓄積部に蓄積格納する更新情報蓄積手段と、前記検索手段による検索の結果、前記更新情報蓄積部に前記更新対象のレコードのレコード名および該レコードの最上位階層から当該レコードの階層までの各識別子と合致するものが存在する場合に、該更新情報蓄積部に格納された該合致するレコードの更新情報に含まれた更新区分と該更新対象のレコードの更新区分について、前者が追加または変更で後者が変更である場合には、前者の更新データを後者の更新データに更新し、前者が追加で後者が削除である場合には、前者の更新区分を出力なしに更新し、前者が変更で後者が削除である場合には、前者の更新区分を削除に更新し、前者が削除で後者が追加である場合には、前者の更新区分を変更に更新し、前者の更新データを後者の更新データに更新する、塗替処理手段と、前記蓄積手段に蓄積された前記レコードの更新情報に含まれたレコード名と前記連結識別子とから、前記リレーショナルデータベース内のテーブルを特定し、該テーブルを前記レコードの更新情報で更新する更新手段と、して機能させることを特徴とする。
【００１５】
【発明の実施の形態】
図１は本発明によるデータベース更新情報の反映システムの一実施形態の概略構成図である。図１全体に示す本発明のデータベース更新情報反映システム１０は、大型のコンピュータシステム（例えば、銀行の事務センタに設置されたコンピュータ）で構成され、演算や制御を行うＣＰＵ１、キーボードやマウスやフレキシブルディスク等の入力部２、ＣＲＴやプリンタやフレキシブルディスク等の出力部３、ＣＰＵ１が実行するプログラムやデータの一時記憶エリアおよびＣＰＵ１のワークエリアに用いられる内部記憶部４、必要に応じて内部記憶部４に書込まれるプログラムやデータを格納する外部記憶部５および他のコンピュータシステムに通信可能に接続され該システムとの間でプログラムやデータを送受信する通信部６を有する。
【００１６】
例えば主としてＲＡＭからなる内部記憶部４には、ＮＤＢ更新処理部４１、ＮＤＢ更新情報蓄積部４２、ＲＤＢ更新処理部４３等が設けられており、例えば主として磁気ディスクからなる外部記憶部５には、ネットワークデータベース（ＮＤＢ）５１、リレーショナルデータベース（ＲＤＢ）５２、ＲＤＢ反映対象テーブル５３、取引ログ５４の各情報が格納されている。本実施形態では１つの外部記憶部５に上記４つの情報を格納するが、これらの情報はそれぞれ独立の磁気ディスク等の外部記憶装置で構成してもよい。また、本実施形態では１つの大型のコンピュータシステムで構成したが、ＲＤＢ５２を他のコンピュータシステムに組込み、これらのコンピュータ間を通信可能に接続した構成にしてもよい。
【００１７】
ＮＤＢ更新処理部４１はＮＤＢ５１のレコードを更新する機能を有する。ＮＤＢ更新情報蓄積部４２はＮＤＢ５１のレコードが更新される度に最新となったレコードに関する情報、すなわちＮＤＢ更新情報を一時的に蓄積するための記憶エリアである。ＮＤＢ更新情報は、通信部６を介して本発明のデータベース更新情報反映システム１０に接続された他のコンピュータ（例えば、銀行の支店に設置された端末装置）から入力され、一時的にＮＤＢ更新情報蓄積部４２に格納され、塗替処理（後述）等をされた後、取引ログ５４へ格納される。ＲＤＢ更新処理部４３はＮＤＢ５１のレコードの更新処理を反映してＲＤＢ５２のテーブルを更新する機能を有する。
【００１８】
図２は図１に示すＮＤＢ更新情報蓄積部４２に蓄積されるデータであるＮＤＢ更新情報の具体例を示す図である。ＮＤＢ更新情報はＲＤＢのテーブル名、ＲＤＢのキー番号（連結識別子）、ＮＤＢの更新区分およびデータ内容を含む。ここで、ＮＤＢの更新処理は、データすなわちレコードの変更、追加または削除の何れかの処理に区分される。
【００１９】
図３は図１に示すＮＤＢ５１の具体例を示す図である。図３に示すＮＤＢは、７つのレコードを３階層構造で構成されており、各レコード３０、３１、３２、３１１、３１２および３２１にはレコード名およびキー番号（識別子）が付加されており、このキー番号は同一親レコードの配下の子レコード間で互いを識別可能に設定されている。
【００２０】
図４の（Ａ）はＲＤＢのキー設定の基本形を示す図であり、図４の（Ｂ）は図３に示すＮＤＢのレコード３１１に対応するＲＤＢのキー設定を具体的に示す図である。図４の（Ａ）に示すように、ＮＤＢ内の第ｎ階層の１つのレコードに対応するＲＤＢ内のテーブルのキー番号は、ＮＤＢの第１〜第ｎ階層の各レコードのキー番号をひとつながりにしたもので設定される。ここで、ｎ（整数）は当該レコードのＮＤＢの最上位階層からの階層の深さを表す。
【００２１】
図４の（Ｂ）に示すように、ＮＤＢ内のレコード３１１に対応するＲＤＢ内のテーブルのキー番号は、ＮＤＢのレコード３１１の最上位階層であるレコード３０からレコード３１１の第３階層までの各レコードのキー番号（識別子）、すなわち第１階層キー番号である００１、第２階層キー番号である９８７、第３階層キー番号である１１１をひとつながりにした連結識別子００１，９８７，１１１で設定される。
【００２２】
図５は図１に示すＲＤＢ５２から抽出されるテーブルの具体例を示す図である。図５に示す行列構成のテーブルは、テーブル名が流動性口座で、テーブルの列には口座名義、口座番号、残高、口座開設日、最終入金日等の項目（データ内容）が格納されており、各行には各列に記された項目に対応するデータが格納されていることを示す。
【００２３】
図６は図１に示すＲＤＢ反映対象テーブル５３の具体例を示す図である。ＲＤＢ反映対象テーブルはＮＤＢ更新処理においてＲＤＢの更新対象となるテーブル名を予めリストした表であり、このテーブル５３に予めリストしたテーブル名に対応するＮＤＢ内のレコードが更新されるときにのみＮＤＢ更新情報蓄積部４２にＮＤＢ更新情報が蓄積される。換言すれば、ＮＤＢに存在するレコードの中でＲＤＢのテーブルに必要ないものは更新情報として取得しないように、このテーブルにＲＤＢ反映対象レコードを予め定義しておく。
【００２４】
なお、ＮＤＢのレコード名とＲＤＢのテーブル名は、テーブルの特定を容易にするため同一名称を使用する。
【００２５】
図１に示す取引ログ５４はコンピュータのシステム状態を示すデータを記録したデータリカバリ用のＨＬＦ（Historical Log File）に付加して記録される取引の履歴を示すデータである。このデータ、すなわち図２に示すＮＤＢ更新情報は、取引毎に内部記憶部４のＮＤＢ更新情報蓄積部４２から外部記憶部５内の取引ログ５４に書出され、例えば数１０分から１時間毎の周期でＲＤＢ更新処理のため外部記憶部５内の他の磁気ディスクに転送される。
【００２６】
ＲＤＢ５２の更新では、所定の周期、例えば数１０分から１時間毎に、ＲＤＢ更新処理部４３を介して取引ログ５４内の更新情報のＲＤＢのテーブル名、ＲＤＢのキー番号（連結識別子）をそのまま検索キーとして該当ＲＤＢテーブルを判定し、ＮＤＢの更新区分（変更／追加／削除）に沿ったＮＤＢのデータ内容のＲＤＢ５２への反映処理を行う。
【００２７】
次に、本発明によるＮＤＢのデータ更新をＲＤＢへ反映させる反映処理について以下に詳細に説明する。
【００２８】
図７は本発明によるＮＤＢ更新処理のフローチャートである。前述したようにＮＤＢ更新情報は、ＲＤＢのテーブル名、ＲＤＢのキー番号（連結識別子）、ＮＤＢの更新区分およびデータ内容を含み、ＮＤＢのレコードの更新時に図示しないワークエリアに一時的に蓄積されている。
【００２９】
ＮＤＢのレコードの更新時に、図６に示すようなＲＤＢ反映対象テーブル５３を検索して（ステップＳ１）、ワークエリアに一時的に格納されている今回更新するレコードがテーブル内のレコードに一致したときにのみ、今回更新するレコードのＮＤＢ更新情報を蓄積対象として、ＮＤＢ更新情報蓄積部４２に格納する（ステップＳ２）。
【００３０】
次に、１取引内（１つの取引ログ）で、ＮＤＢ更新情報蓄積部４２に格納した今回のＮＤＢ更新情報がすでに蓄積されている情報か否か、すなわち同一レコードが複数回更新されたか否かを判定し（ステップＳ３）、ＹＥＳと判定された場合には、塗替対象の情報と判定して塗替処理を実行し（ステップＳ４）、塗替後の情報を取引ログ５４へ書出す（ステップＳ５）。一方ＮＯと判定された場合には、今回のＮＤＢ更新情報を蓄積情報として取引ログ５４の最後に書込む（ステップＳ６）。このように、１取引内で同一レコードが複数回更新された場合には最後の更新情報のみを有効とする。次に、塗替処理を以下に説明する。
【００３１】
図８は本発明による塗替パターンを説明するための図である。ＮＤＢ更新情報蓄積部４２内のＮＤＢ更新情報を塗替処理する時に、今回蓄積するＮＤＢ更新情報であるＲＤＢのテーブル名およびキー番号（連結識別子）が、既にＮＤＢ更新情報蓄積部４２に蓄積されているＮＤＢ更新情報であるＲＤＢのテーブル名、キー番号（連結識別子）に合致するか否かを、最新の蓄積情報から古い方へと順に検索して調べ、同一のテーブル名、キー番号（連結識別子）をもつＮＤＢ更新情報がＮＤＢ更新情報蓄積部４２内に存在していれば、今回蓄積するＮＤＢ更新情報を合致更新情報と判定し、塗替対象とする。この処理は図７のステップＳ３に相当する。この判定結果がＹＥＳのとき塗替処理を行い、判定結果がＮＯのとき塗替処理を行わずＮＤＢ更新情報蓄積部４２内にすでに蓄積されているＮＤＢ更新情報の後に今回蓄積するＮＤＢ更新情報、すなわちＲＤＢのテーブル名、ＲＤＢのキー番号（連結識別子）、ＮＤＢの更新区分およびデータ内容を書込む。以下、図８を参照して本発明による塗替処理を説明する。
【００３２】
図８に示すパターンを説明するための図において、最も左側の列には塗替パターンの番号が、その右側の列には、順に前回更新情報、今回更新情報および塗替後更新情報が示されている。前回更新情報、今回更新情報および塗替後更新情報の各々には、更新区分およびデータが示されている。前回更新情報および今回更新情報は、共に前述の塗替対象と判定された合致更新情報である。塗替後更新情報は、後にＲＤＢ反映処理を要する情報であり、この情報のみが図１に示すＮＤＢ更新情報蓄積部４２から取引ログ５４へ転送される。前回更新情報、今回更新情報および塗替後更新情報は、取引ログ５４への書出し後にオールクリアされる。
【００３３】
ＮＤＢ更新情報の塗替処理（最終更新情報のみを残す手法）は、順序性を意識して下記の具体的塗替パターン１〜５に示す要領で行う。
【００３４】
塗替パターン１：前回更新情報の更新区分が追加で、今回更新情報の更新区分が変更の場合、塗替後更新情報の更新区分は追加とする。これは、取引ログ５４の書出し後にオールクリアされたＮＤＢ更新情報蓄積部４２に、レコードが追加された後に同一レコードのデータを今回変更する場合を示している。それゆえ塗替後更新情報は、次回のＲＤＢ反映処理では追加の更新処理を行い、レコードの最新データが前回更新情報のＸＸＸＸＸＸでなく今回更新情報のＹＹＹＹＹＹであることを示す。
【００３５】
塗替パターン２：前回更新情報の更新区分が追加で、今回更新情報の更新区分が削除の場合、塗替後更新情報は出力なしとする。これは、取引ログ５４の書出し後にオールクリアされたＮＤＢ更新情報蓄積部４２に、レコードが追加された後に同一レコードのデータを今回削除する場合を示している。それゆえ塗替後更新情報は、次回のＲＤＢ反映処理では何も実行する必要がないことを示し、更新区分およびレコードのデータは共に出力されない。
【００３６】
塗替パターン３：前回更新情報の更新区分が変更で、今回更新情報の更新区分が変更の場合、塗替後更新情報は変更とする。これは、取引ログ５４の書出し後にオールクリアされたＮＤＢ更新情報蓄積部４２に、レコードが変更された後に同一レコードのデータを今回更に変更する場合を示している。それゆえ塗替後更新情報は、次回のＲＤＢ反映処理でも変更の更新処理を行い、レコードの最新データが前回更新情報のＸＸＸＸＸＸでなく今回更新情報のＹＹＹＹＹＹであることを示す。
【００３７】
塗替パターン４：前回更新情報の更新区分が変更で、今回更新情報の更新区分が削除の場合、塗替後更新情報は削除とする。これは、取引ログ５４の書出し後にオールクリアされたＮＤＢ更新情報蓄積部４２に、レコードが変更された後に同一レコードのデータを今回削除する場合を示している。それゆえ塗替後更新情報は、次回のＲＤＢ反映処理では削除の更新処理を行い、レコードの最新データが前回更新情報および今回更新情報共にＸＸＸＸＸＸであることを示している。次回のＲＤＢ反映処理時に当該レコードに対応するＲＤＢのテーブルおよびそのデータＸＸＸＸＸＸは共に削除される。
【００３８】
塗替パターン５：前回更新情報の更新区分が削除で、今回更新情報の更新区分が追加の場合、塗替後更新情報は変更とする。これは、取引ログ５４の書出し後にオールクリアされたＮＤＢ更新情報蓄積部４２に、レコードが削除された後に同一レコードのデータを今回追加する場合を示している。それゆえ塗替後更新情報は、次回のＲＤＢ反映処理では変更の更新処理を行い、レコードの最新データが前回更新情報のＸＸＸＸＸＸでなく今回更新情報のＹＹＹＹＹＹであることを示す。
【００３９】
以上、図８を用いて１つの取引で２回のＮＤＢ更新処理を行った場合を例に挙げて塗替処理を説明したが、１つの取引で複数回のＮＤＢ更新処理を行った場合も同様に、塗替処理が行われる。
【００４０】
このように、図８に示した塗替パターンに従って塗替処理を行うことにより、ＲＤＢ反映時に不必要なデータの更新をなくすことができ、処理時間を短縮できる。なお、図８に示した説明図に準ずるような判定テーブルを内部記憶部４に保持しておいてもよいし、プログラムに図８のような判定をさせるための処理を記述しておいても構わない。
【００４１】
最後にＲＤＢの更新処理を説明する。
【００４２】
図９は本発明によるＲＤＢ更新処理のフローチャートである。ＲＤＢの更新処理では、取引ログ５４内に格納されたＮＤＢ更新情報であるＲＤＢのテーブル名およびキー番号（連結識別子）をそのまま検索キーとして該当ＲＤＢテーブルを検索し（ステップＳ１１）、検索したＲＤＢテーブルに対してＮＤＢ更新情報の更新区分（変更／追加／削除）を判定し（ステップＳ１２）、その判定に沿った反映処理、すなわちＲＤＢのデータの更新処理（ステップＳ１３）を行う。
【００４３】
次に、図１０〜１２を参照して図１に示す本発明によるデータベース更新情報の反映システムを用いてＮＤＢのデータ更新内容をＲＤＢへ反映する具体例を以下に説明する。
【００４４】
図１０はオンライン上のＮＤＢの具体例を示す図である。図１０に示されるＮＤＢ１５１は銀行の預金通帳に関し、３段の階層構造を有する。最上位の第１階層に顧客情報のレコードが、第２階層に流動性（普通）口座および定期性口座のレコードが、第３階層に流動性口座の取引明細のレコードが示されている。各レコードには、レコード名および識別子が設定されている。顧客情報のレコードの識別子には顧客番号が、流動性（普通）口座および定期性口座のレコードの識別子には口座番号が、流動性口座または定期性口座の取引明細のレコードの識別子には明細番号が、それぞれ同一親レコードの配下で一意に登録されている。各レコードはそれぞれ最新のデータ内容（図示せず）を有する。
【００４５】
次に、１取引で、流動性口座の取引明細のレコード８１を変更し、破線で囲んで示す定期性口座のレコード８２を新たに追加するＮＤＢ更新処理を行う場合を想定し、この更新をＲＤＢに反映する具体例を以下に説明する。なお、定期性口座のレコード８２が破線で示されているのは、ＮＤＢ更新処理前には存在していなかったからである。
【００４６】
図１１は取引ログ１５４の具体例を示す図である。図１１に示すように、図１０に示すＮＤＢ１５１の１取引の取引ログには、第１番目（上段）に、流動性口座の取引明細のレコード８１の更新情報として、状態の欄に更新の区分が変更であることが示され、レコード名にTORIMEISが示され、第１階層に顧客情報レコードの識別子である識別子0000000001、第２階層に流動性口座レコードの識別子である識別子0000000010、第３階層にレコード８１の識別子である識別子00001が示されており、第２番目（下段）に、定期性口座のレコード８２の更新情報として、状態の欄に更新の区分が追加であることが示され、レコード名にTEIKIKOZが示され、第１番目の取引ログと同様に第１階層に識別子0000000001、第２階層に識別子0000000010が示されている。
【００４７】
この取引ログに示されたＮＤＢ更新をＲＤＢに反映するには、取引ログにおける第１番目の更新レコード８１の更新区分が変更であるので、流動性口座の取引明細のレコード８１のレコード名であるTORIMEISと同一名称のテーブル名を有し、連結識別子が0000000001,0000000010,00001であるテーブルをＲＤＢ内で検索し、検索されたテーブルのデータをレコード８１のデータで変更する。次に、取引ログにおける第２番目の更新レコード８２の更新区分が追加であるので、定期性口座のレコード８２のレコード名であるTEIKIKOZと同一名称のテーブル名を有し、連結識別子が0000000001,0000000010であるテーブルをＲＤＢ内に新たに生成し、生成したテーブルのデータにレコード８２のデータを書込む。
【００４８】
図１２は図１１に示す取引ログがＲＤＢに反映されるときの図１０に示すＮＤＢに対応するＲＤＢの状態を示す図であり、（Ａ）は反映前のＲＤＢの状態を示す図であり、（Ｂ）は反映後のＲＤＢの状態を示す図である。図１２の（Ａ）および（Ｂ）に示されているように、ＲＤＢにはＳＱＬにより抽出可能なテーブル名がKOKYAKUJ、RYUDOKOZ、TORIMEISおよびTEIKIKOZの４つのテーブルが格納されている。各テーブルには、キー番号の欄に、ＮＤＢ内で同一レコード名を有するレコードの最上位階層のレコードの識別子から当該レコードの識別子までをひとつながりにしたキー番号（連結識別子）が格納され、データ内容の欄に、当該レコードのデータ内容が格納されている。
【００４９】
図１２の（Ａ）に示されるように、反映前のＲＤＢには、テーブル名がKOKYAKUJのテーブル、テーブル名がRYUDOKOZのテーブルおよびテーブル名がTORIMEISのテーブルに、それぞれ２つのキー番号（連結識別子）とそれらのデータ内容が格納されており、テーブル名がTEIKIKOZのテーブルに１つのキー番号（連結識別子）とそのデータ内容が格納されている。テーブル名がRYUDOKOZおよびTEIKIKOZのテーブルのデータ内容は、例えば図５に示すような口座名義、口座番号、残高、口座開設日および最終入金日等であり、テーブル名がTORIMEISのテーブルのデータ内容は、入金または出金の区分け、取引金額、取引日および取引時刻等である。
【００５０】
図１２の（Ｂ）に示されるように、反映後のＲＤＢには、テーブル名がKOKYAKUJのテーブル、テーブル名がRYUDOKOZのテーブル、テーブル名がTORIMEISのテーブルおよびテーブル名がTEIKIKOZのテーブルに、それぞれ２つのキー番号（連結識別子）とそれらのデータ内容が格納されている。反映前のＲＤＢと異なるところは、テーブル名がTORIMEISのテーブルにおいて、参照番号１０１で示す１つのキー番号（連結識別子）0000000001,0000000010,00001の反映前のデータ内容が参照番号１０２で示す同一キー番号（連結識別子）の反映後のデータ内容に変更され、かつテーブル名がTEIKIKOZのテーブルに、参照番号１０３で示す１つのキー番号（連結識別子）0000000001,0000000010とそのデータ内容が追加されたことである。
【００５１】
（付記１） ネットワークデータベースにおけるレコードの更新をリレーショナルデータベースに反映させるデータベース更新情報の反映システムにおいて、
前記ネットワークデータベースに階層構造で格納される各レコードに対し、レコード名と、同一親レコードの子レコードが互いに識別可能となるような識別子とを設定する手段と、
前記レコードの更新毎に、更新するレコードに対応する前記レコード名および前記レコードの最上位階層から当該レコードの階層までの各識別子を含む該レコードの更新情報を蓄積する蓄積手段と、
前記リレーショナルデータベースに表構造で格納される各テーブルに対し、前記レコード名に対応するテーブル名および前記レコードの最上位階層から当該レコードの階層までの各識別子をひとつながりにした連結識別子を設定する手段と、
所定の周期で、前記テーブル名と前記連結識別子とから前記リレーショナルデータベース内のテーブルを特定し、該テーブルを前記レコードの更新情報で更新する手段と、
を備えたことを特徴とするデータベース更新情報の反映システム。
【００５２】
（付記２） 前記蓄積手段は、予め設定したリレーショナルデータベースへの更新対象のレコードに対してのみ該レコードの更新時のデータを蓄積する、請求項１に記載のデータベース更新情報の反映システム。
【００５３】
（付記３） 前記蓄積手段は、前記レコードの更新毎に、今回更新対象のレコードが前記蓄積手段に蓄積されたレコード内に有るか無いかを判定し、有ると判定されたときは該レコードの最新のデータを蓄積し、無いと判定されたときは今回更新対象のレコードのデータを蓄積する、請求項１または２に記載のデータベース更新情報の反映システム。
【００５４】
（付記４） 前記蓄積手段は、前記蓄積されたレコード内に今回更新対象のレコードが有るか無いかの判定を、該今回更新対象のレコードの前記レコード名および前記連結識別子が前記蓄積された各レコードの前記レコード名および前記連結識別子に一致するか否かにより判定する、請求項３に記載のデータベース更新情報の反映システム。
【００５５】
（付記５） 前記最新のデータは、今回更新対象のレコードの更新区分と該レコードに一致した前記蓄積されたレコード内のレコードの更新区分とに応じて決定される、請求項４に記載のデータベース更新情報の反映システム。
【００５６】
（付記６） 前記テーブル名は、前記レコード名と同一名称である、付記１乃至５の何れか一つに記載のデータベース更新情報の反映システム。
【００５７】
（付記７） ネットワークデータベースにおけるレコードの更新をリレーショナルデータベースに反映させるデータベース更新情報の反映システムを、
前記ネットワークデータベースに階層構造で格納される各レコードに対し、レコード名と、同一親レコードの子レコードが互いに識別可能となるような識別子とを設定する手段と、
前記レコードの更新毎に、更新するレコードに対応する前記レコード名および前記レコードの最上位階層から当該レコードの階層までの各識別子を含む該レコードの更新情報を蓄積する蓄積手段と、
前記リレーショナルデータベースに表構造で格納される各テーブルに対し、前記レコード名に対応するテーブル名および前記レコードの最上位階層から当該レコードの階層までの各識別子をひとつながりにした連結識別子を設定する手段と、
所定の周期で、前記テーブル名と前記連結識別子とから前記リレーショナルデータベース内のテーブルを特定し、該テーブルを前記レコードの更新情報で更新する手段と、
して機能させるためのプログラムを備えたことを特徴とするデータベース更新情報の反映プログラム。
【００５８】
【発明の効果】
以上説明したように、本発明のデータベース更新情報の反映システムおよびそのためのプログラムによれば、計算機負荷が少なくデータベース更新情報の反映処理を簡素化したので、基幹系データベース（ネットワークデータベース：ＮＤＢ）のデータ更新内容を迅速かつ効率的に情報系データベース（リレーショナルデータベース：ＲＤＢ）に反映することができる。
【００５９】
本発明によれば、データベース更新情報の反映処理時間を短縮でき、それゆえ頻繁に更新処理ができるようになる。具体的には従来日毎にＮＤＢの情報をＲＤＢに反映していたが、本発明では数十分から１時間毎に最新情報が反映可能となるので、ＲＤＢの情報の鮮度が高くなり経営分析等の利用に有効となる。
【００６０】
また、本発明によれば、ＮＤＢの更新データの内でＲＤＢに反映する必要のない更新データを排除する構成を設けたので、効率的なデータ反映が可能となる。
【図面の簡単な説明】
【図１】本発明によるデータベース更新情報の反映システムの一実施形態の概略構成図である。
【図２】図１に示すＮＤＢ更新情報蓄積部４２に蓄積されるデータであるＮＤＢ更新情報の具体例を示す図である。
【図３】図１に示すＮＤＢ５１の具体例を示す図である。
【図４】（Ａ）はＲＤＢのキー設定の基本形を示す図であり、（Ｂ）は図３に示すＮＤＢのレコード３１１に対応するＲＤＢのキー設定を具体的に示す図である。
【図５】図１に示すＲＤＢ５２から抽出されるテーブルの具体例を示す図である。
【図６】図１に示すＲＤＢ反映対象テーブル５３の具体例を示す図である。
【図７】本発明によるＮＤＢ更新処理のフローチャートである。
【図８】本発明による塗替パターンを説明するための図である。
【図９】本発明によるＲＤＢ更新処理のフローチャートである。
【図１０】オンライン上のＮＤＢの具体例を示す図である。
【図１１】取引ログの具体例を示す図である。
【図１２】図１１に示す取引ログがＲＤＢに反映されるときの図１０に示すＮＤＢに対応するＲＤＢの状態を示す図であり、（Ａ）は反映前のＲＤＢの状態を示す図であり、（Ｂ）は反映後のＲＤＢの状態を示す図である。
【符号の説明】
１…ＣＰＵ
２…入力部
３…出力部
４…内部記憶部
５…外部記憶部
６…通信部
１０…データベース更新情報反映システム
４１…ＮＤＢ更新処理部
４２…ＮＤＢ更新情報蓄積部
４３…ＲＤＢ更新処理部
５１，１５１…ネットワークデータベース（ＮＤＢ）
５２…リレーショナルデータベース（ＲＤＢ）
５３…ＲＤＢ対象テーブル
５４，１５４…取引ログ
【発明の属する技術分野】
本発明はネットワークデータベース（ＮＤＢ）のデータ更新内容をリレーショナルデータベース（ＲＤＢ）へ反映するデータベース更新情報の反映システムそのためのプログラムに関する。
【０００２】
【従来の技術】
ビジネスにおいて通常の取引により発生するデータは、日毎等にまとめて基幹系のデータベースへ登録されることが一般的に行われている。基幹系のホストコンピュータで利用されるＤＢは、一般的にはネットワークデータベース（ＮＤＢ）である。
【０００３】
しかし、このようなデータを利用して何らかの分析を行なう場合には、情報系のデータベースであるリレーショナルデータベース（ＲＤＢ）の形式で格納されたデータの方が効率良く処理を行なえるため、ＮＤＢのデータをＲＤＢのデータとして扱えるように反映処理を行っている。ここで、ＮＤＢとＲＤＢの特徴を以下に記す。
【０００４】
ネットワークデータベース（ＮＤＢ）：
レコードを階層関係を基にポインタを利用してレコード間に１対ｎの親子関係（網構造）を設けて管理する。階層間のレコードの親子関係をセットという仕組みで保持している。プログラム／データの論理関係／データの物理的構造を独立して定義できる。階層関係に沿って処理するため階層関係にあるレコードに対して検索、更新スピードが速く、レスポンス重視の基幹系業務向きである。
【０００５】
リレーショナルデータベース（ＲＤＢ）：
レコードを二次元の表（テーブル）を用いて管理する。データ間の親子関係をキーでのみ表現する。各データに設けたキーを利用することにより、異なるテーブル間のデータを連携できるため、すなわちＮＤＢと異なりレコード間の関係付けが無いため、目的に応じた柔軟な検索が可能であり、情報系業務向きである。
【０００６】
このようなＮＤＢの更新データをＲＤＢへ反映させるとき、ＮＤＢの更新データの内容だけを見てもどのＲＤＢテーブルと対応しているか判定できない。このため、このような階層構造であるＮＤＢから表構造であるＲＤＢへデータを反映させる方式として、従来、下記の３つの方式の何れかがとられていた。
【０００７】
従来方式１：ＮＤＢの静態をＲＤＢへコピーする。コピーするための専用処理プログラム、すなわちＮＤＢ側の各レコードにキーを付けて対応するＲＤＢ側のテーブル内のデータを更新するプログラムを必要とする。
【０００８】
従来方式２：ＮＤＢの取引ログ（取引履歴）を利用してＲＤＢの更新時にＮＤＢの更新時の内容を再現してＲＤＢへ反映する。
【０００９】
従来方式３：ＮＤＢのデータがＲＤＢ内のどのアドレスに格納されているかを示す対応表（アドレステーブル）を用意し、ＮＤＢの更新ログにＲＤＢのアドレスを付加し、ＲＤＢの反映の際にこのアドレスに従ってＲＤＢを更新する（特開平７−２４４６０５参照）。
【００１０】
【発明が解決しようとする課題】
上記従来方式によるＮＤＢからＲＤＢへのデータの反映処理は、次のような問題がある。従来方式１では、ＮＤＢのレコードを全て読み込んで、複写しなければならず高負荷のため１日に１度程度しか反映処理を実施できない。従来方式２では、ＲＤＢを更新する段階でＮＤＢの更新と同様な処理を再度行わねばならず処理時間と負荷が２倍になる。従来方式３では、アドレステーブルを常に最新化し、管理しておく負担が発生する。このように、従来方式１〜３は何れもＮＤＢからＲＤＢへのデータの反映処理が高負荷となりもしくは長時間を要するという問題がある。
【００１１】
それゆえ、本発明は上記問題を解決し、ＮＤＢにおけるデータの更新を迅速かつ効率良くＲＤＢにおけるデータに反映させるデータベース更新情報の反映システムおよびそのためのプログラムを提供することを目的とする。
【００１２】
【課題を解決するための手段】
上記問題を解決する本発明によるデータベース更新情報の反映システムは、ネットワークデータベースにおけるレコードの更新をリレーショナルデータベースに反映させるデータベース更新情報の反映システムであって、リレーショナルデータベースに更新を反映させるネットワークデータベースのレコード名を格納する反映対象テーブルと、ネットワークデータベースのレコードのレコード名と、該レコードの最上位階層から当該レコードの階層までの各識別子と、追加、変更、削除、および、出力なしの何れかの更新区分と、該レコードの更新データの情報を含む該レコードの更新情報を蓄積格納する更新情報蓄積部と、前記ネットワークデータベースに格納される各レコードの更新時に、前記反映対象テーブルに、該更新対象のレコードのレコード名に一致するものがあった場合に、前記更新情報蓄積部内に該更新対象のレコードのレコード名および該レコードの最上位階層から当該レコードの階層までの各識別子と合致するものが存在するか検索する検索手段と、前記検索手段による検索の結果、前記更新情報蓄積部に前記更新対象のレコードのレコード名および該レコードの最上位階層から当該レコードの階層までの各識別子と合致するものが存在しない場合に、該更新対象のレコードのレコード名および該レコードの最上位階層から当該レコードの階層までの各識別子を含む該レコードの更新情報を前記更新情報蓄積部に蓄積格納する更新情報蓄積手段と、前記検索手段による検索の結果、前記更新情報蓄積部に前記更新対象のレコードのレコード名および該レコードの最上位階層から当該レコードの階層までの各識別子と合致するものが存在する場合に、該更新情報蓄積部に格納された該合致するレコードの更新情報に含まれた更新区分と該更新対象のレコードの更新区分について、前者が追加または変更で後者が変更である場合には、前者の更新データを後者の更新データに更新し、前者が追加で後者が削除である場合には、前者の更新区分を出力なしに更新し、前者が変更で後者が削除である場合には、前者の更新区分を削除に更新し、前者が削除で後者が追加である場合には、前者の更新区分を変更に更新し、前者の更新データを後者の更新データに更新する、塗替処理手段と、前記蓄積手段に蓄積された前記レコードの更新情報に含まれたレコード名と前記連結識別子とから、前記リレーショナルデータベース内のテーブルを特定し、該テーブルを前記レコードの更新情報で更新する更新手段と、を備えたことを特徴とする。
【００１４】
上記問題を解決する本発明によるデータベース更新情報の反映プログラムは、ネットワークデータベースにおけるレコードの更新をリレーショナルデータベースに反映させるデータベース更新情報の反映システムをコンピュータによって機能させるプログラムであって、前記データベース更新情報の反映システムは、リレーショナルデータベースに更新を反映させるネットワークデータベースのレコード名を格納する反映対象テーブルと、ネットワークデータベースのレコードのレコード名と、該レコードの最上位階層から当該レコードの階層までの各識別子と、追加、変更、削除、および、出力なしの何れかの更新区分と、該レコードの更新データの情報を含む該レコードの更新情報を蓄積格納する更新情報蓄積部と、を備え、前記プログラムは、コンピュータを、前記ネットワークデータベースに格納される各レコードの更新時に、前記反映対象テーブルに、該更新対象のレコードのレコード名に一致するものがあった場合に、前記更新情報蓄積部内に該更新対象のレコードのレコード名および該レコードの最上位階層から当該レコードの階層までの各識別子と合致するものが存在するか検索する検索手段と、前記検索手段による検索の結果、前記更新情報蓄積部に前記更新対象のレコードのレコード名および該レコードの最上位階層から当該レコードの階層までの各識別子と合致するものが存在しない場合に、該更新対象のレコードのレコード名および該レコードの最上位階層から当該レコードの階層までの各識別子を含む該レコードの更新情報を前記更新情報蓄積部に蓄積格納する更新情報蓄積手段と、前記検索手段による検索の結果、前記更新情報蓄積部に前記更新対象のレコードのレコード名および該レコードの最上位階層から当該レコードの階層までの各識別子と合致するものが存在する場合に、該更新情報蓄積部に格納された該合致するレコードの更新情報に含まれた更新区分と該更新対象のレコードの更新区分について、前者が追加または変更で後者が変更である場合には、前者の更新データを後者の更新データに更新し、前者が追加で後者が削除である場合には、前者の更新区分を出力なしに更新し、前者が変更で後者が削除である場合には、前者の更新区分を削除に更新し、前者が削除で後者が追加である場合には、前者の更新区分を変更に更新し、前者の更新データを後者の更新データに更新する、塗替処理手段と、前記蓄積手段に蓄積された前記レコードの更新情報に含まれたレコード名と前記連結識別子とから、前記リレーショナルデータベース内のテーブルを特定し、該テーブルを前記レコードの更新情報で更新する更新手段と、して機能させることを特徴とする。
【００１５】
【発明の実施の形態】
図１は本発明によるデータベース更新情報の反映システムの一実施形態の概略構成図である。図１全体に示す本発明のデータベース更新情報反映システム１０は、大型のコンピュータシステム（例えば、銀行の事務センタに設置されたコンピュータ）で構成され、演算や制御を行うＣＰＵ１、キーボードやマウスやフレキシブルディスク等の入力部２、ＣＲＴやプリンタやフレキシブルディスク等の出力部３、ＣＰＵ１が実行するプログラムやデータの一時記憶エリアおよびＣＰＵ１のワークエリアに用いられる内部記憶部４、必要に応じて内部記憶部４に書込まれるプログラムやデータを格納する外部記憶部５および他のコンピュータシステムに通信可能に接続され該システムとの間でプログラムやデータを送受信する通信部６を有する。
【００１６】
例えば主としてＲＡＭからなる内部記憶部４には、ＮＤＢ更新処理部４１、ＮＤＢ更新情報蓄積部４２、ＲＤＢ更新処理部４３等が設けられており、例えば主として磁気ディスクからなる外部記憶部５には、ネットワークデータベース（ＮＤＢ）５１、リレーショナルデータベース（ＲＤＢ）５２、ＲＤＢ反映対象テーブル５３、取引ログ５４の各情報が格納されている。本実施形態では１つの外部記憶部５に上記４つの情報を格納するが、これらの情報はそれぞれ独立の磁気ディスク等の外部記憶装置で構成してもよい。また、本実施形態では１つの大型のコンピュータシステムで構成したが、ＲＤＢ５２を他のコンピュータシステムに組込み、これらのコンピュータ間を通信可能に接続した構成にしてもよい。
【００１７】
ＮＤＢ更新処理部４１はＮＤＢ５１のレコードを更新する機能を有する。ＮＤＢ更新情報蓄積部４２はＮＤＢ５１のレコードが更新される度に最新となったレコードに関する情報、すなわちＮＤＢ更新情報を一時的に蓄積するための記憶エリアである。ＮＤＢ更新情報は、通信部６を介して本発明のデータベース更新情報反映システム１０に接続された他のコンピュータ（例えば、銀行の支店に設置された端末装置）から入力され、一時的にＮＤＢ更新情報蓄積部４２に格納され、塗替処理（後述）等をされた後、取引ログ５４へ格納される。ＲＤＢ更新処理部４３はＮＤＢ５１のレコードの更新処理を反映してＲＤＢ５２のテーブルを更新する機能を有する。
【００１８】
図２は図１に示すＮＤＢ更新情報蓄積部４２に蓄積されるデータであるＮＤＢ更新情報の具体例を示す図である。ＮＤＢ更新情報はＲＤＢのテーブル名、ＲＤＢのキー番号（連結識別子）、ＮＤＢの更新区分およびデータ内容を含む。ここで、ＮＤＢの更新処理は、データすなわちレコードの変更、追加または削除の何れかの処理に区分される。
【００１９】
図３は図１に示すＮＤＢ５１の具体例を示す図である。図３に示すＮＤＢは、７つのレコードを３階層構造で構成されており、各レコード３０、３１、３２、３１１、３１２および３２１にはレコード名およびキー番号（識別子）が付加されており、このキー番号は同一親レコードの配下の子レコード間で互いを識別可能に設定されている。
【００２０】
図４の（Ａ）はＲＤＢのキー設定の基本形を示す図であり、図４の（Ｂ）は図３に示すＮＤＢのレコード３１１に対応するＲＤＢのキー設定を具体的に示す図である。図４の（Ａ）に示すように、ＮＤＢ内の第ｎ階層の１つのレコードに対応するＲＤＢ内のテーブルのキー番号は、ＮＤＢの第１〜第ｎ階層の各レコードのキー番号をひとつながりにしたもので設定される。ここで、ｎ（整数）は当該レコードのＮＤＢの最上位階層からの階層の深さを表す。
【００２１】
図４の（Ｂ）に示すように、ＮＤＢ内のレコード３１１に対応するＲＤＢ内のテーブルのキー番号は、ＮＤＢのレコード３１１の最上位階層であるレコード３０からレコード３１１の第３階層までの各レコードのキー番号（識別子）、すなわち第１階層キー番号である００１、第２階層キー番号である９８７、第３階層キー番号である１１１をひとつながりにした連結識別子００１，９８７，１１１で設定される。
【００２２】
図５は図１に示すＲＤＢ５２から抽出されるテーブルの具体例を示す図である。図５に示す行列構成のテーブルは、テーブル名が流動性口座で、テーブルの列には口座名義、口座番号、残高、口座開設日、最終入金日等の項目（データ内容）が格納されており、各行には各列に記された項目に対応するデータが格納されていることを示す。
【００２３】
図６は図１に示すＲＤＢ反映対象テーブル５３の具体例を示す図である。ＲＤＢ反映対象テーブルはＮＤＢ更新処理においてＲＤＢの更新対象となるテーブル名を予めリストした表であり、このテーブル５３に予めリストしたテーブル名に対応するＮＤＢ内のレコードが更新されるときにのみＮＤＢ更新情報蓄積部４２にＮＤＢ更新情報が蓄積される。換言すれば、ＮＤＢに存在するレコードの中でＲＤＢのテーブルに必要ないものは更新情報として取得しないように、このテーブルにＲＤＢ反映対象レコードを予め定義しておく。
【００２４】
なお、ＮＤＢのレコード名とＲＤＢのテーブル名は、テーブルの特定を容易にするため同一名称を使用する。
【００２５】
図１に示す取引ログ５４はコンピュータのシステム状態を示すデータを記録したデータリカバリ用のＨＬＦ（Historical Log File）に付加して記録される取引の履歴を示すデータである。このデータ、すなわち図２に示すＮＤＢ更新情報は、取引毎に内部記憶部４のＮＤＢ更新情報蓄積部４２から外部記憶部５内の取引ログ５４に書出され、例えば数１０分から１時間毎の周期でＲＤＢ更新処理のため外部記憶部５内の他の磁気ディスクに転送される。
【００２６】
ＲＤＢ５２の更新では、所定の周期、例えば数１０分から１時間毎に、ＲＤＢ更新処理部４３を介して取引ログ５４内の更新情報のＲＤＢのテーブル名、ＲＤＢのキー番号（連結識別子）をそのまま検索キーとして該当ＲＤＢテーブルを判定し、ＮＤＢの更新区分（変更／追加／削除）に沿ったＮＤＢのデータ内容のＲＤＢ５２への反映処理を行う。
【００２７】
次に、本発明によるＮＤＢのデータ更新をＲＤＢへ反映させる反映処理について以下に詳細に説明する。
【００２８】
図７は本発明によるＮＤＢ更新処理のフローチャートである。前述したようにＮＤＢ更新情報は、ＲＤＢのテーブル名、ＲＤＢのキー番号（連結識別子）、ＮＤＢの更新区分およびデータ内容を含み、ＮＤＢのレコードの更新時に図示しないワークエリアに一時的に蓄積されている。
【００２９】
ＮＤＢのレコードの更新時に、図６に示すようなＲＤＢ反映対象テーブル５３を検索して（ステップＳ１）、ワークエリアに一時的に格納されている今回更新するレコードがテーブル内のレコードに一致したときにのみ、今回更新するレコードのＮＤＢ更新情報を蓄積対象として、ＮＤＢ更新情報蓄積部４２に格納する（ステップＳ２）。
【００３０】
次に、１取引内（１つの取引ログ）で、ＮＤＢ更新情報蓄積部４２に格納した今回のＮＤＢ更新情報がすでに蓄積されている情報か否か、すなわち同一レコードが複数回更新されたか否かを判定し（ステップＳ３）、ＹＥＳと判定された場合には、塗替対象の情報と判定して塗替処理を実行し（ステップＳ４）、塗替後の情報を取引ログ５４へ書出す（ステップＳ５）。一方ＮＯと判定された場合には、今回のＮＤＢ更新情報を蓄積情報として取引ログ５４の最後に書込む（ステップＳ６）。このように、１取引内で同一レコードが複数回更新された場合には最後の更新情報のみを有効とする。次に、塗替処理を以下に説明する。
【００３１】
図８は本発明による塗替パターンを説明するための図である。ＮＤＢ更新情報蓄積部４２内のＮＤＢ更新情報を塗替処理する時に、今回蓄積するＮＤＢ更新情報であるＲＤＢのテーブル名およびキー番号（連結識別子）が、既にＮＤＢ更新情報蓄積部４２に蓄積されているＮＤＢ更新情報であるＲＤＢのテーブル名、キー番号（連結識別子）に合致するか否かを、最新の蓄積情報から古い方へと順に検索して調べ、同一のテーブル名、キー番号（連結識別子）をもつＮＤＢ更新情報がＮＤＢ更新情報蓄積部４２内に存在していれば、今回蓄積するＮＤＢ更新情報を合致更新情報と判定し、塗替対象とする。この処理は図７のステップＳ３に相当する。この判定結果がＹＥＳのとき塗替処理を行い、判定結果がＮＯのとき塗替処理を行わずＮＤＢ更新情報蓄積部４２内にすでに蓄積されているＮＤＢ更新情報の後に今回蓄積するＮＤＢ更新情報、すなわちＲＤＢのテーブル名、ＲＤＢのキー番号（連結識別子）、ＮＤＢの更新区分およびデータ内容を書込む。以下、図８を参照して本発明による塗替処理を説明する。
【００３２】
図８に示すパターンを説明するための図において、最も左側の列には塗替パターンの番号が、その右側の列には、順に前回更新情報、今回更新情報および塗替後更新情報が示されている。前回更新情報、今回更新情報および塗替後更新情報の各々には、更新区分およびデータが示されている。前回更新情報および今回更新情報は、共に前述の塗替対象と判定された合致更新情報である。塗替後更新情報は、後にＲＤＢ反映処理を要する情報であり、この情報のみが図１に示すＮＤＢ更新情報蓄積部４２から取引ログ５４へ転送される。前回更新情報、今回更新情報および塗替後更新情報は、取引ログ５４への書出し後にオールクリアされる。
【００３３】
ＮＤＢ更新情報の塗替処理（最終更新情報のみを残す手法）は、順序性を意識して下記の具体的塗替パターン１〜５に示す要領で行う。
【００３４】
塗替パターン１：前回更新情報の更新区分が追加で、今回更新情報の更新区分が変更の場合、塗替後更新情報の更新区分は追加とする。これは、取引ログ５４の書出し後にオールクリアされたＮＤＢ更新情報蓄積部４２に、レコードが追加された後に同一レコードのデータを今回変更する場合を示している。それゆえ塗替後更新情報は、次回のＲＤＢ反映処理では追加の更新処理を行い、レコードの最新データが前回更新情報のＸＸＸＸＸＸでなく今回更新情報のＹＹＹＹＹＹであることを示す。
【００３５】
塗替パターン２：前回更新情報の更新区分が追加で、今回更新情報の更新区分が削除の場合、塗替後更新情報は出力なしとする。これは、取引ログ５４の書出し後にオールクリアされたＮＤＢ更新情報蓄積部４２に、レコードが追加された後に同一レコードのデータを今回削除する場合を示している。それゆえ塗替後更新情報は、次回のＲＤＢ反映処理では何も実行する必要がないことを示し、更新区分およびレコードのデータは共に出力されない。
【００３６】
塗替パターン３：前回更新情報の更新区分が変更で、今回更新情報の更新区分が変更の場合、塗替後更新情報は変更とする。これは、取引ログ５４の書出し後にオールクリアされたＮＤＢ更新情報蓄積部４２に、レコードが変更された後に同一レコードのデータを今回更に変更する場合を示している。それゆえ塗替後更新情報は、次回のＲＤＢ反映処理でも変更の更新処理を行い、レコードの最新データが前回更新情報のＸＸＸＸＸＸでなく今回更新情報のＹＹＹＹＹＹであることを示す。
【００３７】
塗替パターン４：前回更新情報の更新区分が変更で、今回更新情報の更新区分が削除の場合、塗替後更新情報は削除とする。これは、取引ログ５４の書出し後にオールクリアされたＮＤＢ更新情報蓄積部４２に、レコードが変更された後に同一レコードのデータを今回削除する場合を示している。それゆえ塗替後更新情報は、次回のＲＤＢ反映処理では削除の更新処理を行い、レコードの最新データが前回更新情報および今回更新情報共にＸＸＸＸＸＸであることを示している。次回のＲＤＢ反映処理時に当該レコードに対応するＲＤＢのテーブルおよびそのデータＸＸＸＸＸＸは共に削除される。
【００３８】
塗替パターン５：前回更新情報の更新区分が削除で、今回更新情報の更新区分が追加の場合、塗替後更新情報は変更とする。これは、取引ログ５４の書出し後にオールクリアされたＮＤＢ更新情報蓄積部４２に、レコードが削除された後に同一レコードのデータを今回追加する場合を示している。それゆえ塗替後更新情報は、次回のＲＤＢ反映処理では変更の更新処理を行い、レコードの最新データが前回更新情報のＸＸＸＸＸＸでなく今回更新情報のＹＹＹＹＹＹであることを示す。
【００３９】
以上、図８を用いて１つの取引で２回のＮＤＢ更新処理を行った場合を例に挙げて塗替処理を説明したが、１つの取引で複数回のＮＤＢ更新処理を行った場合も同様に、塗替処理が行われる。
【００４０】
このように、図８に示した塗替パターンに従って塗替処理を行うことにより、ＲＤＢ反映時に不必要なデータの更新をなくすことができ、処理時間を短縮できる。なお、図８に示した説明図に準ずるような判定テーブルを内部記憶部４に保持しておいてもよいし、プログラムに図８のような判定をさせるための処理を記述しておいても構わない。
【００４１】
最後にＲＤＢの更新処理を説明する。
【００４２】
図９は本発明によるＲＤＢ更新処理のフローチャートである。ＲＤＢの更新処理では、取引ログ５４内に格納されたＮＤＢ更新情報であるＲＤＢのテーブル名およびキー番号（連結識別子）をそのまま検索キーとして該当ＲＤＢテーブルを検索し（ステップＳ１１）、検索したＲＤＢテーブルに対してＮＤＢ更新情報の更新区分（変更／追加／削除）を判定し（ステップＳ１２）、その判定に沿った反映処理、すなわちＲＤＢのデータの更新処理（ステップＳ１３）を行う。
【００４３】
次に、図１０〜１２を参照して図１に示す本発明によるデータベース更新情報の反映システムを用いてＮＤＢのデータ更新内容をＲＤＢへ反映する具体例を以下に説明する。
【００４４】
図１０はオンライン上のＮＤＢの具体例を示す図である。図１０に示されるＮＤＢ１５１は銀行の預金通帳に関し、３段の階層構造を有する。最上位の第１階層に顧客情報のレコードが、第２階層に流動性（普通）口座および定期性口座のレコードが、第３階層に流動性口座の取引明細のレコードが示されている。各レコードには、レコード名および識別子が設定されている。顧客情報のレコードの識別子には顧客番号が、流動性（普通）口座および定期性口座のレコードの識別子には口座番号が、流動性口座または定期性口座の取引明細のレコードの識別子には明細番号が、それぞれ同一親レコードの配下で一意に登録されている。各レコードはそれぞれ最新のデータ内容（図示せず）を有する。
【００４５】
次に、１取引で、流動性口座の取引明細のレコード８１を変更し、破線で囲んで示す定期性口座のレコード８２を新たに追加するＮＤＢ更新処理を行う場合を想定し、この更新をＲＤＢに反映する具体例を以下に説明する。なお、定期性口座のレコード８２が破線で示されているのは、ＮＤＢ更新処理前には存在していなかったからである。
【００４６】
図１１は取引ログ１５４の具体例を示す図である。図１１に示すように、図１０に示すＮＤＢ１５１の１取引の取引ログには、第１番目（上段）に、流動性口座の取引明細のレコード８１の更新情報として、状態の欄に更新の区分が変更であることが示され、レコード名にTORIMEISが示され、第１階層に顧客情報レコードの識別子である識別子0000000001、第２階層に流動性口座レコードの識別子である識別子0000000010、第３階層にレコード８１の識別子である識別子00001が示されており、第２番目（下段）に、定期性口座のレコード８２の更新情報として、状態の欄に更新の区分が追加であることが示され、レコード名にTEIKIKOZが示され、第１番目の取引ログと同様に第１階層に識別子0000000001、第２階層に識別子0000000010が示されている。
【００４７】
この取引ログに示されたＮＤＢ更新をＲＤＢに反映するには、取引ログにおける第１番目の更新レコード８１の更新区分が変更であるので、流動性口座の取引明細のレコード８１のレコード名であるTORIMEISと同一名称のテーブル名を有し、連結識別子が0000000001,0000000010,00001であるテーブルをＲＤＢ内で検索し、検索されたテーブルのデータをレコード８１のデータで変更する。次に、取引ログにおける第２番目の更新レコード８２の更新区分が追加であるので、定期性口座のレコード８２のレコード名であるTEIKIKOZと同一名称のテーブル名を有し、連結識別子が0000000001,0000000010であるテーブルをＲＤＢ内に新たに生成し、生成したテーブルのデータにレコード８２のデータを書込む。
【００４８】
図１２は図１１に示す取引ログがＲＤＢに反映されるときの図１０に示すＮＤＢに対応するＲＤＢの状態を示す図であり、（Ａ）は反映前のＲＤＢの状態を示す図であり、（Ｂ）は反映後のＲＤＢの状態を示す図である。図１２の（Ａ）および（Ｂ）に示されているように、ＲＤＢにはＳＱＬにより抽出可能なテーブル名がKOKYAKUJ、RYUDOKOZ、TORIMEISおよびTEIKIKOZの４つのテーブルが格納されている。各テーブルには、キー番号の欄に、ＮＤＢ内で同一レコード名を有するレコードの最上位階層のレコードの識別子から当該レコードの識別子までをひとつながりにしたキー番号（連結識別子）が格納され、データ内容の欄に、当該レコードのデータ内容が格納されている。
【００４９】
図１２の（Ａ）に示されるように、反映前のＲＤＢには、テーブル名がKOKYAKUJのテーブル、テーブル名がRYUDOKOZのテーブルおよびテーブル名がTORIMEISのテーブルに、それぞれ２つのキー番号（連結識別子）とそれらのデータ内容が格納されており、テーブル名がTEIKIKOZのテーブルに１つのキー番号（連結識別子）とそのデータ内容が格納されている。テーブル名がRYUDOKOZおよびTEIKIKOZのテーブルのデータ内容は、例えば図５に示すような口座名義、口座番号、残高、口座開設日および最終入金日等であり、テーブル名がTORIMEISのテーブルのデータ内容は、入金または出金の区分け、取引金額、取引日および取引時刻等である。
【００５０】
図１２の（Ｂ）に示されるように、反映後のＲＤＢには、テーブル名がKOKYAKUJのテーブル、テーブル名がRYUDOKOZのテーブル、テーブル名がTORIMEISのテーブルおよびテーブル名がTEIKIKOZのテーブルに、それぞれ２つのキー番号（連結識別子）とそれらのデータ内容が格納されている。反映前のＲＤＢと異なるところは、テーブル名がTORIMEISのテーブルにおいて、参照番号１０１で示す１つのキー番号（連結識別子）0000000001,0000000010,00001の反映前のデータ内容が参照番号１０２で示す同一キー番号（連結識別子）の反映後のデータ内容に変更され、かつテーブル名がTEIKIKOZのテーブルに、参照番号１０３で示す１つのキー番号（連結識別子）0000000001,0000000010とそのデータ内容が追加されたことである。
【００５１】
（付記１） ネットワークデータベースにおけるレコードの更新をリレーショナルデータベースに反映させるデータベース更新情報の反映システムにおいて、
前記ネットワークデータベースに階層構造で格納される各レコードに対し、レコード名と、同一親レコードの子レコードが互いに識別可能となるような識別子とを設定する手段と、
前記レコードの更新毎に、更新するレコードに対応する前記レコード名および前記レコードの最上位階層から当該レコードの階層までの各識別子を含む該レコードの更新情報を蓄積する蓄積手段と、
前記リレーショナルデータベースに表構造で格納される各テーブルに対し、前記レコード名に対応するテーブル名および前記レコードの最上位階層から当該レコードの階層までの各識別子をひとつながりにした連結識別子を設定する手段と、
所定の周期で、前記テーブル名と前記連結識別子とから前記リレーショナルデータベース内のテーブルを特定し、該テーブルを前記レコードの更新情報で更新する手段と、
を備えたことを特徴とするデータベース更新情報の反映システム。
【００５２】
（付記２） 前記蓄積手段は、予め設定したリレーショナルデータベースへの更新対象のレコードに対してのみ該レコードの更新時のデータを蓄積する、請求項１に記載のデータベース更新情報の反映システム。
【００５３】
（付記３） 前記蓄積手段は、前記レコードの更新毎に、今回更新対象のレコードが前記蓄積手段に蓄積されたレコード内に有るか無いかを判定し、有ると判定されたときは該レコードの最新のデータを蓄積し、無いと判定されたときは今回更新対象のレコードのデータを蓄積する、請求項１または２に記載のデータベース更新情報の反映システム。
【００５４】
（付記４） 前記蓄積手段は、前記蓄積されたレコード内に今回更新対象のレコードが有るか無いかの判定を、該今回更新対象のレコードの前記レコード名および前記連結識別子が前記蓄積された各レコードの前記レコード名および前記連結識別子に一致するか否かにより判定する、請求項３に記載のデータベース更新情報の反映システム。
【００５５】
（付記５） 前記最新のデータは、今回更新対象のレコードの更新区分と該レコードに一致した前記蓄積されたレコード内のレコードの更新区分とに応じて決定される、請求項４に記載のデータベース更新情報の反映システム。
【００５６】
（付記６） 前記テーブル名は、前記レコード名と同一名称である、付記１乃至５の何れか一つに記載のデータベース更新情報の反映システム。
【００５７】
（付記７） ネットワークデータベースにおけるレコードの更新をリレーショナルデータベースに反映させるデータベース更新情報の反映システムを、
前記ネットワークデータベースに階層構造で格納される各レコードに対し、レコード名と、同一親レコードの子レコードが互いに識別可能となるような識別子とを設定する手段と、
前記レコードの更新毎に、更新するレコードに対応する前記レコード名および前記レコードの最上位階層から当該レコードの階層までの各識別子を含む該レコードの更新情報を蓄積する蓄積手段と、
前記リレーショナルデータベースに表構造で格納される各テーブルに対し、前記レコード名に対応するテーブル名および前記レコードの最上位階層から当該レコードの階層までの各識別子をひとつながりにした連結識別子を設定する手段と、
所定の周期で、前記テーブル名と前記連結識別子とから前記リレーショナルデータベース内のテーブルを特定し、該テーブルを前記レコードの更新情報で更新する手段と、
して機能させるためのプログラムを備えたことを特徴とするデータベース更新情報の反映プログラム。
【００５８】
【発明の効果】
以上説明したように、本発明のデータベース更新情報の反映システムおよびそのためのプログラムによれば、計算機負荷が少なくデータベース更新情報の反映処理を簡素化したので、基幹系データベース（ネットワークデータベース：ＮＤＢ）のデータ更新内容を迅速かつ効率的に情報系データベース（リレーショナルデータベース：ＲＤＢ）に反映することができる。
【００５９】
本発明によれば、データベース更新情報の反映処理時間を短縮でき、それゆえ頻繁に更新処理ができるようになる。具体的には従来日毎にＮＤＢの情報をＲＤＢに反映していたが、本発明では数十分から１時間毎に最新情報が反映可能となるので、ＲＤＢの情報の鮮度が高くなり経営分析等の利用に有効となる。
【００６０】
また、本発明によれば、ＮＤＢの更新データの内でＲＤＢに反映する必要のない更新データを排除する構成を設けたので、効率的なデータ反映が可能となる。
【図面の簡単な説明】
【図１】本発明によるデータベース更新情報の反映システムの一実施形態の概略構成図である。
【図２】図１に示すＮＤＢ更新情報蓄積部４２に蓄積されるデータであるＮＤＢ更新情報の具体例を示す図である。
【図３】図１に示すＮＤＢ５１の具体例を示す図である。
【図４】（Ａ）はＲＤＢのキー設定の基本形を示す図であり、（Ｂ）は図３に示すＮＤＢのレコード３１１に対応するＲＤＢのキー設定を具体的に示す図である。
【図５】図１に示すＲＤＢ５２から抽出されるテーブルの具体例を示す図である。
【図６】図１に示すＲＤＢ反映対象テーブル５３の具体例を示す図である。
【図７】本発明によるＮＤＢ更新処理のフローチャートである。
【図８】本発明による塗替パターンを説明するための図である。
【図９】本発明によるＲＤＢ更新処理のフローチャートである。
【図１０】オンライン上のＮＤＢの具体例を示す図である。
【図１１】取引ログの具体例を示す図である。
【図１２】図１１に示す取引ログがＲＤＢに反映されるときの図１０に示すＮＤＢに対応するＲＤＢの状態を示す図であり、（Ａ）は反映前のＲＤＢの状態を示す図であり、（Ｂ）は反映後のＲＤＢの状態を示す図である。
【符号の説明】
１…ＣＰＵ
２…入力部
３…出力部
４…内部記憶部
５…外部記憶部
６…通信部
１０…データベース更新情報反映システム
４１…ＮＤＢ更新処理部
４２…ＮＤＢ更新情報蓄積部
４３…ＲＤＢ更新処理部
５１，１５１…ネットワークデータベース（ＮＤＢ）
５２…リレーショナルデータベース（ＲＤＢ）
５３…ＲＤＢ対象テーブル
５４，１５４…取引ログ
Claims (2)
- ネットワークデータベースにおけるレコードの更新をリレーショナルデータベースに反映させるデータベース更新情報の反映システムであって、
リレーショナルデータベースに更新を反映させるネットワークデータベースのレコード名を格納する反映対象テーブルと、
ネットワークデータベースのレコードのレコード名と、該レコードの最上位階層から当該レコードの階層までの各識別子と、追加、変更、削除、および、出力なしの何れかの更新区分と、該レコードの更新データの情報を含む該レコードの更新情報を蓄積格納する更新情報蓄積部と、
前記ネットワークデータベースに格納される各レコードの更新時に、前記反映対象テーブルに、該更新対象のレコードのレコード名に一致するものがあった場合に、前記更新情報蓄積部内に該更新対象のレコードのレコード名および該レコードの最上位階層から当該レコードの階層までの各識別子と合致するものが存在するか検索する検索手段と、
前記検索手段による検索の結果、前記更新情報蓄積部に前記更新対象のレコードのレコード名および該レコードの最上位階層から当該レコードの階層までの各識別子と合致するものが存在しない場合に、
該更新対象のレコードのレコード名および該レコードの最上位階層から当該レコードの階層までの各識別子を含む該レコードの更新情報を前記更新情報蓄積部に蓄積格納する更新情報蓄積手段と、
前記検索手段による検索の結果、前記更新情報蓄積部に前記更新対象のレコードのレコード名および該レコードの最上位階層から当該レコードの階層までの各識別子と合致するものが存在する場合に、
該更新情報蓄積部に格納された該合致するレコードの更新情報に含まれた更新区分と該更新対象のレコードの更新区分について、
前者が追加または変更で後者が変更である場合には、前者の更新データを後者の更新データに更新し、
前者が追加で後者が削除である場合には、前者の更新区分を出力なしに更新し、
前者が変更で後者が削除である場合には、前者の更新区分を削除に更新し、
前者が削除で後者が追加である場合には、前者の更新区分を変更に更新し、前者の更新データを後者の更新データに更新する、塗替処理手段と、
前記蓄積手段に蓄積された前記レコードの更新情報に含まれたレコード名と前記連結識別子とから、前記リレーショナルデータベース内のテーブルを特定し、該テーブルを前記レコードの更新情報で更新する更新手段と、
を備えたことを特徴とするデータベース更新情報の反映システム。 - ネットワークデータベースにおけるレコードの更新をリレーショナルデータベースに反映させるデータベース更新情報の反映システムをコンピュータによって機能させるプログラムであって、
前記データベース更新情報の反映システムは、リレーショナルデータベースに更新を反映させるネットワークデータベースのレコード名を格納する反映対象テーブルと、
ネットワークデータベースのレコードのレコード名と、該レコードの最上位階層から当該レコードの階層までの各識別子と、追加、変更、削除、および、出力なしの何れかの更新区分と、該レコードの更新データの情報を含む該レコードの更新情報を蓄積格納する更新情報蓄積部と、を備え、
前記プログラムは、
コンピュータを、
前記ネットワークデータベースに格納される各レコードの更新時に、前記反映対象テーブルに、該更新対象のレコードのレコード名に一致するものがあった場合に、前記更新情報蓄積部内に該更新対象のレコードのレコード名および該レコードの最上位階層から当該レコードの階層までの各識別子と合致するものが存在するか検索する検索手段と、
前記検索手段による検索の結果、前記更新情報蓄積部に前記更新対象のレコードのレコ ード名および該レコードの最上位階層から当該レコードの階層までの各識別子と合致するものが存在しない場合に、
該更新対象のレコードのレコード名および該レコードの最上位階層から当該レコードの階層までの各識別子を含む該レコードの更新情報を前記更新情報蓄積部に蓄積格納する更新情報蓄積手段と、
前記検索手段による検索の結果、前記更新情報蓄積部に前記更新対象のレコードのレコード名および該レコードの最上位階層から当該レコードの階層までの各識別子と合致するものが存在する場合に、
該更新情報蓄積部に格納された該合致するレコードの更新情報に含まれた更新区分と該更新対象のレコードの更新区分について、
前者が追加または変更で後者が変更である場合には、前者の更新データを後者の更新データに更新し、
前者が追加で後者が削除である場合には、前者の更新区分を出力なしに更新し、
前者が変更で後者が削除である場合には、前者の更新区分を削除に更新し、
前者が削除で後者が追加である場合には、前者の更新区分を変更に更新し、前者の更新データを後者の更新データに更新する、塗替処理手段と、
前記蓄積手段に蓄積された前記レコードの更新情報に含まれたレコード名と前記連結識別子とから、前記リレーショナルデータベース内のテーブルを特定し、該テーブルを前記レコードの更新情報で更新する更新手段と、
して機能させることを特徴とするプログラム。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002007803A JP4152107B2 (ja) | 2002-01-16 | 2002-01-16 | データベース更新情報の反映システムおよびそのためのプログラム |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002007803A JP4152107B2 (ja) | 2002-01-16 | 2002-01-16 | データベース更新情報の反映システムおよびそのためのプログラム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2003208346A JP2003208346A (ja) | 2003-07-25 |
| JP4152107B2 true JP4152107B2 (ja) | 2008-09-17 |
Family
ID=27646223
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2002007803A Expired - Lifetime JP4152107B2 (ja) | 2002-01-16 | 2002-01-16 | データベース更新情報の反映システムおよびそのためのプログラム |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP4152107B2 (ja) |
Families Citing this family (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP4704736B2 (ja) * | 2004-11-04 | 2011-06-22 | 新日鉄ソリューションズ株式会社 | データ処理装置、データ処理方法及びそのプログラム |
| JP5748711B2 (ja) * | 2012-07-25 | 2015-07-15 | 株式会社三菱東京Ｕｆｊ銀行 | データベースドライバおよびプログラム |
| JP6260339B2 (ja) * | 2014-02-24 | 2018-01-17 | 富士通株式会社 | 情報処理装置，データ変換プログラム，及びデータ変換方法 |
| WO2017078158A1 (ja) * | 2015-11-06 | 2017-05-11 | 株式会社野村総合研究所 | データ管理システム |
| CN119719108A (zh) * | 2024-12-05 | 2025-03-28 | 南京航空航天大学 | 数据预处理方法、系统、设备及可读存储介质 |
-
2002
- 2002-01-16 JP JP2002007803A patent/JP4152107B2/ja not_active Expired - Lifetime
Also Published As
| Publication number | Publication date |
|---|---|
| JP2003208346A (ja) | 2003-07-25 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US10846277B1 (en) | Journaled tables in database systems | |
| US9292573B2 (en) | Extended database engine providing versioning and embedded analytics | |
| US7672966B2 (en) | Adding extrinsic data columns to an existing database schema using a temporary column pool | |
| JP4594306B2 (ja) | 自己記述型ビジネスオブジェクト | |
| CN1746893B (zh) | 事务文件系统 | |
| US5870733A (en) | Automated system and method for providing access data concerning an item of business property | |
| Harrington | Relational database design clearly explained | |
| US20080091704A1 (en) | Time-addressed database management system | |
| US20090287737A1 (en) | Architecture for enabling rapid database and application development | |
| JP2006528801A (ja) | サービス指向ビジネスフレームワークのサービス管理 | |
| Narang | Database management systems | |
| US7958031B2 (en) | Apparatus, system, and method for automated identity relationship maintenance | |
| US20090300037A1 (en) | Enhanced database structure configuration | |
| CN113986974A (zh) | 一种数据库事务管理方法及装置、恢复方法及装置 | |
| CN113886505B (zh) | 一种基于搜索引擎和关系型数据库实现动态建模的管理系统 | |
| JP4152107B2 (ja) | データベース更新情報の反映システムおよびそのためのプログラム | |
| US20070255685A1 (en) | Method and system for modelling data | |
| US7653663B1 (en) | Guaranteeing the authenticity of the data stored in the archive storage | |
| JP5033322B2 (ja) | 連結関係情報を用いた情報管理方法及び装置 | |
| US20030200220A1 (en) | Method, system, and program product for the implementation of an attributegroup to aggregate the predefined attributes for an information entity within a content management system | |
| Hobbs et al. | Rdb: a comprehensive guide | |
| Oxborrow et al. | Object-oriented data management in specialized environments | |
| Carter | Choosing MongoDB | |
| WO2007049289A2 (en) | Method and system for re-population of data in a database | |
| Jain | Database management systems |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20040825 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20080129 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20080205 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20080407 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20080603 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20080701 |
|
| R150 | Certificate of patent or registration of utility model |
Ref document number: 4152107 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110711 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110711 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120711 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120711 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130711 Year of fee payment: 5 |
|
| EXPY | Cancellation because of completion of term |