編輯導語：我們在日常工作中經常會遇到各種各樣的邏輯關係，邏輯可以讓我們的工作提高效率；作者在前一篇介紹了邏輯中的“業務邏輯”表達方式，本篇文章作者繼續介紹“數據邏輯”的表達方式，我們一起來看一下。
多數沒有開發背景的需求工程師對數據面層的分析、設計是比較生疏的，面對比較複雜的數據關係時或多或少都有一些畏懼，不太願意深究，儘量交給後續的程序員去處理。
這個做法是不對的，數據邏輯來源於業務邏輯，需求分析師能夠向程序員説明數據邏輯關係，那麼後者的工作效率會提升很多（否則、不熟悉業務的後者還要花費很多時間去研究業務邏輯）；同時是否能夠清楚地表達數據邏輯關係也説明了需求分析師具有的能力和水平。
一、數據邏輯的概念數據邏輯：表達的是數據層數據之間的邏輯關係，這個層的要素是數據。
為了理解數據邏輯，要先理解為什麼存在着業務邏輯和數據邏輯二種不同的表達形式呢？這首先是因為兩者存在於不同的層面上、且要素不同。
1. 業務邏輯表達的是以客户“活動、規則”等內容為要素的邏輯關係。
業務邏輯表達的是業務活動之間的關係，是以客户的業務知識、業務事理為基礎的。
舉例説明，圖1是一個生產過程的業務架構圖（流程圖），我們對客户業務的理解首先是從業務架構圖獲得的，從圖的表面上只看到業務活動之間的關係，如：活動“4.採購”完成後下一個活動是“5.物流”。
圖1 生產流程圖
在表面上雖然直接看不到數據的存在，但是在兩個活動之間的關聯線中流動着如下的數據：採購物品名稱、數量、單價、交付日期等。
2. 數據邏輯表達的是以“數據”為要素的邏輯關係。
數據邏輯是數據間的關係。數據架構層在業務架構層的下面，圖2是一個業務邏輯與數據邏輯關係的示意圖。
從業務架構圖上是不能直接看到數據邏輯的，數據是業務活動產生的結果（沉澱），數據邏輯的獲取是依賴於業務邏輯的，但在數據獲取後，數據間的引用關係要遠多於業務活動間的關聯關係，如圖2所示。
數據邏輯雖然來源於業務邏輯，反過來數據邏輯又是業務邏輯合理存在的內在支撐。
圖2 業務邏輯與數據邏輯關係的示意圖
確認了存在着數據之間的邏輯關係，那麼這個邏輯表達形式是什麼樣的呢？數據邏輯的表現形式有很多，本篇的目的是支持業務需求的分析工作，因此從“業務的視角”給出數據邏輯的表達方法（而不是從技術視角）。
3. 數據邏輯的表達形式這裏介紹業務分析用的三種數據邏輯表達形式：線、表、圖，參見圖3，其中：
- 圖（a）線：是用數據表的業務編號，作為連接數據表、數據之間的關係（主/外鍵）；
- 圖（b）表：指的是數據表，用表格結構表達出數據之間的上下、父子、從屬等的關係；
- 圖（c）圖：用圖的形式，給出數據之間的關聯關係，如：算式圖、數據線、勾稽圖；
圖3 數據邏輯的表達方式
二、數據邏輯表達的簡介1. 用線表達數據邏輯（主/外鍵）以下面的合同書的數據表為例，説明主鍵和外鍵的定義和關係，參見圖4。
主鍵，是本數據表的代表名稱，一個數據表裏只能有一個主鍵，它只能是唯一地標識表中的每一行，通過它可強制數據表的完整性；它用於與其他表的關聯，以及本記錄的修改與刪除等。
外鍵，當一個表中除了本表的主鍵外，還保存了其它數據表的主鍵時，那麼在本表中其它數據表的主鍵就被稱之為“外鍵”；根據參照外部數據表的數量多少，一個數據表中可以有複數的外鍵。
圖4 數據表之間的主外鍵關係示意圖
2. 用表表達數據邏輯數據表，是按照一定的結構形式排列的數據格式，任何數據的載體都是數據表。用“格式”描述數據表的形式，格式包括了數據結構、數字分類、數據狀態等三類內容，參見圖5。
- 數據結構：列表結構、樹表結構等；
- 數字分類：數值、貨幣、文本、日期、分數等；
- 數據狀態：表達在導入上游功能的數據時，該功能所處的狀態，比如：編輯期限已過、功能被鎖定、審批已完成、數據已被引用等。
圖5 數據表格式示意圖
3. 用圖表達數據邏輯當遇到了非常複雜的計算，比如：數據來源多、計算公式複雜且需要進行多重計算等，需求分析師如何才能做到準確、快速地向程序員説明計算公式和數據呢？
此時僅靠用文字説明就非常困難了，即麻煩、又不準確，使用邏輯圖是一個非常好的方法，這裏簡單地介紹一下算式關聯圖的用法。
算式關聯圖的應用場景是：在某個“節點”上有多個數據來源的彙總、計算；這個計算式可以是存在於活動功能、看板功能或報表功能中的某個處理步驟，這個計算式涉及到了複雜的數據來源、引用、關聯及多重的計算。
算式關聯圖的模型包括了兩大部分：數據的來源和數據的處理，見圖6。
假定在圖a.的“L-021採購流程”的B節點①上有一個計算處理，這個計算需要用到A、B、Q節點、以及其他數據庫的數據，表達B節點計算過程的方式如下。
圖6 算式關聯圖
下面分別對算式關聯圖的各個部分進行詳細説明。
1）數據來源
數據來源圖部分，是用來説明包含有計算功能的位置、以及其它參與計算的數據來源：
- 繪製採購流程L-021，該流程上節點A和節點B中的數據參與了計算，另外，不在流程上的獨立活動Q中的數據也參與了計算；
- 標註出發生了“成本核算”處理的活動B在該流程上的位置（可以採用不同的顏色）；
- 標註出每個活動上參與計算的數據表名稱，比如：活動A/表a（在流程上的功能）、活動Q/表q（非流程上的功能）；
至此，標示出了計算公式的位置和3個數據的來源，完成了數據來源的説明。
2）數據處理
數據處理圖，是建立數據表b的計算處理模型，其中：
圖6的②表b：因為計算公式在發生在功能B上，因此將功能B的數據表b放到處理圖的左上角。
圖6的③其它的數據來源分列在處理圖的兩側（佈局的要求僅作為參考），比如：
- 數據源1：將來源於活動類的數據，如：表a、表q，置於處理圖的左側，表b的下方；
- 數據源2：將來源於數據庫的數據，如：基礎數據、過程數據庫，置於處理圖的右側；
圖6的④計算數據：在表內寫入參與計算的變量名稱、數值，並用箭頭線將數據表指向處理器；
圖6的⑤計算名稱：計算處理器⑤的上面要標明算式的名稱，如：成本核算；
圖6的⑥計算過程：將各數據來源的具體數值帶入到計算過程⑥的公式中，格式必須要給出分步計算的過程，必須要讓程序員可以讀出來每一步的計算公式與對應的計算結果；
圖6的⑦計算結果：將最終的計算結果填入計算結果欄⑦，到此完成全部的計算過程；
圖6的⑧如果某個步驟的內容比較複雜，可以在實體、或是數據旁邊，加入一些説明文；
可以看出來，算式關聯圖實際上就是一個為解決某個特定問題而建立的用例圖。
擴展説明：
由誰來規劃數據和建立數據標準？
在軟件企業中有不少人認為：只要是數據相關的設計就是程序員的工作，其實不然，業務層面與技術層面對數據的設計方法是不同的，技術層面的數據設計不能替代業務層面的數據設計；相反，沒有很好的業務層面的數據設計做支持，技術層面的數據設計缺乏依據、容易發生重複調研、分析和設計的現象，工作效率低。
與技術層面的數據設計不同，業務層面重點做的不是數據“庫”的設計，而是業務數據的邏輯設計，由於業務和技術的視角不同，數據關係圖的表達內容和方式也不同，參見圖7中的兩張圖就可以看出它們之間的區別，區別的關鍵點還是在於業務邏輯的有無。
- 業務視角的數據關係圖（a）：有業務流程，帶有清晰的業務邏輯關係；
- 技術視角的數據關係圖（b）：用“鍵”的形式替代了業務邏輯的表達形式，但是要注意，這個“鍵”的設計依據或直接、或間接地參考了業務邏輯。
圖7 數據關係圖
只有從業務設計的視角，充分地理解業務數據的內容、用途、業務數據之間的邏輯關係、以及未來可能的變動規律等，才能保證不論業務如何變化數據的結構都是穩定的。
消除企業信息孤島現象，首先是業務設計師要解決的問題，因為這個問題的本質不是數據庫問題，也不是技術開發工程師單獨能夠解決的問題。
本系列下一篇博文：李鴻君：如何繪製邏輯圖 — 9.模型的分類
作者：李鴻君；《大話軟件工程—需求分析與軟件設計》一書作者。
本文由 @李鴻君 原創發佈於人人都是產品經理，未經許可，禁止轉載
題圖來自 Unsplash，基於 CC0 協議