JPH0877191A - データベース管理システム - Google Patents

Abstract

(57)【要約】 【目的】 データベースシステムにおいて、システムの
性能や運用性を向上させる。 【構成】 既存の１つのデータベースを、操作者からの
指示に基づき、それぞれ同一のインデクスもしくはハッ
シングを有する２以上のブロックに分割して格納するブ
ロック６ａ〜６ｄと、行検索時に、同一のインデクスも
しくはハッシングを用いて各ブロック毎の検索を行い、
この検索で得た各ブロックの各行を併合して単一の検索
結果として出力する行併合部２１と、操作者からの指示
に基づき各ブロックの割当および割当解除を個別に行う
割当制御部２２と、各ブロックの識別情報、格納すべき
行の条件に関する情報、参照の可否および更新の可否に
関する情報、各ブロック間に予め定めた優先順序情報
を、操作者からの指示に基づき登録する制御テーブル４
とを設けたデータベース管理システム。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、データベース管理シス
テムの分割および連結技術に係るものであり、特に、売
上伝票や発注伝票などを取り扱うデータベース、すなわ
ち、レコードが時系列的に追加されていくようなデータ
ベース（以下、伝票型ＤＢという）や、顧客マスタや各
種コード表など、実世界の実体に関する比較的変更の少
ないデータを保持するデータベース（以下、マスタ型Ｄ
Ｂという）の運用を効率良く行うのに好適なデータベー
ス管理システムに関するものである。

【０００２】

【従来の技術】従来、データベースを分割して保持し、
それを連結する技術としては、次のようなものがある。 （ａ）ＡＰ（アプリケーションプログラム）による複数
の表の検索：要求元のＡＰで意識して複数の表を検索
し、その結果を併合して処理する技術が公知である。例
えば、ＪＩＳのＳＱＬでは、「ＵＮＩＯＮ」の指定をす
ることにより、複数の表を検索できる（ＪＩＳ Ｘ３０
０５−１９９０ データベース言語ＳＱＬ ８．３＜カ
ーソル宣言＞）。また、ワープロのカナ漢字変換で、ユ
ーザ定義辞書とシステム標準辞書を併合して検索する技
術も、その一種である。しかし、この検索では、ＡＰが
併合を意識する必要があるので、検索時に（動的に）連
結することはできない。

【０００３】（ｂ）区分データセットの連結：同一の構
造を持つ区分データセットを、実行時に複数個連結する
ことは広く行われている。連結をＡＰが意識する必要は
ないから、実行時に動的に連結でき、システムを運用し
ていく上で極めて便利である。しかし、この場合の連結
技術は、単にそれぞれの区分データセットのディレクト
リを順にサーチするだけであって、インデクスやハッシ
ングを使うものではないから、本格的なデータベース検
索のためには使えない。

【０００４】（ｃ）表の横分割：表定義時に格納条件を
指定することにより、表を複数のエリアに分けることは
多くのデータベース管理システムで行われている。しか
し、この場合、分割の指定は表定義時に行うから、検索
時に（動的に）連結することはできない。また、エリア
毎に独立にインデクスを設けた構造ではないから、独立
して検索可能ではなく、たまたま一方のエリアだけで検
索が行える場合、例えば、分割キーと同じ列をキーとす
るインデクスを使った検索の他は、独立した検索はでき
ない。特に、二次インデクスを使う場合は、ほとんどの
場合、独立した検索は不可能である。

【０００５】一般にデータベースにおいて、一つの表の
中の各行は、論理的には、他の行と独立である。しか
し、データの発生から消滅に至る流れを考えると、各行
は独立ではなく、まとまった単位で行動することが多
い。このような場合、発生から消滅に至る流れ（データ
のライフサイクル）を共にするグループ毎にデータを独
立したブロックに分け、それを、ちょうど区分データセ
ットの連結のように、実行時（検索時）に動的に連結で
きれば、情報システムの運用に際して便利なことが多
い。しかし、従来のデータベース管理システムは、この
ような機能を持っていないため、データを無理に一つの
ブロックに格納しなければならず、システムの性能や運
用性に関して不便をきたしている。具体的には次のよう
な場合がある。

【０００６】（イ）一定範囲のデータの一括処理：伝票
型ＤＢでは、一定範囲のデータをまとめて扱うことが多
い。例えば、１ヶ月の間に蓄積されたデータを翌月初め
にバッチで月締め処理し、処理終了後または一定の保存
期間満了後に一括してそのデータを消去する、といった
場合である。ところが、従来のデータベース管理システ
ムでは、１ヶ月分のデータが、データベース領域中に分
散して配置されることが多く、この場合は、読み込みの
効率が悪い。また、一括消去に伴って発生する空き領域
は、そのデータがデータベース領域中に分散して配置さ
れていたか否かに係らず、有効再利用が困難である。

【０００７】（ロ）大量データ追加による表の占有：伝
票型ＤＢでは、バッチで大量データを生成し、表に追加
することがある。例えば、月締め処理で売掛金を集計し
て請求書を起こし、その請求書データを表に追加すると
いった場合である。このような場合、仮りに請求書を参
照・更新するオンライントランザクションがあったとし
ても、本来は、排他制御は不要なはずである。なぜな
ら、バッチでは、行の追加しかしないのだから、バッチ
が終了するまでは、そのバッチが追加した行（請求書）
は、単に存在しないものとみなせば良いからである。と
ころが、従来のデータベース管理システムでは、広範な
排他制御が行われるため、このようなバッチと参照・更
新オンライントランザクションとを同時に実行すること
は困難である。尚、分散システムでは、マスタ型ＤＢに
おいても、ファイル転送により大量データの追加が生じ
る場合がある。この場合も、表を占有し、他の処理に悪
影響を及ぼす。

【０００８】（ハ）オンライン中のデータベース再編
成：マスタ型ＤＢでは、データベースに随時、更新／追
加／削除を行う場合が多く、この場合は、定期的に再編
成が必要になる。あるいは、有効日の処理、もしくは、
変更履歴の保存のために、古いデータを書き換えずに新
しいデータをその都度追加していく場合も多く、この場
合は、一定期間毎に、古いデータを消去した上で再編成
することが必要になる。このようなデータベースの再編
成や古いデータの消去は、他のデータベースアクセスに
影響を与えずに行いたい。ところが、従来のデータベー
ス管理システムでは、再編成に際してはデータ全体を排
他しなければならず、この間、他のデータベースアクセ
スはできない。

【０００９】（ニ）マスタ型ＤＢの変更分管理：マスタ
型ＤＢでは、変更の頻度は高くない。このようなデータ
ベースに対し、一定範囲の変更データだけを集計したい
場合がある。例えば、本日分の新規顧客を一覧表にする
といった場合である。ところが、従来のデータベース管
理システムでは、そのためには、顧客表全体を順検索す
るか、あるいは、この目的のために専用のインデクスを
設けるかしなければならない。また、日毎の変更分は僅
かであるのに、変更分がデータベース領域全体に分散し
ているため、データベース領域全体を頻繁に（通常は毎
日）バックアップする必要がある。

