《信息系统分析与设计》课件1第9章

9.1数据库技术与信息系统9.2数据库系统概述9.3数据库设计9.4关系型数据库及SQL语言简介9.5数据库技术的新发展9.6MIS中DBMS用户选择方案思考与练习题第9章数据库技术

9.1数据库技术与信息系统

管理信息系统使用计算机技术管理数据并为管理提供决策支持，使管理人员更有效率地工作。迅速发展的计算机技术，包括数据库管理系统(DBMS)是推动管理信息系统领域前进的动力和基础。

开发管理信息系统最根本的问题有两个：一是对数量庞大的数据的组织与管理；二是对数据的“加工”，这两个问题贯串于系统开发的整个过程。数据库是数据组织与管理的最新技术，是计算机软件的一个重要分支。由于数据库具有结构化程度高、数据冗余度低、数据的独立性高以及易于扩充、编程工作量小等特点，因而获得了广泛的应用。目前，管理信息系统几乎都是建立在数据库系统的基础上的，因此，数据库是管理信息系统的基础和核心，数据库设计是系统开发的重要组成部分。

一个大的企业管理、MIS和DBMS的层次关系可用图9-1表示。图9-1企业的管理、MIS和DBMS的层次关系

9.2数据库系统概述

9.2.1数据库及其特征

数据库是以一定的方式组织、存储起来的相关数据的集合，它具有最小的数据冗余度和较高的数据独立性，可供多种应用(用户或应用程序)服务。

数据库具有以下特点：

(1)数据是结构化的。结构化是数据库系统管理的基础，不同的数据库系统，数据结构是不同的，但同一系统的结构是固定的，如关系型系统的基本结构是二维表。

(2)数据的组织面向系统。数据库用整体的观点，从系统的全部应用出发，来组织系统的全部数据，因此数据的组织是面向系统的，这样，可大大降低数据的冗余度，节省存储空间，减少数据输入与维护的工作量，保证数据的一致性。

(3)数据的独立性高。采用数据库后，数据和应用程序之间彼此依赖的程度低，即应用程序不依赖于数据的组织和物理存储方式，数据的结构需要修改时，也不必修改相应的应用程序，因而数据具有较高的独立性。

(4)数据的共享性高。由于整个数据是结构化的，而且数据的组织是面向系统的全体用户、全部应用的，因此可以最大程度地满足多个用户、多种应用对数据共享的要求。

(5)具有对数据的安全性、完整性和并发操作的控制功能。数据的安全性是指保证数据库中数据的安全，防止对数据的不合法使用；完整性包括数据的正确性、有效性和相容性；并发控制是指在多个用户同时存取同一数据的情况下应采取的控制措施。

(6)对数据进行管理、操作的功能强。有一组专门的软件，即数据库管理系统软件负责对数据进行统一管理和操作。9.2.2数据模型

数据库把相关数据的集合以综合的方法进行组织，使用户能有效地处理数据。数据的结构和表示以及其性质和特征相当复杂，需要有形式化的方法来描述数据的逻辑结构和各种操作，于是产生了数据模型的概念。

数据模型是对客观事物及其联系的数据描述，即实体模型的数据化，是指数据在数据库中排列、组织所遵循的规则，以及对数据所能进行操作的总体。简单地说，数据模型是表示实体及实体之间联系的模型。具体地说，数据库数据结构、数据库操作集合和完整性规则集合组成数据库的数据模型。数据模型可分为三类：

(1)面向记录的传统数据模型。

(2)注重描述数据及其之间语义的语义数据模型。

(3)面向对象数据模型。

1．传统数据模型

传统数据模型早在20世纪六、七十年代就发展起来了，主要有网络、层次和关系三种数据模型。

1)层次数据模型

层次模型(HierarchicalModel)是一种树结构，它有如下几个特点：

(1)有且仅有一个结点，向上不与任何结点联系，这个结点即为树的根，称为根结点。

(2)其他结点向下可以与若干结点联系，但向上只与唯一的一个结点联系。

凡满足上面两个条件的数据模型称为层次数据模型。例如，图9-2所示就是一个层次模型。图9-2层次数据模型

2)网络数据模型

网络模型(NetworkModel)是一种网络结构，数据间紧密相连，呈现出一种网络状的关系形式。它的特征是：

(1)至少有一个以上的结点无父结点。

(2)至少有一个结点有多于一个父结点。

(3)任何两个结点之间可以有两种以上的联系。

例如，图9-3所示的数据模型是网络数据模型。

网络数据模型与层次数据模型的主要区别在于：层次数据模型中，从子结点到父结点的联系是唯一的，而在网络数据模型中，从子结点到父结点的联系不是唯一的。图9-3网络数据模型

3)关系数据模型

关系模型(RelationModel)是以数学理论为基础而构造的数据模型，它把数据看成是一张二维表，这个表就称为关系。表9-1所列的职工情况就是一个关系。

一般来说具有如下性质的一张二维表才能称为一个关系：

(1)每一列中的数据属于同一类型。

(2)各列必须有不同的名字。

(3)表中行和列的顺序可以任意。

(4)表中各行相异，不允许有重复的行。

(5)表中的数据项是不可再分的最小数据项。关系模型以集合论和一阶逻辑为数学基础，最终却以二维表形式把数据的简单视图提供给用户。在关系模型中，数据以关系的形式组织，每个数据库可划分成多个关系，每个关系由关系模式定义，数据库的全部关系模式的集合称为数据库模式。关系模型由关系、关系上定义的操作和对关系的完整性规则组成。由于关系模型具有结构简单灵活，数据独立性高、理论严格、描述一致等优点，因此得到了广泛的流行，目前普遍使用的DBMS软件几乎都是关系型数据库管理系统。关系模型为处理字符、文本等结构化数据提供了简单的形式化手段，但缺乏处理复杂数据的能力。

2．语义数据模型

语义数据模型发展的最初动力是克服传统数据模型的缺陷，提供不受具体的实现结构限制、更多地面向用户的模型。语义模型提供一种“自然”的机制来说明数据库的设计，同时更准确地表示数据及数据间关系。语义数据模型提供了强有力的抽象构造机制，如概括(Generalization)和聚合(Aggregation)。概括允许设计者将相似对象形成组，集中到一个更普及的组对象上，如从GRADUATESTUDENT和UNGRADUATESTUDENT中可得到组对象STUDENT。聚合允许设计者从对象的性质或属性中模型化出抽象实体，抽象实体中可包括异质部件，如一个聚合对象ADRESS由STREET、CITY、STATE和ZIPCODE组成。除概括和聚合外，还有联合(Association)和分类(Classification)等。除抽象构造外，语义数据模型的另一重要特点是支持“派生数据”的概念。派生数据是指并不实际存于库中的、需要时可由库中数据及其之间的关系派生出来的数据。

语义数据模型主要包括：E-R模型、RM/T模型、TAXIS模型、SDM模型、函数模型、SAM模型以及SHM+模型等。

3．面向对象的数据模型

