JPH05204727A

JPH05204727A - デ−タベ−ス管理方法およびそのシステム

Info

Publication number: JPH05204727A
Application number: JP4011617A
Authority: JP
Inventors: Nobuo Kawamura; 信男河村; Kosaku Yamahira; 耕作山平; Takashi Kodera; 孝小寺; Hidenori Shinozaki; 英典篠崎
Original assignee: Hitachi Software Engineering Co Ltd; Hitachi Ltd
Current assignee: Hitachi Software Engineering Co Ltd; Hitachi Ltd
Priority date: 1992-01-27
Filing date: 1992-01-27
Publication date: 1993-08-13

Abstract

(57)【要約】【目的】あるデ−タとの整合性を維持する必要がある
他のデ−タに対して、整合性を簡単に維持することが可
能なデ−タベ−ス管理方法とシステムを実現する。【構成】あるデ−タのデ−タ操作要求に対して、作成
された『処理手続き１』の実行時に、予めあるデ−タと
整合性を維持する必要がある他のデ−タの整合性を維持
するための『処理手続き２』『処理手続き３』および
『処理手続き４』をデ−タベ−スから取り出して、これ
らを実行する。これにより、整合性を維持するための処
理を効率よく行うことができる。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、リレ−ショナルデ−タ
ベ−スの管理方法および管理システムに関し、特に複数
のリレ−ション（表）間でのデ−タの整合性を保持する
ための方法およびシステムに関する。

【０００２】

【従来の技術】デ−タベ−スとは、会社、銀行、病院、
大学、政府機関等の組織体の運用に必要なデ−タを格納
した１以上のファイルの集まりである。そして、そのデ
−タベ−スを管理するため、デ−タを記録し保持するコ
ンピュ−タシステムを、デ−タベ−ス管理システムと呼
ぶ。デ−タベ−ス管理システムのうち、リレ−ショナル
デ−タベ−ス管理システムにおいては、デ−タベ−スが
ユ−ザから２次元の表形式で見られるリレ−ション
（表）からなり、さらにこの表は複数の行（レコ−ド、
またはタップル）から構成されている。また、タップル
は複数個の列（アトリビュ−ト、あるいはフィ−ルド）
から構成され、各列にはその列の特性を示すデ−タ型、
デ−タ長が規定されている。従来のリレ−ショナルデ−
タベ−スでは、個々の表を独立して定義していたので、
複数の表の間でデ−タの関連を持たせるようなことは無
かった。しかし、1987年にＩＳＯ（国際標準化委員会）
で規格化されたデ−タベ−ス言語ＳＱＬでは、複数の表
間で相互に関連する列に注目して、デ−タの参照整合性
を保持することを指定する参照制約が言語仕様として追
加された。これは、ある表の１つないし複数の列からな
る主キ−と、他の１つの表の１つないし複数の列からな
る外部キ−を宣言し、外部キ−が取り得る値は必ず主キ
−の中に値が存在するということを規定するものであ
る。

【０００３】例えば、『従業員』表と『部門』表からな
るデ−タベ−スについて考えると、『従業員』表に存在
するある従業員が、『部門』表に存在しない部門に所属
していてはならない。つまり、『従業員』表に存在する
従業員は、必ず『部門』表中にも存在する。存在しない
状態にある場合は、参照整合性が保持されていないこと
になる。この参照整合性を保持するための制約を規定す
るものが参照制約であって、『部門』表中の部門デ−タ
を持つ列が主キ−であり、『従業員』表中の従業員の所
属部門を持つ列が外部キ−である。また、『部門』表の
ような表を被参照表と呼び、『従業員』表のような表を
参照表と呼ぶ。この参照整合性については、例えば、
Ｃ．Ｊ．Ｄate著『デ−タベ−ス入門（Ａn Ｉntroduct
ion toＤatabase Ｓystems)』第3版、Ａddison Ｗes
ley出版社(1981年)に記載されている。整合性を検査す
る処理は、主キ−に対する更新により対応する外部キ−
との整合性が正しく保持されているか否かを検査する処
理である。例えば、『部門』表に存在する主キ−は部門
デ−タを持つ列であって、ある行の部門デ−タを更新す
る場合には、更新対象となった部門デ−タの値が既に対
応する外部キ−、つまり『従業員』表の従業員の所属部
門として登録されている値に同じものがないことを検査
する処理である。また、『従業員』表に存在するある従
業員の所属が変わったとき、その従業員の所属部門を更
新する場合には、更新する所属部門の値が参照する主キ
−、つまり『部門』表の部門デ−タの値として存在する
ことを検査するものである。これらの検査をする処理
は、他にも主キ−を持つ表から行を削除する場合や、外
部キ−を持つ表に行を挿入する場合等にも、同じような
処理が必要となる。このようなデ−タベ−スのデ−タの
操作は、構造化紹介言語（ＳＱＬ）を使用するリレ−シ
ョナル・デ−タベ−ス管理システムでは、ＩＮＳＥＲＴ
文（行の挿入）、ＵＰＤＡＴＥ文（列の更新）、ＤＥＬ
ＥＴＥ文（行の削除）により行われる。従って、参照関
係にある表に対しては、上述のデ−タ操作が行われる
と、参照制約の検査が行われる必要がある。

【０００４】一方、ユ−ザが定義した参照制約の検査を
行うトランザクションは、実行時の性能にも問題があ
る。その１つは、ある表の主キ−値に対する更新が発生
する場合には、必ずその更新の前後に参照整合性の検査
を行うトランザクションを起動し、実行する必要があ
る。そのため、更新する表に対する入出力回数は、必ず
２回必要となる。本来は１回でよいにもかかわらず、ト
ランザクションが分れているために別々に入出力を発行
しなくてはならない。また、もし更新した後に参照制約
の検査を実施するトランザクションを実行して制約違反
となったときには、デ−タベ−スの更新を無効にするた
めの回復処理を行う必要があるというオ−バヘッドが課
されることになる。さらに、整合性の検査を行うトラン
ザクションは、デ−タベ−ス管理システムとの情報の授
受も多くなるので、それに伴ってデ−タベ−ス全体の処
理効率も低下することになる。このような効率の低下を
回避するために、参照制約が行われる。参照制約は、デ
−タベ−ス管理システムで整合性の検査とその維持が実
行されるので、デ−タベ−スシステムの処理効率が上が
る。また、参照整合性の検査をユ−ザの業務プログラム
が行うのではなく、デ−タベ−ス管理システムが行うの
で、確実な整合性を実現できる。なお、従来、参照整合
性をデ−タベ−ス管理システムで行う方法として、例え
ば特開平２−３９３７２号公報および特開平２−１１６
９７３号公報に開示されている方法がある。これらの公
報に開示されている方法は、２つの参照関係にある表間
の参照制約に関連する情報をオブジェクトとして作成
し、この参照関係にある表に対してデ−タ操作が行われ
る際に、そのオブジェクトをアクセスすることにより参
照制約の検査とその動作を効率的に行うものである。

【０００５】

【発明が解決しようとする課題】前述のように、従来の
方法では、（イ）リレ−ショナルデ−タベ−ス管理シス
テムに関連のある表に対して、予めデ−タの更新時に整
合性を保つ動作をユ−ザが定義して、これを実行する必
要があるので、非常に煩わしく、また確実なデ−タの整
合性を維持する方法が不十分であるという問題がある。
また、（ロ）デ−タベ−ス管理システム外で参照整合性
を実行するプログラムもあるが、ある主キ−の値を更新
する場合に、更新する表および参照関係にある表に対す
る入出力回数が増加するとともに、性能の面でも問題が
ある。そして、デ−タベ−ス管理システム外で参照整合
性を行うため、デ−タベ−ス管理システムとの間でデ−
タの授受が多くなって、デ−タベ−スシステムの処理効
率が低下する。さらに、（ハ）前述の特開平２−３９３
７２号公報、特開平２−１１６９７３号公報に開示され
た処理方法では、基本的にある更新操作を行ってから参
照整合性の検査を行うので、参照制約違反となるデ−タ
の操作を行った後に、そのデ−タの操作の回復処理また
は全てのデ−タの操作を無効にする処理、つまり徹回処
理を行う必要がある。また、これらの方法では、参照整
合性を維持するために、ある表と他の１つの関連を持つ
表との参照制約の情報を持つ関係記述子を設けて、ある
表のデ−タ操作時に関係記述子にアクセスして、関係記
述子にある参照制約による整合性を維持している。本発
明の第１の目的は、これら従来の課題を解決し、デ−タ
間の参照整合性を迅速に維持することが可能なデ−タベ
−ス管理方法およびシステムを提供することにある。本
発明の第２の目的は、デ−タの更新に伴う参照整合性の
検査回数を、必要最小限に抑えることの可能なデ−タベ
−ス管理方法およびシステムを提供することにある。

【０００６】

