居然之家ERP项目方案建议书-技术卷-V3 1

客户北京居然之家云地一体家居连锁有限公司文件名实施方案卷项目居然之家ERP项目版本V1.0第89页 ©2016。欲了解更多信息，请联系德勤管理咨询（上海）有限公司北京分公司居然之家ERP项目实施建议书实施方案卷（正本） 德勤管理咨询(上海)有限公司北京分公司2016年7月

声明

此文件是根据德勤管理咨询（上海）有限公司北京分公司（以下简称“德勤咨询”）的业务、商务或知识产权相关的信息制作的，或包含以上信息，是德勤提供给北京居然之家云地一体家居连锁有限公司的投标资料。未经德勤咨询的允许，不得擅自使用或透露给任何第三方。此文件和文件内包含的全部或部分内容，不得对外使用或泄漏，不得给予与德勤咨询存在商业竞争关系的任何方。如果贵公司对这份项目标书有任何问题或意见，欢迎随时垂询，德勤咨询将竭诚给出准确快速的回复。

目录TOC\o"1-3"\f\u1 德勤对居然之家发展的理解 121.1 居然之家所处行业的业务发展现状 121.2 居然之家发展业务发展理解 132 居然之家ERP项目目标与范围 222.1 本次项目实施的目标 222.2 本次项目实施的范围 232.3 本次项目实施的产品 243 居然之家ERP项目的设计思路 263.1 “战略驱动，业务引领”，打造卓越型ERP管控平台 263.2 “顶层设计、流程驱动”的ERP建设总体思路 303.3 德勤全球家居行业蓝本（IndustryPrint） 334 居然之家IT规划方案 354.1 IT规划 354.1.1 阶段1：现状诊断与分析阶段 354.1.2 阶段2：信息化远景规划阶段 404.1.3 阶段3：实施路线规划阶段 445 大数据中心 485.1 家居行业大数据转型 485.2 大数据分析整体思路 515.3 大数据分析中心关键指标体系设计 525.3.1 大数据分析指标梳理方法 525.3.2 居然之家指标梳理方法 535.4 大数据分析中心主题设计 575.4.1 大数据分析中心总体框架 575.4.2 大数据移动平台分析主题设计思路 585.4.3 消费者与会员管理主题 615.4.4 经营管理主题 645.4.5 供应链管理主题 705.4.6 风险管理主题 725.4.7 人力资源管理主题 745.5 大数据移动平台设计思路 765.5.1 大数据移动平台设计原则 765.5.2 大数据移动平台样例 775.6 大数据平台技术架构方案 805.6.1 总体架构 805.6.2 EDW实现 955.6.3 ETL数据处理 1005.6.4 数据填报平台 1125.6.5 用户权限解决方案 1146 五大平台方案 1196.1 商品主数据平台方案 1196.1.1 主数据建设总体思路 1196.1.2 主数据管理框架体系 1216.1.3 商品主数据现状 1316.1.4 商品主数据平台核心业务方案 1336.1.5 商品主数据平台系统方案 1406.1.6 商品主数据清理总体思路 1446.2 会员数据平台方案 1466.2.1 会员数据现状 1466.2.2 会员关键业务举措与方案 1486.3 结算中心平台方案 1636.3.1 结算中心现状 1636.3.2 结算中心关键业务举措分析 1646.3.3 结算中心平台核心业务方案 1656.3.4 结算中心平台核心功能模块 1676.4 营销服务平台方案 1756.4.1 营销服务关键业务举措与方案 1756.5 订单交易平台方案 2026.5.1 订单交易系统现状 2026.5.2 订单交易关键业务举措分析 2026.5.3 订单交易平台核心业务方案 2037 核心业务系统方案 2147.1 市场管理核心业务方案 2147.1.1 招商管理 2147.1.2 AxGIS图形化方案为招商管理增值助力 2227.1.3 租赁管理 2247.1.4 租赁日常物业维护管理 2307.1.5 JDE与EBS财务系统的接口 2317.2 超市管理核心业务方案 2337.2.1 超市管理的现状 2337.2.2 超市管理的关键业务举措分析 2337.2.3 超市管理解决方案与业务流程简介 2367.3 设计装修核心业务方案 2877.3.1 设计装修关键业务举措分析 2877.3.2 业务方案及关键点 2997.4 金融管理核心业务方案 3087.4.1 小额贷款业务方案 3097.4.2 保理业务方案 3127.4.3 风控管理方案 3137.5 家政物业管理核心业务方案 3167.5.1 家政管理 3167.5.2 物业管理 3187.5.3 “一次消费，终生服务，更多机会” 3197.6 物流配送管理核心业务方案 3217.6.1 物流业务的支撑 3217.6.2 跨行业配送的整合 3257.6.3 物流中心的建设 3257.6.4 配送方案的优化 3267.7 财务核算业务方案 3287.7.1 财务体系架构 3297.7.2 财务标准化体系 3327.7.3 业务财务一体化 3347.7.4 内部控制管理 3437.8 财务共享服务业务方案 3497.8.1 组织变革与流程梳理 3507.8.2 报账平台总体方案 3527.8.3 报账业务流程 3547.8.4 系统接口方案 3647.8.5 通知管理功能 3707.8.6 原始单据管理 3717.8.7 预算和额度控制 3757.8.8 信用报销体系 3767.8.9 查询统计功能要求 3777.9 财务合并报表方案 3787.9.1 合并组织架构 3787.9.2 数据采集管理 3807.9.3 合并流程管理 3827.9.4 外币折算方案 3847.9.5 准则转换方案 3857.9.6 内部往来及交易抵消方案 3877.9.7 股权抵销方案 3887.9.8 合并底稿及结果展现方案 3897.9.9 数据验证及审核方案 3907.9.10 查询输出方案 3917.9.11 分析平台展示 3927.9.12 用户管理方案 3937.9.13 维度与维值设计 3957.9.14 相关管理建议 3957.9.15 扩展性 3957.10 全面预算业务方案 3967.10.1 全面预算管控体系设计 3997.10.2 全面预算管理流程设计 4007.10.3 全面预算中长期预测模型 4037.10.4 全面预算编制模型设计 4047.10.5 预算执行控制方案设计 4107.10.6 全面预算管理分析模型设计 4127.10.7 全面预算管理考核评价体系 4148 系统接口方案 4168.1 居然在线改造及与ERP接口方案 4178.2 设计家与ERP接口方案 4198.3 HR系统与ERP系统接口方案 4208.4 OA流程审批与ERP系统接口方案 4219 技术解决方案 4229.1 硬件部署方案 4229.1.1 OracleEBS硬件部署建议 4229.1.2 JDE硬件部署建议 4229.1.3 SiebelCRM硬件部署建议 4239.1.4 OracleRetail硬件部署建议 4249.1.5 Hyperion硬件部署建议 4249.1.6 BI硬件部署建议 4259.1.7 MDM硬件部署建议 4259.1.8 单点登录硬件部署建议 4269.1.9 SOA硬件部署建议 4269.1.10 备份硬件建议 4279.1.11 容灾硬件建议 4279.2 Sizing及硬件建议配置 4299.2.1 Sizing评估方法 4299.2.2 上线试点阶段硬件建议配置 4309.2.3 全面推广阶段硬件建议配置 4439.3 系统安全解决方案 4579.4 应用集成解决方案 4629.4.1 单点登录解决方案 4629.5 客户化开发解决方案 4689.5.1 技术开发管理 4689.5.2 环境策略 4699.5.3 技术开发流程 4709.5.4 可复用的德勤客户化成果 4739.5.5 技术方面的知识转移 4739.6 运维方案 4779.6.1 居然之家ERP系统运维范围 4779.6.2 居然之家ERP系统运维工作重心 4779.6.3 居然之家ERP运维组织架构与人员配置 4789.6.4 居然之家ERP系统运维管理手段 4849.6.5 问题处理流程 4849.6.6 紧急事件处理 4859.6.7 服务器备份及安全策略 4869.6.8 自动化部署与升级方案 48810 项目推进策略 49310.1 项目推进的总体策略 49310.2 一期：模板建设期总体计划 49410.3 二期：全面推广建设期总体计划 49610.4 三期：纵深应用期总体计划 49810.5 项目推广成功保障措施 50010.5.1 项目一期总结“快速推广套件” 50010.5.2 集中+分散、渠道多样、形式丰富的培训模式 50010.5.3 集团总体方案一致性与个体差异化的平衡 50210.5.4 集团统一运维与现场支持相结合 50310.5.5 成立“数据管控组”，专职负责把控数据整理的质量与进度 50411 项目管理方案 50611.1 德勤的项目实施方法论 50611.2 项目各阶段主要工作任务 50811.2.1 项目启动 50811.2.2 蓝图设计 50811.2.3 系统实现 50911.2.4 上线准备 50911.2.5 系统切换 51011.2.6 上线运维支持 51011.3 项目交付品 51011.3.1 项目各阶段交付品清单 51011.3.2 项目交付品的提交与反馈 51111.3.3 项目交付品归档管理 51111.4 项目组织结构 51211.4.1 对本次项目实施的组织架构建议 51211.4.2 纵向：项目组织架构及其职责 51411.4.3 横向：德勤和居然之家联合项目团队及其职责 51711.5 项目管理方法与过程控制 51811.5.1 德勤管理方法论体系 51811.5.2 计划管理 51911.5.3 风险管理 52111.5.4 沟通管理 52411.5.5 问题管理 52611.5.6 变更管理 52911.5.7 质量管理 53011.5.8 文档管理 53211.6 服务与支持 53211.6.1 后续支持服务概述 53211.6.2 后续支持服务内容和方式 53311.6.3 后续支持服务流程 53511.6.4 运维体系和团队的建立 53611.7 客户方配合要求 53811.8 项目成功的关键性假设 53911.8.1 对居然之家使用的软件产品的假设 53911.8.2 对居然之家的硬件环境及网络环境管理的假设 53911.8.3 对本项目建设过程的假设 54011.8.4 对居然之家的项目管理的假设 54011.8.5 对居然之家用户参与的假设 541附录1：居然之家ERP项目培训服务计划 543附录1.1 培训与知识转移体系 543附录1.1.1针对居然之家的项目培训与知识转移体系 543附录1.1.2 针对居然之家项目的三级用户培训架构 544附录1.1.3 提供纵横结合的分层级、全方位课程体系和培训计划 544附录1.1.4 针对居然之家开发的多形式培训方式 546附录1.2 居然之家项目培训课程计划 547附录2：居然之家ERP项目实施验收方法 549附录2.1验收标的 549附录2.2验收组织形式 549附录2.3验收结束标志 549附录2.4项目交付品验收单 550附录3：居然之家ERP项目方案书一对一应答书 552附录4：投标人资质证明 575附录4.1法人营业执照 575附录4.2法人代表授权书 577附录4.3法人授权代表身份证 578附录4.4Oracle软件授权 579附录4.5财务、技术、人力和实施能力等证明材料 581附录4.5.1德勤财务能力介绍 581附录4.5.2成熟的企业信息化解决方案 581附录4.5.3德勤的服务能力介绍 588附录4.5.4德勤质量保证体系及证明 590附录4.6组织机构代码证 592附录4.7税务登记证 593附录4.8计算机软件著作权登记书 595附录4.9软件产品认定证书 599附录4.10Oracle钻石级合作伙伴资质 604附录4.11德勤的Oracle全球系统集成Titan奖 605附录4.12德勤的CMMI5级证书 606附录5：投标人基本信息 607附录5.1投标人公司信息 607附录5.1.1德勤全球 607附录5.1.2德勤中国 613附录5.1.3德勤财务状况说明_FY14 617附录5.1.4德勤财务状况说明_FY15 621附录5.2项目人员简历 624附录5.3无诉讼案件声明 746附录5.4投标人公司市场地位 747附录5.5近期履行类似合同 757附录5.6本项目联系人 765附录6：居然之家ERP项目保密协议承诺书 766客户北京居然之家云地一体家居连锁有限公司文件名实施方案卷项目居然之家ERP项目版本V1.0系统接口方案面向服务的体系结构（SOA）解决方案德勤团队基于对此次ERP项目的理解，以及丰富的大型分布式系统解决方案经验，由于此次ERP系统需要对接四大系统，分别是居然在线，设计之家，HR系统以及OA流程审批系统。因为对接系统多，接口复杂，更考虑到未来需要有更多系统和ERP系统对接，德勤团队采用面向服务的体系结构（SOA）解决方案，可以解决目前四大系统对ERP面向消息和服务的接口需求，同时满足未来其他系统对ERP系统面向事件的接口需求。ESB构建松散耦合的SOA架构通过构建SOA将应用系统划分成更小的服务，这些服务通过标准协议进行通信，并具有定义良好的接口。这样做的优势在于，让居然之家整个ERP系统更为灵活，整个ERP系统的各个部分之间不存在紧密耦合。松散耦合且具有平台独立性的服务的实现通过使用企业服务总线（EnterpriseServiceBus）ESB获得，ESB不但充当使用不同数据和消息格式、网络协议和编程语言的服务之间的“粘合剂”，而且充当服务使用者和服务提供者之间的中间层，允许部署中介，以执行各种操作，如向交互应用服务质量或执行所需的数据转换。基于ESB的SOA集成方案架构如下图所示：基于ESB构建的居然之家ERP系统ESB提供了一种开放的、基于标准的消息机制，通过简单的标准适配器和接口，来完成粗粒度应用（服务）和其他组件之间的互操作，能够满足居然之家环境的集成需求。它可以在不改变现有基础结构的情况下让新旧系统实现互操作。通过使用ESB，可以在几乎不更改代码的情况下，以一种无缝的非侵入方式使居然之家已有的系统具有全新的服务接口，并能够在部署环境中支持任何标准。更重要的是，充当“缓冲器”的ESB（负责在诸多服务之间转换业务逻辑和数据格式）与服务逻辑相分离，从而使得不同的应用系统可以同时使用同一服务，用不着在系统或者数据发生变化时，改动服务代码。并最终居然之家ERP系统与其他系统的整体架构图如下所示：每个系统既是服务提供者，也是服务消费者，通过统一的ESB服务注册，实现各系统间的松散耦合。整个ERP系统可以不受限制地重复使用软件、把各种资源互连起来，只要项目实施团队选用标准接口包装已有的居然之家旧系统、把新的应用系统构建成服务，那么其他应用系统就可以很方便的和已有居然之家系统以及新系统之家进行接口整合。居然在线改造及与ERP接口方案ERP系统与居然在线系统之间的接口实现两系统之间双向的信息交互，此接口开发工作由ERP系统和居然在线系统两边共同完成。对于卖场业态的销售管理，由于居然之家已经在推广线上线下使用一致的居然在线平台。未来建议对这部分业务进行一定的适应性改造，以满足更多门店的需求和与诸如订单、结算、会员的平台的集成。ERP系统与居然在线系统之间主要有主数据，会员，订单，结算，店铺，售后以及优惠券的数据接口。由于与旧鼎捷ERP系统之间的接口采用WebService服务，本次集成德勤依然建议使用WebService接口集成方式，ERP系统开发开发原鼎捷ERP存在的接口即可。WebService具体实现思路如下：确定ERP系统的服务角色，服务消费者或服务提供者确定服务消息格式，数据字段定义确定服务触发频率以及数据量确定数据时效性（异步或者同步）具体数据过程如下图所示：而原需要手工导入的如门店信息，楼栋信息，楼层信息，产地信息，行政区域信息，销售区域信息，门店与区域分公司对应关系这些主数据信息因为数据量大，集成映射规则会比较复杂，传统开发难度大，由于两端都是结构化数据，德勤推荐使用ETL工具来集成ERP与居然之家系统，如下图所示：采用ETL集成方式的优点如下：不需要编写底层代码（如用Java来编写），只需要定义映射规则映射规则变化时，可以灵活修改规则，不需要改底层代码可以更加直观监控运行情适应数据量大的系统间集成底层代码可以更加直观监控运行情具体实现思路如下：在ETL工具中定义数据源和目标系统。定义数据源和目标系统的数据映射关系和数据转换规则；定义工作流以支持数据转换运行主数据转换工作流设计家与ERP接口方案在设计装修业务系统架构规划中，作为前台的设计家门户和作为中台、后台的新ERP系统需要紧密结合，共同实现对设计装修业务的管理支撑。未来项目实施过程中，考虑设计家与ERP的接口，需要对两个系统的关系作出整体规划：1、首先，需要明确两个系统的定位：设计家作为前台系统，面向各种角色的会员，主要承担引流、交互和业务受理的功能；而ERP则承担数据支撑、规则定义、业务处理、管控支撑等功能；2、其次，在明确系统定位的基础上，针对设计装修的业务流程，作出详细的系统边界规划。初步梳理设计家与新ERP接口如下：1、会员管理：设计家是会员注册的来源之一；会员评级、积分等在ERP集中处理，分发到设计家平台进行查询和调用；2、商品主数据管理：设计家中进行3D设计建模时，可以调用ERP的商品主数据，以便设计完成后，自动出具BOM；3、订单交易：设计家平台的洽谈结果接口到ERP形成家装合同；设计清单转化为材料采购订单；消费者可以在设计家平台查询订单信息；ERP中的物流配送信息通过设计家门户供消费者查询等；4、营销服务：ERP中管理的促销规则、促销活动等通过设计家平台发布；根据设计家平台中的促销活动效果情况（例如点击量等），进行ERP中的促销结算等；5、结算管理：设计家线上付款信息同步给ERP。ERP系统与设计家系统的集成参考ERP系统与居然在线系统的接口集成方案，原则是不额外增加设计家的接口开发工作量，利用已有的设计家与旧ERP系统的标准WebService接口实现集成。具体集成设计如下图所示：HR系统与ERP系统接口方案ERP系统与HR系统之间的接口实现单点登录，主要完成单点登录时对员工信息的认证，以及获取组织架构实现权限控制，此接口开发工作由ERP系统完成，原则是利用HR系统已有接口减少接口集成工作量。ERP系统与HR系统的接口实现采用ESBWebService方式实现，具体实现如下图所示：OA流程审批与ERP系统接口方案ERP系统与OA审批流程系统之间的接口实现OA审批流程与ERP结算流程的集成，此接口开发工作由ERP系统与OA审批流程系统共同完成。原则是利用OA审批流程系统现有接口以减少接口集成工作量。ERP系统与OA审批流程系统的接口实现采用ESBWebService方式实现，具体实现如下图所示：

