在20世纪70年代初期，IBM研究员E. F. Codd博士开创性地研究开发了关系数据模型产品SEQUEL，即结构化英语查询语言（Structured English Query Language）。SEQUEL最终变成了SQL，或结构化查询语言（Structured Query Language，SQL）。
IBM及其他关系数据库的开发厂商都希望有一套能访问并操纵关系数据库的标准化方法。虽然IBM首创了关系数据库理论，但Oracle是第一家在市场上推出该技术的公司。随着时间的流逝，SQL在市场上得到了不错的反响，这引起了美国国家标准局（American National Standards Institute，ANSI）的关注，并分别在1986年、1989年、1992年、2003年及2006年发布了SQL标准。本文适用于ANSI 2003标准，因为ANSI 2006标准处理SQL元素已超出了本书的命令范围。（实质上，SQL2006标准描述了在SQL中如何使用XML。）
自1986年以来，已有多种可使程序员及开发者访问并操纵关系数据的语言。但是，很少有像SQL这么好学或被广泛地获得认同的一门语言。SQL让程序员及管理者只须学习单一语言，稍微作点调整，便可以把它广泛应用到多种数据库平台、应用程序及产品中。
《SQL技术手册（第三版）》讲述了五种SQL2003（SQL3）的常见实现：
1.1 关系模型与ANSI SQL
关系数据库管理系统（Relational database management systems，RDBMSs），如本书所介绍的，是全世界信息系统的主要驱动引擎，尤其在网络应用及分布式客户端/服务器（client/server）处理系统中较为常见。它们可让许多用户快速并同时访问、创建、编辑及操纵数据，也可让程序开发者编写有用的应用程序以便访问资源，还可让管理者对组织好的数据源加以维护、保护及最优化。
RDBMS是一套系统，它的用户数据为彼此互有关联的表集合，关联是由于它们有共同的数据值。数据存储在由数据行（row）和数据列（column）组成的数据表（table）中。如果独立的数据表间有唯一标识的数据列（即键），则它可表示共有的数据值，这些数据表也能彼此相联（或者说产生关联）。1970年6月，E. F. Codd发表在《美国计算机协会通讯》（Communications of the ACM）上的关键性论文《A Relational Model of Data for Large Shared Data Banks》中首次提出关系数据库理论。在Codd的新关系数据模型中，数据以结构式（形成由数据行和数据列组成的数据表）呈现，可以使用选择、投影及链接等操作方式管理，并且由于键值的完整性及参照完整性等原则而使得数据具有一致性。Codd还提出了支配关系数据库应如何设计的原则。运用这些原则的过程便是现在所谓的规范化（normalization）。
Codd的关系数据库系统原则
Codd在数据管理上应用了严谨的数学理论（以集合论为主），并编写了一些数据库必须符合的标准，这样才能称得上是关系数据库。关系数据库的核心概念是用数据表存储数据。这个概念如今已十分平常，以至于感觉有些微不足道。但是，在不久以前，设计能支持关系模型的系统这一任务并不容易，且只有有限的实用性。
下面是Codd提出的关系数据库的12项原则：
1. 信息是以数据表来逻辑呈现的。
2. 数据必须可以用数据表（table）、主键（primary key）和列（column）来逻辑访问。
3. NULL值必须一律被视为“缺少的数据（missing information）”，而不是空字符串、空白或零。
4. 元数据（metadata，即与数据库有关的数据）必须与一般数据一样存储在数据库中。
5. 单一语言必须能定义数据（data）、视图（view）、完整性限制（integrity constraint）、授权（authorization）、事务（transaction）及数据操作（data manipulation）。
6. 视图必须显示它的基表（base table）的更新，反之亦然。
7. 如下操作均须拥有各自的单一操作行为：获取数据、插入数据、更新数据或删除数据。
8. 批处理及终端用户的操作在逻辑上应该与物理存储及访问方式分开。
9. 批处理及终端用户的操作无须重建数据库模式（database schema）或其上的应用程序，便可改变数据库模式。
10. 一定要有完整性限制，并存储在元数据中，而不是存储在应用程序中。
11. 关系系统的数据操作语言不应该关注物理数据分布的位置或方式，无论物理数据是集中式存储还是分散式存储，语言也不应该加以改动。
12. 系统中的数据行处理须服从与集合处理相同的完整性原则及限制。
这些原则一直是用以验证数据库平台是否具有“关系型”特征的关键，不符合上述所有原则的数据库就不是完全的关系型。这些原则尽管并不适用于应用程序的开发，但是它们确实决定了数据库引擎本身是否是真正的“关系型”。目前，绝大部分的商用RDBMS产品均通过了Codd的测试。在《SQL技术手册（第三版）》所讨论的平台中，对于MySQL，除了本书中收录的版本以外，在此之前的MySQL发布版均不符合上述所有要求。
了解Codd的原则可以帮助程序员及开发者正确地开发与设计关系型数据库（relational database，RDB）。以下章节阐述了在运用关系数据库系统时如何让SQL满足上述的这些原则。
数据结构（第1项原则、第2项原则及第8项原则）
Codd的第1项原则及第2项原则说“信息是用数据表来逻辑呈现的”及“数据必须用数据表（table）、主键（primary key）及列（column）来访问”。因此，关系型数据库定义数据表的过程无须程序指示数据库如何同物理数据结构交互。此外，SQL在逻辑上隔离了访问数据的流程，并按照第8项原则“批处理及终端用户的操作在逻辑上应该与物理存储及访问方式分开”的要求来物理维护数据。
在关系模型中，数据是以二维数据表逻辑地显示单一实体（如，公务费用）的。学术界则把数据表称之为实体（entity），把列称之为属性（attribute）。数据表是由数据行（又称记录，学术界把它称为tuple）及列（又称属性，因为数据表的每列均说明了实体的每个特定属性）组成的。记录与列的交集是一个值。如果列或列存储的值可以辨认出每个记录的唯一性，那么该列便可作为主键（primary key）。如今，此种表示方式看起来似乎相当基本，但是在当初却是非常富有创新意义的一个概念。
尽管数据表是核心数据结构，但是SQL3定义了数据表以外的整体数据结构层次。关系型设计处理数据的基础是逐个的数据表处理，而不是逐个的记录处理。面向数据表是集合式程序设计（set programming）的核心。因此，几乎所有的SQL命令在处理数据表或跨数据表的数据集合时，都比处理单笔记录更为有效。换言之，有效的SQL程序必须按照数据集合的概念来思考，而不是按照单一的数据行来思考。