企业信息应用现状

企业对应用集成的需求

我要了解企业目前的运转情况！（实时监控）
我要知道某地区近5年内的销售情况以制定未来的发展策略！（决策支持）
我要知道哪些是值得发展的优质的顾客！（预测）

1. 什么是BI

1.1 BI的定义

BI是Business Intelligence的英文缩写，中文解释为商务智能， 用来帮助企业更好地利用数据提高决策质量的技术集合，是从大量的数据中钻取信息与知识的过程。简单讲就是业务、数据、数 据价值应用的过程。

1.2 BI要做的事情

传统的交易系统完成的是Business到Data的过程，而BI要做的事情是在Data的基础上，让Data产生价值，这个产生价值的过程就是Business Intelligence analyse的过程。从技术角度来说，这个过程是一个复杂的技术集合，它包含ETL、DW、OLAP、DM等多环节。

1.3 BI的智能

BI不能产生决策，而是利用BI过程处理后的数据来支持决策。
那么BI所谓的智能到底是什么呢？BI最终展现给用户的信息就是报表或图视，但它不同于传统的静态报表或图视，它颠覆了传统报表或图视的提供与阅读的方式，产生的数据集合就象玩具“魔方”一样，可以任意快速的旋转组合报表或图视，有力的保障了用户分析数据时操作的简单性、报表或图视直观性及思维的连惯性。

1.4 BI应用架构

1.5 BI系统架构

1.6 BI应用带来的关键效益

A:获得对业务绩效，流程和客户的可见性和洞察力;更好的进行决策和执行决策，以快速应对机会和挑战
B:横跨多个业务和数据源，获得唯一的、一致的企业信息;在各业务层面中协同战略和执行
C通过集成实时与历史数据，将分析转换为执行力
D赋予所有用户个性化的，基于角色的访问
E能够跨越不同的部门和数据源进行高级分析

2. 什么是数据仓库

2.1 数据仓库的概念

数据仓库（Data Warehouse）是一个面向主题的、集成的、相对稳定的、反映历史变化的数据集合，用于支撑管理决策。

企业数据仓库的建设，是以现有企业业务系统和大量业务数据的积累为基础。

数据仓库不是静态的概念，只有把信息及时交给需要这些信息的使用者，供他们做出改善其业务经营的决策，信息才能发挥作用，信息才有意义。

而把信息加以整理归纳和重组，并及时提供给相应的管理决策者，是数据仓库的根本任务。因此，从产业界的角度看，数据仓库建设是一个工程，是一个过程。而不是一种可以购买的产品。

2.2 数据仓库的特性

面向主题

传统数据库主要是为应用程序进行数据处理，未必按照同一主题存储数据；数据仓库侧重于数据分析工作，是按照主题存储的。

集成

面向事务处理的操作型数据库通常与某些特定的应用相关，数据库之间相互独立，并且往往是异构的。而数据仓库中的数据是在对原有分散的数据库数据抽取、清理的基础上经过系统加工、汇总和整理得到的，必须消除源数据中的不一致性，以保证数据仓库内的信息是关于整个企业的一致的全局信息。

相对稳定

操作型数据库中的数据通常实时更新，数据根据需要及时发生变化。数据仓库的数据主要供企业决策分析之用，所涉及的数据操作主要是数据查询，一旦某个数据进入数据仓库以后，一般情况下将被长期保留，也就是数据仓库中一般有大量的查询操作，但修改和删除操作很少，通常只需要定期的加载、刷新。

反映历史变化

操作型数据库主要关心当前某一个时间段内的数据。而数据仓库中的数据通常包含历史信息，系统记录了企业从过去某一时点(如开始应用数据仓库的时点)到目前的各个阶段的信息，通过这些信息，可以对企业的发展历程和未来趋势做出定量分析和预测。同样都是累计购买过九车产品的顾客，一位是最近三个月购买九车，一位是最近一年从未买过，这对于决策者意义是不同的。

3. 数据仓库设计中的几个重要概念

3.1 ETL

