我对一些问题感到困惑。我需要他们的答案。 如果我们的关系模型也是去规范化的，那么为什么我们更喜欢维度模型？ 我们更喜欢维度模型而不是关系模型的原因是什么？ 您的历史数据也可以存储在 OLTP 中，您可以轻松地在任何 OLTP 上执行报告，那么为什么我们使用维度模型和数据仓库？ 维度和非规范化表有什么区别？
提前致谢
【问题讨论】：
标签： relational-database database-schema denormalization dimensional-modeling oltp
简答：
如果您从 OLTP 表中的查找/检索足够快，并且您的特定搜索要求没有有如下所述的复杂性，那么不应该有需要进入任何维度的星图。
长答案：
维度模型和非规范化模型有不同的用途。维度模型一般用于数据仓库场景，尤其适用于“按地区按季度销售”或“按销售员”等计算数字需要超快速查询结果的情况。数据在预先计算好这些数字后存储在维度模型中，并按照一些固定的时间表进行更新。
但即使不涉及数据仓库，维度模型也可能有用，其目的可以补充非规范化模型的用途，如下例所示：
Dimensional model 启用快速搜索。 dimension tables 和 fact table 之间的连接在 star-schema 中设置。搜索 John Smith 将被简化，因为我们将仅在相关维度表中搜索 John OR Smith，并从事实表中获取相应的人员 ID（事实表 FK 指向维度表 PK），从而获得所有人员他们名字中的2个关键字。 （进一步的增强功能将使我们能够通过构建snowflake 维度来搜索姓名中包含“John Smith”变体的所有人，例如John、Jon、Johnny、Jonathan、Smith、Psmith、Smythe。 )
另一方面，Denormalized model 支持快速检索，例如返回有关特定项目的大量列，而无需将多个表连接在一起。
因此，在上述场景中，我们将首先使用维度模型为我们感兴趣的人员获取一组 ID，然后使用非规范化表获取这些选定 ID 的完整详细信息，而无需进行任何进一步的连接.
如果我们直接查询非规范化表，这种搜索会很慢，因为需要对 PersonName 列进行文本搜索。如果我们尝试包含名称变体，或者我们需要添加更多搜索条件，它会变得更慢。
优秀的参考：
Ralph Kimball 的The Data Warehouse Lifecycle Toolkit 是学习维度建模这一庞大（且非常有趣）主题的绝佳参考。它的配套卷The Data Warehouse Toolkit 涵盖了大量的实际用例。
希望这会有所帮助！
【讨论】：
维度模型使用非规范化作为其技术之一，以优化数据库： - 查询性能，以及 - 用户理解。
OLTP 系统通常难以报告且速度较慢，因为它们针对 OLTP（插入、更新、删除）性能以及保护事务完整性进行了优化。 使用维度模型的数据仓库仍然使用关系技术，但经过优化以考虑将数据取出而不是放入数据的体验。
事实是，您不能总是从任何 OLTP 系统轻松报告：表格的标题通常晦涩难懂，而没有考虑到人们想要获取数据以做出业务决策。生成 SQL 的报告工具也难以对典型的规范化架构进行高性能查询。
OLTP 技术的现代进步为解决性能问题的维度模型提供了替代方案，但仍未解决创建维度模型的典型步骤，从而使数据库表更易于理解和导航。
维度是用于表示业务概念或实体的表，为业务流程（或“事实”）的特定度量提供上下文。通常在维度模型中对维度进行非规范化处理，以减少要理解/导航的表的数量，同时出于性能原因减少连接的数量。例如，产品维度可能会联系品牌信息，而在 OLTP 模型中，这些是单独的表，允许用户直接按品牌过滤事实，而无需遍历多个表。
【讨论】：
我同意@Rich 的观点，主要是维度模型使用非规范化表这一事实。正如@Krishna 所说，大约 2 年前，我开始关注 Kimball 的书。 如果你读了这本书，我想你会得到所有问题/疑问的答案。 请注意，如果您的目标是某种 BI 解决方案，那么根据我的意见，请遵循维度建模。这是为了便于报告，真实且更接近业务流程。 您或许也可以直接从 OLTP 系统制作报告，但您的报告解决方案可能无法经受住用户不断变化的需求的考验。在保持接近自然业务流程的同时完成维度建模。同时，它仍然非常灵活，任何其他附加过程都可以轻松完成，例如当您更接近解决它时设置一块拼图。
【讨论】：