関係データベース

このページでは、関係・タプル・属性などの用語、スーパキー・候補キー・主キー・代理キー・外部キーの違い、外部キーと参照制約による表のつなぎ方がわかります。

• 一言で言うと：
  • データを2次元の表で表す関係モデルと、それをコンピュータに載せた関係データベース（RDB）の基本の話
  • 後半は、行を見分けるためのキー（スーパキー → 候補キー → 主キー）と、表どうしをつなぐ外部キーの話

表で表す（関係、タプル、属性、定義域）→ 行を見分ける・表をつなぐ（スーパキー、候補キー、主キー、代理キー、外部キー）→ 長いキーの代わり（代用のキー）

覚え方の軸

• 呼び名は「関係モデル ⇔ 関係データベース」で対応させる
  • 関係 ＝ 表、タプル（組） ＝ 行、属性 ＝ 列
  • 違いは1つだけ注意：関係モデルは同じタプルを許さないが、関係データベースは同じ行を許す
• キーは「広い → 狭い → 1つ選ぶ」
  • スーパキー（行を一意に特定できる属性の組。余分があってもよい）
  • → 候補キー（余分を除いた必要最小限。複数ありうる）
  • → 主キー（候補キーから1つ選ぶ。残りが代理キー）
• NULLを許すかで区別する
  • 主キーは、一意性制約＋NOT NULL（主キー制約）
  • 候補キーと外部キーは、NOT NULLを指定しなければNULLを許す
• 外部キーは「多」の側に置く
  • 1対多なら、「多」側の表に、「1」側の表の主キー（または候補キー）を参照する列を持たせる → 参照制約

関係モデルと関係データベース：データを表で表す（★）

• 関係データベース（RDB：Relational DataBase）：
  • 1970年にコッド博士が提案した関係モデルを基に、設計・構築されるデータベース

① 関係モデル

• 関係モデル：
  • 集合論に基礎を置いた論理データモデル
  • ひとまとまりのデータを、2次元の平坦な表（テーブル）で表す
• 関係：
  • 関係モデルでの表のこと
  • 関係は、タプルの集合
• タプル（組）：
  • 表の各行に入る、1組のデータ
• 属性（アトリビュート）：
  • タプルを構成する項目（列）
• 例：
  • 関係名は“書籍”。属性名は、書籍番号・書名・価格
  • タプルは、（B01、データベース入門、2800）（B02、ネットワーク入門、3000）（B03、SQL練習帳、1800）
• 2次元の平坦な表：
  • 行と列が交わるマスに、1つの値しか入らない形の表
  • 正確には、これを第1正規形の表という

関係モデルの規則（POINT）（★）

• 規則①：

  • 属性名の重複は許されない

• 規則②：

  • タプルや属性の並び順を入れ替えても、同じ関係になる

• 規則③：

  • 関係の中に、同じタプルがあることは許されない

• 規則の例え：

  • 名簿の欄の名前は重ならない（①）、名簿の順番を並べ替えても同じ名簿（②）、同じ人が2行に書かれることはない（③）

② 関係データベース

• 関係データベース：
  • 関係モデルをコンピュータ上に実装したもの
  • 「関係モデルの関係 ＝ 関係データベースの表」と考えてよい

用語対応表

関係モデル	関係データベース
関係	表
タプル（組）	行
属性	列

• 用語の使い分け：
  • 本来は使い分けるべきだが、厳密に考えすぎるとかえって難しくなる
  • 試験でも区別せずに使っている問題があるので、このまとめでも特に区別しない
• 関係モデルと関係データベースの違い（最も注意）：
  • 関係モデルは、関係の中に同じタプルを許さない（規則③）
  • 関係データベースは、表の中に同じ行を許す

③ 属性の定義域（ドメイン）

• 定義域（ドメイン：domain）：
  • 属性が取りうる値の集合
• タプルと定義域の関係：
  • 理論的には、タプルは、同じ特性を持った値の集合（定義域）から、意味を持たせるために1つずつ要素を取り出して作ったデータの組
  • 例えば、定義域「書籍番号」（B01、B02、B03…）、「書名」（データベース入門、ネットワーク入門、SQL練習帳…）、「価格」（1800、2800、3000…）から1つずつ取り出して、（B02、ネットワーク入門、3000）というタプルを作る
