(57)【要約】【課題】複数のデータベースを統合し新たなデータベースを構築する際の構造化データのインデクス設計を容易にするデータベース管理方法、データベース管理装置およびデータベース管理プログラムを提供することを目的とする。【解決手段】入力部４００と、データベース管理部１００と、構造化データを記憶する第１の記憶部２００とを備えるデータベース管理装置１０が、構造化データを検索するためのインデクスを作成することにより、構造化データを管理するデータベース管理方法であって、構造化データの検索に必要なインデクス定義要求からパスに含まれるタグ名を抽出し、抽出したタグ名に対応する構造化データのタグにより囲まれるデータを取得し、取得したデータからデータ型候補を判定する。そして、判定したデータ型候補ごとに適合する数を集計し、インデクス定義の際のデータ型を決定することを特徴とする。【選択図】図１
2009129400.tif 000002
【特許請求の範囲】
【請求項１】
構造化データを格納するデータベース管理装置が、前記構造化データを検索するためのインデクスを作成することにより前記構造化データを管理するデータベース管理方法であって、
前記データベース管理装置は、
外部からの処理要求を受け付ける入力部と、前記構造化データのデータベースを管理するデータベース管理部と、前記構造化データのデータベースと前記作成したインデクスとを記憶する第１の記憶部とを含んで構成され、
前記入力部は、
前記構造化データを検索するために必要な前記インデクスを定義するためのインデクス定義要求を受け付け、
前記データベース管理部は、
前記受け付けたインデクス定義要求から前記インデクスに示すパスに含まれるタグ名を抽出し、
前記第１の記憶部に記憶されたデータベースから前記構造化データを読み出して、前記読み出した構造化データから、前記抽出したタグ名のタグにより囲まれるデータを取得し、
前記取得したデータそれぞれを参照して、前記データの適合するデータ型候補を判定し、
前記抽出したタグ名のタグにより囲まれるデータそれぞれについて、前記判定したデータ型候補ごとに、当該データ型候補に適合する数を集計し、
前記適合する数を集計したデータ型候補のうち、いずれかのデータ型候補においてその数が所定数を超えたとき、前記所定数を超えたデータ型候補を、前記インデクス定義要求の対象であるインデクスにおいて定義するデータ型として決定し、
前記決定したデータ型でインデクスを作成し、前記作成したインデクスを前記第１の記憶部に記憶する
ことを特徴とするデータベース管理方法。
【請求項２】
前記データベース管理部は、
前記データ型候補を判定するときに、前記取得したデータに含まれる文字、記号、および数字を参照して、前記データの適合するデータ型候補を判定する
ことを特徴とする請求項１に記載のデータベース管理方法。
【請求項３】
前記データベース管理部は、
前記適合する数を集計したデータ型候補のうち、いずれかのデータ型候補においてその数が所定数を超えたとき、前記適合する数が最も多いデータ型候補を、前記インデクス定義要求の対象であるインデクスにおいて定義するデータ型として決定する
ことを特徴とする請求項１または請求項２に記載のデータベース管理方法。
【請求項４】
前記データベース管理装置は、
前記構造化データに含まれるタグのタグ名と前記タグ名のタグにより囲まれるデータのデータ型とを対応付けたデータ型情報を記憶する第２の記憶部をさらに備え、
前記データベース管理部は、
前記適合する数を集計したデータ型候補のうち、いずれのデータ型候補においてもその数が所定数に達しない場合に、前記第２の記憶部に記憶したデータ型情報において、前記抽出したタグ名に対応するデータ型を、前記インデクス定義要求の対象であるインデクスにおいて定義するデータ型として決定する
ことを特徴とする請求項１乃至請求項３のいずれか１項に記載のデータベース管理方法。
【請求項５】
前記データベース管理部は、
前記抽出したタグ名が前記データ型情報に設定されていない場合に、前記データ型候補すべてを、前記インデクス定義要求の対象であるインデクスにおいて定義するデータ型として決定する
ことを特徴とする請求項４に記載のデータベース管理方法。
【請求項６】
前記データベース管理部は、
前記適合する数を集計したデータ型候補のうち、いずれのデータ型候補においてもその数が所定数に達しない場合に、前記データ型候補すべてを、前記インデクス定義要求の対象であるインデクスにおいて定義するデータ型として決定する
ことを特徴とする請求項１乃至請求項３のいずれか１項に記載のデータベース管理方法。
【請求項７】
前記データベース管理部は、
前記受け付けたインデクス定義要求から前記インデクスに示されるパスを抽出し、
前記抽出したパスに対し、前記データ型候補すべてについてインデクスを作成し、前記作成したインデクスを前記第１の記憶部に記憶し、
前記第１の記憶部に記憶され前記抽出したパスに対し作成したデータ型候補すべてについてのインデクスのうち、前記インデクス定義要求の対象であるインデクスにおいて定義するデータ型として決定したデータ型と異なるデータ型で作成されたインデクスを削除する
ことを特徴とする請求項１乃至請求項４のいずれか１項に記載のデータベース管理方法。
【請求項８】
前記データ−ベース管理部は、
前記第１の記憶部に前記構造化データが記憶されていない場合に、
前記第２の記憶部に記憶したデータ型情報において、前記抽出したタグ名に対応するデータ型を、前記インデクス定義要求の対象であるインデクスにおいて定義するデータ型として決定する
ことを特徴とする請求項４に記載のデータベース管理方法。
【請求項９】
前記データベース管理部は、
前記抽出したタグ名が前記データ型情報に設定されていない場合に、前記データ型候補すべてを、前記インデクス定義要求の対象であるインデクスにおいて定義するデータ型として決定する
ことを特徴とする請求項８に記載のデータベース管理方法。
【請求項１０】
前記データベース管理装置は、
前記入力部に、前記構造化データを検索するための探索条件が入力された場合において、
前記データベース管理部は、
前記入力された探索条件に指定されるタグ名を抽出し、
前記第１の記憶部に記憶されたインデクスから、前記抽出された探索条件に指定されるタグ名と同じタグ名のインデクスを検索し、
前記検索された同じタグ名のインデクスが、複数のデータ型で作成されていると判定したときに、
前記複数のデータ型で作成されたインデクスそれぞれのデータ型と、前記探索条件で指定された前記構造化データを検索する条件となる比較対象のデータ型とを比較して、前記複数のデータ型で作成されたインデクスのうち、前記比較対象のデータ型と異なるデータ型で作成されたインデクスを削除する
ことを特徴とする請求項１乃至請求項９のいずれか１項に記載のデータベース管理方法。
【請求項１１】
外部からの処理要求を受け付ける入力部と、構造化データのデータベースを管理するデータベース管理部と、前記構造化データのデータベースと前記構造化データを検索するためのインデクスとを記憶する第１の記憶部とを含んで構成されるデータベース管理装置であって、
前記入力部は、
前記構造化データを検索するために必要な前記インデクスを定義するためのインデクス定義要求を受け付け、
前記データベース管理部は、
前記受け付けたインデクス定義要求から前記インデクスに示すパスに含まれるタグ名を抽出し、
前記第１の記憶部に記憶されたデータベースから前記構造化データを読み出して、前記読み出した構造化データから、前記抽出したタグ名のタグにより囲まれるデータを取得し、
前記取得したデータそれぞれを参照して、前記データの適合するデータ型候補を判定し、
前記抽出したタグ名のタグにより囲まれるデータそれぞれについて、前記判定したデータ型候補ごとに、当該データ型候補に適合する数を集計し、
前記適合する数を集計したデータ型候補のうち、いずれかのデータ型候補においてその数が所定数を超えたとき、前記所定数を超えたデータ型候補を、前記インデクス定義要求の対象であるインデクスにおいて定義するデータ型として決定し、
前記決定したデータ型でインデクスを作成し、前記作成したインデクスを前記第１の記憶部に記憶する
ことを特徴とするデータベース管理装置。
【請求項１２】
請求項１乃至請求項１０のいずれか１項に記載のデータベース管理方法をコンピュータに実行させるためのデータベース管理プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データベース管理技術に関する。
【背景技術】
【０００２】
現在、様々なサービスにおいて、顧客情報、企業情報といったデータが蓄積され、個々の企業等がマーケティング活動等に利用している。その際、自社のデータだけでなく、他社あるいは自社内の他事業部等と協力して、データを共有し活用することで、大きな利益を得ようとする動きがある。また、新たな業務システムを構築するために既存システム内に保持しているデータを統合し活用したいというニーズがある。そこで、様々な情報を共有する手段の一つとして、利便性、拡張性に特徴があるＸＭＬ（eXtensible Markup Language）データをデータベースに格納する機会が増えてきている。
【０００３】
このＸＭＬデータを用いたデータベースシステムにおいては、大量のＸＭＬデータを効率よく検索するために、特定のタグおよびデータ型を指定してインデクスを定義している（例えば、非特許文献１参照）。図１５に一般的なインデクス定義の例を示す。図１５の下線に示すように、インデクス定義時に、このインデクスにより定義されるＸＭＬデータのタグについてのデータ型をユーザが指定する必要がある。すなわち、インデクスを定義するためには、このインデクスに含まれるタグのデータ型を予め決定しておかなければならない。
【非特許文献１】Matthias Nicola and Bert van der Linden, “Native XML Support in DB2 Universal Database”, Proceedings of the 31st international conference on Very large data bases, Pages: 1164 -1174, Year of Publication: 2005
【発明の開示】
【発明が解決しようとする課題】
【０００４】
しかしながら、企業間あるいは、企業内での情報の統合を考えた場合に、必ずしもすべてのＸＭＬデータのタグのデータ型が一意に決められているとは限らない。また、既存システムは、それぞれ独自のスキーマを保持していて、たとえ同じタグであってもそれぞれのスキーマで定義しているデータ型が異なる可能性がある。非特許文献１に記載された技術においては、ＸＭＬスキーマを参照してインデクス定義の際のデータ型を決定している。そのため、統合するデータベースが多くなればなるほど、参照するデータ量が増大する。その結果、インデクスを定義する際に、タグのデータ型がわからず、多くのデータ型を調べるなど、データ型を決定するためのインデクス設計が非常に困難であり手間がかかってしまう。
【０００５】
このような背景に鑑みて本発明がなされたのであり、本発明は、新たなデータベースを構築する際のＸＭＬデータに対するインデクス設計を容易にするデータベース管理方法、データベース管理装置およびデータベース管理プログラムを提供することを目的とする。
【課題を解決するための手段】
【０００６】
前記課題を解決するため、本発明のデータベース管理方法、データベース管理装置およびデータベース管理プログラムは、ＸＭＬデータを検索するために必要なインデクスを定義しておくためのインデクス定義要求からパスを抽出し、抽出したパスからタグ名を抽出し、抽出したタグ名に対応するＸＭＬデータのタグにより囲まれるデータを取得し、取得したデータからデータ型候補を判定し、判定したデータ型候補ごとに、当該データ型候補に適合する数を集計することで、インデクス定義の際のデータ型を決定することを特徴とする。
【発明の効果】
【０００７】
本発明によれば、新たなデータベースを構築する際のＸＭＬデータに対するインデクス設計を容易にするデータベース管理方法、データベース管理装置およびデータベース管理プログラムを提供することができる。
【発明を実施するための最良の形態】
【０００８】
次に、本発明を実施するための最良の形態（「実施形態」という）について、適宜図面を参照しながら詳細に説明する。
【０００９】
なお、本発明において、構造化データは、ＸＭＬデータ、ＳＧＭＬ（Standard Generalized Markup Language）データ等を含むが、本実施形態においては、ＸＭＬデータとして説明する。
【００１０】
図１は、本発明の実施形態に係るデータベース管理システムの構成例を示す機能ブロック図である。データベース管理システム１は、データベース管理装置１０と、ネットワーク３０を介して接続される各情報処理装置２０（２０ａ，２０ｂ，２０ｃ）とを含んで構成される。
【００１１】
なお、この各情報処理装置２０（２０ａ，２０ｂ，２０ｃ）は、Ａ社，Ｂ社，Ｃ社のように他社の複数の情報処理装置であっても、自社内の他の事業部等の複数の情報処理装置であってもよい。また、情報処理装置２０ａ，２０ｂ，２０ｃは３つに限定されることなく、複数の情報処理装置で構成されていればよい。
【００１２】
情報処理装置２０は、通信部２１と、制御部２２と、一時記憶部２３と、ＸＭＬデータベース２４とを備えている。
【００１３】
通信部２１は、ネットワーク３０と接続してデータベース管理装置１０との間で、通信を可能にするものである。また、制御部２２は、一時記憶部２３に記憶したアプリケーションプログラムにより、ＸＭＬデータベース２４の管理と、ネットワーク３０を介したデータベース管理装置１０とのデータ通信を制御する。
【００１４】
ＸＭＬデータベース２４は、各情報処理装置２０が持つＸＭＬデータを蓄積するものである。このＸＭＬデータベース２４は、それぞれ独自のＸＭＬスキーマを保持しており、たとえ同じタグであってもそれぞれのＸＭＬデータベースによって、スキーマで定義しているデータ型が異なることがある。ただし、図１の構成は実施例であり、本発明においてＸＭＬデータベース２４は構成要素として必ずしも必要なものではない。
【００１５】
一方、データベース管理装置１０は、入力部４００と、データベース管理部１００と、第１の記憶部２００と、第２の記憶部３００と、出力部５００と、一時記憶部６００と、通信部７００とを含んで構成される。
【００１６】
入力部４００は、外部からの処理要求を受け付ける機能を有する。例えば、ＸＭＬデータを検索するためにインデクスを定義しておくためのインデクス定義要求や、ＸＭＬデータを検索する処理における探索条件等を入力する機能を有し、キーボード等により実現される。もしくは、後述のインデクス定義要求文(図４参照)を電文として受け付けるプログラムとして実現される。
【００１７】
第１の記憶部２００は、ＸＭＬデータ２１０とＸＭＬデータを検索するためのインデクス２２０とを記憶する機能を有し、フラッシュメモリ、磁気ディスク等の記憶装置で構成される。
【００１８】
具体的には、第１の記憶部２００は、各情報処理装置２０のＸＭＬデータベース２４からネットワーク３０を介して取得したＸＭＬデータ２１０を記憶する。また、データベース管理部１００において作成されたインデクス２２０を記憶する。
【００１９】
図２にＸＭＬデータ２１０の一例を示す。ＸＭＬデータは、タグと呼ばれる識別子を用いて、タグにより囲まれるデータの内容を記述する。ＸＭＬデータで用いられるタグ名は、ユーザが任意に設定可能であり、タグにより囲まれるデータのデータ型についても、ユーザが任意に設定できるものである。
【００２０】
なお、ここでいうデータ型は、タグにより囲まれるデータに使用するデータの種類をいい、例えば、string型（文字列）、integer型（整数）等である。
【００２１】
第２の記憶部３００は、ＸＭＬデータのタグ名とデータ型とを対応付けたデータ型情報３１０を記憶し、第１の記憶部２００と同様に、フラッシュメモリ、磁気ディスク等の記憶装置で構成される。なお、第１の記憶部２００と第２の記憶部３００は、必ずしも分かれている必要はなく、一つの記憶部で構成することも可能である。
【００２２】
図３（ａ）は、第２の記憶部３００におけるデータ型情報３１０の一例を示す図である。図３（ａ）のデータ型情報３１０は、ＸＭＬデータのタグ名３１１によって、そのタグ名３１１のタグにより囲まれるデータのデータ型３１２を一意に決定するために、予めユーザが設定しておく情報である。図３（ａ）は、データベース管理部１００が、このデータ型情報３１０により、例えばタグ名が「productID」であれば、そのデータのデータ型を「string型」に決定することを意味する。
【００２３】
また、このデータ型情報３１０は、図３（ｂ）に示すように、インデクス種別３１３をさらに対応付けた情報とすることも可能である。このようにインデクス種別３１３を設定しておくことで、ユーザがタグの属性に対応したインデクスの種別を予め設定しておくことができる。例えば、タグ名「productID」の場合は、B-treeインデクスで作成し、タグ名「性別」の場合は、ビットマップインデクスで作成することができる。また、ユーザがインデクス種別の変更をする場合においても、データ型情報３１０の設定を見直すことによって、インデクス種別３１３を変更したインデクスを作成することが可能となる。
【００２４】
次に、データベース管理部１００は、ＸＭＬデータのデータベースを管理する機能を有し、制御部１１０と、インデクス管理部１２０とを備える。なお、データベース管理部１００は、データベース管理装置１０にインストールされたデータベース管理のためのプログラムであるデータベース管理システム（DataBase Management System：ＤＢＭＳ）を当該データベース管理装置１０内のＣＰＵ（Central Processing Unit）が読み取って実行することにより実現される。
【００２５】
制御部１１０は、データベース管理装置１０全体の制御を行い、入力部４００で受け付けたインデクス定義要求についてのインデクス管理部１２０での制御や、作成したインデクス２２０を用いての検索処理の制御等を行う。
【００２６】
インデクス管理部１２０は、タグ名抽出部１２１、データ取得部１２２、データ型候補判定部１２３、データ型候補集計部１２４、データ型決定部１２５、インデクス作成部１２６、およびインデクス決定部１２７を備えている。
【００２７】
タグ名抽出部１２１は、入力部４００を介して受け付けたインデクス定義要求からインデクスのパスの部分を抽出し、さらに抽出したパスからタグ名を抽出する機能を有する。
【００２８】
図４に、本実施形態に係るインデクス定義要求の一例を示す。タグ名抽出部１２１は、このインデクス定義要求からパスの部分である「/product/productID」を抽出する。そしてこの抽出したパスからタグ名「productID」を抽出する機能を有する。
【００２９】
なお、従来のインデクス定義の例である図１５と対比して、本実施形態に係る図４のインデクス定義要求は、データ型を指定する必要のないことを特徴とする。
【００３０】
データ取得部１２２は、第１の記憶部２００に記憶されたＸＭＬデータ２１０それぞれを読み出し、この読み出したＸＭＬデータの中からタグ名抽出部１２１で抽出したタグ名のタグに囲まれるデータを取得する機能を有する。例えば、図２に示すＸＭＬデータ２１０において、タグ名抽出部１２１で抽出されたタグ名が「productID」である場合、開始タグ「<productID>」と終了タグ「</productID>」とに囲まれたデータ「123」を、データ取得部１２２は取得する。
【００３１】
データ型候補判定部１２３は、データ取得部１２２で取得したデータそれぞれに対し、データに含まれる文字、記号、数字等を参照して、そのデータのデータ型候補を判定する機能を有する。本実施形態の場合、そのデータ型候補を、string型（文字列）、float型（32ビット単精度浮動小数点数）、decimal型（10進数）、integer型（整数）から決定するものである。
【００３２】
データ型候補集計部１２４は、データ取得部１２２で取得したデータそれぞれについて、データ型候補判定部１２３で判定したデータ型候補ごとに、データ型候補に適合する数を集計する機能を有する。
【００３３】
図５に、本実施形態におけるデータ型候補に適合する数を集計した検証データ情報５５０の一例を示す。検証データ情報５５０は、タグ名５５１と、そのタグ名５５１についてデータ型候補判定部１２３において判定されたデータ型候補５５２と、そのデータ型候補に適合したデータの件数５５３とを対応付けた情報を有する。
【００３４】
図５の例においては、タグ名抽出部１２１で抽出されたタグ名５５１が「productID」であり、データ型候補判定部１２３において、データ型候補５５２が、「string型」、「float型」、「decimal型」、「integer型」の４つの候補に決定された場合である。そして、データ型候補集計部１２４により、データ取得部１２２が取得したデータすべてについて、そのデータ型候補に適合する数を集計した結果が適合件数５５３となる。ここでは、タグ名「productID」について、「string型」の適合件数は10件、「float型」の適合件数は890件、「decimal型」の適合件数は100件、「integer型」の適合件数は100,000件であることを示している。
【００３５】
データ型決定部１２５は、データ型候補判定部１２３においてデータ型候補として決定したものの中から、インデクス定義要求の対象であるインデクスにおいて定義するデータ型を決定する機能を有する。
【００３６】
具体的には、データ型決定部１２５は、データ型候補集計部１２４が集計した検証データ情報５５０において、いずれかのデータ型候補５５２の適合件数５５３が所定数を超えたとき、その適合件数５５３が最も多いデータ型候補５５２を、タグ名抽出部１２１が抽出したタグ名のタグにより囲まれるデータのデータ型として決定する。
【００３７】
図５の例においては、データ型候補５５２のうち、「integer型」の適合件数５５３が100,000件と最も多いため、データ型決定部１２５は、「integer型」をデータ型として決定する。
【００３８】
なお、所定数は、ユーザが予め設定しておくものであり、ユーザがＸＭＬデータの総データ数等を考慮して決定するものである。
【００３９】
また、データ型決定部１２５は、データ型候補集計部１２４が集計した検証データ情報５５０において、いずれのデータ型候補５５２においてもその適合件数５５３が所定数に達しない場合に、第２の記憶部３００に記憶したデータ型情報３１０（図３参照）に基づいてデータ型を決定する。つまり、データ型決定部１２５は、データ型情報３１０において、タグ名抽出部１２１で抽出したタグ名と同じタグ名３１１に対応するデータ型３１２を、このタグ名のタグにより囲まれるデータのデータ型に決定する。
【００４０】
例えば、タグ名抽出部１２１で抽出されたタグ名が「productID」であった場合に、検証データ情報５５０の適合件数５５３が所定数に達していないときには、図３（ａ）のタグ名３１１のうち、タグ名抽出部１２１で抽出されたタグ名と同じタグ名３１１の「productID」に対応するデータ型３１２の「string型」を、データ型決定部１２５はデータ型として決定する。
【００４１】
さらに、データ型決定部１２５は、タグ名抽出部１２１で抽出したタグ名が、第２の記憶部３００に記憶したデータ型情報３１０のタグ名３１１に設定されていない場合には、string型、float型、decimal型、integer型のすべてを、このタグ名のタグにより囲まれるデータのデータ型として決定することもできる。
【００４２】
また、データ型決定部１２５は、データ型候補集計部１２４が集計した検証データ情報５５０において、いずれのデータ型候補においてもその適合件数５５３が所定数に達しない場合に、string型、float型、decimal型、integer型のすべてを、タグ名抽出部１２１が抽出したタグ名のタグにより囲まれるデータのデータ型として決定することもできる。
【００４３】
次に、インデクス作成部１２６は、入力部４００に受け付けられたインデクス定義要求と、データ型決定部１２５で決定したデータ型とに基づいて、インデクスを作成する機能を有する。よって、データ型決定部１２５において、一つのデータ型に決定された場合は、タグ名抽出部１２１で抽出されたタグ名につき、一つのインデクスが作成される。一方、string型、float型、decimal型、integer型のすべてをデータ型に決定した場合は、タグ名抽出部１２１で抽出された一つのタグ名について、４つのデータ型すべてでインデクスを作成する。また、インデクス作成部１２６は、作成したインデクスを第１の記憶部２００に記憶させる機能を有する。
【００４４】
インデクス決定部１２７は、一つのタグ名について、string型、float型、decimal型、integer型のすべてでインデクスが作成された場合に、データ型決定部１２５で決定したデータ型と一致しないデータ型で作成されたインデクスを削除する機能を有する。
【００４５】
次に、一時記憶部６００は、データベースを管理するためのプログラムであるデータベース管理システム（ＤＢＭＳ）を記憶し、また、データベース管理部１００の処理結果を一時的に記憶する。具体的には、データ型候補集計部１２４が集計した検証データ情報５５０等を一時的に記憶する機能を有する。
【００４６】
通信部７００は、ネットワーク３０を介して各情報処理装置２０（２０ａ，２０ｂ，２０ｃ）との通信を可能にする機能を有する。本実施形態では、Ａ社，Ｂ社，Ｃ社等の各情報処理装置２０が備えるＸＭＬデータベース２４のＸＭＬデータを、通信部７００は、ネットワーク３０を介して取得する。
【００４７】
出力部５００は、データベース管理部１００で処理された情報を表示するものであり、例えば液晶ディスプレイ等で構成される。
【００４８】
（第１の実施形態）
次に、図１を参照しつつ、図６に沿って、本発明の第１の実施形態に係るデータベース管理方法の処理を説明する。図６は、データベース管理装置１０がＸＭＬデータのインデクス定義をする際の処理を示すフローチャートである。
【００４９】
まず、入力部４００に入力されたインデクス定義要求から、タグ名抽出部１２１がパスを抽出する（ステップＳ６０１）。ここでは、例として図４に示されるインデクス定義要求が入力され、パスの部分である「/product/productID」が抽出されるものとする。
【００５０】
次に、タグ名抽出部１２１は、抽出したパスからさらにタグ名を抽出する（ステップＳ６０２）。ここでは、タグ名抽出部１２１により、タグ名「productID」が抽出される。
【００５１】
次に、データ取得部１２２が、第１の記憶部２００からＸＭＬデータ２１０を読み出し、読み出したＸＭＬデータ２１０の中から、タグ名抽出部１２１で抽出したタグ名のタグにより囲まれるデータを取得する（ステップＳ６０３）。
【００５２】
そして、データ型候補判定部１２３は、ステップＳ６０３でデータ取得部１２２が取得したデータを１件取り込み、そのデータ型候補を判定する（ステップＳ６０４）。なお、データ型候補判定部１２３が、データ型候補を判定する具体的な処理の流れ（図９参照）は後述する。
【００５３】
ステップＳ６０４において、データ型候補判定部１２３が、データ型候補を判定すると、データ型候補集計部１２４は、その判定したデータ型候補について、図５で示した検証データ情報５５０のデータ型候補５５２に対応する適合件数５５３をカウントアップし更新する（ステップＳ６０５）。
【００５４】
そして、データ取得部１２２が取得したすべてのデータについてデータ型候補判定部１２３がデータ型候補を判定したか否かを判断する（ステップＳ６０６）。データ型候補の判定が終わっていないデータがある場合には（ステップＳ６０６→Ｎｏ）、ステップＳ６０４に戻って処理を続ける。
【００５５】
一方、データ取得部１２２が取得したすべてのデータについてのデータ型候補の判定が終わっている場合には（ステップＳ６０６→Ｙｅｓ）、データ型決定部１２５は、データ型候補集計部１２４が集計した検証データ情報５５０において、いずれかのデータ型候補の適合件数５５３が、ユーザが設定した所定数を超えているか否かを判断する（ステップＳ６０７）。
【００５６】
そして、適合件数５５３が所定数を超えているデータ型候補がある場合には（ステップＳ６０７→Ｙｅｓ）、データ型決定部１２５は、その適合件数５５３が最も多いデータ型候補を、タグ名抽出部１２１が抽出したタグ名のタグにより囲まれるデータのデータ型に決定する（ステップＳ６０８）。そして、インデクス作成部１２６が、決定したデータ型でインデクスを作成する（ステップＳ６０９）。
【００５７】
図７に本実施形態のデータ型決定時に出力部５００に出力される表示画面の一例を示す。タグ名抽出部１２１で抽出されたタグ名「productID」について、データ型候補判定部１２３において、「string型」、「float型」、「decimal型」、「integer型」の４つのデータ型候補が判定され、そのうち、適合件数が最も多い「integer型」（図７の符号７０１）にデータ型が決定されたことを表示する。
【００５８】
図６に戻り説明する。次に、データ型決定部１２５は、第２の記憶部３００に記憶したデータ型情報３１０（図３参照）から、タグ名抽出部１２１で抽出したタグ名に対応したデータ型３１２を取得し、ステップＳ６０８で決定したデータ型と一致するか否かを判断する（ステップＳ６１０）。一致している場合には（ステップＳ６１０→Ｙｅｓ）、インデクス定義処理を終了する。一方、一致していない場合には（ステップＳ６１０→Ｎｏ）、データ型情報３１０で設定されているデータ型３１２を、ステップＳ６０８で決定したデータ型に更新する（ステップＳ６１１）。
【００５９】
一方、ステップＳ６０７において、いずれのデータ型候補においても、その適合件数５５３が所定数を超えていない場合には（ステップＳ６０７→Ｎｏ）、データ型決定部１２５は、第２の記憶部３００に記憶したデータ型情報３１０（図３参照）に基づいて、データ型を決定する（ステップＳ６１２）。つまり、タグ名抽出部１２１で抽出したタグ名と同じタグ名３１１に対応するデータ型３１２を、このタグ名のタグにより囲まれるデータのデータ型に決定する。そして、インデクス作成部１２６が、決定したデータ型でインデクスを作成する（ステップＳ６１３）。
【００６０】
図８に、本実施形態のデータ型決定時において、決定したデータ型と適合しないデータ型のデータを出力部５００においてwarningとして表示する例を示す。データ型を決定した際に、決定したデータ型と適合しないデータが存在する場合は、ユーザが適合しないデータを特定できるように、この決定したデータ型と適合しないデータをwarningリストとして表示する。また、決定したデータ型に適合しないデータの件数、および判定した総データ数に対する決定したデータ型のデータ数の割合を適合率として出力できるようにする。
【００６１】
（データ型候補の判定処理）
次に、ステップＳ６０４において、データ型候補判定部１２３が行うデータ型候補の判定処理を具体的に説明する。図９は、データ型候補判定部１２３が、データ取得部１２２が取得したデータを１件取り込み、そのデータ型候補を判定する処理を示すフローチャートである。
【００６２】
データ型候補判定部１２３は、データを取得すると、そのデータの中に、０〜９，＋，−，Ｅ，ｅ，.（小数点）のいずれかの記号が含まれるか否かを判断する（ステップＳ９０１）。含まれていないと判断した場合には（ステップＳ９０１→Ｎｏ）、データ型候補をstring型に判定する（ステップＳ９０２）。
【００６３】
ステップＳ９０１において、０〜９，＋，−，Ｅ，ｅ，.（小数点）のいずれかの記号が含まれていると判断した場合には（ステップＳ９０１→Ｙｅｓ）、さらにそのデータの中にＥ，ｅの記号が含まれているか否かを判断する（ステップＳ９０３）。Ｅ,ｅの記号が含まれていると判断した場合には（ステップＳ９０３→Ｙｅｓ）、データ型候補をstring型、float型に判定する（ステップＳ９０４）。
【００６４】
ステップＳ９０３において、Ｅ，ｅの記号が含まれていないと判断した場合には（ステップＳ９０３→Ｎｏ）、さらにそのデータの中に、.（小数点）の記号が含まれているか否かを判断する（ステップＳ９０５）。.（小数点）の記号が含まれていると判断した場合（ステップＳ９０５→Ｙｅｓ）には、データ型候補をstring型、float型、decimal型に判定する（ステップＳ９０６）。
【００６５】
ステップＳ９０５において、.（小数点）の記号が含まれていないと判断した場合には（ステップＳ９０５→Ｎｏ）、データ型候補をstring型、float型、decimal型、integer型に判定する（ステップＳ９０７）。
【００６６】
このようにすることで、データ型候補判定部１２３は、タグ抽出部１２１で抽出したタグ名のタグにより囲まれるデータのデータ型候補を判定することができる。  
【００６７】
このように第１の実施形態においては、ＸＭＬデータ２１０に対するインデクス定義時に、データ型を指定する必要がないため、従来技術のように大量のデータを参照した上で、データ型を決定するという手間を省くことができる。
【００６８】
また、データ型候補５５２の適合件数５５３が所定数を超えている場合は、その適合件数５５３が最も多いデータ型候補５５２を、当該タグ名により囲まれるデータのデータ型に決定することで、効率的にインデクスの作成を行うことが可能となる。また、データ型候補５５２の適合件数５５３が所定数を超えていない場合であっても、予めユーザが設定したデータ型情報３１０により、ユーザが最も適していると判断するデータ型に決定し、インデクスを作成することができる。
【００６９】
さらに、適合件数５５３が最も多いデータ型と、データ型情報３１０でユーザが予め設定したデータ型とを比較し、両者が異なる場合には、データ型情報３１０におけるデータ型をその適合件数５５３が最も多いデータ型に書き換えることにより、データ型情報３１０を設定し直すことが可能となる。これにより、データ型情報３１０を設定し直した後のインデクス設計について、より効率的に行うことができる。
【００７０】
なお、出力部５００において、インデクス設計に用いるデータ型を、どのデータ型に決定したか表示することで、ユーザは、データ型として決定されなかったデータ型のデータについて、その取り扱いの判断をする機会を得ることできる。また、適合しないデータの件数、適合率、および適合しないデータを出力部５００に表示させることによって、決定したデータ型とは適合しないデータ型のデータについて、その取り扱いの判断材料をユーザに示すことができる。
【００７１】
（第２の実施形態）
第２の実施形態は、データ型情報３１０（図３参照）にタグ名抽出部１２１が抽出したタグ名が設定されていない場合、またはデータ型情報３１０そのものが設定されていない場合に、データ型決定部１２５が、予め設定したデータ型候補すべてをインデクス作成に用いるデータ型として決定することを特徴とする。
【００７２】
図１０は、第２の実施形態に係るデータベース管理装置１０が、ＸＭＬデータのインデクス定義をする際の処理を示すフローチャートである。第２の実施形態においては、データベース管理装置１０は、図６のステップＳ６０１からステップＳ６０８と同様の処理を行う。
【００７３】
そして、図１０のステップＳ６０７において、検証データ情報５５０（図５参照）のいずれのデータ型候補５５２についても、適合件数５５３が、所定数を超えていない場合で（ステップＳ６０７→Ｎｏ）、第２の記憶部３００に予め設定したデータ型情報３１０（図３参照）に、タグ抽出部１２１が抽出したタグ名と同じタグ名３１１が設定されていないとき、またはデータ型情報３１０そのものが設定されていないときに、データ型決定部１２５は、予め設定したデータ型候補であるstring型、float型、decimal型、integer型のすべてをインデクス作成に用いるデータ型に決定する（ステップＳ１００１）。そして、インデクス作成部１２６において、決定した４つのデータ型でインデクスを作成する（ステップＳ１００２）。
【００７４】
このようにすることで、検証データ情報５５０の適合件数５５３が、所定数を超えない場合であり、データ型情報３１０にも、タグ名抽出部１２１が抽出したタグ名が設定されていないとき、または、もともとデータ型情報３１０が設定されていないときであっても、タグ名抽出部１２１が抽出したタグ名のタグに囲まれるデータのデータ型を決定し、インデクスを作成することができる。
【００７５】
（第３の実施形態）
第３の実施形態は、データベース管理装置１０が、予め設定したすべてのデータ型についてインデクスを作成した後に、データ型決定部１２５が決定したデータ型と一致しないデータ型で作成したインデクスを削除することを特徴とする。
【００７６】
図１１は、本発明の第３の実施形態に係るデータベース管理装置１０が、ＸＭＬデータのインデクス定義をする際の処理を示すフローチャートである。なお、図６に示すインデクス定義処理と同じ処理を行うステップについては、同じのステップ番号を付して説明する。
【００７７】
まず、図６と同様に、タグ名抽出部１２１は、入力されたインデクス定義要求からパスを抽出する（ステップＳ６０１）。この時入力部４００（図１参照）に入力されるインデクス定義要求は、図４に示す例のようにデータ型を指定する必要はない。
【００７８】
次に、インデクス作成部１２６は、抽出したパスに対し、予め設定しておいたstring型、float型、decimal型、integer型のデータ型で、インデクスを作成する（ステップＳ１１０１）。
【００７９】
そして、データベース管理装置１０は、図６のステップＳ６０２からステップＳ６１３までの処理と同様の処理を行う。ただし、図６のステップＳ６０９とステップＳ６１３のインデクス作成処理は、すでにすべてのデータ型についてのインデクスをステップＳ１１０１で作成しているため行わない。
【００８０】
続いて、インデクス決定部１２７は、ステップＳ６０８またはステップＳ６１２で決定したデータ型と一致しないデータ型で作成されたインデクスを削除する（ステップＳ１１０２）。
【００８１】
例えば、インデクス決定部１２７は、ステップＳ６０８においてデータ型決定部１２５が決定したデータ型が、integer型であったとした場合、ステップＳ１１０１で作成した４つのデータ型のインデクスのうち、string型、float型、decimal型の３つのデータ型について作成したインデクスを削除する。
【００８２】
また、インデクス決定部１２７は、ステップＳ６０２で抽出されたタグ名が「productID」である場合、データ型情報３１０（図３参照）のタグ名３１１「productID」に対応するデータ型３１２である「string型」と一致しないfloat型、decimal型、integer型で作成されたインデクスについて削除する。
【００８３】
このようにすることでも、ユーザは、インデクス定義要求を入力部４００に入力する際、データ型を予め決定しておく必要がなくなり、インデクス設計時の手間を省くことができる。
【００８４】
（第４の実施形態）
第４の実施形態は、データベース管理装置１０の第１の記憶部２００に、ＸＭＬデータ２１０が入力されていない状態においても、インデクス定義処理を行うことができることを特徴とする。
【００８５】
図１２において、まず、入力部４００（図１参照）に入力されたインデクス定義要求から、タグ名抽出部１２１がパスを抽出し、抽出したパスからタグ名を抽出する（ステップＳ１２０１）。なお、このとき入力部４００に入力されるインデクス定義要求は、図４に示す例のようにデータ型を指定する必要がないものである。
【００８６】
次に、データ型決定部１２５は、ステップＳ１２０１で抽出したタグ名と同じタグ名が、第２の記憶部３００におけるデータ型情報３１０（図３参照）のタグ名３１１として設定されているか否かを判断する（ステップＳ１２０２）。このタグ名が、データ型情報３１０に設定されている場合は（ステップＳ１２０２→Ｙｅｓ）、データ型情報３１０に基づいてデータ型を決定する（ステップＳ１２０３）。そして、インデクス作成部１２６が、決定したデータ型でインデクスを作成する（ステップＳ１２０５）。
【００８７】
一方、抽出したタグ名と同じタグ名が、データ型情報３１０のタグ名３１１として設定されていない場合には（ステップＳ１２０２→Ｎｏ）、string型、float型、decimal型、integer型のすべてをデータ型に決定する（ステップＳ１２０４）。そして、インデクス作成部１２６が、決定した４つのデータ型でインデクスを作成する（ステップＳ１２０５）。
【００８８】
このようにすることで、データベース管理装置１０が、各情報処理装置２０からＸＭＬデータ２１０を取得する前など、第１の記憶部２００に、ＸＭＬデータ２１０が存在しないときでも、インデクス設計を行うことができる。
【００８９】
（第５の実施形態）
本発明の第５の実施形態に係るデータベース管理方法は、string型、float型、decimal型、integer型の複数のデータ型で作成されたインデクスを、インデクス決定部１２７が一意に決定し、決定したデータ型以外のデータ型で作成されたインデクスを削除することを特徴とする。
【００９０】
図１３において、まず、入力部４００（図１参照）に、ＸＭＬデータを検索するための探索条件が入力されると、その入力された探索条件から、タグ名抽出部１２１が探索条件に指定されるパスに含まれるタグ名を抽出する（ステップＳ１３０１）。例えば、図１４に示す探索条件を含む検索要求が入力部４００に入力されたとすると、タグ名抽出部１２１は、タグ名として「productID」を抽出する。
【００９１】
次に、インデクス決定部１２７は、第１の記憶部２００に記憶されたインデクス２２０を検索し、抽出したタグ名について複数のデータ型でインデクスが作成されているか否かを判断する（ステップＳ１３０２）。そして、複数のデータ型でインデクスが作成されていない場合には（ステップＳ１３０２→Ｎｏ）、インデクス決定処理を終了する。
【００９２】
一方、複数のデータ型でインデクスが作成されている場合には（ステップＳ１３０２→Ｙｅｓ）、入力部４００に入力された探索条件のタグの比較対象によって、インデクス決定部１２７は、データ型を決定する（ステップＳ１３０３）。例えば、タグ名「productId」について、string型、float型、decimal型、integer型の４つのデータ型でインデクスが定義されている場合に、図１４の下線に示す、タグの比較対象である「"2"」のデータ型を判別する。そして、比較対象「"2"」がstring型であるので、インデクス決定部１２７は、検索するインデクスのデータ型をstring型に決定する。
【００９３】
次に、インデクス決定部１２７は、決定したデータ型以外のデータ型で作成されたインデクスを削除する（ステップＳ１３０４）。図１４の例においては、決定したデータ型がstring型であるので、抽出した「productID」のインデクスのうち、string型以外のfloat型、decimal型、integer型で作成されたインデクスを削除する。
【００９４】
このようにすることで、ユーザが入力部４００に入力した探索条件に沿った、データ型のＸＭＬデータを検索することが可能となる。また、不要なデータ型で作成されたインデクスを削除することができる。
【図面の簡単な説明】
【００９５】
【図１】本発明の実施形態に係るデータベース管理システムの構成を示す機能ブロック図である。
【図２】本発明の実施形態に係るＸＭＬデータの一例を示す図である。
【図３】本発明の実施形態に係るデータ型情報の例を示す図である。
【図４】本発明の実施形態に係るインデクス定義要求の一例を示す図である。
【図５】本発明の実施形態に係る検証データ情報の一例を示す図である。
【図６】本発明の第１の実施形態に係るインデクス定義処理を示すフローチャートである。
【図７】本発明の実施形態に係るデータ型決定時の表示画面の一例を示す図である。
【図８】本発明の実施形態に係る決定したデータ型とは適合しないデータについての警告表示の一例を示す図である。
【図９】本発明の実施形態に係るデータ型候補の判定処理を示すフローチャートである。
【図１０】本発明の第２の実施形態に係るインデクス定義処理を示すフローチャートである。
【図１１】本発明の第３の実施形態に係るインデクス定義処理を示すフローチャートである。
【図１２】本発明の第４の実施形態に係るＸＭＬデータを取得していない場合のインデクス定義処理を示すフローチャートである。
【図１３】本発明の第５の実施形態に係るインデクスを一意に決定する処理を示すフローチャートである。
【図１４】本発明の実施形態に係る探索条件を含む検索要求の一例を示す図である。
【図１５】従来技術におけるインデクス定義の一例を示す図である。
【符号の説明】
【００９６】
１      データベース管理システム
１０    データベース管理装置
２０    情報処理装置
３０    ネットワーク
１００  データベース管理部
１１０  制御部
１２０  インデクス管理部
１２１  タグ名抽出部
１２２  データ取得部
１２３  データ型候補判定部
１２４  データ型候補集計部
１２５  データ型決定部
１２６  インデクス作成部
１２７  インデクス決定部
２００  第１の記憶部
２１０  ＸＭＬデータ
２２０  インデクス
３００  第２の記憶部
３１０  データ型情報
４００  入力部
５００  出力部
６００  一時記憶部
７００  通信部
【図１】
2009129400.tif 000003
【図２】
2009129400.tif 000004
【図３】
2009129400.tif 000005
【図４】
2009129400.tif 000006
【図５】
2009129400.tif 000007
【図６】
2009129400.tif 000008
【図７】
2009129400.tif 000009
【図８】
2009129400.tif 000010
【図９】
2009129400.tif 000011
【図１０】
2009129400.tif 000012
【図１１】
2009129400.tif 000013
【図１２】
2009129400.tif 000014
【図１３】
2009129400.tif 000015
【図１４】
2009129400.tif 000016
【図１５】
2009129400.tif 000017