JPS62173545A - デ−タデイクシヨナリ・デイレクトリの維持管理方式 - Google Patents

Abstract

(57)【要約】本公報は電子出願前の出願データであるた
め要約のデータは記録されません。

Description

【発明の詳細な説明】 〔産業上の利用分野〕 本発明は、データベースシステムに係り、特にデータデ
ィクショナリ・ディレクトリの操作に好適なデータディ
クショナリ・ディレクトリの維持管理方式に関する。

〔従来の技術〕

と＊のデー々デノ々シ、ナリ、デスレクトリシステムの
維持管理方式は、ディクショナリとディレクトリのそれ
ぞれの内容を管理する場合において、ディクショナリと
ディレクトリ間の定義情報の履歴が、ディクショナリと
ディレクトリ双方に格納されておらず、ディクショナリ
とディレクトリ間の定義情報の整合性維持、関連定義情
報の一括操作について配慮されていなかった。

尚、この種の維持管理方式として関連するものには、例
えば特開昭５５−３２１４０号が挙げられる。

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

上記従来技術は、ブイレフ）　ＩＪの定義情報に対する
操作結果について、ディクショナ＋、ｌ　中に。

保持されているものの、ディレクトリ生成の元となった
定義情報が必ずしも全てディクショナリ中に格納されて
いるとは限らず、またディレクトリ生成の元となった定
義情報がディクショナリに格納されている場合でも、当
該定義情報に対する操作が、当該定義情報を元にして生
成されたディレクトリの定義情報とは無関係になされる
ため、定義情報の変更、ディレクトリの削除、生成の場
合、利用者の操作誤りを防止したり、整合性維持のため
の関連情報の一括操作の点について配慮されておらず、
データディクシヲナリ・ディレクトリシステムの信頼性
に問題があった。

本発明の目的は、ディクショナリとディレクトリの整合
性維持のために、利用者の誤った操作を防止し、関連す
る定義情報への一括操作を行うデータディクショナリ・
ディレクトリの維持管理方式を提供することにある。

〔間迦点を解決するための手段〕

上記目的は、データディクショナリ・ディレクトリの中
に、ディクショナリとディレクトリ双方に対する操作時
の定義情報の履歴を保持せしめ、当該履歴を使って、利
用者の定義情報削除等の操作命令に対し、関連する定義
情報のみを容易に選別して、−指操作を行うことにより
、ディクショナリとディレクトリ間の整合性の維持が図
られる。

〔作用〕 データディクショナリ・ディレクトリの維持管理方式は
、データディクショナリ・ディレクトリ内にディクシ田
ナリとディレクトリに対する操作時の定義情報のｂ歴を
格納し、関連する定義情報を定義情報の履歴を使って判
別する。

これによって、利用者の操作命令に対し、関連する定義
情報のみを容易に操作でき、また関連する定義情報を関
係付けて一括操作できるので、ディクショナリとディレ
クトリ間の整合性の維持が図られる。

〔実施例〕

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

本発明のデータディクシ璽ナリ・ディレクトリの維持管
理方式が実現されるハードウェアの一構成図を第１図に
示す。１は、プロセッサであり、必要な情報の検索等の
処理を行う。２は、定義情報を格納しておく定義情報格
納メモリ、６は、ディクショナリを格納しておくディク
ショナリファイル格納メモリ、４は、ディレクトリを格
納しておくディレクトリファイル格納メモリ、５は、本
発明のデータディクシ叢ナリ・ディレクトリの維持管理
に関するプログラムを格納する定義操作プロゲラム格納
メモリである。

６は、一連の作業の中間結果として検索した情報を格納
するワークエリアを示している。

尚、データベースの定義仕様は、ｌ５Ｏ（Ｘ３Ｈ２−８
４−４８）ネットワークデータベースランゲジ（Ｎｅｔ
ｗｏｒｋ　Ｄａｔａｂａｓｅ　Ｌａｎｇｕａｇｅ　）に
基づく　Ｏ 本システムにおいて、ディクシ目ナリは、データペース
全体の構造を決定するもので、ディレクトリは、ディク
ショナリの構造に基づいて、ユーザが利用し易い構造と
なっている。

データベースの論理的構造は、レコードタイプ（以下レ
コード）、そのレコードを構成するコンポーネントタイ
プ（以下コンポーネント）、松ドアにし１−に＋闇の向
瓜ル箒すふ１．、に々Ｉブを以下セット）によって定義
される。以上のように定義されるデータベースの論理的
構造を論理スキーマと呼び、論理スキーマの一部を再定
義したものをサブスキーマと呼ぶ。サブスキーマは、論
理スキーマのレコードに対応してレコードビュー、コン
ポーネントに対応してコンポーネントビュー、セットに
対応してセットピユーと呼ばれ、定義される。データベ
ースのユーザは、このサブスキーマの範凹内においてデ
ータベースを利用できる。