ETL是将业务系统的数据经过抽取（Extract）、清洗转换（Transform）之后加载（Load）到数据仓库的过程，目的是将企业中的分散、零乱、标准不统一的数据整合到一起，为企业的决策提供分析依据。ETL是BI项目重要的一个环节。通常情况下，在BI项目中ETL会花掉整个项目的1/3的时间,ETL设计的好坏直接关接到BI项目的成败。
ETL的实现有多种方法，常用的有三种。一种是借助ETL工具实现，一种是SQL方式实现，另外一种是ETL工具和SQL相结合。前两种方法各有各的优缺点，借助工具可以快速的建立起ETL工程，屏蔽了复杂的编码任务，提高了速度，降低了难度，但是缺少灵活性。SQL的方法优点是灵活，提高ETL运行效率，但是编码复杂，对技术要求比较高。第三种是综合了前面二种的优点，会极大地提高ETL的开发速度和效率。

3.2 数据集市（Data mart）

也叫做“小数据仓库”。如果说数据仓库是建立在企业级的数据模型之上的话，那么数据集市就是企业级数据仓库的一个子集，他主要面向部门级业务，并且只面向某个特定的主题。数据集市可以在一定程度上缓解访问数据仓库的瓶颈。

3.3 即席查询（Ad hoc queries）

是指那些用户在使用系统时，根据自己当时的需求定义的查询。
即席查询生成的方式很多，最常见的就是使用即席查询工具。一般的BI展现工具都会提供即席查询的功能。通常的方式是，将数据仓库中的维度表和事实表映射到语义层，用户可以通过语义层选择表，建立表间的关联，最终生成SQL语句。
即席查询与通常查询从SQL语句上来说，并没有本质的差别。它们之间的差别在于，通常的查询在系统设计和实施时是已知的，所有我们可以在系统实施时通过建立索引、分区等技术来优化这些查询，使这些查询的效率很高。而即席查询是用户在使用时临时生产的，系统无法预先优化这些查询，所以即席查询也是评估数据仓库的一个重要指标。

3.4 ODS（ Operational Data Store,操作数据存储）

ODS在通常的数据仓库架构中都是一个可选的部件，它和数据仓库起到互相补充的作用。最早给ODS下定义的是数据仓库之父Inmon。他的定义是，操作数据存储（ODS）是面向主题的、集成的、可变的、反映当前数据值的和详细的数据的集合，用来满足企业综合的、集成的以及操作型的处理需求。

Inmon的这个定义与他对数据仓库的定义很像。其中前两个特性和数据仓库是一样的，即都是面向主题的和集成的，而后三个特性和数据仓库相差较大。

ODS中的数据是可以变化的：这一点是Inmon相对与他的CIF（企业信息工厂）中的数据仓库来说的，在CIF中，数据仓库中的数据是不进行更新的，对于错误的处理通常是采用新的快照来进行保存。而ODS是可以按常规方法进行更新的。

ODS反映当前数据值：这一点是指ODS中不会长期的保留数据，通常ODS保留的数据的时限最长到一个月或三个月。而数据仓库可以保留五年、十年或更长的数据。
ODS中保留详细数据：这一点是说ODS中只保留原子数据，而不保留汇总数据。而在数据仓库中原子数据和汇总数据都会进行保留。这和ODS可更新的特性相关，因为随时可能将操作型系统的数据变化更新到ODS中，并且数据的迁移时间间隔会很短，这都使汇总数据在ODS中的意义不大。

3.5 数据仓库的搭建模式

4. 维度建模

维度建模以分析决策的需求出发构建模型，构建的数据模型为分析需求服务。它重点解决如何更快速完成分析需求，同时还有较好的大规模复杂查询的响应性能。

4.1 维度建模基础知识

（1）事实与事实表（Fact Table）

事实表是指其中保存了大量业务度量数据的表，是数仓最核心的表。
事实表中的度量值一般称为事实。通常，最有用的事实就是数字类型的事实和可加类型的事实。事实表的粒度，决定了数据仓库中数据的详细程度。
下图为例。中间的表：服装销售明细表，就是一张事实表。其中的销售金额、成本、利润，都是事实，也是我们需要分析的目标数据。

一般事实表中只存放数字或一些flag用来统计，如：销售金额、成本等。另外，通常事实表中的数据不允许修改，新的数据只是简单地添加到事实表中。
事实表特点：数据量庞大、列数少、经常变化。这个比较好理解，因为实事表是一张业务表嘛，业务肯定是不断有新的数据加进来的。

（2）维度与维度表（Dimension Table）