面向对象的概念起源于程序设计语言。对象是客观世界实体的抽象描述，由信息(数据)和对数据的操作组合而成；类是对多个相似对象共同特性的描述；消息是对象之间通信的手段，用来表示对象的操作；方法是对象接收到消息后应采取的动作序列的描述；实例是由一特定类描述的具体对象。对象具有封装特性，对外部只提供一个抽象接口而隐藏具体实现细节；类具有继承的特性。另外，面向对象数据模型还吸收了语义数据模型中概括和聚合的概念，以及传统数据库管理中持久性、二级存储管理、并发、数据恢复和查询语言的概念，这样就形成了新的面向对象的数据模型，如图9-4所示。图9-4面向对象的数据模型面向对象数据模型提供了表示复杂对象的能力。可在任意层次上嵌套各种类型构造符(数组、表、元组等)，同时可表示数据之间的各种特殊关系。

由以上分析可以看出，传统数据模型适于处理大量相似的简单数据，不适合处理复杂数据；语义数据模型试图从数据的内容和关系中获取更多的意义来增强对可操作消息的表示；面向对象模型充分吸收了面向对象技术及前两种数据模型的优点，被认为是描述多媒体信息的较理想的数据模型。9.2.3数据库系统的组成

数据库系统与图书馆系统十分相似。图书馆系统由书库、图书馆管理系统、图书馆管理员及用户组成。书库是有组织的图书的集合；图书馆管理系统十分复杂，简单地说，它包含管理图书馆的一套规则和工具以及借还图书的一套规则和工具；管理人员按规则维护书库；读者按规则查找、借还图书。

狭义地讲，数据库系统由数据库、数据库管理系统以及用户组成。

1．数据库

数据库是存储在计算机系统内的有结构的数据集合。通俗地讲，这些数据是被数据库管理系统按一定的组织形式存放在各个数据库文件中的。也就是说，数据库是由很多数据库文件以及若干辅助操作文件组成的。存放在数据库中的数据可以被所有合法用户使用。

2．数据库管理系统

数据库管理系统是数据库系统中对数据进行管理的软件，它是在操作系统支持下进行工作的。该软件十分庞大复杂，通俗地讲，它是为用户管理数据所提供的一整套命令。利用这些命令，用户可以建立数据库文件及各种辅助操作文件，可以定义数据，并对数据进行各种操作，如增删、更新、查找、统计、输出等。总之，一切操作都是通过数据库管理系统进行的。

3．用户

用户利用数据库管理系统提供的命令访问数据库，进行各种操作。

广义地说，数据库系统是由计算机硬件、操作系统、数据库管理系统以及在它支持下建立起来的数据库、应用程序、用户和维护人员组成的一个整体。

9.3数 据 库 设 计

9.3.1数据库设计过程

数据库是数据库应用系统的重要组成部分。一个单位(企、事业)的MIS系统绝大多数是由在DBMS支持下建立的数据库构成的。数据库的设计、建立是在MIS建立过程中完成的，所以数据库的设计过程要密切结合整个MIS的开发过程。根据用户需求研制一个数据库结构的过程称为数据库设计。数据库设计的过程可以归纳如下：

(1)调查用户需求，特别是对数据及处理的要求及描述。

(2)设计数据库的概念模型。

(3)数据库的逻辑设计、优化设计。

(4)数据库的物理设计。

(5)物理数据库的建立、试运行、评价。

(6)数据库的使用与维护。

数据库设计过程可分为若干阶段或若干步骤，如图9-5所示。图9-5数据库设计步骤在数据库设计过程中，需求分析与数据分析是整个设计过程中最困难的一步，也是最重要的一步，它的主要任务是从所有数据库用户那里收集信息内容和处理要求。需求分析既要保证企业组织的信息流观点的一致性，同时，也要保证用户目标的一致性。概念设计是通过对用户信息需求的综合归纳，形成一个不依赖于DBMS的信息结构的设计，概念设计结果得到的是数据库概念结构或称概念模型。逻辑设计得到的数据库结构是DBMS可以处理的数据模型，通常用数据定义语言表示，我们把它称为数据库逻辑结构。逻辑设计与概念设计不同，概念设计仅仅是对客观世界的描述，与实现无关，而逻辑设计却与实现有关，依赖于实现的基础DBMS。物理设计是选择物理数据库结构，得到一个完整的、可实现的数据库结构。

下面我们将详细讨论数据库设计中的重要步骤。9.3.2用户需求分析

为了设计出满足要求的数据库，必须先进行用户要求调查、描述与分析，这是数据库设计过程的第一步，是基础工作。从数据库的设计目标讲，要满足用户的数据要求和数据处理要求，就必须向用户调查，并对用户要求进行描述与分析。对开发设计人员来说，事先并不知道用户的这些要求，即要开发的MIS应“做什么”，它是由用户提供的，开发设计人员应该全面、细致地了解这些，这是由用户的现实世界进入计算机世界的必经之路。而且，由于数据库是用数据模型来模拟现实世界的信息类型和信息间的联系的，因此，为了更好地模拟现实世界，必须全面地了解用户的要求，同时还要熟悉MIS系统的工作环境(OS、DBMS和硬件资源等)。

数据库设计的另一个目标是数据库有好的性能，主要的是存取操作的效率高。为达到此目标也必须全面了解用户的要求，并且很好地结合MIS系统的工作环境，设计好数据库，同时还要开发好应用系统。

1．用户要求描述与分析的内容

对用户要求的了解是多方面的，通过与用户单位各层次的领导和业务管理人员交谈，可以了解、收集用户单位各部门的组织机构，各部门的职责、业务联系、业务流程，各部门和各种业务活动和业务管理人员对数据的需求以及对数据处理的要求等。这一阶段的工作量大，很繁琐，开发人员应和业务人员互相沟通，最后写出用户要求说明书。对用户要求的描述与分析可采用结构分析方法自上而下逐层地描述与分析。可以画出用户单位的组织机构图、业务流程图、数据流程图(DFD图)。在DFD图中表示出数据流、数据存储要求、处理的逻辑表示、对数据的立即存取要求等。然后再详细地分析与表示数据流、数据存储结构、对数据的立即存取要求，列出数据项，表示出数据项间关系，编制数据字典，说明对数据项和数据项关系的操作。对数据库设计来说，数据字典着重描述数据以及对数据的操作。

2．用户要求描述与分析的例子

1)业务流程图

参看第7章。

2)数据流程图(DFD)

对一个单位来说，可以自上而下逐层地画出数据流程图(DFD)。图9-6所示是某单位人事管理的数据流程图。图9-6某单位人事管理的数据流程图

3)数据流

数据流是在系统内沿一定路径传输的数据，它可以是简单的数据，也可以是有结构的复杂数据。比如在人事管理DFD(图9-6)中，可以有五个数据流流入“职工档案”这个数据存储中，它们的数据结构分别如下：

新职工(1-D1)，包括职工号、姓名、性别、民族、出生日期、住址、文化程度、工资、职称、部门及历史情况等。

调离通知(2-D1)，包括职工号、姓名等。

住址变动(2-D1)，包括职工号、姓名、新住址等。

职称变动(2-D1)，包括职工号、姓名、新职称等。

工资变动(2-D1)，包括职工号、姓名、新工资、新工资起始日期等。从“职工档案”中流出的数据流可以有两个：

工资情况(D1-3)，包括职工号、姓名、工资等。

职工历史(D1-4)，包括职工号、姓名、现在文化程度、参加工作日期、工作单位变动历史、职称变动历史、工资变动历史等。

4)数据存储

