数据库三范式

设计库设计范式

数据库的设计范式实际上非常的重要，但是从实际的开发来看，如果真的全部按照范式去做，则这个程序很难写，查询语句也会很复杂。

在oracle中的scott用户的四张表，实际上就已经很好的体现了一种设计思路，雇员-部门的关系。

一、第一范式

第一范式的目标是确保每列的原子性。数据库表中的字段都是单一属性的，不可再分。

这个单一属性由基本类型构成，包括整型、实数、字符型、逻辑型、日期型等。

范例：现在假设有如下的数据库创建脚本

create table person

(

      pid number(4) primaty key,

      name varchar2(20),

      info varchar2(50)

);

插入以下的测试数据：

insert into person values(1234,'张三','1983年12月12日出生，现在居住地址：南昌昌北经开区');

实际上对于人员的信息来看，由以下几部分组成：

生日：1983年12月12日

城市：南昌

地区：昌北经开区

每个字段不可再分，所以修改上面的数据库脚本。

要保证数据表中的每一个字段都不可再分。

二、第二范式

定义：数据库表中不存在非关键字段对任一候选关键字段的部分函数依赖（部分函数依赖指 的是存在组合关键字中的某些字段决定非关键字段的情况），也即所有非关键字段都完全依赖于任意一组候选关键字。

第一范式的要求非常简单，就是要保证每个列有意义。但是如果所有的操作都是用第一范式，那么也会存在问题：

现在建立一张学生选课表：学号、姓名、年龄、课程名称、成绩、学分

create table sc

(

      sno number(4),

      sname varchar2(20),

      sage number(2),

      cname varchar2(20),

      grade number,

      credit number

);

以上的数据库脚本，符合第一范式要求，但是如果现在按照第一范式设计的话，则也会存在问题。

insert into sc values(1111,'李四',23,'java',75,3);

insert into sc values(1112,'李1',22,'java',80,3);

insert into sc values(1113,'李2',23,'java',85,3);

从上面的数据可以看出，所有的课程冗余了，而且还存在如下问题：

如果一门课程没有一个学生选修的话，则此课程就在学校消失了。

如果要更新课程信息，则要更新很多条记录。

使用第二范式修改数据库脚本：

学生应该是一个实体表信息

 

课程应该是一个实体表信息

学生选课：一个学生可能选多门课程，一门课程会有多个学生参加，每个学生的每个课程成绩不一样，应该建立一张关系表，表示出以上的概念。

以上设计解决了如下问题：

学生不选课的时候，课程信息不会消失。

更新课程的时候直接更新课程表即可。

所有的关联关系在关系表中体现。

完成了一个多-多的关系。

三、第三范式

在实际开发中，第三范式使用的频率最多。

例如：现在要求设计一张学生表，包含学号、姓名、年龄、所在院校、学院地址、学员电话，此时用第二范式设计看看。

create table student

(

      sno number(4),

      sname varchar2(20),

      sage number(2)

);

create table collage

(

      cid number(4) primaty key,

      cname varchar2(20),

      caddress varchar2(200),

      ctel varchar2(20)

);

create table stucoll

(

      sno number(4),

      cid number(4),

      设置主外键关系

);

按照此种设计，一个学生可以同时在多个学院同时上课，多个学院会同时又一个学生。此时最好的做法是：一个学院包含多个学生，一个学生属于一个学院。

实际上此设计就类似于部门和雇员信息表的设计结构。

修改以上的设计：

以上的三个设计范式只能算是参考。在开发中，数据库的设计唯一原则：数据库表的关联查询越少越好，SQL语句的复杂度越低越好。