Sql server 更改数据捕获和SQL Server分析服务

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

下面是我尝试做的一个例子：

---

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

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

因此，在给定的一个月内，客户123可能有5笔单独的销售交易，每笔交易10美元……每个单独的销售交易可以由不同的销售代表（a、B、C、D、E）处理。在您描述的事实表中，客户123可能有一个50美元的单一记录……但是我们如何对销售代表建模（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不是主键…而是业务键…并且您将使用任意整数作为主键…此任意键称为代理键

以下是我如何为你的维度建立数据模型

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

这同样适用于SalesRep或您希望跟踪某些属性的历史更改的任何其他维度

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

---

顺便说一下，如果你有时间和有兴趣学习更多，我强烈推荐KimBar圣经“数据仓库工具包”…它应该为维度建模场景提供坚实的基础。

< P>你提到你目前有一个包含每月销售数字的事实表。因此，每个客户每月有一个记录。因此，该事实表中的每条记录实际上是当月发生的各个销售“交易”的集合，对应维度

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

基于你的目标

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