跳到主要内容
自媒科技企业 AI · 项目开发与交付
中文ZH
项目询价
项目询价

企业 AI 项目 Wiki · 数据、知识与模型

业务数据

也常写作Business data · 业务信息数据 · 业务运营数据 · 业务领域数据 · 经营业务数据

定义

业务数据是组织在开展业务或使命流程时产生、取得、维护或使用，并以可识别形式表示业务对象及其属性、业务事件与交易、状态变化、决定、责任或业务结果的数据。它以业务含义和用途划定，而不是由表名、文件格式、存储位置或是否来自生产环境决定。

业务数据按业务含义和用途识别，不按数据库位置识别

业务数据回答组织正在处理谁、什么对象、发生了什么、处于什么状态、作出了什么决定以及产生了什么结果。客户、供应商、产品和合同是对象；订单、申请、付款和服务工单是交易或业务记录；提交、批准、发货和取消是事件；金额、状态、责任人和生效日期是描述这些事实的属性。

它可以存在于数据库、消息、文件、表格、文档、录音转写或纸质材料中，也可能暂存在人工队列或外部系统。保存到生产数据库的数据不一定都是业务数据，例如运行时内存指标；存在测试环境的数据也可能是业务数据的副本。分类依据是含义、用途和责任，而不是介质或环境名称。

“业务数据”在行业与组织间是一个实用总称，不应强行套用单一分类。GS1 在供应链语境中明确区分描述实体的主数据、支持组织间流程的交易数据和反映物理或数字过程的可见性事件数据；其他行业可能使用客户数据、运营数据、案件数据、临床数据或任务数据等领域分类。项目应登记自己的分类和映射。

从业务对象、事实和过程识别，而不是把所有表都导出

数据库里既有正式业务记录，也有缓存、技术日志和为了实现而拆开的中间表。识别业务数据要回到客户、合同、申请、付款等对象以及它们经历的事件和决定，才能知道哪些内容需要长期解释、交接和治理。

  1. 确定业务或使命边界

    先说明本项目支持的产品、服务、客户旅程、内部职能、地域与组织单位；范围外系统中的同名数据不自动进入本项目。

  2. 列出对象与参与方

    识别客户、员工、供应商、产品、资产、合同、申请、案件等需要稳定识别的对象，以及自然人、组织、系统和代理角色。

  3. 沿场景标出事件和交易

    逐步检查创建、提交、确认、批准、履行、付款、变更、取消、关闭和争议等正常与异常事件，记录输入事实与产生结果。

  4. 区分当前状态和历史事实

    当前余额或当前状态可以由历史交易和事件导出；项目须确定保存哪一层、怎样重算，以及更正能否覆盖历史。

  5. 识别决定、理由和证据

    找出业务决定使用的数据、适用规则、批准主体、 supporting material 和结果；不是每份附件都等同于已核实事实。

  6. 盘点副本与下游用途

    追踪数据进入报表、搜索索引、缓存、仓库、导出、第三方服务和模型上下文后的身份、时点和用途变化。

  7. 由有权角色确认分类

    业务责任、数据管理、记录管理、安全隐私、运营和技术角色共同确认对象、权威、敏感性、记录地位和生命周期，不由扫描脚本单独裁定。

业务数据可以怎样分类

分类不是为了给每张表贴标签，而是为了区分不同责任。主数据需要稳定身份，交易数据保留发生过程，参考数据控制允许值，分析派生数据还要说明计算与适用时间。类型不同，正本、质量和变更方式也不同。

主数据

跨流程反复引用、用于一致识别核心实体的相对稳定数据，如客户、供应商、产品、地点和组织。它会变化，但变化频率通常低于交易，并需要权威和同步治理。

参考数据

用于分类或约束其他数据的一组允许值、代码、单位、地域、状态或汇率类型。它不必代表具体业务实体，适用版本和生效期很重要。

交易数据

记录具有业务或财务意义的交互与承诺，如采购订单、发票、付款、退货和服务请求；通常引用主数据并具有金额、状态和责任。

事件数据

记录某事在某时发生，如提交、扫描、发货、签收、批准或设备触发。事件可以推动状态，但并非每个事件都形成合同或财务交易。

状态与运营数据

表示对象当前所处阶段、队列、余额、库存、可用性或处理位置；须说明是权威状态、计算快照还是最终一致的观察值。

业务文档与内容

合同、申请、票据、邮件、图片、录音和说明等非结构化或半结构化材料，以及其结构、签署、版本和证据关系。文件不是天然可信，内容也需解释。

