JPH04182749A - 関係型データベースのデータ格納方式 - Google Patents

Abstract

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

Description

【発明の詳細な説明】 ［産業上の利用分野］ 本発明は、関係型データベースのデータ格納方式に係り
、特に、可変長データを短いアクセスタイムで効率よく
読み書きできる関係型データベースのデータ格納方式に
関する。

［従来の技術］ 一般に、データベース管理システム（以下ＬｔＤＢＭＳ
’”と略記する）は、整数、実数９日時２文字列等の多
様なデータ型のデータをデータベース（以下ｒｔ　Ｄ　
Ｂ　ｕと略記する）に格納して管理する。

さらに近年は１文書９図形９画像、音声等の膨大なデー
タも格納するようになっており、最大可変長データの格
納が重要になって来ている。

第３図は、従来のＤＢにおける可変長データを格納する
レコードの構造例を表わす図である。レコードは、該レ
コードの格納部３０１、及び各項目の格納領域３０２か
ら構成されている。また、前記各項目の格納領域３０２
は、該項目の格納部３０３、及びデータ格納領域３０４
から構成されている。なお、Ｌａ、・・・・・＋Ｌ＋１
は項目ａ、・・・・・・ｎの格納部、Ｌはレコード長で
ある。

第４図は、従来のＤＢＭＳのシステム構成例を表わす図
である。まず、アプリケーションプログラム４００から
、コマンドがＤＢＭＳ４０１に渡される。次に、Ｄ　Ｂ
Ｍ　Ｓ　４０１内の処理制御部４０２が、渡されたコマ
ンドに応じて定義処理部４０３、又はデータ処理部４０
４を選択し、処理を依頼する。

定義処理部４０３では、定義制御部４０５がコマンドに
応じて表生成部４０６等を選択して、処理を依頼する。

表生成部４０６は、ＤＢ４Ｌ５内の項目定義情報ファイ
ル４１６に定義情報を格納する。

データ処理部４０４では、データ処理制御部４０７がコ
マンドに応じて検索処理部４０８、格納処理部４１０、
変更処理部４１２、又は削除処理部４１３を選択して、
処理を依頼する。検索処理部４０８には、ＤＢ４１５内
のデータファイル（例えばデータファイルＡ４１７）の
レコードを検索後、前記検索されたレコードから項目値
を取り出す項目値検索部４０９等がある。格納処理部４
１０には、ＤＢ４１５内のデータファイル（例えばデー
タファイルＡ４１７）のレコードに項目値を格納する項
目値格納部４１１等がある。削除処理部４１３には、Ｄ
Ｂ４１５内のデータファイル（例えばデータファイルＡ
４１７）のレコードから項目値を削除する項目値削除部
４１４等がある。

通常、データファイルを格納するディスク装置に対する
入力／出力回数（Ｉ１０回数）を減少させ、処理効率を
向上させるために、いくつかの可変長のレコードを１つ
の固定長のブロック（−回のアクセスで読み書きできる
単位）にまとめて、ブロック単位でＩｌｏを行っている
。したがって、項目はレコードに、レコードはブロック
に、納まらなければならないという制限が生じる。しか
し、ブロック長より長い可変長データを１つの項目に格
納したい場合がある。そのためのデータ格納方法が求め
られている６　　　　　　　　　　　、−５可変長デー
タの格納方式として１例えば特開昭６３−８６０２５号
公報に記載されている方式がある。この方式は、関係表
すなわち関係型データファイルに項目の１つとしてポイ
ンタ格納項目を設け、この項目の各欄（各セル）毎に１
文書データまたは画像データが格納されている別々の外
部ファイルを特定する外部ファイルポインタを格納する
ものである。

また、不定長のデータの格納方式として、例えば特開昭
６２−２４３０３３号公報に記載されている方式がある
。この方式では、データの格納領域を第１のデータ格納
領域（主メモリ）及び第２のデータ格納領域（従メモリ
）により構成し、不定長のデータを所定長（固定長）分
と余り分に分ける。そして、第１のデータ格納領域に、
所定長分のデータを格納すると共に、該所定長分に対応
する余り分データの格納される第２のデータ格納領域の
アドレスデータを格納し、第２のデータ格納領域には、
この対応する余り分データの数及び余り分データを格納
する。

