数据仓库 使用手册

数据仓库使用手册 -天善智能 QQ:744711023 天善智能微软BI培训正式起航，天善团队将于3月3日下午1点进行数据仓库讲解。3月3日下午1点不见不散！详情：/weiruan数据仓库使用手册 1 数据仓库构建1.1 BI分析基石，良好的数据仓库设计1.1.1 数据的两种形式:操作数据和分析数据企业中使用的数据可以分为两类：操作数据和分析数据。这两种数据都可以存储在DBMS中进行管理。他们的组织形式实际上源于并作用于两种系统：操作型系统和分析型系统。 企业的生产环境，也由以数据库为中心的环境发展为以数据仓库为中心的环境。操作型系统根据其特点也称为联机事务处理（OLTP）,存储操作数据，称为数据库。分析型系统也称联机分析处理（OLAP）,一般把存储分析数据的数据库称为数据仓库。 数据仓库是支持管理决策过程的、面向主题的、集成的、随时间变化的、持久的数据集合。 由于数据库系统和数据仓库系统在硬件利用率上的差异，我们难于在同一台服务器上既进行优化操作型处理，又进行优化分析型处理，因此数据库系统和数据仓库系统在物理上应当由不同的服务器来运行。 1.1.2 数据仓库设计方法论 传统的关系数据库一般采用二维数据表的形式来表示数据，以维是行，另一维是列，行和列的交叉处就是数据元素。关系数据的基础是关系数据库模型，通过标准的SQL语言来加以实现。 数据仓库是多维数据库，它扩展了关系数据库模型，以星型架构为主要结构方式的，并在它的基础上，扩展出理论雪花形架构和数据星座等方式，但是不管是哪一种架构，维度表、事实表和事实表中的度量都是必不可少的组成元素。 数据集市是在构建数据仓库的时候经常用到的一个词汇。如果说数据仓库是企业范围的，收集的是关于整个组织的主题，如顾客、商品、销售、资产和人员等方面的信息，那么数据集市则是包含企业范围数据的一个子集，例如之包含销售主题的信息，这样数据集市只对特定的用户是有用的，起范围限定于选定的主题。 宏观上的数据仓库设计分为以下三个大阶段：规划分析阶段、设计实施阶段、使用维护阶段。这三个阶段是循环运动过程。规划分析阶段包括：规划与确定需求、开发概念模型、开发逻辑模型；设计实施阶段包括：设计体系结构、数据库与元数据设计、数据抽取转换与加载、开发中间件、填充与测试数据仓库；使用维护阶段包括：数据仓库应用、数据仓库维护和数据仓库评价。1.1.3 二种创建数据仓库的模式创建数据仓库的方式，根据其出现的先后顺序，主要分为2种模式：自顶向下（TOP-down）,自底向上（Bottom-up）. 自顶向下（TOP-down）：这种模式首先把OLTP数据通过ETL汇集到数据仓库中，然后再把数据通过复制的方式推进各个数据集市中，其优点在于：1、数据来源固定，可以确保数据的完整性。2、数据格式与单位一致，可以确保跨越不同数据集市进行分析的正确性。3、数据集市可以保证有共享的字段。因为都是从数据仓库中分离出来的。自底向上（Bottom-up）：这种模式首先将OLTP数据通过ETL汇集到数据集市中，然后通过复制的方式提升到数据仓库中，其优点在于：1、由于首先构建数据集市的工作相对简单，所以容易成功。2、这种模式也是实现快速数据传送的原型。1.2 数据仓库介绍数据仓库是一项基于数据管理和运用的综合性技术和解决方案。数据仓库的成功实施对培育一种知识共享文化产生重大影响。目前，基于数据仓库的决策支持系统还主要应用于银行业和证券业。 随着全球性竞争的加剧，越来越多的企业认识到正确及时的决策是企业生存和发展的关键所在。因此，充分利用现代信息科技技术，自动快速获取有用的决策信息，为企业提供快速、准确的决策支持，已成为大多数成功企业的共识。数据仓库的出现，给企业带来更好的发展动力。“数据仓库”一词最早出现于20世纪90年代初，目前已趋于成熟。据IDC调查，数据仓库的平均投资回报率在401%。另据调查，幸福500中已经有85%的企业建成或正在建立数据仓库。数据仓库与Internet一样，正在成为最快的IT增长点。1.3 构建数据仓库的目的 1、市场的激烈竞争和管理过程的复杂性，决定了一个企业为了生存与发展，就需要对客户关系、市场营销、产品工程、投资分析等方面的历史数据进行提取与分析，从中找到对企业进一步发展有价值的潜在信息。 2、数据仓库能够把企业的内部数据和外部数据进行有效的集成，为企业的各层决策提供数据依据。3、企业现有的系统不能提供更多的决策信息（尽管企业已经有了大量的数据积累）。4、通过构造一种体系化的数据存贮环境，将分析决策所需的大量数据从传统的操作环境中分离出来，使分散的、不一致的操作数据转换成集成的、统一的信息。5、可以为市场营销和客户分析提供基本的信息源和辅助工具。6、可以实现对产品、部门、机构的利润与成本分析。7、可以规范管理流程、优化业务处理、提高资本利用率。1.4 数据仓库构建的步骤数据仓库的构架由三部分组成：数据源、数据源转换/装载形成新数据库、OLAP(联机分析处理 On-line Analytical Processing)。数据仓库的实施过程大体可分为三个阶段：数据仓库的项目规划、设计和实施、维护调整。从数据仓库的构架和实施过程出发，数据仓库的构建可以分为以下几个步骤：1、目标明确，统筹安排根据企业的发展目标和市场变化规律，用战略发展的眼光，创立一个信息架构方案，使公司的商业目标与所需要的数据保持一致。2、统一规划，分步实施建设和维护一个企业数据仓库，是一项费时费力、投资大的工程。所以应该先设计好一个整体信息架构，制定出分期实施计划，然后再逐步实施，重点放在高度重要的商业事件所需要的数据中心或数据传递机制上。3、构造技术环境、建立支撑平台建立技术环境,，选择实现数据仓库的软硬件资源，包括开发平台、DBMS、网络通信、开发工具、终端访问工具及建立服务水平目标（可用性、装载、维护及查询性能）的选择等。4、建好模型，选好工具通过数据模型的构建，企业可以从中得到完整而又清晰的描述信息，数据模型为企业多应用的数据源提供统一的标准。模型的设计需要企业的信息工作人员与业务工作人员紧密配合，规划出对企业有实际价值的应用模型，这个模型要具有一定的智能性，能够根据实际业务的发展不断调整自身的参数，最终找到企业运作过程中的规律，从而为企业带来效益。构建数据仓库的工具有很多，如建模工具、数据净化工具、数据抽取工具、数据仓库管理工具、联机分析处理和数据挖掘工具等。世界上较著名的大公司，如IBM、Oracle、Sybase、CA、NCR、Informix、Microsoft、和SAS等都竟相推出了构建、维护和应用数据仓库的产品工具和应用解决方案。企业可以从自身的实际情况和用户的需求角度进行考虑，加以选择。5、加强管理，搞好维护数据仓库的安全问题不容忽视，通过操作系统和数据库的安全机制，加强数据仓库操作权限的管理。对数据仓库中的相关数据要及时备份，并利用RAID配置备份数据仓库，以提高数据仓库的安全性和可用性。1.5 我国数据仓库出现的问题数据仓库技术之所以没有在中国很好的发展起来，主要原因如下：1、中国的信息化基础设备相对不太完善。2、企业的竞争意识和服务意识还不够强。3、数据仓库的价格居高不下。4、管理机制的缺乏。数据仓库是一个数据共享的系统，不同层面的人从中得到的信息会是不一样的。但目前中国企业没有建立起一个管理机制来推动数据的共享，不论是对人的能力、企业的组织制度还是数据质量都没有一个连续的管理机制，要在这样的基础之上建立好用的数据分析是非常困难的。5、技术人才缺乏。数据仓库的应用是一个建立的过程。在建立的过程当中，需要大量的技术支持人员。从国内情况来看，真正能够完整实施数据仓库方案的人才还很缺乏，因而制约了国内数据仓库市场的发展。6、数据挖掘工具本身不成熟。除了OLAP以外，更高层次的数据仓库是数据挖掘。然而，目前这一领域的技术还没有大的突破，市场上的数据挖掘技术还难以令人满意。7、数据积累不充分。实现在线分析处理的前提是要有大量的历史数据。但除了电信、证券、银行等少数行业以外，数据积累都不够充分。数据仓库是一项基于数据管理和运用的综合性技术和解决方案。数据仓库的成功实施对培育一种知识共享文化产生重大影响。目前，基于数据仓库的决策支持系统还主要应用于银行业和证券业。随着各种技术的成熟，数据仓库将会在金融、保险、铁路、航空、零售、食品、电信、邮政、医疗等行业中得到更加广泛的应用。2 数据仓库逻辑建模2.1 数据仓库模型特点对于传统的OLTP系统,我们总是按照应用来建立它的模型,换言之,OLTP系统是面向应用的。而数据仓库则一般按照主题 (Subject)来建模,它是面向主题的。何谓应用?何谓主题?让我们来看一个简单的例子。 在银行中,一般都有对私 (个人储蓄)、对公 (企业储蓄)、信用卡等多种业务系统,它们都是面向应用的,所支持的交易类型简单而且固定。由于实施的先后等原因,这些系统可能运行在不同的平台上,相互之间没有什么关系,各系统之间的数据存在冗余。比如每个系统中都会有客户的数据,当针对银行建立其数据仓库应用时,要把上述生产系统中的数据转换到数据仓库中来。从整个银行的角度来看,其数据模型不再面向个别应用,而是面向整个银行的主题,比如客户、产品、渠道等。因此,各个生产系统中与客户、产品、渠道等相关的信息将分别转换到数据仓库中相应的主题中,从而在整个银行的业务界面上提供一个一致的信息视图。2.2 数据仓库的建模方法逻辑建模是数据仓库实施中的重要一环,因为它能直接反映出业务部门的需求,同时对系统的物理实施有着重要的指导作用。目前较常用的两种建模方法是所谓的第三范式 (3NF,即 Third Normal Form)和星型模式 (Star-Schema),我们将重点讨论两种方法的特点和它们在数据仓库系统中的适用场合。 什么是第三范式 范式是数据库逻辑模型设计的基本理论,一个关系模型可以从第一范式到第五范式进行无损分解,这个过程也称为规范化 (Normalize)。在数据仓库的模型设计中目前一般采用第三范式,它有非常严格的数学定义。如果从其表达的含义来看,一个符合第三范式的关系必须具有以下三个条件: 1. 每个属性的值唯一,不具有多义性; 2. 每个非主属性必须完全依赖于整个主键,而非主键的一部分; 3. 每个非主属性不能依赖于其他关系中的属性,因为这样的话,这种属性应该归到其他关系中去。 我们可以看到,第三范式的定义基本上是围绕主键与非主属性之间的关系而作出的。如果只满足第一个条件,则称为第一范式;如果满足前面两个条件,则称为第二范式,依此类推。因此,各级范式是向下兼容的。 什么是星型模式 星型模式是一种多维的数据关系,它由一个事实表(Fact Table)和一组维表(Dimens ion Table)组成。每个维表都有一个维作为主键,所有这些维则组合成事实表的主键,换言之,事实表主键的每个元素都是维表的外键。事实表的非主属性称为事实 (Fact),它们一般都是数值或其他可以进行计算的数据;而维大都是文字、时间等类型的数据。 第三范式和星型模式在数据仓库中的应用 一个数据仓库的基本结构可以分成如图所示的四层: 也有一些企业由于这样那样的原因,没有建立全企业范围的数据仓库,而是建立基于部门应用的独立数据集市(有关数据集市与数据仓库的比较,请参阅本报今年第 27期上笔者编译自 Bill Inmon的文章)。 大多数人在设计中央数据仓库的逻辑模型时,都按照第三范式来设计;而在进行物理实施时,则由于数据库引擎的限制,不得不对逻辑模型进行不规范处理 (De-Normalize), 以提高系统的响应速度,这当然是以增加系统的复杂度、维护工作量、磁盘使用比率 (指原始数据与磁盘大小的比率)并降低系统执行动态查询能力为代价的。 根据数据仓库的测试标准 TPC-D规范,在数据仓库系统中,对数据库引擎最大的挑战主要是这样几种操作:多表连接、表的累计、数据排序、大量数据的扫描。下面列出了一些 DBMS在实际系统中针对这些困难所采用的折衷处理办法: 1、如何避免多表连接:在设计模型时对表进行合并,即所谓的预连接 (Pre-Join)。当数据规模小时,也可以采用星型模式, 这样能提高系统速度,但增加了数据冗余量。 2、如何避免表的累计:在模型中增加有关小计数据 (Summarized Data)的项。这样也增加了数据冗余,而且如果某项问题不在预建的累计项内,需临时调整。 3、如何避免数据排序:对数据事先排序。但随着数据仓库系统的运行,不断有新的数据加入,数据库管理员的工作将大大增加。大量的时间将用于对系统的整理,系统的可用性随之降低。 4、如何避免大表扫描:通过使用大量的索引,可以避免对大量数据进行扫描。但这也将增加系统的复杂程度,降低系统进行动态查询的能力。 这些措施大都属于不规范处理。根据上面的讨论,当把规范的系统逻辑模型进行物理实施时,由于数据库引擎的限制,常常需要进行不规范处理。举例来说,当系统数据量很小 ,比如只有几个 GB时,进行多表连接之类复杂查询的响应时间是可以忍受的。但是设想一下,如果数据量扩展到很大,到几百 GB,甚至上 TB,一个表中的记录往往有几百万、几千万,甚至更多,这时进行多表连接这样的复杂查询,响应时间长得不可忍受。这时就有必要把几个表合并,尽量减少表的连接操作。当然,不规范处理的程度取决于数据库引擎的并行处理能力。用户在选择数据库引擎时,除了参考一些相关的基准测试结果外,最好是能根据自己的实际情况设计测试方案,从几个数据库系统中选择最适合自己企业决策要求的一种。 不规范处理的阶段 现在来讨论一下,当不得不选择不规范处理时,应在哪个阶段进行。 由于中央数据仓库的数据模型反映了整个企业的业务运行规律,在这里进行不规范处理容易影响整个系统,不利于今后的扩展。 而且不规范处理产生的数据冗余将使整个系统的数据量迅速增加,这将增加 DBA的工作量和系统投资。因此,当系统性能下降而进行不规范处理时,比较好的办法是选择问题较集中的部门数据集市实施这种措施。这样既能有效地改善系统性能,又不至于影响整个系统。在国外一些成功的大型企业级数据仓库案例中,基本上都是采用这种方法。 那么,在中央数据仓库中是否可以采用星型模式来进行模型设计呢?我们知道,星型模式中有一个事实表和一组维表,我们可以把事实看成是各个维交叉点上的值。例如,一个汽车厂在研究其销售情况时可以考察汽车的型号、颜色、代理商等多种因素,这些因素就是维,而销售量就是事实。这种多维模型能迅速给出基于各个维的报表,这些维必须事先确定。 星型模式之所以速度快,在于针对各个维作了大量的预处理,如按照维进行预先的统计、分类、排序等。在上面的例子中,就是按照汽车的型号、颜色、代理商进行预先的销售量统计。因此,在星型模式设计的数据仓库中,作报表的速度虽然很快,但由于存在大量的预处理,其建模过程相对来说就比较慢。当业务问题发生变化,原来的维不能满足要求时,需要增加新的维。由于事实表的主键由所有维表的主键组成,这种维的变动将是非常复杂、非常耗时的。星型模式另一个显著的缺点是数据的冗余量很大。综合这些讨论,不难得出结论,星型模式比较适合于预先定义好的问题,如需要产生大量报表的场合;而不适合于动态查询多、系统可扩展能力要求高或者数据量很大的场合。因此,星型模式在一些要求大量报表的部门数据集市中有较多的应用。3 数据仓库建模技术3.1 数据仓库建模技术介绍数据仓库系统是一个与企业同步发展的有机体，数据模型作为数据仓库的灵魂必须提供可扩展的能力，在进行数据模型设计时必须考虑未来的发展，更多的非核心业务数据可以方便的加入到数据仓库，而不需要对数据仓库中原有的系统进行大规模的修改。3.2 数据仓库建模的原则 模型是对现实事物的反映和抽象，它可以帮助我们更加清晰的了解客观世界。数据仓库建模在业务需求分析之后开始，是数据仓库构造工作正式开始的第一步，正确而完备的数据模型是用户业务需求的体现，是数据仓库项目成功与否最重要的技术因素。金融企业的信息系统具有业务复杂、机构复杂、系统庞大的特点，因此金融行业数据仓库建模必须注意以下几个方面， 满足不同用户的需求金融行业的业务流程十分复杂，数据仓库系统涉及的业务用户众多，在进行数据模型设计的时候必须兼顾不同业务产品、不同业务部门、不同层次、不同级别用户的信息需求。数据仓库应该支持企业的各种业务，比如对财产保险行业应该考虑财产险、货物运输险、工程险、责任险等不同业务的特点；不同的业务部门对信息的需求各有不同，应考虑业务、市场、财务、管理等各个部门的需要；不同层次的组织所关心的信息不同，数据模型应支持地市公司、省公司和总公司的信息需求；金融企业是知识密集型的企业，知识密集型企业的显著特征是智能员工(Knowledge Worker)占企业员工的大多数，数据仓库必须支持所有相关智能型员工的信息需求，包括高层领导、基层领导和普通员工。 兼顾效率与数据粒度的需要数据粒度和查询效率从来都是矛盾的，细小的数据粒度可以保证信息访问的灵活性，但同时却降低了查询的效率并占用大量的存储空间，数据模型的设计必须在这矛盾的两者中取得平衡，优秀的数据模型设计既可以提供足够详细的数据支持又能够保证查询的效率。 支持需求的变化用户的信息需求随着市场的变化而变化，所以需求的变化只有在市场竞争停顿的时候才会停止，而且随着竞争的激化，需求变化会越来越频繁。数据模型的设计必须考虑如何适应和满足需求的变化。 避免对业务运营系统造成影响金融企业的数据仓库系统是一个每天都在长大的庞然大物，它的运行很容易占用很多的资源，比如网络资源、系统资源，在进行数据模型设计的时候也需要考虑如何减少对业务系统性能的影响。 考虑未来的可扩展性数据仓库系统是一个与企业同步发展的有机体，数据模型作为数据仓库的灵魂必须提供可扩展的能力，在进行数据模型设计时必须考虑未来的发展，更多的非核心业务数据如人事数据、市场数据、竞争对手数据等必须可以方便的加入到数据仓库，而不需要对数据仓库中原有的系统进行大规模的修改。3.3 数据模型的技术功能结构划分大规模的数据仓库系统特别是金融行业数据仓库的数据结构从技术角度划分应当包含三个部分，如下图所示， 数据仓库数据模型的技术功能划分2.1 分段存储区（Staging Area）由于数据仓库中的数据结构和组织方式具有很大差异、所有原始业务系统的数据必须经过严格的抽取、映射和转换，数据的整合过程十分复杂，通常会耗费比较长的处理时间。如果从业务系统直接抽取数据到数据仓库，必定会占用许多业务系统的资源和时间，为了避免影响业务系统的运行，我们在数据模型的设计中引入分段存储区的概念。分段存储区（Staging Area）是为了保证数据移动的顺利进行而开设的阶段性数据存储空间，它是业务系统原始数据进入数据仓库前的缓存区。需要进入数据仓库的各个业务系统的数据首先直接快速传输到分段存储区，再从分段存储区经过清洗、转换、映射等复杂的数据移动处理转移到目标数据仓库中。从业务系统到分段存储区的数据传输，应尽量避免进行复杂的数据处理，以保证数据的快速导入而尽量减小对业务系统造成的压力。分段存储区的数据有关系数据库和文件两种不同存储方式，分别对应于不同运营系统的数据源。数据成功导入数据仓库之后，应清空分段存储区中的数据。在数据仓库系统的运行和使用过程中，分段存储区的作用主要体现在以下几个方面， 可以减少对业务系统资源的占用，避免复杂数据转换对业务系统的影响 根据经验，跨越网络特别是广域网络的数据库操作会大大降低数据处理的效率，而且处理的复杂程度越高，网络对处理效率的影响越严重，分段存储区可以大大加速数据仓库后台数据数据处理过程的实现； 分段存储区作为数据缓存区，可以在一定程度上屏蔽业务系统变化对数据移动整合系统的影响 如果在数据处理过程中发生系统故障，作为数据仓库系统的备份数据，可以直接从分段存储区进行数据仓库数据恢复，而不必要再从业务系统原始数据开始。2.2 基础数据仓库（BaseLine）基础数据仓库存储所有最详细的业务数据。该层数据直接来源于对分段存储区数据的清洗和加工，属于未经汇总的数据，但数据的组织方式可能已经完全不同于原始的业务系统。根据业务需求的不同，基础数据仓库的组织形式以三范式模型为主，在有的系统中也可能采用星型或雪花模型。通常在金融企业的数据仓库系统中，基础数据仓库数据包括未经汇总的客户交易数据，用户资料数据、客户服务数据等，此外一些相关数据如网络利用，竞争对手，成本投资数据也包括在内。由于基础数据仓库数据是对原始业务数据的原形再现，所以数据量会非常庞大，根据不同业务的需要数据保留的时间在6个月到两年不等。2.3 数据集市（Data Mart）根据业务需求将数据仓库数据分类成几个不同的数据集市，每个数据集市完成不同的分析和查询需求，数据集市中的数据通常由基础数据仓库的详细数据聚合而来，根据数据聚合程度的不同包含轻度聚合、中度聚合和高度聚合三种不同的层次。汇总的方式将依据数据量的大小和使用频度综合考虑。3.4 概念模型数据模型设计的第一步是对用户需求的归纳，需要综合考虑业务划分和用户组织两方面的问题，在明确需求的基础上，可以进行逻辑数据模型的设计，大致需要经过分为三个步骤，高层模型设计即概念模型设计，确定数据仓库的主要主题及相互关系；中层模型设计明确各主题域的实体；底层模型设计明确各个实体的属性。本章以国内某财产保险公司的业务为例介绍财产保险行业的数据仓库建模。3.1 财产保险业务与公司组织机构下图是国内财产保险公司的主要组织机构，国内财产保险经营的主要保险业务如下， 机动车辆保险 家庭财产保险 企业财产保险 建筑安装工程保险 货物运输保险 船舶保险 航空航天保险 其它保险3.2 数据仓库概念模型目前保费收入还是国内财产保险企业的主要利润来源，在激烈的市场竞争中客户是竞争的焦点，在数据仓库中客户信息占有极为重要的地位；围绕着客户资料信息，客户的投保记录、索赔记录都具有极高的分析价值；另外合作伙伴对保险业务的开拓也具有重要地位，如保险代理人、经纪人等中介公司的相关信息。3.2.1 基础数据仓库基础数据仓库用以存储详细的业务数据，采取以客户信息为中心，各个业务环节数据为基础的中心-发散型结构，系统面向经营分析，以经营业务数据为主，如下图所示， 基础数据仓库概念模型介绍 客户资料负责存储用户的详细资料，主要的客户属性包括，客户ID、用户第一次投保时间、资料更新时间、业务类型、用户特征属性、用户类型、缴费情况、投保情况、信用情况、保费收入水平等等。客户资料主题的数据主要针对企业用户和大客户，在可能的情况下，尽量体现客户间的关系，比如某一家庭财险用户隶属于某一企业客户。客户资料数据体现最新的客户状态。客户资料永久在线保存，当客户资料发生变化时，旧的客户信息被转移到客户历史资料库中。在每一个客户的生命周期中，客户资料随时可能发生变化，客户历史资料数据详尽的记录每一次变化的细节，为以后客户信用评估和用户行为分析需求提供依据，客户历史资料永久在线保存。 客户投保记录以详细的保单数据为主，体现在某一时间段内客户的投保情况。由于数据量比较庞大，客户投保记录一般在数据仓库中在线保存两年，最长不超过五年。投保记录是业务分析最重要的数据基础，必要的时候，投保记录可以为很多业务提供数据支持，比如大客户管理等。 客户缴费记录记录用户投保后保费的缴纳情况，从中可以了解保险公司与每一个客户在不同业务的应收情况。是对业务发展的重要衡量依据，也是对客户群进行细分的重要指标。不同保险企业对缴费记录在线保存的时限要求不同，一般在一年以上，五年以下。 客户索赔记录客户索赔记录是过去客户每次索赔的详细记录，比如索赔金额、时间、保单号、立案号、险种、索赔清单、索赔单证、事故描述等，索赔记录是客户行为模式的重要组成，也是反欺诈分析、客户流失分析的重要依据。 客户赔付记录记录保险公司对每一个客户的每一笔赔付，主要的信息包括赔付时间、立案号、赔案号、单证、赔付计算情况、损失原因、赔付金额、是否通融赔付、通融赔付的原因和通融赔付金额等，与索赔记录相结合，可以了解保险公司对客户索赔的反应时间和处理速度 客户退保/退费记录了解用户退保和退费的情况，每一笔退保/退费的原因、时间、保单号、金额等等 中介信息描述中介公司的类型，比如经纪人、兼职代理人或专业代理人，各中介公司的业务量、保险公司之处的中介费用等等。 基础数据仓库概念模型的实现概念模型的意义在于体现用户的需求和基本的数据组织结构，在实际的设计过程中，可能需要根据实际的业务情况进行模型的拆分。比如客户资料模型，针对不同客户的情况拆分成企业客户、个人客户、集团个人客户；投保记录模型，根据不同的业务拆分成车险投保记录、财产险投保记录、运输险投保记录、船舶险投保记录等， 根据不同业务情况设计业务主题3.2.2 数据集市详细业务数据是数据仓库的基础，但对于金融企业来说，对业务发展宏观情况的把握是比详细的客户分析更为迫切的需求。所以在初期任何金融行业数据仓库的应用都以对聚合数据的分析为主。聚合数据存储在数据集市中，数据集市的数据直接通过查询工具提供给最终用户，所以数据集市的设计直接关系到数据仓库应用的成败。现阶段，我国大多数金融数据仓库系统正处于初始阶段，其主要功能需求是了解各省分公司、子公司和各项业务的发展和运营情况，因此数据集市的设计是数据模型设计最重要的环节。数据集市的数据结构可以按照数据粒度和数据所体现的业务范围划分。 按照数据粒度划分数据集市按照数据粒度的大小可以划分为三个部分，轻度汇总、中度汇总、高度汇总，汇总程度越高，数据粒度越大，数据在线保留时间越长，所体现的业务事实越宏观，如下图所示， 按照数据粒度划分的数据集市结构轻度汇总数据可以支持很多对客户个体的业务分析，比如从基础数据仓库投保记录汇总生成每个用户一段时间的投保情况；中度汇总数据在业务分析中经常被用到，大多数情况用于对宏观客户群体的业务分析，比如制定保费政策时，可以通过中度汇总数据了解不同险种不同时间的发展和收益情况；高度汇总数据用于了解保险公司业务整体的运营和发展情况。在实际的设计中，可以根据用户需求决定针对不同的业务采用不同的数据粒度。 按照业务划分按照业务进行数据集市结构的划分，可以把数据集市从总体上分为两个模块，综合业务分析模块和独立业务分析模块，如下图， 按照业务划分的数据集市结构 综合业务分析综合业务分析主要面向保险公司整体业务的分析，从综合业务分析可以了解保险公司的用户构成情况、中介发展情况、业务收入情况、赔付情况、共保/分保、客户服务、保费收入情况和竞争对手发展情况，从综合业务模块可以了解各个业务的总体发展情况，但由于各个业务属性的差异，详细的业务分析必须进入独立业务分析模块。 独立业务分析财产保险各业务、各险种的业务特点具有极大差异，对不同险种业务人员所关心的信息也不尽相同，所以各个业务在独立业务分析模块构成不同的分析主题；除此之外对有共性的业务进行综合构成综合的业务分析主题，比如个人大客户分析、企业客户业务分析就是把相关的业务主题进行综合的结果。3.5 发展与扩充数据仓库数据模型的设计在满足目前业务需求的基础上，必须考虑未来的业务情况和需求，需要认真考虑两方面的问题， 适应未来业务需求和技术环境的改变 数据仓库本身涉及业务范围的扩展4.1 适应未来的变化分段式数据仓库结构可以大大提升数据仓库适应变化的能力。在未来可能对数据仓库产生影响的变化无外乎两种， 业务需求的变化引致对信息需求的变化 技术环境的变化4.1.1 适应业务需求的变化用户需求的变化根据变化的程度和对数据仓库系统的影响被分为两个不同的层次， 可自适应的变化即信息的需求虽然有所变化，但利用已经存储在数据集市中的数据仍然可以支持，需要改变的只是数据访问和信息展现的方式，这不需要对数据仓库的数据结构进行修改就可以实现，在进行数据模型设计时，在保证查询效率的前提下，要尽量使各个业务主题可以满足最多的信息需求。 需要调整的变化即数据集市的数据虽然无法满足信息的需求，但可以从基础数据仓库中的数据获得，针对这样的变化有两种处理方法， 如果这个变化只是偶尔出现，可以直接从基础数据仓库的数据中进行数据的查询和分析，这样可能会牺牲一些性能，但不需对数据仓库的结构和数据模型进行修改 另一种方法是针对以后将频繁使用的新业务需求，可以采取修改现行数据集市和建立新的数据集市的方法实现，由于数据集市只是对基础数据仓库中相关的详细数据进行聚合，所以只需要很小的工作量就可以调整数据仓库实现新的需求。4.1.2 适应技术环境的变化技术环境的变化也是比较普遍出现的变化，比如业务系统的升级或迁移，可能对数据仓库的结构造成较大影响，分段存储区和基础数据仓库的使用，把这种风险降到最小。分段存储区是业务数据进入数据仓库之前的缓存区，复杂的数据转换、清洗工作在分段存储区进入基础数据仓库时实现。当业务系统的数据结构发生变化时，可以利用从业务系统到分段存储区的数据抽取操作把这些变化与数据清洗转换操作隔离即在对新的业务系统进行数据抽取操作时，进行适当的数据结构转换，使分段存储区中的数据与原来保持一致，避免对数据仓库的数据结构和主要的后台处理程序造成影响。从业务系统到分段存储区的数据抽取程序只需十分简单的修改就可以实现需要的功能。4.1.3 元数据管理的意义元数据管理系统可以大大提高数据仓库系统适应变化的能力。元数据记录数据仓库过程中设计的业务规则、数据结构、数据移动规则等，一旦上述某一点发生变化，可以通过元数据管理工具，进行影响分析，定位需要修改的目的。4 数据仓库的设计指南4.1 数据仓库设计指南在数据仓库的设计指导思想中，数据仓库的概念定义是非常重要的，数据仓库概念规定了数据仓库所具有的几个基本特性，这些特性也正是对数据仓库设计结果进行检验的重要依据。 在一般的数据仓库应用系统中，根据系统体系结构的不同，数据仓库设计的内容和范围不尽相同，并且设计方法也不尽相同，下面的两幅图示分别表示带有ODS的数据仓库应用系统体系结构和不带ODS的数据仓库应用系统体系结构。本文将说明两个体系结构上的差异以及这种差异造成的设计方法的不同，并且重点介绍带有ODS的体系结构中数据仓库的设计方法。 在数据仓库的设计指导思想中，数据仓库的概念定义是非常重要的，数据仓库概念规定了数据仓库所具有的几个基本特性，这些特性也正是对数据仓库设计结果进行检验的重要依据。根据Bill.Inmon的定义，“数据仓库是面向主题的、集成的、稳定的、随时间变化的，主要用于决策支持的数据库系统”。 ODS（Operational Data Store）是数据仓库体系结构中的一个可选部分，ODS具备数据仓库的部分特征和OLTP系统的部分特征，它是“面向主题的、集成的、当前或接近当前的、不断变化的”数据。 一般在带有ODS的系统体系结构中，ODS都设计为如下几个作用：1）在业务系统和数据仓库之间形成一个隔离层。一般的数据仓库应用系统都具有非常复杂的数据来源，这些数据存放在不同的地理位置、不同的数据库、不同的应用之中，从这些业务系统对数据进行抽取并不是一件容易的事。因此，ODS用于存放从业务系统直接抽取出来的数据，这些数据从数据结构、数据之间的逻辑关系上都与业务系统基本保持一致，因此在抽取过程中极大降低了数据转化的复杂性，而主要关注数据抽取的接口、数据量大小、抽取方式等方面的问题。2）转移一部分业务系统细节查询的功能在数据仓库建立之前，大量的报表、分析是由业务系统直接支持的，在一些比较复杂的报表生成过程中，对业务系统的运行产生相当大的压力。ODS的数据从粒度、组织方式等各个方面都保持了与业务系统的一致，那么原来由业务系统产生的报表、细节数据的查询自然能够从ODS中进行，从而降低业务系统的查询压力。3）完成数据仓库中不能完成的一些功能。一般来说，带有ODS的数据仓库体系结构中，DW层所存储的数据都是进行汇总过的数据，并不存储每笔交易产生的细节数据，但是在某些特殊的应用中，可能需要对交易细节数据进行查询，这时就需要把细节数据查询的功能转移到ODS来完成，而且ODS的数据模型按照面向主题的方式进行存储，可以方便地支持多维分析等查询功能。 在一个没有ODS层的数据仓库应用系统体系结构中，数据仓库中存储的数据粒度是根据需要而确定的，但一般来说，最为细节的业务数据也是需要保留的，实际上也就相当于ODS，但与ODS所不同的是，这时的细节数据不是“当前、不断变化的”数据，而是“历史的，不再变化的”数据。4.2 设计方法 在数据仓库设计方法和信息模型建模方法中，前人的著作对各种思路和方法都做过大量的研究和对比，重点集中在ER模型和维模型的比较和应用上。根据我们的实践经验，ER模型和维模型在数据仓库设计中并非绝对对立，尤其在ODS设计上，从宏观的角度来看数据之间的关系，以ER模型最为清晰，但从实现出来的数据结构上看，用维模型更加符合实际的需要。因此孤立地看ER模型或者维模型都缺乏科学客观的精神，需要从具体应用上去考虑如何应用不同的设计方法，但目标是一定的，就是要能够把企业的数据从宏观到微观能够清晰表达，并且能够实现出来。 本文中重点介绍维模型的应用。ODS设计指南 在ODS的概念定义中，已经描述了ODS的功能和特点，实际上ODS设计的目标就是以这些特点作为依据的。ODS设计与DW设计在着眼点上有所不同，ODS重点考虑业务系统数据是什么样子的，关系如何，在业务流程处理的哪个环节，以及数据抽取接口等问题。第零步：数据调研 有关数据调研的内容和要求，在调研规范文档中做了详细定义，此处不再重复。 第一步：确定数据范围 确定数据范围实际上是对ODS进行主题划分的过程，这种划分是基于对业务系统的调研的基础上而进行的，并不十分关心整个数据仓库系统上端应用需求，但是需要把上端应用需求与ODS数据范围进行验证，以确保应用所需的数据都已经从业务系统中抽取出来，并且得到了很好的组织。一般来讲，主题的划分是以业务系统的信息模型为依据的，设计者需要综合各种业务系统的信息模型，并进行宏观的归并，得到企业范围内的高层数据视图，并加以抽象，划定几个逻辑的数据主题范围。在这个阶段，以ER模型表示数据主题关系最为恰当。 第二步：根据数据范围进行进一步的数据分析和主题定义 在第一步中定义出来了企业范围内的高层数据视图，以及所收集到的各种业务系统的资料，在这一步中，需要对大的数据主题进行分解，并进行主题定义，直到每个主题能够直接对应一个主题数据模型为止。在这个阶段，将把第一步生成的每个ER图中的实体进行分解，分解的结果仍以ER表示为佳。 第三步：定义主题元素 定义维、度量、主题、粒度、存储期限 定义维的概念特性： 维名称，名称应该能够清晰表示出这个维的业务含义。 维成员，也就是这个维所代表的具体的数据， 维层次，维成员之间的隶属与包含的层次关系，每个层次需要定义名称 定义度量的概念特性： 度量名称，名称应该能够清晰标书这个度量的业务含义 定义主题的概念特性： 主题名称和含义，说明该主题主要包含哪些数据，用于什么分析；主题所包含的维和度量； 主题的事实表，以及事实表的数据。 定义粒度： 主题中事实表的数据粒度说明，这种粒度可以通过对维的层次限制加以说明，也可以通过对事实表数据的业务细节程度进行说明。 定义存储期限： 主题中事实表中的数据存储周期。 第四步：迭代，归并维、度量的定义 在ODS中，因数据来自于多个系统，数据主题划分时虽然对数据概念进行了一定程度上的归并，但具体的业务代码所形成的各个维、以及维成员等还需要进一步进行归并，把概念统一的维定义成一个维，不允许同一个维存在不同的实体表示（象不同的业务系统中一样）。 第五步：物理实现 定义每个主题的数据抽取周期、抽取时间、抽取方式、数据接口，抽取流程和规则。 物理设计不仅仅是ODS部分的数据库物理实现，设计数据库参数、操作系统参数、数据存储设计之外，有关数据抽取接口等问题必须清晰定义。DW设计指南 尽管我们看到过很多关于“不考虑应用，先建立数据平台”的说法，但建立一个“万能的”东西是不可能的，所以数据仓库的设计必须参照应用范围、应用类型，例如要考虑到系统用于报表、OLAP、数据挖掘的哪些模型等等，不同的应用对数据仓库的设计有不同的要求。 数据仓库是面向主题的、集成的、稳定的、随时间变化的数据，数据仓库的这几个特征的含义在这里不具体多介绍，但本人要说明如何实现这些特性。1、数据粒度和数据组织在数据仓库的每个主题，都必须知道这个主题所限定的维的层次、事实数据的粒度；事实数据存储的期限，“过期”的数据的处理方法。2、维和度量的唯一性和公用性千万不要在不同的主题中定义多个表示同一内容的维，尤其对于业务代码类型的维，如果一个业务代码形成了多个维表，那么在元数据维护过程中将困难重重。在整个系统范围内，要不断检视维定义是否唯一，如果有可能，一个维表要尽量被多个主题引用。3、数据粒度一旦变粗，就要考虑多个主题的融合汇总在数据仓库中，我们出于数据组织的规则、业务的要求、性能的要求，都可能对一个主题的事实数据进行汇总，形成粒度较粗的事实数据，但这时候我们往往忘记了粒度变粗的事实数据为最终的用户提供了更宏观的数据视图，这种宏观的数据视图当然需要进行跨主题的数据融合才能更加具有应用的价值。4、不论如何归并，需要保持数据之间的联系在数据仓库中，不同主题的数据之间的物理约束或许不再存在，但无论这些数据如何变化，要知道必须有一些“键”在逻辑上保持着不同数据之间的联系，这样就可以保证有联系的主题数据之间可以进行汇总以支持未知的应用，否则数据仓库的数据是一潭死水，不可能灵活支持各种应用的。 数据仓库设计可以自底向上地进行，也就是说从汇总ODS数据入手，逐渐过渡到应用主题上面去（也就是说，ODS里面的数据主题域与DW中的分析主题完全不是一回事）。我们仍然按部就班地逐项设计，这样并不是完全限定设计思路和步骤，但可以有效地提醒设计者有哪些事情要做。 第一步：对ODS中的各个主题的事实数据进行时间上的汇总 ODS的事实数据是纯细节的交易数据，进入ODS的第一步就是要按照时间维进行汇总，以实现初步的信息沉淀。这种汇总不是只进行一次，而是要制定下来汇总的级别，比如日汇总信息保留3个月，月汇总信息保留2年，年汇总信息长期保存（当然在时间粒度变粗的同时一般都伴随着其他维粒度的变粗或者舍弃），我们最终一定要定义到何种程度的数据可以在数据仓库中永久保存为止的地步。 第二步：按照业务逻辑的规则，对数据进行归并把ODS中不同主题中的表示相同业务的数据（来自不同的业务系统）进行归并，例如一般企业的客服系统（Call Center）都受理一部分业务，而这些业务受理与在营业厅或销售店的受理是一样的，因此这类数据要归并到一起。 第三步：把包含细节过多的交易记录进行拆分 事实上，一个交易记录所包含的信息内容非常丰富，往往超越了某个人或部门的分析需求，但不同的人有不同的关注点，因此为提高性能起见，我们需要把一个长记录包含的信息进行分析、分解、汇总。例如在电信企业中，经过二次批价后的通话详单包含多种信息，经过分析，它包括网络信息、业务类型信息、时间信息、地理信息、费用信息这样几个类别的信息，而每一类信息都由几个字段来进行记录。这些不同类别的信息是很少有人都同时关心的，一般来说网管部门关心网络信息，市场部门关心业务类型信息，而时间信息和地理信息恰是所有部门都需要的。按照这样的情况，我们把一条话单按照信息内容进行拆分，拆分后进行汇总归并，以支持不同部门的分析要求。当然，对于数据挖掘应用，可能同时关心所有的信息以发掘不同信息之间的关系，但这种情况一则很少，二则真正的数据挖掘更多的时候依赖于交易细节数据，也就是说，对于专题问题的研究可以从ODS中进行数据的再次处理。 第四步：汇总、再汇总 汇总的问题决不仅仅是为了提高性能而做的事情（当然汇总能够有效提高性能），但汇总同时意味着更高程度的综合，在这个过程中，我们会发现与ODS系统设计过程相反，我们从细节走向了宏观，在ODS中我们初步确定了企业信息模型，对企业信息模型进行初步分解，再分解、再分解，得到了一个个的主题；在数据仓库中，我们从一