将具有相同主键的两个表规范化为 3NF

Question

我目前有两个表主键相同，我可以让这两个表主键相同吗？

所有的表格都是第三范式

Ticket:                  
-------------------
Ticket_id* PK
Flight_name*  FK
Names*
Price
Tax
Number_bags

Travel class:
-------------------
Ticket id * PK
Customer_5star
Customer_normal
Customer_2star
Airmiles
Lounge_discount
ticket_economy
ticket_business
ticket_first
food allowance
drink allowance

数据库中的其余表如下

乘客：

名字* PK 信用卡号 Credit_card_issue 票号 * 地址

航班：

航班名称* PK 航班日期 Source_airport_id* FK Dest_airport_id* FK 资源 目的地 Plane_id*

机场：

Source_airport_id* PK Dest_airport_id* PK Source_airport_country Dest_airport_country

飞行员：

飞行员姓名* PK 平面编号* FK Pilot_grade 月 飞行小时数 评分

飞机：

Plane_id* PK Pilot_name* FK

Answer 1

这并不是一个答案，但它变得太长了，无法发表评论......

听起来并不苛刻，但您的模型存在一些严重缺陷，您可能应该将其带回绘图板上。

例如，考虑一下如果乘客购买第二张机票会发生什么。乘客表不应包含任何对票的引用。也许乘客可以拥有不止一张信用卡？信用卡不应该在他们自己的桌子上吗？这同样适用于地址。

为什么 Airport 表包含真正有关目的地（或路径/行程）的信息？您已经在航班表中记录了行程信息。在我看来，Airport 表应该包含与特定机场有关的信息（如名称、位置？、IATA 代码等）。

飞行员可以只与一架飞机相关联吗？听起来不太可能。 Pilot 表不应包含有关飞机的信息。

Planes 表不应包含有关飞行员的信息，因为一架飞机肯定可以连接到多个飞行员。

等等……很可能还有其他问题，但这些提示应该让你思考一下。

唯一对我来说看起来不错的表格是 Ticket 和 Flight。

Answer 2

主键相同：

是的，可以有多个具有相同主键的表。无论是在原则上还是在良好实践中。我们声明一个主列集或其他唯一列集，以说明这些列（及其超集）在表中是唯一的。在这种情况下，声明这样的列集。这种情况经常发生。

例如：一个典型的合理案例是“subtyping”/“subtables”，其中由一个表的候选键标识的实体总是或有时也是由另一个表中的相同值标识的实体。 （如果总是那么一个表的候选键值也在另一个表中。所以我们会声明一个从一个表到另一个表的外键。我们会说一个表的实体类型是另一个表的子类型。）另一方面，有时使用一个表同时具有两种属性，而不使用不适用于一种属性的属性。 （即通过 NULL 或表示种类的标签。）

您是否应该拥有相同主键的情况取决于适用于您的特定情况的良好设计的其他标准。你需要学习设计，包括规范化。

例如：所有键都是简单的，3NF 意味着 5NF，因此，如果您的两个表在每个状态下都具有与 only 和简单主键相同的一组值，并且它们都处于 3NF 中，那么它们的连接包含与它们完全相同的信息分别地。不过，为了设计的清晰性、更改的可能性或基于使用的性能，也许您会将它们分开。你没有提供这些信息。

重新正规形式：

普通形式适用于表格。表的最高范式是独立于任何其他表的属性。 （尽管您可能会根据可供选择的表格和表格来选择该表格。）

为了规范化或确定表的最高范式，需要（通常）知道其中的所有函数依赖关系。 （对于 BCNF 之上的普通形式，还要加入依赖项。）你没有给他们。它们取决于表的含义（即在任何给定情况下如何确定其中的行）以及可能出现的情况。你没有给他们。您期望我们可以在不提供此类信息的情况下告诉您表格的正常形式，这表明您不了解规范化并需要自学它。

正确的设计也需要这些信息，以及通常情况下可能出现的所有有效状态。即给定表之间的约束。你没有给他们。

Answer 3

拥有两个具有相同键的表与在规范化中消除冗余的想法背道而驰。

除此之外，这些表在 1NF 和 2NF 中吗？

从Names 字段来看，我建议table1 不是。如果多个名称可以属于一个票证，那么您需要一个新表，最有可能具有ticket_id,name 的复合键。