数据分析涉及不同业务系统时就要做跨库计算，而表间 JOIN 是最麻烦的，很多数据库都不具备这样的能力，用 Java 取数再计算又太复杂。用 esProc 完成跨库 JOIN 会简单很多。
数据与用例
车辆管理系统（DB_Vehicle）保存了车辆与车主等相关信息，其中车主信息表 owner_info 表结构简化如下：
主键 owner_id 是车主身份证号。
车辆表 vehicle_master 简化结构如下：
vin 设为主键，plate_no 也是唯一的，两个字段在逻辑上都可以视为主键。
交管系统（DB_Traffic）存储了车辆交通信息，其中违章记录表 traffic_violation 结构如下：
公民信息系统（DB_CitizenEvent）存储了公民相关信息，其中公民事件表 citizen_event 结构如下：
4 个表间逻辑关系简单描述是这样的：
从逻辑上看，citizen_event 是 owner_info 是多对一的关系，作为维表的 owner_info 的规模要远小于 citizen_event。
traffic_violation 和 vehicle_master 这两个表也是一对多的关系，规模都可能很大，从后者的角度来看，traffic 更像一个子表，这两个表构成主子关系（plato_no 是 vehicle 表的逻辑主键）。
为什么要区分表间关系呢？
日常的等值 JOIN 基本都会涉及主键（多对多的关联基本没有业务意义），大体可以分为两种：维表关联是一种，是普通字段和维表的主键关联（如 citizen_event 和 owner_info）；另一种是某个表的主键与另一个表的主键或部分主键的关联（如 vehicle_master 和 traffic_violation，traffic_violation 表中，可以把 plate_no 和 violation_id 视为共同主键，即 violation_id 是从属于 plate_no 的）。
esProc 在做 JOIN 运算时会根据不同的关联情况选择不同的方法，简化编码的同时还能提升计算效率。这里先有个印象就可以，来看具体例子。
要做这样几个计算：
- 按城市统计最近一年有车公民的事件数量，用于分析各城市有车人的“行为活跃度”
- 找出近一年获得表彰（Commendation）的车主姓名和事件描述，用以识别“优秀市民”
- 按年份和品牌统计车辆违章次数，用于分析某些品牌的车是否更容易违章，用于驾驶行为和车辆品牌的关联研究
如果这些表在同一个数据库，用 SQL 写这些运算并不困难，大概是这样：
1. SELECT o.city, COUNT(e.event_id) AS event_count
FROM citizen_event e
JOIN owner_info o ON e.citizen_id = o.citizen_id
WHERE e.event_time >= DATE_SUB(CURDATE(), INTERVAL 1 YEAR)
GROUP BY o.city
ORDER BY event_count DESC;
2. SELECT o.name AS citizen_name, e.description
FROM citizen_event e
JOIN owner_info o ON e.citizen_id = o.citizen_id
WHERE e.event_type = 'Commendation'
AND e.event_time >= DATE_SUB(CURDATE(), INTERVAL 1 YEAR);
3. SELECT YEAR(v.violate_time) AS year, vi.brand, COUNT(v.violation_id) AS violation_count
FROM traffic_violation v
JOIN vehicle_info vi ON v.plate_no = vi.plate_no
GROUP BY YEAR(v.violate_time), vi.brand
ORDER BY year, violation_count DESC;
但如果跨库时就麻烦很多了。
安装 esProc
先前往乾学院下载免费的 esProc 标准版。
安装后，配数据库连接，这里三个数据库都是 MySQL。
先把 MySQL JDBC 驱动包放到 [esProc 安装目录]\common\jdbc 目录下（其他数据库类似）。
然后启动 esProc IDE，菜单栏选择 Tool-Connect to Data Source，配置 MySQL 标准 JDBC 连接。
三个数据库都采用如上方式配置，配置完成后，测试一下连接，点击 Connect，发现刚刚配置的两个数据源变成粉红色证明连接成功。
测试一下，按 ctrl+F9 执行脚本，可以正常查询数据说明配置没问题
用例实现
下面来实现前面第一个计算需求：按城市统计最近一年有车公民的事件数量。要关联 owner_info 和 citizen_event 两个表，也就是维表的关联计算。
维表的关联
esProc 实现：
A2 从 vehicle 库查询车主信息，query@x 表示数据全部加载内存后关闭数据库连接，使用 keys@i 设置主键并建立索引，通常事实表会远大于维表，这个索引会被复用很多次，能加快计算速度。
A4 查询事件表，筛选最近一年的数据，都读入内存。
A5 使用 switch 进行外键关联。由于外键指向的维表记录是唯一的，switch 直接将关联字段 citizen_id 转换成 A2 中的记录（实际在内存中存储的是维表记录所在地址）。
这种转换是一次性的，后续可以重复使用，而且可以同时处理多个维表的外键关联。关联完成后通过“关联字段. 维表字段”方式就能引用任意维表字段。A6 就通过 citizen_id.reg_city 获得注册地进行分组汇总。
整体运行如下：
接下来继续：找出近一年获得表彰的车主姓名和事件描述。
在前面代码的基础上增加：
还是基于 A5 的关联结果进行计算，实现了复用。
这里我们再解释一下，跨库关联很多数据库本身就做不了，尤其是异构的情况。esProc 的这种关联能力是与数据源无关的，什么库都可以，甚至其他五花八门的数据源也都没问题，这是其一。其二是，即使与单库 JOIN 相比，esProc 显著区分外键关系也有很大的好处。
书写和理解上，通过点（.）操作符（类似对象. 属性）就能引用外键表的所有字段，有多少层都可以（维表还可能有维表），也很容易表达自关联 / 循环关联的情况。
当 citizen_event 表的数据量很大时，用 esProc 仍然可以处理。不过，当数据量大到无法全部放进内存时，内存地址化方法就不再有效了，因为在外存无法保存事先算好的地址，这时就只能边读入边地址化。
按城市统计所有车公民的事件数量：
与全内存的写法大部分一样，区别在 A4 使用 cursor 创建游标分批读取数据。esProc 的游标是延迟游标，附加在游标上的计算等到最后取数时才会真正计算。
但游标是一次性的，如果想再进行其他计算，比如还要获得表彰的车主。再基于 A5 计算是得不到结果的（注意 A7 的计算结果）：
这时可以使用 esProc 提供的管道机制：
A6 和 A7 基于 A5 创建管道（A7 是简化写法），B6 基于管道进行分组汇总，结果返回给 A6：
B7 则根据另一个管道筛选获得表彰的数据，A7 的结果：
主子表的关联
按年份和品牌统计车辆违章次数。
A5 使用 join 函数根据 plate_no 关联了两个表，其关联结果是这样的：
保留了两边完整记录的多层集合，点开可以看到
关联完成后，A6 就能通过多层引用进行分组汇总。
处理主子表关联时，我们使用了与外键关联 switch 不同的 join 函数，join 函数提供了一些选项，@1 表示左连接，@f 表示全连接，@d 做差集等，用来满足不同的连接需求。事实上，外键关联也可以使用 join 函数来完成。
那为什么不统一用 join 呢？
这里我们看到的都是两个表关联，如果存在多个维表（大部分情况），使用 switch 可以将维表（维表可能还有维表）都附加到事实表上，但用 join 就很难表达这种层次关系，书写也不方便。
主子表关联时的两个表可能都很大，利用表的关联字段都是主键（或部分主键）的特性，可以采用有序归并的算法一次遍历就完成关联。
按年份和品牌统计车辆违章次数：
A2 和 A4 使用 cursor 创建游标，里面的 SQL 都对 plate_no 排序。
A5 使用 joinx 做有序归并，返回的仍是游标。剩下的代码就跟全内存时一样了。
有序遍历利用了关联键有序的特性，只适用于主子表的关联（可对主键有序），但不适用于前面那种维表的外键关联。因为同一个表上可能有多个要参与关联的外键字段，不可能让同一个表同时针对多个字段都有序。这也是区分 JOIN 后采用了不同函数（算法）的原因。
总体来看，esProc 不仅能轻松实现跨库关联，还提供了不同关联场景的实现算法，简单区分后就能获得明显的编码效率和运算效率的提升。
