本文基于面向基本公共衛(wèi)生的業(yè)務(wù)系統(tǒng)設(shè)計經(jīng)驗，抽象出一套適合大型ERP系統(tǒng)的表單業(yè)務(wù)數(shù)據(jù)模型，目標是最大限度保留系統(tǒng)彈性的同時，盡可能降低系統(tǒng)復(fù)雜度和開發(fā)成本。enjoy~

背景

填寫表單應(yīng)該是所有業(yè)務(wù)線條中最避免不了的環(huán)節(jié)，例如我所經(jīng)歷的醫(yī)療項目：

居民健康檔案

居民健康檔案信息卡

以上面兩個例圖作為示例，可以看到姓名、性別、出生日期、血型等字段是完全重復(fù)的，由于業(yè)務(wù)場景的差異，表單被定義了不同的樣式和字段結(jié)構(gòu)，此時將遭遇以下幾種問題：

• 同一用戶經(jīng)歷了兩個不同場景時，不得不重復(fù)填寫相同的字段；
• 如果相同的字段在兩個表格中的值不同，基本無法判斷哪個為正確值，例如同一個人在居民健康檔案中血型填寫為A型，而在居民健康檔案信息卡中填寫為B型；
• 某些字段會重復(fù)出現(xiàn)在不同的表單中，隨著業(yè)務(wù)需要，將其串連起來查看其趨勢，如身高、體重、血壓、心率等等，以幫助醫(yī)生確診疾病，然而這些字段保存在各自的表單中，由于開發(fā)人員的變更、文檔的遺漏和產(chǎn)品的迭代，無法窮舉出所有的這些字段數(shù)據(jù)來源，即便能夠回溯所有的來源，本身也是一件十分消耗精力的事情；
• 因為政策或業(yè)務(wù)需要，要在原有的表單上做調(diào)整，新的標準導(dǎo)致表單字段產(chǎn)生變化，此時原有系統(tǒng)為保證其運行的穩(wěn)定，難以從數(shù)據(jù)表和底層代碼中迭代，只能新增數(shù)據(jù)表做開發(fā)，當(dāng)表單需求頻繁變化時，加劇數(shù)據(jù)碎片化的問題；
• 新增業(yè)務(wù)表單時，開發(fā)需要訂排期，用戶需要等待發(fā)版后才能使用，新增大量表單時影響原有開發(fā)計劃的同時，業(yè)務(wù)部門也難以快速開展系統(tǒng)業(yè)務(wù)。
• 做數(shù)據(jù)統(tǒng)計和分析時，由迭代造成的數(shù)據(jù)字段遺失或變更，無法統(tǒng)計出完整而準確的數(shù)據(jù)，做出的報告難以反映出真實的情況 ….

傳統(tǒng)的區(qū)域化基本公共衛(wèi)生系統(tǒng)正在經(jīng)歷這樣的劇痛，當(dāng)然其他行業(yè)比如金融的部分業(yè)務(wù)同樣面臨相同問題（本人只經(jīng)歷過這兩個行業(yè)，見諒），如何在紛繁復(fù)雜的業(yè)務(wù)環(huán)節(jié)中抽離出四兩撥千斤的數(shù)據(jù)模型，除了滿足日益頻繁的業(yè)務(wù)調(diào)整外，還能將數(shù)據(jù)完整的、標準的存儲并利用起來，是后端產(chǎn)品經(jīng)理的安身立命之本。

作為一個不務(wù)正業(yè)的產(chǎn)品經(jīng)理，這次就從數(shù)據(jù)庫表結(jié)構(gòu)設(shè)計上，介紹一套解決方案：結(jié)構(gòu)化動態(tài)表單。

場景和需求：

1. 可覆蓋絕大部分表單業(yè)務(wù)場景；
2. 表單樣式和字段可靈活調(diào)整，不影響歷史積累數(shù)據(jù)，不會造成數(shù)據(jù)庫和代碼層面的頻繁變更；
3. 數(shù)據(jù)統(tǒng)計時能夠快捷、準確、全面地獲取到想要的字段數(shù)據(jù)，不過度依賴文檔和程序員老員工；

模塊介紹

模塊劃分

屬性庫

所有表單中所有的字段都在屬性庫中定義，相當(dāng)于表單字段的字典。定義的核心包含屬性的唯一標識、屬性名、屬性值取值規(guī)則和約束等信息。

因為我認為所有的字段都是圍繞某個業(yè)務(wù)進行的，把這個業(yè)務(wù)抽象成對象，那么這些表單的字段就是這個對象的屬性，所以命名為屬性庫。

如果用關(guān)系型數(shù)據(jù)庫表達屬性庫，根據(jù)以往的經(jīng)驗可以總結(jié)出如下兩個基礎(chǔ)表：

