您是否同意此表在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的唯一性。这可能是也可能不是，但这就是为什么你需要在回答问题之前确定这些事情的原因。