(57)【要約】【課題】ブロックに対してレコードの保存、保存済みレコードの削除を可能とする。【解決手段】データをレコードとしてブッロク単位で管理するデータベースのサイズ管理システムに、ブロックの最大個数N、ブロックサイズB、レコードの最大サイズの次に大きいサイズRmax-1、保存済みレコードの合計Rsum、これから保存しようとするレコードのサイズRnewとし、N*(B-Rmax-1))-Rsum≧Rnew…(式1)を立て、(式1)を満足する場合、保存しようとするレコードが存在すると判断するレコード保存可否判断部401Aと、(式1)を満足せず、すべてのブロックが容量満杯と判断した時に、削除するレコードの候補のサイズの合計Rdelとし、N*(B-Rmax-1))-Rsum+Rdel≧Rnew…(式2)を立て、(式2)を満足する候補を選択し、選択後に、選択したデータを削除した上で新規レコードが保存可能か否かを、(式1)を用いて、判断させるレコード削除部401Bとを備える。【選択図】図１
2009080575.tif 000002
【特許請求の範囲】
【請求項１】
データをレコードとしてブッロク単位で管理するデータベースのサイズ管理システムにおいて、
ブロックの最大個数Ｎ、ブロックサイズＢ、レコードの最大サイズの次に大きいサイズＲｍａｘ−１、保存済みレコードの合計Ｒｓｕｍ、これから保存しようとするレコードのサイズＲｎｅｗとし、下記式を立て、
Ｎ＊（Ｂ−（Ｒｍａｘ−１））−Ｒｓｕｍ≧Ｒｎｅｗ…（式１）
上記（式１）を満足する場合、保存しようとするレコードが存在すると判断するレコード保存可否判断部と、
上記（式１）を満足せず、すべてのブロックが容量満杯と判断した時に、削除するレコードの候補のサイズの合計Ｒｄｅｌとし、下記式を立て、
Ｎ＊（Ｂ−（Ｒｍａｘ−１））−Ｒｓｕｍ＋Ｒｄｅｌ≧Ｒｎｅｗ…（式２）
上記（式２）を満足する候補を選択し、選択後に、選択したデータを削除した上で新規レコードが保存可能か否かを、前記レコード保存可否判断部に対して上記（式１）を用いて、判断させるレコード削除部とを備えることを特徴とするデータベースのサイズ管理システム。
【請求項２】
前記レコード保存可否判断部は、レコードのサイズが大きくレコードが複数のブロックにまたがる場合にはレコードが複数に分割され、分割されたレコードには管理用ヘッダが付与され、空き領域が一定のサイズ（Ｂｓｐｃ）以上でないと、保存しないという条件を付け、下記式を立て、
Ｎ＊（Ｂ−Ｂｓｐｃ）−Ｒｓｕｍ≧Ｒｎｅｗ…（式３）
上記（式３）を満足する場合、保存しようとするレコードが存在すると判断し、
前記レコード削除部は、上記（式３）を満足せず、すべてのブロックが容量満杯と判断した時に、下記式を立て、
Ｎ＊（Ｂ−Ｂｓｐｃ）−Ｒｓｕｍ＋Ｒｄｅｌ≧Ｒｎｅｗ…（式４）
上記（式４）を満足する候補を選択し、選択後に、選択したデータを削除した上で新規レコードが保存可能か否かを、前記レコード保存可否判断部に対して上記（式３）を用いて、判断させることを特徴とする、請求項１に記載のデータベースのサイズ管理システム。
【請求項３】
前記レコード削除部は、古いレコードの順にという条件で、新規レコードが保存可能となる解除レコードを選択することを特徴とする、請求項１又は２に記載のデータベースのサイズ管理システム。
【請求項４】
前記レコード保存可否判断部、前記レコード削除部は、各前記レコードが保持する自分自身のサイズに基づき、保存済みレコードの合計であるサイズＲｓｕｍを算出することを特徴とする、請求項１又は２に記載のデータベースのサイズ管理システム。
【請求項５】
データをレコードとしてブッロク単位で管理するデータベースのサイズ管理方法において、
ブロックの最大個数Ｎ、ブロックサイズＢ、レコードの最大サイズの次に大きいサイズＲｍａｘ−１、保存済みレコードの合計Ｒｓｕｍ、これから保存しようとするレコードのサイズＲｎｅｗとし、下記式を立て、
Ｎ＊（Ｂ−（Ｒｍａｘ−１））−Ｒｓｕｍ≧Ｒｎｅｗ…（式１）
上記（式１）を満足する場合、保存しようとするレコードが存在すると判断する工程と、
上記（式１）を満足せず、すべてのブロックが容量満杯と判断した時に、削除するレコードの候補のサイズの合計Ｒｄｅｌとし、下記式を立て、
Ｎ＊（Ｂ−（Ｒｍａｘ−１））−Ｒｓｕｍ＋Ｒｄｅｌ≧Ｒｎｅｗ…（式２）
上記（式２）を満足する候補を選択し、選択後に、選択したデータを削除した上で新規レコードが保存可能か否かを、上記（式１）を用いて、判断させる工程とを備えることを特徴とするデータベースのサイズ管理方法。
【請求項６】
レコードのサイズが大きくレコードが複数のブロックにまたがる場合にはレコードが複数に分割され、分割されたレコードには管理用ヘッダが付与され、空き領域が一定のサイズ（Ｂｓｐｃ）以上でないと、保存しないという条件を付け、下記式を立て、
Ｎ＊（Ｂ−Ｂｓｐｃ）−Ｒｓｕｍ≧Ｒｎｅｗ…（式３）
上記（式３）を満足する場合、保存しようとするレコードが存在すると判断する工程と、
上記（式３）を満足せず、すべてのブロックが容量満杯と判断した時に、下記式を立て、
Ｎ＊（Ｂ−Ｂｓｐｃ）−Ｒｓｕｍ＋Ｒｄｅｌ≧Ｒｎｅｗ…（式４）
上記（式４）を満足する候補を選択し、選択後に、選択したデータを削除した上で新規レコードが保存可能か否かを、上記（式３）を用いて、判断させる工程とを備えることを特徴とする、請求項５に記載のデータベースのサイズ管理方法。
【請求項７】
データをレコードとしてブッロク単位で管理するデータベースのサイズ管理プログラムにおいて、
ブロックの最大個数Ｎ、ブロックサイズＢ、レコードの最大サイズの次に大きいサイズＲｍａｘ−１、保存済みレコードの合計Ｒｓｕｍ、これから保存しようとするレコードのサイズＲｎｅｗとし、下記式を立て、
Ｎ＊（Ｂ−（Ｒｍａｘ−１））−Ｒｓｕｍ≧Ｒｎｅｗ…（式１）
上記（式１）を満足する場合、保存しようとするレコードが存在すると判断する手順と、
上記（式１）を満足せず、すべてのブロックが容量満杯と判断した時に、削除するレコードの候補のサイズの合計Ｒｄｅｌとし、下記式を立て、
Ｎ＊（Ｂ−（Ｒｍａｘ−１））−Ｒｓｕｍ＋Ｒｄｅｌ≧Ｒｎｅｗ…（式２）
上記（式２）を満足する候補を選択し、選択後に、選択したデータを削除した上で新規レコードが保存可能か否かを、上記（式１）を用いて、判断させる手順とを備えることを特徴とするデータベースのサイズ管理プログラム。
【請求項８】
レコードのサイズが大きくレコードが複数のブロックにまたがる場合にはレコードが複数に分割され、分割されたレコードには管理用ヘッダが付与され、空き領域が一定のサイズ（Ｂｓｐｃ）以上でないと、保存しないという条件を付け、下記式を立て、
Ｎ＊（Ｂ−Ｂｓｐｃ）−Ｒｓｕｍ≧Ｒｎｅｗ…（式３）
上記（式３）を満足する場合、保存しようとするレコードが存在すると判断する手順と、
上記（式３）を満足せず、すべてのブロックが容量満杯と判断した時に、下記式を立て、
Ｎ＊（Ｂ−Ｂｓｐｃ）−Ｒｓｕｍ＋Ｒｄｅｌ≧Ｒｎｅｗ…（式４）
上記（式４）を満足する候補を選択し、選択後に、選択したデータを削除した上で新規レコードが保存可能か否かを、上記（式３）を用いて、判断させる手順とを備えることを特徴とする、請求項７に記載のデータベースのサイズ管理プログラム。
【請求項９】
データをレコードとしてブッロク単位で管理するデータベースのサイズ管理を行う情報処理システムおいて、
ブロック単位で高速にアクセスを行うバッファ、データをレコードとしてブッロク単位で保存しアクセス速度の遅いデータベースを有し、前記バッファ、前記データベースの管理を行うデータベース管理システムが稼動する１つの情報処理装置と、
前記１つの情報装置とネットワークを介して通信を行い、前記１つの情報処理装置のデータベースのクライアントとして稼動するアプリケーションを有する複数の情報処理装置と、
前記アプリケーションは、
ブロックの最大個数Ｎ、ブロックサイズＢ、レコードの最大サイズの次に大きいサイズＲｍａｘ−１、保存済みレコードの合計Ｒｓｕｍ、これから保存しようとするレコードのサイズＲｎｅｗとし、下記式を立て、
Ｎ＊（Ｂ−（Ｒｍａｘ−１））−Ｒｓｕｍ≧Ｒｎｅｗ…（式１）
上記（式１）を満足する場合、保存しようとするレコードが存在すると判断するレコード保存可否判断部と、
上記（式１）を満足せず、すべてのブロックが容量満杯と判断した時に、削除するレコードの候補のサイズの合計Ｒｄｅｌとし、下記式を立て、
Ｎ＊（Ｂ−（Ｒｍａｘ−１））−Ｒｓｕｍ＋Ｒｄｅｌ≧Ｒｎｅｗ…（式２）
上記（式２）を満足する候補を選択し、選択後に、選択したデータを削除した上で新規レコードが保存可能か否かを、前記レコード保存可否判断部に対して上記（式１）を用いて、判断させるレコード削除部とを備え、前記１つ情報処理装置のデータベース管理システムにレコードの保存、削除を要求することを特徴とする情報処理システム。
【請求項１０】
前記レコード保存可否判断部は、レコードのサイズが大きくレコードが複数のブロックにまたがる場合にはレコードが複数に分割され、分割されたレコードには管理用ヘッダが付与され、空き領域が一定のサイズ（Ｂｓｐｃ）以上でないと、保存しないという条件を付け、下記式を立て、
Ｎ＊（Ｂ−Ｂｓｐｃ）−Ｒｓｕｍ≧Ｒｎｅｗ…（式３）
上記（式３）を満足する場合、保存しようとするレコードが存在すると判断し、
前記レコード削除部は、上記（式３）を満足せず、すべてのブロックが容量満杯と判断した時に、下記式を立て、
Ｎ＊（Ｂ−Ｂｓｐｃ）−Ｒｓｕｍ＋Ｒｄｅｌ≧Ｒｎｅｗ…（式４）
上記（式４）を満足する候補を選択し、選択後に、選択したデータを削除した上で新規レコードが保存可能か否かを、前記レコード保存可否判断部に対して上記（式３）を用いて、判断させることを特徴とする、請求項８に記載の情報処理システム。
【請求項１１】
データをレコードとしてブッロク単位で管理するデータベースのサイズ管理を行う情報処理装置おいて、
ブロック単位で高速にアクセスを行うバッファと、
データをレコードとしてブッロク単位で保存しアクセス速度の遅いデータベースと、
前記バッファ、前記データベースの管理を行うデータベース管理システムと、
前記データベース管理システムは、
ブロックの最大個数Ｎ、ブロックサイズＢ、レコードの最大サイズの次に大きいサイズＲｍａｘ−１、保存済みレコードの合計Ｒｓｕｍ、これから保存しようとするレコードのサイズＲｎｅｗとし、下記式を立て、
Ｎ＊（Ｂ−（Ｒｍａｘ−１））−Ｒｓｕｍ≧Ｒｎｅｗ…（式１）
上記（式１）を満足する場合、保存しようとするレコードが存在すると判断するレコード保存可否判断部と、
上記（式１）を満足せず、すべてのブロックが容量満杯と判断した時に、削除するレコードの候補のサイズの合計Ｒｄｅｌとし、下記式を立て、
Ｎ＊（Ｂ−（Ｒｍａｘ−１））−Ｒｓｕｍ＋Ｒｄｅｌ≧Ｒｎｅｗ…（式２）
上記（式２）を満足する候補を選択し、選択後に、選択したデータを削除した上で新規レコードが保存可能か否かを、前記レコード保存可否判断部に対して上記（式１）を用いて、判断させるレコード削除部とを備えることを特徴とする情報処理装置。
【請求項１２】
前記レコード保存可否判断部は、レコードのサイズが大きくレコードが複数のブロックにまたがる場合にはレコードが複数に分割され、分割されたレコードには管理用ヘッダが付与され、空き領域が一定のサイズ（Ｂｓｐｃ）以上でないと、保存しないという条件を付け、下記式を立て、
Ｎ＊（Ｂ−Ｂｓｐｃ）−Ｒｓｕｍ≧Ｒｎｅｗ…（式３）
上記（式３）を満足する場合、保存しようとするレコードが存在すると判断し、
前記レコード削除部は、上記（式３）を満足せず、すべてのブロックが容量満杯と判断した時に、下記式を立て、
Ｎ＊（Ｂ−Ｂｓｐｃ）−Ｒｓｕｍ＋Ｒｄｅｌ≧Ｒｎｅｗ…（式４）
上記（式４）を満足する候補を選択し、選択後に、選択したデータを削除した上で新規レコードが保存可能か否かを、前記レコード保存可否判断部に対して上記（式３）を用いて、判断させることを特徴とする、請求項１０に記載の情報処理装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はデータをレコードとしてブロック単位に保存するデータベースシステムに関する。特に、本発明は、ブロックに保存されるレコードのサイズを管理するデータベースのサイズ管理システム、方法、プログラム、情報処理システム及び情報装置に関する。
【背景技術】
【０００２】
従来、データベース管理システム（ＤＢＭＳ）はサーバーなどの大規模なシステム向けに発展してきたため、トランザクションの処理性能の向上に重点がおかれ、記憶領域の制約はハードウエアの追加によりカバーできるものであった。
しかし、近年の携帯端末の高機能化により、大量のデータを携帯端末で扱うことができるようになったため、携帯端末へのデータベース管理システムの組み込みが検討され始めているが、物理的にサイズの制限により、記憶領域のサイズに制約があるため、サイズ管理の問題が重要となる。
【０００３】
本発明の前提となるデータベースシステムでは、アクセス性能を向上させるため、アクセス速度の遅いディスク等の記憶装置から一度読み込んだデータを、アクセス速度の速いメモリ上のバッファへキャッシュし、次回アクセス時にバッファから読み込む仕組みを有している。キャッシュを行う単位は、一定サイズのブロックである。
図７は本発明の前提となるデータベースシステムにおけるデータの保存方法例を説明する概略データ構造図である。本図(ａ)に示すように、データはレコードとしてブロック単位に保存される。レコードの最大サイズはブロックのサイズよりも小さく、通常、保存しようとする新規レコードのサイズはブロックサイズよりも小さいので、ブロックには空き領域が生じる。なお、レコードには管理ヘッダが付いている。
【０００４】
本図(ｂ)に示すように、レコードが削除されブロックの途中に空き領域が発生すると、本図(ｃ)に示すように、ブロック内でレコードを詰めることで空き領域をブロックの後ろにまとめる。
図８は本発明の前提となるデータベースシステムにおけるデータの他の保存方法例を説明する概略データ構造図である。１つのレコードはブロックをまたいで保存することはできないので、本図(ａ)に示すように、新規レコードのサイズが空き領域よりも大きい場合には、本図(ｂ)に示すように、新規ブロックを確保してそこに新規レコードを保持する。
【０００５】
なお、新規レコードを分割して分割したレコードがブロックを単純にまたいで保存されることはできないが、分割したレコードに管理用ヘッダを付ければ、空き領域に保存可能である。この点については発明の詳細な説明で後述する。
このように、ブロックのサイズの上限が決まっている場合、空き領域へは、空き領域より大きなレコードは保存できず、小さいレコードしか保存できないため、空き領域のサイズの合計と新規レコードのサイズの比較だけでは、新規レコードが保存可能か否かを判断することができず、実際に保存するまでは保存可否がわからないという問題がある。
【０００６】
さらに、すべてのブロックの容量満杯で新規データが保存できない場合に、既存のレコードを削除することで新規レコードを保存可能としたい場合、どのレコードを削除すれば新規レコードが保存可能となるか否か、実際に保存済みレコードを削除して新規レコードを保存するまでわからないという問題がある。
これらの問題は、携帯電話でのメール保存時など、通信が発生する前に判断が必要な場合に特に問題となる。
【０００７】
このような問題に関連して以下の従来の技術がある。
従来、計算式を用いてあらかじめ見積もり計算することを回避できるため、まず、データベースにインデックスを含む作成予定のテーブルを作成することにより容量が確保されると共にテーブル構成情報とデータベース定義情報とが作成され、計算対象のテーブル構成情報に対するレコード数が入力された際、容量計算部は入力されたレコード数とテーブル構成情報とに基づきデータベースの必要容量を算出して一時テーブルに格納し、容量判断部は算出された必要容量が先に確保された容量で間に合う場合に間に合い通知と必要容量とを出力し、間に合わない場合にはサイズ変更判断部が必要容量と空き領域とを比較し、空き領域が不足の場合には確保不可能通知と必要容量とを出力し、空き領域で確保できる場合にはサイズ変更実行部がサイズ変更して変更通知と変更後容量とを出力しているものがある（例えば、特許文献１参照）。
【０００８】
しかしながら、上記特許文献１では、データベースの空き領域と必要容量とを比較するが、本発明の前提となるデータベースではブロック単位でレコードを保存し、ブロックは一定のサイズであるので、ブロックの空き領域へは空き領域よりも大きなレコードは保存することはできず、小さなレコードだけしか保存できないので、単にデータベースの空き容量と必要量の比較だけでは、保存前にブロックに対してレコードの保存の判断はできない。
【０００９】
従来、データ記憶装置はマイコンを含み、マイコンは新規データが入力されると、その新規データに対応する予め設定された重要度レベルなどの属性情報を第２バッファメモリに格納し、フラッシュメモリに十分な空容量がある場合には、そのまま新規データおよびそれに対応する属性情報（テーブルデータ）が記憶され、一方、十分な空容量がない場合には、保存データを削除し、空容量を確保してから新規データを記憶し、つまり、自動削除であれば、重要度レベルが低く、日付の古いものから順に保存データが削除され、一方、手動削除であれば、オペレータの指示に従って選択的に保存データが削除され、このように、属性情報に基づいてデータが管理されることにより、属性情報に基づいてデータを管理するので、簡単にデータを管理することができるものがある（例えば、特許文献２参照）。
【００１０】
しかしながら、特許文献２では、十分な空き容量がある場合には新規データが記憶されるが、前述のように、本発明の前提となるデータベースではブロック単位でレコードを保存し、ブロックは一定のサイズであるので、ブロックの空き領域へは空き領域よりも大きなレコードは保存することはできず、小さなレコードだけしか保存できないので、単に十分な空き容量があるだけでは、保存前にブロックに対してレコードの保存の判断はできない。
【００１１】
従来、本発明は、データベースの表領域の各セグメントに対する新たなエクステントの割り当ての際の記憶容量不足を事前に察知することで障害を未然に防ぐことができるデータベース容量監視装置およびデータベース容量監視方法を提供することを課題とし、データベースの各表領域の連続未使用領域を算出する空き容量算出部と、データベースの各表領域に配置されている各セグメント毎の次に割り当てられるエクステントサイズの最大のサイズを抽出するエクステント抽出部と、連続未使用領域の容量と次に割り当てられるエクステントのサイズの最大のサイズとをデータベースの各表領域毎に比較する容量比較部とからなるものがある（例えば、特許文献３参照）。
【００１２】
しかしながら、特許文献３では、連続未使用領域の容量と次に割り当てられるエクステントのサイズの最大のサイズとをデータベースの各表領域毎に比較するが、前述のように、本発明の前提となるデータベースではブロック単位でレコードを保存し、ブロックは一定のサイズであるので、ブロックの空き領域へは空き領域よりも大きなレコードは保存することはできず、小さなレコードだけしか保存できないので、連続未使用領域の容量と次に割り当てられるエクステントのサイズの最大のサイズとをデータベースの各表領域毎に比較するだけでは、保存前にブロックに対してレコードの保存の判断はできない。
【００１３】
従来、客観的にデータベースファイルの使用状況を把握することができ、しかもデータベースファイル容量の超過によるシステムの障害を未然に回避できるリレーショナルデータベース管理システムを提供するためカラムと行から構成されるテーブルを有するデータベースファイルが作成されたデータベースを管理するリレーショナルデータベース管理システムにおいて、テーブルに予め設定されたデータ領域からなるエクステントのサイズとカラムのサイズの総和とに基づいてテーブルに格納可能な最大レコード格納件数を計算するレコード格納件数計算部と、このレコード格納件数計算部で計算された最大レコード格納件数と実際のレコード格納件数とに基づいてデータベースファイルの使用率を計算するファイル使用率計算部とを備えるものがある（例えば、特許文献４参照）。
【００１４】
しかしながら、特許文献４では、最大レコード格納件数と実際のレコード格納件数とに基づいてデータベースファイルの使用率を計算するが、前述のように、本発明の前提となるデータベースではブロック単位でレコードを保存し、ブロックは一定のサイズであるので、ブロックの空き領域へは空き領域よりも大きなレコードは保存することはできず、小さなレコードだけしか保存できないので、最大レコード格納件数と実際のレコード格納件数とに基づいてデータベースファイルの使用率を計算するだけでは、保存前にブロックに対してレコードの保存の判断はできない。
【００１５】
従来、限られた容量の記録媒体に、データファイルの冗長度を高めることなくファイル管理ができるようにデータを記録し、しかも、記録媒体を効率よく利用できるよう考慮されたデータ記録再生装置および情報記録再生システムを提供するため、ファイル選択手段は、記録手段が記録しようとしているデータファイルの容量が、残量検出手段の検出した記録媒体の空き容量よりも大きい場合、記録媒体に記録されているデータファイルのうち、記録時刻検出手段の検出した記録時刻の古い順に１以上のデータファイルを削除対象データファイルとして選択し、削除手段に削除を指示し、制御手段は、再生手段によるデータファイルの再生時間を計測し、再生時間が予め定めた時間以上であった場合、データファイルについての記録時刻を再生した時刻に書き換えるよう、記録手段に指示するものがある。（例えば、特許文献５参照）。
【００１６】
しかしながら、特許文献５では、データファイルの容量と残量検出手段の検出した記録媒体の空き容量との比較を行っているが、前述のように、本発明の前提となるデータベースではブロック単位でレコードを保存し、ブロックは一定のサイズであるので、ブロックの空き領域へは空き領域よりも大きなレコードは保存することはできず、小さなレコードだけしか保存できないので、データファイルの容量と残量検出手段の検出した記録媒体の空き容量との比較を行うだけでは、保存前にブロックに対してレコードの保存の判断はできない。
【００１７】
従来、情報格納装置の空き容量に応じてアプリケーションプログラムの削除／再組み込みなどを自動実行することのできる容量管理システムを提供するため、ディスク空き容量しきい値比較部は、ディスク容量管理部から送信されるディスクデバイスの空き容量がディスク空き容量しきい値を下回ったことを検知すると、その旨をアプリケーション管理部１３に通知し、そして、この通知を受け取ったアプリケーション管理部は、アプリケーション管理情報を参照することにより、たとえば最終利用日時が古い順に選択していくなど、削除対象とするのに適切なアプリケーションプログラムを適切な数（これらの総容量と空き容量との和が所定の値を越えるまで）だけ選択し、この選択したアプリケーションプログラムを構成するファイルを自動的に削除するものがある（例えば、特許文献６参照）。
【００１８】
しかしながら、特許文献６では、ディスクデバイスの空き容量とディスク空き容量しきい値との比較を行うが、前述のように、本発明の前提となるデータベースではブロック単位でレコードを保存し、ブロックは一定のサイズであるので、ブロックの空き領域へは空き領域よりも大きなレコードは保存することはできず、小さなレコードだけしか保存できないので、ディスクデバイスの空き容量とディスク空き容量しきい値との比較を行うだけでは、保存前にブロックに対してレコードの保存の判断はできない。
【００１９】
【特許文献１】特開２０００−２５９４６９号公報
【特許文献２】特開２０００−３３９２００号公報
【特許文献３】特開２００１−１７５５１３号公報
【特許文献４】特開２００１−２５６０８５号公報
【特許文献５】特開２００３−８５００８号公報
【特許文献６】特開平１０−２６０８７３号公報
【発明の開示】
【発明が解決しようとする課題】
【００２０】
したがって、本発明は上記問題点に鑑みて、保存前にブロックに対してレコードの保存の判断を可能とし、保存済みレコードを削除して新規レコードを保存することを可能とするデータベースのサイズ管理システム、方法、プログラム、情報処理システム及び情報処理装置を提供することを目的とする。
【課題を解決するための手段】
【００２１】
本発明は前記問題点を解決するために、データをレコードとしてブッロク単位で管理するデータベースのサイズ管理システムにおいて、ブロックの最大個数Ｎ、ブロックサイズＢ、レコードの最大サイズの次に大きいサイズＲｍａｘ−１、保存済みレコードの合計Ｒｓｕｍ、これから保存しようとするレコードのサイズＲｎｅｗとし、下記式を立て、
Ｎ＊（Ｂ−（Ｒｍａｘ−１））−Ｒｓｕｍ≧Ｒｎｅｗ…（式１）
上記（式１）を満足する場合、保存しようとするレコードが存在すると判断するレコード保存可否判断部と、上記（式１）を満足せず、すべてのブロックが容量満杯と判断した時に、削除するレコードの候補のサイズの合計Ｒｄｅｌとし、下記式を立て、
Ｎ＊（Ｂ−（Ｒｍａｘ−１））−Ｒｓｕｍ＋Ｒｄｅｌ≧Ｒｎｅｗ…（式２）
上記（式２）を満足する候補を選択し、選択後に、選択したデータを削除した上で新規レコードが保存可能か否かを、前記レコード保存可否判断部に対して上記（式１）を用いて、判断させるレコード削除部とを備えることを特徴とするデータベースのサイズ管理システムを提供する。
【００２２】
さらに、前記レコード保存可否判断部は、レコードのサイズが大きくレコードが複数のブロックにまたがる場合にはレコードが複数に分割され、分割されたレコードには管理用ヘッダが付与され、空き領域が一定のサイズ（Ｂｓｐｃ）以上でないと、保存しないという条件を付け、下記式を立て、
Ｎ＊（Ｂ−Ｂｓｐｃ）−Ｒｓｕｍ≧Ｒｎｅｗ…（式３）
上記（式３）を満足する場合、保存しようとするレコードが存在すると判断し、前記レコード削除部は、上記（式３）を満足せず、すべてのブロックが容量満杯と判断した時に、下記式を立て、
Ｎ＊（Ｂ−Ｂｓｐｃ）−Ｒｓｕｍ＋Ｒｄｅｌ≧Ｒｎｅｗ…（式４）
上記（式４）を満足する候補を選択し、選択後に、選択したデータを削除した上で新規レコードが保存可能か否かを、前記レコード保存可否判断部に対して上記（式３）を用いて、判断させる。
【００２３】
さらに、前記レコード削除部は、古いレコードの順にという条件で、新規レコードが保存可能となる解除レコードを選択する。
さらに、前記レコード保存可否判断部、前記レコード削除部は、各前記レコードが保持する自分自身のサイズに基づき、保存済みレコードの合計であるサイズＲｓｕｍを算出する。
【００２４】
さらに、本発明は、データをレコードとしてブッロク単位で管理するデータベースのサイズ管理方法において、ブロックの最大個数Ｎ、ブロックサイズＢ、レコードの最大サイズの次に大きいサイズＲｍａｘ−１、保存済みレコードの合計Ｒｓｕｍ、これから保存しようとするレコードのサイズＲｎｅｗとし、下記式を立て、
Ｎ＊（Ｂ−（Ｒｍａｘ−１））−Ｒｓｕｍ≧Ｒｎｅｗ…（式１）
上記（式１）を満足する場合、保存しようとするレコードが存在すると判断する工程と、上記（式１）を満足せず、すべてのブロックが容量満杯と判断した時に、削除するレコードの候補のサイズの合計Ｒｄｅｌとし、下記式を立て、
Ｎ＊（Ｂ−（Ｒｍａｘ−１））−Ｒｓｕｍ＋Ｒｄｅｌ≧Ｒｎｅｗ…（式２）
上記（式２）を満足する候補を選択し、選択後に、選択したデータを削除した上で新規レコードが保存可能か否かを、上記（式１）を用いて、判断させる工程とを備えることを特徴とするデータベースのサイズ管理方法を提供する。
【００２５】
さらに、本発明は、レコードのサイズが大きくレコードが複数のブロックにまたがる場合にはレコードが複数に分割され、分割されたレコードには管理用ヘッダが付与され、空き領域が一定のサイズ（Ｂｓｐｃ）以上でないと、保存しないという条件を付け、下記式を立て、
Ｎ＊（Ｂ−Ｂｓｐｃ）−Ｒｓｕｍ≧Ｒｎｅｗ…（式３）
上記（式３）を満足する場合、保存しようとするレコードが存在すると判断する工程と、上記（式３）を満足せず、すべてのブロックが容量満杯と判断した時に、下記式を立て、
Ｎ＊（Ｂ−Ｂｓｐｃ）−Ｒｓｕｍ＋Ｒｄｅｌ≧Ｒｎｅｗ…（式４）
上記（式４）を満足する候補を選択し、選択後に、選択したデータを削除した上で新規レコードが保存可能か否かを、上記（式３）を用いて、判断させる工程とを備える。
【００２６】
さらに、本発明は、データをレコードとしてブッロク単位で管理するデータベースのサイズ管理プログラムにおいて、ブロックの最大個数Ｎ、ブロックサイズＢ、レコードの最大サイズの次に大きいサイズＲｍａｘ−１、保存済みレコードの合計Ｒｓｕｍ、これから保存しようとするレコードのサイズＲｎｅｗとし、下記式を立て、
Ｎ＊（Ｂ−（Ｒｍａｘ−１））−Ｒｓｕｍ≧Ｒｎｅｗ…（式１）
上記（式１）を満足する場合、保存しようとするレコードが存在すると判断する手順と、上記（式１）を満足せず、すべてのブロックが容量満杯と判断した時に、削除するレコードの候補のサイズの合計Ｒｄｅｌとし、下記式を立て、
Ｎ＊（Ｂ−（Ｒｍａｘ−１））−Ｒｓｕｍ＋Ｒｄｅｌ≧Ｒｎｅｗ…（式２）
上記（式２）を満足する候補を選択し、選択後に、選択したデータを削除した上で新規レコードが保存可能か否かを、上記（式１）を用いて、判断させる手順とを備えることを特徴とするデータベースのサイズ管理プログラムを提供する。
【００２７】
さらに、本発明は、レコードのサイズが大きくレコードが複数のブロックにまたがる場合にはレコードが複数に分割され、分割されたレコードには管理用ヘッダが付与され、空き領域が一定のサイズ（Ｂｓｐｃ）以上でないと、保存しないという条件を付け、下記式を立て、
Ｎ＊（Ｂ−Ｂｓｐｃ）−Ｒｓｕｍ≧Ｒｎｅｗ…（式３）
上記（式３）を満足する場合、保存しようとするレコードが存在すると判断する手順と、上記（式３）を満足せず、すべてのブロックが容量満杯と判断した時に、下記式を立て、
Ｎ＊（Ｂ−Ｂｓｐｃ）−Ｒｓｕｍ＋Ｒｄｅｌ≧Ｒｎｅｗ…（式４）
上記（式４）を満足する候補を選択し、選択後に、選択したデータを削除した上で新規レコードが保存可能か否かを、上記（式３）を用いて、判断させる手順とを備える。
【００２８】
さらに、本発明は、データをレコードとしてブッロク単位で管理するデータベースのサイズ管理を行う情報処理システムおいて、ブロック単位で高速にアクセスを行うバッファ、データをレコードとしてブッロク単位で保存しアクセス速度の遅いデータベースを有し、前記バッファ、前記データベースの管理を行うデータベース管理システムが稼動する１つの情報処理装置と、前記１つの情報装置とネットワークを介して通信を行い、前記１つの情報処理装置のデータベースのクライアントとして稼動するアプリケーションを有する複数の情報処理装置と、前記アプリケーションは、ブロックの最大個数Ｎ、ブロックサイズＢ、レコードの最大サイズの次に大きいサイズＲｍａｘ−１、保存済みレコードの合計Ｒｓｕｍ、これから保存しようとするレコードのサイズＲｎｅｗとし、下記式を立て、
Ｎ＊（Ｂ−（Ｒｍａｘ−１））−Ｒｓｕｍ≧Ｒｎｅｗ…（式１）
上記（式１）を満足する場合、保存しようとするレコードが存在すると判断するレコード保存可否判断部と、上記（式１）を満足せず、すべてのブロックが容量満杯と判断した時に、削除するレコードの候補のサイズの合計Ｒｄｅｌとし、下記式を立て、
Ｎ＊（Ｂ−（Ｒｍａｘ−１））−Ｒｓｕｍ＋Ｒｄｅｌ≧Ｒｎｅｗ…（式２）
上記（式２）を満足する候補を選択し、選択後に、選択したデータを削除した上で新規レコードが保存可能か否かを、前記レコード保存可否判断部に対して上記（式１）を用いて、判断させるレコード削除部とを備え、前記１つ情報処理装置のデータベース管理システムにレコードの保存、削除を要求することを特徴とする情報処理システムを提供する。
【００２９】
さらに、本発明は、前記レコード保存可否判断部は、レコードのサイズが大きくレコードが複数のブロックにまたがる場合にはレコードが複数に分割され、分割されたレコードには管理用ヘッダが付与され、空き領域が一定のサイズ（Ｂｓｐｃ）以上でないと、保存しないという条件を付け、下記式を立て、
Ｎ＊（Ｂ−Ｂｓｐｃ）−Ｒｓｕｍ≧Ｒｎｅｗ…（式３）
上記（式３）を満足する場合、保存しようとするレコードが存在すると判断し、前記レコード削除部は、上記（式３）を満足せず、すべてのブロックが容量満杯と判断した時に、下記式を立て、
Ｎ＊（Ｂ−Ｂｓｐｃ）−Ｒｓｕｍ＋Ｒｄｅｌ≧Ｒｎｅｗ…（式４）
上記（式４）を満足する候補を選択し、選択後に、選択したデータを削除した上で新規レコードが保存可能か否かを、前記レコード保存可否判断部に対して上記（式３）を用いて、判断させる。
【００３０】
さらに、本発明は、データをレコードとしてブッロク単位で管理するデータベースのサイズ管理を行う情報処理装置おいて、ブロック単位で高速にアクセスを行うバッファと、データをレコードとしてブッロク単位で保存しアクセス速度の遅いデータベースと、前記バッファ、前記データベースの管理を行うデータベース管理システムと、前記データベース管理システムは、ブロックの最大個数Ｎ、ブロックサイズＢ、レコードの最大サイズの次に大きいサイズＲｍａｘ−１、保存済みレコードの合計Ｒｓｕｍ、これから保存しようとするレコードのサイズＲｎｅｗとし、下記式を立て、
Ｎ＊（Ｂ−（Ｒｍａｘ−１））−Ｒｓｕｍ≧Ｒｎｅｗ…（式１）
上記（式１）を満足する場合、保存しようとするレコードが存在すると判断するレコード保存可否判断部と、上記（式１）を満足せず、すべてのブロックが容量満杯と判断した時に、削除するレコードの候補のサイズの合計Ｒｄｅｌとし、下記式を立て、
Ｎ＊（Ｂ−（Ｒｍａｘ−１））−Ｒｓｕｍ＋Ｒｄｅｌ≧Ｒｎｅｗ…（式２）
上記（式２）を満足する候補を選択し、選択後に、選択したデータを削除した上で新規レコードが保存可能か否かを、前記レコード保存可否判断部に対して上記（式１）を用いて、判断させるレコード削除部とを備えることを特徴とする情報処理装置を提供する。
【００３１】
さらに、前記レコード保存可否判断部は、レコードのサイズが大きくレコードが複数のブロックにまたがる場合にはレコードが複数に分割され、分割されたレコードには管理用ヘッダが付与され、空き領域が一定のサイズ（Ｂｓｐｃ）以上でないと、保存しないという条件を付け、下記式を立て、
Ｎ＊（Ｂ−Ｂｓｐｃ）−Ｒｓｕｍ≧Ｒｎｅｗ…（式３）
上記（式３）を満足する場合、保存しようとするレコードが存在すると判断し、
前記レコード削除部は、上記（式３）を満足せず、すべてのブロックが容量満杯と判断した時に、下記式を立て、
Ｎ＊（Ｂ−Ｂｓｐｃ）−Ｒｓｕｍ＋Ｒｄｅｌ≧Ｒｎｅｗ…（式４）
上記（式４）を満足する候補を選択し、選択後に、選択したデータを削除した上で新規レコードが保存可能か否かを、前記レコード保存可否判断部に対して上記（式３）を用いて、判断させる。
【発明の効果】
【００３２】
以上説明したように、本発明によれば、ブロックの最大個数Ｎ、ブロックサイズＢ、レコードの最大サイズの次に大きいサイズＲｍａｘ−１、保存済みレコードの合計Ｒｓｕｍ、これから保存しようとするレコードのサイズＲｎｅｗとし、下記式を立て、
Ｎ＊（Ｂ−（Ｒｍａｘ−１））−Ｒｓｕｍ≧Ｒｎｅｗ…（式１）
上記（式１）を満足する場合、保存しようとするレコードが存在すると判断し、上記（式１）を満足せず、すべてのブロックが容量満杯と判断した時に、削除するレコードの候補のサイズの合計Ｒｄｅｌとし、下記式を立て、
Ｎ＊（Ｂ−（Ｒｍａｘ−１））−Ｒｓｕｍ＋Ｒｄｅｌ≧Ｒｎｅｗ…（式２）
上記（式２）を満足する候補を選択し、選択後に、選択したデータを削除した上で新規レコードが保存可能か否かを、上記（式１）を用いて、判断させるようにしたので、ブロックに新規レコードを保存する前にそのレコードの保存可否が判断され、ブロックの空き領域が足りなくても、新規レコードが保存できない場合に、そのレコードを保存するために削除するレコードを選択することが可能になる。
【００３３】
新規レコードのサイズがブロックのサイズよりも大きくても分割することにより同様の作用効果を得ることが可能になる。
大規模な情報処理を行うサーバー、大量のデータを扱う携帯端末に利用可能である。
【発明を実施するための最良の形態】
【００３４】
以下、本発明の実施の形態について図面を参照して説明する。
図１は本発明に係るデータベースのサイズ管理システムの概略構成を示すブロック図である。本図に示すように、１つの情報処理装置１００ではデータベース管理システム（ＤＢＭＳ）１０１が稼働し、複数の情報処理装置４００ではデータベース（ＤＢ）クライアントのアプリケーション４０１がそれぞれ稼働している。情報処理装置１００と複数の情報処理装置４００とはネットワーク３００を介して接続され、本発明に係るデータベースのサイズ管理システムは１つの情報処理装置１００と複数の情報処理装置４００の間でブロック単位で管理するデータベースのサイズを管理するプログラムで構成される。
【００３５】
ここで、データベース管理システム１０１はデータ保存・読込み手段１０２を介して記憶装置２０に保存されているデータベース（ＤＢ）２０１へアクセスする。なお、この例では、１つの情報処理装置１００のデータベース管理システム１０１は大規模な情報処理を行うサーバーに向けたものであり、複数の情報処理装置の各々は１つの情報処理装置のデータベース管理システムに対してデータの保存要求を行う。
データをレコードとしてブッロク単位で保存するデータベース２０１に一度読み込まれたＤＢデータはバッファ１０３にキャッシュされる。
【００３６】
データベース管理システム１０１は、通信手段１０４を介して、ネットワーク３００上のアプリケーション４０１と通信する。
アプリケーション４０１は、上記の経路を介して、データベース管理システム１０１へ要求を送信し、データベース管理システム１０１は要求に応じた処理を行い、応答を返す。
【００３７】
また、アプリケーション４０１は、ブロックへのレコードの保存可否判断手段を内包する。
図２は図１における情報処理装置４００のアプリケーション４０１の概略構成を示すブロック図である。本図に示すように、情報処理装置４００のアプリケーション４０１にはレコード保存可否判断部４０１Ａ、レコード削除部４０１Ｂが設けられる。
【００３８】
レコード保存可否判断部４０１Ａはブロックのサイズとレコードのサイズを基にブロックへの最低限保存可能なレコードのサイズを算出することで保存前に保存されるべきレコードのサイズの判断を行う。
レコード削除部４０１Ｂはすべてのブロックが容量満杯である時に新規データを保存する場合にどのレコードを削除すべきかの選択を行う。
【００３９】
図３は図１におけるアプリケーション４０１の動作を説明する概略ＤＢデータ構造図である。従来技術で述べたように、レコードの最大サイズＲｍａｘがブロックのサイズＢより小さく、複数のブロックに分割できない場合には空き領域が問題となる。
本図に示すように、レコードの最大サイズをＲｍａｘ、次に大きいサイズをＲｍａｘ−１とすると、使用できない空き領域が一番大きくなるケースは、すべてのブロックの空き領域のサイズがＲｍａｘ−１の時に、最大サイズＲｍａｘのレコードを保存しようとする場合である。このとき、ブロックの利用率Ｂｐｃｔは、以下のようになる。
【００４０】
Ｂｐｃｔ＝（Ｂ−（Ｒｍａｘ−１））／Ｂ
ブロックの最大個数をＮとすると、データベース２０１のＤＢデータのサイズは、Ｎ＊Ｂとなる。この場合、最低限保存可能なレコードのサイズは、Ｎ＊Ｂ＊Ｂｐｃｔとなる。
保存済みレコードの合計をＲｓｕｍ、これから保存しようとするレコードのサイズをＲｎｅｗとし、下記式を立て、下記式が成立する場合、サイズＲｎｅｗのレコードが保存可能と判断できる。
【００４１】
Ｎ＊Ｂ＊Ｂｐｃｔ−Ｒｓｕｍ≧Ｒｎｅｗ…（式１）
アプリケーション４０１のレコード保存可否判断部４０１Ａでは、上記（式１）が成立するときにサイズＲｎｅｗのレコードが保存可能と判断する。
なお、Ｒｓｕｍを高速に求めるために、各レコードのヘッダには、自分自身のサイズＲｔを保持し、判断の際にＳＱＬ（Ｓｔｒｕｃｔｕｒｅｄ  Ｑｕｅｒｙ  Ｌａｎｇｕａｇｅ）でＲｓｕｍを算出する。ただし、サイズＲｍａｘ、Ｒｎｅｗ、Ｒｔは、レコードに付与される管理用ヘッダのサイズも含むこととする。
【００４２】
ここで、上記式（１）を満足しない場合には、すべてのブロックは容量満杯とする。
レコード保存可否判断部４０１Ａが上記式（１）を満足せずと判断し、すべてのブロックが容量満杯である場合には、アプリケーション４０１のレコード削除部４０１Ｂでは、サイズＲｎｅｗのレコードをブロックに保存するためにブロックから削除するレコードの候補を選出する際には、削除するレコードの候補のサイズの合計をＲｄｅｌとし、下記式を立て、下記の式が成立するようなサイズの合計がＲｄｅｌとなる候補を選択する。
【００４３】
Ｎ＊Ｂ＊Ｂｐｃｔ−Ｒｓｕｍ＋Ｒｄｅｌ≧Ｒｎｅｗ…（式２）
図４は図１における情報処理装置４００のアプリケーション４０１の一連の動作を説明するフローチャートである。ステップＳ５０１において、新規に保存しようとするレコードがデータベース２０１におけるＤＢデータのブロックに保存可能か否かを判断する。判断の方法は上記（式１）による。保存不可ですべてのブロックが容量満杯の場合にはステップ５０３に進む。
【００４４】
ステップＳ５０２において、保存可能な場合には、ベースデータ管理システム１０１にレコードの保存を要求する。要求が完了すれば、処理を終了する。
ステップＳ５０３において、ユーザが処理をキャンセルしたか否かを判断する。キャンセルの場合には処理を終了する。ユーザが保存を求めない場合を考慮したためである。
ステップＳ５０４において、キャンセルしない場合には、アプリケーション４０１又はユーザが削除レコードを選択する。ユーザが選択する場合には複数の選択を可能とし、選択を追加するたびに上記（式２）で判断を行い、現在の選択で新規レコードが保存可能か否かを画面上でユーザに通知する。アプリケーション４０１が自動で選択する場合も、上記(式２）を用いて、たとえば、古いレコードの順にという条件で、新規レコードが保存可能となる解除レコードを選択する。
【００４５】
ステップＳ５０５において、選択後に、選択したデータを削除した上で新規レコードが保存可能か否かを、（式１）を用いて、判断する。保存可能でない場合にはステップ５０３に戻り、削除レコードの選択をやり直す。
ステップＳ５０６において、保存可能な場合には、選択したレコードの削除をデータベース管理システム１０１に要求する。
【００４６】
ステップＳ５０７において、新規レコードの保存をデータベース管理システム１０１に要求する。要求が完了すれば、処理を終了する。
図５は図１における情報処理装置１００のデータベース管理システム１０１の一連の動作を説明するフローチャートである。本図に示すように、ステップＳ５１１において、情報処理装置４００のアプリケーション４０１からの要求を取得する。
ステップＳ５１２において、取得した要求を解析し、解析結果に応じた処理へ分岐を行う。
ステップＳ５１３において、レコードの登録処理を行う。新規レコードをバッファ１０３へ登録し、データベース２０１へも反映する。
【００４７】
ステップＳ５１４において、レコードの読み込み処理を行う。読み込み要求されたレコードを含むブロックがバッファ１０３にキャッシュされているかを知らべ、キャッシュされている場合は該当するレコードをバッファ１０３から読み出し、通信手段１０４を介してアプリケーション４０１へ読み出したレコードを送付する。
ステップＳ５１５において、レコードの削除処理を行う。削除を要求されたレコードをバッファ１０３及びデータベース２０１から削除する。
ステップＳ５１６において、ステップＳ５１３−Ｓ５１５で行った処理の結果をアプリケーション４０１ｈ返送し、ステップＳ５１１に戻る。
【００４８】
したがって、本発明によれば、ブロックに新規レコードを保存する前にそのレコードの保存可否が判断される。
さらに、ブロックの空き領域が足りなくても、新規レコードが保存できない場合に、そのレコードを保存するために削除するレコードを選択することが可能になる。
【実施例１】
【００４９】
前述の説明では、レコードが複数のブロックにまたがることができないことを前提としたが、レコードがブロックにまたがることができる場合について説明を行う。
レコードのサイズが大きくレコードが複数のブロックにまたがる場合にはレコードが複数に分割され、分割されたレコードには管理用ヘッダが付与される。
使用する空き領域の個数によりヘッダの割合が変化し、空き領域のサイズの合計だけでは保存可能か否かを判断できない。
【００５０】
各ブロックに小さな空き領域が点在している状態でサイズが大きいレコードを保存しようとすると、複数のブロックに分割して保存されるが、空き領域が極端に小さい場合にレコードの断片をその空き領域に保存すると、実レコードよりも管理用ヘッダの割合が大きくなり、非常に保存の効率が下がる。
図６は図１におけるアプリケーション４０１の動作を説明する別の概略ＤＢデータ構造図である。本図に示すように、保存の効率を下げないようにするため、空き領域が一定のサイズ（Ｂｓｐｃ）以上でないと、保存しないという条件を付ける。そのとき、分割されるレコードの最小の断片のサイズはＢｓｐｃである。分割ヘッダのサイズをＨとすると、レコードが分割される際にヘッダにより膨張する率Ｒｅｘｐは下記のようになる。
【００５１】
Ｒｅｘｐ＝Ｂｓｐｃ／（Ｂｓｐｃ−Ｈ）
また、空き領域がＢｓｐｃより小さい場合は、その領域は使用されない。このため、利用可能な領域は１ブロック辺りＢ−Ｂｓｐｃとなる。ブロックの最大個数をＮとすると、最低限保存可能な実レコードのサイズは、Ｎ＊（Ｂ−Ｂｓｐｃ）となる。保存済みレコードの合計をＲｓｕｍ、これから保存しようとするレコードのサイズをＲｎｅｗとし、下記式を立て、下記式が成立する場合、サイズＲｎｅｗのレコードが保存可能と判断できる。
【００５２】
Ｎ＊（Ｂ−Ｂｓｐｃ）−Ｒｓｕｍ≧Ｒｎｅｗ…（式３）
アプリケーション４０１のレコード保存可否判断部４０１Ａでは、上記（式３）が成立するときにサイズＲｎｅｗのレコードが保存可能と判断する。
レコード保存可否判断部４０１Ａが上記式（１）を満足せずと判断し、すべてのブロックが容量満杯である場合には、アプリケーション４０１のレコード削除部４０１Ｂでは、サイズＲｎｅｗのレコードをブロックに保存するためにブロックから削除するレコードの候補を選出する際には、削除するレコードの候補のサイズの合計をＲｄｅｌとし、下記式を立て、下記の式が成立するようなサイズの合計がＲｄｅｌとなる候補を選択する。
Ｎ＊（Ｂ−Ｂｓｐｃ）−Ｒｓｕｍ＋Ｒｄｅｌ≧Ｒｎｅｗ…（式４）
【実施例２】
【００５３】
以上の説明では、情報処理装置１００のアプリケーション４０１にレコード保存可否判断部４０１Ａ、レコード削除部４０１Ｂを内包していたが、情報処理装置４００のデータベース管理システム１０１にレコード保存可否判断部４０１Ａ、レコード削除部４０１Ｂを内包するようにしてもよい。これにより、情報処理装置１００単独でブロックに保存するレコードのサイズ管理が可能になるので、携帯端末などにデータベース管理システム１０１が取り込まれた場合には携帯端末に本発明のデータベースのサイズ管理システムの適用が可能になる。
【実施例３】
【００５４】
さらに、リレーション型のデータベースに対しては、１つのデータがテーブルの正規化等により複数のテーブルに分割されている場合がある。この場合、それぞれのテーブルに対してサイズの判断として上記(式１）又は上記（式３）を用いることが可能である。どれか１つでも保存不可のテーブルがあるとデータの保存ができないため、すべてのテーブルで条件が成立するときに保存可能と判断される。
さらに、すべてのテーブルが容量満杯の場合には、テーブルに保存されるデータを削除して新規のデータを保存する判断として上記(式２）又は上記（式４）を用いることが可能である。
【産業上の利用可能性】
【００５５】
以上、情報処理装置、携帯端末について説明を行ったが、これに限らず、携帯電話、携帯情報端末（ＰＤＡ）など、小型で記憶領域のサイズに制約があり、大量の情報を扱うことができる情報端末での利用が可能である。また、携帯端末にも限定されず、データベース全般にて、論理的にサイズ管理を行う方法として有効である。
【図面の簡単な説明】
【００５６】
【図１】本発明に係るデータベースのサイズ管理システムの概略構成を示すブロック図である。
【図２】図１における情報処理装置４００のアプリケーション４０１の概略構成を示すブロック図である。
【図３】図１におけるアプリケーション４０１の動作を説明する概略ＤＢデータ構造図である。
【図４】図１における情報処理装置４００のアプリケーション４０１の一連の動作を説明するフローチャートである。
【図５】図１における情報処理装置１００のデータベース管理システム１０１の一連の動作を説明するフローチャートである。
【図６】図１におけるアプリケーション４０１の動作を説明する別の概略ＤＢデータ構造図である。
【図７】本発明の前提となるデータベースシステムにおけるデータの保存方法例を説明する概略データ構造図である。
【図８】本発明の前提となるデータベースシステムにおけるデータの他の保存方法例を説明する概略データ構造図である。
【符号の説明】
【００５７】
１００、４００…情報処理装置
１０１…データベース管理システム
１０２…データ保存・読込み手段
１０３…バッファ
１０４…通信手段
２００…記憶装置
２０１…データベース
３００…ネットワーク
４０１…アプリケーション
４０１Ａ…レコード保存可否判断部
４０１Ｂ…レコード削除部
【図１】
2009080575.tif 000003
【図２】
2009080575.tif 000004
【図３】
2009080575.tif 000005
【図４】
2009080575.tif 000006
【図５】
2009080575.tif 000007
【図６】
2009080575.tif 000008
【図７】
2009080575.tif 000009
【図８】
2009080575.tif 000010