后台数据系统

2024-06-08

后台数据系统（共7篇）

后台数据系统篇1

摘要：随着信息时代的迅速发展, 社会发展对信息资源的依赖程度越来越高。信息安全风险评估系统作为能帮助了解信息系统安全现状的平台, 对其后台数据库的功能也有着严格的要求, 因此研究信息安全风险评估系统后台数据库, 确保其安全性也显得至关重要。本文主要通过信息安全风险评估系统, 研究并设计出信息安全风险评估系统的后台数据库。

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

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

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) .

[2]范红, 冯登国, 吴亚非.信息安全风险评估方法与应用[M].北京:清华大学出版社, 2006.

后台数据系统篇2

近年来, 我院医疗规模不断扩大, 医疗收入不断提高, 这就对医院管理水平和管理模式提出了更高的要求。医院管理者希望能对医院业绩进行客观、公正的评价, 因此提出从“军卫一号”HIS中抽取医院绩效评价数据, 依据医疗工作分配权重, 制定考核标准[1]。“军卫一号”是在全军医院应用良好的医院信息管理系统, 而基于其研发的军队医院绩效考评系统, 不仅是医院日常业务管理数字化和科学化的内在需求[2,3,4,5,6], 也是提升医院管理手段的保障。本文讨论了基于“军卫一号”HIS的医院绩效考评系统的模块设计和后台数据库实现方案。

1 系统模块设计开发

为了能够充分利用在军队医院广泛应用的“军卫一号”HIS, 开发一套有效且实用的绩效考核系统, 为医院管理者的管理、决策提供科学参考依据, 本系统在设计时采用瀑布模型, 严格遵循预先计划的需求分析、设计、编码、集成、测试和维护的步骤进行[7]。整个系统采用B/S和C/S架构混合模式:对于用户管理、数据库底层访问、删除和修改历史数据等涉及系统安全性和可靠性的模块采用C/S方式开发, 即通过设计不同的用户级别来实现差别式数据访问;对于与业务数据相关的评价指标数据录入、获取、浏览查询采用B/S模式, 这样既方便了系统的部署, 也节约了安装配置成本。数据层采用Oracle数据库平台, 应用服务层和客户应用程序采用Visual Studio2008开发的程序。考核指标以《军队三级综合医院等级评审标准和细则 (试行) 》为指导, 并结合我院临床和管理经验, 体现了指标的科学性。基于需求分析, 我们设计了系统功能和具体模块, 依据开发的实际需求情况, 又设定了开发优先级, 见表1。

所有功能模块中, 最核心的部分是考核方案和考评评分系统2大功能模块的设计。结合开发者长期的设计开发经验, 经过开发组的充分讨论, 形成2个核心模块的设计开发, 现将其思路介绍如下。

1.1 考核方案管理

考核方案管理模块所完成的主要功能为方案类型设计和方案管理。其中, 方案类型设计部分可根据不同科室的考核侧重点灵活选择有针对性的考核指标作为考核内容;同时, 考虑到系统数据的通用性, 在该模块部分也设计了考核指标的Excel导入导出功能, 大大增加了考核数据的灵活性。考核方案管理是本系统整体设计的一个关键, 系统可以针对不同科室设置不同的考核模板, 所有模板内容均可做到自定义选择。对于特定科室, 还可以设定专门的考核指标。

1.2 考评评分系统

考评评分管理模块主要包括考评信息录入、考评结果统计和考评结果模块, 主要功能为考评信息录入、上报、审核等。各科室主管按照考核通知按时录入考核数据, 上级领导审核通过后, 系统自动上报。一旦数据上报, 则不能进行修改, 如要修改, 则需要上级部门打回后方可;而考评结果统计可按照不同的选项进行, 实现考评结果的日、月、年、可选时间段以及对比等方式的统计;考评结果查看实现了考评结果的综合查询分析功能, 可查看各考核维度、考核指标的目标值、完成值、考核得分及明细情况 (报告计算公式、统计数据以及原始记录) , 并可在同类医院中对比分析以及查看历年、历月的变化趋势[8]。

2 数据库设计

