データウェアハウスのETL（抽出、変換、読み込み）プロセスとは何ですか？

what is etl extract

ETLプロセスに関するこの詳細なチュートリアルでは、データウェアハウスのETL（抽出、変換、および読み込み）プロセスに関連するプロセスフローとステップについて説明します。

シリーズのこのチュートリアルでは、次のように説明しています。ETLプロセスとは何ですか。データ抽出、変換、読み込み、フラットファイル、ステージングとは何ですか？ ETLサイクルなど

はじめましょう！！

=> ここで完璧なデータウェアハウジングトレーニングガイドをチェックしてください。

学習内容：

• ETL（抽出、変換、読み込み）プロセスの基礎
  • データウェアハウスのETLプロセスとは何ですか？
  • データ抽出
    • データウェアハウスでの抽出方法
    • 変更されたデータの抽出
  • データ変換
    • 変換を実装する方法は？
  • データの読み込み
  • フラットファイル
    • 固定長フラットファイルの処理
    • 区切られたフラットファイルの処理
  • ステージングエリアの目的
  • ステージングエリアの設計
  • ETLプロセスフロー
• 結論
  • 推奨読書

ETL（抽出、変換、読み込み）プロセスの基礎

ターゲットオーディエンス

• データウェアハウス/ ETL開発者およびテスター。
• データベースの概念に関する基本的な知識を持つデータベースの専門家。
• データウェアハウス/ ETL領域を理解したいデータベース管理者/ビッグデータの専門家。
• データウェアハウスの仕事を探している大学卒業生/フレッシャーズ。

データウェアハウスのETLプロセスとは何ですか？

データウェアハウスは、ビジネスインテリジェンスツールを使用してビジネスユーザーに情報を提供するための膨大な量のデータのコレクションであることは誰もが知っています。

この目的を果たすには、DWを定期的にロードする必要があります。システムへのデータは、1つ以上の運用システム、フラットファイルなどから収集されます。 データをDWに取り込むプロセスは、ETLプロセスとして知られています。 。抽出、変換、および読み込みはETLのタスクです。

＃1）抽出： データベース、アプリケーション、フラットファイルなどのさまざまなソースシステムからのすべての優先データが識別され、抽出されます。データ抽出は、営業時間外にジョブを実行することで完了できます。

＃2）変換： 抽出されたデータのほとんどは、ターゲットシステムに直接ロードできません。ビジネスルールに基づいて、データをロードする前にいくつかの変換を行うことができます。

例えば、 ターゲット列データは、2つのソース列が連結されたデータを入力として予期する場合があります。同様に、専門知識を必要とするデータ変換の複雑なロジックが存在する場合があります。変換を必要としない一部のデータは、ターゲットシステムに直接移動できます。

変換プロセスでは、データを修正し、誤ったデータを削除し、データをロードする前にデータのエラーを修正します。

＃3）読み込み中： 収集されたすべての情報は、ターゲットのデータウェアハウステーブルにロードされます。

データ抽出

データ抽出は、成功するDWシステムの設計において主要な役割を果たします。ソースシステムが異なれば、データの特性も異なる可能性があり、ETLプロセスは、データを抽出しながらこれらの違いを効果的に管理します。

「」 論理データマップ 」は、データ抽出の基本ドキュメントです。これは、どのソースデータをどのターゲットテーブルに移動する必要があるか、およびソースフィールドがETLプロセスのそれぞれのターゲットテーブルフィールドにどのようにマップされるかを示します。

以下は、論理データマップの設計中に実行する手順です。

• データウェアハウスアーキテクトは、論理データマップドキュメントを設計します。
• このドキュメントを参照することにより、ETL開発者はETLジョブを作成し、ETLテスターはテストケースを作成します。
• このドキュメントでは、ビジネス上の意思決定をサポートするすべての特定のデータソースとそれぞれのデータ要素について説明します。これらのデータ要素は、抽出プロセス中に入力として機能します。
• すべてのソースシステムからのデータが分析され、あらゆる種類のデータ異常が文書化されるため、DWへの誤ったデータの抽出を防ぐための正しいビジネスルールの設計に役立ちます。このようなデータは、ここ自体で拒否されます。
• 最終的なソースおよびターゲットデータモデルがETLアーキテクトとビジネスアナリストによって設計されると、ETL開発者とテスターと一緒にウォークスルーを実行できます。これにより、抽出、変換、および読み込みの各フェーズでビジネスルールを実行する方法を明確に理解できます。
• このドキュメントのマッピングルールを確認することで、ETLアーキテクト、開発者、およびテスターは、データがディメンション、ファクト、およびその他のテーブルとして各テーブルからどのように流れるかを十分に理解する必要があります。
• 間違ったデータの抽出を避けるために、あらゆる種類のデータ操作ルールまたは式もここで言及されています。 例えば、 過去40日間のデータなどのみを抽出します。
• ETLチームの責任は、ビジネス要件に従ってデータにドリルダウンし、DWにロードされるすべての有用なソースシステム、テーブル、および列のデータを引き出すことです。

