使用 IBM Industry Model Information Insurance Warehouse 定义智能和成熟的数据模型

保险业数据仓库开发方法简介

在本教程中,理解使用 IBM Industry Model Insurance Information Warehouse (IIW)(IBM Industry Models 产品的一部分、针对保险领域定义)为数据仓库项目开发数据模型的方法。本教程将展示开发核心数据仓库(Core Data Warehouse,CDW)和专用数据栈( Data Mart,DM)模型的最佳方法。本教程还将介绍如何使用推荐的数据仓库开发方法(Recommended Data Warehousing Development Method,DWDM)来处理 IIW 模型模式框架,从而为保险公司架构 DWH 解决方案。

Alexander Tarabrin, 顾问 IT 架构师, IBM China

Alexander Tarabrin 的照片Alexander Tarabrin 拥有 14 年 IT 从业经验,目前是 IBM(德国)的 IBM Software Group Services 的一名顾问 IT 架构师。Alexander 的工作领域包括数据建模、数据管理、行业模型、以及客户数据集成。



Hermann Voellinger, 高级 IT 架构师, IBM

Hermann Voellinger 的照片Hermann Voellinger 是 IBM Software Group Services 的一名高级 IT 架构师。在过去 12 年中,他一直担任 IT 架构师,负责德国的大型数据仓库(DWH)项目。其中前 10 年,他在 German Development 实验室工作,担任文本和数据挖掘解决方案及工具的首席开发人员兼架构师。他的主要技能和关注领域是数据填充过程(ETL)、数据建模概念,以及 DWH 解决方案的策略和架构。



2011 年 4 月 18 日

开始之前

简介

数据仓库设计和数据建模是计算机科学和 IT 结合的产物,众所周知、意义重大。借助上世纪 90 年代初研发的几种方法,这种技术得以发展起来。最重要的方法由 Ralph Kimball(自上而下)和 W. H. Inmon(自下而上)定义(参见 参考资料)。

商业数据建模产品因为其特定于内容的知识而弥足珍贵,这是基于实践经验和业务专长的。IBM 在这个领域提供了一个智力资本(intellectual capital)产品系列,称为 IBM Industry Models。IBM Industry Models 产品包含一些用于数据建模(关系型和多维型)的模式框架,这些框架经过充分测试,比较成熟,针对几个行业打包。本教程将简要介绍 Information Insurance Warehouse (IIW),IIW 是为保险业定义的 IBM Industry Models 产品的一部分。

本教程介绍使用 IBM Industry Model IIW 为数据仓库(DWH)开发数据模型的方法。本教程将演示开发核心数据仓库(CDW)模型(高度规范化的数据模型,包含原子数据元素)和数据专用栈(DM)模型(反规范化 [de-normalized] 的数据模型,实现多维数据模型的结构)的方法。多维数据模型的特征有两点:一是度量值定义,存储在事实表 中;二是维度表定义,定义分析的轴或维度。

本教程中描述的方法是用于开发数据模型的 IIW 路线图。IIW 路线图基于自上而下的方法,这种方法开始于业务需求采集和业务模型(IIW 术语称为分析数据模型)定义。定义业务需求是其他所有工作的前提条件。理想情况下,这个工作应该由数据建模师 和业务部门的专家共同完成。当业务部门创建并批准模型时,逻辑模型创建阶段就开始了。

逻辑模型设计包含两个步骤:先设计 DWH 逻辑模型(CDW),然后设计 DM 逻辑模型。遵守顺序很重要,颠倒设计顺序可能会产生意想不到的结果。因此,IIW 路线图的结构,以及本教程,被划分为以下 4 个阶段:

  1. 阶段 1:采集 IIW 业务需求
  2. 阶段 2:定义分析数据模型
  3. 阶段 3:设计数据仓库逻辑模型
  4. 阶段 4:设计数据专用栈

这 4 个阶段将完成不同的目标并提供不同的可交付结果:

阶段 1:采集 IIW 业务需求
BI 项目应该负责业务需求的完整描述。此阶段的可交付结果是一个概念模型和一个分析需求模型。
概念模型
将在整个组织中使用的所有概念和业务术语的模型
分析需求模型
处理特定行业问题的业务需求的预定义模型。这些模型被表示为度量值和维度。
阶段 2:定义分析数据模型
一个概念模型,表示业务概念以及业务概念之间的相互关系的理想全景图。这个模型是一个独立平台,不需要实现的物理方面。此阶段的可交付结果是分析数据模型。
分析数据模型
指定表示概念模型中定义的概念需要的规范数据结构的数据模型。
DWH 和 DM 设计阶段
业务概念映射到一个实体-关系(ER)逻辑模型(DWH)和一个多维(MD)逻辑模型上。这些模型是数据库中的数据的物理结构的基础。此阶段的可交付结果是 DW 设计数据模型和 DM 设计数据模型。
DW 设计数据模型
代表用于信息处理的原子和分析数据的企业级存储库的数据模型。
DM 设计和数据模型
实现分析需求并构造为支持特定维度分析的维度模型。

图 1 总结了这些可交付结果。

图 1. 图 1. 4 个 IIW 阶段的可交付结果
图表:概念模型注入分析需求和分析数据模型。分析需求注入 DW 设计模型。分析数据模型注入 DW 设计数据模型。DW 设计数据模型注入数据专用栈设计数据模型。

IIW 还定义了 3 个模型层:

  • 基础层包含概念和分析需求模型。
  • 分析层涵盖分析数据模型。
  • 设计层包含 DW 设计和 DW 设计模型。

图 2 描绘了这些层。

图 2. 图 2. IIW 模型层
展示 3 个基础层,它们带有上述支持模型层,该层包含 HIPAA、Sarbanes Oxley、Basel II、IFRS/IAS 和 Solvency II 的架构

本教程下面各小节将分别描述这 4 个阶段,每个阶段都有一些使用 InfoSphere™ Data Architect (IDA) 的示例。那些示例使用 IBM IIW Model Version 8.2。IIW 模型内容通过 Enterprise Model Extender (EME) 工具导入 IDA。EME 是针对 IBM InfoSphere Data Architect 产品的一组插件扩展。要跟随本教程的操作,您需要安装这些产品。


阶段 1:采集 IIW 业务需求

需求分析的早期阶段需要适当的工具配备和模型模式。此阶段的工作包被分配给具有丰富行业知识和高级 IT 技能的业务分析师。此类工作包的可交付结果通常是没有结构化的文档,比如会议协议、演示文稿和字处理文档。以这种方式收集的信息通常没有任何独立模型。这些信息原样 交付给下一阶段(业务模型),该阶段将创建手动处理大量输入可交付结果的负载。显然,这需要引入高级的、非实体关系的模型。

访问知识和参考解决方案是另一个需求。可用的解决方案模式(solution pattern)应该以一种适当的方式表示,以支持业务顾问以一种轻松高效的方式执行以下操作:

  • 访问 IIW 框架模式和文档
  • 收集 IIW 框架中的需求
  • 将来自需求分析阶段的可交付结果映射到 IIW 框架的组件

IIW 引入基础层模型,向业务顾问和分析师提供工具集和知识产权资源,它们作为商业产品分发。基础层模型包括以下组件:

概念模型
包含将在其他模型中使用的业务元数据
分析需求模型
使用概念模型中确认的业务元数据记录分析查询的需求
业务概念词汇表
提供收集的业务术语的类似词典的表示

概念模型

概念模型是业务需求定义的最高模型。此阶段中收集的业务数据相当缺乏组织。概念模型为收集数值型和非数值型数据元素以及它们之间的依赖项的有关信息提供工具支持。

概念模型的各部分如下:

  • 关注基于度量值的需求的汇总描述符。对于 分析需求模型,汇总描述符称为度量模板。
  • 模型的概念部分,主要关注按层级组织的元数据集合。这个部分用于分析需求模型中定义维度。

汇总描述符模型表示一列预定义的描述符。每个描述符都包含一个惟一标签和文档文本,如 图 3 所示。

图 3. 图 3. Accounts Receivable 汇总描述符的属性
屏幕截图:IDA 数据项目浏览器显示 Accounts Receivable

(查看 图 3 的 大图。)

对于已计算的度量值,您可以使用一个特性来记录计算表达式并引用相关度量值。汇总描述符可以被链接到其他模型(例如,分析需求模型或分析数据模型)。

模型的概念部分包含以下元数据类型:

描述符
可以是数值型也可以是非数值型。数值型描述符可以用于已计算的度量值。
关系
描述概念之间的关系。
层级
描述业务概念的顺序。每个概念都有几个分类和描述该概念的子概念。以下三个子概念被使用:
  • 分类符
  • 描述符
  • 关系
