关系型数据库与维度型数据库，有什么区别？

Question

我正在学习OLAP和数据仓库，但对于关系建模和维度建模之间的区别感到困惑。维度建模基本上是关系建模吗，只是允许冗余/非规范化的数据吗？

例如，假设我有历史销售数据（产品、城市、销售数量）。以下是关系视角：

产品 | 城市 | 销售数量
苹果，旧金山，400
苹果，波士顿，700
苹果，西雅图，600
橙子，旧金山，550
橙子，波士顿，500
橙子，西雅图，600

而以下则是更多维度的视角：

产品 | 旧金山 | 波士顿 | 西雅图
苹果，400, 700, 600
橙子，550, 500, 600

但无论哪种视角都会在相同的星型模式下实现：

事实表：产品ID、地区ID、销售数量
产品维度：产品ID、产品名称
城市维度：城市ID、城市名称

只有在向每个维度添加一些附加详细信息时，差异才开始显现。例如，如果您还想跟踪地区，关系数据库通常会有一个单独的地区表来保持所有内容规范化：

城市维度：城市ID、城市名称、地区ID
地区维度：地区ID、地区名称、区域经理、# 区域店铺

而维度数据库将允许非规范化以将地区数据保存在城市维度中，以便更容易地分割数据：

城市维度：城市ID、城市名称、地区名称、区域经理、# 区域店铺

这样说对吗？

- grautur

---

阅读有关 OLTP 和 OLAP 之间区别的内容。http://datawarehouse4u.info/OLTP-vs-OLAP.html - Oded

是的，我已经了解了它们之间的区别。我有些困惑的是当某些内容提到OLAP通常涉及维度数据库而非关系数据库时。这里的“维度”是否只是指“去规范化+星型/雪花模式”的方面？或者也会有“关系型”的星型/雪花模式模式吗？ - grautur

Answer 1

星型模式处于数据关系模型和维度模型的交集。它是从维度模型开始，将其映射到SQL表中的一种方法，这些表有些类似于从关系模型开始所得到的SQL表，但并不完全相同。因为许多关系设计方法会导致规范化设计，或者至少接近规范化设计，星型模式会在很大程度上偏离规范化设计。每一次偏离规范化设计都会带来相应的数据更新异常。这些异常与您开始使用的数据模型无关。

关于OLTP和OLAP的注释在此非常相关。在这两种情况下，更新异常将对性能和/或编程难度产生不同的影响。

除了SQL数据库中的星型模式外，还存在维度数据库产品，这些产品以物理形式存储数据，该形式对该产品具有独特性。使用这些产品，您不会看到如此强调星型模式，而是直接实现维度模型，并可能具有特定于该产品的接口。其中一些接口允许OLAP操作完全是点对点的。

只是稍微离开您的问题，我曾经构建了一个星型模式，作为支持事务应用程序的OLTP数据库和Cognos PowerPlay中的数据立方体之间的中间步骤。使用标准的ETL技术，从OLTP数据库到星型模式的组合转换，然后从星型模式到数据立方体的转换实际上优于从OLTP数据库直接转移到数据立方体。这是一个意外的结果。

希望这有所帮助。

- Walter Mitty

Answer 2

简单来说，OLTP（联机事务处理）标准化数据库是根据最优“事务”视角设计的。数据库被规范化以在事务系统中实现最佳效果。当我说优化事务系统时，我的意思是将数据库结构设计成一种状态，在这种状态下，所有事务操作（如删除、插入、更新和选择）在任何时间点都能平衡地给予相等或最佳重视……因为它们在事务系统中具有相等的价值。

这就是标准化系统所提供的……对于数据更新而言，只进行最小程度的更新、对于新条目只进行最小程度的插入、对于类别删除只进行一次删除等等（例如新产品类别）……我们可以通过创建主表来实现所有这些，但这要付出“选择”操作延迟的代价……但正如我所说，标准化不是所有操作的最有效模型……它是“最优”的……话虽如此，我们得到了其他方法来增强数据提取速度，比如索引等等。

另一方面，维度模型（主要用于数据仓库设计）旨在只给与选择数据一种操作的重视。在数据仓库中，数据更新/插入是定期发生的，这是一次性成本。

因此，如果试图调整规范化的数据结构，使得选择是任何时候最重要的操作，我们最终会得到一个非规范化（我会说是部分非规范化）的维度星型结构。

所有外键都在一个地方成为事实表 -没有维度对维度的连接（即主到主表的连接）.雪花表示同一维度

理想情况下设计良好的事实表只包含数字……衡量值或外键 维度用于承载描述和不可聚合信息 忽略数据的冗余……但在极少数情况下，如果维度本身增长太多。雪花设计被视为选项……但这仍然是可以避免的。

请参考此主题的详细书籍以获取更多详细信息。

- Vijender

---

谢谢。对我来说，强调优化选择而不是优化插入/更新/删除是最重要的。 - kjmerf

Answer 3

我最近刚读了关于维度和关系数据建模的区别，因为我们在业务中主要使用关系模型来存储企业数据仓库（EDW）。根据Steve Hoberman在他的书 "Data Modeling Made Simple" 中的说法，这两种模型的区别在于：

- 关系数据模型捕捉业务解决方案，即业务流程 - 维度数据模型捕捉业务需要回答有关业务表现的详细信息

可以争论认为关系模型也可以作为回答业务问题的基础，但只能在战术层面上。例如：“客户x由于信用保留而有多少未完成的订单？”但是区别在于报告问题何时需要表的本机粒度，以及何时可以通过汇总数据来回答报告问题。

在您上面提到的两个示例中，它们实际上都是维度数据建模的示例，因为这两个表都没有将销售订单存储在其“本机粒度”处，因此不捕捉创建销售订单的业务流程。这两个表之间唯一的区别在于第二个表中，城市维度已转置到事实表中。

- codemagic

---

我认为你的回答是最好的，但我想补充一点，即使你在关系模型中尝试了所有的调整，当你需要统计数据时，最终你会接近一个星型模式，也就是一个带有许多外键的汇总（事实）表。 - delmalki

@codemagic 你所说的“native grain”是什么意思？ - Mehdi Charife