非正規化を使用したデータベース設計

正規化の規則はパフォーマンスを考慮していません。 場合によっては、パフォーマンス向上のための非正規化を考慮する必要があります。

物理設計では、アナリストがエンティティをテーブルに変換し、属性を columns.The の倉庫の住所の列に変換します。この列は、部品と倉庫に関する情報を含むテーブルの一部として最初に表示されます。 表の設計をさらに正規化するために、アナリストは、その表からウェアハウス・アドレス列を除去します。 アナリストはまた、ウェアハウスのみに関する情報を含む表の一部として、列の定義も行います。

表の正規化は、一般的には推奨する方法です。 アプリケーションで、ウェアハウスのアドレスを含む、パーツおよびウェアハウスの両方に関する情報が必要な場合は、どうしますか? 正規化規則の前提は、SQL ステートメントは 2 つの表を結合することにより情報を検索できるということです。 正規化の結果としてパフォーマンス上の問題が発生することがあるということが問題になる場合があります。 例えば、ユーザーの照会で、複数の関連する表に存在するデータを表示することがあります。この場合、結合が多すぎる結果となります。 表の数が多くなると、表のサイズ、使用可能な索引数などによって、アクセス・コストが増加することがあります。 例えば、索引が使用できない場合、数多くの大規模な表の結合にかなりの時間がかかることがあります。 表を非正規化する必要がある場合があります。 非正規化 は、列を複数の表に意図的に重複させ、結果としてデータ冗長度が増します。

両方の表にウェアハウスのアドレスを含む列がある設計を取り上げてみます。 この設計で結合操作が不要になる場合、冗長性は価値があります。 ウェアハウスのアドレスはほとんど変更されません。変更した場合には、SQL を使用してすべてのインスタンスをかなり容易に更新できます。

物理設計を構築する場合、同僚とともにデータを非正規化するかどうかを決定する必要があります。 特に、ハイパフォーマンス要件のある結合によって頻繁にアクセスされる表または表の一部を結合するかどうかを決定する必要があります。 これは、この説明では具体的なアドバイスを行うことができない、複雑な決定です。 決定するには、パフォーマンス要件、さまざまなデータ・アクセス方式、およびデータの非正規化コストを評価する必要があります。 トレードオフを考慮する必要があります。複数の表において、頻繁に要求される列を重複することは、結合を実行する時間よりもコストは少なくて済みますか?

次の図では、パーツ、ウェアハウス、およびウェアハウス・アドレスに関する情報を、2 つの表に、両方とも正規形で示しています。

次の図に、非正規化された表を示します。

多対多関係の解決は特に重要なアクティビティーです。そうすることにより、物理データベース設計での明瞭性と保全性を維持できるからです。 多対多関係を解決するには、関係表 を導入します。関係表は、2 つの表を相互に結びつける、つまり関連付ける、中間表です。

例

従業員は多くのプロジェクトに従事しています。 プロジェクトには多くの従業員がいます。 論理データベース設計では、この関係を、プロジェクトと従業員との間の多対多の関係として表します。 この関係を解決するには、新たな関係表 EMPLOYEE_PROJECT を作成します。 従業員およびプロジェクトの各組み合わせに対して、対応する行が EMPLOYEE_PROJECT 表に含まれています。 表の主キーは、従業員番号 (EMPNO) とプロジェクト番号 (PROJNO) から構成されています。

例

リピーティング・グループの使用に関連する、行う必要のあるもう一つの決定。 頻繁に使用されるトランザクションで、特定の年の月ごとに販売されるワイヤー数が必要であると想定します。 パフォーマンス要因では表の変更を正当化する場合があります。このために、リピーティング・グループを保管することにより第 1 正規形の規則に違反します。 この場合には、リピーティング・グループは MONTH、WIRE です。 表には、各月に販売されたワイヤー数の行が含まれています (1 月のワイヤー数、2 月のワイヤー数、3 月のワイヤー数など)。