主資料和關係資料-業務系統建模系列
資料庫建模能力在傳統企業業務系統開發中是重要技能之一，相比網際網路公司，程式設計技術雖然不會有太大門檻，但是，業務建模過程中建立好資料關係表，程式碼實現中寫好每一個邏輯細節，對思維能力的方面還是有一定要求的。
本文以供應鏈系統背景為例子介紹
複雜關係資料：多個基本業務單元混雜在一起的表
（圖1）
| 物料ID | 採購商ID | 品類ID | 組織機構ID |
|---|---|---|---|
| m01 | buyer01 | c01 | org01 |
| m02 | buyer01 | c02 | org02 |
| m03 | buyer02 | c03 | org03 |
試想想，你能從這個表看出什麼意思？
首先，上面每個欄位都是供應鏈系統裡的基本業務單元，其分別應該對應一個表。例如，物料的基本業務單元表如下圖2
其次，每個業務單元的組合就構成一種關係，根據數學組合知識，這4個業務基本單元至少可以建立10個表代表10種關係。例如（物料+採購商），（物料+品類），… 等等。
那麼，究竟哪個關係表是正確，哪個關係表不正確，哪些關係表會造成資料不一致？純技術角度回答，是沒有絕對的。衡量的標準是業務當中實際需要反映哪種關係。一定要結合業務思考！
資料不一致的例子
例如，假設有下面3個關係配置資訊表。
採購商分配物料：圖a
| 物料ID | 採購商ID |
|---|---|
| m01 | buyer01 |
採購商分配品類：圖b
| 品類ID | 採購商ID |
|---|---|
| c01 | buyer01 |
建立物料時候物料被歸屬某品類（平臺級配置，與任何採購商無關）： 圖c
| 物料ID | 品類ID |
|---|---|
| m01 | c04 |
然後下訂單, 介面裡下拉列表有采購商,物料。如果校驗條件做不好，產生如下資料：圖d
| 採購商ID | 物料ID |
|---|---|
| buyer01 | m01 |
即採購商buyer01購買了m01物料。問題來了，m01屬於品類c04，但是c04沒有授權分配給buyer01。
如何避免上面問題？
訂單下單介面做好校驗。例如，選擇採購商buyer01後，對物料下拉框列表進行篩查。具體是找那些物料被分配給採購商buyer01（表a）並且該物料對應的品類(表c)也分配給採購商buyer01(表a)。
為什麼有上面的問題？
上面提及的問題產生原因在於圖c的畫蛇添足，圖c反映的是平臺級別物料被歸屬某品類的情況。業務上，這樣做不合理的地方有兩點，一是每家採購商公司的物料都不一樣，系統不可能提前配置所有公司需要的物料；二是每家採購商公司可能把某相同的物料歸類到不同的品類。
有簡單點方案嗎？
在圖c的表取消後，如果系統配置時候對於某採購商新增一個物料，業務規定從採購商品類表選擇任意一個品類分配給該物料，則把品類欄位歸併到圖a，於是物料和品類的關係是建立是基於某採購商公司的維度下的。
| 物料ID | 品類ID | 採購商ID |
|---|---|---|
| m01 | c01 | buyer01 |
這樣，就減少了前面校驗的麻煩性，訂單介面直接選擇物料即可 （該物料在表a存在）。
即採購商buyer01購買了m01物料。m01屬於品類c01。
主資料：不能再切分的基本業務單元
（圖2）
| 品類ID（主鍵ID） | 品類code（業務唯一） | 品類name | 屬性attr |
|---|---|---|---|
| m01 | code01 | name01 | attr01 |
| m02 | code02 | name02 | attr02 |
| m03 | code03 | name03 | attr03 |
以上的品類表可以理解為該品類定義是無組織無機構的獨立於任何外界關係的基本單元，給出品類ID或者品類code都能找到代表該品類的唯一一條記錄，記錄裡有關於該品類的所有屬性資訊。
為什麼有品類的平臺級配置？
既然上文提及圖c的多餘（物料不需要平臺級別的設計），為什麼品類卻可以有圖2的平臺級別的設計呢？
個人認為有三點：
1. 品類資訊相比物料更容易抽象出通用情況，大部分公司都適用
2. 基於產品設計出發定位，因為產品的設計是公有云系統，目標讓所有采購商都使用，大部分的採購商可能不會梳理品類的資訊，系統預設提供品類資訊方便使用
3. 產品的定位希望能做到品類層級的管控