数据库表的设计思路——三范式理解

范式（NF）: 符合某一种级别的关系模式的集合，表示一个关系内部各属性之间的联系的合理化程度

第一范式：对属性的原子性约束，要求属性具有原子性，不可再分解； 
第二范式：对记录的惟一性约束，要求记录有惟一标识，即实体的惟一性； 
第三范式：对字段冗余性的约束，要求字段不能由其他字段派生出来，即字段没有冗余

两个表之间的数据关系: 
1)一对一: 两个表里数据唯一对应; 
2)一对多: 表A在表B里对应多条数据,但表B里的一条数据绝对只对就A中的一条数据; 
3)多对多: A里的一条数据对应B里的多条数据,B里一条数据也对应A中的多条数据.

项目中数据库表的设计思路

1 ）首先分析业务，细化模块; 
2）找出模块要描述的东西并以表的形式表达出来(表的设计遵循三范式原则)； 
3）列出你想通过这个表要得到的相关信息的列表； 
4 ) 分析模块之间的关系（表与表之间的关系：一对一， 一对多， 多对多）

 一般的数据库设计都需要满足三范式，这是最基本的要求的，最高达到6NF，但是一般情况下3NF达到了就可以

一：1NF一范式的理解：

1NF是关系型数据库中的最基本要求，就是要求记录的属性是原子性，不可分，就是属性不能分，这是关系型数据库的基本要求，不满足这个就不能叫关系型数据库了

例如：时间(2013-03-31)  ----->开始/结束时间（2013-03-31,2013-05-05）

二：2NF二范式的理解

2NF是不能有部分依赖，部分依赖的前提条件是有组合主键，就是每条记录是需要一个主键的，这个主键可以是一个单独的属性，但也可以是组合主键，就是由记录的多个属性来唯一确定一条记录，那么只要出现了组合主键就可以产生部分依赖，部分依赖是组合主键出现的前提下，剩余的属性，不完全依赖于组合主键，也是部分依赖组合主键，比如该表的N条记录中由组合主键中的一条或者几条就可以确定剩余属性的属性，那么就可以说产生部分依赖，而在实际开发中，一般不采用组合主键，而是自己增加一个字段id自增长，作为主键，这样的单属性主键是不会产生部分依赖的！

三：3NF的理解：不能出现传递依赖：就是主键，非主键1，非主键2三者之间不能出现传递依赖关系，如果出现由主键可以推出非主键1,然后由非主键1可以推出非主键2，那么主键与非主键2就产生了传递依赖关系，这就不满足三范式，通俗来讲，在一个表的，当然以一条记录为单位，主键和非主键之间可以产生父子关系，但是非主键之间是不能出现父子关系的！

没有冗余的数据库未必是最好的数据库，有时为了提高运行效率，就必须降低范式标准，适当保留冗余数据。具体做法是： 在概念数据模型设计时遵守第三范式，降低范式标准的工作放到物理数据模型设计时考虑。降低范式就是增加字段，减少了查询时的关联，提高查询效率。