［発明が解決しようとする課題］ 上記第３図のデータ構造により、いくつかの可変長レコ
ードをまとめて固定長ブロックとして格納する従来方式
（第１従来技術）では、以下の問題点があった。まず、
稀に発生する非常に長いデータを有する項目を含むレコ
ードを収容できるようにするために、所定（固定）ブロ
ック長を非常に長く取っておくと、記憶容量の限られた
ブロック読み込みバッファに格納することができるブロ
ック数が少なくなってしまうので、ファイルとの間のブ
ロックＩ１０回数が増加し、処理性能が劣化するという
問題があった。また、逆に、所定ブロック長を短くして
おいてブロン９１フ０回数の増加を防ぐようにすると、
稀に発生する非常に長いデータを１つの項目のデータ格
納領域内に格納することができないという問題があった
。

上記特開昭６３−８６０２５号公報の従来方式（第２従
来技術）では、データ本体（文書データまたは画像デー
タ）を外部ファイルに格納することにより、データファ
イル（関係表）中には前記外部ファイルへの短いポイン
タのみを格納するだけでよいので、ブロック長を長くし
なくても非常に長いデータに対応することができる。し
かし、この方式では、データ長が短くてデータファイル
のセル（ます目）内に納まる場合であってもデータ本体
をことごとく外部ファイルに格納しているため、常に、
この外部ファイルへのオープン／リード／ライト／クロ
ーズが発生し、大きなオーバヘッドを要するという問題
があった。

また、上記特開昭６２−２４３０３３号公報の従来方式
（第３従来技術）では、ＤＢへの適用について言及され
ていないが、これをＤＢに適用しようとすると以下の問
題が生じる。まず、データファイルに格納する固定要分
データのデータ長は性能に大きく影響するが、このデー
タ長をいつ誰が如何なる長さに決定するかについて、具
体的には何も考慮されていない。また、残りの可変要分
データの追加、更新（特に、拡張、縮小）、または削除
を行う際に、これらの処理を効率的に行わせるための領
域管理手段について何も配慮されていないという問題が
あった。

したがって、本発明の目的は、上記第１従来技術の問題
点を解消し、所定ブロック長を増加することなしに、長
大データの格納を実現する関係型データベースのデータ
格納方式を提供することにある。

本発明の他の目的は、上記第２従来技術の問題点を解消
し、可変長データが短い多くの場合に、オーバヘッドを
増大することなくデータの格納ができると共に、稀に発
生するブロック長の非常に長いデータ（長大データ）も
格納することが実現されるようにする関係型データベー
スのデータ格納方式を提供することにある。

本発明のさらに他の目的は、上記第３従来技術の問題点
を解消し、ごく稀に発生する長大データの格納は考慮さ
れていない通常のＤＢＭＳと同規模のＤＢＭＳを用いて
（これまでのＤＢＭＳの規模を大幅に増加しないで）、
オーバヘッドを増大することなく長大データの格納を実
現することのできる効果的な領域管理手段をもった関係
型データベースのデータ格納方式を提供することにある
。

［課題を解決するための手段］ 上記目的を達成するため１本発明の関係型データベース
のデータ格納方式では、データベースは可変長データの
少なくとも一部をレコード単位で格納するデータファイ
ル及びあふれデータをレコード単位で格納するあふれフ
ァイルを有している。

そして、このあふれファイルのデータ構造は、データフ
ァイルのデータ構造と物理的に同一のデータ構造とされ
ている。すなわち、このデータファイルのレコードは、
前記可変長データの少なくとも一部（所定要分）のほか
に（データ長が所定長を越えるため）、あふれファイル
の利用が予め設定された項目について、対応するあふれ
データの格納されるあふれファイルのレコードを指示す
るレコード指示情報（ポインタ情報）を格納し、あふれ
ファイルのレコードは、当該あふれファイルレコードで
更にあふれたデータがあるとき、前記対応するあふれデ
ータのほかに、前記更にあふれたデータの格納される前
記あふれファイル内の他のレコードを指示する他のレコ
ード指示情報（他のポインタ情報）を格納するように構
成する。

