系统维护阶段

第2章　数据库应用系统设计

2.1　函数依赖

函数依赖是属性之间的一种联系。如果一个关系模式设计得不好，说明在它的某些属性之间存在“不良”的函数依赖。

设在关系R中，X和Y为R的两个属性子集，如果每个X值只有一个Y值与之对应，则称属性Y函数依赖于属性X；或称属性X唯一确定属性Y，记作X→Y。

如果X→Y，同时Y不包含于X，则称X→Y是非平凡的函数依赖。若不特别声明，我们总是讨论非平凡的函数依赖。

函数依赖是最基本的，也是最重要的一种数据依赖。要从属性间实际存在的语义来确定它们之间的函数依赖。

设在关系R中，X和Y为R的两个属性子集，若X→Y，且对于X的任何一个真子集X′，都不存在X′→Y，则称Y完全函数依赖于X，否则称Y部分函数依赖于X。

设在关系R中，X，Y，Z为R的三个属性子集，若X→Y，Y→Z，且X不依赖于Y，则称Z传递函数依赖于X。

2.2　范式与规范化

2.2.1　什么是范式

规范化的基本思想是消除关系模式中的数据冗余，消除数据依赖中不合适的部分，解决数据插入、更新、删除时发生的异常现象。这就要求关系数据库设计出来的关系模式要满足规范的模式，即“范式”（Normal Form）。

2.2.2　第一范式

第一范式（1NF）是最基本的规范形式，即在关系中每个属性都是不可再分的简单项。

例如表2-1中，“收入”不是最基本的数据项，它还可以分为“基本工资”和“课时津贴”两个数据项，因此它不满足第一范式。

表2-1　教工信息表

只要将不满足第一范式的属性分解，表示为不可再分的数据项，即满足第一范式。转换后如表2-2所示。

表2-2　教学信息表（修改后）

2.2.3　第二范式

如果关系模式满足第一范式，并且每个非主属性都完全依赖于任意一个候选关键字，则称这个关系满足第二范式（2NF）。

例如，学生选课表结构（见表2-3）。

表2-3　学生选课表

表2-3的主键是（学号，课程编号），由此复合字段唯一确定一条记录。此表满足第一范式，但是还存在一些问题。比如“课程名称”和“学分”这两个非主属性完全并不完全依赖于主关键字，而是完全依赖于主关键字中的“课程编号”字段。即存在非主属性部分依赖于主关键字的情况，所以不满足第二范式。由此可能产生一些问题，比如有100个学生选修“计算机基础”这门课程，学分就被重复记录了100次；再如，如果调整了“计算机基础”这门课程的学分，则所有记录的“学分”字段都要更新，等等。

解决的方法是将关系模式进一步分解，分解成两个关系模式：学生选课（学号，课程编号，成绩），如表2-4所示；课程（课程编号，课程名称，学分），如表2-5所示。

表2-4　选课表

表2-5　课程表

这样就符合第二范式的要求了。

2.2.4　第三范式

在第二范式的基础上，如果关系模式中的所有非主属性对任何候选关键字都不存在传递依赖，则称这个关系属于第三范式（3NF）。

例如，教师情况如表2-6所示。

表2-6　教师情况表

在表2-6中，“教工编号”是关键字，单个关键字不存在部分依赖的问题，因此它满足第二范式。但是在该表中，“院系名称”和“院系地址”多次被重复存储，不仅仅有数据冗余的问题，也有插入、修改和删除时的异常问题。

这些问题是由于“院系名称”和“院系地址”依赖于“院系编号”，而“院系编号”又依赖于“教工编号”，因此存在传递依赖的问题。

要使关系模式符合第三范式的要求，必须消除传递依赖。可将其分解为两个关系：教师（教工编号，姓名，院系编号）和院系（院系编号，院系名称，院系地址），如表2-7、表2-8所示。

表2-7　教师表

表2-8　院系表

2.2.5　BCNF范式

BCNF是第三范式的改进形式。如果关系模式的所有属性（包括主属性和非主属性）都不传递依赖于关系模式的任何候选关键字，则称这个关系属于BCNF范式。

例如，学生选课表（见表2-9）。

表2-9　学生选课表

在表2-9中，假设“姓名”没有重复值，因此有两个候选关键字（学号，课程名称）和（姓名，课程名称），其中主属性是“学号”，“姓名”和“课程名称”，非主属性是“成绩”。非主属性并不传递依赖于两个候选关键字，因此该关系模式满足第三范式。但是，主属性“姓名”依赖于“学号”，因此部分依赖于候选关键字（学号，课程名称），也就是传递依赖于（学号，课程名称）。