图9-6中的数据存储为职工档案，其编号为D1。在具体问题中，数据存储可能有多个，可以编不同的号码以示区别。数据存储可以有复杂的数据结构，比如职工档案的数据结构可以比新职工的结构还复杂，或者取相同结构。

5)数据项间的联系

比如在职工号、姓名、工资、承担的项目代号、项目完成日期、项目负责人等数据项间是有联系的，应该把数据项间的联系也表示出来。

6)对数据操作的要求

比如每天早上一上班，就要知道公司前一天的销售情况，每到月底就要编制生产统计报表、财务报表、工资报表、原材料消耗报表等，这些都是定期的，是可以调查清楚的。

这些数据存取要求是可以预先估计的。

对数据的更新频率也要查清，对有的系统(如旅馆客房管理，飞机订票系统)，数据要求是最新的，应该实时处理。但有的公司要求早上9:00能提供前一天的生产情况就可以了，对当日早上8:00～9:00的变化可不考虑。销售部门对订货单统计时，每天上午8:00～9:00约有50份，平均100份/天，等等，诸如此类的操作要求都要调查清楚。

7)数据字典

对MIS开发来说，在调研与分析阶段建立的数据字典内容很丰富。数据库设计只是侧重在数据方面，因为设计数据库编写数据字典只是一部分内容，要产生数据的完全定义，可以利用DBMS中的数据字典工具。数据字典是MIS中所出现的数据项的大全，数据项的名称、别名、类型、取值等，在哪个数据流、数据存储、处理逻辑中使用，使用频率都应记录进去。9.3.3数据库概念设计

1．数据概念模型

数据概念模型是对现实世界的一次抽象与模拟，是在用户要求描述与分析的基础上进行的，是以用户能理解的形式表示信息。数据概念模型独立于数据库逻辑结构，也独立于具体的计算机系统和DBMS，可以转换到任何计算机系统和DBMS系统。

实体—联系模型也称E-R模型(Entity-RelationshipModel)，或称E-R方法，是P.S.Chen于1976年提出的，是常用的数据概念模型，在描述现实世界和数据库设计中广泛应用，是一种语义模型。

E-R模型用到实体、属性、联系等概念，它与前面提到的三种数据模型(层次、网状、关系)不同，E-R模型只描述客观世界，不涉及实现，不依赖DBMS。因此，可用E-R模型作为描述现实世界的工具，在此基础上转换为数据模型。

1)实体与属性

实体(Entity)是单位中所关心的客体(事物)，是信息管理的对象，如单位、职工、项目、学生、教师等。

属性(Attributes)是实体(客体)的特征，如职工的编号、姓名、年龄等。一个实体总是通过其属性来描述的。

实体与属性的关系可用图直观地表示，在图中，实体用方框表示，属性用椭圆表示。例如，职工这一实体和它的属性的表示如图9-7所示。图9-7实体与属性的图形表示

2)实体间联系

因为现实世界中客体是彼此联系的，所以在信息世界中实体间是有联系的。比如，职工和单位两个实体之间有联系，职工在单位中工作，属于该单位；而单位又必定有职工。可用菱形表示两实体间的联系。

实体间的联系有三种：1:1、1:m和m:n。

如单位和领导者两实体间的联系是1:1型的；单位与职工间的联系是1:m型的；职工和承担的项目间的联系是m:n型的，即一个职工可以承担多个项目，而一个项目可有多个职工参加，如图9-8所示。图9-8实体间的联系

3) E-R图

使用E-R方法的核心是划分实体和属性，并确定实体间的联系。例如，职工与单位的E-R图如图9-9所示。在E-R图中，有实体及其属性，并且实体间可有联系，联系用菱形表示。在一个E-R图中可有多个实体，它们之间有联系，比如，工程项目(PROJ)、零件(PART)与供应商(SUPP)之间是多对多的联系，某供应商向若干工程项目供应若干零件，而每个工程项目所用的每种零件可由不同的供应商提供，每种零件可由若干供应商提供。它们之间的E-R图用图9-10表示。图9-9职工与单位的E-R图图9-10多个实体间联系的E-R图在实际应用中，使用E-R方法的步骤是：

(1)确定实体类型。

(2)确定联系类型。

(3)画出表示一个单位的E-R图模式。

(4)确定属性。

(5)将E-R图优化。

(6)将E-R图转化为DBMS可接受的数据模型，即三大数据模型之一。

2．数据库概念设计

数据库概念设计就是使用数据概念模型来描述用户的数据处理现实世界。在用户需求调研和系统分析基础上，用E-R模型画出E-R图，然后分析消除冗余的数据和冗余的联系，给出函数依赖表达式。用E-R图进行数据库概念设计时应注意以下事项：

(1)区分实体与属性。在系统分析阶段所收集的数据中，哪些作为实体，哪些作为实体的属性，这没有严格的界限，常常按自然情况进行划分，然后再进行调整。一般来说，作为属性的事物不能再有需要描述的性质或与其他事物有联系。假若某事物因为处理的需要，要与其他事物发生联系，那么就应该将该事物作为实体来处理。例如，工种可以作为职工的属性，但发放劳保用品与工种有关，就可以把工种作为实体，劳保用品也作为实体。因为职工与工种，工种与劳保用品之间有联系。

(2)在画E-R图时，先画局部的E-R图，然后将各部分图汇总，形成总的E-R图。

(3)对E-R图进行综合分析，去掉冗余的数据。

(4)去掉冗余的联系。这是比较复杂的，首先把图中的实体符号化，然后对每一个联系都形成一个函数依赖表达式，表达式的左部为与该联系有关的实体，右部为描述该联系性质的属性，若无属性则记为空。可以用求函数依赖集的最小覆盖算法进行极小化处理，求出最小覆盖，以后的工作可在数据库逻辑设计阶段进行。9.3.4数据库逻辑设计

概念设计是独立于DBMS的，而逻辑设计与DBMS有关，受到所支持的数据模型的约束。

1．逻辑设计的过程

数据库的逻辑设计是在数据库概念设计基础上进行的，主要是把概念结构转换为某个DBMS所支持的数据模型上的结构表示，我们把它称为逻辑模式。数据库逻辑设计过程可用图9-11表示。图9-11数据库逻辑设计过程

2．E-R图向数据模型的转换

逻辑设计过程就是把概念结构转换为逻辑结构的过程。现在，我们是用E-R图来表示概念结构的，而逻辑结构在不同的DBMS中的表示形式不同，因此，所谓转换工作，就是把表示概念结构的E-R图转换为层次模型的逻辑结构，或网状模型的逻辑结构，或关系模型的逻辑结构。这三种转换工作可以按一定规则进行，得到相应的逻辑结构，然后再针对具体DBMS作适当的修改。这里主要介绍向关系数据模型的转换。

关系模型的逻辑结构为一组关系模式，因而从概念结构到关系模型逻辑结构的转换，就是从E-R图转换为关系模式。实体和属性的转换比较容易，一个实体对应一个关系模式，实体的属性就是关系的属性。下面着重讨论联系的转换。

1)两个实体型之间联系的转换

◆ 1:n联系的情况

例如，教研室与教员之间存在着1:n联系，转换时，只要在“教员”关系中增加一个(组)属性项就能反映1:n联系，该属性项是“教研室”关系的码属性，如，教研室号。这样，“教员”关系模式可表示为：

教员(教员号，教研室号，姓名，性别，年龄，…)◆ 1:1联系的情况

