数据仓库设计编码规范3.0.
数据仓库模型的设计
2.5数据仓库模型的设计 数据仓库模型的设计大体上可以分为以下三个层面的设计151: .概念模型设计; .逻辑模型设计; .物理模型设计; 下面就从这三个层面分别介绍数据仓库模型的设计。 2.5.1概念模型设计 进行概念模型设计所要完成的工作是: <1>界定系统边界 <2>确定主要的主题域及其内容 概念模型设计的成果是，在原有的数据库的基础上建立了一个较为稳固的概念模型。因为数据仓库是对原有数据库系统中的数据进行集成和重组而形成的数据集合，所以数据仓库的概念模型设计，首先要对原有数据库系统加以分析理解，看在原有的数据库系统中“有什么”、“怎样组织的”和“如何分布的”等，然后再来考虑应当如何建立数据仓库系统的概念模型。一方面，通过原有的数据库的设计文档以及在数据字典中的数据库关系模式，可以对企业现有的数据库中的内容有一个完整而清晰的认识;另一方面，数据仓库的概念模型是面向企业全局建立的，它为集成来自各个面向应用的数据库的数据提供了统一的概念视图。 概念模型的设计是在较高的抽象层次上的设计，因此建立概念模型时不用考虑具体技术条件的限制。 1.界定系统的边界 数据仓库是面向决策分析的数据库，我们无法在数据仓库设计的最初就得到详细而明确的需求，但是一些基本的方向性的需求还是摆在了设计人员的面前: . 要做的决策类型有哪些? . 决策者感兴趣的是什么问题? . 这些问题需要什么样的信息? . 要得到这些信息需要包含原有数据库系统的哪些部分的数据? 这样，我们可以划定一个当前的大致的系统边界，集中精力进行最需要的部分的开发。因而，从某种意义上讲，界定系统边界的工作也可以看作是数据仓库系统设计的需求分析，因为它将决策者的数据分析的需求用系统边界的定义形式反映出来。 2，确定主要的主题域 在这一步中，要确定系统所包含的主题域，然后对每个主题域的内
数据仓库设计指南
数据仓库设计指南 在一般的数据仓库应用系统中，根据系统体系结构的不同，数据仓库设计的内容和范围不尽相同，并且设计方法也不尽相同，下面的两幅图示分别表示带有ODS的数据仓库应用系统体系结构和不带ODS的数据仓库应用系统体系结构。本文将说明两个体系结构上的差异以及这种差异造成的设计方法的不同，并且重点介绍带有ODS的体系结构中数据仓库的设计方法。GV1 =p}` 在数据仓库的设计指导思想中，数据仓库的概念定义是非常重要的，数据仓库概念规定了数据仓库所具有的几个基本特性，这些特性也正是对数据仓库设计结果进行检验的重要依据。M)_m= }d 根据Bill.Inmon的定义，“数据仓库是面向主题的、集成的、稳定的、随时间变化的，主要用于决策支持的数据库系统”。_R)tJ Ro ODS（Operational Data Store）是数据仓库体系结构中的一个可选部分，ODS具备数据仓库的部分特征和OLTP系统的部分特征，它是“面向主题的、集成的、当前或接近当前的、不断变化的”数据。4\&P~kI 一般在带有ODS的系统体系结构中，ODS都设计为如下几个作用：#:1< R\H6m 1）在业务系统和数据仓库之间形成一个隔离层。[t"C/;S! 一般的数据仓库应用系统都具有非常复杂的数据来源，这些数据存放在不同的地理位置、不同的数据库、不同的应用之中，从这些业务系统对数据进行抽取并不是一件容易的事。因此，ODS用于存放从业务系统直接抽取出来的数据，这些数据从数据结构、数据之间的逻辑关系上都与业务系统基本保持一致，因此在抽取过程中极大降低了数据转化的复杂性，而主要关注数据抽取的接口、数据量大小、抽取方式等方面的问题。,8mPV{U KU 2）转移一部分业务系统细节查询的功能 Cr 标准规范体系建设方案设计 1.1需求分析 1.1.1采购范围与基本要求 收集智慧园区建设涉及的国家标准、行业标准、管理规范、技术标准和信息标准，编写XX高新区开发区智慧园区的接口规范、信息交换标准、元数据标准等。1.1.2建设内容要求 (1)编写 《XX高新区开发区智慧园区元数据信息标准》 《XX高新区开发区智慧园区数据代码规范目录》 《XX高新区开发区智慧园区数据交换方式》 《XX高新区开发区智慧园区数据交换内容标准》 《XX高新区开发区智慧园区数据接口标准》 《XX高新区开发区智慧园区数据采集规范》 《XX高新区开发区智慧园区数据处理规范》 《XX高新区开发区智慧园区数据质量规范》 《XX高新区开发区智慧园区数据管理制度》 《XX高新区开发区智慧园区系统运维管理规范》 《XX高新区开发区智慧园区文档管理制度》 《XX高新区开发区智慧园区运营管理标准》 (2)收集 （住建部智慧城市文件(2013年4月) 《智慧城市公共信息平台建设指南(试行)》 《智慧城市评价模型及基础评价指标体系》（全国通信标准化技术委员会） 《基于云计算的电子政务公共平台顶层设计指南》（工信部，2013年4月） 《政务信息资源目录体系》（GB/T21063-2007） 《政务信息资源交换体系》（GB/T21062-2007） 《信息技术大数据术语》（20141191-T-469） 《信息技术大数据参考架构》（20141191-T-469） 《关系数据管理系统技术要求》（GB/T28821-1012） 《城市基础地理信息系统技术规范》 《关于促进智慧城市健康发展的指导意见》 《关于积极推进“互联网+”行动的指导意见》 《促进大数据发展行动纲要》 《国家信息化发展战略纲要》 《国家电子政务工程建设项目管理暂行办法》 《国家信息化领导小组关于我国电子政务建设指导意见》 《国家电子政务总体框架》 《城市地下管线工程档案管理办法》（住建部2005年） 《城市地下空间开法利用管理规定》（建设部59号、第108号） 《电信建设管理办法》（国发委第20号） 《2006—2020年国家信息化发展战略》 1.2设计方案 XX高新区智慧园区是一个大规模的建设工程。该工程以业务系统的相关数据为业务处理核心，以其它相关部门为信息交换对象，实现跨机构的大型综合与分布式的信息化系统。 面对这样一个大型的信息系统，XX高新区智慧园区建设首先必须建立完善的标准体系和相关制度。保障XX高新区智慧园区生态XX高新区智慧园区建设标准的可持续发展能力，实现真正意义上的互联互通。 1.2.1标准在系统建设中的作用 XX高新区智慧园区建设与标准规范建设是相辅相成的。一方面，生态XX高新区智慧园区各项内容的建设必须遵循标准和规范，其设计、开发和实施等需要标准和规范进行指导；另一方面，标准和规范的制订和维护离不开生态XX高新区智慧园区的建设实践，标准和规范必需符合实际需求，随着生态XX高新区智慧园区建设的不断建设和推广，标准和规范也要根据生态XX高新区智慧园区建设的进展不断完善。 没有规矩不成方圆，生态XX高新区智慧园区及其配套体系的建设需要相应的标准和规范进行指导。标准和规范具有以下指导作用： 数据库与数据仓库的区别是什么 简而言之，数据库是面向事务的设计，数据仓库是面向主题设计的。 数据库一般存储在线交易数据，数据仓库存储的一般是历史数据。 数据库设计是尽量避免冗余，一般采用符合范式的规则来设计，数据仓库在设计是有意引入冗余，采用反范式的方式来设计。 数据库是为捕获数据而设计，数据仓库是为分析数据而设计，它的两个基本的元素是维表和事实表。维是看问题的角度，比如时间，部门，维表放的就是这些东西的定义，事实表里放着要查询的数据，同时有维的ID。 单从概念上讲，有些晦涩。任何技术都是为应用服务的，结合应用可以很容易地理解。以银行业务为例。数据库是事务系统的数据平台，客户在银行做的每笔交易都会写入数据库，被记录下来，这里，可以简单地理解为用数据库记帐。数据仓库是分析系统的数据平台，它从事务系统获取数据，并做汇总、加工，为决策者提供决策的依据。比如，某银行某分行一个月发生多少交易，该分行当前存款余额是多少。如果存款又多，消费交易又多，那么该地区就有必要设立ATM了。 显然，银行的交易量是巨大的，通常以百万甚至千万次来计算。事务系统是实时的，这就要求时效性，客户存一笔钱需要几十秒是无法忍受的，这就要求数据库只能存储很短一段时间的数据。而分析系统是事后的，它要提供关注时间段内所有的有效数据。这些数据是海量的，汇总计算起来也要慢一些，但是，只要能够提供有效的分析数据就达到目的了。 数据仓库，是在数据库已经大量存在的情况下，为了进一步挖掘数据资源、为了决策需要而产生的，它决不是所谓的“大型数据库”。那么，数据仓库与传统数据库比较，有哪些不同呢?让我们先看看W.H.Inmon关于数据仓库的定义:面向主题的、集成的、与时间相关且不可修改的数据集合。 “面向主题的”:传统数据库主要是为应用程序进行数据处理，未必按照同一主题存储数据;数据仓库侧重于数据分析工作，是按照主题存储的。这一点，类似于传统农贸市场与超市的区别—市场里面，白菜、萝卜、香菜会在一个摊位上，如果它们是一个小贩卖的;而超市里，白菜、萝卜、香菜则各自一块。也就是说，市场里的菜(数据)是按照小贩(应用程序)归堆(存储)的，超市里面则是按照菜的类型(同主题)归堆的。 “与时间相关”:数据库保存信息的时候，并不强调一定有时间信息。数据仓库则不同，出于决策的需要，数据仓库中的数据都要标明时间属性。决策中，时间属性很重要。同样都是累计购买过九车产品的顾客，一位是最近三个月购买九车，一位是最近一年从未买过，这对于决策者意义是不同的。 “不可修改”:数据仓库中的数据并不是最新的，而是来源于其它数据源。数据仓库反映的是历史信息，并不是很多数据库处理的那种日常事务数据(有的数据库例如电信计费数据库 归一大数据平台 数据仓库 系统设计说明书受控不受控 修改变更记录： 目录 1引言 (5) 1.1文档编制目的 (5) 1.2背景 (6) 1.3词汇表 (6) 1.4参考资料 (6) 2总体设计 (7) 2.1软件体系结构 (7) 2.2系统运行体系......................................................................... 错误！未定义书签。 2.2.1运行体系图..................................................................... 错误！未定义书签。 2.2.2程序/模块对应表............................................................ 错误！未定义书签。 2.3系统物理结构 (7) 2.4技术路线 (8) 3系统接口设计 (8) 3.1用户接口 (8) 4子系统/模块设计 (8) 4.1数据仓库 (8) 4.1.1ODL(操作数据)层设计 (8) 4.1.2BDL(数据仓库)层设计 (10) 4.1.3IDL(宽表)层设计 (11) 4.1.4PDL(应用)层设计 (12) 4.1.5PUB(维度)层设计 (15) 4.1.6数据导出设计 (16) 5数据结构与数据库设计 (17) 6外部存储结构设计 (17) 7故障处理说明 (17) 8尚需解决的问题 (18) 编写指南： 本模板力图给出系统设计阶段可能包括的基本信息，重点在于和需求分析文档相联系。描述系统整体情况。如果某个章节在项目或当前阶段中无法描述，则可保留其标题，注明“不 第1章数据仓库建设 1.1数据仓库总体架构 专家系统接收增购项目车辆TCMS或其他子系统通过车地通信传输的实时或离线数据，经过一系列综合诊断分析，以各种报表图形或信息推送的形式向用户展示分析结果。针对诊断出的车辆故障将给出专家建议处理措施，为车辆的故障根因修复提供必要的支持。 根据专家系统数据仓库建设目标，结合系统数据业务规范，包括数据采集频率、数据采集量等相关因素，设计专家系统数据仓库架构如下： 数据仓库架构从层次结构上分为数据采集、数据存、数据分析、数据服务等几个方面的内容： 数据采集：负责从各业务自系统中汇集信息数据，系统支撑Kafka、Storm、Flume 及传统的ETL采集工具。 数据存储：本系统提供Hdfs、Hbase及RDBMS相结合的存储模式，支持海量数据的分布式存储。 数据分析：数据仓库体系支持传统的OLAP分析及基于Spark常规机器学习算法。 数据服务总线：数据系统提供数据服务总线服务，实现对数据资源的统一管理和调度，并对外提供数据服务。 1.2数据采集 专家系统数据仓库数据采集包括两个部分内容：外部数据汇集、内部各层数据的提取与加载。外部数据汇集是指从TCMS、车载子系统等外部信息系统汇集数据到专家数据仓库的操作型存储层（ODS）；内部各层数据的提取与加载是指数据仓库各存储层间的数据提取、转换与加载。 1.2.1外部数据汇集 专家数据仓库数据源包括列车监控与检测系统（TCMS）、车载子系统等相关子系统，数据采集的内容分为实时数据采集和定时数据采集两大类，实时数据采集主要对于各项检测指标数据；非实时采集包括日检修数据等。 根据项目信息汇集要求，列车指标信息采集具有采集数据量大，采集频率高的特点，考虑到系统后期的扩展，因此在数据数据采集方面，要求采集体系支持高吞吐量、高频率、海量数据采集，同时系统应该灵活可配置，可根据业务的需要进行灵活配置横向扩展。 本方案在数据采集架构采用Flume+Kafka+Storm的组合架构，采用Flume和ETL 工具作为Kafka的Producer，采用Storm作为Kafka的Consumer，Storm可实现对海量数据的实时处理，及时对问题指标进行预警。具体采集系统技术结构图如下: 现代电信企业数据仓库系统建设 电信企业数据仓库建设的需求 电信行业目前主要的数据来自于计费系统和网管数据。电信系统经过多年的运行，已经存储了大量的历史数据。这些数据中蕴涵着丰富的信息，从中可以了解企业在电信市场经营过程中所处的态势、竞争对手的经营形势、客户群的分布状况、消费特征、企业经营发展的趋势等，对其进行分析处理可以得到很多令人欣喜的结论。强大的数据处理能力，加上丰富的企业数据，可以有力地促进企业经营和竞争。 目前，企业信息化建设呈现出“数据集中化、业务综合化、管理扁平化、决策科学化”的发展趋势。面对激烈的市场竞争，许多大型企业纷纷实施“以客户为中心，以服务求发展”的经营策略。如何优化客户关系，增强企业的竞争优势已经成为现代企业关注的焦点。现有的应用系统往往以“产品”为中心，以“单据（票证）”处理为基础，是面向联机事务处理（Online Transaction Processing，简称OLTP）的系统，而以客户为中心的经营管理模式要求对现有业务系统的数据进行有效的集成并加以重组，建立面向联机分析处理（Online Analysis Processing，简称OLAP）的系统。通过分析客户的行为，掌握不同类型客户的特征，进而为客户提供更加优质的服务，尤其是个性化的服务，同时全面掌握并理解、分析企业业务的发生情况，充分发挥企业现已积累的数据，为各级管理人员提供科学化管理和决策的有力依据，以提高企业的经营业绩，保证利润的持续增长。 面对纷繁复杂的市场竞争，众多企业立足于多年积累的数据和自身的核心业务，提出了建立企业级数据仓库的规划和实施方案，为企业的进一步发展奠定基础。 企业数据仓库系统的总体结构 一个典型的企业数据仓库系统通常包含数据源、数据存储与管理、OLAP服务器以及前端工具与应用四个部分 从系统结构看，电信行业数据仓库解决方案系统一般包括应用系统部分、中央数据仓库系统部分，数据源系统部分三大部分。如图所示： 高效实现数据仓库的七个步骤 数据仓库和我们常见的RDBMS系统有些亲缘关系，但它又有所不同。如果你没有实施过数据仓库，那么从设定目标到给出设计，从创建数据结构到编写数据分析程序，再到面对挑剔的用户的评估，整个过程都会带给你一种与以往的项目完全不同的体验。一句话，如果你试图以旧有的方式创建数据仓库，那你所面对的不是预算超支就是所建立的数据仓库无法良好运作。 在处理一个数据仓库项目时需要注意的问题很多，但同时也有很多有建设性的参考可以帮助你更顺利的完成任务。开放思维，不断尝试新的途径，对于找到一种可行的数据仓库实现方法来说也是必需的。 1. 配备一个全职的项目经理或你自己全面负责项目管理 在通常情况下，项目经理都会同时负责多个项目的实施。这么做完全是出于资金和IT资源方面的考虑。但是对于数据仓库项目的管理，绝对不能出现一人身兼数个项目的情况。由于你所处的领域是你和你的团队之前没有进入过的领域，有关数据仓库的一切－数据分析、设计、编程、测试、修改、维护－全都是崭新的，因此你或者你指派的项目经理如果能全心投入，对于项目的成功会有很大帮助。 2. 将项目管理职责推给别的项目经理 由于数据仓库实现过程实在是太困难了，为了避免自虐，你可以在当前阶段的项目完成后就将项目管理职责推给别的项目经理。当然，这个新的项目经理一定要复合第一条所说的具有全职性。为什么要这么做呢？首先，从项目经理的角度看，数据仓库实施过程的任何一个阶段都足以让人身心疲惫。从物理存储设备的开发到Extract-Transform-Load的实现，从设计开发模型到OLAP，所有阶段都明显的比以前接触的项目更加困难。每个阶段不但需要新的处理方法、新的管理方法，还需要创新性的观点。所以将管理职责推给别的项目经理不但不会对项目有损害，还可以起到帮助作用。 3.与用户进行沟通 这里所讲的内容远比一篇文章本身要重要的多。你必须明白，在数据仓库的设计阶段，那些潜在用户自己也不清楚他们到底需要数据仓库为他们做什么。他们在不断的探索和发现自己的需求，而你的开发团队也在和客户的接触中做着同样的事情。更加频繁的与客户接触，多做记录， 未经允许，不可全部或部分发表、复制、使用于任何目的 文档修订摘要 1引言 编写目的 编写《数据仓库开发规范（dbsql系统）（1.0）》的目的是： dbsql封装了访问db2,oracle,greenplum,Sybase 和Teradata数据库的方法，形成了一套访问db2,oracle,greenplum,sybase和Teradata数据库的统一接口。dbsql不仅提供了对db2,oracle,greenplum,sybase和Teradata访问方法的统一，而且提供了一些方法屏蔽5个数据库之间sql语言的差别。这样对于应用程序，只需要编写一套代码，就可以操纵db2,oraclee,greenplum,sybase和Teradata数据库,对开发工程师而言，只用熟悉sql92的标准sql和此文档sql函数就 本文档供以下相关人员阅览： ◆参于数据仓库设计评审的专家人员； ◆参与数据仓库软件开发的软件部人员； ◆参与数据分析系统测试人员。 1.1 背景介绍 ◆开发的软件系统的名称：数据仓库编程规范 ◆开发单位：数据分析部 ◆系统使用单位： ◆该软件系统是数据仓库底层开发跨平台异构数据仓库的基础平台 1.2 术语定义 1.3 参考资料 参考资料共包括： ◆《Tcl/Tk 编程权威指南》 ◆《Expert One on One: Oracle》 ◆《Oracle 数据库DBA专题技术精粹》 2DBsql环境配置 2.1 目录设置 2.2 环境变量 主要环境变量设置包括： $DBSQL：程序安装点，开发时设置为个人目录。 $AGENTLOGDIR：Scehdule Server日志采集目录，通常设置为$DBSQL/log $AGENTTRACEDIR：日志及TRACE文件目录。（Schedule Server不采集，可用于存放调试信息） $TOOLS：存放tcl运行环境包及异构数据库编译的动态包安装目录。 用户可以在用户目录下创建.profile文件，例如： 数据仓库之路 FAQ FAQ目录 一、与数据仓库有关的几个概念 (3) 1.1 目录 (3) 二、数据仓库产生的原因 (8) 三、数据仓库体系结构图 (11) 四、数据仓库设计 (12) 4.1 数据仓库的建模 (12) 4.2 数据仓库建模的十条戒律： (13) 五、数据仓库开发过程 (14) 5.1 数据模型的内容 (14) 5.2 数据模型转变到数据仓库 (14) 5.3 数据仓库开发成功的关键 (15) 六、数据仓库的数据采集 (16) 6.1 后台处理 (17) 6.2 中间处理 (17) 6.3 前台处理 (18) 6.4 数据仓库的技术体系结构 (18) 6.5 数据的有效性检查 (20) 6.6 清除和转换数据 (20) 6.7 简单变换 (22) 6.8 清洁和刷洗 (24) 6.9 集成 (25) 6.10 聚集和概括 (27) 6.11 移动数据 (27) 七、如何建立数据仓库 (30) 7.1 数据仓库设计 (31) 7.2 数据抽取模块 (32) 7.3 数据维护模块 (33) 一、与数据仓库有关的几个概念 1.1 目录 ?Datawarehouse ?Datamart ?OLAP ?ROLAP ?MOLAP ?ClientOLAP ?DSS ?ETL ?Adhocquery ?EIS ?BPR ?BI ?Datamining ?CRM ?MetaData Data warehouse 本世纪80年代中期，“数据仓库之父”William H.Inmon先生在其《建立数据仓库》一书中定义了数据仓库的概念，随后又给出了更为精确的定义：数据仓 数据仓库的数据标准化思路 数据标准化 对于大型公司而言，各个下层子公司都使用自己本地的业务系统，当这些子公司数据往上汇总到总公司时，常常出现代码不一致，数据歧义等等各种各样的问题，在这种情况下，数据标准化就变得不得不行了。 典型的例子，比如医院，大型医院往往包含多个分院，而分院都是用自己的业务系统。业务数据采集汇总后，发现数据结构及数据本身出现歧义，无法直接使用。因此，就不得不对本院及分院的业务数据进行标准化处理，避免歧义，使数据更真实可用，简单易理解。 数据标准化处理应当注意两个关键点： 1.一号对应一对象。 以病人为例，病人可能在各分院及本院都注册建档，因此同一病人可能在各分院都有不同的ID号，但数据采集到本院，与本院数据合并后，进行标准化处理，应保证此病人具有新的唯一ID号。同时需保留病人曾经的各分院及本院ID号，便于其他分院数据的关联（如分院的病人缴费数据需要关联原始分院号码，之后以标准化后唯一ID号，进入本院系统）。 2.事实数据标明数据来源。 如病人缴费信息，因为缴费事实产生的位置不同，需要进行来源标注，分清本院及各分院，便于数据理解及之后的查询和统计。 在构建DW时的数据标准化处理流程上，可以考虑通过以下方式来完成。 标准化准备 在标准化处理之前，需要对DW表格结构进行一些处理，使得标准化过程易于实施，也保证标准化的结果更易于理解。 对于不同的表格上，所需新增的字段也不尽相同。下面分类进行说明： 维表 比如病人信息，科室信息，员工信息，设备信息等，新加字段如下： 事实表 如病人缴费，医生处方，手术记录等，新加字段如下： 数据标准化处理 在数据标准化的处理过程中，也应分为两步进行处理，先进行维表的代码（如ID号）标准化，然后将事实表中的记录以标准化后的代码配合原来的事实信息（如缴费）及数据来源标记（哪个分院）采集到DW 标准事实表中。 维表标准化 1.维表标准化以病人维表为例进行说明 2.将本院及各分院的维表数据采集到DW标准库的缓冲区（可将本院及各分院数据放置于缓冲区的不同用户 下） 数据仓库数据库设计的心得总结 数据仓库是企业商业智能分析环境的核心，它是建立决策支持系统的基础。一个良好的数据仓库设计应该是构建商业智能和数据挖掘系统不懈的追求。下面把数据仓库数据库设计的心得做一小结。 一透彻理解数据仓库设计过程 商业智能和数据挖掘归根到底是“从实践中来，到实践中去”。也就是说现实需求决定系统需求，业务数据决定系统构架，最终使用的时候又必须作用于现实需求，同时通过决策的行为影响业务。那么可以把数据仓库的设计看做是前一部分，即“从实践中来”，数据仓库的应用可以看做是“到实践中去”。把“从实践中来”这个过程进行抽象，数据仓库的设计就是“客观世界→主观世界→关系世界”的过程。 在前面几节完成了6个任务：选择被建模主题的商业过程、确定事实表的粒度、区分每一个事实表的维和层、区分事实表的度量、确定每一个维表的属性、在D BMS中创建和管理数据仓库。实际上这些任务都可以归结到从客观世界到关系世界的过程。那么把这个过程再进行归纳，可以得到如图3-61所示的综合了模型、方法和过程的示意图。 图3-61 数据仓库设计过程的模型和方法示意图 二把握设计的关键环节 如果将时间、精力、金钱和人事优先花在前面的20%，那么这20%会创造出80% 的价值。这就是有名的2/8原则。下面将介绍在数据仓库设计中，哪些因素是属于这20%的范围。 1．需求 需求分析在任何如见项目中都是最为重要的因素之一。企业模型是从企业的各个视点对企业数据需求及数据间关系的抽象。通过将企业模型映射到数据库系统，可以很快地了解现有数据库系统完成了企业模型中的哪些部分，还缺少哪些部分。然后再将企业模型映射到数据仓库系统，发现企业需要的（或可以构造的）主题。通过这样的过程完成对企业数据需求和现有数据的了解，达到明了原有系统和需要建设的主题域间共性的目的。 2．关键性能指标（KPI） 一般而言，一个决策支持系统最重要的就是要呈现决策数据。而KPI就是决策过程中要显示的数据结果的部分，如销售数量、销售金额、毛利和运费等数值部分的数据。这些KPI是通过与相关的维表进行连接而映射出来的。在分析星形模式时，往往要首先确定KPI。 3．信息对象 信息对象是指在每个分析过程中那些会影响到决策的因素。以销售分析为例，时间、产品、员工与客户就是影响决策的大因子，而每个因子又可以分离出多个分层结构，如时间可分为年、季度、月、周和日等，员工可分为年龄层、年龄、年薪层、年薪和员工所在城市等，也就是影响决策的详细因子。这些都是信息对象。从这里我们可以看出，每个大因子如时间、产品、员工与客户等就可以构成如时间维表、产品维表、员工维表与客户维表等。而时间维表又可分为年、季度和日等字段。在分析和设计这些信息对象组成的维度时，需要注意维的唯一性和公用性，千万不要在不同的主题中定义多个表示同一内容的维，如果有可能，一个维表要尽量被多个主题共享。 4．数据粒度 在数据仓库的每个主题中，都必须考虑事实数据的粒度。粒度的具体划分将直接影响到数据仓库中的数据量及查询质量。在数据仓库开始进行分析时。就需要建立合适的数据粒度模型，指导数据仓库设计和其他问题的解决。如果数据粒度定义不当，将会影响数据仓库的使用效果，使数据仓库达不到设计数据仓库的目的。 5．数据之间的联系 在数据仓库中，不同主题的数据之间的物理约束或许不再存在，但无论这些数据如何变化，要知道必须有一些“键”在逻辑上保持着不同数据之间的联系，这样 ETL技术规 第1章.ETL设计规 ETL设计规主要应用于ETL编码的前期工作。由于ETL全过程是面向数据的， 主要工作为数据的抽取（Extract ）、转换（Transform ）、装载（Loading），正确界定所涉及到的数据围和应当应用的转换逻辑对于后续的编码工作非常重要，这些数据关系的确定，我们称之为Mapping （数据映射）。 正确定义数据映射关系是ETL成功实施的前提，一个完善的Mapping应该包含以下几个部分： 1.1源数据集属性 此部分应该详细描述数据源的相关属性，包括： 实体名称一一含数据来源名称（DSN、所有者等信息； 字段名称--- 英文名称； 字段简述--- 中文名称，如为参数信息应该有相关取值解释，如性别字段（1: 男；2:女；0:不详） 类型一一字段类型，含长度和精度信息； 非空属性一一字段是否可以为空； 1.2目标数据集属性 此部分应该详细描述目标数据集的相关属性，包括： 实体名称一一含数据来源名称（DSN、所有者等信息； 字段名称英文名称，建议根据字段含义来命名，而不是简单用拼音来定义字段（此部分由负责设计数据集的人员控制）； 字段简述中文名称，对于保留字段应该给出默认值； 类型一一字段类型，含长度和精度信息； 非空属性一一字段是否可以为空； 1.3 ETL规则 主要描述ETL各个环节的转换规则，包括： 数据源过滤规则——描述从源数据集获取数据过程中过滤掉记录的规则； 关联规则——当源数据集为多个时，描述相互之间的关联关系； 列转换规则一一描述源数据集到目标数据集的字段间的转换规则；此规则非 常重要，要清晰描述字段间的逻辑关系，包括业务逻辑； 目标数据集更新规则一一描述目标数据集的更新策略，包括更新机制和更新频度，如“每日全量更新”、“每周增量更新”等； ETL作业列表一一由于ETL所开发的作业之间包含一定的业务逻辑和编码逻辑，所以调度过程中应遵循一定的逻辑顺序，此部分主要用来明确调度的顺序，包括：作业名称实现Mapping的作业名称，包括该作业功能描述； 调度顺序一一用序号或者是流程图模式描述作业的调度顺序，需要综合考虑业务逻辑、编码逻辑以及系统资源等多方面情况，在保证业务逻辑和编码逻辑的基础上，通过控制调度，最大限度地合理利用系统资源； 数据仓库设计与实现 学号 128302106 姓名江晨婷 成绩 教师张丹平 二O一五年四月 数据仓库建设方案设计与实现 摘要：本文以博士学位调查为基础，创建方案，设计与实现数据仓库，通过对当前各种主流数据仓库软件在性能、价格等方面的对比，充分考虑统计业务、单位数量等实际情况，本系统决定采用SQL Server 2005数据仓库软件来构建综合信息分析系统的数据仓库。 关键词：数据仓库；联机分析；数据挖掘；博士学位 一、概述 数据仓库的设计一般从操作型数据开始，通常需要经过以下几个处理过程；数据仓库设计——数据抽取——数据管理。 1.数据仓库设计 根据决策主题设计数据仓库结构，一般采用星型和雪花模型设计其数据模型，在设计过程中应保证数据仓库的规范化和体系各元素的必要联系。 2.数据抽取 根据元数据库中的主题表定义、数据源定义、数据抽取规则定义对异地异构数据源进行清理、转换、对数据进行重新组织和加工，装载到数据仓库的目标库中。 3.数据管理 数据管理分为目标数据维护和元数据维护两方面。目标数据维护是根据元数据为所定义的更新频率、更新数据项等更新计划任务来刷新数据仓库，以反映数据源的变化，且对时间相关性进行处理。元数据是数据仓库的组成部分，元数据的质量决定整个数据仓库的质量。当数据源的运行环境、结构及目标数据的维护计划发生变化时，需要修改元数据。 二、博士学位授予信息年度数据统计分析 1.按主管部门统计 从主管部门的角度，分析在一个时间段（年）内，各主管部门所授予的博士学位信息统计。可回答如“2008，由某部门主管的，博士学位授予一共有多少，其平均学习年限是多少，脱产学习的有多少人?”等问题。具有表格和图形两种方式来展示分析结果。典型报表格式如表1所示 数据仓库的基本架构 xiaoyi发表于 2013-07-31 23:57 来源：网站数据分析 数据仓库的目的是构建面向分析的集成化数据环境，为企业提供决策支持（Decision Support）。其实数据仓库本身并不“生产”任何数据，同时自身也不需要“消费”任何的数据，数据来源于外部，并且开放给外部应用，这也是为什么叫“仓库”，而不叫“工厂”的原因。因此数据仓库的基本架构主要包含的是数据流入流出的过程，可以分为三层——源数据、数据仓库、数据应用： 从图中可以看出数据仓库的数据来源于不同的源数据，并提供多样的数据应用，数据自上而下流入数据仓库后向上层开放应用，而数据仓库只是中间集成化数据管理的一个平台。 数据仓库从各数据源获取数据及在数据仓库内的数据转换和流动都可以认为是ETL（抽取Extra, 转化Transfer, 装载Load）的过程，ETL是数据仓库的流水线，也可以认为是数据仓库的血液，它维系着数据仓库中数据的新陈代谢，而数据仓库日常的管理和维护工作的大部分精力就是保持ETL的正常和稳定。 下面主要简单介绍下数据仓库架构中的各个模块，当然这里所介绍的数据仓库主要是指网站数据仓库。 数据仓库的数据来源 其实之前的一篇文章已经介绍过数据仓库各种源数据的类型——数据仓库的源数据类型，所以这里不再详细介绍。 对于网站数据仓库而言，点击流日志是一块主要的数据来源，它是网站分析的基础数据；当然网站的数据库数据也并不可少，其记录这网站运营的数据及各种用户操作的结果，对于分析网站Outcome这类数据更加精准；其他是网站内外部可能产生的文档及其它各类对于公司决策有用的数据。 数据仓库的数据存储 源数据通过ETL的日常任务调度导出，并经过转换后以特性的形式存入数据仓库。其实这个过程一直有很大的争议，就是到底数据仓库需不需要储存细节数据，一方的观点是数据仓库面向分析，所以只要存储特定需求的多维分析模型；另一方的观点是数据仓库先要建立和维护细节数据，再根据需求聚合和处理细节数据生成特定的分析模型。我比较偏向后面一个观点：数据仓库并不需要储存所有的原始数据，但数据仓库需要储存细节数据，并且导入的数据必须经过整理和转换使其面向主题。简单地解释下： (1).为什么不需要所有原始数据？数据仓库面向分析处理，但是某些源数据对于分析而言没有价值或者其可能产生的价值远低于储存这些数据所需要的数据仓库的实现和性能上的成本。比如我们知道用户的省份、城市足够，至于用户究竟住哪里可能只是物流商关心的事，或者用户在博客的评论内容可能只是文本挖掘会有需要，但将这些冗长的评论文本存在数据仓库就得不偿失； 数据仓库设计的21条原则：7个步骤，7个禁忌和7种思路(转) 高效实现数据仓库的七个步骤 数据仓库和我们常见的RDBMS系统有些亲缘关系，但它又有所不同。如果你没有实施过数据仓库，那么从设定目标到给出设计，从创建数据结构到编写数据分析程序，再到面对挑剔的用户的评估，整个过程都会带给你一种与以往的项目完全不同的体验。一句话，如果你试图以旧有的方式创建数据仓库，那你所面对的不是预算超支就是所建立的数据仓库无法良好运作。 在处理一个数据仓库项目时需要注意的问题很多，但同时也有很多有建设性的参考可以帮助你更顺利的完成任务。开放思维，不断尝试新的途径，对于找到一种可行的数据仓库实现方法来说也是必需的。 1. 配备一个全职的项目经理或你自己全面负责项目管理 在通常情况下，项目经理都会同时负责多个项目的实施。这么做完全是出于资金和IT资源方面的考虑。但是对于数据仓库项目的管理，绝对不能出现一人身兼数个项目的情况。由于你所处的领域是你和你的团队之前没有进入过的领域，有关数据仓库的一切－数据分析、设计、编程、测试、修改、维护－全都是崭新的，因此你或者你指派的项目经理如果能全心投入，对于项目的成功会有很大帮助。 2. 将项目管理职责推给别的项目经理 由于数据仓库实现过程实在是太困难了，为了避免自虐，你可以在当前阶段的项目完成后就将项目管理职责推给别的项目经理。当然，这个新的项目经理一定要复合第一条所说的具有全职性。为什么要这么做呢？首先，从项目经理的角度看，数据仓库实施过程的任何一个阶段都足以让人身心疲惫。从物理存储设备的开发到Extract-Transform-Load的实现，从设计开发模型到OLAP，所有阶段都明显的比以前接触的项目更加困难。每个阶段不但需要新的处理方法、新的管理方法，还需要创新性的观点。所以将管理职责推给别的项目经理不但不会对项目有损害，还可以起到帮助作用。 3.与用户进行沟通 这里所讲的内容远比一篇文章本身要重要的多。你必须明白，在数据仓库的设计阶段，那些潜在用户自己也不清楚他们到底需要数据仓库为他们做什么。他们在不断的探索和发现自己的需求，而你的开发团队也在和客户的接触中做着同样的事情。更加频繁的与客户接触，多做记录，并让你的团队更关注于项目需求讨论的结果而不是讨论的过程本身。 既然你和客户的交流是为了了解存储的数据是何种类型以及如何有效存储数据，你也许需要（和你的用户一起）采用一种新的方法观察数据，而不是直接处理数据。你可以尝试从中找出隐藏的信息，比如在一段时期内的数字涨落等。不要试图追寻项目需求的答案，而是要让答案找上门来。 4. 以技术/信息库作为领导 由于数据仓库实施的各个阶段都有很大不同，因此你需要有人能起到维持整个项目的连续进行的作用，不过这个职责并不需要那种全职性。项目实施有三个重要方面：架构、技术和业务。将架构作为重点可以保证在整个项目中，数据仓库的架构从物理层往上，都会受到良好的维护。而我们应该将技术作为重点，因为开发团队和关键用户都在使用他们以前从未用过的工具，必须有人监督开发过程以及工具使用的一致性。 最后，在数据仓库的应用过程中浮现出来的业务需求必须被详细分析和记录，以促机开发过程持续下去。如果用户不能很好的与开发人员以及其它用户沟通，那么数据分析和度量方面的开发进程就会延期，所以必须有人关注业务方面的开发，推动开发进入更高级别。 5. 跳出反复修改程序的陷阱 第一次实现的数据仓库肯定不会是最终交付的版本。为什么呢？实际上在真正见到产品前，你无法确定 数据仓库和数据库有什么区别？ 通常情况下基于业务数据库数据分析人员也能完成数据分析需求，但是为什么要建数据仓库？ 没有数据仓库时，我们需要直接从业务数据库中取数据来做分析。 业务数据库主要是为业务操作服务的，虽然可以用于分析，但需要很多额度的调整。 一，业务数据库中存在的问题 基于业务数据库来做分析，主要有以下几个问题： 结构复杂，数据脏乱，难以理解，历史缺失，数据量大时查询缓慢。 结构复杂 业务数据库通常是根据业务操作的需要进行设计的，遵循3NF范式，尽可能减少数据冗余。这就造成表与表之间关系错综复杂。在分析业务状况时，储存业务数据的表，与储存想要分析的角度表，很可能不会直接关联，而是需要通过多层关联来达到，这为分析增加了很大的复杂度。 数据脏乱 因为业务数据库会接受大量用户的输入，如果业务系统没有做好足够的数据校验，就会产生一些错误数据，比如不合法的身份证号，或者不应存在的Null值，空字符串等。 理解困难 业务数据库中存在大量语义不明的操作代码，比如各种状态的代码，地理位置的代码等等，在不同业务中的同一名词可能还有不同的叫法。 这些情况都是为了方便业务操作和开发而出现的，但却给我们分析数据造成了很大负担。各种操作代码必须要查阅文档，如果操作代码较多，还需要了解储存它的表。同义异名的数据更是需要翻阅多份文档。 缺少历史 出于节约空间的考虑，业务数据库通常不会记录状态流变历史，这就使得某些基于流变历史的分析无法进行。比如想要分析从用户申请到最终放款整个过程中，各个环节的速度和转化率，没有流变历史就很难完成。 大规模查询缓慢 当业务数据量较大时，查询就会变得缓慢。 二，数据仓库解决方案 上面的问题，都可以通过一个建设良好的数据仓库来解决。 业务数据库是面向操作的，主要服务于业务产品和开发。 而数据仓库则是面向分析的，主要服务于我们分析人员。评价数据仓库做的好不好，就看我们分析师用得爽不爽。因此，数据仓库从产品设计开始，就一直是站在分析师的立场上考虑的，致力于解决使用业务数据进行分析带来的种种弊端。 数据仓库解决的问题 结构清晰，简单 数据仓库不需要遵循数据库设计范式，因此在数据模型的设计上有很大自由。 数据模型一般采用星型模型，表分为事实表和维度表两类。 其中事实表位于星星的中心，存储能描述业务状况的各种度量数据。 电信企业数据仓库的设计和应用 漆晨曦 编者按: 竞争的加剧使得营销能力成为决定电信企业竞争力的最重要因素，也使得数据仓库作为营销决策分析支撑的手段日益盛行，如何设计数据仓库、数据仓库上可以展开哪些应用、如何展开等成为电信企业迫切需要解决的问题。本期的这一组文章将围绕数据仓库在电信企业的应用展开深入的阐述，同时也是对上述问题的解答。 数据仓库技术在电信企业的盛行是电信行业竞争的必然结果。竞争使得企业的营销能力成为决定企业竞争力的最重要因素，而营销能力则建立在对客户的购买行为、消费行为、服务要求、营销参与等方面信息的收集、整合、存储的数据基础和分析基础上。为了收集和整合客户购买、消费、服务、营销等方面的海量数据，数据仓库必然地进入电信企业的采购单，比如某电信企业有千万级的电信客户，每个客户每月几百次的本地电话和上百分钟的长途电话，上TB级的数据使得原来的数据存储、分析方法和处理能力力不从心，“仓库”的概念随之被引进数据存储过程中。简单地说，数据仓库就是为了保证数据查询和分析的效率，按照主题将所有的数据分门别类进行存储，需要的时候，再按主题提取数据并进行了进一步的分析处理。 构建电信企业数据仓库 目前，电信企业数据仓库的应用一般集中在经营分析和营销决策支撑两方面。一方面数据仓库从营业、计费账务、渠道、客服中心等生产、管理系统获取市场经营的所有相关信息，经过整合、清洗等环节，按主题存储，形成企业内部有关市场经营的统一数据平台，通过查询、报表、多维分析等方式提供给数据分析用户和营销决策人员; 而另一方面，数据仓库根据客户交互系统的需求，经过分析或挖掘，将客户异常消费、流失客户预警、营销活动目标客户等信息反馈到各客户接触系统，供营销经理、营业员、客服人员对相应客户提供针对性营销和服务(数据仓库与电信企业其他生产管理系统之间的关系见图1)。 北京甲骨文软件有限公司咨询经理鲁百年博士 一、国内信息化的现状 1、信息化建设的发展历史： 在国内信息化建设过程中，基本上是按照当时业务系统的需求进行建设，例如：在一个企业中，财务部门为了减少工资发放的差错，提高发放的效率，先建设一个工资发放和管理程序；为了报账和核对的需求，建设一个财务管理程序；在银行首先为了业务处理的方便，将最基本的手工记帐和处理的业务建成一个系统，过一段时间，如果有新的业务推出，就再建设一个新的系统，或在原系统的基础上增加新的业务处理。这样的结果使每个系统和系统之间缺少真正的信息沟通和信息交换。 2、为何要建立数据仓库： 前面我们讲过，业务系统各自为政，相互独立。当很多业务系统建立后，由于领导的要求和决策的需求，需要一些指标的分析，在相应的业务系统基础上再增加分析和相应的报表功能，这样每个系统就增加了报表和分析功能。但是，由于数据源不统一导致了对同一个指标分析的结果不相同。为了解决该问题，Bell Inman提出了数据仓库的概念，其目的是为了分析和决策的需要，将相互分离的业务系统的数据源整合在一起，可以为领导和决策层提供分析和辅助决策。 3、国内企业对数据仓库建设认识的误区： 大家对数据仓库的认识是将业务系统的数据进行数据抽取、迁移和加载（ETL），将这些数据进行整合存放在一起，统一管理，需要什么样的分析就可提供什么样的分析，这就是数据仓库。这样做的结果是花了一年到两年的时间都无法将整个企业业务系统的数据整合在一起，花钱多、见效慢、风险大。一年后领导问起数据仓库项目时，回答往往是资金不足，人力不够，再投入一些资源、或者再延长半年的时间就会见到效果，但是往往半年过后还是仅仅可以看到十几张或者几十张报表。领导不满意，项目负责人压力也很大，无法交待。这时，项目经理或者项目负责人才意识到，项目有问题，但是谁也不敢说项目有问题，因为这样显然是自己当时的决策失误。怎么办？寻找咨询公司或者一些大的厂商，答案往往是数据仓库缺乏数据模型，应该考虑数据模型。如果建设时考虑到整个企业的数据模型，就可以建设成企业级的数据仓库（EDW）。什么是数据模型，就是满足整标准规范体系建设方案设计
数据库与数据仓库的区别是什么
数据仓库-系统设计说明书
大数据仓库建设方案设计
现代电信企业数据仓库系统建设
数据仓库设计的21条原则：7个步骤,7个禁忌和7种思路
数据仓库编程规范
数据仓库的开发设计过程
数据仓库的数据标准化思路.docx
数据仓库数据库设计的心得总结
ETL技术设计规范方案(通用)
数据仓库设计文档模板
数据仓库基本架构
数据仓库设计的21条原则
数据仓库和数据库
电信企业数据仓库的设计和应用.doc资料
数据仓库建设的几点建议.doc