4. 数据模型设计
资产移交接口的核心在于数据模型的清晰与完整。本章将围绕资产台账主表、维护计划子表、质保记录子表,定义其ER关系与字段规范,确保移交过程中数据不丢失、不歧义。
4.1 三表ER关系图
资产台账主表(Asset)作为核心实体,与维护计划子表(MaintenancePlan)、质保记录子表(WarrantyRecord)构成一对多的主从关系。每项资产可拥有多个维护计划与多条质保记录,移交时子表数据随主表同步迁移。
4.2 资产台账主表字段定义
主表记录资产的核心静态信息,是移交的基础数据载体。以下字段为必选配置:
| 字段名 | 类型 | 长度 | 主键/外键 | 说明 |
|---|---|---|---|---|
| asset_id | VARCHAR | 36 | PK | 全局唯一资产编号,UUID格式 |
| asset_code | VARCHAR | 50 | — | 资产编码,业务可读,如 AST-2024-001 |
| asset_name | VARCHAR | 200 | — | 资产名称 |
| category_id | VARCHAR | 36 | FK | 资产分类ID,关联分类字典 |
| department_id | VARCHAR | 36 | FK | 使用部门ID |
| location | VARCHAR | 255 | — | 物理位置描述 |
| purchase_date | DATE | — | — | 采购日期 |
| status | VARCHAR | 20 | — | 资产状态:在库/使用中/维修/报废 |
| created_at | DATETIME | — | — | 创建时间 |
| updated_at | DATETIME | — | — | 最后更新时间 |
设计要点: asset_id 使用 UUID 而非自增整数,可避免多系统合并时主键冲突;asset_code 保留业务可读性,便于线下盘点核对。
4.3 维护计划子表字段定义
维护计划子表记录每项资产的周期性维护任务,移交时需完整携带未执行的计划:
| 字段名 | 类型 | 长度 | 主键/外键 | 说明 |
|---|---|---|---|---|
| plan_id | VARCHAR | 36 | PK | 计划唯一标识 |
| asset_id | VARCHAR | 36 | FK | 关联资产台账主表 |
| plan_type | VARCHAR | 30 | — | 计划类型:日常巡检/季度保养/年度大修 |
| plan_cycle | INT | — | — | 周期天数,如 90 表示每90天执行一次 |
| next_execute_date | DATE | — | — | 下次计划执行日期 |
| last_execute_date | DATE | — | — | 上次实际执行日期 |
| responsible_person | VARCHAR | 50 | — | 维护负责人 |
| plan_status | VARCHAR | 20 | — | 待执行/执行中/已完成/已取消 |
| remark | TEXT | — | — | 备注说明 |
移交注意事项: 维护计划子表在移交时,应仅迁移 plan_status 为“待执行”或“执行中” 的记录;已完成或已取消的计划可归档,不随移交传输,以减少数据量。
4.4 质保记录子表字段定义
质保记录子表跟踪资产的保修状态与供应商信息,移交时需确保质保期内的记录完整:
| 字段名 | 类型 | 长度 | 主键/外键 | 说明 |
|---|---|---|---|---|
| warranty_id | VARCHAR | 36 | PK | 质保记录唯一标识 |
| asset_id | VARCHAR | 36 | FK | 关联资产台账主表 |
| supplier_name | VARCHAR | 100 | — | 供应商名称 |
| warranty_type | VARCHAR | 30 | — | 质保类型:整机质保/部件质保/延保服务 |
| start_date | DATE | — | — | 质保开始日期 |
| end_date | DATE | — | — | 质保截止日期 |
| warranty_status | VARCHAR | 20 | — | 有效/即将过期/已过期/已作废 |
| contact_phone | VARCHAR | 20 | — | 供应商联系电话 |
| attachment_url | VARCHAR | 500 | — | 质保文件附件链接 |
4.5 字段映射与移交数据包结构
在移交接口中,三表数据以 JSON 结构打包传输。以下为典型数据包示例:
{
"asset": {
"asset_id": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
"asset_code": "AST-2024-088",
"asset_name": "高性能服务器",
"category_id": "cat-srv-01",
"department_id": "dept-it-02",
"location": "A栋3楼机房",
"purchase_date": "2024-03-15",
"status": "使用中"
},
"maintenance_plans": [
{
"plan_id": "plan-001",
"plan_type": "季度保养",
"plan_cycle": 90,
"next_execute_date": "2025-02-10",
"plan_status": "待执行"
}
],
"warranty_records": [
{
"warranty_id": "war-001",
"supplier_name": "华为技术有限公司",
"warranty_type": "整机质保",
"start_date": "2024-03-15",
"end_date": "2027-03-14",
"warranty_status": "有效"
}
]
}
关键校验规则: 接收方在解析移交数据包时,必须校验 asset_id 在三表中一致;若子表记录的 asset_id 与主表不匹配,应拒绝整个批次并返回错误码 ERR-4003。
4.6 数据模型设计检查清单
- 主键策略: 三表均使用 UUID 主键,避免分布式环境下主键冲突。
- 外键约束: 子表 asset_id 必须引用主表 asset_id,移交时先写主表再写子表。
- 状态字段: 维护计划与质保记录均包含状态字段,移交时按状态过滤有效数据。
- 时间字段: 日期类型统一使用 DATE,时间戳使用 DATETIME,避免时区转换问题。
- 附件处理: 质保附件仅存储 URL 链接,文件本身通过独立文件服务传输,不嵌入数据包。
最佳实践: 建议在数据库层面为子表的 asset_id 字段建立索引,可提升移交时按资产查询子表记录的性能;同时为 plan_status、warranty_status 建立复合索引,加速状态过滤。