データ長が所定長を越えたときの、前記あふれファイル
の利用の設定は、ユーザ入力装置からの指示により行わ
れるように構成する。

また、このあふれファイルの利用の設定は、１レコード
における項目長の合計が最大レコード長を越えるデータ
ファイルに対し、データベース管理システムが持つ優先
度によって行われるように構成する（第６図参照）。

［作用］ 上記構成に基づく作用を説明する。

格納すべき可変長データがデータファイル内に格納しき
れない場合、格納しきれなかったデータ（あふれデータ
）があふれファイル内のレコードに格納される。また、
データファイル内の当該項目には、前記可変長データの
一部（所定要分）と、前記あふれファイル内の当該レコ
ードのレコード指示情報（レコード識別情報）とが格納
される。

前記あふれファイル内のレコード（すなわち、先頭レコ
ード）に格納しきれないとき（更にあふれたとき）には
、更にあふれた分のデータをあふれファイル内の２番目
のレコードに格納し、あふれファイル内の先頭レコード
には、あふれデータの一部（所定要分）と、前記２番目
のレコードに対するレコード指示情報とが格納される。

以下同様にして、データファイル内のレコード、あふれ
ファイル内の先頭レコード、同じく２番目のレコード、
・・・・・・を繋ぐレコードチエインが構成される。

データファイル内の他のレコードについても、同様にレ
コードチエインが作成される。

このようにして、たまに、極く長大なデータ長を有する
データが混在する可変長データをデータベースに格納す
る場合でも、データファイル及びあふれファイル中の各
レコードに格納されるレコード指示情報は十分に短く、
しかも、これら両ファイルのレコード中に残されるデー
タの一部は、十分に短く調整されて、それにより各レコ
ード長が短くされてそれらレコード列で構成されるブロ
ック長を所定ブロック長に収まるようにすることができ
るので、ブロック長を増加することなしに、長大データ
の格納を実現することができる。

また、格納する可変長データが短くて該可変長データを
データファイル内に格納しきれる多くの場合には、あふ
れファイルを使用しないで、前記可変長データの全デー
タをデータファイルに格納する。これにより、格納する
可変長データが短くてデータファイル内に格納しきれる
多くの場合には、あふれファイルへのオープン／リード
／ライト／クローズが発生することはない。

［実施例コ 以下に、本発明の実施例を図面によって説明する。

第１図は、本発明の一実施例によるＤＢＭＳの構成例を
表わす図である。第２図（ａ）〜（ｃ）は１本実施例に
よる可変長データのＤＢへの格納構造図である。

第１図において、第４図と同一名称の要素には同一符号
を付して説明を省略するが、本実施例では、ＤＢ４１５
内にあふれファイル１０５を設けると共に、ＤＢＭＳに
おいて、定義処理部４０３内の表生成部４０６に、あふ
れファイル１０５に関する処理を行うために、内部的に
あふれオプション２０５（第２図（ａ））の設定を行う
あふれオプション設定部１０１を加え、更に、データ処
理部４０４内の項目値検索部１ｏ６（従来の項目値検索
部４０９に若干の処理が追加される）にあふれファイル
１０５への検索処理を行うあふれ項目検索部１０２を加
え、データ処理部４０４内の項目値格納部１０７（従来
の項目値格納部４１１に若干の処理が追加される）にあ
ふれファイル１０５へのデータの格納を行うあふれ項目
格納部１０３を加え、データ処理部４０４内の項目値削
除部１０８（従来の項目値削除処理部４１４に若干の処
理が追加される）にあふれファイル１０５の削除を行う
あふれ項目削除部１０４を加える。本実施例では、この
あふれファイル１０５のデータ構造を、ＤＢＭＳ４０１
で管理されているデータファイルＡ４１７゜Ｂ、Ｃ，・
・・・・・等と物理的に同一のデータ構造にすることを
特徴としている。

