通俗易懂数仓建模—Inmon范式建模与Kimball维度建模

数仓指标、标签、维度、度量、自然键、代理键等常见概念术语关系解析作为一个数据人，是不是经常被各种名词围绕，是不是对其中很多概念认知模糊。

有些词虽然只有一字之差，但是它们意思完全不同，今天我们就来了解下数仓建设及数据分析时常见的一些概念含义及它们之间的关系。

建议大家收藏此文，以后遇到不熟悉的概念可以在本篇文章中查找下本文结构如下图所示：一、数仓中常见概念解析1. 实体实体是指依附的主体，就是我们分析的一个对象，比如我们分析商品的销售情况，如华为手机近半年的销售量是多少，那华为手机就是一个实体；我们分析用户的活跃度，用户就是一个实体。

当然实体也可以现实中不存在的，比如虚拟的业务对象，活动，会员等都可看做一个实体。

实体的存在是为了业务分析，作为分析的一个筛选的维度，拥有描述自己的属性，本身具有可分析的价值。

2. 维度维度就是看待问题的角度，分析业务数据，从什么角度分析，就建立什么样的维度。

所以维度就是要对数据进行分析时所用的一个量，比如你要分析产品销售情况，你可以选择按商品类别来进行分析，这就构成一个维度，把所有商品类别集合在一起，就构成了维度表。

3. 度量度量是业务流程节点上的一个数值。

比如销量，价格，成本等等。

事实表中的度量可分为三类：完全可加，半可加，不可加。

1.完全可加的度量是最灵活，最有用的，比如说销量，销售额等，可进行任意维度汇总；2.半可加的度量可以对某些维度汇总，但不能对所有维度汇总，差额是常见的半可加度量，它除了时间维度外，可以跨所有维度进行加法操作；3.还有一种是完全不可加的，例如：比率。

对于这类非可加度量，一种好的方法是，尽可能存储非可加度量的完全可加分量，并在计算出最终的非可加事实前，将这些分量汇总到最终的结果集中。

4. 粒度粒度就是业务流程中对度量的单位，比如商品是按件记录度量，还是按批记录度量。

在数仓建设中，我们说这是用户粒度的事实表，那么表中每行数据都是一个用户，无重复用户；例如还有销售粒度的表，那么表中每行都是一条销售记录。

数据仓库中的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培训有一个常见的误区，数据建模的目的是用ER 图来设计物理数据库，实际上远不仅如此。

数据建模代表了企业业务流程的复杂度，记录了重要的业务规则和概念，并有助于规范企业的关键术语。

它清晰地阐述、协助企业揭示商业过程中模糊的想法和歧义。

此外，可以使用数据模型与其他利益相关者进行有效沟通。

没有蓝图，不可能建造一个房子或桥梁。

所以，没有数据模型这样一个蓝图，为什么要建立一个数据应用，比如数据仓库呢?为什么需要维度建模?维度建模是数据建模的一种特殊方法。

维度建模有两个同义词，数据集市和星型结构。

星型结构是为了更好地进行数据分析，参考下面图示的维度模型，可以有一个很直观的理解。

通过它可以立即知道如何通过客户、产品、时间对订单进行分割，如何通过度量的聚集和比较对订单业务过程进行绩效评估。

维度建模最关键的一点，是要定义事务性业务过程中的最低粒度是什么。

如果切割或钻入数据，到叶级就不能再往下钻取。

从另一个角度看，星型结构中的最低粒度，即事实和维度之间没有进行任何聚集的关联。

数据建模和维度建模标准数据建模的任务，是消除重复和冗余的数据。

当数据发生变化时，我们只需在一个地方修改它，这有助于保证数据的质量，避免了不同地方的数据不同步。

参考下面图示的模型，它包含了代表地理概念的几张表。

在规范化模型中，每个实体有一个独立的表，数据建模只有一张表：geography。

在这张表中，city 会重复出现很多次。

而对于每个city，如果country 改变了名字，就不得不在很多地方进行更新。

注：标准数据模型总是遵守3NF 模式。

