7.1 设计过程概览
7.1 设计过程概览
构建一个数据库应用是一个复杂的任务,包括
- 设计数据库模式,
- 设计访问和更新数据的程序,
- 以及设计控制数据访问的安全模式。
用户的需求在设计过程中扮演一个中心角色。本章主要关注于数据库模式的设计,不过本章后面会简要地概括其他几个设计任务。
7.1.1 设计阶段
对于小型的应用,由一个理解应用需求的数据库设计者直接决定要构建的关系、关系的属性以及其上的约束,这样也许是可行的。但是,这种直接的设计过程在现实的应用中是困难的,由于现实的应用常常很复杂,通常没有一个人能够理解应用的所有数据需求。
数据库设计者必须与应用的用户进行交互以理解应用的需求,把它们以用户能够理解的高级别的形式表示出来,然后再将需求转化为较低级别的设计。
一个高层数据模型为数据库设计者提供了一个概念框架,在该框架中以系统的方式定义了数据库用户的数据需求,以及满足这些需求的数据库结构。
- 数据库设计的
最初阶段需要完整地刻画未来数据库用户的数据需求。为完成这个任务,数据库设计者需要同应用领域的专家和用户进行深入的沟通。这一阶段的产品是用户需求规格说明。虽然存在图形方式的用户需求表示技术,但是在本章中,我们仅限于采用文字的方式来描述用户需求。 - 接下来,设计者选择数据模型,并采用所选数据模型的概念将这些需求转化为数据库的概念模式。
- 在此概念设计(
conceptual-design)阶段所产生的模式提供了一个对企业的详细综述。我们在本章中将研究的**实体-联系模型通常用于表示概念设计**。用实体-联系模型的术语来说,概念模式定义了数据库中表示的实体、实体的属性、实体之间的联系,以及实体和联系上的约束。通常,概念设计阶段会导致实体-联系图的构建,它提供了对模式的图形化描述。设计者检查此模式以确保所有数据需求都满足,并且互相不冲突。还可以检查该设计以去除冗余的特征。在这个阶段关注的是描述数据及其联系,而不是定义物理存储细节。
- 在此概念设计(
- 完善的概念模式还指明企业的功能需求。在功能需求规格说明(
specification of functionalrequirement)中,用户描述将在数据上进行的各类操作(或事务)。操作的例子包括修改或更新数据,搜索并取回特定数据,以及删除数据。在概念设计的这一阶段,设计者可以检查所设计的模式,以确保其满足功能需求。 - 从抽象数据模型到数据库实现的转换过程在最后两个设计阶段中进行。
- 在逻辑设计阶段(
logical-design phase)中,设计者将高层概念模式映射到将使用的数据库系统的实现数据模型上。实现数据模型通常是关系数据模型,**该阶段通常包括将以实体联系模型定义的概念模式映射到关系模式**。 - 最后,设计者将所得到的系统特定的数据库模式使用到后续的物理设计阶段(
physical-design phase)中。在该阶段,指明数据库的物理特征,这些特征包括文件组织格式和索引结构的选择,我们将在第10章和第11章讨论这些内容。
- 在逻辑设计阶段(
改变物理模式相对简单
在应用建立之后,要改变数据库的物理模式相对地比较简单。
改变逻辑模式比较困难
但是,由于可能影响到应用程序代码中散布的大量的査询和更新操作,因此改变逻辑模式的任务执行起来常常更加困难。
因此,在建立后续的数据库应用之前,慎重实施数据库设计阶段是非常重要的。
小结
- 概念设计阶段,得到E-R图
- 逻辑设计结果,根据E-R图得到关系模式
- 物理设计阶段,指定数据库的物理特征,如文件的组织格式,索引结构的选择
7.1.2 设计选择
数据库设计过程的一个主要部分是决定如何在设计中表示各种类型的”事物”,比如人、地方、产品,诸如此类。
我们使用实体(eniy)这个术语来指示所有可明确识别的个体。在一个大学数据库中,实体的例子将包括教师、学生、系、课程和开课°。这些各种各样的实体以多种方式互相关联,而所有这些方式都需要在数据库设计中反映出来。例如,一名学生在一次开课中选课,而一名教师在一次开课中授课,授课和选课就是实体间联系的实例。
要避免的数据库模式缺陷
在设计一个数据库模式的时候,我们必须确保避免两个主要的缺陷。
1 冗余
一个不好的设计可能会重复信息。例如,如果对于每一次开课我们都存储课程编号和课程名称,那么对于每一次开课我们就冗余地(即多次地、不必要地)存储了课程名称。对每次开课仅存储课程编号,并在一个课程实体中将课程名称和课程编号关联一次就足够了。
- 冗余也可能出现在关系模式中。在目前我们所使用的大学的例子中,我们有一个开课信息的关系和一个课程信息的关系。假设换一个做法,我们只有一个关系,对一门课程的每一次开课我们将全部课程信息(课程编号、课程名、系名、学分)重复一次。很明显,关于课程的信息将冗余地存储。
- 信息的这种冗余表达的最大问题是当对一条信息进行更新但没有将这条信息的所有拷贝都更新时,这条信息的拷贝会变得不一致。例如,拥有同一个课程编号的几次不同的开课可能会拥有不同的课程名称,于是会搞不清楚课程的正确名称是什么。理想的情况下,信息应该只出现在一个地方。
2 不完整
一个不好的设计可能会使得企事业机构的某些方面难于甚至无法建模。例如,假设在上述案例(1)中,我们只有对应于开课的实体,而没有对应于课程的实体。从关系的角度说,这就是假设我们有单个关系,对一门课程的每一次开课都重复存储课程的所有信息。那么一门新课程的信息将无法表示,除非开设了该课程。我们可能会尝试将开课信息设置为空值的方法来解决这个有问题的设计。这种绕开问题的措施不仅不吸引人,而且有可能由于主码约束而无法实行。
仅仅避免不好的设计是不够的。可能存在大量好的设计,我们必须从中选择一个。作为一个简单的例子,考虑买了某产品的一个客户。该产品的销售是客户和产品之间的联系吗?还是销售本身是一个与客户和产品都相关的实体?这个选择,虽然简单,却可能对企业某些方面建模的好坏有很大的影响。考虑为一个现实企业中的大量实体和联系做类似这样的选择的需要,不难看出数据库设计是一个很有挑战性的问题。事实上我们将看到,它需要科学和”好的品味”的结合。