1NF 2NF 3NF

摘自百度百科

http://baike.baidu.com/view/998488.htm?fr=aladdin

### 数据库范式的概念 #### 第一范式 (1NF) 第一范式的核心在于确保数据库中的每一列都具有原子性,即不可再分的数据项。这意味着每列只包含单一值而非复合结构或列形式[^1]。 **示例:** 假设有一个未规范化的关系 `R` 示学生的选课情况: | 学生ID | 姓名 | 课程 | |--------|----------|-------------| | S001 | 张三 | 数学, 英语 | 此格违反了1NF,因为“课程”字段包含了多个值。将其转换为符合1NF的形式如下所示: ```sql CREATE TABLE Students ( StudentID VARCHAR(5), Name VARCHAR(20), Course VARCHAR(20) ); ``` | 学生ID | 姓名 | 课程 | |--------|------|-------| | S001 | 张三 | 数学 | | S001 | 张三 | 英语 | --- #### 第二范式 (2NF) 当一个关系已经满足1NF,并且所有的非主属性完全函数依赖于候选键,则该关系属于第二范式[^2]。 **解释:** 在上述例子中,“学生姓名”,“所在系”,以及“系主任”实际上都是通过“学生学号”间接关联起来的信息;而当前设计里它们被重复存储多次造成冗余现象。因此需要拆分成两个独立的实体来消除部分依赖。 **调整后的模型:** - **Student Table:** ```sql CREATE TABLE StudentInfo ( StudentID VARCHAR(5) PRIMARY KEY, Name VARCHAR(20), Department VARCHAR(30) ); ``` - **Department Table:** ```sql CREATE TABLE Departments ( DeptName VARCHAR(30) PRIMARY KEY, HeadOfDept VARCHAR(40) ); ``` 这样就实现了完整的分离并减少了不必要的复制。 --- #### 第三范式 (3NF) 如果某个关系模式达到了2NF标准,并且不存在任何非主属性对码有传递依赖的话,我们就说这个关系处于第三范式之中[^3]。 **说明:** 继续以上面提到的学生信息为例,在原始版本中可能存在这样的逻辑链条:“学生 -> 所属院系 -> 系主任”。这种情况下,“系主任”的定义实际上是基于另一个中间层——也就是具体的学院名称决定下来的,而不是直接由个人身份所确定下来的结果。所以应该把关于部门管理者的描述单独提取出来形成新的子集以避免此类问题的发生。 最终优化之后得到的是更加清晰合理的架构布局方式。 --- ### 总结 通过对不同层次上的逐步改进措施可以有效提升整个系统的性能现水平的同时还能增强其可维护性扩展能力等方面的优势特点。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值