【数据库记录】数据库三大范式和BCNF范式

本文详细解释了数据库设计中的第一范式(1NF)、第二范式(2NF)、第三范式(3NF)及BCNF范式的基本概念,通过实例展示了如何确保数据库表结构遵循这些规范,以实现数据的一致性和减少冗余。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

1.第一范式1NF:指列不可以再分割。

举个例子:一张student表,有三个列id,name,age,如下。

id,name,age不可以再分,这就是符合第一范式,下面这样,就是不符合第一范式。

列不能再拆分这就是满足第一范式,正常的关系型数据库,都是满足第一范式的。

2.第二范式2NF:在第一范式的基础上,还要满足其他字段必须依赖于主键。

在上边的表中,就不满足第二范式。

这里学号是唯一的,张三的信息是完全依赖于学号,但是分数不是完全依赖于学号。

如果有十几个科目,就会有十几行数据,前边的字段都是冗余数据。

这时候我们就要把表拆分一下,如下。

这样就是满足第二范式。

3.第三范式3NF:在第二范式的基础上,消除传递依赖,就是说其他字段依赖主键还不行,还必须的直接依赖。

上图第二张表,老师和老师的年龄是完全依赖于主键(学号+科目),但是老师年龄的直接依赖是老师,老师年龄这个字段是间接依赖于主键(老师年龄->老师->主键)。

这就不满足第三范式,于是再把老师的列单独拆出来。

teacher表

ps:上边应该也有一个老师的编号,student表通过老师编号用来关联老师。

4.BCNF范式:在第三范式的基础上,不允许主键的一部分被另一部分或其它字段决定。

在这张表中,联合主键1(姓名+科目)----》老师     联合主键2(姓名+老师)----》科目。

既满足全部依赖,又满足直接依赖。所以属于第三范式。

(科目是联合主键1的一部分)(老师是联合主键2的一部分)

但是这里的(老师----》科目),老师可以决定科目。

就是说科目被老师所决定=====主键的一部分被其他字段决定。

 

注意:所谓的范式,是设计数据库的基本理念,用来参考,实际开发中并不会有太多要求,按照实际情况来,不一定要遵守。

### 数据库设计中的三大范式及其作用 #### 第一范式(1NF) 第一范式要求数据库表中的每一列都保持原子性,即不可再分。这意味着每个字段必须存储单一值,不能包含多个值或嵌套结构。通过遵循第一范式,可以确保数据的完整性并减少冗余。 例如,在一个学生信息表中,如果“地址”字段包含了完整的地址信息(如“北京市海淀区某街道某号”),这违反了第一范式,因为地址可以进一步分解为城市、区县详细地址等部分[^1]。遵循第一范式后,该表可能如下所示: | 学生ID | 姓名 | 城市 | 区县 | 详细地址 | |--------|--------|--------|--------|----------------| | 1 | 张三 | 北京市 | 海淀区 | 某街道某号 | #### 第二范式(2NF) 第二范式建立在第一范式的基础上,要求非主键字段完全依赖于主键,而不是部分依赖。换句话说,表中的每个非主属性必须完全依赖于整个主键,而不能仅依赖于主键的一部分。 例如,在一个订单详情表中,如果使用“订单编号+商品编号”作为联合主键,并且存在“客户名称”字段,这会导致部分依赖问题,因为“客户名称”只与“订单编号”相关,而不与“商品编号”相关[^5]。遵循第二范式后,可以通过将客户信息单独存放在另一个表中来解决此问题。 | 订单编号 | 商品编号 | 数量 | 价格 | |----------|----------|------|------| | 001 | 101 | 2 | 100 | | 订单编号 | 客户名称 | |----------|----------| | 001 | 李四 | #### 第三范式3NF) 第三范式要求消除传递依赖,即非主属性之间不应存在依赖关系。每个非主属性必须直接依赖于主键,而不能通过其他非主属性间接依赖于主键。 例如,在一个员工信息表中,如果存在“部门名称”字段,而“部门名称”实际上是由“部门编号”决定的,这会形成传递依赖(员工ID → 部门编号 → 部门名称)。遵循第三范式后,可以通过将部门信息单独存放在另一个表中来解决此问题[^3]。 | 员工ID | 姓名 | 部门编号 | |--------|--------|----------| | 1 | 王五 | 001 | | 部门编号 | 部门名称 | |----------|----------| | 001 | 技术部 | #### 三大范式的作用 遵循数据库三大范式可以帮助设计出结构合理、减少冗余、提高数据一致性的数据库。具体来说: - **减少数据冗余**:通过规范化设计,避免重复存储相同的数据。 - **提高数据一致性**:减少因数据冗余而导致的更新异常、插入异常删除异常。 - **简化维护成本**:规范化的设计使得数据库更易于维护扩展。 然而,在实际应用中,也需要根据具体需求场景灵活运用这些范式。有时候为了提高查询性能或简化设计,适度的冗余可能是可以接受的[^2]。 ```sql -- 示例:创建符合三大范式数据库表 CREATE TABLE Departments ( DepartmentID INT PRIMARY KEY, DepartmentName VARCHAR(100) NOT NULL ); CREATE TABLE Employees ( EmployeeID INT PRIMARY KEY, Name VARCHAR(50) NOT NULL, DepartmentID INT NOT NULL, FOREIGN KEY (DepartmentID) REFERENCES Departments(DepartmentID) ); ```
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

安逸的程序猿

意思不意思那是你的意思我没意思

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值