1.4.1 第1 步:总体设计从概念到实现
所有软件开发人员都面临着很多类似的问题，第一个问题就是确定如何才能满足最终用户的需求。在关注细节问题之前，了解一下总体需求尤为重要。

图1-2 中所示的5 步骤设计方法可以帮助您创建所需的系统，而且价格可以承受(按时间或美元计算)。例如， Access Auto Auctions 数据库允许客户向顾客出售商品(车辆和部件)。Access Auto Auctions 数据库实现了以下任务的自动化：
输入和维护客户和销售商的合同信息(姓名、地址和财务历史信息) ;
输入和维护销售信息(销售数据、支付方法、总额，包括税金、购买者ID 和其他方面) ;
输入和维护销售项目信息(实际购买的商品详细信息) ;
查看所有表中的信息(销售、联系人、购买销售项目和支付信息) ;
提出有关数据库中信息的所有问题:
生成当前联系人目录:
生成发货单的月报表:
生成客户销售历史:
生成邮件标签和邮件合并报表。

Access Auto Auctions 数据库自动化实现的9 项任务己经通过客户表现了出来。在设计过程开始时，可能还需要考虑其他任务。

构建系统所需要的大多数信息都来源于最终用户。这就是说需要和他们进行接触以了解现有的处理工作。要实现这一目标，需要对现有系统进行全面的需求分析以及如何实现该系统的自动化。

一个实现方法就是准备一系列的问题，以深入了解客户业务以及客户如何使用数据。例如，在考虑对汽车拍卖业务实现自动化时，可以考虑提出如下问题:
目前正在使用哪些报表和窗体?
目前销售、客户、联系人和其他记录如何存储?
如何处理票据?

提出这些以及其他问题时，客户可能会想起业务的其他方面，对此也应该有所了解。

对现有工作流程的预排对于找到业务"感觉"来说也是十分必要的。极有可能返回多次来观察现有流程以及员工如何工作。

准备完成余下的步骤时，一定要保持客户的参与，让客户知道所做的工作并且要求其提供所需要的输入数据，同时确保按客户需求进行工作。

1.4.2 第2 步:报表设计
尽管从报表开始可能看起来有些奇怪，但在很多情况下，相对于应用程序的其他方面而言，用户更关垃于数据库的打印输出。报表通常包括应用程序管理的所有数据。由于内容很全面，所以报表经常是收集关于重要数据库需求信息的最好方法。使用Access Auto Auctions 数据库时，可打印报表包含数据库中几乎所有数据的详细和汇总版本，根据需求定义完Access Auto Auctions 的总体系统后，就可以开始报表设计了。

看到该部分中需要创建的报表后，可能会有些不解，"哪个先出现一一鸡还是蛋? "是报表布局先出现，还是需要先确定构成报表的数据项和文本?实际上，需要同时考虑这些项目。

如何布置报表中的字段并不重要。然而，此时花的时间越多，构建报表就会变得越容易。有些人甚至在报表中放置了网格线，以便于了解每个数据的准确位置。在这个例子中，实际上可以直接布局报表上的字段。

