Cognos設計開發規範 第二階段

2021-07-31 18:26:01 字數 5068 閱讀 2252

資料中心專案

西安美林電子****

二○○九年七月一日

版本歷史

目錄1 引言 1

1.1 編寫目的 1

1.2 背景 1

1.3 參考資料 1

2 設計原則 1

2.1 合理性 1

2.2 效能 1

2.3 可擴充套件性 2

3 設計開發流程 2

3.1 總體設計 2

3.2 framework模型開發 6

3.3 transformer模型開發 7

3.4 頁面開發 8

4 最佳實踐總結 8

4.1 展現難易程度判斷 8

4.2 具體實踐經驗 10

引言1.1 編寫目的

本文旨在對bi展現開發過程進行規範性指導,為了進一步提高開發的質量和效率,現需對設計開發的規範進行進一步深化,使得開發人員可以通過此規範清晰開發的邏輯思路、加強開發的質量意識。

1.2 背景

通過第一階段基本開發規範的執行,專案組成員的開發規範意識已得到了加強;現需要從更高層次對設計開發過程提出規範性的指導方案,以進一步提高開發質量和效率。

1.3 參考資料

《cognos設計開發規範(20090115).doc》

設計原則

1.4 合理性

◆ 模型設計要按照主題域在業務上進行邏輯劃分;

◆ 頁面開發符合業務要求、邏輯合理。

1.5 效能

◆ 頁面響應速度滿足系統的效能要求;

1.6 可擴充套件性

◆ 模型設計要滿足最大化業務需求;

◆ 模型採用星形結構。

設計開發流程

1.7 總體設計

1.7.1 分析展現需求

1) 維度資料分析

經過對展現需求的分析理解,明確展現涉及到哪些維度,每個維度需包括哪些資料;

2) 事實資料分析

經過對展現需求的分析理解,明確展現涉及到哪些事實資料,模型設計是否需要包括同期值、累計值、同比、環比(目前在etl過程中進行處理)等。

3) 舉例說明

展現需求如下:

圖1我們需要從中得到如下資訊:

◆ 維度:時間、單位(要結合具體業務挖掘)、指標等;

◆ 事實資料:本年累計、上年同期累計、預算值;增減額、增減率和完成預算資料可由以上三個資料計算獲得,可以放在庫中也可放在framework模型中計算,為了提高效率目前採用的是在庫中計算的方式。

1.7.2 資料來源分析

經過對資料來源的分析,明確展現涉及到哪些資料來源、資料來源的提供方式、表結構、資料量及更新頻率等,從而明確資料來源和展現需求的符合度。

舉例說明:

如圖1所示的需求,我們需要了解資料來源以什麼方式提供(excel報表還是資料庫表)、具體的資料結構是什麼樣子、資料量大小及資料更新頻率是多少。

1.7.3 建模方式

1) cognos建模方式選擇

若展現資料量不大、時效性要求不高,則可以通過設計cube實現展現;否則,直接採用framework模型實現展現。

2) 維度

維度需要包括主鍵、編碼、名稱、層級(目前沒有層級結構)、排序號、起止時間和有效標誌位等資訊。

如下圖:

3) 事實資料

事實表設計必須包括展現所需的資料字段(細節性或彙總型),包括累計值、同期值、同比和環比等。

舉例說明:

如圖1所示的需求,事實表需要包括本年累計、上年同期累計、預算值,以及可由以上三個資料計算獲得的增減額、增減率和完成預算的資料。如下圖:

4) 關係

在framework模型中建立維度與事實資料的關係,維度表與事實表通常為一對多的關係;彙總資料採用星形模型結構,需展現的細節性資料可能採用雪花型模型結構。

舉例說明:

如圖1所示的需求,模型設計如下:

從展現需求到模型:

5) 業務層實現

業務層設計有如下兩種方式:

◆ 根據物理層模型每張表對應有乙個查詢主題(query subject);

◆ 根據需求再結合具體物理模型將需要展現資訊集中設計到乙個查詢主題中;

舉例說明:

從物理層模型到業務層:

6) 展現設計

◆ 了為提高展現效率,對於無查詢條件等符合靜態報表要求的需採用靜態報表進行展現;

◆ 為了提高頁面執行速度,對於多個頁面元件(如列表、折線圖、柱圖)能夠使用同乙個查詢的情況,必須使用同乙個查詢(query)。

1.8 framework模型開發

1.8.1 資料來源分析

1) 結合展現需求和dm資料庫模型明確每個模組需要的相關庫表;

2) 必要時可以採用檢視、儲存過程作為framework模型的資料來源。

1.8.2 資料關係

1) 在物理層採用資料夾來劃分每個模組,匯入每個模組的表後在framework中建立維度表與事實表的關係;

2) 根據展現需求基於物理層相關表建立業務層,相當於對維度表和事實表做聯合查詢。

1.8.3 其他操作(計算、過濾等)

1) 盡量將需要計算的資料項計算過程、一些公共資料項的設計放在framework模型設計階段進行(比如,將時間欄位年和月組合成乙個日期型別的字段、簡單計算(增減率、計畫完成率)等),這樣可以提高頁面終端的展現速度,並可以避免頁面開發設計時的大量重複性工作。

2) 對需要處理(如擷取等)的字段放在framework模型中進行;

3) 能在framework中進行資料過濾的過濾條件最好在framework中設定。

4) 每個分析盡可能採用星形模型(乙個事實表和多個維度表關聯),表結構模型不宜過於複雜;

5) framework中的模型物理層和資料庫模型基本保持一致,需要含有必要的度量字段(比如上月值、上年同期值、上年同期累計值等),這些字段需要在etl過程中進行計算(這樣做就可以在一定程度上降低bi模型設計和前台展現的難度,同時也提高了前台頁面的展現速度);