标准的数据建模，本身并不是为了商业智能的工作负载而设计的。

太多的表会导致过多的关联，而表关联会导致性能下降，在数据分析中我们要尽力去避免这种情形发生。

数据建模过程中，通过反规范化把多个相关表合并成一个表，例如前面例子里的多个表被预合并成一个geography 表。

数仓维度建模（如有侵权请联系删除）一、什么是维度建模按照事实表，维度表来构建数据仓库，数据集市。

将数据结构化的逻辑设计方法，它将客观世界划分为度量和上下文。

二、维度建模的优势和原则1、优势和缺点a) 维度建模是可预测的标准框架。

允许数据库系统和最终用户查询工具在数据方面生成强大的假设条件，这些数据主要在表现和性能方面起作用。

b) 星型连接模式的可预测框架能够忍受不可预知的用户行为变化。

c) 具有非常好的可扩展性，以便容纳不可预知的新数据源和新的设计决策。

可以很方便在不改变模型粒度情况下，增加新的分析维度和事实，不需要重载数据，也不需要为了适应新的改变而重新编码。

较好的扩展性意味着以前的所有应用都可以继续运行，并不会产生不同的结果。

但是，维度建模法的缺点也是非常明显的，由于在构建星型模式之前需要进行大量的数据预处理，因此会导致大量的数据处理工作。

而且，当业务发生变化，需要重新进行维度的定义时，往往需要重新进行维度数据的预处理。

而在这些与处理过程中，往往会导致大量的数据冗余。

另外一个维度建模法的缺点就是，如果只是依靠单纯的维度建模，不能保证数据来源的一致性和准确性，而且在数据仓库的底层，不是特别适用于维度建模的方法。

2、维度建模的原则原则1、载入详细的原子数据到维度结构中维度建模应该使用最基础的原子数据进行填充，以支持不可预知的来自用户查询的过滤和分组请求，用户通常不希望每次只看到一个单一的记录，但是你无法预测用户想要掩盖哪些数据，想要显示哪些数据，如果只有汇总数据，那么你已经设定了数据的使用模式，当用户想要深入挖掘数据时他们就会遇到障碍。

当然，原子数据也可以通过概要维度建模进行补充，但企业用户无法只在汇总数据上工作，他们需要原始数据回答不断变化的问题。

原则2、围绕业务流程构建维度模型业务流程是组织执行的活动，它们代表可测量的事件，如下一个订单或做一次结算，业务流程通常会捕获或生成唯一的与某个事件相关的性能指标，这些数据转换成事实后，每个业务流程都用一个原子事实表表示，除了单个流程事实表外，有时会从多个流程事实表合并成一个事实表，而且合并事实表是对单一流程事实表的一个很好的补充，并不能代替它们。

数据仓库建模方法总结数据仓库建模是数据仓库构建过程中的重要环节，它决定了数据仓库的数据结构和查询性能。

本文将总结几种常见的数据仓库建模方法，包括维度建模、事实建模和标准化建模，并比较它们的优缺点。

1. 维度建模维度建模是一种常见的数据仓库建模方法，它基于维度表和事实表的概念。

维度表包含描述业务过程的属性，如时间、地点、产品等，而事实表包含与业务过程相关的度量。

维度表和事实表通过共同的键连接起来，形成星型或雪花型的模型。

优点：1) 简单直观：维度建模易于理解和使用，可以快速设计和构建数据仓库。

2) 查询性能高：维度建模的星型结构简化了查询的关联操作，提高了查询性能。

缺点：1) 一对一关系：维度表和事实表之间是一对多的关系，无法处理多对多的关系。

2) 数据冗余：维度表中的属性可能存在冗余，造成数据冗余和一致性问题。

2. 事实建模事实建模是基于主题的数据仓库建模方法，它以业务过程为核心构建事实表，包括维度键和度量。

事实表记录了业务过程发生的事实信息，维度键用于连接事实表和维度表，度量用于度量业务过程的指标。

优点：1) 灵活性高：事实建模能够适应复杂的业务逻辑和多对多的关系。

