EDW Kimball vs Inmon

Question

我的任务是提出如何进行EDW的建议，并希望澄清我所看到的。我所了解的一切都表明，与Inmon的方法相比，Kimball的方法将更快地为业务带来价值。我了解到，Kimball的方法是来自getgo的维度模型，不同的数据集市(星型模式)通过一致的维度集成在一起……因此，理论上我可以简单地提出我的直接DM来解决业务需求，并从那里继续下去。

我正在学习的内容表明，Inmon的模型表明我有一个用3NF设计的EDW。EDW不是由源系统定义的，而是由业务、公司工厂(订单、HR等)的结构定义的。因此，来自不同系统的数据映射到此结构中。一旦数据以这种形式出现，就会创建ETL来生成DM。

就我个人而言，我认为Inmon的方法是更好的方法。我相信这种方式将确保数据将是一致的，并且感觉您可以使用这些数据做更多事情。然而，阻碍我使用这种方法的是，我读到的所有东西都说，交付一些东西需要更多的时间，但我看不出这是怎么回事。从我的狭义观点来看，无论最终结果是什么，我们都需要一个DM。无论使用Kimball的方法还是Inmon的方法，最终结果都是相同的。

那么问题就变成了我们如何才能做到这一点？在Kimball方法中，我们将创建到一些临时位置的ETL，通常从那里创建一个DM。在Inmon的方法中，我觉得我们只是添加了另一层...也就是说，我们从中间区域将此数据加载到3NF中的另一个数据库中，该数据库是按函数组织的。我遗漏的是这一步如何增加了这么多时间。

我觉得我可以看到最终的DM，这是需要做的。将这些映射回3NF中的DW，然后随着请求的DM越来越多，继续使用越来越多的数据构建3NF中的DW。然而，如果我在Kimball模型中创建一个DM，DM将围绕为该DM决定的粒度级别构建，如果下一个DM请求的报告甚至是更深的粒度(对我来说，它感觉Kimball方法需要更多的工作)，而对于Inmon的，这并不重要。我拥有跨国级别的一切，所以需要不同粒度的DM，我有数据，只需将其ETL到DM，所有DM将报告相同的内容，因为它们来自相同的数据。

我不知道。只是在寻找别人的观点。我读到的都说金鲍尔的更快。我说，当然，也许有一点，但如果选择更快的路线，肯定会产生成本。为了争论..。假设一个DM需要一周的时间才能通过Kimball方法启动和运行……对我来说，使用Inmon应该只需要10%甚至20%的时间。

如果有人在现实世界中对不同的模型有任何经验，如果一个模型真的比另一个模型花费的时间长得多……请分享。或者，如果我是这么倒退的，那也告诉我吧！

Answer 1

作为背景，我管理着一个30亿的记录数据仓库，用于大型跨国企业。我们的数据从不同的源系统经过分段并进入3NF数据库。从这里，我们的ELT过程将数据移动到维度建模的星型模式db中。

如果我可以重新开始，我肯定会放弃3NF步骤。当我第一次构建这一层时，我认为它会增加真正的价值。我确信规范化将保护我的数据的完整性。我同样相信3NF数据库将是运行大型/复杂查询的最佳位置。

但在实践中，它已经减慢了我们的发展。大多数更改都需要对stage、3NF和星型模式db进行更新。

额外的层还增加了发布数据所需的时间。额外的转换、检查和协调都加起来了。

承诺的诚信改善从未实现。我现在意识到，因为我控制了ETL和其中的验证过程，所以我可以确保我的数据既非规范化又准确。在报告数据时，我们控制每个表中的每个单元格。我想得越多，就越觉得这是一个真正的机会。

大型和复杂的查询是另一个被经验打破的神话。我现在看到需要编写复杂的报告查询作为我的star数据库的失败。当这种情况发生时，我总是问自己:为什么这个问题不容易回答？答案通常是糟糕的表格设计。最好在转换数据时执行繁重的任务。

