BI体系结构.pdf

BI体系结构.pdf

《BI体系结构.pdf》由会员分享，可在线阅读，更多相关《BI体系结构.pdf（29页珍藏版）》请在冰豆网上搜索。

LONGTOPGROUPLongtopFinancialTechnologyCo.,Ltd.BI数据模型体系层次议程引言BI环境中的数据层次各层次设计重点各层次数据使用议程引言BI环境中的数据层次各层次设计重点各层次数据使用以个人客户为例，研究信息通路信息采集信息采集信息整合信息整合信息应用信息应用数据组织形式的考虑面向全局or面向局部？

冗余or非冗余？

频繁更新or相对稳定?

议程引言BI环境中的数据层次各层次设计重点各层次数据使用BI环境中的数据层次7第一层第一层结构几乎和源系统一致部分数据保持全量少量数据保持少量历史第二层第二层面向整合主题设计提供规范和共享第四层第四层面向应用按需定制第三层第三层初级的数据加工明细VS汇总依赖对应用的提炼第一层偏源系统模型部分数据保留全量少量数据保留短暂历史简单处理不考虑整合重点考虑保留策略服务于数据加载服务于数据加载直接提供基于源系统结构的简单原貌访问直接提供基于源系统结构的简单原貌访问第一层数据偏向于维持源系统原貌，一般不会对业务数据进行整合加工。

（可能存在一些数据的抽取转换工作，但不影响维持偏源系统的数据模型）；根据业务使用需要或加载测试需要，可能会改变某些源系统表，将其按历史表形式存放，但不影响其包含的业务信息含义；某些源系统表在第一层会保留全量数据，如何保留和保留长度通常出于数据策略而非模型策略。

第二层面向全局，数据整合中性设计，灵活可扩展提供规范和共享面向主题偏范式化细节信息长期保留历史长期的，细节的，整合的数据存储长期的，细节的，整合的数据存储为为BIBI环境中的各类业务需求提供支持环境中的各类业务需求提供支持第二层数据整合多个数据源，并按照主题进行划分；在定义主题的过程中，提供相关业务概念的规范定义；第二层的数据模型并不偏重于面向某个应用，而是站在企业角度统揽全局，提供灵活可扩展的模型设计；偏范式化的设计是为了最大程度的保持一致性和灵活扩展性由于面对不同的应用和不同的数据需求，因此第二层通常保留最细粒度的业务数据，并保留尽可能长的历史。

第三层全局考虑，相对中性多层次设计初级数据加工侧重业务理解提炼应用需求共性多种数据粒度更多的业务含义提供相对中性，具有业务意义的初级加工数据提供相对中性，具有业务意义的初级加工数据支持上层应用的数据加工，或供业务人员的访问支持上层应用的数据加工，或供业务人员的访问第三层的数据模型不面向特定应用，而是提炼多种应用的需求共性，设计相对通用的实体对象；第三层包括多种数据粒度，需要逐层加工、统计、汇总；第三层和第二层的区别在于：

第三层进行更多的数据加工，而非仅保留原始业务信息；第三层的设计通过降范式、预连接、适当冗余等多种方式提供更高的查询效率；第三层的设计更侧重于业务人员理解和使用；第四层形式各异各自独立的数据集市满足特定业务的需求面向应用按需定制提供特定应用使用提供特定应用使用第四层的数据模型面向特定应用，按需定制，其形态随应用不同而变化，既有可能是为数据挖掘而设计的大宽表、也有可能是为OLAP分析而设计的雪花、星型模型；第四层相对独立、仅为特定应用服务，各应用间较少共享数据；各数据层次的定位第一层第二层第三层第四层目标目标服务数据加载；直接提供基于源系统结构的简单原貌访问；长期的，细节的，整合的数据存储；为BI环境中的各类业务需求提供支持相对中性，具业务意义的初加工数据；作为上层应用数据加工的基础，或供业务人员直接访问；服务特定应用原则原则简单处理，不考虑整合；关注保留策略；面向全局，数据整合中性设计，灵活扩展提供规范和共享提炼应用需求共性多种数据粒度易于理解和使用面向具体应按需设计形式形式偏源系统模型；少量数据保留短暂历史；部分数据保留全量面向主题设计；偏范式化；长期保留历史；初步数据加工；分层设计；形式各异，依具体应用不同；议程引言BI环境中的数据层次各层次设计重点各层次数据使用重点关注第2-4层14第一层第一层结构几乎和源系统一致部分数据保持全量少量数据保持少量历史第二层第二层面向整合主题设计提供规范和共享第四层第四层面向应用按需定制第三层第三层初级的数据加工明细VS汇总依赖对应用的提炼各层设计重点主题定义框架设计整合策略实施方法Layer2应用筛选应用提炼Layer3整体性一致性Layer4第二层主题定义产品客户化自行设计项目目标是什么？

