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

交货信息包括以下表格：

事实交付

• 分支键
• DeliveryDateKey
• 产品密钥
• InvoiceNumber(DD：简并尺寸)
• 数量
• 单位成本
• 线成本

笔记：

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

问题是：事实表没有主键。主键应该是可以唯一标识每次交货的添加键以及ProductKey。但是我无法唯一标识交货。

在源OLTP数据库中，有一个DeliveryID对于每个传递都是唯一的，但是对于用户而言，这是一个内部ID。 InvoiceNumber是供应商的发票编号-手动输入该编号，因此我们得到重复的编号。

在多维数据集中，我仅基于FactDeliveres中的InvoiceNumber字段创建了一个维度。这确实意味着，当我们按InvoiceNumber分组时，我们可能会合并两个交货，因为它们(错误地)具有相同的InvoiceNumber。

我觉得我需要包括DeliveryID(称为DeliveryKey)，但是我不确定如何。

我也是：

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

毕竟，我只想问你：当我的源数据库中包含以下信息时，如何创建一个Deliveries多维数据集

交货头

• DeliveryID(PK)
• 邮寄日期
• 供应商编号(FK)
• InvoiceNumber(手动输入)

交货细节

• DeliveryID(PK)
• 产品编号(PK)
• 数量
• 单位成本

解决方案

我将在事实表中包含数量，单位代码，发票编号，交货编号。 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数据那样结构化，而只是事实和描述这些事实的维度。

事实表PK几乎总是代理键。每个事实都是多个维度的一部分，因此事实具有维度的FK，但没有真正的密钥。

交货事实(行项目)属于分支机构，它具有产品，它是较大的交货的一部分，它发生在特定的日期。听起来像是4个独立的维度。

交货维度具有其自己的PK，并且具有发票编号的维度属性。也许还有整个交付的其他属性。

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