JP6159908B1 - 異種データソース混在環境におけるフィールド間の関係性の自動的発見のための方法、プログラム、および、システム - Google Patents

Abstract

設計の異なる複数のデータソース間を横断してデータ分析を行なうためのフィールド間の関連づけを効率的に行ない、多様な分析に対応する。複数のデータストアのそれぞれのフィールドにインデックスを付与し、フィールド間の類似性を判定し、類似性が高いと判定されたフィールドをノードとするグラフ形式データ（エンタープライズ・データ・グラフ）を生成する。類似性の判定には、検索エンジンが提供する形態素解析等の技術を利用してよい。エンタープライズ・データ・グラフを利用することで、複数のデータストアを横断した多様な照会要求に対応できる。

Description

本願発明は、データ分析するための方法、プログラム、および、システムに関し、より詳細には、異種データソース混在環境におけるフィールド間の関係性を自動的に発見し、対応付けるための方法、プログラム、および、システムに関する。

今日の企業は、複数の異なるタイプのデータソースにデータを分散している。たとえば、企業の各部門（販売、サービス、出荷など）に独自のデータソースがある場合もある。一方で、報告や分析のために異なるデータソースのデータを統合する必要性が高まっている。ここで、データソースとは、データの保管および提供を行なう技術の総称であり、典型的にはデータベースだが、これに限定されない。データソースの例については後述する。データソースは、文脈によってはデータ・リポジトリ、データストア、データ・ストレージ等とも呼ばれる

しかしながら、従来システムでは、データがどこに位置するか、複数のデータソース内のフィールドが互いにどのように関係しているかを判断することが困難であった。たとえば、同じモデルの製品であっても、営業部門のデータベースとサービス部門のデータベースとで製品コードが異なることがあった。異なるデータソースにおいて、関連したデータのフィールド名が異なることもあった。異なるデータソース間のフィールドを対応させることに意味がないこともあった。さらに、各データソースが、しばしば別のデータ設計者によって設計された異なるデータモデルを有することがあった。加えて、データソース内のデータはクリーンであるとは限らない（たとえば、データの欠損、不正確なデータ、形式の誤りがあることがある）。また、データソースによって同じ入力項目が異なる形式で保管されていることもある。企業内のデータ量がテラバイトからペタバイト級になることを考えると、従来システムでは、異なるデータソース内のテーブル（エンティティ）やフィールド間の関係を容易に判断できない場合が多かった。

このような問題を解決するための技術として、複数のデータソースを組み合わせて仮想データベースを構築するためのEII（Enterprise Information Integration）と呼ばれる技術が知られている（たとえば、特許文献１、非特許文献１）が、設計が異なるデータソース間でフィールドの対応付けを行なうことは依然として困難であり、十分な効果を発揮できていなかった。

特許公開公報 特開２０００−２２２４３０

Wikipedia - Enterprise information integration （https://en.wikipedia.org/wiki/Enterprise_information_integration）

設計の異なる複数のデータソース間を横断してデータ分析を行なうためのフィールド間の関連づけを効率的に行なう方法、プログラム、および、システムを提供する。

本願発明は、複数のデータストア内のデータを分析する方法であって、前記複数のデータストア内のテーブル内の複数のフィールド内の文字列の集合から重複を排除するステップと、前記重複を排除した文字列を転置インデックスに保存するステップと、前記転置インデックスに保存された文字列間の類似性を判定するステップと、前記判定された文字列間の類似性に基づいて前記複数のフィールド間の類似性を判定するステップと、前記複数のフィールド間の類似性が高いと判定されたフィールドを含むテーブルをノードとして類似関係をエッジで表現したグラフ形式データを生成するステップとを含むコンピューターにより実行される方法を提供することで前記課題に対応する。

また、本願発明は、前記転置インデックスに保存された文字列間の類似性を判定するステップは、さらに、前記複数のフィールド内の文字列に形態素解析を適用して分割するステップと、前記文字列間のコサイン類似度を求めるステップと、前記コサイン類似度にロジステック関数を適用するステップとを含む段落０００８に記載の方法を提供することで前記課題に対応する。

また、本願発明は、前記転置インデックスに保存された文字列間の類似性を判定するステップは、さらに、前記複数のフィールド内の文字列の集合を一時的テーブルに保存するステップと、前記テーブルに自然結合演算を適用するステップと、前記テーブル間の類似度を計算するステップとを含む段落０００８に記載の方法を提供することで前記課題に対応する。

また、本願発明は、さらに、前記複数のデータストア内のテーブル内の複数のフィールド内のデータの属性に基づいて前記フィールド間の類似性を判定するステップを含み、前記属性は、濃度、個別値の数、ヒストグラムの境界、ヌル値の数、または、非ヌル値の数のいずれかひとつ以上である段落０００８、段落０００９、または、段落００１０に記載の方法を提供することで前記課題に対応する。

また、本願発明は、段落０００８、段落０００９、段落００１０、または、段落００１１に記載の方法で作成された前記グラフ形式データを使用した、コンピューターにより実行される方法であって、第一のデータストア内の第一のテーブルの第一のフィールドに対するクエリーを受信するステップと、前記グラフ形式データに基づいて前記第一のフィールドに類似する第二のフィールドを識別するステップと、前記第二のフィールドと前記第二のフィールドを含む第二のテーブルと前記第二のテーブルを含む第二のデータストアとのいずれかひとつ以上を表示するステップとを含む方法を提供することで前記課題に対応する。

また、本願発明は、段落０００８、段落０００９、段落００１０、または、段落００１１に記載の方法で作成された前記グラフ形式データを使用した、コンピューターにより実行される方法であって、第一のデータストアに関する情報を表示するステップと、前記第一のデータストア内の第一のテーブルの第一のフィールドに対するクエリーを受信するステップと、前記グラフ形式データに基づいて前記第一のフィールドに類似する第二のフィールドを識別するステップと、前記第二のフィールドを含む第二のデータストアに関する情報を表示するステップと、前記クエリーに応じて前記第一のデータストアに関する情報の表示と前記第二のデータストアに関する情報の表示とを並列的に更新するステップとを含む方法。

また、本願発明は、段落０００８、段落０００９、段落００１０、または、段落００１１に記載の方法で作成された前記グラフ形式データを使用したコンピューターにより実行される方法であって、第一のデータストア内の第一のテーブルの第一のフィールドに対するクエリーを受信するステップと、前記グラフ形式データに基づいて前記第一のフィールドに類似する第二のフィールドを識別するステップと、前記第一のデータストアに対する前記クエリーの結果と、前記第二のフィールドを含む第二のテーブルを含む第二のデータストアに対する前記クエリーの結果とを組み合わせて同一画面上に表示するステップとを含む方法を提供することで前記課題に対応する。

