JP2644728B2

JP2644728B2 - データディクショナリ・ディレクトリシステム

Info

Publication number: JP2644728B2
Application number: JP61013805A
Authority: JP
Inventors: 和明田中; 一郎横山; 哲和歌山; 嘉人亀城; 誠浦川; 幹彦徳永; 毅鴨志田; 茂米田; 清隆木保
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 1986-01-27
Filing date: 1986-01-27
Publication date: 1997-08-25
Anticipated expiration: 2012-08-25
Also published as: JPS62173546A; US4979109A

Description

【発明の詳細な説明】〔産業上の利用分野〕本発明は、データベースシステムの定義情報の登録管
理と実行時形式への変換機能を有するデータディクショ
ナリ・ディレクトリシステムに関するものである。

〔従来の技術〕

従来のデータディクショナリ・ディレクトリシステム
において、複数の定義情報を登録する場合、定義情報間
に定義内容の不整合があるか否かを定義情報の登録時に
確認していた。また従来のインデックス作成技術につい
ては特開昭58−2938号がある。

〔発明が解決しようとする問題点〕

定義情報を登録するときには、複数の定義情報がそれ
ぞれ関連する場合に、それらの定義情報間の整合性を確
認する必要があり、そのために、それらの関連する定義
情報が全て揃っていなければならなかった。例えば、関
連する上位の定義情報を登録した後に、その下位の定義
情報を登録するように行っていた。

このように従来のデータディクショナリ・ディレクト
リシステムでは、定義情報間の整合性の確認のために、
定義情報の登録に順序性が必要であった。

またディクショナリに既に登録した定義情報の更新に
ついても、定義情報間の整合性の確認のためにそれらの
関連する定義情報が全て揃っていなければならないとい
う制約があった。

以上により、従来のデータディクショナリ・ディレク
トリシステムにおけるデータベースシステムの定義情報
の登録及び管理作業には柔軟性がなかった。本発明の目
的は上記問題を解決することにある。

〔問題点を解決するための手段〕

データディクショナリ，ディレクトリシステムは、デ
ータベースシステムなどのシステム定義情報を、定義情
報の登録・管理に適したソース形式でディクショナリに
登録し、システム実行時にデータベース管理プログラム
などの参照に適したテーブル形式でディレクトリに登録
し管理するシステムである。

又、ディクショナリへの定義情報の登録単位（定義単
位）は、定義の対象や、意味合いによって利用者の便宜
を考えて設定され、ディレクトリテーブルの生成単位
は、データベース管理プログラムなどの実行時性能や、
テーブル生成に使用される定義単位間の独立性などを勘
案して設定される。一般に、定義単位とテーブルの生成
単位は、ｍ対ｎとなる。

一方、ディクショナリに登録された定義情報はディレ
クトリ生成のみならず、ユーザプログラムのコンパイル
時に、ユーザプログラム中のデータベースシステムアク
セス命令が、データベースシステムの定義内容に矛盾し
ないことを確認するために利用されるなど、多様な利用
形態がある。

それゆえ本発明においてはディクショナリへの定義情
報の登録時に関連定義間のチェックを行なわず、ディク
ショナリ登録の手段と関連定義間の整合性を確認する手
段を別に設け、必要に応じて整合性をチェックすること
とし、定義単位間にディクショナリ登録順序を規定しな
いことにしてディクショナリ登録・管理の操作性を向上
させる。

〔作用〕

ディクショナリ中の定義情報の定義単位の整合性チェ
ック機能によって、ディレクトリ生成や、ユーザプログ
ラムの検証等の為、ディクショナリの定義情報が必要と
なる直前に、ディクショナリに、登録されている必要な
定義情報だけに関して、前提となる定義情報との間の整
合性を確認できる。例えばディレクトリの生成にあたっ
ては関連定義情報について整合性が確認される。プログ
ラムコンパイル時にはある登録単位内にだけ関係する場
合は確認を省略し、他の登録単位にも関係する場合には
整合性の確認を行なう。従って、登録時の整合性チェッ
クは行なわれずその定義情報をディクショナリに登録管
理する場合、定義情報を幾つかの定義単位に分け、作業
者の都合に合わせた、ディクショナリへの登録・管理が
容易となる。

〔実施例〕

以下、本発明の一実施例を第１図から第14図により説
明する。