技术解决方案硬件部署方案OracleEBS硬件部署建议OracleEBS由应用服务（Web服务，Form服务，并发服务等组成）和数据库服务组件组成，根据居然之家业务特点，实现负载均衡、7*24小时部署方式、易维护、易扩展、高可用性、高安全、节约成本等。建议EBS应用服务组件（Web服务，Form服务，并发服务等组成）集中部署，也是最常见的应用服务部署方式之一，也是最容易扩展和维护的应用服务架构之一；EBS应用服务采用两台双机，加http负载均衡硬件设备；EBS数据库采用两台OracleRAC方式实现负载均衡部署方式；存储两台互备方式，且存储可与其他系统共享。JDE硬件部署建议JDE由管理客户端（俗称胖客户端）、开发客户端（俗称廋客户端）、Web应用服务、业务逻辑服务和数据库服务组件组成，根据居然之家业务特点，实现负载均衡、7*24小时部署方式、易维护、易扩展、高可用性、高安全、节约成本等。管理客户端（俗称胖客户端）一台；开发客户端（俗称廋客户端）一台；WEB服务采用两台双机，加http负载均衡硬件设备；业务逻辑服务器采用两台双机，通过自身组件实现软负载均衡；JDE数据库采用两台OracleRAC方式实现负载均衡部署方式；存储两台互备方式，且存储可与其他系统共享。SiebelCRM硬件部署建议Siebel由应用服务和数据库服务组件组成，根据居然之家业务特点，实现负载均衡、7*24小时部署方式、易维护、易扩展、高可用性、高安全、节约成本等。Siebel应用服务采用两台双机，加http负载均衡硬件设备；Siebel数据库采用两台OracleRAC方式实现负载均衡部署方式；存储两台互备方式，且存储可与其他系统共享。OracleRetail硬件部署建议Retail由应用服务和数据库服务组件组成，根据居然之家业务特点，实现负载均衡、7*24小时部署方式、易维护、易扩展、高可用性、高安全、节约成本等。Retail应用服务采用两台双机，加http负载均衡硬件设备；Retail数据库采用两台OracleRAC方式实现负载均衡部署方式；存储两台互备方式，且存储可与其他系统共享。Hyperion硬件部署建议Hyperion由应用服务和数据库服务组件组成，根据居然之家业务特点，实现负载均衡、7*24小时部署方式、易维护、易扩展、高可用性、高安全、节约成本等。Hyperion应用服务采用三台服务器，加http负载均衡硬件设备；Hyperion数据库采用两台服务器，每台服务器同时安装Essbase和Oracle数据库，其中Oracle数据库通过OracleRAC方式实现负载均衡部署方式，Essbase通过ProviderService实现双机互备的HA部署方式；存储两台互备方式，且存储可与其他系统共享。BI硬件部署建议BI由应用服务和数据库服务组件组成，根据居然之家业务特点，实现负载均衡、7*24小时部署方式、易维护、易扩展、高可用性、高安全、节约成本等。BI应用服务采用两台双机，加http负载均衡硬件设备；BI数据库采用两台OracleRAC方式实现负载均衡部署方式；存储两台互备方式，且存储可与其他系统共享。MDM硬件部署建议MDM由应用服务和数据库服务组件组成，根据居然之家业务特点，实现负载均衡、7*24小时部署方式、易维护、易扩展、高可用性、高安全、节约成本等。MDM应用服务采用两台双机，加http负载均衡硬件设备；MDM数据库采用两台OracleRAC方式实现负载均衡部署方式；存储两台互备方式，且存储可与其他系统共享。单点登录硬件部署建议单点登录由应用服务和数据库服务（数据库占用空间较小）组件组成，根据居然之家业务特点，实现负载均衡、7*24小时部署方式、易维护、易扩展、高可用性、高安全、节约成本等。单点登录应用服务采用两台双机，加http负载均衡硬件设备；单点登录数据库采用两台OracleRAC方式实现负载均衡部署方式；存储两台互备方式，且存储可与其他系统共享。SOA硬件部署建议SOA由应用服务和数据库服务（数据库占用空间较小）组件组成，根据居然之家业务特点，实现负载均衡、7*24小时部署方式、易维护、易扩展、高可用性、高安全、节约成本等。SOA应用服务采用两台双机，加http负载均衡硬件设备；SOA数据库采用两台OracleRAC方式实现负载均衡部署方式；存储两台互备方式，且存储可与其他系统共享。备份硬件建议每日备份：建议采用虚拟带库每日备份所有重要的信息；定期备份：用物理带库定期备份重点数据，并备份后存放至异地。容灾硬件建议根据居然之家本次项目的特点，建议如下：（同城）异地异步数据容灾：在异地建立一个数据备份站点，通过网络以异步方式进行数据备份。备份站点只备份数据，不承担业务。在对灾难的容忍程度同第3级。但他采用网络进行数据复制度方式，因此两个站点的数据同步程度要比3高，丢失数据也更少。（异城）异地同步应用容灾：在异地建立一个与生产系统完全相同的备用系统，他们之间采用同步的方式进行数据复制。当生产中心发生灾难时，备用系统接替其工作。该级别的容灾，在发生灾难时，可以基本保证数据零丢失和业务的连续性。

