SQL Server 2008：2个表可以具有相同的复合主键吗？

Question

在这种情况下，表Reserve_details和Payment_details;这两个表是否具有相同的复合主键（clientId, roomId）？

或者我应该合并2个表，使它们成为一个：

clientId[PK], roomId[PK], reserveId[FK], paymentId[FK]

Answer 1

  

在这种情况下，表格 Reserve_details和Payment_details; 这两个表是否具有相同的复合主键（clientId, roomId）？

是的，你可以，它在关系数据库中经常发生。

• （你没有设置那个标签，但是因为（a）你正在使用SQL Server，而且（b）你有复合键，它表明了一个关系数据库方向的移动，我正在做这个假设。）

在任何特定情况下，是否应该是一个单独的事情。然后进入设计;造型;正常化。

  

或者我应该合并2个表，以便它们成为一个：
  clientId[PK], roomId[PK], reserveId[FK], paymentId[FK]？

好的，所以你意识到你的设计并不完全健壮。

这是一个规范化问题。它不能在只那对表上回答，因为：

• 规范化是一个整体问题，所有表格都需要在一个练习中一起考虑。

• 该练习确定了键。随着PK的变化，子表中的FK将发生变化。

• 您详细说明的结构是记录归档系统，而不是一组关系表。它充满了重复和混乱（事实 ¹ 没有明确定义）。

• 您似乎犯了在每个文件上标记ID字段的经典错误。 （a）削弱了建模练习（因此遇到了困难）和（b）保证RFS而不是RDb。

解决方案

首先，我要说答案中的详细程度受限于问题中给出的详细程度。在这种情况下，由于您提供了很好的细节，我能够对您的数据做出合理的决定。

如果可以的话，比讨论和纠正一对或另一对文件更容易纠正它们的全部内容。

• 需要对各种文件进行规范化（＆＃34;合并＆＃34;或分开）

• 需要对各种重复字段进行规范化（与相关事实一起定位，以便消除重复）

• 需要澄清和建立各种事实 ¹ 。

请考虑一下：

• Reservation TRD

  • 这是一个IDEF1X模型，在Table-Relation级别呈现。 IDEF1X是关系数据库建模的标准。请注意每一个小嘀嗒声;缺口;并标记;乌鸦脚;实线与虚线;广场与圆角;意味着非常具体和重要的东西。请参阅IDEF1X Notation。如果您不理解符号，您将无法理解或工作模型。

• 谓词非常重要，我已经为你提供了。

  • 如果您想了解有关Predicates的重要关系概念的信息，以及如何使用它来理解和验证模型，以及如何用业务术语对其进行描述，请访问this Answer，向下滚动（直到找到谓词部分，然后仔细阅读。

假设

我做了以下假设：

• 鉴于是2015年，预订客房时，酒店需要信用卡信息。它构成了预订的基础。

• 客房独立存在。 RoomId是愚蠢的，因为所有房间都已经由RoomNo唯一标识。 PK是( RoomNo ).

• 客户独立存在。

  • 真正的标识符必须是(NameLast, NameFirst, Initial ... ),加上可能的StateCode。否则，您将拥有重复行，这在关系数据库中是不允许的。

  • 但是，该密钥太宽而无法迁移到子表 ² ，因此我们添加 ³ 代理{ {1}}制作PK，并将真正的标识符降级为AK。

• CreditCards属于客户端，您希望它们只识别一次（不是每次交易）。 PK是( ClientId ),

• 预订适用于房间，它们不是孤立存在的，而是独立存在的。因此，预订是房间的孩子，PK是( ClientId, CreditCardNo ).如果房间不是整天，如果是短期会议，联络等，则可以使用( RoomNo, Date ).

  < / LI>

• 预订可能会或可能不会进展。 PK与父母相同。这样每个预订只允许一次预订。

• 付款也不是孤立存在的。付款仅适用于预订。

  • 付款可能是针对ReservationFee（针对＆＃34;没有节目＆＃34;），或针对已填写的预订，以及额外内容。我会留给你研究持续时间的变化;支持多次付款（针对预订）。

  • PK是父级的标识符，Reservation，加上序列号：DateTime

关系数据库

您现在拥有一个关系数据库，其级别为（a）完整性（b）功率和（c）速度，每种方式都超出了记录文件系统的功能。请注意，只有一个( RoomNo, Date, SequenceNo ).列。

注意

1. 数据库是关于现实世界的事实集合，仅限于应用程序所涉及的范围。

2. 证明使用代理人的单一原因。

3. 代理人总是一个补充，而不是替代。不能放弃使行独特的真正密钥。

请随时提出问题或发表评论。