【課題を解決するための手段】上記目的を達成するた
め、本発明のデ−タベ−ス管理方法は、（イ）デ−タベ
−ス中の任意のデ−タを更新する場合に、デ−タとの内
容の一致を保つ整合性を維持させる必要がある他のデ−
タに対して、それぞれ整合性を維持させるための手続き
用処理モジュ−ルをデ−タベ−ス中に予め格納し、格納
位置に関する情報も格納し、任意のデ−タに対するデ−
タ操作を行う際、整合性を維持させる手続き用処理モジ
ュ−ルをデ−タベ−スから読み出して、手続き用処理モ
ジュ−ルを実行することに特徴がある。また、（ロ）手
続き用処理モジュ−ルは、任意のデ−タとの整合性を維
持させるための他のデ−タを挿入する場合に、挿入する
デ−タが任意のデ−タとの整合性を維持できることを検
査するプログラムモジュ−ルであることにも特徴があ
る。また、（ハ）手続き用処理モジュ−ルは、任意のデ
−タを削除する場合に、削除するデ−タとの整合性が維
持される必要のある他のデ−タが存在しないことを検査
するプログラムモジュ−ルであることにも特徴がある。
また、（ニ）手続き用処理モジュ−ルは、任意のデ−タ
との整合性が維持される必要のある他のデ−タを追加な
いし更新する場合に、追加ないし更新したデ−タと整合
性を維持することができるデ−タが存在することを検査
するプログラムモジュ−ルであることにも特徴がある。
また、（ホ）手続き用処理モジュ−ルは、任意のデ−タ
を削除する場合に、削除するデ−タと整合性を維持する
他のデ−タが存在すれば、デ−タも削除するプログラム
モジュ−ルであることにも特徴がある。また、（ヘ）手
続き用処理モジュ−ルは、任意のデ−タを削除する場合
に、削除するデ−タと整合性を維持する他のデ−タが存
在すれば、デ−タをナル値ないし予め外部より指定され
た値に更新するプログラムモジュ−ルであることにも特
徴がある。また、（ト）手続き用処理モジュ−ルは、任
意のデ−タを更新する場合に、更新するデ−タと整合性
を維持する他のデ−タが存在すれば、デ−タも同じデ−
タに更新するプログラムモジュ−ルであることにも特徴
がある。また、（チ）手続き用処理モジュ−ルは、任意
のデ−タを更新する場合に、更新するデ−タと整合性を
維持する他のデ−タが存在すれば、デ−タをナル値ない
し予め外部より指定された値に更新するプログラムモジ
ュ−ルであることにも特徴がある。また、（リ）デ−タ
ベ−ス中のデ−タ操作を行う場合に、操作の禁止条件を
含む指示を入力して、禁止条件を判定し、判定の結果、
操作が禁止されない場合には、操作を実行するが、判定
の結果、操作が禁止される場合には、操作を実行しない
ことを報告することにも特徴がある。また、（ヌ）禁止
条件は、任意のデ−タとの整合性が維持される必要のあ
る他のデ−タを挿入および更新する場合、挿入および更
新するデ−タが任意のデ−タに存在しなければ、操作を
禁止する条件であり、また禁止条件を含む指示は、挿入
および更新操作が行われる前ないし後に、挿入および更
新したデ−タが任意のデ−タに存在しなければ操作を禁
止する条件を判定する指示であることにも特徴がある。
また、（ル）操作の禁止条件は、任意のデ−タを更新す
る場合に、任意のデ−タと整合性を維持している他のデ
−タが存在すれば、任意のデ−タを更新する操作を禁止
する条件であり、禁止条件を含む指示は、任意のデ−タ
を更新する前ないし後に、任意のデ−タと整合性を維持
している他のデ−タが存在すれば、任意のデ−タを更新
する操作を禁止する条件を判定する指示であることにも
特徴がある。また、本発明のデ−タベ−ス管理システム
は、（ワ）デ−タベ−スと、デ−タベ−ス中の任意デ−
タの更新に伴い、任意デ−タとの整合性を維持する必要
のある他のデ−タに対する整合性維持のための手続き用
処理モジュ−ルを格納する制御手段と、該モジュ−ルを
格納する位置に関する情報を格納する制御手段と、任意
デ−タの更新に伴い、モジュ−ルを読み出して実行する
モジュ−ルとを具備することに特徴がある。

【０００７】

【作用】本発明においては、（ａ）デ−タベ−ス中のあ
るデ−タの更新に伴い、あるデ−タとの整合性を維持さ
れなければならない他のデ−タに対する整合性を維持す
るための手続きを、予めデ−タベ−スに格納しておく。
また、更新するデ−タに対応して整合性を維持するため
の手続きを格納する位置に関する情報を、格納位置を参
照して格納しておく。次に、デ−タの更新があると、そ
れに伴って格納位置を参照して対応する整合性を維持す
るための手続きをデ−タベ−スから読み出し、これを実
行する。これにより、整合性を維持するための処理を効
率よく実行できる。また、（ｂ）デ−タベ−ス中のデ−
タ操作が要求されたとき、そのデ−タ操作の禁止条件を
含む指示を作成する。次に、デ−タ操作の禁止条件を判
定する。判定の結果、禁止条件に該当しないときにはデ
−タ操作を実行するが、禁止条件に該当するときには、
デ−タ操作を実行しないことを報告する。その結果、デ
−タの整合性を検査する処理の回数を無駄に行うことな
く実行できる。さらに、この禁止条件の判定処理をデ−
タ操作の前に行うので、デ−タの整合性を検査する判定
処理を最小限にするのみならず、禁止条件に該当するデ
−タ操作を中止して、回復する処理の時間を短縮するこ
とができる。

【０００８】

【実施例】以下、本発明の実施例を、図面により詳細に
説明する。図２は、本発明の基本動作である３つの表の
参照関係図であり、図３、図４および図５は、それぞれ
図２における部門、従業員、プロジェクトの各表の内容
を示す図であり、図６は、図２における参照制約定義情
報を示す図である。３つの表である部門４、従業員５お
よびプロジェクト６は、３つの参照制約９１〜９６によ
り参照関係があることを示している。『部門』表４は、
図３に示すように、部門番号、部門名、管理者番号、所
属部門の列から構成されている。『従業員』表５は、図
４に示すように、従業員番号、従業員名、所属部門の列
から構成されている。また、『プロジェクト』表６は、
図５に示すように、プロジェクト番号、プロジェクト
名、担当部署、担当従業員番号、所属プロジェクト名の
列から構成されている。図２の各表４，５，６は、図６
に示す６つの参照制約９１〜９６により関係付けられて
いる。これらの参照制約の中には、自分自身の表に対す
る参照制約も含まれている（図６の９１，９６）。６つ
の参照制約の各々の制約の詳細は、図６から明らかであ
る。先ず、『部門』表の参照制約では、制約『制約１』
９１は『部門』表４の『所属部門』列が同じ『部門』表
４の『部門番号』列を参照することを制約する。このと
き、被参照列である『所属部門』列に対する更新規則は
ＲＥＳＴＲＩＣＴであり、参照する『部門番号』列の更
新時には更新対象となる値と同じ値を持つ『所属部門』
列が存在しない場合にのみ更新を許可することを規定し
ている。また、削除規則はＣＡＳＣＡＤＥであって、
『部門』表４から１行削除する場合には、削除する行に
含まれる『部門番号』列の値と同じ値を持つ『所属部
門』列があれば、その行も削除することを規定してい
る。ここで、『制約１』における主キ−は、『部門番
号』列であって、外部キ−は『所属部門』列である。

【０００９】次に、『制約２』９２は、『従業員』表５
の『所属部門』列が『部門』表４の『部門番号』列を参
照することを制約する。このとき、被参照列である『部
門番号』列に対する更新規則はＲＥＳＴＲＩＣＴであ
り、参照する『部門』表の『部門番号』列の更新時には
更新対象となる値と同じ値を持つ『従業員』表の『所属
部門』列が存在しない場合にのみ更新を許可することを
規定する。また、削除規則はＳＥＴＮＵＬＬであっ
て、『部門』表４から１行削除する場合、削除する行に
含まれる『部門番号』列があれば、その行の『所属部
門』列の値をＮＵＬＬ値（空値）に更新することを規定
する。ここで、『制約２』９２における主キ−は『部
門』表の『部門番号』列であり、外部キ−は『従業員』
表の『所属部門』列である。次に『制約』３は、『プロ
ジェクト』表６の『担当部署』列が『部門』表４の『部
門番号』列を参照することを制約する。このとき、被参
照列である『所属部門』列に対する更新規則はＲＥＳＴ
ＲＩＣＴであり、参照する『部門』表４の『部門番号』
列の更新時には更新対象となる値と同じ値を持つ『プロ
ジェクト』表６の『担当部署』があれば、その行は削除
できないことを規定する。ここで、『制約３』９３にお
ける主キ−は『部門』表４の『部門番号』列であり、外
部キ−は『プロジェクト』表６の『担当部署』列であ
る。

【００１０】次に、『制約４』９４は、『部門』表４の
『管理者番号』列が『従業員』表５の『従業員番号』列
を参照することを制約する。このとき、被参照列である
『従業員』表５の『従業員番号』列に対する更新規則は
ＲＥＳＴＲＩＣＴであって、参照する『従業員』表５の
『従業員番号』列の更新時には更新対象となる値と同じ
値を持つ『部門』表４の『管理者番号』列が存在しない
場合にのみ更新を許可することを規定する。また、削除
規則はＳＥＴＮＵＬＬであって、『従業員』表５から
１行削除する場合、削除する行に含まれる『従業員番
号』列の値と同じ値を持つ『部門』表４の『管理者番
号』列があれば、同じ値を持つ『部門』表４の『管理者
番号』列の値をＮＵＬＬ値（空値）に更新することを規
定する。ここで、『制約４』９４における主キ−は『従
業員』表５の『従業員番号』列であり、外部キ−は『部
門』表４の『管理者番号』列である。次に、『制約５』
９５は、『プロジェクト』表５の『担当従業員番号』列
が『従業員』表５の『従業員番号』列を参照することを
制約する。このとき、被参照列である『従業員』表５の
『従業員番号』列に対する更新規則はＲＥＳＴＲＩＣＴ
であり、参照する『プロジェクト』表６の『担当従業員
番号』列の更新時には、更新対象となる値と同じ値を持
つ『従業員』表５の『担当従業員番号』列が存在しない
場合のみ更新を許可することを規定する。また、削除規
則はＲＥＳＴＲＩＣＴであり、『従業員』表５から１行
削除する場合、削除する行に含まれる『従業員番号』列
の値と同じ値を持つ『プロジェクト』表６の『担当従業
員番号』列があれば、その行は削除できないことを規定
する。ここで、『制約５』９５における主キ−は『従業
員』表５の『従業員番号』列であり、外部キ−は『プロ
ジェクト』表６の『担当従業員番号』列である。