屬性庫表結(jié)構(gòu)

屬性分類，主要根據(jù)使用者需求對屬性進行分類，方便查找和后期的批量數(shù)據(jù)統(tǒng)計，比如健康管理把心率、瞳孔大小、脈搏等屬性規(guī)劃到生命體征類，把身高、體重等屬性規(guī)劃到基本體征類等等，因此僅需要定義唯一識別碼、名稱和分類說明即可。

屬性，這個表非常重要，是數(shù)據(jù)標準化的基礎(chǔ)表。唯一標識、名稱、說明，這是一個屬性最基礎(chǔ)的說明，不用解釋。

• 分類ID字段可支持多個ID，表示一個屬性可劃分到多個分類下，這個可根據(jù)實際需求定義，我所經(jīng)歷的場景是有這種情況的，比如心率，既可以是生命體征類屬性，也可以是臨床診斷類屬性，很難絕對界定。當(dāng)然屬性和屬性分類也可以通過單獨建關(guān)系表來定義對應(yīng)關(guān)系，方法有很多，各有優(yōu)劣，看技術(shù)leader自行選型吧。
• 屬性類型，根據(jù)個人的經(jīng)驗，總結(jié)出圖中的幾種類型，相信大家都認識，不用展開，其中單選框、多選框兩種類型因為還依賴對應(yīng)的取值字典，因此還需要到屬性值字典中定義取值選項。另外值單位這個字段，方便做數(shù)據(jù)轉(zhuǎn)換和終端數(shù)據(jù)展示用，比如時長的值60，單位是分鐘，通過算法即可轉(zhuǎn)換該單位的值為1小時。

屬性值字典，主要用于配合屬性類型為單選框或多選框的取值，也是數(shù)據(jù)標準化的一部分。

例如定義一個屬性叫性別的屬性規(guī)劃到基礎(chǔ)信息分類中，此時會屬性庫的三個表中分別插入以下數(shù)據(jù)： 屬性分類表：ID=‘1’，分類名稱=‘基礎(chǔ)信息’，分類說明=‘用戶基本信息’ 屬性表：ID=2，分類ID=‘’，屬性名稱=‘性別’，屬性說明=‘用戶的性別’，屬性類型=‘單選下拉框’，值單位=空 屬性值字典：[ID=3，屬性ID=‘2’，字典值=‘男’],[ID=4，屬性ID=‘2’，字典值=‘女’],[ID=5，屬性ID=‘2’，字典值=‘未知’]

模版庫

所有的動態(tài)表單都是以模版的方式保存在數(shù)據(jù)庫中，表單模版中定義表單中填寫的字段、字段的默認值和表單樣式。

由于表單樣式的不可預(yù)見性，因此可以準備一套符合自家產(chǎn)品風(fēng)格的視覺設(shè)計語言，限定表單視覺樣式的框架，包含前面提到的屬性類型呈現(xiàn)樣式，和細化到UI在手寫、PC端、移動端的字體大小、線條風(fēng)格、交互方式、間距、縮進、比例、布局方式等參數(shù)，當(dāng)然本篇由于篇幅限制不展開和視覺風(fēng)格相關(guān)的討論，讀者可自行腦補。

既然是模版，肯定少不了控件，模版由控件組成，在這里把控件分為兩類：屬性組件和容器組件。

表單模版庫表結(jié)構(gòu)

表單模版，是表單的字典表，用于定義表單的基礎(chǔ)信息如名稱、用途說明等，如果與業(yè)務(wù)銜接，還可以添加關(guān)聯(lián)的業(yè)務(wù)、填寫對象、觸發(fā)填寫的時間等，這部分信息由具體的業(yè)務(wù)場景決定，可根據(jù)實際需求設(shè)置字段。

容器組件，負責(zé)定義外觀樣式的組件，決定了屬性組件在表單中的呈現(xiàn)樣式，可根據(jù)不同布局需求細分更多容器組件，這里不展開細講。

• 順序號，在同級下的顯示排序，從左至右，從上至下的原則進行排列。
• 容器名稱，即表單中某方框的名稱，可不填
• 在終端顯示表單時，需要充分考慮各個組件在頁面上的默認布局參數(shù)和可變參數(shù)。通常前面提到的設(shè)計語言中會定義標準的內(nèi)邊距外邊距、線粗和線色等視覺樣式，這些就是默認布局參數(shù)，但組件在表單中的顯示順序、嵌套關(guān)系和組件內(nèi)的組件排列方式等參數(shù)多數(shù)時候是需要配置的，依據(jù)實際需求添加參數(shù)即可。
• 容器組件可嵌套，當(dāng)遭遇多級層級關(guān)系時，用容器組件實現(xiàn)嵌套關(guān)系再好不過了，不建議屬性組件也支持嵌套，因為會提高屬性值的取值復(fù)雜度，除了開發(fā)和數(shù)據(jù)存儲邏輯復(fù)雜度高外，后期數(shù)據(jù)分析時也會進入邏輯黑洞，應(yīng)盡量避免
• 是否支持累加數(shù)據(jù)，此字段用于控制組件內(nèi)的元素，是否可以按照定義的字段多組生成，例如如：

  多套數(shù)據(jù)的支持

  在容器組件主要用藥情況中，屬性組件藥物名稱、用法、用量、用藥時間、服藥依從性的值可以添加多次。

