JPH07244605A

JPH07244605A - データベースシステム及びその更新方法

Info

Publication number: JPH07244605A
Application number: JP6033930A
Authority: JP
Inventors: Toshihiko Masumoto; 敏彦増本
Original assignee: Fujitsu Ltd
Current assignee: Fujitsu Ltd
Priority date: 1994-03-03
Filing date: 1994-03-03
Publication date: 1995-09-19
Also published as: US5764978A

Abstract

(57)【要約】【目的】ネットワークデータベースにおけるデータ更
新の内容を迅速にリレーショナルデータベースに反映す
ることができるデータベースシステムを提供する【構成】ネットワークデータベース（１００）に更新が
加えられた時には、その更新ログデータが更新ログデー
タ獲得手段（１０３）により獲得される。アドレス格納
位置検索手段（１０４）は、この更新ログデータに含ま
れるアドレスから、アドレステーブル（１０２）におけ
る当該アドレスの格納位置を検索する。このアドレス格
納位置はリレーショナルデータベースと対応が付けられ
ている。従って、更新位置特定手段（１０５）は、検索
されたアドレス格納位置に基づいて、リレーショナルデ
ータベース（１０１）上のデータの位置を特定すること
ができる。データ更新手段（１０６）は、このデータを
更新して、ネットワークデータベース（１００）の更新
内容をリレーショナルデータベース（１０１）に反映さ
せる。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、ネットワークデータベ
ースとリレーショナルデータベースとからなるデータベ
ースシステム及びその更新方法に関する。

【０００２】

【従来の技術】従来より、データベースとして、ネット
ワークデータベース及びリレーショナルデータベースが
各々知られている。

【０００３】このネットワークデータベースは、ネット
ワークモデルに基づいたデータベースである。このネッ
トワークモデルは、データを階層構造にするとともに、
複数の上位レコードを許す網構造としたものである。こ
のネットワークデータベースは、概念的には、データの
親子関係が木として表される。

【０００４】また、リレーショナルデータベースは、関
係モデルに基づいたデータベースである。この関係モデ
ルは、データの構造を２次元の表形式で表現するもの
で、行が個々の実体と対応し、列が各々の属性と対応す
る。

【０００５】これらのうち、ネットワークデータベース
は高速な検索が可能であるので、データ使用者がアクセ
スを行うのに適している。これに対して、リレーショナ
ルデータベースは大容量であるので管理者が情報系操作
を行うのに適している。従って、これらデータベースの
双方の利点を享受するために、ネットワークデータベー
ス及びリレーショナルデータベースの両方を共存させた
データベースシステムを構築することが望ましい。

【０００６】但し、この場合には、両データベースのデ
ータ内容を一致させる必要がある。例えば、ネットワー
クデータベースに格納されている特定のデータを更新し
た場合には、同時に、リレーショナルデータベースに格
納されたこの特定のデータに対応するデータを更新し、
その更新内容をリレーショナルデータベースに反映させ
る必要がある。もっとも、ネットワークデータベースの
データを更新する毎にリレーショナルデータベースの内
容を更新するのは、データ更新の頻度からみて合理的で
ない。そのため、ある程度更新すべきデータが貯まった
時点で一括してリレーショナルデータベースの更新する
ことになる。

【０００７】

【発明が解決しようとする課題】ところが、従来用いら
れたデータベースシステムにおけるデータ反映方法は、
そのオーナー位置（最上層位置）のデータから最下層位
置のデータまでを一つのデータのつながりとみなさなけ
れば、ネットワークデータベースのデータを抽出できな
いというものであった。即ち、その中の一部のデータの
みを抽出することができないというものであった。

【０００８】従って、ネットワークデータベース上で更
新されたのが任意の位置のレコードタイプ（データベー
スのアクセスの単位）の一つであっても、上記したオー
ナー位置から最下層までのデータのつながりに基づい
て、リレーショナルデータベース全体を、再度書き換え
なければならなかった。

【０００９】このように、従来のデータベースシステム
においては、両データベースの整合性をとるためだけ
に、リレーショナルデータベースの構築に要するのと同
じ時間を要していた。従って、両データベースの整合を
とる頻度は必然的に制限され、両データベース間の内容
のギャップ・更新のタイムラグが大きくなっていた。ま
た、両データベース間の整合に長時間を要するので、そ
れだけデータ障害が生じる危険が大きくなっていた。

【００１０】本発明は、上述した従来の問題点を解決
し、ネットワークデータベースにおけるデータ更新の内
容を迅速にリレーショナルデータベースに反映すること
ができるデータベースシステム及びその更新方法を提供
することを主たる課題とする。

【００１１】本発明の選択的な他の課題は、ネットワー
クデータベースにおけるデータ更新の内容を、リレーシ
ョナルデータベースの一部の更新のみでリレーショナル
データベースに反映することができるデータベースシス
テム及びその更新方法を提供することである。

【００１２】

【課題を解決するための手段】本発明は、前記課題を解
決するため、図１（ａ）の発明原理図に示した通り、以
下の手段を採用した。

【００１３】＜本発明の要旨＞本発明によるデータベー
スシステムは、データを階層形式で有するネットワーク
データベース（１００）と、このネットワークデータベ
ース（１００）のデータ階層に対応して各データを表形
式で有するリレーショナルデータベース（１０１）とを
備えている。

【００１４】本発明は、このネットワークデータベース
（１００）のリレーショナルデータベース（１０１）へ
の反映を、迅速かつ円滑に行うものである。このため、
本発明はアドレステーブル（１０２）、更新ログデータ
獲得手段（１０３）、アドレス格納位置検索手段（１０
４）、更新位置特定手段（１０５）、データ更新手段
（１０６）を備える。

【００１５】〔ネットワークデータベース〕本発明にお
けるネットワークデータベース（１００）は、データを
階層形式で関連付けたデータベースである。従って、本
発明におけるネットワークデータベース（１００）は、
いわゆる階層データベースをも含む概念である。但し、
ネットワークデータベース（１００）を、データの網構
造を持つものとすることもできる。このようにすれば、
リレーショナルデータベース（１０１）で規定できるデ
ータ間の関連を、全てネットワークデータベース（１０
０）において網羅することができる。

【００１６】〔リレーショナルデータベース〕本発明に
おけるリレーショナルデータベース（１０１）は、ネッ
トワークデータベース（１００）のデータ階層に対応し
て各データを表形式で有するデータベースである。この
リレーショナルデータベース（１０１）を構成する表
（テーブル）の数は、一つに限るものではない。即ち、
相互の結合条件又はネットワークデータベース（１０
０）との対応がとれていれば、複数個あってもよい。

【００１７】〔ネットワークデータベースとリレーショ
ナルデータベースとの関係〕本発明において、ネットワ
ークデータベース（１００）のデータはリレーショナル
データベース（１０１）へと反映されて使用される。こ
れは、末端ユーザとしてはネットワークデータベース
（１００）でデータの更新を行う方がその高速性故に使
い勝手がよい反面、データの管理者側としては、リレー
ショナルデータベース（１０１）の方が管理しやすいか
らである。

【００１８】〔アドレステーブル〕本発明におけるアド
レステーブル（１０２）は、前記ネットワークデータベ
ース（１００）の各データのアドレスを上位データ階層
から下位データ階層に至るレコード毎に行として表した
表形式で格納するとともに、各データのアドレス格納位
置とリレーショナルデータベース（１０１）のデータ位
置とを対応させている。この対応を行うために、リレー
ショナルデータベース（１０１）及びアドレステーブル
（１０２）の双方にユニーク性表示部を付し、両者の対
応する行のユニーク性表示部を同じ値としても良い。こ
のようにすれば、アドレステーブル（１０２）とリレー
ショナルデータベース（１０１）とを各々別に管理でき
る効果が得られる他、両者におけるデータ（レコード）
の順番を任意にできる効果を得られる。なお、アドレス
テーブル（１０２）とリレーショナルデータベース（１
０１）とを結合して、一つの表とすることによって両者
を対応付けるようにしても良い。また、別の表とする場
合でも、アドレステーブルをリレーショナルデータベー
ス（１０１）に含ませるようにしても良い。

【００１９】〔更新ログデータ獲得手段〕前記更新ログ
データ獲得手段（１０３）は、前記ネットワークデータ
ベース（１００）のデータ更新がなされたとき、更新デ
ータのアドレス及び更新内容を含む更新ログデータを獲
得する。なお、本発明における「更新」とは、データの
変更，追加，及び削除を含む概念である。

【００２０】〔アドレス格納位置検索手段〕アドレス格
納位置検索手段（１０４）は、更新ログデータ獲得手段
（１０３）で獲得した更新ログデータに従って前記アド
レステーブル（１０２）における更新データのアドレス
格納位置を検索する。この検索は、更新データのアドレ
スが含まれている行のみを検索するものであっても良い
し、行と列を検索するものであっても良い。前者の場合
には、アドレスーブル（１０２）の列毎に予めカラム名
を付しておくと共に、アドレスとこのカラム名との対応
関係を規定した情報テーブルを用意しておき、アドレス
に対応するカラム名とアドレスとから行を特定すれば良
い。

【００２１】〔更新位置特定手段〕更新位置特定手段
（１０５）は、アドレス格納位置検索手段（１０４）で
検索したアドレステーブル（１０２）上の更新データの
アドレスに対応するリレーショナルデータベース（１０
１）上のデータの位置を特定する。アドレステーブル
（１０２）とリレーショナルデータベース（１０１）と
の対応をとるためにユニーク性表示部を設けた場合に
は、更新位置検索手段はこのユニーク性表示部を参照
し、ネットワークデータベース（１００）の更新データ
に対応するリレーショナルデータベース（１０１）上の
データ位置を特定する。アドレス格納位置検索手段（１
０４）が行のみを検索する場合には、更新位置特定手段
（１０５）は、対応する行を特定すると共に更新ログデ
ータを参照してその列を特定する。

【００２２】〔データ更新手段〕データ更新手段（１０
６）は、前記更新位置特定手段（１０５）により特定さ
れたリレーショナルデータベース（１０１）上の位置に
おけるデータを、前記更新ログに従って更新する。

【００２３】＜本発明の方法＞本発明のデータベースシ
ステムの更新方法は、データを階層形式で有するネット
ワークデータベース（１００）と、このネットワークデ
ータベース（１００）の上位データ階層から下位データ
階層に至るレコード毎に行として表した表形式により前
記ネットワークデータベース（１００）と同じデータを
格納するリレーショナルデータベース（１０１）とを合
わせ持つデータベースシステムにおいて、前記各データ
のアドレスと前記リレーショナルデータベース（１０
１）のデータ位置とをアドレステーブル（１０２）によ
り特定することにより、前記ネットワークデータベース
（１００）と前記リレーショナルデータベース（１０
１）との関係を対応づけておく（図１（ａ）参照）。

【００２４】そして、前記ネットワークデータベース
（１００）のデータ更新がなされたとき、更新データの
アドレス及び更新内容を含む更新ログデータを獲得する
（図１（ｂ）参照）。

【００２５】そして、この更新ログデータに従って、前
記アドレステーブル（１０２）における更新データのア
ドレス格納位置を検索する（図１（ｃ）（１）参照）。
次いで、そのアドレス格納位置に対応するリレーショナ
ルデータベース（１０１）上のデータを特定する（図１
（ｃ）（２）参照）。

【００２６】最後に、リレーショナルデータベース（１
０１）上において更新すべきものとして特定されたデー
タを更新ログデータに従って更新する（図１（ｄ）参
照）。＜本発明の利用可能性＞本発明は、ネットワークデータ
ベースと、リレーショナルデータベースとを併用するデ
ータベースシステムを前提としており、銀行における預
金システム等にに利用可能である。

【００２７】

【作用】ネットワークデータベース（１００）に格納さ
れたデータに関して更新が行われた時には、その更新さ
れたデータのアドレス及び更新の内容を含む更新ログデ
ータが更新ログデータ獲得手段（１０３）により獲得さ
れる。

【００２８】アドレス格納位置検索手段（１０４）は、
この更新ログデータを受信する。そして、更新ログデー
タに含まれる更新データのアドレスから、アドレステー
ブル（１０２）において当該アドレスがどこに格納され
ているかを検索する。このアドレス格納位置はリレーシ
ョナルデータベースと対応が付けられている。

【００２９】従って、更新位置特定手段（１０５）は、
アドレス格納位置検索手段（１０４）により検索された
アドレス格納位置に基づいて、リレーショナルデータベ
ース（１０１）上のデータの位置を特定することができ
る。

【００３０】この位置はネットワークデータベース（１
００）に格納されている更新されたデータと同じデータ
が予め表形式で格納されている。よって、データ更新手
段（１０６）は、このデータを更新して、ネットワーク
データベース（１００）の更新内容をリレーショナルデ
ータベース（１０１）に反映させることができる。

【００３１】

【実施例】以下、本発明の実施例を図面を参照して説明
する。

【００３２】

【実施例１】＜システム構成＞図２に、本発明の第１実施例によるデ
ータベースシステムの構成図を示す。

【００３３】図２において、データベースシステム全体
の管理を行うの管理プログラム１３は、オペレーション
システム１２上で動く。この管理プログラム１３の一部
に、更新に関する各種制御を行う更新管理プログラム１
４が含まれている。

