数据仓库建设方案

1 / 23 数据仓库建设方案 目 录 一 、 概述 . 2 二、四科室需求 . 3 1 、风险科需求 . 3 2 、市场科需求 . 13 3 、业务管理科需求 . 14 4、计2 / 23 划资金科需求 . 15 三、需求分析 . 23 1 、维表 . 23 2 、 事 实表 . 23 3 、 事 务 业 务 处 理 过 程 及 业 务 术语 . 23 4 、主键 .3 / 23 . 24 5 、外键 . 24 四 、 系 统 结 构 图 及 业 务 数 据 流图 . 25 1 、系统结构图 . . 25 2 、 数 据 流图 . 26 五、源数据表结构 . 27 1 、 BCS 系统 .4 / 23 . 27 2 、 CARDPOOL 系统 . 34 3、NAS 系统 . 36 4 、 BCS 系统报表 . 37 六 、 生 成 表 结构 . 39 七 、 码 表 结构 .5 / 23 . 43 八、结果表结构 . 50 九 、 数 据 表 创 建 方法 . 51 1、BCS 系统 . 51 2 、 CARDPOOL 系统 . 57 3、NAS 系统 . 58 4 、 生 成表 .6 / 23 . 58 5 、码表 . 62 十 、 数 据 处 理 过程 . 68 1 、目录结构 . 68 2 、 流 程 说明 . 68 十 一 、 问 题 及 处 理 方法 . 80 7 / 23 一、概 述 Bill Inmon 在 Building the Data Warehouse 书中把数据仓库描述为一个“面向主题的、完整的、非易失的、不同时间的、用于支持决策管理的数据集合”。 数据仓库是只用于制作报表的数据库。 对我们而言，数据仓库是某个“宽广”的数据仓储。它包括许多的主题领域。而一个数据集市，恰恰相反，它把眼睛盯在商业活动的某个非常有限的部分上。它往往涉及某个单独主题或单个类型的分析。 在日常工作中， IT 人员经常听到这样的抱怨：“我要求的报表怎么还没出 来？”或者是“我要对 XX 报表做些修改，怎么还没结果？”等等。 在 IT 飞速发展的最近几年里，银行信用卡部先后针对业务上了一些计算机系统。这些系统的特点是：信息量规模小、数据经常实时更新、适用于业务人员快速录入数据、使用模式相对来说是可以预测的、模式很复杂、业务流程难以更改、数据在线保存的时间较短及各系统之间缺乏必要的联系等。这样的系统被称之为 OLTP 系统。 OLTP 系统的这些特点也就决定了有如此抱怨。 如何解决这些问题呢？我们首先想到的是：把数据集中、完整地存储在中心数据库中。所有的业务 处理在中心数据库上进行。所有的报表工作脱离数据库。这听起来难道8 / 23 不是有点像一个数据仓库吗？我们为什么不在 OLTP 的业务系统数据库的基础上生成报表呢？答案很简单：因为报表经常需要大量的、长时间的数据做依据，然后经过大量的运算，才能得出你想要的结论。这对业务系统的正常运转影响很大，以至于业务系统无法正常运转。 当然，不是什么时候都需要一个数据仓库的。正如数据仓库的定义：是用于支持决策管理的数据集合。 中国银行北京分行从 1986 年 6 月 1 日发行第一张人民币长城卡到现在拥有将近 20 万的持卡人。从 过去手工处理业务到现在拥有几个 OLTP 业务系统。信用卡业务有了飞速的发展。但也应看到信用卡市场的激烈竞争。如何给决策者及时提供决策支持信息，是在激烈的市场竞争中立于不败之地的关键。 二、四科室需求 1、风险科需求 表 1 北京市分行 /信用卡透支利息统计表 年月日 表 2北京市分行 /信用卡透支还款分析表 年月日 来的实际还款也算还款户。 第一列的时间段应允许人为调整，时间的累计是以9 / 23 某一天开始，倒推统计数据。 表 3 XXXX 年第 X 季度关于信用卡透支情况的报告 总行： 根据人总行银管 1997185 号文件，关于调整银行卡报表制度的通知精神，现统计数字如下： 1. 数据仓库概述 经过多年 IT 的建设，信息对于 XXX 的日常管理已经日益重要，并逐渐成为重要的信息资产，信息资产的管理已经成为日常管理中一个非常重要的环节。如何管理和利用好 XXX内部纷繁的数据也越来越成为信息管理的一项重要工作。 在过去相当一段时间内， XXX 业务系统的构建主要围绕着业 务的数据展开，应用的构建多是自下而上构建，主要以满足某个部门的业务功能为主，我们称之为业务处理的时代。这样的构建方式造成了一个个分立的应用，分立的应用导致了一个个的静态竖井。由于数据从属于应用，缺乏 XXX全局的单一视图，形成了一个个信息孤岛，分立的系统之间缺乏沟通，同样数据的孤岛导致只能获得片面的信息，而不是全局的单一视图。存储这些信息的载体可能是各种异构或同构的关系型数据库，也有可能是 XML、 EXCEL 等文件。因此，构建新一代的一体化平台提上了日程并最终促成全域数据的管理方式，目的是覆盖 XXX 各个环节的关 键业务数据，10 / 23 完善元数据管理，形成全局的数据字典、业务数据规范和统一的业务指标含义，能够灵活的获取 XXX 业务数据的单一视图。数据的交换和共享主要发生在上下级组织机构之间或同级的不同部门之间。最终，这些数据可以为部队分析、决策支持等应用提供更及时、准确、有效的支持。 数据仓库的目标是实现跨系统数据共享，解决信息孤岛， 提升数据质量，辅助决策分析，提供统一的数据服务。同时，数据仓库的构建也面临着各种挑战，比如信息整合在技术上的复杂度、信息整合的管理成本、数据资源的获取、信息整合的实施周期以及整合项目的风险等。 2. 全域数据库总体架构 全域数据库总体架构 全域数据库总体的层次，最下面是基础架构层，主要包括支撑这一架构运行的主机系统、存储备份系统、网络系统等内容。从下往上看，再上面是数据源层，既包括各个业务的关系型数据源、内容管理数据源也包括半结构化数据源比如 XML、 EXCEL 等，也包括各 个总队、支队的业务数据源。 数据源层之上是“交换服务体系”，主要包括信息服务总线和服务总线两部分。信息服务总线主要实现数据层的信息整合和数据转换，而服务总线主要实现应用层的信息交换和整合。信息服务总线主要依托联邦、复制、清洗、转换11 / 23 等技术实现，其主要包括信息整合服务和清洗转换加载服务两部分。通过信息服务总线的信息整合服务，可以透明、实时的访问分布在总队和支队的各个业务系统中的各种同构、异构数据。信息整合服务在整个 XXX 层面保证 了数据的完整性和及时性。信息服务主要使用两种技术来完成这一功 能：联邦和复制。通过联邦功能可以把关系数据、半结构化数据组成一个逻辑数据库，对这些数据源中的表可以像操作本地数据库表一样进行操作，而不必关心我们操作的这些数据底层是什么数据源，物理在什么位置。而针对大数据量的数据访问或高并发的访问，通常将源数据增量实时复制到本地，复制的实现是基于对源数据库的日志进行捕获，获取增量数据，并基于消息的机制将其复制到目的数据库，复制的过程中可以实现数据的合并、拆分、转换等操作。 信息服务总线主要完成数据的分析、清洗、转换、加载等工作。数据清洗，主要是去除冗余数据，将零 散字段合并成全局记录，并解决重叠和矛盾的数据，然后通过添加关系和层次结构完善丰富信息。首先面临的挑战就是如何更有效的识别现有的业务系统，包括业务系统使用的分类方法、层次结构、数据分布、数据字典等。如果数据字典不完整或缺失，就要通过方法找出其数据的存储结构以及各个表之间的主外键关联、各表之间的转换关系等，同样，数据的12 / 23 分布情况同样可以使用分析功能来完成。在对现有数据足够了解的基础上，接下来就要制定数据的清洗规则以及转换规则，其中，清洗规则又分为两种情况，一种清洗规则是明确的，另一种清洗规则是模糊的，比如不同系统 中存储的地址信息，“南京市定淮门大街 9 号”和“江苏省南京市下关区定淮门大街 9 号”实际上是一个地址，但计算机会当成两个地址来处理。概率匹配功能和动态权重策略可以匹配创建高质量、准确的数据，并在整个数据域中一致地识别核心业务信息，如人名、位置、和时间。 数据清洗、转换、加载服务对保障数据的准确性和一致性非常重要。在不同的系统中，对同一业务会使用不同的分类方法，同样，数据的类别和层次结构也会不同。需要通过数据清洗、转换、加载层实现对这些信息格式的转换，匹配成通用的信息格式和分类方法，以便提供整个 XXX 业务层面聚合的业务视图。实际证明一体化平台的全域数据梳理中，手工统计可以完成这项工作但不够好，不够直观和没有扩展延续能力。数据清洗、转换、加载工作对未来数据的使用非常重要，即使有工具帮助，工作量依然很大。虽然，开始的时候，这项工作看起来费时费力，但从长远来看，它使得基于这些数据的业务流程和统一数据视图实现自动化，并减少了人为干预不准确或不一致数据的努力，从而节省了大量成本。 XXX 层面的单一视图一经建立，其维护必将是一个13 / 23 持续进行的过程。 数据的管理通常需要一个管理组织来对冲突或缺失的数据进行决策，组 织会通常需要各个业务部门的人参与，而不仅仅局限于通技处或信息中心的人。 XXX 单一数据视图的维护，很多业务部门都做的不够好，时间一久，很多业务部门就变得厌倦，数据清洗转换的工作没有坚持下去。一旦数据的准确性出现问题，业务系统的全局共享就无法再从中获益。 交换服务体系中的服务总线主要基于流程服务、传输服务、交换服务等实现。通过使用总线，可以支持各种协议以及数据格式的数据交互。通过搭建一个基于标准的、开发的、易于集成的、总线方式的服务总线，通过今后对现有系统的逐步升级改造，系统之间以一种成为“服务”的 接口方式统一通过总线方式进行交互，通过对服务的管理，系统之间交互的信息格式的差异、传输协议的差异、采用技术的差异、物理位置的不同等等这些问题都由这个总线来进行屏蔽。进一步通过流程管理，将模块和系统之间的服务按照业务流程的需要进行编排，做到了“随需而变”。 数据存储区包括 ODS、数据仓库 /数据集市、共享数据库、特征库、模型库等，主要提供各种数据的存储服务。其中，逻辑视图中 ODS 部分存放了整个 XXX 单位全局级的明细数据，而数据仓库数据集市中存储了不同级别的汇总数14 / 23 据。特征库主要存放各种数据分群特征、业 务分类特征等业务信息，模型库存放构建的各种业务模型信息等。 基础服务层主要包括“应用服务器”，“服务总线”，“工作流引擎”，“消息中间件”，“ OLAP 引擎”，“数据挖掘引擎”，“事件驱动”，“规则引擎”，“协同工作”和“空间地理数据引擎”。 应用层包括各种应用，其中多维分析、即席查询、报表统计、图形展现等。 右边的信息治理层主要是为了保证数据的完整性、一致性、准确性、及时性，保证历史数据正确归档并在需要的时候可以和现有数据一起被联合访问，提供数据库安全、审计、监控和合规服务，从而防止 内部人员偷窃，防范欺诈作假，保护数据隐私，强制执行安全规范，强制满足合规的要求，防止外部攻击对数据的破坏。 而元数据管理会贯穿数据业务层面、业务系统、信息整合服务总线、 ETL 层、数据存储区、信息服务层、展现层等各个层面，当数据口径出现问题时，能够提供数据在各个层面的正向 /逆向追踪功能。元数据的管理涉及业务元数据和技术元数据两种。 3. 数据仓库架构 数据仓库总体架构 1) 多维分析 从数据的全方位了解现状，管理人员往往希望从不15 / 23 同的角度来审视业务数值， 比如从时间、地域、类别、功能来看同一类数据的总和。每一个分析的角度可以叫做一个维，因此，把多角度分析方式称为多维分析。以前，每一个分析的角度需要制作一张报表。由此产生了在线多维分析功能，根据用户常用的多种分析角度，事先计算好一些辅助结构，以便在查询时能尽快抽取到所要的记录，并快速地从一维转变到另一维，将不同角度的信息以数字、直方图、饼图、曲线等等方式展现在您面前。 2) 即席查询 可以将数据进行查询分组，进行资源的管理，可以设置查询优先级，可以自动控制，调度复杂查询和进行跟踪分析查询 。可以按照以下重要方法进行使用，主动和动态地控制 数据库的查询流程，为不同大小的查询定义不同的查询类别，从而改善查询之间的系统资源共享，避免较小的查询被较大的查询阻塞等。 综合医疗系统中的数据仓库解决方案 在医疗服务系统中建立数据仓库是一个不小的挑战。综合医疗系统的焦点正从糟糕的医疗配套问题转向立体交叉的医疗管理之中，在提高医疗服务质量的同时又要削减成本，这就需要在医疗程序中消除不必要的环节。本文介绍了在医疗项目业务开发过程中总结的经验，主题包括建立数据仓库需求，理解医疗系统中的数 据仓库，明确开发数据仓16 / 23 库的成本，建立开发小组，以及设计各阶段的任务目标。 1、 简介 建立数据仓库需求 确定核心业务问题 28 个主要业务经理参与了需求调查，主题是关于决策支持所需的高层信息。在此次调查过程中确立了几个关键性的领域，它们是业务实际利益、数据获取、企业文化、领导及无效的进程。 然而，调查小组很快察觉，将数据仓库认为是能解决上述所有领域的问题的灵丹妙药等于冒一个天大的风险。数据仓库仅对数据的获取与保持数据的连续性方面有本质的突破，而再出色的数据入口对改变 领导模式、企业文化或医疗基础都无济于事。 调查小组调查的问题集中如下： 1 列出 3 个你最需要作出的决策。 2 作出这些决策你需要哪些报表和工具？ 3 目前这些报表和工具的优缺点是什么？ 4 基于当前的信息，时间、质量或资金对作出一个好的 /坏的决策有何影响？ 5 什么样的信息 /计算 /聚合可能提高你制定决策的水平？ 6 你运用联机系统进行信息分析的可能性有多大？ 7 如果你借助于专门的数据查询，决策制定过程有何变化？ 8 为了充分利用信息优势，需要 改进哪些日常工作？ 9 获取新系统信息的最关键的益处在哪里？ 17 / 23 数据源清单和数据源分析 与对管理人员调研同时进行的是定义数据目录，数据目录用于确定哪些参选数据适合进入数据仓库。目录包括用于 IDS 之中的 312 个专用例程的内容及结构的详细信息。数据清单的主要目的是进行当前数据源与预期信息需求的对比。数据源清单和管理调研显示了如下主要问题： ? 在多个应用中使用同一个主题的数据 ? 一些应用包括空的数据结构 ? 系统没有集成，无法自动进行数据的更新、转移和载入，产生数据碎片和数据不一致 的现象 ? 多种多样的和不兼容的数据结构使相似的数据结合起来很困难，有时甚至不可能 ? 数据从一个系统中出出进进，与数据不一致的问题纠缠在一起 定义侯选主题领域 基于如下条例，可以开发并优化一组潜在主题领域： ? 期望利润 通过实施一个主题领域，在患者满意度、出诊收益和运营效率方面，健康系统 取得的定量的和定性的利润 ? 数据裂缝 实施一个主题领域所需数据与可支配数据之间的差异 ? 复杂程度 为一个特定的主题创建一个有效的设计方案所需的努力 ? 实施风险 当组织准备充分并具备运营能力，而且所需的系统界面齐全，时间安排得当， 18 / 23 广度和深度比例适当时，实施一个特定的主题领域会相对容易一些 选择主题领域 通常，一个具有最大潜在利润，同时风险因素又最少的主题是最好的选择。有时对业务的深思熟虑会让我们放弃一个显而易见的决策。另外，你必须时刻牢记在心的还有，如果不存在业务对数据的强烈的需求，那么数据的价值是零。 克里斯蒂安娜健康中心的高层管理者指定了一个指导委员会，这个委员会将担负起选择第一个主题领域的任务。为了确定最佳的选 择，他们列出了潜在主题领域的主要维度的清单，按照期望利润、数据裂缝、复杂程度和实施风险四个类别进行评分，最后计算总分。 基于这个分数卡，指导委员会对各个主题领域进行分析和定级。当得分最高的三个主题领域被进一步分析时，两个看起来较好的侯选主题领域没能经得起业务实例分析的考验，委员会发现，这两个主题领域存在着不可逾越的数据裂缝，而且组织对所需要进行的变革毫无准备。于是委员会将目标锁定在排位第三的主题领域上 医师行为报表，因为医师最终对医疗质量负责，并对医疗成本有巨大的影响作用，于是医师业务行为方式自然而然地 成为了一个逻辑控制点。见图 3。 按照一致赞同的规则，委员会进一步论证了将医师行为报表作为第一个主题领域的合理性。然而，这项决定并没有引起人们充满激情的或持久的支持。可见，要想成功，19 / 23 对这个初始决策的支持必须来自于最高层管理者。 图 3 选择业务出资人 在数据仓库项目中，业务出资人往往提议主题领域应基于一个核心的业务需求。通常，在我们这种医疗服务情况下，有许多组织对医疗主题怀有极大的热忱。医师队伍与患者医疗管理共同资助是可以接受的，因为这两家出资人在削减无谓的医疗行为方式以 获取最大的出诊收益方面目标是一致的。 3、理解医疗系统数据仓库 在 IDS单个业务单元中，基于操作型系统的决策支持应用已经存在了。管理者会理直气壮地问为什么现存的系统不够用呢，要回答这个问题，需要阐明与数据仓库相关的风险、收益和成本。首先，考虑我们面临的风险： ? 几乎没人理解操作型系统与决策支持系统的差别 ? 很难将数据集成带来的收益概念化和具体化 ? 由于静态报表已成为标准，我们的用户很难适应交互式的数据界面 ? 我们的努力很难在整个项目周期中都得到普遍的支持，这也是值得担心的 接着，我们考虑潜在的收益： ? 数据仓库将会提供毫无疑义的数据集成，确保在整个 IDS 中数据的真实性和一致性 ? 联机分析处理系统将20 / 23 通过一个生动并且易于使用的界面给高层管理者提供新奇的决 策支持透视服务 ? 运用数据分析预处理包能使业务分析专家迅速发现问题并很快建立解决方案 ? 对人群和供应商会有更深了解，利于提高医疗管理项目的效率 ? ? ? ? ? 常规报表不再需要借助于 IT部门的先进的技术服务 用户能够获得元数据，即关于数据的来源及数据转换方式的信息。 对数据质量的信心会增强 将会建立数据标准 新成立的医师组织能够发展基于信息的文化 这指引我们去分析最后一个因素 成本。数据仓库项目是昂贵的，保守一点说，数据仓库项目的启动少则 1百万美金，多则 5 百万美金。为了帮助你更好的理解，我们引入了一个样本项目预算，后来我们发现这个预算过于乐观了。见表 2。 表 2 既然清楚了在实施数据仓库项目过程中会涉及到惊人的风险和成本，就应该明白为什么有必要在一些基本方面对管理者进行培 训。 操作型系统与决策支持 虽然医疗服务经常与操作型系统打交道，但对于在21 / 23 整个企业范围内提供决策支持还是经验尚浅。一个错误的认识是，地区的联机操作系统已经能够提供企业范围的决策支持。下面几段将总结这两个概念之间的差别。 操作型系统的设计目的在于实现数据的快速存取，任务或小数据集的快速处理。规范的关系数据库在进行数据的插入、更新和删除操作时能确保数据的完整性，并能优化在多表间进行数据存储的机制。用于决策支持的统计分析需要平滑的数据以及满足查询的最低粒度级。操作型数据与用于决 策支持的统计数据的差别见表 3。 表 3 决策制定者借助于一些软件工具进行决策，这些软件工具可以划分为报表、数据挖掘 /统计和数据浏览几个类别。报表可以发展成为总结已被充分理解的业务进程和主题的工具。数据挖掘工具和数据浏览工