JPH06348564A - アプリケーションプログラムの自動チェック方式 - Google Patents

Abstract

(57)【要約】 【目的】 データベースの定義変更に伴うアプリケーシ
ョンプログラムの運用を容易にする。 【構成】 データディクショナリ・ディレクトリ内のデ
ータベースの論理構造の定義変更時に、該データベース
を利用するアプリケーションプログラムのオブジェクト
モジュールに組み込んだデータベースのバージョン識別
コードと、定義変更後のデータディクショナリ・ディレ
クトリに組み込まれたバージョン識別コードとを比較す
る手段を設け、その比較結果によってアプリケーション
プログラムのリコンパイルの要否を通知する。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、データディクショナリ
・ディレクトリを有するデータベースシステムにおい
て、データディクショナリ・ディレクトリ中の定義情報
を参照するアプリケーションプログラムの自動チェック
方式に関するものである。

【０００２】

【従来の技術】従来、データディクショナリ・ディレク
トリ機能を有するデータべースシステムにおいては、例
えば特開昭６２−１６４１３６号公報に記載のように、
種々のリソースをデータディクショナリ・ディレクトリ
等で管理しているほか、アプリケーションプログラム
（オブジェクトモジュール）にもデータベース定義情報
を持たせ、実行時の性能を向上させている。

【０００３】しかし、アプリケーションプログラムはシ
ステム間のポータビリティの観点からデータディクショ
ナリ・ディレクトリの管理外に置くことが多い。

【０００４】このため、アプリケーションプログラムは
リソース管理の範囲から除外されていることになるの
で、データベースの定義変更を行うと、アプリケーショ
ンプログラムをリコンパイルする必要がある。

【０００５】すなわち、アプリケーションプログラムを
コンパイルする時、そのプログラム中に記述されたデー
タベースのアクセス要求内容とデータベースの定義内容
との整合を検証したり、アクセス要求を実行形式に変換
するため、ディクショナリ中のデータベース定義情報を
参照している。そして、コンパイル時に参照したデータ
ベース定義内容と、データベース管理プムグラムがアプ
リケーションプログラムの実行時に参照するデータベー
ス定義（ディクショナリ中のデータベース定義を実行時
に参照しやすい形式に編集したディレクトリテーブル内
のデータベース定義情報のこと）内容との間の整合がと
れていることを確認するため、ディクショナリ中のデー
タベース定義のバージョン識別コードを、アプリケーシ
ョンプログラムのコンパイル結果であるオブジェクトモ
ジュールと、ディレクトリテーブルとに設定しておき、
実行時に、それらの一致をとって整合性を確認してい
る。

【０００６】従って、データベース定義情報を変更をす
ると、データベース定義のバージョン識別コードが変化
し、新しいディレクトリテーブルに設定されるデータベ
ース定義のバージョン識別コードは変更後のものが設定
されることになる。よって、アプリケーションプログラ
ムを実行するためには、その新しいバージョン識別コー
ドをオブジェクトモジュール中に持たせることが必要に
なる。このため、アプリケーションプログラムのリコン
パイルが必要となる。

【０００７】

【発明が解決しようとする課題】上記のように、データ
ディクショナリディレクトリ機能を有するデータベース
システムでは、ディクショナリ内のある同じ定義管理単
位に属する定義情報を参照した複数のアプリケーション
プログラム互いに関連をもって動作するとき、参照時点
の違いによる定義内容の不一致に起因する誤動作を防止
するため、定義情報のディクショナリ内でのバージョン
識別コード（例えば、定義情報がディクショナリに登録
・更新された日時など）をそれぞれのアプリケーション
プログラムに設定し、その一致をとって整合性を確認す
る方式をとっている。

【０００８】例えば、アプリケーションプログラムのコ
ンパイル時に参照したデータベースの論理構造の定義
（例えば、ＩＳＯで標準化されたＮＤＬの＜ｓｃｈｅｍ
ａ＞）やデータベースの仮想構造の定義（同じく、＜ｓ
ｕｂｓｃｈｅｍａ＞）情報と、これら定義を実行形式に
編集したディレクトリテーブルのそれらとが、アプリケ
ーションプログラムの実行時に矛盾がしないことを、デ
ィクショナリ参照時に定義情報とともに取り込んだ各定
義管理単位バージョン識別コードの一致をとって確認し
ている。このため、各定義管理単位の定義内容に変更が
あった場合、バージョン識別コードが変化し、アプリケ
ーションプログラムをリコンパイルする必要があった。
もし、このリコンパイルを忘れると、アプリケーション
プログラムの実行時に各定義管理のバージョン識別コー
ドが不一致となり、アプリケーションプログラムを実行
できないという問題が生じる。