• 還可以添加跟多字段或子表，描述容器更多的視覺布局樣式，比如支持PC端、移動端、打印手寫的樣式定義。

屬性組件，來自于屬性庫中的屬性，決定了表單中填寫的字段信息。

• 容器ID，當(dāng)前屬性組件放置在某個容器組件內(nèi)，若值為null，表示直接放置在表單中
• 屬性別名，為適應(yīng)部分個性化的需求，可以為屬性定義別名，比如身高，對嬰兒通常叫身長，對青少年或成年人叫身高。別名定義到模版中而不是在屬性庫的意義在于，用戶的個性化稱呼通常只會在自己所處的場景內(nèi)使用，對于其他場景下的其他用戶并不一定通用。
• 屬性默認值，很好理解，沒用把這個字段放到屬性庫的理由和別名一樣，場景不同，默認值不一定通用。
• 是否必填，表單提交前判斷必填項的依據(jù)。
• 頁面區(qū)域，用于判斷當(dāng)前組件出現(xiàn)在其父組件的位置，枚舉類型。

屬性組件還可以有更多可擴展特性，后面會提到一些。

業(yè)務(wù)數(shù)據(jù)庫

有了前面的屬性庫和表單模版庫的配置，即可配置出各式各樣的表單，而實際使用這些表單保存下來的數(shù)據(jù)格式是怎樣的呢？

業(yè)務(wù)數(shù)據(jù)庫表結(jié)構(gòu)

表單主表，作為表單的索引表，主要是提供表單的填寫來源、時間戳和與業(yè)務(wù)相關(guān)的標記。

通常實際業(yè)務(wù)有很多附加的信息，圖中給出的是本人面臨的業(yè)務(wù)場景常見的字段。

容器明細表，這里保存了表單內(nèi)負責(zé)樣式的容器數(shù)據(jù)，因為表單模版可能會變更，因此需要將其視覺樣式數(shù)據(jù)保存下來，以記錄當(dāng)時呈現(xiàn)的樣式，避免因為模版變更而造成的布局樣式丟失。

屬性明細表，保存了所有表單的所有字段的值。

• 為了配合容器組件記錄其布局樣式，還添加了容器ID、順序號、組號、頁面區(qū)域，用于記錄保存表單時屬性在表單中的位置。
• 組號，當(dāng)遇到屬性組件放置在允許累加數(shù)據(jù)的容器組件中時，標記出屬性值所在的組。
• 別名，若屬性在模版中配置了別名，則保存在這里，如果值為空，則顯示原屬性名。
• 修改時間，表單可能會遇到修改部分數(shù)據(jù)，因此標記字段的最后修改時間。如果有屬性值的操作日志，可以不要。

樣例

動態(tài)表單樣例

弊端

動態(tài)表單的存在，在一定程度上可以緩解產(chǎn)品迭代因業(yè)務(wù)變更帶來的壓力，但其開發(fā)復(fù)雜度較高，尤其表單模版，解析模版數(shù)據(jù)呈現(xiàn)到終端時，依賴遍歷算法，對程序員的要求不低，若整套產(chǎn)品的應(yīng)用規(guī)模不大，不建議使用動態(tài)表單，或者根據(jù)需求開發(fā)簡配版。

由于表單依賴屬性庫和表單模版的配置，屬性和表單模版的維護質(zhì)量決定了表單的數(shù)據(jù)質(zhì)量，因此需要有高度責(zé)任心和專業(yè)能力的人員來進行屬性庫的維護，提高了使用門檻，但反過來講，羅馬不是一天建成的，如果有野心建立行業(yè)標準，本身也需要大力投入數(shù)據(jù)質(zhì)控。

設(shè)計思想和基本原則

