MySQL中的规范化是什么？在什么情况下以及如何使用它？
qltillow1#
我试图在这里用外行的术语解释规范化。首先，它适用于关系数据库（Oracle、Access、MySQL），所以它不仅仅适用于MySQL。规范化是为了确保每个表只有最少的字段，并摆脱依赖关系。假设您有一个雇员记录，每个雇员都属于一个部门。如果您将部门与雇员的其他数据沿着存储为字段，则会出现问题-如果删除部门会发生什么？您必须更新所有部门字段，并且有可能出错。如果一些雇员没有部门（可能是新分配的部门？），现在将有空值。因此，简而言之，规范化就是避免字段为空，并确保表中的所有字段只属于所描述的数据的一个域。例如，在employee表中，字段可以是id、name、socialsecuritynumber、但这三个字段与部门无关。只有雇员ID描述雇员属于哪个部门。因此这意味着员工所在的部门应该在另一个表中。下面是一个简单的标准化过程。
EMPLOYEE ( < employee_id >, name, social_security, department_name)
正如前面所解释的，它没有被规范化。
EMPLOYEE ( < employee_id >, name, social_security)
在这里，Employee表只负责一组数据，那么我们将雇员所属的部门存储在哪里呢？存储在另一个表中
EMPLOYEE_DEPARTMENT ( < employee_id >, department_name )
这不是最佳的。如果部门名称改变了怎么办？（美国政府经常发生这种情况）。因此最好这样做
EMPLOYEE_DEPARTMENT ( < employee_id >, department_id ) DEPARTMENT ( < department_id >, department_name )
有第一范式，第二范式和第三范式。但是除非你在学习DB课程，否则我通常只选择我能理解的最规范化的形式。
brc7rcf02#
规范化不仅仅适用于MySQL，它是一个通用的数据库概念。规范化是在数据库中有效组织数据的过程。规范化过程有两个目标：消除冗余数据（例如，将相同的数据存储在多个表中）并确保数据相关性有意义（仅将相关数据存储在一个表中）。这两个目标都是有价值的，因为它们减少了数据库占用的空间量，并确保数据以逻辑方式存储。SQL中的范式如下所示。第一范式（1 NF）：如果一个关系只有单值属性，则称之为1 NF关系，既不允许重复，也不允许数组。第二范式（2NF）：如果一个关系是在1 NF中，并且每个非键属性都是依赖于主键的完全函数，则称它是在2NF中。第三范式（3 NF）：我们说一个关系在3 NF中，如果它在2NF中并且没有传递依赖。博伊斯-科德范式（BCNF）：当且仅当关系中的每个行列式都是候选键时，才称关系在BCNF中。第四范式（4 NF）：如果一个关系在BCNF中并且不包含多值依赖，则称其在4 NF中。第五范式（5 NF）：一个关系称为5 NF当且仅当关系中的每个连接依赖都由关系的候选键隐含。域密钥范式（DKNF）：我们说一个关系是DKNF的，如果它没有任何修改异常。插入、删除和更新异常属于修改异常塞尔还Database Normalization Basics
brtdzjyr3#
这是一种通过消除重复来确保数据保持一致的技术，因此，如果一个数据库中的相同信息存储在多个表中，那么这个数据库就不是“规范化”的。参见维基百科上关于Database normalization的文章。(It是关系数据库的通用技术，而不是MySQL特有的。）
8wigbo564#
在为应用程序创建数据库架构时，需要确保避免将任何信息存储在不同表的多个列中。由于DB中的每个表都标识应用程序中的一个重要实体，因此唯一标识符是它们必须拥有的列。现在，在决定存储模式时，要识别这些实体（表）之间的各种关系，即一对一、一对多、多对多。1.对于一对一关系（例如，学生在班级中具有唯一排名），可以使用同一个表来存储列（来自两个表）。1.对于一对多关系（例如，一个学期可以有多门课程），在父表中创建一个外键。1.对于多对多关系（例如，一个教授要照顾多个学生，反之亦然），需要创建第三个表（将两个表中的主键作为复合键），并存储两个表的相关数据。在处理完所有这些场景之后，您的db-schema将被规范化为4 NF。
jmo0nnb35#
在关系数据库设计领域，规范化是一种系统化的方法，用于确保数据库结构适合于通用查询，并且没有某些不希望的特性（插入、更新和删除异常），这些特性可能会导致数据完整性的损失。[1] E.F. Codd，关系模型的发明者，在1970年引入了规范化的概念和我们现在所知道的第一范式。[2] Codd在1971年定义了第二和第三范式，Codd和Raymond F.博伊斯在1974年定义了Boyce-Codd范式。[4]更高的范式在随后的几年中被其他理论家定义，最近的是由Chris Date，Hugh Darwen和Nikos Lorentzos在2002年引入的第六范式。非正式地，一个关系数据库表（关系的计算机化表示）如果是第三范式（3 NF），通常被描述为“规范化”。[6]大多数3 NF表没有插入、更新和删除异常，即在大多数情况下3 NF表遵循BCNF、4 NF和5 NF（但通常不是6 NF）。数据库设计指南的一个标准部分是设计人员应该创建完全规范化的设计;由于性能原因，可以随后执行选择性的反规格化。[7]然而，一些建模规则，如数据仓库设计的维度建模方法，明确推荐非规格化设计，即在很大程度上不遵守3 NF的设计。
**编辑：**来源：http://en.wikipedia.org/wiki/Database_normalization
5条答案
按热度按时间qltillow1#
我试图在这里用外行的术语解释规范化。首先，它适用于关系数据库（Oracle、Access、MySQL），所以它不仅仅适用于MySQL。
规范化是为了确保每个表只有最少的字段，并摆脱依赖关系。假设您有一个雇员记录，每个雇员都属于一个部门。如果您将部门与雇员的其他数据沿着存储为字段，则会出现问题-如果删除部门会发生什么？您必须更新所有部门字段，并且有可能出错。如果一些雇员没有部门（可能是新分配的部门？），现在将有空值。
因此，简而言之，规范化就是避免字段为空，并确保表中的所有字段只属于所描述的数据的一个域。例如，在employee表中，字段可以是id、name、socialsecuritynumber、但这三个字段与部门无关。只有雇员ID描述雇员属于哪个部门。因此这意味着员工所在的部门应该在另一个表中。
下面是一个简单的标准化过程。
正如前面所解释的，它没有被规范化。
在这里，Employee表只负责一组数据，那么我们将雇员所属的部门存储在哪里呢？存储在另一个表中
这不是最佳的。如果部门名称改变了怎么办？（美国政府经常发生这种情况）。因此最好这样做
有第一范式，第二范式和第三范式。但是除非你在学习DB课程，否则我通常只选择我能理解的最规范化的形式。
brc7rcf02#
规范化不仅仅适用于MySQL，它是一个通用的数据库概念。
规范化是在数据库中有效组织数据的过程。规范化过程有两个目标：消除冗余数据（例如，将相同的数据存储在多个表中）并确保数据相关性有意义（仅将相关数据存储在一个表中）。这两个目标都是有价值的，因为它们减少了数据库占用的空间量，并确保数据以逻辑方式存储。
SQL中的范式如下所示。
第一范式（1 NF）：如果一个关系只有单值属性，则称之为1 NF关系，既不允许重复，也不允许数组。
第二范式（2NF）：如果一个关系是在1 NF中，并且每个非键属性都是依赖于主键的完全函数，则称它是在2NF中。
第三范式（3 NF）：我们说一个关系在3 NF中，如果它在2NF中并且没有传递依赖。
博伊斯-科德范式（BCNF）：当且仅当关系中的每个行列式都是候选键时，才称关系在BCNF中。
第四范式（4 NF）：如果一个关系在BCNF中并且不包含多值依赖，则称其在4 NF中。
第五范式（5 NF）：一个关系称为5 NF当且仅当关系中的每个连接依赖都由关系的候选键隐含。
域密钥范式（DKNF）：我们说一个关系是DKNF的，如果它没有任何修改异常。插入、删除和更新异常属于修改异常
塞尔还
Database Normalization Basics
brtdzjyr3#
这是一种通过消除重复来确保数据保持一致的技术，因此，如果一个数据库中的相同信息存储在多个表中，那么这个数据库就不是“规范化”的。
参见维基百科上关于Database normalization的文章。
(It是关系数据库的通用技术，而不是MySQL特有的。）
8wigbo564#
在为应用程序创建数据库架构时，需要确保避免将任何信息存储在不同表的多个列中。
由于DB中的每个表都标识应用程序中的一个重要实体，因此唯一标识符是它们必须拥有的列。
现在，在决定存储模式时，要识别这些实体（表）之间的各种关系，即一对一、一对多、多对多。
1.对于一对一关系（例如，学生在班级中具有唯一排名），可以使用同一个表来存储列（来自两个表）。
1.对于一对多关系（例如，一个学期可以有多门课程），在父表中创建一个外键。
1.对于多对多关系（例如，一个教授要照顾多个学生，反之亦然），需要创建第三个表（将两个表中的主键作为复合键），并存储两个表的相关数据。
在处理完所有这些场景之后，您的db-schema将被规范化为4 NF。
jmo0nnb35#
在关系数据库设计领域，规范化是一种系统化的方法，用于确保数据库结构适合于通用查询，并且没有某些不希望的特性（插入、更新和删除异常），这些特性可能会导致数据完整性的损失。[1] E.F. Codd，关系模型的发明者，在1970年引入了规范化的概念和我们现在所知道的第一范式。[2] Codd在1971年定义了第二和第三范式，Codd和Raymond F.博伊斯在1974年定义了Boyce-Codd范式。[4]更高的范式在随后的几年中被其他理论家定义，最近的是由Chris Date，Hugh Darwen和Nikos Lorentzos在2002年引入的第六范式。
非正式地，一个关系数据库表（关系的计算机化表示）如果是第三范式（3 NF），通常被描述为“规范化”。[6]大多数3 NF表没有插入、更新和删除异常，即在大多数情况下3 NF表遵循BCNF、4 NF和5 NF（但通常不是6 NF）。
数据库设计指南的一个标准部分是设计人员应该创建完全规范化的设计;由于性能原因，可以随后执行选择性的反规格化。[7]然而，一些建模规则，如数据仓库设计的维度建模方法，明确推荐非规格化设计，即在很大程度上不遵守3 NF的设计。
**编辑：**来源：http://en.wikipedia.org/wiki/Database_normalization