MySQL 中的规范化是什么,在什么情况下以及我们需要如何使用它?
5 回答
我试图在这里用外行的术语来解释规范化。首先,它适用于关系数据库(Oracle、Access、MySQL),因此它不仅适用于 MySQL。
规范化是为了确保每个表都有唯一的最小字段并摆脱依赖关系。假设您有一个员工记录,每个员工都属于一个部门。如果您将部门与员工的其他数据一起存储为字段,您就会遇到问题 - 如果删除部门会发生什么?您必须更新所有部门字段,并且有可能出错。如果某些员工没有部门怎么办(也许是新分配的?)。现在会有空值。
因此,简而言之,规范化是避免字段为空,并确保表中的所有字段仅属于所描述的一个数据域。比如employee表中,字段可以是id、name、社保号,但这三个字段与部门无关。只有员工 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 )
有第一范式、第二范式和第三范式。但除非你正在学习数据库课程,否则我通常只会选择我能理解的最规范的形式。
希望这可以帮助。
规范化不仅适用于 MYSql。它是一个通用的数据库概念。
规范化是在数据库中有效组织数据的过程。规范化过程有两个目标:消除冗余数据(例如,将相同的数据存储在多个表中)和确保数据依赖关系有意义(仅将相关数据存储在表中)。这两个都是有价值的目标,因为它们减少了数据库消耗的空间量并确保数据的逻辑存储。
SQL 中的范式如下所示。
第一范式 (1NF):如果关系只有单值属性,则称该关系在 1NF 中,既不允许重复也不允许数组。
第二范式(2NF):如果一个关系在 1NF 中并且每个非键属性都完全依赖于主键,则称该关系在 2NF 中。
第三范式(3NF):如果一个关系在 2NF 中并且没有传递依赖,我们就说它在 3NF 中。
Boyce-Codd Normal Form (BCNF):当且仅当关系中的每个行列式都是候选键时,才称关系处于 BCNF 中。
第四范式(4NF):如果一个关系在 BCNF 中并且不包含多值依赖,则称该关系在 4NF 中。
第五范式(5NF):当且仅当关系中的每个连接依赖项都被关系的候选键隐含时,才称关系处于 5NF 中。
Domain-Key Normal Form (DKNF):如果一个关系没有任何修改异常,我们就说它在 DKNF 中。插入、删除和更新异常属于修改异常
另见
这是一种通过消除重复来确保您的数据保持一致的技术。因此,将相同信息存储在多个表中的数据库未进行规范化。
请参阅有关数据库规范化的 Wikipedia 文章。
(这是关系数据库的通用技术,不是 MySQL 特有的。)
在为您的应用程序创建数据库模式时,您需要确保避免将任何信息存储在跨不同表的多个列中。
由于数据库中的每个表都标识了应用程序中的重要实体,因此唯一标识符是它们的必备列。
现在,在决定存储模式时,正在确定这些实体(表)之间的各种关系,即一对一、一对多、多对多。
- 对于一对一的关系(例如,学生在班级中具有唯一的排名),可以使用同一个表来存储列(来自两个表)。
- 对于一对多的关系(例如,一个学期可以有多个课程),正在父表中创建一个外键。
- 对于多对多关系(例如,教授照顾许多学生,反之亦然),需要创建第三张表(两个表中的主键作为复合键),以及两者的相关数据表将被存储。
一旦你处理了所有这些场景,你的 db-schema 将被标准化为 4NF。
在关系数据库设计领域,规范化是一种系统化的方法,可确保数据库结构适用于通用查询,并且不存在某些可能导致数据完整性损失的不良特征——插入、更新和删除异常。 .[1] 关系模型的发明者 EF Codd 在 1970 年引入了规范化的概念以及我们现在所知的第一个规范形式。 [2] Codd 在 1971 年继续定义了第二和第三范式,[3] Codd 和 Raymond F. Boyce 在 1974 年定义了 Boyce-Codd 范式。 [4] 随后几年,其他理论家定义了更高的范式,最近的是 Chris Date、Hugh Darwen 和 Nikos Lorentzos 在 2002 年引入的第六范式。 [5]
非正式地,如果关系数据库表(关系的计算机化表示)处于第三范式(3NF),则通常将其描述为“规范化”。 [6] 大多数 3NF 表没有插入、更新和删除异常,即在大多数情况下,3NF 表遵循 BCNF、4NF 和 5NF(但通常不是 6NF)。
一个标准的数据库设计指南是设计者应该创建一个完全规范化的设计;出于性能原因,可以随后执行选择性非规范化。 [7] 然而,一些建模学科,例如数据仓库设计的维度建模方法,明确推荐非规范化设计,即在很大程度上不遵守 3NF 的设计[8]。