はじめに
『データベースをなぜつくるのか』の前半部分を読み、データベース設計の基礎や考え方について学びました。
この記事では、特に勉強になった点をまとめます。
データベースをなぜつくるのか 知っておきたいE-R図とSQLの基礎
Amazonで本書を見る
1章
用語
| 用語 | 英語 | 意味・説明 |
|---|---|---|
| エンティティ | entity | データベースで管理する対象となる「もの」や「概念」。例：ユーザー、商品、注文など。 |
| リレーションシップ | relationship | エンティティ同士の関係性。例：ユーザーが商品を注文する、など。 |
| 図 | diagram | エンティティやリレーションシップの構造を視覚的に表現したもの。ER図など。 |
2章
用語
| 用語 | 英語 | 意味・説明 |
|---|---|---|
| カーディナリティ | cardinality | 多重度。エンティティ間の関連の数の範囲。 |
| オプショナリティ | optionality | 任意性。関連が必須か任意かを示す性質。 |
- カーディナリティ（多重度）: 1 対 1、1 対多、多対多など、エンティティ間の関係の数的な制約。
- オプショナリティ（任意性）: 関連が「必須」か「任意」か（例：必ず関連が存在するか、なくてもよいか）。
カーディナリティ記号（テキストでの便宜的な例）
- 1（1 つだけ）を表す記号：
| - 多（複数）を表す記号：
∈（または|||）
※「多」を表す
∈や|||は、ER 図の枝分かれ線（三本線や鳥の足）をテキスト上で便宜的に表現したものです。本来の ER 図記号とは異なる。これらの記号は、ER 図の「カーディナリティ（多重度）」を示すもので、エンティティ（ボックス）同士を繋ぐ線nの最も外側に付くことで、そのエンティティ側の多重度を表す。
オプショナリティ記号（テキストでの便宜的な例）
- オプショナリティ（任意）を表す記号：
o - オプショナリティ（必須）を表す記号：
|
「オプショナリティ（任意性）」は、カーディナリティ記号の中央寄り（外側のカーディナリティ記号の内側）に付く丸（
o：任意）や縦棒（|：必須）で表現されます。これにより、そのエンティティ側の任意性（必須か任意か）を示す。
ER 図例：カーディナリティ（多重度）
1 対 1（One to One）
1 人の PERSON は 1 つの PASSPORT しか持たず、1 つの PASSPORT も 1 人の PERSON にしか紐づかない。
1 対多（One to Many）
1 人の CUSTOMER は複数の ORDER を持てる。
多対多（Many to Many）
1 人の STUDENT は複数の COURSE を受講でき、1 つの COURSE も複数の STUDENT が受講できる。
ER 図例：オプショナリティ（任意性）
- USER と ADDRESS の関係は「0 以上」なので、ユーザーが住所を持たない場合もある（任意）。
- USER と PROFILE の関係は「1 以上」なので、必ず 1 つ以上のプロフィールが必要（必須）。
主キー・外部キーまとめ
| 用語 | 英語 | 意味・説明 |
|---|---|---|
| 主キー | Primary Key | テーブル内で各行を一意に識別するための列。NULL 不可・重複不可。 |
| 外部キー | Foreign Key | 他テーブルの主キーを参照し、テーブル間の関連（リレーション）を表す。 |
- 主キー（Primary Key）: 各レコードを一意に特定するためのキー。例：ユーザー ID、注文 ID など。
- 外部キー（Foreign Key）: 他のテーブルの主キーを参照し、テーブル同士の関係を作るためのキー。例：注文テーブルの「ユーザー ID」列がユーザーテーブルの主キーを参照する場合など。
3章
データベース設計の手法：トップダウン型とボトムアップ型
| 手法 | 特徴・説明 |
|---|---|
| トップダウン型 | まず全体の業務やシステムの流れを把握し、エンティティや関係を抽出して設計する。 大枠から細部へと設計を進めるため、全体最適や抜け漏れ防止に強い。 |
| ボトムアップ型 | 既存のデータや業務の現場から項目を洗い出し、テーブルや属性を積み上げて設計する。 現場の実態に即した設計ができるが、全体の統一性や最適化には注意が必要。 |
- トップダウン型：業務フローや要件定義からエンティティ・リレーションシップを抽出し、ER図を作成して設計を進める。
- ボトムアップ型：現場の帳票や既存データから項目を集め、テーブルや属性を積み上げて全体設計にまとめる。
4章
正規化とその用語まとめ
| 用語 | 意味・説明 |
|---|---|
| 非正規形 | テーブル内に繰り返し（同じ列が複数回現れる）が存在する状態。 |
| 第1正規形 | 繰り返しが排除され、すべての値が原子値（分割できない値）になっている。 |
| 第2正規形 | 第1正規形を満たし、かつ主キーの一部にのみ依存する「部分従属性」が排除されている。 |
| 第3正規形 | 第2正規形を満たし、かつ主キーに直接依存しない「推移従属性」が排除されている。 |
| 部分従属性 | 複合主キーの一部のみに依存する属性。 |
| 推移従属性 | 主キー→他の属性→さらに別の属性、のように間接的に依存する属性。 |
基本的にはエンティティは第3正規形の形にする。
(パフォーマンス面を考慮した場合は例外あり)
- 部分従属性: 複合主キーの一部のみに依存する属性。
例：
主キーが「学生ID, 科目ID」の複合主キーの場合、「科目名」は「科目ID」にのみ依存しており、学生IDには依存しません。これが部分従属性です。
| 学生ID | 科目ID | 科目名 |
|---|---|---|
| 1 | 101 | 数学 |
| 1 | 102 | 英語 |
| 2 | 101 | 数学 |
- 推移従属性: 主キー→他の属性→さらに別の属性、のように間接的に依存する属性。
例：
主キーが「注文ID」の場合、「顧客名」は「注文ID」→「顧客ID」→「顧客名」と間接的に依存しています。これが推移従属性。
| 注文ID | 顧客ID | 顧客名 |
|---|---|---|
| 1 | 100 | 田中 |
| 2 | 101 | 鈴木 |
5章
インデックス（索引）とは
- **インデックス（索引）**とは、DBMS のテーブルの列（カラム）に設定できる仕組み。
- インデックスを設定すると、
- 「列の値（検索キー）」と「レコード位置」の対応を示すテーブル（索引表）が作られる。
- これにより、検索時に全件を調べる必要がなくなり、検索の効率が大幅に向上する。
イメージ図
| 検索キー（列の値） | レコード位置 |
|---|---|
| 1001 | 1 |
| 1005 | 2 |
| 1010 | 3 |
インデックスは本の「索引」と同じイメージで、目的のデータをすばやく見つけるための仕組み。
導出項目（派生項目）について
-
導出項目とは、他の項目から計算によって得られる項目のこと。
- 例：
金額 = 単価 × 数量
- 例：
- 基本設計の段階では、冗長性を避けるため導出項目は原則としてテーブルに持たせず、削除する。
- 詳細設計の段階では、パフォーマンス（検索や集計の効率）を考慮し、必要に応じて導出項目をテーブルに残す場合もある。
| 項目名 | 内容 | 備考 |
|---|---|---|
| 単価 | 商品 1 つの価格 | 入力項目 |
| 数量 | 注文した個数 | 入力項目 |
| 金額 | 単価 × 数量で算出 | 導出項目（計算で求められる） |
終わりに
データベースについての理解が浅かったですが、今回の学習を通じて多くの気づきがありました。
- これまで何となく描いていたER図の意味や、カーディナリティ・オプショナリティの記号の意味がしっかり理解できました。
- インデックスがなぜ検索を高速化できるのか、その仕組みも納得できました。
- 良い設計を行うためには、やはり基礎知識の積み重ねが大切だと実感しました。
今後は、本書後半部分で実際にSQLiteを使って手を動かしながら、さらに理解を深めていきたいと思います。
参考情報
データベースをなぜつくるのか 知っておきたいE-R図とSQLの基礎
Amazonで本書を見る