Sizing及硬件建议配置服务器Sizing评估及建议配置基于物理服务器，可以等量替换为同等配置的虚拟机。Sizing评估方法居然之家背景北京地区1938人在职，其中系统连接人数284人（北四环店市场（北四环+北五靓屋）共60人，北四环店+北京区总（财务在区总）50人，食品超市丽泽店70人，北四环一部104人）；全国人数约10000人，SF与ERP交互、OA与ERP交互要酌情考虑，两项并发按照10000*5%*2项=1000人/单，高峰期最终业务合计量：7507.15单/分钟，高峰期剔除可能的收银/乐屋业务收单合计：4965.1单/分钟；小结：按北京地区计算，在线人数为在职人数的14%左右，全国按10000人来计算，按此计算并发用户数量为1400人左右，加上冗余并发用户数量为2000人左右。主要应用产品服务器用户数量2000，按照峰值30%在线用户，2000*30%=600每2核CPU运行1个WebServer，每个WebServer支持100个Web并发用户每2核CPU运行1个OACORE，每个OACORE支持100个Web并发用户每核CPU可支持同时运行10个并发请求应用并发用户数约600，需运行600/100≈6个WebServer和OACORE应用并发用户数约600，按峰值30%用户在运行并发请求，600*30%=180CPU核总数为：2*6+2*6+180/10≈48Core内存总数：CPU核数的2~4倍为佳多实例为2个实例，每台实例CPU核总数为48/2=24多实例为2个实例，考虑30%冗余，每台内存为(24*2)*(1+30%)≈64GB主要数据库服务器每核CPU可支持同时处理10个数据库并发高峰时数据库并发数约为并发用户数+50%并发请求数与接口并发数，即600+300=900CPU核数为：900/10=90Core内存：CPU核数的2~4倍为佳多实例为2个实例，每台实例CPU核总数为90/2=45Core≈48Core多实例为2个实例，每台实例内存为48*2=96Gb增加30%冗余后为128Gb上线试点阶段硬件建议配置试点阶段硬件需求