第２図（ａ）は、第１図のＤＢ４１５に格納される項目
定義情報ファイル４１６の一例の格納構造図である。項
目定義情報ファイル４１６には、ファイルＡの定義情報
だけでなく、全てのデータファイルＡ、Ｂ、Ｃ，・・・
・・・及びあふれファイルの項目の定義情報が格納され
ている。項目定義情報ファイル４１６は、項目名列２０
２、データ型列２０３、及び定義項目長月２０４に加え
て、あふれオプション列２０５及びこれらの項目の所属
するファイルを特定する所属ファイル名列２０１から構
成されている。（従来の第２図（ｂ）に示すように）一
般のデータファイルＡ、Ｂ、Ｃ，・・・・・・は、１つ
のデ−タレコードを単位として読み書きの処理を行うが
、第２図（ａ）の項目定義情報ファイル４１６自体も「
所属ファイル名」、「項目名」、「データ型」、「定義
項目長」、「あふれオプション」という５個の項目から
構成されている一種のデータファイルとして扱うことが
できる。従って、１つのデータレコードを単位として読
み書きを行う一般のデータファイルと同様に、項目定義
情報ファイルも読み書き処理はレコード単位で行われる
。

この場合のレコード単位は、２０６，２０７．・・・・
・・等であり、例えば、データファイルＡは項目ａない
しｎから成っており、項目〇についての定義情報はレコ
ード２０６に格納されており、あふれファイル１０５の
項目０についての定義情報はレコード２０７に格納され
ている。

第２図（ｂ）は、第１図のＤＢ４１５に格納されるデー
タファイル、例えば１つのデータファイルＡ４１７を構
成しているデータレコード群中の１データレコードを示
している。第２図（ｂ）のデータレコードは、レコード
長３０１と、各項目の格納領域３０２とから構成されて
おり、各項目の格納領域３０２は、項目ａ−ｎの各項目
毎に、項目長３０３と、項目値格納領域２０８とから構
成されている。各項目値の格納領域２０８は、格納され
るデータ量によって、以下の３つの形態がある。

１つは項目ｉに該当するデータが存在しない場合で、デ
ータファイルのレコード内に項目ｉの格納領域自体が存
在しない。２つは、あふれファイルを使用する項目とな
っていても、データファイルのレコードだけで全データ
が格納しきれる場合で、データファイルのレコード項目
ｉの項目値格納領域に項目ｉのデータを格納し、データ
ファイルのレコードの項目ｉのレコードポインタには０
を入らない）。３つは、データファイルのレコードだけ
では全データが格納しきれない場合で、第２図（ｂ）　
、　（Ｃ）にこの場合が示される。例えば、項目ｎの場
合のように、当該項目があふれファイル１０５を使用す
る場合には、項目値格納領域２０８は、あふれファイル
１０５のレコードへのレコードポインタを格納する領域
２０９と、データ格納領域（データ本体の格納領域）３
ｏ４とから構成される。また、例えば項目ａのように、
当該項目があふれファイル１０５を使用しないデータフ
ァイルの項目である場合には、項目値格納領域２０８は
、データ格納領域（データ本体格納領域）３ｏ４のみが
ら構成される。

第２図（ｃ）は、第１図のＤＢ４１５に格納されるあふ
れファイル１０５のレコードの一部（第２図（ｂ）の１
データレコードにチエインされるあふれレコード部分）
のデータ構造を示している。本実施例の特徴として、各
データファイルＡ、Ｂ。

Ｃ４・・・・・・から発生するあふれデータは、あふれ
データ専用のあふれファイルにまとめて格納される。

