1 文章結構腦圖

第11章 數據倉庫和商務智能 10%.png

2 基本概念

2.1 商務智能

商務智能這個術語有兩層含義。 <font color = green>P292</font>

• 第一層含義,商務智能指的是一種理解組織訴求和尋找機會的<font color=red>數據分析活動</font>。數據分析的結果用來提高組織決策的成功率。
• 第二層含義,商務智能指的是支持這類數據分析活動的<font color = red>技術集合</font>。決策支持工具、商務智能工具的不斷進化,促成了數據查詢、數據挖掘、統計分析、報表分析、場景建模、數據可視化及儀表板等一系列應用,它們被用于從預算到高級分析的方方面面。

2.2 數據倉庫

數據倉庫有兩個重要組成部分: 一個集成的決策支持<font color = red>數據庫</font>和與之相關的用于收集、清理、轉換和存儲來自各種操作和外部源數據的<font color = red>軟件程序</font>。 <font color = green>P292</font>
數據倉庫建設還會包括相依賴的數據集市,數據集市是數據倉庫中數據子集的副本。 <font color = green>P292</font>
從廣義上來說,數據倉庫包括為任何支持商務智能目標的實現提供數據的數據存儲或提取操作。 <font color = green>P292</font>

2.3 數據倉庫建設

數據倉庫建設指的 是<font color = red>數據倉庫中數據的抽取、清洗、轉換、控制、加載等操作過程</font>。數據倉庫建設流程的重點,是<font color = red>通過強制業務規則、維護適當的業務數據關系,在運營的數據上實現一個集成的、歷史的業務環境</font>。數據倉庫建設還包括<font color = red>與元數據資料庫交互的流程</font>。 <font color = green>P292</font>

傳統意義上建設主要關注結構化數據，現在 也包含半結構化數據和非結構化數據。 <font color = green>P293</font>

2.4 數據倉庫建設的方法

兩位思想領袖比爾·恩門(BillInmon)和拉爾夫·金博爾( RalphKimball) 分別使用范式建模和多維建模來完成數據倉庫建模。<font color = green>P293</font>

比爾·恩門在《數據倉庫》(Building theDataWarehouse )中定義: <font color = red>數據倉庫是在企業管理和決策中面向主題的、集成的、與時間相關的、不可修改的數據集合</font>。

拉爾夫·金博爾在《數據倉庫工具箱》(The DataWarehouse Toolkit) 中提出: <font color = red>主張自下而上(DMDW)的方式，力推數據集市建設，他定義為“為查詢和分析定制的交易數據的副本 。 ”</font>

參 考 : https://blog.csdn.net/Luomingkui1109/article/details/91349335 ; https://dataclub.blog.csdn.net/article/details/118663623;

他們遵循的核心理念相似: <font color = green>P293</font>

• 1)數據倉庫存儲的數據來自其他系統。
• 2)存儲行為包括以提升數據價值的方式整合數據。
• 3)數據倉庫便于數據被訪問和分析使用。
• 4)組織建設數據倉庫,因為他們需要讓授權的利益相關方訪問到可靠的、集成的數據。
• 5)數據倉庫數據建設有很多目的,涵蓋工作流支持、運營管理和預測分析。

2.5 企業信息工廠（Inmon）

企業信息工廠(Corporate Information Factory，CIF): Inmon關于數據倉庫的組成是這樣描述的:“<font color = red>面向主題的、整合的、隨時間變化的、包含匯總和明細的、穩定的歷史數據集合</font>”。 <font color = green>P293</font>

這種概念描述也適用于CIF,并指出了數據倉庫和業務系統的區別。 <font color = green>P293</font>

