数据库设计 - 概念和逻辑结构设计.pptx

1、第10讲 数据库设计 概念和逻辑结构设计,浙江大学宁波理工学院计算机系 肖 辉 ,数据库设计过程,数据库设计各阶段描述,10.1 概念结构设计,1976年P.P.S.Chen提出在逻辑结构 设计之前先设计一个概念模型，并提出了数据库设计的实体-联系方法Entity-Relationship Approach目前成为数据库设计中通用的工具,E-R模型设计工具,Sybase公司的PowerDesigner DataArchitect微软公司Microsoft InfoModeler (VisioModeler)ERWin,10.2 概念结构设计的方法与步骤,设计概念结构的四类方法 自顶向下首先定义

2、全局概念结构的框架，然后逐步细化自底向上首先定义各局部应用的概念结构，然后将它们集成起来，得到全局概念结构,设计概念结构的四类方法,逐步扩张首先定义最重要的核心概念结构，然后向外扩充，以滚雪球的方式逐步生成其他概念结构，直至总体概念结构 混合策略将自顶向下和自底向上相结合，用自顶向下策略设计一个全局概念结构的框架，以它为骨架集成由自底向上策略中设计的各局部概念结构。,自顶向下,自底向上,逐步扩张,概念结构设计的方法与步骤（续）,常用策略（P211图7.8） 自顶向下地进行需求分析 自底向上地设计概念结构自底向上设计概念结构的步骤（P211图7.9） 第1步：抽象数据并设计局部视图 第2步：集成

3、局部视图，得到全局概念结构,10.3 E-R图,基本符号实体的表示：用长方形 联系的表示：用菱形，1:1、1:n (m:1)、(m:n) 属性的表示：用椭圆形,10.4 E-R图设计,在数据分析的基础上，就可以着手设计概念结构。E-R图设计的步骤： 选择局部应用，设计局部分ER图 综合各局部E-R图，形成总的E-R图，消除冲突和冗余，得到基本ER图,10.4.1 设计局部分E-R图,需求分析阶段，已用多层数据流图和数据字典描述了整个系统。 设计分E-R图首先需要根据系统的具体情况，在多层的数据流图中选择一个适当层次的数据流图，让这组图中每一部分对应一个局部应用，然后以这一层次的数据流图为出发点

4、，设计分E-R图。,10.4.1 设计局部分E-R图,任务 标定局部应用中的实体、属性、码，实体间的联系 将各局部应用涉及的数据分别从数据字典中抽取出来，参照数据流图，标定各局部应用中的实体、实体的属性、标识实体的码，确定实体之间的联系及其类型（1:1，1:n，m:n）,设计局部分E-R图（2）,如何抽象实体和属性 实体：现实世界中一组具有某些共同特性和行为的对象就可以抽象为一个实体。对象和实体之间是“is member of“的关系。例：在学校环境中，可把张三、李四等对象抽象为学生实体。,设计局部分E-R图（3）,属性：对象类型的组成成分可以抽象为实体的属性。组成成分与对象类型之间是“is

5、part of“的关系。例：学号、姓名、专业、年级等可以抽象为学生实体的属性。其中学号为标识学生实体的码。,设计局部分E-R图（4）,如何区分实体和属性 实体与属性是相对而言的。同一事物，在一种应用环境中作为“属性”，在另一种应用环境中就必须作为“实体”。例：学校中的系，在某种应用环境中，它只是作为“学生”实体的一个属性，表明一个学生属于哪个系；而在另一种环境中，由于需要考虑一个系的系主任、教师人数、学生人数、办公地点等，这时它就需要作为实体了。,设计局部分E-R图（4）,确定实体与属性的原则 属性不能再具有需要描述的性质。即属性必须是不可分的数据项，不能再由另一些属性组成。 属性不能与其他实

6、体具有联系。联系只发生在实体之间。 凡能够作为属性对待的，应尽量作为属性,分E-R图设计实例,实例：P214,分E-R图设计实例1,例1：一个机械制造厂的简单管理系统。 首先按工厂技术部门和工厂供应部门设计两个局部E-R图。 工厂技术部门关心的是产品的性能参数，及由哪些零件组成，零件的材料和耗用量等； 工厂供应部门关心的是产品的价格，使用材料的价格及库存量等。,分E-R图设计实例2,实例：P214,10.4.2 局部视图集成,各个局部视图即分E-R图建立好后，还需要对它们进行合并，集成为一个整体的数据概念结构即总E-R图。,视图的集成方式,视图集成的两种方式 一次集成 一次集成多个分E-R图