【００３４】ネットワークデータベース１は、ＮＤＢマ
ネージャ２により管理される。このＮＤＢマネージャ２
は、管理プログラム１３により制御され、応用プログラ
ム１５からの要求に応じてネットワークデータベース１
を検索する。そして、得られたデータを応用プログラム
１５に回答するとともに、必要に応じてネットワークデ
ータベース１に格納されたデータを更新する。データの
更新を行った場合には、ＮＤＢマネージャ２は更新のた
めのコマンドを、ログデータとして履歴ログファイル３
に格納する。なお、このログデータは、ＮＤＬ文で記載
されている。

【００３５】抽出部４は、更新管理プログラム１４によ
り制御され、履歴ログファイル３に蓄積されたログデー
タから必要なデータを抽出する。通信部５は、更新管理
プログラム１４により制御され、抽出部４により抽出さ
れたデータを通信用の形式に変換して、リレーショナル
データベース側に送信する。

【００３６】更新ログ作成部６は、更新管理プログラム
１４により実行される入力タスクにより制御・管理され
る。即ち、更新ログ作成部６は、通信部５からのデータ
を受信すると、このデータに基づいて更新ログを作成す
る。この更新ログは、更新されたデータのネットワーク
データベース上のアドレス値（自アドレス），更新され
たデータの上位階層に位置するデータ（親データ）のア
ドレス値（上位アドレス），更新後のデータの実体値，
及び更新方法（変更，挿入，又は削除）から構成され
る。作成された更新ログは、更新ログファイル７内に蓄
積される。この更新ログファイル７内の更新ログ蓄積状
況も、更新管理プログラムによる入力タスクにより管理
される。以上のＮＤＢマネージャ２乃至更新ログ作成部
６が、更新ログデータ獲得手段１０３に相当する。

【００３７】更新部９は、更新管理プログラム１４によ
り実行される更新タスクにより制御される。即ち、更新
部９は、更新ログファイル７から更新ログを時系列順に
一つづつ取り出し、その更新ログの内容に応じてＲＢＢ
マネージャ１０を介してリレーショナルデータベース１
１を更新する。この更新部９が、アドレス検索手段１０
４，更新位置特定手段１０５，データ更新手段１０６に
相当する。

【００３８】リレーショナルデータベース１１には、本
来のリレーショナルデータベース１０１としての実テー
ブル１７，及びネットワークデータベース１と実テーブ
ル１７との対応をとるためのアドレステーブル１６が格
納されている。このリレーショナルデータベース１１
は、ＲＤＢマネージャ１０により管理される。このＲＤ
Ｂマネージャ１０は、管理プログラム１３により制御さ
れる。なお、更新部９は、リレーショナルデータベース
１１の更新を行うに際して、情報ファイルとしてのＭＡ
Ｐ情報ファイル８の内容を参照する。このＭＡＰ情報フ
ァイル８には、アドレスに対するアドレステーブル１６
及び実テーブル１７上のカラム名の一覧テーブルが格納
されている。＜ネットワークデータベース１のデータ構成＞図３は、
ネットワークデータベース１内のデータ構造の例を示す
図である。図３に示すように、ネットワークデータベー
ス１内において、各データは、階層構造となるように相
互に関連付けられている。これら各階層の各々には、そ
の階層のデータ（実体値）に共通の属性が与えられてい
る。本実施例においては、最上位階層（オーナ位置，エ
ントリ）Ａの属性が「社名」とされ、その実体値が“富
士通（アドレス値＝ａ１）”となっている。また、２階
層目Ｂの属性が「部署」とされ、その実体値が“２開発
部（アドレス値＝ｂ１）”及び“１開発部（アドレス値
＝ｂ２）”となっている。また、３階層目Ｃの属性が
「課名」とされ、その実体値が“３開発課（アドレス値
＝ｃ１）”，“４開発課（アドレス値＝ｃ２）”，及び
“２開発課（アドレス値＝ｃ３）”となっている。ま
た、４階層目Ｄの属性が「氏名」とされ、その実体値が
“小田康貴（アドレス値＝ｄ１）”，“木村雄三（アド
レス値＝ｄ２）”，“増本敏彦（アドレス値＝ｄ
３）”，及び“鎌田豊（アドレス値＝ｄ４）”となって
いる。

【００３９】なお、本実施例では、上述したようにオー
ナ位置のデータが一つ（“富士通”）だけであり、か
つ、下位階層のデータは各々唯１つの上位階層のデータ
（親データ）に対して関連付けられている。即ち、逆ツ
リー（木）型の構造となっている。このツリーの枝，即
ちオーナ位置のデータから特定の最下位層のデータに至
るまでの繋がりの各々を、レコードという。

【００４０】また、図３における各階層内における横向
きの矢印は、実体値間の論理順を示している。＜アドレステーブル１６のデータ構造＞図４は、アドレ
ステーブル１６内のデータ構造の例を示す図である。こ
のアドレステーブル１６は、リレーショナルデータベー
ス１１内に追加されたテーブルである。アドレステーブ
ル１６は、ネットワークデータベース１の更新に先立つ
初期抽出時に、ネットワークデータベース１の各レコー
ドタイプのアドレス値を元にして作成される。

【００４１】このアドレステーブル１６は、行がレコー
ドを示し列がカラムを示す２次元の表構成となってい
る。アドレステーブル１６の各レコードは、ネットワー
クデータベース１のレコードの何れかに対応している。
アドレステーブル１６の各カラムのうち「Ａ−ＰＧＳ」
乃至「Ｄ−ＰＧＳ」と名付けられたものは、各々ネット
ワークデータベース１の各階層に対応している。また、
「Ｓ−ＫＥＹ」と名付けられたカラムは、ユニーク性表
示部としての一意性保障カラムである。

【００４２】アドレステーブル１６に書き込まれる情報
は、そのレコード及びカラムに対応するネットワークデ
ータベース１内の位置に書き込まれているデータのアド
レス値である。アドレステーブル１６のレコード数はネ
ットワークデータベース１のレコード数に一致している
ので、同じアドレス値が複数のレコードに重複して書き
込まれている。

【００４３】Ｓ−ＫＥＹカラムに書き込まれている情報
は、各レコードを識別するためのシリアル番号である。＜実テーブル１７（ユーザテーブル）のデータ構造＞図
４は、実テーブル１７内のデータ構造の例を示す図であ
る。この実テーブル１７は、本来のリレーショナルデー
タベースとして実体値を保持するテーブルである。

【００４４】実テーブル１７は、行がレコードを示し列
がカラムを示す２次元の表構成となっている。実テーブ
ル１７の各レコードも、ネットワークデータベース１の
各レコードの何れかに対応している。但し、その順番は
アドレステーブル１６の場合の順番とは必ずしも一致さ
れていない。実テーブル１７の各カラムのうち「開発会
社」乃至「開発者」と名付けられたものは、ネットワー
クデータベース１の各階層の属性に対応している。ま
た、「Ｕ−ＫＥＹ」と名付けられたカラムは、ユニーク
性表示部としての一意性保障カラムである。

【００４５】実テーブル１７に書き込まれる情報は、そ
のレコード及びカラムに対応するネットワークデータベ
ース１内の位置に書き込まれている実体値そのものであ
る。実テーブル１７のレコード数はネットワークデータ
ベース１のレコード数に一致しているので、同じ実体値
が複数のレコードに重複して書き込まれている。Ｕ−
ＫＥＹカラムに書き込まれている情報は、各レコードを
識別するためのシリアル番号である。ネットワークデー
タベース１の同じレコードに対応しているアドレステー
ブル１６のレコード及び実テーブル１７のレコードに
は、同じシリアル番号が付されている。従って、アドレ
ステーブル１６のＳ−ＫＥＹカラムと実テーブル１７の
Ｕ−ＫＥＹカラムとを突き合わせることにより、或るア
ドレステーブル１６のレコードに対応する実テーブル１
７のレコードを特定することができる。＜更新処理フロー＞次に、更新部９において実行される
データ更新のための処理フローを、図６乃至図１２に基
づいて説明する。

【００４６】この処理フローによって示される更新タス
クは、更新ログを管理する入力タスクからの指示によっ
て、処理開始をする。この更新タスクは、ネットワーク
データベース１に関する更新回数がある程度になった任
意の時点において実行される。従って、更新タスク実行
の時点では、ネットワークデータベース１からのログデ
ータには、多数回の更新の記録が含まれている。

【００４７】更新タスクの処理は、先ず、ステップＳ１
０１において、ステップＳＴＡＲＴＳＱＬを発行する。
即ち、ＳＱＬ文に従ってトランザクションを開始するこ
とを宣言する。なお、このＳＱＬは、日本規格協会発行
のデータベース言語ＳＱＬＸ３００５−１９９０，ＪＩ
Ｓハンドブック情報処理ソフトウェア，１９９０に従っ
たデータベース用標準言語である。

【００４８】続くステップＳ１０２では、ＭＡＰ情報フ
ァイル８を検索して、更新ログに含まれるアドレス（自
アドレス及び上位アドレス）に対応する実テーブル１７
上のカラム名を獲得する。

【００４９】続くステップＳ１０３では、ＭＡＰ情報フ
ァイル８を検索して、更新ログに含まれるアドレス（自
アドレス及び上位アドレス）に対応するアドレステーブ
ル１６上のカラム名を獲得する。

【００５０】次に、処理は、ステップＳ１０４からステ
ップＳ１０７，ステップＳ１０８，又はステップＳ１０
９までのループに入る。このループでは、入力タスクか
ら通知される個々の更新ログ毎にステップＳ１０５以下
の処理を実行する。

【００５１】ステップＳ１０４において、入力タスクか
らＥＯＦが通知されているかどうかをチェックする。こ
のＥＯＦは、未処理の更新ログが残っていない事を示す
通知である。ＥＯＦが通知されている場合には、処理を
ステップＳ１１０に進めるが、ＥＯＦが未だ通知されて
いなければ、処理をステップＳ１０５に進める。処理が
最初にこのステップ１０２に入ってきたときには、当然
処理はステップＳ１０５に進む。

【００５２】ステップＳ１０５では、ログデータの形式
を通信用データ形式からＲＤＢ形式にデータ変換する。
即ち、ログデータは、通信用データ形式に変換されて、
通信部５から更新部９へ通信される。そこで、このログ
データをＲＤＢマネージャ１０によって扱えるように、
ＲＤＢ形式にデータ変換するのである。

【００５３】続くステップＳ１０６では、更新ログに含
まれる更新のマクロ種を判定して、判定したマクロ種に
依って処理を分岐させる。即ち、ネットワークデータベ
ース１における命令文は、ＮＤＬ文で記述される。ＮＤ
Ｌ文において、「変更」は“ＭＯＤＩＦＹ”であり、
「挿入」は“ＳＴＯＲＥ”であり、「削除」は“ＥＲＡ
ＳＥ”である（ＳＱＬ文において、それらは、各々“Ｕ
ＰＤＡＴＥ”，“ＩＮＳＥＲＴ”，“ＤＥＬＥＴＥ”で
ある。）。ステップＳ１０６は、この種別を判定して、
“ＳＴＯＲＥ”であれば処理をステップＳ１０７のＳＴ
ＯＲＥマクロ処理に進め、“ＭＯＤＩＦＹ”であれば処
理をステップＳ１０８のＭＯＤＩＦＹマクロ処理に進
め、“ＥＲＡＳＥ”であれば処理をステップＳ１０９の
ＥＲＡＳＥマクロ処理に進める。

【００５４】以上のループを実行した結果、入力タスク
からＥＯＦが通知された場合には、処理はステップＳ１
０４からステップＳ１１０に進む。このステップＳ１１
０においては、ＣＯＭＭＩＴＷＯＲＫＥＮＤＳＱ
Ｌ（ＣＯＭＭＩＴ文）が発行される。このＣＯＭＭＩＴ
文は、それまでのＳＱＬ文の処理を完了させる通知であ
る。このステップＳ１１０を行うと、この更新タスクの
処理は終了する。

【００５５】図７は、図６のステップＳ１０７において
実行されるＳＴＯＲＥマクロ処理のサブルーチンを示
す。図７に入って最初のステップＳ２０１では、現在処
理対象となっている更新ログの更新対象が、ネットワー
クデータベース１における最上位階層に対応するカラム
のデータであるか否かを判定する。

【００５６】最上位階層に対応するカラムのデータであ
る場合には、ステップＳ２０２において、アドレステー
ブル１６に対し、下位カラムのデータを欠測（ＮＵＬ）
として、ＩＮＳＥＲＴを行う。即ち、以下のＳＱＬ文を
発行する。

【００５７】ＩＮＳＥＲＴＩＮＴＯスキーマ名，ア
ドレステーブル名（カラム名１，…，カラム名ｎ）ＶＡＬＵＥＳ（ホスト変数１，…，ホスト変数ｎ）ここで、ｎはアドレステーブル１６のＳ−ＫＥＹ以外の
カラム数である。従って、カラム名には、アドレステー
ブル１６のＳ−ＫＥＹを除く全てのカラムの名前（Ａ−
ＰＧＳ，Ｂ−ＰＧＳ，Ｃ−ＰＧＳ，Ｄ−ＰＧＳ）が書き
込まれる。ホスト変数とは、更新によって書き込まれる
アドレス値である。従って、このＳＱＬ文の内容は、指
名されたアドレステーブル１６のカラム名１，…，カラ
ム名ｎのカラムの各々に、ホスト変数１，…，ホスト変
数ｎの実体値を書き込んで挿入するというものである。
但し、このステップＳ２０２の処理においては、ホスト
変数１のみに更新ログの更新データのアドレス値が書き
込まれ、ホスト変数２以下には欠測値（ＮＵＬ）が書き
込まれる。なお、Ｓ−ＫＥＹのカラムには、一意性規約
により、新規な値が書き込まれる。

