通俗地理解三个范式(通俗地理解是够用的理解，并不是最科学最准确的理解)：  

　　       第一范式：1NF是对属性的原子性约束，要求属性具有原子性，不可再分解；  

　　       第二范式：2NF是对记录的惟一性约束，要求记录有惟一标识，即实体的惟一性；  

　　       第三范式：3NF是对字段冗余性的约束，即任何字段不能由其他字段派生出来，要求字段没有冗余。

就看他一个商品只能属于一个分类，还是一个商品能属于多个分类，如果只能属于一个分类的话就是一个一对多的关系，就不需要三张表

太抬举我了，我就是个刚开始弄这里的小白，你可以直接说我说的不对。不过我说的懒加载是hibernate在进行建表的映射配置时配置的那个属性，不是前端显示图片那个啊。也是我打扰了，很抱歉

这个就像是学生表、课程表和选课表。商品分类与分类描述没有依赖关系。

如果你没有分类描述，肯定就两张表，效率快，如果你有分类描述，那肯定是3张表比较好，可维护性高点

感觉也行啊

这个要看情况的，如果你是一个商品只能有一个分类，一个分类可以有多个商品，这是一对多的情况，就没必要建关联表，如果是一个商品有多个分类，一个分类可以有多个商品。这是多对多的情况，就需要建关联表

多对一关系在一系查寻，数据迁移方便些，假如商品表直接存商品类型的话，你删除商品就等于删除商品类型了吗？不需要外中间表，用外键就行了，商品一张表，商品类型一张表，多对多就要用到中间表了，需要用中间表表示多对多关系...

其实，老师的意思是：第二范式不要出现两个ID及相关信息；第三范式，不要出现一个ID（相关信息）和另一个IＤ的部分信息（不含第二个ＩＤ）。

1、经验之谈， 关于商品分类信息，是会冗余在商品表里的。 简化查询，增加了缓存利用率。 

2、至于更新商品类型，是在商品类型表里去更新，不会影响之前冗余在商品表里的类型描述。

3、想要更新商品表里的类型， 可以单独修改商品表里的类型。 不会影响分类表的描述。

4、商品表里冗余数据，是从实际角度出发，不会出现经常更新的数据才会做冗余；商品一旦上线后，就不允许经常      修改类别了， 一般情况上线后的商品信息都是静态数据。 （商品表设计时考虑：动态和静态数据分离）

第二范式是非主属性要完全依赖于码，不存在部分依赖，而第三范式是在第二范式的基础之上的，再加上每个非主属性不存在传递函数依赖于码

楼上正解，若果一个商品对应多个分类的话，就需要建立第三张表来关联。

如果按照范式来说，增加ID，还是有数据冗余一说