关系数据库应用数学方法来处理数据库中的数据。最早将这类方法用于数据处理的是1962年CODASYL发表的“信息代数”，之后有1968年David Child在IBM 7090机上实现的集合论数据结构，但系统、严格地提出关系模型的是美国IBM公司的E.F.Codd。
1970年，E.F.Codd在美国计算机学会会刊《Communications of the ACM》上发表了题为“A Relational Model of Data for Shared Data Banks”的论文，开创了数据库系统的新纪元。ACM1983年把这篇论文列为从1958年以来的四分之一世纪中具有里程碑意义的25篇研究论文之一。此后，E.F.Codd连续发表了多篇论文，奠定了关系数据库的理论基础。
20世纪70年代末，关系方法的理论研究和软件系统的研制均取得了丰硕的成果，IBM公司的San Jose实验室在IBM 370系列机上研制的关系数据库实验系统System R历时6年获得成功。1981年，IBM公司又宣布了具有System R全部特征的新的数据库软件产品SQL/DS问世。
与System R同期，美国加州大学伯克利分校也研制了INGRES关系数据库实验系统，并由INGRES公司发展成为INGRES数据库产品。
40多年来，关系数据库系统的研究和开发取得了辉煌的成就。关系数据库系统从实验室走向了社会，成为最重要、应用最广泛的数据库系统，大大促进了数据库应用领域的扩大和深入。因此，关系数据模型的原理、技术和应用十分重要，是本书、本课程的重点。
本书第2~6章、第8章和第9章将集中讨论关系数据库的有关问题。其中，第2章讲解关系模型的基本概念，即关系模型的数据结构、关系操作和关系的完整性：第3、4、5章介绍关系数据库标准语言SQL的数据定义、数据查询、数据更新、数据安全性和完整性控制等功能；第6章介绍关系数据理论，这是关系数据库的理论基础，也是关系数据库系统逻辑设计的工具；第8章介绍如何通过编程方法对关系数据库进行操纵；第9章讲解关系数据库查询处理和查询优化。
关系数据结构
及形式化定义
关系数据库系统是支持关系模型的数据库系统。第一章初步介绍了关系模型及其基本术语。本章将较深入地介绍关系模型。
按照数据模型的三个要素，关系模型由关系数据结构、关系操作集合和关系完整性约束三部分组成。下面首先来讲解关系数据结构，包括关系的形式化定义及有关概念。
关系
关系模型的数据结构非常简单，只包含单一的数据结构——关系。在用户看来，关系模型中数据的逻辑结构是一张扁平的二维表。
关系模型的数据结构虽然简单却能够表达丰富的语义，描述出现实世界的实体以及实体间的各种联系。也就是说，在关系模型中，现实世界的实体以及实体间的各种联系均用单一的结构类型，即关系来表示。
前面已经非形式化地介绍了关系模型及有关的基本概念。关系模型是建立在集合代数的基础上的，这里从集合论角度给出关系数据结构的形式化定义。
①域(domain)
域是一组具有相同数据类型的值的集合。
例如，自然数、整数、实数、长度小于25字节的字符串集合、{0，1}、{男，女}、大于等于0且小于等于100的正整数等，都可以是域。
②笛卡儿积(cartesian product)
笛卡儿积是域上的一种集合运算。
给定一组域D1，D2，…，Dn，允许其中某些域是相同的，D1，D2，…，Dn的笛卡儿积为
其中，每一个元素(d1，d2，…，dn)叫作一个n元组(n-tuple)，或简称元组(tuple)。元素中的每一个值d叫做一个分量(component)。
一个域允许的不同取值个数称为这个域的基数(cardinalnumber)。
若Di(i=1，2，…，n)为有限集，其基数为mi(i=1，2，…，n)，则D1×D2×…×Dn的基数M为
迪卡儿积可表示为一张二维表。表中的每行对应一个元组，表中的每一列的值来自一个域。例如给出三个域：
其中，(张清玫，计算机专业，李勇)、(张清玫，计算机专业，刘晨)等都是元组。张清玫、计算机专业、李勇、刘晨等都是分量。
该迪卡儿积的基数为2x2x3=12，也就是说，D1xD2xD3一共有2x2x3=12个元组。这12个元组可列成一张二维表，如下所示。
③关系(relation)
D1×D2×…×Dn的子集叫做在域D1，D2，···，Dn上的关系，表示为
R(D1，D2，…，Dn)
这里R表示关系的名字，n是关系的目或度(degree)。
关系中的每个元素是关系中的元组，通常用t表示。
当n=1时，称该关系为单元关系(unary relation)，或一元关系。
当n=2时，称该关系为二元关系(binary relation)。
关系是笛卡儿积的有限子集，所以关系也是一张二维表，表的每行对应一个元组，表的每列对应一个域。由于域可以相同，为了加以区分，必须对每列起一个名字，称为属性(attribute)。n目关系必有n个属性。
若关系中的某一属性组的值能唯一地标识一个元组，而其子集不能，则称该属性组为候选码(candidatekey)。
若一个关系有多个候选码，则选定其中一个为主码(primarykey)。
候选码的诸属性称为主属性(prime attribute)。不包含在任何候选码中的属性称为非主属性(non-prime attribute)或非码属性(non-key atribute)。
在最简单的情况下，候选码只包含一个属性。在最极端的情况下，关系模式的所有属性是这个关系模式的候选码，称为全码(all-key)。
一般来说，D1，D2，…，Dn的笛卡儿积是没有实际语义的，只有它的某个真子集才有实际含义。
例如，可以发现上表的笛卡儿积中许多元组是没有意义的。因为在学校中一个专业方向有多个导师，而一个导师只在一个专业方向带研究生；一个导师可以带多名研究生，而一名研究生只有一个导师，学习某一个专业。因此，上表中的一个子集才是有意义的，才可以表示导师与研究生的关系，把该关系取名为SAP，如下表所示。李勇和刘晨是计算机专业张清玫老师的研究生；王敏是信息专业刘逸老师的研究生。
把关系SAP的属性名取为域名，即SUPERVISOR，SPECIALITY和POSTGRADUATE，则这个关系可以表示为
SAP(SUPERVISOR，SPECLALITY，POSTGRADUATE)
假设研究生不会重名(这在实际生活中是不合适的，这里只是为了举例方便)，则POSTGRADUATE属性的每一个值都唯一地标识了一个元组，因此可以作为SAP关系的主码。
关系可以有三种类型：基本关系(通常又称为基本表或基表)、查询表和视图表。其中，基本表是实际存在的表，它是实际存储数据的逻辑表示：查询表是查询结果对应的表；视图表是由基本表或其他视图表导出的表，是虚表，不对应实际存储的数据。
按照迪卡儿积定义，关系可以是一个无限集合。由于组成笛卡儿积的域不满足交换律，所以按照数学定义，(d1，d2，…，dn)≠(d2，d1，…·，dn)。当关系作为关系数据模型的数据结构时，需要给予如下的限定和扩充。
(1)无限关系在数据库系统中是无意义的。因此，限定关系数据模型中的关系必须是有限集合。
(2)通过为关系的每个列附加一个属性名的方法取消关系属性的有序性，即(d1，d2，…，di，dj，…，dn) = (d1，d2，…，dj，di，…， dn) (i, j=1, 2，…，n)。
因此，基本关系具有以下6条性质。
(1)列是同质的(homogeneous)，即每一列中的分量是同一类型的数据，来自同一个域。
(2)不同的列可出自同一个域，称其中的每一列为一个属性，不同的属性要给予不同的属性名。例如，在上面的例子中，也可以只给出两个域：
人(PERSON)={张清玫，刘逸，李勇，刘晨，王敏}
专业(SPECIALITY)={计算机专业，信息专业}
SAP关系的导师属性和研究生属性都从PERSON域中取值。为了避免混淆，必须给这两个属性取不同的属性名，而不能直接使用域名。例如，定义导师属性名为SUPERVISOR-PERSON(或SUPERVISOR)，研究生属性名为POSTGRADUATE-PERSON(或POSTGRADUATE)。
(3)列的顺序无所谓，即列的次序可以任意交换。由于列顺序是无关紧要的，因此在许多实际关系数据库产品中增加新属性时，永远是插至最后一列。
(4)任意两个元组的候选码不能取相同的值。
(5)行的顺序无所谓，即行的次序可以任意交换。
(6)分量必须取原子值，即每一个分量都必须是不可分的数据项。
关系模型要求关系必须是规范化(normalization)的，即要求关系必须满足一定的规范条件。这些规范条件中最基本的一条就是，关系的每一个分量必须是一个不可分的数据项。规范化的关系简称为范式(Normal Form，NF)。范式的概念将在第6章关系数据理论中做进一步讲解。
例如，下表虽然很好地表达了导师与研究生之间的一对多关系，但由于属性POSTGRADUATE中分量取了两个值，不符合规范化的要求，因此这样的关系在数据库中是不允许的。通俗地讲，关系表中不允许还有表，简言之不允许“表中有表”。直观地描述，下表中还有一个小表。
注意：在许多实际关系数据库产品中，基本表并不完全具有这6条性质。例如，有的数据库产品仍然区分了属性顺序和元组的顺序。许多时候人们把元组称为记录，元组和记录是同一个概念。
关系模式
在数据库中要区分型和值。关系数据库中，关系模式是型，关系是值。关系模式是对关系的描述，那么一个关系需要描述哪些方面呢？
关系是元组的集合，因此关系模式必须指出这个元组集合的结构，即它由哪些属性构成，这些属性来自哪些域，以及属性与域之间的映像关系。
现实世界随着时间在不断地变化，因而在不同的时刻关系模式的关系也会有所变化。但是，现实世界的许多已有事实和规则限定了关系模式所有可能的关系必须满足一定的完整性约束条件。这些约束或者通过对属性取值范围的限定，例如职工年龄小于60岁(60岁以后退休)，或者通过属性值间的相互关联反映出来。例如，如果2个元组的主码相等，那么元组的其他值也一定相等，因为主码唯一标识一个元组，主码相等就表示这是同一个元组。关系模式应当刻划出这些完整性约束条件。
关系的描述称为关系模式(relation schema)。它可以形式化地表示为
R(U,D,DOM, F)
其中R为关系名，U为组成该关系的属性名集合，D为U中属性所来自的域，DOM为属性向域的映像集合，F为属性间数据的依赖关系集合。
属性间的数据依赖将在第6章讨论，本章中关系模式仅涉及关系名、各属性名、域名、属性向域的映像4部分，即R(U,D,DOM)。
例如，在上面例子中，由于导师和研究生出自同一个域——人，所以要取不同的属性名，并在模式中定义属性向域的映像，即说明它们分别出自哪个域，如：
DOM(SUPERVISOR)=DOM(POSTGRADUATE)=PERSON
关系模式通常可以简记为
R(U)
或 R(A1,A2,···, An)
其中R为关系名，A1,A2,···, An为属性名。而域名及属性向域的映像常常直接说明为属性的类型、长度。
关系是关系模式在某一时刻的状态或内容。关系模式是静态的、稳定的，而关系是动态的、随时间不断变化的，因为关系操作在不断地更新着数据库中的数据。例如，学生关系模式在不同的学年，学生关系是不同的。在实际工作中，人们常常把关系模式和关系都笼统地称为关系，这不难从上下文中加以区别，希望读者注意。
关系数据库
在关系模型中，实体以及实体间的联系都是用关系来表示的。例如导师实体、研究生实体、导师与研究生之间的一对多联系都可以分别用一个关系来表示。在一个给定的应用领域中，所有关系的集合构成一个关系数据库。
关系数据库也有型和值之分。关系数据库的型也称为关系数据库模式，是对关系数据库的描述。关系数据库模式包括若干域的定义，以及在这些域上定义的若干关系模式。
关系数据库的值是这些关系模式在某一时刻对应的关系的集合，通常就称为关系数据库。
关系模型的存储结构
我们已经知道，在关系数据模型中实体及实体间的联系都用表来表示，但表是关系数据的逻辑模型。在关系数据库的物理组织中，有的关系数据库管理系统中一个表对应一个操作系统文件，将物理数据组织交给操作系统完成；有的关系数据库管理系统从操作系统那里申请若干个大的文件，自己划分文件空间，组织表、索引等存储结构，并进行存储管理。
