SQL応用と正規化

③ GROUP BY

表の各行は、GROUP BY句を指定することによりグループ化することができます。

GROUP BY句でグループ化する列名を指定すると、指定された列が同じ値の行は同一のグループとして扱われます。このようにグループ化された表をグループ表といい、グループ表はAVGなどの関数を用いて、グループごとに集計を行うことができます。

例

社員表を所属コードでグループ化し、その平均年齢を求めます。

```

SELECT 所属コード,AVG（年齢） FROM 社員表 GROUP BY 所属コード

```

所属コード14には田中（32）と鈴木（28）がいるので、平均は30になります。

④ GROUP BYの重要な制約

> GROUP BY句を用いる場合、SELECT句に指定されているすべての非集約列（集合関数以外の列）は、必ずGROUP BY句で指定する列にも含めなければなりません。

なぜでしょうか。

> これは、グループ化されたグループ内に複数のレコードが存在する場合に、SELECT句でどのレコードを代表値として出力するかが一意に決まらずエラーになるからです。

たとえば所属コード14のグループには田中と鈴木の2人がいます。ここで `SELECT 所属コード, 社員名` と書いたら、社員名として田中と鈴木のどちらを表示すべきか決まりません。だからエラーになるのです。

別の視点でとらえると、GROUP BY句を用いる場合、SELECT句で指定できる列は「グループ化された列」と「集合関数を用いた列」に限定されることになります。

⑤ 代表的な集合関数

第2章で学んだ表計算ソフトの関数と同じ名前が並んでいます。考え方も同じなので、あわせて覚えておくと効率的です。

⑥ COUNT関数の2つの書き方

COUNTは、行数を集計するための関数です。

なお、項目に値がない場合をNULL（ヌルまたはナルと読む）として表します。

例

成績表

この差は試験で問われます。「NULLは数えない」という点を押さえてください。

⑦ HAVING

HAVING句を指定すると、GROUP BY句でグループ化された各グループに対し、条件を満たすグループのみを抽出することができます。

HAVING句の機能はWHERE句の機能に類似しており、グループに対する選択処理であると捉えることができます。WHERE句が行を対象にしているのに対し、HAVING句はグループを対象にしています。

例

社員表を所属コードでグループ化し、グループ内の行数が1を超えるグループの所属コードおよび平均年齢を求めます。

```

SELECT 所属コード, AVG（年齢） FROM 社員表

GROUP BY 所属コード HAVING COUNT（＊）>1

```

所属コード14だけが2人以上いるので、この1グループだけが残りました。

この順番が要点

WHEREはグループ化の前、HAVINGはグループ化の後に働きます。だから、

• WHEREでは集合関数を使えません（まだグループができていないので、COUNTもAVGも計算できない）
• HAVINGでは集合関数を使えます（グループができているので計算できる）

という違いが生まれます。

誤った書き方の例

```

SELECT 所属コード, COUNT（＊） FROM 社員表

WHERE COUNT（＊） >= 2 ← エラー

GROUP BY 所属コード

```

WHERE句で集合関数を使っているのでエラーになります。グループごとの件数で絞りたいなら、HAVINGを使うのが正解です。

設例で確かめる——GROUP BY句の制約

> 次のSQLはエラーになる。理由を説明せよ。

> ```

> SELECT 所属コード, 社員名, AVG（年齢） FROM 社員表

> GROUP BY 所属コード

> ```

解答

SELECT句にある社員名が非集約列でありながら、GROUP BY句に含まれていないからです。

所属コード14のグループには田中と鈴木がいるため、社員名として何を表示すべきかが一意に決まりません。

正しく書くなら

前のテーマの令和7年度の設例で、GROUP BY句に3つの列すべてを指定する選択肢が正解だったのも、この制約によるものです。「SELECT句の非集約列は、すべてGROUP BY句に書く」という一文を、確実に押さえておきましょう。

確認してみましょう

> 次の記述の正誤を判定せよ。

> a　HAVING句は行を対象とし、WHERE句はグループを対象とする。

