如果一个关系模式R的所有属性都是不可分的基本数据项，则R∈1NF。简单的说，就是每一个列（属性）只有一个，没有重复。 第一范式（1NF）是指数据库表的每一列都是不可分割的基本数据项，同一列中不能有多个值，即实体中的某个属性不能有多个值或者不能有重复的属性。

• 指导原则
  第一范式包括下列指导原则：
  数据组的每个属性只能包含一个值；
  关系中的每个数组必须包含相同数量的值；
  关系中的每个数组一定不能相同。
  第一范式是对关系模式的最起码的要求。不满足第一范式的数据库模式不能称为关系数据库。
  但是满足第一范式的关系模式并不一定是一个好的关系模式。
  例：如职工号，姓名，电话号码组成一个表（一个人可能有一个办公室电话 和一个家里电话号码） 规范成为1NF有三种方法：
  一是重复存储职工号和姓名。这样，关键字只能是电话号码。
  二是职工号为关键字，电话号码分为单位电话和住宅电话两个属性
  三是职工号为关键字，但强制每条记录只能有一个电话号码。
  以上三个方法，第一种方法最不可取，按实际情况选取后两种情况。
• 第一范式的关系

  规定关系

  第一范式规定关系的每一个分量必须是一个不可分的数据项。
  非第一范式的例子如表5-5，可以转换为第一范式如表5-6。
  表5-5

  导师	专业	研究生
  第一个研究生　第二个研究生

  表5-6

  导师

  专业

  第一个研究生　第二个研究生

  几乎所有的商用关系DBMS都要求关系为第一范式，现在流行的关系数据库语言，如SQL，也都只支持第一范式。
  如果关系仅仅满足第一范式的条件是不够的，可能会存在更新异常。为了消除这些异常，需要进行关系的规范化。

  关系模式实例

  下面是满足第一范式的(不好的)关系模式的例子。例如：设有一关系模式R(S#，C#，G，TN，D)，其中(S#)为学号，C#为课程号，G为成绩，TN为任课教师姓名，D为教师所在系名，这些数据具有下列语义：
  (1) 学号是一个学生的标识，课程号是一门课程的标识。
  (2) 一位学生所修的每门课程都有一个成绩。
  (3) 每门课程只有一位任课教师，但一位教师可以教多门课。
  (4) 教师中没有重名，每位教师只属于一个系。
  下面是一个具体关系实例的数据，如表5-7：
  表5-7

  学号 S#	课程号 C#	成绩 G	教师 TN	系名 D
  s1	c1	g1	t1	d1
  s1	c2	g2	t2	d2
  s2	c1	g3	t1	d1
  s2	c2	g4	t2	d2
  s3	c2	g5	t2	d2
  s3	c3	g6	t2	d2

  虽然上述的关系模式只有四个属性，但它是一个不好的关系模式，因为该模式在使用过程中有以下几个问题：
  (1) 数据冗余。例如，教师所在系名对选该教师所开课的所有学生都重复输入一次。
  (2) 插入异常。由于关系的主键{S#, C#} 不能为空值，如果一个教师不教课，则这位教师的姓名及所属的系名就不能插入表中。
  (3) 删除异常。如果所有学生都退选某一门课，则有关该门课的其它数据(任课教师名及所在系名)也将被删除。
  (4) 修改异常。如果改变一门课的任课教师，则需要修改表中选修该门课程的多行记录，如果部分修改，部分不修改，则会导致数据的不一致。
  上述关系模式之所以是一个不好的关系模式，是因为模式中存在部分函数依赖和传递函数依赖。消除这些部分函数依赖和传递函数依赖，就可以得到一个比较好的关系模式。
  根据上述示例说明的语义，找出有下面的函数依赖集合F：
  F = { {S#, C#}→ G，C#→TN，TN → D}
  图 5－2
  针对函数依赖集合，运用关系数据库设计理论，可以对上述关系进行分解，得到3个关系模式如下：
  SCG(S#, C#, G)
  CTN(C#, TN)
  TND(TN, D)
  上述3个关系可以消除数据冗余，插入异常，删除异常和修改异常等现象。是一个比较好的关系模式。把原来一个关系表的数据分解为三个关系表存放。
  具体的关系实例的数据如表5-8：
  表5-8

  S#	C#	G
  s1 s1 s2 s2 s3 s3	c1 c2 c1 c2 c2 c3	g1 g2 g3 g4 g5 g6

  对于上述示例，是满足第一范式的关系模式，但它不是一个好的关系模式，存在数据冗余和操作异常现象。通过分析模式属性间的函数依赖关系，把一个模式分解为三个关系模式后，消除了数据冗余和操作异常。对于任一给定的模式，如何判断是一个好的还是不好的关系模式呢？又如何把一个不好的关系模式分解转换为好的关系模式呢？这就是在下面要讨论的问题，对关系模式中X→Y的函数依赖关系，给出不同程度的限制，得到满足不同范式要求的模式。