嵌套/分数对象的维度模型聚合

Question

假设我创建了一个游戏，用户可以在其中提交通过在线市场买卖商品的请求。每个销售请求可以包含多种商品类型的“子请求”。每个买入请求只能满足其中一个子请求，然后父卖出请求不再有效/可用。 （如果您愿意，可以将市场动态称为混乱，但请耐心等待......）

我想汇总这些数据以开始了解和分析趋势。为了论证的缘故，我们假设市场中有足够的行动，我无法有效地存储和/或查询原始的交易级数据，因此我必须使用聚合。

每个销售请求都会生成一个日志条目，大致如下：

{
    sellRequestID: 123,
    userID: 456,
    timestamp: 1449043403,
    country: "United States",
    goods: [ "eggs", "beef", "chicken" ]
}

购买请求可能会生成大致如下的日志条目：

{
    buyRequestID: 987,
    sellRequestID: 123,
    userID: 789,
    timestamp: 1449043408,
    good: "eggs"
}

我希望能够回答以下问题：

1. 按日期和国家/地区提交的销售请求总数是多少？
2. 按日期和国家/地区提交的单个商品销售请求（子请求）的总数是多少？ （在一定程度上，这揭示了“请求膨胀因素”，即每个销售请求的平均商品数量）。
3. 按日期、国家和类型提交的子请求总数是多少（即卖方市场中每种商品的总“可用性”是多少）？

假设我有相对标准的维度表：

users            countries        goods
-----            ---------        -----
456 John Smith   1 United States  1 eggs
789 Jane Doe     2 Canada         2 beef
... ...          . ...            3 chicken

可以回答我的第一个问题的表格可能如下所示：

Date        CountryID        Total Requests
2015-12-01  1                1,000,000
2015-12-01  2                200,000
...

可以回答我的第二个问题和第三个问题的表格可能如下所示：

Date        CountryID  GoodID      Total Requests
2015-12-01  1          1           600,000
2015-12-01  1          2           300,000
2015-12-01  1          3           400,000
...

是否有一种设计可以让我在一个表格中回答所有问题？我考虑了几种可能性，正在寻找任何实际经验或建议。

如果我使用上面的第二个架构，我最终会在尝试回答问题 1 时夸大父请求的数量，并且会失去对这些父请求计数“重复数据删除”的能力。

一种方法可能是使用如下架构：

Date       CountryID  GoodID    Parent Requests    Child Requests

如果我这样做，为了避免之前场景中的通货膨胀，我需要“分解”父请求 - 例如包含三个商品的请求仍会在三行的子请求列中添加 1，但会在父请求聚合中添加 1/3。类似地，包含两种商品的请求将在其两行中将 1/2 添加到父请求列。所以我可能有这样的数据：

Date       CountryID  GoodID    Parent Requests    Child Requests
2015-12-01 1          1         1/3                1
2015-12-01 1          2         5/6                2
2015-12-01 1          3         5/6                2

现在我对父请求（忽略 goodID）列的聚合将总计为预期的 2 个请求，但我仍然能够理解在 2 个父请求中，我有机会购买一次鸡蛋，两次购买牛肉，和鸡肉两次。

这种分数方法有什么缺点吗？我是不是想硬塞一些不应该硬塞的东西？提前致谢。

Answer 1

本身并不是一个直接的答案，而是一些想法。

1) 您的方法的缺点是父请求中的分数将是半加法的，因此您需要仔细控制聚合该列的任何查询。这可能看起来微不足道，但随着您添加维度或最终用户社区的增长，它可能会让您大吃一惊。如果您走这条路，您可能希望将名称“父请求”和“子请求”替换为更注重业务的名称。您可以与您的用户讨论这个问题。即兴发挥，我可能会尝试用“Requests”替换“Child Requests”，因为它直接应用于自然键，并且可能用“Good_to_Request_Ratio”之类的东西替换“Parent Requests”。 （我已经不喜欢了。）

2) 适当索引，加权桥接表可以提供解决方案。但它的行数更多。在这种情况下，您添加一个桥接到 Good 维度的“Request”维度。

3) 我不明白用一张事实表回答所有问题的要求。表格设计首先必须满足功能和非功能分析要求。 Country/Date grain 中的一张表和 Country/Date/Good 中的另一张表很好，尤其是当较细粒度的“请求”度量是半累加的并且不会与较粗粒度相加时。