保险报送系统解决方案.docxVIP

‘XXX报送系统 后台解决方案Vl?2 注意： 由于目询甲方未提供详细的需求文档，只对报送系统的大致流程做了简单的口述，下而只是 粗略的设计思路，该文档阅览对象为乙方内部后台开发人员。 1、 数据源 由甲方提供，称作ODS,数据库类型为DB2,版本未知。 由于不知ODS细节，暂认为ODS是全屋全部业务数据的备库，与业务数据实时并且一致。 2、 可用数据 可用数据为ODS中的外汇部分，即ODS的外汇表。 历史数据不再统计和报送。 每次报送的可用数据为一个口然刀内发生的未报送的外汇数据（一个口然刀内发生H外汇FI 期在一个自然月，注意区分）。 每次报送的可用数据数据最暂无估算值。 为阐述方案这里假设报送主体X10 （表）由A/B/C计算汇总获得。 3、 数据源到基础层 报送系统数据库与ODS分离设计。 报送系统数据库采用DB2,版木未指定。 报送系统数据库笫一层为基础层，数据來自ODS的外汇数据。 基础层保胡所存已获取数据，即保留所冇获取轨迹，这有利于可能出现的数据核对（与数据 源）与纠错。 可用数据的获取方式，数据文件/数据直抽？： ?对于数据文件加载，需要ODS在特定的时间内将可用数据文件放入指定的磁盘目录，涉 及到的细节有：导出操作、导出范畴，全量/增量导出、导出耗时、导出成功标示等， Z后基础层获取并加载数据文件，技术上对采用脚本方式实现磁盘H录的监控，文件的 获取和加载到库； ?对于数据直抽，客户已经否定该方案，这里不做讨论。 可用数据的数据量 未知。 可用数据的获取频率 建议每月月初的1-2天抽取上月发住的可用数据，不建议每天抽取，理由如下：报送主体在 月底计算和牛:成，中间ODS可能存在手工删除（存在可能性），将增加系统内报送主体补录的 操作次数，当然如果数据量过人需考虑增加获取频率。 卬方已确认数据文件为业务数据增量和维表全量，获取频率为每天。 业务数据增量的具体方式未知，建议采用“〉二最末更新LI期作为增最数据文件”的方式，这 样可以最大程序简化增量操作，除了丿力史数据的删除未考虑（删除需要唯-性标示），丿力史 数据的修改和新增只需在基础层根据最末更新H期先删后插即可。 基础表ETL字段 loadtime：加载时间; 前台功能【明细补录】 基础层中的表叫做基础表，在前台叫做明细表。 卬方要求前台提供对基础表的增删改查。 设置菜单【明细补录】，用户在该页面进行基础表的［查询］、［新增］、［修改］、［删除］,这 个过程其实不能称作补录，举个例子，报送主体X10由A/B/C计算汇总获得，用户对A表中的 —?条数据进行的修改，最终该条数据与原始的B和C汇总得岀报送数据BS001,用补录来定义 这条BS001不够准确。 对基础表的补录依然会带来补录不全的问题，如对于关联汇总得来的BSOO1,只补录了A没补 录B可能得不到报送数据BSOO1,问题容易被忽略和隐藏，原因的查找对于川户也会显得繁琐。 仍需讨论： 明细补录是否需要建立与基础表对应的补录表？ 明细补录是否还需耍审核制度？ 其他建议： / 对于加载到基础层的表，建议加入特定前缀重命名（如w［+源表表名），这样便于与源 表区分。 4、主体层 报送主体为主体层中的报送表（也叫主体表，为实体表，非视图V）,由基础表计算汇总所得, 如报送主体X10由A/B/C计算汇总获得。 自动数据 以棊础表为源表，通过存储过程自动计算成为口动数据并存入主体表。 自动数据的时间和规则 上刀自动数据的计算时间在上刀基础层数据准备完毕后，计算的规则以SQL字符的形式存放 在报送主体与规则表中，每次计算将根据必威体育精装版的报送规则计算报送主体，报送主体与 规则表由管理员维护，设置菜单【报送规则】，在报送规则面板中可以进行规则修改， 规则检测’,检测时将执行SQI■并将结果前10条返回页面展示，如果报错则给出后台报错 信息。 前台功能【主体补录及审核】 甲方要求前台提供对主体表的增删改查。 设置菜单【主体补录及审核】，用户在该页面进行主体表的［查询］、［新增］、［修改］、［删除］。 操作后提交审核，数据状态为未审核，经山审核岗员工审核可变为己审核和已拒绝。 前台功能【报送】 在菜单【报送】中选择［主体］（必选），［报送期］（可选），查询出未报送的主体数据，点击 ［报送］即可住成XML报送文件到指定目录，报送任务完成。 主体表ETL字段 lastopttime （授后操作时间）自动数据是存表时间，新建、修改、删除是提交审核时间。 fromtype （原始/干预）白动数据是原始，新建、修改、删除是干预。 confirmflag （未报送/已报送），白动数据是未报送，人工干预提交审核的是未报送，报送 之后是已报送。 underwritflag （待审核/己通过/已绝），口动数据初始是待审核，人工干预提交后是待 审