数据库设计那些事

作者: _张旭 | 来源:发表于2018-06-24 22:28 被阅读0次

本文为慕课网课程数据库设计那些事的笔记。

什么是数据库设计

简单来说就是为我们的业务系统构造出最优的数据存储模型。

数据库的设计步骤

需求分析

数据是什么？
数据有哪些属性？
数据和属性的各自特点有哪些？

逻辑设计

使用ER图对数据库进行逻辑建模

物理设计

根据数据库自身特点，将逻辑设计转换为物理设计。

维护优化

新的需求建表
索引优化
大表拆分

需求分析

了解系统中所要存储的数据
了解数据存储的特点（时效性）
了解数据的生命周期

要搞清楚的问题

1.实体及实体间的对应关系（一对一，一对多，多对多）。
2.实体所包含的属性有什么？
3.哪些属性或者属性组合可以唯一标识出一个实体？

需求分析举例

以一个小型电商网站为例，其包含以下模块

用户模块
商品模块
订单模块
购物车模块
供应商模块

用户模块

用于注册用户信息
包括属性：用户名、密码、手机号、地址、姓名、昵称....
可选的唯一标识：用户名、身份证、手机
存储特点：随时间逐渐增加，需要永久存储（考虑分库、分表）

商品模块

记录网站中所销售的商品信息
包括属性：编码、名称、描述、品类、价格、供应商 ...
可选唯一标识：商品编码、（名称，供应商）
存储特点：对于下线产品可以归档存储（迁移到其他表）

订单模块

用户订购的商品信息
包括属性：订单号、用户姓名、用户电话、收货地址、商品编号、商品名称、数量、价格、订单状态、支付状态、订单类型...
可选唯一标识：订单号
存储特点：永久存储（分库、分表）

购物车模块

保存用户选购商品信息
包括属性：用户名、商品编号、商品名称、商品价格、商品描述、商品分类、加入时间...
可选唯一标识：购物车编号
存储特点：不永久存储（归档、清理规则）

供应商模块

保存商品供应商信息
包括属性：编号、名称、联系人、电话、营业执照、地址、法人....
可选唯一标识：营业执照
存储特点：永久存储

实体间关系

用户------(一对多)------>订单
用户------(一对多)------>购物车
商品<------(多对多)------>订单
商品<------(多对多)------>购物车
商品<------(多对多)------>供应商

逻辑设计—ER图

1.将需求转化为数据库的逻辑模型
2.DBMS系统无关
3.以ER图的形式对逻辑模型进行展示

图例

矩形：实体
菱形：关系
椭圆：实体属性
线段：用来连接上述对象

设计范式

范式：第一范式、第二范式、第三范式、BC范式
异常：插入、更新、删除
数据冗余：相同的数据存在多个地方、某列可以通过其他列计算得到

第一范式

数据表中所有字段都是单一属性不可再分的，要求数据表都是二维表

第二范式

数据表不存在非关键字段对任意组合关键字段的部分函数依赖（单关键字的表都是符合第二范式的）

注：部分函数依赖是指组合关键字中某字段决定非关键字段的情况

第三范式

数据表不存在非关键字段对任意关键字段的传递函数依赖

BC范式

数据表不存在任意字段对任意关键字段的传递函数依赖（组合关键字之间也不能存在函数依赖关系）

物理设计（MYSQL）

存储引擎的选择

MyISAM 不支持事务适用“写少读多” 忌读写频繁
Innodb 支持事物支持MVCC的行级锁适用于绝大多数场景（推荐使用）

表字段命名规范

可读性原则（单词首字母大写）
表意性原则
长名原则

字段选型原则

优先考虑数字类型
其次是日期或二进制类型
最后是字符类型
相同级别的数据类型，优先选择占用空间小的

其他注意事项

主键字段类型所占用空间要尽可能的小
避免使用外键约束（但是相关联的列上一定要建立索引）
避免使用触发器
严禁使用预留字段

反范式化

为了性能和读取效率适当的对第三范式进行违反（减少了表关联，增加数据读取效率，但是要适度）

数据库的维护和优化

维护数据字典

第三方工具
数据库本身的备注字段来维护

维护索引

如何建立索引？

出现在where、group by 、order by从句中的列
可选择性高的列要放到索引的前面
索引的列不要太长

注意事项

索引并不是越多越好，过多的索引会降低读写的效率
要定期维护索引碎片
sql中不要使用强制索引关键字

维护表结构