IT评测·应用市场-qidao123.com技术社区

标题: 数据库的三大范式如何理解? [打印本页]

作者: 锦通    时间: 2025-4-3 01:27
标题: 数据库的三大范式如何理解?
数据库的三大范式是指数据库计划中用来规范化表布局的规则。其目的是淘汰数据冗余,提高数据一致性和完备性。三大范式分别是:
第一范式(1NF)—— 原子性

第一范式要求表中的每个字段都必须是原子的,即字段中的值不可再分割。换句话说,每个字段只能包含一个值,不能是一个列表或集合。
通俗案例
假设你有一个门生信息表:
学号姓名电话号码001小明123456789, 987654321002小红234567890, 876543210 这里,小明和小红的电话号码字段包含了多个值,违反了第一范式。为了符合1NF,需要将电话号码字段拆分成独立的记录:
学号姓名电话号码001小明123456789001小明987654321002小红234567890002小红876543210 这样,每个字段都只有一个值,符合第一范式。

第二范式(2NF)—— 消除部门依赖

第二范式要求数据库中每个非主属性(字段)都完全依赖于主键,而不是仅依赖于主键的一部门。如果一个表有复合主键,必须确保每个非主属性依赖于整个复合主键,而不是只依赖于其中的一部门。
通俗案例
假设你有一个成绩表,复合主键是 学号 和 课程号,包含如下数据:
学号课程号姓名成绩001101小明95001102小明88002101小红92 这里,“姓名”字段依赖于“学号”字段,而不是依赖于整个复合主键“学号+课程号”。为了符合第二范式,我们可以将“姓名”从表中分离出来,建立一个独立的门生表:
这样,非主键字段“姓名”就完全依赖于主键“学号”,符合第二范式。

第三范式(3NF)—— 消除传递依赖

第三范式要求表中的非主键字段不仅要直接依赖于主键,而且不能通过其他非主键字段间接依赖于主键。如果存在这种传递依赖,就需要将其分解成多个表。
通俗案例
假设你有一个员工表,其中有员工的 部门名称 和 部门位置,数据如下:
员工编号姓名部门名称部门位置001小明技术部北京002小红销售部上海 这里,部门位置 是通过 部门名称 间接依赖于 员工编号(主键)。即:员工的 部门名称 决定了 部门位置,所以部门位置应该从这个表中提取出来,单独放在部门表中:
这样,部门位置 不再通过 部门名称 间接依赖于主键,符合第三范式。

总结


通过这些规范化的过程,可以让数据库布局更加合理,淘汰冗余数据,制止数据不一致的环境发生。

高并发系统中,三大范式的缺点是啥?

在高并发系统中,三大范式的计划虽然可以包管数据一致性和淘汰冗余,但它们也有一些缺点,尤其是在处置惩罚大量并发请求时。这些缺点重要表现在性能、复杂性和可扩展性方面。以下是每个范式的缺点及其对高并发系统的影响:
第一范式(1NF)缺点

缺点:1NF要求每个字段都是原子的,即每个字段只能存储一个值。虽然这是数据一致性的根本要求,但在高并发系统中,这种要求可能导致频仍的表拆分和数据更新操作,增加了数据库的负担。
影响

第二范式(2NF)缺点

缺点:2NF要求消除部门依赖,确保每个非主键字段完全依赖于主键。在复杂的业务场景中,消除部门依赖可能会导致过多的表拆分。
影响

第三范式(3NF)缺点

缺点:3NF消除了传递依赖,使得全部非主键字段都不依赖于其他非主键字段。这个原则可能导致数据库太过规范化,使得数据存储非常分散。
影响

高并发环境下的折中与办理方案

在高并发的环境下,严格遵照三大范式可能会导致性能瓶颈,尤其是在查询和写入操作上。为了提高系统的性能和可扩展性,通常会接纳以下计谋:
总结


因此,在高并发系统中,往往需要在规范化和性能之间找到平衡点,采用去规范化、缓存、分库分表等技术来优化性能。

免责声明:如果侵犯了您的权益,请联系站长,我们会及时删除侵权内容,谢谢合作!更多信息从访问主页:qidao123.com:ToB企服之家,中国第一个企服评测及商务社交产业平台。




欢迎光临 IT评测·应用市场-qidao123.com技术社区 (https://dis.qidao123.com/) Powered by Discuz! X3.4