關于商業智能 BI 的介紹面對不同的企業客戶可以從很多不同的角度展開，比如從業務角度、管理角度、數據架構角度、IT 信息化建設角度、BI 實施方法論角度等，不同的視角可以幫助企業更加全面的了解商業智能 BI，對企業在規劃和建設商業智能 BI 項目會有很大的幫助。

筆者同時從事過多年的傳統軟件技術開發和商業智能 BI 開發工作，深感兩個專業領域有所同，也有所不同。這篇文章站在傳統軟件開發流程的角度，對比商業智能 BI 的開發流程，談一談兩者之間的差異。結合這種對比，再來解答一下在企業級商業智能 BI 的建設上，大家可能會存在的一些困擾，以及如何解決。

01

傳統軟件開發流程與商業智能 BI 開發的異同

傳統軟件開發從流程上來看，基本上可以分為以下幾個階段：

需求分析 —— 用戶需求調研、業務流程梳理、核心業務痛點分析、業務邊界確認與劃分等。

概要設計 —— 系統基本處理流程、組織結構、功能模塊劃分、運行設計、異常處理設計等。

詳細設計 —— 數據結構、類與接口設計、技術框架設計等。

編碼開發 —— 根據詳細設計進行程序開發與實現。

測試階段 —— 單元測試、模塊測試、整體測試、日志優化調整等。

交付驗收 —— 軟件開發項目驗收、用戶培訓等。

視項目規劃大小、企業資源投入程度決定以上各個階段的實現的復雜程度，以及進行適當的調整。小投入、短周期的項目要求立竿見影，這種條件下就不可能做到面面俱到，但整體上基本會按照這個大流程進行。

商業智能 BI 的開發從流程上基本上和軟件開發流程類似，從需求開始到設計、開發、測試與驗收上線。

本質上兩者都是解決企業 IT 信息化的問題，區別在于業務軟件重點解決業務流程和管理信息化的問題，商業智能 BI 重點解決數據信息化和決策化的問題。

對比軟件開發流程中的概要設計、詳細設計與開發階段，其中有幾個環節值得注意：

第一，商業智能 BI 在可視化原型建模大多數情況下是缺失的。

第二，傳統軟件底層數據庫設計采用 3NF 建模，而商業智能 BI 在不同的項目規劃中底層數據庫設計可以采用 3NF 建模，也可以采用維度建模以及兩者結合的混合架構。商業智能 BI 不同的建模方式也決定了完全不同的設計理念以及開發與實現過程，例如商業智能 BI 的 3NF 建模與傳統軟件開發的生命周期完全不同，對 BI 開發人員的要求也有很大的差異。

第三，商業智能 BI 的開發人員大多數情況下集數據庫設計、前后端一體，軟件開發在人員分工上會更加細化，前后端分離。

以下從上門這幾個重點環節來談談其中的差異。

02

原型設計與用戶需求分析

在早期的軟件開發領域，用戶需求調研基本上都是以與業務部門訪談梳理業務流程為主，結合靜態的 HTML 或 EXCEL 模擬( 以 B/S 項目為例 )向用戶展示一些基本的表單樣式與表單跳轉( 處理流程 )來理解和確認業務，以及確認相關核心的業務字段。如今，在特別突出產品經理角色的時代，可以通過 Axure、藍湖、墨刀、Sketch 等很多種強大的工具完整的模擬用戶需求原型，效率得到了極大的提升。

藍湖的原型設計與交互頁面

但是在商業智能 BI 領域，到目前為止我們在絕大多數企業我們看到的還是十來年前的老樣子，用戶需求訪談調研，用 EXCEL 結合一些測試數據來模擬一些基本的可視化報表來與客戶確認。實際上還是很難真正表達客戶真實的分析訴求的，因為 EXCEL 圖表太零散、單一，也無法表達完整的分析意圖。同時，在很多實際的項目上，因為項目周期的原因，也不允許出現這種長周期的需求調研。在這一點上，派可數據在 BI 產品上做了很多努力，基本上已經很好的解決了這個問題，可以在很短的時間( 2-3 天 )給出不同的行業化可視化分析原型。

派可數據的原型設計與交互頁面可以在不鏈接任何外部數據源的情況下設計與展示

BI 原型設計的核心是什么 ？是可視化建模，而建模的核心在于數據倉庫中數據分析模型的設計。

