3. Teamcenter核心数据模型

Teamcenter 的数据模型不是“一张大表”，而是一组围绕产品对象组织起来的对象类型与关系类型。理解它的关键，是先分清“对象是什么”和“对象之间怎么连”。在 Teamcenter 中，Item、ItemRevision、Dataset、Form、BOM 以及各类关系对象，共同构成了产品数据的骨架。只有把骨架搭对，后续的权限、流程、变更、配置管理才有稳定的落点。

一、Item 与 ItemRevision：从“是什么”到“哪一版”

Item 是产品、零件、文档或任何需要被管理的对象的“身份”。它回答的是“这是什么”，例如一个零件号 P-1001、一个装配件 A-2001，或者一份需求文档 DOC-REQ-001。Item 本身通常不直接承载具体设计内容，它更像一个稳定的容器，把同一对象的所有版本、所有形态、所有相关数据聚合在一起。

ItemRevision 是 Item 的版本化分支。它回答的是“这个对象的哪一版”。一个 Item 下可以有多个 ItemRevision，例如 P-1001/A、P-1001/B、P-1001/C。每个 ItemRevision 可以拥有自己的 Dataset、Form、BOM 视图和审批状态。这样设计的好处是：零件号不变，但设计可以持续演进；历史版本可追溯，当前版本可控制。

在 Teamcenter 中，Item 和 ItemRevision 之间是“一对多”的版本关系。Item 是主对象，ItemRevision 是版本对象。创建 Item 时，系统通常会自动生成第一个 ItemRevision，例如 A 版。后续升版时，不是修改旧版，而是新建一个 ItemRevision，并让它继承或复制必要的数据。旧版仍然保留，用于追溯、对比和变更影响分析。

二、Dataset：真正存放文件的地方

Dataset 是 Teamcenter 中承载物理文件或数据容器的对象。它回答的是“具体内容存在哪里、以什么格式存在”。例如，一个三维模型可以对应 UGMASTER Dataset，一个二维图纸可以对应 UGPART 或 DXF Dataset，一份 Word 文档可以对应 MSWord Dataset。Dataset 本身不是文件，而是文件及其元数据的封装。

Dataset 通常挂在 ItemRevision 下，而不是直接挂在 Item 下。这是因为文件内容会随版本变化：A 版模型和 B 版模型可能完全不同。如果把 Dataset 直接挂在 Item 上，就无法区分版本。因此，标准做法是：Item 管身份，ItemRevision 管版本，Dataset 管文件。一个 ItemRevision 下可以挂多个 Dataset，例如三维模型、二维图、PDF 预览、JT 轻量化文件等。

三、Form：结构化属性的载体

Form 是 Teamcenter 中用于存放结构化属性数据的对象。它回答的是“这个对象的属性字段是什么、值是什么”。例如，一个零件可以有一个“零件属性表”Form，里面包含材料、重量、表面处理、供应商等字段；一个变更单可以有一个“变更信息”Form，里面包含变更原因、影响范围、审批人意见等。

Form 与 Dataset 的区别在于：Dataset 主要承载文件，Form 主要承载字段。Form 可以挂在 Item、ItemRevision 或 Dataset 上，具体取决于属性属于哪个层级。例如，零件号属于 Item 层级，版本号属于 ItemRevision 层级，文件格式属于 Dataset 层级。把属性放在正确的层级，才能保证数据一致性和查询效率。

四、BOM 与关系模型：结构如何表达

BOM 在 Teamcenter 中不是一张静态表格，而是由“父件—子件—关系”构成的结构化网络。父件和子件都是 ItemRevision，关系对象则描述“父件用了多少个子件、在什么位置、什么顺序、什么装配条件”。常见的关系类型包括 PSOccurrence、BOMView Revision 等。

BOM 视图是 BOM 的一种组织方式。同一个产品结构，可以有不同的 BOM 视图，例如设计 BOM、制造 BOM、服务 BOM。它们共享同一套 ItemRevision，但关系对象和属性可以不同。这样，设计部门改一个零件，制造部门可以看到结构变化，但制造 BOM 中的工艺信息不会被设计变更直接覆盖。

关系模型是 Teamcenter 数据模型的“连接器”。除了 BOM 关系，还有引用关系、审批关系、变更关系、需求关系等。关系对象本身也可以有属性，例如数量、单位、参考位置、生效日期。理解关系模型，才能理解 Teamcenter 为什么能表达复杂的工程语义，而不是简单的文件夹树。

五、版本与版次管理：A、B、C 与 1、2、3

Teamcenter 中常说的“版本”和“版次”容易混淆。通常，ItemRevision 的版本用字母表示，例如 A、B、C，代表正式发布或重大变更；版次用数字表示，例如 1、2、3，代表同一版本下的迭代或小改。实际项目中，命名规则可能不同，但核心思想一致：用一套可读的标识，区分“大版本”和“小迭代”。

版本升级通常由变更流程触发。例如，设计变更单批准后，系统自动将 ItemRevision 从 A 升到 B，并保留 A 版为历史版本。版次升级则可能用于工作版本中的多次保存，例如 A.1、A.2、A.3，直到正式发布为 B。版本和版次的管理策略，需要在实施初期就定义清楚，否则后期会出现“版本混乱、追溯困难”的问题。

六、实施中的关键判断

在实际项目中，数据模型设计最容易出问题的地方，往往不是“不知道有哪些对象”，而是“把对象放错了层级”。例如，把本应属于 ItemRevision 的属性放到了 Item 上，导致不同版本共享了不该共享的字段；或者把本应属于 Dataset 的文件直接挂到了 ItemRevision 上，导致版本切换时文件无法对应。判断原则很简单：属性跟着变化频率走，文件跟着版本走，结构跟着关系走。

另一个常见问题是版本命名规则不统一。有的项目用 A、B、C，有的用 01、02、03，有的用 V1、V2、V3。规则本身没有绝对对错，但必须在项目启动时统一，并写入数据管理规范。否则，同一个 Item 下可能出现 A、01、V1 混用的情况，查询和追溯都会变得困难。

最后需要强调的是，Teamcenter 的数据模型是“可扩展”的。除了标准的 Item、ItemRevision、Dataset、Form，还可以通过 BMIDE 定义自定义对象类型和关系类型。但扩展的前提是理解标准模型。标准模型已经覆盖了绝大多数产品数据管理场景，只有在标准模型确实无法表达业务语义时，才考虑扩展。否则，过度自定义会让系统变得难以维护，也会增加升级和集成的成本。