数据仓库设计的21条原则：7个步骤，7个禁忌，7种思路
数据仓库和我们常见的RDBMS系统有些亲缘关系，但它又有所不同。如果你没有实施过数据仓库，那么从设定目标到给出设计，从创建数据结构到编写数据分析程序，再到面对挑剔的用户的评估，整个过程都会带给你一种与以往的项目完全不同的体验。一句话，如果你试图以旧有的方式创建数据仓库，那你所面对的不是预算超支就是所建立的数据仓库无
法良好运作。
在处理一个数据仓库项目时需要注意的问题很多，但同时也有很多有建设性的参考可以帮助你更顺利的完成任务。开放思维，不断尝试新的途径，对于找到一种可行的数据仓库实
现方法来说也是必需的。
1. 配备一个全职的项目经理或你自己全面负责项目管理
在通常情况下，项目经理都会同时负责多个项目的实施。这么做完全是出于资金和IT资源方面的考虑。但是对于数据仓库项目的管理，绝对不能出现一人身兼数个项目的情况。由于你所处的领域是你和你的团队之前没有进入过的领域，有关数据仓库的一切－数据分析、设计、编程、测试、修改、维护－全都是崭新的，因此你或者你指派的项目经理如果能全
心投入，对于项目的成功会有很大帮助。
2. 将项目管理职责推给别的项目经理
由于数据仓库实现过程实在是太困难了，为了避免自虐，你可以在当前阶段的项目完成后就将项目管理职责推给别的项目经理。当然，这个新的项目经理一定要复合第一条所说的具有全职性。为什么要这么做呢？首先，从项目经理的角度看，数据仓库实施过程的任何一个阶段都足以让人身心疲惫。从物理存储设备的开发到Extract-Transform-Load的实现，从设计开发模型到OLAP，所有阶段都明显的比以前接触的项目更加困难。每个阶段不但需要新的处理方法、新的管理方法，还需要创新性的观点。所以将管理职责推给别的项目经理不但不会对项目有损害，还可以起到帮助作用。
3.与用户进行沟通
这里所讲的内容远比一篇文章本身要重要的多。你必须明白，在数据仓库的设计阶段，那些潜在用户自己也不清楚他们到底需要数据仓库为他们做什么。他们在不断的探索和发现自己的需求，而你的开发团队也在和客户的接触中做着同样的事情。更加频繁的与客户接触，多做记录，并让你的团队更关注于项目需求讨论的结果而不是讨论的过程本身。
既然你和客户的交流是为了了解存储的数据是何种类型以及如何有效存储数据，你也许需要（和你的用户一起）采用一种新的方法观察数据，而不是直接处理数据。你可以尝试从
中找出隐藏的信息，比如在一段时期内的数字涨落等。不要试图追寻项目需求的答案，而
是要让答案找上门来。
4. 以技术/信息库作为领导
由于数据仓库实施的各个阶段都有很大不同，因此你需要有人能起到维持整个项目的连续进行的作用，不过这个职责并不需要那种全职性。项目实施有三个重要方面：架构、技术和业务。将架构作为重点可以保证在整个项目中，数据仓库的架构从物理层往上，都会受到良好的维护。而我们应该将技术作为重点，因为开发团队和关键用户都在使用他们以前从未用过的工具，必须有人监督开发过程以及工具使用的一致性。
最后，在数据仓库的应用过程中浮现出来的业务需求必须被详细分析和记录，以促机开发过程持续下去。如果用户不能很好的开发人员以及其它用户沟通，那么数据分析和度量方面的开发进程就会延期，所以必须有人关注业务方面的开发，推动开发进入更高级别。
5. 跳出反复修改程序的陷阱
第一次实现的数据仓库肯定不会是最终交付的版本。为什么呢？实际上在真正见到产品前，你无法确定的知道自己的目标是什么。或者说，最终用户只有在使用数据仓库产品一段时间后，才能明确告诉你这个产品是不是他所希望的。与你以往处理的项目不同，业务智能还处于发展的初期，每个公司对业务智能都有不同的解释，因此你的项目决不会一次成功。
为了以正确的格式获得数据，你需要在不断变化的状况中摸索前进。BI具有很强的个性，不同的环境、不同的市场以及不同的企业都有不同的BI。这又代表什么呢？这表示你需要把数据库管理员放在一个消息相对封闭的环境中，不要让他知道数据仓库的数据结构以及ETL程序在不断的改变。对此没有别的办法。这样可以减轻你和DBA所承受的压力。
6. 对大量的前端资源进行数据源分析
在数据仓库实现过程中，你不得不在旧有的数据中艰难跋涉，这些数据来自老的数据库、老的磁带机以及远程的数据。它们中的大部分都凌乱不堪，并且难以获取。你要对这些数据进行大量处理，并且还要设计ETL程序来寻找其中的有用信息。如果你希望整个项目做起来比较顺利，并且找到一种方法能够一次成功，那就需要你的开发人员必须花费足够的时间来充分研究这些旧有数据，将凌乱的数据规则化，并尽力设计和实现强壮的数据采集和转换过程。数据仓库的ETL部分会占用整个项目资源的百分之八十，所以一定要确定你
的资源都用在刀刃上了。
7. 将人际关系处理放在首位
在数据仓库实现过程中真正的地狱不是来自技术或者开发方面，而是来自你周围的人。你
也许会遇到一个对项目并不乐观而又没时间听你陈述的领导。你也许会遇到一些开发人员将进度拖延太长时间还抱怨为什么不能用老方法实施。你也许还会遇到一些抱有不切实际的幻想的用户，他们希望轻点鼠标就能实现想象中的功能，但却不愿在他们那边多做些智力投资，更好的培训他们自己的员工。而你也已经疲惫不堪，鼓励投资，以及在开发团队
和用户（甚至老板）中推广新的开发技巧。
总之你要保持微笑。当一切搞定，你的烦恼也就一扫而空了，笑到最后才笑得最轻松。
数据仓库开发过程中的七个禁忌
过去我们一直使用的OLTP技术也许隐藏着许多严重的缺陷。数据仓库的实现并不是一个简单的任务，你会发现以前积累下来的丰富经验，并不适合处理每个数据仓库的独特需求。
下面列出的条款是你在实现数据仓库过程中一定会面对的问题，其中一些看起来并没有想象中那么严重，但是你还是应该尽量避免出现类似问题。数据仓库并不是一个事务处理系统，它没有一定的标准也不会实现某个特定的应用，但它本质上是非常有组织性的。总之，每个公司所建立的数据仓库都是唯一的，并且每一次数据仓库的实现方法都不是一成不变的。在实现数据仓库时需要注意的不单是"应该如何作"，更要注意"不该如何做"。下面就是
我们总结的七点"不该如何作"。
1.不要编写自己无法快速修改的代码
你所要编写的程序主要用于数据分析，而不是处理事务。而你的用户也并不真正知道他们自己真正想要一个什么样的程序。因此你不得不反复修改代码好几次，才会明白用户到底需要一个什么样的程序。如果你编写的程序具有良好的结构和灵活性，就算需要修改也不
会太浪费力气。反之，你会被自己累死。
2. 不要使用无法修改的数据库访问API
在过去，你的数据库可以为大量的客户提供稳定的数据查询服务。而如今，你的程序必须能够应付更多的数据查询。这使得重新改写程序以使得每个查询请求能得到最大的数据量成为势在必行的工作，而一般来说这种代码修改都不会一次成功，所以只有选择合适的可
以修改的API，才能使程序尽快适应新的需求。
3. 不要设计任何无法扩展的东西
在联机处理过程（OLTP）应用中，数据分析并不是一个真正的应用程序。实际上，数据分析的关键是获取大量旧的数据，从中提取数据模型，并以此模型推断出新的信息。而你所编写的访问潜在信息的代码应该具有可扩展性，可以附加新的数据。千万别在支持数据分
析的代码中假定数据都是固定格式的。
4. 不要附加不必要的功能
一个仓库要做的是恰到好处的服务，用户走进仓库，从货架上取得自己所需得信息，仅此而已。由于业务智能、分析以及规律性的问题都有各自的处理程序，因此你的客户唯一的需要就是获取信息。他们需要一种应用环境，可以让他们快速的从数据仓库中取得分析过程所需的数据，而不论这个数据是什么样子的。也许你想帮助他们精炼一下获得的数据，但最好不要这么做。一定要记住，不要给客户的数据分析程序添加任何会影响数据访问性
能的功能。
5. 不要简化数据清除和数据源分析的步骤
在实现数据仓库过程中最应该注意的地方就是为Extract-Transform-Load机制分析数据源，以及为优化负载而清除数据。安全的做法是假设项目经理在这个阶段会需要整个项目资源的一半以上。相反，如果你在这方面进行了简化，稍后肯定会后悔。所以就算系统工作缓
慢，也不要简化清理旧的数据的过程。
6. 不要避免颗粒度和分区问题
在数据仓库设计过程中有两个最大的数据存储问题，第一是如何给转换数据定位一个恰当的颗粒度等级，第二是如何将数据绝对的分区。为什么这两点问题如此重要呢？因为整个数据仓库的响应能力受颗粒度影响，并且数据访问的效率直接与数据分区性能有关。因此这是具有关键性的工作，不要试图避免面对这些问题。
7. 不要在没考虑业务问题前就使用OLAP
用户在亲眼见到程序前通常都不知道自己到底想要个什么样的程序。因此他们的观点有不少错误，比如他们希望分析结果会忠实反应性能度量，或者希望程序会使他们部门或公司的业务工作有所不同。而你必须跳出自己的职责范围，从IT管理者的角度考虑用户部门直至整个企业的运行方式，才能在开发过程中避免这类问题。在通常的OLTP开发中，你可以比较方便的理解业务流程。而在联机分析处理（OLAP）领域，任何事情都需要亲自考察，而在你周围工作的人也许并不会发现你对业务方面存在的误解。因此，不要自以为已经了解了足够的信息。不断的询问才能使你真正了解"业务智能"中的"业务"到底是什么样子的
顺利开发数据仓库的七种思路
对于大多数IT顾问来说，实现一个数据仓库的难度比以前做过的任何项目难度都要大。考虑到不同的数据结构、用途以及应用程序开发方法，以前所积累的经验和技巧大部分都无用武之地了。但是只要在你的前进道路上稍加修正，你就会发现实现一个数据仓库并不是
难事，就算你是第一次实现数据仓库也没问题。
下面列出了数据仓库实施过程需要考虑的步骤，有一些你可能从来没有意识到，而另一些可能已经在实施过程中使用到了，但是重新思考一番也许你会有更多的领悟。开放思维，不断尝试新的途径，找到一种可行的数据仓库实现方法。
1. 再三考虑应用程序的实现方法
数据仓库并不涉及事务处理，并且在报表方面也仅占一小部分。而数据仓库应用程序的本质是分析，尤其是针对业务智能的分析。BI并不是通常所说的数据：它是一种从旧有数据中,模型化得到的新的数据。那么如何才能从旧有数据中挖出这些新数据呢？事实上，这个工作不是让你来完成的，而是你的客户所要完成的。从项目主管的角度看，应该有一个经验丰富的数据表格设计师与你合作，进而决定如何将各类程序融合在一起。其中所遇到的最主要的挑战将是如何用新的方法观察数据，这也是你的客户正在试图使用的方法。
2. 创建抽象的、良好部署的数据库访问组件
在过去你接触过的数据库项目和现在的数据仓库之间，有一点绝对不同，那就是：在Online Transaction Processing （OLTP）环境中，用户数量非常大，但使用到的数据却比较少；而在Online Analytical Processing （OLAP）环境中情况却正好相反，少量的用户在使用大量的数据。而你的工作就是编写一个应用程序来优化这种不同。这里有一个线索：在你所有的分析程序中，都要能抓取连续的数据项，这样在以后建立和访问的数据结构中才能存放与原数据物理结构类似的数据。具体如何实现呢？首先不要规格化数据。第二将其放入数组中最小化读取请求数。按照这种方法，DBA会很乐意与你合作。
3. 保持松散
现在回头看看第一步，你应该可以理解定义一个分析程序不是件简单事了，而且一般情况下，很难在第一次就实现符合要求的最终产品。而在你将要进行分析的数据结构上同样存在这种问题。一句话，实现过程会有很多变数，你需要不断的改动你的程序。通常我们都希望将改动次数降到最低。在一个数据仓库实现过程中，本质是要分析过程毫无差错，这也需要DBA的参与。不要死抓住你的程序设计、代码、框图，或你建立的其它什么东西不
放手，要根据这种变化而不断进行调整。
4. 将管理放在首位
在分析数据源方面你做的如何呢？你是否认为清理垃圾数据的工作非常困难？并不是只有你一个人这样想，做过类似工作的人都有这种看法。在一个一般规模的机构中，作为数据仓库实现过程的一部分，会有大量的旧有数据必须进行一致性处理。所以分析数据源并花费数个小时编写转换程序将旧有数据导入数据仓库是整个数据仓库实现过程中最艰难的一
部分。并且这也是整个项目中最重要的一环，可以占到整个项目周期和预算的四分之三。
所以一定要小心对待。
5. 从字里行间发现问题
与用户交流是个很麻烦的事情，为什么这么说呢？因为很多用户在见到最终产品前都不知道自己想要什么样的产品。定义数据仓库应用程序是一个探索的过程，而且这个过程要反复进行。记住所谓的"业务智能"是用户自己定义的，他们按照自己的理解来处理业务流程。因此这些用户就是连接数据和业务处理过程间的桥梁。他们所要的并不是数据本身，而是隐藏在数据后面的智能性。你可以让他们讨论、思考并给出建设性的意见。但千万不要让他们解决或让他们任意想象和发表那些"有可能"的观点。最后，一定要随时留意用户得出的
结论。
6. 保持领先
数据仓库看起来没有传统的OLTP模式根深蒂固，事实如此。虽然很多人投身数据仓库的开发中，但由于其框架与以前的系统大相径庭，因此在开始的一段时间数据仓库的实现看上去相当混乱。但是坚持下去是很重要的。它具有两方面重要的作用。
第一，技术的领先性。它可以跟踪项目中任何阶段的软件工具的部署和正确使用，以及开发过程。如果这复合你的背景，你可以对此多加留意。
第二，体系结构的领先性。它使得项目在各个阶段转换时，数据仓库和它所支持的系统的物理以及逻辑架构都具有持续性，不会发生改变。这也是你能提供的。
7. 发出警告
最后你要记住，你并不是唯一登上新大陆的人。你周围的每一个人都会有下面一点或几点问题：不现实的期望、对技术的误解、旧习惯或坏习惯、竞争行为，或缺乏对项目的信任度。虽然交流沟通等任务应该是项目经理负责的，但实际上你也要担负起相同的责任。那么作为技术总监你该怎么作呢？首先当然是要真诚的对待周围的人，但一定要竖立威信，适当的发出警告。当你发现项目进度缓慢、资源流失，或者员工失去目标，就要直言不讳的说出来。快速明确的给予警告在大部分情况下都是明智之举。匆忙上马的数据仓库项目
也许会出轨，但不要让失败的项目把你拉下马
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引言 (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可实现对海量数据的实时处理，及时对问题指标进行预警。具体采集系统技术结构图如下: XX 银行 EDW/ 数据仓库项目方案 目录 第一章系统总体架构 (5) 1.1总体架构设计概述 (5) 1.1.1 总体架构的设计框架 (5) 1.1.2总体架构的设计原则 (6) 1.1.3总体架构的设计特点 (7) 1.2 EDW执行架构 (7) 1.2.1执行架构概述 (8) 1.2.2执行架构设计原则 (8) 1.2.3执行架构框架 (9) 1.3 EDW逻辑架构............................................ 1 8 1.3.1逻辑架构框架.......................................... 1 8 1.3.2数据处理流程......................................... 2 7 1.4 EDW运维架构............................................ 2 7 1.4.1 运维架构概述 (27) 1.4.2 运维架构的逻辑框架 (29) 1.5 EDW数据架构............................................ 3 6 1.5.1数据架构设计原则...................................... 3 6 1.5.2数据架构分层设计....................................... 3 8 1.6 EDW应用架构............................................. 4 1 1.6.1应用架构设计原则....................................... 4 1 1.6.2数据服务............................................... 4 2 1.6.3 应用服务 (43) 第二章ETL体系建设 ........................................... 4 4 2.1 ETL架构概述.............................................. 4 4 2.2 ETL设计方案.............................................. 4 6 2.3 ETL关键设计环节......................................... 4 6 2.3.1 接口层设计策略 (46) 高效实现数据仓库的七个步骤 数据仓库和我们常见的RDBMS系统有些亲缘关系，但它又有所不同。如果你没有实施过数据仓库，那么从设定目标到给出设计，从创建数据结构到编写数据分析程序，再到面对挑剔的用户的评估，整个过程都会带给你一种与以往的项目完全不同的体验。一句话，如果你试图以旧有的方式创建数据仓库，那你所面对的不是预算超支就是所建立的数据仓库无法良好运作。 在处理一个数据仓库项目时需要注意的问题很多，但同时也有很多有建设性的参考可以帮助你更顺利的完成任务。开放思维，不断尝试新的途径，对于找到一种可行的数据仓库实现方法来说也是必需的。 1. 配备一个全职的项目经理或你自己全面负责项目管理 在通常情况下，项目经理都会同时负责多个项目的实施。这么做完全是出于资金和IT资源方面的考虑。但是对于数据仓库项目的管理，绝对不能出现一人身兼数个项目的情况。由于你所处的领域是你和你的团队之前没有进入过的领域，有关数据仓库的一切－数据分析、设计、编程、测试、修改、维护－全都是崭新的，因此你或者你指派的项目经理如果能全心投入，对于项目的成功会有很大帮助。 2. 将项目管理职责推给别的项目经理 由于数据仓库实现过程实在是太困难了，为了避免自虐，你可以在当前阶段的项目完成后就将项目管理职责推给别的项目经理。当然，这个新的项目经理一定要复合第一条所说的具有全职性。为什么要这么做呢？首先，从项目经理的角度看，数据仓库实施过程的任何一个阶段都足以让人身心疲惫。从物理存储设备的开发到Extract-Transform-Load的实现，从设计开发模型到OLAP，所有阶段都明显的比以前接触的项目更加困难。每个阶段不但需要新的处理方法、新的管理方法，还需要创新性的观点。所以将管理职责推给别的项目经理不但不会对项目有损害，还可以起到帮助作用。 3.与用户进行沟通 这里所讲的内容远比一篇文章本身要重要的多。你必须明白，在数据仓库的设计阶段，那些潜在用户自己也不清楚他们到底需要数据仓库为他们做什么。他们在不断的探索和发现自己的需求，而你的开发团队也在和客户的接触中做着同样的事情。更加频繁的与客户接触，多做记录， 数据库与信息管理 电脑知识与技术 １引言 传统的数据库技术是以单一的数据资源，即数据库为中心，进行事务处理、批处理、决策分析等各种数据处理工作，数据处理可划分为两大类：操作型处理（ＯＬＴＰ）和分析型处理（统计分析）。操作型处理也叫事务处理，是指对数据库联机的日常操作，通常是对一个或一组纪录的查询和修改，主要为企业的特定应用服务的，注重响应时间，数据的安全性和完整性；分析型处理则用于管理人员的决策分析，经常要访问大量的历史数据。而传统数据库系统利于应用的日常事务处理工作，而难于实现对数据分析处理要求，更无法满足数据处理多样化的要求。因此，专门为业务的统计分析建立一个数据中心，它是一个联机的系统，专门为分析统计和决策支持应用服务的，通过它可以满足决策支持和联机分析应用所要求的一切。这个数据中心就叫做数据仓库。 ２数据仓库概念及发展 ２．１什么是数据仓库 数据仓库就是面向主题的、集成的、不可更新的（稳定性）、随时间不断变化（不同时间）的数据集合，用以支持经营管理中的决策制定过程。数据仓库最根本的特点是物理地存放数据，而且这些数据并不是最新的、专有的，而是来源于其它数据库的。数据仓库的建立并不是要取代数据库，它要建立在一个较全面和完善的信息应用的基础上，用于支持高层决策分析，而事务处理数据库在企业的信息环境中承担的是日常操作性的任务。 ２．２相关基本概念 ２．２．１元数据 元数据（ｍｅｔａｄａｔａ）：是“关于数据的数据”，相当于数据库系统 中的数据字典，指明了数据仓库中信息的内容和位置，刻画了数据的抽取和转换规则，存储了与数据仓库主题有关的各种信息，而且整个数据仓库的运行都是基于元数据的，如修改跟踪数据、抽取调度数据、同步捕获历史数据等。 ２．２．２ＯＬＡＰ（联机分析处理Ｏｎ－ｌｉｎｅＡｎａｌｙｔｉｃａｌＰｒｏｃｅｓｓｉｎｇ）数据仓库用于存储和管理面向决策主题的数据，ＯＬＡＰ对数据仓库中的数据分析，并将其转换成辅助决策信息。ＯＬＡＰ的一个 重要特点是多维数据分析，这与数据仓库的多维数据组织正好形 成相互结合、相互补充的关系。ＯＬＡＰ技术中比较典型的应用是对多维数据的切片和切块、钻取、旋转等，它便于使用者从不同角度提取有关数据，其基本思想是：企业的决策者应能灵活地操纵企业的数据，以多维的形式从多方面和多角度来观察企业的状态、了解企业的变化。对ＯＬＡＰ进行分类，按照存储方式的不同，可将 ＯＬＡＰ分成ＲＯＬＡＰ、ＭＯＬＡＰ和ＨＯＬＡＰ；ＲＯＬＡＰ没有大小限制；现 有的关系数据库的技术可以沿用；可以通过ＳＱＬ实现详细数据与概要数据的储存；现有关系型数据库已经对ＯＬＡＰ做了很多优 化，包括并行存储、并行查询、并行数据管理、基于成本的查询优化、位图索引、ＳＱｌ的ＯＬＡＰ扩展等大大提高了ＲＯＡＬＰ的速度；可以针对ＳＭＰ或ＭＰＰ的结构进行查询优化。 一般比ＭＤＤ响应 速度慢；只读、不支持有关预算的读写操作；ＳＱＬ无法完成部分计算，主要是无法完成多行的计算，无法完成维之间的计算。 ＭＯＬＡＰ性能好、 响应速度快；专为ＯＬＡＰ所设计；支持高性能的决策支持计算；复杂的跨维计算；多用户的读写操作；行级的计算。增加系统复杂度，增加系统培训与维护费用；受操作系统平台中文件大小的限制，难以达到ＴＢ级；需要进行预计算，可能导致数据爆炸；无法支持维的动态变化；缺乏数据模型和数据访问的标准。 ＨＯＬＡＰ综合了ＲＯＬＡＰ和ＭＯＬＡＰ的优点。它将常用的数据存储为ＭＯＬＡＰ，不常用或临时的数据存储为ＲＯＬＡＰ，这样就兼顾 了ＲＯＬＡＰ的伸缩性和ＭＯＬＡＰ的灵活、纯粹的特点。 收稿日期：２００６－０３－２４ 作者简介：赵方（１９７９－），女，浙江杭州人，浙江树人大学助教，硕士在读，主要从事教学、科研工作，以数据库应用、信息管理为主要研究方向。 数据仓库技术及实施 赵 方 （浙江树人大学，浙江杭州３１００１５） 摘要：介绍了数据仓库的基本概念，针对数据仓库建立对创建数据仓库的过程进行了分析，对实现数据抽取、数据仓库的存储和管理等进行分析和比较。 关键词：数据仓库；联机分析处理；数据抽取；数据存储中图分类号：ＴＰ３１１ 文献标识码：Ａ 文章编号：１００９－３０４４（２００６）１７－００３２－０２ ＲｅｓｅａｒｃｈｏｆＤａｔａＷａｒｅｈｏｕｓｅＴｅｃｈｎｏｌｏｇｙ ＺＨＡＯＦａｎｇ （ＺｈｅｊｉａｎｇＳｈｕｒｅｎＵｎｉｖｅｒｓｉｔｙ，Ｈａｎｇｚｈｏｕ３１００１５，Ｃｈｉｎａ） Ａｂｓｔｒａｃｔ：Ｉｎｔｈｉｓｐａｐｅｒ，ｔｈｅｉｎｔｅｒｎａｌｃｈａｒａｃｔｅｒｉｓｔｉｃｓｏｆＤａｔａＷａｒｅｈｏｕｓｅａｒｅｉｎｔｒｏｄｕｃｅｄ．ＡｎａｌｙｚｅｄｔｈｅｐｒｏｃｅｄｕｒｅｏｆｉｎｔｅｇｒａｔｅｄＤａｔａＷａｒｅｈｏｕｓｅａｎｄｂｕｉｌｄｉｎｇｔｈｅｄａｔａｗａｒｅｈｏｕｓｅ，ＤａｔａＥｘｔｒａｃｔ，ＤａｔａＷａｒｅｈｏｕｓｅＳｔｏｒａｇｅａｎｄｈｏｗｔｏｍａｎａｇｅｔｈｅＤａｔａＷａｒｅｈｏｕｓｅ． Ｋｅｙｗｏｒｄｓ：ＤａｔａＷａｒｅｈｏｕｓｅ；ＯＬＡＰ（Ｏｎ－ｌｉｎｅＡｎａｌｙｔｉｃａｌＰｒｏｃｅｓｓｉｎｇ）；ＤａｔａＥｘｔｒａｃｔＴｒａｎｓｆｏｒｍＬｏａｄ；ＤａｔａＳｔｏｒａｇｅ ３２ 数据仓库之路 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.Hadoop技术简介 Hadoop是Apache软件基金会旗下的一个开源分布式计算平台，是目前全世界最主流的大数据应用平台。以分布式文件系统（HDFS）和MapReduce为核心的Hadoop，目前已整合了其他重要组件如Hive、HBase、Spark，以及统一资源调度管理组件Yarn，形成了一个完成的Hadoop产品生态圈。 1.1.HDFS HDFS是一个分布式文件系统，可设计部署在低成本硬件上。它可以通过提供高吞吐率支持大量数据的批量处理，同时支持应用程序流式访问系统数据。 1.2.MapReduce MapReduce是一种编程模型，用于大规模数据机的并行运算。MapReduce可以将一个任务分发到Hadoop平台各个节点上并以一种可靠容错的方式并行处理大量数据集，实现Hadoop的并行任务处理功能。 1.3.Hive Hive是用于对Hadoop中文件进行数据整理、特殊查询和分析储存的工具。Hive提供了一种结构化数据的机制，支持类似传统结构化数据库中SQL元的查询语言，帮助熟悉SQL的用户查询HDFS中数据。 1.4.HBase HBase是一个分布式的、列式储存的开源数据库。HBase不同于传统关系型数据库，适合非结构化数据储存，同时可以为一个数据行定义不同的列。HBase 主要用于需要随机访问、实时读写的大数据。 1.5.Spark Spark是基于内存计算的分布式计算框架。Spark提出了RDD概念，弥补了MapReduce在并行计算各个阶段无法进行有效数据共享的缺陷。同时，Spark形成了自己的生态系统：SparkSQL、SparkStreaming、MLlib，并完全兼容Hadoop 生态系统。 **商业银行数据仓库 报表设计 版本：1.0 4/18/2020 目录 1.报表系统 (3) 1.1. 业务分析 (3) 1.2. 财务分析报表系统 (3) 1.2.1.资产业务分析（月） (3) 1.2.1.1. 资产规模增长情况分析 (4) 1.2.1.2. 资产增量变化情况分析 (4) 1.2.1.3. 资产结构变化情况分析 (4) 1.2.1.4. 贷款资产专项统计 (5) 1.2.2.负债业务分析 (5) 1.2.2.1. 负债规模增长情况分析表 (5) 1.2.2.2. 负债增量变动情况分析表 (5) 1.2.2.3. 负债结构变化情况分析表 (6) 1.2.2.4. 存款负债专项统计 (6) 1.2.3.所有者权益分析 (6) 1.2.3.1. 所有者权益增长情况分析 (6) 1.2.3.2. 所有者权益增量变动情况分析 (7) 1.2.3.3. 所有者权益结构变化情况分析 (7) 1.2.4.财务收支分析 (7) 1.2.4.1. 收支规模增长情况分析 (7) 1.2.4.2. 收支增量变动情况分析 (8) 1.2.4.3. 当期收支情况分析 (8) 1.2.4.4. 财务收支结构变动情况分析 (8) 1.2.4.5. 财务收支计划完成情况分析 (8) 1.2.5.财务比率分析 (9) 1.2.5.1. 各项财务比率分析表 (9) 1.3. 资金计划业务需求 (10) 1.3.1.资金头寸统计 (10) 1.3.2.资金负债管理指标 (10) 1.3.3.现金管理 (10) 1.3.3.1. 结算备付金统计 (10) 1.3.3.2. 库存现金统计 (11) 1.3.3.2.1. 即时余额统计 (11) 1.3.3.2.2. 日均余额统计 (11) 1.3.3.3. 业务量统计 (11) 1.3.4.票据贴现业务统计 (12) 1.4. 综合统计分析 (12) 1.4.1.存款统计 (12) 1.4.1.1. 存款结构统计 (12) 1.4.1.1.1. 日均存款统计 (12) 1.4.1.1.2. 存款即时余额统计 (12) 数据挖掘与数据仓库课程简介 英文名：Data Mining and Data Warehouse 开课单位：计算机学院 课程编码：203086 学分学时：学分，学时32（含实验10） 授课对象：计算机科学与技术专业方向选修课 先修课程：数据库 课程目的和主要内容： 通过本课程的学习，学生应能理解数据库技术的发展为何导致需要数据挖掘，以及数据挖掘潜在应用的重要性；掌握数据仓库和多维数据结构，OLAP（联机分析处理）的实现以及数据仓库与数据挖掘的关系；熟悉数据挖掘之前的数据预处理技术；了解定义数据挖掘任务说明的数据挖掘原语；掌握数据挖掘技术的基本算法，为将来从事数据仓库的规划和实施以及数据挖掘技术的研究工作打下一定的基础。 主要内容包括数据仓库和数据挖掘的基本知识；数据清理、数据集成和变换、数据归约以及离散化和概念分层等数据预处理技术；DMQL数据挖掘查询语言；用于挖掘特征化和比较知识的面向属性的概化技术、用于挖掘关联规则知识的基本Apriori算法和它的变形、用于挖掘分类和预测知识的判定树分类算法和贝叶斯分类算法以及基于划分的聚类分析算法等；了解先进的数据库系统中的数据挖掘方法，以及对数据挖掘和数据仓库的实际应用问题展开讨论。 参考教材： 《数据挖掘概念与技术》，机械工业出版社，JiaWei Han,Micheline Kamber著，范明等译 参考和阅读书目： 《Data Mining: Concepts and Techniques》Jiawei Han and Micheline Kamber, Morgan Kaufmann, 2000 《机器学习》，Tom Mitchell著，曾华军等译 《SQLServer2000数据挖掘技术指南》，机械工业出版社，Claude Seidman著，刘艺等译 数据挖掘与数据仓库教学大纲 一、课程概况 英文名：Data Mining and Data Warehouse 开课单位：计算机学院 课程编码：203086 学分学时：学分，学时32（含实验10） 授课对象： 先修课程：数据库 课程目的和主要内容： 通过本课程的学习，学生应能理解数据库技术的发展为何导致需要数据挖掘，以及数据 数据仓库设计与实现 学号 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).为什么不需要所有原始数据？数据仓库面向分析处理，但是某些源数据对于分析而言没有价值或者其可能产生的价值远低于储存这些数据所需要的数据仓库的实现和性能上的成本。比如我们知道用户的省份、城市足够，至于用户究竟住哪里可能只是物流商关心的事，或者用户在博客的评论内容可能只是文本挖掘会有需要，但将这些冗长的评论文本存在数据仓库就得不偿失； 1.数据仓库 1.1.概念 数据仓库项目是以关系数据库为依托，以数据仓库理论为指导、以OLAP为多层次多视角分析，以ETL工具进行数据集成、整合、清洗、加载转换，以前端工具进行前端报表展现浏览，以反复叠代验证为生命周期的综合处理过程。最终目标是为了达到整合企业信息信息，把数据转换成信息、知识，提供决策支持。 1.2.数据源 数据库、磁带、文件、网页等等。同一主题的数据可能存储在不同的数据库、磁带、甚至文件、网页里都有。 1.3.数据粒度 粒度问题第一反应了数据细化程度；第二在决策分析层面粒度越大，细化程度越低。一般情况，数据仓库需求存储不同粒度的数据来满足不同层面的要求。 例子如顾客的移动话费信息。 1.4.数据分割 分割结构相同的数据，保证灵活的访问数据。 1.5.设计数据仓库 ●与OLTP系统的接口设计：ETL设计 ●数据仓库本身存储模型的设计：数据存储模型设计 1.6.ETL设计难点 数据仓库有多个应用数据源，导致同一对象描述方式不同： ●表达方式不同：字段类型不同 ●度量方式不同：单位不同 ●对象命名方式不同：字段名称不同 ●数据源的数据是逐步加载到数据仓库，怎么确定数据已经加载过 ●如何避免对已经加载的数据的读取，提高性能 ●数据实时发生变化后怎么加载 2.数据存储模型 过程模型：适用于操作性环境。 数据模型：适用于数据仓库和操作性环境。 数据模型从设计的角度分：高层次模型（实体关系型），中间层建模（数据项集），物理模型。 2.1.数据仓库的存储方式 数据仓库的数据由两种存储方式：一种是存储在关系数据库中，另一种是按多维的方式存储，也就是多维数组。 2.2.数据仓库的数据分类 数据仓库的数据分元数据和用户数据。 用户数据按照数据粒度分别存放，一般分四个粒度：早期细节级数据，当前细节级数据，轻度综合级，高度综合级。 元数据是定义了数据的数据。传统数据库中的数据字典或者系统目录都是元数据，在数据仓库中元数据表现为两种形式：一种是为了从操作型环境向数据仓库环境转换而建立的元数据，它包含了数据源的各种属性以及转换时的各种属性；另一种元数据是用来与多维模型和前端工具建立映射用的。 2.3.数据存储模型分类 多维数据建模以直观的方式组织数据，并支持高性能的数据访问。每一个多维数据模型由多个多维数据模式表示，每一个多维数据模式都是由一个事实表和一组维表组成的。 多维模型最常见的是星形模式。在星形模式中，事实表居中，多个维表呈辐射状分布于其四周，并与事实表连接。 在星型的基础上，发展出雪花模式。通常来说，数据仓库使用星型模型。 2.3.1.星型模型 位于星形中心的实体是指标实体，是用户最关心的基本实体和查询活动的中心，为数据仓库的查询活动提供定量数据。每个指标实体代表一系列相关事实，完成一项指定的功能。 位于星形图星角上的实体是维度实体，其作用是限制用户的查询结果，将数据过滤使得从指标实体查询返回较少的行，从而缩小访问范围。每个维表有自己的属性，维表和事实表通过关键字相关联。 星形模式虽然是一个关系模型，但是它不是一个规范化的模型。在星形模式中，维度表被故意地非规范化了，这是星形模式与OLTP系统中的关系模式的基本区别。 使用星形模式主要有两方面的原因:提高查询的效率。采用星形模式设计的数据仓库的优点是由于数据的组织已经过预处理，主要数据都在庞大的事实表中,所以只要扫描事实表 北京甲骨文软件有限公司咨询经理鲁百年博士 一、国内信息化的现状 1、信息化建设的发展历史： 在国内信息化建设过程中，基本上是按照当时业务系统的需求进行建设，例如：在一个企业中，财务部门为了减少工资发放的差错，提高发放的效率，先建设一个工资发放和管理程序；为了报账和核对的需求，建设一个财务管理程序；在银行首先为了业务处理的方便，将最基本的手工记帐和处理的业务建成一个系统，过一段时间，如果有新的业务推出，就再建设一个新的系统，或在原系统的基础上增加新的业务处理。这样的结果使每个系统和系统之间缺少真正的信息沟通和信息交换。 2、为何要建立数据仓库： 前面我们讲过，业务系统各自为政，相互独立。当很多业务系统建立后，由于领导的要求和决策的需求，需要一些指标的分析，在相应的业务系统基础上再增加分析和相应的报表功能，这样每个系统就增加了报表和分析功能。但是，由于数据源不统一导致了对同一个指标分析的结果不相同。为了解决该问题，Bell Inman提出了数据仓库的概念，其目的是为了分析和决策的需要，将相互分离的业务系统的数据源整合在一起，可以为领导和决策层提供分析和辅助决策。 3、国内企业对数据仓库建设认识的误区： 大家对数据仓库的认识是将业务系统的数据进行数据抽取、迁移和加载（ETL），将这些数据进行整合存放在一起，统一管理，需要什么样的分析就可提供什么样的分析，这就是数据仓库。这样做的结果是花了一年到两年的时间都无法将整个企业业务系统的数据整合在一起，花钱多、见效慢、风险大。一年后领导问起数据仓库项目时，回答往往是资金不足，人力不够，再投入一些资源、或者再延长半年的时间就会见到效果，但是往往半年过后还是仅仅可以看到十几张或者几十张报表。领导不满意，项目负责人压力也很大，无法交待。这时，项目经理或者项目负责人才意识到，项目有问题，但是谁也不敢说项目有问题，因为这样显然是自己当时的决策失误。怎么办？寻找咨询公司或者一些大的厂商，答案往往是数据仓库缺乏数据模型，应该考虑数据模型。如果建设时考虑到整个企业的数据模型，就可以建设成企业级的数据仓库（EDW）。什么是数据模型，就是满足整 第一章概述 1.数据挖掘的定义？（书P2，PPT_P8） 从大量的、不完全的、有噪声的、模糊的、随机的数据中，提取隐含在其中的、人们事先不知道的、但又是潜在有用的信息和知识的过程。 2.数据挖掘的源是否必须是数据仓库的数据？可以有哪些来源？（PPT_P14） 关系数据库、数据仓库、事务数据库、高级数据等 3.数据挖掘的常用方法？（P4、PPT_P29） 聚类分析、决策树、人工神经网络、粗糙集、关联规则挖掘、统计分析等 4.数据挖掘的过程包括哪些步骤，每一步具体包括哪些内容？（书P2-3，PPT_P17-19） 确定业务对象、数据准备、数据挖掘、结果分析与知识同化。 5.数据挖掘与数据仓库的关系（联系和区别）？书P6-7，PPT_P45-46 联系：1，数据仓库为数据挖掘提供了更好的，更广泛的数 据源 AHA12GAGGAGAGGAFFFFAFAF 2，数据仓库韦数据挖掘提供了新的支持平台。 3，数据仓库为更好地使用数据挖掘工具提供了方便 4，数据挖掘对数据仓库提供了更好的决策支持。 5，数据挖掘对数据仓库的数据组织提出了更高的要求 6，数据挖掘还为数据仓库提供了广泛的技术支持 区别：数据仓库是一种存储技术，它包含大量的历史数据、当前的详细数据以及综合数据，它能为不同用户的不同决策需要提供所需的数据和信息。~~数据挖掘是从人工智能机器学习中发展起来的，它研究各种方法和技术，从大量的数据中挖掘出有用的信息和知识。 第二章数据仓库 1.数据仓库的定义 数据仓库——是一个面向主题的、集成的、随时间而变化的、不容易丢失的数据集合，支持管理部门的决策定制过程。2.数据仓库数据的四大基本特征： 面向主题的、集成的、不可更新的、随时间变化的。 3.数据仓库体系结构有三个独立的数据层次： AHA12GAGGAGAGGAFFFFAFAF 如何构建银行数据仓库 数据仓库技术作为一项数据管理领域的新技术，其精髓在于针对联机分析处理(OLAP)提出了一种综合的解决方案，与以往很多技术不同的是，它主要是一种概念，在此概念指导下完成系统的构造。既没有可以直接购买到的现成产品，也没有具体的分析规和实现方法，也就是说没有成熟、可靠且被广泛接受的数据仓库标准。在以往关系数据库的设计和实现中，不仅有详细的理论推导，还有无数的设计实例，无论你使用的是什么公司的数据库产品、开发工具，只要按照规做，那么实现同一业务需求的方案都会很相似。而现有数据仓库的实现中，出现了MOLAP方案和ROLAP方案的区别，出现了形形色色的数据仓库建模工具、表现工具，而设计人员的个人经验和素质也会在其中扮演很重要的角色。 数据仓库技术的实现方式 目前在数据仓库技术的实际应用中主要包括如下几种具体实现方式。 1、在关系数据库上建立数据仓库(ROLAP) 2、在多维数据库上建立数据仓库(MOLAP) MOLAP方案是以多维方式来组织数据，以多维方式来存储数据；ROLAP 方案则以二维关系表为核心表达多维概念，通过将多维结构划分为两类表:维表和事实表，使关系型结构能较好地适应多维数据的表示和存储。在多维数据模型的表达方面，多维矩阵比关系表更清晰且占用的存储更少，而通过关系表间的连接来查询数据的ROLAP系统，系统性能成为最大问题。MOLAP方案比ROLAP方案要简明，索引及数据聚合可以自动进行并自动管理，但同时丧失了一定的灵活性。ROLAP方案的实现较为复杂，但灵活性较好，用户可以动态定义统计和计算方式，另外能保护在已有关系数据库上的投资。 由于两种方案各有优劣，因此在实际应用中，往往将MOLAP和ROLAP 结合使用，即所谓的混合模型。利用关系数据库存储历史数据、细节数据或非数值型数据，发挥关系数据库技术成熟的优势，减少花费，而在多维数据库中存储当前数据和常用统计数据，以提高操作性能。 3、在原有关系库上建立逻辑上的数据仓库 由于目前正在运行的OLTP系统中已经积累了海量数据，如何从中提取出决策所需的有用信息就成为用户最迫切的需要。新建数据仓库固然能从功能、性能各方面给出一个完整的解决方案，但需要投入大量的人力、物力，并且数据仓库的建设和分析数据的积累需要一段时间，无法及时满足用户对信息分析的迫切需要。因此在筹建数据仓库的前期，可以采用一些合适的表现工具，在原有OLTP系统上建立起一个逻辑的数 大数据技术部 建设数据仓库的八个步骤2017年04月25日编制 建设数据仓库的八个步骤 摘要：建立数据仓库是一个解决企业问题的过程，业务人员往往不懂如何建立和使用数据仓库，发挥其决策支持的作用；信息部门的人员往往又不懂业务，不知道应该建立哪些决策主题。 关键词：数据仓库元数据 建设数据仓库 建立数据仓库是一个解决企业问题的过程，业务人员往往不懂如何建立和使用数据仓库，发挥其决策支持的作用；信息部门的人员往往又不懂业务，不知道应该建立哪些决策主题，从数据源中抽取哪些数据。因此数据仓库的项目小组应该由业务人员和信息部门的人员共同组成，双方需要相互沟通，协作开发数据仓库。 开发数据仓库的过程包括以下几个步骤。 1.系统分析，确定主题 建立数据仓库的第一个步骤就是通过与业务部门的充分交流，了解建立数据仓库所要解决的问题的真正含义，确定各个主题下的查询分析要求。 业务人员往往会罗列出很多想解决的问题，信息部门的人员应该对这些问题进行分类汇总，确定数据仓库所实现的业务功能。一旦确定问题以后，信息部门的人员还需要确定一下几个因素： ·操作出现的频率，即业务部门每隔多长时间做一次查询分析。 ·在系统中需要保存多久的数据，是一年、两年还是五年、十年。 ·用户查询数据的主要方式，如在时间维度上是按照自然年，还是财政年。 ·用户所能接受的响应时间是多长、是几秒钟，还是几小时。 由于双方在理解上的差异，确定问题和了解问题可能是一个需要多次往复的过程，信息部门的人员可能需要做一些原型演示给业务部门的人员看，以最终确定系统将要实现的功能确实是业务部门所需要的。 2.选择满足数据仓库系统要求的软件平台 在数据仓库所要解决的问题确定后，第二个步骤就是选择合适的软件平台，包括数据库、建模工具、分析工具等。这里有许多因素要考虑，如系统对数据量、响应时间、分析功能的要求等，以下是一些公认的选择标准： ·厂商的背景和支持能力，能否提供全方位的技术支持和咨询服务。 ·数据库对大数据量（TB级）的支持能力。 ·数据库是否支持并行操作。 ·能否提供数据仓库的建模工具，是否支持对元数据的管理。 ·能否提供支持大数据量的数据加载、转换、传输工具（ETT）。 ·能否提供完整的决策支持工具集，满足数据仓库中各类用户的需要。 3.建立数据仓库的逻辑模型 具体步骤如下： （1）确定建立数据仓库逻辑模型的基本方法。 （2）基于主题视图，把主题视图中的数据定义转到逻辑数据模型中。 （3）识别主题之间的关系。 （4）分解多对多的关系。 （5）用范式理论检验逻辑数据模型。数据仓库-系统设计说明书
大数据仓库建设方案设计
某某银行数据仓库建设项目方案说明
数据仓库设计的21条原则：7个步骤,7个禁忌和7种思路
数据仓库技术及实施
数据仓库的开发设计过程
互联网大数据与传统数据仓库技术比较研究
商业银行数据仓库报表设计分析
数据挖掘与数据仓库课程简介
数据仓库设计文档模板
数据仓库基本架构
数据仓库和BI技术概况
数据仓库建设的几点建议.doc
数据仓库复习题
银行数据仓库构建分析
建设数据仓库的八个步骤
相关主题
文本预览