5

我对一些问题感到困惑。我需要他们的答案。如果我们的关系模型也是去规范化的，那么为什么我们更喜欢维度模型？我们更喜欢维度模型而不是关系模型的原因是什么？您的历史数据也可以存储在 OLTP 中，您可以轻松地在任何 OLTP 上执行报告，那么为什么我们使用维度模型和数据仓库？维度和非规范化表有什么区别？

提前致谢

4

3 回答 3

11

简短的回答：

如果您从 OLTP 表中查找/检索的速度足够快，并且您的特定搜索要求没有如下所述的复杂性，那么就不需要进入任何维度星型模式。

长答案：

维度模型和非规范化模型有不同的用途。维度模型一般用于数据仓库场景，尤其适用于“按地区按季度销售”或“按销售员”等计算数字需要超快速查询结果的情况。预先计算好这些数字后，数据存储在维度模型中，并按照一些固定的时间表进行更新。

但即使不涉及数据仓库，维度模型也可能有用，其目的可以补充非规范化模型的目的，如下例所示：

ADimensional model启用快速搜索。dimension tables和之间的连接fact table设置在 a 中star-schema。搜索 John Smith 将被简化，因为我们将仅在相关维度表中搜索 John OR Smith，并从事实表中获取相应的人员 ID（事实表 FK 指向维度表 PK），从而获得所有人员他们名字中的2个关键字。（进一步的增强功能将使我们能够通过建筑尺寸搜索姓名中包含“John Smith”变体的所有人，例如John、Jon、Johnny、Jonathan、Smith、Psmith、Smythesnowflake。）

Denormalized model另一方面，A可以实现快速检索，例如返回很多关于特定项目的列，而无需将多个表连接在一起。

因此，在上述场景中，我们将首先使用 Dimensional 模型为我们感兴趣的人员获取一组 ID，然后使用 Denormalized 表获取这些选定 ID 的完整详细信息，而无需进行任何进一步的连接。

如果我们直接查询非规范化表，这种搜索会非常慢，因为需要对 PersonName 列进行文本搜索。如果我们尝试包含名称变体，或者如果我们需要添加更多搜索条件，它会变得更慢。

优秀参考：

Ralph Kimball 的 Dimensional Modeling 是学习维度建模的广泛（且非常有趣）主题的绝佳参考The Data Warehouse Lifecycle Toolkit。它的配套卷The Data Warehouse Toolkit涵盖了大量的实际用例。

希望这可以帮助！

于 2013-10-17T04:57:24.727 回答
5

维度模型使用非规范化作为其技术之一，以优化数据库： - 查询性能，以及 - 用户理解。

OLTP 系统通常难以报告并且速度较慢，因为它们针对 OLTP（插入、更新、删除）性能以及保护事务完整性进行了优化。使用维度模型的数据仓库仍然使用关系技术，但经过优化以考虑将数据取出而不是输入数据的体验。

事实是，您不能总是从任何 OLTP 系统轻松地报告：表格的标题通常晦涩难懂，而没有考虑到人们想要获取数据来做出业务决策。生成 SQL 的报告工具也难以对典型的规范化模式进行高性能查询。

OLTP 技术的现代进步为解决性能问题的维度模型提供了替代方案，但仍未解决在创建维度模型时所做的典型步骤，从而使数据库表更易于理解和导航。

维度是旨在表示业务概念或实体的表，为业务流程（或“事实”）的特定度量提供上下文。通常在维度模型中对维度进行非规范化处理，以减少要理解/导航的表的数量，同时出于性能原因减少连接的数量。例如，产品维度可能会联系品牌信息，而在 OLTP 模型中，这些将是单独的表，这允许用户直接按品牌过滤事实，而无需遍历多个表。

于 2017-02-14T08:11:01.280 回答
0

我同意@Rich，主要是维度模型使用非规范化表这一事实。正如@Krishna 所说，大约 2 年前，我开始关注 Kimball 的书。如果你读了这本书，我想你会得到所有问题/疑问的答案。请注意，如果您的目标是某种 BI 解决方案，那么根据我的意见，请遵循维度建模。这是为了便于报告，真实且更接近业务流程。您或许也可以直接从 OLTP 系统制作报告，但您的报告解决方案可能无法经受住用户不断变化的需求的考验。在保持接近自然业务流程的同时完成维度建模。同时，它仍然非常灵活，任何其他附加过程都可以轻松完成，例如当您更接近解决它时设置一块拼图。

于 2020-07-29T22:59:11.697 回答