[go: up one dir, main page]
More Web Proxy on the site http://driver.im/

JP3703874B2 - ファイル管理方法及びファイル管理装置 - Google Patents

ファイル管理方法及びファイル管理装置 Download PDF

Info

Publication number
JP3703874B2
JP3703874B2 JP05937895A JP5937895A JP3703874B2 JP 3703874 B2 JP3703874 B2 JP 3703874B2 JP 05937895 A JP05937895 A JP 05937895A JP 5937895 A JP5937895 A JP 5937895A JP 3703874 B2 JP3703874 B2 JP 3703874B2
Authority
JP
Japan
Prior art keywords
record
index
page
slice
long
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP05937895A
Other languages
English (en)
Other versions
JPH08255103A (ja
Inventor
志康 小林
康弘 鈴木
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Fujitsu Ltd
Original Assignee
Fujitsu Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Fujitsu Ltd filed Critical Fujitsu Ltd
Priority to JP05937895A priority Critical patent/JP3703874B2/ja
Publication of JPH08255103A publication Critical patent/JPH08255103A/ja
Application granted granted Critical
Publication of JP3703874B2 publication Critical patent/JP3703874B2/ja
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Images

Landscapes

  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Description

【0002】
【産業上の利用分野】
本発明は、データベースに登録されるファイルを管理するためのファイル管理方法及びファイル管理装置に関し、特に、データベースにおけるデータの入出力動作の単位としてのページ内に収まらないようなデータについてアクセスする際に用いて好適な、ファイル管理方法及びファイル管理装置に関する。
【0003】
【従来の技術】
従来より、例えば複数の端末とデータベース等により構成され、応用プログラム等が起動されるワークステーションにおいては、例えばDBMS(Database Management System)等のようなデータベースに登録されるファイルを管理するためのシステムが用いられている。
【0004】
即ち、このDBMSにおいては、データベースに対して、数値や文字列等のような基本的なデータ型(atomic data type)により構成されるファイルについての部分的な読み込み,更新,及びデータの挿入や削除に伴うサイズ変更等のアクセス処理が行なわれている。
また、上述のワークステーション等においては、文書、画像データ、CAD/CAEにおける可変長の座標配列等のマルチメディアデータについてもデータベース上に表現したいというニーズも高まっている。
【0005】
ここで、マルチメディアデータは、データサイズが可変であり、データに対する固定的な意味付け(大小比較等)は限定することができない。そこで、多くのRDBMS(リレーショナルDBMS)では、マルチメディアデータを、例えばレコード(タップル,行)単位に可変長のビット/バイト列を表すBLOB(binary large objects)というデータ型で表現することにより、上述の基本的なデータ型とは区別されている。
【0006】
ここで、レコードとは、データベース内のデータを応用プログラム間でやり取りする際のデータの単位をいう。
なお、マルチメディアデータを、レコードを構成するデータ項目(フィールド、カラム)単位に対応してBLOBとして扱う場合においては、そのBLOBレコードへのアドレス参照により実現できる。
【0007】
また、BLOBは、この他に「long item data」,「spatial data」,「bulk data 」のように英語表現される場合がある。
ところで、上述したように、マルチメディアデータをファイルとしてデータベースに登録するにあたっては、レコードのサイズが可変であり、複数の物理ページ間にまたがるような大きいサイズとなる場合があり、このような場合においては、マルチメディアデータを、基本的なデータと同様にはデータベース上に登録することができない。
【0008】
従って、マルチメディアデータにより構成されるレコードは、レコード全体のサイズが大きくなり、全てのデータ量を主記憶上に常駐させることができなくなり、ワークステーションの運用の際に、応用プログラムや問い合わせに対する要求として、データベースにおけるレコード全体に対する部分的なアクセスを行なえる必要が生じている。
【0009】
そこで、図37に示すように、ファイルを管理するファイル管理装置において、複数の物理ページ間にまたがる大きなサイズのレコード(BLOBデータ)101を、データベース上にページ単位に分割して格納するとともに、これらの分割して格納された破片101−1〜101−nをアドレスリンクすることが考えられる。
【0010】
これにより、図37に示すようにBLOBデータをデータベースに登録した場合は、ファイル管理装置では、レコード全体に対する部分的なアクセスを行なう際には、アドレスリンクに基づいて、先頭の破片から順次ナビゲートしていくようになっている。
しかしながら、近年のデータベースに格納すべきデータの量の増大に伴って、複数の物理ページに分割された破片数を多くすることになる。従って、データベースに対してのアクセス時間が増加し、例えば画像データの時間軸に対するスキップや、CAEの部分的な配列データへの瞬時なアクセスを実現することができないという課題がある。
【0011】
そこで、例えば図38に示すように、ファイル管理装置において、ページ単位に分割された破片(スライス)101−1〜101−nにより構成されるレコードに対して、各スライス101−1〜101−nについてのサイズとアドレスとからなる一覧情報(ディレクトリ情報)を格納するページ102を別個に登録しておくことにより、データベース上のBLOBデータに対する部分的アクセスの時間を少なくすることができる。
【0012】
即ち、スライス101−1〜101−nの格納されたページに部分的アクセスする場合においては、それぞれ、ディレクトリ情報が格納されたページ102における指針102−1〜102−nを参照することにより、部分的アクセスの時間を少なくしているのである。
【0013】
【発明が解決しようとする課題】
しかしながら、上述の図38に示すようなファイル管理装置によるデータベースのアクセス手法では、ページ102に格納されたディレクトリ情報自体は、一つの物理ページに収まらなければならず、結果としてBLOBのレコード全体に対する最大サイズが制約されるという課題がある。
【0014】
さらに、高々数ページにまたがるような小規模のBLOBデータに対しても、必ずディレクトリ情報のためのページが必要となる。即ち、単にページ内に収まらない小規模のBLOBデータについて、上述の図38に示すようなアクセス手法を用いると、ディレクトリ情報のための領域の設定とそのメンテナンスが、空間的、時間的なオーバーヘッドとなる課題もある。
【0015】
また、応用プログラム利用の際に、利用者の便宜を図るべく、応用プログラム側において、データベース側の環境を意識する必要がないインターフェイスを構築することも必要である。
本発明は、このような課題に鑑み創案されたもので、レコードサイズの制約がなく、且つ部分的なアクセスに対しても高速に行なうことができる、ファイル管理方法及びファイル管理装置を提供することを目的とする。
【0016】
【課題を解決するための手段】
図1は第1の発明の原理ブロック図であり、この図1において、1aはファイル管理装置であり、このファイル管理装置1aは、データベース6aに登録されるファイルを管理するものであり、レコード操作手段2a,長大レコード操作手段3a,通常レコード操作手段4a及びインデクス操作手段5aをそなえている。
【0017】
レコード操作手段1aは、レコードに対する各種要求を受け付けるものであり、ここでいうレコードとは、データベース6内のデータをレコード操作手段2側の要求元との間でやり取りする際のデータの単位をいう。
また、長大レコード操作手段3aは、1ページのサイズ内に収まらないサイズの長大レコードであって、ページ単位に分割された複数のスライスにより構成された長大レコードに関する要求をレコード操作手段2aから受けると、その長大レコードについて、スライス単位に分解するものである。
【0018】
さらに、通常レコード操作手段4aは、レコード操作手段1aからの1ページサイズ内のレコードに関する要求又は長大レコード操作手段3aからの長大レコードに関する要求を受け、1個のレコード内でのアクセス又はレコード内での部分的アクセスを、データベース6aとの間で行なうものである。
また、インデクス操作手段5aは、長大レコードのインデクスを生成又は更新し、長大レコードのアクセスをデータベースとの間で行なうものである。
さらに、通常レコード操作手段4bは、レコード操作手段2aから1ページサイズ内のレコードに関する要求を受けた場合は、1個のレコード内でデータベース6aに対してアクセスを行なうようになっている。
また、長大レコード操作手段3aは、レコード操作手段2aが1ページサイズ内に収まらないサイズを有する新規の長大レコードに関する登録要求を受けた場合はその新規の長大レコードについて1ページに相当するサイズを有するスライス単位に分解するとともに、通常レコード操作手段4aで、データベース6aに登録するようになっている。
さらに、長大レコード操作手段3aが、データベース6aに登録され1ページのサイズ内に収まらないサイズを有する長大レコードであって複数のスライスにより構成された長大レコードに関する要求を受けた場合は、該長大レコードについて、該スライス単位に分解された長大レコード内での部分的アクセスをデータベース6aとの間で行なうか、又は該長大レコードのインデクスを生成又は更新し、該長大レコードのアクセスを、該スライスを単位として、データベース6aとの間で行なうように構成されている。
【0019】
さらに、図2は第2の発明の原理ブロック図であり、この図2において、1bはファイル管理装置であり、このファイル管理装置1bは、データベース6bに登録されるファイルを管理するものであり、レコード操作手段2b,長大レコード操作手段3b,データページ操作手段4b及び木インデクス操作手段5bをそなえている。
【0020】
ここで、レコード操作手段2bは、レコード又はレコード内の部分的なデータに対して、レコードの新規作成、抹消、フェッチ、レコード内の部分的なデータに対する途中挿入、途中削除、更新又は読み込みのいずれかのレコード操作要求を受け付けるものであり、ここでいうレコードについても、データベース6b内のデータをレコード操作手段2側の要求元との間でやり取りする際のデータの単位をいう。
【0021】
また、データページ操作手段4bは、レコード操作手段2bにて受け付けた要求の対象となるデータが1ページ内に収まるサイズの通常レコードである場合において、該要求の対象としての新規レコード又はデータベース6b上で登録されたレコード識別子で示される既存レコードを1ページに収まる通常レコードとして割り当てて、各種レコード操作を行なうとともに、1個の通常レコード内における部分的アクセスを行なうものである。
【0022】
なお、ページとは、データベースにおけるデータに関しての物理的な入出力動作の最小単位である。
さらに、長大レコード操作手段3bは、レコード操作手段2bにて受け付けた要求の対象となるデータが、ページ内に収まらないサイズの長大レコードであって、ページ単位に分割された複数のスライスにより構成された長大レコードである場合は、新規レコード又はデータベース6b上で登録された長大レコードに対し、操作を受けるスライス単位に分解してから、データページ操作手段4bに対して各種レコード操作を該スライス単位に要求するものであり、後述するアクセス開始点決定制御部3b−1及びメンテナンス部3b−2をそなえている。
【0023】
木インデクス操作手段5bは、最下位リーフレベルのインデクスでは各スライスそのもののサイズとスライスへのレコード識別子を格納し、その上の階層のインデクスは下位のインデクスの表すサイズの総和を格納し、最上位のルートレベルのインデクスの表すサイズの総和は長大レコード全体のサイズに一致し、リーフレベルのインデクスの順番は、これらの対応する各スライスのオフセットの順番に一致するようにインデクスを構成するものである。
【0024】
また、長大レコード操作手段3bのアクセス開始点決定制御部3b−1は、既存の長大レコードに対する部分的なアクセスを行なう場合には、レコード全体に対するオフセットより操作対象となるスライスの開始点を、スライス間のアドレスリンクを順次ナビゲートする方法又は上記木インデクスより求める方法のいずれかにより決定するものである。
【0025】
さらに、メンテナンス部3b−2は、スライス単位の追加、削除に伴う上記木インデクスのメンテナンスを木インデクス操作手段5bに要求するものである
また、データページ操作手段4bが、ページ内の各レコードの、通常レコードと長大レコードとの区別を記録するレコード区別記録部をそなえるとともに、レコード操作手段2bが、データページ操作手段4bのレコード区別記録部からの、既存のレコードのレコード識別子に対応するレコードの区別に基づき、通常レコードの場合にはデータページ操作手段4bに、長大レコードの場合には長大レコード操作手段3bにそれぞれレコード操作を要求する操作要求部をそなえることもできる
【0026】
さらに、レコード操作手段2bが、既存の通常レコードに対し、操作に伴いレコード全体のサイズが1ページに収まらなくなる場合には、通常レコードを長大レコードとして登録し直してから長大レコード操作手段3bにレコード操作を要求する一方、既存の長大レコードに対し、操作を完了した後、長大レコード全体のサイズが1ページに収まる場合には、このレコード操作の完了した長大レコードを通常レコードとして登録し直す再登録操作部をそなえることもできる
【0027】
また、アクセス開始点決定制御部3b−1が、既存の長大レコードに対する部分的なアクセスを行なうスライスの開始点を決定する際に、木インデクスが構成されている場合は木インデクス操作手段5bにより、無ければスライス自体の持つアドレスリンクをナビゲートしてその開始点を決定することができる
【0028】
即ち、アクセス開始点決定制御部3b−1の制御に基づいて、該木インデクス操作手段5bによりアクセス開始点の決定する場合は、メンテナンス部3b−2を、長大レコード全体のサイズに対する予め決められたしきいサイズとの大小に基づいて、木インデクスの作成と削除とを決定するように構成することができるほか部分的なアクセスの要否により木インデクスの作成又は削除することを決定しさらに、部分的なアクセスが発生すると、木インデクスを作成するように構成することができる
【0029】
また、長大レコード操作手段3bのメンテナンス部3b−2を長大レコード全体のサイズに対する予め決められたしきいサイズとの大小関係、及び部分的なアクセスの要否により木インデクスの作成又は削除することを決定するように構成することができる
さらに、木インデクス操作手段5bが、長大レコード全体に対するオフセットからスライスを検索する際に、木インデクスの最上位のルートインデクスページから最下位のリーフインデクスページに至る各インデクスのサイズの積算が、所望のオフセットと一致又は直前となるインデクスを検索し、検索されたインデクスから逐次下位階層のインデクスページに移って検索を行なうことにより、リーフインデクスページ上のインデクスにおいて当該オフセットを含むスライスへのレコード識別子を取得するインデクスページ操作部をそなえることもできる
【0030】
また、長大レコード操作手段3bが、長大レコードに対する部分的な挿入を行なう際に、挿入操作後に新規生成されたスライスの格納ページに空き領域があれば、新規生成されたスライスと直後のスライス間で併合するインデクスページ間操作部をそなえることができるほか長大レコードに対する部分的な削除を行なう際に、削除操作の開始点を含むスライスと終了点をスライス間で併合するインデクスページ間操作部をそなえることもできる
【0031】
さらに、長大レコード操作手段3bが、長大レコードに対するサイズ変更操作が行なわれた後に、当該長大レコードを構成する全てのスライスについてのスライスサイズの総和を演算する総和演算部と、総和演算部において演算された総和に対する、スライスの個数と1ページサイズの積との比を演算する比演算部と、比演算部において演算された比と、予め設定された比率とを比較する比率比較部と、比率比較部における比率の比較の結果、比演算部において演算された比が予め設定された比率よりも小さい場合は、隣り合うスライス間において自スライスの空き領域が該自スライスに続くスライスのデータで埋まるように、全てのスライスについて順次マージしていくことにより、ガベージコレクションを行なうように制御するガベージコレクション制御部をそなえることができる
【0032】
また、長大レコード操作手段3bが、メンテナンス部3b−2において、インデクスに対する修正をした後に、修正されたリーフインデクスページ内における、スライスサイズの総和を演算する総和演算部と、総和演算部において演算された総和に対する、スライスの個数と1ページサイズの積との比率を演算する比演算部と、比演算部において演算された比と、予め設定された比率とを比較する比率比較部と、比率比較部における比率の比較の結果、比演算部において演算された比が予め設定された比率よりも小さい場合は、リーフインデクスページ内におけるインデクスに対応したスライスについて、隣り合うスライス間において自スライスの空き領域が該自スライスに続くスライスのデータで埋まるように順次マージしていくことにより、ガベージコレクションを行なうように制御するガベージコレクション制御部をそなえることもできる
【0033】
【作用】
上述の第1の発明では、図1に示すように、レコード操作手段2aにおいて、1ページサイズ内のレコードに関する要求を受けた場合は、通常レコード操作手段4aにより、1個のレコード内でデータベース6aに対してアクセスを行なう。
また、長大レコード操作手段3aで、1ページのサイズ内に収まらないサイズを有する新規の長大レコードに関する登録要求を受けた場合は、該新規の長大レコードについて、ページ単位に分割されたスライスに分解して、通常レコード操作手段4aで、データベース6aに登録する。
また、レコード操作手段2aにおいて、データベース6aに登録され1ページのサイズ内に収まらないサイズを有する長大レコードであって、複数のスライスにより構成された長大レコードに関する要求を受けた場合は、長大レコード操作手段3aにより、長大レコードについて、スライス単位に分解する。
【0034】
そして、通常レコード操作手段4aにより、スライス単位に分解された長大レコード内での部分的アクセスをデータベース6aとの間で行なうか、又はインデクス操作手段5aにより、長大レコードのインデクスを生成又は更新し、長大レコードのアクセスを、スライスを単位として、データベース6aとの間で行なう。
これにより、ファイル管理装置1aでは、データベース6aに格納されるファイルを管理することができる
【0035】
さらに、上述の第2の発明のファイル管理装置1bにおいては、レコード操作手段2bでは、レコード又はレコード内の部分的なデータに対して、レコードの新規作成、抹消、フェッチ、レコード内の部分的なデータに対する途中挿入、途中削除、更新又は読み込みのいずれかのレコード操作要求を受け付ける。
また、データページ操作手段4bでは、レコード操作手段2bにて受け付けた要求の対象となるデータが1ページ内に収まるサイズの通常レコードである場合は、該要求の対象としての新規レコード又はデータベース6b上で登録されたレコード識別子で示される既存レコードを1ページに収まる通常レコードとして割り当てて、各種レコード操作を行なうとともに、1個の通常レコード内における部分的アクセスを行なう。
【0036】
さらに、長大レコード操作手段3bでは、レコード操作手段2bにて受け付けた要求の対象となるデータが、ページ内に収まらないサイズの長大レコードであって、ページ単位に分割された複数のスライスにより構成された長大レコードである場合は、新規レコード又はデータベース6b上で登録された長大レコードに対し、操作を受けるスライス単位に分解してから、データページ操作手段4bに対して各種レコード操作をスライス単位に要求する。
【0037】
また、木インデクス操作手段5bでは、最下位リーフレベルのインデクスでは各スライスそのもののサイズとスライスへのレコード識別子を格納し、その上の階層のインデクスは下位のインデクスの表すサイズの総和を格納し、最上位のルートレベルのインデクスの表すサイズの総和は長大レコード全体のサイズに一致し、リーフレベルのインデクスの順番は、これらの対応する各スライスのオフセットの順番に一致するようにインデクスを構成する。
【0038】
また、長大レコード操作手段3bのアクセス開始点決定制御部3b−1では、既存の長大レコードに対する部分的なアクセスを行なう場合には、レコード全体に対するオフセットより操作対象となるスライスの開始点を、スライス間のアドレスリンクを順次ナビゲートする方法又は上記木インデクスより求める方法のいずれかにより決定し、メンテナンス部3b−2では、スライス単位の追加、削除に伴う上記木インデクスのメンテナンスを木インデクス操作手段5bに要求する。
【0039】
これにより、ファイル管理装置1bでは、操作要求の対象のレコードに基づいて、データベース6bに登録されるファイルを管理することができる
また、データページ操作手段4bでは、レコード区別記録部により、ページ内の各レコードの通常レコードと長大レコードとの区別を記録しておき、レコード操作手段2bの操作要求部により、データページ操作手段4bのレコード区別記録部からの既存のレコードのレコード識別子に対応するレコードの区別に基づき、通常レコードの場合にはデータページ操作手段4bに、長大レコードの場合には長大レコード操作手段3bにそれぞれレコード操作を要求するこれにより、レコード操作手段2bでは、既存のレコードのレコード識別子に対応するレコードの区別に応じてレコード操作を要求することができる。
【0040】
さらに、レコード操作手段2bの再登録操作部により、既存の通常レコードに対し、操作に伴いレコード全体のサイズが1ページに収まらなくなる場合には、通常レコードを長大レコードとして登録し直してから長大レコード操作手段3bにレコード操作を要求する一方、既存の長大レコードに対し、操作を完了した後、長大レコード全体のサイズが1ページに収まる場合には、このレコード操作の完了した長大レコードを通常レコードとして登録し直すこともできる
【0041】
また、長大レコード操作手段3bのアクセス開始点決定制御部3b−1では、既存の長大レコードに対する部分的なアクセスを行なうスライスの開始点を決定する際に、木インデクスが構成されている場合は木インデクス操作手段5bにより、無ければスライス自体の持つアドレスリンクをナビゲートしてその開始点を決定するように制御することができる
【0042】
この場合においては、アクセス開始点決定制御部3b−1による制御に基づき、木エンデクス操作手段5bによりアクセス開始点を決定する場合は、メンテンナンス部3b−2では、長大レコード全体のサイズに対する予め決められたしきいサイズとの大小に基づいて、木インデクスの作成と削除とを決定することができるほか部分的なアクセスの要否により木インデクスの作成又は削除することを決定することができさらに、部分的なアクセスが発生すると、木インデクスを作成することもできる
【0043】
また、メンテナンス部3b−2では、長大レコード全体のサイズに対する予め決められたしきいサイズとの大小関係、及び部分的なアクセスの要否により木インデクスの作成又は削除することを決定することができる
さらに、木インデクス操作手段5bのインデクスページ操作部では、長大レコード全体に対するオフセットからスライスを検索する際に、木インデクスの最上位のルートインデクスページから最下位のリーフインデクスページに至る各インデクスのサイズの積算が、所望のオフセットと一致又は直前となるインデクスを検索し、検索されたインデクスから逐次下位階層のインデクスページに移って検索を行なうことにより、リーフインデクスページ上のインデクスにおいて当該オフセットを含むスライスへのレコード識別子を取得することもできる
【0044】
また、長大レコード操作手段3bのインデクスページ間操作部により、長大レコードに対する部分的な挿入を行なう際に、挿入操作後に新規生成されたスライスの格納ページに空き領域があれば、新規生成されたスライスと直後のスライス間で併合することができるほか長大レコードに対する部分的な削除を行なう際に、削除操作の開始点を含むスライスと終了点をスライス間で併合することもできる
【0045】
さらに、長大レコードに対するサイズ変更操作が行なわれた後に、総和演算部では、当該長大レコードを構成する全てのスライスについてのスライスサイズの総和を演算し、比演算部では、総和演算部において演算された総和に対するスライスの個数と1ページサイズの積との比を演算し、比率比較部では、比演算部において演算された比と予め設定された比率とを比較し、ガベージコレクション制御部では、比率比較部における比率の比較の結果、比演算部において演算された比が予め設定された比率よりも小さい場合は、隣り合うスライス間において自スライスの空き領域が該自スライスに続くスライスのデータで埋まるように、全てのスライスについて順次マージしていくことにより、ガベージコレクションを行なうように制御することができる
【0046】
また、メンテナンス部3b−2において、インデクスに対する修正をした後に、総和演算部では、修正されたリーフインデクスページ内における、スライスサイズの総和を演算し、比演算部では、総和演算部において演算された総和に対するスライスの個数と1ページサイズの積との比率を演算し、比率比較部では、比演算部において演算された比と予め設定された比率とを比較し、ガベージコレクション制御部では、比率比較部における比率の比較の結果、比演算部において演算された比が予め設定された比率よりも小さい場合は、リーフインデクスページ内におけるインデクスに対応したスライスについて、隣り合うスライス間において自スライスの空き領域が該自スライスに続くスライスのデータで埋まるように、順次マージしていくことにより、ガベージコレクションを行なうように制御することもできる
【0047】
【実施例】
以下、図面を参照することにより本発明の実施例について説明する。
(a)本発明の一実施例にかかるファイル管理装置の概要の説明
図3は本実施例にかかるファイル管理装置が適用されたシステムを示すブロック図であり、この図3に示すシステムは、複数の端末とデータベース等により構成され、例えば端末利用者による文書編集処理を行なうための応用プログラム等が起動されるワークステーションなどとして機能するものであり、ファイル管理装置は、データベースに登録されるファイルを管理するためのものである。
【0048】
ここで、この図3において、11は端末利用者による処理内容等を表示するディスプレイ装置であり、12は端末利用者からのデータやコマンド等を入力するためのキーボードである。
また、13はキーボード12からの入力やデータベース14に格納されているデータに基づいて、例えば文書編集処理等の応用プログラムを実行したり、プログラム実行の際に使用されるデータをデータベース14から読み込んで格納する中央処理装置/主記憶装置であり、この中央処理装置/主記憶装置13は、本実施例にかかるファイル管理装置としての機能を有している。
【0049】
また、データベース14は、中央処理装置/主記憶装置13において起動される応用プログラムのための各種データ等をファイル毎に格納しておくものであり、このデータベース14では、データに関しての物理的な入出力動作をページ単位に行なうようになっている。
ここで、CPU及び主記憶装置13は、応用処理部21,レコード操作部22,BLOBレコード操作部23,ツリーインデクス操作部24,データページ操作部25及びページバッファ26をそなえており、それぞれの機能はソフトウェアにより実現することができる。
【0050】
応用処理部21は、応用プログラム(アプリケーションプログラム)による処理を実行するものであり、本実施例においては、文書編集処理の応用プログラムを実行するものである。
レコード操作部(レコード操作手段)22は、データベース14内のデータを応用プログラム間でやり取りする際のデータの単位としてのレコード又はレコード内の部分的なデータに対する各種レコード操作要求を受け付けるものであり、操作要求部22a及び再登録操作部22bをそなえている。
【0051】
例えば、レコード操作部22は、レコード単位に対する操作要求として文書の新規作成(create),抹消(remove)又はフェッチ(fetch)を、レコード内の部分的なデータに対する操作要求として途中挿入(insert)、途中削除(cut)、更新(update),読み込み(read)を受け付けるようになっている。
【0052】
また、レコード操作部22の操作要求部22aは、データページ操作部25からのレコード識別子(Record IDentifier,RID)で示される、既存のレコードにおけるレコードの区別(割り当て)に基づき、通常レコードの場合にはデータページ操作部25に、BLOBレコード(長大レコード)の場合にはBLOBレコード操作部23にそれぞれレコード操作を要求するものである。
【0053】
さらに、再登録操作部22bは、既存の通常レコードに対し、操作に伴いレコード全体のサイズが1ページに収まらなくなる場合には、通常レコードを長大レコードとして登録し直してからBLOBレコード操作部23にレコード操作を要求する一方、既存の長大レコードに対し、操作を完了した後、長大レコード全体のサイズが1ページに収まる場合には、このレコード操作の完了した長大レコードを通常レコードとして登録し直すものである。
【0054】
また、データページ操作部(通常レコード操作手段,データページ操作手段)25は、データを格納するデータページを、ページ毎に操作するものである。具体的には、レコード操作部22にて受け付けた要求の対象となるデータが1ページ内に収まるサイズの通常レコードである場合に、新規レコード又はデータベース14上で登録されたレコード識別子で示される既存レコードが1ページに収まる通常レコードとしての各種レコード操作を行なうとともに、通常レコードにおける1ページ内に収まる部分的アクセスを行なうものである。
【0055】
さらに、データページ操作部25は、ページ内の各レコードの、通常レコードとBLOBレコードとの区別をRIDとして記録するレコード区別記録部25aをそなえている。
また、BLOBレコード操作部(長大レコード操作手段)23は、レコード操作部22にて受け付けた要求の対象となるデータが、1ページ内に収まらないサイズであって、複数のスライスにより構成された長大レコードとしてのBLOB(binary large objects)レコードである場合は、新規レコード又はデータベース14上で登録されたBLOBレコードに対し、操作を受けるスライス単位に分解してから、データページ操作部25に対して各種レコード操作を要求するものであり、アクセス開始点決定制御部23a及びメンテナンス部23bをそなえている。
【0056】
なお、BLOBレコード操作部23は、図17にて後述するように、総和演算部23c,比演算部23d,比率比較部23e及びガベージコレクション(Garbage Collection) 制御部23fをそなえ、データベース14におけるスライスの空の領域を整理することもできる。
ここで、アクセス開始点決定制御部23aは、既存のBLOBレコードに対する部分的なアクセスを行なう場合には、レコード全体に対するオフセットより操作対象となるスライスの開始点を、スライス間のアドレスリンクを順次ナビゲートする方法又は後述するツリーインデクス操作部24のツリーインデクス情報で求める方法のいずれかにより決定するものである。
【0057】
また、メンテナンス部23bは、スライス単位の追加、削除に伴うツリーインデクス情報のメンテナンスをTreeインデクス操作部24に要求するものである。
さらに、ツリーインデクス(Tree Index) 操作部24は、ツリーインデクスを構成して、データベース14におけるインデクスページに格納させるものであり、インデクスページ(Index Page)操作部24a及びインデクスページ間操作部24bをそなえている。
【0058】
また、既存のBLOBレコードに対する部分的なアクセスを行なう場合には、このツリーインデクス操作部24で構成されたツリーインデクス情報に基づいててアクセスを行なうことができるようになっている。
上述のツリーインデクスの構成としては、下位リーフレベル(Leaf Level)のインデクスでは各スライスそのもののサイズとスライスへのレコード識別子を格納し、その上の階層のインデクスは下位のインデクスの表すサイズの総和を格納し、最上位のルートレベル(Root Level)のインデクスの表すサイズの総和は該長大レコード全体のサイズに一致し、リーフレベルのインデクスの順番は、これらの対応する各スライスのオフセットの順番に一致するように構成することができる。
【0059】
上述の構成により、本発明の一実施例にかかるファイル管理装置では、以下に示すような処理が行なわれる。
即ち、レコード操作部22では、応用処理部21の応用プログラムからのレコードに対するアクセス要求を受け付ける。例えば、レコード単位のアクセス要求として、新規作成(create),抹消(remove)又はフェッチ(fetch)を受け付け、また、部分的なアクセスとして、途中挿入(insert),途中削除(cut),更新(update)又は読み込み(read)を受け付ける。
【0060】
さらに、レコード操作部22では、レコードの新規作成時は、そのレコードに対する要求サイズにより、通常レコードか又はBLOBレコードの区別を設定する。
また、レコード操作部22において受け付けたアクセス要求が、既存のレコードに対するものならば、データページ操作部25からのRIDに基づいて、そのレコードが通常レコードであるかBLOBレコードであるかを区別する。
【0061】
ここで、レコード操作部22の操作要求部22aでは、受け付けたアクセスに対応するレコードが、通常レコードである場合は、直接データページ操作部25に実際のレコード操作を要求する一方、BLOBレコードである場合は、BLOBレコード操作部23に実際のレコード操作を要求する。
また、既存のレコードが通常のレコードの場合でも、要求されたレコード操作に伴ってレコード全体サイズが1サイズに収まらなくなる場合には、再登録操作部22bにより既存の通常レコードをBLOBレコードとして登録し直し、その後、操作要求部22aによりBLOBレコード操作部23に実際のレコード操作を要求する。
【0062】
また、既存のBLOBレコードに対する操作を完了した後、BLOBレコード全体が1ページに収まるようになった場合には、再登録操作部22bにより、そのレコード操作完了後のBLOBレコードを通常レコードとして登録し直す。
なお、レコード操作部22において受けたアクセス要求が既存の通常レコードに対するものである場合は、RIDは、それ自体1個のレコードのデータベース14における所在を示している。
【0063】
これに対し、レコード操作部22において受けたアクセス要求がBLOBレコードの場合には、RIDは、BLOBレコードに対する管理情報のデータベース14における所在を示している。また、データベース14に所在する管理情報としては、複数のスライスをナビゲートする情報,ツリーインデクスに関する情報から構成される。
【0064】
データページ操作部25では、レコード操作部22からの要求に基づいて、新規レコード又はRIDで示される既存レコードが1ページに収まる通常レコードとしての割り当て、削除、更新等のレコード操作を行なうほか、1個の通常レコード内における途中削除,部分的な読み出し、及び1ページ内に収まる範囲の途中挿入といったレコード内(スライス内)での部分的アクセスを行なう。
【0065】
BLOBレコード操作部23では、レコード操作部22において受けたアクセス要求が、新規レコードのBLOBレコードか又はRIDで示される既存レコードが複数ページに点在したスライスにまたがって格納されるBLOBレコードに対するものである場合は、そのBLOBレコードについて、操作を受けるスライス単位に分解することにより、見かけ上個別の通常レコードに対するアクセスを行なうことができる。
【0066】
即ち、BLOBレコード操作部23のアクセス開始点決定制御部23aでは、レコード全体に対するオフセットより操作対象となるスライスの開始点を、スライス間のアドレスリンクを順次ナビゲートする方法又はツリーインデクス操作部24により生成されたツリーインデクス情報により求める方法のいずれかにより決定する。
【0067】
具体的には、アクセス開始点決定制御部23aでは、ツリーインデクス操作部24においてツリーインデクスが作成されている場合は、ツリーインデクス操作部24により部分的なアクセス対象となるスライスの開始点を決定するが、作成されていない場合は、スライス自体が有するアドレスリンクをナビゲートしてその開始点を決定するのである。
【0068】
スライスの開始点を上述のいずれかの方法で決定すると、BLOBレコード操作部23では、開始点以降のスライス単位のレコード操作については、アドレスリンクをナビゲートして、スライス単位にデータページ操作部25によるアクセス処理を繰り返し実行させるとともに、スライス単位のデータの追加、削除に伴って、アドレスリンクのメンテナンスを行なう。
【0069】
さらに、ツリーインデクス操作部24においてツリーインデクスが作成されている場合においては、メンテナンス部23bでは、各スライス単位の追加、削除、サイズ変更に関わる操作に伴い、ツリーインデクスをメンテナンスする。
なお、メンテナンス部23bでは、部分的なアクセスの要否や、BLOBレコード全体のサイズに応じて、ツリーインデクスを新規に一括生成したり、すでにあるツリーインデクスを消滅させる。
【0070】
ここで、部分的なアクセスの要否は、このBLOBレコードとして格納管理されるデータの種類毎に事前に定義された辞書を参照したり、応用プログラムから部分的なアクセス要求を受け付けることにより判断し、BLOBレコード全体のサイズは、レコード操作後にサイズが縮小した結果、通常レコードに変換される可能性があるので、レコード操作後のサイズに基づいて判断されている。
【0071】
ところで、ツリーインデクス操作部24では、データベース14上のインデクスページにおける、各スライスに対応したインデクスを操作する。このインデクスは、ページ当たりのインデクスの格納数をX,平均格納率をγ(0.5≦γ≦1.0)とすれば、インデクスの階層の高さHはlogγX(n)となり、スライス数の増加に対して動的にインデクスを増加させるとともに、アクセス性能の劣化を緩和することができる。
【0072】
また、ツリーインデクス操作部24により生成されるインデクスでは、各インデクスには対応するスライスのサイズを格納し、最下位のリーフレベルのインデクスは、各スライスそのもののサイズを格納し、結果として最上位のインデクスの表すサイズの総和が、BLOBレコード全体のサイズに一致する。
さらに、リーフレベルのインデクスの順番は、これらに対応する各スライスのオフセットの順番に一致しており、結果的に上位のインデクスにより、下位のインデクスページをナビゲートすることなく、少ないページアクセスで効率的にBLOB全体に対するオフセットに対応したリーフレベルのインデクスに行き着くことができる。
【0073】
また、最上位階層(ルート)から最下位(リーフ)に至るインデクスページ上の各インデクスのサイズの積算が、所望のオフセットと一致又は直前となるインデクスを見つけ、そのインデクスから逐次下位階層のインデクスページに移って検索することにより、リーフインデクスページ(Leaf Index Page) 上のインデクスに当該オフセットを含むスライスのRIDを取得する。これにより、BLOBレコード全体からのオフセットからスライスを特定することができる。
【0074】
インデクスページ操作部24aでは、インデクスページ単位の操作を行なう。即ち、インデクスを検索する際は、ルートインデクスページ(Root Index Page) から下位のインデクスページに向かって逐次検索されるが、インデクスをメンテナンスする際は、インデクスページ間操作部24bを介して、リーフインデクスページから上位のインデクスページに対して順次変更が反映される。
【0075】
また、インデクスページ間操作部24bでは、同一階層での前後のインデクスページ間のリンクや、上位/下位インデクスページ間のリンクのメンテナンスを行なう。
ところで、ツリーインデクス操作部24において、データページにおけるスライスの増減に伴った、インデクスページにおけるインデクスの増減操作を行なう際においては、同一階層内での前後のインデクスページ間でのインデクスの移動が伴うオーバーフローやアンダーフロー、さらに前後のインデクスページ間であふれたインデクスを収容できない場合のスプリットや、極端に過疎になったインデクスページのマージを行なう。
【0076】
これにより、最初にインデクスページ操作部24aがリーフレベルのインデクスに対するメンテナンス要求を受け付けると、インデクスページ操作部24aからインデクスページ間操作部24bに実際のインデクスに対するメンテナンス要求を行なう。
メンテナンス要求を受けたインデクスページ間操作部24bでは、前記のインデクスページ間にまたがるメンテナンス(オーバフロー,アンダーフロー,スプリット又はマージ)を行ない、インデクスページ単位のインデクスの挿入,削除はインデクスページ操作部24aに要求する。
【0077】
さらに、インデクスページ間操作部24bでは、一つの階層に対するインデクスのメンテナンスが完了すると、その変更内容を上位階層のインデクスページに反映する。例えば、下位階層のインデクスページの総サイズが変更された場合には、その下位階層のインデクスページを代表する上位階層のインデクスのサイズ及び当該上位階層のインデクスページの総サイズを更新する。
【0078】
ところで、ページバッファ26では、データベース14におけるファイル上のページアドレスに従って、物理ページ単位の入出力,主記憶装置に読み込まれたページのバッファリング,新規ページのデータベース14上への割り当て,データレコードやインデクスが空になって不要になったページの、データベース14からの開放等を行なう。
【0079】
このように、ツリーインデクス操作部24により、BLOBレコードのインデクスを生成し、BLOBレコードのアクセスをデータベース14との間で行なうことができるので、管理すべきBLOBレコードの最大レコードサイズの制約を無くすとともに、高速に部分的アクセスを行なえる利点もある。
また、再登録操作部22aにより、操作に伴ってレコード全体のサイズが変わっても、そのレコード全体のサイズに応じて、通常レコード又はBLOBレコードとして登録することができるほか、レコード区別記録部25aにより、ページ内の各レコードの、BLOBレコードと通常レコードとの区別を記録しておき、この区別に基づき、通常レコードとBLOBレコードの操作との分岐制御を行なうことができるので、応用処理部21側において、通常レコードとBLOBレコードの区別を意識する必要がなく、ファイル管理装置を、データ長を区別しない一貫性のあるインターフェイスとして機能させることができる利点がある。
【0080】
さらに、BLOBレコード操作部23のアクセス開始点決定制御部23aにより、レコード全体に対するオフセットから操作対象となるスライスの開始点を、スライス間のアドレスリンクを順次ナビゲートする方法又はツリーインデクスから求める方法のいずれかにより決定することができるので、レコードの規模とアクセス形態に応じた最適なアクセス手段を選択することができる利点があるほか、ファイル管理装置を、応用処理部21側においてデータベース側の環境を意識する必要のない独立性のあるインターフェイスとして機能することができる利点もある。
【0081】
また、ツリーインデクス操作部24では、BLOBレコード全体のサイズの対する予め決められたしきいサイズとの大小関係又は部分的なアクセスの要否によりツリーインデクスを動的に増減して更新,作成又は削除を行なうことができるので、データベースの領域を有効に活用しながら、管理すべき長大レコードの最大レコードサイズの制約を無くすとともに、高速に部分的アクセスを行なえる利点もある。
【0082】
(b)本実施例にかかるファイル管理装置を実現するためのヘッダファイルのプログラミング例の説明
上述のファイル管理装置としての機能をソフトウェアにより構成する場合は、例えば、以下に示す図24〜図36に示すような、C言語のプログラムにより実現することができる。
【0083】
即ち、これらの図24〜図36は、本実施例にかかるファイル管理装置を実現するためのヘッダファイルのプログラミング例を示す図であり、図24は初期の設定を行なうためのもので、図25はレコード操作部22を実現するためのもので、図26はページバッファ26を実現するためのものである。
また、図27はデータベース14におけるデータページ内のヘッダ部分の構造を設定するためのもので、図28はデータページ操作部25を実現するためのもので、図29はデータページ内のレコードエントリ部分の構造を設定するためのものである。
【0084】
さらに、図30はBLOB管理情報を設定するためのもので、図31はBLOBレコード操作部23を実現するためのもので、図32はツリーインデクス操作部24を実現するためのもので、図33はインデクスページ内のスライス毎のインデクスの構造を設定するためのもので、図34はインデクスページ内のヘッダ部の構造を設定するためのもので、図35はインデクスページ操作部24aを実現するためのもので、図36はインデクスページ間操作部24bを実現するためのものである。
【0085】
上述の図24〜図35に示すように、ファイル管理装置を実現するためのヘッダファイルが構成されている場合においては、データベース14におけるデータページ内においては、先頭に、図27のプログラムにより設定されたヘッダ部(DataHead)が格納され、その直後にレコードエントリが可変数の配列として格納される。なお、このレコードエントリの配列数としては、図27のプログラムにおける変数entryMaxが相当する。また、可変長となるレコードはデータページの最後尾から格納され、レコードエントリとレコード領域が衝突しない範囲で格納されるようになっている。
【0086】
さらに、データベース14におけるインデクスページ内においては、先頭に、図34のプログラムにより設定されたヘッダ部(IndexHead)が格納され、その直後に、図33のプログラムにより設定された個々のスライス毎のインデクス(IndexTuple)が固定数の配列として格納される。なお、インデクスが固定数の配列として格納されているので、インデクスのページサイズも固定である。
【0087】
また、図35のプログラムにより実現されたインデクスページ操作部24a及び図36のプログラムにより実現されたインデクスページ間操作部24bは、図32のプログラムにより実現されたツリーインデクス操作部24から利用されるようになっている。
(c)本実施例にかかるファイル管理装置を文書編集システムに適用した場合の動作の概略の説明
次に、図3に示したファイル管理装置を文書編集システムを起動する応用プログラムに適用した場合の動作について、図4に示すフローチャートを用いて以下に説明する。
【0088】
即ち、この図4に示すように、利用者はキーボード12からの入力指示とディスプレイ装置11への表示により文書編集作業を進め、文書情報をデータベース14から入出力する。
まず、利用者は最初にキーボードより新規/既存の文書指定を行ない(ステップA1,ステップA2)、指定された文書が新規文書である場合は、文書ヘッダ情報をcreate操作により新規レコードとしてデータベース14に書き込む(ステップA3)。
【0089】
また、指定された文書が既存文書である場合は、その文書をデータベース14から取り出すためにfetch操作を行なう(ステップA4)。
さらに、ページ単位の文書編集を行なう場合については(ステップA5)、キーボード12により編集すべき文書ページを指示する(ステップA6)。これにより、データベース14上において、BLOBレコード又は通常レコードで構成された文書の当該文書ページに対応するオフセットをlocate操作により位置付ける(ステップA7)。
【0090】
なお、この場合においては、単位文書ページ当たりの総バイト数を固定にすることにより、文書ページとオフセットとが一意に対応付けることができる。
また、locate操作により指示されたオフセットに対応するBLOBレコード又は通常レコード内の単位文書ページに対応する特定サイズ分だけをread操作によりデータベース14から読み込む(ステップA8)。
【0091】
さらに、read操作によりデータベース14から読み込まれた文書の内容をディスプレイ装置11に表示する(ステップA9)。以後、表示中の文書に対する部分文字列,行の単位での修正作業等をキーボード12で指示し(ステップA10)、これらに対応して、途中挿入insert(ステップA11),途中削除cut(ステップA12),部分変更update(ステップA13)といったデータベース14に対する操作が行なわれる。
【0092】
これにより、複数文書ページについて、上述したような編集作業を繰り返すことができる。
また、文書を削除する指示に対しては、キーボード12により不要文書を指定すると(ステップA14)、remove操作を行なうことにより、BLOBレコード又は通常レコード単位で削除する(ステップA15)。
【0093】
(d)本実施例にかかるファイル管理装置の適用されたデータベース14の詳細な説明
図5は本実施例にかかるファイル管理装置の適用されたデータベース14の詳細を示すブロック図であり、この図5に示すように、14aはレコードエントリー部であり、このレコードエントリ部14aは、ページバッファ26からのアクセス要求のあったレコードを特定するためのRIDを入力され、このRIDに対応するレコードの所在(例えばページ内の相対バイト位置等)と通常レコードとBLOBレコードとの区別を記録するものである。
【0094】
なお、このレコードエントリ部14aにて記録されたレコードの区別に基づき、ファイル管理装置側においては、前述のデータページ操作部25のレコード区別記録部25aにて記録されるようになっている。
なお、このRIDには、レコード毎に採番されたユニーク番号を用いたり、レコードアドレスを用いることができる。この場合ではレコードアドレスを用いてRIDを構成する。なお、RIDは、レコードを格納するページのアドレスとともに、そのページ内でのレコード追番とにより構成されている。
【0095】
ここで、データベース14においては、データページ操作部25の操作に基づいて通常レコード及びBLOBレコードを格納するデータページ14eと、ツリーインデクス操作部24の操作に基づきツリーインデクス情報を格納するインデクスページ14dをそなえている。
なお、いずれのページ14d,14eにおいても、データベース14のファイル上では、一つの物理ページであり、ページのファイルとの入出力やバッファリングはページバッファ操作部26で共通して行なわれるようになっている。

【0096】
また、インデクスページ14dに格納されたツリーインデクスとデータページ14eに格納されたBLOBレコードとしてのn個のスライス14−1〜14−nとは、図6に示すような関係を有している。
即ち、この図6に示すように、n個のスライス14−1〜14−nにより、応用処理部21から要求される1個のBLOBレコードを構成しており、それぞれのスライス14−1〜14−nは、各スライスに続くスライスのアドレス情報としてのnextアドレス等の制御情報をそなえ、これにより、例えば各スライス14−1〜14−nを順にnextアドレスに従ってアクセスすることにより、全体としてBLOBレコードにアクセスすることができるようになっている。
【0097】
従って、1個のBLOBレコードのサイズは、以下に示す式(1)に示すように、各スライス14−1〜14−n毎のサイズS1〜Snについての制御情報領域を除いた総和Sとなる。
Figure 0003703874
さらに、インデクスページ14dのツリーインデクスは、3段の階層構成を有するインデクス群14d−1〜14d−3により構成されており、各インデクス群14d−1〜14d−3には対応するスライスのサイズが格納されている。
【0098】
即ち、最下位のリーフレベルのインデクス群14d−3には、各スライスそのもののサイズを格納し、その上の階層のインデクス群14d−2には、下位のインデクスの表すサイズの総和を格納し、結果として最上位のルートレベルのインデクス群14d−1の表すサイズの総和が、BLOBレコード全体のサイズに一致する。
【0099】
さらに、リーフレベルのインデクス群14d−3の順番は、これらに対応する各スライスのオフセットの順番に一致しており、従って、上位のインデクス群14d−2,14d−1を参照することにより、下位のインデクス群14d−3をナビゲートすることなく、少ないページアクセスで効率的にBLOB全体に対するオフセットに対応したリーフレベルのインデクスを検索できるようになっている。
【0100】
ところで、それぞれのインデクス群14d−1〜14d−3は、複数のインデクスページにより構成することができる。さらに、各々のインデクス群14d−1〜14d−3を構成するインデクス1個は、例えば、スライスに対するRIDで8バイト、スライスのサイズで4バイト、更に上位から下位へのインデクスへのページアドレスとして4バイトの合計16バイトからなり、1ページのサイズを4KBとすると、約250個のインデクスを1インデクスページに収容することができる。
【0101】
このような構成により、レコードエントリ部14aにおいて記録された内容に基づき、アクセス要求のあったレコードが通常レコードである場合は、そのレコードは一つのページ上に存在し、且つそのレコードの所在位置がレコードエントリの記録から直接示される(図5における(a)参照)。
また、アクセス要求のあったレコードが、複数ページ上に分散されたスライス14−1〜14−nにより構成されるBLOBレコードである場合は、レコードエントリ部14aにおいて記録されている所在位置情報は、アクセス要求のあったBLOBレコードについてのBLOB管理情報14cを示している(図5における(b)参照)。
【0102】
また、このBLOB管理情報14cにより、複数ページ上に分散されたスライスの内の先頭のものへの位置が示されるとともに、このBLOBレコードに対応するツリーインデクスが生成されている場合は、このBLOBレコードを構成する分散されたスライスへのツリーインデクスへのトップ(ルート)が示されている。
【0103】
ここで、上述のBLOB管理情報14cに基づいて、データページ14e上のデータにアクセスする際においては、スライス間のアドレスリンクを順次ナビゲートする方法か又はインデクスページ14dに生成されたツリーインデクスによりアクセスする方法を採用する。
具体的には、BLOBレコードを構成するスライスの個数が少なかったり、部分的なアクセスを要しない場合にはスライス間のアドレスリンクを順次ナビゲートする方法を採用し、インデクスページ14dにツリーインデクスが生成されていたり、部分的なアクセスを要する場合は、ツリーインデクスによりアクセスする方法を採用する。
【0104】
ここで、上述のツリーインデクスを用いたデータアクセスを行なう方法を採用する場合においては、BLOB管理情報14cからのBLOBレコード全体からのオフセットに基づいて、最上位階層(ルート)から最下位(リーフ)に至るインデクスページ上の各インデクスのサイズの積算が所望のオフセットと一致又は直前となるインデクスを見つけ、そのインデクスから逐次下位階層のインデクスページに移っていくことにより、リーフインデクスページ上のインデクスに当該オフセットを含むスライスのRIDを取得することができ、これにより、BLOBレコード全体からのオフセットからスライスを特定することができる。
【0105】
例えば、i番目のスライス14−iに対する部分的なアクセスを必要とする場合、このi番目のスライスは、応用処理部21からのBLOBレコード全体におけるオフセットで特定される。
ここで、このオフセットに基づいてアクセスする際に、ツリーインデクスを利用した方法を用いた場合においては、上述したように、ルートレベルのインデクス群14d−1からオフセット1が求まり、インデクス群14d−2からオフセット2が求まり、リーフレベルのインデクス群14d−3からオフセット3が求まる。
【0106】
これにより、目標とするオフセットのデータの内容を含むスライス14−iを検索することができ、巨大なBLOBレコード全体の内の1部分に対するアクセスを高速に実現することができる。
なお、アクセス要求のあったBLOBデータについて、実際に存在するスライスが数ページ(例えば10ページ)の場合や、常に先頭から順次読み込むような目的の場合(例えばデータベース14が単なる大きなデータの格納庫であったり、膨大なメモリ空間に一括して読み込むか、読み込める範囲のサイズまでしかデータ量が増大しないものの場合)は、ツリーインデクスによらずにスライス間のアドレスリンクを順次ナビゲートしてアクセスを行なう。
【0107】
これにより、BLOBレコード全体に対するサイズや部分的なレコードのアクセスの要否によりアクセス方法を選択して、ツリーインデクスの生成/削除選択することができるので、インデクスページ14eを生成するのに必要なデータベース14上の記憶領域や、インデクスページ14eのためのメンテナンス時間の冗長性を抑止することができる。
【0108】
(e)データベース上のレコードのサイズ変更に伴った状態遷移の説明
また、データベース14上のレコードは、前述の(b)にて示したような文書ファイルについての修正等が行なわれると、データベース14上では、その修正等に応じて図7に示すように状態が遷移するようになっている。
即ち、文書ファイルにおけるレコードの新規作成(create,図7の状態B1参照)に対しては、初回のレコードサイズが1物理ページに収まれば通常レコードとして登録され(図7の状態B1から状態B2)、収まらなければBLOBレコードとして登録される(状態B1から状態B3)。
【0109】
また、通常レコードに対して、その後の途中挿入(insert)を行なった結果、レコードサイズが1物理ページに収まらなくなった場合は、BLOBレコードとして再登録され(状態B2から状態B3)、逆に、BLOBレコードに対し、途中削除(cut,図7の状態B4参照)を行なった結果、レコードサイズが1物理ページに収まれば通常レコードとして再登録される(状態B3からB2)。
【0110】
さらに、状態B3において登録されているBLOBレコードに対して、途中挿入(insert)により更にレコードサイズが増加するか、既に新規作成(create)段階で充分大きなレコードサイズになっている場合か、又は途中挿入(insert)、途中削除(cut)、途中更新(update)、途中読み込み(read)といった部分的なアクセスが必要である場合は、このBLOBレコードに対し、ツリーインデクス操作部24による操作に基づいて、前述の図6に示すようなツリーインデクスを生成する(状態B3から状態B5)。
【0111】
その後、逆にBLOBレコードに対し途中削除(cut)を行なった結果、レコードサイズが充分小さくなるので、ツリーインデクスはオーバーヘッドとなり、再びツリーインデクスは不要とみなされる。これにより、インデクスページ14eに生成されたツリーインデクスを削除される(状態B5から状態B3)。
上述のツリーインデクスの生成、削除を行なう際の判断は、レコード操作部22において、BLOBレコードのサイズの基準値に基づいて行なっているが、このサイズの基準値は、インデクスページ14eのサイズが、最小のインデクス構成で冗長にならないような全スライスのサイズの総和の閾値として設定されている。
【0112】
なお、最小のインデクス構成であるという条件は、例えばルートとリーフが一致するとともに1個のインデクスページから成り、且つ1ページ内の格納率が0.5とすることができる。
例えば、前述の図6におけるツリーインデクスの場合においては、1個のインデクスページでは250個のインデクスを格納できるので、その0.5の格納率の125個以上のインデクスを保つようなスライス数(=インデクス数)であり、その数分のスライスサイズの総和となる。
【0113】
即ち、ガベージコレクション制御によりスライスが密に詰められた状態で、125個分のインデクスに対応したページの総サイズを閾値としてのサイズとするので、以下に示す式(2)に基づき、500KBとすることができる。
4KB×125=500KB …(2)
なお、レコードの削除/抹消(remove)を行なう際は、最後のレコードサイズに依存して、BLOBレコードと通常レコードの両方の状態から遷移しうる。また、ツリーインデクスが生成されている状態であっても、レコード削除(remove)に伴い、スライスの削除が発生し、その結果の中間の状態遷移としてTreeインデクス無しのBLOBレコードへの状態遷移となる(図7における状態B5から状態B3)。
【0114】
従って、ページ内の各レコードの、BLOBレコードと通常レコードとの区別を記録しておき、この区別に基づき、通常レコードとBLOBレコードの操作との分岐制御を行なうことができるので、応用処理部21側において、通常レコードとBLOBレコードの区別を意識する必要がなく、ファイル管理装置を、データ長を区別しない一貫性のあるインターフェイスとして機能させることができる。
【0115】
(f)本実施例におけるファイル管理装置による、レコードの新規作成の際の動作の詳細な説明
図8はレコードの新規作成(create)を行なう際の動作を詳細に説明するためのフローチャートであり、この図8に示すように、まず新規作成に要求されるレコードサイズがページ内に収まるか否かのチェックを行ない(ステップC1)、このチェック結果に応じて、データベース14に格納される際のレコードの種類としての通常レコード又はBLOBレコードのいずれかが選択される(ステップC2)。
【0116】
ここで、レコードサイズが1物理ページに収まらず、BLOBレコードとして格納することが選択された場合は(ステップC2から“BLOBレコード”ルート)、BLOBレコード操作部23において、最初にBLOBレコードに関わる管理情報を作成するとともに、データページ操作部25の操作により、この管理情報をあたかも通常レコードの如く1物理ページ内に割り当てる(ステップC3)。
【0117】
その後、実際のデータを格納すべきレコードは、データページ操作部25の操作により、スライス形式で複数ページ間に分割して格納される。スライス単位の格納は、あたかも1個1個の通常レコードの如くデータページ操作で格納されるが、スライス毎には、制御情報として、スライス間のRIDによるリンク、そのスライスの持つデータのサイズが付加されている(ステップC4)。
【0118】
次に、BLOBレコード操作部23aにおいて、ツリーインデクス要のフラグが立っているか否かを判定する(ステップC6)。この段階において、BLOBレコード既に巨大化しており、BLOBレコード操作部23aにおいて、ツリーインデクス要のフラグが立っている場合は(ステップC6の“要”ルート)、ツリーインデクス操作部24の操作により、ツリーインデクスを一括作成する(ステップC7)。
【0119】
なお、部分的なアクセスの必要性がある場合においても、ツリーインデクスを作成することができるが、新規作成段階では、実際の部分的なアクセス発生をもってその必要性の判断を行なう場合はない。
このように作成された複数スライスの先頭のスライスへのRIDや、TreeンデクスのルートインデクスページへのページアドレスといったBLOBレコードに関わる情報を、前述のBLOB管理情報に返却記録する(ステップC8)。
【0120】
これにより、データベース14におけるページ内に割り当てられた各領域への所在を示すレコードエントリには、そのBLOBレコードの所在と共に、レコードの種類として、通常レコード、BLOB管理情報、スライスの区別が記録されている。
また、ステップC2において、レコードサイズが1物理ページに収まる通常レコードである場合は、単にデータページ操作部25により、1ページ内にレコードを格納し、RIDをデータベース14に返却する(ステップC9,ステップC10)。
【0121】
従って、新規作成されたレコードに対するRIDを返却した結果、通常レコードならばそのRIDはそのままその領域を示し、BLOBレコードならばそのRIDはBLOB管理情報を示すことになる。
従って、操作に伴ってレコード全体のサイズが変わっても、そのレコード全体のサイズに応じて、通常レコード又はBLOBレコードとして登録することができるので、応用処理部21側において、通常レコードとBLOBレコードの区別を意識する必要がなく、ファイル管理装置を、データ長を区別しない一貫性のあるインターフェイスとして機能させることができる。
【0122】
(g)本実施例におけるファイル管理装置による、レコードの途中挿入の際の動作の詳細な説明
図9〜図12はレコードの途中挿入(insert)を行なう際のレコードの操作の一例とともに、その後の隣接ページのマージの様子を示す図である。
例えば、図9に示すように、n個のスライス14−1〜14−nからなるBLOBレコードに対して、i番目のスライス14−iの途中となるオフセットXから、rバイトのデータ30の挿入を行なう場合においては、まず、目標オフセット位置への位置付け(locate)及び押し出されるデータの有無の判定を行なう。
【0123】
即ち、図10に示すように、挿入の開始点となるオフセットが、i番目のスライス14−iの途中に位置付けられると、このオフセット位置Xからrバイト分のデータ30が挿入されるが、もともとスライス14−iは空き領域がなかったため、挿入されるべき領域にあるrバイト分のデータは押し出される。
この場合のように、押し出されるデータがある場合は、新規スライス領域31を確保しておき、押し出されるデータをその新規スライス領域31に退避させてから、スライス14−iにおける空いた領域に、新データを挿入する。
【0124】
即ち、図11に示すように、オフセット位置Xからrバイト分のデータ30の挿入に伴い、i番目のスライス14−i内に存在するデータrバイト分のデータが、新規に設定されたページ上の新たなスライス領域31として押し出され、元のi番目のスライス14−iの直後のi+1番目だったスライス14−(i+1)のデータが、新規生成されたスライス領域の後ろにマージされる。
【0125】
ここで、図12に示すように、i+1番目だったスライス14−(i+1)内の全てのデータが、新規スライス上にマージできれば、i+1番目だったスライスは空となり削除することができ、新規スライスを新しいi+1番目のスライス14−(i+1)とすることができる。
従って、挿入操作の直後に隣接するページとのマージを行なうことにより、挿入操作によるスライスの増加を抑制することができ、アクセス性能の劣化を防止することができる。
【0126】
(h)本実施例におけるファイル管理装置による、レコードの途中削除の際の動作の詳細な説明
図13〜図16はレコードの途中削除(cut)を行なう際のレコードの操作の一例とともに、その後の隣接ページのマージの様子を示す図である。
即ち、図13に示すように、n個のスライス14−1〜14−nからなるBLOBレコードに対し、i番目のスライス14−iの途中となるオフセットXから、r(=k+m+n)バイトの途中削除を行なう場合においては、最初に削除の開始点となるオフセットへの位置付け(locate)を行なって、i番目のスライス14−iの途中に位置付ける。
【0127】
そして、図14に示すように、スライス14−i〜14−(i+2)内のデータ削除を行ない、目標全ての削除が終わるまで行なう。即ち、スライス14−iにおけるオフセットXから最終位置までのkバイト,スライス14−(i+1)における先頭位置から最終位置までのmバイト及びスライス14−(i+2)における先頭のnバイトを削除する。
【0128】
次に、図15に示すように、空スライス14−(i+1)を削除し、スライス14−iとスライス14−(i+2)との間のスライス間のリンクを結び直すとともに、スライス14−(i+2)内の使用部分(先頭からnバイトの位置から最終位置までの部分)を、当該スライス14−(i+2)の先頭部分に詰め直す。
【0129】
最後に、図16に示すように、元のi番目のスライス14−iの開いたスペース(オフセットXから最終位置までのkバイト)に、新たなi+1番目のスライス14−(i+1)(削除前にi+2番目のスライス14−(i+2)だったもの)のデータをマージし、残ったスライス14−(i+1)のデータについては、前述の図15におけるスライス14−(i+2)と同様に、先頭位置に詰め直す。
【0130】
これにより、削除した結果のページ内に過疎なスライスの増加を抑制することができ、アクセス性能の劣化を抑制することができる。
なお、新たなi+1番目のスライス14−(i+1)内でのデータの再度のマージの際に、新たなi+1番目スライス14−(i+1)のデータが全てi番目のスライス14−i内に収まれば、この新たなi+1番目のスライスも削除されることになる。
【0131】
(i)第1のガベージコレクションの態様の説明
ところで、本実施例にかかるファイル管理装置のBLOBレコード操作部23は、詳細には図17に示すように、総和演算部23c,比演算部23d,比率比較部23e及びガベージコレクション制御部23fをそなえており、ツリーインデクス操作部24においてツリーインデクスを生成していない場合において、データベース14におけるスライスの空の領域を整理するガベージコレクション制御を行なうことができるようになっており、このため、BLOBレコード操作部23は、詳細には図17に示すように、総和演算部23c,比演算部23d,比率比較部23e及びガベージコレクション制御部23fをそなえている。
【0132】
ここで、総和演算部23cは、BLOBレコードに対するサイズ変更操作が行なわれた後に、当該BLOBレコードを構成する全てのスライスについてのスライスサイズの総和を演算するものである。
また、比演算部23dは、総和演算部において演算された総和に対する、スライス14−1〜14−nの個数nとページ単位サイズPの積Dとの比S/Dを演算するものであり、比率比較部23eは、比演算部23dにおいて演算された比S/Dと、予め設定された比率αとを比較するものである。
【0133】
さらに、ガベージコレクション制御部23fは、比率比較部23eにおける比率の比較の結果、比演算部23dにおいて演算された比S/Dが予め設定された比率αよりも小さい場合は、データベース14における全てのスライス14−1〜14−nについてガベージコレクションを行なうように、データページ操作部25を介して制御するものである。
【0134】
このような構成により、本発明のファイル管理装置では、ツリーインデクス操作部24においてツリーインデクスを生成しておらず、nextリンクのみでBLOBデータが管理されている場合は、以下に示すようにガベージコレクションを行なっている。
ところで、個々のスライスが1ページ丸々のサイズ分のデータを持てば、BLOBレコード全体のサイズを満足すべき最小スライス数とすることができる。例えば図18に示すように、スライス14−1〜14−nにデータが格納されている場合においては、スライス14−1〜14−nの個数nとページ単位サイズPの積D(=n×P)が、管理することができるBLOBレコードの最大サイズである。
【0135】
ここで、スライス14−1〜14−nに格納されているデータの総和が所定の格納率αを下回った場合は、図18〜図20に示すように、BLOBレコードを構成する全てのスライスに対し、ガベージコレクション制御を行なうことができる。
即ち、図18に示すように、BLOBレコードに対するサイズ変更操作が行なわれた後に、総和演算部23cでは、当該BLOBレコードを構成する全てのスライス14−1〜14−nについてのスライスサイズの総和Sを、前述の式(1)に従って演算する。
【0136】
比演算部23dでは、総和演算部23cにおいて演算された総和Sに対するスライス14−1〜14−nの個数nとページ単位サイズPの積D(=n×P)との比S/Dを演算する。
そして、比率比較部23eでは、比演算部23dにおいて演算された比S/Dと予め設定された比率α(例えばα=0.5)と比較し、S/Dがαよりも小さい場合は、スライスに格納されるデータ量が、極度に過疎の状態にあると判定され、ガベージコレクション制御部23fにより、全てのスライス14−1〜14−nについてガベージコレクションを行なうように制御する。
【0137】
ここで、全てのスライス14−1〜14−nについてガベージコレクションを行なう際においては、例えば図19におけるスライス14−1〜14−3の間のように、隣り合うスライス間において、自スライスとnextアドレスで続くnextスライスとの間でマージすることが行なわれる。
即ち、例えばスライス14−1の空き領域にスライス14−2のデータS2 及びスライス14−3のデータの一部S3-1 がマージされ(図19の▲1▼参照)、スライス14−2のように、スライス14−2が空になると、スライス削除が発生する(図19の▲2▼参照)。
【0138】
なお、スライス14−3のように、スライス内のデータが空でないものについては、残ったデータS3-2 を当該スライス14−3における先頭部分に詰め直す(図19の▲3▼参照)。
以後、続くスライス14−4〜14−nについても、上述の▲1▼〜▲3▼における処理と同様のガベージコレクションを行なうことにより、図20に示すような総スライス数がm(<n)のスライスとすることができるが、この総スライス数の値mは、以下に示す式(3)により表すことができる。
【0139】
m=CEIL(S/P);CEILは小数点以下を切り上げる関数…(3)
従って、BLOBレコード操作部23により、操作に伴って長大レコード全体のサイズが変わった場合においては、データベース14におけるスライスの空の領域を整理して、スライス数を減少させることができるので、データベース14の領域を有効に活用することができる利点がある。
【0140】
(j)第2のガベージコレクションの態様の説明
上述の(i)で詳述した第1のガベージコレクションの態様においては、ツリーインデクス操作部24においてツリーインデクスを生成していない場合に行なわれるガベージコレクション制御について説明したが、第2のガベージコレクションの態様としては、ツリーインデクスが生成されている場合のガベージコレクション制御を行なうこともできる。
【0141】
また、この場合においても、上述の(i)における図17に示すように、BLOBレコード操作部23は、総和演算部23c,比演算部23d,比率比較部23e及びガベージコレクション制御部23fをそなえているが、それぞれの機能は上述の(i)におけるものと異なる。
即ち、総和演算部23cは、メンテナンス部23bにおいて、インデクスに対する修正をした後に、修正されたリーフインデクスページ内における、スライスサイズの総和を演算するものであり、比演算部23dは、総和演算部23cにおいて演算された総和に対する、スライスの個数とページ単位サイズの積との比率を演算するものである。
【0142】
また、比率比較部23eは、比率演算部23dにおいて演算された比と、予め設定された比率とを比較するものであり、ガベージコレクション制御部23fは、比率比較部23eにおける比率の比較の結果、比演算部23dにおいて演算された比が予め設定された比率よりも小さい場合は、リーフインデクスページ内におけるインデクスに対応したスライスについてガベージコレクションを行なうように制御するものである。
【0143】
このような構成により、本発明のファイル管理装置では、ツリーインデクス操作部24により、ツリーインデクスが構成されているBLOBレコードに対するガベージコレクションの動作について、図21〜図23を用いて以下に説明する。
即ち、スライス14−1〜14−Nに対する修正を行なうとともに、メンテナンス部23bにおいてインデクスに対する修正を行なうことにより、図21に示すようなインデクス15及びこのインデクス15に対応するスライス14−1〜14−Nとなった場合においては、以下に示すようにガベージコレクションを行なうか否かを判定する。
【0144】
即ち、総和演算部23cでは、修正されたリーフインデクスページ15内におけるスライスサイズの総和Sを演算し、比演算部23dでは、総和演算部23cにおいて演算された総和Sに対する、リーフインデクスページ15内におけるスライスの個数Nとスライスページ単位サイズPの積D(=N×P)との比S/Dを演算する。
【0145】
ここで、比率比較部23eでは、比演算部23dにおいて演算された比S/Dと予め設定された比率とを比較し、ガベージコレクション制御部23fでは、比率比較部における比率の比較の結果、比演算部23dにおいて演算された比が予め設定された比率α(例えばα=0.5)よりも小さい場合は、リーフインデクスページ15内におけるインデクスに対応したスライス14−1〜14−Nについてガベージコレクションを行なうように制御する。
【0146】
即ち、図22に示すように、リーフインデクスページ15内のスライス14−1〜14−Nについてガベージコレクションを行なう際においても、前述の図19におけるスライス14−1〜14−3の間のように、隣り合うスライス間において、自スライスとnextアドレスで続くnextスライスとの間でマージすることが行なわれる。
【0147】
ここで、メンテナンス部23bでは、上述の隣り合うスライス間のマージ処理を行なう毎にインデクスページのメンテナンスを行なっている。即ち、例えばスライス削除が生じた場合は、対応するインデクスも削除する。
具体的には、スライス14−1の空き領域にスライス14−2のデータS2 がマージされ(図22の▲1▼参照)、空になったスライス14−2が削除されると(図22の▲2▼参照)、対応するリーフインデクスページ15におけるインデクス15A(サイズS2 が格納されている領域)が削除され、インデクスの詰め直しが行なわれる(図22の▲3▼参照)。
【0148】
以後、続くスライス14−3〜14−Nについても、上述の図22における▲1▼〜▲3▼における処理と同様のガベージコレクションを行なうことにより、図23に示すような総スライス数がm(≦n)のスライスとすることができる。
これにより、ツリーインデクスを構成するリーフインデクスページ15内で、ガベージコレクションを行なう対象となるスライス群の範囲をスライス14−1〜14−Nに限定することができる。
【0149】
従って、BLOBレコード操作部23により、操作に伴って長大レコード全体のサイズが変わった場合においては、データベース14におけるスライスの空の領域を整理して、スライス数を減少させることができるので、データベース14の領域を有効に活用することができる利点がある。
また、ツリーインデクス操作部24によりツリーインデクスが生成される場合のように、詰めなおしの対象となるスライス数が多い場合において、ガベージコレクションを行なう対象となるスライス群の範囲を限定することにより、データの入出力負荷を抑制することもできる。
【0150】
また、各スライス14−1〜14−Nの合計サイズは、ガベージコレクションを行なった後も変わらないので、総管理サイズも変わらず、仮にツリーインデクスが複数段により構成されている場合においても、リーフインデクスページのメンテナンス時の、対応する上位インデクスページのメンテナンスを容易にすることができる。
【0151】
(j)その他
上述の(i),(j)では、スライスの理想サイズに対する格納率に基づいてガベージコレクションを行なうか否かを判定しているが、本発明によればこれに限定されず、理想スライス数に基づいて上述の判定を行なうことができ、このようにしても前述の(i),(j)と同様の作用効果を得ることができる。
【0152】
この場合においては、現在保有サイズ(BLOBレコード全体のサイズ)をSとし、スライスページ単位サイズをPとすると、理想のスライス数、即ち最小のスライス数Mを、以下に示す式(4)のように設定する。
M=CEIL(S/P);CEILは小数点以下を切り上げる関数…(4)
これにより、上述の式(4)にて得られた理想スライス数Mを用いて、実際のスライス数Nに対する理想スライス数Mとの比率N/Mと所定の閾値αとを比較し、この比較結果に基づいてガベージコレクションを行なうか否かを判定するのである。
【0153】
【発明の効果】
以上詳述したように本発明によれば、ツリーインデクス操作手段により、長大レコードのインデクスを生成し、長大レコードのアクセスをデータベースとの間で行なうことができるので、管理すべき長大レコードの最大レコードサイズの制約を無くすとともに、高速に部分的アクセスを行なえる利点もある。
【0154】
また本発明によれば、再登録操作部により、操作に伴ってレコード全体のサイズが変わっても、そのレコード全体のサイズに応じて、通常レコード又は長大レコードとして登録することができるので、応用プログラム側において、通常レコードとBLOBレコードの区別を意識する必要がなく、ファイル管理装置を、データ長を区別しない一貫性のあるインターフェイスとして機能させることができる利点もある。
【0155】
さらに本発明によれば、データページ操作手段のレコード区別記録部により、ページ内の各レコードの、長大レコードと通常レコードとの区別を記録しておき、この区別に基づき、通常レコードと長大レコードの操作との分岐制御を行なうことができるので、前述場合と同様の利点がある。
【0156】
また本発明によれば、長大レコード操作手段のアクセス開始点決定制御部により、レコード全体に対するオフセットより操作対象となるスライスの開始点を、スライス間のアドレスリンクを順次ナビゲートする方法又は上記木インデクスより求める方法のいずれかにより決定することができるので、レコードの規模とアクセス形態に応じた最適なアクセス手段を選択することができるほか、ファイル管理装置を、応用プログラム側においてデータベース側の環境を意識する必要のない独立性のあるインターフェイスとして機能することができる利点もある。
【0157】
さらに本発明によれば、ツリーインデクス操作手段では、長大レコード全体のサイズの対する予め決められたしきいサイズとの大小関係又は部分的なアクセスの要否によりツリーインデクスを動的に増減して更新,作成又は削除を行なうことができるので、データベースの領域を有効に活用しながら、管理すべき長大レコードの最大レコードサイズの制約を無くすとともに、高速に部分的アクセスを行なえる利点もある。
【0158】
また本発明によれば、長大レコード操作手段により、操作に伴って長大レコード全体のサイズが変わった場合においては、データベースにおけるスライスの空の領域を整理して、スライス数を減少させることができるので、前述の場合と同様に、データベースの領域を有効に活用することができる利点がある。
【0159】
さらに本発明によれば、長大レコード操作手段により、ガベージコレクションを行なう際に、詰めなおしの対象となるスライス数が多い場合において、ガベージコレクションを行なう対象となるスライス群の範囲を限定することにより、入出力負荷を抑制することができる利点もある。
【図面の簡単な説明】
【図1】第1の発明の原理ブロック図である。
【図2】第2の発明の原理ブロック図である。
【図3】本実施例にかかるファイル管理装置が適用されたシステムを示すブロック図である。
【図4】本実施例にかかるファイル管理装置を文書編集システムを起動する応用プログラムに適用した場合の動作を説明するためのフローチャートである。
【図5】本実施例にかかるファイル管理装置の適用されたデータベースの詳細を示すブロック図である。
【図6】本実施例にかかるデータベースにおけるスライスとインデクスの関係を示す図である。
【図7】本実施例にかかるデータベースの状態遷移を説明するための図である。
【図8】本実施例にかかるデータベースにおけるレコードの新規作成を行なう際の動作を詳細に説明するためのフローチャートである。
【図9】本実施例にかかるデータベースにおけるレコードの途中挿入を行なう際のレコードの操作の一例とともに、その後の隣接ページのマージの様子を示す図である。
【図10】本実施例にかかるデータベースにおけるレコードの途中挿入を行なう際のレコードの操作の一例とともに、その後の隣接ページのマージの様子を示す図である。
【図11】本実施例にかかるデータベースにおけるレコードの途中挿入を行なう際のレコードの操作の一例とともに、その後の隣接ページのマージの様子を示す図である。
【図12】本実施例にかかるデータベースにおけるレコードの途中挿入を行なう際のレコードの操作の一例とともに、その後の隣接ページのマージの様子を示す図である。
【図13】本実施例にかかるデータベースにおけるレコードの途中削除を行なう際のレコードの操作の一例とともに、その後の隣接ページのマージの様子を示す図である。
【図14】本実施例にかかるデータベースにおけるレコードの途中削除を行なう際のレコードの操作の一例とともに、その後の隣接ページのマージの様子を示す図である。
【図15】本実施例にかかるデータベースにおけるレコードの途中削除を行なう際のレコードの操作の一例とともに、その後の隣接ページのマージの様子を示す図である。
【図16】本実施例にかかるデータベースにおけるレコードの途中削除を行なう際のレコードの操作の一例とともに、その後の隣接ページのマージの様子を示す図である。
【図17】本実施例にかかるファイル管理装置のBLOBレコード操作部を詳細に示すブロック図である。
【図18】本実施例にかかるファイル管理装置における、ツリーインデクスを生成していない場合におけるガベージコレクション制御を説明する図である。
【図19】本実施例にかかるファイル管理装置における、ツリーインデクスを生成していない場合におけるガベージコレクション制御を説明する図である。
【図20】本実施例にかかるファイル管理装置における、ツリーインデクスを生成していない場合におけるガベージコレクション制御を説明する図である。
【図21】ツリーインデクスが構成されている場合におけるBLOBレコードに対するガベージコレクション制御を説明する図である。
【図22】ツリーインデクスが構成されている場合におけるBLOBレコードに対するガベージコレクション制御を説明する図である。
【図23】ツリーインデクスが構成されている場合におけるBLOBレコードに対するガベージコレクション制御を説明する図である。
【図24】本実施例にかかるファイル管理装置を実現するためのヘッダファイルのプログラミング例を示す図である。
【図25】本実施例にかかるファイル管理装置を実現するためのヘッダファイルのプログラミング例を示す図である。
【図26】本実施例にかかるファイル管理装置を実現するためのヘッダファイルのプログラミング例を示す図である。
【図27】本実施例にかかるファイル管理装置を実現するためのヘッダファイルのプログラミング例を示す図である。
【図28】本実施例にかかるファイル管理装置を実現するためのヘッダファイルのプログラミング例を示す図である。
【図29】本実施例にかかるファイル管理装置を実現するためのヘッダファイルのプログラミング例を示す図である。
【図30】本実施例にかかるファイル管理装置を実現するためのヘッダファイルのプログラミング例を示す図である。
【図31】本実施例にかかるファイル管理装置を実現するためのヘッダファイルのプログラミング例を示す図である。
【図32】本実施例にかかるファイル管理装置を実現するためのヘッダファイルのプログラミング例を示す図である。
【図33】本実施例にかかるファイル管理装置を実現するためのヘッダファイルのプログラミング例を示す図である。
【図34】本実施例にかかるファイル管理装置を実現するためのヘッダファイルのプログラミング例を示す図である。
【図35】本実施例にかかるファイル管理装置を実現するためのヘッダファイルのプログラミング例を示す図である。
【図36】本実施例にかかるファイル管理装置を実現するためのヘッダファイルのプログラミング例を示す図である。
【図37】一般的なファイル管理装置によるBLOBレコードのアクセス手法を示す図である。
【図38】一般的なファイル管理装置によるBLOBレコードのアクセス手法を示す図である。
【符号の説明】
1a,1b ファイル管理装置
2a,2b レコード操作手段
3a,3b 長大レコード操作手段
3b−1 アクセス開始点決定制御部
3b−2 メンテナンス部
4a 通常レコード操作手段
4b データページ操作手段
5a インデクス操作手段
5b 木インデクス操作手段
6a,6b データベース
11 ディスプレイ装置
12 キーボード
13 中央処理装置/主記憶装置
14 データベース
14−1〜14−n,14−N スライス
14a レコードエントリ
14b 通常レコード
14c BLOB管理情報
14d インデクスページ
14d−1〜14d−3 インデクス群
14e データページ
15,15A インデクス
21 応用処理部
22 レコード操作部(レコード操作手段)
22a 操作要求部
22b 再登録操作部
23 BLOBレコード操作部(長大レコード操作手段)
23a アクセス開始点決定制御部
23b メンテナンス部
23c 総和演算部
23d 比演算部
23e 比率比較部
23f ガベージコレクション制御部
24 ツリーインデクス操作部
24a インデクスページ操作部
24b インデクスページ間操作部
25 データページ操作部(データページ操作手段)
25a レコード区別記録部
26 ページバッファ
30 挿入データ
31 新規スライス領域
101 レコード
101−1〜101−n スライス
102 ページ

Claims (16)

  1. データベースに登録されるファイルを管理するファイル管理方法において、
    1ページサイズ内のレコードに関する要求を受けた場合は、1個のレコード内で該データベースに対してアクセスを行なう一方、
    1ページのサイズ内に収まらないサイズを有する新規の長大レコードに関する登録要求を受けた場合は、該新規の長大レコードについて、ページ単位に分割されたスライスに分解して、該データベースに登録するとともに、
    該データベースに登録され、1ページのサイズ内に収まらないサイズを有する長大レコードであって、複数のスライスにより構成された長大レコードに関する要求を受けた場合は、該長大レコードについて、該スライス単位に分解された長大レコード内での部分的アクセスを該データベースとの間で行なうか、又は該長大レコードのインデクスを生成又は更新し、該長大レコードのアクセスを、該スライスを単位として、該データベースとの間で行なうことを特徴とする、ファイル管理方法。
  2. データベースに登録されるファイルを管理するファイル管理装置において、
    レコードに対する各種要求を受け付けるレコード操作手段と、
    1ページのサイズ内に収まらないサイズの長大レコードであって、ページ単位に分割された複数のスライスにより構成された長大レコードに関する要求を該レコード操作手段から受けると、該長大レコードについて、該スライス単位に分解する長大レコード操作手段と、
    該レコード操作手段からの1ページサイズ内のレコードに関する要求又は該長大レコード操作手段からの長大レコードに関する要求を受け、1個のレコード内でのアクセス又はレコード内での部分的アクセスを、該データベースとの間で行なう通常レコード操作手段と、
    該長大レコードのインデクスを生成又は更新し、長大レコードのアクセスを該データベースとの間で行なうインデクス操作手段とをそなえ
    該通常レコード操作手段が、該レコード操作手段から1ページサイズ内のレコードに関する要求を受けた場合は、1個のレコード内で該データベースに対してアクセスを行ない、
    該長大レコード操作手段が、該レコード操作手段が1ページサイズ内に収まらないサイズを有する新規の長大レコードに関する登録要求を受けた場合は、該新規の長大レコードについて、1ページに相当するサイズを有するスライス単位に分解するとともに、該通常レコード操作手段で、該データベースに登録するとともに、
    該長大レコード操作手段が、該データベースに登録され、1ページのサイズ内に収まらないサイズを有する長大レコードであって、複数のスライスにより構成された長大レコードに関する要求を受けた場合は、該長大レコードについて、該スライス単位に分解された長大レコード内での部分的アクセスを該データベースとの間で行なうか、又は該長大レコードのインデクスを生成又は更新し、該長大レコードのアクセスを、該スライスを単位として、該データベースとの間で行なうように構成されたことを特徴とする、ファイル管理装置。
  3. データベースに登録されるファイルを管理するファイル管理装置において、
    レコード又はレコード内の部分的なデータに対する各種レコード操作要求を受け付けるレコード操作手段と、
    該レコード操作手段にて受け付けた該要求の対象となるデータが1ページ内に収まるサイズの通常レコードである場合において、該要求の対象としての新規レコード又はデータベース上で登録されたレコード識別子で示される既存レコードを1ページに収まる通常レコードとして割り当てて、各種レコード操作を行なうとともに、1個の通常レコード内における部分的アクセスを行なうデータページ操作手段と、
    該レコード操作手段にて受け付けた該要求の対象となるデータが、ページ内に収まらないサイズの長大レコードであって、ページ単位に分割された複数のスライスにより構成された長大レコードである場合は、新規レコード又はデータベース上で登録された該長大レコードに対し、操作を受けるスライス単位に分解してから、該データページ操作手段に対して各種レコード操作を該スライス単位に要求する長大レコード操作手段と、
    最下位リーフレベルのインデクスでは各スライスそのもののサイズとスライスへのレコード識別子を格納し、その上の階層のインデクスは下位のインデクスの表すサイズの総和を格納し、最上位のルートレベルのインデクスの表すサイズの総和は該長大レコード全体のサイズに一致し、リーフレベルのインデクスの順番は、これらの対応する各スライスのオフセットの順番に一致するようにインデクスを構成する木インデクス操作手段とをそなえ、
    該長大レコード操作手段が、
    既存の長大レコードに対する部分的なアクセスを行なう場合には、レコード全体に対するオフセットより操作対象となるスライスの開始点を、スライス間のアドレスリンクを順次ナビゲートする方法又は上記木インデクスより求める方法のいずれかにより決定するアクセス開始点決定制御部と、
    スライス単位の追加、削除に伴う上記木インデクスのメンテナンスを該木インデクス操作手段に要求するメンテナンス部とをそなえたことを
    特徴とする、ファイル管理装置。
  4. 該レコード操作手段にて要求を受け付ける各種レコード操作が、レコードに対する新規作成、抹消、フェッチ、レコード内の部分的なデータに対する途中挿入、途中削除、更新又は読み込みのうちのいずれかであることを特徴とする、請求項2又は3記載のファイル管理装置。
  5. 該データページ操作手段が、
    ページ内の各レコードの、通常レコードと長大レコードとの区別を記録するレコード区別記録部をそなえるとともに、
    該レコード操作手段が、
    該データページ操作手段のレコード区別記録部からの、既存のレコードのレコード識別子に対応する前記レコードの区別に基づき、通常レコードの場合には前記データページ操作手段に、長大レコードの場合には該長大レコード操作手段にそれぞれレコード操作を要求する操作要求部をそなえたことを特徴とする、請求項3記載のファイル管理装置。
  6. 該レコード操作手段が、
    既存の通常レコードに対し、操作に伴いレコード全体のサイズが1ページに収まらなくなる場合には、該通常レコードを長大レコードとして登録し直してから該長大レコード操作手段にレコード操作を要求する一方、既存の長大レコードに対し、操作を完了した後、長大レコード全体のサイズが1ページに収まる場合には、このレコード操作の完了した長大レコードを通常レコードとして登録し直す再登録操作部をそなえたことを特徴とする、請求項2記載のファイル管理装置。
  7. 該長大レコード操作手段のアクセス開始点決定制御部が、
    既存の長大レコードに対する部分的なアクセスを行なうスライスの開始点を決定する際に、木インデクスが構成されている場合は該木インデクス操作手段により、無ければスライス自体の持つアドレスリンクをナビゲートしてその開始点を決定するように制御するように構成されたことを特徴とする、請求項3記載のファイル管理装置。
  8. 該長大レコード操作手段のメンテナンス部が、
    該アクセス開始点決定制御部による制御に基づき、該木インデクス操作手段によりアクセス開始点を決定する場合、長大レコード全体のサイズに対する予め決められたしきいサイズとの大小に基づいて、該木インデクスの作成と削除とを決定するように構成されたことを特徴とする、請求項7記載のファイル管理装置。
  9. 該長大レコード操作手段のメンテナンス部が、
    部分的なアクセスの要否により該木インデクスの作成又は削除することを決定するように構成されたことを特徴とする、請求項7記載のファイル管理装置。
  10. 該長大レコード操作手段のメンテナンス部が、
    部分的なアクセスが発生すると、該木インデクスを作成するように構成されたことを特徴とする、請求項9記載のファイル管理装置。
  11. 該長大レコード操作手段のメンテナンス部が、
    長大レコード全体のサイズに対する予め決められたしきいサイズとの大小関係、及び部分的なアクセスの要否により該木インデクスの作成又は削除することを決定するように構成されたことを特徴とする、請求項7記載のファイル管理装置。
  12. 該木インデクス操作手段が、
    長大レコード全体に対するオフセットからスライスを検索する際に、該木インデクスの最上位のルートインデクスページから最下位のリーフインデクスページに至る各インデクスのサイズの積算が、所望のオフセットと一致又は直前となるインデクスを検索し、検索されたインデクスから逐次下位階層のインデクスページに移って検索を行なうことにより、リーフインデクスページ上のインデクスにおいて当該オフセットを含むスライスへのレコード識別子を取得するインデクスページ操作部をそなえたことを特徴とする、請求項3記載のファイル管理装置。
  13. 該長大レコード操作手段が、
    長大レコードに対する部分的な挿入を行なう際に、挿入操作後に新規生成されたスライスの格納ページに空き領域があれば、該新規生成されたスライスと直後のスライス間で併合するインデクスページ間操作部をそなえたことを特徴とする、請求項4記載のファイル管理装置。
  14. 該長大レコード操作手段が、
    長大レコードに対する部分的な削除を行なう際に、削除操作の開始点を含むスライスと終了点をスライス間で併合するインデクスページ間操作部をそなえたことを特徴とする、請求項4記載のファイル管理装置。
  15. 該長大レコード操作手段が、
    長大レコードに対するサイズ変更操作が行なわれた後に、当該長大レコードを構成する全てのスライスについてのスライスサイズの総和を演算する総和演算部と、
    該総和演算部において演算された総和に対する、スライスの個数と1ページサイズの積との比を演算する比演算部と、
    該比演算部において演算された比と、予め設定された比率とを比較する比率比較部と、
    該比率比較部における比率の比較の結果、該比演算部において演算された比が予め設定された比率よりも小さい場合は、隣り合うスライス間において自スライスの空き領域が該自スライスに続くスライスのデータで埋まるように、該全てのスライスについて順次マージしていくことにより、ガベージコレクションを行なうように制御するガベージコレクション制御部をそなえたことを特徴とする、請求項3記載のファイル管理装置。
  16. 該長大レコード操作手段が、
    該メンテナンス部において、該インデクスに対する修正をした後に、修正されたリーフインデクスページ内における、スライスサイズの総和を演算する総和演算部と、
    該総和演算部において演算された総和に対する、スライスの個数と1ページサイズの積との比率を演算する比演算部と、
    該比演算部において演算された比と、予め設定された比率とを比較する比率比較部と、
    該比率比較部における比率の比較の結果、該比演算部において演算された比が予め設定された比率よりも小さい場合は、該リーフインデクスページ内におけるインデクスに対応したスライスについて、隣り合うスライス間において自スライスの空き領域が該自スライスに続くスライスのデータで埋まるように順次マージしていくことにより、ガベージコレクションを行なうように制御するガベージコレクション制御部をそなえたことを特徴とする、請求項3記載のファイル管理装置。
JP05937895A 1995-03-17 1995-03-17 ファイル管理方法及びファイル管理装置 Expired - Fee Related JP3703874B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP05937895A JP3703874B2 (ja) 1995-03-17 1995-03-17 ファイル管理方法及びファイル管理装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP05937895A JP3703874B2 (ja) 1995-03-17 1995-03-17 ファイル管理方法及びファイル管理装置

Publications (2)

Publication Number Publication Date
JPH08255103A JPH08255103A (ja) 1996-10-01
JP3703874B2 true JP3703874B2 (ja) 2005-10-05

Family

ID=13111567

Family Applications (1)

Application Number Title Priority Date Filing Date
JP05937895A Expired - Fee Related JP3703874B2 (ja) 1995-03-17 1995-03-17 ファイル管理方法及びファイル管理装置

Country Status (1)

Country Link
JP (1) JP3703874B2 (ja)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5043820B2 (ja) * 2005-03-11 2012-10-10 ロックソフト リミテッド 低冗長記憶システムで索引を行う方法
JP5338461B2 (ja) * 2009-05-01 2013-11-13 ブラザー工業株式会社 管理装置、情報生成プログラム、及び情報生成方法
JP5278151B2 (ja) * 2009-05-01 2013-09-04 ブラザー工業株式会社 分散保存システム、ノード装置、ノードプログラム、及びページ情報取得方法
JP5278152B2 (ja) * 2009-05-01 2013-09-04 ブラザー工業株式会社 管理装置、ノード装置、ノードプログラム、ページ情報送信プログラム、及びページ情報送信方法
US8516137B2 (en) * 2009-11-16 2013-08-20 Microsoft Corporation Managing virtual hard drives as blobs
CN109657015B (zh) * 2018-12-25 2023-05-02 四川效率源信息安全技术股份有限公司 一种基于oracle行迁移和行连接的数据提取方法

Also Published As

Publication number Publication date
JPH08255103A (ja) 1996-10-01

Similar Documents

Publication Publication Date Title
US8224829B2 (en) Database
US11899641B2 (en) Trie-based indices for databases
US9652483B1 (en) Index server architecture using tiered and sharded phrase posting lists
US8600975B1 (en) Query phrasification
US7139783B2 (en) Materialized view system and method
US8161004B2 (en) XML sub-document versioning method in XML databases using record storages
AU2002222096A1 (en) Method of organising, interrogating and navigating a database
JPH0675265B2 (ja) 情報検索方法及びシステム
US20140136513A1 (en) Query management system and engine allowing for efficient query execution on raw details
WO2010084754A1 (ja) データベースシステム、データベース管理方法、データベース構造および記憶媒体
JP3703874B2 (ja) ファイル管理方法及びファイル管理装置
JP5790755B2 (ja) データベース管理装置及びデータベース管理方法
CN113392089B (zh) 一种数据库索引优化方法及可读存储介质
WO2012081165A1 (ja) データベース管理装置及びデータベース管理方法
JP2006092409A (ja) 複合データベース検索システムおよび複合データベース検索方法ならびにそのためのプログラム
Walczuch et al. Using individual prefixes in B+-trees
JPH07210563A (ja) 索引処理方法
Papadias Adaptive Index Structures
JP2000322293A (ja) データベース管理方法及びその実施装置並びにその処理プログラムを記録した記録媒体
JPH05143644A (ja) 索引部管理方式

Legal Events

Date Code Title Description
A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20041026

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20041227

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20050719

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20050721

R150 Certificate of patent or registration of utility model

Free format text: JAPANESE INTERMEDIATE CODE: R150

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20080729

Year of fee payment: 3

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20090729

Year of fee payment: 4

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20100729

Year of fee payment: 5

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20100729

Year of fee payment: 5

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20110729

Year of fee payment: 6

LAPS Cancellation because of no payment of annual fees