數據分析模型的搭建在商業智能 BI 領域重點其實就解決兩個問題：用戶要看什么數據( 指標、度量 )，從什么角度看 ( 維度 )。至于怎么進行可視化展現實際上在底層數據模型設計階段并不重要，因為現在的 BI 工具已經完全實現了拖拉拽的操作，可以非常輕松的進行可視化報表的設計了。

在這里，有一個核心概念是派可數據在市場上反復強調的：商業智能 BI 的本質不是面向報表開發，而是面向模型開發。這里的模型重點指的就是如何組織數據( 指標 )和角度( 維度 )，形成一個具備完整分析鏈路( 維度中的屬性層次結構 )的分析模型，可以支撐到各種靈活多變的可視化圖表展現效果。

派可數據 BI 平臺的可視化數據倉庫建模

所謂面向報表開發，指的就是用戶提出什么報表需求，就寫 SQL 取數通過大寬表以數據集的方式支撐一個或者一張報表的呈現。這樣做實際上犧牲了很多的業務可擴展性和靈活性，在面對日益累計的業務分析需求的時候，對 BI 的開發和擴展會形成非常沉重的負擔。

指標( 事實 ) 與維度的關聯關系

上面講到的建模在商業智能 BI 建模方法論中實際上體現的是 Kimball 的維度建模方法論，另外一個建模方法論則是 Inmon 的 3NF ( The Third Normal Form ) 建模方法論。兩者建模方式上有很大的差異，并且 Inmon 的 3NF 建模方法論在針對 BI 的可視化原型建模過程中是無法很好的實現的。因為 Inmon 的 3NF 建模更多表達的是源自業務系統的業務過程模型，而 Kimball 的維度建模在表達分析思維模型的時候更加直觀。

為什么在商業智能 BI 領域會存在兩種不同的建模方式，3NF 建模和維度建模的主要差異到底在哪里 ？我們需要從根上即商業智能 BI 的底層基礎 —— 業務軟件系統的建模方式上來一探究竟。

03

軟件系統中的3NF 建模

簡單的 ER 模型示例圖

軟件系統的開發在經歷了用戶需求調研、原型設計階段之后，基本上用戶的業務流程、業務需求都確認的差不多了，這時就可以進入到概要設計階段。在這個階段一是要進行 ER 模型的設計，同時也要進行底層數據庫表的結構設計。

ER 模型 - 實體關系圖 ( Entity Relationship ) 表達的是：

1. 在整個實際的業務流程中誰 ( Entity 實體 ) 與誰 ( Entity ) 發生了什么 ？例如一個客戶( 實體 )下了一筆或者多筆訂單( 實體 )，這個訂單包含了一個或者多個商品( 實體 )。

2. 如何描述這個實體 —— 屬性( Attribute ) ？比如，要記錄客戶的姓名、年齡、性別、聯系電話、住址等，這些就都是屬性。

3. 它們( Entity )之間什么關系( Relationship )？下訂單就是客戶與訂單的關系，訂單包含商品就是訂單與商品的關系。同時，也描述了一個客戶可以下多筆訂單，一筆訂單包含多個商品，這就是 ER 模型中一對一、一對多或者多對多的關系。

基于 ER 模型，在數據庫設計層面，就可以進行數據庫表設計建模，對應到 ER 模型：

1. 數據庫表，對應到實體。通常會增加非業務性的一些額外的數據庫表來支撐程序開發。

2. 數據表字段，對應到實體的屬性。通常會增加主鍵來唯一標識一個實體、一張表。

3. 數據表關系，對應到實體與實體的關系。通常通過數據表的主外鍵關系來表達，形成一對一、一對多或者多對多的關系，復雜一點的還有自引用的表設計關系，比如企業的組織架構、上下級關系。

數據庫表結構的模型設計

同時，基于 ER 模型和數據庫表設計，也可以進行程序開發中的類 Class 和接口 Interface 的設計與定義。

在軟件系統的詳細設計和開發階段，數據庫表就已 3NF 的形式來進行設計開發了，3NF ( The Third Normal Form ) 三范式開發的相應要求：

1NF，第一范式，最小字段、原子性不可再分。

2NF，第二范式，唯一標識，可以通過主鍵唯一標識一條數據。

3NF，第三范式，消除傳遞依賴，非主鍵列不依賴除主鍵列的其它字段。

關于三范式的數據庫表設計規范不在這里重點闡述( 除了三范式外還有其它四范式、五范式等，讀者可以搜索了解 )。

為什么軟件業務系統采用 3NF 的數據庫建模方式，主要有以下幾個重點原因：

