JP6268435B2 - データベースの再構成方法、データベースの再構成プログラム、及び、データベースの再構成装置 - Google Patents

Description

本発明は、データベースの再構成方法、データベースの再構成プログラム、及び、データベースの再構成装置に関する。

大規模基幹系システム(例えば、顧客管理システム)のような業務システムでは、ビジネスの変化に追従するために、保守や改修が繰り返し行われる。保守や改修が繰り返し行われることによって、業務システムは肥大化、複雑化し、再構築が必要となることがある。

業務システムは、エンティティとイベントによって構成される。エンティティは、例えば顧客や商品といった名詞的な要素を示し、作成、更新、参照、削除処理の対象となる。また、エンティティは、業務システムが扱うデータとしてデータベース（ＤＢ；database）に格納される。さらに、エンティティは、例えば、「顧客」のようなエンティティ名と、(顧客の)「氏名」や、(商品の)「単価」のような情報を、属性として有する。属性は、例えば、「氏名」のような属性名と、「富士 通子」のような属性値を有す。

ＤＢが有するエンティティ及び属性は、スキーマと呼ばれる定義情報によって規定される。スキーマは、エンティティと属性の関係、エンティティ名、および、属性名を含むが、属性値は含まない。一方、イベントは、例えば、登録や発注といった動詞的な要素を示し、エンティティの状態を遷移させる振る舞いを示す。

業務システムの再構築の大きな作業の１つは、保守や改修によって準直交化の状態が崩れたエンティティ群(データ体系)を準直交化しＤＢを再構成することである（例えば、特許文献１）。準直交化とは、例えば、互いに同一の属性名を持たず、かつ、独立した概念を有するエンティティの組み合わせを選択することを意味する。なお、エンティティが有する１つまたは複数の属性名が具体的な属性値を有する場合、エンティティのインスタンスと呼ぶ。

これに対し、異なるエンティティが同一の属性名を持つ場合、複数のエンティティそれぞれの具体例を示す複数のインスタンス間で、同一の意味を有するデータが複数、存在することになる。エンティティに対応するインスタンス間で同一の意味を有する複数のデータが存在する場合、特定の属性名を持つデータが複数のインスタンスに存在し、システム全体におけるデータの唯一性が損なわれた状態である。このようなシステムでは、データの更新を行う際、更新対象のデータに対応する属性名それぞれに対して更新を行う必要があることから、更新処理を行うプログラムの肥大化、複雑化を招く。また、エンティティが持つ属性名が、独立した概念ではなく複数の概念を持つ場合も、データ更新処理が煩雑化し、データの更新を行うプログラムの肥大化、複雑化を招く。

特開２００６−１６４２４６号公報

しかしながら、エンティティ群の準直交化は手作業で行われる必要があるため、膨大なエンティティ群を有する大規模基幹系システムの準直交化には、膨大な工数を要する。また、準直交化には実データ（属性値）の利用が有用であるものの、個人情報保護やセキュリティの観点から実データを使用できないことが多い。また、準直交化は、エンティティと属性名との関係に基づくため、クラスター分析等による属性名間の関連だけでは適切に行うことが難しい。

１つの側面は、本発明は、データベースを効率的に再構成するデータベースの再構成方法、データベースの再構成プログラム、及び、データベースの再構成装置を提供することを目的とする。

第１の側面は、それぞれが、複数の属性名と対応関係を有するエンティティを有する複数のデータベースの再構成方法であって、複数のデータベースのいずれかに含まれる前記属性名、及び、前記属性名と前記エンティティとの関連度に関する第１の情報に基づいて、複数のエンティティ候補を抽出し、前記抽出した複数のエンティティ候補によって構成されるエンティティ候補の組であって、前記エンティティ候補の組を構成する前記エンティティ候補がいずれかの前記属性名と対応関係を有することによってすべての前記属性名と対応関係を有し、前記構成するエンティティ候補の数が最少となるエンティティ候補の組を複数、特定し、前記特定された複数のエンティティ候補の組のうち、前記エンティティ間の関連度に関する第２の情報に基づいて、前記エンティティ候補の組に含まれるエンティティ候補間の関連度の総和が最大となるエンティティ候補の組を特定し、前記複数の属性名それぞれを、前記第１の情報に基づいて、前記エンティティ候補の組を構成する前記エンティティ候補のいずれかと対応関係を有するように割り当てることを特徴とする。

第１の側面によれば、各属性名についてエンティティ候補を抽出し、全ての属性名と対応関係を有し関連度が最大となるエンティティ候補の組を特定し、属性名それぞれを、エンティティ候補のいずれかと対応関係を有するように割り当てることで、データベースを効率的に再構成可能になる。

業務とシステムとの関係の一例を示す図である。 ＡｓＩｓスキーマの一例とスキーマの準直交化状態とを示す図である。 図２のＡｓＩｓスキーマに対応するＴｏＢｅスキーマの一例と、スキーマの準直交化状態とを示す図である。 ＡｓＩｓスキーマの別の一例とスキーマの準直交化状態とを示す図である。 図４のＡｓＩｓスキーマに対応するＴｏＢｅスキーマの一例と、スキーマの準直交化状態とを示す図である。 データ体系の準直交化処理を説明する図である。 本実施の形態例におけるＤＢ再構成装置の構成の一例を説明する図である。 図７で示したＤＢ再構成装置のブロック図である。 本実施の形態例におけるＤＢ再構成装置の処理を説明するフローチャート図である。 図９の工程Ｓ１１によって生成されるエンティティ-属性名関係表の一例を示す図である。 図９の工程Ｓ１２によって生成される属性名の一覧の一例を示す図である。 図１１に示す属性名の一覧を関連図に基づいて説明する図である。 本実施の形態例における属性名-エンティティ候補関連度表の一例を示す図である。 図９の工程Ｓ１３によって更新されるエンティティ-属性名関係表の一例を示す図である。 図９の工程Ｓ１４によって抽出される２つのエンティティ候補群の例をそれぞれ示すエンティティ-属性名関係表を示す図である。 図１５に示すエンティティ候補群を関連図に基づいて説明する図である。 本実施の形態例におけるエンティティ候補間関連度表の一例を示す図である。 属性名とエンティティ候補との対応関係の選択処理（図９のＳ１６）を説明する図である。 属性名とエンティティ候補との対応関係の選択処理を関連図に基づいて説明する図である。 図９の工程Ｓ１７によって出力されたＴｏＢｅスキーマのデータ体系を説明する図である。 ユーザによってエンティティ間の参照関係が補われたＴｏＢｅスキーマのデータ体系の例を示す図である。 エンティティ間の参照関係が補われたＴｏＢｅスキーマのデータ体系を、関連図に基づいて説明する図である。 エンティティ間で属性が循環するＡｓＩｓスキーマのデータ体系のエンティティ-属性関係表の一例を示す図である。

以下、図面にしたがって本発明の実施の形態を説明する。ただし、本発明の技術的範囲はこれらの実施の形態に限定されず、特許請求の範囲に記載された事項とその均等物まで及ぶものである。

図１は、業務とシステムとの関係の一例を示す図である。図１の（Ａ）と図１の（Ｂ）は同一の教材販売システムを示し、図１の（Ａ）は教材販売システムの業務を、図１の（Ｂ）は教材販売システムのアーキテクチャを示す。教材販売システムとは、例えば、学区に所属する顧客に対する教材の販売状況を管理するシステムである。

図１の（Ａ）に示す教材販売業務は、エンティティとして「顧客」Ｅｍ１、「注文」Ｅｍ２、「商品」Ｅｍ３、「学校」Ｅｍ４を有し、イベントとして、「顧客登録」Ｅｖ１、「住所変更」Ｅｖ２、「氏名変更」Ｅｖ３、「注文追加」Ｅｖ４、「商品変更」Ｅｖ５を有する。エンティティは、作成処理、更新処理、参照処理、削除処理の対象となる名詞的な要素である。なお、図１には図示していないが、エンティティ各々は、複数の属性名を有する。例えば、エンティティ「顧客」Ｅｍ１は、属性名「氏名」「住所」等を有する。一方、イベントは、エンティティの状態を遷移させる振る舞いを示す動詞的な要素である。例えば、イベント「顧客登録」Ｅｖ１に対応したイベントが発生すると、エンティティ「顧客」Ｅｍ１に対応したインスタンスに新しいデータが作成される。同様にして、例えば、イベント「商品変更」Ｅｖ５が発生すると、エンティティ「商品」Ｅｍ３のデータが更新される。

図１の（Ｂ）に示す教材販売システムのアーキテクチャは、Ｖｉｅｗ層とＭｏｄｅｌ層とＣｏｎｔｒｏｌ層とを有する。Ｍｏｄｅｌ層は、教材販売システムが扱うデータを示す要素である。データは、図１の（Ａ）のエンティティに相当し、例えば、データベース（ＤＢ；database）ｄ１〜ｄ４に記憶される。図１の（Ｂ）の例では、例えば、データはエンティティ毎に、各ＤＢｄ１〜ｄ４に記憶される。データはＤＢｄ１〜ｄ４から読み出されメモリ上で更新され、再び、ＤＢｄ１〜ｄ４に記憶される。Ｖｉｅｗ層は、ｍｏｄｅｌ層のデータを取り出し、閲覧に適した形で表示する要素である。つまり、Ｖｉｅｗ層は、画面等のユーザインタフェースへの出力を行う。Ｃｏｎｔｒｏｌ層は、イベントに応答し、イベントに応じた処理を行う要素である。つまり、Ｃｏｎｔｒｏｌ層は、ユーザインタフェースからの入力に応答して処理を行う。

