为什么我们使用维度模型而不是非规范化的关系模型？

作者: 至此
发布时间: 2024-04-03 05:19:11 (22天前)
转自：

3 条回复

0#
回复此人
老夫的少女心吖 | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> 维度模型使用非规范化作为其技术之一，以便优化数据库： - 查询性能，和 - 用户理解。 OLTP系统通常难以报告并且速度慢，正在针对OLTP（插入，更新，删除）性能进行优化，并且还用于保护事务完整性。使用维度模型的数据仓库仍然使用关系技术，但是经过优化以考虑获取数据而不是获取数据的体验。 事实上，您无法始终轻松地从任何OLTP系统进行报告：这些表格经常被模糊地标题，而不考虑人们是否想要获取数据来做出业务决策。生成SQL的报告工具也很难在典型的规范化模式上进行性能查询。 OLTP技术的现代进步提供了解决性能问题的维度模型的替代方案，但仍然没有解决创建维模型的典型步骤，使数据库表更易于理解和导航。 维度是一个表，用于表示业务概念或实体，为业务流程（或“事实”）的特定度量提供上下文。维度通常在维度模型中非规范化，以减少要理解/导航的表的数量，但也出于性能原因减少连接的数量。例如，Product维度可以联系Brand信息，而在OLTP模型中，这些表格可以是单独的表格，允许用户直接过滤Fact by Brand，而无需遍历多个表格。 </DIV>

编辑
1#
回复此人
晴天？霹雳 | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> 的 简短回答： </强> 如果您从OLTP表中查找/检索 足够快 ，以及您的具体搜索要求 不 有如下所述的复杂情况，那么就不需要进入任何维度星型模式。 的 答案很长： </强> 尺寸和非规范化模型具有不同的目的。维度模型通常用于数据仓库方案，并且在计算数字（例如“按地区按季度销售”或“由销售人员”）需要超快查询结果的情况下特别有用。在预先计算这些数字之后，数据存储在Dimensional模型中，并根据某些固定的时间表进行更新。 但即使没有涉及数据仓库，Dimensional模型也可能有用，其目的可以补充Denormalized模型，如下例所示： 一个 <code> Dimensional model </code> 使的 快速搜索 </强> 。加入之间 <code> dimension tables </code> 和 <code> fact table </code> 设置在一个 <code> star-schema </code> 。搜索John Smith将被简化，因为我们将仅在相关维度表中搜索John OR Smith，并从事实表中获取相应的人ID（事实表FK指向维度表PK），从而使所有人都获得他们名下的2个关键字。（进一步的增强将使我们能够在其名称中搜索具有“John Smith”变体的所有人，例如 John，Jon，Johnny，Jonathan，Smith，Psmith，Smythe 通过建设 <code> snowflake </code> 尺寸。） 一个 <code> Denormalized model </code> 另一方面，启用的 快速检索 </强> ，例如返回关于特定项目的大量列，而不必将多个表连接在一起。 因此，在上面的场景中，我们首先使用Dimensional模型为我们感兴趣的人获取一组ID，然后使用Denormalized表获取这些选定ID的完整详细信息，而无需进行任何进一步的连接。 如果我们直接查询非规范化表，这种搜索会非常慢，因为需要在PersonName列上进行文本搜索。如果我们尝试包含名称变体，或者如果我们需要添加更多搜索条件，它会变得更慢。 的 优秀参考： </强> Ralph Kimball是一个很好的参考，用于了解维度建模的巨大（也是非常有趣）主题 <code> The Data Warehouse Lifecycle Toolkit </code> 。它的伴侣量 <code> The Data Warehouse Toolkit </code> 涵盖了大量的实际用例。 希望这可以帮助！ </DIV>

编辑

登录后才能参与评论