第一，業務系統本身描述的就是業務過程的，而業務過程在 ER 圖上的表現就是實體與實體的關系。這種關系對應到數據庫表的設計上就通過 3NF 來體現。

第二，消滅數據冗余。3NF 的設計規范在最大程度上消滅了數據冗余，能夠更加清晰的定義業務發生的實體，實體與實體的關系。

第三，面向對象、面向接口的編程思維。對于對象 OBJECT 的定義以及 CLASS 類的實現本身也就描述了 ER 模型的實體和數據庫基礎表的結構和定義。

第四，業務系統重在數據的錄入、修改和刪除等基本操作。雖然在業務系統中也有大量的查詢，但大多數都是圍繞原子表進行增刪改基礎上的查詢工作，并不是真正為分析為目的的查詢 SELECT 操作。而3NF 的設計更加適合程序對數據的增刪改 INSERT、UPDATE 和 DELETE 操作。

以上，從業務過程的表達與描述、ER 模型的還原、數據的操作場景以及程序設計角度定義了 3NF 在軟件業務系統開發過程中的必要性。

04

BI 系統中的3NF 建模與維度建模

商業智能 BI 系統與業務軟件系統的開發過程一樣，都需要進行底層數據庫表的設計。不同的是，在商業智能 BI 系統中，我們把這種數據庫叫做數據倉庫。數據倉庫本質上就是一個數據庫，核心區別主要在于他們解決的問題的不同，建模方式的不同( 例如使用 Kimball 維度建模方法論時 ), 數據倉庫存在多層表設計分類的不同等等。

關于數據庫和數據倉庫的差異，讀者可以通過這篇文章了解：每日小視頻：數據庫和數據倉庫有什么區別和聯系？

在商業智能 BI 領域中有很多種不同的數據倉庫建模方式，例如:

• Independent Data Marts Achitechture 獨立集市架構
• Centralized Data Warehouse Architecture 集中式架構
• Data Vault 架構
• Data Mart Bus Architecture 數據集市、數據倉庫總線架構 ( Kimball )
• Hub and Spoke / CIF – Corporate Information Factory 集線器架構 / 企業信息工廠架構 ( Inmon )

其中最常見就是 Inmon 的 3NF 三范式建模與 Kimball 的維度建模 ( 星型和雪花型建模 )這兩類。

數據倉庫之父 Inmon 與維度建模專家 Kimball

其中最常見就是 Inmon 的 3NF 三范式建模與 Kimball 的維度建模 ( 星型和雪花型建模 )這兩類。

關于兩種建模的詳細差別與孰優孰劣暫時不在這篇文章中展開，可以放到后續的公眾號文章來闡述，我們只來談談它們做了什么。

Inmon 的 3NF 三范式建模如同在本文開頭的第一節【傳統軟件開發流程與商業智能 BI 開發的異同】中提到的：商業智能 BI 的 3NF 建模與傳統軟件開發的生命周期完全不同。

Inmon 的 3NF 建模在商業智能 BI 的開發過程中不是以分析需求為導向的，Inmon 的做法是先集成各個業務系統的數據，再來設計 DSS ( Dicision Support System 決策支持系統 )，到最后分主題實現 Data Mart 數據集市來支撐到 Reporting 報表系統。

所以 Inmon 的建模方法論復雜就復雜在這個地方，對比業務系統的軟件開發過程，就相當基于各個業務軟件系統的獨立的、按照 3NF 建模的數據庫之上在封裝、設計出一套跨業務、跨主題的大而全的 3NF 數據庫。

也可以理解為：在不同特定行業和領域，Inmon 的 3NF 數據庫事實上梳理了這個行業和領域的一套完整的數據庫設計架構，如果基于這種基礎的表架構來進行軟件系統的開發，這套數據庫底層表設計基本上就是其對接的全部軟件系統數據庫表設計之和。

可以想象它對 BI 開發人員的要求在數據倉庫的設計層面幾乎與軟件開發人員對業務系統的數據庫設計完全對等，其挑戰就是：

第一，要完全理解所服務企業的全部業務，熟悉所對接的全部業務系統數據庫表設計的含義。

第二，幾乎是一種程序開發思維來重新按照 3NF 的設計對數據庫表進行建模。

第三，長周期的調研、長周期的溝通，同時還需要把以往各個業務系統中設計不合理的因素重新規避掉。

第四，巨大的人力、時間投入成本，項目啟動動輒千萬級別的規模，一般的企業無力承擔。