【００１０】（ホ）既製のデータベースへの行の追加：
マスタ型ＤＢの中には、住所コードマスタや金融機関マ
スタ等のように、既製のデータが市販されているものが
ある。これらに対し、一部、自システムで独自のデータ
を追加したい場合がある。このような場合、市販データ
が改訂された場合を考えると、市販データと独自データ
とは、別の領域に分けて格納しておきたい。ところが、
従来のデータベース管理システムでは、それはできず、
市販のデータを格納した領域と同じ領域に独自データも
格納する必要がある。また、情報システムのテストを行
うときには、マスタ型ＤＢにもテスト用の特殊なデータ
（例えば、エラーデータ）を追加する必要がある場合が
ある。この場合は、できればデータベース本体に手を加
えず、特殊データだけを別の領域に格納しておきたい
が、従来のデータベース管理システムではそれはできな
い。

【００１１】

【発明が解決しようとする課題】解決しようとする問題
点は、従来の技術では、データをグループ単位に独立し
たブロックに分けて格納すること、および、このように
格納したデータを、実行時（検索時）に動的に連結する
ことができない点である。本発明の目的は、これら従来
技術の課題を解決し、データを無理に一つのブロックに
格納する必要をなくし、システムの性能や運用性の向上
を可能とするデータベース管理システムを提供すること
である。

【００１２】

【課題を解決するための手段】上記目的を達成するた
め、本発明のデータベース管理システムは、（１）既存
の１つのデータベースを、操作者からの指示に基づき、
それぞれ同一のインデクスもしくはハッシングを有する
２以上のブロックに分割して格納する手段（ブロック６
ａ〜６ｖ）と、行検索時に、同一のインデクスもしくは
ハッシングを用いて、各ブロック毎の検索を行い、該検
索で得た各ブロックの各行を併合して、単一の検索結果
として出力する行併合部２１とを設けることを特徴とす
る。また、（２）上記（１）に記載のデータベース管理
システムにおいて、操作者からの指示に基づき、各ブロ
ックの割当および割当解除を、個別に行う割当制御部２
２を設けることを特徴とする。また、（３）上記
（１）、もしくは、（２）のいずれかに記載のデータベ
ース管理システムにおいて、各ブロックの識別情報と、
このブロックに格納すべき行の条件に関する情報と、こ
のブロックの参照の可否および更新の可否に関する情報
と、各ブロック間に予め定めた優先順序情報とを、操作
者からの指示に基づき登録する制御テーブル４〜４ｅを
設け、行の格納に際して、この行が、格納すべき行の条
件に合致する場合もしくはブロックが更新可の場合に、
このブロックに行を格納し、また、行の検索に際して、
ブロックが参照可の場合に、このブロック内の表を検索
対象とし、また、キー列の値が全て等しい行、もしく
は、キー配列のうち予め定めた１つの値が全て等しい行
が、複数のブロックにまたがって存在する場合には、優
先順序情報に従い、最も高い優先順序のブロック内の行
を有効とみなし、他のブロック内の行は無効とみなして
無視することを特徴とする。

【００１３】

【作用】本発明においては、一つの表を格納する外部記
憶装置を、二つ以上のブロックから構成する。その際、
各ブロックは、独立なインデクスを設ける構造、もしく
は、独立してハッシングを行える構造とし、行検索時
に、独立して設けたインデクス、または、独立して行え
るハッシングを用いて、各ブロック毎に独立して検索す
る。そして、この検索により得た行を併合して、単一の
検索結果を得る。これにより、独立して検索可能な構造
を持つ二つ以上のブロックを、要求元に意識させること
なく、検索時に連結できる。このように、独立したブロ
ックを実行時（検索時）に動的に連結できるので、デー
タを一つの領域に格納する必要がなくなる。例えば、ラ
イフサイクルを共にするグループ毎にデータを分けて格
納しておいても、実行時には、業務プログラム（ＡＰ）
は、何ら意識することなく、それらのデータを連結して
読むことができる。

【００１４】また、本発明においては、操作者からの指
示に基づき、各ブロックの割当および割当解除を個別に
行うことができ、例えば、それぞれライフサイクルを異
にするデータを、ライフサイクル単位でブロックに割り
当て、そのライフサイクルに応じたアクセスが可能とな
る。さらに、制御テーブルに、各ブロックの識別情報
と、各ブロックに格納すべき行の条件に関する情報と、
各ブロックの参照の可否および更新の可否に関する情報
と、各ブロック間に予め定めた優先順序情報とを、操作
者からの指示に基づき登録し、行の格納時、および、行
の検索時には、この制御テーブルに基づき、各ブロック
の格納および検索の可否の制御、各ブロックの選択を行
うことができる。例えば、各ブロックに同等の情報があ
るときに、いずれか一方を優先させたい場合にも、テー
ブルに予め定めた優先順位に従って、いずれかのブロッ
ク内の行を有効とみなすことができる。これにより、上
述の従来技術における不便（イ）〜（ホ）のそれぞれに
体して次のように対処できる。

【００１５】（イ）一定範囲のデータの一括処理：本発
明によれば、各ブロックは個別に割り当ておよび割り当
て解除が可能である。従って、例えば１ヶ月の間に蓄積
されたデータを翌月初めにバッチで月締め処理し、処理
終了後または一定の保存期間満了後に、一括してそのデ
ータを消去するといった場合は、１ヶ月ごとに別のブロ
ックにデータを格納することにより、一定範囲のデータ
を効率良く一括処理することができる。また、一括消去
に伴って発生する空き領域は、割り当て解除すれば良い
から、別の目的に有効再利用できる。

【００１６】（ロ）大量データ追加による表の占有：本
発明によれば、各ブロックへのデータの格納および各ブ
ロックの検索は、テーブルで制御できる。従って、例え
ば月締め処理で売掛金を集計して請求書を起こし、その
請求書データを表に追加するといった場合は、１ヶ月ご
と、すなわち、１バッチごとに別のブロックとし、バッ
チ処理が終了するまでは、バッチで追加を行っているブ
ロックは検索対象としないように制御することにより、
格納と検索との間で、本来は不要なはずの排他制御が起
こることを防ぐことができる。また、分散システムにお
いて、ファイル転送により、マスタ型ＤＢに大量データ
の追加が生じる場合は、転送ごとに別のブロックとする
ことにより、格納と検索との間で、本来は不要なはずの
排他制御が起こることを防ぐことができる。

【００１７】（ハ）オンライン中のデータベース再編
成：本発明によれば、それぞれのブロックは、個別に割
り当ておよび割り当て解除が可能である。従って、例え
ば一定期間ごとに古いデータを消去した上で再編成する
ことが必要になる場合は、別のブロックを割り当てて、
そこに、既存のデータをコピーし、その際に、古いデー
タの消去を行うことにより、データベースをオンライン
中に再編成することが可能である。

【００１８】（ニ）マスタ型ＤＢの変更分管理：本発明
によれば、各ブロックへのデータの格納およびブロック
の検索は、テーブルで制御できる。従って、例えば本日
分の新規顧客を一覧表にするといった場合は、最近の新
規・変更分のデータを別ブロックに格納することによ
り、顧客表全体の順検索は不要となる。また、最近の新
規・変更分以外のデータは更新されないから、この分
は、日次のバックアップは不要である。

