关系数据库表中的关系必须满足一定的要求。满足不同程度要求的为不同范式。数据库的设计范式是数据库表设计所需要满足的规范。只有理解数据库表的设计范式,才能设计出高效率、优雅的数据库表,否则可能会设计出错误的数据库.
范式对数据库表的规范要求是递增的。目前,主要有六种范式:第一范式、第二范式、第三范式、BC范式、第四范式和第五范式。满足最低要求的叫第一范式,简称1NF。在第一范式基础上进一步满足一些要求的为第二范式,简称2NF。其余依此类推。
范式可以避免数据冗余,减少数据库的空间,减轻维护数据完整性的麻烦,但是操作困难,因为需要联系多个表才能得到所需要数据,而且范式越高性能就会越差。要权衡是否使用更高范式是比较麻烦的,一般在项目中,用得最多的也就是第三范式,我认为使用到第三范式也就足够了,性能好而且方便管理数据。
函数依赖,如果一个表中某一个字段Y的值是由另外一个字段或一组字段X的值来确定的,就称为Y函数依赖于X。
第一范式(1NF,normal format)
定义:如果关系模式R的每个关系r的属性都是不可分的数据项,那么就称R是第一范式的模式。
简单的说,每一个属性都是原子项,不可分割。
1NF是关系模式应具备的最起码的条件,如果数据库设计不能满足第一范式,就不称为关系型数据库。关系数据库设计研究的关系规范化是在1NF之上进行的。
例如(学生信息表):
学生编号 姓名 性别 联系方式
20080901 张三 男 email:zs@126.com,phone:88886666
20080902 李四 女 email:ls@126.com,phone:66668888
以上的表就不符合,第一范式:联系方式字段可以再分,所以变更为正确的是:
学生编号 姓名 性别 电子邮件 电话
20080901 张三 男 zs@126.com 88886666
20080902 李四 女 ls@126.com 66668888
范式一主要是细化数据的操作粒度。因为非主属性都是函数依赖于主属性,不遵守第一范式对插入不影响,但是对查询修改影响较大
第二范式(2NF)
定义:如果关系模式R是1NF,且每个非主属性完全函数依赖于候选键,那么就称R是第二范式。
简单的说,第二范式要满足以下的条件:首先要满足第一范式,其次每个非主属性要完全函数依赖与候选键,或者是主键。也就是说,每个非主属性是由整个主键函数决定的,而不能由主键的一部分来决定。
例如(学生选课表):
学生 课程 教师 教师职称 教材 教室 上课时间
李四 Spring 张老师 java讲师 《Spring深入浅出》 301 08:00
张三 Struts 杨老师 java讲师 《Struts in Action》 302 13:30
这里通过(学生,课程)可以确定教师、教师职称,教材,教室和上课时间,所以可以把(学生,课程)作为主键。但是,教材并不完全依赖于(学生,课程),只拿出课程就可以确定教材,因为一个课程,一定指定了某个教材。这就叫不完全依赖,或者部分依赖。出现这种情况,就不满足第二范式。
修改后,选课表:
学生 课程 教师 教师职称 教室 上课时间
李四 Spring 张老师 java讲师 301 08:00
张三 Struts 杨老师 java讲师 302 13:30
课程表:
课程 教材
Spring 《Spring深入浅出》
Struts 《Struts in Action》
所以,第二范式可以说是消除部分依赖。第二范式可以减少数据冗余、插入异常、’删除异常和修改异常,比如:
(1)数据冗余:
这里以(学生,课程)为主键,教程部分依赖于课程,这样会导致教材数据无用重复
(2)插入异常:
新增课程,如果没有学生选就没法新增数据
(3)删除异常:
假设Spring课程暂时关闭,把所有选择Spring的选课记录删除,则Spring课程信息也删除了
(4)修改异常:
如果Spring课程换教材,则所有选择Spring课程的选课记录都要更新
第三范式(3NF)
定义:如果关系模式R是2NF,且关系模式R(U,F)中的所有非主属性(主属性可以理解为能单独作为候选键的属性,关于候选键看另一篇文章)对任何候选关键字都不存在传递依赖,则称关系R是属于第三范式。
简单的说,第三范式要满足以下的条件:首先要满足第二范式,其次非主属性之间不存在函数依赖。由于满足了第二范式,表示每个非主属性都函数依赖于主键。如果非主属性之间存在了函数依赖,就会存在传递依赖,这样就不满足第三范式。
上例中修改后的选课表中,一个教师能确定一个教师职称。这样,教师依赖于(学生,课程),而教师职称又依赖于教师,这叫传递依赖。第三范式就是要消除传递依赖。
修改后,选课表:
学生 课程 教师 教室 上课时间
李四 Spring 张老师 301 08:00
张三 Struts 杨老师 302 13:30
教师表:
教师 教师职称
张老师 java讲师
杨老师 java讲师
这样,新教师的职称在没被选课的时候也有地方存了,没人选这个教师的课的时候教师的职称也不至于被删除,修改教师职称时只修改教师表就可以了。
简单的说,
第一范式就是原子性,字段不可再分割;
第二范式就是完全依赖,没有部分依赖;
第三范式就是没有传递依赖。
相关推荐
设计范式(范式,数据库设计范式,数据库的设计范式)是符合某一种级别的关系模式的集合。构造数据库必须遵循一定的规则。在关系数据库中,这种规则就是范式。关系数据库中的关系必须满足一定的要求,即满足不同的...
数据库设计范式是数据库设计所需要满足的规范,满足这些规范的数据库是简洁的、结构明晰的,同时,不会发生插入、删除和更新操作异常。 第一范式(1NF)是数据库设计的基础规范,它规定了数据库表中的字段都是单一...
### 数据库设计三大范式应用实例剖析 #### 引言 数据库的设计范式是指一系列用于指导数据库设计的规范化准则,其目的是确保数据的完整性、减少数据冗余,并提高数据库的操作效率。遵循这些范式可以避免在数据库...
"数据库设计三大范式应用实例剖析" 数据库设计是数据库系统的核心部分,直接影响着数据库的性能、安全性和可维护性。数据库设计的目的是为了使数据库系统满足某些标准,使得数据库系统更加简洁、明晰、易于维护和...
数据库设计三大范式五大约束 数据库设计是指对数据库的结构、数据模型和数据关系的设计和规划。好的数据库设计可以提高数据库的性能、安全性和可维护性。本文将对数据库设计三大范式和五大约束进行详细的介绍和分析...
尤其是数据库设计范式 现简单介绍1NF(第一范式),2NF(第二范式),3NF(第三范式)和BCNF,另有第四范式和第五范式留到以后再介绍。 在你设计数据库之时,若能符合这几个范式,你就是数据库设计的高手
数据库设计是信息系统构建的核心环节,其中的三大范式——第一范式、第二范式和第三范式,是确保数据规范化和避免数据冗余的关键原则。这些范式是根据关系数据库理论建立的,目的是提高数据库的逻辑独立性和减少数据...
数据库设计的三大范式是构建高效、稳定、无冗余关系型数据库的关键准则。这些范式为数据库设计者提供了一套标准,确保数据的一致性和完整性。以下是这三大范式的详细解释: 1. 第一范式(1NF - First Normal Form)...
【计算机等考三级数据库基础:数据库设计三大范式应用实例剖析】 数据库设计是构建高效、稳定、易维护的信息系统的基础,而三大范式——第一范式(1NF)、第二范式(2NF)和第三范式(3NF)是确保数据库设计规范的...
【数据库设计三大范式】是数据库设计的基本原则,它们确保了数据库的结构合理、数据一致性和减少冗余。这三个范式分别是第一范式(1NF)、第二范式(2NF)和第三范式(3NF)。 **第一范式(1NF)**要求数据库表中的...
在数据库设计中,三大范式(Normal Forms)是确保数据逻辑结构合理化、减少冗余、避免数据不一致的关键原则。这些范式是第一范式(1NF)、第二范式(2NF)和第三范式(3NF)。下面将详细阐述这三大范式及其在MySQL...
数据库设计范式是关系数据库的基础规范,关系数据库的设计必须遵循这些规范,否则将会导致数据库设计混乱、数据冗余、查询效率低下等问题。数据库设计范式的应用非常广泛,可以应用于数据库设计、数据库优化、数据库...
数据库设计的三大范式——第一范式(1NF)、第二范式(2NF)和第三范式(3NF)——是构建高效、无冗余、易于维护的数据库的基础。它们确保了数据的一致性和完整性,避免了数据异常,如插入异常、删除异常和更新异常...
关系型数据库设计范式是数据库设计的核心原则,用于确保数据的一致性、减少冗余和避免数据异常。在设计数据库时,遵循这些范式能够提高数据的组织效率和查询性能,降低维护成本。以下是四种主要的范式以及它们的解释...
数据库设计范式是一系列规则,它们帮助开发者创建出既高效又易于维护的数据模型。遵循这些规范能有效避免数据冗余、插入异常、删除异常以及更新异常等问题。本文将详细介绍数据库设计的三大范式——第一范式(1NF)、...