深圳网站建设伪静态 报价 jsp 语言,网站查询,万维定制平台,怎么制作图片二维码一、范式化的概念范式化#xff08;Normalization#xff09;的目标是消除数据冗余#xff0c;减小物理存储空间。常用的范式有以下3种#xff1a;1. 第一范式#xff08;1NF#xff09;在任何一个关系数据库中#xff0c;1NF是对关系模式的基本要求#xff0c;不满足1…一、范式化的概念 范式化Normalization的目标是消除数据冗余减小物理存储空间。 常用的范式有以下3种1. 第一范式1NF 在任何一个关系数据库中1NF是对关系模式的基本要求不满足1NF的数据库就不是关系数据库。 所谓1NF是指数据库表的每一列都是不可分割的基本数据项同一列中不能有多个值即实体中的某个属性不能有多个值或者不能有重复的属性。如果出现重复的属性就可能需要定义一个新的实体新的实体由重复的属性构成新实体与原实体之间为一对多关系。在1NF中表的每一行只包含一个实例的信息。 例如对于员工信息表不能将员工信息都放在一列中显示也不能将其中的两列或多列在一列中显示员工信息表的每一行只表示一个员工的信息一个员工的信息在表中只出现一次。简而言之第一范式就是无重复的列。 2. 第二范式2NF 2NF是在1NF的基础上建立起来的即满足2NF必须先满足1NF。2NF要求数据库表中的每个实例或行必须可以被唯一地区分。为实现区分通常需要为表加上一个列以存储各个实例的唯一标识。 例如员工信息表中加上了“员工编号”列因为每个员工的员工编号是唯一的因此每个员工可以被唯一区分。这个唯一属性列被称为主关键字或主键、主码。 2NF要求实体的属性完全依赖于主关键字。所谓完全依赖是指不能存在仅依赖主关键字一部分的属性如果存在那么这个属性和主关键字的这一部分应该分离出来形成一个新的实体新实体与原实体之间是一对多的关系。为实现区分通常需要为表加上一个列以存储各个实例的唯一标识。简而言之第二范式就是非主属性非部分依赖于主关键字。 3. 第三范式3NF 3NF要求一个数据库表中不包含已在其它表中已包含的非主关键字信息。简而言之3NF就是属性不依赖于其它非主属性。 满足3NF必须先满足2NF。 例如存在一个部门信息表有“部门编号”、“部门名称”、“部门简介”等列。那么在员工信息表中列出“部门编号”后就不能再将“部门名称”、“部门简介”等与部门有关的信息再加入员工信息表中。如果不存在部门信息表则3NF也应该构建它否则就会有大量的数据冗余。 二、范式化的优点1. 从设计角度 范式化之后每个表的结构非常明确对于设计人员来说非常清晰明了更易于修改系统的架构。 2. 从性能的角度 范式化之后每个表变成最窄因此每一页可以容纳更多的行。查询、排序、索引的开销都会降低。 三、反范式化1. 范式化的缺点 当数据来自不同的表需要join当基表的记录非常多时这也将是一个消耗资源的重要原因。此外频繁查询一些派生列时需要临时计算这也会影响性能而且可能会使查询的设计过程变得复杂。 例如对于一张超市POS机的流水单明细表3NF之后只记录商品ID、单价、数量、单项折扣等信息查询时才临时产生一个单项金额。 而这张流水单明细表对应的流水单主表同样也不会保存金额在查询时通过聚合函数临时计算。 对于上述表结构如果频繁查询金额并且表的记录数非常多性能就会受影响。 2. 反范式化De-normalization 在范式化的架构遇到性能问题时就要考虑放宽范式的要求。通常要仔细权衡将更新增、删、改与查询这两者的开销进行对比。 例如在数据更改时就直接计算聚合值而不是在查询时再临时计算。 3. 反范式化的优势1减少join的数量2减少外键的数量3减少索引的数量从而节省存储空间4加快查询速度因为聚合值已经预先计算5某些情况下可能减少表的数目 四、反范式化的缺点1. 虽然加速查询但降低写入速度。2. 需要考虑应用程序是否适应。3. 可能需要增加物理表。4. 可能使代码变得简单也可能更复杂。 五、范式化 vs. 反范式化 范式化对表结构的严格要求可能会影响性能。在设计阶段务必权衡查询与更新增删改的开销对比。1. 考虑范式化 较多的更新而较少的查询时。 2. 考虑反范式化 较少的更新而较多的查询时。 本文结语 范式化和反范式化各有优势与短板需要从存储空间、维护的开销、查询的开销等方面综合考量。