【００５８】続くステップＳ２０３においては、実テー
ブル１７に対し、下位カラムのデータを欠測（ＮＵＬ）
として、ＩＮＳＥＲＴを行う。即ち、以下のＳＱＬ文を
発行する。

【００５９】ＩＮＳＥＲＴＩＮＴＯスキーマ名，実テーブル名（カラム名１，…，カラム名ｎ）ＶＡＬＵＥＳ（ホスト変数１，…，ホスト変数ｎ）ここで、ｎはアドレステーブル１６のＵ−ＫＥＹ以外の
カラム数である。従って、カラム名には、アドレステー
ブル１６のＵ−ＫＥＹを除く全てのカラムの名前（開発
会社，事業部，担当課，開発者）が書き込まれる。ホス
ト変数とは、更新によって書き込まれる実体値である。
従って、このＳＱＬ文の内容は、指名された実テーブル
１７のカラム名１，…，カラム名ｎのカラムの各々に、
ホスト変数１，…，ホスト変数ｎの実体値を書き込んで
挿入するというものである。但し、このステップＳ２０
３の処理においては、ホスト変数１のみに更新ログの更
新データの実体値が書き込まれ、ホスト変数２以下には
欠測値が書き込まれる。なお、Ｕ−ＫＥＹのカラムに
は、一意性規約により、ステップＳ２０２において挿入
されたレコードのＳ−ＫＥＹの値と同じ値が書き込まれ
る。

【００６０】ステップＳ２０３の処理を行うと、このサ
ブルーチンを終了して図６に戻り、次の更新ログに対す
る処理を行う。ステップＳ２０１にて最上位階層のカラ
ムでない場合には、ステップＳ２０４において、更新ロ
グに含まれる上位アドレス（ＰＧＣＳ）値を検索キーと
してカーソルをオープンする。即ち、以下のＳＱＬ文を
発行する。

【００６１】ＯＰＥＮカーソル名ＳＥＬＥＣＴ＊ＦＲＯＭスキーマ名，アドレステ
ーブル名，スキーマ名，実テーブル名ＷＨＥＲＥ上位ＰＧＣＳカラム名＝ホスト変数ＡＮＤアドレステーブルのリンクカラム名＝実テ
ーブルのリンクカラム名ここで、上位ＰＧＣＳカラム名は、上位アドレスの階層
に対応するカラムの名前である。また、ホスト変数は、
更新ログに含まれている更新データの上位アドレス値で
ある。アドレステーブル１６のリンクカラム名には、
“Ｓ−ＫＥＹ”が入力される。実テーブル１７のリンク
カラム名には、“Ｕ−ＫＥＹ”が入力される。従って、
このＳＱＬ文の内容は、指名されたアドレステーブル１
６から上位ＰＧＳカラムのアドレスがホスト変数と一致
しているレコードの全データを検索し、指名された実テ
ーブル１７からこのレコードのＳ−ＫＥＹと同じ値のＵ
−ＫＥＹを有するのレコードの全データを検索すること
を内容とするカーソルを宣言するというものである。

【００６２】続くステップＳ２０５では、ＦＥＴＣＨ文
により、実テーブル１７とアドレステーブル１６のデー
タを取得する。即ち、以下のＳＱＬ文を発行する。ＦＥＴＣＨカーソル名ＩＮＴＯホスト変数１，…，ホスト変数ｎここで、ｎはアドレステーブル１６と実テーブル１７の
カラム数を足した数である。なお、ホスト変数には定義
のみを書き込む。従って、このＳＱＬ文の内容は、ステ
ップＳ２０４で宣言したカーソルを実行し、ホスト変数
によって定義したデータを取り出すというものである。

【００６３】続くステップＳ２０６では、カーソルのク
ローズを行う。即ち、以下のＳＱＬ文を発行する。ＣＬＯＳＥカーソル名このＳＱＬ文の内容は、ステップＳ２０４にて宣言した
カーソルの使用の終了を宣言するというものである。

【００６４】続くステップＳ２０７では、ステップＳ２
０５によって取り出したデータ（レコード）が欠測値を
持っているかどうかのチェックを行う。欠測値を持って
いる場合には、処理をステップＳ２０８に進める。この
ステップＳ２０８では、ログデータに含まれる更新後の
実体値を欠測位置に入れて、ステップＳ２０５において
取得したデータを検索キーにして、実テーブル１７に対
するＵＰＤＡＴＥ文を発行する。即ち、以下のＳＱＬ文
を発行する。

【００６５】ＵＰＤＡＴＥスキーマ名，実テーブル名ＳＥＴカラム名＝ホスト変数ＷＨＥＲＥ通常項目カラム名＝ホスト変数シーケンスカラム名＝ホスト変数ここで、カラム名は、更新ログに含まれる自アドレスに
対応するカラムの名前である。また、ホスト変数は、更
新ログに含まれている更新データの実体値である。カラ
ム名は、更新ログに含まれるデータの数だけ指定する。
また、通常項目カラム名とホスト変数には、ステップＳ
２０５にて得られたデータの何れかとそのカラム名を入
力する。また、シーケンスカラム名には“Ｕ−ＫＥＹ”
を入力し、そのホスト変数にはステップＳ２０５にて得
られたＵ−ＫＥＹの値を入力する。従って、このＳＱＬ
文の内容は、指名された実テーブル１７におけるＷＨＥ
ＲＥ条件で特定したレコードの指名されたカラムに、ホ
スト変数の実体値を上書きするというものである。

【００６６】続くステップＳ２０９では、ログデータに
含まれる更新後のデータのアドレスを欠測位置に入れ
て、ログデータに含まれる更新後データの上位アドレス
を検索キーにして、アドレステーブル１６に対するＵＰ
ＤＡＴＥ文を発行する。即ち、以下のＳＱＬ文を発行す
る。

【００６７】ＵＰＤＡＴＥスキーマ名，アドレステーブル名ＳＥＴカラム名＝ホスト変数ＷＨＥＲＥ上位ＰＧＣＳカラム名＝ホスト変数ここで、カラム名は、更新ログに含まれる自アドレスの
階層に対応するカラムの名前である。また、ホスト変数
は、更新ログに含まれている更新データのアドレス値で
ある。また、上位ＰＧＣＳカラム名には、上位アドレス
の階層のカラム名が、そのホスト変数には、その上位ア
ドレスが入力される。従って、このＳＱＬ文の内容は、
指名されたアドレステーブル１６におけるＷＨＥＲＥ条
件で特定したレコードの指名されたカラムに、ホスト変
数のアドレス値を上書きするというものである。

【００６８】ステップＳ２０９の処理を行うと、このサ
ブルーチンを終了して図６に戻り、次の更新ログに対す
る処理を行う。ステップＳ２０７にて欠測値を持ってい
ないと判断した場合には、処理をステップＳ２１０に進
める。ステップＳ２１０では、ステップＳ２０５におい
て検索したレコードに更新データを上書きして、アドレ
ステーブル１６に対してＩＮＳＥＲＴ文を発行する。即
ち、以下のＳＱＬ文を発行する。

【００６９】ＩＮＳＥＲＴＩＮＴＯスキーマ名，ア
ドレステーブル名（カラム名１，…，カラム名ｎ）ＶＡＬＵＥＳ（ホスト変数１，…，ホスト変数ｎ）ここで、ｎはアドレステーブル１６のＳ−ＫＥＹ以外の
カラム数である。従って、カラム名には、アドレステー
ブル１６のＳ−ＫＥＹを除く全てのカラムの名前（Ａ−
ＰＧＳ，Ｂ−ＰＧＳ，Ｃ−ＰＧＳ，Ｄ−ＰＧＳ）が書き
込まれる。ホスト変数とは、更新によって書き込まれる
アドレス値である。従って、このＳＱＬ文の内容は、指
名されたアドレステーブル１６のカラム名１，…，カラ
ム名ｎのカラムの各々に、ホスト変数１，…，ホスト変
数ｎのアドレス値を書き込んで挿入するというものであ
る。但し、このステップＳ２１０の処理においては、更
新ログに含まれる更新データのアドレス値を対応するホ
スト変数に書き込み、更新データのカラムよりも下位の
カラムのホスト変数には欠測値（ＮＵＬ）を書き込み、
その他のホスト変数にはステップＳ２０５において取り
出されたアドレス値を書き込む。なお、Ｓ−ＫＥＹのカ
ラムには、一意性規約により、新規な値が書き込まれ
る。

【００７０】続くステップＳ２１１においては、ステッ
プＳ２０５において検索したレコードに更新データを上
書きして、実テーブル１７に対してＩＮＳＥＲＴ文を発
行する。即ち、以下のＳＱＬ文を発行する。

【００７１】ＩＮＳＥＲＴＩＮＴＯスキーマ名，実テーブル名（カラム名１，…，カラム名ｎ）ＶＡＬＵＥＳ（ホスト変数１，…，ホスト変数ｎ）ここで、ｎは実テーブル１７のＵ−ＫＥＹ以外のカラム
数である。従って、カラム名には、アドレステーブル１
６のＵ−ＫＥＹを除く全てのカラムの名前（開発会社，
事業部，担当課，開発者）が書き込まれる。ホスト変数
とは、更新によって書き込まれる実体値である。従っ
て、このＳＱＬ文の内容は、指名された実テーブル１７
のカラム名１，…，カラム名ｎのカラムの各々に、ホス
ト変数１，…，ホスト変数ｎの実体値を書き込んで挿入
するというものである。但し、このステップＳ２１１の
処理においては、更新ログに含まれる更新データの実体
値を対応するホスト変数に書き込み、更新データのカラ
ムよりも下位のカラムのホスト変数には欠測値（ＮＵ
Ｌ）を書き込み、その他のホスト変数にはステップＳ２
０５において取り出された実体値を書き込む。なお、Ｕ
−ＫＥＹのカラムには、一意性規約により、ステップＳ
２１０において挿入されたレコードのＳ−ＫＥＹの値と
同じ値が書き込まれる。

【００７２】ステップＳ２１１の処理を行うと、このサ
ブルーチンを終了して図６に戻り、次の更新ログに対す
る処理を行う。図８は、図６のステップＳ１０８におい
て実行されるＭＯＤＩＦＹマクロ処理のサブルーチンを
示す。

【００７３】図８に入って最初のステップＳ３０１で
は、現在処理対象となっている更新ログに含まれる自ア
ドレス（ＰＧＣＳ）値を検索キーとしてカーソルをオー
プンする。即ち、以下のＳＱＬ文を発行する。

【００７４】ＯＰＥＮカーソル名ＳＥＬＥＣＴ＊ＦＲＯＭスキーマ名，アドレステ
ーブル名，ＷＨＥＲＥ自ＰＧＣＳカラム名＝ホスト変数ここで、自ＰＧＣＳカラム名は、自アドレスの階層に対
応するカラムの名前である。また、ホスト変数は、更新
ログに含まれている更新データのアドレス値である。従
って、このＳＱＬ文の内容は、指名されたアドレステー
ブル１６から指定されたＰＧＳカラムのアドレスがホス
ト変数と一致しているレコードの全データを取り出すこ
とを内容とするカーソルを宣言するというものである。

【００７５】続いて処理は、ステップＳ３０２からステ
ップＳ３０６までのループに入る。ステップＳ３０２で
は、ＦＥＴＣＨ文により、アドレステーブル１６のデー
タを取得する。即ち、以下のＳＱＬ文を発行する。

【００７６】ＦＥＴＣＨカーソル名ＩＮＴＯホスト変数１，…，ホスト変数ｎここで、ｎはアドレステーブル１６のカラム数である。
なお、ホスト変数には定義のみを書き込む。従って、こ
のＳＱＬ文の内容は、ステップＳ３０２で宣言したカー
ソルを実行し、ホスト変数によって定義したデータを取
り出すというものである。

【００７７】続くステップＳ３０３では、ステップＳ３
０２による検索の結果として、カーソルの定義に該当す
るデータが存在しているかどうかを判定する。該当デー
タが存在していないときには、処理をステップＳ３０７
に進める。

【００７８】ステップＳ３０３にて該当データを発見で
きた場合には、処理をステップＳ３０４に進める。この
ステップＳ３０４では、ログデータを対応するカラムに
入れ、ステップＳ３０２において取り出したデータを検
索キーとして、実テーブル１７に対するＵＰＤＡＴＥ文
を発行する。即ち、以下のＳＱＬ文を発行する。

【００７９】ＵＰＤＡＴＥスキーマ名，実テーブル名ＳＥＴカラム名＝ホスト変数ＷＨＥＲＥ自レコードのカラム名＝ホスト変数ここで、カラム名は、更新ログに含まれる自アドレスに
対応するカラムの名前である。また、ホスト変数は、更
新ログに含まれている更新データの実体値である。これ
らカラム名は、更新ログに含まれるデータの数だけ指定
する。また、自レコードのカラム名には“Ｕ−ＫＥＹ”
と入力し、そのホスト変数にはステップＳ３０２にて得
られたＳ−ＫＥＹの値を入力する。従って、このＳＱＬ
文の内容は、指名された実テーブル１７におけるＷＨＥ
ＲＥ条件で特定したレコードの指名されたカラムに、ホ
スト変数の実体値を上書きするというものである。