【０００９】本発明の目的は、データベースの定義変更
に伴うアプリケーションプログラムの運用を容易にする
ことができるアプリケーションプログラムの自動検査方
式を提供することである。

【００１０】

【課題を解決するための手段】上記目的を達成するため
に本発明は、データベースの論理構造の定義変更時に、
該データベースを利用するアプリケーションプログラム
のオブジェクトモジュールに組み込んだデータベースの
バージョン識別コードと、定義変更後のデータディクシ
ョナリ・ディレクトリに組み込まれたバージョン識別コ
ードとを比較し、アプリケーションプログラムのリコン
パイルの要否を通知するようにしたものである。

【００１１】

【作用】上記手段によれば、アプリケーションプログラ
ムをコンパイルする時、データベースの定義情報のバー
ジョン識別コードとアプリケーションプムグラムのメン
バ名称、データベース定義名称を予めオブジェクトモジ
ュールに組み込んでおく。

【００１２】また、データディクショナリ・ディレクト
リを作成する時、データベース定義名称とそのバージョ
ン識別コードを組み込んでく。

【００１３】定義変更を行った時は、アプリケーション
プログラムのオブジェクトモジュールをロードし、その
オブジェクトモジュール中に組み込んであるバージョン
識別コードを検出すると共に、データディクショナリ・
ディレクトリに組み込まれたバージョン識別コードを検
出し、そのバージョン識別コードを比較し、一致する時
はそのまま実行可能とし、不一致の時はリコンパイルが
必要であることを表示出力などの方法で通知する。

【００１４】このようにすれば、データベースの定義情
報に変更があり、バージョン識別コードが変わり、リコ
ンパイルを忘れても、アプリケーションプログラムの実
行前にリコンパイルが必要であることが判るので、デー
タベースの定義変更に伴うアプリケーションプログラム
の運用が極めて容易になる。

【００１５】

【実施例】以下、本発明を図示する実施例に基づいて詳
細に説明する。

【００１６】図１は、本発明を実施するのに必要なプロ
グラムやデータファイルなどの全体構成の一実施例を示
す構成図であり、１はアプリケーションプログラムが登
録されているソースライブラリ、２はアプリケーション
プログラムのソースを翻訳する言語プロセサ、３は言語
プロセサ２による翻訳の結果生成されたオブジェクトモ
ジュールを登録するオブジェクトライブラリ、４はオブ
ジェクトモジュールを実行形式のロードモジュールに変
換するリンケージエディタ、５はロードモジュールを登
録するロードライブラリ、６はデータベースアクセスや
端末とのメッセージ送受信などを行うデータベース管理
プログラム、７はデータベース、８は端末、９はデータ
ベース７の定義情報を登録，更新，削除するディクショ
ナリ，１０はデータベース管理プログラム６が実行時に
参照しやすい形式にディクショナリ９内の定義情報を編
集してディレクトリテーブルを生成するディレクトリ生
成プログラム、１１はディレクトリテーブルを登録する
ディレクトリファィル、１２はディクショナリ９に登録
する定義ソースや定義の登録・更新などのディクショナ
リ操作文を登録する定義操作文ライブラリ、１３は定義
ソースやディクショナリ操作指示を解析し、それに基づ
きディクショナリ９への定義の登録・更新・削除などを
行うディクショナリ操作プログラム、１４はディクショ
ナリ９中の定義情報からディレクトリテーブルの生成・
削除を指示するディレクトリ操作文を登録するディレク
トリ操作文ライブラリ、１５はロードモジュール影響チ
ェックプログラムである。

【００１７】ここで、データベース７の定義仕様は、Ｉ
ＳＯ ８９０７−１９８７Ｉｎｆｏｒｍａｔｉｏｎ Ｐ
ｒｏｃｅｓｓｉｎｇ ｓｙｓｔｅｍｓ−Ｄａｔａｂａｓ
ｅ Ｌａｎｇｕａｇｅ ＮＤＬに基づくものとする。

【００１８】ＮＤＬ（ネットワーク型データベース言
語）では、データべースの論理的な構造をレコードタイ
プ（以下、レコード），そのレコードを構成するコンポ
ーネントタイプ（以下、コンポーネント）およびレコー
ド間の関係を示すセットタイプ（以下、セット）によっ
て定義する。以下レコード，コンポーネント，セットな
どによって定義されるデータベースの論理的な構造を論
理スキーマと呼ぶ。

