JP5075653B2 - データベース管理方法、データベース管理装置、データベース管理プログラム、及び、データベースシステム - Google Patents

Description

本発明は、インデクスを利用して検索可能なデータベースを管理する技術に関する。

カーナビゲーションシステム又は携帯端末をはじめとする組み込み機器において、これらの組み込み機器によって扱われる情報量は日々増加してきている。さらに、エンドユーザには、これらの情報を常時快適に利用することが望まれている。また、組み込み機器の利便性を考慮すると、機器そのものの大きさは極力小さいことがエンドユーザとしては望ましい。

組み込み機器開発において、データ処理モジュールを個別に開発していたのでは、継続的にエンドユーザの要望を満たし続けることは非常に難しい。そのため、多くのエンタープライズシステムがデータ処理をデータベース管理システム（ＤａｔａＢａｓｅ Ｍａｎａｇｅｍｅｎｔ Ｓｙｓｔｅｍ：ＤＢＭＳ）を用いて実現するのと同様に、組み込み機器においてもデータ操作機能を容易かつ高速に実装するためにデータ管理基盤としてＤＢＭＳを利用するようになってきている。

さらに、組み込み機器上で動作し、種々の機能をエンドユーザに提供するためのアプリケーションプログラムを開発する開発者をより多くしかも容易に確保するためには、二次元の表形式のデータモデル及びデータ操作要求としてＳＱＬを用いることが望ましい。二次元の表形式では、１つのデータは複数の「列」と呼ぶデータフィールド（属性）を含み、「行」と呼んでいる。また、複数の「行」の集まりを「表」として表現する。そして、「表」に含まれるデータを操作するための問合せ言語がＳＱＬである。

ここで、組み込み機器上で使用されるＤＢＭＳに期待される要件は、組み込み機器の装置としての利便性（コンパクトであること）を考慮すると、主に以下の２つである。
１．データ検索機能をはじめとするデータ操作機能を高速に、かつ、低フットプリント（ＣＰＵ利用率が低い）で実現すること。
２．機器に搭載されている記憶領域に対してできるだけ多くのデータ量を記憶すること。

また、組み込み機器ではエンドユーザに対し、さまざまな観点のデータ操作サービスを提供することが望まれる。例えば、カーナビゲーションシステムでは、行き先を探すために住所、電話番号、施設名、施設分類（ジャンル）などの複数の観点からキーワードを指定して行き先を特定するようエンドユーザ入力指示させることが多くなっている。

キーワードを指定してデータベースに対して効率的に全文検索を行う技術には、さまざまな技術が開示されている。例えば、特許文献１には、格納データ本体とは別に全文検索用のインデクスを保持し、検索要求に対して当該インデクスを使用して、エンドユーザが指定したキーワードに対する条件を満たすデータを高速に特定可能な技術が記載されている。ここで述べているデータ本体は、先に説明した表形式のデータモデルにて行として実現される。行を実現する具体的なデータ構造については、非特許文献１に記載されている（非特許文献２は非特許文献１の日本語訳）。
特開２００７−２９９０２１号公報 Jim Gray and Andreas Reuter、Transaction Processing: Concepts and Techniques、Morgan Kaufmann Publishers、1993、p.772-784 ジム グレイ（著）、アンドレアス ロイター（著）、喜連川 優（翻訳）、「トランザクション処理〈下〉―概念と技法」、日経BP社、2001年10月、p.912-925

前述したように、カーナビゲーションシステムなどにおける組み込み向けデータベース管理システム（ＤＢＭＳ）の適用分野での要件は、データ容量を小さくし、高速に検索可能であることである。エンドユーザは関心のあるキーワードを入力し、当該キーワードに関連する情報（例えば「施設」）をキーワード検索する。ただし、データベースの表は、複数の表に関連情報が分散して格納管理されている場合が多いため、データの容量は抑えられているが、検索対象である列（住所、施設名など）が複数の表にまたがって格納されている場合が多い。

しかし、表ごとにカテゴリが分割され、かつ、カテゴリを問わない検索（横串検索）を実行したい場合には、ある列に検索対象のデータをまとめ、当該列に対して全文検索インデクスを定義するのが１つの実現方法として挙げられる。この場合には、検索対象の列にデータを重複して保持することになり、データベースの容量が増大するという問題がある。近年、メモリが大容量かつ安価で入手可能になったが、必要なデータ量は急激に増加するため、データ記憶容量の問題は依然として重要である。データを記憶するために必要なメモリ量を削減すれば、削減された分の領域にさらに新たなデータを記憶し、使用することが可能となるのである。

本発明は、このような背景に鑑みてなされたものであり、表データとして記憶又は格納されるデータベース容量を少なくする技術を提供することを目的とする。

本発明の代表的な一形態は、複数行と複数列とで表現される表データと前記複数列に含まれる列に対応づけられたインデクスとを含むデータベース、を格納する記憶部を備え、前記データベースを管理する、データベース管理装置、によるデータベース管理方法であって、前記複数列は、列データが格納されないインデクス専用列と、列データが格納される非インデクス専用列とを含み、前記データベース管理装置は、前記複数列に含まれる列と前記インデクスとの対応付けを定義するインデクス定義情報を有し、前記インデクス定義情報は、前記インデクス専用列と全文検索用インデクスとの対応付けを定義し、前記データベース管理装置が、前記表データへのデータ登録要求を受け付け、前記データ登録要求が前記非インデクス専用列に対応する第１登録対象データの登録を要求する場合に、前記データベース管理装置が、前記非インデクス専用列に前記第１登録対象データを登録し、前記データ登録要求が前記インデクス専用列に対応する第２登録対象データの登録を要求する場合に、前記データベース管理装置が、前記第２登録対象データを前記インデクス専用列に登録することなく、前記インデクス定義情報を参照して前記全文検索用インデクスを特定して、前記全文検索用インデクスを、前記第２登録対象データを用いて更新し、前記データベース管理装置が、前記インデクス専用列に対する検索条件を含む検索要求を受け付けた場合に、前記インデクス定義情報を参照して前記全文検索用インデクスを特定し、前記全文検索用インデクスを使用して検索を行い、前記非インデクス専用列に対する検索条件を含む検索要求を受け付けた場合に、前記インデクス定義情報を参照してインデクスの使用の有無を決定する。

本発明の一形態によれば、表データとして記憶又は格納される容量を削減することができる。

以下、本発明の実施の形態について、適宜図面を参照しながら詳細に説明する。

図１は、本実施の形態の全体概要を説明する図である。

