2. AVEVA对象模型基础
AVEVA的制造数据模型本质上是一套面向对象的语义模型。它把工厂、设备、管线、仪表、文档、工艺参数等制造资产抽象为“对象”，再通过“类”定义这些对象的共同结构与行为，通过“属性”承载具体数据，通过“关系”表达对象之间的连接与从属，通过“实例化”把类变成可用的具体对象。理解这一套机制，是后续做对象建模、数据映射和系统集成的根基。
对象、类与属性：从抽象定义到具体数据
在AVEVA对象模型中，类（Class）是模板，定义某一类制造资产“应该有哪些属性、可以参与哪些关系、具备哪些行为”。例如定义一个Pump类，可以规定它必须具有TagName、DesignFlow、DesignHead、Material、Manufacturer等属性，并允许与Pipe、Motor、Instrument建立连接关系。对象（Object）是类的实例，例如P-101A这台具体泵，它的DesignFlow可能是120 m³/h，Material是316L。属性是对象的数据槽位，分为简单属性（字符串、数值、布尔、日期）和复杂属性（引用其他对象、集合、结构体）。
制造数据建模中，属性定义要区分“类级属性”和“实例级属性”。类级属性描述共性，如泵的额定流量；实例级属性描述个体差异，如某台泵的实际安装位置、序列号。类级属性在类上定义一次，所有实例继承；实例级属性只在具体对象上赋值。这种区分直接决定了后续数据库映射时哪些字段放在类型表、哪些放在实例表。
关系：制造数据模型的骨架
制造数据不是孤立对象的集合，而是由关系连接起来的网络。AVEVA对象模型中的关系通常包括：组成关系（如装置包含设备、设备包含部件）、连接关系（如管线连接泵与阀门）、引用关系（如仪表引用工艺参数、文档引用设备）、分类关系（对象属于某个类或子类）。关系本身也可以带属性，例如连接关系可以带“连接类型”“口径”“压力等级”。
在制造场景中，关系决定了数据能否被正确追溯。例如从一台泵出发，通过连接关系找到上下游管线，通过引用关系找到它的PID图、操作手册和维修记录，通过组成关系找到它的电机和密封件。如果关系缺失，对象就变成信息孤岛，后续的报表、导航和完整性检查都会失败。
实例化机制、继承与多态
实例化是把类变成对象的过程。在AVEVA中，实例化通常有两种方式：一是通过类库选择类，创建空实例后逐项赋值；二是通过模板或已有对象复制生成新实例，再修改差异属性。实例化时，类上定义的属性、关系和默认值会被继承到实例上。继承机制允许子类扩展父类，例如CentrifugalPump继承Pump，增加ImpellerDiameter、NPSHr等属性，同时保留父类的TagName、DesignFlow。多态则体现在：同一操作可以作用于不同子类对象，例如“计算设计余量”这个行为，对离心泵和容积泵可以有不同的实现，但调用接口一致。
在制造数据建模中，继承和多态的价值在于复用与扩展。把通用属性放在父类，把专用属性放在子类，可以避免重复定义，也便于统一查询。例如查询所有泵的TagName和DesignFlow时，不需要区分具体泵型；查询离心泵的NPSHr时，只针对子类即可。
对象模型与关系数据库的映射策略
AVEVA对象模型最终要落到关系数据库或数据平台上。常见的映射策略有三种：单表继承、类表继承和具体表继承。单表继承把所有子类属性放在一张大表中，用类型字段区分，查询简单但宽表冗余大；类表继承把父类属性放父表、子类属性放子表，通过主键关联，结构规范但查询需要连接；具体表继承为每个具体类建独立表，字段紧凑但跨类查询复杂。
关系映射方面，一对多关系通常用外键实现，多对多关系用中间表实现，关系属性放在中间表或关系表上。对象标识通常用稳定ID映射为主键，业务标签如TagName作为唯一约束或索引。属性值如果类型多样，可以采用属性表（对象ID、属性名、属性值）或JSON字段，但要注意查询性能和类型约束。
映射策略的选择与制造场景实践
在制造数据建模中，选择映射策略要结合查询模式和数据规模。如果经常做跨泵型的统一查询，单表继承更直接；如果子类属性差异大、字段多，类表继承更规范；如果每个具体类独立使用、很少跨类查询，具体表继承更紧凑。关系表的设计要保证对象ID稳定，关系属性完整，避免用字符串标签做外键。
一个可参考的映射检查清单如下：
- 每个类是否有稳定主键，是否与业务标签分离；
- 继承层次是否明确，父类属性是否只存一份；
- 关系表是否覆盖组成、连接、引用三类关系；
- 关系属性是否落在关系表而非对象表；
- 多值属性是否用子表或JSON，是否影响查询性能；
- 实例化时默认值是否从类继承，是否允许实例覆盖；
- 多态行为是否在应用层实现，数据库是否只存数据。