0

我们正在使用 Snowflake 数据库中的 Data Vault 方法实施新的数据存储。我们的目的是尽可能地坚持最新的标准和最佳实践，例如仅插入方法并尝试避免各种反模式，例如在可行的情况下驱动密钥关系（请参阅此处的评论以了解有关驱动密钥的讨论）。

以下是我们数据中与一段时间内分配给属性的评级相关的部分的简化示例（想想酒店星级或类似评级）。

其核心是将房产与评级联系起来的表格。以下示例显示了针对两种不同方案的单个属性的评级历史记录。

PropertyRatingID  PropertyID   RatingSchemeID RatingID   EffectiveDate
1                 1            1              1          2020-01-01
2                 1            1              2          2020-01-02
3                 1            1              1          2020-01-03
4                 1            2              3          2020-01-02
5                 1            2              4          2020-01-03

有关数据结构的相关信息。

  • PropertyRatingID 是确保唯一性的身份密钥，没有商业意义。
  • 在任何给定时间，房产只能针对单一方案进行单一评级，但可以在多个方案下进行评级
  • PropertyID、RatingSchemeID 和 EffectiveDate 不需要是唯一的组合。
  • EffectiveDate 不代表记录输入系统的日期，并且可以回溯到过去很长的持续时间，从而在生效日期和应用更改的日期之间创建一个双时态情况。
  • PropertyID、RatingSchemeID 和 RatingID 都是提供描述性数据的其他表的外键。在我们的模型中，财产已经作为一个枢纽而存在。

上面的时间线可以描绘如下。

Date        Scheme1Rating  Scheme2Rating
2020-01-01  1              NULL
2020-01-02  2              3
2020-01-03  1              4
2020-01-04  1              4

我最初的建模尝试是为 RatingID 建立一个中心，在属性和评级之间建立一个链接，并使用 PropertyRatingID 连接到该链接的卫星，其中包含所有其他信息（主要是 BrandID 和 EffectiveDate），以使其具有多用途。事实证明这很难使用，因为更改背后的驱动密钥（PropertyID 和 BrandID 在链路和卫星之间传播）。

就情况的双时性而言，重点将放在获取最近记录的一组生效日期（即最近的系统日期）上，以创建一段时间内的评级历史，例如 EffectiveEndDate 相当于LEAD(EffectiveDate) OVER(PARTITION BY PropertyID,RatingID ORDER BY EffectiveDate ASC)原始表。虽然我们不会定期使用过去系统时间的值记录，但我们有时会临时查看这些记录，以解释报告期间之间历史记录的变化。

一个简单的解决方案是跨源系统中的多个表连接以展平数据，将其分离并生成每个评级方案的卫星并将其直接附加到属性中心。这将为我们提供一个短期的解决方案，但不够灵活（任何新的评级方案都需要一个新的中心），并且仍然需要这些卫星是多活动的，以保持源系统中当前的多个生效日期。

我相信理想的解决方案至少需要一个与驱动钥匙相关的枢纽，并可能需要第二个与为物业分配评级相关的枢纽。我的大部分阅读（参见上一个链接和这篇文章）暗示我的卫星应该连接到集线器而不是链接。

使用 Data Vault 方法对此进行建模的有效方法是什么？

我有兴趣讨论所提出的解决方案的收益，例如额外的“弱”集线器与解决更复杂查询中的驱动关键问题。

4

1 回答 1

1

据我了解，这种情况更像是一个 LINK/SAT，其中 PropertyID、RatingSchemeID 作为 LINK 自然键（链接到 Property 和 RatingScheme HUB）和 SAT 中的 RatingID（挂在 LINK 上）。

于 2020-01-17T13:59:43.617 回答