关系型数据库：定义数据库表格之间的关系

　　设计关系型数据库的重头戏是把数据元素分别放进相关的表格里。一旦准备好开始操作数据，你就要依靠表格之间的关系把数据以有意义的方式联系到一起。例如，（单独的）订单信息是没有用的，除非你知道是哪个用户下了订单。到现在这个时候，你可能已经意识到了，你没有把客户信息和订单信息保存在同一个表格里。但是，你把订单信息和客户数据保存在两个相关的表格里，然后使用这两个表格之间的关系来同时查看每个订单及其相对应的客户信息。如果说规范化的表格是关系型数据库的基础，那么关系就是其基石。
　　关系型数据库设计系列
　　你现在正身处Builder.com关系型数据库设计系列之中。本系列先前的几篇相关文章是：
　　《关系型数据库：理论背后的灵感》
　　《关系型数据库：使用范式创建数据库》
　　《关系型数据库：应用第一范式》
　　《关系型数据库：实现规范化》
　　出发点
　　
　　下面这些数据要用在本文的示例中。使用Boyce-Codd范式（BCNF）来规范化数据的过程产生了七个关系表：
　　Books: {Title*, ISBN, Price}
　　Authors: {FirstName*, LastName*}
　　ZIPCodes: {ZIPCode*}
　　Categories: {Category*, Description}
　　Publishers: {Publisher*}
　　States: {State*}
　　Cities: {City*}
　　
　　现在是该说明这些表格之间是如何建立关联的时候了。
　　
　　关系的类型
　　
　　你和你的家庭成员之间存在着多种关系。例如，你和你母亲就是相关的。你只有一个母亲，但是她可以有多个子女。你和你的兄弟姐妹是相关的——你可以有很多的兄弟和姐妹，当然，他们也有很多兄弟和姐妹。如果你结了婚，你和你的配偶就会有一个配偶——这是相互的——但是一次只有一个。数据库的关系非常类似：它们是通过表格相关联的。有三种类型的关系：
　　
　　一对一（One-to-one）：在关系的每一边，这两个表格都只有一条记录。每个关键字的值都只和关系表里的一条记录（或者没有记录）相关。它们就是一对配偶一样——你可以结婚，也可以不结婚，但是如果结了婚，你和你的配偶就只能有一个配偶。大多数一对一的关系都是商业规则所要求的，而不是源自于数据的要求。在没这样商业规则限制的时候，你通常可以把两个表格合并进一个表格，而且不会打破任何规范化的规则。
　　一对多（One-to-many）：主关键字表格只包含有一条记录，这条记录和关系表里的无记录、一条记录或者多条记录相关。这种关系同你和你父母之间的关系很类似。你只有一个母亲，但是你的母亲可以有多个子女。
　　多对多（Many-to-many）：两个表格里的每条记录都可以和另一个表格里任意数量的记录（或者无记录）相关。例如，如果你有好几个兄弟姐妹，那么你的兄弟姐妹也有好几个兄弟姐妹。多对多的关系需要引入第三个表格，叫做联系表（associate table或者linking table）因为关系型系统不能直接实现这种关系。
　　建立关系
　　
　　　
　　
　　在考虑建立关系表之间的关系之前，你可能需要非常熟悉数据。只有在熟悉数据之后，关联会比你刚开始的时候更明显。你的数据库系统要依靠匹配两个表格里的值来建立关系。如果匹配的话，系统会从这两个表格里抽出数据来创建一个虚拟记录。例如，你可能想要查看某个作者写的所有书。在本文里，系统会匹配Books和Authors这两个表格里的值。要记住在大多数时候，所产生的记录是动态的，这就意味着对这条虚拟记录的任何改动通常都会作用到底层的表格上，这一点非常重要。
　　
　　这些进行匹配的值都是主关键字值和外来关键字值。（关系模型并不要求关系要根据主关键字类来确定。你可以使用表格里的备选关键字，但是使用主关键字是大家认可的标准。）在（本系列的）第二篇文章里你已经了解了主关键字——主关键字会唯一辨别表格里的每条记录。外来关键字简单地说就是一个表格在另一个表格里的主关键字。这样看来，你要做的东西不多——只用简单地把主关键字作为外来关键字添加到关系表里就行了。
　　
　　唯一需要注意的是，外来关键字字段的数据类型必须和主关键字的相同。但是有些系统可以允许这条规则的一个例外，它们能够允许数字和自动编号（autonumbering）字段（例如SQL服务器Identity的Access的AutoNumber）建立关系。此外，外来关键字的值可以是空（Null），尽管推荐的是：在没有特别原因的情况下，不要让外来关键字为空。你有可能永远都不会使用需要这项功能的数据库。
　　
　　现在回到你的示例数据库，并开始正确地输入外来关键字。（请继续在纸上打草稿——在你的数据库系统里真正创建表格仍然是件很容易的事情。在纸上纠正错误要容易得多。）要记住，你正在把主关键字的值添加到关系表里。只用调用条目之间的关系就行了，而其他的就简单了：
　　
　　书（book）和分类（category）相关。
　　书和出版商（publisher）相关。
　　书和作者（author）相关。
　　作者和邮政编码（ZIP code）相关。
　　邮政编码和城市（city）相关。
　　城市和州（state）相关。
　　
　　这一步不是一成不变的，你可能会发现在规范化的过程中加入外来关键字会更容易一些。在把字段移动到一个新的表格时，你可能要把这个新表格的主关键字添加到原来的表格里，作为其为外来关键字。但是，在你继续规范化剩余数据的时候，外来键常常会发生改变。你会发现在所有这些表格被全部规范化之后，一次添加所有的外来关键字，这样的效率会更高。
　　
　　现在让我们一次操作一个表格，就从Books表格开始，它在这个时候只有三个字段。很明显，Authors、Categories和Publishers表格的主关键字会被添加到Books里。当你完成的时候，Books表格就有了七个字段：
　　　
　　要记住，Authors表格里的主关键字是一个基于姓和名字段的复合关键字。所以你必须要把这个两个字段都添加到Books表格里。要注意，外来关键字字段名的结尾包含有FK这个后缀。加入这个后缀有助于提高可读性和自我归档。通过名称这种方式来区别外来关键字会让追踪它们更简单。如果主关键字和外来关键字的名称不同，这没有关系。
　　
　　这里出现了三种关系：Books和Authors、Books和Categories，以及Books和Publishers。这三种关系中的两种所存在的问题可能没有那么明显：
　　
　　Books和Authors之间的关系：一本书可以有多个作者。
　　Books和Categories之间的关系：一本书可以被归入多个类。
　　　
　　
　　
　　这两者的关系是多对多的关系。先前我告诉过你，表格不能直接实现这样的关系，而需要第三个联系表来实现。（Books和Publishers的关系是一对多的关系，就像现在所说的这样是没有问题的。）
　　
　　这两个刚发现的多对多关系将需要一个联系表来包含来自每个表格的主关键字，并将其作为外来关键字。新的联系表是：
　　BooksAuthorsmmlink
　　TitleFK (FK) Books.Title one-to-many
　　ISBNFK (FK) Books.ISBN one-to-many
　　FirstNameFK (FK) Authors.FirstName one-to-many
　　LastNameFK (FK) Authors.LastName one-to-many
　　
　　BooksCategoriesmmlink
　　TitleFK (FK) Books.Title one-to-many
　　ISBNFK (FK) Books.ISBN one-to-many
　　CategoryFK (FK) Categories.Category one-to-many
　　
　　没有必要更改Categories、Authors或者Publishers表格。但是，你必须把FirstNameFK、LastNameFK和CategoryFK这三个外来关键字从Books里移走：
　　Books
　　Title (PK)
　　ISBN (PK)
　　Price
　　PublisherFK (FK) Publishers.Publisher one-to-many
　　
　　现在，让我们转到Authors表格上来，它现在有两个字段。每个作者都和ZIPCodes表格里邮政编码的值相关。但是，每个邮政编码会和多个作者相关。要实现这种一对多的关系，就要把ZIPCodes表格的主关键字添加进Authors表格作为外来关键字：
　　Authors
　　FirstName (PK)
　　LastName (PK)
　　ZIPCodeFK (FK) ZIPCodes.ZIPCode one-to-many
　　
　　至此，你已经准备好了处理剩下的地址部分了。看到它们被分在不同的表格里是很让人奇怪的，但是这是遵照BCNF正确规范化数据的结果。每个邮政编码的值只会有一个对应的城市值和州值。每个城市和州的值只会被输入进其对应的表格里一次。ZIPCodes和Cities表格需要外来关键字字段来实现这些关系：
　　ZIPCodes
　　ZIPCode (PK)
　　CityFK (FK) Cities.City one-to-many
　　
　　Cities
　　City (PK)
　　StateFK (FK) States.State one-to-many
　　
　　States
　　State (PK)
　　
　　从一个到九个
　　
　　最后，你有了九个表格：Books、Authors、Categories、Publishers、ZIPCodes、Cities、States、BooksAuthorsmmlink和BooksCategoriesmmlink。图A是这个示例表格数据库最终的图形形式。很难想像一个简单的数据表格会被分成九个表格。
　　
　　图A
　　
　　原来的表格现在需要九个表格
　　
　　由于这个示例数据库很简单，你可能会问这些关系有什么作用。看起来你仍在保存冗余的数据，只不过形式不同罢了——通过外来键来实现。这是因为我们的表格现在只有很少几个字段。试想一下有十几个字段的表格。需要承认的是，你仍然需要把表格的主关键字作为外来关键字保存进关系表里，但是至多可能最多增加一到两个字段。比较一下为这个表格里的每一条记录都添加十几个条目的情形吧。