> b　COUNT（＊）は全行数を、COUNT（列名）はその列が空白でない行の数を求める。

> c　GROUP BY句を用いる場合、SELECT句で指定できる列はグループ化された列と集合関数を用いた列に限定される。

解答　a：×　b：○　c：○

• a：×……対象が逆です。WHERE句が行、HAVING句がグループを対象とします。

※ASC（Ascending）は昇順、DESC（Descending）は降順を意味し、省略した場合はASCが指定されたものとみなされます。

例

社員表を年齢の降順で並び替え、社員名および年齢を求めます。

```

SELECT 社員名,年齢 FROM 社員表 ORDER BY 年齢 DESC

```

覚え方……ASCのAはAscend（上る）＝小さい順。DESCはdescend（下る）＝大きい順。省略したらASC（昇順）です。

② 列名や表名に別名をつける（AS）

SQL文において主に列名や表名を一時的に別名で参照や抽出する際に、AS句を用います。

SELECT句やFROM句でAS句を用いて「列名」や「表名」を別名にすることで、わかりやすい別名に変更できます。

また、FROM句内にAS句を用いて、同一の表を複数の別名の表に定義することで、同じテーブル内で関連するレコードを比較することがあります。

構文

```

SELECT ＜列名A＞ AS 新列名A, ＜列名B＞ AS 新列名B

FROM ＜表名＞ AS 新表名1, ＜表名＞ AS 新表名2

```

SELECT文より、「列名A」が「新列名A」となり、「列名B」が「新列名B」になります。また、同一の表を別名に定義することにより、一時的に2つの表（「新表名1」と「新表名2」）のように扱えます。

③ 結果の結合（UNION）

複数のSQL文の結果を結合して1つの結果（表）にするには、UNION句を用います。

基本的な記述方法は、2つのSELECT文をつなげるようにUNION句を書きます。ただし、複数のSQL文の結果を結合して1つの結果に表示するため、「列の数」や「同一列の型」が同じである必要があります。異なるとエラーになります。

構文

```

SELECT ＜列名＞ FROM ＜表名1＞

UNION

SELECT ＜列名＞ FROM ＜表名2＞

```

JOINとUNIONの違い

JOINは横、UNIONは縦——この一言で区別できます。

④ 条件分岐に応じた結果の処理（CASE式）

複数の条件分岐に応じてデータに個別の処理を加えるには、CASE式を用います。

CASEは、WHENとTHENおよびELSEを合わせて使用し、条件分岐（WHEN）とデータの個別処理（THEN）を行います。

WHERE句との違い

> WHERE句でも条件を指定してデータを絞り込むことはできますが、絞り込んだ条件に対しては何らかの処理を加えることはできません。一方、CASE式は複数の条件に応じて異なる処理をさせることができる点が大きな違いです。

WHENで指定する各条件は、相互に排他的である必要があります。

構文

```

CASE 列名 ←この列の値で枝分かれする

WHEN 条件A THEN 処理A ←条件Aに当てはまったら処理A

WHEN 条件B THEN 処理B ←条件Bに当てはまったら処理B

ELSE 処理C ←どれにも当てはまらなければ処理C

END

```

例

商品の価格を「高価格帯」「中価格帯」「低価格帯」に分類します。

```

SELECT 商品ID, 商品名, 価格,

CASE 価格

WHEN 価格 >= 1000 THEN '高価格帯'

WHEN 価格 >= 500 THEN '中価格帯'

ELSE '低価格帯'

END AS 価格帯

FROM 商品表;

```

商品表

出力結果

最後の END AS 価格帯 は、CASE式で対象とした列を異なる名称の列名にするための記述です。CASE式とセットで用いられることが多くなっています。

⑤ WHENの順番に注意

上の例で、スマートフォン（800）は最初の条件（1000以上）を満たさず、2番目の条件（500以上）を満たすので「中価格帯」になります。

もし条件の順番を逆にして、

```

WHEN 価格 >= 500 THEN '中価格帯'

WHEN 価格 >= 1000 THEN '高価格帯'

```

