データベースの用語
ACID特製
- Atomicity 原子性
トランザクションが実行されるか、実行されないかのどちらかを保証する。 - Consistency 一貫性
データの矛盾がないように一貫性を保証する。 例えば預金システムで、片方の口座は振り込まれたはずなのに、もう片方には振り込まれないなどの矛盾を生じさせない - Isolation 独立性
並列に処理した場合と、順列で処理した場合に同じ結果であることを保証。 - Durability 永続性
トランザクションデータが消えないことを保証。
データベースの関連
テーブル間の関連は、以下のような3種類で表現されます。
* 1対1
* 1対多
* 多対多
多対多を表現する場合は、中間テーブルが必要となります。
例えば以下の場合、Customer1人は、複数の注文(Order)をすることができるので、1対多を表現します。
正規化
- 第一正規化
繰り返し項目が存在しない。 以下のような場合Aさんは、二つのEmailを持っており、第1正規化に違反します。
id | name | Email1 | Email2 | Email3 |
---|---|---|---|---|
101 | Aさん | A@test.com | AA@test.com | AAA@test.com |
102 | Bさん | B@test.com | ||
103 | Cさん | C@test.com |
この場合、以下のように社員テーブルとEmailテーブルに分けます。
社員テーブルとEmailテーブルの間には、1対多の関係があります。
社員テーブル
id | name |
---|---|
101 | Aさん |
102 | Bさん |
103 | Cさん |
Emailテーブル
社員id | Email1 | Email2 | Email3 |
---|---|---|---|
101 | A@test.com | AA@test.com | AAA@test.com |
102 | B@test.com | ||
1033 | C@test.com |
- 第2正規化
主キーの値が決まれば、各項目の値が自動的にきまる。⇒ 主キー以外の項目は、すべて主キーに従属することになります。
例えば以下の場合、主キーは、コースIDとコース日の複合キーで表すことができる。
しかし、Aコースはコースidの101によって一意に判別でき、コース日をキーにする必要はないです。
コース日だけでば、コース名を特定できません。
これを部分従属といい、第2正規化に違反します。
この時の問題点としては、例えば、コース名を変更する際、一部しか変更できずに矛盾が生じる可能性があります。
コースid | コース日 | コース名 | 参加者 |
---|---|---|---|
101 | 2022/1/2 | Aコース | 30 |
102 | 2022/11/21 | Bコース | 30 |
101 | 2022/3/20 | Aコース | 30 |
この場合、以下のようにコースIDを外部キーとして、テーブルを分割します。
コースid | コース日 | 参加者 |
---|---|---|
101 | 2022/1/2 | 30 |
102 | 2022/11/21 | 30 |
101 | 2022/3/20 | 30 |
コースid | コース名 |
---|---|
101 | Aコース |
102 | Bコース |
- 第3正規化
主キー以外の項目の値によって、各項目の値が自動では決まらない。 主キー以外の項目に従属している項目を見つけ、それを別のテーブルに分離します。
インデックス
検索を高速化するための方法です。
* クラスタ化インデックス
フィールドにインデックスを張ると、一定の順番に並べて、ディスクに保存されます。通常は主キーなどに張ることが多いです。
インデックスを張った、フィールドで検索をかけると、高速に検索が可能です。クラスター化インデックスは、テーブルに1つしか張ることができません。
例えば、以下のようにindexが張られたCustomerID_indexで検索すると、高速で検索できます。
SELCT * CustomerTable WHERE CustomerID=551;
非クラスター化インデックス
テーブルとは別に、indexテーブルを持つことができます。1つのテーブルでいくつもの、非クラスター化インデックスを持つことができます。
辞書検索のようなもので、以下の例では、Last Nameを辞書順に並べることで、Last Nameを使ったSQL検索が高速化されます。注意点
インデックスを作成すると、更新や削除の場合、非クラスター化インデックスの並び替えが発生します。そのため、頻繁に更新、削除する場合は遅くなります。
また、小さなテーブルでは、効率が悪くなるのでIndexを張る意味がありません。
ストアードプロシージャ
複雑なSQL分を関数のようにまとめることができます。