【００１１】次に、『制約６』９６は、『プロジェク
ト』表６の『所属プロジェクト番号』列が『プロジェク
ト』表６の『プロジェクト番号』列を参照することを制
約する。このとき、被参照列である『プロジェクト番
号』列に対する更新規則はＲＥＳＴＲＩＣＴであって、
参照する『プロジェクト番号』列の更新時には更新対象
となる値と同じ値を持つ『所属プロジェクト番号』列が
存在しない場合にのみ更新を許可することを規定する。
また、削除規則はＣＡＳＣＡＤＥであって、『プロジェ
クト』表６から１行削除する場合、削除する行に含まれ
る『プロジェクト番号』列の値と同じ値を持つ『所属プ
ロジェクト番号』列があれば、その行も削除することを
規定する。ここで、『制約６』９６における主キ−は
『プロジェクト番号』列であり、外部キ−は『所属プロ
ジェクト番号』列である。ところで、リレ−ショナル・
デ−タベ−スにおけるデ−タは、複数のタップル（行）
からなるリレ−ション（表）と呼ばれる論理的デ−タ構
造から構成されている。さらに、行は複数のカラム
（列）からなる。このようにして、デ−タベ−ス中に複
数の表が定義される。そして、複数の表が定義される場
合には、表相互間のデ−タの関連を定義する参照制約が
定義されることもある。参照制約を定義する場合、参照
制約を定義する表の１つないし複数の列で構成されるキ
−（外部キ−）を指定して、その外部キ−が参照する主
キ−を指定する。その際に、参照する表を参照表（外部
キ−を持つ表）と呼び、参照される表を被参照表（外部
キ−により参照される主キ−を持つ表）と呼ぶ。また、
参照制約を定義する場合、参照する主キ−のデ−タの操
作に伴う規則を指定することができ、その指定する規則
は、更新時の更新規則、行の削除時の削除規則を指定す
ることができる。

【００１２】また、さらに他の規則として、挿入規則が
ある。この挿入規則とは、指定することができない暗黙
の規則である。以下、これらの各規則について、ＩＳＯ
ＳＱＬ２の規則を基に補充説明する。ＳＱＬについて
は、写像型言語としてＳＱＵＡＲＥが先ず登場し、構文
をより利用者向けにしたＳＥＱＵＥＬが生れ、さらにシ
ステムＲの基本言語ＳＱＬに発展した。更新規則には、
４つのオプションが指定できる。これらのオプション
は、前述のように、ＣＡＳＣＡＤＥ、ＳＥＴＮＵＬ
Ｌ、ＳＥＴＤＥＦＡＵＬＴおよび指定しない場合の暗
黙の規則である。このうち、ＣＡＳＣＡＤＥでは、被参
照表の主キ−値を更新する際に、更新する対象となる値
と同じ値を持つ外部キ−が存在すると、その外部キ−値
も主キ−の更新値と同じ値に更新するように波及させ
る。次に、ＳＥＴＮＵＬＬでは、被参照表の主キ−値
を更新する際に、更新する対象となった値と同じ値を持
つ外部キ−が存在すると、その外部キ−値をＮＵＬＬ値
（空値）に更新を伝搬させる。次に、ＳＥＴＤＥＦＡ
ＵＬＴでは、ＳＥＴＮＵＬＬと同じく、予め定められ
た省略時の解釈値に更新する。また、オプションを指定
しないときには、被参照表の主キ−値を更新する際に、
更新する対象となった値と同じ値を持つ外部キ−が存在
するならば、被参照表の主キ−値は更新させないように
する。

【００１３】次に、削除規則の場合にも、更新規則と同
じように、４つのオプションを指定することができる。
先ず、ＣＡＳＣＡＤＥでは、被参照表の行を削除する場
合、削除する対象となった行の主キ−値と同じ値を持つ
外部キ−が存在すると、その外部キ−値を持つ行も削除
するように波及させる。次に、ＳＥＴＮＵＬＬでは、
被参照表の行を削除する場合、削除する対象となった行
の主キ−値と同じ値を持つ外部キ−が存在すると、その
外部キ−値をＮＵＬＬ値（空値）に更新するように伝搬
させる。また、ＳＥＴＤＥＦＡＵＬＴでは、被参照表
の行を削除する場合、削除する対象となった行の主キ−
値と同じ値を持つ外部キ−が存在すると、その外部キ−
値を予め定められた省略時解釈値に更新するように波及
させる。さらに、オプションを指定しない場合には、被
参照表の行を削除するとき、削除する対象となった行の
主キ−値と同じ値を持つ外部キ−が存在するならば、被
参照表の行は削除させないようにする。さらに、暗黙の
挿入規則では、オプションを指定できないが参照表に行
を挿入する際には、挿入する行に含まれる全ての外部キ
−値が、それぞれ参照する被参照表の主キ−値に同じ値
が存在するときには、挿入することができるようにす
る。

【００１４】図１は、本発明の第１の実施例を示すデ−
タベ−ス管理システムのブロック構成図であり、図７
は、図１のデ−タ操作を実行するデ−タベ−ス管理シス
テムの機能構成図であり、図８は図７の機能ブロックを
実現するためのハ−ドウェア構成図である。以上に述べ
た基本原理を基に、図１の実施例を述べる。本発明のデ
−タベ−ス管理方法は、図１に示すように、複数の処理
手続き（１〜４）５０，６０，７０，８０があり、それ
らの中に各々、実行内容５２，６２，７２，８２があ
り、それらの実行内容５２，６２，７２，８２は制約１
〜制約３によって制約がかけられている。例えば、処理
手続き（１）５０には制約５４があり、そこにはポイン
タ５５が格納され、処理手続き（２）６０の先頭アドレ
スが格納されている。また、制約（２）５６、制約
（３）５８の各ポインタ５７，５９にはそれぞれ処理手
続き（３）および処理手続き（４）８０の先頭アドレス
が格納されている。同じようにして、処理手続き（２）
６０には制約６４，６６，６８があり、それらのポイン
タ６５，６７，６９にはそれぞれ処理手続き（２）６
０、（３）７０，（４）８０の各先頭アドレスが格納さ
れている。

【００１５】図７において、デ−タベ−ス管理システム
７は、ユ−ザからの問合わせ、つまりＳＱＬ文の構文解
析、意味解析処理を行う構文・意味解析処理１０を行っ
た後、与えられた問合わせがデ−タの操作および検索を
行うために最適なアクセスパスを決定する処理１２を実
行する。次に、決定したアクセスパスをデ−タベ−ス管
理システムに特有の内部処理手続きを生成する処理手続
き生成処理１４を実行する。次に、生成した処理手続き
を実行する処理の正誤を判定し、補正を行う処理手続き
実行処理１６を行い、実行している処理手続きの基本的
な処理単位であるデ−タベ−スに対するアクセス、つま
りデ−タベ−スのスキャン処理、デ−タ操作（更新、削
除、挿入）を行うデ−タベ−ス操作処理１８を行い、最
後にデ−タベ−ス８中の表の行を格納する最小単位であ
るペ−ジの入出力処理を効率よく行うためのバッファ管
理２０を実行する。また、構文・意味解析処理１０にお
いてデ−タベ−スの定義に関する問合わせが発行された
場合には、定義系の処理２２を行う。また、定義に関す
る情報が格納されているディクショナリ９に対して、デ
ィクショナリ情報の管理をディクショナリ維持管理２４
が行う。これらの処理１０〜２４は、それぞれプログラ
ム処理モジュ−ルであって、いずれも図８の外部記憶装
置３に蓄積されている。デ−タベ−ス８には、部門４、
従業員５、およびプロジェクト６の各表が格納されてい
る。また、ディクショナリ９には、ディクショナリ９を
構成するテ−ブル９０が格納されている。次に、本発明
のデ−タベ−ス管理システムは、図８に示すように、Ｃ
ＰＵ１と主記憶装置２と外部記憶装置３から構成されて
いる。ＣＰＵ１は、デ−タ演算およびシステム内の各装
置を制御する役目を果す。また、主記憶装置２は、ＣＰ
Ｕ１が実行する図７におけるデ−タベ−ス理システム７
内の各プログラム処理モジュ−ルおよび各種デ−タを記
憶する。さらに、外部記憶装置３は、図７におけるデ−
タベ−ス管理システム７が管理するデ−タベ−ス８およ
びディクショナリ９を格納するものである。

【００１６】図９，図１０は、図７における定義系解析
処理の手順を示す処理フロ−チャ−トである。図７のデ
−タベ−ス管理システム７において、ユ−ザから入力さ
れた問合わせが定義系の場合には、問合わせの構文・意
味解析処理１０から定義系解析処理２２に制御が渡され
る。この定義系解析処理２２の処理は、図９に示すよう
に、スキ−マ定義、表定義、スキ−マ削除および表削除
の各処理に分けられる。すなわち、この定義系解析２２
には、デ−タベ−スのスキ−マや表の定義等を行う問合
わせと逆に、スキ−マや表を削除する問合わせがある。
ここで、デ−タベ−ス全体の論理的な構造と内容との記
述をスキ−マ（ｓｃｈｅｍａ）という。先ず、問合わせ
がスキ−マ定義であるか否かを判定し（ステップ２２
１）、スキ−マ定義であれば、スキ−マの登録処理を行
う（ステップ２２２）。スキ−マの登録処理では、ディ
クショナリ９への登録を行うための図７におけるディク
ショナリ維持管理２４へ制御を渡すことになる。次に、
スキ−マ定義でない場合には、表定義であるか否かを調
べて（ステップ２２３）、表定義であれば表定義法に従
って登録処理を行う表定義処理に制御を渡す（ステップ
２２４）。表の登録処理では、ディクショナリへの登録
を行うために、図７に示すディクショナリ維持管理部２
４に制御を渡すことになる。具体的に、表の定義を図２
の３つの表の関係を例にとって、ＳＱＬ文により表定義
を説明する。図２の３つの表のうち、『部門』表４を定
義するＳＱＬ文は、次のように記述される。記ＣＲＥＡＴＥＴＡＢＬＥ部門（部門番号ＣＨＡＲ（１０），部門名ＮＣＨＡＲ（１０），管理者番号ＣＨＡＲ（１０），所属部門ＣＨＡＲ（１０））ＰＲＩＭＡＲＹＫＥＹ（部門番号）ＦＯＲＥＩＧＮＫＥＹ（管理者番号）ＲＥＦＥＲＥＮＣＥＳ従業員ＯＮＤＥＬＥＴＥＳＥＴＮＵＬＬＣＯＮＳＴＲＡＲＩＮＴ制約４・・・・・・・・・・（１）

