関係データベース：教材を選び、集計の単位を確かめる

対象と編集責任

関係設計と問い合わせの意味を学ぶ学部向け順路で、本番管理手順ではありません。例はSQLite3を用い、SQLite3.51.0のメモリー内データベースで確認しました。全行は創作です。著者公開草稿は後の理論用で、初学者用SQLマニュアルではありません。

出発点を選ぶ

三冊を比較する

準備を確認する

成果物を作る六つの段階

自己記録用のチェックであり、評価ではありません。チェック情報は当サイトに送信されません。

1. 行の単位を選ぶ

   この成果物を作成した

   読む範囲: Watt7–10、システム書2章。

   作るもの: 部屋・予約・タグを描き一行の意味を記述。

   確認すること: 部屋IDと予約IDは同じ計数単位ではありません。

2. 依存関係を宣言

   この成果物を作成した

   読む範囲: Watt11–12と関係設計章。

   作るもの: キー、関数従属性、分解の根拠を小さな台帳で書く。

   確認すること: 三行の偶然ではなく、強制する領域規則を述べます。

3. 結合を予測

   この成果物を作成した

   読む範囲: Watt15–16、システム書4.1。

   作るもの: 集計前のLEFT JOIN全行を手書き。

   確認すること: CのNULL拡張行と、同じ人数でも別のA予約を残します。

4. 分母を選ぶ

   この成果物を作成した

   読む範囲: システム書3.6–3.7、SQLite参照。

   作るもの: 部屋別に三つの個数と合計を解釈。

   確認すること: 数え方ごとに別の問いがあり、実行成功は説明を代替しません。

5. 重複度を調べる

   この成果物を作成した

   読む範囲: 追加問題と理論伴読。

   作るもの: タグ結合後の粒度を追い、正当な同値を消さず修復。

   確認すること: 各結合の行数を確認。DISTINCTは一般的修復法ではありません。

6. 再現可能なメモ

   この成果物を作成した

   読む範囲: 弱点を補う教材に戻る。

   作るもの: スキーマ前提、方言、入力、問い合わせ、出力、反例を保存。

   確認すること: NULLと重複が再現できても同時実行・速度は別の主張です。

解答付きの例題

創作SQL例：未対応と未知の値は違う

部屋はA,B,C。予約(id,room,seats)は(1,A,2),(2,A,2),(3,B,NULL)、Cは予約なし。LEFT JOIN後のCOUNT(*)、COUNT(booking.id)、COUNT(booking.seats)、SUM(booking.seats)を部屋別に求めます。

前提

予約IDは一意で非NULL。seatsのNULLは人数不明で、取消やゼロではありません。台帳はこの例で完全、実行中の変更なし。Aの等しい二値を保持し、SQLite3の意味論を使います。

1. Aは二予約に対応し、四出力は2,2,2,4。SUM(DISTINCT seats)は2となり、正当な繰り返しを消します。
2. Bは予約3に対応し1,1,0,NULL。予約は存在しても既知の人数がなく、SUMは非NULL入力がないためNULLです。
3. CにはNULL拡張行一つが作られ1,0,0,NULL。COUNT(*)の1は予約数ではありません。
4. 無予約をゼロ表示する規則を採るとしても、すべてのNULL合計をゼロにすればBの未知を偽の測定にします。

解答と解釈

指定順でA:(2,2,2,4)、B:(1,1,0,NULL)、C:(1,0,0,NULL)。列の意味を説明してから予約数・人数と呼びます。

            WITH room(room_id) AS (VALUES ('A'), ('B'), ('C')),
booking(id, room_id, seats) AS (
  VALUES (1, 'A', 2), (2, 'A', 2), (3, 'B', NULL)
)
SELECT r.room_id, COUNT(*) AS joined_rows,
       COUNT(b.id) AS bookings, COUNT(b.seats) AS known_counts,
       SUM(b.seats) AS seats
FROM room AS r
LEFT JOIN booking AS b ON b.room_id = r.room_id
GROUP BY r.room_id
ORDER BY r.room_id;
          

結果を検証する

単一SQL文を空のSQLiteセッションで実行。BをNULLから0に変えると既知数1、合計0、予約数1。未知とゼロの差を確認します。

前提を変えて考える

追加問題：説明行が測定値を増やす

同じ予約へタグ(1,red),(1,blue),(2,red)を追加。集計前にLEFT JOINするとAはどうなり、予約の測定を保ったままタグ数を付けるには？

1. 予約1が二行、予約2が一行で、Aの結合行3、単純合計2+2+2=6。予約自体は二件、既知人数は4です。
2. タグを予約別一行へまとめ、件数2と1を作ってから一意の予約へ結合。Aの予約2、人数4、タグ3を保ちます。
3. SUM(DISTINCT seats)は2で誤り。予約を先に集約しても、後の多側結合が再複製すれば直りません。

解答と解釈

予約の測定を足す時に一予約一行を保つか、部屋別の予約・タグ集計を別々に作り一対一で結合します。

結果を検証する

中間行を示してAの2/4/3を確認。タグはBの欠測人数を測ったことにはなりません。

よくある誤り

次に進む前に

• 全出力列と行粒度を説明できる。
• 未対応、欠測、測定ゼロを区別できる。
• 誤った結合やDISTINCT修復への反例を作れる。

出典と版の確認

出典確認日: 2026-11-04

• BCcampus: Database Design second-edition contents and access

  2014年第二版、章と公式無料入口を確認。課題は本サイト独自です。

• Authors: Database System Concepts, seventh-edition identity

  著者が第七版、2019年、ISBNを確認。公開付録を全本文と呼びません。

• Authors: seventh-edition contents

  関係言語、設計、トランザクションの章を著者目次で確認。

• Authors: Foundations of Databases online draft

  既存の著者草稿という識別を保持。接続失敗から新年・紙ISBN・再利用許可を推測しません。

• SQLite: built-in aggregate semantics

  COUNTとSUM/NULLは公式仕様で確認。

• SQLite: SELECT and join processing

  LEFT JOINのNULL拡張は公式SELECT資料で確認。本番操作手順ではありません。

提案する学習活動であり、公式の課題や全巻通読の主張ではありません。

編集と選定の方法 →