JP7419244B2 - 例によるetlルールの学習 - Google Patents

例によるetlルールの学習 Download PDF

Info

Publication number
JP7419244B2
JP7419244B2 JP2020545789A JP2020545789A JP7419244B2 JP 7419244 B2 JP7419244 B2 JP 7419244B2 JP 2020545789 A JP2020545789 A JP 2020545789A JP 2020545789 A JP2020545789 A JP 2020545789A JP 7419244 B2 JP7419244 B2 JP 7419244B2
Authority
JP
Japan
Prior art keywords
etl
schema
source
mapping
target
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.)
Active
Application number
JP2020545789A
Other languages
English (en)
Other versions
JP2021519964A (ja
JPWO2019204106A5 (ja
Inventor
サッシン,ミシェル
Original Assignee
オラクル・インターナショナル・コーポレイション
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by オラクル・インターナショナル・コーポレイション filed Critical オラクル・インターナショナル・コーポレイション
Publication of JP2021519964A publication Critical patent/JP2021519964A/ja
Publication of JPWO2019204106A5 publication Critical patent/JPWO2019204106A5/ja
Application granted granted Critical
Publication of JP7419244B2 publication Critical patent/JP7419244B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06NCOMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
    • G06N20/00Machine learning
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/25Integrating or interfacing systems involving database management systems
    • G06F16/254Extract, transform and load [ETL] procedures, e.g. ETL data flows in data warehouses
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/21Design, administration or maintenance of databases
    • G06F16/211Schema design and management
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06NCOMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
    • G06N5/00Computing arrangements using knowledge-based models
    • G06N5/02Knowledge representation; Symbolic representation
    • G06N5/022Knowledge engineering; Knowledge acquisition
    • G06N5/025Extracting rules from data

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Data Mining & Analysis (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Evolutionary Computation (AREA)
  • Computing Systems (AREA)
  • Mathematical Physics (AREA)
  • Artificial Intelligence (AREA)
  • Medical Informatics (AREA)
  • Computer Vision & Pattern Recognition (AREA)
  • Computational Linguistics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Machine Translation (AREA)

Description

関連出願との相互参照
本願は、2018年4月16日に出願された米国特許出願第15/953,873号の優先権を主張する。当該出願の開示はここに引用により援用される。
分野
本開示の実施形態は一般に、例による抽出、変換、およびロードマッピングの学習に関する。
背景
コンピューティングデバイスおよび接続されたデバイスの急増は、管理を必要とする莫大な量のデータを生成してきた。データ科学者などの人間によってしばしば実行されるデータ管理の一局面は、抽出、変換、およびロード(extract, transform, and load:ETL)、または、抽出、ロード、および変換(extract, load, and transform:ELT)であり、それらは、この開示全体にわたって区別なく使用されるであろう。一般に、ETLは、データをソーススキーマからターゲットスキーマへ動かすより大きいデータ移行プロセスの1ステップである。この移行プロセスは、ほんの数例を挙げると、テーブル/カラムマッピング、抽出およびロードルール/マッピング(たとえば、結合条件、作業単位判断など)、移行後および/または移行前変換といった、複数の層を有することが多い。その結果、データ管理の他の局面は機敏で効率的になるものの、ETLは、今日の従来の手法を活用する際に扱いにくいプロセスになる場合がある。
概要
本開示の実施形態は一般に、関連技術を実質的に改良する、例によって抽出、変換、およびロードマッピングを学習するためのシステムおよび方法に向けられる。
いくつかの実施形態では、複数の特徴が、ソーススキーマおよびターゲットスキーマから抽出され得る。特徴は、ソーススキーマおよびターゲットスキーマの複数のテーブルのカラムを少なくとも含む。例示的なETLマッピングが、機械学習アルゴリズムに提供され得る。例示的なETLマッピングは、ソーススキーマの1つ以上のテーブルからデータを抽出し、抽出されたデータをターゲットスキーマの1つ以上のテーブルにロードするための定義を含む。機械学習アルゴリズムを使用し、ソーススキーマ、ターゲットスキーマ、および抽出された特徴に基づいて、1つ以上のETLルールが予測され得る。1つ以上のETLルールは、ソーススキーマからデータを抽出し、抽出されたデータをターゲットスキーマにロードするためのロジックを定義する。予測されたETLルール、ソーススキーマ、ターゲットスキーマ、および抽出された特徴に基づいて、追加のETLマッピングが生成され得る。追加のETLマッピングは、ソーススキーマの1つ以上のテーブルからデータを抽出し、抽出されたデータをターゲットスキーマの1つ以上のテーブルにロードするための追加の定義を提供する。
実施形態の特徴および利点は、以下の説明で述べられ、または説明から明らかになり、またはこの開示の実践によって学習されるであろう。
さらなる実施形態、詳細、利点、および変更が、添付図面とともに解釈される以下の好ましい実施形態の詳細な説明から明らかになるであろう。
例示的な一実施形態に従った、例によって抽出、変換、およびロードマッピングを学習するためのシステムを示す図である。 例示的な一実施形態に従った、ETL学習システムに動作可能に結合されたコンピューティングデバイスのブロック図である。 例示的な一実施形態に従ったサンプルスターデータスキーマを示す図である。 例示的な一実施形態に従ったサンプルETL仕様を示す図である。 例示的な一実施形態に従った、ETLツールによって実現されるサンプルETL構造を示す図である。 例示的な一実施形態に従ったサンプルスキーママッピング構造を示す図である。 例示的な一実施形態に従ったサンプルETLマッピング式を示す図である。 例示的な一実施形態に従ったサンプル属性ベクトルを示す図である。 例示的な一実施形態に従った、例によって抽出、変換、およびロードマッピングを学習するための例示的な方法を示す図である。
詳細な説明
実施形態は、例によって抽出、変換、およびロードマッピングを学習する。ソーススキーマとターゲットスキーマとの間の関係は複雑であることが多く、このため、ETLのための機械学習アプリケーションを難しくする。実施形態は、改良された学習を可能にする、機械学習アルゴリズムに粒状レベルのデータ点を提供するソースデータスキーマおよびターゲットデータスキーマのための特徴抽出を活用する。また、ソースデータスキーマとターゲットデータスキーマとの間の例示的なマッピングが、ETLフレームワークに従って定義される機械学習アルゴリズムに提供される。その結果、機械学習アルゴリズムは、例においてターゲットスキーマとソーススキーマとの間に示された関係に基づいて、傾向を推定することができる。これらの推定された傾向は、スキーマに特有の粒状レベルで定義されるため、機械予測を助長する詳細なレベルで定義され得る。続いて、機械学習アルゴリズムは、ソースからターゲットへのデータの移行を達成するために使用され得る新たなETLルールを予測することができる。次に、ルールインタプリタが、予測された新たなETLルールに基づいてETLマッピングを生成するために活用され得る。
添付図面において例が示された本開示の実施形態を、これから詳細に参照する。以下の詳細な説明では、本開示の完全な理解を提供するために、多くの特定の詳細が述べられる。しかしながら、本開示はこれらの特定の詳細がなくても実践され得るということが、当業者には明らかであろう。他の例では、実施形態の局面を不必要に不明瞭にしないように、周知の方法、手順、コンポーネント、および回路は、詳細には説明されていない。可能な限り、同じ参照番号が同じ要素について使用される。
図1は、一実施形態に従った、例によって抽出、変換、およびロードマッピングを学習するためのシステムを示す。システム100は、ソーススキーマ102と、ターゲットスキーマ104と、特徴抽出106と、例示的なETLマッピング108と、機械学習コンポーネント110と、出力ETLルール112と、ルールインタプリタ114と、出力ETLマッピング116とを含む。ソーススキーマ102およびターゲットスキーマ104は、リレーショナルデータテーブル、フラットファイル、NoSQLデータベース、メッセージキューまたはトピック、イベントストリーム、もしくはこれらの組合せといった、データを格納するための任意のデータスキーマであり得る。たとえば、ソーススキーマ102および/またはターゲットスキーマ104は、第3正規形(Third Normal Form:3NF)スキーマといった、1組のルールまたは規格に従って構成された1組のリレーショナルテーブルを含み得る。
一般に、各スキーマは、データの1つ以上のカラムを有するデータテーブルを含むであろう。スキーマは、テーブルおよびテーブルが格納するデータだけでなく、テーブル間の関係によって定義される。たとえば、第1のテーブルと第2のテーブルとの間の関係は、テーブルの各々に格納されたデータをリンクする外部キーによって定義され得る。いくつかの実施形態では、2つのテーブルが複数の関係を共有してもよい(たとえば、テーブル間の関係を定義する複数の外部キーを有し得る)。テーブル間の異なるタイプの関係が、さらにここに開示されるであろう。
データスキーマの設計はしばしば、設計者によって異なり得る。たとえば、所与の1組の関係を有する所与の1組のデータが、さまざまな設計を有する多くのデータスキーマによって首尾よく表わされ得る。ある1組のデータを検索するためにテーブル結合を必要とする設計もあれば、必要としない設計もある。加えて、多くのレガシーシステムは、現在公知のデータベースによって容易に実現されないスキーマ設計を実現する。どのようにソーススキーマからデータを抽出し、そのデータをターゲットスキーマにロードするかを考慮する際、とりわけ、テーブル、カラム、およびキーのための命名規則といったきめ細かい詳細が、ルール/マッピング構築において重要な役割を果たす。スキーマ設計の非常に主観的な性質により、ソーススキーマ102に格納されたデータをターゲットスキーマ104へ抽出、ロード、および/または変換するルール/マッピングは、これらのスキーマに特有であり得る。
実施形態では、正確なルール予測を生成するように機械学習コンポーネント110を構成するために、特徴抽出106が、ソーススキーマ102およびターゲットスキーマ104に対して実行される。たとえば、特徴抽出106は、ETLルール/マッピング生成を可能にするきめ細かい詳細を機械学習コンポーネント110に提供するために使用され得る。次に、学習コンポーネント110は、ソーススキーマ102およびターゲットスキーマ104についてのスキーマ特有ルール/マッピングを予測するために、この細かい粒状度で分析することができる。各スキーマについて抽出される特徴は、テーブル名、カラム名、テーブル型、テーブル間の外部キー、自己参照テーブル、および多くの他の特徴を含み得る。これらの抽出される特徴は、スキーマにおけるよく使用される包括的構造またはパターンを表わし、スキーマ情報を強化し、機械学習コンポーネント110のための作業を単純化することができる。
実施形態はまた、特徴抽出106によって抽出された特徴をルールインタプリタ114に提供する。たとえば、ルールインタプリタ114は、抽出された特徴を活用して、予測されたルールを解釈し、出力ETLマッピング116を生成することができる。特徴抽出106による抽出のために利用可能な特徴は、さらにここに開示されるであろう。
実施形態は、ソーススキーマ102からのデータの抽出およびターゲットスキーマ104へのデータのロードのための例示的なETLマッピング108を機械学習コンポーネント110に提供する。例示的なマッピング108は、ソーススキーマ102およびターゲットスキーマ104のデータ(たとえばテーブル)間の特定のマッピングであり得る。ETLマッピング108は(たとえば、ソーススキーマ102からターゲットスキーマ104へ移行する)特定のデータ移行タスクに特有であるため、学習コンポーネント110は、特定の移行タスクが実現されるためのETLルールを予測することができる。
実施形態は、生成された出力ETLルール112をルールインタプリタ114へ渡す。ルールインタプリタ114は、ルールを解釈して出力ETLマッピング116を生成することができる。たとえば、機械学習コンポーネント110は、1つ以上の条件文(たとえば、XおよびYである場合にはZである)の形をしたルールを生成することができ、ルールインタプリタ114は、これらのルールを解釈することによって、ソーススキーマ102とターゲットスキーマ104との間の実際のマッピングを生成することができる。実施形態は、ソーススキーマ102、ターゲットスキーマ104、および特徴抽出106からの抽出された特徴を、ルールインタプリタ114に提供する。たとえば、出力ETLルール112は、ソーススキーマ102およびターゲットスキーマ104の特定の構造に基づいて、および、これらのスキーマから抽出された特定の特徴に基づいて、出力ETLマッピング116へと解釈され得る。
いくつかの実施形態では、ソーススキーマ102とターゲットスキーマ104との間の特定のマッピングのためにETLマッピング108が提供される場合、スキーマ設計の主観的性質によってもたらされる機械学習複雑性が緩和される。たとえば、機械学習コンポーネント110に提供される特定のトレーニングデータは、ソーススキーマ102とターゲットスキーマ104との間の設計差を表わすため、機械学習コンポーネント110によって予測された出力ETLルール112は、包括的スキーマ関係トレーニングデータが使用される場合に生じ得る包括的設計差に基づくのではなく、これら特定の設計差に基づくであろう。ルールインタプリタ114は次に、これら特定のルールを使用し、スキーマ102、ターゲットスキーマ104、および特徴抽出106からの抽出された特徴を使用して、同様にソーススキーマ102およびターゲットスキーマ104に特有である出力ETLマッピングを生成することができる。実施形態によって達成される機能は、以前は人間の労力を大量に必要とした、特定のソーススキーマと特定のターゲットスキーマとの間のETLマッピングを生成するための自動化された手法である。
いくつかの実施形態では、ソーススキーマ102、ターゲットスキーマ104、特徴抽出106、例示的なETLマッピング108、機械学習コンポーネント110、出力ETLルール112、ルールインタプリタ114、および出力ETLマッピング116は、単一のシステムまたはコンピューティングデバイスによって実現され、さまざまなコンピューティングデバイスにわたって分散されてもよく、また、いくつかの実現化例では、さまざまな場所にわたって、これらの組合せが他の好適な態様で構成されてもよい。例示的な実現化例では、システム100の要素は、ソフトウェア、ハードウェア、またはこれらの組合せであり得る。
図2は、実施形態に従ったコンピュータサーバ/システム210のブロック図である。図2に示すように、システム210は、プロセッサ222およびメモリ214といった、システム210のさまざまなコンポーネント間で情報を通信するように構成されたバスデバイス212および/または他の通信メカニズムを含んでいてもよい。加えて、通信デバイス220は、ネットワーク(図示せず)を通してプロセッサ222から別のデバイスへ送信されるデータを符号化し、ネットワークを通して別のシステムから受信されたデータをプロセッサ222のために復号することによって、プロセッサ222と他のデバイスとの間の接続性を可能にしてもよい。
たとえば、通信デバイス220は、無線ネットワーク通信を提供するように構成されるネットワークインターフェイスカードを含んでいてもよい。赤外線、無線、ブルートゥース(登録商標)、Wi-Fi(登録商標)、および/またはセルラー通信を含む、さまざまな無線通信手法が使用されてもよい。それに代えて、通信デバイス220は、イーサネット(登録商標)接続などの有線ネットワーク接続を提供するように構成されてもよい。
プロセッサ222は、システム210の計算および制御機能を実行するための1つ以上の汎用または専用プロセッサを含んでいてもよい。プロセッサ222は、マイクロ処理デバイスといった単一の集積回路を含んでいてもよく、もしくは、プロセッサ222の機能を達成するために連携して作動する複数の集積回路デバイスおよび/または回路基板を含んでいてもよい。加えて、プロセッサ222は、メモリ214内に格納された、オペレーティングシステム215、学習コンポーネント216、および他のアプリケーション218といったコンピュータプログラムを実行してもよい。
システム210は、プロセッサ222による実行のための命令および情報を格納するためのメモリ214を含んでいてもよい。メモリ214は、データを検索し、提示し、修正し、格納するためのさまざまなコンポーネントを含んでいてもよい。たとえば、メモリ214は、プロセッサ222によって実行されると機能を提供するソフトウェアモジュールを格納してもよい。モジュールは、システム210のためのオペレーティングシステム機能を提供するオペレーティングシステム215を含んでいてもよい。モジュールは、オペレーティングシステム215、学習コンポーネント216、および他のアプリケーションモジュール218を含み得る。オペレーティングシステム215は、システム210のためのオペレーティングシステム機能を提供する。学習コンポーネント216は、ソーススキーマからデータを抽出し、それをターゲットスキーマにロードするETLルール/マッピングを予測するためのシステム機能を提供してもよく、または、この開示の任意の他の機能をさらに提供してもよい。いくつかの例では、学習コンポーネント216は、インメモリ構成として実現されてもよい。
非一時的メモリ214は、プロセッサ222によってアクセスされ得るさまざまなコンピュータ読取可能媒体を含んでいてもよい。たとえば、メモリ214は、ランダムアクセスメモリ(random access memory:RAM)、ダイナミックRAM(dynamic RAM:DRAM)、スタティックRAM(static RAM:SRAM)、読出専用メモリ(read only memory:ROM)、フラッシュメモリ、キャッシュメモリ、および/または任意の他のタイプの非一時的コンピュータ読取可能媒体の任意の組合せを含んでいてもよい。
プロセッサ222はさらに、バス212を介して、液晶ディスプレイ(Liquid Crystal Display:LCD)などのディスプレイ224に結合される。キーボード226とコンピュータマウスなどのカーソル制御デバイス228とがさらにバス212に結合され、ユーザがシステム210とインターフェイス接続することを可能にする。
いくつかの実施形態では、システム210は、より大きいシステムの一部であり得る。したがって、システム210は、追加の機能を含むための1つ以上の追加機能モジュール218を含んでいてもよい。他のアプリケーションモジュール218は、たとえば、運用システムを含むデータウェアハウスおよびデータウェアハウスターゲットのさまざまなコンポーネント、オラクル(登録商標)データインテグレータ(Oracle Data Integrator:ODI)、変更データキャプチャ(Change Data Capture :CDC)メカニズムおよびカフカ(Kafka)ストリームベースの処理を用いてオラクル(登録商標)ゴールデンゲート(Oracle Golden Gate)に基づいてソースシステムで変更されたデータを含み得るアパッチ・カフカ(Apache Kafka)、ならびに他の好適なコンポーネントを含んでいてもよい。データベース217がバス212に結合されて、モジュール216および218のための集中格納を提供するとともに、たとえば無線デバイス活動を、また、いくつかの実施形態では、ユーザプロファイル、トランザクション履歴などを格納する。データベース217は、論理的に関連するレコードまたはファイルの統合された集合にデータを格納することができる。データベース217は、運用データベース、分析データベース、データウェアハウス、分散型データベース、エンドユーザデータベース、外部データベース、ナビゲーションデータベース、インメモリデータベース、ドキュメント指向データベース、リアルタイムデータベース、リレーショナルデータベース、オブジェクト指向データベース、Hadoop分散ファイルシステム(Hadoop Distributed File System:HFDS)、または当該技術分野で公知の任意の他のデータベースであり得る。
単一システムとして示されているものの、システム210の機能は、分散型システムとして実現されてもよい。たとえば、メモリ214およびプロセッサ222は、集団でシステム210を表わす複数の異なるコンピュータにわたって分散されてもよい。一実施形態では、システム210は、デバイス(たとえばスマートフォン、タブレット、コンピュータなど)の一部であってもよい。
一実施形態では、システム210はデバイスから離れていてもよく、デバイスのために説明された機能を遠隔で提供してもよい。また、システム210の1つ以上のコンポーネントが含まれていなくてもよい。たとえば、ユーザまたは消費者デバイスとしての機能のために、システム210は、プロセッサとメモリとディスプレイとを含み、図2に示す他のコンポーネントのうちの1つ以上を含まず、図2に示されない追加のコンポーネントを含む、スマートフォンまたは他の無線デバイスであってもよい。
図3は、例示的な一実施形態に従ったサンプルスターデータスキーマを示す。データスキーマ300は、ファクトテーブル302と、ディメンション_1テーブル304と、ディメンション_2テーブル306と、ディメンション_3テーブル308とを含む。一般に、スタースキーマでは、ファクトテーブルは、ドメインに関するファクトを保持し、一方、ディメンションテーブルは、これらのファクトについての属性を保持する。その結果、ファクトテーブル302は、ディメンション_1テーブル304、ディメンション_2テーブル306、およびディメンション_3テーブル308とのさまざまな外部キー関係を有する。言い換えれば、ファクトテーブルにおけるロウ(行)のうちのいくつかは、外部キー(foreign key:FK)である。外部キーは、ディメンションテーブルへのリンクであり得る。ディメンションテーブルは、1つ以上のファクトテーブルによって参照されるイベントに関連付けられたコンテキストを格納するテーブルであり得る。
スターデータスキーマは、スノーフレークデータスキーマに似ているが、相違点がいくつかある。たとえば、スノーフレークデータスキーマは、複数の関連テーブルに正規化されたディメンションを含み、一方、スタースキーマは、非正規化されたディメンションを有し、各ディメンションは単一のテーブルによって表わされる。これらのスキーマの各々は、データ冗長性、問合せ設計の単純性などに関連する異なる利点を提供する。たとえば、正規化の格納効率利点は、正規化されたデータスキーマを問合せる効率とのトレードオフをもたらし得る。
図1を再度参照して、機械学習コンポーネント110は、ソーススキーマ102、ターゲットスキーマ104、および例示的なETLマッピング108の測定可能で観察可能な特性を記述する特徴を抽出するために、特徴抽出106に依拠する。特徴はドメインに特有であってもよく、ソリューションの典型的な局面のうちのいくつかをカプセル化してもよい。一般に、存在する特徴がより独立しているほど、より多くの学習が可能である。下記は、ソーススキーマ102およびターゲットスキーマ104から抽出され得るサンプル特徴である。
テーブルまたはカラム名
名前は、ソースをターゲットテーブル/カラム(列)にマッピングする際の決定源であり得る。例示的な特徴は、以下を含む:
・ソースおよびターゲットテーブル/カラム名が同一である
・フォルダ名が、接頭辞または接尾辞を有するソース/ターゲットテーブル名からなる
・マッピング名が、接頭辞または接尾辞を有するソースまたはターゲットテーブル名からなる
・マッピング名が、テーブル名の前、後、および間に固定された文字列を有するソースおよびターゲット名からなる
・マッピング名が、似た名前を有する他のカラムにおいて単調に増加する数を含む
・ソーステーブルおよびターゲットテーブルが、{1、2、3、4、それ以上}の類似性距離を有して類似している
・カラム名が文字列「UDF」で始まる
・テーブルが「_L」または「_F」で終わる
・カラム名が「EFFECTIVE_DT」である
抽出された特徴のうちのいくつかは、フレームワークの一部として定義されるであろう。また、特定のテーブルまたは接頭辞および接尾辞に関連するいくつかの特徴は、ソーススキーマおよびターゲットスキーマに基づいて作成され得る。
カラム型
カラム型は、さまざまなETLルール/マッピングを作る決定において使用されてもよい。さまざまな実施形態に従った例示的なカラム特徴は、以下のとおりである:
・ソースおよびターゲットカラム型が同一である
・ソースはターゲット型の部分型である(たとえば、ソースはVARCHAR(20)であり、ターゲット型はVARCHAR(30)である)
・ターゲットカラム型は「Date」である
・カラムは主キーに属する
・カラムは外部キー制約に属する
・カラムは、このテーブルの外部キーに属する
・カラムは「非ヌル」制約を有する
・テーブルは、NUMBERという型のカラムを、他の型より2~3倍以上有する。
テーブル関係
テーブル関係は、結合またはルックアップ条件、順序付け、およびテーブル識別を判断するために使用され得る。さまざまな実施形態に従った例示的なテーブル関係特徴は、以下のとおりである:
・テーブルは自己参照性である
・テーブルは入力外部キー制約を有する
・テーブルは出力外部キー制約を有する
・テーブルは、{1つ、2つ、それ以上の}出力外部キー制約を有する
・テーブルは、{1つ、2つ、それ以上の}入力外部キー制約を有する
・テーブルT1はテーブルT2を参照する
・テーブルT1は、T2に直接接続され、または、出力外部キーを通して間接的に接続される
・テーブルT1は、T2に直接接続され、または、X個未満の間接的関係を有して出力外部キーを通して間接的に接続される。
いくつかの状況では、設計者の意図が、根本的なスキーマから明らかではないかもしれない。ドメインの専門知識が、あるETLルール/マッピングを作る決定にとって有用かもしれない。たとえば、高度に接続されたデータモデルにおけるどのテーブルをデータセットに含めるべきかが明らかではないことが多い。いくつかの例では、テーブルおよびカラムについて、所望の挙動を可能にするために、追加のメタデータが根本的なデータベーススキーマに追加され得る。たとえば、10個のテーブルが外部キー制約を通して接続されてもよいが、それらの一部のみが、「group1」属性の同じ値を有するソースデータセットに含まれてもよい。別の例では、スキーマまたはテーブルは、割り当てられた型であってもよい。たとえば、スキーマは、ファクト、ディメンション、階層またはブリッジテーブルを有するスタースキーマであってもよい。下記は、特徴抽出中に抽出され得るあるいくつかのメタデータを示す:
・メタデータ属性Xは、値Yを有する
・メタデータ属性Xが定義されない
・テーブルT1のメタデータ属性Xの値が、テーブルT2のメタデータ属性Xの値と同一である
・テーブルT1のメタデータ属性Xの値が、テーブルT2のメタデータ属性Xの値よりも{小さい、大きい}
・メタデータ属性Xは、{ソース、ターゲット}{テーブル、カラム}Yと同じ名前を有する。
いくつかの実施形態では、メタデータは、他の入力(たとえば、ソーススキーマ102の他の構造、ターゲットスキーマ104の他の構造、他の抽出された特徴、および例示的なETLマッピング108)からは容易に通信されないであろう情報を、機械学習コンポーネント110および/またはルールインタプリタ114に提供することができる。メタデータは、特定のドメイン特有の目的に依存する、名前と値のペアとして表わされ得る。場合によっては、値は、値のリスト/配列であってもよい。
ETLジェネレータのいくつかの実現化例は、以下のメタデータのうちの1つ以上を含み得る:
・「ソーステーブル」は、1つまたは複数のソーステーブルを識別するために、ターゲットテーブルにおいて使用され得る。これは、不適切な命名規則による不整合といった曖昧さを解決するための状況で使用され得る;
・「パターン名」および「パターン参加者」は、ソーステーブルおよびターゲットテーブルのために使用され、使用されるパターン全体と、各テーブルがどの役割を果たすか(参加者)とを明確にすることができる。たとえば、これは、ETL使用事例で一般的な他の設計パターンに似た役割を果たすことができる;
・ソーステーブルおよびターゲットテーブルにおける「グループ」は、構造の範囲を定義するために使用され得る。たとえば、高度に接続されたデータベーススキーマでは、単位を定義するFK制約を通して関連したテーブルを判断することは、難易度が高い。これらの場合、グループ化を示すことは役に立つ;
・ターゲットスキーマテーブルにおける「フィルタ条件」は、情報の一部を定義するためのソーステーブルに対する条件を表わすために使用され得る。そのような条件は、ソースシステムにおけるドメイン特有の詳細によって駆動されることが多い。そのような情報を提供することは、学習アルゴリズムが条件を生成されたルールに含めることを可能にする。
いくつかの実施形態では、ターゲットETLシステムのためのいくつかの標準化されたメタデータ要素のためにデフォルト挙動を実現することが可能であり得る。上述の例は、そのような包括的要素に含められ得る。いくつかの実施形態では、メタデータは、ソーススキーマに特有の他のやり方で使用されてもよい。いくつかの実施形態では、特徴抽出106は、ソーススキーマ102およびターゲットスキーマ104から、複数の上述の例示的な特徴を抽出する。
いくつかの実施形態では、出力ETLマッピング116は、自動化スキーママッピング、または、ソーススキーマ102のターゲットスキーマ104へのマッピングの概念に関連する。この開示の実施形態で説明される手法は、スキーママッピングだけでなく、ソーステーブルからデータを抽出し、データを変換してターゲットテーブルにロードするための手順、すなわち、ETLまたはELTとして公知のプロセスを達成する。ETLソリューションを首尾よく可能にするために、スキーママッピングは、前もって起こることが多い。いくつかの実現化例では、どのソーステーブルカラムがどのターゲットテーブルカラムにマッピングされるかを判断すれば十分である。単純な場合では、整合するソーステーブルカラムとターゲットテーブルカラムとは、十分に似た名前を使用し、関連するデータ型を定義する。
実施形態は、ソーススキーマ102をターゲットスキーマ104にマッピングする例示的なETLマッピング108を提供する。例示的なETLマッピング108は、容易に分析され得る任意の形で表わされてもよく、ETL実行ファイル(たとえば、データ移行のために実行されるように構成された出力ETLマッピング116)を生成するための基盤である。たとえば、さまざまな実施形態で使用されるETL拡張マークアップ言語(extensible markup language:XML)仕様フォーマットは、ETLツールであるオラクルデータインテグレータ(ODI)からのETL XML仕様に類似し得る。いくつかの実施形態では、例示的なXML ETL仕様は、複数の部分を含み得る:
・マッピングの定義
o マッピングの名前
o ETLソフトウェアツールに位置するフォルダの名前(たとえば、論理ファイル位置)
o ソーステーブル、ならびに、ソースをフィルタリング、ルックアップ、および結合する方法。さまざまな実施形態では、ソースは、ソーススキーマおよびターゲットスキーマに存在するかもしれない
o ターゲットテーブル
o パラメータを使用して構成された抽出(たとえば、構造化問合せ言語(structured query language:SQL)またはデータベースリンク)および挿入戦略(たとえば、インクリメント、マージ、アペンド)
o 定数を含み得る各ターゲットカラムについてのマッピング式、1つまたは複数のソースカラムを用いる1対1のカラムマッピングまたは式
・変数
o 変数名
o 変数型
o 変数定義
・シーケンス
o シーケンスの名前
o シーケンスの型(たとえばDBシーケンス)
o シーケンス定義
・ETLマッピングと他のETLプリミティブ(別名パッケージ)とをオーケストレーションする方法の定義
o パッケージ名
o ETLツールに位置するフォルダの名前
o マッピングの順次または並列実行
o 変数の初期化
o 手順の実行。
XML仕様に加えて、ソースおよびターゲットデータベースモデルは、考慮するべき特徴を含む:
・ソーススキーマおよびターゲットスキーマの名前
・テーブル名およびカラム名
・カラムの型
・非ヌル制約、主キー制約、および外部キー制約
・一意インデックス。
いくつかの実施形態では、変数は、マッピングおよびETLオーケストレーション定義において参照され得る状態(数または文字列)を維持するためのETLツールのアーチファクトであり得る。いくつかの実施形態では、シーケンスは、データベース自体においてしばしば定義されるETL定義の一部であり得る。たとえば、シーケンスは、データベースのためのデータ定義言語(data definition language:DDL)スクリプトとして提供可能であり、または、別々に生成されてもよい。
さまざまな実施形態では、ソーススキーマからターゲットスキーマへのデータの抽出、変換、およびロードは、1つまたは1グループのソースが抽出され、変換され、1つまたは1グループのターゲットテーブルにロードされる1組のサブプロジェクトとして構造化される。たとえば、ETL設計は、作業単位の一部としてどのテーブルをマッピングするかを判断することと、ソースカラムとターゲットカラムとの間のマッピング式を設計することという、ほぼ独立した2つのレベルを含み得る。作業単位は、1つまたは複数のマッピングと、手順、シーケンス定義、変数定義などといったETLソリューションのためのさまざまな他の詳細とを含み得る。下記は、これら2つのレベルについての例示的なテーブルおよびカラムマッピングを提供する。
テーブルマッピング設計
テーブルレベルのETL設計は、どのソーステーブルおよびターゲットテーブルが作業単位に参加するかを考慮する。いくつかの一般的パターンが存在する:
・1対1のパターン:1つのソーステーブルが1つのターゲットテーブルにマッピングされる;
・多対1のパターン:複数のソーステーブルが1つのデータセットへと結合され、1つのターゲットテーブルにマッピングされる。これは、スタースキーマを用いて運用システムからのデータをデータウェアハウスにロードする際に一般的なシナリオである。たとえば、非正規化されたディメンションテーブルを生成するために、ディメンション階層を表わす複数のテーブルが結合される;
・1対多のパターン:1つのソーステーブルがレコードのすべてまたは一部を複数のターゲットテーブルにマッピングしてもよく、それらは、ソースカラムのすべてまたは一部を含む。この方法は、無関係なテーブル属性を別々のテーブルへと分離するために使用され得る;
・型-部分型パターン:1つのソーステーブルが複数のターゲットテーブルにマッピングされ、それらは、共通データを型テーブルへと分離し、特定の詳細を1つまたは複数の部分型テーブルへと分離する。これは、上述の1対多のパターンの特殊なケースである。型-部分型関係を有する複数のソーステーブルが1つのターゲットテーブルにマッピングされるという逆のケースも可能である;
・集計テーブルパターン:集計テーブルが典型的には、集計レベルを定義するために、測定値に対する集計関数および「group by」句を使用して、ターゲットスキーマ内で、よりきめ細かいデータを有するテーブルから導き出される。
カラムマッピング設計
カラムマッピングは、カラムの型、カラム型およびカラム名、ならびに利用可能なソースカラムに関連する多くの一般的変形を有する:
・テーブルの主キーに属しており、ソースからコピーされ、DBシーケンスを使用して作成され、またはルックアップ演算を使用して(たとえば、左外部結合を用いて)親テーブルからコピーされ得る、カラム;
・外部キーカラムは、1つの自然キーに基づいて外部キーカラムを検索するために、ルックアップが、参照されるテーブルを有するターゲットスキーマにおいて(たとえば、左外部結合を用いて)実行されることを示唆する;
・カラムは、ソーステーブルとターゲットテーブルとの間で単純に1対1でコピーされてもよい;
・カラムは、CASTなどの単純式を使用して、ターゲットカラムの型にマッピングされてもよい;
・あるシステムカラム(たとえば、データソースID、日付の更新、または挿入データ)は、一貫して命名されてもよく、同じ式を使用するであろう。
いくつかの実施形態では、1つまたは複数のソーステーブルの1つのターゲットテーブルへのマッピングは、作業単位へと編成される。単純な場合では、1つのマッピングは、フォルダまたはパッケージに存在する1作業単位である。いくつかの実現化例では、フォルダは、関連するマッピング、変数定義、シーケンス定義、または手順をグループ化するという概念であり得る。同様に、パッケージは、これらの関連するETL要素がどのシーケンスで実行されるかを定義することができる。
いくつかの実施形態では、型-部分型パターンは、ソーステーブルを型テーブルと1つまたは複数の部分型テーブルとにマッピングする複数のマッピングとして実現されてもよい。これらのマッピングは、フォルダまたはパッケージに位置する1作業単位を作成することができる。加えて、テーブル構造は、型情報を含むターゲットテーブルが最初にロードされ、他のすべてのテーブルがその後、またはおそらく並行してロードされることを必要としてもよい。
機械学習コンポーネント110に抽出された特徴と例示的なETLマッピング108とが提供された後で、新たなETLルール/マッピングが、ソーススキーマ102からのデータの抽出およびターゲットスキーマ104へのそのデータのロードのために予測され得る。いくつかの実施形態では、ソリューションフレームワークが、ソリューションのさまざまな局面を判断するために、異なるモジュールを用いて定義され得る。たとえば、これらのモジュールのうちの1つ以上は、特定のソリューションが特定のソース/ターゲットスキーマのために定義され得るように、柔軟であるよう、かつ構成可能になるよう設計され得る。いくつかの例では、決定はルールとして表わされてもよく、いくつかの例では、決定は確率または重みとして表わされる。
従来のETLジェネレータはしばしば、これらのルールをハードコード化する。いくつかのジェネレータは、ETLジェネレータフレームワークを特定の状況に適応させるために、ETLチームがルールを手動で書くかまたは構成することを可能にする。このアプローチは、従来のジェネレータと比べて著しい利点を有するものの、それは依然として著しい工数を必要とする。対照的に、さまざまな実施形態では、ETLプロセスの異なる局面について、ETLルールおよび構成が、提供された例示的なETLマッピング108を使用して自動的に(すなわち、人間の介入なしで)学習され得る。ETLルールを自動的に生成するプロセスは、複数のコンポーネントに分解されてもよく、各コンポーネントは、学習され得る決定を伴い得る。実施形態は次に、出力ETLルール112をルールインタプリタ114に提供して出力ETLマッピング116に到達させることができ、それらは、スキーマ間の移行を達成するために使用され得る。
いくつかの実施形態では、機械学習コンポーネント110は、ソーススキーマ102、ターゲットスキーマ104、および例示的なETLマッピング108から抽出された特徴に基づいて学習される局面を有し得る複数のモジュールを含み得る。たとえば、学習は、例示的なETLマッピング108から観察されるETLソリューションの局面を判断するスキーマ、テーブル、およびカラム特徴の組合せを学習する教師あり学習アルゴリズムを使用して達成され得る。
多くの点で、学習は、全般的または包括的ではない。たとえば、(たとえばサンプルETLマッピング108を提供する)ETLソリューションの設計者は、提供された例(および、いくつかの例では提供されたメタデータ)に基づいて、学習を、1つまたは複数の学習手法を使用して特定の問題に適合するように調整することができる。
いくつかの実施形態では、ETLルールの学習に先立って、さまざまな準備が実行され得る。たとえば、テーブルは、ロウのデータソース、初期ロードの日時、最終更新の日時、レコードを最後に更新した人のユーザIDなどといった、演算データを取込むことができる。これらのカラムは典型的には、すべてのまたは大抵のテーブルが所有するシステムカラムである。場合によっては、テーブルのグループが共通のカラムを定義してもよく、それは、共有設計の表示である。例は、型-部分型パターンのための型カラム、バージョンレコードのための有効日および現在のフラグカラム、または、階層を示す包括的LVL<n>カラムである。スキーマで頻繁に使用されるカラムは、追加のETLルールを予測するために機械学習コンポーネント110による学習中に使用され得る追加の特徴(たとえば「isCommonColumnType_x」)へと変換され得る。
別の例では、スキーマの構造に関する情報を追加の特徴として導き出すことは、学習を支援することができる。従来の1つの相違は、高度に正規化された運用スキーマと、非正規化されスター型に編成された報告スキーマとの間にある(たとえば、スノーフレークスキーマ対スタースキーマ)。この判断は典型的には、スキーマがスターからなるか否かを判断できるアルゴリズムを用いて下され得る。そのような判断を下す例示的なアルゴリズムは、「物理データベーステーブルおよびメタデータからの論理データベーススキーマの自動生成」(AUTOMATIC GENERATION OF LOGICAL DATABASE SCHEMAS FROM PHYSICAL DATABASE TABLES AND METADATA)と題された、マイケル・サッシン(Michael Sassin)への米国特許出願公開第2016/0078064号において提供される。
関連するアルゴリズムは、スタースキーマテーブルを、ファクト、ディメンション、階層、ブリッジテーブル、ルックアップテーブルなどとして分類することができる。大抵の場合、アルゴリズムは、これらの判断を下すために外部キー制約を使用することができる。命名規則、および、カラムにおけるあるカラムまたはデータ型の出現、もしくは、NUMBERという型およびnumberでない型のカラム間の比率も、学習されてもよい。
いくつかの実施形態では、この種の学習を実行するために、予め分類されたテーブル型を有するスタースキーマのより大きいデータセットが提供され得る。正規化されたスキーマテーブルも、同様の手法を使用して分類されてもよい。実現化例のうちのいくつかでは、目標は、モデルパターンまたは設計原型を識別することであってもよい。他の実施形態では、この情報は、メタデータとして提供されてもよく、または、他の態様でシステムの学習コンポーネントにとって利用可能になってもよい。
いくつかの実施形態では、ETLマッピングは、作業単位として生成される。たとえば、スキーママッピングアルゴリズムによって判断されるカラムマッピングに基づいてテーブルを識別するための手法が、以前に開示されている。いくつかの実施形態では、スキーママッピングによって定義された作業単位は、例示的なETLマッピング108によって定義された作業単位に基づいている。
いくつかの実施形態では、ETLソリューションのための作業単位が分類され得る。各作業単位は、特定のコンテキストにおける類似した問題への再使用可能なソリューションを提供する、以前に開示されたソリューションパターンに従ってもよい。データの非正規化、型-部分型パターンのマッピングなどのために、複数のソリューションパターンが確立される。分類は、導き出された追加の特徴として役に立ち得る。なぜなら、それは、より複雑なルールのためのショートカットになり得るためである。いくつかの実施形態では、作業単位のパターンを予測するために、アルゴリズムが使用される。パターン名はメタデータとして、機械学習コンポーネント110に供給され得る。
いくつかの実施形態では、学習アルゴリズムは、分類アルゴリズムまたはルール学習アルゴリズムとして実現され得る。いくつかの例では、例による学習は、複雑な決定を学習しようとする際に課題に直面する場合がある。実施形態はまた、達成された学習に基づいてユーザが入力(たとえば選択)を提供するように促される教師あり実現化例を含み得る。例示的なアプローチが、S.ボシオネク(Bocionek)およびM.サッシン、「適応インターフェイスエージェントおよびプログラミング・バイ・デモンストレーション・システムのためのダイアログベースの学習」(Dialog-Based Learning (DBL) for Adaptive Interface Agents and Programming-by-Demonstration Systems)、テクニカルリポート(Technical Report)CMU-CS-93-175、カーネギーメロン大学(Carnegie Mellon University)、1993年7月、でさらに説明される。
作業単位を学習する際、結合条件はしばしば、スタースキーマまたは任意の他の好適なスキーマなどからデータセットを抽出するように要求される。たとえば、テーブルは、テーブル間の外部キー制約によって定義されたカラムを利用する条件を使用して結合され得る。結合は、外部キーカラムの非ヌル制約に依存して、内部または外部結合であってもよい。いくつかの実施形態では、この標準アプローチの変形は、参加するテーブルの特徴(たとえば、結合に参加するカラムは、代替キー、インデックスのカラムであること、または、固定された名前を単純に有することなど)に基づいて学習されてもよい。
作業単位を学習する際、マッピング式も、ソーススキーマ102とターゲットスキーマ104との間で学習される。マッピング式は、以下を含む複数の広範なカテゴリに該当し得る:
・主キーカラムのマッピング
・外部キーカラムのマッピング
・コードカラムのマッピング
・システムカラム
・他のカラム。
いくつかの実施形態では、主キーカラムは、既存の主キーカラムを検索するために代理キーを使用して、または(外部キーを介して)親テーブルをルックアップすることによって作成される。たとえば、そのような判断を下すために、ターゲットマッピング式が分析され得る。代理キーの値はデータベースシーケンスとして定義されてもよく、それは、ターゲットマッピング式にあってもよい。自然キーが使用される場合、式は、ターゲットマッピング式におけるソーステーブルの主キーカラムを定義することができる。
いくつかの実施形態では、ソーススキーマ102における外部キーカラムは、ソーススキーマ102における親テーブルの値をルックアップするために使用される。コードカラムは、ルックアップ演算を使用して同様の態様で外部キーカラムとして変換される。これらの例では、学習されないもののETLフレームワークによって提供される、安定した1組のルックアップまたは作成パターンが存在する。
たとえば、関連する式が、例示的なETLマッピング108によって定義され得る。たとえば、ディメンションテーブルをスタースキーマにロードする際、一般的パターンが使用され得る。ディメンションテーブルは、代理キーを主キーとして定義し、ソースシステムから生じる自然キーをルックアップキーとして提供することができる。いくつかの例では、ディメンションテーブルは、ディメンションロウがすでにロードされたかどうかを判断するために自然キーを使用するルックアップとして機能することができ、その場合、新たに到着するデータは、ディメンションの更新をトリガする変更レコードと考えられる。ディメンションをロードまたは更新するためのカラムおよびアクションおよび/またはシーケンスといった特定の詳細は、実現化例に基づいて異なり得る。ETLルールの各インスタンスについて、ソーステーブルおよびターゲットテーブルにおける参加カラムが識別され、それらの選択に関連付けられたルールが学習され得る。
たとえば、テーブルSがターゲットテーブルTにマッピングされ、それは、親テーブルT2との外部キー関係を有する、と仮定する。外部キーカラムをTに代入するために、ソーステーブルSは、T2でも利用可能である、当該関係のための1つまたは複数の自然キーカラムを有するべきである。いくつかの実施形態では、学習アルゴリズムは、例示的なETLマッピング108で使用されるカラムのために(たとえば、特徴抽出106によって抽出された)抽出特徴を使用して、外部カラム名に関する規則を学習することができる。大抵の場合、命名規則において、何らかのレベルの規則性が使用される(たとえば、名前は、親テーブルの名前を使用し、同じ接頭辞または接尾辞を使用する)。ソーステーブルまたはターゲットテーブルのいずれかが、特徴によって表わされ得る規則に従っていないいくつかの場合、カラムレベルのメタデータが、スキーマを補足するために追加され得る。
いくつかの実施形態では、符号化された値のルックアップは、外部キールックアップに関する場合と類似したルールに従う。潜在的な相違は、ロウのキーカラムではなく、マッピングされた値が検索されることである。他の点では、コードカラムは、キーカラムと類似したプロセスに従い得る。
いくつかの実施形態では、システムカラムも同様に、定数名を有するソース値をコピーすること、提供されたアイデンティティ(たとえば、最後に更新されたユーザについてのユーザID)に基づいて関数(たとえばsystem time)、定数(たとえば、CURRENT_FLGは「Y」に設定される)、またはルックアップをテーブルに挿入すること、といったルールに従う。これらのルールは、例示的なETLマッピング108に基づいて学習され得る。
いくつかの実施形態では、上述のカテゴリのうちの1つに該当しない他のカラムが存在するかもしれない。多くの場合、これらのカラムは、ソースカラムから1対1でマッピングされ得る(たとえば、データは単純にターゲットカラムへ渡される)。一般的変形は、ヌル値についてソースデータがチェックされ、デフォルト値が供給されること、または、ソースカラムが切り捨てられるかまたは異なる型にはめられることである。これらのルールは、例示的なETLマッピング108に基づいて再び学習され得る。
いくつかの実現化例では、いくつかのETLルール/マッピングは複雑であるかもしれず、よって、例に基づく学習環境を助長しないかもしれない。これらの例では、複雑なルール/マッピングは学習システムによってスキップされてもよく、ユーザは、最終的なETLソリューションを達成するためにルール/マッピングを手動で生成してもよい。言い換えれば、ソーススキーマとターゲットスキーマとの間の複雑なルールおよび/またはマッピングを含むいくつかの実施形態は、自動化ルールおよびマッピング生成と手動ルールおよびマッピング生成との混合物に依拠し得る。
ソーススキーマ、ターゲットスキーマ、例示的なETLマッピング、および学習されたETLルールを含む使用事例が考慮される。たとえば、付録は、(親スキーマおよび子スキーマを用いて)ソーススキーマおよびターゲットスキーマを生成するために使用されるSQLを含む。ソーススキーマの一実現化例は、データウェアハウスステージングスキーマであり得る。ターゲットスキーマの一実現化例は、変更レコードを有する3NF企業データウェアハウススキーマであり得る。
実施形態は、1つのソーステーブルが1つ以上のターゲットテーブルをロードするために使用される場合に、ETLルールおよび/またはマッピングを実現することができる。自然キーおよびバージョン番号を使用してスキーマのための外部キーをルックアップするために、レコードバージョニングが使用され得る。フィルタ条件を含むメタデータ要素が提供され得る。ソーススキーマおよびターゲットスキーマのためのシステムカラムのために、一般的なマッピング式が使用され得る。いくつかの例示的なETLマッピングは、単純な1対1のカラムマッピングを含む。
いくつかの実現化例では、ソーススキーマおよびターゲットスキーマは、500個を超えるテーブルを含み得る。そのようなETLプロジェクトは、手動で実行するために著しい人手、時間(たとえば数年)、およびリソースを要し得る。しかしながら、多くのマッピングは、少数のETLパターンによって特徴付けられ得る(たとえば、マッピングの90%は、2つまたは3つのETLパターンによって特徴付けられ得る)。いくつかの実現化例では、複雑性が低い約100個のルールが、実施形態によって学習され得る。考慮された使用事例では、ソーススキーマおよびターゲットスキーマは、定義された命名規則に従う。
例示的なETLシステムのコンポーネントは、ETLツールと、ETL仕様と、ETLトランスレータと、ETLジェネレータと、ルールインタプリタ(たとえば、図1のルールインタプリタ114に類似)と、学習コンポーネント(たとえば、図1の学習コンポーネント110に類似)とを含む。所与の実現化例では、ルールは、関連付けられた式を用いる決定および条件であり得る。場合によっては、テンプレートまたはテンプレートの一部が、ルールにリンクされ得る。
ETLツールの実施形態は、ETLコンポーネントおよびマッピングを表わすことができる。たとえば、ETLツールは、定義を、ソースシステムおよびターゲットシステムに対して実行される実行ファイルに変換することができる。オラクル(登録商標)データインテグレータ(ODI)というETLツールは、いくつかの実現化例で使用される一例であり得る。ETL仕様の一実現化例は、ETLソリューションを特定する人間読取可能および機械読取可能テキストフォーマット定義であり得る。いくつかの実施形態では、ETL仕様は、ターゲットETLシステムからほぼ独立している。例示的なETL仕様は、オラクル(登録商標)データウェアハウスファクトリーETLトランスレータ(Data Warehouse Factory ETL Translator:DWF ETL)によって使用されるETL仕様を含む。
図4は、一実施形態に従った例示的なETL仕様を示す。仕様400は、フォルダ名およびアーチファクト名;ソーステーブルおよびターゲットテーブルの参照;フィルタ、結合、ルックアップ、統合、および集計;ターゲットカラムおよびそれらのための式;データをテーブルから抽出/テーブルにロードする方法に関する追加命令などのうちの1つ以上についての定義を含み得る。仕様400はXMLフォーマットで定義されるが、任意の他の好適なフォーマット(たとえば、JavaScript(登録商標)オブジェクト表記法(JavaScript Object Notation:JSON)、YAML Ain't Markup Language(YAML)、プレーンテキストなど)が実現され得る。
ETLトランスレータの実施形態は、ETL仕様を、ターゲットETLツールによって使用される定義に変換することができる。例示的なトランスレータは、ODI定義を生成するためにDWF ETLによって実現される。ETLジェネレータの実施形態は、典型的にはソーステーブルおよびターゲットテーブルの定義から、ETL仕様を生成することができる。たとえば、生成されたETL仕様は、導き出されたメタデータ、ソーススキーマおよび/またはターゲットスキーマから抽出された特徴、ならびに/もしくは、明示的なメタデータに基づき得る。いくつかの実現化例では、ETL仕様は、たとえば、自動生成、手動生成、またはこれらの組合せに基づいて提供され得る。
学習コンポーネントの実施形態は、ETLフレームワーク(たとえば、ETL仕様、および他のETL構成)ならびにETLジェネレータのコンテキストにおいて特定の決定を定義することができる。図1の機械学習コンポーネント110を参照して開示されたように、学習コンポーネントは、例示的なETLマッピングに基づいてETLルールを生成することができる。この考慮された使用事例では、例示的なETLマッピングは、ETL仕様定義および/またはスキーマメタデータとして表わされ得る。学習は、スキーマのデータの異なるルール/マッピング/グループに特有であり得る。いくつかの実施形態では、学習コンポーネントは、データの異なるルール/マッピング/グループのために特定の学習タスクを実行する(および、特定の機械予測を行なう)ように各々構成された複数の機械学習アルゴリズムを実現するように構成され得る。
実施形態は、ソーススキーマとターゲットスキーマとの間のスキーママッピングの一部を生成するために機械学習を活用することを含む。たとえば、学習コンポーネントに提供された例示的なETLマッピングに基づいて、マッピングの一部が学習され予測され得る。いくつかの実現化例では、その一部は、ソーススキーマからの大きい割合のデータ(たとえば、テーブル/カラムの90%)であり得る。いくつかの実現化例は、総合的な1組を生成するために手動マッピングを活用することを含む。いくつかの実施形態では、学習コンポーネントが総合的な1組のマッピングを生成することを可能にするために、十分な例示的なETLマッピングが提供され得る。
学習コンポーネントによって実行されるETL学習の局面は、ETLソリューションの詳細を含む。図5は、一実施形態に従ったETLツール(たとえばODI)のフォルダ構造を示す。構造500は、マッピングおよび他のETL手順において使用されるODIフォルダおよび/またはサブフォルダの名前であり得るフォルダ502を含む。フォルダ命名方式の実施形態は、定数(たとえば、フォルダ502の要素によって示されるような「LOAD_DI_HDWF…」)を含んでいてもよく、および/または、ソース/ターゲットテーブルの名前を含んでいてもよい。構造500はまた、ETL要素504を含んでいてもよく、それらはパッケージ、マッピング、および手順であり得る。これらのETL要素504も、ソース/ターゲットテーブルの名前を含んでいてもよい。マッピングはしばしば、マッピングに関連するソーステーブルまたはターゲットテーブルに基づいてグループ化され得る。
図6は、一実施形態に従ったマッピング構造を示す。たとえば、マッピング構造600は、所与のマッピングにおいて使用されるテーブル602を含む。これらのテーブルはしばしば、ETLについての「パターン」において定義される。テーブルは、マッピング構造内で外部キーを介して参照され得る。フィルタ604がテーブル602に適用され、たとえばソーステーブルに適用され得る。例示的なフィルタ機能性は、ルール/条件に基づくロウフィルタリングおよびカラムフィルタリングを含み得る。フィルタ(たとえば、フィルタについてのルール/条件)が、メタデータを通して供給され、または、他のメカニズムを通して提供され得る。フィルタリング機能性は、ETLプロセスフローにおけるデータ操作および/または変換段階の一部であり得る。たとえば、フィルタ604は、ソースデータテーブルからのソースデータをターゲットデータテーブルにマッピングするための関連するマッピングにおいて使用されるデータ操作を表わし得る。
実施形態は、データ(たとえばソースデータ)を操作、変換、および/またはフィルタリングするために結合を実行することを含む。結合は、外部キー制約を使用して実行され得る。ルックアップ606は、マッピング構造における関連するターゲットデータテーブルへの参照であり得る。ルックアップ606は同様に、外部キー制約に基づいて定義され得る。マッピング構造600は、さまざまな実施形態に従った、ソーススキーマとターゲットスキーマとの間のマッピングのための構造を表わし得る。
図7は、一実施形態に従ったマッピング式を示す。たとえば、構造700は、マッピング式702、704、706、および708を含む。マッピング式は、(たとえばデータテーブルからの)ソースデータをターゲット属性およびデータテーブルにマッピングすることができる。いくつかの例では、マッピング式704によって示されるように、ソースカラムが、似た名前を有するターゲットカラムにマッピングされ得る。いくつかの例では、マッピング式708において示されるように、sysdateなどのシステム関数が、マッピング式において使用され得る。
いくつかの例では、マッピング式702において示されるように、「:」または「#」で始まる文字列を取り込む変数などの変数が、マッピング式において使用され得る。いくつかの例では、マッピング式706において示されるように、CAST、NVL、または何らかの他のカスタム関数などの関数が、カラムを包むために使用され得る。実施形態はまた、SUM、AVG、Group Byなどの集計関数をマッピング式内に含む。
考慮された使用事例と付録で開示されたソーススキーマおよびターゲットスキーマとを参照して、実現された学習コンポーネントは、(以下にさらに開示される)ソーススキーマ、ターゲットスキーマ、抽出された特徴、および例示的なマッピングに基づいて、データにおける多くの傾向を学習することができる。テーブルにおけるシステムカラムは、ソーステーブルおよびターゲットテーブルにおいて系統的に使用され得る。たとえば、データレコードが追加、更新、または削除されてもよく、ユーザが作成および更新されてもよく、フラグ機能性が一貫していてもよい。
学習コンポーネントの実施形態は、著しい数のソースおよび/またはターゲットテーブルに生じる、同じ名前を有するカラムについての式を学習することができる。状況によっては、カラムマッピングは、(たとえば、型に基づいて)カラム名ごとに1つまたはいくつかの変形を定義することができる。学習コンポーネントは、この変形のための基準を具体的に判断することができる。
実施形態は、学習コンポーネントをトレーニングするためにデータを選択することを含み得る。たとえば、例示的なETLマッピングにわたって同じターゲットカラムへのマッピングを選択することは、いくつかの実現化例について学習成果を改良することができる。カラムマッピングに対する決定は、参加カラムに直接関連するメタデータに基づいて実行されてもよく、メタデータは、ある状況では、カラムのテーブルについてのメタデータを含むように、たとえば、名前またはパターン型などの情報を含むように拡張され得る。考慮された使用事例についての例示的なカラムメタデータは、名前、接頭辞または接尾辞などの名前に関連する特徴、コラムデータ型、付加的に追加されたメタデータ要素などを含む。
図8は、例示的な一実施形態に従ったサンプル属性ベクトルを示す。たとえば、属性ベクトル800は、考慮された使用事例に関連するソーススキーマ、ターゲットスキーマ、および抽出された特徴のデータを含み得る。カラム802はソースカラム属性を示し、一方、カラム804はターゲットカラム属性を示す。特徴806は、関連するカラム名についての接頭辞および接尾辞といった、ソーススキーマからの抽出された特徴を示す。マッピング式808は、たとえば学習コンポーネントによって学習されるマッピング式を示す。
一実施形態では、使用事例において、複数の例示的なマッピング式が、学習コンポーネントに提供され得る。例示的なマッピング式「trg.update_date = src.update」は、使用事例データ(たとえば、付録からのソーススキーマおよびターゲットスキーマ)において5回の出現を有する。加えて、例示的なマッピング式「trg.update_date = CAST(src.update, DATE)」は、使用事例データにおいて4回の出現を有する。ソースカラムupdate_dateは、例示的なマッピングの第1の組においてDateという型を使用し、例示的なマッピングの第2の組においてTimestampという型を使用する。したがって、第2の組の例についてのマッピング式において、CAST関数が使用される。示された使用事例では、学習コンポーネントの目標は、同様のマッピング式がいつあてはまるかを学習すること、および、適切な状況でこれらのマッピング式のうちの1つ(たとえば、CASTまたはそれ以外)を選ぶことであり得る。
学習コンポーネントの実施形態は、所望の学習/予測を達成するために、ID3決定木学習アルゴリズムまたは任意の他の好適な学習アルゴリズムを実現することができる。たとえば、学習コンポーネントは、以下のロジックを学習することができる。
Figure 0007419244000001
例示的な使用事例では、学習コンポーネントの実施形態は、システムカラムtrg.update_dtについてのマッピングを学習/予測することができる。この学習/予測は、学習コンポーネントに提供された類似する例示的なマッピング(たとえば、上述の「trg.update」および「srcupdate」についてのマッピング式)に基づき得る。加えて、使用事例では、実施形態は、「CAST」関数を用いるマッピング式をいつ選択するべきか、および他のマッピング式をいつ選択するべきかを判断するために、ロジックを学習/予測することができる。学習されたマッピング式についてのロジックは、提供された例示的なマッピング式におけるロジックと同様である。すなわち、データ型がTimestampである場合、CASTが使用される。同様に、他の使用事例は、ソーススキーマとターゲットスキーマとの間のパターンを示す他の例示的なマッピング式を提供することができ、学習コンポーネントは、ETLルールを予測するために、同様のマッピング式をいつ、どのようにデータの他の局面に適用するべきかを学習することができる。
使用事例を考慮して、学習されたETLルールは、ルールインタプリタによって解釈され得る。たとえば、ルールインタプリタは、上述の学習されたロジックを解釈し、ソーススキーマ、ターゲットスキーマ、および抽出された特徴に基づいて、ルール(および表わされたロジック)に従ったETLマッピングを生成することができる。特に、ETLマッピングは、trg.update_dtカラムについて生成され得る。生成されたマッピングは次に、ETLソリューションにおいて使用されてもよく、最終的には、ソーススキーマからターゲットスキーマへのデータ移行を達成するために使用されてもよい。
実施形態では従来のETLが考慮されているが、ストリーム処理ETLも実現され得る。たとえば、さまざまな実現化例ではアパッチ・カフカが含まれていてもよく、その場合、カフカ・ストリーム(Kafka Streams)アプリケーションプログラミングインターフェイス(Application Programming Interface:API)、アパッチ・ストーム(Apache Storm)、アパッチ・スパーク(Apache Spark)、アパッチ・サムザ(Apache Samza)といったさまざまなストリーム処理フレームワークによって、メッセージストリームが消費され得る。いくつかの実施形態では、開示されたさまざまなソリューションを達成するために、バッチ処理ではなく、ストリーム処理が実現され得る。
図9は、例示的な一実施形態に従った、例によって抽出、変換、およびロードルールを学習するための例示的な機能性を示す。一実施形態では、以下の図9の機能は、メモリまたは他のコンピュータ読取可能媒体または有形媒体に格納され、プロセッサによって実行されるソフトウェアによって実現される。他の実施形態では、各機能は、ハードウェアによって(たとえば、特定用途向け集積回路(application specific integrated circuit:ASIC)、プログラマブルゲートアレイ(programmable gate array:PGA)、フィールドプログラマブルゲートアレイ(field programmable gate array:FPGA)などの使用を通して)、または、ハードウェアとソフトウェアとの任意の組合せによって実行されてもよい。
902で、複数の特徴が、ソーススキーマおよびターゲットスキーマから抽出され得る。特徴は、ソーススキーマおよびターゲットスキーマの複数のテーブルのカラムを少なくとも含む。いくつかの実施形態では、特徴はさらに、カラムについての識別子、カラムについてのメタデータ、テーブルについての外部キー、および他の好適な特徴を含み得る。いくつかの例では、ソーススキーマにおけるカラムについてのメタデータは、そのカラムとソーススキーマの他のカラム/テーブルとの間の関係を示すことができ、または、他の好適なデータ関係を示すことができる。
904で、例示的なETLマッピングが、機械学習アルゴリズムに提供され得る。例示的なETLマッピングは、ソーススキーマの1つ以上のテーブルからデータを抽出し、抽出されたデータをターゲットスキーマの1つ以上のテーブルにロードするための定義である。例示的なETLマッピングは、ソーステーブルの1つ以上のソースカラムとターゲットテーブルのターゲットカラムとの間の関係を定義するマッピング式であり得る。
いくつかの実施形態では、例示的なETLマッピングは、カラム名接尾辞またはカラム名接頭辞のうちの少なくとも1つを実装するマッピング式を含み得る。いくつかの実施形態では、例示的なETLマッピングは、マッピング式のソースカラムに適用される1つ以上の関数を実装するマッピング式を含み得る。
906で、機械学習アルゴリズムを使用し、ソーススキーマ、ターゲットスキーマ、および抽出された特徴に基づいて、1つ以上のETLルールが予測され得る。1つ以上のETLルールは、ソーススキーマからデータを抽出し、抽出されたデータをターゲットスキーマにロードするためのロジックを定義する。いくつかの実施形態では、予測されたETLルールは、例示的なETLマッピングによって表わされるロジックを定義し得る。
一実施形態では、例示的なETLマッピングは、ソーススキーマとターゲットスキーマの第1の組のカラムとの間の関係を表わす。予測されたETLルールは、ソーススキーマとターゲットスキーマの第2の組のカラムとの間の関係についてのロジックを定義することができ、第2の組のカラムは第1の組のカラムとは異なっている。一実施形態では、追加のETLマッピングは、予測されたETLルールに基づいた、ターゲットスキーマの第2の組のカラムについてのマッピング式を含む。
908で、予測されたETLルールは解釈され得る。たとえば、ソーススキーマとターゲットスキーマとの間のマッピング式を生成するために、ルールインタプリタが、ETLルールで定義されたロジックを解釈することができる。解釈は、ソーススキーマ、ターゲットスキーマ、および抽出された特徴に基づき得る。いくつかの実施形態では、ETLソリューションの詳細を定義するETL仕様が実現され、解釈はETL仕様に基づき得る。
910で、予測されたETLルール、ソーススキーマ、ターゲットスキーマ、および抽出された特徴に基づいて、追加のETLマッピングが生成され得る。追加のETLマッピングは、ソーススキーマの1つ以上のテーブルからデータを抽出し、抽出されたデータをターゲットスキーマの1つ以上のテーブルにロードするための追加の定義を提供する。たとえば、追加のETLマッピングを生成するために、ルールインタプリタが使用され得る。いくつかの実施形態では、追加のETLマッピングは、ソーステーブルの1つ以上のソースカラムとターゲットテーブルのターゲットカラムとの間の関係を定義するマッピング式を含み得る。
一実施形態では、例示的なETLマッピングは、ターゲットスキーマの第1のカラムをロードするためにソーススキーマのカラムに適用される第1の型の関数を実装するマッピング式を含み得る。追加のETLマッピングは、ターゲットスキーマの第2のカラムをロードするためにソーススキーマのカラムに適用される第1の型の関数を実装するマッピング式を含み得る。
実施形態は、例によって抽出、変換、およびロードマッピングを学習する。ソーススキーマとターゲットスキーマとの間の関係は複雑であることが多く、このため、ETLのための機械学習アプリケーションを難しくする。実施形態は、改良された学習を可能にする、機械学習アルゴリズムに粒状レベルのデータ点を提供するソースデータスキーマおよびターゲットデータスキーマのための特徴抽出を活用する。また、ソースデータスキーマとターゲットデータスキーマとの間の例示的なマッピングが、ETLフレームワークに従って定義される機械学習アルゴリズムに提供される。その結果、機械学習アルゴリズムは、例においてターゲットスキーマとソーススキーマとの間に示された関係に基づいて、傾向を推定することができる。これらの推定された傾向は、スキーマに特有の粒状レベルで定義されるため、機械予測を助長する詳細なレベルで定義され得る。続いて、機械学習アルゴリズムは、ソースからターゲットへのデータの移行を達成するために使用され得る新たなETLルールを予測することができる。次に、ルールインタプリタが、予測された新たなETLルールに基づいてETLマッピングを生成するために活用され得る。
この明細書全体にわたって説明されたこの開示の特徴、構造、または特性は、1つ以上の実施形態において任意の好適な態様で組合されてもよい。たとえば、この明細書全体にわたる「一実施形態」、「いくつかの実施形態」、「ある実施形態」、または他の同様の文言の使用は、その実施形態に関連して説明された特定の特徴、構造、または特性が、本開示の少なくとも1つの実施形態に含まれ得るという事実を指す。このため、この明細書全体にわたる「一実施形態」、「いくつかの実施形態」、「ある実施形態」という句、または他の同様の文言の出現は、必ずしもすべてが同じグループの実施形態を指すとは限らず、説明された特徴、構造、または特性は、1つ以上の実施形態において任意の好適な態様で組合されてもよい。
当業者であれば、上述されたような実施形態は、異なる順序のステップを用いて、および/または、開示されるものとは異なる構成における要素を用いて実践され得る、ということを容易に理解するであろう。したがって、この開示は概説された実施形態を考慮しているが、ある変更、変形、および代替構造が、この開示の精神および範囲内にとどまりながら明らかであろう、ということが、当業者には明らかであろう。したがって、この開示の境界を判断するために、添付された請求項を参照するべきである。
付録:
ソーステーブル:
Figure 0007419244000002
Figure 0007419244000003
Figure 0007419244000004
Figure 0007419244000005
Figure 0007419244000006
Figure 0007419244000007
ターゲットテーブル-親:
Figure 0007419244000008
Figure 0007419244000009
Figure 0007419244000010
Figure 0007419244000011
ターゲットテーブル-子:
Figure 0007419244000012
Figure 0007419244000013

Claims (14)

  1. 出、変換、およびロード(ETL)マッピングを学習するためのプロセッサが実施する方法であって、前記方法は、
    ソーススキーマおよびターゲットスキーマから複数の特徴を抽出するステップを含み、前記特徴は、前記ソーススキーマおよび前記ターゲットスキーマの複数のテーブルのカラムを少なくとも含み、前記方法はさらに、
    TLマッピングを機械学習アルゴリズムに提供するステップを含み、前記TLマッピングは、前記ソーススキーマの1つ以上のテーブルからデータを抽出し、抽出された前記データを前記ターゲットスキーマの1つ以上のテーブルにロードするための定義を含み、前記方法はさらに、
    前記機械学習アルゴリズムを使用し、前記ソーススキーマ、前記ターゲットスキーマ、および抽出された前記特徴に基づいて、1つ以上のETLルールを予測するステップを含み、前記1つ以上のETLルールは、前記ソーススキーマからデータを抽出し、抽出された前記データを前記ターゲットスキーマにロードするためのロジックを定義し、前記方法はさらに、
    予測された前記ETLルール、前記ソーススキーマ、前記ターゲットスキーマ、および抽出された前記特徴に基づいて、追加のETLマッピングを生成するステップを含み、前記追加のETLマッピングは、前記ソーススキーマの1つ以上のテーブルからデータを抽出し、抽出された前記データを前記ターゲットスキーマの1つ以上のテーブルにロードするための追加の定義を提供する、方法。
  2. 記ETLマッピングおよび前記追加のETLマッピングは、ソーステーブルの1つ以上のソースカラムとターゲットテーブルのターゲットカラムとの間の関係を定義するマッピング式を含む、請求項1に記載の方法。
  3. 記ETLマッピングは、カラム名接尾辞またはカラム名接頭辞のうちの少なくとも1つを実装するマッピング式を含む、請求項1に記載の方法。
  4. 記ETLマッピングは、マッピング式のソースカラムに適用される1つ以上の関数を実装するマッピング式を含む、請求項1に記載の方法。
  5. 記ETLマッピングは、前記ターゲットスキーマの第1のカラムにデータをロードするために前記ソーススキーマのカラムのデータに適用される第1の型の関数を実装するマッピング式を含み、
    前記追加のETLマッピングは、前記ターゲットスキーマの第2のカラムにデータをロードするために前記ソーススキーマの前記カラムのデータに適用される前記第1の型の関数を実装するマッピング式を含む、請求項4に記載の方法。
  6. 予測された前記ETLルールは、前記ETLマッピングによって表わされるロジックを定義する、請求項1から5のいずれか1項に記載の方法。
  7. 記ETLマッピングは、前記ソーススキーマと前記ターゲットスキーマの第1の組のカラムとの間の関係を表わし、
    予測された前記ETLルールは、前記ソーススキーマと前記ターゲットスキーマの第2の組のカラムとの間の関係についてのロジックを定義し、前記第2の組のカラムは前記第1の組のカラムとは異なっている、請求項6に記載の方法。
  8. 前記追加のETLマッピングは、予測された前記ETLルールに基づいた、前記ターゲットスキーマの前記第2の組のカラムについてのマッピング式を含む、請求項7に記載の方法。
  9. 前記複数の特徴は、前記ソーススキーマおよび前記ターゲットスキーマのテーブルについての外部キーを含む、請求項1から8のいずれか1項に記載の方法。
  10. 前記複数の特徴は、前記ソーススキーマのカラムについてのメタデータを含み、前記メタデータは、前記ソーススキーマのカラム間の関係を示す、請求項1から9のいずれか1項に記載の方法。
  11. 請求項1~10のいずれか1項に記載の方法をプロセッサに実行させるプログラム。
  12. システムであって、
    メモリデバイスと通信している処理デバイスを含み、前記処理デバイスは抽出、変換、およびロード(ETL)マッピングを学習するように構成され、前記学習することは、
    ソーススキーマおよびターゲットスキーマから複数の特徴を抽出することを含み、前記特徴は、前記ソーススキーマおよび前記ターゲットスキーマの複数のテーブルのカラムを少なくとも含み、前記学習することはさらに、
    TLマッピングを機械学習アルゴリズムに提供することを含み、前記ETLマッピングは、前記ソーススキーマの1つ以上のテーブルからデータを抽出し、抽出された前記データを前記ターゲットスキーマの1つ以上のテーブルにロードするための定義を含み、前記学習することはさらに、
    前記機械学習アルゴリズムを使用し、前記ソーススキーマ、前記ターゲットスキーマ、および抽出された前記特徴に基づいて、1つ以上のETLルールを予測することを含み、前記1つ以上のETLルールは、前記ソーススキーマからデータを抽出し、抽出された前記データを前記ターゲットスキーマにロードするためのロジックを定義し、前記学習することはさらに、
    予測された前記ETLルール、前記ソーススキーマ、前記ターゲットスキーマ、および抽出された前記特徴に基づいて、追加のETLマッピングを生成することを含み、前記追加のETLマッピングは、前記ソーススキーマの1つ以上のテーブルからデータを抽出し、抽出された前記データを前記ターゲットスキーマの1つ以上のテーブルにロードするための追加の定義を提供する、システム。
  13. 記ETLマッピングは、マッピング式のソースカラムに適用される1つ以上の関数を実装するマッピング式を含む、請求項12に記載のシステム。
  14. 記ETLマッピングは、前記ターゲットスキーマの第1のカラムにデータをロードするために前記ソーススキーマのカラムのデータに適用される第1の型の関数を実装するマッピング式を含み、
    前記追加のETLマッピングは、前記ターゲットスキーマの第2のカラムにデータをロードするために前記ソーススキーマの前記カラムのデータに適用される前記第1の型の関数を実装するマッピング式を含む、請求項13に記載のシステム。
JP2020545789A 2018-04-16 2019-04-11 例によるetlルールの学習 Active JP7419244B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US15/953,873 US11494688B2 (en) 2018-04-16 2018-04-16 Learning ETL rules by example
US15/953,873 2018-04-16
PCT/US2019/026891 WO2019204106A1 (en) 2018-04-16 2019-04-11 Learning etl rules by example

Publications (3)

Publication Number Publication Date
JP2021519964A JP2021519964A (ja) 2021-08-12
JPWO2019204106A5 JPWO2019204106A5 (ja) 2022-01-20
JP7419244B2 true JP7419244B2 (ja) 2024-01-22

Family

ID=66248868

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2020545789A Active JP7419244B2 (ja) 2018-04-16 2019-04-11 例によるetlルールの学習

Country Status (5)

Country Link
US (1) US11494688B2 (ja)
EP (1) EP3782044A1 (ja)
JP (1) JP7419244B2 (ja)
CN (1) CN111712809A (ja)
WO (1) WO2019204106A1 (ja)

Families Citing this family (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11704370B2 (en) 2018-04-20 2023-07-18 Microsoft Technology Licensing, Llc Framework for managing features across environments
US20200210857A1 (en) * 2018-12-31 2020-07-02 Kobai, Inc. Decision intelligence system and method
US11487721B2 (en) 2019-04-30 2022-11-01 Sap Se Matching metastructure for data modeling
US20210012219A1 (en) * 2019-07-10 2021-01-14 Sap Se Dynamic generation of rule and logic statements
CN111338966B (zh) * 2020-03-05 2023-09-19 中国银行股份有限公司 数据源表的大数据加工检测方法及装置
US11379478B2 (en) * 2020-04-02 2022-07-05 International Business Machines Corporation Optimizing a join operation
CN112035468B (zh) * 2020-08-24 2024-06-14 杭州览众数据科技有限公司 基于内存计算、web可视化配置的多数据源ETL工具
CN111966394B (zh) * 2020-08-28 2024-05-31 珠海格力电器股份有限公司 基于etl的数据分析方法、装置、设备和存储介质
US11372826B2 (en) 2020-10-19 2022-06-28 Oracle International Corporation Dynamic inclusion of custom columns into a logical model
US20220179833A1 (en) * 2020-12-03 2022-06-09 International Business Machines Corporation Metadata based mapping assist
JPWO2022259336A1 (ja) * 2021-06-07 2022-12-15
US11836120B2 (en) * 2021-07-23 2023-12-05 Oracle International Corporation Machine learning techniques for schema mapping
US11886396B2 (en) * 2021-11-13 2024-01-30 Tata Consultancy Services Limited System and method for learning-based synthesis of data transformation rules
WO2023097521A1 (zh) * 2021-11-30 2023-06-08 西门子股份公司 数据模型生成的方法和装置
US20230205746A1 (en) * 2021-12-23 2023-06-29 Microsoft Technology Licensing, Llc Determination of recommended column types for columns in tabular data
US12061600B2 (en) * 2022-07-14 2024-08-13 International Business Machines Corporation API management for batch processing
US20240126729A1 (en) * 2022-10-14 2024-04-18 Oracle International Corporation Natively supporting json duality view in a database management system
EP4357929A1 (en) * 2022-10-21 2024-04-24 Atos France Data quality assurance for heterogenous data migration in clouds

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2004086782A (ja) 2002-08-29 2004-03-18 Hitachi Ltd 異種データベース統合支援装置
JP2007188343A (ja) 2006-01-13 2007-07-26 Mitsubishi Electric Corp スキーマ統合支援装置、スキーマ統合支援方法およびスキーマ統合支援プログラム
US20170061500A1 (en) 2015-09-02 2017-03-02 Borodin Research Inc. Systems and methods for data service platform
JP2018060430A (ja) 2016-10-07 2018-04-12 株式会社日立製作所 データ統合装置およびデータ統合方法

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3648051B2 (ja) * 1998-02-02 2005-05-18 富士通株式会社 関連情報検索装置及びプログラム記録媒体
CN101777073A (zh) * 2010-02-01 2010-07-14 浪潮集团山东通用软件有限公司 一种基于xml格式的数据转换方法
US9298787B2 (en) * 2011-11-09 2016-03-29 International Business Machines Corporation Star and snowflake schemas in extract, transform, load processes
US9542412B2 (en) 2014-03-28 2017-01-10 Tamr, Inc. Method and system for large scale data curation
US10169378B2 (en) 2014-09-11 2019-01-01 Oracle International Corporation Automatic generation of logical database schemas from physical database tables and metadata
US10374905B2 (en) * 2015-06-05 2019-08-06 Oracle International Corporation System and method for intelligently mapping a source element to a target element in an integration cloud service design time
US10095766B2 (en) * 2015-10-23 2018-10-09 Numerify, Inc. Automated refinement and validation of data warehouse star schemas
US20170220654A1 (en) * 2016-02-03 2017-08-03 Wipro Limited Method for automatically generating extract transform load (etl) codes using a code generation device
CN106682235A (zh) * 2017-01-18 2017-05-17 济南浪潮高新科技投资发展有限公司 一种异构数据映射系统及方法
CN107798069A (zh) * 2017-09-26 2018-03-13 恒生电子股份有限公司 用于数据加载的方法、装置及计算机可读介质

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2004086782A (ja) 2002-08-29 2004-03-18 Hitachi Ltd 異種データベース統合支援装置
JP2007188343A (ja) 2006-01-13 2007-07-26 Mitsubishi Electric Corp スキーマ統合支援装置、スキーマ統合支援方法およびスキーマ統合支援プログラム
US20170061500A1 (en) 2015-09-02 2017-03-02 Borodin Research Inc. Systems and methods for data service platform
JP2018060430A (ja) 2016-10-07 2018-04-12 株式会社日立製作所 データ統合装置およびデータ統合方法

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
AnHai Doan, et al. ,Reconciling Schemas of Disparate Data Sources: A Machine-Learning Approach,ACM SIGMOD 2001,Volume 30, Issue 2,米国,ACM,2001年05月01日,pp. 509-520

Also Published As

Publication number Publication date
JP2021519964A (ja) 2021-08-12
CN111712809A (zh) 2020-09-25
US20190318272A1 (en) 2019-10-17
EP3782044A1 (en) 2021-02-24
WO2019204106A1 (en) 2019-10-24
US11494688B2 (en) 2022-11-08

Similar Documents

Publication Publication Date Title
JP7419244B2 (ja) 例によるetlルールの学習
US11681702B2 (en) Conversion of model views into relational models
Karnitis et al. Migration of relational database to document-oriented database: structure denormalization and data transformation
US10528548B2 (en) Enforcing referential integrity for object data documents
Gupta et al. NoSQL databases: Critical analysis and comparison
US11921750B2 (en) Database systems and applications for assigning records to chunks of a partition in a non-relational database system with auto-balancing
US10268645B2 (en) In-database provisioning of data
US8180758B1 (en) Data management system utilizing predicate logic
US9582526B2 (en) Optimizing database definitions in an existing database
US20160055233A1 (en) Pre-join tags for entity-relationship modeling of databases
US10296505B2 (en) Framework for joining datasets
US20170371903A1 (en) Dynamic modeling of data in relational databases
US10534797B2 (en) Synchronized updates across multiple database partitions
US20170371922A1 (en) Database Management for Mobile Devices
CN109947741B (zh) 一种物项属性参数的建模和存储方法
AU2017254893A1 (en) Adapting database queries for data virtualization over combined database stores
US11726999B1 (en) Obtaining inferences to perform access requests at a non-relational database system
Soumiya et al. Converting UML class diagrams into temporal object relational database
Sreemathy et al. Data validation in ETL using TALEND
US10311051B1 (en) Storing modeling alternatives with unitized data
US12061579B2 (en) Database gateway with machine learning model
US20190370242A1 (en) Electronic database and method for forming same
US11928125B2 (en) Cleaning and organizing schemaless semi-structured data for extract, transform, and load processing
Solanke et al. Migration of relational database to MongoDB and Data Analytics using Naïve Bayes classifier based on Mapreduce approach
US20240086495A1 (en) Auto-Triage Failures In A/B Testing

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20220111

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20220111

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20230203

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20230404

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20230704

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20230831

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20231212

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20240110

R150 Certificate of patent or registration of utility model

Ref document number: 7419244

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150