前言：
表从何而来？
在进行编程时有这么一个过程:OOA面向对象分析-->OOD面向对象分析-->OOP面向对象编程，
而表的设计是针对OOA，
具体是怎么展开的呢？
1.从需求中获取类，类对应数据库中的实体，实体在数据库中表现为一张张表，类中的属性对应表中的字段。（也就是说类对应数据库中的表）
2.确定类和类之间的关系
3.使用sql来创建具体的表
设计表时要遵循一些规则我们称之为3大范式
一、认识范式
范式有三大规则：
（1）1NF：确保每列具有原子性（不可再分）
（2）2NF：在满足1NF的前提下，非主键列完全依赖于主键
（3）3NF：在满足2NF的前提下，消除传递依赖
（相应规则后续有讲解）
数据库表之间也有三大关系：一对一，一对多，多对多，
总的来说根据三大范式来创建表，根据三大关系来关联表（确认关系是建表的前提）
二、三大范式（1NF，2NF，3NF）
1.第一范式：确保每列具有原子性（不可再分）
怎么理解呢？
列具有原子性，说明列不可以再分了，如学校是可分的（分为，学校名，地址，学校号码）他就不符合第一范式，且列中不可以有字符串，多个数据。
为什么呢？
CREATE TABLE `user_hobby` ( `id` bigint NOT NULL PRIMARY KEY COMMENT 'ID', `name` varchar(50) COMMENT '姓名', `hobby` varchar(100) COMMENT '爱好（多个值）' ); -- 插入数据 INSERT INTO `user_hobby` VALUES (1, '张三', '篮球,游泳,看书'), (2, '李四', '跑步,画画');如果不规范建表，
首先如果你在列中使用了字符串，爱好有多个值，在查询的时候我们还需要拆分字符串，这样会导致效率低，
其次，在更新数据时想把 “游泳” 改成 “羽毛球”，必须修改整个字段值，容易误改其他内容（比如把 “篮球，游泳” 改成 “篮球，羽毛球”，少打一个逗号就错了）导致更新异常，
统计麻烦，当我想统计有多少篮球时无法直接聚合。
2.第二范式
核心理解：在满足 1NF 的基础上，表中的所有非主键字段必须完全依赖于整个主键（而不是依赖主键的一部分）
可以说当不存在复合主键时默认满足第二范式，当存在复合主键时也不一定就是不满足第二范式，
举例说明：
以下这张表就不符合第二范式，首先它存在一个复合主键（order_id，product_id），如果说其他字段都完全依赖于该复合主键，那么它满足第二范式，但是product_name依赖于product_id，order_time依赖于order_id，所以它不满足第二范式，
那么为什么要满足第二范式呢？
1.数据冗余，数据里面有很多个小米手机，以及相同的下单时间
2.更新异常，如果要调整手机名称，如小米手机，那么就要更改所有的小米手机，效率低，且可以出现更新不成功的风险。
3.、删除异常，如：我要删除某些订单，那么同时会删除商品名，这样会导致一段时间内没有商品。
3.第三范式
官方说明：在满足 2NF 的基础上，表中的非主键字段不能依赖于其他非主键字段（即消除 “传递依赖”）。、
我们以这个表为例：
这个表只有一个主键user_id，符合1NF，2NF，但是其中，province是依赖于city的而city和province是非主键字段，这样 就会导致数据冗余，以及复现上面所谈到的问题。
这里需要分表，实际生产中我们也都是分表，然后建立关联来建这种表的，
如：
4.三种关联方式
一对一，一对多，多对多
三种关联方式都是为了三种范式而服务的，在设立表之初我们就要对表中的字段进行分类，如课程表和学生表，一门课可以被多个人选择，一个人可以选择多门课，所以这是多对多的关联方式，在建立表时按照这种形式进行分表，下面我们来举例说明：
用户表（user）和用户详情表（user_detail）：一个用户只有一个用户信息，一对一
如果我们把所有的字段都放在一起去建一个表那么他就不符合1NF更不要提其他两个范式了，所以使用关联来解决这个问题。
