40

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

例如，假设我有（产品、城市、# 销售额）的历史销售数据。我理解以下将是一个关系的观点：

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

虽然以下是更立体的观点：

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

但似乎这两种观点都将在相同的星型模式中实现：

事实表：产品 ID、区域 ID、#销售额
产品维度：产品ID、产品名称
城市维度：城市ID、城市名称

直到您开始向每个维度添加一些额外的细节，差异才会开始显现。例如，如果您还想跟踪区域，关系数据库往往会有一个单独的区域表，以保持一切正常化：

城市维度：城市ID、城市名称、地区ID
Region维度：Region ID、Region Name、Region Manager、#Regional Stores

而维度数据库将允许非规范化以将区域数据保留在城市维度内，以便更轻松地对数据进行切片：

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

它是否正确？

4

4 回答 4

23

星型模式实际上位于数据的关系模型和数据的维度模型的交汇处。这实际上是一种从维度模型开始并将其映射到 SQL 表的方式，这些表有点类似于从关系模型开始时获得的 SQL 表。

我说有点相似，因为许多关系设计方法会导致规范化设计，或者至少是近乎规范化的设计。星型模式与完全规范化有很大的不同。

每次偏离完全标准化都会带来随之而来的数据更新异常。（我将插入、更新和删除操作的异常包括在一个保护伞下）。这些异常与您开始使用的数据模型没有任何关系。

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

除了 SQL 数据库中的星型模式之外，还有维度数据库产品以该产品独有的物理形式存储数据。对于这些产品，您不会看到星型模式，而是看到维度模型的直接实现，以及产品可能特有的接口。其中一些界面允许完全点击操作 OLAP 操作。

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

希望这可以帮助。

于 2010-05-09T21:02:04.913 回答
20

简而言之，OLTP 规范化数据库是从最优化的“事务”角度设计的。数据库被规范化以最佳地工作于事务系统。当我说事务系统的优化时，我的意思是......进入数据库结构的设计状态，其中所有事务操作（如删除、插入、更新和选择）都得到平衡，以便在任何时间点对所有这些操作给予同等或最佳的重要性...... .因为它们在交易系统中具有同等价值。

并且规范化系统提供的功能......数据更新可能的最小更新，新条目可能的最小插入，类别删除的一个地方删除等（例如新产品类别）......这一切都是可能的，因为我们分支了一个创建主表.....但这是以“选择”操作延迟为代价的..但正如我所说，它的（标准化）不是所有操作的最有效模型..它的“最佳”...话虽如此，我们还有其他方法提高数据获取速度..如索引等

另一方面，维度模型（主要用于数据仓库设计）......意味着只重视一种操作，即数据选择......就像在数据仓库中......数据更新/插入会定期发生。 .和它的一次性成本。

因此，如果尝试调整规范化的数据结构，以便在任何时间点只有选择是最重要的操作......我们最终将得到一个非规范化（我会说部分非规范化）......维度星形结构。

  • 所有外键都集中在一个地方事实-维度连接没有维度（即主表到主表连接）..雪花代表相同的维度
    • 理想设计的事实只带有数字..度量或外键
    • 维度用于携带描述和不可聚合的信息
    • 数据的冗余被忽略了……但在极少数情况下，如果维度本身增长太多。雪花设计被视为一种选择……但这仍然是可以避免的

有关详细信息，请阅读有关此主题的详细书籍。

于 2010-08-20T10:25:04.937 回答
7

我最近刚刚阅读了维度数据建模和关系数据建模之间的区别，因为我们主要在存储企业数据仓库 (EDW) 的业务中使用关系模型。

根据史蒂夫·霍伯曼（Steve Hoberman）在他的“数据建模变得简单”一书中，这两种模型之间的区别是：

  • 关系数据模型捕获业务部分如何运作的业务解决方案，也就是业务流程
  • 维度数据模型捕获企业需要回答有关其表现如何的问题的详细信息

可以说，关系模型也可以用作回答业务问题的基础，但在战术层面。“由于信用冻结，客户 x 有多少订单处于未完成状态？” 但区别在于报告问题需要表格的“原生颗粒”以及何时可以用汇总数据回答报告问题。

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

于 2013-10-11T21:56:23.190 回答
7

我发现我在http://www.orafaq.com/node/2286上找到的描述对于从关系角度来看星型模式非常有帮助。

考虑一个完全标准化的数据模型。现在考虑完全相反的情况，您完全非规范化您的关系数据模型，以便您只有一个平面记录，例如具有非常宽行的 big'ol 电子表格。现在从这个平面记录稍微备份一下，这样你就有一个只有两层深的数据模型；一张大桌子，以及大桌子指向的几张小桌子。这是一个 STAR 模式。因此一个真星数据模型有两个属性，它总是两层深，一个真星模型总是只包含一个大表，它是模型的焦点。

于 2017-05-19T09:50:58.213 回答