Question

我正在建模航空公司代理。我有一张桌子“乘客”

CREATE TABLE Passenger 
(
     confirmationNum INTEGER NOT NULL,
     flightNum       INTEGER NOT NULL,
     seatNum         INTEGER NOT NULL,
     name            VARCHAR(30) NOT NULL,
     phone           VARCHAR(10) NOT NULL
);

如果我是正确的，我会说乘客确认号码和航班号是代理钥匙。我想知道的是，在这种情况下，诸如seatNum之类的属性也将是surrogate key，或者被视为natural key。

Answer 1

我不同意 - 代理键是一个人为引入的密钥 - 通常只有一个列 - 没有商业意义。

但是，flightNum和confirmationNum 在您的模型中都有商业含义。如果您使用两者中的任何一个（或两者一起）作为键，那么您将使用自然键。

代理密钥将是PassengerID INT，除了唯一标识IT系统中的每个乘客之外，它不具有任何进一步的业务意义（但不是＆＃34;在现实世界＆＃34;）。

Answer 2

SeatNum不是任何一种钥匙。座位是座位是座位。也就是说，座位之间没有区别。甚至诸如“过道座位”和“靠窗座位”之类的概念也不是源于座椅本身的任何属性。在一次飞行中，Seatnum值必须是唯一的，但这种有限的唯一性几乎不足以使其成为 keyness 的候选者。

正如您所说，这是一种做法，请允许更多评论。您的表名表明该表包含乘客列表，但ConfirmationNum，FlightNum和SeatNum描述的不是乘客，而是乘客和航班（或旅行）之间的多对多关系。航班可以由许多乘客组成，预订号码可以指航班的一个或多个航程。

所以字段ConfirmationNum，FlightNum和SeatNum最符合逻辑地在交叉表中找到，如下所示：

create table Trip(
  ConfirmationNum  int not null,
  FlightNum        int not null
    references Flights( ID ),
  SeatNum          int not null,
  PassengerNum     int not null
    references Passengers( ID )
  -- Possible other attriutes such as price and departure date
);

乘客表中包含的乘客数据不会因航班或航班而异。

确认号码可以指几个不同的乘客 - 一起旅行的家庭或足球队 - 因此该表的主键是由所示四个字段组成的复合键。

此外，虽然代理键应该没有应用商业含义，但是这条规则被广泛忽略也是如此。您有一个非常好的唯一标识符，为什么不称它为“确认号码”或“帐号”或任何其他各种重要名称？

识别代理键

2 个答案: