我在一些问题上感到困惑。我需要他们的答案。 如果我们的关系模型也是去标准化那么为什么我们更喜欢维度模型？ 我们更喜欢维模型而不是关系模型的原因是什么？ 您的历史数据也可以存储在OLTP中，您可以在任何OLTP上轻松执行报告，然后我们使用维度模型和数据仓库？ 维度和非规范化表之间有什么区别？
提前致谢
答案 0 :(得分：9)
简答：
如果您的OLTP表中的查找/检索足够快，并且您的特定搜索要求不具有如下所述的并发症，则不应该需要进入任何维度星型模式。
答案很长：
尺寸和非规范化模型有不同的用途。维度模型通常用于数据仓库方案，并且在计算数字（例如“按地区按季度销售”或“由销售人员”）需要超快查询结果的情况下特别有用。在预先计算这些数字后，数据存储在Dimensional模型中，并根据某些固定的时间表进行更新。
但即使没有涉及数据仓库，Dimensional模型也可能有用，其目的可以补充Denormalized模型，如下例所示：
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启用快速检索，例如返回关于特定项目的大量列，而无需将多个表连接在一起。
因此，在上面的场景中，我们首先使用Dimensional模型为我们感兴趣的人获取一组ID，然后使用Denormalized表获取这些选定ID的完整详细信息，而无需进行任何进一步的连接
如果我们直接查询非规范化表，这种搜索会非常慢，因为需要在PersonName列上进行文本搜索。如果我们尝试包含名称变体，或者我们需要添加更多搜索条件，它会变得更慢。
优秀参考资料：
了解维度建模这个庞大（非常有趣）主题的一个很好的参考是Ralph Kimball的The Data Warehouse Lifecycle Toolkit。其伴随卷The Data Warehouse Toolkit涵盖了大量实际用例。
希望这有帮助！
答案 1 :(得分：1)
维度模型使用非规范化作为其技术之一，以便优化数据库： - 查询性能，和 - 用户理解。
OLTP系统通常难以报告并且速度慢，正在针对OLTP（插入，更新，删除）性能进行优化，并且还用于保护事务完整性。 使用维度模型的数据仓库仍然使用关系技术，而是进行了优化，以考虑获取数据而不是获取数据的体验。
事实是，您无法始终轻松地从任何OLTP系统进行报告：这些表格通常都是模糊的标题，而不考虑人们是否想要获取数据来做出业务决策。生成SQL的报告工具也很难在典型的规范化模式上进行高性能查询。
OLTP技术的现代进步提供了解决性能问题的维模型的替代方案，但仍未解决创建维模型的典型步骤，使数据库表更易于理解和导航。
维度是一个表，用于表示业务概念或实体，为业务流程（或“事实”）的特定度量提供上下文。维度通常在维度模型中非规范化，以减少要理解/导航的表的数量，但也出于性能原因减少连接的数量。例如，Product维度可能会联系Brand信息，而在OLTP模型中，这些表格将是单独的表格，允许用户直接过滤Fact by Brand而不遍历多个表格。
答案 2 :(得分：0)
我同意@Rich，主要是以下事实：维模型使用非规范化表。大约2年前，我开始按照@Krishna的指示阅读Kimball的书。 如果您阅读这本书，我认为您将获得所有问题/疑问的答案。 请注意，如果您想要某种类型的BI解决方案，那么根据我的观点，请遵循尺寸建模。这是为了便于报告，真实且更接近业务流程。 您也许还可以直接从OLTP系统进行报告，但是您的报告解决方案可能无法经受住用户不断变化的需求的考验。在进行维度建模的同时仍保持自然的业务流程。同时，它仍然具有很高的灵活性，以至于其他任何附加过程都可以轻松完成，就像在您接近解决难题时设置拼图一样。