关系型数据库设计之从E-R图绘制到数据库表设计

关系型数据库之父——埃德加·弗兰克·科德（Edgar Frank Codd）

---

前言

本文介绍数据库设计的过程，供各位小伙伴参考。

---

一、设计数据库的流程

1. 现实世界的业务场景转化为E-R模型
2. E-R模型转化为关系模型
3. 关系模型进一步规范化（遵循范式），得到数据库结构模型。

二、E-R图是什么

E-R图也称为实体-联系图，提供了表示实体类型，属性和联系的方法，用来描述现实世界的概念模型。简单来说，就是将现实中的业务场景的属性和它们之间的联系用图绘制出来。

三、E-R图的组成要素

1. 实体（entity），现实世界客观存在，并区别于其他对象的“事件”或“物体”，比如产品。

2. 属性（attribute），每个实体的特征，比如产品的名称、分类。

3. 主键（key），能唯一区分这个实体的属性，比如产品ID。

4. 联系（relationship），实体与实体之间的联系，有一对一，一对多，多对多三种，比如产品和销售员。

四、E-R图各组成要素绘制

1. 实体，矩形框。
2. 联系，菱形框。
3. 属性，椭圆框。
   
4. 关键字，即关键字，对应的属性名下划横线。
5. 映射基数，1:1，1:n，m:n。

五、关系模型概念

1. 关系：可以理解为二维表，每个关系都有一个关系名，即为表名。
2. 元组：可以理解为二维表的一行，即为数据库的一条记录。
3. 属性：可以理解为二维表的一列，即为字段。
4. 域：属性的取值范围，也就是数据库中某一列的取值限制。
5. 关键字：一组可以唯一标识元组的属性，即为主键。
6. 关系模式：指对关系的描述，即为初步表结构（生产中可能部分关系是包含关系，并不需要都形成二维表，比如部门主管也属于员工，一般只做员工表，不会将部门主管独立一张表）。

六、E-R图转换到关系模式

1. 当实体间的联系为一对一时，联系可以单独对应一个关系模式，也可以将一端的实体主键加入另一端的关系模式中。比如部门主管和部门两个实体，是一对一的关系，第一种方案：部门主管的关系模式可以加部门编号，部门的关系模式也可以加工号。第二种方案：将“属于”独立为关系模式，包含工号和部门编号。
   

2. 当实体间的联系为一对多时，联系可以单独对应一个关系模式，也可以将1端的实体主键加入n端的关系模式中。比如部门和员工两个实体，是一对多的关系，第一种方案：员工的关系模式加部门编号。第二种方案，将“属于”独立为关系模式，包含工号和部门编号。
   

3. 当实体间的联系为多对多时，联系必须单独对应一个关系模式（将联系形成中间表），以此来描述两个实体间的联系。比如销售员和产品两个实体，是多对多的关系，将“销售”独立为关系模式，包含工号，产品编号，销售量和销售额，以此来记录每个销售员的销售情况（实际生产中，销售这个关系模式可以是订单等场景）。
   

七、生产案例分享

1. 简易订单表E-R设计
   
2. E-R图转换到关系模式
   一个订单可能会有多个产品，一个产品也可能会在多个订单中存在。所以，订单和产品这两个实体是多对多的联系。必须有一个中间关系将他们联系起来，就是订单详情。
3. 具体数据库表设计
   订单表：包含订单编码，日期，单据状态等字段。
   订单详情表：包含订单编码，产品编码，下单数量，下单金额等字段。
   产品表：包含产品编码，产品名，产品分类等字段。

---

总结

1970年，埃德加·弗兰克·科德提出了数据库关系模型的概念，为数据库管理奠定了基础。
在开发生产中，设计好系统对应的关系型数据库非常重要，既要如上文所说设计好相关表的关联关系，也要关注到冗余和性能。这样的系统才有可靠的底座。