2. Teamcenter基础架构与变更管理数据模型

变更管理之所以在Teamcenter中能够做到“改一处、知全局”，根本原因在于它并不是把文件简单地上传共享，而是把产品拆解成一套有结构、有版本、有关系的数据对象。要真正用好变更流程，必须先理解承载变更的底座：客户端架构决定了你在哪里操作、数据模型决定了你操作的是什么、版本与版次决定了变更如何被记录、数据集与关系决定了变更影响如何被追溯。本节围绕这四层展开，为后续的ECR/ECO流程打下数据基础。

一、AWC与胖客户端：两种入口，同一份数据

Teamcenter提供两类主要客户端。胖客户端（Rich Client，基于Java/Eclipse）功能最完整，适合管理员、数据建模人员和复杂结构编辑场景，例如BMIDE配置、结构管理器深度操作、批量导入导出。Active Workspace（AWC）是基于浏览器的现代化界面，强调搜索、导航、可视化与流程审批，适合工程师日常查询、发起变更、审批任务。两者并非两套系统，而是访问同一后端数据的不同前端。

从部署层次看，用户界面之下是业务逻辑层（TcServer、各类服务与微服务），再往下是数据持久层（Oracle或SQL Server数据库存放元数据，卷（Volume）存放物理文件），最外层还有FMS（文件管理服务）负责大文件的传输与缓存。理解这一分层很关键：当你在AWC中打开一个零件时，元数据来自数据库，三维模型文件则通过FMS从卷中按需拉取。变更流程中“改的是元数据还是文件”这一判断，正来源于此。

二、产品数据模型：Item与ItemRevision

Teamcenter中最核心的对象是Item（零组件/物料）。Item代表一个“事物”的抽象身份，比如“某型号减速器壳体”，它本身不承载具体设计内容，而是承载编号、名称、类型等稳定标识。真正存放设计内容的是ItemRevision（版本）。一个Item下可以挂多个ItemRevision，每个Revision对应一次设计状态。

这种“身份与内容分离”的设计是变更管理的基础。当设计发生更改时，我们不是去修改旧Revision，而是新建一个Revision，旧版本保持冻结可追溯。例如某零件Item编号为PN-100234，初始设计为PN-100234/A，当需要修改壁厚时，创建PN-100234/B，A版仍可被历史BOM引用。这样“变更前是什么、变更后是什么”在数据层面天然可查。

在ItemRevision之下，还可以有版本（Version）的概念，用于同一Revision内的小迭代，例如工作版本与发布版本。实践中常见的规则是：Revision用于对外发布的设计更改，Version用于设计过程中的中间保存。理解这一区别，才能正确设置变更流程中的版本策略。

三、版本与版次：变更的“时间轴”

版本（Revision）与版次（Version）常被混淆。可以这样区分：Revision是设计更改的里程碑，通常对应一次正式的工程变更（ECO）；Version是同一Revision内的迭代，对应设计过程中的反复调整。Teamcenter通过版本规则（Revision Rule）决定用户在打开结构时看到哪一版，例如“最新工作版”“最新发布版”“按生效日期”等。

在变更场景中，版本规则直接影响影响分析结果。假设工程师用“最新工作版”规则查看装配，可能看到尚未发布的B版；而生产部门用“最新发布版”规则，看到的仍是A版。因此，在发起变更前必须明确：变更针对的是哪个Revision、变更后新Revision何时生效、旧Revision是否继续被在制品引用。这些判断都依赖对版本与版次机制的准确理解。

四、数据集与关系：让变更可追溯

Dataset（数据集）是承载物理文件的容器，例如三维模型（UG/NX Part）、二维图纸（DXF/DWG）、PDF文档、Word说明等。Dataset本身不直接挂在Item上，而是通过关系（Relation）与ItemRevision关联。常见关系包括：IMAN_specification（规格说明）、IMAN_reference（参考）、IMAN_manifestation（表现形式）等。

关系决定了变更影响的范围。例如某零件Revision通过IMAN_specification关联了三维模型和图纸，当该Revision被变更时，这些Dataset会一并进入变更影响清单；而通过IMAN_reference关联的参考文档，可能只需评估是否需要同步更新。此外，BOM结构关系（如PSOccurrence）决定了父件与子件的装配联系，变更一个子件可能影响多个父件，这正是变更影响分析要展开的树状结构。

五、把数据模型映射到变更流程

将上述概念串起来，一次典型变更在数据层面的动作是：变更请求（ECR）关联受影响的ItemRevision；变更单（ECO）批准后，系统按版本规则创建新Revision；新Revision继承或调整Dataset关系；BOM关系按变更内容更新；旧Revision被标记为冻结或失效。整个过程之所以能自动追溯，正是因为Item、Revision、Dataset、Relation四者构成了一个有向、可版本化的数据网络。

下表给出一个简化的对象职责对照，便于在实际配置和排障时快速定位：

掌握这些基础后，后续的ECR/ECO流程、变更影响分析、版本控制策略才有稳固的落脚点。数据模型不是抽象概念，而是每一次变更操作背后真实发生的对象创建、关系维护与版本切换。