原则：
规范化的目的是一份数据只存储在一个地方。
根据上面的原则来理解3种范式：
第一范式：
列的原子性；
保证行的唯一性---一份数据只存储在一个地方。
第二范式：非属性键与主键的关系
1.满足第一范式
2.非键属性依赖于整体主键，而不是非键属性仅仅依赖于主键中的某个部分。即：无部分依赖:
违反第二范式就是存在部分依赖（非键属性仅仅依赖于主键中的某个部分）。
违反第二范式这有点像：
在一个由诸多长老全部举手表才能表决的组织里，你却只听一个或个别长老的话，这可是坏了规矩的。
例如，如下的关系就违背了第二范式：
关系名：PersonPet（人宠物）
主键：PesonId 、PetId
非键属性：PesonName、PetName、PetType
违背第二范式：PesonName只依赖于PesonId
PetName只依赖于PetId
举个例子，违反了第二范式存储的数据的样子：
PesonId PetId PesonName PetName
1 1 人才1 宠物1
2 2 人才2 宠物2
3 1 人才3 宠物1
在现实生活中，人和宠物的关系是多对多的关系，即：
1个人可以有0、1、1以上个宠物
1个宠物可以属于0（如流浪狗）、1（单身IT男）、1个以上（一对情侣）个人
我们从上表因为违反第二范式而存储的数据违反规范化的原则：
规范化的目的是一份数据只存储在一个地方。
即：PetId为1的宠物，在存储数据的时候，被复制了多次，存放的不同的地方。
这样会对数据的增、删、改。会有什么影响：
增:
1.通常来说，当需要对单个事物（单个人、单个宠物）进行处理，而不是处理他们之间关系时，
因为没有专门为“人”这个实体建立了的表（如:Person表）为了增加一个人，不得不在PersonPet（人宠物表）中添加人
的相关信息，而在“宠物”相关的列输入无意义的值。
在单独查询人（不查询宠物）的时，不得不额外去除掉那些来自宠物相关信息。
2.只要一个人有多个宠物,这个人的信息将被多次复制。同样：
3.只要一个宠物属于多个人，这个宠物的信息也将被多少复制。
删：
当需要对单个事物（单个人、单个宠物）进行处理，而不是处理他们之间关系时，对删除的影响：
如果PesonId为1和3（这对情侣可能同时出现车祸）的人都没，要删除这两个人，存储的数据就是这样的：
PesonId PetId PesonName PetName
NULL 1 NULL 宠物1
2 2 人才2 宠物2
NULL 1 NULL 宠物1
可以看到这样的设计基本废掉了。
改：
数据同步问题， 例如：通过主键（PesonId ，PetId）=（1,1）修改 PetName的值“宠物1”为“宠物007”，如果在编程时没有
注意同步
PesonId PetId PesonName PetName
3 1 人才3 宠物1
那么就破坏了数据。
第三范式：非属性键之间的关系
1.满足第二范式
2.非属性键不依赖于非属性键，即：不存在传递依赖。
违反第三范式这有点像：
在朝廷中有个皇帝（主键）就够了，有人结党私营，搞小团体，听命于一个小头目（非属性键依赖于非属性键），也是坏了规矩的。
Book表
主键：BookIsbnNunmber
非属性键：Title
Price
PublishName
PublishCity
这个表满足了第二范式.
但是违反了第三范式：
非属性键PublishCity依赖于非属性键PublishName。
违反了第三范式将导致如下问题，例如下面违反了第三范式的表存储的数据：
BookIsbnNunmber Title Price PublishName PublishCity
1001 《我是人才》 63.1 人才出版社 地球村
1002 《我是蠢材》 87.2 人才出版社 地球村
按常规，我们都是通过“主键”去唯一定位要修改的数据,所以，用如下SQL语句：
Update adb.Book
Set PublishCity='月亮城'
Where BookIsbnNunmber=‘1001’;
执行以上SQL后，表中的数据如下：
BookIsbnNunmber Title Price PublishName PublishCity
1001 《我是人才》 63.1 人才出版社 月亮城
1002 《我是蠢材》 87.2 人才出版社 地球村
这就产生了数据同步的问题，数据在更新时被破坏了。
PublishName PublishCity
人才出版社 月亮城
人才出版社 地球村
由于违反了第三范式（非属性键PublishCity依赖于非属性键PublishName），
我们就得写额外的处理去更新所有列的PublishName
Update adb.Book
Set PublishCity='月亮城'
Where PublishCity='地球村' And PublishName='人才出版社'
这样，说明一点，违反第三范式，为了更细数据时，避免非属性键之间依赖产生的数据同步问题，不得不
进行而不处理数据同步问题，但是这额外的同步数据操作很容易被忘记，
更糟糕的是，系统的关系会随着时间的关系不断变化，你也将越来越头痛。