后台数据库

2024-06-24

后台数据库（精选12篇）

后台数据库篇1

1 引言

网站后台主要是用于网站前台的管理与更新,如对网站的文字、图片、多媒体以及各项日常信息的发布与更新等操作,也是网站的数据库以及前台内容有效协调的保证。

传统的网站后台数据库开发方式主要由:在主程序中建立所需的数据连接,进行SQL(一种数据库语言)编程,录入数据,对数据库中的数据对象进行相应的查询、修改与删除等简单的操作。这种简单的开发模式,较适合于开发单一的数据库应用,或只能作为展示型的网站后台数据基础,无法应对综合性的网站后台系统的操作,比如商城网站系统的批量添加商品、进行商品的批量结算等。为了使这些问题得到有效的解决,就要运用现有的数据库语言,优化数据库与网站后台管理系统的连接机制,只有在保证网站后台数据库连接畅通的情况下,才能有效满足网站后台管理的高效性需求。

2 网站后台系统与数据库的连接形式

当前,国内的主流数据库主要有SQL Server和Access两种,在对网站后台进行编程之前就要解决数据库的选择问题。在互联网的实际应用中,大多数网站都是租用服务器商的虚拟主机,用以存储网站数据与文件。而服务器商的服务器一般分为PHP+My SQL型、ASP+Access型和ASP+SQL Server型等几种组合运行形势。在不考虑价格的情况下,本文将主要探讨应用SQL Server进行网站后台管理的技术分析。

2.1 ADO.NET下的网站后台编程技术与数据库连接分析

ADO.NET提供了对包括SQL Server在内的各种数据源及通过x ML与OLEDB公开的数据源的统一访问。数据共享者在对应用程序进行操作时,可以选择性的使用ADO.NET达到连接这些数据源的目的,并可以对其进行检索和更新操作。ADO.NET能够有效的将数据操作中的数据访问阶段分解为若干个可以进行一前一后或单独使用的非连续组件。ADO.NET还包含了用于连接至数据库、检索结果与执行程序命令的.NET Framework提供数据程序。使得用户可以通过数据库语言对检索结果进行直接处理,或者将结果存储至ADO.NET Dataset的对象中,用于来自不同源的数据或者在层次之间进行数据的远程组合处理,并以特有的形式呈现给用户。而ADO.NET Dataset对象又可以从.NET Framework数据中独立出来供程序单独使用,用以进行源自x ML的数据或者本地数据对应用程序的管理。图1所示介绍了ADO.NET与数据库的详细关系。

在ADO.NET中网站后台与数据库进行连接之后,为了保证两者的协调合作,就要在网站后台建立相应的数据库监控机制,运用SQL Server2000进行数据库的设计主要分为两种方式,一种是通过其自带的管理平台,另一种就是通过其查询分析器来运行SQL的脚本从而生成相应的数据库,本文采用后者设计(调用)监视数据库。在网站后台系统中使用ODBC的方式连接SQL Server的原理就是利用Windows操作系统本身自带的ODBC添加其自带数据源JKinfo,并采用以下代码建立连接。

2.2 Java下的网站后台与数据库的连接分析

Java在网站编程中与数据库的连接主要以JDBC(Java数据库连接)的形式实现,JDBC作为一种执行SQL语句的Java PI,能够为SQL Server提供统一的访问接口,其实现主要是由Java语言编写的接口与类组成。以Java为基础的网站后台系统在与SQL Server进行连接时往往根据的是连接池的原理,以及应用连接池的技术来具体实现。连接池的主要思想就是:通过使用相应的编程语言,建立一套连接分配、管理、使用策略,用以保证连接的安全性与高效性,同时避免对数据库的连接进行频繁的建立与关闭的开销。另一方面,因为一般要对JDBC中原始的连接进行封装,因此也提高了数据库对于连接的使用效率,同时隔离了数据库具体访问逻辑与数据库本身的处理逻辑,使得其对本身的复用变成可能。连接池主要由:连接池建立、对其中的连接的应用与管理、连接池关闭三个部分组成,如图2所示。

在实际的开发过程中,应用程序经常会需要访问若干个不同数据库,而通过同一连接池访问这些不同数据库,就是应用程序本身需要解决一个关键的问题。

首先,需要定义一个连接池的参数类,并对数据库的JDBC的驱动程序类进行定义,及URL连接等,此类主要用来对连接池的参数进行初始化:

然后是对连接池的工程类(Connection Facctory)进行处理,并通过此类将连接池的名称与其对象对应起来,从而使得用户可以通过此名称获取指定连接池的对象,核心代码如下:

2.3 数据库与网站后台编程语言连接的安全性分析

网站后台系统包括数据库在内是整个网站的核心之所在,在保证其有效连接的同时,还要对其安全性负责。本文主要以一个较为典型的PHP语言中session参数为例进行分析。网站后台的SQL脚本因为其本身的交互能力,为网站后台的正常运行乃至多种后台编程语言的协调作出了突出贡献。同时,session作为后台脚本的另一大亮点,对其进行灵活的掌握,并利用其进行参数的传递,能够在很大程度上提高网站后台的安全性能。下面是session的一个实例:

3 结束语

从上面的一个简单的变量传递的例子,可以看出数据库语言可以结合多用网站后台编程技术使用,并在不同的应用中产生不同的效果。采用数据库的脚本结合不同的网站编程语言达到对后台数据进行批处理,也将是一个新的发展契机。

摘要：数据库系统在整个动态Web站点中具有重要的支撑作用,网站的数据库系统主要伴随网站的后台而存在。本文主要是针对数据库在网站中的关键作用进行分析,探讨数据库对网站后台编程的影响因素,从而作出相关的编程技术分析,并以数据库设计为出发点,提出网站后台编程的相关优化建议。

关键词：数据库,网站后台,编程

参考文献

[1]安玉艳.Java编程中主流数据库连接技术[J].电脑编程技巧与维护,2010,(12).

[2]高伟,李爽,杜瑞庆.基与JDBC的SQL Server数据库访问[J].福建电脑,2008,(01).

[3]耿仲华.论PHP网站设计中信息安全防范措施[J].无线互联技术,2012,(08).

[4]邹蕾,张先锋.人工智能及其发展应用[J].信息网络安全,2012,(02):11-13.

[5]黄华军,王耀钧,姜丽清.网络钓鱼防御技术研究[J].信息网络安全,2012,(04):30-35.

后台数据库篇2

一、搜索引擎关键词

关键词在搜索结果的排名是我们优化人员所关心的问题之一。如果你的网站的主关键词是一个竞争非常大的的关键词，而且没有获得很好的排名，但是如果你的长尾关键词有好的排名的话，那么你的网站流量也不会因为主关键词排名不好而差到哪里去。那么第一我们需要如何知道哪些长尾关键词可以让你获得更多流量。此时我们可以通过CNZZ数据中关键词的数据来获悉哪些词可以给你带来想要的流量。你就可以选择一个合适的关键词进行相应的优化排名，来获得更高的流量。如下图所示，笔者的CNZZ后台数据通过下图中关键词的数据，我们可以发现到很多有用的长尾关键词。如果我们可以合理的利用这一些后台数据，那么它们会为你省去很多不必要的时间及精力。

二、从升降榜中的来路升降榜看流量的来源