また、あふれファイル１０５のデータ構造は、データフ
ァイルＡ４１７．・・・・・・等のデータ構造と基本的
に同一とされる。但し、結果的には、当該項目があふれ
内項口０である場合には、いずれの項目値格納領域も、
レコードポインタを格納する領域とデータ格納領域とか
ら構成される。例えば第２図（ｃ）のあふれファイル１
０５のレコードの１つは、レコード長（ＭＬ）３０Ｌａ
と項目格納領域（項目○）３０２ａとから成り、項目格
納領域（０）３ｏ２ａは、項目長（ｍｌ）３０３ａと項
目値格納領域２０８　ａとから成り、当該項目（０）が
更に当該あふれファイル１０５内の他のあふれレコード
を使用する場合には、項目値格納領域２０８ａは、他の
あふれレコードのポインタ（ｒ□）を格納する領域２０
９ａとデータ格納領域３０４ａとから構成され、当該項
目（０）がもはや更に他のレコードを使用（参照）しな
い場合には、その項目値格納領域のレコードポインタに
は０が格納される。以下同様にして、データファイルＡ
４１７の１レコードと同様なデータ構造を有するあふれ
レコードが、ポインタｒｏ、ｒｌ、ｒ２．・・・・・・
によって連結される。

第５図は１本発明の実施例による定義部分の一部の処理
で使用するデータ構造例を示す。同図で、５０１は項目
定義情報配列で、この項目定義情報配列５０１は、項目
名配列Ｎ　（ｎ）２０２　（ｎは定義する項目数）と、
データ型配列Ｔ（ｎ）２０３と、定義項目長配列Ｌ（ｎ
）２０４と、あふれオプション配列０　（ｎ）２０５と
から構成されている。あふれオプション０（ｎ）２０５
の設定は、他の項目の定義情報（例えば項目名Ｎ　（ｎ
）と同じ時に操作者により行われる。

第６図は、オプション設定部で行う定義部分の一部の処
理を示すフロー図、特に、あふれオプションが未だ明示
的に１１　Ｑ　Ｎ　ＩＩにされていない場合に、必要に
応じて定義項目長が最大である項目のうち、新しく定義
された項目から順次自動的にあふれオプションを○Ｎ　
＋１にして行く処理をフロー図で示したものである。

まず、第６図で用いている用語について説明する。

１′最大レコード長″：データファイルの１レコードの
物理的な最大炎（処理システムで予め定められている）
からレコード長格納領域長を引いた値である。

″最大可能レコード長Ｓパ二項目定義（定義項目長）ま
たはあふれファイル使用項目の最低確保長（処理システ
ムで固定の値であり、変更されない）から求められる１
レコードを格納するのに要するサイズである。但し、レ
コード長格納領域長は含まない。

ｄ・最大項目長Ｍ″′二項目定義長のうち、最大の項目
長であ、る。ここで、「無制限」は数学で通常用いる「
ω」とほぼ同等であるが、「無制限」同士は比較可能（
同一とする）である。

゛あふれファイル使用項目の最低確保長ｎｏ　Ｑ　”（
ミニマム・オーバフロー・レングス）：あふれファイル
使用項目（あふれファイルを使用して緑）る項目、すな
わち、あふれオプションがＯＮになっている項目）のデ
ータレコードのうちの項目値格納領域長をいう。データ
量があふれファイル使用項目の最低確保長以下の場合（
データファイルのレコードで全データが格納しきれる場
合、すなわち、前記２つ目の形態の場合）、あふれファ
イルを使用することはない。

″変数ｊ″：自動的にあふれオプションを′ＯＮ　ＩＩ
にする項目の定義情報が格納されている項目定義情報配
列５０１の要素番号を表わす。ステップ６０５の段階で
は、まだ候補の段階のものである。

次に、第６図により、定義の一部の処理の動作を説明す
る。表生成部４０６は、今回定義するデータファイルに
ついて、定義する項目数ｎ、及び。

第５図で表わされるような項目定義情報配列５０１をあ
ふれオプション設定部１０１に渡す。あふれオプション
設定部１０１は、以下の定義の処理をする。

ステップ６０１： まず、最大可能レコード長ＳをＯで、最大項目長Ｍをあ
ふれファイル１０５使用項目の最低確保長ｌｌ０Ｑで、
カウンタ値ｉ（要素番号）を１で、変数ｊをＯで、それ
ぞれ初期化する。

ステップ６０２： 次に、項目定義情報配列５０′１の第１番目の要素のあ
ふれオプション○（ｉ）がＩｔ　Ｑ　Ｎ　ＰＩならステ
ップ６０６に進み、／ｌ　ＯＮ　ＩＩでないならステッ
プ６０３に進む。

