0

我正在模拟一家航空公司。我有一张“乘客”表

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 之类的属性也将是 asurrogate key或将被视为 a natural key。

4

2 回答 2

1

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

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

代理键将被引入，除了在 IT 系统中唯一标识每个乘客（但不是“在现实世界中”）PassengerID INT之外，没有任何进一步的商业意义。

于 2016-09-14T06:01:17.767 回答
0

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
);

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

一个确认号很可能是指几个不同的乘客——一个家庭或一起旅行的足球队——所以这个表的主键将是一个由所有四个字段组成的组合键，如图所示。

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

于 2016-09-15T09:07:29.770 回答