我们在分析总结后台数据流量时，不能只是单方面的看到流量上升就满足于现状，看到流量下降就泄气，

不论网站流量是提高或者降低我们都应该进行全方面的分析，才能不断的改善我们的网站。流量上升，我们需要分析流量在哪个来源有所提高。流量降低，就要分析流量在哪里消失了，等等。这些才是提升网站的正确的方法。而CNZZ中的升降榜里的来路升降榜中的数据就是我们进行全方位分析的重要数据。我们可以通过这些数据来制定适合我们站点的推广方式。如下图所示，笔者网站的升降榜数据，从下图我们可以看出笔者的网站流量主要来源是在搜索引擎百度、谷歌，问答平台等等。我们可以利用这些数据进行分析总结。找到适合自己的推广方法。

三：用户的回头率数据

当我们在推广自己的网站的时候，不仅我们需要获得更多人的注意，更重要的是如何黏住这些人。只有这样才能保证我们的站点有一个稳定的流量及用户。如下图所示，笔者的网站回头率数据。我们可以看到在回头率中在一次访问中数量达到44.47%，回头率在十次回访(含十次以上)的访客数量就达到了 27.98%。有一个稳定的访客群使得笔者的网站推广能够在稳定中不断的前进。

数据分析笔者也认为是一项枯燥烦人的工作，但是优化离不开数据分析，只有一个合理的分析才能使网站有一个更加坚实的发展。

★ 大数据时代信息安全问题探讨论文

★ 不可忽视：谈网络防火墙和安全问题防火墙技术

★ Oracle技术题

★ Oracle笔试大观

★ oracle随机取数

★ 安全问题不容忽视作文

★ 忽视的近义词

★ 忽视的反义词

★ Oracle参数绑定性能实践

壹读有后台篇3

某日，@壹读在一个读者的微博里发现紫色火龙果，在下面弱弱留言，表示没有见过。第二天，一个神秘包裹降临办公室—该微博博主@微微viona航空快递了一箱紫色火龙果。于是，在这个月黑风高的傍晚，众同事刀叉似剑。壹读君表示他们真没出息，然后……不是就没有然后了，是没有火龙果了……这帮没出息的。

还没见过什么？

@超级无敌小胖：你应该说没娶过老婆。

那就不用你航空快递了，我上门取货。

@dorains：壹读君想吃臭豆腐了不？俺是北京的，送两坛王致和到府上咋样？

也行，不过我更想吃豆腐……等等，你的性别是？

@乖乖青田：我没见过苹果手机。

我犹豫了下，没敢这么说，因为本微博回复“来自iPhone客户端”……

@longyuqin：杂志办成这样，人品也太好了吧？！我能说没见过马尔代夫的蓝天白云海水之类的么壹读君……

哥已经从《麦兜故事》开始默默补课了，那里蓝天白云，椰林树影，水清沙幼……

只能叫您大爷了

@shine豆豆：在报刊亭买《壹读》，大叔示意在搁板下面。我遍寻不见，他只好出来取给我。我说：“这个杂志很好的，干吗藏起来不摆出来？”他说：“这杂志不摆出来也没关系，会有人问。”

这大叔，说您啥好呢，只能叫您大爷了。

@papa06：午饭后得空逛报摊买《壹读》。老板说：“就你一人买。”我愕然。老板接着说，这条街上的人的素质没高到看这杂志。我更加愕然。老板要为了我一人坚持卖。我告诉他坚持！

你要这么想：我是街头一哥，《壹读》的VVIP，报摊都是尊贵独享。

装×指南

@吾双Sophia：常戒戒微博，常读读《壹读》。也许不久的将来，手拿iPad和iPhone刷微博不再是装×的标准之一，手里拿本iRead才是。

装×？如果在＋－×÷里挑，我挑－……因为，我们是壹啊。

@久嘻嘻久等了：悲催地发现那里的闷骚和有趣在我这里基本都要延时体现，那是多么精准定位的读者群体间的相互调侃和说笑啊。

看来你的反射弧是26.6厘米……这是《壹读》杂志的长度。

我们

什么职业

因为加班，编辑部“正常”的下班时间是凌晨两三点。专题总监潘晓凌说，有一次被司机问：“小姐，你是做啥职业的？”新闻编辑莫静清安慰她说：“没关系，你再做多几年，司机看你三四点打车，就会问你：‘大媽，这么早出来买菜啊。’”

不识香蕉苹果

中午吃饭时食堂会有水果，某天是香蕉苹果。一同事看了说：“今天是梨啊。”过了一会，新闻编辑杨佳瑜也来了，有人提醒她今天有香蕉苹果吃，她拿了苹果后在水果堆旁转半天，“香蕉呢？”

相信楚方

内部会议……bla bla bla……副主编马昌博说：“我不信某某（某著名媒体人）没有绯闻，但我相信楚方没有。”专题总监潘晓凌接话说：“是的，绯闻是要有资本的。”众人笑。晓凌马上补充，“笑什么，我相信楚方有绯闻……”

后台数据库篇4

“军卫一号”系统是当前军队医院使用的主流医院管理信息系统,已经有10多年的历史,其后台采用的多为Oracle数据库系统。在系统建立之初使用的Oracle版本为Oracle7.1,该版本没有中文字符集,所以采用US7ASCII字符集存储中文信息。随着医院业务的不断发展,继续使用单字节ASCII编码,给医院信息系统的应用、开发与维护带来一系列问题,而Oracle公司在随后的版本中很快实现了多国语言的全球化支持。本文紧密结合“军卫一号”数据结构,深入研究字符集的特性,在实践中研究出一套字符集的转换方法,有效提高了“军卫一号”系统的规范性、安全性和可扩展性,为基于“军卫一号”数据库开发的各类新应用程序提供了可靠的数据保障。

2“军卫一号”字符集应用现状及弊端

“军卫一号”系统采用C/S架构,服务器端和客户端大多采用中文Windows平台(近年来部分医院已经先后将服务器平台迁移到UNIX平台上[1,2]),当客户端与服务器端采用相同的字符集时,应用系统不会出现任何问题。但是,随着数据库系统的日益庞大,新应用系统的不断开发使用,客户端数目的逐步增多,继续使用ASCII字符集带来了一系列的弊端和安全隐患,主要表现在以下几个方面:

(1)部署客户端需重新修改字符集环境变量。

由于客户端采用中文Windows系统,客户端字符集缺省环境变量为ZHS16GBK,需手工修改为ASCII字符集(一般都是采用修改注册表的方式进行)。在客户端数目日渐庞大的形势下,此项工作变得极为繁琐。

(2)在不同的应用系统间交换数据,兼容性差。

“军卫一号”系统已经与越来越多的系统进行数据交换(最典型的例子是医保程序)。这些系统基本都采用规范的中文编码,在与这些系统进行数据交换和对接过程中,字符集兼容性问题突出[3],增加了系统部署的工作量,且存在一定的安全隐患。

(3)开发基于Java的Web应用程序时,处理中文字符的复杂度增加。

基于Java的Web应用程序开发已经成为一种主流技术。Java语言在内部采用Unicode表示字符,在访问基于ASCII非中文编码的数据库时,都会有字符编码的转换,增加了编程的复杂度,且容易引起混淆[4]。

(4)采用EM管理器管理Oracle数据库难以处理中文字符。

