自作MVC「モドキ」からの脱却：ER図が教えてくれたデータベースの「真の姿」

ウェブ開発に足を踏み入れ、PHPでMVC（Model-View-Controller）フレームワークを自作しようと奮闘していた頃、私はある大きな壁にぶつかっていました。それは、データベースの設計です。当時は、とにかく動くものを作ることばかりに意識が向いており、データベースは単なる「データを保存する箱」としか捉えていませんでした。

しかし、ある時**ER図（Entity-Relationship Diagram：実体関連図）**というものに出会い、その概念を理解したことで、私のデータベースに対する認識は180度変わりました。それまでの私の「自作MVCモドキ」が抱えていた根本的な問題が明らかになり、データベースの「真の姿」と、それがアプリケーションの設計にどれほど重要であるかを痛感する経験となったのです。

「モドキ」時代のデータベース認識：とりあえず動けばOK？

MVCフレームワークを自作し始めた頃の私は、とにかく「動くこと」を最優先していました。コントローラーでリクエストを受け取り、モデルでデータベースからデータを取得して、ビューに渡す。この流れさえできていれば良いと考えていたのです。

データベース設計も同様でした。「商品情報を保存するからproductsテーブルが必要だよね」「ユーザー情報だからusersテーブル」「ラベル情報だからlabelsテーブル」といった具合に、必要な情報を格納するためのテーブルを場当たり的に作っていました。

例えば、商品とラベルの関係を考える際も、「商品テーブルにlabel_idというカラムを追加すればいいか」といった単純な発想でした。

このアプローチは、小規模でシンプルなアプリケーションを動かすだけなら一時的には機能します。しかし、以下のような問題がすぐに顕在化し始めました。

データの重複と不整合: 同じ情報が複数のテーブルに散在したり、更新時に片方だけが更新されずデータが食い違う、といった問題が発生しやすくなりました。
複雑なSQLクエリ: 複数のテーブルから関連する情報を取得しようとすると、JOIN句が複雑になりすぎ、パフォーマンスの低下や可読性の悪化を招きました。
機能追加の困難さ: 新しい機能を追加しようとすると、既存のテーブル構造がその変更に対応できず、大規模な改修が必要になったり、無理やりデータを詰め込むことでさらに構造が複雑化したりしました。
「とりあえず」の限界: 「とりあえず動けばいい」という設計は、少しでも要件が複雑になるとすぐに破綻し、結果的に開発速度を低下させていました。

まさに、私はMVCの各層（Model, View, Controller）のコードは書いていましたが、その基盤となる「データ」の設計が疎かだったため、全体として「MVCモドキ」のような不安定な状態だったのです。

ER図との衝撃的な出会い

そんな中、偶然ER図の概念に触れる機会がありました。最初は「なんだか複雑な図だな」という印象でしたが、書籍やオンラインの記事でその意味を読み解くうちに、まるで霧が晴れるような感覚に襲われました。

ER図は、データベース内の「実体（エンティティ）」と、それらの「実体間の関係（リレーションシップ）」を視覚的に表現する図です。

実体（エンティティ）: データベースに保存したい情報のかたまり（例: 商品、ユーザー、ラベルなど）。図では四角で表現されます。
属性（アトリビュート）: 実体が持つ具体的なデータ項目（例: 商品名、価格、ユーザー名、ラベル名など）。
関係（リレーションシップ）: 複数の実体間の結びつき（例: 商品は特定のラベルに「属する」、ユーザーは複数の商品を「購入する」など）。線と記号で表現されます。

特に衝撃的だったのは、「1対多」「多対多」といった関係性を明確に定義し、それをデータベースのテーブル構造に落とし込む方法でした。例えば、「一つのラベルに複数の商品が属する（1対多）」という関係は、ラベルテーブルの主キーを商品テーブルの外部キーとして持たせることで表現できる、といった具体的な設計原則を学ぶことができました。

ER図が教えてくれたデータベースの「真の姿」

