数据库设计三范式

文章转载自「开发者圆桌」一个关于开发者入门、进阶、踩坑的微信公众号


作为一个数据库的学习者,搞懂关系数据库的三大范式是很有用的。然而有关数据库范式的介绍都是采用学术性的定义,语法羞涩,让人难懂,故写下自己对数据库范式的理解,给初学者提供帮助。


关系数据库中的关系必须满足一定的要求。满足不同程度要求的为不同范式。数据库的设计范式是数据库设计所需要满足的规范。只有理解数据库的设计范式,才能设计出高效率、优雅的数据库,否则可能会设计出错误的数据库。


目前,主要有六种范式:第一范式、第二范式、第三范式、BC范式、第四范式和第五范式。满足最低要求的叫第一范式,简称1NF。在第一范式基础上进一步满足一些要求的为第二范式,简称2NF。其余依此类推。


范式可以避免数据冗余,减少数据库的空间,减轻维护数据完整性的麻烦,但是操作困难,因为需要联系多个表才能得到所需要数据,而且范式越高性能就会越差。要权衡是否使用更高范式是比较麻烦的,一般在项目中,用得最多的也就是第三范式,使用到第三范式也就足够了,性能好而且方便管理数据。


本文不介绍规范化程度高于3NF的范式,对于很多大型复杂的系统,其数据库设计都没有遵循所谓的范式,这也是为什么会出现所谓的逆规范化,范式也需要考虑使用场景,不可一切东西都要范式化。在没有更多实践经验的情况下,遵循范式是非常好的选择。


在实例中理解三大范式


1NF:字段不可分


强调的是列的原子性,即列不能够再分成其他几列。 


例1,学生信息表


学生编号 姓名 性别 联系方式

20080901 张三 男 email:zs@126.com,phone:88886666

20080902 李四 女 email:ls@126.com,phone:66668888

以上的表就不符合,第一范式:联系方式字段可以再分,所以变更为正确的是:

学生编号 姓名 性别 电子邮件 电话

20080901 张三 男 zs@126.com 88886666

20080902 李四 女 ls@126.com 66668888


例2,学生班级信息


学生编号 姓名 班级

20080901 小明 高三1班

20080902 小叶 高三2班

以上的表就不符合,第一范式:班级字段可以再分,所以变更为正确的是:

学生编号 姓名 年级 班级

20080901 小明 高三 1班

20080902 小叶 高三 2班


例3,员工信息表


员工编号 姓名 工作年限

20080901 小明 2009~2011

20080902 小叶 2006~2012

以上的表就不符合,第一范式:工作年限可以再分,所以变更为正确的是:

员工编号 姓名 工作年份 离职年份 

20080901 小明 2009 2011

20080902 小叶 2006 2012


例4,学生成绩表


学生编号 姓名 课程成绩

20080901 小明 80,70,90

20080902 小叶 60,70,85

以上的表就不符合,第一范式:课程成绩可以再分,所以变更为正确的是:

学生编号 姓名 语文 数学 外语

20080901 小明 80 70 90

20080902 小叶 60 70 85


例5,联系人信息表


姓名 性别 电话

小明  男   0101-3464554,13699170707

小叶  女   0101-3464674,13623450707

以上的表就不符合,第一范式:电话可以再分,所以变更为正确的是:

姓名 性别 座机 手机

小明  男   0101-3464554 13699170707

小叶  女   0101-3464674 13623450707


例6,公司信息表


公司编号 名称 地址

20080901 谷歌 美国加利福尼亚州圣克拉拉县山景市

20080902 百度 中国北京市海淀区上地十街10号百度大厦

以上的表就不符合,第一范式:地址可以再分,所以变更为正确的是:

公司编号 名称 国籍 地址

20080901 谷歌 美国 加利福尼亚州圣克拉拉县山景市

20080902 百度 中国 北京市海淀区上地十街10号百度大厦


对于例6地址的拆分可根据需求进行,不一定非要拆分。如果需知道哪个国家并按其分类,那么显然第一个表格是不容易满足需求的,也不符合第一范式。因此是否符合第一范式的要求在一定程度上取决于后期对数据的查询和使用上,当然,第一范式是前人总结的通用方法,遵循它会得到意想不到的好处。



2NF:有主键,非主键字段依赖主键


首先是满足 1NF,另外包含两部分内容,一是表必须有一个主键;二是没有包含在主键中的列必须完全依赖于主键。


主键很重要,要记住在设计表的时候无论如何也要添加主键,没有主键的表会给你带来噩梦般的体验,会给系统开发、功能维护、数据维护带来不必要的麻烦。举个例子,上面例5,联系人信息表就没有添加主键,如下数据你想删除小明的信息该如何操作,根据姓名吗?不行,因为有重名的情况,只能通过姓名+电话两个字段组合为一个唯一的条件进行删除。


姓名 性别 电话

小明  男   0101-3464554,13699170707

小叶  女   0101-3464674,13623450707

小朱  女   0101-3464675,13623450705

小明  男   0101-3464676,13623450706


而有了主键,情况会是怎样的呢?你只需要根据联系人编号即可删除,一步到位。


联系人编号 姓名 性别 电话

1 小明  男   0101-3464554,13699170707

2 小叶  女   0101-3464674,13623450707

3 小朱  女   0101-3464675,13623450705

4 小明  男   0101-3464676,13623450706


切记,在任何时刻,一张表一定要有主键,如果你无法确定业务中哪个字段作为主键,那么你就建立一个ID字段作为主键,多一个ID字段不会影响什么。


例1,学生信息表(主键学号)


学号 姓名 性别 年龄 课程名称 学分

