ER図の重要性

私は学生で、学界の一部としていくつかのプロジェクトを開発しています。

あるプロジェクトのデータベースを開発しているときに、ERDが必要かどうかを考えている状況に遭遇しました。現在、私たち全員が最初にERDを開発し、次にそれからデータベースを開発することに同意しているわけではありません。

大多数の人は、紙で直接要求されるシステムに従って口頭でデータベースをオンザフライで開発することを好みます。

現在、私はデータベースの原則を厳守しています。データベースはERDのみから開発する必要があると思います。だから、私は次のことを知りたいだけです：

• 業界はこれらの原則に従っていますか？
• ERDの開発に時間を浪費しているだけですか？
• ERDを開発する利点は何ですか？

単純明快で、ERDなしでデータベースを開発することは、建築計画なしで家を建てることと考えてください。レンガを積み重ねるだけで何かを構築するのに十分であると考えているので、それは可能かもしれませんが、プロジェクトに対して誰かが責任を負う瞬間には、災害の可能性があります。

私の経験では、ERDをCASEツール（ERWin、MySQL Workbenchなど）と併用しない限り、ERDのメリットはあまりありません。これにより、フォワードエンジニアリングやリバースエンジニアリングなどの非常に役立つ操作を実行できるようになります。これらの機能がなくても、データベース全体の集中型の回路図を使用すると便利です。データベース自体に実装された制約では、特定のデータベースエンティティ間の関係についてすべてを説明するには不十分な場合があるためです。

これは、ご存じかもしれませんが、MyISAMやInnoDBなどのいくつかの内部ストレージエンジンを実装するMySQLの例です。それらの間には大きな違いがあります。最も重要なものの1つは、MyISAMが制約をサポートしていないことです。その事実にもかかわらず、MyISAMはWebアプリケーションで頻繁に使用されます。つまり、リレーショナルロジックは、ビジネスロジック（アプリケーションコード）または別の方法で実装する必要があります。問題は、MyISAMテーブル（エンティティ）を使用してERDをフォワードエンジニアリングすると、MySQLが暗黙的にERDによって設定された制約を無視し、エンティティ間の関係の性質を明確に識別しないデータベースになってしまうことです。つまり、データベースレイアウトを開発した後は、コード開発者がERDなしで適切なビジネスロジックを実装する方法はありません。

ERDは、データベース構造を明確に把握できると非常に便利です。プロジェクトにとって重要なドキュメントアーティファクトであることに加えて、クエリを実装する必要がある場合、特にテーブル間の結合が容易になります。デュアルモニター構成がどれほど素晴らしいかを想像してください。左側にERDがあり、右側にクエリエディターがあります。テーブル間の関係を明確に確認し、それに基づいてクエリを作成できます。データベースプロジェクトが非常に単純で、プロジェクトにそれが必要ない場合は、おそらくそれなしでも問題ありません。

ERDを使用すると、思ったよりはるかに多くの時間を節約できます。その場ですべてを実行すると、ジャンクションテーブルを生成するときに行き詰まります。

ERDなしで数年後にデータベースに遭遇した場合、プロジェクトで何が行われているのかを確認するために多くの時間を費やす必要があります。

私には会社があり、ERDを設計していますが、ERDなしのデータベースについて考えてはいけません（実際、これは私自身の個人的な実験です）。

ERDは、以前はより主流でした。IMOは現在、ほぼオプションです。

現在、非常に成功しているチームの中には、ERDをまったく気にしないものの、優れたシステムを提供しています。これは、最小限のツールセットで小規模から始めるアジャイル開発で特に当てはまります。

もちろん、ERDは優れたコミュニケーション手段ですが、決して唯一の方法ではありません。一部のチームは、他の方法の文書化とコミュニケーションを好みます。

この業界には包括的なルールはありません。

量産コードを記述する前に設計することが重要です。プロトタイプを作成することも重要です。データベースの人々はSQLを書いてプロトタイプを開発します。（フレッド・ブルックスがプロトタイプについて言ったことを覚えていますか？）

ERが1つだけであるグラフィカル言語は、データベースのすべてのセマンティクスを理解しやすく簡単な方法でキャプチャするのに優れているとは証明されていません。

また、開発者間を除いて、これらは非常に効果的なコミュニケーションツールであることが証明されていません。しかし、データベースの設計において、重要なコミュニケーションは開発者間ではありません。それは、開発者とドメインエキスパートの間（開発者とビジネスマンの間）にあります。

オブジェクトロールモデリング（ORM）にはグラフィカル言語がありますが、これは「ファクト」（単純な文）に基づいています。ビジネスマンは事実をかなり簡単に検証できます。ビジネスマンは、ERダイアグラムやORMダイアグラムを簡単に検証できません。