数据库设计范式和ER模型

1.什么是范式

    简言之就是，数据库设计对数据的存储性能，还有开发人员对数据的操作都有莫大的关系。所以建立科学的，规范的的数据库是需要满足一些规范的来优化数据数据存储方式。在关系型数据库中这些规范就可以称为范式。

 

2.关系模式范式

2.1 范式理论概述

    关系型数据库设计时，遵照一定的规范要求，目的在于降低数据的冗余性和数据的一致 性，目前业界范式有:第一范式(1NF)、第二范式(2NF)、第三范式(3NF)、巴斯-科德范式 (BCNF)、第四范式(4NF)、第五范式(5NF)。

    范式的标准定义是:符合某一种级别的关系模式的集合，表示一个关系内部各属性之间的联系的合理化程度。通俗地讲，范式可以理解为一张数据表的表结构所符合的某种设计标准的级别。

    使用范式的根本目的是:减少数据冗余，尽量让每个数据只出现一次，获取数据时通 过 join 拼接出最后的数据。

 

2.2 范式基本概念

2.2.1 函数依赖

    若在一张表中，在属性(或属性组)X 的值确定的情况下，必定能确定属性 Y 的值，那么就可以说 Y 函数依赖于 X，写作 X → Y。

    也就是说，在数据表中，如果符合函数依赖，那么不存在任意两条记录，它们在 X 属 性(或属性组)上的值相同，而在 Y 属性上的值不同。这也就是“函数依赖”名字的由来，类似于函数关系 y = f(x)，在 x 的值确定的情况下，y 的值一定是确定的。

    例如，对于表 3 中的数据，找不到任何一条记录，它们的学号相同而对应的姓名不同。 所以我们可以说姓名函数依赖于学号，写作 学号 → 姓名。但是反过来，因为可能出现同 名的学生，所以有可能不同的两条学生记录，它们在姓名上的值相同，但对应的学号不同， 所以我们不能说学号函数依赖于姓名。

    表中其他的函数依赖关系还有如: 系名 → 系主任

    学号 → 系主任

    (学号，课名) → 分数 

    以下函数依赖关系则不成立: 学号 → 课名

    学号 → 分数

    课名 → 系主任 (学号，课名) → 姓名

2.2.2 完全函数依赖

    在一张表中，若 X → Y，且对于 X 的任何一个真子集(假如属性组 X 包含超过一个属性的话)，X' → Y 不成立，那么我们称 Y 对于 X 完全函数依赖，记做:

    例如:

    学号 F→ 姓名

    (学号，课名) F→ 分数 (注:因为同一个的学号对应的分数不确定，同一个课名 对应的分数也不确定)

2.2.3 部分函数依赖

    假如 Y 函数依赖于 X，但同时 Y 并不完全函数依赖于 X，那么我们就称 Y 部分函数依赖于 X，记做:

    简单来说，(学号，课名)→ 系名，学号 → 系名，那么(学号，课名)p→ 系名。

2.2.4 传递函数依赖

    假如 Z 函数依赖于 Y，且 Y 函数依赖于 X ，且Y不包含于 X，X 不函数依赖于 Y， 那么我们就称 Z 传递函数依赖于 X，记做:

    简单来说，系名 → 系主任，学号 → 系名，那么学号 T→ 系主任。

 

3.理解三大范式

3.1  一范式

    一范式(1NF):域应该是原子性的，即数据库表的每一列都是不可分割的原子数据项

    很明显如上图所示的表格设计是不符合第一范式的，商品列中的数据不是原子数据 项，是可以进行分割的，因此对表格进行修改，让表格符合第一范式的要求，修改结果如下图所示:

    实际上，1NF 是所有关系型数据库的最基本要求，你在关系型数据库管理系统 (RDBMS)，例如 SQL Server，Oracle，MySQL 中创建数据表的时候，如果数据表的设计不符合这个最基本的要求，那么操作一定是不能成功的。也就是说，只要在 RDBMS 中已 经存在的数据表，一定是符合 1NF 的。

 

