人性化公共报修系统的数据库设计

史书明 （常州工学院计算机信息与工程学院，江苏 常州213002）

随着计算机应用的深入推广，企事业单位中使用 “公共报修系统”来改善后勤服务质量和效率的也越来越多。但是目前主流的公共报修系统在实际使用时，普遍暴露出通用性有余、针对性不强、功能有限等不足。在此，笔者对公共报修业务进行了细致的分析，提出了一套人性化的设计方案。

1 现行 “公共报修系统”的主要不足

目前多数 “公共报修系统”存在以下不足：①平台开放，缺少 “用户登录”环节。看似便捷，却不能阻止恶意的信息发布，而且报修时每次都要填写报修人信息 （姓名、联系电话等），如果经常报修，反而带来麻烦，而且还容易出现由输入错误带来的意外。②报修一旦完成，不能修改。如果当时报修信息填写有误，不能更正，也不能撤单 （这也是缺少 “用户登录”环节带来的弊病）。③报修信息中的“地点”信息，由报修人自己填写，无法规范，而且容易出错，也不便于日后统计。④缺少领导敦促功能，而实际工作中却是需要的。⑤缺少评价、投诉功能，无法为维修员的工作实绩提供有效的评估依据。⑥统计功能不丰富，不能为后勤服务工作的总结、规划、发展提供确凿、科学的分析手段。⑦缺少历史数据转存清理功能。历史数据不能简单删除 （毕竟还是会有可能需要调阅很久以前的信息），但日积月累，会严重影响系统的运行效率。

2 报修业务分析

2．1 前台业务分析

目前主流的公共报修系统，前台通常只涉及2个角色，即 “报修方”和 “维修方”，缺乏 “管理方”，而且 “报修方”没有 “登录”的环节，因此功能和业务流都很单一。笔者在设计中引入了 “管理方”，报修方也增加了 “登录”环节，使得系统更贴合了实际的业务需求，从而业务流也发生了明显的变化，如图1所示。

在图1中，所有带实线下划线的操作都是由 “维修方”发起的，包括受理、完工、申请延期、申请撤销、评价回复、投诉回复；所有带虚线下划线的操作都是由 “管理方”发起的，包括同意延期、拒绝延期、敦促、投诉回复；所有带实线框的操作都是由系统自动发起的，包括过期、延期结束；其他操作都是由 “报修方”发起的，包括报修、主动撤销、同意撤销、拒绝撤销、评价、修改评价、投诉、撤销投诉。

按照笔者的设计，“报修方”、“维修方”和 “管理方”发起的所有操作中，除 “敦促”外，都允许修改，但是，为了体现严肃性，修改之前的历史痕迹都应该得到保留。在图1中可以看到，一次报修业务的最终状态有4种：已完结、已撤销、已过期、被投诉。通常，报修业务都应该终止在 “以完结”状态。最顺利的一次报修业务一般是这样的：首先，报修人员登录后进行 “报修”操作，业务进入初始状态，即 “已报修，等待受理”。然后，相关的维修人员登录后会收到这个报修，并予以受理，业务状态转入 “处理中”。接下来，在维修完成后，维修人员进行 “完工”操作，业务状态转入 “已处理，等待评价”（因为日后要通过对维修人员获得的所有 “评价”进行统计分析，以评判该维修人的工作实绩，因此 “评价”环节是必须的）。最后，报修人员进行评价，报修业务进入结束状态，即 “已完结”。此后，维修方可以就报修方的评价进行评价回复，但不会改变业务的状态。

报修业务也可以终止在 “已撤销”的状态。如报修人员发现自己误报了，则可以 “主动撤销”。维修人员受理报修后，发现此次报修因特殊原因不能处理 （如因外网光缆受损，导致不能访问外网），则可以申请原报修人员撤销报修，原报修人员批准后，业务终止于 “已撤销”状态。

报修业务若在规定时间内 （后台可以指定一个天数）未能被受理或是没有处理完毕的，则由系统自动终止，并标示为 “已过期”状态。对过期的报修，报修方有权发起投诉，从而使业务终止于 “被投诉”状态。若是未及时受理引起的过期，由于尚未确定维修人员，因此该投诉的回复由相关部门的管理人员负责；若是受理后的过期，即维修人员未能在规定时间内处理完毕，则该投诉的回复由受理的维修人员负责。投诉回复不影响业务状态，报修方也可以撤销已经发起的投诉，从而使业务状态从 “被投诉”回复到 “已过期”状态。

