关于本文
本文是通过利用生成式 AI 的自动化流程创建的。我们确认了 Power Query M 的 Table.RenameColumns、Table.SelectColumns 和 MissingField 规范,并将现有示例重新审视为了“不默默丢弃多个候选”的安全侧设计。验证状态:📘 已确认 Power Query M 官方规范・已完成示例安全性评审・未在实际数据上执行
即使每月 CSV 的列名发生变化也尽量不中断 —— 使用 Power Query M 吸收列名波动
如果每月送达的 CSV 只有列名发生变化,例如 社員コード、従業員ID、社員ID,那么通过在 Power Query 侧将多个别名收敛到一个标准名,可以稳定后续处理。
但是,如果同一个 CSV 中同时存在 社員コード 和 社員ID,情况则另当别论。我们不自动决定哪一个正确,而是采取报错停止的更安全侧策略。
预先决定目标架构
本次的最终列为以下 4 个。
社員ID / 名前 / 部門 / 金額
输入侧允许以下别名。
| 标准名 | 允许的别名 |
|---|---|
| 社員ID | 社員コード / 従業員ID / 社員ID |
| 名前 | 氏名 / 名前 / 社員名 |
| 部門 | 所属 / 部署 / 部門 |
仅找到一个时进行名称收敛
NormalizeOne = (tbl as table, candidates as list, target as text) as table =>
let
names = Table.ColumnNames(tbl),
matches = List.Select(candidates, each List.Contains(names, _)),
result =
if List.Count(matches) = 0 then
tbl
else if List.Count(matches) > 1 then
error Error.Record(
"SchemaConflict",
"候选列有多个。请进行确认。",
[Target = target]
)
else if matches{0} = target then
tbl
else
Table.RenameColumns(tbl, {{matches{0}, target}}, MissingField.Ignore)
in
result
Table.RenameColumns 是用于更改列名的函数。在此处,仅限存在且仅存在一个候选时将其变更为标准名。
不自动采用多个候选的原因
例如,假设 CSV 中存在以下两列。
社員コード = A001 社員ID = B999
如果采用“优先找到哪一个就用哪一个”的处理方式,就会在不知不觉中漏掉另一个。然而这并非列名波动,而是输入数据含义处于模棱两可的状态。
因此,当前的示例会作为 SchemaConflict 停止执行。在自动化中,不仅要让正常流程通过,确定“绝不能自动判断的边界”同样重要。
用 null 补全缺失列
在标准化列名后,通过 Table.SelectColumns 和 MissingField.UseNull 来对齐最终列。
Table.SelectColumns(
Step3,
{"社員ID", "名前", "部門", "金額"},
MissingField.UseNull
)
例如,如果仅在今月缺少 金額 列,它不会丢弃列本身,而是创建一个值为 null 的 金額 列。这使得后续步骤的列结构更容易保持恒定。
flowchart LR
A[毎月のCSV] --> B[候補列を確認]
B --> C{同義候補が複数?}
C -- はい --> D[SchemaConflictで停止]
C -- いいえ --> E[標準列名へrename]
E --> F[必要列をSelect]
F --> G[不足列はnull補完]
G --> H[一定のスキーマ]
比起“永不停止”,不如“正确停止”
如果只是缺少一列左右,可以通过 null 补全来继续处理。另一方面,如果同时来了两列、且无法分清哪一列正确,则必须停止。
引入这种区别后,Power Query 就不再仅仅是一个隐藏错误的机制,而是变成了一个吸收预期内的波动、并检测出含义模糊的变化的机制。