本実施の形態のデータベース管理装置におけるデータベース管理方法では、前述したように、データを表形式の行とし、データに含まれるフィールド（属性）を列として格納している。ここで、キーワード検索を実行するためのデータを関連付ける列を「インデクス専用列」として定義する。インデクス専用列として定義された列データ（値ともいう）は、表データとしてデータベースに記憶されず、インデクス専用列に対して定義されたインデクスに列データが保持される。

図１には、INSHOKU2表（２１１）においてALL_KANA_NAME列がインデクス専用列として定義されており、INSHOKU2表の表データの格納（記憶）イメージを示している。インデクス専用列として定義されていないSID列、TEL_NO列、SHOP_CODE列、及びAREA_CODE列は、行データを構成する列データとして記憶されている。例えば、一番目の行についてはデータ（値ともいう）「113」、「045-877-6637」、「765」、及び「002」が記憶されている。

一方、インデクス専用列として定義されているALL_KANA_NAME列は、列データとしてのデータ「とつかえき えき よこはましとつかくとつか」を記憶しない。列データは、インデクスIDX_ALLKANA（２１２）内のみに保持される。データ「とつかえき えき よこはましとつかくとつか」は、SHISETSU表の施設よみ列、JANRU表のジャンルよみ列、JUSHO表の住所よみ列のそれぞれの列データからアプリケーションプログラムがINSHOKU2表のALL_KANA_NAME列のデータとしてINSHOKU2表へのデータ登録時に登録データの一部として生成されたものである。ALL_KANA_NAME列に含められる情報は、本データベース管理装置を利用する利用者の求めに応じて決定される。「よみ」とは、漢字の読み方を示すものであり、本例では表音文字として平仮名を利用している。「横浜市」のよみは「よこはまし」と表すことになる。

ここで、エンドユーザがキーワード「よこはまし」を指定して検索項目（施設名、ジャンル名、住所）を限定せずに検索する場合について説明する。この場合、検索サービスを提供するアプリケーションプログラムは、以下に示すＳＱＬ文を用いた検索要求をデータベース管理システムに送信する。以下に示すＳＱＬ文の具体的な検索要求内容は、「“よこはまし”を含むデータのＳＩＤ（施設ＩＤ）を取得」することである。
SELECT “SID” FROM “INSHOKU2” WHERE CONTAINS(“ALL_KANA_NAME”,“よこはまし”)

検索要求を受信したデータベース管理システムは、インデクス２１２にアクセスして検索条件（“よこはまし”を含む）に合致する行データを特定し、さらに特定された行データにアクセスし、要求データであるSID列のデータを検索結果として要求元であるアプリケーションプログラムに返却する。検索結果を返却されたアプリケーションプログラムは、検索結果であるデータを加工し、エンドユーザに対してサービス実行結果を提示する。

以上のように、従来の列データを記憶する場合と比較して、キーワードを指定して検索する対象である列の列データが表データとして記憶されていないため、データベース容量を最小限に抑えることができる。また、従来では複数の表に分散して情報を記憶していたために、アプリケーションプログラムでこれら複数の表に検索を要求し、検索結果をマージする処理が必要であったが、本発明の実施の形態のように１つの表のインデクス専用列に対する検索要求で実現することができる。このように、アプリケーションプログラムの開発工数の削減を図ることができ、結果として性能を向上させることができる。

図２は、本発明の実施の形態のデータベース管理装置の構成の一例を示すブロック図である。

データベース管理装置１は、入力部５００、出力部６００、ＣＰＵ（Central Processing Unit）７００、メモリ８００、第１の記憶部２００及び第２の記憶部３００を含む。入力部５００、出力部６００、ＣＰＵ７００、メモリ８００、第１の記憶部２００及び第２の記憶部３００は、内部バスで接続されている。

入力部５００は、外部からの処理要求を受け付ける。出力部６００は、アプリケーションプログラム４００の出力結果を表示する。アプリケーションプログラム４００の出力結果は、例えば、データベース管理システム１００で処理され、さらに、アプリケーションプログラム４００によってさらに加工された情報である。出力部６００は、例えば、液晶ディスプレイである。

ＣＰＵ７００は、メモリ８００に記憶されたプログラムを実行する。メモリ８００は、ＣＰＵ７００によって実行されるプログラム及び処理に必要なデータを記憶する。メモリ８００に記憶されるプログラムは、具体的には、アプリケーションプログラム４００及びデータベース管理システム１００である。

アプリケーションプログラム４００は、ＣＰＵ７００に実行されることによって、所定の業務処理を実行する。アプリケーションプログラム４００は、さらに、データ操作要求部４１０及びインデクス専用列データ生成部４２０を備える。

データ操作要求部４１０は、後述するデータベース管理システム１００に対し、データベースに記憶されているデータに対する操作（データ検索（またはデータ参照やデータ読み出しともいう）、データ挿入（データ登録ともいう）、データ削除、データ更新）を要求する機能を有する。また、データ挿入もしくはデータ更新をデータ登録と言う場合もある。

インデクス専用列データ生成部４２０は、データ操作要求がデータ登録又はデータ更新である場合に、インデクス専用列に対する登録データ又は更新後のデータを生成する機能を有する。

インデクス専用列に対する登録データ又は更新後のデータは、例えば、登録対象のデータの属性を指定し、指定された属性に関連する値（もしくはデータ）を連結することによって生成する。具体的には、図１に示すように、ある施設について登録する場合に、施設の名称、ジャンル及び住所などを指定し、これらの情報の読み方を連結してもよい。

データベース管理システム１００は、概念的に表形式で表現されるデータの集まりである表データ２１１と当該表データを効率的にアクセスするための手段であるインデクス２１２を含むデータベース２１０を管理する機能を有する。データベース管理システム１００は、制御部１１０、定義情報管理部１２０、表データ管理部１３０、及び、インデクス管理部１４０を備える。

制御部１１０は、データベース管理システム１００全体を制御する。具体的には、アプリケーションプログラム４００などのプログラムから要求された表定義及びインデクス定義に従って、定義情報管理部１２０の制御を実行する。

さらに、制御部１１０は、アプリケーションプログラム４００のデータ操作要求部４１０からデータ操作が要求されると、適宜インデクス２１２を利用しながら、要求されたデータ操作を表データ２１１に対して実行する。詳細に説明すると、制御部１１０は、まず、アプリケーションプログラム４００のデータ操作要求部４１０から入力されたデータ操作要求（データ登録要求、データ削除要求、データ更新要求及びデータ検索要求）を解析する。次に、データベース２１０に対する操作（アクセス）のための適切な実行手順（どのインデクスを使用するかなどの決定）を生成し、当該実行手順に従って表データ管理部１３０にデータ操作を要求する。

