准金融机构监管信息系统可行性研究报告暨初步设计方案.docx

准金融机构监管信息系统可行性研究报告暨初步设计方案编制： 生效日期： 审核： 批准：目录第1章 项目概述51.1 项目名称51.2 业主单位51.3 工程背景51.4 建设规模51.5 项目概算6第2章 现状与需求分析62.1 项目的意义和建设必要性62.2 现状分析62.3 需求分析72.3.1 数据中心系统需求72.3.2 数据采集系统需求82.3.3 内部信息服务管理系统需求92.3.4 系统安全保障的需求10第3章 总体设计113.1 建设目标113.2 建设内容123.2.1 数据中心系统123.2.2 数据采集系统123.2.3 机构及高级管理人员管理信息系统123.2.4 贷款（担保、典当）业务管理信息系统133.2.5 财务管理信息系统133.2.6 风险管理信息系统133.2.7 现场检查信息系统133.2.8 信息交流平台143.3 系统的总体结构143.3.1 设计原则143.3.2 总体架构163.4 质量保证体系17第4章 工程建设方案184.1 主机及存储系统184.1.1 服务器架构建设184.1.2 主要性能分析184.1.3 存储系统容量考虑184.2 系统软件194.2.1 操作系统194.2.2 数据库管理系统194.2.3 应用服务器软件204.3 系统功能204.3.1 数据中心系统 数据处理系统建设 数据库表结构设计224.3.2 数据采集系统2 自动数据采集系统设计与建设2 手工数据采集系统设计与建设3 数据采集内容344.3.3 机构及高级管理人员管理信息系统3 准金融机构信息3 业务准入信息3 高级管理人员信息3 违规处理情况管理374.3.4 贷款（担保、典当）业务管理信息系统374.3.5 财务管理信息系统384.3.6 风险管理信息系统4 风险指标、模型管理4 风险分析4 风险识别4 风险应对策略4 风险应对处理434.3.7 现场检查信息系统4 现场检查立项4 现场检查数据录入4 检查数据分析核对4 现场检查报告444.3.8 信息交流平台4 金融政策发布4 金融宣传平台4 金融信息交流444.4 系统安全454.4.1 安全服务概述454.4.2 安全服务需求454.4.3 系统安全分析464.4.4 安全体系建设目标464.4.5 系统安全设计4 物理安全4 系统安全4 应用安全4 管理安全504.5 技术路线与关键技术504.5.1 J2EE与三层架构504.5.2 面向服务体系机构524.5.3 面向对象技术524.5.4 开发语言和开发工具52第5章 培训及维护535.1 应用培训535.2 运行测试设计535.3 系统维护机制与定员54第1章 项目概述1.1 项目名称准金融机构监管信息系统1.2 业主单位XXXXXX1.3 工程背景为加快建立市准金融机构监管信息系统，加强对各类准金融机构（包括小额贷款公司、融资性担保公司、典当行、民间资本管理公司等）的监测预警，完善地方金融监管机制，提高防范和化解金融风险能力，规范发展民间融资。建立一套信息资料齐全、数据更新及时、全面反映准金融机构状况的监管信息系统。1.4 建设规模本次项目建设规模如下：（1） 硬件建议配置：应用服务器2台，数据库服务器1台。（2） 系统软件建议配置：操作系统6套，数据库管理系统ORACLE 11G 2套，Weblogic 10 2套。（3） 业务应用系统开发数据中心系统1套数据采集系统1套机构及高级管理人员管理信息系统1套贷款（担保、典当）业务管理信息系统1套财务管理信息系统1套风险管理信息系统1套现场检查信息系统1套信息交流平台1套1.5 项目概算本项目的硬件采用以租代建的方式实施，设备可选择的托管运营方式为：数字办机房、电信机房、联通机房。每种方式的详细预算以及软件开发费用详见“概算编制”章节。第2章 现状与需求分析2.1 项目的意义和建设必要性与地方金融机构不同，目前很多准金融机构尚未建立规范高效的业务运行系统，相关监管部门难以及时获取有效的监管信息。例如各准金融机构业务流程差别较大，财务报表不统一不规范，导致数据汇总难度较大。目前对地方准金融机构的监管基本还停留在审批设立和事后风险处置环节上，而连续监管力度不够，风险预警系统薄弱。因此，有必要建立一套信息资料齐全、数据更新及时、全面反映准金融机构状况的监管信息系统。2.2 现状分析准金融机构与传统金融机构相比，虽然一般不会产生系统性风险，但是由于准金融机构的目标客户资信信息具有离散度高、透明度低、规范性差等特点，加之准金融机构尚未具备足够的风险评估技术，存在较为严重的信息不对称情况，因此不管是小额贷款公司还是融资担保公司，如果监管不力，均可能产生涉众金融风险。目前准金融机构中，小额贷款公司发展时间较短，虽未爆发严重风险，但是已经有一些问题出现，而融资担保公司目前由于前期的发展混乱，目前正处于清理整顿阶段，风险自不待言；其他如典当等一直以来就是一个高风险的领域。随着准金融机构的发展加速，在实体经济或者金融市场出现大幅波动时，对金融稳定将形成新的压力。2.3 需求分析2.3.1 数据中心系统需求准金融机构监管信息系统项目是建立采集和管理政府及其职能部门掌握的各类准金融机构的经营管理和数据信息、报表、报告，对准金融机构业务经营状况、财务情况、风险管理状况等进行监测、监控和分析，形成并维护全市最完整、最准确的准金融机构数据库的应用系统。其建设主要需求点分析如下：1. 存储系统建设需求由于数据中心系统处理过程中数据大，数据库、知识库等对存储系统的要求高，因此存储系统需要专门部署，为各种数据提供专门的存储解决方案。2. 系统数据处理需求数据中心系统中的数据处理系统需具备全市准金融机构的各种数据及人工受理数据等方式采集到的数据，统一到数据处理系统进行自动核对、整理及人工审核的能力以保证本次项目建设的数据库数据安全、准确、有效。3. 数据备份建设需求项目中的数据集中在服务器上，为确保系统运行及数据安全，需对系统数据进行备份，以便发生灾难时可以及时的恢复数据。4. 安全性建设需求数据中心系统安全系统建设，主要从网络层、系统层、数据层、应用层、服务层等各个方面考虑，加强安全系统的建设。为了保证准确、及时、有效的掌握数据库系统的详细使用情况对于核心数据库管理是十分重要的，因此需新增安全审计系统实现对数据库远程各种操作的详细审计，并进一步分析业务数据的使用状况，为数据中心系统提供种类丰富的分析报告，为数据使用的合规分析，数据的性能分析提供可靠的依据。5. 基础数据整理需求基础数据的整理：对已经征集、备案的历史基础数据，进行整理、比对，形成完整的基础数据档案6. 业务数据利用需求数据中心系统能够对信息进行分级分类存储管理，全面详细地记录、存储、管理本部门的业务信息，并按要求自动汇总相关信息，通过利用数据库的业务信息，能够支持多条件的综合查询和不同业务类型的主题应用。2.3.2 数据采集系统需求数据采集系统是准金融机构监管信息系统的重要的子系统，该系统通过自动或手动的方式对准金融机构不同业务类型的数据进行抽取，针对数据采集系统的需求如下：1. 数据采集系统建设必要性需求准金融机构监管信息系统是以准金融机构的基本信息为基础，并对这些基本信息进行有效的整合、加工处理，而数据采集系统在这里就产生了关键性作用，也是准金融机构监管信息系统建设中不可以分离的子系统。2. 数据收集的需求：数据采集系统是必须且能够将分散在准金融机构的信息，快速、准确地进行抽取，并将采集到的业务系统中信息的单向的上传到数据中心系统。3. 数据采集多样化的需求数据采集系统对前端数据采集需要有多样化的需求，目前数据采集系统分自动和手动采集两种方式：手动采集客户端采用IE浏览器录入信息；自动采集则是通过软件自动抽取各准金融机构已有数据库内的信息数据。4. 数据交换可扩充性需求数据采集系统应具有良好的可扩充性。随着业务需求的变化和发展，通过在数据采集系统上进行配置部署，即可实现不同的业务数据的实时交换，无需开发或修改程序代码。数据采集系统可方便地适应建设规模扩大的需求，实现平滑升级过度。2.3.3 内部信息服务管理系统需求内部信息服务管理系统包括机构及高级管理人员管理信息系统、贷款业务管理信息系统、财务管理信息系统、风险管理信息系统、信息交流平台等5个子系统，子系统应能满足“内部共享、辅助决策、信息检索、监督预警、系统管理”五大功能，能实现信息数据共享，发挥监管和服务作用；通过对信息数据进行分析统计，为领导决策提供支持；起到监督成员准金融机构、风险预警的作用。1. 内部共享模块：能通过接口配置、开发，将数据共享交换给省及相关部门准金融机构信息报送系统对接的端口，逐步实现与各信息报送系统数据交换，以利于各部门资源共享，并减轻各准金融机构报送压力；2. 辅助决策模块：主要针对性的提供各类统计报表，为领导决策提供支持，分析报表包括：汇总报表、监管指标表、数据异常变化表等；3. 信息检索：提供全方位的检索手段，支持多种检索运算符，包括外部特征与正文内容的各种逻辑组合检索，逻辑或、与非的检索，符合通用搜索引擎使用习惯；多字段复合检索、历史检索、相关词扩展检索、分类导航检索、中英文（字符）混合检索，支持前方一致检索、短语与句子检索功能等。 检索子系统符合通用搜索引擎的使用习惯，支持搜索引擎搜索的绝大部分功能。用户通过关键词检索后，会在标题和摘要中以高亮显示，搜索结果分别按照标题、摘要、内容进行类聚，并剔除重复性的内容；4. 监督预警：基于非现场监管数据、现场检查结果和外部审计数据，通过风险分析与预警系统，实现对准金融机构整体运行情况的风险预警，并及时向准金融机构发出早期预警信号，同时启动和指导现场检查，对风险进行确认和评估；5. 系统管理:为内部信息服务管理系统的应用模块提供应用支撑，主要包含用户管理、角色管理、组织管理、权限管理、日志管理等模块。2.3.4 系统安全保障的需求由于“黑客”、计算机病毒、信息间谍等对网络安全构成越来越严重的威胁，安全也成为网络应用的必需手段，以保护网络传输的数据的安全性和完整性。加强准金融机构监管信息系统安全建设，以实现对系统实体安全、网络安全、信息安全、系统安全、运行安全实施安全管理。系统安全需求主要体现在以下几个方面： 安全等级保护需求系统应在物理安全、网络安全、系统安全、应用安全和管理安全几个方面有所保障。安全建设内容除延续信息系统安全等级保护基本要求的内容之外，重点在于应用系统安全建设、数据备份、审计核查，涵盖范围包括服务器、网络等硬件及应用软件等，结合安全等级保护三级要求主要包括以下几个方面的内容建设：网络安全：结构安全、网络边界安全、访问控制、入侵防范、恶意代码防范；应用安全：身份鉴别、访问控制、通信完整性、软件容错、权限控制、主机安全、恶意代码防范；数据安全：数据完整性、数据保密性、数据备份和恢复；审计核查：网络安全审计、应用安全审计。 网络安全需求分析包括防网络故障、物理隔离、加密传输、安全漏洞扫描、入侵检测防御与预警、身份鉴别、访问控制、数据保护、日志审查、防病毒等。基于联动联防和网络集中管理、监控技术，将所有网络安全和数据安全产品有机的结合在一起，在漏洞预防、攻击处理、破坏修复三方面给信息系统提供整体的解决方案，大在提高系统防护效果，降低网络管理的风险和复杂性。 应用安全需求分析防止对外的Web应用系统页面被篡改，对应用层协议进行深层过滤，阻止利用应用层协议进行的攻击；对计算机及服务器采取足够强硬的安全措施，如漏洞封堵、定期的漏洞检测、病毒防护等。 审计核查需求分析审计系统应具备统一的策略、集中的审计，适用于不同的设备、操作系统、数据库系统和应用系统的审计要求，并对这些系统不造成影响，审计核查需求主要来自于以下两个方面：数据库审计：由于业务系统数据在数据库中进行集中存储，故对于数据库的操作审计需要细化到数据库指令、表名、视图、字段等，同时能够审计数据库返回的错误代码，这样能够在数据库出现关键错误时及时响应，避免由于数据库故障带来的业务损失；内部网络审计：终端接入内部网络开始，提供从安全防护、信息管理和远程维护、防泄密和审计，为内部网络终端提供全程的保护和合规管理。 数据安全需求分析准金融机构监管信息系统的存储架构基于平台安全体系进行建设，在存储系统上集中了大量的业务数据，并且成为业务系统的关键应用之一。数据备份系统的核心任务是中心数据库业务数据中的备份和网络中重要数据资源的备份。第3章 总体设计3.1 建设目标以风险监管为核心，以“统一规划、分级负责、上下联动、资源共享”为设计原则，着力构建以数据库为基础平台的新型监管信息系统，充分利用联机分析处理、数据挖掘和内容管理等技术，推动准金融机构监管信息系统的深入应用，建立适合各类准金融机构特点和监管需要的实时监管信息系统，进一步强化对准金融机构合规性经营和风险管理的持续监控，充分发挥非现场监管与现场核查的互补作用，切实提升监管的效率和质量。3.2 建设内容3.2.1 数据中心系统数据中心系统是承载跨部门、跨应用系统之间的信息交换与共享，整体，按照“统一数据项、统一标准”原则，采用规范的数据采集和定期更新机制。而本次项目中数据中心系统建设的主要内容是针对已抽准金融机构各类数据进行管理，将采集到的信息数据利用安全的网络传输通道，并通过数据采集系统上传至数据中心系统，并进行数据的基本清洗，再将清洗后的信息数据通过比对、整理、汇总提供给各业务系统使用。3.2.2 数据采集系统数据采集系统是准金融机构监管信息系统的重要的子系统，该系统主要对准金融机构不同业务类型的数据抽取。数据采集系统为适应对前端数据采集需要有多样化的需求，目前数据采集系统分自动和手动采集两种方式主要建设如下内容：1、自动数据采集系统：自动采集则是通过软件方式自动抽取各准金融机构已有数据库内的信息数据。2、手工数据采集系统：采用IE浏览器录入信息的方式采集数据，也提供指定格式的数据文件的导入功能采集数据。3.2.3 机构及高级管理人员管理信息系统实行对所有准金融机构的机构信息、业务准入信息、高级管理人员（董事、监事及高级管理人员）信息及违规处理情况的集中统一管理。实现对准金融机构准入及重要事项变更的审批，对高管人员任职资格的审批及履职监管。3.2.4 贷款（担保、典当）业务管理信息系统对各类准金融机构报送的信贷业务管理报表进行采集和分析加工，主要生成部分包含汇总报表、监管指标表、合规情况表、数据异常变化表等，主要有趋势分析、同比排名分析、增减百分比和占比分析等，同时还包含各类组合查询系统和EXECL格式数据下载等。实现对准金融机构信贷资金使用、流向、集中度等情况的监管。3.2.5 财务管理信息系统对各类准金融机构各种财务报表包括月季年度报表、收支明细表、资产负债表、现金流量表、利润表、缴纳税收情况表等进行采集和分析加工，主要生成部分包含汇总报表、监管指标表、合规情况表、数据异常变化表等，主要有趋势分析、同比排名分析、增减百分比和占比分析等，同时还包含各类组合查询系统和EXECL格式数据下载等。实现对准金融机构财务情况特别是融资和用资情况的监管。3.2.6 风险管理信息系统对各类准金融机构贷款（担保、典当）风险分类数据进行采集和分析加工，主要生成部分包含汇总报表、监管指标表、数据异常变化表等，主要有趋势分析、同比排名分析、增减百分比和占比分析等，同时还包含各类组合查询系统和EXECL格式数据下载等。以利于及时掌握准金融机构信贷资产质量，准确、及时地识别各家准金融机构贷款（担保、典当）的潜在风险及其迁徙，并能通过信息交流为同行业企业提供风险预警，以便采取更为有效的措施来防范和化解风险。3.2.7 现场检查信息系统通过现场检查数据及结果评价归档保存、非现场与现场数据比对，实现现场检查过程文档处理电子化、检查程序规范化、检查资料归档电子化以及监管信息共享，同时便于核查非现场监管系统报送数据的真实性，并根据核查结果确定下一步非现场监管方向。3.2.8 信息交流平台主要用于各级监管部门的政策及信息发布、信息交流等。3.3 系统的总体结构3.3.1 设计原则根据项目建设总体目标和基本目标，本期项目建设的基本原则是：1.整合资源，互联共享。全面整合我市准金融机构的信息资源，投资方面最大程度地整合网络与信息资源，保护现有投资，在保证网络整体性能的前提下，充分利用现有的网络设备或通过必要的升级，最终实现有序互联，有效共享。2.统一规划，分步实施。按照XXXX的统一部署，制定总体规划，贯彻落实统一的标准，制定统一的规范体系，建设和整合统一准金融机构监管信息系统、避免重复建设。3.强化服务，追求实效。结合服务社会公众和政府机关的效能建设，根据政府业务的需要，在整体的准金融机构监管信息系统建设中突出服务重点，讲求便民实效，提高办事效率。4.建立完善的应用整合架构。能够为整体 IT架构提供重要的基础设施，为后续需要增加新的业务应用系统和对现存系统进行整合提供基础，从而促进整个IT架构的完善。5.遵循标准规范。系统采用的各种协议，数据库建设标准，信息交换和共享都符合相关国际标准，保证系统将来能与其他系统进行快速、顺利、安全的信息数据交换。6.遵循开放性原则。系统应提供符合国际标准的软件、硬件、通信、网络、操作系统和数据库管理系统等诸方面的接口与工具，采用开放的技术可使平台能够更好、更及时地将新的技术、功能和标准植入，使系统具备良好的灵活性、兼容性、扩展性和可移植性。7.保证系统的可靠性。选择较为成熟、可靠、稳定、先进的各种组件、技术以及操作系统、数据库、网络协议、中间件，服务器可采用集群技术，保证系统能长期稳定的不间断运行，保证系统的稳定性。8.保证数据的安全性和一致性。借鉴国内外先进的信息安全理念，遵循国家有关信息安全的法律、法规、制度，使用软硬件结合的安全保证手段，在物理层、网络层、系统层、应用层及规章制度层等多个层面确保信息系统的安全性与保密性。9.保证系统的实用性。系统应具备完成工程中所要求功能的能力和水准。系统应符合本工程实际需要的国内外有关规范的要求，并且实现容易，操作方便。坚持以需求为导向，以应用促发展、贴近用户的需求，满足实际信息管理的要求。10.保证系统的先进性。主要有：一是系统规划和整体结构的先进性，二是系统平台的先进性，三是网络结构的先进性，四是系统布局的先进性，五是数据库平台和开发平台的先进性，六是应用功能的先进性。在构建应用系统时，要立足先进的技术，系统着眼点要高，不仅能满足当前管理的要求，而且要符合信息化的最新发展方向。11.保证系统的灵活性。系统可运行于单机、单服务器、多服务器等模式；信息采集、管理、传递可多平台分布式协同操作；统计、查询及数据输出格式等业务流程均可调整、定制，实现业务逻辑与数据存储分离，业务逻辑设计模块化，保证系统适应未来升级的需求。12.保证系统的易用性。系统的使用及管理以简便、易用、实用为准则，界面直观、简单、贴近实际，符合实际业务过程。系统维护简单，无须投入大量精力就可保证系统具有高可管理性，降低系统管理和维护成本。以保证系统正常运行。13.保证系统的可扩展性。系统建设应采用面向对象方法进行模块化设计，不仅要满足当前的建设要求，还应具有良好的可扩充与可延展性。有利于逐步升级，实现向未来技术平滑过渡。同时应向用户提供完整、详细的开发文档，确保客户能够对系统进行二次开发。3.3.2 总体架构1、资源层资源层主要包括已有的系统平台、服务器、存储及其他设备，是构成共享平台应用系统的重要基础设施，支撑信息应用系统的运行。2、数据资源层数据资源层构建于基础设施层之上，并为上层的应用支撑层提供各种信息资源，主要为各业务系统的数据源。数据资源层是整个系统的信息唯一来源，是整个系统数据正确性的唯一依据。3、数据采集系统数据采集系统是将数据通过手工采集或自动采集的方式，抽取提供到数据中心系统中，实现对各数据源的数据采集、传输、清洗、比对、交换，及交换过程的流程监控管理和数据资源管理。4、平台数据层平台数据层基于数据采集系统，并为上层的应用支撑层提供各种信息资源。平台数据层是整个系统的信息资源中心，是整个系统数据的集散地。数据资源层主要包括业务数据、监控数据、分析数据。5、业务应用层业务应用层主要包括系统的各个功能模块和子系统。6、标准规范体系系统建设，要遵循统一的标准规范，是系统得以顺利建设和正常运行的保障体系。7、安全保障体系确保系统安全运行的保障体系，信息安全贯穿于平台的各个层面，平台各系统的建设都必须具有相应软硬件安全保障措施，以保障各应用系统的安全可靠运行。3.4 质量保证体系本次系统设计将遵循国家和行业有关业务、技术、数据标准和规范中国公用计算机互联网工程设计暂行规定（YD 5037-97）；信息技术互连国际标准（ISO/IEC11801-95）；信息技术、软件包质量要求和测试（GB/T 17544-1998）；软件工程标准分类法（GB/T 15538-1995）；软件开发规范（GB 8566-88）；软件维护指南（GB/T 14079-93）；计算机软件质量保证计划规范（GB/T 12504-90）；计算机软件测试文件编制指南（GB 9386-88）；质量管理体系要求（idt IS0 9000：2000）（GB/T 19001）；基于XML的电子公文交换格式规范（国标）；智能网工程设计暂行规定（YD 5036-97）；计算机信息系统安全专用产品分类原则（GA 163-1997）。第4章 工程建设方案4.1 主机及存储系统4.1.1 服务器架构建设服务器平台是构建各种信息数据库、中间件、应用软件平台的依托，涉及到各种数据库及其应用，存储着所有业务数据、应用系统和信息运行所需的数据，是保证系统正常运作的关键。这些对服务器系统处理能力提出了较高要求，需要高性能CPU、大容量内存为各类数据应用提供支撑。4.1.2 主要性能分析数据库服务器：数据库服务器作为业务系统的核心，承担着业务数据的存储和处理任务，具有业务量大、存储量大等特点，服务器的可靠性和可用性是首要的需求，其次是数据处理能力和安全性，然后是可扩展性和可管理性。为保证信息系统持续稳定高效地运行，须保证服务器数据存储系统较高的可靠性、扩展性和灾难恢复能力。并根据具体业务需求和投资情况选择双机集群或单服务器系统。应用层服务器：承担着XX市准金融机构监管信息系统各类应用服务，主要强调其强大的计算能力，能够处理大量的并发连接处理，并能够在用户数增加的情况下保持良好的性能平衡。除此之外，能够提供连续可用的可靠性，能够适应各种网络环境的扩展能力。4.1.3 存储系统容量考虑存储容量的计算涉及到业务系统的数据量，从目前数据中心数据类型来看，主要包括6大系统的数据，考虑数据余量及3年的数据存储，因此本期工程配备600GB的存储容量，同时需要确保选购的存储系统具备良好的扩展性，至少需要支持3TB以上的扩展容量，以满足应用未来业务数据存储要求。4.2 系统软件4.2.1 操作系统目前主要的服务器操作系统有：Unix、Linux、Windows等。建议根据项目建设及系统安全性和应用、集群操作的需要，分别选择Windows 2008 Server（企业版）和 RedHat Enterprise Linux 5.5（及以上版本），以满足本次项目的使用需求。(1).Windows 2008 Server企业版具有系统扩充性好、多用户、多任务、界面友好；能够提供一个高可用性、可管理性和安全、稳定、容错的服务平台。(2). RedHat Enterprise Linux 5.5服务器产品具有系统稳定、安全、高效，以及对企业级核心应用的良好支持等特点；支持电信级Linux CGL 2.0标准，实现从用户应用到操作系统的故障自动恢复，可最大限度的降低系统宕机时间；易于部署、管理和使用，在统一的控制面板框架下内建了集成化的管理工具，提供了Linux系统的专业和全面的主机管理工具集，支持本地和远程管理，有效提高了系统管理员的工作效率。以上两种操作系统，均可为本次项目使用，建议选用RedHat Enterprise Linux 5.5（及以上版本）。4.2.2 数据库管理系统基于数据库管理系统本身的优势、本期项目应用的需求、应用及数据环境间的集成因素，经过认真比较分析后建议选择Oracle产品。主要考虑到：(1).Oracle 11g提供了完整的开发工具，可以充分满足数据中心及业务应用系统的数据需求，同时还留有很大的扩展性。(2).基于Oracle 11g以及相应的Oracle系统软件，可以组建高效、安全的三层应用环境，是目前先进、成熟的数据库服务器产品。(3).Oracle有JDBC、ODBC、OLE DB、OCI的支持，并且提供了.NET版的Oracle Client Provider；Oracle在9i中已经有相对完善的Java支持；Oracle在10g中提供了一个完整的2-D、3-D数据开发平台。4.2.3 应用服务器软件应用服务器和整合服务器是目前比较流行的两种类型的整合架构、整合环境和产品，两者的功能有很大部分的重合。从产品的成熟性方面来看，应用服务器相对要成熟得多。因此，建议在本期项目建设中，选用以J2EE应用服务器为基础的整合方式。一方面，应用服务器提供了成熟的面向消息的中间件JMS；另一方，应用服务器提供了一系列有利于应用整合的服务或功能，如JDBC、JCA、Web Service、XML、SOAP、HTTP、TCP/IP等，同时还可以随时加入工作流管理等组件，以进行业务逻辑的整合。4.3 系统功能4.3.1 数据中心系统 数据处理系统建设.1 数据清洗 数据清洗逻辑结构数据清洗是针对记录集而言，记录集是一个逻辑概念，在数据库中通常由视图表示，每个记录集通常由一到多个的基本表构成，每个记录集可对应一到多个的比对规则： 数据清洗规则配置数据整合系统内置了大量的清洗规则和基于JAVA语言的开发包，如：对于企业上报的数据可以选择清洗企业名称为空、数据格式不规范等等情况的记录。当系统内置的清洗规则无法满足需要时，管理员可根据系统提供的配置规则进行扩展。清洗规则配置支持JAVA语言扩展，在扩展时必须实现系统提供的IClean接口，并在实现类中实现IClean接口的Clean方法。配置完保存系统后可在本系统的任何地方使用，每次扩展后主程序无须修改，极大的保证了系统的扩展性。.2 数据转换数据转换是以数据库的建设标准将不同企业的数据进行标准化转换，转化的规则通过数据整合系统实现。数据整合系统内置了大量的转换规则和基于JAVA语言的开发包，如：进行字符集转换、数据的中文和数字间转换等。当系统内置的转换规则无法满足需要时，系统管理员可根据系统提供的配置规则进行扩展。转换规则配置支持JAVA语言扩展，如：在扩展时必须先导入开发包，实现系统提供的ITranslate接口，并在实现类中实现ITranslate接口的translate方法。配置完保存系统后可在本系统的任何地方使用，每次扩展后主程序无须修改，极大的保证了系统的扩展性。.3 数据比对校验系统提供了数据比对功能，数据比对包括计算机自动比对和手动比对，自动比对的规则可由用户自己配置。数据整合系统还提供了数据校验功能，数据校验规则可由用户自定义，另外，通过比对结果的查看功能可方便监控数据的比对情况，包括数据比对成功的查询，数据比对失败的查询等功能。1、数据比对数据比对的目的是建立两个数据源之间的关联关系，最终形成关联库，为后期的数据集成装载奠定基础。2、数据校验数据校验是指数据装载进主表和索引库后进行的正确性校验，排查错误数据，从而进一步提高数据库的数据质量。数据整合系统提供了许多预定义好校验功能，当系统提供的校验规则不能满足需求时，管理员可根据工具提供的自定义功能进行新校验功能的配置。如：校验规则配置采用JAVA语言扩展，在扩展时必须实现系统提供的IReCheck接口，并在实现类中实现IReCheck接口的reCheck方法。配置完保存系统后可在本系统的任何地方使用，每次扩展后主程序无须修改，极大的保证了系统的扩展性。.4 数据集成数据集成的目的是将数据比对形成的关联表按数据库的标准装载进主表或索引库中，数据的集成需经过数据源选择、转换和装载等步骤。1、选择数据源时可一次选择多个数据表；2、数据转换，这里的转换会自动调度系统配置好的转换规则；3、数据装载。 数据库表结构设计数据库设计（Database Design)是指对于一个给定的应用环境，构造最优的数据库模式，建立数据库及其应用系统，使之能够有效地存储数据，满足各种用户的应用需求（信息要求和处理要求）。.1 库表设计原则1、规范化与反规范化规范化的优点是减少了数据冗余，节约了存储空间，相应逻辑和物理的I/O次数减少，同时加快了增、删、改的速度。但是一个完全规范化的设计并不总能生成最优的性能，因为对数据库查询通常需要更多的连接操作，从而影响到查询的速度，而且范式越高性能就会越差。出于性能和方便管理的考虑，原则上表设计应满足第三范式。有时为了提高某些查询或应用的性能而可以破坏规范规则，即反规范化。数据应当按两种类别进行组织：频繁访问的数据和频繁修改的数据。对于频繁访问但是不频繁修改的数据，内部设计应当物理不规范化。对于频繁修改但并不频繁访问的数据，内部设计应当物理规范化。比较复杂的方法是将规范化的表作为逻辑数据库设计的基础，然后再根据整个应用系统的需要，物理地非规范化数据。2、数据表分类说明根据应用的实际需要和特点，可以将数据表进行如下分类：分类表描述基本数据表描述业务实体的基本信息。例如，人员基本信息、单位基本信息等。标准编码表描述属性的列表值。例如，职称、民族、状态等。业务数据表记录业务发生的过程和结果。例如，人员调动登记、变更通知单等。系统信息表存放与系统操作、业务控制有关的参数。例如，用户信息、权限、用户配置信息等。统计数据表存放业务数据统计值。例如，通知单统计、人员类别统计等。临时处理表存放业务处理过程中的中间结果。其他类型表存放应用层的日志、消息记录等。.2 字段设计原则（1）一般来说，应该使用能正确存储和表示数据的最小类型。如果不确定需要什么数据类型，则选择不会超出范围的最小类型。（2）选择更简单的数据类型。例如，比较整数的代价小于比较字符，因为字符集和排序规则使字符比较更复杂。（3）尽可能把字段定义为 NOT NULL。对于字段能否NULL，应该在SQL建表脚本中明确指明，不应使用缺省。（4）一个表中的字段不要太多，理论上不要超过80个。（5）数据库中所有布尔型中数值0表示为假；数值1表示为真（6）当字段定义为字符串类型时使用VARCHAR2而不用NVARCHAR（7）字段尽可能有默认值，字符型的默认值为一个空字符值串，数字型的默认值为数值0。.3 键设计原则（1）为关联字段创建外键。（2）所有的键都必须唯一。（3）尽可能避免使用复合键。（4）外键总是关联唯一的键字段。（5）尽可能使用系统生成（如序列SEQUENCE产生）的主键。（6）可选键有时可做主键。（7）一个表中组合主键的字段个数尽可能少。.4 索引设计原则（1）如果一列出现在表达式或函数中，不会使用该列上的索引（2）要索引外键（3）对于索引选择性高的列使用B-Tree索引（4）对于索引选择性低的列使用位图索引（5）HASH索引只适用于相等比较（6）不要索引大型字段（有很多字符的字段）（7）不要索引常用的小型.5 LOB设计原则如无特别需要，避免使用大字段（BLOB、CLOB、LONG等）。如使用时必须使用BLOB或CLOB类型。.6 完整性设计采用数据库系统实现数据的完整性。这不但包括通过标准化实现的完整性而且还包括数据的功能性。在写数据的时候还可以增加触发器来保证数据的正确性。不要依赖于应用程序保证数据完整性，它不能保证表之间（外键）的完整性。（1）主键约束每个表要求有主健，主健字段或组合字段必须满足非空属性和唯一性要求。（2）键约束对于关联两个表的字段，一般应该分别建立主键、外键。实际是否建立外键，根据对数据完整性的要求决定。根据需要适当设置父表数据修改时对子表的影响：父表中删除数据：级联删除；受限删除；置空值。父表中插入数据：受限插入；递归插入。父表中更新数据：级联更新；受限更新；置空值。（3）NULL值由于NULL值在参加任何运算时，结果均为NULL，所以必须利用NVL()函数把可能为NULL值得字段或变量转换为非NULL的默认值。（4）CHECK条件对于字段有检查性约束，要求指定CHECK规则。（5）触发器触发器是一种特殊的存储过程，通过对表的DML操作而触发执行，是为确保数据的完整性和一致性不被破坏而创建，实现数据的完整约束。选择触发器的BEFORE或AFTER事务属性的时候，对表操作的事务属性必须与应用程序事务属性保持一致，以避免死锁发生。在大量修改数据时，尽量避免使用触发器。（6）视图为了在数据库和应用程序之间提供另一层抽象，可以为应用程序建立专门的视图而不必非要应用程序直接访问表。这样做还在处理数据库变更时提供了更多的自由。视图是虚拟的数据库表，在使用时要遵循以下原则：为简化查询，将复杂的检索或子查询通过视图实现。提高数据的安全性，只将需要查看的数据信息显示给权限有限的人员。视图中如果嵌套使用视图，级数不要超过3级。由于视图中只能固定条件或没有条件，所以对于数据量较大或随时间的推移逐渐增多的表，不宜使用视图，可以采用实体化视图代替。除特殊需要，避免类似SELECT * FROM TableName 而没有检索条件的视图。（4） 视图中尽量避免出现数据排序的SQL语句。4.3.2 数据采集系统 自动数据采集系统设计与建设.1 自动数据采集设计自动数据采集的主要功能需要从源系统中采集数据到数据集成平台的源系统数据文件落地区。常见的数据采集方法主要有以下几种：1、通过专用数据同步工具将源系统生产数据实时同步到数据采集区。采用该模式的好处，主要是基于效率以及稳定性考虑，特别适合数据库层次的复制；另外一个好处是，几乎可以适用于任何类型的数据源，包括不同厂商的数据库、文件等。2、通过存储设备本身的同步复制软件将源系统生产数据同步到数据采集区。该模式实际上和上述专用工具备份方式没有本质上的区别，只不过一个是数据库厂商或其他软件厂商开发的数据备份软件，一个是存储设备厂商（例如EMC）自行开发的数据备份软件。从效率上来说，存储设备复制技术要优于其他数据备份软件，但同时有一个比较大的缺点，受制于操作系统和数据库系统对存储设备的识别方式；一般情况下，通过存储设备复制的数据库，并不能很快就能使用，需要重新加载数据库设备，重新启动数据库，极端情况下还需要重启操作系统，因此这种存储复制技术更多情况下也是用于灾备。3、自行开发通用的数据下载平台，将源系统生产数据同步到数据采集区。这种模式常用于增量数据采集。通过该模式基本上能按需要来定制开发数据采集程序，灵活性大，效率也较高，同时还可以集成增量比对、乱码校验及修正、压缩打包、拆分并发处理、传输处理等功能，是一个务实的做法。但该模式也存在一个致命的问题，那就是如何确定增量数据的问题？如果通过数据库日志来获取，难度很大，而且也并不一定可行；如果通过数据库结构的某个字段来识别，这完全取决于源系统最初设计时是否考虑了增量备份的需求；不幸的是，大多数情况下，并没有考虑。于是，不得不采用先全量下载的方式，然后传送到数据采集区，再通过数据采集区来实现增量对比。在这种模式下，全量数据的传输无疑又是一个新的问题。4、由源系统本身开发数据下载脚本，在本地生成数据，然后通过文件传输工具发送到数据采集区。这种模式常用于源系统数据采集，这主要是考虑其他源系统的数据采集量不大，而且各源系统架构多样化，不适宜采用通用的数据下载工具。这种模式是一种主动采集模式。上述四种数据采集模式，均各有特点，各有合适的应用场景。“准金融机构监管信息系统”的数据源也是多种多样，不宜采用统一的数据采集模式；应根据采集数据本身的特点，来规划数据采集模式。源数据是来“企业信用信息交换平台”，则自动采集的策略是：若能识别增量数据，尽可能在第3种模式；对于数据量大的数据对象，可以考虑使用第1种或第2种方法。数据采集除了考虑上述采集技术外，还应该设计数据采集区的存储方式。由于“准金融机构监管信息系统”的数据是来自于不同源系统，不改变源系统的数据表结构，因此无需另外设计独立的数据模型，仅需按一定的规则存储不同源系统的基础数据即可。.2 自动数据采集建设.2.1 数据抽取策略抽取所涉及外围元业务系统的范围及各系统所涉及的表的大致范围确定以后，就要根据每个系统的具体情况确定抽取策略。数据抽取策略包括数据源连接策略和数据加载策略。数据源连接策略包括：文件传送方式，直连方式。数据加载策略包括：增量（通常按照交易日期），全量。增量原则是根据业务系统数据产生或变化为标准，对于“准金融机构监管信息系统”而言，每日加载为了提高数据传输和转换的效率和计算性能，尽量选择增量加载。.2.2 数据转换策略自动抽取在把源数据加载到“准金融机构监管信息系统”临时数据区以后，对临时数据区的数据进行转换加载到信息数据库基础数据模型中，在该数据转换中需要根据数据的特点选择不同的数据转换策略。数据转换策略包括：(A)全表覆盖（Delete All and Insert）全表覆盖策略，是指对整个目标表在抽取加载时，删除目标表中原有数据，从源表中重新抽取、转换数据，并添加到目标表中，从而达到对目标表中数据全部更新的作用。目标表全部更新，适用于存在修改历史的数据并且不用保存历史的数据，同时也基于性能考虑。(B)增量追加(Add )增量追加策略，是指按照加载周期，仅仅将源表中加载时间点或加载时间段内的数据insert到目标表中。这种抽取加载策略适用于源表中的数据是按照日期的增长，不断增加记录（insert），并且这些增加的数据对原来的数据不发生作用(即没有delete、update)的情况下，要对目标表进行加载转换的情况。(C)增量比对（Update and Insert）增量比对策略，是指按照加载周期，将源表中加载时间点或加载时间段内的数据insert到目标表中，因源表中部分并不是完全新增，会有部分数据发生变化，如此，就需要对加载时间点或时间段中的数据与已经加载的数据进行比对，以保证加载的数据是正确的。这种抽取加载策略适用于源表中的数据是不断变化而无法容易的得到增量的情况。这种策略情况下，我们通常将主键字段作为比对条件，但是某些情况下要根据业务含义及源系统数据提供方式来决定。(D)历史拉链（History Chain）适用于需要保存数据的连续历史轨迹，用开始时间和结束时间标志数据不同历史时段。历史拉链的算法在数据库实现步骤上通常由如下2种方式：方式1：1) 获取当前的数据；2) 比较当前数据和历史数据，找出新增加的和变化的数据，存放在临时表中，把起始日期置为该数据所对应的日期，结束日期置为最大日期；3)针对对变化的历史数据数据对结束日期进行更新置为最大日期；4)从临时表向历史表中插入新增加的和变化的数据。方式2：1) 找出前一日的数据和当前的数据；2) 比较当前数据和前一日的数据，找出新增加的和更改后的数据；3) 比较前一日的数据和当前的数据，找出被删除的和更改前的数据；4) 从历史表中删除被删除的数据和更改前的数据；5) 向历史表中插入新增加的和更改后的数据，把起始日期置为该数据所对应的日期，结束日期置为最大日期；6) 向历史表中插入被删除的数据和更改前的数据，并把结束日期置为该数据所对应的日期。方式1与方式2比较而言实现上更为简洁，但具体采取何种实现方式需要参考实际数据处理量和数据库性能状况，方式2在数据处理量大的情况下效率会较高。.2.3 抽取作业调度抽取任务间关系的最大特点，就是相互依赖性和高度并发性，而抽取作业调度的关键，就是解决好依赖性和并发性二者的统一。在依赖性方面，作业调度模块要能够识别任务间的依赖关系，优先处理被依赖的任务，滞后并有选择地处理依赖任务。在并发性方面，作业调度模块在处理并发任务时，要顾及系统的资源和处理能力，过高的并