編輯導語：我們在日常工作中經常會遇到各種各樣的邏輯關係，邏輯可以讓我們的工作提高效率；作者在前一篇介紹了邏輯中的“業務邏輯”表達方式，本篇文章作者繼續介紹“資料邏輯”的表達方式，我們一起來看一下。
多數沒有開發背景的需求工程師對資料面層的分析、設計是比較生疏的，面對比較複雜的資料關係時或多或少都有一些畏懼，不太願意深究，儘量交給後續的程式設計師去處理。
這個做法是不對的，資料邏輯來源於業務邏輯，需求分析師能夠向程式設計師說明資料邏輯關係，那麼後者的工作效率會提升很多（否則、不熟悉業務的後者還要花費很多時間去研究業務邏輯）；同時是否能夠清楚地表達資料邏輯關係也說明了需求分析師具有的能力和水平。
一、資料邏輯的概念資料邏輯：表達的是資料層資料之間的邏輯關係，這個層的要素是資料。
為了理解資料邏輯，要先理解為什麼存在著業務邏輯和資料邏輯二種不同的表達形式呢？這首先是因為兩者存在於不同的層面上、且要素不同。
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 協議