数据库设计的范式和反范式介绍

范式化

  • 第一范式:数据库表的每一列都是不可分割的原子数据项,确保每一列的原子性
  • 第二范式:如果一个关系满足1NF,并且除了主键以外的其它列,都依赖与该主键;即一个表中不能有两个主键。即非主键字段必须依赖于主键字段
  • 第三范式:在2NF基础上,除了主键以外的其它列都不传递依赖于主键列,或者说: 任何非主属性不依赖于其它非主属性(在2NF基础上消除传递依赖)(不准冗余)

总结:一范式就是属性不可分割,二范式就是要有主键,其他字段都依赖于主键,三范式就是要消除传递依赖,消除冗余,就是各种信息只在一个地方存储,不出现在多张表中

反范式化

不满足范式的模型,就是反范式模型,反范式跟范式所要求的正好相反,在反范式的设计模式,并不是完全不遵守范式模型,而是允许适当的数据的冗余,用这个冗余去取操作数据时间的缩短。本质上就是用空间来换取时间,把数据冗余在多个表中,当查询时可以减少或者是避免表之间的关联

两者对比

  • 范式数据没有冗余,更新容易,但是查询时需要join很多表,导致效率较低;反范式数据存在冗余,更新时需要进行更多的操作,但是因为很多数据沉淀在同一表,查询效率较高
  • 传统数据表,更新频繁,不适合反范式设计;而在hive这种存储系统中,数据不允许更新,且查询需求更为频繁,因此天然适合反范式模型设计。

实际应用中,一般对需要综合使用范式和反范式,保证空间和时间的平衡,但是随着磁盘空间的越来越廉价,反范式应用越来越普遍

### 范式反范式的概念 #### 范式 (Normalization) 范式是一种数据库设计方法,旨在减少数据冗余并提高数据完整性。通过规范化处理,可以消除重复组、创建单一主题的小型表格,并确保每个表只包含最少数量的列。范式分为多个级别,通常提到的第一至第三范式是最常见的。 - **第一范式 (1NF)**:确保每列都是原子性的,即不可再分。 - **第二范式 (2NF)**:在满足1NF的基础上,消除了部分依赖,使得非主键属性完全依赖于整个主键。 - **第三范式 (3NF)**:进一步去除传递依赖,在2NF基础上不允许存在非主键之间的间接关联[^2]。 ```sql CREATE TABLE Orders ( OrderID INT PRIMARY KEY, CustomerID INT NOT NULL, ProductID INT NOT NULL, Quantity INT NOT NULL, FOREIGN KEY (CustomerID) REFERENCES Customers(CustomerID), FOREIGN KEY (ProductID) REFERENCES Products(ProductID) ); ``` 此SQL语句展示了如何按照范式原则构建订单表,其中`Orders`表仅保存必要的信息而不含任何冗余字段。 #### 反范式 (Denormalization) 相比之下,反范式则是有意违反某些范式规则以换取更好的读取性能或其他特定目标的技术手段。这可能涉及增加一些冗余度或将原本分开存储的信息合并到一起。虽然这样做可能导致更复杂的维护工作以及潜在的数据一致性风险,但在某些场景下确实能显著提升效率[^4]。 ```sql CREATE TABLE SalesReport ( ReportDate DATE, TotalSales DECIMAL(10, 2), MostSoldItem VARCHAR(255), BestCustomerName VARCHAR(255) ); ``` 这里展示了一个经过反范化后的销售报告表例子,它直接包含了汇总统计结果其他预计算好的值以便快速访问。 ### 应用场景分析 对于高并发读操作的应用程序来说,适当运用反范式能够有效降低查询延迟;而对于写密集型应用,则应优先考虑遵循严格的范式标准来保障事务的一致性简化管理流程。当面对海量数据分析任务时,可以通过预先聚合或缓存常用视图的方式来实现局部范围内的反范式优化,从而达到平衡两者优势的效果[^1]。
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值