事實上，我們在很多企業看到的一些按照 Inmon 3NF 設計思想設計的數據倉庫是經不起推敲的，基本上都是通過簡單分層、臨時表來寫 SQL 拼數據集拼報表做展現，這就是一種典型的面向報表開發思維。

哪些企業做的比較好，例如傳統的金融( 銀行、保險)等民生領域，有幾個方面的原因：

第一，這些領域是最早實現基礎軟件信息化的，早在 2000 年前后就已經有了非常成熟的業務系統。沒有業務信息化的支撐，用戶連基本銀行交易都無法實現。

第二，基礎業務信息化實現的早，就構成了對數據分析決策、報表統計的大量需求，因此這些領域商業智能 BI 的建設也比傳統企業領先了至少十年時間。

第三，不同于傳統企業 BI 的分析需求可以從某一個業務領域切入，這些行業需要一個整體的、大而全的數據標準，達到一個完整的一致性的數據倉庫平臺，這種就很符合 Inmon 的 3NF 建模方法論。

業務需要、有錢能投入、數據需求這幾個方面的主要因素就決定了他們選擇 Inmon 建模方法論的合理性。

在過去的兩年我們一直在大批量的面試 BI 開發人員，可以發現大部分新進入這個行業的 BI 開發人員早期的項目經驗或培訓實習經驗都提到了金融、銀行、保險等項目經驗。通過面試反饋，大部分的 BI 開發人員對于數據倉庫建模了解很有限，日常的主要工作就是從已經建好的數據倉庫中取數做報表開發。這也從側面說明了這些行業的數據倉庫成熟度很高，所以他們很少能碰到完整的從零到一開發數據倉庫的機會。

我們再來談談 Kimball 建模方法論，Kimball 建模的開發過程實際上就與傳統軟件開發的過程和生命周期相對一致。

第一，從需求出發，通過需求分析來確認分析的數據( 指標 、度量 )、確認分析的角度或者叫看數據的角度 ( 維度 )。

第二，通過星型和雪花型建模方式來組織分析模型，進行維度建模的設計開發過程。

第三，通過 ETL 過程 ( Extract 抽取、Transformation 轉換、Loading 加載 )完成從各個業務系統數據源取數、清洗、格式轉換到最終適配模型層數據庫表來實現數據的填充。

第四，根據項目實際的需要進行 Data Mart 數據集市的組織。

第五，分析報表可以直接從底層 FACT 事實表，也可以從 Data Mart 數據集市完成反向的 SQL 自動查詢來呈現數據可視化報表。

Kimball 的數據倉庫從數據表的建模角度來講，與 Inmon 有幾個重要不同：

第一，Kimball 的維度建模是反規范化的，反三范式的，因此會有大量的數據冗余，適合大批量查詢，而非增刪改。

第二，Kimball 從需求端往下推進，從小業務范圍切入逐步擴大，在一開始不需要建立大而全的數據倉庫，只解決特定業務領域的分析，取數范圍從小到大。

第三，Kimball 維度建模的數據表架構( 星型和雪花型模型 )更容易表達業務分析思維，而不是像 Inmon 主要描述業務過程。

我們在外面經常聽到大家提 Inmon 和 Kimball 的差別就是自上往下、自下往上，實際上就是兩端，一端是需求，一端是數據。我們的習慣認為需求在上、數據在下，所以我們通常會反過來介紹：Inmon 是自下往上的，而 Kimball 是自上往下的。實際上什么方向并不重要，這都是一種表達形勢。重要的是要真正理解 Inmon 和 Kimball 在商業智能 BI 項目建設過程中到底扮演了什么角色，對 BI 實施方法論有什么影響，對于企業和 BI 開發人員有提出了什么挑戰和要求。

看到這里，大家可能會有以下幾個疑問：

第一，Inmon 的建模方法論基本上講明白了，Kimball 建模方法論中的星型和雪花型模型到底是什么 ？

第二，Inmon 在一開始的時候就集成了大而全的業務系統數據，所以 BI 需要什么數據就取什么樣的數據，這種方式應該會更好一些。但 Kimball 并沒有這樣做，如何在架構上保證不斷增進的業務需求不會破壞已經建好的數據倉庫架構 ？

第三，維度建模的核心到底是什么，維度、事實在 ETL 中處理流程是什么，如何對他們組織并進行合理的分層 ？

