私の経験では、ER（またはUML）ダイアグラムは最も有用なアーティファクトではありません。テーブルが多数あるため、ダイアグラム（特にリバースエンジニアリングされたもの）は、多くの場合、誰も何も学ばない大きな複雑な混乱です。
私のお金では、人間が読める形式の優れたドキュメント（おそらくシステムの小さな部分の図で補足されている）が最も多くのマイレージを提供します。これには、テーブルごとに次のものが含まれます。
- テーブルの意味と機能的な使用方法（UIなど）の説明
- 明確でない場合は、各属性の意味の説明
- このテーブルから他のテーブルへの関係（外部キー）の説明、およびその逆
- 追加の制約および/またはトリガーの説明
- まだ十分に文書化されていない場合は、テーブルに触れる主要なビューとプロシージャの追加の説明
上記のすべてで、文書化のために文書化しないでください-明白なことを言い換える文書化は人々の邪魔になります。代わりに、最初はあなたを混乱させたものに焦点を合わせ、本当に明確で簡潔な説明を書くのに数分を費やしてください。それはあなたがそれを熟考するのを助けるでしょう、そしてそれは大規模に これらのテーブルに初めて遭遇する他の開発者を支援します。
他の人が言及しているように、Enterprise Architect、Red Gate SQL Doc、さまざまなベンダーの組み込みツールなど、これを管理するのに役立つさまざまなツールがあります。しかし、ツールのサポートは役に立ちますが（さらに、大規模なデータベースでは重要です）、理解するという大変な作業を行います。 および説明 データベースの概念モデルが真の勝利です。その観点からは、テキストファイルでそれを行うこともできます（ただし、Wiki形式で行うと、複数の人が共同でそのドキュメントに段階的に追加できるようになります-したがって、誰かが何かを理解するたびに、成長するボディに追加できますドキュメントの即時）。