2. Teamcenter分类体系核心概念

在Teamcenter中建设标准件库，第一步不是急着建类、导数据，而是把分类体系的几个核心术语彻底厘清：分类（Classification）、类（Class）、属性（Attribute）、属性映射（Attribute Mapping）、分类层次（Class Hierarchy）与继承关系（Inheritance）。这些概念彼此咬合，任何一个理解偏差，都会在后续建库时演变成返工。本节把它们放在同一张关系图上讲清楚，并说明分类数据与零件主数据之间到底是什么关系。

一、分类与类：从"一堆零件"到"有结构的类目"

分类是一种按特征对对象进行归集与检索的方法。它回答的问题是："这个零件属于哪一类？我按什么条件能快速找到它？"在Teamcenter中，分类体系独立于零件主数据存在，它是一套类目结构 + 属性定义 + 分类规则的集合，用于组织、描述和检索零部件。

类（Class）是分类体系中的节点，代表一组具有共同特征的零件集合。例如"紧固件"是一个类，"螺栓"是它的子类，"内六角圆柱头螺钉"又是"螺栓"的子类。类本身不存储具体零件，它定义的是"这一类零件应该具备哪些属性、遵循什么规则"。真正挂到类下面的是具体的零件对象（Item）或分类对象（Classification Object）。

这里要区分两个容易混淆的概念：类（Class）是分类结构中的"容器与规则定义"，而零件（Item）是PLM中的主数据对象。一个Item可以关联到一个或多个类，但Item的版本、BOM、图文档等主数据信息仍由Item自身管理，分类只负责"它是什么、按什么特征被找到"。

二、属性：分类的"描述维度"

属性（Attribute）是描述类成员特征的字段。它决定了用户能用什么条件检索零件。属性通常分为几类：

• 标识属性：如零件编号、名称、标准号（GB/T 70.1）。
• 规格属性：如螺纹规格M6、长度20mm、材料8.8级。
• 枚举属性：取值来自预定义列表，如"表面处理"可选镀锌、发黑、达克罗。
• 数值属性：如公称直径、螺距、抗拉强度，支持范围检索。

属性定义在类上，子类通过继承获得父类属性，并可追加自己特有的属性。例如"紧固件"类定义"标准号、材料、表面处理"，"螺栓"子类继承这些属性后，再增加"螺纹规格、长度、强度等级"。这样既保证一致性，又避免重复定义。

三、分类层次与继承关系

分类层次是类按父子关系组织成的树状结构，通常从抽象到具体：

紧固件
├── 螺栓
│   ├── 六角头螺栓
│   └── 内六角圆柱头螺钉
├── 螺母
│   └── 六角螺母
└── 垫圈
    └── 平垫圈

继承关系是这条树的核心机制：子类自动拥有父类的全部属性定义与分类规则，无需重复配置。继承带来两个直接好处——一致性（同一父类下的零件共享同一套描述维度）和可维护性（修改父类属性，所有子类同步生效）。但继承也有边界：子类可以增加属性，一般不建议删除或改写父类已定义的属性语义，否则会造成检索口径混乱。

设计层次时有一个实用原则：越靠上的类越抽象、属性越通用；越靠下的类越具体、属性越贴近规格。如果某个属性只有个别子类需要，就应定义在该子类上，而不是硬塞到父类，避免所有兄弟类都被迫携带无用字段。

四、属性映射：分类与主数据之间的桥梁

属性映射（Attribute Mapping）解决的是"分类属性"与"零件主数据属性"之间的对应问题。分类体系中的属性（如"螺纹规格"）需要与Item主数据中的实际字段（如Item的"规格"属性或自定义属性）建立映射关系，这样在分类检索时，系统才能把主数据中的值读出来参与匹配，也才能在创建零件时把分类属性回写到主数据。

映射通常有三种方向需要关注：

• 分类属性 → 主数据属性：分类中填写的规格值写入Item属性，保证主数据完整。
• 主数据属性 → 分类属性：已有Item的属性值被分类检索读取，用于匹配和展示。
• 双向同步：两边都可修改，需要明确以哪边为准，避免冲突。

实际配置时，映射关系要落到具体字段名和数据类型上。例如分类属性"公称直径"（数值型，单位mm）映射到Item属性"d"（数值型，单位mm），类型和单位必须一致，否则检索会出现漏检或类型错误。映射没做好，分类树再漂亮也查不到零件。

五、分类与零件主数据的关系

理解下面这层关系，是建库不跑偏的关键：分类体系是"索引与描述层"，零件主数据是"实体与业务层"。分类不替代主数据，主数据也不替代分类。

一个典型的标准件在Teamcenter中的存在方式是：创建一个Item（主数据），它带有编号、版本、BOM结构、图文档；同时这个Item被归入某个类（如"内六角圆柱头螺钉"），并填写该类要求的分类属性（M6、20mm、8.8级）。用户检索时走分类树和属性条件，找到后打开的是Item主数据。分类负责"找得到"，主数据负责"用得对"。

六、几个容易踩的坑

坑一：把类当成零件。类只是规则容器，不要为每一个具体规格都建一个类。M6×20和M6×30应该是同一个类下的两个Item，而不是两个类。

坑二：属性定义过粗或过细。属性太少，检索维度不够，用户只能靠编号猜；属性太多，录入负担重，数据质量反而下降。建议以"用户实际会用来筛选的条件"为准，通常一个类5～10个关键属性即可。

坑三：映射字段类型不匹配。分类属性是字符串，主数据属性是数值，检索时"20"和"20.0"可能匹配不上。配置映射时务必核对数据类型、单位、枚举值域。

坑四：继承层次过深。层次超过5～6级后，属性来源难以追踪，维护成本上升。建议控制在3～4级，把差异大的属性下沉到具体子类。