关系型数据库中的一条记录中有若干个属性，若其中某一个属性组(注意是组)能唯一标识一条记录，该属性组就可以成为一个主键
主键和外键是把多个表组织为一个有效的关系数据库的粘合剂。主键和外键的设计对物理数据库的性能和可用性都有着决定性的影响。
必须将数据库模式从理论上的逻辑设计转换为实际的物理设计。而主键和外键的结构是这个设计过程的症结所在。一旦将所设计的数据库用于了生产环境，就很难对这些键进行修改，所以在开发阶段就设计好主键和外键就是非常必要和值得的。
主键：
关系数据库依赖于主键---它是数据库物理模式的基石。主键在物理层面上只有两个用途：
惟一地标识一行。
作为一个可以被外键有效引用的对象。
基于以上这两个用途，下面给出了我在设计物理层面的主键时所遵循的一些原则：
主键应当是对用户没有意义的。如果用户看到了一个表示多对多关系的连接表中的数据，并抱怨它没有什么用处，那就证明它的主键设计地很好。
主键应该是单列的，以便提高连接和筛选操作的效率。
注：使用复合键的人通常有两个理由为自己开脱，而这两个理由都是错误的。其一是主键应当具有实际意义，然而，让主键具有意义只不过是给人为地破坏数据库提供了方便。其二是利用这种方法可以在描述多对多关系的连接表中使用两个外部键来作为主键，我也反对这种做法，理由是：复合主键常常导致不良的外键，即当连接表成为另一个从表的主表，而依据上面的第二种方法成为这个表主键的一部分，然，这个表又有可能再成为其它从表的主表，其主键又有可能成了其它从表主键的一部分，如此传递下去，越靠后的从表，其主键将会包含越多的列了。
永远也不要更新主键。实际上，因为主键除了惟一地标识一行之外，再没有其他的用途了，所以也就没有理由去对它更新。如果主键需要更新，则说明主键应对用户无意义的原则被违反了。
第一范式（1NF）：当关系模式R的所有属性都不能分解更基本的数据元素时，即R的所有属性都处于原子特征时，就叫做第一范式（1NF）。
例如：我们在关于员工的关系模式中，如果工资这项属性可以再分成基本工资和奖金的话，那么它就不属性第一范式，如果不能再分的话就属性第一范式，当然，需要员工这个关系模式里所有属性都满足这个条件。
第二范式（2NF）：如果关系模式R在满足第一范式的基础下，并且所有R的所有非主属性都完全依赖于R（关于依赖自己查询）的每一个候选关键字属性，则叫做R满足第二范式。
例如：在一个图书管理系统中，存在如下关系模式：R=R（读者编号，图书编号，工作单位，借阅日期，归还日期），在这个关系模式中，有两个候选主属性，（读者编号，图书编号），而工作单位这个属性只需要读者编号这个属性就能确定，所以在这个它并不是完全的依赖于每一个候选关键属性，所以它并不是第二范式。
第三范式（3NF）：假设R是一个满足1NF的关系模式，X是R的任意属性组，如果X非传递依赖于R的任意一个候选关键属性，称R满足第三范式。
什么叫传递依赖，比如，人->（男人，女人），男人->(小孩，大人，老人），这里因为小孩是男人，所以推出小孩也是人，（这个例子不是很恰当）。那怎么来理解第三范式，我们同样举个例子来理解下
例如：假如KFC这个公司，它在北京有100家分店，那么我们记录它的时候，就会这样记录R=R（公司注册号，法人代表，注册城市，所在省），如果按照第一范式，我们需要些100次注册城市，这就导致了数据的高度冗余，所以我们这里想要用第三范式，公司注册号->注册城市，注册城市->所在省，这里就导致了R的传递依赖，所以我们这里并不能用第三范式。
再接下来就是Boyce-Codd范式和第四、第五范式了，这三个范式都是这前三个范式的基础上增加更合理的规范性而来的，所以符合第三范式以上的范式的关系模式才能称之为标准的关系模式。
Boyce-Codd又简称BCNF，它比第三范式具有更强的规范性，或者又叫做约束性，符合BCNF的关系模式一定符合第三范式，但是反过来却不一定成立。很多情况下，第三范式就是BCNF，但是二者是不等价的。
第四范式（4NF）：禁止主属性和非主属性一对多的关系不受约束，这个就有点涉及到了UML，不多讲。
第五范式（5NF）：将表尽可能的分割成小的表，使之不存在冗余。
（1）T2中的数据A不需要定义PRIMARY KEY；
（2）第五范式分解很容易带出很多错误的数据，如果你不能通过联接来重新构建分解前的表的话，最好就不要分解了。
第一个问题：A在T2中不必是主键！
第二个问题：需要好好看看第五范式的定义，反正是作业，也不是实战！列数多少没关系的。
那一定要定义外键的。不然怎么和A表连接呢？
内容全部来源于网络收集，如有侵权，请联系网站删除：QQ：24596024