第3正規形

第 3 正規形( 3NF ) は、正規化の原則を使用してデータの重複を減らし、データの異常を回避し、参照整合性を確保し、データ管理を簡素化するリレーショナル データベースのデータベース スキーマ設計アプローチです。これは、データベース管理用のリレーショナル モデルを発明した英国のコンピューター科学者、エドガー F. コッドによって 1971 年に定義されました。

データベース関係（例：データベーステーブル）は、すべての属性（例：データベース列）がキーのみに機能的に依存している場合、第3正規形の基準を満たしていると言われます。ただし、機能的依存関係の右側が主属性（あるキーに厳密に含まれる属性）である場合は除きます。コッドはこれを、主属性以外のすべての属性が候補キーのみに依存し、別のキーに推移的に依存しない第2正規形の関係として定義しました。^[1]

第 3 正規形を満たさない仮想的な例としては、医師の電話番号の列を含む患者テーブルを持つ病院データベースが挙げられます。(電話番号は患者ではなく医師に依存するため、医師テーブルに保存する方が適切です。) このような設計のマイナス面は、複数の患者がいる場合に医師の番号がデータベース内で重複し、入力エラーの可能性と、番号が変更された場合にその番号を更新するコストとリスクの両方が増加することです (医師テーブルに医師の番号を 1 回だけ保存する第 3 正規形準拠のデータ モデルと比較して)。

コッドは後に、3NF では望ましくないデータ異常がすべて排除されるわけではないことに気づき、1974 年にこれに対処するためのより強力なバージョンを開発しました。これはボイス・コッド正規形として知られています。

第3正規形（3NF）は、データベースの正規化で使用される正規形です。3NFは、1971年にE. F. Coddによって最初に定義されました。^[2]

Codd の定義によれば、次の条件が両方と も満たされる場合にのみ、テーブルは 3NF になります。

• 関係R (テーブル)は第 2 正規形(2NF)です。
• R の非主属性は主キーに推移的に依存しません。

Rの非プライム属性は、 Rのどの候補キーにも属さない属性である。 ^[3]推移的依存関係は、 X → Z（XがZを決定する）が、 X → YとY → Z （ Y → Xではない）によって間接的に決定される機能的依存関係である。^[4]

コッドの定義と同等だが表現が異なる3NFの定義は、1982年にカルロ・ザニオーロによって与えられた。この定義では、テーブルが3NFであるためには、その関数従属性X → Yのそれぞれに対して、以下の条件のうち少なくとも1つが満たされる必要があるとしている。^{[5] [6] [検証には引用が必要]}

• XにはY が含まれる（つまり、Y はXのサブセットであり、X → Yは単純な関数従属関係である）。
• Xはスーパーキーです。
• Y  \  Xのすべての要素、つまり Y と X の差集合は主属性です（つまり、Y  \  Xの各属性は何らかの候補キーに含まれています）。

Zaniolo の定義をもっと簡単に言い換えると、関係が 3NF にあるのは、すべての非自明な関数従属性 X → Y に対して、 X がスーパーキーであるか、Y  \  X が主要な属性から構成されている場合のみです。Zaniolo の定義は、3NF とより厳格なボイス・コッド正規形(BCNF)の違いを明確に示しています。BCNF は、単に 3 番目の選択肢 (「Y  \  Xのすべての要素、つまりYとXの差集合は主要な属性です。」) を排除します。

法廷で真実の証言をするという伝統的な宣誓と並行して、コッドの 3NF の定義に近い定義は、ビル・ケントによって与えられました。「[すべての] 非キー [属性] は、キー、キー全体、そしてキー以外の何ものでもない事実を提供しなければなりません」。 ^{[7]一般的なバリエーションでは、この定義に「}コッド、助けてください」という宣誓が追加されます。^[8]

「キー」の存在を要求すると、テーブルが1NFであることが保証されます。キー以外の属性が「キー全体」に依存することが要求されると、2NF であることが保証されます。さらに、キー以外の属性が「キー以外の何にも」依存しないことが要求されると、3NF であることが保証されます。このフレーズは便利な記憶法ですが、単一のキーのみに言及しているという事実は、第 2 正規形と第 3 正規形を満たすために必要な条件を定義しているが、十分ではないことを意味します。2NF と 3NF はどちらも、テーブルのすべての候補キーに等しく関係し、1 つのキーだけに関係するわけではありません。