1. 面向主題的。數據倉庫是基于主要業務實體組織的,而不關注功能或應用
2. 整合的。數據倉庫中的數據是統一的、內聚的。因為數據是整合的,數據倉庫不是簡單的運營數據的副本。相反,數據倉庫變成了一個數據記錄的系統。
3. 隨時間變化的。數據倉庫存儲的是某個時間段的數據。數據倉庫中的數據像快照一樣,每一張快照都反映了某個時點的數據狀態。
4. 穩定的。在數據倉庫中,數據記錄不會像在業務系統里那樣頻繁更新。相反,新數據只會追加到老數據的后面。
5. 聚合數據和明細數據。數據倉庫中的數據包括原子的交易明細,也包括匯總后的數據。
6. 歷史的。業務系統的重心是當前的數據。數據倉庫還包括歷史數據,通常要消耗很大的存儲空間。

Inmon、Claudia Imhoff和Ryan Sousa等是在CIF的語境下描述數據倉庫的。CIF的組成部分包括: <font color = green>P294</font>

1. 應用程序。
2. 數據暫存區。
3. 集成和轉換。
4. 操作型數據存儲 (ODS)。
5. 數據集市。
6. 操作型數據集市(OpDM)。操作型數據集市是專注于運營決策支持的數據集市。直接從操作型數據存儲而不是從數據倉庫獲取數據，具有與操作型數據存儲相同的特性:包含當前或近期的數據，這些數據是經常變化的。
7. 數據倉庫。單向流向數據集市。
8. 運營報告。運營報告從數據存儲中輸出。
9. 參考數據、主數據和外部數據。

業務系統到數據集市，數據流程過程的變化: <font color = green>P295</font>
1)目標:功能執行——>數據分析。2)用戶:業務人員——>決策人員。3)使用:固定操作——>即席查詢。4)時間:即時要求高——>不高。 5)影響面:數據少——>涉及更多數據。

數據倉庫和數據集市的數據與應用程序中的數據不同: <font color = green>P295</font>

1. 數據的組織形式是==按主題域而不是按功能需要==。
2. 數據是==整合的數據,而不是“孤立”的煙囪數據==。
3. 數據是==隨時間變化的系列數據,而非僅當前時間的值==。
4. 數據在數據倉庫中的==延遲比在應用程序中高==。
5. 數據倉庫中提供的==歷史數據比應用程序中提供的歷史數據多==。

2.6 多維數據倉庫（Kimball）

Kimball將數據倉庫簡單地定義為“專為查詢和分析而構建的事務數據的副本”。多維模型旨在方便數據使用者理解和使用數據, 同時還支持更優的查詢性能。它不是以實體關系模型的規范化要求組織的。 <font color = green>P295</font>

多維模型通常稱為星型模型,由事實表(包含有關業務流程的定量數據,如銷售數據)和維度表(存儲與事實表數據相關的描述性屬性, 為數據消費者解答關于事實表的問題,如這個季度產品X賣了多少)組成。事實表與許多維表關聯,整個圖看上去像星星一樣。 <font color = green>P296</font>

多個事實數據表將通過“總線”共享公共的維度或遵循一致性的維度,類似于計算機中的總線。通過插入遵循維度的總線,可以將多個數據集市集成為企業級的數據集市。 <font color = green>P296</font>

Kimball的數據倉庫比Inmon的數據倉庫的可擴展性更強。數據倉庫包含數據暫存和數據展示區域的所有組件。
Kimball 的數據倉庫分為業務源系統、數據暫存區域、數據展示區域、數據訪問工具四個部分。 <font color = green>P296</font> 見下圖11-3

數據倉庫的總線矩陣展示 的是<font color = red>生成事實數據的業務流程</font>和<font color = red>表示維度的數據主題域的交匯</font>。獨立于技術，用于表示數據倉庫/BI 系統長期數據的內容需求，幫助組織確定可管理的開發工作范圍。<font color = green>P296</font> 見下表11-4

2.7 數據倉庫架構組件

數據倉庫環境包括一系列組織起來以滿足企業需求的架構組件。 包括源系統，數據集成，數據存儲區域等。 <font color = green>P298</font> 見下圖 11-5
大數據方案一般會先加載數據，再處理，即 ELT。

1. 源系統。 包括要流入數據倉庫/商務智能環境的業務系統和外部數據。<font color = green>P297</font>

