問題タブ [scd2]

次のような状況があるとします。

揮発性でないいくつかの属性 (説明と直径 - 修正のための SCD-1 変更によってのみ変更可能) と揮発性の可能性がある属性 (販売グループ、同じ製品の時間の経過とともに変化する可能性がある) を持つディメンション製品）。

そのため、1 つの製品のこれらの揮発性の属性に変化が生じた場合、何らかの方法でそれらを追跡する必要があります。

私はこれらの2つのアプローチを採用しました：

両方の場合:不揮発性属性には SCD-1 を使用し続けます。

アプローチ #1: product_dim で SCD-2 を使用するのは、揮発性属性のみです。

アプローチ #2:販売グループをまったく新しい次元にすると、すべての販売が ETL の瞬間に現在の価値を追跡します。ここでは SCD-2 は必要ありません。

私はデータ ウェアハウスに不慣れで、どちらが優れているのか、その理由を理解しようとしています。私の目標の 1 つは、OLAP ソフトウェアを使用してこれらすべてを読み取ることです。

私はPostgresの初心者です。

Postgres を使用してプロジェクトに SCD タイプ 2 を実装しました。入力ファイルは、毎日約 3,000 万件のレコードを含む完全更新ファイルです。

口座番号がキー列です。

新しいレコードのおおよその数は、1 日あたり 20K になります。ソースからレコードが欠落している場合、そのレコードはターゲットの終了日でクローズされます。クローズされるレコードのおおよその数 - 10,000/日

クエリの実行時間は着実に増加しています。索引付けはプロセスのスピードアップに役立ちますか?

使用するインデックスに関する提案はありますか?

しばらくして、ゆっくりと変化するディメンション タイプ 2 を履歴化するための非常に高速なワンパス マージ ステートメントを考え出しました。

一意の制約のないテーブルで完全に機能します。

ほとんどの場合、一意の制約を持つテーブルでも機能します。しかし、ときどき (通常は履歴の変更が大きい場合)、エラー ORA-00001、一意の制約違反が発生します。もちろん、動作する 2 パスの方法があることは知っていますが、それらは遅くなります。

私の唯一の推測は、Oracle が UPDATE の前に INSERT を実行して、TH_Valid_To_Date を一時的に複製することがあるということです。

（主キーを保持しながら）それを回避する方法はありますか？

ソース テーブル:

履歴表:

マージ：

ETL に問題があります。SCD 1 列と SCD 2 列を含むディメンション テーブルがあります。これらを SCD 変換Changing AttributeでHistorical Attributeそれぞれ と として正しくマッピングしました。

次に、Historical Attribute Options ページで をチェックしUse start and end dates to identify current and expired records、ValidFrom 列を として入力し、ValidTo 列を として入力Start date columnしましたEnd date column。

私が理解しているように、これは、挿入されたレコードには現在の日時値の ValidFrom が与えられ、その ValidTo 列はそのままであることを意味するはずですNULL。また、既に存在するが古いレコードの場合、その ValidTo は現在の日時値になります。

ただし、インポートされるすべてのレコードではなく、一部のレコードでは、挿入された最新のレコードが、ValidFrom および ValidTo レコードにまったく同じ日時で挿入されます。クエリでそのレコードが無効であると見なされ、ファクトテーブルの読み込みに影響が及ぶため、これは非常に苦痛になります。

なぜこれが起こっているのか誰でも助けることができますか?