数据建模：对需求的理解与表达
两类模型：概念模型 和 数据模型
概念模型：表达信息世界的模型（信息世界是对现实世界的理解与抽象；如E-R模型，O-O模型等）
数据模型：表达计算机世界的模型（关系、网状、层次模型等）
概念模型---E-R模型
E-R（Entity-Relationship）模型的基本观点：世界是由一组称作实体的基本对象和这些对象之间的联系构成的。
E-R模型包含的一组基本概念：实体，属性，联系、关键字/码，可以刻画信息世界
实体：客观存在并且可以相互区分的事物，有类和个体（实例）的概念

数据库设计---概念模型（E-R图：对需求的理解与表达）

1.获取需求，并进行需求自我消化，进而描述出来，形成需求文档。目标是要理解业务过程，数据处理流程，数据处理的性能需求
2.抽取实体
能够用一个个、一件件、一串串等叠词形容的都可以作为实体，要覆盖需求涉及到的可独立管理的每一类事物，区分不同的实体并进行命名
3.用属性刻画实体
1）给出重要的属性：例如名字、类型等；
2）确定出复合属性和多值属性
复合属性：一个属性可由多个属性描述，例如家庭住址可以由省份和详细住址构成。这时需要将复合属性转化为单一属性（第1范式：每一列都是不可分割的基本数据项）；
多值属性：该属性对应的值有多个，多值属性一定要转化为单值属性（第一范式：同一列中不能有多个值）。
3）确定出可空值属性和非可空值属性
4.确定实体的关键字/码
关键字/码：实体中能够用其值唯一区分开每一实例的属性或属性组合
5.确定属性的约束规则
需要从需求中对属性的业务规则进行准确理解，例如成绩这个属性，成绩只能取”优秀“，”良好“，”中等“，“及格”，“不及格”等五个值，或者存储数据表的名字这个属性，系统中已有的数据表的长度要求不能超过255的长度等等。
5.分析设计实体之间的联系
1）分析联系及联系是否有属性
由需求描述出发，有时候可以借助已抽取出的实体进行两两之间或自身到自身联系（比如部门1下设子部门部门2和部门3）的分析，来确定联系以及联系是否有属性，注意联系也要进行命名
2）分析多值属性是否需要单独建模
如果可以简单由代码级别控制数据的完整性，可以不进行单独建模，是一种折衷的办法
3）确定联系的基数
联系的基数为，一个实体的实例通过一个联系能与另一个实体种相关联的实例的数目，基数表达了业务规则，联系有很多种类，其中二元联系包括：一对一、一对多和多对多。因为不同基数的联系对应的数据库设计不同。
6.检查是否覆盖了需求
对照需求描述进行一条条检查
7.绘制E-R图
1）绘制的图要符合规范（Chen方法或者Crow's Foot方法，或者工程化方法IDEF1X（IDEF1X是将E-R模型扩充语义含义而形成的，或者说，是E-R图的细化））
2）绘图工具，可以用powerdesigner（Crow's Foot方法）

数据库设计---逻辑模型

逻辑模型包含：关系模型、网状模型，层次模型，面向对象模型
这里描述关系模型的过程
将E-R图转换成逻辑模式，遵循关系范式的设计原则
基本转换规则
1.E-R图的实体转换为实体
2.E-R图的属性转换为实体的属性
3.E-R的关键字/码转换为实体的关键字/码
4.复合属性：要么将每个分量属性作为实体的属性；要么将复合属性本身作为所在实体的属性
5.多值属性：将其与所在实体的关键字一起组成一个新的关系（上面也提到多值属性是否需要单独成关系需要折衷考虑一下，但是这是一种基本的做法）
6.联系的转换
一对一：不定义新的关系（联系的其中一方全部参与）；将联系定义为一个新的关系（联系的双方均部分参与）
一对多：将一方的实体关键字作为多方实体的属性
多对多：将联系定义为一个关系，属性为双方实体的关键字

数据库设计---物理模型

物理模型离不开具体的DBMS系统，所以要进行DBMS选型，设计对应的一些完整性约束，确定出数据库的高效访问方式（例如创建索引），可能还要进行安全性控制（例如用户视图，访问控制规则等）等具体内容

上述从概念模型->逻辑模型->物理模型的设计过程，可以借助powerdesigner进行绘图，并且这个工具也提供了模型之间的直接转换，只需要按照相应的模型绘制规则进行绘制，就可以进行后面的转换。上述过程是我之前设计过几个数据库所遵循的一个流程，严格性不敢保证，因为经验也没有多少，但足够我有一个流程来理顺整个数据库设计的过程，并最终形成数据库表的设计文档。总的来说，数据库概念模型的设计还是有些复杂的，它集中体现了对于需求的分析、理解、抽象和表达，每一个步骤都最好总结出相应的文档，具体的可以参考哈尔滨工业大学战德臣在慕课上面的数据库课程，里面有一些项目示例的设计过程。
链接：https://www.icourse163.org/course/HIT-1001554030?tid=1002211002