Question

我正在建立一个包含餐馆送货信息的数据仓库。数据存储在SQL Server 2005中，然后放入SQL Server Analysis Services 2005多维数据集中。

交货信息包括以下表格：

FactDeliveres

BranchKey
DeliveryDateKey
的ProductKey
InvoiceNumber（DD：退化维度）
数量
UnitCosT
Linecost

注意：

FactDeliveres的粒度是发票上的每一行
产品维度包括供应商信息

问题：事实表没有主键。主键应该是唯一标识每个交付加上ProductKey的东西。但我无法唯一确定交付。

在源OLTP数据库中，有一个DeliveryID对于每次传递都是唯一的，但这是一个对用户毫无意义的内部ID。 InvoiceNumber是供应商的发票号码 - 这是手动输入的，因此我们会重复发送。

在立方体中，我仅根据FactDeliveres中的InvoiceNumber字段创建了一个维度。这意味着，当您按InvoiceNumber分组时，您可能只会因为（错误地）具有相同的InvoiceNumber而获得2次交付。

我觉得我需要包含DeliveryID（称为DeliveryKey），但我不确定如何。

所以，我：

使用它作为InvoiceNumber维度的基础密钥？
创建一个DimDelivery，每次有新的交付时增长？这可能意味着一些属性来自FactDeliveries并进入DimDelivery，如DeliveryDate，Supplier，InvoiceNumber。

毕竟，我可以问你：当我在源数据库中有以下信息时，如何创建Deliveries多维数据集

DeliveryHeaders

DeliveryID（PK）
DeliveryDate
SupplierID（FK）
InvoiceNumber（手动输入）

DeliveryDetails

DeliveryID（PK）
ProductID（PK）
数量
UnitCosT

Answer 1

我会在事实表中有Quantity，UnitCode，InvoiceNumber，DeliveryID all。 InvoiceNumber和DeliveryID都是退化维度，因为它们会随着每个事实（或很少的事实）而改变。如果每个订单上有大量商品，您可以将它们放在自己的维度中。如果您在发票上有多次交货，则下面的模型可能不是100％正确，但它会很接近。看看Kimball，他可能有一个关于这个业务场景的星型模式的例子。

Fact table:
OrderDateID (not in your model, but probably should be, date dimension in a role)
DeliveryDateID (date dimension in a role)
SupplierID (supplier dimension surrogate key)
InvoiceID (invoice dimension surrogate key)
ProductID (product dimension surrogate key)
Quantity (fact)
UnitCost (fact)
InvoiceNumber (optional)
DeliveryID (optional)

使用通常的日期维度表和以下维度：

Supplier Dim:
SupplierID (surrogate)
SupplierCode and data

Invoice Dim:
InvoiceID (surrogate)
InvoiceNumber (optional)
DeliveryID (optional)

Product Dim:
ProductID (surrogate)
ProductCode and Data

永远记住，您的（星型模式）数据仓库根本不像您的OLTP数据那样构建 - 它完全取决于事实以及描述它们的维度。

Answer 2

事实表PK几乎总是代理键。每个事实都是几个维度的一部分，所以事实上FK是维度的，但没有真正的关键。

交付事实（一个行项目）属于一个分支，它有一个产品，它是一个更大的交付的一部分，它发生在特定的日期。听起来像4个独立的维度。

交付维度拥有自己的PK，并且维度属性为发票编号。或许，也许是整个交付的其他属性。

每个交货行项目事实与一个交货和该交货的发票号相关联。

如何设计交付数据的事实表

2 个答案: