そのため、現在、次のことを達成しようとしています。
SourceTableA は変更データ キャプチャ テーブルで、ナチュラル キーとして I、U、D、I の次に U、I の次に D、I の次に U の次に D、または U の次に D が含まれます。このテーブルのプライマリ キーはナチュラル キーです。 + アクション (I、U、または D)。
TargetTableA は、シーケンス ジェネレーターによって生成された代理キーを持つタイプ 2 の scd テーブルです。
私たちが抱えている主な問題は、まだ挿入されていないレコードの更新を処理することです (代理キーはマッピングにのみ存在し、テーブルには存在しません) が、同じパイプラインに含まれています。
SourceTableA のすべてのレコードをバッチで処理する必要があります。
ルックアップ ロジックが複雑なため、I、U、D パイプラインとして 3 つの異なるソース修飾子を使用することはできません。
Oracle が ins/upd/deletes を処理する方法を制御できないため、生成された代理キーのストアを維持するために動的キャッシュを使用することはできません。参照レコードを挿入する前に更新しようとしていることがわかるまで、実際には機能していました。
私はここで機知に富んでいます。
何が起こるべきかの例のシナリオ:
レコードを挿入すると、このレコードのキーが生成されます (100 など)。active_flag = 'Y' で挿入され、end_date は 'open' です。次に、同じ自然キーの更新レコードが入り、キーが生成され (101)、新しいデータを持つレコードが active_flag = 'Y' で挿入されます。以前に「挿入」された行 100 は、active_flag = 'N' および end_date = (update_row).end_date - 1 秒に非アクティブ化されます。
ありがとう！