論理スキーマやサブスキーマは、個々に名称やバージョ
ン番号が付されていて、ディクショナリに登録される。

論理スキー７の定義情報を登録するディクシヲナリの構
造を第２図に示す。

レコード１１には、スキーマ名、システム内−意のスキ
ーマ番号、スキーマバージョン番号および論理スキーマ
全体に関するスキーマ情報が含まれている。レコード１
２には、レコード名、スキーマ内−ｔのレコード番号お
よびレコード単位のレコード情報が含まれている。レコ
ード１３には、コンポーネント名、レコード内−意のコ
ンポーネント番号およびコンポーネント単位のコンポー
ネント情報が含まれている。レコード１４には、セット
名、スキーマ内−意のセット番号、セットの親となるオ
ーナレコードのレコード番号およびセット単位のセット
情報が含まれている。レコード１５には、セットの子と
なるメンバレコードのレコード番号トメンバレコード単
位のメンバレコード情報が含まれている。ディクショナ
リにおいて、レコード１１とレコード１２．レコード１
２とレコード１３　。

レコード１１トレコード１４．レコード１４とレコード
１５がそれぞれセット関係にある。

同様に第３図に、サブスキーマの定義情報を登録するデ
ィクショナリの構造を示す。レコード２１には、サブス
キーマ名、スキーマ内−意のサブスキーマ番号、サブス
キーマバージョン番号、スキーマ名、スキーマバージョ
ン番号およびサブスキーマ全体に関するサブスキーマ情
報が含まれている。レコード２２には、レコードビュー
名、サブスキーマ内−意のレコードビュ一番号、レコー
ドビューに対応するレコードのレコード名およびレコー
ドピー一単位のレコードビニ−情報が含まれている。レ
コード２６にハ、コンポーネントビュー名、レコードビ
ュー内−意のコンポーネントビニ一番号、コンポーネン
トピユーに対応するコンポーネント名およびコンポーネ
ントビュ一単位のコンポーネントビニ−情報が含まれて
いる。レコード２４には、セットビュー名、サブスキー
マ内−意の七ントビ二一番号、セットビニ−に対応する
セット名およびセットビニ一単位のセットビュー情報が
含まれている。ディクシ１ナリにおいて、レコード２１
とレコード２２、レコード２とレコード２３、レコード
１とレコード２４がそれぞれセット関係にある。

また、ある名称とバージョン番号とで識別される論理ス
キーマと、ある名称とバージョン番号とで識別されるサ
ブスキーマとが正しく関係付けられたとき、この１組の
論理スキーマとサブスキーマに対して世代番号が付与さ
れる。

名称が同じ組合せでもバージョン番号が異なれば別の世
代番号が与えられる。世代番号は関係付けられた時点に
依存し、バージョン番号の大きさに依存しない。

世代番号を登録するディクショナリの構造を第４図に示
す。第４図では、関係付けられた論理スキーマのスキー
マ番号とバージョン番号、サブスキーマのサブスキーマ
番号とバージョン番号および世代番号とが別レコードに
登録される０ このようにして、−組の論理スキーマとサブスキーマは
、世代管理がなされ、いくつもの世代がレコードに登録
され、維持管理されることになる。

ディクショナリに登録された定義情報は、ディレクトリ
生成プログラムによってデータベース管理プログラムが
実行時に参照しゃすい形式、つまりディレクトリテーブ
ルに編集されディレクトリ７丁イルに合侭六わスへその
也　舟什釆号も合わせて登録される。

ディレクトリテーブルの例を第５図に示す。

ここでビニ−情報は、ビニ−の種別毎にひとまとまりの
テーブルとして構成される。また個々のビュー情報は、
各テーブルの第何番目即ち配列番号が、ディクシ１ナリ
中のビュ一番号と一致するように生成される。

ディクショナリやディレクトリへの定義情報の登録、削
除などは、定義操作プログラムによる０ ディクショナリ、ディレクトリの利用者は、定義操作プ
ログラムに対して、次に例示するような操作コマンドや
定義情報を与える必要がある。

定義情報のディクショナリへの登録は例えばＥＮＴＲＹ
操作コマンドを用い ＊ＥＮＴＲＹ　　ＤＩＣＴＩＯＮＡＲＹくディクショナ
リメンバ種別〉〈定義情報〉と指定する。

ここで、〈ディクショナリメンバ槙別〉とは、ディクシ
ョナリへの定義情報の登録を、幾つかの定義単位に分け
たとき、その定義単位を識別。

するのに指定する記号である。又、く定義情動とは、デ
ィクショナリに登録する定義ソースのことである。

