第一章 - 数据库基础理论

第一章 - 数据库基础理论

1.1 数据库概述

数据库技术是计算机科学的重要组成部分，也是信息管理的技术依托，主要用于研究如何向用户提供具有共享性、安全性和可靠性数据的方法。数据库技术解决了计算机信息处理过程中有效地组织和存储海量数据的问题。而大数据的发展更是将数据库技术的应用平台推上一个新的高度。数据库的建设规模、数据信息的存储量度和处理能力已成为衡量一个国家现代化程度的重要标志。

数据库技术包括数据库系统、SQL语言、数据库访问技术等。像MySQL、Oracle、SQL Server和DB2等都是目前常用的数据库管理系统软件。尤其是MySQL已经成为目前软件行业市场份额提高最快的数据库软件。

信息技术的发展极大地促进了数据库技术向各行各业的渗透，数据库与其他学科技术结合先后出现了各种形式的数据库系统分支。

1.1.1 数据与数据库

1、数据和信息

数据(Data) 是描述事物的符号记录，它有多种表现形式，可以是文本、图表、图形、图像、声音、语言、视频等。

信息(Information) 是具有特定意义的数据。信息不仅具有能够感知、存储、加工、传播和再生等自然属性，同时也是具有重要价值的社会资源。信息是用一定的规则或算法筛选的数据集合。

2、数据库

数据库(Database，DB) 是存储在计算机内、有组织、可共享的数据和数据对象（如表、视图、存储过程和触发器等）的集合。

数据库中的数据需要创建数据模型来描述，如网络、层次、关系模型。在数据库中的数据具有冗余度小、独立性高和易扩展性的特点。用户可以对其中的数据进行新增、删除、修改、查询等操作。

3、数据库管理系统

数据库管理系统(Database Management System，DBMS) 位于用户和操作系统之间，是一种操纵和管理数据库的大型软件，用于建立、使用和维护数据库。像Oracle、SQL Server 和DB2都是常用的数据库管理系统软件。

DBMS提供了数据定义语言(DDL)、数据操作语言(DML)和应用程序。数据库管理系统是由多种不同的程序模块组成，基本数据库管理系统的系统架构包括4部分。

image

存储管理(Storage Manager) ：数据库管理系统通常会自行配置磁盘空间，将数据存入存储装置的数据库。

查询处理(Query Processor) ：负责处理用户下达的查询语言命令语句，可以再细分成多个模块负责检查语法、优化查询命令的处理程序。

事务管理(Transaction Manager) ：负责处理数据库的事务，保障数据库商业事务的操作需要,及并发控制管理(Concurrency- Control Manager)资源锁定等。

恢复管理(Recovery Manager) ：恢复管理主要是日志管理(Log Manager)，负责记录数据库的所有操作，可以恢复数据库系统存储的数据到指定的时间点。

4、数据库系统

数据库系统（Data Base System，简称DBS） 通常由软件、数据库和数据管理员组成。其软件主要包括操作系统、各种语言、实用程序以及数据库管理系统。

数据库系统的组成

image

用户(Users) ：用户执行DDL语言定义数据库架构，使用DML语言新增、删除、更新和查询数据库的数据，通过操作系统访问数据库的数据。第一类为系统分析员和数据库设计人员；第二类为应用程序员；第三类为最终用户；第四类用户是数据库管理员（data base administrator，DBA），负责数据库的总体信息控制。

数据(Data) ：数据库系统中的数据种类包括永久性数据、索引数据、数据字典和事务日志等。

软件(Software) ：指在数据库环境中使用的软件，包括数据库管理系统(DBMS)、应用程序和开发工具等。

硬件(Hardware) ：安装数据库相关软件的硬件设备，包含主机(CPU、内存和网卡等)、磁盘阵列、光驱和备份装置等。

1.1.2 数据库发展历程

人工管理阶段 -> 文件系统阶段 -> 数据库管理

image

1、人工管理阶段

20世纪50年代中期以前，计算机主要用于科学计算，硬件方面只有卡片、纸带、磁带等，没有可以直接访问、直接存取的外部存储设备；软件方面也没有专门的管理数据的软件；数据由应用程序自行携带，数据与数据不能长期保存。

image

人工管理阶段的特点：

  • 数据不进行保存；
  • 没有专门的数据管理软件；
  • 数据面向应用；
  • 基本上没有文件的概念

2、文件系统阶段

20世纪50年代中期到60年代中后期，计算机大量应用用于数据处理，硬件出现了可以直接存取的磁盘、磁鼓，软件则出现了高级语言和操作系统，以及专门管理外存的数据管理软件，实现了按文件访问的管理技术。

image

文件系统阶段特点：

  • 程序与数据有了一定的独立性，程序与数据分开，文件系统提供数据与程序之间的存取方法；
  • 数据文件可以长时间保存在外存上，可以进行诸如查询、修改、插入、删除等操作；
  • 数据冗余量大，缺乏独立性，无法集中管理；
  • 文件之间缺乏联系，相互独立，不能反应显示世界各种食物之间错综复杂的联系。

3、数据库系统阶段

从20世纪60年代后期开始，根据实际需要发展了数据库技术。数据可是通用化的相关数据集合，它不仅包括数据本身，而且包括数据之间的联系。为了让多种应用程序并发地使用数据库中具有最小冗余的共享数据，必须使数据与程序具有较高的独立性，这就需要有一个软件系统对数据实行专门的管理，提供安全性和完整性等统一控制，方便用户以交互命令或程序方式对数据库进行操作。为数据库的建立、使用和维护而配置的软件称为数据库管理系统。

image

数据库系统阶段特点

  • 数据结构化数据共享性和独立性好；
  • 数据存储力度小；
  • 数据库管理系统对数据进行统一的管理和控制；
  • 为用户提供了友好的接口。

4、数据库系统的体系结构

数据库系统的体系结构主要包括如下几种结构： 集中式 、 客户-服务器式 、 浏览器-服务器式 和 分布式 等。

集中式结构 ：集中式系统是指运行在一台计算机上，不与其它计算机系统交互的数据库系统,例如运行在个人计算机上的单用户数据库系统和运行在大型主机上的高性能数据库系统。

C/S结构 ：C/S结构的客户端系统主要包括图形用户界面工具、表格及报表生成和书写工具等；服务器系统负责数据的存取和控制，包括故障恢复和并发控制等。客户机通过网络将要求传递给服务器，服务器按照客户机的要求返回结果。

1.1.3 结构化查询语言SQL

SQL语言是用于管理数据的一种数据库查询和程序设计语言。其主要用于存取、查询和更新数据，还能够管理关系数据库系统的数据库对象。最早由Boyce和Chambedin在1974年提出，称为SEQUEL语言。1976年，IBM公司的San Jose研究所在研制关系数据库管理系统System R时修改为SEQUEL2，即目前的SQL语言。

1、SQL语言特点

一体化 ：SQL集数据定义DDL、数据操纵DML和数据控制DCL于一体，可以完成数据库中的全部工作。

使用方式灵活 ：它具有两种使用方式，即可以直接以命令方式交互使用；也可以嵌入使用，嵌入到C、C++、Fortran、COBOL和Java等主语言中使用。

非过程化 ：只需要提供操作要求，不必描述操作步骤，也不需要导航。使用时只需要告诉计算机“做什么”，而不需要告诉它“怎么做”。

语言简洁，语法简单，好学好用 ：在ANSI标准中，只包含了94个英文单词，核心功能只用6个动词，语法接近英语口语。

2、SQL查询语言的组成

数据定义语言（Data Definition Language，DDL） ：其语句包括动词create、alter和drop。在数据库中创建、修改或删除数据库对象，如表、索引、视图、存储过程、触发器、事件等。

数据操作语言（Data Manipulation Language，DML） ：包括动词select、insert、update和delete。它们分别用于查询、插入、修改和删除表中的数据行等。select是用得最多的动词，其他DQL常用的保留字有where、order by、group by和having。

数据控制语言（DCL） ：包括grant语句和revoke等语句。通过grant语句获得权限许可，revoke可以撤销权限许可，确定单个用户和用户组对数据库对象的访问权限。

事务处理语言（TPL） ： TPL语句能确保被DML语句影响的表的所有行及时得以更新。TPL语句包括begin transaction、commit和rollback。

指针控制语言（CCL） ： CCL语句，像declare cursor，fetch into和update where current用于对一个或多个表单独行的操作。

1.1.4 常见的关系型数据库管理系统

1、Oracle

  • Oracle公司的产品，世界上最好的数据库系统
  • “关系-对象”型数据库
  • 支持70多种操作系统，配置、管理和维护复杂
  • 主要满足对银行、金融、保险等企业、事业开发大型数据库需求

2、SQL Server

  • Microsoft公司的产品，针对不同用户群体的多个版本
  • 要求在Windows操作系统平台上运行
  • 易用性好

3、MySQL

  • 瑞典MySQLAB公司开发，被SUN公司收购，后Oracle收购Sun，
  • 现在MySQL并入了Oracle旗下。
  • 体积小、速度快、成本低、开放源码
  • 广泛地应用在Internet上的中小型网站中

4、Access

  • 微软公司推出的基于Windows的桌面关系数据库管理系统 ，Microsoft Office的成员之一
  • 优点 ：存储方式单一 、面向对象 、界面友好、易操作 、集成环境、处理多种数据信息 、支持ODBC
  • 小型数据库，有局限性 ：数据库过大 、网站访问频繁 、记录数过多性能会急剧下降

1.2 数据模型

1.2.1 数据抽象的过程

美国国家标准化协会ANSI根据数据抽象的级别定义了4种模型，即概念模型、逻辑模型、外部模型、内部模型。

数据抽象的过程即是数据库设计的过程，具体的步骤如下。

第1步：根据用户需求，设计数据库的概念模型，这是一个“综合”的过程。

第2步：根据转换规则，把概念模型转换成数据库的逻辑模型，这是一个“转换”的过程。

第3步：根据用户的业务特点，设计不同的外部模型，给应用程序使用。也就是说，应用程序使用的是数据库外部模型中的各个视图。

第4步：数据库实现时，要根据逻辑模型设计其内部模型。

1、概念模型

概念模型在这4种模型中抽象级别最高。其特点如下。

（1）概念模型表达了数据库的整体逻辑结构，它是企业管理人员对整个企业组织的全面概述。

（2）概念模型是从用户需求的观点出发，对数据建模。

（3）概念模型独立于硬件和软件。

（4）概念模型是数据库设计人员与用户之间进行交流的工具。

现在采用的概念模型主要是实体-联系模型，即E-R模型。E-R模型主要用E-R图来表示。

实体是现实世界或客观世界中可以相互区别的对象，这种对象可以是具体的，也可以是抽象的。

联系是两个或多个实体间的关联。两个实体之间的联系可以分为三种：

（1）一对一联系（1：1）

（2）一对多联系（1：n）

（3）多对多联系（m：n）

2、逻辑模型

逻辑模型具有下列特点。

（1）逻辑模型表达了数据库的整体逻辑结构，但它是设计人员对整个企业组织数据库的全面概述。

（2）逻辑模型是从数据库实现的观点出发，对数据建模。

（3）逻辑模型硬件独立，但软件依赖。

（4）逻辑模型是数据库设计人员与应用程序员之间进行交流的工具。

逻辑模型有层次模型、网状模型和关系模型3种。现在使用的关系型数据库管理系统（RDBMS）均采用关系数据模型。

3、外部模型

外部模型具有如下特点。

（1）外部模型是逻辑模型的一个逻辑子集。

（2）硬件独立，软件依赖。

（3）外部模型反映了用户使用数据库的观点。

从整个系统考察，外部模型具有下列特点。

（1）简化了用户的观点。

（2）有助于数据库的安全性保护。

（3）外部模型是对概念模型的支持。

4、内部模型

内部模型又称为物理模型，是数据库最底层的抽象，它描述数据在磁盘上存储方式、存取设备和存取方法。内部模型是与硬件和软件紧密相连的。

可以不必考虑内部级的设计细节，由系统自动实现。

1.2.2 关系模型

1、数据模型的三要素

（1）数据结构

数据结构是所描述的对象类型的集合。现在常用的是关系数据模型。

数据结构是对系统静态特性的描述。

（2）数据操作

数据操作是指对数据库表中记录的值允许执行的操作集合，数据库对数据的操作主要有增、删、改、查询4种操作。

数据操作是对系统动态特性的描述。

（3）数据的完整性约束条件

数据的完整性约束条件是一组完整性规则。用以保证数据的正确、有效、相容。

2、关系数据模型的数据结构

（1）关系（Relation） 一个关系就是一张规范的二维表 。

（2）元组（Tuple） 表中的一行即为一个元组。

（3）属性（Attribute） 表中的一列即为一个属性，每个属性都有一个属性名。

（4）码或键（Key） 也称为关键码或关键字。表中的某个属性或者属性的组合，能唯一的确定一个元组。

（5）关系模式 对关系的描述，一般表示为：关系名（属性1，属性2，属性3，……，属性n）

3、关系数据模型的操作与完整性约束

关系的完整性约束条件包括三大类：

  • 实体完整性

  • 参照完整性

  • 用户定义的完整性

1.3 数据库体系结构

1.3.1 数据库系统三级结构

1、用户级数据库

用户级对应于外模式，是最接近用户的一级，是用户看到和使用的数据库，又称为用户视图。

2、概念级数据库

概念级数据库对应于概念模式，介于用户级和物理级之间，是数据库管理员看到和使用的数据库，又称DBA视图。

3、物理级数据库

物理级数据库对应于内模式，是数据库的底层表示，它描述数据的实际存储组织，是最接近于物理存储的级，又称内部视图。

1.3.2 数据库系统三级模式

1、概念模式

概念模式又称为模式或逻辑模式，是数据库中全体数据的逻辑结构和特征的描述，是所有用户的公共数据视图。一个数据库只能有一个概念模式。

2、外模式

外模式又称为子模式或用户模式，是数据库用户（包括程序员和最终用户）能够看到和使用的局部数据的逻辑结构和特征的描述，是数据库用户的数据视图，是与某一应用有关的数据的逻辑表示。一个数据库可以有多个外模式。

3、内模式

内模式又称为存储模式或物理模式，是数据物理结构和存储方式的描述，是数据在数据库内部的表示方式。一个数据库只能有一个内模式。

1.3.3 数据库系统的二级映射与数据独立性

1、数据库系统的二级映射

数据库系统的二级映射是：外模式/模式映射和模式/内模式映射。

2、数据独立性

（1）物理独立性

物理独立性是指用户的应用程序与存储在磁盘上的数据库中的数据是独立的。物理独立性是通过模式/内模式映射来实现的。

（2）逻辑独立性

逻辑独立性是指用户的应用程序与逻辑结构是相互独立的。逻辑独立性是通过外模式/模式映射来实现的。

1.3.4 数据库应用系统的开发架构**

1、C/S模式

客户/服务器（Client/Server，C/S）模式是一种流行的解决分布式问题的架构模式。C/S模式通过网络环境，将应用划分为前台和后台两个部分。

（1）两层C/S模式

（2）三层C/S模式

2、B/S模式（浏览器/服务器模式）

1.4 高级数据库系统**

分布式数据库系统

面向对象数据库系统

并行数据库系统