可参考主题都有哪些？

该主题在当前环境下是否适用？

是否需要其他修改？

目标达成！

项目目标是什么？

总是有这些共通的主题：

客户、协议（账户）、产品、事件（交易）其他业务信息的归纳使用业务熟悉的主题词汇目标达成！

第二层框架设计主实体名称含义分类分类依据子类名称子类含义关系主实体间关系其他重要关系框架设计体现了模型设计原则框架决定了模型的整体结构框架是基石，经验是资源第二层整合策略同一业务对象有多种实例是否整合是否整合依赖业务现状，需要确定影响性确定信息源选择单一信息源（系统）？

还是多个源？

源保留策略整合前信息是否保留？

整合标识选择整合后的对象标识选择已有标识？

还是新建？

确定业务对象整合策略第二层整合策略（例）举例某银行客户信息现状：

已经有ECIF系统处理全行的客户信息，包括个人和对公；并且已进行全行系统客户编号整合，但不排除一些历史遗留数据；信贷系统认为ECIF系统的客户信息不足以支持客户贷款管理，因此在ECIF基础上新增了一些客户信息，单独保存；信贷系统除了客户初笔业务时和ECIF交互客户信息外，均独立维护客户信息；可以得出：

（1）可以ECIF客户信息为主，将其他系统客户信息进行整合；

（2）历史遗留数据可能无法和ECIF客户相对应；（3）其他系统存在ECIF中没有的客户信息；（4）其他系统可能存在和ECIF中客户信息不一致的数据；第二层整合策略（例续）是否整合整合，和业务部门讨论后确定以ECIF为主构建客户统一视图确定信息源两个源系统信息有交叉，均作为本次客户整合的信息源源保留策略源系统客户信息不做保留整合标识选择不新增标识，取用ECIF客户标识经确认，得出客户主题整合策略：

第二层实施方法整合业务对象的所有信息源列表整合业务对象下的信息项取舍规则源信息保留规则标识的定义规则、标识的映射规则（若新增标识）标识选取规则（若选取原有标识）例外处理在整合策略的指导下，定义具体的整合方法在整合策略的指导下，定义具体的整合方法第二层实施方法（接前例）信息源取舍核心和信贷两大系统负责维护客户信息，因此作为客户整合的信息源信息取舍以核心系统为准，信贷系统补充源信息保留N/A标识选择规则取用ECIF客户标识例外处理信贷系统存在核心系统没有的客户，对于ECIF中没有的客户，按“信贷系统编码+前缀”设定客户标识。

经确认，得出客户整合的实施方法：

*实际情况中整合规则需要详细到可操作程度第三层应用筛选确定业务指标、业务口径收集范围依赖于项目目标依赖于业务部门配合程度并不局限于当前基础数据的满足程度须确保后续有相关业务人员回答加工口径问题第三层应用提炼选取/提炼公用度较高的业务统计口径可能是某一个业务统计指标的一个中间统计口径需要业务部门的鼎力支持需要参考外部的行业统计分析经验很大程度依赖于模型设计人员对业务的理解整合有差异的业务统计口径是否整合同样依赖于业务现状需要有完整的文档描述加工规则和适用范围第四层按需定制面向应用的模型设计尽可能多的使用尽可能多的使用第三层模型实体第三层模型实体整体性整体性一致性一致性加工规则应尽量和加工规则应尽量和已有规则保持一致已有规则保持一致议程引言BI环境中的数据层次各层次设计重点各层次数据使用各层次数据使用示例BI数据审计/风险管理等常常需要未经加工的业务原始数据（第一层）源数据质量检查规则通常部署在第一层，同时提供常规报告业务部门人员多数需要常规报表供日常呈报（第三层）POWERUSER通常需要访问第二层对数据进行深入分析业务人员参考整合规则来验证业务正确性（第二层）业务人员通过设定业务检查规则来明确模型可用性（第三层）应用用户、决策用户会访问特定应用（第四层）保密须知：

本文件及其书面或其他任何形式的附件乃以保密形式提供，其著作权归属于本公司，仅供阁下内部使用。

未经过本公司的审核、确认及书面授权，阁下不得以任何方式在任何媒体（包括互联网）上公开引用或在阁下的任何资料中引用本文件及其附件中的任何数据和信息，不得以任何方式将本文件及其附件中的任何内容提供、披露给其他单位或个人。

敬希阁下与我们共同遵守法律。

四海皆融通四海皆融通