Question

请帮助您了解如何使用尺寸中的代理键填充事实表。

我有以下事实表和尺寸：

ClaimFacts

ContractDim_SK ClaimDim_SK AccountingDim_SK ClaimNbr ClaimAmount

ContractDim

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

AccountingDim

TransactionNbr（BK） ReportingPeriod（PK）交易代码货币代码（我应该在这里添加ContractNbr吗？OLTP中的原始表有它）

ClaimDim

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

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

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

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

Answer 1

通常的工作方式：

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

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

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

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

Star Schema The Complete Reference

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

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

这可能有点难以消化，但请考虑以下因素。＆＃34;根据权利要求＆＃34;本质上是一个信息容器（与＃34; Invoice＆＃34;，＆＃34; Order＆＃34;等相同）。如果将所有有用的数据移动到相关的维度，那么除了空容器之外什么都不应该留下。

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

报告期间：成为＆＃34;日期＆＃34;的业务关键;尺寸
合同编号：成为＆＃34;合同＆＃34;的业务关键尺寸
索赔金额：保留在事实表格中作为数字（完全加法）事实

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

更好的设计是将这些字段留在事实表中。索赔号变为＆＃34;退化维度＆＃34; - ＆＃34;空的＆＃34; （不存在的）维度。基本上，它只是信息容器的ID，如发票号，订单号等。

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

另一种看待这种情况的方式：尺寸通常用于＆＃34;切片＆＃34; （disect）事实通过一些属性/字段。例如，＆＃34;按国家/地区的销售金额＆＃34;，＆＃34;按工厂位置的产品成本＆＃34;等等。但您无法按描述，备注或其他自由文本进行切片 - 它会使没有意义。

如果您的描述或其他声明属性是结构化的，该怎么办？例如，如果它们用于对您的声明进行分类/分类？在这种情况下，它们不是自由文本，它们是属于维度的属性。例如，您可以设计维度＆＃34;声明类型＆＃34;。或者＆＃34;声明状态＆＃34;。等等。如果这些小属性文件中有太多，你可以将它们组合成一个叫做＆＃34; junk＆＃34;维度（又名＆＃34;个人资料＆＃34;维度），即维度＆＃34;索赔个人资料＆＃34;。这种设计干净而有效。

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

1 个答案: