代理キーの特定

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

私は同意しません - 代理キーは人為的に導入されたキーです - 通常は1つのカラムですが、ビジネス上の意味はありません。

ただし、flightNumとconfirmationNumの両方にはというビジネス上の意味があります。 2つのいずれか（またはその両方）をキーとして使用する場合は、ナチュラルというキーを使用しています。

代理キーは一意に（ではなく、「現実の世界で」）ITシステム内の各乗客を特定する以外の意味任意の更なるビジネスを持っていない導入されるPassengerID INTだろう。

Answer 2

SeatNumはどのような種類のキーでもありません。座席は座席です。つまり、座席の区別はありません。 「通路座席」や「窓座席」などの概念さえ、座席自体の属性に由来するものではありません。フライト内では、Seatnumの値は一意でなければなりませんが、そのような限定的な一意性は、キーの候補の候補にすることはほとんどできません。

これは練習問題ですので、もう少しコメントを許可してください。あなたのテーブル名は、テーブルに乗客のリストが含まれていますが、ConfirmationNum、FlightNumおよびSeatNumは乗客ではなく、乗客とフライト（または旅行）との多対多の関係を記述していることを示しています。フライトは多数の乗客で構成され、予約番号はフライトの1つまたは複数のレッグの旅行を参照することができます。

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

乗客テーブルは、フライトや旅行へのフライトから変化しないでしょう乗客のデータで構成されます旅行する。

確認番号は、家族やフットボールのチームが一緒に旅行しているいくつかの異なる乗客を指すことができます。したがって、このテーブルの主キーは、示されているように4つのフィールドすべてからなる複合キーになります。

また、サロゲートキーにはにはビジネス上の意味が適用されてはいけませんが、このルールは広く無視されています。あなたは完全に良い一意の識別子を持っていますので、なぜ「確認番号」や「口座番号」などの多種多様な重要な名前を呼んでください。