前言
这里将以前不怎么熟悉的数据库设计知识重新拾起，做一个简单的知识梳理。之前一直认为数据库设计无非就是创建数据库、建表、添加字段、确定字段类型（这点随意性很大），诸如此类。当系统地对数据库知识重新学习的时候才发现数据库设计也有一套类似软件开发流程的规范，并且每一个步骤都是有不同的侧重点的。
数据库设计的概念
简单来说，数据库设计就是对需求进行分析、逻辑设计、物理设计以及维护和优化的过程。可以看到，数据库设计不仅仅体现在软件开发过程中，还体现在软件后期的维护上。（时间周期）
这里的软件需求分析与软件开发过程中的需求分析不太一样，数据库设计中的需求分析更侧重数据源（什么数据）、数据的属性以及数据和属性的特点。
数据库设计的一系列过程都需要结合我们现有的DBMS，设计表以及表之间联系，从而对数据进行有限的存储以及高效访问。
数据库设计的步骤
在此之前还有一个问题没有弄清楚，为什么要进行数据库设计？就我自己总结而言，有以下好处：
良好的数据库设计对减少数据冗余和操作异常、对数据有限存储和高效访问有很大帮助。之前自己做的毕业设计实现的实验管理系统就是由于没有对数据库好好设计，导致后面数据查找的困难，事实是，你写一大堆SQL代码还不一定得到你想要的结果，所以这就是糟糕的数据库设计的后果。各位小伙伴要引以为鉴呐。
数据库设计的步骤
OK，言归正传，数据库设计包括四个步骤：
- 需求分析
- 逻辑设计
- 物理设计
- 维护与优化
作为一名非专业DBA，本着实用即王道的原则，认为周边知识了解即可，不求深入。所以对最后的维护和优化不做详细的介绍，如果有小伙伴对这块比较感兴趣，可以参考数据库设计教程。
需求分析
需求分析需要解决三个问题：软件需要哪些数据、数据有哪些属性以及数据属性的特点。首先，软件需要的数据是由软件业务决定的，这点可以从前期的需求文档中看到；数据的属性就是数据库每个表中的字段，数据的属性是构成数据的不可缺少的元素，在数据库中一行数据成为数据的基本单元，也称为元组；数据属性的特点就是分析该数据是否需要永久保存，如果是则数据将一直存在数据库中，如果否，则该数据不能永久存在数据库中（这类数据一直是时间敏感的，涉及频繁的读写操作）。
逻辑设计
逻辑设计承接需求分析，要解决的核心问题就一个：绘制E-R图。E-R图就是把需求分析的结果转换成逻辑模型的过程。E-R图由三个要素组成：实体集、属性集和联系集。实体集都是具有相同属性的，属性集是实体所具有的，联系集则是由实体之间的联系组成的（这里的联系包括多种联系，后面的文章将详细说明这点，敬请期待）。所谓“逻辑设计”，就是与具体的DBMS无关。要绘制E-R图需要了解以下几个概念:
- 关系：一个关系对应数据库中的一张表
- 实体：具有一组相同属性的数据库管理对象
- 元组：表的一行数据
- 属性：每个属性对应数据库表的一列
- 主关键字：可以唯一标识实体的一条或多条属性
- 候选关键字：特指需要多条属性才能标识实体的情况
说完基本概念，下面就是实例讲解了，下面以我自己正在做的项目加以说明：
整个系统是学生信息管理系统，具有很多模块，我负责的模块是住宿信息管理，经过需求分析，最终确定该模块具有三部分的功能：学生物品报修、学生查询水电信息、宿管登记住宿信息、物业处理物品报修和后勤分配住宿信息。
学生: {学号,姓名,性别,联系方式,宿舍号}
宿管: {宿管ID,姓名,性别,联系方式}
物业: {物业管理人员ID,姓名,性别,联系方式}
后勤: {后勤管理人员ID,姓名,性别,联系方式}
住宿信息表: {id,姓名,学号,性别,宿舍号,专业,班级号,联系方式}
宿舍: {宿舍ID,楼栋号,宿舍号}
物品报修信息表: {id,物品名称,损坏情况,报修人,联系方式,宿舍号,报修时间,紧急程度,是否处理}
用水信息: {id,宿舍号,用水量,本月剩余水量,剩余金额,欠费状态}
用电信息: {id,宿舍号,用电量,本月剩余电量,剩余金额,欠费状态}
根据上面这些数据，可以绘制下面的E-R图：
由于原图过大所以，只展示了部分。下面简要说明一下图的内容，每一个矩形代表一个实体，每个实体都有属性集，<M>代表该字段不能为空，<pi>代表该字段是实体的主键，<ai>代表该字段是实体的候选关键字。实体之间存在各种联系，图中的线条就表示了实体与实体的具体联系。下面就简要说说这个联系是什么鬼：
在数据库设计中，存在4种基本的联系（Relationship）：一对多、一对一、多对一。举例来说，老师可以带多个学生上课，学生也有多个多个老师，所以老师和学生是多对多的联系；一个学生只能在一个班级，而一个班级可以有多个学生，所以学生与班级是多对一的联系。反正分析思路就是一个和多个的对应关系能否成立。继承（Inheritance）：例如学生、老师都是人，所以“学生”和“老师”这两个实体和“人”之间构成继承关系。继承关系的存在是为了以后更好的扩展。连接：具有连接关系的实体之间的地位是平等的，请仔细思考下图：
下面是开发人员、专家与讲座之间的关系：
从图中可以看出，如果两者不是连接关系就意味着地位的不平等。所以连接关系也挺好理解的。Ok，next，依赖：依赖就是某个实体不能单独存在，必须和另一个实体共存才有存在的意义。举例来说：门窗必须依赖房子而存在，没有房子，就没有门窗存在的必要。
物理设计
物理设计是最终的数据库设计的核心，也是可见成果的关键步骤。那么物理设计要解决什么问题呢？
- 选择合适的DBMS
- 规定数据库、表和字段的命名规范
- 根据所选的DBMS确定具体字段的字段类型
选择合适的数据库
目前，企业级数据库有Oracle和SQL Server，这类数据库对数据的安全性和容量有较高要求。互联网项目使用的一般都是MySQL、PgSQL，所以根据需要根据自己项目的类型选择合适的数据库。
规定命名规范
命名规范需要遵循字段可读性原则和见名知义原则，不然随意的字段名还要建立数据字典，增加额外的工作量，没什么必要。
确定字段类型
就我自己而言，觉得最不好判断的是char和var char类型，两种数据类型特别容易选择，所以一般情况都是选择更保守的varchar类型。但是只要仔细分析发现两种类型首先在表达的范围就存在限制，char类型不能超过255个字节，所以只要不是那种常文本一般都可以容纳，这点上讲，varchar比char节省空间，但是varchar比char效率更差，这一点可以这么理解：当对varchar类型的数据进行修改的时候，可能因为数据长度的不同（以字符串”abc”为例，char类型需要5个字节，而varchar只需要3个字节）导致“行迁移(Row Migration)”，下面Oracle对行迁移的官方解释：
当一行的记录初始插入时是可以存储在block（block是磁盘存储的最小单位）中的，由于更新操作导致行增加了，而block的自由空间已经满了，这个时候就产生了行迁移。在这种情况下，oracle将会把正行数据迁移到一个新的block中，oracle会保留被迁移的行的原始指针指向新的存放行数据的block，这意味着被迁移的ROW ID是不会改变的。
说的有点复杂，但总结起来可以知道varchar和char类型的差距不大，当然在大数据开发应用中除外。