と書くと、ノートパソコン（1200）も最初の条件（500以上）に該当してしまい、すべて「中価格帯」になってしまいます。CASE式は上から順に評価され、最初に一致した条件で確定するためです。

だからこそ「WHENで指定する各条件は、相互に排他的である必要がある」とされているのです。重なりがある条件を書くなら、厳しい条件から順に並べる必要があります。

※1 繰り返し項目とは、1行における1項目に複数の値を含んでいる状態を指します。

※2 主キーが複合キーでない場合、第2正規化は不要となります（第1正規形を満たしていれば、そのまま第2正規形を満たしていることになります）。

③ 3段階を1行でまとめる

④ 正規形の条件（正規度が高い順に見る）

⑤ 「従属する」とは

「BがAに従属する」とは、Aの値が決まればBの値が1つに決まることをいいます。

たとえば「商品コード」が決まれば「商品名」と「単価」が決まります。このとき、商品名と単価は商品コードに従属している、といいます。

正規化の作業は、どの項目がどの項目に従属しているかを洗い出し、従属先ごとに表を分けることにほかなりません。

⑥ 第2正規化が不要な場合

※2の注記が重要です。

> 主キーが複合キーでない場合、第2正規化は不要となります。

第2正規化は「主キーの一部だけから特定できる項目」を追い出す作業です。主キーが1つの項目だけ（単一キー）であれば、そもそも「一部」というものが存在しません。したがって、第1正規形を満たしていれば自動的に第2正規形も満たしていることになります。

この点は、令和7年度の本試験で「主キーが複合キーではないため、第2正規形を満たしている」という形で問われました。

⑦ 正規度の向き

• 正規度が低い……非正規形、第1正規形
• 正規度が高い……第3正規形

正規化を進めるほど表の数は増え、1つの表に含まれる項目は減っていきます。表の数が増えることは、欠点ではなく正規化が進んだ証です。ただし、次で見るとおり、それに伴う代償もあります。

なぜこの2つが必要なのか

• 重複があったら……その値を指定しても行が1つに決まりません。主キーの意味がなくなります
• 空値があったら……その行を指し示す手段がなくなります

どちらも「行を一意に特定する」という主キーの役割から導かれる、当然の要請です。

③ 単一キーと複合キー

主キーは1つの項目から成ることもあれば（単一キー）、複数の項目から成ることもあります（複合キー）。

複合キーが必要になるのは、1つの項目だけでは行が特定できない場合です。受注明細表では、同じ受注番号の行が複数あり（1件の受注で複数の商品を注文するため）、同じ商品コードの行も複数あります（別の受注で同じ商品を注文するため）。2つを組み合わせて初めて1行が決まります。

前のテーマとのつながり……主キーが複合キーかどうかで、第2正規化が必要かどうかが決まります。主キーを特定する作業は、正規化の出発点です。

④ 主キーを見つけるコツ

> 主キーを特定するには、表で管理される情報に「ID」「コード」「番号」などを付加した項目名を探すとよい。

さらに、その項目の具体的な値を見て、各行で値が重複していないかを確かめます。重複していれば、その項目だけでは主キーになれず、他の項目と組み合わせた複合キーになります。

⑤ 外部キー

ある表Aの主キーの項目が別の表Bの項目となるような場合、表Bの項目を外部キーといいます。つまり、他の表の主キーを参照する項目が外部キーとなります。

例

表A（主キー：伝票番号）

表B（外部キー：伝票番号）

表Bに含まれる「伝票番号」と、表Aの主キーである「伝票番号」が同じ項目となっています。この場合、表Bの「伝票番号」は、表Aを参照するための外部キーとして設定できます。

⑥ 参照制約

このように外部キーを設定した場合、次のような制約が課されます。これを参照制約といいます。

• 表Bで外部キーに用いられている項目（列）は、必ず表Aに項目（列）として存在しなければならない
• 表Aから行を削除する際に、表Bから参照されている行は削除できない

2つ目が実務上とくに重要です。

