数据库键和三大设计范式

数据库设计范式

首先复习一下一些数据库的基本概念：

超键（superkey）：在一个关系中可以唯一的识别一条记录的字段或字段集合

候选键（candidate key）：最小超键

主键（primary key）：   被数据库设计者选中的，作为区分数据库中不同记录的候选键。

外键：一张表中的一个字段可能是其他表的主键，这个字段称为外键。

例子：一张表学生记录表。 属性有   学号，姓名，班级

这张表中 {学号}、{学号，姓名}、{姓名，班级}都可以作为却定一条记录的超键，但是可以作为候选键的只有{学号}、{姓名、班级}。{学号，姓名}不是最小超键，应为它的子集{学号}依然是一个超键。如果设计者选择学号来标识不同的学生，那么学号就是主键。

下面简单解释一下三大范式

第一范式：如果一个关系模式（数据库表设计）的所有属性（字段）的域都是原子的，就符合第一范式。

不符合第一范式的两种属性：

1.多值属性

比如 电话 这个属性，一个人可能有多个电话，这种情况就要为每个电话号码值建立一条记录

2.组合属性

比如 详细地址，详细地址包括了所在省，所在市，所在街道等这样的属性的域也不是原子域，可以把组合属性拆分

        看一个关系模式R是不是符合第二，第三范式主要看各个属性之间的依赖关系，如果存在属性依赖于候选键组合的部分属性，则不符合第二范式，若存在属性不仅依赖于主键，还依赖于其他属性，则不符合第三范式。

第二范式：每一行的数据只能与其中一列相关，即一行数据只做一件事。只要数据列中出现数据重复，就要把表拆分开来。

例如：

（学号，姓名，年龄，课程，学分，成绩）

  

依赖关系：

学号 -->姓名，年龄               课程 -->学分

  

在这里，学分属性只依赖于候选键组合（学号，课程）的一部分，也就是课程。

可以拆分成（学号，姓名，年龄）

（学号，所选课程，成绩）

（课程，学分）三张表。  

第三范式：不允许传递依赖

  （学号，姓名，院系，院系地址）

  依赖关系：学号->院系->院系地址

可以拆分成（学号，姓名，院系）

（院系，院系地址）两张表

    不符合第二，第三范式的表设计会造成数据冗余和插入异常的问题，比如在上面的表结构中，同一个院系有400名学生，那这个院系就要出现在记录中400次，同时如果要修改院系的名称，也要修改400条记录，如果要增加新的院系，新增院系的前提是有一个学生。