SAP /BI的介绍
如前边所述，SAP BI与BW的区别就是在于版本的问题，我们在介绍星状结构的时候你会发现二者在表的设计上可能发生了变化。但是在技术方面，BW的操作与BI的区别不是特别的大。只是我们在不同的版本上看到的界面不一致而已。所以如果大家看到关于BW的一些内容的时候也不要感到惊奇。
当出现BW与BI出现不一致的情况下，我会对二者进行比较，以方便大家的学习与操作。这里将包含概念的区分以及技术操作的变更。甚至会出现怎么将3.5版本的BW标准内容转换成7.0的BI内容。这些具体体现在技术的操作。
1 数据仓库简介
数据仓库是一个拥有自带数据库的系统，它从其他不同的系统中抽取数据来支持查询和分析。为了方便数据的检索和分析，我们需要一种特殊的数据库设计技术----星形模型。 数据仓库是一个面向主题的过程而操作型数据库的数据组织面向事务处理任务，各个业务系统之间各自分离，而数据仓库中的数据是按照一定的主题域进行组织。主题是一个抽象的概念，是指用户使用数据仓库进行决策时所关心的重点方面，一个主题通常与多个操作型信息的系统相关。
目前，大家公认的数据仓库创始人是W.H.Inmon在他所著的《建立数据仓库》一书中对数据仓库所下的定义：数据仓库就是面向主题的、集成的、稳定的、不同时间的数据集合，用以支持经营管理中的决策制定过程。数据仓库中的数据面向主题与传统的数据库面向应用相对应。主题是一个在较高层次将数据归类的标准，每一个主题对应一个宏观的分析领域。数据仓库的集成特性是指在数据进入数据仓库之前，必须进行数据加工和集成，这是建立数据仓库的关键步骤，首先要统一原始数据中的矛盾之处，还要将原始数据结构做成一个面向应用主题的转变，数据仓库的稳定性是指数据仓库反应的是历史数据的内容，而不是日常事务处理产生的数据，数据经加工和集成进入数据仓库后是很少修改或根本不修改的；数据仓库是不同时间的数据集合，它要求数据仓库中的数据保存时能满足进行决策分析的需要，而且数据仓库中的数据都要表明该数据的历史时期。
数据仓库最根本的特点是物理地存放数据，而且这些数据不是最新的、专有的，而是来源于其它的数据库，它要建立在一个较全面和完善的信息应用的基础上，用于支持高层决策分析，而事务处理数据仓库在企业的信息环境中承担的是日常操作性的任务，数据仓库是数据库技术的一种新的应用，到目前为止，数据仓库还是常用数据库管理系统来管理其中的数据。
这里解释一个目前对数据仓库某些认识上的误区。这个也是我在初学的时候犯下的错误。对数据仓库最大的误解就是，初学者把它当作一个现成、可以直接买来使用的产品。事实上，数据仓库和数据库不同，他不是现成的软件或者硬件产品。比较确切地说，数据仓库是一种解决方案，是对原始的操作数据进行各种处理并转换成有用信息的处理过程，用户可以通过分析这些信息，从而做出策略性的决策。
因此，在很多的场合，我们也把数据仓库系统成为“决策支持系统”。由于这些原因，数据仓库的用户不是类似银行柜员的终端操作人员，而是针对各个业务部门的用户和有关决策人员。因此，数据仓库的用户比传统的0LTP 物处理>用户少的多。对于数据仓库而言，我们使用的是OLAP操作。这里又是与一般数据库的一个较大的区别。本章我们会涉及到对OLAP与OLTP的解释以及区别的介绍。 1.1 数据仓库的架构 数据仓库（Data Warehouse DW）是为了便于多维分析和多角度展现而将数据按特定的模式进行存储所建立起来的关系型数据库，它的数据基于OLTP源系统。数据仓库中的数据是细节的、集成的、面向主题的，以OLAP系统的分析需求为目的。 数据仓库的架构模型包括了星型架构与雪花型架构两种模式。如图所示，星型架构的中间为事实表，四周为维度表，类似星星；而相比较而言，雪花型架构的中间为事实表，两边的维度表可以再有其关联子表，从而表达了清晰的维度层次关系。 从OLAP系统的分析需求和ETL的处理效率两方面来考虑：星型结构聚合快，分析效率高；而雪花型结构明确，便于与OLTP系统交互。因此，在实际项目中，我们将综合运用星型架构与雪花型架构来设计数据仓库。 1.2 构建企业级数据仓库五步法 1.2.1 确定主题 即确定数据分析或前端展现的主题。例如：我们希望分析某年某月某一地区的啤酒销售情况，这就是一个主题。主题要体现出某一方面的各分析角度（维度）和统计数值型数据（量度）之间的关系，确定主题时要综合考虑。 我们可以形象的将一个主题想象为一颗星星：统计数值型数据（量度）存在于星星中间的事实表；分析角度（维度）是星星的各个角；我们将通过维度的组合，来考察量度。那么，“某年某月某一地区的啤酒销售情况”这样一个主题，就要求我们通过时间和地区两个维度的组合，来考察销售情况这个量度。从而，不同的主题来源于数据仓库中的不同子集，我们可以称之为数据集市。数据集市体现了数据仓库某一方面的信息，多个数据集市构成了数据仓库。关于主题的介绍大家可以参考1.3小节。 1.2.2 确定量度 在确定了主题以后，我们将考虑要分析的技术指标，诸如年销售额之类。它们一般为数值型数据。我们或者将该数据汇总，或者将该数据取次数、独立次数或取最大最小值等，这样的数据称为量度。 量度是要统计的指标，必须事先选择恰当，基于不同的量度可以进行复杂关键性能指标（KPI）等的设计和计算。 1.2.3 确定事实数据粒度 在确定了量度之后，我们要考虑到该量度的汇总情况和不同维度下量度的聚合情况。考虑到量度的聚合程度不同，我们将采用“最小粒度原则”，即将量度的粒度设置到最小。 例如：假设目前的数据最小记录到秒，即数据库中记录了每一秒的交易额。那么，如果我们可以确认，在将来的分析需求中，时间只需要精确到天就可以的话，我们就可以在ETL处理过程中，按天来汇总数据，此时，数据仓库中量度的粒度就是“天”；反过来，如果我们不能确认将来的分析需求在时间上是否需要精确到秒，那么，我们就需要遵循“最小粒度原则”，在数据仓库的事实表中保留每一秒的数据，以便日后对“秒”进行分析。 在采用“最小粒度原则”的同时，我们不必担心海量数据所带来的汇总分析效率问题，因为在后续建立多维分析模型（CUBE）的时候，我们会对数据提前进行汇总，从而保障产生分析结果的效率。 1.2.4 确定维度 维度是指分析的各个角度。例如我们希望按照时间，或者按照地区，或者按照产品进行分析，那么这里的时间、地区、产品就是相应的维度。基于不同的维度，我们可以看到各量度的汇总情况，也可以基于所有的维度进行交叉分析。 这里我们首先要确定维度的层次（Hierarchy）和级别（Level）。如图所示，我们在时间维度上，按照“年-季度-月”形成了一个层次，其中“年”、“季度”、“月”成为了这个层次的3个级别；同理，当我们建立产品维度时，我们可以将“产品大类-产品子类-产品”划为一个层次，其中包含“产品大类”、“产品子类”、“产品”三个级别。 那么，我们分析中所用到的这些维度，在数据仓库中的存在形式是怎样的呢？ 我们可以将3个级别设置成一张数据表中的3个字段，比如时间维度；我们也可以使用三张表，分别保存产品大类、产品子类、产品三部分数据，比如产品维度。 另外，值得一提的是，我们在建立维度表时要充分使用代理键。代理键是数值型的ID号码（例如图六中每张表的第一个字段），它唯一标识了每一维度成员。更重要的是，在聚合时，数值型字段的匹配和比较，JOIN效率高，便于聚合。同时，代理键对缓慢变化维度有着重要的意义，在原数据主键相同的情况下，它起到了对新数据与历史数据的标识作用。 在此，我们不妨谈一谈维度表随时间变化的问题，这是我们经常会遇到的情况，我们称其为缓慢变化维度。 比如我们增加了新的产品，或者产品的ID号码修改了，或者产品增加了一个新的属性，此时，维度表就会被修改或者增加新的记录行。这样，我们在ETL的过程中，就要考虑到缓慢变化维度的处理。对于缓慢变化维度，有三种情况： ★ 缓慢变化维度第一种类型：历史数据需要修改。这种情况下，我们使用UPDATE 方法来修改维度表中的数据。例如：产品ID号码为123，后来发现ID号码错误了，需要修改成456，那么，我们就在ELT处理时，直接修改维度表中原来的ID号为456。 ★ 缓慢变化维度第二种类型：历史数据保留，新增数据也要保留。这时，要将原来数 据更新，将新数据插入，我们使用UPDATE/INSERT，比如：某一员工2005年在A部门。2006年他调到了B部门。那么统计2005年的数据时就应该将该员工定位到A部门； 而在统计2006年数据时就应该定位到B部门，然后再由新的数据插入时，将按照新部门（B部门）进行处理，这样我们的做法是将该维度成员列表加入标示列，将历史的数据标示为“过期”，将目标数据标示为“当前的”。另一种方法是将该维度打上时间戳，即历史数据成效的时间段作为他的一个属性，在与原始表皮配生成事实表时将按照时间段进行关联，这种方法的好处是该维度成员生效时间明确。 ★ 缓慢变化维度第三种类型：新增数据维度成员改变了属性。例如：某一维度成员新 加入了一列，该列在历史数据中不能基于它浏览，而在目前数据和将来来数据中可以按照它浏览，那么此时我们需要改变维度表属性，即加入新的字段列。那么，我们将使用存储过程或程序生成新的维度属性，在后续的数据中将基于新的属性进行查看。 1.2.5 创建事实表 在确定好事实数据和维度后，我们将考虑加载事实表。 在公司的大量数据堆积如山时，我们想看看里面究竟是什么，结果发现里面是一笔笔生产记录，一笔笔交易记录… 那么这些记录是我们将要建立的事实表的原始数据，即关于某一主题的事实记录表。 我们的做法是将原始表与维度表进行关联，生成事实表。注意在关联时有为空的数据时（数据源脏），需要使用外连接，连接后我们将各维度的代理键取出放于事实表中，事实表除了各维度代理键外，还有各量度数据，这将来自原始表，事实表中将存在维度代理键和各量度，而不应该存在描述性信息，即符合“瘦高原则”，即要求事实表数据条数尽量多（粒度最小），而描述性信息尽量少。 如果考虑到扩展，可以将事实表加一唯一标识列，以为了以后扩展将该事实作为雪花型维度，不过不需要时一般建议不用这样做。 事实数据表是数据仓库的核心，需要精心维护，在JOIN后将得到事实数据表，一般记录条数都比较大，我们需要为其设置复合主键和索引，以实现数据的完整性和基于数据仓库的查询性能优化。事实数据表与维度表一起放于数据仓库中，如果前端需要连接数据仓库进行查询，我们还需要建立一些相关的中间汇总表或物化视图，以方便查询。 1.3 主题介绍 数据仓库是面向在数据模型中已定义好的公司的主题。典型的主题领域包括： ★销售 ★采购 ★物流管理 ★生产进度 ★项目管理 ★会计账目 ★管理费用…… 按照第一章的业务需求，我们就以项目管理为例来展开对数据仓库的研究。 在数据仓库中，主题是已一组相关的表来具体实现的。从这些表中我们就可以延伸出传统的星状图和BI星状结构的概念。关于这些概念我们具体可以参考星状结构详解小节去了解，接下来我们将共同来对主题做一个了解，其中业务环境还是上述业务中举的例子。具体的可以参考如下的罗列： 项目定义ID 项目定义ID 项目承建单位 国网项目类型 电压等级 归口管理部门 WBS ID 可研估算 初涉概算 下达预算 实际成本 促进增收节支情况 WBS ID 河南项目类型 如上图所示的，有三张关联的表。每个表设计用来实现在作为项目管理这个主题领域的一部分。其中2张表定义的分别是项目定对象相关的信息和工作分解结构对象相关的详细信息。另一张表则详细记录了项目管理中的每笔项目产生的金额产生情况。其中这张表与其它表通过ID来关联，这样就组成一个相对完整的项目管理分析主题。 注释：上述的所谓项目对象相关详细信息和工作分解结构对象详细信息，这些信息中其实隐藏掉了大量的特征对象或者关键指标，仅仅是将需求中涉及到的罗列出来，所以大家不要对这些东西感到疑惑。这里所罗列的详细信息在属性中都必须设置成为导航属性。否则就失去了本身的意义。 1.4 数据仓库模型与业务系统数据仓库模型的区别 1.4.1 BW是分析业务系统数据的系统，为什么不直接访问业务系统进行分析呢？ 业务系统是主要对日常业务操作处理信息进行实时存储，在业务过程中需要事实地输入数据到业务表中，这些表中的数据记录能最优化地描述出实际业务过程中千变万化的过程。业务数据库的表数量需要非常多；表关系也会根据业务场景变化的非常的复杂；不同应用之间的表结构区别也很大；并且需要存储业务数据的所有细节。如果直接从业务数据库中抽取数据进行分析也会使得抽取数据及分析数据变成一场噩梦。 数据仓库是在大量的应用数据基础之上做进一步的分析处理，从海量数据中挖掘出有用的历史信息，并根据历史信息和数据的变化趋势对未来的形势变化为决策者提供科学的预测，数量仓库系统不再关注业务系统每一笔单据是如何创建等细节明细信息。数据仓库的数据结构不需要像业务系统的数据结构那样复杂，并且数据结构完全脱离实际业务数据库结构，只是会根据对实际业务的关注点创建不同的维度表信息。经典数据仓库一般采用星型的模型结构分别存储关注角度的维度信息和业务数据信息。BW数据库一般不针对单独的事务