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数据库模式时,需要确保避免将任何信息存储在不同表中的多个列中。

由于数据库中的每个表都标识了应用程序中的重要实体,因此唯一的标识符是它们必备的列。

现在,在决定存储模式的同时,在这些实体(表)之间正在识别各种关系,即一对一,一对多,多对多。

  1. 对于一对一的关系(例如,学生在课堂上有独特的排名),可以使用同一个表来存储列(来自两个表)。
  2. 对于一对多的关系(例如一个学期可以有多个课程),在父表中创build一个外键。
  3. 对于多对多的关系(例如教授参加许多学生,反之亦然),需要创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就会出现。