本発明のデータベースの制御方式が実現されるハード
ウェアの構成例を第１図に示す。１は、プロセッサであ
り、必要な情報の検索の処理を行なう。２は、定義情報
を格納しておく定義情報格納メモリで、３は、ディクシ
ョナリを格納しておくディクショナリファイル格納メモ
リ、４は、ディレクトリを格納しておくディレクトリフ
ァイル格納メモリ、５は、本発明による整合性チェック
を制御するプログラムを格納する定義操作プログラム格
納メモリ、６は、検索した情報を格納するワークエリア
を示している。ワークエリア６は、ＡからＪまでの格納
域を有し、更に、整合性チェック済か否かを示す整合性
チェック済フラグと、該当する情報が検索の結果、存在
しなかった場合、存在しなかったことを示すエラーフラ
グを有する。

本システムにおいて、ディクショナリファイル格納メ
モリ３内のディクショナリは、データベース全体の構造
を決定するもので、ディレクトリファイル格納メモリ４
内のディレクトリは、ディクショナリを利用者が利用し
易い構造に変換したものである。

以下の説明において、データベースの定義仕様はISO
X3H2−84−48 Draft Proposed“ネットワークデータ
ベースランゲージ”（Network Database Language:ND
Lと略す）に基づくものとする。

NDLでは、データベースの論理的な構造はレコードタ
イプ（以下レコード）、そのレコードを構成するコンポ
ーネントタイプ（以下コンポーネント）およびレコード
間の関係を示すセットタイプ（以下セット）によって定
義される。以下、レコード・フィールド・セットなどに
よって定義されるデータベースの論理的な構造を論理ス
キーマとよぶ。又論理スキーマの一部分を再定義したも
のをサブスキーマとよぶ。

サブスキーマは、論理スキーマのレコードに対してレ
コードビューに、コンポーネントに対してコンポーネン
トビューに、セットに対してセットビューによって定義
される。

データベースの利用者は、このサブスキーマの範囲内
のデータベースを利用できる。

論理スキーマの定義例を次に示す。データベースの論
理構造が第２図のとおりとし、レコード名がREC1,REC2
であり各レコードを構成するコンポーネント名が夫々C1
1,C12とC21,C22,C23である。レコードREC1とREC2のセッ
ト名がSET1である。

同様にサブスキーマの構造が第３図のとおりとし、レ
コードビュー名がRECV1,RECV2であり、各レコードビュ
ーを構成するコンポーネントビュー名が夫々CV11,CV12
とCV21,CV22である。レコードビューRECV1とRECV2のセ
ットビュー名がSETV1である。ディクショナリに登録さ
れる論理スキーマやサブスキーマは個々に名称やバージ
ョン番号が付与されている。論理スキーマの定義情報を
登録するディクショナリの構造を第４図に示す。

第４図では、スキーマ名や、システム内一意のスキー
マ番号、スキーマバージョン番号および論理スキーマ全
体に関係するスキーマ情報がスキーマレコード41に、レ
コード名やスキーマ内一意のレコード番号およびレコー
ド単位のレコード情報がレコードタイプレコード42に、
コンポーネント名やレコード内一意のコンポーネント番
号、コンポーネント単位のコンポーネント情報がコンポ
ーネントタイプレコード43に、セット名やスキーマ内一
意のセット番号、セットの親となるオーナレコードのレ
コード番号およびセット単位のセット情報がセットタイ
プレコード44に、セットの子となるメンバレコードのレ
コード番号とメンバレコード単位のメンバレコード情報
がセットメンバレコード45に登録される。

スキーマレコード41とレコードタイプレコード42、レ
コードタイプレコード42とコンポーネントレコード43、
スキーマレコード１とセットタイプレコード44、セット
タイプレコード44とセットメンバレコード45とがそれぞ
れセット関係を有する。

同様にサブスキーマの定義情報を登録するディクショ
ナリの構造を第５図に示す。

第５図では、サブスキーマ名やスキーマ内で一意なサ
ブスキーマ番号、サブスキーマバージョン番号、スキー
マ名、スキーマ番号、スキーマバージョン番号およびサ
ブスキーマ全体に関係するサブスキーマ情報がサブスキ
ーマレコード51に、レコードビュー名やサブスキーマ内
一意のレコードビュー番号、レコードビューに対応する
レコードのレコード名およびレコードビュー単位のレコ
ードビュー情報がレコードビューレコード52に、コンポ
ーネントビュー名やレコードビュー内一意のコンポーネ
ントビュー番号、コンポーネントビューに対応するコン
ポーネント名およびコンポーネントビュー単位のコンポ
ーネントビュー情報がコンポーネントビューレコード53
に、セットビュー名とサブスキーマ内一意のセットビュ
ー番号、セットビューに対応するセットのセット名およ
びセットビュー単位のセットビュー情報がセットビュー
レコード54に登録される。又サブスキーマレコード51と
レコードビューレコード52、レコードビューレコード52
とコンポーネントビューレコード53、サブスキーマレコ
ード51とセットビューレコード54とがそれぞれセット関
係を有する。

