数据库设计（范式例子讲解，E-R图讲解）

emmm，上星期做课程设计的时候才发现自己在数据库设计这方面掌握得很差劲，这星期打算重新开始学习和思考！！

一、一些基本的概念

1.1 函数依赖

在一个关系模式中，如果一组属性的取值可以决定另一组属性的取值，我们说这两组属性之间存在函数依赖的关系。

1.2 多值依赖

定义：设R(U)是属性集U上的一个关系模式。X，Y，Z是U的子集,并且Z=U-X-Y。关系模式R(U)中多值依赖X→→Y成立，当且仅当对R(U)的任一关系r,给定的一对(x，z)值有一组Y的值，这组值仅仅决定于x值而与z值无关。

通俗地讲就是一个x值改变对应多个值y改变（但是与z值无关）

举个栗子：

有这样一个关系 <仓库管理员，仓库号，库存产品号> ，假设一个产品只能放到一个仓库中，但是一个仓库可以有若干管理员，那么对应于一个 <仓库管理员，库存产品号>有一个仓库号，而实际上，这个仓库号只与库存产品号有关，与管理员无关，就说这是多值依赖。 

说明：在这里， <库存产品号，仓库管理员>就对应着(x，z)，这组值取决于x(库存产品号)，而与z（库存管理员）无关。因为上面说了仓库号只与库存产品有关。也就意味着库存产品号改变，仓库号也改变，而一个仓库可以有若干个管理员，也就意味着多个仓库管理员的改变，这不就是前面所说的一个值改变对应多个值改变。

二、基于函数依赖的范式

2.1 INF（关系型数据必须具有的）

定义：对于关系模式R，当且仅当R中的每个属性对应的域是原子的，即域的元素被认为是不可分的单元，则该关系称为第一范式，即R∈1NF。

通俗地讲就是不能表中带表。

2.2 2NF

定义：对于关系模式R，当且仅当R∈1NF，且R中每个非主属性都完全函数依赖于候选键时，该关系模式R属于第二范式，即R∈2NF。

如何才能满足二范式呢？也就是消除非主属性对主键的部分依赖（分解，根据一张表只管一件事情的思想来划分表）

比如设计一个学生表S(studentID，name，age，address，courseID，grade)，那么这个表主键不单单是studentID，因为课程成绩依赖于课程，所以这个表的主键应该是studentID和courseID，但是name，age，address只依赖于studentID这个属性，这也就存在了非主属性对主键存在部分函数依赖，即不满足第二范式。

不满足第二范式的缺点：（以上面的学生表为例）

1. 插入异常，比如有一个新手刚开学到学校报道，这个时候学生是一门课都还没选的。这个时候，学生的姓名年龄都不能插入进去，因为没选课courseID为空，但是主键不能为空，这就导致了插入异常。
2. 删除异常，如果有个学生生病了选择休息一学期，把他这学期的所有课程都退选了，这时候学生基本信息也随之被删除了。但是这个学生只是休学而不是退学。
3. 更新异常，比如一个学生选修5门课，这个时候他想修改地址，那么就需要修改5条信息，这就是数据冗余造成的更新繁琐。

解决方法：

  根据一张表只管一件事情的思想来划分表。前面的学生表S就是因为一张表包含和学生基本信息和选课信息两件事情造成的数据冗余。

  前面的学生表S划分为：

     S(studentID，name，age，address)

     SC(studentID，courseID，grade)

2.3 3NF

定义：对于关系模式R，当且仅当R∈2NF，且R中所有的非主属性都不传递函数依赖于主键，该关系模式属于第三范式，记为R∈3NF。

3NF是一个可用的关系模式应该满足的最低范式，但有时候会降低范式，以空间换时间。

举个栗子：比如有表R1(学生学号，学生姓名，所在系，系主任)，因为学生学号 → 所在系  → 系主任，所以这就存在传递依赖

不满足第三范式的缺点（以上面R1为例）：

1. 更新异常，比如你有50个学生，你现在要更改系主任，那么你就需要更改50条信息。
2. 插入异常，在学生所在系还没确定之前，所在系和系主任的对照关系是无法插入的。
3. 删除异常，如果一个系只有一个学生，那么删除这个学生的时候，所在系和系主任的这个对照关系也会被删除了。