同様に、ディクショナリからの定義情報の削除は、例え
ばＤＥＬＥＴＥ操作コマンドを用い、＊ＤＥＬＥＴＥ　
　ＤＩＣＴＩＯＮＡＲＹくディクショナリメンバ種別〉
＜定義情報名〉と指定する。

ここで、く定義情報名〉とは、登録した定義情報に含ま
れる定義情報の識別名称を示す。

又、ディクショナリ中の定義情報間の整合性チェックは
、例えば、ＣＨＥＣＫ操作コマンドを用い ＊ＣＨＥＣＫ　　ＤＩＣＴＩＯＮＡＲＹくディクシ田ナ
リメンバ種別〉く定義情報名〉と指定する。

ここで、〈ディクショナリメンバ種別〉やく定義情報名
〉は関連をチェックする定義情報のうちの従となるもの
指定する。例えば、スキーマとサブスキーマとでは、サ
ブスキーマの方を指定する。

又１デイレクトリの生成は、例えば、ＥＮＴＲＹ操作コ
マンドを用い ＊ＥＮＴ：ＲＹ　　ＤＩＲＥＣＴＯＲＹ〈ブイレフ）　
＋１メンバ種別〉〈定義情報名〉と指定する。

ここで、くディレクトリメンバ種別〉とは、生成したい
ディレクトリテーブルの識別記号である。

同様に翫ディレクトリの削除は例えば、ＤＥＬＥＴＥ操
作コマンドを用い、 ＊ＤＥＬＥＴＥ　　ＤＩＲＥＣＴＯＲＹくブイレフ）　
＋１メンバ種別〉＜定義情報名〉と指定する。

次に、各操作コマンドに基づく定義操作プログラムの処
理内容を、第６図の７０−チャートにより説明する。

定義操作プログラムが起動されると、定義情報格納メモ
リ２から操作コマンド単位に、定義情報が入力され、ワ
ークエリアＡに格納される（＋００）。操作コマンドが
入力されなければ（１０１）、処理を終了する。操作コ
マンドが入力されると、その解析を行ない（１０２）、
ディクショナリ登録を指示する操作コマンドならば（１
０３）、ディクショナリ登録処理を行なった（１０４）
後プログラムの始めに戻る。以下同機に、ディクショナ
リ中の定義情報のチェックを指示する操作コマンドなら
ば（１０５）、整合性チェック処理を行なう（１０（Ｓ
）。ディクショナリ削除を指示する操作コマンドならば
（１０７）、ディクショナリ削除処理を行なう（１０８
）。ディレクトリ生成を指示する操作コマンドならば（
１０９）　、ディレクトリ生成処理を行なう（１１０）
。ディレクトリ削除を指示する操作コマンドならば（１
１１）、ディレクトリ削除処理を行なう（１１２）。

ディクショナリ登録処理の概要を、第７図に甘づ−に＋
詣１旧ナス ディクショナリ登録処理ルーテンが起動されると、定義
情報格納メモリから、ディクシコナリに登録する定義情
報を入力し、ワークエリアＢに格納する（２Ｏｆ）。入
力された定義情報を解析しく２０２）、文法エラーがあ
れば（２０３）、診断メツセージを出力して処理を終了
する（２０５）。

定義情報が文法的に正しければ、データ構造を有するデ
ィクショナリ・ファイル格納メモリへ登録する（２０４
）。但し、サブスキーマ登録処理の場合は、サブスキー
マレフードに、スキーマ情報が埋め込まれるが、未だ、
スキーマが存在しないときは、スキーマ名称は仮に埋め
込むが、スキーマ番号とスキーマバージョン番号は不明
であるので空白のままにしておく。空白となったスキー
マ番号とスキーマバージョン番号は、整合性チェック時
に、サブスキーマレコードに埋め込まれることになる。

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

整合性チェック処理ルーテンが起動されると。

整合性チェックの対象となる定義情報をディクショナリ
から検索する（３０１）。検索された定。

残情報間に整合性をチェックしく３０２）、整合性がな
ければ、整合性エラーのメツセージを円方して（３０５
）処理を終了する。整合がとれていれば、主の定義情報
、例えばスキーマとサブスキーマであれば、スキーマの
定義情報を、従の定義情報、上記例ではサブスキーマの
定義情報に埋めこみ、ディクショナリを更新する（３０
４）。

具体的には、サブスキーマレコードに、スキーマ番号と
スキーマバージョン番号を埋め込みディクショナリを更
新する。

上記処理内容を、スキーマとサブスキーマの定義情報を
例にとり、第９図の７０−チャートに基づき詳細に説明
する。