【００１７】上記ＣＲＥＡＴＥ文を解析して、表の定義
情報である表識別子や列定義情報をディクショナリに登
録する。そして、ＦＯＲＥＩＧＮＫＥＹ句が指定され
ていると、各制約の内容を解析して、参照制約による整
合性を維持するための処理手続きを生成するために、参
照制約処理手続き生成処理に制御を渡す（ステップ２２
５，２２６）。次に、ステップ２２３で問合わせが表定
義でなければ、スキ−マ削除（ＤＲＯＰＳＣＨＥＭ
Ａ）であるか否かを調べて（ステップ２２７）、スキ−
マ削除の場合にはスキ−マの削除処理を行う（ステップ
２２８）。スキ−マ削除処理では、スキ−マ中に既に表
が存在すれば、その表も削除する。さらに、表について
の参照制約定義があれば参照制約の定義情報も削除す
る。ステップ２２７で、問合わせがスキ−マ削除でなけ
れば、表削除（ＤＲＯＰＴＡＢＬＥ文）であるか否かを
調べ（ステップ２２９）、表削除の場合には、表の定義
情報を削除する処理へ制御を渡す（ステップ２３０）。
表の削除処理では、ディクショナリ９からの表の定義情
報を削除するために、図７におけるディクショナリ維持
管理部２４に制御を渡すことになる。そして、既に表中
にデ−タが格納されていれば、表中のデ−タも全て削除
することになる。次に、削除する表中に参照制約定義が
あるか否かを調べ（ステップ２３１）、参照制約定義が
あれば、各参照制約により作成した参照整合性を実施す
るための処理手続きの削除を行う処理に制御を渡す（ス
テップ２３２）。

【００１８】図１１、図１２は、本発明の特徴的な処理
である図９のステップ２２６の参照制約処理手続き生成
処理の詳細フロ−チャ−トである。参照制約処理手続き
生成処理部２２６では、指定された更新規則および削除
規則と暗黙の挿入規則について、各々参照整合性を実施
する処理手続きを生成するものである。先ず、更新規則
が指定されているか否かを調べ（ステップ２２６１）、
更新規則が指定された場合には、次にオプションの内容
を調べる。指定されたオプションがＣＡＳＣＡＤＥであ
るか否かを調べ（ステップ２２６２）、ＣＡＳＣＡＤＥ
であれば、その参照制約を定義した外部キ−が参照する
主キ−値の更新を波及させるための波及更新処理手続き
を生成する（ステップ２２６３）。いま、図３に示す
『部門』表４の『所属部門』列に対して更新規則がＣＡ
ＳＣＡＤＥである場合を仮定して説明する。『所属部
門』列に対して指定する参照制約は同じ『部門』表を参
照する自己参照となっている。この場合、指定する参照
制約は、次のように定義される。ＦＯＲＥＩＧＮＫＥＹ（所属部門）ＲＥＦＥＲＥＮＣＥＳ部門ＯＮＵＰＤＡＴＥＣＡＳＣＡＤＥ・・・・・・・・・・（２）

【００１９】上記参照制約により更新規則のオプション
にＣＡＳＣＡＤＥが指定されると、主キ−値の更新によ
り外部キ−である『所属部門』列も更新するという処理
手続きを生成する。この処理手続きをＳＱＬのＵＰＤＡ
ＴＥ文で示すと、次のようなＳＱＬ文となる。ＵＰＤＡＴＥ部門ＳＥＴ所属部門＝『部門番号』列更新値ＷＨＥＲＥ所属部門＝『部門番号』列更新前値・・・・・・・・・・・（３）上記ＳＱＬ文をデ−タベ−ス管理システムが実行する内
部処理手続き（中間言語）として生成する。この処理手
続きには、２つの変数である『部門番号』列更新値と更
新前値が含まれる。この変数は、『部門』表に対するデ
−タ操作において抽出され、この内部処理手続きに引数
として渡されることになる。次に、オプションがＣＡＳ
ＣＡＤＥでない場合には、ＳＥＴＮＵＬＬであるか否
かを調べ（ステップ２２６４）、ＳＥＴＮＵＬＬであ
れば、その参照制約を定義した外部キ−が参照する主キ
−値の更新により、更新前の主キ−値と同じ値を持つ外
部キ−値をＮＵＬＬ値に更新するＮＵＬＬ値更新処理手
続きを生成する（ステップ２２６５）。上記ＣＡＳＣＡ
ＤＥのときの例を、ＳＥＴＮＵＬＬに替えた場合の処
理手続きをＳＱＬ文のＵＰＤＡＴＥ文で示すと、次のよ
うになる。ＵＰＤＡＴＥ部門ＳＥＴ所属部門＝ＮＵＬＬＷＨＥＲＥ所属部門＝『部門番号』列更新前値・・・・・・・・・（４）

【００２０】上記ＳＱＬ文を、デ−タベ−ス管理システ
ムが実行する内部処理手続き（中間言語）として生成す
る。この処理手続きには、１つの変数である『部門番
号』列の更新前値が含まれる。この変数は、『部門』表
４に対するデ−タ操作において抽出され、この内部処理
手続きに引数として渡されることになる。さらに、オプ
ションがＳＥＴＮＵＬＬでないときには、ＳＥＴＤ
ＥＦＡＵＬＴであるか否かを調べ（ステップ２２６
６）、ＳＥＴＤＥＦＡＵＬＴであれば、この参照制約
を定義した外部キ−値を予め指定された省略時解釈値に
更新する省略時解釈値更新処理手続きを生成する（ステ
ップ２２６７）。ＣＡＳＣＡＤＥのときの例を、ＳＥＴ
ＤＥＦＡＵＬＴに替えた場合の処理手続きを、ＳＱＬ
文のＵＰＤＡＴＥ文で示すと、次のようになる。ＵＰＤＡＴＥ部門ＳＥＴ所属部門＝省略時解釈値ＷＨＥＲＥ所属部門＝『部門番号』列更新前値・・・・・・・・・・（５）

【００２１】上記ＳＱＬ文をデ−タベ−ス管理システム
が実行する内部処理手続き（中間言語）として生成す
る。この処理手続きには、１つの変数である『部門番
号』列の更新前値が含まれる。この変数は、『部門』表
４に対するデ−タ操作において抽出され、この内部処理
手続きに引数として渡されることになる。また、省略時
解釈値は、必ず参照する主キ−値に存在する値であるこ
とが前提となる。ステップ２２６６で、この更新規則に
おけるオプションが指定されなかったときには、これま
でのオプションと異なって、表間の整合性を検出しない
ことを解査する処理を生成する（ステップ２２６８）。
すなわち、整合性検査処理手続きでは、主キ−の更新に
より参照する外部キ−値を更新するか否かではなく、主
キ−を更新する前に更新前の値と同じ値を持つ外部キ−
が存在しないことを検査する必要がある。この整合性を
検査する処理を処理手続きとして生成する。この処理手
続きをＳＱＬ文のＳＥＬＥＣＴ文で示すと、次のように
なる。ＳＥＬＥＣＴ＊ＦＲＯＭ部門ＷＨＥＲＥ所属部門＝『部門番号』列更新前値・・・・・・・・・（６）

【００２２】上記ＳＱＬ文をデ−タベ−ス管理システム
が実行する内部処理手続き（中間言語）として生成す
る。この処理手続きには、１つの変数である『部門番
号』列の更新前値が含まれる。この変数は、『部門』表
４に対するデ−タ操作において抽出され、この内部処理
手続きに引数として渡されることになる。ステップ２２
６１により、更新規則でなければ、削除規則について各
々指定されたオプションであると判定する。すなわち、
指定されたオプションがＣＡＳＣＡＤＥであるか否かを
調べ（ステップ２２６９）、ＣＡＳＣＡＤＥであるとき
には、この参照制約を定義した外部キ−が参照する被参
照表の行を削除するときに削除される行の主キ−値と同
じ値を持つ行も同時に削除するように、波及させるため
の波及削除処理手続きを生成する（ステップ２２７
０）。ここでは、図３に示す『部門』表４の『所属部
門』列に対して削除規則がＣＡＳＣＡＤＥである場合に
ついて説明する。この制約は、図６の『制約１』９１に
対する削除規則である。『所属部門』列に対して指定す
る参照制約は同じ『部門』表４を参照する自己参照とな
っている。このときに、指定する参照制約は、次のよう
に定義される。ＦＯＲＥＩＧＮＫＥＹ（所属部門）ＲＥＦＥＲＥＮＣＥＳ部門ＯＮＤＥＬＥＴＥＣＡＳＣＡＤＥ・・・・・・・・・・・・・・（７）

【００２３】上記参照制約で削除規則のオプションにＣ
ＡＳＣＡＤＥが指定されると、参照している『部門』表
からの行の削除により、削除される行の主キ−値と同じ
値を持つ外部キ−の行も削除するという処理手続きを生
成する。この処理手続きをＳＱＬのＤＥＬＥＴＥ文で示
すと、次のようになる。ＤＥＬＥＴＥＦＲＯＭ部門ＷＨＥＲＥ所属部門＝『部門番号』列削除対象値・・・・・・・・・・（８）

【００２４】上記ＳＱＬ文をデ−タベ−ス管理システム
が実行する内部処理手続き（中間言語）として生成す
る。この処理手続きには、１つの変数である『部門番
号』列削除対象値が含まれる。この変数は、『部門』表
４に対するデ−タ操作において抽出され、この内部処理
手続きに引数として渡されることになる。次に、オプシ
ョンがＣＡＳＣＡＤＥでないときには、ＳＥＴＮＵＬ
Ｌであるか否かを調べ（ステップ２２７１）、ＳＥＴ
ＮＵＬＬであれば、この参照制約を定義した外部キ−が
参照する参照中の『部門』表４からの行の削除により、
削除される行の主キ−値と同じ値を持つ外部キ−値をＮ
ＵＬＬ値に更新するＮＵＬＬ値更新処理手続きを生成す
る（ステップ２２７２）。上記ＣＳＣＡＤＥのときの例
を、ＳＥＴＮＵＬＬに替えた場合の処理手続きをＳＱ
Ｌ文のＵＰＤＡＴＥ文で示すと、次のようになる。ＵＰＤＡＴＥ部門ＳＥＴ所属部門＝ＮＵＬＬＷＨＥＲＥ所属部門＝『部門番号』列削除対象値・・・・・・・・・（９）