【００１９】また、論理スキーマの一部分を再定義した
ものをサブスキーマと呼ぶ。このサブスキーマは、論理
スキーマのレコード，コンポーネント，セットを前提に
するレコードビュー，コンポーネントビュー，セットビ
ューを定義するものである。

【００２０】データベースの利用者は、このサブスキー
マの範囲内でデータべースをアクセスできる。

【００２１】論理スキーマの定義例を次に示す。データ
べースの論理構造が図２のような構造であり、レコード
名がＲＥＣ１，ＲＥＣ２、各レコードの構成するコンポ
ートネント名がＣ１１，Ｃ１２とＣ２１，Ｃ２２，Ｃ２
３、親レコードＲＥＣ１と子レコードＲＥＣ２のセット
名がＳＥＴ１であるとすると、ＮＤＬでは次のように定
義できる。

【００２２】 ＳＣＨＥＭＡ ＳＣＨ１ ＲＥＣＯＲＤ ＲＥＣ１ ＩＴＥＭ Ｃ１１ ＣＨＡＲＡＣＴＥＲ ２ ＩＴＥＭ Ｃ１２ ＣＨＡＲＡＣＴＥＲ ２ ＲＥＣＯＲＤ ＲＥＣ２ ＩＴＥＭ Ｃ２１ ＢＩＮＡＲＹ ３１ ＩＴＥＭ Ｃ２２ ＣＨＡＲＡＣＴＥＲ ２ ＩＴＥＭ Ｃ２３ ＣＨＡＲＡＣＴＥＲ ２ ＳＥＴ ＳＥＴ１ ＯＷＮＥＲ ＲＥＣ１ ＯＲＤＥＲ ＦＩＲＳＴ ＭＥＭＢＥＲ ＲＥＣ２ ＩＮＳＥＲＴＩＯＮ ＡＵＴＯＭＡＴＩＣ ＲＥＴＥＮＴＩＯＮ ＦＩＸＥＤ ここで、論理スキーマ名称をＳＣＨ１とした。

【００２３】同様に、サブスキーマの構造が図３のよう
な構造であり、レコードビュー名がＲＥＣＶ１とＲＥＣ
Ｖ２、各レコードビューを構成するコンポーネントビュ
ー名がＣＶ１１とＣＶ１２およびＣＶ２１とＣＶ２２、
レコードビューＲＥＣＶ１とＲＥＣＶ２のセットビュー
名がＳＥＴＶ１であるとすると、ＮＤＬでは、次のよう
に定義できる。

【００２４】 ＳＵＢＳＣＨＥＭＡ ＳＵＢＳ１ ＯＦ ＳＣＨ１ ＲＥＣＯＲＤ ＲＥＣ１ ＲＥＮＡＭＥＤ ＲＥＣＶ１ ＩＴＥＭ Ｃ１１ ＲＥＮＡＭＥＤ ＣＶ１１ ＩＴＥＭ Ｃ１２ ＲＥＮＡＭＥＤ ＣＶ１２ ＲＥＣＯＲＤ ＲＥＣ２ ＲＥＮＡＭＥＤ ＲＥＣＶ２ ＩＴＥＭ Ｃ２１ ＲＥＮＡＭＥＤ ＣＶ２１ ＩＴＥＭ Ｃ２２ ＲＥＮＡＭＥＤ ＣＶ２２ ＳＥＴ ＳＥＴ１ ＲＥＮＡＭＥＤ ＳＥＴＶ１ ここで、サブスキーマ名称をＳＵＢＳ１とした。

【００２５】このような論理スキーマやサブスキーマ
は、個々に名称やバージョン識別コードが付与されてデ
ィクショナリ９に登録される。論理スキーマの定義情報
を登録するディクショナリの構造を図４に示す。

【００２６】図４では、スキーマ名やシステム内一意の
スキーマ番号，スキーマバージョン番号および論理スキ
ーマ全体に関係するスキーマ情報がレコード４１に、レ
コード名やスキーマ内一意のレコード番号およびレコー
ド単位のレコード情報がレコード４２に、コンポーネン
ト名やレコード内一意のコンポーネント番号、コンポー
ネント単位のコンポーネント情報がレコード４３に、セ
ット名やスキーマ内一意セット番号、セットの親となる
オーナレコードのレコード番号およびセット単位のセッ
ト情報がレコード４４に、セットの子となるメンバレコ
ードのレコード番号とメンバレコード単位のメンバレコ
ード情報がレコード４５にそれぞれ登録される。

