一、系统需求分析阶段
数据库设计的第一步，就是了解与分析用户需求，确定系统边界信息需求、处理需求、安全性和完整性需求，然后编写系统分析报告。
系统分析报告的内容主要包括：
随系统分析报告需提供的附件还有：
需求分析有两种方法：自顶向下和自底向上。
具体来说，自底向上的分析，是从具体到抽象；而自顶向下的分析，则是从抽象到具体。举个例子就比较好理解了：
比如你想搭建一个电子商务网站，如果你是先确定核心模块包括哪些，然后根据每子模块的属性继续往下分。那么这种就是自顶而下的分析。
反之，如果你是先整理出大量的属性，然后对这些属性进行归纳总结出几大模块，那么就是自底向上的分析。
二、概念结构设计阶段
概念结构设计，就是将上一阶段通过需求分析得到的用户需求抽象为概念结构，或称为概念模型（整个过程，其实就是我们前面提到的自底向上的分析）。描述概念模型的有力工具是E-R模型。
E-R模型由三大要素组成，分别是实体、属性和联系。
- 实体是一个数据的使用者，代表软件系统中客观存在的生活中的实物，比如物体、人、部门、项目等；
- 实体中的所有特性称为属性，如用户有特定的姓名、性别、住址、电话、邮箱等元素；
- 实体与实体间存在联系，如，某一个人在某个公司的某个部门工作，其中的实体有"某个人"、“某个公司”和"某个公司的某个部门"。
E-R模型的绘制需要遵循三范式原则：
三、逻辑结构设计阶段
数据库逻辑设计，则是将上一阶段的概念结构转换成特定DBMS所支持的数据模型的过程。如下图所示：
其中初始关系模式设计过程，就是将E-R模型向关系模式的转换。
转换中要遵循以下原则：
- 一个实体转换为一个关系模式，实体的属性就是关系的属性，实体的键就是关系的键；
- 具有相同主键的关系可以合并；
- 一个联系转换为一个关系模式，分为以下几种情况：
一个1：1的联系可以转化为一个独立的关系模式，也可以与任意一端对应的关系模式合并。
一个1：N的联系可以转换为一个独立的关系模式，也可以与n端对应的关系模式合并。
假如有老师和学校两个实体，一个学校可以招收多个老师，但是一个老师只能选择一个学校（这里不讨论特殊情况）， 因此学校和老师是1：N的关系。现在要转换为关系模型，我们只需在老师的这端加上学校的唯一标识即可，这样做的原因是，因为一个老师只能在一个学校，学校相对老师是唯一的。
一个M：N的联系转换为一个关系。关系的属性由联系本身的属性和与之联系的实体的主键组成，关系的主键由联系中各实体的主键组合而成（组合键）。
四、物理结构设计阶段
物理设计是为逻辑数据模型选取一个最适合应用环境的物理结构。
1.选择哪种数据库
商业数据库（更适合企业级项目），比如：Oracle、SQLServer
开源数据库（适用于互联网项目）。比如：MySQL、PgSQL
2.数据库表级字段的命名规则：
可读性原则：使用大写和小写来格式化的库对象名字以获得良好的可读性
表意性原则：对象的名字应该能够描述它所标识的对象
长名原则：尽可能少使用或者不使用缩写，适用于数据库（DATABASE）名之外的任一对象
3.数据库字段类型选择原则
以上选择原则主要是从下面两个角度考虑：
1）在对数据进行比较（查询条件、JOIN条件及排序）操作时：同样的数据，字符处理往往比数字处理慢
2）在数据库中，数据处理以页为单位，列的长度越小，利于性能提升。
4.数据库设计其它注意事项
1）区分业务主键和数据库主键：业务主键用于标识业务数据，进行表与表之间的关联；数据库主键为了优化数据存储（Innodb会生成6个字节的隐含主键）
2）根据数据库的类型，考虑主键是否要顺序增长：有些数据库是按主键的顺序逻辑存储的
3）主键的字段类型所占空间要尽可能的小：对于使用聚集索引方式存储的表，每个索引后都会附加主键信息
严格来说，数据库设计还有后续的实施阶段和运行维护阶段，如果继续展开下去又得半小时，这里就不做复述了（其实是想偷懒）。感兴趣的朋友可以在我整理的数据库资源包里找到续篇，包里还有其他数据库相关的思维导图学习资料，一并分享给大家。