【００２５】上記ＳＱＬ文をデ−タベ−ス管理システム
が実行する内部処理手続き（中間言語）として生成す
る。この処理手続きには、１つの変数である『部門番
号』列の更新前値が含まれている。この変数は、『部
門』表４に対するデ−タ操作において抽出され、この内
部処理手続きに引数として渡されることになる。さら
に、オプションがＳＥＴＮＵＬＬでなければ、ＳＥＴ
ＤＥＦＡＵＬＴであるか否かを調べ（ステップ２２７
３）、ＳＥＴＤＥＦＡＵＬＴであれば、この参照制約
を定義した外部キ−が参照する参照中の『部門』表４か
らの行の削除により、削除される行の主キ−値と同じ値
を持つ外部キ−値を予め指定された省略時解釈値に更新
する省略時解釈値更新処理手続きを生成する（ステップ
２２７４）。前記ＣＡＳＣＡＤＥのときの例を、ＳＥＴ
ＤＥＦＡＵＬＴに替えた場合の処理手続きをＳＱＬ文
のＵＰＤＡＴＥ文で示すと、次のようになる。ＵＰＤＡＴＥ部門ＳＥＴ所属部門＝省略時解釈値ＷＨＥＲＥ所属部門＝『部門番号』列削除対象値・・・・・・・・・（10)

【００２６】上記ＳＱＬ文をデ−タベ−ス管理システム
が実行する内部処理手続き（中間言語）として生成す
る。この処理手続きには、１つの変数である『部門番
号』列の更新前値が含まれる。この変数は、『部門』表
４に対するデ−タ操作において抽出され、この内部処理
手続きに引数として渡されることになる。また、省略時
解釈値は、必ず参照する主キ−値に存在する値であるこ
とが前提となる。ステップ２２７３で、この削除規則に
おけるオプションが指定されなかったとき、これまでの
オプションとは異なって、表間の整合性を検出しないこ
とを検査する処理を生成する（ステップ２２７５）。す
なわち、参照している『部門』表４からの行の削除によ
り、削除される行の主キ−値と同じ値を持つ外部キ−が
存在しないことを検査する必要がある。この整合性を検
査する処理を、処理手続きとして生成するのである。こ
の処理手続きをＳＱＬ文のＳＥＬＥＣＴ文で示すと、次
のようになる。ＳＥＬＥＣＴ＊ＦＲＯＭ部門ＷＨＥＲＥ所属部門＝『部門番号』列削除対象値・・・・・・・・（11)

【００２７】上記ＳＱＬ文をデ−タベ−ス管理システム
が実行する内部処理手続き（中間言語）として生成す
る。この処理手続きには、１つの変数である『部門番
号』列の削除対象値が含まれる。この変数は、『部門』
表４に対するデ−タ操作において抽出され、この内部処
理手続きに引数として渡されることになる。次に、実際
のデ−タ操作を例にとり、全体のデ−タ操作処理の流れ
を、図１と図７により詳述する。先ず、『部門』表４か
ら行を削除する場合の処理について述べる。デ−タ操作
を行う問合わせは、次のようなＳＱＬ文で行う。ＤＥＬＥＴＥＦＲＯＭ部門ＷＨＥＲＥ部門番号＝削除対象値・・・・・・・・・・・・・・・・（12）

【００２８】上記ＳＱＬ文が発行されると、先ず図７に
おける構文・意味解析処理１０で、ＤＥＬＥＴＥ文の文
法や意味上の解析処理が行われる。このとき、『部門』
表４に対するデ−タ操作であって、この表の主キ−を参
照する外部キ−、つまり参照制約が存在するので、この
参照制約に関する情報を図７のディクショナリ９から整
合性を維持するための手続きに関する情報を取り出して
おく。次に、アクセスバス決定処理１２で、そのＤＥＬ
ＥＴＥ文の実行方法として、指定された削除する行の探
索条件からデ−タベ−スのアクセス手順を決定する。次
に、処理手続き生成処理１４では、決定されたアクセス
手順を基にしてデ−タベ−ス管理システムが実行できる
形式に変換するために、このＤＥＬＥＴＥ文に対応する
処理手続きを生成する。次に、処理手続き実行処理１６
において、前段で生成された処理手続きを基に、インタ
プリティブにデ−タ操作を実行する。ここで、生成され
た処理手続きは、図１に示す処理手続き５０として実行
される。図１において、処理手続き５０の中には、前の
構文・意味解析処理１０において整合性を維持するため
の手続きに関する情報として、制約（１）５４、制約
（２）５６、制約（３）５８の情報が組み込まれてい
る。各情報５４，５６，５８には、整合性を維持するた
めの手続きが格納されている位置に関する情報が含まれ
ている。すなわち、制約５４には、その制約による整合
性を維持するための手続きとして、処理手続き（２）６
０の先頭アドレスが格納されている。また、制約５６に
は、その制約による整合性を維持するための手続きとし
て、処理手続き（３）７０の先頭アドレスが格納されて
いる。さらに、制約５８には、その制約による整合性を
維持するための手続きとして、処理手続き（４）８０の
先頭アドレスが格納されている。処理手続き実行処理１
６は、生成された手続きの処理内容を調べて、削除処理
であることが判明すると、図１２に示す削除処理手続き
実行処理の流れに従って、インタプリティブ（解釈的）
に実行される。

【００２９】図１４は、削除処理手続き実行処理の動作
フロ−チャ−トである。削除処理手続き実行処理２８で
は、図１４に示すように、行削除処理において削除の対
象となる行を図７のデ−タベ−ス操作処理１８およびバ
ッファ管理２０を通じて探索し、条件を満足する行を１
行だけ削除する（ステップ２８１）。そして、削除され
た行に対して、その行の主キ−を参照する参照表がある
か否かを調べる（ステップ２８２）。参照表があるか否
かについては、その処理手続き中に格納されている制約
情報の有無により判定される。この処理手続き（１）５
０の場合、３つの参照表があるので、各々の制約につい
て整合性を維持するための処理手続きを呼び出し、これ
らを実行する（ステップ２８３，２８４）。先ず、制約
１について、整合性を維持するための手続きを呼出し、
これを実行する。制約情報５４には、この整合性を維持
するための手続きを格納する位置に関する情報５５を参
照して、処理手続き（２）６０をディクショナリ９から
呼出し、実行する。制約１は、削除対象となった行の主
キ−値と同じ値を持つ同じ表の外部キ−である所属部門
列があれば、その行を削除するものである。これを実行
するための処理手続き（２）６０は、その手続きの実行
内容がメモリ６２に格納されており、再帰的に処理手続
き実行処理部１６で実行される。この整合性を維持する
ための手続きも、図１４に示す処理フロ−に従って実行
される。制約１の場合には、参照制約が自己の表に対す
る制約のために、処理手続き（２）６０が主キ−の削除
により順次波及されて、再帰的に実行される。しかし、
常に動作が波及される毎に、その処理手続きがディクシ
ョナリ９から呼出されるのではなく、一旦呼出された手
続きを再利用する。

【００３０】図１５，図１６は、更新処理手続き実行処
理の動作フロ−チャ−トである。次に、制約１について
処理が終了すると、制約２についても同じように整合性
を維持するための手続きを呼出し、これを実行する。制
約２は、削除対象となった行の主キ−値と同じ値を持つ
『従業員』表５の外部キ−列である『所属部門』列があ
れば、その行の『所属部門』列の値をＮＵＬＬ値（空
値）に更新する。これを実行するための『処理手続き
（３）』７０には、その手続きの実行内容がメモリ７２
に格納される。この整合性を維持するための手続きは、
更新処理であるため、図１５に示す更新処理手続き実行
処理３０の処理に従って実行される。先ず、『部門』表
４で削除対象となった行の『所属部門』列の値が引数と
して渡され、渡された引数をその処理手続きの探索条件
に用いて、『従業員』表５の『所属部門』列で同じ値を
持つ行を探索し、同じ値を持つ行の『所属部門』列の値
をＮＵＬＬ値に更新する（ステップ３０１）。更新後に
は、この更新が主キ−の更新か否かを調べて（ステップ
３０２）、この処理手続き（３）７０には整合性を維持
するための制約がないため、さらに外部キ−の更新か否
かを調べる（ステップ３０８）。この手続きは、外部キ
−の更新であるが、この処理手続き中に整合性を維持す
るための手続きに関する情報が含まれていないため、こ
のまま処理を終了する。さらに、制約２の処理が終了す
ると、最後の制約３について同じように整合性を維持す
るための手続きを呼出し、実行する。制約３は、削除対
象となった行の主キ−値と同じ値を持つ『プロジェク
ト』表６の外部キ−である『担当部署』列に同じ値を持
つ行が存在するか否かを検索する。存在する場合には、
制約違反として処理手続き１による『部門』表４からの
行の削除処理を中止して、制約違反が発生したことを報
告する。

【００３１】これを実行するための『処理手続き
（４）』８０には、その手続きの実行内容がメモリ８２
に格納されている。この整合性を維持するための手続き
は、検索処理であって、特にフロ−としては示してない
が、『部門』表４で削除対象となった行の『所属部門』
列の値が引数として渡され、渡された引数をこの処理手
続きの探索条件として用い、該当する行が存在するか否
か検索する。検索の結果は、探索条件を満足する行が存
在すれば、制約違反となり、探索条件を満足する行が存
在しなければ、『部門』表４からの行の削除を実行可能
とする。制約違反になると、処理手続き（４）８０の結
果が処理手続き（１）４０に返却され、図１４において
制約違反が発生したか否かを調べる（ステップ２８
５）。制約違反があると、その処理手続きの処理を中断
して、ロ−ルバックする処理を行った後、処理を終了す
る。次に、『従業員』表５への行の挿入を例にとり説明
する。例えば、『従業員』表５への行の挿入を行うＳＱ
Ｌ文は、次のように記述される。ＩＮＳＥＲＴＩＮＴＯ従業員ＶＡＬＵＥＳ（‘０００１５’，‘萩野政雄’，‘９５１０１’）・・・・・・・・・・・・・・・・（13)