【００２７】また、レコード４１とレコード４２，レコ
ード４２とレコード４３，レコード４４とレコード４５
とがそれぞれセット関係を有する。

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

【００２９】図５ではサブスキーマ名やスキーマ内で一
意なサブスキーマ番号、サブスキーマバージョン識別コ
ードおよびサブスキーマ全体に関係するザブスキーマ情
報がレコード５１に、レコードビュー名やサブスキーマ
内一意のレコードビュー番号、レコードビューに対応す
るレコードのレコード名とレコード番号およびレコード
ビュー単位のレコードビュー情報がレコード５２に、コ
ンポーネントビュー名やレコードビュー内一意のコンポ
ーネントビュー番号、コンポーネントビューに対応する
コンポーネント名とコンポーネント番号およびコンポー
ネントビュー単位のコンポーネントビュー情報がレコー
ド５３に、セットビュー名とサブスキーマ内一意のセッ
トビュー番号、セットビューに対応するセットのセット
名とセット番号およびセットビュー単位のセットビュー
情報がレコード５４にそれぞれ登録される。

【００３０】また、レコード５１とレコード５２，レコ
ード５２とレコード５３，レコード５１とレコード５４
とがそれぞれセット関係を有する。そして、ある名称と
バージョン識別コードとで識別される論理スキーマと、
ある名称とバージョン識別コードとで識別コードとで識
別されるサブスキーマとが正しく関係付けられたとき、
この１組の論理スキーマとサブスキーマに対して世代識
別が付与される。

【００３１】この場合、名称が同じ組合せでも、バージ
ョン識別コードが異れば、別の世代識別が与えられる。
世代識別は関係付けられた時点に依存し、バージョン識
別コードの大きさに依存いない。この世代識別を登録す
るディクショナリ９の構造を図６に示す。

【００３２】図６では、関係付けられた論理スキーマの
スキーマ番号とバージョン識別レコード、サブスキーマ
のザブスキーマ番号とバージョン識別コードおよび世代
識別とがレコード６１に登録される。

【００３３】ディクショナリ９に登録された定義情報
は、ディレクトリ生成プログラム１０によってデータベ
ース管理システム６が実行時に参照しやすい形式（ディ
レクトリテーブル）に編集され、ディレクトリファイル
１１に登録される。

【００３４】ディレクトリテーブルの例を図７に示す。
ここでビュー情報は、ビューの種別毎に１まとまりのテ
ーブルとして構成される。また、個々のビュー情報は、
各テーブルの第何番目、すなわち配列番号がディクショ
ナリ中のビュー番号と一致するように生成される。

【００３５】他方、データベースシステムの利用者は、
アプリケーションプログラムをＣＯＢＯＬ言語やＰＬ／
Ｉ言語などの標準プログラム言語を用いて作成する。例
えば、次のように記述される。サブスキーマの例として
ＳＵＢＳ１を用い、ＣＯＢＯＬ言語により記述例を示
す。

【００３６】 ： ＤＡＴＡ ＤＩＶＩＳＩＯＮ ＳＵＢ−ＳＣＨＥＭＡ ＳＥＣＴＩＯＮ ＤＢ ＳＵＢＳ１ ＷＩＴＨＩＮ ＳＣＨ１ ： ＰＲＯＣＥＤＵＲＥ ＤＩＶＩＳＩＯＮ ： ＦＩＮＤ ＦＩＲＳＴ ＲＥＣＶ１ ＩＮ ＳＥＴ ＳＥＴＶ１ ＷＨＥＲＥ ＣＶ１１＝’ＡＢ’ ＡＮＤ ＣＶ１２＝’ＣＤ’ ： 「ＤＡＴＡ ＤＩＶＩＳＩＯＮ」では、このアプリケー
ションプログラムで使用するユーザデータベースの論理
スキーマ名や、サブスキーマ名が指定される。

【００３７】また、「ＰＲＯＣＥＤＵＲＥ ＤＩＶＩＳ
ＩＯＮ」においては、データべースアクセス命令が記述
される。上記の例では、ユーザデータベース中からセッ
トビューＳＥＴＶ１に属するレコードビューＲＥＣＶ１
の実現値の中で、コンポーネントビューＣＶ１１の値
が’ＡＢ’であり、かつＣＶ１２の値が’ＣＤ’である
実現値の並びの中で先頭（ＦＩＲＳＴ）のものを検索す
るデータベースアクセス命令である。