【００１９】（ホ）既製のデータベースへの行の追加：
本発明によれば、キー列の値が全て等しい行、または、
キー列のうち予め定められた列の値が全て等しい行が複
数のブロックにまたがって存在する場合、予め定めた優
先順位に従い、いずれかのブロック内の行を有効とみな
すことができる。従って、例えば市販データに対して一
部、自システムで独自のデータを追加したい場合、自シ
ステムの独自データを別ブロックに格納して、その優先
順位を高くしておくことにより、自システムの独自デー
タを市販データに優先させて参照することができる。

【００２０】

【実施例】以下、本発明の実施例を、図面により詳細に
説明する。図１は、本発明のデータベース管理システム
の本発明に係る構成の第１の実施例を示すブロック図で
ある。本図において、１は業務プログラム、２は本発明
に係るブロックの動的連結を行うミドルソフト、３は市
販されている通常のデータベース管理パッケージ、６ａ
〜６ｄは既存の一つのデータベースを、操作者からの指
示に基づき、それぞれ同一のインデクスもしくはハッシ
ングを有する二以上のブロックに分割して格納したブロ
ックである。

【００２１】ミドルソフト２は、行検索時に、同一のイ
ンデクスもしくはハッシングを用いて、各ブロック６ａ
〜６ｄ毎の検索を行い、この検索で得た各ブロックの各
行を併合して、単一の検索結果として出力する行併合部
２１と、操作者からの指示に基づき、各ブロックの割当
および割当解除を、個別に行う割当制御部２２と、各ブ
ロックの識別情報や、このブロックに格納すべき行の条
件に関する情報、このブロックの参照の可否および更新
の可否に関する情報、各ブロック間に予め定めた優先順
序情報などを、操作者からの指示に基づき登録した制御
テーブル４を具備している。

【００２２】このような構成により、本実施例のデータ
ベース管理システムは、独立して設けたインデクス、ま
たは、独立して行えるハッシングを用いて、各ブロック
毎に独立して検索し、この検索により得た行を併合し
て、単一の検索結果を得る。これにより、独立して検索
可能な構造を持つ二つ以上のブロックを、要求元に意識
させることなく、検索時に連結できる。このように、独
立したブロックを実行時（検索時）に動的に連結できる
ので、データを一つの領域に格納する必要がなくなる。
例えば、ライフサイクルを共にするグループ毎にデータ
を分けて格納しておいても、実行時には、業務プログラ
ム１は、何ら意識することなく、それらのデータを連結
して読むことができる。

【００２３】また、割当制御部２２により、操作者から
の指示に基づき、各ブロックの割当および割当解除を個
別に行うことができ、例えば、それぞれライフサイクル
を異にするデータを、ライフサイクル単位でブロックに
割り当て、そのライフサイクルに応じたアクセスが可能
となる。さらに、制御テーブル４に、各ブロックの識別
情報と、各ブロックに格納すべき行の条件に関する情報
と、各ブロックの参照の可否および更新の可否に関する
情報と、各ブロック間に予め定めた優先順序情報とを、
操作者からの指示に基づき登録し、行の格納時、およ
び、行の検索時には、この制御テーブル４に基づき、各
ブロックの格納や検索の可否の制御、および各ブロック
の選択を行うことができる。例えば、各ブロックに同等
の情報があるときに、いずれか一方を優先させたい場合
にも、テーブルに予め定めた優先順位に従って、いずれ
かのブロック内の行を有効とみなすことができる。

【００２４】以下、このような本実施例のデータベース
管理システムの本発明に係る動作説明を、図２、図３を
用いて行う。図２および図３は、図１におけるデータベ
ース管理システムの本発明に係る動作例を示す説明図で
ある。本実施例は、ブロックの動的連結機能を実現する
に際し、市販されている通常の（本機能を持たない）デ
ータベース管理パッケージ（図中、ＰＧＭ１と記載）１
をミドルソフト２（図中、ＭＩＤＤＬＥと記載）で補完
して、全体として本発明に係る機能を持ったデータベー
ス管理システムを構築したものである。尚、本図におい
て、１ａ〜１ｈは業務プログラム１内のＤＢ処理（以
下、単に処理と記載）、２ａ〜２ｈは業務プログラム１
内の各ＤＢ処理１ａ〜１ｈにそれぞれ対応してミドルソ
フト２が実行する処理、２ｘはＳＱＬＩＤテーブル、ま
た、５はデータベース管理パッケージ３から見たデータ
ベース定義である。

【００２５】ミドルソフト２は、本発明に係るブロック
の動的連結を行なうため、ＪＩＳのＳＱＬで定めるＵＮ
ＩＯＮおよび動的ＳＱＬ機能を活用する。ＵＮＩＯＮ
は、二つの表を仮想的に結合し、あたかも一つの表であ
るかのように見せる機能であり、動的ＳＱＬは、ＳＱＬ
を予めコンパイルすることなくＰＲＥＰＡＲＥ文により
実行時に動的に与えることを許す機能である。この二つ
を併用し、本図の２ａで例示するように、ＵＮＩＯＮ指
定を含むＳＱＬをＰＲＥＰＡＲＥ文の中に指定すること
により、独立したテーブルを動的に結合し、あたかも一
つの表であるかのように見せる。

【００２６】このように、本実施例では、業務プログラ
ム１とデータベース管理パッケージ３との間にミドルソ
フト２が介在する。業務プログラム１では、データベー
スにアクセスするときは、ミドルソフト２に対して要求
を行う。各ブロック（図中、ＤＢ１ＢＬＫ１、ＤＢ１Ｂ
ＬＫ２、ＤＢ２ＢＬＫ１、ＤＢ２ＢＬＫ２と記載）６ａ
〜６ｄは、データベース管理パッケージ３からみれば、
それぞれ一つの表（データベーステーブル）である。従
って、それぞれ独立したインデクスまたはハッシングを
持つ。業務プログラム１からみた表は、これらのブロッ
クが、必要により、二つ以上集まって構成される。制御
テーブル４には、業務プログラム１からみた表（ＤＢ
名）に対してどのブロックを連結すべきか（業務プログ
ラム１からみた表が、どのブロックから構成されるか）
の情報を持つ。尚、本例では、その他に、参照可否およ
び更新可否の情報を持っているが、これらについては後
に説明する。

【００２７】業務プログラム１による一連のデータベー
スアクセスを識別するため、ミドルソフト２をコールす
るときに「ＩＤ」を指定する。本例では、ＤＢ１に対す
るアクセス（処理１ａ〜１ｅ）では、「ＰＧＭ１ＩＤ
１」を指定し、またＤＢ２に対するアクセス（処理１ｆ
〜１ｈ）では、「ＰＧＭ１ＩＤ２」を指定している。ミ
ドルソフト２では、連結対象とすべきブロックの名称を
制御テーブル４から得ると、それらのブロックを「ＵＮ
ＩＯＮ」するためのＳＱＬを組み立て、ＰＲＥＰＡＲＥ
する。尚、ＰＲＥＰＡＲＥは、任意のＳＱＬを動的指定
するものではあるが、ＰＲＥＰＡＲＥ文自身は、予め静
的に用意しておく必要がある。そこで、ＰＲＥＰＡＲＷ
文からなるＳＱＬの枠だけは、予めミドルソフト２内に
用意しておく。業務プログラム１が指定したＩＤとミド
ルソフト２内に用意したＳＱＬの枠を対応付けるため、
ＳＱＬＩＤテーブル２ｘをミドルソフト２内に持つ。

