数据库范式

1NF

列的原子性,列的内容不可再分割

学生表(学号、姓名、年龄、性别、地址)。地址可以细分为国家、省份、城市、市区、街道,那么该模式就没有达到第一范式。

  • 第一范式存在问题:冗余度大、会引起修改操作的不一致性、数据插入异常、数据删除异常。

2NF

非主键完全依赖主键
(确保每列都和主键直接相关)
(表必须有主键ID)

版本表(版本编码,版本名称,产品编码,产品名称),其中主键是(版本编码,产品编码),这个场景中,数据库设计并不符合第二范式,因为产品名称只依赖于产品编码。存在部分依赖。所以,为了使其满足第二范式,可以改造成两个表:版本表(版本编码,产品编码)和产品表(产品编码,产品名称)

3NF

  • 属性不依赖于其他非主属性
    (不传递依赖)
    不能存在非主键列 A 依赖于非主键列 B,非主键列 B 依赖于主键的情况。
    (数据库中的一个表不包含已在其他表中已包含的非主关键字信息)
    (除主键以外的列,不存在某个列,能决定其他列)
    (确保每列都和主键列直接相关,而不是间接相关)

    订单表(订单编码,顾客编码,顾客名称),其中主键是(订单编码),这个场景中,顾客编码、顾客名称都完全依赖于主键,因此符合第二范式,但顾客名称依赖于顾客编码,从而间接依赖于主键,所以不能满足第三范式。如果要满足第三范式,需要拆分为两个表:订单表(订单编码,顾客编码)和顾客表(顾客编码,顾客名称)。

2NF和3NF的区别关键点

· 2NF: 非主键是否完全依赖于主键,还是依赖于主键的一部分
· 3NF: 非主键列是直接依赖于主键,还是直接依赖于非主键列

BCDF范式(鲍伊斯-科得范式,3NF改进形式)

  • 在第三的基础上, 数据库表中不存在任何字段对任一候选关键字段的传递函数依赖则符合第三范式
    防止主键的某一列会依赖于主键的其他列。当3NF消除了主属性对码的部分函数依赖和传递函数依赖称为BCNF。

特性:

1、所有主属性对每一个码都是完全函数依赖

2、所有主属性对每一个不包含它的码,也是完全函数依赖

3、没有任何属性完全函数依赖与非码的任何一组属性

库存表(仓库名,管理员名,商品名,数量),主键为(仓库名,管理员名,商品名),这是满足前面三个范式的,但是仓库名和管理员名之间存在依赖关系,因此删除某一个仓库,会导致管理员也被删除,这样就不满足BCNF。

4NF

非主属性不应该有多值。如果有多值就违反了第四范式。4NF是限制关系模式的属性间不允许有非平凡且非函数依赖的多值依赖。

用户联系方式表(用户id,固定电话,移动电话),其中用户id是主键,这个满足了BCNF,但是一个用户有可能会有多个固定电话或者多个移动电话,那么这种设计就不合理,应该改为(用户id,联系方式类型,电话号码)。

如果只考虑函数依赖,关系模式规范化程度最高的范式是BCNF;如果考虑多值依赖则是4NF

5NF

第五范式属于最终范式,消除了4NF中的连接依赖,第五范式需要满足以下要求:

1、必须满足第四范式

2、表必须可以分解为较小的表,除非那些表在逻辑上拥有与原始表相同的主键。

一般实际应用中不必考虑第五范式。

作者

孙起

发布于

2022-09-09

更新于

2022-09-09

许可协议

评论