名称主要技术指标参考机型生产容灾单位用途及推荐理由1EBS生产环境

1.1数据库服务器CPU：至少2颗，每颗12核心，主频高于2.0GHz

内存：最低64G

本地磁盘：至少2*500G

HBA卡：2块

SAN存储：本地文件系统300G

共享SAN存储：600G以上，如果数据库归档日志保存在ASM中，建议分配1TB。IBMX3850X52

台部署R12.1.3数据库节点，构建RAC架构，需要使用共享SAN存储。使用SAN存储配置2块HBA卡提供双链路保障，至少1块HBA卡进行单链连接，但生产建议采用双链路模式。

1.2应用服务器CPU：至少2颗，每颗8核心，主频高于2.0GHz

内存：最低48G

本地磁盘：至少2*500G

HBA卡：2块

挂载SAN存储500GIBMX3850X52

台部署R12.1.3应用节点。使用SAN存储配置2块HBA卡提供双链路保障，至少1块HBA卡进行单链连接，但生产建议采用双链路模式。2JDE生产环境

2.1管理客户端CPU：至少4核心，主频高于2.0GHz

内存：最低16G

本地磁盘：500G本地磁盘空间N/A1

台可以硬件配置符合的工作站或者虚拟化服务器

2.2开发客户端CPU：至少4核心，主频高于2.0GHz

内存：最低16G

本地磁盘：500G本地磁盘空间N/A1

台可以硬件配置符合的工作站或者虚拟化服务器

2.3WEB服务CPU：至少8核心，主频高于2.0GHz

内存：最低32G

本地磁盘：至少2*500G，建议4*500G并配置为Raid1+0

HBA卡：可选

SAN存储：可选，如使用存储，建议500G以上空间IBMX3690X52

台如果不使用SAN存储，建议服务器至少配置4块本地硬盘并使用Raid1+0模式

2.4业务逻辑服务器CPU：至少8核心，主频高于2.0GHz

内存：最低32G

本地磁盘：至少2*500G，建议4*500G并配置为Raid1+0

HBA卡：可选

SAN存储：可选，如使用存储，建议500G以上空间IBMX3690X52

台如果不使用SAN存储，建议服务器至少配置4块本地硬盘并使用Raid1+0模式

2.5JDE数据库CPU：至少16核心，主频高于2.0GHz

内存：最低32G

本地磁盘：至少2*500G

HBA卡：2块

SAN存储：建议500G以上空间共享存储IBMX3850X52

台构建RAC架构，需要使用共享SAN存储。使用SAN存储配置2块HBA卡提供双链路保障，至少1块HBA卡进行单链连接，但生产建议采用双链路模式。3Siebel生产环境

3.1应用服务器CPU：至少16核心，主频高于2.0GHz

内存：最低32G

本地磁盘：至少2*500G，建议4*500G并配置为Raid1+0

HBA卡：可选

SAN存储：可选，如使用存储，建议500G以上空间IBMX3690X52

台如果不使用SAN存储，建议服务器至少配置4块本地硬盘并使用Raid1+0模式

3.2数据库服务器CPU：至少16核心，主频高于2.0GHz

内存：最低64G

本地磁盘：至少2*500G

HBA卡：2块

SAN存储：建议500G以上空间共享存储IBMX3850X52

台构建RAC架构，需要使用共享SAN存储。使用SAN存储配置2块HBA卡提供双链路保障，至少1块HBA卡进行单链连接，但生产建议采用双链路模式。4Retail生产环境

4.1应用服务器CPU：至少16核心，主频高于2.0GHz

内存：最低32G

本地磁盘：至少2*500G，建议4*500G并配置为Raid1+0

HBA卡：可选

SAN存储：可选，如使用存储，建议500G以上空间IBMX3690X52

台如果不使用SAN存储，建议服务器至少配置4块本地硬盘并使用Raid1+0模式

4.2数据库服务器CPU：至少16核心，主频高于2.0GHz

内存：最低32G

本地磁盘：至少2*500G

HBA卡：2块

SAN存储：建议500G以上空间共享存储IBMX3850X52

