师夷长技以制夷—数据模型的圣三一—Item, Revision 与 Dataset 的哲学

Teamcenter学习平台正式上线(官网: https://www.plmvision.top)，安装配置实施开发源码仓库，全套学习教材！

如果说面向对象编程（OOP）是软件工程的基石，那么 Item（对象/零组件）、ItemRevision（版本）与 Dataset（数据集） 构成的“圣三一”结构，就是工业数据管理的物理定律。 

今天，我们就来拆解这套“圣三一”背后的工业哲学。

一、 版本管理的铁律：Item vs. ItemRevision

初学者最容易犯的错误，就是将“对象”和“对象的状态”混为一谈。在数据库设计时，往往只有一张 Product 表，字段里包含 Version。

但在 TC 的哲学里，身份（Identity）必须与状态（State）分离。

1. 为什么对象必须与版本分离？

• Item (零组件)：代表的是“概念”和“身份”。它回答的是“我是什么”。例如，通过编码 Part-001，我们知道这是一个“M8 螺栓”。无论这个螺栓如何改进，它永远是 Part-001。

• ItemRevision (版本)：代表的是“迭代”和“快照”。它回答的是“我是现在的什么样”。Part-001/A 代表初始设计的螺栓，Part-001/B 代表更换了材质后的螺栓。

这种分离的意义在于：
在装配结构（BOM）中，你可以灵活地选择挂载。

• 如果你挂载的是 Item，意味着你永远指向最新版（动态引用，Dynamic）。

• 如果你挂载的是 ItemRevision，意味着你指向了特定的历史瞬间（静态引用，Precise）。

2. 快照（Snapshot）原则：发布的代价

在工业界，有一条不可逾越的红线：版本一旦发布（Released），必须只读。

很多国产轻量级系统喜欢允许用户“修改发布后的图纸”，美其名曰“灵活”，实则是“埋雷”。
TC 的逻辑非常冷酷：

• ItemRevision 一旦被盖上 Released 的状态章（Status），它就变成了一块化石。任何属性都不可更改，关联的文件也不可替换。

• 追溯逻辑：如果一架飞机掉下来，调查组需要追溯的是“20年前生产那架飞机时，所依据的图纸究竟是哪一张”。如果你在原版本上偷偷改了数据，物理世界的实物与数字世界的模型就会断裂（Digital Thread Broken），这是工业制造的死罪。

结论： 想改？请创建 Revision B。

二、 Dataset (数据集) —— 摆脱“文件”的束缚

在 Windows 资源管理器里，文件就是一切。但在 TC 的眼里，文件是最底层的尘埃。

TC 引入了 Dataset 这个概念，彻底颠覆了“文件管理”的思路。

1. 文件只是属性，Dataset 才是容器

在 TC 中，当你看到一个 CAD 图纸或 Word 文档时，你看到的其实是一个 Dataset 对象。

• Dataset 是一个壳：它有自己的属性（创建者、修改时间、描述、甚至自定义属性）。

• 物理文件是附件：真正的物理文件（.docx, .prt），只是 Dataset 内部的一个“挂载物”。

2. 命名引用（Named Reference）：指针的艺术

Dataset 是如何找到物理文件的？通过 Named Reference。
这是一种指针机制。Dataset 不直接存储二进制流，它记录的是一个指向底层存储区（Volume）的指针。

这带来了极大的灵活性：

• 多格式共存：一个 CatiaPart 类型的 Dataset，内部可以同时包含 .CATPart（源文件）和 .cgr（轻量化预览文件）。它们属于同一个数据对象，不会在系统中散落成两个孤立的文件。

• 版本独立：Dataset 也可以有自己的版本。甚至，不同的 ItemRevision 可以共享同一个 Dataset（虽然不推荐，但在标准件库场景下有奇效）。

3. 一物多图/多物一图：Relation 的胜利

国产软件最头疼的问题之一：图文档关联。
是把图纸放在文件夹里？还是把图纸作为属性存字段里？

TC 的答案是：既不是文件夹，也不是属性，而是挂载（Relation）。

• 一物多图：一个 ItemRevision 下面，可以通过 IMAN_specification 关系挂载一个 Word 规格书，通过 IMAN_Rendering 挂载一张 JPG 渲染图，通过 IMAN_UG_Part_Placement 挂载一个 3D 模型。

• 多物一图：一份通用的“表面处理工艺规范”PDF（一个 Dataset），可以被成千上万个不同的螺栓 ItemRevision 同时引用。修改这份规范，所有引用它的零件都能看到更新。

Dataset 实现了数据与结构的解耦，这是文件系统永远做不到的。

三、 GRM (General Relationship Manager) —— 一切皆关系

如果说 Item 和 Dataset 是点，那么 GRM 就是线。TC 的世界是一个巨大的图数据库（Graph），而 GRM 引擎掌管着所有的连接。

1. 强关系 vs. 弱关系

在设计数据模型时，必须搞清楚你需要的关系是“组合”还是“引用”。

• 强关系（Composition / 父死子亡）

• 典型代表：IMAN_master_form（主属性表）。

• 逻辑：表单是对象的一部分。如果我删除了 ItemRevision，那么挂在它下面的主属性表单必须一同消失，否则就是数据垃圾。

• 行为：级联删除（Cascade Delete）。

• 弱关系（Reference / 独立存在）

• 典型代表：IMAN_reference（参考资料）。

• 逻辑：我引用了一份国家标准 PDF。如果我删除了我的零件，国家标准还在那里，不能因为我不看了就把它烧了。

• 行为：仅断开链接（Unlink），保留目标对象。

2. 关系的业务语义

GRM 的强大在于它给连线赋予了语义。
不仅仅是 A 连接了 B，而是：

• A 由 B 制造 (Manufacturing_made_from)

• A 是 B 的替代料 (Global_Alternate)

• A 基于 B 设计 (IMAN_based_on)

这种语义化的关系网络，构成了 PLM 中“影响分析”（Impact Analysis）的基础。当你变更一个零件时，顺着 GRM 网线，就能揪出所有受影响的图纸、工艺和工装。

偷师要点：如何构建你的“数据容器”

如果你正在开发自己的数据管理系统，请从 TC 的“圣三一”中偷师以下几点：

1. 拒绝“文件路径”字段：不要在你的业务表里直接存 FilePath。

2. 建立“附件对象”模型：

• 创建一个独立的 Attachment (或 Document) 表。

• 该表包含：ID, Version, Type, State。

• 该表关联一个 FileStorage 表（用来存物理路径或 Blob 指针）。

• 不要在业务表里加外键指向附件。

• 建立一个 Relation 表：Source_ID (业务对象), Target_ID (附件对象), Relation_Type (关系类型)。

• 业务对象发布后，切断对“附件内容”的写权限。若需修改附件，强制业务对象升级版本，并关联新的附件对象。

总结：
TC 的界面或许笨重，但其底层数据模型（Item-Revision-Dataset + GRM）是对工业物理世界最精准的数字抽象。它告诉我们：数据不仅仅是存储，更是结构、状态与关系的集合。