第1章 数据库基础概述
当今社会是一个信息化的社会，信息已经成为社会上各行各业的重要资源。数据是信息的载体，数据库是相互关联的数据集合。数据库能利用计算机保存和管理大量复杂的数据，快速而有效地为多个不同的用户和应用程序提供数据，帮助人们有效利用数据资源。目前，数据库应用已遍及生活中的各个角落，例如,学校的教学管理系统、图书馆的图书借阅系统、车站及航空公司的售票系统、电信局的计费系统、超市的售货系统、银行的业务系统、工厂的管理信息系统等。
数据库技术已经成为先进信息技术的重要组成部分，是现代计算机信息系统和计算机应用系统的基础和核心。因此，掌握数据库技术是全面认识计算机系统的重要环节，也是适应信息化时代的重要基础。
本章主要介绍数据库系统的基本概念、数据模型、数据库系统结构、关系数据理论和数据库系统体系结构。
1.1 数据库系统概述
在系统地介绍数据库的概念之前，这里首先介绍数据库最常用的一些基本概念。
1.1.1 数据管理技术的产生和发展
数据是现实世界中实体（或客体）在计算机中的符号表示。数据不仅可以是数字，还可以是文字、图表、图像、声音等。每个组织都保存了大量的复杂的数据。例如，银行有关储蓄存款、贷款业务、信用卡管理、投资理财等方面的数据；医院有关病历、药品、医生、病房、财务等方面的数据；超市有关商品、销售情况、进货情况、员工等方面的信息。数据是一个组织的重要资源，有时甚至比其他资源更珍贵。因此必须对组织的各种数据实现有效管理。数据管理是指对数据的分类、组织、编码、存储、检索和维护等操作。数据库的核心任务就是数据管理。
数据库技术并不是最早的数据管理技术。在计算机诞生的初期，计算机主要用于科学计算，虽然当时同样存在数据管理的问题，但当时的数据管理是以人工的方式进行的，后来发展到文件系统，再后来才是数据库。也就是说，数据管理主要经历了人工管理阶段、文件系统阶段和数据库系统阶段。
1.1.1.1 人工管理阶段
人工管理阶段是指计算机诞生的初期（20世纪50年代中期以前）。这个时期的计算机技术，从硬件看还没有磁盘这种可直接存取的存储设备，从软件看还没有操作系统，更没有管理数据的软件。人工管理阶段，程序与数据之间的对应关系如图1-1所示。
这个阶段数据管理的特点是:
 (1)  数据不保存。因为计算机主要用于科学计算，一般也不需要长期保存数据，只是在要完成某一个计算或课题时才输入数据，不仅原始数据不保存，计算结果也不保存。
 (2)  应用程序管理数据。数据需要由应用程序自己管理，没有相应的软件系统负责数据的管理工作。应用程序中不仅要规定数据的逻辑结构，而且要设计物理结构，包括存储结构存取方法、输入方式等，因此程序员负担很重。
 (3)  数据不共享。数据是面向应用的，一组数据只能对应一个程序。当多个应用程序涉及某些相同的数据时，由于必须各自定义，无法相互利用、相互参照，因此程序与程序之间有大量的冗余数据。
 (4)  数据不具有独立性。数据的逻辑结构或物理结构发生变化后，必须对应用程序做相应的修改，这进一步加重了程序员的负担。
1.1.1.2 文件系统阶段
文件系统阶段是指20世纪50年代后期到60年代中期这一阶段。在这个阶段，计算机不仅大量用于科学计算，也开始大量用于信息管理。像磁盘这样的直接存取存储设备也已经出现，在软件方面也有了操作系统和高级语言，有专门用于数据管理的软件--文件系统（或操作系统的文件管理部分）。在文件系统阶段，程序与数据之间的对应关系如图1-2所示。
图1-1 人工管理阶段程序与数据的对应关系
图1-2 文件系统阶段程序与数据之间的对应关系
这个阶段数据管理的特点是:
 (1)  由于存储设备的出现，数据可以长期保存在磁盘上，也可以反复使用，即可以经常对文件进行查询、更新和删除等操作。
 (2)  操作系统提供了文件管理功能和访问文件的存取方法，程序和数据之间有了数据存取的接口，程序开始通过文件名和数据打交道，可以不再关心数据的物理存放位置。因此，这时也有了数据的物理结构和逻辑结构的区别。程序和数据之间有了一定的独立性。
 (3)  文件的形式多样化。由于有了磁盘这样的直接存取存储设备，文件也就不再局限于顺序文件，也有了索引文件、链表文件等。因此，对文件的访问可以是顺序访问，也可以是直接访问；但文件之间是独立的，它们之间的联系要通过程序去构造，文件的共享性也比较差。
 (4)  数据的存取基本上以记录为单位。
尽管文件系统阶段较手工阶段已经有了长足进步，但仍然存在如下缺陷:
 (1)  数据冗余度大。由于文件都是为特定的用途设计的，因此会造成同样的数据在多个文件中重复存储，导致数据冗余度大，容易造成数据的不一致。
 (2)  数据独立性差。应用程序是根据文件结构编写的，文件结构一旦改变，应用程序也必须随之加以修改，程序和数据之间的独立性较差。
 (3)  数据联系弱。文件与文件之间是独立的，文件之间的联系必须通过程序来构造。因此，文件是一个不具有弹性的、无结构的数据集合，不能反映现实世界事物之间的联系。
