|
|
1
163
规范化基本上是设计一个数据库模式,以避免重复和冗余的数据。如果某个数据在数据库中的多个位置被复制,则存在在一个位置而不是另一个位置进行更新的风险,从而导致数据损坏。 从1开始有许多规范化级别。正常形态到5。正常形式。每一个正常形式描述了如何摆脱一些特定的问题,通常与冗余有关。 一些典型的规范化错误: (1)一个单元格中有多个值。例子:
这里的“car”列(字符串)有几个值。这违反了第一种正常形式,即每个单元格应该只有一个值。我们可以通过为每辆车单独设置一行来规范化这个问题:
在一个单元格中有多个值的问题是更新比较困难,查询比较困难,不能应用索引、约束等。 (2)具有冗余的非关键数据(即数据在几行中不必要地重复)。例子:
这种设计是一个问题,因为名称是每列重复的,即使名称总是由用户ID决定的。这使得理论上有可能在一行中更改sue的名称,而不是在另一行中更改sue的名称,这就是数据损坏。通过将表拆分为两部分,并创建主键/外键关系来解决此问题:
现在看起来我们仍然有多余的数据,因为用户ID是重复的;但是pk/fk约束确保了值不能独立更新,所以完整性是安全的。 重要吗? 是的,它是 非常 重要的。通过使数据库具有规范化错误,您就有可能将无效或损坏的数据放入数据库中。由于数据“永远存在”,当它第一次进入数据库时,很难清除损坏的数据。 不要害怕正常化 . 标准化级别的官方技术定义相当模糊。这使得它听起来像是一个复杂的数学过程。然而,规范化基本上只是常识,您会发现,如果使用常识设计数据库模式,它通常会完全规范化。 围绕规范化有许多误解:
它是否适用于数据库之外的任何内容? 不是直接的,不是。规范化的原则对于关系数据库是非常具体的。然而,一般的底层主题——如果不同的实例不同步,就不应该有重复的数据——可以广泛应用。这基本上是 DRY principle . |
|
2
44
|
|
|
3
19
最重要的是,它可以从数据库记录中删除重复数据。 例如,如果有多个位置(表)可以显示一个人的姓名,那么可以将该姓名移动到单独的表中,并在其他位置引用它。这样,如果您以后需要更改人名,则只需在一个位置进行更改。 它对于正确的数据库设计至关重要,理论上,您应该尽可能多地使用它来保持数据的完整性。然而,当从许多表中检索信息时,您会失去一些性能,这就是为什么有时您会看到在性能关键型应用程序中使用的非规范化数据库表(也称为扁平数据库表)的原因。 我的建议是从很好的正常化程度开始,只有在真正需要的时候才进行非正常化。 P.S.还请检查本文: http://en.wikipedia.org/wiki/Database_normalization 阅读更多关于这个主题和所谓的 正规形式 |
|
|
4
7
规范化:用于消除表中各列之间的冗余和功能依赖性的过程。 有几种正常形式,通常用数字表示。更高的数字意味着更少的冗余和依赖性。任何SQL表都是1nf(第一个正常形式,定义上几乎是这样)规范化意味着以可逆的方式更改模式(通常对表进行分区),从而提供一个功能相同的模型,除了冗余和依赖性更少之外。 数据的冗余和依赖性是不可取的,因为在修改数据时,它会导致不一致。 |
|
|
5
5
它旨在减少数据冗余。 有关更正式的讨论,请参阅维基百科 http://en.wikipedia.org/wiki/Database_normalization 我举个简单的例子。 假设组织的数据库通常包含家庭成员
可以规范化为
还有一张家庭餐桌
近完全归一化(BCNF)通常不用于生产,而是一个中间步骤。一旦将数据库放入bcnf,下一步通常是 去正规化 它以一种合乎逻辑的方式加速查询,并降低某些常见插入的复杂性。但是,如果不首先对其进行适当的规范化,就不能很好地完成这一任务。 其思想是将冗余信息简化为一个条目。这在地址等领域尤其有用,克里斯先生将其地址作为Unit-7123 Main St.提交,克里斯夫人将Suite-7123 Main Street列为两个不同的地址,显示在原始表格中。 通常,使用的技术是查找重复的元素,并将这些字段隔离到具有唯一ID的另一个表中,并用引用新表的主键替换重复的元素。 |
|
|
6
3
引用CJ日期:理论是可行的。 偏离规范化将导致数据库中出现某些异常。 偏离第一个正常形式将导致访问异常,这意味着您必须分解和扫描单个值,以便找到您要查找的内容。例如,如果其中一个值是字符串“ford,cadillac”,正如前面的响应所给出的那样,并且您正在查找“ford”的所有事件,则必须断开该字符串并查看子字符串。这在某种程度上破坏了将数据存储在关系数据库中的目的。 自1970年以来,第一种正常形式的定义已经改变了,但是这些差异暂时不需要你关心。如果使用关系数据模型设计SQL表,则表将自动位于1nf中。 由于同一事实存储在多个位置,偏离第二种正常形式或更高形式将导致更新异常。这些问题使得不存储可能不存在的其他事实就无法存储某些事实,因此必须发明这些事实。或者,当事实发生变化时,您可能需要找到存储事实的所有plce,并更新所有这些位置,以免最终得到一个自相矛盾的数据库。而且,当您从数据库中删除一行时,您可能会发现,如果您这样做了,那么您将删除存储仍然需要的事实的唯一位置。 这些是逻辑问题,而不是性能问题或空间问题。有时,通过仔细编程,您可以绕过这些更新异常。有时(通常)最好首先坚持正常的形式来防止问题的发生。 尽管已经说过了一些价值,但应该提到的是,规范化是一种自下而上的方法,而不是自上而下的方法。如果在数据分析和初始设计中遵循某些方法,则可以确保设计至少符合3nf。在许多情况下,设计将完全规范化。 您可能真正想要应用规范化下教给您的概念的地方是,当您得到遗留数据、遗留数据库或由记录组成的文件时,数据的设计完全忽略了正常形式以及偏离它们的后果。在这些情况下,您可能需要发现偏离标准化的地方,并纠正设计。 警告:标准化通常是用宗教色彩来教导的,好像每一次偏离标准化的行为都是一种罪恶,一种对CODD的冒犯。(小双关语)。别买那个。当你真的,真的学习数据库设计时,你不仅知道如何遵循规则,而且知道何时可以安全地打破规则。 |
|
|
7
2
规范化是基本概念之一。这意味着两件事不会相互影响。 在数据库中,这意味着两个(或更多)表不包含相同的数据,即没有任何冗余。 乍一看,这真的很好,因为您有机会使某些同步问题接近于零,您总是知道您的数据在哪里,等等。但是,很可能,您的表数量会增加,您将有问题交叉数据,并获得一些汇总结果。 因此,在最后,您将完成不完全规范化的数据库设计,以及一些冗余(它将处于一些可能的规范化级别)。 |
|
8
1
规范化是一个步骤式的正式过程,它允许我们以这样一种方式分解数据库表,即 数据冗余 和 update anomalies 被最小化。
标准化过程
第一范式 如果且仅当每个属性的域仅包含原子值(原子值是不能分割的值),并且每个属性的值仅包含该域中的单个值(例如:gender列的域为:“m”、“f”)。. 第一个正常形式强制执行这些标准:
第二范式 =1nf+无部分依赖性,即所有非键属性都完全依赖于主键。 第三范式 =2nf+没有可传递的依赖项,即所有非键属性都是完全功能依赖的,只直接依赖于主键。 Boyce_ (或bcnf或3.5nf)是第三正常形式(3nf)的稍强版本。 注:第二、第三和Boyce_“Codd范式与功能依赖有关。 Examples 第四范式 =3nf+删除多值依赖项 第五范式 =4nf+删除连接依赖项 |
|
|
9
-10
它有助于防止重复(更糟的是,冲突)数据。 但会对性能产生负面影响。 |
|
|
developer · 带外键的SQL表设计 1 年前 |
|
|
relatively_random · 确保两个表之间一致的共同参考 1 年前 |
|
|
b126 · 在两种不同的Oracle模式上执行相同查询的速度差异很大 2 年前 |
|
|
robertspierre · 在多对多关系中自动删除未引用的行 2 年前 |
|
|
Michael Samuel · MYSQL在以下情况下自动创建索引 8 年前 |