biee報表開發總結

近日學習BIEE,偶然發現好文章:

biee報表開發總結(一)

當BI項目已經在essbase中搭建好框架之後,接着就要通過biee製作各種報表來展示BI的成果了。
BIEE報表開發能否成功的關鍵就在於初期的設計。首先你必須明確你的需求,你開發的報表是給哪些人使用的,他們會如何使用,比如他們一般會有些什麼輸入,他們希望產生什麼樣的輸出以及他們可能會做什麼樣的下鑽動作。一張報表往往只是給一類人使用的,你必須精心地爲他們挑選合適的維度以及初始粒度。所以同樣的查詢內容往往需要做好幾張報表適合不同維度不同方式的數據查看(用下鑽的方式可以通過彙總數據查詢到詳細數據,但是效率不高,如果已有足夠的信息可以直接查到詳細數據則直接顯示詳細數據)。這樣做可以減少每次查詢使用到得維度,從而提高查詢效率。一般在一張儀表盤頁中只放一張報表(彙總報表除外)。一組報表一般由一張彙總報表(給領導查看)和幾張明細查閱報表組成,彙總報表中包含各種圖表,初始粒度大,同時支持很深的下鑽,明細報表針對某個用途提供合適的查詢方式,一般不放圖表。維度是由請求字段控制的,字段越多查詢越慢,所以請求字段不能過多,尤其是大的維度(我遇到過成員好幾千的維度,而且層次很少)不能太多,除非已經在篩選器中進行控制,最好不要直接添加時間字段,而使用全局篩選器來控制時間。相反請求提示和相應的篩選器越多查詢效率就越高,所以請求提示和篩選器可以多一些(這樣還可以提供便捷的訪問),請求提示使用什麼輸入方式也是需要考慮的問題。關於使用表還是數據透視表,兩者各有利弊。表因爲其結構就是請求字段的結構,所以可操作性強一些,可以實現很多數據透視表無法實現的功能(儀表盤排序,條件樣式等),但是數據透視表在表現能力上優於表,尤其是維度較多的情況,可以通過一些高級的操作來改善數據透視表的功能(如修改saw腳本)。
總體來說BIEE報表的設計要控制好以下3點:1、彙總和明細分開;2、控制各種不同的查詢路徑;3、考慮查詢效率。

 

biee報表開發總結(二)

因爲我做的報表的數據源是essbase多維數據庫,所以在製作報表時不需要在administration tool當中添加維度和度量。只要直接導入數據源,然後做兩次拖曳就可以了。但是很不幸的是BIEE其實並沒有提供對essbase很好的支持,很多功能都無法實現,或需要調整之後才能實現。
在將文件夾從物理層拖到邏輯層之後,可以看到多維數據庫的邏輯結構,但是展開的時候有些讓人不知所云,因爲biee並不使用essbase大綱中的名稱,而是根據維度層次來命名的。需要注意的是每個維度實際是從第2層(Gen2)開始的(因爲essbase大綱中的實際維度也是從第2層開始算起,第0層是大綱的根,第1層是維度的根),之後的層次可以看到被標爲藍色,這類似於關係型的雪花模型。所以在將文件夾從邏輯層拖到展現層之後就可以把第0層和第1層刪了。維度的每一層只有一個key,它到底是維度值還是它的別名呢?答案是別名,而且我到目前爲止還沒有發現顯示維度值的方法(可能是BIEE不支持)。接着修改一下維度和度量的標籤就可以在answer裏面使用了。但是這樣還是不夠的,當使用到聚合的時候就會出現“發現外部聚合集”的錯誤,原因是BIEE在導入essbase的時候,默認將度量的聚合屬性設置爲外部聚合。只要將外部聚合改爲正確的度量即可,注意在物理層和邏輯層都要改,另外所有度量都要指定一種聚合方式,不能爲none。

 

biee報表開發總結(三)

