数据库基础：数据建模与数据库设计

数据建模

在需求分析过程中，有一些重要的工作给系统进行建模，它为后续的设计和实现工作提供了支持，数据建模主要是要抽象出系统中所涉及到的实体，以及它们之间的关系。此过程一般需要经过三个阶段：
概念建模
逻辑建模
物理建模

数据建模三阶段

概念建模

此阶段主要进行的步骤有：客户交流，理解需求，形成实体。在业务复杂的时候，我们通常不能很快理解这个业务流程中的每个步骤，并且可能在客户的很多业务中，会有一些相同的步骤，这些都是需要我们反复和客户进行沟通后，才有可能有一个比较全面的掌握。所以，这一般是一个迭代的过程，需要反复多次的和客户沟通、理解和确认。

逻辑建模

此阶段主要是对概念建模阶段的实体进行细化、优化、测试等，最后形成具体的E-R图（实体关系图），这张关系图中详细记录了实体信息，同时展示了实体与实体之间的关系。

物理建模

此阶段中，将在逻辑建模阶段创建的实体关系图，**根据选择使用的数据库，转为相应的 SQL代码，**以便在在数据库中，创建相应数据库对象。由于之后系统中的功能，主要就是围绕数据库进行实现的，所以此时还需要在数据库中，模拟测试数据并插入到表中，然后对前期需求分析中的功能，进行测试，以便能及时发现问题并处理。最后，还可以针对系统的实际业务特点，考虑是否需要对数据库中的表进行拆分、读写分离等

E-R图（实体关系图）

用来描述现实世界的概念模型，数据建模完成后，会形成一套具体的E-R图。
构成E-R图的三大要素有：
实体：用来表示据有相同特征和性质的事物，实体由实体名和实体属性组成。
属性：实体所具有的某一特性就是它的属性，一个实体可以拥有多个属性。
关系：实体彼此之间的连接方式。

实体关系的类型
一对一关系（例如丈夫和妻子）
一对多关系（例如班级和学生）
多对多关系（例如老师和学生）

例如：以顾客和订单（一对多关系）为例，来进行说明
一个顾客对应多个订单。
一个订单对应一个顾客。
一个顾客可以（may be）没有订单。
一个订单一定（must be）对应一个顾客。

由此构成的er图如上，说明：

• #，表示唯一
• *，表示非空
• o，表示可以为空
• 虚线，表示may be
• 实现，表示must be
• 表示关系的连线，伞状的一端表示多的一方，另一端表示一的一方
• 连线上面可以加上文字说明

在使用不同的绘图工具时，可能画出的图形形状是由区别的，但是表达的含义都是一样的，例如：

1. 矩形或圆角矩形表示实体
2. 菱形描述关系
3. 圆形表示属性
4. 连线表示关系

绘图工具：
window visio（安装）
power designer（安装）
navicat（安装）
diagrams.net（在线）
process on（在线）（使用的是矩形、圆形、菱形等）

数据库设计

E-R图转换为数据库中的表

1. 实体名转换为表的名字
2. 实体的属性转换为表中的列
3. 具有唯一特点的属性设置为表中的主键
4. 根据实体之间的关系，设置表中某列为外键列（主外键关联）

主键

主要作用就是用来唯一标识一行数据的
特点：

1. 能做主键的列必须满足非空唯一的特点
2. 只要满足非空唯一的任何列都可以做主键
3. 可以让表中一个有意义的列做主键（如，学号）
4. 可以找一个没有意义的列做主键（大部分情况下都是没有意义的列做主键，如ID列）
5. 可以让多个列联合在一起做表中的主键（联合主键：要求几个列的值联合在一起是非空惟一的）

外键

主要作用就是用来表示这个类中的数据，是引用自另一种表的字段值
特点：

1. 表中的某一个列声明为外键列，一般这个外键列都会引用另外一张表的主键列的值。（只要是具体唯一约束的列，就可以被另一种表的外键列所引用）
2. 一张表的主键列中出现过的值，都可以在另一张表的外键列中使用。
3. 外键列值也可以为空的，前提是这个外键列没有做主键或联合主键。
4. 如果把B表中的联合主键，引用到A表中做外键，那么这个外键就是一个联合外键。

范式

设计关系数据库时，要遵从规范要求，才能设计出更加合理的表结构，这些不同的规范要求被称为不同的范式，各种范式依次递进，越高的范式数据库冗余越小。
目前关系数据库有六种范式：
第一范式(1NF)
第二范式(2NF)
第三范式(3NF)
巴斯-科德范式(BCNF)
第四范式(4NF)
第五范式(5NF，又称完美范式)

满足最低要求的范式是第一范式(1NF)。在第一范式的基础上，进一步满足更多规范要求的称为第二范式(2NF)，其余范式以次类推。一般说来，数据库只需满足第三范式(3NF)就行了

第一范式

一个表中，每个列里面的值是不能再分割的。（属性不可再分）

第二范式

第二范式是在满足第一范式的基础上，表中的非主键列都必须依赖于主键列。

第三范式

第三范式是在满足第二范式的基础上，表中的非主键列都必须直接依赖于主键列，而不能间接的依赖，也就是不能出现依赖传递。

？？什么是依赖传递？？
例如：订单表中有订单编号，并且该列是主键。

顾客编号依赖于订单编号，顾客姓名依赖于顾客编号，从而顾客姓名间接的依赖于订单编号，那么这里产生了依赖传递。

在常见的实体关系中，对应的数据库中表的设计规则如下：

1. 一对一关系
   假设是A表和B表，这种情况下，外键列设置在任意一张表中，都是可以的。
2. 一对多关系
   假设是A表和B表，这种情况下，外键列要设置在多的一方。
3. 多对多关系
   假设是A表和B表，这种情况下，需要设计第三张表（桥表），桥表中设置俩个外键，分别引用A表的主键和B表的主键。