• E-R模型在数据库概念设计阶段广泛采用
• E-R模型的构成成分是实体集，属性和联系集
• 实体是把具有属性、性质和特征相同的实体，用所有实体名和他的属性名称的来用抽象的形式描述同种类的实体;一般实体用矩形符号表示，矩形框内标注实体的名称
• 属性是实体特有的一些特性，一个实体有包含有许多个属性来进行描述。用椭圆形的符号来表示，用无向直线将属性的椭圆和其相对应的实体图形串联起来
• 联系是ER模型中的联系是用来反映实体内部和实体之间的属性关系。用菱形符号表示，在菱形框内标注联系的名称，然后使用无向直线将有关系的实体属性串联起来，还需要在无向直线上标出实体和联系的类型（1 : 1，1 : n或m : n）
• 例如系、学生和课程的联系的E-R模型
• 系、学生和课程作为实体集；一个系有多个学生，而一个学生仅属于一个系，所以系和学生之间是一对多的联系；一个学生可以选修多门课程，而一门课程有多个学生选修，所以学生和课程之间是多对多的联系
• E-R模型的设计也要遵循三范式的要求
• 第三范式是数据库逻辑设计阶段的有效方法
• 第一范式(1NF)：表示每个属性都不可分，是数据库设计的基本要求
• 仅符合第一范式存在数据冗余过大，插入删除和修改异常的问题
• 假如学校新建了一个系，但是暂时还没有招收任何学生（比如3月份就新建了，但要等到8月份才招生），那么是无法将系名与系主任的数据单独地添加到数据表中去的 （注１）——插入异常
• 假如将某个系中所有学生相关的记录都删除，那么所有系与系主任的数据也就随之消失了（一个系所有学生都没有了，并不表示这个系就没有了）。——删除异常
• 假如李小明转系到法律系，那么为了保证数据库中数据的一致性，需要修改三条记录中系与系主任的数据。——修改异常
• 第二范式(2NF)：在第一范式的基础上限制一个表只能表达一个实体
• 第三范式(3NF)：在第二范式的基础上，表中的每列都和主键有直接关系，而不存在传递性依赖
• 符合3NF要求的数据库设计，基本上解决了数据冗余过大，插入异常，修改异常，删除异常的问题。当然，在实际中，往往为了性能上或者应对扩展的需要，经常 做到2NF或者1NF，但是作为数据库设计
人员，至少应该知道，3NF的要求是怎样的
• 范式的优势在于：
• 当数据较好的范式化时，就只有很少或者没有重复数据，所以只需要修改更少的数据，也就意味着更新操作更快
• 范式化的表通常更小，可以更好地放在内存里，所以执行操作会更快
• 很少有多余的数据意味着检索列表数据时更少需要distinct或者groupby语句
• 范式化的缺点在于通常需要表关联，有的时候会显得代价昂贵
• 事实上在是否对每个应用场景使用第三范式设计表结构不是固定的，要具体问题具体分析，实际情况中经常混合使用
• 比如按照第三范式只会在teacher表中存储老师姓名的字段，但如果经常会碰到查询课程信息和对应老师姓名的语句时，就可以考虑将老师姓名也存储在course表中一份，以便在查询时不再需要两个表关联查
询。
• 当然还要评估老师姓名是否会经常变化，如果经常变化那更新两个表的代价也比较大，所以要综合评估
• 另外也有排序的需要，当子表中的字段要依赖父表的信息排序时，关联排序往往代价很大，可以考虑冗余排序字段到子表并建立索引。
• 当比如要经常计算老师的课程数时，可以考虑将课程数冗余到老师表里，并在课程表更新时同时更新老师表里的该字段