データベース設計パラダイム

デザイン|データ|データベース|データベースデザイン

リレーショナル データベースは、設計時に特定のルールに従う必要があります。特にデータベース設計パラダイムについては、1NF (第 1 正規形)、2NF (第 2 正規形)、3NF (第 3 正規形)、および BCNF については後で紹介します。 データベースを設計するときに、これらのパラダイムに準拠できれば、データベース設計の達人になることができます。

第一正規形 (1NF): 関係スキーマ R の各特定の関係 r において、各属性値が細分化できない最小のデータ単位である場合、R は第一正規形の関係であると言われます。例: 従業員番号、名前、および電話番号がテーブルを形成する場合 (人はオフィスの電話番号と自宅の電話番号を持っている可能性があります)、それを 1NF に標準化するには 3 つの方法があります:
1 つは、従業員番号と従業員番号を繰り返し保存することです。名前。この場合、キーワードは電話番号のみです。
2 番目に、従業員番号がキーワードであり、電話番号は職場の電話番号と自宅の電話番号の 2 つの属性に分けられます。
3 番目に、従業員番号がキーワードですが、各レコードには必ず 1 つの電話番号しか含めることができません。番号。
上記の 3 つの方法のうち、最初の方法が最も推奨されません。実際の状況に応じて、後の 2 つのケースを選択してください。

第 2 正規形 (2NF): 関係パターン R (U, F) 内のすべての非主属性がいずれかの候補キーワードに完全に依存している場合、関係 R は第 2 正規形に属すると言われます。
例: コース選択関係 SCI (SNO、CNO、GRADE、CREDIT) SNO は学生番号、CNO はコース番号、GRADEGE は成績、CREDIT は単位です。 上記の条件に基づくと、キーワードは組み合わせキーワード (SNO、CNO) です。
上記のリレーショナル モデルをアプリケーションで使用すると、次の問題があります。
a. 同じコースを 40 人の学生が受講すると仮定した場合、単位は40回繰り返されます。
b. 更新異常 特定の科目の単位数が調整されると、対応するタプルの CREDIT 値が更新され、同じ科目の単位数が異なる場合があります。
c. たとえば、新しいコースを開く予定の場合、誰も受講していなく、学生 ID キーワードがないため、コースとクレジットを入金する前に誰かが受講するのを待つ必要があります。 。
d. 削除の例外、学生がコースを完了した場合は、現在のデータベースから選択レコードを削除します。新入生がまだ一部のコースを受講していない場合、コースと単位記録は保存できません。
理由: 非キーワード属性 CREDIT は機能的にのみ CNO に依存します。つまり、CREDIT は完全にではなく、結合されたキーワード (SNO、CNO) に部分的に依存します。
解決策: 2 つの関係モード SC1 (SNO、CNO、GRADE)、C2 (CNO、CREDIT) に分割します。新しい関係には、SC1 の外部キーワード CNO を通じて接続される 2 つの関係スキーマが含まれます。必要に応じて、元の関係を復元するために自然な接続が作成されます

第 3 正規形 (3NF): 関係スキーマ R(U、すべて非) の場合-F) の主属性がどの候補キーワードにも推移的に依存しない場合、関係 R は第 3 正規形に属すると言われます。
例: S1 (SNO、SNA​​ME、DNO、DNAME、LOCATION) 各属性は、学生番号、
名前、学科、学科名、学科住所を表します。
キーワード SNO が各属性を決定します。単一キーワードなので部分依存の問題はないので2NFでなければなりません。ただし、この関係には多くの冗長性が必要であり、生徒の位置に関連するいくつかの属性 DNO、DNAME、および LOCATION が繰り返し保存、挿入、削除、および変更されるため、上記の例と同様の状況が発生します。
原因: 関係に推移的な依存関係があります。つまり、SNO -> DNO です。 ただし、DNO -> SNO は存在せず、DNO -> LOCATION であるため、重要な点は、SNO が推移的な依存関係 LOCATION を通じて LOCATION 関数を決定することです。つまり、SNO は非プライマリ属性 LOCATION を直接決定しません。
解決策の目的: 各関係モデルに推移的な依存関係が存在することはできません。
解決策: 2 つの関係 S (SNO、SNA​​ME、DNO)、D (DNO、DNAME、LOCATION) に分割します。
注: 関係 S は外部キーワード DNO なしではできません。そうしないと、2 つの関係間の接続が失われます。

