資料倉庫 - 交付流程

資料倉庫從來都不是靜態的；它會隨著業務的擴充套件而發展。隨著業務的發展，其需求不斷變化，因此必須設計資料倉庫來適應這些變化。因此，資料倉庫系統需要具有靈活性。

理想情況下，應該有一個交付流程來交付資料倉庫。但是，資料倉庫專案通常會遇到各種問題，這些問題使得難以按照瀑布方法嚴格有序的方式完成任務和交付成果。大多數情況下，需求並未完全理解。只有在收集和研究所有需求後，才能完成架構、設計和構建元件。

交付方法

交付方法是為交付資料倉庫而採用的聯合應用開發方法的一種變體。我們已經將資料倉庫交付流程分階段進行，以最大限度地降低風險。我們在這裡將討論的方法不會縮短整體交付時間，但可以確保透過開發流程逐步交付業務利益。

注意 - 交付流程被分解成多個階段，以降低專案和交付風險。

下圖解釋了交付流程中的各個階段：

資料倉庫是需要業務流程來產生效益的戰略性投資。需要IT戰略來獲得和保留專案的資金。

商業案例的目的是評估使用資料倉庫應該獲得的業務效益。這些效益可能無法量化，但需要明確說明預計效益。如果資料倉庫沒有明確的商業案例，那麼在交付過程中某個階段，業務往往會遇到信譽問題。因此，在資料倉庫專案中，我們需要了解投資的商業案例。

組織在確定解決方案之前，會嘗試資料分析的概念，並瞭解擁有資料倉庫的價值。這是透過原型設計來實現的。它有助於瞭解資料倉庫的可行性和效益。小規模的原型設計活動可以促進教育過程，只要：

為了儘早釋出並交付業務效益，需要記住以下幾點：

為了提供高質量的交付成果，我們應該確保理解總體需求。如果我們理解短期和中期的業務需求，那麼我們可以設計一個解決方案來滿足短期需求。然後可以將短期解決方案發展為完整的解決方案。

在此階段確定以下方面：

此階段需要交付一個滿足長期需求的整體架構。此階段還將交付必須在短期內實施才能獲得任何業務利益的元件。藍圖需要確定以下內容：

在此階段，將生成第一個生產交付成果。此生產交付成果是資料倉庫的最小元件。此最小元件增加了業務效益。

這是將所需其餘歷史資料載入到資料倉庫的階段。在此階段，我們不新增新的實體，但可能會建立額外的物理表來儲存增加的資料量。

讓我們舉個例子。假設構建版本階段交付了一個包含 2 個月曆史資料的零售銷售分析資料倉庫。此資訊將允許使用者僅分析近期趨勢並解決短期問題。在這種情況下，使用者無法識別年度和季節性趨勢。為了幫助他做到這一點，可以從存檔中載入過去 2 年的銷售歷史記錄。現在，40GB 的資料擴充套件到 400GB。

注意 - 備份和恢復過程可能會變得複雜，因此建議在單獨的階段執行此活動。

在此階段，我們配置一個用於操作資料倉庫的特設查詢工具。這些工具可以生成資料庫查詢。

注意 - 建議在資料庫發生重大修改時不要使用這些訪問工具。

在此階段，運營管理流程將完全自動化。這些將包括：

在此階段，資料倉庫將擴充套件以滿足一組新的業務需求。可以透過兩種方式擴充套件範圍：

注意 - 由於此階段涉及大量工作和複雜性，因此應單獨執行。

從交付流程的角度來看，需求始終是可變的。它們不是靜態的。交付流程必須支援這一點，並允許將這些更改反映到系統中。

這個問題是透過圍繞業務流程中資料的使用來設計資料倉庫來解決的，而不是現有查詢的資料需求。

該架構旨在改變和發展以匹配業務需求，該流程作為一個偽應用程式開發流程執行，其中新的需求不斷被輸入到開發活動中，併產生部分交付成果。這些部分交付成果會被反饋給使用者，然後進行重新設計，確保整個系統不斷更新以滿足業務需求。

列印頁面