需求分析与模型设计：从业务到数据的桥梁

说实话，很多做数据仓库的朋友，一上来就急着建表、写ETL。我见过太多这样的项目了——表建了一堆，数据也灌进去了，结果业务方一问「这个月的储能电站充放电效率是多少」，查半天查不出来。为什么？因为需求没摸透，模型没设计好。

这一章，我们就聊聊怎么把业务需求翻译成数据模型。我个人习惯把这一步叫做「翻译工作」——把业务语言翻译成数据语言。翻译得好，后面的查询、分析、报表都顺风顺水；翻译不好，后面全是坑。

一、业务需求调研：别急着动手，先听懂业务在说什么

我记得刚入行那会儿，有个项目经理跟我说：「你去调研一下储能业务的报表需求。」我兴冲冲地跑去找业务部门，人家说「我要看每天的充放电量」，我就记下来了。结果建完表才发现，人家要的是「每个储能单元、每个时段的充放电量」，而且还要区分是「计划内调度」还是「市场交易」。

你看，一个「充放电量」背后，藏着这么多维度。所以需求调研，不能只听表面。

我建议按这四步走：

1. 找对人——储能业务涉及的人不少：运维人员、交易员、财务、管理层。每个人看数据的角度不一样。运维关心设备健康度，交易员关心电价和收益，财务关心成本和折旧。
2. 问对问题——别问「你要什么报表」，要问「你每天做决策时，需要看哪些数据？」、「你最近一次因为数据不全而拍脑袋的决策是什么？」
3. 看现场——我习惯去储能电站的监控室待半天。看他们实际操作时，哪些数据是高频查看的，哪些是出了问题才看的。这比开会聊一个小时管用多了。
4. 梳理指标——把业务需求整理成指标清单。比如：

业务域	指标名称	粒度	更新频率
运行监控	SOC（荷电状态）	每个电池簇/每分钟	实时
交易结算	充放电收益	每个电站/每天	T+1
设备管理	循环次数	每个电池簇/累计	每日更新
安全预警	温度异常次数	每个温度传感器/每小时	实时

二、维度建模理论：星型还是雪花？别纠结，看场景

维度建模，说白了就是怎么把「事实」和「维度」摆在一起。事实就是「发生了什么」，维度就是「谁、什么时间、在哪里、什么设备」。我见过有人把维度建模讲得玄乎其玄，其实核心就两个模型：星型和雪花型。

星型模型——维度表直接挂在事实表旁边，像星星的光芒一样。查询快，理解简单。我大部分储能项目都用星型。

雪花型——维度表再分层次，比如「电站维度」下面再挂「区域维度」。数据冗余少，但查询要关联更多表。

举个例子。储能电站的「充电事实表」，如果用星型：

-- 星型模型示例
CREATE TABLE fact_charging (
    charging_id BIGINT,
    station_id INT,        -- 直接关联电站维度
    time_id INT,           -- 直接关联时间维度
    battery_cluster_id INT,-- 直接关联电池簇维度
    charge_volume DECIMAL(10,2),
    charge_duration INT
);

CREATE TABLE dim_station (
    station_id INT,
    station_name VARCHAR(100),
    region_id INT,         -- 雪花型会把这层拆出去
    city VARCHAR(50),
    capacity_mwh DECIMAL(10,2)
);

如果用雪花型，region_id 会单独拆成一张 dim_region 表。嗯，这里要注意：储能行业的数据量通常不是天文数字，一个中型储能电站一天也就几万条记录。所以我个人更推荐星型，查询效率高，开发也快。

三、事实表与维度表设计：储能行业的特殊之处

储能数据仓库和电商、金融不太一样。储能的数据有几个特点：

• 时序性强——SOC、电压、电流都是按秒甚至毫秒采集的
• 状态变化频繁——充、放、待机、检修，状态切换很快
• 设备层级多——电站→单元→电池簇→电池模组→电芯

所以事实表的设计，我一般分三类：

事实表类型	典型例子	粒度	更新方式
事务事实表	单次充电/放电事件	每次充放电	增量插入
周期快照事实表	每日电站运行状态汇总	每天/每个电站	每日覆盖
累积快照事实表	电池全生命周期跟踪	每个电池簇	状态变化时更新

维度表的设计，我建议重点关注这几个：

• 时间维度——储能对时间精度要求高，建议建到「秒」级别。我习惯把「是否峰时段」、「是否谷时段」这些业务标签直接放在时间维度表里，查询时直接关联，不用每次计算。
• 设备维度——要包含设备型号、投运日期、设计寿命、额定容量。注意：设备维度是缓慢变化维度，设备升级或更换后，历史数据怎么处理？我一般用SCD Type 2，保留历史版本。
• 电价维度——储能收益和电价强相关。电价分峰、平、谷，还有可能每天变化。把电价单独做成维度表，方便做收益分析。

四、总线矩阵设计：一张图理清所有关系

总线矩阵，说白了就是一张大表格——行是业务过程，列是公共维度，交叉点打勾表示「这个业务过程需要这个维度」。我每次做数据仓库，第一件事就是画总线矩阵。

为什么？因为它能帮你发现：

• 哪些维度是多个业务过程共享的（比如时间、电站）
• 哪些业务过程缺少必要的维度（比如「充电记录」没有关联「电价」，那收益分析就做不了）
• 哪些维度其实可以合并（比如「运维人员」和「操作人员」本质是同一张员工维度表）

下面是我为储能项目画的一张总线矩阵示例：

业务过程	时间	电站	设备	电价	用户	交易
充电记录	✓	✓	✓	✓
放电记录	✓	✓	✓	✓
设备告警	✓	✓	✓
收益结算	✓	✓		✓	✓	✓
运维工单	✓	✓	✓		✓

你看，有了这张矩阵，哪些维度是「核心共享维度」一目了然。时间、电站、设备这三个维度几乎每个业务过程都用，所以它们的设计要特别用心，因为牵一发而动全身。

接下来，我用一张图来展示本章的知识体系：

好了，这一章的内容就到这里。需求分析和模型设计是数据仓库的「地基」，地基打牢了，后面的ETL开发、查询优化才能站得住脚。下一章我们聊聊ETL的具体实现，到时候我会分享一些我在储能项目中踩过的坑和总结的技巧。

---