如何使用维度中的代理键填充事实表

Question

您能否帮助了解如何使用维度中的代理键填充事实表。

我有以下事实表和维度：

索赔事实

ContractDim_SK ClaimDim_SK AccountingDim_SK ClaimNbr ClaimAmount

合同调光

ContractDim_SK (PK) ContractNbr(BK) ReportingPeriod(BK) 代号

会计昏暗

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

声明昏暗

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

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

1. 首先我将数据加载到维度中（代理键被创建为身份列）

2. 从事务模型 (OLTP) 中，事实表将填充度量（ClaimNbr 和 ClaimAmount）

3. 我不知道如何用维度的 SK 填充事实表，如何知道将我从维度中提取的键放在哪里到事实表中的哪一行（哪个键属于这个 claimNBR？）我应该全部添加合同 Nbr尺寸并在加载事实键时将它们连接在一起？

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

Answer 1

它通常的工作方式：

1. 在您的维度中，您将拥有“自然密钥”（又名“业务密钥”）——来自外部系统的密钥。例如，合同编号。然后为表创建合成（代理）键。
2. 在您的事实表中，所有键最初也必须是“自然键”。例如，合同编号。对于要连接到事实表的每个维度，此类键都必须存在。有时，一个维度可能需要多个自然键（它们共同表示维度表的“粒度”级别）。例如，如果在 State-City 级别建模，Location 可能需要 State 和 City 键。
3. 将您的昏暗表加入自然键的事实表，并从结果中省略事实中的自然键并从昏暗中选择代理键。我通常做一个左连接（事实上左连接暗淡），以控制不匹配的记录。我也一一加入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 添加到其他维度。您已经在合同维度中拥有此数据。这就是星型模式的工作原理 - 您始终可以通过事实表使用合同属性。无需复制它们。
• 我不能肯定（没有足够的信息），但怀疑dim Accounting 和dim Claim 可能设计不正确。如果您打算列出您的个人交易描述和个人索赔属性，那就错了。这将导致维度与事实表一样大。在一个好的设计中，事实表是“又高又瘦”，而维度是“短而胖”。即，在事实表中，您应该有少量字段和大量记录，而在暗淡的大量字段和少量记录中。通常，如果您的 dim 的记录数超过事实表记录的 10-20%，则表明设计不正确。处理这个问题的正确方法是将理赔分解为多个维度，将理赔编号（订单号、发票号、交易号等）作为“

如果你需要更多关于这方面的信息，我推荐这本书：

Star Schema 完整参考

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

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

这可能有点难以消化，但请考虑以下内容。“索赔”本质上是一个信息容器（与“发票”、“订单”等相同）。如果您将所有有用的数据移动到它们的相关维度，那么应该只剩下一个空容器。

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

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

剩下 3 个字段：Claim Number、Claim Name 和 Claim Description。在这一点上，一些设计师创建维度“声明”并将这些领域停放在那里。正如我之前提到的，这是一个错误，因为您的维度中的记录将与事实表中的记录一样多，从而导致严重的问题。

更好的设计是将这些字段留在事实表中。声明编号成为“退化维度”——“空”（不存在）维度的业务密钥。本质上，它只是一个信息容器的 ID，如发票号、订单号等。

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

另一种看待这个的方式：维度通常用于通过某些属性/字段“切片”（剖析）事实。例如，“按国家/地区划分的销售额”、“按工厂位置划分的产品成本”等。但是您不能按说明、注释或其他自由文本进行切片 - 这没有任何意义。

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

在此处阅读有关垃圾维度的更多信息