数据库设计的第一步，就是了解与分析用户需求，确定系统边界信息需求、处理需求、安全性和完整性需求，然后编写系统分析报告。
系统分析报告的内容主要包括：
随系统分析报告需提供的附件还有：
需求分析有两种方法：自顶向下和自底向上。
具体来说，自底向上的分析，是从具体到抽象；而自顶向下的分析，则是从抽象到具体。举个例子就比较好理解了：
比如你想搭建一个电子商务网站，如果你是先确定核心模块包括哪些，然后根据每子模块的属性继续往下分。那么这种就是自顶而下的分析。
反之，如果你是先整理出大量的属性，然后对这些属性进行归纳总结出几大模块，那么就是自底向上的分析。
二、概念结构设计阶段概念结构设计，就是将上一阶段通过需求分析得到的用户需求抽象为概念结构，或称为概念模型（整个过程，其实就是我们前面提到的自底向上的分析）。描述概念模型的有力工具是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）主键的字段类型所占空间要尽可能的小：对于使用聚集索引方式存储的表，每个索引后都会附加主键信息
严格来说，数据库设计还有后续的实施阶段和运行维护阶段，如果继续展开下去又得半小时，这里就不做复述了（其实是想偷懒）。感兴趣的朋友可以在我整理的数据库资源包里找到续篇，包里还有其他数据库相关的思维导图学习资料，一并分享给大家。