从本讲开始，我们设计、编写一个应用程序，在程序的编写过程中穿插讲解数据库有关知识，这种写讲座的方式是一种尝试，完整的程序需要很多讲之后才能完成，对编写数据库程序不熟悉的读者只要紧跟讲座，边学边练定会有所收获。下面就跟着心铃来开始设计程序吧。
编写程序设计方案
这里心铃就按照第一讲中提到编写数据库程序的方法来进行。在设计应用程序之前我们先要明白程序的基本要求。心铃在这里要带领大家编写的程序名称是“劳保用品发放管理系统”，这是应我们公司生产计划部编写的一个实用程序。
程序应该具备哪些主要功能呢？在企业工作的读者可能都知道，劳动保护用品是国家明文规定必须要给员工发放的，基本要求是：对不同的工种要发放不同的劳保用品以适应从事工种的安全、工作及其他需要。只知道这些对编写应用程序来说是远远不够的，你必须了解更多的内容才能编写程序，正如编写行业商品软件那样，你首先要了解行业的运作模式才能写出符合用户需求的软件，所以，要进一步了解企业劳保用品的发放办法。根据自己掌握的情况并向部门分管人员了解，得知劳保用品发放方法是：按不同的工种发放不同的劳保用品；不同的劳保用品发放周期不同，如棉衣60个月发放一次，工作帽24个月发放一次等；工种变化后劳保用品也随之变化；不同的工种相同的劳保用品发放周期也不同，比如科室人员的棉衣60个月发放一次，而车间人员的棉衣是48个月发放一次。
知道了劳保用品的发放办法后，就要询问用户的需求了。用户提出程序应该具备的功能是：员工可以添加和删除；按单位（部门）每半年下达一次发放计划给各下属单位和供应部门，由各单位根据下达的计划向供应部门提出劳保用品的名称、规格、数量等，供应部门负责采购，发放计划中包括单位每个员工应领取的各种劳保用品的名称、数量、规格及整个单位各种劳保用品的名称、数量和规格汇总数据。到这里，读者可先不往下阅读讲座内容，根据上面提供的发放办法和用户的需求，考虑一下程序应该怎么编写，应该写哪些功能，还应该增加哪些用户没有提出的功能和辅助功能。
我们应该知道，软件用户特别是应用类软件的用户一般都不是电脑高手，他们提出定制的软件功能一般都是最主要的功能，但软件的编写人员不能只完成用户提出的功能。作为程序编写人员来说，无论是写通用软件还是为个别客户定制软件，都首先要具有尽最大努力让用户使用方便、为用户着想的思想，所以编程者必须充分考虑用户可能用到的各种功能和其他一些程序自身需要的功能，就这些用户没有提出的功能和用户沟通，最后确定程序应具备的各种主要和辅助功能。下面就是心铃最终为“劳保用品管理系统”确定的各种功能，有些给出了解释。
（一）本程序应具备的功能：
1 员工基本情况录入。此功能除了录入员工姓名、性别等基本信息外，部门、工种、有规格要求的劳保用品的规格等关键信息是不可少的。后面会解释有规格要求的劳保用品是怎么回事。
2 新员工劳保用品初次发放时间设定。这是一个比较重要的功能，用户没提出来。为什么要有此功能呢？由于老员工都已经有了发放记录，每种劳保用品上次的发放时间都记录下来了，这样根据发放周期和上次发放时间就可以计算下次下达发放计划时是否应该发放及发放数量，对新员工来说，由于没有发放记录（劳保用品上次发放时间），就无法计算下次什么时候该发放，所以必须特意制造出一个初始发放时间记录。根据公司规定，新员工到岗位后就应该在半年之内将所需的所有劳保用品发一套，这样用户就可以将新员工的初始发放时间记录按发放周期向前推一个周期作为上次发放时间，下次程序统计时就一定能为此新员工发放劳保用品了。
3 按单位（部门）统计本次发放给各员工、此单位汇总及所有单位汇总的劳保用品名称、规格、数量，此功能应该是最核心的一个功能了，没有好解释的。
4 员工工种改变。这个功能也是很重要的一个功能，员工一般不会在一个岗位上干一辈子，工种改变是不可避免的，更改了工种，劳保用品种类及发放周期都应重新设定。
5 发放记录查询。查询功能应该是必备的，虽然用户没提出来，但应编写查询单个员工的所有劳保用品上次发放时间记录的功能。
6 员工信息修改及删除员工。这是应该具备的较重要的功能吧。
下面是心铃认为的各种辅助功能，虽然划为辅助功能，但有些也是比较重要的：
7 某工种劳保用品发放周期修改。企业有时根据实际情况调整某些工种劳保用品的发放周期，必须及时修改，这关系到所有此工种的人员。
8 某工种增加劳保用品。这事也常有，及时增加可使此工种的员工下次发放时都能领到。
9 某工种删除劳保用品。
10 删除工种。
12 增加新工种。不要忘记给此新工种添加对应的劳保用品和发放周期。
13 工种改名。
14 劳保用品改名。
15 增加新部门
16 删除部门
17 部门名称修改
18 部门合并
19 员工部门改变
20 按部门查询员工基本信息、查询所有员工和单个员工信息
以下是心铃划出来的其他一些功能：
21 数据库管理。包括数据库整理、压缩、备份、还原等，还是比较重要的。
22 帮助信息。总得给用户提供帮助文档吧。
23 打印功能。此功能放在这里主要是因为随着公司办公自动化的发展，各种计划直接以电子文档方式传送，可以不用打印功能了。
24 关于本系统。现在的软件都应该有吧，提供版本信息、版权信息、求助联系方式等。
读到这里，大家感觉如何，别看用户提出的功能很少，但站在用户角度，本着为用户着想的思想，心铃给程序列出了二十几项功能，虽然重要性、使用频率不一样，但几乎都是必不可少的。至此，我们完成第一步方案的一半任务，下一半的任务是根据所需功能来构造数据库结构，包括用几个数据表、每个表中的字段及属性设定。
（二） 构造数据库结构
上面我们已经分析了程序的功能，那么我们根据上面需要完成的功能来构造需要的数据库。
我们首先要做的是选择使用什么类型的数据库。选择什么样的数据库要考虑数据量的多少及要求什么样的性能，对我们的这个程序来说，由于是给企业用的，数据量不是太大，就我们公司而言，约八千员工，每人平均劳保用品为八种，这样发放记录大概有6～7万条；从性能要求来说，每半年集中发放一次，平时就是用来做维护员工在企业内部岗位更换、工种变化、新增员工等一些工作，要求也不高。从这些方面来说，目前的各种类型的数据库都可以满足要求，但我们还应该再考虑一下使用方便及数据库流行的程度。从目前来说，使用DBF数据库的比较少，由于Delphi是将Paradox作为自己的标准数据库的，所以使用Paradox数据库的也不少，而使用大型数据库比较复杂也根本没必要，使用ACCESS97或ACCESS2000类型的数据库比较多，因此我们可以根据自己的喜好选用Paradox或ACCESS数据库就可以了。心铃最终选择使用的是ACCESS97数据库，能满足要求，由于大部分电脑中都安装有office，所以随时可以方便地在ACCESS中打开，在中文ACCESS97下建库也非常方便，加之它只有一个数据库文件，安装目录下只有很少的二三个文件，而不象Paradox数据库那样每个数据表是一个文件，还有许多索引文件，看起来让人烦。
选好了数据库类型，我们就要来考虑需要几个数据表了。最基本的我们首先应该想到有员工信息和发放记录两个表，再考虑一下工种和对应的劳保用品，我们还应该有一个工种劳保对应信息数据表。由于在录入数据时应该有部门名称和工种名称供选择，所以必须有部门名称及代码、工种及代码两个数据表。在未深入编程之前，是否还要用到一些临时数据表还不能确定，所以这里我们就把需要的基本数据表构建出来就可以，其他的根据编程需要再构建。我们先来为数据库选一个名字吧：LKLB,那么数据库文件的全名就是LKLB.MDB。下面我们就来构建LKLB中的这几个数据表。
1 员工基本信息（取个名字LKYG）
员工信息这个数据库表中都应该有什么字段呢？部门名称、员工姓名、性别、工种名称是最基本的吧。我们想一下，部门名称和工种的内容都是汉字，在程序中使用时不是太方便，所以我们最好给每个部门和工种都分配一个对应的数字编号。是否想过员工有重名的现象？这是很常见的，特别象我们八千人的大企业。因此我们必须有一个唯一能区分员工的字段，用数字编号是最常用的，所以给每个员工分配一个唯一编号，不允许重复。另外从程序中的员工劳保用品查询功能考虑，由于不太可能记住每位员工的编号，所以需要使用姓名来查询，查询时输入员工的姓名汉字是比较麻烦的，常采用的是用姓名的每个汉字的第一个拼音字母来输入，这样我们需要增加一个姓名拼音字段。下面该考虑员工的劳保用品的问题了。
关于劳保用品种类问题，按常规只要知道了员工的工种就可以在工种劳保对应信息表中查到该员工所有的劳保用品。如果劳保用品都没有规格之分就好办了，如毛巾、香皂每位员工发放的都一样，但劳保用品中有一些是有规格的，比如棉衣、工作鞋等，每个员工的各不相同，心铃只能把这些有规格之分的劳保用品放在员工信息表中，当然再为每位员工建一个有规格的劳保用品数据表也是可以的。还要考虑一个问题，如果我们设计时只设计员工当前的工种对应的有规格的劳保用品是不行的，因为作为一个字段来说，应该都是同一类的，那么我们就必须将所有带规格的劳保用品都设定一个字段，在录入时即使员工所属的工种没有这种劳保用品也录入。这样做有一个好处，正常情况下根据工种对应的劳保发放，如果碰到有规格的劳保用品就到员工信息表中来查询规格，当然有些是用不到的。如果员工工种变化了，有了和以前不同的有规格的劳保用品，那么就不用再修改员工信息表了，因为事先都已经录入了，这样可以做到无论员工的工种怎么变化，员工信息表都无需再改变。至此，我们的员工基本信息数据表的字段就可以确定了。下面是LKYG数据表中的字段、字段类型、长度等汇总表。
||||||LKYG数据表字段信息列表
字段名称
含义
类型
长度
备注
bmbh
部门编号
文本
3
索引有重复
xm
姓名
文本
8
xmdm
姓名拼音
文本
4
ygbh
员工编号
文本
6
索引无重复
xb
性别
文本
2
gzbh
工种编号
文本
3
gzfgg
工作服规格
文本
3
mygg
棉衣规格
文本
3
cygg
衬衣规格
文本
3
bwx
白网鞋规格
文本
4
bjx
布胶鞋规格
文本
4
jx
胶靴规格
文本
4
jyx
绝缘鞋规格
文本
4
xz
文化衫规格
文本
4
由于考虑到都是按部门来发放，所以建立部门编号索引可以提高程序的执行效率；员工应有一个不允许重复的员工编号索引。
2 发放记录数据表（FFJL）
发放记录数据表结构如下：
字段名称
含义
类型
长度
备注
bmbh
部门编号
文本
3
索引有重复
ygbh
员工编号
文本
6
gzbh
工种编号
文本
3
lbmc
劳保名称
文本
12
ffrq
发放日期（上次）
日期
ffzq
发放周期（月）
整型
按部门索引主要是为了提高统计速度。为什么在这里要加上发放周期呢？心铃是这么考虑的，只要平时员工工种变动等能及时在程序中更改，那么每次发放时，就根据这个发放记录中的发放日期和发放周期直接计算是否应该发、该发多少数量，就没有必要对每个员工再通过其工种去查其劳保用品的发放周期了，这里虽然使得数据库有点冗余，但写程序比较方便。由于人员较多，不可能每次发放都做流水记录，否则每次要增加几万条记录。所以心铃采用的是只保存最近的发放记录，也就说发放后发放日期将更新为最近的一次的发放日期，这样保证不影响以后的发放，而数据库也不会迅速膨胀。
3 工种劳保对应数据表（GZLB）
结构如下：
字段名称
含义
类型
长度
备注
gzbh
工种编号
文本
3
索引有重复
lbmc
劳保名称
文本
12
ffzq
发放周期
整型
4 部门数据表（BM）
结构如下：
字段名称
含义
类型
长度
备注
bmbh
部门编号
文本
3
索引无重复
bmmc
部门名称
文本
24
索引无重复
5 工种数据表（GZ）
结构如下：
字段名称
含义
类型
长度
备注
gzbh
工种编号
文本
3
索引无重复
gzmc
工种名称
文本
24
索引无重复
到这里，我们已经把数据库结构构造出来了，请读者建立LKLB数据库并在数据库中建立上述五个数据表吧，并利用第二讲中讲到的建立数据库别名的方法为数据库建立别名lklb。下一讲将继续按照心铃在第一讲提到的几个步骤进行资料准备、编写程序流程等工作。