また、制御部１１０は、データベース２１０に対する操作の実行結果データをデータ操作要求元であるアプリケーションプログラム４００に返却する機能も有する。

定義情報管理部１２０は、表データ２１１及びインデクス２１２などのデータベース２１０を構成する論理的なスキーマ構成及びテーブル情報などの各種定義情報を管理する。具体的には、表データ２１１に対応する定義情報として表定義情報３１０を、インデクス２１２に対応する定義情報としてインデクス定義情報３２０を生成し、記憶する。また、データ操作が要求された場合には、表データ管理部１３０又はインデクス管理部１４０からの要求に基づいて、記憶されている定義情報を提供する。定義情報管理部１２０は、制御部１１０からの表定義要求及びインデクス定義要求を受信して解析し、解析した結果を表定義情報３１０及びインデクス定義情報３２０として第２の記憶部３００に記憶する。

また、定義情報管理部１２０は、インデクス専用列解析部１２１を備える。インデクス専用列解析部１２１は、表定義要求又はインデクス定義要求にインデクス専用列が関係する場合に解析処理を実行する。

表データ管理部１３０は、第１の記憶部２００に記憶されているデータベース２１０の表データ２１１を管理する。具体的には、データ操作として表データ２１１に対するデータの登録、削除、更新及び検索を実行する。

表データ管理部１３０は、行データ作成部１３１、行データアクセス部１３２、及びインデクス専用列処理部１３３を備える。

行データ作成部１３１は、データ操作として表データ２１１に対してデータを登録又は更新する際に、データベース２１０に記憶する行データを作成する機能を有する。行データを作成するための列データがインデクス専用列に対応する場合は、インデクス専用列処理部１３３が対応する列データを処理する。具体的には、インデクス専用列の場合の列データには実際のデータを記憶せずに、インデクス専用列であることを示す情報を列データに関連した領域に記憶する。

行データアクセス部１３２は、データ操作として表データ２１１に対するデータの登録、削除、更新及び検索を実行する機能を有する。表データ２１１は、インデクス専用列に対応する列を含む。この場合、インデクス専用列処理部１３３がインデクス専用列にデータアクセスし、処理を実行する。

インデクス専用列処理部１３３は、インデクス専用列にデータアクセスする機能を有する。

インデクス管理部１４０は、第１の記憶部２００に記憶されているデータベース２１０のインデクス２１２を管理する。インデクス管理部１４０は、インデクスメンテナンス部１４１、及びインデクス検索部１４２を備える。

インデクスメンテナンス部１４１は、表データ管理部１３０から送信されたインデクスメンテナンス要求に基づいて、インデクスを実現するデータの更新及びインデクスの構造を変更する機能を有する。

インデクス検索部１４２は、表データ管理部１３０から送信されたインデクス検索要求に基づいて、インデクスを参照し、検索条件（キーワード検索）に合致する列データを有する行の行識別子を検索結果として取得する機能を有する。

第１の記憶部２００は、表データ２１１、及び、表データを効率的に検索するためのインデクス２１２をデータベース２１０として記憶する。第１の記憶部２００は、フラッシュメモリ又は磁気ディスクなどの記憶装置によって構成される。

第１の記憶部２００は、具体的には、アプリケーションプログラム４００のデータ操作要求部４１０によって生成された表データ２１１を記憶する。また、データベース管理システム１００のインデクス管理部１４０において作成されたインデクス２１２を記憶する。本実施の形態のメモリ８００に配置（インストール）した各処理部は、プログラムで実現することを想定しているがオブジェクトやハードウェアで実現することも可能である。本実施の形態のメモリ８００に配置（インストール）された各処理部は、CD-ROMやDVD−ROMのような記憶媒体に格納されており、OSやデータベースシステムが有するインストール処理部によりメモリ８００にインストールされる。

図７は、本実施の形態の表データ管理部１３０によって管理されるインデクス専用列を含む表の行データの格納（記憶）構造の一例を示す図である。

行データは、図７に示すデータレコード２１１３０のような形態で記憶される。データレコード２１１３０は、記憶領域のアクセス単位又は入出力の単位（記憶領域がディスク装置などの場合）であるページ２１１００の内部に記憶される。

ページ２１１００は、データベース２１０の物理的構成単位である。１つのページ２１１００内には、複数のデータレコード２１１３０を記憶可能である。データレコード２１１３０のページ内の記憶位置は、スロット２１１２０によって特定される。スロット２１１２０の領域には、データレコード２１１３０が記憶されているページ２１１００の先頭からの記憶位置が設定されている。ページ制御情報２１１１０は、スロットの割り当て情報などのスロット管理及びページ内の領域使用状況などの領域管理を行うための情報である。

データレコード２１１３０は、データフィールド２１１３２、２１１３３及び２１１３４を含む。データフィールド２１１３４は、インデクス専用列に関する情報を記憶する。データフィールド２１１３２及び２１１３３は、インデクス専用列でない列に関する情報を記憶する。

データレコード２１１３０は、表データ管理部１３０（行データ作成部１３１及びインデクス専用列処理部１３３）によってデータが記憶される。行データ作成部１３１は、データフィールド２１１３３に列データそのものを記憶する。そして、列データが記憶されたデータフィールド２１１３３の先頭記憶位置を示す情報をデータフィールド２１１３２に記憶する。

また、インデクス専用列処理部１３３は、図７のデータレコード２１１３０の構造に示されるように、インデクス専用列に対応する列データそのものをデータレコード２１１３０内には記憶しない。この場合、列データ記憶位置を記憶したデータフィールド２１１３２に対応するデータフィールド２１１３４に、インデクス専用列であることを示す値（ここでの例では“１”）を記憶する。

ここで、列データとして「NULL値」を記憶する場合には、NULL値を示す情報として、データフィールド２１１３２又はデータフィールド２１１３４に“０”を記憶する。列データが「NULL値」の場合には、当該列に対応する列データのデータフィールド２１１３３の領域は確保しない。また、列データ記憶位置を示す値として、データレコード２１１３０の先頭から列データ記憶位置までのオフセット値を採用するものとする。さらに、ここでは、データレコード２１１３０の長さなどを管理するためのレコードヘッダ２１１３１の領域長を１６バイトとしている。そのため、値“１”は、インデクス専用列であることを示す値として機能させることが可能である。

