JPH0370048A

JPH0370048A - ディクショナリ創成方法

Info

Publication number: JPH0370048A
Application number: JP1206089A
Authority: JP
Inventors: Kazuaki Tanaka; 和明田中; Noriyuki Takahashi; 高橋　典幸; Toshio Akiba; 秋葉　俊夫
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 1989-08-09
Filing date: 1989-08-09
Publication date: 1991-03-26
Also published as: US5375237A

Abstract

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

Description

【発明の詳細な説明】〔産業上の利用分野〕本発明は、計算機システムを実現するプログラムプロダ
クトの実行方法を規定する定義データを管理する管理シ
ステムに係り、特に、計算機システムに関連する全ての
定義データを一元管理するディクシヨナリの創成方法に
関するものである。

〔従来の技術〕

計算機システムを構成するプログラムプロダクト（メー
カやソフトウェアハウス等から供給されるソフトウェア
の総称であり、その代表的なものとしては、例えば、オ
ペレーティングシステムやデータベース管理システムが
ある。）は、一般に、その利用方法に柔軟性を持たせる
ために、利用者が指定した実行方法に関する定義データ
に基づき動作するソフト構造となっている。そのため、
各プログラムプロダクトには、それぞれに対応した定義
データが付随している。

計算機システムは、処理すべきそれぞれのプログラムプ
ロダクト（ソフトウェア）にそれぞれ対応する定義デー
タに基づき、処理を行う。そのため、使用されるプログ
ラムプロダクトの定義データの管理機能、すなわち、デ
ータが定義されたことの登録、参照（どのプログラムが
どのデータを使っているかなどの問い合わせ回答）、抹
消を行う機能が必要であり、その機能を実現するデータ
管理システムとしてディクシヨナリシステムがある。

現在、計算機システムで取り扱う情報の増大と多様化に
より、データ管理システムを強化し、これら、膨大な定
義データ間の因果関係を正確に把握し、システムの拡張
、構成変更等に十分対応ができるディクシヨナリシステ
ムの実現が必要となってきている。

従来の技術において、その定義データの管理システムは
、各プログラムプロダクトにそれぞれ対応して供給され
ているか、あるいは、例えば、（株）日立製作所ＨＩＴ
ＡＣプログラムプロダクトＶＯ３３データマネージメン
トシステムＸＤＭの解説８０９０−６−６０２−３０第
９頁から第１８頁に記載のごとく、いくつかの関連のあ
るプログラムプロダクトに共通な仕掛けとして供給され
ていた。

一方、定義データの管理方法に関しては、情報処理学会
誌Ｖｏ１．２９．Ｎｏ、３（！９８８年）第２１５頁か
ら第２２４頁において論じられているように、国際標準
化機＠　（Ｉ　ｎｔｅｒｎａｔｉｏｎａｌ　　Ｏｒｇａ
ｎｉｚａｔｉｏｎ　　ｆｏｒ　　Ｓ　ｔａｎｄａｒｄｉ
ｚａｔｉｏｎ（以下ＩＳＯと略記））において、データ
ディクシヨナリ（以下第１のディクシヨナリと記載）で
管理する定義データ（テーブル名、カラム名）と、その
属性、例えば、データ型（英数、漢字等）、データ長等
の制約条件等を定義したデータ（以下構造定義データと
記載）を登録・管理するディクシヨナリ（以下第２のデ
ィクシヨナリと記載）に関する国際規格化作業が進めら
れている。そこでは、第２のディクシヨナリに構造定義
データを登録し、それに基づき第１のディクシヨナリを
創成、管理することで、ディクシヨナリとして管理する
定義データの種類等を適宜拡張できる定義データの柔軟
な管理方法が検討されている。

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

従来のプログラムプロダクトにおける定義データの管理
システムは、各プログラムプロダクトに対応して、ある
いは、関連のあるプログラムプロダクトに対応して、い
くつかの定義データの管理システムが存在すると、それ
らのシステム間で、同一定義データを重複して登録する
必要があったり、同一定義データ間の整合性をとって運
用する手間がかかるといった問題があった。

また、ＩＳＯの情報資源辞書システム（Ｉ　ｎｆｏｒｍ
ａｔｌｏｎ　　Ｒｅ５ｏｕｒｃｅ　　Ｄｉｃｔｉｏｎａ
ｒｙ　　Ｓｙｓｔｅｍ　（以下ＩＲＤＳと略記））は、
計算機システムの定義データの一元管理を目的として、
第２のディクシヨナリや第１のディクシヨナリの構造を
表現するモデルと、それぞれへのサービスプロトコルの
使用を規格化しているものであり、第１のディクシヨナ
リにより管理する定義データの種類や、第２のディクシ
ヨナリにより管理する構造定義データの内容、あるいは
、それをどこから持ってくるのかは実現者が決める問題
である。

例えば、計算機システムに対するすべての定義データを
第１のディクシヨナリにより一元管理することを実現す
るためには、計算機システムを構成するプログラムプロ
ダクトの実行に必要な定義データに関する構造定義デー
タを第２のディクシヨナリに登録する必要がある。この
プログラムプロダクトの実行に必要な定義データは、プ
ログラムプロダクトの持つ機能に依存しており一様でな
い。例えば、データベース管理システムも、その提供者
により、実行に必要な定義データの種類に差がある。ま
た、同一提供者のものでも、バージョンやりビジョンに
よって、定義データの種類が異なる場合もある。

さらに、計算機システムを構成するプログラムプロダク
トの種類や数は、その計算機システムにより実現される
業務内容により異なる。

また、従来、定義データの管理システムは、管理処理を
行うプログラムに加え、データディクシヨナリ（本明細
書における第１のディクシヨナリ）と呼ばれる定義デー
タの管理簿をデータベースとして実現されるため、その
データベースの構造定義データを一緒にしてメーカ等か
ら提供されていた。

上記例のように、計算機システムに対する全ての定義デ
ータを、ディクシヨナリにより一元管理することを実現
するためには、計算機システムのプログラムプロダクト
構成に合わせて、その構造定義データの管理システムを
メーカは提供する必要があった。これは、メーカにとっ
て不都合であるばかりでなく、業務内容により、計算機
システムのプログラムプロダクト構成を変えたり、同一
マルチベンダによるプログラムプロダクト構成をとる利
用者にとっても不都合である。

また、モニタデータや、記憶媒体の所在、用途管理デー
タといった運用データの管理システムは、定義データの
管理システムとは別に、個別に実現されており、定義デ
ータと運用管理データとを関連付けて一元管理すること
ができなかった。

本発明の目的は、これら従来技術の課題を解決し、プロ
グラムプロダクトの多様な組み合わせで実現される計算
機システムの定義データや運用データを第１のディクシ
ヨナリで一元管理することを可能とし、定義データの登
録の重複と定義データ間の整合性を管理する手間を省き
、効率の良い定義データの管理システムを実現できるデ
ィクシヨナリ創威方法を提供することである。

［課題を解決するための手段］上記目的を達成するため、本発明のディクシヨナリ創成
方法は、（１）データベース管理システムに代表される
プログラムプロダクト群、このプログラムプロダクト群
の各々の実行に必要な定義データを登録し管理する第１
のディクシヨナリ、および、この第１のディクシヨナリ
の構造定義データを記憶し管理する第２のディクシヨナ
リを有する計算機システムにおいて、オペレーティング
システムおよびシステム開発支援ツールを含むプログラ
ムプロダクト群各々には、あらかじめ、このプログラム
プロダクト群各々の実行に必要な運用データを含む全定
義データに関する構造定義データが付加され、計算機シ
ステムは、この付加された構造定義データを記憶し、第
１のディクシヨナリの創成要求に応答して、プログラム
プロダクト群が有する構造定義データに基づき第１のデ
ィクシヨナリを創成することを特徴とする。また、（２
）上記（１）に記載の各プログラムプロダクト群の各々
に施された全定義データに関する構造定義データを、プ
ログラムプロダクト群の各々のマスタテープに格納し、
第１のディクシヨナリの創成要求に応答し、各々のマス
タテープから構造定義データを読み込むことを特徴とす
る。また、（３）上記（１）に記載の各プログラムプロ
ダクト群の各々に施された全定義データに関する構造定
義データを、お互いに関連する各プログラムプロダクト
群の内の１つのプログラムプロダクトのマスタテープに
まとめて格納し、第１のディクシヨナリの創成要求に応
答して、構造定義データをまとめて格納しているマスク
テープから構造定義データを読み込むことを特徴とする
。また、（４）上記（１）（こ記載の第１のディクシヨ
ナリの創成要求は、少なくとも、構造定義データを有す
るプログラムプロダクトを特定する名前と、プログラム
プロダクト群を特定する名前とから構成されることを特
徴とする。また、（５）上記（１）に記載の第Ｉのディ
クシヨナリの創成要求に応答し、各プログラムプロダク
ト群における共通な構造定義データの重複を排除して、
第１のディクシヨナリを創成することを特徴とする。ま
た、（６）上記（１）に記載のプログラムプロダクト群
への新たなプログラムプロダクトの追加に伴う第１のデ
ィクシヨナリの拡張要求に応答して、この追加されるプ
ログラムプロダクトの構造定義データから、既存の構造
定義データの重複部分を排除して、第１のディクシヨナ
リを拡張することを特徴とする。そして、（７）上記（
１）に記載のプログラムプロダクト群の既存のプログラ
ムプロダクトの削除に伴う第１のディクシヨナリの縮小
要求に応答して、この削除要求されたプログラムプロダ
クトの構造定義データであり、かつ、削除要求されてい
ないプログラムプロダクトの構造定義データと重複しな
い構造定義データのみを削除して、第１のディクシヨナ
リを縮小することを特徴とする。

