コンテンツにスキップ

5-1. 演習問題


1-1. RDB の説明として最も適切なのはどれか。

  • A. 表どうしの関係を使ってデータを管理する仕組み
  • B. 画像だけを保存する専用フォルダ
  • C. CSS の色を自動で決める機能

1-2. 主キーの主な役割として最も適切なのはどれか。

  • A. 各行を一意に識別する
  • B. すべての文字を大文字に変える
  • C. 価格を自動で割引する

1-3. 外部キーの説明として最も適切なのはどれか。

  • A. 別テーブルの主キーを参照して関係を表す列
  • B. 必ず数値を 2 倍にする列
  • C. ログレベルを保存する列

1-4. 正規化の主な目的として最も適切なのはどれか。

  • A. 重複を減らし、更新しやすくする
  • B. すべての列名を短くする
  • C. SQL を使わずに済むようにする

1-5. 1 つのセルへ tag1,tag2,tag3 のように複数値を入れることが危険な理由として最も適切なのはどれか。

  • A. 検索・更新・分割がしにくくなるから
  • B. 主キーが必ず文字列になるから
  • C. 行数が自動で 0 になるから

1-6. テーブル設計の最初の一歩として最も適切なのはどれか。

  • A. 管理したい対象と必要な項目を整理する
  • B. 先にインデックス名だけを決める
  • C. すべてのテーブル名を data1, data2 にする

次の文章の空欄を埋めてください。

  1. 同じ種類のデータをまとめた表を (   ) という。
  2. 表の 1 件分のデータを (   ) という。
  3. 各行を一意に識別する列を (   ) という。
  4. 別テーブルの主キーを参照する列を (   ) という。
  5. 同じ事実を何度も書かないように整理する考え方を (   ) という。
  6. 更新時に、同じ情報を複数箇所直さなければならない問題を (   ) 異常という。
解答欄

3-1. 主キーが必要な理由を説明してください。

解答欄

3-2. 外部キーを使うと何が良くなるか説明してください。

解答欄

3-3. 正規化しないと、どのような更新ミスが起きやすいか説明してください。

解答欄

3-4. 要件からテーブル設計へ落とし込むとき、最初に何を整理すべきか説明してください。

解答欄

会員が本を借りる小さなサービスを想定して、テーブル設計を考えてみましょう。

① 要件を読む

次の情報を管理したい。

  • 会員: 会員ID、名前、メールアドレス
  • 書籍: 書籍ID、タイトル、ISBN
  • 貸出: 貸出ID、会員ID、書籍ID、貸出日、返却日

② 1 枚表で考えたときの問題を探す

もし 1 枚の表へ「会員名」「メールアドレス」「書籍タイトル」「ISBN」「貸出日」を全部入れると、どんな重複が起きるか考える。

  • 同じ会員が複数冊借りると、会員名とメールアドレスが重複する
  • 同じ本が何度も貸し出されると、タイトルと ISBN が重複する

③ テーブルを分ける

紙やエディタに、membersbooksloans の 3 テーブルを書き分ける。

次のように、貸出テーブルが他 2 つの ID を参照する形になれば成功:

members
- id
- name
- email
books
- id
- title
- isbn
loans
- id
- member_id
- book_id
- rented_at
- returned_at

④ 関係を確認する

次のような関係を言葉で説明できれば成功:

loans.member_id -> members.id
loans.book_id -> books.id
  • 貸出は「誰が」「どの本を」借りたかをつなぐ役割を持つ
  • 会員情報と書籍情報を loans に直接重複して書かなくて済む

問題1の解答(クリックで開く)

1-1. 正解:A. 表どうしの関係を使ってデータを管理する仕組み

解説

  • A が正しい。RDB は、テーブルとその関係を使ってデータを整理する考え方である。
  • B は誤り。画像保存専用の仕組みではない。
  • C は誤り。CSS の自動設定とは無関係である。

RDB の本質は「表を作ること」だけでなく、表どうしの関係を安全に扱うことにある。


1-2. 正解:A. 各行を一意に識別する

解説

  • A が正しい。主キーは 1 行を他の行と区別するための識別子である。
  • B は誤り。文字の見た目を変える役割ではない。
  • C は誤り。価格計算とも無関係である。

タイトルや名前は重複しうるため、識別専用の列を持つことが重要になる。