論理データマップドキュメントは通常、次のコンポーネントを示すスプレッドシートです。

抽出フロー図：

抽出サイクル中にソースデータが失われないように、事前に各ソースシステムに対してジョブを実行する時間枠について記述します。

上記の手順により、抽出は、さまざまなソースのさまざまな形式のデータを単一のDW形式に変換するという目標を達成し、ETLプロセス全体にメリットをもたらします。このような論理的に配置されたデータは、より良い分析に役立ちます。

データウェアハウスでの抽出方法

ソースおよびターゲットのデータ環境とビジネスニーズに応じて、DWに適した抽出方法を選択できます。

＃1）論理抽出方法

データウェアハウスシステムでのデータ抽出は、最初に実行される1回限りの完全なロードである場合があります（または）一定の更新で毎回発生する増分ロードである場合があります。

Oracleデータベースの面接の質問と回答

• 完全抽出： 名前自体が示すように、ソースシステムデータはターゲットテーブルに完全に抽出されます。この種の抽出は、最後に抽出されたタイムスタンプを考慮せずに、現在のソースシステムデータ全体をロードするたびに行われます。できれば、初期ロードまたはデータの少ないテーブルに完全抽出を使用できます。
• インクリメンタル抽出： 特定の日付から追加/変更されたデータは、増分抽出の対象と見なされます。この日付は、最終抽出日（または）最終注文日などのビジネス固有です。ソーステーブル自体からタイムスタンプ列を参照できます（または）抽出日の詳細のみを追跡するために別のテーブルを作成できます。タイムスタンプの参照は、インクリメンタル抽出中の重要な方法です。 DWテーブルに大きなデータがある場合、タイムスタンプのないロジックは失敗する可能性があります。

＃2）物理的抽出方法

ソースシステムの機能とデータの制限に応じて、ソースシステムは、オンライン抽出およびオフライン抽出として抽出するためにデータを物理的に提供できます。これは、すべての論理抽出タイプをサポートします。

• オンライン抽出:: 接続文字列を使用して任意のソースシステムデータベースに直接接続し、ソースシステムテーブルから直接データを抽出できます。
• オフライン抽出:: ここでは、ソースシステムデータベースに直接接続するのではなく、ソースシステムが事前定義された構造でデータを明示的に提供します。ソースシステムは、フラットファイル、ダンプファイル、アーカイブログ、およびテーブルスペースの形式でデータを提供できます。

ETLツールは、高価ですが、DWの場合、複雑なデータ抽出を何度でも実行するのに最適です。

変更されたデータの抽出

初期ロードが完了したら、ソースシステムから変更されたデータをさらに抽出する方法を検討することが重要です。 ETLプロセスチームは、プロジェクト自体の開始時に、初期ロードと増分ロードの抽出を実装する方法に関する計画を設計する必要があります。

ほとんどの場合、データの変更をキャプチャするための増分負荷の「列の監査」戦略を検討できます。一般に、ソースシステムテーブルには、挿入（または）変更ごとのタイムスタンプを格納する監査列が含まれる場合があります。

タイムスタンプは、アプリケーション自体からのデータベーストリガー（または）によって入力される場合があります。増分ロードのために変更されたデータを見逃さないように、監査列のデータが何らかの方法でロードされている場合でも、そのデータの正確性を確保する必要があります。

増分ロード中に、最後のロードが発生した最大日時を考慮し、最後のロードのタイムスタンプよりも大きいタイムスタンプでソースシステムからすべてのデータを抽出できます。

データの抽出中：

• クエリを最適に使用して、必要なデータのみを取得します。
• Distinct句はクエリのパフォーマンスを低下させるため、あまり使用しないでください。
• パフォーマンスが低下するため、Union、Minus、IntersectなどのSET演算子を慎重に使用してください。
• substr（）、to_char（）などの関数ではなく、where句でlike、betweenなどの比較キーワードを使用します。

データ変換

