通俗易懂数仓建模—Inmon范式建模与Kimball维度建模
数仓指标、标签、维度、度量、自然键、代理键等常见概念术语关系解析
数仓指标、标签、维度、度量、自然键、代理键等常见概念术语关系解析作为一个数据人，是不是经常被各种名词围绕，是不是对其中很多概念认知模糊。
有些词虽然只有一字之差，但是它们意思完全不同，今天我们就来了解下数仓建设及数据分析时常见的一些概念含义及它们之间的关系。
建议大家收藏此文，以后遇到不熟悉的概念可以在本篇文章中查找下本文结构如下图所示：一、数仓中常见概念解析1. 实体实体是指依附的主体，就是我们分析的一个对象，比如我们分析商品的销售情况，如华为手机近半年的销售量是多少，那华为手机就是一个实体；我们分析用户的活跃度，用户就是一个实体。
当然实体也可以现实中不存在的，比如虚拟的业务对象，活动，会员等都可看做一个实体。
实体的存在是为了业务分析，作为分析的一个筛选的维度，拥有描述自己的属性，本身具有可分析的价值。
2. 维度维度就是看待问题的角度，分析业务数据，从什么角度分析，就建立什么样的维度。
所以维度就是要对数据进行分析时所用的一个量，比如你要分析产品销售情况，你可以选择按商品类别来进行分析，这就构成一个维度，把所有商品类别集合在一起，就构成了维度表。
3. 度量度量是业务流程节点上的一个数值。
比如销量，价格，成本等等。
事实表中的度量可分为三类：完全可加，半可加，不可加。
1.完全可加的度量是最灵活，最有用的，比如说销量，销售额等，可进行任意维度汇总；2.半可加的度量可以对某些维度汇总，但不能对所有维度汇总，差额是常见的半可加度量，它除了时间维度外，可以跨所有维度进行加法操作；3.还有一种是完全不可加的，例如：比率。
对于这类非可加度量，一种好的方法是，尽可能存储非可加度量的完全可加分量，并在计算出最终的非可加事实前，将这些分量汇总到最终的结果集中。
4. 粒度粒度就是业务流程中对度量的单位，比如商品是按件记录度量，还是按批记录度量。
在数仓建设中，我们说这是用户粒度的事实表，那么表中每行数据都是一个用户，无重复用户；例如还有销售粒度的表，那么表中每行都是一条销售记录。
数据仓库中的Inmon与Kimball架构
数据仓库中的Inmon与Kimball架构对于数据仓库体系结构的最佳问题，始终存在许多不同的看法，甚⾄有⼈把Inmon和Kimball之争称之为数据仓库界的“宗教战争”，那么本⽂就通过对两位提倡的数据仓库体系和市场流⾏的另⼀种体系做简单描述和⽐较，不是为了下定义那个好，那个不好，⽽是让初学者更明⽩两位数据仓库⿐祖对数据仓库体系的见解⽽已。
⾸先，我们谈Inmon的企业信息化⼯⼚。
2000年5⽉，W.H.Inmon在DM Review杂志上发表⼀篇⽂章，⾥⾯写到⼀句话“……如果明天⾮得设计⼀个数据集市，我将不考虑使⽤其他的⽅法”；正是揭⽰了他的企业信息化⼯⼚的特点。
下图是关于他的企业信息化⼯⼚的架构图：我们理解⼀下这个体系架构，左边是操作型系统或者事务系统，⾥⾯包括很多种系统，有数据库在线系统，有⽂本⽂件系统…等等。
⽽这些系统的数据经过ETL的过程，加载数据到企业数据仓库中，ETL的过程是整合不同系统的数据，经过整合，清洗和统⼀，因此我们可以称之为数据集成。
企业数据仓库是企业信息化⼯⼚的枢纽，是原⼦数据的集成仓库，但是由于企业数据仓库不是多维格式，因此不适合分析型应⽤程序，BI⼯具直接查询。
他的⽬的是将附加的数据存储⽤于各种分析型系统。
数据集市，是针对不同的主题区域，从企业数据仓库中获取的信息，转换成多维格式，然后通过不同⼿段的聚集、计算，最后提供最终⽤户分析使⽤，因此Inmon把信息从企业数据仓库移动到数据集市的过程描述为“数据交付”。
接下来我们来看Kimball的维度数据仓库：kimball的维度数据仓库是基于维度模型建⽴的企业级数据仓库，它的架构有的时候可以称之为“总线体系结构”，和inmon提出的企业信息化⼯⼚有很多相似之处，都是考虑原⼦数据的集成仓库；我们来根据下⾯的架构来分析他的观点：虽然初看两个图有很多不⼀样的地⽅，但是这两种结构有很多相似之处：⼀，都是假设操作型系统和分析型系统是分离的；⼆，数据源（操作型系统）都是众多；三，ETL整合了多种操作型系统的信息，集中到⼀个企业数据仓库。
数据仓库之数据建模理论
数据仓库之数据建模理论数据仓库建模理论就像⼤厦的地基，只有把建模理论理解清楚，在数据建模时才能有理有据。
作为⼀个数据仓库开发⼈员，数据建模理论是我们必须要掌握和理解的⼀部分，只要充分理解了数据建模理论知识，在建设数据仓库时我们就可轻松上⼿。
数据建模理论Kimball维度建模 和 Inmon范式建模数据仓库的两⼤模式：Kimball维度建模 和 Inmon范式建模⼀、Inmon范式建模1.1、什么是Inmon范式模型？数据仓库是商业智能的⼀部分，⼀家企业或公司只有⼀个数据仓库，数据集市的信息皆来源数据仓库。
现在的数据库⼤多数都是依据3FN范式来建⽴的，⽽依据范式的思想来进⾏数据仓库建模，就是范式建模。
数据仓库中的数据信息必须符合第三范式。
范式是关系型数据库的基本概念。
是指符合某些条件、符合某些规则的关系集合。
范式是分级的，每向上⼀级，条件和规则更加严格，每⼀级是下⼀级的⼦集。
范式最主要的⽬的是消除冗余，每⼀份信息必须存放⼀次，也只能存储⼀次。
数据的冗余不仅仅会造成存储资源的浪费，⽽且可能会引发数据的更新异常。
⼆、Kimball维度建模2.1、什么是Kimball维度建模？数据仓库是公司内部所有数据集市的集合，信息总是被存储在多维模型中。
是⾯向数据集市、数据主题的，⼀般采⽤星型模型建模。
依据星型模型，构建事实表和维度表，建⽴数据仓库模型的过程，就是维度建模。
Kimball的核⼼思想就是星型模型和维度建模。
2.2、什么是星型模型？所有的表直接与事实表关联，整个图解就像星星⼀样，该模型称为星型模型。
星型模型是⼀种⾮正规化的结构，是反范式的。
因为多维数据集的每⼀个维度都直接与事实表相连接，不存在渐变维度，所以数据有⼀定的冗余，星型模型2.3、事实表和维度表事实表描述业务过程的度量、以可加数据为主题，每⼀⾏代表⼀个可以观察的实体或事件。
主要的是发⽣了业务过程，如卖出⼀件商品，⽤户购买⼀件商品，这都触发了业务过程。
大数据和Hadoop时代的维度建模和Kimball数据集市_光环大数据Hadoop培训
大数据和Hadoop时代的维度建模和Kimball数据集市_光环大数据Hadoop培训有一个常见的误区，数据建模的目的是用ER 图来设计物理数据库，实际上远不仅如此。
数据建模代表了企业业务流程的复杂度，记录了重要的业务规则和概念，并有助于规范企业的关键术语。
它清晰地阐述、协助企业揭示商业过程中模糊的想法和歧义。
此外，可以使用数据模型与其他利益相关者进行有效沟通。
没有蓝图，不可能建造一个房子或桥梁。
所以，没有数据模型这样一个蓝图，为什么要建立一个数据应用，比如数据仓库呢?为什么需要维度建模?维度建模是数据建模的一种特殊方法。
维度建模有两个同义词，数据集市和星型结构。
星型结构是为了更好地进行数据分析，参考下面图示的维度模型，可以有一个很直观的理解。
通过它可以立即知道如何通过客户、产品、时间对订单进行分割，如何通过度量的聚集和比较对订单业务过程进行绩效评估。
维度建模最关键的一点，是要定义事务性业务过程中的最低粒度是什么。
如果切割或钻入数据，到叶级就不能再往下钻取。
从另一个角度看，星型结构中的最低粒度，即事实和维度之间没有进行任何聚集的关联。
数据建模和维度建模标准数据建模的任务，是消除重复和冗余的数据。
当数据发生变化时，我们只需在一个地方修改它，这有助于保证数据的质量，避免了不同地方的数据不同步。
参考下面图示的模型，它包含了代表地理概念的几张表。
在规范化模型中，每个实体有一个独立的表，数据建模只有一张表：geography。
在这张表中，city 会重复出现很多次。
而对于每个city，如果country 改变了名字，就不得不在很多地方进行更新。
注：标准数据模型总是遵守3NF 模式。
标准的数据建模，本身并不是为了商业智能的工作负载而设计的。
太多的表会导致过多的关联，而表关联会导致性能下降，在数据分析中我们要尽力去避免这种情形发生。
数据建模过程中，通过反规范化把多个相关表合并成一个表，例如前面例子里的多个表被预合并成一个geography 表。
数仓学习-维度建模
数仓维度建模（如有侵权请联系删除）一、什么是维度建模按照事实表，维度表来构建数据仓库，数据集市。
将数据结构化的逻辑设计方法，它将客观世界划分为度量和上下文。
二、维度建模的优势和原则1、优势和缺点a) 维度建模是可预测的标准框架。
允许数据库系统和最终用户查询工具在数据方面生成强大的假设条件，这些数据主要在表现和性能方面起作用。
b) 星型连接模式的可预测框架能够忍受不可预知的用户行为变化。
c) 具有非常好的可扩展性，以便容纳不可预知的新数据源和新的设计决策。
可以很方便在不改变模型粒度情况下，增加新的分析维度和事实，不需要重载数据，也不需要为了适应新的改变而重新编码。
较好的扩展性意味着以前的所有应用都可以继续运行，并不会产生不同的结果。
但是，维度建模法的缺点也是非常明显的，由于在构建星型模式之前需要进行大量的数据预处理，因此会导致大量的数据处理工作。
而且，当业务发生变化，需要重新进行维度的定义时，往往需要重新进行维度数据的预处理。
而在这些与处理过程中，往往会导致大量的数据冗余。
另外一个维度建模法的缺点就是，如果只是依靠单纯的维度建模，不能保证数据来源的一致性和准确性，而且在数据仓库的底层，不是特别适用于维度建模的方法。
2、维度建模的原则原则1、载入详细的原子数据到维度结构中维度建模应该使用最基础的原子数据进行填充，以支持不可预知的来自用户查询的过滤和分组请求，用户通常不希望每次只看到一个单一的记录，但是你无法预测用户想要掩盖哪些数据，想要显示哪些数据，如果只有汇总数据，那么你已经设定了数据的使用模式，当用户想要深入挖掘数据时他们就会遇到障碍。
当然，原子数据也可以通过概要维度建模进行补充，但企业用户无法只在汇总数据上工作，他们需要原始数据回答不断变化的问题。
原则2、围绕业务流程构建维度模型业务流程是组织执行的活动，它们代表可测量的事件，如下一个订单或做一次结算，业务流程通常会捕获或生成唯一的与某个事件相关的性能指标，这些数据转换成事实后，每个业务流程都用一个原子事实表表示，除了单个流程事实表外，有时会从多个流程事实表合并成一个事实表，而且合并事实表是对单一流程事实表的一个很好的补充，并不能代替它们。
范式建模维度建模比较.doc
一、范式建模
这样的设计方式是在关系型数据库中常用的，Inmon的范式建模法的最大
优点就是从关系型数据库的角度出发，结合了业务系统的数据模型，能够比
较方便的实现数据仓库的建模。
1.1范式化模型设计需满足下面三大范式：
1.1.1第一范式（1NF）:原子性字段不可再分,否则就不是关系数据
库;
2.4维度建模设计流程图
2.5高层模型设计
日期
订单杂项订单产品
客户
2.6识别维度和度量
有了高层模型，就要设计维度和度量，维度和度量清单不仅仅是业务用户所关心，
还要从业务过程出发，自上而下的设计所涉及的维度和度量。防止业务用户的需
求变化带来的冲击。
2.7确定命名规范
在详细设计之前，为DW/BI系统制定规范，主要包含源系统、主题、业务术语、
1.1.2第二范式（2NF）:唯一性一个表只说明一个事物;
1.1.3第三范式（3NF）:每列都与主键有直接关系，不存在传递依赖;
1.2特点：
同一份数据只存放在一个地方，因此只能从一个地方获取，没有数
据冗余，保证了数据一致性；
解耦（系统级与业务级），方便维护；
设计思路自上而下，适合上游基础数据存储，同一份数据只存储一
参考资料数据仓库工具箱：维度建模的完全指南（第二版）》
三、优缺点比较
范式建模优点
范式建模缺点
从关系型数据库的角度出发，结合由于建模方法限定在关系型数据库
了业务系统的数据模型，能够比较之上，在某些时候反而限制了整个
方便的实现数据仓库的建模数据仓库模型的灵活性，性能等，
特别是考虑到数据仓库的底层数据
向数据集市的数据进行汇总时，需
2.1特点：
数据仓库建模方法总结
数据仓库建模方法总结数据仓库建模是数据仓库构建过程中的重要环节，它决定了数据仓库的数据结构和查询性能。
本文将总结几种常见的数据仓库建模方法，包括维度建模、事实建模和标准化建模，并比较它们的优缺点。
1. 维度建模维度建模是一种常见的数据仓库建模方法，它基于维度表和事实表的概念。
维度表包含描述业务过程的属性，如时间、地点、产品等，而事实表包含与业务过程相关的度量。
维度表和事实表通过共同的键连接起来，形成星型或雪花型的模型。
优点：1) 简单直观：维度建模易于理解和使用，可以快速设计和构建数据仓库。
2) 查询性能高：维度建模的星型结构简化了查询的关联操作，提高了查询性能。
缺点：1) 一对一关系：维度表和事实表之间是一对多的关系，无法处理多对多的关系。
2) 数据冗余：维度表中的属性可能存在冗余，造成数据冗余和一致性问题。
2. 事实建模事实建模是基于主题的数据仓库建模方法，它以业务过程为核心构建事实表，包括维度键和度量。
事实表记录了业务过程发生的事实信息，维度键用于连接事实表和维度表，度量用于度量业务过程的指标。
优点：1) 灵活性高：事实建模能够适应复杂的业务逻辑和多对多的关系。
2) 数据粒度控制：事实表可以根据需要控制数据的粒度，提供灵活的查询和分析能力。
缺点：1) 设计复杂：事实建模的设计复杂度较高，需要考虑多对多的关系和度量的粒度控制。
2) 查询性能相对低：事实建模需要进行多表关联操作，查询性能相对较低。
3. 标准化建模标准化建模是一种将数据仓库模型与关系数据库模型类似的建模方法。
它将数据存储在标准化的表中，通过复杂的关联操作来查询和分析数据。
标准化建模与维度建模和事实建模相比，更适用于小型数据仓库和查询较少的情况。
优点：1) 数据一致性：标准化建模减少了数据冗余，提高了数据一致性。
2) 灵活可扩展：标准化建模可以适应不同的查询需求，支持灵活的查询和分析。
缺点：1) 查询复杂：标准化建模需要进行多表关联和聚合操作，查询复杂度较高。
数据仓库建模方法
数据仓库建模方法每个行业有自己的模型，但是不同行业的数据模型，在数据建模的方法上，却都有着共通的基本特点。
什么是数据模型数据模型是抽象描述现实世界的一种工具和方法，是通过抽象的实体及实体之间联系的形式，来表示现实世界中事务的相互关系的一种映射。
在这里，数据模型表现的抽象的是实体和实体之间的关系，通过对实体和实体之间关系的定义和描述，来表达实际的业务中具体的业务关系。
数据仓库模型是数据模型中针对特定的数据仓库应用系统的一种特定的数据模型，一般的来说，我们数据仓库模型分为几下几个层次。
图 2. 数据仓库模型通过上面的图形，我们能够很容易的看出在整个数据仓库得建模过程中，我们需要经历一般四个过程： ?业务建模，生成业务模型，主要解决业务层面的分解和程序化。
?领域建模，生成领域模型，主要是对业务模型进行抽象处理，生成领域概念模型。
?逻辑建模，生成逻辑模型，主要是将领域模型的概念实体以及实体之间的关系进行数据库层次的逻辑化。
?物理建模，生成物理模型，主要解决，逻辑模型针对不同关系型数据库的物理化以及性能等一些具体的技术问题。
因此，在整个数据仓库的模型的设计和架构中，既涉及到业务知识，也涉及到了具体的技术，我们既需要了解丰富的行业经验，同时，也需要一定的信息技术来帮助我们实现我们的数据模型，最重要的是，我们还需要一个非常适用的方法论，来指导我们自己针对我们的业务进行抽象，处理，生成各个阶段的模型。
为什么需要数据模型在数据仓库的建设中，我们一再强调需要数据模型，那么数据模型究竟为什么这么重要呢？首先我们需要了解整个数据仓库的建设的发展史。
数据仓库的发展大致经历了这样的三个过程：?简单报表阶段：这个阶段，系统的主要目标是解决一些日常的工作中业务人员需要的报表，?以及生成一些简单的能够帮助领导进行决策所需要的汇总数据。
这个阶段的大部分表现形式为数据库和前端报表工具。
?数据集市阶段：这个阶段，主要是根据某个业务部门的需要，进行一定的数据的采集，整理，按照业务人员的需要，进行多维报表的展现，能够提供对特定业务指导的数据，并且能够提供特定的领导决策数据。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
通俗易懂数仓建模—Inmon范式建模与Kimball维度建模
在数据仓库领域，有两位大师，一位是“数据仓库”之父B i l l I n m o n，一位是数据仓库权威专家R a l p h K im ba l l，两位大师每人都有一本经典著作，I n m o n大师著作《数据仓库》及K im ba l l大师的《数仓工具箱》，两本书也代表了两种不同的数仓建设模式，这两种架构模式支撑了数据仓库以及商业智能近二十年的发展。
今天我们就来聊下这两种建模方式——范式建模和维度建模。
本文开始先简单理解两种建模的核心思想，然后根据一个具体的例子，分别使用这两种建模方式进行建模，大家便会一目了然！
一、两种建模思想
对于In mo n和K i m ba l l两种建模方式可以长篇大论叙述，但理论是很枯燥的，尤其是晦涩难懂的文字，大家读完估计也不会收获太多，所以我根据自己的理解用通俗的语言提炼出最核心的概念。
范式建模
范式建模是数仓之父In mo n所倡导的，“数据仓库”这个词就是这位大师所定义的，这种建模方式在范式理论上符合3N F，这里的3N F与O L T P中的3N F还是有点区别的：关系数据库中的3N F是针对具体的业务流程的实体对象关系抽象，而数据仓库的3N F是站在企业角度面向主题的抽象。
I n m o n模型从流程上看是自上而下的，自上而下指的是数据的流向，“上”即数据的上游，“下”即数据的下游，即从分散异构的数据源-> 数据仓库-> 数据集市。
以数据源头为导向，然后一步步探索获取尽量符合预期的数据，因为数据源往往是异构的，所以会更加强调数据的清洗工作，将数据抽取为实体-关系模型，并不强调事实表和维度表的概念。
维度建模
K i m b al l模型从流程上看是自下而上的，即从数据集市-> 数据仓库-> 分散异构的数据源。
K i mb a l l是以最终任务为导向，将数据按照目标拆分出不同的表需
求，数据会抽取为事实-维度模型，数据源经E T L转化为事实表和维度表导入数据集市，以星型模型或雪花模型等方式构建维度数据仓库，架构体系中，数据集
市与数据仓库是紧密结合的，数据集市是数据仓库中一个逻辑上的主题域。
两种建模方式的理论概念就简单介绍到这，因为纯理论知识说再多，大家也可能有点迷惑，所以下面用一个具体的例子来实践两种建模方式。
二、两种建模实践
通过上一小节两种建模核心思想，相信大家对这两种建模方式已经有了大概的理解，接下来我们通过具体的例子，让大家有具体的感受。
以电商举例
大家都网购过，知道购买物品的流程，因此以电商购物为例，更易于大家的理解。
真实的电商购物的流程较复杂，此处表数量和表字段做简化处理。
1. 源表的结构及数据
对于我们大数据平台来说，源表指的电商系统中后台数据库中的表，这种表一般都是O L T P类型的表：
①用户信息表
②城市信息表
③用户等级表
④用户订单表
2. 使用Inmon模式建模
使用In mo n模式对以上源表数据进行建模，需要将数据抽取为实体-关系模式，根据源表的数据，我们将表拆分为：用户实体表，订单实体表，城市信息实体表，用户与城市信息关系表，用户与用户等级关系表等多个子模块：
①用户实体表
(注：E T L已过滤掉注销用户)
②支付成功订单实体表
③城市信息实体表
④订单与用户关系表
⑤用户与城市信息关系表
⑥用户与用户等级关系表
通过以上我们可以发现，范式建模就是将源表抽取为实体表，关系表，所以范式建模即是实体关系（E R）模型。
数据没有冗余，符合三范式设计规范。
3. 使用Kimball模式建模
使用K i m b al l模式，需要将数据抽取为事实表和维度表，根据源表数据，我们将表拆分为：订单事实表，用户维度表，城市信息维度表，用户等级维度表。
可以看出，在K im ba l l 的维度建模中，不需要单独维护数据关系表，因为关系已经冗余在事实表和维度表中。
①支付成功订单事实表
②用户维度表
③城市信息维度表
④用户等级维度表
我们用图的方式将以上表之间的关系简单展示出来：
根据上图，我们发现什么，这不就是典型的雪花模式嘛，其特点就是维度表可以拥有其他维度表。
三、两种建模对比
两种建模方式特点
范式建模：通过上一小节的具体例子可以看出范式建模的优点：能够结合业务系统的数据模型，较方便的实现数据仓库的模型；同一份数据只存放在一个地
方，没有数据冗余，保证了数据一致性；数据解耦，方便维护。
但同时也带来了缺点：表的数量多；查询时关联表较多使得查询性能降低。
维度建模：模型结构简单，面向分析，为了提高查询性能可以增加数据冗余，反规范化的设计，开发周期短，能够快速迭代。
缺点就是数据会大量冗余，预处理阶段开销大，后期维护麻烦；还有一个问题就是不能保证数据口径一致性，原因后面有讲解。
我们再来理解下维度建模：数据会抽取为事实-维度模型，维度就是看待问题的
角度，从不同的角度看待某个问题，就会得出不同的结论，而要得到这个结
论，就需要事实表中的度量，何为度量，就是事实表中数值类型的字段。
例：某公司的各个商品在全国各地市的销售情况，维度就是全国的城市和各个商品，度量就是商品的单价，从不同的维度计算销售额：如查看北京市酸奶的销售额，上海市纯牛奶的销售额，这就是不同的维度组合方式。
在限定的维度
条件上，计算商品单价的总和，也就是s u m 度量值，即可得到我们想要的结果。
维度建模，就是依靠维度进行建模，但是如果维度设计的不合理，会不会带来问题呢？
如果我们把省份当做一个单独维度，城市当做一个维度，计算城市的人口数量。
这时省份和城市都是单独的维度，它们之间没有了关系，就会出现以下情况：
广东省杭州市1500
浙江省广州市1200
这时会出现数据口径不一致，最后导致数据结果不准确。
而范式建模就不会出现这个问题，因为在范式建模中强调的就是实体-关系模型，所以省份和城市之间一定存在归属关系的，不会出现省份和城市口径不一致的问题。
所以，范式建模能保证口径的一致性，而维度建模不能！
建模方式对比
通过上一节的具体的例子以及两种建模的特点，我们对比下两种建模方式的不
我们知道，互联网公司的业务一般是周期比较短需求变化快，并且迭代频繁，如果精心设计In m o n实体-关系的模式似乎并不能满足快速迭代的业务需要。
所以，互联网公司更多场景下趋向于使用K i m b a l l 维度-事实的设计反而可以更快地完成任务。
四、两种建模混合场景
通过以上几个小节我们已经理解了范式建模与维度建模的思想以及它们之间的异同，优缺点。
那么我们能不能将两种建模方式混合使用呢，让它们发挥各自最大的优势。
接下来我们一起来看下。
范式建模必须符合准三范式设计规范，如果使用混合建模，则源表也需要符合范式建模的限制，即源数据须为操作型或事务型系统的数据。
通过E T L抽取转换和加载到数据仓库的O D S层，O DS层数据与源数据是保持一致的，所以O D S 层数据也是符合范式设计规范的，通过O D S的数据，利用范式建模方法，建设原子数据的数据仓库E D W，然后基于E D W，利用维度建模方法建设数据集市。
结合两种建模方式的各自规范，混合建模按照“松耦合、层次化”的基本架构原则进行实施。
混合数据仓库架构方法主要包含以下关键步骤：业务需求分步构
建、分层次保存数据、整合原子级的数据标准、维护一致性维度等。
最后
建模方式没有好与坏之分，只有合适与不合适之分，在实际数仓建设中，需要灵活多变，不能全依赖建模理论，也不能不依赖。
适时变通，才能建设一个好的数据仓库。