1.1.1.3 数据库系统阶段
数据库系统阶段是指20世纪60年代后期至今。在这个阶段，计算机主要用于大规模的管理，涉及的数据量急剧增长。这时硬件已有大容量磁盘，价格下降；软件则价格上升，为编制和维护系统软件及应用程序所需的成本相对增加；在处理方式上，联机实时处理要求更多，并开始提出和考虑分布处理。在这种背景下，以文件系统作为数据管理手段已经不能满足应用的需求，于是为解决多用户、多应用共享数据的需求，使数据为尽可能多的应用服务，数据库技术应运而生，出现了统一管理数据的专门软件系统--数据库管理系统。在数据库系统阶段，程序和数据之间的关系如图1-3所示。
图1-3 数据库系统阶段程序与数据的对应关系
数据库是指长期存储在计算机存储设备上、相互关联的、可以被用户共享的数据集合。用数据库系统来管理数据比文件系统具有明显的优点，从文件系统到数据库系统，标志着数据管理技术的飞跃。
数据库系统主要有以下优点。
1. 数据库是相互关联的数据的集合
现实世界的数据信息是相互关联的，用数据库管理数据可以将数据之间的关联关系也体现出来。数据库中的数据不是孤立的，数据与数据之间是相互关联的。在数据库中不仅能表示数据本身，还能表示数据与数据之间的联系。例如，在银行贷款管理中，数据库中不仅要存放银行和法人两类数据，还要存放哪些法人在哪些银行进行贷款的信息，这就反映了银行数据与法人数据之间的联系。
2. 具有较小的数据冗余
在文件系统中，每个应用都拥有各自的文件，即同一数据可能存放在不同的文件中，这带来了大量的数据冗余。在数据库系统中，数据成为统一的逻辑结构，每一个数据项的值可以只存储一次，最大限度地控制了数据冗余。所谓控制数据冗余，是指数据库系统可以把数据冗余限制在最少，系统也可保留必要的数据冗余。事实上，由于应用业务或技术上的原因，如数据合法性检验、数据存取效率等方面的需要，同一数据可能在数据库中保持多个副本。但是在数据库系统中，冗余是受控的。系统知道冗余，保留必须的冗余也是系统预定的。
3. 具有较高的数据独立性
数据独立性是指数据的组织和存储方法与应用程序互不依赖、彼此独立的特性。在数据库技术之前，数据文件的组织方式和应用程序是密切相关的，当改变数据结构时，相应的应用程序也随之修改，从而极大地增加了应用程序的开发代价和维护代价。数据库技术可以使数据的组织和存储方法与应用程序互不依赖，从而大幅降低应用程序的开发代价和维护代价。
4. 具有安全控制机制，能够保证数据的安全、可靠
数据库技术要能够保证数据库中的数据是安全的、可靠的。数据库要有一套安全机制，以便有效地防止数据库中的数据被非法使用或非法修改；数据库还要有一套完整的备份和恢复机制，以便保证当数据遭到破坏时（软件或硬件故障引起的），能够立刻完全恢复数据，从而保证系统能够连续、可靠地运行。
5. 最大限度地保证数据的正确性
保证数据正确的特性在数据库中称为数据完整性。可以在数据库中通过建立一些约束条件来保证数据库中的数据是正确的。例如，北京市电话的区号是010，当输入027-56785436时，数据库能够主动拒绝这类错误。
6. 数据可以共享并能保证数据的一致性
数据库中的数据是共享的，允许多个用户同时使用相同的数据，并能保证各个用户之间对数据的操作不发生矛盾和冲突，即在多个用户同时使用数据库时，能够保证数据的一致性和正确性。
1.1.2 数据库系统的组成
数据库系统（DataBase System, DBS）是指在计算机系统中引入数据库后的系统，一般由数据库、数据库管理系统（DataBase Management System, DBMS）及其开发工具、应用系统、数据库用户和管理员构成。其中，数据库是系统的核心，DBMS及其开发工具和数据库管理员是系统的基础，应用系统和用户是系统服务的对象。在不引起混淆的情况下，数据库系统常常简称为数据库。
数据库系统的组成如图1-4所示。数据库系统在整个计算机系统中的位置如图1-5所示。
图1-4 数据库系统的组成
图1-5 数据库系统在整个计算机系统中的位置
数据库系统对硬件的要求除了一般计算机系统对硬件的要求外，还要求有足够大的内存，以便存放操作系统、DBMS的核心模块、数据缓冲区和应用程序；有容量足够大的磁盘等直接存取设备，以便存放数据和作数据备份；有较高的数据传输速率。
数据库系统的软件主要有DBMS、支持DBMS运行的操作系统、具有与数据库接口的高级程序设计语言及其编译程序、以DBMS为核心的应用开发工具和为特定应用开发的数据库应用系统。
数据库用户和数据管理员是数据库系统的重要组成部分，它们的作用是开发、管理和使用数据库系统。不同人员涉及不同的数据抽象级别，对应不同的数据视图。
1.1.3 数据库管理系统
1.1.1节提到的数据库的各种功能和特性，并不是数据库中的数据固有的，而是靠管理或支持数据库的系统软件--数据库管理系统提供的。一个完备的数据库管理系统应该具备1.1.1节提到的各种功能，它的任务就是对数据资源进行管理，并且使之能为多个用户共享，同时保证数据的安全性、可靠性、完整性、一致性和高度独立性。
具体来说，一个数据库管理系统应该具备如下功能。
 (1)  数据定义功能: 定义数据库的结构和数据库的存储结构、定义数据库中数据之间的联系、定义数据的完整性约束条件等。
 (2)  数据操纵功能: 对数据库中的数据进行查询、插入、删除和修改操作。
 (3)  数据维护功能: 为了提高数据库的性能，可以重新组织数据库的存储结构，为了保证数据库的安全性和可靠性，可以完成数据库的备份和恢复等。
 (4)  数据控制功能: 实现对数据库的安全性控制、完整性控制、多用户环境下的并发控制等各方面的控制。
 (5)  数据通信功能: 在分布式数据库或提供网络操作功能的数据库中还必须提供数据的通信功能。
 (6)  数据服务功能: 数据库不是一个孤立的系统，通常可以被其他软件访问，可以与其他系统交换数据；数据库中的数据也不是简单的操纵和查询，还可以提供很多服务，如数据分析服务等。