〔作用〕

本発明においては、各プログラムプロダクトは、その実
行内容を規定する定義データや運用データ（以下、説明
を簡略化するため両者をまとめて定義データと記載する
）を定義した構造定義データも合わせて、プログラムプ
ロダクトの提供者より提供される。この構造定義データ
は、各定義データに対し、その定義データを登録する第
１のディクシヨナリ内のテーブル名、カラム名、世代識
別子（バージョン等）、データ型（英語、数字、漢字等
）、制約条件（データの長さ等）、省略時解釈データ等
から構成される。その構造定義データの提供方法は、従
来通り、マスタテープ等によるものに限らず、各プログ
ラムプロダクトの構造定義データであることが分かる提
供方法であれば、プログラムプロダクトとは別に、例え
ば、他の磁気ディスクや磁気テープで提供されても良い
。いずれかの方法によって入力されたプログラムプロダ
クトの構造定義データを、まずテーブル名とカラム名と
に基づき、その次に、世代識別子、データ型の順序で重
複をチエツクし、もし重複があれば条件に基づき排除し
、統合する。

統合された構造定義データから、テーブル名が同じもの
を−まとめにして、さらに、各第１のディクシヨナリの
実現に使用されている記述言語を用いて、第１のディク
シヨナリを創成する定義データを自動生成し、この自動
生成された定義データに基づき、データベース管理シス
テムを介して、第１のディクシヨナリを創成する。

上記構造定義データは、各プログラムプロダクトのマス
クテープにそれぞれ別々に格納されていても良い。また
、幾つかの関連するプログラムプロダクトが、まとめら
れ、いわゆる統合出荷をされる場合には、それら幾つか
の関連するプログラムプロダクトの内の１つに、まとめ
て構造定義データを格納されていても良い。この場合に
は、第１のディクシヨナリを創成する時に、まとめて構
造定義データを格納したマスタテープから構造定義デー
タを読み込む。

実際に第１のディクシヨナリを創成する時には、対象と
なるプログラムプロダクト名とこのプログラムプロダク
トを含むプログラムプロダクト群名（このプログラムプ
ロダクトにより実行される計算機システム名）を指定し
て第１のディクシヨナリの創成要求を行う。

さらに、第１のディクシヨナリを創成する時には、重複
する構造定義データは排除される。

また、プログラムプロダクトの追加に伴い、第１のディ
クシヨナリを拡張する時には、既存の第１のディクシヨ
ナリの構造定義データと重複する追加プログラムプロダ
クトの構造定義データ部分を排除して、第１のディクシ
ヨナリを拡張する。

そして、プログラムプロダクトの削除に伴い、第１のデ
ィクシヨナリを縮小する時には、この削除要求されたプ
ログラムプロダクトの構造定義データであり、かつ、削
除要求されていないプログラムプロダクトの構造定義デ
ータと重複しない構造定義データのみを削除して、第１
のディクシヨナリを縮小する。

〔実施例〕

以下、本発明の動作原理を説明する。

本発明において、第１のディクシヨナリを管理する計算
機システム（以下管理計算機システムと記載）は、次の
ように作用することで、プログラムプロダクト構成にあ
わせた第１のディクシヨナリを創成できる。

（Ｔ）（１）各プログラムプロダクトの提供者は、その
プログラム類に加えて、そのプログラムプロダクトの実
行内容を規定する定義データや運用データを定義した構
造定義データも提供する。

これらは、従来プログラムプロダクトがそのメーカ等か
ら提供されていたとおり、マスタテープと呼ばれる記憶
媒体を用いて提供される。

尚、各プログラムプロダクトの構造定義データであるこ
とが分かる提供方法であれば、プログラムプロダクトと
は別のマスタテープで、個々にあるいはまとめて提供さ
れても良いし、関連する幾つかのプログラムプロダクト
をまとめ、いわゆる統合出荷される場合には、各々のプ
ログラムプロダクトの構造定義データを、統合出荷され
る内の１つのプログラムプロダクトに代表させて提供す
る方法でも良い。

構造定義データは、各定義データに対し、その定義デー
タを登録するテーブル名、カラム名、世代識別子（バー
ジョン）、および、データ型（英語、数値、漢字等）、
制約条件（データ長等）、省略時解釈データ等の属性か
ら構成される。

（２）計算機システムを構成するプログラムプロダクト
のマスタテープから、磁気テープ装置等を介し、この構
造定義データを管理計算機システムの主記憶装置に入力
する。

（３）（２）で入力した構造定義データのうち、テーブ
ル名とカラム名の組み合わせが同じものについて、次の
ようにして、重複して登録されることを排除し、統合化
する。

（ａ）世代識別子も一致していれば、一方を排除する。

（ｂ）世代識別子が不一致で、かつ、カラムの長さだけ
が不一致ならば、長い方に合わせる。

（ｃ）世代識別子が不一致で、かつ、制約条件だけが不
一致ならば、制約条件を緩和する。

（ｄ）これら（ａ　）、　（ｂ　）、　（ｃ　）のどれ
にも該当しなければ、新世代の方を残す。

（４）このようにして統合された構造定義データから、
テーブル名が同じものを−まとめにする。

（５）上記（４）に基づき、データ記述言語（Ｄａｔａ
Ｄｅｆｉｎｉｔｉｏｎ　　Ｌａｎｇｕａｇｅ、あるいは
、Ｄ　ａｔａＤｅｓｃｒｉｐｔｉｏｎ　　Ｌａｎｇｕａ
ｇｅ（以下ＤＤＬと記載））、もしくは、関係型（リレ
ーショナル）データベース記述言語のスキーマ定義言語
を用いて、第１のディクシヨナリを創成する定義データ
を自動生成する。

例えば、ＩＳＯで規格化されたネットワーク型データベ
ースの問い合わせ言語の１つであるＮＤＬ（Ｎｅｔｗｏ
ｒｋ　　Ｄａｔａｂａｓｅ　　Ｌａｎｇｕａｇｅ）に準
拠したデータベースであれば、上記（４）の各テーブル
を１つの＜ｒｅｃｏｒｄ　　ｔｙｐｅ）とする定義デー
タが生成される。

同様に、Ｉｓ○で規格化された関係型（リレーショナル
）データベース記述言語の５ＱＬ２（Ｓｔｒｕｃｔｕｒ
ｅｄ　　Ｑｕｅｒｙ　　Ｌａｎｇｕａｇｅ２（に準拠し
たデータベースであれば、（４）の各テーブルを１つの
（ｔａｂｌｅ　　ｄｅｆｉｎｉｔｉｏｎ）とする定義デ
ータが生成される。

（６）第１のディクシヨナリを創成する定義データをデ
ータベース管理システムへ送り、第１のディクシヨナリ
を創成する。

（ＩＩ）また、上記（Ｉ）の（２）において、次のよう
に作用させることで、構造定義データを毎回各プログラ
ムプロダクトのマスタテープから磁気テープ装置を介し
て読み込むのではなく、管理計算システム内の第２のデ
ィクシヨナリから読み込むことで、オペレーションを容
易にできる。

（１）各プログラムプロダクトのマスタテープ内の構造
定義データを、プログラムプロダクトの識別子をキーと
して、第２のディクシヨナリに登録する。

（２）プログラムプロダクトの識別子を指定した計算機
システムの構成が利用者から入力されたことに応答して
、第２のディクシヨナリから構造定義データを検索する
。

（３）以下、（１）の（３）以降と同じ。

（ＩＩＩ）さらに、次のように作用させることにより、
既存の第１のディクシヨナリで管理できるプログラムプ
ロダクトの定義データの種類を増やすための第１のディ
クシヨナリ構造の拡張ができる。それゆえ、計算機シス
テムの構成要素となるプログラムプロダクトが増える度
に、第１のディクシヨナリを再創成する必要が無くなる
。