図１の（Ｂ）の教材販売システムにおける処理の流れを説明する。まず、例えば、ユーザがボタン等を押下することによって、画面等のユーザインタフェースを通してＶｉｅｗ層に指示を入力すると、Ｃｏｎｔｒｏｌ層は、Ｖｉｅｗ層からのイベント（例えば、イベント「顧客登録」Ｅｖ１）を処理する。その結果、ｍｏｄｅｌ層のエンティティ「顧客」Ｅｍ１に関連するデータが更新される。そして、Ｖｉｅｗ層は、更新されたエンティティ「顧客」Ｅｍ１に関連するデータをＭｏｄｅｌ層から取得し、画面等の表示内容を更新する。

なお、ＤＢが有するエンティティ及び属性名は、スキーマと呼ばれる定義情報によって規定される。現状の業務システムを示すスキーマをＡｓＩｓスキーマ、あるべき状態の業務システムを示すスキーマをＴｏＢｅスキーマと称する。本実施の形態例におけるＤＢ再構成装置は、ＡｓＩｓスキーマを入力として、準直交化処理によってＤＢの再構成を行い、ＴｏＢｅスキーマを生成する。

［スキーマの例］
図２は、ＡｓＩｓスキーマＳａ１の一例とスキーマの準直交化状態とを示す図である。図１において前述したとおり、本実施の形態例におけるＡｓＩｓスキーマＳａ１は、現状の業務システムを示す、準直交化処理の対象のスキーマである。なお、図２のＡｓＩｓスキーマＳａ１における括弧で囲まれた属性名は、他のエンティティを参照する識別番号である。具体的に、図２のＡｓＩｓスキーマＳａ１の属性名「（商品番号）」は、エンティティ「商品」のデータを参照可能にする識別情報である。

図２のＡｓＩｓスキーマＳａ１のデータ体系は、例えば、注文、商品、顧客という３つの概念を有する。ただし、図２のＡｓＩｓスキーマＳａ１のデータ体系において、顧客に関する属性名「氏名」「住所」「電話番号」は、エンティティ「注文」とエンティティ「店舗顧客情報」との間で重複する。属性名が複数のエンティティの間で重複する場合、運用や保守に工数を要する。

図２の関係図Ｐａ１は、ＡｓＩｓスキーマＳａ１のエンティティと属性名との関連を示す図である。関係図Ｐａ１における実線は、エンティティＥｍと、当該エンティティＥｍに属する属性名Ｅｓとの対応関係を表す。また、点線は、エンティティＥｍと、他のエンティティを参照可能にする括弧付きの属性名との対応関係を表す。また、関連図Ｐａ１における円Ｅｍａ、Ｅｍｂ、Ｅｍｃは、それぞれ、エンティティＥｍと、当該エンティティＥｍに属する属性名Ｅｓとを包含する。例えば、関連図Ｐａ１の円Ｅｍａは、エンティティ「注文」Ｅｍとその属性名「注文年月日」「氏名」「年齢」「住所」「学区」「電話番号」「ＦＡＸ」Ｅｓとを包含する。他の円Ｅｍｂ、Ｅｍｃも同様である。

準直交化されたスキーマのエンティティは、独立した概念を有することから、互いに同一の属性名を有しない。言い換えると、準直交化されていないスキーマは、複数のエンティティと対応関係を有する属性名を有する。関係図Ｐａ１によると、属性名「住所」「氏名」「電話番号」Ｅｓは、複数のエンティティ「注文」「店舗顧客情報」の円Ｅｍｂ、Ｅｍｃに属する。したがって、関連図Ｐａ１によると、ＡｓＩｓスキーマＳａ１が準直交化されていないことを示す。

ここで、運用や保守に工数を要する例として、運用時に、例えば、顧客の住所を変更する例を挙げる。顧客の住所を変更する場合、教材販売システムは、エンティティ「注文」の属性名「住所」と、エンティティ「店舗顧客情報」の属性名「住所」の両方の値を更新する。ただし、エンティティ「注文」の属性名「住所」と、エンティティ「店舗顧客情報」の属性名「住所」は、それぞれ別に実データを有する。したがって、エンティティ「注文」の属性名「住所」の実データと、エンティティ「店舗顧客情報」の属性名「住所」の実データとは異なっていることがある。

具体的に、例えば、同じ住所を示していても、エンティティ「注文」の属性名「住所」には漢数字表記の番地が、エンティティ「店舗顧客情報」の属性名「住所」には数字表記の番地が記憶される場合がある。また、対象とする顧客の住所が途中で変更された場合、例えば、エンティティ「注文」の属性名「住所」には変更後の住所が、エンティティ「店舗顧客情報」の属性名「住所」には変更前の住所が記憶されている場合がある。

教材販売システムは、属性名「住所」がエンティティ「注文」及びエンティティ「店舗顧客情報」に属する場合、各属性名「住所」が同一の住所を指すことを判定した後、住所データの更新処理を行う。したがって、教材販売システムに同一の住所であるか否かを判定する処理が増加し、工数が発生する。また、住所を更新する対象の顧客が複数の注文を実施する場合、エンティティ「注文」のデータの属性名「住所」に加えて、複数のエンティティ「店舗顧客情報」のデータそれぞれの属性名「住所」が更新の対象となるため、更新ミスが生じ易い。

図３は、図２のＡｓＩｓスキーマに対応するＴｏＢｅスキーマＳｔ１の一例と、スキーマの準直交化状態とを示す図である。図３のＴｏＢｅスキーマＳｔ１は、図２のＡｓＩｓスキーマＳａ１を準直交化することによって生成されるスキーマである。また、前述したとおり、図３のＴｏＢｅスキーマＳｔ１における括弧で囲まれた属性名は、他のエンティティを参照する識別番号である。前述したとおり、図３のＴｏＢｅスキーマＳｔの属性名「（商品番号）」は、エンティティ「商品」のデータを参照可能にする識別情報である。

具体的に、図３のＴｏＢｅスキーマＳｔ１のデータ体系において、顧客に関する属性名「氏名」「住所」「電話番号」は、エンティティ「顧客」にだけ属する。即ち、エンティティが互いに同一の属性名を有していない。

図３の関係図Ｐｔ１は、ＴｏＢｅスキーマＳｔ１のエンティティと属性名との関連を示す図である。図２と同様にして、関係図Ｐｔ１における実線は、エンティティＥｍと、当該エンティティＥｍに属する属性名Ｅｓとの対応関係を表す。また、点線は、エンティティＥｍと、他のエンティティを参照可能にする括弧付きの属性名との対応関係を表す。また、関連図Ｐｔ１における円Ｅｍｄ〜Ｅｍｇは、それぞれ、エンティティＥｍと、当該エンティティＥｍに属する属性名Ｅｓとを包含する。

図３のＴｏＢｅスキーマＳｔ１は準直交化されていることから、属性名は１つのエンティティにのみ所属する。例えば、図２のＡｓＩｓスキーマＳａ１において複数のエンティティ「注文」「店舗顧客情報」に所属する属性名「住所」「氏名」「電話番号」Ｅｓは、関係図Ｐｔ１において、１つのエンティティ「顧客」の円Ｅｍｆにのみ属する。また、図３の関係図Ｐｔ１は、図２の関係図Ｐａ１に対して、エンティティの数が増加していると共に、１つのエンティティＥｍに対する属性名Ｅｓの数が少ない。これは、図３のＴｏＢｅスキーマＳｔ１の各エンティティが独立した概念を有することを示す。

準直交化されたスキーマに基づいて顧客の住所を変更する場合、教材販売システムは、エンティティ「顧客」の属性名「住所」の実データのみを更新すればよく、更新ミスが生じ難い。図３のＴｏＢｅスキーマＳｔ１のデータ体系によると、属性名が複数のエンティティ間で重複しないため、運用や保守が容易である。

図４は、ＡｓＩｓスキーマＳａの別の一例とスキーマの準直交化状態とを示す図である。図４のスキーマは、運用の途中で、複数の注文を一括して請求可能にする要件が追加されたスキーマである。図２、図３と同様にして、図４のＡｓＩｓスキーマＳａ２における括弧で囲まれた属性名は、他のエンティティを参照する識別番号である。図４のＡｓＩｓスキーマＳａ２は、図２のＡｓＩｓスキーマＳａ１に対して、エンティティ「注文」に、さらに、属性名「請求先番号」「親請求先番号」を有する。エンティティ「注文」に属性名「請求先番号」「親請求先番号」を追加することにより、複数の注文を一括して請求可能になる。

例えば、複数の注文において、１つの注文が親の注文であって、それ以外の注文が子の注文である場合を例示する。具体的に、教材販売システムは、子の注文の属性名「親請求先番号」に、親の注文の属性名「請求先番号」のデータを付与する。そして、教材販売システムは、属性名「親請求先番号」にデータを有する注文を、子の注文であると認識することによって、親の注文と子の注文の請求先を、親の注文の請求先に統一することができる。

ただし、エンティティ「注文」が属性名「請求先番号」「親請求先番号」を有する場合、注文の親子関係が循環してしまう場合がある。注文の親子関係が循環する場合とは、例えば、親の注文の属性名「親請求先番号」が、子の注文の属性名「請求先番号」のデータを有する場合である。この場合、親の注文と子の注文とが循環し、親の注文が特定できない。そこで、教材販売システムは、データの更新時に、注文の親子関係が循環していないかを確認する必要がある。注文の親子関係が循環しているか否かの確認処理の追加は、既存の教材販売システムの複雑化を招き、教材販売システムに大きな影響が生じる。つまり、教材販売システムの開発、保守の効率及び品質の低下が生じる。

図４の関係図Ｐａ２は、ＡｓＩｓスキーマＳａ１のエンティティと属性名との関連を示す。図４の関連図Ｐａ２における実線及び点線は、図２、図３と同様である。また、関連図Ｐａ１における円Ｅｍｈ〜Ｅｍｊは、それぞれ、エンティティＥｍと、当該エンティティＥｍに属する属性名Ｅｓとを包含する。図４のＡｓＩｓスキーマＳａ２は準直交化されていないことから、関係図Ｐａ２によると、属性名「住所」「氏名」「電話番号」Ｅｓは、複数のエンティティ「注文」「店舗顧客情報」の円Ｅｍｈ、Ｅｍｊに属する。

