在数据库系统中,关系模式必须满足一定的性质，以确保数据的准确性和一致性，这些性质包括：第一范式（1NF）、第二范式（2NF）、第三范式（3NF）以及BCNF（Boyce-Codd范式），下面将逐一介绍这些性质及其具体实例。
图片来源于网络，如有侵权联系删除
第一范式（1NF）
第一范式是所有关系模式都必须满足的最基本要求,它确保了表中所有的列都是原子性的，即每一个单元格中的数据项是不可再分的，假设我们有一个学生成绩表：
| 学号 | 姓名 | 课程编号 | 成绩 |
|---|---|---|---|
| 001 | 张三 | CS101 | 85 |
| 002 | 李四 | Math201 | 90 |
在这个表格中,每一列的数据项都是不可分割的，因此这个关系模式符合第一范式。
第二范式（2NF）
第二范式要求关系模式除了满足第一范式外,还需要消除非主属性对候选键的部分依赖，部分依赖是指某个非主属性仅依赖于候选键的一部分，而不是整个候选键，考虑以下学生信息表：
| 学号 | 姓名 | 性别 | 年龄 | 班级编号 |
|---|---|---|---|---|
| 001 | 张三 | 男 | 20 | A01 |
| 002 | 李四 | 女 | 22 | B02 |
在这个例子中,“性别”和“年龄”都只依赖于“学号”，而“班级编号”则依赖于“学号”，为了消除这种部分依赖，我们可以将其拆分为两个表：
学生基本信息表
| 学号 | 姓名 | 性别 | 年龄 |
|---|---|---|---|
| 001 | 张三 | 男 | 20 |
| 002 | 李四 | 女 | 22 |
学生班级表
| 学号 | 班级编号 |
|---|---|
| 001 | A01 |
| 002 | B02 |
通过这样的分解,消除了部分依赖，使得关系模式符合第二范式。
第三范式（3NF）
第三范式进一步要求关系模式除了满足第二范式外,还要消除非主属性之间的传递依赖，传递依赖指的是一个非主属性依赖于另一个非主属性，考虑以下订单明细表：
| 订单号 | 产品ID | 数量 | 单价 | 总金额 |
|---|---|---|---|---|
| O1001 | P1001 | 10 | 00 | 50 |
| O1002 | P1002 | 15 | 50 | 50 |
在这个例子中,“总金额”是通过“数量”和“单价”计算得出的，这实际上是一种传递依赖，为了消除这种传递依赖，可以将该表拆分为两个表：
图片来源于网络，如有侵权联系删除
订单明细表
| 订单号 | 产品ID | 数量 | 单价 |
|---|---|---|---|
| O1001 | P1001 | 10 | 00 |
| O1002 | P1002 | 15 | 50 |
订单汇总表
| 订单号 | 总金额 |
|---|---|
| O1001 | 50 |
| O1002 | 50 |
通过这样的分解,消除了传递依赖，使得关系模式符合第三范式。
BCNF（Boyce-Codd范式）
BCNF是对第三范式的扩展,要求关系模式的每一个决定因素都必须是候选键，这意味着任何非主属性都不能由其他非主属性决定，考虑以下员工工资表：
| 员工ID | 部门ID | 工资等级 | 基本工资 | 提成比例 |
|---|---|---|---|---|
| E1001 | D01 | S1 | 5000 | 05 |
| E1002 | D01 | S1 | 5500 | 06 |
在这个例子中,“提成比例”可以由“工资等级”决定，这是一种不完全的函数依赖，为了达到BCNF，我们需要重新设计这张表：
员工基本信息表
| 员工ID | 部门ID | 工资等级 |
|---|---|---|
| E1001 | D01 | S1 |
| E1002 | D01 | S1 |
员工工资详情表
| 员工ID | 基本工资 | 提成比例 |
|---|---|---|
| E1001 | 5000 |
标签： #数据库关系的性质包含哪些方面 #每个性质给出具体实例
评论列表