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，再設計報表。

總結

以上是生活随笔為你收集整理的bo sap 客户端_SAP BO 技术的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。