4

我即将在星型模式中创建一个包含事实和维度的数据仓库。

我想回答的业务问题通常是：

  • 我们在第一季度卖了多少钱？
  • 我们在第一季度卖给了女性多少钱？
  • 我们在第一季度向 30-35 岁的女性卖了多少钱？
  • 我们在第一季度向居住在纽约的 30-35 岁女性卖了多少钱？

  • 我们在第一季度向居住在纽约的 30-35 岁女性卖了多少钱？

  • 去年我们在服装类别中卖了多少钱？

  • 去年我们的蓝色牛仔裤产品卖了多少钱？
  • 去年，我们向居住在澳大利亚的 40 至 42 岁的男性销售了蓝色牛仔裤产品多少钱？

我正在考虑一个小时粒度的日期维度（指定年、月、日、小时、季度、日名称、月名称等）。我也在考虑产品维度和用户维度。

我想知道这些问题是否可以使用单个事实表来回答，或者是否适合创建多个事实表？我正在考虑一个表格，例如：

事实销售

DimDate - 转至包含日期信息的表格（例如季度、星期几、年、月、日）

DimProduct - 指向包含产品信息的表，例如（产品名称）

DimUser - fk 到包含用户信息的表，例如（年龄，性别）

TotalSales - 那些特定日期、产品和用户的所有销售额的总和。

另外，如果我想测量展位的总销售额（金钱）和总销售额？创建一个具有相同维度但使用 TotalNumberOfSales 作为事实的新事实表是否合适？

感谢我能得到的所有输入。

4

2 回答 2

3

我认为你在正确的轨道上。上述所有问题都应该可以仅使用一个涵盖销售额的事实表来回答。

我认为应该从不聚合开始，如果需要，以后再聚合。考虑到一个销售可以包含多个产品和多个项目，我将其组织如下......销售中每个产品的一个事实行（通常是发票上的行，所以我称之为“订单行”或“销售线”），也许还有三个柜台属性：

  • NumItems- 商品数量，即如果客户购买了三个相同的产品，则为 3。
  • NumLines- “订单行”的数量 - 应始终为 1。在稍后聚合数据时可能很有用（已经拥有sum(NumLines)而不是count(*)在 SQL 中），或者在添加更正项时 ( NumLines = -1)。
  • NumSales- 一个小数，因此可以将其相加得出销售数量（即，如果销售涉及三种不同的产品并因此包含三个订单行，则为 0.333）。

现在，人们会遇到一个问题来获得正确的计数，即“涉及黑色衣服的销售数量”。我们在我以前的工作场所遇到过这个问题——我确信为此必须存在一些“最佳实践”，我们或多或少地通过SaleID在事实表（或TransactionID）中引入 a 和 do 来结束count(distinct SaleID)。这缺乏优雅，但有效。

在我们的设置中，我们有几个货币属性 - 最重要的，一个是收入（在支付与所售商品相关的直接成本后剩下的收入），另一个是营业额（客户为商品支付的价格）。销售税或增值税可能会增加更多的复杂性。可以只使用一个货币属性，然后在事实表中将销售额拆分为多行，但我认为我更愿意在销售行事实表中推荐多个货币列。事实表中的所有内容都以“基础货币”（在我们的例子中为欧元）计算，然后我们有一个汇率维度来跟踪确切的金额。

我认为包含一天中的小时的日期维度没有意义。在我以前的工作中，我将仓库保存在 postgres 中，实际上我在没有日期维度的情况下管理得很好——尽管日期维度被认为是“最佳业务实践”，但我发现从性能方面来说，就我们所有的目的而言，我们得到了更好的性能通过使用标准的 postgres 日期函数而不是在日期维度中拖动。我用它玩了很多，我认为最后我发现最优化的是将日期和时间分成两个不同的属性。（时区和夏令时让我非常头疼......）

于 2012-07-11T11:01:38.997 回答
2

我同意 tobixen - 你走在正确的轨道上。

我建议您阅读 Ralph Kimball 的书“The Data Warehouse Toolkit”，尤其是关于零售的一章——它深入探讨了销售事实。

日期维度就像有一个日历表 - 您可以根据季度、会计月份和其他特定于日期的业务进行拆分。我通常同时保留日期键和时间戳数据类型，因此我们可以使用财政日历来做事。如果您需要将表格的粒度保持在该级别，我实际上会有一个单独的时间维度，一天中的几个小时或几分钟等都有桶。我怀疑您是否需要每小时。

这是我要做的：

声明事实表的粒度：

每个订单行 1 行

请注意，grain 如何不包含任何不能唯一标识行的内容。

订单行的维度属性：

Date
Time (if needed, and bucketed by hour/minute etc)
Product
Customer

订单行的退化维度（这些是与交易相关的代码）：

Order Number
Order Line Number

一些示例措施：

Item Price at time of Sale (optional, may be useful in some situations)
Discount Amount
Sale Dollars

这应该回答所有这些问题。

对于总计，过滤维度属性后的简单 COUNT / SUM 应该可以正常工作。

您应该考虑到客户维度是最难建模的维度之一，Kimball 在他的书中用了整整一章来讨论客户维度。

于 2012-07-11T14:07:21.820 回答