はじめに
「データベースは重要だ」
という言葉をよく耳にします。
そしてデータベースが「技術的に」何故大切なのか？
という事については調べればすぐに出てきます。
しかし根本的な考え方やデータベースへの捉え方。
データベースに対する「概念的な」大切さを説いている人は意外にも少なく、 またその説明をするのも難しいような気がします。
なのでデータベースに対して技術的な面からではなく、概念的な面から大切な理由を書いてみようと思います。
もしもデータベースがなかったら？
少し想像してみてください。あなたは小さなお店を運営しています。
データベースなしの世界
【1日目】
お客さんが3人来ました。注文をメモ帳に書きました。
田中さん → りんご3個
佐藤さん → みかん5個
鈴木さん → バナナ2房
【1週間後】
お客さんが50人になりました。メモ帳が3冊に...
「えっと、先週の田中さんの注文どこだっけ...」
（30分後）「あった！でも田中さんって2人いた...どっちだ？」
【1ヶ月後】
お客さんが500人になりました。
「りんごを買ったことのあるお客さん全員にセールのお知らせを送りたい」
「...全部のメモ帳を1ページずつ見るしかない...」
（3日後）「まだ終わらない...そしてたぶん見落としてる...」
現実に起きていること
笑い話のようですがこれは実際に、現実の企業で起きている問題です。
- Excelで顧客管理 → ファイルが壊れて全データ消失
- 紙の台帳で在庫管理 → 棚卸しに時間がかかる
- メールで情報共有 → 「あのメールどこ行った？」
データベースはこうした問題を解決してくれます。
データは「プログラム」より長生きする
そして多くの人が見落としがちな事実があります。
プログラムは何度も書き直されるが、データは残り続ける
これがデータベースが重要な根本的な理由です。
具体例で考えてみる
【2010年】
・言語: PHP 5.2
・フレームワーク: なし（生PHP）
・顧客データ: 1万件
【2015年】
・言語: PHP 7.0
・フレームワーク: Laravel 5
・顧客データ: 10万件(2010年のデータも含む)
【2020年】
・言語: Python 3.8
・フレームワーク: Django
・顧客データ: 50万件(2010年からのデータ全部)
【2025年】
・言語: Go
・フレームワーク: Gin
・顧客データ: 100万件(15年分のデータが生きている)
プログラミング言語は3回変わりましたが、顧客データは一度も失われていません。
これこそがデータベースを「プログラムとは別に」しっかり設計・管理する理由です。
従来のプログラム中心の考え方（POA : Program Oriented Approach）
普通に設計を組み立てようと思うと、どうしてもプログラムを中心に考えてしまいがちです。
1.「どんな機能を作るか？」
2.「その機能に必要なデータは？」
3.「じゃあ、こんなテーブルを作ろう」
しかしこの考え方だと、仕様変更があるとデータ構造も変わってしまいます。
データ中心アプローチ（DOA : Data Oriented Approach）
1.「このビジネスで扱う"モノ"や"コト"は何か？」
2.「それらはどう関係しているか？」
3.「データ構造を設計」
4.「そのデータを使う機能を作る」
この考え方なら、どれだけ機能が変わっても、データ構造は変わりません。
開発に仕様変更はつきものです。
データを中心に考えたほうが結果的に楽に開発を進められる場面が多く、現在ではDOAの方が主流だと言われています。
実際、「ベテランエンジニアの方がデータを中心にどう開発を進めていくのかを考える」という話をよく聞きます。
データの具体例
例：ECサイトの設計
-- DOAで設計すると、こういうシンプルな構造になる
顧客（顧客ID, 名前, メールアドレス, 住所）
商品（商品ID, 商品名, 価格, 在庫数）
注文（注文ID, 顧客ID, 注文日, 合計金額）
注文明細（注文ID, 商品ID, 数量, 単価）
この構造があれば、どんな機能でも対応できます：
- 「ポイント制度を追加したい」→ 顧客テーブルにポイント列を追加
- 「定期購入機能を追加したい」→ 定期購入テーブルを追加
- 「レビュー機能を追加したい」→ レビューテーブルを追加
データ構造がしっかりしていれば、機能追加は怖くないのです。
データベースは「約束」である
少し抽象的な話をします。
データベースのテーブル定義（スキーマ）は、単なる技術的な設計図ではありません。それは 「このシステムでは、現実世界をこのように捉える」という宣言 です。
例：「顧客」の定義
CREATE TABLE 顧客 (
顧客ID INT PRIMARY KEY,
名前 VARCHAR(100) NOT NULL,
メールアドレス VARCHAR(255) UNIQUE,
生年月日 DATE,
会員ランク VARCHAR(20) DEFAULT '一般'
);
この定義は、以下のことを全社的に約束しています：
| 定義 | 意味する約束 |
|---|---|
顧客ID INT PRIMARY KEY |
「顧客は必ず一意に識別できる」 |
名前 NOT NULL |
「名前なしの顧客は存在しない」 |
メールアドレス UNIQUE |
「同じメアドで2人登録はできない」 |
生年月日 DATE |
「生年月日は正確な日付形式で持つ」 |
会員ランク DEFAULT '一般' |
「新規登録時は全員一般会員から始まる」 |
これが「約束」である理由
- 営業部：「このルールで顧客を登録します」
- 開発部：「このルールに従ってシステムを作ります」
- カスタマーサポート：「このルールで顧客情報を参照します」
データベース設計は、部署を超えた約束なのです。
「真実の単一ソース」という概念
英語で "Single Source of Truth"（SSOT）という概念があります。
「ある情報について、正しい値が存在する場所は一箇所だけであるべき」
これがデータベースの果たす最も重要な役割の一つです。
アンチパターン：真実が複数ある地獄
Excelファイル「顧客リスト_最新.xlsx」 → 営業部が管理
基幹システムのDB → IT部が管理
Googleスプレッドシート「顧客メモ」 → カスタマーサポートが管理
もしデータをこうやって管理していると
「田中商事さんの住所が変わったらしい」
「え、どこを更新すればいいの？」
「全部...？」
「あれ、でも営業部のExcelには古い住所のままで契約が...」
この問題は、企業で実際に起きている事です。
なぜこれが問題なのか
【1ヶ月後の状況】
Excelの住所 : 東京都渋谷区... （先月更新）
DBの住所 : 東京都新宿区... （半年前のまま）
スプレッドシート : 東京都品川区... （2年前のまま）
本当の住所はどこなのか、誰にも分らなくなってしまいます。
データベースによる解決
【正しい設計】
┌─────────────┐
│ データベース │
└──────┬──────┘
┌───────────────┼───────────────┐
↓ ↓ ↓
営業システム 請求システム サポート画面
（参照のみ） （参照のみ） （参照のみ）
ルール：
- 住所の更新はデータベースに対してのみ行う
- 各システムはデータベースを参照する
- Excelやスプレッドシートは一時的な作業用のみ
これで「どこが正しいか？」という問題は解決します。
まとめ
1： データはプログラムより長生きする
→ プログラムから独立して管理する必要がある
2： データ中心で考えると設計が安定する
→ 仕様変更に強いシステムになる
3： データベース設計はビジネス決定である
→ 技術だけでなくビジネス理解も必要
4： 真実は一箇所にあるべき
→ データの整合性を保つ唯一の方法