在Oracle10g之后的版本中,Oracle提供了一个基于Web的EM管理器对数据库进行日常管理,极大地减轻了DBA的负担。然而,EM对采用ASCII码存储中文的数据库进行管理时,存在不兼容性,在Web页面中出现乱码,尽管互联网上提供了诸多补救措施,但方法比较繁琐,增加工作量。

因此,将“军卫一号”系统字符集转换为标准的中文字符编码,是当前医院DBA亟需解决的问题。

3 数据库字符集(服务器端)的转换

字符集是在安装数据库时选定的,一旦数据库创建之后,数据库的字符集是不能改变的。根据Oracle的官方说明,字符集的转换从子集到超集受支持,反之则不行。如果2种字符集不存在子集和超集的关系,字符集的转换是不受Oracle支持的[5]。但通常也可以在特定的条件下通过一些其他途径来完成字符集的转换。本文紧密结合“军卫一号”系统数据结构的特征,研究出针对性较强的从ASCII字符集到ZHS16GBK的转换方法。具体步骤如下:

3.1 准备工作

备份整个数据库,将数据库置于限制模式下(防止外部用户在转换过程中对其进行访问)

connect/as sysdba

shutdown immediate

startup mount

alter session set sql_trace=true;

alter system enable restricted session;

alter system set job_queue_processes=0;

alter system set aq_tm_processes=0;

alter database open;

3.2 字符集转换扫描

执行数据库字符集转换语句。命令如下:

alter database character set zhs16gbk;

此条命令会首先调用Oracle的字符集扫描工具Csscan,当转换条件都满足时才会执行真正的转换工作。因此,在“军卫一号”系统中首次执行该语句,将会报错而终止。

3.3 查看扫描结果日志

查看alert日志,看哪些具体的表含有clob字段。

3.4 备份特殊表

对含有club字段的表,进行exp导出,导出时注意将导出客户端的字符集环境变量更改为成ZHS16GBK(此步骤至关重要),这时Oracle会自动执行字符集的转换。

export nls_lang=american_america.zhs16gbk

exp′sys/lzck as sysdba′parfile=convert_exp.par

convert_exp.par的内容如下:

tables=SYS.METASTYLESHEET,SYS.WRI$_DBU_FEA-TURE_USAGE,

SYS.WRI$_DBU_FEATURE_METADATA,SYS.WRI$_DBU_HWM_METADATA,

SYS.WRH$_SQLTEXT,SYS.WRH$_SQL_PLAN,SYS.SCHEDULER$_EVENT_LOG,

SYS.WRI$_ADV_RATIONALE,SYS.RULE$,SYSMAN.MGMT_JOB_OUTPUT,

MDSYS.SDO_STYLES_TABLE,MDSYS.SDO_STYLES_TABLE,

MDSYS.SDO_COORD_OP_PARAM_VALS,MDSYS.SDO_XML_SCHEMAS,

MDSYS.SDO_GEOR_XMLSCHEMA_TABLE

file=convert_exp.dmp

log=convert_exp.log

在sys模式下创建这几个表的备份:

create table sdo_coord_op_param_vals as

select*from mdsys.sdo_coord_op_param_vals;

……

create table sdo_geor_xmlschema_table as

select*from mdsys.sdo_geor_xmlschema_table。

3.5 清空已备份的特殊表

使用truncate命令清空导出表中的数据;

truncate table sys.metastylesheet;

……

truncate table sysman.mgmt_job_output。

3.6 再次执行字符集转换扫描并执行转换工作

重新执行alter database character set zhs16gbk命令,如报错,返回步骤3.3,直至不再报错。

3.7 恢复清空的特殊表

重启数据库,将导出的表重新导入到数据库中。

imp′sys/lzck as sysdba′parfile=convert_imp_sys.par

imp′sys/lzck as sysdba′parfile=convert_imp_sysman.par

convert_imp_sys.par的内容如下:

fromuser=sys

touser=sys

tables=METASTYLESHEET,WRI$_DBU_FEATURE_US-AGE,

WRI$_DBU_FEATURE_METADATA,WRI$_DBU_HWM_METADATA,

WRH$_SQLTEXT,WRH$_SQL_PLAN,SCHEDULER$_EVENT_LOG,

WRI$_ADV_RATIONALE,RULE$

file=convert_exp.dmp

log=convert_imp_sys.log

ignore=y

convert_imp_sysman.par的内容如下:

fromuser=sysman

touser=sysman

tables=MGMT_JOB_OUTPUT

file=convert_exp.dmp

log=convert_imp_sysman.log

ignore=y

导入成功之后,即完成数据库的转换。

3.8 转换结束

取消数据库的限制模式,重启数据库,数据库字符集转换完毕。

4 客户端字符集更改

服务器端字符集更改后,还需要对已经设置为ASCII的客户端进行字符集修改。客户端修改字符集的方法较多[6],此处我们以修改注册表为例,简单介绍。

打开注册表编辑器(在命令行下键入regedit),依次打开HKEY_LOCAL_MACHINE→SOFTWARE→ORACLE→KEY_OraClient10g_home1路径,找到NLS_LANG,将其键值AME-RICAN_AMERICA.US7ACSII改为AMERICAN_AMERICA.ZH S16GBK。

保存后推出注册表编辑器,新字符集即刻生效。在实际应用中,由于客户端机器比较繁多,我们可以使用Windows主域控制器的域策略技术,将上述键值导出成1个Reg文件,将该文件放入域登陆脚本中,当客户端机器登陆医院域时,将自动导入新字符集的注册表键值,详细步骤这里不再赘述。

5 结束语

“军卫一号”后台数据库采用ASCII单字节字符集是一个历史问题,随着医院信息系统的日益庞大,采用这种编码带来了一系列的麻烦和问题。本文研究出了一种在“军卫一号”系统环境中数据库的字符集转换方法,使“军卫一号”数据库采用规范的中文编码ZHS16GBK来处理中文信息,提高了“军卫一号”系统的安全性、方便性和可扩展性,具有较强的推广意义。

参考文献

[1]张江涛,康雅斌,程冬梅.“军卫一号”数据库系统从Windows平台到Linux平台的移植[J].中国医院管理,2008,28(增刊):198-200.

[2]梁昌明,袁功智,秦占伟.Oracle数据库升级或迁移的方法探讨[J].医疗卫生准备,2008,29(1):35-37.

[3]刘长兴.字符集不同的Oracle数据库间交换数据的解决方法[J].中国医疗设备,2009,24(6):35-36.

[4]刘长生,谢强,丁秋林.Java应用中的汉字乱码问题分析[J].计算机技术与发展,2006,16(1):158-161.

[5]董玉梅,张亚南.Oracle数据库字符集问题解析[J].电脑知识与技术,2007(21):623-625.

后台朋友作文篇5

人有前台，也有后台。

有这样一个著名演员：

前台是大家都看得到的，光鲜亮丽，这一切都是因为事先的准备：费尽心思，化妆，穿衣，准备台词，端好架式，调匀呼吸，一步步踏出去，使出浑身解数：唱，五音不乱;说，字正腔圆;演，淋漓尽致。于是赢得满堂彩，名利双收。

然而，当他回到后台，脱戏服，卸妆彩，露出疲惫的脸部，后台是否有一个朋友在等他，和他说一句真心话，道一句辛苦了，或默默交换一个眼神，这个眼色，也许对我们来说要比前台的满堂彩重要，而且必要!

