不运用关系型数据库的理论就想使用关系型数据库管理系统（relational database management system，RDBMS）与不踩离合器就想使用启动标准变速器一样不现实。你不要在歧途上走得更远了。实际上，你的应用程序的问题可能就是起因于一个不合格的数据库。但是情况可能会更糟，你创建的数据库可能会错误报告数据、甚至还会破坏数据。在本系列文章中，你将会学到如何运用关系规则并从中学会如何开发一个可以保护数据合法性的数据库。让我们以回顾关系型数据模型的方式开始本系列文章。
尽管我们已经被新的技术所包围，但我们中的许多人还是得依靠老的成熟技术——RDBMS和关系型数据库理论。它们起源于三十年前，那时保存大量数据的资源是很昂贵的。
在我们今天广为使用的关系型数据库出现之前，数据是按扁平文件（flat-file）的格式保存起来的。所有的数据以记录的形式保存到一个大的表格中。设想一下反复输入客户地址、电话号码以及其它重要信息的情形——每一次插入都需要重排客户记录。扁平文件需要冗余的数据，这就导致了大文件的产生。此外，扁平文件数据很难处理，而且需要大量的人力资源去维护它——这最终等效于需要更多的薪水支出、更多的办公空间以及更多的设备。一言以蔽之，关系型数据库理论的产生是由问题所激励出来的，这个问题就是维护数据以及与之相关的程序的花费和复杂度。
关系型模型解决了冗余数据的问题。理论出现之后，工具紧接着也诞生了。在E. F. Codd博士于1970年发表了名为《大规模共享数据银行的关系型模型》的论文（发表在Communications of the ACM杂志1970年6月刊上）之后，解决方案也就出现了。在这篇论文中，Codd博士介绍了用来消除保留冗余数据的必要性的一套规则。这套规则就是关系型数据库理论的起源。
由此产生的关系型数据库就成为了按关系表示数据的数据模型。数据模型在概念上是数据、关系以及对数据的约束这三者的集合。关系型数据库模型就是对象、事件和与关系型数据库系统有关的其它事项在概念上的表示。其真正含义就是关系型数据模型要求数据按照关系来保存。
关系（一类数据在概念上的集合）由表格（它保存了关于实体的信息）来表示。表中的每一行对应一个tuple（元组），列对应一个属性。在本文中，属性仅仅是关系中的一个命名列。每个属性都和一个值域（该属性可能的赋值范围）相联系。例如，表A给出了给出了一个关系（它保存了关于书的信息）的某些属性的值域。
表A
| 属性 | 域名 | 域定义 |
| Book的标题 | Title | 字符或者文本 |
| Book'的作者 | Author | 字符或者文本 |
| Book的国际标准图书编号 | ISBN | 字符或者文本 |
| Book的定价 | Price | 数字或者钱数 |
| Book的出版商 | Publisher | 字符或者文本 |
| Book的类标 | Category | 字符或者文本 |
