1.保险案例研究
高级管理层们一直鼓吹向以客户为中心转换的理念,而不是传统的产品为中心的方法,以努力获得竞争优势。CIO跳入这一潮流中成为变更的催化因素。同一战壕中的人承诺共享数据而不是将数据拿走用于完成单一的目标。每个人都有强烈的愿望要实现对业务状态的共同的理解。他们吵着要摆脱孤立的数据,同时确保他们能够访问详细的和汇总的企业级别的和业务线级别的数据。
保险价值链
保险公司的主要价值链看似非常简短。核心过程是制定保单、收取保费和处理索赔。保险公司从事许多其他的外部处理,例如,支付保费的投资或合同代理的补偿,·以及许多内部关注的活动,例如,人力资源、财务和购买等。我们将关注与政策和索赔有关的核心业务。
总线矩阵草图
2.保单事务
操作型保单事务系统
- 建立保单、修改保单或删除保单(合乎情理)
- 建立针对保险项的保险项目、修改保险项目或删除保险项目(合乎情理)
- 保险项目费率或拒绝保险项目费率(合乎情理)
- 承销保单或拒绝承销保单(合乎情理)
维度角色扮演
每个保单事务都涉及两个日期。保单事务日期是保单进入操作型系统的日期,而保单事务有效日期是保单事务从法律上生效的日期。在事实表中包含的两个外键,其命名应该是唯一的。与这些键关联的两个独立的维度采用单一物理事实表实现。给用户的是通过视图方式展示的多个逻辑上独立的表,这些视图具有唯一的列名
缓慢变化维
采用类型1技术,可以简单地重写先前的维度属性。这种技术是处理维度变化的最简单的方法,因为属性总是表示最近的描述。例如,也许业务商同意将投保人的生日属性作为类型1属性变化来处理,其前提是假设该属性的任何变化都是正确的。采用该方法,该投保人的所有事实表历史信息将始终与最新的生日数据保持一致。
由于投保人的邮政编码对投保价格和风险算法来说是关键的输入,用户对跟踪邮政编码的变化情况非常感兴趣,因此对该属性应采用类型2技术。当需要对变化按照时间进行精确的跟踪时,类型2是最常见的缓慢变化维度技术。在此情况下,当邮政编码发生变化时,建立包含新的代理键和更新的地理属性的投保人维度行。不要返回并访问事实表。在邮政编码发生变化前的历史事实表行,仍然存储旧的代理键。
针对大型的和快速变化维度的微型维度
保险项是房屋、汽车或其他特定投保项。保险项维度为每个实际的保险项构建一行。保险项维度通常比投保人维度大,因此保险项维度是另外一个考虑部署微型维度的地方。(微型维度确实是一个重点)
多值维度属性
用户的行业按照比例拆分,例如, 50%农业服务、30%日用产品、20%石油及天然气钻探,·则可在桥接表每行中分配权重因子。若需要处理某个关联的用户的行业代码不存在的情况,可以建立一个特殊的表示“未知的”桥接表行。
作为事实或者维度的事实属性
下面让我们来看看保险项目维度。对某个给定类型的保险项来说,大型保险公司具有几十个或上百个不同的保险产品可销售。特定保险项的实际评估价值,类似某人的房屋,是一个连续值的数字量,随着时间的推移,对一个给定的保险项来说会发生变化,因此要将这种变化看成是合理的事实。在维度表中,您可能会存储一个描述性的价值范围,例如,评估值为250000~299999,以实现分组和过滤。基本保险项目的限制可能是更标准化的且不连续的值,类似重置值或多达$250 000。这样的情况下,可以将其视为维度属性。
退化维度
如果您获取所有的保单表头信息并将其放入其他维度中,保单号将会被当成退化维度来处理。显然您希望避免建立一个仅有少量键的保单事务事实表,而将所有的描述性细节(包括投保人、日期和保险项目)嵌入超负荷的保单维度中。某些情况下,可能会有一个或两个属性仍然属于保单而不属于其他维度。例如,如果保险商基于所有保险项目和保险项为保单建立了一个整体的风险级别,则这一风险级别可能属于保单维度。当然,此时保单号就不再是退化维度了。
低粒度维度
保单事务类型维度是针对前文列出的包含原因描述符的事务类型的较小的维度。事务类型维度可能包含不超过50行的数据。即使该表无论是从行号来看还是从列号来看都非常小,属性仍然应由维度表来处理。如果文本特征被用于查询过滤或报表标识,则它们属于维度。
审计维度
您可以选择将ETL过程的元数据与事务事实行关联,在获取过程中通过利用某个键与一个审计维度行连接。每个审计维度行描述了事实表行的数据的世系,包括获取的时间、源表和获取软件的版本等。
保单事务事实表
异构的子类或超类的产品
辅助保险累积快照
累积快照可用于表示流水线过程中的关键里程碑信息。它获取保单、保险项和保险项目的累积效应,然而,它不能存储发生的每一个事务的信息。通常标准流水线中事务型事件或未预期的离群点可能会掩盖累积场景。另一方面,源于事务的累积快照,提供了关键过程事件之间延迟和延续情况的明确的景象。
3.保费周期快照
一致性维度
投保人、保险项和保险项目维度应该是相同的。表示每天的日期维度应该可以用一致性的月维度表替换。不需要按月跟踪参与保单事务所有的雇员,但保留涉及的代理可能是比较有用的,特别是因为字段操作非常关注持续的收益指标的分析。事务类型维度可能很少被使用,因为它不能以周期快照粒度应用。相反,可以引入状态维度,这样用户可以快速识别保险项目或保单的状态,例如,本月以来新保单或取消的保单的情况。
一致性事实
预付事实
再谈异构超类与子类
每个子类快照事实是超类事,实表某一段的拷贝,该表仅包含那些属于特定业务线的保险项目或保险项的键。使用超类事实表主要是为了方便开展分析工作,分析时可以使用超类和自定义子类事实,而不需要同时访问两个大型事实表。
(以前觉得不是很重要,现在想来觉得挺重要的)
再谈多值维度
4.更多保险案例研究背景
更新保险行业总体矩阵
5.索赔事务
6.索赔累积快照
复杂工作流的累积快照
累积快照事实表通常适合于包含具有建立好的里程碑的可预测的工作流。它们通常包含5~10个里程碑日期,分别表示流水线开始、结束,以及开始与结束之间的关键事件。然而,有时工作流会缺失可预测性。它们仍然具有定义的开始和结束日期,但是中间的里程碑较多且不稳定。某些事件可能会跳过中间的里程碑,但是针对这些事件,没有可靠的模式。
在此情况下,首要的任务是确定角色扮演的日期维度的关键日期。这些日期表示最重要的里程碑。过程的开始日期和结束日期肯定在其中,此外,您应当考虑其他通常会发生的关键里程碑。这些日期(以及它们关联的维度)将被用于扩展对B1应用的过滤。
时间范围累积快照
累积快照易于表示工作流的当前状态,但是不利于表示中间状态。例如,某个索赔可能会移进和移出各种状态,诸如发起、否决、结束、辩论、再次发起、再次结束等。索赔事务事实表将包含不同的行用于表示每个事件,但是正如前文讨论的那样,它无法跨事务累积度量,如果打算从这些事务事件重新建立对流程的评价,将会变得非常困难。同时,典型的累积快照不允许针对过去的任意日期重建索赔工作流。
作为选择,您可以在累积快照中增加生效日期和截止日期。在此场景下,与其在变化发生时,对每行进行破坏性的更新,不如增加一个针对时间范围的新行来保存索赔状态。与类型2缓慢变化维度类似,事实行中包括下列增加的列:
快照开始日期
快照结束日期(当某一给定索赔增加了新行时更新)
快照当前标识(当增加新行时更新)
周期而不是累积快照
对于索赔周期比较长的情况,例如,长期的残疾或人身伤害索赔具有多年寿命,您可以将快照表示为周期快照而不是累积快照。周期快照的粒度为每个固定快照间隔(例如月)的活动的索赔对应一行。事实表示为周期中发生的诸如索赔额、支付额和改变准备金等数字的可加事实。
7.保单/索赔合并事实表
8.无事实的意外事件
9.需要避免的常见维度建模错误
- 错误1 在事实表中放置文本属性
- 错误2 限制冗长的描述符以节省空间
- 错误3 将层级划分为多个维度
- 错误4 忽视对维度变化的追踪
- 错误5 使用更多的硬件解决所有的性能问题
- 错误6 使用操作型键连接事实表和维度表
- 错误7 忽视为事实表粒度的声明并混淆粒度
- 错误8 使用报表来设计维度模型
- 错误9 希望用户查询规范化的原子数据
- 错误10 违反事实和维度的一致性要求
需求驱动的维度设计方法
价值链影响,以及示例保险公司的总线矩阵片段
互补事务、周期快照和累积快照模式
维度角色扮演
处理缓慢变化维度属性
处理大型、快速变化维度属性的微型维度
多值维度属性
用于操作型控制号码的退化维度
跟踪数据世系的审计维度
处理具有变化属性和事实的产品的异构超类和子类
用于综合指标的杂项维度
一致性维度与事实
从不同的业务过程合并度量的整合事实表
无事实的事实表
设计维度模型时应该避免的常见错误