例如，“车间主任”与“车间”存在着1:1联系，转换时，只要在“车间主任”的关系中增加“车间”关系的码作为属性项；而在“车间”的关系中增加“车间主任”关系的码作为属性项即可。这样，这两个关系模式可以有如下形式：

车间主任(车间主任号，车间号，车间主任名，…)

车间(车间号，车间主任号，车间名，…)当然，可以有另外的转换方法：即只在一个关系中增加另一关系的码作为属性，这样，这两个关系模式可以有如下形式：

车间主任(车间主任号，车间号，车间主任名，…)

车间(车间号，车间名，…)

或为另一种形式：

车间主任(车间主任号，车间主任名，…)

车间(车间号，车间主任号，车间名，…)还可以有别的转换方法，如引进一个新的关系模式，如称为GT，它只包含两个属性项：“车间主任号”和“车间号”。这样，有关系模式如下：

车间主任(车间主任号，车间主任名，…)

车间(车间号，车间名，…)

GT(车间主任号，车间号，…)

可以看出，转换方法不同，性能会有所区别。◆ n:m联系的情况

例如，“学生”与“课程”之间存在着n:m联系，转换时，引入新的关系“选课”。这样，转换后所得到的关系模式如下：

学生(学生号，学生名，…)

课程(课程号，课程名，…)

选课(学生号，课程号，成绩)

2)一个实体型内联系的转换

◆ 1:n联系的情况

例如，在“学生”内部存在着1:n的领导与被领导的联系，学生中的班长领导班内的学生。这样，在转换时，只要在“学生”关系中增加一个属性项“班长学生号”就能反映这种1:n联系。转换后得到的关系模式如下：

学生(学生号，班长学生号，学生名，…)◆ n:m联系的情况

例如，在“零件”内部存在着n:m的构成联系，转换时，需引入新的关系，如称它为“构成”关系，它包括属性项“零件号1”(主零件)和“零件号2”(子零件)，还可以包括附加的属性项“数量”(构成该主零件所用该子零件的数量)。这样，转换后得到的关系模式如下：

零件(零件号，零件名，…)

构成(零件号1，零件号2，数量)◆ 1:1联系的情况

例如，“职工”内存在着1:1的配偶联系，转换时，只要在“职工”关系中增加一个属性项“配偶职工号”，就可反映这种1:1联系。这样，关系模式就变成如下形式：

职工(职工号，配偶职工号，职工名，…)

当然，也可以用另一种方法来转换，即引进新的关系，它的属性项包括“职工号”和“配偶职工号”。这样，转换后得到的关系模式如下：

职工(职工号，职工名，…)

配偶(职工号，配偶职工号)

3)多元联系和多重联系的转换

◆ 多元联系的情况

例如，“供应者S”、“零件P”和“工程J”之间存在着三元联系，转换时，需要引入新的关系，如称它为SPJ，关系SPJ包含S、P、J的码属性以及附加属性“数量QTY”。这样，转换后得到的关系模式如下：