次に、各操作コマンドに基づく定義操作プログラムの
処理内容を、第６図のフローチャートにより説明する。
データベースシステムの定義は、定義項目の意味的分類
（例えば、データベースの定義、通信回線系の定義、シ
ステム実行環境系の定義、トランザクション類の定義な
ど）や、階層構造別（例えば、データベースの論理構造
を定義するスキーマ、使用範囲や使用時の名称など仮想
的視野を定義するサブスキーマなどの関係）などによ
り、幾つかの定義単位に分割して登録される。

定義操作プログラムが起動されると、定義情報格納メ
モリ２から、操作コマンド単位に、定義情報が入力さ
れ、第１図６のワークエリアＡに格納される（100）。
操作コマンドが入力されなければ（101）、処理を終了
する。操作コマンドが入力されると、その解析を行ない
（102）、ディクショナリ登録を指示する操作コマンド
ならば（103）、ディクショナリ登録処理を行なった（1
04）後、プログラムの始めに戻る。以下同様。ディクシ
ョナリ中の定義情報のチェックを指示する操作コマンド
ならば（105）、整合性チェック処理を行なう（106）。
ディクショナリ削除を指示す操作コマンドならば（10
7）、ディクショナリ削除処理を行なう（108）。ディレ
クトリ生成を指示する操作コマンドならば（109）、デ
ィレクトリ生成処理を行なう（110）。ディレクトリ削
除を指示する操作コマンドならば（111）、ディレクト
リ削除処理を行なう（112）。

なお、ここではプログラムコンパイル時の処理につい
ては説明が省略してある。コンパイル時には別の手段に
より定義情報の整合性が必要な範囲、即ち、複数の登録
単位に関わる処理かどうかを調べ、かつ、その定義情報
の整合性の確認が済んでないことを判別し、これらの条
件が成をしたとき整合性チェック処理106のルーチンを
共用して整合性チェック処理を行なう。

ディクショナリ登録処理104の概要を、第７図に基づ
き説明する。

ディクショナリ登録処理ルーチンが起動されると、定
義情報格納メモリ２から、ディクショナリに登録する定
義情報を入力し第１図のワークエリア６のＢに格納する
（201）。入力された定義情報を解析し（202）、文法エ
ラーがあれば（203）、診断メッセージを出力して処理
を終了する（205）。

定義情報が文法的に正しければその定義情報を例え
ば、スキーマ定義ならば第４図に例示したようなデータ
構造を有するディクショナリ・ファイル格納メモリへ登
録する（204）。

但し、このときサブスキーマを登録する場合であれば
第５図の定義情報中、スキーマ番号、スキーマバージョ
ン番号は空白となっている。というのはスキーマの定義
情報とは独立にサブスキーマ定義情報を登録するのでこ
の番号は不明であるからである。この２つの欄はスキー
マとの整合性がチェックされたときに書き込まれる。こ
の２つの欄が空白であるかどうかによって整合性チェッ
クが済んでいるかどうかが判る。

整合性チェック処理の概要を第８図のフローチャート
に基づき説明する。

整合性チェック処理ルーチンが起動されると整合性チ
ェックの対象となる操作コマンドで指定されたディクシ
ョナリ定義単位種別、定義情報名で特定される定義情報
と関連定義情報をディクショナリから検索しワークエリ
アC,Dに格納する（301）。検索された定義情報間の整合
性をチェックし（302）、整合性がなければ、整合性エ
ラーのメッセージを出力して（305）処理を終了する。
整合がとれていれば、被参照定義情報中に整合性チェッ
クを行なって得られる情報を付加し、ディクショナリを
更新する（304）。

上記処理内容を、スキーマとサブスキーマの定義情報
間の整合性チェック処理を例にとり、第９図のフローチ
ャートに基づき詳細に説明する。

本発明では、ディクショナリ中のスキーマおよびサブ
スキーマの定義情報は、それぞれ、第４図，第５図に示
すデータ構造を有するデータベースに登録されているも
のとする。