决定、规则执行与审计事实

保存采用的规则版本、输入事实、决定、批准或覆盖、执行主体与时间，以证明为何得到某个业务结果；技术审计日志只是可能的证据载体。

派生与分析结果

报表指标、聚合、预测、评分、分群和模型输出由其他数据计算。必须标明方法、时间、版本和适用用途，不能无条件回写成原始事实。

业务语义要把对象、时间、状态和允许值说清

“金额”“客户”“已完成”这些词看似普通，在不同系统中可能指含税或未税、签约方或联系人、提交完成或付款完成。语义要把对象和时间边界说清，使人员、规则、报表和接口对同一个值作同样解释。

对象身份

定义什么构成同一客户、供应商、产品、申请或合同，标识由谁生成、能否复用、合并拆分怎样保留历史，避免用名称当唯一身份。

属性含义

每个重要字段说明对象、特征、单位、精度、允许值、空值含义和适用上下文。ISO/IEC 11179 强调数据元素同时需要语义和表示描述。

业务时间

区分发生、收到、登记、生效、失效、结算、修正和观察时间，并定义时区和迟到事件处理；updated_at 不能代表全部时间语义。

状态与转换

定义状态代表的业务事实、允许进入退出条件、终态、撤销和更正规则。界面显示文字、数据库代码和外部系统状态需受控映射。

金额和数量

记录币种、含税口径、单位、精度、舍入、汇率来源和汇总规则；“总额”必须说明由哪些明细在什么时点计算。

真实性和确认程度

区分用户声称、系统验证、第三方返回、模型推断、人工确认和正式批准；资料存在不等于事实已经核实。

版本和有效期

主数据、代码表、条款、规则和派生指标都可能随时间变化，结果应能还原当时适用版本，不用当前定义解释全部历史。

每类业务数据都要知道谁定义、谁确认、哪里是正本

多个系统都保存同一字段时，“最新的一份”不一定是正本。团队要明确谁有权定义含义、哪个系统产生正式事实、谁能批准更正，以及副本多久同步。发生争议时，才能依据治理关系判断，而不是比较时间戳猜答案。

业务定义责任

由理解业务并获授权的角色确认含义、规则、质量和适用范围；技术团队可以维护载体，但不能凭数据库现状决定业务真相。

正本系统或权威证据

逐对象或逐属性说明以哪个系统、签署文件、外部登记或有权决定为准。一个系统可能是客户地址正本，却不是信用状态正本。

记录创建与确认

区分录入者、事实提供者、复核者、批准者和系统生成者，保留代理、委托、批量和自动决定的身份链。

技术保管与平台责任

明确数据库、文件库、消息平台、仓库和备份由谁运行、保护、恢复与监测；技术保管不自动获得所有业务使用权。

数据使用者责任

消费者须遵守目的、时点、质量、访问和再传播条件，不能因获得副本便把它改造成新的权威来源。

冲突裁定和升级

为多个来源不一致、人工与系统结果冲突、历史更正和外部来源不可用设置裁定角色、暂存状态、停止条件和证据。

业务数据随业务事件变化，副本和派生物也属于生命周期

一笔申请从草稿到批准、撤回或关闭，会留下当前状态、历史事件、通知、报表和缓存。删除或更正正本不代表这些副本自动变化。生命周期治理要沿传播路径处理，避免旧事实继续影响决定。

业务数据的生命周期不是简单的创建—存储—删除直线。申请可以成为订单，订单产生交付和发票，付款改变余额，取消产生补偿事件；原记录、当前状态、快照和下游汇总之间形成关系网。设计时应确定哪些事实不可变、哪些以新事件更正、哪些可以覆盖，以及怎样重建某一时点的状态。

NIST Privacy Framework 把采集、保留、记录、生成、转换、使用、披露、共享、传输和处置都视为数据处理动作。即使不涉及个人数据，这个动作清单也有助于发现缓存、索引、导出和第三方副本；涉及个人数据时，还须由有权隐私角色确认目的和风险。

不是所有业务数据都会成为正式记录，也不是只有 PDF 才是记录。NARA 的记录管理资料强调，记录用于证明组织的政策、交易、决定和行动，并需经过创建或接收、维护使用和处置。项目应由适用的记录管理与法律责任确定哪些数据、文档、元数据和系统文档需要作为记录保存。

  1. 业务状态能从证据重建吗？

    重要结果能连接原始事实、事件、规则、决定和更正，而不是只保留当前值。

    核对：抽样时点重建与对账。

  2. 副本和派生物有身份吗？

    报表、仓库、索引、导出和第三方副本标明源、时点、刷新和允许用途。

    核对：数据流和处理清单。

  3. 记录地位由有权角色确认吗？

    保存期、法定保全和处置不由开发团队或数据库 TTL 自行决定。

    核对：记录类别、保存表和批准。