（１）計算機システムを構成するプログラムプロダクト
の識別子と、その計算機システム名とが利用者から入力
されたことに応答して、第２のディクシヨナリ内の各構
造定義データに、その使用先を示すデータとして計算機
システム名を付加する。

第１のディクシヨナリの創成方法は、（ＩＩ）と同じで
ある。

（２）計算機システム名と、その計算機システムに追加
するプログラムプロダクトの識別子とを指定した利用者
からの第１のディクシヨナリの拡張要求に応答して、こ
の計算機システムを構成するプログラムプロダクトと追
加される新プログラムプロダクトとの構造定義データを
第２のディクシヨナリから検索する。

（３）既存計算機システムを構成するプログラムプロダ
クトの構造定義データについて、上記（Ｉ）の（３）に
おける排除を行い、統合化を行う。

（４）追加される新プログラムプロダクトの構造定義デ
ータについて、（３）で統合化された構造定義データと
比較し、テーブル名とカラム名の組み合わせが同じもの
は、さらに、次のとおり、重複を排除し、統合する。

（ａ）世代識別子も一致していれば排除する。

（ｂ）世代識別子が不一致で、がっ、カラムの長さが短
いだけであれば排除する。

（ｃ）世代識別子が不一致で、かつ、制約条件が緩和さ
れるだけならば排除する。

（５）（４）で統合された構造定義データから、テーブ
ル名が同じものを−まとめにする。

尚、テーブル名とカラム名が同じものが存在するならば
、新規追加プログラムプロダクトのものを採用する。ま
た、追加されるプログラムプロダクトが複数あり、その
中でテーブル名とカラム名が同じものが存在するならば
、新世代の方を採用する。

（６）上記（５）に基づき、（１）の（５）と同様に、
第１のディクシヨナリが実現されるデータベースのＤＤ
Ｌ、あるいは、スキーマ操作言語を用いて、第１のディ
クシヨナリの構造を拡張する定義データを自動生成する
。

（７）第１のディクシヨナリを拡張する定義データをデ
ータベース管理システムへ送り、第１のディクシヨナリ
を拡張する。

尚、この拡張において、第１のディクシヨナリ内の定義
データを、−旦、他の記憶媒体へ退避し、第１のディク
シヨナリを自動的に創成後、そこへ定義データを戻す、
いわゆる再構成を伴う拡張方法と、定義データの退避を
伴わない拡張方法とは、データベース管理システムが持
つ基本的な操作機能により、使い分けられるものである
。

（ＩＶ）さらに、次のように作用させることで、既存の
第１のディクシヨナリにより管理対象する定義データの
種類を減じるために、第１のディクシヨナリ構造を縮小
できる。そのため、計算機システムの構成要素となって
いたプログラムプロダクトの使用をやめることで、第１
のディクシヨナリを再創成する必要が無くなる。

（１）計算機システム名と、その計算機システムから削
除する新プログラムプロダクトの識別子とを指定した利
用者からの第１のディクシヨナリの縮小要求に応答して
、この計算機システムを構成するプログラムプロダクト
の構造定義データを第２のディクシヨナリから検索する
。

（２）削除するプログラムプロダクトの構造定義データ
を除いた、この計算機システムを構成するプログラムプ
ロダクトの構造定義データについて、前記（Ｉ）の（３
）における統合化を行う。

（３）上記（２）で統合化された構造定義データと削除
される新プログラムプロダクトの構造定義データとを比
較し、テーブル名とカラム名の組み合わせが、新プログ
ラムプロダクトの構造定義データにあって、統合化され
た構造定義データに無いものだけを抽出する。

（４）上記（２）で統合化された構造定義データについ
て、削除される新プログラムプロダクトの構造定義デー
タとを比較し、テーブル名とカラム名の組み合わせが両
方にあるものを抽出する。

次に、その中で、次の条件を満たすものを抽出する。

（ａ）削除される構造定義データのカラムの長さが短い
だけである。

（、ｂ　）削除される構造定義データの制約条件が厳し
いだけである。

（５）上記（３）で抽出された構造定義データに基づき
、前記（Ｉ）の（５）と同様に、第１のディクシヨナリ
が実現されるデータベースのＤＤＬあるいはスキーマ操
作言語を用いて、第１のディクシヨナリの構造を縮小す
る定義データを自動生成する。

（６）上記（４）で抽出された構造定義データに基づき
、前記（１）の（５）と同様に、第１のディクシヨナリ
が実現されるデータベースのＤＤＬあるいはスキーマ操
作言語を用いて、第１のディクシヨナリの構造を変更す
る定義データを自動生成する。

（７）（５）および（６）で自動生成された第１のディ
クシヨナリの縮小、変更定義データをデータベース管理
システムへ送り、第１のディクシヨナリの構造を縮小、
変更する。

尚、この縮小、変更において、第１のディクシヨナリ内
の定義データを、−旦、他の記憶媒体へ退避し、第１の
ディクシヨナリを自動的に創成後、そこへ定義データを
戻す、いわゆる再構成を伴う拡張方法と、定義データの
退避を伴わない拡張方法とは、データベース管理システ
ムが基本的に持つデータ操作機能により使い分けられる
。

以上のような作用により、計算機システムのプログラム
プロダクト構成に合わせた第１のディクシヨナリを創成
でき、業務内容により多様なプログラムプロダクト構成
をとる計算機システムの全定義データや運用データを一
元管理できる。

これにより、プログラムプロダクト別に重複して登録し
た定義データの整合性を管理するための手間が省ける。

さらに、定義データと運用データとを関連付けた管理が
できる。

次に、本発明の実施例を、図面により詳細に説明する。

第１図は本発明を施した計算機システムの全体の構成を
示すブロック図である。

システム全体の制御を行う中央処理装置（Ｃｅｎｔｒａ
ｌ　　Ｐｒｏｃｅｓｓｉｎｇ　　Ｕｎｉｔ、以下ＣＰＵ
と略記）ｌ、各プログラムを格納する主記憶装置３、プ
ログラムプロダクトの供給媒体であるマスタテープ群９
、構造定義データを登録・管理する第２のディクシヨナ
リ１１、定義データを登録・管理する第１のディクシヨ
ナリ１５、利用者からの要求を入力する端末装置１９よ
り構成される。

主記憶装置３上には、下記のものが格納されている。

第１のディクシヨナリ創成モジュール５Ａと第１のディ
クシヨナリ拡張モジュール５Ｂ、および、第１のディク
シヨナリ縮小モジュール５０等の第１のディクシヨナリ
の創成、拡張、および、縮小設定（インストール）要求
を処理するプログラムが含まれている定義データ管理シ
ステム５、データベースの全般を統括的に管理するプロ
グラムで、データベースの定義、生成、再編成、操作等
の管理機能を持つデータベース管理システム７、そして
、テーブル識別子２１Ａ、カラム識別子２１Ｂ、世代識
別子２１Ｃ，属性２１Ｄ等から構成され、構造定義デー
タを設定するための作業領域（１）２１が設けられる。

同様に、構造定義データを設定するための、テーブル識
別子２３Ａ、カラム識別子２３Ｂ、世代識別子２３Ｃ１
属性２３Ｄ、更新フラグ２３Ｅから構成される作業領域
（２）２３が設けられる。

属性２１Ｄには、カラムの長さ、データ型、制約条件（
一意性制約、参照制約、空位制約、値の範囲制約等）、
省略時解釈値等がある。また、第１のディクシヨナリの
テーブル名やカラム名を１つの属性としても良い。

マスタテープ群９は、プログラムプロダクトの識別子９
Ａ、このプログラムプロダクトのロードモジュール類９
Ｂ、このプログラムプロダクトの実行方法を規定する定
義データ、実行状況のモニタデータや記憶媒体の所在・
用途管理等の運用データ（以下これらをまとめて定義デ
ータと記載する）の第１のディクシヨナリでの構造を定
義した構造定義データ９０等から構成される。これは、
各プログラムプロダクトのロードモジュール類と構造定
義データとが一体となって提供されることで、管理が容
易になるといる実用上のメリットがある。勿論、各プロ
グラムプロダクトの構造定義データは、上記プログラム
プロダクトと一緒に提供される方法でなくても、各プロ
グラムプロダクトの構造定義データであることが分かる
提供方法であればプログラムプロダクトとは別に、個々
にあるいは、まとめて提供されても良いし、幾つかのプ
ログラムプロダクトの構造定義データをあるプログラム
プロダクトに代表させて提供する方法でも良い。本実施
例では、説明を簡単にするため、マスクテープに格納さ
れるとして説明する。

