データベース設計の基礎：Excel脳から脱却するための「RDB」入門

データベース設計の基礎：Excel脳から脱却するための「RDB」入門

「Excelで管理してるんですけど、そろそろ限界で…」

起業して間もない頃、顧客リストや売上データをExcelやGoogleスプレッドシートで管理するのはごく自然なことです。

しかし、事業が成長するにつれて、こんな問題に直面していませんか？

• 同じ顧客情報が複数のシートに散らばっていて、どれが最新かわからない
• データを更新したら、別のシートとの整合性が取れなくなった
• 「この顧客の注文履歴を全部出して」と言われても、手作業で探すしかない
• スタッフが増えるたびに、誰がどのファイルを編集したか追えなくなる

「開発会社にシステムを発注したら、最初に『データベース設計』の話をされたけど、正直よくわからなかった」——そんな経験をお持ちの方も多いのではないでしょうか。

実は、このデータベース設計こそが、あなたのサービスの開発コスト・運用コスト・将来の拡張性を大きく左右する最重要ポイントなのです。

なぜExcelの発想のままだと「高くつく」のか

「データを管理するだけなら、Excelでもデータベースでも同じでしょ？」

そう思うのは無理もありません。実際、筆者も多くの起業家から同じ質問を受けてきました。

問題は、Excelとデータベースでは「データの持ち方」の考え方が根本的に違うということです。

Excelでは、1つのシートに必要な情報を全部並べるのが自然です。たとえば「注文一覧」シートに、注文番号・顧客名・顧客の住所・商品名・金額を全部入れますよね。

一見わかりやすいのですが、これをそのままシステムのデータベースに持ち込むと、同じ顧客の住所が100行に重複して保存されることになります。その顧客が引っ越したら？ 100行すべてを更新しなければなりません。1行でも漏れたら、データ不整合の完成です。

この「Excel脳」のままシステム開発を進めてしまうと、後から修正するのに当初の開発費と同じくらいのコストがかかることも珍しくありません。

この記事でわかること：RDBの「考え方」を身につける

この記事では、非エンジニアの起業家・経営者の方に向けて、リレーショナルデータベース（RDB）の基本的な考え方を解説します。

難しいSQL文やコマンドは一切出てきません。代わりに、以下のことが理解できるようになります。

• なぜExcel的なデータ管理がシステムでは通用しないのか
• RDBの「テーブル」「リレーション」とは何か
• 「正規化」という概念がなぜ開発コスト削減につながるのか
• 開発会社との打ち合わせで、データベース設計の話についていけるようになる

技術の詳細を理解する必要はありません。 でも、「考え方」を知っているだけで、開発の失敗リスクは大幅に下がります。

RDBの考え方を図解

RDBの基本を「Excel→テーブル変換」で理解する

「テーブル」＝目的別に分けたExcelシート

RDB（リレーショナルデータベース）の最も基本的な概念は**「テーブル」**です。

Excelで「注文一覧」という1枚のシートにすべての情報を詰め込んでいたものを、RDBでは目的別のテーブルに分割します。

Excel脳の場合：

RDB脳の場合：

顧客テーブル：

商品テーブル：

注文テーブル：

「あれ、分けたらかえって見にくくない？」と思うかもしれません。しかしこの分割こそが、RDBの最大の強みなのです。

「リレーション」＝テーブル同士のつながり

上の例で、注文テーブルの「顧客ID」は顧客テーブルの「顧客ID」とつながっています。これが**リレーション（関係）**です。

この仕組みがあるおかげで：

• 田中太郎さんが引っ越しても、顧客テーブルの1行を更新するだけで、すべての注文に反映される
• Tシャツの値段が変わっても、商品テーブルの1行を更新するだけ
• 「田中太郎さんの全注文履歴」も、IDをたどるだけで一瞬で取得できる

Excelなら100行を手作業で直す作業が、RDBなら1行の更新で完了する。これがデータの整合性が保たれるということです。

「正規化」＝ムダな重複をなくす設計ルール

先ほどの「1枚のシートを複数のテーブルに分割する」作業を、専門用語で正規化と言います。

正規化のメリットは明快です：

• データの重複が減る → ストレージコストが下がる
• 更新箇所が1つで済む → バグや不整合が起きにくい
• データの検索が速い → ユーザー体験が向上する
• 機能追加がしやすい → 将来の開発コストが抑えられる

逆に、正規化をせずにExcel脳のままデータベースを作ると：

• データが膨大に膨れ上がり、サーバー費用が無駄に増える
• 1つの変更に複数箇所の修正が必要になり、バグの温床になる
• 「ここを直すと、あっちが壊れる」という泥沼にはまる