また、本願発明は、段落０００８、段落０００９、段落００１０、または、段落００１１に記載の方法で作成された前記転置インデックスを使用したコンピューターにより実行される方法であって、第一のデータストアに関する情報を表示するステップと、
前記第一のデータストア内の第一のテーブルの第一のフィールドに対するクエリーを受信するステップと、前記グラフ形式データに基づいて前記第一のフィールドに類似する第二のフィールドを識別するステップと、前記第二のフィールドを含む第二のデータストアに関する情報を表示するステップと、前記クエリーに応じて前記第一のデータストアに関する情報の表示と前記第二のデータストアに関する情報の表示とを並列的に更新するステップとを含む方法を提供することで前記課題に対応する。

設計の異なる複数のデータソース間を横断してデータ分析を行なうためのフィールド間の関連づけを効率的に行なう方法、プログラム、および、システムが提供される。

エンタープライズ環境における多様なデータソースの例を表わす図である。 本願発明に係る実施例のデータ管理分析装置によって実行される、エンタープライズ・データ・グラフ作成のプロセスを表わす図である。 本願発明に係るテーブルのフィールド間の類似性を判断するアルゴリズムの第一の例である。 本願発明に係るテーブルのフィールド間の類似性を判断するアルゴリズムの第二の例である。 本願発明に係るエンタープライズ・データ・グラフの例の模式的表現図である。 本願発明に係る実施例におけるエンタープライズ・データ・グラフの画面表示例を表わす図である。 本願発明に係る実施例のデータ管理分析装置によって実行される、エンタープライズ・データ・グラフを使用したクエリーの第一の実施例のプロセスを表わす図である。 本願発明に係る実施例のデータ管理分析装置によって実行される、エンタープライズ・データ・グラフを使用したクエリーの第二の実施例のプロセスを表わす図である。 本願発明に係る実施例のデータ管理分析装置によって実行される、エンタープライズ・データ・グラフを使用したクエリーの第三の実施例のプロセスを表わす図である。 本願発明に係る実施例のデータ管理分析装置によって実行される、エンタープライズ・データ・グラフを使用したクエリーの第四の実施例のプロセスを表わす図である。 本願発明に係るデータ管理分析装置の実施例の機能的概略を表わす図である。 本願発明に係る実施例での使用に適したコンピューター・デバイスを含むコンピューティング環境の例を示す図である。

発明の詳細な説明

以下に図を用いて本願発明に係る実施例を説明する。明確化のために詳細は省略されている。図はすべて例示である。

図１に、エンタープライズ環境（１００）における多様なデータソースの例を示す。エンタープライズ環境（１００）で使用されるデータは多様なタイプのデータソース（１０５−１３５）から提供される。データソースのタイプの一つに検索エンジン（１０５）がある。検索エンジン（１０５）（たとえば、SOLRやELASTICSEARCH）は、トークナイザーやn-グラムによって分割された文字列を用いた高速検索のための転置インデックスを使用しており、テキストデータの保存や検索に有用である。転置インデックスは、複数の文書（１０７）にマップされた用語やキーワードを保存する。各文書は、一つ以上の属性値を含む一つのレコードに対応してよい。各レコードのフィールドの一部には検索の効率化のためにインデックスが付されていてよい。

他のデータソースのタイプとしてリレーショナル・データベース（リレーショナル・データベース管理システム（RDBMS）とも呼ばれる）（１１０）がある。リレーショナル・データベース（１１０）はデータをテーブル（１１３）に保存し、各テーブルはシステム中のエンティティを表現し、特定のフィールド（アトリビュートとも呼ばれる）がエンティティ間の関係を表わす。関係は、1対1、1対多、または、多対多であってよい。RDBMSは構造化照会言語（SQL）により照会することができ、構造化データの保存と照会のための堅牢で成熟したメカニズムを提供する。RDBMSは、ディスクからの効率的な読み取りとリレーショナル・データベース（１１０）へのデータ挿入のために、典型的にはBツリーのデータ構造を使用する。Bツリーは、対数時間（log N）で検索、挿入、削除が行なえるようデータをソートして維持するデータ構造である。

他のデータソースのタイプとしてカラムナー・データベース（１１５）がある。カラムナー・データベース（１１５）は、リレーショナル・データベース（１１０）と類似しているが、データを行指向の構造ではなく、カラム（列）（１１８）指向で保存する点に特徴がある。カラムナー・データベース（１１５）では、多数の行に少数のカラム（１１８）を有するデータの効率的な検索処理が可能である。多くの分析型照会では、一部のカラム（１１８）に対して集計処理を行なうことが必要であり、このような場合に、カラムナー・データベース（１１５）は保存と検索の効率性の点で有利である。カラム指向の保存では、特定のカラム（１１８）を読むためのディスク読み取り回数が少なくてすむためである。AMAZON REDSHIFTはカラムナー・データベース（１１５）の一例であり、APACHE PARQUET はカラム指向ファイル形式の一例である。

他のデータソースのタイプとしてキー・バリュー・データベース（キー・バリュー・ストアとも呼ばれる）（１２０）がある。キー・バリュー・ストア（１２０）は、連想アレイ（１２３）を保管、検索、管理するために設計されたデータ保管方式を使用する。連想アレイ（１２３）は、一般的にはディクショナリーまたはハッシュと呼ばれるデータ構造である。キー・バリュー・ストア（１２０）（たとえば、RIAK、REDIS、MEMCACHE)では、キーに基づいて高速なデータの検索が可能である。キー・バリュー・ストア（１２０）は、ディスクまたはメモリー上のマップデータ構造として実装されることもある。キー・バリュー・ストア（１２０）はシリアライザビリティや結果整合性に基づく整合性モデルに従うことができる。キー・バリュー・ストア（１２０）へのキーによるアクセスはO(1)のオーダー（定数）の複雑性で実行できる。

他のタイプのデータソースのタイプとしてウェブ・サービス（１２５）がある。ウェブ・サービス（１２５）は、エンタープライズ環境（１００）内外の多様なデータ・システムに対する共通の統合インターフェースとして機能する。たとえば、ほとんどのソーシャル・メディアのデータへのアクセスは、REST（Representational State Transfer）API（アプリケーション・プログラミング・インターフェース）を経由して行なわれる。外部のクラウドベースのアプリケーション（１６０）（Salesforce.com、Google Analyticsなど）もREST API経由でアクセス可能である。ウェブ・サービス（１２５）は、サービスプロバイダが格納したデータに対するリアルタイムの要求−応答型アクセスを実現する。

他のタイプのデータソースのタイプとして、エンタープライズ環境内の共有ストレージに保管されているファイルシステムがある。ファイルシステムの中には、CSV/Excelなどのような構造化されたファイルデータに加えて、提案書、設計書などの非構造のデータも多く存在する。ファイルが保管されるストレージは、一般的な共有フォルダに加えて他の文書管理システム内に存在でもよい。

