数据库讲义ch13.docx
《数据库讲义ch13.docx》由会员分享，可在线阅读，更多相关《数据库讲义ch13.docx（28页珍藏版）》请在冰豆网上搜索。
数据库讲义ch13
13数据库设计
13.1数据库设计的过程
13.1.1数据库设计概述
以数据库为基础的信息系统通常称为数据库应用系统，它一般具有信息的采集、组织、加工、抽取和传播等功能。
数据库应用系统的开发是一项软件工程，但又有自己持有的特点，所以特称为“数据库工程”。
一项数据库工程按内容可分为两部分：
作为系统核心的数据库结构的设计与实现；
相应的应用软件及其他软件（如通信软件）的设计与实现。
本章主要研究前一部分。
数据库设计具体步骤：
总体信息需求：
数据库系统的目标说明，数据元素的定义，数据在企业组织中的使用描述。
处理需求：
每个应用需要的数据项、数据量以及应用执行的频率。
DBMS的特征：
有关DBMS的一些说明和参数，DBMS所支持的模式、子模式和程序语法的规则。
硬件和OS特征：
对DBMS和OS访问方法特有的内容，例如物理设备容量限制时间特性及所有的运行要求。
数据库设计过程的输出主要有两部分，一部分是完整的数据库结构，其中包括逻辑结构与物理结构；另一部分是基于数据库结构和处理需求的应用程序的设计原则。
这些输出一般都是以说明书的形式出现。
13.1.2规划阶段
对于数据库系统，特别是大型数据库系统或大型信息系统中的数据库群，规划阶段是十分必要的。
规划的好坏将直接影响到整个系统的成功与否，对企业组织的信息化进程产生深远的影响。
规划阶段具体可分成三个步骤：
系统调查。
对企业组织作全面的调查，画出组织层次图，以了解企业的组织机构。
可行性分析。
从技术、经济、效益、法律等诸方面对建立数据库的可行性进行分析，然后写出可行性分析报告，组织专家讨论其可行性。
确定数据库系统的总目标和制订项目开发计划。
在得到决策部门批准后，就正式进行数据库系统的开发工作。
13.1.3需求分析阶段
这一阶段是计算机人员（系统分析员）和用户双方共同收集数据库所需要的信息内容和用户对处理的需求。
并以需求说明书的形式确定下来，作为以后系统开发的指南和系统验证的依据。
需求分析的工作主要由下面四步组成：
分析用户活动，产生业务流程图
了解用户当前的业务活动和职能，搞清其处理流程（即业务流程）。
如果一个处理比较复杂，就要把处理分解成若干个子处理，使每个处理功能明确、界面清楚，分析之后画出用户的业务流程图。
确定系统范围，产生系统范围图
这一步是确定系统的边界。
在和用户经过充分讨论的基础上，确定计算机所能进行的数据处理的范围，确定哪些工作由人工完成，哪些工作由计算机系统完成，即确定人机界面。
分析用户活动涉及的数据，产生数据流图
深入分析用户的业务处理，以数据流图形式表示出数据的流向和对数据所进行的加工。
分析系统数据，产生数据字典
数据字典是对数据描述的集中管理，它的功能是存储和检索各种数据描述（称为元数据metadata）。
对数据库设计来说，数据字典是进行详细的数据收集和数据分析所获得的主要成果。
数据字典中通常包括数据项、数据结构、数据流、数据存储和处理过程五个部分。
13.1.4概念设计阶段
概念设计的目标是产生反映企业组织信息需求的数据库概念结构，即概念模式。
概念模式是独立于计算机硬件结构、独立于支持数据库的DBMS。
概念模式（ConceptualSchema）是数据库中全部数据的整体逻辑结构的描述。
它由若干个概念记录类型组成，还包含记录间联系、数据的完整性和安全性等要求。
概念模式必须不涉及到存储结构、访问技术等细节。
只有这样，概念模式才能达到“物理数据独立性”。
概念设计的任务一般可分为三步来完成：
进行数据抽象，设计局部概念模式
局部用户的信息需求是构造全局概念模式的基础。
因此，需要先从个别用户的需求出发，为每个用户或对数据的观点与使用方式相似的用户建立一个相应的局部概念结构。
在建立局部概念结构时，要对需求分析的结果进行细化、补充和修改，如有的数据项要分为若干子项，有的数据的定义要重新核实等。
设计概念结构时，常用的数据抽象方法是“聚集”和“概括”：
聚集是将若干对象和它们之间的联系组合成一个新的对象。
概括是将一组具有某些共同特性的对象合并成更高一层意义上的对象。
将局部概念模式综合成全局概念模式
综合各局部概念结构就可得到反映所有用户需求的全局概念结构。
在综合过程中，主要处理各局部模式对各种对象定义的不一致问题，包括同名异义、异名同义和同一事物在不同模式中被抽象为不同类型的对象（例如，有的作为实体，有的又作为属性）等问题。
把各个局部结构合并，还会产生冗余问题，或导致对信息需求的再调整与分析，以确定确切的含义。
评审
消除了所有冲突后，就可把全局结构提交评审。
评审分为用户评审与DBA及应用开发人员评审两部分。
用户评审的重点放在确认全局概念模式是否准确完整地反映了用户的信息需求和现实世界事物的属性间的固有联系。
DBA和应用开发人员评审则侧重于确认全局结构是否完整、各种成分划分是否合理、是否存在不一致性，以及各种文档是否齐全等。
文档应包括局部核念结构描述、全局核念结构描述、修改后的数据清单和业务活动情单等。
概念设计中最著名的方法就是实体联系方法（ER方法），建立ER模型，用ER图表示概念结构，得到数据库的概念模式。
13.1.5逻辑设计阶段
概念结构是独立于任何一种数据库的信息结构，而逻辑结构设计的任务就是把概念结构转换为选用的DBMS所支持的数据模型相符的过程。
设计过程分三步：
首先，把概念结构向一般的关系、网状、层次模型转换。
然后，向特定的DBMS支持下的数据模型转换。
最后，进行模型优化。
13.1.6物理设计阶段
对于给定的基本数据模型选取一个最适合应用环境的物理结构的过程，称为物理设计。
数据库的物理结构主要指数据库的存储记录格式、存储记录安排和存取方法。
显然数据库的物理设计是完全依赖于给定的硬件环境和数据库产品的。
13.1.7数据库的实现
数据库实现主要包括以下工作：
用DDL定义数据库结构；
组织数据入库；
编制与调试应用程序；
数据库试运行。
13.1.8数据库的运行与维护
在数据库试运行结果符合设计目标后，数据库就可以真正投入运行了。
在数据库运行阶段，对数据库经常性的维护工作由DBA来完成，它包括以下内容
数据库的转储和恢复
数据库安全性、完整性控制
数据库性能的监督、分析和改进
数据库的重组织和重构造
13.2ER模型
实体联系模型（ER模型）是广泛被采用的概念模型设计方法。
它是由PeterChen于1976年在题为“实体联系模型：
将来的数据视图”的论文中提出的。
此后Chen和其他许多人对它又进行了扩展和修改，出现了ER模型的许多变种，且表达的方法无一定的标准。
但是，绝大多数ER模型的基本构件相同，只是表示的方法有所差别。
这里采用的是一些典型的和流行的符号，所介绍的内容也是一些较普通和实用的方法。
13.2.1ER模型的基本元素
13.2.1.1实体
实体是一个数据对象，指应用中可以区别的客观存在的事物，如人、部门、表格、物体、项目等。
同一类实体构成实体集（EntitySet）。
实体的内涵用实体类型（EntityType）来表示。
实体类型是对实体集中实体的定义。
由于实体、实体集、实体类型等概念的区分在转换成数据库的逻辑设计时才要考虑，因此在不引起混淆的情况下，我们一般将实体、实体集、实体类型等概念统称为实体。
由此可见，ER模型中提到的实体往往是指实体集。
在ER模型中，实体用方框表示，方框内注明实体的命名。
实体名常用大写字母开头的有具体意义的英文名词表示。
但建议实体名在需求分析阶段用中文表示，在设计阶段再根据需要转成英文形式，这样有利于软件工作人员相用户之间的交流。
13.2.1.2联系
现实世界中，实体不是孤立的，实体之间是有联系的。
例如“职工在某部门工作”是实体“职工”和“部门”之间的联系，“学生在某个教室听某位老师讲的课程”说明“学生”、“教室”、“老师”和“课程”等四个实体之间有联系；而“零件之间有组合联系”表示“零件”实体之间有联系。
联系表示一个或多个实体之间的关联关系。
同一类联系构成“联系集（RelationshipSet）”。
联系的内涵用联系类型（RelationshipType）来表示。
联系类型是对联系集中联系的定义。
同实体一样，我们一般将联系、联系集、联系类型等统称为联系。
联系是实体之间的一种行为，所以在英语国家中，一般用动名词来命名联系，我们则用汉语动词，譬如“工作”、“参加”、“属于”、“入库”、“进库”等。
在ER图中，联系用菱形框表示，并用线段将其与相关的实体连接起来。
由于一个实体可能涉及多个联系，在每个联系中所扮演的角色也会不同，如实体“职工”，在管理联系中可能扮演经理的角色，在保健联系中扮演病人的角色，在储蓄联系中扮演客户的角色。
实体的角色为实体在该联系中所起的作用。
13.2.1.3属性
实体的某一特性称为属性。
如人有姓名、性别、年龄等属性。
在一个实体中，能够惟一标识实体的属性或属性集称为实体标识符。
一个实体只有一个标识符，但没有候选标识符的概念。
实体标识符有时也称为实体的主键。
在ER图中，属性用椭圆形框表示，加下划线的属性为标识符。
属性域是属性的可能取值范围，也称为属性的值域。
抽象地说，属性将实体集合中每个实体和该属性的值域的一个值联系起来。
实体属性的一组特定值，确定了一个特定的实体，实体的属性值是数据库中存储的主要数据。
联系也会有属性，用于描述联系的特征，如参加工作时间、入库数量等。
但联系本身没有标识符。
13.2.2属性的分类
13.2.2.1基本属性和复合属性
基本属性是不可再分割的属性。
复合属性是可再分解为其他属性的属性（即属性可嵌套）。
13.2.2.2单值属性和多值属性
单值属性指的是同一实体的属性只能取一个值。
譬如，同一个学生只能具有一个年龄，所以年龄属性是一个单值属性。
多值属性指同一实体的某些属性可能取多个值。
譬如，一个人的学位是一个多值属性（学士、硕士和博士）；一种零件可能有多种销售价格（经销、代销、批发和零售）。
多值后性用双椭圆形表示。
13.2.2.3导出属性
通过具有相互依赖的属性推导而产生的属性称为导出属性。
例如在职工实体中，实发工资可从基本工资、资金、房租等同性中推导出来。
导出属性的值不仅可以从其他属性导出，也可以从有关的实体导出。
导出属性用虚线椭圆形与实体相连。
13.2.3联系的设计
13.2.3.1联系的元数
一个联系涉及到的实体集个数，称为该联系的元数或度数（Degree）。
通常，同一个实体集内部实体之间的联系，称为一元联系，也称为递归联系；两个不同实体集实体之间的联系，称为二元联系；三个不同实体集实体之间的联系，称为三元联系。
以此类推。
13.2.3.2联系的连通词
联系涉及到的实体集之间实体对应的方式，称为联系的连通词（Connectivity）。
这里“对应的方式”，是指实体集E1中一个实体与实体集E2中至多一个还是多个实体有联系。
二元联系的连通词有四种：
一对一联系1:
1，
一对多联系1:
N，
多对一联系M:
1，
多对多联系M:
N。
由于M:
1是1:
N的反面，因此通常就不再提及。
一对一联系：
如果实体集E1中每个实体至多和实体集E2中的一个实体有联系反之亦然。
那么实体集E1和E2的联系称为“一对一联系”，记为“1:
1”。
一对多联系：
如果实体集E1中每个实体可以与实体集E2中任意个（零个或多个）实体间有联系，而E2中每个实体至多和E1中一个实体有联系，那么称E1对E2的联系是“一对多联系”，记为“1:
N”。
多对多联系：
如果实体集E1中每个实体可以与实体集E2中任意个（零个或多个）实体有联系，反之亦然，那么称El和E2的联系是“多对多联系”，记为“M:
N”。
二元联系连通词的三种方式：
一元联系连通词的三种方式：
运动员根据其得分来排定名次。
在名次排列中，排在他前面只有一个人，排在他后面也只有一个人，也就是运动员之间有1:
1联系。
职工之间的上下级联系有1:
N联系。
零件之间存在着组合关系，一种零件由许多种零件组成，而一种零件也可以是其他零件的零件。
三元联系连通词方式：
某商业集团中，商店、仓库、商品之间存在着进货联系。
13.2.3.3联系的基数
有两个实体集E1和E2，E1中每个实体与E2中有联系实体的数目的最小值min和最大值max，称为E1的基数，用（min，max）形式表示。
学校里规定每学期学生至少选修一门课程，最多选修六门课程，每门课程至多有50人选修，最少可以没人选修。
也就是，学生的基数是（1，6），课程的基数是（0，50）。
教师和课程之间有1：
N联系。
如果进一步规定，每位教师可讲授3门课，也可只搞研究而不教课；每门课程必须有一位教师上课。
也就是，教师的基数是（0，3），课程的基数是（1，1）。
13.2.4ER模型的操作
在数据库设计过程中，常常要对ER图进行各种变化。
这种变化称为ER模型的操作，包括实体类型、联系类型和属性的分裂、合并、增删等。
13.2.5采用ER方法的概念设计步骤
利用ER方法进行概念设计，可以分成三步进行：
1）设计局部ER模式：
具体过程如图。
2）综合成全局ER模式：
具体过程如图。
3）全局ER模式的优化：
进行相关实体类型的合并，以减少实体类型的个数；尽可能消除实体中的冗余属性；尽可能除掉冗余的联系类型。
13.3ER模型到关系模型的转换
13.3.1ER图转换成关系模式集的规则
规则1（实体类型的转换）将每个实体类型转换成一个关系模式，实体的属性即为关系模式的属性，实体标识符即为关系模式的键。
规则2（联系类型的转换）根据不同的情况做不同的处理。
二元联系类型的转换
若实体间联系是1：
1，可以在两个实体类型转换成的两个关系模式中任意一个关系模式的属性中加入另—个关系模式的键（作为外键）和联系类型的属性。
若实体间联系是1：
N，则在N端实体类型转换成的关系模式中加入1端实体类型的键（作为外键）和联系类型的属性。
若实体间联系是M：
N，则将联系类型也转换成关系模式，其属性为两端实体类型的键加上联系类型的属性，而键为两端实体键的组合。
一元联系类型的转换
和二元联系类型的转换类似。
三元联系类型的转换
不管联系类型是何种方法，总是将三元联系类型转换成关系模式，其属性为三端实体类型的键加上联系类型的属性，而键为三端实体键的组合。
但应注意，由于三元联系比较复杂，这样设计出来的关系模式可能有冗余现象，因此有可能还需用规范化理论进行处理。
13.3.2转换实例
例1：
工厂里车间与产品存在着1：
1联系（二元联系）
车间（车间号，名称，电话，产品编号，月计划量）
产品（产品编号，名称，规格，型号）
例2：
工厂里部门与职工存在着1：
N联系（二元联系）
部门（部门号，名称，电话）
职工（职工号，姓名，性别，年龄，部门号，工资）
例3：
工厂里产品与零件存在着M：
N联系（二元联系）
产品（产品编号，名称，规格，型号）
零件（零件号，名称，库存量）
构成（产品编号，零件号，数量）
例4：
运动员名次之间存在着1：
1联系（一元联系）
运动员（编号，姓名，性别，名次，上一名运动员编号）
例5：
职工之间存在着上下级联系，即1：
N联系（一元联系）
职工（编号，姓名，性别，年龄，上级的职工编号）
例6：
零件之间存在着组合，即M：
N联系（一元联系）
零件（零件编号，名称，型号，规格）
组成（零件编号，子零件编号，数量）
例7：
三元联系
仓库（仓库号，名称，地址）
商店（商店号，名称）
商品（商品号，名称）
进货（商店号，商品号，仓库号，数量，日期）
13.3.3采用ER模型的逻辑设计步骤
1）导出初始关系模式
逻辑设计的第一步是把概念设计的结果（即全局ER模型）转换成初始关系模式
2）规范化处理
规范化的目的是减少乃至消除关系模式中存在的各种异常，改善完整性、一致性和存储效率。
规范化过程分为两个步骤：
（1）确定规范级别
规范级别取决于两个因素，一是归结出来的数据依赖的种类，二是实际应用的需要。
（2）实施规范化处理
确定规范级别之后，逐一考察关系模式，判断它们是否满足规范要求。
若不符合上一步所确定的规范级别，则利用相应的规范算法将关系模式规范化。
3）模式评价
模式评价的目的是检查已给出的数据库模式是否完全满足用户的功能要求，是否具有较高的效率，并确定需要加以修正的部分。
模式评价主要包括功能和性能两个方面。
4）模式修正
根据模式评价的结果，对已生成的模式集进行修正。
修正的方式依赖于导致修正的原因，如果因为需求分析、概念设计的疏漏导致某些应用不能得到支持，则应相应增加新的关系模式或属性；如果因为性能考虑而要求修正，则可采用合并、分解或选用另外结构的方式进行。
在经过模式评价及修正的反复多次后，最终的数据库模式得以确定，全局逻辑结构设计即告结束。
13.4范式和规范化方法
关系模式的好坏，用什么标准来衡量？
这个标准就是模式的范式（NormalForm，简记为NF）。
13.4.1函数依赖
在数据库中，属性值之间会发生联系，譬如一个学生只有一个姓名，一门课程只有一个任课教师，学生所学的一门课程只有一个总成绩，等等，这类联系称为函数依赖（FunctionalDependency，简记为FD）。
设关系模式R（U），X，Y是U的子集。
若对于R（U）的任意一个可能的关系R，R中不可能有两个元组在X中的属性值相等，而在Y中的属性值不等，则称X函数决定Y，或Y函数依赖于X，记作XY。
在R（U）中，如果XY，并且对于X的任何一个真子集X＇都有X＇-/Y（也就是X＇Y不成立），则称Y对于X完全函数依赖，记作
。
在R（U）中，若X
Y，但Y不完全函数依赖于X，则称Y对X部分函数依赖，记作
。
在R（U）中，若
，XY，YZ，则称Z对X传递函数依赖。
在R（U）中，设
，如果
，则K为R的候选键（CandidateKey），若候选键多于一个，则选定其中的一个作为主键（PrimaryKey）。
包含在任何一个候选键中的属性称为主属性（PrimaryAttribute），不包含在任何键中的属性称为非主属性（NonprimaryAttribute）。
在关系：
学生-课程（学号，学生姓名，课程号，课程名称，任课教师姓名，任课教师单位，课程成绩）中：
学号学生姓名
课程号课程名称
（学号，课程号）
课程成绩
课程号-/课程成绩
若学生姓名不重复，则：
学生姓名学号
13.4.2第一范式
设R是一个关系模式，R属于第一范式当且仅当R中的每一个属性A的值域只包含原子项，即不可再分的数据项，记为1NF（FirstNormalForm）。
13.4.3第二范式
设R是一个关系模式，R属于第二范式当且仅当R是1NF，且每个非主属性都完全函数依赖于主属性，记为2NF。
设关系模式R（学号，课程号，课程成绩，任课教师姓名，任课教师单位），（学号，课程号）是R的候选键。
例：
R上有两个函数依赖：
（学号，课程号）（任课教师姓名，任课教师单位）和
课程号（任课教师姓名，任课教师单位）
因此后一个函数依赖是部分函数依赖，R不是2NF模式。
此时R的关系就会出现冗余和异常现象。
譬如某一门课程有40个学生选修，那么在关系中就会存在40个元组，因而教师的姓名和单位就会重复40次。
如果把R分解成R1（课程号，任课教师姓名，任课教师单位）和R2（学号，课程号，课程成绩），部分函数依赖（课程号）（任课教师姓名，任课教师单位）就消失了。
R1和R2都是2NF。
13.4.4第三范式
设R是一个关系模式，R属于第三范式当且仅当R是1NF，且每个非主属性都不传递函数依赖于主属性，记为3NF。
例：
前例中的R1（课程号，任课教师姓名，任课教师单位），R1∈2NF，由于函数依赖：
课程号任课教师姓名，任课教师姓名任课教师单位，则：
课程号任课教师单位就是一个传递函数依赖，即R1不是3NF。
此时R1的关系中也会出现冗余和异常操作。
譬如一个教师开设五门课程，那么关系中就会出现五个元组，教师的单位就会重复五次。
如果把R1分解成R11（任课教师姓名，任课教师单位）和R12（课程号，任课教师姓名）后，课程号任课教师单位就不会出现在R11和R12中，这样R11和R12都是3NF模式。
13.4.5BCNF
BCNF（BoyceCoddNormalForm鲍依斯-科得范式）是由Boyce和Codd提出的，比3NF又进了一步。
通常认为BCNF是修正的3NF。
如果关系模式R是1NF，且每个属性都不传递依赖于R的候选键，那么称R是BCNF的模式。
也就是说关系模式R中，若每一个决定因素都包含键则R∈BCNF。
3NF的“不彻底”性表现在可能存在主属性对键的部分依赖和传递依赖。
例：
关系模式STC（S，T，C），S表示学生，T表示教师，C表示课程。
每一位教师只教一门课。
每门课有若干教师，某一学生选定某门课后就对应于一个固定的教师。
由语义可得到如下的函数依赖：
（S，C）T；（S，T）C；TC。
这里（S，C），（S，T）都可以作为候选键。
因为没有任何的非主属性对键传递依赖或部分依赖，所以STC是3NF，但STC不是BCNF，因为T是决定因素，而T不是键（T只是键的一部分）。
STC可以分解为ST（S，T），TC（T，C），他们都是BCNF。
ER模型实例分析
某高校要在网上进行选课。
学生首先输入自己的学号和密码进入登陆。
登陆成功后，该学生可以看到自己的相关信息：
学号、班级、姓名。
然后该学生可以浏览可选的课程，查阅自己已选的课程，以及感兴趣课程的简介。
学生的信息有：
学号、班级、姓名、密码。
课程信息有：
课程编号、课程名称、学分数、上课时间、地点、限选人数、课程简介。
课程分为两类：
文化素质课和公共选修课。
教师的信息有：
职工号、姓名、单位。
该校规定：
一门课程可以被多名学生选修，也可以由多名教师开设，且一名教师一学期只能开设同一门课程一次。
一名学生最多可选不超过两门同类型的课程。
一名教师可以教多门课程。
要求：
1.请画出选课系统的E-R图
2.将E-R图转换为关系模式
3.分析每一个关系模式符合哪一级范式
4.用DDL写出关系模式的表定义语句
5.写出查询语句：
1）查询文化素质课的课程列表，包括：
课程编号、课程名称、教师姓名、学分数、上课时间、限选人数、已选人数。
2）查询某门课程的详细信息：
课程编号、课程名称、学分数、上课时间、地点、授课教师、详细简介。
3）查询某位同学的选修课程表：
学生姓名、所选课程名称、上课时间、地点、教师姓名。
4）查询某位同学所选课程的教学班名条：
课程编号、课程名称、教师、学号、姓名（以学号为序）
5）教师的授课门数（教师姓名、授课门数）
6）学生的选课门数（学号、姓名、选课门数）
7）不到限选人数1/3的课程（课程编号、课程名称、授课教师的姓名）
8）查询没选课的同学
9）查询没上课的教师
10）查询所有学生和他们的选课情况，包括：
学号，姓名，课程编号、课程名称、学分数
11）查询所有的教师和他们的授课情况，包括：
职工号，姓名，课程编号、课程名称、学
升级会员 