7、通常用于局部视图比较简单时 逐步累积式 首先集成两个局部视图（通常是比较关键的两个局部视图） 以后每次将一个新的局部视图集成进来,视图的集成过程,一、合并分E-R图，生成初步E-R图,各分图存在冲突 各个局部应用所面向的问题不同由不同的设计人员进行设计各个分E-R图之间必定会存在许多不一致的地方 合并分E-R图的主要工作与关键所在：合理消除各分E-R图的冲突,合并分E-R图，生成初步E-R图（续）,冲突的种类 属性冲突 命名冲突 结构冲突, 属性冲突,两类属性冲突属性域冲突：属性值的类型、取值范围或取值集合不同。属性取值单位冲突。, 命名冲突,两类命名冲突 同名异义：不同意义的对象在不同的局部

8、应用中具有相同的名字异名同义：同一意义的对象在不同的局部应用中具有不同的名字命名冲突可能发生在属性级、实体级、联系级上。其中属性的命名冲突更为常见。, 结构冲突,三类结构冲突 同一对象在不同应用中具有不同的抽象例，“课程”在某一局部应用中被当作实体在另一局部应用中则被当作属性解决方法：通常是把属性变换为实体或把实体变换为属性，使同一对象具有相同的抽象。变换时要遵循两个准则。,结构冲突（续）,同一实体在不同局部视图中所包含的属性不完全相同，或者属性的排列次序不完全相同。 产生原因：不同的局部应用关心的是该实体的不同侧面。 解决方法：使该实体的属性取各分E-R图中属性的并集，再适当设计属性的次序。

9、,结构冲突（续）,实体之间的联系在不同局部视图中呈现不同的类型例1， 实体E1与E2在局部应用A中是多对多联系，而在局部应用B中是一对多联系例2， 在局部应用X中E1与E2发生联系，而在局部应用Y中E1、E2、E3三者之间有联系。解决方法：根据应用语义对实体联系的类型进行综合或调整。,初步ER图集成示例,二、修改与重构,基本任务 消除不必要的冗余，设计生成基本E-R图,修改与重构（续）,1什么是冗余 2消除冗余的方法,1冗余,冗余的数据是指可由基本数据导出的数据，冗余的联系是指可由其他联系导出的联系。 冗余数据和冗余联系容易破坏数据库的完整性，给数据库维护增加困难并不是所有的冗余数据与冗余联系

10、都必须加以消除，有时为了提高某些应用的效率，不得不以冗余信息作为代价。,冗余（续）,设计数据库概念结构时，哪些冗余信息必须消除，哪些冗余信息允许存在，需要根据用户的整体需求来确定。消除不必要的冗余后的初步E-R图称为基本E-R图。,2消除冗余的方法,分析方法 以数据字典和数据流图为依据，根据数据字典中关于数据项之间逻辑关系的说明来消除冗余。,消除冗余的方法(续),例，教师工资单中包括该教师的基本工资、各种补贴、应扣除的房租水电费以及实发工资。由于实发工资可以由前面各项推算出来，因此可以去掉，在需要查询实发工资时根据基本工资、各种补贴、应扣除的房租水电费数据临时生成。,消除冗余的方法（续）,如果

11、是为了提高效率，人为地保留了一些冗余数据，则应把数据字典中数据关联的说明作为完整性约束条件。一种更好的方法是把冗余数据定义在视图中,消除冗余的方法（续）,规范化理论1.确定分E-R图实体之间的数据依赖FL 。实体之间一对一、一对多、多对多的联系可以用实体码之间的函数依赖来表示。2. 求FL的最小覆盖GL ，差集为D = FL-GL。逐一考察D中的函数依赖，确定是否是冗余的联系，若是，就把它去掉。,三、验证整体概念结构,视图集成后形成一个整体的数据库概念结构，对该整体概念结构还必须进行进一步验证，确保它能够满足下列条件： 整体概念结构内部必须具有一致性，不存在互相矛盾的表达。 整体概念结构能准确

