我的任务是提出如何进行EDW的建议，并希望澄清我所看到的内容。我正在学习的一切都表明，Kimball的方法将为Inmon带来更快的商业价值。我认为Kimball的方法是来自getgo的维度模型，不同的数据集市（星型模式）通过一致的维度进行整合......因此理论上我可以简单地提出我的直接DM来解决业务需求并从那里继续
我所学到的东西表明Inmon的模型表明我有一个3NF设计的EDW。 EDW不是由源系统定义的，而是业务的结构，公司工厂（订单，人力资源等）。因此，来自不同系统的数据会映射到此结构中。一旦数据处于这种形式，就会创建ETL以生成DM。
我个人认为Inmon的方法是更好的方法。我相信这种方式可以确保数据保持一致，感觉您可以使用这些数据做更多事情。然而，正如我正在阅读的所有内容所说的那样，我需要花费更多的时间来提供一些东西，但我不知道这是怎么回事。从我的狭隘观点来看，无论最终结果是什么，我们都需要DM。无论使用Kimball还是Inmon的方法，最终结果都是一样的。
那么问题就变成了我们如何到达那里？在Kimballs方法中，我们将创建ETL到某个临时位置，并且通常从那里创建DM。在Inmon的方法中，我觉得我们只是添加另一层...来自暂存区域，我们将这些数据加载到由功能组织的3NF中的另一个数据库中。我缺少的是这一步如何增加这么多时间。
我觉得我可以看看需要制作的最终DM。将它们映射回3NF中的DW，然后随着更多DM的请求，继续在3NF中构建DW，其中包含越来越多的数据。然而，如果我在Kimballs模型中创建一个DM，那么DM将围绕为该DM决定的谷物水平而建立，如果下一个DM要求报告甚至更深层次的话（如果对我来说感觉像Kimballs方法需要更多）工作）和Inmon一起没关系。我拥有跨国水平的所有东西，所以要求不同谷物的DM，我有数据，只有ETL到DM，所有DM都报告相同，因为它们来自相同的数据。
我不知道......只是在寻找其他人的观点。我读到的所有内容都表明Kimball的速度更快......我说可能确实有一点点，但肯定会因为更快的路线而造成成本。为了争论...让我们说需要一个星期的时间才能获得DM并运行Kimballs方法......对我而言，使用Inmon的时间感觉应该只需要10％甚至20％。
如果有人对不同型号有任何实际经验，如果一个人真的花了这么长时间，那么另一个......请分享。或者，如果我有这样的反过来告诉我那个！
答案 0 :(得分：5)
我为一个大型跨国公司提供30亿记录数据仓库。我们的数据从各种源系统通过分段进入3NF数据库。从这里开始，我们的ELT流程将数据移动到维度建模的星型模式数据库中。
如果我可以重新开始，我肯定会放弃3NF步骤。当我第一次构建该层时，我认为它会增加真正的价值。我确信规范化可以保护数据的完整性。我同样相信3NF数据库将是运行大型/复杂查询的最佳位置。
但在实践中，它减缓了我们的发展。大多数更改都需要更新阶段，3NF和星型模式db。
额外的图层也会增加发布数据所需的时间。所有额外的转换，检查和对帐都加起来。
承诺的诚信改善从未实现。我现在意识到，因为我控制ETL和内部的验证过程，我可以确保我的数据都是非规范化和准确的。在报告数据时，我们控制每个表中的每个单元格。我越是想到这一点，我就越认为这是一个真正的机会。
大而复杂的查询是经验所破坏的另一个神话。我现在看到有必要编写复杂的报告查询作为我的明星数据库的失败。当这种情况发生时，我总是问自己：为什么这个问题不容易回答？答案通常是糟糕的桌面设计。在改造数据时最好进行繁重的工作。
运行3NF和星也为两个系统创造了一个不同意的机会。当发生这种情况时，通常会产生非常微妙的差异。这本身都不是错的。相反，3NF和星级查询可能会询问稍微不同的问题，从而返回不同的结果。虽然技术上正确，但这很难解释。随着时间的推移，即使是微小的，可解释的差异也会侵蚀人们的信心。
为了保护我们的3NF数据库，它确实使得加载到星上更容易。但我很乐意将更复杂的SSIS包换成一层。
说完所有这些;如果没有深入了解他们的系统，要求，文化，技能等，很难向任何人推荐一种方法。在阅读了你的问题后，我确信你已经解决了所有这些问题，而且更多的是毫无疑问！最后，只有您可以根据自己的情况决定最佳方法。一旦你开始思考，坚持下去。一致性，清晰度和明确定义的方法对其他任何事情都更为重要。
答案 1 :(得分：3)
维度和度量是向最终用户呈现和简化数据的经过充分验证的方法。
如果您向最终用户呈现基于源系统（3nf）的架构，而对于最终用户呈现尺寸建模的星型架构（Kimball），他们将能够更好地理解维度建模的< / p>
我从未真正研究过Inmon决策支持系统，但对我而言，它似乎只是完整数据仓库的ODS部分。
你说的是“EDW不是由源系统定义的，而是业务的结构”。星型模式反映了这一点，但ODS（源系统的副本）不是
星型模式的构建时间比仅仅是ODS需要更长的时间，但却带来许多好处，包括
如果您的Inmon 3NF数据库不仅仅是ODS（源系统的副本），而是某种实际业务模型，那么您有两个要建模的层：3NF层和星型模式层。
如果每个人都认为他们可以在“自助服务”工具中完成所有工作，那么现在很难销售甚至一个层数据建模的好处！ （我认为这是一种谬论）。您的系统应该没有比它需要的更复杂，因为所有这些复杂性都会增加维护，这就是真正的问题 - 当您需要更改多个层时，在构建中引入更改12个月
解释@ destination-data：您的源系统到星型模式转换（和分离）已经通过ETL实现，所以3nf对我来说似乎是多余的。通过正确实现代理键和业务键，并在业务上而不是在源系统上对其进行建模，您可以将星型模式设计为独立于源系统
答案 2 :(得分：1)
ETL和后端数据争夺占用了这项努力的约70％的项目时间，额外的一层产生了很大的不同。它是一个从源到目标的额外转换层，与业务达成一致并进行测试。这一切都加起来。
虽然我并不是说维度模型（Kimball类型）总是很容易改变，但是当你想要改变时，如果你必须总是改变很多层，你就会变得更加僵硬。你的BI。
事实上，我在那些有数据仓库的地方进行咨询，这些数据仓库被认为是不灵活且开发费用昂贵，而且没有跟上业务变化的步伐，他们毫无例外地包括了3NF层在DM之前。正如尼克提到的那样，现在很难卖出“正确”的想法。数据仓库与Data Discovery Bi工具相反 - 而这些工具的吸引力往往是由于DW被认为开发速度慢而且成本高昂。
如果对于某种情况有意义的话，Kimball并不反对在他的DW之前拥有3NF层，他只是不同意Inmon的观点。一个常见的误解是，Kimball提出了不同的数据集市，因此您每次有不同的报告请求时都必须对其进行更改。相反，Kimball的DM基于现实生活中的业务流程并相应地建模。虽然它是真的，你会尝试使它们适合报告，你尝试制作它们，以便他们可以回答可疑的查询。您不会聚合和存储聚合：您使用Kimball维模型中的事务数据。 因此，从这个角度来看，不需要那么不情愿。
如果ODS适合您，那就去吧 - 但是Kimball DW将满足大多数要求。