整合性チェック処理ルーチンが起動されると、整合性
チェックの対象がサブスキーマとスキーマとの整合性を
チェックするものであるときは、サブスキーマからスキ
ーマとの整合性をチェックすることとなるため、整合性
チェック処理ルーチンの対象がサブスキーマか否か判定
を行い（401）、操作コマンドの定義情報名をキーとし
て、第５図51に例示するサブスキーマレコードを検索し
ワークエリアＣに格納する（402）。

検索の結果該当サブスキーマレコードがディクショナ
リ中に存在しないと判明すると（403）、エラーメッセ
ージを出力して（404）処理を終了する。

検索の結果該当サブスキーマレコードが見つかるとワ
ークエリアＣに格納され、サブスキーマレコード中のス
キーマ名称をキーとして第４図41に例示するスキーマレ
コードを検索しワークエリアＤに格納する（405）。

検索の結果該当スキーマレコードがディクショナリ中
に存在しない（406）と判明すれば、エラーメッセージ
を出力し（407）処理を終了する。

検索の結果該当スキーマレコードが存在すると、スキ
ーマとサブスキーマの各定義情報間の整合性チェックを
行ない（408）、第１図６に示すエラーフラグがONであ
れば（409）エラーメッセージを出力（410）した後処理
を終了する。

整合性エラーがなければ、サブスキーマレコード中に
スキーマレコード中のスキーマ番号とスキーマバージョ
ン番号を付加（411）した後、ディクショナリ中のサブ
スキーマレコードを更新（412）する。

整合性チェック処理（302,408）につき、第14図のフ
ローチャートに基づき、詳細に説明する。

整合性チェック処理では、まず既に検索されているサ
ブスキーマレコードを親とするレコードである第５図に
示すレコードビューレコード52を１レコード順次取り出
してワークエリアＥに格納するためにレコードビューレ
コードの検索処理を行う（901）。既に検索されている
サブスキーマレコードと第５図に示す親子関係を有する
レコードビューレコードが存在するか否かを判定（90
2）し、存在いなければ910以降の処理を行なう。判定の
結果該当レコードビューレコードが存在すればワークエ
リアＥに格納し、更にレコードビューレコード中のレコ
ード名をキーとして、既に検索されて、第９図のフロー
チャートのステップ405で検索し、ワークエリアＤに格
納されているスキーマレコードを親とする第４図に示す
レコードタイプレコード42をワークエリアＦに格納する
ために、既に検索されているスキーマレコードと第４図
で示す親子関係となっているレコードタイプレコードの
検索処理を行う（903）。

該当レコードタイプレコードを検索し、該当レコード
タイプレコードが存在するか否か判定し（904）存在し
なければ909以降の処理を行なう。該当レコードタイプ
レコードがあればワークエリアＦに格納する。更に901
で検索したレコードビューレコードを親とする第５図に
示すコンポーネントビューレコード53を１レコード順次
取り出してワークエリアＧに格納するために、既に検索
されてワークエリアＥに格納されているレコードビュー
レコードと第５図で示す親子関係にあるコンポーネント
ビューレコードの検索処理を行う（905）。該当コンポ
ーネントビューレコードを検索し、該当コンポーネント
ビューレコードが存在するか否か判定（906）し、なけ
れば当該サブスキーマレコードを親とする他のレコード
ビューレコードに対して901以降の処理を繰返す。該当
コンポーネントビューレコードがあればワークエリアＧ
に格納する。更にコンポーネントビューレコード中のコ
ンポーネント名をキーとして、903で検索されたレコー
ドタイプレコードを親とする第４図に示すコンポーネン
トタイプレコード43をワークエリアＨに格納するため
に、既に検索されてワークエリアＦに格納されているレ
コードタイプレコードと第４図に示す親子関係にあるコ
ンポーネントタイプレコードの検索処理を行う（90
7）。該当コンポーネントタイプレコードを検索（908）
し、該当コンポーネントタイプレコードが存在するか否
か判定し、なければ第１図６に示すエラーフラグをON
（909）にして処理を終了する。検索の結果該当コンポ
ーネントタイプレコードがあれば、901で検索したレコ
ードビューレコードを親とする他のコンポーネントビュ
ーレコードに対して、905以降の処理を繰返す。

910では、該当サブスキーマレコードを親とする第５
図に示すセットビューレコード54を順次取り出してワー
クエリアＩに格納するために、既に検索されてワークエ
リアＣに格納されているザブスキーマレコードと第５図
に示す親子関係にあるセットビューレコードの検索処理
を行う（910）。