第２のディクシヨナリ１１は、構造定義データを登録・
管理し、プログラムプロダクトに対応して管理された構
造定義データレコード群１３により構成される。このレ
コードはプログラムプロダクト識別子１３Ａと、構造定
義データ１３Ｂ、計算機システム名１３Ｃ等から構成さ
れる。尚、計算機システム名とは、各々のプログラムプ
ロダクトに対応して動作する各々のシステムのことであ
り、計算機システム名１３Ｃは、複数個設定できるよう
に実現されて良い。

第１のディクシヨナリ１５は、定義データを登録・管理
し、定義データテーブル群１７により構成され、さらに
、定義データテーブル群Ｉ７は、テーブル名１７Ａと、
カラム名１７Ｂ、各カラム名１７Ｂに対する定義データ
の値１７Ｃから構成される。定義データの値１７Ｃは、
複数個設定できるように実現される。

端末装置１９は、利用者からの要求を入力する手段とし
て、会話形式以外に、パッチジョブとして行う方法であ
っても良い。本実施例では、説明を簡素にする目的で、
会話形式で入力されるものとする。

さて、本計算機システムにおいて、定義データ管理シス
テム５に対する利用者の要求は、端末装置１９からコマ
ンド形式で与えられる。以下、本発明に関連したコマン
ドの構成を示す。

第１のディクシヨナリの創成コマンドの構成は、例えば
、￥ＣＲＥＡＴＥ［く計算機システム名〉］くプログラムプロダクト識別子〉０．。

ここで、￥ＣＲＥＡＴＥは、このコマンドが第１のディ
クシヨナリの創成要求であることを示す。

［く計算機システム名〉コは、第１のディクシヨナリに
付加された名前であり、その名前の第１のディクシヨナ
リで、くプログラムプロダクト識別子〉で特定されるプ
ログラムプロダクトの定義データを管理することを示す
。

プログラムプロダクトがバージョンやりビジョン等の世
代識別子を持つならば、くプログラムプロダクト識別子
〉は、くプログラムプロダクト名〉とく世代識別子〉と
から構成される実施例としても良い。以下の説明では、
簡素化のため、単にくプログラムプロダクト識別子〉と
記述する。

コマンド中の１１．は、くプログラムプロダクト識別子
〉が複数個指定されても良いこと示す。

［］は、く計算機システム名〉が省略できることを示す
。但し、省略した場合、定義データ管理システムが、他
のコマンドにおいて第１のディクシヨナリを特定できる
必要がある。例えば、第１のディクシヨナリがシステム
に１つしか存在しないという場合がある。以下の説明で
は、省略しない場合につき示す。

第１のディクシヨナリの拡張コマンドの構成は、例えば
、￥ＥＮＨＡＮＣＥ［く計算機システム名〉］くプログラムプロダクト識別子〉０．。

ここで、￥ＥＮＨＡＮＣＥは、このコマンドが第１のデ
ィクシヨナリの拡張要求であることを示す。く計算機シ
ステム名〉は、この名前を付加された第１のディクシヨ
ナリが拡張する第１のディクシヨナリであることを特定
し、くプログラムプロダクト識別子〉で特定されるプロ
グラムプロダクトの定義データを新たに管理することを
示す。

第１のディクシヨナリの削除コマンドの構成は、例えば
、￥ＤＲＯＰ［く計算機システム名〉］くプログラムプロダクト識別子〉２．。

ここで、￥ＤＲＯＰは、このコマンドが第１のディクシ
ヨナリの縮小要求であることを示す。く計算機システム
名〉は、縮小する第１のディクシヨナリを特定し、くプ
ログラムプロダクト識別子〉で特定されるプログラムプ
ロダクトの定義データの管理を今後しないことを示す。

定義データ管理システム５に対する各種要求の終了コマ
ンドの構成は、例えば、￥ＥＮＤここで、￥ＥＮＤは、このコマンドが第１のディクシヨ
ナリの創成、拡張、縮小等の利用者からの要求を終了す
ることを示す。このコマンドは、以下の定義データ管理
システムの処理を終了するきっかけを利用者からのコマ
ンドで与えるために設けたものであり、各コマンドごと
に処理を終了させる等の他の方法をとっても良い。

また、上記各コマンドの名称は、その意図が表現された
他の文字列でも良いし、それらが組み合わされたコマン
ド表現でも良い。

第２図は、定義データ管理システム５の処理概要を示す
フローチャートである。

本実施例の計算機システムが起動され、利用者からの要
求コマンドを入力すると（ステップ２５）、このコマン
ドが第１のディクシヨナリ創成コマンドか否かを判定す
る（ステップ２７）。第１のディクシヨナリ創成コマン
ドであれば、第１のディクシヨナリ創威モジュール５Ａ
（プログラム）を起動して、第１のディクシヨナリを創
成（ステップ２９）した後、ステップ２５以降を繰り返
す。ステップ２９の第１のディクシヨナリの創成動作は
後述する。

もし、ステップ２７で、第１のディクシヨナリ創威コマ
ンドでないと判断されれば、このコマンドが第１のディ
クシヨナリ拡張コマンドが否かを判定する（ステップ３
１）。拡張コマンドであれば、第１のディクシヨナリ拡
張モジュール５Ｂ（プログラム）を起動して、第１のデ
ィクシヨナリを拡張（ステップ３３）後、ステップ２５
以降を繰り返す６ステツプ３３の第１のディクシヨナリ
の拡張動作は後述する。

もし、ステップ３１で、拡張コマンドでなければ、この
コマンドが第１のディクシヨナリ縮小コマンドか否かを
判定する（ステップ３５）。縮小コマンドであれば、第
１のディクシヨナリ縮小モジコール５Ｇ（プログうム）
を起動して、第１のディクシヨナリを縮小（ステップ３
７）し、ステップ２５以降を繰り返す。ステップ３７の
第１のディクシヨナリの縮小動作は後述する。

もしステップ３５で、縮小コマンドでなければ、このコ
マンドがその他のコマンド（例えば、テーブル名変更等
）であるかを判定し、それに見合った処理を実行する。

第２図においては、その他のコマンドは省略し、終了コ
マンドの判定（ステップ３９）のみ説明する。

このコマンドが終了コマンドであれば、定義データ管理
システムの処理を終了する。終了コマンドでなければ、
未定義のコマンドであるとして、端末装置１９にエラー
メツセージを表示後、ステップ２５以降を繰り返す。

第３図は、第１のディクシヨナリ創成モジュールの処理
手順を示すフローチャートである。

第１のディクシヨナリ創成モジュールが起動されると、
第１のディクシヨナリ創成コマンドのオペランドである
計算機システム名とプログラムプロダクト識別子とを端
末装置１９から読み込む（ステップ４３）。尚、この場
合、創成コマンドと一緒に、第２図のステップ２５でま
とめて読み込む方法でも良く、以下、他のコマンドにつ
いても同様である。

次に、指定されたプログラムプロダクトの１つについて
、指定されたプログラムプロダクト識別子をキーとして
、第２のディクシヨナリ１１から、その構造定義データ
を検索し、作業領域（１）２１へ設定する（ステップ４
５）。検索できたか否かを判定しくステップ４７）、検
索できていれば、第２のディクシヨナリ内のこの構造定
義データに指定された計算機システム名を付加（ステッ
プ５１）した後、ステップ５７以降を実行する。もし、
検索できていなければ、このプログラムプロダクトが格
納されたマスタテープ９から構造定義データを読み込み
（ステップ４９）、カラム単位に分割し、作業領域＜１
）２１へ設定する（ステップ５３）。この構造定義デー
タに、指定された計算機システム名を付加し、第２のデ
ィクシヨナリへ登録する（ステップ５５）。指定された
全プログラムプロダクトについて、その構造定義データ
を作業領域（１）２１へ設定したかを判定（ステップ５
７）し、設定していなければ、ステップ４５以降を繰り
返す。もし、設定していれば、作業領域（１）２１の構
造定義データをテーブル識別子、カラム識別子、世代識
別子でソートしくステップ５９）、その後、テーブル識
別子とカラム識別子の組が同じ構造定義データを排除す
る（ステップ６１）、残った構造定義データ群を区別の
ため統合構造定義データと呼ぶ。

統合構造定義データに基づき、テーブル識別子が同じも
の毎に、第１のディクシヨナリを実現するデータベース
管理システム７が提供するスキーマ定義言語（Ｓｃｈｅ
ｍａ　　Ｄｅｆｉｎｔｔｉｏｎ　　Ｌａｎｇｕａｇｅ）
による第１のディクシヨナリを創成するスキーマ定義デ
ータを生成する（ステップ６３）。

