数据仓库 - 星型模式与平面表

Question

我正在尝试为一系列常用数据设计数据仓库，这些数据包括财务系统，项目调度系统和无数科学系统。即许多不同的数据集市。

我一直在阅读数据仓库和流行的方法，如Star Schemas和Kimball方法等，但我找不到答案的一个问题是：

为什么将DW数据集市设计为星型模式而不是单个平台更好？

当然，事实和属性/维度之间没有连接比对所有维度表进行大量小连接更快更简单吗？磁盘空间不是问题，如果需要，我们只会在数据库中抛出更多磁盘。这些天的星型架构是否略显过时，还是它仍然是数据架构师的教条？

Answer 1

您的问题非常好：用于维度建模的Kimball口头禅是提高性能并提高可用性。

但我不认为它已经过时，或者说教条 - 对于许多情况和平台而言，这是一种合理，实用的方法。

关系数据库存储数据的方式意味着在表的数量和类型之间存在平衡行为，典型查询的数据路由，易于维护以及数据之间关系的描述，连接数，构造连接的方式，列的可索引性等。

<3> 3NF（或更远）是频谱的一端，适合OLTP系统，单个表是频谱的另一端。尺寸模型位于中间，适合报告，至少在使用某些技术时。

性能不仅仅是'连接数'，尽管星型模式比完全规范化的数据库更适合报告工作负载，部分原因是连接数量减少。尺寸通常非常宽。如果要在每个事实的每一行中包含所有这些维度字段，那么确实存在非常大的行，并且找到进入这些行的方式对于典型查询将表现得非常糟糕。

事实很多，所以如果你可以制作那些紧凑的表格，并且'wordier'维度可以过滤，那么你就会达到单个表不匹配的性能最佳点，除非重度索引。

是的，对于一个事实来说，单个表在表的数量方面更简单但是它更容易导航吗？维度和事实是易于理解的概念，如果您想跨越事实跨越查询，该怎么办？您有许多不同的数据集市，但首先拥有数据仓库的好处之一是它们并不是独特的 - 它们是相关的并且可以跨报告。一致的尺寸可以实现这一目标。

Answer 2

如果将事实和维度合并到一个表中，您将失去对从未使用过的维度属性的可见性，或者通过包含未使用维度属性的虚拟事件来抛弃您的度量。

例如，餐馆菜单是一个维度，购买的食物是一个事实。如果将这些组合成一个表格，您如何识别从未订购过哪些食物？就此而言，在您第一次订购之前，您如何确定菜单上有哪些食物？

维度代表了可能性，事实代表了可能性的实现。

Answer 3

在同一个表中组合事实和维度限制了可扩展性和灵活性。

假设有一天业务决定更改维度描述（例如产品名称）。维度表没有事实表那么深，更新过程或SCD管理应该更容易，资源也更少。