数据库物理设计.ppt

第六章 数据库设计,第六章 数据库设计,6.1 数据库设计概述6.2 需求分析6.3 概念结构设计6.4 逻辑结构设计6.5 数据库的物理设计6.6 数据库实施6.7 数据库运行与维护6.8 小结,6.1数据库设计的步骤（1）,目前主要采用以逻辑数据库设计和物理数据库设计为核心的规范设计方法。逻辑数据库设计-设计全局逻辑结构和每个用户的局部逻辑结构，将概念结构转换为某个DBMS支持的数据模型并优化物理数据库设计-为逻辑数据模型选一个最适合应用环境的物理结构，设计数据库的存储结构、存取方法及其他实现细节,6.1数据库设计的步骤（2）,选定参加设计的人员：数据库分析设计人员-核心，自始至终用户-重要，需求分析(头)，运行和维护(尾)程序员-编制程序操作员-准备软硬件环境,数据库设计过程图,需求分析,概念结构设计,数据库实施,数据库运行和维护,逻辑结构设计,数据库物理设计,6.2需求分析6.2.1任务,重点是调查、收集与分析用户在数据管理中的信息要求、处理要求、安全性和完整性要求信息要求-用户需从库中获得信息的内容和性质，存储哪些信息于库中处理要求-要求完成的功能、响应时间、方式是批处理还是联机处理,6.2需求分析6.2.1任务,困难在：用户缺少计算机知识，无法准确表达自己的需求，需求往往不断变化设计人员缺乏用户的专业知识，不易理解甚至误解用户的需求。软硬件技术的出现会使用户需求发生变化,6.2需求分析6.2.2需求分析的方法（1）,调查与初步分析用户需求需四步：调查组织机构情况：部门组成、职责，为分析信息流程做准备调查各部门业务活动情况：输入和使用什么数据，如何加工处理这些数据，输出什么信息、到哪里、输出结果的格式协助用户明确对新系统的要求确定新系统边界，哪些是计算机完成的功能,6.2需求分析6.2.2需求分析的方法（2）,常用的调查方法：跟班作业开调查会-用户彼此启发请专人介绍询问-专人设计调查表请用户填写查阅记录-与原系统有关的数据记录,6.2需求分析,分析和表达用户需求的方法主要包括：自顶向下（SA）和自底向上方法自顶向下（SA）方法从最上层的系统组织机构入手，采用逐层分解的方式分析系统，并用数据流图和数据字典描述系统用SA方法做需求分析，设计人员需要把任何一个系统都抽象为如下形式,数据存储 数据流 数据流 数据来源 处理 数据输出,然后将处理功能分解，不停分解，直至系统工作过程被表达清楚；数据也逐级分解，形成若干层次的数据流图。数据流图表达了数据和处理过程的关系数据借助数据字典描述处理过程的处理逻辑借助判定表或判定树来描述,实例：开发学校管理系统,高层数据流图,管理信息系统,教师管理子系统,后勤管理子系统,学生管理子系统,课程管理,学籍管理,实例（续）,学生管理子系统的主要功能：学籍管理和课程管理。包括：学生报到、入学、毕业、上课情况管理。通过详细的信息流程分析和数据收集后，生成该系统的数据流图。见188-189,6.3概念结构设计 6.3.1概念结构设计方法与步骤,概念结构设计-将需求分析得到的用户需求抽象为概念模型的过程概念结构独立于数据库逻辑结构，也独立于DBMS四类方法：自顶向下自底向上经常采用。即自顶向下进行需求分析，再自底向上设计概念结构。逐步扩张-先定义核心概念，然后向外扩充混合策略,6.3.2分E-R图设计（1）,在多层数据流图中选择一个适当层次的数据流图，让每一部分对应一个局部应用，因为中层的数据流图能较好地反映系统中各局部应用的子系统组成，所以一般作为分E-R图的依据参照数据流图，标定局部应用中的实体、实体的属性、标识实体的码，确定实体之间的联系及其类型。,6.3.2设计分E-R图（2）,现实世界中一组具有共同特性和行为的对象可抽象为一个实体，例，张三、李斯、王五可抽象为学生实体对象的组成成分可抽象为实体的属性，例，学号、姓名、年级等可抽象为学生实体的属性，其中学号为标识实体的码实体与属性很难划分界限。例，系是学生实体的属性，在需要考虑系主任、教师人数、学生人数、办公地点时就需要作为实体了。,6.3.2设计分E-R图（3）,属性和实体区别的原则：属性不能再具有需要描述的性质。即为不可再分的数据项属性不能与其他实体具有联系。联系只能发生在实体之间。能做属性对待尽量作属性。,“职称”分别作为实体和属性,教师,教师,职称,住房,姓名,职称,性别,性别,姓名,评定,分配,学籍管理分E-R图草图,班主任,班级,档案材料,学生,宿舍,教室,管理,指导,归档,住宿,组成,上课,对学籍管理E-R草图调整,一般，性别应作为学生实体的属性，本应用中由于宿舍分配与性别有关，依据准则2-属性不能与其他实体有联系，性别应作为实体对待数据存储“学生登记表”由手工完成，有用部分转入学生档案材料中，因此这里不必作为实体。,学籍管理分E-R图草图调整后,班主任,班级,档案材料,学生,宿舍,教室,管理,指导,归档,住宿,组成,上课,性别,拥有,课程管理的E-R图,教室,课程,教师,教科书,学生,开设,教学,讲授,选修,成绩,6.3.3E-R图的集成（1）,不同设计人员进行局部视图设计，这导致各分E-R图之间存在许多不一致的地方，因此着力消除冲突是主要工作与关键所在1.属性冲突-讨论协商解决属性域冲突：属性值的类型、取值范围、取值集合不同属性取值单位冲突,6.3.3E-R图的集成（2）,2.命名冲突-讨论协商解决同名异义异名同义3.结构冲突同一对象在不同应用中具有不同的抽象-例，“课程”在某一局部应用中当作实体，另一局部应用中当作属性解决办法：使同一对象有相同的抽象，遵守前面的属性原则,6.3.3E-R图的集成（3）,3.结构冲突同一实体在不同E-R图中所包含的属性不完全相同，或排列次序不完全相同解决办法：取分 E-R图的并集，再适当设计属性的次序实体间联系在不同视图中呈现不同类型解决办法：根据应用的语义对实体联系的类型进行综合或调整,学籍管理与课程管理E-R图的合并,存在的冲突：1.班主任也属于教师，两图存在异名同义，统一为教师实体，属性构成为：教师职工号，姓名，性别，职称，优秀班主任否2.班主任改为教师后，教室和学生之间的联系为两类，因为“指导”包含在“教学”中，所以综合为教学联系3.性别在学籍管理为实体，在课程管理中为属性，合并后只能作为实体，否则无法与宿舍实体发生联系4.二者中学生实体属性组成及次序都存在差异，应将所有属性综合并重新调整次序。,6.3.3E-R图的修改与重构（1）,修改与重构-消除不必要的冗余信息,生成基本E-R图冗余数据-可由基本数据导出冗余的实体间联系-可由其它联系导出冗余信息易破坏数据库的完整性，给数据维护增加困难，但有时为了提高某些应用的效率不得不以冗余信息为代价。,6.3.3E-R图的修改与重构（2）,消除冗余主要采用分析方法，例如教师工资单里的实发工资，可以推算消除冗余还可采用规范化理论例，学生实体的年龄可由生日推算，属冗余数据教室实体与班级实体的上课联系可由教室与课程间的开设联系、课程与学生间的选修联系、学生与班级之间的组成联系推导出来，属于冗余联系学生实体中平均成绩可由选修联系中的成绩属性推算，但经常查询，为维护数据一致性，应设置触发器,整体概念结构（总E-RT图）必须验证,整体概念结构内部必须具有一致性整体概念结构能准确反映原来的每个视图结构整体概念结构能满足需求分析阶段所确定的所有要求,6.4 逻辑结构设计,逻辑结构设计的任务概念结构是各种数据模型的共同基础为了能够用某一DBMS实现用户需求，还必须将概念结构进一步转化为相应的数据模型，这正是数据库逻辑结构设计所要完成的任务。,6.4 逻辑结构设计,逻辑结构设计的步骤将概念结构转化为一般的关系、网状、层次模型将转化来的关系、网状、层次模型向特定DBMS支持下的数据模型转换对数据模型进行优化,6.4 逻辑结构设计,6.4.1 E-R图向关系模型的转换6.4.2 向特定DBMS规定的模型进行转换6.4.3 数据模型的优化6.4.4 设计用户子模式,6.4.1 E-R图向关系模型的转换,转换内容转换原则,E-R图向关系模型的转换（续）,转换内容E-R图由实体、实体的属性和实体之间的联系三个要素组成关系模型的逻辑结构是一组关系模式的集合将E-R图转换为关系模型：将实体、实体的属性和实体之间的联系转化为关系模式。,E-R图向关系模型的转换（续）,转换原则 一个实体型转换为一个关系模式。关系的属性：实体型的属性关系的码：实体型的码例，学生实体可以转换为如下关系模式：学生（学号，姓名，出生日期，所在系，年级，平均成绩）性别、宿舍、班级、档案材料、教师、课程、教室、教科书等实体都分别转换为一个关系模式。,E-R图向关系模型的转换（续）,一个m:n联系转换为一个关系模式。关系的属性：与该联系相连的各实体的码以及联系本身的属性关系的码：各实体码的组合例，“选修”联系是一个m:n联系，可以将它转换为如下关系模式，其中学号与课程号为关系的组合码：选修（学号，课程号，成绩）,学生 选修 成绩 课程学生的码为学号，课程的码为课程号，选修的属性为成绩,E-R图向关系模型的转换（续）,一个1:n联系可以转换为一个独立的关系模式，也可以与n端对应的关系模式合并。1)转换为一个独立的关系模式关系的属性：与该联系相连的各实体的码以及联系本身的属性关系的码：n端实体的码,E-R图向关系模型的转换（续）,一个1:n联系可以转换为一个独立的关系模式，也可以与n端对应的关系模式合并。2)与n端对应的关系模式合并合并后关系的属性：在n端关系中加入1端关系的码和联系本身的属性合并后关系的码：不变可以减少系统中的关系个数，一般情况下更倾向于采用这种方法,E-R图向关系模型的转换（续）,例，“组成”联系为1:n联系。将其转换为关系模式的两种方法：1)使其成为一个独立的关系模式：组成（学号，班级号）（见下页）2)将其与学生关系模式合并：学生（学号，姓名，出生日期，所在系，年级，班级号，平均成绩）,班级 1 组成 n 学生学生的码为学号，班级的码为班级号，选修的属性为成绩,E-R图向关系模型的转换（续）,一个1:1联系可以转换为一个独立的关系模式，也可以与任意一端对应的关系模式合并。1)转换为一个独立的关系模式关系的属性：与该联系相连的各实体的码以及联系本身的属性关系的候选码：每个实体的码均是该关系的候选码,E-R图向关系模型的转换（续）,一个1:1联系可以转换为一个独立的关系模式，也可以与任意一端对应的关系模式合并。2)与某一端对应的关系模式合并合并后关系的属性：加入对应关系的码和联系本身的属性合并后关系的码：不变,E-R图向关系模型的转换（续）,例，“管理”联系为1:1联系，可以有三种转换方法：（1）转换为一个独立的关系模式：管理（职工号，班级号）或管理（职工号，班级号）（2）“管理”联系与班级关系模式合并，则只需在班级关系中加入教师关系的码，即职工号：班级（班级号，学生人数，职工号）（3）“管理”联系与教师关系模式合并，则只需在教师关系中加入班级关系的码，即班级号：教师（职工号，姓名，性别，职称，班级号，是否为优秀班主任）,E-R图向关系模型的转换（续）,注意：从理论上讲，1:1联系可以与任意一端对应的关系模式合并。但在一些情况下，与不同的关系模式合并效率会大不一样。因此究竟应该与哪端的关系模式合并需要依应用的具体情况而定。由于连接操作是最费时的操作，所以一般应以尽量减少连接操作为目标。例如，如果经常要查询某个班级的班主任姓名，则将管理联系与教师关系合并更好些。,E-R图向关系模型的转换（续）,三个或三个以上实体间的一个多元联系转换为一个关系模式。关系的属性：与该多元联系相连的各实体的码以及联系本身的属性关系的码：各实体码的组合例，“讲授”联系是一个三元联系，可以将它转换为如下关系模式，其中课程号、职工号和书号为关系的组合码：讲授（课程号，职工号，书号）,E-R图向关系模型的转换（续）,同一实体集的实体间的联系，即自联系，也可按上述1:1、1:n和m:n三种情况分别处理。例，如果教师实体集内部存在领导与被领导的1:n自联系，我们可以将该联系与教师实体合并，这时主码职工号将多次出现，但作用不同，可用不同的属性名加以区分：教师：职工号，姓名，性别，职称，系主任,E-R图向关系模型的转换（续）,具有相同码的关系模式可合并。目的：减少系统中的关系个数。合并方法：将其中一个关系模式的全部属性加入到另一个关系模式中，然后去掉其中的同义属性（可能同名也可能不同名），并适当调整属性的次序。,E-R图向关系模型的转换（续）,例，“拥有”关系模式：拥有（学号，性别）与学生关系模式：学生（学号，姓名，出生日期，所在系，年级，班级号，平均成绩）都以学号为码，可以将它们合并为一个关系模式：学生（学号，姓名，性别，出生日期，所在系，年级，班级号，平均成绩）,E-R图向关系模型的转换（续）,实例按照上述七条原则，学生管理子系统中的18个实体和联系可以转换为下列关系模型：学生（学号，姓名，性别，出生日期，所在系，年级，班级号，平均成绩，档案号）性别（性别，宿舍楼）宿舍（宿舍编号，地址，性别，人数）班级（班级号，学生人数）教师（职工号，姓名，性别，职称，班级号，是否为优秀班主任）,E-R图向关系模型的转换（续）,教学（职工号，学号）课程（课程号，课程名，学分，教室号）选修（学号，课程号，成绩）教科书（书号，书名，价钱）教室（教室编号，地址，容量）讲授（课程号，教师号，书号）档案材料（档案号，）,E-R图向关系模型的转换（续）,该关系模型由12个关系模式组成。其中：学生关系模式包含了“拥有”联系、“组成”联系、“归档”联系所对应的关系模式教师关系模式包含了“管理”联系所对应的关系模式；宿舍关系模式包含了“住宿”联系所对应的关系模式；课程关系模式包含了“开设”联系所对应的关系模式。,6.4 逻辑结构设计,6.4.1 E-R图向关系模型的转换6.4.2 向特定DBMS规定的模型进行转换6.4.3 数据模型的优化6.4.4 设计用户子模式,6.4.2 向特定DBMS规定的模型进行转换,一般的数据模型还需要向特定DBMS规定的模型进行转换。转换的主要依据是所选用的DBMS的功能及限制。没有通用规则。对于关系模型来说，这种转换通常都比较简单。,6.4 逻辑结构设计,6.4.1 E-R图向关系模型的转换6.4.2 向特定DBMS规定的模型进行转换6.4.3 数据模型的优化6.4.4 设计用户子模式,6.4.3 数据模型的优化,数据库逻辑设计的结果不是唯一的。得到初步数据模型后，还应该适当地修改、调整数据模型的结构，以进一步提高数据库应用系统的性能，这就是数据模型的优化。关系数据模型的优化通常以规范化理论为指导。,数据模型的优化（续）,优化数据模型的方法 确定数据依赖按需求分析阶段所得到的语义，分别写出每个关系模式内部各属性之间的数据依赖以及不同关系模式属性之间数据依赖。,数据模型的优化（续）,例，课程关系模式内部存在下列数据依赖：课程号课程名 课程号学分 课程号教室号 选修关系模式中存在下列数据依赖：（学号，课程号）成绩,数据模型的优化（续）,学生关系模式中存在下列数据依赖：学号姓名 学号性别 学号出生日期 学号所在系 学号年级 学号班级号 学号平均成绩 学号档案号,数据模型的优化（续）,学生关系模式的学号与选修关系模式的学号之间存在数据依赖：学生.学号选修.学号,数据模型的优化（续）,对于各个关系模式之间的数据依赖进行极小化处理，消除冗余的联系。,数据模型的优化（续）,按照数据依赖的理论对关系模式逐一进行分析，考查是否存在部分函数依赖、传递函数依赖、多值依赖等，确定各关系模式分别属于第几范式。例如经过分析可知，课程关系模式属于BC范式。,数据模型的优化（续）,按照需求分析阶段得到的各种应用对数据处理的要求，分析对于这样的应用环境这些模式是否合适，确定是否要对它们进行合并或分解。,数据模型的优化（续）,并不是规范化程度越高的关系就越优。当一个应用的查询中经常涉及到两个或多个关系模式的属性时，系统必须经常地进行联接运算，而联系运算的代价是相当高的，可以说关系模型低效的主要原因就是做联接运算引起的，因此在这种情况下，第二范式甚至第一范式也许是最好的。,数据模型的优化（续）,非BCNF的关系模式虽然从理论上分析会存在不同程度的更新异常，但如果在实际应用中对此关系模式只是查询，并不执行更新操作，则就不会产生实际影响。对于一个具体应用来说，到底规范化进行到什么程度，需要权衡响应时间和潜在问题两者的利弊才能决定。一般说来，第三范式就足够了。,数据模型的优化（续）,例：在关系模式 学生成绩单(学号,英语,数学,语文,平均成绩)中存在下列函数依赖：学号英语 学号数学 学号语文 学号平均成绩(英语,数学,语文)平均成绩,数据模型的优化（续）,显然有：学号(英语,数学,语文)因此该关系模式中存在传递函数信赖，是2NF关系。虽然平均成绩可以由其他属性推算出来，但如果应用中需要经常查询学生的平均成绩，为提高效率，我们仍然可保留该冗余数据，对关系模式不再做进一步分解。,数据模型的优化（续）,按照需求分析阶段得到的各种应用对数据处理的要求，对关系模式进行必要的分解或合并，以提高数据操作的效率和存储空间的利用率常用分解方法水平分解垂直分解,数据模型的优化（续）,水平分解什么是水平分解把(基本)关系的元组分为若干子集合，定义每个子集合为一个子关系，以提高系统的效率。,数据模型的优化（续）,水平分解的适用范围1.满足“80/20原则”的应用80/20原则：一个大关系中，经常被使用的数据只是关系的一部分，约20%把经常使用的数据分解出来，形成一个子关系，可以减少查询的数据量。,数据模型的优化（续）,水平分解的适用范围2.并发事务经常存取不相交的数据如果关系R上具有n个事务，而且多数事务存取的数据不相交，则R可分解为少于或等于n个子关系，使每个事务存取的数据对应一个关系。,数据模型的优化（续）,水平分解什么是水平分解把(基本)关系的元组分为若干子集合，定义每个子集合为一个子关系，以提高系统的效率。水平分解的适用范围满足“80/20原则”的应用并发事务经常存取不相交的数据,数据模型的优化（续）,满足“80/20原则”的应用80/20原则：一个大关系中，经常被使用的数据只是关系的一部分，约20%把经常使用的数据分解出来，形成一个子关系，可以减少查询的数据量。并发事务经常存取不相交的数据如果关系R上具有n个事务，而且多数事务存取的数据不相交，则R可分解为少于或等于n个子关系，使每个事务存取的数据对应一个关系。,数据模型的优化（续）,垂直分解什么是垂直分解把关系模式R的属性分解为若干子集合，形成若干子关系模式。垂直分解的原则经常在一起使用的属性从R中分解出来形成一个子关系模式。,数据模型的优化（续）,垂直分解的优点可以提高某些事务的效率垂直分解的缺点可能使另一些事务不得不执行连接操作，从而降低了效率。,数据模型的优化（续）,垂直分解的适用范围取决于分解后R上的所有事务的总效率是否得到了提高。进行垂直分解的方法简单情况：直观分解复杂情况：用第五章中的模式分解算法垂直分解必须不损失关系模式的语义(保持无损连接性和保持函数依赖)。,5.4 逻辑结构设计,5.4.1 E-R图向关系模型的转换5.4.2 向特定DBMS规定的模型进行转换5.4.3 数据模型的优化5.4.4 设计用户子模式,5.4.4 设计用户子模式,定义数据库模式主要是从系统的时间效率、空间效率、易维护等角度出发。定义用户外模式时应该更注重考虑用户的习惯与方便。包括三个方面：,设计用户子模式（续）,(1)使用更符合用户习惯的别名合并各分E-R图曾做了消除命名冲突的工作，以使数据库系统中同一关系和属性具有唯一的名字。这在设计数据库整体结构时是非常必要的。但对于某些局部应用，由于改用了不符合用户习惯的属性名，可能会使他们感到不方便，,设计用户子模式（续）,(1)使用更符合用户习惯的别名(续)因此在设计用户的子模式时可以重新定义某些属性名，使其与用户习惯一致。当然，为了应用的规范化，我们也不应该一味地迁就用户。例：负责学籍管理的用户习惯于称教师模式的职工号为教师编号。因此可以定义视图，在视图中职工号重定义为教师编号,设计用户子模式（续）,(2)针对不同级别的用户定义不同的外模式，以满足系统对安全性的要求。,设计用户子模式（续）,例：教师关系模式中包括职工号、姓名、性别、出生日期、婚姻状况、学历、学位、政治面貌、职称、职务、工资、工龄、教学效果等属性。学籍管理应用只能查询教师的职工号、姓名、性别、职称数据；课程管理应用只能查询教师的职工号、姓名、性别、学历、学位、职称、教学效果数据；教师管理应用则可以查询教师的全部数据。,设计用户子模式（续）,定义两个外模式：教师_学籍管理(职工号，姓名，性别，职称)教师_课程管理(工号，姓名，性别，学历，学位，职称，教学效果)授权学籍管理应用只能访问教师_学籍管理视图授权课程管理应用只能访问教师_课程管理视图授权教师管理应用能访问教师表这样就可以防止用户非法访问本来不允许他们查询的数据，保证了系统的安全性。,设计用户子模式（续）,(3)简化用户对系统的使用如果某些局部应用中经常要使用某些很复杂的查询，为了方便用户，可以将这些复杂查询定义为视图。,逻辑结构设计小结,任务将概念结构转化为具体的数据模型逻辑结构设计的步骤将概念结构转化为一般的关系、网状、层次模型将转化来的关系、网状、层次模型向特定DBMS支持下的数据模型转换对数据模型进行优化设计用户子模式,逻辑结构设计小结,E-R图向关系模型的转换内容将E-R图转换为关系模型：将实体、实体的属性和实体之间的联系转化为关系模式。,逻辑结构设计小结,E-R图向关系模型的转换原则 一个实体型转换为一个关系模式。一个m:n联系转换为一个关系模式。一个1:n联系可以转换为一个独立的关系模式，也可以与n端对应的关系模式合并。一个1:1联系可以转换为一个独立的关系模式，也可以与任意一端对应的关系模式合并。,逻辑结构设计小结,E-R图向关系模型的转换原则 三个或三个以上实体间的一个多元联系转换为一个关系模式。同一实体集的实体间的联系，即自联系，也可按上述1:1、1:n和m:n三种情况分别处理。具有相同码的关系模式可合并。,逻辑结构设计小结,优化数据模型的方法 确定数据依赖 对于各个关系模式之间的数据依赖进行极小化处理，消除冗余的联系。确定各关系模式分别属于第几范式。分析对于应用环境这些模式是否合适，确定是否要对它们进行合并或分解。对关系模式进行必要的分解或合并,逻辑结构设计小结,设计用户子模式1.使用更符合用户习惯的别名2.针对不同级别的用户定义不同的外模式，以满足系统对安全性的要求。3.简化用户对系统的使用,