【００３８】図１に示すソースライブラリ１の中のアプ
リケーションプログラムは言語プロセッサ２によってオ
ブジェクトモジュールに変換され、オブジェクトライブ
ラリ３に登録される。この時、アプリケーションプログ
ラムの「ＳＵＢ−ＳＣＨＥＭＡ ＳＥＣＴＩＯＮ」で指
定したサブスキーマ名，スキーマ名がディクショナリ９
に登録されているか、またＦＩＮＤ文で指定したレコー
ドビュー名，セットビュー名コンポーネントビュー名が
ディクショナリ９に登録されているかのチェックを行
い、ＯＫであればＦＩＮＤ命令の実行時テーブルを図８
のように生成する。

【００３９】図８はＵＡＰ（ユーザアプリケーションプ
ログラム）名称７１，スキーマ名称７２，サブスキーマ
名称７３，世代識別７４，命令種別７５，セットビュー
番号７６，レコードビュー番号７７，アクセス命令情報
７８，検索条件情報７９からなるテーブル構成を示す。

【００４０】次に、図１のオブジェクトライブラり３中
のオブジェクトモジュールは、ユーザがリンケージエン
ディタ４を起動することにより、ロードモジュールに変
換されてロードライブラリ５に登録される。その後、ユ
ーザがロードモジュールを実行させ、その中でデータベ
ースシステムアクセス命令が発行されると、データべー
ス管理システム６が図７に示すようなディレクトリテー
ブル中のビュー情報をもとにデータベース７をアクセス
する。

【００４１】一方、既登録の論理スキーマ定義の部分変
更操作は、ディクショナリ操作プログラム１３によって
行なわれる。

【００４２】図９は、ディクショナリ操作プログラム１
３の処理手順を示すフローチャートである。

【００４３】まず、ディクショナリ操作プログラム１３
が起動されると、ディクショナリ操作文が論理スキーマ
の定義内容の部分変更の操作文であるかどうかを判別し
（ステップ１０１）、そうであればステップ１０２以降
を実施し、それ以外の操作文ならば、操作内容に合わせ
た他の処理を実行する。

【００４４】ディクショナリ操作文が図１０、図１１お
よび図１２に例示するような論理スキーマＳＣＨ１の定
義内容の部分変更の操作文ならば、ステップ１０２以降
を実行する。

【００４５】ステップ１０２では、部分変更の内容が解
析される。次に、該当論理スキーマの定義内容がディク
ショナリ９から検索され（ステップ１０３）、部分変更
内容を反映して、ディクショナリ９内のものと入れ替え
る（ステップ１０４）。

【００４６】その後、当該部分変更がサブスキーマ定
義、更にはアプリケーションプログラムに影響を与える
可能性があるかどうかをロードモジュール影響チェック
プログラム１５によって判断し（ステップ１０５）、影
響を与える可能性があればステップ１０９を実行する。

【００４７】すなわち、ロードライブラリ５より当該サ
ブスキーと論理スキーマを使用しているアプリケーショ
ンプログラムを検索して表示し、ユーザに通知する。

【００４８】例えば、図１１の例ではコンポーネントタ
イプのデータ属性が変更されており、サブスキーマ定義
を通してアプリケーションプログラムに影響を与える可
能性があるので、ステップ１０９を実行する。

【００４９】また、図１２の例では、レコードタイプが
追加されているが、これは既存のサブスキーマやアプリ
ケーションプログラムに影響を与えないので処理を終了
する。

【００５０】また、図１０の例では、サブスキーマＳＵ
ＢＳ１内のセットビューＳＥＴＶ１は、論理スキーマＳ
ＣＨ１のセットタイプＳＥＴ１を前提としており、この
セットタイプＳＥＴ１の削除により、サブスキーマＳＵ
ＢＳ１との整合性を維持できなくなるので、ステップ１
０９を実行する。

【００５１】同様に、また部分変更内容とサブスキーマ
定義内容とをチェックし（ステップ１０６〜１０７）、
サブスキーマを通してアプリケーションプログラムに影
響があるかどうかをロードモジュール影響チェックプロ
グラム１５によって判断し（ステップ１０８）、あるな
らばステップ１０９を実行する。

