在使用Cognos的ReportNet的時候,一個很重要的功能是設置聚合函數屬性。
聚合函數屬性用得比較多的是“合計”和“已計算”屬性。
這些屬性最終是在報表展示的時候發(fā)揮作用的,這點可以通過比較運行查詢和運行報表的情況來證明。
比如在開發(fā)過程中經常會遇到要將一個整體的數據集從縱向到橫向進行展開。比如,一個數據集包括:

最后報表展示的時候你可能希望得到的樣式是:

這種情況可以通過交叉表來自動完成,前提是成績字段上要設置“合計”的聚合函數屬性。它告訴ReportNet在展示報表的時候遇到行和列的值都一樣的若干條記錄的時候的處理方式。試試不使用交叉表,而使用列表的方式實現該需求會對這個屬性了解得更加深刻。用列表的時候是利用CASE語句分離各個字段來實現的,通過比較查詢的和報表的結果可能更容易想象這個屬性的工作。
而一些自建的計算字段一般聚合屬性都設置為“已計算”,這樣才能得到計算的結果。實際開發(fā)中發(fā)現“已計算”的優(yōu)先級是比較低的,Cognos認為你已經定義好了計算公式,可以放到最后進行計算。所以,如果這個計算字段來自于列表中其他字段的計算結果,而這些被用到的字段上有合計的話,這個計算的結果會是合計之后的值進行的計算。
當然也會有聚合屬性的設置和記錄的內容相沖突而導致失效的情況。這只能視實際情況進行調整。
--------------------
Cognos 對很多東西進行了封裝,所以很多地方讓你覺得是既強大又煩人的……這是方便和靈活這對矛盾不可調和的結果 。。。
對數據集的內容進行加工形成報表展示需要的形式不可避免的要用到Cognos提供的函數。隨著應用的不同,Cognos的函數還是很值得挖掘的,也應該去了解。因為Cognos不會認那個函數列表之外的函數。而且這些函數在使用上也是有限制的,特別是在過濾器里使用函數的時候會收到很多的限制。
除了普通的運算函數外,匯總函數的使用也是比較多的,比如你可能會經常需要計算百分比什么的,那你可能需要對某個字段進行求和,然后在一一計算百分比。
函數列表中的“匯總函數”和“成員函數”雖然大多關鍵字是一樣的,但是語法和實用范圍是有很大區(qū)別的。一般情況下,你可以使用兩種匯總函數的語法和成員函數的語法達到相同的結果,雖然他們的實現機制可能是不同的。這兩個部分從名字上可以有一個大致的區(qū)分,一個是用于整體數據集的,一個是用于數據集成員的。也可以從語法上試著去區(qū)分它們,比如total函數,在“匯總函數”中基本語法是total(<**> for <**> ),在“成員函數”中是total(<**> within set <**>),也就是說在用后者的語法可以指定更詳細的作用范圍,一個set的范圍。
當然,既然分開而存在就肯定有不交叉的作用地方。比如,你有一個聚合屬性為“已計算”的字段A,這個字段可能是來自其他兩個字段的比率,然后你可能想對這個A字段使用函數得到字段C,比如說匯總(total),如果你使用total(A for report)或其他的“匯總函數”中total的語法,你可能會發(fā)現結果為0,也就是說這個匯總沒有使用你想要的A字段的值,而使用“成員函數”的語法你卻可以獲得正確的結果,比如total(A within set B),報表會在聚合范圍內,也就是B,對A進行一個total。產生這種結果和Cognos底層的機制和解析優(yōu)先級有關系,筆者也沒有機會能了解到…… (使用工具就是這樣。。。)。有些時候這種不對使用者開放的機制會導致你的方案功虧一簣!~~比如說上文中的字段C,這個字段可能是要通過CASE語句處理不同情況的,例如:case B = **** then C …… 這時候你運行查詢會發(fā)現Cognos報錯,這應該是語句中的判斷條件和C字段指定了within set沖突導致的,就算判斷條件中用到的和C字段中用到的字段不是同一個,也可能會產生一樣的問題,所以我認為,這應該是由實現的邏輯帶來的問題。
如果你的開發(fā)設計像上面提到的那樣,一步步走向胡同深處,我勸你最好盡早停下來思考一下,因為有時候這并不是唯一的做法,像我就是想躲避麻煩,所以一步步變得復雜。。。最后懶得弄了,回來麻煩那么一下,多弄個查詢就了事了……(兄弟,鉆到花崗巖就要看看夠不夠時間和頭夠不夠硬了~~)
http://smalc.net.blog.163.com/blog/static/1682328200872642213546/ |