质量、完整性和保护要连接具体业务后果

缺一个电话分机和错一个付款账户，都是数据错误，后果却完全不同。质量优先级、访问保护和修复时限要围绕业务用途与损害决定；不能用总体完整率掩盖少量但严重的记录问题。

用途适配质量

为提交、付款、服务、报告、预测或审计分别规定准确、完整、一致、及时、唯一和有效等需要；同一副本不能默认适合所有用途。

完整性与不可否认事实

重要交易和决定防止未授权改变，保留来源、顺序、校验、批准和更正痕迹。NIST SP 1800-26 提供检测与响应数据完整性事件的工程参考。

机密性和最小使用

按数据类型、主体、目的和风险限制查看、导出、共享与分析，减少非必要字段和保存；“内部数据”不等于所有员工可见。

可用性和恢复

确定业务在数据不可用、延迟或结果不确定时的停止、只读、排队、人工或恢复路径，并验证恢复后状态与外部交易一致。

信息类型与风险分类

NIST SP 800-60 展示了按信息类型和机密性、完整性、可用性影响进行安全分类的方法。具体项目须采用适用制度，不能直接复制联邦分类结论。

问题处置

质量或保护事件记录受影响对象、期间、来源、下游、业务决定和责任，执行隔离、修正、重算、通知、撤销或有权接受并关闭。

项目交付时不能只移交数据库备份

备份能恢复字节，却不一定告诉接手团队每个对象代表什么、哪一处是正本、如何校验或怎样合法删除。交接还需要词汇、血缘、权限、质量规则、保留安排和未解决问题，数据才能在原团队离开后继续可靠使用。

业务数据目录

按领域列出对象、事件、交易、状态、文档和派生结果，标明用途、责任、正本、敏感性、记录地位及主要消费者。

定义与映射

移交数据字典、代码表、对象关系、状态机、源目标映射、转换和对账规则的受控版本，保留尚未确认项及负责人。

访问和运行责任

说明生产、支持、报表、导出、第三方和紧急访问，账号移交不应扩大业务权限；审计和定期复核能继续执行。

初始化与迁移证据

记录迁移范围、批次、排除、清洗、失败、前后计数与关键金额、抽样结果、差异关闭、批准和旧系统冻结时点。

备份恢复和连续性

区分业务正本、恢复副本和归档，说明恢复点、恢复时间、密钥、依赖、演练、恢复后对账及不能通过代码回滚撤销的业务交易。

保留、导出和退役

交接保存与处置规则、保全、可读导出、第三方返还或删除、系统文档和退役证据，使接手方无需猜测长期义务。

采购申请中的业务数据构造例子

下面用独立构造、与任何客户无关的采购申请，把对象身份、状态事件、决定记录和派生指标放在一起观察。重点不是字段设计，而是每类数据怎样回到权威来源、业务时间和允许用途。

业务对象

申请、申请人、供应商、采购项目、预算对象、合同和附件分别有稳定身份；供应商引用获批主数据，申请保留提交时必要快照。

交易与金额

申请明细记录项目、数量、单位、币种、税务口径、价格来源和舍入；总额是带规则和版本的派生结果，不是来源不明的独立事实。

事件与状态

创建、提交、退回、改正、批准、拒绝、发送 ERP、接收确认和取消分别记录事件时间、登记时间、主体、前后状态和原因。

决定与证据

批准结果连接当时的输入事实、规则版本、审批权限、意见和材料；AI 摘要或风险提示标明为辅助派生结果，不能冒充批准事实。

正本与副本

申请系统是申请流程状态正本，身份平台是主体身份来源，供应商主数据是供应商有效状态来源，ERP 是否成功建单以双方对账结果确认。

记录和生命周期

业务与记录责任确认哪些申请、批准、附件、接口确认和审计事实形成正式记录，并规定更正、保全、保存、导出和处置；测试副本另行脱敏与销毁。

企业 AI 使用业务数据时，输入事实、知识和模型输出不能混成一层

模型可以把记录整理成摘要、标签或建议，但流畅表达不会把推断变成正式事实。如果生成结果和权威数据存进同一字段、又没有来源与审核状态，下一次检索就可能把自己的旧猜测当作新证据。

限定获批业务用途