【００５２】図１１の例では、コンポーネントビューＣ
Ｖ２１の前提となるコンポーネントタイプＣ１２のデー
タ属性がＢＩＮＡＲＹ３１→ＦＬＯＡＴ４に変更され
る。これはサブスキーマ定義内容に影響しないが、アプ
リケーションプログラムへの影響の可能性がある。例え
ば、データベース検索時の条件として、図１３に示すよ
うなコンポーネントととの比較対象として、リテラル値
を指定した場合、アプリケーションプログラムの実行時
性能を向上させるため、言語プロセッサ２によるアプリ
ケーションプログラムのコンパイル時に、リテラル値を
コンポーネントの属性に合わせたデータ形式に前もって
変換する方式をとったとすると、コンポーネントタイプ
のデータ属性の変更は、アプリケーションプログラムに
影響があるとしてステップ１０９を実行することにな
る。

【００５３】このような処理は独立したプログラムによ
って行うようにしてもよいが、データベース管理プログ
ラム６に組み込んでもよい。いずれにおいても、データ
ベースの定義変更に伴ってリコンパイルする必要のある
アプリケーションプログラムがその実行前にユーザに通
知される。

【００５４】これによって、論理スキーマの定義内容を
部分変更した際、それによって整合性が維持できなくな
るサブスキーマ、またはリコンパイルを必要とするアプ
リケーションプログラムの範囲が明確にわかるようにな
るため、定義変更後のデータベースシステムの運用が容
易になると共に、定義変更にかかわる保守コストを削減
し、信頼性を向上させることができる。

【００５５】

【発明の効果】以上説明したように本発明によれば、デ
ータベースの論理構造の定義変更時に、該データベース
を利用するアプリケーションプログラムのオブジェクト
モジュールに組み込んだデータベースのバージョン識別
コードと、定義変更後のデータディクショナリ・ディレ
クトリに組み込まれたバージョン識別コードとを比較
し、アプリケーションプログラムのリコンパイルの要否
を通知するようにしたため、データベースの定義変更に
伴うアプリケーションプログラムの運用を極めて容易に
することができる。

【図面の簡単な説明】

【図１】本発明の一実施例を示す全体構成図である。

【図２】データベースの論理的構成を例示した説明図で
ある。

【図３】データベースの使用範囲をビューとして例示し
た説明図である。

【図４】論理スキーマ定義のディクショナリ内構造を表
現した説明図である。

【図５】サブスキーマ定義ディクショナリ内構造を表現
した説明図である。

【図６】世代情報のディクショナリ内構造を表現した説
明図である。

【図７】ディレクトリテーブルの構造を示した説明図で
ある。

【図８】アプリケーションプログラムのデータベースア
クセス命令を実行形式に編集、加工した実行時テーブル
の構成を示す説明図である。

【図９】ディクショナリ操作プログラムの中で論理スキ
ーマ定義内容を部分変更する処理のフローチャートであ
る。

【図１０】論理スキーマ定義内容を部分変更する指示の
一例を示す説明図である。

【図１１】論理スキーマ定義内容を部分変更する指示の
他の例を示す説明図である。

【図１２】論理スキーマ定義内容を部分変更する指示の
さらに他の例を示す説明図である。

【図１３】データベースアクセス命令の例を示す説明図
である。

【符号の説明】

１…ソースライブラリ、２…言語プロセッサ、３…オブ
ジェクトライブラリ、４…リンケージエディタ、５…ロ
ードライブラリ、６…データベース管理システム、７…
データベース、８…端末、９…ディクショナリ、１０…
ディレクトリ生成プログラム、１１…ディレクトリ、１
２…定義操作文ライブラリ、１３…ディクショナリ操作
プログラム、１４…ディレクトリ操作文ライブラリ、１
５…ロードモジュール影響チェックプログラム。

Claims (1)

【特許請求の範囲】
1. 【請求項１】 データディクショナリ・ディレクトリを
   有するデータべースシステムにおいて、 前記データディクショナリ・ディレクトリ内のデータベ
   ースの論理構造の定義変更時に、該データベースを利用
   するアプリケーションプログラムのオブジェクトモジュ
   ールに組み込んだデータベースのバージョン識別コード
   と、定義変更後のデータディクショナリ・ディレクトリ
   に組み込まれたバージョン識別コードとを比較する手段
   を設け、その比較結果によってアプリケーションプログ
   ラムのリコンパイルの要否を通知することを特徴とする
   アプリケーションプログラムの自動チェック方式。