変換は、ソースシステムデータをターゲットシステムに直接ロードする前に、抽出されたデータに一連のルールが適用されるプロセスです。抽出されたデータは生データと見なされます。

一連の標準を使用した変換プロセスにより、さまざまなソースシステムからのすべての異なるデータがDWシステムで使用可能なデータに変換されます。データ変換は、データの品質を目的としています。すべての論理変換ルールについては、データマッピングドキュメントを参照できます。

変換ルールに基づいて、ソースデータが指示を満たしていない場合、そのようなソースデータはターゲットDWシステムにロードされる前に拒否され、拒否ファイルまたは拒否テーブルに配置されます。

ソースからターゲットへのストレートロード列データ（変更の必要はありません）には、変換ルールが指定されていません。したがって、データ変換は単純なものと複雑なものに分類できます。データ変換には、列変換、データ構造の再フォーマットなどが含まれる場合があります。

以下に、データ変換中に実行するタスクの一部を示します。

＃1）選択： テーブルデータ全体または特定の列データのセットをソースシステムから選択できます。データの選択は通常、抽出自体で完了します。

ソースシステムが、抽出フェーズで特定の列データのセットを選択してから、データ全体を抽出し、変換フェーズで選択を行うことを許可しない場合があります。

＃2）分割/結合： 選択したデータを分割または結合することで操作できます。変換中に、選択したソースデータをさらに分割するように求められます。

例えば、 住所全体がソースシステムの単一の大きなテキストフィールドに格納されている場合、DWシステムは、住所を都市、州、郵便番号などの個別のフィールドに分割するように要求する場合があります。これは、それぞれに基づくインデックス作成と分析が容易です。コンポーネントを個別に。

一方、2つ以上の列のデータの結合/マージは、DWシステムの変換フェーズで広く使用されています。これは、2つのフィールドを1つのフィールドにマージすることを意味するものではありません。

例えば、 特定のエンティティに関する情報が複数のデータソースからのものである場合、単一のエンティティとして情報を収集することは、データの結合/マージと呼ばれます。

＃3）変換： 抽出されたソースシステムデータは、データタイプごとに異なる形式である可能性があるため、抽出されたすべてのデータは、変換フェーズ中に標準化された形式に変換する必要があります。同じ種類の形式は、理解しやすく、ビジネス上の意思決定に簡単に使用できます。

＃4）要約： 状況によっては、DWは、ソースシステムからの低レベルの詳細データではなく、要約されたデータを探します。低レベルのデータは、ビジネスユーザーによる分析やクエリには最適ではないためです。

例えば、 DWシステムでは、すべてのチェックアウトの売上データが必要ない場合があります。毎日の売上副産物（または）店舗による毎日の売上が役立ちます。したがって、データの要約は、ビジネス要件に従って変換フェーズ中に実行できます。

＃5）エンリッチメント： 複数のレコードからの1つ以上の列を組み合わせてDW列を形成すると、データエンリッチメントによってフィールドが再配置され、DWシステムのデータが見やすくなります。

＃6）フォーマットの改訂： フォーマットの改訂は、変換フェーズで最も頻繁に発生します。データ型とその長さは、列ごとに改訂されます。

例えば、 あるソースシステムの列は数値であり、別のソースシステムの同じ列はテキストである場合があります。これを標準化するために、変換フェーズ中に、この列のデータ型がテキストに変更されます。

＃7）フィールドのデコード： 複数のソースシステムからデータを抽出する場合、さまざまなシステムのデータが異なる方法でデコードされる可能性があります。

例えば、 1つのソースシステムは、顧客のステータスをAC、IN、およびSUとして表す場合があります。別のシステムは、1、0、および-1と同じステータスを表す場合があります。

データ変換フェーズでは、このようなコードをビジネスユーザーが理解できる適切な値にデコードする必要があります。したがって、上記のコードは、アクティブ、非アクティブ、および一時停止に変更できます。

＃8）計算値と導出値： ソースシステムデータを考慮することにより、DWは計算用の追加の列データを格納できます。 DWに保存する前に、ビジネスロジックに基づいて計算を行う必要があります。

＃9）日付/時刻の変換： これは、集中すべき重要なデータ型の1つです。日付/時刻の形式は、複数のソースシステムで異なる場合があります。

例えば、 1つのソースは1997年11月10日として日付を保存できます。別のソースは1997年11月10日の形式で同じ日付を保存できます。したがって、データ変換中に、すべての日付/時刻値を標準形式に変換する必要があります。