通过使用分类符,可以记录业务层级。例如,一个账户拥有 4 个分类符:
  • 账户期间类型
  • 账户状态原因类型
  • 账户状态类型
  • 账户类型
在账户类型下,可以定义 4 个子类型,包括货币账户。货币账户本身有 7 个子类型,依次类推,如 图 4 所示。这种图表标记法技术称为架构-值标记法(schema-value notation)。使用这种标记法,可以在同一个层级中记录元数据(级别名称)和业务数据(级别值)。
图 4. 图 4. 描述账户层级的一部分的概念模型的图案(cut-out)
模型的层级视图,显示账户类型、货币账户类型、货币账户的类型等

概念模型是一个重要的 IIW 特性,用于从一个较高的业务级别视角记录业务概念。它还显示一个业务对象(比如 图 4 中的业务对象 account)的现有依赖项和关系。

分析需求模型

分析需求模型(Analytical Requirements Model,ARM)的目的是对概念模型中收集的概念进行分组和分类。一个分析需求模型表示单个分析需求。一个分析需求包含分析一个特定业务案例所需的度量值和维度。

分析需求被分为几个组,这些组称为关注区域(focus areas)。每个关注区域代表一个业务问题领域,比如索赔分析、产品管理、风险管理等。可以创建替代关注区域。例如,索赔效率分析(claim efficiency analysis)可以是索赔分析(claims analysis)的替代关注区域,如 图 5 所示。

图 5. 图 5. 分析需求模型的关注区域
关注区域的浏览器视图,高亮显示 claim analysis

一个关注区域包含多个分析需求。一个分析需求包含一组度量值和一组维度。例如,需求 Customer risk analysis 包含维度 PolicyProduct Time dimension,包含度量值 Number of accidentsNumber of claims,如 图 6 所示。

图 6. 图 6. 样例分析需求
customer risk analysis 的浏览器视图,包含维度 policy、product、time dimension、number of accidents、number of at fault accidents 和 number of claims

分析需求模型和概念模型之间的链接很关键。所有度量值和维度都被链接到概念模型中的适当概念。度量值重用概念模型中预定义的汇总或可度量属性。维度是概念模型中预定义的业务概念、分类符、关系和描述性属性的视图或包装器。

这种链接方法的好处是不同分析需求中引用的语义上一致的度量值或维度被映射到概念模型中的单个概念。这解决了冗余性问题,允许将一个特殊业务概念的相关文档放置到一个地方。反之,您也可以检查概念模型的任意元素,查看来自分析需求模型的引用。

IIW 附带了一组预定义分析需求,它们被划分为几个关注区域。业务用户能够选择分析需求来修改或创建新的分析需求。请参阅文章 Scoping the IBM Industry Model for banking using Enterprise Model Extender and InfoSphere Data Architect 了解更多信息。

业务词汇表

业务词汇表(或业务术语表)是任何数据仓库项目的必要可交付结果。通常,它作为一个半结构化文档手动维护,在需求目录和数据模型上有依赖项。IIW 将业务词汇表交付为建模环境的一个集成部分。

业务词汇表总结概念和分析需求模型中收集的业务术语。业务词汇表包含已定义的术语(单词),这些术语被组合到词典 中,如 图 7 所示。

图 7. 图 7. 业务词汇表
左边窗格显示 asset holding account 高亮显示的浏览器视图,右边窗格显示 asset holding account 的定义字段

(查看 图 7 的 大图。)

每个单词都提供了说明,即概念或分析需求模型的适当元素的说明。业务词汇表对外开放,允许修改。业务用户能够编辑或创建词典和单词。业务用户可以定义一个 单词生命周期,在其中指定状态,比如 候选已接受标准否决

业务词汇表提供了几个其他特性,其中包括指定同义词或相关单词的功能。

可以使用 Metadata Server 将业务词汇表的内容导出到 IBM InfoSphere Business Glossary。

阶段 1 小结

本小节简要介绍了 IIW 基础层的主要模型,这些模型是需求分析过程中用于收集数据的框架,它们是下一阶段的可交付结果。


阶段 2:定义分析数据模型

IIW 使用术语分析数据模型(analysis data model)来指业务模型(business model)。数据仓库开发方法(Data Warehousing Development Method,DWDM)交付方案在逻辑和物理模型的创建之前预见分析数据模型的创建。分析数据模型是面向业务的,独立于任何涉及或架构。定义分析数据模型是设计阶段最资源密集的阶段。

