BI是Business Intelligence的英文缩写，中文解释为商务智能，用来帮助企业更好地利用数据提高决策质量的技术集合，是从大量的数据中钻取信息与知识的过程。简单讲就是业务、数据、数据价值应用的过程。
传统的交易系统完成的是Business到Data的过程，而BI要做的事情是在Data的基础上，让Data产生价值，这个产生价值的过程就是Business Intelligence analyse的过程。从技术角度来说，这个过程是一个复杂的技术集合，它包含ETL、DW、OLAP、DM等多环节。
BI不能产生决策，而是利用BI过程处理后的数据来支持决策。
数据仓库设计中的几个基本概念:
数据仓库（Data Warehouse）是一个面向主题的、集成的、相对稳定的、反映历史变化的数据集合，用于支撑管理决策。－－[William H.Inmon]
面向主题
传统数据库主要是为应用程序进行数据处理，未必按照同一主题存储数据；数据仓库侧重于数据分析工作，是按照主题存储的。
集成
面向事务处理的操作型数据库通常与某些特定的应用相关，数据库之间相互独立，并且往往是异构的。
而数据仓库中的数据是在对原有分散的数据库数据抽取、清理的基础上经过系统加工、汇总和整理得到的，必须消除源数据中的不一致性，以保证数据仓库内的信息是关于整个企业的一致的全局信息。
相对稳定
操作型数据库中的数据通常实时更新，数据根据需要及时发生变化。
数据仓库的数据主要供企业决策分析之用，所涉及的数据操作主要是数据查询，一旦某个数据进入数据仓库以后，一般情况下将被长期保留，也就是数据仓库中一般有大量的查询操作，但修改和删除操作很少，通常只需要定期的加载、刷新。
反映历史变化
操作型数据库主要关心当前某一个时间段内的数据。
而数据仓库中的数据通常包含历史信息，系统记录了企业从过去某一时点(如开始应用数据仓库的时点)到目前的各个阶段的信息，通过这些信息，可以对企业的发展历程和未来趋势做出定量分析和预测。
企业数据仓库的建设，是以现有企业业务系统和大量业务数据的积累为基础。
数据仓库不是静态的概念，只有把信息及时交给需要这些信息的使用者，供他们做出改善其业务经营的决策，信息才能发挥作用，信息才有意义。
而把信息加以整理归纳和重组，并及时提供给相应的管理决策者，是数据仓库的根本任务。因此，从产业界的角度看，数据仓库建设是一个工程，是一个过程。而不是一种可以购买的产品。
粒度（Grain）
粒度是指数据仓库中数据的细化或综合程度的级别，也就是数据的详细程度。细节程度越高，粒度级就越低，反之亦然。
设计粒度是设计数据仓库中的一个重要的前提 。因为粒度深深地影响存放在数据仓库中的数据量的大小，同时影响数据仓库所能回答的查询类型。粒度的大小需要数据仓库在设计时在数据量大小与查询的详细程度之间作出权衡。
事实表（Fact Table）
事实表是指其中保存了大量业务度量数据的表。事实表中的度量值一般称为事实。在事实表中最有用的事实就是数字类型的事实和可加类型的事实。事实表的粒度决定了数据仓库中数据的详细程度。
一般事实表中只存放数字或者一些Flag用来统计(Count)，如收益、数量、支出等
维度表（Dimension Table）
维度表可以看作是用户分析数据的窗口，维度表中包含事实数据表中事实记录的特性，有些特性提供描述性信息，有些特性指定如何汇总事实数据表数据，以便为分析者提供有用的信息。
维度层次（Hierarchy）
层次指描述明细数据的层次
数据组织结构:
星形模型(Star Schema)：事实表被维度所包围，维表和事实表通过主关键字和外关键字联系在一起，且维度没有被新的表连接
雪花模型(Snowflake Schema)：是对星型模型的扩展，每个维度都可向外连接到多个详细类别表。在这种模式中。维度表除了具有星型模型中的维度表功能外，还连接上对事实表进行详细描述的详细类别表。详细类别表通过对事实表在有关维上的详细描述，达到了缩小事实表、提高查询效率的目的。
维度的类型：
缓慢变化维(Slowly Changing Dimension)
缓慢变化维的提出是因为在现实世界中，维度的属性并不是静态的，它会随着时间的流失发生缓慢的变化（如：组织结构的调整、客户更改了他的名称或地址）。这种随时间发生变化的维度我们一般称之为缓慢变化维，并且把处理维度表的历史变化信息的问题称为处理缓慢变化维的问题，有时也简称为处理SCD的问题。
处理缓慢变化维的方法通常有三种方式：
第一种方式是直接覆盖原值，通常简称为“TYPE 1” 。这样处理，最容易实现，但是没有保留历史数据，无法分析历史变化信息。
第二种方式是添加维度行，通常简称为“TYPE 2” 。这样处理，需要代理键的支持。实现方式是当有维度属性发生变化时，生成一条新的维度记录，主键是新分配的代理键，通过自然键可以和原维度记录保持关联。
第三种方式是添加属性列，通常简称为“TYPE 3” 。这种处理的实现方式是对于需要分析历史信息的属性添加一列，来记录该属性变化前的值，而本属性字段使用TYPE 1来直接覆盖。这种方式的优点是可以同时分析当前及前一次变化的属性值，缺点是只保留了最后一次变化信息。
快速变化维(Rapidly Changing Dimension)
当某个维度的变化是非常快的时候，我们认定他为快速变化维(具体要看实际的变化频率)，比如：客户的地址、联系电话等。
大维(Huge Dimension)和微型维(Mini-Dimension)
数据仓库中最有意思的维度是一些非常大的维度，比如客户，产品等等。一个大的企业客户维度往往有上百万记录，每条记录又有上百个字段。而大的个人客户维度则会超过千万条记录，这些个人客户维度有时也会有十多个字段，但大多数时候比较少见的维度也只有不多的几个属性。
退化维(Degenerate Dimension)
退化维度一般都是事务的编号，如订单编号、发票编号等。这类编号需要保存到事实表中，但是不需要对应的维度表，所以称为退化维度。
退化维度经常会和其他一些维度一起组合成事实表的主键。在Kimball提出的维度建模中，事实表应该保存最细粒度的数据。所以对于象销售单这样的事实表来说，需要销售单编号和产品来共同作为主键，而不能用销售日期、商场、产品等用来分析的维度共同作为主键。
微型维(Mini Dimension)
以客户维度举例来说，如果维度表中有数百万行记录或者还要多，而且这些记录中的字段又经常变化，这样的维度表一般称之为快变超大维度。对于快变超大维度，设计人员一般不会使用TYPE 2的缓慢变化维处理方法，因为大家都不愿意向本来就有几百万行的维度表中添加更多的行。
这时，有一项技术可以解决这个问题。解决的方法是，将分析频率比较高或者变化频率比较大的字段提取出来，建立一个单独的维度表。这个单独的维度表就是微型维度表。
微型维度表有自己的关键字，这个关键字和原客户维度表的关键字一起进入事实表。有时为了分析的方便，可以把微型维度的关键字的最新值作为外关键字进入客户维度表。这时一定要注意，这个外关键字必须做TYPE 1型处理。
在微型维度表中如果有像收入这样分布范围较广的属性时，应该将它分段处理。比如，存储￥31257.98这样过于分散的数值就不如存储￥30000－￥34999这样的范围。这样可以极大的减少微型维度中的记录数目，也给分析带来方便。
ETL
ETL是将业务系统的数据经过抽取（Extract）、清洗转换（Transform）之后加载（Load）到数据仓库的过程，目的是将企业中的分散、零乱、标准不统一的数据整合到一起，为企业的决策提供分析依据。ETL是BI项目重要的一个环节。通常情况下，在BI项目中ETL会花掉整个项目的1/3的时间,ETL设计的好坏直接关接到BI项目的成败。
ETL的实现有多种方法，常用的有三种。一种是借助ETL工具实现，一种是SQL方式实现，另外一种是ETL工具和SQL相结合。前两种方法各有各的优缺点，借助工具可以快速的建立起ETL工程，屏蔽了复杂的编码任务，提高了速度，降低了难度，但是缺少灵活性。SQL的方法优点是灵活，提高ETL运行效率，但是编码复杂，对技术要求比较高。第三种是综合了前面二种的优点，会极大地提高ETL的开发速度和效率。
建模的一般过程：
1、确定每个事实表的粒度
确定详细数据的粒度级别
此过程必须是在建模之前最需要考虑的问题
比较典型的粒度指的是单独的，基于时间的或聚集在一个常用的维度的事务
2、确定维度的属性
确定是否需要同时存储编号和描述，或者只是编号，或者只是描述的信息
确定哪些字段的值需要被筛选掉或者需要存在
3、确定维度的层次
对于时间维度，我们需要确定的是年，季度，月，周，日等不同的层次
对于产品维度，我们需要确定的是产品大类，产品小类，产品等不同的层次
需要注意的是比如在销售中，地理位置的层次可能和真正的地理位置的层次会有不同
4、确定每个事实所需要关联的维度
通常的维度包括时间，产品，投保人，代理人，和地理等常见对象
请注意，创建的维度需要和与其连接的事实的粒度保持一致
5、确定事实，包括预先计算的
需要根据具体业务来确定事实及其量度
对于每个聚合事实需要在应用(ETL)过程中进行计算
6、确定缓慢变化维
根据需求，对缓慢变化维进行相应的处理
比如：
对于一个需求为不保留历史的客户维度，我们使用第一种类型的缓慢变化维来处理
对于一个需求为需要保留历史的产品维度，我们需要使用第二种类型的缓慢变化维来处理