【００３２】上記ＳＱＬ文が発行されると、先ず図７に
示す構文・意味解析処理１０で、ＩＮＳＥＲＴ文の文法
や意味上の解析処理が行われる。このとき、『従業員』
表５に対するデ−タ操作であって、その表５には外部キ
−つまり参照制約が存在するため、この参照制約に関す
る情報を、図７のディクショナリ９から整合性を維持す
るための手続きに関する情報を取り出しておく。次に、
アクセスパス決定処理１２で、このＩＮＳＥＲＴ文の実
行方法として指定された行を挿入するためのデ−タベ−
スのアクセス手順を決定する。そして、決定されたアク
セス手順を基にしてデ−タベ−ス管理システムが実行で
きる形式に変換するため、処理手続き生成処理１４でこ
のＩＮＳＥＲＴ文に対応する処理手続きを生成する。こ
のようにして生成された処理手続きを基にして、処理手
続き実行処理１６がインタプリティブにデ−タ操作を実
行する。図１３、図１４に戻って、先ず行を挿入するペ
−ジを割り当てる（ステップ２６１）。次に、割り当て
たペ−ジに対して行を挿入する処理を、図７に示すデ−
タ操作処理１８に対して要求し、行を挿入する（ステッ
プ２６２）。次に、この挿入表には、参照制約があるか
否かを調べて（ステップ２６３）、参照制約があるとき
には、参照制約数分以下の処理を繰り返す（ステップ２
６４）。この処理手続き中には、前の構文・意順解析処
理１０で整合性を維持するための手続きに関する情報と
して、制約２の情報が組み込まれている。制約２には、
整合性を維持するための手続きが格納されている位置の
情報が含まれている。このＳＱＬ文はＩＮＳＥＲＴ文で
あるため、この場合の整合性を維持するための手続きと
は、暗黙の挿入規則に基づいた手続きであって、挿入す
る行に含まれる『所属部門』列に相当する値が参照する
『部門』表４の主キ−である『所属部門』列に同じ値を
持つものが存在するか否かを検索する。先ず、この処理
手続き中に含まれる参照制約の情報を参照し、整合性を
維持するための手続きをディクショナリ９から読み出
し、これを実行する（ステップ２６５）。次に、整合性
を維持するための手続きを実行した結果、制約違反とな
ったか否かを調べて（ステップ２６６）、制約違反とな
った場合には、処理中断としてロ−ルバック処理を行
い、処理を終了する。

【００３３】図１７は、本発明の第２の実施例を示すデ
−タベ−ス管理システムの全体構成図である。図１７に
おいて、１０はデ−タベ−ス管理システム７に対して要
求される問合わせ文の構文のチェックと、意味上の解析
処理を行う構文・意味解析処理部、３２は正しく解析さ
れたデ−タ操作の問合せ文に参照制約の定義が含まれて
いるとき、そのデ−タ操作の禁止条件を付加するデ−タ
操作禁止条件付加処理部、１４以降の他のモジュ−ル
は、図７で示した構成と同じであるので、説明を省略す
る。この実施例では、前述の参照制約の定義時に更新規
則および削除規則を指定しない場合の暗黙の規則の場合
に適用される。先ず、更新について説明する。『従業
員』表５の『所属部門』列を更新する場合を考えると、
この場合のＳＱＬ文は次のように要求される。ＵＰＤＡＴＥ従業員ＳＥＴ所属部門＝更新値ＷＨＥＲＥ従業員番号＝更新対象値・・・・・・・・・・・・・・（14)

【００３４】上記ＳＱＬ文が発行されると、構文・意味
解析処理部１０で、このＵＰＤＡＴＥ文の文法上のチェ
ックと意味上の解析処理が行われる。意味解析時に、デ
ィクショナリ９を参照することにより、『従業員』表５
の『所属部門』列は外部キ−であることが判る。次に、
解析されたＵＰＤＡＴＥ文に対してデ−タ操作の禁止条
件を付加するために、デ−タ操作禁止条件付加処理部３
２に制御を渡す。図１８は、本実施例におけるデ−タ操
作禁止条件付加処理部３２の処理のフロ−チャ−トであ
り、図１９は、同じくデ−タ操作禁止条件生成の処理フ
ロ−チャ−トである。先ず、『従業員』表５の『所属部
門』列が参照する『部門』表４の定義情報を予め取り出
しておく（ステップ３２１）。次に、デ−タ操作を禁止
するための条件を生成する（ステップ３２２）。デ−タ
操作禁止条件の生成処理３２２の詳細なフロ−は、図１
９に示す通りである。先ず、要求されたＳＱＬ文が主キ
−の更新か、あるいは削除かを調べる（ステップ３２２
１）。この場合には、条件に合致しないので、次に外部
キ−値の更新か挿入かを調べる（ステップ３２２９）。
この場合、要求されたＵＰＤＡＴＥ文は外部キ−の更新
であることが判明する。そして、デ−タ操作禁止条件の
生成を参照制約数分繰り返すようにする（ステップ３３
３０）。先ず、更新する外部キ−値が存在するか否かを
調べるために、ＳＱＬ文の副問合わせの述語に見られる
存在比較子であるＥＸＩＳＴＳ述語を生成する（ステッ
プ３３３１）。そして、ＳＥＬＥＣＴ節を生成し（ステ
ップ３２３２）、射影する項目は特に指定する必要がな
い。次に、ＦＲＯＭ節を生成して、検索の対象となる表
は『部門』表４とする（ステップ３３３３）。次に、Ｗ
ＨＥＲＥ節を生成して、探索条件としては『部門』表４
の『所属部門』列に対する等号条件で比較する値は外部
キ−更新値を指定する（ステップ３３３４）。これらを
生成し終ると、全ての参照制約についての禁止条件の生
成を終了したか否かを調べて（ステップ３３３５）、終
了したならばその処理を終了する。このようにして、Ｕ
ＰＤＡＴＥ文は次のようにデ−タ操作禁止条件が付加さ
れたものとなる。ＵＰＤＡＴＥ従業員ＳＥＴ所属部門＝更新値ＷＨＥＲＥ従業員番号＝更新対象値ＡＮＤＥＸＩＳＴＳ（ＳＥＬＥＣＴ＊ＦＲＯＭ部門ＷＨＥＲＥ所属部門＝更新値）・・・・・・・・・・・・（15)

【００３５】次に、主キ−を更新する場合について説明
する。『従業員』表５の『従業員番号』列を更新する場
合には、このＳＱＬ文は例えば次のように要求される。ＵＰＤＡＴＥ従業員ＳＥＴ従業員番号＝更新値ＷＨＥＲＥ従業員番号＝更新対象値・・・・・・・・・・・・・・（16）上記ＳＱＬ文が発行されると、構文・意味解析処理部１
０で、このＵＰＤＡＴＥ文の文法上のチェックと意味上
の解析処理を実行する。ここで、意味解析時にディクシ
ョナリ９を参照することにより、この『従業員』表５の
『従業員番号』列は主キ−であることが判る。次に、解
析されたＵＰＤＡＴＥ文に対してデ−タ操作の禁止条件
を付加するために、デ−タ操作禁止条件付加処理部３２
に制御を渡す。図１８、図１９において、先ず『従業
員』表５の『従業員番号』列を参照する『部門』表４お
よび『プロジェクト』表６の参照制約定義情報を予め取
り出しておく（ステップ３２１）。次に、デ−タ操作を
禁止するための条件を生成する（ステップ３２２）。デ
−タ操作禁止条件の生成処理では、図１９に示すよう
に、先ず、要求されたＳＱＬ文が主キ−の更新か、ある
いは削除かを調べる（ステップ３２２１）。この場合に
は、この条件を満足するので、要求されたＵＰＤＡＴＥ
文は主キ−の更新であることが判明する（ステップ３２
２１）。そして、デ−タ操作禁止条件の生成を参照制約
数分繰り返すようにする（ステップ３２２２）。

【００３６】次に、更新前の主キ−値と同じ値を持つ外
部キ−値が存在しないことを調べるため、ＳＱＬ文の副
問合わせの述語に見られる存在比較子であるＮＯＴＥ
ＸＩＳＴＳ述語を生成する（ステップ３２２３）。次
に、ＮＯＴＥＸＩＳＴＳ述語で評価する副問合わせの
ＳＱＬ文を生成する。次に、ＳＥＬＥＣＴ節を生成し
（ステップ３２２４）、射影する項目は特に指定する必
要がない。次に、ＦＲＯＭ節を生成し（ステップ３２２
５）、次にＷＨＥＲＥ節を生成して、探索条件としては
『部門』表４の『管理者番号』列に対する等号条件で比
較する値は主キ−更新前値を指定する（ステップ３２２
６）。これらを生成し終ったとき、全ての参照制約につ
いての禁止条件の生成を終了したか否かを調べる（ステ
ップ３２２７）。この場合、『プロジェクト』表６につ
いての処理があるので、両者の禁止条件を論理結合する
ためにＡＮＤ条件を生成する（ステップ３２２８）。次
に、『部門』表４と同じようにデ−タ操作禁止条件を生
成する（ステップ３２２２ないしステップ３２２７）。
全ての参照制約について、処理を終了したならば、この
処理を終了する。以上のようにして、ＵＰＤＡＴＥ文は
次のようにデ−タ操作禁止条件が付加されたものとな
る。ＵＰＤＡＴＥ従業員ＳＥＴ従業員番号＝更新値ＷＨＥＲＥ従業員番号＝更新対象値ＡＮＤＮＯＴＥＸＩＳＴＳ（ＳＥＬＥＣＴ＊ＦＲＯＭ部門ＷＨＥＲＥ管理者番号＝更新対象値）ＡＮＤＮＯＴＥＸＩＳＴＳ（ＳＥＬＥＣＴ＊ＦＲＯＭプロジェクトＷＨＥＲＥ担当従業員番号＝更新対象値）・・・・・・・・・・・・・・・（17）

