圖解主資料的單源與多源以及集中與聯邦管理
關於主資料的單源與多源管理,以及集中與聯邦等管理,相關概念在主資料專案的規劃和應用中都比較重要,是專案各方形成共同語境的重要基礎,並且在實踐中,這幾個概念也常常模糊不清,本文以圖解的方式介紹相關的內容。
主資料的單源管理
主資料的單源是指同類主資料只由一個源系統產生,源系統可以是應用系統,也可以是主資料管理(MDM)系統本身。如圖1所示,供應商主資料只在SRM系統中產生並傳入MDM系統,某類主資料只在應用系統A產生並傳入MDM系統;客戶、專案主資料則直接在MDM系統錄入從而產生,即客戶、專案主資料只在MDM系統中產生。
圖1:主資料的單源管理
對在MDM系統中直接產生的主資料型別,MDM系統負責唯一性控制,並編制主資料編碼,即主資料管理系統的內部賦碼;對由外部應用系統產生的主資料型別,在單源情況下,主要由外部應用系統負責唯一性控制,主資料編碼可以由外部應用系統在產生主資料時一併編制一次性傳給MDM系統,即由外部賦碼,也可以先把主資料傳給MDM系統,由MDM系統編制主資料編碼,然後回傳給應用系統,即仍然可以是MDM系統的內部賦碼,內外部兩種賦碼方式可根據業務需求和應用系統的情況選擇。
對由外部應用系統產生的主資料,唯一性控制主要由外部應用系統負責,例如供應商管理系統中一般也不允許錄入重複的供應商資料,但為最大限度保障主資料的唯一性,MDM系統也可以啟用自己的唯一性控制做輔助,進一步保障進入MDM系統的主資料唯一性。
主資料來自於單一來源,肯定是最理想的情況,單源情況下更容易實現主資料的標準化和唯一性管理,但在很多現實中,由於業務和系統的多樣化及複雜性,往往很難做到單源,所以單源可以作為主資料應用的基本原則儘量去遵循和實現,但也需要根據實際情況和客觀條件以多源的方式管理主資料。
主資料的多源管理
主資料的多源是指同類主資料由多個應用系統產生。如圖2所示,在常見的主資料集團級應用場景下(由集團總部統一建設的一套服務於全集團的主資料管理系統,簡稱統建MDM系統),由於集團多業態,開展不同業務的所屬企業有各自專業的應用系統,都會產生供應商主資料,對子企業A和C所產生的主資料,既有各自獨立使用的,也有共用的,此時,在各應用系統中供應商資料的唯一性控制由各系統自己負責,但在主資料管理層面,供應商主資料的唯一性控制只能由MDM系統負責,即在主資料同類多源的情況下,主資料管理系統對主資料的唯一性起著決定性的作用。
圖2:主資料的多源管理
稍作展開介紹,如圖2,對A公司的SRM和C公司的PMS,都在各自的企業中獨立承擔著各自對供應商完整的管理功能,而一些供應商會同時服務A公司和C公司,那麼在A公司和C公司的系統中就會獨立存在相同的一些供應商。而在整個集團範圍,要求對供應商主資料做唯一性管理(例如,對境內組織機構採用18位的全國組織機構統一社會信用程式碼,對境外的通常只能使用名稱),對某供應商,可能先與A公司合作,先在A公司的SRM系統中建立並傳給集團統建MDM系統產生供應商主資料,後續才與C公司合作,後在C公司的PMS建立C公司要用的該供應商資料,那麼C公司的PMS向集團統建MDM系統傳該供應商資料的時候,基於統建MDM系統的唯一性校驗,會向C公司提示該供應商主資料已經存在。由此說明,在主資料的同類多源情況下,在整個組織的範圍內唯一性只能由MDM系統負責。
同時,與單源主資料不同,在單源時主資料編碼內外部賦碼均可,而在多源時,因為主資料的唯一性控制只能由MDM系統負責,同時導致多個外部應用系統各自都無法產生組織內唯一性的主資料編碼,所以多源時只能由主資料管理系統賦碼。也稍作展開介紹,如上例,因為MDM系統中管理的供應商主資料來自於多個源系統,並且來自多源的資料近乎是隨機插入的,供應商1來自於A公司系統並被統建MDM系統編碼為001,供應商2來自C公司系統並被統建MDM系統編碼為002,003號又來自A公司系統,……,各公司的應用系統不掌握整個集團供應商主資料的唯一性以及編碼狀況,只有集團統建MDM可以掌握這些內容,所以主資料同類多源時只能由MDM系統賦碼。
主資料的集中與聯邦管理
如果在組織範圍內,只有一個主資料管理系統,由該系統全面負責所有的主資料管理,即集中式管控。在集中管控模式下,往往都存在主資料的多源管理,並且在同時滿足更多個性化需求時有更大的管理和技術挑戰,主資料管理系統也會有更大的主資料產生、管理、收發等處理的負荷。
如果因多方面原因,在組織範圍記憶體在多套主資料管理系統,例如集團企業中各企業自建的包括MDM系統在內的一系列系統,每套MDM系統在自己所在的範圍內實現著完整的主資料管理功能,但在集團統一建設集團層面的資訊系統時,必須把全集團相關主資料納管至集團統建的頂層MDM系統中,此時多套主資料管理系統之間就形成了一種至少兩層的聯邦型管控模式。
在技術角度上,所謂聯邦型機制是指組織內有多個獨立的,並且擁有各自完整功能的同類系統,為實現某一體系化的共同功能,按照大家都能遵循的一套規則組成的系統功能集合。相當於各系統本身都是獨立的(一個個聯邦),彼此在各自的範圍內都是一個功能完備的系統,然後大家為了一個共同的目標,按一套互認的規則組織在一起,共同承載一定的功能以實現共同目標。
在聯邦型管控模式下,頂層MDM系統按集團層面要求管理著全部主資料,而各子企業自己的MDM系統仍然只負責管理企業自己的主資料,子企業之間通常不做主資料互動,各子企業MDM系統都會與頂層MDM系統互動。能夠形成聯邦型模式,一定是基於聯邦成員互認的一套規則,在此規則下,多個成員組成了聯邦,在主資料管理中,所有成員互認的規則即是主資料的唯一性,並且這個唯一性必須透過頂層MDM系統的管理才能實現,換言之,對頂層MDM系統而言,各聯邦MDM系統可被認為是頂層MDM系統的多源,所以在集團範圍的唯一性只能由頂層MDM負責與實現。
理想的情況下,由頂層MDM系統為同一類的主資料編制在整個組織範圍內唯一的主資料編碼,各子企業的MDM系統,即聯邦MDM系統都直接使用這個唯一性編碼與頂層MDM系統互動資料。但如果子企業的MDM系統建設更早,已經存在了自己的一套編碼體系,直接替換難度往往很大,此時在子企業的MDM系統中在自己的主資料上可以新增欄位,儲存頂層MDM系統編制的全組織範圍的主資料編碼,子企業自己的應用系統日常使用子企業自己的主資料編碼,當子企業的應用系統與集團統建系統互動時則使用額外儲存的頂層主資料編碼。
因為要同時兼顧更多、更復雜的需求,聯邦型管控模式相比集中式往往更為複雜,聯邦型管控模式也是更為複雜的多源管理,需要更好的規劃設計、功能支援和管理。
來自 “ 貓說資訊化 ”, 原文作者:苗峰79;原文連結:https://mp.weixin.qq.com/s/JasQK_hvYj9rz1jxdwAF0g,如有侵權,請聯絡管理員刪除。
相關文章
- 多資料來源與動態資料來源的權衡
- 聯邦學習:多工思想與聚類聯邦學習聯邦學習聚類
- 容器雲資源資料關聯與資料聯動的難點和解決思路
- 伺服器集中化管理 如何選擇源主機伺服器
- 資源管理與作業系統作業系統
- Java中的多資料來源管理:如何在單個應用中整合多資料庫Java資料庫
- SqlSugar 多資料來源的簡單封裝SqlSugar封裝
- Spring Boot與多資料來源那點事兒~Spring Boot
- 多專案管理-資源管理(3)專案管理
- 多專案管理-資源管理(2)專案管理
- 多專案管理-資源管理(1)專案管理
- springboot liquibase整合mysql與clickhouse多資料來源Spring BootUIMySql
- 聯邦學習開源框架FATE架構聯邦學習框架架構
- Hadoop多使用者資源管理–Fair Scheduler介紹與配置(Yarn)HadoopAIYarn
- Android 資源與屬性備忘單Android
- Spring多資料來源管理實現原理Spring
- Spring-Boot 多資料來源配置+動態資料來源切換+多資料來源事物配置實現主從資料庫儲存分離Springboot資料庫
- Memcache/Redis叢集管理探索與實現:美圖開源PaaS平臺資源閘道器Redis
- 多伺服器運維管理 集中監控與管理平臺伺服器運維
- Atomikos實現多資料來源的事物管理
- 多資料來源配置
- Spring Boot 揭祕與實戰(二) 資料儲存篇 – 資料訪問與多資料來源配置Spring Boot
- Spring Boot 揭祕與實戰(二) 資料儲存篇 - 資料訪問與多資料來源配置Spring Boot
- .NET資料探勘與機器學習開源框架機器學習框架
- webpack與SPA實踐之管理CSS等資源WebCSS
- 基於Spring Boot與Spring Data JPA的多資料來源配置Spring Boot
- 集中式資料庫與分散式資料庫的戰場與戰爭資料庫分散式
- 談談Spring Boot 資料來源載入及其多資料來源簡單實現Spring Boot
- 工時及資源管理:管理者五大挑戰與解決方案
- windows10無法與裝置或資源(主dns)通訊的解決方法WindowsDNS
- 佇列、資源與鎖佇列
- springboot 多資料來源,最簡單的整合方式Spring Boot
- 專案資源管理-日曆圖
- MyBatis配置多資料來源MyBatis
- web 配置多資料來源Web
- 大咖說·圖書分享|深入叢集:大型資料中心資源排程與管理
- 「Golang成長之路」錯誤處理與資源管理Golang
- 多個資料來源的問題