他のタイプのデータソースのタイプとして、リアルタイムで生成または受信されたライブデータを提供するライブ・ストリーミング・データソース（１３０）がある。ライブデータは、ソケット（KinesisやKafkaなど）からのリアルタイム・ストリームから提供されることが多い。ストリーム処理はラムダ・アーキテクチャ（バッチ処理とリアルタイム対話型処理）の二重の目的を果たすことができる。後者では、遅延時間の要件が1秒未満であることもある。ストリーム・イベントが欠落した場合の再処理が行なわれるケースもある。

他のタイプのデータソースのタイプとして「ビッグデータ」（１０３）がある。ビッグデータのデータソースは、Hadoopや Sparkなどのクラスター化された環境に大量の（TB（テラバイト）単位以上）のデータを保存する。典型的にはビッグデータはSQL的な照会言語を提供する。リアルタイムモデル（たとえば、SPARKSQLやImpala）または非同期モデル（たとえば、HIVE）が採用されることもある。

他のタイプのデータソースのタイプにデータマート（１０４）がある。データマートは、オンライン分析処理（OLAP）または分析サービス（たとえば、SQL Server Analysis Services（SSAS））の分析用キューブであることが多い。データマート（１４０）を照会するために分析クエリー（たとえば、SQLベース）が発行されることがある。これらの分析クエリーは、事前集計済のデータであっても、洗浄済のデータであってもよく、様々なレポートのニーズに合わせて使用される。

他のタイプのデータソースのタイプに、ビジネス・オブジェクト層（１４５）がある。ビジネス・オブジェクト（たとえば、SAP、Infomatica）は、ビジネス・ユーザーがビジネスインテリジェンスのデータを閲覧、分類、分析することを可能にするフロントエンド・アプリケーションであることが多い。これらのフロントエンド・アプリケーション層が、特定のAPIを使用して直接照会されてもよい。

複数のタイプのデータソース（１０５−１４５）を、有線接続や無線接続のネットワーク（１５０）を介して互いに通信可能に接続してもよい。さらに、データ管理分析装置（１５５）をネットワーク（１５０）に接続してもよい。データ管理分析装置（１５５）は、コンピューター（たとえば、ラップトップまたはデスクトップ）、モバイル・デバイス（たとえば、スマートフォン、ウェアラブル・デバイス（たとえば、スマートウォッチ）、および、サーバー・コンピューターであってよいが、これらに限定されない。データ管理分析装置（１５５）は、末尾の図９に示すようなコンピューティング環境（９００）を有していてもよい。

上記の課題に対応するために、データ管理分析装置（１５５）は、以降に示すデータ分析のためのプロセスを実行することができる。実施例は、主に、リレーショナル・データベースのデータソースを例に使用しているが、他のタイプのデータソースにも適用可能である。

図２に、データ管理分析装置（１５５）が実行する、異なるデータソース間でフィールドの類似判定を行ない、エンタープライズ・データ・グラフを生成するプロセスの例（２００）示す。ここで、エンタープライズ・データ・グラフとは、複数のデータソース間の関係、ひとつ以上のデータソース内の複数のデータモデル間の関係、または、ひとつ以上のデータソースに保管されたエンティティ間の関連性を表現したグラフである。以降の例では、エンティティ間の関係を表わすエンタープライズ・データ・グラフを説明するが、同様の考え方はデータソースやデータモデル間の関係に対しても適用される。なお、エンティティとは、データベース（データソース）により表現される現実世界の物のことを指し、リレーショナル・データベースではテーブルまたはビュー（仮想的テーブル）に相当する（以下の説明では、エンティティとテーブルは同義として扱い、テーブルにはビューを含むものとする）。また、フィールドとはテーブル中の列（カラム）のことを指す。

（２０５）複数のデータソースの各データソース中の各テーブルの文字列形式フィールドから単語を抽出するためのヒューリスティック・インデックスを準備する。ここで、ヒューリスティクス・インデックスとは、データソース中のテーブルの文字列形式フィールドに含まれるテキスト中の意味のある単語を抽出し、単語がどのデータソースのどのテーブルのどのフィールドにどの程度の頻度で存在するかを指し示すためのインデックスであり、Luceneなどの検索エンジンが提供する転置インデックス機能を使用して実装することができる。

（２１０）次に、類似性判定アルゴリズムにより、ヒューリスティクス・インデックスに格納された文字列形式フィールド間の類似性を判定する。具体的アルゴリズムの実施例のうちの２種類を以下に説明する。

図３に類似性判定アルゴリズムの第一の例を示す。この例では、フィールドに含まれる文字列の類似性で関連性を判定する。完全な一致ではなく、部分一致やトークナイズによる揺らぎなどを考慮した一致判定を行なう点に特色がある。たとえば、データソースによって同じ用語に対する表現の相違（たとえば、「車外装置」と「車外用装置」、「株式会社特許」と「（株）特許」）があっても、類似するフィールドを発見できる点に優位性がある。アルゴリズムの第一の例は以下のステップから成る。（１）各テ-ブルの文字列型フィールドを識別し、フィールド毎に保持される値を全て取得する。（２）取得した値集合に対してDISTINCT演算を適用し、重複除去を行なう（値の「件数」ではなく「種類」に着目した分析を行なう）。（３）重複除去された値集合を、形態素解析が可能な検索エンジン（たとえば、Apache Lucene / Solr） にフィードする。文字列に対して形態素解析器によりトークン分解、または n-gram 処理よりシーケンス分割を施す。文字列をどのように分割するかは、ユーザーのニーズに応じて検索エンジン側のスキーマを変更させることで設定することができる。検索エンジンのインデックス構造体には、Bag of Wordsを溜め込んだ索引が形成される。フィードした一件の文字列が、１ドキュメントに相当する。（４）フィールド間のコサイン類似度を求める。（５）コサイン類似度は0から1の間の実数値であるが、算出値と人間が感じる類似感には非線形な関係がある為、ロジスティック関数を適用する。0.5 近辺の変動鋭敏性を高め、0.0近辺と1.0近辺の鋭敏性を緩めることが好ましい。ロジスティック関数のパラメータは、設定ファイルで変更可能とすることが好ましい。（６）算出したフィールド間の類似度値に対して、所定の閾値に基づいてHigh /
Medium / Low / None 等の属性を設定することが好ましい。

図４に類似性判定アルゴリズムの第二の例を示す。この例では、フィールドに文字列が含まれている度合で関連性を判定する。曖昧な揺らぎの吸収は行わず、完全一致での判定を行う方式であり、以下のステップから成る。（１）各データモデルから文字列型フィールドを識別し、フィールド毎に保持される値を全て取得する。（２）取得した値集合に対してDISTINCT演算を適用し、重複除去を行なう（値の「件数」ではなく「種類」に着目する）。（３）重複除去された値集合を、1列×n行のテンポラリテーブルとして保持する。テンポラリー・テーブルにはインメモリDBMSを使用してよい。（４）上記ステップ3で生成された1列×n行のテンポラリテーブル群において、相互に結合演算（自然結合）を行なう。この結果セットの行数と元の２テーブルの各レコード数を比較する。（５）比較方法として、Dice係数、Simpson係数、Jaccard係数の３手法を適用し、各々の類似度を求める。３つの値は、重み付けした上で合成し、0から1の範囲を値域とする実数値（類似度）を算出する。（６）全テーブルの組み合わせで類似度が算出できた段階で、1列×n行のテンポラリテーブル群を全て破棄することが好ましい。（７）算出したフィールド間の類似度値に対して所定の閾値に基づいてHigh / Medium / Low / None 等の属性を設定することが好ましい。