該当セットビューレコードを検索（911）し、該当セ
ットビューレコードが存在するか否か判定し、存在しな
ければ処理を終了する。該当セットビューレコードがあ
ればワークエリアＩに格納する。更に、セットビューレ
コード中のセット名をキーとし、既に検索されているス
キーマレコードを親とする第４図に示すセットタイプレ
コード４を検索し、ワークエリアＪに格納する処理を行
う（912）。該当セットタイプレコードを検索し、該当
セットタイプレコードが存在するか否か判定（913）
し、存在しなければ909以降の処理を行なう。該当セッ
トタイプレコードがあれば当該サブスキーマレコードを
親とする他のセットビューレコードに対して、910以降
の処理を繰返す。このように、サブスキーマとスキーマ
の整合性のチェック処理は、サブスキーマの定義情報を
ディクショナリで管理されるデータ構造を使い、サブス
キーマのデータ構造中のレコードビューレコード内のス
キーマのレコード名、コンポーネントビューレコード内
のスキーマのコンポーネント名、セットビューレコード
内のスキーマのセット名をそれぞれ突き合わせて、整合
性をチェックするものである。

上記整合性チェック処理において、整合性がとれなけ
れば、すべてエラーフラグがONとなり、第９図で説明し
たようにエラーメッセージを出力することになる（41
0）。整合性がとれれば、エラーフラブはONとならず、
第９図で説明したように、スキーマ番号、スキーマバー
ジョン番号をサブスキーマレコードに付加し（411）、
サブスキーマレコードを再登録して（412）、サブスキ
ーマとスキーマの整合性チェックの処理を終了する。

ディクショナリ削除処理の概要を、第10図のフローチ
ャートに基づき説明する。

ディクショナリ削除処理ルーチンは、起動されると、
操作コマンド中のディクショナリメンバ種別と、定義情
報名とで特定されるディクショナリ中の定義情報を削除
する（701）。該当する定義情報がない（702）と、エラ
ーメッセージを出力（703）して処理を終了する。

次に、削除対象のディクショナリメンバ（定義単位）
が他の定義単位から参照されるものでなければ（704）
処理を終了し、参照される定義単位であれば、参照して
いる定義単位中、削除した定義情報を参照している定義
情報を、操作コマンド中の定義情報名をキーとして検索
しワークエリアＣに格納する（705）。該当定義情報が
なければ（706）処理を終了し、存在すればワークエリ
アＣ中のその定義情報中の整合性チェックを行なったと
きに書き込まれる情報（スキーマ番号，スキーマバージ
ョン番号など）をクリアして（707）、ディクショナリ
を更新する（708）。

ディレクトリ生成処理の概要を、第11図のフローチャ
ートに基づき説明する。

ディレクトリ生成処理ルーチンは、起動されると、デ
ィレクトリ生成の定義情報間の整合性が確認され（50
1）、整合性チェック済でなければ（502）、整合性チェ
ック処理を要求する（503）。正常に処理が行なわれれ
ば（507,504）、501以降の処理を繰返し、異常があれ
ば、処理を終了する。なお、本例では第６図の整合性チ
ェック処理ルーチンへ処理を要求することとしたが、デ
ィレクトリ生成処理ルーチン中に整合性チェックを行な
う機能を持たせてもよい。

整合性チェック済であれば（502）、ディレクトリテ
ーブルを生成（505）後、ディレクトリファイル格納メ
モリに登録する（506）。

整合性の確認（501）方法につき、サブスキーマ定義
情報をもとにしたディレクトリテーブル生成時を例にと
り、第12図のフローチャートに基づき詳細に説明する。

まず、操作コマンドによる指示がサブスキーマの定義
情報によるディレクトリテーブル生成であれば（60
1）、操作コマンド中の定義情報名をキーとして、ディ
クショナリファイル格納メモリから、サブスキーマレコ
ードを検索しワークエリアＣに格納する処理を行う（60
2）。

検索の結果該当サブスキーマレコードがなければ（60
3）エラーメッセージを出力（604）して処理を終了す
る。

該当サブスキーマレコードがあれば（603）ワークエ
リアＣに格納し、更にサブスキーマレコード中にスキー
マ番号が格納されているかを判定し（605）存在すれば
第１図に例示するような整合性チェック済フラグ６をON
（607）にし、存在しなければ、整合性チェック済フラ
グをOFF（606）にした後、処理を終了する。