多媒体数据库系统

1.5 数据仓库技术与数据挖掘技术

1.5.1 数据仓库

数据仓库（Data Warehouse，DW）是一个面向主题的、集成的、稳定的、随时间不断变化的数据集合，它用于支持经营管理中的决策制定过程。

1.5.2 联机分析处理

OLAP可以对大量的多给数据进行动态合并和分析，是决策支持领域的一部分。

1.5.3 数据挖掘

数据挖掘（Date Mining）是从大量数据中提取隐含在其中的、人们事先不知道的但又可能有用的信息和知识的过程。

1.6 非关系型数据库NoSQL

1.6.1 NoSQL概述

NoSQL是非关系型数据存储的广义定义。它打破了长久以来关系型数据库与事务ACID理论大一统的局面。NoSQL数据存储不需要固定的表结构，通常也不存在连接操作。在大数据存取上具备关系型数据库无法比拟的性能优势。

1.6.2 NoSQL相关理论

BASE是Basically Available（基本可用）、Soft state（软状态）和Eventually consistent（最终一致性）三个短语的简写，BASE是对CAP中一致性和可用性权衡的结果，其核心思想是即使无法做到强一致性，但每个应用都可以根据自身的业务特点，采用适当的方式使系统达到最终一致性。

1.6.3 NoSQL数据库模型

  1. Key-Value存储模型

  2. 文档存储模型

  3. 图存储模型

  4. BigTable存储模型

1.7 SQL语言介绍

SQL语言采用统一的国际标准

  • 1986年美国国家标准化组织ANSI和国际标准化组织ISO发布了SQL标准：SQL86 。

  • 1989年，ANSI发布了一个增强完整性特征的SQL89标准。

  • 1992年发布了SQL2标准，实现了对远程数据库访问的支持 。

  • 1999年，ISO发布了SQL3标准，包括对象数据库、开放数据库互联等内容。

  • SQL2003标准，SQL Server2005和Oracle10g都支持此标准。

  • SQL2006主要讲述了SQL与XML间如何进行交互。

  • SQL2016主要的新特性包括行模式识别、支持JSON对象、多态表函数

1.7.1 SQL数据库的体系结构

SQL用户可以是应用程序，也可以是终端用户。SQL语言可以被嵌入在宿主语言的程序（如Python、C++、Java等）中使用，也可以作为独立的用户接口在DBMS环境下被用户直接使用。

SQL用户可以用SQL语言对基本表和视图进行查询。

一个视图是从若干基本表或其他视图上导出的表。数据库中只存放该视图的定义，而不存放该视图所对应的数据，这些数据仍然存放在导出该视图的基本表中。因此，可以说视图是一个虚表。

一个或一些基本表对应于一个数据文件。一个基本表也可以存放在若干数据文件中。一个数据文件对应于存储设备上的一个存储文件。

一个基本表可以带若干索引。索引也存放在数据文件中。

一个表空间可以由若干个数据文件组成。

一个数据库可以由多个存储文件组成。

1.7.2 SQL的特点

SQL集数据查询、数据操纵、数据定义 和数据控制功能于一体，主要特点包括：

1、综合统一

SQL集数据定义语言DDL、数据操纵语言DML、数据控制语言DCL的功能于一体，语言风格统一，可以独立完成数据库生命周期中的全部活动，包括：

定义关系模式，插入数据，建立数据库;

对数据库中的数据进行查询和更新;

数据库重构和维护;

数据库安全性、完整性控制。

2、高度非过程化

非关系数据模型的数据操纵语言是“面向过程”的，用“过程化”语言完成某项请求，必须指定存储路径。

SQL进行数据操作，只要提出“做什么”，而无须指明“怎么做”，因此无需了解存储路径。存储路径的选择以及SQL的操作过程由系统自动完成。这样可以减轻用户的负担，也提高了数据独立性。

3、面向集合的操作方式

非关系数据模型得采用提面向记录的操作方式，操作对象是一条记录。

SQL采用集合操作方式，不仅操作对象、查找结果可以是元组的集合，而且一次插入、删除、更新操作的对象也可以是元组的集合。

4、以同一种语法结构提供多种使用方式

SQL既是独立的语言，又是嵌入式语言。

作为独立的语言，它能够独立地用于联机交互的使用方式，用户可以在终端键盘上直接键入SQL命令对数据库进行操作;

作为嵌入式语言，SQL语句能够嵌入到高级语言（如Python、C++、Java）程序中，供程序员设计程序时使用。

而在两种不同的使用方式下，SQL的语法结构基本上是一致的。

5、语言简洁，易学易用

SQL功能极强，完成核心功能只用了9个动词，接近英语口语，所以容易学习，易于使用。

数据定义：CREATE、DROP、ALTER

数据操纵：SELECT、INSERT、UPDATE、DELETE

数据控制：GRANT、REVOKE

1.7.3 SQL语言的组成

1、数据定义语言（DDL）

DDL用来定义、修改、删除数据库中的各种对象。包括创建、修改、删除或者重命名模式对象（CREATE、ALTER、DROP、RENAME）的语句，以及删除表中所有行但不删除表（Truncate）的语句等。

2、数据操纵语言（DML）

DML的命令用来查询、插入、修改、删除数据库中数据。包含用于查询数据（Select）、添加新行数据（Insert）、修改现有行数据（Update）、删除现有行数据（Delete）的语句等。

3、数据控制语言（DCL）

用于事务控制、并发控制、完整性和安全性控制等。

1.8 关系模型基本概念

1.8.1 基本术语

关系： 是用于描述数据的一张二维表，组成表的行称为元组，组成表的列称为属性。

域（Domain）： 指列（或属性）的取值范围。

候选键（Candidate Key）： 也称为候选码。能唯一的标识关系中每一个元组的最小属性集。一个关系可能有多个候选键。

主键（Priamary Key，PK）： 也称为主码。一个唯一识别关系中元组的最小属性集合。可以从关系的候选键中，指定其中一个作为关系的主键。一个关系最多只能指定一个主键。要求作为主键的列不允许取NULL值。

主属性： 候选键中所有的属性均称为主属性。

非主属性： 不包含在任何候选键中的属性称为非主属性。

全码： 关系中所有属性的组合是该关系的一个候选码，则该候选码称为全码。

外键（Foreign Key，FK）： 关系R中的某个属性K是另一个关系S中的主键，则称该属性K是关系R的外键。通过外键可以建立两表间的联系。

1.8.2 关系的特性

  • 列是同质的，即每一列中的分量是同一类型的数据，来自同一个域。

  • 不同的列可出自同一个域，称其中的每一列为一个属性，不同的属性要给予不同的属性名。

  • 各列的顺序在理论上是无序的，即列的次序可以任意互换，但使用时按习惯考虑列的顺序。

  • 任意两个元组的侯选码不能相同。

  • 行的顺序无所谓，即行的次序可以任意交换。

  • 分量必须取原子值，即每一个分量都必须是不可分的数据项。

1.8.3 关系的数据完整性

实体完整性 ：实体完整性是指关系的主关键字不能取“空值”。在关系模式中，以主关键字作为唯一性标识，如果主关键字是多个属性的组合，那么所有主属性均不得取空值。

域完整性 ：确保属性中只允许一个有效数据。在物理数据库中，可以利用表中的数据类型和行可空性强制执行域完整性。

参照完整性 ：参照完整性是定义建立关系之间联系的主关键字与外部关键字引用的约束条件。关系数据库中通常包含多个存在相互联系的关系，关系与关系之间的联系是通过公共属性来实现的。

事务完整性 ：事务可以确保每个逻辑单元的工作作为单个事务执行。

用户定义完整性 ：用户定义完整性则是根据应用环境的要求和实际的需要，对某一具体应用所涉及的数据提出约束性条件。

1.9 使用实体-联系模型进行数据建模

实体-联系模型（又称为E-R模型）是一种高级数据模型，广泛用于对现实世界的数据抽象，以及数据库的概念模式设计。

数据模型是数据库设计的一个计划、蓝图。在数据建模过程中，改变数据仅需要重新绘图或修改文档，但当数据库创建好后，再改变数据则难的多，这时需要迁移数据、重写SQL语句、重写表单和报表等，所以，数据建模对数据库设计来说是十分必要的。

1.9.1 概念模型设计

将概念模型设计从设计过程中独立出来，可以带来以下好处：

（1）任务相对单一化，设计复杂程度大大降低，便于管理。

（2）概念模型不受具体DBMS的限制，也独立于存储安排和效率方面的考虑，因此更稳定。

（3）易于被业务用户所理解。

（4）能真实、充分地反映现实世界，包括事物和事物间的联系，能满足用户对数据的处理要求，是反映现实世界的一个真实模型。

（5）易于更改，当应用环境和应用要求改变时，容易对概念模型进行修改和扩充。

（6）易于向逻辑模型中的关系数据模型转换。

常用数据模型

数据模型的三要素

数据结构 ：数据结构用于描述数据库系统的静态特性。数据结构所研究是数据本身的类型、内容和性质，以及数据之间的关系。

数据操作 ：数据操作是对数据库中对象实例允许执行的操作集合，主要指检索和更新（插入、删除、修改）等操作

完整性约束条件 ：数据完整性约束是一组完整性规则的集合，它规定数据库状态及状态变化所应满足的条件，以保证数据的正确性、有效性和相容性。

常用数据模型

层次模型 ：层次数据库的数据结构类似一颗倒置的树，每个节点表示一个记录类型，记录之间的联系是一对多的联系，现实世界中很多事物是按层次组织起来的。

网状模型 ：网状数据库是用来处理以记录类型为结点的网状数据模型的数据库。网状模型采用网状结构表示实体及其之间的联系。

关系模型 ：关系数据库是目前流行的数据库。

面向对象模型（Object Oriented Model） ：面向对象模型采用面向对象的方法来设计数据库。面向对象的数据库存储对象是以对象为单位，每个对象包含对象的属性和方法，具有类和继承等特点。Computer Associates的Jasmine就是面向对象模型的数据库系统。

概念模型设计的方法

1、自顶向下

首先定义全局概念结构的框架，然后逐步细化。

2、自底向上

首先定义各局部应用的子概念结构，然后将它们集成起来，得到全局概念结构 。

3、逐步扩张

首先定义核心业务的概念结构，然后向外扩充，以滚雪球的方式逐步生成其他概念结构，直至全局概念结构 。

4、混合策略

将自顶向下和自底向上两种方法相结合，首先用自顶向下方法设计一个全局概念结构框架，划分成若干个局部概念结构，再采取自底向上的方法实现全局概念结构加以合并，最终实现全局概念结构。

1.9.2 实体-联系模型

E-R模型是一种语义模型，模型的语义方面主要体现在用模型图去表达数据的意义。

E-R模型在将现实世界的含义和相互关联映射到概念模式方面非常有用，因此，许多数据库设计工具都利用E-R模型的概念。

image

image

1、实体及实体集

实体（Entity） 概念：实体是现实世界或客观世界中可以相互区别的对象。

实体集（Entity Set） 概念：实体集是同类实体的集合。在不混淆的情况下，简称为实体。

2、属性

（1）属性（Atrribute）

属性概念：实体的某一特性称为属性。在一个实体中，能够唯一标识实体的属性或属性集称为实体的主键。

属性域是属性的可能取值范围，也称为属性的值域。例如，“性别”属性的域是（男，女，NULL）。

（2）属性的分类

按结构分类，属性有简单属性和复合属性；

按取值分类，属性有单值属性、多值属性和空值属性。

1）简单属性和复合属性

简单属性是不可再分的属性。

复合属性是可再分解为其他属性的属性。

2）单值属性和多值属性

单值属性指的是同一实体的属性只能取一个值。

多值属性指同一实体的某个属性可能取多值。在E-R图中，多值属性用双线椭圆表示。如：一个零件可能有多种销售价格（经销、代销、批发、零售）。

多值属性的变换通常有下列两种变换方法：

① 将原来的多值属性用几个新的单值属性来表示。

② 将原来的多值属性用一个新的实体表示。

弱实体：一个实体对于另一个实体（称为父/强实体）具有很强的依赖联系，称该实体为弱实体。

部分键：弱实体没有能唯一识别其实体的键，但可指定其中一个属性，与父实体的键结合，形成相应弱实体的的键。弱实体的这个属性，称为弱实体的部分键。

在E-R模型中，弱实体用双线矩形框表示，部分键加虚下划线。与弱实体关联的联系，用双线菱形框表示。强实体与弱实体的联系只能是1：1或1：n。

例如，在零件实体中，可以增加一个销售价格弱实体，该弱实体的主键是零件编号+销售性质，它与零件实体具有“存在”的联系。

3）空值属性

当实体在某个属性上没有值时应使用空（NULL）值。

比如某个员工在配偶值处填上空值，实际上至少有以下3种情况:

该员工尚未婚配，即配偶值无意义。
该员工已婚配，但配偶名尚不知。
该员工是否婚配，还不能得知。

1.9.3 联系

1、联系

概念：表示一个或多个实体间的关联关系。

联系的属性：联系也可以有描述属性，用于记录联系的信息而非实体的信息。

联系的主键：联系由所参与的实体的键共同唯一确定。

2、联系的设计

（1）二元联系

二元联系是指两个实体之间的联系，这种联系比较常见。

（2）一元联系

一元联系是指一个联系所关联的是同一个实体集中的两个实体。

（3）三元联系

三元联系是指三个实体间的联系，这种联系也比较常见。

3、实体之间的联系

一对一的联系(1∶1)。对于实体集A中的每一个实体，实体集B中至多有一个实体与之联系。

例：某学院有若干个系，每个系只有一个主任。则主任和系之间是一对一的关系。

主任和系的属性分别如下：
  主任——编号，姓名，年龄，学历;
  系——系编号，系名 
主任和系之间是一个管理关系

主任与系之间的一对一的联系
image

一对多联系(1∶M)。对于实体集A中的每1个实体，实体集B中有M个实体(M≥2)与之联系。

例： 在某仓库管理系统中，有两个实体集：仓库和商品。仓库用来存放商品，且规定一类商品只能存放在一个仓库中，一个仓库可以存放多件商品。

仓库和商品的属性分别如下：
 仓库——仓库号，地点，面积
 商品——商品号，商品名，价格      

在存放联系中要反映出存放商品的数量。

仓库和商品之间一对多的联系

image

多对多联系(M∶N)。对于实体集A中的每一个实体，实体集B中有N个实体(N≥0)与之联系

假设在某教务管理系统中，一个教师可以上多门课，一门课也可以由多个老师去上。

教师和课程可用以下属性来描述：
   教师——教师号，教师名，职称
   课程——课程号，课程名，班级
   在“讲授”联系中应能反映出教师的授课质量

教师和课程之间的多对多联系

image

1.9.4 利用E-R模型的数据库概念设计

采用E-R模型进行数据库的概念设计，可以分成3步进行：

1）首先设计局部E-R模型；

2）然后把各局部E-R模型综合成一个全局E-R模型；

3）最后对全局E-R模型进行优化，得到最终的E-R模型，即概念模型。

1、局部E-R模型设计

设计局部E-R模型，关键是确定：

1）一个概念是用实体还是属性表示？

2）一个概念是作实体的属性还是联系的属性？

（1）实体和属性的数据抽象

