根据金博尔的说法：
一个维度可以包含对另一个维度表的引用。例如，银行账户维度可以引用代表账户开立日期的单独维度。
例如，这向我表明，如果您想跟踪一段时间内开设的账户数量，您可以直接查询账户维度。这很常见吗？
在我的例子中，我将 Customer 建模为一个维度，它还引用 Date（用于 Signed Up Date）和 Demographic 维度。
例如，企业询问的一种常见查询是，随着时间的推移，按人口统计我们有多少注册。这根本不涉及事实表。所有这些都可以通过总结维度本身来解决。这是否表明架构设计中存在某种气味，或者这只是某些维度的特征，其中维度本身对业务具有一定的意义？
我在 Redshift 中有一个星型模式数据库。我正在使用order_facts以下相关列在事实表上运行聚合：
total- FLOAT- 总订单成本
payment_date- INTEGER- 付款日期格式YYYYMMDD
shop_id-INTEGER商店维度的外键
我正在使用以下维度表：
日期
id- INTEGER- 日期格式YYYYMMDD
date- DATE- SQL 日期格式字段
商店
id--INTEGER表的主键
created- DATETIME- 商店创建时间的时间戳
我的目标是获取每个商店前 30 天的订单总量表。
我的查询是这样的，应该给出准确的答案。但是，它需要半个多小时才能运行：
SELECT of.shop_id, SUM(of.total) FROM order_facts of
INNER JOIN shops s
ON of.shop_id = s.id
INNER JOIN dates d
ON of.payment_date = d.id
WHERE d.date <= (s.created + INTERVAL '30 days')
GROUP BY of.shop_id
我尝试像这样重写它，但是在运行超过 20 分钟后查询仍然没有完成
SELECT SUM(r.total), r.shop_id
FROM (
SELECT s.created, of.shop_id, of.total, of.payment_date
FROM order_facts of
INNER JOIN shops s
ON of.shop_id = s.id
) r
INNER JOIN dates d
ON r.payment_date = d.id
WHERE d.date <= (r.created + INTERVAL '30 days')
GROUP BY r.shop_id
我目前不明白为什么要花这么长时间才能运行。理解这一点将帮助我知道如何更正查询。同样，查看上述查询的更好版本将帮助我了解效率低下的地方。无论哪种方式对我都非常有帮助。
仅获取过去 X 天或历史上每家商店的总订单量是一个非常快速的查询。因此，似乎我在加入日期表时做的不是最理想的，但不清楚是什么。
编辑：输出EXPLAIN
1
XN HashAggregate (cost=868301988.49..868301991.01 rows=1009 width=12)
2
-> XN Merge Join DS_DIST_NONE (cost=0.00..868286973.07 rows=3003084 width=12)
3
Merge Cond: ("outer".id = "inner".payment_date)
4
Join Filter: ("inner".shop_id = "outer".id)
5
-> XN Nested Loop DS_BCAST_INNER (cost=0.00..1773635510.00 rows=32472000 width=8)
6
Join Filter: (("outer".date)::timestamp without time zone > ("inner".created + '30 days'::interval))
7
-> XN Seq Scan on dates d (cost=0.00..110.00 rows=11000 width=8)
8
-> XN Seq Scan on shops s (cost=0.00..88.56 rows=8856 width=12)
9
-> XN Seq Scan on order_facts "of" (cost=0.00..90092.52 rows=9009252 width=16)
10
----- Nested Loop Join in the query plan - review the join predicates to avoid Cartesian products -----
我是数据仓库的新手，我一直在阅读有关这些原则的文章和视频，但我对如何采用下面的设计并将其转换为星型模式感到有些困惑。在这个例子中，我假设事实表是 (order-orderitem-book) 而度量是 (category-customer-time) 我的问题是关于书籍作者我们如何把它作为度量？是否允许在星型模式中放置多对多关系？如果我错了，如何将星型模式绘制到这个关系数据库？
