报表是很多企业级系统都绕不过去的一个必要功能，大部分有几年工作经验的同行都对这种功能很是看不起。因为报表的开发都是对已有数据的整理，这个时候业务数据其实已经有了很多积累，我们只要稍微写写SQL就可以得到我们想要的结果。它的难度就在于SQL是否难写。
正常情况下，我们上面的思路是完全没有问题。但往往定制化的功能都没那么简单，经常做出了功能，却被业务人员吐槽辣鸡。所以本次针对报表设计，以我自己被自己坑的经验，做一个系统性的汇总盘点。
一 单个报表开发的具体工作
单个报表工作可分为以下几步：数据口径梳理、数据中间表设计、数据汇总、数据展示。
l 数据口径梳理****
数据口径是报表的第一步，也是我们报表设计最重要的一步。这个主要是细致活，可以根据以下维度汇总：
| 统计指标 | 使用表 | 使用字段 | 统计逻辑 | 汇总方案 |
|---|
l 数据中间表设计****
在做数据中间表设计之前，我们对数据种类要有一个基本认识。
流水表：数据只会新增的表，一般是交易流水等；
维度表：数据会增删改查的表，一般是账户表、客户表等，只记录最新的数据状态；
拉链表：基于维度表新增数据有效开始时间、数据有效结束时间两个字段，一般用于记录账户的全生命周期；如果账户在5月1日时性别是男、5月2日时性别是女，那么表里则有两条数据：
| 账户 | 性别 | 数据有效开始时间 | 数据有效结束时间 |
|---|---|---|---|
| A | 男 | 2024-5-1 | 2024-5-2 |
| A | 女 | 2024-5-2 | 2224-5-2 |
一般在业务系统中的数据是相当散乱的，为了将数据变成可用数据，我们需要对这些原始数据进行：数据质量审计、数据抽取、数据转换、数据输出等一系列工作。也因此诞生了ETL工程师这一岗位，有兴趣的同学可以了解下。
在通常的数据治理方案中，需要对数据进行严格的分层（有兴趣可以了解下数仓的分层架构）。我所在的系统将数据分为以下4层：
1 ODM：最原始的数据；
2 SDM：基于ODM做过数据修复、汇总的数据；
3 ADM：基于SDM生成的业务可直接用数据；
4 RDM：基于SDM、AMD生成的报表用数据。
数据汇总 没什么好说的
数据展示 没什么好说的
二 单个报表设计实例
了解完这些基础知识后，我们就可以应用他们的思路设计表。假设我们现在拥有三张ODM层的表：
预警账户表（WRAN_ACCT）
| 字段中文**** | 字段英文**** |
|---|---|
| 预警编号（主键） | WRAN_NO |
| 创建时间 | CREATE_T |
| 所属机构 | ORG_NO |
预警账户流水表（WRAN_ORDER）
| 字段中文**** | 字段英文**** |
|---|---|
| 预警编号 | WRAN_NO |
| 流水号（主键） | ORDER_ID |
| 创建时间 | CREATE_T |
预警账户流水触发规则表（WRAN_RULE）
| 字段中文**** | 字段英文**** |
|---|---|
| ID（主键）**** | ID**** |
| 预警编号 | WRAN_NO |
| 流水号 | ORDER_ID |
| 创建时间 | CREATE_T |
| 规则编号 | RULE |
业务场景： 每日实时接入行内交易流水，并经过多个规则决策，最终将决策出来的可疑账户需要记录表中，如果当日预警账户重复则只生成一条预警单，生成完成后，需要业务人员线下排查并记录排查结果。排查过程中，业务人员需要我们提供决策过程中的流水相关信息、触发规则相关信息，我们也将这些信息记录入库。
表介绍： 当一条业务数据接入系统后产生决策后，决策后数据包含了账户、流水、规则等。一条业务数据对应一条“预警账户流水表（WRAN_ORDER）”信息；一条业务数据触发的n条规则对应n条“预警账户流水触发规则表（WRAN_RULE）”信息；多条同账户的业务数据对应一条“预警账户表（WRAN_ACCT）”信息。
汇总目标：****
1，业务选择指定创建时间范围，统计此条件下每个机构的预警单数量。
2，业务选择指定创建时间范围，统计此条件下每个机构的预警账户去重数量。
解决方案：****
l 汇总目标：1
设计中间表：机构预警情况日表（RPT_ORG_WRAN_INFO_BYDAY）
| 字段中文**** | 字段英文**** |
|---|---|
| 加工时间（精度到日）**** | ETL_DATE**** |
| 所属机构 | ORG_NO |
| 预警单数 | ALL_NUM |
数据汇总流程：
每日启动定时任务，根据SQL将数据量汇总到日表程度。优点就是面对千万数据表，只需要查询中间表，节约了大量查询时间。
l 汇总目标：2
设计中间表：机构预警情况日表（RPT_ORG_WRAN_INFO_BYDAY）
| 字段中文**** | 字段英文**** |
|---|---|
| 加工时间（精度到日）**** | ETL_DATE**** |
| 所属机构 | ORG_NO |
| 预警单数 | ALL_NUM |
| 预警账户去重数 | ALL_ACCT_NUM |
到这里的时候，大家会发现一个重要问题：当业务任务选择一天的时间范围时候，我们通过上表是可以实现；但是当业务选择多天的时候，我们是没办法对上表的ALL_ACCT_NUM做数据累积的。这个时候，我们要和业务深入沟通，看他们常用的报表多久看一次、如果多天账户去重与实际数量有些许偏差是否可以接受。
根据目前的项目经验，业务统计数据的频次是有规律的。在我所属的系统里，业务的统计基本是每个月月末。因此我们设计月表去应对这个情况，表如下：
机构预警情况月表（RPT_ORG_WRAN_INFO_BYMON）
| 字段中文**** | 字段英文**** |
|---|---|
| 加工时间（精度到月）**** | ETL_DATE**** |
| 所属机构 | ORG_NO |
| 预警单数 | ALL_NUM |
| 预警账户去重数 | ALL_ACCT_NUM |
而在平时时，如果发现业务统计的时间范围不适合月表统计，则转而变成实时统计。
上面只是对单表的报表设计，有什么不妥大家可以交流。后面会记录企业级的报表整体规划。