12、地反映原来的每个视图结构，包括属性、实体及实体间的联系。 整体概念结构能满足需要分析阶段所确定的所有要求。,验证整体概念结构（续）,整体概念结构最终还应该提交给用户，征求用户和有关人员的意见，进行评审、修改和优化，然后把它确定下来，作为数据库的概念结构，作为进一步设计数据库的依据。,基本ER图示例,概念结构设计小结,1. 根据局部应用，设计分E-R图（确定实体和属性的原则）2. 将局部分E-R图集成，形成总的初步E-R图3. 消除数据和联系的冗余，设计基本E-R图,10.5 逻辑结构设计,逻辑结构设计的任务 概念结构是各种数据模型的共同基础 为了能够用某一DBMS实现用户需求，还必须将概念结构

13、进一步转化为相应的数据模型，这正是数据库逻辑结构设计所要完成的任务。,10.5 逻辑结构设计,10.5.1 E-R图向关系模型的转换 10.5.2 向特定DBMS规定的模型进行转换 10.5.3 数据模型的优化 10.5.4 设计用户子模式,10.5.1 E-R图向关系模型的转换,转换内容 转换原则,E-R图向关系模型的转换（续）,转换内容 E-R图由实体、实体的属性和实体之间的联系三个要素组成 关系模型的逻辑结构是一组关系模式的集合 将E-R图转换为关系模型：将实体、实体的属性和实体之间的联系转化为关系模式。,E-R图向关系模型的转换（续）,转换原则 一个实体型转换为一个关系模式。 关系的属

14、性：实体型的属性 关系的码：实体型的码,例，学生实体可以转换为如下关系模式：学生（学号，姓名，出生日期，所在系，年级，平均成绩）性别、宿舍、班级、档案材料、教师、课程、教室、教科书都分别转换为一个关系模式。,E-R图向关系模型的转换（续）, 一个m:n联系转换为一个关系模式。 关系的属性：与该联系相连的各实体的码以及联系本身的属性 关系的码：各实体码的组合例，“选修”联系是一个m:n联系，可以将它转换为如下关系模式，其中学号与课程号为关系的组合码：选修（学号，课程号，成绩）,E-R图向关系模型的转换（续）, 一个1:n联系可以转换为一个独立的关系模式，也可以与n端对应的关系模式合并。1) 转换

15、为一个独立的关系模式 关系的属性：与该联系相连的各实体的码以及联系本身的属性 关系的码：n端实体的码,E-R图向关系模型的转换（续）,2) 与n端对应的关系模式合并 合并后关系的属性：在n端关系中加入1端关系的码和联系本身的属性 合并后关系的码：不变 可以减少系统中的关系个数，一般情况下更倾向于采用这种方法,E-R图向关系模型的转换（续）,例，“组成”联系为1:n联系。将其转换为关系模式的两种方法：1)使其成为一个独立的关系模式：组成（学号，班级号）2)将其学生关系模式合并：学生（学号，姓名，出生日期，所在系，年级，班级号，平均成绩）,E-R图向关系模型的转换（续）, 一个1:1联系可以转换为

16、一个独立的关系模式，也可以与任意一端对应的关系模式合并。 1) 转换为一个独立的关系模式 关系的属性：与该联系相连的各实体的码以及联系本身的属性 关系的候选码：每个实体的码均是该关系的候选码,E-R图向关系模型的转换（续）,2) 与某一端对应的关系模式合并 合并后关系的属性：加入对应关系的码和联系本身的属性 合并后关系的码：不变,E-R图向关系模型的转换（续）,例，“管理”联系为1:1联系，可以有三种转换方法：（1）转换为一个独立的关系模式：管理（职工号，班级号）或 管理（职工号，班级号）（2）“管理”联系与班级关系模式合并，则只需在班级关系中加入教师关系的码，即职工号：班级：（班级号，学生人

17、数，职工号）（3）“管理”联系与教师关系模式合并，则只需在教师关系中加入班级关系的码，即班级号：教师：（职工号，姓名，性别，职称，班级号）,E-R图向关系模型的转换（续）,注意： 从理论上讲，1:1联系可以与任意一端对应的关系模式合并。 但在一些情况下，与不同的关系模式合并效率会大不一样。因此究竟应该与哪端的关系模式合并需要依应用的具体情况而定。 由于连接操作是最费时的操作，所以一般应以尽量减少连接操作为目标。例如，如果经常要查询某个班级的班主任姓名，则将管理联系与教师关系合并更好些。,E-R图向关系模型的转换（续）, 三个或三个以上实体间的一个多元联系转换为一个关系模式。 关系的属性：与该多

