浅谈数据建模

一.数据建模简介

数据模型，表现为一组用符号、文本组成的集合，本质上是一种对现实世界的抽象表达，所谓抽象，可以简单的理解为屏蔽了不重要的细节，抽取特性的东西。比如：google earth(地球仪)就是地球的模型，地球仪失去了很多细节，但任然明确的给人一个地球的印象；而不同的抽象程度、不同层次的数据模型，呈现出不同的信息景观，就像放大、缩小google earth呈现出来的信息一样；

以下2个例子是生活中，应用了模型的场景，其中，地图是对地理信息的抽象，户型图，是对房屋空间布局的抽象。

二.数据建模的目的OR价值

1.便于理解：面对错综复杂的业务信息，先得到一个描述公司业务模式的全局的视野，然后再根据不同的层次模型循序渐进，逐步深入；从而避免一开始就陷入细节，只见树木不见森林。

2.便于交流：通过统一观念，可以使来自不同部门、职责，以具有不同技术背景和业务经验的人就业务问题进行讨论并最终指导行动。数据模型作为一种信息导航工具，可以达到有效理解、记录并协调不同观点的目的；而站在数据仓库建设角度，只有观念统一了，数据才能统一；在实际项目中，概念不统一的现象往往来自于不同的业务部门，站在各自的业务视角，就同一个物理实体，定义出了不同的概念，概念之间也没有映射关系，最终导致沟通交流、数据整合的时候，造成了一定的困难，甚至要起一个专项来解决业务系统之间的交互。

三.如何进行数据建模

前面说过，数据模型是有层次的，不同层级的模型，呈现不同细节程度的视图，且每一层模型都作为下一层的指导；而每一个层级的数据建模，则是一系列的过程，通过不断的信息收集、摘要、分类、规则化的步骤将信息提炼成一个模型：

4种通用方法：

收集：大部分的项目，都是由需求和问题驱动的，信息收集就是和需求方、相关业务关键决策者、一线开发进行信息沟通和确认，并将信息记录下来的过程；过程中，要尽可能的整合不同业务方、不同的业务视角的意见；当遇到无人维护的老业务系统的时候，还需要进行数据库逆向工程，来还原业务流程；
摘要：将收集到的信息提取出关键内容，浓缩信息的精华，保留信息所代表的本质的概念；
分类：将摘要信息按照性质分组，并将分组的信息概念化、抽象化；
规范：建立规则和约束，就像现实世界中的对象不可能独立存在，信息之间也有从属和关联等关系。

数据仓库领域，有一套经典、通用的建模方法论：

其中，每个建模流程的目的和产出物概括如下：

1.领域建模
需要根据要解决的问题，了解背后的业务流程，以及业务流程所代表的业务目标，然后提取出关键的业务概念(划分主题)，以及概念间相互作用(主题关系)，最终根据要解的问题，明确业务的边界(划分主题域)；

具体可以通过以下5个步骤：

a.明确模型要解决的关键问题

要解决的核心问题(包括未来可能出现的问题)，是模型建设的切入点，是作为去了解上层业务流程的引子，也是模型的最终价值的直观体现。比如，作者做某账单分析和稽核项目就要去了解交易涉及到的所有的业务概念、业务场景，以及计量、计费、帐处、结算等业务概念；

b.概念的识别和定义

在数据库领域中，概念其实就是一堆业务实体之间的共性和本质(参考Java语言中的抽象类:abstract)，而实体，是保持业务运转的重要组成要素；实体从何而来呢？可以从上一步的业务概念、场景中提取； 一般来说，有6个种类的实体：谁、什么、何时、何地、为何、如何：

通常，大部分的主题都很容易识别，业界也有一些通用的主题模型可以参考，但是，需要贴合本公司的商业模式和特色，比如，对于下单、支付等交易过程，其它平台型电商的数仓中可能会定义为"事件域"，或"行为域"，目的是为了分析用户行为，做二次营销。

c.创建关系