台构建RAC架构，需要使用共享SAN存储。使用SAN存储配置2块HBA卡提供双链路保障，至少1块HBA卡进行单链连接，但生产建议采用双链路模式。5Hyperion生产环境

5.1应用服务器CPU：至少16核心，主频高于2.0GHz

内存：最低32G

本地磁盘：至少2*500G，建议4*500G并配置为Raid1+0

HBA卡：可选

SAN存储：可选，如使用存储，建议500G以上空间IBMX3690X53

台如果不使用SAN存储，建议服务器至少配置4块本地硬盘并使用Raid1+0模式

5.2数据库服务器CPU：至少16核心，主频高于2.0GHz

内存：最低32G

本地磁盘：至少2*500G，建议4*500G并配置为Raid1+0

HBA卡：2块

SAN存储：建议500G以上空间共享存储IBMX3690X52

台构建RAC架构，需要使用共享SAN存储。使用SAN存储配置2块HBA卡提供双链路保障，至少1块HBA卡进行单链连接，但生产建议采用双链路模式。6BI生产环境

6.1应用服务器CPU：至少16核心，主频高于2.0GHz

内存：最低32G

本地磁盘：至少2*500G，建议4*500G并配置为Raid1+0

HBA卡：可选

SAN存储：可选，如使用存储，建议500G以上空间IBMX3690X52

台如果不使用SAN存储，建议服务器至少配置4块本地硬盘并使用Raid1+0模式

6.2数据库服务器CPU：至少16核心，主频高于2.0GHz

内存：最低32G

本地磁盘：至少2*500G，建议4*500G并配置为Raid1+0

HBA卡：2块

SAN存储：建议500G以上空间共享存储IBMX3690X52

台构建RAC架构，需要使用共享SAN存储。使用SAN存储配置2块HBA卡提供双链路保障，至少1块HBA卡进行单链连接，但生产建议采用双链路模式。7MDM生产环境

7.1应用服务器CPU：至少16核心，主频高于2.0GHz

内存：最低32G

本地磁盘：至少2*500G，建议4*500G并配置为Raid1+0

HBA卡：可选

SAN存储：可选，如使用存储，建议500G以上空间IBMX3690X52

台如果不使用SAN存储，建议服务器至少配置4块本地硬盘并使用Raid1+0模式

7.2数据库服务器CPU：至少16核心，主频高于2.0GHz

内存：最低32G

本地磁盘：至少2*500G，建议4*500G并配置为Raid1+0

HBA卡：2块

SAN存储：建议500G以上空间共享存储IBMX3690X52

台构建RAC架构，需要使用共享SAN存储。使用SAN存储配置2块HBA卡提供双链路保障，至少1块HBA卡进行单链连接，但生产建议采用双链路模式。8单点登录生产环境

8.1应用服务器CPU：至少16核心，主频高于2.0GHz

内存：最低32G

本地磁盘：至少2*500G，建议4*500G并配置为Raid1+0

HBA卡：可选

SAN存储：可选，如使用存储，建议500G以上空间IBMX3690X52

台如果不使用SAN存储，建议服务器至少配置4块本地硬盘并使用Raid1+0模式

8.2数据库服务器CPU：至少16核心，主频高于2.0GHz

内存：最低32G

本地磁盘：至少2*500G，建议4*500G并配置为Raid1+0

HBA卡：2块

SAN存储：建议500G以上空间共享存储IBMX3690X52

台构建RAC架构，需要使用共享SAN存储。使用SAN存储配置2块HBA卡提供双链路保障，至少1块HBA卡进行单链连接，但生产建议采用双链路模式。9SOA生产环境

9.1应用服务器CPU：至少16核心，主频高于2.0GHz

内存：最低32G

本地磁盘：至少2*500G，建议4*500G并配置为Raid1+0

HBA卡：可选

SAN存储：可选，如使用存储，建议500G以上空间IBMX3690X52

台如果不使用SAN存储，建议服务器至少配置4块本地硬盘并使用Raid1+0模式

9.2数据库服务器CPU：至少16核心，主频高于2.0GHz

内存：最低32G

本地磁盘：至少2*500G，建议4*500G并配置为Raid1+0

HBA卡：2块

SAN存储：建议500G以上空间共享存储IBMX3690X52

台构建RAC架构，需要使用共享SAN存储。使用SAN存储配置2块HBA卡提供双链路保障，至少1块HBA卡进行单链连接，但生产建议采用双链路模式。10其他生产环境服务器和设备

10.1备份服务器CPU：至少2核心，主频高于2.0GHz

内存：最低16G

本地磁盘：500G本地磁盘空间IBMX3690X51

台

10.2存储阵列建议容量30Tb以上N/A1

台

10.3光纤交换机24口，16Gb/sN/A2

台建议使用2台光纤交换机实现高可用，如现有设备可以满足要求，则不必另行采购。

10.4虚拟带库建议容量50Tb以上N/A1

台

10.5物理带库建议容量10Tb以上N/A1

台

10.6负载均衡

F5-BIG-LTM2000S1

台

11开发测试服务器

11.1EBS测试开发CPU：至少8核心，主频高于2.0GHz

内存：最低24G

本地磁盘：至少4*500G

HBA卡：可选

SAN存储：可选，如使用存储，建议500G以上空间IBMX3690X52

台如果不使用SAN存储，建议服务器至少配置4块本地硬盘并使用Raid1+0模式

11.2JDE测试开发CPU：至少8核心，主频高于2.0GHz

内存：最低24G

本地磁盘：至少4*500G

HBA卡：可选

SAN存储：可选，如使用存储，建议500G以上空间IBMX3690X52

台如果不使用SAN存储，建议服务器至少配置4块本地硬盘并使用Raid1+0模式

11.3Siebel测试开发CPU：至少8核心，主频高于2.0GHz

内存：最低24G

本地磁盘：至少4*500G

HBA卡：可选

SAN存储：可选，如使用存储，建议500G以上空间IBMX3690X52

台如果不使用SAN存储，建议服务器至少配置4块本地硬盘并使用Raid1+0模式

11.4Retail测试开发CPU：至少8核心，主频高于2.0GHz

内存：最低24G

本地磁盘：至少4*500G

HBA卡：可选

SAN存储：可选，如使用存储，建议500G以上空间IBMX3690X52

台如果不使用SAN存储，建议服务器至少配置4块本地硬盘并使用Raid1+0模式

11.5Hyperion测试开发CPU：至少8核心，主频高于2.0GHz

内存：最低24G

本地磁盘：至少4*500G

HBA卡：可选

SAN存储：可选，如使用存储，建议500G以上空间IBMX3690X53

台如果不使用SAN存储，建议服务器至少配置4块本地硬盘并使用Raid1+0模式

11.6BI测试开发CPU：至少8核心，主频高于2.0GHz

内存：最低24G

本地磁盘：至少4*500G

HBA卡：可选

SAN存储：可选，如使用存储，建议500G以上空间IBMX3690X52

台如果不使用SAN存储，建议服务器至少配置4块本地硬盘并使用Raid1+0模式

11.7MDM测试开发CPU：至少8核心，主频高于2.0GHz

内存：最低24G

本地磁盘：至少4*500G

HBA卡：可选

SAN存储：可选，如使用存储，建议500G以上空间IBMX3690X52

台如果不使用SAN存储，建议服务器至少配置4块本地硬盘并使用Raid1+0模式

11.8单点登录测试开发CPU：至少8核心，主频高于2.0GHz

内存：最低24G

本地磁盘：至少4*500G

HBA卡：可选

SAN存储：可选，如使用存储，建议500G以上空间IBMX3690X51

