- BW扩展星型结构和传统的星型结构相比有哪些优势？
回答：标准星型模型是数据仓库中一种常用的组织信息和数据的多维数据模型。它由中心的一个事实表（Fact Table）和一些围绕它的维度表（Dimensional Table）组成。SAP BW星型模型 SAP在标准星型模型基础上做了一些改进，将维度表中的主数据（Master Data）分离出去，独立建表，并通过SID Table和维度表关联起来。SAP将主数据分为3类：属性（Attributes），文字描述（Text），层级结构（Hierarchy）。这里需要注意的是Master Data 并不是InfoCube的一部分，因此Master Data可以在多个InfoCube中共享。这是BW将Master Data从维度表分离出来的主要原因之一。我们知道MOLAP数据仓库为了提高Aggregation的效率，需要事先把这些Aggregation的值计算好，而不是在每次请求的时候才计算。这些预先计算好的Aggregation值当然也需要以cube的形式保存起来。如果是用标准星型模型，那么有两种方法来存储：一种是将Aggregation值和facts一起保存在原始cube的事实表中，这样事实表就会更加庞大，查询效率肯定不高。另一种是为不同的Aggregation建立独立的aggregation cube，存在这写新的cube中，但这样会造成维度表的冗余，每个aggregation cube都会重复一份它所需要的维度表中的所有信息。现在BW将Master Data从维度表分离出来使得维度表变成一张简单的关系表，就解决了Master Data的冗余问题。同时由于Master Data不是和维度表绑在一起而是通过SID Table查询得到，使得多语言支持非常方便。可以为每种语言建立独立的主数据表并根据查询时的语言信息动态绑定到不同语言的主数据表。
- 特征值可以使用哪些数据类型？
答复：一般特性有四种：char、 number、date，time；特殊的特性：时间特性、单位特性、技术特性；
- 一个信息立方体里面有多少个维度，分别是什么？什么是聚集？
答复：有三个维度是系统定义的：时间维度、单位维度、技术特性维度；最少一个自定义维度、做多16个维度；
聚集：聚集是数据仓库经常使用的一个方法。聚集是对信息立方体中的数据(基本事实表， F-Fact表)按照指定的一个子集进行数据汇总，汇总的数据存在不同的独立的事实表(聚集事实表， E-Fact 表)中。根据常用的查询的种类，一个基本事实表可以设置多个聚集事实表。
- · 根据CUBE中几个或者一个维度信息对象创建的Mini Cube，可以提高数据的访问效率当查询访问CUBE时，若聚集中的维度能满足查询条件则只需访问聚集而非CUBE
- · 新生成一张事实表外加一些对应的维度表。
- · 用空间换时间、数据是冗余的。
- · 聚集可以建立在特征值、导航属性、层级上。
在报表运行中，系统自动根据报表的查询维度找到最合适，也就是数据量最少的聚集事实表中读取数据。由于数据量的减少，降低了报表运行时间。也就是说，聚集的设置对最终用户是透明的，用户没有必要关心是否找到合适的聚集，系统自动会找出相应的聚集表。
聚集在是基本的事实表上设置的。聚集可以按照特性建立，可以按照导航属性建立，也可以按照层次建立。
其中对于聚集中维度数据和事实表数据的更新，如果是导航属性生成的维度表，则通过信息对象的change run（在“管理”下面）可以同步聚集维度表数据，而事实表数据通过ROLL UP可以更新。
聚集的适用范围
聚集是基于多维分析模型的基础上设定多维分析模型的子集，同时又是具有真实的物理数据存储的，因而聚集的创建不适合信息集和多信息提供者，以及虚拟信息提供者(虚拟信息立方体)这些不具有物理数据存储的数据对象，也不适用于DS。这样的二维的数据存储对象。
- BW报表查询中，什么是计算指标，什么是限制指标，什么是条件？
计算指标：是针对query的数据源，根据现有的特定指标通过计算或者公式定义出需要的指标；
限制指标：是针对query的数据源，根据现有的特定特性和指标的组合选择出一个新的特定指标；
条件：在query中根据指标做过滤的条件；
中级面试问题:
- 属性有哪些类型，分别是什么？怎么区分这些类型？举个例子
答复：属性分显示属性、导航属性；显示属性在query中不能单独存在，导航属性可以脱离主数据而独立存在；
- 什么是复合特性（compounding）,举例说明。
答复：是把两个特性，合并成一个特性，比如item不能确认一条数据，需要和head连接一起
- 信息立方体有多少张表，分别是什么，cube压缩的实质？
答复：一张实时表和最多16张维表，最少4张维表组成；
Cube压缩的实质：前几天的数据测试无误，做压缩，压缩就是把request id 去掉，相同维度的做add，提高性能；压缩的缺点：不能根据request区分和删除数据；如果选择了with zero ，把数据里真的是0的数据压缩没了；压缩可以设置到处理链中（compression of the cube）；
- 怎么设计出一个好的立方体维度出来，举例说明？
答复：创建维度就是多角度多层次全方位的去分析数据。
1 如果维度表列和事实表中的连接太多时，可以采用行项目维。也就是去掉维度表，把sid表直接放在事实表中。通常有销售订单，发票号。
2 如果维度数据是事实数据20%，可以采用基数高度，对生成cube自动优化，采取合适索引。
维度设计原则：
1倾向于更多的列和更少的行；尽可能有意义
2 设计一个占空间尽可能小的主键；带来更小索引，主要是提高效率
3 不建议特别的规范化，也可以有冗余。规范化后可能使结构更加复杂
4维度表中属性尽可能是文本或离散的。通常是查询的条件
合理的维度数量，不宜太多，影响性能，用户使用起来也没有太大意义；维度的组合和顺序也要合理；把相近的有关系的维度放在一个维表中。
比如可以从Outline的组合顺序、Sparse/Dense的设置、计算脚本的运用、Partition优化、DataLoad File优化等等，其中outline的组织顺序有一定的规则，类似沙漏型。总言之，可以通过这些方法找到一种平衡。
但我想说的是：这么多的维度合不合适？实际上是上面问题的出发点。作为主题，是相对比较独立且很明确的数据，不是大而全。换句话说，每一个主题的背后隐含着1..n个故事场景。在实际中，如果提供很多维度，不但我们组织起来不很容易，而且用户使用起来也会晕倒：因为这么多维度，无所适从；况且，有些组合是没有意义的或者是错误的，多于三维的数据对用户来讲也是很难理解的。鉴于此，我想能不能在深刻理解业务的基础上，将主题重新划分，并不严格的遵从用户提出的那种模式。这是其一；
其二，举例说明。拿移动的用户来讲，他们起初并不清楚OLAP是什么，主题是怎么回事，只是想从这些方面看数据，所以我们就遵从了。这就是根源。个人觉得：应该有一个分析、归纳、提炼、引导的过程，我想这样才会真正的做出比较有价值的主题分析。
根据上述两点：希望重新组织主题，将维度控制在最低限度。
- Multiprovider 和 infoset的区别，举例说明。
答复：Multi Provider与InfoSet和virtual Provider一样都是逻辑结构，都没有数据的实际物理存储。MultiProvider与InfoSet本身不存储任何数据但它们能够把多个如下InfoProvider对象上的数据结合起来：
l . InfoCubes
l . DataStore objects
l . InfoObjects
l . InfoSets
l . Aggregation levels (slices of a InfoCube to support BI Integrated Planning)
MultiProvider与InfoSet的主要区别在于它们结合InfoProvider对象的方式不同。连接方式不一样：multiprovider的连接方式是：union，infoset：inner join，left out join
- 如何分析事实表和维度的大小？
答复：
- BW汇率是如何转换的？举例说明。
一个货币转换类型是汇率，源货币，目标货币和转换时间设置的组合。就是说，在一个货币转换类型中，会设置汇率，源货币，目标货币和转换时间设置。然后将此currency translation type定义于query中的key figure。于是在执行query时便会应用到这个currency translation type。也就是货币转换。
Tcode：RSCUR create currency translation type
在Report中使用汇率转换，这个功能可能大家都很熟悉。但是随着我们的专案增加很多以及程度的提高，一些个性化的需求就出现了。比如这段时间就碰到几个对汇率有特殊要求的问题，通过对Query以及汇率变量的相关了解也找到了相关的解决方案。
我先将问题描述一下.
问题1:DWHD要做一个Actual Forecast的对照表，Actual的数据采用当前的标准汇率，但是Forecast的数据采用用户自己提供的汇率，因为这个提供的汇率是针对未来几期的，所以和实际的汇率可能不一致或者无法去要求一致，所以希望我们的报表需要能够满足这样一种功能要求。
问题2：MM段要在某个报表中增加上个月的金额和本月数据作对比，并且汇率要按照实际月份进行转换。
在解决问题之前，有几个知识点我们是需要清楚的。
- Currency Conversion Type：币种转换类型，也就是转换币种的规则。币种转换会涉及到几个关键问题：A. 汇率 B. 源币种 C. 目标币种 D. 汇率时间
- Currency Conversion Key： 即币种转换类型的编码
- Target Currency Variable：如果在1中设置C目标币种为“Sel. Of targ. Currency with Translation”时，可以在Report中设置目标币种变量，允许用户改变目标币种
在分析上述两个问题之后，我们大致可以把问题1归结为：如何实现多币种转换；而问题2可以归结为：如何实现多时间段转换。
作了以上分析，我们先逐一看看。
首先在Query中，每个Key Figure只要是金额栏位都可以进行汇率转换，如果不是金额栏位通过“Calculated Key Figure”（CKF）或“Restricted Key Figure”（RKF）也可以实现汇率转换。所以通过CKF或RKF可以实现一个Key Figure多种汇率转换。比如将Amount和“Actual” 设定为RKF“Actual Data”，而将Amount和“Forecast”设定为RKF“Forecast Data”，那么就可以分别设定两个汇率转换类型了，其实这个知识点就可以解决问题1了。另外用户有特别说明，Forecast有自己的一套汇率，那么我们就必须把这种情况考虑进去。当然方法也很简单，我们在设置Exchange Rate Type时就有必要自定义一些Type来区别标准的“M“类型。
而问题2着力点可能是如果将汇率转换时间切换到上一个月（或者非当前月）。我们来看看在1中设置D汇率转换时间有那些内容在里面。
- Fixed Time Ref. (固定时间)
- i. Current Date (系统当前时间)
- ii. Key Date (设定一个定值)
- iii. Time Based From Variable（设定时间变量，这个变量必须是挂在Calendar下面）
- Variable Time Ref. （变动时间）
- i. Standard InfoObject （当前报表中标准的时间Object）
- ii. Special InfoObject （处理不是精确到日的时间Object，比如0Fiscper）
如果是ii的情况，会要求设定具体的时间点
- Query Key Date
通过上述的属性的列举，我们可以找到两种解决方案
- 采用1-iii 设置一个时间变量，这样可以灵活的获取时间
- 采用3，因为这个Report其实不要用到Key Date，所以可以利用Key Date 来传递时间
最终权衡之后，我们选择了方案1，因为来得更为合理而专业。同时只需要将设置的时间变量类型设为“Customer Exit”，就可以通过代码来设定时间。
- BW里的分析权限是如何做的？举例说明。
答复：权限：报表权限：报表的权限在bo、port中控制；
data权限：（1）定位对那个字段做权限控制、（2）特性-业务浏览（相关的权限勾选上）、（3）query desinger变量的出理由选择权限，（4）rsa1-管理-分析权限-在分析权限中进行管理；