1

3nf に関するウィキを読みました https://en.wikipedia.org/wiki/Third_normal_form

それはウィキが与える例です

Tournament Winners
Tournament              Year    Winner          Winner Date of Birth
Indiana Invitational    1998    Al Fredrickson  21 July 1975
Cleveland Open          1999    Bob Albertson   28 September 1968
Des Moines Masters      1999    Al Fredrickson  21 July 1975
Indiana Invitational    1999    Chip Masterson  14 March 1977

それは言う the non-prime attribute Winner Date of Birth is transitively dependent on the candidate key {Tournament, Year} via the non-prime attribute Winner

機能依存性はそれだと思います

for two row X1 , X2 if X1.col1 = X2.col1 and 
X1.col2 = X2.col2, then col1 -> col2

勝者の生年月日 -> 勝者 (同じ誕生日で同じ名前の人がいる可能性がありますか?) と勝者 -> 候補キー {トーナメント、年} が勝者名 Al Fredrickson の場合、それはインディアナ インビテーショナル 1998 である可能性があることを理解できません。またはデモイン マスターズ 1999)

では、どうやって結論に飛びつくのでしょうか。

4

3 に答える 3

1

非形式的に言えば、機能依存とは、左側が複数の行に存在する場合でも、左側の 1 つの値が右側に複数の値を生成できないことを意味します。1

したがって、ウィキペディアの例ではWinner -> Winner Date of Birth、同じ勝者が複数の行に存在する場合でも異なる生年月日を持つことはできないという単純な理由から、関数依存性があります (複数のトーナメントで優勝したため)。

以来...

  • {Tournament, Year} -> Winner（1つのトーナメントで複数の勝者を持つことはできないため）
  • そしてWinner -> Winner Date of Birth（上で説明したように）
  • ではない Winner -> {Tournament, Year}(1 人が複数のトーナメントで優勝できるため)

...そして、定義上、推移的な依存関係があります。

当選者の生年月日→当選者(同姓同名の方がいらっしゃるかも？)

方向転換しましたね。関数の依存関係は、単一の値から「から」ではなく、「に向かって」います。したがってWinner -> Winner Date of Birth、そうではありません Winner Date of Birth -> Winner。

ところで、このモデルには名前の異なる 2 人は存在できません。より優れた (より現実的な) モデルでは、おそらく代理キーを使用して人を識別し、重複した名前を許可します。

1「関数」という数学的概念に準拠しています。関数を何回「呼び出し」ても (つまり、fd の左側を含む行がいくつあるか)、常に同じ「結果」(fd の右側) が生成されます。複数の結果を生成できる場合、それは関数ではなく、「関係」になります。

于 2013-05-18T11:28:50.973 に答える
1

私の理解
では、{Tournament, Year} の勝者は 1 人だけです。各勝者の生年月日は 1 つだけです。Wiki は、これが脆弱性につながる可能性があると主張しています:
新しい行を入力したと仮定します: {"愚かなトーナメント", "2013", "Al Fredrickson", "21 July 2012"} - 間違った生年月日を入力しました!
別のテーブル {WinnerID, WinnerBithday} を保持すると、それを防ぐことができます。

于 2013-05-18T06:38:23.610 に答える