はじめに
また試験1ヶ月前までろくに勉強しなかった。。。
今回こそは合格するために、Qiitaで勉強した内容をまとめていきます。
データベース分野の主な学習項目とキーワード
- E-R図
- 正規化
- DBMS
- データベース言語（SQL）
- データベースシステムの運用・保守
データベースのキーについて
関係データベースには、様々な種類の「キー」があります。主なキーについて以下の表に示します。
| キー | 説明 |
|---|---|
| 主キー（Primary Key） | 一つのテーブルには一つの主キーがあり、そのキーによってテーブル内の各行（レコード）が一意に識別されます。主キーはNULL値を持つことができず、必ず一意でなければなりません。 |
| 候補キー（Candidate Key） | 主キーと同じく、テーブル内の各行を一意に識別できる属性（または属性のセット）です。ただし、一つのテーブルには複数の候補キーが存在する可能性があります。主キーは候補キーの中から一つ選ばれます |
| 非キー（Non-Key） | 候補キーでも主キーでもない属性を指します。非キーはテーブル内のレコードを一意に識別する能力がありません。 |
| 外部キー（foreign key） | 複数のテーブルの関係を結び付けるためのキーのこと |
学生テーブルを例に考えてみる
学生テーブル（Students）
| 学生ID | メールアドレス | 名前 | 年齢 |
|---|---|---|---|
| S1 | s1@example.com | 田中 | 20 |
| S2 | s2@example.com | 鈴木 | 21 |
| S3 | s3@example.com | 佐藤 | 22 |
この例では、「学生ID」が主キーとして選ばれています。これは、テーブル内の各行を一意に識別するためのキーです。
「メールアドレス」は候補キーとしています。これは、主キーとしても機能可能なキーですが、この例では「学生ID」が主キーとして選ばれています。
「名前」や「年齢」は非キーです。これらは、行を一意に識別する能力がないフィールドです。
こちらのサイトが具体例があって分かりやすかったです。
完全関数従属、部分関数従属、推関数従属について
データベースの設計において、完全関数従属（Full Functional Dependency）、部分関数従属（Partial Functional Dependency）、推関数従属（Transitive Dependency）は正規化の過程で重要な概念です。
完全関数従属（Full Functional Dependency）
属性 ( A ) が属性セット ( B ) に完全関数従属する場合、( B ) の任意の部分集合に ( A ) が関数従属しないという条件が必要です。
例：
学生ID, コースID → 成績
学生ID, コースID→成績 では、成績は学生ID, コースIDに完全関数従属しています。
部分関数従属（Partial Functional Dependency）
属性 ( A ) が属性セット ( B ) に部分関数従属する場合、( B ) のいくつかの部分集合に ( A ) が関数従属するという条件があります。
例：
学生ID, コースID → 学生名
学生ID, コースID→学生名 では、学生名は学生ID, コースIDに部分関数従属しています。これは、学生名が学生IDだけにも関数従属しているからです。
推関数従属（Transitive Dependency）
属性 ( A ) が属性 ( B ) に関数従属し、属性 ( B ) が属性 ( C ) に関数従属するが、( A ) が ( C ) に直接関数従属していない場合、( A ) と ( C ) の間に推関数従属が存在します。
例：
部署ID → マネージャID
部署ID→マネージャID とマネージャID → マネージャ名
マネージャID→マネージャ名 の場合、部署IDとマネージャ名の間には推関数従属が存在します。
正規化
正規化とはデータベース設計の冗長性を減らし、データの一貫性と整合性を高めるプロセスです。
正規化問題のポイント
- 正規化の目的はデータの重複を排除して、重複更新を避け矛盾の発生を防ぐこと
- 正規化を行っていない場合の理由として考えられるのは、変更がない（少ない）から
- 表が正規系ではない場合、どんな問題が生じる可能性があるか
- 更新時以上（データの矛盾が起こる可能性がある）
未正規化のテーブルにはいくつかの問題が生じる可能性があります。以下に、例として「学生の成績表」を考えます。
未正規化のテーブル：学生の成績表
| 学生ID | 学生名 | 科目ID | 科目名 | 成績 |
|---|---|---|---|---|
| S1 | 田中 | M1 | 数学 | 80 |
| S1 | 田中 | M2 | 英語 | 75 |
| S2 | 鈴木 | M1 | 数学 | 90 |
| S2 | 鈴木 | M2 | 英語 | 88 |
問題1：更新の冗長性
- 田中さんが名前を変更する場合、複数のレコードを更新する必要があります。
問題2：削除の側面効果
- 田中さんの「数学」の成績を削除すると、田中さんに関するその他の情報（英語の成績など）も失われる可能性があります。
問題3：挿入時の制約
- 新しい学生を追加する場合、成績がまだ無い状態での挿入が難しい（NULL値の問題）。
問題4：矛盾の可能性
- 鈴木さんの学生IDが一部のレコードで誤って入力されると、データの整合性が損なわれます（例：S2 と S3 が混在）。
これらの問題は、テーブルを正規化することで解消できます。正規化により、データの冗長性が減少し、データの一貫性と整合性が向上します。
データの冗長性とは、同じ情報がデータベース内で複数回重複して保存されている状態を指します。この冗長性が存在すると、いくつかの問題が生じる可能性があります。
-
更新の冗長性: 同じデータが複数の場所に存在するため、一つの情報を更新する際に複数の場所を同時に更新する必要があります。これが行われないと、データの矛盾（不整合）が生じる可能性があります。
-
データの一貫性の欠如: 冗長なデータが一部だけ更新され、他の部分が更新されないと、データ間の一貫性が失われます。
-
リソースの無駄: 冗長なデータはストレージスペースを無駄に消費し、データベースのパフォーマンスにも悪影響を与える可能性があります。
-
エラーのリスク: データが冗長であると、誤ったデータの挿入や削除が発生しやすく、これがエラーや不整合を引き起こす可能性があります。
正規化を通じて冗長性を排除することで、これらの問題を大幅に軽減または解消することができます。
正規形
データベースにおいて「第一正規形（1NF）」、「第二正規形（2NF）」、「第三正規形（3NF）」といった用語は、通常、テーブルの正規形（Normal Form）を指すことが多いです。これらは、テーブルがどれだけ「正規化」されているかを表す指標です。
第一正規形（1NF）
1NFは、各列が原子的な値（分割できない値）を持つようにテーブルを設計することです。
未正規化のテーブル
| ID | 名前 | 趣味 |
|---|---|---|
| 1 | Alice | 映画, 読書 |
| 2 | Bob | 釣り |
1NF適用後
| ID | 名前 | 趣味 |
|---|---|---|
| 1 | Alice | 映画 |
| 1 | Alice | 読書 |
| 2 | Bob | 釣り |
第二正規形（2NF）
2NFは、1NFを満たした上で、部分関数従属を排除する正規形です。
1NFテーブル
| 注文ID | 商品ID | 商品名 | 数量 |
|---|---|---|---|
| 1 | P1 | ペン | 2 |
| 1 | P2 | ノート | 1 |
| 2 | P1 | ペン | 3 |
2NF適用後
注文テーブル
| 注文ID | 商品ID | 数量 |
|---|---|---|
| 1 | P1 | 2 |
| 1 | P2 | 1 |
| 2 | P1 | 3 |
商品テーブル
| 商品ID | 商品名 |
|---|---|
| P1 | ペン |
| P2 | ノート |
第三正規形（3NF）
3NFは、2NFを満たした上で、推移関数従属を排除する正規形です。
2NFテーブル
| 学生ID | 科目 | 教師 | 成績 |
|---|---|---|---|
| S1 | 数学 | 田中 | A |
| S2 | 数学 | 田中 | B |
3NF適用後
成績テーブル
| 学生ID | 科目 | 成績 |
|---|---|---|
| S1 | 数学 | A |
| S2 | 数学 | B |
科目テーブル
| 科目 | 教師 |
|---|---|
| 数学 | 田中 |
以上のように、各正規形はテーブルの品質を向上させ、冗長性や不整合を防ぐための基準を提供しています。
※この記事の一部はOpenAIのChatGPTによって提供されています。