分析数据模型指定表示概念模型中定义的概念所需的规范化数据结构。作为一个分析模型,分析数据模型不向概念模型中定义的任何内容添加任何新的业务概念。

分析业务模型结构

分析数据模型包含 23 个业务区域,其中包括有关方面、地点、索赔、事件等。分析数据模型拥有 1100 多个实体,每个核心实体都有一个类型层级,比如 Claim 核心实体的类型层级,如 图 8 所示。

图 8. 图 8. Claim 类型层级
拥有 17 个属性的 Claim 类型。层级中的 claim 类型下方是 elementary claim 和 claim folder

超类型及其子类型(称为自然属性(nature))使用 “父-子” 关系连接。属性存储在层级的适当级别。

分析数据模型的实体和属性通过 Enterprise Model Extender (EME) 特有的属性描述。图 9 显示了其他 ClassificationMappings 选项卡。

图 9. 图 9. EME 特有属性
显示 elementary claim 实体上的 classification 和 mappings

使用 Classification 选项,可以验证适当的实体和属性类型。实体最常见的类型是语义实体(semantic entity),属性最常见的类型是语义属性(semantic attribute)。分析数据模型的所有属性都被映射到概念模型,如 图 10 所示。

图 10. 图 10. 到概念模型的映射
显示映射到目标类型 classifier 的 claim folder first advice 类型

模型验证和分析

可以验证和分析模型,以识别容易出错的建模或差距。模型分析被定义为一组规则,可以针对您创建的分析数据模型检查该组规则。例如,有一个规则用于检查模型中定义的所有属性的映射是否存在,如 图 11 所示。

图 11. 图 11. 模型分析规则
高亮显示必须被映射的属性

如果某些映射缺失,如 图 12 所示,执行模型分析后将出现适当的错误消息。

图 12. 图 12. 错误消息样例
显示错误消息:there is no mapping for attributes

阶段 2 小结

本小节介绍如何定义分析数据模型(业务模型),这是 DWDM 方法中最重要的任务。负责这个任务的人员需要同时具备业务知识和数据建模技能。分析数据模型是阶段 3 中将介绍的逻辑数据模型定义的基础。


阶段 3:设计数据仓库逻辑模型

业务用户完成了本教程介绍的前两个阶段。设计 IIW 逻辑模型是面向 IT 的,更适合 IT 用户(数据设计师)完成。IIW 设计层包含原子部分(企业模型)和分析部分(合规维度模型和数据专用栈模型)。本小节介绍 IIW 企业模型。

企业模型的结构类似于分析数据模型。这个模型被封装成几个包。每个包都包含一组工件(实体、属性和关系)以及一些用于满足可视化需求的图表,如图 13 所示。这是 IBM InfoSphere Data Architect 中的逻辑模型的标准结构。

图 13. 图 13. 来自企业模型结构的样例图案
显示层级的浏览器视图

企业模型工件

数据仓库模型表示用于信息处理的原子数据的企业级存储库。此模型包含可能随时间变化的业务信息的值更改历史。您可能需要跟踪这个历史以便进行分析。

数据仓库模型定义以下属性类型:

基础实体
包含原子业务信息。基础实体可以是版本化的,也可以是非版本化的。它需要一个锚点实体(如果是版本化的)或一个根实体(如果是非版本化的)来维护其版本。
锚点实体
充当一个锚点来维护一个实体实例的不同版本。锚点还用作数据仓库环境中的恒定键(Time-Invariant Key,TIK)。
根实体
充当非版本化实体的超类型。
关联实体
充当两个根实体或锚点实体之间的关系。
填充特征实体
包含 ETL 作业相关信息。
分类实体
实例化数据类型 enumeration 的特定语义属性。

这些实体通过如下为企业模型定义的不同类型的关系连接:

设计关系
连接两个实体(通常一对多),针对设计目的(作为导航机制或为了提高性能)。
锚点关系
连接基础实体和相关锚点实体。

实体拥有属性。企业模型中定义的属性类型如下:

基本属性
包含业务数据。
候选键
包含惟一标识一个实体实例的业务键。
关系属性
包含一个外键属性。
派生属性
包含从另一(几)个属性的值派生(或复制)而来的值。

图 14 显示了 claim 域的数据图表的一个图案。属性被省略,以提高可读性。