【００８０】続くステップＳ３０５では、アドレス値の
変更がある場合に限りアドレステーブル１６に対するＵ
ＰＤＡＴＥ文を発行する。即ち、ログデータを対応する
カラムに入れ、ステップＳ３０１にて宣言したカーソル
を条件にして、ＰＤＡＴＥ文を発行する。即ち、以下の
ＳＱＬ文を発行する。

【００８１】ＵＰＤＡＴＥスキーマ名，アドレステーブル名ＳＥＴカラム名＝ホスト変数ＷＨＥＲＥＣＵＲＲＥＮＴＯＦカーソル名ここで、カラム名は、更新ログに含まれる自アドレスに
対応するカラムの名前である。また、ホスト変数は、更
新ログに含まれている更新データのアドレス値である。
これらカラム名は、更新ログに含まれるデータの数だけ
指定する。また、カーソル名には、ステップＳ３０１に
て宣言したカーソルの名前を入力する。従って、このＳ
ＱＬ文の内容は、指名された実テーブル１７におけるＷ
ＨＥＲＥ条件で特定したレコードの指名されたカラム
に、ホスト変数のアドレス値を上書きするというもので
ある。

【００８２】続くステップＳ３０６では、ステップＳ３
０５でＵＰＤＡＴＥ対象としたレコードがアドレステー
ブル１６における最下位のレコードであるかどうかを判
断する。最下位のレコードである場合には、処理をステ
ップＳ３０７に進める。最下位のレコードでない場合に
は、処理をステップＳ３０２に戻し、次の該当データを
探しに行く。

【００８３】ステップＳ３０７では、カーソルのクロー
ズを行う。即ち、以下のＳＱＬ文を発行する。ＣＬＯＳＥカーソル名ステップＳ３０７の処理を行うと、図６に戻り、次の更
新ログに対する処理を行う。

【００８４】図８及び図９は、図６のステップＳ１０９
において実行されるＥＲＡＳＥマクロ処理のサブルーチ
ンを示す。図８に入って最初のステップＳ４０１では、
現在処理対象となっている更新ログの更新対象が、ネッ
トワークデータベース１における最上位階層のデータで
あるか否かを判定する。この判定は、更新ログに上位ア
ドレスが含まれているか否かによって行う。

【００８５】最上位階層のカラムである場合には、ステ
ップＳ４０６において、図１１に示す他のメンバありの
削除サブルーチンを呼び出す。図１１において、最初の
ステップＳ５０１では、現在処理対象となっている更新
ログに含まれる自アドレス（ＰＧＣＳ）値を検索キーと
してカーソルをオープンする。即ち、以下のＳＱＬ文を
発行する。

【００８６】ＯＰＥＮカーソル名ＳＥＬＥＣＴ＊ＦＲＯＭスキーマ名，アドレステ
ーブル名，ＷＨＥＲＥ自ＰＧＣＳカラム名＝ホスト変数ここで、自ＰＧＣＳカラム名は、更新ログに含まれる自
アドレスの階層に対応するカラムの名前である。また、
ホスト変数は、更新ログに含まれている更新データのア
ドレス値である。従って、このＳＱＬ文の内容は、指名
されたアドレステーブル１６から、指定されたＰＧＣＳ
カラムのアドレスがホスト変数と一致しているレコード
の全データを取り出すことを内容とするカーソルを宣言
するというものである。

【００８７】ステップＳ５０２では、ＦＥＴＣＨ文によ
り、アドレステーブル１６のデータを取得する。即ち、
以下のＳＱＬ文を発行する。ＦＥＴＣＨカーソル名ＩＮＴＯホスト変数１，…，ホスト変数ｎここで、ｎはアドレステーブル１６のカラム数である。
なお、ホスト変数には定義のみを書き込む。従って、こ
のＳＱＬ文の内容は、ステップＳ５０１で宣言したカー
ソルを実行し、ホスト変数によって定義したデータを取
り出すというものである。

【００８８】続くステップＳ５０３では、ステップＳ５
０２による検索の結果として、カーソルの定義に該当す
るデータが存在しているかどうかを判定する。該当デー
タが存在していないときには、処理をステップＳ５０６
に進める。

【００８９】ステップＳ５０３にて該当データが存在し
ていると判断する場合には、処理をステップＳ５０４に
進める。このステップＳ５０４では、ステップＳ５０２
において取り出したデータを検索キーとして、実テーブ
ル１７に対してＤＥＬＥＴＥ文を発行する。即ち、以下
のＳＱＬ文を発行する。

【００９０】ＤＥＬＥＴＥスキーマ名，実テーブル名ＳＥＴカラム名＝ホスト変数ＷＨＥＲＥ自レコードのカラム名＝ホスト変数ここで、カラム名は、更新ログに含まれる自アドレスの
階層に対応するカラムの名前である。また、ホスト変数
は、更新ログに含まれている更新データの実体値であ
る。これらカラム名は、更新ログに含まれるデータの数
だけ指定する。また、自レコードのカラム名には“Ｕ−
ＫＥＹ”と入力し、そのホスト変数にはステップＳ５０
２にて得られたＳ−ＫＥＹの値と同じ値を入力する。従
って、このＳＱＬ文の内容は、指名された実テーブル１
７におけるＷＨＥＲＥ条件で特定したレコードを削除す
るというものである。

【００９１】続くステップＳ５０５では、ステップＳ５
０１において宣言したカーソルを条件に、アドレステー
ブル１６に対するＤＥＬＥＴＥ文を発行する。即ち、以
下のＳＱＬ文を発行する。

【００９２】ＤＥＬＥＴＥスキーマ名，アドレステーブル名，ＷＨＥＲＥＣＵＲＲＥＮＴＯＦカーソル名ここで、カーソル名には、ステップＳ５０１にて宣言し
たカーソルの名前を入力する。従って、このＳＱＬ文の
内容は、指名されたアドレステーブル１６におけるＷＨ
ＥＲＥ条件で特定したレコードを削除するというもので
ある。ステップＳ５０５の処理の後、処理をステップＳ
５０６に進める。

【００９３】ステップＳ５０６では、カーソルのクロー
ズを行う。即ち、以下のＳＱＬ文を発行する。ＣＬＯＳＥカーソル名このステップＳ５０６の処理を終了すると、この他メン
バ有りの削除サブルーチンを終了し、処理を図９に戻
す。図９においてステップＳ４０６が終了すると、処理
を図６に戻し、次のログデータに対する処理を行わせ
る。

【００９４】図９のステップＳ４０１にて最上位階層の
カラムでない場合には、ステップＳ４０２において、更
新ログに含まれる上位アドレス（ＰＧＣＳ）値が確定し
ているか否かを判定する。この判定では、更新対象のデ
ータの上位アドレス（ＰＧＣＳ）値が“ＦＦＦＦＦＦＦ
Ｆ”である場合を未確定と扱う。上位ＰＧＣＳ値が確定
していない場合には、処理をステップＳ４０３に進め
る。

【００９５】このステップＳ４０３では、現在処理対象
のレコード以外にも、更新対象のデータの上位のデータ
（親データ）からリンクするメンバ（レコード）が存在
するか否かを判定する。この判定は、更新ログ内のフラ
グのセット状態を判別することにより行う。親データか
らリンクするメンバが存在する場合には、ステップＳ４
０７に進む。このステップＳ４０７では、ステップＳ４
０６の場合と同様に、図１１の他メンバ有りの削除サブ
ルーチンを実行する。このステップＳ４０７の処理を終
了すると、処理を図６に戻し、次のログデータに対する
処理を行わせる。

【００９６】ステップＳ４０３にて、親データからリン
クするメンバが存在しない場合には、処理をステップＳ
４０５に進める。このステップＳ４０５では、図１２の
他メンバなしの削除サブルーチンを実行する。

【００９７】図１２において、最初のステップＳ６０１
では、現在処理対象となっている更新ログに含まれる自
アドレス（ＰＧＣＳ）値を検索キーとしてカーソルをオ
ープンする。即ち、以下のＳＱＬ文を発行する。

【００９８】ＯＰＥＮカーソル名ＳＥＬＥＣＴ＊ＦＲＯＭスキーマ名，アドレステ
ーブル名，ＷＨＥＲＥ自ＰＧＣＳカラム名＝ホスト変数ここで、自ＰＧＣＳカラム名は、自アドレスの階層に対
応するカラムの名前である。また、ホスト変数は、更新
ログに含まれている更新データのアドレス値である。従
って、このＳＱＬ文の内容は、指名されたアドレステー
ブル１６から、指定されたＰＧＣＳカラムのアドレスが
ホスト変数と一致しているレコードの全データを取り出
すことを内容とするカーソルを宣言するというものであ
る。

【００９９】続くステップＳ６０２では、ＦＥＴＣＨ文
により、アドレステーブル１６のデータを取得する。即
ち、以下のＳＱＬ文を発行する。ＦＥＴＣＨカーソル名ＩＮＴＯホスト変数１，…，ホスト変数ｎここで、ｎはアドレステーブル１６のカラム数である。
なお、ホスト変数には定義のみを書き込む。従って、こ
のＳＱＬ文の内容は、ステップＳ６０１で宣言したカー
ソルを実行し、ホスト変数によって定義したデータを取
り出すというものである。

【０１００】続くステップＳ６０３では、ステップＳ６
０２による検索の結果として、カーソルの定義に該当す
るデータが存在しているかどうかを判定する。該当デー
タが存在していないときには、処理をステップＳ６０６
に進める。

【０１０１】ステップＳ６０３にて該当データが存在し
ていると判断する場合には、処理をステップＳ６０４に
進める。このステップＳ６０４では、ステップＳ６０２
において取り出したデータを検索キーとして、実テーブ
ル１７に対してＵＰＤＡＴＥ文を発行する。即ち、以下
のＳＱＬ文を発行する。

【０１０２】ＵＰＤＡＴＥスキーマ名，実テーブル名，ＳＥＴカラム名＝ＮＵＬＷＨＥＲＥ自レコードのカラム名＝ホスト変数ここで、カラム名は、更新ログに含まれる自アドレスの
階層に対応する実テーブル１７のカラムの名前である。
このカラム名は、更新ログに含まれるデータの数だけ指
定する。また、自レコードのカラム名には“Ｕ−ＫＥ
Ｙ”と入力し、そのホスト変数にはステップＳ６０２に
て得られたＳ−ＫＥＹの値と同じ値を入力する。従っ
て、このＳＱＬ文の内容は、指名された実テーブル１７
におけるＷＨＥＲＥ条件で特定したレコードの指定した
カラムにＮＵＬを設定するというものである。

【０１０３】続くステップＳ６０５では、ステップＳ６
０１において宣言したカーソルを条件に、アドレステー
ブル１６に対するＵＰＤＡＴＥ文を発行する。即ち、以
下のＳＱＬ文を発行する。

【０１０４】ＵＰＤＡＴＥスキーマ名，アドレステーブル名，ＳＥＴカラム名＝ＮＵＬＷＨＥＲＥＣＵＲＲＥＮＴＯＦカーソル名ここで、ここで、カラム名は、更新ログに含まれる自ア
ドレスの階層に対応するアドレステーブル１６のカラム
の名前である。このカラム名は、更新ログに含まれるデ
ータの数だけ指定する。また、カーソル名には、ステッ
プＳ６０１にて宣言したカーソルの名前を入力する。従
って、このＳＱＬ文の内容は、指名されたアドレステー
ブル１６におけるＷＨＥＲＥ条件で特定したレコードの
指定したカラムにＮＵＬを設定するというものである。
ステップＳ６０５の処理の後、処理をステップＳ６０６
に進める。

【０１０５】ステップＳ６０６では、カーソルのクロー
ズを行う。即ち、以下のＳＱＬ文を発行する。ＣＬＯＳＥカーソル名このステップＳ６０６の処理を終了すると、この他メン
バ有りの削除サブルーチンを終了し、処理を図９に戻
す。図９においてステップＳ４０５が終了すると、処理
を図６に戻し、次のログデータに対する処理を行わせ
る。

【０１０６】ステップＳ４０２にて上位ＰＧＣＳ値が確
定していると判定する場合には、処理をステップＳ４０
８（図１０）に進める。ステップＳ４０８では、更新ロ
グに含まれる上位アドレス（ＰＧＣＳ）値と更新データ
の自アドレス（ＰＧＣＳ）値を検索キーとして、カーソ
ルをオープンする。即ち、以下のＳＱＬ文を発行する。
ＯＰＥＮカーソル名ＳＥＬＥＣＴ＊ＦＲＯＭスキーマ名，アドレステ
ーブル名ＷＨＥＲＥ上位ＰＧＣＳカラム名＝ホスト変数ＡＮＤＮＯＴ自ＰＧＣＳカラム名＝ホスト変数ここで、上位ＰＧＣＳカラム名は、上位アドレスの階層
の上の階層に対応するカラムの名前である。そのホスト
変数は、更新ログに含まれている更新データの上位アド
レス値である。自ＰＧＣＳカラム名は、自アドレスの階
層に対応するカラムの名前である。そのホスト変数は、
更新ログに含まれている更新データのアドレス値であ
る。従って、このＳＱＬ文の内容は、指名されたアドレ
ステーブル１６から上位カラムのアドレスがホスト変数
と一致しているが自カラムのアドレスがホスト変数と一
致していないレコードを検索し、そのレコードの全デー
タを取得するカーソルを宣言するというものである。

