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种类型:错误修正、规范改动和问题解答。错误修正必须尽可能快地进行。规范改动的意义应该清楚地解释给用户,在进行所要求的改动时要涉及到时间和费用这两个方面。在对问题进行解答时,应该多召集一些用户,告诉他们如何优化窗体和报表,使他们能更灵活地使用应用程序并对它进行开发。当然,应用程序的最终目标就是给尽可能多的用户带来便利。