如何使用尺寸的Surrogate键填充事实表

Question

您能帮忙了解如何使用尺寸的Surrogate键填充事实表。

我有以下事实表和尺寸：

ClaimFacts

ContractDim_SK ClaimDim_SK AccountingDim_SK ClaimNbr ClaimAmount

ContractDim

ContractDim_SK（PK）ContractNbr（BK）ReportingPeriod（BK）代码名称

AccountingDim

TransactionNbr（BK）ReportingPeriod（PK）TransactionCode CurrencyCode（我应该在这里添加ContractNbr吗？OLTP中的原始表有它）

ClaimDim

CalimsDim_Sk（PK）CalimNbr（BK）ReportingPeriod（BK）ClaimDesc ClaimName（我应该在这里添加ContractNbr吗?? OLTP中的原始表有它）

我将数据加载到事实表中的逻辑如下：

1. 首先，我将数据加载到维度中（将Surrogate键创建为标识列）
2. 从事务模型（OLTP），事实表将填充度量（ClaimNbr和ClaimAmount）
3. 我不知道如何使用尺寸的SK填充事实表，如何知道把我从实际表中哪一行拉出的键的位置（哪个键属于这个claimNBR？）我应该在所有中添加合同Nbr将密钥加载到事实时，维度并将它们连接在一起？

这样做的正确方法是什么？请帮忙，谢谢

Answer 1

它通常的工作方式：

1. 在您的维度中，您将拥有“自然键”（又名“业务键”） - 来自外部系统的键。例如，合同号。然后为表创建合成（代理）键。
2. 在您的事实表中，所有键最初也必须是“自然键”。例如，合同号。对于要连接到事实表的每个维度，必须存在此类键。有时，维度可能需要几个自然键（统称为维度表“粒度”级别）。例如，如果在州 - 城市级别建模，则位置可能需要州和城市密钥。
3. 将您的昏暗表连接到自然键上的事实表，并从结果中省略自然键和从昏暗中选择surrogat键。我通常做左连接（事实上左连接昏暗），以控制不匹配的记录。我也一个接一个地加入dims（以便更好地控制正在发生的事情）。

基本示例（使用T-SQL）。假设您有以下2个表格：

Table OLTP.Sales
(   Contract_BK, 
    Amount, 
    Quanity)

Table Dim.Contract
(   Contract_SK,
    Contract_BK,
    Contract Type)

要交换密钥：

SELECT
     c.Contract_SK
    ,s.Amount
    ,s.Quantity
INTO
    Fact.Sales
FROM
    OLTP.Sales s LEFT JOIN Dim.Contract c ON s.Contract_BK = c.Contract_BK

-- Test for missing keys
SELECT 
    * 
FROM 
    Fact.Sale 
WHERE 
    Contract_SK IS NULL

另外，我相信你的设计有些错误。

• 报告期应该是一个单独的维度。通常它是一个包含所有日期/期间相关属性的日历表。
• 您当然不应该将ContractNbr添加到其他维度。您已在合约维度中拥有此数据。这就是星型模式的工作原理 - 契约属性总是可以通过事实表获得。无需复制它们。
• 我不能肯定地说（没有足够的信息），但怀疑昏暗的会计和昏暗的索赔可能设计不正确。如果您打算列出您的个人交易描述和个人索赔属性，那就错了。它将产生与事实表一样大的维度。在一个好的设计中，事实表是“高而瘦的”，而尺寸则是“短而肥胖”。即，在事实表中，你应该有很少的字段和大量的记录，而在dims中有很多字段和很少的记录。通常，如果您的dim的记录数超过事实表记录的10-20％，则表明设计不正确。处理此问题的正确方法是将声明分解为多个维度，并将声明编号（订单号，发票编号，交易编号等）保留为事实表中的“简并维度”。这是一个高级主题，但你显然需要它适合你的情况。重要的原因是：如果您的尺寸与事实表一样高，那么您的性能会越来越差。如果trasactions或claim的数量在数百万条记录中，那么它可能会很慢，以至于它会破坏你的设计。

如果您需要更多相关信息，我推荐这本书：

Star Schema The Complete Reference

[编辑以回答后续问题]：

我并不是要从Claim维度中删除ClaimNbr字段。我建议你根本不需要这样的尺寸。

这可能有点难以消化，但请考虑以下内容。 “索赔”本质上是信息的容器（与“发票”，“订单”等相同）。如果将所有有用的数据移动到相关的维度，那么除了空容器之外什么都不应该留下。

例如，假设您的OLTP声明表包含以下字段：声明编号，报告期间，声明说明，声明名称，合同编号，声明金额。您可以按如下方式对它们建模：

• 报告期间：成为“日期”维度的业务关键
• 合同号：成为“合同”维度的业务关键
• 索赔金额：保留在事实表格中作为数字（完全加法）的事实

这留下3个字段：索赔号，索赔名称和索赔说明。在这一点上，一些设计师创建维度“索赔”并将这些字段停放在那里。正如我之前提到的，这是一个错误，因为您的维度中的记录将与事实表中的记录一样多，从而导致严重的问题。

更好的设计是将这些字段留在事实表中。声明号码变为“退化维度” - “空”（不存在）维度的业务键。从本质上讲，它只是信息容器的ID，如发票号，订单号等。

声明名称和声明说明也应保留在事实表中，并成为“非数字”（非加性）事实。如果你需要在报告中显示它们，它很容易做到，你可以计算它们，对它们进行条件逻辑，测量它们的长度等。

查看此内容的另一种方式：维度通常用于通过某些属性/字段“切片”（disect）事实。例如，“按国家/地区的销售额”，“按工厂位置的产品成本”等。但您无法按描述，注释或其他自由文本进行切片 - 这没有任何意义。

如果您的描述或其他声明属性是结构化怎么办？例如，如果它们用于对您的声明进行分类/分类？在这种情况下，它们不是自由文本，它们是属于维度的属性。例如，您可以设计维度“声明类型”。或“索赔状态”。等等。如果这些小属性文件中有太多，你可以将它们组合成所谓的“垃圾”维度（又名“简档”维度），即维度“索赔简档”。这种设计干净而有效。

Read more on junk dimensions here