人有没有这样的朋友，很需要。后台的朋友，是心灵的休息地。

在后台朋友面前，你能够想怎样就怎样：不必化妆，不必穿戏服，不必作表情，不必端架子，可以说心里话，可以说泄气话，可以让他知道你很害怕，你很脆弱。每次出场前都很紧张，但是知道有一个后台朋友在默默的支持你，会忽然感觉一下有了一股勇气，勇敢的迈出去。

有这样一个真心朋友是幸福的，即使你在这个人面前没有出息，没有形象，甚至全身都是缺点，都可以暴露出来，这是很大的解放。当然解放过后，要重新拾起勇气，重新披上戏服、化妆、端起架子，走到前台去去扮演该扮演的，做一个人模人样的好演员，博得大家的一致好评，获得功成名就的利益。

但是，后台朋友并不是任何人都能找得到的，亲如夫妇，往往也不能成为“休息地”，

可见人无论生死，都很难找到后台朋友，因为他太珍贵了。

便携也有“后台” 篇6

看来车载导航后台服务已是大势所趋，由整车厂商推出的人机互动导航系统早就迈出了第一步，来自后装市场的专车专用“云导航”也屡见不鲜，但是将后台武装上身的便携式导航仪，我还真是一直没碰到过。最近拿到了华锋送测的e途X20便携机，它号称就配备了名为“E联星空”的后台服务，于是赶紧装车试一试。

便携式导航仪的最大优势还是安装方便随装随用，这台X20俨然就是一个小平板电脑，拥有7英寸的高清电阻屏（分辨率800×480），显示效果与专车专用的机型可有一拼。虽然面板挺大，但厚度适中，因此整机并不笨重，便携性还算不错。

X20预装了道道通正版地图，进入导航界面，感觉搜星还是蛮快，关于这些常规的导航性能我不再罗嗦了，直接来看看它的后台服务到底如何吧。

蓝牙技术巧妙应用

一听到“E联星空”，顾名思义，我以为它应该和目前主流的人机互动导航系统一样，也是采用内置3G网络电话卡来呼叫后台并接收服务，但事实上并没有那么复杂，根本不需要什么3G，利用简单的蓝牙传输技术它就实现了真人语音服务一键导航，这还真是挺巧妙的。

妙在哪里？只需要一台带有蓝牙功能的手机（现在还有不带蓝牙的手机吗？），将它与导航仪进行蓝牙匹配，并用该号码在“E联星空”上注册，就可以用这台手机来联系呼叫中心。注意到导航界面左下角那个客服人员模样的图标吗？点开它手机随即拨打呼叫中心的号码，接通人工座席之后你就能享受到远程服务了。

最核心的服务内容当然就是代为设定导航目的地，服务人员会根据你口述的目的地要求，从后台数据库当中找到准确的对应信息，那么问题来了，怎么将目的地信息数据（POI）传送到导航仪上呢？答案就是未接来电还有蓝牙。后台会将目的地信息编制成分别包含经度和纬度数据的2个手机号码，用该虚拟号码来拨打但不接通你的手机（有点像那些只响一声的骚扰电话），然后手机上这两个未接电话号码可通过蓝牙传送到导航仪上，目的地信息就这样到手了。试了几次，从结束后台通话到导航仪接收到目的地，基本只需要短短十几秒时间，确实是既方便又快捷。此外，多动口少动甚至不动手，用这样的方式来设置导航当然更利于驾驶安全。

离你更近的后台服务

用蓝牙而不是3G其实也更利于成本控制，最多你只要支付拨打呼叫中心的电话费，完全不用考虑什么通讯套餐数据流量。再有就是，剔除了并不见得实用的网络应用，回归到导航这一基本功能，我觉得也是好事。从呼叫中心的功能设置上，华锋还预留了诸如酒店预订、救援代驾、保险理赔等林林总总的服务项目。不管未来这些商业化开发到底如何，能够涉足后台服务，它就已经迈出了勇敢的一步。如此低消费就能享受到人工后台一键导航，面对这样的便携式导航仪你不动心吗？

后台数据库篇7

关键词：信息安全,风险评估,数据库

信息系统在安全方面存在问题和面临的威胁, 可以通过信息安全风险评估对信息系统进行安全管理。在展开信息安全风险评估, 对系统接触网络、企业信息系统的资产、价值、威胁、脆弱环节、以及发现威胁后采取的措施进行分析之后, 才能找到主要存在的安全问题, 并选取有效措施, 针对性地管理系统。

1 信息安全风险评估概念

信息安全风险评估采用定性、定量的分析方法和手段, 通过对其资产、信息系统进行概要分析后, 于存在有潜在威胁发生危害时, 提出对威胁级别相对应的安全保护措施和整改措施, 避免一些负面影响, 以减小损失。进行信息安全风险评估, 可以帮助企业了解信息系统的安全环境与其安全状况。进行信息安全风险评估有如下要素。

(1) 资产:具有价值的信息, 是策略所保护的对象。

(2) 资产价值:资产价值是进行资产识别主要内容, 它是描述资产的属性。用来判别资产重要程度或敏感程度。

(3) 可用性:被授权能访问数据的实体, 按照授权权限访问数据资源。

(4) 业务战略:组织为目标而制定的一组规则或要求。

(5) 信息安全风险:利用信息系统和其管理体系里存在的脆弱性导致安全事件的发生的人为或自然威胁。

(6) 机密性:数据不能向访问实体透露的程度。

(7) 信息系统:典型的信息系统是三个部分组成的:硬件系统、应用软件、系统软件。具体指由计算机、配套设备、设施构成的, 按照需求的应用目标、规则, 对信息进行采集、加工、存储、传输、检索处理的人机系统。

2 信息安全风险原理及流程

如图1、图2所示。

信息安全风险评估首先需要识别信息资产和任务。

(1) 判断安全事件发生的可能性:确定威胁及其出现频率, 识别脆弱性、并对脆弱性的严重程度赋值, 根据威胁及威胁利用脆弱性的难易程度, 最后综合判断安全事件发生的可能性。

(2) 计算安全事件所造成的损失:根据脆弱性的严重程度, 安全事件所作用的资产的价值, 用公式计算得到安全事件造成的损失。

(3) 计算风险值:根据安全事件发生的可能性和安全事件出现后的损失、计算安全事件一旦发生对组织的影响, 即风险值。

风险评估过程将会涉及到以下几个步骤:识别的资产评估, 确定的威胁以及相关问题和脆弱点, 评估风险, 建议对策。信息安全风险评估的完整的过程如图1所示。

计算出以上数据后, 计算安全事件的风险值R, 即:

风险值=R (A, T, V) =R (安全事件发生的可能性, 安全事件的损失) =R (L (T, V) , F (Ia, Va) )

其中, R表示风险计算函数, A表示资产, T表示威胁, V表示脆弱性, Ia表示安全事件所作用的资产价值, Va表示脆弱性严重程度, L表示威胁利用资产的脆弱性导致安全事件发生的可能性, F表示安全事件发生后造成的损失。

3 信息安全风险评估系统后台数据库设计

信息安全风险评估系统进行风险评定前, 由评估人员进行风险评估的准备, 将所做的准备报告交给领导, 当领导认可后开始风险评估。