管理人员除了在报修业务的过程中能够进行一些干预操作外，在实际工作中，还有一些特权，主要是对信息的查看、统计和分析。如查看某个员工上半年的报修次数；统计某几个维修人员上一年度的用户评分情况；比较同一时间段内不同楼宇中相同报修小类的发生次数等等。

图1 前台业务状态图

2．2 后台业务分析

后台的主要业务通常涉及人员管理、公共信息管理、系统维护等等。人员管理主要包括账号管理、角色 （权限）管理；公共信息管理主要包括报修位置 （故障发生的具体位置）管理、报修类别管理、时间段管理 （主要针对数据转储和统计）；系统维护主要包括数据库的备份、还原、系统初始化、历史数据的转存和调用等等。其中转储历史数据的直接目的就是将过期数据从主数据中剔除，以提高系统的运行效力，但考虑到日后可能会需要调阅这些历史数据，因此采取转储的形式。转储后的历史数据需要被“调阅”后才能看到，但 “调阅历史数据”的功能不会向普通用户开放，发生的频率很低，所以由此带来的不便也很有限。

2．3 特色业务分析

1）“用户地址簿” 因为大多数用户在报修时的地址信息是相对固定的，所以 “用户地址簿”的使用可以帮助用户方便准确地填写地址信息。“用户地址簿”的产生途径有2种，一种是用户自定义，另一种是系统自动生成。系统自动生成又可以按2种方式，一种是取最近使用过的若干个地址，按时间的由近到远排序；另一种是取最近一阶段使用频率最高的若干个地址，按使用频率由高到低排序。

2）“时间段定义” 转储历史数据的首要目的是给现行系统减负，其次是为了日后的调阅。“调阅”通常会指明一个 “时间段”，如果没有对时间段进行具体的说明和定义，那么，在需要调阅某个历史时间段的数据时，用户在起止日期的确定上往往会很迷茫。如2011年的某天，校领导要求调阅2005～2006学年第一学期的有关数据。这个时间段到底应该从哪天算起又是到哪天结束，恐怕没人能立即提供正确的答案。然而，如果事先现进行了 “时间段定义”，就可以方便地从 “时间段列表”中选择，而不必担心出错。

3 数据库设计

3．1 数据库的总体设计

数据库中的数据表被分为2大类：一类是与报修业务直接相关的表，这里称为 “前台类表”；另一类是与报修业务不直接相关的表，这些表主要面向后台系统管理员，这里称为 “后台类表”。

1）前台类表的设计 前台类表的设计以前台业务的分析为基础，因此涉及以下一些表：①前台用户要求登录后方可进行操作，因此需要有一个用户表 （users）。另外需要一个用户所在部门的信息表（departments），以方便用户管理。②前台的用户有不同角色，不同角色的用户会被分配不同的操作权限，因此需要有一个用户角色表 （user＿character）和一个操作类型表 （operations）。③用户报修需要提供位置信息。这里将位置信息分成由大到小的3级——区域、楼宇、房间 （房间也兼有 “场所的含义”，如3楼走廊）。因此需要有区域信息表 （areas）、楼宇信息表 （buildings）和房间信息表（rooms）——这3个表之间是逐级关联的。④用户的报修项目还需要指定类别。这里将类别信息分成由大到小的3级——维修部 （如总务处）、工种 （如强电）、小类 （如照明），其中，“工种”也可理解为是 “大类”。因此需要有维修部信息表 （这个表可以借用前面的部门信息表）、大类信息表 （big＿class）和小类信息表 （small＿class），显然，这3个表之间也是逐级关联的。⑤前台用户的各种操作都需要被记录下来，形成一个流水账，因此需要有记录表 （records）。这个记录表是信息量最大的表，日积月累后会影响系统运行效率，所以需要被定期转储和清理。为了方便日后的调阅，转储的方式可以是建立一个结构相同的转储表，然后将需要转储的历史数据导入其中。⑥为了实现 “用户地址簿”，需要一个用户地址簿表 （user＿addressbook）。

