校园“一卡通”信息系统数据库设计刍议

文章出处：http://www.nexussmartsolutions.com 作者：佚名 人气： 发表时间：2007年11月30日

校园“一卡通” 系统是集多种功能于一 体的综合性消费与管理系统，它为构建数字化大学提供了全面的数据采集平台，是数字化校园的基础工程。所谓“一卡通” 就是每一个用户可使用一张卡，在多种不同功能的管理中使用。校园“一卡通”系统，就是集个人证件、住宿管理、餐饮消费、学籍考试、图书借阅、购物消费、医疗服务等功能干一体的综合性消费与管理系统。它结合目前大多数大学现有的管理信息系统和网络，进一步形成了全校范围的数字空间和共享环境，真正实现了“一卡在手，走遍校园”。它为构建数字化大学提供了全面的数据采集平台，是数字化校园的基础工程，是数字化校园中有机的、重要的组成部分。

1 使用“一卡一库”设计方法的特点

据笔者考察， 目前高校使用的“一卡通” 系统数据库大多采用传统的数据库设计 方法，即将“一卡通” 系统所有数据集中 在一起的模式下进行设计(也就是所有的功 能模块均使用一个数据库)。使用这种“一库” 设计方法的优点是：

(1)各类数据容易共享
(2)数据一致性容易保证
(3)数据检索方便

但由于“一卡通” 系统功能模块很多， 其中很多模块性质、属性不尽相同，从而导 致使用“一库”设计方法在实际运用中暴露出很多问题：

随着高校规模的不断扩大，使用“一库”设计方法不便于进行系统的应用升级与扩充。这是因为，“一卡通” 系统是一个不断创新与升级的系统，根据学校需求和软硬件相关技术的发展，“一卡通”系统将会有新的应用加 入和老的应用的升级。一般情况下，“一卡通” 系统的数据库需要作相应的变动与升级，由此造成“一卡通”系统数据的兼容性、一致性 独立性等问题将是非常突出，特别是针对一 个运行比较久且较大型的“一卡通”系统，庞 大的数据量将使得系统升级与改动成本增高。

目前大多数高校使用的各应用子系统都 不是同一家公司研发的，软硬件各自不同， 其后台数据库不可能都集成在“一卡通” 系统数据库中。但他们都使用同一张卡作为身 份识别与计费的媒介。因此它与“一卡通” 系统数据库之间需要一定的信息交换(如： 卡的开户、挂失、注销、补卡等信息)。可以想象，在执行数据修改、更新等操作时， 必将会出现操作与数据库不同步的情况，必然导致人力、物力的无谓消耗。

由于库的不断扩大，各表的相互制约势 必增加，其使用效率必将受到影响，尤其是 某些条件下需要系统能够实时处理用户需求， 在此情况下，“一卡多库” 的设计方法势必 影响到学生的正常学习生活。

笔者在考虑上述各种因素基础之上，认 为可以采用建立“一卡多库” 的设计方法来解决“一卡一库” 带来的使用不便。