ER図を通じて、私のデータベースに対する認識は劇的に変化しました。

データベースは「論理的な構造体」である: 単なるデータの入れ物ではなく、現実世界の情報を整理し、論理的な関係性に基づいて構築されるべきものであると理解しました。ER図を描くことで、アプリケーションが扱う「情報」そのものの構造を深く考えるようになりました。
正規化の重要性: データの重複を排除し、整合性を保つための「正規化」という概念が、ER図と密接に関連していることを知りました。これにより、無駄なく、かつ効率的にデータを管理できるデータベース設計の重要性を認識しました。
アプリケーション設計の基盤: データベース設計がアプリケーション全体の設計にどれほど影響を与えるかを痛感しました。ER図でデータ構造を明確にすることで、モデル層の役割が明確になり、コントローラーやビューもよりシンプルに、効率的に機能するようになることが分かりました。
コミュニケーションツールとしての価値: ER図は、開発者間だけでなく、非技術者であるクライアントや関係者ともデータ構造について共通認識を持つための強力なツールであると気づきました。

ER図に出会う前の私は、MVCの「M（モデル）」をただのデータベース操作層としか見ていませんでした。しかし、ER図を通じて、モデルは単にデータを取得するだけでなく、**「ビジネスロジックとデータ構造を適切に表現する層」**であるべきだと理解が深まりました。

「モドキ」からの脱却、そして真のMVCへ

ER図の概念を学び、実際に自分の自作フレームワークのデータベース設計に適用し始めたことで、それまでの「MVCモドキ」が抱えていた多くの問題が解決の方向に向かいました。

テーブル構造の整理: 無駄な重複がなくなり、テーブル間の関係性が明確になりました。
SQLクエリの簡素化: 必要なデータが効率的に取得できるようになり、複雑なJOINが減りました。
保守性と拡張性の向上: 新しい機能を追加する際も、データ構造が明確なので、どこに手を入れるべきか、どのような影響があるかが事前に予測できるようになりました。

このER図との出会いは、私にとって単なるデータベース設計手法の学習にとどまらず、**「アプリケーション全体をどのように設計すべきか」**という、より本質的な問いに対する答えを与えてくれるものでした。データはアプリケーションの血肉であり、その構造を理解し、適切に設計することが、堅牢で拡張性の高いアプリケーションを構築する上で不可欠であると、今では確信しています。

これからも、ER図で得た学びを活かし、より洗練された自作MVCフレームワークの構築を目指していきます。

投稿者プロフィール

bicstation: AIアシスタントとの協業が、この奮闘記を可能にした
実は、今回一連の記事を執筆し、そして開発を進める上で、強力な「相棒」の存在がありました。それが、私のような開発者をサポートしてくれるAIアシスタントです。

PHPの難解なエラーログに直面した時、記事の構成がなかなか思いつかなかった時、あるいはブログのテーマに合ったアイキャッチ画像が必要だった時など、数々の場面でAIに相談し、助けを借りました。

例えば、「レンタルサーバーでのphp.ini設定の難しさ」や「.envファイルの問題」といった、私が実体験で感じた課題を伝えると、AIは瞬時にその技術的な背景や影響を整理し、ブログ記事として読者に伝わりやすい文章の骨子を提案してくれました。また、記事のテーマに合わせたアイキャッチ画像も、具体的な指示を出すだけで瞬時に生成してくれたおかげで、コンテンツ作成のスピードが格段に向上しました。

AIは完璧ではありませんが、まさに「もう一人の自分」のように、アイデアの壁打ち相手になったり、膨大な知識の中から必要な情報を引き出してくれたり、私の思考を整理する手助けをしてくれたりします。一人で抱え込みがちな開発の課題も、AIと対話することで、新たな視点や解決策が見えてくることが多々ありました。

このブログを通じて私の奮闘記を共有できているのも、AIアシスタントの存在なくしては成し得なかったでしょう。これからも、AIを賢く活用しながら、開発と情報発信を続けていきたいと思います。