2008 张三 男 15 语文    45

2008 张三 男 15 数学    55

2009 李四 女 16 语文    45

2009 李四 女 16 数学    55

以上的表就不符合,第二范式:主键(学号)无法唯一确定课程名称和学分,也就是说部分非主键字段不依赖主键,所以变更为正确的是:


学生信息表


学号 姓名 性别 年龄

2008 张三 男 15 

2008 张三 男 15 


课程表


课程名称 学分

语文     45

数学     55


学生选课表


学号  课程名称

2008  语文

2008  数学

2009  语文

2009  数学


例2,学生借书表


学生证号 学生证办理时间 借书证号 借书证办理时间

2008 2010年9月1号 201001  2010年10月1号

2009 2010年9月2号 201011  2011年10月1号

以上的表就不符合,第二范式:借书证号和借书证办理时间这些非主键字段不依赖学生证号这个主键,所以变更为正确的是:


学生证表


学生证号 学生证办理时间

2008 2010年9月1号

2009 2010年9月2号 


借书证表


借书证号 借书证办理时间

201001  2010年10月1号

201011  2011年10月1号


例3,订单表订单编号和商品编号为联合主键


订单编号 商品编号 商品名称 数量 单位 价格 客户 所属单位 联系方式

001 1 挖掘机 1 台 1200000¥ 张三 上海玖智 020-1234567

001 2 冲击钻 8 把 230¥     张三 上海玖智 020-1234567

002 3 铲车   2 辆 980000¥  李四 北京公司 010-1234567

这样就产生一个问题:这个表中是以订单编号和商品编号作为联合主键。这样在该表中商品名称、单位、商品价格等信息不与该表的主键相关,而仅仅是与商品编号相关。所以在这里违反了2NF的设计原则。而如果把这个订单信息表进行拆分,把商品信息分离到另一个表中,把订单项目表也分离到另一个表中,就非常完美了。如下所示:


订单信息表


订单编号 客户 所属单位 联系方式

001 张三 上海玖智 020-1234567

002 李四 北京公司 010-1234567


订单项目表


订单编号 商品编号 数量

001 1 1

001 2 8

002 3 2


商品信息表


商品编号 商品名称 单位 商品价格

1 挖掘机 台 1200000¥

2 冲击钻 个 230¥

3 铲车 辆 980000¥



3NF:非主键字段不能相互依赖


首先是 2NF,另外非主键列必须直接依赖于主键,不能存在传递依赖。即不能存在:非主键列 A 依赖于非主键列 B,非主键列 B 依赖于主键的情况。 通俗解释:任意一个字段都只依赖表中的同一个字段。


例1,家庭成员表


户主 儿子 女儿 女儿的小熊 女儿的海绵宝宝

Jack Tom  Lucy  Bear       spongebob

Jobs july Lily  Bear2      spongebob2

以上的表就不符合,第三范式:其中 儿子 女儿 等非主键列都完全依赖于主键(户主),所以符合 2NF,不过问题是 女儿的小熊 女儿的海绵宝宝 直接依赖的是 女儿字段 (非主键列),而不是直接依赖于主键,它通过传递才依赖于主键,所以不符合 3NF。 所以变更为正确的是:


户主信息表


户主 儿子 女儿

Jack Tom  Lucy

Josb  July  Lily


女儿信息表


女儿 女儿的小熊 女儿的海绵宝宝

Lucy  Bear       spongebob

Lily  Bear2      spongebob2


例2,订单表(主键是OrderID)


OrderID OrderDate CustomerID CustomerName CustomerAddr CustomerCity

101  2011年 100 xx联合公司 中央大街100号 纽约

102  2012年 100 xx联合公司 中央大街100号 纽约

103  2014年 200 yy联合公司 白宫          纽约

以上的表就不符合,第三范式:其中 OrderDate,CustomerID等非主键列都完全依赖于主键(OrderID),所以符合 2NF,不过问题是 CustomerName,CustomerAddr,CustomerCity 直接依赖的是 CustomerID(非主键列),而不是直接依赖于主键,它是通过传递才依赖于主键,所以不符合 3NF。 所以变更为正确的是:


订单表


OrderID OrderDate CustomerID

101  2011年 100

102  2012年 100

103  2014年 200


客户信息表


CustomerID CustomerName CustomerAddr CustomerCity

100 xx联合公司 中央大街100号 纽约

200 yy联合公司 白宫          纽约


例3,学生信息表(主键是学号)


学号 姓名  所在系 系名称 系地址 

101  小明  001 数学系 1号楼

102  小叶  002 文学系 5号楼

103  小炫  003 物理系 6号楼

以上的表就不符合,第三范式:其中学号,姓名,所在系等非主键列都完全依赖于主键(学号),所以符合 2NF,不过问题是系名称,系地址直接依赖的是所在系(非主键列),而不是直接依赖于主键,它是通过传递才依赖于主键,所以不符合 3NF。 所以变更为正确的是:


学生表


学号 姓名  所在系

101  小明  001 

102  小叶  002 

103  小炫  003


院系信息表


系编号 系名称 系地址 

001 数学系 1号楼

002 文学系 5号楼

003 物理系 6号楼


第二范式(2NF)和第三范式(3NF)的概念很容易混淆,区分它们的关键点在于,2NF:非主键列是否完全依赖于主键,还是依赖于主键的一部分;3NF:非主键列是直接依赖于主键,还是直接依赖于非主键列。


通过对每个范式的定义介绍,加上几个在实践中的反例进行讲解,可在一定程度上加快理论的理解,缩短理论和实践之间的距离,可快速上手3范式在开发中的应用。


  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值