2. 數據集成。 數據集成包括抽取、轉換和加載(此三者英文首字母縮寫為E、T、L,通常直接這把三者稱為ETL)、數據虛擬化以及將數據轉換為通用格式和位置的其他技術。<font color = green>P298</font>

3. 數據存儲區域 <font color = green>P298</font>
   數據倉庫包含多個不同用途的存儲區域:

   1. 暫存區。介于原始數據源和集中式數據存儲庫之間的中間數據存儲區域。
   2. 參考數據和主數據一致性維度。
   3. 中央數據倉庫。
      數據結構的設計元素包括:
      1 基于性能考慮而設計的業務主鍵和代理主鍵之間的關系。
      2 創建索引和外鍵以支持維 度表。
      3 用于檢測、維護和存儲歷史記錄的變更數據捕獲(Change Data Capture，CDC)技術。
   4. 操作型數據存儲 ODS。操作型數據存儲包含一個時間窗口的數據而不是全部歷史記錄，因此 可以比數據倉庫有更快地刷新頻率。
   5. 數據集市。面向特定主題域、單個部門或單個業務流程。
   6. 數據立方體 Cubes。3 種經典的支持在線分析處理系統 OLAP:基于關系、基于多維及混合型存儲結構。

2.8 加載處理的方式

數據倉庫建設涉及兩種主要的數據集成處理類型：歷史數據加載和持續不斷的數據更新。<font color = green>P299</font>

1. 歷史數據 <font color = green>P299</font>

   1. Inmon 類型的數據倉庫建議所有數據存儲在單個數據倉庫層中。這一層中存儲已清洗過的、標準化的和受管控的原子級數據。
   2. Kimball 類型的數據倉庫建議，數據倉庫由包含已清洗過的、標準化的和受管控數據的部門級數據集市合并而成。數據集市將在原子級別存儲歷史記錄，由一致性維度表和一致性事實表提供企業級信息。
   3. Data Vault，作為數據暫存處理的一部分，同樣進行數據清洗和標準化。歷史數據以規范化的原子結構存儲，每個維度定義了代理鍵(Surrogate key)、主鍵(Primary key)、備用鍵(Alternate key)

2. 批量變更數據捕獲 <font color = green>P300</font>
   數據倉庫是通過每天晚上的批處理窗口進行一次數據加載服務。因為不同源系統可能需要不同的變更捕獲技術，所以加載過程可以包含各種變更檢測。各種變更數據捕獲技術之間的差異。 見下表11-2

3. 準實時和實時數據加載 <font color = green>P300</font>
   操作型商務智能(或運營分析)的出現推動了更低延遲的需求,將更多實時的或準實時的數據集成到數據倉庫中,新的架構方法隨之出現,用于處理易變化的數據。
   批處理的替代方案解決數據倉庫中對數據可用性延遲越來越短的要求,有 <font color = red>涓流式加載、消息傳送和流式傳送三種主要的替代方案</font>,它們在等待處理時的數據累積位置不同。

   1. <font color = red>涓流式加載(源端累積)</font>。與夜間窗口批量加載不同,涓流式加載是以更頻繁的節奏(如每小時甚至每5分鐘)或者以閾值的方式(如每300個事務,每1 G數據)進行批量加載。這
   2. <font color = red>消息傳送(總線累積)</font>。當極小的數據報(消息、事件或事務)發布到消息總線時,實時或接近實時的消息交互就非常有用。
   3. <font color = red>流式傳送(目標端累積)</font>。與在源端定時或按閥值加載不同, 目標端系統用緩沖區或隊列方式收集數據,并按順序處理。

3 語境關系圖

3.1 定義

數據倉庫(Data Warehouse，DW): 始于 20 世紀 80 年代，發展于 20 世紀 90 年代，后與商務智能(Business Inteligence,BI)作為業務決策主要驅動力協同發展。賦能組織將不同來源的數據整合到公共的數據模型，整合后的數據能為業務運營提供洞察，為企業決策支持和創造組織價值開辟新的可能性。
數據倉庫還是減少企業建設大量決策支持系統(Decision Support System,DSS)的一種手段,大部分DSS系統使用的都是企業中同樣的核心數據。<font color = red>企業數據倉庫提供了一種減少數據冗余、提高信息一致性,讓企業能夠利用數據做出更優決策的方法。
數據倉庫是企業數據管理的核心</font>。<font color=green>P290</font>