ステップ６０３： 最大可能レコード長Ｓをり、　（ｉ　）分（正確にはＬ
（ｉ）＋Ｌｃ１分）増加してｓ＋ｒ、（ｉ）十項目長格
納領域長Ｉ、　ｄとする。

ステップ６０４： 項目定義情報配列５０１の第ｉ要素の項目定義長Ｌ　（
ｉ）とそれまでの定義項目長の最大値Ｍとの比較を行う
。この定義項目長Ｌ　（ｉ）が最大の場合はステップ６
０５に進み、そうでない場合はそのままステップ６０７
に進む。

ステップ６０５： このステップに処理が移るのは当該定義項目長Ｌ　（ｉ
）が最大の場合であり、この場合、あふれオプションを
自動的に“ＯＮ　ＰＩにする項目の候補の項目定義情報
配列の要素番号ｉを変数ｊに保存し、定義項目長の最大
値Ｍに１、（ｉ）を設定する。

ステップ６０６： ステップ６０２であふれオプションが”ＯＮ”の項目で
は、データレコードに、最大で「あふれファイル使用項
目の最低確保長ｍｏＱ分−レコードポインタ格納長」の
データしか格納されない。そこで、本ステップでは、最
大可能レコード長Ｓを更新して、Ｓにあふれファイル使
用項目の最低確保長ｌ　ｍｏ　Ｑ分を加算したものを入
れる（厳密には、これに項目値格納領域長Ｌｄも加わる
）。

ステップ６０７．６０８： 次に、全定義項目についての処理が終了したか判定し、
終了していないときは、ステップ６０８で要素番号ｉを
１増加してステップ６０２に戻る。

全定義項目についての処理が終了したときはステップ６
０９に進む。

ステップ６０９： 最大可能レコード長Ｓ（データ量）がデータレコード内
に収まりきるかどうかの判定を行う。収まりきるとき（
Ｓが最大レコード長を越えないとき）は１本処理を終了
する。

ステップ６１１ニ ステップ６０９で、データレコード内に収まりきらない
ときは、本ステップの処理を行う６本ステップで、変数
ｊがＯ（初期値のまま）とは、あふれオプションを自動
的に１１　Ｑ　Ｎ　Ｉ＋にする新たな項目の候補がない
ことを表わす。

ステップ６１２： 本ステップで、新たにあふれオプションを自動的にｌ（
ＯＮ　ＴＴにする項目の候補のあふれオプション○（ｊ
）をＯＮ”にし、再度あふれオプション設定部１０１　
Ｃコよる設定を行って、本処理を終了する。

ステップ６１３： 本ステップは、データレコードに収まりきらず、かつ新
たにあふれオプションを′○Ｎ”にする項目の候補がな
い場合であり、ｊが初期値のままであるため定義長が長
すぎて格納しきれないと判断し、エラーコードをセット
して本処理を終了する。

本処理によって、項目長の合計が最大レコード長の制限
を越える場合について、明示的にあふれファイル１０５
を使用する指定がされていなくても、与えられた定義項
目長の合計が最大レコード長を越える場合、自動的にあ
ふれオプションを“ＯＮ”にして行くことにより、あふ
れファイル１０５を使用するようにできる。ここで、自
動的にあふれオプションを“ＯＮ”にしていく順序を「
優先度」という。第６図では、定義項目長が最大である
項目のうち、新しく定義された項目から順次“ＯＮ”に
されて行く。

第７図は、項目値格納部１０７及びあふれ項目格納部１
０３の処理手順の一例を示すフローチャートである。

項目値格納部１０７では、格納処理を行う項目（処理対
象項目）に全データを格納しきれるか否か判定する（ス
テップ７０１）。格納しきれないと判定された場合には
、あふれ項目格納部１０３に進み、格納しきれると判定
された場合には、ステップ７０２に進み、ここで、処理
対象項目のあふれオプションが“ＯＮ”であるか否か判
定して、処理対象項目のあふれオプションが○Ｎ　１７
でない場合には、従来の項目格納部４１１のみによる処
理を行って、本処理を終了する。ステップ７０２で、処
理対象項目のあふれオプションが“ＯＮ”である場合に
は、処理対象項目のデータ格納領域３０４（第２図（ｂ
））に位置付け（ステップ７０３）。