在answers中的開發難點就在於設計,我在(一)中已經介紹了經驗。但是顯然不可能一開始就設計得十分完美,有的時候會遇到功能實現不了或者效率太低,報表根本刷不出來,這時要麼修改原先的設計,要麼想辦法解決問題。
關於如何提高效率,首先是優化查詢。在BIEE當中,有趣的一點是它首先根據你的設計生成一條SQL查詢語句,然後如果判斷出數據源是多維數據庫,則再將SQL語句在後臺轉化爲MDX語句去執行。轉化的邏輯大致是,select子句中放查詢目標集(對應於MDX中的select字句,但是沒有行列之分),from字句中放cube,where字句中定義如何進行切片。所以在設計時儘量控制請求字段(對應select字句)中的維度字段,不需要的維度不要添加,尤其是大維度,而篩選器(對應where字句)則儘可能的多,這樣切片可以切得小一些。另外查詢的邏輯不要太複雜,不要使用嵌套查詢(篩選器不要使用“根據其他請求結果”)。如果這樣還不行,就只能優化數據源了,對於essbase,可以考慮將一些複雜的動態計算轉爲預先計算後存儲(雖然這樣做很可能會導致佔用的空間增長好幾倍...),可以大大提高效率。
在BIEE中表的樣式控制要比數據透視表靈活得多,基本的樣式都是可控的,所以能用表的時候就儘量用表。關於如何設置樣式,由於比較繁雜而且在(一)中也介紹了一些經驗,所以這裏就不一一介紹了,比較重要的就是條件樣式(只用表能用),可以靈活地控制顯示樣式,另外就是列的隱藏,可以控制哪些列在表中不顯示。
BIEE的訪問控制是比較靈活的,可以使用單獨的鏈接,也可以對標題設鏈接,還可以對值設鏈接,並可以控制是否用於下鑽(在列的交互控制當中設置搜索或鏈接)。BIEE最神奇的就是篩選器中的提示選項,選了這個選項不僅可以使用提示中的選擇還可以用於鏈接的值傳遞。如果一個請求的字段的篩選器使用提示,則通過值鏈接被連接過來的時候,該字段就會被篩選爲進行鏈接的那個值。另外使用提示默認是所有值,所以可以靈活的控制提示字段,比如同一個請求在不同地方使用時,需要的查詢條件可能不同,這時可以通過請求提示來控制查詢條件,此時就必須將所有使用到的查詢條件字段加一個使用請求的篩選器。
不過在awnser中提示篩選器是不會被使用的,如果不使用篩選器就會導致查詢過慢的話,建議在設計報表時先指定一個篩選值,設計完成後再將篩選器的篩選方式改爲請求。
對於實在無法實現的功能,最後一條路就是修改saw腳本了,但是有關BIEE的saw腳本的文檔實在太少...不過通過查看saw腳本倒是可以分析出別人的報表的某些功能是怎麼實現的。實施上saw腳本包含了一個請求的一切,包括顯示樣式和SQL查詢,所以如果要備份或者拷貝一個請求,最簡單的方法就是把saw腳本拷貝下來。如果你想直接修改SQL查詢語句,應該先看一下SQL查詢語句的各個字句存儲在saw腳本中的什麼位置,然後對saw腳本修改,如果直接改下面的SQL框,點了設置SQL的結果是,它產生一個最簡單的SQL語句(沒有任何附加內容),而且把原來你的一切設置都重新初始化(要是你之前沒備份的化,趕緊退出重來吧,千萬不要保存了...)
另外介紹一些經驗。爲了防止字段過多導致一格內無法一行顯示,可以在格式化視圖的附加格式中指定一個很大的寬度,然後選擇單元格向左對齊。如果只想修改請求條件的化,最好不要直接雙擊進入,而是先打開所在的文件夾,然後在面板中選擇修改條件,這樣可以避免一次不必要的查詢。查詢如果異常中斷,即使你在後臺取消了請求,甚至刪除會話,essbase仍然會繼續執行,如果你想進入同一個請求就會報錯,這時你能做的就是等待,等essbase執行完畢才能繼續使用(這也是BIEE與essbase不兼容的一個表現,它導致了BIEE的不穩定,所以要儘量避免沒有篩選控制的查詢)。  

 

 

biee報表開發總結(四)

本文主要講biee中answers和dashboard的開發步驟。在administrator tool搭建好框架之後,接着通
過在瀏覽器中操作的answers和dashboard開發最後的報表顯示。
  首先要做的是添加全局篩選器。對每一個維度都設定一個全局篩選器,每個層次都設定爲請求。
  接着開發請求。按請求在報表中的使用順序一個一個開發請求。先選擇合適的請求字段,再添加全局
篩選器,接着添加測試篩選條件(因爲全局篩選器中的篩選條件都是請求,所以不會在answers中發揮作
用,所以不會和測試篩選條件衝突),然後在表中查看結果,如果要用表顯示則調整字段的順序。如果不
報錯且數據無誤,則返回請求條件面板,添加一些需要計算的字段(這些字段可以通過加入一個原始字段
然後用編輯公式輸入計算表達式產生),設置標題和值的樣式,並添加篩選器。然後在結果面板中開發需
要用到的數據透視表或圖表,同樣需要設置字段順序和顯示樣式和一些其他小功能(比如計算和排序)。
然後在組合佈局中調整佈局,並調整格式化視圖中的值。最後回到條件面板,在列格式中設置交互即鏈接
(建議不要現在做,因爲鏈接最好鏈接到儀表盤,不過如果鏈接的內容很簡單也可以這裏做)。
  然後開發提示。提示要考慮到所有可能的篩選,提示可以儘量多(就像篩選要儘量多),但是必須要
關聯到篩選器。提示的輸入方式很重要,必須要根據實際需求精心設計。提示之間有關聯的要勾選約束,
這樣可以限制提示的內容。但是biee的約束很噁心,你不能限定某幾個提示有約束,一旦勾選了約束,就
會和所有約束關聯,也就是說如果其他任何一個提示被輸入錯誤的值,它就會報錯。對提示進行分組以防
止一行中提示太多。提示設計完成後一定要預覽一下,看看效果如何,尤其是約束關係。
  這時可以將所有的測試篩選器刪除了。
  然後就可以再dashboard上開發了。首先建一個儀表盤,然後添加提示和請求,不同的請求放在不同
的部分,但是因爲部分只能垂直排列,所以如果要水平排列則必須放在同一個部分,並設置排列方式爲水
平排列,排版的時候要注意,各部分的附加格式的寬度必須一致,否則會出現排版錯誤。
  最後就是甚至權限了,這個很簡單,這裏不介紹了。
  整個開發過程當然不可能按上面的步驟一帆風順地做下來,在開發過程中經常會遇到需求變更和一些
意外的結果,所以整個開發過程應該是一個循環迭代的過程,不斷地完善,最後使得開發出來的報表十分
好用而且能夠從各方面反映這個報表應該反映的內容。

 

本文引用:http://christolee.blog.ccidnet.com/blog-htm-do-list-uid-305712-type-blog-dirid-32231.html

 

發佈了62 篇原創文章 · 獲贊 3 · 訪問量 25萬+
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章