什么是规范化（或规范化）？
为什么数据库家伙继续正常化？
它是什么？ 它如何帮助？
它适用于数据库以外的任何东西吗？
规范化基本上是devise一个数据库模式，避免重复和冗余的数据。 如果某些数据片段在数据库中的几个地方被复制，则存在在一个地方而不是另一个地方更新的风险，导致数据损坏。
从正常forms到正常forms有许多归一化水平。 每一个正常的forms描述如何摆脱一些特定的问题，通常涉及冗余。
一些典型的规范化错误：
（1）在一个单元中有多个值。 例：
UserId | Car --------------------- 1 | Toyota 2 | Ford,Cadillac 这里的“汽车”栏（这是一个string）有几个值。 这冒犯了第一个正常forms，即每个单元应该只有一个值。 我们可以通过每辆车有一个单独的行来将这个问题归一化：
UserId | Car --------------------- 1 | Toyota 2 | Ford 2 | Cadillac
在一个单元格中有多个值的问题是，更新比较棘手，查询困难，而且不能应用索引，约束等等。
（2）具有冗余的非关键数据（即，在多行中不必要地重复数据）。 例：
UserId | UserName | Car ----------------------- 1 | John | Toyota 2 | Sue | Ford 2 | Sue | Cadillac
这种devise是一个问题，因为每个列都重复该名称，即使该名称总是由UserId确定。 这使得理论上可以将Sue的名称改为一行而不是另一个，这是数据损坏。 这个问题通过将表分成两部分来解决，并创build一个主键/外键关系：
UserId(FK) | Car UserId(PK) | UserName --------------------- ----------------- 1 | Toyota 1 | John 2 | Ford 2 | Sue 2 | Cadillac
现在看起来我们仍然有冗余数据，因为UserId是重复的; 但PK / FK约束确保值不能独立更新，因此完整性是安全的。
是不是重要？ 是的，这是非常重要的。 通过使数据库出现规范化错误，您可能会将无效或损坏的数据导入数据库。 由于数据“永远存在”，在首次进入数据库时很难摆脱损坏的数据。
不要害怕正常化 。 正常化水平的官方技术定义是相当钝的。 这听起来像标准化是一个复杂的math过程。 然而，规范化基本上只是常识，你会发现，如果你使用常识来devise数据库模式，它通常会被完全标准化。
关于正常化存在一些误解：
-
有些人认为规范化的数据库比较慢，反规范化提高了性能。 然而，这只在非常特殊的情况下才是真实的。 通常，规范化的数据库也是最快的。
-
有时规范化被描述为一个渐进的devise过程，你必须决定“何时停止”。 但实际上，正常化水平只是描述了不同的具体问题。 第三NF以上的正常forms解决的问题是非常罕见的问题，所以很可能你的模式已经在5NF。
它适用于数据库以外的任何东西吗？ 不直接，不。 关系数据库的规范化原则非常特殊。 但是，一般的基本主题 – 如果不同的实例可能不同步，你不应该有重复的数据 – 可以广泛应用。 这基本上是干的原则 。
规范化的规则（来源：未知）
- 关键（ 1NF ）
- 整个键（ 2NF ）
- 只有关键（ 3NF ）
…所以帮助我Codd。
最重要的是它可以消除数据库logging中的重复。 例如，如果你有一个以上的地方（表格），一个人的名字可能会出现，你可以把名字移到一个单独的表格，并在其他地方引用它。 这样，如果您稍后需要更改人员名称，则只需在一个地方更改人员名称即可。
正确的数据库devise至关重要，理论上你应该尽可能地使用它来保持你的数据的完整性。 然而，当从许多表中检索信息时，你正在失去一些性能，这就是为什么有时候你可能会看到在性能关键的应用程序中使用的非规格化数据库表（也称为展平）。
我的build议是开始良好的规范化程度，只有在真正需要的时候才会去规范化
PS也检查这篇文章： http : //en.wikipedia.org/wiki/Database_normalization阅读更多的主题和所谓的正常forms
标准化用于消除表中列之间的冗余和function依赖性的过程。
有几种正常的forms，一般用数字表示。 数字越大意味着越less的冗余和依赖性。 任何SQL表都在1NF（第一个正常forms，几乎定义）规范化意味着以可逆方式更改模式（通常是对表进行分区），给出一个function相同的模型，但冗余和依赖性较less。
数据的冗余性和依赖性是不可取的，因为在修改数据时会导致不一致。
它旨在减less数据冗余。
有关更正式的讨论，请参阅Wikipedia http://en.wikipedia.org/wiki/Database_normalization
我会举一个简单的例子。
假定一个组织的数据库通常包含家庭成员
id, name, address 214 Mr. Chris 123 Main St. 317 Mrs. Chris 123 Main St.
可以被归一化为
id name familyID 214 Mr. Chris 27 317 Mrs. Chris 27
和一张家庭桌子
ID, address 27 123 Main St.
近完全标准化（BCNF）通常不用于生产，而是一个中间步骤。 一旦将数据库放入BCNF中，下一步通常是以逻辑方式对其进行解规一化 ，以加快查询速度并降低某些常见插入的复杂度。 但是，如果没有正确的标准化，就无法做到这一点。
这个想法是冗余信息被简化为一个单一的条目。 在地址这样的地方，Chris先生把他的地址称为Unit-7 123 Main St.，Chris夫人列出了Suite 7 7 123 Main Street，这在原始表格中显示为两个不同的地址。
通常，使用的技术是查找重复的元素，并将这些字段隔离到具有唯一标识的另一个表中，并用引用新表的主键replace重复的元素。
引用CJdate：理论是可行的。
离开正常化会导致数据库中的某些exception情况。
从第一范式离开将导致访问exception，这意味着你必须分解和扫描单个值，以find你正在寻找什么。 例如，如果其中一个值是早先回答给出的string“Ford，Cadillac”，并且您正在查找“Ford”的所有发生次数，则必须打开string并查看子。 这在一定程度上破坏了将数据存储在关系数据库中的目的。
第一范式的定义自1970年以来已经改变，但这些差异现在不需要关注。 如果使用关系数据模型deviseSQL表，则表将自动处于1NF。
从第二范式及其以后的出发将导致更新exception，因为相同的事实存储在多个地方。 这些问题使得不可能存储一些事实而不存储其他可能不存在的事实，因此不得不发明。 或者当事实发生变化时，您可能需要find存储事实的所有元素，并更新所有这些地方，以免导致数据库自相矛盾。 而且，当你从数据库中删除一行时，你可能会发现如果你这样做了，你将删除唯一存储仍然需要的事实的地方。
这些是逻辑问题，而不是性能问题或空间问题。 有时你可以通过仔细的编程来解决这些更新exception。 有时（通常）通过坚持正常forms来防止问题首先是好的。
尽pipe已经说过的东西有价值，但应该指出，正常化是一种自下而上的方法，而不是自顶向下的方法。 如果您在分析数据和初始devise时遵循某些方法，则可以保证devise至less符合3NF。 在很多情况下，devise将完全正常化。
如果你真的想要应用在正常化下教授的概念，那么当你给遗留数据，遗留数据库或者由logging组成的文件之外，数据被devise为完全不了解正常forms以及离开从他们。 在这些情况下，您可能需要发现正常化的偏离，并纠正devise。
警告：正常化通常是带有宗教色彩的教导，仿佛每一次从完全正常化的背离都是一种罪恶，是对Codd的一种冒犯。 （那里的小双关语）。 不要买那个。 当你确实学习了数据库devise的时候，你不仅会知道如何遵守规则，而且知道何时可以安全地打破它们。
规范化是基本概念之一。 这意味着两件事情不会相互影响。
在数据库中特别意味着两个（或更多）表不包含相同的数据，即没有任何冗余。
在第一眼看来，这是非常好的，因为你的同步问题的机会接近于零，你总是知道你的数据在哪里，等等。但是，你的表的数量可能会增加，你将有问题跨越数据并得到一些总结的结果。
所以，最后你会完成数据库devise，这是不是纯正常化，有一些冗余（这将在一些可能的规范化水平）。
什么是规范化？
规范化是一个有步骤的forms化过程，它允许我们分解数据库表，使数据冗余和更新exception都被最小化。
标准化过程
礼貌
第一范式当且仅当每个属性的域只包含primefaces值（primefaces值是一个不能被分割的值），每个属性的值只包含来自该域的单个值（例如： – 域性别栏是：“M”，“F”）。
第一个正常forms强制执行这些标准：
- 消除单个表中的重复组。
- 为每组相关数据创build一个单独的表。
- 用主键识别每组相关数据
第二范式 = 1NF +没有部分依赖关系，即所有非关键属性完全依赖于主键。
第三范式 = 2NF +没有传递依赖关系，即所有非关键属性直接只在主关键字上完全function依赖。
Boyce-Codd正常forms （或BCNF或3.5NF）是第三种正常forms（3NF）的略微更强的版本。
注意： – 第二，第三，和博伊斯 – 科德的正常forms与function依赖有关。 例子
第四范式 = 3NF +去除多值依赖
第五范式 = 4NF +删除连接依赖关系
在直接跳到“数据库规范化及其types”主题之前，我们需要了解数据冗余，插入/更新/删除exception，部分依赖和传递函数依赖。
什么是数据冗余和更新/修改exception？
数据冗余是数据库内甚至同一个表内多个表中不必要的数据重复。 它不必要地增加了数据库的大小，导致数据不一致，从而降低了数据库的效率。
例：
在这里，学生Alex的“student_age”被不必要地重复，这自然会增加数据冗余。 当“student_age”列在将来需要改变时，则如上表所示，在学生Alex的两行上进行更新。 这种情况被称为更新exception。 如果用户只更新一行并忘记更新另一行，则会导致数据不一致。
什么是插入exception？
如果某个属性的某些值不能插入表中，而没有与该特定值相关的附加数据，则会发生插入exception。
例：
这里'student_name'和'exam_registered'被假定为复合主键（包含多个列的主键）。 主键应该始终是唯一的，不应该保存NULL值，并且必须唯一地标识表中的每一行。 现在假设高中正在尝试引入一门名为“化学”的新考试。 一开始没有学生在这门课上注册。 由于上表不接受“student_name”列中的NULL值，因此我们需要等到至less有一名学生已经注册才能进入上表中的考试化学。
什么是删除exception？
当属性*的某些重要值由于删除了其他不需要的值而丢失时，会发生删除exception。
例：
这里'student_name'和'exam_registered'被假定为复合主键（包含多个列的主键）。 主键应该始终是唯一的，不应该保存NULL值，并且必须唯一地标识表中的每一行。 现在假设名为John的学生已经取消了英语考试的注册。 由于“student_name”列不能保留NULL值，因此我们将被迫删除整个行，从而导致我们的表中名为“英语”的考试stream失。 但高中仍然提供了对学生进行英语考试的可能性。
什么是偏依赖？
当表中的非主键属性完全依赖于该表中的组合主键属性的一部分时，表被称为处于部分依赖关系。
例：
考虑一个如上所述的具有3列名为'student_name'，'student_age'和'exam_registered'的表。 这里'student_name'和'exam_registered'可以一起形成一个复合主键。 通常情况下，规范化表中的每个非主键列都应该总是依赖于整个组合主键。 这里的'student_age'只依赖于'student_name'，它和'exam_registered'没有关系，这会导致这个表部分依赖。
什么是传递函数依赖？
当表中的非主键属性更强烈地依赖于该表中的另一个非主键属性时，表被认为处于传递函数依赖关系中。
例：
在上表中，非主键属性“postal_code”和另一个非主键属性“City”之间的关系比主键属性“student_id”和非主键属性“postal_code”之间的关系强得多。 这导致上表在传递函数依赖。
随着对上述概念的深入理解，我们现在可以深入到数据库表格的规范化。
数据取决于密钥[1NF]，整个密钥[2NF]，除了密钥[3NF]
表没有正常化
下面给出一个非规范化的示例表，这将在本文的增量步骤中进行规范化。
在下面的student_id = 2的例子中，由于父母id不同，有两个条目。 在这里，我们可以假设像Parent_id = 1代表父亲，Parent_id = 3代表student_id = 2的学生的母亲。
例：
第一范式（1NF）
规则：1.属性必须只包含primefaces值2.没有两行数据必须包含重复的信息组3.每个表必须有一个主键
步骤1：
上述步骤满足规则1，但仍不符合规则2和规则3。
步骤2：下面的表格满足1NF的规则1，规则2和规则3。
第二范式（2NF）
规则：
- 表格应该满足第一范式（1NF）
- 表内不应有任何部分依赖关系
除了第一个表格外，其余所有来自1NF的表格均满足2NF。 在第一个表中，“年龄”列仅依赖于“student_id”列。 这违反了2NF的规则2。 因为所有的非键列都应该完全依赖主键列。 所以按照2NF的规格化表格在下面给出。
第三范式（3NF）
通常，关系数据库表如果满足3NF，通常被描述为“规范化”。 大多数3NF表格是免费插入，更新和删除exception。
规则：
- 表格应该满足第二范式（2NF）
- 表内不应该有任何传递函数依赖关系
除了最后一个表格外，2NF的所有其他表格都满足3NF。 这是因为列“city”更依赖于“postal_code”列而不是主键“student_id”，这使得“城市”列成为传递函数依赖于“student_id”列。 所以最终的归一化表格按照3NF给出如下。
*属性：
– 考虑一下学生的表格。 这里的student_name，age等被认为是相应列的标题的属性。
================================================== ====================== 简单的例子 – 数据库规范化
它有助于防止重复（和更糟，冲突）的数据。
虽然可能会对性能产生负面影响。