运行3NF和star也为这两个系统提供了不同意见的机会。当这种情况发生时，通常是一个非常微妙的差异。从本质上讲，两者都没有错。相反，3NF和star查询提出的问题可能略有不同，因此返回的结果也可能不同。虽然在技术上是正确的，但这可能很难解释。随着时间的推移，即使是微小的和可以解释的差异也会侵蚀信心。

为了保护我们的3NF db，它确实使加载到星形变得更容易。但我很乐意用更复杂的SSIS包换更少的一层。

话虽如此，如果不深入了解他们的系统、需求、文化、技能等，就很难向任何人推荐一种方法。读过你的问题后，我相信你已经解决了所有这些问题，毫无疑问还有更多的问题！最后，只有你才能决定最适合你情况的方法是什么。一旦你下定决心，就坚持下去。一致性、清晰度和定义良好的方法比其他任何东西都更重要。

Answer 2

维度和度量是向最终用户展示和简化数据的一种行之有效的方法。

如果您将基于源系统(3nf)的模式呈现给最终用户，而将维度建模的星型模式(Kimball)呈现给最终用户，他们将能够更好地理解维度建模的模式

我从来没有真正研究过Inmon决策支持系统，但对我来说，它似乎只是一个完整数据仓库的ODS部分。

您说得对，“EDW不是由源系统定义的，而是由业务结构定义的”。星型模式反映了这一点，但ODS (源系统的副本)不反映这一点

与ODS相比，星型模式需要更长的构建时间，但它提供了许多好处，包括

缓慢变化的维度可以通过time

• Denormalisation跟踪更改简化连接和改进performance

• Surrogate键允许您断开与源的连接systems

• Conformed维度允许您跨业务部门报告(即每个员工的利润)

如果您的Inmon 3NF数据库不仅仅是ODS (源系统的副本)，而是某种实际的业务模型，那么您有两层要建模: 3NF层和星型架构层。

如今，当每个人都认为他们可以在“自助式”工具中完成所有这些工作时，即使是一层数据建模的好处也很难推销！(我认为这是一种谬误)。您的系统不应该比需要的更复杂，因为所有这些复杂性加起来就是维护，而这才是真正的问题-当您必须更改许多层时，需要在构建中引入12个月的更改

套用@destination-data:您的源系统到星型模式的转换(和分离)已经通过ETL实现了，所以3nf对我来说似乎是多余的。通过正确实现代理键和业务键，并在业务上建模，而不是在源系统上，您可以将星型模式设计为独立于源系统

Answer 3

由于ETL和后端数据争论占据了这种努力项目时间的70%左右，额外的一层会产生很大的不同。这是一个额外的从源到目标的转换层，以与业务一致并进行测试。所有这些都是合理的。

虽然我并不是说维度模型(金球型)总是很容易改变的，但是当你想要改变你的BI时，如果你总是要改变很多层，你就会有更多的不灵活。

事实上，我一直在一些地方咨询，这些地方的数据仓库被认为开发起来不灵活，开发成本也很高，而且没有跟上业务变化的步伐，它们无一例外地在DM之前包括了3NF层。正如Nick提到的，现在很难推销“适当的”数据仓库的想法，而不是data Discovery Bi工具-而且这些工具的吸引力通常是由于DWs被认为开发缓慢和昂贵。

金博尔并不反对在他的DW之前有一个3NF层，如果这对于一种情况是有意义的，他只是不同意Inmon的观点。

一个常见的误解是，Kimball提出了不同的数据集市，因此每次有不同的报告请求时，您都必须对其进行更改。相反，金宝的DM基于现实生活中的业务流程，并进行了相应的建模。尽管你会试着让它们适合于报告，但你也要试着让它们能够回答可接受的查询。您不仅可以聚合和存储聚合数据:还可以在一个Kimball维度模型中处理事务数据。因此，从这个角度来看，没有必要不情愿。

如果ODS适合你，那就去试试吧--但是一个金博尔DW可以满足大多数需求。