0

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

交付信息由下表组成：

事实交付

  • 分支键
  • 交货日期密钥
  • 产品密钥
  • InvoiceNumber（DD：退化维度）
  • 数量
  • 单位成本
  • 线路成本

笔记：

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

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

在源 OLTP 数据库中，有一个 DeliveryID，对于每个交付都是唯一的，但这是一个对用户没有意义的内部 ID。InvoiceNumber 是供应商的发票编号——这是手动输入的，所以我们得到了重复。

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

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

我也是：

  1. 将其用作 InvoiceNumber 维度的基础键？
  2. 创建一个每次有新交付时都会增长的 DimDelivery？这可能意味着某些属性来自 FactDeliveries 并进入 DimDelivery，例如 DeliveryDate、Supplier、InvoiceNumber。

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

DeliveryHeaders

  • DeliveryID (PK)
  • 交货日期
  • 供应商 ID (FK)
  • 发票号码（手动输入）

交货详情

  • DeliveryID (PK)
  • 产品 ID (PK)
  • 数量
  • 单位成本
4

2 回答 2

3

我会在事实表中包含 Quantity、UnitCode、InvoiceNumber、DeliveryID。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 数据那样结构化 - 它完全取决于事实以及描述它们的维度。

于 2008-09-29T18:11:48.287 回答
0

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

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

Delivery维度有自己的PK，并且有发票号的维度属性。另外，也许还有整体交付的其他属性。

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

于 2008-09-29T19:42:18.880 回答