数据库逻辑设计

数据库设计

数据库设计包含需求设计、逻辑设计、物理设计和维护优化。

• 需求分析：全面了解产品设计的存储需求（存储需求，数据处理需求，数据的安全性和完整性）
• 逻辑设计：设计数据的逻辑存储结构（数据实体之间的逻辑关系，解决数据冗余和数据维护异常 ）
• 物理设计：根据所使用的数据库特色进行表结构设计
• 维护优化：根据实际状况对索引、存储结构等进行优化

数据库结构优化的目的

• 减小数据冗余
• 尽可能你变数据维护中出现更新，插入和删除异常
• 简约数据库的存储空间
• 提升查询效率

为了设计出没有数据冗余和数据维护异常的数据结构，咱们须要遵循如下规范：

• 第一范式

1. 数据库表中的全部字段都只有单一属性
2. 单一属性的列都是由基本的数据类型所构成
3. 设计出来的表都是简单的二维表

• 第二范式 要求一个表中只具备一个业务主键，也就是说符合第二范式的表中不能存在非主键列对只对部分主键的依赖关系。以学生选课为例，它的主键是复合主键（学生编号，课程），而学分只依赖于课程，即非主键列只对部分主键存在依赖关系，不符合第二范式。

  

针对这个问题，咱们怎么破呢？咱们对上面这个表拆分为3个表：学生表、课程表、学生课程关系表。其中，学生表和课程表只有一个主键，而学生课程关系表有一个复合主键（学生编号，课程），分数彻底依赖于这个复合主键，所以符合第二范式。

第三范式

每个非主属性既不部分依赖于也不传递依赖于业务主键，也就是在第二范式的基础上消除了非主属性对主键的传递依赖。 对于学生表，学院依赖于学生编号，而学院地址却依赖于学院，这就是传递依赖，此时，这张表不知足第三范式。若是想让这张表知足第三范式就须要继续对这张表进行拆分。

反范式化

遵循范式化的数据库设计，实现了消除数据冗余的目的，可是此时数据库的性能和读取效率并非最优的。为了性能和读取效率的考虑而适当的对数据库设计范式的要求进行违反，而容许存在少许的数据冗余，换句话来讲反范式化就是使用空间来换取时间。 举个栗子，以咱们常常进行下单为例。根据范式准则，定单表和订单商品关联表以下：

订单表：{订单编号，下单用户名，下单日期，支付金额，物流单号}
订单商品关联表：{订单编号，订单商品分类，订单商品名，商品数量}
复制代码

咱们知道查询订单时，每每须要知道用户名称和用户手机号，那么，此时咱们就须要将订单表和用户表进行关联查询。这种设计存在一个问题，当用户修改手机号，那么用旧手机号买的订单号的手机信息是新的手机号，而不是旧手机号，这是不符合业务需求的。解决这个问题的办法就是将用户名和用户手机号加入到订单表中。一样状况，商品的价格也存在修改的状况，所以，也须要将支付金额加入到订单表中，此时，订单表和订单商品关联表以下：

订单表：{订单编号，下单用户名，下单日期，支付金额，物流单号，订单金额}
订单商品关联表：{订单编号，订单商品分类，订单商品名，商品数量，商品单价}

复制代码

总结

• 范式化设计能够尽可能的减小数据冗余，更新操做比反范式化更快，可是对于查询须要对多个表进行关联，更难进行索引优化。
• 反范式化设计能够减小表的关联（顺序IO），能够更好的进行索引优化，可是存在数据冗余及数据维护异常，对数据的修改须要更多的成本（须要修改多个地方）。 所以，咱们须要结合反范式化和范式化，设计出高性能数据库结构。

---

欢迎关注微信公众号：木可大大，全部文章都将同步在公众号上。