大数据时代，维度建模已成为各大厂的主流方式。维度建模从分析决策的需求出发构建模型，为分析需求服务。重点关注用户如何快速的完成数据分析，可以直观的反应业务模型中的业务问题，需要大量的数据预处理、数据冗余，有较好的大规模复杂查询的响应性能。
要讨论数据建模，我们首先要搞清楚“数据建模”是什么，以及数据建模的目标是什么。在大数据时代，数据不仅仅包括数据表，因此，我们用一个内涵更加广泛的词“数据集合”来替代“一系列的表”这个说法。那么数据建模是如何去满足要求的呢？是通过抽象出良好的结构，来实现的。
数据建模是一个用于定义和分析在组织的信息系统范围内支持商业流程所需的数据要求的过程。简单来说，数据建模是基于对业务数据的理解和数据分析的需要，将各类数据进行整合和关联，使得数据可以最终以可视化的方式呈现，让使用者能够快速地、高效地获取到数据中有价值的信息，从而做出准确有效的决策。
之所以数据建模会变得复杂且难度大，是因为在建模过程中会引入数学公式或模型，用于确定数据实体之间的关联关系。不同的业务逻辑和商业需求需要选择不同的数学公式或模型，而且，一个好的数据模型需要通过多次的测试和优化迭代来完成，这就使得数据建模的难度变得很高。但是，数据分析中的建模并没有想象中的那么高深莫测，人人都可以做出适合自己的模型。
数据建模是一个“通过良好的结构设计，建设满足要求的数据集合”的过程。在建模过程中，需分析数据和数据之间的关系，对所要模型化的内容具有清晰的认 识。数据建模者要和各方涉众进行交流、沟通，以便构建的数 据模型具有较高的精确性，在所有用户中达成共识。
1.保障数据质量：质量是数据的生命线，数据的质量决定了数据的价值。具体而言数据质量，可以概括为4类，正确性、完整性、时效性，以及一致性。
2.提升交付效率：稳定性、适应性、简洁性和易用性，是影响数据研发效率的4个主要因素。
3. 降低整体成本：在确定的品质效率下，要尽可能的降低成本，把握好存储成本与计算成本之间的平衡。
简而言之，数据建模的目标是建立对于业务经营而言“好用、高效、且经济”的数据资产。当然，与此同时，我们还要守好底线，保证数据合规、防止数据泄露。
一、数据建模类型和流程
1.1 数据建模常见类型
概念模型的主要目标是建立实体及其属性和实体之间的关系，不会涉及数据库结构的。例如，客户和产品是两个实体，客户的编号和名称是它的属性，产品的名称和价格是产品的属性，销售是客户和产品之间的关系。
逻辑模型将更多的信息添加到概念模型中，定义了元素的结构并设置了元素之间的关系。逻辑数据模型具有如下特征：描述单个项目的数据需求，但可以根据项目范围与其他逻辑数据模型集成；独立于数据库的设计和开发；数据属性将具有精确精度和长度的数据类型；通常将模型的标准化过程应用到第三范式。
物理数据模型描述数据模型的数据库实现，提供了数据库的抽象，包含了丰富的信息。这种类型的数据模型还有助于可视化数据库结构。它有助于为数据库列建模键，约束，索引，触发器和其他RDBMS功能。
1.2 数仓模型设计原则
数据仓库要分层建设，这个几乎是毫无争议的。但具体分为哪几层，每一层的称呼是什么，各家的见解略有差异。不过没关系，最重要的是抓住本质：高内聚、低耦合、高复用、控依赖，以下详细阐述。
1. 高内聚低耦合：逻辑和物理模型的记录和字段组成方式，应该遵循最基本的软件设计方法论中的高内聚低耦合的原则。
- 从业务特征而言：将业务近似或相关的数据，或是粒度相同的数据设计为一个逻辑或物理模型。
- 从访问特征而言：将高概率同时访问的数据放一起，将低概率同时访问的数据分开存储。
2. MECE原则：数据域划分统一标准，尽可能遵照MECE原则，不重不漏。数据域之间的边界划分的越清晰，越能够延缓数据模型的腐化。
3. 公共处理逻辑，下沉且保持单一：所谓下沉是指，越是底层公用的处理逻辑，越应该在数据调度任务依赖的上游进行封装和实现，不可让公共的处理逻辑暴露给应用层实现。所谓保持单一是指，不可用让公共逻辑
在多处存在，因为多处存在的逻辑，随着时间的推演，很难保持一致性。
4. 核心模型与扩展模型分离：建立核心模型与扩展模型体系，核心模型包括的字段支持常用核心的业务，扩展模型包括的字段支持个性化，或是少量应用的需要。不可让扩展字段过度侵入核心模型，以至于破坏核心模型的架构简洁性和可维护性。
5. 合理的层次依赖：各层数据空间之间，避免“反向引用”；例如DWD层应严格遵守层次依赖，理论上只可以引用ODS、DIM和部分的DWD层数据，不可引用处于下游层次的ADS层数据。ADS应用层各数据集市之间，也应该尽量避免频繁引用，如有高频共用的逻辑，应该向CMD中间层（含DWD、DWS、DIM）沉淀。
6. 清晰可理解的数据表命名，遵照一致性的字段命名：表命名需要遵照OneModel数据表命名规范，表名需要对于主要消费者而言，是清晰、易于理解和易于使用的。对于核心的指标（事实）、维度（对象），相同含义的字段，在不同表中的字段名必须保持一致，且须使用《模型命名规范》中的名称。
1.3 数据仓库核心架构
数据仓库是一个为数据分析而设计的企业级数据管理系统。数据仓库可集中、整合多个信息源的大量数据，借助数据仓库的分析能力，企业可从数据中获得宝贵的信息进而改进决策。同时，随着时间的推移，数据仓库中积累的大量历史数据对于数据科学家和业务分析师也是十分宝贵的。
1.4 数据仓库建模的意义
如果把数据看作图书馆里的书，我们希望看到它们在书架上分门别类地放置；如果把数据看作城市的建筑，我们希望城市规划布局合理；如果把数据看作电脑文件和文件夹，我们希望按照自己的习惯有很好的文件夹组织方式，而不是糟糕混乱的桌面，经常为找一个文件而不知所措。
数据模型就是数据组织和存储方法，它强调从业务、数据存取和使用角度合理存储数据。只有将数据有序的组织和存储起来之后，数据才能得到高性能、低成本、高效率、高质量的使用。
高性能：良好的数据模型能够帮助我们快速查询所需要的数据
低成本：良好的数据模型能减少重复计算，实现计算结果的复用，减低计算成本
高效率：良好的数据模型能极大的改善用户使用数据的体验，提高使用数据的效率
高质量：良好的数据模型能改善数据统计口径的混乱，减少计算错误的可能性
二、四种常见模型
2.1 维度模型
维度建模按数据组织类型划分可分为星型模型、雪花模型、星座模型。
维度建模四个步骤：
选择业务处理过程 > 定义粒度 > 选择维度 > 确定事实
2.1.1 星型模型
星型模型主要是维表和事实表，以事实表为中心，所有维度直接关联在事实表上，呈星型分布。
2.1.2 雪花模型
雪花模型，在星型模型的基础上，维度表上又关联了其他维度表。这种模型维护成本高，性能方面也较差，所以一般不建议使用。尤其是基于hadoop体系构建数仓，减少join就是减少shuffle，性能差距会很大。
星型模型可以理解为，一个事实表关联多个维度表，雪花模型可以理解为一个事实表关联多个维度表，维度表再关联维度表。
2.1.3 星座模型
星座模型，是对星型模型的扩展延伸，多张事实表共享维度表。
星座模型是很多数据仓库的常态，因为很多数据仓库都是多个事实表的。所以星座模型只反映是否有多个事实表，他们之间是否共享一些维度表。
2.2 范式模型
即实体关系（ER）模型，数据仓库之父Immon提出的，从全企业的高度设计一个3NF模型，用实体加关系描述的数据模型描述企业业务架构，在范式理论上符合3NF。此建模方法，对建模人员的能力要求非常高。
特点：设计思路自上而下，适合上游基础数据存储，同一份数据只存储一份，没有数据冗余，方便解耦，易维护，缺点是开发周期一般比较长，维护成本高。
2.3 Data Vault模型
DataVault由Hub（关键核心业务实体）、Link（关系）、Satellite（实体属性） 三部分组成 ，是Dan Linstedt发起创建的一种模型方法论，它是在ER关系模型上的衍生，同时设计的出发点也是为了实现数据的整合，并非为数据决策分析直接使用。
2.4 Anchor模型
高度可扩展的模型，所有的扩展只是添加而不是修改，因此它将模型规范到6NF，基本变成了K-V结构模型。企业很少使用。
三、数据模型的流程
3.1 确定实体关系
在数据库中，管理信息系统为其中的基本框架，设计数据库概念模型是构建数据库的关键所在。其中构建实体关系是非常关键的一个环节。在真实的世界当中，实体是能够互相区分的，能够被人类所了解与掌握的概念、事与物等。集合概念是实体的基本特征，用实体实例来阐述它的各个个体。有若干个特征存在于实体当中，因此，可以称它们为属性。对于实体的属性组合属性 都能够唯一标识出来，也就是 PK Primary Key（主键），同时也有外键存在于实体当中，在现阶段的实体中，它也是属性的一种，在其他的实体中则为主键。
可以通过三种方式构建实体之间的关系：构建一对多的关系：指的是将实体B的n个实例通过实体A的一个实例构建出来。构建多对多的关系：对于实体B的n个实例，能够利用实体A的一个实例构建起来。构建一对一的关系：实体B的一个实例能够通过实体A的一个实例构建起来。
3.2 将信息用统主题构建起来
这为相关行业进行信息系统数据建模的一个关键流程，利用分析信息系统数据建模的相关需求，将行业内的工作主题确定出来。在相关决策的前提下，将工作人员所要倾向的主体构建起来。此外，还应该同行业内的联机系统进行连接，然后粗略的分析这些操作型数据，进而将良好的数据基础为构 建综合性的数据分析系统和信息系统构建起来。
3.3 逻辑数据建模
分析系统的数据逻辑模型和数据综合信息系统是通过数据库将数据模型构建起来的，因此，怎样可以令数据仓库更加有效的对用户的相关需求给予满足，是构建数据逻辑模型的关键所在。用一定数量的维数据将星型模式设计出来，这样能 将良好的查询功能为数据仓库提供出来。通过数据模式的外观得出了星型模式这个概念，从属的 表格通过星状包围起了这个居于中间的大表格。而且，指标实体的度量属性和指标实体一同构成了这个居于中央的大表格。
这与概念模型过程中所产生的度量属性和事实实体是相 对应的。维度实体被包含于从属的表格中，而且，它有效的对 应着指标实体当中的较多个度量属性。同时，还有另一类实体也存在于从属表格中，进而来有效的限制用户的数据查询结果，将较少的行为查询过程中的指标实体返回来，将产讯范围进而缩小。而将实体的详细的类别出来，是为了对用户查询过 程详细信息的需求给予充分的满足，维度实体和指标实体的 联系一般都是通过各个维度实体当中最低一层的精细类别展现出来的，也就是说，居中表格的主键是从属表格外键的主要来源。
3.4 选择有效的建模工具
例如选择ROSE，可以切实的完成相关的数据建模：
①利用分析相关的需求，将项目里面所关联的数据实体寻找出来，将 E-R 图在关系数据库中构建起来；
② 将关系与实体在相关的图形中完成映射处理，进而将类图在对象模型中构建起来，并且用类的方法取缔数据上的操作。可是，将实体的对象模型如果能够在需求分析中直接构建起来，这样上一步就能够被有效的省略掉；
③用 rose 转化功能对构 成的对象模型进行转化，能够用数据模型取代象模型；
④将关系数据库用数据模型自动转化出来，并且，按照有关的转换原实现生成过程；
⑤导出对象数据，将代码的框架构造成型，然后进一步的强化和完善代码框中的相关内容；
⑥将相关的测试用例编写出来，与数据库中的一些对象及对应类结合起来统一的进行测试；
⑦随着不断深入的项目建设，也会相应的完善和增加一些数据对象，因此，循环的迭代过程就需要被开展 =起来，进行相应的完善和细化。经过以上流程，能够找出对象层里面所涵盖的对象，并且迅速的进行编码测试和建模。
此工作环节的目的是将相应封装之后的实体类获取出来。接下来的工作是在业务需求的基础上，合理的组装实体类，进而确保能够有效的调用界面层。
四、数据模型的评价标准
数据模型建设的怎么样，极度依赖规范设计，如果代码风格是“千人千面”，那么恐怕半年下来，业务系统就没法看了。没有什么比“数据系统”更看重“法制”了，规范体系不仅能保障数据建设的一致性，也能够应对业务交接的情况，更能够为自动化奠定基础。
业务过程清晰：ODS就是原始信息，不修改；DWD面向基础业务过程；DIM描述维度信息；DWS针对最小场景做指标计算；ADS也要分层，面向跨域的建设，和面向应用的建设；
指标可理解：按照一定业务事务过程进行业务划分，明细层粒度明确、历史数据可获取，汇总层维度和指标同名同义，能客观反映业务不同角度下的量化程度；
核心模型相对稳定：如果业务过程运行的比较久，过程相对固定，就要尽快下沉到公共层，形成可复用的核心模型；
高内聚低耦合：各主题内数据模型要业务高内聚，避免在一个模型耦合其他业务的指标，造成该模型主题不清晰和性价比低。
总结
在传统企业数仓中，业务相对稳定，以范式建模为主。如电信、金融行业等。在互联网公司，业务变化快，需求来来回回的改，计算和存储也不是问题，我们更关心快速便捷的响应业务需求，所以以维度建模为主流。