3.2 目標

數據倉庫的建設目標: 1)支持商務智能活動。2)賦能商業分析和高效決策。3)基于數據洞察尋找創新方法。<font color=green>P291</font>

數據倉庫建設應遵循原則: <font color=green>P291-292</font>

1. <font color = red>聚焦業務目標</font>。用于最優級的業務并解決它。
2. <font color = red>以終為始</font>。以業 務優先級和最終成果驅動倉庫創建。
3. <font color = red>全局性的思考和設計，局部性的行動和建設</font>。
4. <font color = red>總結并 持續優化，而不是一開始就這樣做</font>。
5. <font color = red>提升透明度和自助服務</font>。
6. <font color = red>與數據倉庫一起建立元數據</font>。 DW 的成功關鍵是能準確解釋數據。
7. <font color = red>協同</font>。與其他數據活動協作，尤其是數據治理、數據質 量和元數據管理活動。
8. <font color = red>不要千篇一律</font>。為每種數據消費者提供正確的工具和產品。

3.3 業務驅動因素

數據倉庫建設的主要驅動力是 <font color = red>運營支持職能、合規需求和商務智能活動</font>(盡管不是所有的商務智能活動都依賴倉庫數據)。 <font color=green>P291</font>

3.4 輸入

3.5 活動

活動: 1.理解<font color = red>需求</font>。2.定義和維護 DW 和 BI <font color = red>架構</font>。3.<font color = red>開發</font>數據倉庫和數據集市。4.<font color = red>加載</font>數據倉庫。 5.<font color = red>實施</font> BI 產品組合。6.<font color = red>維護</font>數據產品。

【活動 1】理解需求 <font color=green>P301</font>

• 首先,要考慮業務目標和<font color = red>業務戰略</font>,確定業務領域并<font color = red>框定范圍;</font>
• 然后,確定并對相關的業務人員進行<font color = red>訪談</font>,了解他們想做些什么和這么做的原因,記錄他們當下關心的具體問題和想要詢問的數據,以及他們如何區分和分類重要信息。
• 在可能的情況下,界定并書面記錄關鍵的性能指標和計算口徑。
• 將需求進行分類并排出<font color = red>優先級</font>,與生產上線相關的排在前面,將與數據倉庫相關的和那些可以等的排在后面。
• 尋找并<font color = red>快速啟動</font>那些簡單且有價值的項目,以便在項目初始發布階段就能獲得產出。

【活動 2】定義和維護數據倉庫/商務智能架構 <font color=green>P301</font>
數據倉庫/商務智能架構應該描述<font color = red>數據從哪里來、到哪里去、什么時候去、為什么要去,以及用什么樣的方式流入數據倉庫。</font>

1. 確定數據倉庫/商務智能<font color = red>技術架構</font>。 應能以<font color = red>原子化的數據處理方式支</font>撐交易級和運營級的報表需求。做好<font color = red>原型設計</font>可以快速證明或駁斥關鍵需求的實現，避免對某些技術或架構進行過大的投入。

2. 確定數據倉庫/商 務智能<font color = red>管理流程</font>。通過協調和集成維護流程進行生產管理，定期向業務團隊發布。<font color = red>建立一個有效的發布流程</font>，確保管理層理解這是一個以數據產品為中心的<font color = red>主動流程</font>，而不是已安裝產品的被動式問題解決方式。

【活動 3】開發數據倉庫和數據集市 <font color=green>P302</font>

數據倉庫/商務智能建設項目有三條并存的構建軌跡:

1. ==<font color = red>支持業務分析所必需的數據</font>==。識別最佳來源、設計規則、處理不合預期數據。
2. ==<font color = red>技術</font>==。支持數據存儲和遷移的后端系統及流程。
3. ==<font color = red>商務智能工具</font>==。數據消費者從已部署的數據產品中獲得有意義的數據洞察所必需的應用套件。

