关系数据库设计理论

是什么

关系数据库设计理论是指在设计关系数据库时所需要遵循的一系列规则和原则。这些规则和原则有助于确保数据库的结构合理、数据完整性和一致性得到保证，使得数据可以被高效地存储、检索和管理。

函数依赖

函数依赖是关系数据库设计中的一个基本概念，它是指在一个关系中，一个属性或者属性组的取值决定了另一个属性或者属性组的取值。函数依赖通常用X → Y表示，其中X是决定Y的属性集合，Y是被决定的属性集合。

记 A->B 表示 A 函数决定 B，也可以说 B 函数依赖于 A。

如果 {A1，A2，… ，An} 是关系的一个或多个属性的集合，该集合函数决定了关系的其它所有属性并且是最小的，那么该集合就称为键码。

对于 A->B，如果能找到 A 的真子集 A’，使得 A’-> B，那么 A->B 就是部分函数依赖，否则就是完全函数依赖。

对于 A->B，B->C，则 A->C 是一个传递函数依赖。

• 合并律：由X→Y，X→Z，有X→YZ
• 伪传递律：X→Y，WY→Z，有WX→Z
• 分解律：由X→Y及Z∈Y，有X→Z

完全函数依赖(Full Functional Dependency)

完全函数依赖是指在一个关系中，X对Y的决定是最小的，也就是说，如果去掉X中的任何一个属性，Y的值都会发生改变。例如，学生的学号决定了他的姓名和性别，如果去掉学号中的任何一个数字，学生的姓名和性别都会发生改变。因此，学号对姓名和性别的依赖是完全函数依赖。

例如，在一个学生信息表中，如果学生的学号（StudentID）唯一地决定了他的姓名（Name）和年龄（Age），则可以表示为：StudentID → Name, Age。这里的完全函数依赖指学号对姓名和年龄的决定是最小的，即没有其他属性或属性组对姓名和年龄的取值有影响。

部分函数依赖(Partial Functional Dependency)

部分函数依赖是指在一个关系中，X对Y的决定不是最小的，也就是说，Y可以由X中的某个真子集决定。例如，学生的姓名和性别的值可能由学号和出生日期的组合决定，但是学号或者出生日期单独来看都不能确定姓名和性别的值。因此，学号和出生日期对姓名和性别的依赖是部分函数依赖。

例如，在一个订单表中，如果订单号（OrderID）和订单日期（OrderDate）组合决定了客户姓名（CustomerName），但是订单号或订单日期单独来看都不能确定客户姓名，则可以表示为：{OrderID, OrderDate} → CustomerName。这里的部分函数依赖指客户姓名可以由订单号和订单日期的组合决定，但是其中任意一个属性都不能单独决定客户姓名。

传递函数依赖(Transitive Functional Dependency)

传递函数依赖是指在一个关系中，X对Y的决定不是直接的，而是通过另一个属性集合Z来传递的。例如，学生的班级决定了他所在的学院和专业，班级和学院的关系是一对多的，学院和专业的关系也是一对多的，因此班级对专业的依赖就是通过学院这个中介属性集合传递的。

例如，在一个学生信息表中，如果学生的班级（Class）决定了他所在的学院（College）和专业（Major），而学院又决定了专业，则可以表示为：Class → College, Major。这里的传递函数依赖指班级对专业的决定是通过学院这个中介属性集合传递的，而不是直接决定的。

异常

插入异常(Insertion Anomaly)

插入异常是指在向数据库表中插入新数据时，由于表的设计不合理，导致无法插入完整的数据行。例如，假设一个订单表中包含订单号、客户姓名和客户地址三个属性，如果有一些客户没有下订单，就无法将他们的姓名和地址插入订单表中，这就是插入异常。

更新异常(Update Anomaly)

更新异常是指在更新数据库表中的数据时，由于表的设计不合理，导致同一数据在不同地方重复出现，从而导致更新时需要修改多个副本，容易出现数据不一致的情况。例如，假设一个学生信息表中包含学生的学号、姓名和班级三个属性，如果一个学生转班了，就需要更新他的班级信息，但是如果该学生在多个地方都有记录，就需要同时更新多个副本，容易出现更新不一致的情况。

删除异常(Deletion Anomaly)

删除异常是指在从数据库表中删除数据时，由于表的设计不合理，导致无法删除部分数据行，或者删除一个数据行会同时删除其他数据行。例如，假设一个课程表中包含课程号、课程名称和授课教师三个属性，如果一个教师离职了，就需要将他所授课程从课程表中删除，但是如果该教师所授多门课程都在同一数据行中，就需要删除整个数据行，从而导致其他课程的信息也被删除了。

这些异常都是由于关系数据库表的设计不合理所导致的，而范式的设计原则就是为了解决这些异常。通过将数据规范化到符合特定范式的形式，可以避免或减少这些异常的出现，从而提高数据的一致性和完整性。

实例

以下的学生课程关系的函数依赖为 {Sno, Cname} -> {Sname, Sdept, Mname, Grade}，键码为 {Sno, Cname}。也就是说，确定学生和课程之后，就能确定其它信息。

Sno	Sname	Sdept	Mname	Cname	Grade
1	学生-1	学院-1	院长-1	课程-1	90
2	学生-2	学院-2	院长-2	课程-2	80
2	学生-2	学院-2	院长-2	课程-1	100
3	学生-3	学院-2	院长-2	课程-2	95

不符合范式的关系，会产生很多异常，主要有以下四种异常：

