你同意这张表在 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

您的双表设计在这些依赖方面满足 3NF，假设 BRANCH_NO 和 BRANCH_ADDRESS 都将是候选键（您需要考虑所有键而不仅仅是一个主键）。

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