正文概述

附件为22页PDF文件。

一、先理解L1—L5到底在解决什么

华为的数据资产目录采用五层结构，分别是：

L1业务域 → L2主题域 → L3业务对象 → L4逻辑实体 → L5属性。

在华为当前DMAP数小二产品中，L1名称调整为“主题域分组”，之后仍然是L2主题域、L3业务对象、L4逻辑数据实体和L5属性。名称虽然略有差异，但L3—L5的核心逻辑是一致的。

如果用一句人话解释：

L1：企业有哪些大的数据管理领域；

L2：一个领域内部可以分成哪些相对独立的数据主题；

L3：企业到底在管理哪些重要的“人、事、物、地”；

L4：围绕一个业务对象，需要管理哪些相对独立的业务特征；

L5：这些业务特征具体由哪些最小属性描述。

真正的数据架构设计，从L3开始进入核心。

二、L1、L2解决的是“怎么分类”

华为对L1和L2的定义比较清楚。

L1是高层级的数据分类。方案中给出了两种划分思路：按照数据自身特征划分，或者按照业务管理边界划分。为了强化数据管理责任，方案采用的是业务管理边界，让L1尽量与业务职能相匹配。

L2则是在L1下面继续形成互不重叠的数据分类，一个主题域管理一组密切相关的业务对象，通常具有相对一致的数据Owner。

这意味着L1、L2不能简单照搬组织机构，也不适合直接照抄现有系统菜单。

它们本质上是在为后面的L3业务对象建立一个稳定的数据分类框架。

这也是为什么我们在实际项目里，通常会同时看业务架构、业务职责、流程以及现有数据资产，再反复校准L1和L2，而不会拿一张部门组织图直接改成数据目录。

三、L3业务对象从哪里来？答案是业务流程

这是华为这套方法里非常关键的一点。

业务对象不是从数据库表里找出来的，而是从业务中识别出来的。

华为给出的路径是：业务流程 → 流程活动 → 输入/输出信息 → 候选业务对象。

比如一条销售流程可能包含：线索跟进 → 商机评估 → 报价 → 下单 → 发货 → 回款。

这些是业务活动。

继续看每个活动处理的信息，就可能识别出：客户、机会点、报价单、订单、发货单、回款单。

这些才是业务对象。

华为对候选业务对象还给出了几条比较实用的判断原则：它应该是业务运行中重要的人、事、物、地；具有唯一身份；能够相对独立存在；同时能够实例化，产生具体的业务记录。

这一点非常重要。之前写过一篇文章，详见：华为对【业务对象】的理解。

比如“客户名称”“订单金额”“合同状态”，一般都不应该作为L3，因为它们更像对象属性。

“客户管理”“订单处理”也通常不是L3，因为它们更偏业务活动或管理行为。

L3回答的是：企业到底在管理什么，而不是企业在做什么。

四、确定L3之后，还要把Data Owner定下来

很多企业把数据目录做到业务对象这一层就结束了，其实还差了一步。

华为在L3业务对象识别过程中，把Data Owner确定直接放进了同一个工作步骤。

因为一个业务对象如果没有明确的数据责任主体，后面很多事情都会失去落脚点：

谁定义？谁维护？谁判断质量问题？谁确认权威数据源？谁有权修改业务规则？

所以一个完整的L3对象，实际上应该继续挂接：

所属业务域、主题域、Data Owner、逻辑实体、数据源、数据分类等信息。

做到这里，数据资源目录才开始从一棵“分类树”，变成企业的数据责任体系。

五、L3怎么拆成L4？核心是“业务特征”

L4是整个五层设计中最容易做错的一层。

华为给出的定义很准确：逻辑实体是描述业务对象某种业务特征的一组具有逻辑关系的属性集合。

这里最关键的四个字就是：业务特征。

例如“客户”是L3业务对象，它内部可能进一步存在：

客户基本信息；客户联系信息；客户信用信息。

它们描述的是同一个客户的不同业务特征，因此可以设计为不同的L4逻辑实体。

再比如“报价单”，可能拆成：报价单头、报价单行。

报价单头描述报价单整体信息，报价单行描述具体商品、数量、价格等明细，这就是典型的L3到L4拆分。

华为同时给出了一组比较严格的规则：

L4不能脱离L3单独存在；一个L4不能同时归属于多个L3；L3与L4只能是1:1或1:N；

跨业务领域共享的基础数据可以单独形成逻辑实体；

对象之间的关系实体，需要按照业务发生关系确定归属；

逻辑实体阶段不做年份、地区等水平拆分，这类拆分留给物理模型。

这些规则很实用，因为它们直接限制了L4设计过程中最常见的“随便拆”。

六、L4到底拆到哪里停？

知道怎么拆以后，还有一个更现实的问题：

拆到什么时候算完？

