69

(注: これはHow do you document your database structure?に近いと思いますが、同一ではないと思います。)

私は、文字通り数百のテーブルとビューを持つデータベースのある場所で仕事を始めました。すべて母音がほとんどなく、ドキュメントもありません。また、データベース スキーマへの不当な変更も許可されていません。また、自分のマシンのテスト用のデータベース (吹き飛ばされ、定期的に再作成される) 以外のデータベースに触れることもできないため、誰の助けにもならないようなコメントを追加することはできません。

"Toad" を使用して ER 図を作成しようとしましたが、48 時間実行したままにしておくと、何も表示されず、コンピューターを元に戻す必要がありました。私は他の最近採用した人たちと話していて、特定のテーブルやその列が何を意味するのか分からなくなったときはいつでも、開発者 wiki でそれを更新するべきだと提案しました。

では、これを行う良い方法は何ですか? テーブル/ビューとその列をリストして、それらを埋めていくだけですか? 私が持っている基本的なツールは、Toad、Oracle の「SQL Developer」、MS Office、および Visio です。

##このコメントを使用してこれを再開しようとしています

4

10 に答える 10

79

私の経験では、ER（またはUML）ダイアグラムは最も有用なアーティファクトではありません。テーブルが多数あるため、ダイアグラム（特にリバースエンジニアリングされたダイアグラム）は、多くの場合、誰も何も学ばない大きな複雑な混乱です。

私のお金のために、いくつかの優れた人間が読めるドキュメント（おそらくシステムのより小さな部分の図で補足されている）はあなたに最も多くのマイレージを与えるでしょう。これには、テーブルごとに次のものが含まれます。

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

上記のすべてで、文書化するために文書化しないでください-明白なことを言い換える文書化は人々の邪魔になります。代わりに、最初はあなたを混乱させたものに焦点を合わせ、本当に明確で簡潔な説明を書くのに数分を費やしてください。それはあなたがそれを熟考するのを助け、そしてそれはこれらのテーブルに初めて遭遇する他の開発者を大いに助けます。

他の人が述べているように、Enterprise Architect、Red Gate SQL Doc、さまざまなベンダーの組み込みツールなど、これを管理するのに役立つさまざまなツールがあります。しかし、ツールのサポートは役に立ちますが（さらに、大規模なデータベースでは重要です）、データベースの概念モデルを理解して説明するという大変な作業を行うことが真の勝利です。その観点からは、テキストファイルでそれを行うこともできます（ただし、Wiki形式で行うと、複数の人が共同でそのドキュメントに段階的に追加できるようになります-したがって、誰かが何かを理解するたびに、成長するボディに追加できますドキュメントの即時）。

于 2008-12-15T19:06:26.100 に答える
7

DB 定義にはEnterprise Architectを使用します。UML で定義されたストアド プロシージャ、トリガー、およびすべてのテーブル定義が含まれます。プログラムの 3 つの優れた機能は次のとおりです。

  1. ODBC 接続から UML ダイアグラムをインポートします。
  2. DB全体のSQLスクリプト(DDL)を一度に生成
  3. DB のカスタム テンプレート ドキュメントを生成します。

UML ツール内でクラス/テーブル定義を編集し、写真を含む完全に説明的なドキュメントを生成できます。自動生成されたドキュメントは、MSWord を含む複数の形式にすることができます。スキーマには 100 未満のテーブルがあり、非常に管理しやすいものです。

開発者としての 10 年以上の経験の中で、他のツールにこれほど感銘を受けたことはありません。EA は、Oracle、MySQL、SQL Server (複数のバージョン)、PostGreSQL、Interbase、DB2、および Access を一挙にサポートします。問題が発生したときはいつでも、彼らのフォーラムが私の問題に迅速に答えてくれました. 強くお勧めします！！

DB の変更が入ると、EA で変更を加え、SQL を生成し、バージョン管理 (svn) にチェックインします。構築にはHudsonを使用しており、チェックインされた sql を変更したことがわかると、スクリプトからデータベースを自動構築します。

（ほとんどが私の別の回答から盗まれました）

于 2008-12-15T18:57:01.390 に答える
4

データベースのドキュメントへのアプローチ方法に関する良い投稿は次のとおりです。

于 2011-05-04T07:10:00.883 に答える
3

