数据库设计

一、E-R模型（entity-relationship）

     

      三个属性：实体集、联系集合属性

（1）实体：现实世界区别于其他对象的“对象”或“事物”

（2）联系：多个实体之间的联系

（3）属性：类似于数据表的列

 

    码：（1）超码：在实体集可以唯一标示一个实体的属性集合（比如说一个id标示不同的人，人就相当于实 体）

           （2）候选码：最小的超码

           （3） 被选作来区分不同实体的候选码

 

二、关系数据库的设计

（1）函数依赖

      如果属性集A能够推出属性集B，那么可以说属性集B函数依赖于属性集A，即A-->B

 

（2）平凡的函数依赖

        如果B属于A，那么A-->B的函数依赖就是平凡的

 

（3）第一范式：所有的属性域都是原子的

         什么叫都是原子的，就是不可分割的，举个俩字来说，如果某个表中有一个属性为children，该属性的值是一些名字的组合，那么该表就不符合第一范式

         原子性是可以根据自己的感受去衡量的，比如说你说整数是原子的，那么如果你的属性是整数，那你的属性具有原子性，如果你说整数是单个数字的组成，如果你的属性是整数，那么，你的属性就是非原子的

 

（4）第二范式

       在满足第一范式的情况下，每个非主属性都完全函数依赖于超码R

       举个例子（来源百度）：

从定义可以看出，若某个 1NF 的关系的主码只由一个列组成，那么这个关系就是 2NF 关系。但是，如果主码是由多个属性列共同组成的复合主码，并且存在非主属性对属性的部分函数依赖，则这个关系不是 2NF 关系。  

例如：在关系 SB（学号，姓名，系名，系主任，课号，成绩）中，

非主属性“姓名”仅函数依赖于“学号”，也就是“姓名”部分函数依赖于主码（学号，课号）而不是完全依赖；

非主属性“系名”仅函数依赖于“学号”，也就是“系名”部分函数依赖于主码（学号，课号）而不是完全依赖；

非主属性“系主任”仅函数依赖于“学号”，也就是“系主任”部分函数依赖于主码（学号，课号）而不是完全依赖。

 

（5）BC范式（boyce-codd）

         当关系满足如果R中非平凡的函数依赖的左边都是超键，则此关系R属于BCNF；

        也就是说BC范式满足两个条件：a-->b是平凡的函数依赖；a-->b，a是整个关系R的超码

 

（6）第三范式

        第三范式多加了一个条件：a-->b，（b-a）的每个属性A都包含在R的一个候选码中

       从另一个角度解释：

       如果关系 R ∈ 2NF，并且 R 中每一个非主属性对任何候选码都不存在传递函数依赖，则 R ∈ 3NF 。

        

      关系模式 SC 和 SD 均是 2NF 的，但在关系 SD（学号，姓名，系名，系主任）中，存在如下函数依赖：

 

     学号 → 系名

 

     系名 → 系主任

 

     系名 －\→ 学号

     那么，存在着一个传递函数依赖“学号 → 系主任”成立。

     从上面的分析可以知道，因为在 SD 中存在传递函数依赖，所以 SD 不满足 3NF。

 

 

（7）分解算法

     2NF分解

       

1. 用组成主码的属性集合的每一个子集作为主码构成一个表。

2. 对于每个表，将依赖于此主码的属性放置到此表中。

例如：将 SB 分解为两个关系模式

SC（学号，课号，成绩），主码为（学号，课号）

SD（学号，姓名，系名，系主任），主码为 学号。

 

3NF分解

1. 对于不是候选码的每个决定因子，从关系模式中删除依赖于该决定因子的属性。

2. 新建一个关系模式，新的关系模式中应包含在原表中所有依赖于该决定因子的属性。

3. 将决定因子作为新关系模式的主码。

例如：将 SD 分解为

SE（学号，姓名，系名）

SF（系名，系主任）