整合性チェック処理ルーテンが起動されると、整合性チ
ェックの対象がサブスキーマとスキーマであるならば（
４０１）　、カウンタＣＮＴに０をセラ）（４０２）後
、操作コマンドの定義情報名をキーとして、サブスキー
マレコードヲ検索する（４０３）。

カウンタは、整合性が済んだかどうかをチェックプログ
ラムが認識するためのもので、当該プログラムに対して
割り当てられたメモリエリア内に設定される。

該当サブスキーマレコードがディクショナリ中に存在し
ないと（４０４）、エラーメツセージを出力して（４０
５）処理を終了する。

該当サブスキーマレコードが見つかると、それを親レコ
ードとするスキーマリストレコードを検索する（４０６
）。スキーマリストレコードとは、ディクショナリ中に
、スキーマのリストを持りているレコードのことである
。該当レコードがないと（４０７）、カウンタＣＮＴが
１以上であれば（４０Ｂ）、ディクショナリ中のサブス
キーマレコード中の整合性チェックフラグをＯＮにした
（４１０）後、整合性チェック処理を正常終了する。カ
ウンタＣＮＴがＯならば、エラーメツセージを円方して
（４０９）処理を終了する。

スキーマリストレコードが見つかると、スキーマリスト
レコード中のスキーマ名称をキーとしてスキーマレフー
ドを検索する（４１１　）。

該当スキーマレコードがディクシｌチリ中に存在しない
（４１２）とエラーメツセージを出力（４１３）Ｌ、て
処理を終了する。

該当スキーマレコードが見つかると、カウンタＣＮＴを
１加算（４１４）する。更に、関連するスキーマが存在
するか否か、スキーマリストを検索しく４０６）、これ
以上関連スキーマが存在しなければ、４０８の処理に移
行する。カウンタＣＮＴは１以上であるから、整合性チ
ェックフラグをＯＮにしく４１０Ｌサブスキーマレコー
ドに、スキーマ番号とスキーマバージョン番号を埋め込
み、整合性チェック処理を終了する。

ブイレフ）　ＩＪ生成処理の概要を、第１０図のフロー
チャートに基づき説明する。

ディレクトリ生成処理ルーテンは、起動されると、ディ
レクトリ生成の対象となる定―情報間の整合性が確認さ
れ（５０１）　、整合性チェック済でなければ（５０２
）、整合性チェック処理を実施（５０３）Ｌ、正常に処
理が行なわれれば（５０４）、５０１以降の処理を繰返
し、異常があれば、処理を終了する。

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

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

まず、操作コマンドによる指示が、サブスキーＶの定義
情報によるディレクトリテーブル生成であれば（６０１
）、操作コマンド中の定義情報名をキーとして、ディク
シヲナリファイル格納メモリから、サブスキーマレコー
ドを検索する（６０２）。

該当レコードがなければ（６０３）エラーメッセージを
出力（６０４）Ｌ、て処理を終了する。

該当サブスキーマレコードがあれば（６０３）、レコー
ド中の整合性チェックフラグを判定（６０５）し、ＯＮ
ならば、整合性チェ７り済フラグにＯＮを代入（＜５０
７）Ｌ、ＯＦＦならば、整合性チェック済フラグにＯＦ
Ｆを代入（６０６）後、処理を終了する。

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

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

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

ディレクトリ削除処理ルーチンは、起動されると、操作
コマンド中のディレクトリメンバ種別と定義情報名とで
特定されるディレクトリ中のディレクトリテーブルを削
除する（：ａＯｌ）。

該当するディレクトリテーブルがない（８０２）と、エ
ラーメツセージを出力（８０３）して処理を終了する。

第１４図は、ディクショナリに登録された各メンバ間の
論理的な階層を示す図。第１５図は、ディクシ目ナリチ
ェック処理の動作を示す図。

第１６図は、ディクショナリ削除のディクショナリメン
バの関連チェック処理の動作を示す図である。

第１４図において、ディクショナリ登録されたメンバ間
の論理的な階層を、データベースの論理構造を定義する
スキーマ、データの格納方法を定義する格納スキーマ及
び、物理エリア定義の各定義を、ディクショナリ登録さ
れた各メンバとする例によって説明する。

スキーマ及び物理エリア定義は、それぞれの定義中に、
他定義文の定義名称又は定義内容を参照して定義する項
目のない定義である。従って個々独立に定義することが
できるので最上位レベルに位置づけている。これに対し
、サブスキーマ及び格納スキーマは、それぞれ、サブス
キーマはスキーマの定銭名称と、定義内容又、格納スキ
ーマはスキーマと物理エリア定義の定義名称と定義内容
を参照して定義する項目を含む定義である。従って、ス
キーマや物理エリア定義より下位に位置づけている。こ
の階層関係において、上位のメンバを親メンバ、下位の
メンバを子メンバと呼び、親メンバは、それ自身が削除
又は更新されると子メンバに影響があることを示してい
る。これらと同様に、ディクショナリで管理されるすべ
ての定義について階層関係を定義して、ディクショナリ
メンバの関連を管理する。ディクショナリに各メンバを
登録しただけの状態では、第１４図に示すような階層に
基づく関連は結ばれていないので、メンバの削除更新は
自由にできる状態である。