【００２８】処理１ａは、以下「ＰＧＭ１ＩＤ１」とい
うＩＤのもとで、「ＤＢ１」に対する読み込みを行うこ
とを宣言するものである。これを受け、ミドルソフト２
では、空きのＳＱＬの枠をＳＱＬＩＤテーブル２ｘから
探す。ここでは、指定されているキーが二つあるから、
二つのキーを持つＳＱＬの枠の中から、ＳＱＬＩＤ２−
１を選択している。次に制御テーブル４を参照して、該
当するブロックを求め、これに基づいてＳＱＬを組み立
て、「ＰＲＥＰＡＲＥ」要求を行う。本例では、当該す
るブロックが二つあるので、ＳＱＬ中に「ＵＮＩＯＮ」
の指定を行い、両方のブロックを読めるようにしてい
る。

【００２９】処理１ｂはカーソルのオープン要求であ
る。ここでキー値が指定され、カーソルが位置付けられ
る。処理１ｃはフェッチ要求であり、１行のデータが転
送される。処理１ｄはカーソルのクローズ要求である。
キー値の指定およびカーソルの位置付けはこの時に解除
される。但し、ＳＱＬ枠「ＳＱＬＩＤ２−１」は、まだ
ＩＤ「ＰＧＭ１ＩＤ１」に割り当てられたままであり、
「ＰＲＥＰＡＲＥ」の効力も消えていない。処理１ｅは
ＩＤ「ＰＧＭ１ＩＤ１」の解除要求であり、ＳＱＬ枠
「ＳＱＬＩＤ２−１」の割り当てが解除される。

【００３０】図３において、処理１ｆは、以下「ＰＧＭ
１ＩＤ２」というＩＤのもとで「ＤＢ２」に対する追加
を行うことを宣言するものである。これを受け、ミドル
ソフト２では、空きのＳＱＬの枠をＳＱＬＩＤテーブル
２ｘから探す。ここではＳＱＬＩＤ１−１を選択してい
る。次に制御テーブル４を参照して、該当するブロック
を求め、これに基づいて、ＳＱＬを組み立て、「ＰＲＥ
ＰＡＲＥ」を行う。本例では、単一のブロックに対する
ＳＱＬを作るだけであるが、後述の図５、６で説明する
ように、追加する行の内容によって追加先ブロックが異
なる場合は、複数のＳＱＬを組み立て、「ＰＲＥＰＡＲ
Ｅ」しておく必要がある。処理１ｇはデータの追加要求
であり、そして処理１ｈは、ＩＤ「ＰＧＭ１ＩＤ２」の
解除要求である。

【００３１】本実施例によれば、既存のデータベース管
理パッケージ３に手を加えることなく本発明に係る処理
を行うことができる。また、動的ＳＱＬを使っているの
で、使い方によっては、性能を若干害することがあるも
のの、各ブロックを個別に割り当ておよび割り当て解除
することは容易である。さらに、それぞれのブロック
は、データベース管理パッケージから見て、それぞれ一
つの表であるから、例えば、一部のブロックにはインデ
クスを用い、他のブロックにはハッシングを用いるよう
なことも可能である。一方、ミドルソフト２は、データ
ベースの構成について、データベース管理パッケージ３
ほどは詳細な定義情報を持っていないため、サポートで
きる機能には制約が生じる場合がある。このことの具体
例は、後述の図９、１０を用いて説明する。

【００３２】次に、本発明に係るブロックの動的連結
を、市販されるパッケージプログラムとしてのデータベ
ース管理パッケージ自体で行う実施例を、図４、図５を
用いて説明する。図４は、本発明のデータベース管理シ
ステムの本発明に係る構成の第２の実施例を示すブロッ
ク図である。本実施例では、図１〜図３におけるミドル
ソフトは存在せず、業務プログラム１は、データベース
管理パッケージ３ａに対して直接データベースアクセス
を要求する。データベース管理パッケージ３ａには、図
１において説明した本発明に係る行併合部２１と割当制
御部２２および制御テーブル４が設けられている。尚、
本図において、３ｉ〜３ｎは、業務プログラム１内のＤ
Ｂ処理１ｉ〜１ｎにそれぞれ対応してデータベース管理
パッケージ３ａが実行する処理である。

【００３３】データベース管理パッケージ３ａは、制御
テーブル４を参照し、必要なブロックに対して入出力を
行う。制御テーブル４には、その表（ＤＢ名）を構成す
るブロック名を持つ。尚、本例では、その他に、参照可
否および更新可否の情報を持っているが、これらについ
ては図５以降を用いて説明する。各ブロック６ａ〜６ｄ
（ＤＢ１ＢＬＫ１〜ＤＢ２ＢＬＫ２）は、表の構成要素
であり、それぞれ独立したインデクスまたはハッシング
を持っている。制御テーブル４は、テーブル構成・イン
デクス構成等に関する他のデータベース定義情報と共
に、データベース管理パッケージ３ａが管理している。

【００３４】業務プログラム１における処理１ｉは、カ
ーソルの宣言である。これを受けて、データベース管理
パッケージ３ａでは、制御テーブル４を参照し、当デー
タベースを構成するブロックを求める。以下の処理で
は、データベース管理パッケージ３ａは、該当するブロ
ック内のデータをマージ（併合）して業務プログラム１
に渡す。これにより、ブロックが動的に連結される。処
理１ｊは、カーソルのオープン要求である。キー値は、
この時点でのＫＥＹ１、ＫＥＹ２の値が用いられる。処
理１ｋは、データのフェッチ要求である。１行のデータ
が転送される。

【００３５】処理１ｌは、カーソルのクローズ要求であ
る。キー値の指定およびカーソルの位置付けはこの時に
解除され、カーソルは再オープンが可能な状態となる。
但し、ブロックとの結び付けは解除されず、再オープン
しても、制御テーブルは再アクセスされない。処理１ｍ
は、カーソル宣言の効果を終了させるものである。これ
により、カーソルとブロックとの結び付けが解除され
る。これはＪＩＳのＳＱＬにはないものであるが、ＪＩ
Ｓでは、標準外のＳＱＬを各処理系が独自にサポートす
ることを禁じていないから、このようなＳＱＬがあるこ
と自体は規格合致性の上で問題はない。但し、規格合致
性を主張するためには、このようなＳＱＬは必須として
はならず、省略した場合は、プログラム終了時に自動的
にこれと同じことが起こるようにしておく必要がある。

