下载掌阅APP，畅读海量书库
立即打开
数据库技术是应对信息资源（即大量数据）的管理需求而产生的。信息技术的不断发展，尤其是人类迈入网络时代后，社会信息资源呈爆炸式地增长，对数据管理技术也随之提出更高的要求。数据管理技术先后经历了人工管理、文件系统、数据库系统3个阶段。在数据库系统中，数据模型主要有层次模型、网状模型和关系模型3种（另一种面向对象模型还处于探索研究中），目前使用最普遍的模型就是关系模型，它是关系型数据库的理论基础。
关系型数据库是建立在关系模型基础上的数据库，借助于集合代数等数学概念和方法来处理数据库中的数据，现实世界中的各种实体以及实体之间的各种联系均用关系模型来表示。
关系模型以二维表来描述数据。在关系模型中，每张表有多个字段列和记录行，每个字段列有固定的类型属性（如数字、字符、日期等类型）。关系模型中，数据结构简单、清晰，具有很高的数据独立性，因此是目前主流的数据库数据模型。
在关系数据模型中，关系可以看成由行和列交叉组成的二维表格，表中的行称为元组，可以用来标识实体集中的一个实体。表中的列称为属性，给每一列起个名称即为属性名，表中的属性名不能相同。列的取值范围称为域，同列具有相同的域，不同的列也可以有相同的域。表中任意两行（元组）不能相同。能唯一标识表中不同行的属性或属性组（即多个属性的组合）称为主键或复合主键。
关系与传统的二维表格数据文件具有类似之处，但是它们又有区别。严格地说，关系是一种规范化的二维表格，它具有如下性质。
● 属性值具有原子性，不可分解。
● 没有重复的元组，即没有重复的行。
● 理论上没有行序，但是在使用时有时可以有行序。
在关系型数据库中，关键码（简称键）是关系模型的一个非常重要的概念，它通常是行（元组）的一个或几个列（属性）。如果键是由一个列组成的，则称之为唯一键；如果是由多个列（属性）组成的，则称之为复合键。键的主要类型如下。
● 超键：在一个关系中，能唯一标识元组的属性或属性集称为关系的超键。
● 候选键：如果一个属性集能唯一标识元组，且又不含有多余的属性，那么这个属性集称为关系的候选键。
● 主键：如果一个关系中有多个候选键，则选择其中的一个键为关系的主键。用主键可以实现关系定义中“表中任意两行（元组）不能相同”的约束。
● 这里以管理学生信息为例，我们在“学生信息表”中设置学号、姓名、性别、年龄、院系、班级等列。在该表中，“学号”能够唯一标识一名学生，因此，把学号作为主键是最佳的选择。而如果把“姓名”作为主键则会存在问题，因为有可能存在同名的学生。为此，最好创建一个单独的键将其明确地指定为主键，这种唯一标识符在现实生活中很普遍，如身份证号、银行卡号、手机号、发票号等。
● 外键：如果一个关系R中包含另一个关系A的主键所对应的属性组T，则称此属性组T为关系R的外键，并称关系A为参照关系，关系R是依赖关系。为了表示关联，可以将一个关系的主键作为属性放入另一个关系中，第二个关系中的那些属性就称为外键。
这里以商品销售为例，在填写一张商品销售单时，可以将商品销售信息分为两大类：第一类是单据的主体信息（销售主表），如销售单号、销售金额、销售日期、收款人等；第二类是单据的明细信息（销售明细表），如商品序号、商品名称、商品数量等。在数据库的销售主表中通常以“销售单号”作为主键；在销售明细表中，为了标识被销售出去的商品隶属于哪张单据，需要对每一条商品销售记录标明“单据编号”。在这种情况下，销售明细表中的“销售单号”就被称为外键，因为“销售单号”是其所在表以外（主体表）的一个主键。
当出现外键时，主键与外键的列名称可以是不同的，但必须要求它们的值集相同，即销售明细表中出现的“销售单号”一定要和主体表中的值匹配。
对于上面提到的二维表格中存储的数据信息，通常以物理文件的形式存储在磁盘上，这种物理文件称为数据文件。用户通常使用数据库软件与磁盘上的数据文件进行交互，这种数据库软件就称为数据库管理系统（DBMS）。DBMS是建立在操作系统基础上的，它可以对数据库文件进行统一的管理和控制。用户对数据库提出的访问请求都是由DBMS来处理的。另外，DBMS还提供了多种用于管理数据的实用工具。
在设计关系型数据库时，首先需要为它建立逻辑模型。关系型数据库的逻辑模型可以通过实体和关系组成的图形来表示，这种图形称为E-R图，它将现实世界中的实体和实体之间的联系转换为逻辑模型。使用E-R图形表示的逻辑模型称为E-R模型，一个标准的E-R模型由实体、属性和联系3部分组成。
实体是一个数据对象，是指客观存在并可以相互区分的事物，如一名教师、一名学生、一名雇员等。每个实体由一组属性来表示，如一名具体的学生拥有学号、姓名、性别和班级等属性，其中学号可以唯一标识该名学生实体。具有相同属性的实体组合在一起就构成实体集—实体的集合，而实体则是实体集中的某一个特例。例如，王同学这个实体就是学生实体集中的一个特例。
在E-R模型中，实体用矩形表示，矩形内注明实体的命名。实体名常用以大写字母开头的有具体意义的英文名词来表示，联系名和属性名也采用这种方式。图1.2为一个图书档案的E-R图。
在实际应用中，实体之间是存在联系的，这种联系必须在逻辑模型中表现出来。在E-R模型中，联系用菱形表示，菱形框内写明联系名，并用连接线将有关实体连接起来，同时在连接线的旁边标注上联系的类型。两个实体之间的联系类型可以分为以下3类。
● 一对一：若对于实体集 A 中的每一个实体，在实体集 B 中最多有一个实体与之相关，反之亦然，则称实体集 A 与实体集 B 具有一对一的联系，可标记联系为1∶1。
● 一对多：若对于实体集 A 中的每一个实体，在实体集 B 中有多个实体与之相关；反之，对于实体集 B 中的每一个实体，实体集 A 中最多有一个实体与之相关，则称实体集 A 与实体集 B 具有一对多的联系，可标记联系为1∶ n 。
● 多对多：若对于实体集 A 中的每一个实体，在实体集 B 中有多个实体与之相关；反之，对于实体集 B 中的每一个实体，实体集 A 中也有多个实体与之相关，则称实体集 A 与实体集 B 具有多对多的联系，可标记联系为 m ∶ n 。
例如，一名读者可以有多条图书借还记录，而一条借还记录只能隶属于一名读者，这样“读者档案实体”与“读书借还实体”之间就存在一对多的联系（即1∶ n ），如图1.3所示。
图1.2 图书档案实体E-R图
图1.3 “读者档案实体”与“读者借还实体”之间的联系
在数据库中，数据之间存在着密切的联系。关系型数据库由相互联系的一组关系组成，每个关系包括关系模式和关系值两方面。关系模式是对关系的抽象定义，给出关系的具体结构；关系值是关系的具体内容，反映关系在某一时刻的状态。一个关系包含许多元组（记录行），每个元组都是符合关系模式结构的一个具体值，并且都分属于相应的属性。在关系数据库中的每个关系都需要进行规范化，使之达到一定的规范化程度，从而提高数据的结构化、共享性、一致性和可操作性。
规范化是把数据库组织成在保持存储数据完整性的同时最小化冗余数据的结构的过程。规范化的数据库必须符合关系模型的范式规则。范式可以防止使用数据库时出现不一致的数据，并防止数据丢失。关系模型的范式有第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、第四范式（4NF）、第五范式（5NF）、第六范式（6NF）和BCNF范式等多种。通常数据库只要满足前3个范式就足够使用，下面举例介绍前3个范式。
第一范式是第二范式和第三范式的基础，是最基本的范式。第一范式包括下列指导原则。
● 数据组的每个属性只可以包含一个值。
● 关系中的每个数组必须包含相同数量的值。
● 关系中的每个数组一定不能相同。
在任何一个关系数据库中，第一范式是对关系模式的基本要求，不满足第一范式的数据库不是关系型数据库。
如果数据表中的每一个列都是不可再分割的基本数据项—同一列中不能有多个值，那么就称此数据表符合第一范式，由此可见第一范式具有不可再分解的原子特性。
在第一范式中，数据表的每一行只包含一个实体的信息，并且每一行的每一列只能存放实体的一个属性。例如，对于学生信息，不可以将学生实体的所有属性信息（如学号、姓名、性别、年龄、班级等）都放在一个列中显示，也不可以将学生实体的两个或多个属性信息放在一个列中显示，而是将学生实体的每个属性信息都放在一个列中显示。
如果数据表中的列信息都符合第一范式，那么在数据表中的字段都是单一的、不可再分的。例如，表1.1就是不符合第一范式的学生信息表，因为“班级”列中包含了“系别”和“班级”两个属性信息，这样“班级”列中的信息就不是单一的，它是可以再分的；而表1.2就是符合第一范式的学生信息表，它将原“班级”列的信息拆分到了“系别”列和“班级”列中。
表1.1 不符合第一范式的学生信息表
表1.2 符合第一范式的学生信息表
第二范式是在第一范式的基础上建立起来的，即满足第二范式需要先满足第一范式。第二范式要求数据库表中的每个实体（即各个记录行）可以被唯一地区分。为区分各行记录，通常需要为表设置一个区分列，用以存储各个实体的唯一标识。在学生信息表中，设置了“学号”列，由于每名学生的编号都是唯一的，因此每名学生可以被唯一地区分（即使学生存在重名的情况），那么这个唯一属性列被称为主关键字或主键。
第二范式要求实体的属性完全依赖于主关键字，即不能存在仅依赖主关键字一部分的属性，如果存在，那么这个属性和主关键字的这一部分应该分离出来形成一个新的实体，新实体与原实体之间是一对多的关系。
例如，这里以员工工资信息表为例，若以员工编码、岗位为组合关键字（即复合主键），就会存在如下决定关系。
（员工编码、岗位）→（决定）（姓名、年龄、学历、基本工资、绩效工资、奖金）
在上述决定关系中，还可以进一步拆分为如下两种决定关系。
（员工编码）→（决定）（姓名、年龄、学历）
（岗位）→（决定）（基本工资）
其中，员工编码决定了员工的基本信息（包括姓名、年龄和学历），而岗位决定了基本工资，所以这个关系表不满足第二范式。
对于上述这种关系，可以把上述两张关系表更改为如下3张表。
● 员工信息表：employee（员工编码、员工姓名、年龄、学历）。
● 岗位工资表：quarters（岗位、基本工资）。
● 员工工资表：pay（员工编码、岗位、绩效工资、奖金）。
第三范式是在第二范式的基础上建立起来的，即满足第三范式需要先满足第二范式。第三范式要求关系表不存在非关键字列对任意候选关键字列的传递函数依赖，也就是说，第三范式要求一张关系表中不包含已在其他表中包含的非主关键字信息。
所谓传递函数依赖，就是指如果存在关键字段A决定非关键字段B，而非关键字段B决定非关键字段C，则称非关键字段C传递函数依赖于关键字段A。
例如，这里以员工信息表（employee）为例，该表中包含员工编码、员工姓名、年龄、部门编码、部门经理等信息，该关系表的关键字为“员工编码”，因此存在如下决定关系。
（员工编码）→（决定）（员工姓名、年龄、部门编码、部门经理）
上述这种关系表是符合第二范式的，但它不符合第三范式，因为该关系表内部隐含着如下决定关系。
（员工编码）→（决定）（部门编码）→（决定）（部门经理）
上述关系表存在非关键字段“部门经理”对关键字段“员工编码”的传递函数依赖。对于上述这种关系，可以把这张关系表（即employee）更改为如下两个关系表。
员工信息表：employee（员工编码、员工姓名、年龄、部门编码）。
部门信息表：department（部门编码、部门经理）。
对于关系型数据库的设计，理想的设计目标是按照“规范化”原则存储数据的，因为这样做能够消除数据冗余、更新异常、插入异常和删除异常。