1.2 数据模型
数据库中不仅存储数据本身，还要存储数据与数据之间的联系，这种数据及其联系是需要描述和定义的，数据模型正是用于完成这一任务的。
1.2.1 数据模型的概念、分类及构成1.2.1.1 概念图1-6 对现实世界的
抽象过程  模型是对现实世界特征的模拟和抽象，它可以帮助人们描述和了解现实世界。人们可以将现实世界的物质抽象为模型。同时，看到模型，人们就能想象现实世界的物质。数据模型（Data Model）也是一种模型，它是现实世界数据特征的抽象。设计数据库系统时，一般要求用图或表的形式抽象地反映数据彼此之间的关系，这被称为建立数据模型。现有的数据库系统都是基于某种数据模型的。
数据模型应满足三方面要求: 一是能比较真实地模拟现实世界；二是容易为人所理解；三是便于在计算机上实现。
计算机不能直接处理现实世界中的具体事物，所以人们必须把具体事物抽象并转换成计算机能够处理的数据。一般要经过两个阶段: 首先将现实世界中的客观对象抽象为信息世界的概念数据模型；然后将信息世界的概念数据模型转换成机器世界的组织数据模型，如图1-6所示。
1.2.1.2 三个领域
为了能够很好地理解数据模型，下面先介绍现实世界、信息世界和机器世界这三个领域。
1. 现实世界
现实世界是存在于人们头脑外的客观世界。在现实世界中，事物之间不是相互孤立的，而是相互联系的。事物及其之间的联系正是建立数据库的原始数据。现实世界中的原始数据是错综复杂的，数据量是很大的。例如，银行贷款管理、企业人事管理、超市销售管理等。
2. 信息世界
信息世界是现实世界在人脑中的反映，它搜集、整理现实世界的原始数据，找出数据之间的联系和规律，并用形式化方法表示出来，实现人与人之间的信息交流。信息世界最主要的特征是可以反映数据之间的联系。
3. 机器世界
机器世界是数据库的处理对象。信息世界的信息经过加工、编码转换成机器世界的数据，这些数据必须具有自己特定的数据结构，能反映信息世界中数据之间的联系。计算机能对这些数据进行处理，并向用户展示经过处理的数据。
1.2.1.3 数据模型的分类
在数据库系统中，针对不同的使用对象和应用目的，往往采用不同的数据模型。根据数据模型的不同应用目的，可以将这些模型划分为两类，它们分属于两个不同的层次。
第一类模型是概念数据模型。它面向现实世界，从数据的语义视角来抽取模型，按用户的观点对数据和信息建模，强调语义表达能力，建模容易、方便、概念简单、清晰，易于用户所理解，是现实世界到信息世界的第一层抽象，是用户和数据库设计人员之间进行交流的语言。概念数据模型主要用在数据库的设计阶段，与DBMS无关。常用的概念数据模型是实体联系模型。
第二类模型是组织数据模型，也称为数据模型。它是一种基于记录的模型，主要包括网状模型、层次模型、关系模型等。组织数据模型是面向机器世界的，它按照计算机系统的观点对数据建模，从数据的组织层次来描述数据，一般与实际数据库对应。例如，层次模型、网状模型、关系模型分别与层次数据库、网状数据库和关系数据库对应，可以在机器上实现。这类模型有更严格的形式化定义，常需要加上一些限制或规定。组织数据模型是数据库系统的核心和基础，各种机器上实现的DBMS软件都是基于某种组织数据模型的。
设计数据库系统时，通常利用第一类模型作初步设计，之后按一定方法转换为第二类模型，再进一步设计全系统的数据库结构，最终在计算机上实现。
1.2.1.4 数据模型的构成元素
数据模型包括三部分: 数据结构、数据操作和数据的约束条件。
1. 数据结构
数据结构用于描述数据库系统的静态特性，包括数据库中的数据的组成、特性及其相互间联系。在数据库系统中通常按数据结构的类型来命名数据模型，如层次结构、网状结构和关系结构的模型分别被命名为层次模型、网状模型、关系模型。
2. 数据操作
数据操作用于描述数据库系统的动态特性，是对数据库中各种对象的实例允许执行的操作的集合，包括操作及有关的操作规则。数据库的数据操作主要有查询、插入、删除和更新。数据模型要给出这些操作的确切定义、操作符号、操作规则及实现操作的语言。
3. 数据的约束条件
数据的约束条件也用于描述数据库系统的静态特性，是一组数据完整性规则的集合。它给定数据模型中数据及其联系所具有的制约依存规则，用于限定符合数据模型的数据库状态及其变化，以保证数据的完整性。
数据模型的这三方面内容完整描述了一个数据模型，而其中的数据结构是首要内容。
1.2.2 实体联系模型
概念模型主要描述现实世界中实体以及实体和实体之间的联系。P.P.S. Chen于1976年提出的实体-联系（Entity-Relationship, E-R）模型，是支持概念模型的最常用方法。E-R模型使用的工具称为E-R图，它描述的是现实世界的信息结构。
E-R模型主要包含3个要素: 实体、联系和属性。
1.2.2.1 实体
现实世界中所管理的对象称为实体（Entity) 。实体的定义为: 客观存在并可以相互区分的客观事物或抽象事件。例如，职工、学生、银行、桌子都是客观事物，球赛、上课都是抽象事件，它们都是现实世界管理的对象，都是实体。
在关系数据库中，一般一个实体被映射成一个关系表，表中的一行对应一个可区分的现实世界对象，称为实体实例（Entity Instance) 。比如，“银行”实体中的每家银行都是“银行”实体的一个实例。这里所提到的实体在其他书中有用实体集或实体型表示的，这里提到的实体实例在其他书中有用实体实例表示的。
图1-7 实体示例在E-R图中用矩阵框表示实体，在框内写上实体，图1-7分别显示了银行、雇员和球赛三个实体的E-R图表示。
1.2.2.2 属性
实体所具有的某一特性称为属性（Attribute) 。一个实体可以由若干个属性来刻画。例如，雇员可以由雇员号、雇员名、工资和经理号来刻画。人们可以根据实体的特性来区分实体。但并不是每个特性都可以用来区分实体，因此又把用于区分实体的实体特性称为标识属性。例如，雇员的雇员号是标识属性，用雇员号可以区分一个个雇员，而工资就不是标识属性。
在E-R图中用椭圆框表示实体的属性，框内写上属性名，并用连线连到对应实体。可以在标识属性下加下划线。图1-8显示用E-R图表示的雇员实体及其属性。
图1-8 雇员实体及其属性1.2.2.3 联系
在现实世界中，事物内部以及事物之间是有联系的，这些联系在信息世界反映为实体内部的联系和实体之间的联系。实体内部的联系通常是指组成实体的各属性之间的联系。例如，图1-8中雇员实体的属性“雇员号”与“经理号”之间就有关联关系，即经理号的取值受雇员号取值的约束（因为经理也是雇员，也有雇员号），这就是实体内部的联系。实体之间的联系通常是指不同实体之间的联系。例如，在银行贷款管理信息系统中，银行实体和法人实体之间就存在“贷款”联系。我们主要研究的是实体之间的联系。实体之间的联系用菱形框表示，框内写上联系名，然后用连线与相关的实体相连。实体之间的联系按联系方式可分为三类。
 (1)  一对一联系（1∶1) 
