データベース設計とは
データベース設計とは、システムが扱うデータを、どのような単位・項目・関係でデータベースに保存するかを決める工程です。DB設計、テーブル設計とも呼ばれます。
平易に言えば、「データの収納棚の設計図」を作る作業です。どの棚に何を入れ、棚同士をどうひも付けるかが決まっていれば、必要なデータを速く正確に取り出せます。逆に設計が雑だと、同じデータがあちこちに重複し、更新漏れや集計の食い違いが起きます。
画面や機能は後から比較的変えやすいのに対し、データの構造はシステム全体が依存しているため、後から変えるのが難しい部分です。その意味で、データベース設計はシステムの土台にあたります。
データベース設計の3段階
データベース設計は、抽象度の異なる3つの段階で進めるのが一般的です。
| 段階 | 決めること | 主な成果物 |
|---|---|---|
| 概念設計 | 業務で扱うデータのまとまりと関係 | 概念レベルのER図 |
| 論理設計 | 項目、主キー、正規化、関係の詳細 | 論理ER図、項目定義 |
| 物理設計 | 使う製品、型、インデックス、容量 | テーブル定義書、DDL |
概念設計は業務の言葉で行うため、発注側の関与が最も重要な段階です。論理設計では重複をなくす正規化を行い、物理設計で実際に使うデータベース製品に合わせて型や検索を速くするための索引（インデックス）を決めます。
物理設計では、次のような非機能面の判断も含まれます。
- データ量の増え方と、何年分を保存するか
- 削除したデータを完全に消すか、履歴として残すか
- 個人情報など、暗号化して保存すべき項目はどれか
- バックアップの頻度と、復元にかけられる時間
実務での使い方・具体例
ある会社が、紙と表計算で管理していた修理受付業務をシステム化するとします。データベース設計は、次のような手順で進みます。
- 現在使っている帳票やExcelをすべて集め、項目を洗い出す
- 「顧客」「製品」「修理受付」「作業記録」「部品」などのまとまりに分ける
- 「1件の受付に作業記録は何件付くか」など関係の数を業務担当者に確認する
- 重複している項目を整理し、どのまとまりに持たせるかを決める
- 検索や集計で使う条件を確認し、索引や集計用の項目を設計する
- 既存データをどう移すか、移行の観点から設計を見直す
特に6の観点は見落とされがちです。旧データに「顧客名が空」「日付の書式がばらばら」といった状態があると、きれいに設計した新しい構造へそのまま入れられません。設計の段階で既存データのサンプルを見ておくと、移行時の想定外を減らせます。
もう一つの重要な判断は、「何を履歴として残すか」です。たとえば商品の価格を後から変更したとき、過去の注文にも新しい価格が表示されてしまうと困ります。注文時点の価格を注文側に保存しておく、といった判断は業務の意味を理解していないとできません。
さらに、将来の分析を見据えるなら「いつ、誰が、どの状態に変えたか」を残す設計にしておくと有効です。修理受付であれば、受付から完了までのステータス変更の日時を記録しておくだけで、後から工程ごとの所要時間やボトルネックを把握できます。運用開始後に「この数字が知りたい」と思っても、記録していないデータは遡って集められません。
よくある誤解と注意点
画面ができてから考えればよいという誤解。 画面に合わせてテーブルを作ると、似たデータが画面ごとに分散し、整合性が崩れやすくなります。画面とデータ構造は並行して、データ側を土台に考えるのが基本です。
正規化すれば必ず正解になる。 正規化は重複を防ぐ基本ですが、集計の速度を優先して意図的に重複を持たせる設計もあります。判断の理由を記録しておくことが大切です。
項目名を開発者任せにする。 テーブルや項目の名前が業務で使う言葉とずれていると、後から集計やデータ活用をする際に「この項目は何を意味するのか」が分からなくなります。業務用語と項目名の対応表を作っておくと、保守や分析の担当者が変わっても意味が伝わります。
将来の拡張をすべて盛り込もうとする。 起こるかどうか分からない要件のために構造を複雑にすると、開発も保守も重くなります。「近いうちに確実に必要になること」と「可能性があること」を分け、前者だけを設計に織り込むのが現実的です。
関連用語
- ER図（実体関連図）：データのまとまりと関係を図示する、設計の基本ツール
- 正規化（データベース）：データの重複を減らすための設計手法
- RDB（リレーショナルデータベース）：表形式でデータを管理する代表的なデータベース
- NoSQL：表形式以外の方法でデータを扱うデータベースの総称
- データ移行：旧システムのデータを新しい構造へ移す作業
移行前のデータ整備は「Excelデータをシステムに移す前のデータ整備」で詳しく解説しています。
Otsumuに相談できること
Otsumuは、業務の流れとデータの使われ方を確認したうえで、将来の改善や分析にも耐えるデータ構造を設計し、開発・運用まで一貫して担います。必要以上に複雑にせず、目的に合わせて構造を絞り込むことを重視しています。
業務システムの開発については業務システム開発のページをご覧ください。既存データの扱いに不安がある場合も、30分の無料相談でご相談いただけます。
執筆：Otsumu株式会社 ／ 編集日 2026.10.01