第１５図において、ディクシコナリチェック処理の動作
を説明する。チェック処理は、子メンバを対象に以下の
ように行われる。

ディクショナリチェックの要求により、指定された名称
を持つ最新世代のディクショナリメンバを検索し、その
親メンバの定義名称又は定義内容を参照している各項目
について、親メンバとのチェックを繰り返し行う（１７
０１）。

親メンバを参照している項目で指定されている親メンバ
が、ディクショナリメンパとして登録されているか検索
しく１７０２）、登録されている場合は、チェック処理
を進め、登録されていない場合は、エラーメツセージを
出力する。

親メンバを参照している項目に指定された内容親メンバ
の定義内容と不整合な場合がある。

例えは、第１４図のスキーマと格納スキーマの関係にお
いて、子メンバである格納スキーマで格納しようとする
レコードがスキーマで定義されていなかったり、キーと
して指定したコンポーネントの属性が不正であるような
場合が該当する。

このような場合に対し、参照している親メンバの内容が
、子メンバで指定内容に対し整合がとれているかチェッ
クを行い（１７０３）　、整合がとれている場合は、参
照している親メンバのディクショナリ中の管理情報を子
メンバにチェック済の情報として書き込み（１７０４）
整合な内容については、親メンバ中の整合のとれていな
い定義のステートメント番号とその不正内容を表示した
メツセージを出力する。

参照しているすべての親メンバとのチェックが正常終了
したとき、ディクショナリチェックは正常終了となり、
不正があった場合、親メンバの管理情報はディクショナ
リチェック実行前の状態にもどす（１７０５）。

ディクショナリチェックが正常終了した時点で、第１４
図に示す階層がディクショナリ中に結ばれ、定義間の整
合性をチェックした履歴が管理され、ブイレフ）　ｌ］
生成可能な状態になる。

ディクショナリに登録された各メンバは、ディクショナ
リ登録、ディクシ甘ナリチェック及びブイレフ）　＋１
生成の各操作が行われ、次の３態が存在する。

（す＜ディクショナリ登録〉操作により、ディクショナ
リに登録されただけのメンバの状態は、第１４図に示す
ような階層関係は結ばれていない。

（２）＜ディクショナリチェック〉操作により、メンバ
間の整合性チェック済の情報が書き込まれ、第１４図に
示すような階層関係が結ばれる。

（３）＜ディレクトリ生成〉操作は、くディクショナリ
チェック〉操作により、メンバ間の整合性のとれている
場合だけ実行され、生成されたディレクトリメンバに、
ディクシミナリメンバの構成メンバ情報として、各ディ
クショナリメンバの管理情報が書き込まれる。

誤操作防止処理について、ディクンヨナリ削除を例にと
り、第１６図について説明する。

特定のディクショナリメンバ削除の要求がなされると、
指定されたメンバ名であって指定された世代のディクシ
ョナリメンバをディクンヨナリの中から検索する（１８
０１　）。検索の結果、指定されたディクショナリメン
バが存在しなかった場合は、エラーメツセージを出力し
てディクショナリ削除の処理を終了する。検索の結果、
指定されたディクショナリメンバが存在した番台であっ
て、ディクショナリ中の関連メンバとのチェックを行わ
ない場合には（１８０２）、そのまま削除処理を行い（
１８０４）、ディクショナリ削除処理を終了する。また
、指定されたディクンヨナリメンバが存在した場合であ
って、ディクショナリ中の関連メンバとのチェックを行
う場合には（１８０２）、ディクショナリ中に、関連す
る定義情報間に整合性をチェックした履歴を保持管理し
ているので、整合性チェック済の関連メンバも削除する
。この場合、削除要求されたディクショナリメンバを親
メンバとする全ての子メンバのうち、指定されたメンバ
名であって、指定された世代とだけ整合性のとれている
子メンバが存在するときは、削除基準を満すことになり
（１８０３）、関連メンバも含めディクショナリ削除の
処理を行い（１８０４）　、Ｋ理を終了する。

これにより、ディクシ目ナリ中の関連メンバのチェック
を、整合性チェック済の各層を使って行うので、ユーザ
の誤操作を防止し）ディクショナリでの定義間の整合性
を確保できる。

次に関連する定義情報の一括操作について説明する。ま
ず、ディレクトリ生成処理におけるディクショナリディ
レクトリ一括操作について第１７図のフローチャートに
基づき、より詳細に説明する。