• 定義域の例え：
  • 定食屋の「主菜の候補」「副菜の候補」「汁物の候補」から1つずつ選んで1食（タプル）を組み立てる

定義域（ドメイン）の定義

• 関係データベースでのドメイン：
  • データ型が定義域に当たる
  • 日付、金額、数量のように、特定の制約で決まる値の範囲（値域）を持つものを、新しいデータ型として定義できる
• ドメインを定義する利点：
  • 違うデータ項目でも、同じ入力チェックや同じ出力編集ができる
• ドメイン定義の例：
  • 整数値で、かつ非負（0以上）のドメイン「数量（SURYO）」

CREATE DOMAIN SURYO AS INTEGER
       CHECK (VALUE >= 0)
CREATE TABLE 在庫
(商品番号  CHAR(5),
 在庫数    SURYO,
 発注点    SURYO)

• 定義例の読み方：
  • INTEGERは、整数を表すデータ型
  • CHECK (VALUE >= 0)は、入る値が非負（0以上）かどうかのチェック（VALUEはドメインに入る値を指す）
  • 在庫数と発注点の2つの列に、同じSURYO型を使える（どちらにも0以上のチェックがかかる）
  • CREATE TABLE文は後の「データ定義言語」で扱う

関係データベースのキー：行を見分ける、表をつなぐ（★）

• キーの種類：
  • 表の中の行を一意に識別するためのキー（スーパキー、候補キー、主キー）
  • 別の表を参照して関連付けるための外部キー

① スーパキー

• スーパキー（super key）：
  • 表の中の行を一意に特定できる属性、あるいは属性の組
  • 極端な例では、表の中に同じ行がなければ、すべての属性を指定してもかまわない（余分な属性が含まれていてもよい）

② 候補キー

• 候補キー（candidate key）：
  • スーパキーのうち、余分な属性を含まず、行を一意に識別できる必要最小限の属性で構成されるスーパキー
• 一意性制約：
  • 一意性を保証するため、候補キーには、同じ表の中に同じ値があってはいけないという一意性制約が設定される
• 候補キーは複数ありうる：
  • 例えば、下の例の社員表では、社員コードと電話番号（入社時に貸与された携帯の電話番号）が候補キー
• 候補キーとNULL：
  • 一般に、空値は重複値として扱われないので、候補キーの値として空値は許される
• 非キー属性：
  • どの候補キーにも属さない属性

③ 主キー

• 主キー（primary key）：
  • 候補キーの中から、データ管理上（運用面で）最も適切なものを1つ選んだもの
• 代理キー（alternate key）：
  • 主キーに選ばれなかった残りの候補キー
  • 代替キーと呼ばれることもある
• 主キー制約：
  • 主キーには、一意性制約のほか、実体を保証するため空値（NULL）を許さないNOT NULL制約が設定される
  • この主キーが持つ制約を、主キー制約という

キーの包含関係（図）

• スーパキー ⊃ 候補キー ⊃ 主キー
  • 候補キーは、主キーと代理キーに分かれる
• キーの例え：
  • スーパキーは「名前＋住所＋電話番号」のように、余分があっても本人を特定できる組
  • 候補キーは、余分を削った「社員番号」や「社用携帯番号」
  • 主キーは、その中から公式に使うと決めた「社員番号」。選ばれなかった「社用携帯番号」が代理キー

④ 外部キー

• 外部キー（foreign key）：
  • 関連する表の候補キーを参照する属性、または属性の組
• 外部キーの置き方：
  • 2つの表の間に1対多の関係がある場合、「多」側の表に、「1」側の表の主キー（あるいは主キー以外の候補キー）を参照する属性を持たせて、外部キーにする
• 参照制約：
  • 外部キーの値が、被参照表（外部キーによって参照される表）に存在することを保証する制約
• 外部キーの補足：
  • 複数の表を参照する場合は、表の中に複数の外部キーを持つ
  • 外部キーの値は、NOT NULL制約が定義されていなければ、空値（NULL）は許される
• 候補キーを参照する場合：
  • 一般に、外部キーは被参照表の主キーを参照するが、UNIQUE指定された候補キーを参照する場合もある