1-3. 正解:A. 別テーブルの主キーを参照して関係を表す列

解説

  • A が正しい。外部キーは、別テーブルとのつながりを表すための列である。
  • B は誤り。計算用の列ではない。
  • C は誤り。ログ管理の話ではない。

外部キーがあると、書籍と著者、会員と貸出のような関係を安定してたどれる。


1-4. 正解:A. 重複を減らし、更新しやすくする

解説

  • A が正しい。正規化は、同じ事実を何度も書かない形へ整理する考え方である。
  • B は誤り。列名の短さ自体は目的ではない。
  • C は誤り。正規化しても SQL は必要である。

正規化の目的は、理論を守ることだけでなく、更新漏れや整合性崩れを防ぐことにある。


1-5. 正解:A. 検索・更新・分割がしにくくなるから

解説

  • A が正しい。1 セル 1 値の原則から外れると、部分一致検索や個別更新がしづらくなる。
  • B は誤り。主キーの型とは直接関係しない。
  • C は誤り。行数が自動で 0 になることはない。

1 つのセルへ複数値を混ぜると、あとから扱うロジックが一気に複雑になる。


1-6. 正解:A. 管理したい対象と必要な項目を整理する

解説

  • A が正しい。設計では、まず何を管理したいかをはっきりさせる必要がある。
  • B は誤り。インデックスは設計の後半で考えることが多い。
  • C は誤り。意味の分からない名前は保守性を下げる。

テーブル設計は、SQL 文を書く前の要件整理から始まる。

問題2の解答(クリックで開く)
  1. テーブル

同じ種類のデータをまとめた表である。どの行も同じ意味の項目を持つ。

1 件分のデータである。レコードとも呼ばれる。

  1. 主キー

各行を一意に識別する列である。重複しない値が必要になる。

  1. 外部キー

別テーブルの主キーを参照する列であり、関係を表す入口になる。

  1. 正規化

重複を減らし、更新しやすくするための整理の考え方である。

  1. 更新時

同じ事実を複数行へ書いていると、1 箇所だけ更新して不整合が起きやすい。

問題3の解答例(クリックで開く)

3-1. 主キーが必要な理由

主キーがあると、各行を他の行と区別して安定して参照できる。 名前やタイトルは重複しうるが、主キーは識別専用なので「どの 1 件か」を明確にできる。 そのため更新や参照の対象を間違えにくくなる。


3-2. 外部キーを使う利点

外部キーを使うと、別テーブルとの関係を ID ベースで安全に表せる。 その結果、著者名や会員名を何度も重複して書かずに済み、更新漏れも減る。 また JOIN を使って後から情報を組み合わせやすくなる。


3-3. 正規化しないと起きやすい問題

同じ著者名や電話番号を複数行へ持つと、変更時に全部直す必要がある。 1 行だけ直すと、同じ対象なのに値が食い違う更新ミスが起きる。 これが更新時異常であり、正規化の重要な動機である。


3-4. 設計の最初に整理すべきこと

まず、何を管理したいのかという対象と、その対象に必要な項目を整理するべきである。 たとえば書籍と著者を別対象として見るかどうかで、テーブルの切り方が変わる。 先に要件を明確にすると、後の主キーや外部キーの設計が自然になる。

問題4の解答例(クリックで開く)

③ テーブル分割の例

members
- id
- name
- email
books
- id
- title
- isbn
loans
- id
- member_id
- book_id
- rented_at
- returned_at

会員情報・書籍情報・貸出情報を役割ごとに分けている。 こうすると、会員名や書籍タイトルを貸出のたびに重複して持たずに済む。


④ 関係の説明

loans.member_id -> members.id
loans.book_id -> books.id

loans は「誰がどの本を借りたか」を表す橋渡し役である。 このように関係を外部キーで表すと、データの意味が明確になる。


なぜ 3 テーブルに分けるのか

1 枚表にすると、同じ会員の名前・メール、同じ本のタイトル・ISBN が何度も登場する。 その結果、更新漏れや削除時異常が起きやすくなる。 正規化の基本は、「1 つの事実は 1 箇所に置く」である。


図で見る

members 1 ---- * loans * ---- 1 books

1 人の会員は複数回借りられる。 1 冊の本も複数回貸し出されうる。 loans は、その対応を記録するテーブルである。