ディレクトリ生成の要求により、まず生成要求のあった
名称を持つディクショナリメンバをディクショナリの中
から検索しく１９０１）、ディレクトリ生成時、の各層
情報となるディレクトリ生成層ｆイクショナリメンバテ
ーブルにディレクトリ生成要求のメンバ情報をセントす
る（１９０２）。次にこのディクショナリメンバをもと
にディレクトリ生成に必要である関連ディクショナリメ
ンパの検索を行い（１９０３）　、関連ディクショナリ
メンバが存在すれば（１９０４）ディレクトリ生成用デ
ィクショナリメンバテーブルにディレクトリ生成要求の
メンバ情報をセットする処理を関連メンバ数行い、関連
ディクショナリメンバが存在しなくなれは（１９０４）
、既に生成されているディレクトリ群の中を検索して、
生成要求のあった名称を持つディレクトリメンバが存在
するかを調べ、存在しない場合は（１９０５）、ディク
シ１す１１中にディレクトリ生成用ディクンヨナリメン
バテーブルを格納しく１９０８）、更にディレクトリ中
にディレクトリ生成用ディクショナリメン／くテーブル
を格納する（１９０９）処理を行う。生成要求のあった
名称を持つディレクトリメンバが存在する場合（１９０
５）、ブイレフ）　ＩＩ中に格納しておいたディレクト
リ生成用ディクショナリメンバテーブルを検索しく１９
０（Ｓ）、１９０２の処理で作成したテーブルの内容と
同一であるかを調べる。

これにより同一であることが判明すれば（１９０７）生
成要求により同一内容のブイレフ）　１１メンバが作成
されることとなるため、ディレクトリ生成処理を終了す
る。２つのテーブルの内容が異なる場合（１９０７）、
デイクシヨナリ中に、１９０２の処理で作成したディレ
クトリ生成用ディクショナリメンバテーブルを格納（１
９０８）すると共に、ディレクトリ中にも同様のテーブ
ルを格納（１９０９）する。

これにより、デイクシヨナリ及びディレクトリにディレ
クトリ生成時の履歴情報を持つことができ、ディレクト
リ生成時、同一の内容を持つメンバを生成することを防
ぐことも可能となるＯ 次にディクショナリ削除処理におけるディクショナリデ
ィレクトリ一括操作について第１８図のフローチャート
に基づき、より詳細に説明する０ ディクショナリ削除、要求のオプション指定として一括
操作がない場合（２００１）ディレクトリと無関係にデ
ィクショナリ削除を行う（２０１４）。一括操作の指定
がある場合（２００１）、まず、削除しようとするディ
クシ目ナリメンバの検索を行い（２００２）　、そのデ
ィクショナリメンバ中にディレクトリ生成用ディクショ
ナリメンパテーブルが存在するかどうか検索する（２０
０３）。デイクシヨナリ中に当該テーブルが存在する場
合（２００４）、Ｍ連するディレクトリメンバが存在す
るわけであるから、一括操作の対象となる。関連するデ
ィレクトリメンバを１つのテーブルに生成したものを、
ディレクトリメンバ情報テーブルという。関連するディ
レクトリメンバをディレクトリメンバ情報テーブルニ格
納スる（２００５）。ディレクトリメンバ情報テーブル
生成後又は、関連ディレクトリメンバが存在しなかった
場合（２００４）、削除しようとするディクショナリメ
ンバに関連するディクショナリメンバを検索しく２００
６）、Ｍ達するディクショナリメンバが存在すれは（２
００７）同様にして関連ディレクトリメンバ情報を取得
する。関連するディクショナリメンバが存在しなくなっ
た後、ディレクトリメンバ情報テーブルが存在するかど
うか調べ、存在しない場合（２００８）、デイクシヨナ
リの削除（２０１２以下）の処理を行う。テーブルが存
在する場合（２００Ｂ）、ディクショナリ削除要求のオ
プション指定が関連ディレクトリメンバを削除するもの
であれば（２００９）　、関連ディレクトリメンバを削
除する（　２０１０　）と共にデイクシヨナリを削除（
２０１２）Ｌ、オプション指定が関連ブイレフ）　Ｉ］
メンバが存在する場合削除不可というものであれば（２
００９）、エラー処理を行い（２０１１）デイクシヨナ
リ、ディレクトリ共に削除は行わない。

ディクショナリ削除においては、一括操作の指定をせず
にデイクシヨナリだけを削除する機能と一括操作の指定
をし、さらに関連ディレクトリが存在する場合ディクシ
ョナリと共にディレクトリを削除するという指定を行う
こともできる。関連ディレクトリが存在する場合ディク
ショナリの削除を禁止することによりデイクシヨナリと
ディレクトリの間を矛盾なく保つ機能が実現できる。

