第7章3数据库设计

1、第7章3数据库设计，数据库技术和应用第7章数据库设计(续2)，第7章3数据库设计，第6章数据库设计，6.1数据库设计概述6.2需求分析6.3概念结构设计6.4逻辑结构设计6.5数据库物理设计6.6数据库实现6.7数据库操作和维护6.8总结，第7章3数据库设计，6.4逻辑结构设计，逻辑结构设计的任务概念结构是各种数据模型的共同基础。为了满足用户对数据库管理系统的需求，概念结构必须进一步转化为相应的数据模型，这正是数据库逻辑结构设计要完成的任务。第7章：3数据库设计，6.4逻辑结构设计。逻辑结构设计的步骤是将概念结构转化为一般的关系、网格和层次模型，并将转化后的关系、网格和层次模型转化为特定数据库

2、管理系统支持的数据模型，以优化数据模型。6.4.1从电子关系图到关系模型的转换6.4.2到特定数据库管理系统模型的转换6.4.3数据模型的优化6.4.4用户子模式的设计，第7章3数据库设计，6.4.1从电子关系图到关系模型的转换，转换内容的原则，第7章3数据库设计，从电子关系图到关系模型的转换。关系模型的逻辑结构是一组关系模式。E-R图被转换成关系模型：实体、实体的属性和实体之间的关系被转换成关系模式。第7章：3数据库设计，从E-R图到关系模型的转换(续)，转换原理：一个实体被转换成一个关系模型。关系属性：实体类型属性关系代码：实体类型代码示例。学生实体可以转换为以下关系模式：学生(学号、姓名

3、、出生日期、系、年级、平均年级)、性别、宿舍、班级、档案材料、教师、课程、教室和教科书都分别转换为关系模式。第7章，第3节数据库设计，第7章，第3节数据库设计，从E-R图到关系模型的转换(续)，从m:n连接到关系模型的转换。关系属性：与连接相关联的每个实体的代码和连接本身的属性关系的代码：每个实体代码的组合示例，“选修”连接是一个1:n的连接，可以转换为以下关系模型，其中学生号和课程号是关系的组合代码：选修(学生号、课程号、成绩)，第7章，3数据库设计， 和从E-R图到关系模型的转换(续)1)属性转换成独立的关系模式关系：与关系相关联的实体的代码和关系本身的属性关系的代码：N端实体的代码，第7

4、章，3，数据库设计，以及从E-R图到关系模型的转换(续)。 2)与N端对应的关系模式合并后的关系的属性：将1端关系的代码和自身属性合并后的关系的代码添加到N端关系中：可以减少系统中的关系数量而不改变，这种方法一般比较好。第7章，3数据库设计，从E-R图到关系模型的转换(续)，例如，“组合”连接是1:n连接。有两种方法可以将它转换成关系模型：1)使它成为一个独立的关系模型：合成(学生人数，班级人数)2)合并它的学生关系模型：学生(学生人数，姓名，出生日期，系，年级，班级人数，平均成绩)，第7章，3，数据库设计，从E-R图到关系模型的转换(续)，1，1331)将关系的属性转化为独立的关系模式：与连

5、接相关联的每个实体的代码和连接本身的属性关系的候选代码：每个实体的代码是关系的候选代码，第7章，3数据库设计，从E-R图到关系模型的转换(续)，2)与关系模式合并后的关系的属性对应于某个端点：对应关系的代码和连接本身的属性合并后的关系的代码不变。第7章：3数据库设计，从E-R图到关系模型的转换(续)。例如，“管理”连接是1:1，有三种转换方法：(1)转换成一个独立的关系模型：管理(员工号，类号)或管理(员工号，类号)；(2)将“管理”连接与班级关系模型合并(学生人数、员工人数)(3)如果将“管理”连接与教师关系模型合并，只需将班级关系代码添加到教师关系中，即班级编号：教师：(员工人数、姓名、性

6、别、职称、班级编号、是否是优秀的班级教师)，第7章3数据库设计、E-R图转换到关系模型(续)，注意：在理论上，但是在某些情况下，与不同关系模型合并的效率会有很大不同。因此，这取决于应用程序的具体情况，关系模式的哪一方应该合并。因为连接操作是最耗时的操作，所以通常目标是最小化连接操作。例如，如果一个班级的班主任的名字经常被询问，最好将管理联系与教师关系结合起来。第7章：3数据库设计，从E-R图到关系模型的转换(续)，以及三个或更多实体之间的多重连接到关系模型的转换。关系属性：与多元连接相连的每个实体的代码和连接本身的属性关系的代码：每个实体代码的组合示例，“讲座”连接是一个三元连接，可以转换为以