• 例：
  • 社員表（社員コード、社員名、電話番号、住所、部門コード）
  • 部門表（部門コード、部門名）
  • 社員表の部門コード（D1、D2、D3など）が外部キーで、部門表の部門コードを参照する
  • 属性名の実線下線は主キー、破線下線は外部キーを示す
• 外部キーの例え：
  • 社員名簿の「所属部門コード」欄。部門一覧表にないコード（存在しない部署）は書けない（参照制約）。まだ配属が決まっていない新人なら空欄（NULL）でもよい

代用のキー設定

• 複合キー（連結キー）：
  • 複数の属性で構成される主キー
• 代用のキー（surrogate key）：
  • 複合キーの構成属性が多すぎると、運用面で面倒
  • そこで、連番など意味のない（人工的な）属性を追加して、それを代用のキーにする
  • 複合キーを構成していた属性は、代理キーにする
• 例：
  • 主キーが（年度、店舗コード、伝票番号、行番号）の複合キーだった売上明細表に、連番の明細IDを追加して主キーにする
  • （年度、店舗コード、伝票番号、行番号）は代理キーになる
• 代用のキーの例え：
  • 「学年＋組＋出席番号＋入学年度」で生徒を指すのは面倒なので、「学籍番号」という通し番号を振る

例題（キーを見分ける）

• 問題：
  • 社員表（社員コード、社員名、電話番号、住所、部門コード）で、社員コードと電話番号はどちらも全員違い、空欄もない。同姓同名の社員はいる。①候補キー、②主キーを社員コードにしたときの代理キー、③（社員コード、社員名）はスーパキーか候補キーか、を答えよ
• 答え：
  • ①候補キーは、社員コードと電話番号（社員名は同姓同名がいるので一意にならない）
  • ②代理キーは、電話番号
  • ③（社員コード、社員名）は、行を一意に特定できるのでスーパキー。でも、社員名は余分（社員コードだけで特定できる）なので、候補キーではない

混同しやすいペア

• 関係 ／ タプル ／ 属性
  • 関係は、表のこと（タプルの集合）
  • タプル（組）は、行のこと
  • 属性（アトリビュート）は、列のこと
• 関係モデル ／ 関係データベース
  • 関係モデルは、集合論に基づく論理データモデル。同じタプルを許さない
  • 関係データベースは、関係モデルをコンピュータに実装したもの。同じ行を許す
• 定義域（ドメイン） ／ データ型
  • 定義域は、属性が取りうる値の集合
  • 関係データベースでは、データ型が定義域に当たる（CREATE DOMAINで新しく定義できる）
• スーパキー ／ 候補キー
  • スーパキーは、行を一意に特定できる属性の組（余分を含んでもよい）
  • 候補キーは、余分を含まない必要最小限のスーパキー
• 候補キー ／ 主キー
  • 候補キーは、一意性制約あり。空値は許される。複数ありうる
  • 主キーは、候補キーから1つ選んだもの。一意性制約＋NOT NULL制約（主キー制約）
• 主キー ／ 代理キー
  • 主キーは、運用面で最も適切な候補キー
  • 代理キー（代替キー、alternate key）は、主キーに選ばれなかった候補キー
• 代理キー（alternate key） ／ 代用のキー（surrogate key）
  • 代理キーは、主キーに選ばれなかった候補キー
  • 代用のキーは、複合キーの代わりに追加した、連番など意味のない人工的なキー
• 主キー ／ 外部キー
  • 主キーは、その表の行を一意に識別する（NULL不可）
  • 外部キーは、別の表の候補キーを参照する（NOT NULLがなければNULL可）
• 一意性制約 ／ 参照制約
  • 一意性制約は、同じ表の中に同じ値があってはいけない
  • 参照制約は、外部キーの値が被参照表に存在することを保証する
• 参照表 ／ 被参照表
  • 参照表は、外部キーを持つ側（「多」側）
  • 被参照表は、外部キーに参照される側（「1」側）
• キー属性 ／ 非キー属性
  • キー属性は、候補キーに属する属性
  • 非キー属性は、どの候補キーにも属さない属性
• 複合キー（連結キー） ／ 単一キー
  • 複合キーは、複数の属性で構成される主キー
  • 単一キーは、1つの属性だけの主キー

---

← 06 データベースの目次に戻る