1.数据仓库概要
1.1.数据仓库起因
在建设数据仓库之前，数据散落在企业各部门应用的数据存储中，它们之间有着复杂的业务连接关系，从整体上看就如一张巨大的蜘蛛网：结构上错综复杂，却又四通八达。在企业级数据应用上单一业务使用方便，且灵活多变；但涉及到跨业务、多部门联合应用就会存在：①数据来源多样化，管理决策数据过于分散；②数据缺乏标准，难以整合；③数据口径不统一，可信度低；④缺乏数据管控体系，数据质量难以保证。如下图：
如果企业在数据建设方面没有一个整体的规划，而采取自然演化的方式，那么在未来数据应用的过程中，将不得不面对以下问题：
- 数据缺乏可信性：缺乏统一的维度；数据算法上存在差异；抽取的多层次；外部数据问题；无起始的公共数据源；
- 生产率低：需要根据全部数据生成企业报表；定位数据需要浏览大量文件；抽取程序很多，并且每个都是定制的，不得不克服很多技术上的障碍。
- 数据转化为信息的不可行性：数据没有集成化；缺乏将数据转化为信息所需的历史数据。
基于以上这些的问题，就产生了建立企业级数据仓库的必要性。
1.2.数据仓库发展
数据仓库的萌芽阶段：MIT（麻省理工学院）在20世纪70年代进行了大量研究，经过一系列测试论证，最终提出将业务系统和分析系统分开，将业务处理和分析处理分成不同的层次。也就是如下结论：分析系统和业务系统，只能采用完全不同的架构和设计方法分别处理。
数据仓库的原理、架构和规范的探索阶段：1988年IBM提出了“Information Warehouse”，目标就是为解决企业数据集成问题，在设计上能够实现“一个结构化的环境，能支持最终用户管理其全部的业务，并支持信息技术部门保证数据质量”。但是IBM只是将这种先进的概念用于市场宣传，而没有付诸实践的架构设计。
数据仓库正式提出：1991年Bill Inmon出版了数据仓库的第一本书《Buildingthe Data Warehouse》，提出了数据仓库的概念，阐述了为什么要建立数据仓库，并且也给出了建设数据仓库的方式。
1.3.数据仓库定义
数据仓库是一个面向主题的、集成的、相对稳定的、反映历史变化的（随着时间流逝发生变化）的数据集合。它主要支持企业管理人员决策分析。数据仓库收集了企业相关的内部和外部各个业务系统数据源、归档文件等一系列历史数据，最后转化成企业需要的战略决策信息。
1.3.1.数据仓库特点
- 面向主题的：普通的操作型数据库主要面向事务性处理，而数据仓库中的所有数据一般按照主题进行划分。主题是对业务数据的一种抽象，是从较高层次上对信息系统中的数据进行归纳和整理。面向主题的数据可以划分成两部分----根据原系统业务数据的特点进行主题的抽取和确定每个主题所包含的数据内容。例如客户主题、产品主题、财务主题等；而客户主题包括客户基本信息、客户信用信息、客户资源信息等内容。分析数据仓库主题的时候，一般方法是先确定几个基本的主题，然后再将范围扩大，最后再逐步求精
- 集成性：面向操作型的数据库通常是异构的、并且相互独立，所以无法对信息进行概括和反映信息的本质。而数据仓库中的数据是经过数据的抽取、清洗、切换、加载得到的，所以为了保证数据不存在二义性，必须对数据进行编码统一和必要的汇总，以保证数据仓库内数据的一致性。数据仓库在经历数据集成阶段后，使数据仓库中的数据都遵守统一的编码规则，并且消除许多冗余数据。
- 稳定性：数据仓库中的数据反映的都是一段历史时期的数据内容，它的主要操作是查询、分析而不进行一般意义上的更新（数据集成前的操作型数据库主要完成数据的增加、修改、删除、查询），一旦某个数据进入到数据仓库后，一般情况下数据会被长期保留，当超过规定的期限才会被删除。通常数据仓库需要做的工作就是加载、查询和分析，一般不进行任何修改操作，是为了企业高层人员决策分析之用。
- 反映历史变化：数据仓库不断从操作型数据库或其他数据源获取变化的数据，从而分析和预测需要的历史数据，所以一般数据仓库中数据表的键码（维度）都含有时间键，以表明数据的历史时期信息，然后不断增加新的数据内容。通过这些历史信息可以对企业的发展历程和趋势做出分析和预测。数据仓库的建设需要大量的业务数据作为积累，并将这些宝贵的历史信息经过加工、整理，最后提供给决策分析人员，这是数据仓库建设的根本目的。
1.3.2.数据仓库优势
- 数据整合后信息流简化
- 共享数据利用率提高
- 数据集中管理，来源唯一
- 形成业务单一视图，数据标准化
- 数据管控体系，数据质量得以保证
在数据仓库的建设中，我们一再强调需要数据模型，那么数据模型究竟为什么这么重要呢？首先我们需要了解整个数据仓库的建设的发展史。数据仓库的发展大致经历了这样的三个过程： 通过对数据仓库建设的发展阶段，我们能够看出，数据仓库的建设和数据集市的建设的重要区别就在于数据模型的支持。因此，数据模型的建设，对于我们数据仓库的建设，有着决定性的意义。 一般来说，数据模型的建设主要能够帮助我们解决以下的一些问题： 3.3.1.业务建模 从定义上来说，业务模型是最高层次的数据模型，主要完成： 主题域模型数据仓库的主要主题和重要业务之间的关系。一般来说，在进行数据仓库系统设计和开发之前，设计开发人员和业务人员通过前期的业务建模，已经对主题域的划分达成共识，因为主题域模型反映的是核心的业务问题。主题域模型设计步骤如下： 主题域建模的流程大致可以划分成如下几个部分：在前一个阶段业务建模的过程中，已经对业务系统进行数据的梳理。根据各业务的特点列出数据主题详细的清单，并对每个数据主题都作出详细的解释，然后经过归纳、分类，整理成各个数据主题域，列出每个数据主题域包含哪些部分，并对每个数据主题域作出详细解释，最后划分成主题域概念模型。 3.3.3.逻辑建模 从定义上讲，逻辑模型是以概念模型为基础，对概念模型的进一步细化、分解。逻辑模型通过实体和实体之间的关系描述业务的需求和系统实现的技术领域，是业务需求人员和技术人员沟通的桥梁和平台。 逻辑模型的设计是数据仓库实施中最重要的一步，因为他直接反应了业务部门的实际需求和业务规则，同时对物理模型的设计和实现具有指导作用。他的特点就是通过实体和实体之间的关系勾勒出整个企业的数据蓝图和规则。 概念模型的主题域一般是从企业现有的信息系统和行业自身业务活动汇总的来的业务模型主题域。而逻辑模型除了在概念模型的基础上丰富和细化主题域，并且确定每个主题域包含哪些主题外，还需要： 在逻辑模型的基础上，为应用生产环境选取一个合适的物理结构的过程，包括合适的存储结构和存储方法，称作物理模型的设计过程。逻辑模型转变为物理模型包括以下几个步骤： 从上面列举的例子可以了解，我们使用的抽象归纳方法其实很简单，任何业务可以看成3个部分： 由于实体建模法，能够很轻松的实现业务建模的划分。因此，在业务建模阶段和领域建模阶段，实体建模方法有着广泛的应用。一般在没有现成的行业建模的情况下，可以采用实体建模的方法，和客户一起清理整个业务的模型，进行领域概念的划分，抽象出具体的业务概念，结合客户的使用特点，完全可以创建出一个符合自己需要的数据仓库模型来。 但是，实体建模也有着自己先天的缺陷，由于实体说明法只是一种抽象客观事件的方法，因此，注定了该建模方法只能局限在业务建模和领域概念建模阶段。因此，到了逻辑建模阶段和物理建模阶段，则是范式建模和维度建模发挥长处的阶段。 3.4.2.范式建模法 根据Inmon的观点，数据仓库模型的建设方法和业务系统的企业数据模型类似。在业务系统中，企业数据模型决定了数据的来源，而企业数据模型也分为两个层次，即主题域模型和逻辑模型。同样，主题域模型可以看成业务模型的概念模型，而逻辑模型则是域模型在关系型数据库上的实例化。
从业务数据模型转向数据仓库模型时，同样也需要有数据仓库的域模型，即概念模型，同时也存在域模型的逻辑模型。这里，业务模型中的数据模型和数据仓库的模型稍稍有一些不同，主要区别在于： 范式建模法的最大优点就是从关系型数据库的角度出发，结合了业务系统的数据模型，能够比较方便的实现数据仓库的建模。但其缺点也很明显，由于建模方法限定在关系型数据库之上，在某些时候反而限制了整个数据仓库模型的灵活性，性能等，特别是考虑数据仓库的底层数据向数据集市的数据进行汇总时，需要进行一定的变通才能满足响应的需求。 3.4.3.维度建模法 维度建模是kimball最先提出的。其最简单的描述就是：按照事实表，维表来构建数据仓库、数据集市。这种方法最被人广泛知晓的名字就是星型建模。
上图就是这个架构中最典型的星型架构。星型模式之所以被广泛使用，在于针对各个维做了大量的预处理，如按照维进行预先的统计、分类、排序等。通过这些预处理，能够极大的提升数据仓库的处理能力。特别是针对3NF的建模方法，星型模式在性能上占据明显的优势。 同时，维度建模法的另外一个优势是：维度建模非常直观，仅仅围绕着业务模型，可以直观的反应出业务问题。不需要经过特别的抽象处理，即可以完成维度建模。这一点也是维度建模的优势。 但是维度建模的缺点也非常明显，由于在构建星星模型之前需要进行大量的数据预处理，因此会导致大量的数据处理工作。而且，当业务发生变化，需要重新进行维度的定义时，往往需要重新进行维度数据的预处理。而在这些预处理的过程中，往往会导致大量的数据冗余。 另外一个维度建模的缺点是：如果只是单纯的维度建模，不能保证数据来源的一致性和准确性，而且在数据仓库的底层，不是特别适用于维度建模的方法。 4.维度建模 维度建模具有一定顺序，分别是：①业务处理②粒度③维度④事实。 4.3.数仓在维度建模层次划分