数据仓库中的Inmon与Kimball架构
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
数据仓库中的Inmon与Kimball架构
对于数据仓库体系结构的最佳问题,始终存在许多不同的看法,甚⾄有⼈把Inmon和Kimball之争称之为数据仓库界的“宗教战争”,那么本⽂就通过对两位提倡的数据仓库体系和市场流⾏的另⼀种体系做简单描述和⽐较,不是为了下定义那个好,那个不好,⽽是让初学者更明⽩两位数据仓库⿐祖对数据仓库体系的见解⽽已。
⾸先,我们谈Inmon的企业信息化⼯⼚。
2000年5⽉,W.H.Inmon在DM Review杂志上发表⼀篇⽂章,⾥⾯写到⼀句话“……如果明天⾮得设计⼀个数据集市,我将不考虑使⽤其他的⽅法”;正是揭⽰了他的企业信息化⼯⼚的特点。
下图是关于他的企业信息化⼯⼚的架构图:
我们理解⼀下这个体系架构,左边是操作型系统或者事务系统,⾥⾯包括很多种系统,有数据库在线系统,有⽂本⽂件系统…等等。
⽽这些系统的数据经过ETL的过程,加载数据到企业数据仓库中,ETL的过程是整合不同系统的数据,经过整合,清洗和统⼀,因此我们可以称之为数据集成。
企业数据仓库是企业信息化⼯⼚的枢纽,是原⼦数据的集成仓库,但是由于企业数据仓库不是多维格式,因此不适合分析型应⽤程序,BI⼯具直接查询。
他的⽬的是将附加的数据存储⽤于各种分析型系统。
数据集市,是针对不同的主题区域,从企业数据仓库中获取的信息,转换成多维格式,然后通过不同⼿段的聚集、计算,最后提供最终⽤户分析使⽤,因此Inmon把信息从企业数据仓库移动到数据集市的过程描述为“数据交付”。
接下来我们来看Kimball的维度数据仓库:
kimball的维度数据仓库是基于维度模型建⽴的企业级数据仓库,它的架构有的时候可以称之为“总线体系结构”,和inmon提出的企业信息化⼯⼚有很多相似之处,都是考虑原⼦数据的集成仓库;我们来根据下⾯的架构来分析他的观点:
虽然初看两个图有很多不⼀样的地⽅,但是这两种结构有很多相似之处:⼀,都是假设操作型系统和分析型系统是分离的;⼆,数据源(操作型系统)都是众多;三,ETL整合了多种操作型系统的信息,集中到⼀个企业数据仓库。
当然如果去区别他们的不同,最⼤的不同就是企业数据仓库的模式不同,inmon是采⽤第三范式的格式,⽽kimball则采⽤了多维模型–星型模型,并且还是最低粒度的数据存储。
其次是,维度数据仓库可以被分析系统直接访问,当然这种访问⽅式毕竟在分析过程中很少使⽤。
最后就是数据集市的概念有逻辑上的区别,在kimball的架构中,数据集市有维度数据仓库的⾼亮显⽰的表的⼦集来表⽰。
当然有的时候,在kimball的架构中,有⼀个可变通的设计,就是在ETL的过程中加⼊ODS层,使得ODS层中能保留第三范式的⼀组表来作
为ETL过程的过度。
但是这个思想,Kimball看来只是ETL的过程辅助⽽已。
另外,还可以把数据集市和企业维度数据仓库分离开来,这样多⼀层所谓的展现层(presentationlayer),这些变通的设计都是可以接受的,只要符合企业本⾝分析的需求。
最后⼀种是独⽴型数据集市,来⾃市场的实施过程被⼴泛使⽤,下⾯是独⽴型数据集市的架构:特点是⾮常简单,容易实现,⽽且实施时间段。
但是最⼤的问题是,由于快速的实施,廉价的过程,导致长期费⽤的提供和效率的低下。
开发⼀个独⽴的数据集市是获得可见结果的最有效的⽅法,因为不需要做跨部门,跨功能的分析,并且数据集市可以很快投⼊到⽣产中,因此能够迅速和廉价地获得结果,所以很多机构应⽤这种⽅法。
⽽且很多ERP集成商的系统中也⾃带了类似的功能作为⼀个卖点来吸引客户。
虽然它有很多有点,但是最致命的缺点,短期的成功却带来长期的棘⼿问题。
特别是独⽴型数据集市⽀持多主题区域时,会导致多个部门数据不⼀致,就是数据打架的现象。
并且使得各个数据集市成为信息孤岛,缺乏兼容性。
因此这种⽅案很多时候是不可接受的。
通过本⽂的简要的介绍3种体系结构,希望能帮助你准确的理解数据仓库的体系结构和实施⽅法。