正規化がしっかりされているかどうかは、そのシステムの品質を測る最も基本的な指標の1つです。開発会社に「正規化はどの程度やっていますか？」と聞くだけでも、相手の技術力を推し量ることができます。

データベース設計のステップ

起業家が知っておくべき「設計ミス」のコスト

ここで、実際によくあるケースをご紹介します。

ケース1：ECサイトの注文データが壊れる

あるスタートアップが、Excelの構造をそのままデータベースにしてECサイトを構築しました。ローンチ直後は問題なく動いていましたが、注文が1,000件を超えたあたりから「注文と顧客の紐付けがおかしい」「金額が合わない」というクレームが発生。

原因は、顧客情報と注文情報が1つのテーブルにまとめられていたこと。修正にはテーブル設計のやり直しとデータ移行が必要で、追加で数百万円のコストが発生しました。

ケース2：新機能の追加に既存機能の3倍かかる

「お気に入り機能を追加してほしい」という簡単な要望に対して、開発会社から返ってきた見積もりが想定の3倍。理由を聞くと、「既存のテーブル構造では新しい関係を表現できないため、データベースの再設計が必要」とのこと。

最初の設計を正しく行っていれば、テーブルを1つ追加するだけで済んだ話です。

開発会社に発注する前に確認すべき3つのポイント

データベース設計の詳細を自分でやる必要はありません。しかし、以下の3点を発注前に確認するだけで、失敗のリスクは大幅に減ります。

1. 「ER図」を見せてもらう

ER図（Entity-Relationship Diagram）とは、テーブルとテーブルの関係を図にしたものです。先ほどの「顧客テーブル」「商品テーブル」「注文テーブル」がどうつながっているかを一目で確認できます。

開発会社に「ER図を共有してください」とお願いするだけでOKです。まともな開発会社なら、必ず作成しているはずです。逆に、ER図が存在しない場合は要注意です。

2. 「将来の機能追加を考慮した設計か」を聞く

「今の仕様だけでなく、半年後・1年後に追加しそうな機能も想定して設計していますか？」と聞きましょう。

たとえば、今はBtoC向けのサービスでも、将来BtoB向けに「企業アカウント」を追加する可能性があるなら、最初からそれを見越した設計にしておくべきです。

3. 「正規化のレベル」を確認する

「第3正規形まで対応していますか？」と聞くだけで十分です。細かい意味を理解する必要はありません。この質問ができるだけで、「この人はデータベース設計の重要性を理解している」と開発会社に伝わります。 結果として、手を抜かれにくくなるという効果もあります。

こんな方におすすめ

• 顧客データや注文データをExcel・スプレッドシートで管理しているが、限界を感じている方
• これからWebサービスやアプリの開発を外注しようとしている起業家・経営者の方
• 開発会社との打ち合わせで「データベース」の話が出るたびに不安になる方
• 過去にシステム開発で「データの不整合」に悩まされた経験がある方

データベース設計の問題は、サービスが成長してから発覚することがほとんどです。そして、成長してからの修正は、最初に正しく設計するコストの何倍にも膨れ上がります。

だからこそ、開発を発注する前の「今」、RDBの考え方を理解しておくことに大きな意味があります。

まとめ

まとめ：Excel脳からRDB脳へ

この記事のポイントを振り返ります。

• Excelとデータベースでは「データの持ち方」が根本的に違う。Excelの発想のままシステムを作ると、重複・不整合・検索の遅さが必ず問題になる
• RDBは「テーブル分割」と「リレーション」で、データの整合性と効率を両立する仕組み
• 「正規化」はムダな重複をなくす設計ルール。これがしっかりしているかどうかで、将来の開発コストが大きく変わる
• 開発会社には「ER図の共有」「将来の拡張性」「正規化のレベル」の3点を確認するだけで、失敗リスクを大幅に減らせる

技術がわからなくても、正しい「問い」を持っているだけで、開発の成功確率は飛躍的に上がります。

データベース設計のような技術的な判断に不安がある方は、アトリエ・バイナリの技術コンサルティングもぜひご活用ください。非エンジニアの起業家が「技術がわからないことで挑戦を諦める」ことのないよう、開発の失敗回避から技術選定まで伴走しています。

まずは今の自社のデータ管理を見直すところから始めてみませんか？ 今使っているExcelのシートを眺めて、「これは本来、いくつのテーブルに分けるべきだろう？」と考えてみる——それだけで、あなたのデータベースリテラシーは大きく前進しています。