クリス・デイトは、ケントの要約を 3NF の「直感的に魅力的な特徴付け」と呼び、少し調整すれば、わずかに強力なボイス・コッド正規形の定義として役立つ可能性があると指摘しています。「各属性は、キー、キー全体、およびキー以外の何物でもない事実を表す必要があります。」^[9] 3NF バージョンのこの定義は、デイトの BCNF バリエーションよりも弱いものです。これは、前者がキー以外の属性がキーに依存していることを保証することのみに関係しているからです。プライム属性 (キーまたはキーの一部) は、機能的にまったく依存してはなりません。プライム属性は、キー自体の一部またはすべてを提供するという意味で、キーに関する事実を表します。(このルールは、機能的に依存する属性にのみ適用されます。すべての属性に適用すると、複合候補キーが暗黙的に禁止されるためです。このようなキーの各部分が「キー全体」条項に違反するからです。)

3NF の要件を満たさないテーブルの例は次のとおりです。

テーブルの各行は、特定の年の特定のトーナメントで誰が優勝したかを示す必要があるため、複合キー{Tournament, Year} は、行を一意に識別することが保証された属性の最小セットです。つまり、{Tournament, Year} はテーブルの候補キーです。

3NF 違反は、非プライム属性 (Winner の生年月日) が非プライム属性 Winner を介して候補キー {Tournament, Year} に推移的に依存しているために発生します。Winner の生年月日が Winner に機能的に依存しているという事実により、同じ人物が異なるレコードで異なる生年月日で表示されるのを防ぐものがないため、テーブルは論理的な矛盾に対して脆弱になります。

3NF に違反せずに同じ事実を表現するには、テーブルを 2 つに分割する必要があります。

以前とは異なり、Winner は 2 番目のテーブルの候補キーになったため、各 Winner の誕生日の値は 1 つしか許可されないため、これらのテーブルでは更新異常は発生しません。

関係は常に第3正規形で分解できる。つまり、関係Rは、結合が元の関係に等しい射影R ₁ , ..., R _{nに書き換えられる。さらに、この分解では}機能的依存性は失われず、Rのすべての機能的依存性は、射影R ₁ , ..., R _nに保持される機能的依存性から導出できる。さらに、このような分解は多項式時間で計算できる。^[10]

関係を2NFから3NFに分解するには、テーブルを正規カバー関数従属性に分割し、分解内の関係のサブセットではなかった元の関係の候補キーごとに関係を作成します。^[11]

1982 年に Carlo Zaniolo によって提案され、上記で示した 3NF の定義は、次のようにして Codd の定義と同等であることが示されます。X → A を非自明なFD (つまり、X に A が含まれないもの) とし、A を非プライム属性とします。また、Y を R の候補キーとします。すると、Y → X となります。したがって、X → Y に関数従属性がある場合、X が R のスーパーキーである場合に限り、A は Y に推移的に依存しません。

ほとんどの 3NF テーブルには、更新、挿入、削除の異常はありません。実際にはめったに見られない特定の種類の 3NF テーブルは、このような異常の影響を受けます。これらのテーブルは、ボイス・コッド正規形(BCNF) を満たしていないか、BCNF を満たしていても、より高次の正規形である4NFまたは5NF を満たしていないテーブルです。

3NF は機械処理には理想的でしたが、データ モデルのセグメント化された性質は、人間のユーザーが直感的に理解するのが難しい場合があります。クエリ、レポート、ダッシュボードによる分析は、多くの場合、トレンド ライン、期間累計計算 (月累計、四半期累計、年累計)、累積計算、基本統計 (平均、標準偏差、移動平均)、前期間比較 (前年、前月、前週) などの事前計算された分析を提供する別の種類のデータ モデルによって促進されました。たとえば、次元モデリングと次元モデリングを超えるもの、Hadoopによるスターの平坦化、データ サイエンスなどです。^{[12] [13]} Hadley Wickham の「整頓されたデータ」フレームワークは 3NF であり、「統計言語で枠組みが決められた制約」を備えています。^[14]

• 属性値システム

• Litt のヒント: 正規化
• データベース正規化の基礎 (Mike Chapple 著、About.com)
• Mike Hillyer 著「データベース正規化入門」。
• Fred Coulson による最初の 3 つの正規形に関するチュートリアル
• Microsoftによるデータベース正規化の基礎の説明
• exploreDatabase による簡単な例による第 3 正規形