目录
数据库优化的目的
数据库结构设计的步骤
数据库设计范式
数据库第一范式
数据库第二范式
数据库第三范式
数据库设计的目的
实战
需求说明
需求分析及逻辑设计
需求分析及逻辑设计-反范式化设计
反范式化设计总结
范式化设计和反范式化设计优缺点
数据库的物理设计介绍
物理设计涉及的内容
定义数据库表、及字段命名规范
选择适合的存储引擎
物理设计-数据类型的选择
不同数据类型在Mysql服务器上的体现
如何选择VARCHAR和CHAR类型
应该如何确定VARCHAR的宽度
VARCHAR的实用场景
如何选择varchar和char类型
CHAR类型的适用场景
物理设计-如何存储日期类型
如何存储日期数据
timestamp在Mysql的时区不同的体现
datetime、timestamp是如何存储微秒值
查看timestamp自动更新特征
Timstamp数据结果操作结论
date类型和time类型
存储日期时间数据注意的事项
物理设计——本章节总结
存储引擎的最好选择
InnoDB存储引擎的选择注意事项
如何为Innodb选择主键
数据库设计的整个过程
数据库优化的目的
1 减少数据的冗余。问：那么什么是数据冗余呢？
答：指相同的数据在多个地方的存在，或者说表中的某个列的，可以由其他列来计算得到，这样的数据就是冗余的。这里所说的，那是要尽量减少数据的冗余，而不是说要完全的没有冗余的数据，因为在一些情况下，必要的数据冗余也是必须的。
2 尽量避免在数据维护中出现的更新，插入以及删除异常。3 节约数据库的存储空间 4 提高查询的效率
数据库结构设计的步骤
数据库设计范式
数据库第一范式
例子：
分析：
每一列不可拆分，所有列由基本的数据类型组成，是二维表（但是还是存在冗余【反范式】）
数据库第二范式
例子：show creat table selectcourse;
分析：学号课程名称组成符合组件，有可能不满足第二范式要求的，学分只和课程名称名称关联也就是上面的第二个，总结是不符合。
拆分成符合：
分成：《学分表》《课程表》《学生选课关系表》
show create table study\G
show create table course\G
前两种表只有一个主键so满足第二范式要求；
show create tablestudycourse\G
第三张表不存在非主键的依赖关系也是符合第二范式。
修改结果
已满足第二范式看是否满足第三范式。
数据库第三范式
例子：
分析：但是学院的地址和学院又有依赖关系，那就是说学院地址和学院具有传递依赖关系。
拆分改造：《学生信息表》《学院信息表》
结论：第三范式该造后不会有数据冗余和数据维护异常。
数据库设计的目的
实战
需求说明
按下面的需求，设计一个电子商务网站的数据结构
网站只销售图书类商品需要具有以下功能（用户登录，商品展示，供应商管理，用户管理，在线销售）
需求分析及逻辑设计
用户登录及用户管理功能
用户必须注册并登录系统才能进行网上交易（用户名作为用户信息的业务主键）同一时间，一个用户只能在一个地方登陆用户信息：{用户名，密码，手机号，姓名，注册日期，在线状态，出生日期}
只有一个业务主键，一定是符合第二范式；
没有属性和业务主线存在传递依赖关系，符合第三范式
商品展示及商品管理功能
供应商管理功能
在线销售功能
问：这样的设计已经符合了范式化的要求，但是数据库处理来说，是否是高效的呢？
答：前面我们已经说过，在数据库设计时不仅要考虑到范式化，同时也要考虑到查询性能的要求！
问：编写SQL查询出每一个用户的订单总额？
答：
首先这个查询关联四张表，关于MySQL而言关联表越多性能越差，虽然说四张表并不算多，但是这样的查询可能会非常的频繁，所以如果能减少关联表的数量，能提高性能！
问：现在只在商品表中记录了价格，一旦商品发生价格变动，会产生什么样的问题呢？
答：这样会导致历史订单的价格也会发生变化，我们恰恰是不想要看到的。
假设下单用户就是商品的收货人，我们在发货前一定要查询出每个订单的下单人信息，而这些信息全部记录在用户信息表中。
问：编写SQL查询出下单用户和订单详情？
答：
结论：完全符合范式化的设计，有时并不能得到良好的SQL查询性能(即反范式化设计)。
需求分析及逻辑设计-反范式化设计
问：什么叫做反范式化设计？
答：反范式化是针对范式化而言的，在前面介绍了数据库设计的方式，所谓的反范式化就是为了性能和读取效率的考虑，而适而适当的对数据库设计范式的要求进行违反，而允许存在少量的数据冗余，换句话来说，办事话就是利用空间来换取时间。
图书在线销售网站数据库的反范式化改造
反范式化改造后的查询
问：编写SQL查询出每一个用户的订单总额？
答：
问：编写SQL查询出下单用户和订单详情？
答：
反范式化设计总结
不能完全按照范式化的要求进行设计考虑如何使用表范式化设计和反范式化设计优缺点
1 范式化设计的优点2 范式化设计的缺点1 反范式化优点2 反范式化缺点数据库的物理设计介绍
问：什么是数据库的物理设计？
答：根据所选择的关系型数据库的特点，对逻辑模型进行存储结构设计。
物理设计涉及的内容
定义数据库、表及字段命名规范选择合适的存储引擎为表中的字段选择合适的数据类型建立数据库结构定义数据库表、及字段命名规范
定义数据库、表及字段命名要遵守 可读性原则定义数据库、表及字段命名要遵守 表意性原则定义数据库、表及字段命名要遵守长名原则选择适合的存储引擎
物理设计-数据类型的选择
为表中的字段选择合适的数据类型
当一个列可以选择多种数据类型时，应该优先考虑数字类型，其次是日期或二进制类型，最后是字符型，对于相同级别的数据类型，应该优先选择占有空间小的数据类型。
问：如何选择正确的整数类型？
答：
问：如何选择正确的实数类型？
答：
不同数据类型在Mysql服务器上的体现
1、表结构：
2、查询表内容：select * from t_double
3、对上述数据进行汇总操作 select i,sum(d1) as a,sum(d2) as b from t_double group by i having a<>b;
结论：21.40000000..6意味着double是非精确的值，两个double汇总和直接结果是有差异的，DECIMAL是精确地实数类型，但是所占用存储空间比上述2个大——财务数据，其他可以用double和float。
如何选择VARCHAR和CHAR类型
VARCHAR的存储特点
VARCHAR用于存储变长字符串，只占用必要的存储空间（无论长短varchar只占有必要的存储空间，如varchar(50)近存储10个字符，只占用10个字符的宽度，字符==多个字节-->【UTF-8 1个字符==3个字节】，VARCHAR是以字符为单位不是以字节为单位，如：以UTF-8为例，varchar中存储10个字符，只要定义为10即可，而不是30）列的最大长度小于255，则只占用一个额外字节，用于记录字符串长度列的最大长度大于255，则要占用两个额外字节，用于记录字符串的长度
应该如何确定VARCHAR的宽度
VARCHAR的实用场景
如何选择varchar和char类型
CHAR类型的适用场景
物理设计-如何存储日期类型
如何存储日期数据
timestamp在Mysql的时区不同的体现
1、设置时区
set time_zone='+10:00';
2、创建表
create table t(d1 datetime,d2 timestamp);
3、插入时间值
insert into t values(new(),now());
4、插入结果
5、修改当前时区后查询变化是什么呢？
结论：timestamp数据显示和时区有关。
datetime、timestamp是如何存储微秒值
进行宽度设置（alter table t modify d1 datetime(6),modify d2 timestamp(6);）插入数据（insert into t values(now(),now());）查询结果有图所示查看timestamp自动更新特征
drop table t;create table t(id int,d1 datetime,d2 timestamp not null,d3 timestamp not null);insert into values(1,now(),now(),now());如果只插入id（insert into t(id) value(1);）插入结果，仅仅datetime类型数据为空Timstamp数据结果操作结论
timestamp具有自动更新的功能，但是第二个却不能就能发现，在MySql中只有第一个Timestamp类型具有自动跟新的。
date类型和time类型
在mysql 5.7之前的操作如上，mysql5.7 以后的版本直接使用date类型
存储日期时间数据注意的事项
物理设计——本章节总结
存储引擎的最好选择
InnoDB存储引擎的选择注意事项
如何为Innodb选择主键
数据库设计的整个过程
![[06月]跳皮筋作文700字](https://700zi.400zi.cn/uploadfile/img/2024/06/11/5d6569f8c6ebae1ce134fe4ddcfec138.jpg)