虽然没有非主属性对候选关键字的传递依赖，但存在主属性对候选关键字的传递依赖，同样也会带来麻烦。例如，新生入学，因为没有选课，“姓名”就不能加入到表中。

解决办法是将其分解为两个关系（见表2-10、表2-11），这样两个关系都属于BCNF范式。

表2-10　学生表

表2-11　成绩表

2.2.6　规范化设计小结

规范化的目的是将结构复杂的关系模式分解成结构简单的关系模式，从而把不好的关系模式转变为好的关系模式。

范式的等级越高，应满足的约束条件也越严格。每一级别都依赖于它的前一级别，例如，若一个关系模式满足2NF，则一定满足1NF。

一般来说，将不好的关系模式转化为好的关系模式的方法是将关系模式分解成两个或两个以上的关系模式。

在数据库设计过程中，1NF很容易遵守，大部分的关系模式设计能够满足3NF就比较容易维护了。

规范化的优点是减少了数据冗余，节约了存储空间，同时加快了增、删、改的速度，但在数据查询方面，往往需要进行关系模式之间的联接操作，过高的数据分离有时候会影响查询的速度。因此，并不一定要求全部模式都达到BCNF，有时故意保留部分冗余可能更方便进行数据查询。

2.3　数据库应用系统的设计过程

数据库设计是指对于一个给定的环境，构造优化的数据库逻辑模式和物理结构，并以此建立数据库及管理信息系统，进行有效存储和管理数据，满足用户的应用需求。按照规范设计的方法，考虑数据库及其应用系统开发过程，将数据库应用系统的设计分为以下4个阶段：

（1）系统分析阶段。

（2）系统设计阶段。

（3）系统实施阶段。

（4）系统维护阶段。

2.3.1　系统分析阶段

1．了解需求

简单地说，需求分析就是分析用户的要求。需求分析是设计数据库的起点，其结果是否准确直接影响后面各个阶段的设计。

在数据库应用系统开发的需求分析阶段，要完成的任务是通过详细调查现实世界要处理的对象（企业、部门等），充分了解原来系统的工作情况，明确用户的各种需求，然后在此基础上确定新系统的功能。最终需求的确定不是一件简单的事情，因为一方面用户可能不太了解计算机能够为自己做什么，或者不能准确表达出自己的实际需求；另一方面，设计人员缺乏相关专业知识，不能准确理解用户的需求，甚至误解用户的需求。因此需要与用户不断深入地反复交流才能逐步确定用户的实际需求。

例如，某高校有工会学院、法学系、公共管理系、文传学院等下属院系，教职工800多人，在校本科生4000多人。该校的主要教学管理工作有：

（1）制定教学计划，安排课程开设计划等。

（2）学生基本信息管理。

（3）教师基本信息管理。

（4）学生成绩查询与统计。

（5）教师授课情况查询与统计。

手工完成教学管理工作的劳动量非常大，为了实现教学工作管理信息化，该校拟开发教学管理信息系统。

2．可行性研究

可行性主要是指建立新的管理信息系统的必要性和可能性。可能性主要包括经济可行性、技术可行性和社会可行性。

经济可行性是做投资估算，对开发所需要的软件、硬件、人力成本等投入和带来的经济效益产出进行估算。

技术可行性是确定根据现有的技术条件是否可以顺利完成开发工作。

社会可行性是对系统投入使用后带来的社会影响进行分析。

开发人员对某学院的教学管理工作进行了详细的调查后认为，教学管理是一个教学单位不可缺少的部分，并且教学管理的水平和质量对教育过程的影响至关重要。但传统的手工管理方式效率低，时间一长，将产生大量的文件和数据，这对于查找、更新和维护都带来了不少的困难。使用计算机进行教学管理，优点是检索迅速、查找方便、可靠性高、存储量大、保密性好等，大大提高了教学管理工作的效率和质量。因此开发“教学管理系统”是必要的，同时，从经济、技术、社会三方面分析也是可行的。

3．提出总需求目标

经过需求分析和可行性研究，确定了教学管理信息系统的开发目标是：由教学管理工作人员使用，可完成学生信息管理、教师信息管理、课程信息管理、成绩信息管理等功能的小型数据库管理信息系统。

2.3.2　系统设计阶段

1．功能模块设计

根据上述对教学管理业务流程和数据流程的调查分析，可将系统划分为图2-1所示的功能模块结构。

图2-1　系统功能设计图

教师管理模块：对教师的基本信息进行管理；对教师的授课信息进行管理；对教师工作量和工作成绩进行计算和评估；具备信息查询功能。

学生管理模块：对学生的基本信息进行管理；对学生选课信息进行管理；对学生成绩进行登记、统计管理；具备查询功能。

课程模块：对全校所开课程的类别设置、学分设置、学时设置、其他等设置进行管理。