ディレクトリ削除処理におけるディクシ田ナリディレク
トリ一括操作について第１９図の７０−チャートに基づ
き、より詳１１１１に説明する。

ディレクトリ削除の要求により、まず削除しようとする
ディレクトリメンバの検索を行う（２１０１）０デイレ
クトリメンバが存在しない場合（２１０２）は処理を終
了し、ディレクトリメンバが存在する場合は（２１０２
）、ディレクトリ中にある、ディレクトリ生成用ディク
ショナ１１　メ＞　ハチ−プルを検索する（　２１０３
　）。次に、このテーブルをもとにディクショナリメン
バを検索しく２１０４）、ディクショナリ中のブイレフ
）’ｌＥＩ＆用ディクショナリメンバテーブルを削除（
２１０５）した後、ブイレフ）　ＩＪの削除（２１０（
５）を行う。

これにより、ディレクトリ生成時に作成したｌ１ｊＩ歴
情報の削除が実現できる。

以上の一括処理について、サブスキーマ、スキーマ分用
いさらに詳しく説明する。

サブスキーマとスキーマの定義情報から生成されるディ
レクトリの例を第５図に示す。この図において、のスキ
ーマ名称はスキーマ定義情報から得られるもの、のサブ
スキーマ名称はサブスキーマの定義情報から得られるも
のである。

このブイレフ）　＋１を生成する場合、指定する名称は
サブスキーマ名称であり、第３図に例示するような構造
を持つディクショナリメンバでは、２１のサブスキーマ
情報にその情報が格納されている、ディレクトリ生成の
処理においては生成要求のあったサブスキーマ名称を持
ツディクショナリメンバを検索し、まずそのディクショ
ナリ種別（サブスキーマ）と名称、ディクシ目ナリメン
バを一意に定めるための情報たとえば作成日付を第２０
図に示すようなディレクトリ生成用ディクショナリメン
バテーフルにセットする。次に、ディレクトリ生成に必
要なス　　　゛キーマ定義情報を得るために、第４図で
示すようなサブスキーマメンバ中に持つ関連メンバ情報
からスキーマに関するものを取り川し、スキーマのディ
クショナリメンバを検索する。これにより得られたスキ
ーマの情報もディレクトリ生成用ディクショナリメンバ
テーブルにセットする。このようにして関連するメンバ
の検索が終了した後第２１図で示すディレクトリ中のデ
ィレクトリ生成用ディクショナリメンバ情報テーブルの
内容と今、生成したテーブルの内容とを比較し、同一の
場合はディレクトリ生成を行わず、違っている場合第５
図の形式で新たなディレクトリメンバを作成する。一方
サブスキーマのディクシコナリメンバ中にも第２２図の
ようなディレクトリ生成用ディクショナリメンバテーブ
ルを格納する。

サブスキーマのディクショナリメンバを削除する際一括
操作を行う場合例えば ＊ＤＥＬＥＴＥ　　ＤＩＣＴＩＯＮＡＲＹＬＩＮＫＥＤ
　　ＦＯＲＣＥ ＳＵＢＳＣＨＥＭＡ　　サブスキーマ名称と指定する。

ＬＩＮＫＥＤは一括操作を行うという削除のオプション
指定で１１”０ＲＣＥは関連するディレクトリが存在す
る場合、ディクショナリと共にディレクトリも削除する
というオプション指定である。

この削除要求に対して削除しようとするサブスキーマの
ディクショナリメンバをまず検索する。検索したサブス
キーマの情報をもとにブイレフ）　ＩＪ生成が行われて
いれば上述の通りディレクトリ生成用ディクショナリメ
ンバテーブルが存在するためこのテーブルが存在するか
どうか検索し、存在すれば第２２図のようなディレクト
リメンバ情報テーブルを生成する。

次に関連するスキーマのディクショナリメンバを検索し
そのメンバ中にディレクトリ生成用ディクショナリメン
バテーブルが存在していないかどうか調べ削、＠シよう
とするサブスキーマの定義情報を使用して生成したディ
レクトリ用のものがあればディレクトリメンバ情報テー
ブルにたとえばそのディレクトリ種別、スキーマ名称日
付情報をセットする。同様にして関連するディクショナ
リメンバの検索を行った後、関連するディレクトリが存
在するかどうかディレクトリメンバ情報テーブルにより
調べ、存在すればオプションのＦＯＲＣＥ指定に従い、
ディレクトリを削除すると共にディクショナリヲ削除す
る。

