データベース設計は、この点でアプリケーション設計とは異なります。
多くの場合、クライアントの再考はアプリケーションを完全に変更しますが、企業の基盤となるデータモデルにはほとんど変更がありません。この理由は、クライアントがビジネスプロセスの観点から考えている傾向にありますが、基本的なデータに関しては考えていないためです。ビジネス処理とデータ処理は緊密に結合されています。データ記憶装置の密接度は低い。
古典的なデータベース設計の当時、設計者は、データベース設計を(少なくとも)論理設計と物理設計の2つの層に分割してこのパターンを悪用する方法を学びました。ビジネスプロセスの変更には、アプリケーションの完全な書き換えと、データベースの物理的な設計の大幅な変更が必要ですが、論理設計の変更がほとんど必要ありません。
データベース設計でこのようなレイヤーが分離されなかった場合、影響を受けるものとそうでないものを区別することは難しいです。テーブルと列から始めましょう。変更があれば、それが入っているテーブルから列を削除する必要があるか、新しい列を作成する必要があるかどうか自問してください。答えがノーなら、あなたは運がいいです。次に、データベースに置かれた制約(PRIMARY KEY、FOREIGN KEY、UNIQUE、NOT NULLなど)を調べます。これらの制約は、クライアントの変更によって強化されたり緩められたりする可能性があります。そうでなければ、あなたは運がいい。データベースに制約を宣言しておらず、アプリケーションコードですべての整合性保護を行うことを選択した場合、おそらく運が悪いでしょう。
テーブルのインデックスの変更や、アプリケーションでのデータの操作方法については、依然としてかなりの労力が必要です。しかし、あなたは古いシステムへの投資の一部を回収しました。
アプリケーション自体は、データベースよりもプロセスにおけるクライアントの変更に対して脆弱です。データベース設計がアプリケーション設計によって完全に推進された場合、不運になる可能性があります。
すべてのITプロジェクトのように聞こえます。私は解決策が2つの部分のジン、3つの部分のトニックの –
があったことを見つける。私は助けに爪の大きなバットを見つける – Calanus
私は常に氷の上に4部のジャック、1部の水に部分的だった...そして楽しむ〜 – BigBlondeViking