数据库范式的区别

1、1NF(第一范式)

第一范式是指数据库表中的每一列都是不可分割的基本数据项,同一列中不能有多个值,即实体中的某个属性不能有多个值或者不能有重复的属性。

 

如果出现重复的属性,就可能需要定义一个新的实体,新的实体由重复的属性构成,新实体与原实体之间为一对多关系。第一范式的模式要求属性值不可再分裂成更小部分,即属性项不能是属性组合或是由一组属性构成。

 

简而言之,第一范式就是无重复的列。例如,由“职工号”“姓名”“电话号码”组成的表(一个人可能有一部办公电话和一部移动电话),这时将其规范化为1NF可以将电话号码分为“办公电话”和“移动电话”两个属性,即职工(职工号,姓名,办公电话,移动电话)。

 

2、2NF(第二范式)

第二范式(2NF)是在第一范式(1NF)的基础上建立起来的,即满足第二范式(2NF)必须先满足第一范式(1NF)。第二范式(2NF)要求数据库表中的每个实例或行必须可以被唯一地区分。为实现区分通常需要为表加上一个列,以存储各个实例的唯一标识。

 

如果关系模型R为第一范式,并且R中的每一个非主属性完全函数依赖于R的某个候选键,则称R为第二范式模式(如果A是关系模式R的候选键的一个属性,则称A是R的主属性,否则称A是R的非主属性)。

 

例如,在选课关系表(学号,课程号,成绩,学分),关键字为组合关键字(学号,课程号),但由于非主属性学分仅依赖于课程号,对关键字(学号,课程号)只是部分依赖,而不是完全依赖,因此此种方式会导致数据冗余以及更新异常等问题,解决办法是将其分为两个关系模式:学生表(学号,课程号,分数)和课程表(课程号,学分),新关系通过学生表中的外关键字课程号联系,在需要时进行连接。

 

3、3NF(第三范式)

如果关系模型R是第二范式,且每个非主属性都不传递依赖于R的候选键,则称R是第三范式的模式。

 

以学生表(学号,姓名,课程号,成绩)为例,其中学生姓名无重名,所以该表有两个候选码(学号,课程号)和(姓名,课程号),故存在函数依赖:学号——>姓名,(学号,课程号)——>成绩,唯一的非主属性成绩对码不存在部分依赖,也不存在传递依赖,所以属性属于第三范式。

 

4、BCNF(BC范式)

它构建在第三范式的基础上,如果关系模型R是第一范式,且每个属性都不传递依赖于R的候选键,那么称R为BCNF的模式。

 

假设仓库管理关系表(仓库号,存储物品号,管理员号,数量),满足一个管理员只在一个仓库工作;一个仓库可以存储多种物品,则存在如下关系:

(仓库号,存储物品号)——>(管理员号,数量)

(管理员号,存储物品号)——>(仓库号,数量)

所以,(仓库号,存储物品号)和(管理员号,存储物品号)都是仓库管理关系表的候选码,表中唯一非关键字段为数量,它是符合第三范式的。但是,由于存在如下决定关系:

(仓库号)——>(管理员号)

(管理员号)——>(仓库号)

即存在关键字段决定关键字段的情况,因此其不符合BCNF。把仓库管理关系表分解为两个关系表仓库管理表(仓库号,管理员号)和仓库表(仓库号,存储物品号,数量),这样这个数据库表是符合BCNF的,并消除了删除异常、插入异常和更新异常。

 

5、4NF(第四范式)

设R是一个关系模型,D是R上的多值依赖集合。如果D中存在凡多值依赖X->Y时,X必是R的超键,那么称R是第四范式的模式。

 

例如,职工表(职工编号,职工孩子姓名,职工选修课程),在这个表中,同一个职工可能会有多个职工孩子姓名,同样,同一个职工也可能会有多个职工选修课程,即这里存在着多值事实,不符合第四范式。如果要符合第四范式,只需要将上表分为两个表,使它们只有一个多值事实,例如职工表一(职工编号,职工孩子姓名),职工表二(职工编号,职工选修课程),两个表都只有一个多值事实,所以符合第四范式。

 

