简介中国电信企业数据模型3.0是中国电信CTG-MBOSS体系中EDA分规范的重要分册面向电信行业数据架构、数据治理及系统建设人员用于统一企业级数据标准与模型规范。资源为1个doc文档大小4.45MB内容系统完整便于查阅与复用。文档重点阐述概念数据模型、逻辑数据模型和物理数据模型三个层次本次修订聚焦BSS部分覆盖参与人、产品、帐务、市场营销、事件和地域六大主题域并对模型框架、一级二级分解、建模原则、维护原则和建模方法论作了完整说明。读者可据此完整理解中国电信企业数据模型3.0的体系结构与设计思路为相关系统设计、数据集成和数据治理提供直接参考。已有299人学习下载。1. 企业数据模型3.0从“数据口径打架”到“一张图说话”的那个标准如果你管过三个以上的业务系统大概率经历过这种场面A系统里“用户”指的是开户人B系统里“用户”指的是登录账号C系统里的“用户标识”干脆是设备串号。月底对账时三张表导出来数字永远对不上最后只能靠Excel手工拉平——这种“数据口径打架”的痛做数据的人都有。企业数据模型3.0本质上就是要解决这个问题的它把电信行业里最常见的数据对象比如客户、产品、营销、服务、资源、订单用一套统一的业务语言和编码规则定义出来让各个系统在建设数据仓库、数据中台或做数据共享时能照着同一个模型去对齐口径。这不是一个软件包也不是一套API而是一份“数据层面的架构规范”。适合谁适合正在做数据标准化、数据迁移、数仓建模或数据治理的从业者尤其是那些被“同名不同义、同义不同名”折磨过的人。用一句话概括它的价值它能让你在谈数据时先不谈技术而是把“什么是客户、什么是产品实例、什么是服务保障单”这件事先说清楚。2. 模型定位与整体架构先看懂3.0在数据体系里站在哪个位置2.1 从概念模型到物理模型3.0覆盖的是“中间那一层”数据建模有经典的三层体系概念模型、逻辑模型、物理模型。企业数据模型3.0在这个体系里的位置并不是只做某一层而是把概念层和逻辑层标准化再给物理层留出规范的落地约束。这意味着它关注的是“业务对象应该有哪些实体、每个实体有哪些属性、实体之间是什么关系、编码怎么统一”而不是直接规定某个表引擎里必须建哪张表、字段名必须叫什么。这里有个常见的误解有人拿到3.0的实体清单以为是要照着建表结果发现属性定义里没有字段长度、没有索引建议就开始质疑模型“太虚”。实际上3.0的定位就是“翻译层”——把业务语言翻译成数据语言。它告诉你“客户”和“用户”是两个实体“产品”和“产品实例”不能混为一谈至于落库时用DWD还是DWS、表名带不带日期分区那是物理建模的事需要你结合平台和场景去设计。3.0相比早期版本最大的演进我觉得体现在两个地方一是实体关系的表达更细了不再只是“有联系”这种粗粒度描述而是会区分“一对多”“多对多”以及关系上的关键约束二是对公共编码的治理力度明显加强像“用户标识”这类跨域核心属性3.0会明确它的取值来源和统一编码规则而不是让每个域各自维护一套。这对后续做跨域关联分析帮助是决定性的。2.2 数据分层视角下的3.0它在整合层的作用最关键如果你做过数仓一定熟悉贴源层、整合层、汇总层、应用层这套分层思路。企业数据模型3.0在其中的着力点主要是整合层。贴源层你可以原封不动地把业务系统的表搬进来它不关心口径但到了整合层必须做标准化——这时候没有模型指引你就会面临一个灵魂拷问这个系统的“客户ID”和另一个系统的“客户ID”到底是不是同一个东西该不该关联我一般会这样理解3.0的分层价值它是整合层的“宪法”。在贴源层表的命名、字段类型尽量随源系统在整合层实体的定义、编码的规则、主外键关系要按3.0来到了汇总层已经是对外提供分析服务的结果数据模型的作用更多体现在维度的口径一致性上。换句话说3.0管得最严的就是整合层往上的部分越往上它的约束力越强你越不可能靠“临时映射”蒙混过关。所以在落地时你需要先判断自己的数据体系现在处于哪个成熟度如果还在贴源层打转3.0对你来说是“提前规划”如果已经进入整合层建设3.0是“对准口径”如果已经做到汇总层甚至应用层3.0更多是为“模型重构”和“数据治理”提供依据。不同阶段你对这个标准的投入方式完全不同。这个判断做对了后续才不会出现“模型讲得很美、代码跑不起来”的落差。3. 主题域划分与核心实体模型里到底装了什么3.1 六域框架与实体边界企业数据模型3.0在一级分类上普遍采用主题域的方式来组织。电信行业的业务对象虽然多但归纳下来基本跑不出六个域客户域、产品域、营销域、服务域、资源域、订单域。每个域解决一类核心业务问题域与域之间通过关键实体建立关系。主题域核心业务问题典型实体输出物客户域谁在使用我们的服务客户、账户、用户标识统一客户视图、用户标识编码产品域我们卖什么、用户订了什么产品、产品目录、产品实例产品目录树、实例关系营销域怎么触达与转化营销活动、营销交互、渠道活动效果分析、渠道偏好服务域用户有问题怎么处理服务工单、服务保障、投诉记录服务质量指标、故障关联资源域网络和硬件怎么管理资源、资源规格、资源组网络资源视图、资源利用率订单域业务受理与交付的闭环订单、订单项、订购关系订单时效、交付质量分析这里最核心的一条边界线是“客户”和“用户标识”的区别。客户是自然人或法人是合同签约主体用户标识则对应具体的产品使用账号比如手机号码、宽带账号。一个人可以是客户同时拥有三个用户标识一个客户ID下挂着多条用户标识这是很常见的状态。如果在模型里不区分这两个实体后面做“客户流失预测”时你会把“客户离网”和“用户停机”搅在一起分析结果必然失真。另一个容易踩的边界是“产品”和“产品实例”。产品是目录里的可售项比如“百兆宽带套餐”产品实例是用户实际订购的那个具体套餐有生效时间、有状态、有对应的资源。没有产品实例这个实体你无法回答“目前有多少用户在用的套餐是什么版本”这类运营问题。3.0把这些边界定义清楚实际是在帮你在建模前先做“业务概念对齐”而不是等表建完了再返工。3.2 核心实体与统一编码模型里最值得抄作业的部分主题域下面的核心实体是3.0里最实用的部分。以客户域为例它通常包含客户、账户、用户标识三个核心实体客户记录合同关系账户记录结算关系用户标识记录服务使用关系。三者之间通过“客户—账户—用户标识”这个链式结构关联缺一环都会导致后续账务或服务分析断裂。在编码规范上模型会为每个核心实体指定主键编码规则。这里以“用户标识”为例说明一个常见设计思路它的编码来源通常是业务受理系统在开户时生成的签约号模型会要求各个系统统一引用这个编码作为关联键而不是各建各的编号。你可能会问源系统里的编码格式五花八门怎么办这正是3.0里“编码映射”要解决的问题。它不允许你直接改源系统但要求你在整合层建立一张“编码映射表”把各源系统的编码与统一编码做对应并记录映射关系与生效时间。我建议你在落地时针对每个域的编码规范做一张《主体编码对照表》至少包含源系统表名、源系统字段、业务含义、统一编码规则、映射方式直接映射/值转换/组合生成、生效日期、失效日期。这张表的价值在于它会逼着你和业务方把“你这个编号到底是什么含义”说清楚。做数据的人都有这种体验很多问题不是技术解决不了而是业务定义本身是模糊的。3.0给你提供了一个“强制讨论”的抓手让模糊定义在建模阶段就暴露出来而不是等数据跑完了才发现对不上。4. 从3.0到落地标准如何变成可用的数据资产4.1 五步落地路线现状盘点、差异分析、模型映射、存量转换、模式推广拿到3.0标准后最常见的问题不是看不懂而是不知道第一步干什么。我在实际项目里比较推荐按这五步走每一步都有明确的输入和输出不会让团队陷入“讨论模型理论”的循环。步骤核心动作关键产物完成标志现状盘点梳理各源系统表清单、字段清单、关系清单数据字典、系统清单所有源系统覆盖无遗漏差异分析将源系统数据对象与大主题域对齐差异分析报告每个源对象都标出归属域和未匹配项模型映射按主题域实体定义设计目标模型映射说明书源字段与目标属性映射关系完整存量转换开发ETL脚本做编码转换与数据清洗转换脚本、映射表数据迁移完成且校验通过模式推广把规范固化到新系统建设流程建模规范、编码标准新系统上线即遵循3.0建模这五步里面现状盘点最容易被低估。很多人上来就想做映射但如果你连源系统有哪几张表在表达“客户”都不清楚后面的映射一定会返工。我见过一个项目X业务方说“客户信息都在CRM里”结果盘点完发现至少还有BOSS系统、网厅系统、装维系统三处也在维护客户资料字段含义各有偏差。这个发现直接让整个映射工作量翻倍但也幸好提前暴露了。盘点的产出不只是一张表清单还要标出每个表的“可信度等级”比如哪些是权威源、哪些只是冗余备份、哪些是历史遗留。这个等级会直接决定映射时的优先级。4.2 模型映射与编码转换最花时间、也是最容易出细节问题的一步映射的本质是把“源系统怎么表达”翻译成“3.0怎么定义”。这里有一个很关键的原则映射不是一一对应有三种常见映射方式需要灵活运用。第一是直接映射——源字段和目标属性语义一致比如源系统“USER_NAME”直接对应模型的“用户姓名”。第二是值转换映射——语义相同但取值格式或枚举值不同比如源系统性别用“M/F”模型统一用“1/2”就需要做枚举映射。第三是组合派生映射——目标属性需要由多个源字段计算生成比如“客户全生命周期价值”可能是多个消费字段的组合。我一般建议在映射说明书里明确标注每一条映射的类型并且对“值转换映射”单独维护一张枚举映射表。参数上有三个点你必须在映射阶段就定下来不然后面会翻车。一是时间粒度统一用自然日还是营业日这决定了日期维度的加工逻辑。二是时区归属如果涉及跨地域系统必须确定统一记录的是哪个时区我见过某公司因为一个“业务日期”字段混用了UTC和本地时间导致当日收入统计一连错了一个月都没人发现。三是记录生命周期模型实体是否需要保留历史版本如果是就需要设计生效时间、失效时间两个字段而不是简单覆盖。这三个参数请务必写进映射说明书并且让开发人员逐条确认。5. 落地排查与避坑3.0落地中的典型问题每一条都是血泪经验5.1 坑一实体字典照搬业务语义被“翻译”变形现象团队严格照着核心实体清单建表字段名、类型都按模型来但跑出来分析结果和业务认知完全对不上。例如“客户”应收账龄分析结果和财务口径永远差一大截。原因模型是通用设计落到具体业务时“客户”可能还分“个人客户”“政企客户”它们的合同关系、结算方式完全不同。只建一张大宽表反而丢失了这些细分业务语义。解决一般建议在核心实体基础上增加“业务子类”扩展属性例如“客户实体”增加“客户类别”字段并在维度表中维护子类值域。同时在映射说明书里记录细分规则让下游应用能按子类做数据切片。5.2 坑二编码映射表设计不完整关联查询丢数据现象整合层的用户标识统一了但按统一编码关联客户和产品实例时发现大量孤儿数据。排查半天原来是部分源系统历史数据中的编号没有经过映射。原因编码映射通常只做了“在线业务数据”忽略了历史归档数据、下线系统的数据。这些数据的编号规则可能与现行映射规则完全不同甚至没有维护过映射关系。解决我现在的习惯是在编码映射表里加“映射来源”和“适用范围”两个字段明确这张映射记录是针对哪个系统、哪个时间段的数据。同时在数据迁移脚本里增加“未匹配记录”输出而不是直接丢弃。未匹配的数量和占比反而是最该关注的质量指标。5.3 坑三只改整合层不治理源头系统的数据质量现象整合层按3.0做好了标准化但每次上游源系统数据结构调整整合层就要跟着改一遍。尤其当源系统新增一种“用户状态”枚举值整合层没有及时同步数据直接乱套。原因3.0不是“下游单方面的事”需要上游在产生数据时就遵循相关约定。没有源头治理整合层永远在“救火”。解决更稳妥的做法是把3.0的编码规范“前移”——在源系统新增枚举值时要求同步更新公共码表而不是只在整合层做映射。具体操作上可以在数据平台建一个“公共码表同步接口”源系统发布新业务枚举时先向码表注册再做整合层刷新。数据治理说到底是干这个的不是等数据出错了再清洗而是让错误在源头就没机会产生。5.4 坑四数据质量规则没有挂到模型实体上检查流于形式现象数据质量报告每天生成显示“完整性”“及时性”“一致性”都在99%以上但业务方还是抱怨数据不准。细查发现很多质量规则只检查了表有没有数据根本没有感知到业务语义的变化。比如“产品实例”表的“是否有效”字段在质量报告里是100%有效但业务方指出大量已拆机产品实例状态没有更新。原因质量规则没有从“技术完整性”上升到“业务正确性”。3.0强调的是“实体—属性—值域”的绑定但绝大多数团队的质量规则还在“非空、唯一、外键”这个层面上打转。解决这个解决方案其实很简单把质量规则注册到模型的属性上。在具体落地时我建议先从三类规则入手必填规则哪些属性在什么状态下不允许为空、值域规则枚举类型属性必须来自统一码表、关联规则跨实体关联的记录不能出现悬空引用。每一条规则都关联到3.0模型的具体实体和属性这样质量报告一出来看的人就知道到底是“数据本身错了”还是“业务逻辑变了”。这也是3.0能帮到你的重要场景不然模型建得再漂亮数据质量不达标一切白搭。6. 验证与进阶用3.0给你的数据资产做一次“体检”模型落完怎么判断做得对不对我建议用三个核心指标来验证。一是实体覆盖率现有核心业务对象中有多少已经按3.0实体定义完成映射。理想情况下覆盖率达到80%以上才说明模型骨架搭起来了。二是属性映射率在已映射实体中关键属性与模型定义的匹配程度。属性映射率低于60%的实体说明业务语义还没真正对齐需要回头补映射。三是编码一致性跨系统关联查询时按统一编码关联的命中率。这个指标最能反映“数据有没有真正打通”。具体操作上你可以写一个简单的SQL脚本去检查整合层核心表的主键编码是否全部来自编码映射表并且没有悬空引用。除此之外也可以验证一下“同一用户标识在客户域、产品域、服务域中的记录数是否一致”。这个数一旦对不上基本可以断定关联链路有断裂。进阶做法是把3.0模型当作数据资产目录的骨架。每一个实体、每一项属性都生成对应的元数据标签这样业务方在数据平台上找数据时不是对着“T_CUST_20240101”这样的物理表名去猜而是按“客户域—账户实体—账户状态”这样业务友好路径去浏览。一旦做到这一步企业数据模型3.0就从“建模规范”变成了“数据资产门户”这才是它真正的长期价值。回头说我自己的习惯我每次拿到这类模型规范第一件事不是读全文而是先把“核心实体清单”和“编码规范”这两章读完然后挑一个最熟的域通常是客户域画实体关系图画完对照模型改一遍。这样过一遍之后再去看别的域速度就上来了。希望你也能用这个思路把3.0当成一个“对齐业务语言”的工具而不是一份压在案头的文档。希望帮到你。本文还有配套的精品资源点击获取