3. 产品数据模型与对象类型

在Teamcenter中，产品数据不是以“文件”为单位散落存放的，而是由一组具有明确职责的对象类型协同承载。理解这些对象之间的关系，是后续做数据建模、权限控制、版本管理和BOM配置的基础。本节围绕最核心的五类对象——Item、ItemRevision、Dataset、Form、BOM展开，说明它们各自“是什么、管什么、怎么连”，并给出可落地的属性定义思路。

一、五类核心对象的职责边界

Item（零组件/物料）是产品数据的管理主键，代表一个可被唯一标识的“事物”，例如一个零件号、一个文档编号或一个外购件。它本身通常不直接承载几何模型，而是承载“这个对象是谁”的标识信息，如Item ID、名称、类型、版本序列等。Item是版本无关的，它回答的是“这是什么”。

ItemRevision（版本）是Item的版本化实例，代表该对象在某一阶段的具体状态。一个Item可以有多个Revision，例如A、B、C，或01、02、03。Revision回答的是“这个对象在某个版本下是什么状态”。工程变更、发布状态、有效性、审批记录通常挂在Revision上，而不是Item上。

Dataset（数据集）是实际文件或数据内容的容器，例如三维模型、二维图纸、PDF、Word文档、仿真结果。Dataset通过“关系”挂接到ItemRevision上，回答的是“这个版本下有哪些具体文件”。一个Revision可以挂多个Dataset，例如一个零件版本同时包含CATIA模型、STEP中性文件和PDF图纸。

Form（表单）是结构化属性的载体，用于存放不适合直接放在Item或Revision上的补充信息，例如材料规格、表面处理、检验要求、供应商信息。Form通过关系挂接到Item或Revision，回答的是“这个对象的附加属性是什么”。Form的价值在于把“属性”从对象主表中解耦出来，便于复用和权限隔离。

BOM（物料清单）是描述产品装配结构的关系集合，通常表现为“父ItemRevision—子ItemRevision”的层级关系，并附带数量、位号、查找编号等属性。BOM回答的是“这个产品由哪些零部件组成、各用多少”。在Teamcenter中，BOM既可以作为结构关系存在，也可以作为BOM View Revision（BVR）或BOM Line来管理。

二、属性定义：把业务含义落到字段上

对象类型只是骨架，真正决定数据可用性的是属性。属性定义要回答三个问题：这个字段代表什么业务含义、由谁在什么阶段填写、是否参与版本或变更控制。

以Item为例，常见属性包括：Item ID（唯一编码，通常由编码规则自动生成或人工指定）、名称（中文/英文描述）、对象类型（如Part、Document、Assembly）、版本序列（定义Revision的编号规则，如A、B、C或01、02、03）。Item ID一旦发布，通常不允许修改，因为它是对外沟通的“身份证号”。

ItemRevision上则承载版本号、发布状态（如工作中、已发布、已冻结）、有效性（生效日期、批次范围）、变更单号（关联的ECN/ECO）。这些字段决定了“这个版本能不能被下游使用”。例如，只有状态为“已发布”的Revision才允许被BOM引用，否则装配结构会出现“未发布件”，导致生产或采购误用。

Dataset的属性重点在数据集类型（如UGMASTER、PDF、DXF）、文件名、文件格式、引用关系。Dataset本身不决定业务含义，它只是“文件袋”，业务含义由它挂接的Revision和关系类型决定。例如，同一个PDF文件，挂在“设计图纸”关系下是设计输出，挂在“检验报告”关系下就是质量记录。

Form的属性设计要克制。一个常见误区是把所有补充字段都塞进Form，导致Form变成“第二张主表”。更合理的做法是：Form只承载可复用、可独立授权、与主对象生命周期不完全同步的属性。例如“材料规格”Form可以被多个零件Revision引用，材料工程师只维护一份，零件工程师只读引用，这样既减少重复录入，也避免材料变更时漏改。

三、BOM：从“关系”到“结构”

BOM在Teamcenter中不是一张静态表，而是由BOM Line组成的层级结构。每条BOM Line至少包含：父节点、子节点、数量、单位、位号（Find No.）、查找编号、装配顺序。父节点和子节点都是ItemRevision，而不是Item。这意味着BOM天然与版本绑定：当子件从A版升到B版时，父件BOM可以选择“固定引用A版”或“浮动引用最新版”，前者用于已发布产品，后者用于研发阶段。

BOM的业务含义体现在三个层面：设计BOM（EBOM）描述产品按功能划分的装配关系；制造BOM（MBOM）描述按工艺路线划分的装配关系；服务BOM（SBOM）描述可更换单元。三者可以共享同一套Item/Revision数据，但通过不同的BOM视图和关系类型区分。理解这一点，就能明白为什么Teamcenter不把BOM直接做成一个字段，而是做成可配置的结构。

四、数据组织逻辑：一条主线串起来

把上述对象串起来，可以得到一条清晰的数据主线：Item定义“是什么”，ItemRevision定义“哪个版本”，Dataset定义“有哪些文件”，Form定义“补充属性”，BOM定义“和谁装配”。这条主线决定了Teamcenter中绝大多数查询、权限和变更操作的落点。

例如，当工程师要修改一个零件时，实际操作对象是ItemRevision，而不是Item；当他要查看图纸时，实际打开的是Revision下挂接的Dataset；当他要检查这个零件被哪些产品使用时，查询的是BOM中作为子件的Revision；当他要确认材料是否符合RoHS时，读取的是Revision关联的Form。每一步都对应明确的对象和关系，而不是在文件夹里“找文件”。

五、常见误区与判断依据

第一个误区是把Item当Revision用。有些实施会把版本号直接写在Item ID里，例如“P-1001-A”“P-1001-B”，这会导致Item数量膨胀、版本关系断裂，后续变更和BOM维护都会变得困难。正确做法是Item ID保持稳定，版本信息由Revision承载。

第二个误区是Dataset直接挂Item。Dataset必须挂接到Revision，才能参与版本控制和发布流程。如果Dataset直接挂Item，就会出现“文件没有版本”的情况，无法判断某张图纸对应哪个设计状态。

第三个误区是BOM只建一层。实际产品往往有多层装配，BOM需要按层级展开。判断BOM是否完整，可以检查：每个父节点是否有至少一个子节点、每个子节点是否指向已发布的Revision、数量单位是否一致、位号是否唯一。这些检查项可以直接作为数据质量校验规则。

掌握这五类对象的关系与属性定义，就掌握了Teamcenter产品数据模型的“骨架”。后续的权限、工作流、变更管理、配置管理，都是在这套骨架上叠加规则和流程。