【００３７】以上のように、デ−タ操作禁止条件が付加
されたＳＱＬ文により、図１７のアクセスパス決定処理
部１４において、デ−タベ−スに対するアクセス経路が
決定される。そして、決定されたアクセスパスに従って
デ−タベ−ス管理システムが処理できる手続きを生成
し、生成した手続きを基に処理手続き実行処理におい
て、インタプリティブに実行される。実行に至っては、
デ−タ操作禁止条件として付加された条件を評価したと
きに、条件が満足されない場合には制約違反として処理
を禁止し、条件が満足される場合にはデ−タ操作を実行
する。次に、削除の場合を考える。『従業員』表５から
行を削除する場合には、ＳＱＬ文は例えば次のように要
求される。ＤＥＬＥＴＥＦＲＯＭ従業員ＷＨＥＲＥ従業員番号＝削除対象値・・・・・・・・・・・・・（18）

【００３８】上記ＳＱＬ文が発行されると、構文・意味
解析処理部１０でこのＤＥＬＥＴＥ文の文法上のチェッ
クおよび意味上の解析処理を実行する。意味解析時にデ
ィクショナリ９を参照することにより、『従業員』表５
の『従業員番号』列は主キ−であることが判る。次に、
解析されたＤＥＬＥＴＥ文に対して、デ−タ操作の禁止
条件を付加するために、デ−タ操作禁止条件付加処理部
３２に制御を渡す。デ−タ操作禁止条件付加処理部３２
では、図１８に示すように、先ず『従業員』表５の『従
業員番号』列を参照する『部門』表４の参照制約定義情
報を予め取り出しておく（ステップ３２１）。次に、デ
−タ操作を禁止するための条件を生成する（ステップ３
２２）。デ−タ操作禁止条件の生成処理は、図１９に示
すように、先ず要求されたＳＱＬ文が主キ−の更新か、
あるいは削除であるかを調べる（ステップ３２２１）。
この場合には、条件を満足するので、要求されたＤＥＬ
ＥＴＥ文は主キ−を持つ行の削除であることが判る。次
に、デ−タ操作禁止条件の生成を参照制約数分だけ繰り
返すようにする（ステップ３２２２）。次に、削除する
行の主キ−値と同じ値を持つ外部キ−値が存在するか否
かを調べるため、ＳＱＬ文の副問合わせの述語に見られ
る存在比較子であるＮＯＴＥＸＩＳＴＳ述語を生成す
る（ステップ３２２３）。次に、ＮＯＴＥＸＩＳＴＳ
述語で評価する副問合わせのＳＱＬ文を生成する。先
ず、ＳＥＬＥＣＴ節を生成し（ステップ３２２４）、射
影する項目は特に指定する必要がない。次に、ＦＲＯＭ
節を生成し、検索の対象となる表は『部門』表とする
（ステップ３２２５）。次に、ＷＨＥＲＥ節を生成し、
探索条件としては『部門』表の『所属部門』列に対する
等号条件で比較する値は削除対象主キ−値を指定する
（ステップ３２２６）。これらの生成が終了したなら
ば、全ての参照制約についての禁止条件の生成が終了し
たか否かを調べ（ステップ３２２７）、終了したなら
ば、この処理を終了する。このようにして、ＤＥＬＥＴ
Ｅ文は次のようにデ−タ操作禁止条件が付加される。

【００３９】ＤＥＬＥＴＥＦＲＯＭ従業員ＷＨＥＲＥ従業員番号＝削除対象値ＡＮＤＮＯＴＥＸＩＳＴＳ（ＳＥＬＥＣＴ＊ＦＲＯＭ部門ＷＨＥＲＥ管理者番号＝削除対象値）ＡＮＤＮＯＴＥＸＩＳＴＳ（ＳＥＬＥＣＴ＊ＦＲＯＭプロジェクトＷＨＥＲＥ担当従業員番号＝削除対象値）・・・・・・・・・・・・・・・（19）次に、行の挿入について、例を挙げて説明する。『従業
員』表に行を挿入する場合には、ＳＱＬ文は次のように
要求される。ＩＮＳＥＲＴＩＮＴＯ従業員ＶＡＬＵＥＳ（‘０００１０’，‘萩野政雄’，‘９５１０１’）・・・・・・・・・・・・・・・（20）

【００４０】上記ＳＱＬ文が発行されると、構文・意味
解析処理部１０では、このＩＮＳＥＲＴ文の文法上のチ
ェックと意味上の解析処理を実行する。意味解析時にデ
ィクショナリ９を参照することにより、『従業員』表５
の『所属部門』列は外部キ−であることが判る。次に、
解析されたＩＮＳＥＲＴ文に対して、デ−タ操作の禁止
条件を付加するために、デ−タ操作禁止条件付加処理部
３２に制御を渡す。デ−タ操作禁止条件付加処理部３２
の処理は、図１８に示すように、先ず『従業員』表５の
『所属部門』列が参照する『部門』表４の定義情報を予
め取り出しておく（ステップ３２１）。次に、デ−タ操
作を禁止するための条件を生成する（ステップ３２
２）。デ−タ操作を禁止するための条件を生成する処理
の流れは、図１９に示すように、先ず要求されたＳＱＬ
文が主キ−の更新であるか、または削除であるかを判別
する（ステップ３２２１）。この場合、条件に合致しな
いため、次に外部キ−値の更新であるか、あるいは挿入
であるかを判別する（ステップ３２２９）。ここでは、
要求されたＩＮＳＥＲＴ文は外部キ−の挿入であること
が判明する。次に、デ−タ操作禁止条件の生成を参照制
約数分だけ繰り返すようにする（ステップ３３３０）。
次に、挿入する外部キ−値が存在するか否かを調べるた
め、ＳＱＬ文の副問合わせの述語に見られる存在比較子
であるＥＸＩＳＴＳ述語を生成する（ステップ３３３
１）。次に、ＥＸＩＳＴＳ述語で評価する副問合わせの
ＳＱＬ文を生成する。先ず、ＳＥＬＥＣＴ節を生成し
（ステップ３３３２）、射影する項目は特に指定する必
要がない。次に、ＦＲＯＭ節を生成して、検索の対象と
なる表は『部門』表４とする（ステップ３３３３）。次
に、ＷＨＥＲＥ節を生成し（ステップ３３３４）、探索
条件として『部門』表４の『所属部門』列に対する等号
条件で比較する値は、外部キ−挿入値を指定する。以上
の生成が終了すると、全ての参照制約についての禁止条
件の生成が終了したか否かを判別し（ステップ３３３
５）、終了したならばこの処理を終了する。

【００４１】このようにして、ＩＮＳＥＲＴ文は次のよ
うにデ−タ操作禁止条件が付加されたものとなる。ただ
し、実際のＳＱＬの文法上は、生成したデ−タ操作禁止
条件をＩＮＳＥＲＴ文には付加できないので、論理的に
付加した形式をとって、後になり処理手続きを生成した
際に１つの手続きとする。ＩＮＳＥＲＴＩＮＴＯ従業員ＶＡＬＵＥＳ（‘０００１５’，‘萩野政雄’，‘９５１０５’）ＡＮＤＥＸＩＳＴＳ（ＳＥＬＥＣＴ＊ＦＲＯＭ部門ＷＨＥＲＥ所属部門＝‘９５１０５’）・・・・・・・・・・・・・・・（21）上述のようにして生成したＳＱＬ文を実行することによ
り、付加したデ−タ操作禁止条件を評価して、禁止条件
に該当する場合には、そのデ−タ操作を中止して、制約
違反になったことを報告する。また、禁止条件に該当し
ないときには、そのデ−タ操作を実行する。デ−タ操作
の禁止条件を含むデ−タ操作を実行する際の処理手順と
して、前記生成する禁止条件によっては、その処理の順
序を変えられる場合がある。これは、図１９におけるＷ
ＨＥＲＥ節の生成において、要求されたデ−タ操作のＳ
ＱＬ文中に指定された探索条件を参照して、主キ−に対
して指定された等号条件の条件で、かつ比較する値が定
数の場合には、デ−タ操作の禁止条件の探索条件で外部
キ−に対する条件も同じ値を用いて、等号条件による探
索条件を生成することが可能である。例えば、次のよう
なＳＱＬ文が与えられる。ＵＰＤＡＴＥ従業員ＳＥＴ従業員番号＝更新値ＷＨＥＲＥ従業員番号＝更新前値・・・・・・・・・・・・・（22）

【００４２】上記デ−タ操作に際して、禁止条件の生成
処理では、ＷＨＥＲＥ節に指定された探索条件である
‘従業員番号＝更新前値’を参照すると、主キ−である
『従業員番号』列に対して定数による等号条件の比較条
件が指定されているので、禁止条件のＷＨＥＲＥ節で
は、対応する外部キ−列の探索条件の比較定数として使
用できる。このようにして、生成されたＷＨＥＲＥ節
は、次のようなものとなる。ＷＨＥＲＥ外部キ−構成列＝更新前値・・・・・・・・・・・・・（23）この禁止条件を付加した場合に、アクセスパス決定処理
では、禁止条件部分の副問合わせを先に評価できること
が判る。従って、このアクセスパスに従って生成された
更新処理手続きは、先ず禁止条件の副問合わせの評価を
行い、評価した結果、禁止条件に合致する結果が得られ
た場合には、後のデ−タ操作処理を行うことなく、制約
違反として、処理を中止することになる。また、前例の
ように、予めＷＨＥＲＥ節において、更新対象となる主
キ−の値が判明しない場合にも、更新前値を更新対象表
の検索を行った後に、禁止条件の判定を行うことによ
り、実際に更新を行わずに処理を中止することができ
る。

【００４３】