首先, 对资产、所存威胁、脆弱性进行识别, 将所得数据输入后台数据库中, 然后根据数据库中的数据算出风险值, 将风险值存入数据库供专家分析, 最后得到本次风险评估报告, 递交风险评估负责领导。

本设计分为五个模块:前台登录模块、数据库修改模块、数据库查询模块、数据库备份模块、系统权限管理模块。

(1) 数据库修改:可以对资产信息进行增加、删除、修改等操作, 可以对威胁信息进行增加、删除、修改操作, 可以对脆弱性信息进行增加、删除、修改操作;

评估专家可以经过调查得到资产赋值、威胁频率赋值、脆弱性赋值并录入数据库。

(2) 数据库查询:对于制定权限的用户可以查看对应表格, 不可对数据库中的数据进行修改, 只允许进行“读”操作。

(3) 数据库备份/恢复:管理者可以将数据库进行数据的备份与恢复。

(4) 设计特点:该数据库具有便于录入, 方便查询, 使用简单的特点。如图2所示

本信息安全风险评估系统后台数据库本着操作简单、适用性强、效率高的原则, 实行人性化的设计思想, 有助于测试行业系统的安全性能, 帮助风险评估专家完成对行业信息安全的评估, 并采取相应安全措施保证系统的数据安全。

参考文献

[1]吴亚非, 李新友, 禄凯.信息安全风险评估[M].北京:清华大学出版社, 2007 (04) .

后台数据库篇8

一、业务对象声明

业务对象声明用于声明统计处理过程中使用的逻辑表、目录等业务相关的对象。

1、逻辑表声明

当设定数据存取方式为UPDATE时, 报表数据是可修改的, 不过此时系统会将报表的数据全部加载到内存中, 因此对于数据量很大的逻辑表, 不要使用UPDATE方式打开。当数据存取方式为NOUPDATE时, 报表数据不可修改。

2、目录声明

目录的起始点字符串可以指定多个离散的起始点, 以逗号分隔 (如"01, 05") , 也可以指定一个范围 (如"01:05"?表示代码起点从01开始到05结束) 。当指定目录的层号时, 目录的起始点必须在同一层。声明目录时, 对于数据量很大的目录, 不要使用UPDATE方式打开。目录的过滤条件表达式可以用以限制目录数据加载的范围。

二、逻辑表关联定义

1、调查对象内关联

如果两个逻辑表属于同一个调查对象, 则这两个逻辑表可以直接通过add Join来进行关联:

2、调查对象间关联

如果需要跨调查对象关联两个基层表, 可通过relation来进行关联:

定义了跨调查对象的关联之后, 在遍历数据时, 可以通过relation DATA来访问调查对象2的逻辑表数据。

三、遍历逻辑表数据

对于逻辑表数据, 可以直接通过一个for循环来遍历。对于NOUPDATE方式打开表, 数据将会遍历的同时从数据库中获取, 而对于UPDATE方式打开表时, 数据将会在遍历之前一次全部从数据库中复制到内存中。

四、执行业务处理

执行业务处理主要是指针对遍历的逻辑表数据进行审核、汇总、计算等业务逻辑操作。

1、审核

2、汇总

3、计算

首先对需要更新的报表声明为可更新 (UPDATE) 状态, 然后在遍历报表数据时, 根据需要进行计算, 同时将计算结果直接赋给可更新表的相应指标即可。

五、保存结果

业务操作语句执行之后, 通常其结果是保存在一个临时的记录集 (dataset) 中。因此, 在遍历逻辑表数据、执行业务操作语句之后, 需要将业务操作的结果保存到数据库中。

1、审核错误信息记录集通过store Audit Error () 方法保存到数据库的审核错误信息表中。

2、汇总的结果也是在执行汇总语句时保存在一个临时数据集中的, 遍历所有单位完成汇总后, 需要将临时数据集中的数据回填到汇总表对应的字段中, 以便保存汇总结果。

3、计算

执行数据计算时, 由于在遍历数据的同时已经将计算值赋给了要更新的逻辑表, 因此, 只需调用store () 方法保存逻辑表数据即可

摘要：APRAS作为统计系统内部的数据处理软件在第二次全国农业普查及其它日常应用中起着非常重要的作用。其审核、汇总、计算等功能均是通过后台公式实现。

参考文献

后台数据库篇9

对于基于Web的高校项目申报系统而言, 系统后台数据库的设计与构建决定了后台数据的完整性、易维护性和可操作性。因此, 对于系统后台数据库的论证与设计, 在系统开发过程中具有重要的现实意义。

1 需求分析

1.1 系统功能分析。

基于Web的高校项目申报系统, 其主要功能如图1所示。新用户注册和项目申报模块主要面向项目申请人, 项目申请人通过这两个模块完成身份注册、认证, 以及项目申报。项目审核模块主要面向专家, 专家通过此模块来审核已申报的项目。其余模块主要面向管理员, 管理员通过这些模块来完成项目的管理与维护, 用户和管理员信息的管理与维护, 管理员权限的设定, 后台数据库的维护, 以及系统参数的设定等功能。

1.2 用户需求分析。

基于Web的高校项目申报系统根据其功能设定, 主要分为项目申请人、专家、管理员三类用户。这三类用户有各自的权限范围, 并且互不干涉, 但管理员的权限可通过权限管理模块调节。

2 概念结构设计

2.1 数据需求。

基于Web的高校项目申报系统的数据需求如下: (1) 项目申请人通过其user_id来标识。项目申请人可同某个项目发生联系, 该项目作为项目申请人所申请的项目。 (2) 项目审核专家通过其expert_id来标识。专家可同某几个项目发生联系, 这些项目作为专家的审核项目。 (3) 项目通过project_id来标识。每一个项目既同项目申请人发生联系, 也同项目审核专家发生联系。 (4) 管理员通过admin_id来标识。管理员根据权限的不同可与项目申请人、项目审核专家、项目、系统属性状态集分别发生联系, 也可同时发生联系。 (5) 系统属性状态集有且只有一条记录, 其所包含的字段记录着系统的基本属性与状态。系统属性状态集只与分配系统管理权限的管理员发生联系。

2.2 E-R模型设计。

实体-联系 (entity-rela-tionship, E-R) 数据模型是一种语义模型, 它可以将现实世界的含义和相互关系转换成数据库的概念模型, 因此有助于数据库设计。

2.2.1 实体集及其属性。

基于Web的高校项目申报系统实体集及其属性分为以下几部分: (1) 实体集项目申请人, 具有user_id、login_name、login_password、name等属性。 (2) 实体集项目审核专家, 具有expert_id、login_name、login_password、name等属性。 (3) 实体集项目, 具有project_id、project_name、application_date等属性。 (4) 实体集管理员, 具有admin_id、login_name、login_password、permissions等属性。 (5) 实体集系统属性状态, 具有allow_user_login、count_per_page、auditing_date等属性。 (6) 实体集权限分类, 具有permission_id、permission_name等属性。

2.2.2 联系集。

