笔记：数据建模基本流程，概念模型，逻辑模型和物理模型

注：本文的数据建模基本流程适用于OLTP系统数据建模，同样也涵盖了DW的数据建模

数据建模基本流程：概念模型->逻辑模型->物理模型

概念模型：确定系统的核心以及划清系统范围和边界

该阶段需完成：

1.该系统的商业目的是什么，要解决何种业务场景

2.该业务场景中，有哪些人或组织参与，角色分别是什么

3.该业务场景中，有哪些物件参与，

4.此外需要具备相关行业经验：如核心业务流程，组织架构，行业术语

5.5w1h：who， what，when，where，why,  how

概念模型tips：

1.注重全局的理解而非细节

2.在概念模型阶段，就需要对整体架构做思考

3.概念模型阶段通常是自上而下的模式，这里需要读大量的文档做课前工作，并且通过大量的会议进行反复沟通、澄清需求确认需求。

4.在此阶段，应粗略地估算出整个项目需要的时间以及项目计划草案

5.出品的概念模型可以帮助划定系统边界，也就是说什么地方做什么地方不做，另外也能够帮助避免一些方向性的错误

6.当然业务和数据都精通的专家更好了，但对比数据专家，这个阶段更需要业务专家来配合

7.可以说概念模型是一个沟通的基础，假设你和客户讨论，讨论的内容是什么？依据什么来讨论？这个就是概念模型存在的意义，同时它也是逻辑模型非常重要的输入，逻辑模型其实就是概念模型逐步求精的结果。

8.要用与客户一致的商业语言，这个目的主要是避免双方沟通产生歧义

9.通常用实体关系图表示，但不需要添加实体的属性

逻辑模型：梳理业务规则以及对概念模型的求精

该阶段需完成：

1.分多少个主题？每个主题包含的实体

2.每个实体的属性都有什么？

3.各个实体之间的关系是什么？

4.各个实体间是否有关系约束？

逻辑模型tips：

1.当你结束了逻辑建模，如果项目是以数据为核心应用的话，你就能够更精确推算出整个项目需要的时间，同时你也能估算出更精确的费用。

2.如果你的实体数量超过100个，建议你使用术语表进行统一的规划定义

3.建议采用3NF进行规范化建模

4.一定要先规范化，再逆规范化

5.不可缺少约束的定义，比如主键，比如外键，比如特殊属性的范围定义等。

6.强烈建议使用CASE工具做逻辑建模

7.从系统工程管理的角度来讲，你需要一个和你同等级或者略高等级的同事（或小组）帮助定期评审你的模型，以确保模型的质量。

8.对于逻辑模型而言，需要对各个实体，重要的属性做结构化、详尽、准确的描述

9.需要和概念模型保持一致，如果发现有些地方不一致，需要确认是逻辑模型出问题了还是概念模型出问题了，再统一修正。

10.要非常非常注意细节，很多时候基础模型的一个小小的纰漏都会带来相关程序大量的修改

11.和概念模型简单明了的一页纸不同，逻辑模型应该是像一本书一样，它需要被用来生成未来的数据字典

12.和概念模型只有实体无需属性不同，所有实体属性都需要添加进去，不应有遗漏

13.实体之间的关系，是1:N, 0:N, 要清晰的描述

14.如果实体数量足够多，需要使用术语表

15.要严格遵循命名规则 

16.对各个实体均需要有清晰完整的描述 

17.对于关键属性都需要有清晰的描述 

物理模型：从性能，访问，开发等多方面考虑，做系统的实现

该阶段需完成：

1.类型与长度的定义

2.字段的其他详细定义：非空，默认值

3.却准详细的定义：枚举类型字段，各枚举值具体含义

4.约束的定义：主键，外键

物理模型tips：

1.注意开发，测试，生产不同版本的模型管理

2.注意性能

3.估算数据规模

4.考虑数据归档

5.同分考虑未来使用数据库的优点与缺点

什么样的模型算是高质量数据模型呢？

1.对真实世界的抽象和表达要正确并且完整；

2.需要使用标准化的建模语言，使数据模型能够清晰的表达设计的思想，让人容易理解并不产生歧义

3.数据模型的框架稳定并且灵活，能够一定程度上容纳未来的变化

4.根据需求的实际情况，不要随意的逆规范化，要尽可能的减少数据冗余

5.需要充分考虑潜在的性能问题，尤其要根据数据库产品的特点，避免使用数据库产品的短处。

6.要不仅仅站在当前项目的视角去构筑模型，需要从企业的全局视角出发，比如方便其他系统访问，可以很方便的外部数据接口，命名规则术语定义和企业标准保持一致，等等。