數據倉庫需求定義

數據倉庫系統是一個信息傳遞系統。它不是一個關於技術的系統,而是解決用戶問題和麵向用戶提供戰略信息的系統。在需求定義階段,重點是用戶需要哪些信息,而不是你如何提供這些信息。

1. 維度分析

建立數據倉庫與建立操作型系統在很多方面有很大的不同,特別是在需求收集階段。適合操作型系統的收集需求的傳統方法將不再適合數據倉庫。

在向操作型系統提供需求信息的方面,用戶可以告訴你關於所需功能、信息內容、使用方式等準確細節。在這方面,數據倉庫系統有很大的不同。用戶不能清楚的定義他們的需求。他們不能準確定義他們真正想從數據倉庫得到哪些信息,也不能說明他們如何使用和處理這些信息。

數據倉庫定義需求的整個過程就是如此模糊。你可以收集公司整個商業的數據。你可以參考行業的實踐經驗,收集指導日常決策的一些商業規則,可以瞭解產品是如何開發和銷售的。但是這些對於確定需求細節來說都太籠統了。

2. 商業維度層次和分類

當用戶根據商業維度分析指標的時候,他們通常希望首先看到總數,然後是各個層次的細節數據。用戶在這裡所做的就是穿過商業維度的不同層次,得到不同細節程度的數據。例如,用戶首先看到了全年的總體銷售數據,然後轉到季度層次,看了每個季度的銷售情況之後,用戶更進一步的查看每個月的數據。這裡的時間維度的層次由年、季度和月份組成。這種維度層次就是我們在分析中向下層鑽取的路徑。

在每一個主要的商業維度中,都有對分析有用的數據元素的分類。在時間維度中,你會設置一個數據元素來表示某天是否為假日。這個數據元素可以幫助分析,假期的銷售情況與其他日子相比有什麼不同。同樣,在產品維度中,你也想要對產品包的類型進行分析。產品包的類型就是產品維度中的數據元素。時間維度中的假日標誌和產品維度中的產品包類型在這些維度中不是必須的維度層次,這樣的數據元素可以稱為分類。

3. 收集需求的方法

誰是能夠使用數據倉庫信息的用戶?你從哪裡收集用戶的需求?

3.1 收集需求列表

數據元素:事實類型、維度

根據時間記錄的數據

從源系統進行數據抽取

商業規則:特性、範圍、領域、操作記錄

3.1 需求收集方法

(1)採訪,一對一或在一個小團體內;(2)聯合應用程序設計(JAD)會議

3.1.1 採訪

數據倉庫需求定義

採訪內容

當前信息來源

哪一個操作型系統產生與重要商業主題相關的數據?

支持這些主題的計算機系統有什麼類型?

在已有報表和在線查詢中傳遞的是什麼樣的信息?

現有信息傳遞系統的細節程度是怎樣的?

主題領域

對於分析最有價值的主題領域是哪些?

商業維度是哪些?有哪些層次?

制定決策的商業分區是什麼?

不同地區需要的是全球信息還是隻需要當地信息來制定決策?還是兩者混合?

只在特定的區域供應特定的商品和服務嗎?

關鍵性能指標

商業單位的表現是如何衡量的?

哪些是關鍵的成功因素?如何監控?

這些關鍵指標是如何出現的?

所有市場都是用這個方式衡量嗎?

信息頻率

決策支持所需的數據更新頻率是多少?時間間隔是多長?

每種分析與不同時間的標準對比如何?

數據倉庫中的信息需求的時間線是什麼?

作為需求定義的初始文檔,準備採訪提綱時可以包括以下內容:

1. 用戶資料

2. 背景和目標

3. 信息需求

4. 分析需求

5. 當前使用的工具

6. 成功標準

7. 有用的商業指標

8. 相關商業維度

3.1.2聯合應用程序設計

通過群體會議的形式為了開發目標而聚集在一起。它是一個聯合開發計算機應用的方法,用戶和IT專業人員通過一種有組織的方式組合在一起。


分享到:


相關文章: