談談資料建模和設計成功的三大能力
資料建模可以幫助標準化組織定義和描述其資料的方式,健全的資料模型能夠加速資料目錄的實施和資料質量計劃的啟動。根據資料建模經驗,我們探討組織如何透過關注三個關鍵子功能來增強其資料建模能力:元建模、概念和邏輯資料建模以及物理資料建模。對於每項子功能,它將描述高度成熟度是什麼樣子,並將以整體最佳實踐和成功因素作為結尾。
一 資料建模的三個能力
讓我們從資料建模的基本元件開始:
-
元建模——元建模是資料建模的一項子功能,涉及建立定義其他模型的結構、概念和關係的模型。元模型提供了一種定義和描述模型及其元件的標準化方法,這有助於確保這些模型的開發和使用的一致性和清晰度。元模型涵蓋概念、邏輯和物理模型,並定義各個元件如何一致地連結在一起。
-
概念和邏輯資料建模——概念和邏輯資料建模是資料建模的子功能,包括建立面向業務的資料檢視,捕獲特定領域(例如客戶、員工和產品)涉及的主要實體、關係和屬性。邏輯資料建模透過新增更多細節(例如指定資料型別、鍵和實體之間的關係)以及將概念域分解為邏輯屬性(例如客戶名稱、員工名稱和產品 SKU)來細化概念模型。
概念模型在最高層次上解釋了各自的領域或概念是什麼,以及它們之間的關係。在以上示例中,可以看到交易形成了一個關鍵概念,其中每筆交易都可以連結到已售產品、購買產品的客戶、付款方式以及購買所在的商店。其中每一項構成了自己的概念。此外,關係顯示每個單獨的交易最多可以有一個與之關聯的客戶、商店或員工,但這些反過來又可以與許多交易相關聯。
在邏輯模型中,概念或域被分解為邏輯屬性。這樣的邏輯模型與底層元模型一致,現在可以轉換為物理模型,其中新增了有關這些資料屬性存在的確切位置,例如,在什麼表中以及以什麼格式存在的詳細資訊。
在物理模型中,進一步的技術細節被新增到邏輯模型中,例如澄清表名稱、列名稱和資料型別。
二 資料建模需要考慮的內容
資料建模的高度成熟需要考慮幾個維度:
-
策略——組織的整體資料建模策略,包括資料建模工作與業務目標的一致性。
-
人員——明確特定角色及其職責,以及所需的專業知識、技能和培訓。
-
流程——流程和工作流程,包括資料建模方法的文件、資料建模模板和標準的開發以及質量控制和稽核流程的建立。
-
技術——支援資料建模工作所需的工具,例如資料建模軟體和工具,以及資料建模工具與其他系統和應用程式的整合。
-
應用——在組織內部和整個組織內應用和使用資料建模實踐。這可能包括應用計劃、解決應用障礙以及衡量資料建模工作的有效性和影響的跟蹤指標。
讓我們將其應用到三個子能力中。
元模型
-
元建模的高度成熟是擁有一個定義明確且廣泛採用的元模型,並在整個組織中一致使用。為了確認需要一個,而且只需要一個。如果沒有適當的元模型(比方說,通用語言的基本語法和詞彙),各種資料模型可能會湧現,導致跨領域、流程和系統的可解釋性和互操作性問題。
-
需要了解元模型並且能夠維護和解釋元模型的人。建議由一個人對元模型擁有最終權力。他可以接受反饋並收集變更請求,以確保其符合並保持符合目的。
-
定義的過程應該描述如何在建模活動中使用元模型。它的採用應該在資料建模者、資料架構師和資料工程師中廣泛採用。
-
資料目錄或後設資料管理系統等工具可以提供用於儲存和管理元模型的集中儲存庫,並且可以支援協作和版本控制。
概念和邏輯資料建模
-
高成熟度是對概念和邏輯資料建模採用定義明確且一致的方法,並嚴格遵守元模型。概念域應該有一個所有者,並且應該有一個結構化的過程來建立新的邏輯屬性,然後對其進行審查、批准和釋出。
-
對域和邏輯屬性進行建模是一項技能,而且是一項罕見的技能。它既需要核心資料建模專業知識,又需要能夠將其對映到現實業務領域,以對業務和技術組織都有意義的邏輯屬性進行描述。
-
概念資料模型應該明確與企業或業務架構保持一致,並與分配資料所有權的資料域保持一致。
-
資料建模軟體可用於大規模建立和維護概念和邏輯資料模型。這些工具可以提供模型的視覺化表示,並且可以支援協作、版本控制以及與其他系統(例如資料目錄或後設資料管理系統)的整合。業務術語表可用於定義和標準化模型中使用的業務概念和術語。
物理資料建模
-
物理資料建模的高成熟度級別通常包括擁有精心設計且高效的資料庫模式,以滿足適用的效能和可擴充套件性要求。這需要擁有能夠設計和實現模式的人員、定義明確的模式開發和維護流程以及支援模式設計和實現的適當技術工具。
-
資料庫設計軟體可用於建立和維護物理資料模型。這些工具可以從邏輯資料模型生成資料庫模式,並且可以支援協作、版本控制以及與其他系統(例如資料目錄或後設資料管理系統)的整合。資料字典還可用於定義和標準化技術細節,例如資料型別、約束和其他資料庫物件。
三 最佳實踐和成功因素
為了增強資料建模能力,組織可以遵循一些最佳實踐和成功因素:
-
首先獲得正確的元模型。元模型驅動整個企業的可重用性和一致性。它確保所有後續建模工作逐步構建整體模型。如果這些沒有到位,那麼面臨一項艱鉅的任務,即在未來調整和橋接現有的、不相容的模型。
-
考慮預製的工業或通用模型。根據所處的階段,可以考慮採用預先存在的資料模型。這可以推動與國際最佳實踐和標準的一致,節省從頭開始構建模型的時間和精力,並實現與外部各方高效、可靠的資料交換。例如,BIAN提供了標準化的銀行服務參考模型,為銀行業定義了通用語言、分類法和業務流程框架。
-
在概念、邏輯和物理之間進行迭代。資料建模需要時間,這項工作永遠無法完成。建議對域進行優先順序排序(客戶和產品等參考域是很好的候選域),並從 1 或 2 開始,在進入下一個域之前,首先完成邏輯模型,然後是物理模型的指南。
-
不要過於複雜。資料建模可能很複雜、耗時,因此成本高昂。完成基本的概念和邏輯模型幾乎總是絕對值得付出努力,但一旦進入物理領域,可能不需要集中指導和捕獲所有物理模型。可能還想在這裡確定優先順序,例如,確定“關鍵任務”系統並記錄這些系統的物理模型,但對於其他系統,確保本地應用程式所有者遵守特定的建模規範和標準可能就足夠了。
-
戰略性地實施技術。它們可能很昂貴,並且可能不需要它們用於第一個域,但最終資料模型的大小和複雜性將呈指數級增長。考慮資料目錄、業務術語表和資料字典,或者可以充當所有這些的東西。沒有它,資料價值創造將會很差。
四 小結
資料建模是一項關鍵能力,可幫助組織確保其資料設計良好、一致且有效支援業務需求。透過專注於元建模、概念和邏輯資料建模以及物理資料建模等子能力,組織可以提高其成熟度,並使業務使用者和資料科學家能夠始終如一地為各自的用例找到正確的資料。
來自 “ 資料驅動智慧 ”, 原文作者:曉曉;原文連結:https://mp.weixin.qq.com/s/Ex98dDEnNSEEtS9YDfAf3w,如有侵權,請聯絡管理員刪除。
相關文章
- 談談阻礙資料建模的5大藉口
- 談一談阻礙資料建模的5大藉口
- 談談VB的資料庫程式設計方式 (轉)資料庫程式設計
- 談談資料目錄應具備的四大能力
- 談談 "JS 和 設計泛型"JS泛型
- 談談資料湖和資料倉儲
- 談談關於設計資料管理/治理角色的問題
- 談談程式設計師的離職和跳槽程式設計師
- 談談資料資產和資料產品的異同
- 資料庫設計經驗談資料庫
- 淺談資料庫設計技巧資料庫
- 談談透過有效的指標設計推動運營成功的方法指標
- 談談資料湖分散式資料治理的資料目錄應具備的四大能力分散式
- 四面阿里成功定級P6,想和Java程式設計師談一談阿里Java程式設計師
- App架構設計經驗談:資料層的設計APP架構
- 談談人工智慧和機器學習的資料架構人工智慧機器學習架構
- 談談主動式後設資料管理
- 談談設計模式 —— Iterator設計模式
- 談談程式設計師程式設計師
- 專家訪談之:可用性專家談網站設計成功的關鍵網站
- 也談應用之“基石”——資料庫設計資料庫
- 淺談資料庫設計技巧(下)(轉)資料庫
- 資料庫物理設計經驗談(二)資料庫
- 資料庫物理設計經驗談(一)資料庫
- 大佬視角:談談程式設計師的離職和跳槽程式設計師
- 談談小城市程式設計師的迷茫和堅持程式設計師
- 談談 MyBatis 的外掛化設計MyBatis
- 談談對程式設計師的管理程式設計師
- 談談工作中的設計模式設計模式
- 談談UI架構設計的演化UI架構
- 談談資料產品團隊的角色和職責
- 談談我和大資料的情緣及入門大資料
- 創新性應用 資料建模經驗談(轉)
- 談一談資料管理的格局
- 談談資料的貨幣化
- 從JS物件開始,談一談前端“不可變資料”和函數語言程式設計JS物件前端函數程式設計
- 談談遊戲難度設計遊戲
- 談談非同步程式設計非同步程式設計