关系模式R
1.关系模式R(U,F)介绍
在数据库理论中，关系模式通常表示为 R(U, F)，其中：
● R 是关系的名称。
● U 是属性（或称属性集）的集合，这些属性构成了关系的模式（schema）。
● F 是属性之间的函数依赖集合，描述了属性之间的关系。
1.1自然连接 R><S
- 自然连接 R><S （两个关系模式R和S连接成新的关系模式）
自然连接是R和S关系中的元素之和, 自然连接不要重复元素
2.R(U,F)怎么确定主属性和非主属性
确定关系模式中的主属性和非主属性通常涉及到函数依赖和候选键的概念。
在数据库设计中，主属性指的是可以唯一标识元组的属性，而非主属性则是依赖于候选键而存在的其他属性。
● 下面是确定主属性和非主属性的一般步骤：
- 确定候选键： 首先，需要确定关系模式中的候选键。候选键是能够唯一标识关系中的元组的最小属性集合。可以通过分析函数依赖来确定候选键。通常，候选键是一个或多个属性的集合，其属性的值在整个关系中唯一。
- 确定主属性： 候选键中的属性被称为主属性。这些属性可以唯一标识关系中的元组。因此，候选键中的每个属性都是主属性。
- 确定非主属性： 非主属性是依赖于候选键而存在的其他属性。也就是说，非主属性的值由候选键中的属性决定。在确定候选键后，剩余的属性即为非主属性。
举例说明：
● 假设有一个关系模式 R 表示学生信息，包括学生姓名、年龄和所在班级，那么可以定义如下：
● 属性集合 U：{学号,姓名, 年龄, 班级}
● 函数依赖集合 F：{学号 -> 年龄, 学号 -> 班级, 学号 ->姓名 }
● 最后，将属性集合和函数依赖集合放在一起，即可构成给定的关系模式 R(U, F)，在设计数据库结构或进行相关分析时使用。
在这个例子中，学生学号是唯一标识学生的属性，因此它是主属性。而姓名、年龄和所在班级是依赖于学生学号的其他属性，因此它们是非主属性。
3.冗余
一般范式NF较小的都会存在冗余
- 数据冗余：数据中存在重复的信息或重复的存储方式。例如，在数据库中，同一信息可能存储在多个表中，导致数据冗余。
- 硬件冗余：系统中存在多个相同或相似的硬件组件，以提高系统的可靠性和容错性。例如，RAID（Redundant Array of Independent Disks）系统中的磁盘冗余，可以通过镜像或备份磁盘来保护数据不受硬件故障影响。
- 软件冗余：系统中存在相同或类似的软件模块或功能，以提高系统的可靠性、可用性或性能。例如，在分布式系统中使用冗余的服务节点来实现故障容错。
- 过程冗余：系统中存在相同或类似的处理流程或操作步骤，可能由于设计缺陷或历史原因而导致。消除过程冗余可以提高系统的效率和可维护性。
4.依赖(部分依赖,传递依赖,多值依赖)
在关系数据库中，关系模式R(U,F) 中的依赖是指数据之间存在的某种约束关系。
这里 U 是关系模式的属性集合，F 是依赖集合。依赖的理解和管理对于数据库的设计、优化以及规范化处理非常重要。
- 依赖的基本概念：依赖（Dependency）：在关系数据库中，依赖表示一种约束关系，说明一个或多个属性如何依赖于其他属性。依赖帮助维护数据一致性和完整性。
4.1部分依赖
部分依赖（Partial Dependency）指的是一个关系模式中的某个属性（或属性组合）依赖于候选键（Primary Key）的一部分，而不是全部。
- 举个例子，假设有一个关系模式 R(A, B, C)，其中 A 是候选键。如果属性 C 依赖于属性 A 和属性 B，而不仅仅是属性 A，那么就存在部分依赖。换句话说，C 只依赖于关系键的一部分，而不是全部。
- 部分依赖可能会导致数据库中的冗余数据和更新异常，因此在数据库设计中通常会尽量避免或规范化。通过将存在部分依赖的关系模式进行分解或重组，可以提高数据库的规范性和一致性。
4.2传递依赖
传递依赖（Transitive Dependency）是数据库设计中的一个概念，指的是一个关系模式中的某个属性（或属性组合）依赖于另一个非关系键属性，而这个非关系键属性又依赖于关系键。(关系键 = 候选键)
- 举个例子，假设有一个关系模式 R(A, B, C)，其中 A 是候选键。如果属性 C 依赖于属性 B，而属性 B 又依赖于属性 A，则存在依赖传递。换句话说，C 依赖于关系键的一部分 B，而 B 依赖于关系键 A。
- 依赖传递可能会导致数据库中的冗余数据和更新异常，因此在数据库设计中通常也会尽量避免或规范化。通过将存在依赖传递的关系模式进行分解或重组，可以提高数据库的规范性和一致性。
4.3多值依赖
多值依赖（Multivalued Dependency）是数据库设计中的一个概念，用来描述关系模式中多个属性之间的特定依赖关系。在一个关系模式中，如果存在一组属性 A 和另一组属性 B，使得对于每个 A 的取值，都存在多个 B 的取值与之对应，且这种对应关系与其他属性无关，那么就称属性 B 对属性 A 存在多值依赖。
- 举个例子，假设有一个关系模式 R(A, B, C)，其中 A 是关系键。如果对于每个 A 的取值，都存在多个 B 的取值与之对应，同时也存在多个 C 的取值与之对应，且这种对应关系与属性 B 和 C 无关，那么就存在 B 对 A 和 C 对 A 的多值依赖。
- 多值依赖的存在会导致数据库中的冗余数据和更新异常，因此在数据库设计中通常会尽量避免或规范化。通过将存在多值依赖的关系模式进行分解或重组，可以提高数据库的规范性和一致性。
5.关系模式判断NF(范式)
范式（Normalization Form，NF）是用来评估关系数据库设计是否合理、是否符合规范的标准。常见的范式包括1NF、2NF、3NF、BCNF、4NF等。
● 判断一个关系是否满足某个范式，通常需要检查以下几个方面：
- 第一范式（1NF）： 具有原子性:(关系中的每个属性都是原子的，不可再分的)。即每个属性都是不可再分的最小数据单元。例如，如果一个关系中有一个属性是多值属性，那么该关系就不满足第一范式。
- 第二范式（2NF）： 关系必须满足第一范式，并且非主属性完全依赖于候选键。这意味着关系中的每个非主属性都必须完全依赖于候选键，而不能存在部分依赖。
- 第三范式（3NF）： 关系必须满足第二范式，并且非主属性不传递依赖于候选键。这意味着关系中的每个非主属性都不能依赖于其他非主属性，即不能存在传递依赖。
- Boyce-Codd范式（BCNF）： 关系必须满足第三范式，并且每一个决定因素都是候选键。这意味着关系中的每个属性都是直接由整个候选键决定的，不存在对候选键的部分依赖。
- 第四范式（4NF）： 关系必须满足第三范式，并且没有多值依赖。
注意：某个关系模式R(U,F)存在部分依赖最多是1NF，即候选键有两个,关系中存在单个候选键推出非主属性（易混淆）