図５は、図４のＡｓＩｓスキーマに対応するＴｏＢｅスキーマＳｔ２の一例と、スキーマの準直交化状態とを示す図である。図５のＴｏＢｅスキーマＳｔ２のデータ体系は、図４のＡｓＩｓスキーマＳａ２を準直交化することによって生成されるスキーマである。また、前述したとおり、図５のＴｏＢｅスキーマＳｔ２における括弧で囲まれた属性名は、他のエンティティを参照する識別番号である。

図５のＴｏＢｅスキーマＳｔ２のデータ体系は、図４のＡｓＩｓスキーマＳａ２に対して、エンティティ「請求先」を有する。また、図５のＴｏＢｅスキーマＳｔ２のデータ体系におけるエンティティ「注文」は、エンティティ「請求先」のデータを参照可能にする属性名「請求先番号」を有する。教材販売システムは、請求先を統一したい複数の注文の属性名「請求先番号」に、請求先とするエンティティ「請求先」の属性名「請求先番号」のデータを付与することによって、複数の注文の一括請求を可能にする。

図５の関係図Ｐｔ２は、ＴｏＢｅスキーマＳｔ２のエンティティと属性名との関連を示す図である。図５の関連図Ｐｔ２における実線及び点線は、図２〜図４と同様である。また、関連図Ｐｔ２における円Ｅｍｋ〜Ｅｍｏは、それぞれ、エンティティＥｍと、当該エンティティＥｍに属する属性名Ｅｓとを包含する。図５のＴｏＢｅスキーマＳｔ２は準直交化されていることから、属性名は１つのエンティティにのみ所属する。例えば、図４のＡｓＩｓスキーマＳａ２において複数のエンティティ「注文」「店舗顧客情報」に所属する属性名「住所」「氏名」「電話番号」Ｅｓは、図５の関係図Ｐｔ２において、１つのエンティティ「顧客」「請求先」の円Ｅｍｍ、Ｅｍｏにそれぞれ属する。

また、図５の関係図Ｐｔ２は、図４の関係図Ｐａ２に対して、エンティティの数が増加していると共に、１つのエンティティＥｍに対する属性名Ｅｓの数が少ない。これは、図５のＴｏＢｅスキーマＳｔ２の各エンティティが独立した概念を有することを示す。

したがって、図５のＴｏＢｅスキーマＳｔ２のデータ体系を有する場合、教材販売システムは、注文の親子関係が循環しているか否かを確認する必要がなく、既存の教材販売システムに対する影響が小さい。また、運用時、教材販売システムは、請求先を同一とする複数の注文の属性名「請求先番号」に同一のデータを付与するだけでよい。したがって、ＴｏＢｅスキーマＳｔ２のデータ体系によると、要件の追加による教材販売システムの運用、保守の複雑化が回避される。

［データ体系の準直交化］
図６は、データ体系の準直交化処理を説明する図である。図６の（Ａ）（Ｂ）において、黒丸は属性名Ｅｓに対応し、白四角はエンティティＥｍに対応する。図６の（Ａ）は、属性名Ｅｓ間の関連を表す図であって、図６の（Ｂ）は、属性名ＥｓとエンティティＥｍとの関連を表す図である。図６の（Ｂ）における線及び点線は、図２〜図５と同様である。

データ体系の準直交化とは、例えば、互いに同一の属性名Ｅｓを有しないエンティティＥｍの組み合わせであって、かつ、独立した概念を有するエンティティＥｍの組み合わせを選択することを示す。独立した概念を有するエンティティＥｍの組み合わせとは、例えば、類似度の小さいエンティティＥｍの組み合わせである。各属性名Ｅｓは、実データに対応するため、属性名Ｅｓを削除することは想定し難い。したがって、本実施の形態例におけるデータ体系の準直交化は、例えば、既存の複数の属性名Ｅｓを、新規または既存のいずれかのエンティティＥｍに対応させる処理を示す。

図６の（Ａ）に示すような複数の要素（属性名）Ｅｓをグルーピングする技術として、クラスタリング技術がある。しかしながら、クラスタリング技術は、要素（属性名）Ｅｓ間の距離に基づいて、距離が近い要素（属性名）Ｅｓ同士をグルーピングする技術である。これに対し、データ体系の準直交化は、図６の（Ｂ）に示すように、属性名ＥｓとエンティティＥｍとの間の関連度(距離)に基づいて、属性名ＥｓとエンティティＥｍの対応関係を生成する。また、現状のＡｓＩｓスキーマのデータ体系は、不要なエンティティＥｍを有すると共に、不足しているエンティティＥｍを有する。したがって、属性名ＥｓとエンティティＥｍとの間の関連度（距離）の判定は容易ではなく、データ体系の準直交化処理にはクラスタリング技術が適用できない。

本実施の形態例におけるＤＢ再構成装置１０は、複数のＤＢのいずれかに含まれる属性名、及び、属性名とエンティティとの関連度に関する第１の情報に基づいて、複数のエンティティ候補を抽出する。そして、ＤＢ再構成装置１０は、抽出した複数のエンティティ候補によって構成されるエンティティ候補の組であって、エンティティ候補の組を構成するエンティティ候補がいずれかの属性名と対応関係を有することによってすべての属性名と対応関係を有し、構成するエンティティ候補の数が最少となるエンティティ候補の組を複数、特定する。次に、ＤＢ再構成装置１０は、特定された複数のエンティティ候補の組のうち、エンティティ間の関連度に関する第２の情報に基づいて、エンティティ候補の組に含まれるエンティティ候補間の関連度の総和が最大となるエンティティ候補の組を特定する。そして、ＤＢ再構成装置１０は、複数の属性名それぞれを、第１の情報に基づいて、エンティティ候補の組を構成するエンティティ候補のいずれかと対応関係を有するように割り当てる。

つまり、ＤＢ再構成装置１０は、属性名に基づいてエンティティ候補群を抽出し、属性名とエンティティ候補との対応関係を選択する。これにより、エンティティに過不足がある場合であっても、実データを要することなく、属性名に基づいてデータ体系を準直交化し、ＤＢを再構成することができる。なお、本実施の形態例において、ＤＢは、例えば、１つのエンティティと複数の属性名とを有する。ただし、この例に限定されるものではなく、ＤＢは、複数のエンティティを有していてもよい。

［ＤＢ再構成装置の構成］
図７は、本実施の形態例におけるＤＢ再構成装置１０の構成の一例を説明する図である。図７のＤＢ再構成装置１０は、例えば、入力装置１１、表示装置１２、通信インタフェース１３、プロセッサ１４、記憶媒体１５、メモリ１６を有する。各部は、バス１７を介して互いに接続される。入力装置１１は、例えば、キーボードやマウス等を示し、表示装置１２は、例えば、ディスプレイ等の表示画面を示す。

また、記憶媒体１５は、ＤＢ再構成プログラムＰＲを記憶する。プロセッサ１４は、実行時にＤＢ再構成プログラムＰＲをメモリ１６にロードし、ＤＢ再構成プログラムＰＲと協働して、記憶媒体１５から読み出したＡｓＩｓスキーマＳａを入力としてデータ体系の準直交化処理を行う。そして、ＤＢ再構成プログラムＰＲは、メモリ１６上にＴｏＢｅスキーマＳｔを生成し、記憶媒体１５に出力する。また、記憶媒体１５は、ＤＢ再構成プログラムＰＲによって参照される属性名-エンティティ候補関連度表Ｈ１と、エンティティ候補間関連度表Ｈ２とを有する。

［ＤＢ再構成装置のブロック図］
図８は、図７で示したＤＢ再構成装置１０のブロック図である。図８のＤＢ再構成装置１０のＤＢ再構成プログラムＰＲは、例えば、エンティティ-属性名関係表生成部２１、属性名抽出部２２、エンティティ候補抽出部２３、エンティティ候補群抽出部２４、エンティティ候補群選択部２５、対応関係選択部２６、ＴｏＢｅスキーマ出力部２７を有する。

エンティティ-属性名関係表生成部２１は、ＡｓＩｓスキーマＳａに基づいて、エンティティ-属性名関係表を生成する。属性名抽出部２２は、エンティティ-属性名関係表に基づいて、複数のＤＢが有する複数の属性名の一覧を抽出する。エンティティ候補抽出部２３は、属性名-エンティティ候補関連度表Ｈ１を参照して、抽出した属性名の一覧に基づいて、属性名各々に対応する１つまたは複数のエンティティの候補との対応関係を抽出する。エンティティ候補群抽出部２４は、抽出したエンティティ候補から、対応関係を有する属性名の集合が、エンティティ-属性名関係表の属性名の一覧と一致する最少数のエンティティ候補の組み合わせを抽出する。

また、エンティティ候補群選択部２５は、エンティティ候補間関連度表Ｈ２を参照して、複数のエンティティ候補の組み合わせから、１つのエンティティ候補の組み合わせを選択する。対応関係選択部２６は、１つの属性名に対応するエンティティ候補が複数ある場合、即ち、属性名とエンティティ候補との対応関係が重複する場合、属性名-エンティティ候補関連度表Ｈ１を参照して、１つの対応関係を選択する。ＴｏＢｅスキーマ出力部２７は、エンティティ候補と属性名とを、その対応関係と共に、ＴｏＢｅスキーマＳｔに出力する。

［フローチャート］
図９は、本実施の形態例におけるＤＢ再構成装置１０の処理を説明するフローチャート図である。各工程の処理の詳細については、具体例に対応して後述する。エンティティ-属性名関係表生成部２１は、ＡｓＩｓスキーマからエンティティ及び属性名を抽出し、エンティティ-属性名関係表を生成する（Ｓ１１）。次に、属性名抽出部２２は、工程Ｓ１１で生成したエンティティ-属性名関係表からエンティティをすべて消去する（Ｓ１２）。属性名は、実データを有するのに対し、エンティティは、不足しているエンティティや不要なエンティティを含む。したがって、属性名抽出部２２は、属性名を残存させると共に、エンティティを消去する。即ち、属性名抽出部２２は、属性名を残存させると共に、エンティティを消去することによって、重複のない属性名の一覧を取得する。