18、元联系相连的各实体的码以及联系本身的属性 关系的码：各实体码的组合例，“讲授”联系是一个三元联系，可以将它转换为如下关系模式，其中课程号、职工号和书号为关系的组合码：讲授（课程号，职工号，书号）,E-R图向关系模型的转换（续）, 同一实体集的实体间的联系，即自联系，也可按上述1:1、1:n和m:n三种情况分别处理。例，如果教师实体集内部存在领导与被领导的1:n自联系，我们可以将该联系与教师实体合并，这时主码职工号将多次出现，但作用不同，可用不同的属性名加以区分：教师：职工号，姓名，性别，职称，系主任,E-R图向关系模型的转换（续）, 具有相同码的关系模式可合并。 目的：减少系统中的关系个数。

19、合并方法：将其中一个关系模式的全部属性加入到另一个关系模式中，然后去掉其中的同义属性（可能同名也可能不同名），并适当调整属性的次序。,E-R图向关系模型的转换（续）,例，“拥有”关系模式：拥有（学号，性别） 与学生关系模式：学生（学号，姓名，出生日期，所在系，年级，班级号，平均成绩） 都以学号为码，可以将它们合并为一个关系模式：学生（学号，姓名，性别，出生日期，所在系，年级，班级号，平均成绩）,ER图转换示例,m:n 联系转换,弱实体,同一型实体上的联系,10.5 逻辑结构设计,10.5.1 E-R图向关系模型的转换 10.5.2 向特定DBMS规定的模型进行转换 10.5.3 数据模型的优化

20、 10.5.4 设计用户子模式,10.5.2 向特定DBMS规定的模型进行转换,一般的数据模型还需要向特定DBMS规定的模型进行转换。转换的主要依据是所选用的DBMS的功能及限制。没有通用规则。对于关系模型来说，这种转换通常都比较简单。,10.5 逻辑结构设计,10.5.1 E-R图向关系模型的转换 10.5.2 向特定DBMS规定的模型进行转换 10.5.3 数据模型的优化 10.5.4 设计用户子模式,10.5.3 数据模型的优化,数据库逻辑设计的结果不是唯一的。 得到初步数据模型后，还应该适当地修改、调整数据模型的结构，以进一步提高数据库应用系统的性能，这就是数据模型的优化。 关系数据模

21、型的优化通常以规范化理论为指导。,数据模型的优化（续）,优化数据模型的方法 确定数据依赖 按需求分析阶段所得到的语义，分别写出每个关系模式内部各属性之间的数据依赖以及不同关系模式属性之间数据依赖。,数据模型的优化（续）,例，课程关系模式内部存在下列数据依赖：课程号课程名课程号学分课程号教室号选修关系模式中存在下列数据依赖：（学号，课程号）成绩,数据模型的优化（续）,学生关系模式中存在下列数据依赖：学号姓名 学号性别学号出生日期 学号所在系学号年级 学号班级号学号平均成绩 学号档案号学生关系模式的学号与选修关系模式的学号之间存在数据依赖：学生.学号选修.学号,数据模型的优化（续）, 对于各个关系

22、模式之间的数据依赖进行极小化处理，消除冗余的联系。 按照数据依赖的理论对关系模式逐一进行分析，考查是否存在部分函数依赖、传递函数依赖、多值依赖等，确定各关系模式分别属于第几范式。,数据模型的优化（续）, 按照需求分析阶段得到的各种应用对数据处理的要求，分析对于这样的应用环境这些模式是否合适，确定是否要对它们进行合并或分解。,数据模型的优化（续）,并不是规范化程度越高的关系就越优 连接运算不要太过频繁，花费代价最高.所以有时2NF甚至1NF也能满足需求 非BCNF范式存在更新异常，实际上有些表只需查询，很小甚至无需更新 规范化理论的应用一定要和实际应用结合在一起。一般来说，3NF is enou

23、gh.,数据模型的优化（续）,例：在关系模式学生成绩单(学号,英语,数学,语文,平均成绩) 中存在下列函数依赖：学号英语学号数学学号语文学号平均成绩(英语, 数学, 语文)平均成绩,数据模型的优化（续）,显然有：学号(英语,数学,语文)因此该关系模式中存在传递函数信赖，是2NF关系。虽然平均成绩可以由其他属性推算出来，但如果应用中需要经常查询学生的平均成绩，为提高效率，我们仍然可保留该冗余数据，对关系模式不再做进一步分解。,关系模式分解,关系模式分解的常用方法 水平分解 把(基本)关系的元组分为若干子集合，定义每个子集合为一个子关系，以提高系统的效率。 垂直分解,关系模式分解（续）,水平分解的

