[解決済み] データベースの文書化方法【終了しました

質問事項

(注)これは、近いと認識しています。 データベース構造をどのように文書化していますか？ しかし、同一ではないと思う)

私は、文字通り何百ものテーブルとビューを持つデータベースを持つ職場で仕事を始めましたが、すべて母音がほとんどない不可解な名前であり、文書もありません。 また、データベーススキーマへの無償の変更を許可されておらず、自分のマシン上のテストデータベース（定期的に破棄され再作成される）以外には触れることができないので、誰かの役に立つようなコメントを追加することができません。

ERダイアグラムを作成するために"Toad"を使ってみたのですが、48時間起動しっぱなしで何も表示されず、パソコンを返さなければならなくなりました。 他の新入社員と話をしていて、あるテーブルやカラムの意味が分かったら、開発者用のWikiにアップロードしようという話になったんです。

では、どんな方法がいいのでしょうか？ テーブルやビューとそのカラムをリストアップして、その都度埋めていくだけでいいのでしょうか？ 手元にある基本的なツールは、Toad、Oracleの"SQL Developer"、MS Office、そしてVisioです。

どのように解決するのか？

私の経験では、ER（またはUML）図は最も有用な成果物ではありません。多数のテーブルがある場合、図（特にリバースエンジニアリングされたもの）はしばしば大きく複雑な混乱に陥り、誰もそこから何かを学ぶことはできません。

私の考えでは、人間が読むことのできる優れたドキュメント（おそらくシステムの小さな部分のダイアグラムで補ったもの）が、最も大きな効果をもたらすでしょう。これには、各テーブルが含まれます。

• テーブルの意味と機能的な使用方法（UIなど）の説明
• 各属性の意味（明白でない場合）の説明
• このテーブルから他のテーブルへの関係（外部キー）、およびその逆の関係の説明
• 追加制約および/またはトリガーの説明
• テーブルを操作する主要なビューとプロックについて、まだ十分に文書化されていない場合は追加で説明します。

以上のように、ドキュメントを作成するためにドキュメントを作成するのではなく、当たり前のことを繰り返し説明するドキュメントは、人々の邪魔になるだけです。その代わり、最初に混乱したものに焦点を当て、本当に明確で簡潔な説明を書くために数分を費やしてください。そうすることで、じっくりと考えることができ、その結果 大量に このようなテーブルに初めて遭遇する他の開発者の助けになります。

他の方もおっしゃっていますが、これを管理するためのツールは、以下のように多岐にわたります。 エンタープライズアーキテクト , レッドゲートSQLドキュメント そして、さまざまなベンダーのビルトインツールがあります。しかし、ツールのサポートは有用ですが（大規模なデータベースでは重要な場合もあります）、その一方で 理解する と 説明 データベースの概念モデルこそが真の勝利なのです。その観点からは、テキストファイルでも可能です（ただし、Wiki形式にすることで、複数の人が協力して少しずつドキュメントを追加していくことができます - 誰かが何かを発見するたびに、即座に増え続けるドキュメントにそれを追加することができるのです）。