數據建模中的 SCD-2：如何檢測變化？

Question

我知道 SCD-2 的概念，我正在嘗試通過一些練習來提高我的技能。

我有下一個場景/實驗：

1. 我每天都在調用一個 rest API 來提取有關公司的信息。 在我對數據庫的初始加載中，一切都是新的，所以一切都非常簡單。
2. 第二天，我調用相同的 rest API，它可能返回相同的公司，但其中一些可能（或沒有）發生了一些變化（即，他們改變了規模、利潤、位置……）

我知道如果其余 API 只返回有變化的記錄，SCD-2 可能真的很簡單，但在這種情況下，它也可能返回沒有變化的記錄。

在這種情況下，人們如何檢測公司的數據是否有變化以應用 SCD-2？他們是否比較所有字段？。

有沒有我可以看到的例子？

Answer 1

沒有標准的 SCD-2，甚至沒有它的獨特概念。 它是大量可能方法的總稱。 唯一的機會是練習，看看什么適合您的用例。

在任何情況下，您都必須確定維度的自然鍵以及要保留歷史記錄的屬性集。

當然，您可能會因為決定使用自己的代理鍵而使其變得更加復雜。

您提到該流程有兩種主要類型的界面：

• 您會定期獲得一整套維度數據

• 您獲得“僅更改”（又名增量界面）

矛盾的是，前者比后者更容易處理。

首先，在全維快照中，自然鍵保持不變，這與 delta 接口相反（您可能會為一個實體獲得更多更改）。

此外，您必須處理更改交付延遲甚至更改交付順序錯誤的情況。

下一個重要決定是您是否希望發生刪除。 這在完整接口中又是微不足道的，您必須定義一些約定，這些信息將如何在 delta 接口中傳遞。 Connected 是之前刪除的實體是否可以重新使用（即重新出現在數據中）的問題。

如果您支持刪除/重用，則必須考慮如何在維度表中顯示它們。

在任何情況下，您都需要維度中的一些附加列來覆蓋歷史信息。

一些實現使用change_timestamp ，另一些實現使用有效間隔valid_from和valid_to 。

甚至其他實現都聲稱需要額外的序列號——因此您可以避免使用相同時間戳進行更多更改的陷阱。

因此，您會看到，在尋找某些特定實現之前，您需要仔細確定上述選項。 例如full和delta接口導致完全不同的實現。