2．数据库设计

1）确定实体和属性

为了利用计算机完成这些繁杂的教学管理任务，必须存储院系、教师、学生、课程、成绩等大量的信息，因此教学管理系统中的实体应包括：院系、教师、人事档案、课程、学生。

这些实体的E-R图如图2-2~图2-6所示。

图2-2　院系E-R图

图2-3　教师E-R图

图2-4　人事档案E-R图

图2-5　学生E-R图

图2-6　课程E-R图

2）确定实体间的联系类型

每个院系有不同的教师和学生，而教师和学生只能隶属于某一个院系。因此，院系与教师、院系与学生是一对多联系。

每个教师可以教授多门课程，教师与课程是一对多联系。

每个教师都有唯一的一份人事档案记录，教师与人事档案是一对一联系。

每个学生可以选修多门课程，每门课程也可以对多个学生选修，学生与课程是多对多联系。

上述联系类型用图2-7表示。

图2-7　实体间关系E-R图

3）转换为关系模式

将用E-R图表示的概念模型转换为关系模型时，要遵循以下原则：

（1）一对一联系中，将其中一个“一”端的主键作为外键放在另外一个“一”端中。

例如，实体“教师”与“人事档案”是一对一联系，教师编号是实体“教师”的主键，转换成的关系模式为：

教师（教师编号，姓名，性别，出生日期，联系电话，电子邮件，家庭住址）

人事档案（档案编号，教师编号，最高学历，毕业日期，毕业院校，职称，政治面貌，所获奖励，所受处分）

说明：关系的主键用下划线标出。

（2）一对多联系中，将“一”端的主键作为外键放在“多”端中。

例如，实体“院系”与“教师”，实体“院系”与“学生”，实体“教师”与“课程”是一对多联系，将实体“院系”的主键“院系编号”作为外键放入“教师”、“学生”中，将“教师”的主键“教师编号”作为外键放入“课程”中，转换成的关系模式为：

院系（院系代码，院系名称，办公电话，办公地址，院系领导）

教师（教师编号，姓名，性别，出生日期，联系电话，电子邮件，家庭住址，院系编号）

学生（学号，姓名，性别，出生日期，籍贯，专业，照片，备注，院系编号）

课程（课程编号，课程名称，学分，学时，课程简介，授课教师编号）

（3）多对多联系中，除了将连个“多”端的实体转换为关系之外，还要将联系本身转换成一个关系模式，它的主键由两个“多”端的主键组合而成。

例如，实体“学生”与“课程”是多对多“选修”联系，将联系“选修”单独转换为一个关系，其主键为“学生”与“课程”主键的组合。转换成的关系模式为：

学生（学号，姓名，性别，出生日期，籍贯，专业，照片，备注，院系编号）

课程（课程编号，课程名称，学分，学时，课程简介，授课教师编号）

选修（学号，课程编号，选修学期，成绩，备注）

经过以上转换过程，最终形成的关系模式为：

院系（院系代码，院系名称，办公电话，办公地址，院系领导）

教师（教师编号，姓名，性别，出生日期，联系电话，电子邮件，家庭住址，院系编号）

人事档案（档案编号，教师编号，最高学历，毕业日期，毕业院校，职称，政治面貌，所 获奖励，所受处分）

学生（学号，姓名，性别，出生日期，籍贯，专业，照片，备注，院系编号）

课程（课程编号，课程名称，学分，学时，课程简介，授课教师编号）

选修（学号，课程编号，选修学期，成绩，备注）

4）规范化理论应用

对于转换后的关系模式，应按照数据库规范化设计原则检验其好坏。经检验，转换后关系模式都符合数据库规范化设计原则。

2.3.3　系统实施阶段

系统的实施包括两项重要的工作：一项是数据的入库；另一项是应用系统模块的开发和调试。

在应用系统模块的开发过程中，采用“自顶向下”的设计思路和步骤来开发系统，把整个大的应用系统划分成若干个相对独立的小系统。通过系统菜单或控制面板逐级控制低一层的模块，确保每个模块完成一个独立的任务，并受控于上层模块。

2.3.4　系统维护阶段

维护阶段的任务是修正数据库应用系统的缺陷，增加新的性能。虽然应用系统已经开始运行，但是由于工作环境和实际需求的不断变化，还需要对数据库应用系统进行评价、调整、修改等维护工作，这是一个长期的任务，也是设计工作的继续和提高。

思考题

（1）什么是函数依赖？

（2）实体间的联系有哪些类型？

（3）什么是范式？

（4）简述第一范式、第二范式和第三范式的定义。

（5）简述数据库应用系统的设计过程。

（6）如何进行数据库结构设计？

（7）E-R图如何转换为关系模式？