标签：style blog http io 使用 ar 数据 2014 sp
1、联接路径问题：
– 环路
在关系数据库模式中，返回太少行的一种常见联接路径称为环路，环路是一组联接， 它定义了经过模式中的一组表的闭合联接，如下图：
解决办法：创建别名表（基表的副本）。
– 断层陷阱（chasmtrap）
断层陷阱是关系数据库模式中的一种常见问题，其中联接路径返回了比预计更多的数据，断层陷阱是当两个“多对一” 联接会聚在一个表上时三个表之间的一种联接路径，
并且没有适当地分隔会聚联接路径中的上下文，如下图：
解决办法：为每个事实表创建一个上下文，此方法适用于所有情况。
– 扇形陷阱（fantrap）
扇形陷阱是关系数据库模式中仅次于断层陷阱的常见问题，它的影响与返回比预计更多的数据相同，当“一对多”联接链接了依次由另一个“一对多”联接链接的表时，
扇形陷阱是三个表之间的一种联接路径，如下图：
解决方法：创建别名表（基表的副本），然后在别名表与基表之间创建一个新的联接，最后构建上下文。
2、派生表、别名表的概念、实现方式以及它们各自的优缺点？
派生表类似数据库视图，别名表为数据库物理表在Universe中的重命名；
派生表可以灵活地处理较为复杂的数据逻辑，但是效率低；
别名表根据业务需要设置，一般用来解决Universe中的环路问题。
3、Universe设计的要点以及注意事项？
设计要点：
a、业务问题的分析和规划Universe解决方案
b、设计模式
c、构建Universe
d、将Universe分发给用户
e、维度对象按维度分开放置
f、度量对象按主题放置
g、提示与维度和主题对应
注意事项：上下文、环路、断层陷阱、扇形陷阱、基数、BO开发规范等。
4、怎样快速分析、定位并解决BO报表问题（测试）：
5、报表性能优化的策略：
a、逻辑运算向后移，即：报表层向Universe移，Universe层的向后台移
b、在报表上添加查询条件，减少返回分析的数据量
c、建立物化视图
d、避免建立复杂Universe，即一个Universe包含很多事实表，可根据情况适当拆分
e、设置多个数据请求，做到数据并行查询
f、数据库优化（表索引、关联条件等）
6、客户化开发：
其目标是方便客户使用，尽量将度量、纬度、筛选条件等对象公开、合并，并命名为用户易于理解的名称，方便用户自行拖拽组合。
7、变量的创建：
Universe和WEBI报表都可以创建变量，但Universe的变量可供用到该Universe的所有报表使用，而WEBI报表的变量只能供该报表自身使用。
8、WEBI报表的合并查询、警报器、合并维：
合并查询即SQL中的Union操作，各个查询需要保持查询对象个数以及类型的一致性。警报器是做数据预警使用的，当数据符合某一条件时可以按照用户需求来展示特定内 容。 合并维即将多个Query里相同的纬度合并，展示成一个纬度，当报表中使用合并维时，报表会根据度量来查找相应Query的纬度查询数据，但是，如果报表比较复杂，使用合并维生成的数据可能就会乱套，此时应该禁用合并维功能。
9、什么情况下用多个Query查询？
a、查询主题不同时
b、查询效率低下时
10、报表自动生成的SQL语句拿到数据库查看数据没有问题，报表结果却是不对的，原因：
Universe的数据库联接有问题。
11、对上下文的理解：
上下文是一组联接的集合，即一组数据库表的关联关系，它为WEBI报表提供了有效的 查询路径，以使报表能够生成正确的SQL语句。
12、关于测试：首先，BO顾问要自行进行单元测试，BO顾问需要首先确保BO这边所做 的变量及逻辑正确，一般数据问题大多是BW端问题；其次，BO顾问与BW
顾问一起进行集成测试；最后，两方面都没有问题以后，再让客户进行测试。
13、以BW为数据源的BO项目，顾问重点放在开发报表上，Universe是自动生成的，所以无需花费过多工作量；开发之前需与客户明确报表格式及使用哪种BO报表工具；以外
围系统（非SAP系统）为数据源的BO项目，重点放在Universe的设计上，先设计出正确合理的Universe，再设计报表。
标签：style blog http io 使用 ar 数据 2014 sp
原文地址：http://blog.csdn.net/iluckyflower/article/details/39298567