例えば、ＩＳＯのＳ　Ｑ　Ｌ　（Ｓｔｒｕｃｔｕｒｅｄ
　　ＱｕｅｒｙＬ　ａｎｇｕａｇｅ　２　）に基づくデ
ータベースの場合、計算機システム名Ｓ１、　テーブル
名がテーブル識別子Ｔ１、カラム名がカラム識別子Ｃ１
とＣ２、各カラムのデータ型が共に文字列型、データ長
がそれぞれ４．８、その他の属性は無いものとすると、
ＣＲＥＡＴＥ　　ＳＣＨＥＭＡ　　Ｓ。

ＣＲＥＡＴＥ　　ＴＡＢＬＥ　　Ｔ（Ｃ，ＣＨＡＲ（４）。

Ｃ，ＣＨＡＲ（８））のようなスキーマ定義データを生成する。

尚、この例では、テーブル識別子を第１のディクシヨナ
リのテーブル名、カラム識別子を第１のディクシヨナリ
のカラム名としたが、テーブル名やカラム名も属性の１
つとする場合では、Ｔ　やＣ、Ｃ，として、その名前を
指定するものとする。

以下のコマンドでも同様とする。

このスキーマ定義データをデータベース管理システム７
へ送って実行させる（ステップ６５）ことで、第１のデ
ィクシヨナリ１５を創成できる。データ管理システム７
は、従来から存在するものであり、その処理についての
説明は省略する。

また、上記の例では、ＩＳＯの５ＱＬ２に基づいて説明
したが、Ｉｓ○のＮ　Ｄ　Ｌ　（Ｎｅｔｗｏｒｋ　　Ｄ
ａｔａｂａｓｅ　　Ｌ　ａｎｇｕａｇｅ）や、その他の
データベース定義、あるいは、操作言語に基づ〈実施方
法でも良い。要は、第１のディクシヨナリを実現するデ
ータベース管理システムの基本的な機能により、第１の
ディクシヨナリの創成、拡張、縮小を行うコマンドに変
換すれば良い。以下の説明でも同様である。

第４図は、第３図のステップ６１における重複構造定義
データの排除の手順を示すフローチャートである。

カウンタＮに作業領域（１）２１のエントリ数を設定す
る（ステップ６７）６カウンタエに１を設定する（ステ
ップ６９）。カウンタＪにカウンタ■に１を加算した値
を設定しくステップ７１）、作業領域（１）２１の第１
エントリのテーブル識別子とカラム識別子、および、第
Ｊエントリのテーブル識別子とカラム識別子とが一致し
ているかを判定する（ステップ７３）。一致していなけ
れば、ステップ８５以降を実行し、一致していれば、作
業領域（１）２１の第■エントリの世代識別子と第Ｊエ
ントリの世代識別子とが一致しているかを判定する（ス
テップ７５）。一致していれば、第Ｊエントリの構造定
義データを削除し、後続のエントリがあればエントリ番
号の小さい方へ１つづつシフトする（ステップ７７）。

カウンタＮの値を１減産しくステップ７９）、次に、カ
ウンタＮがカウンタＪより小さいかを判定する（ステッ
プ８１）。小さくない場合は、カウンタＪの値を１加算
（ステップ８３）後、ステップ７３以降を繰り返す。も
し小さければ、カウンタＮがカウンタ■より大きいこと
を判定しくステップ８５）、大きければ、カウンタ■に
１加算してステップ７１以降を繰り返す。

もし大きくない場合には、この処理を終了する。

さらに、ステップ７５において、作業領域（１）２１の
第１エントリの世代識別子と第Ｊエントリの世代識別子
とが一致していなければ、属性のうち、データ型は同じ
で、データ長だけが異なるかを判定しくステップ８９）
、データ長だけが異なれば、データ中の短い方のエント
リを削除し、後続のエントリがあればエントリ番号の小
さい方へ１つづつシフト（ステップ９１）した後、ステ
ップ７９以降を実行する。もしデータ型もデータ長も異
なれば、属性のうち、制約条件のみが異なるがを判定し
くステップ９３）、制約条件のみが異なる場合は、制約
条件の厳しい方のエントリを削除し、後続のエントリが
あればエントリ番号の小さい方へ１つづつシフト（ステ
ップ９５）した後、ステップ７９以降を実行する。もし
、制約条件以外も異なる場合は、世代識別子が旧世代を
示す方のエントリを削除し、後続のエントリがあればエ
ントリ番号の小さい方へ１つづつシフト（ステップ９７
）した後、ステップ７９以降を実行する。

尚、ステップ７５において、作業領域（１）２１の第■
エントリの世代識別子と第Ｊエントリの世代識別子とが
一致していなければ、無条件にステップ９７を実行する
方法でも良いし、端末装置１９を介して、利用者の指示
に従う方法でも良いし、ステップ８９やステップ９３で
、データ長が長く、かつ、制約条件が緩いものを選択し
たり、あるいは、そのように属性を合成する方法でも良
い。本質は、テーブル識別子とカラム識別子とが一致す
るものは、その一方だけを残す方法であれば良い。

第５図は、第１図の計算機システムにおける第１のディ
クシヨナリ拡張モジュールの処理の手順を示すフローチ
ャートである。

本モジュールが起動されると、第１のディクシヨナリ拡
張コマンドのオペランド（命令の対象）である計算機シ
ステム名と追加プログラムプロダクト識別子を端末装置
１９から読み込む（ステップ９９）。指定された計算機
システム名をキーとし、第２のディクシヨナリからこの
計算機システム名で特定されるプログラムプロダクトの
構造定義データを検索し、作業領域（１）２１へ設定す
る（ステップ１０１）。次に、指定された追加プログラ
ムプロダクト識別子をキーとして、第２のディクシヨナ
リから構造定義データを検索し、作業領域（２）２３へ
設定する（ステップ１０３）。検索できたかを判定して
（ステップ１０５）、検索できていれば、第２のディク
シヨナリ内のこの構造定義デ−夕に指定された計算機シ
ステム名を付加（ステップ１０９）した後、ステップ１
１５以下を実行する。ステップ１０５において、検索で
きていなければ、このプログラムプロダクトが格納され
たマスタテープ９から構造定義データを読み込み（ステ
ップ１０７）、カラム単位に分割して作業領域（２）２
３へ設定する（ステップ１１１）。この構造定義データ
に、指定された計算機システム名を付加して第２のディ
クシヨナリへ登録する（ステップ１１３）。指定された
全追加プログラムプロダクトについて、その構造定義デ
ータを作業領域（２）２３へ設定したかを判定しくステ
ップ１１５）、設定していなければ、ステップ１０３以
降を繰り返す。もし、設定していれば、作業領域（１）
２１の構造定義データをテーブル識別子、カラム識別子
、世代識別子でソートし、テーブル識別子とカラム識別
子の組が同じ構造定義データを排除する（ステップ１１
７）。これは、第１のディクシヨナリ創成時における、
ステップ５９とステップ６１の処理と同じである。残っ
た構造定義データ群を区別するため、既存続合構造定義
データと呼ぶ。

同様に、作業領域（２）２３の構造定義データをテーブ
ル識別子、カラム識別子、世代識別子でソートして、テ
ーブル識別子とカラム識別子の組が同じ構造定義データ
を排除する（ステップ１１９）。

残った構造定義データ群を区別するため、追加候補統合
構造定義データと呼ぶ。既存構造定義データと追加候補
統合構造定義データの中で、テーブル識別子とカラム識
別子とが同じものを追加候補統合構造定義データから排
除する（ステップ１２１）。残った追加候補統合構造定
義データを追加統合構造定義データと呼ぶ。この追加統
合構造定義データによる第１のディクシヨナリの拡張が
第１のディクシヨナリの再構成を必要とするかを判定す
る（ステップ１２３）。再編成が必要が否かは、データ
ベース管理システムの能力による。本実施例では、再構
成が必要な場合と、不要な場合とのいずれでも実現でき
るようにしており、その方法を以下で説明する。

ステップ１２３で、再構成を必要としないならば、追加
統合構造定義データから、スキーマ操作言語（Ｓｃｈｅ
ｎ＋ａ　　Ｍａｎｉｐｕｌａｔｉｏｎ　　Ｌａｎｇｕａ
ｇｅ）による第１のディクシヨナリ拡張するスキーマ操
作データを生成する（ステップ１２５）。このスキーマ
操作データを第１図のデータベース管理システム７へ送
って実行させる（ステップ１２７）ことで、第１のディ
クシヨナリ１５を拡張できる。

ステップ１２３で、再構成を必要とするならば、第１の
ディクシヨナリ内の定義データを退避する（ステップ１
２９）。退避場所は、図示されない磁気テープや磁気デ
ィスク等の外部記憶装置、あるいは、拡張記憶装置でも
良いし、第１図の主記憶装置３でも良い。追加統合構造
定義データを作業領域（１）２１へ追加し、ステップ１
１７と同様にソート後、重複した構造定義データを排除
して、スキーマ定義言語により第１のディクシヨナリを
創成するスキーマ定義データを生成する（ステップ１３
１）。それを第１図のデータベース管理システム７へ送
って実行させ、新たな第１のディクシヨナリを創成する
（ステップ１３３）。