基于Web的高校项目申报系统中的联系集分为以下几部分: (1) 申报, 是项目申请人和项目之间一对一的联系集, 表明一个项目申请人只能申请一个项目。 (2) 审核, 是项目审核专家和项目之间一对多的联系集, 表明一个专家可以审核多个项目, 一个项目只能被一个专家审核。 (3) 项目管理, 是管理员和项目之间的多对多联系集, 表明一个管理员可以管理多个项目, 一个项目可被多个管理员管理。 (4) 项目申请人管理, 是管理员和项目申请人之间多对多的联系集, 表明一个管理员可以管理多个项目申请人的信息, 一个项目申请人的信息可以被多个管理员管理。 (5) 项目审核专家管理, 是管理员和项目审核专家之间多对多的联系集, 表明一个管理员可以管理多个项目审核专家的信息, 一个项目审核专家的信息可以被多个管理员管理。 (6) 设置, 是管理员和系统属性状态之间多对一的联系集, 表明系统的属性状态可以由多个管理设置。 (7) 拥有, 是管理员和权限分类之间多对多的联系集, 表明一个权限可以被多个管理员所拥有, 一个管理员可以拥有多个权限。

2.2.3 E-R模型。

基于Web的高校项目申报系统E-R模型如图2所示, 为了简单直观, 图2中将省略实体集的属性。

3 逻辑结构设计

3.1 E-R模型向关系模型转换。

3.1.1 实体集的转换。

实体集向关系模型的转换, 其转换过程如下:每个实体集对应着一个关系模式, 实体集的主码就是关系模式的主码, 实体集的属性就是关系模式的字段。比如实体集项目申请人, 它有user_id、login_name等属性, 其中user_id是主码, 那么对于关系模式项目申请人而言user_id便是它的主码, 实体集项目申请人中所有属性便是关系模式项目申请人的字段。

3.1.2 联系集的转换。

联系集向关系模型转换分为以下几种情况: (1) 对于一对一的二元联系集, 相关联的两个实体集中任意一个实体集的主码均可以作为联系的主码。比如联系集申报是实体集项目申请人和项目之间一对一的联系, 那么关系申报的主码既可以是user_id, 也可以是project_id。 (2) 对于一对多的二元联系集, "多"的一方实体集的主码作为转换后关系模式的主码。比如联系集审核是实体集项目审核专家和项目之间一对多的联系, 那么关系审核的主码为实体集项目的主码project_id。 (3) 对于多对多的二元联系集, 主码应该是相关联的两个实体集主码的并集。比如联系集拥有是实体集管理员和权限分类之间多对多的联系, 那么关系拥有的主码为实体集管理员和权限分类主码的并集 (admin_id, permission_id) 。

3.2 表的规范化。

对于转换完毕后的关系表还要进行规范化, 规范化的目的是通过校验调整表的结构, 来使表中数据冗余最小化, 从而消除数据的不一致性的过程。

4 结论

针对基于Web的高校项目申报系统, 介绍了其后台数据库的设计方法及构建过程, 给出了E-R模型, 并完成了E-R模型向关系模型的转换, 最终完成了本系统的后台数据库设计。

参考文献

[1]杨睿娜.数据库设计过程中E-R图向关系模型的转换[J].硅谷, 2009 (11) :28-44.

[2]盛锐, 韵湘.基于Power Designer的数据库设计与实现[J].电脑应用技术, 2006 (66) :1-5.

后台数据库篇10

教学成果的检验往往要通过考试来完成, 可是, 目前, 我们一般的命题过程是这样的:制定考试大纲和试题编写原则, 向有教学经验和命题经验的教师或命题专家征集题目, 通过小规模的试测获取关于题目和试卷的统计数据, 然后从质和量两方面的角度对题目和由题目组成的试卷进行分析、判断和调整, 之后再以这套试卷施测于考生对象。这种命题过程存在着大量人力财力浪费的问题, 不仅组卷困难, 阅卷量很大, 后续工作繁杂, 试卷不易永久地保存, 成绩查阅困难且不能及时地反馈, 而且不能保证出题的科学性。随着网络技术的发展与普及, 迫切需要有科学、方便、完善的题库系统, 作为积累题目、自动组卷、保存成卷、分析试卷的利器。这里的关键就是题库系统的设计, 也就是说, 实现无纸答题, 用户通过注册和身份验证后可以进入模块后选择题型, 进入相应的测试模块。单项选择题可用鼠标直接点击相应的选项进行选择;多项选择题用鼠标点击复选框进行多个答案的选择;判断题和单选题类似;填空题和论述题可以在文本框中输入答案。完成 (未完成) 所有的习题后可以交卷, 系统会自动判断答题情况 (对、错和未做的题数) 。在交卷前, 用户可进行答案的修改, 交卷后只能查看每题的正确答案和答题情况而不能再进行答题或修改答案。

因此, 根据以上调研了解, 该系统的功能可归纳为:

题库模块应有用户登陆、注册验证功能。同时, 系统应具有为用户随机抽题组卷的功能。多媒体题库也必须具有即时提交试卷, 即时判卷、计时计分和保存用户做题信息等功能。题库类型应具有单选、多选、判断等题型。系统维护模块完成题库的维护, 如追加、删除、修改、检索等。不仅可以提高教学效率, 而且可以更大范围地使高校的教学资源得到共享。

2 开发工具

数据库选用Sql (Structured Query Language) Server 2000, 它是一种关系型网络数据库, 也可做为单机版数据库开发工具。它一大特点是易操作性、易应用性, 有数据库基本知识的初学者都可以进行简单的操作。它是企业进行大量数据存储、检索、更新的重要系统。它担负着企业内部重要数据的处理, 具有用户喜欢的易用性、适合分布式组织的可伸缩性、用于决策支持的数据仓库、与许多其他服务器软件紧密关联的集成性等优良的性能。对于查询处理、信息发送、数据转移和与Internet集成等功能有很大增强。

页面采用ASP (Active Server Page) 是微软开发的一项新技术.Active Server Page (ASP, 活动服务器页) 代表了微软开发技术的一个新方向, 它是服务器端的脚本编写环境.使用ASP可以组合HTML页、脚本命令 (如VBScript, Java Script) 和Active X组件以创建交互的Web页和基于Web的功能强大的应用程序.运用ASP方法, 浏览器可以引用服务器上的一个ASP文件, 执行它的脚本, 并将ASP执行结果以常规的HTML标记返回给浏览器.由于脚本在服务器而不是在客户端运行, 传送到浏览器上的Web页是在Web服务器上生成的, 故不必担心浏览器能否处理脚本。

3 系统设计

3.1 题库数据流图。按照系统规划所确定的目标。根据在需求分析中题库系统所具有的功能, 具体归纳如下:3.1.1题库系统应有用户登陆、注册、验证功能。3.1.2题库系统应具有为用户随机抽题组卷的功能。3.1.3题库系统也必须具有即时提交试卷, 即时判卷、即时计分、查分数成绩和保存用户做题信息的功能。3.1.4题库系统试题类型应具有单选、多选、判断。3.1.5题库系统维护模块完成题库的维护, 如追加、删除、修改、检索等结合以上题库系统的系统需求和功能, 系统的数据流图如图1所示:

3.2. 数据库E-R图 (部分) 。系统数据库E-R图, 如图2所示。

3.3 流程图, 如图3所示。

4 界面设计 (部分)

4.1 页面设计。4.1.1登录页面设计。

运行结果如图4所示

以上就是该系统的全部设计, 而且运行全部通过。

参考文献

[1]刘勇, 周学军..SQL Server2000基础教程[M].北京:清华大学出版社, 2005, 7.