図８は、本実施の形態のキーワード指定の検索を実現するための全文検索用インデクスであるインデクス２１２の構造の一例を示す図である。

図８に示すように、インデクス２１２は、インデクス項目２１２１０、及び、当該インデクス項目２１２１０に対応するインデクス情報２１２２０を含む。

インデクス項目２１２１０は、インデクスを定義している列（インデクス専用列に限定しない）の列データに含まれる文字列２１２１１によって構成される。図８の例では、文字列２１２１１として「と」「つ」「か」「え」と１文字として記載しているが、複数の文字からなる文字列であってもよい。

また、インデクス情報２１２２０は、インデクス項目２１２１０を構成する文字列２１２１１を列データとして有する行を一意に識別するための行識別子と文字位置との組（２１２２２）の集合２１２２１によって構成される。例えば、図８の例では、文字列２１２１１「と」を含む行の識別子は「RID001」及び「RID008」などであって、それぞれの列の行データ内の文字列２１２１１「と」の文字位置は「03」及び「12」などである。

行識別子は、具体的には、図７にて説明したデータレコード２１１３０が記憶されるページ２１１００を一意に識別するためのページ識別子、及び、ページ内のデータレコード記憶位置を特定するスロットを示すスロット番号によって構成される。スロット番号は、ページ記憶構造においてページ制御情報２１１１０側から順次番号付けされる。

図２に示した行データアクセス部１３２は、行識別子に基づいてデータレコード２１１３０をアクセスする。具体的には、行識別子を構成するページ識別子に基づいて記憶ページにアクセスし、さらに、スロット番号に対応するスロットに記録されているデータレコード記憶位置を取得することによって、アクセス対応のデータレコード２１１３０の先頭アドレスを特定し、データレコード２１１３０内の列データなどにアクセスする。

インデクス検索部１４２は、キーワードを指定した検索要求を受信すると、指定されたキーワード及びインデクス項目２１２１０を参照し、当該キーワードを含む文字列２１２１１を特定する。そして、特定された文字列２１２１１に関連付けされている行識別子−文字列（２１２２２）を検索結果として取得する。

第２の記憶部３００は、第１の記憶部２００にデータベース２１０として記憶される表データ２１１及びインデクス２１２に関するデータベースの論理的な構成を示す定義情報を記憶する。第２の記憶部３００は、第１の記憶部２００と同様に、フラッシュメモリ又は磁気ディスクなどの記憶装置によって構成される。

第２の記憶部３００は、具体的には、表データ２１１の定義情報として、表定義情報３１０を記憶する。また、インデクス２１２の定義情報として、インデクス定義情報３２０を記憶する。

なお、第１の記憶部２００及び第２の記憶部３００は、必ずしも別の記憶部に格納する必要はなく、一つの記憶部で構成することも可能である。

図３は、本実施の形態の表定義情報（列情報）３１０の一例を示す図である。

表定義情報３１０は、表を構成する各列を一レコードとする表形式となっている。列情報には、列情報を特定する列名３１２、当該列を含む表の表名３１１、当該列のデータの型（列データ型３１３）、及び、当該列がインデクス専用列であるか否かを示すインデクス専用列指定３１４が含まれる。

また、図３に示す表定義情報３１０は、図４にて後述する表定義要求の例に対応している。具体的な対応関係については、図４にて後述する。

図４は、本実施の形態の表定義情報を作成するための表定義要求（ＳＱＬ）の一例を示す図である。

図４に示す表定義要求は、インデクス専用列を含むINSHOKU2表の表定義文を示しており、ALL_KANA_NAME列に対して、キーワード“TEXTSEARCH INDEX KEY”を用いてインデクス専用列を指定している。すなわち、アプリケーションプログラム４００の開発者などのデータベース２１０の作成者は、キーワード“TEXTSEARCH INDEX KEY”を指定することによって、データベース２１０の表データ２１１の記憶容量を抑制することが可能となる。したがって、データベース管理装置１を利用してアプリケーションプログラム４００のキーワード検索サービスを利用するエンドユーザに対して、高速なサービス実行時間を提供することができる。

図３に示した表定義情報（列情報）３１０は、前述したように、図４に示した表定義要求の例に対応する。

表名「INSHOKU2」及び列名「ALL_KANA_NAME」の列データ型は、「最大の長さが４０００バイトであるVARCHAR（可変長文字列型）」であり、当該列はインデクス専用列指定が「“Ｔ”」であることから、インデクス専用列であることを示している。

図３に示した表定義情報３１０の上から５番目のレコード３１５は、ALL_KANA_NAME列を示す列情報である。当該レコードのインデクス専用列指定３１４に記されている“Ｔ”は、表定義要求においてインデクス専用列であることを「TEXTSEARCH INDEX KEY」を用いて指定されたことを意味している。

一方、表名「INSHOKU2」及び列名「SID」の列データ型は「INT」（Integer型（整数型））であり、当該列はインデクス専用列指定が「NULL」であることから、インデクス専用列ではないことを示している。列名「SID」と同様に列名「TEL_NO」、「SHOP_CODE」及び「AREA_CODE」はインデクス専用列ではないことを示している。

ここでは、列名「TEL_NO」は、データ型「数値部分１０文字を含む全体で１２文字のパック型（PACK(12,10)と表現）」の電話番号を、列名「SHOP_CODE」はデータ型「INT」の店コードを、そして、列名「AREA_CODE」はデータ型「INT」のエリアコードを示している。パック型とは、数値及び文字含むデータを１バイトで、かつ、１０進２桁で表現する形式である。例えば、電話番号「０４５−８７７−６６３７」はパック型の内部データ形式としては、0x04、0x5A、0x87、0x7A、0x66、0x37というように６バイト（１２文字）で表現される（文字“−”は0xAで表現）。

図５は、本実施の形態のインデクス定義情報３２０の一例を示す図である。

インデクス定義情報３２０は、定義されたインデクスごとに一レコードとする表形式となっている。インデクスは、表を構成する列に対して定義される。インデクス定義情報３２０には、インデクス名３２１、当該インデクスが定義される表の表名３２２、当該インデクスが定義される列に対応する列名３２３、さらに、当該インデクスのインデクス種別３２４が含まれる。

また、図５に示すインデクス定義情報３２０、図６にて後述するインデクス定義要求の例に対応している。具体的な対応関係については、図６にて後述する。

図６は、本実施の形態のインデクスを作成するためのインデクス定義要求（ＳＱＬ）の一例を示す図である。

