情報処理装置
【課題】リレーショナルデータモデルに従ったデータベース操作言語によってアクセスされるデータベースを、リレーショナルデータモデルに従ったデータベースと、それ以外のモデルに従ったデータベースとからなる構成とする。
【解決手段】アプリケーション群１７から送信されたＳＱＬによって記述されたデータベース操作要求を受信すると、データベース切替部２１は、その操作要求によって操作されるリレーションの名称に依存して、その要求をリレーショナルデータベース２５を管理するリレーショナルデータベース操作部２４か、非リレーショナルデータベース、例えば、インデックス付きレコードデータ２８を管理するデータベース操作変換部２６のいずれかに送信する。データベース操作変換部２６は、受信された要求を変換テーブル２７を参照してインデックス付きレコードデータ２８を操作するＡＰＩに変換する。
【解決手段】アプリケーション群１７から送信されたＳＱＬによって記述されたデータベース操作要求を受信すると、データベース切替部２１は、その操作要求によって操作されるリレーションの名称に依存して、その要求をリレーショナルデータベース２５を管理するリレーショナルデータベース操作部２４か、非リレーショナルデータベース、例えば、インデックス付きレコードデータ２８を管理するデータベース操作変換部２６のいずれかに送信する。データベース操作変換部２６は、受信された要求を変換テーブル２７を参照してインデックス付きレコードデータ２８を操作するＡＰＩに変換する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理装置に係り、特に、データベース処理に関する。
【背景技術】
【０００２】
情報処理装置で、リレーショナルデータモデルに従ってデータベースを構築し、そのモデルに従ったデータベース操作言語、例えば、ＳＱＬを介してデータベースを操作することが知られている。ここで、データベースの操作は、データの追加、変更、削除、そしてクエリ（検索）を含む。
【０００３】
リレーショナルデータモデルに従うと、あらゆるデータは、ｎ項の関係（リレーション）で論理的に表現され、アプリケーションがどのような手順でデータベースを操作するかに依存した表現はされない。そのため、データベース操作言語は、理解が容易であるが、データベース操作によっては処理に長時間を要することがある。
【０００４】
また、主に、クエリの高速な処理を可能とするため、本来のデータの他に各種の補助データを付加させる。そこで、補助データの記憶のために大きい記憶容量を必要とすることがあり、また、補助データを操作するために長時間の処理を必要とすることがある。
【０００５】
一方、ネットワーク型データモデル、木構造型データモデル、インデックス付きレコードデータ、ランダムアクセスデータ、ハッシングされたデータなどのデータ表現に従って構築されたデータベースでは、データベース操作言語は、データ表現に依存したものとなるため、理解が容易とは限らない。また、特定のクエリのみが可能であって、データベース操作言語は、ＡＰＩ（Application Program Interface）として提供されることもある。しかし、どのようなデータベース操作であっても処理に必要な時間は予測が容易であり、更には、特定のクエリを高速に処理するデータベースを構築することも可能である。
【０００６】
このように、リレーショナルデータモデルに従ったデータベースと、それ以外のモデルに従ったデータベースとは、それぞれ長短があるためにいずれも用いられている。しかしながら、複数のデータベースを用いるアプリケーションは、所望のデータがいずれのデータベースに記憶されているかに依存して異なるデータベース操作言語を介してアクセスする必要があり、複雑なプログラムとなる。
【０００７】
そこで、アプリケーションは、いずれのデータベースへのアクセスであっても、例えば、ＳＱＬを介してアクセスすることとし、アクセスされるデータがリレーショナルデータモデル以外のモデルに従ったデータベースに含まれている場合、ＳＱＬをそのデータベースに固有のデータ操作言語に変更した上で、そのデータベースへアクセスすることが知られている（例えば、特許文献１参照。）。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】特開平２−６７６８２号公報（第１頁、図１）
【発明の概要】
【発明が解決しようとする課題】
【０００９】
しかしながら、上述した特許文献１に開示されている方法では、リレーショナルデータモデルに従ったデータベースの長所と、それ以外のモデルに従ったデータベースの長所とを組み合せたデータベース構築が考慮されていない問題点があった。
【００１０】
本発明は上記問題点を解決するためになされたもので、リレーショナルデータモデルに従ったデータベース操作言語によってアクセスされるデータベースを、リレーショナルデータモデルに従ったデータベースと、それ以外のモデルに従ったデータベースとからなる構成とすることによって、高速なデータベースクエリ操作を実現する情報処理装置を提供することを目的とする。
【課題を解決するための手段】
【００１１】
上記目的を達成するために、本発明の情報処理装置は、第１のデータベースを管理する第１のデータベース管理手段と、第２のデータベースを管理する第２のデータベース管理手段と、リレーショナルデータベース操作要求の要素毎にＡＰＩ（Application Program Interface）を記憶する記憶手段と、リレーショナルデータベース操作要求を受信して、その受信されたリレーショナルデータベース操作要求に係るリレーションに基づいて、その操作要求を前記第１のデータベース管理手段、及び、前記第２のデータベース管理手段のいずれか一方へ送信するデータベース切替手段とを有し、前記第１のデータベースは、リレーショナルデータベースであり、前記第１のデータベース管理手段は、前記データベース切替手段から送信されたリレーショナルデータベース操作要求を受信し、その操作要求に従って前記第１のデータベースを操作し、前記第２のデータベース管理手段は、前記データベース切替手段から送信されたリレーショナルデータベース操作要求を受信し、その操作要求を要素に分解し、前記記憶手段に記憶されたその分解された要素のＡＰＩを呼び出すことによって、前記リレーショナルデータベース操作要求に従った前記第２のデータベースの操作を行うことを特徴とする。
【発明の効果】
【００１２】
本発明によれば、リレーショナルデータモデルに従ったデータベース操作言語によってアクセスされるデータベースを、リレーショナルデータモデルに従ったデータベースと、それ以外のモデルに従ったデータベースとからなる構成とすることによって、高速なデータベースクエリ操作を実現することができる。
【図面の簡単な説明】
【００１３】
【図１】本発明の実施形態に係る移動通信装置の構成を示すブロック図。
【図２】本発明の実施形態に係る移動通信装置のデータベース管理部の詳細な構成を示すブロック図。
【図３】本発明の実施形態に係る移動通信装置のデータベース管理部の動作の詳細を示すフローチャート。
【図４】本発明の実施形態に係る変換テーブルの第１の例。
【図５】本発明の実施形態に係る変換テーブルの第２の例。
【発明を実施するための形態】
【００１４】
以下に、本発明の実施形態に係る情報処理装置が適用された移動通信装置の実施の形態を、図面を参照して説明する。図１は、本発明の実施形態に係る移動通信装置の構成を示すブロック図である。この移動通信装置は、装置全体の制御を行う制御部１１と、移動通信網の基地局（図示せず）との間で電波の送受信を行うアンテナ１２ａと、通信部１２ｂと、送受信部１３と、通話用のスピーカ１４ａと、通話用のマイクロフォン１４ｂと、通話部１４ｃと、表示部１５と、入力部１６と、アプリケーション群１７と、データベース管理部２０とからなる。
【００１５】
図２は、データベース管理部２０の詳細な構成を示すブロック図である。データベース管理部２０は、アプリケーション群１７と接続されるデータベース切替部２１と、リレーショナルデータベース管理部２２と、インデックス付きレコードデータ管理部２３とからなる。リレーショナルデータベース管理部２２は、データベース切替部２１と接続されるリレーショナルデータベース操作部２４と、リレーショナルデータベース２５とからなる。インデックス付きレコードデータ管理部２３は、データベース切替部２１と接続されるデータベース操作変換部２６と、変換テーブル２７と、インデックス付きレコードデータ２８とからなる。
【００１６】
上記のように構成された、本発明の実施形態に係る情報処理装置の各部の動作を、図１及び図２を参照して説明する。
【００１７】
通信部１２ｂは、アンテナ１２ａが受信した高周波信号を送受信部１３へ出力し、また、送受信部１３から出力される高周波信号をアンテナ１２ａより送信する。
【００１８】
送受信部１３は、通信部１２ｂからの高周波信号を増幅、周波数変換及び復調し、それによって得られたディジタル音声信号を通話部１４ｃへ、また、制御信号を制御部１１に送る。更には、通話部１４ｃから出力されるディジタル音声信号、及び制御部１１から出力される制御信号を変調、周波数変換及び増幅し、高周波信号を得て、それを通信部１２ｂに送る。
【００１９】
通話部１４ｃは、送受信部１３から出力されるディジタル音声信号をアナログ音声信号に変換し、それを増幅してスピーカ１４ａに送る。また、マイクロフォン１４ｂから出力されるアナログ音声信号を増幅し、それをディジタル音声信号に変換して送受信部１３に送信する。
【００２０】
表示部１５は、使用者に操作を促す表示や、使用者が操作した内容の表示や、装置の動作状態の表示などに用いられるバックライト付きのＬＣＤ（Liquid Crystal Display）であり、制御部１１に制御されることで、カーソルを含む文字・数字を含む画像データの表示動作を行い、表示されているデータは、入力部１６からの入力操作や着信信号に応答して制御部１１からの指示を受けることで切換わる。
【００２１】
入力部１６は、通信相手の電話番号などを指定し、また、トグル式の入力方式によってひらがな文字、アルファベット文字及び記号文字を入力するための数字キーと、カーソル移動キーやスクロールキーを含む複数の機能キーとを含むキーからなる。そして、入力部１６のキーが押下されると、そのキーの識別子を制御部１１に通知する。
【００２２】
アプリケーション群１７は、データベース管理部２０に含まれるデータベースをＳＱＬによる記述によって操作する１つ又は複数のアプリケーションである。アプリケーション群１７に如何なるアプリケーションが含まれるかは、本発明の実施に影響を及ぼさないが、例えば、アドレス帳管理部、予定表管理部、電子メール管理部などである。これらのアプリケーションは、入力部１６の所定のキー操作に従って、ＳＱＬによって記述されたデータベース操作をデータベース管理部２０に要求する。その要求が、例えばクエリ操作であって、データベース管理部２０から要求に対して検索されたデータが得られる場合、そのデータに基づく表示を表示部１５にさせる。
【００２３】
データベース管理部２０は、ＳＱＬによって記述されたデータベース操作要求に従って、データベース管理部２０内のデータベースの操作を行う。そして、その操作の結果を回答する。回答の一例は、例えば、操作がクエリである場合、検索されたデータである。
【００２４】
データベース管理部２０の動作の詳細を、図３に示すフローチャートを参照して説明する。データベース管理部２０は、アプリケーション群１７から送信された、ＳＱＬによって記述されたデータベース操作要求を受信してデータベース管理動作を開始する（ステップＳ１０１）。
【００２５】
そして、まず、データベース切替部２１は、受信されたＳＱＬによって記述されたデータベース操作要求によって操作されるリレーションの名称がデータベース切替部２１内に記憶されたリレーションの名称と一致するか否かを調べる（ステップＳ１０２）。そして、一致しない場合、そのデータベース操作要求はリレーショナルデータベース管理部２２によって処理されると判断して、その要求をリレーショナルデータベース操作部２４に送る。
【００２６】
リレーショナルデータベース操作部２４は、リレーショナルデータベース２５に対して、受信されたＳＱＬによって記述されたデータベース操作を行い（ステップＳ１０３）、その操作によって得られた回答を、データベース切替部２１は、データベース操作要求を送信したアプリケーション群１７に送信して（ステップＳ１０４）、データベース管理部２０は、データベース管理動作を終了する（ステップＳ１０５）。
【００２７】
ステップＳ１０３で、リレーショナルデータベース操作部２４は、ＳＱＬによって記述可能な全てのデータベース操作要求に対する処理が可能である。この処理の一環として、リレーショナルデータベース操作部２４は、ＳＱＬによって記述された要求のパース（構文解析）を行い、併せて、構文の誤り検出を行う。
【００２８】
そして、リレーショナルデータベース操作部２４は、パースの結果と、リレーショナルデータベース２５に含まれるインデックスなどの補助データの有無を参照して、リレーショナルデータベース２５を操作する。ここで、ＳＱＬによって記述された要求がクエリである場合、リレーショナルデータベース２５に含まれる補助データを利用した最適化処理、即ち、最も高速と判断される処理手順の選択を伴う。
【００２９】
一方、ステップＳ１０２で一致する場合、データベース切替部２１は、そのデータベース操作要求はインデックス付きレコードデータ管理部２３によって処理されると判断して、その要求をデータベース操作変換部２６に送る。
【００３０】
データベース操作変換部２６は、ＳＱＬによって記述されたデータベース操作要求を受信して、その操作要求を要素に分解し、分解された要素を変換テーブル２７を参照することによって、インデックス付きレコードデータ２８を操作するＡＰＩと、優先度との組に変換し（ステップＳ１０６）、優先度が高い組のＡＰＩから、低い組のＡＰＩへと、順にＡＰＩを呼ぶことによってインデックス付きレコードデータ２８を操作する（ステップＳ１０７）。
【００３１】
データベース操作変換部２６は、上記操作によって得られた結果をリレーショナルデータベース操作部２４がリレーショナルデータベース２５を操作して得る回答の形式に変換し（ステップＳ１０８）、データベース切替部２１は、その変換によって得られた回答をデータベース操作要求を送信したアプリケーション群１７に送信して（ステップＳ１０４）、データベース管理部２０は、データベース管理動作を終了する（ステップＳ１０５）。
【００３２】
ここで、データベース操作変換部２６は、データベース切替部２１によって選択されたリレーションに対する操作のみを行う。そこで、処理する操作には限りがあるため、例えば、その操作のパースは限られた処理である。更には、アプリケーション群１７が操作記述に所定の区切り記号を含ませる、例えば、空白文字や、改行文字の使い方に制約を設けることによって、パースは更に限られた処理となる。
【００３３】
また、インデックス付きレコードデータ２８の操作は、変換テーブル２７に記憶されたＡＰＩを介して行うことによって最も高速な処理が可能であるので、データベース操作変換部２６は、それ以外の最適化処理は行わない。
【００３４】
上記のように構成された、本発明の実施形態に係る情報処理装置において、如何なるＳＱＬによって記述されたデータベース操作要求が、如何にインデックス付きレコードデータ管理部２３によって処理されるかを説明する。なお、リレーショナルデータベース操作部２４は、周知のように、ＳＱＬによって記述可能な全てのデータベース操作要求を処理するので、処理の詳細の説明を省略する。
【００３５】
（第１の例）
以下の（式１）〜（式４）は、インデックス付きレコードデータ管理部２３によって処理されるデータベース操作要求の例を示す。この要求は、ＳＱＬによって記述されるが、理解を容易にするため、必ずしもＳＱＬの文法に従うことなく、要点を示す。
【００３６】
ＳＥＬＥＣＴ 要求属性 ＦＲＯＭ Ｒ１
ＷＨＥＲＥ 条件１ ＯＲＤＥＲ ＢＹ ソート属性 （式１）
ＳＥＬＥＣＴ 要求属性 ＦＲＯＭ Ｒ１
ＷＨＥＲＥ 条件２ ＯＲＤＥＲ ＢＹ ソート属性 （式２）
ＳＥＬＥＣＴ 要求属性 ＦＲＯＭ Ｒ１
ＷＨＥＲＥ 条件１ ＡＮＤ 条件２ ＯＲＤＥＲ ＢＹ ソート属性 （式３）
ＳＥＬＥＣＴ 要求属性 ＦＲＯＭ Ｒ１
ＷＨＥＲＥ 条件１ ＯＲ 条件２ ＯＲＤＥＲ ＢＹ ソート属性 （式４）
【００３７】
ここで、Ｒ１はリレーション名、条件１はＡ１＝Ｖ１、条件２はＡ２＝Ｖ２（Ａ１、Ａ２は、Ｒ１の属性名。）、Ｖ１、Ｖ２は値である。また、要求属性はＲ１の属性名、ソート属性はＲ１の属性名と、ソート順（昇順か、降順か。）である。
【００３８】
図４は、この（式１）〜（式４）で示された要求を処理するための変換テーブル２７の第１の例を示す。変換テーブル２７は、操作要求の要素２７ａと、ＡＰＩ２７ｂと、優先度２７ｃとが関連付けられている。ここで、操作要求の要素２７ａは、ＳＱＬによって記述されたデータベース操作要求の要素であって、図４に示すように、リレーション名、条件などである。ＡＰＩ２７ｂは、操作要求の要素２７ａを処理するためにインデックス付きレコードデータ２８を操作するＡＰＩである。優先度２７ｃは、ＡＰＩ２７ｂのいずれを先に呼び出すかを示し、高い場合先に、低い場合後に呼び出すことを示す。
【００３９】
（式１）が、変換テーブル２７を参照しつつデータベース操作変換部２６によって処理される手順を説明する。まず、操作対象のリレーション名が「Ｒ１」なので、操作要求の要素２７ａが「Ｒ１」である変換テーブル２７を検索する。その検索の結果、そのリレーションに関する操作は、ＡＰＩ２７ｂが示す「機能ＡＰＩ＿Ｒ１（）」を介して行うので、このＡＰＩを呼び出す。ここで、このＡＰＩ２７ｂによって呼び出される機能は、リレーション「Ｒ１」が如何にインデックス付きレコードデータ２８にマッピングされているかに従って作成されている。例えば、その属性のいずれについてインデックスが付いているかなどに完全に依存して作られているので、最適化の動作は不要である。
【００４０】
次に、データベース操作要求の要素として「条件１」が取り出され、操作要求の要素２７ａが「Ｒ１＿Ａ１＝Ｖ１」である変換テーブル２７を検索する。ここで、「Ｒ１＿Ａ１＝Ｖ１」は、条件１である「Ａ１＝Ｖ１」と比較して、Ａ１がＲ１の属性であることを示すため、「Ａ１」の前に「Ｒ１＿」が付加されている。その検索の結果、この条件の検索は、ＡＰＩ２７ｂが示す「機能ＡＰＩ＿Ｒ１＿Ａ１（）」を介して行うので、このＡＰＩを呼び出すことによって、「条件１」の検索が行われる。
【００４１】
検索の後、（式１）の要求属性が選択され、ソート属性に従ってソートされる。これは、要求属性及びソート属性が事前に定められていれば、検索の一環として行われる。それらが事前に定められていない場合、それらを操作要求の要素２７ａとする変換テーブル２７のＡＰＩ２７ｂを介して行われる。
【００４２】
（式２）は、（式１）と比較して、「条件１」に代えて「条件２」である。そこで、上述した（式１）の処理の「機能ＡＰＩ＿Ｒ１＿Ａ１（）」に代えて「機能ＡＰＩ＿Ｒ１＿Ａ２（）」が用いられる。ここで、これらの２つのＡＰＩを介して呼び出されるプログラムの内容は異なっていることがある。例えば、属性「Ａ１」や、属性「Ａ２」にインデックスが付けられているか否かによって、プログラムは大きく異なる。
【００４３】
（式３）は、（式１）と比較して、「条件１」に代えて「条件１ ＡＮＤ 条件２」である。そこで、「機能ＡＰＩ＿Ｒ１＿Ａ１（）」及び「機能ＡＰＩ＿Ｒ１＿Ａ２（）」の２つのＡＰＩを介して検索が行われる。ただし、前者に関連付けられた優先度２７ｃが「高」で、後者に関連付けられた優先度２７ｃが「低」であるので、まず、前者を介した検索を行い、次に、後者を介した検索が行われる。
【００４４】
この優先度２７ｃの高低は、属性「Ａ１」に係わる検索は、属性「Ａ２」に係わる検索より高速に処理されることに基づいている。その理由は、属性「Ａ１」にはインデックスが付されているが、属性「Ａ２」にはインデックスが付されていない、属性「Ａ１」の値は整数であって、属性「Ａ２」の値は文字列や、浮動小数点数である、属性「Ａ１」の値は４バイトの文字列であって、属性「Ａ２」の値は可変長の文字列である、属性「Ａ１」の値は整数であって、属性「Ａ２」の値は画像であるなどであって、ＣＰＵの能力に依存する。
【００４５】
なお、属性「Ａ１」と、属性「Ａ２」とが上記のいずれかに該当する場合であっても、機械的に上記の優先度２７ｃとなる訳ではない。変換テーブル２７は、ＣＰＵの能力に加え、アプリケーション群１７が如何なるクエリ要求を行うか、また、インデックス付きレコードデータ２８に記憶される値の分布を熟知している設計者によって設計され、最適な処理が行われるように設定される。例えば、ある属性を用いた検索によって得られるデータの件数が極めて少数である場合、その属性に関連付けられた優先度２７ｃは高くなる。
【００４６】
（式４）は、（式３）と比較して、条件の「ＡＮＤ」に代えて「ＯＲ」である。そこで、リレーション名が「Ｒ１」でり、ＯＲの検索である場合のデータベース操作要求の要素として「Ｒ１＿ＯＲ」が取り出され、操作要求の要素２７ａが「Ｒ１＿ＯＲ」である変換テーブル２７を検索する。その検索の結果、この条件の検索は、ＡＰＩ２７ｂが示す「機能ＡＰＩ＿Ｒ１＿ＳＥＱ（）」を介して行うので、このＡＰＩを呼び出すことによって、（式４）の検索が行われる。
【００４７】
ここで、この「機能ＡＰＩ＿Ｒ１＿ＳＥＱ（）」は、リレーション「Ｒ１」マッピングされているインデックス付きレコードデータ２８をシーケンシャルにアクセスするＡＰＩである。属性「Ａ１」や、属性「Ａ２」にインデックスが付けられているか否かに係わらず、「Ｒ１＿ＯＲ」を含む検索は、シーケンシャルアクセスによることが示されている。
【００４８】
これは、例えば、属性「Ａ１」や、属性「Ａ２」の値の分布に依存して、たとえ、インデックスが付されていても、用いないことによって一層高速な処理が可能な場合に対応する。即ち、変換テーブル２７は、インデックス付きレコードデータ２８に記憶される値の分布を熟知している設計者によって設計されるので、クエリ時の最適化処理を行うことなく最適な処理が可能である。一方、リレーショナルデータベース操作部２４は、値の分布に依存した最適化処理が最適でない可能性がある。
【００４９】
（第２の例）
図５は、上記（式１）〜（式４）で示された要求を処理するための変換テーブル２７の第２の例を示す。この例は、図４に示す第２の例と比較して、「機能ＡＰＩ＿Ｒ１（）」なるＡＰＩ２７ｂに代えて、「機能ＡＰＩ＿Ｒ１１（）、機能ＡＰＩ＿Ｒ１２（）」と記憶され、リレーション「Ｒ１」に関する操作は、２つのＡＰＩを介して行うことが示されている。これは、リレーション「Ｒ１」は、２つのインデックス付きレコードデータ２８、「Ｒ１１」と、「Ｒ１２」とからなることを示している。
【００５０】
また、「機能ＡＰＩ＿Ｒ１＿Ａ１（）」なるＡＰＩ２７ｂと、「機能ＡＰＩ＿Ｒ１＿Ａ２（）」なるＡＰＩ２７ｂに代えて、それぞれ「機能ＡＰＩ＿Ｒ１１＿Ａ１（）」、「機能ＡＰＩ＿Ｒ１２＿Ａ２（）」と記憶され、属性「Ａ１」は、「Ｒ１１」なるインデックス付きレコードデータ２８に、属性「Ａ２」は、「Ｒ１２」なるインデックス付きレコードデータ２８に記憶されていることを示す。
【００５１】
このように、アプリケーション群１７から送信されるデータベース操作記述によれば、１つのリレーション「Ｒ１」に対する操作であるが、データベース操作変換部２６による変換を経ると、２つのインデックス付きレコードデータ２８に対する操作となることは、ＳＱＬのジョイン操作の高速化に相当する。
【００５２】
即ち、２つのリレーションのジョインを経て行われるクエリにおいて、ジョインは、理解が容易なデータベース操作であるが、その実行には比較的長時間を要する。特に、ジョイン操作で指定される２つのリレーションの属性によっては、長時間を要する。例えば、それらの属性にインデックスが付されていない場合、それらの属性の値が可変長の文字列である場合などである。
【００５３】
このように、長時間を要する場合であっても、ジョインの前に、例えば、ジョインされるリレーションの中の特定の一方（図５に示す例では、属性「Ａ１」が含まれる、「Ｒ１１」なるインデックス付きレコードデータ２８。）に対する検索を行うことによって、得られるデータの件数が極くわずかな件数になる場合、上記２つのリレーションは、リレーショナルデータベース管理部２２によって管理されるより、インデックス付きレコードデータ管理部２３によって管理される方が高速な処理がされることがある。なお、この場合も、変換テーブル２７は、インデックス付きレコードデータ２８に記憶される値や、それに対して行われる操作を熟知している設計者によって設計されることが必要である。
【００５４】
また、リレーション「Ｒ１」を２つのインデックス付きレコードデータ２８、「Ｒ１１」と、「Ｒ１２」とに分けることは、そのリレーションの属性の値によって、データを二分し、それぞれを異なるインデックス付きレコードデータ２８として記憶させることにも用いられる。例えば、二分された一方の上記属性以外の属性の値が可変長のビット列であり、他方は、その値がない（ＮＵＬＬ値である。）場合、異なるインデックス付きレコードデータ２８とすることにより、高速な処理と、記憶容量の有効利用が可能である。
【００５５】
以上の説明は、処理速度が最も重視されるクエリ操作を例に行ったが、これ以外の操作、データの追加、変更、及び削除についても同様である。
【００５６】
以上の説明で、操作要求の要素２７ａとして記憶される条件は、属性名、比較演算子、及び値からなるとしたが、これに限るものではない。属性名、及び比較演算子からなるとしても良く、また、属性名からなるとしても良い。それぞれの場合、操作要求の要素２７ａとして記憶されない部分は、ＡＰＩ２７ｂが示すＡＰＩへ伝えられ、そのＡＰＩが伝えられた情報に従ってデータベースを操作する。
【００５７】
以上の説明で、データベース切替部２１は、データベース切替部２１内に記憶されたリレーションの名称を参照することによって、ＳＱＬによって記述されたデータベース操作要求がリレーショナルデータベース管理部２２によって処理されるか、インデックス付きレコードデータ管理部２３によって処理されるかを判断するとしたが、これに限るものではない。クエリの条件も参照して判断しても良い。この処理によれば、クエリの条件に従って、より高速な処理が可能な管理部を選択することができる。
【００５８】
なお、クエリの条件も参照して判断する処理においては、データベース切替部２１は、変換テーブル２７の操作要求の要素２７ａとして操作の要素が記憶されているクエリは、インデックス付きレコードデータ管理部２３によって処理されると判断しても良い。ただし、上記の処理による場合、同じリレーションをリレーショナルデータベース管理部２２と、インデックス付きレコードデータ管理部２３の双方に分割して、又は、二重に記憶させ、管理させることが必要になる。
【００５９】
以上の説明で、データベース管理部２０は、リレーショナルデータベース管理部２２に加えて、インデックス付きレコードデータ２８を管理するインデックス付きレコードデータ管理部２３からなるとしたが、これに限るものではない。即ち、データベース管理部２０は、リレーショナルデータベース管理部２２に加えて、リレーショナルデータモデルに基づかずに構築された任意のデータベースを管理する管理部を備えることによって、本発明は実施可能である。
【００６０】
リレーショナルデータモデルに基づかないデータベースには、ネットワーク型データモデルによるデータベース、木構造型データモデルによるデータベース、インデックス付きレコードデータ、ランダムアクセスデータ、ハッシングされたデータなどがある。
【００６１】
以上の説明は、本発明を移動通信装置に適用した形態を例にとって行ったが、これに限るものではない。本発明は、あらゆる情報処理装置に適用することが当然に可能である。本発明は以上の構成に限定されるものではなく、種々の変形が可能である。
【符号の説明】
【００６２】
１７ アプリケーション群
２０ データベース管理部
２１ データベース切替部
２２ リレーショナルデータベース管理部
２３ インデックス付きレコードデータ管理部
２４ リレーショナルデータベース操作部
２５ リレーショナルデータベース
２６ データベース操作変換部
２７ 変換テーブル
２７ａ 操作要求の要素
２７ｂ ＡＰＩ
２７ｃ 優先度
２８ インデックス付きレコードデータ
【技術分野】
【０００１】
本発明は、情報処理装置に係り、特に、データベース処理に関する。
【背景技術】
【０００２】
情報処理装置で、リレーショナルデータモデルに従ってデータベースを構築し、そのモデルに従ったデータベース操作言語、例えば、ＳＱＬを介してデータベースを操作することが知られている。ここで、データベースの操作は、データの追加、変更、削除、そしてクエリ（検索）を含む。
【０００３】
リレーショナルデータモデルに従うと、あらゆるデータは、ｎ項の関係（リレーション）で論理的に表現され、アプリケーションがどのような手順でデータベースを操作するかに依存した表現はされない。そのため、データベース操作言語は、理解が容易であるが、データベース操作によっては処理に長時間を要することがある。
【０００４】
また、主に、クエリの高速な処理を可能とするため、本来のデータの他に各種の補助データを付加させる。そこで、補助データの記憶のために大きい記憶容量を必要とすることがあり、また、補助データを操作するために長時間の処理を必要とすることがある。
【０００５】
一方、ネットワーク型データモデル、木構造型データモデル、インデックス付きレコードデータ、ランダムアクセスデータ、ハッシングされたデータなどのデータ表現に従って構築されたデータベースでは、データベース操作言語は、データ表現に依存したものとなるため、理解が容易とは限らない。また、特定のクエリのみが可能であって、データベース操作言語は、ＡＰＩ（Application Program Interface）として提供されることもある。しかし、どのようなデータベース操作であっても処理に必要な時間は予測が容易であり、更には、特定のクエリを高速に処理するデータベースを構築することも可能である。
【０００６】
このように、リレーショナルデータモデルに従ったデータベースと、それ以外のモデルに従ったデータベースとは、それぞれ長短があるためにいずれも用いられている。しかしながら、複数のデータベースを用いるアプリケーションは、所望のデータがいずれのデータベースに記憶されているかに依存して異なるデータベース操作言語を介してアクセスする必要があり、複雑なプログラムとなる。
【０００７】
そこで、アプリケーションは、いずれのデータベースへのアクセスであっても、例えば、ＳＱＬを介してアクセスすることとし、アクセスされるデータがリレーショナルデータモデル以外のモデルに従ったデータベースに含まれている場合、ＳＱＬをそのデータベースに固有のデータ操作言語に変更した上で、そのデータベースへアクセスすることが知られている（例えば、特許文献１参照。）。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】特開平２−６７６８２号公報（第１頁、図１）
【発明の概要】
【発明が解決しようとする課題】
【０００９】
しかしながら、上述した特許文献１に開示されている方法では、リレーショナルデータモデルに従ったデータベースの長所と、それ以外のモデルに従ったデータベースの長所とを組み合せたデータベース構築が考慮されていない問題点があった。
【００１０】
本発明は上記問題点を解決するためになされたもので、リレーショナルデータモデルに従ったデータベース操作言語によってアクセスされるデータベースを、リレーショナルデータモデルに従ったデータベースと、それ以外のモデルに従ったデータベースとからなる構成とすることによって、高速なデータベースクエリ操作を実現する情報処理装置を提供することを目的とする。
【課題を解決するための手段】
【００１１】
上記目的を達成するために、本発明の情報処理装置は、第１のデータベースを管理する第１のデータベース管理手段と、第２のデータベースを管理する第２のデータベース管理手段と、リレーショナルデータベース操作要求の要素毎にＡＰＩ（Application Program Interface）を記憶する記憶手段と、リレーショナルデータベース操作要求を受信して、その受信されたリレーショナルデータベース操作要求に係るリレーションに基づいて、その操作要求を前記第１のデータベース管理手段、及び、前記第２のデータベース管理手段のいずれか一方へ送信するデータベース切替手段とを有し、前記第１のデータベースは、リレーショナルデータベースであり、前記第１のデータベース管理手段は、前記データベース切替手段から送信されたリレーショナルデータベース操作要求を受信し、その操作要求に従って前記第１のデータベースを操作し、前記第２のデータベース管理手段は、前記データベース切替手段から送信されたリレーショナルデータベース操作要求を受信し、その操作要求を要素に分解し、前記記憶手段に記憶されたその分解された要素のＡＰＩを呼び出すことによって、前記リレーショナルデータベース操作要求に従った前記第２のデータベースの操作を行うことを特徴とする。
【発明の効果】
【００１２】
本発明によれば、リレーショナルデータモデルに従ったデータベース操作言語によってアクセスされるデータベースを、リレーショナルデータモデルに従ったデータベースと、それ以外のモデルに従ったデータベースとからなる構成とすることによって、高速なデータベースクエリ操作を実現することができる。
【図面の簡単な説明】
【００１３】
【図１】本発明の実施形態に係る移動通信装置の構成を示すブロック図。
【図２】本発明の実施形態に係る移動通信装置のデータベース管理部の詳細な構成を示すブロック図。
【図３】本発明の実施形態に係る移動通信装置のデータベース管理部の動作の詳細を示すフローチャート。
【図４】本発明の実施形態に係る変換テーブルの第１の例。
【図５】本発明の実施形態に係る変換テーブルの第２の例。
【発明を実施するための形態】
【００１４】
以下に、本発明の実施形態に係る情報処理装置が適用された移動通信装置の実施の形態を、図面を参照して説明する。図１は、本発明の実施形態に係る移動通信装置の構成を示すブロック図である。この移動通信装置は、装置全体の制御を行う制御部１１と、移動通信網の基地局（図示せず）との間で電波の送受信を行うアンテナ１２ａと、通信部１２ｂと、送受信部１３と、通話用のスピーカ１４ａと、通話用のマイクロフォン１４ｂと、通話部１４ｃと、表示部１５と、入力部１６と、アプリケーション群１７と、データベース管理部２０とからなる。
【００１５】
図２は、データベース管理部２０の詳細な構成を示すブロック図である。データベース管理部２０は、アプリケーション群１７と接続されるデータベース切替部２１と、リレーショナルデータベース管理部２２と、インデックス付きレコードデータ管理部２３とからなる。リレーショナルデータベース管理部２２は、データベース切替部２１と接続されるリレーショナルデータベース操作部２４と、リレーショナルデータベース２５とからなる。インデックス付きレコードデータ管理部２３は、データベース切替部２１と接続されるデータベース操作変換部２６と、変換テーブル２７と、インデックス付きレコードデータ２８とからなる。
【００１６】
上記のように構成された、本発明の実施形態に係る情報処理装置の各部の動作を、図１及び図２を参照して説明する。
【００１７】
通信部１２ｂは、アンテナ１２ａが受信した高周波信号を送受信部１３へ出力し、また、送受信部１３から出力される高周波信号をアンテナ１２ａより送信する。
【００１８】
送受信部１３は、通信部１２ｂからの高周波信号を増幅、周波数変換及び復調し、それによって得られたディジタル音声信号を通話部１４ｃへ、また、制御信号を制御部１１に送る。更には、通話部１４ｃから出力されるディジタル音声信号、及び制御部１１から出力される制御信号を変調、周波数変換及び増幅し、高周波信号を得て、それを通信部１２ｂに送る。
【００１９】
通話部１４ｃは、送受信部１３から出力されるディジタル音声信号をアナログ音声信号に変換し、それを増幅してスピーカ１４ａに送る。また、マイクロフォン１４ｂから出力されるアナログ音声信号を増幅し、それをディジタル音声信号に変換して送受信部１３に送信する。
【００２０】
表示部１５は、使用者に操作を促す表示や、使用者が操作した内容の表示や、装置の動作状態の表示などに用いられるバックライト付きのＬＣＤ（Liquid Crystal Display）であり、制御部１１に制御されることで、カーソルを含む文字・数字を含む画像データの表示動作を行い、表示されているデータは、入力部１６からの入力操作や着信信号に応答して制御部１１からの指示を受けることで切換わる。
【００２１】
入力部１６は、通信相手の電話番号などを指定し、また、トグル式の入力方式によってひらがな文字、アルファベット文字及び記号文字を入力するための数字キーと、カーソル移動キーやスクロールキーを含む複数の機能キーとを含むキーからなる。そして、入力部１６のキーが押下されると、そのキーの識別子を制御部１１に通知する。
【００２２】
アプリケーション群１７は、データベース管理部２０に含まれるデータベースをＳＱＬによる記述によって操作する１つ又は複数のアプリケーションである。アプリケーション群１７に如何なるアプリケーションが含まれるかは、本発明の実施に影響を及ぼさないが、例えば、アドレス帳管理部、予定表管理部、電子メール管理部などである。これらのアプリケーションは、入力部１６の所定のキー操作に従って、ＳＱＬによって記述されたデータベース操作をデータベース管理部２０に要求する。その要求が、例えばクエリ操作であって、データベース管理部２０から要求に対して検索されたデータが得られる場合、そのデータに基づく表示を表示部１５にさせる。
【００２３】
データベース管理部２０は、ＳＱＬによって記述されたデータベース操作要求に従って、データベース管理部２０内のデータベースの操作を行う。そして、その操作の結果を回答する。回答の一例は、例えば、操作がクエリである場合、検索されたデータである。
【００２４】
データベース管理部２０の動作の詳細を、図３に示すフローチャートを参照して説明する。データベース管理部２０は、アプリケーション群１７から送信された、ＳＱＬによって記述されたデータベース操作要求を受信してデータベース管理動作を開始する（ステップＳ１０１）。
【００２５】
そして、まず、データベース切替部２１は、受信されたＳＱＬによって記述されたデータベース操作要求によって操作されるリレーションの名称がデータベース切替部２１内に記憶されたリレーションの名称と一致するか否かを調べる（ステップＳ１０２）。そして、一致しない場合、そのデータベース操作要求はリレーショナルデータベース管理部２２によって処理されると判断して、その要求をリレーショナルデータベース操作部２４に送る。
【００２６】
リレーショナルデータベース操作部２４は、リレーショナルデータベース２５に対して、受信されたＳＱＬによって記述されたデータベース操作を行い（ステップＳ１０３）、その操作によって得られた回答を、データベース切替部２１は、データベース操作要求を送信したアプリケーション群１７に送信して（ステップＳ１０４）、データベース管理部２０は、データベース管理動作を終了する（ステップＳ１０５）。
【００２７】
ステップＳ１０３で、リレーショナルデータベース操作部２４は、ＳＱＬによって記述可能な全てのデータベース操作要求に対する処理が可能である。この処理の一環として、リレーショナルデータベース操作部２４は、ＳＱＬによって記述された要求のパース（構文解析）を行い、併せて、構文の誤り検出を行う。
【００２８】
そして、リレーショナルデータベース操作部２４は、パースの結果と、リレーショナルデータベース２５に含まれるインデックスなどの補助データの有無を参照して、リレーショナルデータベース２５を操作する。ここで、ＳＱＬによって記述された要求がクエリである場合、リレーショナルデータベース２５に含まれる補助データを利用した最適化処理、即ち、最も高速と判断される処理手順の選択を伴う。
【００２９】
一方、ステップＳ１０２で一致する場合、データベース切替部２１は、そのデータベース操作要求はインデックス付きレコードデータ管理部２３によって処理されると判断して、その要求をデータベース操作変換部２６に送る。
【００３０】
データベース操作変換部２６は、ＳＱＬによって記述されたデータベース操作要求を受信して、その操作要求を要素に分解し、分解された要素を変換テーブル２７を参照することによって、インデックス付きレコードデータ２８を操作するＡＰＩと、優先度との組に変換し（ステップＳ１０６）、優先度が高い組のＡＰＩから、低い組のＡＰＩへと、順にＡＰＩを呼ぶことによってインデックス付きレコードデータ２８を操作する（ステップＳ１０７）。
【００３１】
データベース操作変換部２６は、上記操作によって得られた結果をリレーショナルデータベース操作部２４がリレーショナルデータベース２５を操作して得る回答の形式に変換し（ステップＳ１０８）、データベース切替部２１は、その変換によって得られた回答をデータベース操作要求を送信したアプリケーション群１７に送信して（ステップＳ１０４）、データベース管理部２０は、データベース管理動作を終了する（ステップＳ１０５）。
【００３２】
ここで、データベース操作変換部２６は、データベース切替部２１によって選択されたリレーションに対する操作のみを行う。そこで、処理する操作には限りがあるため、例えば、その操作のパースは限られた処理である。更には、アプリケーション群１７が操作記述に所定の区切り記号を含ませる、例えば、空白文字や、改行文字の使い方に制約を設けることによって、パースは更に限られた処理となる。
【００３３】
また、インデックス付きレコードデータ２８の操作は、変換テーブル２７に記憶されたＡＰＩを介して行うことによって最も高速な処理が可能であるので、データベース操作変換部２６は、それ以外の最適化処理は行わない。
【００３４】
上記のように構成された、本発明の実施形態に係る情報処理装置において、如何なるＳＱＬによって記述されたデータベース操作要求が、如何にインデックス付きレコードデータ管理部２３によって処理されるかを説明する。なお、リレーショナルデータベース操作部２４は、周知のように、ＳＱＬによって記述可能な全てのデータベース操作要求を処理するので、処理の詳細の説明を省略する。
【００３５】
（第１の例）
以下の（式１）〜（式４）は、インデックス付きレコードデータ管理部２３によって処理されるデータベース操作要求の例を示す。この要求は、ＳＱＬによって記述されるが、理解を容易にするため、必ずしもＳＱＬの文法に従うことなく、要点を示す。
【００３６】
ＳＥＬＥＣＴ 要求属性 ＦＲＯＭ Ｒ１
ＷＨＥＲＥ 条件１ ＯＲＤＥＲ ＢＹ ソート属性 （式１）
ＳＥＬＥＣＴ 要求属性 ＦＲＯＭ Ｒ１
ＷＨＥＲＥ 条件２ ＯＲＤＥＲ ＢＹ ソート属性 （式２）
ＳＥＬＥＣＴ 要求属性 ＦＲＯＭ Ｒ１
ＷＨＥＲＥ 条件１ ＡＮＤ 条件２ ＯＲＤＥＲ ＢＹ ソート属性 （式３）
ＳＥＬＥＣＴ 要求属性 ＦＲＯＭ Ｒ１
ＷＨＥＲＥ 条件１ ＯＲ 条件２ ＯＲＤＥＲ ＢＹ ソート属性 （式４）
【００３７】
ここで、Ｒ１はリレーション名、条件１はＡ１＝Ｖ１、条件２はＡ２＝Ｖ２（Ａ１、Ａ２は、Ｒ１の属性名。）、Ｖ１、Ｖ２は値である。また、要求属性はＲ１の属性名、ソート属性はＲ１の属性名と、ソート順（昇順か、降順か。）である。
【００３８】
図４は、この（式１）〜（式４）で示された要求を処理するための変換テーブル２７の第１の例を示す。変換テーブル２７は、操作要求の要素２７ａと、ＡＰＩ２７ｂと、優先度２７ｃとが関連付けられている。ここで、操作要求の要素２７ａは、ＳＱＬによって記述されたデータベース操作要求の要素であって、図４に示すように、リレーション名、条件などである。ＡＰＩ２７ｂは、操作要求の要素２７ａを処理するためにインデックス付きレコードデータ２８を操作するＡＰＩである。優先度２７ｃは、ＡＰＩ２７ｂのいずれを先に呼び出すかを示し、高い場合先に、低い場合後に呼び出すことを示す。
【００３９】
（式１）が、変換テーブル２７を参照しつつデータベース操作変換部２６によって処理される手順を説明する。まず、操作対象のリレーション名が「Ｒ１」なので、操作要求の要素２７ａが「Ｒ１」である変換テーブル２７を検索する。その検索の結果、そのリレーションに関する操作は、ＡＰＩ２７ｂが示す「機能ＡＰＩ＿Ｒ１（）」を介して行うので、このＡＰＩを呼び出す。ここで、このＡＰＩ２７ｂによって呼び出される機能は、リレーション「Ｒ１」が如何にインデックス付きレコードデータ２８にマッピングされているかに従って作成されている。例えば、その属性のいずれについてインデックスが付いているかなどに完全に依存して作られているので、最適化の動作は不要である。
【００４０】
次に、データベース操作要求の要素として「条件１」が取り出され、操作要求の要素２７ａが「Ｒ１＿Ａ１＝Ｖ１」である変換テーブル２７を検索する。ここで、「Ｒ１＿Ａ１＝Ｖ１」は、条件１である「Ａ１＝Ｖ１」と比較して、Ａ１がＲ１の属性であることを示すため、「Ａ１」の前に「Ｒ１＿」が付加されている。その検索の結果、この条件の検索は、ＡＰＩ２７ｂが示す「機能ＡＰＩ＿Ｒ１＿Ａ１（）」を介して行うので、このＡＰＩを呼び出すことによって、「条件１」の検索が行われる。
【００４１】
検索の後、（式１）の要求属性が選択され、ソート属性に従ってソートされる。これは、要求属性及びソート属性が事前に定められていれば、検索の一環として行われる。それらが事前に定められていない場合、それらを操作要求の要素２７ａとする変換テーブル２７のＡＰＩ２７ｂを介して行われる。
【００４２】
（式２）は、（式１）と比較して、「条件１」に代えて「条件２」である。そこで、上述した（式１）の処理の「機能ＡＰＩ＿Ｒ１＿Ａ１（）」に代えて「機能ＡＰＩ＿Ｒ１＿Ａ２（）」が用いられる。ここで、これらの２つのＡＰＩを介して呼び出されるプログラムの内容は異なっていることがある。例えば、属性「Ａ１」や、属性「Ａ２」にインデックスが付けられているか否かによって、プログラムは大きく異なる。
【００４３】
（式３）は、（式１）と比較して、「条件１」に代えて「条件１ ＡＮＤ 条件２」である。そこで、「機能ＡＰＩ＿Ｒ１＿Ａ１（）」及び「機能ＡＰＩ＿Ｒ１＿Ａ２（）」の２つのＡＰＩを介して検索が行われる。ただし、前者に関連付けられた優先度２７ｃが「高」で、後者に関連付けられた優先度２７ｃが「低」であるので、まず、前者を介した検索を行い、次に、後者を介した検索が行われる。
【００４４】
この優先度２７ｃの高低は、属性「Ａ１」に係わる検索は、属性「Ａ２」に係わる検索より高速に処理されることに基づいている。その理由は、属性「Ａ１」にはインデックスが付されているが、属性「Ａ２」にはインデックスが付されていない、属性「Ａ１」の値は整数であって、属性「Ａ２」の値は文字列や、浮動小数点数である、属性「Ａ１」の値は４バイトの文字列であって、属性「Ａ２」の値は可変長の文字列である、属性「Ａ１」の値は整数であって、属性「Ａ２」の値は画像であるなどであって、ＣＰＵの能力に依存する。
【００４５】
なお、属性「Ａ１」と、属性「Ａ２」とが上記のいずれかに該当する場合であっても、機械的に上記の優先度２７ｃとなる訳ではない。変換テーブル２７は、ＣＰＵの能力に加え、アプリケーション群１７が如何なるクエリ要求を行うか、また、インデックス付きレコードデータ２８に記憶される値の分布を熟知している設計者によって設計され、最適な処理が行われるように設定される。例えば、ある属性を用いた検索によって得られるデータの件数が極めて少数である場合、その属性に関連付けられた優先度２７ｃは高くなる。
【００４６】
（式４）は、（式３）と比較して、条件の「ＡＮＤ」に代えて「ＯＲ」である。そこで、リレーション名が「Ｒ１」でり、ＯＲの検索である場合のデータベース操作要求の要素として「Ｒ１＿ＯＲ」が取り出され、操作要求の要素２７ａが「Ｒ１＿ＯＲ」である変換テーブル２７を検索する。その検索の結果、この条件の検索は、ＡＰＩ２７ｂが示す「機能ＡＰＩ＿Ｒ１＿ＳＥＱ（）」を介して行うので、このＡＰＩを呼び出すことによって、（式４）の検索が行われる。
【００４７】
ここで、この「機能ＡＰＩ＿Ｒ１＿ＳＥＱ（）」は、リレーション「Ｒ１」マッピングされているインデックス付きレコードデータ２８をシーケンシャルにアクセスするＡＰＩである。属性「Ａ１」や、属性「Ａ２」にインデックスが付けられているか否かに係わらず、「Ｒ１＿ＯＲ」を含む検索は、シーケンシャルアクセスによることが示されている。
【００４８】
これは、例えば、属性「Ａ１」や、属性「Ａ２」の値の分布に依存して、たとえ、インデックスが付されていても、用いないことによって一層高速な処理が可能な場合に対応する。即ち、変換テーブル２７は、インデックス付きレコードデータ２８に記憶される値の分布を熟知している設計者によって設計されるので、クエリ時の最適化処理を行うことなく最適な処理が可能である。一方、リレーショナルデータベース操作部２４は、値の分布に依存した最適化処理が最適でない可能性がある。
【００４９】
（第２の例）
図５は、上記（式１）〜（式４）で示された要求を処理するための変換テーブル２７の第２の例を示す。この例は、図４に示す第２の例と比較して、「機能ＡＰＩ＿Ｒ１（）」なるＡＰＩ２７ｂに代えて、「機能ＡＰＩ＿Ｒ１１（）、機能ＡＰＩ＿Ｒ１２（）」と記憶され、リレーション「Ｒ１」に関する操作は、２つのＡＰＩを介して行うことが示されている。これは、リレーション「Ｒ１」は、２つのインデックス付きレコードデータ２８、「Ｒ１１」と、「Ｒ１２」とからなることを示している。
【００５０】
また、「機能ＡＰＩ＿Ｒ１＿Ａ１（）」なるＡＰＩ２７ｂと、「機能ＡＰＩ＿Ｒ１＿Ａ２（）」なるＡＰＩ２７ｂに代えて、それぞれ「機能ＡＰＩ＿Ｒ１１＿Ａ１（）」、「機能ＡＰＩ＿Ｒ１２＿Ａ２（）」と記憶され、属性「Ａ１」は、「Ｒ１１」なるインデックス付きレコードデータ２８に、属性「Ａ２」は、「Ｒ１２」なるインデックス付きレコードデータ２８に記憶されていることを示す。
【００５１】
このように、アプリケーション群１７から送信されるデータベース操作記述によれば、１つのリレーション「Ｒ１」に対する操作であるが、データベース操作変換部２６による変換を経ると、２つのインデックス付きレコードデータ２８に対する操作となることは、ＳＱＬのジョイン操作の高速化に相当する。
【００５２】
即ち、２つのリレーションのジョインを経て行われるクエリにおいて、ジョインは、理解が容易なデータベース操作であるが、その実行には比較的長時間を要する。特に、ジョイン操作で指定される２つのリレーションの属性によっては、長時間を要する。例えば、それらの属性にインデックスが付されていない場合、それらの属性の値が可変長の文字列である場合などである。
【００５３】
このように、長時間を要する場合であっても、ジョインの前に、例えば、ジョインされるリレーションの中の特定の一方（図５に示す例では、属性「Ａ１」が含まれる、「Ｒ１１」なるインデックス付きレコードデータ２８。）に対する検索を行うことによって、得られるデータの件数が極くわずかな件数になる場合、上記２つのリレーションは、リレーショナルデータベース管理部２２によって管理されるより、インデックス付きレコードデータ管理部２３によって管理される方が高速な処理がされることがある。なお、この場合も、変換テーブル２７は、インデックス付きレコードデータ２８に記憶される値や、それに対して行われる操作を熟知している設計者によって設計されることが必要である。
【００５４】
また、リレーション「Ｒ１」を２つのインデックス付きレコードデータ２８、「Ｒ１１」と、「Ｒ１２」とに分けることは、そのリレーションの属性の値によって、データを二分し、それぞれを異なるインデックス付きレコードデータ２８として記憶させることにも用いられる。例えば、二分された一方の上記属性以外の属性の値が可変長のビット列であり、他方は、その値がない（ＮＵＬＬ値である。）場合、異なるインデックス付きレコードデータ２８とすることにより、高速な処理と、記憶容量の有効利用が可能である。
【００５５】
以上の説明は、処理速度が最も重視されるクエリ操作を例に行ったが、これ以外の操作、データの追加、変更、及び削除についても同様である。
【００５６】
以上の説明で、操作要求の要素２７ａとして記憶される条件は、属性名、比較演算子、及び値からなるとしたが、これに限るものではない。属性名、及び比較演算子からなるとしても良く、また、属性名からなるとしても良い。それぞれの場合、操作要求の要素２７ａとして記憶されない部分は、ＡＰＩ２７ｂが示すＡＰＩへ伝えられ、そのＡＰＩが伝えられた情報に従ってデータベースを操作する。
【００５７】
以上の説明で、データベース切替部２１は、データベース切替部２１内に記憶されたリレーションの名称を参照することによって、ＳＱＬによって記述されたデータベース操作要求がリレーショナルデータベース管理部２２によって処理されるか、インデックス付きレコードデータ管理部２３によって処理されるかを判断するとしたが、これに限るものではない。クエリの条件も参照して判断しても良い。この処理によれば、クエリの条件に従って、より高速な処理が可能な管理部を選択することができる。
【００５８】
なお、クエリの条件も参照して判断する処理においては、データベース切替部２１は、変換テーブル２７の操作要求の要素２７ａとして操作の要素が記憶されているクエリは、インデックス付きレコードデータ管理部２３によって処理されると判断しても良い。ただし、上記の処理による場合、同じリレーションをリレーショナルデータベース管理部２２と、インデックス付きレコードデータ管理部２３の双方に分割して、又は、二重に記憶させ、管理させることが必要になる。
【００５９】
以上の説明で、データベース管理部２０は、リレーショナルデータベース管理部２２に加えて、インデックス付きレコードデータ２８を管理するインデックス付きレコードデータ管理部２３からなるとしたが、これに限るものではない。即ち、データベース管理部２０は、リレーショナルデータベース管理部２２に加えて、リレーショナルデータモデルに基づかずに構築された任意のデータベースを管理する管理部を備えることによって、本発明は実施可能である。
【００６０】
リレーショナルデータモデルに基づかないデータベースには、ネットワーク型データモデルによるデータベース、木構造型データモデルによるデータベース、インデックス付きレコードデータ、ランダムアクセスデータ、ハッシングされたデータなどがある。
【００６１】
以上の説明は、本発明を移動通信装置に適用した形態を例にとって行ったが、これに限るものではない。本発明は、あらゆる情報処理装置に適用することが当然に可能である。本発明は以上の構成に限定されるものではなく、種々の変形が可能である。
【符号の説明】
【００６２】
１７ アプリケーション群
２０ データベース管理部
２１ データベース切替部
２２ リレーショナルデータベース管理部
２３ インデックス付きレコードデータ管理部
２４ リレーショナルデータベース操作部
２５ リレーショナルデータベース
２６ データベース操作変換部
２７ 変換テーブル
２７ａ 操作要求の要素
２７ｂ ＡＰＩ
２７ｃ 優先度
２８ インデックス付きレコードデータ
【特許請求の範囲】
【請求項１】
第１のデータベースを管理する第１のデータベース管理手段と、
第２のデータベースを管理する第２のデータベース管理手段と、
リレーショナルデータベース操作要求の要素毎にＡＰＩ（Application Program Interface）を記憶する記憶手段と、
リレーショナルデータベース操作要求を受信して、その受信されたリレーショナルデータベース操作要求に係るリレーションに基づいて、その操作要求を前記第１のデータベース管理手段、及び、前記第２のデータベース管理手段のいずれか一方へ送信するデータベース切替手段とを有し、
前記第１のデータベースは、リレーショナルデータベースであり、
前記第１のデータベース管理手段は、前記データベース切替手段から送信されたリレーショナルデータベース操作要求を受信し、その操作要求に従って前記第１のデータベースを操作し、
前記第２のデータベース管理手段は、前記データベース切替手段から送信されたリレーショナルデータベース操作要求を受信し、その操作要求を要素に分解し、前記記憶手段に記憶されたその分解された要素のＡＰＩを呼び出すことによって、前記リレーショナルデータベース操作要求に従った前記第２のデータベースの操作を行う
ことを特徴とする情報処理装置。
【請求項２】
前記リレーショナルデータベース操作要求の要素は、そのリレーショナルデータベース操作要求に含まれるリレーションである
ことを特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記リレーショナルデータベース操作要求は、リレーショナルデータベースに対するクエリである
ことを特徴とする請求項１に記載の情報処理装置。
【請求項４】
前記リレーショナルデータベース操作要求の要素は、前記クエリに含まれる検索条件である
ことを特徴とする請求項３に記載の情報処理装置。
【請求項５】
前記検索条件は、リレーションの属性と、比較演算子と、値とからなる
ことを特徴とする請求項４に記載の情報処理装置。
【請求項６】
前記記憶手段は、更に、前記検索条件のＡＰＩ毎に優先度を記憶し、
前記第２のデータベース管理手段は、前記リレーショナルデータベース操作要求の要素として複数の前記検索条件を含む場合、それらの検索条件のＡＰＩの中で、前記優先度が高いＡＰＩを先に呼び出す
ことを特徴とする請求項４に記載の情報処理装置。
【請求項１】
第１のデータベースを管理する第１のデータベース管理手段と、
第２のデータベースを管理する第２のデータベース管理手段と、
リレーショナルデータベース操作要求の要素毎にＡＰＩ（Application Program Interface）を記憶する記憶手段と、
リレーショナルデータベース操作要求を受信して、その受信されたリレーショナルデータベース操作要求に係るリレーションに基づいて、その操作要求を前記第１のデータベース管理手段、及び、前記第２のデータベース管理手段のいずれか一方へ送信するデータベース切替手段とを有し、
前記第１のデータベースは、リレーショナルデータベースであり、
前記第１のデータベース管理手段は、前記データベース切替手段から送信されたリレーショナルデータベース操作要求を受信し、その操作要求に従って前記第１のデータベースを操作し、
前記第２のデータベース管理手段は、前記データベース切替手段から送信されたリレーショナルデータベース操作要求を受信し、その操作要求を要素に分解し、前記記憶手段に記憶されたその分解された要素のＡＰＩを呼び出すことによって、前記リレーショナルデータベース操作要求に従った前記第２のデータベースの操作を行う
ことを特徴とする情報処理装置。
【請求項２】
前記リレーショナルデータベース操作要求の要素は、そのリレーショナルデータベース操作要求に含まれるリレーションである
ことを特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記リレーショナルデータベース操作要求は、リレーショナルデータベースに対するクエリである
ことを特徴とする請求項１に記載の情報処理装置。
【請求項４】
前記リレーショナルデータベース操作要求の要素は、前記クエリに含まれる検索条件である
ことを特徴とする請求項３に記載の情報処理装置。
【請求項５】
前記検索条件は、リレーションの属性と、比較演算子と、値とからなる
ことを特徴とする請求項４に記載の情報処理装置。
【請求項６】
前記記憶手段は、更に、前記検索条件のＡＰＩ毎に優先度を記憶し、
前記第２のデータベース管理手段は、前記リレーショナルデータベース操作要求の要素として複数の前記検索条件を含む場合、それらの検索条件のＡＰＩの中で、前記優先度が高いＡＰＩを先に呼び出す
ことを特徴とする請求項４に記載の情報処理装置。
【図１】
【図２】
【図３】
【図４】
【図５】
【図２】
【図３】
【図４】
【図５】
【公開番号】特開２０１０−２２４８２４（Ｐ２０１０−２２４８２４Ａ）
【公開日】平成２２年１０月７日（２０１０．１０．７）
【国際特許分類】
【出願番号】特願２００９−７０８２１（Ｐ２００９−７０８２１）
【出願日】平成２１年３月２３日（２００９．３．２３）
【出願人】（０００００３０７８）株式会社東芝 (54,554)
【Ｆターム（参考）】
【公開日】平成２２年１０月７日（２０１０．１０．７）
【国際特許分類】
【出願日】平成２１年３月２３日（２００９．３．２３）
【出願人】（０００００３０７８）株式会社東芝 (54,554)
【Ｆターム（参考）】
[ Back to top ]