前言
之前的博客中我们讲解的是关于数据库的增删改查与约束的基本操作，
是在已经创建数据库，表之上的操作。
在实际的项目开发过程中，表的设计是需要我们根据需求来分析设计的，
表设计的过程：
OOA面向对象分析–>OOD面向对象设计–>OOP面向对象编程。
首先：我们是从需求中获得类（与java中的对象类的概念相同），
然后类对应数据库中的实体，实体对应数据库中一张一张的表
，而类中的每一个属性对应表中的每一个字段（列）。
其次获取类与类之间的关系，类与类之间的关系（或者说实体与实体之间的关系）有
一对一，一对多，多对多三种关系。
最后进行SQL语句进行创建表。
三大范式：
在创建关系型数据库时，遵循着一些规则称为三大范式。
第一范式：即表中的每一列属性不可以再划分（即实体不可以作为属性）。
例：设计一个学生表
如果这样设计即是错误的，因为“学校”是一个实体，它还可以再划分：
如果“学校”换成下面三个属性，则该表的创建满足第一范式。
第二范式：
第二范式即在满足第一范式的基础上，避免非关键字段（）对任一候选键（主键，外键，唯一键）产生部分函数依赖（下面给出解释）。第二范式的本质上依然是一个表（非关联表）只能表示一个实体，一个实体只能对应一个类。
举例说明：
反例：
在此表中，学分不依赖于学号，而依赖于课程名字段，姓名，年龄不依赖于课程名，而是依赖于学号字段，这样在两个及以上的关键字段决定一条记录的表中，存在部分非关键字段对其中一个关键字段依赖的情况称为部分函数依赖。
正例：
在上图中每张表的非主键字段都强依赖于主键字段，满足第二范式。
不满足第二范式的坏处：
- 在查询数据时，会产生大量的数据冗余。
例如：只想要查询学生的学号，姓名信息，却会展示出课程名，学分等无用的信息。 - 更新异常，比如要更新课程所对应的学分，这种实体混合在一张表中的模式会导致不能够整体地更新某一个实体记录中的数据，下次插入数据时，课程对应的学分还是原来的数据，会导致数据不一致的情况出现。
- 插入异常：
对于课程实体我们没有单独地设置一张表，那么假如我们设置了一门新的课程，则除非插入一条学生信息，否则不能查询到此课程的信息如学分，但是插入学生信息时，必须插入此课程的考试成绩，成绩为空又没有意义。 - 删除异常：
如将全部的毕业学生信息都删除后，则课程的信息也全部会被删除，无法查询到课程的信息了。
第三范式：
在满足了第二范式的基础上，不存在非关键字段对任一候选键的传递依赖。本质上依然是一个表中只能实现一个类（实体）。
反例：
正例：
还是创建两个表，然后在学生表中用外键联系学院表。
几种实体间的关系：
在表的设计中关于实体之间有一对一，一对多，多对多之间的关系。
一对一关系：
举例：
在此过程中，账号与用户是两个实体，一个账号对应一个用户，一个用户对应一个账号
我们在设计表时可以有两种方式：
第一种将两个实体的信息放入一张表中设计：
第二种：设计成两张表，一张表一个实体。
然后将这两张表做关联。
有两种关联方式：
一对多关系：
举例：
学生与班级的关系，一个学生只能在一个班级之中，而一个班级可以有多个学生。
设计思想：不能将学生与班级两个实体设计在一张表中，不满足三大范式
而列的数据类型不存在集合的情况：所以将关联关系的实现在学生表中。
站在班级的角度，与学生是一对多的关系，站在学生的角度，与班级是多对一的关系。
多对多关系：
举例：学生与课程的关系，一个学生可以选择多门课程，一门课程可以被多个学生选择。
在这种情况下，应该将学生与课程的关联关系实现单独设计一张表。
这样设计，在删除关联表中的数据时，不会影响实体本身的信息。
