SeatNum n'est pas un type de clé. Un siège est un siège est un siège. Autrement dit, il n'y a pas de différenciation entre les sièges. Même les concepts tels que «siège de l'allée» et «siège de la fenêtre» ne dérivent pas de n'importe quel attribut du siège lui-même. Dans un vol, la valeur de Seatnum doit être unique, mais cette unicité limitée est à peine suffisante pour en faire un candidat pour keyness.
Comme vous le dites, pratiquez quelques commentaires supplémentaires. Le nom de votre table suggère que la table contient une liste de passagers, mais ConfirmationNum, FlightNum et SeatNum décrivent, pas un passager, mais une relation plusieurs-à-plusieurs entre un passager et un vol (ou un voyage). Un vol peut être composé de nombreux passagers et un numéro de réservation peut faire référence à un voyage d'une ou de plusieurs étapes de vols.
Ainsi, les champs ConfirmationNum, FlightNum et SeatNum on trouverait plus logiquement dans une table d'intersection comme celui-ci:
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
);
Le tableau des passagers consisterait des données des passagers qui ne varie pas d'un vol à ou voyage voyager. Un numéro de confirmation pourrait bien désigner plusieurs passagers différents - une famille ou une équipe de football voyageant ensemble - de sorte que la clé primaire de ce tableau serait une clé composite composée des quatre champs comme indiqué.
Même s'il est vrai qu'une clé de substitution ne devrait avoir aucune signification commerciale, il est également vrai que cette règle est largement ignorée. Vous avez un identifiant unique parfaitement bien, alors pourquoi ne pas l'appeler "numéro de confirmation" ou "numéro de compte" ou tout autre nom significatif?