まとめ

• SELECTには、リレーショナルな操作とそうでない操作の両方が含まれる

• リレーショナルモデルの垣根を縦横無尽に飛び越えることができてしまう

  • ゆえに扱いが難しい

SELECTはSQLの心臓部

SELECTの本質

SELECTの強大さ

これはSQLそのものだ。SELECTのパーサなんて開発したら、RDBそのものを開発することになる！ (Bill Karwin)

• 誇張は入っているがあながち間違いでもない

データを取得する唯一の手段

• SELECTはSQLにおける心臓部

  • RDBにおいて、テーブルからデータを参照できるのはSELECTのみ
  • リレーションの演算相当の操作はすべてSELECTにより行われる

SELECTの基本構造

• 論理的な評価順(再掲)

  1. FROM句

     • テーブルのリスト(直積)

  2. WHERE句

     • 検索条件(制限)

  3. SELECT句

     • カラムのリスト(射影)

SELECT七変化

• すべてがSELECTという万能APIに詰め込まれている
• 文脈や用法により意味が変化する点が厄介

集約関数

関数の有無だけで意味が変わる

• select list

  • SELECT句におけるカラムのリスト
• select listに特定の関数があるかないかによって出力の形式が変わる

• 特定の関数: 集約関数

  • COUNT()とか

COUNTの特殊性

• 空集合を対象としたとき

  • COUNT(): 0

  • その他: NULL

    • SUM()とか
• NULL対策を怠るな(ch.7)

GROUP BYによる集約の書式

• 論理的な評価順 = 書式の順番

  1. (WHERE句)
  2. GROUP BY句
  3. HAVING句
  4. ORDER BY句

• WHERE句の検索条件にマッチしない行は集計対象外となる点に注意

  • 「0件」という集計結果を含めるためには基本形を逸脱しなければならない

    • 相関サブクエリ
    • LEFT OUTER JOIN
    • CASE式

サブクエリ

• 複数のタイプがある

テーブルサブクエリ

• WHERE句の中で IN、ANY(SOME)、ALL句に伴って利用されるもの

  • 【補】EXISTSも

• FROM句に現れるやつも

  • 【補】UNIONやMINUSのオペランドもこれかな

スカラサブクエリ

• select listに現れるやつ

  • サブクエリ結果がスカラ(1行1列)もしくはNULLでないとエラー

行サブクエリ

• サブクエリ結果が1行複数列のもの
• select listには含められない

ビュー

• リレーショナルモデルにおいて、ビューとベーステーブルとに区別はない
• 複雑さ隠蔽
• 水面下の実際は把握しづらくなる

• 性能問題に注意

  • ビューにサブクエリ、UNION、集約関数などが含まれていると問題になりやすい

UNION

• 2つのSELECTを「足せる」

• 2つのSELECTは属性が同じなだけで、中身は似ても似つかないかもしれないことに注意

  • 異なるテーブル
  • 異なる実行計画

組み合わせは自由

• これまで挙げたSELECTは自由に組み合わせられる