＃10）重複排除： ソースシステムに重複するレコードがある場合は、DWシステムにロードされるレコードが1つだけであることを確認してください。

変換フロー図：

変換を実装する方法は？

データ変換の複雑さに応じて、手動の方法、変換ツール（または）両方の組み合わせを使用できます。

＃1）手動テクニック

小規模なDWシステムには、手動の手法で十分です。データアナリストと開発者は、データを手動で変換するためのプログラムとスクリプトを作成します。この方法では、コードのすべての部分について詳細なテストが必要です。

ビジネスルールの変更により（または）データ量の増加に伴いエラーが発生する可能性があるため、メンテナンスコストが高くなる可能性があります。最初にメタデータを処理する必要があります。また、変換ルールで発生するすべての変更についても処理する必要があります。

＃2）変換ツール

変換プロセスのほとんどを自動化したい場合は、プロジェクトで利用可能な予算と時間枠に応じて変換ツールを採用できます。自動化する際には、ツールの選択、構成、インストール、およびDWシステムとの統合に質の高い時間を費やす必要があります。

ツール自体を使用した実質的な完全な変換は、手動による介入なしでは不可能です。しかし、ツールによって変換されたデータは確かに効率的で正確です。

これを実現するには、適切なパラメーター、データ定義、およびルールを入力として変換ツールに入力する必要があります。指定された入力から、ツール自体がメタデータを記録し、このメタデータがDWメタデータ全体に追加されます。

ビジネスルールに変更がある場合は、それらの変更をツールに入力するだけで、残りの変換の変更はツール自体によって処理されます。したがって、両方の方法を組み合わせて使用​​すると効率的です。

データの読み込み

抽出および変換されたデータは、ETLプロセスのロードフェーズ中にターゲットDWテーブルにロードされます。ビジネスは、各テーブルのロードプロセスをどのように行うかを決定します。

ロードプロセスは、次の方法で実行できます。

• 初期負荷： データをロードして、それぞれのDWテーブルに初めてデータを入力します。
• 増分負荷： DWテーブルがロードされると、進行中の残りの変更が定期的に適用されます。
• 完全更新： 使用中のテーブルを更新する必要がある場合、そのテーブルの現在のデータは完全に削除されてから再ロードされます。再ロードは初期ロードと同様です。

ETLでの読み込みプロセスをよりよく理解するには、以下の例をご覧ください。

＃1） 初期ロード中、3で販売されているデータ^rd2007年6月は、上記のテーブルの初期データであるため、DWターゲットテーブルにロードされます。

＃二） インクリメンタルロード中に、3以降に販売されたデータをロードする必要があります^rd2007年6月。販売日が前日よりも大きい（>）すべてのレコードを翌日の検討する必要があります。したがって、4に^th2007年6月、販売日が3を超えるすべてのレコードをフェッチします^rd2007年6月、クエリを使用して、上記の表からこれら2つのレコードのみをロードします。

5日^th2007年6月、販売日が4を超えるすべてのレコードをフェッチします^th2007年6月、上記の表から1つのレコードのみをロードします。

＃3） フルリフレッシュ中、上記のすべてのテーブルデータは、販売日に関係なく一度にDWテーブルにロードされます。

ロードされたデータは、それぞれのディメンション（または）ファクトテーブルに保存されます。データは、次のようにDWテーブルにロード、追加、またはマージできます。

＃4）ロード： データが空の場合、データはターゲットテーブルにロードされます。テーブルにデータが存在する場合、既存のデータが削除されてから、新しいデータがロードされます。

例えば、

既存のテーブルデータ

変更されたデータ

ロード後のデータ

＃5）追加： Appendは、既存のデータテーブルで機能するため、上記の負荷を拡張したものです。ターゲットテーブルで、Appendは既存のデータにさらにデータを追加します。入力データで重複レコードが見つかった場合、重複として追加されるか、拒否される可能性があります。

例えば、

既存のテーブルデータ

Windows 764ビットに最適なファイアウォール

変更されたデータ

追加後のデータ

＃6）破壊的なマージ： ここで、受信データは、主キーに基づいて既存のターゲットデータと比較されます。一致する場合は、既存のターゲットレコードが更新されます。一致するものが見つからない場合、新しいレコードがターゲットテーブルに挿入されます。

例えば、

既存のテーブルデータ

変更されたデータ

建設的マージ後のデータ

＃7）建設的な行きます： 破壊的マージとは異なり、既存のレコードと一致する場合は、既存のレコードをそのままにして、受信レコードを挿入し、その主キーに関して最新のデータ（タイムスタンプ）としてマークします。