台如果不使用SAN存储，建议服务器至少配置4块本地硬盘并使用Raid1+0模式

11.9SOA测试开发CPU：至少8核心，主频高于2.0GHz

内存：最低24G

本地磁盘：至少4*500G

HBA卡：可选

SAN存储：可选，如使用存储，建议500G以上空间IBMX3690X52

台如果不使用SAN存储，建议服务器至少配置4块本地硬盘并使用Raid1+0模式全面推广阶段硬件建议配置推广阶段硬件需求

名称主要技术指标参考机型生产容灾单位用途及推荐理由1EBS生产环境

1.1数据库服务器CPU：至少4颗，每颗12核心，主频高于2.0GHz

内存：最低128G

本地磁盘：至少2*500G

HBA卡：2块

SAN存储：本地文件系统300G

共享SAN存储：600G以上，如果数据库归档日志保存在ASM中，建议分配1TB。IBMX3850X522台部署R12.1.3数据库节点，构建RAC架构，需要使用共享SAN存储。使用SAN存储配置2块HBA卡提供双链路保障，至少1块HBA卡进行单链连接，但生产建议采用双链路模式。

1.2应用服务器CPU：至少2颗，每颗12核心，主频高于2.0GHz

内存：最低64G

本地磁盘：至少2*500G

HBA卡：2块

挂载SAN存储500GIBMX3850X522台部署R12.1.3应用节点。使用SAN存储配置2块HBA卡提供双链路保障，至少1块HBA卡进行单链连接，但生产建议采用双链路模式。2JDE生产环境

2.1管理客户端CPU：至少4核心，主频高于2.0GHz

内存：最低16G

本地磁盘：500G本地磁盘空间N/A11台可以硬件配置符合的工作站或者虚拟化服务器

2.2开发客户端CPU：至少4核心，主频高于2.0GHz

内存：最低16G

本地磁盘：500G本地磁盘空间N/A11台可以硬件配置符合的工作站或者虚拟化服务器

2.3WEB服务CPU：至少16核心，主频高于2.0GHz

内存：最低32G

本地磁盘：至少2*500G，建议4*500G并配置为Raid1+0

HBA卡：可选

SAN存储：可选，如使用存储，建议500G以上空间IBMX3690X522台如果不使用SAN存储，建议服务器至少配置4块本地硬盘并使用Raid1+0模式

2.4业务逻辑服务器CPU：至少16核心，主频高于2.0GHz

内存：最低32G

本地磁盘：至少2*500G，建议4*500G并配置为Raid1+0

HBA卡：可选

SAN存储：可选，如使用存储，建议500G以上空间IBMX3690X522台如果不使用SAN存储，建议服务器至少配置4块本地硬盘并使用Raid1+0模式

2.5JDE数据库CPU：至少16核心，主频高于2.0GHz

内存：最低64G

本地磁盘：至少2*500G

HBA卡：2块

SAN存储：建议500G以上空间共享存储IBMX3850X522台构建RAC架构，需要使用共享SAN存储。使用SAN存储配置2块HBA卡提供双链路保障，至少1块HBA卡进行单链连接，但生产建议采用双链路模式。3Siebel生产环境

3.1应用服务器CPU：至少16核心，主频高于2.0GHz

内存：最低32G

本地磁盘：至少2*500G，建议4*500G并配置为Raid1+0

HBA卡：可选

SAN存储：可选，如使用存储，建议500G以上空间IBMX3690X522台如果不使用SAN存储，建议服务器至少配置4块本地硬盘并使用Raid1+0模式

3.2数据库服务器CPU：至少16核心，主频高于2.0GHz

内存：最低64G

本地磁盘：至少2*500G

HBA卡：2块

SAN存储：建议500G以上空间共享存储IBMX3850X522台构建RAC架构，需要使用共享SAN存储。使用SAN存储配置2块HBA卡提供双链路保障，至少1块HBA卡进行单链连接，但生产建议采用双链路模式。4Retail生产环境

4.1应用服务器CPU：至少16核心，主频高于2.0GHz

内存：最低32G

本地磁盘：至少2*500G，建议4*500G并配置为Raid1+0

HBA卡：可选

SAN存储：可选，如使用存储，建议500G以上空间IBMX3690X522台如果不使用SAN存储，建议服务器至少配置4块本地硬盘并使用Raid1+0模式

4.2数据库服务器CPU：至少16核心，主频高于2.0GHz

内存：最低64G

本地磁盘：至少2*500G

HBA卡：2块

SAN存储：建议500G以上空间共享存储IBMX3850X522台构建RAC架构，需要使用共享SAN存储。使用SAN存储配置2块HBA卡提供双链路保障，至少1块HBA卡进行单链连接，但生产建议采用双链路模式。5Hyperion生产环境

5.1应用服务器CPU：至少16核心，主频高于2.0GHz

内存：最低48G

本地磁盘：至少2*500G，建议4*500G并配置为Raid1+0

HBA卡：可选

SAN存储：可选，如使用存储，建议500G以上空间IBMX3690X533台如果不使用SAN存储，建议服务器至少配置4块本地硬盘并使用Raid1+0模式

5.2数据库服务器CPU：至少16核心，主频高于2.0GHz

内存：最低64G

本地磁盘：至少2*500G，建议4*500G并配置为Raid1+0

HBA卡：2块

SAN存储：建议500G以上空间共享存储IBMX3690X522台构建RAC架构，需要使用共享SAN存储。使用SAN存储配置2块HBA卡提供双链路保障，至少1块HBA卡进行单链连接，但生产建议采用双链路模式。6BI生产环境

6.1应用服务器CPU：至少16核心，主频高于2.0GHz

内存：最低32G

本地磁盘：至少2*500G，建议4*500G并配置为Raid1+0

HBA卡：可选

SAN存储：可选，如使用存储，建议500G以上空间IBMX3690X522台如果不使用SAN存储，建议服务器至少配置4块本地硬盘并使用Raid1+0模式

6.2数据库服务器CPU：至少16核心，主频高于2.0GHz

内存：最低32G

本地磁盘：至少2*500G，建议4*500G并配置为Raid1+0

HBA卡：2块

SAN存储：建议500G以上空间共享存储IBMX3690X522台构建RAC架构，需要使用共享SAN存储。使用SAN存储配置2块HBA卡提供双链路保障，至少1块HBA卡进行单链连接，但生产建议采用双链路模式。7MDM生产环境

7.1应用服务器CPU：至少16核心，主频高于2.0GHz

内存：最低32G

本地磁盘：至少2*500G，建议4*500G并配置为Raid1+0

HBA卡：可选

SAN存储：可选，如使用存储，建议500G以上空间IBMX3690X522台如果不使用SAN存储，建议服务器至少配置4块本地硬盘并使用Raid1+0模式

7.2数据库服务器CPU：至少16核心，主频高于2.0GHz

内存：最低32G

本地磁盘：至少2*500G，建议4*500G并配置为Raid1+0

HBA卡：2块

SAN存储：建议500G以上空间共享存储IBMX3690X522台构建RAC架构，需要使用共享SAN存储。使用SAN存储配置2块HBA卡提供双链路保障，至少1块HBA卡进行单链连接，但生产建议采用双链路模式。8单点登录生产环境

8.1应用服务器CPU：至少16核心，主频高于2.0GHz

内存：最低32G

本地磁盘：至少2*500G，建议4*500G并配置为Raid1+0

HBA卡：可选

SAN存储：可选，如使用存储，建议500G以上空间IBMX3690X522台如果不使用SAN存储，建议服务器至少配置4块本地硬盘并使用Raid1+0模式

