第1章 データベースの基本概念 — なぜ整理して保存するか
この章で学ぶこと
- データベースを「自分の言葉」で説明できる
- データベースがない場合に起きる典型的な困りごとを 3 つ挙げられる
- 一意性 (ID) がなぜ必要なのかを具体例で説明できる
特になし。プログラミングの基本 (変数・関数) と、表計算ソフト (Excel など) で名簿や売上を管理した経験があれば十分です。
データベースとは何か
データベース (database) を一言で表すと、「整理されたデータの集まり」 です。後から検索・追加・更新・削除しやすい形でデータを保管しておく仕組み、と言い換えてもよいでしょう。
身近な例を挙げると、次のようなものがすべてデータベースに該当します。
| 身近な例 | 何が「整理」されているか |
|---|---|
| 紙の電話帳 | あいうえお順で並んでおり、名前から電話番号を引ける |
| 図書館の蔵書検索 | タイトル・著者・分類で検索できる |
| ネット通販サイトの商品ページ | 商品名・価格・在庫・カテゴリで絞り込める |
| 銀行の口座管理 | 口座番号から残高・取引履歴をたどれる |
ここで重要なのは、「整理されている」= 必要なデータを取り出しやすい状態にある という点です。机の上に紙が散らばっていても情報は持っていますが、それは「データベース」とは呼びません。
データベースがないと何が困るか
データベースの価値は、それがない状態を想像すると見えてきます。たとえば 1000 人分の顧客情報を Excel ファイルで管理する場面を考えてみましょう。
これらの困りごとは、データベースを使うとひと通り解消されます。
| 困りごと | データベースでの解決 |
|---|---|
| 検索に時間がかかる | インデックス (索引) で瞬時に該当データを取り出せる |
| 同時編集ができない | 複数のユーザーが同時にアクセスしても安全に処理できる |
| データの重複・矛盾 | 「同じ情報を 1 箇所にしか持たない」設計 (正規化) で防げる |
| ファイル消失 | バックアップ・複製・障害復旧の仕組みが組み込まれている |
| 誰が変えたか不明 | 操作ログや更新日時を記録できる |
インデックス (index): データを高速に検索するための索引。本の巻末索引と同じ役割で、検索したい値からデータの位置をすぐに引ける。詳しくは第 6 章「DBMS と SQL」で扱います。
正規化 (normalization): データの重複と矛盾を排除するための設計手法。詳しくは第 11 章「正規化」で扱います。
連絡先データベースの例で考える
イメージをつかむために、最もシンプルなデータベース — 連絡先一覧 — を見てみましょう。
| ID | 名前 | メールアドレス | 電話番号 | 登録日 |
|---|---|---|---|---|
| 1 | 山田 太郎 | yamada@example.com | 090-1234-5678 | 2026-01-01 |
| 2 | 鈴木 花子 | suzuki@example.com | 080-2345-6789 | 2026-01-05 |
| 3 | 佐藤 次郎 | sato@example.com | 070-3456-7890 | 2026-01-10 |
| 4 | 田中 美咲 | tanaka@example.com | 090-4567-8901 | 2026-01-15 |
| 5 | 高橋 健一 | takahashi@example.com | 080-5678-9012 | 2026-01-20 |
この表 (テーブルと呼びます) は、1 行が 1 件の連絡先 (レコード)、1 列が 1 つの項目 (カラム) を表します。
テーブル (table) / レコード (record) / カラム (column) の正式な定義と命名規則は第 7 章「リレーショナルデータベースの基本用語」で詳しく扱います。
なぜ ID が必要か
上の表で、左端の「ID」列に注目してください。これは「一意 (ユニーク) な番号」で、各レコードを他と区別するための識別子です。
ID がないとどんな困りごとが起きるでしょうか? 次のような状況を考えてみます。
名前: 山田 太郎
メール: yamada@example.com
電話: 090-1234-5678
名前: 山田 太郎
メール: yamada2@example.com
電話: 080-9999-0000
同姓同名の人が 2 人いた場合、名前だけでは区別できません。「山田 太郎さんの電話番号を更新したい」と言われたとき、どちらの山田さんかが特定できないのです。
ID という機械的な番号を 1 人につき 1 つ割り振っておけば、ID = 1 の人の電話番号を更新 という指定が一意に効きます。これが一意性 (uniqueness) の考え方です。
ID のような一意な値で「行を一意に特定できる」ことは、リレーショナルデータベースの設計全体の前提です。次の第 7 章「基本用語」では、これを 主キー (Primary Key) と呼んで詳しく扱います。
データベースを使うと何が嬉しいか
ここまでの内容を整理すると、データベースのメリットは大きく次の 5 つに集約されます。
これらの機能を支える具体的な仕組みは、本ガイドの後の章で順に扱います。
| メリット | 詳しく扱う章 |
|---|---|
| 一元管理・正規化 | 第 11 章「正規化」 |
| 同時アクセス・トランザクション | 第 4 章「CRUD と ACID」 |
| データ検証・制約 | 第 4 章「CRUD と ACID」 |
| 高速検索・インデックス | 第 6 章「DBMS と SQL」 |
| バックアップ・障害対策 | 第 4 章「CRUD と ACID」 |
演習: 連絡先データベースを設計してみる
ここまでの内容を確認するため、簡単な設計演習をやってみましょう。
あなたが「友人の連絡先」を管理するデータベースを作るとします。先ほどの例には「ID・名前・メール・電話・登録日」がありましたが、これに加えてどんなカラム (列) があると便利でしょうか? 3 つ以上挙げてみてください。
解答例
たとえば次のようなカラムが考えられます。
| カラム例 | 何のためか |
|---|---|
| 誕生日 | 誕生日にお祝いメッセージを送りたい |
| 住所 | プレゼントを郵送したいとき |
| 関係 (友人・同僚・家族など) | 連絡頻度や送るメッセージの内容を変えたい |
| 最後に連絡した日 | しばらく連絡していない人を見つけたい |
| メモ | 趣味や好きな食べ物などの自由記述 |
ありがちな間違い: 「年齢」を保存してしまうこと。年齢は時間が経つと変わるため、誕生日を保存して都度計算するほうが正確です。「変わる値を直接保存しない」「変わらない元データから計算で導く」という考え方は、設計を考えるうえで重要な視点です。
別解: 連絡先の数が多いなら、「タグ」(複数選択できるラベル) のような項目も考えられますが、これは 1 つのカラムに収まらず別のテーブルが必要になります。詳しくは第 14 章「多対多」で扱います。
ID 列を取り除いたとき、「鈴木さんの電話番号を変更したい」という依頼を受けて困るのはどんな場面でしょうか? 具体例を 1 つ考えてみてください。
解答例
たとえば「鈴木 花子」さんが 2 人いた場合 (同姓同名) です。「鈴木さんを変更して」と言われても、メールアドレスか電話番号で「どちらの鈴木さんですか?」と聞き返さなければなりません。
ID という機械的な番号があれば、ID = 2 の人 という指定で完全に一意に決まります。
さらに踏み込むと: 仮に「同姓同名はいない」と決め打ちしても、名前は変わる可能性があります (結婚・改姓など)。名前を識別子に使うと、改姓のときにすべての参照を書き換える必要が出てきます。変わる可能性のある情報を識別子に使わないのが原則です。
まとめ
この章で学んだことを整理します。
- データベースは「整理されたデータの集まり」で、後から検索・追加・更新・削除しやすい形でデータを保管する仕組み
- データベースがあると、検索の高速化・同時編集・データ検証・障害復旧が実現できる
- 各レコードを一意に区別する ID (一意性) が、設計の出発点になる
- 「変わる可能性のある情報を識別子にしない」「変わる値を直接保存しない (計算で導く)」という考え方が重要
次章では、これらの機能を実現する仕組みとして、システムとデータベースの関係を見ていきます。