《第10章数据库系统设计数据库原理及应用SQLServer数据库原理及应用课件.ppt》由会员分享，可在线阅读，更多相关《第10章数据库系统设计数据库原理及应用SQLServer数据库原理及应用课件.ppt（80页珍藏版）》请在三一办公上搜索。
1、第10章数据库系统设计,本章学习目标,理解数据库系统设计理解需求分析的任务和方法理解概念结构设计掌握概念设计的方法和步骤掌握逻辑结构设计掌握规范化了解数据库的物理设计,10.1数据库系统设计概述,10.1.1数据库和信息系统10.1.2数据库设计的基本步骤,10.1.1数据库和信息系统,(1)数据库是信息系统的核心和基础，把信息系统中大量的数据按一定的模型组织起来，提供存储、维护、检索数据的功能，使信息系统可以方便、及时、准确地从数据库中获得所需的信息。(2)数据库是信息系统的各个部分能否紧密地结合在一起以及如何结合的关键所在。(3)数据库设计是信息系统开发和建设的重要组成部分。,10.1.2
2、数据库设计的基本步骤,数据库设计一般都遵循软件的生命周期理论，分为6个阶段进行，如图10-1所示，即需求分析、概念结构设计、逻辑结构设计、物理结构设计、数据库实施和数据库的运行和维护。,图10-1 数据库设计流程,10.2需求分析,10.2.1需求分析的任务10.2.2需求分析的方法,10.2.1需求分析的任务,需求分析的任务就是通过详细调查现实世界要处理的对象(组织、部门、企业等)，充分了解原系统(手工系统或计算机系统)的工作概况，明确用户的各种需求，然后在此基础上确定新系统的功能，新系统必须充分考虑今后可能的扩充和改变，不能仅仅按当前应用需求来设计数据库。,10.2.2需求分析的方法,(1
3、)使用数据流图分析信息处理过程(2)使用数据字典汇总各类数据(3)撰写需求说明书,10.3概念结构设计,10.3.1概念模型的基本概念10.3.2概念模型的表示方法10.3.3概念结构的特点10.3.4概念结构设计的方法10.3.5概念结构设计的步骤,10.3.1概念模型的基本概念,概念结构设计的目标是在需求分析阶段产生的需求说明书的基础上，按照特定的方法把它们抽象为一个不依赖于任何具体机器的数据模型，即概念模式，描述概念结构的工具是E-R图。,10.3.2概念模型的表示方法,概念模型的表示方法很多，其中最为著名且常用的是P.P.S.chen于1976年提出的实体联系方法（Entity-Rel
4、ationship Approach）。该方法用E-R图来描述现实世界的概念模型，E-R方法也称为E-R模型。,E-R图是描述概念世界、建立概念模型的实用工具，包括3个基本要素：属性实体(型)联系 1.多对多的联系(mn)2.一对多的联系(1n)3.一对一的联系(11),10.3.3概念结构的特点,（1）能真实充分地反应现实世界，包括事物与事物之间的联系，能满足用户对数据的处理要求。（2）易于理解。（3）易于修改。（4）易于向关系、网状、层次等各种数据模型转换。,10.3.4概念结构设计的方法,(1)自顶向下：这种方法是从总体概念结构开始逐层细化。,(2)自底向上：这种方法是从具体的对象逐层抽
5、象，最后形成总体概念结构。,(3)由内向外：这种方法是从核心的对象着手，然后向四周逐步扩充，直到最终形成总体概念结构。,（4)混合策略。该方法采用自顶向下和自底向上相结合的方法，先自顶向下定义全局框架，再以它为骨架集成自底向上方法中设计的各个局部概念结构。,10.3.5概念结构设计的步骤,概念模型设计通常采用自底向下的设计方法，将设计分为局部视图设计和视图集成两个步骤进行。(1)局部视图设计(2)视图集成,10.4规范化,10.4.1关系模式规范化的必要性10.4.2函数依赖10.4.3范式与规范化10.4.4模式分解原则10.4.5规范化的本质分析与总结,10.4.1关系模式规范化的必要性,
6、规范化的原因很多，其主要原因是不规范的关系模式在应用中可能产生很多弊病，导致产生各种存储异常。最常见的存储异常问题如下所示：数据冗余更新异常插入异常删除异常,10.4.2函数依赖,关系中属性之间这种相互依赖又相互制约的联系称为数据依赖。函数依赖是从数学角度来定义的，在关系中用来刻画关系各属性之间相互制约而又相互依赖的情况。,定义：设UA1，A2，An是属性集合，R（U）是U上的一个关系，x、y是U的子集。若对于R（U）下的任何一个可能的关系，均有x的一个值对应于y的唯一具体值，称y函数依赖于x，记作xy。其中x称为决定因素。进而若再有yx，则称x与y相互依赖，记作xy。,例如，对于Studen
7、t(Sno,Major)，假定每个学生都有惟一的学号Sno，每个学生有且只有一个专业Major，则只要给定Sno的值，就可以弄清楚该学生的专业。“专业”函数依赖于“学生学号”，或“学生学号”函数决定“学生专业”。函数依赖使用下面的形式来书写 SnoMajor。,函数依赖中还可细分为多种函数依赖，分别介绍如下：(1)部分函数依赖(2)完全函数依赖(3)传递函数依赖,部分函数依赖,设R（U）是属性集U上的关系，x、y是U的子集，x是x的真子集，若xy且xy，则称y部分依赖x，记作。显然，当且仅当x为复合属性组时，才有可能出现部分函数依赖。,完全函数依赖,设R（U）是属性集U上的关系，x、y是U的子
8、集，x是x的真子集。若对于R（U）的任何一个可能的关系，有xy但不存在一个真子集xy，则称y完全函数依赖于x，记作。,传递函数依赖,设R（U）是属性集U上的关系，x、y、z是U的子集，在R（U）中，若xy，但yx，若yz，则xz，称z传递函数依赖于x，记作。,10.4.3范式与规范化,各范式之间的联系有5NF 4NF BCNF 3NF 2NF 1NF成立。各种范式之间的联系可以由下图10-9简单描述。图10-9 各种范式之间的关系,通常按属性间依赖情况区分关系规范化的程度，定义了不同要求的规范化关系模式，即范式。目前遵循的主要范式有：第一范式(1NF)、第二范式(2NF)、第三范式(3NF)、
9、BC范式(BCNF)、第四范式(4NF)和第五范式(5NF)等。范式是嵌套的，就是说，属于第二范式的关系必然是属于第一范式的关系，在第五范式中的关系也在第四范式、BC范式、第三范式、第二范式和第一范式中的关系。,第一范式,下面主要讨论1NF、2NF、3NF和BCNF范式。第一范式，在关系模式R中的每一个具体关系，如果每个属性值都是不可再分的最小数据单位，则称R是第一范式的关系，记为R1NF。,例如：学生选课数据库中将学生、系、课程，选课成绩等所有的信息一起存放。即有关系模式：StudData(Sno,Sname,Ssex,Ssage,Dno,Dname,Cno,Cname,Credits,Gr
10、ade)这个关系的主键(Sno,Cno),，关系StudData就是属于第一范式的，可记作：StudData1NF。,第二范式,第二范式，若R1NF，且每一个非主属性完全函数依赖于R的任何侯选关键字，则称R2NF。,关系StudData属于第一范式。但它不属于第二范式。原因：存在非主属性Sname、Ssex、Sage、Dno部分函数依赖于主键(Sno,Cno)。所以StudData违反了2NF的定义，它不属于2NF。消除部分函数依赖的方法就是将关系分解，使其新的关系中非主属性于候选键之间不存在部分函数依赖。,前面已经分析过StudData的主键是(Sno,Cno)。所以，Sno,Cno是主属性
11、，其他属性如Sname、Ssex等都是非主属性。根据主键定义，（Sno,Cno）完全函数决定其他非主属性。所以存在如下函数依赖：,（Sno,Cno）Sname（Sno,Cno）Ssex（Sno,Cno）Sage（Sno,Cno）Dno（Sno,Cno）Dname（Sno,Cno）Cname（Sno,Cno）Credit（Sno,Cno）Grade,只要给定学生的学号Sno值，就能知道该学生的姓名、性别等情况，即存在函数依赖,Sno SnameSno SsexSno SageSno DnoSno Dname只要给定课程号Cno值，就能知道课程名、课程的学分，即存在函数依赖Cno CnameCno
12、 Credit,分解的方法是投影。具体讲：(1)用组成候选键的属性集合的每一个非空真子集作为主键构成一个新关系；(2)对于每个新关系，将完全依赖或传递依赖于此主键的属性放置到此关系中。下面将StudData关系按上述方法分解：,StudData关系只有一个候选键，也就是主键(Sno,Cno)。它的非空子集有：Sno、Cno、(Sno,Cno)。对应构成三个新关系，设分别为Students和Courses、Enrollment，其中，Students的主键为Sno，Courses的主键为Cno，Enrollment的主键为(Sno,Cno)。将完全依赖或传递依赖于Sno主键的属性放置到Stude
13、nts表中，完全依赖或传递依赖于Cno主键的属性放置到Courses表中，完全依赖或传递依赖于(Sno,Cno)主键的属性放置到Enrollment表中得到：Students(Sno,Sname,Ssex,Sage,Dno,Dname)Courses(Cno,Cname,Credits)Enrollment(Sno,Cno,Grade),Students(Sno,Sname,Ssex,Sage,Dno,Dname),Courses(Cno,Cname,Credits),Enrollment(Sno,Cno,Grade),分解得到三个关系Students、Courses、Enrollmen。根据
14、2NF的标准衡量，这三个关系中都不存在非主属性部分函数依赖于候选键的情况。所以它们都属于2NF。即Students2NF、Courses2NF、Enrollmen2NF。结果：冗余问题已得到明显改善，但还有一定的数据冗余，还存在插入异常和删除异常。属于第二范式的关系同样还可能存在操作异常情况，因此需要进一步规范化。,第三范式(3NF)定义：如果关系R2NF，且每一个非主属性都不传递依赖于候选键，则R属于第三范式，记作R3NF。StudData分解后得到的三个关系Students、Courses、Enrollment，它们都属于第二范式了。但Students(Sno,Sname,Ssex,Sag
15、e,Dno,Dname)不属于3NF。原因：SnoDno，Dno Dname，存在非主属性Dname传递函数依赖于候选键Sno。根据3NF的定义，Students不属于3NF。,关系Students(Sno,Sname,Ssex,Sage,Dno,Dname),一个关系R若仅属于2NF但不属于3NF，如关系Students，仍然存在数据冗余过多、删除异常和插入异常等问题。解决的办法仍然是分解，以消除传递依赖。具体方法为：(1)对于不是候选键的每个决定因子，从原关系中删去依赖于它的所有属性；(2)对原关系中不是候选键的每个决定因子，新建一个关系，新关系中包含依赖该决定因子的属性；(3)将该决定因
16、子加入新关系并作为新关系的主键。按上述方法，来分解Students关系得到：Students(Sno,Sname,Ssex,Sage,Dno)Departments(Dno,Dname),Students(Sno,Sname,Ssex,Sage,Dno),Departments(Dno,Dname),最终得到的所有关系：Students(Sno,Sname,Ssex,Sage,Dno)Courses(Cno,Cname,Credits)Enrollment(Sno,Cno,Grade)Departments(Dno,Dname)都已经属于3NF的关系。对于一般的数据库应用来说，设计出的关系符合
17、第三范式标准就够了。因为，一般来说，满足3NF的关系已能消除冗余和各种异常现象，获得较满意的效果。,无论2NF还是3NF都没有涉及关系中主属性间的函数依赖问题，所以有时仍会引起一些问题。由此我们引入BC范式(BCNF)，通常认为BCNF是第三范式的改进。BC范式(BCNF)定义：如果关系R1NF，且R中每一个决定因子都是候选键，则R属于BC范式，记作RBCNF。可以证明：若RBCNF，则R3NF。反过来，若R3NF，则R未必属于BCNF。,(5)第四范式，设一个关系模式R1NF，若XY(Y X)是非平凡的多值依赖，且X含有码，则R4NF。,10.4.4模式分解原则,模式分解主要涉及两个原则：保
18、持依赖（Preserve Dependency）无损连接（Lossless Join）,10.4.5规范化的本质分析与总结,从数据库设计实践的角度给出几条经验原则：部分函数依赖和传递函数依赖的存在是产生数据冗余、更新异常的重要原因。因此，在关系规范化中，应尽可能消除属性间的这些依赖关系。非第三范式的1NF、2NF以至非规范化的模式，由于它们性能上的弱点，一般不宜作为数据库模式。由于第三范式的关系模式中不存在非主属性对关键字的部分依赖和传递依赖关系，因而消除了很大一部分冗余和更新异常，具有较好的性能，所以，一般要求数据库设计达到3NF。,总结规范化的本质：即“一事一地”。如果某个关系有两个或多个
19、事实，它就应该分解为多个关系，每个关系只包含一种事实。每当分解关系的时候，都应该考虑建立关系之间的关联，加入必要的外健。因为对关系进行的每一次分解都会产生参照完整性约束。因此，每当把一个关系分解为两个或多个时，就要检查这种约束。,10.5逻辑结构设计,10.5.1E-R图向关系模型的转换10.5.2数据模型优化10.5.3数据库逻辑设计案例,关系数据库设计需要设计出数据库赖以实现的实现模型，现在用的实现模型都是关系模型。因此需要设计一个关系模型。关系模型的数据结构是关系，一个关系用一个关系模式表示。所有的关系模式组成数据库的模式。所以关系数据库设计就是要设计出数据库的模式，也称逻辑结构或逻辑模
20、型。,10.5.1E-R图向关系模型的转换,设计方法：将实体-联系模型转换为关系模型，用若干个关系模式来表示。实体-联系模型由实体、属性、标识符和实体之间的联系等要素组成的，所以将实体联系模型转换为关系模型，实际上就是要将E-R图中实体、实体的属性和实体之间的联系等转换为若干个关系模式，并确定这些关系模式的属性、关键字和约束。E-R图的转换规则。,(1)一个实体型转换为一个关系模型，实体的属性就是关系的属性，实体的键就是关系的键；例如，图10-14所示的实体类型“学生”可转换成如下的关系模式：学生(学号，姓名，性别，年龄，专业)其中，带下划线的属性为主属性。,图10-14 一个实体类型转换为一
21、个关系模式,(2)一个联系转换为一个关系模式，与该联系相连的每个实体型的键以及联系的属性都转换为关系的属性。这个关系的键分为以下3种不同的情况。若联系为11,若联系为1:n,若联系为m:n,同一实体集内部的联系，可将该实体集拆分为相互联系的两个子集，然后根据它们相互间不同的联系方式（1：1，1：n，m：n）按上述规则处理。,三个或三个以上实体间的一个多元联系可以转换为一个关系模式。与该多元联系相连的各实体的码以及联系本身的属性均转换为关系的属性，而关系的码为各实体码的组合。,具有相同码的关系模式可合并。为了减少系统中的关系个数，如果两个关系模式具有相同的主码，可以考虑将他们合并为一个关系模式。
22、,10.5.2数据模型优化,应用规范化理论优化逻辑模型一般要做如下5项工作：(1)确定数据依赖。(2)对于各个关系模式之间的数据依赖进行极小化处理，消除冗余的联系。(3)按照数据依赖的理论对关系模式逐一进行分析，考察是否存在部分函数依赖、传递函数依赖、多值依赖等，确定各关系模式分别属于第几范式。(4)按照需求分析阶段得到的处理要求，分析这些模式对于这样的应用环境是否合适，确定是否要对某些模式进行合并或分解。,(5)对关系模式进行必要的分解，提高数据操作的效率和存储空间的利用率。常用的两种分解方法水平分解和垂直分解。水平分解是把（基本）关系的元组分为若干子集合，定义每个子集合为一个子关系，以提高
23、系统的效率。垂直分解是把关系模式R的属性分解为若干于集合，形成若干子关系模式。,学生图书借阅管理子系统1 学生图书借阅管理子系统的基本需求 该子系统是一个专为该学校图书馆管理而设计的系统。读者从图书馆借书，对图书馆来说，读者好像书籍一样，都是先被注册在该系统中的。图书馆需要处理新买的图书，包括添加、删除等。图书管理员是图书馆的雇员，所有图书登记、读者注册的工作由图书管理员完成，他们负责和读者交互，该系统支持他的工作。图书馆要求系统能方便地建立、更新和删除存在该系统中有关书名、读者等信息，也能方便地登记图书的借出与归还等的信息。,10.5.3数据库逻辑设计案例,2 学生图书借阅管理子系统的ER模
24、型设计 首先，根据对学生图书借阅管理系统的需求分析，我们可以先得到实体:书、读者和管理员。其次，分析它们之间的关系，管理员与书之间存在着一对多的联系，联系命名为“登记”，因为一个管理员可以负责登记多本图书；管理员与读者之间也存在一对多的联系，联系命名为“注册”，因为一个管理员可以负责注册多名读者；管理员、读者、书之间存在多对多的借阅联系，因为一名读者可以借阅多本图书，一个管理员可以办理多次借阅，一本书可以被多个读者借阅。至此，三个实体与它们之间的联系可以表示如下：,为了简化E-R图，我们假定管理员的属性只有：职工号、姓名、性别、权限级别，读者的属性只有：借书证号，姓名、性别、系别。书的属性有：
25、书号、书名、作者、出版社、分类号。再分析每一个实体的标识符。我们假定管理员的标识符是职工号，书的标识符是书号，读者的标识符是借书证号。将上述实体、联系、属性等集成，得到学生图书借阅管理系统完整的E-R模型图如下表示：,3 ER模型转换为关系模型 根据实体转换规则，先把管理员、书、读者实体转换关系，关系模式如下：管理员（职工号，姓名，性别，权限级别）书（书号，书名，作者，出版社，分类号）读者（借书证号，姓名，性别，系别）根据1:n联系的转换规则，把联系“登记”的属性即“读者权限”和管理员关系的主键即“职工号”加入到读者关系中，得到读者改进后的关系读者（借书证号,姓名,性别,系别,读者权限,职工号
26、）再把1:n联系“注册”的属性即“入库时间”和管理员关系的主键即“职工号”加入到书关系中，得到书改进后的关系：书（书号，书名，作者，库存，出版社，分类号，入库时间，职工号）,将一个三元关系管理员、书和读者之间的借阅联系转换为一个关系：借阅(职工号,借书证号,书号,借出日期，归还日期)所以最终得到的关系模型为：管理员（职工号，姓名，性别，权限级别）书（书号,书名,作者,出版社,分类号,入库时间,职工号）读者（借书证号，姓名，性别，系别，读者权限，职工号）借阅(职工号,借书证号,书号,借出日期，归还日期),用英文命名的关系模式为：Administrator（Ano,Aname,Asex,Apriv
27、ilege）BOOK（Bno，Bname，Bauthor，Bpublisher，BTPno，Indate，Ano）READER（Rno,Rname,Rsex,Rdept，Rprivilege，Ano）Borrow（Ano,Rno,Bno,Bdate）,10.6数据库的物理设计,10.6.1数据库物理设计的方法10.6.2确定数据库的存储结构10.6.3对物理结构进行评价,10.6.1数据库物理设计的方法,数据库逻辑设计得到的逻辑模型（或逻辑结构）就是数据库的模式。但数据库最终是存储在物理设备上的，数据库在物理设备上的存储结构和存储方式称为数据库的物理结构，它依赖于具体的DBMS。物理设计主要包
28、括聚簇设计、索引设计和分区设计。,10.6.2确定数据库的存储结构,1.确定数据存放位置和存储结构的因素2.存储分配参数,10.6.3对物理结构进行评价,数据库物理设计过程中需要对时间效率、空间效率、维护代价和各种用户要求进行权衡，其结果可以产生多种方案，数据库设计人员必须对这些方案进行细致的评价，从中选择一个较优的方案作为数据库的物理结构。评价物理数据库的方法完全依赖于所选用的 DBMS，主要是从定量估算各种方案的存储空间、存取时间和维护代价入手，对估算结果进行权衡、比较，选择出一个较优的合理的物理结构。如果该结构不符合用户需求，则需要修改设计。,10.7本章小结,数据库系统的设计是一项十分复杂的系统工程。本章开始通过介绍了如何开发高效实用的数据库应用系统的基本步骤，包括需求分析、概念设计、逻辑结构设计、物理设计以及数据库的实施和运行与维护引出了下面的内容。,