华为的建议规则给了方向：描述不同业务特征的属性集合，可以独立形成逻辑实体；只在特定业务场景中使用的一组属性，也可以进行纵向拆分。

结合实际项目，我觉得可以把颗粒度判断进一步简化成一句话：

L4拆到一个能够独立描述、独立管理的业务特征即可。

比如“客户基本信息”作为一个整体有明确业务含义，那么它可以是L4。

继续向下的：客户编号、客户名称、客户类型……

已经是描述这个业务特征的具体属性，就应该进入L5，而不应该继续把每个字段都包装成一个L4。

所以L4通常存在两个典型问题：

拆分不足：几百个不同性质的属性全堆在一个逻辑实体里。

拆分过度：按照数据库表、年份、地区甚至单个字段机械拆分。

两种方式都会让逻辑模型失去业务含义。

七、L5是业务属性，不等于数据库字段

L5是最容易被IT人员直接理解成“字段”的一层。

华为对L5的定义是：描述业务对象某方面特征的最小颗粒度属性信息。属性设计需要参考业务流程、业务规则和业务规格，并通过业务检查、交叉检查保证完整性和准确性。

所以更准确的理解应该是：

L5首先是业务属性，在物理模型中通常进一步映射为字段。

例如：L3：报价单

下面拆成：L4：报价单头、报价单行

报价单头可以包含：报价单号、报价日期、客户、总金额……

报价单行包含：Part编码、产品、数量、单价……

这些才是L5属性。

华为当前DMAP文档也明确指出，L4在物理实现中通常对应一张或多张表、API等，而L5通常对应到物理表字段。这里强调的是映射关系，并不是说设计L5应该从数据库字段开始。

这个区别非常重要。

否则数据架构很容易重新退化成一次数据库盘点。

八、到了L5，数据架构还没有结束

L1—L5只是把企业的数据“讲清楚”。

后面还要继续解决三个问题。

1. 数据标准

对于重要L5属性，需要定义统一的数据标准，包括名称、业务定义、业务规则、数据类型、长度、允许值、值域等，使不同系统对同一个数据具有一致理解。华为当前的数据要素专业服务仍然明确要求，针对重要L5属性设计数据标准，并明确其定义、所属业务域以及Data Owner。

2. 数据模型

L3业务对象及其关系可以进一步形成概念数据模型，L4和L5则继续展开为逻辑数据模型，再结合具体数据库形成物理数据模型。

也就是：CDM → LDM → PDM。

3. 数据分布

最后还要明确：数据从哪里正式产生？哪个系统是权威数据源？哪些系统使用？如何流转？

华为明确提出，数据源应当是业务上首次正式发布该项数据、经过认证的应用系统，关键数据应明确唯一数据源。

所以完整的数据架构设计，最终应该形成这样一条链：

业务理解 → L1业务域 → L2主题域 → L3业务对象 → Data Owner → L4逻辑实体 → L5属性 → 数据标准 → 数据模型 → 数据分布与权威数据源

九、“自上而下＋自下而上”，这句话很重要

华为目前的数据要素实施服务中，有一句非常值得注意的话：

数据资产目录按照“自上而下”和“自下而上”相结合的方式设计。

这其实把实际项目中的方法说得很清楚。

自上而下看：

战略、业务架构、业务职能、业务流程、业务规则。

用于发现企业“应该有什么数据”。

自下而上看：

现有系统、数据库表、字段、接口、数据字典。

用于验证企业“现在到底有什么数据”。

两条线最后需要在L3、L4、L5逐层校验。

业务有、系统没有，可能意味着数据缺失或者系统能力缺口；

系统有、业务上解释不清，则需要进一步判断它是技术数据、历史遗留数据，还是业务定义本身没有梳理清楚。

只做自上而下，容易落不了地；只做自下而上，最后又会变成数据库目录。

这也是我们在实际项目中更倾向采用双向校验的原因。

十、22页PPT详解

从业务出发找到稳定的业务对象，在L3建立企业统一的数据语言；按照业务特征拆成L4逻辑实体；再向下形成L5业务属性，并继续连接数据标准、逻辑模型、物理模型和权威数据源。

这样做出来的数据资源目录，才真正能够连接业务架构、数据治理和IT建设。如果只是把已有数据库中的表和字段重新分个类，那还不能算真正意义上的企业级数据架构。

注：上传图片压缩导致不清晰，文末阅读原文下载高清完整版。

业务架构企业经验华为系列战略技术实现数据架构数据资产文章文章知识架构治理流程解决方案资料下载

自2026年起，所有内容均为EA之家原创，享有内容版权，盗版必究。2026年之前部分案例来源于各文库类平台，如有标错或文章所使用的图片文字链接等涉及侵权，请尽快与我们联系处理，谢谢。
EA之家 » 一篇看懂：详解华为数据资源目录L1到L5设计方法，附案例22页PDF

分享到：