たとえば、まだ受注明細が残っている商品を商品表から削除しようとすると、参照制約によって拒否されます。もし削除できてしまえば、受注明細に「存在しない商品コード」が残り、どの商品を注文したのか分からない状態になってしまいます。

参照制約は、データの整合性をDBMSが自動的に守ってくれる仕組みです。アプリケーションが削除の前にチェックする必要がなくなります。第2節で学んだ「本質でない作業をDBMSに任せる」の一例といえます。

⑦ 主キーと外部キーの関係を図で

• 主キー……指される側。その表の行を一意に特定する
• 外部キー……指す側。別の表の主キーを参照する

第2節で学んだ結合は、この主キーと外部キーの対応関係を使って表をつなぐ操作です。正規化で表を分け、主キーと外部キーでつながりを残し、結合で必要なときに元の形に戻す——この3つが一体の仕組みになっています。

更新には強く、参照には弱い——これが正規化された設計の性格です。

実務では、あえて正規化を崩す（非正規化する）こともあります。たとえば、頻繁に参照される集計値をあらかじめ表に持たせておく、といった手法です。ただしその場合、更新時に整合性を保つ仕組みを自分で用意しなければなりません。

④ 正規化の例——受注伝票を電子化する

紙面で運用していた受注伝票を電子化し、各データ項目をデータベースで管理する場合の正規化を追いかけます。

受注伝票のイメージ

> 受注番号 H151　受注日 1/25

> 顧客コード 1　顧客名 ○商事

> 住所 中央区…　電話番号 ○○○　合計額 26,100円

>

> | 商品コード | 商品名 | 単価 | 数量 | 金額 |

> |---|---|---|---|---|

> | SA1 | A | 200 | 90 | 18,000 |

> | SC4 | C | 135 | 60 | 8,100 |

⑤ 非正規形

受注伝票からデータ項目を抜粋し、表として整理すると次のようになります。

商品コードや商品名などに、1行における1項目に複数の値を含む繰り返し項目が存在するため、正規化されていない表（非正規形）であるといえます。

リレーショナルデータベースでは、非正規形の表を登録することができないため、正規化を進める必要があります。

⑥ 第1正規形

非正規形の表に現れる繰り返し項目を分離して、独立した行にします。第1正規形のデータは、1行における1項目に1つの値が入るようになります。

〈売上表1〉

繰り返し項目は消えましたが、そのかわり受注日や顧客名が何度も繰り返されていることに注目してください。これを解消するのが次の段階です。

⑦ 第2正規形

前のテーマで確かめたとおり、主キーは「受注番号」および「商品コード」（複合キー）です。

次に、主キーの一部である「受注番号」または「商品コード」のみに従属している項目を探すと、

が紐付いていることがわかります。これらの項目を売上表1から分離した結果が第2正規形となります。

〈受注表〉

〈商品表〉

〈受注明細表〉

5行あった表が、2行・4行・5行の3つの表に分かれました。顧客名が何度も繰り返されていた状態が解消されています。

⑧ 第3正規形

第3正規化では、第2正規形において、主キー以外で「ID」「コード」「番号」などを含む項目に注目するとよいでしょう。「顧客コード」がその候補となります。

「顧客コード」に従属する項目を探すと、「顧客名」「顧客住所」「顧客電話番号」が紐付いているのがわかります。これらの項目を受注表から分離した結果が第3正規形となります。

また、第3正規化では計算で求められる項目（導出項目）の削除も行います。受注明細表の「金額」項目が該当するため、この項目を削除します。

〈受注表〉

〈顧客表〉

〈商品表〉

〈受注明細表〉

⑨ 導出項目を削除する理由

「金額」は「単価×数量」で計算できます。表に持っておくと、

• 単価を変えたときに金額を直し忘れると、計算と合わない値が残る
• 同じ情報を2か所に持つことになり、冗長である

という問題が生じます。必要なときにSQLで `単価＊数量 AS 金額` と計算すればよいので、持たないほうが安全です。

なお「合計額 26,100円」も導出項目です。受注明細から計算できるので、表には持ちません。