エンティティリレーションシップダイアグラム(簡潔にするためにERD)を作成し、属性を派生させました。
リレーショナルスキーマを使用したデータベース設計に関しては、テーブルを設計し、すべてを適切にリンクしました。
派生属性を持つテーブルに列を追加する必要があるかどうかわかりませんか?たとえば、派生属性は次のように計算されます。
Total
= Price * Quantity
また、次の例示的なテーブルスキーマに関連しています。
Customer (
ID,
CustomerName,
ItemsID,
Total
);
Total
をCustomer
テーブルに含める必要がありますか?
できることは、リレーショナルモデルのさまざまな用途に常に適切であるとは限りません。顧客の売上を分析するためにデータウェアハウスを作成する場合は、派生属性が適切です。私はこれを、レポートツールのサマリーテーブルに対して実行しました。クエリは、合計などの多くの集計で30以上のテーブルを結合し、エンティティが持っていたすべての値を表示します。要約された表、毎日更新され、リストされた派生属性は、レポートの優れたソリューションでした。
派生属性を使用するオンライントランザクション処理データベースの場合、常に最適なソリューションとは限りません。
例:現在、合計は価格*数量です
来月の経営陣は、暦年に$ 1000を超える注文をした顧客に対して10%の割引を実装することを決定しました。現在、合計列は柔軟性に欠けています。
残念ながら、Total = Price * Quantityなど、今日は「変化しない」と言えることは、ビジネスロジックの例です。ビジネスロジックは、予期しない方法でいつでも変更できます。
例を続けると、...経営陣が割引を設けており、customersテーブル、ordersテーブルがある場合は、割引テーブルを追加するだけです。次に、その日のビジネスロジックをカプセル化したビューを作成して、総売上高を導き出すことができます。ロジックが変更されると、テーブルで修正された派生属性を再計算するよりもはるかに簡単にビューを変更できます。
また、本当に準備したい場合は、ビジネスロジックの変更をデータベースのテーブルに格納し、「誰が、何を、なぜ」を隠すことができます。したがって、マネージャーのボブが割引を提供し、5年後に新しいマネージャーのスーが「割引の提供をいつ開始し、誰が承認したか」と述べたとします。あなたはデータベーススターです。
派生属性を含むテーブルを作成しないでください。代わりに、検索時に値を計算できます。テーブルに何百万ものレコードがあると仮定すると、冗長フィールド(例:totall)はすべてのフィールドに書き込まれますが、取得時に計算できます。