这里有一点背景：
我知道what a data warehouse is，或多或少。我已经阅读了数十个关于数据仓库的指南，我玩过SSAS，我知道什么是星型模式，维度表和事实表，我知道ETL是什么以及如何做。 这不是“如何”问题或教程请求。
我的问题是，我在数据仓库中阅读的所有材料似乎都掩盖了用于构建数据仓库的基本原理。它们都是比喻性的，或者在某些情况下字面上以“”开头，所以你决定建立一个数据仓库...... “除了我还没有做出那个决定。
所以我希望SO成员可以指点我，或者帮助提出某种半客观测试。我可以适应特定系统并最终得到“是的，我们需要一个数据仓库”或“不，今天的收益太小了”。我认为我应该能够回答的具体问题是：
在什么时候构建数据仓库值得考虑？换句话说，我应该注意哪些标志，指标或其他标准可能表明标准的交易环境不再足够？
全面数据仓库有哪些替代方案？事务数据库中的非规范化和沼泽标准复制的“报告服务器”是我想到的两个;在进入DW之前还有其他我应该探索的吗？
为什么数据仓库比上述备选方案更好？如果答案是“它取决于”，那么它依赖于什么？
当不应时，我尝试构建数据仓库？无论背景如何，我都对所谓的“最佳实践”持怀疑态度。肯定有一些情况下DW是错误的选择 - 它们是什么？
是否有任何实用示例我可以看一下通过引入数据仓库而改进的系统？可以向我解释的东西，端到端，他们需要仓库的决策或分析，他们如何决定放入什么，以及仓库最终如何适应更大的环境？我不想要一个人为的“让我们从AdventureWorks数据库中创建一个多维数据集” - 实现与我无关，我对规范和设计以及整体思维过程感兴趣< / em>参与其中。
我一般不会问多方，但我认为这些都是非常密切相关的。我愿意接受至少解决前4个问题的任何答案，尽管最后一个问题确实有助于在我的脑海中明白这一点。如果有人已经写过关于此问题的链接很好，只要它们相当简洁和具体（链接到Ralph Kimball的主页=无用）。
希望我已经明确了这个问题 - 提前感谢您的回答！
答案 0 :(得分：42)
我会看看我是否可以尽力回答你的问题。
1.构建数据仓库的重点是什么值得考虑？ 换句话说，有什么标志， 我应该是指标还是其他标准 寻找可能表明这一点 标准的交易 环境不再充足？
一个。如果您发现报告和监控会影响生产系统和/或离线数据存储的性能。
湾如果您发现获得业务问题的答案需要每次都构建大量复杂的SQL。
℃。如果您发现每次对事务架构进行更改时，都必须返回并重新编写所有报告查询。
d。如果您想汇集来自多个来源的数据。
2.完整数据仓库的替代方案是什么？ 事务中的非规范化 数据库和沼泽标准 复制的“报告服务器”是两个 浮现在脑海中;有没有 其他我以前应该探索 承诺到DW？
3.为什么数据仓库比上述备选方案更好？如果答案是， “这取决于”，那么它取决于什么 上？
我会一起回答这些问题。我不认为数据仓库是一个全有或全无的冒险。它只是一个简洁的短语，意思是“以一种允许您更轻松快速地回答业务问题的方式存储您的数据。”
事务数据库旨在有效地与应用程序进行交互。如果有意义的话，数据仓库，数据集市，运营数据存储和报告表可以与人们进行有效的交互。
4.我不应该尝试建立数据仓库吗？我对此持怀疑态度 任何被宣称为“最佳实践”的事物 不论背景如何。肯定在那里 必须是DW的一些场景 错误的选择 - 他们是什么？
好问题。如果您的交易系统为您提供了足够的业务洞察力，那么您可能不需要仓储。
如果您只有一个数据源并且性能不是问题，那么您可以从创建简单报告表中获得洞察力。
5.有任何实际的例子，我可以看一下那些系统 通过引入数据来改进 仓库？会有的东西 向我解释，端到端，有什么样的 他们需要的决定或分析 仓库，他们如何决定 放入什么，以及如何 仓库最终装入了 更大的环境？我不想要 做作“让我们制作一个立方体 AdventureWorks数据库“ - 实施与我无关， 我对规格很感兴趣 和设计和整体思想 涉及的过程。
这是一个很大的问题，需要的空间远远超过我在这里分配的空间。
在这一篇文章中，我可以向您指出一些可能提供您所寻求的洞察力的地方。
答案 1 :(得分：5)
DW的主要目的是加速（简化）报告和分析。它可以以业务用户可以想到的任何方式切片和切割数据。
对于第一步DW，您只需实现一个Kimball星型模式并对其运行SQL查询。如果这证明仍然太慢，请开始考虑预先计算的聚合（立方体）。
针对DW的信息切片和切割比标准化DB更简单。复制的报表服务器将提高性能，但不会简化切片和切块。另外请记住，DW属于业务用户，因此他们可以随时提出各种切片/骰子的想法 - IT人员应该只提供这样的环境。
如果您在操作系统上不时运行少量报告并且对性能感到满意，则无需使用DW。
我所有的经验都是系统，业务用户无休止地抱怨报告缓慢和无法编写“复杂查询”，而生产人员抱怨数据库因报告而陷入困境。在所有情况下，简单的Kimball星和具有缓存和快照的报表服务器都足够好。
答案 2 :(得分：3)
当满足以下两个条件时，您应该考虑构建数据仓库：
这是您认为数据仓库的问题。在许多情况下，只要您可以坚持使用关系数据库管理系统，就可以逐步从具有某些报告的OLTP系统移动到完整的数据仓库。首先可以是构建第一个事实表，并继续使用规范化的表进行维度。然后向游戏添加更多事实，更多事实表或专用维度表。首先在同一个数据库（或所涉及系统的一个数据库）中，可能稍后转移到一个单独的数据库。
完整的数据仓库（单独的数据库，星型模式）提供了调整选择语句的最佳选项，除了转到专门的系统。它也与OLTP系统完全分离。考虑架构设计，还有CPU，I / O和内存以及组织等资源，例如新版本的安排。当然，你可能不需要做很多工作。
在上面的答案中：仅仅因为你有一些复杂的查询，并不意味着你应该建立一个DWH，如果它们是孤立的，那么它们也适用于其他标准。
< / LI>这里不能提供太多，但建议：敏捷。 DWH的要求极大地取决于用户看到的可能性。需求可能会发生变化。使用数据库自动化测试是一件痛苦的事情，但是在没有正确测试的生产系统中愚弄更糟糕。
答案 3 :(得分：2)
在什么时候构建数据仓库值得考虑？换句话说，我应该注意哪些标志，指标或其他标准可能表明标准的交易环境不再足够？
当您发现在事务数据存储中执行报告和分析活动对两者都有害时，我建议使用数据仓库。
全面数据仓库有哪些替代方案？事务数据库中的非规范化和沼泽标准复制的“报告服务器”是我想到的两个;在进入DW之前还有其他我应该探索的吗？
我这里没什么好提的。我要说保持交易和报告数据库对我来说似乎是明智的，无论你是否称它为仓库。数据挖掘可能是一项非常耗费CPU的活动。
为什么数据仓库比上述备选方案更好？如果答案是“它取决于”，那么它依赖于什么？
我在这里没什么可提供的。
什么时候不应该尝试构建数据仓库？无论背景如何，我都对所谓的“最佳实践”持怀疑态度。肯定有一些情况下DW是错误的选择 - 它们是什么？
我会说，如果你不需要保留很长的历史记录，没有对数据进行密集分析，并且你的报告需求不时局限于一个即席查询，那么可能是一个数据仓库没有必要。
是否有任何实际的例子我可以看一下通过引入数据仓库而改进的系统？可以向我解释的东西，端到端，他们需要仓库的决策或分析，他们如何决定放入什么，以及仓库最终如何适应更大的环境？我不想要一个人为的“让我们从AdventureWorks数据库中创建一个多维数据集” - 实现与我无关，我对所涉及的规范和设计以及整体思维过程感兴趣。
我的雇主在我到达之前已经使用了多年的数据仓库，所以在我到达之前我不能说出事情是什么样的。
答案 4 :(得分：2)
根据我的经验，开始考虑数据仓库的第一个标志是您拥有（或正在开发）事务数据库并且用户开始添加大量报告和数据历史记录要求。这几乎总是如此。拥有一个单独的数据仓库或报告数据库比尝试设计一个处理最终用户始终拥有的报告需求的事务系统更容易。在事务系统中存储历史记录（用于业务实体）会增加复杂性并使数据库膨胀，并尽可能地响应。
另一方面，我一直在大型公司中，许多团队创建了数据仓库，因为感兴趣的数据分布在许多系统中，因此难以查询。问题是每个组都创建了自己的数据仓库，因为公司中的所有现有仓库都没有正确的信息子集，或者数据模型被认为是非最佳或不正确的。通过创建更难以比较的不同数据系统，情况变得更糟。
答案 5 :(得分：0)
需要采取以下步骤来构建数据仓库：
答案 6 :(得分：-1)
“我认为为什么有些项目会失败？”
主要有五个原因：