数据库的设计对于系统的开发效率和运行效率都有很大影响。由于军队医院原本已经部署并运营了“军卫一号”HIS, 很多临床业务流水数据已经在其中产生, 因此, 在系统设计中需要考虑设计数据库表来直接获取指标点信息, 而无需重新录入。根据需求分析, 后台数据库表按照基础信息、方案指标、系统及权限3个方面进行设计。

2.1 基础信息

基础信息部分的表用来存放整个系统运行期间需要的一些基础数据, 例如国家和地区信息、医院基本信息和科室工作人员信息等。这部分数据的特点是在系统部署初始化阶段就基本完成了数据的录入或者导入。基础信息部分的数据库表设计如图1所示。

2.2 方案指标

方案指标部分是考评系统的数据核心。除了对详细的指标点数据进行采集和记录外, 在数据库设计时考虑了对于灵活考评方案的支持。用户可以根据自己的需求定制考评方案并进行保存, 且系统从指标点、分值、权重、考评时间等多个方面允许用户进行自行设计和定制[9]。既解决了不同医院之间的差异性问题, 又满足了同一所医院在不同时间段、不同任务需求时的考核需求。用户自定义的考评方案可以保存后反复使用, 这样既满足了灵活性要求, 又保证了考评效率。方案指标表详细设计如图2所示。

2.3 系统及权限

由于系统中大量采用了基于局域网Web的B/S架构, 因此安全永远是必须要面对和解决的头等大事, 绝大多数应用程序都有严格的安全需求。对于一个中型或大型的软件系统, 安全管理是一个基础模块, 涉及到用户、角色、操作权限、菜单、管理域等相关知识和模型, 它们分别有自己的职责, 同时相互关联, 共同构建起安全模型[10]。

通常来说, 应用程序需要满足几个基本的安全需求。首先, 应用程序必须能够识别访问者的身份;其次, 应用程序必须对Web资源提供安全保证, 拒绝未经授权的访问;最后, 在多层应用程序的模型中, 应用程序还要有能力对业务逻辑组件提供保护, 以防止非法用户绕过Web层调用受保护的方法。

本系统的安全管理主要解决2个问题:认证和授权。认证就是识别用户身份, 一个用户通过认证来告诉系统自己的身份, 从而使得系统确定用户的身份。认证有多种方式, 通常可以使用用户名和口令实现, 还可以使用数字证书等形式实现更安全的认证。一旦系统确定了用户的身份, 下一步就是要确定用户是否有权进行某些操作, 即授权。例如, 是否能进行全院各科室考评分数的查询。由于用户通常很多, 对每个用户进行授权会非常麻烦, 因此基于角色的权限控制就成为了一种最流行的授权方式, 本系统也采用此种授权方式。

建立合理框架模型, 能方便管理用户和用户权限, 保证功能的可配置性和安全性。在通过深入的需求分析和调研后, 我们采用了如图3所示的系统及权限表设计。

3 结语

本文对军队医院考评系统的模块和数据库后台设计进行了完整的介绍。模块和数据库设计是在进行了系统整体框架设计、指标体系设计和指标数据采集方案设计之后的工作, 是对整体设计的细化。在完成了模块设计和数据库表设计之后, 便可以进行前台程序开发。数据库后台根据数据的性质、层次和来源将其分为基础信息、方案指标、系统及权限3大类, 为后续的代码开发提供了基础。

参考文献

[1]谢爱辉.浅议公立医院财务绩效评价指标设置[J].中国市场, 2012 (18) :78-80.

[2]李华军.信息管理模式新概念[J].计算机世界, 2000 (10) :356-358.

[3]陈敏.借助信息化提升医院核心竞争力[J].中国医院院长, 2005 (12) :43-46.

[4]杨恩芬.医院办公自动化系统的设计及应用[J].江苏卫生事业管理, 2007, 18 (6) :39-40.

[5]张向阳, 张凌, 陈玲, 等.信息科在现代医院中的作用与地位[J].解放军医院管理杂志, 2009, 16 (1) :30, 80.

[6]许岸高.医院信息系统及其面临的问题[J].现代医院, 2003, 3 (1) :67-68.

