データベース構造をどのように文書化しますか？
多くのデータベースシステムでは、テーブルとフィールドのコメントや説明が許可されていません。適切な命名規則があることは明らかですが、テーブル/フィールドの目的を文書化するにはどうすればよいでしょうか。
（今のところ、「優れた」テーブル名とフィールド名では、データベース内のすべてのテーブル、フィールド、および関係の完全な意味を文書化するのに十分ではないと仮定しましょう。）
多くの人がデータベースを視覚化するためにUMLダイアグラムを使用していることは知っていますが、フィールドコメントを含むUMLダイアグラムを見たことはほとんどありません。ただし、.sqlファイル内でコメントを使用した経験は豊富です。このアプローチの欠点は、データベース構造が時間の経過とともに変化するため、.sqlファイルを手動で最新の状態に保つ必要があることです。ただし、そうする場合は、バージョン管理下に置くこともできます。
私が見た他のいくつかのテクニックは、データベースの構造と関係を説明する別のドキュメントと、ORMコードまたは他のデータベースマッピングコード内で手動で維持されるコメントです。
過去にこの問題をどのように解決しましたか？どのような方法が存在し、それらに関連するさまざまな長所と短所は何ですか？これを「完璧な世界」でどのように解決してほしいですか？
更新
他の人が指摘しているように、人気のあるSQLエンジンのほとんどは、実際にはコメントを許可しています。これは素晴らしいことです。奇妙なことに、人々はこれらの機能をあまり使用していないようです。少なくとも、私が過去に携わったプロジェクトについてはそうではありません。
遅いものですが、うまくいけば便利です…これは比較的大きなデータベース（合計で約100のテーブルと約350のオブジェクト）を開発するときに使用したプロセスです。
- 開発者は、拡張プロパティを使用してすべてのオブジェクトに詳細を追加する必要がありました。
- 管理者は、拡張プロパティを持たないDDLを拒否しました
- サードパーティのツールを使用して、コマンドラインインターフェイスを介してビジュアルドキュメントを毎日自動的に生成しました。 ApexSQL Doc を使用しましたが、問題なく動作しましたが、他社のRedGateのSQLDocも正常に使用しました。
このプロセスにより、すべてのオブジェクトが文書化され、最新の状態になっていることが保証されました。
しかし難しいのは、開発者に良いコメントを一貫して書かせることでした;）
SQL Serverには、これを処理できる拡張プロパティがあります。
この記事では、SQLサーバーでそれらを設定する方法について説明します http://www.developer.com/db/article.php/3677766
RedGate SQL Doc と組み合わせて使用すると、NiceDataディクショナリを作成できます。
表と列に付けられたコメントを使用します。 SchemaSpy は、コメントを含むスキーマからhtmlドキュメントファイルを生成するための優れたツールです。
ある時点で、CREATE TABLEステートメントを解析し、特別にフォーマットされたコメントを取り除く基本的なSQLパーサーを作成しました。次に、これらはLaTeXソースに後処理され、PDFにレンダリングされました。これは Javadoc に触発され、 この製品 のドキュメントを作成するために使用されました。その後、データディクショナリ機能がウェアハウスマネージャーに組み込まれ、LaTeXジェネレーターの修正バージョンを使用してウェアハウスマネージャーからデータディクショナリがレンダリングされました。
別のプロジェクトでは、Visioを使用しました。VisualStudioEnterpriseArchitectに付属しているバージョンは、データベースをフォワードエンジニアリングします。そのように生成されたSQLでは、テーブルと列のコメントがコメント文字列でレンダリングされ、解析が非常に簡単でした。私が作成したツールは、FrameMakerで作成されたスペックドキュメントに含まれる生成されたMIFファイルを作成しました。
Powerdesigner などのリポジトリツールがある場合は、その中にデータモデルを維持し、入力したドキュメントを含むリポジトリレポートを取得できます。データディクショナリと機能仕様のより深い統合が必要な場合（ETLが複雑で、派生値の大量の計算を伴うデータウェアハウスシステムに非常に役立ちます）、メタデータを抽出し、データを統合するものを生成するユーティリティを作成できます。仕様書への辞書。これにより、データディクショナリアイテムと他の仕様ドキュメント間の相互参照や、データディクショナリの定義や、例を使用した計算方法の仕様などの関連ドキュメントをカバーするインデックスの生成も可能になります。
これは本当に単純なアプローチですが、私は2つのwikiページを使用します。1つはデータベースのmysqldumpを使用し、もう1つはもう少し英語に似た形式で記述されています。
私が取り組んできたプロジェクトの場合、それで十分です（数十のテーブルレベルで）。大規模なプロジェクト（たとえば、数百のテーブル）にどれだけ拡張できるかはわかりませんが、これまでのところ良好です。
テーブル、フィールド、およびすべての機能をリストしたWord文書を作成しました。これは、すべてが互いにどのようにリンク/関係しているかを示す図によって裏付けられています。これは本当に非常に単純なドキュメントであり、フィールド名>データ型>目的を持つテーブルがたくさんあります。
私は使用しています Firebird すべてのシステムオブジェクト（テーブル、列、ビュー、プロシージャとパラメータ、トリガーなど）の説明フィールドがあります。他の人と簡単に共有できるので便利です（ドキュメントはデータベース、個別ではありません）そしてあなたはそれを失うことはありません。
ほとんどの管理者。 Firebirdのツールを使用すると、これらの説明を編集できます。また、（一部またはすべてのテーブルに対して）簡単に印刷できるNiceHTMLまたはPDFレポート）を作成する特殊なツール（IBDescなど）がいくつかあります。
プログラムにコメントするときに、データベースにコメントします。ソースコード（DDL命令を含むSQLファイル）に良い（私は願っています）コメントを書くことによって。
SQLCOMMENTを使用することも可能です。それらの良い点は、それらが常にオブジェクトと一緒にある、それらでバックアップされているなどです。悪い点は、それらがより制限されていることです（たとえば長さ）。
私は最近、個々のテーブルへのリンクを含むマークダウンドキュメントの作成に目を向けました.sqlファイル（テーブルとフィールドには、多くのコメントを付けて直感的に名前を付けることができます）。
次のコマンドを使用して、個々のテーブルスキーマをバージョン管理に保持します。
mysqldump --no-data --tab=./tables dbname
単一のテーブルのスキーマを使用すると、コメント、インデックス、一意のキーなどを確認できるため、かなり自明です（少なくともそれはアイデアです）。
マスターマークダウンのドキュメントには、ユーザーテーブルなどのハイパーリンクが全体に散らばっているため、読者はさまざまなテーブルに簡単に移動できます。
Rational Software Architectを使用しているため、そのデータ検出機能を使用してデータベースを文書化し、そこから注釈を付けます。
Oracleでは、テーブルにコメントを付けることができ、それをデータディクショナリに格納します。
ただし、テーブル、列、インデックスのコメントはすべて、非常に古いバージョンのERWinに保存しています。これは真実のマスターソースであり、テーブルなどを作成するためのDDLを生成します。そこから、Word文書またはPDFに抽出できます。