3.2 二范式

    二范式(2NF):在 1NF 的基础上，实体的属性完全函数依赖于主关键字(混合主键)，  不能存在部分函数依赖于主关键字(混合主键)。 如果存在某些属性只依赖混合主键中的部分属性，那么不符合二范式。

    上述表格中是混合主键(学生 ID + 所修课程)，但是所属系和系主任这两个属性只依 赖于混合主键中的学生 ID 这一个属性，因此，不符合第二范式。

    如果有一天学生的所属系要调整，那么所属系和系主任这两列都需要修改，如果这个学 生修了多门课程，那么表中的多行数据都要修改，这是非常麻烦的，不符合第二范式。

    为了消除这种部分依赖，只有一个办法，就是将大数据表拆分成两个或者更多个更小的数据表。

    通过上述的修改，当一个学生的所属系需要调整时，不管学生修了多少门课程，都只需要改变上表中的第一行数据即可。

 

3.3  三范式

    3NF 在 2NF 的基础之上，消除了非主属性对于主键(复合主键)的传递依赖。

    很明显，上表中，商品颜色依赖于商品 ID，商品 ID 依赖于订单 ID，那么非主属性商 品颜色就传递依赖于订单 ID，因此不符合三范式，解决方案是将大数据表拆分成两个或者 更多个更小的数据表。

 

    三大范式只是一般设计数据库的基本理念，可以建立冗余较小、结构合理的数据库。如果有特殊情况，当然要特殊对待，数据库设计最重要的是看需求跟性能，需求>性能>表结构。所以不能一味的去追求范式建立数据库。

 

 

4.数据库设计E-R模型理论详解

4.1 基本理论

    E-R 模型是数据库设计的理论基础，当前几乎所有的 OLTP 系统设计都采用 ER 模型建模的方式。

    在信息系统中，将事物抽象为“实体”、“属性”、“关系”来表示数据关联和事物 描述;其中，实体:Entity，关系:Relationship，这种对数据的抽象建模通常被称为 ER 实体关系模型。

    实体:通常为参与到过程中的主体，客观存在的，比如商品、仓库、货位、汽车，此实体非数据库的实体表;

    属性:对主体的描述、修饰即为属性，比如商品的属性有商品名称、颜色、尺寸、重 量、产地等;

    关系:现实的物理事件是依附于实体的，比如商品入库事件，依附实体商品、货位， 就会有“库存”的属性产生;用户购买商品，依附实体用户、商品，就会有“购买数量”、 “金额”的属性产品。

 

4.2 实体之间的对照关系

    实体之间建立关系时，存在对照关系:

    1:1，即 1 对 1 的关系，比如实体人、身份证，一个人有且仅有一个身份证号;(A->B: 相互完全依赖，知道 A 一定确定 B，知道 B 一定确定 A)。

    (动静分离:在数据库设计时，会将动态属性(年龄、地址、偏好、...)和静态属性(姓 名、性别、身份证号、...)进行分离，剥离为两张表，一张父表，一张子表，从而提高性能)。

    1:n，即 1 对多的关系，比如实体学生、班级，对于某 1 个学生，仅属于 1 个班级，而 在 1 个班级中，可以有多个学生;(一张学生表，一张班级表，通过班级 ID 这个外键进行 关联)。

    n:m，即多对多的关系，比如实体学生、课程，每个学生可以选修多门课程，同样每个 课程也可以被多门学生选修;(一张学生表，一张课程表，一张选课表)。

 

4.3  ER 建模的图形表示 

    在日常建模过程中: 

     “实体”:使用矩形表示; 

    “关系”:使用菱形表示;

     “属性”:使用椭圆形表示;

    所以 ER 实体关系模型也称作 E-R 关系图。

 

5. 数据库设计E-R 建模实例 

5.1 场景

    学生选课系统，该系统主要用来管理学生和选修课程，其中包括课程选修、学生管理功 能，现需要完成数据库逻辑模型设计。

5.2 实现步骤

    抽象出主体 —— 学生，课程;

    梳理主体之间的关系 —— 选修;(学生与选修课程是一个多对多的关系)

    梳理主体的属性;

    画出 E-R 关系图;

    使用 ER 模型构建数据仓库的成功率是比较低的，因为涉及到“抽象出实体”这个过程， 这就涉及到将企业所有业务系统中的所有实体都抽象出来，这需要先梳理出所有的业务系 统实体，再梳理实体之间的关系，这是一个非常复杂的过程，可能你把公司所有的实体梳 理清楚了，可能业务又要调整了。