数据库中建立的表是对现实世界的数据构建的“数据模型”；建立现实世界到机器世界的一个桥梁这样的作用，在一定的理论基础上建立表能够降低“数据的冗余”，查询请求更加的高效；
基础理论
- 降低表冗余的“三范式”
- 清晰描述“实例”与“关系”的ER图
在讲解范式和ER图之前，需要搞清楚几个名词；首先构建一个订单-用户表；
若规定：同一产品对于不同订单的单价不同。则有(订单号，产品号)–>产品单价 属于完全函数依赖，一对一关系，改变订单号和产品号中的任意一个都会造成产品单价的改变
若规定：同一产品对于不同订单的单价相同。则有产品号–>产品单价，(订单号，产品号)–>产品单价 属于部分函数依赖。只依赖其中的一个属性。多对一关系，当产品号相同，订单号不同会产生多个相同的产品单价。
若规定，一个订单只可以订购一个产品，一种产品只有一种价格。则有订单号–>产品号，产品号–>产品单价。显然订单号–>产品单价属于传递函数依赖
三范式
- 一范式：列不可分
一范式是指数据库中的每一列都是不可分割的基本数据项，同一列中不能有多个多个重复的值。这里显然将“地址”属性分为“省份”和“城市”会更好
改进后的表设计，在对用户居住城市进行分类的时候就非常的方便，也提高了数据库的性能。
原表：
- 二范式：在满足一范式的基础上，消除部分函数依赖成为完全函数依赖，多对一关系变为一对一；
首先对于原表而言，存在(OrderID,ProductID)->(CustomerID,CompanyID)部分函数依赖；直观理解就是后者只依赖前者的部分属性；这里而言只有OrderID影响CustomerID和CompanyID。
如果一个公司下了50个订单，表中就会出现50次客户ID和公司名字，造成数据冗余；
表拆分：
O-C表
O-D表
- 三范式：当二范式消除了非主属性对健的传递函数依赖，就成为三范式；
这里我们主要关注O-C表，存在OrderID->CustomerID，CustomerID->CompanyName这样的传递函数依赖，需要对O-C表进行二次拆分；
总结：三范式是为了消除数据的冗余，提高查询效率；
E-R图 entry-relation
ER图为实体联系模型；清晰表述实体之间的多种关系：
- 1.一对一关系(1:1)：例如一个班级只有一个正班长，而一个正班长也只在一个班中任职；
- 2.一对多关系(1:N)：例如一个班级有很多学生，而一个学生只属于一个班级；
- 2.多对多关系(M:N)：例如一门课程有很多学生选修，一个学生可以同时选修多门课程；