內容:(70%的工作)

1. <font color = red>將源映射到目標</font>。建立轉換規則。確保鏈接有效性或等效性。邏輯數據模型。最困難是確定多系統數據間的鏈接有效性或等效性。
2. <font color = red>修正和轉換數據</font>。數據修正或清理活動的執行標準。糾正域值。源系統應負責數據的修復工作并確保數據正確。<font color = red>樂觀加載策略:</font>創建維度記錄以容納事實數據。<font color = red>悲觀加載策略:</font>事實數據的回收區域。

【活動 4】加載數據倉庫 <font color=green>P303</font>

在所有數據倉庫/商務智能工作中,工作量最大的部分都是數據準備和預處理。描述數據倉庫中所包含的設計決策和原則是數據倉庫/商務智能架構設計的關鍵考量因素。

確定數據加載方法時， 1.要考慮的關鍵因素是數據倉庫和數據集市所需的<font color = red>延遲要求、源可用性、批處理窗口或上載間隔、目標數據庫及時間幀的一致性</font>，還必須解決數據質量處理過程、執行轉換的時間、延遲到達的維度和數據拒絕等問題。2.另一個因素是圍繞變更數據捕獲過程檢測源系統中的數據變更，將這些變更集成在一起，并依時間調整變更。

【活動 5】實施商務智能產品組合 <font color=green>P304</font>

實施商務智能組合是<font color = red>為了在業務部門內部或業務部門之間為正確的用戶社區選定合適的工具,通過協調常見業務流程、性能分析、管理風格和需求找到相似之處。</font>

1. 根據需要給用戶分組。了解用戶組。將工具與用戶組匹配。
2. 將工具與用戶要求相匹配。需要系統資源、技術支持、培訓和架構集成。

【活動 6】維護數據產品 <font color=green>P305</font>

1. <font color = red>發布管理</font>。確保是最佳狀態。
2. 管理數據產品開發<font color = red>生命周期</font>。
3. <font color = red>監控和調優加載過程</font>。了解性能瓶頸和依賴路徑。在需要的地方和時刻使用數據庫調優技術,包括分區、備份調優和恢復策略調整。數據歸檔是數據倉庫構建中的一個難題。
4. <font color = red>監控和調優商務智能活動和性能</font>。商務智能監控和調優的最佳實踐是定義和顯示一組面向客戶滿意度的指標,如平均查詢響應時間,每天、每周或每月的用戶數就是有用的指標。定期審查 。透明度和可見性推動數據倉庫/商務智能監控的關鍵原則。

3.6 交付成果

3.7 技術驅動因素

3.8 方法

1. 驅動需求的原型。
   在實現產品之前,通過創建一組演示數據并在協調原型設計工作中采用需求挖掘的方法,快速確定需求優先級。
   對數據進行剖析(Profiling) <font color=red>有助于原型設計,并降低與非預期數據相關的風險。數據倉庫通常最先體會到源系統或數據輸入函數中數據質量差的痛楚。概要分析還揭示了可能對數據集成造成障礙的數據來源之間的差異。數據可能在其來源中具有高質量,但由于各來源的不同, 數據集成過程變得更加復雜。</font>
   對源數據的狀態評估,有助于對集成可行性和工作范圍進行更準確的前期估算。評估對于設定適當的期望值也很重要。計劃與數據質量和數據治理團隊合作,并結合其他主題專家的專業知識來了解數據差異和風險。
   ==數據剖析有助于原型設計，降低風險。狀態評估有助于集 成可行性和工作范圍的評估。演示數據。數據虛擬技術。數據探查。源系統評估。==

