Expert Cube Development with Microsoft SQL Server 2008 Analysis Services(3) 第一章

第一章：设计一个用来提供分析服务的数据仓库

本章主要是介绍，如何设计一个用来提供分析服务的数据仓库。有无数本书，介绍过数据仓库理论，维度建模等。本书不讨论这些。

本章主要是介绍数据仓库设计的各个方面，有些主题，诸如：Analysis Services cube and dimension design，将在后续章节仔细介绍，

有些主题，在本书之外，就不多介绍。

 

1.源数据库

a）The OLTP 数据库

　　一般情况下，在客户需要根据自己的数据进行分析，展示和报表生成时，一个bi解决方案就出现了。这些数据可能以成千上万行，甚至是几百万行的量

    存在数据库里，供业务使用。这类数据库，就是oltp。可能是crm，可能是erp，也可能是其他。

    随后介绍了oltp数据库的一些重要特点。

  我们经常思考的一个问题是：我们是否真的需要一个以维度建模为基础的数据集市，用来作为数据分析的基础。答案是肯定的！

  1）数据集市的构架和OLTP数据库的构架是不一样的，而分析服务等是构架在数据集市上的，他们构架是一致的。从oltp数据源向

      数据集市进行数据转换时，一般都是通过专门的etl工具进行的，而不是简单的使用分析服务里诸如：Data Source View，可以做到的。

  2）oltp数据库，针对oltp类型的查询，有专门的优化；如果bi风格的查询在oltp上运行，会带来很大的性能影响。

  3）如果我们已经有了一个维度的数据集市，那我们就可以在数据集市的（维度和事实数据表里）执行各种清洗和计算。如果直接在oltp里做，

     那我们建立第一个cube可能是快速的，可是，数据是脏的，不一致的和不可信的。而且cube处理会很缓慢。

 

  b）数据仓库

  我们都有一个oltp数据库作为数据源，可是，当这些数据进入数据仓库后，我们思考的问题是，我们真的建立数据仓库了吗？

  这里的难点就是：什么是数据仓库？

  这里有2个观点：

　　　　Ralph Kimball: if we are building a Kimball data warehouse, we build fact
　　　　　　　　　　　　tables and dimension tables structured as data marts. We will end up with a
　　　　　　　　　　　　data warehouse composed of the sum of all the data marts.

 

　　　　

 
　　　　Bill Inmon: if our choice is that of an Inmon data warehouse, then we design
　　　　　　　　　　a (somewhat normalized), physical relational database that will hold the data
　　　　　　　　　　　　warehouse. Afterwards, we produce departmental data marts with their star
　　　　　　　　　　　schemas populated from that relational database.

 

  　　　　

 

   本书，采用Inmon的理论讲解。

  c)数据集市

    无论采用哪种理论，在分析服务cube之前的，都是data mart，也就是数据集市。

 2。针对分析服务的数据建模

   在数据仓库理论的技术上，进行有针对性的建模，比如有利于查询的建模。

   下面介绍一些理论点：

  1）事实表和维度表

  数据集市的构架核心就是，整个数据库分成两大类型的结构：

   维度数据：维度是bi里主要的分析对象。维度放在维度表里。维度有自己的属性，比如颜色等。

               维度有原生key和新产生的key。原生key，是指诸如原来数据库里就有的，比如product id等，新产生的key，只是在数据集市里新出来的数据，中来关联

               维度表和数据表。

 

  事实数据：

 2）星星模型和雪花模型

     星形模型，容易理解。而且，分析服务会发现，容易组织维度建模。当然，不是说，星形模式，是容易建立的。有时候，有更复杂的建模。

 3）Junk dimensions

    在维度建模的处理过程中，经常在最后，碰到有些属性，不属于任何维度。一般情况下，这些属性都是有限范围内的几个值。比如4个，或者更多些。

    这时候，我们有2个选择：

      a)对每个属性创建一个简单的维度，可是，这会导致维度的数量快速增加，从而使cube难以使用。

      b)把他们都放到一个叫做“Junk dimensions”的维度里。A junk dimension is simply a dimension that merges together attributes that do not belong

　　anywhere else and share the characteristic of having only a few distinct 　　values each.

     我们这样做的目的是：

      a)可以降低维度的数量，从而减少事实表里的字段数，降低数据处理速度和存储空间。

      b)降低维度，意味着分析服务在聚合，查询等操作时，性能更好。

      c)最终用户不喜欢cube的维度太多。

   

However, there is one big disadvantage in using a junk dimension: whenever we join
attributes together into a junk dimension, we are clearly stating that these attributes
will never have the rank of a fully-fledged dimension. If we ever change our mind
and need to break one of these attributes out into a dimension on its own we will not
only have to change the cube design, but we will also have to reprocess the entire
cube and run the risk that any queries and reports the users have already created
will become invalid.