図６に示すインデクス定義要求は、図４にて示した表定義要求によって定義されたINSHOKU2表のインデクス専用列ALL_KANA_NAMEに対し、キーワード検索サービスを実現するための全文検索インデクスを定義するインデクス定義文を示している。インデクス名が「IDX_ALLKANA」であるインデクスを、INSHOKU2表のALL_KANA_NAME列に対して定義することを「ON “INSHOKU2”(“ALL_KANA_NAME”）」で示している。また、続いて指定されているキーワード“TEXTSEARCH”はインデクス種別を表している。キーワード“TEXTSEARCH”が指定されている場合には、インデクス２１２の実現（データ構造及び提供機能）の際に、キーワード検索サービスを実現するための全文検索インデクスを用いることを示している。一方、キーワード“TEXTSEARCH”の指定がない場合には、本実施の形態では、Ｂ木インデクスを想定している。

図５に示したインデクス定義情報３２０は、図６に示したインデクス定義要求の例に対応する。図５に示したインデクス定義情報３２０を参照すると、インデクス名「IDX_ALLKANA」のインデクス３２６は、表名「INSHOKU2」及び列名「ALL_KANA_NAME」に対して定義され、インデクス種別が「TEXTSEARCH」である。したがって、インデクス２１２がキーワード検索サービスを実現するための全文検索インデクスであることを示している。

一方、インデクス名「IDX_SID」のインデクス３２５は、表名「INSHOKU2」の列名「SID」に対して定義されているが、インデクス種別は「B-TREE」であることため、全文検索インデクスではなく、データ値に対する範囲検索などを実現するためのＢ木インデクスであることを示している。

次に、図２を参照しながら、図９に示すフローチャートに従って、本実施の形態のデータベース管理方法の処理を説明する。

図９は、本実施の形態のデータベース管理システム１００によってインデクス専用列を含む表を定義する際の処理の手順を示すフローチャートである。

本処理は、ＣＰＵ７００によって、定義情報管理部１２０が実行されることによって処理される。

ＣＰＵ７００は、まず、定義情報管理部１２０を実行することによって、アプリケーションプログラム４００などによって入力された表定義要求から定義対象である表の表名を取得し、メモリ８００に保持する（ステップＳ９０１）。例えば、図４に示した表定義要求が入力された場合には、定義対象の表名である「INSHOKU2」が保持される。

ＣＰＵ７００は、次に、表定義要求から定義対象である表に含まれる列に対応する定義部分を一つ取得し、当該定義部分に含まれる列名及び列データ型をメモリ８００に保持する（ステップＳ９０２）。例えば、SID列の場合には、列名及び列データ型として、「SID」及びInteger型を示す「INT」が保持される。また、別の列であるALL_KANA_NAME列の場合には、列名として「ALL_KANA_NAME」、列データ型としてデータ最大長が４０００バイトである可変長文字列型と示す「VARCHAR(4000)」が保持される。

ＣＰＵ７００は、取得された列情報にキーワード“TEXTSEARCH INDEX KEY”が指定されているか否かを判定する（ステップＳ９０３）。キーワード“TEXTSEARCH INDEX KEY”が指定されている場合には（ステップＳ９０３の結果が「Ｙｅｓ」）、当該列がインデクス専用列であるため、インデクス専用列指定の値として“Ｔ”をメモリ８００に保持する（ステップＳ９０４）。図４に示した表定義情報３１０では、ALL_KANA_NAME列に、キーワード“TEXTSEARCH INDEX KEY”が指定されているため、インデクス専用列指定の値として“Ｔ”が保持される。

一方、ＣＰＵ７００は、取得された列情報にキーワード“TEXTSEARCH INDEX KEY”が指定されていない場合には（ステップＳ９０３の結果が「Ｎｏ」）、当該列がインデクス専用列でないため、インデクス専用列指定の値として「NULL」をメモリ８００に保持する（ステップＳ９０５）。図４に示した表定義情報３１０では、SID列、TEL_NO列、SHOP_CODE列及びAREA_CODE列には、キーワード“TEXTSEARCH INDEX KEY”が指定されていないため、インデクス専用列指定の値として「NULL」が保持される。

ＣＰＵ７００は、その後、メモリ８００に保持されている表名、列名、列データ型及びインデクス専用列指定値を関連付けて列情報とし、表定義情報３１０に登録する（ステップＳ９０６）。

ＣＰＵ７００は、ステップＳ９０２からＳ９０６までの処理を表定義要求に含まれるすべての列定義部分に対して実行したか否かを判定する（ステップＳ９０７）。すべての列定義部分に対して処理が完了していない場合には（ステップＳ９０７の結果が「Ｎｏ」）、ステップＳ９０２に戻り、処理を継続する。すべての列定義部分に対して処理が完了した場合には（ステップＳ９０７の結果が「Ｙｅｓ」）、本処理を終了する。

図１０は、本実施の形態のデータベース管理システム１００によってインデクスを定義する際の処理の手順を示すフローチャートである。

ＣＰＵ７００は、まず、定義情報管理部１２０を実行することによって、アプリケーションプログラム４００などによって入力されたインデクス定義要求に基づいて、定義対象であるインデクスのインデクス名及び当該インデックスに対応する表名及び列名を取得し、メモリ８００に保持する（ステップＳ１００１）。図６に示したインデクス定義要求を例として説明すると、定義対象のインデクス名は「IDX_ALLKANA」、インデクスを定義する対象の表の表名は「INSHOKU2」、列名は「ALL_KANA_NAME」となる。

ＣＰＵ７００は、次に、取得した表名、列名に対応する列情報を表定義情報３１０から取得する（ステップＳ１００２）。図６に示したインデクス定義要求では、取得対象の列情報は図３の表定義情報（列情報）３１０の、列名３１２が「ALL_KANA_NAME」であるレコード３１５に対応する。

ＣＰＵ７００は、次に、インデクス定義要求によって指定されたインデクス種別を取得し、メモリ８００に保持する（ステップＳ１００３）。図６に示したインデクス定義要求では、インデクス種別「TEXTSEARCH」が保持される。なお、インデクス定義要求においてインデクス種別が指定されていない場合には、「NULL」が保持される。

ＣＰＵ７００は、メモリ８００に保持されているインデクス種別と、取得された列情報に含まれる“インデクス専用列指定”とを比較評価する（ステップＳ１００４、ステップＳ１００５）。

ＣＰＵ７００は、評価結果として、メモリ８００に保持されているインデクス種別が「TEXTSEARCH」である場合には（ステップＳ１００５の結果が「インデクス種別が“TEXTSEARCH”」）、“TEXTSEARCH”をインデクス種別の値として保持する（ステップＳ１００６）。図６に示したインデクス定義要求では、保持されたインデクス種別が「TEXTSEARCH」であるため、ステップＳ１００６の処理が実行される。

一方、ＣＰＵ７００は、評価結果として、メモリ８００に保持されているインデクス種別が「NULL」であって、かつ、インデクス専用列指定の値が“Ｔ”の場合には（ステップＳ１００５の結果が「インデクス種別が“NULL”、かつ、インデクス専用列指定が“Ｔ”」）、インデクス定義要求において「TEXTSEARCH」が指定されたものと判定し、“TEXTSEARCH”をインデクス種別の値として保持する（ステップＳ１００７）。さらに、インデクス種別の値とインデクス専用列指定の値が整合していない点について警告メッセージを出力する（ステップＳ１００８）。

また、ＣＰＵ７００は、評価結果として保持されたインデクス種別が「NULL」であり、かつ、インデクス専用列指定の値が「NULL」の場合には、“B-TREE”をインデクス種別の値として保持する（ステップＳ１００９）。インデクス種別“B-TREE”は、数値の範囲検索などに使用される木構造であるＢ木インデクスであることを示している。

ＣＰＵ７００は、メモリ８００に保持されたインデクス名、表名、列名及びインデクス種別を関連付け、インデクス定義情報３２０に登録する（ステップＳ１０１０）。図６に示したインデクス定義要求では、図５のインデクス定義情報３２０に記載されたレコードのように、インデクス名３２１「IDX_ALLKANA」、表名３２２「INSHOKU2」、列名３２３「ALL_KANA_NAME」及びインデクス種別３２４「TEXTSEARCH」を含むレコードがインデクス定義情報として登録される。

ここで、本実施の形態では、ステップＳ１００５の評価結果の判定において、評価結果として保持されたインデクス種別が「NULL」であり、かつ、インデクス専用列指定が“Ｔ”の場合には、インデクス定義要求において「TEXTSEARCH」が指定されたものと判定しているが、インデクス定義要求でインデクス種別の指定が不正（正しい指定がなされていない）と判定し、その旨のエラーメッセージを出力してもよい。

図１１は、本実施の形態のデータベース管理システム１００によってインデクス専用列を含む表に対してデータを登録する処理の手順を示すフローチャートである。

ＣＰＵ７００は、まず、表データ管理部１３０を実行することによって、アプリケーションプログラム４００のデータ操作要求部４１０によって要求されたデータ登録要求に基づいて、１つの列についての登録対象データを取得し、メモリ８００に保持する（ステップＳ１１０１）。

ＣＰＵ７００は、次に、表定義情報３１０を参照し、当該列に対応する列情報を取得する（ステップＳ１１０２）。

さらに、ＣＰＵ７００は、取得された列情報に含まれるインデクス専用列指定の値を判定する（ステップＳ１１０３）。インデクス専用列指定の値が“Ｔ”の場合には（ステップＳ１１０３の結果が「“Ｔ”」）、インデクス専用列処理部１３３を実行し、作成中の行データに列の値として保持されているデータを記録せずに、インデクス専用列である旨を示す情報を記録する（ステップＳ１１０４）。具体的には、図７にて説明したデータフィールド２１１３４にオフセット値“１”を設定する。

一方、ＣＰＵ７００は、インデクス専用列指定の値が「NULL」の場合には（ステップＳ１１０３の結果が「NULL」）、行データ作成部１３１を実行し、作成中の行データに列の値として保持されているデータを記録する（ステップＳ１１０５）。

ＣＰＵ７００は、以上の処理が終了すると、データ登録要求に含まれるすべての列に対する処理が完了したか否かを判定する（ステップＳ１１０６）。すべての列に対して、処理が完了していない場合には（ステップＳ１１０６の結果が「Ｎｏ」）、ステップＳ１１０１に戻り、処理を継続する。

ＣＰＵ７００は、すべての列に対して、処理が完了している場合には（ステップＳ１１０６の結果が「Ｙｅｓ」）、作成された行データをデータベース（ＤＢ）に記憶し、当該記憶された行データの行識別子を決定する（ステップＳ１１０７）。具体的には、図７の説明にて記述したように、記憶する行データ、すなわち、データレコードを含むページ２１１００の識別子と、当該ページ内のデータレコードの位置を示すスロット２１１２０のスロット番号によって行識別子が決定される。

ＣＰＵ７００は、次に、行データ登録対象の表に対応するインデクス情報を、インデクス定義情報３２０を参照し、取得する（ステップＳ１１０８）。そして、取得したインデクス情報に含まれるインデクスについて、メモリ８００に保持されている登録データ及び行識別子に基づいて、インデクス管理部１４０にメンテナンスを要求する（ステップＳ１１０９）。インデクスのメンテナンスを要求されたインデクス管理部１４０は、インデクスメンテナンス部１４１によってインデクスを更新する。

図１２は、本実施の形態のデータベース管理システム１００によってインデクス専用列に対する検索条件を含む検索要求を実行する処理の手順を示すフローチャートである。

ＣＰＵ７００は、まず、表データ管理部１３０を実行することによって、アプリケーションプログラム４００のデータ操作要求部４１０によって要求されたデータ検索要求に基づいて、条件評価又は射影対象（取出し対象）である列に対応する表名及び列名を取得する（ステップＳ１２０１）。

ＣＰＵ７００は、次に、表定義情報３１０を参照し、取得された表名及び列名に対応する列情報を取得する（ステップＳ１２０２）。

ＣＰＵ７００は、取得された列情報に含まれるインデクス専用列指定の値を判定する（ステップＳ１２０３）。インデクス専用列指定が「NULL」の場合には（ステップＳ１２０３の結果が「NULL」）、条件評価に適用可能なインデクスをインデクス定義情報３２０から取得し、インデクスの使用有無及び使用インデクスを決定する（ステップＳ１２０５）。その後、インデクス検索部１４２によって決定されたインデクスに基づいて、条件に合致する行の行識別子を検索結果として取得する。さらに、検索要求に応じて、行データアクセス部１３２が要求された列データを取得し、要求元であるアプリケーションプログラム４００に返却する。

ＣＰＵ７００は、取得された列情報に含まれるインデクス専用列指定の値が“Ｔ”の場合には（ステップＳ１２０３の結果が「“Ｔ”」）、条件評価にインデクスの適用が可能であるか否かを判定する（ステップＳ１２０４）。インデクスの適用が可能な場合には（ステップＳ１２０４の結果が「Ｙｅｓ」）、インデクス定義情報３２０から条件評価対象の列に対応するインデクス情報を取得する（ステップＳ１２０６）。さらに、ステップＳ１２０６の処理で取得されたインデクス情報に含まれる（全文検索用）インデクスを使用することを決定する（ステップＳ１２０８）。その後、ステップＳ１２０５の処理の場合と同様に、インデクス検索部１４２が決定したインデクスに基づいて、条件に合致する行の行識別子を検索結果として取得する。さらに、検索要求に応じて、行データアクセス部１３２が要求された列データを取得して、要求元であるアプリケーションプログラム４００に返却する。

一方、ＣＰＵ７００は、インデクスを適用できない（インデクスを利用できない）場合には（ステップＳ１２０４の結果が「Ｎｏ」）、検索不可としてエラーメッセージを出力し（ステップＳ１２０７）、検索処理を終了する。インデクスを適用できない場合には、表データが存在しないインデクス専用列の値を取得しようとした場合などが含まれる。

図１３は、本実施の形態のデータベース管理システム１００によってインデクス専用列を含む表からデータを削除する処理の手順を示すフローチャートである。

ＣＰＵ７００は、まず、表データ管理部１３０を実行し、アプリケーションプログラム４００のデータ操作要求部４１０によって要求されたデータ削除要求に基づいて、削除対象行データにアクセスし、削除データをメモリ８００に保持する（ステップＳ１３０１）。削除対象行データにインデクス専用列が含まれる場合には、インデクス専用列処理部１３３によって、当該インデクス専用列のデータに対応するデータは保持しない。

続いて、ＣＰＵ７００は、指定された行データを削除する（ステップＳ１３０２）。

次に、ＣＰＵ７００は、インデクス定義情報３２０を参照し、行データ削除対象の表に関連するインデクス情報を取得する（ステップＳ１３０３）。

さらに、ＣＰＵ７００は、取得されたインデクス情報に含まれるインデクスについて、メモリ８００に保持されている削除データ及び行識別子に基づいて、インデクス管理部１４０にメンテナンスを要求する（ステップＳ１３０４）。ここで、インデクス専用列の削除列データについては、削除対象の行識別子のみに基づいて、インデクス管理部１４０にメンテナンスを要求する。インデクスのメンテナンスを要求されたインデクス管理部１４０は、インデクスメンテナンス部１４１によってインデクスを更新する。インデクス専用列に対するインデクスの場合には、インデクスメンテナンス部１４１によって当該インデクスに保持される行識別子を当該インデクスから削除する。

図１４は、本実施の形態のデータベース管理システム１００によってインデクス専用列を更新する処理の手順を示すフローチャートである。

まず、ＣＰＵ７００は、表データ管理部１３０を実行し、アプリケーションプログラム４００のデータ操作要求部４１０によって要求されたデータ更新要求に基づいて、１つの列についての更新対象データ（更新後のデータ）を取得し、メモリ８００に保持する（ステップＳ１４０１）。

ＣＰＵ７００は、次に、表定義情報３１０を参照し、当該列に対応する列情報を取得する（ステップＳ１４０２）。

ＣＰＵ７００は、取得された列情報に含まれるインデクス専用列指定を判定する（ステップＳ１４０３）。インデクス専用列指定の値が“Ｔ”の場合には（ステップＳ１４０３の結果が「“Ｔ”」）、インデクス専用列処理部１３３を実行し、作成中の行データに列の値として保持されているデータを記録せずに、インデクス専用列である旨を示す情報を記録する（ステップＳ１４０４）。具体的には、図７にて説明したデータフィールド２１１３４にオフセット値“１”を設定する。

一方、ＣＰＵ７００は、インデクス専用列指定の値が「NULL」の場合には（ステップＳ１４０３の結果が「NULL」）、行データ作成部１３１を実行し、作成中の行データに列の値として保持されているデータを記録する（ステップＳ１４０５）。

ＣＰＵ７００は、以上の処理が終了すると、データ登録要求に含まれるすべての列に対する処理が完了したか否かを判定する（ステップＳ１４０６）。すべての列に対して、処理が完了していない場合には（ステップＳ１４０６の結果が「Ｎｏ」）、ステップＳ１４０１に戻り、処理を継続する。

ＣＰＵ７００は、すべての列に対して、処理が完了している場合には（ステップＳ１４０６の結果が「Ｙｅｓ」）、更新対象行データにアクセスし、更新前の列データをメモリ８００に保持する（ステップＳ１４０７）。このとき、インデクス専用列処理部１３３によって、当該インデクス専用列のデータに対応するデータを保持しない。

ＣＰＵ７００は、行データ又は当該行データの一部の列データを更新する（ステップＳ１４０８）。

ＣＰＵ７００は、次に、インデクス定義情報３２０を参照し、行データ更新対象の表及び列に対応するインデクス情報を取得する（ステップＳ１４０９）。そして、取得されたインデクス情報に含まれるインデクスについて、保持されている更新前後データ及び行識別子に基づいて、インデクス管理部１４０にメンテナンスを要求する（ステップＳ１４１０）。インデクスのメンテナンスを要求されたインデクス管理部１４０は、インデクスメンテナンス部１４１によってインデクスを更新する。

本実施の形態によれば、インデクス専用列に指定された列に対応する表データの列データを記憶しないため、表の格納に必要な容量を少なくすることができる。表データとして格納するデータがインデクスにも格納されているため、本実施形態のように列にデータを格納しなくとも該データの操作（挿入や更新や削除）を実現することができる。

また、本実施の形態によれば、全文検索に利用されるインデクスをインデクス専用列に対応させることによって、組み込み機器でもキーワード検索を高速に実現することが可能となる。

本発明の実施の形態の全体概要を説明する図である。 本発明の実施の形態のデータベース管理装置の構成の一例を示すブロック図である。 本発明の実施の形態の表定義情報（列情報）の一例を示す図である。 本発明の実施の形態の表定義情報を作成するための表定義要求（ＳＱＬ）の一例を示す図である。 本発明の実施の形態のインデクス定義情報の一例を示す図である。 本発明の実施の形態のインデクスを作成するためのインデクス定義要求（ＳＱＬ）の一例を示す図である。 本発明の実施の形態の表データ管理部によって管理されるインデクス専用列を含む表の行データの格納（記憶）構造の一例を示す図である。 本発明の実施の形態のキーワード指定の検索を実現するための全文検索用インデクスであるインデクスの構造の一例を示す図である。 本発明の実施の形態のデータベース管理システムによってインデクス専用列を含む表を定義する際の処理の手順を示すフローチャートである。 本発明の実施の形態のデータベース管理システムによってインデクスを定義する際の処理の手順を示すフローチャートである。 本発明の実施の形態のデータベース管理システムによってインデクス専用列を含む表に対してデータを登録する処理の手順を示すフローチャートである。 本発明の実施の形態のデータベース管理システムによってインデクス専用列に対する検索条件を含む検索要求を実行する処理の手順を示すフローチャートである。 本発明の実施の形態のデータベース管理システムによってインデクス専用列を含む表からデータを削除する処理の手順を示すフローチャートである。 本発明の実施の形態のデータベース管理システムによってインデクス専用列を更新する処理の手順を示すフローチャートである。

符号の説明

１ データベース管理装置
１００ データベース管理システム
１１０ 制御部
１２０ 定義情報管理部
１２１ インデクス専用列解析部
１３０ 表データ管理部
１３１ 行データ作成部
１３２ 行データアクセス部
１３３ インデクス専用列処理部
１４０ インデクス管理部
１４１ インデクスメンテナンス部
１４２ インデクス検索部
２００ 第１の記憶部
２１０ データベース
２１１ 表データ
２１２ インデクス
３００ 第２の記憶部
３１０ 表定義情報（列情報）
３２０ インデクス定義情報
４００ アプリケーションプログラム
４１０ データ操作要求部
４２０ インデクス専用列データ生成部
５００ 入力部
６００ 出力部
７００ ＣＰＵ
８００ メモリ

Claims (3)

1. 複数行と複数列とで表現される表データと前記複数列に含まれる列に対応づけられたインデクスとを含むデータベース、を格納する記憶部を備え、前記データベースを管理する、データベース管理装置、によるデータベース管理方法であって、
   前記複数列は、列データが格納されないインデクス専用列と、列データが格納される非インデクス専用列とを含み、
   前記データベース管理装置は、前記複数列に含まれる列と前記インデクスとの対応付けを定義するインデクス定義情報を有し、
   前記インデクス定義情報は、前記インデクス専用列と全文検索用インデクスとの対応付けを定義し、
   前記データベース管理装置が、前記表データへのデータ登録要求を受け付け、
   前記データ登録要求が前記非インデクス専用列に対応する第１登録対象データの登録を要求する場合に、前記データベース管理装置が、前記非インデクス専用列に前記第１登録対象データを登録し、
   前記データ登録要求が前記インデクス専用列に対応する第２登録対象データの登録を要求する場合に、前記データベース管理装置が、前記第２登録対象データを前記インデクス専用列に登録することなく、前記インデクス定義情報を参照して前記全文検索用インデクスを特定して、前記全文検索用インデクスを、前記第２登録対象データを用いて更新し、
   前記データベース管理装置が、前記インデクス専用列に対する検索条件を含む検索要求を受け付けた場合に、前記インデクス定義情報を参照して前記全文検索用インデクスを特定し、前記全文検索用インデクスを使用して検索を行い、前記非インデクス専用列に対する検索条件を含む検索要求を受け付けた場合に、前記インデクス定義情報を参照してインデクスの使用の有無を決定する、ことを特徴とするデータベース管理方法。
2. 複数行と複数列とで表現される表データと前記複数列に含まれる列に対応づけられたインデクスとを含むデータベース、を格納する記憶部を備え、前記データベースを管理する、データベース管理装置であって、
   前記複数列は、列データが格納されないインデクス専用列と、列データが格納される非インデクス専用列とを含み、
   前記データベース管理装置は、前記複数列に含まれる列と前記インデクスとの対応付けを定義するインデクス定義情報を有し、
   前記インデクス定義情報は、前記インデクス専用列と全文検索用インデクスとの対応付けを定義し、
   前記データベース管理装置は、前記表データへのデータ登録要求を受け付け、
   前記データ登録要求が前記非インデクス専用列に対応する第１登録対象データの登録を要求する場合に、前記データベース管理装置は、前記非インデクス専用列に前記第１登録対象データを登録し、
   前記データ登録要求が前記インデクス専用列に対応する第２登録対象データの登録を要求する場合に、前記データベース管理装置は、前記第２登録対象データを前記インデクス専用列に登録することなく、前記インデクス定義情報を参照して前記全文検索用インデクスを特定して、前記全文検索用インデクスを、前記第２登録対象データを用いて更新し、
   前記データベース管理装置は、前記インデクス専用列に対する検索条件を含む検索要求を受け付けた場合に、前記インデクス定義情報を参照して前記全文検索用インデクスを特定し、前記全文検索用インデクスを使用して検索を行い、前記非インデクス専用列に対する検索条件を含む検索要求を受け付けた場合に、前記インデクス定義情報を参照してインデクスの使用の有無を決定する、ことを特徴とするデータベース管理装置。
3. データベース管理装置で実行されるデータベース管理プログラムであって、
   前記データベースは、複数行と複数列とで表現される表データと前記複数列に含まれる列に対応づけられたインデクスとを含み、
   前記複数列は、列データが格納されないインデクス専用列と、列データが格納される非インデクス専用列とを含み、
   前記データベース管理装置は、前記複数列に含まれる列と前記インデクスとの対応付けを定義するインデクス定義情報を有し、
   前記インデクス定義情報は、前記インデクス専用列と全文検索用インデクスとの対応付けを定義し、
   前記データベース管理プログラムは、
   前記表データへのデータ登録要求を受け付ける手順と、
   前記データ登録要求が前記非インデクス専用列に対応する第１登録対象データの登録を要求する場合に、前記非インデクス専用列に前記第１登録対象データを登録する手順と、
   前記データ登録要求が前記インデクス専用列に対応する第２登録対象データの登録を要求する場合に、前記第２登録対象データを前記インデクス専用列に登録することなく、前記インデクス定義情報を参照して前記全文検索用インデクスを特定して、前記全文検索用インデクスを、前記第２登録対象データを用いて更新する手順と、
   前記インデクス専用列に対する検索条件を含む検索要求を受け付けた場合に、前記インデクス定義情報を参照して前記全文検索用インデクスを特定し、前記全文検索用インデクスを使用して検索を行う手順と、
   前記非インデクス専用列に対する検索条件を含む検索要求を受け付けた場合に、前記インデクス定義情報を参照してインデクスの使用の有無を決定する手順と、を前記データベース管理システムに実行させることを特徴とするデータベース管理プログラム。

Images