【０１０７】続くステップＳ４０９では、ＦＥＴＣＨ文
により、アドレステーブル１６のデータを取得する。即
ち、以下のＳＱＬ文を発行する。ＦＥＴＣＨカーソル名ＩＮＴＯホスト変数１，…，ホスト変数ｎここで、ｎはアドレステーブル１６のカラム数である。
なお、ホスト変数には定義のみを書き込む。従って、こ
のＳＱＬ文の内容は、ステップＳ４０８で宣言したカー
ソルを実行し、ホスト変数によって定義したデータを取
り出すというものである。

【０１０８】続くステップＳ４１０では、カーソルのク
ローズを行う。即ち、以下のＳＱＬ文を発行する。ＣＬＯＳＥカーソル名このＳＱＬ文の内容は、ステップＳ４０８にて宣言した
カーソルの使用の終了を宣言するというものである。

【０１０９】続くステップＳ４１１では、ステップＳ４
０９による検索の結果として、カーソルの定義に該当す
るデータが存在しているかどうかを判定する。該当デー
タが存在していないときには、処理をステップＳ４１２
に進める。このステップＳ４１２では、ステップＳ４０
５の場合と同様に、図１２の他メンバなしの削除サブル
ーチンを実行する。このステップＳ４１２の処理を終了
すると、処理を図６に戻し、次のログデータに対する処
理を行わせる。

【０１１０】これに対して、ステップＳ４１１にて該当
データが存在すると判定したときには、処理をステップ
Ｓ４１３に進める。このステップＳ４１３では、ステッ
プＳ４０６の場合と同様に、図１１の他メンバ有りの削
除サブルーチンを実行する。このステップＳ４１３の処
理を終了すると、処理を図６に戻し、次のログデータに
対する処理を行わせる。＜更新の具体例＞次に、上記した処理フローに従ってデ
ータを更新する場合におけるアドレステーブル１６及び
実テーブル１７の状態の具体例を示す。なお、アドレス
テーブル１６のスキーマ名は“ＳＣＨＥＭＡ１”であ
り、テーブル名は“ＴＡＢＬＥ１”であるとする。ま
た、実テーブル１７のスキーマ名は“ＳＣＨＥＭＡ２”
であり、テーブル名は“ＴＡＢＬＥ２”であるとする。＜変更の場合の具体例１＞この具体例説明の前提とし
て、更新前の状態において、ネットワークデータベース
１の状態は図３に示す通りであり、アドレステーブル１
６の状態は図４に示す通りであり、実テーブル１７の状
態は図５に示す通りであるとする。

【０１１１】いま、ネットワークデータベース１上のア
ドレスｄ２に存在するデータ“木村雄三”を、“Ａ．Ｓ
ＥＮＮＡ”に変更したとする。その場合に作成される更
新ログは、図１３に示す通りの構成である。この図１３
において、“ＵＰＤＡＴＥ”は更新方法であり、“Ａ．
ＳＥＮＮＡ”は更新後のデータの実体値であり、“ｄ
２”は更新対象データのアドレス（自アドレス）であ
り、“ｃ１”は更新対象データのレコードにおける１段
上位階層のデータ（親データ）のアドレス（上位アドレ
ス）である。

【０１１２】最初にこの更新ログを元にＭＡＰ情報ファ
イル８を検索し、自アドレスのアドレステーブル１６上
でのカラム名と、実テーブル１７上でのカラム名の情報
を得る（ステップＳ１０２，１０３）。その結果、アド
レステーブル１６上のカラム名は“Ｄ−ＰＧＣＳ”であ
り実テーブル１７上のカラム名は“開発者”であること
が認識される。

【０１１３】次に、この更新ログに基づいて、カーソル
をオープンする（ステップＳ３０１）。この場合におけ
るＳＱＬ文の具体的内容は、以下のようになる。ＯＰＥＮＣＵＲ１ＳＥＬＥＣＴ＊ＦＲＯＭＳＣＨＥＭＡ１，ＴＡＢ
ＬＥ１ＷＨＥＲＥＤ−ＰＧＣＳ＝ｄ２次に、このカーソルを実行する（ステップＳ３０２）。
この場合におけるＳＱＬ文の具体的内容は、以下の様に
なる。

【０１１４】ＦＥＴＣＨＣＵＲ１ＩＮＴＯＡ−ＰＧＣＳ，Ｂ−ＰＧＣＳ，Ｃ−ＰＧＣ
Ｓ，Ｄ−ＰＧＣＳ，Ｓ−ＫＥＹこの１回目のＦＥＴＣＨ文発行の結果として、以下のデ
ータが有られる。

【０１１５】 “ａ１，ｂ１，ｃ１，ｄ２，０００００３” このデータが得られると、ステップＳ３０３からステッ
プＳ３０４に進み、このデータに基づいて実テーブル１
７に対するＵＰＤＡＴＥ文を発行する（ステップＳ３０
４）。この場合におけるＳＱＬ文の具体的内容は、以下
のようになる。

【０１１６】ＵＰＤＡＴＥＳＣＨＥＭＡ２，ＴＡＢＬＥ２ＳＥＴ開発者＝Ａ．ＳＥＮＡＷＨＥＲＥＵ−ＫＥＹ＝０００００３これにより、実テーブル１７の内容は、図１４に示す様
に更新される。なお、この場合にはアドレス値の変更は
ないので、ステップＳ３０５の処理は行わない。

【０１１７】更新されたレコードはアドレステーブル１
６上の最下位レコードではないので、続くステップＳ３
０６において処理を戻す。従って、再度ＦＥＴＣＨ文を
発行する（ステップＳ３０６）。しかし、今回は該当す
るデータがないので、ＡＴ−ＥＮＤ（ＳＱＬＳＴＡＴＥ
２０００：データ無し）との回答がなされる。従って、
ステップＳ３０３からループを抜けて処理を終了する。＜変更の場合の具体例２＞この具体例説明の前提とし
て、更新前の状態において、アドレステーブル１６の状
態は図４に示す通りであり、実テーブル１７の状態は図
１４に示す通りであるとする。

【０１１８】いま、ネットワークデータベース１上のア
ドレスｃ１に存在するデータ“３開発課”を、“３推進
室”に変更したとする。その場合に作成される更新ログ
は、図１５に示す通りの構成である。この図１５におい
て、“ＵＰＤＡＴＥ”は更新方法であり、“３推進室”
は更新後のデータの実体値であり、“ｃ１”は自アドレ
スであり、“ｂ１”は上位アドレスである。

【０１１９】最初にこの更新ログを元にＭＡＰ情報ファ
イル８を検索し、自アドレスのアドレステーブル１６上
でのカラム名と、実テーブル１７上でのカラム名の情報
を得る（ステップＳ１０２，１０３）。その結果、アド
レステーブル１６上のカラム名は“Ｃ−ＰＧＣＳ”であ
り実テーブル１７上のカラム名は“担当課”であること
が認識される。

【０１２０】次に、この更新ログに基づいて、カーソル
をオープンする（ステップＳ３０１）。この場合におけ
るＳＱＬ文の具体的内容は、以下のようになる。ＯＰＥＮＣＵＲ１ＳＥＬＥＣＴ＊ＦＲＯＭＳＣＨＥＭＡ１，ＴＡＢ
ＬＥ１ＷＨＥＲＥＣ−ＰＧＣＳ＝ｃ１次に、このカーソルを実行する（ステップＳ３０２）。
この場合におけるＳＱＬ文の具体的内容は、以下の様に
なる。

【０１２１】ＦＥＴＣＨＣＵＲ１ＩＮＴＯＡ−ＰＧＣＳ，Ｂ−ＰＧＣＳ，Ｃ−ＰＧＣ
Ｓ，Ｄ−ＰＧＣＳ，Ｓ−ＫＥＹこの一回目のＦＥＴＣＨ文発行の結果として、以下のデ
ータが有られる。

【０１２２】 “ａ１，ｂ１，ｃ１，ｄ１，０００００２” このデータが得られると、ステップＳ３０３からステッ
プＳ３０４に進み、このデータに基づいて実テーブル１
７に対するＵＰＤＡＴＥ文を発行する（ステップＳ３０
４）。この場合におけるＳＱＬ文の具体的内容は、以下
のようになる。

【０１２３】ＵＰＤＡＴＥＳＣＨＥＭＡ２，ＴＡＢＬＥ２ＳＥＴ担当課＝３推進室ＷＨＥＲＥＵ−ＫＥＹ＝０００００２この場合にはアドレス値の変更はないので、ステップＳ
３０５の処理は行わない。

【０１２４】更新されたレコードはアドレステーブル１
６上の最下位レコードではないので、続くステップＳ３
０６において処理を戻す。従って、再度ＦＥＴＣＨ文を
発行する（ステップＳ３０６）。

【０１２５】この二回目のＦＥＴＣＨ文発行の結果とし
て、以下のデータが有られる。 “ａ１，ｂ１，ｃ１，ｄ２，０００００３” このデータが得られると、ステップＳ３０３からステッ
プＳ３０４に進み、このデータに基づいて実テーブル１
７に対するＵＰＤＡＴＥ文を発行する（ステップＳ３０
４）。この場合におけるＳＱＬ文の具体的内容は、以下
のようになる。

【０１２６】ＵＰＤＡＴＥＳＣＨＥＭＡ２，ＴＡＢＬＥ２ＳＥＴ担当課＝３推進室ＷＨＥＲＥＵ−ＫＥＹ＝０００００３この場合にはアドレス値の変更はないので、ステップＳ
３０５の処理は行わない。これにより、実テーブル１７
の内容は、図１６に示す様に更新される。なお、この場
合にはアドレス値の変更はないので、ステップＳ３０５
の処理は行わない。

【０１２７】更新されたレコードはアドレステーブル１
６上の最下位レコードではないので、続くステップＳ３
０６において処理を戻す。従って、再度ＦＥＴＣＨ文を
発行する（ステップＳ３０６）。しかし、今回は該当す
るデータがないので、ＡＴ−ＥＮＤ（ＳＱＬＳＴＡＴＥ
２０００：データ無し）との回答がなされる。従って、
ステップＳ３０３からループを抜けて処理を終了する。＜挿入の場合の具体例１＞この具体例説明の前提とし
て、更新前の状態において、アドレステーブル１６の状
態は図４に示す通りであり、実テーブル１７の状態は図
１６に示す通りであるとする。

【０１２８】いま、ネットワークデータベース１上のア
ドレスｃ３に存在するデータ“２開発課”に、下位デー
タとして“山田俊昭”を追加したとする。その場合に作
成される更新ログは、図１７に示す通りの構成である。
この図１７において、“ＩＮＳＥＲＴ”は更新方法であ
り、“山田俊昭”は更新後のデータの実体値であり、
“ｄ５”は自アドレスであり、“ｃ３”は上位アドレス
である。

【０１２９】最初にこの更新ログを元にＭＡＰ情報ファ
イル８を検索し、上位アドレスのアドレステーブル１６
上でのカラム名と、自アドレスの実テーブル１７上での
カラム名の情報を得る（ステップＳ１０２，１０３）。
その結果、上位アドレスのアドレステーブル１６上での
カラム名は“Ｃ−ＰＧＣＳ”であり自アドレスの実テー
ブル１７上でのカラム名は“開発者”であることが認識
される。

【０１３０】次に、この更新ログに基づいて、カーソル
をオープンする（ステップＳ２０４）。この場合におけ
るＳＱＬ文の具体的内容は、以下のようになる。ＯＰＥＮＣＵＲ１ＳＥＬＥＣＴ＊ＦＲＯＭＳＣＨＥＭＡ１，ＴＡＢ
ＬＥ１，ＳＣＨＥＭＡ２，ＴＡＢＬＥ２ＷＨＥＲＥＣ−ＰＧＣＳ＝ｃ３ＡＮＤＳ−ＫＥＹ＝Ｕ−ＫＥＹ次に、このカーソルを実行する（ステップＳ２０５）。
この場合におけるＳＱＬ文の具体的内容は、以下の様に
なる。

【０１３１】ＦＥＴＣＨＣＵＲ１ＩＮＴＯＡ−ＰＧＣＳ，Ｂ−ＰＧＣＳ，Ｃ−ＰＧＣ
Ｓ，Ｓ−ＫＥＹ，開発会社，事業部，担当課，
開発者，Ｕ−ＫＥＹこのＦＥＴＣＨ文発行の結果として、以下のデータが有
られる。

【０１３２】“ａ１，ｂ２，ｃ３，ｄ４，０００００
１，富士通，１開発部，２開発課，鎌田豊，０００００
１（図１８参照）” このデータが得られると、ステップＳ２０７からステッ
プＳ２１０に進み、このデータに基づいてアドレステー
ブル１６に対するＩＮＳＥＲＴ文を発行する（ステップ
Ｓ２１０）。この場合には、“ｄ４”を“ｄ５”でマー
ジするとともに、Ｓ−ＫＥＹとして新規な値（００００
０５）を設定する。即ち、この場合におけるＳＱＬ文の
具体的内容は、以下のようになる。

