データベース設計とは？なぜ最初の設計が重要なのか

「DB設計が終わらないと開発が進められません」「設計を後から変えると大変です」。プロジェクト現場でよく聞く言葉ですが、なぜデータベースの設計がそこまで重要なのか、ピンとこない方もいるのではないでしょうか。

この記事では、データベース設計とは何か、なぜ最初に丁寧に設計することが大切なのかを、わかりやすく解説します。

この記事でわかること

データベース設計とは、システムで扱うデータをどんな表（テーブル）に、どんな形で保存するかを事前に決める作業のことです。

具体的には以下のようなことを決めます。

家を建てる前に間取り図を作るのと同じです。

「後から壁を増やしたい」「トイレをもっと広くしたい」という要望が出ても、建て終わった家を大幅に作り直すのは大変ですし、費用もかかります。最初の設計が重要な理由がよくわかりますよね。

データベースも同じです。後からテーブル構造を変えると、その変更に合わせてプログラムも変更しなければならず、テスト工程も増えます。大規模なシステムでは、設計変更が連鎖的に影響を与えることもあります。

データが重複・矛盾する 同じ情報が複数の場所に保存されると、片方だけ更新されて整合性が取れなくなるケースがあります（例：顧客の住所を変えたが、別テーブルでは古い住所のまま）。

検索が遅くなる・パフォーマンスが落ちる 設計が悪いと、必要なデータを取り出すのに複雑な処理が必要になり、システムの動作が重くなります。

後からの変更コストが跳ね上がる 「このデータ項目を追加してほしい」という要望に応えるだけで、大量のプログラム変更が必要になることがあります。

バグの原因になる 想定外のデータが入り込んだり、必要なデータが保存されていなかったりと、バグの温床になります。

設計では「正規化」という考え方がよく使われます。正規化とは、データの重複をなくし、一貫性を保つためのテーブル分割のルールです。

たとえば「注文テーブル」に顧客名・顧客住所・商品名・商品価格をすべて入れると、顧客情報や商品情報が注文ごとに重複して保存されます。正規化すると「顧客テーブル」「商品テーブル」「注文テーブル」に分けて管理するようになります。

「設計は後でやればいい」は危険 開発が始まってから「やはりこのデータも必要だった」という追加要求は珍しくありません。ただし、設計が固まる前に進める場合と、設計なしで進める場合では影響の大きさが全然違います。

ER図が読めると会話がしやすい ER図（Entity Relationship Diagram）はテーブル間の関係を図示したものです。全部理解できなくてもよいですが、「どのテーブルがどこと関係しているか」を確認できるだけで、設計会議での理解が大きく変わります。

「DB設計が終わっていないから開発を始められない」という発言が出たとき、それは「家の間取りが決まらないと大工が作れない」と同じ理屈です。PM・PMOとして、設計フェーズに十分なリソースと時間を確保することが重要です。

また、顧客から「このデータも保存してほしい」という追加要求が出た際は、設計変更コストが発生する可能性があることをエンジニアに確認しましょう。

データベース設計の全体像を体系的に学びたい方には、FEX-104「データベース入門」がおすすめです。図書館の仕組みというわかりやすいたとえで、保存・設計・SQLの基本をまとめて学べます。