1

MS SQL Server (2008 または 2012) の変更データ キャプチャを、複数のソース テーブルを 1 つの宛先テーブルに結合する SSIS パッケージと共に使用できますか?

Technet の記事では、ソース テーブルと宛先テーブルが同じ構造である場合の CDC + SSIS の使用例について説明しています。カスタム データ変換の変更追跡の可能性に関する唯一のヒントは、CDC が変更を追跡する列を指定できることです。

問題は、多数のソース テーブルのデータを組み合わせて宛先テーブルを取得し、それをそれらのソース テーブルと同期させる必要があることです。

これは、宛先データ ウェアハウスのデータがソース データベースよりも正規化されていないためです。たとえば、イベント テーブル (コンピューター ID、日付/時刻、イベントの説明を含む) とコンピューター テーブル (コンピューター ID とコンピューター名を含む) があります。これらの正規化されたテーブルとコンピューター ID は宛先テーブルに必要ないため、宛先テーブルを埋めるための選択は次のようにする必要があります。

INSERT INTO DestDB..ComputerEvents (ComputerName, DateTime, Event) 
SELECT s.ComputerName, e.DateTime, e.Event
FROM SourceDB..EventLog e
JOIN SourceDB..ComputerNames s
ON e.CompID = s.CompID

そのような変換を含むSSISパッケージでCDCを機能させる方法がわかりませんか? それは可能ですか？

4

3 に答える 3

2

質問に答えるには: いいえ、できません。

他のレスポンダーが指摘したように、CDC は、最後に変更を抽出してから各ソース テーブルで何が変更されたかしか通知できません。

CDC を使用して複数のソース テーブルから変更を抽出し、単一の宛先テーブルをロードするのは簡単ではありません。

その理由を例を挙げて説明しましょう。この例では、ステージング テーブルは、データが入力される前に定期的に切り捨てられるテーブルであると想定しています。

Order、OrderDetail という 2 つのソース テーブルがあるとします。1 つの宛先ファクト テーブル FactOrder があります。FactOrder には、OrderKey (Order から) と OrderDetail からの注文金額の合計が含まれます。顧客は 3 つの製品を注文します。1 つの Order レコードと 3 つの OrderDetail レコードがソース データベース テーブルに挿入されます。DW ETL は、1 つの注文レコード (挿入) と 3 つの OrderDetail レコード (挿入) を抽出します。前のレスポンダーが言ったように、変更されたレコードをステージング テーブルにロードすることを選択した場合、単にステージング テーブルを結合して FactOrder レコードを作成できます。しかし、いずれかの製品を取り扱っておらず、誰かが OrderDetail レコードからレコードを削除した場合はどうなるでしょうか。次の DW ETL は、1 つの OrderDetail レコードを抽出します (削除)。この情報を使用してターゲット テーブルを更新するにはどうすればよいでしょうか。明らかにできる」Order から OrderDetail に結合します。これは、この特定の OrderKey が切り捨てられたステージング テーブルであるため、Order にはこの特定の OrderKey のレコードがないためです。削除の例を選択しましたが、従属テーブルが更新された場合も同じ問題を考慮します。

代わりに私が提案するのは、FactOrder レコードを構築するために必要なソース テーブルのいずれかに変更がある主キー (この例では OrderKey) 値の個別のセットを抽出し、その後の要求で完全な FactOrder レコードを抽出することです。たとえば、5 つの Order レコードが変更された場合、5 つの OrderKey 値がわかります。30 個の OrderDetail レコードが変更された場合、OrderKey 値の個別のセットを決定する必要があります。それが 10 個の OrderKey だとしましょう。次に、2 つのセットを結合します。オーバーラップがあり、12 個の OrderKey 値が得られるとしましょう。ここで、FactOrder 抽出クエリに 12 個の OrderKey 値をシードします。12 個の完全な FactOrder レコードが返されます。次に、新しいチェックサムと保存されたバイナリ チェックサムの比較を使用して、12 のレコードを処理する方法 (挿入または更新) を決定します。上記のアプローチは、Order テーブルからの削除には対応していません。それらは、FactOrder からの些細な削除につながります。

あなたが指摘した多くの例は、CDC を使用して 1 つのソースから 1 つの宛先にデータをレプリケート/同期する方法を示しています。宛先行を作成するための複数のソース テーブル)。

于 2014-04-15T18:11:37.587 に答える
0

最初に CDC がテーブルの変更をキャプチャするので、テーブルに挿入、削除、または更新があった場合、CDC レコードが作成され、挿入、更新、または削除を示すインジケーターが付けられ、CDC タスクはレコードを 1 つに出力するだけです。そのインジケーター列に基づく3つの出力のうち、質問に戻ると、ソースごとに複数のOLDEDBソースとCDCタスクが必要になる場合があり、UNION ALLの同様の操作（挿入、更新、削除）をまとめてから、宛先コンポーネントまたはOLEDBコマンドコンポーネントこれが役立つことを願っています:)

于 2013-12-30T21:00:29.613 に答える
0

1 つの通常のステージング テーブルを指す 1 つの CDC ソース テーブルを使用して、(SQL クエリやレプリケーションではなく) ステージング テーブルを埋めるための自動化されたメカニズムであるかのように CDC を検討してください。そこから、必要に応じて、複数のステージング テーブルに対して結合クエリを作成するだけです。

私の仮定は、次のように、同一でないテーブルからデータを取得していることです。

  • 注文テーブル、
  • OrderDetail テーブルなど。

同じまたは異なるデータベース内の複数の同一のテーブルからプルしている場合は、CDC の出力を直接ステージング テーブルにプッシュすれば完了です。

于 2014-01-29T21:21:10.203 に答える