次に、エンティティ候補抽出部２３は、属性名とエンティティ候補の間の関連度を用いて、属性名の一覧に基づいて、属性名に対応するエンティティ候補を推察し追加する（Ｓ１３）。つまり、エンティティ候補抽出部２３は、現状の属性名の一覧に基づいて、エンティティ候補を網羅的に抽出する。具体的に、エンティティ候補抽出部２３は、予め用意された属性名-エンティティ候補関連度表Ｈ１を参照して、各属性名について、所定以上の関連度を有する、当該属性名に対応する１つまたは複数のエンティティ候補との対応関係を抽出する。エンティティ候補は任意の候補である。エンティティ候補抽出部２３は、工程Ｓ１３の処理によって、エンティティの不足を補う。

属性名の一覧に対応して、膨大なエンティティ候補が列挙される。したがって、次に、エンティティ候補群抽出部２４は、対応関係を有する属性名の集合が全ての属性名を含むエンティティ候補群のうち、エンティティ候補の数が最少となるエンティティ候補群を抽出する（Ｓ１４）。具体的に、エンティティ候補群抽出部２４は、対応関係を有する属性名の集合が、エンティティ-属性名関係表の属性名の一覧と一致する最少数のエンティティ候補の組み合わせを抽出する。エンティティ候補の数が少ない程、エンティティ候補間の類似度の総和が小さいため、エンティティ候補が互いに独立した概念を有することが想定される。したがって、エンティティ候補群抽出部２４は、最少数のエンティティ候補の組み合わせを抽出することにより、互いに独立した概念を有するエンティティ候補群を抽出することができる。

エンティティ候補の組み合わせは、複数パターン抽出され得る。したがって、次に、エンティティ候補群選択部２５は、工程Ｓ１４によって抽出したエンティティ候補群から、エンティティ候補とエンティティ候補との間の関連度を用いて、エンティティ候補群におけるエンティティ候補間の関連度の総和が最大になるエンティティ候補群を選択する（Ｓ１５）。即ち、エンティティ候補群選択部２５は、エンティティ候補群の冗長性を解消する。具体的に、エンティティ候補群選択部２５は、エンティティ候補間関連度表Ｈ２を参照して、複数のエンティティ候補の組み合わせから、エンティティ候補間の関連度がより高いエンティティ候補の組み合わせを選択する。エンティティ候補群の各エンティティ候補は、同一の特定の業務内で使用され、同一の特定の業務内で使用されるエンティティ候補間の関連度は高いことが想定される。したがって、エンティティ候補群選択部２５は、エンティティ候補間の関連度が最も高いエンティティ候補群を選択し、その他のエンティティ候補を除去する。

また、選択されたエンティティ候補群が有するエンティティ候補は、互いに同一の属性名と対応関係を有することがある。次に、対応関係選択部２６は、複数のエンティティ候補と重複して対応関係を有する属性名について、重複した前記対応関係を減少させる（Ｓ１６）。具体的に、対応関係選択部２６は、複数のエンティティ候補と対応関係を有する属性名各々について、属性名-エンティティ候補関連度表Ｈ１を参照し、対応するエンティティ候補との間の関連度が最大となる対応関係を選択する。同一の特定の業務内で使用される属性名とエンティティ候補との間の関連度は高いことが想定される。したがって、対応関係選択部２６は、属性名と対応関係を有するエンティティ候補との関連度が最大となる対応関係を選択し、その他の対応関係を除去する。

工程Ｓ１６の結果、それぞれのエンティティ候補は、互いに異なる属性名の組み合わせと対応関係を有し、同一の属性名を有しない。また、エンティティ候補の数が最少に収められているため、エンティティ候補が互いに独立した概念を有することを示す。したがって、ＤＢ再構成装置１０は、工程Ｓ１１〜Ｓ１６によって、互いに同一の属性名と対応関係を有しないエンティティ候補群であって、互いに独立した概念を有するエンティティ候補群を取得できる。即ち、ＤＢ再構成装置１０は、工程Ｓ１１〜Ｓ１６によって、準直交化された、エンティティ候補と属性名との対応関係を取得できる。

次に、ＴｏＢｅスキーマ出力部２７は、工程Ｓ１１〜Ｓ１６によって取得したエンティティ候補と属性名との対応関係をＴｏＢｅスキーマに出力する（Ｓ１７）。次に、ユーザは、例えば、人手でエンティティ間の参照関係等を補う（Ｓ１８）。詳細については、後述する。

続いて、図９のフローチャート図で説明した各処理を具体例に対応させて説明する。

[具体例：図９の工程Ｓ１１]
図１０は、図９の工程Ｓ１１によって生成されるエンティティ-属性名関係表Ｔ１の一例を示す図である。図１０のエンティティ-属性名関係表Ｔ１は、エンティティの列と属性名の行とを有する。また、エンティティ-属性名関係表Ｔ１における白丸は、エンティティと属性名とが対応関係を有することを示す。図９のフローチャート図で説明したとおり、初めに、エンティティ-属性名関係表生成部２１は、図２に例示したＡｓＩｓスキーマからエンティティ及び属性名を抽出し、エンティティ-属性名関係表Ｔ１を生成する（図９のＳ１１）。

図２のＡｓＩｓスキーマＳａ１は、エンティティとして、「注文」「商品」「店舗顧客情報」を有する。また、図２のＡｓＩｓスキーマＳａ１は、エンティティ「注文」の属性名として、「注文年月日」「氏名」「年齢」「住所」「学区」「電話番号」「FAX」、エンティティ「商品」の属性名として、「商品番号」「数量」「商品名」「単価」、エンティティ「店舗顧客情報」の属性名として「氏名」「住所」「電話番号」を有する。エンティティ-属性名関係表生成部２１は、図２のＡｓＩｓスキーマＳａ１におけるエンティティ及び属性名をそれぞれ、エンティティ-属性名関係表Ｔ１のエンティティ及び属性名に記載する。

また、エンティティ-属性名関係表生成部２１は、複数のエンティティの間で重複する属性名がある場合、１つの属性名のみ記載する。図２のＡｓＩｓスキーマＳａ１では、「氏名」「住所」「電話番号」が、エンティティ「注文」とエンティティ「店舗顧客情報」との間で重複する。そこで、エンティティ-属性名関係表生成部２１は、属性名「氏名」「住所」「電話番号」を１つに集約した、エンティティ-属性名関係表Ｔ１を生成する。

そして、エンティティ-属性名関係表生成部２１は、ＡｓＩｓスキーマＳａ１におけるエンティティと属性名との間の対応関係を、エンティティ-属性名関係表Ｔ１に白丸で記載する。属性名「氏名」「住所」「電話番号」は、１つに集約されている。したがって、属性名「氏名」「住所」「電話番号」は、エンティティ「注文」及びエンティティ「店舗顧客情報」とそれぞれ対応関係を有する。

[具体例：図９の工程Ｓ１２]
図９のフローチャート図で説明したとおり、続いて、属性名抽出部２２は、工程Ｓ１１で生成したエンティティ-属性名関係表Ｔ１からエンティティをすべて消去する（Ｓ１２）。具体的に、属性名抽出部２２は、図１０のエンティティ-属性名関係表Ｔ１のエンティティを消去すると共に、エンティティ-属性名関係表Ｔ１におけるエンティティと属性名との対応関係を消去することによって、重複のない属性名の一覧を取得する。

図１１は、図９の工程Ｓ１２によって生成される属性名の一覧の一例を示す図である。図１１の属性名の一覧は、図１０のエンティティ-属性名関係表Ｔ２が有する重複のない属性名群を示す。既存の教材販売システムのデータ体系を準直交化の対象とする場合、ＡｓＩｓスキーマが有する各属性名はそれぞれ、実データを有する。したがって、属性名抽出部２２は、準直交化に当たり、属性名を減少させない。一方、ＡｓＩｓスキーマが有するエンティティは、不足しているエンティティや不要なエンティティを含む。したがって、属性名抽出部２２は、属性名を残存させると共に、エンティティ-属性名関係表Ｔ２から、エンティティ、及び、属性名とエンティティとの対応関係を消去する。

図１２は、図１１に示す属性名の一覧を関連図に基づいて説明する図である。図１２に示す属性名群は、図２に示す関連図Ｐａ１からエンティティＥｍを取り除いた属性名Ｅｓの一覧である。それぞれの属性名Ｅｓは、エンティティＥｍとの対応関係を有していない。そして、次に、エンティティ候補抽出部２３は、図１２の属性名Ｅｓに基づいて、新たなエンティティ候補を抽出する。

[具体例：図９の工程Ｓ１３]
図９のフローチャート図で説明したとおり、次に、エンティティ候補抽出部２３は、属性名とエンティティ候補の間の関連度を用いて、属性名の一覧に基づいて、属性名に対応するエンティティ候補を推察し追加する（Ｓ１３）。具体的に、エンティティ候補抽出部２３は、予め用意された属性名-エンティティ候補関連度表Ｈ１を参照して、各属性名について、所定以上の関連度を有する、当該属性名に対応する１つまたは複数のエンティティの候補との対応関係を抽出する。前述したとおり、属性名-エンティティ候補関連度表Ｈ１におけるエンティティ候補は任意の候補である。また、本実施の形態例において、関連度は、例えば、属性名とエンティティ候補との共起使用頻度、属性名とエンティティ候補の類似度のいずれかまたは両方に基づいて取得される。

