变更数据捕获和 SQL Server 分析服务

Question

我正在设计一个数据库应用程序，其中数据会随着时间而变化。我想保留历史数据并允许我的用户使用 SQL Server Analysis Services 对其进行分析，但我正在努力想出一个允许这样做的数据库架构。我想出了一些可以跟踪更改的模式（包括依赖 CDC），但是我不知道如何将该模式转换为 SSAS 中的工作 BISM。我还能够创建一个可以很好地转换为 BISM 的模式，但是它没有我正在寻找的历史功能。是否有任何既定的最佳实践来做这种事情？

这是我正在尝试做的一个示例：

我有一个名为 Sales 的事实表，其中包含每月的销售数据。我还有一个名为“客户”的常规维度表，它允许用户查看按客户细分的销售数据。客户和销售代表之间存在多对多的关系，因此我可以创建一个称为责任的参考维度来引用客户维度，并创建一个销售代表参考维度来引用责任维度。我现在通过参考维度销售链链接到销售代表的销售事实 -> 客户 -> 责任 -> 销售代表，这使我可以查看按销售代表细分的销售数据。问题在于，销售事实并不是唯一会随着时间而改变的东西。我还希望能够保留在特定销售事实发生时哪个销售代表负责客户的历史记录。我还想知道销售代表的办公室在特定销售事实发生时的位置，这可能与他当前的位置不同。我还可能知道在特定销售事实时客户组织的规模，这也可能与当前不同。我不知道如何以对 BISM 友好的方式对此进行建模。

Answer 1

您提到您目前有一个包含月度销售数据的事实表。所以每个客户每个月有一个记录。因此，该事实表中的每条记录实际上都是相应维度在当月发生的单个销售“交易”的聚合。

因此，在给定的月份中，客户 123 可能有 5 笔单独的销售交易，每笔 10 美元...并且每笔单独的销售交易都可以由不同的销售代表（A、B、C、D、E）处理。在您描述的事实表中，客户 123 将有一条 50 美元的记录……但是我们如何为 SalesReps（A-B-C-D-E）建模？

根据您的目标...

• 能够维护在特定销售事实发生时销售代表对客户负责的历史记录
• 了解销售代表的办公室位于在特定销售事实发生时
• 了解客户组织的规模在特定销售事实时

...我认为在较低粒度上建模会更容易...特别是销售交易事实表，每个销售交易有 1 条记录。每笔销售交易都会有一个客户和一个销售代表。

FactSales
    DateKey (date of the sale)
    CustomerKey (customer involved in the sale)
    SalesRepKey (sales rep involved in the sale)
    SalesAmount (amount of the sale)

现在对于历史更改跟踪...任何具有您想要跟踪其历史更改的属性的维度都需要建模为“缓慢变化的维度”，因此需要使用“代理键”。因此，例如，在您的客户维度中，客户 ID 不会是主键...而只是业务键...您将使用任意整数作为主键...这个任意键被引用to 作为代理键。

这是我为您的维度建模数据的方式...

DimCustomer
    CustomerKey (surrogate key, probably generated via IDENTITY function)
    CustomerID (business key, what you will find in your source systems)
    CustomerName
    Location (attribute we wish to track historically)
    -- the following columns are necessary to keep track of history
    BeginDate
    EndDate
    CurrentRecord

DimSalesRep
    SalesRepKey (surrogate key)
    SalesRepID (business key)
    SalesRepName
    OfficeLocation (attribute we wish to track historically)
    -- the following columns are necessary to keep track of historical changes
    BeginDate
    EndDate
    CurrentRecord

FactSales
    DateKey (this is your link to a date dimension)
    CustomerKey (this is your link to DimCustomer)
    SalesRepKey (this is your link to DimSalesRep)
    SalesAmount

这样做是允许您为同一客户拥有多条记录。 前任。 CustomerID 123 于 2012 年 3 月 5 日从 NC 移至 GA...

CustomerKey | CustomerID | CustomerName | Location | BeginDate | EndDate | CurrentRecord
1 | 123 | Ted Stevens | North Carolina | 01-01-1900 | 03-05-2012 | 0
2 | 123 | Ted Stevens | Georgia        | 03-05-2012 | 01-01-2999 | 1

这同样适用于 SalesReps 或您希望在其中跟踪某些属性的历史变化的任何其他维度。

因此，当您按 CustomerID、CustomerName（或任何其他非历史跟踪属性）对销售交易事实表进行切片时，您应该会看到一条记录，其中包含针对该客户的所有交易汇总的事实。如果您决定按 CustomerName 和 Location（历史跟踪的属性）分析销售交易，您将看到与客户在该位置时的销售额相对应的客户位置的每个“版本”的单独记录。

顺便说一句，如果您有时间并有兴趣了解更多信息，我强烈推荐 Kimball 的圣经“数据仓库工具包”……它应该为维度建模场景提供坚实的基础。

Answer 2

既定的最佳实践方式是一种具有缓慢变化维度的维度模型。销售代表经常被用来描述 SCD 的有用性。例如，如果销售代表转移到新领域，奖金与其团队绩效挂钩的销售经理不希望他们的总数下降。 SCD 非常适合跟踪此类事情（以及您描述的情况），并允许您查看历史上任何时间点的情况。

花一些时间在Ralph Kimball's website 上开始吧。我建议您阅读的前 3 篇文章是缓慢变化的维度、缓慢变化的维度第 2 部分和维度建模的 10 条基本规则 .

为了获得成功，需要注意以下几点：

1. 您不是在设计 3NF 事务数据库。熟悉非规范化。
2. 确保您了解粒度的含义并明确定义数据库的粒度。
3. 不要使用自然键作为键，也不要将任何智能添加到代理键中（时间键除外）。
4. 您的应用程序的目标应该是查询速度以及易于理解和导航。
5. 了解类型 1 和类型 2 缓慢变化的尺寸并知道在哪里使用它们。
6. 确保您在业务方面有一个有权“断绝关系”的赞助商。你会发现组织中不同的人对同一件事有不同的定义，你需要一个有权做出决定的执行者。要明白我的意思，请让组织中的 5 个不同的人来定义“客户”或“毛利润”。你会很幸运有 2 个人以相同的方式定义。
7. 不要试图让它飞起来。阅读The Data Warehouse Lifecycle Toolkit 并接受这些想法，即使它们起初看起来很奇怪。他们工作。
8. OLAP 功能强大，如果实施得当，可以改变生活。如果不是这样，那绝对是一场噩梦。
9. 玩得开心！