设计关系数据库的一个重要部分是将数据元素划分为相关的表。一旦准备好开始处理数据，就可以依赖表之间的关系以有意义的方式将数据聚合在一起。例如，除非您知道哪个客户下了特定的订单，否则订单信息是无用的。到目前为止，您可能已经意识到，您并没有将客户和订单信息存储在同一个表中。而是将订单和客户数据存储在两个相关表中，然后使用这两个表之间的关系同时查看每个订单及其相应的客户信息。如果规范化表是关系数据库的基础，那么关系就是基础。
本文使用以下数据进行演示。通过Boyce - Codd范式( BCNF )对数据进行规范化的过程产生了七个相关表格:
书籍: {标题*，ISBN，价格}
作者: {名字*，姓氏* }
邮政编码: {邮政编码* }
类别: {类别*，说明}
发布者: {发布者* }
状态: { State * }
城市: {城市* }
关系类型
你和家人有很多关系。例如，你和你母亲是亲戚。你只有一个母亲，但她可能有几个孩子。你和你的兄弟姐妹是亲戚——你可能有很多兄弟姐妹，当然，他们也会有很多兄弟姐妹。如果你结婚了，你和你的配偶都有配偶——彼此——但一次只有一个。数据库关系非常相似，因为它们是表之间的关联。关系有三种类型:
- 一对一:两个表在关系的任一侧只能有一条记录。每个主键值仅与相关表中的一个(或否)记录相关。他们就像夫妻一样——你可以结婚，也可以不结婚，但是如果你结婚了，你和你的配偶只有一个配偶。大多数一对一关系都是由业务规则强制执行的，并且不会自然地从数据中流动。如果没有这样的规则，通常可以将这两个表合并到一个表中，而不破坏任何规范化规则。
- 一对多:主键表仅包含一个与相关表中的无、一个或多个记录相关的记录。这种关系类似于你和父母之间的关系。你只有一个母亲，但你母亲可能有几个孩子。
- 多对多:两个表中的每个记录都可以与另一个表中的任意数量的记录(或没有记录)相关。例如，如果您有几个兄弟姐妹，那么您的兄弟姐妹也是如此(有许多兄弟姐妹)。多对多关系需要第三个表，称为关联表或链接表，因为关系系统不能直接容纳关系。
建立关系
当您开始建立相关表之间的关系时，您可能已经非常熟悉这些数据了。因此，此时的关联比开始时更明显。数据库系统依赖于在两个表中找到的匹配值来形成关系。找到匹配项后，系统将从两个表中提取数据以创建虚拟记录。例如，您可能希望查看特定作者编写的所有书籍。在这种情况下，系统将匹配图书和作者表之间的值。重要的是要记住，大多数情况下，生成的记录是动态的，这意味着对虚拟记录所做的任何更改通常都将返回到底层表。
这些匹配值是主键和外键值。(关系模型不要求关系基于主键。您可以使用表中的任何候选键，但使用主键是公认的标准。)您在第2部分中了解了主键—主键唯一标识表中的每个记录。a外键简单地说，就是一个表在另一个表中的主键。因此，您没有什么可做的—只需将主键字段作为外键添加到相关表中即可。
唯一需要考虑的是外键字段必须与主键具有相同的数据类型。某些系统允许此规则的一个例外，并且允许数字与自动编号字段之间的关系(例如SQL Server中身份访问中的自动编号)。此外，外键值可以为Null，尽管建议您在没有非常具体的原因的情况下不要将外键保留为Null。您可能永远不会使用需要此功能的数据库。
返回到您的示例表，并根据需要开始输入外键。(继续使用纸面列表—在数据库系统中实际创建表还为时过早。在纸上改正错误要容易得多。)请记住，您要将主键值添加到相关表中。简单地回忆一下实体之间的关系，剩下的就容易了:
- 书籍与类别有关。
- 书籍与出版商有关。
- 书籍与作者有关。
- 作者与邮政编码相关。
- 邮政编码与城市相关。
- 城市与州有关。
这个特定步骤不是用石头写的，您可能会发现在规范化过程中添加外键更容易。将字段移动到新表时，可能会将新表的主键作为外键添加到原始表中。但是，在继续规范化剩余数据时，外键通常会发生更改。您可能会发现，在所有表完全规范化之后，一次完成所有这些任务更有效。
让我们从Books表开始，一次遍历每个表，此时该表只有三个字段。具体而言，将“作者”、“类别”和“发布者”表中的主键添加到图书中。完成后，“帐簿”表有七个字段:
书
标题(主键)
国际标准书号(主键)
价格
名作者。名字多对多
作者。姓多对多
类别( FK )类别。类别多对多
出版社。出版商一对多
请记住，Authors表中的主键是基于名字和姓氏字段的复杂键。因此，必须将这两个字段添加到“帐簿”表中。请注意，外键字段名称包含FK后缀。添加后缀提高了可读性，并且是自文档化的。如果以外键的名称标识外键，您可能会发现跟踪外键更容易。如果主键和外键的名称不同，也没关系。
存在三种关系:书籍与作者、书籍与类别和书籍与出版商。您可能不太清楚的是其中两种关系的问题:
- 给作者的书:一本书可以有多个作者。
- 图书分类:一本书可以有多个类别。
这两种关系表示多对多关系。前面我们已经告诉过您，表不能直接适应这些关系，需要第三个链接表。(图书与出版商之间的关系是一对多的关系，就像目前所说的那样。) )
新发现的两种多对多关系都需要一个链接表，其中包含每个表中的主键作为外键。新的连结资料表为:
图书作者
书名。标题一对多
书。一对多
名作者。名字一对多
作者。姓氏一对多
图书分类
书名。标题一对多
书。一对多
类别( FK )类别。一对多类别
不需要更改“类别”、“作者”或“发布者”表。但是，必须从帐簿中删除名为fk、LastNameFK和CategoryFK的外键:
书
标题(主键)
国际标准书号(主键)
价格
出版社。出版商一对多
现在，让我们转到Authors表，该表当前有两个字段。每个作者都与ZIPCodes表中的邮政编码值相关联。但是，每个邮政编码可能涉及多个作者。要适应这种一对多关系，请将ZIPCodes表中的主键作为外键输入到Authors表中:
作者
名字(主键)
姓氏(主键)
邮政编码。邮政编码一对多
此时，您已经准备好处理剩余的地址组件。看到它们被分成表很奇怪，但这是通过BCNF对数据进行正常化的结果。每个邮政编码值将具有一个相应的城市和州值。每个城市和州的值将只在其相应的表中输入一次。zipcode和城市表需要外键字段来适应这些关系:
邮政编码
邮政编码
城市。城市一对多
城市
城市(主键)
州。一对多状态
州
状态(主键)
从一点到九点
最后，您有九个表:图书、作者、类别、出版商、邮政编码、城市、州、图书作者和图书类别。图一在此过程结束时，显示示例图书数据库的图形表示。很难想象一个简单的数据表可以分成九个。
| 图一 |
 |
| 原始表现在需要九个表。 |
由于示例的简单性，您可能想知道这种关系业务如何帮助您。看起来您仍然以外键的形式存储冗余数据，只是不同而已。那是因为我们的表现在只有几个字段。试着想象一张有十几个字段的桌子。当然，您仍然必须将该表的主键存储为相关表中的外键值，但这最多可能构成一个或两个额外字段。与为每个记录添加该表中的所有十几个条目的替代方案相比。