データベースを再設計するためのベストプラクティス

アプリケーション用のデータベースを設計する際の一般的なベストプラクティスをいくつか知っていますが、再設計についてはどうですか？

私は「内部」と言っているにも関わらず、内部ビジネスアプリケーションの再設計を担当するチームに所属していますが、残念ながら、システムの実際のユーザーとの接触から多くの層の人々がいます。

現在のプログラムは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を出すことができた場合、あなたが得る入札は、あなたがやろうとしていることはあなたのマネージャーが理解しているよりもはるかに複雑であることを示していると思います。

必要なデータ型を使用して、必要な正規化データベースを設計します。次に、最も難しい部分はデータの移行です。最初に、古いものから新しいものへのマッピング方法と、新しい構造を満たさないデータをどうするかについて計画を立てる必要があります。たとえば、適切な整合性制約がなければ、データは特定できません。そのデータを単に移動しないか、移動する必要があるが、「不明」と呼ばれる新しい親レコードに添付する必要がある場合があります。日付が実際の日付ではない場合、移行時にフィールドにヌルを入れることはできますか？これらの種類の質問に対する答えが必要になります。開発者の中には、GUIを変更して新しいデータベース構造を使用する開発者と、移行に厳密に取り組む開発者がいることをお勧めします。移行は大きなタスクです。多くのスキルと時間がかかります。後付けのままにしないでください。

SQL Serverを使用しているため、SSISを介して実際の移行を行うことができます。

古いシステムと新しいシステムで同じ結果が得られるように、テストケースの適切なセットを作成します。

長年のデータがあるため、2つの部分に移行することができます。最初に大部分のデータを移行し、次に稼働する時間になったら、変更されたデータのみを移行します。もちろん、まだ持っていない可能性のある変更されたデータを見つけることができるように、データベースにコントロールを配置する必要があります。いくつかのデータをアーカイブする場合は、この時点で検討することもできます。

MS Accessファイル（.mdb）として生まれ、その後MS SQLに数百のテーブルがある大規模データベースに成長したいくつかのレガシーアプリケーションのサポートとさらなる開発のために、ほぼ毎日データベーススキーマの再設計に直面しています。サーバーですが、元のデザインの「乳児の衰弱」がまだ残っています。以下は、私にとって役立つと思われるいくつかのプラクティスです。

データベーススキーマの公開されている表面を最小限に抑えるようにしてください。

つまり、外部アプリケーションで利用できるパブリックAPIを設計する必要があります。私は通常、静的データをビューとして（単一のテーブルのみに基づいている場合でも）、動的データをパラメーター化されたビューまたはストアドプロシージャとして実装しようとします。単一の値で十分なデータクエリの場合は、スカラー関数も使用できます。

これら（ビュー、ストアドプロシージャ、およびスカラー関数）のみが外部アプリケーションに（ORM経由または直接）表示され、すべてのCRUD操作に使用されます。このスキーマは完全にフリーズされますが、内部的には基になるテーブルを変更したり、プロシージャを改善したりできます。これにより、アプリケーションとの互換性が損なわれることはありません。

本からのものではなく、実際の基準に合わせて最適化してください。

正規化は、データベース設計に関するすべての本で大きなトピックです。しかし、現実には、たとえば、繰り返されるデータがあるが、繰り返しの割合が非常に低い場合など、正規化ではデータベースが大幅に低下したり、データベースの速度が低下したりすることはありません。私がここで言いたいのは、あなたは懐疑心と慎重さをもってそれに取り組む必要があるということです。

プロファイリングセッションを記録し、分析します。

データベーススキーマのみに基づくデータベースの再設計は完全ではありません。データベースのダイナミクスを確認し、負荷テスト中にボトルネックを見つけて対処します。MS SQL Serverの場合、記録されたアクティビティトレースに関する推奨事項を生成できる特別なチューニングアドバイザーがあります。

私の答えは次のとおりです。

1. まず、できる限り現在のデータベースシステムを理解します。これらのシステムのすべての使用方法とユーザーを知る必要があります。システムのすべてのソースと、それらがソースシステムとして機能しているシステムを知る必要があります。

2. 運用用かレポート用か、その両方かを問わず、システムのさまざまな用途をすべて特定する必要があります。データベースを使用している可能性のあるアプリケーションとアップストリームシステムを特定します。そうすることで、現在のデータベースの古い要素や不要になった要素を知ることができます。

3. また、データベースにデータをロードし、データベースからデータを抽出する現在のETLプロセスを分析および理解します。

4. データベースのすべてのデータ要素を理解し、重複要素の識別に役立つボックスマトリックスを構築できるかどうか。

5. すべての情報を取得したら、要件収集の一部として収集した情報を使用してデータベースを初めて設計するかのように、再設計にアプローチできます。

6. がんばろう！