図１３は、本実施の形態例における属性名-エンティティ候補関連度表Ｈ１の一例を示す図である。具体的に、図１３の属性名-エンティティ候補関連度表Ｈ１は、属性名とエンティティ候補との共起使用頻度に基づいて生成された関連度表の一例である。図１３の属性名-エンティティ候補関連度表Ｈ１は、例えば、「*の‘属性名’」を検索キーワードとしてＷｅｂ上の検索エンジンを用いて検索したときのヒット数に基づいて生成される。「*の‘属性名’」の*（アスタリスク）は、エンティティ候補を示すワイルドカードである。例えば、属性名が注文年月日である場合、検索キーワードは「*の注文年月日」となる。Ｗｅｂ上の検索エンジンによって、検索キーワード「*の注文年月日」を検索したときの検索ヒット数に基づいて、任意のエンティティ候補が抽出されると共に、抽出された各エンティティ候補と属性名「注文年月日」とが関連を持って使用されるＷｅｂページ数、即ち、使用頻度が検出可能になる。

なお、図１３の属性名-エンティティ候補関連度表Ｈ１の共起使用頻度は、Ｗｅｂ上の検索エンジンを用いて検索した場合のヒット数に基づいて取得されるが、共起使用頻度は、市販の共起頻度辞書に基づいて取得されてもよい。また、属性名-エンティティ候補関連度表Ｈ１における関連度は、属性名とエンティティ候補との類似度に基づいていてもよい。属性名とエンティティ候補との類似度は、例えば、市販のシソーラス辞典等に基づいて取得される。

図１４は、図９の工程Ｓ１３によって更新されるエンティティ-属性名関係表Ｔ３の一例を示す図である。図１４に示すエンティティ-属性名関係表Ｔ３における属性名は、工程Ｓ１２によって取得された属性名に対応する。また、図１４に示すエンティティ-属性名関係表Ｔ３は、エンティティ候補として例えば、「注文」「商品」「顧客」「購入者」「学校」を例示しているが、実際には、エンティティ候補は膨大な数となる。

エンティティ候補抽出部２３は、属性名各々について、図１３に例示した属性名-エンティティ候補関連度表Ｈ１を参照し、エンティティ-属性名関係表Ｔ３における属性名が一致する行を検索する。そして、エンティティ候補抽出部２３は、属性名と関連度（図１３の例では共起使用頻度）が高いエンティティをエンティティ候補として、エンティティ-属性名関係表Ｔ３に追記し、属性名とエンティティ候補とが対応関係を有することを示す白丸をエンティティ-属性名関係表Ｔ３に記載する。エンティティ候補抽出部２３は、例えば、関連度が所定の基準値以上であるといった絶対的な指標や、全てのエンティティ候補の関連度における平均値以上や最大関連度における所定の割合といった相対的な指標等に基づいて、エンティティ候補を抽出する。または、エンティティ候補抽出部２３は、各属性名について、関連度が上位から所定個のエンティティ候補を抽出してもよい。

図１４の例において、エンティティ候補抽出部２３は、属性名「注文年月日」について、図１３に例示した属性名-エンティティ候補関連度表Ｈ１に基づいて、エンティティ候補「注文」「商品」等の多量のエンティティ候補からエンティティ候補「注文」を取得する。そして、エンティティ候補抽出部２３は、図１４のエンティティ-属性名関係表Ｔ３の属性名「注文年月日」とエンティティ候補「注文」との対応関係に白丸を付与する。同様にして、エンティティ候補抽出部２３は、例えば、属性名「住所」について、図１３に例示した属性名-エンティティ候補関連度表Ｈ１に基づいて、エンティティ候補「顧客」「購入者」「学校」等の多量のエンティティ候補から、エンティティ候補「顧客」「購入者」「学校」を取得する。そして、エンティティ候補抽出部２３は、図１４のエンティティ-属性名関係表Ｔ３の属性名「住所」とエンティティ候補「顧客」「購入者」「学校」との各対応関係に白丸を付与する。他の属性名についても同様である。

図１３及び図１４で説明したように、関連度が共起使用頻度または類似度のいずれか両方に基づいて取得されることにより、客観的な情報に基づいた関連度が取得可能になる。また、エンティティ候補抽出部２３は、属性名と所定以上の関連度を有するエンティティ候補を抽出することによって、ユーザがエンティティ候補を提示する場合に対して、客観的な情報である関連度に基づいて、より適切なエンティティ候補を網羅的に抽出することができる。したがって、エンティティ候補抽出部２３は、エンティティの不足を補うことができる。

図９の工程Ｓ１３によって、エンティティ候補抽出部２３は、属性名各々について、当該属性名と関連度が高い１つまたは複数のエンティティ候補との対応関係を抽出する。抽出したエンティティ候補は、ＴｏＢｅスキーマＳｔのデータ体系におけるエンティティの候補である。

[具体例：図９の工程Ｓ１４]
次に、エンティティ候補群抽出部２４は、対応関係を有する属性名の集合が全ての属性名を含むエンティティ候補群のうち、エンティティ候補の数が最少となるエンティティ候補群（エンティティ候補の組み合わせ）を抽出する（Ｓ１４）。具体的に、エンティティ候補群抽出部２４は、対応関係を有する属性名の集合が、エンティティ-属性名関係表Ｔ３の属性名の一覧（注文年月日、氏名、年齢、住所、学区、電話番号、ＦＡＸ、商品番号、数量、商品名、単価）と一致する最少数のエンティティ候補の組み合わせを抽出する。エンティティ候補の数が小さい程、エンティティ候補間の類似度の総和が小さくなり、互いに独立な概念を有することが想定される。なお、抽出されるエンティティ候補群の各エンティティ候補は、互いに、対応関係を有する属性名が重複してもよい。

図１５は、図９の工程Ｓ１４によって抽出される２つのエンティティ候補群の例をそれぞれ示すエンティティ-属性名関係表Ｔ４−１、Ｔ４−２を示す図である。図１５は、第１のエンティティ候補群（Ａ）を有するエンティティ-属性名関係表Ｔ４−１と第２のエンティティ候補群（Ｂ）を有するエンティティ-属性名関係表Ｔ４−２を有する。

エンティティ-属性名関係表Ｔ４−１に示す第１のエンティティ候補群（Ａ）は、エンティティ候補「ａ：注文」「ｂ：商品」「ｃ：顧客」「ｅ：学校」を有する。また、第１のエンティティ候補群（Ａ）のエンティティ候補「ａ：注文」「ｂ：商品」「ｃ：顧客」「ｅ：学校」が対応関係を有する属性名の集合（注文年月日、氏名、年齢、住所、学区、電話番号、ＦＡＸ、商品番号、数量、商品名、単価）は、図９の工程Ｓ１３によって生成されたエンティティ-属性名関係表Ｔ３が有する属性名の一覧と一致する。即ち、第１のエンティティ候補群（Ａ）は、対応関係を有する属性名の集合が全ての属性名を含み、エンティティ候補の数が最少となるエンティティ候補群に該当する。

また、エンティティ-属性名関係表Ｔ４−２に示す第２のエンティティ候補群（Ｂ）は、エンティティ候補「ａ：注文」「ｂ：商品」「ｄ：購入者」「ｅ：学校」を有する。また、第２のエンティティ候補群（Ｂ）のエンティティ候補「ａ：注文」「ｂ：商品」「ｄ：購入者」「ｅ：学校」が対応関係を有する属性名の集合（注文年月日、氏名、年齢、住所、学区、電話番号、ＦＡＸ、商品番号、数量、商品名、単価）は、図９の工程Ｓ１３によって生成されたエンティティ-属性名関係表が有する属性名の一覧と一致する。即ち、第２のエンティティ候補群（Ｂ）は、対応関係を有する属性名の集合が全ての属性名を含み、エンティティ候補の数が最少となるエンティティ候補群に該当する。

エンティティ候補群抽出部２４は、最少のエンティティ候補を有するエンティティ候補群を選択することによって、再構成後のデータ体系が膨大になることを回避すると共に、互いに独立した概念を有するエンティティ候補群を取得する。エンティティ候補群抽出部２４は、エンティティ候補群を複数（この例では、エンティティ候補群（Ａ）（Ｂ））抽出し得る。

図１６は、図１５に示すエンティティ候補群を関連図に基づいて説明する図である。図１６は、図１５で説明したエンティティ-属性名関係表Ｔ４−１、Ｔ４−２に対応する関連図Ｐ４−１、Ｐ４−２を示す。関連図Ｐ４−１、Ｐ４−２は、それぞれ、属性名Ｅｓとエンティティ候補群の各エンティティ候補と対応関係を有する。図１６によると、工程Ｓ１４の過程において、属性名Ｅｓの一部は、複数のエンティティ候補Ｅｍと対応関係を有する。

[具体例：図９の工程Ｓ１５]
次に、エンティティ候補群選択部２５は、工程Ｓ１４によって抽出したエンティティ候補群（Ａ）（Ｂ）から、各エンティティ候補群におけるエンティティ候補間の関連度を用いて、エンティティ候補群のエンティティ候補間の関連度の総和が最大になるエンティティ候補群を選択する（Ｓ１５）。具体的に、エンティティ候補群選択部２５は、エンティティ候補間関連度表Ｈ２を参照して、エンティティ候補群（Ａ）（Ｂ）のうち、エンティティ候補間の関連度がより高いエンティティ候補群を選択する。

本実施の形態例において、エンティティ候補間の関連度は、例えば、エンティティ候補間の共起使用頻度、エンティティ候補間の類似度のいずれかまたは両方に基づいて取得される。エンティティ候補間の関連度が共起使用頻度または類似度のいずれか両方に基づいて取得されることにより、客観的な情報に基づいたエンティティ候補間の関連度が取得可能になる。

同一の特定の業務内で使用されるエンティティ候補群の各エンティティ候補は、それぞれ独立した概念を有するものの、関連度は高いことが想定される。したがって、エンティティ候補群選択部２５は、エンティティ候補間の関連度がより高いエンティティ候補群を選択することによって、客観的な情報である関連度に基づいて、より適切なエンティティ候補群を選択することができる。