1 、第一范式(1NF) 
在任何一个关系数据库中,第一范式(1NF)是对关系模式的基本要求,不满足第一范式(1NF)的数据库就不是关系数据库。 
所谓第一范式(1NF)是指数据库表的每一列(即每个属性)都是不可分割的基本数据项,同一列中不能有多个值,即实体中的某个属性不能有多个值或者不能有重复的属性。简而言之,第一范式就是无重复的列。 
2、 第二范式(2NF) 
第二范式(2NF)是在第一范式(1NF)的基础上建立起来的,即满足第二范式(2NF)必须先满足第一范式(1NF)。第二范式(2NF)要求数据库表中的每个实例或行必须可以被唯一地区分。为实现区分通常需要为表加上一个列,以存储各个实例的唯一标识。员工信息表中加上了员工编号(emp_id)列,因为每个员工的员工编号是唯一的,因此每个员工可以被唯一区分。这个唯一属性列被称为主关键字或主键、主码。 
第二范式(2NF)要求实体的属性完全依赖于主关键字。所谓完全依赖是指不能存在仅依赖主关键字一部分的属性,如果存在,那么这个属性和主关键字的这一部分应该分离出来形成一个新的实体,新实体与原实体之间是一对多的关系。为实现区分通常需要为表加上一个列,以存储各个实例的唯一标识。简而言之,第二范式就是非主属性依赖于主关键字。 
3 、第三范式(3NF) 
满足第三范式(3NF)必须先满足第二范式(2NF)。在满足第二范式的基础上,切不存在传递函数依赖,那么就是第三范式。简而言之,第三范式就是属性不依赖于其它非主属性。

### 数据库范式的概念 数据库范式是指由E.F.Codd提出的关于关系数据库设计的一系列规则和标准,这些规则帮助开发者减少数据冗余并增强数据一致性[^3]。通过遵循不同的范式级别(从1NF到更高的形式如5NF),可以逐步优化数据库结构。 #### 第一范式 (1NF) 第一范式要求表中的每一列都必须是原子性的,即不可再分的基本数据项[^1]。这意味着每一条记录都应该是一个单一值而不是一组重复的值或者列表。 #### 第二范式 (2NF) 第二范式建立在第一范式的基础上,进一步规定所有的非主属性完全依赖于整个主键而非其部分组件[^2]。这有助于防止部分函数依赖带来的问题。 #### 第三范式 (3NF) 第三范式是在满足前两者的前提下,消除了任何非主属性对候选关键字之间的传递函数依赖关系[^2]。这样做的目的是为了确保没有间接的数据关联影响整体架构稳定性。 ### 应用场景分析 尽管高阶范式提供了更好的逻辑独立性和较少的数据重复率,但在实际项目开发当中并非总是追求最高程度的形式化处理。例如,在某些特定条件下允许一定程度上的去规范化(反范式),以便换取读取速度方面的改进: - **低频写入高频读取环境**:在这种环境中适当引入一些冗余信息可能会显著加快查询响应时间因为减少了必要的联接次数[^4]。 - **实时报表生成系统**:当面对复杂的汇总计算需求时预先聚合结果存储下来也可以有效降低在线事务处理的压力从而提升用户体验质量。 然而需要注意的是过度使用这种方法不仅增加了磁盘占用还容易引发同步错误所以应当谨慎评估利弊后再决定实施策略。 ```sql -- 示例SQL语句展示如何创建符合3NF的关系型表格 CREATE TABLE Orders ( OrderID INT PRIMARY KEY, CustomerID INT NOT NULL, -- 假设Customer有单独一张表 FOREIGN KEY (CustomerID) REFERENCES Customers(CustomerID), OrderDate DATE NOT NULL ); CREATE TABLE OrderDetails ( DetailID INT AUTO_INCREMENT PRIMARY KEY, OrderID INT NOT NULL, ProductID INT NOT NULL, Quantity INT DEFAULT 0 CHECK (Quantity >= 0), Price DECIMAL(8 , 2 ) UNSIGNED , FOREIGN KEY (OrderID) REFERENCES Orders(OrderID), FOREIGN KEY (ProductID) REFERENCES Products(ProductID) ); ``` 以上代码片段展示了两个相互关联但各自保持良好分离度的实体定义方式——订单及其明细条目分别存放在不同地方并通过外键机制维持联系;这样的安排正好体现了良好的实践原则之一就是尽量避免不必要的嵌套复合类型字段存在于此同时又能很好地适应未来扩展可能性变化趋势的要求。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值