(57)【要約】【課題】インデックスデータの更新に利用する順序規則をアプリケーションが任意に指定でき、かつ、そのアプリケーションやデータベース管理装置を含むシステムに存在する全てのアプリケーションがこの順序規則を利用してデータベースの変更とインデックスデータの更新とを行えるようにする。【解決手段】任意のアプリケーション１１からのレコード追加要求に基づき、レコードデータ処理部１３３は、追加されたレコード型データをレコードデータ１３６に入力して記憶し、モジュールロード部１３２は、自立インデックスデータ１３７に記憶されているモジュールの識別名から、これに対応する装置外部に存在するモジュールの順序規則１２１を取得し、ソート・フィルタ処理部１３４は、取得された順序規則１２１に従ってレコード型データをソート及び／又はフィルタ処理し、その結果を自立インデックスデータ１３７に出力する。【選択図】　図１
2004110696.tif 000002
【特許請求の範囲】
【請求項１】
複数のレコード型データを記憶するとともにこれらデータのインデックスを管理するデータベース管理装置であって、
前記レコード型データを記憶する第１の記憶手段と、
装置外部に存在するモジュールの識別名及びこのモジュールの実行結果で得られたデータのインデックスを記憶する第２の記憶手段と、
装置外部のアプリケーションからのデータベース処理要求を受け付ける要求処理手段と、
前記第１の記憶手段に対してレコード型データの入出力を行うレコードデータ処理手段と、
前記第２の記憶手段に記憶されているモジュールの識別名から、これに対応する装置外部に存在するモジュールを取得するモジュールロード手段と、
取得されたモジュールによってレコード型データをソート及び／又はフィルタ処理し、その結果を前記第２の記憶手段に出力するソート・フィルタ手段とを備えており、
前記要求処理手段により任意のアプリケーションからのレコード追加要求が受け付けられると、前記レコードデータ処理手段は、追加されたレコード型データを前記第１の記憶手段に入力し、前記モジュールロード手段は、前記第２の記憶手段に記憶されているモジュールの識別名から、これに対応する装置外部に存在するモジュールを取得し、前記ソート・フィルタ手段は、取得されたモジュールによって前記第１の記憶手段に記憶されているレコード型データをソート及び／又はフィルタ処理し、その結果を前記第２の記憶手段に出力することを特徴とするデータベース管理装置。
【請求項２】
前記ソート・フィルタ手段は、取得されたモジュールに基づいて前記第２の記憶手段の記憶内容の更新が必要か否かを判定し、必要であると判断した場合に、ソート及び／又はフィルタ処理した結果を前記第２の記憶手段に出力することを特徴とする請求項１に記載のデータベース管理装置。
【請求項３】
複数のレコード型データを記憶するとともにこれらデータのインデックスを管理するデータベースの管理方法であって、
レコード型データを記憶する第１の記憶手段と、前記データに対してソート及び／又はフィルタ処理を実行するデータベース管理装置の外部に存在するモジュールの識別名及び該モジュールの実行結果で得られたデータのインデックスを記憶する第２の記憶手段とを用い、
任意のアプリケーションからのレコード追加要求に基づき、
前記第１の記憶手段の記憶内容の更新時に前記第２の記憶手段に記憶されたモジュールの識別名で示されるモジュールを外部から取得する段階と、
取得したモジュールに基づいて前記第２の記憶手段の記憶内容の更新が必要であるか否かを判定する段階と、
判定の結果、更新が必要であると判断した場合には、前記第１の記憶手段に記憶されているレコード型データをソート及び／又はフィルタ処理する段階と、
ソート及び／又はフィルタ処理の結果を前記第２の記憶手段の記憶内容として更新する段階とを備えたことを特徴とするデータベース管理方法。
【請求項４】
前記モジュールの識別名は前記データベースを所有するアプリケーションによるデータベースの作成時に記憶されることを特徴とする請求項３に記載のデータベース管理方法。
【請求項５】
複数のレコード型データを記憶するとともにこれらデータのインデックスを管理するコンピュータ読み取り可能なデータベース管理プログラムであって、
レコード型データを記憶する第１の記憶手段と、前記データに対してソート及び／又はフィルタ処理を実行するデータベース管理装置の外部に存在するモジュールの識別名及び該モジュールの実行結果で得られたデータのインデックスを記憶する第２の記憶手段とを用い、
任意のアプリケーションからのレコード追加要求に基づき、
前記第１の記憶手段の記憶内容の更新時に前記第２の記憶手段に記憶されたモジュールの識別名で示されるモジュールを外部から取得するステップと、
取得したモジュールに基づいて前記第２の記憶手段の記憶内容の更新が必要であるか否かを判定するステップと、
判定の結果、更新が必要であると判断した場合には、前記第１の記憶手段に記憶されているレコード型データをソート及び／又はフィルタ処理するステップと、
ソート及び／又はフィルタ処理の結果を前記第２の記憶手段の記憶内容として更新するステップとを備えたことを特徴とするデータベース管理プログラム。
【請求項６】
請求項５に記載のデータベース管理プログラムを記録したコンピュータ読み取り可能な記録媒体。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、携帯情報機器等の処理能力の低い情報処理システムにおいて、ソート・フィルタ結果を保持するレコード型データのデータベース管理装置、データベース管理方法、データベース管理プログラム及びデータベース管理プログラムを記録した記録媒体に関する。
【０００２】
【従来の技術】
住所録から名前順のリストを作る等、レコードを蓄積したデータベースから特定の順序でレコードを取り出すことは頻繁に行われている。そして、これを高速に行うために、予め特定の順序にソートした結果をインデックスとしてデータベースに保持する装置が提案されている（例えば、特許文献１参照）。
【０００３】
この装置によれば、入力部からレコードが入力されると、順序規則に従って並べられているインデックスデータも自動的に更新され、ソート処理が要求される際にはこのインデックスデータを使用して高速にレコードのソート処理を行うようになっている。順序規則としては、入力部から入力される順序規則定義用データにより、装置内に存在する複数の規則から選択したものをレコード内の任意のフィールドに関連付けたものが用いられる。また、この関連付けはインデックス番号メモリに複数記憶することができ、各関連付けに対応して複数のインデックスデータが作成されるため、実行処理に最も適したインデックスデータを使用してソート処理を高速に実行することができる。
【０００４】
この技術を用いて、アプリケーションプログラムにデータベース機能を提供するデータベース管理装置を構成すると、上記特許文献１の装置全体がデータベース管理装置となり、入力装置を介してアプリケーションプログラムからレコードや順序規則定義用データを入力する構成となる。
【０００５】
図９はこのようなデータベース管理装置を用いた電話システムの一例を示している。
【０００６】
データベース管理装置８３内に登録されている順序規則８３２は図１１に示す構成となっている。
【０００７】
ここでは、順序規則ＩＤ＝１として名前順の規則が定義されており、順序規則ＩＤ＝２として電話番号順の規則が定義されている。
【０００８】
データベース管理装置８３は、アプリケーションの要求に応じて、各順序規則に対応したインデックスデータを保持することができるが、図９では名前順の順序規則を用いた名前順インデックスデータ８３７のみが存在する場合を示している。
【０００９】
データベースで管理されるレコードデータ８３６には、図１０に示すように、名前がＣ、電話番号が１というレコードが、レコードＩＤ＝０として登録されており、以下同様に全部で３つのレコードが登録されている。
【００１０】
このレコードデータ８３６に対応する、名前でソートされた名前順インデックスデータ８３７には、図１２に示すように、順序規則としてＩＤ＝１を使用していること（すなわち、名前順であること）と、名前順にソートされたレコードＩＤとが登録されている。
【００１１】
順序の判定を行う順序規則８３２は、上記したようにデータベース管理装置８３内に登録されており、電話アプリケーション８１やアドレス帳アプリケーション８２の要求によりレコードの追加や削除が行われた場合でも、レコードデータ８３６と名前順インデックスデータ８３７との整合が保たれるように、データベース管理装置８３によって名前順インデックスデータ８３７が自動的に更新される。
【００１２】
例えば、アドレス帳アプリケーション８２が新しいレコードを要求処理部８３１に依頼すると、要求処理部８３１はレコードデータ処理部８３３に対してレコードデータ８３６への追加を要求する。
【００１３】
レコードデータ処理部８３３は未使用のレコードＩＤを生成し、新しいレコードに割当てて、レコードデータ８３６に登録する。
【００１４】
次に要求処理部８３１は、ソート・フィルタ処理部８３４にインデックスデータの更新を要求する。
【００１５】
ソート・フィルタ処理部８３４は、名前順インデックスデータ８３７に対応する名前順の順序規則を順序規則８３２から取り出し、これを用いてレコードデータ８３６をソートした結果を名前順インデックスデータ８３７に登録する。
【００１６】
【特許文献１】
特開平６−１８７２０８号公報
【００１７】
【発明が解決しようとする課題】
ところで、このような構成のデータベース管理装置８３では、順序規則８３２がデータベース管理装置８３内に予め記憶されているため、アプリケーションは、記憶されていない順序規則、例えばメールアドレス順にソートすることができないといった問題がある。また、予測可能な全順序規則を予め記憶しておくことも可能であるが、この場合、大半がほとんど利用されないと考えられるため、メモリ効率が悪くなるといった問題がある。
【００１８】
さらに、新たに追加されるアプリケーションが必要な順序規則を予測することは不可能なことから、このアプリケーションは希望する順序規則でソートすることができないといった問題もある。
【００１９】
一方で、アプリケーションが用意した任意の順序規則から、インデックスデータを作成する方法も従来より行われている。
【００２０】
図１３はこのようなデータベース管理装置を用いた電話システムの例である。
【００２１】
この電話システムの構成は、図９に示す装置とほぼ同じ構成であるが、違うところは、順序規則９２３がデータベース管理装置９３内ではなくアドレス帳アプリケーション９２に存在している点である。
【００２２】
この場合、アドレス帳アプリケーション９２は用意した任意の順序規則９２３からインデックスデータを作成することができる。
【００２３】
しかし、このようなシステムでは順序規則９２３を提供しているアドレス帳アプリケーション９２しか順序規則９２３を利用できないという問題がある。
【００２４】
一般に、各アプリケーションは各々プロセスとして動作し、各プロセスはそのプロセスに存在するモジュールしか利用できない。
【００２５】
図１４に示すように、（ａ）に示すアドレス帳アプリケーション１０１はプロセス内に順序規則１０２を持っているので、これを利用してデータベースへのレコードデータの追加等の変更に応じてインデックスデータの更新を行うことができるが、（ｂ）に示す電話アプリケーション１０３のプロセスには順序規則が存在しないため、インデックスデータを更新することができない。すなわち、データベースを参照することはできても、変更を行うことができない。
【００２６】
以上の問題点に鑑み、本発明ではインデックスデータの更新に利用する順序規則をアプリケーションが任意に指定でき、かつ、そのアプリケーションやデータベース管理装置を含むシステムに存在する全てのアプリケーションがこの順序規則を利用してデータベースの変更とインデックスデータの更新とを行えるようにしたデータベース管理装置、データベース管理方法、データベース管理プログラム及びデータベース管理プログラムを記録した記録媒体を提供することを目的としている。
【００２７】
【課題を解決するための手段】
本発明のデータベース管理装置は、レコード型データを記憶する第１の記憶手段と、装置外部に存在するモジュールの識別名及びこのモジュールの実行結果で得られたデータのインデックスを記憶する第２の記憶手段と、装置外部のアプリケーションからのデータベース処理要求を受け付ける要求処理手段と、前記第１の記憶手段に対してレコード型データの入出力を行うレコードデータ処理手段と、前記第２の記憶手段に記憶されているモジュールの識別名から、これに対応する装置外部に存在するモジュールを取得するモジュールロード手段と、取得されたモジュールによってレコード型データをソート及び／又はフィルタ処理し、その結果を前記第２の記憶手段に出力するソート・フィルタ手段とを備えており、前記要求処理手段により任意のアプリケーションからのレコード追加要求が受け付けられると、前記レコードデータ処理手段は、追加されたレコード型データを前記第１の記憶手段に入力し、前記モジュールロード手段は、前記第２の記憶手段に記憶されているモジュールの識別名から、これに対応する装置外部に存在するモジュールを取得し、前記ソート・フィルタ手段は、取得されたモジュールによって前記第１の記憶手段に記憶されているレコード型データをソート及び／又はフィルタ処理し、その結果を前記第２の記憶手段に出力することを特徴としている。また、本発明のデータベース管理方法は、任意のアプリケーションからのレコード追加要求に基づき、前記第１の記憶手段の記憶内容の更新時に前記第２の記憶手段に記憶されたモジュールの識別名で示されるモジュールを外部から取得する段階と、取得したモジュールに基づいて前記第２の記憶手段の記憶内容の更新が必要であるか否かを判定する段階と、判定の結果、更新が必要であると判断した場合には、前記第１の記憶手段に記憶されているレコード型データをソート及び／又はフィルタ処理する段階と、ソート及び／又はフィルタ処理の結果を前記第２の記憶手段の記憶内容として更新する段階とを備えたことを特徴としている。
【００２８】
本発明によれば、アプリケーションプログラムは、データベースを作成する際に、ソート・フィルタ条件を含むモジュールの識別名をデータベース管理装置に登録依頼する。
【００２９】
このモジュールはデータベース管理装置によって予め規定されたインターフェースを備えており、モジュールを提供するアプリケーションプログラムが動作していなくても、モジュールロード手段によってデータベース管理装置内に読み込むことで、データベース管理装置からソート・フィルタ条件を利用可能である。
【００３０】
そのため、他のアプリケーションプログラムによるレコードの変更の際に、データベース管理装置によって自動的にソート・フィルタ結果を保持するインデックスデータを更新することができる。
【００３１】
また、ソート・フィルタ条件はデータベース管理装置外部のアプリケーションプログラムが定義しているため、データベース管理装置を変更することなく、アプリケーションプログラムが提供する任意の条件が利用可能である。
【００３２】
なお、本発明のデータベース管理方法は、これを実行するデータベース管理プログラムとして実現することができる。また、このプログラムはコンピュータ読み取り可能な記録媒体に記録した状態で提供することができる。
【００３３】
【発明の実施の形態】
以下、本発明の実施の形態について、図面を参照して説明する。
【００３４】
図１は、本発明の一実施の形態であるデータベース管理装置を用いた電話システムの構成図である。
【００３５】
本実施の形態の電話システムは、大別すると、電話アプリケーション１１、アドレス帳アプリケーション１２、及びデータベース管理装置１３によって構成されており、データベース管理装置１３は、要求処理部１３１、モジュールロード部１３２、レコードデータ処理部１３３、ソート・フィルタ処理部１３４、レコードデータ１３６及び自立インデックスデータ１３７を格納したアドレス帳データベース１３５によって構成されている。すなわち、本実施の形態の電話システムは、図１３に示した従来の電話システムとほぼ同じ構成であり、違うところは、モジュールロード部１３２が追加されている点、及び自立インデックスデータ１３７の構成が名前順インデックスデータの構成と若干異なる点のみである。
【００３６】
すなわち、電話アプリケーション１１やアドレス帳アプリケーション１２は、データベース管理装置１３を介してアドレス帳データベース１３５にアクセスする。
【００３７】
アドレス帳アプリケーション１２は、アドレス帳データベース１３５の所有者であり、インデックスデータとして格納すべきレコードを抽出するフィルタ条件や、インデックスデータに格納されるレコード順序を決定するソート条件がプログラムされている順序規則１２１を持っている。
【００３８】
なお、アドレス帳データベース１３５にアクセスする他のアプリケーションが存在する場合も同様の構成であり、そのアプリケーションは、順序規則１２１を持たない電話アプリケーション１１と同じ位置付けとなる。
【００３９】
データベース管理装置１３は、データベースを管理するシステムであり、アプリケーションの要求に応じてレコードの追加や削除、内容変更等の編集処理を行い、同時に編集内容に応じて自立インデックスデータ１３７の更新も行う。
【００４０】
要求処理部１３１は、アプリケーションの要求を直接受け付け、結果をアプリケーションに返す。
【００４１】
レコード処理部１３３は、要求処理部１３１の制御によってレコードデータ１３６にアクセスし、レコードの入出力を行う。
【００４２】
モジュールロード部１３２は、要求処理部１３１の制御によってデータベース管理装置１３外部に存在する順序規則１２１を読み込む。
【００４３】
ソート・フィルタ処理部１３４は、モジュールロード部１３２によって読み込まれた順序規則を使用して、レコードデータ１３６に対してソート・フィルタ処理を行い、その結果を自立インデックスデータ１３７に記録する。
【００４４】
レコードデータ１３６は、レコードの集合である。１レコードには１個人の情報が記録されており、各レコードにはデータベース管理装置によってレコードＩＤが付与されている。
【００４５】
自立インデックスデータ１３７は、ソート・フィルタに関する情報を保持している。
【００４６】
図２（ａ），（ｂ）は、レコードデータ１３６及び自立インデックスデータ１３７のデータ構成例を示している。
【００４７】
同図（ａ）において、レコードデータ１３６の最初に登録されているレコード１３６１は、レコードＩＤが０であり、名前がＡ、電話番号が１、備考は無しである。以下のレコードも同様であり、本実施の形態では全部で５つのレコードが登録されている。
【００４８】
同図（ｂ）において、自立インデックスデータ１３７には順序規則であるソート・フィルタ条件がプログラムされているモジュールの名前（識別名）として、条件クラス名１３７１が登録されている。
【００４９】
本実施の形態では、これはＪａｖａ（登録商標）言語のクラス名であり、アドレス帳アプリケーション１２が提供する順序規則１２１の名前（識別名）である。
【００５０】
本実施の形態では、このソート・フィルタ条件にプログラム可能な任意のものを使用できることが特徴であるが、ここでは簡単のために例として「備考に”Ｂ”という文字を含んだものを電話番号で昇順にソートする」という条件とする。
【００５１】
図２（ａ）に示すレコードデータ１３６にこの条件を適用すると、レコードＩＤ＝１、ＩＤ＝３、ＩＤ＝４の３つのレコードが備考に”Ｂ”を含んでいるので、これらを電話番号で昇順ソートした結果のＩＤ＝４、ＩＤ＝１、ＩＤ＝３が、この順に自立インデックスデータ１３７に登録（図２（ｂ）参照）されている。
【００５２】
なお、ここでは自立インデックスデータ１３７は１つであるが、複数の順序規則を使用して複数の自立インデックスデータとすることもできる。
【００５３】
ここで、アドレス帳アプリケーション１２はアドレス帳データベース１３５の所有者であり、アドレス帳アプリケーション１２がデータベース管理装置１３に依頼してアドレス帳データベース１３５を作成する際に、順序規則１２１である条件クラスの名前（識別名）をデータベース管理装置１３に登録依頼する。
【００５４】
この登録の依頼は、アドレス帳アプリケーション１２から要求処理部１３１に対して行われ、ソート・フィルタ処理部１３４を通じて自立インデックスデータ１３７に記録される。
【００５５】
この条件クラスのインターフェースはデータベース管理装置１３によって規定されており、本実施の形態ではＪａｖａ言語の　ｉｎｔｅｒｆａｃｅ３０１を用いている。
【００５６】
この　ｉｎｔｅｒｆａｃｅは例えば図３（ａ）に示すようになる。
【００５７】
ｆｉｌｔｅｒメソッド３０２は、自立インデックスデータ１３７に登録するレコードと、登録しないレコードとを振り分ける際にソート・フィルタ処理部１３４が使用するものであり、実装はアプリケーションプログラマが行う。
【００５８】
このメソッドが、与えられたレコードに対してｔｒｕｅを返すと、そのレコードは自立インデックスデータ１３７に登録され、ｆａｌｓｅを返すと登録されない。
【００５９】
ｃｏｍｐａｒｅメソッド３０３は、自立インデックスデータ１３７に登録するレコードの順序を規定するものであり、ソート・フィルタ処理部１３４が使用するものである。実装はやはりアプリケーションプログラマが行う。
【００６０】
このメソッドは与えられた２つのレコードに対してどちらが大きいか、又は同じ大きさかを返す。
【００６１】
このメソッドが返す具体的な値は、一般の比較関数に見られるものと同じで、２つのレコードが同じ大きさであれば０であり、第１引数のレコードのほうが大きければ正の値であり、第２引数のレコードのほうが大きければ負の値となるようにする。
【００６２】
図２（ｂ）に示す自立インデックスデータ１３７に登録されている条件クラス名１３７１のクラス本体はアドレス帳アプリケーション１２が提供している順序規則１２１であり、「備考に”Ｂ”という文字を含んだものを電話番号で昇順にソートする」という条件であったが、これを上記規定の　ｉｎｔｅｒｆａｃｅに従って実装すると、例えば図３（ｂ）に示すようになる。
【００６３】
図５は、図２（ａ）に示すレコードデータ１３６に、図４に示すレコード４０１を電話アプリケーション１１の要求により追加する処理フローを示している。
【００６４】
先ず、電話アプリケーション１１が図４に示す内容のレコード追加を要求処理部１３１に依頼する（ステップＳ１１）。
【００６５】
次に、依頼を受けた要求処理部１３１は、未使用のレコードＩＤを生成し、追加レコード４０１に付与する（ステップＳ１２）。
【００６６】
続いて要求処理部１３１は、ソート・フィルタ処理部１３４を通じて、追加レコード４０１が自立インデックスデータ１３７に登録されるかどうかを判定する（ステップＳ１３）。
【００６７】
この判定の結果、　ｆａｌｓｅと判定され、自立インデックスデータ１３７に登録されない場合は、ステップＳ１５の「レコードデータにレコード追加」に処理を進め、追加レコード４０１を自立インデックスデータ１３７には登録せずに、レコード処理部１３３を介してレコードデータ１３６にのみ追加する。
【００６８】
一方、ステップＳ１３での判定の結果、ｔｒｕｅ判定となり、自立インデックスデータ１３７に登録される場合は、ステップＳ１４の「自立インデックスデータにレコードＩＤ挿入」に処理を進める。
【００６９】
ここでは追加レコード４０１の挿入位置をバイナリサーチ等によって探索し、ステップＳ１２の「レコードＩＤ付与」で決定されたＩＤを自立インデックスデータ１３７に挿入する。
【００７０】
図６は、上記ステップＳ１３の処理をより詳細に説明したものである。
【００７１】
すなわち、ソート・フィルタ処理部１３４は、自立インデックスデータ１３７に登録されている条件クラス名１３７１を取得する（ステップＳ２１）。
【００７２】
次に、ソート・フィルタ処理部１３４は、この条件クラス名１３７１が示す順序規則１２１（図３（ｂ）の符号３１１参照）を、モジュールロード部１３２を通じてアドレス帳データベース１３５の所有者であるアドレス帳アプリケーション１２からロードする（ステップＳ２２）。
【００７３】
ここで、本実施の形態での順序規則１２１，３１１はＪａｖａ言語のクラスであり、モジュールロード部１３２はこれをロードするＪａｖａプログラムである。クラスをロードする具体的方法としては、Ｊａｖａ標準のクラスローダがクラスをロード可能なクラスパスに、電話アプリケーション１１やアドレス帳アプリケーション１２など全アプリケーションのクラスを配置しておき、モジュールロード部１３２はＪａｖａ標準のクラスローダを使用して順序規則１２１，３１１をロードする方法が最も簡便である。
【００７４】
データベース管理装置を含むプログラム実行システムによっては、電話アプリケーション１１やアドレス帳アプリケーション１２などのクラスがアプリケーション毎に異るクラスパスに配置されることも考えられる。この場合は標準のクラスローダを拡張して、実行するアプリケーションが配置されているクラスパスと、そのアプリケーションが使用するデータベースの所有者であるアプリケーションのクラスが配置されているクラスパス双方からクラスをロードできるクラスローダを作成する。この拡張されたクラスローダによって、アプリケーションのクラスをロード、実行できると共に、モジュールロード部１３２が順序規則１２１，３１１をロード可能となる。
【００７５】
すなわち、図８に示すように、電話アプリケーション１１が動作する電話アプリケーションプロセス１１Ａは、プロセス内に順序規則１２１が存在しないため、これを使用することができないが、モジュールロード部１３２によって電話アプリケーションプロセス１１Ａ内に順序規則１２１をロードすることにより、順序規則１２１が使用可能となる。
【００７６】
また、ロードされたクラス１３７１（図２（ｂ）参照），３１１（図３（ｂ）参照）はデータベース管理装置１３が規定する　ｉｎｔｅｒｆａｃｅ３０１（図３（ａ）参照）を実装しているので、ソート・フィルタ処理部１３４は　ｆｉｌｔｅｒメソッド３１２（図３（ｂ）参照）を使用できる。
【００７７】
そこで、ソート・フィルタ処理部１３４は、このｆｉｌｔｅｒメソッド３１２に追加レコード４０１を渡し、自立インデックスデータ１３７に登録されるか否かを判定する（ステップＳ２３）。
【００７８】
判定結果は、自立インデックスデータ１３７に登録されるのであればｔｒｕｅとなり、登録されないのであれば　ｆａｌｓｅとなる（ステップＳ２４）。
【００７９】
この結果は、そのまま図５のステップＳ１３の判定結果となる。
【００８０】
本実施の形態での追加レコード４０１は、備考フィールドに”Ｂ”を含むのでｔｒｕｅ判定となり、ソート・フィルタ処理部１３４はこの追加レコード４０１が自立インデックスデータ１３７に登録されるものと判定する。
【００８１】
もし、ｆｉｌｔｅｒメソッド３１２が　ｆａｌｓｅ判定を返せば、ソート・フィルタ処理部１３４は、この追加レコード４０１は自立インデックスデータ１３７に登録しないものと判定する。
【００８２】
なお、図５に示すステップＳ１４の「自立インデックスデータにレコードＩＤ挿入」の処理において、ソート状態を保持するように追加レコード４０１の挿入位置を決定する際に、２つのレコードの大小を比較するメソッドが必要となるが、これも前記の自立インデックスデータ１３７に登録されるかどうかを調べる場合と同様であり、ソート・フィルタ処理部１３４は条件クラス名１３７１に登録されている名前のクラスを、モジュールロード部１３２を通じてアドレス帳データベース１３５の所有者であるアドレス帳アプリケーション１２よりロードし、ｃｏｍｐａｒｅメソッド３１３（図３（ｂ）参照）を大小比較メソッドとして使用する。
【００８３】
以上のようにして追加レコード４０１を追加した後のレコードデータ１３６と自立インデックスデータ１３７は、図７に示すようになる。すなわち、レコードデータ１３６は、例えば一番最後のレコード１３６２として末尾に追加されている。また、自立インデックスデータ１３７は、追加したレコードのＩＤが電話番号順に並ぶように挿入されている。この例では、レコードＩＤ＝１とレコードＩＤ３の間に追加されたレコードＩＤ＝５が挿入されている。
【００８４】
以上説明したように、本実施の形態では、自立インデックスデータ１３７を関知しない電話アプリケーション１１の依頼によってレコードを追加したにもかかわらず、自動的に「備考に”Ｂ”という文字を含んだものを電話番号で昇順にソートする」という条件を維持するように更新されている。
【００８５】
なお、本実施の形態ではＪａｖａ言語を使用したが、Ｃ言語等でも動的にロードされるライブラリを使用して、同様の機能を実装することができる。
【００８６】
また、自立インデックスデータ１３７に登録されるレコードＩＤの記録構造を、ソートされた一次元配列として説明しているが、ツリー構造等の他の構造にした場合にも、本装置を適用可能である。
【００８７】
以上説明したデータベース管理装置は、複数のレコード型データを記憶するとともにこれらデータのインデックスを管理するためのプログラムで実現されている。
【００８８】
発明の対象とするのは、このプログラムそのものであってもよいし、このプログラムがコンピュータで読み取り可能な記録媒体に格納されているものであってもよい。
【００８９】
本発明では、この記録媒体として、図１に示されているデータベース管理装置１３で処理が行なわれるために必要なメモリ、例えばＲＯＭのようなものそのものがプログラムメディアであってもよいし、また、図示していない外部記憶装置としてプログラム読み取り装置が設けられ、そこに記録媒体を挿入することで読み取り可能なプログラムメディアであってもよい。いずれの場合においても、格納されているプログラムはマイクロコンピュータがアクセスして実行させる構成であってもよいし、あるいはいずれの場合もプログラムを読み出し、読み出されたプログラムは、マイクロコンピュータの図示しないプログラム記憶エリアにロードされて、そのプログラムが実行される方式であってもよい。このロード用のプログラムは予め本体装置に格納されているものとする。
【００９０】
ここで、上記プログラムメディアは、本体と分離可能に構成される記録媒体であり、磁気テープやカセットテープ等のテープ系、ＦＤ（フレキシブルディスク）やＨＤ（ハードディスク）等の磁気ディスクやＣＤ−ＲＯＭ／ＭＯ／ＭＤ／ＤＶＤ等の光ディスク系、ＩＣカード（メモリカードを含む）／光カード等のカード系、あるいはマスクＲＯＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、フラッシュＲＯＭ等による半導体メモリを含めた固定的にプログラムを担持する媒体であってもよい。
【００９１】
また、本発明においては、インターネットを含む通信ネットワークと接続可能なシステム構成であ場合には、通信ネットワークからプログラムをダウンロードするように流動的にプログラムを担持する媒体であってもよい。なお、このように通信ネットワークからプログラムをダウンロードする場合には、そのダウンロード用プログラムは予め装置本体に格納しておくか、あるいは別の記録媒体からインストールされるものであってもよい。なお、記録媒体に格納されている内容としてはプログラムに限定されず、データであってもよい。
【００９２】
さらに、本発明では、プログラム自体として、図１に示されているデータベース管理装置１３で実行される処理そのものであってもよいし、あるいはインターネットを含む通信ネットワークとアクセスすることで取り込める、あるいは取り込めたものであってもよいし、こちらから送り出すものであってもよい。さらには、この取り込んだプログラムに基づいて、上記データベース管理装置内で処理された結果、つまり生成されたものであってもよい。あるいは、こちらから送り出す際に上記データベース管理装置内で処理された結果、つまり生成されたものであってもよい。なお、これらのものはプログラムに限定されず、データであってもよい。
【００９３】
【発明の効果】
本発明によれば、ソート・フィルタ結果をインデックスデータに保持するレコード型データベースにおいて、任意のソート・フィルタ条件を使用してインデックスデータの更新を行うことができる。また、当該データベースを所有し、ソート・フィルタ条件を提供するアプリケーションも何等特殊な処理を行う必要もなく、データベース作成時にソート・フィルタ条件を含むモジュールの名前をデータベースシステムに登録するだけで、ソート・フィルタ結果を保持するインデックスデータの有効性を保持したまま、当該データベースの変更を他のアプリケーションに行わせることができる。
【図面の簡単な説明】
【図１】本発明のデータベース管理装置の一実施の形態を示すシステム構成図である。
【図２】（ａ）はレコードデータのデータ構成例、（ｂ）は自立インデックスデータのデータ構成例を示す説明図である。
【図３】（ａ）はソート・フィルタ条件クラスのインターフェースの具体例、（ｂ）はクラスの具体例を示す説明図である。
【図４】追加するレコードの具体例を示す説明図である。
【図５】レコードの追加処理手順を説明するためのフローチャートである。
【図６】自立インデックスデータへの挿入可否を判定する処理手順を説明するためのフローチャートである。
【図７】（ａ）はレコード追加後のレコードデータのデータ構成例、（ｂ）はレコード追加後の自立インデックスデータのデータ構成例である。
【図８】電話アプリケーションのプロセス図である。
【図９】従来のデータベース管理装置の一システム構成図である。
【図１０】従来のデータベース管理装置によるレコードデータの具体例を示す説明図である。
【図１１】従来のデータベース管理装置における順序規則の具体例を示す説明図である。
【図１２】従来のデータベース管理装置におけるインデックスデータの具体例を示す説明図である。
【図１３】従来のデータベース管理装置の他のシステム構成図である。
【図１４】（ａ），（ｂ）は従来のデータベース管理装置におけるアプリケーションのプロセス図である。
【符号の説明】
１１　電話アプリケーション
１２　アドレス帳アプリケーション
１２１　順序規則（ソート・フィルタ条件クラス）
１３　データベース管理装置
１３１　要求処理部
１３２　モジュールロード部
１３３　レコード処理部
１３４　ソート・フィルタ処理部
１３５　アドレス帳データベース
１３６　アドレス帳データベースのレコードデータ
１３７　アドレス帳データベースの自立インデックスデータ
３０１　条件インターフェース
３０２　条件インターフェースのフィルタ用メソッド
３０３　条件インターフェースのソート用メソッド
３１１　条件クラス
３１２　条件クラスのフィルタ用メソッド
３１３　条件クラスのソート用メソッド
４０１　追加するレコード
【図１】
2004110696.tif 000003
【図２】
2004110696.tif 000004
【図３】
2004110696.tif 000005
【図４】
2004110696.tif 000006
【図５】
2004110696.tif 000007
【図６】
2004110696.tif 000008
【図７】
2004110696.tif 000009
【図８】
2004110696.tif 000010
【図９】
2004110696.tif 000011
【図１０】
2004110696.tif 000012
【図１１】
2004110696.tif 000013
【図１２】
2004110696.tif 000014
【図１３】
2004110696.tif 000015
【図１４】
2004110696.tif 000016