尚、創成に先立ち、同一計算機システム名で特定される
第１のディクシヨナリを削除しておく。

次に、退避した定義データを新しい第１のディクシヨナ
リに再登録する（ステップ１３５）ことで、第１のディ
クシヨナリを拡張できる。

第６図は、第５図のステップ１２１での重複構造定義デ
ータの排除方法を示すフローチャートである。

カウンタＮ１に作業領域（１）２１のエントリ数を設定
する（ステップ１３７）。カウンタＮ２に作業領域（２
）２３のエントリ数を設定する（ステップ１３９）。カ
ウンタ■に１を設定する（ステップ１４１）。カウンタ
Ｊに１を設定する（ステップ１４３）。作業領域（１）
２１の第Ｔエントリのテーブル識別子とカラム識別子と
作業領域（２）２３第Ｊエントリのテーブル識別子とカ
ラム識別子とが一致しているか否かを判定する（ステッ
プ１４５）。一致していなければ、カウンタＮ２がカウ
ンタＪより大きいか否かを判定する（ステップ１４７）
。大きければ、カウンタＪに１加算（ステツブ１４９）
後、ステップ１４５以降を実施する。

カウンタＮ２がカウンタＪより小さいならば、ステップ
１５７以降を実施する。ステップ＋４５において、作業
領域（１）２１の第１エントリのテーブル識別子とカラ
ム識別子と作業領域（２）２３第Ｊエントリのテーブル
識別子とカラム識別子とが一致していれば、作業領域（
１）２１の第エニントリの世代識別子と作業領域（２）
２３の第エニントリの世代識別子とが一致しているか否
かを判定する（ステップ１５１）。一致していれば、第
エニントリの構造定義データを削除し、後続のエントリ
があればエントリ番号の小さい方へ１つづつシフトする
（ステップ１５３）。カウンタＮ２の値を１減算しくス
テップ１５５）、カウンタＮｌがカウンタＩより大きい
か否かを判定しくステップ１５７）、大きければ、カウ
ンタＴに１加算してステップ１４３以降を繰り返す。小
さければ、処理を終了する。ステップ１４７において、
カウンタＮ２がカウンタＪより小さければ、属性のうち
、データ型は同じでデータ長だけが異なるかを判定しく
ステップ１６１）、データ長だけが異なれば、作業領域
（２）２３の第エニントリの方がデータ長が長いか否か
を判定する（ステップ１６３）。第エニントリの方がデ
ータ長が長ければ、ステップ１７０以降を実施し、第エ
ニントリの方がデータ長が短ければ、ステップ１５３以
降を実施する。ステップ１６１で、データ長も同じであ
れば、属性のうち制約条件のみが異なるかを判定する（
ステップ１６５）。制約条件のみが異なれば、作業領域
（２）２３の第エニントリの方が制約条件が緩いか否か
を判定する（ステップ１６７）。第エニントリの方が制
約条件が緩ければ、ステップ１７０以降を実施し、第エ
ニントリの方が制約条件が厳しければ、ステップ１５３
以降を実施する。ステップ１６５において、制約条件が
同じであれば、作業領域（２）２３の第エニントリの世
代識別子が新世代を示すか否かを判定する（ステップ１
６９）。新世代を示していれば、作業領域（２）２３の
第エニントリの更新エントリ２３ＥにカウンタＩの値を
設定（ステップ１７１．）ｌ、た後、ステップ１５５以
降を実施する。ステップ１６９において、第エニントリ
の世代識別子が新世代を示していなければ、ステップ１
５３以降を実施する。

尚、ステップ１５１において、作業領域（１）２１の第
エニントリの世代識別子と作業領域（２）２３の第エニ
ントリの世代識別子とが一致していなければ、無条件に
ステップ１６９を実施するようにしても良いし、端末１
９を介して、利用者の指示に従う方法や、ステップ１６
１や１６５でデータ長が長く、かつ、制約条件が緩いも
のを選択したり、あるいは、そのように属性を合成する
方法でも良い。つまり、基本的には、テーブル識別子と
カラム識別子とが一致するものは、その一方だけを残す
方法であれば良い。

第７図は、第５図のステップ１２５での作業領域（２）
２３の追加統合構造定義データから第１のディクシヨナ
リを拡張するためのスキーマ操作データの生成方法を示
すフローチャートである。

カウンタＮｌに作業領域（１）２１のエントリ数を設定
する（ステップ１７３）。カウンタＮ２に作業領域（２
）２３のエントリ数を設定する（ステップ１７５）、カ
ウンタＪに１を設定する（ステップ１７７）、カウンタ
■にｌを設定する（ステップ１７９）、作業領域（２）
２３の第エニントリの更新エントリが初期値か否かを判
定する（ステップ１８１）。初期値で無ければ、作業領
域（１）２１の第エニントリの構造定義データによるカ
ラム削除のためのスキーマ操作データを生成する（ステ
ップ２０３）。

例えば、ＩＳＯの５ＱＬ２に基づくデータベースの場合
、テーブル名がテーブル識別子Ｔ１の既存のテーブルか
ら、カラム名がカラム識別子Ｃ１のカラムを削除する場
合、ＡＬＴＥＲＴＡＢＬＥ　　ＴＤＲＯＰ　　Ｃのようなスキーマ操作データを生成する。

そして、次に、作業領域（２）２３の第エニントリの構
造定義データによるカラムの新規追加のためのスキーマ
操作データを生成する（ステップ２０５）。

例えば、ＩＳＯの５ＱＬ２に基づくデータベースの場合
、テーブル名がテーブル識別子Ｔ１　のテーブルに、新
規に追加するカラムのカラム名がカラム識別子Ｃ＋　ｔ
　ｓカラムのデータ型が文字列型、データ長がそれぞれ
２、その他の属性は無いとすると。

ＡＬＴＥＲＴＡＢＬＥ　　Ｔ。

ＡＤＤ　（Ｃ，、ＣＨＡＲ（２））のようなスキーマ操作データを生成する。

その後、ステップ１９７以降を実施する。

ステップ１８１において、第エニントリの更新エントリ
が初期値であれば、作業領域（１）２１の第エニントリ
のテーブル識別子と作業領域（２）２３の第エニントリ
のテーブル識別子とが一致しているか否かを判定する（
ステップ１８３）。一致していれば、ステップ２０５以
降を実施し、一致していなければ、カウンタＮ１がカウ
ンタｒより大きいか否かを判定する（ステップ１８５）
。大きければ、カウンタｒにｌ加算（ステップ１８７）
Ｌ、ステップ１８３以降を繰り返す。小さければ、カウ
ンタＮ１にカウンタＪの値を設定（ステップ１８９）後
、カウンタＮ２がカウンタＪより大きいか否かを判定す
る（ステップ１９１）。小さければ、ステップ１９５以
降を実施して、大きければ、作業領域（１）２１の第１
エントリの世代識別子と作業領域（２）２３の第エニン
トリの世代識別子とが一致しているか否かを判定する（
ステップ１９３）。

一致していれば、カウンタＪに１加算（ステップ２０１
）後、ステップ１９３以降を実施する。

致していなければ、作業領域（２）２３の第１エントリ
から第エニントリまでの構造定義データにより、新テー
ブルのスキーマ定義データを生成する（ステップ１９５
）。生成内容は、第１のディクシヨナリの創成時と同じ
であるので省略する。

次に、カウンタＮ２がカウンタＪより大きいか否かを判
定する（ステップ１９７）。大きければ、カウンタＪに
１加算（ステップ１９９）後、ステップ１７９以降を実
施する。小さければこの処理を終了する。

次に、第８図は、第１図の第１のディクシヨナリ縮小モ
ジュール５Ｃの処理動作を示すフローチャートである。