如果实体A与实体B之间存在联系，并且对于实体A中的任一个实例，实体B中至多有一个（也可以没有）实例与之关联，反之亦然，则称实体A与实体B具有一对一联系，记作1∶1。例如，飞机的乘客和座位之间、学校与校长之间都是1∶1联系，要注意的是1∶1联系不一定是一一对应，如图1-9所示。联系本身也有属性，图1-9中乘客与座位的联系--“乘坐”的属性为“乘坐时间”. 
图1-9 一对一联系示例
  (2)  一对多联系（1∶n) 
如果实体A与实体B之间存在联系，并且对于实体A中的任一实例，实体B中有n个实例(n≥0)与之对应；而对于实体B中的任一个实例，实体A中至多有一个实例与之对应，则称实体A到实体B的联系是一对多的，记为1∶n。例如，部门和职工之间、学校和学生之间都是1∶n联系，如图1-10所示。
图1-10 一对多联系示例
 (3)  多对多联系（m∶n) 
如果实体A与实体B之间存在联系，并且对于实体A中的任一实例，实体B中有n个实例(n≥0)与之对应；而对实体B中的任一实例，实体A中有m个实例(m≥0)与之对应，则称实体A到实体B的联系是多对多的，记为m∶n。例如，银行和法人之间、商场和顾客之间都是m∶n联系,如图1-11所示。
图1-11 多对多联系示例1.2.3 关系数据模型
关系数据模型就是用关系表示现实世界中实体以及实体之间联系的数据模型。关系数据模型包括关系数据结构、关系数据操作和关系完整性约束三个重要要素。
1.2.3.1 关系模型的数据结构
关系数据结构非常简单，在关系数据模型中，现实世界中的实体及实体之间的联系均用关系来表示。从逻辑或用户的观点来看，关系就是二维表。
关系系统要求让用户感觉数据库就是一张张表。在关系系统中，表是逻辑结构而不是物理结构。实际上，系统在物理层可以使用任何有效的存储结构来存储数据，比如，有序文件、索引、哈希表、指针等。因此，表是对物理存储数据的一种抽象表示--对很多存储细节的抽象，如存储记录的位置、记录的顺序、数据值的表示等以及记录的访问结构，如索引等，对用户来说都是不可见的。
如图1-12所示的两个关系模型分别为银行关系和贷款关系。
图1-12 关系模型的基本术语
用关系表示实体以及实体之间联系的模型称为关系数据模型。下面介绍一些关系数据模型的基本术语。
1. 关系
关系就是二维表，它满足如下条件。
 关系表中的每一列都是不可再分的基本属性。如表1-1所示就不是关系表，因为“电话”列不是基本属性，它包含了子属性“区号”和“号码”. 
 表中各属性不能重名。
 表中的行、列次序并不重要，即可交换列的前后顺序。例如,表1-2就是将图1-12银行关系中的“负责人”列和“电话”列交换顺序，部分行交换顺序后的结果，所以图1-12银行关系和表1-2是完全等价的。表1-1 银行基本信息表（包含复合属性的表）