【０１３３】ＩＮＳＥＲＴＩＮＴＯＳＣＨＥＭＡ
１，ＴＡＢＬＥ１（Ａ−ＰＧＳＣ，Ｂ−ＰＧＳＣ，Ｃ−ＰＧＳＣ，Ｄ−Ｐ
ＧＳＣ，Ｓ−ＫＥＹ）ＶＡＬＵＥＳ（ａ１，ｂ２，ｃ３，ｄ５，０００００
５）次に、得られたデータの“鎌田豊”を“山田俊昭”でマ
ージするとともに、Ｕ−ＫＥＹとして新規な値（０００
００５）を設定して図１９に示すような新レコードを作
成する。そして、この新レコードに基づいて、実テーブ
ル１７に対するＩＮＳＥＲＴ文を発行する（ステップＳ
２１１）。この場合におけるＳＱＬ文の具体的内容は、
以下のようになる。

【０１３４】ＩＮＳＥＲＴＩＮＴＯＳＣＨＥＭＡ
２，ＴＡＢＬＥ２（開発会社，事業部，担当課，開発者，Ｕ−ＫＥＹ）ＶＡＬＵＥＳ（富士通，１開発部，２開発課，山田俊
昭，０００００５）これにより、実テーブル１７の内容は、図２０に示す様
に更新される。＜挿入の場合の具体例２＞この具体例説明の前提とし
て、更新前の状態において、実テーブル１７の状態は図
２０に示す通りであるとする。

【０１３５】いま、ネットワークデータベース１上のア
ドレスｂ２に存在するデータ“１開発部”に、下位デー
タとして“教育課”を追加したが、それに所属する者が
未だ決まっていないとする。その場合に作成される更新
ログは、図２１に示す通りの構成である。この図２１に
おいて、“ＩＮＳＥＲＴ”は更新方法であり、“教育
課”は更新後のデータの実体値であり、“ｃ４”は自ア
ドレスであり、“ｂ２”は上位アドレスである。

【０１３６】最初にこの更新ログを元にＭＡＰ情報ファ
イル８を検索し、上位アドレスのアドレステーブル１６
上でのカラム名と、自アドレスの実テーブル１７上での
カラム名の情報を得る（ステップＳ１０２，１０３）。
その結果、上位アドレスのアドレステーブル１６上での
カラム名は“Ｂ−ＰＧＣＳ”であり自アドレスの実テー
ブル１７上でのカラム名は“担当課”であることが認識
される。

【０１３７】次に、この更新ログに基づいて、カーソル
をオープンする（ステップＳ２０４）。このこの場合に
おけるＳＱＬ文の具体的内容は、以下のようになる。ＯＰＥＮＣＵＲ１ＳＥＬＥＣＴ＊ＦＲＯＭＳＣＨＥＭＡ１，ＴＡＢ
ＬＥ１，ＳＣＨＥＭＡ２，ＴＡＢＬＥ２ＷＨＥＲＥＢ−ＰＧＣＳ＝ｂ２ＡＮＤＳ−ＫＥＹ＝Ｕ−ＫＥＹ次に、このカーソルを実行する（ステップＳ２０５）。
この場合におけるＳＱＬ文の具体的内容は、以下の様に
なる。

【０１３８】ＦＥＴＣＨＣＵＲ１ＩＮＴＯＡ−ＰＧＣＳ，Ｂ−ＰＧＣＳ，Ｃ−ＰＧＣ
Ｓ，Ｓ−ＫＥＹ，開発会社，事業部，担当課，
開発者，Ｕ−ＫＥＹこのＦＥＴＣＨ文発行の結果として、以下のデータが有
られる。

【０１３９】“ａ１，ｂ２，ｃ３，ｄ４，０００００
１，富士通，１開発部，２開発課，鎌田豊，０００００
１（図２２参照）” このデータが得られると、ステップＳ２０７からステッ
プＳ２１０に進み、このデータに基づいてアドレステー
ブル１６に対するＩＮＳＥＲＴ文を発行する（ステップ
Ｓ２１０）。この場合には、“ｃ３”を“ｃ４”でマー
ジし、“ｄ４”に“ＮＵＬ”を設定するとともに、Ｓ−
ＫＥＹとして新規な値（０００００６）を設定する。即
ち、この場合におけるＳＱＬ文の具体的内容は、以下の
ようになる。

【０１４０】ＩＮＳＥＲＴＩＮＴＯＳＣＨＥＭＡ
１，ＴＡＢＬＥ１（Ａ−ＰＧＳＣ，Ｂ−ＰＧＳＣ，Ｃ−ＰＧＳＣ，Ｄ−Ｐ
ＧＳＣ，Ｓ−ＫＥＹ）ＶＡＬＵＥＳ（ａ１，ｂ２，ｃ４，ＮＵＬ，０００００
６）次に、得られたデータの“２開発課”を“教育課”でマ
ージし、“鎌田豊”を“ＮＵＬ”でマージするととも
に、Ｕ−ＫＥＹとして新規な値（０００００６）を設定
して図２３に示すような新レコードを作成する。そし
て、この新レコードに基づいて、実テーブル１７に対す
るＩＮＳＥＲＴ文を発行する（ステップＳ２１１）。こ
のこの場合におけるＳＱＬ文の具体的内容は、以下のよ
うになる。

【０１４１】ＩＮＳＥＲＴＩＮＴＯＳＣＨＥＭＡ
２，ＴＡＢＬＥ２（開発会社，事業部，担当課，開発者，Ｕ−ＫＥＹ）ＶＡＬＵＥＳ（富士通，１開発部，教育課，ＮＵＬ，０
００００６）これこれにより、実テーブル１７の内容は、図２４に示
す様に更新される。＜削除の場合の具体例＞この具体例説明の前提として、
更新前の状態において、実テーブル１７の状態は図２４
に示す通りであるとする。

【０１４２】いま、ネットワークデータベース１上のア
ドレスｃ１に存在するデータ“３推進室”を削除したと
する。その場合には、同時に、“３推進室”の子データ
である“小田康貴（アドレス：ｄ１）”及び“Ａ．ＳＥ
ＮＮＡ（アドレス：ｄ２）”も削除される。従って、こ
の場合には、図２５に示す様に３つの更新ログが作成さ
れる。図２５Ｉにおいて、“ＤＥＬＥＴＥ”は更新方法
であり、“−（ＮＵＬ）”は更新後のデータの実体値で
あり、“ｄ２”は自アドレスであり、“ｃ１”は上位ア
ドレスである。図２５ＩＩにおいて、“ＤＥＬＥＴＥ”
は更新方法であり、“−（ＮＵＬ）”は更新後のデータ
の実体値であり、“ｄ１”は自アドレスであり、“ｃ
１”は上位アドレスである。図２５ＩＩＩにおいて、
“ＤＥＬＥＴＥ”は更新方法であり、“−（ＮＵＬ）”
は更新後のデータの実体値であり、“ｃ１”は自アドレ
スであり、“ｂ１”は上位アドレスである。〔更新ログＩによる処理〕最初にこの更新ログＩを元に
ＭＡＰ情報ファイル８を検索し、上位アドレスと自アド
レスのアドレステーブル１６上でのカラム名と、上位ア
ドレスと自アドレスの実テーブル１７上でのカラム名の
情報を得る（ステップＳ１０２，１０３）。その結果、
アドレステーブル１６上のカラム名は上位アドレスが
“Ｃ−ＰＧＣＳ”であり自アドレスが“Ｄ−ＰＧＣＳ”
であり、実テーブル１７上のカラム名は上位アドレスが
“担当課”であり自アドレスが“開発者”であることが
認識される。

【０１４３】この更新ログＩによれば、更新対象データ
（“Ａ．ＳＥＮＮＡ”）は最上位階層ではなく、且つ上
位ＰＧＣＳ値は確定しているので、ステップＳ４０１及
びステップＳ４０２を通ってステップＳ４０８に進む。
このステップＳ４０８では、更新ログＩに基づいて、カ
ーソルをオープンする。この場合におけるＳＱＬ文の具
体的内容は、以下のようになる。

【０１４４】ＯＰＥＮＣＵＲ１ＳＥＬＥＣＴ＊ＦＲＯＭＳＣＨＥＭＡ１，ＴＡＢ
ＬＥ１ＷＨＥＲＥＣ−ＰＧＣＳ＝ｃ１ＡＮＤＮＯＴＤ−ＰＧＣＳ＝ｄ２次に、このカーソルを実行する（ステップＳ４０９）。
この場合におけるＳＱＬ文の具体的内容は、以下の様に
なる。

【０１４５】ＦＥＴＣＨＣＵＲ１ＩＮＴＯＡ−ＰＧＣＳ，Ｂ−ＰＧＣＳ，Ｃ−ＰＧＣ
Ｓ，Ｄ−ＰＧＣＳ，Ｓ−ＫＥＹこのＦＥＴＣＨ文発行の結果として、以下のデータが有
られる。

【０１４６】 “ａ１，ｂ１，ｃ１，ｄ１，０００００２” この結果、更新ログＩによって現在削除対象となってい
るレコード以外にも“３推進室”配下のレコードタイプ
が存在することが確認できた。よって、今回更新対象の
レコードを削除するために、処理をステップＳ４１１か
らステップＳ４１３に進める。ステップＳ４１３のサブ
ルーチン（図１１）では、最初に、更新ログＩに基づい
て、カーソルをオープンする（ステップＳ５０１）。こ
の場合におけるＳＱＬ文の具体的内容は、以下のように
なる。

【０１４７】ＯＰＥＮＣＵＲ１ＳＥＬＥＣＴ＊ＦＲＯＭＳＣＨＥＭＡ１，ＴＡＢ
ＬＥ１ＷＨＥＲＥＤ−ＰＧＣＳ＝ｄ２次に、このカーソルを実行する（ステップＳ５０２）。
この場合におけるＳＱＬ文の具体的内容は、以下の様に
なる。

【０１４８】ＦＥＴＣＨＣＵＲ１ＩＮＴＯＡ−ＰＧＣＳ，Ｂ−ＰＧＣＳ，Ｃ−ＰＧＣ
Ｓ，Ｄ−ＰＧＣＳ，Ｓ−ＫＥＹこのＦＥＴＣＨ文発行の結果として、以下のデータが有
られる。

【０１４９】 “ａ１，ｂ１，ｃ１，ｄ２，０００００３” このデータが得られると、ステップＳ５０３からステッ
プＳ５０４に進み、このデータに基づいて実テーブル１
７に対するＤＥＬＥＴＥ文を発行する（ステップＳ５０
４）。この場合におけるＳＱＬ文の具体的内容は、以下
のようになる。

【０１５０】ＤＥＬＥＴＥＳＣＨＥＭＡ２，ＴＡＢＬＥ２ＷＨＥＲＥＵ−ＫＥＹ＝０００００３これにより、実テーブル１７の内容は、図２６に示す様
に更新される。

【０１５１】続いて、ＦＥＴＣＨ文により得られたデー
タに基づいてアドレステーブル１６に対するＤＥＬＥＴ
Ｅ文を発行する（ステップＳ５０５）。この場合におけ
るＳＱＬ文の具体的内容は、以下のようになる。

【０１５２】ＤＥＬＥＴＥＳＣＨＥＭＡ１，ＴＡＢＬＥ１ＷＨＥＲＥＣＵＲＲＥＮＴＯＦＣＵＲ１〔更新ログＩＩによる処理〕続いて更新ログＩＩによる
処理を行う。

【０１５３】最初にこの更新ログＩＩを元にＭＡＰ情報
ファイル８を検索し、上位アドレスと自アドレスのアド
レステーブル１６上でのカラム名と、上位アドレスと自
アドレスの実テーブル１７上でのカラム名の情報を得る
（ステップＳ１０２，１０３）。その結果、アドレステ
ーブル１６上のカラム名は上位アドレスが“Ｃ−ＰＧＣ
Ｓ”であり自アドレスが“Ｄ−ＰＧＣＳ”であり、実テ
ーブル１７上のカラム名は上位アドレスが“担当課”で
あり自アドレスが“開発者”であることが認識される。

【０１５４】この更新ログＩＩによれば、更新対象デー
タ（“小田康貴”）は最上位階層ではなく、且つ上位Ｐ
ＧＣＳ値は確定しているので、ステップＳ４０１及びス
テップＳ４０２を通ってステップＳ４０８に進む。この
ステップＳ４０８では、更新ログＩＩに基づいて、カー
ソルをオープンする。この場合におけるＳＱＬ文の具体
的内容は、以下のようになる。

【０１５５】ＯＰＥＮＣＵＲ１ＳＥＬＥＣＴ＊ＦＲＯＭＳＣＨＥＭＡ１，ＴＡＢ
ＬＥ１ＷＨＥＲＥＣ−ＰＧＣＳ＝ｃ１ＡＮＤＮＯＴＤ−ＰＧＣＳ＝ｄ１次に、このカーソルを実行する（ステップＳ４０９）。
この場合におけるＳＱＬ文の具体的内容は、以下の様に
なる。

【０１５６】ＦＥＴＣＨＣＵＲ１ＩＮＴＯＡ−ＰＧＣＳ，Ｂ−ＰＧＣＳ，Ｃ−ＰＧＣ
Ｓ，Ｄ−ＰＧＣＳ，Ｓ−ＫＥＹこのＦＥＴＣＨ文発行の結果として、以下のデータが有
られる。

【０１５７】“ＡＴ−ＥＮＤ（ＳＱＬＳＴＡＴＥ０２０
００：データなし）” この結果、更新ログＩによって現在削除対象となってい
るレコード以外には“３推進室”配下のレコードタイプ
が存在しないことが確認できた。よって、今回更新対象
のデータにＮＵＬを設定するために、処理をステップＳ
４１１からステップＳ４１２に進める。ステップＳ４１
２のサブルーチン（図１２）では、最初に、更新ログＩ
Ｉに基づいて、カーソルをオープンする（ステップＳ６
０１）。この場合におけるＳＱＬ文の具体的内容は、以
下のようになる。