S(S#，Sname，…)

P(P#，Pname，…)

J(J#，Jname，…)

SPJ(S#，P#，J#，QTY)◆ 对于多重联系的情况

转换时，一重一重地考虑，其转换规则与单重联系的情况相同。当然，在逻辑设计时应考虑规范化问题，这一点我们将在下面做详细讨论。

3．关系数据规范化方法

由E.F.Codd于1972年开始提出，以后又有了很大发展的关系数据库规范化理论是数据库设计的一种理论指南。规范化理论研究的是关系模式中各属性之间的依赖关系及其对关系模式性能的影响，探讨“好”的关系模式应该具备的性质，以及达到“好”的关系模式的设计算法，即关系模式的“优化”问题。规范化理论给我们提供判断关系模式优劣的理论标准，帮助我们预测可能出现的问题，提供了自动产生各种模式的算法工具，因此是设计人员的有力工具，也使数据库设计工作有了严格的理论基础。关系规范化理论也称数据库模式设计理论，它主要遵循两个原则，即关系的等价替代和数据最小冗余。通过关系规范化使数据模式设计得既稳定又灵活。所谓稳定，是指数据模式不随存储硬件的更新或存储方式的改变而改变。所谓灵活，是指数据结构允许方便地调整、扩充。如增加新的数据项，增加新的应用等，而不影响原来的程序。显然，不是什么样的数据结构都能做到这一点。例如，我们看一个“不好”的关系模式，设有“供应者”关系模式SUPPlier(Sname，saddress，Item，Price)，其中各属性分别表示供应者名、供应者地址、货物名称、货物售价。一个供应者供应一种货物则对应到关系中的一个记录。关系模式SUPPlier有如下问题：

(1)数据冗余。一个供应者每供应一种货物，他的地址就要重复一次。

(2)更新异常(不一致的危险)。由于数据冗余，有可能我们在一个记录中更改了某供应者的地址，而没有更改另一个记录中同一供应者的地址，于是同一供应者有了两个不同的地址，与实际情况不符。

(3)插入异常。如果某供应者没有供应任何货物，则我们无法登录它的名称和地址。事实上，Sname和Item构成关系模式Supplier的一个码，码值的一部分为空的记录是不能插入到关系中的。

(4)删除异常。如果一个供应者供应的所有货物都被删除，则将丢失该供应者的名称和地址。由上述的问题可知，必须采取适当的办法来处理数据存储的逻辑结构，尽可能地简化数据存储的数据结构，以提高数据的可修改性、完整性和一致性。

下面我们就深入地讨论关系的第一规范化形式、第二规范化形式和第三规范化形式。

1)第一规范化形式(FirstNormalForm，1NF)

如果关系的每个属性都是不可分割的数据项，则称这个关系是1NF的。

现在让我们来分析一个不规范的表，见图9-12。这个关系不是规范的，因为它有重复组出现，因此是一个“不平坦”的数据结构。关系TEAF包括了教师的两类信息：一类是有关教师的固定信息，如T# (教师编号)、TNAME(教师姓名)、TAGE

(教师年龄)和TSALARY(教师工资)；另一类则是教师的变动信息，如TCOURSE(教师教课情况)，它包括三个数据项，分别为DATE(讲课日期)、CNAME(课程名称)和CNUM(课程时数)。这两类信息集中在一个表中必然出现许多冗余的数据，而且教课情况的数据项没有必要放在教师的基本情况中，这会引起重复组出现，应把它们去掉。于是将其分解成两个“平坦”的数据结构，如图9-13中的两个关系TEAJ(教师基本情况)和TEAC(教师教课情况)。

关系TEAJ的主关键字是T#，而关系TEAC的主关键字则由T#和CNAME共同组成的。图9-12不规范的关系TEAF图9-13第一范式关系TEAJ和TEAC

2)第二规范化形式(SecondNormalForm，2NF)

在介绍第二范式的定义之前，先引入函数依赖的概念。

如果在一个数据结构，也就是在关系R中，数据项B的取值依赖于数据项A的取值，我们就称B函数依赖于A，换句话说，就是A决定B。

下面从关系的概念上给出函数依赖定义。◆ 函数依赖

R作为一个关系，A和B是R中的两个属性，对于A的每一个值，必然有一个唯一的B值与之对应，则称关系R的属性B函数依赖于属性A，用A→B表示。通常可以理解为A决定B，或B由A决定。

我们以图9-13中的关系TEAJ为例，说明函数依赖关系。属性T#(教师编号)是关系中的关键字，它唯一地标识着关系的每个记录，其他属性TNAME、TAGE、TSALARY是由T#决定的，即如果已知教师编号，就可以唯一地查得教师姓名、教师年龄和教师工资，该三个属性依赖于教师编号。◆ 完全函数依赖

R为一个关系，A是它中的一个主关键字，B是R中的一个属性，若有A→B，则对A的任何一个真子集A’(A’A，A’A)都有A’ —→ B，则称B完全函数依赖于A，记为A —→ B’，若有A’ —→B，则称B部分依赖于A，记为A —→ B。

下面我们以图9-14所示的关系SCT为例，说明函数的完全依赖。pf图9-14非2NF的关系SCT在此关系SCT中，关键字为S#(学生号)和C#(课程号)，这是一个复合关键字。

这两个属性的取值唯一地确定了GRADE(学生成绩)，因为不同学生读不同课程时都将获取一个学习成绩，我们称“学生成绩”完全函数依赖于学生编号和课程编号。而课程号C#则可以唯一地标识教师姓名、教师年龄和教师所在办公室，这三个属性对于S#和C#这个复合关键字来说都是部分函数依赖的。◆ 第二范式定义

如果关系R是1NF的，并且关系的非主属性都完全函数依赖于R的每一个候选关键字，则称关系R为2NF。

当一个关系的键是一个复合关键字时，可能出现一个非关键字段函数依赖于关键字子集的事实，因而使关系中包含有非主属性部分依赖于候选关键字，导致2NF遭到破坏。

关系SCT是1NF的，但不是2NF的。因为S#和C#是关系SCT的复合关键字(候选关键字)，TNAME是关系SCT的非主属性，且有C＃→TNAME，即，SCT的非主属性部分依赖于复合关键字(S#和C#)，这不满足2NF的定义。不满足2NF的定义会出现什么问题呢？从关系SCT可以看出：在某一教师担任课之前不能在SCT中登记其姓名、年龄和办公室号(TAGE和OFFICE)，如TNAME为MENG的没有登记(该教师没任课)；当某教师不再上某班课程时，其姓名、年龄和所在办公室信息也被删除；关系中存在大量冗余数据，如教师的名字、年龄和办公室都随该教师上一门课而重复记载一次，这在修改时很繁琐，并容易引起数据的不一致性。因此，应把SCT转换成第二规范化形式，方法是：对于关键字由若干个数据项组成的数据结构，必须确保所有的非关键字属性完全函数依赖于复合关键字，必要时把它分解成若干个都属于2NF的关系，而每一个关系中的非关键字属性都完全函数依赖于复合关键字。例如，SCT可分解成两个关系，它们分别为SC(S#，C#，GRADE)和CTO(C#，TNAME，TAGE，OFFICE)，如图9-15所示。图9-15第二范式的关系SC和CTO

3)第三规范化形式(ThirdNormalForm，3NF)

在引进第三范式定义之前，先介绍传递函数依赖的概念。

◆函数传递依赖

关系R中的三个属性A、B、C，若A→B，B→C，则称C对A是函数传递依赖的，也可以说，C传递函数依赖于A。

用一般数据结构的术语来叙述就可以说：假设A、B、C分别是同一个数据结构中的三个数据项，如果B函数依赖于A，而C又函数依赖于B，那么C也函数依赖于A，我们称C函数传递依赖于A。这种情况说明，关系R中存在着函数传递依赖关系。现在让我们来分析图9-15中的CTO关系， 其中，TAGE是由TNAME决定的，而TNAME又由C#(课程)决定，所以，TAGE是传递依赖于C#的，因为教师的年龄是由教师的名字所决定的，而不能直接由课程决定。同样，OFFICE也是传递依赖于C#的。◆ 第三范式定义

若关系是2NF的，且没有任何R的非主要属性传递依赖于R的任何一个候选关键字，则称关系R是3NF的。

在3NF中，每个非主属性既不部分函数依赖于候选关键字，也不传递依赖于候选关键字。如果出现传递依赖就会造成关系的属性间不是互相独立的，即在某教师担任某门课程之前无法登记他的年龄等，此时没有主关键字值，如MENG的情况。解决的办法是对关系CTO进一步分解，关系CTO变成CT(C#，TNAME)和TO(TNAME，TAGE，OFFICE)，具体内容如图

9-16所示。图9-163NF的关系CT和TO小结一下前面三个范式的定义过程，可以说，把一个非规范化的数据结构转换成第三规范化形式的数据结构，一般要经过如图9-17所示的步骤。

由上面的讨论可知，数据库设计的规范化规则是为了防止修改数据引起的异常问题和数据的不相容性，同时，一般情况下，第三范式的关系所占用的存储空间会比非规范的关系所占用的存储空间少。图9-17从非规范化的关系到规范化的关系9.3.5数据库的物理设计

对于给定的数据模型，选取一个最适合于应用环境的物理结构的过程，称为数据库的物理设计。数据库的物理结构主要是指数据库在物理设备上的存储结构和存取方法，它显然依赖于具体的计算机。

物理设计的主要内容包括：

(1)确定数据的存储结构。在所提供的各种存储结构中选取合适的结构，即在保证数据逻辑结构的前提下，选择合适的结构加以实现。

(2)选择和确定存取路径。即为了满足多个用户的不同应用要求，确定对数据存储应建立哪些存取路径。例如，是否要建立次关键字以及以什么数据项作为次关键字，建立单码索引还是多码索引，对涉及不同文件的数据查询是否要建立数据链，等等。

(3)确定数据的存储介质。根据数据的不同应用情况，确定数据存放在磁带上还是光盘上、磁盘上，硬磁盘上还是软磁盘上。

(4)确定存储分配的有关参数。许多DBMS提供了一些存储分配的参数供物理设计时选用，如数据块长度、缓冲区大小和个数等。对于上述问题，采取不同的方法可以产生不同的方案，物理设计的任务就是根据数据库全部用户的应用要求，合理地考虑各种因素，在多种方案中选择一个存储空间的利用率高、存取速度快和维护代价小的方案去实现数据库。因此，物理设计的质量将直接影响数据库的性能和应用效果，是数据库设计的重要组成部分。9.3.6数据库的实现

数据库实现是指根据逻辑设计所确定的逻辑关系和物理设计所确定的物理结构，来具体地实现数据库，具体内容有：

(1)用DBMS所提供的数据描述语言(DDL)对逻辑设计和物理设计的结果进行描述，包括数据的描述、记录的描述、记录间联系的描述以及物理结构的各种描述。

(2)数据的输入、数据库的试运行，主要包括实际运行应用程序，用DBMS提供的数据操纵语言(DML)对数据库进行各种操作，测试应用程序的功能。还包括测量系统的各种性能指标，分析是否符合设计目标。9.3.7一个数据库设计的实例

下面将介绍在开发某企业管理信息系统时对车间生产数据库的设计。

1．E-R图

在车间DFD和数据字典的基础上，识别出实体和联系，绘制出E-R图，如图9-18所示。

图中，有8个实体(班、工人、日期、机组、及格标准、产品、设备、辅料)、9个联系(隶属、出勤、日计划、生产、开工、消耗、消耗定额、及格、使用)，这就是车间生产方面的企业模式。由E-R图转换出关系型DBMS下的17个关系(表文件)。显然，它们都是基础表，其数据都是由用户直接输入的，全系统的所有数据及各种输出都来源于它们。图9-18车间生产的E-R图

2．范式检查

经分析，班、工人、日期、机组、及格标准、产品、隶属、出勤、日计划、生产、开工、消耗、消耗定额、及格、使用等关系均满足3NF，但关系设备、辅料只满足1NF。

对设备、辅料两个关系的规范化，既要力图保持数据模式库完善，又要考虑提高数据库系统效率、简化程序，这就要求设计者进行全盘考虑、适当折中，采取较优的策略。设备(序号，名称，编号，型号，规格，单位，设计能力，实际能力，…)的候选关键字由一组属性组成：名称、编号和型号。而属性规格、单位、设计能力是部分依赖于候选关键字的，即函数依赖于候选关键字中的一个属性型号，因而不满足2NF。只要把设备分割成两个关系，如设备(序号，名称，编号，型号，实际能力，…)和设备型号(型号，规格，单位，设计能力)，则上述的两个新关系，即设备、设备型号就既满足2NF，也满足3NF了。考虑到分割前的关系设备在系统中使用频度低，与别的关系联系少，因此为了简化系统，就不分割了。辅料(辅料名，规格，单位，计量单位)的候选关键字是辅料名和规格，存在着部分函数依赖，即计量单位仅依赖于辅料名。分割成两个关系即可：(辅料名、规格、单价)、(辅料名、计量单位)，这就满足2NF和3NF。但考虑到两个关系都太小，徒然增加管理的工作，且原来的关系也是一个较小的关系，尽管有部分函数依赖存在，但带来的问题尚在可控制范围内，因此不分割。此外，考虑到系统运行时搜寻数据的方便，为这个关系增加一个属性，即搜寻过否，于是关系辅料变为(辅料名，规格，单价，计量单位，搜寻过否)，满足1NF。

3．中间库设计

系统的各种输出数据都是由基础数据运算产生的，由于上述基础表大多符合3NF，因而要产生输出数据的各种模式，常常要进行大量的联接操作，而且很多输出数据都要用到一些相同的模式，导致大量的文件开关操作，降低了系统运行速度，同时也产生了大量重复编程，重复运算，这都导致系统效率低下。为了克服这个缺点，采取的办法是把由基础表产生的一些公用的数据模式存储在一些公用表中，称为中间表。根据需要，设计6个中间表：班产量、班开机台时、班消耗、机型产量、影响生产情况和配套系统影响生产情况。下面的例子可以说明中间表对系统效率的提高和程序简化方面的作用。为产生某个生产日报表，在引入中间表之前，程序复杂，长达90K字节，运行既耗时，调试又困难；引入6个中间表后，使上述程序压缩到20K字节，调试方便，运行时间也大大下降了。

当然，中间表并不是必须的，但它能使系统优化。没有中间表，系统照样能正确工作，产生预期的结果。中间表完全来源于基础表，除了稍许增加一些数据冗余度外，不会为数据的一致性带来不利影响。由于中间表仅是临时存储的性质，因此不必考虑其规范化问题。总之，我们在进行数据库设计时，应遵循以数据为中心的原则开发管理信息系统，在数据库设计中摒弃那种终端用户观点的数据结构，立足于设计覆盖整个子系统的主题数据库，并尽可能在本单位计算机应用的战略规划指导下设计全局性的综合数据库。在数据库的具体设计中作好企业模式的设计，得到正确反映单位数据概貌的E-R图，进而获得能很好满足单位数据需求的基础数据库文件，最后处理好规范化和中间库的设计。

9.4关系型数据库及SQL语言简介

9.4.1关系数据库模型

关系模型是目前最重要的一种逻辑数据模型，关系数据库采用关系模型作为数据的组织方式。

1970年，美国IBM公司SanJose研究室的研究员E.F.Codd首次提出了数据库的关系模型，开创了数据库关系方法和关系数据理论的研究，为目前数据库技术奠定了理论基础。由于E.F.Codd的杰出工作，他于1981年获得ACM图灵奖。

1．关系模型的数据结构

表9-2是一张我们在工作中经常见到的一类表格，表名为“旅客信息表”，信息或数据按行列进行组织：一行数据信息描述了一个旅客，每列有一个列名，相同列的数据有相同的数据类型，一列描述了旅客的一个特征。在用户观点下，关系模型中的数据结构就是一张由行列构成的二维表格，可由以下术语描述：

(1)关系(relation)或表(table)：关系模型中数据的逻辑结构是一张二维表，它由行和列组成。

(2)元组(Tuple)或记录(Record)或行(Row)：表中的一行。

(3)属性(Attrribute)或列(Column)：表中的一列。

(4)码(键Key)或候选码(候选键CandidateKey)：如果关系的某一属性或属性组能唯一地标识一个元组(记录)，而其任何真子集无此性质，则称这个属性或属性组为该关系的码(键)或候选码(候选键)，如旅客信息表中的“身份证号码”。

(5)主键或主码：若一个关系有多个候选码，则选定其中一个为主键或主码。

(6)域(Domain)：属性的取值范围。

(7)关系模型：对关系或表的描述，一般表示为

关系名(属性1，属性2，…，属性n)键的诸属性称为主属性。一般在构成主键的诸属性下加下划线，以表示它们是构成主键的属性。

在关系模型中，实体集以及实体集间的联系都是用关系来表示的。我们实例中的一些表可表示如下：

(1)旅客(身份证号码，姓名，性别，工作单位，职务，职称，贵宾)。

(2)入住记录(身份证号码，入住时间，离店时间，房号，包房，预收金额，优惠级别，房金结账，消费结账，总账)

(3)房型价目(房型，价目，可住人数)。

(4)客房信息(房号，房型，入住人数)。

(5)消费项目分类(项目代码，项目名称，项目内容)。

(6)消费累帐(身份证号码，入住时间，项目代码，费用)。

(7)安全黑名单(身份证号码)。

关系模型要求关系必须是规范化的，即要求关系必须满足一定的规范条件。这些规范条件中最基本的一条就是，关系的每一个分量必须是一个不可分的数据项。也就是说，不允许表中有表，即列不能再分解。关系数据库中关系或表的性质如下：

(1)列是同质的，即每一列是同一类型的数据，取自同一个值域。

(2)每一列称为属性，要给予不同的属性名。

(3)列的顺序无所谓，即列的次序可以任意交换。

(4)任意两个元祖(记录)不能完全相同。

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

(6)每一分量必须是不可分的数据项。

2．关系模型的数据操作

关系模型中的数据操作是集合操作，操作对象和操作结果都是关系(二维表)，即若干元组或记录的集合。另一方面，关系模型把存取路径向用户隐蔽起来，用户只要指出“干什么”或“找什么”而不必详细说明“怎么干”或“怎么找”，从而大大地提高了数据的独立性，提高了用户的工作效率。

关系模型的数据操作主要包括两大类，一类是数据的查询；另一类是数据的插入、删除和修改。查询用来对数据库中的一个表或一组表进行检索，检索的结果仍然是表，即关系数据库要求所有的查询结构都以表的格式返回，从而查询结果作为表仍可参与其他的数据操作。

查询的基本操作可分为如下三类。

1)选择操作(SelectOperation)

如果在实例宾馆管理数据库中，要查找闽南大学的旅客，就要使用关系的选择操作。

选择操作：从一个表中选出所有满足给定条件的记录(行)，选出的记录构成一个新表，其关系模式与原表相同。

执行时，逐条扫描指定表中的记录，验证当前记录的属性值是否满足选择条件，当且仅当逻辑表达式为true时，将该记录放在结果表中。

例如，工作单位=闽南大学(旅客)，表示从表“旅客”中选择出其属性“工作单位”为“闽南大学”的旅客记录。

2)投影操作(ProjectOperation)

