データベースを再設計するためのベストプラクティス
アプリケーションのデータベースを設計するときにいくつかの一般的なベストプラクティスを知っていますが、再設計についてはどうですか？
私は内部のビジネスアプリケーションの再設計を担当するチームに所属していますが、「内部」と言っていても、残念ながら、システムの実際のユーザーと連絡をとっていない層がたくさんあります。
現在のプログラムはOracle Formsにあり、正規化されていない多数のテーブルに散在しており、複数のほぼ重複するテーブルが互いのデータにわずかなバリアントを保持している場合があります。制約は、多くの場合、不十分に適用されたストアドプロシージャの形式です。タイプでさえ正しく保存されていないようです。 Oracleが無視しているように見えるあらゆる種類の不良データに遭遇しましたが、SQL Serverのインポート/エクスポートウィザードに適合しました（そうです）。 （たとえば、2桁の整数は完全な日時を構成するわけではありません！）
元のプログラムはおそらく20年前にさかのぼります。元の開発者のすべてが非常に古くに引退しており、ここの高齢者でさえ彼らが誰であるかを知りません。その結果、実際に必要な明確な要件もありません。単に、既存のアプリケーションの機能を複製して、既存のデータを保持することになっています。
書き換えの最終結果は、バックエンド用のMS SQL Serverを備えたASP.NETで実行されるWebベースのバージョンになります。
私の他の2人の開発チームメイトは私よりはるかに年上で、どちらもビジネス/ MISのバックグラウンドを持っていますが、私のチームはCSです。シニアメンバーの経験はほぼすべてOracleフォームであり、他のメンバーは主にVisual Basicでビジネスアプリケーションの作業を行ってきました。データベースの背景は、MySQLまたはSQLiteのプロジェクト用の新しいデータベースの設計に限定されていましたが、ほとんどが学部生のクラスでしたが、実際にデータベースを設計した経験があるのは私だけです。
既存のデータをすべてニュートラルな形式で読み込み、再キャストして新しいデータベースに配置する準備ができている小さなプログラムをC＃で既に作成しました。新しい正規化されたテーブル間でデータを適切に分割したり、新しい制約に従うために正しい順序で追加したりできるように、宛先データベースの設計後にロードインコードを書く予定です。その後、同じプログラムを後で再度実行できます本番データを実際に新しくデプロイした完成した再設計にコピーします。これは、データベースの実際の再設計を理解するための主なものとして残します。
私の質問の中心：既存のアプリケーションのデータベースレベルから再設計を行うためのベストプラクティスは何ですか？
データベースを正規化する方法はすでにご存じだと思います。
すべてのソフトウェアを新しいデータベースに移動するときのリスクを最小限に抑えるための戦略が必要です。
私が提案しているのは、より少ないリスクとのトレードオフとしてのより多くの仕事です。
データベースを正規化し、正規化されたデータベースに元のデータベースのデータを入力するプロセスを作成します。元のデータベースは、挿入、更新、削除用のデータベースになります。変換中、正規化されたデータベースはクエリデータベースのみになります。
作成プロセスは、クエリデータの必要性と同じくらい頻繁に実行する必要があります。 1日経ったデータが許容できる場合は、毎晩のデータ入力プロセスを実行できます。さらに最新のデータが必要な場合は、継続的なデータ入力プロセスを実行する必要があります。
新しい正規化されたデータベースを指す、新しいASP.NETシステムのクエリ部分を構築します。
新しいシステムのクエリ結果は、元のシステムのクエリ結果と比較する必要があります。
この時点で停止できます。これはビジネス上の決定であり、技術的な決定ではありません。
自由に、新しいASP.NETシステムに新しい挿入/更新/削除機能を作成します。新しい機能を作成するとき、対応する元のシステムの部分をオフにします。ある時点で、元のシステムは何も残っていません。
この方法で変換することの利点は、最初にクエリ部分を作成することでリスクを減らすことです。通常、クエリ機能は、挿入/更新/削除機能に組み込まれたビジネスロジックと比較してシンプルです。
挿入/更新/削除機能を一度に1つのプロセスに変換します。ビジネスロジックの誤解に問題がある場合は、ユーザーが元のシステムを使用している間に修正できます。
言うまでもなく、作成プロセスは完全に一貫している必要があります。
新しいシステムの開発を外部の会社に委託するように説得してください。限られたチームよりも速く、より適切にアプリケーションを開発するためのリソースを持つ優れた開発会社がたくさんあります。優れた開発会社は、あなたが上司に依頼した場合にできないことを上司に強制することもできます。PMアプリを開発するために多額のお金を受け取っている会社のIT担当者よりも多くのレベルでユーザーの関与を得るために、管理権限よりも多くのレベルでそのようなことを調整します。
事前に多額の費用がかかりますが、開発と実装のための適切なリソースを確保するには大きな時間を費やすことになります。あなたがRFPを出すことに成功した場合、私が得る入札は、あなたがやろうとしていることがあなたのマネージャーが理解するよりもはるかに複雑であることを示していると思います。
必要なデータ型を使用して、必要な正規化データベースを設計します。次に、最も難しいのはデータの移行です。最初に、古いものから新しいものにどのようにマッピングするか、新しい構造に適合しないデータをどのように処理するかについての計画が必要です。たとえば、適切な整合性の制約がない場合、データを特定できない可能性があります。単にそのデータを移動したくない場合や、移動する必要があるが、「不明」という新しい親レコードに添付する必要がある場合があります。日付が実際の日付ではない場合、移行時にフィールドにnullを入力できますか？この種の質問に対する答えが必要になります。新しいデータベース構造を使用するためにGUIの変更に取り組む開発者もいれば、移行に厳密に取り組む開発者もいることをお勧めします。移行は大変な作業であり、多くのスキルと多くの時間を要します。後付けとして残さないでください。
SQL Serverを使用しているため、SSISを介して実際の移行を行うことができます。
古いシステムとの結果が新しいシステムと同じであることを確認できるように、適切なテストケースのセットを作成します。
長年のデータがあるので、2つの部分に移行することができます。最初にほとんどのデータを移行し、次に稼働するときは変更されたデータのみを移行します。もちろん、まだ持っていない可能性のある変更されたデータを見つけるには、データベースにコントロールを配置する必要があります。一部のデータをアーカイブする場合は、この時点で検討することもできます。
MS Accessファイル（.mdb）として生まれ、その後数百のテーブルがMS SQLに配置された大規模なデータベースに成長したいくつかのレガシーアプリケーションのサポートとさらなる開発により、ほぼ毎日データベーススキーマの再設計に直面しています。サーバーですが、元のデザインの「乳児の死」が残っています。以下は、私に役立つと思われるいくつかのプラクティスです。
データベーススキーマの公開されている表面を最小限に抑えるようにしてください。
つまり、外部アプリケーションで使用できるようにするパブリックAPIを設計する必要があります。私は通常、静的データをビュー（単一のテーブルに基づいている場合でも）として実装し、動的データをパラメーター化されたビューまたはストアドプロシージャとして実装しようとしています。単一の値のみで十分なデータクエリの場合、スカラー関数も使用できます。
これら（ビュー、ストアドプロシージャ、スカラー関数）だけが（ORM経由で、または直接）外部アプリケーションから見えるようになり、すべてのCRUD操作に使用されます。その後、このスキーマは完全に凍結されますが、内部では基礎となるテーブルを変更したり、手順を改善したりできます。これにより、アプリケーションの互換性が損なわれることはありません。
本の基準ではなく、実際の基準に合わせて最適化してください。
正規化は、データベース設計に関するすべての本の大きなトピックです。しかし、実際には、正規化によってデータベースがあまりまたは遅くならない場合があります。たとえば、繰り返されるデータがあるが、繰り返しの割合が非常に低い場合などです。私は正規化に反対していません。ここで私が言おうとしているのは、ある程度の懐疑論と慎重さをもってそれに取り組む必要があるということです。
プロファイリングセッションを記録して分析します。
データベーススキーマのみに基づくデータベースの再設計は完全ではありません。データベースをそのダイナミクスで確認し、負荷テスト中にボトルネックを見つけて、それらに対処してください。 MS SQL Serverの場合、特別な Tuning Advisor があり、記録されたアクティビティトレースにいくつかの推奨を生成できます。
これが私の答えです：
まず、現在のデータベースシステムをできる限り理解してください。これらのシステムのすべての使用法とユーザーを知る必要があります。システムのすべてのソースと、ソースシステムとして機能している可能性のあるシステムを知る必要があります。
システムの運用目的、レポート目的、またはその両方に関係なく、システムのさまざまな用途をすべて特定する必要があります。データベースを使用している可能性のあるアプリケーションと上流システムを特定します。そうすることで、現在使用されていない不要になった現在のデータベースの要素を知ることができます。
また、データベースにデータをロードし、データベースからデータを抽出する現在のETLプロセスを分析して理解します。
データベースのすべてのデータ要素を理解し、重複する要素を特定するのに役立つボックスマトリックスを作成できるかどうかを理解します。
すべての情報を入手したら、要件収集の一環として収集した情報を使用してデータベースを初めて設計する場合と同じように、再設計に取り組むことができます。
幸運を！