前面的话
本文将详细介绍数据库设计的相关知识
设计范式
数据库设计共有三大范式：
第一范式：无重复的列
第二范式：属性完全依赖于主键
第三范式：属性不能依赖于主属性
下面将分别对这三个范式进行详细介绍
第一范式
数据库表中的每一列都是不可分割的基本数据项，同一列中不能有多个值。具体而言，有以下两条要求
1、每一列属性都是不可再分的，确保每一列的原子性
2、两列的属性相近或相似或一样，尽量合并属性一样的列， 确保不产生冗余数据
以考勤表设计为例，考勤表用来记录每天学生的考勤情况
最简单的情况是，每一天都建立一张表。字段是每个学生的姓名，列值表示是否签到。这样，可以很方便的存储当天的考勤情况。但是，这也导致了每天都需要在数据库里新建一张考勤表。而且，这种做法违反了第一范式，这张考勤表的字段的属性含义都是一样的，都是记录学员的考勤情况。因此，这些字段是需要合并的
更优化的设计是，第一字段是学生姓名，第二字段是0101表示`1月1日，第三字段是0102表示1月2日，以此类推。这种做法，不再需要设计那么多表，将学生的姓名列合并成了一个姓名列。但是，同样它没有遵循第一范式，1年365天， 代码除了学生姓名列外，还需要设置365个字段。而且，这些列的含义都是一样的，记录当天的考勤。因此，这些字段也是需要合并的
下面是优化的情况，把所有的日期合并成一个日期字段，新增一个考勤状态字段，如下所示，完全遵循了第一范式，没有重复的列，且每一列都是可拆分的。
总而言之，用第一范式设计数据库时，就是分解数据，并将属性相似的列合并
第二范式
第二范式需要遵循以下要求：
1、一个表表必须有一个主键
2、没有包含在主键中的列必须完全依赖于主键，而不能只 依赖于主键的一部分
以下面购物车表为例，用户ID和商品ID构成了商品的主键，数量列依赖于用户购买商品的数量，单价和商品名称只依赖于商品ID。因此，这张表不满足第二范式
优化后，修改如下
第三范式
非主键列必须直接依赖于主键，不能存在传递依赖。第三范式，相较于第二范式而言，强调的是直接依赖，而不能是传递依赖
关于传递依赖，以下面的中奖信息表为例，中奖金额依赖于中奖等级，而中将等级及依赖于用户ID，这就是传递依赖
要遵循第三范式，就要消除传递依赖
新闻系统
下面尝试利用三个范式，来设计新闻系统数据库。包括以下要点：
1、用户名、密码、是否是管理员
2、新闻标题、新闻内容、作者、新闻时间、是否上线
3、评论人、评论内容、评论时间、评论源
分别对应用户表、新闻表和评论表
一般来说，用户名长度不超过20个字符，密码长度不超过20个字符，新闻标题长度不超过30个字符，新闻内容长度不超过5000个字符，评论内容长度不超过300个字符
用户表详细如下
新闻表详细如下
评论表详细如下
最后
在设计数据库时，只需满足以上三个范式，就可以设计既合理又满足需求的数据库