（２１５）さらに、各データストアの各テーブルの各フィールド（文字列フィールドに限られない）の属性（たとえば、濃度（cardinality）、個別値数 (NDV)、ヒストグラムの範囲、ヌル値の件数、非ヌル値の件数）を収集し、保存してもよい。

（２２０）生成されたヒューリックス・インデックスと収集されたフィールド属性のいずれか、または、その両方に基づいて、異なるデータストア内の各テーブルの類似性を判定する。ヒューリックス・インデックスにより判定された類似度とフィールド属性により判定された類似度を重み付け平均し、所定の閾値を超えた場合に類似すると判定してもよい。ヒューリックス・インデックスにより判定された類似度が所定の閾値を超えた場合には、フィールド属性により判定された類似度にかかわらず、類似すると判定してよい。フィールド属性により判定された類似度が所定の閾値を超えた場合には、ヒューリックス・インデックスにより判定された類似度にかかわらず、類似すると判定してよい。ヒューリックス・インデックスにより判定された類似度が所定の閾値以下の場合には、フィールド属性により判定された類似度にかかわらず、類似しないと判定してよい。フィールド属性により判定された類似度が所定の閾値以下の場合には、ヒューリックス・インデックスにより判定された類似度にかかわらず、類似しないと判定してよい。このような判定の方法や所定の閾値はユーザーがパラメーターとして設定したり、スクリプトとして記述したりできるようになっていることが好ましい。

（２２５）判定された各フィールド間の類似性に基づいて、テーブル間の類似性を判定する。類似すると判定されたフィールドを多く含むテーブルは類似性が強いとして扱うことが好ましい。

（２３０）判定されたテーブル間の類似性に基づいてエンタープライズ・データ・グラフを生成する。図５に本願発明に係るエンタープライズ・データ・グラフの例の模式的表現を示す。エンタープライズ・データ・グラフのノードは、異なるデータソースに属するが、類似すると判定されたフィールドを含むテーブル（エンティティ）であり、エッジがテーブル間の類似性を表現する。類似するフィールドの数やその類似度に応じてテーブル間の類似度を設定してもよい。この例では各ノードはテーブルだが、同様の考え方でデータソースやデータモデル間の類似関係を表現してもよい。

（２３５）生成されたエンタープライズ・データ・グラフは、ユーザーのデータ間の関係の理解を高めたり、データソースを横断したクエリーを支援したりするために、画面上にグラフィック形式で表示することが好ましい。

図６に本願発明に係る実施例におけるエンタープライズ・データ・グラフ（６００）の画面表示例を示す。図示したように、エンタープライズ・データ・グラフ（６００）は、データストア（データ・リポジトリ）間の関連のマッピング処理の開始点となる開始データストア（６０５）（ここでは、"Complaints"）の領域（６１０）を含んでいてよい。この領域（６１０）は開始データストア（６０５）に関する情報（たとえば、フィールドの数、および、フィールドやテーブルの内容を確認するためのリンク（６０７））を含んでいてもよい。この開始データストア（６０５）が、ユーザーから受信したクエリーに基づいて自動的に選択されてもよい。

また、エンタープライズ・データ・グラフ（６００）は、図２のプロセスによって、開始データストア（６０５）類似すると判定されたと他の複数のデータストア（６２０−６５５）との間の類似関係を図示する領域（６１５）も含んでいてよい。図では、開始データストア（６０５）（この例では、"Complaints"）は、他の8つのデータストア、すなわち、"Supplier"（６２０）、"Blue"（６２５）、"Sales"（６３０）、"Recalls"（６３５）、"Investigations"（６４０）、"Parts"（６４５）、"Reviews"（６５０）、および、"BOM"（６５５）と類似すると判定されている。これらの複数データストアのテクノロジーや設計（データモデル）は同一であるとは限らず、格納されたデータの内容も完全に整合性が取れているとは限らないが、前述のフィールド間の類似性判定アルゴリズムにより、テーブル（エンティティ）やデータスストア（データ・リポジトリ）間の関係をグラフィカルに表現し、ユーザーのデータ分析作業を支援できる。

さらに、エンタープライズ・データ・グラフ（６００）は、ユーザーが選択したデータストア（この例では、"Supplier"（６２０）を選択したものとする）に類似するフィールドを有すると判定されたテーブルを含む、データストア（６２５−６６０）を示す領域（６６５）も含んでいてもよい。

これらのデータストア（６２５−６６０）のいくつかは類似するフィールドを開始データリポジトリ（６０５）にも含んでいると判定されている。たとえば、"Blue"（６２５）、"Sales"（６３０）、"Recalls"（６３５）、"Investigations"（６４０）、"Investigations"（６４５）、および、”Reviews”（６５０）は、いずれも領域（６１５）と領域（６６５）の両方に示されている。

しかし、領域（６６５）に示されたデータストアのいくつかが領域（６１５）に示されていないこともある。この場合には、これらのデータストアが、開始データストア（６０５）内のテーブル内のフィールドと類似するフィールドを含まないことを意味する。さらに、領域（８１５）に示されているデータストアのいくつかが領域（６６５）に示されていないこともあり、この場合には、これらのデータストアがユーザー選択データストア（６２０）内のテーブル内のフィールドと類似するフィールドを含まないことを意味する。たとえば、”Call logs”（６６０）は領域（６６５）にのみ示されているので、開始データストア（６０５）内のテーブルのフィールドに類似するフィールドを含まない。同様に、"BOM""(６５５）は領域（６１５）にのみ図示されているので、ユーザー選択データストア（６２０）内のテーブルのフィールドに類似するフィールドを含まない。

エンタープライズ・データ・グラフ（６００）は、開始データストア（６０５）に関する情報（たとえば、フィールドの数）を提供する情報領域（６７０）と開始データストア（６０５）内のフィールドを表示するためのリンク（８７２）とのいずれかひとつ以上を含んでいてよい。

さらに、エンタープライズ・データ・グラフ（６００）は、ユーザー選択データストア（６２０）に関する情報（たとえば、フィールドの数）を提供する情報領域（６７５）とフィールドを表示するためのリンク（６７７）を含んでいてよい。

