关系型数据库及其设计方法

2.2.4关系型数据库规范化分析
• 1．1NF:如果一个关系R的所有属性都是不可分 的基本数据项，则R∈1NF。任何一个关系模式 都是1NF，不满足第一范式的数据库模式不能称 为关系数据库。 • 2．2NF:若关系R∈lNF，并且每一个非主属性 都完全依赖于R的主码，则R∈ 2NF。 • 3．3NF:若关系R∈2NF，并且每一个非主属 性不传递依赖于R的主码，则R∈3NF。
选择
• 选择是在关系R中选择满足给定条件的诸元 组 • 是从行的角度进行的运算
σ
投影
• 关系R上的投影是从R中选择出若干属性列 组成新的关系。 • 是从列的角度进行的运算
π
连接
• 连接（Join） 是将两个和多个关系连接在一起，形成一个新的关 系。连接运算是按照给定条件，把满足条件的各 关系的所有元组，按照一切可能组合成新的关系。 或者说，连接运算的结果是在两关系的笛卡尔积 上的选择。记作：
• 自然连接：当连接的两关系有相同的属性名时， 称这种连接为自然连接，它是连接的一个特例。 记作：
连接
• 等值连接：它是从关系R与S的笛卡尔积中 选取条件为A、B属性值相等的那些元组
R
S
AθB
2.2 关系型数据库基本概念
2.2.1关系型数据库定义 2.2.2数据完整性 2.2.3表间关联 2.2.4关系型数据库规范化分析
2.3.2 需求分析
• 进行数据库设计首先必须准确了解与分析 用户需求（包括数据与处理）。需求分析 是整个设计过程的基础，是最困难、最耗 费时间的一步。需求分析的结果是否准确 地反映了用户的实际要求，将直接影响到 后面各个阶段的设计，并影响到设计结果 是否合理和实用。
2.3.3 概念设计
• 将需求分析的结果综合为一个统一的概念 模型。首先根据单个应用的需求，画出能 反映每一个应用需求的局部E-R模型。然 后把这些模型合并起来，消除冗余和可能 存在的矛盾，得到系统的E-R模型。
2.2.4关系型数据库规范化分析
• 关系模式的规范化 1．范式（Normal form） 范式：建立关系时需要满足的约束条件划分成若干标准， 这些标准称为范式，简写为 NF。范式的级别越高，发 生操作异常的可能性越小，数据冗余越小，但由于关联 多，读取数据时花费时间也会相应增加。 2．第一范式（1NF） • 对于给定的关系 R，如果 R 中的所有行、列交点处的值 都是不可再分的数据项，则称关系R属于第一范式，记 作：R∈1NF。 • 1NF是关系数据库中对关系的最低要求，它是从关系的 基本性质而来的，任何关系必须遵守。
R×S
a 1 1 b 2 2 c 3 3 a 1 0 b 2 0 c 3 0
1 4
4 4 7 7 7
2 5
5 5 8 8 8
3 6
6 6 9 9 9
7 1
0 7 1 0 7
8 2
0 8 2 0 8
9 3
0 9 3 0 9
2.1.3 专门的关系运算
• • • • 1．选择 2．投影 3．连接 4．除
2.3 关系型数据库设计方法
• • • • • • 2.3.1 数据库设计方法概述 2.3.2 需求分析 2.3.3 概念设计 2.3.4 逻辑设计 2.3.5 物理设计 2.3.6 数据库的实施与维护
2.3.1 数据库设计方法概述
• 数据库设计分为六个阶段：需求分析、概 念结构设计、逻辑结构设计、物理设计、 数据库实施和数据库运行维护。
2.2.4关系型数据库规范化分析
3．第二范式（2NF） • 如果关系 R∈1NF，并且 R 的每一个非主属性都决定于 主键，则称R属于第二范式，记作：R∈2NF。 • 思考：主键没有冗余，非主键存在冗余。 4．第三范式（3NF） • 第三范式：如果关系R∈2NF，并且R的每一个非主属 性都不间接决定于主键，则称R属于第三范式，记作： R∈3NF。 • 达到第三范式的关系仍有可能存在冗余等问题，所以关 系数据库理论还有BCNF、4NF、5NF等范式。在实 际应用中，一般达到了3NF的关系就可以认为是较为优 化的关系。
a
b
1
0 7
2
0 8
3
0 9
7
8
9
差
• 关系R与关系S的差由 属于R而不属于S的所 有元组组成。其结果 关系仍为n目关系。记 作R-S
R S R-S
a b c 4 5 6 c
a 1 4
b 2 5
c 3 6
a
b
1
0 7
2
0 8
3
0 9
7
8
9
广义笛卡尔积
• 两个分别为n目和m目的关系R和S的广义 笛卡尔积是一个(n+m)列的元组的集合。 元组的前n列是关系R的一个元组，后m列 是关系S的一个元组。若R有A1个元组，S 有A2个元组，则关系R和关系S的广义笛 卡尔积有Al×A2个元组。记作R×S
图2.1
纵的一列称为一个属性（字段），表头 给出属性名（字段名）
横的一行称为一个元组（记录）
2.1.2 传统的集合运算
• • • • 1．并 2．交 3．差 4．广义笛卡尔积
R S
a 1 4
b 2 5
c 3 6
a
b
c
1
0 7
2
0 8
3
0 9
7
8
9
并
• 关系R与关系S的并由 属于R或属于S的元组 组成，其结果关系仍 为n目关系。记作R∪ S
2.2.3表间关联
1．一对一关联（one-to-one） 设在一个关系型数据库中有A、B两表，对于表A中的任何一条 记录，表B中只能有一条记录与之对应；反过来，对于表B中 的任何一条记录，表A中也只能有一条记录与之对应，则称这 两个表是一对一的关联。一对一关联是通过主码来实现的。 2．一对多关联（one-to-many） 设在一个关系型数据库中有A、B两表，对于表A中的任何一条 记录，表B中可能有多条记录与之对应；反过来，对于表B中 的任何一条记录，表A中却只能有一条记录与之对应，则称这 两个表是一对多的关联。 3．多对多关联（many-to-many） 设在一个关系型数据库中有A、B两表，对于表A中的任何一条 记录，表B中可能有多条记录与之对应；反过来，对于表B中 的任何一条记录，表A中也有多条记录与之对应，则称这两个 表是多对多的关联。
2.2.4关系型数据库规范化分析
5 关系分解的原则 • 关系的规范化就是将关系按照一定的原则不断地分解为 多个关系的过程，通过分解使关系逐步达到较高范式。 任何一个非规范化的关系经过分解都可以达到3NF。 • 在实际应用中，数据库设计人员应根据具体情况灵活掌 握，千万不要盲目追求规范化的程度。 关系分解的基本原则是： • 关系分解后必须可以无损连接的。 • 分解后的关系要相互独立。
2.2.1关系型数据库定义
• 关系型数据库 是指一些相关的表和其他数 据库对象，例如视图、存储过程和索引等的 集合。在关系型数据库中，信息存放在二维 表中，一个关系型数据库包含多个二维表。 关系型数据库所包含的表之间是有关联的， 关联主要由主码和外码所体现的参照关系实 现。
2.2.2数据完整性
数据完整性用于保证关系型数据库中数据的正确性和可靠性。
2.3.4 逻辑设计
• 将E-R模型转换为所选用的DBMS支持的 数据模型。对于关系数据库，主要是完成 表的关联和结构设计。
2.3.5 物理设计
• 数据库物理设计是为逻辑数据模型选取一 个最适合应用环境的物理结构（包括存储 结构和存取方法）。
2.3.6 数据库的实施与维护
• 在数据库实施阶段，设计人员运用DBMS提供 的数据语言及其宿主语言，根据逻辑设计和物理 设计的结果建立数据库，编制与调试应用程序， 组织数据入库，并进行试运行。 • 数据库应用系统经过试运行后即可投入正式运行。 在数据库系统运行过程中必须不断地对其进行评 价、调整与修改。在数据库的运行阶段，对数据 库经常性的维护工作主要是由DBA完成的，它 包括：数据库的转储和恢复、数据库的安全性和 完整性控制、数据库性能的监督和分析改造、数 据库的重新组织与重构。
2.1.1 基本概念
• 1．关系：一个关系对应一张二维表，图2.1中的这张学 生信息表就是一个关系。 • 2．元组：表中的一行即为一个元组（也称为一条记 录）。 • 3．属性：表中的一列即为一个属性，图2.1有6列，对 应6个属性，给每个属性起一个名字即属性名，例如stud ent_id即为第一列的属性名。 • 4．码（key）：表中的某个属性（组），它可以惟一 确定一个元组，则称该属性组为“侯选码”。若一个关 系有多个候选码，则选定其中一个为主码。如图2.1中 的student_id（学号），是该学生关系的码，并且是主 码。 • 5．域（domain）：属性的取值范围，如图2.1中学 生性别的域是(男,女)。
1．实体完整性（Entity Integrity）:实体完整性用来保证关系数据库表中 的每一条记录都是唯一的。 实体完整性规则：若属性A是基本关系R的主属性，则属性A不能取空值。 2．域完整性（Domain Integrity）:域完整性用于属性的取值在有效的范 围内。 3．参照完整性（Referential Integrity） 参照完整性用于确保相关联的表间的数据保持一致。当进行增加、删除 和修改关系型数据库表中的记录时，必须借助参照完整性来保证相关联的表 之间数据的一致性。 4．用户自定义完整性（User-defined Integrity） 实体完整性和参照完整性适用于任何关系数据库系统。除此之外，不同 的关系数据库系统根据其应用环境的不同，往往还需要一些特殊的约束条件。 用户自定义的完整性就是针对某一具体关系数据库的约束条件，它反映某一 具体应用所涉及的数据必须满足的语义要求。
2.2.4关系型数据库规范化分析
问题的提出 在设计关系数据库时，经常采用一种自下而上的设 计方法。这种方法是对涉及的所有数据进行收集， 然后按照栏目进行归纳分类。 • 插入异常： • 删除异常： • 数据冗余： 解决这些问题的办法就是重新设计数据库。