2）后台类表的设计 后台类表的设计，以后台业务的分析为基础，因此涉及以下一些表：①前台用户的个人信息可以由前台用户自行维护，但是用户的角色、权限则是由后台管理员维护的。不同角色的有着不同的权限，即可以进行不同的操作，需要有一个用户权限表 （rights）来罗列每个角色都可以进行哪些操作。②用户报修时会涉及调用与 “位置信息”相关的3个表，以及与 “报修类别”相关的3个表中的内容项，但是，很显然，这6个表的维护是后台管理员的职责和权限。③为了增强系统的安全性，需要建立系统运行日志，即记录所有的操作，包括操作发生的时间、发起该操作的用户、操作的类型、操作的概要性说明、IP地址等等。这些都需要一个表来记录，即日志表 （logs）。显然，这个“日志表 （logs）”和 “记录表 （records）”一样也需要被定期转储和清理。④历史数据的转储和调阅都会涉及 “时间段定义”业务，因而需要一个时间段表 （interval）来维护时间段列表。⑤整个系统的全局信息需要一个表来维护，即系统表 （system）。其中包含 “系统标题”、“版权”、“后台管理员账号”等常规信息，还要包含支持前面提到的 “用户地址簿”业务的相关信息，如每个用户的地址条目数上限；默认系统要求报修被受理的时限；默认系统要求报修被处理完毕的时限等等。⑥根据图1，一条报修记录生成后，会经历不同的状态。这些状态包括已报修、已撤销、处理中、已完结、已过期、被投诉、申请延期中、暂缓处理、等待评价、敦促中、申请撤销中等等。这些状态的表述可能会需要修改，而且，2～5个字的短语可能不足以将其含义表达清楚，因此需要配以解释说明，所以就需要一个状态表 （state）来维护这些信息。⑦同大多数用户管理机制一样，需要向前台用户提供 “找回密码”的途径，常见的就是 “密码问题”。为了方便管理，不推荐由用户自定义密码问题，而是由系统设定，因此需要一个密码问题表 （question）。⑧每个维修员都应该有明确的职责分工，包括负责维修的区域、建筑；负责维修的大类、小类，因此需要一个职责分工表 （responsibility）。⑨报修方在业务进入 “完工”状态后，可以对此次报修处理进行评级，但是评级的习惯有多种，有的用 “满意、基本满意、不满意”；有的用 “优、良、中、差”。为了满足通用性，需要一个评级表 （grade）。可以在这个表中引入 “评级”和 “评级值”的概念—— “评级”是直接显示给前台用户的，每一个 “评级”对应一个 “评级值”，这个值主要是面向日后的统计分析的。

3．2 重点表的设计

所有表中 “记录表 （records）”的设计是最为讲究的，因为它直接为日后的统计分析提供第一手的数据。“能够提供丰富的统计分析功能”是系统人性化的重要表现。因此笔者对这个表向统计分析功能提供信息的能力有很高的要求，记录表的结构如表1。表1中，第1～14字段，是报修方在提交报修信息后写入的。其中第2～6字段来自于报修方的登录信息，第7～13字段是由报修方填写的。第15个字段，是根据第7～13字段的内容到 “职责分工表 （responsibility）”中查询后得到的。第16、17个字段，是在维修方进行 “受理”操作后根据维修人员的登录信息写入的 （因为有r＿selectable＿mm字段的存在，所以很容易就可以实现 “仅相关的维修人员才能看到该报修信息”的功能，也就只有这些相关的维修人员才能受理此项报修）。第18个字段是根据 “系统表 （system）”中的相关信息确定的。第19个字段是维修人员进行 “完工”操作时写入的。第20个字段是根据报修方的 “评级”操作而写入的。第21个字段用于记录所有的评价、投诉、评价回复、投诉回复等。第22个字段的内容随不同的操作而改变，以反映该报修业务的当前状态。

表1 记录表 （records）的结构

3．3 细节设计

区域信息表 （areas）、楼宇信息表 （buildings）和房间信息表 （rooms）以及部门信息表 （departments）、大类信息表 （big＿class）和小类信息表 （small＿class）中的内容是要提供给前台用户在报修时选择的。为了方便程序设计时控制这些表中信息项的显示，可以加入2个字段：“次序”（order，数值型）和 “是否可见”（visible，布尔型）。

［1］Connolly T M．数据库设计教程 ［M］．第2版 ．何玉洁 译 ．北京：机械工业出版社，2005．

［2］鲍威尔 ．数据库设计入门经典 ［M］．沈洁 译 ．北京：清华大学出版社，2007．