MSSQL 2005 データベースのエンティティ ダイアグラムを作成する必要があります。
リレーションシップは一貫して主キーを使用して定義されますが、外部キーはどこにもありません。Microsoft Visio の「リバース エンジニア」機能を試してみましたが、もちろん外部キーがないために失敗しました。
したがって、関係を描画するときに外部キーだけに依存しないダイアグラム ツールが必要です。
MSSQL 2005 データベースのエンティティ ダイアグラムを作成する必要があります。
リレーションシップは一貫して主キーを使用して定義されますが、外部キーはどこにもありません。Microsoft Visio の「リバース エンジニア」機能を試してみましたが、もちろん外部キーがないために失敗しました。
したがって、関係を描画するときに外部キーだけに依存しないダイアグラム ツールが必要です。
正しい外部キー関係を作成するスクリプトを作成し、ダイアグラム ツールを実行してから、外部キーを削除する 2 つ目のスクリプトを実行します。
これにより、データベースをあまり混乱させることなくツールを使用できるようになります。最初のスクリプトが失敗した場合は、データにも問題があることがわかります。
[編集] 外部キー列の命名規則がある場合は、スクリプト言語を使用して SQL を生成できます。
それも失敗する場合は、どの設計ツールでも不足しているリレーションを作成できるはずです。つまり、データの不整合が発生する可能性があります。ここでの解決策は、テーブル定義のスナップショットを作成し、プライベート データベース サーバー上に (データなしで) データベースを再作成することです。そこでは、元のシステムを中断することなく、好きなだけデザインをいじることができます。
設計の修正が完了したら、必要に応じてコマンドを抽出して外部キーを作成し、それを実際のシステムに適用できます。そうすれば、データベース内の混乱がすでにどれほど大きいかを感じることができます。そうでない場合は、単純に新しいコピーを保持し、そこに設計変更を加え、それらを確認した後、変更を本番データベースに移行できます。
私自身のシステムでは、現在の開発および運用データベースのクローンをすばやく作成するためのスクリプトが常にあります。通常、Derby や HSQL などの組み込みデータベースを使用します。ただし、プロセスにフィルタを追加する$(SCHEMA)
と、DDL ファイルで使用して、同じデータベースを同じサーバー上の異なるスキーマにインストールできます。これを使用して、各移行テストの結果を新しいスキーマに保存するデータ移行プロジェクトで大成功を収めました (TABLE_DATE_XX
はXX
2 桁の数字で、1 日に複数のテストを作成できます)。
これにより、さまざまな修正を検証したり、2 つの移行を比較したりすることができました。プロセス全体が 100% 自動化されているため、既存のスキーマを修正するよりも新しいスキーマを作成する方が安価になりました。