【００３６】本実施例によれば、ＳＱＬそのもので本発
明に係る動作をサポートするため、広範な機能を実現で
きる。また、用途に応じ、静的ＳＱＬと動的ＳＱＬのい
ずれでも使うことができる。静的ＳＱＬを使えば、各ブ
ロックの個別の割り当ておよび割り当て解除に制約はあ
るものの、性能上は有利である。

【００３７】以下、図５〜図１４を用いて、本発明に係
るブロックの動的連結動作を五つの例で具体的に説明す
る。図５は、本発明のデータベース管理システムの本発
明に係る動作の第１の具体例を示す説明図である。本実
施例は、伝票型ＤＢへの適用例であり、オンラインで逐
次データが追加されて、それを一定のタイミング（例え
ば月次）でバッチ処理するような業務、例えば、得意先
への売掛データが逐次追加されて、それを毎月の月末に
まとめて請求および経理処理するような業務に応用した
ものである。

【００３８】図５に示した時点で、制御テーブル４ａに
おいては、一つの表（ＤＢ３）に対して４個のブロック
６ｅ〜６ｈ（ＤＢ３ＢＬＫ１〜ＤＢ３ＢＬＫ４）が割り
当てられている。各ブロック６ｅ〜６ｈは、それぞれ１
ヵ月分のデータを保持する。すなわち、一時点では、い
ずれか一つのブロックに書き込みが行われ、また、一つ
のブロック内のデータは、まとめて削除されるのが普通
であって、この意味で、各ブロック内のデータは、それ
ぞれライフサイクルを共にし、別のブロックのデータと
は、ライフサイクルを異にする。各ブロックは、例えば
図１における割当制御部２２により、個別に割り当てお
よび割り当て解除が可能である。

【００３９】制御テーブル４ａでは、各ブロック６ｅ〜
６ｈに対して、このブロックに格納すべき行の条件（こ
こでは日付け（自）および日付け（至））、および、こ
のブロックの更新可否に関する情報を管理している。
尚、参照可否に関する情報も管理しているが、本例では
有効ではない。一つの表（ＤＢ３）の各行は、先頭部８
に当該伝票の発行年月日を持つ。行の格納に際しては、
この日付けを制御テーブル４ａの日付け（自）および日
付け（至）と比較し、格納先を決める。当該の行を格納
すべきブロックが「更新不可」ならば、その月分の伝票
は、既に締め切られたことを示す。

【００４０】図６は、図５における制御テーブル内容に
基づく本発明に係る動作例を示す説明図である。まず、
３月３１日（３／３１）に、翌月（４月）分のデータを
保持するブロック（ＤＢ３ＢＬＫ４）を割り当てる。図
５の制御テーブル４ａは、この状態を表している。これ
により、４月発行分の伝票が投入可能となる。次に、４
月５日（４／５）に、３月分のデータを保持するブロッ
ク（ＤＢ３ＢＬＫ３）を更新不可とする。これにより、
３月分の伝票は締め切られ、以降、投入不可となる。さ
らに、４月６日（４／６）に、３月分のデータをバッチ
で一括処理する。３月分の伝票は既に締め切られている
から、以降、変更されることはない。そして、４月７日
（４／７）に、保存期限を満了した１月分データを保持
するブロック（ＤＢ３ＢＬＫ１）を削除する。

【００４１】本実施例によれば、次のような利点があ
る。 （い）データを１ヵ月ごとに分けて保持することができ
る。これにより、１ヵ月分データの一括処理が効率良く
行える。また、削除によって空いた領域は、有効利用で
き、再編成の必要もない。 （ろ）更新する部分が限られているから、日次のバック
アップの対象を限定できる。 （は）ブロックを実行時に割り当てることができるか
ら、データベースの容量を随時変えられる。これによ
り、例えば、本番運転開始直後はスペースを小さくして
おき、必要に応じてスペースを拡張することができる。 （に）伝票の「締め切り」という概念を自然にサポート
できる。これにより、バッチラインとバッチの間では排
他制御は必要なくなる。従って、オンライン中でもバッ
チジョブが実行できる。

【００４２】図７は、本発明のデータベース管理システ
ムの本発明に係る動作の第２の具体例を示す説明図であ
る。本実施例は、伝票型ＤＢへの本発明の別の応用例で
あり、バッチで追加されたデータまたは他のシステムか
らファイル転送されたデータをオンラインで検索するよ
うな業務、例えば、月締め処理で売掛金を集計して請求
書を起こし、その請求書をオンラインで参照するような
業務に本発明を応用したものである。図７に示した時点
で、制御テーブル４ｂにおいては、一つの表「ＤＢ４」
に対して４個のブロック６ｉ〜６ｌが割り当てられてい
る。各ブロック６ｉ〜６ｌは、それぞれ１ヵ月分のデー
タベースを保持し、図１における割当制御部２２によ
り、個別に割り当ておよび割り当て解除が可能である。
１ヵ月分のデータは、同一の時期に生成・削除されるか
ら、それぞれ同一のライフサイクルを持つ。

【００４３】制御テーブル４ｂでは、各ブロック６ｉ〜
６ｌに対して、各ブロックの更新可否に関する情報を管
理し、また、各ブロックの参照可否に関する情報も管理
している。更新可のブロックは、１時点では１個だけで
ある。これにより、データの追加先ブロックは自動的に
決まる。また参照は、更新が不可のブロックからのみ可
とされる。これにより、未確定のデータを参照すること
はない。

【００４４】図８は、図７における制御テーブル内容に
基づく本発明に係る動作例を示す説明図である。まず、
４月１日（４／１）に、今月（４月）分のデータを保持
するブロック「ＤＢ４ＢＬＫ４」を割り当てる。図７の
制御テーブル４ｂは、この状態を表している。続いて、
バッチ処理により、４月分のデータを追加する。バッチ
処理終了後、当ブロックを、更新不可、参照可とする。
そして、４月７日（４／７）に、保存期限を満了した１
月分データを保持するブロック「ＤＢ４ＢＬＫ１」を削
除する。

【００４５】本実施例によれば、次のような利点があ
る。 （い）データの参照と更新とは別のブロックに対して行
われる。これにより、排他制御は必要なくなる。したが
って、オンライン中でもバッチジョブが実行できる。 （ろ）データを１ヵ月ごとに分けて保持することができ
る。これにより、削除によって空いた領域は、有効活用
でき、再編成の必要がない。 （は）ブロックを実行時に与えることができるから、デ
ータベースの容量を随時変えられる。これにより、例え
ば、本番運転開始直後はスペースを小さくしておき、必
要に応じてスペースを拡張することができる。 尚、本実施例によると、オンライン参照時には複数組の
インデクスを辿る必要があるため、性能上は不利であ
る。しかし、マスタ型ＤＢと異なり、伝票型ＤＢでは、
一つのオンライントランザクションで参照する表の数は
少ないから、大きな問題とはならない。