例えば、

既存のテーブルデータ

変更されたデータ

建設的マージ後のデータ

技術的には、更新はデータの更新よりも簡単です。更新には、特定の変更のみを抽出してDWシステムに適用するための特別な戦略が必要ですが、更新ではデータが置き換えられるだけです。ただし、データの量によっては、データの更新に時間がかかります。

このような更新ジョブを毎日実行する場合は、データをロードするためにDWシステムを停止する必要がある場合があります。 DWシステム全体を停止して毎回データをロードする代わりに、データをいくつかのファイルの形式で分割してロードできます。

テスト中に、各ロードの実行時間をメモします。キーの不一致などが原因でデータをDWシステムにロードできない場合は、そのような種類のデータを処理する方法を提供してください。ロードされたデータが徹底的にテストされていることを確認してください。

フロー図のロード：

フラットファイル

フラットファイルは、異なるソースオペレーティングシステムから、異なるソースデータベースシステムからデータウェアハウスアプリケーションまで、異種システム間でデータを交換するために広く使用されています。フラットファイルは、同種のシステムでも最も効率的で管理が簡単です。

フラットファイルは、主に次の目的で使用されます。

＃1）ソースデータの配信： セキュリティ上の理由から、DWユーザーがデータベースにアクセスできないようにするソースシステムはほとんどない場合があります。このような場合、データはフラットファイルを介して配信されます。

同様に、データは基本的にフラットファイルの形式で外部ベンダーまたはメインフレームシステムから供給され、これらはETLユーザーによってFTPで転送されます。

＃2）作業/ステージングテーブル： ETLプロセスは、内部目的のためにステージングテーブルを作成します。ファイルシステムへの読み取りと書き込みはデータベースの挿入とクエリよりも高速であるため、ステージングテーブルとフラットファイルの関連付けはDBMSよりもはるかに簡単です。

＃3）バルクロードの準備： 抽出プロセスと変換プロセスが完了したら、インストリームバルクロードがETLツールでサポートされていない場合（または）データをアーカイブする場合は、フラットファイルを作成できます。このフラットファイルデータはプロセッサによって読み取られ、データをDWシステムにロードします。

フラットファイルは、「固定長フラットファイル」と「区切りフラットファイル」の2つの方法で作成できます。フラットファイルは、ソースシステムで作業するプログラマーが作成できます。

これらのフラットファイルをどのように処理するかを見てみましょう。

固定長フラットファイルの処理

一般に、フラットファイルは固定長の列であるため、定位置フラットファイルとも呼ばれます。以下は、ファイル内の正確なフィールドとその位置を示すフラットファイルのレイアウトです。

レイアウトには フィールド名、長さ、開始位置 フィールド文字の開始位置、フィールド文字の終了位置、テキスト、数値などのデータ型、およびコメント（ある場合）。

データの位置に応じて、ETLテストチームは固定長のフラットファイル内のデータの正確性を検証します。

区切られたフラットファイルの処理

区切りフラットファイルでは、各データフィールドは区切り文字で区切られます。この区切り文字は、各フィールドの開始位置と終了位置を示します。通常、区切り文字としてコンマが使用されますが、他の記号または記号のセットを使用できます。

区切りファイルには、.CSV拡張子（または）.TXT拡張子（または）を付けることができます。 ETLファイルを作成する開発者は、そのファイルを処理するための実際の区切り記号を示します。区切られたファイルレイアウトでは、最初の行が列名を表す場合があります。

位置フラットファイルと同じように、ETLテストチームは区切られたフラットファイルデータの精度を明示的に検証します。

ステージングエリアの目的

ステージング領域の主な目的は、ETLプロセスのためにデータを一時的に保存することです。ステージング領域は、DWシステムのバックルームと呼ばれます。 ETLアーキテクトは、ステージング領域にデータを格納するかどうかを決定します。

ステージングは​​、ソースシステムからデータを非常に高速に取得するのに役立ちます。同時に、DWシステムに障害が発生した場合、ステージングデータがすでに存在する場合は、ソースシステムからデータを収集してプロセスを再開する必要はありません。

データ抽出プロセスの後、DWシステムでデータをステージングする理由は次のとおりです。

＃1）回復可能性： 入力されたステージングテーブルは、DWデータベース自体に保存されます（または）ファイルシステムに移動して、個別に保存できます。ある時点で、変換またはロードステップが失敗した場合、ステージングデータはリカバリデータとして機能できます。