2) 数据粒度控制：事实表可以根据需要控制数据的粒度，提供灵活的查询和分析能力。

缺点：1) 设计复杂：事实建模的设计复杂度较高，需要考虑多对多的关系和度量的粒度控制。

2) 查询性能相对低：事实建模需要进行多表关联操作，查询性能相对较低。

3. 标准化建模标准化建模是一种将数据仓库模型与关系数据库模型类似的建模方法。

它将数据存储在标准化的表中，通过复杂的关联操作来查询和分析数据。

标准化建模与维度建模和事实建模相比，更适用于小型数据仓库和查询较少的情况。

优点：1) 数据一致性：标准化建模减少了数据冗余，提高了数据一致性。

2) 灵活可扩展：标准化建模可以适应不同的查询需求，支持灵活的查询和分析。

缺点：1) 查询复杂：标准化建模需要进行多表关联和聚合操作，查询复杂度较高。

数据仓库建模方法每个行业有自己的模型，但是不同行业的数据模型，在数据建模的方法上，却都有着共通的基本特点。

什么是数据模型数据模型是抽象描述现实世界的一种工具和方法，是通过抽象的实体及实体之间联系的形式，来表示现实世界中事务的相互关系的一种映射。

在这里，数据模型表现的抽象的是实体和实体之间的关系，通过对实体和实体之间关系的定义和描述，来表达实际的业务中具体的业务关系。

数据仓库模型是数据模型中针对特定的数据仓库应用系统的一种特定的数据模型，一般的来说，我们数据仓库模型分为几下几个层次。

图 2. 数据仓库模型通过上面的图形，我们能够很容易的看出在整个数据仓库得建模过程中，我们需要经历一般四个过程： ?业务建模，生成业务模型，主要解决业务层面的分解和程序化。

?领域建模，生成领域模型，主要是对业务模型进行抽象处理，生成领域概念模型。

?逻辑建模，生成逻辑模型，主要是将领域模型的概念实体以及实体之间的关系进行数据库层次的逻辑化。

?物理建模，生成物理模型，主要解决，逻辑模型针对不同关系型数据库的物理化以及性能等一些具体的技术问题。

因此，在整个数据仓库的模型的设计和架构中，既涉及到业务知识，也涉及到了具体的技术，我们既需要了解丰富的行业经验，同时，也需要一定的信息技术来帮助我们实现我们的数据模型，最重要的是，我们还需要一个非常适用的方法论，来指导我们自己针对我们的业务进行抽象，处理，生成各个阶段的模型。

为什么需要数据模型在数据仓库的建设中，我们一再强调需要数据模型，那么数据模型究竟为什么这么重要呢？首先我们需要了解整个数据仓库的建设的发展史。

数据仓库的发展大致经历了这样的三个过程：?简单报表阶段：这个阶段，系统的主要目标是解决一些日常的工作中业务人员需要的报表，?以及生成一些简单的能够帮助领导进行决策所需要的汇总数据。

这个阶段的大部分表现形式为数据库和前端报表工具。

?数据集市阶段：这个阶段，主要是根据某个业务部门的需要，进行一定的数据的采集，整理，按照业务人员的需要，进行多维报表的展现，能够提供对特定业务指导的数据，并且能够提供特定的领导决策数据。

数据建模师谈建模方法及技巧笔者从98年进入数据库及数据仓库领域工作至今已经有近八年的时间，对数据建模工作接触的比较多，创新性不敢谈，本文只是将工作中的经验总结出来，供大家一同探讨和指正。

提起数据建模来，有一点是首先要强调的，数据建模师和DBA有着较大的不同，对数据建模师来说，对业务的深刻理解是第一位的，不同的建模方法和技巧是为业务需求来服务的。

而本文则暂时抛开业务不谈，主要关注于建模方法和技巧的经验总结。

从目前的数据库及数据仓库建模方法来说，主要分为四类。

第一类是大家最为熟悉的关系数据库的三范式建模，通常我们将三范式建模方法用于建立各种操作型数据库系统。

