3

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

我有以下事实表和维度：

索赔事实

ContractDim_SK ClaimDim_SK AccountingDim_SK ClaimNbr ClaimAmount

合同暗淡

ContractDim_SK (PK) ContractNbr(BK) ReportingPeriod(BK) 代码名称

会计昏暗

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

ClaimDim

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

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

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

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

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

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

4

1 回答 1

8

它通常的工作方式：

  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 字段。我建议你根本不需要这样的维度。

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

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

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

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

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

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

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

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

在此处阅读有关垃圾尺寸的更多信息

于 2018-03-03T09:50:02.857 回答