数据库关系 1:1 vs 1:0..1答案

【问题标题】：Database relationship 1:1 vs 1:0..1数据库关系 1:1 vs 1:0..1
【发布时间】：2011-06-12 11:59:33
【问题描述】：

我正在努力学习这些关系。如下所示是否正确：

1) 通过简单地将父母的身份密钥也作为孩子的身份密钥，我将拥有 1:0..1 关系？

2) 为了实现 1:1，我在父表中添加了一个 FK，连接两个 Identity 列？

这就是全部吗？如果我的措辞不准确/不正确，请纠正我。

1:0..1

客户（Id {PK，Identity}，姓名）

客户地址（客户 ID {PK、FK、身份}、街道名称）

FK_CustomerAddress_Customer(CustomerId, Id)

1:1

客户（Id {PK, FK, Identity}, 姓名）

FK_Customer_CustomerAddress（Id，CustomerId）

客户地址（客户 ID {PK、FK、身份}、街道名称）

FK_CustomerAddress_Costumer(CustomerId, Id)

EDIT1：

我相信以上两个都是错误的，解决方案是这样的：（？）

1:0..1

客户（Id {PK，身份}，姓名）

CustomerAddress（CustomerId {PK, FK, UNIQUE}, StreetName）

FK_CustomerAddress_Customer(CustomerId, Id)

【问题讨论】：

我想知道你的意思是1:0..1（“一到零还是一”）。
是的，我的意思是，将编辑。
如果您的意思是客户而不是客户（设计服装的人），请修正您的表格和字段的拼写。并且 ID 对于身份字段来说是一个糟糕的选择。它会导致报告出现问题（报告不喜欢具有相同名称的多个列）并且在连接中很容易出错。请改用 tablenameId。

【解决方案1】：

两个表之间的 1:1 关系意味着每个表中的每个元组都映射到另一个表中的一个元组。这更正式地称为双射。这是 SQL 的一个限制，对于大多数实际目的，双射实际上是不可能在 SQL 数据库中实现的。这是因为 SQL 要求单独更新每个表，因此除非您暂时禁用其中一个约束，否则无法更新两个这样的表。

1:0/1 关系也称为超射（您的第一个示例）。 Surjection 是 SQL 风格的“FOREIGN KEY”约束的标准行为，假设不允许使用空值。约束在关系的一侧始终是可选的。

注意：IDENTITY 属性与您的示例无关。定义关系的是键和外键约束。

【讨论】：

支持可延迟约束的 DBMS 可以仅使用 DDL 强制实施 1:1 关系。如果必要的话，你也许可以通过触发器在 SQL Server 上获得相同的效果，但我现在太累了，无法思考。
是的，您可以使用可延迟的约束来做到这一点。但是，可延迟约束只是可以暂时禁用的约束，以便每次更新时都可以违反约束。换句话说，约束并没有真正作为声明性约束被强制执行。 SQL 对多表约束的支持在这方面极为有限。 SQL Server 中的解决方法是禁用约束，然后重新启用它。
@dportas：“可延迟约束只是一个可以暂时禁用的约束，因此每次更新时都可以违反约束”。这是看待它的一种方式。另一种说法是，可延迟约束是在任意一系列 SQL 语句结束时检查的约束（在事务 0 结束时，而不是在中间某处。
谢谢！我认为我混淆了“独特”和“身份”。什么是真正的身份列？它可以做什么或习惯于 Unique 列不能做什么？在 Management Studio 中制作这些表时，我也遇到了问题。 (1:0) 我可以添加一个客户，但不能向 CustomerAddress 添加一行... (?)
哦.. 当然，我必须删除 CustomerAddressID 上的身份，然后我可以插入。 ..请参阅上面的 EDIT1 .. 那么这是否正确？

【解决方案2】：

外键只能指向一个方向；如果你指出两种方式，你永远不能插入一行，因为一次插入只能在一个表上操作。

因此，您为 1:0,1 列出的解决方案通常用于这两种情况。据我所知，SQL Server 无法在 1:1 约束中添加第二个 1。

【讨论】：

【解决方案3】：

关于这个主题的有趣阅读：

我总是教导失去这个约束 [圆形 FK] 作为另一个标准化的优势，而不是有问题！

【讨论】：

“标准化的优势”是什么意思？一开始就不应该使用 1:1 吗？
@bretddog：这不是我的话，而是休·达尔文的话。点击链接 (dbdebunk.com/page/page/3010532.htm) 并阅读文章！ :)
好的。我还是不明白。比我的水平高一点。既然你用了引号，你应该能够解释.. ;)
@bretddog: "你应该能够解释......例如删除地址会导致客户被删除，在知道客户地址之前无法将客户输入数据库等。FWIW 在我看来Address 是Customer 的属性，而不是 1 :1 两个实体之间的关系。
我明白了。很高兴知道关于删除等，我还没有尝试过..这些表只是举例。我有一个大约 100 列的表，它们在逻辑上属于 3 个不同的类别。所以这就是为什么将它分成 3 张桌子感觉更容易管理，其中两张桌子与第一张桌子的比例为 1:1。我相信我也会将这些“类别”映射到 1:1 父：子域对象，所以也许（？）它也使存储库更容易编写。