1）分类

定义某一类概念作为现实世界中一组对象的类型，将一组具有某些共同特性和行为的对象抽象为一个实体。

2）聚集

定义某个类型的组成成分。将对象的组成成分抽象为实体的属性。

（2）实体和属性的取舍

实体和属性需要根据实际情况进行必要的调整，在调整时要遵守两条原则：

1）属性不能再具有需要描述的性质，即属性必须是不可分的数据项，不能再由另一些属性组成。

2）属性不能与其它实体具有联系，联系只发生在实体之间。

（3）属性在实体与联系间的分配

一般把属性分配给那些使用频率最高的实体，或分配给实体值少的实体。

有些属性不宜归属于任一实体，只说明实体之间联系的特性。

（4）局部E-R模型设计过程

1）确定局部结构范围

设计各个局部E-R模型的第一步是确定局部结构的范围划分，划分的方式一般有两种：

2）一种是依据系统的当前用户进行自然划分。

1）另一种是按用户要求数据库提供的服务归纳成几类，使每一类应用访问的数据显著不同于其他类，然后为每类应用设计一个局部E-R模型。

局部结构范围的确定要考虑下述因素。

范围划分要自然，易于管理。

范围之间的界面要清晰，相互影响要小。

范围的大小要适度。太小了，会造成局部结构过多，设计过程繁杂，综合困难；太大了，则容易造成内部结构复杂，不便于分析。

2）实体定义

实体定义的任务就是从信息需求和局部范围定义出发，确定每一个实体的属性和键。

实体确定之后，它的属性也随之确定。对实体命名并确定其键也是很重要的工作。命名应反映实体的语义性质，见名知意，在一个局部结构中应是唯一的；键可以是单个属性，也可以是属性的组合。

3）联系定义

E-R模型的“联系”用于刻画实体之间的关联。

一种完整的方式是依据需求分析的结果，考察局部结构中任意两个实体之间是否存在联系。若有联系，进一步确定的是1：n、m：n还是1：1。

在确定联系时，应注意防止出现冗余的联系（即可从其它联系导出的联系），如果存在，要尽可能地识别并消除这些冗余联系，以免将这些问题遗留给综合全局的E-R模型阶段。

4）属性分配

实体与联系都确定下来后，局部结构中的其他语义信息大部分可用属性描述。这一步工作有两个：一是确定属性；二是把属性分配到有关实体和联系中去。

2、全局E-R模型设计

全局E-R模型的设计过程

（1）确定公共实体

为了给多个局部E-R模型的合并提供开始合并的基础，首先要确定各局部结构中的公共实体。

确定公共实体并非一目了然。特别是当系统较大时，可能有很多局部模式，这些局部E-R模型是由不同的设计人员确定的，因而对同一现实世界的对象可能给予不同的描述。有的作为实体，有的又作为联系或属性。

即使都表示成实体，实体名和键也可能不同，这种情况，一般把同名实体作为公共实体的一类候选；把具有相同键的实体作为公共实体的另一类候选。

（2）局部E-R模型的合并

合并可以有两种方式：多个局部E-R图一次合并。

逐步合并，用累加的方式一次合并两个局部E-R图。

（3）消除冲突

合并的顺序有时影响处理效率和结果。建议的合并原则是逐步合并：首先进行两两合并，先合并那些现实世界中有联系的局部结构；合并从公共实体开始，最后再加入独立的局部结构。

各局部E-R图之间的冲突主要有三类：属性冲突、命名冲突和结构冲突。

1）属性冲突

属性冲突又包括属性域冲突和属性取值单位冲突。

  • 属性域冲突。即属性值的类型、取值范围或取值集合不同。

  • 属性取值单位冲突。

属性冲突理论上好解决，通常采用讨论、协商等行政手段解决，但实际上需要各部门讨论协商，解决起来并非易事。

2）命名冲突

命名冲突包括同名异义和异名同义两种情况。

  • 同名异义。即不同意义的对象在不同的局部应用中具有相同的名字。

  • 异名同义。即同一意义的对象在不同的局部应用中具有不同的名字。

命名冲突包括属性名、实体名、联系名之间的冲突。其中属性的命名冲突更为常见。处理命名冲突通常也采用讨论、协商等行政手段解决。

3）结构冲突

  • 同一对象在不同应用中具有不同的抽象。

解决方法：通常是把属性变换为实体或实体变换为属性，使同一对象具有相同的抽象。

  • 同一实体在不同局部E-R图中所包含的属性个数和属性排列次序不完全相同。

解决方法：使该实体的属性取各局部E-R图中属性的并集，再适当调整属性的次序。

  • 实体间的联系在不同的局部E-R图中为不同类型。

解决方法：根据应用的语义对实体联系的类型进行综合或调整。

（4）全局E-R模型的优化

（1）实体的合并

这里的合并是指相关实体的合并。在信息检索时，涉及到多个实体的信息要通过连接操作获得。因而减少实体个数，可减少连接的开销，提高处理效率。

一般在权衡利弊后，可以把1：1联系的两个实体合并。

（2）冗余属性的消除

一个属性值可从其他属性的值导出来，所以应把冗余的属性从全局模型中去掉。

冗余属性消除与否，也取决于它对存储空间、访问效率和维护代价的影响。有时为了兼顾访问效率，有意保留冗余属性。这当然会造成存储空间的浪费和维护代价的提高。

（3）冗余联系的消除

在全局模型中可能存在有冗余的联系，通常利用规范化理论中函数依赖的概念消除冗余。

1.9.5 总结

本小节较详细地介绍了广泛作为概念数据库设计工具的E-R模型。E-R模型描述的元素有实体、实体型、属性、键（键和候选键）、联系、联系型。其中，实体主要是指单独存在的具体事物或抽象概念的个体，而实体型是指同一类型的实体集合。实体用属性来描述，实体型中的实体用相同的属性集合来描述。属性按结构分为简单属性、复合属性，按取值分为单值属性、多值属性和空属性。键用于唯一标识实体型中的实体，可能是一个属性，也可能是多个属性的集合，按其具有的属性个数，分为简单键和复合键。如果存在多个候选键，则应指定其中一个作为主键。联系是两个或多个实体间的关联，也可以有其描述属性。一般情况下，联系由所参与实体的键共同决定。

采用E-R模型进行数据库的概念设计，可以分成3步进行：首先设计局部E-R模型，然后把各局部E-R模型综合成一个全局E-R模型，最后对全局E-R模型进行优化，得到最终的E-R模型，即概念模型。在将局部E-R模型合成全局E-R模型时，需要消除冲突，如属性冲突、命名冲突、结构冲突。


1.10 关系模型规范化设计理论

在数据管理中，数据冗余一直是影响系统性能的大问题。数据冗余是指同一个数据在系统中多次重复出现。如果一个关系模式设计的不好，就会导致数据冗余、插入异常、删除异常和修改复杂等问题。规范化设计理论使用范式来定义关系模式所要符合的不同等级，将较低级别范式的关系模式，经模式分解转换为多个符合较高级别范式要求的关系模式，减少数据冗余和出现的各种异常情况。

1.10.1 关系模式中可能存在的异常

1、存在异常的关系模式示例

下面给出一个存在异常的关系模式及其语义：

Students（Sid，Sname，Dname，Ddirector，Cid，Cname，Cscore）

中文意思：

Students（学号，姓名，系名，系主任，课程号，课程名，成绩）

语义：

（1）一个系有多名学生，而一个学生只属于一个系，即系与学生之间是的1：n的联系。

（2）一个系只有一名系主任，一名系主任也只在一个系任职，即系与系主任之间是1：1的联系。

（3）一名学生可以选修多门课程，而每门课程有多名学生选修，即学生与课程之间是m：n的联系。

2、可能存在的异常

（1）数据冗余

冗余的表现是，某种信息在关系中存储多次。

（2）插入异常

插入异常的表现是，元组插入不进去。

（3）删除异常

删除异常的表现是，删除时，删掉了其他不应删除的信息。

（4）更新异常

更新异常的表现是，修改一个元组，却要求修改多个元组。

3、关系模式中存在异常的原因

开发现实系统时，在需求分析阶段，用户会给出数据间的语义限制 ，这就是数据语义。

数据语义在关系模式中的具体表现是，在关系模式中的属性间存在一定的依赖关系，即数据依赖。

异常现象产生的原因，就是由于关系模式中存在的这些复杂的数据依赖关系所导致的。

解决异常的方法是利用关系数据库规范化理论，对关系模式进行相应的分解，使得每一个关系模式表达的概念单一，属性间的数据依赖关系单纯化，从而消除这些异常。

1.10.2 函数依赖

1、函数依赖定义

函数依赖（FD）是数据库设计的核心部分。

什么是函数依赖？
例如：

在Students关系中，因为每个学号Sid的值都对应着唯一一个学生的名字Sname，我们可以将其形式化为：
      
      Sid → Sname

因此，可以说，名字Sname函数依赖于学生的学号Sid，学生的学号Sid决定了学生的名字Sname。

定义：

设R（U）是属性集U上的关系模式，X和Y是U的子集。若对于R（U）的任意一个可能的关系r，对于X的每一个具体值，Y都有唯一的具体的值与之对应，则称X函数决定Y，或Y函数依赖于X，记作X→Y。称X为决定因素，Y为依赖因素。

例如:

学号Sid和课号Cid可以一起决定某位同学某科的成绩Cscore，将其形式化为：
   (Sid，Cid) → Cscore

说明：

（1）函数依赖同其它数据依赖一样，是语义范畴概念。只能根据数据的语义来确定函数依赖。 

（2）函数依赖不是指关系模式R的某个或某些元组满足的约束条件，而是指R的所有元组均要满足的约束条件，不能部分满足。

（3）函数依赖关心的问题是一个或一组属性的值决定其它属性的值。

2、发现函数依赖

确定数据间的函数依赖关系，是数据库设计的前提。

函数依赖可以通过数据间的语义来确定，也可以通过分析完整的样本数据来确定。

（1）根据完整的样本数据发现函数依赖

这种方法是根据完整的样本数据和函数依赖的定义来实现的。

在没有样本数据或者只有部分样本数据时，则不能用此方法确定数据之间函数依赖的关系。

为了能够找到表上存在的函数依赖，我们必须确定，哪些列的取值决定了其它列的取值。

例如：

根据上表可以看出，订单编号与商品编号决定了数量、单价、总价，所以数量、单价、总价依赖于订单编号、商品数量。

而数量和单价又决定了总价，所以总价依赖于数量与单价。

存在的函数依赖：

（Order_ID，SKU）→（Quantity，Price，Total）

（Quantity，Price）→Total

（2）根据数据语义发现函数依赖

一般，对于关系模式R，U为其属性集合，X、Y为其属性子集，根据函数依赖的定义和实体间联系的类型，可以得出如下变换的方法：

如果X和Y之间是1：1的联系，则存在的函数X→Y和Y→X；

如果X和Y之间是1：n的联系，则存在的函数Y→X；

如果X和Y之间是m：n的联系，则X和Y之间不存在函数依赖关系。

例如，在Students关系模式中，系与系主任之间是1：1的联系，所以有Dname→Ddirector和Ddirector→Dname函数依赖；系与学生之间是1：n的联系，所以有函数依赖Sid→Dname；学生和课程之间是m：n的联系，所以Sid与Cid之间不存在函数依赖。

【示例-1】设有关系模式R（A，B，C），其关系r如下所示。

（1）试判断下列3个FD在关系r中是否成立？

      A→B      BC→A     B→A

（2）根据关系r，你能断定哪些FD在关系模式R上不成立？

解答：

（1）在关系r中，A→B成立，BC→A不成立，B→A不成立。

（2）在关系r中，不成立的FD有：
      
      B→A，C→A，C→B，C→AB，BC→A。

【示例-2】有一个包括学生选课、教师任课数据的关系模式：

R（S#，SNAME，AGE，SEX，C#，CNAME，SCORE，T#，TNAME，TITLE）

属性分别表示学生学号、姓名、年龄、性别、选修课程的课程号、课程名、成绩、任课教师工号、教师姓名和职称。

规定：

每个学号只能有一个学生姓名，每个课程号只能决定一门课程；

每个学生每学一门课，只能有一个成绩；

每门课程只由一位教师任课。

根据上面的规定和实际意义，写出该关系模式所有的FD。

解答：

R关系模式包括的FD有：