【０１５８】ＯＰＥＮＣＵＲ１ＳＥＬＥＣＴ＊ＦＲＯＭＳＣＨＥＭＡ１，ＴＡＢ
ＬＥ１ＷＨＥＲＥＤ−ＰＧＣＳ＝ｄ１次に、このカーソルを実行する（ステップＳ５０２）。
この場合におけるＳＱＬ文の具体的内容は、以下の様に
なる。

【０１５９】ＦＥＴＣＨＣＵＲ１ＩＮＴＯＡ−ＰＧＣＳ，Ｂ−ＰＧＣＳ，Ｃ−ＰＧＣ
Ｓ，Ｄ−ＰＧＣＳ，Ｓ−ＫＥＹこのＦＥＴＣＨ文発行の結果として、以下のデータが有
られる。

【０１６０】 “ａ１，ｂ１，ｃ１，ｄ１，０００００２” このデータが得られると、ステップＳ６０３からステッ
プＳ６０４に進み、このデータに基づいて実テーブル１
７に対するＵＰＤＡＴＥ文を発行する（ステップＳ６０
４）。この場合におけるＳＱＬ文の具体的内容は、以下
のようになる。

【０１６１】ＵＰＤＡＴＥＳＣＨＥＭＡ２，ＴＡＢＬＥ２ＳＥＴ開発者＝ＮＵＬＷＨＥＲＥＵ−ＫＥＹ＝０００００２これにより、実テーブル１７の内容は、図２７に示す様
に更新される。

【０１６２】続いて、ＦＥＴＣＨ文により得られたデー
タに基づいてアドレステーブル１６に対するＤＥＬＥＴ
Ｅ文を発行する（ステップＳ６０５）。この場合におけ
るＳＱＬ文の具体的内容は、以下のようになる。

【０１６３】ＵＰＤＡＴＥＳＣＨＥＭＡ１，ＴＡＢＬＥ１ＳＥＴＤ−ＰＧＣＳ＝ＮＵＬＷＨＥＲＥＣＵＲＲＥＮＴＯＦＣＵＲ１これにより、アドレステーブル１６の内容は、図２８に
示す様に更新される。〔更新ログＩＩＩによる処理〕続いて更新ログＩＩＩに
よる処理を行う。

【０１６４】最初にこの更新ログＩＩＩを元にＭＡＰ情
報ファイル８を検索し、上位アドレスと自アドレスのア
ドレステーブル１６上でのカラム名と、上位アドレスと
自アドレスの実テーブル１７上でのカラム名の情報を得
る（ステップＳ１０２，１０３）。その結果、アドレス
テーブル１６上のカラム名は上位アドレスが“Ｂ−ＰＧ
ＣＳ”であり自アドレスが“Ｃ−ＰＧＣＳ”であり、実
テーブル１７上のカラム名は上位アドレスが“事業部”
であり自アドレスが“担当課”であることが認識され
る。

【０１６５】この更新ログＩＩＩによれば、更新対象デ
ータ（“３推進室”）は最上位階層ではなく、且つ上位
ＰＧＣＳ値は確定しているので、ステップＳ４０１及び
ステップＳ４０２を通ってステップＳ４０８に進む。こ
のステップＳ４０８では、更新ログＩＩＩに基づいて、
カーソルをオープンする。この場合におけるＳＱＬ文の
具体的内容は、以下のようになる。

【０１６６】ＯＰＥＮＣＵＲ１ＳＥＬＥＣＴ＊ＦＲＯＭＳＣＨＥＭＡ１，ＴＡＢ
ＬＥ１ＷＨＥＲＥＢ−ＰＧＣＳ＝ｂ１ＡＮＤＮＯＴＣ−ＰＧＣＳ＝ｃ１次に、このカーソルを実行する（ステップＳ４０９）。
この場合におけるＳＱＬ文の具体的内容は、以下の様に
なる。

【０１６７】ＦＥＴＣＨＣＵＲ１ＩＮＴＯＡ−ＰＧＣＳ，Ｂ−ＰＧＣＳ，Ｃ−ＰＧＣ
Ｓ，Ｄ−ＰＧＣＳ，Ｓ−ＫＥＹこのＦＥＴＣＨ文発行の結果として、以下のデータが有
られる。

【０１６８】 “ａ１，ｂ１，ｃ２，ｄ３，０００００４” この結果、更新ログＩＩＩによって現在削除対象となっ
ているレコード以外にも“２開発部”配下のレコードタ
イプが存在することが確認できた。よって、今回更新対
象のレコードを削除するために、処理をステップＳ４１
１からステップＳ４１３に進める。ステップＳ４１３の
サブルーチン（図１１）では、最初に、更新ログＩＩＩ
に基づいて、カーソルをオープンする（ステップＳ５０
１）。この場合におけるＳＱＬ文の具体的内容は、以下
のようになる。

【０１６９】ＯＰＥＮＣＵＲ１ＳＥＬＥＣＴ＊ＦＲＯＭＳＣＨＥＭＡ１，ＴＡＢ
ＬＥ１ＷＨＥＲＥＣ−ＰＧＣＳ＝ｃ２次に、このカーソルを実行する（ステップＳ５０２）。
この場合におけるＳＱＬ文の具体的内容は、以下の様に
なる。

【０１７０】ＦＥＴＣＨＣＵＲ１ＩＮＴＯＡ−ＰＧＣＳ，Ｂ−ＰＧＣＳ，Ｃ−ＰＧＣ
Ｓ，Ｄ−ＰＧＣＳ，Ｓ−ＫＥＹこのＦＥＴＣＨ文発行の結果として、以下のデータが有
られる。

【０１７１】 “ａ１，ｂ１，ｃ１，ＮＵＬ，０００００２” このデータが得られると、ステップＳ５０３からステッ
プＳ５０４に進み、このデータに基づいて実テーブル１
７に対するＤＥＬＥＴＥ文を発行する（ステップＳ５０
４）。この場合におけるＳＱＬ文の具体的内容は、以下
のようになる。

【０１７２】ＤＥＬＥＴＥＳＣＨＥＭＡ２，ＴＡＢＬＥ２ＷＨＥＲＥＵ−ＫＥＹ＝０００００２これにより、実テーブル１７の内容は、図２９に示す様
に更新される。

【０１７３】続いて、ＦＥＴＣＨ文により得られたデー
タに基づいてアドレステーブル１６に対するＤＥＬＥＴ
Ｅ文を発行する（ステップＳ５０５）。この場合におけ
るＳＱＬ文の具体的内容は、以下のようになる。

【０１７４】ＤＥＬＥＴＥＳＣＨＥＭＡ１，ＴＡＢＬＥ１ＷＨＥＲＥＣＵＲＲＥＮＴＯＦＣＵＲ１これにより、アドレステーブル１６の内容は、図３０に
示す様に更新される。＜挿入の場合の具体例３＞この具体例説明の前提とし
て、更新前の状態において、アドレステーブル１６の状
態は図３０に示す通りであり、実テーブル１７の状態は
図２９に示す通りであるとする。

【０１７５】いま、ネットワークデータベース１上のア
ドレスｃ４に存在するデータ“教育課”に、下位データ
として“正富勝利”を追加したとする。その場合に作成
される更新ログは、図３１に示す通りの構成である。こ
の図３１において、“ＩＮＳＥＲＴ”は更新方法であ
り、“正富勝利”は更新後のデータの実体値であり、
“ｄ６”は自アドレスであり、“ｃ４”は上位アドレス
である。

【０１７６】最初にこの更新ログを元にＭＡＰ情報ファ
イル８を検索し、上位アドレスのアドレステーブル１６
上でのカラム名と、自アドレスの実テーブル１７上での
カラム名の情報を得る（ステップＳ１０２，１０３）。
その結果、上位アドレスのアドレステーブル１６上での
カラム名は“Ｃ−ＰＧＣＳ”であり自アドレスの実テー
ブル１７上でのカラム名は“開発者”であることが認識
される。

【０１７７】次に、この更新ログに基づいて、カーソル
をオープンする（ステップＳ２０４）。この場合におけ
るＳＱＬ文の具体的内容は、以下のようになる。ＯＰＥＮＣＵＲ１ＳＥＬＥＣＴ＊ＦＲＯＭＳＣＨＥＭＡ１，ＴＡＢ
ＬＥ１，ＳＣＨＥＭＡ２，ＴＡＢＬＥ２ＷＨＥＲＥＣ−ＰＧＣＳ＝ｃ４ＡＮＤＳ−ＫＥＹ＝Ｕ−ＫＥＹ次に、このカーソルを実行する（ステップＳ２０５）。
この場合におけるＳＱＬ文の具体的内容は、以下の様に
なる。

【０１７８】ＦＥＴＣＨＣＵＲ１ＩＮＴＯＡ−ＰＧＣＳ，Ｂ−ＰＧＣＳ，Ｃ−ＰＧＣ
Ｓ，Ｓ−ＫＥＹ，開発会社，事業部，担当課，
開発者，Ｕ−ＫＥＹこのＦＥＴＣＨ文発行の結果として、以下のデータが有
られる。

【０１７９】“ａ１，ｂ２，ｃ４，ＮＵＬ，０００００
６，富士通，１開発部，教育課，ＮＵＬ，０００００６
（図３２参照）” このデータが得られると、ステップＳ２０７では検索結
果が欠測値を持っていると判断される。よって、ステッ
プＳ２０７からステップＳ２０８に進み、このデータに
基づいて実テーブル１７に対するＵＰＤＡＴＥ文を発行
する（ステップＳ２０８）。この場合には、得られたデ
ータ“ＮＵＬ”を“正富勝利”でマージする。即ち、こ
の場合におけるＳＱＬ文の具体的内容は、以下のように
なる。

【０１８０】ＵＰＤＡＴＥＳＣＨＥＭＡ２，ＴＡＢＬＥ２ＳＥＴ開発者＝正富勝利ＷＨＥＲＥＵ−ＫＥＹ＝０００００６これにより、実テーブル１７の内容は、図３３に示す様
に更新される。

【０１８１】次に、アドレステーブル１６に対しても同
様に、得られたデータに基づいてＵＰＤＡＴＥ文を発行
する（ステップＳ２０９）。この場合には、“ＮＵＬ”
を“ｄ６”でマージする。この場合におけるＳＱＬ文の
具体的内容は、以下のようになる。

【０１８２】ＵＰＤＡＴＥＳＣＨＥＭＡ１，ＳＣＨＥＭＡ１ＳＥＴＤ−ＰＧＣＳ＝ｄ６ＷＨＥＲＥＣ−ＰＧＣＳ＝ｃ４これにより、アドレステーブル１６の内容は、図３４に
示す様に更新される。

【０１８３】以上のように、本実施例によれば、更新ロ
グから更新情報を抽出することにより、実テーブル１７
中の必要な部分にだけ更新を行うことができる。

【０１８４】

【実施例２】図３５乃至図３７は、本発明によるデータ
ベースシステムの第２実施例を示す。この第２実施例で
は、ユニーク性表示部としての一意性保障キーの構造が
第１実施例と異なるのみである。従って、第２実施例の
システム構成は第１実施例と全く同じである。また、第
１実施例の処理フローの説明における“Ｓ−ＫＥＹ”及
び“Ｕ−ＫＥＹ”の両方を“ＬＩＮＫ”に置き換えるこ
とにより、第１実施例の処理フローを第２実施例の処理
フローと看做すことができる。よって、ここでは、ネッ
トワークデータベース１，アドレステーブル１６，実テ
ーブル１７のみの説明を行う。＜ネットワークデータベース１のデータ構成＞図３５
は、ネットワークデータベース１内のデータ構造の例を
示す図である。図３５に示すように、ネットワークデー
タベース１内において、各データは、階層構造となるよ
うに相互に関連付けられている。即ち、最上位階層（１
階層）のデータの実体値が“Ａ（アドレス値＝ａ１）”
となっている。また、２階層目のデータの実体値値が
“Ｂ（アドレス値＝ｂ１）”及び“Ｅ（アドレス値＝ｂ
２）”となっている。また、３階層目データの実体値が
“Ｃ（アドレス値＝ｃ１）”，“Ｄ（アドレス値＝ｃ
２）”，及び“Ｆ（アドレス値＝ｃ３）”となってい
る。

【０１８５】なお、本実施例では、上述したようにオー
ナ位置のデータが一つ（“Ａ”）だけであり、かつ、下
位階層のデータは唯１つの上位階層のデータ（親デー
タ）に対して関連付けられている。即ち、逆ツリー
（木）型の構造となっている。このツリーの枝，即ちオ
ーナ位置のデータから特定の最下位層のデータに至るま
での繋がりの各々を、レコードという。＜アドレステーブル１６のデータ構造＞図３６（ｂ）は
アドレステーブル１６内のデータ構造の例を示す図であ
る。このアドレステーブル１６は、リレーショナルデー
タベース１１内に追加されたテーブルである。アドレス
テーブル１６は、ネットワークデータベース１の更新に
先立つ初期抽出時に、ネットワークデータベース１の各
レコードタイプ（データ）のアドレス値を元にして作成
される。

