数据库设计 三范式

 

建立冗余小,结构合理的数据库,设计数据库时必须准许你一定的规则,在关系数据库中的这种规则就成为范式.是要符合某一种设计要求的总结

 

要想设计一个合理的关系数据型数据库库,就必须满足一定的范式

 

 

1 第一范式.(确保每列的原子性), 每个列的值只有一个

 

 

也是最基本的范式. 如果数据库表中的所有字段值是都不可分解的原子值.

 

例如 ,用户信息表中.

 

 

但是这个并不是一个规范化的关系.因为电话可以进一步分解.包含两个子属性.长途好和家庭电话.

使表达到第一规范化要求很简单, 只需要把子属性提升为一般属性就满足了第一规范式要求.

 

 

 

2  第二范式 (确保表中的每列都和主键相关)

 

它是在满足第一范式的基础上建立起来的. 第二范式必须先满足第二范式.

 

要求数据库表中的每个实例或行必须可以被唯一区分,完全依赖主关键字, 也就是和主键相关. 而不能与主键的某

一部分相关. 不可以把多种数据保存在同一张数据库表中.

 

比如要设计一个订单信息表,因为订单可能会有多种商品.所以要将订单编号和商品编号作为一个数据库表的联合主键

如下表.

 

订单信息表

 

 

 

就这意味着这个属性决定其他属性.比如(订单编号, 商品编号) 确定 联系方式.

其次,这个关系中还存在其他依赖, 如(商品编号 确定 单位,  价格, 上平名称等) 这里就违反了第二规范式设计原则.

 

一个关系,如果没有满足第二范式,只满足第一范式, 那么就会带来数据的冗余和操作异常.包括,插入异常, 删除和修改异常. 操作异常又经常称为更新异常或存储异常. 

 

这里可以看到 张三在表中出现了两次.这里就存在着大量的冗余的数据.

 

一般可以通过分分解的方法,消除部分依赖.

 

把商品信息分离到另一个表中,把定单项目也分离到另外一个表中,如下图

 

 

 

 

3  第三范式 ( 属性不能依赖于其他非主属性[ 消除传递依赖])

 

第三范式必须先满足第二范式. 要求一个数据库表中不包含已经在其他表中已包含的非主关键字.

 

下面看一个不满足的表

一张employee 雇员表

 

    

 

可以观察到 ,以上表中出现了问题

 

 人力部出现了两次, 而销售部更贱过分,出现了四次,这是不能容忍的.怎么减呢>

 另外增加一个Department部门表. 如下

 

department（deptid， deptname）

雇员表中

employee（empid， ename， deptid）

 

这样就好多了。