关系即业务规则，创建关系的过程，就是明确实体间相互关系，清晰的掌握所有的规则。

d.形式化

即，将模型图形化，图形不需要太复杂，只要能说明问题；此阶段需要将上述步骤中的关键业务流程、概念以流程图、概念ERD的形式产出。

以下是一个交易的模型图：

说明：一个销售经理联系多个客户，一个客户可以就一个或多个产品发起一笔或多笔订单、账单、退订订单，订单、账单、退订订单都属于交易的子类型，每一笔订单，包含多个子订单，一个产品，属于一个或多个子订单。

e.校验并确认，业务场景验证

需要得出的模型，和业务方确认，并和需求方进行业务场景的覆盖性验证，并可能需要重新回到第二步，该过程是一个循环迭代的过程。

2.逻辑建模
逻辑建模是在使用概念数据模型比较宽泛的业务概念和数据域之上，以业务需求为基础(忽略软件环境、硬件环境等有关模型实现的复杂性)，所形成的下一级别的业务解决方案，作为连接概念和逻辑模型的桥梁；具体来说，逻辑建模需要交付出业务实体所有的属性和业务规则；比如：在以上交易域概念建模中，我们定义了一个用户可以发起多笔订单，那么逻辑数据模型则需要关注诸如用户昵称、订单号、订购产品、金额等有关用户、订单的细节信息。

说到逻辑建模，不得不提两种主要的建模思想：范式(3NF)建模和维度建模，简单的介绍一下：

a.范式建模，是自上而下的得到一个完整的企业业务信息视图，然后通过透出数据集市来解决上层应用；所谓范式，就是规范化，确保表中的每个属性都是单值的(1NF)，并且是完整的(2NF)、唯一的依赖于主键(3NF)：

1NF：保证属性的原子性；是所有数据库的最基本要求；

2NF：满足1NF，且表中的字段必须完全依赖于全部主键而非部分主键(针对联合主键的情况)；

3NF：满足2NF，且确保每列都和主键列直接相关,而不是间接相关，即：非主键外的所有字段不能有传递依赖。

b.维度模型，从需求出发，识别出一系列的业务过程中，明确度量和环境，将度量设计为事实表，将环境设计为维度表，最终，将多个事实表和维表构建成星型模型；维度建模的核心技术就是对于维度表(渐变维度、巨型维度)的设计,在此就不展开说了。

面对业务的快速发展，需要短平快的解决业务问题的时候，维度建模是最佳选择。

3.物理建模

物理数据建模使用由逻辑模型定义的业务解决方案，构建下一层的技术解决方案； 该层需要考虑计算复杂度型、性能、数据安全等技术问题；比如：采用数据分层(详细层、轻度汇总、应用层)解决计算复杂性问题，采用分区、视图、索引来解决性能问题。

四.数据模型的评估

从需求的满足程度看：

模型的完整性如何？业务场景的覆盖度如何？
需求完整性是说每个需求(包括将来可以预见到的需求)都应该出现在模型中；同时意味着数据模型仅仅包含需求的内容，而没有其他不相干的、多余的东西。

模型是否准确的表达了业务需求？
准确性是说从模型是否能够推导出业务需求所期望的结果。

从模型本身的质量来看：

模型的通用性如何？
通用型意味着模型能适应未来的变化，做到可扩展；对于概念模型，通用型意味着能cover所有的业务概念和实体，比如是否“用户”替换为更通用的“当事人”？对于物理模型，意味着数据是否可复用，是否高内聚，低耦合。

模型的标准化命名如何？
模型是否采用了一致的术语，命名是否符合公司的标准规范等。

模型的可阅读性如何？
模型需要以适当的形式表现出来；前文说过，建模，特别是高层建模，没有统一的形式化语言，但是要简练，能说明问题。

五.总结

数据模型是一个持续的过程，需要不断进化，不断完善；数据建模就和工程端的系统架构一样，只有指导思想，没有标准答案，要符合所在组织的业务特点，不然就会，手术很成功，病人确挂了。