Access开发中建表的基本原理和规范（上）

Access是一个基于数据库的开发设计工具，用它甚至可以开发出一整套的基于数据库的应用管理软件，所以使用时就必须遵循一定的开发设计流程，不像和它同属MicrosoftOffice办公系统软件的其它组件如Word、Excel等，可随时随意的打开新文件及输入数据，而必须进行一定的设计才能使用。

而表是Access中其它对象的根源，所有其它对象的设计开发都围绕表中的数据而进行，所以表的设计至关重要。

当开发进行到一定程度的时候，如果要对表的设计做出改动，和其相关的所有内容都需要同样进行修改，耗时耗力，甚至需要完全重新设计，由此可见初期正确建表的重要性。

本文针对刚接触Access的初学者，讲述了一些建表的基本原理和规范，让大家少走一些弯路，尽量避免由于初期建表不正确造成的效率不高、后续开发困难，甚至因此造成需要全部推倒重来。

在实际应用中，尤其是刚接触Access的朋友，如果之前没有数据库的相关理论知识的话，就会感到很茫然，不知如何下手。最可能的情况就是凭感觉随意建表，结果造成完全达不到想要的结果或者效率不高，乃至后继的开发无以为继，甚至需要全部推倒重来。

建议大家找一些关系数据库理论方面的书看看，因为Access就是一个关系数据库。在这里由于篇幅所限，只能简单的说一下在Access中建表的一些基本原理规范及要点。

先声明一下两个名词的含义：表是列和行组成的，在Access中列被称为字段，行被称为记录（大部分关系数据库也都是这么叫的）。请记住这两个名词，以后会频繁的用到

构造数据库必须遵循一定的原理规则，而Access是一个关系数据库系统，所以使用Access就要遵循关系数据库的原理规则：范式（NormalForm）。

目前按照国际标准，一共有6种范式，除第一范式外，其它范式都是在满足前一范式的基础上而定义的，也就是说，符合第三范式的必定符合第二范式，符合第二范式的必定符合第一范式，以此类推。不过一般来说我们只要规范化到第三范式就足够了，其它范式不常用到，这里就不做解释和讨论了。

 

第一范式（1NF）：数据库表中的字段都是单一属性，不可再分。

第一范式是最低的规范化要求，第一范式要求数据表不能存在重复的记录，即存在一个无重复主索引（主键）。第一范式的第二个要求是每个字段都不可再分，即已经分到最小，关系数据库的定义就决定了数据库满足这一条。主键不一定是某一个字段，也可以是多个字段的组合，不过一般都是设为一个字段，这样在使用时相对简单。主键要求它基于的字段不允许重复、不允许有空值。

满足第一范式的关系模式有许多不必要的重复值，并且在添加、修改、删除记录时可能会导致异常。为了避免数据冗余和消除异常，就引出了第二范式（2NF）。 

 

第二范式（2NF）：在第一范式的基础上，其它所有的字段都完全地依赖于主键字段。

为了说明问题现举一个例子来说明：有一个库房存储的库有四个字段（零件号码，仓库号码，零件数量，仓库地址），这个库符合第一范式，其中“零件号”和“仓库号”构成主关键字。但是因为“仓库地址”只完全依赖于“仓库号码”，即只依赖于主关键字的一部分，所以它不符合第二范式。

这样首先存在数据冗余，因为仓库数量可能不多。其次，存在如果更改仓库地址时，如果漏改了某一记录，存在数据不一致性。再次，如果某个仓库的零件出完了，那么这个仓库地址就丢失了，即这种关系不允许存在某个仓库中不放零件的情况。

我们可以用投影分解的方法消除部分依赖的情况，而使关系达到第二范式的标准。方法是从关系中分解出新的表，是每个表中所有的非关键字都完全依赖于各自的主关键字。我们可以分解成两个表（零件号码，仓库号码，零件数量）和（仓库号码，仓库地址），这样就完全符合第二范式了。

 

第三范式（3NF）：如果一个关系属于第二范式，且其它字段不传递依赖于主键，则它满足第三范式。

从第二范式中消除传递依赖，就是第三范式。比如有一个表（姓名，工资等级，工资额），其中姓名是关键字， 此关系符合第二范式，但是因为工资等级决定工资额，这就叫传递依赖，它不符合第三范式，我们同样可以使用投影分解的办法分解成两个表：（姓名，工资等级），（工资等级，工资额）。 

以上就是关系数据库的最基本的三范式规则，只有从理论上理解了，才会更容易在实际应用中理出头绪。后面我们会再用一篇文章说一些要点和技巧。