如何繪制邏輯圖——邏輯的表達:數據邏輯(8)
編輯導語:我們在日常工作中經常會遇到各種各樣的邏輯關系,邏輯可以讓我們的工作提高效率;作者在前一篇介紹了邏輯中的“業務邏輯”表達方式,本篇文章作者繼續介紹“數據邏輯”的表達方式,我們一起來看一下。
多數沒有開發背景的需求工程師對數據面層的分析、設計是比較生疏的,面對比較復雜的數據關系時或多或少都有一些畏懼,不太愿意深究,盡量交給后續的程序員去處理。
這個做法是不對的,數據邏輯來源于業務邏輯,需求分析師能夠向程序員說明數據邏輯關系,那么后者的工作效率會提升很多(否則、不熟悉業務的后者還要花費很多時間去研究業務邏輯);同時是否能夠清楚地表達數據邏輯關系也說明了需求分析師具有的能力和水平。
一、數據邏輯的概念
數據邏輯:表達的是數據層數據之間的邏輯關系,這個層的要素是數據。
為了理解數據邏輯,要先理解為什么存在著業務邏輯和數據邏輯二種不同的表達形式呢?這首先是因為兩者存在于不同的層面上、且要素不同。
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 協議
- 目前還沒評論,等你發揮!