ソースシステムがETLに使用されるデータを上書きしている可能性があるため、抽出されたデータをステージングに保持しておくと、参照に役立ちます。

＃2）バックアップ： 大量のDWデータベーステーブルをバックアップすることは困難です。ただし、災害復旧にはバックアップが必須です。したがって、抽出されたデータであるステージングデータがある場合は、変換とロードのためにジョブを実行できます。これにより、クラッシュしたデータを再ロードできます。

ステージングデータをバックアップするために、ステージングデータをファイルシステムに頻繁に移動して、ネットワークに簡単に圧縮して保存できるようにすることができます。必要な場合はいつでも、ファイルを解凍し、ステージングテーブルにロードし、ジョブを実行してDWテーブルをリロードします。

＃3）監査： ソースシステムとターゲットシステム間のデータリンケージをチェックするために、ETLシステムで監査が行われる場合があります。監査人は、変換ルールに基づいて、元の入力データを出力データに対して検証できます。

ステージングデータとそのバックアップは、ソースシステムに利用可能なデータがあるかどうかに関係なく、ここで非常に役立ちます。監査は、現在（または）過去のデータのいつでも、どの期間でも発生する可能性があるためです。ステージングエリアのアーキテクチャは十分に計画する必要があります。

ステージングエリアの設計

データウェアハウスでは、ステージング領域のデータを次のように設計できます。

ステージングテーブルにデータが新たにロードされるたびに、既存のデータを削除（または）参照用の履歴データとして維持できます。データが削除されると、それは「一時的なステージング領域」と呼ばれます。

データが履歴として保持される場合、それは「永続的なステージング領域」と呼ばれます。上記2種類を組み合わせた「ハイブリッド」のステージングエリアをデザインすることもできます。

ステージング領域を設計する際に知っておくべき基本的なルールは次のとおりです。

• ETLチームのみがデータステージング領域にアクセスできる必要があります。ステージングデータのクエリは、他のユーザーに制限されています。
• ステージング領域のテーブルは、他のユーザーを関与させることなく、ETLデータアーキテクトが追加、変更、または削除できます。ステージング領域はレポートを生成するためのプレゼンテーション領域ではないため、ワークベンチとして機能します。
• ETLアーキテクトは、ステージング領域のデータストレージメジャーを見積もり、DBAおよびOS管理者に詳細を提供する必要があります。管理者は、ステージングデータベース、ファイルシステム、ディレクトリなどにスペースを割り当てます。

ステージング領域とDWデータベースが同じサーバーを使用している場合は、データをDWシステムに簡単に移動できます。サーバーが異なる場合は、FTP（または）データベースリンクを使用してください。

ETLプロセスフロー

標準のETLサイクルでは、以下のプロセスステップが実行されます。

• ETLサイクルを開始して、ジョブを順番に実行します。
• すべてのメタデータの準備ができていることを確認してください。
• ETLサイクルは、さまざまなソースからデータを抽出するのに役立ちます。
• 抽出されたデータを検証します。
• ステージングテーブルが使用されている場合、ETLサイクルはデータをステージングにロードします。
• ETLは、ビジネスルールの適用、集計の作成などによって変換を実行します
• 障害が発生した場合、ETLサイクルにより、レポートの形式で通知されます。
• 次に、ETLサイクルはデータをターゲットテーブルにロードします。
• 履歴参照のために保存する必要がある以前のデータはアーカイブされます。
• 保存する必要のない残りのデータはクリーンアップされます。

ETLプロセスフロー図：

結論

このチュートリアルでは、データウェアハウスのETLプロセスの主要な概念について学習しました。これで、データ抽出、データ変換、データ読み込み、およびETLプロセスフローとは何かを理解できるようになります。

データウェアハウステストの詳細については、次のチュートリアルをお読みください。

=> 独占的なデータウェアハウジングシリーズについては、こちらをご覧ください。

推奨読書

• 例を含むデータウェアハウステストチュートリアル| ETLテストガイド
• ETLプロセスで役立つ10のベストデータマッピングツール(2021リスト)
• ETLテストデータウェアハウステストチュートリアル（完全ガイド）
• データマイニング：データ分析におけるプロセス、技術、および主要な問題
• データマイニングプロセス：モデル、プロセスステップ、および関連する課題
• ETLテストの面接の質問と回答
• 2021年のトップ10ETLテストツール
• 人気のあるデータウェアハウスツールとテストテクノロジーのトップ10