不明なデータベースの理解を開始する場所

だから、タイトルはそれを要約しています。

28個のテーブルと86個のストアドプロシージャを備えたSQL Serverデータベースがあり、リバースエンジニアリングする必要があります。一部のテーブルは決して使用されず、すべてのprocも使用されるわけではないことを確信しています。

最大の問題は、このDBで使用するために作成されたすべてのWindowsサービス、およびすべてのソフトウェアとデータベースのドキュメントが失われ、システム全体を設計した人物がどこにも見つからないことです。

関係を理解するのに役立つER図を作成できましたが、データベース管理の経験がないため、どこから始めるべきかわかりません。

また、この種の質問がここで質問されることを意図していない場合は申し訳ありません。

開始するための3つの非常に簡単な手順：

1）

USE DatabaseName

SELECT    [TableName] = OBJECT_NAME(object_id),
last_user_update, last_user_seek, last_user_scan, last_user_lookup
FROM    sys.dm_db_index_usage_stats
WHERE    database_id = DB_ID('DatabaseName')

クラスタ化インデックスを含め、各インデックスが最後に使用された時間を通知します。したがって、少なくとも、どのテーブルがアクセスされているか（アクセスされていないか）を確認してください。

2）アプリの使用中に1時間程度拡張イベントセッション（またはSQL 2012以前を実行している場合はサーバー側のプロファイラートレース）をオンにします。また、アプリケーションでさまざまなアクションを特定の順序で実行するようにユーザーに依頼して、トレース/セッションと関連付けることができます。

役に立つ提案：アプリが使用する接続文字列を変更できる場合は、「; Application Name = AppNameGoesHere」を追加して、その特定のアプリケーション名でトレースフィルタリングを実行できるようにします。とにかく良い練習。

3）非実稼働サーバーで動作するアプリケーションのバージョンを取得します。アプリケーションの動作駆動テストのリストを作成します（「ユーザーが[新しいアイテム]ボタンをクリックすると、そのユーザーの新しいアイテムが作成されます」など）。テストに関係ないと思われるオブジェクトのソフト削除を開始します。 （objectName_DEPRECATED_YYYYMMDDのような形式を使用します-日付は実際に削除する予定の日付です。）すべてのテストを再検証します。

拡張イベントセッション、インデックス使用DMV、およびソフト削除の組み合わせにより、アプリケーションで使用されているメインオブジェクトと、どのオブジェクトが何を行うかについての一般的なコンセンサスを特定できるはずです。

幸運を！

最初に行う最善の方法は、SQL Power Docを使用してデータベースを文書化することです

Windows PowerShellを使用したSQL ServerとWindowsのドキュメント

SQL Power Docは、SQL Serverインスタンスとその基盤となるWindows OSおよびマシン構成を検出、文書化、診断するWindows PowerShellスクリプトとモジュールのコレクションです。SQL Power Docは、SQL Server 2000から2014までのすべてのバージョンのSQL Server、およびWindows ServerのすべてのバージョンとWindows 2000およびWindows XPからWindows Server 2012 R2およびWindows 8までのWindowsオペレーティングシステムで動作します。 Windows Azure SQLデータベースのドキュメント化。

注：私はこれを使用しましたが、データベースサーバーインスタンスの文書化と理解において非常に良いスタートを切ることができます。

私はかつて同じような状況にあったので、これは難しい仕事から不可能な仕事になると言うことができます。ソースコード（> 100k行のコード）、実行中のサービス、実行中のデータベース（〜50テーブル）のみがあり、このアプリケーションのユーザーと実行中のデータベースとサービスのコピーを除いて、それについて尋ねる人はいませんでしたテスト環境（これはソースコードなしで数バージョン先のバージョンでした）。もう1つの要件は、サービスが顧客の外部にあったため、24時間年中無休で実行する必要があることでした。この状況は、開発者とドキュメントを含むほとんどのスタッフがほぼ同時に退社したために発生しました。大まかな概要/ドキュメントを入手するには、6か月以上かかりました。多くのテーブルと関数がありましたが、それらは将来使用するためのものであるか、完全に実装されなかったため効果がありませんでした。不良または非推奨または未リリースの機能。6か月後、ドキュメントを書き直さなければなりませんでした。新しいものやもの同士の関係を発見し、以前は間違った仮定をしていたからです。

なぜこれを言っているのですか？そのような状況では、最初から始めて古いアプリケーション（または時間の経過とともに変更された場合や新しいメジャーリリースが必要な場合は新しいアプリケーション）の要件を満たす新しいアプリケーションを作成する方が簡単で安価な場合があるためです。または、何を期待する必要があるかを説明します。

本当にリバースエンジニアリングしたい場合は、次の手順をお勧めします。

• システム全体のバックアップを作成してください！（最初：いつ必要になるかわかりません。次：次のステップに必要です）
• システムのコピー（サービスとデータベース）を再作成し、それを使用して作成する方法を書き留めます。これは、リバースエンジニアリング中に何度も台無しにすることになるため、今後数か月間に何度も行う必要があるからです。
• テーブル間の依存関係を持つER図を作成する
• ERダイアグラムにはほとんど含まれていないため、各テーブル、ストアドプロシージャの依存関係を表示および文書化します。
• ユーザーに尋ねてそれ自体を使用することで、ソフトウェアが何をすべきかを理解します（テストシステムで行うのが最善です）
• サービスのソースコードが利用可能な場合：サービスの概要を取得し、DBを呼び出して文書化します（doxygenは、関数呼び出し階層の大まかな文書を取得するための優れたツールです）
• テーブル名とその列を見て、DBの大まかな概要を取得してください
• 使用中にデータベースを見る
• 前の4つの手順では、テーブルを3つのカテゴリに分割します（アプリケーションによって異なる場合があります）：静的データ（serverconfigurationのようなサーバーの実行中に変化しないデータ、外部キーを使用して他のテーブルの有効な値を制限する列挙型） 、...）、構成データ（ユーザー設定などめったに変更されないデータ）およびOLTPデータ（チャットサーバーのユーザーメッセージ、フォーラムへの投稿、機械制御システムの測定値、オンラインゲームでの戦闘、 ...）
• 満足するか、あきらめるまで、前の5つの手順を繰り返します
• あなたのコード/システム/データベースを維持することになった人が、あなたがどこに住んでいるかを知っている暴力的なサイコパスになるかのように文書化してコードを書いてください。

幸運を願っています ;）

私はコメントを投稿するのに十分な担当者がいませんが、あなたの質問を手伝いたいです

getting the SQL Power Doc to work。

ドキュメントページの手順に従うと、かなり簡単に機能します。上から始めてください。

https://sqlpowerdoc.codeplex.com/wikipage?title=Guide%20For%20PowerShell%20Beginners