図１７は、本実施の形態例におけるエンティティ候補間関連度表Ｈ２の一例を示す図である。具体的に、図１７のエンティティ候補間関連度表Ｈ２は、エンティティ候補間の共起使用頻度に基づいて生成された関連度表の一例である。図１７のエンティティ候補間関連度表Ｈ２は、例えば、「‘第１のエンティティ候補’ ‘第２のエンティティ候補’」を検索キーワードとしてＷｅｂ上の検索エンジンを用いて検索したときのヒット数に基づいて生成される。例えば、第１のエンティティ候補が「注文」であって、第２のエンティティ候補が「商品」である場合、検索キーワードは「注文 商品」となる。Ｗｅｂ上の検索エンジンによって、検索キーワード「注文 商品」を検索したときの検索ヒット数に基づいて、エンティティ候補「注文」とエンティティ候補「商品」とが同時に使用されるＷｅｂページの数、即ち、使用頻度が検出可能になる。

なお、図１７のエンティティ候補間関連度表Ｈ２の共起使用頻度は、Ｗｅｂ上の検索エンジンを用いて検索した場合のヒット数に基づいて取得されるが、共起使用頻度は、市販の共起頻度辞書に基づいて取得されてもよい。また、エンティティ候補間関連度表Ｈ２における関連度は、エンティティ候補間の類似度に基づいていてもよい。エンティティ候補間の類似度は、例えば、市販のシソーラス辞典等に基づいて取得される。

エンティティ候補群選択部２５は、図１７に例示したエンティティ候補間関連度表Ｈ２を参照して、エンティティ候補群（Ａ）（Ｂ）それぞれについて、エンティティ候補群が有するエンティティ候補間の相互の関係における各関連度（図１７の例では使用頻度）を取得する。そして、エンティティ候補群選択部２５は、エンティティ候補群（Ａ）（Ｂ）それぞれについて、エンティティ候補群が有するエンティティ候補相互の関係の各関連度の合計を算出する。図１７のエンティティ候補間関連度表Ｈ２に基づく場合、エンティティ候補群（Ａ）における関連度の合計は、エンティティ候補群（Ｂ）における関連度の合計よりも大きい。したがって、エンティティ候補群選択部２５は、工程Ｓ１５によって、エンティティ候補群（Ａ）を選択する。

[具体例：図９の工程Ｓ１６]
次に、対応関係選択部２６は、複数のエンティティ候補と重複して対応関係を有する属性名について、重複した前記対応関係を減少させる（Ｓ１６）。具体的に、対応関係選択部２６は、複数のエンティティ候補と対応関係を有する属性名各々について、図１３に示した属性名-エンティティ候補関連度表Ｈ１を参照し、対応するエンティティ候補との間の関連度が高い、即ち、同一の特定の業務内で使用される度合いがより高い対応関係を選択する。同一の特定の業務内で使用されるエンティティ候補と属性名との関連度は高いことが想定される。

図１８は、属性名とエンティティ候補との対応関係の選択処理（図９のＳ１６）を説明する図である。図１８のエンティティ-属性名関係表Ｔ４−１は、図１５のエンティティ-属性名関係表Ｔ４−１と同一である。エンティティ-属性名関係表Ｔ４−１において、例えば、属性名「住所」は、エンティティ候補「顧客」及びエンティティ候補「学校」と対応関係を有する。即ち、属性名「住所」は、複数のエンティティ候補と重複して対応関係を有する。図１３に示す属性名-エンティティ候補関連度表Ｈ１によると、属性名「住所」とエンティティ候補「顧客」の使用頻度は、属性名「住所」とエンティティ候補「学校」の使用頻度より大きい。したがって、対応関係選択部２６は、属性名「住所」とエンティティ候補「顧客」との対応関係と、属性名「住所」とエンティティ候補「学校」との対応関係のうち、属性名「住所」とエンティティ候補「顧客」との対応関係を選択する。対応関係選択部２６は、エンティティ-属性名関係表Ｔ５における、属性名「住所」とエンティティ候補「学校」との対応関係を示す白丸ｘ１を除去する。

また、図１８のエンティティ-属性名関係表Ｔ４−１において、例えば、属性名「商品番号」も、エンティティ候補「注文」及びエンティティ候補「商品」と対応関係を有し、複数のエンティティ候補と重複して対応関係を有する。図１３に示す属性名-エンティティ候補関連度表Ｈ１によると、属性名「商品番号」とエンティティ候補「注文」の使用頻度は、属性名「商品番号」とエンティティ候補「商品」の使用頻度より小さい。したがって、対応関係選択部２６は、属性名「商品番号」とエンティティ候補「商品」を選択し、エンティティ-属性名関係表Ｔ５における、属性名「商品番号」とエンティティ候補「注文」との対応関係を示す白丸ｘ２を除去する。対応関係選択部２６は、エンティティ-属性名関係表Ｔ４−１において重複した対応関係を有する他の属性名（例えば、電話番号、ＦＡＸ、数量）の対応関係についても同様に処理する。

図１８に示すように、対応関係選択部２６は、エンティティ候補間における、属性名との対応関係の重複を除去する（Ｓ１６）。対応関係選択部２６は、属性名とエンティティ候補との関連度が最大の対応関係を選択することによって、客観的な情報である関連度に基づいて、より適切な属性名とエンティティ候補との対応関係を選択することができる。また、対応関係選択部２６は、工程Ｓ１６の処理の結果、それぞれ異なる属性名群と対応関係を有するエンティティ候補群、即ち、互いに同一の属性名と対応関係を有しないエンティティ候補群を取得する。

図１９は、属性名とエンティティ候補との対応関係の選択処理を関連図に基づいて説明する図である。図１９は、図１６に示す関連図Ｐ４−１に対して、属性名「商品番号」「数量」「電話番号」「ＦＡＸ」「住所」Ｅｓそれぞれが、最も関連度の大きい１つのエンティティ候補Ｅｍとのみ対応関係を有する。図１９において、破線は、除去された対応関係を示す。

[具体例：図９の工程Ｓ１７]
次に、ＴｏＢｅスキーマ出力部２７は、工程Ｓ１１〜Ｓ１６によって取得したエンティティ候補と属性名との対応関係をＴｏＢｅスキーマに出力する（Ｓ１７）。具体的に、ＴｏＢｅスキーマ出力部２７は、図１４のエンティティ-属性名関係表Ｔ５のエンティティ候補及び属性名を、ＴｏＢｅスキーマのエンティティ及び属性名にそれぞれに記載する。

図２０は、図９の工程Ｓ１７によって出力されたＴｏＢｅスキーマＳｔｘのデータ体系を説明する図である。図１８のエンティティ-属性名関係表Ｔ５は、エンティティ候補「注文」として、属性名「注文年月日」「数量」と対応関係を有する。また、エンティティ候補「商品」は、属性名「商品番号」「商品名」「単価」と対応関係を有する。また、エンティティ候補「顧客」は、属性名「氏名」「年齢」「住所」「電話番号」「ＦＡＸ」と対応関係を有する。また、エンティティ候補「学校」は、属性名「学区」と対応関係を有する。したがって、図２０のＴｏＢｅスキーマＳｔｘのデータ体系も、図１８のエンティティ-属性名関係表Ｔ５と同様のエンティティと属性名、及び、エンティティと属性名との対応関係を有する。

図２０に示すように、ＴｏＢｅスキーマＳｔｘは、互いに同一の属性名と対応関係を有しておらず、互いに独立した概念を有するエンティティ「注文」「商品」「顧客」を有する。したがって、ＤＢ再構成装置１０は、工程Ｓ１１〜Ｓ１６によって、図２に示すＡｓＩｓスキーマＳｔ１のデータ体系を準直交化したＴｏＢｅスキーマＳｔｘを生成することができる。続く、工程Ｓ１８の処理は、ＤＢの再構成における補足的な工程を示す。

［具体例：図９の工程Ｓ１８］
続いて、ユーザは、例えば、人手によってエンティティ間の参照関係等を補う（Ｓ１８）。具体的に、ＴｏＢｅスキーマの各エンティティが、当該エンティティのデータを一意に特定可能な識別情報を有しない場合、ユーザは、エンティティに「○○ＩＤ」や「○○番号」等の識別情報の属性名を追加する。また、ユーザは、エンティティの識別情報を用いてエンティティの間の参照関係を補足する。

図２１は、ユーザによってエンティティ間の参照関係が補われたＴｏＢｅスキーマＳｔ２のデータ体系の例を示す図である。図２１のＴｏＢｅスキーマＳｔ１は、図２のＴｏＢｅスキーマＳｔ１に対応する。なお、図２１のＴｏＢｅスキーマＳｔ１のデータ体系において、中括弧（［］）で囲む属性名は、エンティティのデータを一意に特定する識別情報を示す属性名である。具体的に、エンティティ「注文」の属性名［注文番号］は、エンティティ「注文」の複数のデータを識別可能にする情報である。同様にして、エンティティ「顧客」の属性名［顧客番号］は、エンティティ「顧客」の複数のデータを識別可能にする識別情報である。

また、図２１の例において、エンティティ「注文」は、エンティティ「商品」「顧客」のデータを参照する。したがって、エンティティ「注文」は、関連するエンティティ「商品」「顧客」のデータを一意に特定する属性名「商品番号」「顧客番号」を有する。同様にして、エンティティ「顧客」は、エンティティ「学校」のデータを参照するため、関連するエンティティ「学校」のデータを一意に特定する属性名「学校番号」を有する。

工程Ｓ１８によって、スキーマに基づいて準直交化されたデータ体系が調整される。なお、本実施の形態例におけるＤＢの再構成処理（図９のＳ１１〜Ｓ１８）は、エンティティ間で属性名が循環しているデータ体系に対しても有効である。