一个表所提供的对象属性有许多，有时关心的只是其中的部分属性，如对于“旅客”表，在应用中有时只要看到旅客的姓名和工作单位，并不关心诸如身份证号码等属性。这时就要使用关系的投影操作。

投影操作：从给定表的属性集中选择若干属性构成新表的属性，而给定表的记录在这些属性上的值保持不变。新表的属性集是原表的真子集。由于属性集{属性1，属性2，…，属性n}中不一定包含原表的键，因此经投影后，很可能出现重复的记录，违背了关系的性质。投影操作可以消除重复记录，构成新的表，所以新表的记录数将小于等于原表的记录数。

若投影的属性集中含有键，则新表记录数与原表的记录数相同。

例如，查看“旅客”表中两列“姓名”与“工作单位”的信息就是属于投影操作。

3)自然链接操作(NaturalJoin)

关系数据库系统当然也具有数据库系统数据冗余度小的特征，这个特性使得数据库中表的表示方式更为简洁。但要使得从数据库中提取的数据表达更为清晰的信息，就必须通过表间的联系来实现。例如，宾馆管理数据中，虽然表“入住记录”能够提供某人在该宾馆的入住历史记录，可以通过旅客的身份证号码进行查询，但是关于旅客，只有身份证号，使人很难知道该顾客的详细情况，而人们希望看到有某人的姓名与工作单位的信息，然而姓名与工作单位不在“入住记录”表中，在“旅客”表中。因为同一个人在这两个表中的身份证号码是一致的，这时就要使用关系的自然链接操作。自然链接操作：A为表R、表S属性集的交集，即A是由R、S中相同属性构成的集合，表R中除A外的属性集合记为B，表S中除A外的属性集合记为C，则表R的关系模式可以记为R(A，B)，表S的关系模式可以记为S(A，C)，B与C的交集为空集。R与S自然链接操作的结果是这样的一个表，其关系模式为R∞S，其中的记录由R、S中在A上取相同属性值的记录链接而成。例如，从“旅客∞入住记录”中选择身份证号码入住记录，可以用SQL语句表示为