S#→SNAME
C#→CNAME    
(S#，C#)→GRADE
C#→T#        
S#→(AGE，SEX)
T#→(TNAME，TITLE)

3、最小函数依赖集

函数依赖的定义使我们能由已知的函数依赖推导出新的函数依赖。例如，若X→Y，Y→Z，则有X→Z。 既然有的函数依赖能由其他函数依赖推出，那么对于一个函数依赖集，其中有的函数依赖可能是不必要的、冗余的。如果一个函数依赖可以由该集中其它函数依赖推导出来，则称该函数依赖在其函数依赖集中是冗余的。数据库设计的实现，是基于无冗余的函数依赖集的，即最小函数依赖集。

（1）函数依赖的推理规则

设U是关系模式R的属性集，F是R上成立的只涉及U中属性的函数依赖集。函数依赖的推理规则如下：

1）A1（自反性）：如果Y⊆X⊆U，则X→Y。
2）A2（增广性）：如果X→Y且Z⊆U，则XZ→YZ。
3）A3（传递性）：如果X→Y且Y→Z，则X→Z。
4）B1（合并性）：如果X→Y且X→Z，则X→YZ。
5）B2（分解性）：如果X→YZ，则X→Y、X→Z。
6）B3（结合性）：如果X→Y且W→Z，则XW→YZ。
7）B4（伪传递性）：如果X→Y且WY→Z，则XW→Z。

A1~A3就是有名的Armstrong公理，B1~B4是Armstrong公理的推论。

【示例-3】设有关系模式R，属性集U=｛A，B，X，Y，Z｝，函数依赖集F=｛Z→A，B→X，AX→Y，ZB→Y｝，试给出ZB→Y是冗余的函数依赖的过程。

解答：

1）因为Z→A，B→X，由B3可知，ZB→AX；
2）因为ZB→AX ，AX→Y ，由A3可知，ZB→Y。

即ZB→Y可以由F中其它函数依赖导出，所以ZB→Y是冗余的函数依赖。

（2）求最小函数依赖集

如果函数依赖集F满足下列条件，则称F为一个最小函数依赖集。

1）每个函数依赖的右边都是单属性（可以通过B2分解性实现）；

2）函数依赖集F中没有冗余的函数依赖（即F中不存在这样的函数依赖X→Y，使得F与F-{X→Y}等价）；

3）F中每个函数依赖的左边没有多余的属性（即F中不存在这样的函数依赖X→Y，X有真子集W使得F-{X→Y}∪{ W→Y}与F等价）。

注意：最小依赖集不一唯一。

【示例-4】设F是关系模式R（A，B，C）的FD集，F=｛A→BC，B→C，A→B，AB→C｝，试求最小函数依赖集。

解答：

1）先把F中的函数依赖写成右边是单属性形式：
      F={A→B，A→C，B→C，A→B，AB→C｝
   删去一个A→B，得：
      F={A→B，A→C，B→C，AB→C｝

2）删去冗余的函数依赖。F中A→C可从A→B和B→C推出，因此A→C是冗余的，删去，得：
      F={A→B，B→C，AB→C｝

3）消除函数依赖左边冗余的属性。F中的AB→C，因为有B→C，所以A多余，删去，
   得到最小函数依赖集为：
      F={A→B，B→C｝

【示例-5】设关系模式R（A，B，C，D，E，G，H）上的函数依赖集F=｛AC→BEGH，A→B，C→DEH，E→H｝，求F的最小函数依赖集。

解答：

1）把每个FD的右边拆成单属性，得到9个FD，得：
      F={AC→B，AC→E，AC→G，AC→H，A→B，C→D，C→E，C→H，E→H}

2）消除冗余的FD，得：
      F={ AC→B，AC→E，AC→G，AC→H，A→B，C→D，C→E，E→H }

3）消除FD中左边冗余的属性。因为A→B，所以消去AC→B中的C；因为C→E，所以消去AC→E的A；因为由C→E、E→H，可推出C→H，所以消去AC→H中的A，得C→H，因为可由C→E、E→H推出，所以将AC→H删去，得到的F为：   
      F={ A→B，C→E，AC→G，A→B，C→D，C→E，E→H}
   精简后，得
      F={ A→B，C→E，AC→G，C→D，E→H}

4）再把左边相同的FD合并起来，得到最小的函数依赖集为：
      F={ A→B，C→DE，AC→G，E→H}

1.10.3 候选键

只有在确定了一个关系模式的候选键后，才能用关系规范化理论对出现异常现象的关系模式进行分解。

1、候选键定义

定义：
   设F是属性集U上的函数依赖集，X是U的子集，那么属性集X的闭包用X+表示，它是一个从F集使用函数依赖推理规则推出的所有满足X→A的属性A的集合：
            X+=｛属性A｜X→A能由F推导出来｝
 从属性集闭包的定义，容易得出下面的定理。

定理:
   X→Y能由F根据函数依赖推理规则推出的充分必要条件是Y⊆X+。

于是，判定X→Y是否能由F根据函数依赖推理规则推出的问题，就转化为求出X+的子集问题。

算法：求属性集X（X⊆U）关于U上的函数依赖集F的闭包X+。

输入：函数依赖集F；属性集U

输出：X+

步骤：

1）令X(0)=X，i=0；

2）求b，这里 b=｛A｜（彐V）（彐W）（V→W∈F∧V⊆X(i) ∧A∈W）｝；

3）X(i+1) =b∪X(i) ；

4）判断X(i+1) =X(i)是否成立；

5）如果等式成立或X(i+1) =U，则X(i+1) 就是X+，算法终止；

6）如果等式不成立，则i=i+1，返回步骤（2）继续。

*彐数学符号代表存在量词。彐数学符号的意思是一种存在量词，存在量词表示至少存在一个，是在大学的数学分析中出现的。

【示例-6】已知关系模式R（U，F），其中U=｛A，B，C，D，E｝；F={AB→C，B→D，C→E，EC→B，AC→B}。求(AB) +。

解答：

1）X(0)=AB。

2）求b。逐一扫描F集中各个函数依赖，找左部为A、B或AB的函数依赖，得到AB→C，B→D，则B=CD。

3）X(1)= b∪X(0) =CD∪AB=ABCD。

4）因为X(1) ≠ X(0)，所以再找左部为ABCD子集的函数依赖，得到C→E，AC→B，
     于是X(2)= B∪X(1) =BE∪ABCD=ABCDE。

5）因为X(2)=U，所以(AB) +=ABCDE。

【示例-7】设关系模式R（A，B，C，D，E，G）上函数依赖集为F，F=｛D→G，C→A，CD→E，A→B｝。求D+，CD+，AD+，AC+，ACD+。

解答：

D+=DG
CD+=ABCDEG
AD+=ABDG
AC+=ABC
ACD+=ABCDEG

3、求候选键

（1）查看函数依赖集F中的每个形如Xi→Yi（i=1，…，n）的函数依赖关系。看哪些属性在所有Yi（i=1，…，n）中一次也没有出现过，设没有出现过的属性集为P（P=U-Y1-Y2-…Yn）。则当P=∅时，转步骤（4）；P≠∅时，转步骤（2）。

（2）根据候选键的定义，候选键中应必包含P（因为没有其它属性能决定P，但自己能决定自己）。考察P，如果P满足候选键定义，则P为候选键，并且候选键只有P一个，然后转步骤（5）结束；如果P不满足候选键定义，则转步骤（3）继续。

（3）P可以分别与｛U-P｝中的每一个属性合并，开成P1、P2、…、Pm。再分别判断Pj（j=1，…，m）是否满足候选键定义，能成立则找到了一个候选键，没有则放弃。合并一个属性如果不能找到或不能找全候选键，可进一步考虑P与｛U-P｝中的2个（或3个，4个，…）属性的所有组合分别进行合并，继续判断分别合并后的各属性组是否满足候选键的定义，如此下去，直到找出R的所有候选键为止。转步骤（5）结束。

注意：如果属性组K已有K→U，则不需要再去考察含K的其它属性组合，显然它们都不可能再是候选键了（根据候选键定义的第②项）。

（4）如果P=∅，则可以先考察Xi→Yi（i=1，…，n）中的单个Xi，判断Xi是否满足候选键定义。如果成立则Xi为候选键。剩下不是候选键的，可以考察它们两个或多个的组合，查看这些组合是否满足候选键定义，从而找出其它可能还有的候选键。转步骤（5）结束。

（5）本方法结束。

【示例-8】设有关系模式R（A，B，C，D，E，G），函数依赖集F=｛AB→E，AC→G，AD→B，B→C，C→D｝，求出R的所有候选键。

解答：

1）P=｛A｝。因为P≠，转步骤（2）。

2）求P对应属性的闭包，即(A)+。
   (A)+=A，P对应的属性不能决定U，所以P不满足候选键定义，转步骤（3）。

3）P中A分别与｛U-P｝中的（B，C，D，E，G）合并，形成AB、AC、AD、AE、AG。下面分别求(AB) +、(AC) +、(AD) +、(AE) +、(AG) +。
    (AB)+=ABCDEG，(AC)+=ABCDEG，(AD)+ =ABCDEG，(AE)+=AE，(AG)+=AG。

所以R的候选键是AB、AC、AD。

【示例-9】设有关系模式R（A，B，C，D，E）上的函数依赖集为F，并且F=｛A→BC，CD→E，B→D，E→A｝，求出R的所有候选键。

解答：

R的候选键有4个：A、E、CD和BC。

1.10.4 关系模型的规范化

存在异常的关系模式示例

Sid Sname Dname Ddirector Cid Cname Cscore
1001 李红 计算机 罗刚 1 数据库原理 86
1001 李红 计算机 罗刚 3 数据结构 90
2001 张小伟 信息管理 李少强 1 数据库原理 92
2001 张小伟 信息管理 李少强 2 电子商务 75
2001 张小伟 信息管理 李少强 3 数据结构 86
1002 钱海斌 计算机 罗刚 1 数据库原理 90
1002 钱海斌 计算机 罗刚 3 数据结构 60

该关系模式的主键为（Sid，Cid）。

关系模式的好与坏，用什么标准来衡量呢？

这个标准就是关系模式的范式。将坏的关系模式转换成好的关系模式，则需要对范式进行规范化。

1、范式及规范化

（1）范式

范式（Normal Form，NF）是指关系模式的规范形式。

各范式间的联系为：

$$5NF ⊂ 4NF ⊂ BCNF ⊂ 3NF ⊂ 2NF ⊂ 1NF$$

范式级别与异常问题的关系是：级别越低，出现异常的现象越高。

规范化

将一个给定的关系模式转化为某种范式的过程，称为关系模式的规范化过程，简称为规范化。

规范化一般采用分解的办法，将低级别范式向高级别范式转化，使关系的语义单纯化。

规范化程度，不一定越高越好，在关系模式设计时，一般要求关系模式达到3NF或BCNF即可。

存在异常的关系模式示例

Students（Sid，Sname，Dname，Ddirector，Cid，Cname，Cscore）

语义：

1）一个系有多名学生，而一个学生只属于一个系，即系与学生之间是的1：n的联系。

2）一个系只有一名系主任，一名系主任也只在一个系任职，即系与系主任之间是1：1的联系。

3）一名学生可以选修多门课程，而每门课程有多名学生选修，即学生与课程之间是m：n的联系。

Students上的函数依赖有：

｛ Sid → Sname，
Sid → Dname，
Sid → Ddirector ，
Cid → Cname， 
Dname → Ddirector，
Ddirector → Dname，
(Sid，Cid) → Cscore，
(Sid，Cid) → Sname，   
(Sid，Cid) → Dname，
(Sid，Cid) → Ddirector，
(Sid，Cid) → Cname｝。

2、完全函数依赖、部分函数依赖和传递函数依赖

（1）完全函数依赖和部分函数依赖

定义： 设R是一个具有属性集合U的关系模式，X和Y是U的子集。如果X→Y，并且对于X的任何一个真子集Z，Z→Y都不成立，则称Y完全函数依赖于X，记作

$$X \xrightarrow{f} Y$$

如果X→Y，并且对于X的任何一个真子集Z，Z→Y都成立，则称Y部分函数依赖于X，记作

$$X \xrightarrow{p} Y$$

【示例-10】对于关系模式Students（Sid，Sname，Dname，Ddirector，Cid，Cname，Cscore），判断下面所给的两个函数依赖是完全函数依赖还是部分函数依赖，为什么？

①（Sid，Cid）→Cscore
②（Sid，Cid）→Dname

解答：

①是完全函数依赖。因为Cscore的值必须由Sid和Cid一起来决定。
②是部分函数依赖。因为Dname的值只由Sid决定，与Cid的值无关。

（2）传递函数依赖

定义：设R是一个具有属性集合U的关系模式，X、Y、Z是U的子集，且X、Y、Z是不同的属性集。如果X→Y，Y→X不成立，Y→Z，则称Z传递函数依赖于X，记作

$$X \xrightarrow{t} Y$$

说明：

（1）如果X→Y，且Y→X，则称X与Y等价，记作X↔Y。
（2）如果定义中Y→X成立，则X与Y等价，这时称Z对X直接函数依赖，而不是传递函数。

【例9-11】对于关系模式Students（Sid，Sname，Dname，Ddirector，Cid，Cname，Cscore）

① 存在Sid→Dname，但Dname→Sid不成立，而Dname→Ddirector，则有Sid→Ddirector。

② 在学生不存在重名的情况下，Sid→Sname，Sname→Sid，即Sid↔Sname，而Sname→Dname，这时Dname对Sid是直接函数依赖，而不是传递函数依赖。

1.10.5 以函数依赖为基础的范式

1．第一范式（1NF）
定义9.6 设R是一个关系模式。如果R中每个属性的值域，都是不可分的原子值，则称R是第一范式，记作1NF。
1NF是关系模式具备的最起码的条件。

【例9-12】以关系模式Students（Sid，Sname，Dname，Ddirector，Cid，Cname，Cscore）为例，分析1NF出现的异常情况。

Sid Sname Dname Ddirector Cid Cname Cscore
1001 李红 计算机 罗刚 1 数据库原理 86
1001 李红 计算机 罗刚 3 数据结构 90
2001 张小伟 信息管理 李少强 1 数据库原理 92
2001 张小伟 信息管理 李少强 2 电子商务 75

该关系模式存在：数据冗余、插入异常、删除异常、更新异常。

2、第二范式（2NF）

主属性——候选键中所有的属性均称为主属性；

非主属性——不包含在任何候选键中的属性。

定义：如果关系模式R是1NF，而且R中所有非主属性都完全函数依赖于任意一个候选键，则称R是第二范式，记作2NF。

2NF的实质是不存在非主属性“部分函数依赖”于候选键的情况。

非2NF关系或1NF关系向2NF的转换原则：

设关系模式R属性集合为U，主键是W，R上还存在函数依赖X→Z，且X是W的子集，Z是非主属性，那么W→Z就是一个部分函数依赖。此时应把R分解成两个关系模式：

   R1（XZ），主键是X；

   R2（Y），其中Y=U-Z，主键仍是W，外键是X。

如果R1和R2还不是2NF，则重复上述过程，一直到每个关系模式都是2NF为止。

Students上的函数依赖有：

{Sid→Sname，
Sid→Dname，
Sid→Ddirector，
Cid→Cname，
Dname→Ddirector，
Ddirector→Dname，
（Sid，Cid）→Cscore，
（Sid，Cid）→Sname，  
（Sid，Cid）→Dname，
（Sid，Cid）→Ddirector，
（Sid，Cid）→Cname｝。

【例9-13】根据例9-12函数依赖关系，将满足1NF的关系模式Students（Sid，Sname，Dname，Ddirector，Cid，Cname，Cscore）分解成2NF。

解答：

可将其分解为3个2NF关系模式，每个关系模式及函数依赖分别如下：

（1）Students（Sid，Sname，Dname，Ddirector）
      
      ｛Sid→Sname，Sid→Dname，Dname→Ddirector，Ddirector→Dname，Sid→Ddirector｝

（2）Score（Sid，Cid，Cscore）
      ｛（Sid，Cid）→Cscore｝

（3）Course（Cid，Cname）
      ｛Cid→Cname｝

分解后第一个2NF关系模式为例：
   
   Students（Sid，Sname，Dname，Ddirector）

该关系模式的主键为Sid，其中的函数依赖关系有：

   ｛Sid→Sname，Sid→Dname，Dname→Ddirector，Ddirector→Dname，Sid→Ddirector｝

该关系模式存在：数据冗余、插入异常、删除异常、更新异常。

3、第三范式（3NF）

定义：如果关系模式R是2NF，而且R中所有非主属性对任何候选键都不存在传递函数依赖，则称R是第三范式，记作3NF。

3NF是从1NF消除非主属性对候选键的部分函数依赖，和从2NF消除传递函数依赖而得到的关系模式。

2NF关系向3NF转换的原则

设关系模式R属性集合为U，主键是W，R上还存在函数依赖X→Z，并且Z是非主属性，Z不包含于X，X不是候选键，这样W→Z就是一个传递依赖。此时应把R分解成两个关系模式：
           R1（XZ），主键是X；
           R2（Y），其中Y=U-Z，主键仍是W，外键是X。

如果R1和R2还不是3NF，则重复上述过程，一直到每个关系模式都是3NF为止。

2NF关系模式：

Students（Sid，Sname，Dname，Ddirector）

该关系模式的主键为Sid，其中的函数依赖关系有：

｛Sid→Sname，Sid→Dname，Dname→Ddirector，Ddirector→Dname，Sid→Ddirector｝

【示例-14】根据例9-13分解出的第一个2NF，将关系模式Students（Sid，Sname，Dname，Ddirector）分解成3NF，其函数依赖集是｛Sid→Sname，Sid→Dname，Dname→Ddirector，Ddirector→Dname，Sid→Ddirector｝。

解答：

（1）Students（Sid，Sname，Dname）
    ｛Sid→Sname，Sid→Dname｝

（2）Depts（Dname，Ddirector）
    ｛Dname→Ddirector，Ddirector→Dname｝

【例9-15】3NF异常情况。现有关系 STC（Sid，Cid，Grade，Tname）假定该关系模式包括以下数据语义。
（1）课程与教师之间是1：n的联系，即一门课程可由多名教师讲授，而一名教师只讲授一门课程。

（2）学生与课程之间是m：n的联系，即一名学生可选修多门课程，而每门课程有多名学生选修。

函数依赖集：

{(Sid，Cid)→Grade，(Sid，Tname)→Grade，Tname→Cid }

候选键：

（Sid，Cid）和（Sid，Tname）

该关系模式是3NF。存在的异常：

（1）插入异常。
（2）删除异常。
（3）数据冗余。
（4）更新异常。

4、Boycc-Codd范式（BCNF）

定义：如果关系模式R是1NF，且对于R中每个函数依赖X→Y，X必为候选键，则称R是BCNF范式。

由BCNF的定义可以知，每个BCNF范式应具有以下3个性质：

（1）所有非主属性都完全函数依赖于每个候选键；
（2）所有主属性都完全函数依赖于每个不包含它的候选键；
（3）没有任何属性完全函数依赖于非键的任何一组属性。

3NF关系向BCNF转换的原则是消除主属性对候选键的部分和传递函数依赖，将3NF关系分解成多个BCNF关系模式。

【例9-16】将例9-15的3NF分解成BCNF.

STC（Sid，Cid，Grade，Tname） ,

函数依赖关系如下：

{(Sid，Cid)→Grade，(Sid，Tname)→Grade，Tname→Cid }

解答：

通过消除主属性Cid部分函数依赖于候选键（Sid，Tname），将其分解为如下两个BCNF关系模式：

（1）SG（Sid，Cid，Grade）
       ｛（Sid，Cid）→Grade｝
（2）TC（Tname，Cid）
       ｛Tname→Cid｝

【示例-17】综合练习。

设有关系模式R（运动员编号，比赛项目，成绩，比赛类别，比赛主管），用于存储运动员比赛成绩及比赛类别、主管等信息。

语义规定：每个运动员每参加一个比赛项目，只有一个成绩；每个比赛项目只属于一个比赛类别；每个比赛类别只有一个比赛主管。

试回答下列问题：

（1）根据上述规定，写出模式R的基本函数依赖集和候选键。

（2）说明R不是2NF的理由，并把R分解成2NF模式集。

（3）进而分解成3NF模式集。

解答：

（1）基本的函数依赖集有3个：
    ｛（运动员编号，比赛项目）→成绩，比赛项目→比赛类别，比赛类别→比赛主管｝
     R候选键为（运动员编号，比赛项目）
（2）R中有两个这样的函数依赖：
    （运动员编号，比赛项目）→（比赛类别，比赛主管）
    （比赛项目）→（比赛类别，比赛主管）
       可见前一个函数依赖是部分依赖，所以R不是2NF模式。
R应分解成   R1（比赛项目，比赛类别，比赛主管）
                     R2（运动员编号，比赛项目，成绩）
这里，R1和R2都是2NF模式。
（3）R2已是3NF模式。
     在R1中，存在两个函数依赖：
        比赛项目→比赛类别
        比赛类别→比赛主管
因此，“比赛项目→比赛主管”是一个传递依赖，R1不是3NF模式。
        R1应分解成   R11（比赛项目，比赛类别）
                               R12（比赛类别，比赛主管）
这样，｛R11，R12，R2｝是一个3NF模式集。

1.10.6 关系的分解

分解是否会带来新的问题？

分解能否“复原”，即将分解的关系再连接起来是否能得到原来的关系？

分解后各关系函数依赖集的并运算结果是否与原关系的函数依赖等价？

1、无损连接分解

如果关系模式R上的任一关系r都是它在各分解模式上投影的自然连接，则该分解就是无损连接分解，也称无损分解。否则就是有损连接分解，或称有损分解。

【例9-18】设有关系模式R（ABC）

（1）设R上的一个关系r及对r分解得到的两个关系r1、r2分别如下，判断此分解是否为无损连接分解。

解答：为“无损分解”。

（2）设R上的一个关系r及对r分解得到的两个关系r1、r2分别如下，判断此分解是否为无损连接分解。

解答：

r1和r2自然连接后得到的结果为：

为“有损分解”。

如果一个关系被分解成两个关系，可以通过下面所给的定理判断该分解是否为无损分解。

定理：设p=(R1，R2)是关系模式R的一个分解，F为R的函数依赖集。当且仅当R1∩R2→R1-R2或R1∩R2→R2-R1属于F+时，p是R的一个无损连接分解。

【示例-19】（1）设有关系模式R（ABC），函数依赖集F=｛A→B，C→B｝，分解成p={AB，BC}，判断该分解是否是无损的。

解答：该分解是有损的。

（2）设有关系模式R（XYZ），函数依赖集F=｛X→Y，X→Z，YZ→X｝，分解成p={XY，XZ}，判断该分解是否是无损的。

解答：该分解是无损的。

2、无损连接分解的测试

算法：无损分解的测试方法。

输入：关系模式R=(A1，A2，……，An)，F是R上成立的函数依赖集，
                 p=｛R1，R2，……，Rk｝是R的一个分解。

输出：确定p是否为R的无损分解。

步骤：

（1）构造一张k行n列的表格，每列对应一个属性Aj（1≤j≤n），每行对应一个模式Ri（1≤i≤k）。如果Aj在Ri中，那么表格的第i行第j列处填上符号aj，否则填上bij（aj，bij仅是一种符号，无专门含义）。

（2）把表格看成模式R的一个关系，反复检查F中每个函数依赖在表格中是否成立，若不成立，则修改表格中的值。修改方法如下：
      
  对于F中的一个函数依赖X→Y，在表格中寻找对应于X中属性的所有列上符号ai或bij全相同的那些行，按下列情况处理：
      
  ① 如果表格中有两行（或多行）这样的行，则让这些行中对应于Y中属性的所有列的符号相同：如果符号中有一个aj，那么其它全都改成aj；如果没有aj，那么用其中一个bij替换其它值（尽量把下标i，j改成较小的数）。
      
  ② 如果没有找到两个这样的行，则不用修改。
   对F集中所有函数依赖重复执行步骤2，直到表格不能修改为止。

（3）若修改的最后一张表格中有一行是全a，即a1，a2，……，an，那么称p相对于F是无损分解，否则称有损分解。

【例9-20】设有关系模式R，其函数依赖F和R的一个分解p如下：
R=（ABCDE）
F=｛A→C，B→C，C→D，DE→C，CE→A｝
p=｛R1（AD），R2（AB），R3（BE），
R4（CDE），R5（AE）｝
判断p相对于F是否为无损分解？
解答：

（1）构建表格

A B C D E
R1（AD） a1 b12 b13 a4 b15
R2（AB） a1 a2 b23 b24 b25
R3（BE） b31 a2 b33 b34 a5
R4（CDE） b41 b42 a3 a4 a5
R5（AE） a1 b52 b53 b54 a5

（2）取A→C，A列中值相同的是第2、3、6行，全为a1，对应于C的列中无任何一个ai；选取b13，改b23和b53均为b13，得新的表格如下。

A B C D E
R1（AD） a1 b12 b13 a4 b15
R2（AB） a1 a2 b13 b24 b25
R3（BE） b31 a2 b33 b34 a5
R4（CDE） b41 b42 a3 a4 a5
R5（AE） a1 b52 b13 b54 a5

（3）再取B→C，B列中值相同的是第3、4行，全为a2，对应于C列中无任何一个ai；选取b13，改b33为b13，得新的表格如下。

A B C D E
R1（AD） a1 b12 b13 a4 b15
R2（AB） a1 a2 b13 b24 b25
R3（BE） b31 a2 b13 b34 a5
R4（CDE） b41 b42 a3 a4 a5
R5（AE） a1 b52 b13 b54 a5

（4）再取C→D，C列中值相同的是第2、3、4、6行，全为b13，对应于D列中有一个a4，将b24、b34、b54都改为a4，得新的表格如下。

A B C D E
R1（AD） a1 b12 b13 a4 b15
R2（AB） a1 a2 b13 a4 b25
R3（BE） b31 a2 b13 a4 a5
R4（CDE） b41 b42 a3 a4 a5
R5（AE） a1 b52 b13 a4 a5

（5）再取DE→C，DE列值相同的是第4、5、6行，对应于C列中有一个a3，将b13都改为a3，得新的表格如下。

A B C D E
R1（AD） a1 b12 b13 a4 b15
R2（AB） a1 a2 b13 a4 b25
R3（BE） b31 a2 a3 a4 a5
R4（CDE） b41 b42 a3 a4 a5
R5（AE） a1 b52 a3 a4 a5

（6）再取CE→A，CE列值相同的是第4、5、6行，对应于A列有一个a1，所以将A列的b31和b41都改为a1，得新的表格如下。

A B C D E
R1（AD） a1 b12 b13 a4 b15
R2（AB） a1 a2 b13 a4 b25
R3（BE） a1 a2 a3 a4 a5
R4（CDE） a1 b42 a3 a4 a5
R5（AE） a1 b52 a3 a4 a5

最终得到的表格如下。

A B C D E
R1（AD） a1 b12 a3 a4 b15
R2（AB） a1 a2 a3 a4 b25
R3（BE） a1 a2 a3 a4 a5
R4（CDE） a1 b42 a3 a4 a5
R5（AE） a1 b52 a3 a4 a5

（7）此时第4行全是a，所以相对于F，R分解成p是无损分解。

【例9-21】设关系模式R（ABCD），R分解成p=｛AB，BC，CD｝。

如果R上成立的函数依赖集F1=｛B→A，C→D｝，那么p相对于F1是否为无损分解？

如果R上成立的函数依赖集F2=｛A→B，C→D｝呢？

解答：

相对于F1，R分解成p是无损分解。
相对于F2，R分解成p是有损分解。

3、保持函数依赖分解

分解是否会带来新的问题？

分解能否“复原”，即将分解的关系再连接起来是否能得到原来的关系？

分解后各关系函数依赖集的并运算结果是否与原关系的函数依赖等价？

怎样保持函数依赖分解呢？

直观的讲，就是当一个关系模式被分解成多个模式时，其函数依赖集也被相应地分成各自的函数依赖集的集合，若该FD集的集合与原FD集等价，则该分解是依赖保持的。

定义：设有关系模式R（U，F），Z⊆U，则Z所涉及的F中所有函数依赖为F在Z上的投影，记为∏Z（F），有 ∏Z（F）=｛X→Y｜（X→Y）∈F+且X⊆Z、Y⊆Z｝为函数依赖集F在Z上的投影。

注：F+包含F集中的函数依赖关系和通过FD集推导出来的函数依赖关系。

定义：设R（U，F）的一个分解p=｛R1，R2，……，Rk｝，如果F等价于∏R1（F）∪∏R2（F）∪……∪∏Rk（F），则称分解p具有函数依赖保持性。

【示例-22】设有R=（XYZ），其中函数依赖集F=｛X→Y，Y→Z｝，分解p=（R1，R2），R1=（XY），R2=（XZ）。判断p是否保持函数依赖。

解答：

R1上函数依赖是F1=｛X→Y｝，

R2上函数依赖是F2=｛X→Z｝。但从这两个函数依赖推导不出在R上成立的函数依赖Y→Z，因此分解p把Y→Z丢失了，即p不保持函数依赖。

【示例-23】设关系模式R（ABC），p=｛AB，AC｝是R的一个分解。试分析分别在F1=｛A→B｝，F2=｛A→C，B→C｝，F3=｛B→A｝，F4=｛C→B，B→A｝情况下，p是否具有无损分解和保持FD的分解特性。

解答：

（1）相对于F1=｛A→B｝，分解p是无损分解且保持FD集的分解。
（2）相对于F2=｛A→C，B→C｝，分解p是无损分解，但不保持FD集。因为B→C丢失了。
（3）相对于F3=｛B→A｝，分解p是有损分解但保持FD集的分解。
（4）相对于F4=｛C→B，B→A｝，分解p是有损分解且不保持FD集的分解，因为丢失了C→B。

1.10.7 多值依赖与4NF

前面介绍的规范化都是建立在函数依赖的基础上，函数依赖表示的是关系模式中属性间的一对一或一对多的联系，但它并不能表示属性间多对多的关系，因而某些关系模式虽然已经规范到BCNF，但仍然会存在一些异常，下面主要讨论属性间多对多的联系，即多值依赖问题，以及在多值依赖范畴内定义的4NF。

1、多值依赖

设有关系模式Course（Cou，Stu，Pre）的属性分别表示课程、选修该课程的学生及该课程的先修课。Cou值与Stu值、Cou值与Pre值之间都是1：n联系，并且这两个1：n联系是独立的。

Cou Stu Pre
C4 S1 C1
C4 S1 C2
C4 S1 C3
C4 S2 C1
C4 S2 C2
C4 S2 C3

该关系模式的主键为（Cou，Stu，Pre），由BCNF范式的定义及性质可知，此模式属于BCNF范式。

该关系模式仍然存在以下异常。

（1）插入异常。插入选修某门课的学生，因该课程有多门先修课，需要插入多个元组。导致插入一个元组，却需插入多个元组的情况。

（2）删除异常。删除某门课程的一门先修课，因为选修该课程的学生有多名，所以需删除多个元组。导致删除一个元组却要删除了多个元组的情况。

（3）数据冗余。每门课程的先修课，由于有多名学生选修该课程，所以需存储多次，导致数据大量冗余。

（4）更新异常。修改一门课程的先修课，由于该课程涉及多名学生，所以需修改多个元组。

该关系模式已经达到函数依赖范畴内的最高范式BCNF，为什么还存在这4种异常？问题的根源在于先修课（Pre）的取值与学生（Stu）的取值，彼此独立、毫无关系，它们都取决于课程名（Cou）。此即多值依赖的表现。

定义: 设R是一个具有属性集合U的关系模式，X、Y和Z是属性集U的子集，并且Z=U-X-Y。如果对于R的任一关系，对于X的一个确定值，存在Y的一组值与之对应，且Y的这组值仅仅决定于X的值而与Z值无关，则称Y多值依赖于X，或X多值决定Y，记作X→→Y。

【示例-24】 多值依赖示例。

以关系模式Course（Cou，Stu，Pre）为例，其上的多值依赖关系有：
｛Cou→→Stu，Cou→→Pre｝

对于Cou→→Stu，因为每组（Cou，Pre）上的值，对应一组Stu值，且这种对应只与Cou的值有关，而与Pre的值无关。同理，对于Cou→→Pre，每组（Cou，Stu）上的值，对应一组Pre值，且这种对应只与Cou的值有关，而与Stu的值无关。

2、多值依赖的性质

设U是一个关系模式的属性全集，X、Y、Z都是U的子集。以下为多值依赖推理出的几个性质。

（1）多值依赖对称性。若X→→Y，则X→→Z，其中Z=U-X-Y。
（2）多值依赖传递性。若X→→Y，Y→→Z，则X→→Z-Y。
（3）多值依赖合并性。若X→→Y，X→→Z，则X→→YZ。
（4）多值依赖分解性。若X→→Y，X→→Z，则X→→Y∩Z，X→→Y-Z，X→→Z-Y。
（5）函数依赖可看作是多值依赖的特殊情况。若X→Y，则X→→Y。

3、第四范式

设R是一个具有属性集合U的关系模式，X、Y和Z是属性集U的子集，并且Z=U-X-Y。在多值依赖中，若X→→Y且Z=U-X-Y≠φ，则称X→→Y是非平凡多值依赖，否则称为平凡多值依赖。

定义：设有一关系模式R（U），U是其属性全集，X、Y是U的子集，D是R上的数据依赖集。如果对于任一多值依赖X→→Y，此多值依赖是平凡的，则称关系模式R是第四范式，记作4NF。

BCNF关系向4NF转换的方法是，消除非平凡多值依赖，即将BCNF分解成多个4NF关系模式。

【示例-24】BCNF分解示例。

以关系模式Course（Cou，Stu，Pre）为例，其上存在非平凡多值依赖关系：

｛Cou→→Stu，Cou→→Pre｝

根据4NF定义，通过消除非平凡多值依赖，可将Course分解为如下两个4NF关系模式：

CS（Cou，Stu）
CP（Cou，Pre）

【例9-25】设关系模式R（ABCEFG），数据依赖集D={A→→BCG，B→AC，C→G}，将R分解为4NF。

解答：

（1）因为A→→BCG，根据多值依赖的对称性可得A→→EF，所以将R分解为两个关系模式：
          R1（ABCG）  D1={ B→AC，C→G}
          R2（AEF）    D2={  }
（2）R2既无函数依赖也无多值依赖，所以R2已是4NF。
（3）R1的候选键是B，因为存在非主属性G对候选键B的传递依赖，所以R1是2NF，所以将其分解为两个关系模式：
          R11（ABC）   D11={ B→AC}
          R12（CG）    D12={ C→G}
     根据定义，R11和R12已是4NF。
（4）R关系分解为4NF的结果是：
         R1（ABC）   D1={ B→AC}
         R2（CG）    D2={ C→G}
         R3（CG）    D3={ C→G}

1.10.8 关系模式规范化总结

1NF(消去非主属性对候选键的部分函数依赖)

2NF

↓ (消去非主属性对候选键的传递函数依赖)

3NF

↓ (消去主属性对候选键的部分和传递函数依赖)

BCNF

1.11 关系数据库设计

什么是数据库设计呢？

设计数据库的各级模式并建立数据库，这是数据库应用系统设计的一部分。

当然设计一个好的数据库与设计一个好的数据库应用系统是密不可分的。一个好的数据库结构是应用系统的基础。

作为一名设计人员，首先必须要明确数据库设计要考虑和解决的主要问题。

为什么需要设计数据库?

数据库设计就是将数据库中的数据对象以及这些数据对象之间关系进行规划和结构化的过程
  • 良好的数据库设计
节省数据的存储空间
能够保证数据的完整性
方便进行数据库应用系统的开发
  • 糟糕的数据库设计：
数据冗余、存储空间浪费
内存空间浪费
数据更新和插入的异常

1.11.1 数据库设计概述

1、数据库设计问题

在整个数据库开发周期中要解决的主要问题或任务是：

（1）确定用户的需求（包括数据、功能和运用）是什么？如何表示它们？
（2）这些需求如何转换成有效的逻辑数据库结构？
（3）如何在计算机上有效地实现这种逻辑数据库结构及基于这种结构的存取？
（4）怎样用这种数据库结构及其存取的系统去实现满足用户当前和将来的新的需求？

2、数据库设计方法

什么是“好”的数据库设计方法呢？

首先，它应该能在合理的时间内以合理的工作量在给定的条件下产生一个有效的数据库。有效的数据库就是能实现各种用户需求（即对数据要求、处理要求、性能要求、安全性及完整性要求等的适应）、满足各种限制（如完整性、一致性和安全性限制，响应时间限制，存储空间限制等），且以最简的数据模型表示的（为了便于用户理解）数据库。

其次，它应具有充分的一般性和灵活性，以便能为具有各种数据库设计经验的人使用。

最后，它应是可重复使用的，即不同的人对同一问题使用该方法应能产生同样或几乎同样的结果。

（1）基于E-R模型的数据库设计方法

E-R方法设计的基本步骤是：

① 确定实体类型；
② 确定实体联系；
③ 画出E-R图；
④ 确定属性；
⑤ 将E-R图转换成某个DBMS可接受的逻辑数据模型；
⑥ 设计记录格式。

（2）基于3NF的数据库设计方法

基于3NF的数据库设计方法是用关系规范化理论为指导来设计数据库的逻辑模型。其基本思想是在需求分析的基础上确定数据库模式中全部的属性与属性之间的依赖关系，将它们组织为一个单一的关系模式，然后再将其投影分解，消除其中不符合3NF的约束条件，把其规范成若干个3NF关系模式的集合。

（3）计算机辅助数据库设计方法

计算机辅助数据库设计是数据库设计趋向自动化的一个重要方面，其设计的基本思想不是要把人从数据库设计中赶走，而是提供一个交互式平台，一方面充分地利用计算机速度快、容量大和自动化程度高的特点，完成比较规则、重复性大的设计工作；另一方面又充分发挥设计者的技术和经验，作出一些重大决策，人机结合，互相渗透，帮助设计者更好地进行数据库设计。

3、数据库应用系统设计过程

数据库设计开始之前，首先必须确定参加设计的人员，包括系统分析人员、数据库设计人员、应用开发人员、数据库管理员和用户代表。

系统分析人员和数据库设计人员是数据库设计的核心人员，他们将自始至终的参与数据库设计，他们的水平决定了数据库系统的质量。

用户和数据库管理员在数据库设计中也是举足轻重的，他们主要参加需求分析和数据库的运行和维护，他们的积极参与（不仅仅是配合）不但能加速数据库设计，而且也是决定数据库设计质量的重要因素。

应用开发人员（包括程序员和操作员）分别负责编制程序和准备软硬件环境，他们在系统实施阶段参与进来。

设计过程可划分成6个阶段：规划、需求分析、设计、实现、测试和运行维护。

（1）规划阶段

规划阶段具体可分成3个步骤。

① 系统调查。对企业组织作全面的调查，画出组织层次图，以了解企业的组织机构。

② 可行性分析。从技术、经济、效益、法律等诸方面对数据库的可行性进行分析；然后写出可行性分析报告；组织专家进行讨论其可行性。

③ 确定数据库系统的总目标和制定项目开发计划。在得到决策部门批准后，就正式进入数据库系统的开发工作。

（2）需求分析阶段

这一阶段是计算机人员（系统分析员）和用户双方共同收集数据库所需要的信息内容和用户对处理的需求。并以需求说明书的形式确定下来，作为以后系统开发的指南和系统验证的依据。

需求分析是整个设计过程的基础，是最困难、最耗费时间的一步。作为“地基”的需求分析是否做的充分与准确，决定了在其上构建数据库大厦的速度与质量。需求分析做得不好，甚至会导致整个数据库设计返工重做。

（3）设计阶段

1）概念设计阶段

概念设计的目标是产生反映企业组织信息需求的数据库概念结构，即概念模型。概念模型是独立于计算机硬件结构，独立于支持数据库的DBMS。

2）逻辑设计阶段

概念设计的结果是得到一个与DBMS无关的概念模型。而逻辑设计的目的是把概念设计阶段设计好的全局E-R模型转换成DBMS能处理的逻辑模型。这些模型在功能上、完整性和一致性约束及数据库的可扩充性等方面均应满足用户的各种要求。

3）物理设计阶段

对于给定的基本数据模型选取一个最适合应用环境的物理结构的过程，称为物理设计。

（4）实现阶段

数据库实现主要包括3项工作。

① 用DBMS提供的DDL（数据定义语言）定义数据库结构；
② 组织数据入库；
③ 编制与调试应用程序。

（5）测试阶段

在这一阶段，对数据库的结构及使用进行测试；对数据库的并发控制、恢复、安全性、完整性措施进行测试。采用软件工程的白盒测试和黑盒测试方法，对应用程序进行单元测试和集成测试。

应用程序调试完成，并且已有一小部分数据入库后，就可以开始数据的试运行了。在数据库试运行阶段，由于系统还不稳定，硬、软件故障随时都有可能发生，而且系统的操作人员对新系统还不熟悉，误操作也不可避免，因此必须做好数据库的转储和恢复工作，尽量减少对数据库的破坏。

（6）运行维护阶段

在数据库试运行结果符合设计目标后，数据库就可以真正投入运行了。数据库投入运行标志着开发任务的基本完成和维护工作的开始，并不意味着设计过程结束，由于应用环境在不断变化，数据库运行过程中物理存储也会不断变化，所以对数据库设计进行评价、调整、修改等维护工作是一个长期的任务，也是设计工作的继续和提高。

1.11.2 需求分析

对用户需求进行调查、描述和分析是数据库设计过程的最基础的一步。从开发设计人员的角度讲，事先并不知道数据库应用系统到底要“做什么”，它是由用户提供的。但遗憾的是，用户虽然熟悉自己的业务，但往往不了解计算机技术，难以提出明确、恰当的要求；而设计人员常常不了解用户的业务甚至非常陌生，难以准确、完整地用数据模型来模拟用户现实世界的信息类型和信息之间的联系。在这种情况下，马上要对现实问题进行设计，几乎注定要返工，因此用户需求分析是数据库设计必经的一步。

1、需求分析的任务

（1）信息需求

信息需求是最基本的，它作用于整个数据库设计过程的各步。信息需求就是用户需要从数据库中获得信息的内容和性质。由信息要求可以导出数据要求，即在数据库中需要存储哪些数据。

（2）处理需求

处理需求就是用户需要数据库系统提供的各种处理功能。这里，用户类型必须具有代表性、完全性，要包括业务层、计划管理层、领导层等用户。要考虑当前应用还要考虑可能的操作变化及未来的策略。

（3）运行需求

运行需求是指如何使用数据库方面的要求，包括使用数据库的安全性、完整性、一致性限制；查询方式、输入输出格式、同时能支持的用户或应用个数等方面的要求；对数据库性能方面的要求，如响应速度、故障恢复速度等。

2、需求分析的过程

（1）分析用户活动，产生业务流程图。

了解用户当前的业务活动和职能，搞清其处理流程（即业务流程）。如果一个处理比较复杂，就要把处理分成若干个子处理，使每个处理功能明确、界面清楚，分析之后画出用户的业务流程图。

（2）确定系统范围，产生系统关联图。

这一步是确定系统的边界。在和用户经过充分讨论的基础上，确定计算机所能进行的数据处理的范围，确定哪些工作由人工完成，哪些计算机系统完成，即确定人机界面。

（3）分析用户活动涉及的数据，产生数据流图。

深入分析用户的业务处理，以数据流图形式表示出数据的流向和对数据所进行的加工。

数据流图是从“数据”和“对数据的加工”两方面表达数据处理系统工作过程的一种图形表示法，具有直观、易于被用户和软件人员双方都能理解的一种表达系统功能的描述方式。

（4）分析系统数据，产生数据字典。

数据字典是对数据描述的集中管理，它的功能是存储和检索各种数据描述。对数据库设计来说，数据字典是进行详细的数据收集和数据分析所获得的主要成果。

3、用户需求调研的方法

（1）审阅以前的研究及应用情况。

在调研过程中，不但应该仔细研究用户的业务需求，而且还要考察现有的系统。

（2）查阅文档。

这里所说的文档并不是指文本化的，事实上是形式化的，包括图例、表格、文件、报告、单据等。

（3）发调查问卷。

就用户的职责范围、业务工作目标结果（输出）、业务处理过程与使用的数据、与其他业务工作的联系（接口）等方面，请其回答若干问题。

（4）同用户交谈。

与用户代表面谈，这是需求调查目前最有效的方法。

（5）现场调查。

深入用户的业务活动中进行实地调研，目的在于掌握业务流程所发生的各个事件，收集有关的资料以补充前面工作不足。但要避免介入或干涉其具体业务工作。

4、数据流图


外部实体：描述一个输入源点或输出汇点。其中注明源点或汇点的名称。


加工：描述一个处理过程。输入数据在此进行变换产生输出数据。其中注明数据处理的名称。


数据流：在转换之间有向流动的数据项或数据项集合。流线上注明数据流名称，箭头代表数据流动方向。


数据存储：为一个或多个转换提供数据源或数据存储服务的缓冲区、文件或数据库。其中注明数据存储名称。

在使用数据流图来进行系统分析的时候，在构造各个层次的数据流图的时候必须注意以下问题。

（1）有意义地为数据流、加工、数据存储以及外部实体命名，名字应反映该成分的实际含义，避免使用特别简单的、空洞的名字。

（2）在数据流图，需要画的是数据流而不要画控制流。

（3）一个加工的输出数据流不应与一个输入数据流同名，即使它们的组成成分相同。

（4）允许一个加工有多条数据流流向另一个加工，也允许一个加工有两个相同的输出数据流流向两个不同的加工。

（5）保持父图与子图平衡。也就是说，父图中某加工的输入输出数据流必须与它的子图的输入输出数据流在数量和名字上相同。值的注意的是：如果父图的一个输入（或输出）数据流对应于子图中几个输入（或输出）数据流，而子图中组成这些数据流的数据项全体正好是父图中的这一个数据流，那么它们仍然算是平衡的。

（6）在自顶向下的分解过程中，若一个数据存储首次出现时只与一个加工相关，那么这个数据存储应作为这个加工的内部文件而不必画出。

（7）保持数据守恒。也就是说，一个加工的所有输出数据流中的数据必须能从该加工的输入数据流中直接获得，或者是通过该加工能产生的数据。

（8）每个加工必须既有输入数据流，又有输出数据流。

（9）在整套数据流图中，每个数据存储必须既有读的数据流，又有写的数据流。但在某一张子图中可能只有读没有写，或者只有写没有读。

5、数据字典

数据字典通常包括数据项、数据结构、数据流、数据存储和处理过程5个部分。其中数据项是数据的最小组成单位，若干个数据项可以组成一个数据结构，数据字典通过对数据项和数据结构的定义来描述数据流、数据存储的逻辑内容。

“学生选课”数据流图

（1）数据项

数据项描述=｛数据项名，数据项含义说明，别名，数据类型，长度，取值范围，取值含义，与其他数据项的逻辑关系，数据项之间的联系｝

例如：以“学号”为例

数据项名：  学号
数据项含义：惟一标识每一个学生
别名：      学生编号
数据类型：  字符型
长度：      8
取值范围：  00000000～99999999
与其他数据项的逻辑关系：主码或外码

（2）数据结构

数据结构描述=｛数据结构名，含义说明，组成：｛数据项或数据结构｝｝

例如：以“学生”为例

数据结构名：学生
含义说明：是学籍管理子系统的主体数据结构，定义了一个学生的有关信息
组成：    学号、姓名、性别、年龄、所在系

（3）数据流

数据流描述=｛数据流名，说明，数据流来源，数据流去向，
组成：｛数据结构｝，平均流量，高峰期流量}

其中，“数据流来源”是说明该数据流来自哪个过程；“数据流去向”是说明该数据流将到哪个过程去；“平均流量”是指在单位时间（每天、每周、每月等）里的传输次数；“高峰期流量”则是指在高峰时期的数据流量。

例如：以“选课信息”为例

数据流名：  选课信息
说明：      学生所选课程信息
数据流来源：“学生选课”处理
数据流去向：“学生选课”存储
组成：      学号，课程号
平均流量：  每天10个
高峰期流量：每天100个

（4）数据存储

数据存储描述=｛数据存储名，说明，编号，流入的数据流 ，流出的数据流 ，组成：｛数据结构｝，数据量，存取频度，存取方式｝

其中，“存取频度”指每小时或每天或每周存取几次、每次存取多少数据等信息；“存取方式”包括是批处理还是联机处理、是检索还是更新、是顺序检索还是随机检索等；另外，“输入的数据流”要指出其来源；“输出的数据流”要指出其去向。

例如：以“学生选课”为例

数据存储名：  学生选课表
说明：        记录学生所选课程的成绩
编号：        无
流入的数据流：选课信息、成绩信息
流出的数据流：选课信息、成绩信息
组成：        学号，课程号，成绩
数据量：      50000个记录
存取频度：    每天20000个记录
存取方式：    随机存取

（5）处理过程

处理过程描述=｛处理过程名，说明，输入：｛数据流｝，输出：｛数据流｝，处理：｛简要说明｝｝

其中，“简要说明”中主要说明该处理过程的功能及处理要求。功能是指该处理过程用来做什么（而不是怎么做），处理要求包括处理频度要求，如单位时间里处理多少事务、多少数据量、响应时间要求等。这些处理要求是后面物理设计的输入及性能评价的标准。

例如：以“学生选课”为例

处理过程名：学生选课
说明：      学生从可选修的课程中选出课程
输入数据流：学生，课程
输出数据流：学生选课信息
处理：      每学期学生都可以从公布的选修课程中选修自己需要的课程，选课时有些选修课有先修课程的要求，还要保证选修课的上课时间不能与该生必修课时间相冲突，每个学生四年内的选修课门数不能超过16门。

1.11.3 概念数据建模

之所以称为“概念”，是因为它仅由表示现实世界中的实体及其联系的抽象数据形式定义，根本不涉及计算机硬软件环境，与DBMS或任何其他的物理特性无关。

1、建模方法

E-R建模方法设计概念模型一般有两种方法。

（1）视图集成建模法。

视图集成建模法，即自底向上建模法。以各部分需求说明为基础，分别设计各部门的局部模式；然后再以这些视图为基础，集成一个全局模式。这个全局模式就是所谓的概念模式。该方法适合于大型数据库的设计。

（2）集中模式建模法。

集中模式建模法，即自顶向下建模法。首先将需求说明综合成一个一致的统一的需求说明，然后在此基础上设计一个全局的概念模式，再据此为各个用户或应用定义子模式。该法强调统一，适合于小的、不太复杂的应用。

2、建模的基本任务与步骤

（1）用户视图建模

构造实体方法如下：

1）根据数据流图和数据字典提供的情况，将一些对应于客观事物的数据项汇集、形成一个实体，数据项则是该实体的属性。这里的事物可以是具体的事物或抽象的概念、事物联系或某一事件等。

2）将剩下的数据项用一对多的分析方法，再确定出一批实体。某数据项若与其它多个数据项之间存在一对多的对应关系，那么这个数据项就可以作为一个实体，而其他多个数据项则作为它的属性。

3）分析最后一些数据项之间的紧密程度，又可以确定一批实体。如果某些数据项完全依赖于另一些数据项，那么所有这些数据项可以作为一个实体，而后者“另一些数据项”可以作为此实体的键。

（2）视图集成

视图集成要解决如下问题。

（1）命名冲突。指属性、联系、实体的命名存在冲突，冲突有同名异义和同义异名两种。

（2）结构冲突。同一概念在一个视图中可作为实体，在另一个视图中可作为属性或联系。

（3）属性冲突。相同的属性在不同的视图中有不同的取值范围。例如，学号在一个视图中可能是字符串，在另一个视图中可能是整数。有些属性采用不同的度量单位。例如，身高在一个视图中用厘米作单位，在另一个视图中可能用米作单位。

（4）标识的不同。要解决多标识机制。例如，在一个视图中，可能用学号唯一标识学生，而在另外的一些视图中，可能用校园卡卡号作为学生的唯一标识。

（5）区别数据的不同子集。例如，学生可分为本科生、硕士生、博士生。具体的做法，可以选取最大的一个局部视图作为基础，将其他局部视图逐一合并。合并时尽可能合并对应部分，保留特殊部分，删除冗余部分。必要时，对局部视图进行适当修改，力求使视图简明清晰。

1.11.4 逻辑结构设计

由概念建模所产生的概念模型完全独立于DBMS及任何其他软件或计算机硬件特征。该模型必须转换成DBMS所支持的逻辑数据结构，并最终实现为物理存储的数据库结构。

1、E-R图向关系模型的转换

（1）实体转换成关系模式

实体转换成关系模式很直接，实体的名称即是关系模式的名称，实体的属性则为关系模式的属性，实体的主键就是关系模式的主键。

【示例-25】将下面所给的“学生”实体转换成关系模式。

解答：

“学生”实体转换成的关系模式为：
       学生（ 学号 ，姓名，性别，班级）

但在转换时需要注意以下3个问题。

（1）属性取值范围的问题。如果所选用的DBMS不支持E-R图中某些属性的取值范围，则应作相应修改，否则由应用程序处理转换。

（2）非原子属性的问题。E-R模型中允许非原子属性，这不符合关系模型的1NF的条件，必须作相应的修改。

（3）弱实体的转换。弱实体在转换成关系模式时，弱实体所对应的关系模式中必须包含强实体的主键。

【示例-26】将下面所给的E-R图中的“销售价格”弱实体转换成关系模式。

解答：

将“销售价格”弱实体转换成的关系模式为：
销售价格（ 零件编号 ，销售性质 ，售货价格）

（2）联系的转换

二元联系的转换

实体之间的联系，有1：1、1：n和m：n等3种，它们在向关系模型转换时，采取的策略是不一样的。

  • 1：1 联系的转换

一个1：1联系可以转换为一个独立的关系，也可以与任意一端对应的关系模式合并。

① 转换为一个独立的关系模式，则与该联系相连接的各实体的键及联系本身的属性均转换为该关系模式的属性，每个实体的键均是该关系模式的候选键。

② 与某一端实体对应的关系模式合并，则需要在该关系模式的属性中加入另一个关系模式的键（作为外键）和联系本身的属性。

【例10-4】将下面的E-R图转换成关系模式。

解答：

- 方案一
学生（ 学号 ，姓名，性别，班级）
床位（ 楼号 ， 寝室号 ，床号 ）
入住（ 学号 ， 楼号 ，寝室号 ，床号  ，入住时间）

- 方案二
学生（ 学号 ，姓名，性别，班级， 楼号 ，寝室号 ，床号 ，入住时间）
床位（ 楼号 ，寝室号 ， 床号）

- 方案三
学生（ 学号 ，姓名，性别，班级）
床位（ 楼号 ，寝室号 ，床号 ，学号  ，入住时间）
  • 1：n联系的转换

在n端实体转换的关系模式中加入1端实体的键（作为外键）和联系的属性。

【示例-27】将下面所给的E-R图转换成关系模式。

解答：

管理经理（ 员工号 ，姓名，性别）
公寓（ 楼号 ，名称， 员工号 ）
  • m：n联系的转换

将联系转换为一个独立的关系模式，其属性为两端实体的键（作为外键）加上联系的属性，两端实体的键组成该关系模式的键或键的一部分。

【示例-28】将下面所给的E-R图转换成关系模式。

解答：

学生（ 借书证号 ，姓名，系）
图书（ 图书编号 ，书名，价格）
借阅（ 借书证号，图书编号，借阅日期）

【示例-29】综合练习。

将下面所给的一个有关教学管理的E-R图转换成关系模式，E-R图如下。

解答：

转换成的4个关系模式如下所示。

系（ 系编号 ，系名，电话，教工号 ）
教师（ 教工号 ，姓名，性别，职称， 系编号 ，聘期）
课程（ 课程号 ，课程名，学分， 系编号 ）
任教（ 教工号 ，课程号 ，教材）

一元联系的转换

和二元联系的转换类似。

【示例-30】将下面所给的一元联系E-R图转换成关系模式。

解答：

转换成的关系模式：  
职工（ 工号 ，姓名，年龄，性别，经理工号 ）

三元联系的转换

（1）1：1：1联系转换

如果实体间的联系是1：1：1，可以在3个实体转换成的3个关系模式中，任意一个关系模式的属性中加入另两个关系模式的键（作为外键）和联系的属性。

（2）1：1：n联系转换

如果实体间的联系是1：1：n，则在n端实休转换成的关系模式中加入两个1端实体的键（作为外键）和联系的属性。

（3）1：m：n联系转换

如果实体间的联系是1：m：n，则将联系也转换成关系模式，其属性为m端和n端实体的键（作为外键）加上联系的属性， 两端实体的键作为该关系模式的键或键的一部分。1端的键可以根据应用的实际情况，加入到m端或者n端或者联系中作为外键。

（4）m：n：p联系转换

如果实体间的联系是m：n：p，则将联系也转换成关系模式，其属性为3端实体的键（作为外键）加上联系的属性，各实体的键组成该关系模式的键或键的一部分。

【示例-31】将下面的三元联系转换成关系模式。

解答：

仓库（ 仓库号 ，仓库名，地址）
商店（ 商店号，商店名）
商品（ 商品号，商品名）
进货（ 仓库号 ， 商店号 ，商品号 ，日期，数量）

2、采用E-R模型的逻辑设计步骤

关系数据库的逻辑设计:

1）导出初始关系模型
逻辑设计的第1步是把概念设计的结果，即全局E-R模型，转换成初始关系模型。

2）规范化处理
对于从E-R图转换来的关系模式，就要以关系数据库规范化设计理论为指导，对得到的关系模式逐一分析，确定它们分别是第几范式，并通过必要的分解来得到一组3NF的关系。

3）模式评价
模式评价的目的是检查已给出的数据库模式是否完全满足用户的功能要求，是否具有较高的效率，并确定需要加以修正的部分。模式评价主要包括功能和性能两个方面。

4）模式优化
根据模式评价的结果，对已生成的模式集进行优化。

（1）数据模式的优化

对关系模式规范化，其优点是消除异常、减少数据冗余、节约存储空间，相应的逻辑和物理的I/O次数减少，同时加快了增、删、改的速度。但是，对完全规范的数据库查询，通常需要更多的联接操作，而联接操作很费时间，从而影响查询的速度。因此，有时为了提高某些查询或应用的性能，而有意破坏规范化规则，这一过程叫逆规范化。

  • 增加冗余属性。

增加冗余属性，是指在多个关系中都具有相同的属性，它常用来在查询时避免联接操作。

例如，在“公寓管理系统”中，有如下两个关系：

学生（ 学号 ，姓名，性别，班级）
床位（ 楼号 ，寝室号 ，床号 ，学号 ）

如果公寓管理人员经常要检索学生所在的公寓、寝室、床位，则需要对“学生”和“床位”进行联接操作。而对于公寓管理来说，这种查询非常频繁。因此，可以在“学生”关系中增加3个属性：楼号、寝室号和床号。这3个属性即为冗余属性。

增加冗余属性，可以在查询时避免联接操作。但它需要更多的磁盘空间，同时增加了表维护的工作量。

  • 增加派生属性。

增加派生属性，是指增加的属性来自其他关系中的数据，由它们计算生成。它的作用是在查询时减少联接操作，避免使用聚集函数。

例如，在“公寓管理系统”中，有如下两个关系：

公寓（楼号，公寓名）
床位（楼号，寝室号，床号，学号）

如果想获得公寓名和该公寓入住了多少学生，则需要对两个关系进行联接查询，并使用聚集函数。如果这种查询很频繁，则有必要在“公寓”关系中加入“学生人数”属性。相应的代价是必须在“床位”关系上，创建增、删、改的触发器来维护“公寓”中“学生人数”的值。派生属性具有冗余属性同样的缺点。

  • 重建关系。

重建关系，是指如果许多用户需要查看两个关系联接出来的结果数据，则把这两个关系重新组成一个关系，以减少联接而提高查询性能。

例如，在教务管理系统中，教务管理人员需要经常同时查看课程号、课程名称、任课教师号、任课教师姓名，则可把关系：

课程（课程编号，课程名称，教师编号）
教师（教师编号，教师姓名）

合并成一个关系：

课程（课程编号，课程名称，教师编号，教师姓名）

这样可提高性能，但需要更多的磁盘空间，同时也损失了数据的独立性。

  • 分割关系。

水平分割。

水平分割通常在下面的情况下使用。

① 数据量很大。分割后可以降低在查询时需要读的数据和索引的页数，同时也降低了索引的层数，提高了查询速度。

② 数据本身就有独立性。例如，数据库中分别记录各个地区的数据或不同时期的数据，特别是有些数据常用，而另外一些数据不常用。
水平分割会给应用增加复杂度，它通常在查询时需要多个表名，查询所有数据需要UNION操作。在许多数据库应用中，这种复杂性会超过它带来的优点。因为，在索引用于查询时，增加了读一个索引层的磁盘次数。

垂直分割。

垂直分割是把关系中的主键和一些属性构成一个新的关系，把主键和剩余的属性构成另外一个关系。如果一个关系中某些属性常用，而另外一些属性不常用，则可以采用垂直分割。

垂直分割可以使得列数变少，一个数据页就能存放更多的数据，在查询时就会减少I/O次数。其缺点，是需要管理冗余属性，查询所有数据需要联接（JOIN）操作。

（2）设计用户外模式

1）重定义属性名。

设计视图时，可以重新定义某些属性的名称，使其与用户习惯保持一致。属性名的改变并不影响数据库的逻辑结构，因为，这里的新的属性名是“虚的”，视图本身就是一张虚拟表。

2）提高数据安全性。

利用视图可以隐藏一些不想让别人操纵的信息，提高了数据的安全性。

3）简化了用户对系统的使用。

由于视图已经基于局部用户对数据进行了筛选，因此屏蔽了一些多表查询的联接操作和一些更加复杂的查询（如分组、聚集函数查询），大大简化了用户的使用。

1.11.5 物理设计

数据库的物理设计是从数据库的逻辑模式出发，设计一个可实现的、有效的物理数据结构，包括文件结构选择和存储记录结构设计、记录的存储安置和存取方法选择，以及系统性能评测。

索引是从数据库中获取数据的、最高效的方式之一，绝大部分的数据库性能问题都可以采用索引技术得到解决。

1、索引存取方法

在下列情况下，有必要考虑在相应属性上建立索引。

（1）如果一个（或一组）属性经常在查询条件中出现，则考虑在这个（或这组）属性上建立索引（或组合索引）。

（2）如果一个属性经常作为最大值或最小值等聚集函数的参数，则考虑在这个属性上建立索引。

（3）如果一个（或一组）属性经常在联接操作的联接条件中出现，则考虑在这个（或这组）属性上建立索引。

2、聚簇索引存取方法

若满足下列情况之一，可考虑建立聚簇索引。

（1）如果一个关系的一组属性经常作为检索限制条件，且返回大量数据，则该单个关系可建立聚簇。

（2）如果一个关系的一个（或一组）属性上的值重复率很高，则此单个关系可建立聚簇。

（3）如果一个关系的一个（或一组）属性作为排序、分组等条件，则此单个关系可建立聚簇。因为当SQL语句中包含有与聚簇键有关的ORDER BY、GROUP BY、DISTINCT等子句或短语时，使用聚簇特别有利，可以省去对结果集的排序操作。

3、不适于建立索引的情况

一般在下列情况下不考虑建立索引。

（1）小表（记录很少的表）。不要为小表设置任何索引，假如它们经常有插入和删除操作就更不能设置索引。对这些插入和删除操作的索引，维护它们的时间可能比扫描表的时间更长。

（2）值过长的属性。如果属性值很长，则在该属性上建立索引所占存储空间很大。

（3）很少作为操作条件的属性。因为很少有基于该属性的值去检索记录，此索引的使用率很低。

（4）频繁更新的属性。因为对该属性的每次更新都需要维护索引，系统开销较大。

（5）属性值很少的属性。例如，“性别”属性只有“男”、“女”两种取值，在上面建立索引并不利于检索。

1.11.6 数据库的实现与测试

1、定义数据库结构

确定了数据库的逻辑结构与物理结构后，就可以用所选用的DBMS提供的数据定义语言DDL来严格描述数据库结构。

2、数据装载

（1）对于数据量不是很大的小型系统，可以用人工方法完成数据的入库，步骤如下。

① 筛选数据。需要装入数据库中数据，通常都分散在各个部门的数据文件或原始凭证中，所以首先必须把需要入库的数据筛选出来。

② 转换数据格式。筛选出来的需要入库的数据，其格式往往不符合数据库要求，还需要进行格式转换。这种转换有时可能很复杂。

③ 输入数据。将转换好的数据输入计算机中。

④ 校验数据。检查输入的数据是否有误。

（2）对于大中型系统，由于数据量极大，用人工方式组织数据入库将会耗费大量人力物力，而且很难保证数据的正确性。为了保证数据能够及时入库，应在数据库物理设计的同时编制数据输入子系统，由计算机辅助数据的入库工作，这个输入工具一般可作为最终应用程序的一个模块——输入子系统。其步骤如下。

① 筛选数据。

② 输入数据。由录入员将原始数据直接输入计算机中，数据输入子系统应提供输入界面。

③ 检验数据。数据输入子系统采用多种检验技术检查输入数据的正确性。

④ 转换数据。数据输入子系统根据数据库系统的要求，从录入的数据中抽取有用成分对其进行分类，然后转换数据格式。抽取、分类和转换数据是数据输入子系统的主要工作。也是数据输入子系统的复杂性所在。

⑤ 综合数据。数据输入子系统对转换好的数据根据系统的要求进一步综合成最终数据。

3、编制与调试应用程序

数据库应用系统中应用程序的设计应该与数据设计并行进行。在数据库实现阶段，当数据库结构建立好后，就可以开始编制数据库的应用程序，也就是说，编制应用程序是与组织数据入库同步进行的。

4、程序的测试

应用程序初步完成后，应首先用少量数据对应用程序进行初步测试。这实际上是软件工程中的软件测试，目的是检验程序的工作是否正常，即对于正确的输入，程序能否产生正确的输出；对于非法的输入，程序能否正确地鉴别出来，并拒绝处理等。

5、数据库试运行

数据库试运行期间，应利用性能监视工具对系统性能进行监视和分析。应用程序在少量数据的情况下，如果功能表现完全正常，那么在大量数据时，主要看它的效率，特别是在并发访问情况下的效率。如果运行效率不能达到用户的要求，就要分析是应用程序本身的问题，还是数据库设计的缺陷。对于应用程序的问题，就要以软件工程的方法排除；对于数据库设计的问题，可能还需要返工，检查数据库的逻辑设计是否不好。接下来，分析逻辑结构在映射成物理结构时，是否充分考虑了DBMS的特性。如果是，则应转储测试数据，重新生成物理模式。

1.11.7 数据库的运行维护

数据库维护的主要工作如下。

1．数据库的转储和恢复

    在系统运行过程中，可能存在无法预料的自然或人为的意外情况，如电源故障、磁盘故障等，导致数据库运行中断，甚至破坏数据库部分内容。许多大型的DBMS都提供了故障恢复的功能，但这种恢复大都需要DBA配合才能完成。因此，DBA要针对不同的应用要求制定不同的转储计划，定期对数据库和日志文件进行备份，以保证一旦发生故障，能利用数据库备份和日志文件备份，尽快将数据库恢复到某种一致性状态，并尽可能减少对数据库的破坏。

2．数据库的安全性、完整性控制

     DBA必须对数据库安全性和完整性控制负责。根据用户实际需要授予不同的操作权限。另外，在数据库运行过程中，应用环境的变化，对安全性的要求也会发生变化，比如有的数据原来是机密，现在是可以公开查询了，而新加入的数据又可能是机密的，而且系统中用户的密级也会改变。这些都需要DBA根据实际情况修改原有的安全性控制。同样，由于应用环境的变化，数据库的完整性约束条件也会变化，DBA应根据实际情况作出相应的修正。

3．数据库性能的监督、分析和改进

      在数据库运行过程中，监督系统运行，对监测数据进行分析，找出改进系统性能的方法是DBA的重要职责。利用DBMS提供的监测系统性能参数的工具，DBA可以方便地得到系统运行过程中一系列性能参数的值。DBA应该仔细分析这些数据，判断当前系统是否处于最佳运行状态，如果不是，则需要通过调整某些参数来进一步改进数据库性能。

4．数据库的重组织和重构造

      当数据库应用环境变化时，例如增加新的应用或新的实体，取消某些已有应用，改变某些已有应用，这些都会导致实体及实体间的联系也发生相应的变化，使原来的数据库设计不能很好地满足新的要求，从而不得不适当调整数据库的模式和内模式。例如，增加新的数据项、改变数据项的类型、改变数据库的容量、增加或删除索引、修改完整性约束条件等。这就是数据库的重构造。DBMS都提供了修改数据库结构的功能。
       
      重构造数据库的程度是有限的。若应用变化太大，已无法通过重构数据库来满足新的需求，或重构数据库的代价太大，则表明现有数据库应用系统的生命周期已经结束，应该重新设计新的数据库系统，开始新数据库应用系统的生命周期了。

1.11.8 MySQL数据库性能优化

性能优化是通过某些有效的方法提高MySQL数据库的性能。性能优化的目的是为了使MySQL数据库运行速度更快、占用的磁盘空间更小。

1、优化简介

使用SHOW STATUS语句查询MySQL数据库的性能参数.

SHOW STATUS LIKE 'value';

【说明】
value是要查询的参数值，常用的性能参数如下：

① Connections：连接MySQL服务器的次数。
② Uptime：MySQL服务器的上线时间。
③ Slow_queries：慢查询的次数。
④ Com_select：查询操作的次数。
⑤ Com_insert：插入操作的次数。
⑥ Com_update：更新操作的次数。
⑦ Com_delete：删除操作的次数。

2、优化查询

（1）分析查询语句

EXPLAIN语句的语法形式如下：

EXPLAIN SELECT语句;

【示例-32】使用EXPLAIN语句分析一个查询语句。

EXPLAIN SELECT * FROM employee;

DESCRIBE语句的语法形式如下：

DESCRIBE SELECT语句;

【示例-33】使用DESCIBE语句分析一个查询语句。

DESCRIBE SELECT * FROM employee WHERE 性别='女';

（2）索引对查询速度的影响

【示例-34】下面是查询语句中不使用索引和使用索引的对比。

EXPLAIN SELECT * FROM employee WHERE 姓名='刘东阳';


CREATE INDEX name_idx ON employee(姓名);

EXPLAIN SELECT * FROM employee WHERE 姓名='刘东阳';

（3）索引未提高查询速度的情况

1）使用LIKE关键字的查询语句

查询语句使用LIKE关键字进行查询时，如果匹配字符串的第一个字符为“%”，索引不会起作用。只有“%”不在第一个位置，索引才会起作用。

【示例-35】查询语句中使用LIKE关键字，并且匹配的字符串中包含有“%”的两种查询情况比较。

EXPLAIN SELECT * FROM employee WHERE 姓名 LIKE '%阳';


EXPLAIN SELECT * FROM employee WHERE 姓名 LIKE '刘%';

2）使用多列索引的查询语句

多列索引是在表的多个字段上创建一个索引。只有查询条件中使用了这些字段中的第一个字段时，索引才会被使用。

【示例-36】下面在employee表的学号和性别两个字段上创建多列索引，然后验证多列索引的使用情况。

CREATE INDEX sno_sex_idx ON employee(学号,性别);

EXPLAIN SELECT * FROM employee WHERE 学号='0001';


EXPLAIN SELECT * FROM employee WHERE 性别='女';

3）使用OR关键字的查询语句

查询语句的查询条件中只有OR关键字，且OR前后的两个条件中的列都是索引时，查询中才使用索引。如果OR前后有一个条件的列不是索引，那么查询中将不使用索引。

【示例-37】查询语句中使用OR关键字示例。

EXPLAIN SELECT * FROM employee WHERE 学号='0001' OR 姓名='刘东阳';


EXPLAIN SELECT * FROM employee WHERE 学号='0001' OR 出生日期='1990-10-23';

4）优化子查询

子查询可以使查询语句很灵活，但子查询的执行效率不高。执行子查询时，MySQL需要为内层查询语句的查询结果建立一个临时表。然后外层查询语句从临时表中查询记录。查询完毕后，再撤销这些临时表。因此，子的速度会受到一定的影响，如果查询的数据量比较大，这种影响就会随之增大。

在MySQL中，可以使用连接（JOIN）查询来代替子查询。连接查询不需要建立临时表，其速度比子查询要快，如果查询中使用了索引，性能会更好。

（3）优化数据库结构

1）将字段很多的表分解成多个表

【示例-38】假设employee表中有很多字段，其中“备注”字段存储着雇员的备注信息，有些备注信息的内容特别多。另外“备注”信息很少使用。对employee表进行分解。

① 根据题义，将employee表分解成两个表employee_info表和employee_extra表，employee_info为雇员基本信息表，employee_extra为雇员备注信息表。employee_extra表中存储两个字段，分别为雇员编号和备注。

② 如果需要查询某个雇员的备注信息，可以使用雇员编号查询。

③ 如果需要同时查询雇员基本信息与备注信息，可以将employee_info表和employee_extra表进行连接查询，查询语句如下：

SELECT 姓名,备注 FROM employee_info i,employee_extra e  
WHERE  i.学号=e.学号;

2）增加中间表

【例10-19】有employee表（雇员编号，姓名，职位，入职日期，工资，部门编号），department表（部门编号，部门名称，地址），实际中经常要查询雇员姓名、所在部门及工资信息。通过增加中间表，提高查询速度。

CREATE TABLE temp_emp(
 姓名 VARCHAR(10),
 部门名称 VARCHAR(14),
 工资 DECIMAL(7,2)
);

INSERT INTO temp_emp SELECT 姓名,部门名称,工资 FROM employee e,department d WHERE e.部门编号=d.部门编号;

以后，可以直接从temp_emp表中查询雇员的姓名、部门名称及工资，而不用每次都进行多表连接查询，提高数据库的查询速度。

3）增加冗余字段

设计数据库表的时候尽量达到3NF的要求，但是，有时候为了提高查询速度，可以有意识的在表中增加冗余字段。

例如，雇员信息存储在employee表中，部门信息存储在department表中，通过employee表中的部门编号与department表建立关联关系。如果要查询一个员工所在部门的名称，需要将这两个表进行连接查询，而连接查询会降低查询速度。那么，则可以在employee表中增加一个冗余字段部门名称，该字段用来存储员工所在部门的名称，这样就不用每次都进行多表连接操作了。

（4）优化插入记录的速度

1）禁用唯一性检查

插入数据时，MySQL会对插入的记录进行唯一性校验，这种校验也会降低插入记录的速度。可以在插入记录之前禁用唯一性检查。等到记录插入完毕后再开启。

禁用唯一性检查的语句形式如下：

SET UNIQUE_CHECKS=0;

开启唯一性检查的语句形式如下：

SET UNIQUE_CHECKS=1;

2）禁用外键检查

插入数据之前执行禁止对外键的检查，数据插入完成之后再恢复对外键的检查。

禁用外键检查的语句形式如下：

SET FOREIGN_KEY_CHECKS=0;

恢复对外键检查的语句形式如下：

SET FOREIGN_KEY_CHECKS=1;

3）使用批量插入

插入多条记录时，可以使用一条INSERT语句插入一条记录；也可以使用一条INSERT语句插入多条记录。

使用一条INSERT语句插入多条记录的情形如下：

INSERT INTO temp_emp VALUES
   ('李三','销售部',5000),
   ('赵四','人事部',6000),
   ('王五','财务部',4500);

执行多条INSERT语句插入多条记录的情形如下：

INSERT INTO temp_emp VALUES ('李三','销售部',5000);
INSERT INTO temp_emp VALUES ('赵四','人事部',6000);
INSERT INTO temp_emp VALUES ('王五','财务部',4500);

第一种方式减少了与数据库之间的连接等操作，其速度比第二种方式要快。

4）使用LOAD DATA INFILE批量导入

当需要批量导入数据时，如果通用LOAD DATA INFILE语句，就尽量使用。因为LOAD DATA INFILE语句导入数据的速度比INSERT语句速度快。

1.11.9 小 结

数据库应用设计过程分为6个阶段：规划阶段、需求分析阶段、设计阶段、实现阶段、测试阶段和运行维护阶段。

对系统进行调查、可行性分析，确定数据库系统的总目标和制定项目开发计划。规划阶段的好坏直接影响到整个系统的成功与否，对企业组织的信息化进程将产生深远的影响。

可以通过跟班作业、开调查会、专人介绍、询问、请用户填写调查表、查阅记录等方法调查用户需求，通过编制组织机构图、业务关系图、数据流图和数据字典等方法来描述和分析用户需求。

设计阶段主要包括概念设计、逻辑设计和物理设计。概念设计是数据库设计的核心环节，是在用户需求描述与分析的基础上对现实世界的抽象和模拟。目前，应用最广泛的概念设计工具是E-R模型。对于小型、不太复杂的应用，可使用集中模式设计法进行设计；对于大型数据库的设计可采用视图集成法进行设计。

逻辑设计是在概念设计的基础上，将概念模式转换为所选用的、具体的DBMS支持的数据模型的逻辑模式。将E-R图向关系模型的转换，转换后得到的关系模式，应首先进行规范化处理，然后根据实际情况对部分关系模式进行逆规范化处理。物理设计是从逻辑设计出发，设计一个可实现的、有效的物理数据库结构。现代DBMS将数据库物理设计的细节隐藏起来，使设计人员不必过多介入。但索引的设置必须认真对待，它对数据库的性能有很大的影响。

数据库的实现阶段和测试阶段，包括数据的载入、应用程序调试、数据库试运行等几个步骤，该阶段的主要目标，是对系统的功能和性能进行全面测试。

数据库运行和维护阶段的主要工作有数据库安全性与完整性控制、数据库的转储与恢复、数据库性能监控分析与改进、数据库的重组与重构等。

posted @ 2024-03-19 19:20  WNAG_zw  阅读(120)  评论(0)    收藏  举报