【００４６】図９は、本発明のデータベース管理システ
ムの本発明に係る動作の第３の具体例を示す説明図であ
る。本例は、マスタ型ＤＢへの応用例であり、オンライ
ンでマスタデータが逐次追加・更新および参照されるよ
うな業務、例えば、得意先の住所・氏名・電話番号等の
情報を格納したマスタのメンテナンスおよび参照を行う
業務に応用したものである。図９に示した時点で、制御
テーブル４ｃにおいては、一つの表「ＤＢ５」に対して
４個のブロック６ｍ〜６ｐ（ＤＢ５ＢＬＫ１〜ＤＢ５Ｂ
ＬＫ４）が割り当てられている。このうち、「ＤＢ５Ｂ
ＬＫ１」はベースとなる情報を保持し、「ＤＢ５ＢＬＫ
２」〜「ＤＢ５ＢＬＫ４」はそれぞれある一定期間の更
新データを保持する。各ブロック６ｍ〜６ｐは、図１に
おける割当制御部２２により個別割り当ておよび割り当
て解除が可能である。

【００４７】制御テーブル４ｃでは、各ブロック６ｍ〜
６ｐに対して、各ブロックの更新可否に関する情報を管
理している。尚、参照可否に関する情報も管理している
が、本例では有効でない。更新可のブロックは、１時点
では１個だけである。これにより、データの追加先ブロ
ックは自動的に決まる。本例では、通常の制御テーブル
４ｃの他に、キーテーブル７を保持している。これは、
この表における各インデクス（いずれもユニークインデ
クスであり、かつ、レコードを特定するのに必要ない項
目を含まない）を構成するインデクス構成例を登録した
ものである。これは、後述するように、ある時点での最
新のデータを識別するために必要であり、予め作成して
おかなければならない。尚、厳密には、ここに登録する
のはインデクス構成例に限らず、任意のキー（キーでな
いスーパキーは不可）であって良いが、効率を考える
と、インデクス構成例に限るのが現実的である。

【００４８】ＤＢ５の各行には、先頭部８ｂに有効開始
日、有効終了日、更新日時を持つ。有効開始日と有効終
了日は、この更新がいつから有効になり、いつまで有効
であるかを示す。更新日時は、この更新を登録した日時
（システム日時）を示す。本例では、更新可のブロック
は１時点では１個だけである。そこで、既存データの更
新は、旧データを実際に更新することなく、更新可のブ
ロック「ＤＢ５ＢＬＫ４」に更新データを追加すること
により行う。本例の動作を次の図１０を用いて説明す
る。

【００４９】図１０は、図９における制御テーブル内容
に基づく本発明に係る動作例を示す説明図である。新し
いデータを追加するときは、単に、そのデータを「ＤＢ
５ＢＬＫ４」に追加する。この時、有効開始日、すなわ
ち、そのデータがいつから有効になるかを指定できる。
直ちに有効にしたければ、現在の日付けを指定する。来
月から有効にしたければ、来月１日を指定する。有効終
了日には、特に指定の必要がなければＭＡＸ値（９９９
・・・９）を指定しておけば良い。更新日時は、ミドル
ソフトでセットする。

【００５０】既存のデータを更新するときは、既存の行
はそのままにし、新たに「ＤＢ５ＢＬＫ４」に更新デー
タを追加する。この時、有効日を指定できる。データを
参照するときには、最新の更新を反映した行を選びだし
て要求元の業務プログラムに与える必要がある。参照に
際しては、業務プログラムは、図９におけるキーテーブ
ル７に登録されたいずれかのインデクスの構成例をキー
条件として指定し、その他に、検索対象日を指定する。
キー条件は、一つのインデクスの構成例を全て指定して
も良いし、その内の一部を指定しても良い。実際の検索
では、該当するインデクスを使い、指定されたキー条件
を満たし、かつ、検索対象日において有効な行を対象と
して読み出す。

【００５１】この時、該当するインデクスの各構成例の
順（キー条件に指定されているか否かに係らず、該当イ
ンデクスの構成例すべての順）に読み出す。各インデク
スは、その末尾に、更新日時を降順の構成例として含
む。従って、読み出される行は、他の構成例が同じな
ら、更新日時の降順にソートされているから、その中の
先頭の行をとれば、それが最新の更新を反映した行とな
る。既存データを削除するときは、既存の行はそのまま
にし、新たに「ＤＢ５ＢＬＫ４」に削除データ（削除フ
ラグを付けた行）を追加する。

【００５２】本例によれば、次のような利点がある。 （い）変更分のデータが一つのブロックに集中している
から、例えば、「本日分の新規顧客を一覧表にする」と
いった操作を効率良く行うことができる。 （ろ）更新する部分が限られているから、日次のバック
アップの対象を限定できる。 （は）既存のデータを更新しないから、更新履歴が残
る。これをトラブル対策に利用したり、監査証跡とする
ことができる。 （に）データベースの再編成のためにオンラインを停止
する必要がない。通常のマスタ型ＤＢでは、定期的にデ
ータベースの再編成が必要である。しかし、本例におい
ては、ブロックが多くなりすぎることを防ぐためと、古
いデータを削除するために、通常の再編成の代わりに、
定期的にブロックのマージによる再編成作業が必要であ
るが、この作業は、次のような手順をとることにより、

【００５３】手順１：まず新しいブロック「ＤＢ５ＢＬ
Ｋ５」を割り当てる（更新可、参照可）。 手順２：次に「ＤＢ１ＢＬＫ４」を更新不可とする。以
降、更新は「ＤＢ５ＢＬＫ５」に対して行う。 手順３：新しいブロック「ＤＢ５ＢＬＫ０」を割り当て
る（更新不可、参照不可）。 手順４：「ＤＢ５ＢＬＫ１」〜「ＤＢ５ＢＬＫ４」のデ
ータを「ＤＢ５ＢＬＫ０」にコピーする。その際に古い
データの消去を行う。この間、データベース参照は、
「ＤＢ５ＢＬＫ１」から「ＤＢ５ＢＬＫ５」を使ってお
り、「ＤＢ５ＢＬＫ０」は未だ使われていない。 手順５：「ＤＢ５ＢＬＫ１」〜「ＤＢ５ＢＬＫ４」を更
新不可、参照不可とし、「ＤＢ５ＢＬＫ０」を更新不
可、参照可とする。 手順６：「ＤＢ５ＢＬＫ１」〜「ＤＢ５ＢＬＫ４」を削
除する。以降のデータベース参照は、「ＤＢ５ＢＬＫ
０」と「ＤＢ５ＢＬＫ５」を使う。

【００５４】尚、この例によると、参照時には複数組の
インデクスを辿る必要があるため、性能上は不利であ
る。しかし、更新データ（「ＤＢ５ＢＬＫ２」〜「ＤＢ
５ＢＬＫ４」に格納されるデータ）のデータ量は少ない
から、これらのブロックのインデクスは、主記憶に常駐
させることができ、大きな問題とはならない。また、本
例では、参照に際して指定できる条件は、いずれかのイ
ンデクスの構成列に関するキー条件および検索対象日に
限られる。これは、それ以外の条件が指定されると、最
新の更新を反映した行が選択されない可能性が生じるた
めであり、ミドルソフトがデータベースに関する詳細情
報を知らないために生じる制約である。しかしデータベ
ース管理パッケージ自体に本発明に係る機能を設けた場
合には、この制約はない。