8.2数据库服务器CPU：至少16核心，主频高于2.0GHz

内存：最低32G

本地磁盘：至少2*500G，建议4*500G并配置为Raid1+0

HBA卡：2块

SAN存储：建议500G以上空间共享存储IBMX3690X522台构建RAC架构，需要使用共享SAN存储。使用SAN存储配置2块HBA卡提供双链路保障，至少1块HBA卡进行单链连接，但生产建议采用双链路模式。9SOA生产环境

9.1应用服务器CPU：至少16核心，主频高于2.0GHz

内存：最低32G

本地磁盘：至少2*500G，建议4*500G并配置为Raid1+0

HBA卡：可选

SAN存储：可选，如使用存储，建议500G以上空间IBMX3690X522台如果不使用SAN存储，建议服务器至少配置4块本地硬盘并使用Raid1+0模式

9.2数据库服务器CPU：至少16核心，主频高于2.0GHz

内存：最低32G

本地磁盘：至少2*500G，建议4*500G并配置为Raid1+0

HBA卡：2块

SAN存储：建议500G以上空间共享存储IBMX3690X522台构建RAC架构，需要使用共享SAN存储。使用SAN存储配置2块HBA卡提供双链路保障，至少1块HBA卡进行单链连接，但生产建议采用双链路模式。10其他生产环境服务器和设备

10.1备份服务器CPU：至少2核心，主频高于2.0GHz

内存：最低16G

本地磁盘：500G本地磁盘空间IBMX3690X511台

10.2存储阵列建议容量30Tb以上N/A11台

10.3光纤交换机24口，16Gb/sN/A22台建议使用2台光纤交换机实现高可用，如现有设备可以满足要求，则不必另行采购。

10.4虚拟带库建议容量50Tb以上N/A11台

10.5物理带库建议容量10Tb以上N/A11台

10.6负载均衡

F5-BIG-LTM2000S11台

11开发测试服务器

11.1EBS测试开发CPU：至少8核心，主频高于2.0GHz

内存：最低32G

本地磁盘：至少4*500G

HBA卡：可选

SAN存储：可选，如使用存储，建议500G以上空间IBMX3690X52

台如果不使用SAN存储，建议服务器至少配置4块本地硬盘并使用Raid1+0模式

11.2JDE测试开发CPU：至少8核心，主频高于2.0GHz

内存：最低32G

本地磁盘：至少4*500G

HBA卡：可选

SAN存储：可选，如使用存储，建议500G以上空间IBMX3690X52

台如果不使用SAN存储，建议服务器至少配置4块本地硬盘并使用Raid1+0模式

11.3Siebel测试开发CPU：至少8核心，主频高于2.0GHz

内存：最低32G

本地磁盘：至少4*500G

HBA卡：可选

SAN存储：可选，如使用存储，建议500G以上空间IBMX3690X52

台如果不使用SAN存储，建议服务器至少配置4块本地硬盘并使用Raid1+0模式

11.4Retail测试开发CPU：至少8核心，主频高于2.0GHz

内存：最低32G

本地磁盘：至少4*500G

HBA卡：可选

SAN存储：可选，如使用存储，建议500G以上空间IBMX3690X52

台如果不使用SAN存储，建议服务器至少配置4块本地硬盘并使用Raid1+0模式

11.5Hyperion测试开发CPU：至少8核心，主频高于2.0GHz

内存：最低32G

本地磁盘：至少4*500G

HBA卡：可选

SAN存储：可选，如使用存储，建议500G以上空间IBMX3690X53

台如果不使用SAN存储，建议服务器至少配置4块本地硬盘并使用Raid1+0模式

11.6BI测试开发CPU：至少8核心，主频高于2.0GHz

内存：最低32G

本地磁盘：至少4*500G

HBA卡：可选

SAN存储：可选，如使用存储，建议500G以上空间IBMX3690X52

台如果不使用SAN存储，建议服务器至少配置4块本地硬盘并使用Raid1+0模式

11.7MDM测试开发CPU：至少8核心，主频高于2.0GHz

内存：最低32G

本地磁盘：至少4*500G

HBA卡：可选

SAN存储：可选，如使用存储，建议500G以上空间IBMX3690X52

台如果不使用SAN存储，建议服务器至少配置4块本地硬盘并使用Raid1+0模式

11.8单点登录测试开发CPU：至少8核心，主频高于2.0GHz

内存：最低32G

本地磁盘：至少4*500G

HBA卡：可选

SAN存储：可选，如使用存储，建议500G以上空间IBMX3690X51

台如果不使用SAN存储，建议服务器至少配置4块本地硬盘并使用Raid1+0模式

11.9SOA测试开发CPU：至少8核心，主频高于2.0GHz

内存：最低32G

本地磁盘：至少4*500G

HBA卡：可选

SAN存储：可选，如使用存储，建议500G以上空间IBMX3690X52

台如果不使用SAN存储，建议服务器至少配置4块本地硬盘并使用Raid1+0模式

