JPWO2017170459A6 - 異種データソース混在環境におけるフィールド間の関係性の自動的発見のための方法、プログラム、および、システム - Google Patents
異種データソース混在環境におけるフィールド間の関係性の自動的発見のための方法、プログラム、および、システム Download PDFInfo
- Publication number
- JPWO2017170459A6 JPWO2017170459A6 JP2017523549A JP2017523549A JPWO2017170459A6 JP WO2017170459 A6 JPWO2017170459 A6 JP WO2017170459A6 JP 2017523549 A JP2017523549 A JP 2017523549A JP 2017523549 A JP2017523549 A JP 2017523549A JP WO2017170459 A6 JPWO2017170459 A6 JP WO2017170459A6
- Authority
- JP
- Japan
- Prior art keywords
- data
- field
- query
- similarity
- fields
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Abstract
設計の異なる複数のデータソース間を横断してデータ分析を行なうためのフィールド間の関連づけを効率的に行ない、多様な分析に対応する。
複数のデータストアのそれぞれのフィールドにインデックスを付与し、フィールド間の類似性を判定し、類似性が高いと判定されたフィールドをノードとするグラフ形式データ(エンタープライズ・データ・グラフ)を生成する。類似性の判定には、検索エンジンが提供する形態素解析等の技術を利用してよい。エンタープライズ・データ・グラフを利用することで、複数のデータストアを横断した多様な照会要求に対応できる。
複数のデータストアのそれぞれのフィールドにインデックスを付与し、フィールド間の類似性を判定し、類似性が高いと判定されたフィールドをノードとするグラフ形式データ(エンタープライズ・データ・グラフ)を生成する。類似性の判定には、検索エンジンが提供する形態素解析等の技術を利用してよい。エンタープライズ・データ・グラフを利用することで、複数のデータストアを横断した多様な照会要求に対応できる。
Description
本願発明は、データ分析するための方法、プログラム、および、システムに関し、より詳細には、異種データソース混在環境におけるフィールド間の関係性を自動的に発見し、対応付けるための方法、プログラム、および、システムに関する。
今日の企業は、複数の異なるタイプのデータソースにデータを分散している。たとえば、企業の各部門(販売、サービス、出荷など)に独自のデータソースがある場合もある。一方で、報告や分析のために異なるデータソースのデータを統合する必要性が高まっている。ここで、データソースとは、データの保管および提供を行なう技術の総称であり、典型的にはデータベースだが、これに限定されない。データソースの例については後述する。データソースは、文脈によってはデータ・リポジトリ、データストア、データ・ストレージ等とも呼ばれる
しかしながら、従来システムでは、データがどこに位置するか、複数のデータソース内のフィールドが互いにどのように関係しているかを判断することが困難であった。たとえば、同じモデルの製品であっても、営業部門のデータベースとサービス部門のデータベースとで製品コードが異なることがあった。異なるデータソースにおいて、関連したデータのフィールド名が異なることもあった。異なるデータソース間のフィールドを対応させることに意味がないこともあった。さらに、各データソースが、しばしば別のデータ設計者によって設計された異なるデータモデルを有することがあった。加えて、データソース内のデータはクリーンであるとは限らない(たとえば、データの欠損、不正確なデータ、形式の誤りがあることがある)。また、データソースによって同じ入力項目が異なる形式で保管されていることもある。企業内のデータ量がテラバイトからペタバイト級になることを考えると、従来システムでは、異なるデータソース内のテーブル(エンティティ)やフィールド間の関係を容易に判断できない場合が多かった。
このような問題を解決するための技術として、複数のデータソースを組み合わせて仮想データベースを構築するためのEII(Enterprise Information Integration)と呼ばれる技術が知られている(たとえば、特許文献1、非特許文献1)が、設計が異なるデータソース間でフィールドの対応付けを行なうことは依然として困難であり、十分な効果を発揮できていなかった。
Wikipedia - Enterprise information integration (https://en.wikipedia.org/wiki/Enterprise_information_integration)
設計の異なる複数のデータソース間を横断してデータ分析を行なうためのフィールド間の関連づけを効率的に行なう方法、プログラム、および、システムを提供する。
本願発明は、複数のデータストア内のデータを分析する方法であって、前記複数のデータストア内のテーブル内の複数のフィールド内の文字列の集合から重複を排除するステップと、前記重複を排除した文字列を転置インデックスに保存するステップと、前記転置インデックスに保存された文字列間の類似性を判定するステップと、前記判定された文字列間の類似性に基づいて前記複数のフィールド間の類似性を判定するステップと、前記複数のフィールド間の類似性が高いと判定されたフィールドを含むテーブルをノードとして類似関係をエッジで表現したグラフ形式データを生成するステップとを含むコンピューターにより実行される方法を提供することで前記課題に対応する。
また、本願発明は、前記転置インデックスに保存された文字列間の類似性を判定するステップは、さらに、前記複数のフィールド内の文字列に形態素解析を適用して分割するステップと、前記文字列間のコサイン類似度を求めるステップと、前記コサイン類似度にロジステック関数を適用するステップとを含む段落0008に記載の方法を提供することで前記課題に対応する。
また、本願発明は、前記転置インデックスに保存された文字列間の類似性を判定するステップは、さらに、前記複数のフィールド内の文字列の集合を一時的テーブルに保存するステップと、前記テーブルに自然結合演算を適用するステップと、前記テーブル間の類似度を計算するステップとを含む段落0008に記載の方法を提供することで前記課題に対応する。
また、本願発明は、さらに、前記複数のデータストア内のテーブル内の複数のフィールド内のデータの属性に基づいて前記フィールド間の類似性を判定するステップを含み、前記属性は、濃度、個別値の数、ヒストグラムの境界、ヌル値の数、または、非ヌル値の数のいずれかひとつ以上である段落0008、段落0009、または、段落0010に記載の方法を提供することで前記課題に対応する。
また、本願発明は、段落0008、段落0009、段落0010、または、段落0011に記載の方法で作成された前記グラフ形式データを使用した、コンピューターにより実行される方法であって、第一のデータストア内の第一のテーブルの第一のフィールドに対するクエリーを受信するステップと、前記グラフ形式データに基づいて前記第一のフィールドに類似する第二のフィールドを識別するステップと、前記第二のフィールドと前記第二のフィールドを含む第二のテーブルと前記第二のテーブルを含む第二のデータストアとのいずれかひとつ以上を表示するステップとを含む方法を提供することで前記課題に対応する。
また、本願発明は、段落0008、段落0009、段落0010、または、段落0011に記載の方法で作成された前記グラフ形式データを使用した、コンピューターにより実行される方法であって、第一のデータストアに関する情報を表示するステップと、前記第一のデータストア内の第一のテーブルの第一のフィールドに対するクエリーを受信するステップと、前記グラフ形式データに基づいて前記第一のフィールドに類似する第二のフィールドを識別するステップと、前記第二のフィールドを含む第二のデータストアに関する情報を表示するステップと、前記クエリーに応じて前記第一のデータストアに関する情報の表示と前記第二のデータストアに関する情報の表示とを並列的に更新するステップとを含む方法。
また、本願発明は、段落0008、段落0009、段落0010、または、段落0011に記載の方法で作成された前記グラフ形式データを使用したコンピューターにより実行される方法であって、第一のデータストア内の第一のテーブルの第一のフィールドに対するクエリーを受信するステップと、前記グラフ形式データに基づいて前記第一のフィールドに類似する第二のフィールドを識別するステップと、前記第一のデータストアに対する前記クエリーの結果と、前記第二のフィールドを含む第二のテーブルを含む第二のデータストアに対する前記クエリーの結果とを組み合わせて同一画面上に表示するステップとを含む方法を提供することで前記課題に対応する。
また、本願発明は、段落0008、段落0009、段落0010、または、段落0011に記載の方法で作成された前記転置インデックスを使用したコンピューターにより実行される方法であって、第一のデータストアに関する情報を表示するステップと、
前記第一のデータストア内の第一のテーブルの第一のフィールドに対するクエリーを受信するステップと、前記グラフ形式データに基づいて前記第一のフィールドに類似する第二のフィールドを識別するステップと、前記第二のフィールドを含む第二のデータストアに関する情報を表示するステップと、前記クエリーに応じて前記第一のデータストアに関する情報の表示と前記第二のデータストアに関する情報の表示とを並列的に更新するステップとを含む方法を提供することで前記課題に対応する。
前記第一のデータストア内の第一のテーブルの第一のフィールドに対するクエリーを受信するステップと、前記グラフ形式データに基づいて前記第一のフィールドに類似する第二のフィールドを識別するステップと、前記第二のフィールドを含む第二のデータストアに関する情報を表示するステップと、前記クエリーに応じて前記第一のデータストアに関する情報の表示と前記第二のデータストアに関する情報の表示とを並列的に更新するステップとを含む方法を提供することで前記課題に対応する。
設計の異なる複数のデータソース間を横断してデータ分析を行なうためのフィールド間の関連づけを効率的に行なう方法、プログラム、および、システムが提供される。
以下に図を用いて本願発明に係る実施例を説明する。明確化のために詳細は省略されている。図はすべて例示である。
図1に、エンタープライズ環境(100)における多様なデータソースの例を示す。エンタープライズ環境(100)で使用されるデータは多様なタイプのデータソース(105−135)から提供される。データソースのタイプの一つに検索エンジン(105)がある。検索エンジン(105)(たとえば、SOLRやELASTICSEARCH)は、トークナイザーやn-グラムによって分割された文字列を用いた高速検索のための転置インデックスを使用しており、テキストデータの保存や検索に有用である。転置インデックスは、複数の文書(107)にマップされた用語やキーワードを保存する。各文書は、一つ以上の属性値を含む一つのレコードに対応してよい。各レコードのフィールドの一部には検索の効率化のためにインデックスが付されていてよい。
他のデータソースのタイプとしてリレーショナル・データベース(リレーショナル・データベース管理システム(RDBMS)とも呼ばれる)(110)がある。リレーショナル・データベース(110)はデータをテーブル(113)に保存し、各テーブルはシステム中のエンティティを表現し、特定のフィールド(アトリビュートとも呼ばれる)がエンティティ間の関係を表わす。関係は、1対1、1対多、または、多対多であってよい。RDBMSは構造化照会言語(SQL)により照会することができ、構造化データの保存と照会のための堅牢で成熟したメカニズムを提供する。RDBMSは、ディスクからの効率的な読み取りとリレーショナル・データベース(110)へのデータ挿入のために、典型的にはBツリーのデータ構造を使用する。Bツリーは、対数時間(log N)で検索、挿入、削除が行なえるようデータをソートして維持するデータ構造である。
他のデータソースのタイプとしてカラムナー・データベース(115)がある。カラムナー・データベース(115)は、リレーショナル・データベース(110)と類似しているが、データを行指向の構造ではなく、カラム(列)(118)指向で保存する点に特徴がある。カラムナー・データベース(115)では、多数の行に少数のカラム(118)を有するデータの効率的な検索処理が可能である。多くの分析型照会では、一部のカラム(118)に対して集計処理を行なうことが必要であり、このような場合に、カラムナー・データベース(115)は保存と検索の効率性の点で有利である。カラム指向の保存では、特定のカラム(118)を読むためのディスク読み取り回数が少なくてすむためである。AMAZON REDSHIFTはカラムナー・データベース(115)の一例であり、APACHE PARQUET はカラム指向ファイル形式の一例である。
他のデータソースのタイプとしてキー・バリュー・データベース(キー・バリュー・ストアとも呼ばれる)(120)がある。キー・バリュー・ストア(120)は、連想アレイ(123)を保管、検索、管理するために設計されたデータ保管方式を使用する。連想アレイ(123)は、一般的にはディクショナリーまたはハッシュと呼ばれるデータ構造である。キー・バリュー・ストア(120)(たとえば、RIAK、REDIS、MEMCACHE)では、キーに基づいて高速なデータの検索が可能である。キー・バリュー・ストア(120)は、ディスクまたはメモリー上のマップデータ構造として実装されることもある。キー・バリュー・ストア(120)はシリアライザビリティや結果整合性に基づく整合性モデルに従うことができる。キー・バリュー・ストア(120)へのキーによるアクセスはO(1)のオーダー(定数)の複雑性で実行できる。
他のタイプのデータソースのタイプとしてウェブ・サービス(125)がある。ウェブ・サービス(125)は、エンタープライズ環境(100)内外の多様なデータ・システムに対する共通の統合インターフェースとして機能する。たとえば、ほとんどのソーシャル・メディアのデータへのアクセスは、REST(Representational State Transfer)API(アプリケーション・プログラミング・インターフェース)を経由して行なわれる。外部のクラウドベースのアプリケーション(160)(Salesforce.com、Google Analyticsなど)もREST API経由でアクセス可能である。ウェブ・サービス(125)は、サービスプロバイダが格納したデータに対するリアルタイムの要求−応答型アクセスを実現する。
他のタイプのデータソースのタイプとして、エンタープライズ環境内の共有ストレージに保管されているファイルシステムがある。ファイルシステムの中には、CSV/Excelなどのような構造化されたファイルデータに加えて、提案書、設計書などの非構造のデータも多く存在する。ファイルが保管されるストレージは、一般的な共有フォルダに加えて他の文書管理システム内に存在でもよい。
他のタイプのデータソースのタイプとして、リアルタイムで生成または受信されたライブデータを提供するライブ・ストリーミング・データソース(130)がある。ライブデータは、ソケット(KinesisやKafkaなど)からのリアルタイム・ストリームから提供されることが多い。ストリーム処理はラムダ・アーキテクチャ(バッチ処理とリアルタイム対話型処理)の二重の目的を果たすことができる。後者では、遅延時間の要件が1秒未満であることもある。ストリーム・イベントが欠落した場合の再処理が行なわれるケースもある。
他のタイプのデータソースのタイプとして「ビッグデータ」(103)がある。ビッグデータのデータソースは、Hadoopや Sparkなどのクラスター化された環境に大量の(TB(テラバイト)単位以上)のデータを保存する。典型的にはビッグデータはSQL的な照会言語を提供する。リアルタイムモデル(たとえば、SPARKSQLやImpala)または非同期モデル(たとえば、HIVE)が採用されることもある。
他のタイプのデータソースのタイプにデータマート(104)がある。データマートは、オンライン分析処理(OLAP)または分析サービス(たとえば、SQL Server Analysis Services(SSAS))の分析用キューブであることが多い。データマート(140)を照会するために分析クエリー(たとえば、SQLベース)が発行されることがある。これらの分析クエリーは、事前集計済のデータであっても、洗浄済のデータであってもよく、様々なレポートのニーズに合わせて使用される。
他のタイプのデータソースのタイプに、ビジネス・オブジェクト層(145)がある。ビジネス・オブジェクト(たとえば、SAP、Infomatica)は、ビジネス・ユーザーがビジネスインテリジェンスのデータを閲覧、分類、分析することを可能にするフロントエンド・アプリケーションであることが多い。これらのフロントエンド・アプリケーション層が、特定のAPIを使用して直接照会されてもよい。
複数のタイプのデータソース(105−145)を、有線接続や無線接続のネットワーク(150)を介して互いに通信可能に接続してもよい。さらに、データ管理分析装置(155)をネットワーク(150)に接続してもよい。データ管理分析装置(155)は、コンピューター(たとえば、ラップトップまたはデスクトップ)、モバイル・デバイス(たとえば、スマートフォン、ウェアラブル・デバイス(たとえば、スマートウォッチ)、および、サーバー・コンピューターであってよいが、これらに限定されない。データ管理分析装置(155)は、末尾の図9に示すようなコンピューティング環境(900)を有していてもよい。
上記の課題に対応するために、データ管理分析装置(155)は、以降に示すデータ分析のためのプロセスを実行することができる。実施例は、主に、リレーショナル・データベースのデータソースを例に使用しているが、他のタイプのデータソースにも適用可能である。
図2に、データ管理分析装置(155)が実行する、異なるデータソース間でフィールドの類似判定を行ない、エンタープライズ・データ・グラフを生成するプロセスの例(200)示す。ここで、エンタープライズ・データ・グラフとは、複数のデータソース間の関係、ひとつ以上のデータソース内の複数のデータモデル間の関係、または、ひとつ以上のデータソースに保管されたエンティティ間の関連性を表現したグラフである。以降の例では、エンティティ間の関係を表わすエンタープライズ・データ・グラフを説明するが、同様の考え方はデータソースやデータモデル間の関係に対しても適用される。なお、エンティティとは、データベース(データソース)により表現される現実世界の物のことを指し、リレーショナル・データベースではテーブルまたはビュー(仮想的テーブル)に相当する(以下の説明では、エンティティとテーブルは同義として扱い、テーブルにはビューを含むものとする)。また、フィールドとはテーブル中の列(カラム)のことを指す。
(205)複数のデータソースの各データソース中の各テーブルの文字列形式フィールドから単語を抽出するためのヒューリスティック・インデックスを準備する。ここで、ヒューリスティクス・インデックスとは、データソース中のテーブルの文字列形式フィールドに含まれるテキスト中の意味のある単語を抽出し、単語がどのデータソースのどのテーブルのどのフィールドにどの程度の頻度で存在するかを指し示すためのインデックスであり、Luceneなどの検索エンジンが提供する転置インデックス機能を使用して実装することができる。
(210)次に、類似性判定アルゴリズムにより、ヒューリスティクス・インデックスに格納された文字列形式フィールド間の類似性を判定する。具体的アルゴリズムの実施例のうちの2種類を以下に説明する。
図3に類似性判定アルゴリズムの第一の例を示す。この例では、フィールドに含まれる文字列の類似性で関連性を判定する。完全な一致ではなく、部分一致やトークナイズによる揺らぎなどを考慮した一致判定を行なう点に特色がある。たとえば、データソースによって同じ用語に対する表現の相違(たとえば、「車外装置」と「車外用装置」、「株式会社特許」と「(株)特許」)があっても、類似するフィールドを発見できる点に優位性がある。アルゴリズムの第一の例は以下のステップから成る。(1)各テ-ブルの文字列型フィールドを識別し、フィールド毎に保持される値を全て取得する。(2)取得した値集合に対してDISTINCT演算を適用し、重複除去を行なう(値の「件数」ではなく「種類」に着目した分析を行なう)。(3)重複除去された値集合を、形態素解析が可能な検索エンジン(たとえば、Apache Lucene / Solr) にフィードする。文字列に対して形態素解析器によりトークン分解、または n-gram 処理よりシーケンス分割を施す。文字列をどのように分割するかは、ユーザーのニーズに応じて検索エンジン側のスキーマを変更させることで設定することができる。検索エンジンのインデックス構造体には、Bag of Wordsを溜め込んだ索引が形成される。フィードした一件の文字列が、1ドキュメントに相当する。(4)フィールド間のコサイン類似度を求める。(5)コサイン類似度は0から1の間の実数値であるが、算出値と人間が感じる類似感には非線形な関係がある為、ロジスティック関数を適用する。0.5 近辺の変動鋭敏性を高め、0.0近辺と1.0近辺の鋭敏性を緩めることが好ましい。ロジスティック関数のパラメータは、設定ファイルで変更可能とすることが好ましい。(6)算出したフィールド間の類似度値に対して、所定の閾値に基づいてHigh /
Medium / Low / None 等の属性を設定することが好ましい。
Medium / Low / None 等の属性を設定することが好ましい。
図4に類似性判定アルゴリズムの第二の例を示す。この例では、フィールドに文字列が含まれている度合で関連性を判定する。曖昧な揺らぎの吸収は行わず、完全一致での判定を行う方式であり、以下のステップから成る。(1)各データモデルから文字列型フィールドを識別し、フィールド毎に保持される値を全て取得する。(2)取得した値集合に対してDISTINCT演算を適用し、重複除去を行なう(値の「件数」ではなく「種類」に着目する)。(3)重複除去された値集合を、1列×n行のテンポラリテーブルとして保持する。テンポラリー・テーブルにはインメモリDBMSを使用してよい。(4)上記ステップ3で生成された1列×n行のテンポラリテーブル群において、相互に結合演算(自然結合)を行なう。この結果セットの行数と元の2テーブルの各レコード数を比較する。(5)比較方法として、Dice係数、Simpson係数、Jaccard係数の3手法を適用し、各々の類似度を求める。3つの値は、重み付けした上で合成し、0から1の範囲を値域とする実数値(類似度)を算出する。(6)全テーブルの組み合わせで類似度が算出できた段階で、1列×n行のテンポラリテーブル群を全て破棄することが好ましい。(7)算出したフィールド間の類似度値に対して所定の閾値に基づいてHigh / Medium / Low / None 等の属性を設定することが好ましい。
(215)さらに、各データストアの各テーブルの各フィールド(文字列フィールドに限られない)の属性(たとえば、濃度(cardinality)、個別値数 (NDV)、ヒストグラムの範囲、ヌル値の件数、非ヌル値の件数)を収集し、保存してもよい。
(220)生成されたヒューリックス・インデックスと収集されたフィールド属性のいずれか、または、その両方に基づいて、異なるデータストア内の各テーブルの類似性を判定する。ヒューリックス・インデックスにより判定された類似度とフィールド属性により判定された類似度を重み付け平均し、所定の閾値を超えた場合に類似すると判定してもよい。ヒューリックス・インデックスにより判定された類似度が所定の閾値を超えた場合には、フィールド属性により判定された類似度にかかわらず、類似すると判定してよい。フィールド属性により判定された類似度が所定の閾値を超えた場合には、ヒューリックス・インデックスにより判定された類似度にかかわらず、類似すると判定してよい。ヒューリックス・インデックスにより判定された類似度が所定の閾値以下の場合には、フィールド属性により判定された類似度にかかわらず、類似しないと判定してよい。フィールド属性により判定された類似度が所定の閾値以下の場合には、ヒューリックス・インデックスにより判定された類似度にかかわらず、類似しないと判定してよい。このような判定の方法や所定の閾値はユーザーがパラメーターとして設定したり、スクリプトとして記述したりできるようになっていることが好ましい。
(225)判定された各フィールド間の類似性に基づいて、テーブル間の類似性を判定する。類似すると判定されたフィールドを多く含むテーブルは類似性が強いとして扱うことが好ましい。
(230)判定されたテーブル間の類似性に基づいてエンタープライズ・データ・グラフを生成する。図5に本願発明に係るエンタープライズ・データ・グラフの例の模式的表現を示す。エンタープライズ・データ・グラフのノードは、異なるデータソースに属するが、類似すると判定されたフィールドを含むテーブル(エンティティ)であり、エッジがテーブル間の類似性を表現する。類似するフィールドの数やその類似度に応じてテーブル間の類似度を設定してもよい。この例では各ノードはテーブルだが、同様の考え方でデータソースやデータモデル間の類似関係を表現してもよい。
(235)生成されたエンタープライズ・データ・グラフは、ユーザーのデータ間の関係の理解を高めたり、データソースを横断したクエリーを支援したりするために、画面上にグラフィック形式で表示することが好ましい。
図6に本願発明に係る実施例におけるエンタープライズ・データ・グラフ(600)の画面表示例を示す。図示したように、エンタープライズ・データ・グラフ(600)は、データストア(データ・リポジトリ)間の関連のマッピング処理の開始点となる開始データストア(605)(ここでは、"Complaints")の領域(610)を含んでいてよい。この領域(610)は開始データストア(605)に関する情報(たとえば、フィールドの数、および、フィールドやテーブルの内容を確認するためのリンク(607))を含んでいてもよい。この開始データストア(605)が、ユーザーから受信したクエリーに基づいて自動的に選択されてもよい。
また、エンタープライズ・データ・グラフ(600)は、図2のプロセスによって、開始データストア(605)類似すると判定されたと他の複数のデータストア(620−655)との間の類似関係を図示する領域(615)も含んでいてよい。図では、開始データストア(605)(この例では、"Complaints")は、他の8つのデータストア、すなわち、"Supplier"(620)、"Blue"(625)、"Sales"(630)、"Recalls"(635)、"Investigations"(640)、"Parts"(645)、"Reviews"(650)、および、"BOM"(655)と類似すると判定されている。これらの複数データストアのテクノロジーや設計(データモデル)は同一であるとは限らず、格納されたデータの内容も完全に整合性が取れているとは限らないが、前述のフィールド間の類似性判定アルゴリズムにより、テーブル(エンティティ)やデータスストア(データ・リポジトリ)間の関係をグラフィカルに表現し、ユーザーのデータ分析作業を支援できる。
さらに、エンタープライズ・データ・グラフ(600)は、ユーザーが選択したデータストア(この例では、"Supplier"(620)を選択したものとする)に類似するフィールドを有すると判定されたテーブルを含む、データストア(625−660)を示す領域(665)も含んでいてもよい。
これらのデータストア(625−660)のいくつかは類似するフィールドを開始データリポジトリ(605)にも含んでいると判定されている。たとえば、"Blue"(625)、"Sales"(630)、"Recalls"(635)、"Investigations"(640)、"Investigations"(645)、および、”Reviews”(650)は、いずれも領域(615)と領域(665)の両方に示されている。
しかし、領域(665)に示されたデータストアのいくつかが領域(615)に示されていないこともある。この場合には、これらのデータストアが、開始データストア(605)内のテーブル内のフィールドと類似するフィールドを含まないことを意味する。さらに、領域(815)に示されているデータストアのいくつかが領域(665)に示されていないこともあり、この場合には、これらのデータストアがユーザー選択データストア(620)内のテーブル内のフィールドと類似するフィールドを含まないことを意味する。たとえば、”Call logs”(660)は領域(665)にのみ示されているので、開始データストア(605)内のテーブルのフィールドに類似するフィールドを含まない。同様に、"BOM"'(655)は領域(615)にのみ図示されているので、ユーザー選択データストア(620)内のテーブルのフィールドに類似するフィールドを含まない。
エンタープライズ・データ・グラフ(600)は、開始データストア(605)に関する情報(たとえば、フィールドの数)を提供する情報領域(670)と開始データストア(605)内のフィールドを表示するためのリンク(872)とのいずれかひとつ以上を含んでいてよい。
さらに、エンタープライズ・データ・グラフ(600)は、ユーザー選択データストア(620)に関する情報(たとえば、フィールドの数)を提供する情報領域(675)とフィールドを表示するためのリンク(677)を含んでいてよい。
さらに、エンタープライズ・データ・グラフ(600)は、開始データストア(605)とユーザー選択データストア(620)との関係に関する情報を提供する領域(680)を含むこともできる。この領域(680)には、ユーザー選択データストア(620)内のフィールドと類似すると判定された開始データストア(605)内のフィールドのリスト(685)が含まれていてよい。また、この領域(680)はユーザー選択データストア(620)内のフィールドと類似すると判定された開始データストア(605)内のフィールドを表示するためのリンク(690)を含んでいてよい。
以降では、図2のプロセスにより生成されたエンタープライズ・データ・グラフとヒューリスティクス・インデックスのいずれか、または、その両方を使用した様々なクエリー(データ照会要求)の様々な実施例を説明する。
図7に、出願のデータ管理分析装置(155)の実施例によって実行され得る、エンタープライズ・データ・グラフを使用したクエリーの第一の実施例(ここでは、データ・チェーンと呼ぶ)のプロセス(700)を示す。
(705)ユーザーからデータストア内の特定のテーブルのフィールドに対するクエリーを受信する。
(710)エンタープライズ・データ・グラフを使用して、クエリーの対象となったテーブルと類似する他のテーブル内のフィールドを識別する。
(715)オプションとして、ヒューリスティック・インデックスに対して再度クエリーを行ない、ユーザーのクエリー対象であるフィールドの類似フィールドを識別してユーザーに表示してもよい。
(720)類似するフィールド、および、そのフィールドを含むテーブルを識別すると、ユーザーに対して確認メッセージを表示し、ユーザー入力を受け取って、データストアA以外のデータストアを表示する画面に画面表示を遷移する。この際に複数のテーブルを表示してユーザーにひとつを選択させてもよい。
(725)710または715で識別されたフィールドを使用して、ユーザーが対応するデータストアを照会し、結果を表示することができるようにする。
この実施例は、たとえば、コールセンターで問い合わせがあった製品のシリアル番号を用いて、異なるデータストアに保存された出荷明細や生産実績のデータをたどり、分析をする場合等に有効である。この際に、通常のRDBMSのテーブル間リレーションシップのように完全にその単語が一致しなくとも、部分一致するだけで求めるデータストアやテーブルに到達することができる点に優位性がある。
図8に、本出願の実施例によるデータ管理分析装置(155)によって実行され得る、エンタープライズ・データ・グラフを使用したクエリーの第二の実施例(フェデレーテッド・クエリーまたは連邦型クエリーと呼ばれる)のプロセス(800)を示す。
(805)複数のデータストアのデータを表現する画面をユーザーに表示し、ユーザーが、これらのデータストアからひとつを選択してクエリーを入力できるようにする。
(810)データストアの1つに対するクエリーを受信する。
(815)エンタープライズ・データ・グラフを使用して、810において受信されたクエリーの対象テーブルと類似する他のデータストア中のテーブルおよびそれが含むフィールドを識別する。
(820)オプションとして、ヒューリスティック・インデックスに対して再度クエリーを行ない、ユーザーのクエリーに関連するフィールドを識別して、ユーザーに表示してもよい。
(825)識別されたフィールドおよびテーブルに基づいて、各データストアに対して並列的にクエリーを発行する。
(830)
並列的なクエリーに応答して、各データストアに対応する画面上の表示を更新する。たとえば、ユーザーがあるデータストアに対して照会期間の絞り込みを行なうクエリーを送信すると、それ以外のデータストアに対しても同等のクエリーが発行され、それぞれの画面表示を変更することができ、データ分析を行なうユーザーの利便性を向上できる。
並列的なクエリーに応答して、各データストアに対応する画面上の表示を更新する。たとえば、ユーザーがあるデータストアに対して照会期間の絞り込みを行なうクエリーを送信すると、それ以外のデータストアに対しても同等のクエリーが発行され、それぞれの画面表示を変更することができ、データ分析を行なうユーザーの利便性を向上できる。
図9に、本出願の実施例によるデータ管理分析装置(155)によって実行され得る、エンタープライズ・データ・グラフを使用したクエリーの第三の実施例(リアルタイム・データ・フュージョン、仮想統合、または、コンポジット・データモデルと呼ぶ)のプロセス(900)を示す。
(905)データストア内の特定のテーブルに対するクエリーを受信する。
(910)エンタープライズ・データ・グラフに基づいて、他のデータストア中のテーブルの類似フィールドを識別する。
(915)オプションとして、類似と識別されたフィールドの選択肢をユーザーに表示し、ユーザーに選択させてもよい。
(920)905で要求されたフィールドと910で識別されたフィールドとを組み合わせて、クエリーの結果を生成する。この実施例により、物理的に異なる2つ以上のデータストアを、単一のデータストアのように取り扱うことができる。たとえば、ある販売データが地域別に別のデータベースやテーブルに格納したいた場合に、物理統合なしにあたかも単独のテーブルとして分析をおこなうことができ、ユーザーの利便性を向上できる。
図10に、本発明の実施例によるデータ管理および分析装置(155)によって実行され得る、ヒューリスティクス・インデックスを使用したクエリーの第四の実施例(Mμgenサーチと呼ぶ)のプロセス(1000)を示す。
(1005)ユーザーが入力した検索の対象となる文字列(キーワード)を受信する。この際に、ヒューリスティクス・インデックスを検索して、オートコンプリート(サジェスチョン)を行なってもよい。
(1010)受信したキーワードに基づいて、ヒューリスティクス・インデックスを検索して、そのキーワードを含むフィールドを含むテーブル、および、そのテーブルを含むリストを生成しユーザーに表示する。
(1015)リストからテーブルやフィールドを選択するユーザーからの入力を受信する。
(1020)選択されたテーブルやフィールドに対応する画面(ダッシュボード)を表示し、ユーザーからの照会要求を受信し、結果を表示する。この実施例により、多種多様なデータストアを網羅的に検索し、特定のキーワードに関連する可能性があるデータストアを発見できる。たとえば、車のモデル名をキーワードとして入力し、関連するリコール関連情報、サプライチェーン関連情報、生産システム関連情報を横断的に検索することで、その車種のクレーム対策を迅速に行なうことができる。
上記に述べた実施例以外にも、エンタープライズ・データ・グラフおよびヒューリスティクス・インデックスを使用して、複数のデータストアを横断した様々なクエリーに対応可能である。たとえば、現在の検索結果の特定のフィールドに含まれるすべて(または、一部)の値を用いて、他のデータストアに対して横断的に検索することができる。本願発明に係る方法では、テーブル間の関係がヒューリスティクス・インデックス、および、エンタープライズ・データ・グラフとして抽出されているため、データストアのアクセスにシステムの多大な負荷を要することなく、データストアの数が多数にわたる大規模なシステムにおいても効率的なデータ照会・分析が可能となる。
図11に、データ管理分析装置(155)の実施例の機能概略図を示し、図2から図10に示したプロセスやクエリーの実行方式の概要を示す。データ管理分析デバイス(155)は、ユーザーからクエリーパラメーター(Params)を受信し、クエリー結果をユーザーに提示するユーザーインターフェース層(1105)を含んでよい。ユーザーインターフェース層(1105)はクエリーを受信し、クエリー・エンジン(1110)に送信する。クエリー・エンジン(1110)は、クエリー・トランスフォーマ(1120)、クエリー・パイプライン(1125)、クライ・エグゼキュータ(1155)、リザルト・パイプライン(1160)、および、リザルト・コンバイナ(1165)を含む。
クエリー・トランスフォーマー(1120)は、クエリーエンジン(1110)内で、様々なフォーム要素を介してクエリーをユーザーインターフェース層(1105)から取得し、クエリー・トランスフォーマ(1120)に渡すために、汎用サーチ・オブジェクト(1115)に変換する。サーチ・オブジェクト(1115)はインターナル・メタデータ(1130)から検索したクエリーに関するすべてのメタデータ(データモデル、フィールド、データリポジトリ、フィルター)を含む。フェデレーテッド・サーチにおけるクエリー・トランスフォーマー(1120)の役割は、エンタープライズ・データ・グラフ(1135)を探索し、類似するフィールドを識別することである。クエリー・トランスフォーマー(1120)は、エンタープライズ・データ・グラフ(1135)に基づいてサーチ・オブジェクト(1115)を変換する。次に、サーチ・オブジェクト(1115)がクエリー・パイプライン(1125)に供給され、クエリー・パイプライン(1125)が実行すべきクエリーの順序を決定し、セキュリティ(1175)などの変換をサーチ・オブジェクト(1115)に追加する。クエリーの実行前に、クエリー・エグゼキュータ(1155)が、クエリーの結果がクエリー結果キャッシュ(1150)に存在するかどうかをチェックしてもよい。クエリーが1つのデータソースに対するものである場合には、クエリー・エグゼキュータ(1155)が直接実行してよい。
複合クエリー(たとえば、複数のデータストア(1140、1145)に対するクエリー)の場合、クエリー実行フロー全体が、対応する統計と共にインターナル・メタデータ(1130)に記録されてもよい。たとえば、クエリー変換の時間、物理的クエリーの実行時間、全ネットワーク転送の転送時間、ワークフローが実行されたクエリー・テンプレート/フォーマットなどの統計情報を記録してよい。
クエリー・エグゼキュータ(1155)は、サーチ・オブジェクト(1115)を取り込み、ネイティブ・データ・エンジンのAPIまたは言語を使用して実行可能なクエリーに変換する。クエリー実行の効率性向上のために可能な限りプッシュダウンを使用してよい。次いで、クエリー・エグゼキュータ(1155)は、クエリー結果を含むデータ構造体をリザルト・パイプライン(1160)に返す。
クエリー・エグゼキュータ(1155)は、結果のシーケンスを調整するリザルト・パイプライン(1160)として複数のクエリー結果を返してよい。独自のロジックに基づく変換をこのレイヤーで実行してもよい。
複合クエリーがそれぞれ異なる物理データソースに対する複数のクエリーを呼び出す場合、リザルト・コンバイナ(1165)を呼び出して、クエリーの各結合点で中間結果をジョインまたは組み合わせてもよい。たとえば、リザルト・コンバイナ(1165)は、中間結果を受け入れ、最良のジョイン戦略を決定し、次いで両方の中間データセットのジョイン結果を戻してもよい。データセット間の「ビッグデータ」級のジョインの場合、リザルト・コンバイナ(765)は、クラスター化されたインメモリエンジン(たとえば、APACHE SPARK)を使用して計算を実行することによって、分散ジョイン戦略を使用することができる。このようなクエリーは、リアルタイムで実行されてもよく、クラスター化環境での処理にネットワークオーバーヘッド以上のオーバーヘッドが含まれる場合、非同期的に実行されてもよい。
中間データセット量が小さい場合、メモリ内SQLエンジンを使用してジョインを実行することができる。一部の実施例では、RAMディスクテーブルへの一括挿入した後にSQLを実行することで、リアルタイム実行のための十分な高速性を実現可能である。
一部の実施例では、ジョインは、各中間結果をフェッチし、次に適切なジョインアルゴリズムを適用してリザルト・オブジェクト(1170)を生成することによって、リザルト・ジョイナー(1165)で2つのデータソースのクエリー結果をユーザー・インターフェース層(1105)に戻してもよい。リザルト・コンバイナ(1165)において、各中間結果を取得して適切なジョイン・アルゴリズムを適用して、ユーザー・インターフェース層(1105)を通じて返すための結果オブジェクト(1170)を生成することで、ジョインが、2つのデータソースをまたがって実行されてよい。
結果のマージには、多くのジョイン戦略を使用することができる。一部の実施例では、インメモリSQLエンジンを使用してよい。たとえば、中間データセットを、RAMディスク上のPOSTGRESQLまたはMYSQLテーブル(同じネットワーク上の別のサーバー上に存在していてもよい)に書き込んでよい。その後、SQLジョインのクエリー(計算式と共に使用されてもよい)がデータベース上で実行され、最終的な結果セットが生成されてよい。最終的なリザルト・セットは、リザルト・ジョイナー(1165)に送り返されてもよい。同様に、他のインメモリSQLエンジンの(たとえば、MemSQL)も使用してよい。インメモリサーバーを実行するインフラストラクチャは、大容量のメモリを備えていてよい。同様に、他のカラムナー・データベースも使用して良い。コストがかかる複雑なクエリや対象となるデータソースの性能が悪いときに、クエリパフォーマンスに優れたカラムナー・データベースに書き込んで、ユーザーに快適なパフォーマンスを提供する。
他の実施例では、ネイティブなデータソース上で可能な限り多くの処理を行なうことが望ましいことがある。サーチ、比較、ローカル・ジョイン、ソート、集計、および、グルーピングを下位のデータソースにプッシュダウンすることで、データソースの機能を活用でき、ネットワークを介して転送され、インメモリのエンジンで処理される中間データの量を制限できる。
他の実施例として、データのクエリー・キャッシングを使用してもよい。たとえば、キャッシュ・クラスター(たとえば、REDIS、MEMCACHED)をクエリーごとに結果を保管するように構成してもよい。どのストアに対してクエリーを実行する前にも、キャッシュ上に結果がないかをチェックしてよい。結果がキャッシュ上にない場合のみに、データソースへのアクセスが行なわれる。レイテンシーが大きいソースに対して頻繁にクエリーが実行される場合には性能が向上可能である。自身ではキャッシュ機能を持たないエンジン(たとえば、IMPALA)や複合クエリー(たとえば、クエリーが複数の物理的クエリーに分割され、結果がインメモリのSQLエンジンで併合される場合)では、性能向上が顕著である可能性がある。
他の実施例では、同時並行処理が実行されてもよい。たとえば、クエリーが多くのデータソースにまたがる場合、並行処理によってクエリー実行時間が短縮される可能性がある。さらに、一部の実施例において、クエリー実行プラン決定中に、相互に排他的なクエリーを識別して、並列スレッドで実行してもよい。
他の実施例では、分散処理が実行されてもよい。たとえば、HadoopプラットフォームまたはSparkプラットフォーム上の特定のエンジン(たとえば、HIVE、IMPALA)を用いてクエリーを実行する間に、ネイティブデータソースの分散処理能力を本質的に使用してもよい。しかし、いくつかの実装例では、SparkやHadoopのようなクラスター化エンジン上の大規模な中間セットを分散ジョインする際には、他のエコシステムツールを必要とすることがある。
さらに、非リアルタイム最適クエリープラン生成が使用されてもよい。たとえば、クエリー・エンジン(1110)は、クエリー実行ワークフロー内の各ステージの実行時間を記録することができる。このログには、特定のデータモデルのデータソースに対するクエリー処理と、ネットワーク転送およびデータマージが含まれてよい。このログは、その後のクエリー・ワークフローの実行のためにクエリープランをさらに最適化するためのデータとして有用である。最適な実行グラフの探索のオーバーヘッドを避けるために、この最適化プロセスは、最適な実行計画を決定し、内部メタデータ記憶装置(1130)に再使用のためにキャッシュするバックグラウンドプロセスとして実行してもよい。
(コンピューティング環境の例)
図12に、特定の実施例の実装に適したコンピューティング・デバイス(1205)を含むコンピューティング環境(1200)の例を示す。コンピューティング環境(1200)中のコンピューティング・デバイス(1205)は一つ以上の処理ユニット、コア、または、プロセッサ(1210)、メモリ(1215)(たとえば、RAM、ROM等)、内部ストレージ(1220)(たとえば、磁気ディスク、光学ディスク、半導体ストレージ、有機ストレージ)、I/Oインターフェース(1225)を含んでいてよく、それらは、情報のやり取りのためにコミュニケーション機構またはバス(1230)上で接続されていてよく、コンピューティング・デバイス(1205)に埋め込まれていてもよい。
図12に、特定の実施例の実装に適したコンピューティング・デバイス(1205)を含むコンピューティング環境(1200)の例を示す。コンピューティング環境(1200)中のコンピューティング・デバイス(1205)は一つ以上の処理ユニット、コア、または、プロセッサ(1210)、メモリ(1215)(たとえば、RAM、ROM等)、内部ストレージ(1220)(たとえば、磁気ディスク、光学ディスク、半導体ストレージ、有機ストレージ)、I/Oインターフェース(1225)を含んでいてよく、それらは、情報のやり取りのためにコミュニケーション機構またはバス(1230)上で接続されていてよく、コンピューティング・デバイス(1205)に埋め込まれていてもよい。
コンピューティング・デバイス(1205)は、入力ユーザー・インターフェース(1235)および出力デバイス・インターフェース(1240)と通信可能なように接続されていてよい。入力ユーザー・インターフェース(1235)および出力デバイス・インターフェース(1240)のいずれか、または、両方は有線であっても無線であってもよく、取り外し可能であってもよい。入力ユーザー・インターフェース(1235)は、物理的か仮想的か問わず、入力を提供できる任意の装置、コンポーネント、センサーを含む(たとえば、ボタン、タッチスクリーンインターフェース、キーボード、ポインター、カーソルコントロール、マイクロフォン、点字、モーションセンサー、光学リーダーなど)。出力デバイス・インターフェース(1240)は、ディスプレイ、テレビ、モニター、プリンター、スピーカー、点字等を含む。一部の実施例では、入力ユーザー・インターフェース(1235)と出力デバイス・インターフェース(1240)はコンピューティング・デバイス(1205)に埋め込まれているか、物理的に接続されていてもよい。他の実施例では、他のコンピューティング・デバイスがコンピューティング・デバイス(1205)の入力ユーザー・インターフェース(1235)と出力デバイス・インターフェース(1240)の機能を提供してもよい。
コンピューティング・デバイス(1205)は、(たとえば、タブレット、ノートブック、ラップトップ、パーソナルコンピュータ、携帯テレビ、ラジオなどの)モバイルデバイス、携帯性が高いデバイス(たとえば、スマートフォン、車両および他の機械のデバイス、人間および動物が携行するデバイスなど)、コンピューター(たとえば、デスクトップコンピューター、サーバーデバイス、他のコンピューター、情報キオスク、1つ以上のプロセッサが埋め込まれたテレビ、および/またはそれらに結合されたテレビ、ラジオなど)を含むが、これに限定されない。
コンピューティング・デバイス(1205)は、ひとつ以上の同種または異種のコンピューティング・デバイスを含む、任意の数のネットワーク構成要素、デバイス、およびシステムと通信するために、外部記憶装置(1245)およびネットワーク(1250)に(たとえば、I / Oインターフェース(1225)を介して)接続可能にされていてよい。コンピューティング・デバイス(1205)、または、任意の接続されたコンピューティング・デバイスは、サーバー、クライアント、シン・サーバー、一般的なマシン、特殊目的のマシン、または、他の名称で呼ばれるコンピューターとして機能し、サービスを提供したり、それらを参照したりすることができる。
I/Oインターフェース(1225)は、コンピューター環境900内の接続されたコンポーネント、デバイス、ネットワークの間で情報を通信するためのネットワークのための、任意の通信またはI / Oプロトコルまたは規格(たとえば、イーサネット(登録商標)、802.11x、ユニバーサルシステムバス、WiMAX、モデム、セルラネットワークプロトコルなど)を使用する有線や無線インターフェースを含むが、これに限定されない。ネットワーク(950)は、任意のネットワーク(たとえば、インターネット、ローカルエリアネットワーク、エリアネットワーク、電話ネットワーク、セルラネットワーク、衛星ネットワーク)またはそれらの組み合わせであってよい。
コンピューティング・デバイス(1205)は、一時媒体および非一時媒体を含むコンピューター使用可能またはコンピューター可読媒体を使用して使用・通信することができる。一時媒体には、伝送媒体(たとえば、金属ケーブル、光ファイバ)、信号、搬送波などが含まれる。非一時的媒体には、磁気媒体(たとえば、ディスクおよびテープ)、光媒体(たとえば、CD-ROM、デジタルビデオディスク、ブルーレイディスク)、半導体媒体(たとえば、RAM、ROM、フラッシュメモリ、ソリッドステートストレージ )、および他の不揮発性記憶装置またはメモリを含む。
コンピューティング・デバイス(1205)は、いくつかのコンピューティング環境実施例において、技法、方法、アプリケーション、プロセス、またはコンピューター実行可能命令を実現するために使用することができる。コンピューター実行可能命令は、一時媒体から取り出して、非一時媒体上に記憶し、それから取り出すことができる。実行可能命令は、プログラミング、スクリプティング、および機械語(たとえば、C、C ++、C#、Java、Visual Basic、Python、Perl、JavaScriptなど)のうちの1つ以上から成っていてよい。
プロセッサ(1210)は、ネイティブ環境または仮想環境において、任意のオペレーティングシステム(OS)(図示していない)の下で実行することができる。論理ユニット(1255)、API(アプリケーションプログラミングインターフェース)ユニット(1260)、入力ユニット(1265)、出力ユニット(1270)、ヒューリスティック・インデックス生成ユニット(1275)、類似性判定ユニット(1280)、エンタープライズ・データグラフ生成ユニット(1285)、分析グラフィクス・ユニット(1290)、および、ユニット間通信機構(1295)は、互いに通信するために、OSおよび他のアプリケーション(図示してない)と通信する。たとえば、ヒューリスティック・インデックス生成ユニット(1275)、類似性判定ユニット(1280)、エンタープライズ・データグラフ生成ユニット(1285)、および分析グラフィクス・ユニット(1290)は、図2から図図10に示すひとつ以上の処理を実装することができる。記載されたユニットと要素は、設計、機能、構成、または実装において変更可能であり、説明の内容に限定されない。
いくつかの実施例では、APIユニット(1260)は、情報または実行命令を受信すると、1つ以上の他のユニット(たとえば、ヒューリスティック・インデックス生成ユニット(1275)、類似性判定ユニット(1280)、エンタープライズ・データグラフ生成ユニット(1285)、分析グラフィックス・ユニット(1290)、および、クエリーユニット(1297)と通信を行なってよい。たとえば、ヒューリスティック・インデックス生成ユニット(1275)を介してヒューリスティック・インデックスが生成されるときに、異なるエンティティ間の類似性を判定するために、ヒューリスティック・インデックスが類似性判定ユニット(1280)に提供されてもよい。さらに、エンタープライズ・データグラフ生成ユニット(1285)がエンタープライズ・データグラフを生成する際に、類似性判定ユニット(1280)が類似性データを提供してもよい。さらに、エンタープライズ・データ・グラフ生成ユニット(1285)が、分析グラフィクス(1290)に提供され、出力ユニット(1270)を用いて表示されるデータ分析グラフィックを生成してもよい。
一部の実施例では、論理ユニット(1255)が、ユニット間の情報フローを制御し、APIユニット(1260)、入力ユニット(1265)、出力ユニット(1270)、ヒューリスティック・インデックス生成ユニット(1275)、類似性判定ユニット(1280)、エンタープライズ・データグラフ生成ユニット(1285)、および、分析グラフィクスユニット(1290)を含む。たとえば、1つ以上プロセスのフローや実装を、論理ユニット(1255)によって単独で、またはAPIユニット(1260)と連携して制御することができる。クエリーユニット(1297)は、APIユニット(1260)、論理ユニット(1255)、および、類似性判定ユニット(980)と連携して、それぞれのデータリポジトリでクエリーを実行する。
いくつかの実施例について説明してきたが、これらは当業者に対して本願発明の主題を伝えるために提供されたものである。本願発明の主題は、説明された実施例に限定されることなく、様々な形態で実現され得ることに注意されたい。本願発明の主題は、ここで定義または説明された構成要素なしに実現することもでき、ここで説明されなかった別の構成要素と共に実現することもできる。本願請求の範囲により定義された本願発明の主題を逸脱することなく、これらの実施例を変更することは当業者にとって容易である。
Claims (8)
- 複数のデータストア内のデータを分析する方法であって、
前記複数のデータストア内のテーブル内の複数のフィールド内の文字列の集合から重複を排除するステップと、
前記重複を排除した文字列を転置インデックスに保存するステップと、
前記転置インデックスに保存された文字列間の類似性を判定するステップと、
前記判定された文字列間の類似性に基づいて前記複数のフィールド間の類似性を判定するステップと、
前記複数のフィールド間の類似性が高いと判定されたフィールドを含むテーブルをノードとして類似関係をエッジで表現したグラフ形式データを生成するステップとを
含むコンピューターにより実行される方法。 - 前記転置インデックスに保存された文字列間の類似性を判定するステップは、さらに、
前記複数のフィールド内の文字列に形態素解析を適用して分割するステップと、
前記文字列間のコサイン類似度を求めるステップと、
前記コサイン類似度にロジステック関数を適用するステップとを
含む請求項1に記載の方法。 - 前記転置インデックスに保存された文字列間の類似性を判定するステップは、さらに、
前記複数のフィールド内の文字列の集合を一時的テーブルに保存するステップと、
前記テーブルに自然結合演算を適用するステップと、
前記テーブル間の類似度を計算するステップとを
含む請求項1に記載の方法。 - さらに、前記複数のデータストア内のテーブル内の複数のフィールド内のデータの属性に基づいて前記フィールド間の類似性を判定するステップを含み、
前記属性は、濃度、個別値の数、ヒストグラムの境界、ヌル値の数、または、非ヌル値の数のいずれかひとつ以上である
請求項1、請求項2、または、請求項3に記載の方法。 - 請求項1、請求項2、請求項3、または、請求項4に記載の方法で作成された前記グラフ形式データを使用した、コンピューターにより実行される方法であって、
第一のデータストア内の第一のテーブルの第一のフィールドに対するクエリーを受信するステップと、
前記グラフ形式データに基づいて前記第一のフィールドに類似する第二のフィールドを識別するステップと、
前記第二のフィールドと前記第二のフィールドを含む第二のテーブルと前記第二のテーブルを含む第二のデータストアとのいずれかひとつ以上を表示するステップとを含む方法。 - 請求項1、請求項2、請求項3、または、請求項4に記載の方法で作成された前記グラフ形式データを使用した、コンピューターにより実行される方法であって、
第一のデータストアに関する情報を表示するステップと、
前記第一のデータストア内の第一のテーブルの第一のフィールドに対するクエリーを受信するステップと、
前記グラフ形式データに基づいて前記第一のフィールドに類似する第二のフィールドを識別するステップと、
前記第二のフィールドを含む第二のデータストアに関する情報を表示するステップと、
前記クエリーに応じて前記第一のデータストアに関する情報の表示と前記第二のデータストアに関する情報の表示とを並列的に更新するステップとを含む方法。 - 請求項1、請求項2、請求項3、または、請求項4に記載の方法で作成された前記グラフ形式データを使用した、コンピューターにより実行される方法であって、
第一のデータストア内の第一のテーブルの第一のフィールドに対するクエリーを受信するステップと、
前記グラフ形式データに基づいて前記第一のフィールドに類似する第二のフィールドを識別するステップと、
前記第一のデータストアに対する前記クエリーの結果と、前記第二のフィールドを含む第二のテーブルを含む第二のデータストアに対する前記クエリーの結果とを組み合わせて同一画面上に表示するステップとを含む方法。 - 請求項1、請求項2、請求項3、または、請求項4に記載の方法で作成された前記転置インデックスを使用した、コンピューターにより実行される方法であって、
ユーザーからのキーワードを受信するステップと、
前記転置インデックスから前記キーワードを含むフィールドを含むテーブルを検索するステップと、
前記フィールド、または、前記テーブルを表示するステップとを
含むコンピューターにより実行される方法。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2017115395A JP6964384B2 (ja) | 2016-03-31 | 2017-06-12 | 異種データソース混在環境におけるフィールド間の関係性の自動的発見のための方法、プログラム、および、システム |
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US201662315784P | 2016-03-31 | 2016-03-31 | |
US62/315,784 | 2016-03-31 | ||
PCT/JP2017/012496 WO2017170459A1 (ja) | 2016-03-31 | 2017-03-27 | 異種データソース混在環境におけるフィールド間の関係性の自動的発見のための方法、プログラム、および、システム |
Related Child Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2017115395A Division JP6964384B2 (ja) | 2016-03-31 | 2017-06-12 | 異種データソース混在環境におけるフィールド間の関係性の自動的発見のための方法、プログラム、および、システム |
Publications (4)
Publication Number | Publication Date |
---|---|
JP6159908B1 JP6159908B1 (ja) | 2017-07-05 |
JPWO2017170459A6 true JPWO2017170459A6 (ja) | 2018-04-05 |
JPWO2017170459A1 JPWO2017170459A1 (ja) | 2018-04-05 |
JP6159908B6 JP6159908B6 (ja) | 2018-06-27 |
Family
ID=59272936
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2017523549A Active JP6159908B6 (ja) | 2016-03-31 | 2017-03-27 | 異種データソース混在環境におけるフィールド間の関係性の自動的発見のための方法、プログラム、および、システム |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP6159908B6 (ja) |
Families Citing this family (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN110110211A (zh) * | 2018-01-22 | 2019-08-09 | 北京京东尚科信息技术有限公司 | 基于通用模型的数据查询方法和装置 |
CN111198898B (zh) * | 2018-11-16 | 2023-10-27 | 浙江宇视科技有限公司 | 大数据查询方法及大数据查询装置 |
CN111459789B (zh) * | 2019-08-28 | 2023-11-03 | 南京意博软件科技有限公司 | 一种应用程序编程接口的检测方法及装置 |
CN111666274B (zh) * | 2020-06-05 | 2023-08-25 | 北京妙医佳健康科技集团有限公司 | 数据融合方法、装置、电子设备及计算机可读存储介质 |
JP7434117B2 (ja) | 2020-09-10 | 2024-02-20 | 株式会社東芝 | 対話装置、方法、及びプログラム |
Family Cites Families (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2000222430A (ja) * | 1999-02-03 | 2000-08-11 | Osaka Gas Co Ltd | 仮想データベース管理システム |
JP2004227037A (ja) * | 2003-01-20 | 2004-08-12 | Sangaku Renkei Kiko Kyushu:Kk | フィールドマッチング装置とそのプログラム、コンピュータ読み取り可能な記録媒体、及び同一フィールド判定方法 |
JP4451624B2 (ja) * | 2003-08-19 | 2010-04-14 | 富士通株式会社 | 情報体系対応付け装置および対応付け方法 |
JP5194818B2 (ja) * | 2008-01-16 | 2013-05-08 | 富士通株式会社 | データ分類方法およびデータ処理装置 |
US9507824B2 (en) * | 2014-08-22 | 2016-11-29 | Attivio Inc. | Automated creation of join graphs for unrelated data sets among relational databases |
-
2017
- 2017-03-27 JP JP2017523549A patent/JP6159908B6/ja active Active
Similar Documents
Publication | Publication Date | Title |
---|---|---|
WO2017170459A1 (ja) | 異種データソース混在環境におけるフィールド間の関係性の自動的発見のための方法、プログラム、および、システム | |
JP6617117B2 (ja) | 半構造データのためのスケーラブルな分析プラットフォーム | |
US11036735B2 (en) | Dimension context propagation techniques for optimizing SQL query plans | |
JP6159908B6 (ja) | 異種データソース混在環境におけるフィールド間の関係性の自動的発見のための方法、プログラム、および、システム | |
CN107402995B (zh) | 一种分布式newSQL数据库***及方法 | |
Khasawneh et al. | Sql, newsql, and nosql databases: A comparative survey | |
JPWO2017170459A6 (ja) | 異種データソース混在環境におけるフィールド間の関係性の自動的発見のための方法、プログラム、および、システム | |
EP3014488B1 (en) | Incremental maintenance of range-partitioned statistics for query optimization | |
Chung et al. | JackHare: a framework for SQL to NoSQL translation using MapReduce | |
US10860562B1 (en) | Dynamic predicate indexing for data stores | |
JP2017037648A (ja) | ハイブリッドデータを保存するためのハイブリッドデータストレージシステム、方法及びプログラム | |
WO2015128756A1 (en) | A method, system and computer program for scanning a plurality of storage regions within memory for a specified quantity of results | |
Khan et al. | SQL Database with physical database tuning technique and NoSQL graph database comparisons | |
Harby et al. | From data warehouse to lakehouse: A comparative review | |
Khan et al. | Predictive performance comparison analysis of relational & NoSQL graph databases | |
Duda | Business intelligence and NoSQL databases | |
US11366811B2 (en) | Data imprints techniques for use with data retrieval methods | |
Venkatesh et al. | Challenges and research disputes and tools in big data analytics | |
US20160070707A1 (en) | Keyword search on databases | |
Hasan et al. | Data transformation from sql to nosql mongodb based on r programming language | |
Ramchand et al. | Big data architectures for data lakes: A systematic literature review | |
Cassavia et al. | Data preparation for tourist data big data warehousing | |
Greca et al. | Optimizing Data Retrieval by Using Mongodb with Elasticsearch. | |
Lovalekar | Big data: An emerging trend in future | |
JP2016062522A (ja) | データベース管理システム、データベースシステム、データベース管理方法およびデータベース管理プログラム |