我的任务是提出有关如何进行EDW的建议，并希望就我所看到的内容进行澄清。我正在学习的所有内容都表明，与Inmon相比，Kimball的方法将更快地为企业带来价值。我发现Kimball的方法是来自getgo的维度模型，并且不同的数据集市（星型架构）通过一致的维度进行集成...因此，理论上讲，我可以简单地提出直接的DM来解决业务需求并从那里继续。
我正在学习的内容表明，Inmon的模型表明我有3NF设计的EDW。EDW不是由源系统定义的，而是由业务结构，公司工厂（订单，HR等）定义的。因此，来自不同系统的数据会映射到此结构中。数据采用这种形式后，便会创建ETL以生成DM。
我个人认为Inmon的方法是更好的方法。我相信这种方式将确保数据保持一致，并且感觉您可以对这些数据做更多的事情。尽管我正在阅读的所有内容都说，交付某些内容将花费更多的时间，但我不知道这是怎么回事，这使我无法采用这种方法。从我的狭narrow角度来看，无论最终结果是什么，我们都需要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％的时间。
如果有人对不同模型有任何现实世界的经验，并且如果一个人花费的时间那么长，那么另一个人……请分享。或者，如果我有这个问题，那么也告诉我！
维度和度量是向最终用户呈现和简化数据的行之有效的方法。
如果您向最终用户提供基于源系统 (3nf) 的模式，而不是向最终用户提供维度建模的星型模式 (Kimball)，他们将能够更理解维度建模的模式
我从未真正研究过 Inmon 决策支持系统，但对我来说，它似乎只是完整数据仓库的 ODS 部分。
您说得对：“EDW 不是由源系统定义的，而是由业务结构定义的”。星型模式反映了这一点，但 ODS（源系统的副本）却没有
星型模式的构建时间比 ODS 更长，但具有许多好处，包括
如果您的 Inmon 3NF 数据库不仅仅是一个 ODS（源系统的副本），而是某种实际的业务模型，那么您有两层需要建模：3NF 层和星型模式层。
如今，当每个人都认为他们可以在“自助”工具中完成所有工作时，即使是一层数据建模的好处也很难推销！（我认为这是一个谬论）。您的系统不应该比它需要的更复杂，因为所有这些复杂性都会增加维护成本，这才是真正的问题 - 当您必须更改许多层时，在构建中引入更改 12 个月
解释@destination-data：源系统到星型模式的转换（和分离）已经通过 ETL 实现，因此 3nf 对我来说似乎是多余的。您可以通过正确实现代理键和业务键，并根据业务而不是源系统对其进行建模，将星型模式设计为独立于源系统
我为一个大型跨国公司管理着30亿条记录数据仓库。我们的数据从各种源系统一直到暂存并进入3NF数据库。从这里，我们的ELT流程将数据移动到一个尺寸建模的星型数据库中。
如果我可以重新开始，那我肯定会放弃3NF步骤。当我第一次构建该层时，我认为它将增加真正的价值。我确信规范化将保护我的数据的完整性。我同样有信心3NF数据库将是运行大型/复杂查询的最佳位置。
但是实际上，它减慢了我们的发展速度。大多数更改都需要更新舞台，3NF和星型数据库。
额外的层还增加了发布数据所需的时间。所有其他转换，检查和对帐加起来。
承诺的完整性改善从未实现。我现在意识到，由于我控制着ETL及其内部的验证过程，因此可以确保我的数据既非规范化又准确。在报告数据时，我们控制每个表中的每个单元格。我思考得越多，就越有机会。
大型而复杂的查询是被经验破坏的另一个神话。现在，我将需要编写复杂的报表查询作为我的star db的失败。发生这种情况时，我总是问自己：为什么这个问题不容易回答？答案通常是表格设计不正确。转换数据时最好执行繁重的工作。
运行3NF和star也为两个系统之间的分歧创造了机会。发生这种情况时，通常会有非常细微的差异。本身没有错。取而代之的是，3NF和星形查询可能会问一些稍有不同的问题，从而返回不同的结果。尽管从技术上讲是正确的，但这很难解释。随着时间的流逝，即使是微小且可以解释的差异也会削弱信心。
为了保护我们的3NF分贝，它确实使装入星空变得更加容易。但是我很乐意将更复杂的SSIS包换成少一层的东西。
说完所有这些；如果没有对他们的系统，需求，文化，技能等有深刻了解的人，很难向他们推荐一种方法。阅读您的问题后，我相信您已经为所有这些问题而苦恼，还有更多无疑的问题！最后，只有您才能决定哪种方法最适合您的情况。一旦下定决心，就坚持下去。一致性，清晰度和定义明确的方法比其他任何事情都重要。