不运用关系型数据库的理论就想使用关系型数据库治理系统（relational database management system，RDBMS）与不踩离合器就想使用启动标准变速器一样不现实。你不要在歧途上走得更远了。实际上，你的应用程序的问题可能就是起因于一个不合格的数据库。
但是情况可能会更糟，你创建的数据库可能会错误报告数据、甚至还会破坏数据。在本系列文章中，你将会学到如何运用关系规则并从中学会如何开发一个可以保护数据合法性的数据库。让我们以回顾关系型数据模型的方式开始本系列文章。
在最初……
尽管我们已经被新的技术所包围，但我们中的许多人还是得依靠老的成熟技术——RDBMS和关系型数据库理论。它们起源于三十年前，那时保存大量数据的资源是很昂贵的。
在我们今天广为使用的关系型数据库出现之前，数据是按扁平文件（flat-file）的格式保存起来的。所有的数据以记录的形式保存到一个大的表格中。设想一下反复输入客户地址、电话号码以及其它重要信息的情形——每一次插入都需要重排客户记录。扁平文件需要冗余的数据，这就导致了大文件的产生。此外，扁平文件数据很难处理，而且需要大量的人力资源去维护它——这最终等效于需要更多的薪水支出、更多的办公空间以及更多的设备。一言以蔽之，关系型数据库理论的产生是由问题所激励出来的，这个问题就是维护数据以及与之相关的程序的花费和复杂度。
上述问题的解决方案
关系型模型解决了冗余数据的问题。理论出现之后，工具紧接着也诞生了。在E. F. Codd博士于1970年发表了名为《大规模共享数据银行的关系型模型》的论文（发表在Communications of the ACM杂志1970年6月刊上）之后，解决方案也就出现了。在这篇论文中，Codd博士介绍了用来消除保留冗余数据的必要性的一套规则。这套规则就是关系型数据库理论的起源。
由此产生的关系型数据库就成为了按关系表示数据的数据模型。数据模型在概念上是数据、关系以及对数据的约束这三者的集合。关系型数据库模型就是对象、事件和与关系型数据库系统有关的其它事项在概念上的表示。其真正含义就是关系型数据模型要求数据按照关系来保存。
关系（一类数据在概念上的集合）由表格（它保存了关于实体的信息）来表示。表中的每一行对应一个tuple（元组），列对应一个属性。在本文中，属性仅仅是关系中的一个命名列。每个属性都和一个值域（该属性可能的赋值范围）相联系。例如，表A给出了给出了一个关系（它保存了关于书的信息）的某些属性的值域。
表A
Book关系的例子
值域定义了哪些值可以保存到特定的栏上。例如，你可以限制name栏的字数等于或者少于35个字符。可接受的名字集合就是值域，该值域可以包括一个上限为35个字符。值域是概念上的；RDBMS并不用除数据类型之外的技术支持值域。你必须使用系统特性，如为了进一步限制栏所接收的数据类型，可以加上对字符数限制的约束。
一般只有在进行纯技术讨论时，你才会遇上如关系、tuple和属性这样的术语。在本系列文章的其它部分，我将分别用到以下三个术语：表、记录和栏（这三个术语不太正式，但是得到了广泛使用）。一些人更喜欢用术语：文件、行和字段，但是实际上这是一回事。
关系型表格存储关于某一个事情的数据、概念或者事件。表格是保存在行和栏中的相关数据的集合。栏（或者字段）定义为数据的种类。所有的栏组合成一个记录，它表示关于一个条目或者实体的所有相关数据。
今天的RDBMS把关系型数据库的理论付诸实现。从技术的角度来说，RDBMS包括了数据以及治理这些数据的接口工具。这意味着使用这个系统你就不需要其它工具来添加、删除、更新以及观看数据。你所需要的所有东西这个系统都有。这个系统还包括元数据（metadata）：对保存数据本身的描述。
为什么使用关系型数据库
关系型理论在建立时没有考虑到存储器——无论是挥发性的还是永久性的——是非常昂贵而且计算机需要许多物理空间的问题。显然，这些问题已经不复存在了，所以使用关系型数据库还会存在什么问题呢？利用关系型数据模型，你可以做到：
消除冗余数据。
消除数据间的不一致性。
保护数据的完整性。
由于存储器很便宜了，从存储的观点来看，数据库是否存在冗余数据并不是一件大不了的事情。然而，减少输入条目所花费的时间附带出来的一个好处就是减少数据输入错误。每个条目只保存一次，所以即使你犯了一个错误，你也只需要修正出错的那个输入即可。关系型数据模型相对其它数据模型的其它个好处将在本系列文章的后续部分陆续介绍。
第一步——了解你的数据
在Codd博士的论文中，你找不到这个规则，但是熟悉数据并对数据库的目的有个彻底的了解是创建高效率、灵活的数据库的最重要的步骤。你需要和用户以及治理员交谈，收集所有的正在使用以及已发行的书面报表和报告。用户知道数据库需要收集什么数据以及如何处理。假如有必要，你要和用户坐在一起处理数据并观察他们的手工处理数据方法。治理员知道他们希望数据是以何种方式表示出来。用户和治理员这俩方面的观点都很重要，所以都要听取。
在会见用户和治理者之后，写一个任务称述。称述的长短完全根据需要而定，但是它应该清楚的定义数据库的目标并阐明实现该目标的主要过程，主要过程不需要写的很具体。然后把任务称述共享给参与项目的所有开发成员以及用户和治理员，以确保你知道项目的症结之所在。
当要求你修订任务称述时，你不必感到惊奇或者心烦。修订的次数越多，你对产生误解的机会也就越少，这就减少了日后修正带来的麻烦。
下一篇文章的内容
我已经解释了关系型数据模型的起源，但是你可能仍不能把握tuple、属性和关系的概念，对关系型数据库的了解也不多。本系列文章的第二部分将深入标准化规则，你将从中学到更多的知识。