図２２は、エンティティ間の参照関係が補われたＴｏＢｅスキーマＳｔ２のデータ体系を関連図に基づいて説明する図である。図２２に示す関連図は、図１９に示す関連図に加えて、エンティティのデータを一意に特定する属性名「商品番号」「顧客番号」「学校番号」Ｅｓを有する。また、図２２の関連図における点線は、他のエンティティからの参照関係を表す。

図２３は、エンティティ間で属性名が循環するＡｓＩｓスキーマＳａのデータ体系のエンティティ-属性名関係表Ｔ１１、Ｔ１２の一例を示す図である。図２３は、ＡｓＩｓスキーマＳａに基づくエンティティ-属性名関係表Ｔ１１と、エンティティを削除したエンティティ-属性名関係表Ｔ１２の例を有する。

具体的に、図２３のエンティティ-属性名関係表Ｔ１１によると、エンティティ「注文」「商品」「顧客」を有する。また、エンティティ-属性名関係表Ｔ１１によると、エンティティ「注文」は属性名「注文番号」に加えて、属性名「商品番号」「顧客番号」を有する。また、エンティティ「商品」は、属性名「商品番号」に加えて、属性名「注文番号」を有する。即ち、エンティティ「注文」「商品」は、相互に識別番号を有する。したがって、例えば、ある注文Ａにおける、エンティティ「注文」が参照するエンティティ「商品」の属性名「注文番号」が、別の注文Ｂの注文番号を示す場合、エンティティの間で属性名が循環する。

本実施の形態例におけるＤＢの再構成方法によると、まず、エンティティ-属性名関係表生成部２１は、ＡｓＩｓスキーマＳａからエンティティ及び属性名を抽出し、複数のエンティティの間で重複する属性名がある場合、１つの属性名のみを、図２３に示すエンティティ-属性名関係表Ｔ１２に記載する（図９のＳ１１）。したがって、図２３のエンティティ-属性名関係表Ｔ１２は、重複のない属性名の一覧を有する。つまり、エンティティ-属性名関係表Ｔ生成部２１は、エンティティ間で属性名が循環する場合であっても、エンティティ-属性名関係表Ｔ１１からエンティティを削除し、属性名の重複を除外するため、重複のない属性名の一覧（エンティティ-属性名関係表Ｔ１２）を取得することができる。そして、本実施の形態例におけるＤＢの再構成方法によると、属性名に基づいてエンティティの過不足を補うことが可能になる。したがって、本実施の形態例におけるＤＢの再構成方法は、エンティティ間で属性名が循環しているデータ体系に対しても適用可能である。

以上のように、本実施の形態例におけるＤＢの再構成方法では、複数のＤＢのいずれかに含まれる属性名、及び、属性名とエンティティとの関連度に関する第１の情報に基づいて、複数のエンティティ候補を抽出し、抽出した複数のエンティティ候補によって構成されるエンティティ候補の組であって、エンティティ候補の組を構成するエンティティ候補がいずれかの属性名と対応関係を有することによってすべての属性名と対応関係を有し、構成するエンティティ候補の数が最少となるエンティティ候補の組を複数、特定する。また、ＤＢの再構成方法では、特定された複数のエンティティ候補の組のうち、エンティティ間の関連度に関する第２の情報に基づいて、エンティティ候補の組に含まれるエンティティ候補間の関連度の総和が最大となるエンティティ候補の組を特定する。そして、ＤＢの再構成方法では、複数の属性名それぞれを、第１の情報に基づいて、エンティティ候補の組を構成するエンティティ候補のいずれかと対応関係を有するように割り当てる。

本実施の形態例におけるＤＢの再構成方法によると、ＤＢが有する複数の属性名の情報に基づいて、互いに同一の属性名を持たず、かつ、独立した概念を有するエンティティの組み合わせを選択することが可能になる。つまり、本実施の形態例におけるＤＢの再構成方法によると、業務システムのスキーマのデータ体系に基づいた準直交化によるＤＢの再構成を自動化することが可能になる。したがって、業務システムの運用及び保守の工数の削減や品質の向上を図ることが可能になる。

また、本実施の形態例におけるＤＢの再構成方法によると、スキーマのデータ体系のみに基づくことにより、ＤＢの実データ（属性値）やシステムの画面及び帳票の構成情報を要することなく、ＤＢの再構成が可能となる。即ち、実データや画面等が使用できない場合であっても、スキーマのデータ体系に基づく自動的な準直交化が可能になると共に、既存のシステムの実データや画面等に関する機密性が保持される。また、本実施の形態例におけるＤＢの再構成方法によると、属性名の一覧を維持することにより、既存の実データに影響を与えることなくＤＢの再構成が可能になる。

また、本実施の形態例におけるＤＢの再構成方法によると、各属性名とエンティティ候補の間の関連度を用いて、現状の属性名に基づいてあるべきエンティティ候補を抽出することによって、エンティティの過不足を補足することが可能になる。また、関連度が最大となるエンティティ候補群を選択することにより、１つの特定の業務に関するエンティティ候補群の関連度は高いという想定のもと、同一の業務内で使用される度合いがより高いエンティティ候補群が選択可能になる。これにより、エンティティ候補群の冗長性がより適切に改善可能になる。

また、本実施の形態例におけるＤＢの再構成方法によると、最少のエンティティ候補を有するエンティティ候補群が選択されることによって、再構成後のデータ体系が膨大になることが回避される。また、エンティティ候補が少ない程、エンティティ候補間の類似度の総和が小さくなり、互いに独立な概念を有することが想定される。したがって、本実施の形態例におけるＤＢの再構成方法によると、互いに独立した概念を有するエンティティ候補群が選択可能になる。

また、本実施の形態例におけるＤＢの再構成方法には、入力となるデータ体系の仕様に制限がない。即ち、本実施の形態例におけるＤＢの再構成方法は、複数のＤＢに跨るデータ体系に対して有効であると共に、複数のＤＢをそれぞれ有する複数のシステムに跨るデータ体系に対しても有効である。

また、本実施の形態例におけるＤＢの再構成方法によると、複数のエンティティ候補を抽出した後、抽出した複数のエンティティ候補それぞれと、複数の属性名それぞれとの対応関係を有する対応関係情報を生成し、対応関係情報に基づいて、複数のエンティティ候補のうち複数のエンティティ候補の組を特定する。これにより、すべての属性名との対応関係を有するエンティティ候補の組が効率的に特定可能になる。

また、本実施の形態例におけるＤＢの再構成方法によると、エンティティ候補の組を特定した後、複数の属性名それぞれを、エンティティ候補の組に属するエンティティ候補のうち、第１の情報に基づく関連度が最大のエンティティ候補に割り当てる。したがって、１つの特定の業務に関する属性名とエンティティ候補との関連度は高いという想定のもと、関連度が最大となる属性名とエンティティ候補との対応関係を選択することによって、同一の業務内で使用される度合いがより高い対応関係が選択可能になる。これにより、より適切な対応関係が選択可能になる。

また、本実施の形態例におけるＤＢの再構成方法によると、属性名とエンティティとの関連度は、属性名とエンティティとの共起頻度、属性名とエンティティとの類似度のいずれかまたは両方に基づいて取得される。したがって、本実施の形態例におけるＤＢの再構成方法によると、関連度が共起使用頻度または類似度のいずれか両方に基づいて取得されることにより、客観的な情報に基づいた関連度が取得可能になる。また、属性名と所定以上の関連度を有するエンティティ候補を抽出することによって、ユーザがエンティティ候補を提示する場合に対して、客観的な情報に基づいたより適切なエンティティ候補が抽出可能になる。さらに、属性名とエンティティ候補との関連度が最大の対応関係を選択することによって、客観的な情報に基づいたより適切な属性名とエンティティ候補との対応関係が選択可能になる。

また、本実施の形態例におけるＤＢの再構成方法によると、エンティティ間の関連度は、エンティティと別のエンティティとの共起頻度、エンティティと別のエンティティとの類似度のいずれかまたは両方に基づいて取得される。したがって、関連度が共起使用頻度または類似度のいずれか両方に基づいて取得されることにより、客観的な情報に基づいたエンティティ候補間の関連度が取得可能になる。また、最大の関連度を有するエンティティ候補群を選択することによって、客観的な情報に基づいたより適切なエンティティ候補群の選択が可能になる。

以上の実施の形態をまとめると、次の付記のとおりである。

（付記１）
それぞれが、複数の属性名と対応関係を有するエンティティを有する複数のデータベースの再構成方法であって、
複数のデータベースのいずれかに含まれる前記属性名、及び、前記属性名と前記エンティティとの関連度に関する第１の情報に基づいて、複数のエンティティ候補を抽出し、
前記抽出した複数のエンティティ候補によって構成されるエンティティ候補の組であって、前記エンティティ候補の組を構成する前記エンティティ候補がいずれかの前記属性名と対応関係を有することによってすべての前記属性名と対応関係を有し、前記構成するエンティティ候補の数が最少となるエンティティ候補の組を複数、特定し、
前記特定された複数のエンティティ候補の組のうち、前記エンティティ間の関連度に関する第２の情報に基づいて、前記エンティティ候補の組に含まれるエンティティ候補間の関連度の総和が最大となるエンティティ候補の組を特定し、
前記複数の属性名それぞれを、前記第１の情報に基づいて、前記エンティティ候補の組を構成する前記エンティティ候補のいずれかと対応関係を有するように割り当てることを特徴とするデータベースの再構成方法。

（付記２）
付記１において、
前記複数のエンティティ候補を抽出した後、前記抽出した前記複数のエンティティ候補それぞれと、前記複数の属性名それぞれとの対応関係を有する対応関係情報を生成し、前記対応関係情報に基づいて、前記複数のエンティティ候補の組を特定するデータベースの再構成方法。