银行代码银 行 名 称电  话区号号码负 责 人B1100工商银行北京分行0104573张爽 B111A工商银行北京A支行0103489王伟 B111B工商银行北京B支行刘丽丽B2100交通银行北京分行0106829张强 B211A交通银行北京A支行0109045李语 B211B交通银行北京B支行王凡 B3200建设银行上海分行0216739李良维表1-2 银行基本信息表（交换行、列后）
银行代码银 行 名 称负 责 人电  话B2100交通银行北京分行李良维010-6829B211A交通银行北京A支行张强 010-9045B211B交通银行北京B支行李语 B1100工商银行北京分行张爽 010-4573B111A工商银行北京A支行王伟 010-3489B111B工商银行北京B支行刘丽丽B3200建设银行上海分行王凡 021-67392.  元组
表中的每一行数据称为一个元组，它相当于一记录值。如图1-12所示，银行关系包含7个元组，贷款关系包含9个元组。
3.  属性
二维表中的列称为属性；每个属性有一个名称，称为属性名；二维表中对应某一列的值称为属性值；二维表中列的个数称为关系的元数；一个二维表如果有n列，则称为n元关系。如图1-12所示的银行关系有银行代码、银行名称、电话和负责人四个属性，它是一个4元关系；贷款关系有银行代码、法人代码、贷款日期、贷款金额和贷款年限五个属性，它是一个5元关系。
在数据库中，有两套标准术语，一套用的是表、列、行；而相应的另外一套用的则是关系（对应表）、元组（对应行）、属性（对应列）. 
4.  关系模式
二维表的结构称为关系模式，或者说关系模式就是二维表的表框架或结构，它相当于文件结构或记录结构。设关系名为REL，其属性为A1, A2, …, An，则关系模式可以表示为REL (A1, A2, …, An)   对于每个Ai (i=1, …, n) 还包括属性到值域的映像，即属性的取值范围。可以用下划线标识主关键字。如图1-12所示的银行关系模式和贷款关系模式可以分别表示为: 银行（银行代码，银行名称，电话，负责人）
贷款（银行代码，法人代码，贷款日期，贷款金额，贷款年限）5.  候选关键字
如果一个属性集的值能唯一标识一个关系的元组而不含有多余的属性，则称该属性集为候选关键字。简言之，候选关键字是指能唯一标识一个关系的元组的最小属性集。候选关键字又称候选码或候选键。在一个关系上可以有多个候选关键字。
候选关键字可以由一个属性组成，也可以由多个属性共同组成。确定关系的候选关键字与其实际的应用语义有关，与表的设计者的意图有关。
例1-1 已知关系模式: 银行（银行代码，银行名称，负责人），请确定其候选关键字。
由于属性“银行代码”可以唯一标识银行关系中的元组，而此属性又是单属性，显然不包含多余的属性，所以银行关系的候选关键字有1个，即（银行代码）. 
例1-2 已知关系模式: 银行（银行代码，银行名称，电话，负责人），假设每家银行的电话互不相同，请确定其候选关键字。
由于属性“银行代码”可以唯一标识银行关系中的元组，而此属性又是单属性，显然不包含多余的属性，所以“银行代码”是银行关系的候选关键字。
又由于每家银行的电话互不相同，所以属性“电话”也可以唯一标识银行关系中的元组，而此属性也是单属性，显然不包含多余的属性，所以“电话”也是银行关系的候选关键字。
因此，银行关系的候选关键字有2个，即（银行代码）和（电话）. 
例1-3 已知关系模式: 贷款（银行代码，法人代码，贷款日期，贷款金额，贷款年限），请在下列语义环境中确定其候选关键字。
 (1)  假设一个法人只能贷一次款，一家银行可以有多个法人贷款。
该语义环境下，贷款关系的候选关键字有1个，即（法人代码）. 
 (2)  假设一个法人可以在多家银行贷款，一家银行可以有多个法人贷款，但是一个法人只能在一家银行贷款一次。