2. 自助式商務智能。
   自助服務是商務智能產品的基本交付方式。它通常會將用戶活動放在受管門戶中,根據用戶的權限提供各種功能,包括消息傳遞、警報、查看預定的生產報表、與分析報表交互、開發即席查詢報表,當然還有儀表盤和計分卡功能。
   將協作工具向外擴展到用戶社區,可以提供一些自助服務提示和技巧、負載狀態、整體性能和發布進度的公告,也可以在論壇對話。
   ==基本交付形式。根據用戶權限提供。按標準計劃推送。在門戶中執行報表提取數據。社區。==

3. 可查詢的審計數據。
   為了維系數據血緣關系,所有的結構和流程都應該能夠創建和存儲審計信息,并能夠進行細粒度的跟蹤和報告。允許用戶查詢該審計數據,讓用戶能夠自己驗證數據的狀況和到達情況,從而提高用戶的信心。當出現數據問題時,使用審計信息還可以進行更詳細的故障排除。
   ==所有結構和流程都應能創建和存儲審計數據。能進行細粒度的跟蹤和報告。 提升用戶信心。可快速定位問題。==

3.9 工具

1. ==<font color = red>元數據存儲庫。</font>== <font color =green>P307</font>
   A.數據字典和術語。數據字典是支撐數據倉庫使用的必需組件。字典用業務術語來描述數據，包括使用該數據所需的其他信息(如數據類型、結構細節、安全限制)。數據字典內容來自邏輯數據模型。
   B.數據和數據模型的血緣關系。
   記錄的數據血緣關系有很多用途： 1)調查數據<font color = red>問題的根本原因</font>。2)對系統變更或數據問題進行<font color = red>影響分析</font>。3)根據數據來源確定數據的<font color = red>可靠性</font>。

2. ==<font color = red>數據集成工具。</font>== <font color =green>P308</font>
   用于加載數據倉庫。考慮系統管理的如下功能:
   1)過程審計、控制、重啟和調度。
   2)有選擇地提取數據元素并將其提供給下游系統進行審計的能力。
   3)控制操作的執行，并重啟失敗或中止的進程。還提供 BI 產品的集成功能，支持工作流消息、電子郵件甚至語義層的導入導出。

3. ==<font color = red>商務智能工具。</font>== <font color =green>P308</font>
   1)運營報表。
   2)業務績效管理 BPM。旨在優化業務戰略的執行。績效度量和帶正反饋回路是關鍵的要素。績效度量和帶正反饋回路是關鍵的要素。
   3)描述性自助分析。 為前臺提供，指導運營決策。

【運營報表】 <font color =green>P309</font>
業務用戶直接從交易系統、應用程序或數據倉庫生成報表。
數據檢索和報表工具，有時稱為即席查詢工具，允許用戶編寫自己需要的報表或創建供他人使用的報表。
業務運營報表中的需求通常與業務查詢報告的需求不同。
生產報表跨越了數據倉庫/商務智能的邊界，它經常直接查詢交易系統，產生諸如發票或銀行對賬單之類的操作項。
傳統的商務智能工具可以很好地展現表格、餅圖、折線圖、面積圖、條形圖、直方圖、K 線圖等一些數據可視化方法。

【業務績效管理】 <font color =green>P309</font>
績效管理是一套集成的組織流程和應用程序,旨在優化業務戰略的執行。應用程序包括預算、規劃和財務合并。

【在線分析處理OLAP】 <font color =green>P310</font>
OLAP工具和Cube(數據立方體)的價值是,<font color = red>通過將數據內容與分析師的心理模型對齊,減少混淆和錯誤解釋。</font>
多維分析查詢提供快速性能的方法。常見操作有<font color = red>切片、切塊、向下/向上鉆 取、向上卷積、透視。</font>
三種經典 OLAP 實現方法如下: <font color = red>關系型聯機分析處理 ROLAP。多維矩陣型聯機分析處理 MOLAP。混合型聯機分析處理 HOLAP。</font>

3.10 度量指標

1. 使用指標。
   包括注冊用戶數、連接用戶數或并發用戶數。

2. 主題域覆蓋率。
   衡量每 個部門訪問倉庫的程度

3. 響應時間和性能指標。
   指標的后續跟進工作是驗證和服務級別調整。

4 實施指南