创建图1-3 和图1-4 中的报表有两个不同的.目的。图1-3 中的报表显示了有关单个联系人的信息(购买者、销售商或者二者兼备〉。与此相反，图1-4 中的报表是一个包含票据和客户信息的发货单。这两种报表都是建立在所用信息类型的基础之上。每个报表的设计和布局都是由报表的目的和表中包含的数据来驱动的。

图1-3 联系人信息报表

参考:可以在第9 章和;第20 章中了解到更多有关Access Auto Auctions 系统报表的内容.

图1.4 包含销售信息的销售发货单报表

1.4.3 第3 步:数据设计:需要哪些字段?
设计阶段的下一步就是建立一个关于报表所需的所有信息或数据字段的清单。最好的办法之一就是列出每个报表中的数据项。在此过程中， 一定要注意多个报表中所包含的数据项。由于数据项实际上是相同的，因此要确保为多个报表中的每个数据项保留了相同的名称。

另一种方法就是看看是否可以将数据项分到多个逻辑排列中。以后，这些数据项可以组合为表结构并映射到数据输入屏幕(窗体)。例如，应该输入客户数据(购买者和销售商)，作为联系人表处理的一部分，而不是作为销售输入项的一部分。

1 .确定联系人信息
首先看看己经检查过或者试图为Access Auto Auctions 创建的每一个报表。对于该系统而言，应从客户数据和数据项列表着手，如表1-1 所示。

表1-1 报表中与客户相关的数据项

通过比较每个报表所需的联系人(客户)类型可以看出，报表中存在着很多的公共字段。大多数与客户有关的数据字段在两个报表中都可以找到。表1-1 只显示了每个报表中都使用的一些字段：与客户信息有关的字段。两个报表中的字段出现在表中相同的行中，这就可以更容易地查看到哪些数据项存在于哪个报表中。可以在一行中进行查看而不需要在两个报表中查找相同的名称。由于相关行和字段名称都相同，所以可非常容易地确保包含了所杳数据项。尽管轻松查找数据项对于小型数据库来说并不重要，但在必须处理其中包含了许多字段的大型表时，这一点就显得至关重要。

2. 确定销售信息
提取客户数据后，可以继续处理销售数据。此时仅需分析Invoice 报表中专门用于销售的数据项。表1-2 列出了报表中包含销售信息的字段。

表1-2 报表中的销售擞据项

检查报表所需的销售信息类型时可以看到，几个数据项(字段)是重复的(例如，所购产品、购买数量和商品价格字段)。每个发货单都可以包含多个数据项，而每个数据项都需要同类信息：定购数量和单价。每张销售发货单都可能包含多个己出售并且正在列出发货清单的商品。同样，每张发货单也可以包含分期付款，并且这种支付信息将包含多行的支付信息，因此这些重复的数据项可以放入它们自己的组中。

3. 确定项目信息
可以使用前面部分所述销售信息组中可找到的所有单个数据项，并将它们提取到发货单报表中对应的组。表1-2 显示了与每个项目有关的信息。

回顾一下图1-4 中的报表，可以看到表1-2 中的数据没有列出计算字段，但可以在报表中轻松地重新创建宫。

提示:除非几个数字字段特别要求存储在一个表中，否则应在运行报表(或者窗体)时进行重新计算。如果可以基于其他的字段来创建表中的字段，就应该避免创建后者，可在报表或窗体中轻松创建并显示这些计算字段。在本书的第2 章中，将了解到在数据库表中存储计算值会导致数据维护问题.

1.4.4 第4 步:表设计
现在是比较困难的部分2 必须确定构成报表的表需要哪些字段。检查文档中的大量字段和计算值时，可以看到各种数据库表中包含了哪些字段(通过把字段安排到逻辑组中，己经完成了大量的初步工作〉。现在添加提取的每个字段。尽管某些字段不会出现在任何表中，仍需要在以后添加其他字段(出于多种原因)。

不需要向数据库表中添加每一位数据，了解这一点尤为重要。比如，用户可能会表示出向数据库中添加假期和其他不在职的愿望，从而可以更容易地了解某一天中有哪些员工出勤。然而，在初步开发阶段，融入太多思想会很容易对应用程序的初步设计造成负担。由于Access 表以后很易于修改，因而在初步设计完成之前最好先搁置一下不重要的数据项。一般来说，在数据库开发项目开始以后，满足用户的需求并不难。

使用每个报表显示出所有数据后，根据目的来合并数据(例如，组合成逻辑组)并且比较这些功能间的数据。为此首先需要查看联系人信息，并且把不同的字段都结合起来以创建一组数据工页。接着对销售信息和项目信息也进行同样的操作。表1-3 对来源于这三组信息的数据项进行对比较。

表1-3 比较来源于联系人信息、销售信息和项目信息的数据项

数据合并和比较是为Access Auto Auctions 创建单个表定义的好办法，然而还有很多工作需要完成。

随着逐步了解如何进行数据设计，也会了解到联系人数据必须分为两个组。其中一些数据项只针对一个联系人使用一次而其他的数据项可能要多次输入。例如联系人日志信息。每个联系人在数据库中都可能会有多个日志项记录。就Sales 列而言也是如此，支付信息可能会有多个信息行。

进一步把这些信息类型存在它们各自的列中，然后将所有相关类型的数据项分到其自己的列中十分必要，这是设计过程中的规范化部分。例如，客户可能会在公司中拥有多个联系人。客户可能对一次销售进行多次支付。当然，我们己经把数据分为了以上三类:联系人、发货单和项目。

请记住一个客户可能会有多张发货单，并且每张发货单上可能会有多个项目。联系人列表表示客户(购买者和销售商〉信息，发货单类别包含单个销售信息，而项目类别包含每张发货单的相关信息。注意，这三列都是相关的:例如，一个客户可以有多张发货单，每张发货单可能需要多个详细的行(项目)。

表间的关系也是不同的。例如，每张销售发货单有且只有一个客户，而每个客户却可以有多笔销售。在销售发货单和发货单项目之间也存在着类似的关系。

参考:第2 章介绍了创建和了解关系以及规范化过程.

假设这3 个组代表着系统中的3 个主要表，为了让其他的字段更少，就需要将这些表链接起来。当然，该步骤意味着向数据库设计中添加表关系。

数据库表关系要求关系中所涉及的两个表内有惟一的字段。如果在表中没惟一的标识符，则数据库引擎无法正确链接并提取相关的数据。

我们所设计的表中都没有惟一的标识符，这意味着需要向每个表中至少添加一个额外的字段，让该字段作为与其他表形成关系的点。例如，可以向Contact 表中添加ContactID 字段，随后向Invoice 表中添加相同的字段，并通过每个表中的Contact 工D 建立表间的关系(在第3 章中将讨论关系的创建)。数据库引擎使用Contact 和Invoice 表之间的关系将客户与其发货单链接起来。

表的链接可以通过称为键字段的特定字段来实现。

了解必需将两组字段进行链接后，可以向每个组中添加所需的键字段。表1-4 显示了两个新组以及针对每组字段而创建的链接字段。这些称为主露和勿锺的链接字段用来把这些表链接起来。

惟一标识表中每个行的字段称为主挥。相关表中的对应字段称为开擂。在该示例中， Contact 表中的ContactID 字段是主锺，而Invoice 表中的ContactID 字段是必擂。

让我们假设Contact 表中的某个记录在其Contact 工D 字段中显示为120 Invoice 表中任何ContactID 字段包含12 的记录会被第12 个联系人所"拥有"。在第2 章和第3 章中将了解到，可应用特定的规则来选择和管理主键及外键。主键和外键的概念是关系型数据库幕后最为重要的概念。可从本书的第2 章和第3 章了解更多相关内容。

表1-4 包含键的主要表

随着向每个表添加主键，现在可以从每个表中找到与数据库中其他表相链接的字段。例如，表1-4显示了Contact 表(在表中为主键)和Invoice 表(在该表中为外键)中的ContactID 字段。

如表1-4 前三列所示，系统中3 个主要表的核心内容已经标识了。这是通常使用或者首选的最终表设计方案。此外，还使用表1-3 中的字段创建了两个额外的表(列)。

正确设计数据库及其所包含的表内容可能是面向数据库应用程序开发过程中最重要一步。借助有效的数据库设计，可以保持对数据的控制，消除损失重大的数据输入错误并且限制对基本字段的数据输入。

尽管本书并非为数据库理论及其细微差别而设计，但此时可以简要描述数据库规范化技巧。

规范化的详细内容可以在第3 章中了解到，但同时应该知道规范化是将数据分解到几个组成表中的过程。在本章的开头部分己经提到了有很多Access 开发人员将不同的信息(例如联系人、发货单数据和发货单项目)添加到一个大型表中。一个包含不同数据的大型表会立即变得难以使用和更新。由于某一联系人的电话号码存在于包含该客户信息的任何行中，因而在联系人的电话号码更改时必须进行多重更新。

规范化是将数据分解成为更小、更易于管理的表。每个表定义且仅定义了一个实体， 例如联系人或发货单，而不能同时对二者进行定义。通过发货单表中的主键(客户表中的ContactID)和外键(也称为ContactID) ，可以建立联系人和发货单表之间的联系。

规范化过程还涉及到了很多其他的内容，我们将在第3 章中进行讨论。

1.4.5 第5 步:窗体设计:输入
创建数据并建立了表关系后，就到了设计窗体的时候了。窗体是由可以在"编辑"模式中进行输入和查看的各个字段构成。如果有可能，屏幕上会显示出与人工系统中所使用的窗体非常类似的窗体。这种设置可让系统显得更为用户友好。

设计窗体时需要在屏幕上放置三类对象:
标签和文本框数据输入字段CAccess 窗体和报表中的这些字段通常被称为2佯) ;
特殊控件(多行文本框、选项按钮、列表框、复选框、商业图形和图片) ;
提升窗体效果的图形对象(颜色、线条、矩形和三维效果)。

设计窗体时，将字段(文本框、复选框、列表框和单选按钮)放置在窗体中的相应位置。如果窗体是基于现有的打印窗体开发的，那么Access 数据输入窗体应与打印格式类似。这些字段在屏幕中的位置应与它们在打印窗体中的位置一致。

标签显示消息、题目或标题。文本框提供了一个用于输入和显示数据库所包含的文本或数值的区域。复选框指示了某种条件，可以是未选中或者选中(选定)状态。Access 中可用的其他控件类型包括列表框、组合框、选择按钮、切换按钮和选项组。

参考:第7 章介绍了Access 中可用的各种类控件。

本书中创建了几个基本数据输入窗体。
联系人日志:简单的数据输入窗体。
联系人:稍复杂的数据输入窗体，包含了几种不同类型的控件。
销售:从多个表中组合数据。
产品:向Access Auto Auctions 数据库添加产品的数据输入窗体。

在阅读以下各章内容的过程中会看到所有这些窗体。尽管Access Auto Auctions 只是一种使用Microsoft Access 构建的数据库应用程序，但是在构建Access Auto Auctions 表、查询、窗体、报表和其他数据库对象时所了解的原理实际上也适用于其他任何Access 项目。

1.5 小结
本章介绍了深入数据库开发的各种概念和考虑事工页。数据对于用户来说非常重要，这一点毫无疑问。如果没有客户和产品列表、应收账款和应付账款以及工资单信息，大多数公司都无法运营。甚至小公司也必须对它们的业务数据进行有效的管理。

出色的数据库设计意味着不仅仅是坐下来拼凑几个表。通常，不好的数据库设计习惯经常会导致在屏幕和打印报表中出现信息丢失和信息错误，这严重困扰着开发人员和用户。用户很快就会厌烦-次次地重复输入同样的信息，业务经理和业主都很期望数据库应用程序能够节省时间和资金，而不是增加业务开销。