【００５５】図１１は、本発明のデータベース管理シス
テムの本発明に係る動作の第４の具体例を示す説明図で
ある。本例は、マスタ型ＤＢへの別の応用例であり、オ
ンラインでマスタデータが参照される一方で、他のシス
テムから追加・更新データがファイル転送されるような
業務、例えば、得意先の住所・氏名・電話番号等の情報
を格納したマスタの配布と、配布されたマスタの参照を
行う業務に応用したものである。

【００５６】図１１に示した時点で、制御テーブル４ｄ
においては、一つの表（ＤＢ６）に対して４個のブロッ
ク６ｑ〜６ｔが割り当てられている。このうち、「ＤＢ
６ＢＬＫ１」は、ベースとなる情報を保持し、「ＤＢ６
ＢＬＫ２」〜「ＤＢ６ＢＬＫ４」は、それぞれ、ある１
回のファイル転送で送られた更新データを保持する。従
って、それぞれのブロック６ｑ〜６ｔの中のデータはラ
イフサイクルを共にしている。各ブロック６ｑ〜６ｔ
は、図１における割当制御部２２により、個別に割り当
ておよび割り当て解除が可能である。

【００５７】制御テーブル４ｄでは、各ブロック６ｑ〜
６ｔに対して、各ブロックの更新可否に関する情報を管
理し、また、ブロックの参照可否に関する情報も管理し
ている。さらに、ブロックの優先順位を管理しており、
キー列の値が全て等しい行、または、キー列の内予め定
めた列の値が全て等しい行が、複数のブロックにまたが
って存在する場合、優先順位の最も高いブロック内の行
を有効とみなし、他のブロック内の行は、無効とみなし
て無視する。各ブロック６ｑ〜６ｔは、ファイル転送の
度に割り当てられ、転送中のみ更新可、参照不可とな
り、転送終了後は更新不可、参照可となる。本図１１の
制御テーブル４ｄは「ＤＢ６ＢＬＫ４」を使ってファイ
ル転送を受けている途中の状態を表す。

【００５８】本例では、制御テーブル４ｄの他に、キー
テーブル７ａを保持し、また、ＤＢ６の各行には、先頭
部８ｃに有効開始日、有効終了日を持つ。これらは、図
９におけるものと同じである。しかし図９における例
（先頭部８ｂ）と異なり、各行の先頭部８ｃに更新日時
は持っていない。これは、本例では、更新が一括して行
われ、その度にブロックを割り当てるので、最新データ
を識別するのに個々の行の新旧を意識する必要がないか
らである。

【００５９】図１２は、図１１における制御テーブル内
容に基づく本発明に係る動作例を示す説明図である。本
例では、更新データは「ＤＢ６ＢＬＫ４」にしか格納し
ない。そこで、図９における例と同じく、既存データの
更新は、旧データを実際に変更することなく、「ＤＢ６
ＢＬＫ４」に更新データを追加することにより行う。す
なわち、転送されたデータは、「ＤＢ６ＢＬＫ４」に順
次追加する。この時、既存データに含まれない新しいデ
ータであっても良いし、既存データの修正情報であって
も良い。そのいずれにせよ、データには、そのデータが
いつから有効になるかが指定されている。また、既存デ
ータを削除するときは、新たに削除データを追加する。

【００６０】データを参照するときには、最新の更新を
反映した行を選び出して、要求元の業務プログラムに与
える必要がる。参照に際しては、業務プログラムは、図
１１のキーテーブル７ａに登録されたいずれかのインデ
クスの構成列をキー条件として指定し、その他に、検索
対象日を指定する。キー条件は、一つのインデクスの構
成列を全て指定しても良いし、その内の一部を指定して
も良い。実際の検索では、該当するインデクスを使い、
指定されたキー条件を満たし、かつ、検索対象日におい
て有効な行を対象として読み出す。この時、該当するイ
ンデクスの各構成列の順（キー条件に指定されているか
否かに係らず、該当インデクスの構成列全ての順）に読
み出す。読み出し結果の中で、キー列（すなわち、イン
デクス構成列）の値が全て等しい行が複数のブロックに
またがって存在する場合、優先順位の最も高いブロッ
ク、すなわち、最も新しく転送されたブロック内の行を
検索結果とみなす。これが最新の更新を反映した行であ
る。

【００６１】本例によれば、次のような利点がある。 （い）データの参照と更新とは、別のブロックに対して
行われる。これにより、排他制御は発生しなくなる。従
って、オンライン中にファイル転送を行っても差し支え
ない。 （ろ）更新は別のブロックに対して行われるから、更新
に備えて予め予備スペースを確保しておく必要がなくな
る。 （は）図９における例と同様に、データベースの再編成
のためにオンラインを停止する必要がない。

【００６２】尚、本例によると、参照時には複数組のイ
ンデクスを辿る必要があるため、性能上は不利である。
しかし、更新データ（「ＤＢ６ＢＬＫ２」〜「ＤＢ６Ｂ
ＬＫ４」に格納されるデータ）のデータ量は少ないか
ら、これらのブロックのインデクスは、主記憶に常駐さ
せることができ、大きな問題とはならない。また本例で
は、参照に際して指定できる条件は、いずれかのインデ
クスの構成列に関するキー条件および検索対象日に限ら
れる。これは、それ以外の条件が指定されると、最新の
更新を反映した行が選択されない可能性が生じるためで
あり、ミドルソフトがデータベースに関する詳細情報を
知らないために生じる制約である。データベース管理パ
ッケージ自体に本発明に係る機能を設けた場合には、こ
の制約はない。

【００６３】図１３は、本発明のデータベース管理シス
テムの本発明に係る動作の第５の具体例を示す説明図で
ある。本例は、マスタ型ＤＢへのさらに別の応用例であ
り、市販のマスタに独自のデータを追加して使用するよ
うな業務、例えば、市販の金融機関マスタに郵便局の情
報を独自に追加して使う業務に応用したものである。図
１３に示した時点で、制御テーブル４ｅにおいては、一
つの表（ＤＢ７）に対して２個のブロック６ｕ、６ｖが
割り当てられている。このうち、「ＤＢ７ＢＬＫ１」
は、市販データを保持し、「ＤＢ７ＢＬＫ２」は、独自
データを保持する。従って、それぞれのデータはライフ
サイクルが異なる。

【００６４】制御テーブル４ｅでは、各ブロック６ｕ、
６ｖに対して、ブロックの更新可否に関する情報を管理
している。更新は独自データに対してだけ可能である。
また、ブロックの優先順位を管理しており、キー列の値
が全て等しい行、または、キー列の内、予め定めた列の
値が全て等しい行が複数のブロックにまたがって存在す
る場合、優先順位の高い方のブロック内の行を有効とみ
なし、他のブロック内の行は、無効とみなして無視す
る。本例では、通常の制御テーブル４ｅの他に、キーテ
ーブル７ｂを保持する。これらは、図９で示した例にお
けるものと同じである。尚、図９で示した例と異なり、
各行の先頭部８ｄに固定情報は持っていない。