ウィキ ソリューションは、ハイパーリンクと共同編集をサポートしますが、ウィキは、それを整理して最新の状態に保つ人々と同じくらい優れたものになります。使用するツールに関係なく、ドキュメント プロジェクトの所有権を取得する人が必要です。その人は他の知識のある人を巻き込んで詳細を記入するかもしれませんが、情報を整理する責任を負うのは 1 人である必要があります。

ツールを使用してリバース エンジニアリングによって ERD を生成できない場合は、TOAD または VISIO を使用して手動で設計する必要があります。

何百ものオブジェクトを含む ERD は、ボックスや行が多すぎて読みにくくなるため、開発者向けのガイドとしてはおそらく役に立ちません。非常に多くのオブジェクトを含むデータベースでは、それぞれ数十のテーブルとビューの「サブシステム」が存在する可能性があります。したがって、これらのサブシステムのカスタム ダイアグラムを作成する必要があります。ツールに作成してもらうことを期待するのではありません。

テーブルのグループが 1 つの図で 1 つのオブジェクトによって表され、そのグループが別の図で展開される疑似 ERD を設計することもできます。

単一の ERD または ERD のセットでは、この複雑なシステムを文書化するには不十分です。オブジェクト指向システムを文書化するにはクラス図が適切であるのと同様です。ERD を図として使用して、ドキュメントを作成する必要があります。各テーブル、各列、およびテーブル間の関係の意味と使用についてのテキストによる説明が必要です (特に、そのような関係が参照整合性制約によって表されるのではなく暗黙的に示されている場合)。

これはすべて大変な作業ですが、それだけの価値はあります。スキーマが文書化されている明確で最新の場所があれば、チーム全体が恩恵を受けるでしょう。

于 2008-12-15T18:58:21.577 に答える
1

同じ船に乗っている仲間の開発者と一緒に仕事をする余裕があるので、必要な情報を最も簡単に伝えられると思うものを彼らに尋ねることをお勧めします。私の会社には 100 を超えるテーブルがあり、上司はすべてが接続されている特定のセット テーブルの ERD をくれました。また、1 つの大規模な ERD を小さくて管理しやすい ERD の束に分割することもできます。

于 2008-12-15T18:30:51.257 に答える
1

エンド ユーザーにデータベースを説明することが主な目的である場合、 Ooluk Data Dictionary Managerが役立つことがわかります。これは、テーブルと列に説明を添付し、それらの説明の全文検索を可能にする、Web ベースのマルチユーザー ソフトウェアです。また、ラベルを使用してテーブルを論理的にグループ化し、それらのラベルを使用してテーブルを参照することもできます。テーブルと列にタグを付けて、データベース間で類似のデータ項目を見つけることができます。

このソフトウェアでは、API を使用して、テーブル名、列名、列のデータ型、外部キーなどのメタデータ情報を内部リポジトリにインポートできます。JDBC データ ソースのサポートが組み込まれており、API ソースが ASL 2.0 で配布されているため、さらに拡張できます。多くの RDBMS から COMMENTS/REMARKS を読み取るようにコーディングされています。インポートされた情報はいつでも手動で上書きできます。テーブルと列について格納できる情報は、カスタム フィールドを使用して拡張できます。

データ ディクショナリ マネージャーは、リレーショナル データベース専用に設計されていないため、テーブルと列の代わりに「データ オブジェクト」と「属性」という用語を使用します。

ノート

  • トリガー、インデックス、統計などのデータベースの技術的側面を記述することが重要な場合、このソフトウェアは最適なオプションではありません。ただし、ハイパーリンク カスタム フィールドを使用して、技術的なソリューションをこのソフトウェアと組み合わせることができます。
  • ソフトウェアは ERD を生成しません

開示：私はこの製品を開発する会社で働いています。

于 2015-06-23T10:08:03.883 に答える
0

百聞は一見に如かずということで、テーブル間の関係がひと目でわかる ER 図を作成することをお勧めします。これは、テキストのみの説明では難しいことです。

データベース全体を 1 つの図に収める必要はなく、セクションに分割してください。私たちは仕事で Visual Paradigm を使用していますが、EA は ERWIN と同様に優れた代替手段であり、他にも同様に優れたものがたくさんあることは間違いありません。

忍耐力がある場合は、html を使用して表と列を文書化すると、文書へのアクセスが容易になります。

于 2008-12-15T21:31:57.567 に答える