• 產(chǎn)品開發(fā)和業(yè)務(wù)運行盡可能的解耦。業(yè)務(wù)人員不必完全依賴產(chǎn)品業(yè)務(wù)功能的情況下才能運行相關(guān)業(yè)務(wù)（這個問題單獨靠動態(tài)表單無法完全解決，還需要依賴工作流，不過沒有動態(tài)表單時也可以勉強適應(yīng)部分場景做業(yè)務(wù)試運行）；
• 產(chǎn)品永遠做功能迭代，盡量避免數(shù)據(jù)迭代。常見的C端產(chǎn)品往往會有很多的營銷推廣廣告頁，這些廣告頁常常會頻繁變化，而且為了抓熱點往往需要即時響應(yīng)跟進，如果按照每周發(fā)版1-2次的節(jié)奏，等發(fā)出來商業(yè)機會已經(jīng)涼了，因此往往會做一個后臺配置廣告頁的功能，使運營人員可以自行配置廣告頁面，包含頁面元素、入口布局、外鏈引導(dǎo)、渠道埋點配置等等，這就是功能迭代。如果運營改一次廣告，產(chǎn)品即發(fā)一次版，這就是數(shù)據(jù)層迭代。每一次變更都將累積相應(yīng)的數(shù)據(jù)，產(chǎn)品是生成這些數(shù)據(jù)的工具，產(chǎn)生數(shù)據(jù)是業(yè)務(wù)人員做的事情，產(chǎn)品和業(yè)務(wù)是冰淇淋機和賣冰淇淋的小姐姐的關(guān)系。
• 用戶永遠只能看到功能，只關(guān)心產(chǎn)品是否滿足其需求，而產(chǎn)品經(jīng)理永遠要從高低遠近多維視角看待和解構(gòu)需求，不斷的整合、重組、拆分、歸納，窮舉各種場景下的業(yè)務(wù)形態(tài)，在業(yè)務(wù)耦合和模塊化處理上達到平衡，本質(zhì)上是優(yōu)化效率，創(chuàng)造利潤，如果達不到這兩個目的，這個產(chǎn)品不能叫產(chǎn)品，只叫藝術(shù)品。
• 提前預(yù)判功能模塊的發(fā)展趨勢，在設(shè)計初期預(yù)留充分的擴展性和迭代方向，避免高頻率的推倒重來，當(dāng)然如果是敏捷開發(fā)，請無視這條。

意義

• 屬性庫即數(shù)據(jù)規(guī)范，如果數(shù)據(jù)量在行業(yè)中足夠大，適用面足夠廣的情況下，具備發(fā)展為行業(yè)規(guī)范的潛力。
• 表單模版即數(shù)據(jù)接口標準，當(dāng)多個系統(tǒng)需要進行數(shù)據(jù)對接時，最頭疼的往往是梳理數(shù)據(jù)對接標準，將需要對接的數(shù)據(jù)模版通過接口規(guī)范的方式導(dǎo)出給對接方，數(shù)據(jù)字段和取值規(guī)范一目了然，新老系統(tǒng)導(dǎo)數(shù)據(jù)也會用到。
• 數(shù)據(jù)利用更加便捷方便，需要查詢某項具體的屬性數(shù)據(jù)時，只需到屬性明細表中即可找到，無需遍歷其他業(yè)務(wù)表單
• 用戶可通過配置表單明確新需求，表單模版一定程度上提高了用戶需求和功能落地的溝通效率，一定程度上提高了產(chǎn)品的業(yè)務(wù)可擴展性

擴展性

以下是隨意舉例的可能的功能擴展方向，僅作為擴展閱讀。

屬性組件功能擴展

多屬性之間的邏輯約束和默認值：

• 性別為男時，診斷中不可出現(xiàn)婦科疾病；
• 年齡在18-21歲之間，職業(yè)默認值為大學(xué)生；
• 填寫了身份證號碼即可解析出籍貫、性別和出生日期。

單屬性復(fù)用：

姓名性別等字段用戶一旦填寫后，以后再次填寫有這些字段的表單即可自動填寫。

屬性值字典 診斷、癥狀字典數(shù)據(jù)可能依賴外部接口調(diào)取，而非本地屬性值字典庫。

容器組件擴展

• 可配置容器背景圖，視覺優(yōu)化；
• 內(nèi)部元素排列方式支持左對齊、右對齊、垂直排列、水平排列等；
• 可套用整體視覺設(shè)計的皮膚。

模版庫擴展

• 模版插入公用參數(shù)字段，如表單中的制表機構(gòu)、填表人、所在科室等等；
• 表單中的字段可作為工作流業(yè)務(wù)環(huán)節(jié)控制字段，比如當(dāng)支付方式為現(xiàn)金時，無需彈出支付二維碼。

操作日志

• 記錄所有用戶在業(yè)務(wù)表單上的操作記錄，包含操作人、時間戳、修改前屬性值；
• 記錄所有用戶在屬性庫和表單模版庫上的操作記錄。

本文由@魚丸 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載

題圖來自Unsplash，基于CC0協(xié)議