SELECT姓名，入住时间，离店时间

FROM旅客，入住记录

WHERE旅客.身份证号码=入住记录.身份证号码AND旅客.身份证号码=

3．关系模型的完整性约束

完整性(Integrity)指保证数据的正确性、有效性和相容性的措施。关系的完整性约束条件包括四大类：域完整性、实体完整性、参照(引用)完整性和用户定义的完整性约束。其中，域完整性、实体完整性和参照完整性是关系模型必须满足的完整性约束条件，关系型DBMS应该自动支持这三个完整性约束。

1)域完整性约束(DomainIntegrityConsraint)

根据关系模型的定义，关系中不同记录在同一属性上的值是同一类型的数据，也就是说，取自相同的域，一旦定义了某一属性的取值域类型与范围，在数据库系统的运行中，就不允许不在域中的值进入同一列(属性)。

2)实体完整性约束(EntityIntegrityConstraint)

在关系数据库中，一个表通常对应现实世界的一个实体集。例如，实例的“旅客”表对应宾馆接待的旅客集合。在这个集合中，旅客是可区别的，也就是说，现实世界中的实体是可区分的，它们应具有某种唯一性标识，即关系模型中的键。在“旅客”表中，用“身份证号码”作为唯一性标识的主键，那么每个记录的“身份证号码”不能没有值，否则就有可能出现完全相同的旅客信息，因此，键中的属性，即主属性不能取空值。所谓空值，就是“不知道”或“无意义”的值。如果主属性取空值，就说明存在某个不可标识的实体，即存在不可区分的实体，这与实体是可区分相矛盾。实体完整性：若属性A是表的主属性，即它是构成键的一个属性，那么表中每个记录在属性A上都不能取空值。

例如，在表房型价目(房型，价目，可住人数)中，“房型”属性为主键，则在这个表记录中，“房型”不能取空值，而且每个记录的“房型”值互不相同。

实体完整性规则规定表中每个记录在所有主属性上都不能取空值。

例如，在表入住记录(身份证号码，入住时间，离店时间，房号，包房，预收金额，优惠级别，房金结账，消费结账，总账)中，“身份证号码”与“入住时间”为主键，则这个表中的每个记录在“身份证号码”和“入住时间”两个属性上都不能取空值。

3)参照完整性(ReferentialIntegrityConstaint)

现实世界中的实体之间往往存在某种联系，在关系模型中，实体及实体间的联系都是用表来描述的，这样就自然存在着表与表间的数据引用。

例如，在表消费项目分类(项目代码，项目名称，项目内容)与消费累账(身份证号码，入住时间，项目代码，费用)中，用下划线标注的为主键。这两个关系之间存在着属性的引用，即表消费累账引用了表消费项目分类的主键“项目代码”。显然，表消费累账中“项目代码”的值必须是表消费项目分类中确实存在的项目代码。也就是说，表消费累账中“项目代码”的取值需要参照表消费项目分类中“项目代码”的取值。同样，表消费累账中“身份证号码”与“入住时间”的取值需要参照表“入住记录”中主键“身份证号码”与“入住时间”的取值。

从上面可以看出，一个表往往引用的是另一个表的主键值。外键：如果F是表R的一个或一组属性，但F不是表R的键，如果F的值引用另一表S主键的值，则称F是表R的外键(ForeignKey)。

例如，在表入住记录(身份证号码，入住时间，离店时间，房号，包房，预收金额，优惠级别，房金结账，消费结账，总账)中，“身份证号码”是外键；“房号”因为引用表客房信息(房号，房型，入住人数)的主键“房号”的值，所以也是外键。

在表客房信息(房号，房型，入住人数)中，“房型”是外键。

在表消费累账(身份证号码，入住时间，项目代码，费用)中，“身份证号码”和“入住时间”是外键，“项目代码”也是外键。参照完整性约束定义了外键与主键之间的引用规则。

参照完整性：属性(或属性组)F是表R的外键，它引用表S的主键值，则R中每个记录在F上或者取空值(F的每个属性值均为空值)，或者等于S中某个记录的主键值。

例如，在表客房信息(房号，房型，入住人数)中，每个房间的“房型”属性只能有两种情形：

①空值，表示尚未给该房间定型(也许尚未装修或设备尚未配备)。

②非空值，这时该值必须是表房型价目(房型，价目，可住人数)中某个“房型”的值，表示该房间不可能分配到一个不存在的房型。

4)用户定义的完整性约束(User-definedIntegrityConstraint)