壹读有后台篇11

过年回家，你会被各种婆婆妈妈的问题纠缠，但是也只有在家里，你可以再一次坐在旧沙发上跟妈妈聊天，陪老了的爸爸喝一杯酒，在老街跟老同学闲逛，看看过去的痕迹又消失了多少，然后整顿一下精神，准备重新上路。马解了鞍，船靠了港，再出发就不会怕路远。

火车票难买，开车回家的，请尽可能捎上顺路的朋友，坐飞机的跟邻座说说话，保不齐一路下来就变成了女朋友或男朋友，直接带回家给爸妈欢喜去。总之，祝归途平安，新年快乐。

评壹读微博：《甄嬛传》美国版的神翻译

榕树夏日记：流朱该作何解释？flowing pig？streaming red？实初哥哥呢，又当如何？real first Warm？

你知道国内有部神剧叫《抗日奇侠》，英文名是《Anti-fucked Men》吗？

评壹读微博：“堆雪人防洪水”（媒体报道，英国建议民众将积雪堆成雪人，以减缓雪融化的速度，防止住宅被淹。）

空空追梦：哦，原来复活节岛群像是古人为了防止泥石流。

李晓乐Rossiey：哦，原来兵马俑是秦始皇为了防止地震。

秦始皇铸十二铜人，为了防止老百姓有武器。你们的例子弱爆了。

评壹读微博：“京城‘毒’雾缭绕，似城中仙境”

禾草M：让背着大包连滚带爬去峨眉看云海的人羡慕忌妒恨吧。

冬天看云，春天看敦煌，夏天看海，京城果然什么都不缺。

評壹读微博：《壹读》是“厕所最佳读物”

烟霞深处苍苔冷：两个时段读书最投入，一如厕，二听会。

所以痔疮是学问之友？

评第13期生活版“作业本”栏目（一位小学六年级同学如何吐槽自己班上官气十足的班长）

WitherlessRose：00后精通人际关系的处理。世事洞明，人情练达。以后必将是我等80后的心腹大患。

建议80后努力制造10后以求逆袭吧，风物长宜放眼量。

评第13期封面故事之《开始学车前，先把驾照考了》

混吃活自在：记得考试的时候，还得喊报告，某某驾校，某某学员，准备完毕，请求起步……

我喊过：报告考官，某某驾校，某某学员准备完毕，请求起飞……过一会儿是：离合踩踏正常，刹车制动正常，方向盘转向正常，大灯闪烁正常，雨刷摇摆正常……轮胎与地面分离，轮胎与地面分离……

我们

心疼

专题记者康雯萱和文化编辑靳锦去东南亚旅游。去某地，车船得两天多，坐飞机只要1个小时，但机票190美金一点也不便宜。靳锦一会儿心疼自己，一会儿心疼钱，最后决定还是心疼自己一点，掏出信用卡买了机票。康雯萱既心疼自己又心疼钱，于是她摸出靳锦的信用卡给自己买了机票……

虫它与虫他

“蛇字怎么写？”市场总监于淼问。“一个虫和一个它。”新媒体编辑黄晞答。于淼比划半天，问：“可是怎么看起来这么别扭？”坐她旁边的市场经理程天晓瞄了一眼，发现她写的是“虫他”……

（编者注：这是真事，已经确认过了。）

论摄影

文化记者苏更生购入新相机后，把玩数月，得相片若干，向专题记者吴久久讨教技术。久久审阅照片后，说：“技术咱就不说了，照片还是很有意义。”苏大喜，追问意义何在。他沉思片刻，说：“你得了老年痴呆之后，它们可以提醒你当时在什么地方，做了什么。”

我们错了

因编辑疏忽，第12 期P143 娱乐版“头牌”栏目《成龙：关于出手，全部的人生》，第一段的成龙电影《师弟计划》应为《师弟出马》。

因编辑疏忽，第12 期P09“我就壹说”栏目《我想拍电影》一文最后一段，“以至于连也我想……”表达有误，应为“以至于连我也想……”。

后台数据库篇12

随着联通移动网客户群的快速增长, 客户业务资料的准确度成为向客户提供优质服务的关键。当客户通过营业厅等前台受理方式提出移动网业务请求时, 联通通过BSS营帐系统将客户需求送至后台交换机等网元设备, 实现客户业务的开通、变更或注销。前后台客户业务数据密切相关, 前台接受客户订单, 后台实现业务功能, 二者理论上应该一致, 但由于各种因素影响, 实际上会有所差异, 以至影响了对客户的正常服务。为提高移动网客户服务支撑质量, 中国联通威海市分公司着手定期对移动网BSS营帐系统与HLR设备内的炫铃、来显等业务数据进行稽核整改, 从而有效提高了移动核心网前后台客户业务数据的准确率。

2 客户前后台业务数据不一致的原因

在处理10010投诉时, 发现部分移动网客户投诉是由于前后台炫铃、来显业务数据存在差异所引发。只有提高前后台业务数据的一致性, 才能减少此类投诉。鉴于此, 需要定期对移动网后台交换机内客户业务数据与BSS营帐客户资料进行认真比对, 找出差错根源, 采取有效措施进行处理。

首先看一下客户业务的生成过程, 如图1所示。

移动网客户可以通过营业厅、代理商、客户经理、10010、互联网等接入方式提出移动网业务需求, 前台BSS营帐系统负责将客户申请业务转化为综合联机指令, 自动发往后台各类业务的客户认证管理平台, 实现客户业务需求在后台网元设备内的开通、变更或注销。

对2009年第一季度移动网交换机内客户业务数据与移动网BSS营帐系统客户资料进行比对, 发现差错主要集中在炫铃、来电显示两项业务上, 其它业务所占比例较小。检查落实后, 发现炫铃业务差异突增集中在3月份地市分公司炫铃业务整合至省炫铃平台过程中, 本地移动HLR客户数据库内部分手机炫铃体验客户未同步撤除, 导致与BSS系统出现较大差异。若能解决炫铃业务差错问题, 就可以明显提高业务准确率。

前台BSS与后台HLR等网络设备业务数据发生差异一般有三种表现方式: (1) 前台BSS有, 后台HLR无; (2) 前台BSS无, 后台HLR有; (3) 前台BSS、后台HLR都有, 但实现功能有差异。从客户业务实现流程看, 导致上述差异的原因可能出现在BSS系统内、HLR等网络设备中, 也可能出现在二者接口部分。

由于现在联通移动网客户的集团炫铃和个性化炫铃业务在HLR交换机内的业务签约参数值相同, 所以第 (3) 种情况基本不存在。

下面主要从 (1) 、 (2) 两方面分析可能导致炫铃业务差错的末端因素, 如图2所示。

2.1 移动网客户业务数据前台BSS有, 后台HLR无

(1) 接口设备运行异常

BSS系统至HLR设备的接口部分, 如DCN网路由器设备异常、接口线路劣化丢包等, 易导致BSS自动工单指令未正常发送至HLR设备。经测试, 此类故障情况较少。

(2) 移动网HLR设备问题

1) 移网HLR设备数据库割接情况

HLR设备割接等变动较大的数据库操作易引起数据不一致。检查近期HLR设备割接情况, 2009年初移动网2/3G网络整合期间将HLR设备机型从北电替换为华为设备时, 曾进行过全网移动客户数据库割接调整。但割接前后对二者客户数据库进行了严格比对, 可以确保入网客户数据一致, 不存在数据丢失问题。