维度表是用户来分析数据的窗口，比如时间、地区、用户等。
维度表中包含事实表中记录的特性，有些特性提供描述性信息，有些特性指定如何汇总事实数据表数据，以便为分析者提供有用的信息。

例如上图，包括了五张维度表：时间维表、产品维表、地域维表、用户维表、支付维表。每一张维度表对应现实世界中的一个对象或概念。
每一张维度表利用维度关键字（图中标红字段）通过事实表中的外键约束事实表的中某一行。
维度表等特点：很多描述性的列，行数较少，内容较固定。这个也好理解，比如地域，省市区县这些内容十几年都不会有啥变化。

（3）粒度

粒度是指数据仓库的数据单位中，保存数据的细化程度的级别。简单点来看，在实事表中一条记录所表达的业务细节，就是粒度。

通常，为了便捷的下钻分析，我们都会使用到最小粒度。比如订单表中，最小粒度就是一条订单的记录。使用最小粒度的优点：
可以频繁的ETL操作
很多数据挖掘需要最小粒度数据
方便向下钻取
当然，使用最小粒度也有缺点：
存储和维护代价较高
需要进一步构建汇总事实表来支持汇总数据查询

（4）切片、切块与旋转

切片与切块主要是用来进行数据分析的。我们以下面的三维（产品、年度、地区）为例。

切片：从多维数组中选定一个二维子集，切出一个“平面” 。比如选中上图的2011年，这就是一个切片。
切块：从多维数组中选定一个三维子集，切出一个“立方体” 。比如上图中，年度选择了2011、2012，然后看所有的数据内容，这就是一个切块。
旋转：改变一个报告（页面）显示的维方向

（5）钻取

根据维层次，改变数据分析的粒度，就是钻取分析，主要包括上钻（也叫上卷）和下钻。其实Excel中的数据透视就是各种上卷和下钻。

下钻：从汇总数据深入到细节数据进行观察或增加新维
上钻（上卷）：从某一维上将低层次的细节数据概括到高层次的汇总数据或减少维数
钻透：直接下钻到最明细的数据。

4.2 建模中的三种模型

（1）星形模型

所谓星型模型，具体表现是：事实被维度所包围，且维度没有被新的表连接。如下图。

每个维表都有一个维作为主键，所有这些维的主键组合成事实表的主键。

可以看出，星型模型是比较单纯的模型，像星星一样触角没有延伸了。

（2）雪花模型

所谓的雪花模型，是有一个或多个维表没有直接连接到事实表上，而是通过其他维表连接到事实表上，就像雪花一样。如下图：

雪花模型去除了数据冗余，更贴近与业务。尽可能降低数据存储量以及联合较小的维表来改善查询性能。

（3）星座模型

无论是星型模型还是雪花模型，都是单事实表的情况。但通常来讲，实践当中大部分情况都是多事实表的。这时就是需要星座模型了。

所谓星座模型，是多个事实表共享维度表， 因而可以视为星型模型的集合，故亦称星座模型（星系模型）。如下图：

星座模型是数据仓库最常使用的模型。

4.3 维度的类型

（1）缓慢变化维(Slowly Changing Dimension)

缓慢变化维的提出是因为在现实世界中，维度的属性并不是静态的，它会随着时间的流失发生缓慢的变化（如：组织结构的调整、客户更改了他的名称或地址）。这种随时间发生变化的维度我们一般称之为缓慢变化维，并且把处理维度表的历史变化信息的问题称为处理缓慢变化维的问题，有时也简称为处理SCD的问题。
处理缓慢变化维的方法通常有三种方式：
第一种方式是直接覆盖原值，通常简称为“TYPE 1” 。这样处理，最容易实现，但是没有保留历史数据，无法分析历史变化信息。
第二种方式是添加维度行，通常简称为“TYPE 2” 。这样处理，需要代理键的支持。实现方式是当有维度属性发生变化时，生成一条新的维度记录，主键是新分配的代理键，通过自然键可以和原维度记录保持关联。
第三种方式是添加属性列，通常简称为“TYPE 3” 。这种处理的实现方式是对于需要分析历史信息的属性添加一列，来记录该属性变化前的值，而本属性字段使用TYPE
1来直接覆盖。这种方式的优点是可以同时分析当前及前一次变化的属性值，缺点是只保留了最后一次变化信息。

（2）快速变化维(Rapidly Changing Dimension)

