次の列を持つテーブルがあるとします。
- person_id (主キー)
- ファーストネーム
- 苗字
- 誕生日
{first_name, last_name} の組み合わせにも一意の制約があります (同じ名前を持つ人が増えることはわかっていますが、例を単純にしたいと思います)。この表が第 3 正規形かどうかを知りたいです。
私の推論（編集前）：
- すべてのフィールドにはアトミック値のみを含めることができるため、テーブルは第 1 正規形になります。
- 候補キーは、1) person_id、2) [first_name, last_name] です。
- 非プライム属性は誕生日だけです。
- 属性誕生日は、候補キー 1 の一部に機能的に依存していません (候補キー 1 には属性が 1 つしかないため、これはとにかく不可能です)。
- 属性誕生日は、候補キー 2 の一部に機能的に依存していません
- したがって、この表は第 2 正規形です。
- 属性 birthday (is/is not) は候補キー 1 に非推移的に依存します
- 属性 birthday は、候補キー 1 に非推移的に依存しています。
質問（編集前）：
私が答えられない質問は、誕生日が非推移的に person_id に依存しているかどうかです。機能的には、この ID 番号と誕生日の間にはまったく関係がありません。
- これは、推移的な依存関係 (誕生日は [first_name, last_name] に依存し、各組み合わせ [first_name, last_name] は ID にマップされる) があり、したがって 3NF ではないことを意味しますか?
- これは、依存関係がまったくないということであり、したがって 3NF ではないということですか?
- 私は難しい言葉を誤解していますか? この表は 3NF ですか?
私の推論（編集後）：
- person_id がわかれば、彼の名、姓、誕生日がわかるので、FD には {person_id} -> {first_name}、{person_id} -> {last_name}、{person_id} -> {birthday} があります。
- 人の名前と姓がわかれば、その人の person_id と誕生日がわかるので、FD {first_name, last_name} -> {person_id} と {first_name, last_name} -> {birthday} があります。
人の誕生日を知っている場合、その人の person_id や名前については何も知らないため、誕生日から別の (セットの) 属性への FD はありません。
すべてのフィールドにはアトミック値のみを含めることができるため、テーブルは第 1 正規形になります。
- 候補キーは 1) {person_id}、2) {first_name, last_name} です。
- 非プライム属性は {birthday} だけです。
- 属性 {birthday} は、CK 1 の一部の FD ではありません (CK 1 には属性が 1 つしかないため、とにかく不可能です)。
- 属性 {birthday} は CK 2 の一部で FD ではありません
したがって、この表は第 2 正規形です。
FD {person_id} -> {birthday} があるため、属性 {birthday} は CK 1 に非推移的に依存します。
- FD {first_name, last_name} -> {birthday} があるため、属性 {birthday} は CK 2 に非推移的に依存します。
- したがって、この表は第 3 正規形です。
依存関係 {person_id} -> {first_name, last_name} -> {birthday} がありますが、直接の依存関係 {person_id} -> {birthday} もあるため、この依存関係は推移的ではありません。
質問（編集後）：
私は本の FD の事前定義されたセットを持っていないので、FD が正しいかどうかわかりません。誰かがこれを確認できますか、または正しく見えない場合は、この実際の例で FD を見つける方法を示してもらえますか?
3 番目の推論 (2 回目の編集):
FD:
- 人物の person_id しか知らない場合は、その人物の名、姓、誕生日がわかります (同じ person_id を持つ人物が複数存在することはありません)。
- FD: {person_id} -> {first_name}
- FD: {person_id} -> {last_name}
- FD: {person_id} -> {誕生日}
- {person_id} を含むスーパーセットを考慮する必要がなくなりました
- 人の名のみを知っている場合、この人の他のフィールドはわかりません (同じ名を持つ人が複数いる可能性があります)。
- FD ではない: {first_name} -> {person_id}
- FD ではない: {first_name} -> {last_name}
- FD ではない: {first_name} -> {birthday}
- 人物の last_name しか知らない場合、この人物の他のフィールドはわかりません (同じ last_name を持つ人物が複数存在する可能性があります)。
- FD ではない: {last_name} -> {person_id}
- FD ではない: {last_name} -> {first_name}
- FD ではない: {last_name} -> {birthday}
- ある人の誕生日しか知らない場合、その人の他のフィールドはわかりません (同じ誕生日の人が複数いる可能性があります)。
- FD ではない: {birthday} -> {person_id}
- FD ではない: {誕生日} -> {first_name}
- FD ではない: {誕生日} -> {姓}
- 人の姓と名がわかれば、その人物の ID と生年月日がわかります (姓名が同じ人が複数存在することはありません)。
- FD: {first_name, last_name} -> {person_id}
- FD: {名、姓} -> {誕生日}
- {first_name, last_name} を含むスーパーセットを考慮する必要がなくなりました
- 人の名前と誕生日がわかっている場合、この人の他のフィールドはわかりません (同じ名前と誕生日を持つ人が複数いる可能性があります)。
- FD ではない: {first_name, birthday} -> {person_id}
- FD ではない: {first_name, birthday} -> {last_name}
- 人物の姓と誕生日がわかっている場合、この人物の他のフィールドはわかりません (姓と誕生日が同じ人物が複数存在する可能性があります)。
- FD ではない: {last_name, birthday} -> {person_id}
- FD ではない: {last_name, birthday} -> {first_name}
通常形:
すべての属性には単一の値のみを含めることができるため、テーブルは第 1 正規形です。
FD を見ると、1) {person_id}、2) {first_name, last_name} の 2 つの候補キーがあります。
- 非プライム属性は {birthday} だけです。
- 属性 {birthday} は、CK 1 の一部の FD ではありません (CK 1 には属性が 1 つしかないため、とにかく不可能です)。
- 属性 {birthday} は、CK 2 の一部の FD ではありません (つまり、FD {first_name} -> {birthday} または FD {last_name} -> {birthday} はありません)。
したがって、この表は第 2 正規形です。
S -> X かつ X -> T かつ not(X -> S) となるような X が存在する場合、S は推移的に T を決定します。
- S = CK1 = {person_id} および T = {birthday} とします。S -> X および X -> T となる唯一の X は、X = {first_name, last_name} の場合です。ただし、X -> S も成立します。したがって、S は非推移的に T を決定します。
- S = CK2 = {first_name, last_name} および T = {birthday} とします。S -> X および X -> T となる X は、X = {person_id} の場合のみです。ただし、X -> S も成立します。したがって、S は非推移的に T を決定します。
- したがって、この表は第 3 正規形です。