sql-server - 如何对事实表建模

Question

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

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

• 我们第一季度的售价是多少？
• 第一季度我们向女性销售的产品售价是多少钱？
• 第一季度我们向 30-35 岁之间的女性销售了多少钱？
• 第一季度，我们向居住在纽约的 30-35 岁女性销售了多少钱？

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

• 去年我们的同类服装卖了多少钱？

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

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

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

事实销售

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

DimProduct - fk 到包含产品信息的表，例如(产品名称)

DimUser - fk 到包含用户信息的表，例如(年龄、性别)

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

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

感谢我能得到的有关此问题的所有意见。

Answer 1

我认为你走在正确的道路上。仅使用一张涵盖销售额的事实表就可以回答上述所有问题。

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

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

现在，人们会遇到一个问题，即如何获得正确的计数，即“涉及黑色衣服的销售数量”。我们在以前的工作场所遇到了这个问题 - 我确信一定存在一些“最佳实践”，我们最终或多或少地在事实表中引入了 SaleID (或 TransactionID)并执行count(distinct SaleID)。这缺乏优雅，但有效。

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

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