【０１８６】アドレステーブル１６は、行がレコードを
示し列がカラムを示す２次元の表構成となっている。ア
ドレステーブル１６の各レコードは、ネットワークデー
タベース１のレコードの何れかに対応している。アドレ
ステーブル１６の各カラムのうち「カラムＩ」，がネッ
トワークデータベース１の１階層に対応し、「カラムＩ
Ｉ」が２階層に対応し、「カラムＩＩＩ」が３階層に対
応している。また、「ＬＩＮＫ」と名付けられたカラム
は、ユニーク性表示部としての一意性保障カラムであ
る。

【０１８７】アドレステーブル１６に書き込まれる情報
は、そのレコード及びカラムに対応するネットワークデ
ータベース１内の位置に書き込まれているデータのアド
レス値である。アドレステーブル１６のレコード数はネ
ットワークデータベース１のレコード数に一致している
ので、同じアドレス値が複数のレコードに重複して書き
込まれている。

【０１８８】ＬＩＮＫカラムに書き込まれている情報
は、そのレコードに含まれる全データのアドレスを一連
に繋げた値である。＜実テーブル１７（ユーザテーブル）のデータ構造＞図
３６（ａ）は実テーブル１７内のデータ構造の例を示す
図である。実テーブル１７は、本来のリレーショナルデ
ータベースとして実体値を保持するテーブルである。

【０１８９】この実テーブル１７は、行がレコードを示
し列がカラムを示す２次元の表構成となっている。実テ
ーブル１７の各レコードは、ネットワークデータベース
１の各レコードの何れかに対応している。但し、その順
番をデータテーブルの場合の順番と一致させる必要はな
い。アドレステーブル１６の各カラムのうち「アドレス
Ｉ」がネットワークデータベース１の１階層に対応し、
「アドレスＩＩ」が２階層に対応し、「アドレスＩＩ
Ｉ」が３階層に対応する。また、「Ｕ−ＫＥＹ」と名付
けられたカラムは、ユニーク性表示部としての一意性保
障カラムである。

【０１９０】実テーブル１７に書き込まれる情報は、そ
のレコード及びカラムに対応するネットワークデータベ
ース１内の位置に書き込まれている実体値そのものであ
る。実テーブル１７のレコード数はネットワークデータ
ベース１のレコード数に一致しているので、同じ実体値
が複数のレコードに重複して書き込まれている。

【０１９１】ＬＩＮＫカラムに書き込まれている情報
は、そのレコードに含まれる全データのアドレスを一連
に繋げた値である。ネットワークデータベース１の同じ
レコードに対応しているアドレステーブル１６のレコー
ドと実テーブル１７のレコードには、各々同じ値が付さ
れている。従って、アドレステーブル１６のＬＩＮＫカ
ラムの値（ＬＩＮＫキー）と実テーブル１７のＬＩＮＫ
カラムとの値（ＬＩＮＫキー）を突き合わせることによ
り、図３６に示すように、或るアドレステーブル１６の
レコードに対応する実テーブル１７のレコードを特定す
ることができる。＜更新の概略説明＞本実施例による処理は、原則として
第１実施例の処理フローに従ってなされる。よって、こ
こでは、その場合の更新の概略例を説明するに止める。

【０１９２】いま、ネットワークデータベース１上のレ
コードタイプＢのデータがＢ⁺に変更されたとする。す
ると更新ログとして以下のものが抽出される。自アドレス：ｂ１データ（実体値）：Ｂ⁺ 更新方法：ＵＰＤＡＴＥこの更新ログを受信したネットワークデータベース１で
は、データの変更を行うと決定する。そして、アドレス
テーブル１６を検索して、自アドレス＝ｂ１のレコード
のＬＩＮＫキーを探し出す。その結果、ＬＩＮＫキー＝
ａ１ｂ１ｃ２の情報を得た。

【０１９３】次に、ＬＩＮＫキーが上記値と一致してい
るレコードを、実テーブル１７から探し出す。そして、
そのレコードのレコードタイプＢにあたるカラムの情報
をＢ⁺に変更する。このようにして、実テーブル１７の
内容は、図３７に示すように更新される。

【０１９４】

【発明の効果】本発明の必須の構成要素により、ネット
ワークデータベースにおけるデータ更新の内容を迅速に
リレーショナルデータベースに反映することができる。
又は、ネットワークデータベースにおけるデータ更新の
内容を、リレーショナルデータベースの一部の更新のみ
でリレーショナルデータベースに反映することができ
る。

【図面の簡単な説明】

【図１】本発明の原理図であり、（ａ）はシステム
の原理図であり、（ｂ）乃至（ｄ）は方法の原理図

【図２】本発明の第１実施例によるデータベースシ
ステムの構成図

【図３】図２におけるネットワークデータベースの
説明図

【図４】図２におけるアドレステーブルの説明図

【図５】図２における実テーブルの説明図

【図６】図２における更新部で実行される更新タス
クの処理を示すフローチャート

【図７】図６のステップＳ１０７で実行されるＳＴ
ＯＲＥマクロ処理のサブルーチンを示すフローチャート

【図８】図６のステップＳ１０８で実行されるＭＯ
ＤＩＦＹマクロ処理のサブルーチンを示すフローチャー
ト

【図９】図６のステップＳ１０９で実行されるＥＲ
ＡＳＥマクロ処理のサブルーチンを示すフローチャート

【図１０】図９のステップＳ４０２で上位ＰＧＣＳ値
が確定している場合に実行される処理を示すフローチャ
ート

【図１１】図９のステップＳ４０６又はステップＳ４
０７，若しくは図１０のステップＳ４１３で実行される
他メンバありの削除サブルーチンを示すフローチャート

【図１２】図９のステップＳ４０５又は図１０のステ
ップＳ４１２で実施される他メンバなしの削除サブルー
チンを示すフローチャート

【図１３】図２の更新ログ作成部で作成される変更時
の更新ログの説明図

【図１４】図１３の更新ログにより更新された実テー
ブルの説明図

【図１５】図２の更新ログ作成部で作成される変更時
の更新ログの説明図

【図１６】図１５の更新ログにより更新された実テー
ブルの説明図

【図１７】図２の更新ログ作成部で作成される挿入時
の更新ログの説明図

【図１８】図１５の更新ログにより獲得されたレコー
ドの説明図

【図１９】図１８のレコードから作成された新レコー
ドの説明図

【図２０】図１９の新レコードを追加して更新された
実テーブルの説明図

【図２１】図２の更新ログ作成部で作成される挿入時
の更新ログの説明図

【図２２】図２１の更新ログにより獲得されたレコー
ドの説明図

【図２３】図２２のレコードから作成された新レコー
ドの説明図

【図２４】図２３の新レコードを追加して更新された
実テーブルの説明図

【図２５】図２の更新ログ作成部で作成される削除時
の更新ログの説明図

【図２６】図２５Ｉの更新ログにより更新された実テ
ーブルの説明図

【図２７】図２５ＩＩの更新ログにより更新された実
テーブルの説明図

【図２８】図２５ＩＩの更新ログにより更新されたア
ドレステーブルの説明図

【図２９】図２５ＩＩＩの更新ログにより更新された
実テーブルの説明図

【図３０】図２５ＩＩＩの更新ログにより更新された
アドレステーブルの説明図

【図３１】図２の更新ログ作成部で作成される挿入時
の更新ログの説明図

【図３２】図３１の更新ログにより獲得されたレコー
ドの説明図

【図３３】図３１の更新ログにより更新された実テー
ブルの説明図

【図３４】図３１の更新ログにより更新されたアドレ
ステーブルの説明図

【図３５】本発明の第２実施例によるデータベースシ
ステムにおけるネットワークデータベースの説明図

【図３６】本発明の第２実施例によるデータベースシ
ステムにおける実テーブル（ａ）及びアドレステーブル
（ｂ）の説明図

【図３７】更新後における図３６に示した実テーブル
（ａ）及びアドレステーブル（ｂ）の説明図

【符号の説明】

１ネットワークデータベース２ＮＤＢマネージャ３履歴ログファイル４抽出部６更新ログ作成部７更新ログファイル８ＭＡＰ情報ファイル９更新部１０ＲＤＢマネージャ１１リレーショナルデータベース１６アドレステーブル１７実テーブル

Claims

【特許請求の範囲】

【請求項１】データを階層形式で有するネットワークデ
ータベース（１００）と、このネットワークデータベー
ス（１００）のデータ階層に対応して各データを表形式
で格納するリレーショナルデータベース（１０１）と、
を備えたデータベースシステムにおいて、前記ネットワークデータベース（１００）の各データの
アドレスを上位データ階層から下位データ階層に至るレ
コード毎に行として表した表形式で格納するとともに、
前記各データのアドレス格納位置とリレーショナルデー
タベース（１０１）のデータ格納位置とを対応させたア
ドレステーブル（１０２）と、前記ネットワークデータベース（１００）のデータ更新
がなされたとき、その更新データのアドレス及び更新内
容を含む更新ログデータを獲得する更新ログデータ獲得
手段（１０３）と、この更新ログデータ獲得手段（１０３）で獲得した更新
ログデータに従って前記アドレステーブルにおける更新
データのアドレス格納位置を検索するアドレス格納位置
検索手段（１０４）と、このアドレス格納位置検索手段（１０４）で検索したア
ドレステーブル（１０２）上の更新データのアドレス格
納位置に対応するリレーショナルデータベース（１０
１）上のデータの位置を特定する更新位置特定手段（１
０５）と、この更新位置特定手段（１０５）で特定されたリレーシ
ョナルデータベースデータ上の位置におけるデータを前
記更新ログデータに従って更新するデータ更新手段（１
０６）とを備えたデータベースシステム。
【請求項２】前記リレーショナルデータベース（１０
１）及び前記アドレステーブル（１０２）の両者にユニ
ーク性表示部を設け、前記リレーショナルデータベース
（１０１）の或る行におけるユニーク性表示部の値を、
この或る行に対応する前記アドレステーブル（１０２）
の行におけるユニーク性表示部の値に対応させた請求項
１記載のデータベースシステム。
【請求項３】前記ユニーク性表示部は、前記リレーショ
ナルデータベース（１０１）及び前記アドレステーブル
（１０２）の各々の特定の列に設けられている請求項２
記載のデータベースシステム。
【請求項４】前記データ更新手段（１０６）は、前記ネ
ットワークデータベース（１００）におけるアドレス情
報の更新があった場合には、この更新内容に従って、前
記アドレステーブル（１０２）におけるアドレス情報を
更新する請求項１記載のデータベースシステム。
【請求項５】前記アドレス格納位置検索手段（１０４）
は、前記更新ログデータに含まれるアドレスに基づい
て、前記アドレスが含まれている前記アドレステーブル
（１０２）の行を検索する請求項１記載のデータベース
システム。
【請求項６】前記更新位置特定手段（１０５）は、前記
アドレス位置格納手段により検索された前記アドレステ
ーブル（１０２）の行に対応するリレーショナルデータ
ベースの行を特定し、更に前記更新ログデータに含まれ
るアドレスに基づいて列を特定する請求項５記載のデー
タベースシステム。
【請求項７】前記アドレステーブル（１０２）はその列
毎にカラム名を有するとともに、前記リレーショナルデ
ータベース（１０１）もその列毎にカラム名を有してい
る請求項６記載のデータベースシステム。
【請求項８】前記各アドレスと前記アドレステーブル
（１０２）のカラム名との対応関係を規定した情報テー
ブルを更に有し、前記アドレス格納位置検索手段（１０４）は前記更新ロ
グデータに含まれるアドレスに対応する前記アドレステ
ーブル（１０２）上のカラム名を前記ＭＡＰ情報テーブ
ルから獲得し、このカラム名と前記更新ログデータに含
まれるアドレスとから前記アドレステーブル（１０２）
の行を特定する請求項７記載のデータベースシステム。
【請求項９】前記各アドレスと前記リレーショナルデー
タベース（１０１）カラム名との対応関係を規定した情
報テーブルを更に有し、前記更新位置特定手段（１０５）は前記更新ログデータ
に含まれるアドレスに対応する前記アドレステーブル
（１０２）上のカラム名を前記ＭＡＰ情報テーブルから
獲得し、このカラム名と前記特定した行とからリレーシ
ョナルデータベース（１０１）上のデータの位置を特定
する請求項７記載のデータベースシステム。
【請求項１０】前記更新ログデータを蓄積する更新ログ
ファイルを更に有する請求項１記載のデータベースシス
テム。
【請求項１１】データを階層形式で有するネットワーク
データベース（１００）と、このネットワークデータベ
ース（１００）の上位データ階層から下位データ階層に
至るレコード毎に行として表した表形式により前記ネッ
トワークデータベース（１００）と同じデータを格納す
るリレーショナルデータベース（１０１）とを合わせ持
つデータベースシステムの更新方法において、前記各データのアドレスと前記リレーショナルデータベ
ース（１０１）のデータ位置とをアドレステーブル（１
０２）により特定し、前記ネットワークデータベース（１００）のデータ更新
がなされたとき、更新データのアドレス及び更新内容を
含む更新ログデータを獲得し、この更新ログデータに従って、前記アドレステーブル
（１０２）における更新データのアドレス格納位置を検
索し、そのアドレス格納位置に対応するリレーショナルデータ
ベース（１０１）上のデータを特定し、リレーショナルデータベース（１０１）上の特定された
データを前記更新ログデータに従って更新するデータベ
ースシステムの更新方法。