さらに、エンタープライズ・データ・グラフ（６００）は、開始データストア（６０５）とユーザー選択データストア（６２０）との関係に関する情報を提供する領域（６８０）を含むこともできる。この領域（６８０）には、ユーザー選択データストア（６２０）内のフィールドと類似すると判定された開始データストア（６０５）内のフィールドのリスト（６８５）が含まれていてよい。また、この領域（６８０）はユーザー選択データストア（６２０）内のフィールドと類似すると判定された開始データストア（６０５）内のフィールドを表示するためのリンク（６９０）を含んでいてよい。

以降では、図2のプロセスにより生成されたエンタープライズ・データ・グラフとヒューリスティクス・インデックスのいずれか、または、その両方を使用した様々なクエリー（データ照会要求）の様々な実施例を説明する。

図７に、出願のデータ管理分析装置（１５５）の実施例によって実行され得る、エンタープライズ・データ・グラフを使用したクエリーの第一の実施例（ここでは、データ・チェーンと呼ぶ）のプロセス（７００）を示す。

（７０５）ユーザーからデータストア内の特定のテーブルのフィールドに対するクエリーを受信する。

（７１０）エンタープライズ・データ・グラフを使用して、クエリーの対象となったテーブルと類似する他のテーブル内のフィールドを識別する。

（７１５）オプションとして、ヒューリスティック・インデックスに対して再度クエリーを行ない、ユーザーのクエリー対象であるフィールドの類似フィールドを識別してユーザーに表示してもよい。

（７２０）類似するフィールド、および、そのフィールドを含むテーブルを識別すると、ユーザーに対して確認メッセージを表示し、ユーザー入力を受け取って、データストアA以外のデータストアを表示する画面に画面表示を遷移する。この際に複数のテーブルを表示してユーザーにひとつを選択させてもよい。

（７２５）７１０または７１５で識別されたフィールドを使用して、ユーザーが対応するデータストアを照会し、結果を表示することができるようにする。

この実施例は、たとえば、コールセンターで問い合わせがあった製品のシリアル番号を用いて、異なるデータストアに保存された出荷明細や生産実績のデータをたどり、分析をする場合等に有効である。この際に、通常のRDBMSのテーブル間リレーションシップのように完全にその単語が一致しなくとも、部分一致するだけで求めるデータストアやテーブルに到達することができる点に優位性がある。

図８に、本出願の実施例によるデータ管理分析装置（１５５）によって実行され得る、エンタープライズ・データ・グラフを使用したクエリーの第二の実施例（フェデレーテッド・クエリーまたは連邦型クエリーと呼ばれる）のプロセス（８００）を示す。

（８０５）複数のデータストアのデータを表現する画面をユーザーに表示し、ユーザーが、これらのデータストアからひとつを選択してクエリーを入力できるようにする。

（８１０）データストアの1つに対するクエリーを受信する。

（８１５）エンタープライズ・データ・グラフを使用して、８１０において受信されたクエリーの対象テーブルと類似する他のデータストア中のテーブルおよびそれが含むフィールドを識別する。

（８２０）オプションとして、ヒューリスティック・インデックスに対して再度クエリーを行ない、ユーザーのクエリーに関連するフィールドを識別して、ユーザーに表示してもよい。

（８２５）識別されたフィールドおよびテーブルに基づいて、各データストアに対して並列的にクエリーを発行する。

（８３０）
並列的なクエリーに応答して、各データストアに対応する画面上の表示を更新する。たとえば、ユーザーがあるデータストアに対して照会期間の絞り込みを行なうクエリーを送信すると、それ以外のデータストアに対しても同等のクエリーが発行され、それぞれの画面表示を変更することができ、データ分析を行なうユーザーの利便性を向上できる。

図９に、本出願の実施例によるデータ管理分析装置（１５５）によって実行され得る、エンタープライズ・データ・グラフを使用したクエリーの第三の実施例（リアルタイム・データ・フュージョン、仮想統合、または、コンポジット・データモデルと呼ぶ）のプロセス（９００）を示す。

（９０５）データストア内の特定のテーブルに対するクエリーを受信する。

（９１０）エンタープライズ・データ・グラフに基づいて、他のデータストア中のテーブルの類似フィールドを識別する。

（９１５）オプションとして、類似と識別されたフィールドの選択肢をユーザーに表示し、ユーザーに選択させてもよい。

（９２０）９０５で要求されたフィールドと９１０で識別されたフィールドとを組み合わせて、クエリーの結果を生成する。この実施例により、物理的に異なる２つ以上のデータストアを、単一のデータストアのように取り扱うことができる。たとえば、ある販売データが地域別に別のデータベースやテーブルに格納したいた場合に、物理統合なしにあたかも単独のテーブルとして分析をおこなうことができ、ユーザーの利便性を向上できる。

図１０に、本発明の実施例によるデータ管理および分析装置（１５５）によって実行され得る、ヒューリスティクス・インデックスを使用したクエリーの第四の実施例（Mμgenサーチと呼ぶ）のプロセス（１０００）を示す。

（１００５）ユーザーが入力した検索の対象となる文字列（キーワード）を受信する。この際に、ヒューリスティクス・インデックスを検索して、オートコンプリート（サジェスチョン）を行なってもよい。

（１０１０）受信したキーワードに基づいて、ヒューリスティクス・インデックスを検索して、そのキーワードを含むフィールドを含むテーブル、および、そのテーブルを含むリストを生成しユーザーに表示する。

（１０１５）リストからテーブルやフィールドを選択するユーザーからの入力を受信する。

（１０２０）選択されたテーブルやフィールドに対応する画面（ダッシュボード）を表示し、ユーザーからの照会要求を受信し、結果を表示する。この実施例により、多種多様なデータストアを網羅的に検索し、特定のキーワードに関連する可能性があるデータストアを発見できる。たとえば、車のモデル名をキーワードとして入力し、関連するリコール関連情報、サプライチェーン関連情報、生産システム関連情報を横断的に検索することで、その車種のクレーム対策を迅速に行なうことができる。

上記に述べた実施例以外にも、エンタープライズ・データ・グラフおよびヒューリスティクス・インデックスを使用して、複数のデータストアを横断した様々なクエリーに対応可能である。たとえば、現在の検索結果の特定のフィールドに含まれるすべて（または、一部）の値を用いて、他のデータストアに対して横断的に検索することができる。本願発明に係る方法では、テーブル間の関係がヒューリスティクス・インデックス、および、エンタープライズ・データ・グラフとして抽出されているため、データストアのアクセスにシステムの多大な負荷を要することなく、データストアの数が多数にわたる大規模なシステムにおいても効率的なデータ照会・分析が可能となる。

図１１に、データ管理分析装置（１５５）の実施例の機能概略図を示し、図２から図１０に示したプロセスやクエリーの実行方式の概要を示す。データ管理分析デバイス（１５５）は、ユーザーからクエリーパラメーター（Params）を受信し、クエリー結果をユーザーに提示するユーザーインターフェース層（１１０５）を含んでよい。ユーザーインターフェース層（１１０５）はクエリーを受信し、クエリー・エンジン（１１１０）に送信する。クエリー・エンジン（１１１０）は、クエリー・トランスフォーマ（１１２０）、クエリー・パイプライン（１１２５）、クライ・エグゼキュータ（１１５５）、リザルト・パイプライン（１１６０）、および、リザルト・コンバイナ（１１６５）を含む。

