你好！ 我叫安德烈‧謝苗諾夫 (Andrey Semenov)，是 Sportmaster 的高級分析師。 在這篇文章中，我想提出 ERP 系統資料庫的非規範化問題。 我們將研究一般條件以及具體示例 - 假設這將是海盜和水手的絕佳壟斷酒館。 其中海盜和水手必須得到不同的服務，因為這些好先生的美學觀念和消費模式明顯不同。
如何讓大家都開心呢？ 如何才能避免瘋狂地設計和維護這樣的系統？ 如果不只是平常的海盜和水手開始來到酒館怎麼辦？
一切都在削減之中。 但我們還是按順序來吧。
1. 限制和假設
以上所有內容僅適用於關聯式資料庫。 不考慮以修改、刪除和插入異常形式出現的非規範化的後果，這些後果已被廣泛報道，包括在互聯網上。 在本出版物的範圍之外，非規範化也很常見，典型的例子是：護照系列和號碼、日期和時間等。
這篇文章使用了直覺且實際適用的範式定義，沒有參考數學術語。 它們可以應用於實際業務流程 (BP) 的檢查和工業軟體的設計。
有人認為，資料倉儲、報告工具和整合協議（使用資訊的表格表示）的設計與 ERP 系統資料庫的設計不同，因為易於使用和使用有意識的非規範化來實現它可能優先於完整性保護資料。 我同意這個觀點，以下描述的內容僅適用於 ERP 系統的主資料和交易資料模型。
使用大多數讀者在日常層面上可以理解的範例來解釋範式。 然而，作為視覺說明，在第4-5段中，故意使用了一個故意「虛構」的任務。 如果你不這樣做，並採取一些教科書的例子，例如，與第2點相同的順序存儲模型，你可能會發現自己處於這樣一種情況：讀者的焦點將從建議的過程分解轉移到模型中，個人經驗和對如何建立在IS 中儲存資料的流程和模型的看法。 換句話說，聘請兩名合格的 IT 分析師，其中一名為運送乘客的物流人員提供服務，另一名為運輸晶片生產機器的物流人員提供服務。 要求他們創建一個數據模型來存儲有關鐵路旅行的信息，而無需提前討論自動化 BP。
在所提出的模型中，您不僅會發現一組明顯不同的屬性，而且還會發現不同的實體組，這是非零機率的，因為每個分析師都會依賴他熟悉的流程和任務。 在這種情況下，不可能說哪個模型是“正確的”，因為沒有評價標準。
2. 範式
資料庫的第一範式 要求所有屬性的原子性。
特別是，如果物件 A 具有非鍵屬性 a 和 b，例如 c=f(a,b) 並且在描述物件 A 的表中儲存屬性 c 的值，則資料庫中違反了第一範式。 例如，如果訂單規格指示數量，則其計量單位取決於產品類型：在一種情況下，它可以是件，另一公升，在由件組成的第三個包裝中（在上面的 Good_count_WR 模型中） ，那麼資料庫中就違反了屬性的原子性。 在這種情況下，為了說出訂單規範的表簇應該是什麼，你需要對IS中的工作流程進行有針對性的描述，並且由於流程可能不同，因此可能有很多「正確」的版本。
資料庫的第二範式 要求與 IS 中的工作流程相關的每個實體遵守第一個表格及其自己的表格。 如果在一個表中存在依賴關係 c=f1(a) 和 d=f2(b) 且不存在依賴關係 c=f3(b)，則該表中違反了第二範式。 在上面的範例中，訂單表中的訂單和地址之間不存在依賴關係。 更改街道或城市名稱不會影響訂單的基本屬性。
第三範式資料庫 要求遵守第二範式並且不同實體的屬性之間不存在功能依賴性。 這個規則可以表述為：“凡是能計算的都必須計算。” 也就是說，如果有兩個物件A和B，在儲存物件A的屬性的表中，體現了屬性C，而物件B有屬性b，使得c=f4(b)存在，則第三範式被侵犯。 在下面的範例中，訂單記錄中的件數屬性 (Total_count_WR) 明確聲稱違反了第三個範式
3. 我應用標準化的方法
1. 只有目標自動化業務流程才能為分析師在建立資料儲存模型時提供識別實體和屬性的標準。 建立流程模型是建立正常資料模型的先決條件。
2. 如果滿足以下部分或全部條件，實現嚴格意義上的第三範式在創建 ERP 系統的實際實踐中可能並不切合實際：
- 自動化流程很少會發生變化，
- 研究和開發的期限很緊，
- 對資料完整性的要求相對較低（工業軟體中的潛在錯誤不會導致軟體客戶的金錢或客戶損失）
- 等等
在所描述的條件下，從經濟效率的角度來看，識別和描述某些物件及其屬性的生命週期的成本可能不合理。
3. 可以透過對程式碼和測試進行徹底的初步研究來減輕已創建的 IS 中資料模型非規範化的任何後果。
4.非規範化是將人力成本從研究資料來源、設計業務流程階段轉移到開發階段，從實施期轉移到系統開發期的一種方式。
5. 若符合以下條件，建議採用資料庫的第三範式：
- 自動化業務流程的變革方向很難預測
- 實施和/或開發團隊內部分工薄弱
- 積體電路中包含的系統是依照自己的計畫開發
- 數據不一致可能會導致公司失去客戶或金錢
6. 資料模型的設計應由分析師僅結合目標業務流程和IS 中的流程的模型來進行。 如果開發人員正在設計資料模型，他必須將自己沉浸在該主題領域中，特別是要了解屬性值之間的差異 - 這是隔離原子屬性的必要條件。 因此，承擔了不尋常的功能。
4 說明問題
假設您在港口有一家小型機器人酒館。 您的細分市場：進港需要休息的水手和海盜。 你向水手出售加百里香的茶，向海盜出售用於梳理鬍鬚的朗姆酒和骨梳。 酒館本身的服務由機器人女主人和機器人調酒師提供。 你們以高品質、低價格趕走了競爭對手，讓所有下船的人都來到你們的小酒館，這是港口裡唯一的一家。
酒館資訊系統綜合體由以下軟體組成：
- 一種根據特徵識別其類別的客戶預警系統
- 機器人服務員和機器人調酒師控制系統
- 倉庫和配送管理系統到銷售點
- 供應商關係管理系統（SURP）
過程：
預警系統可以辨識離開船隻的人員。 如果一個人鬍子刮得乾乾淨淨，她就認定他是水手；如果發現一個人留著鬍鬚，那麼他就認定他是海盜。
進入酒館，客人會聽到機器人女主人按照他的類別打招呼，例如：“嗬嗬嗬，親愛的海盜，到No號桌去……”
客人來到指定的餐桌，機器人調酒師已經按照品類為他準備好了商品。 機器人調酒師向倉庫系統發送訊息，告知下一批交貨應該增加；倉庫IS根據儲存的剩餘餘額，在管理系統中產生採購請求。
雖然預警系統可能是由您的內部 IT 開發的，但酒吧機器人管理程式可能是由外部承包商專門為您的業務創建的。 用於管理倉庫和與供應商關係的系統是來自市場的客製化打包解決方案。
5. 非規範化的例子及其對軟體開發的影響
在設計業務流程時，受訪主題專家一致表示，世界各地的海盜喝朗姆酒，用骨梳梳理鬍鬚，水手喝百里香茶，總是把鬍子刮得乾乾淨淨。
客戶類型目錄顯示有兩個值：1 - 海盜，2 - 水手，對於公司的整個資訊迴路來說是通用的。
客戶通知系統立即將影像處理結果儲存為識別出的客戶的識別碼（ID）及其類型：水手或海盜。
識別的對象ID
客戶類別
100500
海盜
100501
海盜
100502
水手
讓我們再次注意
1.我們的水手其實都是剃光頭的人
2.我們的海盜其實都是有鬍子的人
在這種情況下需要消除哪些問題，以便我們的結構力求第三個範式：
- 屬性原子性違規 - 客戶端類別
- 將分析的事實和結論混合在一張表中
- 不同實體的屬性之間固定的功能關係。
以標準化形式，我們將得到兩個表：
- 辨識結果以一組既定特徵的形式出現，
識別的對象ID
鬍子
100500
Да
100501
Да
100502
沒有
- 確定客戶端類型的結果，作為嵌入在 IS 中的邏輯的應用程式來解釋已建立的特徵
識別的對象ID
識別碼
客戶類別
100500
100001
海盜
100501
100002
海盜
100502
100003
水手
規範化的資料儲存組織如何促進IP綜合體的發展？ 假設您突然有了新客戶。 就算是日本海盜，他們可能沒有鬍子，但他們走路時肩上扛著一隻鸚鵡，而環保海盜，你可以透過左胸上格蕾塔的藍色側面輕鬆認出他們。
環境海盜自然不能使用骨梳，他們需要用回收的海洋塑膠製成的類似物。
您需要根據新的輸入重新設計程式演算法。 如果遵循規範化規則，那麼您只需補充某些系統中某些流程分支的輸入，並僅針對那些情況和那些臉部毛髮很重要的 IS 中建立新分支。 但是，由於沒有遵循規則，您將必須分析整個電路中的整個程式碼，其中使用了客戶端類型目錄的值，並明確確定在一種情況下該演算法應考慮專業客戶的活動以及其他身體特徵。
以一種形式 尋求 為了標準化，我們將得到兩個包含操作資料的表格和兩個目錄：
- 辨識結果以一組既定特徵的形式出現，
識別的對象ID
葛蕾塔在左胸
肩膀上的鳥
鬍子
100510
1
1
1
100511
0
0
1
100512
1
0
- 確定客戶端類型的結果（讓它成為顯示目錄描述的自訂視圖）
偵測到的非規範化是否意味著系統無法修改以滿足新條件？ 當然不是。 如果我們想像所有的資訊系統都是由一個團隊創建的，人員流動率為零，開發過程有詳細記錄，並且資訊在團隊內部傳輸而不會丟失，那麼所需的更改可以毫不費力地完成。 但如果我們回到問題的原始條件，1,5個鍵盤將被刪除，只是用於列印共同討論的協議，另外0,5個鍵盤用於處理採購程序。
在上面的例子中，所有三個範式都被違反了，讓我們試著分別違反它們。
違反第一範式：
假設貨物是透過您酒館的一隻 1.5 噸的瞪羚提貨從供應商倉庫運送到您的倉庫。 相對於供應商的營業額，您的訂單規模非常小，因此它們總是一對一完成，無需等待生產。 透過這樣的業務流程，您是否需要單獨的表格：車輛、車輛類型，是否有必要將訂單中的計劃和事實分開給離職的供應商？
想像一下，如果您使用下面的模型來開發程序，您的程式設計師將需要編寫多少「額外」連接。
假設我們認為所提出的結構不必要地複雜；在我們的例子中，將訂單記錄中的計劃和事實分開是冗餘信息，並且生成的訂單規範是根據到貨驗收結果重寫的，很少會出現錯誤。- 品質不合格的貨物的分級和到達在 IS 之外進行結算。
然後有一天，你看到整個酒館大廳擠滿了憤怒且蓬頭垢面的海盜。 發生了什麼事？
事實證明，隨著您的業務成長，您的消費也在成長。 曾幾何時，管理層做出了一項決定：如果瞪羚的體積和/或重量超載（這種情況極為罕見），供應商將優先考慮超載，而不是飲料。
未交付的貨物最終進入下一個訂單並搭乘新的航班離開；酒館倉庫中存在最低餘額，因此可以不注意到丟失的情況。
最後一個競爭對手在港口關閉，瞪羚超載的刺穿案例，透過基於最小餘額充足和車輛定期裝載不足的假設的優先順序來繞過，成為常見的做法。 理想情況下，創建的系統將按照嵌入其中的演算法運行，並且將被剝奪任何追蹤履行計劃訂單的系統故障的機會。 只有聲譽受損和不滿意的客戶才能發現問題。
細心的讀者可能已經注意到，第2節和第5節中的訂單規格（T_ORDER_SPEC）中的訂購數量可能滿足也可能不符合第一範式的要求。 這完全取決於給定選定的商品種類，本質上不同的計量單位是否可以屬於同一領域。
違反第二範式：
隨著您的需求成長，您會購買更多不同尺寸的車輛。 在上述情況下，創建車輛目錄被認為是多餘的；因此，所有滿足交付和倉庫需求的數據處理演算法都將貨物從供應商到倉庫的移動視為專門 1,5 噸的航班。羚羊。 因此，在購買新車的同時，您仍然創建一個車輛目錄，但在最終確定時，您必須分析引用貨物移動的所有代碼，以找出每個特定位置是否暗示了該特徵的引用業務開始的那輛車。
違反第三範式：
在您開始創建忠誠度計劃的某個時刻，會出現常客的記錄。 例如，如果在忠誠度計劃開始時，客戶感興趣的所有內容都可以放在客戶的記錄中，為什麼要花時間建立材料視圖來儲存單一客戶的銷售匯總資料以用於報告和傳輸到分析系統？ 事實上，乍一看，沒有任何意義。 但是，每次您的業務連接（例如新的銷售管道）時，您的分析師中都應該有人記住這種聚合屬性的存在。
在設計每個新流程時，例如網路上的銷售、透過連接到通用忠誠度系統的經銷商進行的銷售，必須記住所有新流程都必須確保程式碼層級的資料完整性。 對於一個擁有一千張表的工業資料庫來說，這似乎是一項不可能的任務。
當然，經驗豐富的開發人員知道如何阻止上述所有問題，但在我看來，經驗豐富的分析師的任務不是揭露這些問題。
我要向主要開發人員 Evgeniy Yarukhin 在本書準備過程中提供的寶貴回饋表示感謝。
文學
康諾利·托馬斯，貝格·卡羅琳。 資料庫. 設計、實施和支援。 理論與實踐
來源： www.habr.com