しかる後、従来の項目格納部４１１による処理を行って
、本処理を終了する。

あふれ項目格納部１０３では、まず、処理対象項目のレ
コードポインタ２ｏ９（第２図（ｂ））に。

あふれファイル１０５の未使用レコードポインタを設定
する（ステップ７０４）。次に、処理対象項目のデータ
格納領域３０４に、可能な限りデータを格納する（ステ
ップ７０５）。次に、あふれファイル１０５内の項目０
を新たに処理対象項目とする（ステップ７０６）。次に
、項目格納部１０７を再び使用して、ステップ７０５で
格納できなかった残りのデータを格納して（ステップ７
ｏ７）、本処理を終了する。

第８図は、項目値検索部１０６及びあふれ項目検索部１
０２の処理手順の一例を示すフローチャートである。

項目値検索部１０６では、検索処理を行う項目（処理対
象項目）のあふれオプションが１１０　Ｎ　ＩＩか否か
判定して（ステップ８０１）、処理対象項目のあふれオ
プションが”　ＯＮ”でないならば、従来の項目値検索
処理部４０９による処理を行って、本処理を終了し、処
理対象項目のあふれオプションが“ＯＮ”であるならば
、あふれ項目検索部１０２による処理を行って、本処理
を終了する。

あふれ項目検索部１０２では、まず、処理対象項目のデ
ータ格納領域３０４（第２図（ｂ））に位置付けて（ス
テップ８０２）、再び項目値検索部１０６を使用して処
理対象の項目のデータ格納領域３０４のデータを読み出
す（ステップ８０３）。次に、処理対象項目に格納され
ているレコードポインタが“０”か否か判定する（ステ
ップ８０４）。処理対象項目に格納されているレコード
ポインタがｕ　Ｏ”ならば１本処理を終了する。ステッ
プ８０４で、処理対象項目に格納されているレコードポ
インタが“０”でないならば、あふれファイル１０５内
の項目０を新たに処理対象項目として（ステップ８０５
）、あふれ項目検索部１０２による処理を再び行って、
本処理を終了する。

第９図は、本発明の他の実施例による可変長データのＤ
Ｂへの格納構造図である。第９図（ａ）は項目定義情報
ファイル４１６、第９図（ｂ）はデータファイルＡのレ
コード、第９図（ｃ）はあふれファイルのレコードをそ
れぞれ示している。

第２図の実施例では、あふれファイル１０５を使用する
各項目毎に、レコードポインタを格納する領域２０９を
設けている。こ九に対し、第９図の実施例では、各項目
に関するレコードポインタを、レコードに１つ存在する
レコードポインタ格納領域９０１にまとめ格納するよう
にしたものである。格納処理、読み呂し処理等、そのほ
かのデータ処理は、第２図のデータ構造を有する実施例
の場合と同様であり、容易に類推できると思われるので
、詳しい説明は省略する。

［発明の効果］ 以上詳しく説明したように、本発明によれば、長大な可
変長データをデータベースに格納する場合に、データフ
ァイルにはこの可変長データの一部と、短くて済むあふ
れファイル内レコードのレコードポインタまたはあふれ
ファイル内レコードチエインの先頭レコードポインタを
格納し、あふれファイルには、データファイル中に格納
しきれなかった残りのデータを格納するようにしたので
、極めて長大なデータであっても、ブロック長を増大す
ることなく、この長大データの格納を実現することがで
きる。

また、データファイル内に格納しきれない長大なデータ
は稀にしか発生せず、通常の可変長データが短くてデー
タファイル内に格納しきれる場合には、あふれファイル
を使用しないので、あふれファイルに対するオープン／
クローズ及びＩｌｏが発生せず、上記第２従来技術の方
式に比べてオーバヘッドを少なくすることができる。こ
の場合、あふれファイルの使用を要するか否かの判断を
レコード単位で行い、レコード内のある項目が長大でも
レコード全体で所定長以内に収まれば、あふれファイル
は使用しないようにすることができる。

