基于B/S结构的卡务管理系统的设计 - 中国一卡通网
用户名密码 [免费注册] [找回密码] 推广技巧 发布求购 建商铺  发产品  会员体制比较  
 

基于B/S结构的卡务管理系统的设计

来源:中国一卡通网  作者:袁振坤 温遇华  发布时间:2011-03-07 15:11:19  字体:[ ]

关键字:卡务管理  IC卡  B/S结构  

摘   要:本文提出用B/S 结构进行“基于因特网的卡务管理系统”的开发和实践,以适应这种新的应用模式。为了解决B/S 结构软件“客户机”浏览器对读卡器等终端设备的读写操作、B/S 结构系统服务器端负担相对较重的问题、B/S 结构的系统信息安全性的问题,本文分别给出了解决方案。最后通过实际的开发案例进行了实践。

    随着IC及其终端设备的技术的成熟,企业采用IC卡进行辅助运营管理的成本降低,因此,IC卡的使用逐步由这些规模较大的企业或机构,向一些规模较小、运营比较分散的连锁机构发散。由于连锁经营机构经营方式和规模等方面的制约,其卡务管理系统,不适合用传统的C/S 结构进行开发。
    
    1.引言

    传统上,由于成本的原因,IC卡一般都是用于规模较大的企业或部门,例如用于学校作为结算工具的“一卡通”,用于公司作为考勤的考勤卡,等等。因此,卡务管理系统——其功能包括卡片发行、充值、挂失等,其客户机数目较少、相对固定、相对集中,一般采用的是C/S 结构进行开发。

    但随着IC 及其终端设备的技术的成熟,企业采用IC卡进行辅助运营管理的成本降低,因此,IC卡的使用逐步由一些比较大的企业或机构,向一些规模较小、运营比较分散的连锁机构发散。由于连锁经营机构分店数目较多、规模较小小、经营地域分散等特点,采用传统的C/S 结构的卡务管理系统,带来大量的系统维护、扩充、使用上的成本,不利于IC卡与连锁经营机构的有效融合。因此,本文提出,采用B/S 结构,进行该卡务管理系统的开发。B/S 结构的卡务管理系统的开发,与C/S 结构不同。由于B/S 结构的系统其客户机只有通用的浏览器,因此本文提出采用OCX 嵌入网页的方法,提供浏览器操作读卡器等硬件设备的接口;由于B/S 结构的系统服务器负担较重的问题,本文提出采用数据库分裂表设计、浏览器页面请求均衡设计等方法,来尽可能的减轻服务器负担、降低系统对服务器性能的要求;由于B/S 面对广域网,本文提出采用信息加密的方法,保证系统帐号等信息的安全性。

    2. 连锁经营机构的卡务管理系统

    2.1 连锁经营卡务管理系统的提出

    所谓连锁经营,是指在流通领域中,若干同业商店以统一的店名、统一的标志、统一的经营方式、统一的管理手段连接起来,共同进货、分散销售,共享规模效益的一种现代组织形式和经营方式,已成为我国零售业、餐饮业和服务业普遍应用的经营方式和组织形式,并加快向汽车、医药、家居建材、加油站等多业种渗透,显示出厂强大的生命力和发展潜力。目前来说,IC卡在连锁经营中已经得到了广泛的应用,但是,它们更多的是作为一种“电子钱包”,消费者在刷卡消费过程中,产生的反应连锁经营机构经营情况的信息,没有得到利用。连锁经营机构管理层对该机构经营活动的管理和决策所需的信息,仍然是通过各分店传统的纸质报表方式获得,信息反馈不及时、效率低。因此,为连锁经营机构开发一个卡务管理系统,收集由于消费者刷卡等行为产生的信息,并能进行必要的统计分析,为决策层提供决策支持,取代传统做法上人工、纸质的方式,能提高机构的运行效率和决策的准确性。

    连锁经营机构的卡务管理系统,需要实现如下功能:[1]总公司管理层通过登陆进入系统,通过选择和输入检索条件,对会员信息、分店运营信息、商品销售信息等进行检索和统计等管理操作,为实行新的广告策略、分店经营范围优化、制定商品进销计划等提供决策支持;[2]分店通过通过登陆进入系统,进行新会员的开通、会员的刷卡消费、会员卡的充值、会员卡的挂失、对本店运营信息的检索统计等操作。如图1 所示。 

    2.2 B/S 机构的卡务管理系统的设计

    由于连锁经营机构对卡务管理系统的使用,分店与总公司使用频率不同。分店很频繁,而管理层对系统的使用频率,远远要比分店小,所以为了尽可能的保证系统的健壮性,同时为了保证各分店对该卡务系统的使用,和总公司决策人员或管理人员对卡务系统的使用或管理相对独立性,本文把整个卡务管理系统分为如下两个分系统:仅对决策人员/管理人员开放的管理中心系统,仅对分店开放的分店系统。与传统的卡务管理系统不同,由于连锁经营机构具有分店规模小、经营地域分散、扩展较频繁等特点,所以,系统的开发不能采用一般的C/S 软件结构。用B/S 结构进行该系统的开发,能很好的满足连锁经营机构扩展性的要求,而且由于其维护成本低、使用简单等特色,降低了系统的维护和使用费用,节约了成本。

    在此类连锁经营中,分店是直接面对会员的窗口,直接与会员活动打交道,还可以依据分店权限的不同,给会员提供不同的服务,例如会员的刷卡消费、刷卡充值、以及新增会员等,这些信息就是该店的运营情况信息。这些信息,通过分店对系统的使用,采集和汇总到系统的中心数据库,为管理层的决策支持等行为,提供依据。分店对该系统的使用,至少应该提高两个接口:一是提供对系统的手动操作,例如:信息录入、意外情况下对系统的处理的人机交互界面;二是提供读卡设备等终端,连接到系统的接口。有些操作,例如会员卡充值,既需要读卡器读取卡号,有需要手动输入充值金额信息; 

    分店系统,通过如下方式,采集公司管理层所需的相关信息:一方面,在消费者直接刷卡消费活动时,系统自动汇总到中心数据库;另一方面,分店的手动操作分店系统,实现信息的采集。

    管理中心系统需要能对所有会员、分店的信息提供方便高效的管理,为公司决策层的决策、加强与会员的联系互动,提供依据;因为分店对系统的使用,是通过中心系统授权的合法帐号进行的,分店对会员提供的服务,是由中心系统授权决定的,所以中心系统必须拥有严格的分店授权和管理机制;中心系统还必须能对系统采集到的信息提供必要的分析、汇总的决策支持手段,例如:按要求生成和打印各种报表、生成和打印特定的曲线或走势图等,取代传统上手工做法,达到提高企业运行效率的目的。 

    2.3 B/S 结构卡务管理系统的几个关键问题

    正如前文所述,要实现这种新的卡务管理系统,与传统的C/S 架构不同之处,就是要解决/实现这样三个问题: 浏览器实现对读卡器等终端设备的操作;尽可能的减轻服务器的负担,增加系统的可靠性;如何保证系统的安全性。

    在下文,作者采用了三种方法,以期能对B/S 架构系统可能面临的,上文所述的三个方面的问题,作出尽可能的解决/改善。

    2.3.1 用OCX 提供浏览器与终端之间的接口

    我们知道,B/S 架构的软件,它没有专门的“客户端”软件,只有一个通用的浏览器,例如:IE。浏览器只是一个浏览工具,本身并不能对读卡器等终端设备进行操作,因此,我们必须采取其他方式,来解决这一问题,我们采用的是通过开发相应的OCX 控件,嵌入网页,提供浏览器与终端设备之间的接口,这样,在没有专门客户端软件的情况下,仅仅通过使用浏览器,也能实现对终端设备的读/写等操作。每个OCX 控件都有一个唯一的ID, 在网页中,可以可以通过Javascript 脚本语言,把OCX 控件潜入网页[1]。示例如下:
    OBJ = document.getElementById("OcxID");
    OBJ.Function(parameter);

    2.3.2 海量数据表的分裂表设计

    用户对数据库最频繁的操作是数据查询。为了提高数据检索的能力,数据库引入了索引机制。按照一种最频繁的访问习惯在某列建立簇索引,能极大地提高数据库的访问效率[2]。然而,索引虽然能提高数据库表的查询性能,但影响了数据库表的更新,所以对那些更新频繁的表,不适合建立索引。同时,对一个海量数据表里数据的访问,不是均等的,人们常常对某个范围内的数据更感兴趣一些。基于上文两点原因,有研究者提出,按照一定原则对海量数据表进行分表设计,能有效地减少数据查询的时间。

    已有研究证明,一个分裂成n 个子表的分裂表设计,当查询无分组统计(即group)时,分裂表设计的查询时间,最佳情况可以达到分裂表之前的1/n,最差情况约与分裂前相当;当查询有分组统计时,最佳查询时间为分裂表之前的1/n2,最差时间与分裂表之前相当[3]。那么如何确定该分裂表的原则呢?参考建立簇索引时,一条重要原则就是:簇索引要建在最常被用来作为查询条件的列,因此本文提出这样的“分列表”设计的原则:不考虑约束因素,假设大表能建簇索引。那么,“簇索引”列,就是进行分裂表的“分表列”。以该列进行分裂表的查询效率提高,类似于索引对查询效率的提高,取决于对该表进行查询时,该列作为查询条件的频率。频率越高,效率提升越多。

    2.3.3 客户端数据请求的优化

    除了上文所说的,由于单次查询数据库时间过长,增加服务器负担外,还有一种情况,也增加了服务器负担,那就是“客户端”对服务器端的频繁数据请求。这种情况可能经常发生,例如:在百度输入关键字进行检索,百度并不会一次把所有页都返回给浏览器,而是返回搜索结果的第一页,当人们对后续的某页感兴趣时,浏览器再次向服务器提交请求,由服务器返回该页信息。每点击一次后续页的连接页码,就需要对服务器提交一次页面请求,这样,就造成了对服务器甚至数据库的频繁访问。

    我们注意到,通常我们获取到的检索结果往往比较多,而人们并不会每个结果都去一一察看,人们总是看有限几页后,就失去了继续看下去的兴趣[4]。因此我们设计一个合适的P,浏览器每一次向服务器提交页面请求时,服务器不是返回一页,而是返回P 页。在接下来的P-1 页请求中,浏览器直接使用已储存在缓存中的结果,而不需要再向服务器请求,如图3。这样,把访问服务器的频率最好情况下,可以降低到原来的1/P。 

    作者通过调查发现,75%以上的用户,兴趣范围在3 页以内,这说明,尽管检索获得了大量的数据,大部分情况下,人们只对前3 页感兴趣。考虑到每个结果网页超文本的大小,以及目前的网络带宽,一次访问,取合适的冗余数据(例如3 页),是可行的。

    2.3.4 系统安全性设计

    加密技术是网络安全的核心[5]。由于本系统用B/S 开发,运行在广域网上,因此必须对系统的安全性和关键信息的保密性进行考虑。对于一个运行在广域网上,但是仅对特定用户开发的系统来说,目前最主要的准入手段就是帐号,通过建立严密的帐号和权限管理机制,来实现系统对特定用户的、分层次的开放。

    用户口令的保密性,是保证系统安全性的基本。然而,通过网络监听、种植木马病毒等手段,使口令的安全性受到严重的威胁。口令在浏览器端提交到服务器端进行验证的过程中,可能被窃取。因此,我们需要对密码进行加密,再进行传输。目前来说,MD5 是一种较好的加密算法,对口令的加密足够了。针对加密对口令的保护,出现了木马病毒,它不需要监听数据报,从而获取口令信息,而是通过感染目标客户端,用户进入登陆界面,进行登陆时,记录用户的键盘动作。所以,可以通过设计动态软键盘的方式,进行有效的预防。

    3.实现和应用

    本文针对连锁经营卡务管理系统所提出的结构和设计,已经成功的应用于一个连锁经营机构的卡务管理系统的开发和实践中,该连锁经营机构下设分店数目为20 个。在该系统中,需要维护一个消费流水表,数目每天2 万左右,分列表的方式采用的是按月分列表,由于流水更新主要在当前月,往月更新极少,所以在往月建立索引,当前月不建任何索引;在系统中,数据访问均衡设计里的P 取了3;加密算法采用的MD5。系统运行稳定,用户反应良好。

    4.结论

    IC卡在连锁经营中得到越来越广泛的应用,开发一个适合于连锁经营模式的卡务管理系统,很有意义。本文针对连锁经营的特点,提出采用B/S 结构,进行该系统的开发,并针对系统中可能出现的几个问题,进行了探讨,提出了解决或改善的办法。并通过实际的系统开发和运行,得到了验证。

    参考文献
    [1] 孙锐,苗放。ActiveX 与服务器端对象级交互[J]。电脑编程技巧与维护,2008,第1 期
    [2] 宗薇,董占球。聚簇索引在数据库查询中的重要作用[J].微机发展,2000,(5):70-73
    [3] 尚展垒,陈慧,宋于伟。一种改进的查询优化技术——分裂大表[J].郑州轻工业学院学报(自然科学版),2002,(9):61-63
    [4] 科学信息离散分布规律的研究——从文献单元到内容单元的实证分析(Ⅵ):内容单元的齐夫分布[J].情报学报,1999,6
    [5] 蔡勉,卫宏儒。信息系统安全理论与技术。北京工业大学出版社

    作者简介:南开大学信息技术科学学院   袁振坤
    天津市南开太阳高技术有限公司  温遇华

更多

新闻投稿合作邮箱:yktchina-admin@163.com    字体[ ] [收藏] [进入论坛]

推荐文章

论坛热帖