24、适用范围 1. 满足“80/20原则”的应用 80/20原则：一个大关系中，经常被使用的数据只是关系的一部分，约20% 把经常使用的数据分解出来，形成一个子关系，可以减少查询的数据量。,关系模式分解（续）,水平分解的适用范围 2. 并发事务经常存取不相交的数据 如果关系R上具有n个事务，而且多数事务存取的数据不相交，则R可分解为少于或等于n个子关系，使每个事务存取的数据对应一个关系。,关系模式分解（续）,垂直分解 把关系模式R的属性分解为若干子集合，形成若干子关系模式。 垂直分解的原则 经常在一起使用的属性从R中分解出来形成一个子关系模式。,数据模型的优化（续）,垂直分解的优点 可以提高某些事

25、务的效率垂直分解的缺点 可能使另一些事务不得不执行连接操作，从而降低了效率。,数据模型的优化（续）,垂直分解的适用范围 取决于分解后R上的所有事务的总效率是否得到了提高。 进行垂直分解的方法 简单情况：直观分解 复杂情况：用第五章中的模式分解算法 垂直分解必须不损失关系模式的语义(保持无损连接性和保持函数依赖)。,10.5 逻辑结构设计,10.5.1 E-R图向关系模型的转换 10.5.2 向特定DBMS规定的模型进行转换 10.5.3 数据模型的优化 10.5.4 设计用户子模式,10.5.4 设计用户子模式,定义数据库模式主要是从系统的时间效率、空间效率、易维护等角度出发。定义用户外模式时

26、应该更注重考虑用户的习惯与方便。包括三个方面： (1) 使用更符合用户习惯的别名 (2) 针对不同级别的用户定义不同的外模式，以满足系统对安全性的要求。 (3) 简化用户对系统的使用,设计用户子模式（续）,(1) 使用更符合用户习惯的别名 合并各分E-R图曾做了消除命名冲突的工作，以使数据库系统中同一关系和属性具有唯一的名字。这在设计数据库整体结构时是非常必要的。 但对于某些局部应用，由于改用了不符合用户习惯的属性名，可能会使他们感到不方便，,设计用户子模式（续）,(1) 使用更符合用户习惯的别名(续) 因此在设计用户的子模式时可以重新定义某些属性名，使其与用户习惯一致。例：负责学籍管理的用户

27、习惯于称教师模式的职工号为教师编号。因此可以定义视图，在视图中职工号重定义为教师编号,设计用户子模式（续）,(2) 针对不同级别的用户定义不同的外模式，以满足系统对安全性的要求。,设计用户子模式（续）,例：教师关系模式中包括职工号、姓名、性别、出生日期、婚姻状况、学历、学位、政治面貌、职称、职务、工资、工龄、教学效果等属性。学籍管理应用只能查询教师的职工号、姓名、性别、职称数据；课程管理应用只能查询教师的职工号、姓名、性别、学历、学位、职称、教学效果数据；教师管理应用则可以查询教师的全部数据。,设计用户子模式（续）,定义两个外模式： 教师_学籍管理(职工号，姓名，性别，职称) 教师_课程管理(

28、工号，姓名，性别，学历，学位，职称，教学效果) 授权学籍管理应用只能访问教师_学籍管理视图 授权课程管理应用只能访问教师_课程管理视图 授权教师管理应用能访问教师表 这样就可以防止用户非法访问本来不允许他们查询的数据，保证了系统的安全性。,设计用户子模式（续）,(3) 简化用户对系统的使用 如果某些局部应用中经常要使用某些很复杂的查询，为了方便用户，可以将这些复杂查询定义为视图。,逻辑结构设计小结(1),E-R图向关系模型的转换原则 一个实体型转换为一个关系模式。 一个m:n联系转换为一个关系模式。 一个1:n联系可以转换为一个独立的关系模式，也可以与n端对应的关系模式合并。 一个1:1联系可以转换为一个独立的关系模式，也可以与任意一端对应的关系模式合并。,逻辑结构设计小结(2),E-R图向关系模型的转换原则 三个或三个以上实体间的一个多元联系转换为一个关系模式。 同一实体集的实体间的联系，即自联系，也可按上述1:1、1:n和m:n三种情况分别处理。 具有相同码的关系模式可合并。,