クエリー・トランスフォーマー（１１２０）は、クエリーエンジン（１１１０）内で、様々なフォーム要素を介してクエリーをユーザーインターフェース層（１１０５）から取得し、クエリー・トランスフォーマ（１１２０）に渡すために、汎用サーチ・オブジェクト（１１１５）に変換する。サーチ・オブジェクト（１１１５）はインターナル・メタデータ（１１３０）から検索したクエリーに関するすべてのメタデータ（データモデル、フィールド、データリポジトリ、フィルター）を含む。フェデレーテッド・サーチにおけるクエリー・トランスフォーマー（１１２０）の役割は、エンタープライズ・データ・グラフ（１１３５）を探索し、類似するフィールドを識別することである。クエリー・トランスフォーマー（１１２０）は、エンタープライズ・データ・グラフ（１１３５）に基づいてサーチ・オブジェクト（１１１５）を変換する。次に、サーチ・オブジェクト（１１１５）がクエリー・パイプライン（１１２５）に供給され、クエリー・パイプライン（１１２５）が実行すべきクエリーの順序を決定し、セキュリティ（１１７５）などの変換をサーチ・オブジェクト（１１１５）に追加する。クエリーの実行前に、クエリー・エグゼキュータ（１１５５）が、クエリーの結果がクエリー結果キャッシュ（１１５０）に存在するかどうかをチェックしてもよい。クエリーが1つのデータソースに対するものである場合には、クエリー・エグゼキュータ（１１５５）が直接実行してよい。

複合クエリー（たとえば、複数のデータストア（１１４０、１１４５）に対するクエリー）の場合、クエリー実行フロー全体が、対応する統計と共にインターナル・メタデータ（１１３０）に記録されてもよい。たとえば、クエリー変換の時間、物理的クエリーの実行時間、全ネットワーク転送の転送時間、ワークフローが実行されたクエリー・テンプレート/フォーマットなどの統計情報を記録してよい。

クエリー・エグゼキュータ（１１５５）は、サーチ・オブジェクト（１１１５）を取り込み、ネイティブ・データ・エンジンのAPIまたは言語を使用して実行可能なクエリーに変換する。クエリー実行の効率性向上のために可能な限りプッシュダウンを使用してよい。次いで、クエリー・エグゼキュータ（１１５５）は、クエリー結果を含むデータ構造体をリザルト・パイプライン（１１６０）に返す。

クエリー・エグゼキュータ（１１５５）は、結果のシーケンスを調整するリザルト・パイプライン（１１６０）として複数のクエリー結果を返してよい。独自のロジックに基づく変換をこのレイヤーで実行してもよい。

複合クエリーがそれぞれ異なる物理データソースに対する複数のクエリーを呼び出す場合、リザルト・コンバイナ（１１６５）を呼び出して、クエリーの各結合点で中間結果をジョインまたは組み合わせてもよい。たとえば、リザルト・コンバイナ（１１６５）は、中間結果を受け入れ、最良のジョイン戦略を決定し、次いで両方の中間データセットのジョイン結果を戻してもよい。データセット間の「ビッグデータ」級のジョインの場合、リザルト・コンバイナ（７６５）は、クラスター化されたインメモリエンジン（たとえば、APACHE SPARK）を使用して計算を実行することによって、分散ジョイン戦略を使用することができる。このようなクエリーは、リアルタイムで実行されてもよく、クラスター化環境での処理にネットワークオーバーヘッド以上のオーバーヘッドが含まれる場合、非同期的に実行されてもよい。

中間データセット量が小さい場合、メモリ内SQLエンジンを使用してジョインを実行することができる。一部の実施例では、RAMディスクテーブルへの一括挿入した後にSQLを実行することで、リアルタイム実行のための十分な高速性を実現可能である。

一部の実施例では、ジョインは、各中間結果をフェッチし、次に適切なジョインアルゴリズムを適用してリザルト・オブジェクト（１１７０）を生成することによって、リザルト・ジョイナー（１１６５）で2つのデータソースのクエリー結果をユーザー・インターフェース層（１１０５）に戻してもよい。リザルト・コンバイナ（１１６５）において、各中間結果を取得して適切なジョイン・アルゴリズムを適用して、ユーザー・インターフェース層（１１０５）を通じて返すための結果オブジェクト（１１７０）を生成することで、ジョインが、２つのデータソースをまたがって実行されてよい。

結果のマージには、多くのジョイン戦略を使用することができる。一部の実施例では、インメモリSQLエンジンを使用してよい。たとえば、中間データセットを、RAMディスク上のPOSTGRESQLまたはMYSQLテーブル（同じネットワーク上の別のサーバー上に存在していてもよい）に書き込んでよい。その後、SQLジョインのクエリー（計算式と共に使用されてもよい）がデータベース上で実行され、最終的な結果セットが生成されてよい。最終的なリザルト・セットは、リザルト・ジョイナー（１１６５）に送り返されてもよい。同様に、他のインメモリSQLエンジンの（たとえば、MemSQL）も使用してよい。インメモリサーバーを実行するインフラストラクチャは、大容量のメモリを備えていてよい。同様に、他のカラムナー・データベースも使用して良い。コストがかかる複雑なクエリや対象となるデータソースの性能が悪いときに、クエリパフォーマンスに優れたカラムナー・データベースに書き込んで、ユーザーに快適なパフォーマンスを提供する。

他の実施例では、ネイティブなデータソース上で可能な限り多くの処理を行なうことが望ましいことがある。サーチ、比較、ローカル・ジョイン、ソート、集計、および、グルーピングを下位のデータソースにプッシュダウンすることで、データソースの機能を活用でき、ネットワークを介して転送され、インメモリのエンジンで処理される中間データの量を制限できる。

他の実施例として、データのクエリー・キャッシングを使用してもよい。たとえば、キャッシュ・クラスター（たとえば、REDIS、MEMCACHED）をクエリーごとに結果を保管するように構成してもよい。どのストアに対してクエリーを実行する前にも、キャッシュ上に結果がないかをチェックしてよい。結果がキャッシュ上にない場合のみに、データソースへのアクセスが行なわれる。レイテンシーが大きいソースに対して頻繁にクエリーが実行される場合には性能が向上可能である。自身ではキャッシュ機能を持たないエンジン（たとえば、IMPALA）や複合クエリー（たとえば、クエリーが複数の物理的クエリーに分割され、結果がインメモリのSQLエンジンで併合される場合）では、性能向上が顕著である可能性がある。

他の実施例では、同時並行処理が実行されてもよい。たとえば、クエリーが多くのデータソースにまたがる場合、並行処理によってクエリー実行時間が短縮される可能性がある。さらに、一部の実施例において、クエリー実行プラン決定中に、相互に排他的なクエリーを識別して、並列スレッドで実行してもよい。

