数据仓库 - 星型图与平坦表

Question

我试图设计一个数据仓库，用于从财务系统，项目调度系统和各种科学系统中获取常用数据。即许多不同的数据集市。

我已经在数据仓库和流行的方法，如星型模式和金博尔方法等，但一个问题，我无法找到答案，阅读起来很：

为什么它更好地设计自己的数据仓库数据集市作为星型模式而不是单一的平台？

当然，在事实和属性/维度之间没有联接比有大量小联接到所有维度表更快，更简单？磁盘空间不是问题，如果有必要，我们会在数据库中放置更多磁盘。星型模式最近是否略显过时，还是数据架构师的教条？

Answer 1

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

但我不认为它已经过时，或者说教条 - 对于很多情况和平台来说这是一个合理的实际情况。

关系数据库存储数据的方式意味着在数据和表的类型，典型查询的数据路径，数据之间关系的易维护性和描述，连接数量，构建连接的方式，列的可索引性等。

3NF（或更进一步）是频谱的一端，适合OLTP系统，单个表格是频谱的另一端。维度模型处于中间，适合报告。

虽然星型模式在报告工作负载方面比完全标准化的数据库更好，但部分原因是联接数量减少，但性能不是全部关于“联接数量”。尺寸通常很宽。如果您在每一个事实的每一行都包含所有这些维度字段，那么您的行数确实非常大，并且寻找进入这些行的方式对于典型查询的执行情况会非常糟糕。

事实是很多的，所以如果你可以使这些表格变得紧凑，并且可以过滤“单词”维度，那么你就会发现单个表格无法匹配的性能的最佳位置，除非索引严重。

是的，对于事实而言，单个表格就表格数量而言更简单，但它是否更容易导航？维度和事实是易于理解的概念，以及如果您想跨越事实跨越查询，该怎么办？您拥有许多不同的数据集市，但首先拥有数据仓库的好处之一是这些数据仓库不是独特的 - 它们是相关的，可以进行报告。一致的尺寸可以实现这一点

Answer 2

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

例如，餐馆菜单是维度，购买的食物是事实。如果你将这些组合成一张桌子，你会如何确定哪些食物从未被订购？对于这个问题，在你的第一个订单之前，你如何确定菜单上有什么食物？

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

Answer 3

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

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