• 冗余数据：例如 学生-2 出现了两次。
• 修改异常：修改了一个记录中的信息，但是另一个记录中相同的信息却没有被修改。
• 删除异常：删除一个信息，那么也会丢失其它信息。例如删除了 课程-1 需要删除第一行和第三行，那么 学生-1 的信息就会丢失。
• 插入异常：例如想要插入一个学生的信息，如果这个学生还没选课，那么就无法插入。

范式

范式是一种关系数据库设计理论中的概念，它用于帮助设计者将数据存储在关系数据库中的最佳方式。范式的主要目的是减少数据冗余，提高数据的一致性和减少数据的更新异常。关系数据库设计理论中存在多种范式，例如第一范式（1NF）、第二范式（2NF）和第三范式（3NF）等。

第一范式要求每个属性都是原子性的、不可分割的，避免数据冗余和复杂性。第二范式要求一个关系中所有属性都应该依赖于该关系的候选键，避免了部分函数依赖关系。第三范式要求一个关系中不存在非主属性对主键的传递依赖，避免了传递依赖关系，使得数据的更新更加简单和高效。

范式理论是为了解决以上提到四种异常。

高级别范式的依赖于低级别的范式，1NF 是最低级别的范式。

第一范式(1NF)

第一范式要求每个属性都是原子的，即不可再分。例如，假设一个学生信息表中包含姓名和电话两个属性，如果将电话号码拆分成区号和号码两个属性，则违反了第一范式。

第二范式(2NF)

第二范式要求关系表中的每个非主属性都完全依赖于主键，即不存在部分函数依赖。例如，假设一个订单表中包含订单号、商品号、商品名称和价格四个属性，其中商品名称和价格都只与商品号有关系，而不与订单号有关系，就违反了第二范式。

分解前

Sno	Sname	Sdept	Mname	Cname	Grade
1	学生-1	学院-1	院长-1	课程-1	90
2	学生-2	学院-2	院长-2	课程-2	80
2	学生-2	学院-2	院长-2	课程-1	100
3	学生-3	学院-2	院长-2	课程-2	95

以上学生课程关系中，{Sno, Cname} 为键码，有如下函数依赖：

• Sno -> Sname, Sdept
• Sdept -> Mname
• Sno, Cname-> Grade

Grade 完全函数依赖于键码，它没有任何冗余数据，每个学生的每门课都有特定的成绩。

Sname, Sdept 和 Mname 都部分依赖于键码，当一个学生选修了多门课时，这些数据就会出现多次，造成大量冗余数据。

分解后

关系-1

Sno	Sname	Sdept	Mname
1	学生-1	学院-1	院长-1
2	学生-2	学院-2	院长-2
3	学生-3	学院-2	院长-2

有以下函数依赖：

• Sno -> Sname, Sdept
• Sdept -> Mname

关系-2

Sno	Cname	Grade
1	课程-1	90
2	课程-2	80
2	课程-1	100
3	课程-2	95

有以下函数依赖：

• Sno, Cname -> Grade

第三范式(3NF)

第三范式要求关系表中的每个非主属性都不传递依赖于主键，即不存在传递函数依赖。例如，假设一个学生信息表中包含学号、姓名、班级和学院四个属性，其中学院和专业只与班级有关系，而不与学号有关系，就违反了第三范式。

上面的 关系-1 中存在以下传递函数依赖：

• Sno -> Sdept -> Mname

可以进行以下分解：

关系-11

Sno	Sname	Sdept
1	学生-1	学院-1
2	学生-2	学院-2
3	学生-3	学院-2

关系-12

Sdept	Mname
学院-1	院长-1
学院-2	院长-2

第四范式(4NF)

第四范式要求关系表中不存在多值依赖。多值依赖是指一个或多个属性的值可以由一个或多个非主属性集合决定，而不是由主键决定。例如，假设一个订单表中包含订单号、商品号、商品名称和订单数量四个属性，其中订单数量可以由订单号和商品号的组合决定，而不是由订单号或商品号单独决定，就违反了第四范式。

实例

假设有一个学生信息表，包含以下属性：

• 学号(StuID)
• 姓名(Name)
• 年龄(Age)
• 班级(Class)
• 学院(College)
• 专业(Major)

如果班级决定了学院和专业，即同一班级的学生所属的学院和专业都相同，那么就存在传递函数依赖。例如，如果有以下数据行：

StuID	Name	Age	Class	College	Major
001	Tom	18	1	A	Math
002	Jack	19	1	A	Math
003	Lucy	20	2	B	English

在这个例子中，班级为1的学生都属于学院A的数学专业，因此可以通过班级确定学院和专业的取值，存在传递函数依赖。如果要符合第三范式，则需要将原始的学生信息表拆分成两个表，分别是学生基本信息表和班级信息表，具体如下：

学生基本信息表(Student):

StuID	Name	Age
001	Tom	18
002	Jack	19
003	Lucy	20

班级信息表(Class):

Class	College	Major
1	A	Math
2	B	English

在拆分后的表中，学生的基本信息和班级的信息被分别存储在不同的表中，避免了班级信息对于学生信息的传递函数依赖关系。这样设计的好处是，可以避免数据冗余和数据不一致的问题，同时也方便了数据的维护和查询。

总结

关系数据库设计理论是数据库领域中的一个重要分支，它提供了一套规范化的设计原则，用于规范关系数据库表的结构，以提高数据的一致性、完整性和可维护性。范式设计、函数依赖和数据库设计过程是关系数据库设计理论的核心要点。在实践中，需要根据不同的业务需求和数据特征选择合适的设计原则和设计方法，以实现数据的高效管理和利用。

同时，需要注意的是，范式设计和函数依赖分析虽然可以提高数据的一致性和完整性，但也会对数据库的性能和存储效率产生一定的影响。因此，在实际应用中，需要进行权衡和优化，以满足业务需求和性能要求。