このモジュールが起動されると、第１のディクシミナリ
縮小コマンドのオペランドである計算機システム名と削
除プログラムプロダクト識別子を端末１９から読み込む
（ステップ２０７）。指定された計算機システム名をキ
ーとして、第２のディクシヨナリ１１からこの計算機シ
ステム名で特定されるプログラムプロダクトの構造定義
データを検索し、第１図の作業領域（１）２１へ設定す
る（ステップ２０９）、次に、指定された削除プログラ
ムプロダクトの構造定義データは、第１図の作業領域（
２）２３へ移しくステップ２１１）、その後、第２のデ
ィクシヨナリ１１中の、これらの構造定義データに付加
されている計算機システム名を削除する（ステップ２１
３）。第２図のステップ６１と同様に、第１図の作業領
域（１）２１の構造定義データをテーブル識別子、カラ
ム識別子、世代識別子でソートし、かつ、重複を排除す
る（ステップ２１５）。同様に、第１図の作業領域（２
）２３の構造定義データをテーブル識別子、カラム識別
子、世代識別子でソートし、かつ、重複を排除する（ス
テップ２１７）。第１図の作業領域（２）２３の構造定
義データのうち、他のプログラムプロダクトと共用され
るため削除できないものを除く（ステップ２１９）。そ
の処理内容は、第６図の処理内容と同じである。残った
構造定義データ群を区別のため削除統合構造定義データ
と呼ぶ。尚、ステップ２１５で得られた構造定義データ
群を区別のため残存続合構造定義データと呼ぶ。

次に、削除統合構造定義データによる第１のディクシヨ
ナリの縮小が第１のディクシヨナリの再構成を必要とす
るか否かを判定する（ステップ２２３）。尚、再構成が
必要か否かは、データベース管理システムの能力による
。本実施例では、再構成が必要な場合と、不要な場合と
のいづれでも実現できるように、以下のようにしている
。

ステップ２２３において、削除統合構造定義データによ
る第１のディクシヨナリの縮小が第１のディクシヨナリ
の再構成を必要としなければ、削除統合構造定義データ
から、スキーマ操作言語による第１のディクシヨナリを
縮小するスキーマ操作データを生成する（ステップ２２
５）。このスキーマ操作データをデータベース管理シス
テム７へ送って実行させる（ステップ２２７）ことで、
第１のディクシヨナリ１５を縮小できる。ステップ２２
３において、削除統合構造定義データによる第１のディ
クシヨナリの縮小が第１のディクシヨナリの再構成を必
要とすれば、まず、第１のディクシヨナリ内の定義デー
タを退避する（ステップ２２９）。退避場所は、磁気テ
ープや磁気ディスク等の外部記憶装置でも良いし、第１
図の主記憶装置３、または、拡張記憶装置でも良い、残
存続合構造定義データから、スキーマ定義言語により第
１のディクシヨナリを創成するスキーマ定義データを生
成しくステップ２３１）、それを第１図のデータベース
管理システム７へ送って実行させ、新たな第１のディク
シヨナリを創成する（ステップ２３３）。尚、創成に先
立ち、同一計算機システム名で特定される第１のディク
シヨナリを削除しておくものとする。そして、退避した
定義データを新しい第１のディクシヨナリに再登録する
（ステップ２３５）ことで、第１のディクシヨナリを縮
小できる。

次に、第９図は、第８図のステップ２２５での第１図の
作業領域（２）２３の削除統合構造定義データによる第
１のディクシヨナリの縮小方法を示すフローチャートで
ある。

カウンタＮ１に第１図の作業領域（１）２１のエントリ
数を設定する（ステップ２３７）。カウンタＮ２に第１
図の作業領域（２）２３のエントリ数を設定する（ステ
ップ２３９）。カウンタＪに１を設定する（ステップ２
４１）。カウンタ■に１を設定する（ステップ２４３）
。第１図の作業領域（２）２３の第Ｊエントリの更新エ
ントリが初期値か否かを判定する（ステップ２４５）。

初期値でなければ、この作業領域（２）２３の第Ｊエン
トリの構造定義データによるカラム削除のためのスキー
マ操作データを生成する（ステップ２４７）。このデー
タの内容は、第１のディクシヨナリの拡張時（第７図の
ステップ２０３）と同じであり省略する。

次に、第１図の作業領域（１）２１の第１エントリの構
造定義データによるカラムの新規追加のためのスキーマ
操作データを生成する（ステップ２４９）。このデータ
の内容も、第１のディクシヨナリの拡張時（第７図のス
テップ２０４）と同じであり省略する。

その後、ステップ２６５以降を実行する。もし、ステッ
プ２４５において、更新エントリが初期値であれば、第
１図の作業領域（１）２１の第１エントリのテーブル識
別子と作業領域（２）２３の第Ｊエントリのテーブル識
別子とが一致しているか否かを判定する（ステップ２５
１）、一致していれば、ステップ２４９以降を実行する
。一致していなければ、カウンタＮ１がカウンタ■より
大きいが否かを判定する（ステップ２５３）。大きけれ
ば、カウンタ■に１加算（ステップ２５５）後、ステッ
プ２５１以降を繰り返し、小さければ、カウンタＮ２が
カウンタＪより大きいが否かを判定する（ステップ２５
７）。小さければ、ステップ２６３以降を実施し、大き
ければ、第１図の作業領域（２）２３の第Ｊエントリの
テーブル識別子と第Ｊ＋１エントリのテーブル識別子と
が一致しているが否かを判定する（ステップ２５９）。

一致していれば、カウンタＪに１加算（ステップ２６１
）後、ステップ２５９以降を実行し、一致していなけれ
ば、第１図の作業領域（２）２３の第Ｊエントリの構造
定義データにより削除するテーブルのスキーマ操作デー
タを生成する（ステップ２６３）。

例えば、ＩＳＯの５ＱＬ２に基づくデータベースの場合
、削除するテーブルの名前をテーブル識別子Ｔ、とする
と、ＤＲＯＰ　　ＴＡＢＬＥ　　Ｔのようなスキーマ操作データを生成する。

次に、カウンタＮ２がカウンタＪより大きいか否かを判
定する（ステップ２６５）。大きければ、カウンタＪに
１加算（ステップ２６７）後、ステップ２４３以降を実
行し、小さければ、この処理を終了する。

第１Ｏ図は、本発明の第２の実施例を施した管環システ
ムの構成を示すブロック図である。

第１の実施例では、計算機システム名で特定されるプロ
グラムプロダクト群の構造定義データの重複を排除した
統合構造定義データを第２のディクシヨナリに登録しな
い方法であったが、第２の実施例では、統合構造定義デ
ータを第２のディクシヨナリに登録することで、第２の
ディクシヨナリの容量は増えるが、処理の性能を向上さ
せた点に違いがある。

第２の実施例の構成は、第１図の第１の実施例の構成の
第２のディクシヨナリにおいて管理される構造定義デー
タレコード１３に加え、新たに統合構造定義データレコ
ード２６９が登録される。

また、統合構造定義データを第２のデイクショナリに登
録するために、定義データ管理システム２７１の第１の
ディクシヨナリ創成モジュール２７１Ａ、第１のディク
シヨナリ拡張モジュール２７１Ｂ、および、第１のディ
クシヨナリ縮小モジュール２７１Ｃの各プログラムの処
理内容が第１の実施例と異なる。しかし、それ以外は同
様であるため、以下、第１のディクシヨナリ創成モジュ
ール２７１Ａ、第１のディクシヨナリ拡張モジュール２
７１Ｂ、第１のディクシヨナリ縮小モジュール２７１Ｃ
の処理内容のみに関して説明する。

第１１図は、第２の実施例における第１０図の第１のデ
ィクシヨナリ創成モジュール２７１Ａの処理動作を示す
フローチャートである。

ステップ２７３以外は、第１の実施例における第３図と
同じ動作であり、説明を省略する。

本モジュールにおいては、第３図のステップ６１の処理
を実行して得られた統合構造定義データを、指定された
計算機システム名をキーとして、第２のディクシヨナリ
へ登録する（ステップ２７３）。

第１２図は、第２の実施例の第１０図における第１のデ
ィクシヨナリ拡張モジュール２７１Ｂの処理動作を示す
フローチャートである。

ステップ２７５とステップ２７７、および、第５図のス
テップ１１７の削除以外は、第１の実施例の第５図と同
じ動作であり、説明を省略する。

本モジュールでは、ステップ９９で得られた計算機シス
テム名をキーとして、第２のディクシヨナリから統合構
造定義データを検索して、第１０図の作業領域（１）２
１へ設定する（ステップ２７５）。

ステップ１１５において、指定された全追加プログラム
プロダクトについて構造定義データを第１０図の作業領
域（２）２３へ設定されたならば、第５図のステップ１
１７は行わず、直ちにステップ１１９を実行する。

ステップ１２１の後に、第１０図の作業領域（１）２１
へ、第１０図の作業領域（２）２３の構造定義データを
追加し、第１の実施例の第２図のステップ６１で実行し
たように、構造定義データをソート、重複部分を排除し
てできた新統合構造定義データで、第２のディクシヨナ
リ内に存在するステップ９９で指定された計算機システ
ム名と同名の統合構造定義データを置き換える。

第１３図は、第１０図の第２の実施例における第１のデ
ィクシヨナリ縮小モジュール２７１Ｃの処理動作を示す
フローチャートである。

