业务数据库设计流程
需求分析分析—>概要设计—>详细设计

瀑布模型和螺旋模型

瀑布模型: 只有往下迭代开发,没有回溯.多适合用于业务需求十分明确可以一次性完成开发

螺旋模型: 有回溯,多次迭代开发.每次开发仅完成一部分的内容,与瀑布模型相反,用敏捷开发快速迭代出一版,适用于业务需求并不明确.

宽表模式
将属性全部列在一个表中

缺点

  1. 数据冗余,相同数据出现多次
  2. 维护成本高
  3. 更新异常
  4. 插入异常: 部分数据由于缺失主键信息而不得显示
  5. 删除异常: 删除某一数据时不得不删除另一数据

适用场景
配合列存储的数据报表应用

逻辑设计: 数据库设计范式

第一范式: 表中的所有字段都是不可再分的

第二范式: 表中必须存在业务主键(能够唯一标识出每一行业务数据的列或者列的组合),并且非主键依赖于全部业务主键,意味着列非主键不能只依赖于组合业务主键中的某一个主属性

第三范式: 表中的非主键列之间不能相互依赖.(传递依赖),第三范式的目的就是为了让非主键列的字段只完全依赖于主键列,与其他列无关.

ER图:实体关系图,

属性语法

复合属性是多个属性的组合

多值属性是某个属性可以有多个不同的取值

派生属性是不保存在实体中的属性,用虚线绘制

可选属性是允许有空值的属性(在名字下方增加”(0)” )

主键字段由下划线标识

实体关系语法

一对一关系

一对多关系

MySQL存储引擎
| 引擎名称 | 支持事务 | 说明 |
| —- | —- | —- |
| MyISAM | No | 不具备事务机制,不具备多线程访问,串行执行SQL语句 |
| CSV引擎 | No | 以CSV格式存储的非事务型存储引擎|
| Memory | No |存储于内存中的易失型非事务型存储引擎|
| Archive |No| 只允许查询和新增数据而不允许修改的非事务型存储引擎|
| InnoDB |Yes |最常用,支持事务机制,适合写多读多,支持多线程读写,在多线程读写的时候是用行锁而不是MyISAM引擎的表锁
| TokuDB |Yes |支持事务机制,适合写多读少.

InoDB引擎特点

  1. 事务型存储引擎支持ACID
  2. 数据按主键聚集存储: 按照主键顺序存储
  3. 支持行级锁及MVCC(多版本的并发控制)
  4. 支持B树和自适应Hash索引
  5. 支持全文和空间索引