关系数据库:定义数据库表之间的关系

关系类型
你和家人有很多关系。例如，你和你母亲是亲戚。你只有一个母亲，但她可能有几个孩子。你和你的兄弟姐妹是亲戚——你可能有很多兄弟姐妹，当然，他们也会有很多兄弟姐妹。如果你结婚了，你和你的配偶都有配偶——彼此——但一次只有一个。数据库关系非常相似，因为它们是表之间的关联。关系有三种类型:

• 一对一:两个表在关系的任一侧只能有一条记录。每个主键值仅与相关表中的一个(或否)记录相关。他们就像夫妻一样——你可以结婚，也可以不结婚，但是如果你结婚了，你和你的配偶只有一个配偶。大多数一对一关系都是由业务规则强制执行的，并且不会自然地从数据中流动。如果没有这样的规则，通常可以将这两个表合并到一个表中，而不破坏任何规范化规则。
• 一对多:主键表仅包含一个与相关表中的无、一个或多个记录相关的记录。这种关系类似于你和父母之间的关系。你只有一个母亲，但你母亲可能有几个孩子。
• 多对多:两个表中的每个记录都可以与另一个表中的任意数量的记录(或没有记录)相关。例如，如果您有几个兄弟姐妹，那么您的兄弟姐妹也是如此(有许多兄弟姐妹)。多对多关系需要第三个表，称为关联表或链接表，因为关系系统不能直接容纳关系。

建立关系
当您开始建立相关表之间的关系时，您可能已经非常熟悉这些数据了。因此，此时的关联比开始时更明显。数据库系统依赖于在两个表中找到的匹配值来形成关系。找到匹配项后，系统将从两个表中提取数据以创建虚拟记录。例如，您可能希望查看特定作者编写的所有书籍。在这种情况下，系统将匹配图书和作者表之间的值。重要的是要记住，大多数情况下，生成的记录是动态的，这意味着对虚拟记录所做的任何更改通常都将返回到底层表。

这些匹配值是主键和外键值。(关系模型不要求关系基于主键。您可以使用表中的任何候选键，但使用主键是公认的标准。)您在第2部分中了解了主键—主键唯一标识表中的每个记录。a外键简单地说，就是一个表在另一个表中的主键。因此，您没有什么可做的—只需将主键字段作为外键添加到相关表中即可。

唯一需要考虑的是外键字段必须与主键具有相同的数据类型。某些系统允许此规则的一个例外，并且允许数字与自动编号字段之间的关系(例如SQL Server中身份访问中的自动编号)。此外，外键值可以为Null，尽管建议您在没有非常具体的原因的情况下不要将外键保留为Null。您可能永远不会使用需要此功能的数据库。

返回到您的示例表，并根据需要开始输入外键。(继续使用纸面列表—在数据库系统中实际创建表还为时过早。在纸上改正错误要容易得多。)请记住，您要将主键值添加到相关表中。简单地回忆一下实体之间的关系，剩下的就容易了:

• 书籍与类别有关。
• 书籍与出版商有关。
• 书籍与作者有关。
• 作者与邮政编码相关。
• 邮政编码与城市相关。
• 城市与州有关。

这个特定步骤不是用石头写的，您可能会发现在规范化过程中添加外键更容易。将字段移动到新表时，可能会将新表的主键作为外键添加到原始表中。但是，在继续规范化剩余数据时，外键通常会发生更改。您可能会发现，在所有表完全规范化之后，一次完成所有这些任务更有效。

让我们从Books表开始，一次遍历每个表，此时该表只有三个字段。具体而言，将“作者”、“类别”和“发布者”表中的主键添加到图书中。完成后，“帐簿”表有七个字段:
书
标题(主键)
国际标准书号(主键)
价格
名作者。名字多对多
作者。姓多对多
类别( FK )类别。类别多对多
出版社。出版商一对多

请记住，Authors表中的主键是基于名字和姓氏字段的复杂键。因此，必须将这两个字段添加到“帐簿”表中。请注意，外键字段名称包含FK后缀。添加后缀提高了可读性，并且是自文档化的。如果以外键的名称标识外键，您可能会发现跟踪外键更容易。如果主键和外键的名称不同，也没关系。

存在三种关系:书籍与作者、书籍与类别和书籍与出版商。您可能不太清楚的是其中两种关系的问题:

• 给作者的书:一本书可以有多个作者。
• 图书分类:一本书可以有多个类别。

这两种关系表示多对多关系。前面我们已经告诉过您，表不能直接适应这些关系，需要第三个链接表。(图书与出版商之间的关系是一对多的关系，就像目前所说的那样。) )

新发现的两种多对多关系都需要一个链接表，其中包含每个表中的主键作为外键。新的连结资料表为:
图书作者
书名。标题一对多
书。一对多
名作者。名字一对多
作者。姓氏一对多
 
图书分类
书名。标题一对多
书。一对多
类别( FK )类别。一对多类别

不需要更改“类别”、“作者”或“发布者”表。但是，必须从帐簿中删除名为fk、LastNameFK和CategoryFK的外键:
书
标题(主键)
国际标准书号(主键)
价格
出版社。出版商一对多

现在，让我们转到Authors表，该表当前有两个字段。每个作者都与ZIPCodes表中的邮政编码值相关联。但是，每个邮政编码可能涉及多个作者。要适应这种一对多关系，请将ZIPCodes表中的主键作为外键输入到Authors表中:
作者
名字(主键)
姓氏(主键)
邮政编码。邮政编码一对多

此时，您已经准备好处理剩余的地址组件。看到它们被分成表很奇怪，但这是通过BCNF对数据进行正常化的结果。每个邮政编码值将具有一个相应的城市和州值。每个城市和州的值将只在其相应的表中输入一次。zipcode和城市表需要外键字段来适应这些关系:
邮政编码
邮政编码
城市。城市一对多
 
城市
城市(主键)
州。一对多状态
 
州
状态(主键)

从一点到九点
最后，您有九个表:图书、作者、类别、出版商、邮政编码、城市、州、图书作者和图书类别。图一在此过程结束时，显示示例图书数据库的图形表示。很难想象一个简单的数据表可以分成九个。

图一

原始表现在需要九个表。

由于示例的简单性，您可能想知道这种关系业务如何帮助您。看起来您仍然以外键的形式存储冗余数据，只是不同而已。那是因为我们的表现在只有几个字段。试着想象一张有十几个字段的桌子。当然，您仍然必须将该表的主键存储为相关表中的外键值，但这最多可能构成一个或两个额外字段。与为每个记录添加该表中的所有十几个条目的替代方案相比。

关系数据库:定义数据库表之间的关系

标签：作者   一对多   显示   跟踪   告诉   table   div   alt   输入