就緒評估/風險評估: 所有IT項目都應該有業務支持,與戰略保持一致,并有一個定義好的架構方法。 <font color =green>P312</font>
數據倉庫應該能夠實現以下幾點:

1. 明確數據敏感性和安全性約束。
2. 選擇工具。
3. 保障資源安全。
4. 創建抽取過程以評估和接收源數據。

版本路線圖: 因為需要進行大量的開發工作,所以數據倉庫是逐步構建的。無論選擇何種實現方法,不管是瀑布式、迭代式,還是敏捷開發,都應該考慮到想要實現的最終狀態。 <font color =green>P313</font>

組織與文件變革: 始終保持一致的業務重點是項目成功的關鍵。了解企業的價值鏈是理解業務環境的好方法,企業價值鏈中的特定業務流程提供了一個自然地面向業務的環境,該環境可用于構建分析領域。 <font color =green>P313</font>

<font color = red>最重要的是,考慮到以下關鍵成功因素</font>,將項目與實際業務需求保持一致并評估必要的業務支持: <font color =green>P314</font>

1. 業務倡議。是否有合適的管理層支持?
2. 業務目標和范圍。是否有確切的業務需要、業務目標和工作范圍?
3. 業務資源。是否有專家?參與度如何?
4. 業務準備情況。業務合作是否準備好這是長期的增量交付項目?目標組織內的平均知識水平或技能差距有多大?
5. 愿景一致。IT 戰略對業務愿景的支持程度如何?

5 數據倉庫和商務智能治理

5.1 業務接受度

一個關鍵的成功因素是業務對數據的接受程度,包括可以理解的數據、具有可驗證的質量,以及具有可證明的數據血緣關系。

預先還要考慮一些非常重要的架構子組件及其支持活動,具體如下:

1. 概念數據模型。組核心信息?關鍵的業務概念? 如何相互關聯?
2. 數據質量反饋循環。如何識別和修正問題數據?如何了解問題是怎么產生的? 怎樣對解決問題負責?對數據倉庫的數據集成過程中引起的問題進行補救的過程是什么?
3. 端到端元數據。架構如何支持集成的端到端元數據流?是否理解上下文環境的意義?數據消費者如何回答諸如“這個報表的含義是什么”或“這個指標是什么意思”等基本的問題?
4. 端到端可驗證數據血緣。業務用戶公開訪問的項目是否能以自動化的、可自維護的方式追溯到源系統?所有數據是否都記錄在案?

5.2 報表策略

確保BI產品組合內部和跨BI產品組合間都存在報表策略。報表策略包括 <font color=red>標準、流程、指南、最佳實踐和程序</font>,它將確保用戶獲得清晰、準確和及時的信息。

報表策略必須解決如下問題:

1. 安全訪問。確保只有獲得授權的用戶才能訪問敏感數據。
2. 描述用戶交互、報告、檢查或查看其數據的訪問機制。
3. 用戶社區類型和使用它的適當工具。
4. 報表摘要、詳細信息、例外情況以及頻率、時間、分布和存儲格式的本質。
5. 通過圖形化輸出發揮可視化功能的潛力。
6. 及時性和性能之間的權衡。

6 關鍵架構圖

1. 圖11-1 數據倉庫和商務智能語境關系圖

   
   
   圖11-1 數據倉庫和商務智能語境關系圖

2. 圖11-2 企業信息工廠（CIF）

   
   
   圖11-2 企業信息工廠（CIF）

3. 圖11-3 Kimball 的數據倉庫棋子視圖

   
   
   圖11-3 Kimball 的數據倉庫棋子視圖

4. 表11-4 數據倉庫總線矩陣示例

   
   
   表11-4 數據倉庫總線矩陣示例

5. 圖11-5 數據倉庫/商務智能和大數據概念架構

   
   
   圖11-5 數據倉庫/商務智能和大數據概念架構

6. 表11-6 CDC技術比對

   
   
   表11-6 CDC技術比對

7. 圖11-7 發布流程示例

   
   
   圖11-7 發布流程示例