6) 充分考慮與模型中每個分析相對應的bi展現需求,模型的每部分必須滿足相關的展現需求,這樣可以避免「前台展現做了一部分後發現模型不能滿足其他展現」等情況的出現(若出現這種情況就會導致大量的返工);

7) 頁面設計時涉及到增減率、無油化率和計畫完成率等百分比資料需要基於某個維度求彙總的情況目前不能實現(頁面彙總只是簡單的相加),通常都是在etl過程中進行資料處理,設計模型時需要考慮到類似情況並和資料庫模型設計人員、etl人員及時溝通達成共識 ;

8) 定義資料報package時,需要把分析的物理層隱藏掉,這樣做可以對相關的庫表結構起到一定的保密作用,而且還可以避免在頁面設計時引起不必要的混亂;

9) 當與展現相關資料的資料量很大時,模型設計要避免在頁面設計時頻繁使用「join」或「union」的現象發生,否則會大大降低頁面的展現速度;

10) 資料庫模型中維度表的劃分必須和bi展現需求所需的維度一致,避免把展現中所需的維度作為資料庫模型中事實表的字段,否則在bi模型設計時會很麻煩,甚至需要寫資料庫檢視來實現。

11) 設計framework模型時不要將庫表關係匯入;

1.9 transformer模型開發

1.9.1 資料來源

資料來源有多種型別,目前採用package型別(較常用);

1.9.2 維度

1) 在進行cube模型設計(transformer model)時,維度(dimension) 必須具有清晰的層次結構,以免在頁面設計時引起不必要的錯誤;

2) 必須在進行維度設計時,對必要的維度(如單位、電壓等級等需求中明確要求排序的)進行排序處理,這樣可以大大減少頁面設計時的排序工作。

3) 維度最底層要對應資料來源窗格中的乙個列;

4) 要注意維度層屬性的設定,特別是源source屬性associations的設定,因為對於每個層我們通常需要顯示乙個值而在過濾、鑽取時使用另乙個值。

1.9.3 度量

1) 只能是數字型的字段才能作為度量;

2) 在可以根據需要自定義計算度量;

1.9.4 cube

發布cube時,需要注意cube路徑的填寫,伺服器不同則路徑就不同。

1.9.5 安全

主要為使用者訪問許可權控制

1.9.6 更新

根據資料要求設定cube的更新頻率

1.10 頁面開發

1.10.1 report studio

1) 介面元件

採用符合展現需求、執行高效的頁面元件進行展現實現;頁面元件一般情況下在展現需求中已確定;列表(list)的執行效率要高於交叉表(crosstable)。

2) mdx

1.10.2 query studio

無特殊要求,利用該工具結合具體業務及展現要求進行即席查詢報表製作

1.10.3 analysis studio

無特殊要求,利用該工具結合具體業務及展現要求進行多維分析實現

最佳實踐總結

1.11 展現難易程度判斷

1. 該部分工作要求工作人員具有一定的開發經驗才行,也正是我們bi開發人員應該具有的重要能力,所以從一開始就要有意識地培養、訓練、努力提高這種能力。

2. 舉例分析

a) 簡單實現:直接利用頁面展現的設計元素(列表、交叉表和各種圖形等),經過拖拉字段、求和、分組和過濾等就可以實現需求。

如以下列表,資料庫模型涉及到四個表,時間維度、單位維度、勞動生產率分析維度和乙個事實表,在進行頁面設計時可以直接使用交叉表,單位作為行維度,勞動生產率分析作為列維度,事實表的事實資料字段作為交叉部分的度量,用時間進行條件過濾就可以了。

下圖和列表類似,經過直接拖拉相關維度、度量,並進行相應設定、過濾等就可以實現。

b) 較複雜實現:不能直接利用頁面設計元素通過簡單設定實現,需要進行多個維度資料的連線、求並集、求交集和編寫sql語句等。

如以下列表,資料庫模型涉及到五個表,單位維度、時間維度、人員型別維度、職工分析維度和乙個事實表,該列表的列維度需要把兩個維度進行聯合(求並集),否則是查不出資料的。在求並集時,過濾條件最好在各個維度資料的查詢中進行設定,而不要在聯合後的查詢中進行過濾,這樣可以提高執行效率;需要注意求並集時兩個維度資料之間的關聯關係。

下圖和該列表類似,需要把兩個維度資料進行聯合(求並集)才能實現。

c) 不能實現:由於資料庫模型設計、cognos實現技術等原因導致部分需求不能很好的實現。

高2019級2023年春期高二數學第二階段考試題

高2012級2011年春期第二階段考試題 一 選擇題 本大題共12小題,每小題5分,共60分 在每小題給出的四個選項中,只有一項是符合題目要求的 1 空間四邊形abcd中,e f g h分別是四條邊上異於頂點的四點,直線eg和fh的位置關係是 a 異面 b 相交 c 相交或異面 d 平行或異面 2 ...

1109高起專第二階計算機資訊管理

江南大學現代遠端教育2012年下半年第二階段測試卷b 考試科目 作業系統 第5章至第7章 總分100分 時間 90分鐘 學習中心 教學點 批次層次 專業學號身份證號 姓名得分 一 名詞解釋 12分 1 系統抖動 2 置換演算法 3 儲存保護 4 虛擬儲存器 二 競爭與死鎖有什麼區別?7分 三 三個程...

工業大學電子工程設計 二階實驗報告

電子工程設計報告 題目 溫度測量系統 閉環溫度控制系 統設計專業 電子科學與技術 小組 7 姓名 學號 袁彬 11023221 賴力 11023222 指導教師 高新 完成日期 2013.12.12 在上學期我們完成了溫度控制系統的第一階段,在這一階段,我們完成了焊接包括電源板 驅動器和變送器在內的...