スキーマ定義生成装置、スキーマ定義生成方法およびスキーマ定義生成プログラム
【課題】スキーマ定義を自動で生成することで、スキーマ定義作成作業の工数を削減し、スキーマ定義を迅速に作成することを課題とする。
【解決手段】スキーマ生成装置１の要素比較作成部２は、管理対象である構成要素を示す構成要素情報を検索するための検索式に含まれる構成要素情報と、リレーショナルデータベース５への問い合わせ履歴情報に含まれるテーブル情報とを比較し、構成要素情報とテーブル情報との対応関係を示す対応関係情報を作成する。関係比較作成部３は、検索式に含まれる構成要素間の関係を示す関係情報と、問い合わせ履歴情報に含まれるとテーブル間の関係を示す情報とを比較し、関係情報と問い合わせ履歴情報との対応関係を示す対応関係情報を作成する。スキーマ生成部４は、要素比較作成部２によって作成された対応関係情報と、関係比較作成部３によって作成された対応関係情報とを用いて、スキーマ定義を作成する。
【解決手段】スキーマ生成装置１の要素比較作成部２は、管理対象である構成要素を示す構成要素情報を検索するための検索式に含まれる構成要素情報と、リレーショナルデータベース５への問い合わせ履歴情報に含まれるテーブル情報とを比較し、構成要素情報とテーブル情報との対応関係を示す対応関係情報を作成する。関係比較作成部３は、検索式に含まれる構成要素間の関係を示す関係情報と、問い合わせ履歴情報に含まれるとテーブル間の関係を示す情報とを比較し、関係情報と問い合わせ履歴情報との対応関係を示す対応関係情報を作成する。スキーマ生成部４は、要素比較作成部２によって作成された対応関係情報と、関係比較作成部３によって作成された対応関係情報とを用いて、スキーマ定義を作成する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、スキーマ定義生成装置、スキーマ定義生成方法およびスキーマ定義生成プログラムに関する。
【背景技術】
【０００２】
近年、複数の業務システム同士での提携やマルチベンダ運用管理環境における情報管理のために、異なるシステム間の情報を仮想的に統合するＦＣＭＤＢ（Federated Configuration Management Database）を有する情報管理システムが知られている。
【０００３】
例えば、図３３に例示するように、ＦＣＭＤＢは、構成情報管理システムと保守契約情報管理システムとのそれぞれに記憶されるデータを仮想的に統合して管理する。ここで、ＦＣＭＤＢは、複数のスキーマで記述されたデータを管理することで、複数のシステムに記憶されるデータを仮想的に統合している。
【０００４】
このため、情報管理システムの目的に応じたスキーマ定義を手動で作成する作業が実施されている。具体的には、スキーマ定義を作成する作業として、ＦＣＭＤＢの管理項目をＣＩまたはＲｅｌａｔｉｏｎｓｈｉｐとして設計し、統合時に必要となる情報を選別した後、ＦＣＭＤＢのスキーマ定義を管理者が手動で作成している。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特表２００１−５１８６７０号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかしながら、上述のスキーマ定義を手動で作成する方式では、複数のシステムに対して繰り返し作業が発生することや、必要となる情報を選別することを手動で行うので、スキーマ定義作成作業に工数が掛かり、スキーマ定義を迅速に作成できないという課題があった。
【０００７】
一つの側面では、スキーマ定義を自動的に作成することで、スキーマ定義作成作業の工数を削減し、スキーマ定義を迅速に作成することを目的とする。
【課題を解決するための手段】
【０００８】
第一の案では、管理対象である構成要素を示す構成要素情報を検索するための検索式に含まれる構成要素情報とリレーショナルデータベースへの問い合わせ履歴情報に含まれるテーブル情報とを比較して、対応関係情報を作成する。そして、検索式に含まれる構成要素間の関係を示す関係情報と問い合わせ履歴情報に含まれるとテーブル間の関係を示す情報とを比較して、関係情報と問い合わせ履歴情報との対応関係を示す対応関係情報を作成する。その後、作成された対応関係情報を用いて、構成要素情報のスキーマ定義および関係情報のスキーマ定義を作成する。
【発明の効果】
【０００９】
スキーマ定義を自動で生成することで、スキーマ定義作成作業の工数を削減し、スキーマ定義を迅速に作成することができる。
【図面の簡単な説明】
【００１０】
【図１】図１は、実施例１に係るスキーマ生成装置の構成を示すブロック図である。
【図２】図２は、実施例２に係るスキーマ生成装置の構成を示すブロック図である。
【図３】図３は、検索式の一例を示す図である。
【図４】図４は、ＳＱＬのログを示す図である。
【図５】図５は、ＣＩ名リストの一例を示す図である。
【図６】図６は、テーブル名リストの一例を示す図である。
【図７】図７は、ＣＩ候補リストの一例を示す図である。
【図８】図８は、Ｒｅｌａｔｉｏｎｓｈｉｐ候補リストの一例を示す図である。
【図９】図９は、ＣＩとテーブルの対応関係を生成する処理を説明する図である。
【図１０】図１０は、異なるスキーマのテーブル間で辞書を生成する処理を説明する図である。
【図１１】図１１は、ＲｅｌａｔｉｏｎｓｈｉｐとＳＱＬ文の対応関係を生成する処理を説明する図である。
【図１２】図１２は、スキーマを生成する処理を説明する図である。
【図１３】図１３は、実施例２に係るスキーマ生成装置の処理動作全体を示すフローチャートである。
【図１４】図１４は、実施例２に係るスキーマ生成装置のＣＩマッチング処理の動作を示すフローチャートである。
【図１５】図１５は、実施例２に係るスキーマ生成装置のＲｅｌａｔｉｏｎｓｈｉｐマッチング処理の動作を示すフローチャートである。
【図１６】図１６は、実施例２に係るスキーマ生成装置のスキーマ生成処理の動作を示すフローチャートである。
【図１７】図１７は、実施例３に係るスキーマ生成装置の構成を示すブロック図である。
【図１８】図１８は、テーブル未割当リストの一例を示す図である。
【図１９】図１９は、リコンサイル候補リストの一例を示す図である。
【図２０】図２０は、ＣＩ・Ｒｅｌａｔｉｏｎｓｈｉｐリストの一例を示す図である。
【図２１】図２１は、ＣＩ未割当リストの一例を示す図である。
【図２２】図２２は、パターンリストの一例を示す図である。
【図２３】図２３は、ＣＩ名に対応付けられていないテーブルに対するリコンサイル先推定処理を説明する図である。
【図２４】図２４は、検索式によって推定したモデルを辿れるかどうか検証する図である。
【図２５】図２５は、検証に失敗した場合の再検証処理を説明する図である。
【図２６】図２６は、検証に失敗した場合の再検証処理を具体的に説明する図である。
【図２７】図２７は、スキーマを生成する処理を説明する図である。
【図２８】図２８は、実施例３に係るスキーマ生成装置の処理動作全体を示すフローチャートである。
【図２９】図２９は、実施例３に係るスキーマ生成装置のＣＩマージ処理の動作を示すフローチャートである。
【図３０】図３０は、実施例３に係るスキーマ生成装置の検証処理の動作を示すフローチャートである。
【図３１】図３１は、実施例３に係るスキーマ生成装置のパターン変更処理の動作を示すフローチャートである。
【図３２】図３２は、スキーマ生成プログラムを実行するコンピュータを示す図である。
【図３３】図３３は、データセンタの構成を説明する図である。
【発明を実施するための形態】
【００１１】
以下に、本願の開示するスキーマ定義生成装置、スキーマ定義生成方法およびスキーマ定義生成プログラムの実施例を図面に基づいて詳細に説明する。なお、この実施例によりこの発明が限定されるものではない。
【実施例１】
【００１２】
まず、図１を用いて、実施例１に係るスキーマ生成装置の構成について説明する。図１は、実施例１に係るスキーマ生成装置の構成を示すブロック図である。
【００１３】
実施例１に係るスキーマ生成装置１は、要素比較作成部２、関係比較作成部３およびスキーマ生成部４を有し、リレーショナルデータベース５（図１では、「ＲＤＢ」と記載）と接続される。また、スキーマ生成装置１は、管理対象である構成要素を示す構成要素情報を検索するための検索式の入力を受け付けるとともに、リレーショナルデータベース５から問い合わせ履歴情報を収集する。
【００１４】
要素比較作成部２は、管理対象である構成要素を示す構成要素情報を検索するための検索式に含まれる構成要素情報と、リレーショナルデータベース５への問い合わせ履歴情報に含まれるテーブル情報とを比較し、構成要素情報とテーブル情報との対応関係を示す対応関係情報を作成する。
【００１５】
関係比較作成部３は、検索式に含まれる構成要素間の関係を示す関係情報と、問い合わせ履歴情報に含まれるとテーブル間の関係を示す情報とを比較し、関係情報と問い合わせ履歴情報との対応関係を示す対応関係情報を作成する。
【００１６】
スキーマ生成部４は、要素比較作成部２によって作成された対応関係情報と、関係比較作成部３によって作成された対応関係情報とを用いて、構成要素情報のスキーマ定義および関係情報のスキーマ定義を生成する。
【００１７】
つまり、実施例１に係るスキーマ生成装置１では、検索式や問い合わせ履歴情報などの既存の情報を利用することで、スキーマ定義を自動で生成することができる結果、スキーマ作成の工数を削減することができる。
【実施例２】
【００１８】
以下に、実施例２に係るスキーマ生成装置の構成および処理の流れを順に説明し、最後に実施例２による効果を説明する。
【００１９】
［スキーマ生成装置の構成］
まず、図２を用いて、スキーマ生成装置１０の構成を説明する。図２は、実施例２に係るスキーマ生成装置の構成を示すブロック図である。図２に示すように、このスキーマ生成装置１０は、管理ＤＢ１１、検索式解析部１２、ＳＱＬログ収集部１３、要素分析部１４、関係分析部１５、スキーマ生成部１６を有し、ＲＤＢ２０と接続される。
【００２０】
また、スキーマ生成装置１０は、ＦＣＭＤＢ向けに拡張したＸｐａｔｈ（ＸＭＬ Ｐａｔｈ Ｌａｎｇｕａｇｅ）で記述された検索式（例えば、後に詳述する図３参照）を受け付けるとともに、ＲＤＢ２０に記憶されたＳＱＬログ（例えば、後に詳述する図４参照）を収集する。ここで、検索式とは、ＣＩを検索するための検索式のことをいい、検索式にはＣＩおよびＲｅｌａｔｉｏｎｓｈｉｐの情報や構造が含まれている。また、ＳＱＬログとは、リレーショナルデータベースへ問い合わせた履歴のことをいい、ＳＱＬログにはテーブルの情報やテーブル間の関係が含まれている。
【００２１】
ＦＣＭＤＢ向けに拡張した検索式は、情報を要求するＣＩの種別やＲｅｌａｔｉｏｎｓｈｉｐなどを指定する。例えば、サーバ装置の情報、すなわちＣＩ種別「Server」を有するＣＩの情報を要求する場合、検索式は「%Server」で表される。なお、名称の前に「%」を付すことにより、その名称がＣＩの名称であることが特定される。
【００２２】
また、ＣＩ及びＲｅｌａｔｉｏｎｓｈｉｐを交互に並べることで、ＣＩ間の関係を辿る検索が可能となる。例えば、サーバ装置の管理者の情報を要求する場合、検索式は、「%Server==>%User」で表される。なお、「==>」はＲｅｌａｔｉｏｎｓｈｉｐを示す。
【００２３】
また、「%」の後に「*」を付すことにより、全てのＣＩ種別を指定した検索が可能となる。例えば、「%Server==>%*」で表される検索式は、ＣＩ種別「Server」と何らかの関係を持つＣＩの情報が要求されていることを示す。
【００２４】
また、ＣＩ種別の後に、要求するＣＩを具体的に指定する情報を付すことにより、ＣＩについての詳細検索が可能となる。例えば、名前がAであるようなサーバ装置の情報を要求する検索式は、「%Server[@name=='A']」で表される。
【００２５】
管理ＤＢ１１は、各種処理に必要なデータを記憶するとともに、ＣＩ名リスト１１ａ、テーブル名リスト１１ｂ、ＣＩ候補リスト１１ｃ、Ｒｅｌａｔｉｏｎｓｈｉｐ候補リスト１１ｄを記憶する。
【００２６】
ＣＩ名リスト１１ａは、検索式に含まれるＣＩ名を記憶する。具体的には、ＣＩ名リスト１１ａは、図５に示すように、ＣＩ名を一意に識別する「ＩＤ」と、検索式に含まれる「ＣＩ名」とを対応付けて記憶する。例えば、図３の例を用いて具体的に説明すると、ＣＩリスト１１ａは、図３に例示する検索式に含まれるＣＩ名「Ｓｅｒｖｉｃｅ」、「Ｓｅｒｖｅｒ」、「ＣＰＵ」をそれぞれ記憶する。
【００２７】
テーブル名リスト１１ｂは、ＳＱＬログに含まれるテーブル名を記憶する。具体的には、テーブル名リスト１１ｂは、図６に示すように、テーブル名を一意に識別する「ＩＤ」と、テーブルのスキーマ種別を示す「スキーマ」と、ＳＱＬログに含まれる「テーブル名」とを対応付けて記憶する。
【００２８】
ＣＩ候補リスト１１ｃは、ＣＩ名リスト１１ａに記憶されたＣＩ名のうち、テーブル名リスト１１ｂに記憶されたテーブル名と一致するＣＩ名をＣＩ候補として記憶する。具体的には、図７に示すように、ＣＩ候補リスト１１ｃは、ＣＩ候補を一意に識別する「ＩＤ」と、ＣＩ候補の「ＣＩ名」と、ＣＩ名と一致するテーブル名のＩＤを示す「テーブル」とを対応付けて記憶する。
【００２９】
Ｒｅｌａｔｉｏｎｓｈｉｐ候補リスト１１ｄは、ＣＩ名候補リスト１１ｃのうち、検索式中でＲｅｌａｔｉｏｎｓｈｉｐ名の前後のＣＩに対応するテーブル名の組をＲｅｌａｔｉｏｎｓｈｉｐ候補として記憶する。具体的には、Ｒｅｌａｔｉｏｎｓｈｉｐ候補リスト１１ｄは、図８に示すように、Ｒｅｌａｔｉｏｎｓｈｉｐ候補を一意に識別する「ＩＤ」と、Ｒｅｌａｔｉｏｎｓｈｉｐ名の前後のＣＩに対応するテーブル名の組である「テーブル（１）」および「テーブル（２）」と、テーブル名の組のＳＱＬ文での関係を示す「関係」とを対応付けて記憶する。
【００３０】
ここで、図４のＳＱＬログの例を用いて、テーブル名の組のＳＱＬでの関係について説明する。ＳＱＬログに含まれる特定のＳＱＬ文（例えば、副文問い合わせ、結合、キー制約など）から、テーブル名の組のＳＱＬでの関係を特定する。例えば、図４に例示するように、テーブル名「ｓｅｒｖｅｒ」にキー制約を示す「ＦＯＲＥＧＮ ＫＥＹ（ｓｅｒｖｉｃｅｉｄ）」が含まれている。この場合には、テーブル名「ｓｅｒｖｉｃｅ」とテーブル名「Ｓｅｒｖｅｒ」との関係が「キー制約」であるものとしてＲｅｌａｔｉｏｎｓｈｉｐ候補リスト１１ｄに記憶される。
【００３１】
また、図４のＳＱＬログにおいて、テーブル名「ＰｈｙｓｉｃａｌＳｅｒｖｅｒ」に結合を示す「ＪＯＩＮ ＣＰＵ ＯＮ」が含まれている。この場合には、テーブル名「ＰｈｙｓｉｃａｌＳｅｒｖｅｒ」とテーブル名「ＣＰＵ」との関係が「結合」であるものとしてＲｅｌａｔｉｏｎｓｈｉｐ候補リスト１１ｄに記憶される。
【００３２】
検索式解析部１２は、拡張したＸｐａｔｈ（ＸＭＬ Ｐａｔｈ Ｌａｎｇｕａｇｅ）で記述された検索式を解析してＣＩ名リスト１１ａを生成する。具体的には、検索式解析部１２は、図３に例示するような検索式を受け付けると、検索式を分割してＣＩ名リスト１１ａを生成し、生成したＣＩ名リストを管理ＤＢ１１に格納する。例えば、検索式解析部１２は、図３に例示する検索式を受け付けた場合には、検索式を「Ｓｅｒｖｉｃｅ」、「Ｓｅｒｖｅｒ」、「ＣＰＵ」に分割し、ＣＩ名「Ｓｅｒｖｉｃｅ」、「Ｓｅｒｖｅｒ」および「ＣＰＵ」を管理ＤＢ１１のＣＩ名リスト１１ａに記憶させる。
【００３３】
ＳＱＬログ収集部１３は、ＲＤＢ２０からＳＱＬログを収集する。具体的には、ＳＱＬログ収集部１３は、ＳＱＬログをＲＤＢ２０から収集し、テーブル名リスト１１ｂを生成し、生成したテーブル名リスト１１ｂを管理ＤＢ１１に記憶させる。例えば、ＳＱＬログ収集部１３は、図４に例示するＳＱＬログを収集した場合には、テーブル名「Ｓｅｒｖｉｃｅ」、「Ｓｅｒｖｅｒ」、「ＰｈｙｓｉｃａｌＳｅｒｖｅｒ」、「ＣＰＵ」および「Ｕｓｅｒ」を管理ＤＢ１１のテーブル名リスト１１ｂに記憶させる。
【００３４】
要素分析部１４は、ＣＩを検索するための検索式に含まれるＣＩ情報と、リレーショナルデータベース２０へのＳＱＬログに含まれるテーブル情報を比較し、構成要素情報とテーブル情報との対応関係を示すＣＩ候補リスト１１ｃを作成する。具体的には、要素分析部１４は、ＣＩ名リスト１１ａからＣＩ名を一つ取り出し、テーブル名リスト１ｂからテーブル名を１件取得する。
【００３５】
そして、要素分析部１４は、比較関数群（完全比較や部分比較）を用いて、ＣＩ名とテーブル名とを比較し、ＣＩ名とテーブル名とが一致するか判定する。この結果、要素分析部１４は、ＣＩ名とテーブル名とが一致した場合には、対応関係を生成してＣＩ候補リスト１１ｃに格納する。
【００３６】
ここで、図９を用いて、ＣＩとテーブルの対応関係を生成する処理について説明する。図９は、ＣＩとテーブルの対応関係を生成する処理を説明する図である。図９に示すように、要素分析部１４は、検索式に含まれるＣＩ名とＳＱＬログに含まれるテーブル名のマッチングを行い、ＣＩとテーブルの関係の候補をリストアップし、ＣＩ候補リスト１１ｃに記憶させる。
【００３７】
また、要素分析部１４は、全てのテーブル名について比較する処理を済ませた後に、ＣＩ名リスト１１ａから１件ＣＩを取得し、ＣＩ候補リスト１１ｃに該当ＣＩ名が複数件存在する場合には、同一のＣＩ名同士の対応関係を記憶する辞書を生成してもよい。
【００３８】
ここで、図１０を用いて、異なるスキーマのテーブル間で辞書を生成する処理について説明する。例えば、図１０に例示するように、要素分析部１４は、ＣＩ候補リストにＣＩ名「Ｓｅｒｖｅｒ」が複数件存在し、スキーマが異なるテーブルが割り当てられた場合には、既存の辞書生成方式用いて、ＣＩ名「Ｓｅｒｖｅｒ」同士の関係が紐付けられた辞書情報を作成する。
【００３９】
関係分析部１５は、検索式に含まれるＲｅｌａｔｉｏｎｓｈｉｐと、ＳＱＬログに含まれるとテーブル間の関係を示す特定のＳＱＬ文とを比較し、ＲｅｌａｔｉｏｎｓｈｉｐとＳＱＬとの対応関係を示すＲｅｌａｔｉｏｎｓｈｉｐ候補リスト１１ｄを作成する。具体的には、関係分析部１５は、検索式からＲｅｌａｔｉｏｎｓｈｉｐを一つ取り出すと、リレーションシップの前後のＣＩに対応するテーブル名をＣＩ候補リスト１１ｃから取り出す。
【００４０】
そして、関係分析部１５は、ＳＱＬログ中の関係をリストアップし、対応するＲｅｌａｔｉｏｎｓｈｉｐとの関係の有無と種類をＲｅｌａｔｉｏｎｓｈｉｐ候補リスト１１ｄに格納する。ここで、図１１を用いて、ＲｅｌａｔｉｏｎｓｈｉｐとＳＱＬ文の対応関係を生成する処理を説明する。図１１は、ＲｅｌａｔｉｏｎｓｈｉｐとＳＱＬ文の対応関係を生成する処理を説明する図である。図１１に示すように、関係分析部１５は、検索式中で着目するＲｅｌａｔｉｏｎｓｈｉｐが結ぶＣＩに紐付けられたテーブルをＣＩ候補リスト１１ｃから取得し、テーブル名を含む特定のＳＱＬを検索する。
【００４１】
例えば、図１１の例では、ＣＩ名「Ｓｅｖｉｃｅ」とＣＩ名「Ｓｅｒｖｅｒ」との関係を示すＲｅｌａｔｉｏｎｓｈｉｐに着目した場合に、関係分析部１５は、ＣＩ名「Ｓｅｖｉｃｅ」に紐付けられたテーブル名「Ｓｅｒｖｉｃｅ」とＣＩ名「Ｓｅｒｖｅｒ」に紐付けられたテーブル名「ＰｈｙｓｉｃａｌＳｅｒｖｅｒ」とを含む特定のＳＱＬ文を検索する。この結果、関係分析部１５は、「ＣＲＥＡＴＥ ＴＡＢＬＥ ＰｈｙｓｉｃａｌＳｅｒｖｅｒ・・・ＦＯＲＥＩＧＮ ＫＥＹ（ｃｐｕｉｄ）ＲＥＦＥＲＥＮＣＥＳ ＣＰＵ（ｉｄ）」を取得する。
【００４２】
ここで、関係分析部１５は、キー制約を示す「ＦＯＲＥＩＧＮ ＫＥＹ」が含まれているので、リレーションシップ候補リストに関係の種類「キー制約」であることをＲｅｌａｔｉｏｎｓｈｉｐ候補リスト１１ｄに記憶する。
【００４３】
スキーマ生成部１６は、ＣＩ候補リスト１１ｃおよびＲｅｌａｔｉｏｎｓｈｉｐ候補リスト１１ｄを用いて、ＣＩのスキーマ定義およびＲｅｌａｔｉｏｎｓｈｉｐのスキーマ定義を生成する。具体的には、スキーマ生成部１６は、ＣＩ名リスト１１ａから１件取り出し、ＣＩ候補リスト１１ｃとテーブル名リスト１１ｂからテーブル名を取り出す。
【００４４】
そして、スキーマ生成部１６は、ＳＱＬログを検索し、含まれる属性名を取得し、テーブル名と取得した属性名を元に、ＣＩ定義を生成する。そして、スキーマ生成部１６は、全てのＣＩに対してＣＩ定義を生成すると、Ｒｅｌａｔｉｏｎｓｈｉｐ候補リスト１１ｄから１件取り出し、ＣＩ候補リストを参照してＲｅｌａｔｉｏｎｓｈｉｐ定義を作成する。
【００４５】
その後、スキーマ生成部１６は、全てのリレーションシップ候補についてＲｅｌａｔｉｏｎｓｈｉｐ定義を作成する処理を繰り返す。例えば、スキーマ生成部１６は、生成するスキーマとして、図１２に例示するように、ＣＩ定義およびＲｅｌａｔｉｏｎｓｈｉｐ定義を生成する。
【００４６】
図１２の例では、スキーマ生成部１６は、ＣＩタイプが「Ｓｅｒｖｅｒ」、「ＣＰＵ」、「Ｓｅｒｖｉｃｅ」であるＣＩ定義を生成し、Ｒｅｌａｔｉｏｎｓｈｉｐタイプが「Ｓｅｒｖｅｒ−ＣＰＵ」、「Ｓｅｒｖｉｃｅ−Ｓｅｒｖｅｒ」であるＲｅｌａｔｉｏｎｓｈｉｐ定義を生成している。
【００４７】
例えば、スキーマ生成部１６は、図４に例示するＳＱＬログの「ＴＡＢＬＥ Ｓｅｒｖｉｃｅ」からＣＩタイプ「Ｓｅｒｖｉｃｅ」のＣＩ定義を生成する場合について説明する。図４に例示するＳＱＬログの「ＴＡＢＬＥ Ｓｅｒｖｉｃｅ」には、サービスのＩＤを示す「ｉｄ」、ユーザのＩＤを示す「ｕｓｅｒ＿ｉｄ」、サービス名称を示す「ｎａｍｅ」が列名で記載されている。スキーマ生成部１６は、これらの列名を用いて、「ｉｄ」、「ｕｓｅｒ＿ｉｄ」および「Ｓｅｒｖｉｃｅ」をＣＩ定義として生成する。
【００４８】
また、例えば、Ｒｅｌａｔｉｏｎｓｈｉｐタイプが「ＣＰＵ」のＲｅｌａｔｉｏｎｓｈｉｐ定義として、接続元のＣＩを示す「ｓｒｃ」と、接続先のＣＩを示す「ｄｓｔ」とが属性名として定義されている。
【００４９】
このように、検索式およびＳＱＬログなどの簡単に用意できる情報を用いて、スキーマ定義を自動で生成することができ、スキーマ定義作成作業の工数を削減し、スキーマ定義を迅速に作成することができる。
【００５０】
［スキーマ生成装置による処理］
次に、図１３〜図１６を用いて、実施例２に係るスキーマ生成装置１０による処理を説明する。図１３は、実施例２に係るスキーマ生成装置１０の処理動作を示すフローチャートである。図１４は、実施例２に係るスキーマ生成装置のＣＩマッチング処理の動作を示すフローチャートである。図１５は、実施例２に係るスキーマ生成装置のＲｅｌａｔｉｏｎｓｈｉｐマッチング処理の動作を示すフローチャートである。図１６は、実施例２に係るスキーマ生成装置のスキーマ生成処理の動作を示すフローチャートである。
【００５１】
図１３に示すように、スキーマ生成装置１０は、拡張したＸｐａｔｈで記述された検索式を受け付けると、検索式を分割してＣＩ名リストを生成する（ステップＳ１０１）。そして、スキーマ生成装置１０は、ＣＩ名リスト１１ａからＣＩ名を一つ取り出し（ステップＳ１０２）、ＣＩマッチング処理（後に図１４を用いて詳述）を行う（ステップＳ１０３）。
【００５２】
そして、スキーマ生成装置１０は、全てのＣＩについて処理済であるか判定し（ステップＳ１０４）、全てのＣＩが処理済でない場合には（ステップＳ１０４否定）、ステップＳ１０２に戻って処理を繰り返す。
【００５３】
また、スキーマ生成装置１０は、全てのＣＩが処理済である場合には（ステップＳ１０４肯定）、検索式の先頭から順に検索してＲｅｌａｔｉｏｎｓｈｉｐを一つ取り出し（ステップＳ１０５）、Ｒｅｌａｔｉｏｎｓｈｉｐマッチング処理（後に図１５を用いて詳述）を行う（ステップＳ１０６）。
【００５４】
その後、スキーマ生成装置１０は、全てのＲｅｌａｔｉｏｎｓｈｉｐについて処理済であるか判定し（ステップＳ１０７）、全てのＲｅｌａｔｉｏｎｓｈｉｐが処理済でない場合には（ステップＳ１０７否定）、ステップＳ１０５に戻って処理を繰り返す。また、スキーマ生成装置１０は、全てのＲｅｌａｔｉｏｎｓｈｉｐが処理済である場合には（ステップＳ１０７肯定）、スキーマ生成処理（後に図１６を用いて詳述）を行い（ステップＳ１０８）、生成されたスキーマを結果として出力する（ステップＳ１０９）。
【００５５】
次に、図１４を用いて、ＣＩマッチング処理の動作を説明する。図１４に示すように、
スキーマ生成装置１０の要素分析部１４は、テーブル名リスト１ｂからテーブル名を１件取得する（ステップＳ２０１）。そして、要素分析部１４は、比較関数群を用いて、ＣＩ名とテーブル名とを比較し（ステップＳ２０２）、ＣＩ名とテーブル名とが一致するか判定する（ステップＳ２０３）。この結果、要素分析部１４は、ＣＩ名とテーブル名とが一致した場合には（ステップＳ２０３肯定）、ＣＩ候補リスト１１ｃに対応関係を記録する（ステップＳ２０４）。
【００５６】
その後、要素分析部１４は、全てのテーブル名について比較する処理を済ませたか判定し（ステップＳ２０５）、全てのテーブル名について比較する処理を済ませていない場合には（ステップＳ２０５否定）、ステップＳ２０１に戻って処理を繰り返す。また、要素分析部１４は、全てのテーブル名について比較する処理を済ませた場合には（ステップＳ２０５肯定）、ＣＩ名リスト１１ａから１件ＣＩを取得し（ステップＳ２０６）、ＣＩ候補リストに該当ＣＩ名が複数件存在するか判定する（ステップＳ２０７）。
【００５７】
この結果、要素分析部１４は、ＣＩ候補リストに該当ＣＩ名が複数件存在する場合には（ステップＳ２０７肯定）、複数のＣＩ名同士が紐付けられた辞書を生成する（ステップＳ２０８）。その後、要素分析部１４は、全てのＣＩについて処理済みであるか判定し（ステップＳ２０９）、全てのＣＩについて処理済みでない場合には（ステップＳ２０９否定）、Ｓ２０６に戻って処理を繰り返す。また、要素分析部１４は、全てのＣＩについて処理済みである場合には（ステップＳ２０９肯定）、ＣＩマッチング処理を終了する。
【００５８】
次に、図１５を用いて、Ｒｅｌａｔｉｏｎｓｈｉｐマッチング処理の動作を説明する。図１５に示すように、リレーションシップの前後のＣＩに対応するテーブル名をＣＩ候補リスト１１ｃから取り出す。
【００５９】
図１５に示すように、スキーマ生成装置１０の関係分析部１５は、ＣＩ候補リスト１１ｃから、検索式中でリレーションシップの前後のＣＩに対応するテーブル名を取り出す（ステップＳ３０１）。そして、スキーマ生成装置１０は、ＳＱＬログ中の関係をリストアップし（ステップＳ３０２）、対応するＲｅｌａｔｉｏｎｓｈｉｐに関係の有無と種類をＲｅｌａｔｉｏｎｓｈｉｐ候補リスト１１ｄに記録する（ステップＳ３０３）。
【００６０】
次に、図１６を用いて、スキーマ生成処理の動作を説明する。図１６に示すように、スキーマ生成装置１０のスキーマ生成部１６は、ＣＩ名リスト１１ａから１件取り出し（ステップＳ４０１）、ＣＩ候補リスト１１ｃとテーブル名リスト１１ｂからテーブル名を取り出す（ステップＳ４０２）。
【００６１】
そして、スキーマ生成部１６は、ＳＱＬログを検索し、含まれる属性名を取得し（ステップＳ４０３）、テーブル名と取得した属性名を元に、ＣＩ定義を生成する（ステップＳ４０４）。そして、スキーマ生成部１６は、全てのＣＩについて処理済みであるか判定し（ステップＳ４０５）、処理済でない場合には（ステップＳ４０５否定）、ステップＳ４０１に戻って処理を繰り返す。
【００６２】
また、スキーマ生成部１６は、全てのＣＩについて処理済である場合には（ステップＳ４０５肯定）、Ｒｅｌａｔｉｏｎｓｈｉｐ候補リスト１１ｄから１件取り出し（ステップＳ４０６）、ＣＩ候補リストを参照してＲｅｌａｔｉｏｎｓｈｉｐ定義を作成する（ステップＳ４０７）。
【００６３】
その後、スキーマ生成部１６は、全てのリレーションシップ候補についてＲｅｌａｔｉｏｎｓｈｉｐ定義を作成する処理が済んでいるかを判定し（ステップＳ４０８）、全てのリレーションシップ候補についてＲｅｌａｔｉｏｎｓｈｉｐ定義を作成する処理が済んでいない場合には（ステップＳ４０８否定）、ステップＳ４０６に戻る。また、スキーマ生成部１６は、全てのリレーションシップ候補についてＲｅｌａｔｉｏｎｓｈｉｐ定義を作成する処理が済んだ場合には（ステップＳ４０８肯定）、スキーマ生成処理を終了する。
【００６４】
[実施例２の効果]
上述してきたように、スキーマ生成装置１０は、ＣＩを検索するための検索式に含まれるＣＩ情報と、リレーショナルデータベース２０へのＳＱＬログに含まれるテーブル情報を比較し、構成要素情報とテーブル情報との対応関係を示すＣＩ候補リスト１１ｃを作成する。そして、スキーマ生成装置１０は、検索式に含まれるＲｅｌａｔｉｏｎｓｈｉｐと、ＳＱＬログに含まれるとテーブル間の関係を示す特定のＳＱＬ文とを比較し、ＲｅｌａｔｉｏｎｓｈｉｐとＳＱＬとの対応関係を示すＲｅｌａｔｉｏｎｓｈｉｐ候補リスト１１ｄを作成する。その後、スキーマ生成装置１０は、ＣＩ候補リスト１１ｃおよびＲｅｌａｔｉｏｎｓｈｉｐ候補リスト１１ｄを用いて、ＣＩのスキーマ定義およびＲｅｌａｔｉｏｎｓｈｉｐのスキーマ定義を生成する。このため、スキーマ定義を自動で生成することができ、スキーマ定義作成作業の工数を削減し、スキーマ定義を迅速に作成することが可能である。
【００６５】
また、実施例２によれば、検索式に含まれるＣＩの名称とＳＱＬログに含まれるテーブル情報の名称とを比較し、当該構成要素情報の名称とテーブルの名称とが一致する組を前記対応関係情報として作成する。このため、検索式およびＳＱＬログなどの簡単に用意できる情報を用いて、スキーマ定義を自動で生成することができ、スキーマ定義作成作業の工数を削減し、スキーマ定義を迅速に作成することが可能である。
【実施例３】
【００６６】
ところで、上記の実施例２では、ＣＩマッチング処理およびＲｅｌａｔｉｏｎｓｈｉｐマッチング処理を行った後に、スキーマ生成処理を行っているが、本発明はこれに限定されるものではない。例えば、ＣＩマッチング処理およびＲｅｌａｔｉｏｎｓｈｉｐマッチング処理を行った後に、リコンサイル先を推定するＣＩマージ処理や検索式どおりにＣＩおよびＲｅｌａｔｉｏｎｓｈｉｐを辿れるかを検証する検証処理を行ってもよい。
【００６７】
そこで、以下の実施例３では、ＣＩマッチング処理およびＲｅｌａｔｉｏｎｓｈｉｐマッチング処理を行った後に、ＣＩマージ処理および検証処理を行う場合として、実施例３におけるスキーマ生成装置１０Ａの構成と処理について説明する。
【００６８】
まず、図１７を用いてスキーマ生成装置１０Ａの構成について説明する。図１７に示すように、スキーマ生成装置１０Ａは、図２に示したスキーマ生成装置１０と比較して、テーブル未割当リスト１１ｅ、リコンサイル候補リスト１１ｆ、ＣＩ・Ｒｅｌａｔｉｏｎｓｈｉｐリスト１１ｇ、ＣＩ未割当リスト１１ｈ、パターンリスト１１ｉ、従属要素推定部１７および検証部１８を新たに有する点が相違する。
【００６９】
テーブル未割当リスト１１ｅは、ＣＩに対応付けられていないテーブル名を記憶する。具体的には、テーブル未割当リスト１１ｅは、図１８に示すように、ＣＩに対応付けられていないテーブルを一意に識別する「ＩＤ」と、ＣＩに対応付けられていないテーブルのＩＤを示す「テーブル名」とを対応付けて記憶する。
【００７０】
リコンサイル候補リスト１１ｆは、ＣＩに対応付けられていないテーブルのリコンサイル先の候補を記憶する。具体的には、リコンサイル候補リスト１１ｆは、図１９に示すように、リコンサイル先候補を一意に識別する「ＩＤ」と、リコンサイル先のテーブルを示す「テーブル（先）」と、リコンサイル元のテーブルを示す「テーブル（元）」とを対応付けて記憶する。
【００７１】
ＣＩ・Ｒｅｌａｔｉｏｎｓｈｉｐリスト１１ｇは、ＣＩおよびＲｅｌａｔｉｏｎｓｈｉｐを記憶する。具体的には、ＣＩ・Ｒｅｌａｔｉｏｎｓｈｉｐリスト１１ｇは、ＣＩまたはＲｅｌａｔｉｏｎｓｈｉｐを一意に識別する「ＩＤ」と、ＣＩまたはＲｅｌａｔｉｏｎｓｈｉｐの種別を示す「ＣＩ／Ｒｅｌ」とを対応付けて記憶する。
【００７２】
ＣＩ未割当リスト１１ｈは、検証に失敗した原因となるＣＩを記憶する。具体的には、ＣＩ未割当リスト１１ｈは、検証に失敗した原因となるＣＩ候補を一意に識別する「ＩＤ」と、検証に失敗した原因となるＣＩの名称を示す「ＣＩ名」と、検証に失敗した原因となるＣＩに対応するテーブルを一意に識別する「テーブル」とを対応付けて記憶する。
【００７３】
従属要素推定部１７は、ＣＩと対応付けられずに残ったテーブルに関連するＳＱＬ文を分析し、残ったテーブルのリコンサイル先のＣＩを推定する。具体的には、従属要素推定部１７は、ＣＩと対応付けられずに残ったテーブル名を含む特定のＳＱＬ文を検索し、それに含まれるテーブル名を取得することで、リコンサイル先をリストアップする。ここで、特定のＳＱＬ文とは、副文問い合わせ、結合、キー制約などである。
【００７４】
例えば、図２３の例を用いて説明すると、ＣＩと対応付けられずに「Ｕｓｅｒ」テーブルが残った場合に、従属要素推定部１７は、テーブル名「Ｕｓｅｒ」を含む特定のＳＱＬ文を検索する。
【００７５】
この検索の結果、従属要素推定部１７は、ＳＱＬ文「Ｓｅｌｅｃｔ＊ＦＲＯＭ Ｓｅｖｉｃｅ ＷＨＥＲＥ ｕｓｅｒ＿ｉｄ＝（ＳＥＬＥＣＴ ｉｄ ＦＲＯＭ Ｕｓｅｒ ＷＨＥＲ ｎａｍｅ＝“Ｓｕｚｕｋｉ”）；」をＳＱＬログから取得する。かかるＳＱＬ文「Ｓｅｌｅｃｔ＊ＦＲＯＭ Ｓｅｖｉｃｅ ＷＨＥＲＥ ｕｓｅｒ＿ｉｄ＝（ＳＥＬＥＣＴ ｉｄ ＦＲＯＭ Ｕｓｅｒ ＷＨＥＲ ｎａｍｅ＝“Ｓｕｚｕｋｉ”）；」は、テーブル名「Ｕｓｅｒ」を含む副文問い合わせのＳＱＬ文である。
【００７６】
そして、従属要素推定部１７は、ＳＱＬ文「Ｓｅｌｅｃｔ＊ＦＲＯＭ Ｓｅｖｉｃｅ ＷＨＥＲＥ ｕｓｅｒ＿ｉｄ＝（ＳＥＬＥＣＴ ｉｄ ＦＲＯＭ Ｕｓｅｒ ＷＨＥＲ ｎａｍｅ＝“Ｓｕｚｕｋｉ”）；」に含まれるもう一つのテーブル名「Ｓｅｒｖｉｃｅ」をリコンサイル先として推定する。その後、従属要素推定部１７は、ＣＩと対応付けられずに残ったテーブルと推定されたリコンサイル先のテーブルを対応付けてリコンサイル候補リスト１１ｆに記憶させる。
【００７７】
検証部１８は、検索式通りにＣＩおよびＲｅｌａｔｉｏｎｓｈｉｐを辿れるか検証する。具体的には、検証部１８は、検索式を分割し、ＣＩ・Ｒｅｌａｔｉｏｎｓｈｉｐリスト１１ｇを作成する。そして、検索部１８は、図２４に示すように、ＣＩ・Ｒｅｌａｔｉｏｎｓｈｉｐリスト１１ｇからＣＩまたはＲｅｌａｔｉｏｎｓｈｉｐを一つずつ取り出して、検索式通りにＣＩおよびＲｅｌａｔｉｏｎｓｈｉｐを辿れるかを検証する。
【００７８】
例えば、図２４の例では、検索式が「％Ｓｅｒｖｉｃｅ→％Ｓｅｒｖｅｒ→％ＣＰＵ」である場合に、検証部１８は、ＣＩ・Ｒｅｌａｔｉｏｎｓｈｉｐリスト１１ｇからＣＩまたはＲｅｌａｔｉｏｎｓｈｉｐを一つずつ取り出す。そして、検証部１８は、ＣＩ「Ｓｅｒｖｉｃｅ」、「Ｒｅｌａｔｉｏｎｓｈｉｐ」、「Ｓｅｒｖｅｒ」、「Ｒｅｌａｔｉｏｎｓｈｉｐ」、「ＣＰＵ」の順に辿れるかを検証する。
【００７９】
ここで、検証に失敗する場合について説明する。例えば、検証部１８は、図２５に示すように、検証の結果、該当するＲｅｌａｔｉｏｎｓｈｉｐが複数存在する場合や辿る先のＣＩが複数のテーブルに対応付けられている場合に、検索通りにＣＩおよびＲｅｌａｔｉｏｎｓｈｉｐを辿ることができない。
【００８０】
例えば、図２５の例では、ＣＩ「ＰｈｙｓｉｃａｌＳｅｒｖｅｒ」に複数のテーブル「ＰｈｙｓｉｃａｌＳｅｒｖｅｒ」、「Ｓｅｒｖｅｒ」が対応付けられており、Ｒｅｌａｔｉｏｎｓｈｉｐが複数存在する。このため、検証部１８は、検索通りにＣＩおよびＲｅｌａｔｉｏｎｓｈｉｐを辿ることができない。
【００８１】
検証部１８は、検証に失敗した場合には、辿ることができなかった原因となったＣＩとそのＣＩに対応するテーブルをＣＩ未割当リスト１１ｈに格納する。そして、辿ることができなかった原因となるＣＩとテーブルの関連付け数を減らす条件パターンを生成してパターンリスト１１ｉに格納する。そして、検証部１８は、検証が成功するまで、条件パターンを順に適用して検証処理を繰り返す。
【００８２】
例えば、図２６の例では、検証部１８は、検索式「％Ｓｅｒｖｉｃｅ→％Ｓｅｒｖｅｒ→％ＰｈｙｓｉｃａｌＳｅｒｖｅｒ→％ＣＰＵ」について、検証処理を行った場合に、ＣＩ「Ｓｅｒｖｅｒ」に複数の経路が存在し、検証に失敗する。ここで、検証部１８は、辿ることができなかった原因となったＣＩ「Ｓｅｒｖｅｒ」の情報をＣＩ未割当リスト１１ｈに格納する。
【００８３】
そして、検証部１８は、辿ることができなかった原因となったＣＩ「Ｓｅｒｖｅｒ」に関係するテーブル名「ＰｈｙｓｉｃａｌＳｅｒｖｅｒ」、「Ｓｅｒｖｅｒ」、「Ｓｅｒｖｅｒ」をＣＩ候補リストから取得する。そして、検証部１８は、ＣＩとテーブルの対応付けを部分的に無効にしたパターンをパターンリスト１１ｉに格納する。そして、パターンを一つずつ順に取り出し、パターンを順に適用して検証が成功するまで、検証処理を繰り返す。
【００８４】
スキーマ生成部１６は、実施例２と同様に、ＣＩのスキーマ定義およびＲｅｌａｔｉｏｎｓｈｉｐのスキーマ定義を生成する。ここで、実施例３に係るスキーマ生成装置１０Ａでは、前述した従属要素推定部１７が、ＣＩと対応付けられずに残ったテーブルのリコンサイル先のＣＩを推定している。このため、図２７に例示するように、実施例３に係るスキーマ生成装置１０Ａは、図１２に例示したスキーマと比較して、ＣＩと対応付けられずに残ったテーブの情報がマージされて、ＣＩタイプ「Ｓｅｒｖｉｃｅ」に「＠ｕｓｅｒ＿ｎａｍｅ」が追加されている。
【００８５】
次に、実施例３に係るスキーマ生成装置の処理動作全体について図２８〜図３１を用いて説明する。実施例３に係るスキーマ生成装置は、図１３に示した実施例２にかかるスキーマ生成装置と比較して、ＣＩマージ処理、検証処理およびパターン変更処理を新たに行う点が相違する。
【００８６】
すなわち、図２８に示すように、スキーマ生成装置１０Ａは、実施例２と同様に、全てのＣＩについてマッチング処理を行い（ステップＳ５０１〜Ｓ５０４）、全てのＲｅｌａｔｉｏｎｓｈｉｐについてマッチング処理を行う（ステップＳ５０５〜５０７）。その後、実施例３に係るスキーマ生成装置は、ＣＩマージ処理（後に図２９を用いて詳述）を行い（ステップＳ５０８）、ＸｐａｔｈによってＣＩおよびＲｅｌａｔｉｏｎｓｈｉｐが辿れるかどうかを検証する検証処理（後に図３０を用いて詳述）を行う（ステップＳ５０９）。
【００８７】
検証の結果、スキーマ生成装置１０Ａは、検索式を満たす定義になっているか判定し（ステップＳ５１０）、検索式を満たす定義になっている場合には（ステップＳ５１０肯定）、実施例２と同様にスキーマ生成処理を行って（ステップＳ５１１）、生成されたスキーマ定義の結果を出力する（ステップＳ５１４）。
【００８８】
また、検証の結果、スキーマ生成装置１０Ａは、検索式を満たす定義になっていない場合には（ステップＳ５１０否定）、パターン変更が可能か判定する（ステップＳ５１２）。具体的には、スキーマ生成装置１０Ａは、パターン変更済みかつ全パターン処理を行った場合、または終了フラグが立っている場合には、パターン変更が可能でないと判定する。
【００８９】
この結果、スキーマ生成装置１０Ａは、パターン変更が可能である場合には（ステップＳ５１２肯定）、パターン変更処理（後に図３１を用いて詳述）を行った後（ステップＳ５１３）、ステップＳ５０２に戻って処理を繰り返す。また、スキーマ生成装置１０Ａは、パターン変更が可能でない場合には（ステップＳ５１２否定）、結果を出力する（ステップＳ５１４）。
【００９０】
ここで、図２９を用いて、ＣＩマージ処理の動作について説明する。図２９は、実施例３に係るスキーマ生成装置のＣＩマージ処理の動作を示すフローチャートである。図２９に示すように、スキーマ生成装置１０Ａは、ＣＩリストに出現しないテーブルのテーブル未割当リストを作成し（ステップＳ６０１）、ＳＱＬログ中の関係をリストアップする（ステップＳ６０２）。つまり、スキーマ生成装置１０Ａは、ＳＱＬログ中から未割当リストのテーブル名を含む特定のＳＱＬ文を検索する。
【００９１】
そして、スキーマ生成装置１０Ａは、割当リストのテーブル名を含む特定のＳＱＬ文にテーブル名が存在するか判定し（ステップＳ６０３）、テンプレートに合致するテーブル名が存在する場合には（ステップＳ６０３肯定）、リコンサイル候補リストに記録する（ステップＳ６０４）。また、スキーマ生成装置１０Ａは、テンプレートに合致するテーブル名が存在しない場合には（ステップＳ６０３否定）、リコンサイル候補リストに記録せずにステップＳ６０５に進む。
【００９２】
そして、スキーマ生成装置１０Ａは、未割当リストの全てのテーブル名について処理済であるか判定し（ステップＳ６０５）、処理済でない場合には（ステップＳ６０５否定）、ステップＳ６０２に戻って処理を繰り返す。また、スキーマ生成装置１０Ａは、未割当リストの全てのテーブル名について処理済である場合には（ステップＳ６０５肯定）、ＣＩマージ処理を終了する。
【００９３】
ここで、図３０を用いて、検証処理の動作について説明する。図３０は、実施例３に係るスキーマ生成装置の検証処理の動作を示すフローチャートである。図３０に示すように、スキーマ生成装置１０Ａは、検索式を分割し、ＣＩおよびリレーションシップのリストを作成する（ステップＳ７０１）。
【００９４】
そして、スキーマ生成装置１０Ａは、ＣＩ・Ｒｅｌａｔｉｏｎｓｈｉｐリスト１１ｇに残りが存在するか判定する（ステップＳ７０２）。この結果、スキーマ生成装置１０Ａは、ＣＩ・Ｒｅｌａｔｉｏｎｓｈｉｐリスト１１ｇに残りが存在する場合には（ステップＳ７０２肯定）、ＣＩ・Ｒｅｌａｔｉｏｎｓｈｉｐリスト１１ｇから１件取り出す（ステップＳ７０３）。そして、スキーマ生成装置１０Ａは、取り出した種別がＣＩであるか判定し（ステップＳ７０４）、ＣＩである場合には（ステップＳ７０４肯定）、ＣＩ候補から該当するものを取り出す（ステップＳ７０５）。
【００９５】
そして、スキーマ生成装置１０Ａは、ＣＩ候補から該当するものが存在するか判定し（ステップＳ７０６）、該当するものが存在する場合には（ステップＳ７０６肯定）、ＣＩ・Ｒｅｌａｔｉｏｎｓｈｉｐ名リスト１１ｇ中で直前のＣＩと同じスキーマが割り当てられているか判定する（ステップＳ７０７）。
【００９６】
この結果、スキーマ生成装置１０Ａは、Ｉ・Ｒｅｌａｔｉｏｎｓｈｉｐリスト１１ｇ中で直前のＣＩと同じスキーマが割り当てられている場合には（ステップＳ７０７肯定）、取り出されたＣＩまたはＲｅｌａｔｉｏｎｓｈｉに対して複数テーブルを割り当てられたスキーマが存在するか判定する（ステップＳ７０８）。
【００９７】
そして、スキーマ生成装置１０Ａは、取り出されたＣＩまたはＲｅｌａｔｉｏｎｓｈｉに対して複数テーブルを割り当てられたスキーマが存在する場合には（ステップＳ７０８肯定）、取り出されたＣＩまたはＲｅｌａｔｉｏｎｓｈｉｐのＩＤと該当テーブルのＩＤを出力して（ステップＳ７０９）、検証処理を終了する。また、スキーマ生成装置１０Ａは、取り出されたＣＩまたはＲｅｌａｔｉｏｎｓｈｉに対して複数テーブルを割り当てられたスキーマが存在しない場合には（ステップＳ７０８否定）、ステップＳ７０２に戻る。
【００９８】
また、Ｓ７０６において、スキーマ生成装置１０Ａは、ＣＩ候補から該当するものが存在しない場合（ステップＳ７０６否定）、終了フラグをセットして（ステップＳ７１４）、検証処理を終了する。また、Ｓ７０７において、スキーマ生成装置１０Ａは、Ｉ・Ｒｅｌａｔｉｏｎｓｈｉｐリスト１１ｇ中で直前のＣＩと同じスキーマが割り当てられていない場合には（ステップＳ７０７否定）、終了フラグをセットして（ステップＳ７１４）、検証処理を終了する。
【００９９】
Ｓ７０４の説明に戻って、スキーマ生成装置１０Ａは、取り出した種別がＣＩでない場合には（ステップＳ７０４否定）、直前のＣＩをキーとしてＣＩ候補リスト１１ｃおよびＲｅｌａｔｉｏｎｓｈｉｐ候補リスト１１ｄから該当するものを取り出す（ステップＳ７１０）。そして、スキーマ生成装置１０Ａは、Ｒｅｌａｔｉｏｎｓｈｉｐ候補リストに該当するものが存在するか判定し（ステップＳ７１１）、Ｒｅｌａｔｉｏｎｓｈｉｐ候補リストに該当しない場合には（ステップＳ７１１否定）、終了フラグをセットし（ステップＳ７１４）、検証処理を終了する。
【０１００】
また、スキーマ生成装置１０Ａは、Ｒｅｌａｔｉｏｎｓｈｉｐ候補リストに該当する場合には（ステップＳ７１１肯定）、該当するもののうち、もう一方のテーブル名が複数種類存在するか判定する（ステップＳ７１２）。この結果、スキーマ生成装置１０Ａは、テーブル名が複数種類存在しない場合には（ステップＳ７１２否定）、ステップＳ７０２に戻る。
【０１０１】
また、スキーマ生成装置１０Ａは、テーブル名が複数種類存在する場合には（ステップＳ７１２肯定）、取りだされたＣＩまたはＲｅｌａｔｉｏｎｓｈｉｐのＣＩ・Ｒｅｌａｔｉｏｎｓｈｉｐリスト中におけるＩＤを出力する（ステップＳ７１３）。
【０１０２】
Ｓ７０２の説明に戻って、スキーマ生成装置１０Ａは、ＣＩ・Ｒｅｌａｔｉｏｎｓｈｉｐリストに残りが存在しないと判定した場合には（ステップＳ７０２否定）、検証に成功したものとして（ステップＳ７１５）、検証処理を終了する。
【０１０３】
ここで、図３１を用いて、パターン変更処理の動作について説明する。図３１は、実施例３に係るスキーマ生成装置のパターン変更処理の動作を示すフローチャートである。図３１に示すように、スキーマ生成装置１０Ａは、パターンリストが存在しているかを判定し（ステップＳ８０１）、パターンリストが存在する場合には（ステップＳ８０１肯定）、パターンリストから次のパターンを参照し、該当する定義を無効に設定する（ステップＳ８０８）。
【０１０４】
また、スキーマ生成装置１０Ａは、パターンリストが存在しない場合には（ステップＳ８０１否定）、検証で出力されたのがＣＩであるか判定する（ステップＳ８０２）。この結果、スキーマ生成装置１０は、検証で出力されたのがＣＩである場合には（ステップＳ８０２肯定）、ＣＩ候補リスト１１ｃから検証時出力されたテーブルＩＤとＣＩ・Ｒｅｌａｔｉｏｎｓｈｉｐリスト１１ｇ以外のＣＩ名を共に含む項目を抽出してＣＩ未割当リスト１１ｈを作成する（ステップＳ８０３）。
【０１０５】
また、スキーマ生成装置１０は、検証で出力されたのがＣＩではなくＲｅｌａｔｉｏｎｓｈｉｐである場合には（ステップＳ８０２否定）、ＲｅｌａｔｉｏｎｓｈｉｐのＣＩ・Ｒｅｌａｔｉｏｎｓｈｉｐリスト１１ｇ中でのＩＤの次のＣＩ名を取得する（ステップＳ８０４）。
【０１０６】
そして、スキーマ生成装置１０Ａは、ＣＩ候補から、取得されたＣＩを含むレコードを抽出して未割当リストを作成する（ステップＳ８０５）。続いて、スキーマ生成装置１０は、未割当リストの全要素から全ての組み合わせを作成し（ステップＳ８０６）、空集合以外を要素数が少ない順に並べ替え、パターンリスト１１ｉとして出力する（ステップＳ８０７）。その後、スキーマ生成装置１０Ａは、パターンリスト１１ｉから次のパターンを参照し、該当する定義を無効に設定する（ステップＳ８０８）。
【０１０７】
このように、実施例３に係るスキーマ生成装置１０Ａは、ＳＱＬに含まれるテーブルのうち、いずれのＣＩとも対応関係がなかった未割当のテーブルが存在する場合に、そのテーブルに関連するＳＱＬを分析し、リコンサイル先のＣＩを推定する。このため、対応付けられずに残ったテーブルに関連するＳＱＬ文もさらに利用して、スキーマ定義を作成することができる。
【０１０８】
また、実施例３に係るスキーマ生成装置１０Ａは、作成されたＣＩ候補リスト１１ｃおよびＲｅｌａｔｉｏｎｓｈｉｐ候補リスト１１ｄを用いて、検索式を辿れるかを検証するので、精度の高いスキーマ定義を作成することができる。
【実施例４】
【０１０９】
さて、これまで本発明の実施例について説明したが、本発明は上述した実施例以外にも、種々の異なる形態にて実施されてよいものである。そこで、以下では実施例４として本発明に含まれる他の実施例を説明する。
【０１１０】
（１）システム構成等
また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。例えば、要素分析部１４および関係分析部１５を統合してもよい。
【０１１１】
（２）プログラム
ところで、上記の実施例で説明した各種の処理は、あらかじめ用意されたプログラムをコンピュータで実行することによって実現することができる。そこで、以下では、図３２を用いて、上記の実施例と同様の機能を有するプログラムを実行するコンピュータの一例を説明する。図３２は、スキーマ生成プログラムを実行するコンピュータを示す図である。
【０１１２】
図３２に示すように、スキーマ生成プログラムを実行するコンピュータ６００は、ＨＤＤ６１０、ＲＡＭ６２０、ＲＯＭ６３０およびＣＰＵ６４０をバス６５０で接続して構成される。
【０１１３】
そして、ＲＯＭ６３０には、上記の実施例と同様の機能を発揮するスキーマ生成プログラム、つまり、図３２に示すように、検索式解析プログラム６３１、ＳＱＬログ収集プログラム６３２、要素分析プログラム６３３、関係分析プログラム６３４およびスキーマ生成プログラム６３５が予め記憶されている。なお、プログラム６３１〜６３５については、図２に示したスキーマ生成装置の各構成要素と同様、適宜統合または分散してもよい。
【０１１４】
そして、ＣＰＵ６４０が、これらのプログラム６３１〜６３５をＲＯＭ６３０から読み出して実行することで、図３２に示すように、各プログラム６３１〜６３５は、検索式解析プロセス６４１、ＳＱＬログ収集プロセス６４２、要素分析プロセス６４３、関係分析プロセス６４４およびスキーマ生成プロセス６４５として機能するようになる。
【０１１５】
また、ＨＤＤ６１０には、図３２に示すように、ＣＩ名リスト６１１、テーブル名リスト６１２、ＣＩ候補リスト６１３およびＲｅｌａｔｉｏｎｓｈｉｐ候補リスト６１４が設けられる。そして、ＣＰＵ６４０は、ＣＩ名リスト６１１、テーブル名リスト６１２、ＣＩ候補リスト６１３およびＲｅｌａｔｉｏｎｓｈｉｐ候補リスト６１４に対してデータを登録する。また、ＣＰＵ６４０は、とともに、ＰＵ６４０は、ＣＩ名リスト６１１、テーブル名リスト６１２、ＣＩ候補リスト６１３およびＲｅｌａｔｉｏｎｓｈｉｐ候補リスト６１４からデータを読み出してＲＡＭ６２０に格納し、ＲＡＭ６２０に格納されたデータに基づいて処理を実行する。
【符号の説明】
【０１１６】
１、１０ スキーマ生成装置
２ 要素比較作成部
３ 関係比較作成部
４ スキーマ生成部
１１ 管理ＤＢ
１１ａ ＣＩ名リスト
１１ｂ テーブル名リスト
１１ｃ ＣＩ候補リスト
１１ｄ Ｒｅｌａｔｉｏｎｓｈｉｐ候補リスト
１２ 検索式解析部
１３ ＳＱＬログ収集部
１４ 要素分析部
１５ 関係分析部
１６ スキーマ生成部
２０ ＲＤＢ
【技術分野】
【０００１】
本発明は、スキーマ定義生成装置、スキーマ定義生成方法およびスキーマ定義生成プログラムに関する。
【背景技術】
【０００２】
近年、複数の業務システム同士での提携やマルチベンダ運用管理環境における情報管理のために、異なるシステム間の情報を仮想的に統合するＦＣＭＤＢ（Federated Configuration Management Database）を有する情報管理システムが知られている。
【０００３】
例えば、図３３に例示するように、ＦＣＭＤＢは、構成情報管理システムと保守契約情報管理システムとのそれぞれに記憶されるデータを仮想的に統合して管理する。ここで、ＦＣＭＤＢは、複数のスキーマで記述されたデータを管理することで、複数のシステムに記憶されるデータを仮想的に統合している。
【０００４】
このため、情報管理システムの目的に応じたスキーマ定義を手動で作成する作業が実施されている。具体的には、スキーマ定義を作成する作業として、ＦＣＭＤＢの管理項目をＣＩまたはＲｅｌａｔｉｏｎｓｈｉｐとして設計し、統合時に必要となる情報を選別した後、ＦＣＭＤＢのスキーマ定義を管理者が手動で作成している。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特表２００１−５１８６７０号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかしながら、上述のスキーマ定義を手動で作成する方式では、複数のシステムに対して繰り返し作業が発生することや、必要となる情報を選別することを手動で行うので、スキーマ定義作成作業に工数が掛かり、スキーマ定義を迅速に作成できないという課題があった。
【０００７】
一つの側面では、スキーマ定義を自動的に作成することで、スキーマ定義作成作業の工数を削減し、スキーマ定義を迅速に作成することを目的とする。
【課題を解決するための手段】
【０００８】
第一の案では、管理対象である構成要素を示す構成要素情報を検索するための検索式に含まれる構成要素情報とリレーショナルデータベースへの問い合わせ履歴情報に含まれるテーブル情報とを比較して、対応関係情報を作成する。そして、検索式に含まれる構成要素間の関係を示す関係情報と問い合わせ履歴情報に含まれるとテーブル間の関係を示す情報とを比較して、関係情報と問い合わせ履歴情報との対応関係を示す対応関係情報を作成する。その後、作成された対応関係情報を用いて、構成要素情報のスキーマ定義および関係情報のスキーマ定義を作成する。
【発明の効果】
【０００９】
スキーマ定義を自動で生成することで、スキーマ定義作成作業の工数を削減し、スキーマ定義を迅速に作成することができる。
【図面の簡単な説明】
【００１０】
【図１】図１は、実施例１に係るスキーマ生成装置の構成を示すブロック図である。
【図２】図２は、実施例２に係るスキーマ生成装置の構成を示すブロック図である。
【図３】図３は、検索式の一例を示す図である。
【図４】図４は、ＳＱＬのログを示す図である。
【図５】図５は、ＣＩ名リストの一例を示す図である。
【図６】図６は、テーブル名リストの一例を示す図である。
【図７】図７は、ＣＩ候補リストの一例を示す図である。
【図８】図８は、Ｒｅｌａｔｉｏｎｓｈｉｐ候補リストの一例を示す図である。
【図９】図９は、ＣＩとテーブルの対応関係を生成する処理を説明する図である。
【図１０】図１０は、異なるスキーマのテーブル間で辞書を生成する処理を説明する図である。
【図１１】図１１は、ＲｅｌａｔｉｏｎｓｈｉｐとＳＱＬ文の対応関係を生成する処理を説明する図である。
【図１２】図１２は、スキーマを生成する処理を説明する図である。
【図１３】図１３は、実施例２に係るスキーマ生成装置の処理動作全体を示すフローチャートである。
【図１４】図１４は、実施例２に係るスキーマ生成装置のＣＩマッチング処理の動作を示すフローチャートである。
【図１５】図１５は、実施例２に係るスキーマ生成装置のＲｅｌａｔｉｏｎｓｈｉｐマッチング処理の動作を示すフローチャートである。
【図１６】図１６は、実施例２に係るスキーマ生成装置のスキーマ生成処理の動作を示すフローチャートである。
【図１７】図１７は、実施例３に係るスキーマ生成装置の構成を示すブロック図である。
【図１８】図１８は、テーブル未割当リストの一例を示す図である。
【図１９】図１９は、リコンサイル候補リストの一例を示す図である。
【図２０】図２０は、ＣＩ・Ｒｅｌａｔｉｏｎｓｈｉｐリストの一例を示す図である。
【図２１】図２１は、ＣＩ未割当リストの一例を示す図である。
【図２２】図２２は、パターンリストの一例を示す図である。
【図２３】図２３は、ＣＩ名に対応付けられていないテーブルに対するリコンサイル先推定処理を説明する図である。
【図２４】図２４は、検索式によって推定したモデルを辿れるかどうか検証する図である。
【図２５】図２５は、検証に失敗した場合の再検証処理を説明する図である。
【図２６】図２６は、検証に失敗した場合の再検証処理を具体的に説明する図である。
【図２７】図２７は、スキーマを生成する処理を説明する図である。
【図２８】図２８は、実施例３に係るスキーマ生成装置の処理動作全体を示すフローチャートである。
【図２９】図２９は、実施例３に係るスキーマ生成装置のＣＩマージ処理の動作を示すフローチャートである。
【図３０】図３０は、実施例３に係るスキーマ生成装置の検証処理の動作を示すフローチャートである。
【図３１】図３１は、実施例３に係るスキーマ生成装置のパターン変更処理の動作を示すフローチャートである。
【図３２】図３２は、スキーマ生成プログラムを実行するコンピュータを示す図である。
【図３３】図３３は、データセンタの構成を説明する図である。
【発明を実施するための形態】
【００１１】
以下に、本願の開示するスキーマ定義生成装置、スキーマ定義生成方法およびスキーマ定義生成プログラムの実施例を図面に基づいて詳細に説明する。なお、この実施例によりこの発明が限定されるものではない。
【実施例１】
【００１２】
まず、図１を用いて、実施例１に係るスキーマ生成装置の構成について説明する。図１は、実施例１に係るスキーマ生成装置の構成を示すブロック図である。
【００１３】
実施例１に係るスキーマ生成装置１は、要素比較作成部２、関係比較作成部３およびスキーマ生成部４を有し、リレーショナルデータベース５（図１では、「ＲＤＢ」と記載）と接続される。また、スキーマ生成装置１は、管理対象である構成要素を示す構成要素情報を検索するための検索式の入力を受け付けるとともに、リレーショナルデータベース５から問い合わせ履歴情報を収集する。
【００１４】
要素比較作成部２は、管理対象である構成要素を示す構成要素情報を検索するための検索式に含まれる構成要素情報と、リレーショナルデータベース５への問い合わせ履歴情報に含まれるテーブル情報とを比較し、構成要素情報とテーブル情報との対応関係を示す対応関係情報を作成する。
【００１５】
関係比較作成部３は、検索式に含まれる構成要素間の関係を示す関係情報と、問い合わせ履歴情報に含まれるとテーブル間の関係を示す情報とを比較し、関係情報と問い合わせ履歴情報との対応関係を示す対応関係情報を作成する。
【００１６】
スキーマ生成部４は、要素比較作成部２によって作成された対応関係情報と、関係比較作成部３によって作成された対応関係情報とを用いて、構成要素情報のスキーマ定義および関係情報のスキーマ定義を生成する。
【００１７】
つまり、実施例１に係るスキーマ生成装置１では、検索式や問い合わせ履歴情報などの既存の情報を利用することで、スキーマ定義を自動で生成することができる結果、スキーマ作成の工数を削減することができる。
【実施例２】
【００１８】
以下に、実施例２に係るスキーマ生成装置の構成および処理の流れを順に説明し、最後に実施例２による効果を説明する。
【００１９】
［スキーマ生成装置の構成］
まず、図２を用いて、スキーマ生成装置１０の構成を説明する。図２は、実施例２に係るスキーマ生成装置の構成を示すブロック図である。図２に示すように、このスキーマ生成装置１０は、管理ＤＢ１１、検索式解析部１２、ＳＱＬログ収集部１３、要素分析部１４、関係分析部１５、スキーマ生成部１６を有し、ＲＤＢ２０と接続される。
【００２０】
また、スキーマ生成装置１０は、ＦＣＭＤＢ向けに拡張したＸｐａｔｈ（ＸＭＬ Ｐａｔｈ Ｌａｎｇｕａｇｅ）で記述された検索式（例えば、後に詳述する図３参照）を受け付けるとともに、ＲＤＢ２０に記憶されたＳＱＬログ（例えば、後に詳述する図４参照）を収集する。ここで、検索式とは、ＣＩを検索するための検索式のことをいい、検索式にはＣＩおよびＲｅｌａｔｉｏｎｓｈｉｐの情報や構造が含まれている。また、ＳＱＬログとは、リレーショナルデータベースへ問い合わせた履歴のことをいい、ＳＱＬログにはテーブルの情報やテーブル間の関係が含まれている。
【００２１】
ＦＣＭＤＢ向けに拡張した検索式は、情報を要求するＣＩの種別やＲｅｌａｔｉｏｎｓｈｉｐなどを指定する。例えば、サーバ装置の情報、すなわちＣＩ種別「Server」を有するＣＩの情報を要求する場合、検索式は「%Server」で表される。なお、名称の前に「%」を付すことにより、その名称がＣＩの名称であることが特定される。
【００２２】
また、ＣＩ及びＲｅｌａｔｉｏｎｓｈｉｐを交互に並べることで、ＣＩ間の関係を辿る検索が可能となる。例えば、サーバ装置の管理者の情報を要求する場合、検索式は、「%Server==>%User」で表される。なお、「==>」はＲｅｌａｔｉｏｎｓｈｉｐを示す。
【００２３】
また、「%」の後に「*」を付すことにより、全てのＣＩ種別を指定した検索が可能となる。例えば、「%Server==>%*」で表される検索式は、ＣＩ種別「Server」と何らかの関係を持つＣＩの情報が要求されていることを示す。
【００２４】
また、ＣＩ種別の後に、要求するＣＩを具体的に指定する情報を付すことにより、ＣＩについての詳細検索が可能となる。例えば、名前がAであるようなサーバ装置の情報を要求する検索式は、「%Server[@name=='A']」で表される。
【００２５】
管理ＤＢ１１は、各種処理に必要なデータを記憶するとともに、ＣＩ名リスト１１ａ、テーブル名リスト１１ｂ、ＣＩ候補リスト１１ｃ、Ｒｅｌａｔｉｏｎｓｈｉｐ候補リスト１１ｄを記憶する。
【００２６】
ＣＩ名リスト１１ａは、検索式に含まれるＣＩ名を記憶する。具体的には、ＣＩ名リスト１１ａは、図５に示すように、ＣＩ名を一意に識別する「ＩＤ」と、検索式に含まれる「ＣＩ名」とを対応付けて記憶する。例えば、図３の例を用いて具体的に説明すると、ＣＩリスト１１ａは、図３に例示する検索式に含まれるＣＩ名「Ｓｅｒｖｉｃｅ」、「Ｓｅｒｖｅｒ」、「ＣＰＵ」をそれぞれ記憶する。
【００２７】
テーブル名リスト１１ｂは、ＳＱＬログに含まれるテーブル名を記憶する。具体的には、テーブル名リスト１１ｂは、図６に示すように、テーブル名を一意に識別する「ＩＤ」と、テーブルのスキーマ種別を示す「スキーマ」と、ＳＱＬログに含まれる「テーブル名」とを対応付けて記憶する。
【００２８】
ＣＩ候補リスト１１ｃは、ＣＩ名リスト１１ａに記憶されたＣＩ名のうち、テーブル名リスト１１ｂに記憶されたテーブル名と一致するＣＩ名をＣＩ候補として記憶する。具体的には、図７に示すように、ＣＩ候補リスト１１ｃは、ＣＩ候補を一意に識別する「ＩＤ」と、ＣＩ候補の「ＣＩ名」と、ＣＩ名と一致するテーブル名のＩＤを示す「テーブル」とを対応付けて記憶する。
【００２９】
Ｒｅｌａｔｉｏｎｓｈｉｐ候補リスト１１ｄは、ＣＩ名候補リスト１１ｃのうち、検索式中でＲｅｌａｔｉｏｎｓｈｉｐ名の前後のＣＩに対応するテーブル名の組をＲｅｌａｔｉｏｎｓｈｉｐ候補として記憶する。具体的には、Ｒｅｌａｔｉｏｎｓｈｉｐ候補リスト１１ｄは、図８に示すように、Ｒｅｌａｔｉｏｎｓｈｉｐ候補を一意に識別する「ＩＤ」と、Ｒｅｌａｔｉｏｎｓｈｉｐ名の前後のＣＩに対応するテーブル名の組である「テーブル（１）」および「テーブル（２）」と、テーブル名の組のＳＱＬ文での関係を示す「関係」とを対応付けて記憶する。
【００３０】
ここで、図４のＳＱＬログの例を用いて、テーブル名の組のＳＱＬでの関係について説明する。ＳＱＬログに含まれる特定のＳＱＬ文（例えば、副文問い合わせ、結合、キー制約など）から、テーブル名の組のＳＱＬでの関係を特定する。例えば、図４に例示するように、テーブル名「ｓｅｒｖｅｒ」にキー制約を示す「ＦＯＲＥＧＮ ＫＥＹ（ｓｅｒｖｉｃｅｉｄ）」が含まれている。この場合には、テーブル名「ｓｅｒｖｉｃｅ」とテーブル名「Ｓｅｒｖｅｒ」との関係が「キー制約」であるものとしてＲｅｌａｔｉｏｎｓｈｉｐ候補リスト１１ｄに記憶される。
【００３１】
また、図４のＳＱＬログにおいて、テーブル名「ＰｈｙｓｉｃａｌＳｅｒｖｅｒ」に結合を示す「ＪＯＩＮ ＣＰＵ ＯＮ」が含まれている。この場合には、テーブル名「ＰｈｙｓｉｃａｌＳｅｒｖｅｒ」とテーブル名「ＣＰＵ」との関係が「結合」であるものとしてＲｅｌａｔｉｏｎｓｈｉｐ候補リスト１１ｄに記憶される。
【００３２】
検索式解析部１２は、拡張したＸｐａｔｈ（ＸＭＬ Ｐａｔｈ Ｌａｎｇｕａｇｅ）で記述された検索式を解析してＣＩ名リスト１１ａを生成する。具体的には、検索式解析部１２は、図３に例示するような検索式を受け付けると、検索式を分割してＣＩ名リスト１１ａを生成し、生成したＣＩ名リストを管理ＤＢ１１に格納する。例えば、検索式解析部１２は、図３に例示する検索式を受け付けた場合には、検索式を「Ｓｅｒｖｉｃｅ」、「Ｓｅｒｖｅｒ」、「ＣＰＵ」に分割し、ＣＩ名「Ｓｅｒｖｉｃｅ」、「Ｓｅｒｖｅｒ」および「ＣＰＵ」を管理ＤＢ１１のＣＩ名リスト１１ａに記憶させる。
【００３３】
ＳＱＬログ収集部１３は、ＲＤＢ２０からＳＱＬログを収集する。具体的には、ＳＱＬログ収集部１３は、ＳＱＬログをＲＤＢ２０から収集し、テーブル名リスト１１ｂを生成し、生成したテーブル名リスト１１ｂを管理ＤＢ１１に記憶させる。例えば、ＳＱＬログ収集部１３は、図４に例示するＳＱＬログを収集した場合には、テーブル名「Ｓｅｒｖｉｃｅ」、「Ｓｅｒｖｅｒ」、「ＰｈｙｓｉｃａｌＳｅｒｖｅｒ」、「ＣＰＵ」および「Ｕｓｅｒ」を管理ＤＢ１１のテーブル名リスト１１ｂに記憶させる。
【００３４】
要素分析部１４は、ＣＩを検索するための検索式に含まれるＣＩ情報と、リレーショナルデータベース２０へのＳＱＬログに含まれるテーブル情報を比較し、構成要素情報とテーブル情報との対応関係を示すＣＩ候補リスト１１ｃを作成する。具体的には、要素分析部１４は、ＣＩ名リスト１１ａからＣＩ名を一つ取り出し、テーブル名リスト１ｂからテーブル名を１件取得する。
【００３５】
そして、要素分析部１４は、比較関数群（完全比較や部分比較）を用いて、ＣＩ名とテーブル名とを比較し、ＣＩ名とテーブル名とが一致するか判定する。この結果、要素分析部１４は、ＣＩ名とテーブル名とが一致した場合には、対応関係を生成してＣＩ候補リスト１１ｃに格納する。
【００３６】
ここで、図９を用いて、ＣＩとテーブルの対応関係を生成する処理について説明する。図９は、ＣＩとテーブルの対応関係を生成する処理を説明する図である。図９に示すように、要素分析部１４は、検索式に含まれるＣＩ名とＳＱＬログに含まれるテーブル名のマッチングを行い、ＣＩとテーブルの関係の候補をリストアップし、ＣＩ候補リスト１１ｃに記憶させる。
【００３７】
また、要素分析部１４は、全てのテーブル名について比較する処理を済ませた後に、ＣＩ名リスト１１ａから１件ＣＩを取得し、ＣＩ候補リスト１１ｃに該当ＣＩ名が複数件存在する場合には、同一のＣＩ名同士の対応関係を記憶する辞書を生成してもよい。
【００３８】
ここで、図１０を用いて、異なるスキーマのテーブル間で辞書を生成する処理について説明する。例えば、図１０に例示するように、要素分析部１４は、ＣＩ候補リストにＣＩ名「Ｓｅｒｖｅｒ」が複数件存在し、スキーマが異なるテーブルが割り当てられた場合には、既存の辞書生成方式用いて、ＣＩ名「Ｓｅｒｖｅｒ」同士の関係が紐付けられた辞書情報を作成する。
【００３９】
関係分析部１５は、検索式に含まれるＲｅｌａｔｉｏｎｓｈｉｐと、ＳＱＬログに含まれるとテーブル間の関係を示す特定のＳＱＬ文とを比較し、ＲｅｌａｔｉｏｎｓｈｉｐとＳＱＬとの対応関係を示すＲｅｌａｔｉｏｎｓｈｉｐ候補リスト１１ｄを作成する。具体的には、関係分析部１５は、検索式からＲｅｌａｔｉｏｎｓｈｉｐを一つ取り出すと、リレーションシップの前後のＣＩに対応するテーブル名をＣＩ候補リスト１１ｃから取り出す。
【００４０】
そして、関係分析部１５は、ＳＱＬログ中の関係をリストアップし、対応するＲｅｌａｔｉｏｎｓｈｉｐとの関係の有無と種類をＲｅｌａｔｉｏｎｓｈｉｐ候補リスト１１ｄに格納する。ここで、図１１を用いて、ＲｅｌａｔｉｏｎｓｈｉｐとＳＱＬ文の対応関係を生成する処理を説明する。図１１は、ＲｅｌａｔｉｏｎｓｈｉｐとＳＱＬ文の対応関係を生成する処理を説明する図である。図１１に示すように、関係分析部１５は、検索式中で着目するＲｅｌａｔｉｏｎｓｈｉｐが結ぶＣＩに紐付けられたテーブルをＣＩ候補リスト１１ｃから取得し、テーブル名を含む特定のＳＱＬを検索する。
【００４１】
例えば、図１１の例では、ＣＩ名「Ｓｅｖｉｃｅ」とＣＩ名「Ｓｅｒｖｅｒ」との関係を示すＲｅｌａｔｉｏｎｓｈｉｐに着目した場合に、関係分析部１５は、ＣＩ名「Ｓｅｖｉｃｅ」に紐付けられたテーブル名「Ｓｅｒｖｉｃｅ」とＣＩ名「Ｓｅｒｖｅｒ」に紐付けられたテーブル名「ＰｈｙｓｉｃａｌＳｅｒｖｅｒ」とを含む特定のＳＱＬ文を検索する。この結果、関係分析部１５は、「ＣＲＥＡＴＥ ＴＡＢＬＥ ＰｈｙｓｉｃａｌＳｅｒｖｅｒ・・・ＦＯＲＥＩＧＮ ＫＥＹ（ｃｐｕｉｄ）ＲＥＦＥＲＥＮＣＥＳ ＣＰＵ（ｉｄ）」を取得する。
【００４２】
ここで、関係分析部１５は、キー制約を示す「ＦＯＲＥＩＧＮ ＫＥＹ」が含まれているので、リレーションシップ候補リストに関係の種類「キー制約」であることをＲｅｌａｔｉｏｎｓｈｉｐ候補リスト１１ｄに記憶する。
【００４３】
スキーマ生成部１６は、ＣＩ候補リスト１１ｃおよびＲｅｌａｔｉｏｎｓｈｉｐ候補リスト１１ｄを用いて、ＣＩのスキーマ定義およびＲｅｌａｔｉｏｎｓｈｉｐのスキーマ定義を生成する。具体的には、スキーマ生成部１６は、ＣＩ名リスト１１ａから１件取り出し、ＣＩ候補リスト１１ｃとテーブル名リスト１１ｂからテーブル名を取り出す。
【００４４】
そして、スキーマ生成部１６は、ＳＱＬログを検索し、含まれる属性名を取得し、テーブル名と取得した属性名を元に、ＣＩ定義を生成する。そして、スキーマ生成部１６は、全てのＣＩに対してＣＩ定義を生成すると、Ｒｅｌａｔｉｏｎｓｈｉｐ候補リスト１１ｄから１件取り出し、ＣＩ候補リストを参照してＲｅｌａｔｉｏｎｓｈｉｐ定義を作成する。
【００４５】
その後、スキーマ生成部１６は、全てのリレーションシップ候補についてＲｅｌａｔｉｏｎｓｈｉｐ定義を作成する処理を繰り返す。例えば、スキーマ生成部１６は、生成するスキーマとして、図１２に例示するように、ＣＩ定義およびＲｅｌａｔｉｏｎｓｈｉｐ定義を生成する。
【００４６】
図１２の例では、スキーマ生成部１６は、ＣＩタイプが「Ｓｅｒｖｅｒ」、「ＣＰＵ」、「Ｓｅｒｖｉｃｅ」であるＣＩ定義を生成し、Ｒｅｌａｔｉｏｎｓｈｉｐタイプが「Ｓｅｒｖｅｒ−ＣＰＵ」、「Ｓｅｒｖｉｃｅ−Ｓｅｒｖｅｒ」であるＲｅｌａｔｉｏｎｓｈｉｐ定義を生成している。
【００４７】
例えば、スキーマ生成部１６は、図４に例示するＳＱＬログの「ＴＡＢＬＥ Ｓｅｒｖｉｃｅ」からＣＩタイプ「Ｓｅｒｖｉｃｅ」のＣＩ定義を生成する場合について説明する。図４に例示するＳＱＬログの「ＴＡＢＬＥ Ｓｅｒｖｉｃｅ」には、サービスのＩＤを示す「ｉｄ」、ユーザのＩＤを示す「ｕｓｅｒ＿ｉｄ」、サービス名称を示す「ｎａｍｅ」が列名で記載されている。スキーマ生成部１６は、これらの列名を用いて、「ｉｄ」、「ｕｓｅｒ＿ｉｄ」および「Ｓｅｒｖｉｃｅ」をＣＩ定義として生成する。
【００４８】
また、例えば、Ｒｅｌａｔｉｏｎｓｈｉｐタイプが「ＣＰＵ」のＲｅｌａｔｉｏｎｓｈｉｐ定義として、接続元のＣＩを示す「ｓｒｃ」と、接続先のＣＩを示す「ｄｓｔ」とが属性名として定義されている。
【００４９】
このように、検索式およびＳＱＬログなどの簡単に用意できる情報を用いて、スキーマ定義を自動で生成することができ、スキーマ定義作成作業の工数を削減し、スキーマ定義を迅速に作成することができる。
【００５０】
［スキーマ生成装置による処理］
次に、図１３〜図１６を用いて、実施例２に係るスキーマ生成装置１０による処理を説明する。図１３は、実施例２に係るスキーマ生成装置１０の処理動作を示すフローチャートである。図１４は、実施例２に係るスキーマ生成装置のＣＩマッチング処理の動作を示すフローチャートである。図１５は、実施例２に係るスキーマ生成装置のＲｅｌａｔｉｏｎｓｈｉｐマッチング処理の動作を示すフローチャートである。図１６は、実施例２に係るスキーマ生成装置のスキーマ生成処理の動作を示すフローチャートである。
【００５１】
図１３に示すように、スキーマ生成装置１０は、拡張したＸｐａｔｈで記述された検索式を受け付けると、検索式を分割してＣＩ名リストを生成する（ステップＳ１０１）。そして、スキーマ生成装置１０は、ＣＩ名リスト１１ａからＣＩ名を一つ取り出し（ステップＳ１０２）、ＣＩマッチング処理（後に図１４を用いて詳述）を行う（ステップＳ１０３）。
【００５２】
そして、スキーマ生成装置１０は、全てのＣＩについて処理済であるか判定し（ステップＳ１０４）、全てのＣＩが処理済でない場合には（ステップＳ１０４否定）、ステップＳ１０２に戻って処理を繰り返す。
【００５３】
また、スキーマ生成装置１０は、全てのＣＩが処理済である場合には（ステップＳ１０４肯定）、検索式の先頭から順に検索してＲｅｌａｔｉｏｎｓｈｉｐを一つ取り出し（ステップＳ１０５）、Ｒｅｌａｔｉｏｎｓｈｉｐマッチング処理（後に図１５を用いて詳述）を行う（ステップＳ１０６）。
【００５４】
その後、スキーマ生成装置１０は、全てのＲｅｌａｔｉｏｎｓｈｉｐについて処理済であるか判定し（ステップＳ１０７）、全てのＲｅｌａｔｉｏｎｓｈｉｐが処理済でない場合には（ステップＳ１０７否定）、ステップＳ１０５に戻って処理を繰り返す。また、スキーマ生成装置１０は、全てのＲｅｌａｔｉｏｎｓｈｉｐが処理済である場合には（ステップＳ１０７肯定）、スキーマ生成処理（後に図１６を用いて詳述）を行い（ステップＳ１０８）、生成されたスキーマを結果として出力する（ステップＳ１０９）。
【００５５】
次に、図１４を用いて、ＣＩマッチング処理の動作を説明する。図１４に示すように、
スキーマ生成装置１０の要素分析部１４は、テーブル名リスト１ｂからテーブル名を１件取得する（ステップＳ２０１）。そして、要素分析部１４は、比較関数群を用いて、ＣＩ名とテーブル名とを比較し（ステップＳ２０２）、ＣＩ名とテーブル名とが一致するか判定する（ステップＳ２０３）。この結果、要素分析部１４は、ＣＩ名とテーブル名とが一致した場合には（ステップＳ２０３肯定）、ＣＩ候補リスト１１ｃに対応関係を記録する（ステップＳ２０４）。
【００５６】
その後、要素分析部１４は、全てのテーブル名について比較する処理を済ませたか判定し（ステップＳ２０５）、全てのテーブル名について比較する処理を済ませていない場合には（ステップＳ２０５否定）、ステップＳ２０１に戻って処理を繰り返す。また、要素分析部１４は、全てのテーブル名について比較する処理を済ませた場合には（ステップＳ２０５肯定）、ＣＩ名リスト１１ａから１件ＣＩを取得し（ステップＳ２０６）、ＣＩ候補リストに該当ＣＩ名が複数件存在するか判定する（ステップＳ２０７）。
【００５７】
この結果、要素分析部１４は、ＣＩ候補リストに該当ＣＩ名が複数件存在する場合には（ステップＳ２０７肯定）、複数のＣＩ名同士が紐付けられた辞書を生成する（ステップＳ２０８）。その後、要素分析部１４は、全てのＣＩについて処理済みであるか判定し（ステップＳ２０９）、全てのＣＩについて処理済みでない場合には（ステップＳ２０９否定）、Ｓ２０６に戻って処理を繰り返す。また、要素分析部１４は、全てのＣＩについて処理済みである場合には（ステップＳ２０９肯定）、ＣＩマッチング処理を終了する。
【００５８】
次に、図１５を用いて、Ｒｅｌａｔｉｏｎｓｈｉｐマッチング処理の動作を説明する。図１５に示すように、リレーションシップの前後のＣＩに対応するテーブル名をＣＩ候補リスト１１ｃから取り出す。
【００５９】
図１５に示すように、スキーマ生成装置１０の関係分析部１５は、ＣＩ候補リスト１１ｃから、検索式中でリレーションシップの前後のＣＩに対応するテーブル名を取り出す（ステップＳ３０１）。そして、スキーマ生成装置１０は、ＳＱＬログ中の関係をリストアップし（ステップＳ３０２）、対応するＲｅｌａｔｉｏｎｓｈｉｐに関係の有無と種類をＲｅｌａｔｉｏｎｓｈｉｐ候補リスト１１ｄに記録する（ステップＳ３０３）。
【００６０】
次に、図１６を用いて、スキーマ生成処理の動作を説明する。図１６に示すように、スキーマ生成装置１０のスキーマ生成部１６は、ＣＩ名リスト１１ａから１件取り出し（ステップＳ４０１）、ＣＩ候補リスト１１ｃとテーブル名リスト１１ｂからテーブル名を取り出す（ステップＳ４０２）。
【００６１】
そして、スキーマ生成部１６は、ＳＱＬログを検索し、含まれる属性名を取得し（ステップＳ４０３）、テーブル名と取得した属性名を元に、ＣＩ定義を生成する（ステップＳ４０４）。そして、スキーマ生成部１６は、全てのＣＩについて処理済みであるか判定し（ステップＳ４０５）、処理済でない場合には（ステップＳ４０５否定）、ステップＳ４０１に戻って処理を繰り返す。
【００６２】
また、スキーマ生成部１６は、全てのＣＩについて処理済である場合には（ステップＳ４０５肯定）、Ｒｅｌａｔｉｏｎｓｈｉｐ候補リスト１１ｄから１件取り出し（ステップＳ４０６）、ＣＩ候補リストを参照してＲｅｌａｔｉｏｎｓｈｉｐ定義を作成する（ステップＳ４０７）。
【００６３】
その後、スキーマ生成部１６は、全てのリレーションシップ候補についてＲｅｌａｔｉｏｎｓｈｉｐ定義を作成する処理が済んでいるかを判定し（ステップＳ４０８）、全てのリレーションシップ候補についてＲｅｌａｔｉｏｎｓｈｉｐ定義を作成する処理が済んでいない場合には（ステップＳ４０８否定）、ステップＳ４０６に戻る。また、スキーマ生成部１６は、全てのリレーションシップ候補についてＲｅｌａｔｉｏｎｓｈｉｐ定義を作成する処理が済んだ場合には（ステップＳ４０８肯定）、スキーマ生成処理を終了する。
【００６４】
[実施例２の効果]
上述してきたように、スキーマ生成装置１０は、ＣＩを検索するための検索式に含まれるＣＩ情報と、リレーショナルデータベース２０へのＳＱＬログに含まれるテーブル情報を比較し、構成要素情報とテーブル情報との対応関係を示すＣＩ候補リスト１１ｃを作成する。そして、スキーマ生成装置１０は、検索式に含まれるＲｅｌａｔｉｏｎｓｈｉｐと、ＳＱＬログに含まれるとテーブル間の関係を示す特定のＳＱＬ文とを比較し、ＲｅｌａｔｉｏｎｓｈｉｐとＳＱＬとの対応関係を示すＲｅｌａｔｉｏｎｓｈｉｐ候補リスト１１ｄを作成する。その後、スキーマ生成装置１０は、ＣＩ候補リスト１１ｃおよびＲｅｌａｔｉｏｎｓｈｉｐ候補リスト１１ｄを用いて、ＣＩのスキーマ定義およびＲｅｌａｔｉｏｎｓｈｉｐのスキーマ定義を生成する。このため、スキーマ定義を自動で生成することができ、スキーマ定義作成作業の工数を削減し、スキーマ定義を迅速に作成することが可能である。
【００６５】
また、実施例２によれば、検索式に含まれるＣＩの名称とＳＱＬログに含まれるテーブル情報の名称とを比較し、当該構成要素情報の名称とテーブルの名称とが一致する組を前記対応関係情報として作成する。このため、検索式およびＳＱＬログなどの簡単に用意できる情報を用いて、スキーマ定義を自動で生成することができ、スキーマ定義作成作業の工数を削減し、スキーマ定義を迅速に作成することが可能である。
【実施例３】
【００６６】
ところで、上記の実施例２では、ＣＩマッチング処理およびＲｅｌａｔｉｏｎｓｈｉｐマッチング処理を行った後に、スキーマ生成処理を行っているが、本発明はこれに限定されるものではない。例えば、ＣＩマッチング処理およびＲｅｌａｔｉｏｎｓｈｉｐマッチング処理を行った後に、リコンサイル先を推定するＣＩマージ処理や検索式どおりにＣＩおよびＲｅｌａｔｉｏｎｓｈｉｐを辿れるかを検証する検証処理を行ってもよい。
【００６７】
そこで、以下の実施例３では、ＣＩマッチング処理およびＲｅｌａｔｉｏｎｓｈｉｐマッチング処理を行った後に、ＣＩマージ処理および検証処理を行う場合として、実施例３におけるスキーマ生成装置１０Ａの構成と処理について説明する。
【００６８】
まず、図１７を用いてスキーマ生成装置１０Ａの構成について説明する。図１７に示すように、スキーマ生成装置１０Ａは、図２に示したスキーマ生成装置１０と比較して、テーブル未割当リスト１１ｅ、リコンサイル候補リスト１１ｆ、ＣＩ・Ｒｅｌａｔｉｏｎｓｈｉｐリスト１１ｇ、ＣＩ未割当リスト１１ｈ、パターンリスト１１ｉ、従属要素推定部１７および検証部１８を新たに有する点が相違する。
【００６９】
テーブル未割当リスト１１ｅは、ＣＩに対応付けられていないテーブル名を記憶する。具体的には、テーブル未割当リスト１１ｅは、図１８に示すように、ＣＩに対応付けられていないテーブルを一意に識別する「ＩＤ」と、ＣＩに対応付けられていないテーブルのＩＤを示す「テーブル名」とを対応付けて記憶する。
【００７０】
リコンサイル候補リスト１１ｆは、ＣＩに対応付けられていないテーブルのリコンサイル先の候補を記憶する。具体的には、リコンサイル候補リスト１１ｆは、図１９に示すように、リコンサイル先候補を一意に識別する「ＩＤ」と、リコンサイル先のテーブルを示す「テーブル（先）」と、リコンサイル元のテーブルを示す「テーブル（元）」とを対応付けて記憶する。
【００７１】
ＣＩ・Ｒｅｌａｔｉｏｎｓｈｉｐリスト１１ｇは、ＣＩおよびＲｅｌａｔｉｏｎｓｈｉｐを記憶する。具体的には、ＣＩ・Ｒｅｌａｔｉｏｎｓｈｉｐリスト１１ｇは、ＣＩまたはＲｅｌａｔｉｏｎｓｈｉｐを一意に識別する「ＩＤ」と、ＣＩまたはＲｅｌａｔｉｏｎｓｈｉｐの種別を示す「ＣＩ／Ｒｅｌ」とを対応付けて記憶する。
【００７２】
ＣＩ未割当リスト１１ｈは、検証に失敗した原因となるＣＩを記憶する。具体的には、ＣＩ未割当リスト１１ｈは、検証に失敗した原因となるＣＩ候補を一意に識別する「ＩＤ」と、検証に失敗した原因となるＣＩの名称を示す「ＣＩ名」と、検証に失敗した原因となるＣＩに対応するテーブルを一意に識別する「テーブル」とを対応付けて記憶する。
【００７３】
従属要素推定部１７は、ＣＩと対応付けられずに残ったテーブルに関連するＳＱＬ文を分析し、残ったテーブルのリコンサイル先のＣＩを推定する。具体的には、従属要素推定部１７は、ＣＩと対応付けられずに残ったテーブル名を含む特定のＳＱＬ文を検索し、それに含まれるテーブル名を取得することで、リコンサイル先をリストアップする。ここで、特定のＳＱＬ文とは、副文問い合わせ、結合、キー制約などである。
【００７４】
例えば、図２３の例を用いて説明すると、ＣＩと対応付けられずに「Ｕｓｅｒ」テーブルが残った場合に、従属要素推定部１７は、テーブル名「Ｕｓｅｒ」を含む特定のＳＱＬ文を検索する。
【００７５】
この検索の結果、従属要素推定部１７は、ＳＱＬ文「Ｓｅｌｅｃｔ＊ＦＲＯＭ Ｓｅｖｉｃｅ ＷＨＥＲＥ ｕｓｅｒ＿ｉｄ＝（ＳＥＬＥＣＴ ｉｄ ＦＲＯＭ Ｕｓｅｒ ＷＨＥＲ ｎａｍｅ＝“Ｓｕｚｕｋｉ”）；」をＳＱＬログから取得する。かかるＳＱＬ文「Ｓｅｌｅｃｔ＊ＦＲＯＭ Ｓｅｖｉｃｅ ＷＨＥＲＥ ｕｓｅｒ＿ｉｄ＝（ＳＥＬＥＣＴ ｉｄ ＦＲＯＭ Ｕｓｅｒ ＷＨＥＲ ｎａｍｅ＝“Ｓｕｚｕｋｉ”）；」は、テーブル名「Ｕｓｅｒ」を含む副文問い合わせのＳＱＬ文である。
【００７６】
そして、従属要素推定部１７は、ＳＱＬ文「Ｓｅｌｅｃｔ＊ＦＲＯＭ Ｓｅｖｉｃｅ ＷＨＥＲＥ ｕｓｅｒ＿ｉｄ＝（ＳＥＬＥＣＴ ｉｄ ＦＲＯＭ Ｕｓｅｒ ＷＨＥＲ ｎａｍｅ＝“Ｓｕｚｕｋｉ”）；」に含まれるもう一つのテーブル名「Ｓｅｒｖｉｃｅ」をリコンサイル先として推定する。その後、従属要素推定部１７は、ＣＩと対応付けられずに残ったテーブルと推定されたリコンサイル先のテーブルを対応付けてリコンサイル候補リスト１１ｆに記憶させる。
【００７７】
検証部１８は、検索式通りにＣＩおよびＲｅｌａｔｉｏｎｓｈｉｐを辿れるか検証する。具体的には、検証部１８は、検索式を分割し、ＣＩ・Ｒｅｌａｔｉｏｎｓｈｉｐリスト１１ｇを作成する。そして、検索部１８は、図２４に示すように、ＣＩ・Ｒｅｌａｔｉｏｎｓｈｉｐリスト１１ｇからＣＩまたはＲｅｌａｔｉｏｎｓｈｉｐを一つずつ取り出して、検索式通りにＣＩおよびＲｅｌａｔｉｏｎｓｈｉｐを辿れるかを検証する。
【００７８】
例えば、図２４の例では、検索式が「％Ｓｅｒｖｉｃｅ→％Ｓｅｒｖｅｒ→％ＣＰＵ」である場合に、検証部１８は、ＣＩ・Ｒｅｌａｔｉｏｎｓｈｉｐリスト１１ｇからＣＩまたはＲｅｌａｔｉｏｎｓｈｉｐを一つずつ取り出す。そして、検証部１８は、ＣＩ「Ｓｅｒｖｉｃｅ」、「Ｒｅｌａｔｉｏｎｓｈｉｐ」、「Ｓｅｒｖｅｒ」、「Ｒｅｌａｔｉｏｎｓｈｉｐ」、「ＣＰＵ」の順に辿れるかを検証する。
【００７９】
ここで、検証に失敗する場合について説明する。例えば、検証部１８は、図２５に示すように、検証の結果、該当するＲｅｌａｔｉｏｎｓｈｉｐが複数存在する場合や辿る先のＣＩが複数のテーブルに対応付けられている場合に、検索通りにＣＩおよびＲｅｌａｔｉｏｎｓｈｉｐを辿ることができない。
【００８０】
例えば、図２５の例では、ＣＩ「ＰｈｙｓｉｃａｌＳｅｒｖｅｒ」に複数のテーブル「ＰｈｙｓｉｃａｌＳｅｒｖｅｒ」、「Ｓｅｒｖｅｒ」が対応付けられており、Ｒｅｌａｔｉｏｎｓｈｉｐが複数存在する。このため、検証部１８は、検索通りにＣＩおよびＲｅｌａｔｉｏｎｓｈｉｐを辿ることができない。
【００８１】
検証部１８は、検証に失敗した場合には、辿ることができなかった原因となったＣＩとそのＣＩに対応するテーブルをＣＩ未割当リスト１１ｈに格納する。そして、辿ることができなかった原因となるＣＩとテーブルの関連付け数を減らす条件パターンを生成してパターンリスト１１ｉに格納する。そして、検証部１８は、検証が成功するまで、条件パターンを順に適用して検証処理を繰り返す。
【００８２】
例えば、図２６の例では、検証部１８は、検索式「％Ｓｅｒｖｉｃｅ→％Ｓｅｒｖｅｒ→％ＰｈｙｓｉｃａｌＳｅｒｖｅｒ→％ＣＰＵ」について、検証処理を行った場合に、ＣＩ「Ｓｅｒｖｅｒ」に複数の経路が存在し、検証に失敗する。ここで、検証部１８は、辿ることができなかった原因となったＣＩ「Ｓｅｒｖｅｒ」の情報をＣＩ未割当リスト１１ｈに格納する。
【００８３】
そして、検証部１８は、辿ることができなかった原因となったＣＩ「Ｓｅｒｖｅｒ」に関係するテーブル名「ＰｈｙｓｉｃａｌＳｅｒｖｅｒ」、「Ｓｅｒｖｅｒ」、「Ｓｅｒｖｅｒ」をＣＩ候補リストから取得する。そして、検証部１８は、ＣＩとテーブルの対応付けを部分的に無効にしたパターンをパターンリスト１１ｉに格納する。そして、パターンを一つずつ順に取り出し、パターンを順に適用して検証が成功するまで、検証処理を繰り返す。
【００８４】
スキーマ生成部１６は、実施例２と同様に、ＣＩのスキーマ定義およびＲｅｌａｔｉｏｎｓｈｉｐのスキーマ定義を生成する。ここで、実施例３に係るスキーマ生成装置１０Ａでは、前述した従属要素推定部１７が、ＣＩと対応付けられずに残ったテーブルのリコンサイル先のＣＩを推定している。このため、図２７に例示するように、実施例３に係るスキーマ生成装置１０Ａは、図１２に例示したスキーマと比較して、ＣＩと対応付けられずに残ったテーブの情報がマージされて、ＣＩタイプ「Ｓｅｒｖｉｃｅ」に「＠ｕｓｅｒ＿ｎａｍｅ」が追加されている。
【００８５】
次に、実施例３に係るスキーマ生成装置の処理動作全体について図２８〜図３１を用いて説明する。実施例３に係るスキーマ生成装置は、図１３に示した実施例２にかかるスキーマ生成装置と比較して、ＣＩマージ処理、検証処理およびパターン変更処理を新たに行う点が相違する。
【００８６】
すなわち、図２８に示すように、スキーマ生成装置１０Ａは、実施例２と同様に、全てのＣＩについてマッチング処理を行い（ステップＳ５０１〜Ｓ５０４）、全てのＲｅｌａｔｉｏｎｓｈｉｐについてマッチング処理を行う（ステップＳ５０５〜５０７）。その後、実施例３に係るスキーマ生成装置は、ＣＩマージ処理（後に図２９を用いて詳述）を行い（ステップＳ５０８）、ＸｐａｔｈによってＣＩおよびＲｅｌａｔｉｏｎｓｈｉｐが辿れるかどうかを検証する検証処理（後に図３０を用いて詳述）を行う（ステップＳ５０９）。
【００８７】
検証の結果、スキーマ生成装置１０Ａは、検索式を満たす定義になっているか判定し（ステップＳ５１０）、検索式を満たす定義になっている場合には（ステップＳ５１０肯定）、実施例２と同様にスキーマ生成処理を行って（ステップＳ５１１）、生成されたスキーマ定義の結果を出力する（ステップＳ５１４）。
【００８８】
また、検証の結果、スキーマ生成装置１０Ａは、検索式を満たす定義になっていない場合には（ステップＳ５１０否定）、パターン変更が可能か判定する（ステップＳ５１２）。具体的には、スキーマ生成装置１０Ａは、パターン変更済みかつ全パターン処理を行った場合、または終了フラグが立っている場合には、パターン変更が可能でないと判定する。
【００８９】
この結果、スキーマ生成装置１０Ａは、パターン変更が可能である場合には（ステップＳ５１２肯定）、パターン変更処理（後に図３１を用いて詳述）を行った後（ステップＳ５１３）、ステップＳ５０２に戻って処理を繰り返す。また、スキーマ生成装置１０Ａは、パターン変更が可能でない場合には（ステップＳ５１２否定）、結果を出力する（ステップＳ５１４）。
【００９０】
ここで、図２９を用いて、ＣＩマージ処理の動作について説明する。図２９は、実施例３に係るスキーマ生成装置のＣＩマージ処理の動作を示すフローチャートである。図２９に示すように、スキーマ生成装置１０Ａは、ＣＩリストに出現しないテーブルのテーブル未割当リストを作成し（ステップＳ６０１）、ＳＱＬログ中の関係をリストアップする（ステップＳ６０２）。つまり、スキーマ生成装置１０Ａは、ＳＱＬログ中から未割当リストのテーブル名を含む特定のＳＱＬ文を検索する。
【００９１】
そして、スキーマ生成装置１０Ａは、割当リストのテーブル名を含む特定のＳＱＬ文にテーブル名が存在するか判定し（ステップＳ６０３）、テンプレートに合致するテーブル名が存在する場合には（ステップＳ６０３肯定）、リコンサイル候補リストに記録する（ステップＳ６０４）。また、スキーマ生成装置１０Ａは、テンプレートに合致するテーブル名が存在しない場合には（ステップＳ６０３否定）、リコンサイル候補リストに記録せずにステップＳ６０５に進む。
【００９２】
そして、スキーマ生成装置１０Ａは、未割当リストの全てのテーブル名について処理済であるか判定し（ステップＳ６０５）、処理済でない場合には（ステップＳ６０５否定）、ステップＳ６０２に戻って処理を繰り返す。また、スキーマ生成装置１０Ａは、未割当リストの全てのテーブル名について処理済である場合には（ステップＳ６０５肯定）、ＣＩマージ処理を終了する。
【００９３】
ここで、図３０を用いて、検証処理の動作について説明する。図３０は、実施例３に係るスキーマ生成装置の検証処理の動作を示すフローチャートである。図３０に示すように、スキーマ生成装置１０Ａは、検索式を分割し、ＣＩおよびリレーションシップのリストを作成する（ステップＳ７０１）。
【００９４】
そして、スキーマ生成装置１０Ａは、ＣＩ・Ｒｅｌａｔｉｏｎｓｈｉｐリスト１１ｇに残りが存在するか判定する（ステップＳ７０２）。この結果、スキーマ生成装置１０Ａは、ＣＩ・Ｒｅｌａｔｉｏｎｓｈｉｐリスト１１ｇに残りが存在する場合には（ステップＳ７０２肯定）、ＣＩ・Ｒｅｌａｔｉｏｎｓｈｉｐリスト１１ｇから１件取り出す（ステップＳ７０３）。そして、スキーマ生成装置１０Ａは、取り出した種別がＣＩであるか判定し（ステップＳ７０４）、ＣＩである場合には（ステップＳ７０４肯定）、ＣＩ候補から該当するものを取り出す（ステップＳ７０５）。
【００９５】
そして、スキーマ生成装置１０Ａは、ＣＩ候補から該当するものが存在するか判定し（ステップＳ７０６）、該当するものが存在する場合には（ステップＳ７０６肯定）、ＣＩ・Ｒｅｌａｔｉｏｎｓｈｉｐ名リスト１１ｇ中で直前のＣＩと同じスキーマが割り当てられているか判定する（ステップＳ７０７）。
【００９６】
この結果、スキーマ生成装置１０Ａは、Ｉ・Ｒｅｌａｔｉｏｎｓｈｉｐリスト１１ｇ中で直前のＣＩと同じスキーマが割り当てられている場合には（ステップＳ７０７肯定）、取り出されたＣＩまたはＲｅｌａｔｉｏｎｓｈｉに対して複数テーブルを割り当てられたスキーマが存在するか判定する（ステップＳ７０８）。
【００９７】
そして、スキーマ生成装置１０Ａは、取り出されたＣＩまたはＲｅｌａｔｉｏｎｓｈｉに対して複数テーブルを割り当てられたスキーマが存在する場合には（ステップＳ７０８肯定）、取り出されたＣＩまたはＲｅｌａｔｉｏｎｓｈｉｐのＩＤと該当テーブルのＩＤを出力して（ステップＳ７０９）、検証処理を終了する。また、スキーマ生成装置１０Ａは、取り出されたＣＩまたはＲｅｌａｔｉｏｎｓｈｉに対して複数テーブルを割り当てられたスキーマが存在しない場合には（ステップＳ７０８否定）、ステップＳ７０２に戻る。
【００９８】
また、Ｓ７０６において、スキーマ生成装置１０Ａは、ＣＩ候補から該当するものが存在しない場合（ステップＳ７０６否定）、終了フラグをセットして（ステップＳ７１４）、検証処理を終了する。また、Ｓ７０７において、スキーマ生成装置１０Ａは、Ｉ・Ｒｅｌａｔｉｏｎｓｈｉｐリスト１１ｇ中で直前のＣＩと同じスキーマが割り当てられていない場合には（ステップＳ７０７否定）、終了フラグをセットして（ステップＳ７１４）、検証処理を終了する。
【００９９】
Ｓ７０４の説明に戻って、スキーマ生成装置１０Ａは、取り出した種別がＣＩでない場合には（ステップＳ７０４否定）、直前のＣＩをキーとしてＣＩ候補リスト１１ｃおよびＲｅｌａｔｉｏｎｓｈｉｐ候補リスト１１ｄから該当するものを取り出す（ステップＳ７１０）。そして、スキーマ生成装置１０Ａは、Ｒｅｌａｔｉｏｎｓｈｉｐ候補リストに該当するものが存在するか判定し（ステップＳ７１１）、Ｒｅｌａｔｉｏｎｓｈｉｐ候補リストに該当しない場合には（ステップＳ７１１否定）、終了フラグをセットし（ステップＳ７１４）、検証処理を終了する。
【０１００】
また、スキーマ生成装置１０Ａは、Ｒｅｌａｔｉｏｎｓｈｉｐ候補リストに該当する場合には（ステップＳ７１１肯定）、該当するもののうち、もう一方のテーブル名が複数種類存在するか判定する（ステップＳ７１２）。この結果、スキーマ生成装置１０Ａは、テーブル名が複数種類存在しない場合には（ステップＳ７１２否定）、ステップＳ７０２に戻る。
【０１０１】
また、スキーマ生成装置１０Ａは、テーブル名が複数種類存在する場合には（ステップＳ７１２肯定）、取りだされたＣＩまたはＲｅｌａｔｉｏｎｓｈｉｐのＣＩ・Ｒｅｌａｔｉｏｎｓｈｉｐリスト中におけるＩＤを出力する（ステップＳ７１３）。
【０１０２】
Ｓ７０２の説明に戻って、スキーマ生成装置１０Ａは、ＣＩ・Ｒｅｌａｔｉｏｎｓｈｉｐリストに残りが存在しないと判定した場合には（ステップＳ７０２否定）、検証に成功したものとして（ステップＳ７１５）、検証処理を終了する。
【０１０３】
ここで、図３１を用いて、パターン変更処理の動作について説明する。図３１は、実施例３に係るスキーマ生成装置のパターン変更処理の動作を示すフローチャートである。図３１に示すように、スキーマ生成装置１０Ａは、パターンリストが存在しているかを判定し（ステップＳ８０１）、パターンリストが存在する場合には（ステップＳ８０１肯定）、パターンリストから次のパターンを参照し、該当する定義を無効に設定する（ステップＳ８０８）。
【０１０４】
また、スキーマ生成装置１０Ａは、パターンリストが存在しない場合には（ステップＳ８０１否定）、検証で出力されたのがＣＩであるか判定する（ステップＳ８０２）。この結果、スキーマ生成装置１０は、検証で出力されたのがＣＩである場合には（ステップＳ８０２肯定）、ＣＩ候補リスト１１ｃから検証時出力されたテーブルＩＤとＣＩ・Ｒｅｌａｔｉｏｎｓｈｉｐリスト１１ｇ以外のＣＩ名を共に含む項目を抽出してＣＩ未割当リスト１１ｈを作成する（ステップＳ８０３）。
【０１０５】
また、スキーマ生成装置１０は、検証で出力されたのがＣＩではなくＲｅｌａｔｉｏｎｓｈｉｐである場合には（ステップＳ８０２否定）、ＲｅｌａｔｉｏｎｓｈｉｐのＣＩ・Ｒｅｌａｔｉｏｎｓｈｉｐリスト１１ｇ中でのＩＤの次のＣＩ名を取得する（ステップＳ８０４）。
【０１０６】
そして、スキーマ生成装置１０Ａは、ＣＩ候補から、取得されたＣＩを含むレコードを抽出して未割当リストを作成する（ステップＳ８０５）。続いて、スキーマ生成装置１０は、未割当リストの全要素から全ての組み合わせを作成し（ステップＳ８０６）、空集合以外を要素数が少ない順に並べ替え、パターンリスト１１ｉとして出力する（ステップＳ８０７）。その後、スキーマ生成装置１０Ａは、パターンリスト１１ｉから次のパターンを参照し、該当する定義を無効に設定する（ステップＳ８０８）。
【０１０７】
このように、実施例３に係るスキーマ生成装置１０Ａは、ＳＱＬに含まれるテーブルのうち、いずれのＣＩとも対応関係がなかった未割当のテーブルが存在する場合に、そのテーブルに関連するＳＱＬを分析し、リコンサイル先のＣＩを推定する。このため、対応付けられずに残ったテーブルに関連するＳＱＬ文もさらに利用して、スキーマ定義を作成することができる。
【０１０８】
また、実施例３に係るスキーマ生成装置１０Ａは、作成されたＣＩ候補リスト１１ｃおよびＲｅｌａｔｉｏｎｓｈｉｐ候補リスト１１ｄを用いて、検索式を辿れるかを検証するので、精度の高いスキーマ定義を作成することができる。
【実施例４】
【０１０９】
さて、これまで本発明の実施例について説明したが、本発明は上述した実施例以外にも、種々の異なる形態にて実施されてよいものである。そこで、以下では実施例４として本発明に含まれる他の実施例を説明する。
【０１１０】
（１）システム構成等
また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。例えば、要素分析部１４および関係分析部１５を統合してもよい。
【０１１１】
（２）プログラム
ところで、上記の実施例で説明した各種の処理は、あらかじめ用意されたプログラムをコンピュータで実行することによって実現することができる。そこで、以下では、図３２を用いて、上記の実施例と同様の機能を有するプログラムを実行するコンピュータの一例を説明する。図３２は、スキーマ生成プログラムを実行するコンピュータを示す図である。
【０１１２】
図３２に示すように、スキーマ生成プログラムを実行するコンピュータ６００は、ＨＤＤ６１０、ＲＡＭ６２０、ＲＯＭ６３０およびＣＰＵ６４０をバス６５０で接続して構成される。
【０１１３】
そして、ＲＯＭ６３０には、上記の実施例と同様の機能を発揮するスキーマ生成プログラム、つまり、図３２に示すように、検索式解析プログラム６３１、ＳＱＬログ収集プログラム６３２、要素分析プログラム６３３、関係分析プログラム６３４およびスキーマ生成プログラム６３５が予め記憶されている。なお、プログラム６３１〜６３５については、図２に示したスキーマ生成装置の各構成要素と同様、適宜統合または分散してもよい。
【０１１４】
そして、ＣＰＵ６４０が、これらのプログラム６３１〜６３５をＲＯＭ６３０から読み出して実行することで、図３２に示すように、各プログラム６３１〜６３５は、検索式解析プロセス６４１、ＳＱＬログ収集プロセス６４２、要素分析プロセス６４３、関係分析プロセス６４４およびスキーマ生成プロセス６４５として機能するようになる。
【０１１５】
また、ＨＤＤ６１０には、図３２に示すように、ＣＩ名リスト６１１、テーブル名リスト６１２、ＣＩ候補リスト６１３およびＲｅｌａｔｉｏｎｓｈｉｐ候補リスト６１４が設けられる。そして、ＣＰＵ６４０は、ＣＩ名リスト６１１、テーブル名リスト６１２、ＣＩ候補リスト６１３およびＲｅｌａｔｉｏｎｓｈｉｐ候補リスト６１４に対してデータを登録する。また、ＣＰＵ６４０は、とともに、ＰＵ６４０は、ＣＩ名リスト６１１、テーブル名リスト６１２、ＣＩ候補リスト６１３およびＲｅｌａｔｉｏｎｓｈｉｐ候補リスト６１４からデータを読み出してＲＡＭ６２０に格納し、ＲＡＭ６２０に格納されたデータに基づいて処理を実行する。
【符号の説明】
【０１１６】
１、１０ スキーマ生成装置
２ 要素比較作成部
３ 関係比較作成部
４ スキーマ生成部
１１ 管理ＤＢ
１１ａ ＣＩ名リスト
１１ｂ テーブル名リスト
１１ｃ ＣＩ候補リスト
１１ｄ Ｒｅｌａｔｉｏｎｓｈｉｐ候補リスト
１２ 検索式解析部
１３ ＳＱＬログ収集部
１４ 要素分析部
１５ 関係分析部
１６ スキーマ生成部
２０ ＲＤＢ
【特許請求の範囲】
【請求項１】
管理対象である構成要素を示す構成要素情報を検索するための検索式に含まれる構成要素情報と、リレーショナルデータベースへの問い合わせ履歴情報に含まれるテーブル情報とを比較し、前記構成要素情報と前記テーブル情報との対応関係を示す対応関係情報を作成する要素比較作成部と、
前記検索式に含まれる構成要素間の関係を示す関係情報と、前記問い合わせ履歴情報に含まれるとテーブル間の関係を示す情報とを比較し、前記関係情報と前記問い合わせ履歴情報との対応関係を示す対応関係情報を作成する関係比較作成部と、
前記要素比較作成部によって作成された対応関係情報と、前記関係比較作成部によって作成された対応関係情報とを用いて、前記構成要素情報のスキーマ定義および前記関係情報のスキーマ定義を生成するスキーマ定義生成部と、
を有することを特徴とするスキーマ定義生成装置。
【請求項２】
前記要素比較作成部は、前記検索式に含まれる構成要素情報の名称と前記問い合わせ履歴情報に含まれるテーブル情報の名称とを比較し、当該構成要素情報の名称とテーブルの名称とが一致する組を前記対応関係情報として作成することを特徴とする請求項１に記載のスキーマ定義生成装置。
【請求項３】
前記要素比較作成部によって比較されたテーブル情報のうち、いずれの構成要素情報とも対応関係がなかった未割当のテーブル情報が存在する場合に、該テーブル情報に関連する問い合わせ履歴情報を分析し、従属関係にある構成要素情報を推定する従属要素推定部をさらに有することを特徴とする請求項１または２に記載のスキーマ定義生成装置。
【請求項４】
前記構成要素情報作成部によって作成された対応関係情報と、前記接続関係情報作成部によって作成された対応関係情報とを用いて、前記検索式を辿れるかを検証する検証部をさらに有することを特徴とする請求項１〜３のいずれか一つに記載のスキーマ定義生成装置。
【請求項５】
管理対象である構成要素を示す構成要素情報を検索するための検索式に含まれる構成要素情報と、リレーショナルデータベースへの問い合わせ履歴情報に含まれるテーブル情報とを比較し、前記構成要素情報と前記テーブル情報との対応関係を示す対応関係情報を作成する要素比較作成ステップと、
前記検索式に含まれる構成要素間の関係を示す関係情報と、前記問い合わせ履歴情報に含まれるとテーブル間の関係を示す情報とを比較し、前記関係情報と前記問い合わせ履歴情報との対応関係を示す対応関係情報を作成する関係比較作成ステップと、
前記要素比較作成ステップによって作成された対応関係情報と、前記関係比較作成ステップによって作成された対応関係情報とを用いて、前記構成要素情報のスキーマ定義および前記関係情報のスキーマ定義を生成するスキーマ定義生成ステップと、
を含んだことを特徴とするスキーマ定義生成方法。
【請求項６】
管理対象である構成要素を示す構成要素情報を検索するための検索式に含まれる構成要素情報と、リレーショナルデータベースへの問い合わせ履歴情報に含まれるテーブル情報とを比較し、前記構成要素情報と前記テーブル情報との対応関係を示す対応関係情報を作成する要素比較作成手順と、
前記検索式に含まれる構成要素間の関係を示す関係情報と、前記問い合わせ履歴情報に含まれるとテーブル間の関係を示す情報とを比較し、前記関係情報と前記問い合わせ履歴情報との対応関係を示す対応関係情報を作成する関係比較作成手順と、
前記要素比較作成手順によって作成された対応関係情報と、前記関係比較作成手順によって作成された対応関係情報とを用いて、前記構成要素情報のスキーマ定義および前記関係情報のスキーマ定義を生成するスキーマ定義生成手順と、
をコンピュータに実行させることを特徴とするスキーマ定義生成プログラム。
【請求項１】
管理対象である構成要素を示す構成要素情報を検索するための検索式に含まれる構成要素情報と、リレーショナルデータベースへの問い合わせ履歴情報に含まれるテーブル情報とを比較し、前記構成要素情報と前記テーブル情報との対応関係を示す対応関係情報を作成する要素比較作成部と、
前記検索式に含まれる構成要素間の関係を示す関係情報と、前記問い合わせ履歴情報に含まれるとテーブル間の関係を示す情報とを比較し、前記関係情報と前記問い合わせ履歴情報との対応関係を示す対応関係情報を作成する関係比較作成部と、
前記要素比較作成部によって作成された対応関係情報と、前記関係比較作成部によって作成された対応関係情報とを用いて、前記構成要素情報のスキーマ定義および前記関係情報のスキーマ定義を生成するスキーマ定義生成部と、
を有することを特徴とするスキーマ定義生成装置。
【請求項２】
前記要素比較作成部は、前記検索式に含まれる構成要素情報の名称と前記問い合わせ履歴情報に含まれるテーブル情報の名称とを比較し、当該構成要素情報の名称とテーブルの名称とが一致する組を前記対応関係情報として作成することを特徴とする請求項１に記載のスキーマ定義生成装置。
【請求項３】
前記要素比較作成部によって比較されたテーブル情報のうち、いずれの構成要素情報とも対応関係がなかった未割当のテーブル情報が存在する場合に、該テーブル情報に関連する問い合わせ履歴情報を分析し、従属関係にある構成要素情報を推定する従属要素推定部をさらに有することを特徴とする請求項１または２に記載のスキーマ定義生成装置。
【請求項４】
前記構成要素情報作成部によって作成された対応関係情報と、前記接続関係情報作成部によって作成された対応関係情報とを用いて、前記検索式を辿れるかを検証する検証部をさらに有することを特徴とする請求項１〜３のいずれか一つに記載のスキーマ定義生成装置。
【請求項５】
管理対象である構成要素を示す構成要素情報を検索するための検索式に含まれる構成要素情報と、リレーショナルデータベースへの問い合わせ履歴情報に含まれるテーブル情報とを比較し、前記構成要素情報と前記テーブル情報との対応関係を示す対応関係情報を作成する要素比較作成ステップと、
前記検索式に含まれる構成要素間の関係を示す関係情報と、前記問い合わせ履歴情報に含まれるとテーブル間の関係を示す情報とを比較し、前記関係情報と前記問い合わせ履歴情報との対応関係を示す対応関係情報を作成する関係比較作成ステップと、
前記要素比較作成ステップによって作成された対応関係情報と、前記関係比較作成ステップによって作成された対応関係情報とを用いて、前記構成要素情報のスキーマ定義および前記関係情報のスキーマ定義を生成するスキーマ定義生成ステップと、
を含んだことを特徴とするスキーマ定義生成方法。
【請求項６】
管理対象である構成要素を示す構成要素情報を検索するための検索式に含まれる構成要素情報と、リレーショナルデータベースへの問い合わせ履歴情報に含まれるテーブル情報とを比較し、前記構成要素情報と前記テーブル情報との対応関係を示す対応関係情報を作成する要素比較作成手順と、
前記検索式に含まれる構成要素間の関係を示す関係情報と、前記問い合わせ履歴情報に含まれるとテーブル間の関係を示す情報とを比較し、前記関係情報と前記問い合わせ履歴情報との対応関係を示す対応関係情報を作成する関係比較作成手順と、
前記要素比較作成手順によって作成された対応関係情報と、前記関係比較作成手順によって作成された対応関係情報とを用いて、前記構成要素情報のスキーマ定義および前記関係情報のスキーマ定義を生成するスキーマ定義生成手順と、
をコンピュータに実行させることを特徴とするスキーマ定義生成プログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図３１】
【図３２】
【図３３】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図３１】
【図３２】
【図３３】
【公開番号】特開２０１１−２５７８１２（Ｐ２０１１−２５７８１２Ａ）
【公開日】平成２３年１２月２２日（２０１１．１２．２２）
【国際特許分類】
【出願番号】特願２０１０−１２９４４１（Ｐ２０１０−１２９４４１）
【出願日】平成２２年６月４日（２０１０．６．４）
【出願人】（０００００５２２３）富士通株式会社 (25,993)
【Ｆターム（参考）】
【公開日】平成２３年１２月２２日（２０１１．１２．２２）
【国際特許分類】
【出願日】平成２２年６月４日（２０１０．６．４）
【出願人】（０００００５２２３）富士通株式会社 (25,993)
【Ｆターム（参考）】
[ Back to top ]