[7]高社.军队医院绩效量化考评指标体系构建的宏观思考[J].解放军医院管理杂志, 2009, 16 (11) :1 030-1 032.

[8]于华, 薛运友, 王忠, 等.军队医院绩效量化考评指标体系构建思考[J].解放军医院管理杂志, 2010, 17 (11) :1 008-1 009.

[9]周宇顺.基于B/S架构和Web挖掘的用户需求定制系统研究[D].上海:上海交通大学, 2012.

后台数据系统篇3

对于基于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.

后台数据系统篇4

一、业务对象声明

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

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

参考文献

后台数据系统篇5

“军卫一号”系统是当前军队医院使用的主流医院管理信息系统,已经有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.

后台数据系统篇6

1 SQLServer与网络连接及数据库安全内涵

一般情况下, SQLServer使用的是1433端的监听, SQLServer是一种微软公开化的端口, 入侵者可以利用SQLPing工具获取数据库里面的数据。对于这种情况SQLServer如果建立在网络基础上进行数据储存, 这样可以师用防火墙对数据库进行保护。网络属性中可以选择TCP和IP协议属性, SQLServer与网络设计连接之后可以隐藏SQLServer实例, 然后就可以将默认的端口更改为其他端口, 并防火墙日志进行重新设置, 实现SQLServer与网络连接的保护。

数据库安全性问题的探讨主要是为了防止非法用护越权使用, 或是对数据中比较重要的数据进行修改等不法行为, 所以针对这类问题需要对计算机的系统建立相应的安全机制, 确保数据库安全。

首先数据库的建立要有保密性和完整性以及可用性的特点, 其中保密性就是所建立的数据库不能对外泄密数据, 或是访问权。而数据库的建立还需要有一定的完整性, 在保密性的前提下实现数据库建立的完整性。主要是数据库的建立不能受到硬件或是系统, 电源等物理故障的影响, 使得在发生故障时还可以对数据库进行恢复。

2 SQLServer数据库安全机制

2.1 使用安全账户和允许数据库访问

SQLServer这个用户是不能随意删除, 所以要加强对账号的保护。要建立一个比较强的密码, 不能在数据库再使用sa账号, 确保SQLServer实例的安全性。一般情况下要再次使用sa账号时是当密码忘记或是其他管理系统不可以再次使用的情况下。同时数据管理人员也可以建立一个与sa账号基本相一致的账号, 当然为了进一步的提高数据库管理水平要可以将系统账号删除, 这样系统操作人员就不能与数据库相接触。

在数据库建立以来人们都会采用不同的方式进行登录验证, 为了提高SQLServer数据库的安全性可以将数据库登录的方式进行权限分配。如果在创建了新的数据库时, 可以采用sp-grandbaccess的存储授权进行访问, 但是与sp-grandbaccess所对应的spdenybaccess存储过程实际上不存在, 所以不能以决绝服务器的访问的方式拒绝对数据库的访问, 所以在创建新的数据库时可以建立相对全局组, 并授予访问权对数据库进行访问, 但是这种方式不能限制对DDL访问。所以需要通过用户的个人账号对SID授权用户进行数据库的访问, 也可以对用户所在的一个组或是多个组进行授权访问数据库。

2.2 对数据库的权限进行合理化的分配, 并简化安全管理

在对SQLServer数据库事项安全策略的同时在最后要建立一个用户定义, 之后再进行数据库权限的分配。在创建新的名字时最好能与全剧组名字相符合, 一般在数据库数据整理比较复杂, 因此可以使用名字的缩写进行代替, 不过要保证数据分析的明确性, 避免造成数据管理出现混乱, 便于判断的数据库中的数据存储。当新的角色创建好之后需要用标准的REVOKE等来命令, 但是一般在命令中DENY权限要比其他的权限具有优先权, 所以要注意对DENY权限的使用, 如果随意使用就会使SQLServer数据库拒绝访问。然后就可以加入有关SQLServer的验证。一般情况下内建角色适用于整个数据库的访问, 所在内建在选择的时候通常是db-securityadmina和db-datrareder两个数据库角色。所以为了使用方便, 可以对数据库的用户建立定义角色, 并将用户访问的权限授予这个定义的角色就可以。

