副問合せ
SELECT、INSERT、DELETE等のSQLを使用する際にWHERE句の条件として別のSELECT文を指定すること。
副問合せとして使用するSELECT文により解釈する順番が異なるので注意すること。
先頭で記述されるSELECT等を副問合せに対して主問合せと言う。
副問合せ
副問合せが主問合せで使用しているテーブルの属性を使用していない場合がこれにあたる。
解釈する順番としては副問合せ→主問合せの順となる。
SELECT 受注番号 FROM 受注テーブル WHERE 得意先コード IN (SELECT 得意先コード FROM 得意先テーブル WHERE 担当者 = '田中')
※得意先テーブルから担当者が「田中」の得意先コードを取得し、それをキーに受注テーブルから受注番号を取得する。
副問合せの結果が複数行となる場合は条件としてINの他に以下のようなものがある。
| IN | 副問合せと一致 | |
| ALL | 副問合せの全ての結果と比較して大きい（あるいは小さい） | |
| SOME | 副問合せのいずれかの値よりも大きい（あるいは小さい） | |
| ANY | SOMEと同じ。副問合せのいずれかの値よりも大きい（あるいは小さい） |
また、副問合せの結果が単一行となるような場合は条件として指定できるのは比較演算子のみとなる。
SELECTのWHERE句のほかにもFROM句やHAVING句、UPDATE句などでも使用できる。
相関副問合せ
副問合せの一種だが、解釈順番が主問合せ→副問合せの順となる。
相関副問合せの条件は主問合せのFROM句で使用しているテーブルを副問合せで使用すること。
主問合せの結果が存在しないと副問合せが実行されないため、条件としてはINやEXISTSが使用される。
(INとEXISTSは同じ結果を得る事が可能だが、一般的にはEXISTSのほうが処理が早いとされている。）
SELECT 受注番号 FROM 受注テーブル X WHERE EXISTS (SELECT 得意先コード FROM 得意先テーブル WHERE 得意先コード = X.得意先コード AND 担当者 = '田中')
※受注テーブルからレコードを取得し、レコードの得意先コードと得意先テーブルの得意先コードが一致、
かつ担当者が「田中」のレコードが存在する場合に受注番号を取得する。
SQLの標準化
SQLはもともとRDBMSベンダー毎に独自実装されていたが、1986年のANSIの標準化から始まり複数回の標準化が行われている。
しかし、標準化の遅れ、市場の拡大、既に独自構文を使用しているユーザへの互換性の維持等の理由により各RDBMSベンダー毎の対応度はバラバラ。
以下に代表的な標準化規格と代表的な改訂内容を示す。
SQL86(1986年)
別名SQL87。ANSIによって策定された最初の標準化規格。
87年にISOにより批准(つまり同意、確認)された。
DML、COBOL,FORTRAN,PL/Iへの埋め込みSQL仕様の策定。
SQL/PSM(1996年)
ストアドプロシージャ(DB側に一連の処理を登録し、通信回数の削減、処理の効率化を図る機能)の対応。
ER図
実体関連図（Entity-Relationship）のこと。
概念データモデルを作成する際に使用する。
UMLでいうところのクラス図みたいなもん。
ER図はエンティティ名（一般的にはテーブル名になる）と属性名（一般的にはカラム名になる）からなるエンティティと、
エンティティ同士の関連を表すリレーションシップから構成される。
多重度について
リレーションシップにはエンティティ間の多重度を明記するべきである。
多重度は一般的には次の４つを考慮しておけばよい。
1対0または1
1対1
1対多（多は0以上）
1対多（多は1以上）
多重度が多対多になる場合
これは非正規系であることを示し、条件からデータを絞り込めない可能性が出てくるため設計上も実運用上もよろしくない。
このような多対多のリレーションシップがある場合は、そのリレーションに対して新たにエンティティを追加することで1対多のリレーションシップになるようにする。
項目間の従属性２
多値従属性
ある項目Xが決定すると、2つ以上の項目Yが自動的に決まること。
例えば、名前、趣味を要素とするテーブルがあった場合、名前＝太郎とすると趣味が「読書、音楽鑑賞」など2つ以上出てくるケースを指す。
表記は名前をX、趣味をYとすると X→→Y と記載する。
また、自明でない多値従属性と言われた場合は、項目Xが決まると独立する別の項目、項目Y,項目Zが同時に決まるような場合を指す。表記はX→→Y|Zとする。
ついでに言うと、多値従属性の被決定項が1つの場合が関数従属性である。
結合従属性（情報無損失分解）
リレーションが分解可能でかつ分解したリレーションを自然結合した時に分解前のリレーションを復元できること。
元のリレーションをR、Rの全属性集合をX、分解後のリレーションをR1、R2、…、その全属性集合をX1、X2、…とした場合、以下の関係が成立する。
R = R1 * R2 * …
X = X1 ∪ X2 ∪ …また結合従属性を持つような分解を情報無損失分解という。
関数従属性を持つ場合は結合従属性を持った分解が可能。
（十分条件であり必要条件ではない。つまり結合従属性があるリレーションを自然結合しても関数従属性があるとは限らない。）
更新時異常
正規化が不十分である場合に操作を行った場合に発生しえる異常状態のこと。
冗長項目が存在する状態でのレコードの削除、追加などによるNotNull?制約違反、整合性異常などがこれにあたる。
強エンティティと弱エンティティ
エンティティ＝テーブルだと思って差し支えない。
テーブルAのレコードが無くなると自動的にテーブルBの関連するレコードも無くなってしまうような関係においてテーブルAを強エンティティ、テーブルBを弱エンティティという。
項目間の従属性１
関数従属性
あるテーブル上で項目Xが決定すると、項目Yが自動的に一意に決まること。
これを「項目Yは項目Xに関数従属している」といい、X→Yと表す。
関数従属性には以下に示す推測論が成立する。
| 反射律 | YがXの部分集合の場合X→Yが成立 |
| 増加律 | X→Yならば{X,Z}→{Y,Z}が成立 |
| 推移律 | X→YかつY→ZならばX→Zが成立 |
| 擬推移律 | X→Yかつ{W,Y}→Zならば{W,X}→Zが成立(推移律の拡張) |
| 合併律 | X→YかつX→ZならばX→{Y,Z}が成立(分離率の逆) |
| 分解律 | X→{Y,Z}ならばX→YかつX→Zが成立(合併律の逆) |
部分関数従属と完全関数従属
あるテーブル上の項目がX{X1,X2,X3}→Yの場合。
{X1,X2}→Yや{X2,X3}→YなどXの全ての要素を用いなくても関数従属性が成立するものを部分関数従属。
Xの全ての要素を用いて初めて関数従属性が成立するものを完全関数従属という。
RDBのキー関連用語
スーパーキー（Super Key）
タプルを一意に識別できる属性集合のこと。
一意にさえできればよいので属性の組み合わせでもよい。
候補キー（Candidate Key）
スーパーキーの中でどれか一つでも欠けるとレコードが特定できない組み合わせのことを候補キーとよぶ。
つまり候補キーは決まれば必ずレコードを確定できる組み合わせの中で極小な組み合わせのことである。
つまり主キーが2つの属性の組み合わせであった場合、「極小の組み合わせ」という制約から他に候補キーがあるとした場合でも、それは2つの属性の組み合わせであり3つ以上の組み合わせや単一の値にはなりえない。
候補キーの名前の由来は「主キーの候補になる」ことから来ているらしい。
候補キーにNULLを許すか。許す派と許さない派が両方存在しているため、一概には言えないが現状許す派が多いみたい。
ただ、NULL値を許すと主キーの条件から外れる為、「候補」キーという名前に反するのではないかとかなんとか。。。
非キー属性
どの候補キーにも含まれない属性のこと。
主キー（PrimaryKey?)
リレーションの中に複数候補キーが存在する場合に主に使用する候補キーのこと。
主キーはリレーションに１つだけ設定することができ、一意性制約（同じ表の中で重複してはいけない）とNotNull?制約（NULL値の設定は不可）という条件がかかっている。
候補キーの説明にも書いたとおり、候補キーの定義上はNotNull?制約が強制ではないため「主キーは候補キーのうちのどれか」っていうのはおかしいんじゃない論争がある。
外部キー（Foreign Key）
他のリレーションの主キー（または候補キー）を参照する項目のこと。
概念データモデルから関連型データモデル（論理データモデル）に落とし込む際に、
エンティティはリレーションをリレーションシップは外部キーに対応付けられる。
リレーション間の関係（1対1か1対多か等）によってどちらのリレーションの主キー（あるいは候補キー）を外部キーとして組み込むのが適切かは変化する。