图 14. 图 14. claim 域的企业模型的图案
显示 claim 域的 “父-子” 关系

定制方法

Enterprise Model Extender 安装后的在线帮助详细介绍了企业模型定制的方法。有一些特定技术用于添加或修改任何类型的实体、关系或属性。这些技术被归结为 8 个转换规则。这些规则通过如下方式描述这个定制方法:添加语义关联实体和语义关联;转换超语义实体和子语义实体;处理派生和复制属性。

定制企业模型时,数据设计师应该记住:企业模型的元素应该被链接到分析数据模型的适当元素。

转为物理模型

与分析数据模型不同的是,企业模型是面向 IT 的。企业模型包含以下特性:

数据版本化
数据仓库设计的一个最重要的方面。企业模型(EM)的基础实体的特点是下面 4 个属性:
  • EFFECTIVE_FROM
  • EFFECTIVE_TO
  • VALID_FROM
  • VALID_TO
EFFECTIVE_FROM/TO 属性依赖语义有效性期间。VALID_FROM/TO 属性依赖一些时间戳(表明当时数据已经从源系统填充数据并表示技术有效期)。
主键
EM 中定义的主键是 4 位整数。它们是没有业务语义的代理键。它们不是从源系统的主键派生的。
数据填充
这些实体包含一些数据填充属性,这些属性描述 ETL 过程相关信息。

阶段 3 小结

本小节介绍了企业模型及其定制方法。可以使用 InfoSphere Data Architect 向导将企业模型转换为物理模型。


阶段 4:设计数据专用栈

业务用户完成了本教程介绍的前两个阶段。设计数据专用栈是面向 IT 的,更适合 IT 用户(数据设计师)完成。 IIW 设计层包含原子部分(企业模型)和分析部分(合规维度模型和数据专用栈模型)。本小节介绍 IIW 分析部分。

合规维度模型(conformed dimensional model)是分析数据的企业级存储库,包含基于事实实体的维度数据结构,事实实体支持将分析数据轻松分发给下游分析模型,比如数据专用栈。

合规维度模型中的维度的结构和业务内容基于并重用数据仓库模型。事实表中的度量值支持分析需求中定义的度量值。

除来自数据仓库模型的数据结构和内容外,合规维度模型还包含以下组件:

  • 构建可以在其上分析度量值的汇总路径的其他关系
  • 用于提高存储和分析效率的其他实体,比如配置文件和帮助实体

在 InfoSphere Data Architect 中,有几个预定义 IIW 数据专用栈逻辑模型,如图 15 所示。

图 15. 图 15. IIW 数据专用栈结构样例图案
IIW 数据专用栈结构样例图案

每个数据专用栈模型本身都包含一组分析子集。图 15 显示索赔效率分析包含 4 个分析包(保存数据类型)和一个关联包(保存关系实体)。这是 IBM InfoSphere Data Architect 中的逻辑模型的标准结构。

使用合规维度模型

合规维度模型就像是一个超级数据专用栈。但是,要小心翼翼地考虑终端用户查询,原因如下:

  • 合规维度模型的维度结构被组织为雪花状,这使得查询更复杂。
  • 有些事实实体可能太通用,这可能会导致含义更少的业务度量值名称。
  • 每个事实实体的维度数量可能太高。维度粒度应尽可能低,以便支持最精细的分析需求,同时不需要任何设计维护。这可能会导致太多事实和较长的查询响应时间。

合规维度模型基于以下两个主要设计原则:

合规维度
合规维度是一个主维度,企业中所有有关各方都已同意其内容。合规维度支持跨多个事实表的度量值的可重用汇总路径。
合规事实
合规事实是一个度量值,企业中的所有有关各方都已同意它的业务定义。合规事实可用于跨多个独立数据源的分析计算并与其他合规事实联用。

这两个设计原则定义跨数据表的一致性,改进分析结果的质量,并促进分析技术,比如钻取技术。

合规维度模型被部分反规范化,以便于提取维度结构来填充下游数据专用栈模型。

合规维度模型的工件

使用 IBM Industry Models 开发 BI 解决方案时,合规维度模型使用以下工件:

