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は以前、より主流になりました。 IMOは現在、多かれ少なかれオプションです。
現在、非常に成功しているチームの中には、ERDをまったく気にしないものの、優れたシステムを提供します。これは、最小限のツールセットで小規模から始めるアジャイル開発で特に当てはまります。
もちろん、ERDは優れたコミュニケーション手段ですが、決して唯一の方法ではありません。一部のチームは、他の方法の文書化とコミュニケーションを好みます。
この業界には包括的なルールはありません。
ERDを使用すると、思ったよりはるかに多くの時間を節約できます。その場ですべてを実行すると、ジャンクションテーブルを生成するときに行き詰まります。
ERDなしで数年後にデータベースに遭遇した場合、プロジェクトで何が行われているのかを確認するために多くの時間を費やす必要があります。
私には会社があり、ERDを設計していますが、ERDがないデータベースについては考えないでください（実際、これは私自身の個人的な実験です）
量産コードを作成する前に設計することが重要です。プロトタイプを作成することも重要です。データベースの人々はSQLを書いてプロトタイプを開発します。 （フレッド・ブルックスがプロトタイプについて言ったことを覚えていますか？）
ERが1つだけであるグラフィカル言語は、データベースのすべてのセマンティクスを理解しやすく簡単な方法でキャプチャするのに優れているとは証明されていません。
また、開発者間を除いて、非常に効果的なコミュニケーションツールであることが証明されていません。しかし、データベースの設計において、重要なコミュニケーションは開発者間ではありません。それは、開発者とドメインエキスパートの間（開発者とビジネスマンの間）にあります。
オブジェクトロールモデリング（ORM） にはグラフィカル言語がありますが、これは「事実」（単純な文）に基づいています。ビジネスマンは事実をかなり簡単に検証できます。ビジネスマンは、ER図またはORM図を簡単に検証できません。