9

データベースに T 10と T 11という 2 つのテーブルがあり、それぞれ 10 列と 11 列があり、そのうちの 10 列は両方でまったく同じであるとします。

違反している正規化ルール (ある場合) は?

4

8 に答える 8

9

編集:理論上、ここでは正規形に違反していないとの通知を受けました。これは受け入れられた答えだったので、参考のためにここに残しておきます。3NFについて考えることは、実際には、質問でそのような状況を回避するのに役立つ可能性があるためです。

両方のテーブルにほぼ同じデータが保持されている場合、各テーブルのすべての属性がそれぞれのテーブルのキーに直接依存していないため、第3正規形(3NF)に違反しています。

于 2010-03-04T18:39:54.890 に答える
6

信じられないかもしれませんが、テーブル間で列を複製すること自体は、理論上の正規形に違反していません。ドメイン/キー正規形 (DKNF) を除いて、正規形は、複数のテーブルではなく、個々のテーブルに関して定義されます。DKNF は制約の観点から定義されますが、一般的なケースでは制約はありません。したがって、正規形の違反がある場合:

  • いずれかのテーブルに固有であり、両方のテーブルを持つこととは関係なく存在する必要があります (つまり、他のテーブルを削除しても、テーブルは通常の形式に違反します)、または
  • 関係にはDKNFに違反する制約があります。つまり、質問で概説されている一般的なケースの例ではなく、より具体的なケースです。違反を作成するのは重複列ではなく、余分な列に対する追加の制約です。

ウィキペディアの記事の簡単な定義を使用して、正規形を考えてみましょう。

1NF
テーブルは関係を忠実に表し、グループの繰り返しはありません。

これはかなり簡単です。「繰り返しグループ」という用語には理論上複数の意味がありますが、いずれも重複する列やデータとは何の関係もありません。

2NF
テーブル内の非プライム属性は、候補キーの適切なサブセットに機能的に依存していません。

ここで、検討すべき重要な用語は「機能依存性」です。基本的に、機能依存とは、X と Y の 2 つの列への関係を射影し、関数 X → Y で終了する場所です。2 つ (またはそれ以上) のテーブル間で機能依存を持つことはできません*。さらに、候補キーは複数のテーブルにまたがることはできません。

3NF
すべての非プライム属性は、テーブル内のすべての候補キーに非推移的に依存しています。

推移的な依存関係は、関数の依存関係の観点から定義されます。推移的な依存関係は、X → Y および Y → Z という理由だけで X → Z の依存関係です。これらは関数の依存関係であるため、X、Y、および Z は同じテーブルにある必要があります。

4NF
テーブル内の重要な多値依存関係はすべて、スーパーキーへの依存関係です。

多値の依存関係は少しトリッキーですが、次の例で説明できます。 a、d、c) も r" ("r" はテーブル) に存在する必要があります。当面の問題で最も重要なことは、多値の依存関係は単一のテーブルにのみ適用されることです。

5NF
テーブル内のすべての重要な結合依存関係は、テーブルのスーパーキーによって暗示されます。

テーブルが他のテーブルの自然な結合として表現できる場合、そのテーブルには結合依存関係があります。ただし、これらの他のテーブルはデータベースに存在する必要はありません。この例のテーブル T 11に結合依存関係がある場合、テーブル T 10を削除しても結合依存関係は残ります。

6NF (C.伊達)
テーブルには、重要な結合依存関係がまったくありません (一般化された結合演算子を参照)。

5NFについても同じ理由です。

基本キーの正規形(EKNF)
表内の重要な機能依存関係はすべて、基本キー属性の依存関係またはスーパーキーへの依存関係のいずれかです。

2NF についても同じ理由です。

ボイス・コッド正規形(BCNF)
表内の重要な機能依存関係はすべて、スーパーキーへの依存関係です。

2NF についても同じ理由です。

ドメイン/キー正規形(DKNF)
テーブルのすべての制約は、テーブルのドメイン制約とキー制約の論理的な結果です。

T 11に T 10に依存する制約がある場合、それは重要な制約か、T 10を引き続き参照するより複雑な制約のいずれかです。後者のケースは、質問で言及されている一般的なケースではありません。つまり、DKNF に違反する列が重複している特定のスキーマが存在する可能性がありますが、一般的にはそうではありません。さらに、DKNF 違反を引き起こすのは、複数のテーブルに関して定義された制約 (通常の形式ではない) と、制約 (列の重複ではない) です。


正規化の目的には、異常の防止が含まれます。ただし、リレーショナル データベースに異常がまったくないことを保証するものではないという点で、正規化は完全ではありません。これは、実践が理論から逸脱している 1 つの例です。

それでも納得できない場合は、スキーマ KM. のコメントが示唆するものを検討してください。ここで、 T 11は T 10の履歴 (またはバージョン管理された) バージョンを表します。T 11の主キーは、T 10と共通の主キー列と追加の列 (日付/バージョン列) で構成されます。T 11に異なる候補キーがあるということは、異常が発生しやすい設計と異常のない正規化された設計との間のすべての違いになります。

*結合を使用して 2 つのテーブル間の依存関係を作成できると考える人もいるかもしれません。結合によって依存関係を持つテーブルが作成される場合がありますが、依存関係は結合の構成要素間ではなく、このテーブルに存在します。この場合も、テーブルの 1 つが結合されたテーブルになり、データベース内の他のテーブルに関係なく、依存関係自体の影響を受けることを意味します。

于 2012-01-25T05:59:40.277 に答える
4

テーブルの内容によって異なります。

相互に関連するレコードがない場合(たとえば、1つのテーブルが、最初のテーブルで作成されたが最初のテーブルから削除されたレコードをアーカイブしただけの場合)、ルールに違反していません。

ただし、これらが各テーブルの同じレコードである場合は、依存関係の問題があります。つまり、11番目の列はレコードのキー値のみに依存し、追加の列には依存しません。10列すべてが主キーに含まれていないと仮定すると、3番目のNFに違反しています。

于 2010-03-04T18:41:42.627 に答える
4

おそらく、冗長データを避けるためのルールでしょうか? (つまり、2 つのテーブルの同じデータ)

于 2010-03-04T18:37:56.370 に答える
4

11 列のうち 10 列が同じである場合、11 番目の列が空白のままになっている 1 つのテーブルにならないのはなぜですか (12 番目の列は、データのタイプ、つまり、どのテーブルであったかを示す可能性があります)もともと)?

于 2010-03-04T18:38:34.613 に答える
3

2 つの同一またはほぼ同一の関係を持つこと自体は、通常の正規形のいずれにも違反しません。Outis はその理由を非常に包括的に説明しています。ただし、これはリレーショナル データベース設計理論のもう 1 つの側面である直交設計の原則に違反している可能性があります。

于 2012-01-25T06:32:41.547 に答える
0

10列すべてがキーの一部である場合、第2正規形:冗長データの削除。具体的には、これは「非代理主キーと代理主キー」のジレンマに該当します。正直なところ、これら2つの選択肢のどちらも2NFに「違反」していることは思い出せませんが、代理キーは間違いなく2NFの精神に近いものです。

于 2010-03-04T18:44:08.340 に答える
0

テーブル間で冗長にできるのは主キーだけです。複数のテーブルに非主キー列がいくらでもあると、第 3 正規形に違反します。

于 2010-03-04T18:45:47.043 に答える