0

我有我的 Fact 表，其中包含 Policy 数据，并且我想将 Policy Products 详细信息添加到仓库中。一项政策获得不同类型的产品，并且价值也是动态的。

例如：Policy01 可能有两个产品 Building & Contents，其中保险金额分别为 1000 和 500。并且 Policy02 仅获得 750 的建筑。

有大约 30 种产品可用，我需要存储每个保单的每种产品的保额、总保费和净保费。因此，如果我将每种产品类型的单独列添加到事实表中，它将添加 120 列（目前有 23 列）。每个政策最多 5 个产品，因此只有 20 列将包含值，其他列保持为空。

事实表可以有 100 多列吗？可以连续保留这么多空值吗？或者有没有其他方法可以解决这个问题？

我是 DWH 的新手，希望有人能告诉我如何将这些添加到我的事实表中。

4

2 回答 2

2

事实表中有 100 多列是不行的；这是数据模型不正确的症状（缺失值也是如此——设计良好的事实表不应该有）。

事实表设计的逻辑如下：首先，在表“粒度”上——它将包含的数据的最原子级别。在您的情况下，数据粒度由策略编号 + 产品定义。它们共同唯一标识了您可用的最详细信息。

然后，确定你的“事实”。通常，事实是您可以聚合的数据片段（总和、计数、平均值等）。在您的情况下，它们是 Insured_Value、Gross_Premium、Net_Premium。

最后，为这些事实（维度）定义业务上下文。在您的情况下，它们是策略和产品（很可能，您还会有某种日期）。

您生成的事实表应如下所示：

  • Policy_Date
  • 保单号码
  • 产品_ID
  • 保险价值
  • Gross_Premium
  • Net_Premium

Policy_Date 将提供与“日历”维度的连接，Product_ID 将连接到“产品”维度（包含您的 30 个产品及其描述的表格）。

Policy_Number 是所谓的“退化维度”——它是一个通常不连接到任何维度的 ID（但如果需要也可以）。它存储在事实表中，仅作为参考。有些人在模型中添加了“Policy”维度，但通常这是一个设计错误——这样的维度太“高”，与事实表的大小相当，这会大大降低模型的性能。通常最好将策略属性拆分为多个小维度，并将策略编号保留为退化维度。

因此，您的包含 5 个产品的典型策略将在事实表中表示为 5 条记录，而不是一条包含 5 个字段的记录。这是关键的区别 - 永远不会以事实表字段的名称存储信息（在您的情况下为产品）。

于 2017-05-02T15:37:14.070 回答
2

一种方法是添加产品维度： 在此处输入图像描述

然后，您可以按策略返回总计：

SELECT
    PolicyKey
    SUM(PolicyProductValue) AS PolicyValue
FROM
    Fact.PolicyProductValue
GROUP BY
    PolicyKey
;

或产品：

SELECT
    ProductKey,
    SUM(PolicyProductValue) AS ProductValue
FROM
    Fact.PolicyProductValue
GROUP BY
    ProductKey
;

或两者：

SELECT
    PolicyKey,
    ProductKey,
    SUM(PolicyProductValue) AS PolicyProductValue
FROM
    Fact.PolicyProductValue
GROUP BY
    PolicyKey,
    ProductKey
;

这种方法将产品从列移动到行。

这种技术提供了几个好处：

  1. 添加新行比添加列更容易。
  2. 您可以将常用过滤器添加到Dim.Product.
  3. Dim.Product提供创建产品层次结构的位置。例子：

| Product Key | Product Name | Product Group | | ----------- | ------------ | --------------------| | 0 | Building | Building & Contents | | 1 | Contents | Building & Contents |

于 2017-05-02T11:24:29.147 回答