📚 课程目录第4章数据模型设计

第四章：数据模型设计——标签、时间序列与元数据

走到这一步，说实话，很多团队都栽在数据模型上。不是技术多难，是设计思路不对。我个人习惯，在搭建PDB之前，先把“数据长什么样”想清楚。这一章，我就把标签设计、时间序列结构、元数据管理这几个核心问题，掰开揉碎了讲给你听。

4.1 标签（Tag）设计原则

标签是什么？就是你给数据打上的“身份证标签”。在流程溯源数据库里，每个操作、每个样本、每个设备状态，都得有标签才能找到。

我遇到过最夸张的情况，一个项目里同一个参数叫了三个名字：“温度_01”、“Temp_01”、“T01”。你想想看，这要是查起审计记录来，得排查到什么时候？

所以，标签设计得守住几条硬规矩：

唯一性：同一个工厂、同一条产线，同一个指标只能有一个标签名。别以为用数字后缀就能搞定，我见过有人把“压力_01”和“压力_02”当成两个不同位置的传感器——其实位置根本没变，只是换了个记录员。
可读性：标签名要让新人看一眼就懂。别用太长的英文缩写，更别用拼音首字母。我一般建议：英文单词+下划线+编号，长度控制在40个字符以内。
版本意识：设备改了、工艺变了，标签可能也得变。但别直接删掉旧标签，你永远不知道审计什么时候需要回溯老数据。加个后缀比如“_v2”，但必须另建映射表记录变更时间。
层级结构：别把所有标签堆在一层。按“工厂——产线——工段——设备——参数”分五层。这样查询的时候，一个层级一个层级往下钻，效率高得多。

下面是个标签设计的示例：

# 标签命名规范示例
# 格式：site_line_area_device_parameter
CNBJ_L01_CIP_TANK1_TEMP
CNBJ_L01_CIP_TANK1_PH
CNBJ_L01_CIP_TANK2_FLOWRATE
# 更细的版本控制
CNBJ_L01_CIP_TANK1_TEMP_v1
CNBJ_L01_CIP_TEMP_SENSOR_v2  # 换了传感器型号

小窍门：你在设计标签体系时，最好先做个“标签字典”，把每个标签的物理含义、单位、数据源、采集频率、合规要求全列一遍。我保证，这份字典能帮你节省后面80%的排查时间。

4.2 时间序列数据结构

PDB里存的数据，本质上就是“什么时间、谁、干了什么、结果怎么样”。它的核心结构就是时间序列。

为什么强调时间序列？因为GMP合规要求你记录每一次变更、每一次操作、每一次设备运行。说白了，就是一个带有时间轴的数据表格。

我建议把数据分成两大块：

事件表：记录“发生了什么”。比如“2025-03-01 09:15:00，操作员A完成了CIP清洗”。这个表一般很大，但字段少：时间戳、事件ID、事件类型、操作人、关联对象。
测量表：记录“数值是多少”。比如“2025-03-01 09:15:00，温度传感器读数是25.3℃”。这个表更细，字段包括时间戳、标签ID、数值、单位、质量标识。

你可能会问：“为什么不把事件和测量放在一个表里？”嗯，这里有个性能陷阱：如果把两者混在一起，审计查询的时候，你要同时扫描大量无关数据。我在一个项目中试过，混着存，200万行数据就慢得不行；分开之后，5000万行也能秒级响应。

下面是一个典型的测量表结构示例：

-- 测量表结构（PostgreSQL示例）
CREATE TABLE measurement (
    id BIGSERIAL PRIMARY KEY,
    tag_id INTEGER NOT NULL,          -- 引用标签字典
    ts TIMESTAMPTZ NOT NULL,          -- 时间戳，用带时区类型
    value DOUBLE PRECISION NOT NULL,  -- 数值
    uom VARCHAR(16),                  -- 单位
    quality INT DEFAULT 0,            -- 质量标识：0=正常，1=可疑，2=无效
    source VARCHAR(64)                -- 数据源，比如"PLC_01"或"手动录入"
);