他の実施例では、分散処理が実行されてもよい。たとえば、HadoopプラットフォームまたはSparkプラットフォーム上の特定のエンジン（たとえば、HIVE、IMPALA）を用いてクエリーを実行する間に、ネイティブデータソースの分散処理能力を本質的に使用してもよい。しかし、いくつかの実装例では、SparkやHadoopのようなクラスター化エンジン上の大規模な中間セットを分散ジョインする際には、他のエコシステムツールを必要とすることがある。

さらに、非リアルタイム最適クエリープラン生成が使用されてもよい。たとえば、クエリー・エンジン（１１１０）は、クエリー実行ワークフロー内の各ステージの実行時間を記録することができる。このログには、特定のデータモデルのデータソースに対するクエリー処理と、ネットワーク転送およびデータマージが含まれてよい。このログは、その後のクエリー・ワークフローの実行のためにクエリープランをさらに最適化するためのデータとして有用である。最適な実行グラフの探索のオーバーヘッドを避けるために、この最適化プロセスは、最適な実行計画を決定し、内部メタデータ記憶装置（１１３０）に再使用のためにキャッシュするバックグラウンドプロセスとして実行してもよい。

（コンピューティング環境の例）
図１２に、特定の実施例の実装に適したコンピューティング・デバイス（１２０５）を含むコンピューティング環境（１２００）の例を示す。コンピューティング環境（１２００）中のコンピューティング・デバイス（１２０５）は一つ以上の処理ユニット、コア、または、プロセッサ（１２１０）、メモリ（１２１５）（たとえば、RAM、ROM等）、内部ストレージ（１２２０）（たとえば、磁気ディスク、光学ディスク、半導体ストレージ、有機ストレージ）、I/Oインターフェース（１２２５）を含んでいてよく、それらは、情報のやり取りのためにコミュニケーション機構またはバス（１２３０）上で接続されていてよく、コンピューティング・デバイス（１２０５）に埋め込まれていてもよい。

コンピューティング・デバイス（１２０５）は、入力ユーザー・インターフェース（１２３５）および出力デバイス・インターフェース（１２４０）と通信可能なように接続されていてよい。入力ユーザー・インターフェース（１２３５）および出力デバイス・インターフェース（１２４０）のいずれか、または、両方は有線であっても無線であってもよく、取り外し可能であってもよい。入力ユーザー・インターフェース（１２３５）は、物理的か仮想的か問わず、入力を提供できる任意の装置、コンポーネント、センサーを含む（たとえば、ボタン、タッチスクリーンインターフェース、キーボード、ポインター、カーソルコントロール、マイクロフォン、点字、モーションセンサー、光学リーダーなど）。出力デバイス・インターフェース（１２４０）は、ディスプレイ、テレビ、モニター、プリンター、スピーカー、点字等を含む。一部の実施例では、入力ユーザー・インターフェース（１２３５）と出力デバイス・インターフェース（１２４０）はコンピューティング・デバイス（１２０５）に埋め込まれているか、物理的に接続されていてもよい。他の実施例では、他のコンピューティング・デバイスがコンピューティング・デバイス（１２０５）の入力ユーザー・インターフェース（１２３５）と出力デバイス・インターフェース（１２４０）の機能を提供してもよい。

コンピューティング・デバイス（１２０５）は、（たとえば、タブレット、ノートブック、ラップトップ、パーソナルコンピュータ、携帯テレビ、ラジオなどの）モバイルデバイス、携帯性が高いデバイス（たとえば、スマートフォン、車両および他の機械のデバイス、人間および動物が携行するデバイスなど）、コンピューター（たとえば、デスクトップコンピューター、サーバーデバイス、他のコンピューター、情報キオスク、1つ以上のプロセッサが埋め込まれたテレビ、および/またはそれらに結合されたテレビ、ラジオなど）を含むが、これに限定されない。

コンピューティング・デバイス（１２０５）は、ひとつ以上の同種または異種のコンピューティング・デバイスを含む、任意の数のネットワーク構成要素、デバイス、およびシステムと通信するために、外部記憶装置（１２４５）およびネットワーク（１２５０）に（たとえば、I / Oインターフェース（１２２５）を介して）接続可能にされていてよい。コンピューティング・デバイス（１２０５）、または、任意の接続されたコンピューティング・デバイスは、サーバー、クライアント、シン・サーバー、一般的なマシン、特殊目的のマシン、または、他の名称で呼ばれるコンピューターとして機能し、サービスを提供したり、それらを参照したりすることができる。

I/Oインターフェース（１２２５）は、コンピューター環境900内の接続されたコンポーネント、デバイス、ネットワークの間で情報を通信するためのネットワークのための、任意の通信またはI / Oプロトコルまたは規格（たとえば、イーサネット（登録商標）、802.11x、ユニバーサルシステムバス、WiMAX、モデム、セルラネットワークプロトコルなど）を使用する有線や無線インターフェースを含むが、これに限定されない。ネットワーク（950）は、任意のネットワーク（たとえば、インターネット、ローカルエリアネットワーク、エリアネットワーク、電話ネットワーク、セルラネットワーク、衛星ネットワーク）またはそれらの組み合わせであってよい。

コンピューティング・デバイス（１２０５）は、一時媒体および非一時媒体を含むコンピューター使用可能またはコンピューター可読媒体を使用して使用・通信することができる。一時媒体には、伝送媒体（たとえば、金属ケーブル、光ファイバ）、信号、搬送波などが含まれる。非一時的媒体には、磁気媒体（たとえば、ディスクおよびテープ）、光媒体（たとえば、CD-ROM、デジタルビデオディスク、ブルーレイディスク）、半導体媒体（たとえば、RAM、ROM、フラッシュメモリ、ソリッドステートストレージ ）、および他の不揮発性記憶装置またはメモリを含む。

コンピューティング・デバイス（１２０５）は、いくつかのコンピューティング環境実施例において、技法、方法、アプリケーション、プロセス、またはコンピューター実行可能命令を実現するために使用することができる。コンピューター実行可能命令は、一時媒体から取り出して、非一時媒体上に記憶し、それから取り出すことができる。実行可能命令は、プログラミング、スクリプティング、および機械語（たとえば、C、C ++、C＃、Java、Visual Basic、Python、Perl、JavaScriptなど）のうちの1つ以上から成っていてよい。

