1.3関係モデルの基礎

「表（テーブル）」という言葉は日常的に使いますが、関係モデルの理論では関係（リレーション）という数学的に厳密な概念として定義されます。この節では用語を暗記するのではなく、関係モデルの用語がなぜ表の直感的なイメージとずれる場面があるのか、そして候補キーが複数存在するとき、どれを主キーに選ぶべきかという実務の判断につながる形で理解します。

1.3.1関係・タプル・属性・定義域

• 関係（リレーション）＝関係モデルにおいてデータを格納する基本構造で、表（テーブル）に対応する。数学的にはタプルの集合として定義される。タプル＝関係を構成する1件のデータで、表の1行に対応する。属性＝タプルを構成する個々の値の項目で、表の1列（列名）に対応する。
• 定義域（ドメイン）＝ある属性が取り得る値の集合。例えば「性別」属性の定義域が{男性,女性,その他}であれば、その属性にはこの集合外の値は入らない。定義域はデータ型よりも意味的に厳密な制約を表すことがある（例：整数型でも「1〜12の月」という定義域）。
• 次数（degree）＝関係を構成する属性の数（＝表の列数）。濃度（cardinality）＝関係を構成するタプルの数（＝表の行数）。次数は設計時に決まる比較的静的な値、濃度はデータの増減に伴い動的に変化する値という性質の違いがある。

1.3.2候補キー・主キー・外部キー

• 候補キー＝1つの関係の中で、タプルを一意に識別できる属性（または属性の組）のうち、それ以上属性を減らすと一意性が失われる極小性を満たすもの。1つの関係に候補キーは複数存在し得る（例：社員番号とメールアドレスの両方が一意な識別子になり得る）。
• 主キー＝複数存在し得る候補キーの中から、その関係を代表する識別子として選定した1つ。主キーに選ばれなかった候補キーは代替キーと呼ばれる。外部キー＝別の関係の主キー（または候補キー）を参照する属性で、関係間の関連付け（参照制約）を実現する。

あなたは人事システムの論理設計を担当するデータベース設計者で、「社員」関係を設計しています。この関係には候補キーとして「社員番号」「マイナンバー」「社内メールアドレス」の3つが一意性を満たすことが分かりました。ここで「マイナンバーは法的に一意で最も確実な識別子だから主キーにすべきだ」と短絡的に判断するのは危険です。マイナンバーは機微な個人情報であり、参照制約（外部キー）で多数のテーブルから参照される主キーとして扱うと、アクセス制御や監査の負担が増大し、情報漏えい時の影響範囲も広がるという設計上のリスクがあります。また「社内メールアドレスを主キーにする」という案も、組織変更や結婚による改姓でメールアドレスが変更される可能性があるため、外部キーとして多数のテーブルに埋め込まれた値の更新が連鎖するリスクを抱えます。結果として、業務上の意味を持たず、一度発行したら変更されない社員番号（サロゲートキー的な性質を持つ人工キー）を主キーに選定するのが最も安定した設計です。マイナンバーと社内メールアドレスは代替キーとして一意性制約（UNIQUE制約）を保持しつつ、外部キーとしての参照には使わない、という判断がレベル4の設計者に求められます。

1.3.3この節のまとめ

• 関係＝タプルの集合（表）、タプル＝行、属性＝列、次数＝列数（静的）、濃度＝行数（動的）
• 候補キーは複数存在し得て、その中から主キーを1つ選定する。選ばれなかった候補キーは代替キー
• 主キー選定は業務的な変更されにくさ・機微情報の回避を判断基準にする（マイナンバー等の機微情報は代替キーに留め主キーにしない）