系统安全解决方案针对居然之家对于安全的要求，结合Oracle应用产品在安全方面的强大功能，我们从用户访问、系统架构、数据传输、数据存储、数据访问等方面提供安全解决方案：安全策略：全方位的安全性支持，提供端对端的安全解决方案Oracle从来都是把产品的安全放在首要的位置，Oracle的数据库获得过多达15项的安全认证证书，也是唯一获得过NCSCB1级认证的数据库，是美国军方和中央情报局主要的数据库平台；在Oracle应用产品中，我们不但利用到Oracle数据库的许多安全特性来保证数据的安全，实现字段级的数据权限控制，并且通过多种Oracle先进的技术平台优势实现应用层次、应用服务器层次、数据库服务器层次各个层次全方位的应用系统保障。包括：数据存储加密Oracle数据库可以以密文的形式来存储放在表中的记录，这样即使有用户得到访问数据库表的权限，也无法从加密的表中得到任何有用的信息。例如所有存储在数据库中的用户Password都是以加密方式进行存储的。如下图所示，居然之家的敏感信息可以采用列级透明加密技术对关键列进行双层密钥保护的方式进行加密，该方式对应用用户是透明的，在保存和获取的过程中进行加密解密，即使是DBA也需要双层密钥才可以在后台看到数据。数据传输加密、保证数据完整性Oracle应用产品的Web服务器是基于业已成为互联网上普遍认可的标准Web服务器：Apache的基础上进行完善的，Apache为全球超过60%以上的网站提供Web服务，是经过长期全面测试的Web服务器，提供稳健、安全、可扩展的技术支持。Oracle应用产品结合扩展的Apache功能在数据传输上提供完善的加密保护：在由Java（如Oracle的Forms表单应用）、JSP应用和执行客户端网络请求时提供标准的SSL和HTTPS支持。通过使用Oracle在SecureSocketsLayer（SSL）上提供的加密机制，Oracle应用产品和客户端浏览器之间可以建立安全密文传输通道，保证数据传输过程的安全性和完整性（不被窃取或篡改）。并可以通过在互联网上使用数字证书技术，来进行用户鉴定。基于LDAP的集中用户认证管理Oracle应用产品全面支持Oracle的目录服务器，可以通过LDAPServer来集成进行用户的认证和管理，支持所有主流的口令认证方式和设置规则，并且Oracle的LDAPServer可以和所有主流的LDAPServer进行集成实现SSO，如iPlanet，ActiveDirectory等，来实现居然之家全局用户管理的策略和全方位内的全局认证。数字证书数字证书对于保护企业基础架构部署很重要。OracleApplicationServerCertificateAuthority用于生成并发布X.509v3PKI证书，以支持各种应用情形，如保护网络连接、数字签名和强用户身份验证方法。OracleApplicationServerCertificateAuthority的部署简单快速，还提供一个针对证书供应的用户自助Web界面。审计用户操作，用户操作不可否认Oracle应用产品也提供多层次的审计机制来记录各种用户访问行为，挖掘和跟踪非法访问，并确保用户操作的不可否认性：用户审计Oracle应用产品可以全程审计用户的行为，系统可以设置来审计每一个用户的访问记录，包括用户访问的终端、时间、职责、报表、执行的并发处理等。灵活的审计方式可以让管理员动态地选择和改动要审计的级别。甚至对于恶意的尝试性登录，Oracle应用产品也提供详细的Log记录非法尝试登录的主机、用户名、时间等信息。数据审计对数据的各种访问操作（如插入，删除、修改等）都可以进行审计，Oracle应用产品丰富的审计机制可以让系统管理员对数据表进行任何级别的审计。页面访问审计（应用层面访问审计）系统可以对应用用户访问的页面进行访问审计，对于每个用户的访问记录如下信息：页面信息TimestampJSPname(forexample,jtflogin.jsp)（用户登录的页面）JSPexecutiontime,inmillisecondsClientIPaddress（客户端IP地址）服务器端信息Hostname（服务器主机名）ApacheportJservportRequestmethod(POST,GET,PUT,HEAD,etc.)Returnstatus(OK,Error,orException)SessionContextApplicationID(用户登录的模块)ResponsibilityID（系统中用户对应的职责）UserID（系统中用户的ID）LanguageIDSessionID客户浏览器信息Clientlanguage（客户端语言）HTTPheaderUser-agent（用户代理）Protocol（访问协议）RefererAuthorizationtype（认证类型）客户端语言信息Characterencoding（字符）Language（语言）Characterset（字符集）以上功能可以通过ORACLEAPPLICATIONMANAGER轻松进行配置实现，不需要进行二次开发。安全报告同样在系统中，Oracle也提供一系列的报表可以从上述设置的审计数据中得到格式化的信息，方便管理人员进行查看。这些报告包括用户审计，页面访问审计，数据审计等，系统都能够提供详细的报告，这些报告都可以由业务人员（应用用户）提交，不需要DBA提供支持。以上这项数据审计功能可以基本满足居然之家对于安全性的需要。建议居然之家尽量使用这些标准报告，如有特殊需求的报告也可通过对报表的二次开发来实现。应用产品全方位用户功能权限控制Oracle应用产品提供功能权限控制功能，支持居然之家灵活地定义各种岗位角色。另外，利用Oracle灵活的菜单重组功能，居然之家可以将Oracle应用产品的标准软件流程与居然之家复杂的业务进行自由匹配，来确保用户只在许可范围下进行相关功能和数据的操作。Oracle的权限设置是基于职责和角色的，可以将操作权和审核权分配给不同的职责或角色，并且对于用户的权限设置也是非常的简单直观，在员工岗位调动时，只要分配和回收相关的职责或角色就完成了用户权限的变动，而且Oracle的权限分配可以进行层级分配和委托管理。图:Oracle应用产品安全体系结构如上图所示，Oracle应用产品中通过灵活分配组合菜单、角色、职责、以及用户来严格控制每个用户在系统中可以进行的操作，包括：菜单权限：在Oracle应用产品中可以跨模块选择不同的功能和菜单，进行重组，形成自定义的菜单。同时也可以方便的将应用Oracle工具开发的客户化的新功能加入进自定义的菜单中。组织权限：在Oracle应用产品中可以划分多个业务实体，然后实现不同业务实体间的业务数据和操作屏蔽。岗位角色：居然之家可以根据分工责任设置不同的岗位角色，Oracle应用产品支持将不同菜单组合和组织分配给不同的岗位责任。用户：系统的使用者，每一个用户均有自己的用户名称及密码，系统管理员只能覆盖，不能修改。系统支持将已定义的不同的岗位责任分配给不同用户。一个岗位角色对应一个菜单，通过这种对应关系确定了此岗位所能行使的功能。一个岗位角色对应一个组织，这限制了此岗位所能访问和操作的数据权限。另外，同一种岗位责任可以由多个用户（员工）担任，同一用户又可以兼任多个岗位。应用集成解决方案单点登录解决方案针对家居行业专业软件多以及系统异构的特点，为了简化用户和身份管理，在本次项目中需要建立统一的身份管理和认证平台，实现安全的统一管理，提高访问的便利性。建议在本次项目实现单点登录的系统范围为本次项目新实施的所有系统及原有的OA系统、居然在线平台和设计家平台，如下图所示：根据技术规范要求，实现先进性，安全性，可扩展性，兼容性等的要求，推荐使用Oracle统一身份管理和访问解决方案：OracleAccessManagement(OAM)：单点登录的实现模块OracleIdentityManagement(OIM)：身份供应的实现模块OracleInternetDirectory(OID)：LDAP信息存储的数据库其架构与技术的优势在于：访问控制和数据隐私性极高，是真正的密码加密与身份访问管理方式；基于SOA的架构设计，从应用中去扩展身份服务；与Oracle其他产品有成熟的解决方案，如：有现成与OracleEBS、JDE、Siebel和Retail集成的解决方案；开放架构和应用，兼容支持相关标准，与非Oracle产品松散耦合并具有综合性，易与OA系统、设计家平台、居然在线平台集成实现单点登录。

Oracle统一身份管理和访问解决方案的技术架构如下图所示：单点登录的具体实现过程如下：用户发出请求，例如需要访问业务系统，WebGate截获到请求之后，会要求用户输入验证信息（如果使用的是基于IntegratedWindowsAuthentication，则不需要输入验证信息），WebGate将信息提交给AccessServer，AccessServer将从统一的目录服务器（LDAPServer，即OID）中获得与之相匹配的身份信息。如果用户提供的验证信息不合法，AccessServer将发出消息给WebGate拒绝用户的请求，如果验证通过，AccessServer就提供该用户有权访问的企业资源，例如EBS或者OBIEE系统，发出消息给WebGate同意用户的请求，并且形成相应的Cookie信息以避免重复校验。举例与OracleEBS集成方案，用OAMAgent（WebGate代理）与OracleE-BusinessSuiteAccessGate集成实现单点登录，如图所示：如果与OA系统、居然在线平台及设计家平台集成时要实现基于Windows域验证的单点登录，则可以配置IWA，IWA的工作原理如下：用户登录到Windows机器，通过Kerberos得到了验证；当访问IIS，则IIS使用Kerberos的token（Kerberosticket）进行解码，并设置REMOTE_USER的HTTP头变量；WebGate使用外部验证方式获得REMOTE_USERHTTP头变量的值，并映射为DN，以便产生ObSSOCookie及授权，产生的ObSSOcookie返回给浏览器，用户便得到了验证。具体配置过程如下：安装OAMwithIdentityServer，保证服务器的时间是同步的。注意：PolicyManager和WebPass（主要用来进行IdentityServer的管理，通过AdmistrationConsole连接到WebPass再访问IdentityServer）必须安装在同一台机器上，它们需要放在同一目录下；AccessManager最好安装在跟IdentityServer不同的机器上；为了支持SSO和基于Form的认证，WebGate和PolicyManager安装在同一目录下；如果要保证系统的安全，那么必须在WebServer和AccessManager间