7、下关系模式，其中课程编号、员工编号和图书编号是关系的组合代码：讲座(课程编号、员工编号、图书编号)，第7章第3节数据库设计，从E-R图到关系模型的转换(续)例如， 如果在教师实体集中的领导和领导之间存在1:n的自连接，我们可以合并与教师实体的连接。 这时，主要代码员工号会出现很多次，但其功能是不同的，所以可以用不同的属性名称来区分：教师：员工号、姓名、性别、职称、部门负责人、第7章、第3章数据库设计、E-R图到关系模型的转换(续)，以及与同一代码的关系目的：减少系统中的关系数量。合并方法：将一个关系模式的所有属性添加到另一个关系模式中，然后删除同义属性(可能同名也可能不同)，并适当调整属性的顺

8、序。，第7章3数据库设计，E-R图到关系模型的转换(续)，例如，“所有权”关系模型：所有权(学生人数，性别)和学生关系模型：学生(学生人数，姓名，出生日期，系，年级，班级人数，平均成绩)由学生人数编码，可以组合成一个关系模型：学生第7章3数据库设计，E-R图到关系模型的转换(续)，示例根据上述七个原则， 学生管理子系统中的18个实体和联系人可以转化为以下关系模型：学生(学号、姓名、性别、出生日期、系、年级、班级编号、平均年级、档案编号)性别(性别、宿舍)宿舍(宿舍编号、地址)学生人数教师(员工编号、姓名、性别、职称、班级编号、是否为优秀班主任)、第7章第3节数据库设计、从E-R图到关系模型的转

9、化(续)、教学(员工编号、学生编号)课程(课程编号、课程名称、 学分，教室号)选修教材(学生号，课程号，年级)图书号)档案材料(档案号)，第7: 3章数据库设计，E-R图到关系模型的转换(续)，它由12个关系模型组成。 其中，学生关系模式包括与“所有权”、“作文”和“归档”相对应的关系模式，教师关系模式包括与“管理”相对应的关系模式。宿舍关系模型包括对应“住宿”联系的关系模型；课程关系模式包括与“开放”接触相对应的关系模式。第7章3数据库设计，6.4逻辑结构设计，6.4.1电子关系图到关系模型的转换，6.4.2到特定数据库管理系统模型的转换，6.4.3数据模型的优化，6.4.4用户子模式的设计

10、，第7章3数据库设计，6.4.2到特定数据库管理系统模型的转换，通用数据模型也需要指定到特定数据库管理系统。转换的主要基础是所选数据库管理系统的功能和限制。没有一般的规则。对于关系模型，这种转换通常相对简单。第7章，3数据库设计，6.4逻辑结构设计，6.4.1从电子关系图到关系模型的转换，6.4.2到特定数据库管理系统模型的转换，6.4.3数据模型的优化，6.4.4用户子模式的设计，第7章，3数据库设计，6.4.3数据模型的优化，数据库逻辑设计的结果不是唯一的。在获得初步的数据模型之后，应该对数据模型的结构进行适当的修改和调整，以进一步提高数据库应用系统的性能，这就是数据模型的优化。关系数据模

11、型的优化通常以规范化理论为指导。第7: 3章数据库设计，数据模型优化(续)，优化数据模型的方法根据需求分析阶段确定数据依赖的语义，并分别写出每个关系模式中属性之间的数据依赖和不同关系模式中属性之间的数据依赖。第7章3数据库设计，数据模型优化(续)，例如，下列数据依赖关系存在于课程关系模型中：课程(课程编号，课程名称，学分，教室编号)课程名称课程编号学分课程编号教室编号下列数据依赖关系存在于选修关系模型中：(学生编号，课程编号)结果，第7章3数据库设计，学生(学生编号，姓名，性别，平均成绩，档案编号)在学生关系模型中有下列数据依赖关系：学生姓名， 学生编号、性别、出生日期、学生编号、系、年级、班

