设计数据库时，通常需要遵从不同的规范，设计出合理的数据库，减少数据冗余，而这些规范称为数据库范式，一般来说，只需要实现前三大范式即可。

下面说说我对这三大范式的理解：

以下表为例：

[sql] view plain copy print?

CREATE TABLE `test` (
`id` int UNSIGNED NOT NULL AUTO_INCREMENT ,
`name` varchar(50) NOT NULL ,
`email` char(20) NULL ,
`phone` char(12) NULL ,
`foreign_id` int UNSIGNED NOT NULL,
INDEX(`foreign_id`),
PRIMARY KEY (`id`)
)ENGINE=InnoDB;

CREATE TABLE `test` (

`id` int UNSIGNED NOT NULL AUTO_INCREMENT ,

`name` varchar(50) NOT NULL ,

`email` char(20) NULL ,

`phone` char(12) NULL ,

`foreign_id`  int UNSIGNED NOT NULL,

INDEX(`foreign_id`),

PRIMARY KEY (`id`)

)ENGINE=InnoDB;

别小看这个表，这个表就其实已经算是符合了三大范式哦。

第一范式，是针对于数据表的列的规范，即数据表的每一列都是不可分割的原子数据项，而不能是数组，集合，记录等非原子数据项，说白了就是，不能把好几列的数据合在一起，且每一列的数据都是不可分割的，看看两个错误的例子：

将几列数据合在一起=>错误

原子数据项被分割=>错误

第二范式，基于第一范式，非码属性必须完全依赖码，即非主键数据必须依赖主键数据。

“码”(主键)是数据表用来唯一区分实例或记录的数据项，若没有，可人为添加。

对于第一范式针对列来说，第二范式则是针对于行的规范。先说说他的作用吧，从作用反推他的实现。

他的作用就是让表的每一行都不会一样，以便我们可以识别任何一行记录。那怎么实现这个作用呢？答案是给每一行分配一个序号，或者以每一行里肯定不会和其它行一样的数据项来识别，这就要求其它“可能“会一样的数据完全依赖于此序号(数据项)。

看看错误实例：

第三范式，其实是第二范式的子集，也是基于第一范式，任何非码属性不依赖其他非码属性。

这个比较抽象，还是看图说话好了，下图是错误示例

咳咳，其实我还是只单身狗，没有交过这么多女票的，美女快来把我领回家。

回归主题，这个表有没有违反第二范式呢？没有，( ⊙ o ⊙ )是的，并没有。

这个表其实存在着一种依赖关系—“传递依赖“，girlfriend依赖着girlfriend_id,，而girlfriend_id依赖着id，如此即没有违反第二范式了。

但是，他就违反了第三范式，任何非码属性不依赖其他非码属性，通俗地讲，就是不能存在这种传递依赖关系，规范要我们怎么做呢？将上表拆分成两个表，如下：

表一

表二

两表之间通过grilfriend_id进行关联

如此，便符合第三范式了。