ディレクトリ削除処理の概要を、第13図のフローチャ
ートに基づき説明する。

ディレクトリ削除処理ルーチンは、起動されると、該
当するディクショナリテーブルがあるかどうかを調べ
（802）、あれば操作コマンド中のディレクトリメンバ
種別と定義情報名とで特定されるディレクトリ中のディ
レクトリテーブルを削除する（801）。該当するディレ
クトリテーブルがない（802）と、エラーメッセージを
出力（803）して処理を終了する。

〔発明の効果〕

本発明によれば、ディクショナリへのデータベースシ
ステムの定義情報を幾つかの定義単位に分けて登録する
場合、各定義単位間の整合性を確認する機能を別個に設
けたことにより、ディレクトリ生成におけるような整合
性のとれた定義情報が必要になったときに、その定義内
容の整合性を確認することができ、その時までの各定義
単位の登録の順序性や、登録した定義情報の更新が自由
となることから、ディクショナリへの定義情報の登録・
管理の操作性が向上する。

【図面の簡単な説明】

第１図は本発明の一実施例のハードウェア構成図、第２
図はデータベースの論理的な構造を例示した図、第３図
は第２図で例示したデータベースの仮想的な視野を例示
した図、第４図はスキーマの定義情報をディクショナリ
で管理する場合、そのデータ構造を例示した図、第５図
はサブスキーマ定義情報をディクショナリで管理する場
合、そのデータ構造を例示した図、第６図は本発明の一
実施例である定義操作プログラムの全体処理概要を例示
した図、第７図は第６図におけるディクショナリ登録処
理を例示した図、第８図は第６図における整合性チェッ
ク処理を例示した図、第９図は第８図の整合性チェック
処理をサブスキーマ定義の場合を例に詳細に例示した
図、第10図は第６図のディクショナリ削除処理を例示し
た図、第11図は第６図のディレクトリ生成処理を例示し
た図、第12図は第11図のディレクトリ生成処理における
整合性チェック済か否かの判定ルーチンを例示した図第
13図は第６図のディレクトリ削除処理を例示した図、第
14図は、第９図で示したサブスキーマ定義とスキーマ定
義との整合性チェック処理を詳細に説明した図である。

フロントページの続き (72)発明者和歌山哲横浜市戸塚区戸塚町5030番地株式会社日立製作所ソフトウエア工場内 (72)発明者亀城嘉人横浜市戸塚区戸塚町5030番地株式会社日立製作所ソフトウエア工場内 (72)発明者浦川誠横浜市戸塚区戸塚町5030番地株式会社日立製作所ソフトウエア工場内 (72)発明者徳永幹彦横浜市戸塚区戸塚町5030番地株式会社日立製作所ソフトウエア工場内 (72)発明者鴨志田毅横浜市戸塚区戸塚町5030番地株式会社日立製作所ソフトウエア工場内 (72)発明者米田茂川崎市麻生区王禅寺1099番地株式会社日立製作所システム開発研究所内 (72)発明者木保清隆横浜市戸塚区戸塚町5030番地株式会社日立製作所ソフトウエア工場内

Claims

(57)【特許請求の範囲】

【請求項１】データベースシステムにおけるシステム定
義情報をディクショナリに登録し、該システム実行時に
システム定義情報をディレクトリに登録し、管理するデ
ータディクショナリ・ディレクトリシステムにおいて、データベースの論理的な構造を定義する第１の定義情報
とデータベースの利用範囲を定義する第２の定義情報を
別々に登録する登録手段と、前記ディクショナリに登録された前記第１及び第２の定
義情報間の定義内容の整合性の確認処理を起動する起動
手段と、前記起動手段による起動指示に応じて前記確認処理を実
行し前記確認処理を実行して得た情報を前記定義情報に
付加する確認手段を有することを特徴とするデータディ
クショナリ・ディレクトリシステム。
【請求項２】前記起動手段は、上記登録手段による登録
と非連動に確認処理を起動することを特徴とする特許請
求の範囲第１項記載のデータディクショナリ・ディレク
トリシステム。
【請求項３】前記起動手段は、前記ディクショナリ中の
登録された定義情報間の整合性の確認の必要がある処理
が発生し、且つ、関係する定義情報に関して整合性の確
認が済んでいないことを検知して確認処理を起動するこ
とを特徴とする特許請求の範囲第２項記載のデータディ
クショナリ・ディレクトリシステム。