(57)【要約】【課題】データベース処理要求を実行する際に不要なインデクスの作成を回避し、記憶媒体の効率的な使用を実現することが可能な技術を提供する。【解決手段】データベースを管理するデータベース管理方法において、受け付けたデータベース処理要求を解析してアクセス手順情報を生成するステップと、一時表の物理実体が生成済みかどうかを判定し、一時表の物理実体が未生成である場合にその物理実体を生成するステップと、一時表のインデクスが生成済みかどうかを判定し、一時表のインデクスが未生成である場合にそのインデクスの物理実体を生成するステップと、前記受け付けたデータベース処理要求を前記物理実体の生成された一時表を用いて実行するステップとを有するものである。【選択図】        図１
2005018102.tif 000002
【特許請求の範囲】
【請求項１】
データベースを管理するデータベース管理方法において、
受け付けたデータベース処理要求を解析してアクセス手順情報を生成するステップと、一時表の物理実体が生成済みかどうかを判定し、一時表の物理実体が未生成である場合にその物理実体を生成するステップと、一時表のインデクスが生成済みかどうかを判定し、一時表のインデクスが未生成である場合にそのインデクスの物理実体を生成するステップと、前記受け付けたデータベース処理要求を前記物理実体の生成された一時表を用いて実行するステップとを有することを特徴とするデータベース管理方法。
【請求項２】
前記物理実体へのアクセスを行う際に当該物理実体を生成することを特徴とする請求項１に記載されたデータベース管理方法。
【請求項３】
前記物理実体へのアクセス終了後に当該物理実体を削除することを特徴とする請求項１または請求項２のいずれかに記載されたデータベース管理方法。
【請求項４】
データベースを管理するデータベース管理装置において、
受け付けたデータベース処理要求を解析してアクセス手順情報を生成するデータベース処理要求解析部と、一時表またはそのインデクスの物理実体が生成済みかどうかを判定し、一時表またはそのインデクスの物理実体が未生成である場合にその一時表またはインデクスの物理実体の生成を指示する一時表管理部と、前記指示により一時表またはインデクスの物理実体を生成するデータベース操作部と、前記受け付けたデータベース処理要求を前記物理実体の生成された一時表を用いて実行するデータベース処理実行部とを備えることを特徴とするデータベース管理装置。
【請求項５】
データベースを管理するデータベース管理装置としてコンピュータを機能させる為のプログラムにおいて、
受け付けたデータベース処理要求を解析してアクセス手順情報を生成するデータベース処理要求解析部と、一時表またはそのインデクスの物理実体が生成済みかどうかを判定し、一時表またはそのインデクスの物理実体が未生成である場合にその一時表またはインデクスの物理実体の生成を指示する一時表管理部と、前記指示により一時表またはインデクスの物理実体を生成するデータベース操作部と、前記受け付けたデータベース処理要求を前記物理実体の生成された一時表を用いて実行するデータベース処理実行部としてコンピュータを機能させることを特徴とするプログラム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明はデータベースを管理するデータベース管理装置に関し、特にデータベース処理における一時表を管理するデータベース管理装置に適用して有効な技術に関するものである。
【０００２】
【従来の技術】
データベースとは、コンピュータ内に保存した情報であり、データベース管理システムとは、データベースを保持・操作する為の機能を備えた情報システムである。
【０００３】
例えば、データベース管理システムの一種であるリレーショナルデータベース管理システム（Ｒｅｌａｔｉｏｎａｌ  ＤａｔａＢａｓｅ  Ｍａｎａｇｅｍｅｎｔ  Ｓｙｓｔｅｍ以下ＲＤＢＭＳと略す）は、データベースを行及び列から構成される表として表現する。データベースは、通常、複数の物理的な表から構成され、表の定義や操作はリレーショナルデータベース独特の問合せ言語により行われる。問合せ言語の代表であるＳＱＬ（Ｓｔｒｕｃｔｕｒｅｄ  Ｑｕｅｒｙ  Ｌａｎｇｕａｇｅ）は、ＩＳＯ（Ｉｎｔｅｒｎａｔｉｏｎａｌ  Ｓｔａｎｄａｒｄｉｚａｔｉｏｎ  Ｏｒｇａｎｉｚａｔｉｏｎ）において規格化されており、規格中で定められている一時表という機能は、現在、多くのＲＤＢＭＳでサポートされている。
【０００４】
通常の表の内容は、明示的にデータを削除しない限り永続的に保存される（これを永続実表と呼ぶ）。一方、一時表のデータには有効期限が存在し、この有効期限は一時表定義時に表の属性としてＳＱＬ中に指定されている。
【０００５】
一時表の物理実体は、データベースのセション（データベース使用者がＲＤＢＭＳに接続してから切り離すまでの期間）内で、最初に一時表を操作する時点で作成され、有効期限（接続終了時またはトランザクション終了時）に達した時点でＲＤＢＭＳにより自動的に削除される（例えば非特許文献１参照）。
【０００６】
また、一時表の物理実体には、そのセション内で挿入したデータのみが格納され、他の接続者が挿入したデータを参照することはできない。つまり、一時表は各セション単位に個別の物理実体を持つ、セション毎に独立した表であると捉えることができる。
【０００７】
【非特許文献１】
Ｃ．Ｊ．ＤＡＴＥ，  Ｈｕｇｈ  Ｄａｒｗｅｎ著，  ＱＵＩＰＵ  ＬＬＣ訳「標準ＳＱＬガイド改訂第４版」株式会社アスキー，  ｐｐ．２７９−２８２（第１８章  一時テーブルの項）
【０００８】
【発明が解決しようとする課題】
一時表に関し、従来技術には以下の問題があった。
データベースの検索を高速化する為に、インデクスを定義することが行われている。このインデクスは２次的なデータであり、一般に、一表に対して複数個定義できる。また一時表の列に対してインデクスを定義することも可能である。
【０００９】
一時表のインデクスは、表の物理実体と同じく、各セション毎に個別に作成されるが、従来技術では、一時表のインデクスの物理実体の効率的な管理方法が考慮されていない為、セション内で使用しないインデクスであってもディクショナリ情報に従って物理実体を作成してしまい、記憶媒体を無駄に消費してしまうという問題があった。
【００１０】
本発明の目的は上記問題を解決し、データベース処理要求を実行する際に不要なインデクスの作成を回避し、記憶媒体の効率的な使用を実現することが可能な技術を提供することにある。本発明の他の目的はデータベース処理に必要な記録媒体の使用量を節減することが可能な技術を提供することにある。
【００１１】
【課題を解決するための手段】
本発明は、データベースを管理するデータベース管理装置において、一時表のインデクスが未生成である場合にそのインデクスの物理実体を生成してデータベース処理要求を実行するものである。
【００１２】
本発明では、データベース処理装置（計算機や情報処理装置、またはその様な処理を実施するプログラムやオブジェクトでも良い）でデータベース処理要求を受け付けると、その受け付けたデータベース処理要求を解析してアクセス手順情報を生成した後、その生成したアクセス手順情報に従ってデータベース処理を実行する。
【００１３】
すなわち、前記生成したアクセス手順情報からアクセス手順を順次取り出し、そのアクセス手順が一時表を用いるものである場合には、当該アクセス手順で用いられる一時表の物理実体が生成済みかどうかを判定し、一時表の物理実体が未生成である場合にはその物理実体を生成する。
【００１４】
また前記取り出したアクセス手順が一時表のインデクスを用いるものである場合には、当該アクセス手順で用いられる一時表のインデクスが生成済みかどうかを判定し、一時表のインデクスが未生成である場合にそのインデクスの物理実体を生成する。
【００１５】
そして前記物理実体の生成された一時表やそのインデクスを用いて前記アクセス手順を実行することにより、前記受け付けたデータベース処理要求の処理を行う。
【００１６】
前記の様に本発明では、一時表のインデクスの物理実体を、そのインデクスへのアクセスを行う直前に作成しており、これにより、そのデータベース処理で使用されない不要なインデクスの作成を回避して記憶媒体の使用量を節減し、インデクス作成及び更新に必要な処理負荷を低減することができる。
【００１７】
以上の様に本発明のデータベース管理装置によれば、一時表のインデクスが未生成である場合にそのインデクスの物理実体を生成してデータベース処理要求を実行するので、データベース処理要求を実行する際に不要なインデクスの作成を回避し、記憶媒体の効率的な使用を実現することが可能である。
【００１８】
【発明の実施の形態】
（実施形態１）
以下に一時表のインデクスの物理実体をアクセスする直前に作成し、使用しないインデクスの作成を回避して記憶媒体の使用量を節減する実施形態１のデータベース管理装置について説明する。
【００１９】
図１は本実施形態のＲＤＢＭＳの概略構成を示す図である。図１に示す様に本実施形態のデータベース管理装置は、ＲＤＢＭＳ１０２と、ＳＱＬ解析部１０３と、ディクショナリ管理部１０４と、ＳＱＬ実行部１０５と、データベース操作部１０６と、一時表管理部１０７とを有している。
【００２０】
ＲＤＢＭＳ１０２は、ＳＱＬ解析部１０３、ディクショナリ管理部１０４、ＳＱＬ実行部１０５、データベース操作部１０６及び一時表管理部１０７の動作を制御してデータベース処理全体を管理する処理部である。
【００２１】
ＳＱＬ解析部１０３は、アプリケーションプログラム１０１から受け付けたデータベース処理要求を解析してアクセス手順情報を生成するデータベース処理要求解析部である。ディクショナリ管理部１０４は、表及びインデクスの属性を登録するディクショナリ情報１０８を管理する処理部である。
【００２２】
ＳＱＬ実行部１０５は、前記受け付けたデータベース処理要求を物理実体の生成された一時表を用いて実行するデータベース処理実行部である。データベース操作部１０６は、一時表管理部１０７からの指示により一時表またはインデクスの物理実体を生成する処理部である。
【００２３】
一時表管理部１０７は、一時表またはそのインデクスの物理実体が生成済みかどうかを判定し、一時表またはそのインデクスの物理実体が未生成である場合にその一時表またはインデクスの物理実体の生成を指示する処理部である。
【００２４】
データベース管理装置をＲＤＢＭＳ１０２、ＳＱＬ解析部１０３、ディクショナリ管理部１０４、ＳＱＬ実行部１０５、データベース操作部１０６及び一時表管理部１０７として機能させる為のプログラムは、ＣＤ−ＲＯＭ等の記録媒体に記録され磁気ディスク等に格納された後、メモリにロードされて実行されるものとする。なお前記プログラムを記録する記録媒体はＣＤ−ＲＯＭ以外の他の記録媒体でも良い。また前記プログラムを当該記録媒体から情報処理装置にインストールして使用しても良いし、ネットワークを通じて当該記録媒体にアクセスして前記プログラムを使用するものとしても良い。
【００２５】
図１に示す様に本実施形態のデータベース管理装置は、アプリケーションプログラム１０１からのデータベース処理要求を受け付けてデータベース処理を行うＲＤＢＭＳ１０２と、表及びインデクスの属性を登録するディクショナリ情報１０８と、一時表及び一時表のインデクスの物理実体１０９から成っており、ＲＤＢＭＳ１０２は、更に、ＳＱＬ解析部１０３、ＳＱＬ実行部１０５、ディクショナリ管理部１０４、データベース操作部１０６、一時表管理部１０７から成っている。
【００２６】
図２は本実施形態のＲＤＢＭＳ１０２がアプリケーションプログラム１０１から一時表を操作するＳＱＬを受け付けてから実行するまでの処理手順を示すフローチャートである。アプリケーションプログラム１０１は、データベース処理要求に応じたＳＱＬをＲＤＢＭＳ１０２へ送信し、そのデータベース処理の実行をＲＤＢＭＳ１０２に要求する。
【００２７】
ステップ２０１でＲＤＢＭＳ１０２は、アプリケーションプログラム１０１からＳＱＬが送信されているかどうかを調べ、ＳＱＬが送信されている場合にはそのＳＱＬを受け付けて、データベース管理装置のメモリ上に一時的に保持する。
【００２８】
ステップ２０２でＳＱＬ解析部１０３は、前記メモリ上に保持したＳＱＬの内容を解析して、そのデータベース処理で一時表が用られるかどうかや、一時表が用いられる場合にはその一時表でインデクスが用いられるかどうかを最適化処理も考慮して判定する行い、そのＳＱＬの処理を実行する為のアクセス手順を示すアクセス手順情報を生成する。
【００２９】
その後、前記生成したアクセス手順情報からアクセス手順を順次取り出し、そのアクセス手順が一時表へのアクセスを行うものである場合に、ステップ２０３で一時表管理部１０７は、そのアクセス対象の一時表の物理実体がメモリ上に生成されているかどうかを調べることにより、一時表の物理実体が生成済みかどうかを判定し、未生成である場合にはステップ２０４へ進み、データベース操作部１０６をコールしてその一時表の物理実体を生成する。
【００３０】
同様に、前記取り出したアクセス手順が一時表のインデクスを用いた検索を行うものである場合に、その一時表の検索に使用するインデクスの物理実体がメモリ上に生成されているかどうかを調べることにより、一時表のインデクスの物理実体が生成済みであるかどうかを判定し、未生成である場合にはステップ２０６へ進み、データベース操作部１０６をコールしてインデクスの物理実体を生成する。
【００３１】
その後、ステップ２０７では、一時表管理部１０７からＳＱＬ実行部１０５へ制御を渡し、前記取り出したアクセス手順のＳＱＬ実行処理をＳＱＬ実行部１０５により行う。
【００３２】
次に、本実施形態のデータベース管理装置において、一時表の社員番号インデクスを用いるアプリケーションプログラムＡの処理と、一時表の名前インデクスを用いるアプリケーションプログラムＢの処理とを行う場合に生成される一時表のインデクスの物理実体の違いについて説明する。
【００３３】
図３は本実施形態のアプリケーションプログラムＡから発行されるＳＱＬの処理手順を示すフローチャートである。図３では、ＲＤＢＭＳ１０２への接続（３０１）、一時表に対する行の挿入（３０２）、一時表の検索（３０３）、ＲＤＢＭＳ１０２からの切り離し（３０４）が、この順序で行われることを表している。
【００３４】
図４は本実施形態のアプリケーションプログラムＢから発行されるＳＱＬの処理手順を示すフローチャートである。図４の処理内容は検索ＳＱＬ（４０３）の条件部分を除いて図３と同様である。
【００３５】
また、前提として、以下の（ａ）（ｂ）（ｃ）のＳＱＬにより一時表及び一時表のインデクスが定義されているものとする。（ａ）は、６列から構成される部門社員表という一時表を定義しており、部門社員表のデータの有効期限がトランザクション終了時であることを意味している。（ｂ）（ｃ）は、部門社員表の社員番号列、名前列にそれぞれインデクスを定義することを意味している。また、（ｄ）により、永続実表の「社員表」が定義されているものとする。社員表は部門社員表と同じ列構成を持つ。
【００３６】
（ａ）ＣＲＥＡＴＥ  ＧＬＯＢＡＬ  ＴＥＭＰＯＲＡＲＹ  ＴＡＢＬＥ  部門社員表
（社員番号  ＣＨＡＲ（１０），
名前  ＮＣＨＡＲ（３０），
給与  ＤＥＣＩＭＡＬ（１０），
生年月日  ＤＡＴＥ，
入社年度  ＤＥＣＩＭＡＬ（４），
所属部門  ＮＣＨＡＲ（１０））
ＯＮ  ＣＯＭＭＩＴ  ＤＥＬＥＴＥ  ＲＯＷＳ
（ｂ）ＣＲＥＡＴＥ  ＩＮＤＥＸ  社員番号インデクス  ＯＮ  部門社員表（社員番号）
（ｃ）ＣＲＥＡＴＥ  ＩＮＤＥＸ  名前インデクス  ＯＮ  部門社員表（名前）
（ｄ）ＣＲＥＡＴＥ  ＴＡＢＬＥ  社員表
（社員番号  ＣＨＡＲ（１０），
名前  ＮＣＨＡＲ（３０），
給与  ＤＥＣＩＭＡＬ（１０），
生年月日  ＤＡＴＥ，
入社年度  ＤＥＣＩＭＡＬ（４），
所属部門  ＮＣＨＡＲ（３０））
（ａ）（ｂ）（ｃ）（ｄ）を実行した結果、ディクショナリ情報１０８に表及びインデクスの属性が登録される。
【００３７】
では、図３のアプリケーションプログラムＡからのＳＱＬの実行時の処理の流れを説明する。まず、従来技術と同じくデータベースへの接続（３０１）を実行する。
【００３８】
次にＩＮＳＥＲＴ文（３０２）により、社員表から抽出した行群を部門社員表に挿入する。このとき、ステップ２０３の判定により、部門社員表の物理実体を作成する。ＩＮＳＥＲＴ文ではインデクスを使用しない為、次のステップ２０５の判定では、インデクスの物理実体は作成されない。
【００３９】
次にＳＥＬＥＣＴ文（３０３）が実行される。ここで、検索時には社員番号インデクスが使用されるものと仮定する（使用するインデクスの決定はＳＱＬの最適化方法により異なるが、インデクスの決定方法と本発明は直接関係しないため、このように仮定しても差し支えない）。使用するインデクスの情報は、ＳＱＬ解析部１０３によりＳＱＬを解析した結果出力されるアクセス手順情報に格納される。
【００４０】
一時表管理部１０７は、ステップ２０３の判定により、部門社員表の物理実体が作成済みか否かを判定するが、ＩＮＳＥＲＴ文（３０２）実行時に既に作成されている為、ＮＯの分岐を選択する。
【００４１】
また、次のステップ２０５の判定で社員番号インデクスの物理実体が作成済みかどうか判定するが、この時点では、社員番号インデクスの物理実体は作成されていない為、ＹＥＳの分岐を選択し、社員番号インデクスの物理実体を作成する。
【００４２】
最後に、ＤＩＳＣＯＮＮＥＣＴ文（３０４）によりトランザクション及びセションが終了し、部門社員表及び社員番号インデクスの物理実体をＲＤＢＭＳ１０２により削除する。
【００４３】
一方、アプリケーションプログラムＢでは、ＳＥＬＥＣＴ文の実行時に名前インデクスが使用されるので、アプリケーションプログラムＡと同様の流れにより、名前インデクスの物理実体が作成され、社員番号インデクスの物理実体は作成されない。
【００４４】
すなわち、まずデータベースへの接続（４０１）を実行した後、ＩＮＳＥＲＴ文（４０２）により、社員表から抽出した行群を部門社員表に挿入する。このとき、ステップ２０３の判定により、部門社員表の物理実体を作成する。ＩＮＳＥＲＴ文ではインデクスを使用しない為、次のステップ２０５の判定では、インデクスの物理実体は作成されない。
【００４５】
次にＳＥＬＥＣＴ文（４０３）が実行される。ここで、検索時には名前インデクスが使用されるので、一時表管理部１０７は、ステップ２０３の判定により、部門社員表の物理実体が作成済みか否かを判定するが、ＩＮＳＥＲＴ文（４０２）実行時に既に作成されている為、ＮＯの分岐を選択する。
【００４６】
また、次のステップ２０５の判定で名前インデクスの物理実体が作成済みかどうか判定するが、この時点では、名前インデクスの物理実体は作成されていない為、ＹＥＳの分岐を選択し、名前インデクスの物理実体を作成する。
【００４７】
最後に、ＤＩＳＣＯＮＮＥＣＴ文（４０４）によりトランザクション及びセションが終了し、部門社員表及び名前インデクスの物理実体をＲＤＢＭＳ１０２により削除する。
【００４８】
この様に本実施形態のデータベース管理装置では、一時表の社員番号インデクスを用いるアプリケーションプログラムＡの処理の際には一時表の名前インデクスの物理実体は生成されず、また一時表の名前インデクスを用いるアプリケーションプログラムＢの処理の際には一時表の社員番号インデクスの物理実体は生成されない。
【００４９】
前記の様に本実施形態による一時表管理処理により、不要な一時表インデクスについては、物理実体が作成されなくなり、記憶媒体の容量節減やインデクスの作成負荷や更新負荷の低減が実現されていることが分かる。
【００５０】
以上説明した様に本実施形態のデータベース管理装置によれば、一時表のインデクスが未生成である場合にそのインデクスの物理実体を生成してデータベース処理要求を実行するので、データベース処理要求を実行する際に不要なインデクスの作成を回避し、記憶媒体の効率的な使用を実現することが可能である。
（実施形態２）
以下に一時表及び一時表のインデクスの物理実体を、定義上の有効期限前であっても、実質的に不要になった時点で削除する実施形態２のデータベース管理装置について説明する。
【００５１】
従来技術では、一時表及び一時表インデクスの物理実体を、表定義時に指定された有効期限に従い、セションまたはトランザクション終了時に削除する。しかし、定義時に指定された有効期限前であっても、実質的に不要となった時点で物理実体を削除すれば、記憶媒体のより効率的な活用が可能となる。
【００５２】
多くのＲＤＢＭＳでは、ＳＱＬによる一連のデータベース操作を手続きとして定義する機能を備えている。ＳＱＬ手続きは、定義時にＲＤＢＭＳにより解析され、解析結果は内部的なアクセス手順情報としてディクショナリに登録される。ＳＱＬ手続きを明示的に定義する場合の他、トリガやＳＱＬ関数の定義時にも、同様にアクセス手順情報が生成され、ディクショナリに登録される。ＳＱＬ手続きのアクセス手順情報を生成する場合は、ＲＤＢＭＳでＳＱＬの発行順序を解析することができる為、一時表及びインデクスの物理実体の削除指示を、アクセス手順情報中の最適な位置に埋め込むことが可能である。これにより物理実体をできるだけ早期に削除し、記憶媒体を効率的に活用することができる。
【００５３】
本実施形態では、実施形態１で説明した部門社員表及び社員表を操作するＳＱＬ手続きを例にとり、ＳＱＬ手続きのアクセス手順情報中に、部門社員表及びインデクスの物理実体削除指示情報を埋め込み、定義上の有効期限前に削除する例を説明する。
【００５４】
図５は本実施形態の実施形態１で説明した部門社員表及び社員表を操作するＳＱＬ手続きＡの内容を示す図である。図５に示す様にＳＱＬ手続きＡ（５０１）は、部門社員表に対する挿入ＳＱＬ（５０２）、社員番号インデクスを使用して部門社員表を検索するＳＱＬ（５０３）、名前インデクスを使用して部門社員表を検索するＳＱＬ（５０４）、社員表を検索するＳＱＬ（５０５）及びＣＯＭＭＩＴ文（５０６）から成り、これらのＳＱＬをこの順に実行する。
【００５５】
図６は本実施形態のＳＱＬ手続きＡ（５０１）を解析した結果のアクセス手順情報の内容を示す図である。図６に示す様にアクセス手順情報（６０１）は、図５に示した各ＳＱＬに対応するアクセス手順情報と、それらの実行順序を制御するアクセス手順制御情報（６０２）から成る。矢印は制御関係を示している。アクセス手順情報（６０３）は挿入ＳＱＬ（５０２）に、アクセス手順情報（６０４）は部門社員表の検索ＳＱＬ（５０３）に、アクセス手順情報（６０６）は部門社員表の検索ＳＱＬ（５０４）に、アクセス手順情報（６０８）は社員表の検索ＳＱＬ（５０５）、アクセス手順情報（６０９）はＣＯＭＭＩＴ文（５０６）に対応している。
【００５６】
本実施形態によるＳＱＬ手続き解析処理でＳＱＬ解析部１０３は、アクセス手順情報（６０１）中の、社員番号インデクスが最後に用いられるアクセス手順情報（６０４）の直後に、社員番号インデクスの物理実体を削除する為の社員番号インデクス削除指示情報（６０５）を埋め込み、また、部門社員表及び名前インデクスが最後に用いられるアクセス手順情報（６０６）の直後に、部門社員表及び名前インデクスの物理実体を削除する為の部門社員表削除指示情報（６０７）を埋め込む。これにより、ＳＱＬ手続きＡ実行時には、部門社員表の定義上の有効期限であるＣＯＭＭＩＴ（５０５）前に、部門社員表及びインデクスの物理実体が削除される。
【００５７】
従来技術では、ＣＯＭＭＩＴ（５０６）実行時まで、部門社員表及びインデクスの物理実体が存在していたが、本実施形態により、情報の保存期間がより短期となり、記憶媒体が有効に活用できるようになることが分かる。
【００５８】
前記の説明では、一時表やそのインデクスの物理実体が最後に用いられるアクセス手順情報の直後に、その物理実体を削除する為の指示情報を埋め込んでいるが、一時表の同一のインデクスへアクセスするアクセス手順情報が複数存在している場合には、各アクセス手順情報の直後にその物理実体を削除する為の指示情報を埋め込み、そのインデクスへのアクセスの直前に物理実体を生成し、アクセスの直後に削除する様にしても良い。
【００５９】
以上説明した様に本実施形態のデータベース管理装置によれば、物理実体へのアクセス終了後に当該物理実体を削除するので、データベース処理に必要な記録媒体の使用量を節減することが可能である。
【００６０】
【発明の効果】
本発明によれば一時表のインデクスが未生成である場合にそのインデクスの物理実体を生成してデータベース処理要求を実行するので、データベース処理要求を実行する際に不要なインデクスの作成を回避し、記憶媒体の効率的な使用を実現することが可能である。
【図面の簡単な説明】
【図１】実施形態１のＲＤＢＭＳの概略構成を示す図である。
【図２】実施形態１のＲＤＢＭＳ１０２がアプリケーションプログラム１０１から一時表を操作するＳＱＬを受け付けてから実行するまでの処理手順を示すフローチャートである。
【図３】実施形態１のアプリケーションプログラムＡから発行されるＳＱＬの処理手順を示すフローチャートである。
【図４】実施形態１のアプリケーションプログラムＢから発行されるＳＱＬの処理手順を示すフローチャートである。
【図５】実施形態２の実施形態１で説明した部門社員表及び社員表を操作するＳＱＬ手続きＡの内容を示す図である。
【図６】実施形態２のＳＱＬ手続きＡ（５０１）を解析した結果のアクセス手順情報の内容を示す図である。
【符号の説明】
１０１…アプリケーションプログラム、１０８…ディクショナリ情報、１０９…一時表及び一時表のインデクスの物理実体、１０２…ＲＤＢＭＳ、１０３…ＳＱＬ解析部、１０４…ディクショナリ管理部、１０５…ＳＱＬ実行部、１０６…データベース操作部、１０７…一時表管理部。
【図１】
2005018102.tif 000003
【図２】
2005018102.tif 000004
【図３】
2005018102.tif 000005
【図４】
2005018102.tif 000006
【図５】
2005018102.tif 000007
【図６】
2005018102.tif 000008