1.8 Access应用程序的开发过程
Access 2007开发指南(修订版)
许多开发人员认为，Access是一个快速的应用程序开发环境，因此在创建应用程序时，没有必要进行系统分析和系统设计。对于这一点，笔者并不赞同。如本章前面所述，Access应用程序看起来比较容易创建，但如果规划不当，也会带来灾难。
1.8.1 任务分析
Access应用程序开发过程的第一步就是进行任务分析，也就是考虑在用户工作的时候会发生的每一个过程，这是一件麻烦而必要的工作。当笔者第一次受聘于一家大型公司在大型机上作编程工作的时候，他们就要求对任务列表进行仔细的任务分析。那时，必须找出系统中的各个用户为了完成日常工作要做些什么，还要描述各个过程，并决定一个任务到另一个任务之间的流向，同时又要将各个用户的各个任务与其他任务，以及系统内其他用户的每一个任务联系起来，并且要将任务与对象挂钩。虽然如今快速的应用程序开发环境和创建技术日益流行，而且在开发过程中这个步骤好像有点过时了，但是，要是这一步完成得不好，或者从某种意义上说根本就没有做，那么将有可能对应用程序进行大规模地返工。
1.8.2 数据分析和设计
在分析和描述了系统中的所有任务之后，就进入了应用程序的数据分析和设计阶段。在这个阶段，用户必须找出要完成各个任务需要的相应信息。这些数据元素必须指定给各个对象，每个对象在数据库中将成为一个唯一的表。例如，一个对象可以就是一个客户。这样，与客户相关联的各个数据元素（名称、地址、信用限额及其他有关系的信息）将成为客户表中的各个字段。
用户应该为每个数据元素指定以下内容：
合适的数据类型；
所要求的大小；
有效性规则。
还要决定各个数据元素是否可以更新，以及它们是通过输入得来还是通过计算得来。然后要确定自己表的结构是否规范化。
规范化的应用
按照一系列规则对表的设计进行测试的过程就叫做规范化，这一系列规则用于确保应用程序进行尽可能有效的操作。这些规则是基于集合理论的，它们最先由Dr.E.F.Codd提出。虽然学习规范化也许要花上几年的时间，但是它的基本思想是一目了然的，那就是以尽可能少的数据操作和编码来实现应用程序的有效运行。第3章会详细介绍规范化和数据库设计。本章只介绍其中的6条基本规范化规则。
（1）字段原子化。也就是数据的各个部分应该尽量分开。比如，不应该泛泛地创建一个叫做“名字”的字段，而应该为其创建两个字段，即一个“名”和一个“姓”。这样处理使得数据的操作变得非常简单。例如，要是想只以名（而不管姓是什么）来排序或搜索，那么做了以上处理之后，就可以节省很多开销。
（2）每个记录应该有一个唯一的标识符，以便能够安全地识别各条记录。例如，如果要改变客户信息，就必须确保所改变的信息与适当的客户发生了正确的联系。这个唯一的标识符叫做主键。
（3）主键是一个字段或几个字段，它用于唯一地标识相应的记录。有时候需要指定原有的字段作为主键。例如，在员工表中，社会保险号码应该用来为系统标识员工。但是在有些时候，又需要创建一个主键。例如，要是两个员工具有相同的名字，那么员工名就不能为系统独立地标识员工。这时就有必要创建一个字段，使它成为员工的一个唯一标识符，比如说可以创建一个客户ID。
（4）主键应该比较短小、稳定而简单。短小是指它的尺寸应该比较小（不应该是50个字符这么大的字段）。长整型数据对于主键是极好的。稳定意味着主键的字段值应该很少变动或者说不变动。例如，客户ID较少改动，而一个公司的名字变化的概率则比较大。简单说就是要让用户容易操作。
（5）表中的每个字段应该提供主键所标识记录的其他信息。例如，客户表中的各个字段应该描述具有特定客户ID的客户。
（6）表中的信息不应该在多个位置出现。例如，一个特定客户的名字就不应该出现在多个记录之中。
例如，图1.15所给出的数据表是一个没有规范化的表的例子。请注意，CustInfo字段针对各个订单进行了重复，因此，如果客户地址发生了变化，指定给相应客户的每个订单其地址也会发生改变。换句话说，CustInfo字段没有实现原子化。如果用户想以城市名排序，则行不通，因为城市名处在CustInfo字段的中间。如果订货清单的项目名称发生了改变，则必须对有该订货清单项目的每条记录进行修改。在这个例子中，问题就出现在订购的项目上。在这个设计过程中，可能需要为每个客户订单项创建4个字段，即姓名、供应商、数量和价格。这样设计以后，要想为用户创建他们所需要的销售报表和其他报表是相当困难的。
图1.16所示的是经过规范化的同样的数据。请注意，这时候它们分成了好几个不同的表，即tblCustomers、tblOrders、tblOrderDetails和tblSuppliers。tblCustomers表只包含与特定用户相对应的数据。
每条记录均由所设计的CustomerID字段单独标识，而这个字段又用于将表tblCustomers和表tblOrder联系起来。tblOrders表包含的信息只针对于整个订单，而不针对于客户订购的各个项目。这个表包含了那些具有订单和订单日期的客户的CustomerID，而且它通过OrderID与表tblOrderDetails发生联系。tblOrderDetails表持有针对特定OrderID所订项目的信息。
在这里，可订购项目的数量没有限制。想订购多少项目，就可以订购多少项目，因为这时只须在tblOrderDetails表中多添加一些记录。最后，供应商信息也放在一个唯一的表（tblSuppliers）中，这样，供应商的信息发生改变时，只有一处会变动。
1.8.3 原型开发
与以前使用大型机的时候相比较，虽然应用程序开发的任务分析阶段和数据分析阶段并没有多大改变，但是，原型开发阶段发生了很大的变化。在对大型机进行操作时，用的是基于DOS的语言，那时对各个屏幕和报表开发详细的规范是很重要的。这种情况下，稍作改动，比如说在屏幕上移动一个字段，则意味着一场大的改变，这时往往又得工作几个小时。在用户对屏幕和报表的规范发表看法后，开发人员又得花上几天时间埋头苦干，才能开发出屏幕和报表的规范。而且，当开发人员工作了几个月并把产品交给用户时，用户也许并不完全满意。而这往往意味着开发人员必须回到绘制板前，再花不少时间进行改动，以满足用户对应用程序的要求。
不过，现在这个过程完全不同了。一旦任务描述和数据分析完成之后，开发人员便可以实现对表的设计，并在它们之间建立关系。窗口和报表的原型开发过程便可以随即开始。这时，开发人员不必在与用户交流之前先躲起来开发几周甚至几个月，使用Access向导，只须花上几天时间，便可以快速地开发出窗体的原型。
1.8.4 测试
在没有进行测试以前，用户还不能断定应用程序能做些什么。如果用户的应用程序要在Windows 2000、Windows 2003、Windows XP和Windows Vista的机器上运行，那么应该在所有这些环境下都进行一次测试。测试应用程序应该扩展到最低分辨率的显示器上，因为应用程序可能会在开发人员自己的机器上运行得很好，而在用户的低配置机器上会运行得很慢。
在测试时，既要对应用程序进行部分测试，又要进行集成测试。测试应用程序时，应尽量多组织一些人，并且要确保这些人中有计算机方面的行家，也有对计算机一窍不通的人。这些不同类型的用户可以发现完全不同的问题。千万不要自己独自一人进行测试，因为自己往往找不出自己所开发程序的错误。
1.8.5 程序的实现
到最后，应用程序便可以作为产品发行了，但是，应该先将应用程序发行给少量的用户，并让他们知道这是进行测试。要让他们意识到他们是系统的第一批用户，这自然是一件引以为荣的事，但也要告诉他们问题可能随时发生，而且他们也有责任将遇到的问题反馈回来。如果一开始就大范围地发行应用程序，而结果证明操作不正常，那么将完全失去用户对您的信任。这就是要慢慢发行应用程序的原因。
1.8.6 维护
由于Access是一个快速的应用程序开发环境，因此，它所开发的应用程序要求维护的时间比基于DOS开发的应用程序要求维护的时间要长。用户的要求一般是很高的，开发人员的水平越高，他们的要求就越高。不过，对咨询人员来说，这倒是一件好事。当然，也应该具体情况具体分析，因为应用程序的作用范围在不断改变，不能将自己局限于一种情形，从而走入死胡同。
维护包括3种类型：错误修正、规范改动和问题解答。错误修正必须尽可能快地进行。规范改动的意义应该清楚地解释给用户，在进行所要求的改动时要涉及到时间和费用这两个方面。在对问题进行解答时，应该多召集一些用户，告诉他们如何优化窗体和报表，使他们能更灵活地使用应用程序并对它进行开发。当然，应用程序的最终目标就是给尽可能多的用户带来便利。