さらに、あふれファイルのデータ構造を、通常のデータ
ファイルのデータ構造と物理的に同一としであるので、
通常のデータファイルの各処理（既存のＤＢＭＳによる
処理）をあふれファイルの処理に流用することが可能と
なり、あふれファイル専用の処理を抑えることができ、
Ｉ’）ＥＭＳの規模を大幅に増加することなしに長大デ
ータの格納を実現することができる。

【図面の簡単な説明】

第１図は本発明の一実施例によるＤＢＭＳのシステム構
成の一例を示す図、第２図は本発明の一実施例による可
変長データのデータベースへの格納構造の一例を示す図
、第３図は従来のデータベースによる可変長データの格
納構造の一例を示す図、第４図は従来のＤＢＭＳのシス
テム構成の一例を示す図、第５図は本発明の一実施例に
よる定義部分の一部の処理で使用するデータ構造の一例
を示す図、第６図は本発明の一実施例による定義部分の
一部の処理を説明するためのフローチャート、第７図は
本発明の一実施例による項目値格納部の処理を示すフロ
ーチャート、第８図は本発明の−実施例による項目値検
索部の処理を示すフローチャート、第９図は本発明の他
の実施例による可変長データの格納構造の一例を示す図
である。 １０１・・・・・・あふれオプション設定部、１０２・
・・・・あふれ項目検索部、１０３・・・・・・あふれ
項目格納部、１０４・・・・・あふれ項目削除部、１０
５・・・・・・あふれファイル、２０１・・・・・・所
属ファイル名、２０２・・・・項目名、２０３・・・・
・データ型、２０４・・・・・・定義項目長、２０５・
・・・・・あふれオプション、２０６．２０７・・・・
・・レコード、２０８・・・・・・項目値格納領域、３
０１・・・・・レコード長、３０２・・・・・項目格納
領域、３０３・・・・・項目長、３０４・・・・・デー
タ格納領域、４０１・・・・・・ＤＢＭＳ、４０２・・
・・・・処理制御部、４０３・・・・・・定義処理部、
４０４・・・・・・データ処理部、４０５・・・・・・
定義制御部、４０６・・・・・・表生成部、４０７・・
・・・・データ処理制御部、４０８・・・・・・検索処
理部、４１０・・・・・格納処理部、４１２・・・・・
・変更処理部、４１３・・・・・・削除処理部、４１５
・・・・・・データベースＤＢ、４１６・・・・・・項
目定義情報ファイル、４１７・・・・・・データファイ
ルＡ。 第５図 項目定義情報配列５０／ −−ＪＬＪＩＪ 第７図 第８図

Claims (1)

1. 【特許請求の範囲】 １、データベースは可変長データの少なくとも一部をレ
   コード単位で格納するデータファイル及びあふれデータ
   をレコード単位で格納するあふれファイルを有し、デー
   タファイルのレコードは前記可変長データの少なくとも
   一部のほかに、あふれファイルの利用が予め設定された
   項目について、あふれデータの格納されるあふれファイ
   ルのレコードを指示するレコード指示情報を格納し、あ
   ふれファイルのレコードは、当該あふれファイルレコー
   ドで更にあふれたデータがあるとき、前記あふれデータ
   の一部のほかに、前記更にあふれたデータの格納される
   前記あふれファイル内の他のレコードを指示する他のレ
   コード指示情報を格納するように構成したことを特徴と
   する関係型データベースのデータ格納方式。 ２、前記あふれファイルの利用の設定は、ユーザ入力装
   置からの指示により行われるように構成したことを特徴
   とする請求項１記載の関係型データベースのデータ格納
   方式。 ３、前記あふれファイルの利用の設定は、１レコードに
   おける項目長の合計が最大レコード長を越えるデータフ
   ァイルに対し、データベース管理システムが持つ優先度
   によつて行われるように構成したことを特徴とする請求
   項１記載の関係型データベースのデータ格納方式。