-- 建立时间索引，这是审计查询的命门
CREATE INDEX idx_measurement_ts ON measurement (ts DESC);
CREATE INDEX idx_measurement_tag_ts ON measurement (tag_id, ts DESC);

重点：时间序列数据的“质量标识”字段，很多人不重视。但在GMP审计里，数据完整性要求你区分“有效数据”和“无效数据”。我曾经吃过这个亏，所以后来在每个表中都留了这个字段。

4.3 元数据管理

元数据是什么？简单说，就是“关于数据的数据”。你存了一个温度读数，这个读数的标签定义、采集设备、校准记录、变更历史，全都属于元数据。

我总结过一个原则：你能存多少元数据，你就能解决多少审计问题。因为审计官问的永远不是“这个数是多少”，而是“这个数是怎么来的、谁改过、什么时候改的、为什么改”。

元数据管理得做到这么几件事：

定义清晰：每个字段的元数据都得有文档。比如“质量标识”字段，可用值列表、取值范围、类型定义，统统写清楚。
版本追踪：元数据本身也会变。你今天给“温度_01”改了量程范围，明天就得能查到三天前到底是多少。别小看这个，我遇到过乙方直接把元数据覆盖了，查不到历史，最后被审计开缺陷项。
自动采集：能用程序抓的元数据，就别让人手动填。比如数据库表的创建时间、索引信息、数据量、最后修改时间，写个脚本定期扫一遍就行。
关联关系：元数据之间是有关系的。“这个标签属于哪个设备？这个设备属于哪个产线？这个产线的CIP标准是谁定的？”把这些关系做成图，审计官一看就明白。

我可以给你看一个元数据表的例子：

-- 元数据变更历史表
CREATE TABLE metadata_change_history (
    id BIGSERIAL PRIMARY KEY,
    target_table VARCHAR(64) NOT NULL,   -- 哪个表被改了
    target_field VARCHAR(64) NOT NULL,   -- 哪个字段被改了
    old_value TEXT,                      -- 旧值
    new_value TEXT,                      -- 新值
    changed_by VARCHAR(64),              -- 谁改的
    change_time TIMESTAMPTZ NOT NULL,    -- 什么时候改的
    reason TEXT                          -- 为什么改（这个很重要！）
);

-- 标签字典表（元数据核心）
CREATE TABLE tag_dictionary (
    id SERIAL PRIMARY KEY,
    tag_name VARCHAR(64) UNIQUE NOT NULL,
    description TEXT,
    data_type VARCHAR(32),               -- 数据类型
    uom VARCHAR(16),                     -- 默认单位
    range_min DOUBLE PRECISION,          -- 量程下限
    range_max DOUBLE PRECISION,          -- 量程上限
    created_at TIMESTAMPTZ DEFAULT NOW(),
    modified_at TIMESTAMPTZ DEFAULT NOW(),
    is_active BOOLEAN DEFAULT TRUE       -- 是否在用
);

注意：别把元数据表和数据表混在一个库里！我见过有人图省事，把标签字典直接贴在测量表的备注字段里。结果数据量一上来，查询和审计都成了噩梦。元数据单独建库，甚至可以考虑用专门的元数据管理系统。

最后，我用一张图把这三个核心要素的关系串起来。你看完应该就能明白，它们不是孤立的：

说白了，标签给了数据一个规范的名字，时间序列给了数据一个正确的定位，而元数据则保证你能说清楚这个数据的来龙去脉。没有标签，你找不到数据；没有时间序列，你拼不全事件经过；没有元数据，审计官问起“你为什么这么设计”，你就答不上来。

嗯，这一章的内容就到这。这三样东西，你设计数据库的时候一定得把它们想透。否则回头改，那可是大工程。我在这上面交过学费，所以劝你别学我。