明确业务数据用于检索、摘要、抽取、分类、建议、预测还是执行，哪些高影响决定禁止仅由模型完成；能够访问不表示可以训练或跨目的复用。

先分清这是正式事实、他人陈述，还是模型的推断

权威记录、用户输入、外部资料、模型抽取、模型推断和人工确认的可信地位不同，必须分别标记。比如模型从发票猜出的供应商名称可以等待核对，却不能直接覆盖主数据；否则一次识别错误会被后续系统当成已经确认的事实。

按对象和目的过滤上下文

在检索、提示和工具调用前执行用户、租户、对象、字段与用途授权，只传递任务所需数据；检索相关性不能绕过访问控制。

来源和时点可见

AI 结果连接使用的业务记录、版本、生效期和检索时点；数据已变、来源冲突或证据不足时限制回答、重新查询或转人工。

模型输出作为派生数据治理

摘要、标签、评分和建议记录模型、提示、知识、规则、时间、输入引用和审核状态，规定允许消费方、有效期、更正和是否可回写。

工具动作保持业务事务边界

模型提出参数后仍由确定性规则校验身份、权限、状态、金额和重复请求；未知结果先对账，不把超时当成未发生。

反馈和日志不自动成为训练材料

生产对话、人工修正和失败样本进入评测或训练前重新确认目的、权利、最小化、敏感性、代表性、版本、期限和批准。

更正和删除向下游传播

业务事实修正或使用权终止时，识别索引、缓存、特征、评测集和可控派生物；无法从既有模型参数直接删除的影响须记录和风险处理。

持续监测业务影响

监测数据分布、来源、缺失和权限变化，以及错误输出对真实业务对象和决定的影响；模型指标不能代替交易对账和业务结果确认。

业务数据与相邻概念怎样区分

业务数据强调对组织有意义的事实与记录，主数据、交易数据、参考数据和分析数据是其中不同角色。数据库数据范围更大，知识文档和模型输出又有不同权威地位。区分它们，是为了给每类内容安排正确的正本、变化和使用责任。

概念与业务数据的边界
企业数据组织控制或使用的全部数据，可包括业务、技术、研究、人员、外部和管理数据；业务数据只取与业务或使命活动事实直接相关的部分。
数据要求规定指定数据必须满足的语义、来源、质量、保护和生命周期义务；业务数据是被这些要求约束的事实与记录。
业务对象业务领域中被识别和管理的人、物、事项或概念；业务数据是对对象属性、关系、事件和状态的表示，对象不等于某一张表。
主数据跨流程一致识别核心实体的相对稳定业务数据，是业务数据的一类，不包含全部交易、事件、文档和结果。
参考数据用于分类、约束或解释其他值的代码和允许值集合，可由外部标准或内部权威维护；也是部分业务数据的解释基础。
交易数据记录订单、付款等业务或财务交互，是业务数据的一类；业务数据还包含主数据、事件、状态、文档和决定。
业务记录因证明政策、交易、决定或行动而按适用记录制度受控保存的信息。部分业务数据构成记录，但两者不能默认画等号。
元数据描述数据定义、来源、结构、时间、权限或处理的信息。它可能本身承担业务证据，但通常用于解释和管理业务数据。
技术日志和遥测描述系统运行、请求、资源和故障。若用于证明正式业务动作或决定，其中部分可能兼有业务与审计地位；普通 CPU 指标通常不是业务事实。
分析数据为报表、分析或模型而整合、清洗和派生的数据，可源自业务数据；它的时点、粒度和方法可能不同，不能自动成为交易正本。
个人数据按适用法律和制度定义的、与个人相关的数据类别；它可与业务数据重叠。是否属于个人数据及义务须由有权角色判断。
训练数据用于训练或调整模型的数据集，可能包含获批的业务数据，也可能来自公开、合成或其他来源；业务数据不会因可用就自动获准训练。

依据与适用边界

本文把业务数据定义为组织在执行业务或使命活动时创建、接收、维护或使用，用来描述业务对象、参与方、事件、交易、状态、决定、义务和结果的数据。不同组织对 business data 的分类并不完全一致，项目必须声明适用口径。本文不完整定义企业全部数据、主数据、参考数据、交易数据、事件数据、业务记录、数据要求、数据模型、数据库、元数据、技术遥测、分析指标、测试数据、训练数据、个人数据法律分类、知识文档或数据治理体系。某项数据是否属于业务数据、是否构成正式记录、谁是权威来源以及适用的保护和保存义务，须由项目有权角色按用途与制度确认。