第四，在文章開頭提到的原型設計和維度建模有什么樣的關聯和聯系，在實際業務分析需求過程中兩者如何結合和關聯 ？

第五，在維度建模過程中，Data Mart 數據集市到底應該如何定位，在實際的場景中應該如何應用 ？

對于這些疑問，我們不在這里展開，我們會陸續通過后續的文章展開分享，答疑解惑。

最后，我們仍然將數據倉庫架構的設計置于整個軟件開發流程和商業智能 BI 開發的流程來看，Kimball 的建模方法論是符合軟件開發流程和生命周期的。

05

再看軟件開發與商業智能 BI 開發

從大的開發過程上來看，軟件開發解決的是業務流程的開發，商業智能 BI 解決的是數據分析的開發，本質上都是服務于 IT 信息化，我們可以通過下面的對比找到很多的對應關系，這樣對商業智能 BI 的理解會更加容易一些。

可以從開發環境、開發角色、實現語言、實現效果等多個角度來對比理解：

第一，軟件開發需要依賴 IDE 工具進行開發，商業智能 BI 開發同樣需要。比如現在的IDEA，還有筆者早年經歷過 Visual Studio、JCreator、JBuilder、NetBeans、Eclipse 等。商業智能 BI 開發環境例如派可數據 BI 可視化分析平臺，以及國內外其它優秀的 BI 產品工具，都是 BI 開發的 IDE。

所以，很多企業不能簡單的認為只要買了一個 BI 工具就可以解決所有的問題，它只是一個工具，在實際的 BI 項目開發過程中一樣會遇到類似于傳統軟件開發過程中的很多挑戰，例如數據倉庫的設計。

第二，軟件程序開發人員的角色更為細分，會包括 WEB 前端開發、后端開發、數據庫設計、UI 與測試等多種角色。而商業智能 BI 在大多數情況下開發人員集數據庫設計( 數據倉庫設計 )、ETL 實現 ( BI 系統與底層數據的交互 )、報表開發 ( 前端可視化呈現 )為一體的角色。

在商業智能 BI 領域更加細分的角色只會在特別大的項目中出現，有專業的數據倉庫架構師、ETL 開發工程師與報表開發人員，但傳統上我們提到 BI 開發人員就一定是一個全棧的角色。

第三，軟件程序開發人員和商業智能 BI 開發人員都需要通過 IDE 進行編程，但開發語言有很大的不同。例如軟件開發人員從前端往后端看，有：HTML、CSS、JS、VUE、JQUERY、PHP、JSP、ASP.NET、JAVA、C#.NET、C、C++ 等等。商業智能 BI 開發人員主要就是 SQL 語句，再結合一些存儲過程和 ETL 工具 ( Kettle、Informatica、DataStage、Pentaho )等就可以解決 BI 項目開發的問題。

05

總結

通過傳統軟件開發與商業智能 BI 的開發過程對比，還是可以看到很多能互相映射的地方，對于企業的 IT 信息化部門特別是有過傳統軟件開發和維護經驗的管理人員來說，通過這篇文章可以更加清晰的理解商業智能 BI 在開發過程中的特點，也便于企業未來商業智能 BI 項目的規劃與管理。

而對于商業智能 BI 開發人員來說，也可以通過上述的對比更加理解商業智能 BI，以及在與企業信息化部門、業務部門的溝通的過程中尋找更加通俗的表達方式，利于推進商業智能 BI 的建設，減少必要的工作阻力。

從職業的發展角度上來看，有過一定傳統軟件開發背景的 BI 開發人員對于業務信息化和數據信息化的認識會相對深刻一些，特別是經歷過傳統軟件底層數據庫設計開發的人員，再從事 BI 開發工作對于模型的建設也會更加有經驗一些。重點需要轉變的只是從業務過程解決思維方式到業務分析思維方式，這些可以通過努力學習和實際項目沉淀、復盤總結來有效提升的。

( 全文完，作者：派可數據 呂品，編輯：派小可)

作者介紹：十五年 IT 行業經驗，從事過大型軟件項目與大型商業智能 BI 項目規劃、設計、開發與項目管理。商業智能 BI 行業專家，數據架構師，對于企業 IT 業務信息化和數據信息化的建設有非常深厚的認知。如需對企業 IT 信息化建設、商業智能 BI 等相關話題交流，可通過下方 派小友 聯系我們。

總結

以上是生活随笔為你收集整理的er图用什么软件_从软件开发生命周期看商业智能 BI 数据仓库建模的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。