12、级、平均年级、文件编号、第7章3数据库设计、数据模型优化(续)、学生关系模型和选修关系模型之间的数据依赖关系：学生、学生编号选修、学生编号、第7章3数据库设计、数据模型优化(续)。第7章：3数据库设计、数据模型优化(续)，根据数据依赖理论，逐一分析关系模式，检查是否存在部分函数依赖、传递函数依赖、多值依赖等。并确定每个关系模式属于哪种范式。例如，经过分析，可以看出课程关系模型属于BC范式。第7章：3数据库设计，数据模型优化(续)。根据需求分析阶段得到的各种应用程序的数据处理需求，分析这些模型是否适合这样的应用环境，并决定是合并还是分解它们。第7章3数据库设计和数据模型优化(续)，并不是说标准化

13、程度越高，关系越好。当应用程序的查询中经常涉及两个或多个关系模式的属性时，系统必须经常执行连接操作，并且连接操作的成本相当高。可以说，关系模型效率低下的主要原因是做连接操作，所以在这种情况下，第二范式甚至第一范式可能是最好的。第7章：3数据库设计，数据模型优化(续)。虽然从理论上对非BCNF关系模式进行了分析，但会有不同程度的更新异常，但如果在实际应用中只查询关系模式而不执行更新操作，则不会产生实际影响。对于特定的应用，有必要权衡响应时间的优缺点和潜在问题，以确定标准化程度。一般来说，第三个范例就足够了。第7章3数据库设计，例如：在关系模型中，学生成绩单(学生人数，英语，数学，汉语，平均成绩)

14、有以下函数依赖关系：学生人数，英语学生人数，数学学生人数，中国学生人数，平均成绩(英语，数学，汉语)，第7章3数据库设计，数据模型优化(续)，显然有：学生人数(英语，数学，汉语，虽然平均成绩可以从其他属性计算，如果学生的平均成绩需要在应用中经常查询，为了提高效率，我们仍然可以保留冗余数据而不进一步分解关系第7章3数据库设计，数据模型优化(续)，根据需求分析阶段获得的各种应用对数据处理的要求，对关系模式进行必要的分解或合并，以提高数据操作的效率和存储空间的利用率。常用的分解方法有水平分解和垂直分解。第7章3数据库设计，数据模型优化(续)，水平分解什么是水平分解？将(基本)关系的元组分成若干子集，

15、并将每个子集定义为一个子集。水平分解的应用范围符合“80/20原则”。并发事务经常访问不相交的数据。第7章3数据库设计，数据模型优化(续)，符合“80/20原则”:在一个关系中，频繁使用的数据只是关系的一部分，约20%的人将频繁使用的数据分解成一个子关系。并发事务经常访问不相交的数据。如果关系R中有N个事务，并且大多数事务访问不相交的数据，则关系R可以分解成小于或等于N个子关系，这样每个事务访问的数据对应于一个关系。第7章3数据库设计，数据模型优化(续)，垂直分解什么是垂直分解？关系模式R的属性被分解成若干子集，形成若干子关系模式。垂直分解的原理：经常一起使用的属性从关系中分解出来，形成一个子

16、关系模式。第7章3数据库设计，数据模型优化(续)，垂直分解的优点可以提高一些事务的效率，而垂直分解的缺点可能会使其他事务不得不执行连接操作，从而降低效率。第7章3数据库设计和数据模型优化(续)，垂直分解的适用范围取决于分解后R上所有事务的总效率是否提高。垂直分解的方法很简单：直观的分解很复杂：垂直分解使用第5章中的模式分解算法一定不能失去关系模式的语义(保持无损co第7章，3数据库设计，6.4逻辑结构设计，6.4.1从E-R图到关系模型的转换，6.4.2到特定数据库管理系统指定的模型的转换，6.4.3数据模型的优化，6.4.4设计用户子模式，第7章，3数据库设计，6.4.4设计用户子模式，主要从系统的时间效率和空间效率来定义数据库模式在定义用户外模式时，我们应该更加注意用户的习惯和方便。它包括三个方面：第7、3章，数据库设计，用户子模式设计(续)；(1)将E-R图与更符合用户习惯的别名合并，完成了消除命名冲突的工作，从而使数据库系统中相同的关系和属性具有唯一的名称。在设计数据库的整体结构时，这是非常必要的。但是，对于一些本地应用程序来说，使用不符合用户习惯的属性名称可能会不方便。第7章，3数据库设计，设计用户子模式(续)，以及(1)使用更符合用户习惯的别名(续)。因此，在设计用户子模式时，可以重新定义一些属性名称，以使它们符合用户的习惯。当然，为了规范应用，我们