BCNF: 関係スキーマ R (U, F) のすべての属性 (主属性と非主属性を含む) が R に依存する候補キーワードを渡さない場合、関係 R は BCNF に属すると言われます。または、リレーショナル スキーマ R、各決定要因に (キーワードに含まれるのではなく) キーワードが含まれる場合の RCNF のリレーショナル スキーマ。
例: 部品管理関係モデル WPE (WNO、PNO、ENO、QNT) は、それぞれ倉庫番号、部品番号、従業員番号、数量を表します。次の条件が適用されます
a. 倉庫には複数の従業員がいます。
b. 従業員は 1 つの倉庫でのみ作業します。
c. 各倉庫では専任担当者が 1 種類のアクセサリを担当しますが、1 人で複数のアクセサリを管理することもできます。
d. 同じモデルのアクセサリは複数の倉庫に保管できます。
分析: 上記より、PNO は QNT を決定できません。結合された属性 (WNO、PNO) によって決定されます (WNO、PNO) -> ENO。各倉庫には1種類のアクセサリを専任担当者が担当し、1人で複数のアクセサリを管理できるため、担当者は属性(WNO、PNO)の組み合わせだけで決定でき、(WNO、PNO)が存在します。 ->ENO。従業員は 1 つの倉庫でのみ作業するため、ENO -> WNO が存在します。各倉庫の 1 種類のアクセサリは専任担当者が担当し、従業員は 1 つの倉庫でのみ作業するため、(ENO、PNO)->QNT が存在します。
(WNO, PNO) -> QNT, (WNO, PNO) -> ENO なので、(WNO, PNO) はタプル全体を決定でき、候補キーワードになります。 ENO→WNO、(ENO,PNO)→QNTによれば、(ENO,PNO)もタプル全体を決定でき、もう一つの候補キーワードとなる。属性 ENO、WNO、および PNO はすべてプライマリ属性であり、非プライマリ属性 QNT は 1 つだけあります。これは、機能的には候補キーワードに完全に依存しており、直接依存しているため、関係パターンは 3NF です。
主な属性を分析します。 ENO->WNO であるため、主属性 ENO が WNO の決定要因になりますが、それ自体はキーワードではなく、結合されたキーワードの一部にすぎません。これにより、メイン属性 WNO が別の候補キーワード (ENO, PNO) に部分的に依存することになります。これは、(ENO, PNO) -> ENO ですが、その逆は真ではなく、P->WNO であるため、(ENO, PNO) - > WNO も推移的な依存関係です。
候補キーワードに対する非主属性の推移的な依存性はありませんが、候補キーワードに対する主属性の推移的な依存性があり、これも問題を引き起こします。たとえば、新入社員は倉庫で働くように割り当てられていますが、一時的にインターンシップ段階にあり、特定の付属品の管理について独立した責任を負いません。キー PNO の一部が欠落しているため、関係に挿入できません。また、付属品に関わらずセキュリティ責任者が変更になった場合、付属品の削除に伴いその従業員も削除されます。
解決策: 管理 EP (ENO, PNO, QNT) に分割し、キーワードは (ENO, PNO) 作業 EW (ENO, WNO) で、そのキーワードは ENO です。
欠点: 分解後の関数の依存関係の保持が不十分です。この例では、分解により関数の依存関係 (WNO、PNO)->ENO が失われ、元のセマンティクスが破壊されます。これは、専任の担当者が各倉庫の各コンポーネントに責任を負っていることを反映するものではありません。コンポーネントは 2 人以上のユーザーによって同時に管理される可能性があります。したがって、分解されたリレーショナル スキーマにより、一部の整合性制約が軽減されます。

関係は複数の関係に分解されます。分解を意味のあるものにするための最小要件は、分解後に元の情報が失われないことです。この情報には、データ自体だけでなく、関数の依存関係によって表されるデータ間の相互制約も含まれます。分解の目標は、より高いレベルの正規化を達成することですが、分解中に 2 つの問題、つまりロスレス接続と機能依存関係の維持を考慮する必要があります。機能の依存関係を完全に維持しながら、ロスレス接続を実現することは不可能な場合があります。必要に応じてトレードオフを行う必要があります。

1NF から BCNF までの 4 つのパラダイムには次の関係があります:
BCNF には 3NF が含まれます 2NF には 1NF が含まれます

概要:
目的: 正規化の目的は、構造をより合理的にし、ストレージ例外を排除し、データの冗長性を確保することです。挿入、削除、更新に便利です
原則: 概念的な単純さの「1 つのもの、1 つの場所」の原則に従います。つまり、関係パターンはエンティティまたはエンティティ間の接続を記述します。規範の本質は概念の単純化です。
方法: 関係パターンの投影を 2 つ以上の関係パターンに分解します。
要件: 分解された関係パターン セットは元の関係パターンと「同等」である必要があります。つまり、情報を失うことなく自然な接続を通じて元の関係を復元でき、属性間の合理的な接続が維持される必要があります。

注: 関係パターンの結び目を分解すると、さまざまな関係パターンのセットが生成される可能性があります。これは、分解方法が一意ではないことを意味します。最小限の冗長性の要件は、分解されたデータベースが元のデータベースのすべての情報を表現できるという前提で達成されなければなりません。その基本的な目標は、ストレージ領域を節約し、データの不整合を回避し、運用関係の効率を向上させ、同時にアプリケーション要件を満たすことです。実際、すべてのモードが BCNF に達する必要はありません。場合によっては、意図的に冗長性を保持すると、データのクエリが容易になる場合があります。これは、更新頻度が低く、クエリ頻度が非常に高いデータベース システムに特に当てはまります。

リレーショナル データベースでは、関数の依存関係に加えて、多値の依存関係や結合の依存関係の問題もあり、第 4 正規形や第 5 正規形などのより高いレベルの標準化要件が生じます。これについては後で話しましょう。

親愛なる皆さん、これを読んでどう思いますか? 実際、多くのネチズンが中途半端に僧侶になってデータベースになったことを考えると、基本的なデータベース理論に関する本はどれもこれらのことについて語っています。本を探しているので、質問がある場合は、私に尋ねずに、リレーショナル データベース理論に関する本を探して読んでください。きっと役に立つでしょう。上記は単なる基本的な理論です。データベースを設計するときに、上記のパラダイムに従うことを検討したことがありますか。上記を比較して、どのパラダイムに違反しているか考えたことはありますか?
私が見たデータベース設計では、上記のパラダイムに非常に一貫している人はほとんどいません。一般的に、誰もが最初のパラダイムを遵守できますが、2 番目と 3 番目のパラダイムを完全に遵守する人はほとんどいません。データベース設計の達人であれば、BCNF パラダイムが現れる可能性は低く、設計時に無視しても構いません。もちろん、ORACLE では、その欠点はトリガーによって解決できます。将来一緒にデザインする際には、皆さんが上記のパラダイムを遵守していただけることを願っています。