サブスキーマのディレクトリを削除する場合、第２３図
における２で示されるディレクトリ中のディレクトリ生
成用ディクショナリメンバテーブルから当該ディレクト
リと同一のテーブルをディクショナリ中に持つサブスキ
ーマのディクショナリメンバの情報を取得し、これをも
とにディクショナリを検索し、サブスキーマディクショ
ナリメンバ中のディレクトリ生成用ディクショナリメン
バテーブルを削除するト共にサブスキーマディレクトリ
メンバの削除を行う。

〔発明の効果〕 本発明によれば、データディクンヨナリ・ディレクトリ
システムの運用において、関連する定義情報を操作時の
定義情報の履歴を使って、関連性分チェックするので、
ディクショナリとブイレフ）　＋１の定義情報間の整合
性をくずす利用者の誤った操作を防止することができ、
また、整合性を維持するために必要な一連の操作を一括
操作としτ指定することができる。これにより、データ
ディクショナリ・ディレクトリシステムを用いたンステ
ム開発・運用・保守における操作性と効率を向上できる
効果がある。

【図面の簡単な説明】

第１図は本発明の一実施例のハードウェア構成図、第２
図はスキーマの定義情報をディクショナリで管理する場
合、そのデータ構造を例示した図、第６図はサブスキー
マ定義情報をディクショナリで管理する場合、そのデー
タｊｉ４造を例示した図、第４図は世代番号をディクシ
ョナリで管理する場合、そのデータ構造を例示した図、
第≠図は第２図、第３図のデータを用いて生成したディ
レクトリのデータ構造を例示した図、第６図は定義操作
プログラムの全体処理概要を例示した図、第７図は第６
図におけるディクショナリ登録処理を例示した図、第８
図は第６図における整合性チェック処理を例示した図、
第９図は第８図の整合性チェック処理をサブスキーマ定
義の場合を例に詳細に例示した図、第１０図は第６図の
ブイレフ）　＋１生成処理を例示した図、第１１図は第
１０図のディレクトリ生成処理における整合性チェック
済か否かの判定ルーチンを例示した図、第１２図は第６
図のディクショナリ削除処理を例示した図、第１３図は
第６図のディレクトリ削除処理を例示した図、第１４図
はディクショナリに登録された各メンバ間の論理的な関
係を例示した図、第１５図は第１４図に基く整合性チェ
ック処理を例示した図、第１６図は本発明の一実施例で
ある誤操作防止処理分ディクショナリ削除処理について
例示した図、第１７図は本発明の一実施例である一括操
作処理をブイレフ）　＋１生成について例示した文、第
１８図は本発明の一実施例である一括処理をディクンヨ
ナリ削除について例示した図、第１９図は本発明の一実
施例である一括処理をブイレフ）　＋１削除について例
示した図、第第２０図はディレクトリ生成用ディクンヨ
ナリメンバテーブル、第２１　ｕはディレクトリメンバ
、第２２図はブイレフ）　＋１メンバ情報テーブルであ
る。 第２０図において１はディレクトリ生成用ディクショナ
リメンバテーブルの１つのエントリを表しており、その
構成はたとえばデイクンヨナリ種別、ディクショナリメ
ンバ名称、日付ｆｆ報といったディクショナリメンバを
一意に示す情報の集まりである。 第２１図はディレクトリメンバを表している。 ディレクトリメンバは、１ディレクトリ管理部分、２デ
イレクトリ中のブイレフ）　＋１生成用デイクシヨナリ
メンバテーブル、３ディレクトリ本体の３つの部分から
構造される。 第２２図において１はブイレフ）　＋１メンバ情報テー
ブルの１つのエントリを表しており、その構成は、たと
えばディレクトリ種別、ディレクトリメンバ名称、日付
情報といったディレクトリメンバを一意に示す情報の集
まりである。 １・・・プロセッサ、２・・・定義情報格納メモリ、３
・・・ディクショナリファイル格納メモリ、４・・・デ
ィレクトリファイル格納メモリ、５・・・定義操作プロ
グラム格納メモリ、６・・・ワークエリア。 ・“べ 、″ ２゜ 代理人弁理士　小　　川　　勝　　実 射　２０ 第　３０ 第　５図 躬　６区 第　７　国 躬　８０ も１０工 躬　ｕ　Ｉｆｌ 占 躬　１４圀 箔　ｒ５刀 括　７６０ 馬　ｌ”ｌ　η 第１８図

Claims (1)

1. 【特許請求の範囲】 １、データベースにおけるデータディクショナリ・ディ
   レクトリシステムにおいて、 ディクショナリとディレクトリ双方に対する操作時の定
   義情報の履歴をデータディクショナリ・ディレクトリシ
   ステム内に保持し、定義情報の履歴を使って、関連する
   定義情報を関係付けて操作することを特徴とするデータ
   ディクショナリ・ディレクトリの維持管理方式。