事实实体
一个汇总实体,重新组合一组度量值(事实),这些度量值共享相同的维度。事实实体的主键被定义为用作其维度的实体的所有外键的串联。事实实体是维度数据结构的核心实体,可以充当分发到下游数据专用栈的结构的子集的创建基础。
帮助实体
帮助实体管理维度的变量深度的复杂层级结构的分析。仅当这个层级结构是树形而不是网络时,才能使用帮助实体。对于从层级树中的每个节点到帮助实体本身和到帮助实体之下的每个节点的每条独立路径,帮助实体都包含一个实例。地理区域帮助实体就是这样一个例子。
支持实体
仅用于支持分析数据结构的实体。日历日期实体就是这样一个例子。
值组实体
此实体将用于在一个事实表上执行分析的属性组合在一起。值组实体的每个属性都有一组离散值,可以基于那些值汇总事实表的度量值。客户个人资料实体就是这样一个例子。
维度关系
事实实体和基础实体(或来自数据仓库模型的分类实体)之间的关系。
复杂属性
从其他度量值计算而来的度量值,其定义包含一个公式,公式的参数就是属性。
派生属性
其属性值派生自数据仓库模型的一个或多个属性的值。通常,这个值包含一些不是复杂属性的事实实体度量值。它们的值根据数据仓库模型中的原子数据计算。
来自数据仓库模型的其他工件
合规维度模型重用来自数据仓库模型的实体,通常用于定义它的维度和派生属性。请参阅 阶段 3 中的企业模型的工件。以下是部分工件:
  • 基础实体
  • 分类实体
  • 支持实体
  • 基本属性
  • 关系属性

定制合规维度模型

通常,在项目范围上下文中的分析需求上执行的定制驱动合规维度模型的定制。

多亏有到分析需求的映射,对于分析需求中所有预先存在的 Industry Model 元素而言,合规维度模型的定制相当简单。如果分析需求的预先存在的元素在已确定范围的项目的上下文中定制,那么定制应该相应反映到合规维度模型中。例如,一个已确定范围的已定制度量值的定义和示例需要在合规维度模型中审查和定制。

对于需要在合规维度模型中创建的模型元素,可以在 Industry Model Data Warehouse Development Method 的一个特殊任务描述中找到这个任务的描述。

下面两小节提供创建新的合规维度模型元素时需要遵循的规则示例。

规则 1

如果一个新事实实体被添加到合规维度模型,则主键需要被添加到源自分析需求的属性(度量值)列表。 这个实体包含所有关系属性,这些关系属性是维度关系上的外键。动词词组是 for dimensionis dimension of

注意:

  • 对于一个快照 事实实体而言,时间维度将被一个候选键属性(比如一个参考日期)所替代。
  • 组成主键的关系属性应该根据它们表示的维度命名。例如:一个维度关系上的销售代理 ID 带有渠道角色基础实体。
  • 这将在 EME Data Project Explorer 中生成一个主键属性,您应该将其重命名为带有后缀 PK" 的事实实体名称。
  • 您需要将以下技术属性添加到主键属性:
    • 一个 valid from 日期属性,这个属性表示一个时段开始的事务时间,这个已记录的数据的值在该时段内在源系统中为 true。valid from 日期属性被归类为一个基本属性,它使用一个数据类型时间戳 [TIMESTAMP]。
    • 一个 valid to 日期属性,这个属性表示一个时段结束的事务时间,这个已记录的数据的值在该时段内在源系统中为 true。valid to 日期属性也被归类为一个基本属性,它使用一个数据类型时间戳 [TIMESTAMP]。
  • 您需要将新的事实实体映射到它支持的分析需求。

规则 2

如果一个新维度被添加到合规维度模型中的一个事实实体上,则这个新维度需要被定义为一个维度关系,该关系将数据仓库模型的一个基础或分类实体链接到该事实实体。 动词词组是 for dimensionis dimension of

注意:

  • 您应该将表示事实实体中新添加的维度的关系属性定义为事实实体的主键的一个组件。
  • 关系属性的名称必须反映它表示的维度。例如:一个维度关系上的销售代理 ID 带有渠道角色基础实体。

图 16 显示了一个索赔处理性能事实表的一个维度数据模型的一个示例数据图表的一个图案。这个事实表是 Claim Efficiency Analysis (CEA) 应用程序的合规维度模型中的一个预定义事实表。属性被省略,以提高可读性。

图 16. 图 16. 索赔处理性能的维度模型示例
以原因、事故位置开始,拥有邮政区划、组件、以及引导策略通过流程图的维度

(查看图 16 的 大图。)