プロセッサ（１２１０）は、ネイティブ環境または仮想環境において、任意のオペレーティングシステム（OS）（図示していない）の下で実行することができる。論理ユニット（１２５５）、API（アプリケーションプログラミングインターフェース）ユニット（１２６０）、入力ユニット（１２６５）、出力ユニット（１２７０）、ヒューリスティック・インデックス生成ユニット（１２７５）、類似性判定ユニット（１２８０）、エンタープライズ・データグラフ生成ユニット（１２８５）、分析グラフィクス・ユニット（１２９０）、および、ユニット間通信機構（１２９５）は、互いに通信するために、OSおよび他のアプリケーション（図示してない）と通信する。たとえば、ヒューリスティック・インデックス生成ユニット（１２７５）、類似性判定ユニット（１２８０）、エンタープライズ・データグラフ生成ユニット(１２８５)、および分析グラフィクス・ユニット（１２９０）は、図２から図図１０に示すひとつ以上の処理を実装することができる。記載されたユニットと要素は、設計、機能、構成、または実装において変更可能であり、説明の内容に限定されない。

いくつかの実施例では、APIユニット（１２６０）は、情報または実行命令を受信すると、1つ以上の他のユニット（たとえば、ヒューリスティック・インデックス生成ユニット（１２７５）、類似性判定ユニット（１２８０）、エンタープライズ・データグラフ生成ユニット（１２８５）、分析グラフィックス・ユニット（１２９０）、および、クエリーユニット（１２９７）と通信を行なってよい。たとえば、ヒューリスティック・インデックス生成ユニット（１２７５)を介してヒューリスティック・インデックスが生成されるときに、異なるエンティティ間の類似性を判定するために、ヒューリスティック・インデックスが類似性判定ユニット（１２８０）に提供されてもよい。さらに、エンタープライズ・データグラフ生成ユニット（１２８５）がエンタープライズ・データグラフを生成する際に、類似性判定ユニット（１２８０）が類似性データを提供してもよい。さらに、エンタープライズ・データ・グラフ生成ユニット（１２８５）が、分析グラフィクス（１２９０）に提供され、出力ユニット（１２７０）を用いて表示されるデータ分析グラフィックを生成してもよい。

一部の実施例では、論理ユニット（１２５５）が、ユニット間の情報フローを制御し、APIユニット（１２６０）、入力ユニット（１２６５）、出力ユニット（１２７０）、ヒューリスティック・インデックス生成ユニット（１２７５）、類似性判定ユニット（１２８０）、エンタープライズ・データグラフ生成ユニット（１２８５）、および、分析グラフィクスユニット（１２９０）を含む。たとえば、1つ以上プロセスのフローや実装を、論理ユニット（１２５５）によって単独で、またはAPIユニット（１２６０）と連携して制御することができる。クエリーユニット（１２９７）は、APIユニット（１２６０）、論理ユニット（１２５５）、および、類似性判定ユニット（９８０）と連携して、それぞれのデータリポジトリでクエリーを実行する。

いくつかの実施例について説明してきたが、これらは当業者に対して本願発明の主題を伝えるために提供されたものである。本願発明の主題は、説明された実施例に限定されることなく、様々な形態で実現され得ることに注意されたい。本願発明の主題は、ここで定義または説明された構成要素なしに実現することもでき、ここで説明されなかった別の構成要素と共に実現することもできる。本願請求の範囲により定義された本願発明の主題を逸脱することなく、これらの実施例を変更することは当業者にとって容易である。

Claims (8)

1. 複数のデータストア内のデータを分析する方法であって、
   前記複数のデータストア内のテーブル内の複数のフィールド内の文字列の集合から重複を排除するステップと、
   前記重複を排除した文字列を転置インデックスに保存するステップと、
   前記転置インデックスに保存された文字列間の類似性を判定するステップと、
   前記判定された文字列間の類似性に基づいて前記複数のフィールド間の類似性を判定するステップと、
   前記複数のフィールド間の類似性が高いと判定されたフィールドを含むテーブルをノードとして類似関係をエッジで表現したグラフ形式データを生成するステップとを
   含むコンピューターにより実行される方法。
2. 前記転置インデックスに保存された文字列間の類似性を判定するステップは、さらに、
   前記複数のフィールド内の文字列に形態素解析を適用して分割するステップと、
   前記文字列間のコサイン類似度を求めるステップと、
   前記コサイン類似度にロジステック関数を適用するステップとを
   含む請求項１に記載の方法。
3. 前記転置インデックスに保存された文字列間の類似性を判定するステップは、さらに、
   前記複数のフィールド内の文字列の集合を一時的テーブルに保存するステップと、
   前記テーブルに自然結合演算を適用するステップと、
   前記テーブル間の類似度を計算するステップとを
   含む請求項１に記載の方法。
4. さらに、前記複数のデータストア内のテーブル内の複数のフィールド内のデータの属性に基づいて前記フィールド間の類似性を判定するステップを含み、
   前記属性は、濃度、個別値の数、ヒストグラムの境界、ヌル値の数、または、非ヌル値の数のいずれかひとつ以上である
   請求項１、請求項２、または、請求項３に記載の方法。
5. 請求項１、請求項２、請求項３、または、請求項４に記載の方法で作成された前記グラフ形式データを使用した、コンピューターにより実行される方法であって、
   第一のデータストア内の第一のテーブルの第一のフィールドに対するクエリーを受信するステップと、
   前記グラフ形式データに基づいて前記第一のフィールドに類似する第二のフィールドを識別するステップと、
   前記第二のフィールドと前記第二のフィールドを含む第二のテーブルと前記第二のテーブルを含む第二のデータストアとのいずれかひとつ以上を表示するステップとを含む方法。
6. 請求項１、請求項２、請求項３、または、請求項４に記載の方法で作成された前記グラフ形式データを使用した、コンピューターにより実行される方法であって、
   第一のデータストアに関する情報を表示するステップと、
   前記第一のデータストア内の第一のテーブルの第一のフィールドに対するクエリーを受信するステップと、
   前記グラフ形式データに基づいて前記第一のフィールドに類似する第二のフィールドを識別するステップと、
   前記第二のフィールドを含む第二のデータストアに関する情報を表示するステップと、
   前記クエリーに応じて前記第一のデータストアに関する情報の表示と前記第二のデータストアに関する情報の表示とを並列的に更新するステップとを含む方法。
7. 請求項１、請求項２、請求項３、または、請求項４に記載の方法で作成された前記グラフ形式データを使用した、コンピューターにより実行される方法であって、
   第一のデータストア内の第一のテーブルの第一のフィールドに対するクエリーを受信するステップと、
   前記グラフ形式データに基づいて前記第一のフィールドに類似する第二のフィールドを識別するステップと、
   前記第一のデータストアに対する前記クエリーの結果と、前記第二のフィールドを含む第二のテーブルを含む第二のデータストアに対する前記クエリーの結果とを組み合わせて同一画面上に表示するステップとを含む方法。
8. 請求項１、請求項２、請求項３、または、請求項４に記載の方法で作成された前記転置インデックスを使用した、コンピューターにより実行される方法であって、
   ユーザーからのキーワードを受信するステップと、
   前記転置インデックスから前記キーワードを含むフィールドを含むテーブルを検索するステップと、
   前記フィールド、または、前記テーブルを表示するステップとを
   含むコンピューターにより実行される方法。

Images