当某个维度的变化是非常快的时候，我们认定他为快速变化维(具体要看实际的变化频率)，比如：客户的地址、联系电话等。

（3）大维(Huge Dimension)

数据仓库中最有意思的维度是一些非常大的维度，比如客户，产品等等。一个大的企业客户维度往往有上百万记录，每条记录又有上百个字段。而大的个人客户维度则会超过千万条记录，这些个人客户维度有时也会有十多个字段，但大多数时候比较少见的维度也只有不多的几个属性。

（4）微型维(Mini-Dimension)

以客户维度举例来说，如果维度表中有数百万行记录或者还要多，而且这些记录中的字段又经常变化，这样的维度表一般称之为快变超大维度。对于快变超大维度，设计人员一般不会使用TYPE
2的缓慢变化维处理方法，因为大家都不愿意向本来就有几百万行的维度表中添加更多的行。
这时，有一项技术可以解决这个问题。解决的方法是，将分析频率比较高或者变化频率比较大的字段提取出来，建立一个单独的维度表。这个单独的维度表就是微型维度表。
微型维度表有自己的关键字，这个关键字和原客户维度表的关键字一起进入事实表。有时为了分析的方便，可以把微型维度的关键字的最新值作为外关键字进入客户维度表。这时一定要注意，这个外关键字必须做TYPE
1型处理。
在微型维度表中如果有像收入这样分布范围较广的属性时，应该将它分段处理。比如，存储￥31257.98这样过于分散的数值就不如存储￥30000－￥34999这样的范围。这样可以极大的减少微型维度中的记录数目，也给分析带来方便。

（5）退化维(Degenerate Dimension)

退化维度一般都是事务的编号，如订单编号、发票编号等。这类编号需要保存到事实表中，但是不需要对应的维度表，所以称为退化维度。
退化维度经常会和其他一些维度一起组合成事实表的主键。在Kimball提出的维度建模中，事实表应该保存最细粒度的数据。所以对于象销售单这样的事实表来说，需要销售单编号和产品来共同作为主键，而不能用销售日期、商场、产品等用来分析的维度共同作为主键。

4.4 常用的事实表类型

（1）聚集事实表（Aggregated Fact Table）

是原子事实表上的汇总数据，也称为汇总事实表。即新建立一个事实表，它的维度表是比原维度表要少，或者某些维度表是原维度表的子集，如用月份维度表代替日期维度表；事实数据是相应事实的汇总，即求和或求平均值等。在做数据迁移时，当相关的维度数据和事实数据发生变化时，聚集事实表需要做相应的刷新。 物化视图是实现聚集事实表的一种有效方式，可以设定刷新方式，具体功能由DBMS来实现。

（2）合并事实表（Consolidated Fact Table）

是指将位于不同事实表中处于相同粒度的事实进行组合建模而成的一种事实表。即新建立一个事实表，它的维度是两个或多个事实表的相同维度的集合；事实是几个事实表中感兴趣的事实。在Kimball的总线架构中，由合并事实表为主组成的合并数据集市称为二级数据集市。合并事实表的粒度可以是原子粒度也可以是聚集粒度。在做数据迁移时，当相关的原子事实表的数据有改变时，合并事实表的数据需要重新刷新。合并事实表和交叉探察是两个互补的操作。
聚集事实表和合并事实表的主要差别是合并事实表一般是从多个事实表合并而来。但是它们的差别不是绝对的，一个事实表既是聚集事实表又是合并事实表是很有可能的。因为一般合并事实表需要按相同的维度合并，所以很可能在做合并的同时需要进行聚集，即粒度变粗。

（3）旋转事实表（Pivoted Fact Table）

是将一条记录中的多个事实字段转化为多条记录，其中每条记录保存一个事实字段的一种建模方法。或者反过来，也可以由多条记录转化为一条记录。
旋转事实表建模方法的使用通常是为了简化前端数据展现的查询。它通过改变后端的事实记录存储方式，使相应的查询需求的性能得到的极大的提高。如果在SQL或者查询工具中进行这种转换会非常麻烦，效率也很差。
和合并事实表类似，有时当基础表中没有记录时，旋转事实表也要存储一些零值在里面。

（4）预连接聚集表（Pre-Joined Aggregagte Table）