Claim Efficiency Analysis (CEA) 通过执行以下操作处理影响索赔处理流程效率的因素:

  • 监控来自第三方和再保险人的恢复付款
  • 评估中介机构之间的索赔分布和索赔处理程序的加载
  • 核对未决索赔和索赔估计
  • 执行可能会影响产品开发的索赔统计分析
  • 分析索赔在所有损失事故类型之间的分布

CEA 解决方案允许分析事实表索赔处理性能监控和识别索赔处理流程中效率低下的环节。生成的报告帮助优化供应商的网络并提高运营效率和客户满意度。

阶段 4 小结

本小节介绍了合规维度模型及其定制方法。可以使用 InfoSphere Data Architect Wizard 将合规维度模型转换为物理模型。


结束语

本教程介绍了一个开发流程,该流程用于为一个保险数据仓库构建一个灵活稳定的数据模型。这种方法使用 IBM Industry Model for Insurance Information Warehouse (IIW) 的行业特有概念的业务模板。建模工作本身使用数据建模工具 Information Data Architect (IDA) 和特定增强 Enterprise Model Extender (EME) 完成。Data Warehousing Development Method (DWDM) 中介绍了适当的设计方法。您还了解了关于这个开发流程的主要工件的一些特别提示。理解这种方法的说明将使您做好准备,顺利通过这个设计流程的主要阶段。

这种方法通常包括 4 个步骤 — 从业务对象和视图到越来越多的技术对象。阶段 1 收集需求,阶段 2 构建业务模型。业务需求的收集需要与业务专家共同完成,在您继续这个开发流程之前,需要业务专家审批生成的业务模型。在阶段 1 和阶段 2 中,您使用了 IDA 和 EME 工具环境中的业务词汇表和其他 EME 特有选项。本教程解释了这两个概念模型的结构。

在阶段 3 和阶段 4 中,您从业务模型构建了逻辑数据模型(也称为企业模型)。在阶段 3 中,您为企业模型的原子部分构建了逻辑模型,这是一个规范化的实体关系(ER)模型。在阶段 4 中,您为数据专用栈处理了一个维度逻辑数据模型。这个模型是反规范化的,并针对查询和分析性能进行了优化。描述阶段 3 和阶段 4 的小节提供了 DWDM 方法最重要的工件,并通过示例展示了如何定制其中一些工件。这些示例展示了完成特定建模任务的最佳实践方法。

通过遵循这个明确的阶段路线图,您就能交付稳定可靠的数据模型,这些模型也很灵活,将来能够集成新的业务需求。

本教程使您对 Industry Models 的各个方面有了一个整体认识。 在未来的 developerWorks 文章和教程中,我们将进一步介绍 IBM Industry Models。特别是,我们计划撰写一些文章和教程详细讨论这个使用 IDA 和 EME 的 IIW 数据模型开发流程的 4 个阶段。我们还计划撰写一篇文章,详细介绍在 IDA 和 EME 环境中基于一个现有 IIW 逻辑模型构建一个物理模型的流程。

参考资料

学习

获得产品和技术

讨论

  • 参与 developerWorks 博客 并加入 developerWorks 中文社区,developerWorks 社区是一个面向全球 IT 专业人员,可以提供博客、书签、wiki、群组、联系、共享和协作等社区功能的专业社交网络社区。

条评论

developerWorks: 登录

标有星(*)号的字段是必填字段。


需要一个 IBM ID?
忘记 IBM ID?


忘记密码?
更改您的密码

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件

 


在您首次登录 developerWorks 时,会为您创建一份个人概要。您的个人概要中的信息(您的姓名、国家/地区,以及公司名称)是公开显示的,而且会随着您发布的任何内容一起显示,除非您选择隐藏您的公司名称。您可以随时更新您的 IBM 帐户。

所有提交的信息确保安全。

选择您的昵称



当您初次登录到 developerWorks 时,将会为您创建一份概要信息,您需要指定一个昵称。您的昵称将和您在 developerWorks 发布的内容显示在一起。

昵称长度在 3 至 31 个字符之间。 您的昵称在 developerWorks 社区中必须是唯一的,并且出于隐私保护的原因,不能是您的电子邮件地址。

标有星(*)号的字段是必填字段。

(昵称长度在 3 至 31 个字符之间)

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件.

 


所有提交的信息确保安全。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=Information Management
ArticleID=648277
ArticleTitle=使用 IBM Industry Model Information Insurance Warehouse 定义智能和成熟的数据模型
publish-date=04182011