database - 你同意这个表在 3NF 中被归一化吗

Question

我正在检查表规范化，看看结果如何:

描述并说明将此表中显示的数据规范化为第三范式的过程表格 (3NF) :

BRANCH_NO(PK)  BRANCH_ADDRESS    TELL_NO    MANAGER_ID    MANAGER_NAME
B001           ADDRESS 1         TELL 1     S1500         TOM DANIELS
B002           ADDRESS 2         TELL 2     S0010         MARY MARTINEZ
B003           ADDRESS 3         TELL 3     S0145         ART PETERS
B004           ADDRESS 4         TELL 4     S2250         SALLY STEM 

在他们转换之后，他们最终得到了这两个他们声称都在 3NF 中的表:

BRANCH_NO(PK)  BRANCH_ADDRESS    TELL_NO    MANAGER_ID(FK)
B001           ADDRESS 1         TELL 1     S1500     
B002           ADDRESS 2         TELL 2     S0010     
B003           ADDRESS 3         TELL 3     S0145     
B004           ADDRESS 4         TELL 4     S2250

和

 MANAGER_ID(PK)    MANAGER_NAME
    S1500             TOM DANIELS
    S0010             MARY MARTINEZ
    S0145             ART PETERS
    S2250             SALLY STEM

我认为第一个表显然不是 3NF。例如。 : tell_no依赖于branch_addres，它不是主键，但是主键在功能上标识了branch_address，这与过渡函数依赖冲突。

Answer 1

规范化就是确保数据库模式准确地表示一组给定的依赖关系。如果没有为您提供开始时的依赖关系，那么这样的练习实际上归结为基于一组属性名称和几行样本数据的猜测和假设。因此，关于什么是对的什么是错的，不可能有任何明确的答案。这更多的是了解正在做出的假设以及可能产生的后果。写下您希望应用的依赖项，然后确保架构针对这些依赖项进行了规范化。

假设每个分支机构都需要有一个唯一的分支机构编号和一个唯一的地址，因此我们要强制执行这些 FD:

BRANCH_NO -> BRANCH_ADDRESS
BRANCH_ADDRESS -> BRANCH_NO
BRANCH_NO -> TEL_NO
BRANCH_NO -> MANAGER_ID -> MANAGER_NAME

假设 BRANCH_NO 和 BRANCH_ADDRESS 都将成为候选键(您需要考虑所有键，而不仅仅是一个主键)，您的双表设计就这些依赖关系而言满足 3NF。

现在假设对 BRANCH_ADDRESS 的隐含依赖性足够准确和重要，因此强制执行 BRANCH_ADDRESS 的唯一性是有意义的。这可能是也可能不是这种情况，但这就是为什么您需要在回答问题之前确定这些事情的原因。