当前位置:Gxlcms > 数据库问题 > 关系数据库:定义数据库表之间的关系

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

时间:2021-07-01 10:21:17 帮助过:26人阅读


  书籍: {标题*,ISBN,价格}
  作者: {名字*,姓氏* }
  邮政编码: {邮政编码* }
  类别: {类别*,说明}
  发布者: {发布者* }
  状态: { State * }
  城市: {城市* }

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

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


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

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

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

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

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


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

让我们从Books表开始,一次遍历每个表,此时该表只有三个字段。具体而言,将“作者”、“类别”和“发布者”表中的主键添加到图书中。完成后,“帐簿”表有七个字段:

标题(主键)
国际标准书号(主键)
价格
名作者。名字多对多
作者。姓多对多
类别( FK )类别。类别多对多
出版社。出版商一对多

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

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

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


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

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

不需要更改“类别”、“作者”或“发布者”表。但是,必须从帐簿中删除名为fk、LastNameFK和CategoryFK的外键:

标题(主键)
国际标准书号(主键)
价格
出版社。出版商一对多

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

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

状态(主键)

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


图一
技术分享图片
原始表现在需要九个表。



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

 

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

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

人气教程排行