【００６５】図１４は、図１３における制御テーブル内
容に基づく本発明に係る動作例を示す説明図である。本
例では、新しいデータを追加するときは、単にそのデー
タを「ＤＢ７ＢＬＫ２」に追加する。また、既存のデー
タを更新するときは、それが「ＤＢ７ＢＬＫ２」にあっ
た場合（すなわち独自データの場合）は、単にそのデー
タを更新する。そうでなければ、既存の行はそのままに
し、新たに「ＤＢ７ＢＬＫ２」に更新データを追加す
る。データを参照するときには、独自データを優先する
必要がある。そのため、条件に合致する行が両ブロック
にまたがって存在する場合、優先順位の高いブロック、
すなわち、「ＤＢ７ＢＬＫ２」内の行（独自データ）を
検索結果とみなす。既存データを削除するときは、既存
の行はそのままにし、新たに「ＤＢ７ＢＬＫ２」に削除
データ（削除フラグを付けた行）を追加する。

【００６６】本例によれば、次のような利点がある。 （い）市販データと独自データを分けて扱える。このた
め、例えば市販データが改訂された場合、改訂後のデー
タを単に市販データ格納ブロック（ＤＢ７ＢＬＫ１）に
上書きすれば良く、独自データは影響を受けない。尚、
本例によると、参照時には複数組のインデクスを辿る必
要があるため、性能上は不利である。しかし、独自デー
タ（「ＤＢ７ＢＬＫ２」に格納されるデータ）のデータ
量は少ないから、これらのブロックのインデクスは、主
記憶に常駐させることができ、大きな問題とはならな
い。また本例では、参照に際して指定できる条件は、い
ずれかのインデクスの構成列に関するキー条件および検
索対象日に限られる。これは、それ以外の条件が指定さ
れると、最新の更新を反映した行が選択されない可能性
が生じるためであり、ミドルソフトがデータベースに関
する詳細情報を知らないために生じる制約である。デー
タベース管理パッケージ自体に本発明に係る機能を設け
た場合には、この制約はない。

【００６７】以上、図１〜図１４を用いて説明したよう
に、本実施例のデータベース管理システムでは、データ
をそのライフサイクルに沿って自然に管理することがで
きる。これにより、データベース管理の都合により、業
務的には本来不要なデータを検索したり、業務的には本
来不要な排他を行ったりすることがなくなり、性能上有
利となる。また、ある時点で更新される部分を局限する
ことにより、再編成やバックアップ等の運用上有利とな
り、また、効率良い一括削除ができる。さらに、市販デ
ータと独自データの用に、その起源を異にするデータを
分けて扱うことにより、運用上、便利となる。尚、本発
明は、図１〜図１４を用いて説明した実施例に限定され
るものではなく、その要旨を逸脱しない範囲において種
々変更可能である。

【００６８】

【発明の効果】本発明によれば、データをグループ単位
に独立したブロックに分けて格納すること、および、こ
のように格納したデータを、実行時（検索時）に動的に
連結することができ、データを無理に一つのブロックに
格納する必要がなくなり、システムの性能や運用性を向
上させることが可能である。

【図面の簡単な説明】

【図１】本発明のデータベース管理システムの本発明に
係る構成の第１の実施例を示すブロック図である。

【図２】図１におけるデータベース管理システムの本発
明に係る動作例を示す説明図の前半部である。

【図３】図１におけるデータベース管理システムの本発
明に係る動作例を示す説明図の後半部である。

【図４】本発明のデータベース管理システムの本発明に
係る構成の第２の実施例を示すブロック図である。

【図５】本発明のデータベース管理システムの本発明に
係る動作の第１の具体例を示す説明図である。

【図６】図５における制御テーブル内容に基づく本発明
に係る動作例を示す説明図である。

【図７】本発明のデータベース管理システムの本発明に
係る動作の第２の具体例を示す説明図である。

【図８】図７における制御テーブル内容に基づく本発明
に係る動作例を示す説明図である。

【図９】本発明のデータベース管理システムの本発明に
係る動作の第３の具体例を示す説明図である。

【図１０】図９における制御テーブル内容に基づく本発
明に係る動作例を示す説明図である。

【図１１】本発明のデータベース管理システムの本発明
に係る動作の第４の具体例を示す説明図である。

【図１２】図１１における制御テーブル内容に基づく本
発明に係る動作例を示す説明図である。

【図１３】本発明のデータベース管理システムの本発明
に係る動作の第５の具体例を示す説明図である。

【図１４】図１３における制御テーブル内容に基づく本
発明に係る動作例を示す説明図である。

【符号の説明】

１：業務プログラム、１ａ〜１ｎ：業務プログラム内の
ＤＢ処理、２：ミドルソフト、２ａ〜２ｈ：ミドルソフ
トが実行する処理、２ｘ：ＳＱＬＩＤテーブル、３：デ
ータベース管理パッケージ、３ｉ〜３ｎ：データベース
管理パッケージが実行する処理、４〜４ｅ：制御テーブ
ル、５：データベース管理パッケージから見たデータベ
ース定義、６ａ〜６ｖ：ブロック、７〜７ｂ：キーテー
ブル、８〜８ｄ：行の先頭部、２１：行併合部、２２：
割当制御部

Claims (3)

【特許請求の範囲】
1. 【請求項１】 インデクスによる行検索、もしくは、ハ
   ッシングによる行検索のいずれかにより、要求元が指定
   した条件に合致する行を、外部記憶装置に格納された表
   の中から検索するデータベース管理システムにおいて、
   既存の１つのデータベースを、操作者からの指示に基づ
   き、それぞれ同一のインデクスもしくはハッシングを有
   する２以上のブロックに分割して格納する手段と、行検
   索時に、上記同一のインデクスもしくはハッシングを用
   いて、上記各ブロック毎の検索を行い、該検索で得た各
   ブロックの各行を併合して、単一の検索結果として出力
   する手段とを設けることを特徴とするデータベース管理
   システム。
2. 【請求項２】 請求項１に記載のデータベース管理シス
   テムにおいて、操作者からの指示に基づき、上記各ブロ
   ックの割当および割当解除を、個別に行う手段を設ける
   ことを特徴とするデータベース管理システム。
3. 【請求項３】 請求項１、もしくは、請求項２のいずれ
   かに記載のデータベース管理システムにおいて、上記各
   ブロックの識別情報と、該ブロックに格納すべき行の条
   件に関する情報と、該ブロックの参照の可否および更新
   の可否に関する情報と、各ブロック間に予め定めた優先
   順序情報とを、操作者からの指示に基づき登録する制御
   テーブルを設け、行の格納に際して、該行が、格納すべ
   き行の条件に合致する場合もしくは上記ブロックが更新
   可の場合に、該ブロックに上記行を格納し、行の検索に
   際して、上記ブロックが参照可の場合に、該ブロック内
   の表を検索対象とし、キー列の値が全て等しい行、もし
   くは、キー配列のうち予め定めた１つの値が全て等しい
   行が、複数のブロックにまたがって存在する場合には、
   上記優先順序情報に従い、最も高い優先順序のブロック
   内の行を有効とみなし、他のブロック内の行は無効とみ
   なして無視することを特徴とするデータベース管理シス
   テム。