首先在设计关系数据库时，按照不同的规范要求，设计合理的关系数据库。 这些不同的规范要求被称为不同的范式，每个范式提出以下规范，越高的范式数据库冗余越小。
现在，关系数据库中存储有第一模式(1NF )、第二模式(2NF )、第三模式(3NF )、总线代码模式(BCNF )、第四模式(4NF )、第五模式(55 ) 满足最低要求的范式是第一范式(1NF )。 在第一范式的基础上进一步满足更多规范要求的称为第二范式(2NF )，其馀范式类推如下。 一般来说，数据库只需要满足第三模式(3NF )。
以上两次摘自女儿。 (大学老师也实际说过，但是记不住，所以写下来吧。 )本篇介绍前三种范式。
首先，了解数据库的实体属性和关系。 实体：表； 属性：表中的数据(字段)； 关系：表与表的关系
第一范式：如果关系模型r的所有属性不能分解为更基本的数据单位，则称r满足第一范式，简称1NF。 满足第一范式是关系模式规范化的最低要求，否则很多基本操作无法通过这种关系模式实现。
第二范式：如果关系模型r满足第一范式，且r的所有非主属性完全依赖于r的所有主要候选属性，则r满足第二范式，并简单表示为2NF。
第三范式： r是满足第一范式条件的关系模型，x是r的任意属性集，如果x依赖于r的任意候选关键字，则r满足第三范式，简单记为3NF。
第一范式
1、各列属性为不可分离属性值，确保各列的原子性
2、合并两列属性相近或相似或相同，但属性相同的列，以避免生成冗馀数据。
需求知道该省该市并按其分类，显然首表不容易满足需求，也不符合第一范式。
显然最初的表结构不仅不能满足足够数量物品的要求，而且在物品少的时候会产生冗馀。 不符合第一范式。
第二范式
如果满足1NF，则表中的所有列都必须依赖于主键。 没有与主键无关的列。 这意味着一个表只能写一件事。
例如，由于订单表只包含有关订单的信息，因此所有字段都必须在与订单id相关的产品表中包含有关产品的信息。 因此，所有字段都必须与产品id相关。 因此，订单和产品信息不能同时显示在一个表中；
每行的数据只能与其中一列相关联。 这意味着一行数据只能做一件事。 只要数据列中有数据重复，就必须分割表。
一个人同时预约多个房间的话，就会出现订单号码的多个数据。 如果联系人像这样重复的话，数据就会变得冗长。 我们应该分解他。
这样一个数据就能实现一件事，不掺杂复杂的关系逻辑。 另外，表数据的更新维护也变得容易。
第三范式
数据没有事务关系。 这意味着任何属性都直接与主键相关，而不是间接关系。 a--b--c属性之间包含这样的关系，不符合第三模式。
例如，Student表(学校号码、姓名、年龄、性别、所在大学、大学地址、大学电话) )。
这种表结构与上述的关系。 学校编号----所在大学----大学地址、大学电话)
这种表的结构应该分解如下。
(学校编号、姓名、年龄、性别、所在大学)---(所在大学、大学地址、大学电话) )。
最后附上：
虽然也很容易忘记E-R图，但是我会记录下来：
ER图有以下四个成分。
方框-表示实体，并在框中输入实体名称。
菱形框：表示联系，在框中填写联系名称。
椭圆框：表示实体或联系人的属性，并在框中输入属性名称。 对于主属性名称，请在名称下加下划线。
连接：实体和属性之间； 实体和联系之间； 用直线连接联系和属性之间，在直线上标记联系的类型。 对于一对一联系，在两个物理连接方向上分别写1； 关于一对多的联系，在一方写1，多方写n的多对多的关系中，在两个物理连接方向上分别写n，m。 ) )
三大范式只是一般设计数据库的基本理念，可以构建冗余度小、结构合理的数据库。 有特殊情况，当然要特殊对待。 数据库设计中最重要的是看需求和性能，需求性能表的结构。 所以不能追求范式建立数据库。