论文资料：成都住房公积金中心管理中心决策分析信息支持系统开发及开发平台采.doc

成都住房公积金中心管理中心决策分析信息支持系统开发及开发平台采购项目技术、商务要求及投标人资格条件预公告各潜在投标人：成都市政府采购服务中心受成成都住房公积金中心管理中心的委托，拟对成都住房公积金中心管理中心决策分析信息支持系统开发及开发平台采购项目进行公开招标。为确保政府采购当事人的合法权益，现就该项目的商务、技术要求及投标人资格条件等广泛征求各方的询问和意见，如有异议，请于2010年12月24日下午17:00前以书面形式提出，详细的技术、商务要求及投标人资格条件、联系方式见附件。成都市政府采购服务中心二一年十二月十七日附件：成都住房公积金中心管理中心决策分析信息支持系统开发及开发平台采购项目技术、商务条件及投标人资格条件一、采购项目技术、商务条件1.1.1. 说明本技术规格及要求是最低限度的技术要求，并未对一切技术细节做出规定，也未充分引述有关标准和规范的条文，投标人应保证提供符合本技术规格和有关国家标准的优质产品。1.1.2. 所遵循的标准和质量保证1、所采用的软件开发平台为目前IT业界通用的平台，并符合技术发展潮流。2、提供的产品应有完善的质量监督手段和质量保证体系，产品须符合国家标准和行业标准。3、所提供的所有技术文件中的技术指标均应符合相应的国家标准、行业标准和国际标准。4、应遵守有关地方的法规、法令和规定的有关要求。5、提供的货物所使用的度量衡单位，除技术规格中另有规定外应统一使用公制单位。1.2. 机构现状1.2.1. 中心组织架构以及业务现状成都住房公积金管理中心（以下简称“中心”）成立于2004年8月，是市政府直属的不以营利为目的的独立的正局级事业单位。下设10个职能处（室）和城区、新都、龙泉驿等15个管理部以及省级、铁路、石油3个分中心。中心对15个管理部实行垂直管理，对3个分中心实行授权管理。中心的主要职责为编制、执行住房公积金归集使用计划；负责记载职工住房公积金的缴存、提取、使用等情况；负责住房公积金的保值和归还；编制住房公积金归集、使用计划执行情况的报告。截止2009年10月底，中心累计归集住房公积金345.1亿元，归集余额176.5 亿元，缴存单位8518户，缴存职工人数107万；累计发放住房公积金贷款169.22亿元，贷款余额120.18亿元，累计发放户数10.7万户，支持职工购房面积1100万平方米，社会效益十分显著。1.2.2. 应用系统现状2007年10月，成都住房公积金管理中心启用新一代住房公积金综合业务系统支撑业务运行。该系统以“规范、安全、效率、效益”为目标，采用了“集中事权管理，委托事务办理，统一业务平台，全面监督控制，丰富服务渠道”的管理思想，以“以客户为中心规范业务，统一、灵活的业务流程与核算体系，稳定高效安全的运行，丰富的服务渠道接入，科学的决策模型”为建设目标。它主要由中心综合业务系统以及12家受托银行（包含工商银行、建设银行、中国银行、农业银行、交通银行等商业银行）中间业务平台（公积金部分）构成。中心综合业务系统运行环境为IBM P570小型机、采用IBM AIX 5.3操作系统、WebLogic应用服务器和Oracle 10g数据库。中心与各受托银行之间采用统一标准的接口规范通过SDH专线进行公积金业务实时联机交易，通过严格的控制规则，灵活的业务处理流程，完成了多级在线审批，实现中心作为“业务处理中心、资金营运中心、会计核算中心、风险控制中心”的主导地位。1.3. 项目背景随着综合业务系统的应用深入，数据资源越来越丰富。成都住房公积金管理中心信息化的发展已从建立业务信息系统阶段过渡到深度运用业务基础数据和智能决策支持阶段。随着成都住房公积金管理中心信息化向更高层次发展，需要有像数据仓库/商业智能（DW/BI）这样的集成化、智能化的高级应用叠加到整个成都住房公积金管理中心信息化的整体构建进程中来，能够为决策提供科学、准确的分析、决策、预测。 随着成都住房公积金管理中心综合业务系统数据大集中的实现，已经具备了对信息资源和业务数据进行规划、采集和应用能力，所积累的数据量也达到了一个相当可观的规模，使得建设基于数据仓库技术的决策分析平台系统成为可能。充分利用数据资源，发现数据背后隐含的信息和规律，为管理决策层提供综合、全面、准确的决策信息，为政策的制定提供依据的需求越来越迫切。因此，利用现代化技术手段全面支持决策分析工作，是中心信息化的重要应用和体现，将有利于提高决策水平，对于完善管理体系具有重要意义。 在此背景下，为适应社会需求，满足业务发展的要求，成都住房公积金管理中心需建设一套决策支持系统，为成都住房公积金管理中心业务的发展提供科学依据，为内部管理提升提供科学分析。 1.4. 项目目标成都住房公积金管理中心信息化建设，就是要在数据大集中带来的新的发展平台上充分发挥信息化的支撑作用，支持成都住房公积金管理中心整体工作的创新型发展。依托已积累的海量信息，深度应用大集中后的数据，在其基础上针对住成都房公积金管理中心各业务领域及各项业务之间的关系进行分析，从而实现对政策执行情况进行检验，对业务异常情况监测预警，对住房公积金管理中心内部进行监督考核，为领导下一步的决策提供科学、准确、及时的依据；从而促进成都住房公积金管理中心管理向科学化、精细化发展，提高住房公积金管理中心管理能力和服务能力。决策分析平台系统与业务应用系统间形成良好的互动。成都住房公积金管理中心决策分析平台的总体建设目标为，基于成都住房公积金管理中心已开展的归集、支取、贷款等业务数据，形成决策交换库数据，并在此交换库上进行数据清理、整合、加工处理，形成决策分析数据仓库，并在此基础上结合用户管理需求完成主题分析、监测预警、即席查询、预测分析等应用功能的开发和实施，为各级管理者提供不同级别、不同角色相应的业务数据分析功能，以保证决策的科学性、准确性、及时性。本次任务包括： 1完成决策分析平台系统的数据仓库设计和建设。 （1）实现对业务数据源数据的交换库生成及数据仓库的构建，实现决策分析数据的合理、集中存储，用以支撑决策分析的实现。（2）根据中心综合业务系统的特点，制定准确的数据转换规则，选择合适的抽取时机、抽取频率、追加策略和数据装载周期等数据集成策略，保证高效、高质地完成数据抽取、转换、加载，建立数据仓库。 （3）根据业务现状及业务需求，建立数据仓库模型，确定数据仓库的组织形式。 2完成决策分析平台系统的应用软件的开发。 （1）能够根据用户需求构建、设计分析主题，实现数据展示、分析、挖掘以及进行主题内部要素的扩充、主题的新增和主题的重构，并根据用户分析目标实施定制分析指标、维度和粒度。（2）根据业务需求及主题模型利用数据仓库的切片、切块、旋转、钻取、透视等技术，通过设计开发构建多角度、多视角的数据透视在线分析功能，在分析过程中形成、输出分析报表，并可对输出的报表进行计算、编辑等操作。（3）根据用户需求，应用数学、统计、管理学等常用的数据分析方法，建立业务分析模型，并开发相应的应用功能，使用户能够方便灵活地运用这些方法和功能，对数据进行分析处理和预测。（4）根据业务单位需求，建立单项业务和整体业务的监测预警指标体系、构建监测预警模型，确定预警线，制定预案。对数据仓库特定域的数据进行分析与监测，在达到预警线时，及时提供预警信息，供各级决策层参考，以便采取及时有效的措施。3负责决策分析平台应用软件实施工作，提供相关的技术支持。 4为用户提供软件培训。1.5. 项目建设原则成都住房公积金管理中心决策分析平台建设从整体上遵循“统一规划、分步实施、短期见效”原则，按照相关法律法规要求，结合成都住房公积金管理中心信息化建设总体规划，统一规划，分步实施。应用系统开发遵循以下原则：实用性原则：以满足成都住房公积金管理中心业务需求为首要目标。标准性原则：系统开发应符合软件工程标准，保证系统的灵活性。 可靠性原则：系统设计应采用成熟、稳定、可靠的软件技术，保证系统在大数据量、高并发的情况下不间断地安全运行。 可操作性原则：操作方式简便灵活；操作界面设计风格统一。软件设计自动化程度较高。 可扩展原则：软件设计要简明，各个功能模块间的耦合度小，适应业务发展需要，便于系统的继承和扩展。 可维护性原则：系统应具有良好的结构，各个部分应有明确和完整的定义，使得局部的修改不影响全局和其他部分的结构和运行。 1.6. 项目业务要求决策分析平台主要是借助技术手段对已有的海量数据进行整合、清洗、处理，并对这些数据进行深度利用。系统主要包括以下几个方面的功能：数据整合、统计查询、主题分析、监测预警、预测分析等。1.6.1. 分层决策决策分析系统必须按照宏观（中心级）、中观（处级）、微观（业务级）不同级别、不同角色进行相应的数据的分析，保证不同的粒度观测角度的个性化与系统统一的协调性。决策分析提供全面的、全局的分析视角；中观决策提供局部的、分析视角；微观决策提供微粒度的业务辅助决策视角。1.6.2. 数据整合决策分析平台的基础就是海量数据。成都住房公积金管理中心决策分析平台系统的数据源主要基于决策交换库数据。数据的获取主要采用定期采集方式为主，同时也提供临时采集和抽取的方式。原始数据和汇总数据都是数据仓库的重要内容。利用信息技术手段进行数据采集，从系统中直接获取信息，提高信息的准确性和及时性。从各数据源中所获得的数据按照决策分析平台的需要，经过清洗、转换、加工后，装载到数据仓库中进行管理，以备下一步的统计、分析使用。数据整合必须同时提供全量和增量策略。1.6.3. 即席查询利用数据仓库中的数据，实现即席查询。支持对数据仓库所存储各类数据的自定义查询。提供方便、快捷的查询定制功能。完成基于业务模型和数据仓库的即席查询功能，实现紧密结合业务管理的分析报告的生成，并能自动生成基于业务数据仓库的图表内嵌功能。1.6.4. 主题分析决策分析平台应用软件以决策交换库、分析数据仓库以及多维立方体（Cube）等作为数据源，以成熟的BI展现软件作为工具，实现任意数据的切片、旋转、钻取等在线分析处理（OLAP）功能。系统从业务服务效率、客户行为、资金运营管理等多个角度，实现同期、环比、历史趋势等主题分析功能。并提供完善丰富的图表展示。1.6.5. 监测预警根据业务单位需求，在深入调查研究业务特点、业务之间的关联关系，结合业务的变化发展趋势，建立单项业务和整体业务的监测预警指标体系、研制监测预警模型，确定预警线，制定预案。对数据仓库特定域的数据进行分析与监测，在达到预警线时，及时提供预警信息，供各级决策层参考，以便采取及时有效的措施。制定评估方案，研制评估模型， 对数据仓库特定域的数据进行评估分析，分析已开展业务的执行力度，供各级决策层对业务开展进行考察评估，使得业务经办过程可视化。1.6.6. 预测分析应用统计分析的方法和工具，在对住房公积金管理中心各项业务调查研究的基础上，建立适合业务需求的预测分析模型，对住房公积金的未来发展趋势和状况进行定量和定性的描述、分析，做出相应的预测。1.7. 决策分析平台指标体系要求1) 配合成都住房公积金管理中心研究制定统一的决策分析平台指标体系。制定的指标体系应对指标名称、指标类型、指标长度、标识和指标解释给出具体定义，进行编码。 2) 决策分析平台指标范围和定义应符合住房公积金管理中心业务有关规范和要求，与交换区的基础指标相衔接，满足住房公积金管理中心部门管理需要，指标应适应业务发展的需要进行扩充。3) 软件研发过程中形成的数据标准须符合住房公积金管理中心部的指标体系。 1.8. 技术开发总体要求 1) 按照基于J2EE 标准的三层架构原则进行整体规划和建设，满足未来发展的要求，具备可扩展性，保证技术上的先进性。基于BS模式实现。2) 支持多种数据仓库开发平台。3) 数据处理、数据整合应用支持多种ETL平台间的平滑迁移，支持多种OLAP服务器、支持多种前端展示工具。4) 支持合理的数据访问优化策略，缩短读取时间，提高数据检索效率。 5) 能够对数据仓库中的海量数据进行合理的存储空间规划。 6) 将各系统中口径不相同的数据进行规范化、标准化、集成化，按唯一性、同一性和共享性原则重组基础数据，实现统一基础数据、统一统计口径、统一数据管理。 7) 能够为将来的其他系统数据源预留出易于使用的接口，便于业务扩展。 8) 采用能够充分提升用户界面体验的有关技术，提供友好的用户界面。1.9. 技术开发总体约束 1) 性能要求简单的查询和报表生成平均响应时间在2秒以内，最大响应时间不超过10秒；复杂报表生成和一般的分析统计平均响应时间在10秒以内，最大响应时间不超过20秒；复杂的分析应用平均响应时间在30秒以内，最大响应时间不超过60秒。系统的设计应能确保系统性能地提高与硬件的增长呈线性增长关系。2) 数据要求系统保存已有和未来至少三年的（共十年以上）最明细的业务数据。进入数据仓库的数据应与业务系统中的数据保持一致。3) 扩展性要求系统应能适应公积金数据应用需求复杂多变的要求，采用构件化设计思想，系统框架与业务逻辑分离，具备开放的体系结构。系统的设计应确保在用户需求变更或增加时系统可以灵活地、方便地扩展。4) 可靠性要求排除人为误操作因素，由系统自身原因导致的系统崩溃故障，平均无故障时间（MTBF）应大于365 天，平均修复时间（MTTR）应小于4 小时。排除人为误操作因素，由系统自身原因导致的系统错误故障,平均无故障时间（MTBF）应大于100 天，平均修复时间（MTTR）应小于30 分钟。系统必须支持连续724 小时不间断地工作，系统中的任一构件更新、加载时，在不更新与上下构件的接口的前提下，不影响业务运转和服务。系统必须支持负载均衡能力，支持应用部署在多台服务器上，避免应用系统的单点故障。5) 可操作性要求系统功能的实现应尽可能自动化，减少人工操作环节，用户操作界面应简明、实用、易于学习和掌握。1.10. 数据模型设计要求投标方案应建立起一个业务覆盖全面、层次划分合理的数据模型。数据模型方案应符合如下要求：1) 数据模型拥有良好的层次架构数据模型应当在数据仓库理论指导下，在充分考虑数据现状、业务特点的基础上进行层次架构的规划设计，中心数据仓库数据存储分为三个层次：原始数据层、主题数据层、汇总层。原始数据层：原始数据层是为了保证数据转换的顺利进行而建立的数据存储空间，它是业务系统原始数据进入主题数据区前的存储区。业务系统的数据首先快速复制到原始数据层中，再从原始数据层经过清洗、转换、映射等复杂的数据处理转移到主题数据层中。在数据应用的运行和使用过程中，原始数据层的作用主要体现在以下三个方面： 减少对业务系统资源的占用，避免复杂数据转换对业务系统的影响； 将不同形式的源数据转换为统一的存储形式。 如果主题数据层发生系统故障，可以直接从原始数据层进行数据恢复，而不必重新从业务系统原始数据抽取。主题数据层：主题数据层是数据应用平台底层存储的核心，主要功能是存储和管理从原始数据层通过ETL过程得到的历史和当前的业务明细数据，但数据的组织方式不同于原始的业务系统。主题数据层数据结构一般符合第三范式要求，保存全量的最细粒度数据。主题数据层建模符合面向主题分析的需求，考虑到未来的变化，应具有很好的稳定性和可扩展性，一方面是业务系统变化时模型应保持稳定，一方面是平台需求的变化时模型应保持稳定。主题的确定应该保证其具有独立的内涵和明确的界限，并能为数据应用提供所要求的一切内容。在数据应用的运行和使用过程中，主题数据层的作用主要体现在以下几个方面： 直接支持前端部分查询、预警、报表等应用； 为基于汇总层的统计分析应用提供明细数据。汇总层：汇总层中的数据由主题数据层的详细数据聚合而来，根据数据聚合程度的不同包含轻度聚合、中度聚合和高度聚合三种不同的层次。汇总的方式将依据数据量的大小、使用需求和使用频度综合考虑。根据业务需求分类成多个不同的子区，每个子区完成不同的应用需求。在数据应用过程中，汇总层的作用主要体现在以下几个方面：l 服务于应用主题，根据用户需求灵活定制；l 满足统计、报表、预警、绩效考核等需求；l 利用存储空间换时间，提升系统运行效率；l 汇总层面向聚集数据，在聚集数据上的分析可下钻到明细数据。2) 主题数据层、汇总层建模要求主题数据区数据模型一般要求符合三范式的要求，但允许在一定程度上打破三范式的要求，以满足业务需求或提高数据库的性能的要求。采用自顶向下的方法实现底层数据存储的建模，主题数据层的建模无论数据应用需求是否完备，都必须根据业务通盘考虑、全局规划，从无到有，而且不能照抄照搬源业务生产系统的数据模型。主题数据层的建模利用科学合理的主题规划，通过业务自身的主题关联，将相对无序的业务数据串联整合成有机的数据链集合，并实施规范化梳理。投标方案应详细说明以下内容：从宏观到微观，业务数据主题应该逐级精细，实现原子化，确保数据的最后内聚和最大共享能力。宏观到中观的主题框架必须科学合理，保障完备性，为微观层面主题深化与扩展保留空间。投标方案应给出宏观主题划分方法和依据，并给出所有宏观主题。对主题规划进行充分性、必要性论证，保证规划是科学、合理、满足公积金领域业务要求的。投标方案应以满足业务能力为目标对宏、中观主题的完备性进行验证。详细描述主题数据层建模采取的其他措施。比如：主题数据层的模型基于三范式构建；保存数据的历史痕迹等等。根据业务需求，准确指定事实表和维度表，进行维度建模提供MOLAP操作提供增量加载数据的粒度在同一CUBE中必须统一。针对各个维度作预处理，如按照维度进行预先的统计、分类、排序等。1.11. 数据的抽取、转换和加载要求 投标方案应结合公积金行业的数据特性，提出完整的ETL方案，方案要求：1）阐述数据抽取、转换和加载各部分所用的技术和方案2）阐述在ETL过程中，针对业务数据特性的数据清洗规则和数据质量保障机制3）阐述增量抽取变化数据方案，若提供多种方案，则进行方案的比较。4）阐述ETL异常数据的解决方案及处理流程。1.12. 应用支撑平台建设要求数据应用功能规划应支撑现有业务需求，同时业务需求也是不断发展和完善的，各类业务需求都要对系统内的数据进行运算、分析、挖掘以得到自己所需要的信息，其针对的数据源和技术实现的逻辑都应该是共同的，因此，应能抽象出一个公用的分析应用平台，在此平台上逐渐灌注各类具体的数据应用业务需求，快速搭建各类数据应用。最终用户看到的是多个数据应用系统，而实质性的技术支撑都是统一的技术组件服务。因此，建设统一的应用支撑平台是数据分析应用功能规划的关键。应用支撑平台的设计原则是： 统一公共服务：满足业务能力要求，为上层数据应用提供共同的技术体系框架、公共的基础组件服务； 高扩展性：以不编程、图形化的方式灵活适应公积金行业各种常见业务场景变化，比如查询、统计、预警、评估等； 高可管理性：提供统一的业务数据视图，夯实分析基础，实现分析口径的统一管理。基于上述原则，对投标方案要求如下：根据应用支撑平台的设计定位和原则，提供应用支撑平台解决方案，详细说明应用支撑平台设计架构、功能组成和特点。应用支撑平台的功能设计应包括但不限于以下几个方面：分析元素的统一管理：对分析所需的数据项、指标、模型等元素进行统一管理，同时提供面向业务人员的、便捷的管理环境。分析工具的统一管理：提供面向各种常见分析场景的分析工具，分析场景应包括但不限于预警监控、评估选案、查询统计，分析工具应具有图形化、向导式、不编程的特点。元数据管理：提供对元数据的管理功能，建立统一的数据地图。任务管理：提供统一的工作流管理功能，灵活、便捷的实现流程定义。1.13. 其他通用技术要求各投标人需根据自身对成都住房公积金管理中心决策分析平台建设的理解及经验，在投标文件中对本项目其他相关的技术采用、系统环境设计以及质量保障等内容提出相应的解决方案。1) 决策分析平台总体架构采用开放、规范、先进、成熟的技术；采用基于WEB的三层分布式体系结构，分层的、组件化的设计理念，广泛应用符合国际标准的技术，保证决策分析平台的健壮性、可扩展性、可维护性；保证决策分析平台的互联性和开放性；采用开放式标准接口，实现与已有系统优良集成，与未来新系统的平滑过渡。2) 决策分析平台网络结构应以实现内外网隔离的基础上应该能够实现与业务系统及其他系统的互联互通，在业务处理上保持一致，与各系统准确及时交互，保证各类数据完整一致。3) 采用面向对象的软件分析、设计、编码及基于公用组件化设计框架的开发方法，对业务进行抽象，科学规划信息决策分析平台的公用组件框架，作为整个应用系统的高附加应用，以确保快速搭建应用系统、保证信息系统具有良好的可拆分性、方便决策分析平台的维护升级；4) 决策分析平台设计采用国际标准的UML建模语言和MVC应用开发模型，支持主题业务逻辑独立封装。5) 采用先进的客户端技术实现多客户端模式、一套组件，多种展示模式；人性化操作、快捷易用。6) 决策分析平台安全性是需考虑重要组成部分，通过多层次、多角度、多渠道、多种措施保证系统的安全，包括安全软件、用户权限设计、安全策略和安全管理制度等在内多层次的安全架构；解决方案应覆盖各个层次的安全问题和应用数据流的各个环节。7) 投标人应制定决策分析平台完整的备份与恢复方案，优化备份与恢复的策略，并组织实施。包括操作系统的备份与恢复策略、应用服务器的备份与恢复策略、数据库的备份与恢复策略、应用程序的备份与恢复策略。8) 决策分析平台应在先进的、完善的项目管理机制下进行构建,以确保决策分析平台的质量。9) 提供合理的完整的软件选型方案。10) 提供全面完善的测试方案，以确保产品的质量保证。11) 提供验收方案，具备完整性和合理性。12) 针对中心技术人员提供详实可行的培训方案， 需对不同的应用软件、系统软件提供有针对性的培训，并提供相关培训资料（如PPT、文档等）。13) 就本次项目提供工程技术支持、技术支持响应时间和技术支持其它承诺的方案。14) 提供完善的后期运行维护方案，服务范围包括决策分析平台安装、升级、调试、性能调优、系统管理等。1.14. 数据仓库及商业智能工具说明及选型要求1.14.1. 数据集成工具招标技术要求（要求支持2CPU ，UNIX操作系统）1. 开放性：ETL工具处理过程可支持多种操作系统平台，如UNIX、WINDOWS、AIX、HP UNIX、等，并且可支持主流硬件平台,如HP、IBM、SUN等，并且可支持主流数据库,如ORACLE、SYBASE、DB2、SQL SERVER等。能够支持各种平台的异构数据源的数据、包括结构化系统和非结构化的数据。2. 数据抽取：采用高性能的数据抽取接口，比如：专用数据库驱动接口、JDBC、ODBC接口等。数据抽取过程支持增量抽取、完全抽取以及基于日志抽取等抽取策略，对于数据源系统支持异步抽取或同步抽取。3. 数据转换：对常用的数据转换功能，应都有现成的知识模块支持，无需人工编程实现。同时模板是完全可扩展的，模板中的代码是开放的，并且技术人员能够通过图形化用户界面编辑它们去实现新的功能。4. 数据装载：应支持从抽取到转换和装载的不落地的策略，同时转换可以直接在数据源或者目标数据库目标中完成。减少数据在数据源、ETL服务器和数据仓库目标之间的多次传递和转换，从而提高性能。5. 能图形化的设计和定义抽取流程。6. 管理性：可以将数据集成工具执行或开发的权利赋给指定的用户，避免不相关人员的误操作，并能记录操作人员的使用情况。具有版本管理的功能，确保团队共同开发时对最新版本的维护。7. 监控性：能对每一个数据操作过程进行严密的监控，包括数据处理的流程到了哪一步？每一步处理了多少数据？性能参数是多少？ 8. 易用性：处理过程可提供图形化的操作界面，具有良好的易用性。支持声明式设计，只需设计业务逻辑上数据过程做什么，而不需要描述它底层数据库的技术实现细节。 同时能很好地支持Oracle等不同数据库，针对不同数据库生成相应优化的执行脚本。生成的ETL执行脚本是开放的、可编辑的。并且提供脚本的编辑模板。9. 错误控制：处理过程可以定义外部数据记录的错误限制，如发现最多1000条错误数据记录时停止进行处理，同时将发生错误的数据记录加到相应的错误表中。10. 字符集支持：处理过程支持各种字符集的转换。11. 应具有数据增量抽取功能，数据增量抽取功能需支持各种数据库，对于Oracle数据库和DB2/400支持通过日志方式获取增量数据；所获得的数据增量应可以直接传入数据集成工具进行处理，无需落地。数据增量工具应支持图形化界面配置和管理，设置简单。12. 要求有丰富的调度方式：自动调度、人工调度、脚本调度等。13. 元数据的存储和管理：元数据应以数据库存储，能提供动态的影响分析，便于管理，维护和扩展。14. 内置支持与Web服务的双向操作，即可以将Web服务作为数据源进行处理，同时内置地，无需编程即可将数据集成操作（抽取，转换和加载）以Web服务方式发布出来，供其他业务系统调用。1.14.2. BI平台套件（包含多维分析引擎(OLAP)及前端展示工具，要求支持 50 User ，UNIX操作系统)1.14.2.1 多维分析引擎(OLAP)支持主流的操作系统,特别是Unix和Linux1. 支持Java、JSP/ASP、 C、Visual Basic、DreamWeaver的编程开发，支持XMLA、CWM和Java OLAP API，降低开发成本和集成复杂度；2. 支持MDX标准多维查询语言；3. 各种主流前端工具可以使用该OLAP工具作为后端的数据平台；4. 用户能方便查看对数据进行分析的多维概念视图；5. 具备图形化的模型设计工具；6. 支持MOLAP、HOLAP以及ROLAP等能力；7. 提供MOLAP方式，具有从CUBE钻透到关系数据库的能力；8. 支持数据分区；9. 能提供丰富的各类型多维计算函数，具有扩展性。包括数学计算、 财务、预测、统计、日期、关系、条件、判断、集合等；10. 支持MS Office(PPT,Word,Excel)对OLAP进行访问；11. 用户自定义的Function可以加载到OLAP引擎中；12. 提供统计、分析和报表处理功能。具备简易制作各种复杂的不平衡报表的功能；13. 支持时间序列分析，支持带自动的聚合计算，也可灵活定义计算脚本，完成复杂的计算规则；14. 支持结果回写多维数据库，支持回写结果授权，支持回写痕迹保留，回写时，确保相关数据的安全性和正确性，支持what-if 虚拟情景分析；15. 支撑企业绩效管理应用所需的高级分析和复杂计算功能。包括预测、趋势、相关度分析以及复杂计算和数据挖掘聚簇分析、决策树、神经网络计算等；16. 根据数据特征提供属性维、共享成员、混合存储等多种灵活维度设计，支持父子维；17. 处理上千万成员维度的分析主题需求；18. 支持不同数据源搭建立方体，数据可分批加载；19. 支持增量数据更新；20. 在安全控制上提供开放性接口，能够与第三方安全产品集成。和NTLM、MSAD、LDAP以及兼容的安全系统无缝集成；21. 支持集中的用户权限管理，系统管理员具有对Cube分级访问的控制能力。例如，部门领导限于查看其管辖部门内的详尽数据而只可查看其它部门的主要汇总数据，这时可将各个部门的数据作一定的限制和安全处理；再比如，根据用户的不同级别，允许上级拥有下级的所有数据访问权限而限制下级对上级的数据访问权限和数据访问范围；22. 对数据粒度能控制到单元格 (cell level security) 层次；23. 对TB规模的大数据量具有高性能的处理能力。对大数据量的多维数据集生成时间需在本业务能够承受的范围内（依据具体测试要求而定）。对联机查询业务的响应时间在秒级内（依据具体测试的功能和数据量要求而定）。通过鼠标拖拉即可实现钻取、旋转、切片等基本的OLAP分析处理功能；24. 支持多用户并发访问的能力；25. 单个立方体上具备数百GB的规模；26. 支持动态聚合，也可设计数据上层节点的聚合存储， 实现大立方体下的快速的查询响应速度；27. 支持上千万成员维度的分析主题的处理，支持大量维度分析主题的处理；1.14.2.2 前端展示工具功能要求2. 支持B/S架构，用户通过浏览器访问，不需要安装插件3. 同一界面完成仪表盘、OLAP分析、报表和即席查询功能4. 在同一界面中完成报表的开发和发布5. 增强的交互性，能够实现跨维度的任意钻取而不需要编写代码6. 仪表盘功能灵活，用户可以对仪表盘进行一些设置，从而使得在整个仪表盘中钻取任何一张报表，都在当前仪表盘中展开。用户也可以设置全局的过滤器或者提示条件7. 丰富强劲的图形引擎8. 灵活的输出格式(PDF, Excel, xml，PPT等)9. 主动式订阅和报警1