2) 移网HLR设备存储数据库板卡故障

利用华为诊断软件对移动网HLR设备的主备数据库板卡硬件进行逐个诊断测试, 结果表明, HLR设备的每块数据库板卡均可正常工作。

(3) 客户个人行为因素

1) 客户自愿取消套餐中炫铃业务

现实中有客户个人行为对业务产生影响的案例。如某些客户不想听炫铃, 拨打10010要求保留炫铃业务套餐、但取消后台交换机内业务功能。话务员接到此类需求后, 会要求后台取消业务功能。对10010人员进行现场访问并调用录音内容, 确认客服人员曾向机房转派此类客户需求。

2) 因为客户国际漫游, 需要临时取消或恢复炫铃业务

客户国际漫游时, 部分漫游国家可能不支持联通所提供炫铃功能, 所以客户出国前一般会申请临时取消炫铃功能;但回国后可能忘记恢复后台功能, 导致前后台数据不一致。由于炫铃功能存在业务使用费, 所以该业务取消和恢复无法经过前台营帐BSS系统受理渠道解决。为此, 前台市场部门一般会要求后台人工临时取消业务功能。对市场部门进行现场访谈, 确认存在此种情况。

(4) 营帐工单出错, 手工处理失误

由于营帐自动工单意外出错, 需要后台维护人员根据营帐BSS工单的客户业务需求, 从后台HLR设备对相应客户数据进行修改。维护人员手工处理失误, 未正确调整相应业务。

(5) 测试数据

维护人员根据市场需求在BSS系统中进行某种新业务测试 (注:未正式向HLR设备发送自动工单) , 测试完毕后却未及时撤除。

2.2 移动网客户业务数据前台BSS无, 后台HLR有

(1) 历史原因, 营帐资料不全

由于历史问题, 最初客户资料采用纸质保存, 手工书写内容可能不完整。在创建BSS营帐电子系统数据库、将纸质资料转为电子档导入营帐系统时, 存在导入数据不完整情况。

(2) 新旧炫铃平台割接遗留问题

1) 因割接时间差导致提前采集的旧炫铃平台客户资料与割接前旧平台实时数据有偏差。提取割接前后时间差内营帐工单, 比对BSS营帐库及后台HLR设备内的相关客户数据, 可以得到存在业务差异的客户资料。

2) 割接时只完成了新炫铃平台与BSS系统间的数据同步, 未进行BSS系统与HLR设备同步, 导致新炫铃平台与BSS系统、HLR设备的三方数据不一致。提取BSS系统和HLR设备全量客户数据进行比对, 可以找出存在差异的客户资料。

(3) 客户临时业务需求变更

根据客户紧急需求, 客户经理电话通知后台维护人员先更改后台HLR交换机数据再补办受理单。若客户经理未及时补办工单, 则会产生前后台不一致问题。提取此类场景下的后台手工制作记录, 核查前台营帐系统是否存在对应的客户资料。经检查, 确实存在客户经理提出业务变更需求、但BSS营帐系统未及时更新客户资料的情况。

(4) BSS系统问题

BSS营帐系统运行异常, 可能损坏BSS系统客户数据库。观察BSS系统小型机告警日志, 此类故障情况较少。

(5) 测试数据

维护人员根据市场需求在HLR设备中进行某种新业务测试 (注:未正式进行营业受理) , 测试完毕后却未及时撤除。

3 降低前后台移动客户数据库差异的措施

综上, 可以看出客户个人行为、炫铃平台割接、历史遗留问题、客户经理特殊需求等是导致前后台业务数据出现差异的主要原因。可以从定期比对、分步整改、流程管理、技术培训等方面采取措施进行优化整改。

3.1 前后台移动网客户数据库比对整改

为解决新旧炫铃平台割接遗留问题和历史原因营帐资料问题, 保证BSS系统和HLR平台内的客户资料一致, 公司维护部门与信息化支撑部门制订了《移动网交换机和BSS系统内用户数据核对规范》, 规定了每月双方必须核对的增值业务和补充业务种类。

下面主要介绍炫铃业务整改的实施步骤:

(1) 数据比对:预先对移动网BSS系统和HLR交换机内各类客户业务对应的参数配置、批量客户数据提取方法进行充分了解, 定期提取两个系统中客户数据库的全量资料, 利用数据库工具完成炫铃等选定业务数据的全面比对, 找出不一致的移动客户号码信息。

(2) 数据核实:确定由10010外呼中心协助落实差异客户资料的可行性方案, 并规定了核对反馈时限。同时要求社区客户经理配合完成相关确认工作。

(3) 数据修正:对落实清楚、需要整改的客户业务资料进行及时调整更新。

对于经10010外呼、客户确认需整改的客户业务, 在一个工作日内再次提交信息化支撑中心和网管设备中心进行二次核对, 确认无误后通过流程调度整改。对HLR系统中的不一致部分, 单个客户调整可由10010提交“业务响应”工单至维护部门做手工调整;批量客户变更, 需由市场部下发“业务协调流程”至维护单位机房进行统一整改。对BSS系统中的不一致部分, 由信息化支撑中心负责整改系统库资料。考虑到资料变动可能会引起的客户投诉, 由市场部负责统一制定解释口径, 并将有变动的客户资料和解释口径通知客服部门。

(4) 定期稽核:每月定期进行前后台客户业务资料的全量核对以保持整改效果。并且, 今后在实施炫铃等增值业务平台割接过程中, 加强业务平台、BSS系统和HLR设备的数据同步、一致性检查验证, 有效避免此类数据差异的产生。

3.2 利用流程管理规范手工工单

为利用流程实现对客户紧急业务需求手工工单的闭环管理, 确保业务办理经过正常的审批、执行、复核等环节, 维护部门协调市场部门下发《关于建立客户经理绿色通道的通知》, 明确:当客户经理提出临时紧急业务需求时, 不能仅通过电话交流决定, 而应发起“业务响应”流程, 流转至机房后再执行手工完成业务调整;当月有效时间内要补办营帐受理单。若后台发现客户经理未及时补办受理单, 维护人员可通过业务响应流程进行退单处理。

3.3 加强维护人员培训

(1) 培训:由BSS营帐系统专家、HLR设备维护专家分别对维护人员进行集中培训, 学习掌握移动网的业务受理、开通、销户等知识、技能。

(2) 考试:定期对维护人员进行移动网客户数据操作技能考试。

4 效果分析和巩固措施

经过整治, 2010年威海联通移动网炫铃业务的前后台一致性明显提高。

(1) 显性效益

对移动网前后台客户业务资料进行定期比对整改, 减少了客户业务差错率, 避免了因业务设置失当可能给企业带来的经济损失, 降低了企业风险;而且, 联动作业增强了后台运行维护、信息化支撑与前台市场、营业和客服等多部门的协作能力, 树立了企业形象。

(2) 隐性效益

从对比数据看, 2010年移动网由于客户业务数据差错引起的营业、10010客服投诉次数比去年同期减少21次, 有效保障了客户业务的正常使用, 同时减轻了营业和10010台客服人员的工作压力。

(3) 巩固措施

公司对工作成果进行了总结, 制订、修改了一系列管理规定, 如表1所示。

5 结束语