その動作は、第１の実施例の第８図とほとんど同じ動作
であり、相違のあるところのみを説明する。

本モジュールでは、既存の統合構造定義データから、削
除される部分を省いた、第１０図の作業領域（１）２１
の新統合構造定義データを第２のディクシヨナリ内に存
在するステップ２０？で指定された計算機システム名と
同名の統合構造定義データを置き換える（ステップ２７
９）。その他の動作は、第８図と同じである。

このように、本実施例によれば、計算機システムを構成
する全プログラムプロダクトの実行内容を規定した定義
データや、実行状態のモニタデータや記録媒体の所在・
用途管理データ等の運用データを登録するための第１の
ディクシヨナリを創成できる。

そして、従来、計算機システムを構成するプログラムプ
ロダクトの種類やソフトハウス等のいわゆるベンダが異
なることに対応するため、プログラムプロダクト対応、
あるいは、組み合わされて利用されることの多い関連の
あるプログラムプロダクト群対応に別々の定義データ管
理システムが実現されていたため、各定義データ管理シ
ステム間で定義データが重複したり、整合性がとれない
等の事象が発生していたが、本実施例により、各プログ
ラムプロダクトの実行内容を規定した定義データや運用
データを第１のディクシヨナリにより一元管理できるの
で、プログラムプロダクト別に重複して定義データを登
録する手間や、整合性を管理する手間等が省ける。さら
に、定義データと運用データの一元管理もできる。

さらに、既存の第１のディクシヨナリにより管理できる
定義データの種類を増やすために第１のディクシヨナリ
構造の拡張ができる。そして、計算機システムの構成要
素となるプログラムプロダクトが増える度に、第１のデ
ィクシヨナリを再創成する必要がなくなる。

さらに、既存の第１のディクシヨナリにより管理対象す
る定義データの種類を少なくすることができるので、第
１のディクシヨナリ構造を縮小できる。そして、計算機
システムの構成要素となっていたプログラムプロダクト
の使用をやめることで、第１のディクシヨナリを再創成
する必要がなくなる。

さらに、現在の第１のディクシヨナリの構造定義データ
を別に管理することにより、新規プログラムプロダクト
の追加による第１のディクシヨナリの拡張処理時に、計
算機システム全体の構造定義データを合成する手間が省
けるので、この拡張処理を高性能化できる。

〔発明の効果］以上のように、本発明によれば、プログラムプロダクト
の多様な組み合わせで実現される計算機システムの定義
データや運用データを第１のディクシヨナリで一元管理
することが可能となり、定義データの登録の重複と定義
データ間の整合性を管理する手間が省け、効率の良い定
義データの管理システムを実現することが可能である。

【図面の簡単な説明】

第１図は本発明を施した第１の実施例の計算機システム
の全体構成を示すブロック図、第２図は第１図における
定義データ管理システム５の処理概要を示すフローチャ
ート、第３図は第１図における計算機システムの第１の
ディクシヨナリ創成モジュールの処理手順を示すフロー
チャート、第４図は第３図のステップ６１における重複
構造定義データの排除の手順を示すフローチャート、第
５図は第１図における計算機システムの第１のディクシ
ヨナリ拡張モジュールの処理手順を示すフローチャート
、第６図は第５図におけるステップ１２１での重複構造
定義データの排除方法を示すフローチャート、第７図は
第５図のステップ１２５でのスキーマ操作データの生成
方法を示すフローチャート、第８図は第１図における計
算機システムの第１のディクシヨナリ縮小モジュールの
処理を示すフローチャート、第９図は第８ＶＩ！Ｊのス
テップ２２５での第１のディクシヨナリの縮小方法を示
すフローチャート、第１０図は本発明を施した第２の実
施例の計算機システムの全体構成を示すブロック図、第
１１図は第１０図の第２の実施例における計算機システ
ムの第１のディクシヨナリ創成モジュールの処理動作を
示すフローチャート、第１２図は第１ｏ図の第２の実施
例における計算機システムの第１のディクシヨナリ拡張
モジュールの処理動作を示すフローチャート、第１３図
は第１０図の第２の実施例における計算機システムの第
１のディクシヨナリ削除モジュールの処理動作を示すフ
ローチャートである。１：ＣＰＵ、３：主記憶装置、５．定義データ管理シス
テム（第１のディクシヨナリ創成モジュール（５Ａ）／
第１のディクシヨナリ拡張モジュール（５Ｂ）／第１の
ディクシヨナリ縮小モジュール（５Ｃ））、７・データ
ベース管理システム、９：マスタテープ群（プログラム
プロダクト識別子（９Ａ）／ロードモジュール類（９Ｂ
）／構造定義データ（９Ｃ））、　１１　：第２のディ
クシヨナリ、１３構造定義データレコード群（プログラ
ムプロダクト識別子（１３）／構造定義データ（１３Ｂ
）／計算機システム名（１３Ｃ））、１５：第１のディ
クシヨナリ、１７：定義データテーブル群（テーブル名
（１７Ａ）／カラム名（１７Ｂ）／定義データ値（１７
Ｃ））、１９　：端末装置、２１：作業領域（１）（テ
ーブル識別子（２１Ａ）／カラム識別子（２１Ｂ）７世
代識別子（２１Ｃ）／属性（２ＬＤ））、２３　：作業
領域（２）（テーブル識別子（２３Ａ）／カラム識別子
（２３Ｂ）７世代識別子（２３Ｃ）／属性（２３Ｄ）／
更新フラグ（２３Ｅ））、２６９　：統合構造定義デー
タレコード群、２７１：定義データ管理システム（第１
のディクシヨナリ創成モジュール（２７＋Ａ）／第１の
ディクシヨナリ拡張モジュール（２７１Ｂ）／第１のデ
ィクシヨナリ縮小モジュール（２７１Ｃ））。

Claims

【特許請求の範囲】１、データベース管理システムに代表されるプログラム
プロダクト群、該プログラムプロダクト群の各々の実行
に必要な定義データを登録し管理する第１のディクシヨ
ナリ、および、該第１のディクシヨナリの構造定義デー
タを記憶し管理する第２のデイクシヨナリを有する計算
機システムにおいて、オペレーティングシステムおよび
システム開発支援ツールを含む上記プログラムプロダク
ト群各々には、あらかじめ、該プログラムプロダクト群
各々の実行に必要な運用データを含む全定義データに関
する上記構造定義データが付加され、上記計算機システ
ムは、該付加された構造定義データを記憶し、上記第１
のディクシヨナリの創成要求に応答して、上記プログラ
ムプロダクト群が有する構造定義データに基づき上記第
１のデイクシヨナリを創成することを特徴とするデイク
シヨナリ創成方法。２、上記各プログラムプロダクト群の各々に施された全
定義データに関する構造定義データを、上記各プログラ
ムプロダクト群の各々のマスタテープに格納し、上記第
１のディクシヨナリの創成要求に応答して、上記各々の
マスタテープから上記構造定義データを読み込むことを
特徴とする請求項１に記載のディクシヨナリ創成方法。３、上記各プログラムプロダクト群の各々に施された全
定義データに関する構造定義データを、お互いに関連す
る上記各プログラムプロダクト群の内の１つのプログラ
ムプロダクトのマスタテープにまとめて格納し、上記第
１のディクシヨナリの創成要求に応答して、上記構造定
義データをまとめて格納しているマスタテープから上記
構造定義データを読み込むことを特徴とする請求項１に
記載のディクシヨナリ創成方法。４、上記第１のデイクシヨナリの創成要求は、少なくと
も、上記構造定義データを有するプログラムプロダクト
を特定する名前と、上記プログラムプロダクト群を特定
する名前とから構成されることを特徴とする請求項１に
記載のディクシヨナリ創成方法。５、上記各プログラムプロダクト群における共通な構造
定義データの重複を排除して、上記第１のディクシヨナ
リを創成することを特徴とする請求項１に記載のデイク
シヨナリ創成方法。６、上記プログラムプロダクト群への新たなプログラム
プロダクトの追加に伴う上記第１のデイクシヨナリの拡
張要求に応答して、該追加されるプログラムプロダクト
の構造定義データから既存の第１のディクシヨナリを創
成した構造定義データの重複部分を排除して、上記第１
のディクシヨナリを拡張することを特徴とする請求項１
に記載のディクシヨナリ創成方法。７、上記プログラムプロダクト群内の任意のプログラム
プロダクトの削除に伴う上記第１のデイクシヨナリの縮
小要求に応答して、該削除要求されたプログラムプロダ
クトの構造定義データであり、かつ、削除要求されてい
ないプログラムプロダクトの構造定義データと重複しな
い構造定義データのみを削除して、第１のディクシヨナ
リを縮小することを特徴とする請求項１に記載のディク
シヨナリ創成方法。