SQLServer验证登录比较方便而且也可以被很容易的编写到应用程序中, 但是这种容易编写和登录主要低对于用户数量比较少的情况下, 如果用户数量超过25, 或是服务器数量等在增加的同时SQLServer就不容易进行登录。SQLServer用户的权限不能进行限制, 所以需要对用户的权限进行记录就比较困难。所以不管是大型的数据库处理对数据存储或是小型数据处理系统都需要简化安全策略, 以便减少问题的复杂性, 便于对数据库实施安全策略。总之在SQLServer数据库管理问题上需要进行适当的规划, 这样管理人员才能进行更好的控制和管理, 提高对SQLServer数据库管理的水平。但是随着科学技术的不断提高, 在实际应用过程中数据库管理方式也会存在相应的变化, 但是在上述分析过程中几种方式是可以应用的, 能够在实际数据库存储过程中起到较好的安全保护作用。

3 提高SQLServer数据库安全性的方法

3.1 Windows身份验证模式

Windows身份验证模式对数据库进行访问一般在比较适用于部分数据库, 而且具有一定的优势, 能够提供更多的功能, 可以直接对口令进行加密或是账号锁定等。而且这种身份验证的方式也可以在SQLServer数据库中增加用户组, 用户可以对SQLServer数据库进行快速访问。SQLServer数据库处理Windows身份验证模式登录账号时需要用户将Windows NT/2000系统相连接, 并打开SQLServer数据库的委托连接, 这样将可以将Windows NT/2000的账号传输给SQLServer数据库, 实现SQLServer对数据库的确认。如果出现多个SQLServer机器在一个或是一组的网路区域中, 这种情况下就可以对SQLServer机器进行全面访问。

3.2 混合模式

混合模式一般比较适合外界用户访问数据库, 在这种情况下混合模式的SQLServer身份验证具有一定的优势, 可以将非Windows NT/2000客户或是因特网客户连接到SQLServer。而且也对SQLServer数据库增加了一层安全保障作用, 因而在SQLServer数据库登录账号时要对SQLServer用户进行验证, 查看用户是否在ayaslogins系统中, 是否与之前的口令相符等相关手续。

SQLServer系统表示是一个高性能数据库管理系统, 在对数据进行存储的过程中含有数据图像或是表格等。而且SQLServer本身对系统在存储数据过程进行了保留, 所以能够对单个表结构进行查询, 操作比较简单只需要在SQLServer中键入SP-COLUMNS就可以得到结果。

4 结束语

随着科学技术的不断提高, 网路技术的不断扩大, 信息量的不断增加, 使得信息存储出现了安全性问题, 经常会有非法用户对企业的重要数据或是个人的信息进行窃取, 或是进行修改, 失去了有效性。所以本文针对SQLServer数据库安全性问题展开了讨论, 并介绍了数据库安全性内涵和提高安全性的对策。实质上数据库管理是一个比较复杂的问题, 而且不仅仅是技术上的问题, 提高技术的同时还需要管理和法律等的社会因素的配合, 这样才能更好的实现数据库安全管理, 提高数据库的安全保障。

摘要：SQLServer是一种大型的数据库, 能够对大型数据处理系统的数据进行储存, 而数据库的安全性问题目前受到越来越多人的关注。所以SQLServer后台数据库的管理很重要, 该文主要探讨的是SQLServer后台数据库安全性管理和应用研究。

关键词：SQLServer,数据库安全性管理,应用研究

参考文献

[1]姜进成, 李文宏.SQLServer数据库在数据采集与监视控制系统 (SCADA) 系统中的应用[J].煤矿现代化, 2012 (2) .

[2]贺宪春.SQLSERVER视图和存储过程在进销存系统开发中的应用——以.NET开发环境实现统计业绩提成为例[J].计算机光盘软件与应用, 2013 (1) .

后台数据系统篇7

随着联通移动网客户群的快速增长, 客户业务资料的准确度成为向客户提供优质服务的关键。当客户通过营业厅等前台受理方式提出移动网业务请求时, 联通通过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 结束语