该语义环境下，贷款关系的候选关键字有1个，它由2个属性构成，即（银行代码，法人代码）. 
 (3）假设一个法人可以在多家银行贷款，一家银行可以有多个法人贷款，一个法人可以在同一家银行贷款多次，但是一个法人同一天只能在同一家银行贷款一次。
该语义环境下，贷款关系的候选关键字有1个，它由3个属性构成，即（银行代码，法人代码，贷款日期）. 
6. 主关键字
有时一个关系中有多个候选关键字，这时可以选择其中一个作为主关键字，简称关键字。主关键字也称为主码或主键。每一个关系都有且仅有一个主关键字。
当一个关系中有一个候选关键字时，则此候选关键字也就是主关键字。例1-3中贷款关系的候选关键字只有1个，所以在不同语义下，贷款关系的主关键字和候选关键字都一样。图1-12 (b）中所标注的主关键字是与例1-3的第（3）种语义环境对应的。
当一个关系中有多个候选关键字时，选择哪一个作为主关键字与实际语义和系统需求相关。在例1-2的银行关系中，由于银行代码通常都会包含银行名称、银行所在地区等编码信息，所以选择候选关键字“银行代码”作为主关键字，而不会选择“电话”作为主关键字。再举一个例子，已知职员关系: 职员（工作证号，姓名，年龄，身份证号），此关系模式有2个候选关键字（工作证号）和（身份证号）。如果此关系模式应用在企业信息管理系统中，选择“工作证号”作为主关键字比较合理，如果此关系模式应用在户籍管理系统中，选择“身份证号”作为主关键字比较合理。
7. 主属性
包含在任一候选关键字中的属性称为主属性。例1-1中的银行关系中的主属性有1个，为“银行代码”。例1-2的银行关系中主属性有2个，为“银行代码”和“电话”. 
8. 非主属性
不包含在任一候选关键字中的属性称为非主属性。例1-1中的银行关系中非主属性有2个，为“银行名称”和“负责人”。例1-2的银行关系中非主属性有2个，为“银行名称”和“负责人”. 
9. 外部关键字
如果一个属性集不是所在关系的关键字，但是是其他关系的关键字，则该属性集称为外部关键字。外部关键字也称为外码或外键。如图1-12所示，贷款关系中的“银行代码”不是贷款关系的主关键字，但是是银行关系的主关键字，则贷款关系中的“银行代码”就是贷款关系中的外部关键字。
外部关键字一般定义在联系中，用于表示两个或多个实体之间的关联关系。外部关键字实际上是表中的一个（或多个）属性，它参照某个其他表（特殊情况下，也可以是外部关键字所在的表）的主关键字，当然，也可以是候选关键字，但多数情况下是主关键字。
外部关键字并不一定要与所参照的主关键字同名。不过，在实际应用中，为了便于识别，当外部关键字与参照的主关键字属于不同关系时，往往给它们取相同的名字。
10. 参照关系和被参照关系
在关系数据库中可以通过外部关键字使两个关系关联，这种联系通常是一对多 (1∶n) 的，其中主（父）关系（1方）称为被参照关系，从（子）关系（n方）称为参照关系。图1-12说明了通过外部关键字关联的两个关系，其中贷款关系通过外部关键字“银行代码”参照了银行关系，所以银行关系为被参照关系，贷款关系为参照关系。
1.2.3.2 关系模型的数据操作
关系模型中的操作可以分为3类，它们是传统的集合运算、专门的关系运算和关系数据操作。实际上，传统的集合运算和专门的关系运算是传统数学意义上的关系运算，而关系数据操作是在关系模型的应用中扩展的一类运算或操作。
关系模型的操作对象是集合，而不是行，也就是操作的对象以及操作的结果都是完整的表（是包含行集的表，而不只是单行，当然，只包含一行数据的表是合法的，空表或不包含任何数据行的表也是合法的）。而非关系型数据库系统中典型的操作则是一次一行或一次一个记录。因此集合处理能力是关系系统区别于其他系统的一个重要特征。
传统的集合运算包括并、交、差和广义笛卡儿积运算。专门的关系运算包括选择、投影、连接和除运算。关系数据操作主要包括查询、插入、删除和更新数据。在数据库应用中，查询表达能力是最重要的，它意味着数据库能否以便捷的方式为用户提供丰富的信息，而关系操作集恰恰提供了丰富的查询表达能力，读者可以在第6章（数据查询与数据操作）中进行体验。
现在关系数据库已经有了标准语言--SQL (Structured Query Language) ，它是一种介于关系代数和关系演算的语言。SQL尽管字面上是结构化查询语言，但是它不仅具有丰富的查询功能，而且具有数据操作、数据定义和数据控制等功能，是集查询语言、数据定义语言、数据操作语言和数据控制语言于一体的关系数据语言，充分体现了关系数据语言的特点和优点。
1.2.3.3 关系模型的数据完整性约束
关系模型的完整性规则是对关系的某种约束条件。关系模型中可以有三类完整性约束: 实体完整性、参照完整性和用户定义的完整性。其中，实体完整性和参照完整性是关系模型必须满足的完整性约束条件，被称为关系的两个不变性，应该由关系系统自动支持。
1. 实体完整性规则
实体完整性的目的是保证关系中的每个元组都是可识别和唯一的。
实体完整性规则的具体内容是: 若属性A是基本关系R的主属性，则属性A不能取空值。
所谓空值就是“不知道”或“没有确定”，它既不是数值0，也不是空字符串，而是一个未知的量。
实体完整性规则规定了关系的所有主属性都不可以取空值，而不仅是主关键字整体不能取空值。例如，例1-3 (3）的贷款关系: 贷款（银行代码，法人代码，贷款日期，贷款金额，贷款期限）中，（银行代码，法人代码，贷款日期）为主关键字，则实体完整性要求“银行代码”、“法人代码”和“贷款日期”三个属性都不能取空值。
关系数据库管理系统可以用主关键字实现实体完整性（非主关键字的属性也可以说明为唯一和非空值的）。说明了主关键字之后，关系系统可以自动支持关系的实体完整性。
2. 参照完整性规则
现实世界中的实体之间存在某种联系，而在关系模型中实体是用关系描述的，实体之间的联系也是用关系描述的，这样就自然存在关系和关系之间的参照或引用。先来看几个例子。
例1-4 银行实体和城市实体可以用下面的关系表示，其中主关键字用下划线标识: 
银行（银行代码，银行名称，电话，城市代码）
城市（城市代码，城市名称）
在银行关系和城市关系之间，银行关系是被参照关系，城市关系是参照关系，银行关系中的“城市代码”是外部关键字。这两个关系之间存在属性的参照，即银行关系参照了城市关系的主关键字“城市代码”。显然，银行关系中的“城市代码”的取值必须是确实存在的城市的城市代码，即城市关系中有该城市的记录。也就是说，银行关系中的某个属性的取值需要参考城市关系的属性取值。
例1-5 银行、法人、银行与法人之间的贷款联系（多对多联系）可以用如下三个关系表示，其中主关键字用下划线标识: 
银行（银行代码，银行名称，电话）
法人（法人代码，法人名称，经济性质，注册资金）
贷款（银行代码，法人代码，贷款日期，贷款金额，贷款期限）
在这三个关系之间，银行关系和法人关系是被参照关系，贷款关系是参照关系，贷款关系中有两个外部关键字，分别是“银行代码”和“法人代码”。也就是说，贷款关系参照了银行关系的主关键字“银行代码”，又参照了法人关系的主关键字“法人代码”。显然，贷款关系中的“银行代码”的取值必须是确实存在的银行的银行代码，即银行关系中有该银行的记录；贷款关系中的“法人代码”的取值必须是确实存在的法人的法人代码，即法人关系中有该法人的记录。也就是说，贷款关系中的某些属性的取值需要参考银行关系和法人关系。
参照完整性规则定义了外部关键字与主关键字之间的参照规则。参照完整性规则的内容是: 如果属性（或属性组）F是关系R的外部关键字，它与关系S的主关键字K相对应，则对于关系R中每个元组在属性（或属性组）F上的值必须为
 或者取空值（F的每个属性均为空值）; 
 或者等于S中某个元组的主关键字的值。
例1-4的银行和城市的关系之间的参照问题说明: 如果银行关系中某个元组的城市编号为空值，则意味着该银行所在城市尚未确定；如果是非空值，则一定是城市关系中某一已经存在的元组的主关键字，说明该银行在此城市中。
思考: 例1-5的贷款关系中的两个外部关键字“银行代码”和“法人代码”能否取空值？
在关系系统中通过说明外部关键字来实现参照完整性，而说明外部关键字是通过说明参照的主关键字实现的。说明了外部关键字之后，关系系统可以自动支持关系的参照完整性。
3. 用户定义的完整性规则
实体完整性和参照完整性是关系数据模型必须满足的，或者说是关系数据模型固有的特性。除此之外，还有其他与应用密切相关的数据完整性约束，例如，年龄的取值范围为0~150，身份证的取值必须唯一，北京市的电话号码前三位（区号）必须是010等。类似这些方面的约束不是关系数据模型本身所要求的，而是为了满足应用方面的语义要求提出来的，这些完整性需求需要用户来定义，所以又称为用户定义完整性。数据库管理系统需提供定义这些数据完整性的功能和手段，以便统一进行处理和检查，而不是由应用程序实现这些功能。
1.2.4 实体联系模型向关系模型的转换
前面两节分别介绍了实体联系模型和关系模型，如何将实体联系模型转换成关系模式、如何确定这些关系模式的属性和主关键字，是本节要讨论的问题。
关系模型的逻辑结构是一组关系模式的集合。实体联系模型则由实体、实体的属性和实体之间的联系三个要素组成。因此，将实体联系模型转换为关系模型实际上就是要将实体、实体的属性和实体之间的联系转换为关系模式。这种转换一般遵循如下原则:
 对于E-R图中的每个实体都应转换为一个关系模式。实体的属性就是关系模式的属性，实体的标识属性就是关系模式的主关键字。
 对于E-R图中的联系，需要根据实体联系方式的不同，采取不同的手段加以实现。其中，表1-3列出了二元联系的常用处理方法。需要说明的是，在1∶1联系和1∶n联系中，联系也可以单独转换成一个关系模式，但由于这种转换的结果会增加表的张数，导致查询效率降低，所以不推荐使用，这里就不再详细介绍这种转换方式。表1-3 二元联系的常用处理方法
二元
联系E-R图转换成的
关系模式联系的处理主 关 键 字外部关键字1∶1 关系模式A关系模式B把关系模式B的主关键字和联系的属性加入关系模式A中；或把关系模式A的主关键字和联系的属性加入关系模式B中。实体A的标识属性是关系模式A的主关键字；实体B的标识属性是关系模式B的主关键字。关系模式B的主关键字是关系模式A中参照关系模式B的外部关键字；或关系模式A的主关键字是关系模式B中参照关系模式A的外部关键字。1∶n关系模式A关系模式B把关系模式A (1端）的主关键字，联系的属性加入关系模式B (n端）中。实体A的标识属性是关系模式A的主关键字；实体B的标识属性是关系模式B的主关键字。关系模式A的主关键字是关系模式B中参照关系模式A中的外部关键字。m∶n关系模式A关系模式B关系模式A-B联系单独转换成一个关系模式A-B，模式A-B的属性包括关系模式A的主关键字、关系模式B的主关键字和联系的属性。实体A的标识属性是关系模式A的主关键字；实体B的标识属性是关系模式B的主关键字；关系模式A-B的主关键字包括实体A的标识属性和实体B的标识属性，根据实际语义，关系模式A-B的主关键字还可以包括联系的部分属性。关系模式A的主关键字是关系模式A-B中参照关系模式A中的外部关键字；关系模式B的主关键字是关系模式A-B中参照关系模式B中的外部关键字。  对于其他情况，应遵循如下原则: 
 三个或三个以上实体间的一个多元联系可以转换为一个关系模式。与该多元联系相连的各实体的标识属性以及联系本身的属性均转换为关系模式的属性。而关系模式的主关键字为各实体的标识属性的组合，同时新关系模式中的各实体的标识属性为参照各实体对应关系模式的外部关键字。
 合并具有相同关键字的关系模式。为了减少系统中的关系模式个数，如果两个关系模式具有相同的关键字，可以考虑将它们合并为一个关系模式。合并方法是将其中一个关系模式的全部属性加入另一个关系模式中，然后去掉其中的同义属性，并适当调整属性的次序。
 同一实体集的实体间的联系，即自联系，也可按上述1∶1、1∶n和m∶n三种情况分别处理。
例1-6 将如图1-13所示的实体联系模型转换成关系模式。
针对1∶1联系，联系的转换方式通常有两种。
方法1: 将实体“行长”的主关键字和联系“负责”合并到实体“银行”对应的关系模式中，则转换后的结果为两个关系模式:
银行表（银行代码，银行名称，电话，行长代码）
行长表（行长代码，行长姓名）
其中，银行表的主关键字是“银行代码”，外部关键字是“行长代码”（即“行长代码”是参照了关系模式行长表中的“行长代码”的外部关键字）；行长表的主关键字是“行长代码”，无外部关键字。
方法2: 将实体“银行”的主关键字和联系“负责”合并到实体“行长”对应的关系模式中，则转换后的结果为两个关系模式: 
银行表（银行代码，银行名称，电话）
行长表（行长代码，行长姓名，银行代码）
其中，银行表的主关键字是“银行代码”，无外部关键字；行长表的主关键字是“行长代码”，外部关键字是“银行代码”（即“银行代码”是参照了关系模式银行表中的“银行代码”的外部关键字）. 
例1-7 将如图1-14所示的实体联系模型转换成关系模式。
图1-13 1∶1联系
图1-14 1∶n联系
针对1∶n联系，需要将1端实体“银行”和联系“工作”合并到n端实体“职员”对应的关系模式中，转换后的结果为两个关系模式: 
银行表（银行代码，银行名称，电话）
职员表（职员代码，职员姓名，所在部门，银行代码）
其中，银行表的主关键字是“银行代码”，无外部关键字；职员表的主关键字是“职员代码”，外部关键字是“银行代码”（即“银行代码”是参照了关系模式银行表中的“银行代码”的外部关键字）. 
例1-8 将如图1-15所示的实体联系模型转换成关系模式。已知: 一个法人可以在多家银行贷款，一家银行可以有多个法人贷款，一个法人可以在同一家银行贷多次款，但一个法人一天在同一家银行只能贷一次款。
图1-15 m∶n联系
针对m∶n联系，需要将联系“贷款”转换为一张独立的关系模式。转换后的结果为三个关系模式: 
银行表（银行代码，银行名称，电话）
法人表（法人代码，法人姓名，经济性质，注册资金，法定代表人）
贷款表（银行代码，法人代码，贷款日期，贷款金额，贷款期限）
其中，银行表的主关键字是“银行代码”，无外部关键字；法人表的主关键字是“法人代码”，无外部关键字。由于，一个法人一天在同一家银行只能贷一次款，所以贷款表的主关键字不仅包括“银行”实体和“法人”实体的标识属性，还包括“贷款”联系的属性“贷款日期”，即贷款表的主关键字是（银行代码，法人代码，贷款日期）。贷款表的外部关键字有2个，分别是银行代码和法人代码（即“银行代码”是参照了关系模式银行表中的“银行代码”的外部关键字，“法人代码”是参照了法人表中“法人代码”的外部关键字）. 
1.3 关系数据理论
关系数据库设计是数据库应用开发的关键步骤。一个设计不完善的关系模式会带来诸如数据冗余、更新异常等问题，需要对这样的关系模式进行规范化。
数据库设计是我们研究和应用数据库的重点。数据库设计的任务是在给定的具体环境下，解决以下问题: 
 如何构造适当的关系模型;
 构造几个关系模式;
 如何组织它们;
 每个关系模式应包括哪些属性。
这些问题直接关系到整个数据库系统的运行效率，是数据库系统优劣的关键。关系数据库设计理论是设计关系数据库的指南，是关系数据库的理论基础。
1.3.1 问题的提出
设计任何一种数据库系统都会遇到如何构造合适的数据模式的问题。由于关系模式有严格的数学理论基础，并且可以方便地向其他数据模型转换，因此，人们多以关系模型为背景讨论这个问题，并由此形成了数据库设计的一个著名理论框架--关系数据库的规范化理论。规范化理论虽然是基于关系模型提出的，但是它对于一般的数据库设计同样具有理论上的指导意义。
在讨论规范化理论之前，首先看看什么是“不好”的数据库设计，我们通过下面的例子来说明这个问题: 已知贷款A关系（法人代码，法人名称，经济性质，银行代码，银行名称，贷款日期，贷款金额），假设一个法人可以在多家银行贷款，一家银行可以为多个法人贷款，同一法人在同一家银行一天只能贷款一次。则贷款A关系的主关键字为: （法人代码，银行代码，贷款日期）
下面从表1-4的数据分析这样的关系模式在实际应用中可能出现的问题: 表1-4 贷款A关系实例
法人代码法 人 名 称经济性质银行代码贷款日期贷款金额/万元E01塞纳网络有限公司私营B11002008-8-2010E01塞纳网络有限公司私营B111A2005-4-115E01塞纳网络有限公司私营B21002009-3-28E02华顺达水泥股份有限公司国营B111A2007-8-201000E03新意企业策划中心私营B32002008-6-430E03新意企业策划中心私营B321A2009-3-220   (1)  数据冗余问题。在这个关系中，对应同一个法人代码，其法人名称和经济性质都是相同的。一个法人可以在多家银行进行多次贷款，每贷一次款，其法人信息（例如，法人名称和经济性质）就要存储一遍，很显然法人信息有重复存储。重复存储或数据冗余不仅会浪费存储空间，更重要的是可能会引起数据更新、数据插入、数据删除问题。