设计数据库时，通常需要遵从不同的规范，设计出合理的数据库，减少数据冗余，而这些规范称为数据库范式，一般来说，只需要实现前三大范式即可。
下面说说我对这三大范式的理解：
以下表为例：
- 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进行关联
如此，便符合第三范式了。