究竟什么是2NF和3NF?

时间:2018-03-03 01:10:25

标签: database database-design database-normalization

标准化的要点是什么?

我的意思是如果普通形式不在2NF中,则是因为部分依赖性,即非关键属性取决于候选键的一部分。 所以,让我们说,关于R(A,B,C)与FD的关系:

AB->C, B->C

显然,AB是候选键,B->C是部分依赖。

解决方案:分解关系,使(B,C)与B形成新的关系作为关键。

现在,如果3NF中的关系,那是因为非关键属性依赖于另一个非关键属性,即说 如果关系R(A,B,C)的FD是:

A->B,B->C

显然,A是键,B-> C表示传递依赖,因此不是3NF。

解决方案:分解关系,使(B,C)与B形成新的关系作为关键。

那么,确切的区别是什么? 我的意思是,为什么这么明显的区别?基本上在两种情况下,动作都是相同的。 使用依赖关系来分解关系,其中行列式(此处为B)是键的PART或不是。 为什么有单独的术语,如部分依赖传递依赖? 为什么不看,如果存在依赖,其中非素数属性由不是候选键的东西确定(无论它是部分键还是其他非素数属性)

为什么我们不能实现这样的方法:

  • 1 NF - 拥有原子形式的所有元素
  • X NF - 如果有的话 形式non_key -> non_prime_attribute(s)的依赖关系, 分解与具有此关系的新关系之一的关系 特别是" non_key"作为那些non_prime_attributes的关键。
  • BCNF :对于X-> Y形式的所有依赖关系,X是超级密钥?

我们可以有这样的NF条件格式吗?它是否结合了所有条件?

4 个答案:

答案 0 :(得分:3)

  

那么,确切的区别是什么?

<2> 2NF不是3NF&amp; 2NF的定义不是3NF的定义。没有任何特定的语义或句法结构相似性会留下某种“差异”,而不是2NF关系可能具有违反3NF关系所没有的3NF的问题FD(功能依赖)。你可以找到所有地方的定义。你几乎可以在这里正确地给他们。但NF(正常形式)是一个条件,而不是一个过程。你是什​​么意思“行动是一样的”?在3NF中意味着处于2NF,因此自然分解为3NF也会产生2NF。但是存在2NF但不是3NF的关系,并且可能存在与2NF的关系的分解,这些关系没有达到3NF。这些分解将涉及删除所有问题的部分FD,这些部分FD不会导致所有问题传递性FD的移除。

(因为3NF总是可以实现的,并且与2NF相比没有其他缺点,2NF甚至没有用。它只是首先发现的不如3NF强的条件。)

(3NF经常用2NF定义加上CK上没有非素数属性的传递依赖性,但实际上没有这样的FD意味着CK上没有非素数属性的部分FD,因此2NF,所以第一个条件是多余的。)

  

为什么不看,如果存在依赖,其中非主要属性由不是候选键的东西确定

为什么这种情况会有所帮助?这并不仅仅是为了摆脱2NF&amp;的FD问题。 3NF - 这就是投入3NF的原因。

摆脱非平凡不是由超级钥匙决定的FD恰好给了BCNF。它意味着2NF&amp; 3NF。但它与两者都不同。 BCNF关系不表现出基于FD的更新异常。它总是可以实现的。然而,3NF在“保留FD”时总是可以实现,而BCNF则不是。有些情况下,为了使原始中的FD在视图/查询中强制执行,通过对其组件的约束来提供它,我们需要EQD(等式依赖性)约束。这表示两个列集具有相同的子行值集,这比FD强制执行更昂贵。要么你有BCNF&amp; EQD&amp;更新异常更少或您有3NF / EKNF&amp; FD&amp;某些更新异常。

真正重要的NF是5NF,这意味着BCNF,没有更新异常&amp;与其他好处。 (出于性能原因,我们可能会决定进行非规范化。)

PS对给定NF的归一化不一定涉及降低NF的归一化。

答案 1 :(得分:2)

听起来好像你想知道为什么他们用不同的名字称这两个普通形式,而不是只发明一个涵盖两种情况的形式。如果情况并非如此,请忽略此答案。

部分答案是表格未同时发现。部分答案是1NF引起2NF的问题与引起3NF的2NF问题不同,即使它们都表现出有害的冗余。

可能会让你更满意的是BCNF。 BCNF实际上是在4NF之后发现的,所以该名称已经在使用中。但BCNF必须放在3NF和4NF之间,因为它比3NF更具限制性,但比4NF限制性更小。所以它被发现“不按顺序”,可以这么说。

在BCNF中,每个(非平凡的)行列式都是候选键。这似乎是你在寻找的东西。我猜想任何在1NF中并且每个行列式都是候选键的关系都可以显示为2NF和3NF。但证据超出了我的范围。

答案 2 :(得分:1)

<2> 2NF和3NF本质上是历史概念,您的问题是合理的。没有理由将它们应用于实际数据库设计中,因为目前存在更好的工具。

在教学方面,提及2NF和3NF可能有一些理由。这样做可以让学生探索所涉及的概念(正如你所做的那样),同时也教他们一点关于设计理论的起源和基本原理。在学校的数学课上,我被教授了长期分工并区别于第一原则。没有人在实践中使用这些技术,它们只是教具。

答案 3 :(得分:0)

在检查2NF之前,关系应该是1NF。简单来说,2NF只有完全依赖,没有关系的部分依赖。完全依赖意味着如果x给出y,那么通过删除x中的任何元素,则y没有任何关系。如果通过删除x,你与y有关系则那么它就是部分依赖。对于3NF,我们必须检查2NF,在3NF中我们不应该有任何传递关系,如果x给出z,那么就没有关系,比如x给出y,y给出z。

2NF的解决方案为部分依赖创建表,并在新关系中添加外键,这是上一个关系的主键。

3NF的解决方案为x给出y和y给出z的关系。为关系添加键。