任何关系数据库系统都应该支持实体完整性和参照完整性。除此之外，在实际应用中，往往还需要一些特殊的约束条件，如在宾馆管理实例中，旅客入住时，要求用户交纳一定数额的预付款，以保证宾馆的利益。一般要求每个旅客入住时，都交纳至少200元的预付款，在定义数据库时，就应该将这个要求告诉DBMS，以使系统自动地验证这个条件。所以，用户定义的完整性是针对某一具体关系数据库的约束条件，它反映某一具体应用所涉及的数据必须满足的语义要求。例如，某个属性必须取唯一值，某些属性值之间应满足一定的函数关系，某个属性的取值范围在0～100之间等。

关系数据库管理系统应提供定义和检验这类完整性的机制，以使用统一的、系统的方法处理这类约束，而不是由应用程序承担这一功能。9.4.2SQL语言简介

SQL的全称是结构化查询语言(StructuredQueryLanguage)， 最早是IBM公司的SanJoseResearchLaboratory为其关系数据库管理系统SYSTEMR开发的一种查询语言。 SQL通常发音为“sequel”，所以如果听到用这个发音提到某种编程语言的话，指的就是SQL，当然也可以用缩写字母称呼它。SQL结构简洁，功能强大，简单易学，所以自从IBM公司1981年推出以来，得到广泛的应用。如今无论是像Oracle、Sybase、Informix、SQLServer这些大型的数据库管理系统，还是像VisualFoxPro、PowerBuilder这些微机上常用的数据库开发系统，都支持SQL作为查询语言。

1．SQL的历史

在20世纪70年代初，E.F.Codd首先提出了关系模型。20世纪70年代中期，IBM公司在研制SYSTEMR关系数据库管理系统中研制了SQL，最早的SQL是在1976年11月的IBMJournalR＆D上公布的。

1979年，ORACLE公司首先提供商用的SQL，IBM公司在DB2和SQL/DS数据库系统中也实现了SQL。

1986年10月，美国国家标准局ANSI(AmericanNationalStandardInstitute)采用SQL作为关系数据库管理系统的标准语言，后被国际标准化组织ISO(InternationalStandardizationOrganization)采纳为国际标准。

1989年，ANSI在ANSIX3.135—1989报告中定义SQL作为关系数据库管理系统的标准语言，称为ANSISQL89，该标准替代了ANSIX3.135—1986版本。SQL89标准同时为下列组织所采纳：

(1)国际标准化组织(ISO)：ISO9075—1989报告“DatabaseLanguageSQLWithIntegrityEnhancement”。

(2)美国联邦政府：在TheFederalInformationProcessingStandardPublication(FIPSPUB)127发布。

目前，所有主要的关系数据库管理系统都支持某些形式的SQL，大部分数据库遵循ANSISQL89标准。

2．SQL的特点

SQL之所以能够为用户和业界所接受，并成为国际标准，是因为它是一个综合的、功能极强又简捷易学的语言，它使全部用户，包括应用程序员、DBA管理员和终端用户受益匪浅。

1)非过程化语言

SQL是一个非过程化的语言，用SQL进行数据操作，只要提出“做什么”，而无须指明“怎么做”，因此无需了解存取路径及存取路径的选择，SQL语句的操作过程就由系统自动完成。这不但大大减轻了用户的负担，而且有利于提高数据的独立性。

2)面向集合的操作方式

SQL采用集合操作方式，不仅操作对象、查找结果可以是记录的集合，而且一次插入、删除、更新操作的对象也可以是记录的集合。SQL允许用户在高层的数据结构上工作，SQL语句接受集合作为输入，返回集合作为输出。SQL的集合特性允许一条SQL语句的结果作为另一条SQL语句的输入。

3)一体化的语言

SQL能完成定义关系模式、录入数据以建立数据库并提供查询、更新、维护、数据库重构、数据库安全性控制等一系列操作，SQL集数据定义语言(DataDefinitionLanguage，DDL)、数据查询语言(DataQueryLanguage，DQL)、数据操纵语言(DataManipulationLanguage，DML)和数据控制语言(DataControlLanguage，DCL)于一体．可以实现数据库生命期中的全部活动。

4)灵活的使用方式

SQL既是自含式语言，又是嵌入式语言。作为自含式语言，它能够独立地用于联机交互的使用方式，用户可以在终端键盘上直接键入SQL命令，以对数据库进行操作；作为嵌入式语言，SQL语句能够嵌入到高级语言程序中，供程序员设计程序时使用。在两种不同的使用方式下，SQL的语法结构基本上是一致的。这种以统一的语法结构提供两种不同的使用方式的做法，为用户提供了极大的灵活性与方便性。

5)语言简洁，易学易用

SQL设计巧妙，语言十分简洁，完成核心功能只用少量的动词，这些动词易于理解，构成的语言接近英语口语，因此容易学习和使用。

3．常用SQL语句及应用

SQL语言是集DDL与DML为一体的结构化数据库语言，是国际标准化组织规定的关系数据库的国际标准语言。

在SQL中，称关系为表TABLE，属性为列COL，元组(记录)为行ROW，下面分别从数据定义、数据查询、日常数据维护、汇总统计等方面详细介绍SQL语句。SQL有许多版本，对于不同的关系型数据库系统，稍有差异，这里以桌面数据库系统VisualFoxPro和SQLServer为例进行介绍。

1)数据定义语句

◆建立表文件

格式：

CREATETABLE<表名>(<列定义>[，<列定义>…])

其中，列定义语法为：

<列名><数据类型><空值指定>

数据类型主要有：

(1)数字型：NUMBER(n，d)，n为字长，d为小数位。

(2)字符型：CHAR(n)，n为字符长。

(3)日期型：DATE，为日-月-年。空值指定主要有：

(1) NULL或省略，表示该列可为空值。

(2) NOTNULL，表示该列不可为空值。

例如，有如下的SQL语句：

CREATETABLES(SNONUMBER(7)

NOTNULL，SNCHAR(8)，SANUMBER(3))◆撤销关系表

格式：

DROPTABLE<表名>

例如，删除刚才建立的表S的语句为

DROPTABLES

◆修改表结构

修改表结构有多种情况：增加列、删除列、修改列名以及修改现有列的宽度、小数位及类型等。命令格式为

ALTERTABLE<表名>不同的情况加不同的子句实现：

(1)修改现有列属性用ALTER子句，具体格式为

ALTERTABLE<表名>ALTER列名类型(宽度，小数位)

例如，ALTERTABLESALTERSNOCHAR(10)语句将字段SNO修改为10个宽度的字符型。

(2)增加列用ADD子句，具体格式为

ALTERTABLE<表名>ADD列名类型(宽度，小数位)

例如，ALTERTABLESADDDHCHAR(8)语句增加了一列DH，字符型，8个宽度。

(3)删除列用DROP子句，具体格式为

ALTERTABLE<表名>DROP列名

例如，ALTERTABLESDROPDH语句删除了字段DH。

◆建立视图

视图是一种虚拟关系，用户可以通过建立视图命令从一个或多个关系中选择所需数据项构成一个新的关系。格式：

CREATEVIEW<视图名>

ASSELECT列名1，列名2，…，列名N

FROM<表名>WHERE<条件>

视图不以文件形式存在外存中，一旦建立就可以像其他关系一样操作。例如，有学生表S(SNO，SN)、课程表C(CNO，CN，TNO)、教师表T(TNO，TN，TD)、成绩表SC(SNO，CNO，GR)，从S、SC、C中建立