（付記３）
付記１または２において、
前記エンティティ候補の組を特定した後、前記複数の属性名それぞれを、前記エンティティ候補の組に属する前記エンティティ候補のうち、前記第１の情報に基づく関連度が最大の前記エンティティ候補に割り当てるデータベースの再構成方法。

（付記４）
付記１乃至３のいずれかにおいて、
前記属性名と前記エンティティとの関連度は、前記属性名と前記エンティティとの共起頻度、前記属性名と前記エンティティとの類似度のいずれかまたは両方に基づいて取得されるデータベースの再構成方法。

（付記５）
付記１乃至４のいずれかにおいて、
前記エンティティ間の関連度は、前記エンティティと別の前記エンティティとの共起頻度、前記エンティティと前記別のエンティティとの類似度のいずれかまたは両方に基づいて取得されるデータベースの再構成方法。

（付記６）
それぞれが、複数の属性名と対応関係を有するエンティティを有する複数のデータベースの再構成処理をコンピュータに実行させるコンピュータ読み取り可能なデータベースの再構成プログラムであって、
複数のデータベースのいずれかに含まれる前記属性名、及び、前記属性名と前記エンティティとの関連度に関する第１の情報に基づいて、複数のエンティティ候補を抽出する抽出工程と、
前記抽出した複数のエンティティ候補によって構成されるエンティティ候補の組であって、前記エンティティ候補の組を構成する前記エンティティ候補がいずれかの前記属性名と対応関係を有することによってすべての前記属性名と対応関係を有し、前記構成するエンティティ候補の数が最少となるエンティティ候補の組を複数、特定する第１の特定工程と、
前記特定された複数のエンティティ候補の組のうち、前記エンティティ間の関連度に関する第２の情報に基づいて、前記エンティティ候補の組に含まれるエンティティ候補間の関連度の総和が最大となるエンティティ候補の組を特定する第２の特定工程と、
を前記複数の属性名それぞれを、前記第１の情報に基づいて、前記エンティティ候補の組を構成する前記エンティティ候補のいずれかに割り当てる割り当て工程と、有することを特徴とするデータベースの再構成プログラム。

（付記７）
付記６において、
前記第１の特定工程は、前記抽出した前記複数のエンティティ候補それぞれと、前記複数の属性名それぞれとの対応関係を有する対応関係情報を生成し、前記対応関係情報に基づいて、前記複数のエンティティ候補の組を特定するデータベースの再構成プログラム。

（付記８）
付記６または７において、
前記第２の特定工程は、前記複数の属性名それぞれを、前記エンティティ候補の組に属する前記エンティティ候補のうち、前記第１の情報に基づく関連度が最大の前記エンティティ候補に割り当てるデータベースの再構成プログラム。

（付記９）
それぞれが、複数の属性名と対応関係を有するエンティティを有する複数のデータベースの再構成装置であって、
複数のデータベースのいずれかに含まれる前記属性名、及び、前記属性名と前記エンティティとの関連度に関する第１の情報に基づいて、複数のエンティティ候補を抽出する抽出手段と、
前記抽出した複数のエンティティ候補によって構成されるエンティティ候補の組であって、前記エンティティ候補の組を構成する前記エンティティ候補がいずれかの前記属性名と対応関係を有することによってすべての前記属性名と対応関係を有し、前記構成するエンティティ候補の数が最少となるエンティティ候補の組を複数、特定する第１の特定手段と、
前記特定された複数のエンティティ候補の組のうち、前記エンティティ間の関連度に関する第２の情報に基づいて、前記エンティティ候補の組に含まれるエンティティ候補間の関連度の総和が最大となるエンティティ候補の組を特定する第２の特定手段と、
を前記複数の属性名それぞれを、前記第１の情報に基づいて、前記エンティティ候補の組を構成する前記エンティティ候補のいずれかに割り当てる割り当て手段と、有することを特徴とするデータベースの再構成装置。

（付記１０）
付記９において、
前記第１の特定手段は、前記抽出した前記複数のエンティティ候補それぞれと、前記複数の属性名それぞれとの対応関係を有する対応関係情報を生成し、前記対応関係情報に基づいて、前記複数のエンティティ候補の組を特定するデータベースの再構成装置。

（付記１１）
付記９または１０において、
前記第２の特定手段は、前記複数の属性名それぞれを、前記エンティティ候補の組に属する前記エンティティ候補のうち、前記第１の情報に基づく関連度が最大の前記エンティティ候補に割り当てるデータベースの再構成装置。

１０：ＤＢ再構成装置、１１：入力装置、１２：表示装置、１３：通信インタフェース、１４：プロセッサ、１５：記憶媒体、１６：メモリ、ＰＲ：ＤＢ再構成プログラム、Ｓａ：ＡｓＩｓスキーマ、Ｓｔ：ＴｏＢｅスキーマ、Ｈ１：属性-エンティティ候補関連度表、Ｈ２：エンティティ候補間関連度表、２１：エンティティ-属性関係表生成部、２２：属性抽出部、２３：エンティティ候補抽出部、２４：エンティティ候補群抽出部、２５：エンティティ候補群選択部、２６：対応関係選択部、２７：ＴｏＢｅスキーマ出力部

Claims (7)

1. それぞれが、複数の属性名と対応関係を有するエンティティを有する複数のデータベースの再構成処理をコンピュータに実行させるコンピュータ読み取り可能なデータベースの再構成プログラムであって、
   複数のデータベースのいずれかに含まれる前記属性名、及び、前記属性名と前記エンティティとの関連度に関する第１の情報に基づいて、複数のエンティティ候補を抽出する抽出工程と、
   前記抽出した複数のエンティティ候補によって構成されるエンティティ候補の組であって、前記エンティティ候補の組を構成する前記エンティティ候補がいずれかの前記属性名と対応関係を有することによってすべての前記属性名と対応関係を有し、前記構成するエンティティ候補の数が最少となるエンティティ候補の組を複数、特定する第1の特定工程と、
   前記特定された複数のエンティティ候補の組のうち、前記エンティティ間の関連度に関する第２の情報に基づいて、前記エンティティ候補の組に含まれるエンティティ候補間の関連度の総和が最大となるエンティティ候補の組を特定する第２の特定工程と、
   前記複数の属性名それぞれを、前記第１の情報に基づいて、前記エンティティ候補の組を構成する前記エンティティ候補のいずれかと対応関係を有するように割り当てる割り当て工程とを有することを特徴とするデータベースの再構成プログラム。
2. 請求項１において、
   前記複数のエンティティ候補を抽出した後、前記抽出した前記複数のエンティティ候補それぞれと、前記複数の属性名それぞれとの対応関係を有する対応関係情報を生成し、前記対応関係情報に基づいて、前記複数のエンティティ候補の組を特定するデータベースの再構成プログラム。
3. 請求項１または２において、
   前記エンティティ候補の組を特定した後、前記複数の属性名それぞれを、前記エンティティ候補の組に属する前記エンティティ候補のうち、前記第１の情報に基づく関連度が最大の前記エンティティ候補に割り当てるデータベースの再構成プログラム。
4. 請求項１乃至３のいずれかにおいて、
   前記属性名と前記エンティティとの関連度は、前記属性名と前記エンティティとの共起頻度、前記属性名と前記エンティティとの類似度のいずれかまたは両方に基づいて取得するデータベースの再構成プログラム。
5. 請求項１乃至４のいずれかにおいて、
   前記エンティティ間の関連度は、前記エンティティと別の前記エンティティとの共起頻度、前記エンティティと前記別のエンティティとの類似度のいずれかまたは両方に基づいて取得するデータベースの再構成プログラム。
6. それぞれが、複数の属性名と対応関係を有するエンティティを有する複数のデータベースの再構成方法であって、
   プロセッサが、複数のデータベースのいずれかに含まれる前記属性名、及び、前記属性名と前記エンティティとの関連度に関する第１の情報に基づいて、複数のエンティティ候補を抽出し、
   前記プロセッサが、前記抽出した複数のエンティティ候補によって構成されるエンティティ候補の組であって、前記エンティティ候補の組を構成する前記エンティティ候補がいずれかの前記属性名と対応関係を有することによってすべての前記属性名と対応関係を有し、前記構成するエンティティ候補の数が最少となるエンティティ候補の組を複数、特定し、
   前記プロセッサが、前記特定された複数のエンティティ候補の組のうち、前記エンティティ間の関連度に関する第２の情報に基づいて、前記エンティティ候補の組に含まれるエンティティ候補間の関連度の総和が最大となるエンティティ候補の組を特定し、
   前記プロセッサが、前記複数の属性名それぞれを、前記第１の情報に基づいて、前記エンティティ候補の組を構成する前記エンティティ候補のいずれかに割り当てることを特徴とするデータベースの再構成方法。
7. それぞれが、複数の属性名と対応関係を有するエンティティを有する複数のデータベースの再構成装置であって、
   複数のデータベースのいずれかに含まれる前記属性名、及び、前記属性名と前記エンティティとの関連度に関する第１の情報に基づいて、複数のエンティティ候補を抽出する抽出手段と、
   前記抽出した複数のエンティティ候補によって構成されるエンティティ候補の組であって、前記エンティティ候補の組を構成する前記エンティティ候補がいずれかの前記属性名と対応関係を有することによってすべての前記属性名と対応関係を有し、前記構成するエンティティ候補の数が最少となるエンティティ候補の組を複数、特定する第１の特定手段と、
   前記特定された複数のエンティティ候補の組のうち、前記エンティティ間の関連度に関する第２の情報に基づいて、前記エンティティ候補の組に含まれるエンティティ候補間の関連度の総和が最大となるエンティティ候補の組を特定する第２の特定手段と、
   前記複数の属性名それぞれを、前記第１の情報に基づいて、前記エンティティ候補の組を構成する前記エンティティ候補のいずれかに割り当てる割り当て手段とを、有することを特徴とするデータベースの再構成装置。

Images