MYSQL中的规范化
任何人都可以帮助我知道什么是在MySQL规范化，在这种情况下，我们需要如何使用它..
提前致谢。
我尝试在这里尝试用外行的词汇来解释正常化。 首先，它适用于关系数据库（Oracle，Access，MySQL），所以它不仅适用于MySQL。
规范化是关于确保每个表具有唯一的最小字段并摆脱依赖关系。 想象一下，你有一个员工logging，每个员工属于一个部门。 如果将部门作为现场与员工的其他数据一起存储，则会出现问题 – 部门被删除后会发生什么情况？ 你必须更新所有的部门领域，并有机会出现错误。 而如果一些员工没有一个部门（新分配，也许？）。 现在会有空值。
所以简单来说，规范化就是避免让字段为空，并确保表中的所有字段只属于被描述的数据的一个域。 例如，在员工表中，这些字段可以是id，姓名，社会安全号码，但这三个字段与该部门无关。 只有员工ID才能描述员工属于哪个部门。 所以这意味着一个员工所在的部门应该在另一个表中。
这是一个简单的标准化过程。
EMPLOYEE ( < employee_id >, name, social_security, department_name) 正如所解释的，这不是正常化的。 规范化的forms可能看起来像
EMPLOYEE ( < employee_id >, name, social_security)
这里，Employee表只负责一组数据。 那么我们在哪里存储员工属于哪个部门？ 在另一张桌子
EMPLOYEE_DEPARTMENT ( < employee_id >, department_name )
这不是最佳的。 如果部门名称改变怎么办？ （这一直发生在美国政府）。 因此，最好这样做
EMPLOYEE_DEPARTMENT ( < employee_id >, department_id ) DEPARTMENT ( < department_id >, department_name )
有第一范式，第二范式和第三范式。 但是除非你正在学习数据库课程，否则我通常只是按照我能理解的最正常的forms去学习。
希望这可以帮助。
规范化不仅适用于MYSQL。 它是一个通用数据库概念。
规范化是有效地组织数据库中的数据的过程。 标准化过程有两个目标：消除冗余数据（例如，将相同的数据存储在多个表中）并确保数据依赖性是有意义的（仅将相关数据存储在表中）。 这些都是值得的目标，因为它们可以减less数据库消耗的空间，并确保数据在逻辑上存储。
SQL中的正常forms如下所示。
第一范式（1NF）：如果一个关系只有单值属性，那么它就是在1NF中，不允许重复也不允许数组。
第二范式（2NF）：如果一个关系处于1NF中，并且每个非关键属性完全依赖于主关键字，则称该关系在2NF中。
第三范式（3NF）：如果它处于2NF并且没有传递依赖关系，我们就说关系在3NF。
Boyce-Codd范式（BCNF）：当且仅当关系中的每个行列式都是候选关键字时，关系才被认为是在BCNF中。
第四范式（4NF）：如果在BCNF中并且不包含多值依赖关系，则称该关系在4NF中。
第五范式（5NF）：当且仅当关系的候选关键字隐含关系中的每个关联依赖关系时，关系被认为是在5NF中。
领域关键范式（DKNF）：如果没有任何修改exception，我们就说关系在DKNF中。 插入，删除和更新exception处于修改exception
Seel也是
数据库规范化基础
这是一种通过消除重复来确保数据保持一致的技术。 因此，一个数据库中，相同的信息存储在多个表中没有规范化 。
请参阅维基百科关于数据库规范化的文章。
（这是关系数据库的通用技术，不是MySQL特有的。）
为应用程序创build数据库模式时，需要确保避免将任何信息存储在不同表中的多个列中。
由于数据库中的每个表都标识了应用程序中的重要实体，因此唯一的标识符是它们必备的列。
现在，在决定存储模式的同时，在这些实体（表）之间正在识别各种关系，即一对一，一对多，多对多。
- 对于一对一的关系（例如，学生在课堂上有独特的排名），可以使用同一个表来存储列（来自两个表）。
- 对于一对多的关系（例如一个学期可以有多个课程），在父表中创build一个外键。
- 对于多对多的关系（例如教授参加许多学生，反之亦然），需要创build第三个表（将两个表中的主键作为组合键）以及两者的相关数据表将被存储。
一旦你参加所有这些场景，你的数据库模式将被规范化为4NF。
检查这个post有帮助的build议
巴里关于理解数据库模式的教程
http://www.youtube.com/watch?v=KqvIGYjcLQ4
在关系数据库devise领域，规范化是确保数据库结构适合于通用查询并且没有某些不良特性（插入，更新和删除exception）的系统方式，这可能导致数据完整性的丢失[1]。 EF Codd（关系模型的发明者）介绍了标准化的概念，以及我们现在知道的1970年的第一个标准forms。[2] 科德在1971年继续定义了第二和第三个正常forms[3]，Codd和Raymond F.Boyce在1974年定义了Boyce-Codd正态forms[4]。 其他理论家在随后的几年中定义了更高的正常forms，最近的一次是Chris Date，Hugh Darwen和Nikos Lorentzos在2002年提出的第六种正常forms[5]。
非正式地，关系数据库表格（关系的计算机化表示）如果处于第三范式（3NF），通常被描述为“标准化”[6]。 大多数3NF表格没有插入，更新和删除exception，即在大多数情况下，3NF表格遵循BCNF，4NF和5NF（但通常不是6NF）。
一个标准的数据库devise指导是devise师应该创build一个完全标准化的devise; 随后可以出于性能原因select性去规范化。[7] 然而，一些build模学科，如数据仓库devise的维度build模方法，明确推荐非规范化devise，即大部分不遵守3NF的devise[8]。
编辑：来源： http ： //en.wikipedia.org/wiki/Database_normalization
规范化是从表中删除冗余数据以提高存储效率，数据完整性和可伸缩性的过程。 规范化通常涉及将现有表分成多个表，每次发出查询时必须重新连接或链接。
标准化的步骤
- 第一范式（1NF）
- 第二范式（2NF）
- 第三范式（3NF）
- 博伊斯 – 科德范式（BCNF）
- 第四范式（4NF）
- 第五范式（5NF）在实践中，1NF，2NF和3NF对于数据库是足够的。
1NF所需的规则是：1.每个属性名称必须是唯一的。 2.每个属性值必须是单一的。 3.每行必须是唯一的。 4.没有重复的组。 其他：select一个主键。提醒：主键是唯一的，不为空，不变。 主键可以是属性或组合属性。
第二范式（2NF）2NF所需的规则是：1.表格已经在1NF中。 2.所有非键属性完全依赖于主键。 所有的部分依赖关系被删除放置在另一个表中
Boyce Codd Normal Form（BCNF）3.5NF BCNF所需的规则是：1.表格已经在3NF.2。所有的决定因素都必须是超级的。 所有不是超级键的决定因素都被移除到另一个表中
第四范式（4NF）4NF所需的规则是：1.表格已经在BCNF.2中。 一个表不包含多值依赖关系。多值依赖关系：当同一个表中有两个或多个关于同一属性的独立多值事实发生时，MVD就会出现。