第二类是Inmon提倡的三范式数据仓库建模，它和操作型数据库系统的三范式建模在侧重点上有些不同。

Inmon的数据仓库建模方法分为三层，第一层是实体关系层，也即企业的业务数据模型层，在这一层上和企业的操作型数据库系统建模方法是相同的；第二层是数据项集层，在这一层的建模方法根据数据的产生频率及访问频率等因素与企业的操作型数据库系统的建模方法产生了不同；第三层物理层是第二层的具体实现。

第三类是Kimball提倡的数据仓库的维度建模，我们一般也称之为星型结构建模，有时也加入一些雪花模型在里面。

维度建模是一种面向用户需求的、容易理解的、访问效率高的建模方法，也是笔者比较喜欢的一种建模方式。

第四类是更为灵活的一种建模方式，通常用于后台的数据准备区，建模的方式不拘一格，以能满足需要为目的，建好的表不对用户提供接口，多为临时表。

下面简单谈谈第四类建模方法的一些的经验。

数据准备区有一个最大的特点，就是不会直接面对用户，所以对数据准备区中的表进行操作的人只有ETL工程师。

ETL工程师可以自己来决定表中数据的范围和数据的生命周期。

下面举两个例子：1）数据范围小的临时表当需要整合或清洗的数据量过大时，我们可以建立同样结构的临时表，在临时表中只保留我们需要处理的部分数据。

《数据仓库⼯具箱》——建模四步骤Kimball建模⽅法的精髓，就是简单、使⽤，建模这四步骤是它的核⼼部分。

⽤术语表达是：始终⼀致的四步设计维度模型，分别如下：⼀、选择业务过程业务过程是由组织完成的⼀系列微观活动，例如：完成下单、完成⽀付、发放代⾦券、上线产品等等。

充分理解它们，有助于辨别组织中的不同业务过程，它⼀般具有这些特性：⽤⾏为动词表⽰：它们通常表⽰业务过程的活动，⽐如下单、⽀付、退款等⼀般由某个操作系统⽀持：⽐如下单由交易系统⽀持、产品上架由产品中⼼⽀持等⽣成度量：度量⼀般由操作过程直接⽣成，⽐如⽤户⽀付⾦额，由⽤户⽀付过程直接产⽣。

分析⼈员⼀般⼯作事件分析度量结果。

⼀句话总结：⼀系列过程产⽣⼀系列事实表数据仓库⼈员不仅要详细了解业务过程，还要充分理解⽤户需求（特别是他们的KPI），因为⽤户⼀般很难回答：“你对哪些业务过程感兴趣”，⽽是使⽤BI分析来⾃业务过程的性能度量我们即需要理解上⾯的什么是业务过程，也需要理解如下的什么不是业务过程，这样才能取舍。

⽐如不同部门的功能划分就不是业务过程，我们应该将注意⼒放在业务过程⽽不是不同的部门，这样才能避免重复的获取数据。

⼆、声明粒度粒度是说明事实表的每⼀⾏表⽰什么。

⽐如：⽤户下单的内容放倒订单事实表的每⼀⾏中。

这⾥的关键是粒度的描述，不能讲维度列出来，⽽代替粒度声明。

这⼀步特别容易被忽略，粒度声明需要达成共识，否则极有可能到下⾯三四步之后返⼯重来三、确定维度如果粒度合适，维度很容易确定，因为维度是⽤来描述：“谁、何时何地、为何、如何”。

⽐如订单常⽤的维度是：⽇期、产品、供应商、订单状态、退款状态等四、确定事实⽤“业务的度量是什么”来思考事实。

属于不同粒度的事实要放在不同的事实表中。

有⼈可能疑惑粒度和事实的区别是啥，粒度说明了事实的每⼀⾏代表什么意思，⽽事实是⾥⾯包含哪些列，⽐如成交⾦额、退款⾦额、购买份数等等总结强烈抵制仅仅考虑数据来源做为建模的⽅案，⽐如订单类数据，是从交易系统获取的，那么就将这些数据放在⼀起。