• 1.6 数据库设计
• 1.6.1 设计过程
  • 确定需求
  • 概念设计阶段
  • 逻辑设计阶段
  • 物理设计阶段
• 1.6.2 大学机构的数据库设计
• 1.6.3 实体-联系模型
  • 什么是实体
  • 通过属性的集合来描述实体
  • 什么是联系
  • 什么是实体集
  • 什么是联系集
  • 实体-联系图 entity-relationship diagram E-R图
    • E-R图符号
    • 映射基数
• 1.6.4 规范化

1.6 数据库设计

数据库设计的主要内容是数据库模式的设计。为设计一个满足企业需求模型的完整的数据库应用环境还要考虑更多的问题。在本书中,我们先着重讨论数据库查询语句的书写以及数据库模式的设计,第9章将讨论应用设计的整个过程。

1.6.1 设计过程

确定需求

高层的数据模型为数据库设计者提供了一个概念框架,去说明数据库用户的数据需求,以及将怎样构造数据库结构以满足这些需求。因此,数据库设计的初始阶段是全面刻画预期的数据库用户的数据需求。为了完成这个任务,数据库设计者有必要和领域专家、数据库用户广泛地交流。这个阶段的成果是制定出用户需求的规格文档。

概念设计阶段

下一步,设计者选择一个数据模型,并运用该选定的数据模型的概念,将那些需求转换成一个数据库的概念模式。在这个概念设计阶段开发出来的模式提供了企业的详细概述。设计者再复审这个模式,确保所有的数据需求都满足并且相互之间没有冲突,在检查过程中设计者也可以去掉些冗余的特性。这一阶段的重点是描述数据以及它们之间的联系,而不是指定物理的存储细节。
从关系模型的角度来看,概念设计阶段涉及决定数据库中应该包括哪些属性,以及如何将这些属性组织到多个表中。前者基本上是商业的决策,在本书中我们不进一步讨论。而后者主要是计算机科学的问题,解决这个问题主要有两种方法:

• 一种是使用实体-联系模型(见1.6.3节),
• 另一种是引入一套算法(通称为规范化),这套算法将所有属性集作为输入,生成一组关系表(见1.6.4节)。

一个开发完全的概念模式还将指出企业的功能需求。在功能需求说明中,用户描述数据之上的各种操作(或事务),例如更新数据、检索特定的数据、删除数据等。在概念设计的这个阶段,设计者可以对模式进行复审,确保它满足功能需求。

逻辑设计阶段

在逻辑设计阶段( logical-designphrase),设计者将高层的概念模式映射到要使用的数据库系统的数据模型上;这样,设计者将得到的特定系统的数据库模式

物理设计阶段

在这个阶段中指定数据库的物理特性,这些特性包括文件组织的形式以及内部的存储结构,这些内容将在第10章中讨论。

1.6.2 大学机构的数据库设计

为了阐明设计过程,我们来看如何为大学做数据库设计。初始的用户需求说明可以基于与数据库用户的交流以及设计者自己对大学机构的分析。这个设计阶段中的需求描述是制定数据库的概念结构的基础。以下是大学的主要特性:

• 大学分成多个系。每个系由自己唯一的名字(dept_name)来标识,坐落在特定的建筑物(building)中,有它的经费预算(budget)。
• 每一个系有一个开设的课程列表。每门课程有课程号(course_id)、课程名(title)、系名(dept_name)和学分( credits),还可能有先修要求(prerequisites)。
• 教师使用唯一的标识号(ID)来标识。每位教师有姓名(name)、所在的系(dept_name)和工资(salary).
• 学生使用唯一的标识号(ID)来标识。每位学生有姓名(name)、主修的系(dept_name)和已修学分数( tot_cred)。
• 大学维护一个教室列表,详细说明楼名(building)、房间号( room_number)和容量(capacity)
• 大学维护开设的所有课程(开课)的列表。课程由课程号( course_id)、开课号(sec_id)、年(year)和学期( semester)来标识,与之相关联的有学期(semester)、年(year)、楼名(building)、房间号(room_number)和时段号(time_slot_id,即上课的时间)。
• 系有一个教学任务列表,说明每位教师的授课情况。
• 大学有一个所有学生课程注册的列表,说明每位学生选择了哪些课程的哪个课程。

一个真正的大学数据库会比上述的设计复杂得多。然而,我们就用这个简化了的模型来帮助你理解概念思想,避免你迷失在复杂设计的细节中。

1.6.3 实体-联系模型

实体-联系(E-R)数据模型描述了一组称作实体的基本对象之间的联系。

什么是实体

实体是现实世界中可区别于其他对象的一件”事情”或一个”物体”。例如,每个人是一个实体,每个银行账户也是个实体。

通过属性的集合来描述实体

数据库中通过属性集合来描述实体。例如,属性dept_name、 building与budget可以描述大学中的一个系,并且它们也组成了department实体集的属性。类似地,ID、name和salary这几个属性可以描述instructor实体。

因为可能存在两位教师有相同的名字和相同的工资,但又必须给每位教师分配唯一的教师标识,所以我们用额外的属性ID来唯一标识教师。在美国,社会保障号是美国政府分配给每个美国人的一个唯一的号码,所以许多机构用一个人的社会保障号作为他的唯一标识。

什么是联系

联系(relationship)是几个实体之间的关联。例如, member联系将一位教师和她所在的系关联在起。

什么是实体集

同一类型的所有实体的集合称作实体集(entity set),

什么是联系集

同一类型的所有联系的集合称作联系集(relationship set)。

实体-联系图 entity-relationship diagram E-R图

数据库的总体逻辑结构(逻辑模式)可以用实体-联系图进行图形化表示。有几种方法来画这样的图。最常用的方法之一是采用统一建模语言(UML)。

E-R图符号

在我们使用的基于UML的符号中,E-R图如下表示:

• 实体用矩形框表示,实体名在头部,属性名列在下面。
• 联系用连接两个相关的实体集的菱形表示,联系名放在菱形内部

作为例子,我们来看一下大学数据库中包括教师和系以及它们之间的关联的部分。对应的E-R图如图1-3所示。E-R图表示出有instructor和departmen这两个实体集,它们具有先前已经列出的一些属性。这个图还指明了在教师和系之间的member联系。

映射基数

除了实体和联系外,E-R模型还描绘了数据库必须遵守的对其内容的某些约束。一个重要的约束是映射基数,它表示通过某个联系集能与一实体进行关联的实体数目。例如,如果一位教师只能属于一个系,E-R模型就能表达出这种约束。
实体-联系模型在数据库设计中使用广泛,在第7章中将详细研究。

1.6.4 规范化

设计关系数据库所用到的另外一种方法是通常被称为规范化的过程。规范化的目标是生成一个关系模式集合,使我们存储信息时没有不必要的冗余,同时又能很轻易地检索数据。
这种方法是设计一种符合适当的范式的模式,为确定一个关系模式是否符合想要的范式,我们需要额外的 关于用数据库建模的 现实世界中机构的信息。最常用的方法是使用函数依赖(functional dependency),我们将在8.4节讨论。

为了理解规范化的必要性,我们看一看在不好的数据库设计中会发生什么问题。一个不好的设计可能会包括如下不良特性:

1. 信息重复
2. 缺乏表达某些信息的能力

规范化的详尽理论已经研究形成,它有助于形式化地定义什么样的数据库设计是不好的,以及如何得到我们想要的设计。第8章将讨论关系数据库设计,包括规范化。

原文链接: 1.6 数据库设计