解决方法：

   还是根据上面一张表只管一件事的思想，明显上面的R1表既包含了学生基本信息又包含了每个系的主任是谁。那么分解的结果即为：

    R2(学生学号，学生姓名，所在系)

    R3(所在系，系主任)

三、数据字典

数据字典要解决的问题：

1. 名字冲突：比如编号在学生中代表学生编号，在课程代表课程编号，应该区分开来。
2. 概念冲突：同一概念在一个视图中可能作为实体，在另一视图中可能作为属性或联系。比如部门在员工表中是一个属性，但是它在别的模块中又是单独独立为一个部门表，这时候就需要和客户沟通部门表需不需要单独成立一个表，如果需要的话，就把在员工表中的部分属性改成部门编号。
3. 值域冲突：比如性别：一些用中文表达，一些用01表达。

请记住这句话，每一项数据必须是来源唯一，责任唯一（数据来源于哪，谁产生，谁来用）

四、E-R图向关系模式的转换

E-R图真的真的很重要，特别是比较大一点的项目，如果有了一个总体的E-R图，那么每个实体之间的联系就会变得很清晰。

4.1 实体的转换

一个实体转换为一个关系模式。实体的属性就是关系的属性，实体的关键字就是关系的候选键

4.2  1:1联系的转换方法

对于1:1的联系，有两种转换方式：

（1）单独对应一关系模式。关系模式的属性由参与联系的各实体的关键字以及该联系本身的属性组成，且每个实体的关键字均可为该关系模式的候选键。（但是只能选择一个哦）

（2）不单独对应一关系模式。可将联系合并到与该联系相关的任意一端实体所对应的关系模式中。需要在被合并的关系模式中添加联系本身的属性以及与联系相关的另一端实体的关键字，新增属性后，原关系模式的候选键不变。

说的通俗点，就是两个实体任选一个，添加另一个实体的关键字及其联系的属性。

4.3 1:n的转换方法

对于1:n的联系，同样有两种转换方式：

（1）将联系转换为一个独立的关系模式。关系模式的属性由参与联系的各实体的关键字以及该联系本身的属性组成，关系模式的主键为n端实体的主键。

（2）不单独转换为一个独立的关系模式。可将联系合并到n端实体所对应的关系模式中。需要在n端实体对应的关系模式中增加联系本身的属性以及与联系相关的另一端实体的关键字，新增属性后，原关系模式的候选键不变。

说的通俗点，就是n端实体添加另一端实体的关键字和联系本身的属性。主键不变

4.4 m:n联系的转换方法

对于m:n的联系，只能转化为一个独立的关系模式。关系模式的属性由参与联系的各实体的关键字以及联系本身的属性构成，关系模式的候选键由各实体的关键字属性共同组成。

说的通俗点，就是说对于多对多的关系，两张表需要变成三张表。第三张表也就是关系表，包含【联系本身的属性和两个外键（是另外两个表的主键）】，且其主键是两个外键组合成

举个栗子：

学生（学生编号，学生姓名）

班级（班级编号，班级名称）

课程（课程编号，课程名称）

班级和学生是一对多的关系：

        （1）单独对应一关系模式：学生班级表（学生编号，班级编号），学生（学生编号，学生姓名），班级（班级编号，班级名称）

        （2）还是两张表：学生（学生编号，学生姓名，班级编号），班级（班级编号，班级名称）

学生和课程是多对多的关系：

        学生（学生编号，学生姓名）

        学生课程（学生编号，课程编号）

        课程（课程编号，课程名称）

五、数据库设计的一些要点

1. 对于表达类似信息，模式相似只是取值不同的表，应尽量合并。如学习经历、进修经历；奖惩信息、惩处信息等。考虑到效率、用途等因素，该分开的表还应分开。如本科生基本信息和研究生基本信息。
2. 结合DBMS内部实现技术，合理设计索引和文件结构，为查询优化准备好存取路径。
3. 在结构规范化、减少数据冗余和提高数据库访问性能之间仔细权衡，适当折中。并不是范式越高越好。