是通过对事实表和维度表的联合查询而生成的一类汇总表。在预连接聚集表中，保存有维度表中的描述信息和事实表的事实值。

通过预连接，可以避免在用户查询时RDBMS的连接操作，所以预连接聚集表的查询效率要高很多。

在这个销售事实表，前五个字段都来自于维度表的描述字段，后两个字段来自于事实表的事实字段。这样在用户提交查询后，RDBMS就不需要连接维度表和事实表了，只需直接在该表中查询即可。

预连接聚集表有一个很大的缺点，它需要占用大量的存储空间。预连接事实表的记录和事实表一样多，每条记录的长度和维度表一样长，所以对存储空间的需求是非常大的。除非情况特殊，或者该表是高度汇总的，否则不建议建立预连接聚集表。在建立预连接聚集表时需要平衡效率和存储空间的矛盾。

预连接聚集表的生成方式较为简单，直接使用SQL查询即可生成。

如果聚集导航器的功能很强大的话，也可以处理预连接聚集表。否则，需要用户理解预连接聚集表，并在SQL中直接使用该表。

预连接聚集表在数据仓库领域有着很重要的作用，是汇总表的一种。它的优点和缺点都很明显，在使用时需要综合考虑。

（5）非事实型事实表（Factless Fact Table）

事实表通常会保存十个左右的维度外键和多个度量事实，度量事实是事实表的关键所在。在非事实型事实表中没有这些度量事实，只有多个维度外键。非事实型事实表通常用来跟踪一些事件或者说明某些活动的范围。

下面举例来进行说明：
第一类非事实型事实表是用来跟踪事件的事实表。例如：学生注册事件，学校需要对学生按学期进行跟踪。维度表包括学期维度、课程维度、系维度、学生维度、注册专业维度和取得学分维度，而事实表是由这些维度的主键组成，事实只有注册数，并且恒为1。这样的事实表可以回答大量关于大学开课注册方面的问题，主要是回答各种情况下的注册数。

第二类非事实型事实表是用来说明某些活动范围的事实表。例如：促销范围事实表。通常销售事实表可以回答如促销商品的销售情况，但是对于那些没有销售出去的促销商品没法回答。这时，通过建立促销范围事实表，将商场需要促销的商品单独建立事实表保存。然后，通过这个促销范围事实表和销售事实表即可得出哪些促销商品没有销售出去。这样的促销范围事实表只是用来说明促销活动的范围，其中没有任何事实度量。

（6）切片事实表（Sliced Fact Table）

切片事实表中的字段结构和相应的基础表完全相同，差别在于存储的记录的范围。切片事实表中保存记录的是相应基础表中记录的子集，记录数通常与某个维度记录数相同。

这种建模方法一般用来满足特殊需要，如需要分析某些特殊问题时，可以将与之相关的数据切片出来。相反，这种方法也常用于合并存储在不同地区的数据，即各个地区都保存自己地区的数据，总部和所有地区的表结构都相同，然后总部将所有地区的数据合并在一起。

切片事实表的结构与相对应的基础表相同，数据来源于相对应的基础表。切片事实表由于缩小了表中数据的记录数，所以查询的效率得到了很大的提高。

4.5 建模的一般过程

4.5.1 确定该业务过程每个事实表的粒度

确定详细数据的粒度级别

此过程必须是在建模之前最需要考虑的问题

比较典型的粒度指的是单独的，基于时间的或聚集在一个常用的维度的事务

4.5.2 确定维度的属性

确定是否需要同时存储编号和描述，或者只是编号，或者只是描述的信息

确定哪些字段的值需要被筛选掉或者需要存在

4.5.3 确定维度的层次

对于时间维度，我们需要确定的是年，季度，月，周，日等不同的层次

对于产品维度，我们需要确定的是产品大类，产品小类，产品等不同的层次

需要注意的是比如在销售中，地理位置的层次可能和真正的地理位置的层次会有不同

4.5.4 确定每个事实所需要关联的维度

通常的维度包括时间，产品，投保人，代理人，和地理等常见对象

请注意，创建的维度需要和与其连接的事实的粒度保持一致

4.5.5 确定数字型事实，包括预先计算的

需要根据具体业务来确定事实及其量度

对于每个聚合事实需要在应用(ETL)过程中进行计算

4.5.6 确定缓慢变化维

根据需求，对缓慢变化维进行相应的处理