【発明の効果】以上説明したように、本発明によれば、
あるデ−タとの整合性を維持する必要のある他のデ−タ
に対して、整合性を維持すべき手続きをデ−タベ−ス中
に格納して、更新するデ−タに対応して整合性を維持す
るための手続きを読み出し、これを実行することによ
り、整合性を効率よく維持することができる。さらに、
デ−タ操作の要求に対して、そのデ−タ操作の禁止条件
を含む指示を作成して、禁止条件の判定により、禁止条
件に合致しないときのみデ−タ操作を実行するので、デ
−タの整合性を効率よく維持できる。

【００４４】

【図面の簡単な説明】

【図１】本発明の一実施例を示す整合性維持のための手
続き実行関連図である。

【図２】本発明の一実施例を示す３つの表の参照関係を
示す図である。

【図３】図２における『部門』表の列の構成とデ−タの
実現値を示す図である。

【図４】図２における『従業員』表の列の構成とデ−タ
の実現値を示す図である。

【図５】図２における『プロジェクト』表の列の構成と
デ−タの実現値を示す図である。

【図６】図２に示した３つの表間の参照制約の定義情報
を示す図である。

【図７】本発明の第１の実施例を示すデ−タベ−ス管理
システムの構成図である。

【図８】図７におけるハ−ドウェア構成図である。

【図９】本発明における定義系解析処理の動作フロ−チ
ャ−トである。

【図１０】図９と同じく、定義系解析処理の動作フロ−
チャ−トの他の一部である。

【図１１】本発明における制約処理手続き生成処理の動
作フロ−チャ−トである。

【図１２】図１１と同じく、制約処理手続き生成処理の
動作フロ−チャ−トの一部である。

【図１３】本発明における挿入処理手続き実行処理の動
作フロ−チャ−トである。

【図１４】本発明における削除処理手続き実行処理の動
作フロ−チャ−トである。

【図１５】本発明における更新処理手続き実行処理の動
作フロ−チャ−トである。

【図１６】図１５と同じく、更新処理手続き実行処理の
動作フロ−チャ−トである。

【図１７】本発明の第２の実施例を示すデ−タベ−ス管
理システムの全体構成図である。

【図１８】本実施例におけるデ−タ操作禁止条件付加処
理の動作フロ−チャ−トである。

【図１９】図１８におけるデ−タ操作禁止条件生成処理
の動作フロ−チャ−トである。

【符号の説明】

１ＣＰＵ２主記憶装置３外部記憶装置４部門表５従業員表６プロジェクト表７デ−タベ−ス管理システム８デ−タベ−ス９ディクショナリ１０構文・意味解析処理部１２アクセスパス決定処理部１４処理手続き生成処理部１６処理手続き実行処理部１８デ−タベ−ス操作処理部２０バッファ管理部２２定義系処理部２４ディクショナリ維持管理部３２デ−タ操作禁止条件付加処理部５０，６０，７０，８０処理手続き１，２，３，４５２，６２，７２，８２メモリ領域５４，５６，５８制約情報６４，６６，６８制約情報５５，５７，５９ポインタ６５，６７，６９ポインタ９１，９２，９３，９４，９５，９６制約１，２，
３，４，５，６

───────────────────────────────────────────────────── フロントページの続き (72)発明者山平耕作神奈川県横浜市戸塚区戸塚町5030番地株式会社日立製作所ソフトウェア開発本部内 (72)発明者小寺孝神奈川県横浜市戸塚区戸塚町5030番地株式会社日立製作所ソフトウェア開発本部内 (72)発明者篠崎英典広島県広島市中区銀山町３番１号（ひろしまハイビル21）日立中国ソフトウェア株式会社内

Claims

【特許請求の範囲】

【請求項１】デ−タベ−ス中の任意のデ−タを更新す
る場合に、該デ−タとの内容の一致を保つ整合性を維持
させる必要がある他のデ−タに対して、それぞれ整合性
を維持させるための手続き用処理モジュ−ルを上記デ−
タベ−ス中に予め格納し、かつ格納位置に関する情報も
格納しておき、上記任意のデ−タに対するデ−タ操作を
行う際に、上記整合性を維持させる手続き用処理モジュ
−ルを上記デ−タベ−スから読み出して、該手続き用処
理モジュ−ルを実行することを特徴とするデ−タベ−ス
管理方法。
【請求項２】請求項１に記載のデ−タベ−ス管理方法
において、上記手続き用処理モジュ−ルは、任意のデ−
タとの整合性を維持させるための他のデ−タを挿入する
場合に、挿入するデ−タが上記任意のデ−タとの整合性
を維持できることを検査するプログラムモジュ−ルであ
ることを特徴とするデ−タベ−ス管理方法。
【請求項３】請求項１に記載のデ−タベ−ス管理方法
において、上記手続き用処理モジュ−ルは、任意のデ−
タを削除する場合に、削除するデ−タとの整合性が維持
される必要のある他のデ−タが存在しないことを検査す
るプログラムモジュ−ルであることを特徴とするデ−タ
ベ−ス管理方法。
【請求項４】請求項１に記載のデ−タベ−ス管理方法
において、上記手続き用処理モジュ−ルは、任意のデ−
タとの整合性が維持される必要のある他のデ−タを追加
ないし更新する場合に、追加ないし更新したデ−タと整
合性を維持することができるデ−タが存在することを検
査するプログラムモジュ−ルであることを特徴とするデ
−タベ−ス管理方法。
【請求項５】請求項１に記載のデ−タベ−ス管理方法
において、上記手続き用処理モジュ−ルは、任意のデ−
タを削除する場合に、削除するデ−タと整合性を維持す
る他のデ−タが存在すれば、該デ−タも削除するプログ
ラムモジュ−ルであることを特徴とするデ−タベ−ス管
理方法。
【請求項６】請求項１に記載のデ−タベ−ス管理方法
において、上記手続き用処理モジュ−ルは、任意のデ−
タを削除する場合に、削除するデ−タと整合性を維持す
る他のデ−タが存在すれば、該デ−タをナル値（ＮＵＬ
Ｌ）ないし予め外部より指定された値に更新するプログ
ラムモジュ−ルであることを特徴とするデ−タベ−ス管
理方法。
【請求項７】請求項１に記載のデ−タベ−ス管理方法
において、上記手続き用処理モジュ−ルは、任意のデ−
タを更新する場合に、更新するデ−タと整合性を維持す
る他のデ−タが存在すれば、該デ−タも同じデ−タに更
新するプログラムモジュ−ルであることを特徴とするデ
−タベ−ス管理方法。
【請求項８】請求項１に記載のデ−タベ−ス管理方法
において、上記手続き用処理モジュ−ルは、任意のデ−
タを更新する場合に、更新するデ−タと整合性を維持す
る他のデ−タが存在すれば、該デ−タをナル値（ＮＵＬ
Ｌ）ないし予め外部より指定された値に更新するプログ
ラムモジュ−ルであることを特徴とするデ−タベ−ス管
理方法。
【請求項９】デ−タベ−ス中のデ−タ操作を行う場合
に、該操作の禁止条件を含む指示を入力して、該禁止条
件を判定し、該判定の結果、該操作が禁止されない場合
には、該操作を実行するが、該判定の結果、該操作が禁
止される場合には、該操作を実行しないことを報告する
ことを特徴とするデ−タベ−ス管理方法。
【請求項１０】請求項９に記載のデ−タベ−ス管理方
法において、上記禁止条件は、任意のデ−タとの整合性
が維持される必要のある他のデ−タを挿入および更新す
る場合、挿入および更新するデ−タが上記任意のデ−タ
に存在しなければ、該操作を禁止する条件であり、また
上記禁止条件を含む指示は、挿入および更新操作が行わ
れる前ないし後に、挿入および更新したデ−タが上記任
意のデ−タに存在しなければ該操作を禁止する条件を判
定する指示であることを特徴とするデ−タベ−ス管理方
法。
【請求項１１】請求項９に記載のデ−タベ−ス管理方
法において、上記操作の禁止条件は、任意のデ−タを更
新する場合に、上記任意のデ−タと整合性を維持してい
る他のデ−タが存在すれば、該任意のデ−タを更新する
操作を禁止する条件であり、上記禁止条件を含む指示
は、該任意のデ−タを更新する前ないし後に、該任意の
デ−タと整合性を維持している他のデ−タが存在すれ
ば、該任意のデ−タを更新する操作を禁止する条件を判
定する指示であることを特徴とするデ−タベ−ス管理方
法。
【請求項１２】請求項９に記載のデ−タベ−ス管理方
法において、上記操作の禁止条件は、任意のデ−タを削
除する場合に、該任意のデ−タと整合性を維持している
他のデ−タが存在すれば、該任意のデ−タを削除する操
作を禁止する条件であり、上記禁止条件を含む指示は、
該任意のデ−タを削除する前ないし後に、該任意のデ−
タと整合性を維持している他のデ−タが存在すれば、該
任意のデ−タを削除する操作を禁止する条件を判定する
指示であることを特徴とするデ−タベ−ス管理方法。
【請求項１３】デ−タベ−スと、該デ−タベ−スの中
の任意のデ−タの更新に伴って、該任意のデ−タとの整
合性が維持される必要のある他のデ−タに対する整合性
を維持するための手続き用処理モジュ−ルを上記デ−タ
ベ−ス中に格納する第１の記憶制御手段と、該任意のデ
−タに対応して上記手続き用処理モジュ−ルを格納する
位置に関する情報を格納する第２の記憶制御手段と、該
任意のデ−タの更新に伴って、上記格納位置を参照して
上記手続き用処理モジュ−ルを読み出し、該モジュ−ル
を実行するプロセッサを具備することを特徴とするデ−
タベ−ス管理システム。
【請求項１４】デ−タベ−スと、該デ−タベ−ス中の
デ−タ操作のために、該デ−タ操作の禁止条件を含む指
示を作成するサブモジュ−ルと、該デ−タ操作の禁止条
件を含む指示を読み出して、該禁止条件を判定するサブ
モジュ−ルと、判定の結果、該操作が禁止されない場合
には該操作を実行し、判定の結果、該操作が禁止される
場合には該操作を実行しないことをオペレ−タに報告す
るサブモジュ−ルとを有することを特徴とするデ−タベ
−ス管理システム。