Oracle DB2
运营型业务系统
数据仓库
数据集市
报表 分析型应用
© 2007 FEnet Software Co., Ltd. All Rights Reserved.
日程
为什么需要模型
模型的组织结构
模型实施方法 模型设计策略 Q
&A
© 2007 FEnet Software Co., Ltd. All Rights Reserved.
|
Hash code字段组成规则

带anchor的实体


带status表的实体（Commercial agreement、Group agreement、Individual agreement、 Claim folder、Elementary claim） 不带status表的实体

除表的主键、type id、Partition key、Status、Status date、Status reason、 Valid from date、Valid to date、 Effective from date、Effective to date、 Population timestamp之外的所有字段 除表的主键、 type id、 Partition key、 Valid from date、Valid to date、Effective from date、Effective to date、 Population timestamp之外的所有字段
BI.Insurance i.DWM for P&C 模型设计说明
Product | Application | Solution | Professional Services | Business Consulting | Outsourcing
© 2007 FEnet Software Co., Ltd. All Rights Reserved.
1.逻辑模型 2.物理模型 3 逻辑物理数据元 素对照表
设计文档： 1.Mapping流程图 2.数据元素Mapping 文档
1.目前的报表 2.想做的报表 3.想做的功能
A：数据源报告： 1.主要功能 2.历史数据情况 3.与其它系统关系 4.联系人 B：数据质量报告： 1.数据类型 2.值分布 3.关联情况
© 2007 FEnet Software Co., Ltd. All Rights Reserved.
|
Partition key

问题的提出:

在进行多表关联时，所涉及的关联表行数巨大，关联速度达不到要求。

解决方案：在所有大表中建立 Partition key, 按照该键的键值对表进行
物理分 区。Partition key 从Partition config 表中获得。分区策略是 按照分公司进行分区。
© 2007 FEnet Software Co., Ltd. All Rights Reserved.
日程
为什么需要模型
模型的组织结构
模型实施方法 模型设计策略 Q
&A
© 2007 FEnet Software Co., Ltd. All Rights Reserved.
|
日程
地理位置
地理区域，物理的 或电子的地址信息
渠道
与客户交易或接触 的渠道信息
理赔
与理赔相关的活动 及各理赔环节
事件
与当事人或协议相 关的一系列事件
资源
保险公司的有形资 产和无形资产信息
© 2007 FEnet Software Co., Ltd. All Rights Reserved.
BI.Insurance i.DWM for P&C
日程
为什么需要模型
模型的组织结构
模型实施方法 模型设计策略 Q
&A
© 2007 FEnet Software Co., Ltd. All Rights Reserved.
|
Hash code


问题的提出:

进行增量加载时无法快速判断对表的原有记录是否新插入。例如：
解决方案：

使用示例：表 A 与表 B 进行关联时，如下进行 select A.column1, B.column2 from A, B where A.foreign_key=B.Primary_key
and A.partition_key in (select Storage partition from
CP R 204
3
Party 041
Place Label
823
P Label CP R 927
P Name CP R 926
Party Name 366
映射
数据集市
财务报表数据集市 中介绩效分析数据集市
健康险盈利性管理数据集市
营销管理快速入门 潜在客户管理
客户细分和管理
保险盈利性分析
© 2007 FEnet Software Co., Ltd. All Rights Reserved.

1. 理赔案件发生的时候,增量文件会把保单数据也传来 2. 保单增量过来,可能只是投保人的信息改了,而目标保单表所需信息并没有改变

使用示例：

使用增量的比较字段生成 Hash code。在对表进行增量加载时，对增量文件中的每一条记录生成 Hash code 将生成完的 Hash code 与原表中同一anchor id并且最新的记录的 Hash code 进行比较 如果一致的话，即不动作；如果不一致的话，即新插入。 在 individual agreement 表中使用各个需要保留历史信息的字段生成 hash code。 在增量加载时，使用业务增量文件中的字段生成 hash code。 与 Individual agreement 表中同一agreement id的最新记录的hash code 进行比较。
车险承保分析 通用承保分析
核心业务 财务系统 再保险系统 人意险系统 精算系统 aCRM 数据集市 客户关系 管理OCRM ALM 客户讯息 ECIF 财务分析 数据集市 外部数据 财务分析 应用 ALM应用 业务持续性 分析数据集市 风险管理 应用
监管报表
管理报表
“数据和信息集成平台” “统一的分析平台” “唯一的信息出口”
需求划分 多维建模 使用模型、产生报表
数据筛选
客户提供需求
字段映射
数据质量分析
需求整理
Mapping程序开 发测试 数据加载
代码整理
产出： 原则：
需求文档：
1.报表需求 2.功能需求 3. 非功能需求
1.数据筛选清单 2.数据源报告： 3.数据质量分析报告 4.代码清单
Mapping文档： 源-模型对应关系
© 2007 FEnet Software Co., Ltd. All Rights Reserved.
BI.Insurance i.DWM-Agreement
© 2007 FEnet Software Co., Ltd. All Rights Reserved.
BI.Insurance i.DWM-Claim
为什么需要模型
模型的组织结构
模型实施方法 模型设计策略 Q
&A
© 2007 FEnet Software Co., Ltd. All Rights Reserved.
|
EDW体系架构
源系统层
手工数据
ETL层
数据仓库层
ETL层
数据集市层
应用层 企业统一分析平台
展现层
数据仓库
业务量分析 数据集市

底层数据模型主题域说明：

Agreement：保单、批单申请及管理；
Claim：理赔
Financial Transaction：应收应付、实收实付以及交易关联 Party：当事方，包括当事方的组织结构、角色结构及类型 Money Provision：资金管理 Specification And Product：规范及产品管理 Place：地点 Code：标准代码 Activity：活动管理 Physical Object：实物、标的管理



不带anchor的实体

关联实体
原则上不需要保留历史，一般执行Update操作。如果有需要的，ETL Mapping特别指明 对于需要保留历史的关联类型，除Identifier、Partition key、Nature id、 Left anchor identifier、 Right anchor identifier、 Left entity identifier、Left entity type id、Right entity identifier、Right entity type id、Valid from date、Valid to date、Effective from date、 Effective to date、Population timestamp之外的所有字段
© 2007 FEnet Software Co., Ltd. All Rights Reserved.
BI.Insurance i.DWM-Physical Object
© 2007 FEnet Software Co., Ltd. All Rights Reserved.
日程
为什么需要模型
如果一致，即不动作 如果不一致，则插入新记录。


备注：

relationship表是要根据业务去判断是否关系已经存在，然后，如果有其他属性（如：Role player - Physical object age），才需要用hashcode判别是否重复。