sql在使用窗口函数的情况下嵌套三层完成；
你不妨试试能不能读懂！
润乾报表产品功能-九游会登陆
1润乾报表的作用
提升图表的开发效率
- 表格少的，可以用代码写，几十上百张表格呢，纯手工需要用多少时间？
- 格式复杂，逻辑复杂的，做起来更是头大
- 需求总变来变去，修改和维护成本太高
使用润乾报表可以数倍得提升开发效率
- 图形自己做不美观，而且工作量巨大
- 用第三方的相对简单，但集成和学习成本也不小
润乾自带各类统计图，并且内置了echarts，做图美观又方便
- 从各行业j9国际官网的合作伙伴的实际使用情况证明：使用润乾报表做表格和图形，可以极大的提升效率，节省成本
润乾报表为什么做表效率高呢？往下看！
完善系统结构
不仅做表格和图形快，报表工具自带的外围功能还能很好的完善补充自己系统的功能
也可以看到报表在整个应用体系架构中的位置
2非线性报表模型
先看线性的
再看非线性的
多源分片
多源分片是中国式复杂报表的特点，在一个报表中包含多个数据集（数据库）数据，在报表中以多个分片的方式呈现
行列对称
任意复杂报表都可以横向和纵向两种方式实现，行上的配置和操作在列上同样可以进行
不规则分组
除了常规分组汇总，还支持按段分组、归并分组等不规则分组方式
除了“华北和华东”，其他地区的数据都归并到“其他”分组中
按照金额的不同区间，不同分段来分组
动态格间计算
格间计算主要指跨单元格运算，常见的同比环比就是典型的格间计算
格间计算可以写出很复杂的计算目标（同比、环比、累积、占比、排名.……）
这里“比去年同期”计算时，只会比较有去年同月的数据
什么是非线性报表模型？
能快速制作这类复杂报表的就是“非线性报表模型”
- “中国式复杂报表” 的概念，就是20年前润乾首先提出的
- “非线性报表模型” 就是润乾解决这些复杂报表的的方案，是润乾的专利
- 这些概念和方案一直是报表行业的标准，一直被沿用至今
纯手工或者其他报表工具怎么做这些复杂的报表？
润乾非线性报表模型又是如何做的？
非线性报表模型的优势
手工或者传统报表
- 编写复杂sql语句
- 编写存储过程
- 建立辅助中间表
- 编写程序计算
- 页面拼接
- ……
润乾非线性模型
用函数和表达式直接就做出来了
- 多源分片：像简单报表一样直接写表达式
- 比去年同期：用层次坐标一个式子搞定=c2/c2[`0]{a2==$a2-1 && b2==$b2}
- 按段分组：plot 函数搞定
- ……
润乾非线性报表模型做什么表都是简单报表！
3润乾的工作原理
整体工作原理
分步说明：第一步设计报表模板
在润乾类excel的设计器（ide）中，配置数据源，设置数据集，拖拽设计模板
分步说明：第二步在web服务器发布报表
润乾是标准j2ee结构，把润乾的应用包，复制到应用系统中，xml文件配置数据源信息，编辑jsp文件配置展现报表的tag标签
分步说明：第三步浏览报表
然后在浏览器中输入url，访问对应jsp，就可以浏览报表了，同时还可以做打印或者导出到excel等的操作了
4报表功能
基础报表不基础
- 在这部分材料中，将展示润乾报表的基础功能，这里的“基础”是相对润乾报表其他高级/独有功能而言的，而这部分“基础”功能涵盖了市面上主流报表产品的绝大部分核心功能，包括一些高级企业级功能
- 使用基础报表（产品版本中的报表版）可以满足绝大多数用户对报表的功能期望，实现同类报表工具的绝大部分功能
满足90%以上功能期望
功能速览
| 设计与调试 | 参数控制 | 主子报表 | 报告生成 |
| 多源数据分片 | 宏 | 报表组 | dashboard与大屏 |
| 行列对称 | sql植入防备 | 冻结表头 | 移动端呈现 |
| 不规则分组 | 图表呈现 | 折叠报表 | 高可用与高性能 |
| 动态格间计算 | 图章水印 | 数据钻取 | 集成部署 |
| 数据源种类 | 报表样式 | 打印导出 | api接口 |
报表设计与调试
润乾报表采用桌面的类excel设计器，开发者可以在设计器中预览报表
或使用内置tomcat将其发布到web上预览，以方便查看页面效果
类excel报表设计
报表文件设计采用类excel风格，这样开发出来的报表格式规整（相对控件类），开发人员上手也更简单
excel无缝交互
在报表设计阶段，可以将业务部门提供excel表样导入设计器继承excel样式快速开发报表
在报表查看时，报表可以无失真导出excel，方便业务部门使用
中国式复杂报表
润乾的非线性报表模型完美解决了中国式复杂报表的制表问题
*润乾报表一直是业内对复杂报表支持全面、性能出色的产品
数据源种类
报表支持常见的各种数据源类型
参数控制
报表可以接收参数实现数据过滤和权限控制
参数可以通过定制参数模板用来录入，也可以使用用户自有的表单，或通过web传递
润乾报表参数表单
提供多种编辑风格：
- 下拉日历
- 下拉树
- 下拉列表
- ……
外部输入参数
- session
- request
- api
- ……
宏
使用宏（${参数名}）可以进行表达式动态替换，实现更灵活的查询条件
报表开发者可以定义一个及其通用的报表模板，通过参数和宏来实现不同报表的呈现效果
sql植入防备
支持敏感词配置，有效防止报表sql注入攻击
图表呈现
支持表格、图形或图表结合的呈现方式
润乾报表提供30 种内置统计图类型，同时支持echarts/d3等第三方js图库
图章水印
提供电子签章/签名、水印、二维码/条形码等功能
报表样式
可以定义局部样式，作用于某一单元格和或行列，也可以定义全局样式进行整体报表风格把控
*适用场景：要求报表呈现风格与系统整体设计一致时
主子报表
主子表提供了报表嵌报表的呈现方式，这样可以在一个报表中展现不同主题（格式）的分片内容
*在这个例子中，报表中各片的格线（纵向）是不对齐的，如果不使用主子表很难实现这样的效果
报表组
报表组将多个报表组合到一起，以多sheet方式呈现，整个报表组共用同一套参数
冻结表头
报表很高或很宽时，通过冻结（锁定）表头固定表头信息方便数据查看
折叠报表
多层分级报表可以采用折叠/展开方式呈现
数据钻取
表格和图形提供超链接钻取功能，通过传递表格/图形参数实现汇总到明细、报表到报表的数据穿透和钻取效果
*除了不同页面间跳转，还可以在一个页面实现图表联动
打印导出
导出
支持多类型文件与多导出选项
*支持echarts图形导出
打印
applet、flash、pdf打印适应不同打印环境
applet打印
客户端需安装java插件
flash打印
客户端需安装flash播放器 ，用户系统往往自带
pdf打印
大部分浏览器无需安装任何插件即可使用
预览打印、直接打印、批量打印、套打，适应不同打印场景
预览打印
预览打印效果，可更改打印设置
直接打印
不预览，直接打印，适用快速打印场景
批量打印
适用于需要同时打印多张报表场景
套打
适用于打印输出到票据类有格式纸张
*支持echarts图形打印
报告生成
将多个报表、文字、图片等内容输出到word指定位置，形成内容丰富的报告
dashboard与大屏
支持企业仪表版（dashboard），将多个报表按指定布局进行呈现
dashboard可以用于pc/移动端的领导看板，也可用于数据大屏呈现
移动端呈现
报表采用全面的html5输出，适用于多种终端，支持多种操作系统
*【注意】润乾报表不提供完整的移动app，用户可将报表嵌入自己的app中使用
高可用与高性能
支持集群部署，支持集群缓存同步保证报表查询性能
静态和动态并发结合控制，保证报表服务器高效稳定运行
集群缓存同步
用户访问a节点产生的报表缓存，可以同步给b节点为另外用户返回报表查询结果（无需再次计算报表）
动态并发控制
静态并发控制用于指定同时计算的报表数量；动态并发控制则根据同时计算的报表单元格数进行控制
集成部署
可采用taglib方式进行集成，嵌入到已有系统中；也可以单独部署报表服务进行调用
<%@taglib %>
- tag标签自由插入网页需要位置
- 几十种标签属性灵活配置
- api方式实现更灵活控制
- 样式文件实现皮肤快速切换
*嵌入式和服务式集成各有优缺点，前者与应用结合更紧密但耦合性更高；后者松耦合但要面临服务通信时可能的问题
api接口
丰富的api便于深度控制
5润乾报表的优势
优势1：比国外开源 - 功能全面易用
- 开源报表大都比较老旧，有些操作都不是类excel的，操作不易
- 开源报表基本都是国外的，文档难懂，而且不全，学习不易
- 开源报表大都功能不全，比如很多都没有填报功能，使用不易
其实现在开源报表基本已经很少有人用了，论坛之类的交流场所也基本荒芜了;而且商用报表越来越便宜，就更无人问津了
优势2：比国内商用 - 老牌性价比高
- 润乾报表专业报表20年，是中国式复杂报表的提出者，更是九游会登陆的解决方案的先行者。是国内报表工具的代表，功能全面稳定，性能好
- 润乾价格公开透明，不仅为用户节省财务成本，更为双方节省了人力沟通成本，我简单，你方便，通用工具类产品，原本就应该这么简单！
优势3：市场占有率高可信赖
润乾专注报表20年，累积的用户、j9国际官网的合作伙伴、市场占有率都遥遥领先。能想到的各行业软件开发商，基本都在用润乾
数据准备
什么是报表数据准备？
报表开发有两个过程：
- 是将原始数据（数据源）加工成报表可用的结果集，通常使用sql/存储过程/java实现
- 是将准备好的结果集通过某种显示样式展现出来，比如常见的表格、图形、颜色等
报表数据准备存在的问题
报表呈现通过报表工具已经做得较好，但使用sql/存储过程/java准备数据会有一些问题
sql的问题
- 复杂计算难写难维护，想想那些上千行、嵌套n层的sql
- 强依赖关系数据库，nosql和文件系统用不了
- 不支持跨库查询，数据库无法横向扩容
- 移植性差，换库要大量修改sql
存储过程的问题
- 复杂计算难写难维护，虽然存储过程支持分步，但几百kb的存储过程仍然很难写
- 没有移植性，现在很多企业都禁用存储过程了
- 数据库存在安全隐患，存储过程创建修改需要较高数据库权限，开放这些权限存在数据库安全隐患
java的问题
- 计算实现难度高，比如分组汇总用java要上百行代码
- 与主应用强耦合，报表模块无法剥离。报表查询强度大、并发高，与主应用耦合过高会导致整个系统不稳定
- 需要专业程序员，成本高
为什么一直没有解决？
报表数据准备是报表开发（运行）的必要过程，也是报表不可分割的组成部分，既然存在这些问题为什么一直没解决？
难
- 报表数据准备的本质是数据计算，报表工具要解决这个问题就需要在内部增加一个强计算机制，不仅要所有计算都能做，还要保证性能，写法要比sql写法更简单（至少不能太难）
- 这个事情无异于开发一门专用计算语言，难度比做报表工具还要高很多，所以报表工具很难具备数据准备的能力
习惯了
- 报表工具不具备数据准备能力，自然要由开发人员写复杂sql、存储过程和java代码
- 数据准备的问题一直没有解决，以至于大家都习惯用那些比较笨拙的方式，甚至认为报表开发就应该这样
润乾报表如何解决？
润乾报表增加了一个数据计算模块（脚本数据集） ，专门用于解决报表数据准备过程中的这些问题
特性速览
| 计算实现简单 | 可控缓存 |
| 多数据源支持 | 低耦合 |
| 异构数据源混算 | 易移植易扩展 |
| 并行计算 | 梳理应用结构 |
| 大报表 | 低成本 |
计算实现简单-比sql/存储过程的优势
计算目标：某支股票最长连续涨了多少交易日
select max(continuousdays)-1 from (select count(*) continuousdays from (select sum(changesign) over(order by tradedate) unrisedays from (select tradedate, case when closeprice>lag(closeprice) over(order by tradedate) then 0 else 1 end changesign from stock) ) group by unrisedays)
sql解法
| a | |
|---|---|
| 1 | =stock.sort(tradedate) |
| 2 | =0 |
| 3 | =a1.max(a2=if(closeprice>closeprice[-1],a2 1,0)) |
spl解法
其实这个计算很简单，按照自然思维：先按交易日排序（行1）,然后比较当天收盘价比前一天高就 1，否则就清零，最后求个最大值（行3）
计算实现简单-比java的优势
相对使用java实现数据准备，润乾报表的数据准备（脚本）采用集合化语法，代码要比没有直接提供结构化计算的java更加短小
写的更快更短
- 基于java提供了更高层的类库和方法
容易理解和排错
- 伪实代码的比例大约是只有1:1.5，大多数报表数据准备算法可以在一个屏幕内显示出来
- 一个页面内能看到更多代码，能更完整地理解代码的含义与排错
*想想java实现一个通用的分组汇总要写多少行代码？
脚本分组举例
【常规分组】
汇总每个人的值班天数
| a | |
|---|---|
| 1 | =file(“/users/test/duty.xlsx”).importxls@tx() |
| 2 | =a1.groups(name;count(name):count) |
【每组top n】
获取每个月、每个人、头三天的加班记录
| a | |
|---|---|
| 1 | =file(“/users/test/duty.xlsx”).importxls@tx() |
| 2 | =a1.groups(month(workday):mon,name;~.top(3):top3) |
【对位分组】
按顺序分别列出使用 chinese、english、french 作为官方语言的国家数量
| a | |
|---|---|
| 1 | =connect(“mysql”) |
| 2 | =a1.query@x(“select * from world.countrylanguage where isofficial=‘t’”) |
| 3 | [chinese,english,french] |
| 4 | =a2.align@a(a3,language) |
| 5 | =a4.new(a3(#):name,~.len():cnt) |
*实际上，润乾报表数据准备脚本的计算能力是完备的，所有计算都能完成
多数据源支持
润乾报表在脚本的支持下，可以对接更多数据源
- 商用 rdbms：oracle、ms sql server、db2、informix
- 开源 rdbms：mysql、postgresql
- 开源 nosql：mongodb、redis、cassandra、elasticsearch
- hadoop家族：hdfs、hive、hbase
- 应用软件：sap ecc、bw
- 文件：excel、json、xml、txt
- 其他：http restful、web services、olap4j 、...
异构数据源混算
脚本支持同构或异构数据源之间混合计算，有了这个能力，做报表的时候就不再需要将异构源数据都灌倒一个关系库查询了
并行计算
脚本支持多线程并行取数，可以基于多个同构或异构数据源并行取数、计算
大报表
支持海量数据异步呈现，秒级响应，大数据下保证呈现速度，同时降低服务器压力
传统报表模式
- 全部取出后再呈现，用户体验恶劣
- 全内存计算的报表可能溢出
- 由数据库实现分页取出，翻页性能差并且可能导致数据不一致
润乾报表实现异步分页取出
- 异步线程边取数边呈现，快速响应
- 本地缓存，按页随机取数
- 不依赖于数据库的分页取出能力，适用于非关系数据库的数据源
可控缓存
可实现报表的部分缓存、多个报表之间缓存复用、以及不同缓存的不同生存周期
低耦合
相对于使用java实现报表数据准备，计算模块与应用的耦合性更低
java
模块化困难java程序必须和主应用一起编译打包，耦合度高
难以热切换java编写的报表数据准备算法有修改后会导致整个应用重新编译部署，很难做到热切换
类库少java程序在结构化和半结构化计算方面的类库较少
润乾报表计算模块
模块化简单计算脚本和报表模板一起管理维护，从而使报表功能模块化
容易热切换计算脚本是解释执行的语言，很容易做到热切换
类库多更丰富的语法和类库，让结构化数据的计算更有效率
易移植易扩展
计算模块具备不依赖数据源的计算能力，数据源变化无需更改计算算法，利于移植和扩展
数据源变化只更改相应取数逻辑即可，无需更改计算逻辑，平滑移植
数据库扩容，更改取数逻辑，归并数据后，延用原有计算逻辑，快速扩容
梳理应用结构 - 减少存储过程
采用存储过程实现数据准备算法，会造成报表与数据库的耦合问题
- 存储过程和报表的存放位置不同，导致模块化难度大
- 存储过程修改需要分配相应的数据库权限，存在安全隐患
- 存储过程容易被其他应用使用，造成多个应用间的耦合
使用计算脚本替代存储过程完成报表数据准备，会极大减少存储过程，算法外置后与报表模板一起存放管理，完全归属于应用本身，降低报表与应用其他部分或其他应用的耦合
梳理应用结构 - 减少中间表
由于数据量或计算复杂度原因，经常需要在数据库中创建中间表，中间表会带来很多问题。通过计算模块可以有效减少中间表数量，梳理应用结构
数据库管理混乱
各个应用的累积大量中间表存储在线性结构的数据库中造成数据库管理混乱
数据库资源浪费
不用的中间表，仍然需要相应etl过程向其更新数据，浪费数据库资源
计算模块提供高性能私有数据存储格式，可以将中间表数据外置存放到文件系统，便于管理，通过计算脚本获得计算能力，同时获得更高效的io性能和计算能力，充分减少数据库中间表，梳理数据库结构
低成本
有了专门的数据准备工具，报表开发可以不再依赖专业程序员，从而进一步降低报表开发成本
需要注意的是，润乾报表提供的计算模块（脚本数据集）并非必选，您仍然可以使用sql/存储过程/java来准备数据。只不过，当你遇到困难的时候，多了一种解决问题的手段
不要锦上添花，只有雪中送炭
没完没了的报表
- 报表业务天生具有稳定性差的特点，报表经常要新增、修改。
- 因为报表需求是在业务开展过程中逐渐催生的，没完没了是常态，没法消除，只能适应
- 需要低成本的适应手段来面对没完没了的报表
- 以往报表工具只能解决呈现阶段的问题，而无法搞定数据准备，仍会面临开发人员要求高、应用耦合性高、运维成本高等问题。这就会让人感到没完没了是个棘手的问题。
- 润乾报表的计算模块专门用做数据准备，可以进一步降低报表开发成本，从而更低成本地适应没完没了的报表开发
报表开发成本如何再降低？
使用润乾报表解决了1.报表呈现和2.数据准备两个阶段的问题，这样报表开发已经全面工具化，有效解放了人力，降低了成本
那么还有哪些因素会影响报表开发成本？如何解决？
3.运维困难
报表与业务系统耦合在一起，报表频繁修改会影响业务系统，导致运维困难，增加成本
4.报表开发人员成本高
因为要面对业务系统复杂的技术环境，又涉及编写复杂sql和java，报表开发工作往往需要专业程序员参与，无疑又增加了成本
5.沟通成本高
技术部门面对业务部门的需求往往需要多次往复沟通，有时还会因为误解导致报表开发不对，进一步增加了成本
五步解决报表没完没了
1.引入报表工具
报表呈现工具化-解放报表呈现阶段人力
2.引入计算模块
报表数据准备工具化-解放数据准备阶段人力
3.独立报表模块
调整应用结构，梳理报表数据源，实现报表模块与数据库及应用解耦
4.建设报表团队
模块独立后可建设培训独立于应用开发团队外的低成本报表队伍应对多变需求
5.完善沟通机制
建设报表知识库论坛。减少沟通中的误解，实现历史工作的复用
商业智能(bi)
润乾bi大不同
与大多数bi产品必须独立使用不同，润乾报表的bi功能支持集成嵌入
让自己的应用也拥有bi功能可不是开开玩笑
*基于润乾报表，你可以很容易打造属于自己的bi系统；再贴上牌，秒变bi供应商
功能速览
| 固定报表 | 文件源分析 | dashboard |
| 图表分析 | sql源分析 | 跨库查询 |
| 常规多维分析 | 语义层建模 | 管理平台 |
| 跨行组运算 | 关联分析 | 权限控制 |
| 自定义图表 | dql模型 | 移动端 |
| 页面控制 | 透明化 | 集成部署 |
固定报表
固定报表是指业务中逻辑复杂但格式相对固定的报表，也经常被称为复杂报表
这类报表往往无法通过自助拖拽完成，必须由技术人员进行定制开发
*固定报表是bi的必要组成部分，考察产品时不容忽视；固定报表详细资料请参考：《基础报表》
图表分析
提供多种图表，拖拖拽拽生成图，拉拉扯扯生成表
常规多维分析
支持切片/切块、钻取/上卷、旋转等多维分析常见操作
跨行组运算
在bi分析中还会查询同比、环比、排名、占比等复杂查询，这类查询也被称为：跨行组运算
跨行组运算会涉及两个层次，聚合层（如年汇总）和范围层（总排名还是省内排名）
*【选型注意】很多bi产品只提供聚合层，范围层只面向全集，这样是不够用的
自定义图表
呈现的图表种类可扩展，自定义表格样式，新增图表类型，支持常见js第三方图库
*新增一个自定义报表模板，放到模版目录下，再修改资源树js，前端就可以看到这个模版了
页面控制
除了图表扩展，润乾bi还提供了页面控制接口，用户可根据需要自行修改多维分析前端页面风格
文件源分析
直接基于本地或服务上的csv、excel、txt等文件进行多维分析
sql源分析
在页面上手动输入sql语句，基于sql查询结果进行多维分析
sql源分析
sql还可以事先由管理员指定好，用户根据不同的权限进行查询分析
sql可以动态选择，也可以动态生成
语义层建模
润乾bi提供了桌面建模工具构建语义模型，进行常规多维分析（文件和sql相对临时）
*模型文件中元数据lmd用于梳理数据结构，字典dct进行语义转换，可视文件vsb进行权限控制
关联分析
基于语义模型，在页面端可以很方便实现关联分析，根据用户的拖拽实时关联查询数据
*用户选择多层维度进行多表实时关联查询，可以避免事先关联引发的各种（空间和时间）问题
dql模型
为什么润乾bi不需要事先建cube，也不需要由用户来指定关联？
原因：dql模型重新看待表间关联，让实时关联成为可能
·dql模型
举例
进销存系统涉及的4个表：订单表orders、员工表employee、部门表department、区域表area。表间存在如下关联关系：
- 常规多级外键关联，如：订单.emp_id = 员工.emp_id、员工.dept_id = 部门.dept_id
- 表间自关联，如：地区.pid=地区.id
- 相互关联，如：员工.dept_id = 部门.dept_id，同时，员工.emp_id = 部门.manager
- 两表多字段关联，如：订单.send_city=地区.area_id，订单.recieve_city=地区.area_id
常规多级关联
多级关联是指一次查询涉及的多个表需要通过逐级外键实施关联完成查询计算
查询目标：哪些部门的哪些员工在什么时间签过订单
通过这种方式就可以拖拽3个表的所有字段进行查询，完成多级外键关联查询，生成的dql语句也很好理解：
select emp_id.dept_id.dept_name 部门, emp_id.emp_name 员工, order_date 签单日期 from orders
自关联
自关联是指一个表两个字段之间存在关联关系，常用于存储多层数据
查询目标：各发货地区、省、市的订单明细
自关联的层级可能非常多，通过这种方式可以应对任意层级的自关联。生成的dql如下：
select send_city.name 市, send_city.pid.name 省, send_city.pid.pid.name 地区 from orders
相互关联
相互关联是指两个表互为外键表，彼此分别有字段指向另一张表
查询目标：各部门经理、员工信息
相互关联与自关联类似，也会存在多层。dql仍然可以处理任意层的相互关联。语句如下：
select
emp_name 员工,
dept_id.manger. emp_name 经理
from employee
两表多关联
两表多关联是指一个表中有多个字段与同一个表关联
查询目标：订单的发货和收货城市信息
无论有多少字段指向同一张表，都不用重复选出多遍。dql语句：
select send_city.name 发货城市, receive_city.name 收货城市 from orders
dql的优势
相对其他bi产品需要用户在页面端完成表关联，dql让多表关联查询不再错、不再晕
不再错
- 传统bi允许业务用户自行关联，理解难度太，容易出错；而自动关联只能适应简单情况，关联复杂时经常对应错误
- 关联出错时，轻则查不到数据，重则跑崩数据库
- 基于dql模型的润乾bi，业务用户基于做好的关联模型随意拖拽，保持了灵活性，而临时生成的关联还会必然正确
不再晕
- 传统bi实施关联需要面对太多表和关联字段，业务人员经常会晕掉
- 而经常出现的自关联、互相关联、两表多关联，则会导致表间关系变成一团乱麻的网状结构，很难理清
- 基于dql模型的润乾bi仅需技术人员建好基础关联，就可以生成易于理解的树状结构，清晰简单，关联随操作实时生成
*选型bi产品时，不妨拿这几个例子试试，比较一下
透明化
- 汇总查询如果每次都使用基础表汇总效率较低，为此会事先建立汇总表（空间换时间）
- 汇总表很多（各种维度组合）时全部暴露给用户会导致用户体验极差
- 润乾bi提供透明化机制，用户使用基础表的查询会自动转换成查询汇总表
用户基于“支付单”按年汇总金额，会被引擎自动指向“支付单年汇总表”查询，而不会使用更基础的“支付单表”，而在页面上用户只基于“支付单”进行操作
dashboard
多维分析查询结果以多图表形式组合到dashboard中，并共用全局参数
跨库查询
润乾bi提供跨异构库查询能力，实现面向异构库查询的多维分析
管理平台
润乾bi可以集成嵌入用户已有应用，同时也提供独立的平台管理系统—润乾报表中心。润乾报表中心开源免费
*基于润乾bi核心功能，加上开源的bi管理系统，助你快速打造属于自己的bi产品
权限控制
- 润乾bi通过定义语义层建模中的“可视文件（vsb）”实现权限控制
- 控制粒度包括表、字段和记录
- 实现方式包括定义多个可视文件和使用宏
移动端
润乾bi采用全面html5输出，适配各类终端（不提供移动app，需集成嵌入使用）吗，
集成部署
- 润乾bi可以采用集成或独立两种方式部署
- 将bi部分作为模块集成嵌入已有系统中
- 集成时可以采用嵌入式紧集成（taglib） ，亦可采用服务式松集成（服务调用）
- 将润乾报表中心作为一个独立应用系统部署，包含用户、组织机构等系统管理功能
- bi系统与业务系统无直接交互，可实施单点登录
开放源码
- 润乾bi中，多维分析前端页面、dashboard、报表中心三部分均开放源代码
- 基于源码可以实现更深度的定制，拥有更具自身特色、属于自己的bi产品
1润乾填报的作用
润乾填报能做什么？
1 采集新数据
业务人员在web端，填报新的数据，并保存到后端数据库中（或其他数据存储）
2 补录旧数据
补全缺失的数据，或者维护修改老数据，并更新到数据库中（或其他数据存储）
润乾填报的体系结构图
润乾报表是标准的j2ee结构，可以无缝集成到用户的java应用中，方便用户统一管理
填报工作原理
分步说明：第一步设计填报模板
在润乾类excel的设计器（ide）中，配置数据源，设计表格，用向导自动生成数据来去脚本
分步说明：第二步在web服务器发布报表
润乾是标准j2ee结构，把润乾的应用包，复制到应用系统中，xml文件配置数据源信息，编辑jsp文件配置展现报表的tag标签
分步说明：第三步浏览，增删改，回填
然后在浏览器中输入url，访问对应jsp，就可以进行填报了，填报可以手动填报，也可以导入excel中的数据来填报
2润乾填报的功能
填报样式—网格填报
常规网格式报表填报
填报样式—行式填报
可以增加、插入、删除行，进行数据的增删改
填报样式—自由格式
用户根据需求，自由定义数据填报格式
填报样式—主子填报
同时向相关的不同表中填报数据
填报样式—多源填报
支持多源填报，数据来去无关，初始数据可以来自，不同库，文件或者json等，回填数据同样可以去向任意不同数据源
填报样式—报表组填报
像excel的多sheet表格一样，可以多个sheet同时填报，来源和去向同样可以多样性
excel交互
导入现有excel模板，当做填报模板，节省开发工作量
填报表格，可以导出excel，用于本地保存，或者离线填报
导入excel的数据进行填报，也可以整体复制粘贴填报
填报辅助输入
多种编辑风格，编辑框/复选框/上下载文件/下拉列表/下拉数据集/下拉日历/下拉树。辅助用户快速录入，还能保证格式和数据的正确性
填报自动计算
可以根据同一表填写的数据，自动计算出其他的指标数据。订单金额=单价*数量*（1-折扣）
还可以跨表取数，对不同表中输入的数据进行自动计算。包含“几”类产品是根据“订单明细”表中“产品id”数量计算的
填报数据校验
各种类型的数据都可以做验证，保证数据的正确性
3来去自如的填报
传统填报难点
传统填报工具只会：
“一来一去，哪来哪去”
复杂填报场景需要：
“多来多去，来去无关”
一来一去，哪来哪去
数据来源和回填的表是同一个表，数据从哪里来，回哪里去。
多来多去，来去无关
报表的不同区域是不同的数据来源，修改后，还可以回填到不同去向中。
传统工具基本解决不了这么复杂的填报需求
润乾解决多来多去的法宝 - 脚本
通过脚本可以连接主流的各种关系，非关系型数据库，以及文本，json，http型数据源
通过脚本可以灵活定义数据来源与去向，对数据流动的路径进行更精准、深度的控制，解决各类复杂的多来多去复杂场景
数据来源可能是excel，json，oracle，mongodb，数据去向可能是mysql，hive，redis等，不管多复杂，两个脚本都搞定
4业务自由的填报
什么是业务填报
由业务发起人根据需求，灵活、自由定义的数据填报采集表格
业务填报的特点和困难
润乾怎么解决这些困难
润乾的填报模型，可以自动识别数据结构，把填写的数据结构化保存，并可以直接针对这些结构化的数据进行后续的分析
1.业务人员设计表样
2.自动识别数据结构
3.保存为结构化的json
分步说明—设计模板
上级单位业务人员根据业务需求，实时制作填报模板
分步说明—识别结构
填报引擎可以自动识别数据结构，下面这种样式复杂的，都可以识别
分步说明—人员填报
下级单位在网页上填报，或者下载excel后离线填报，再上传
分步说明—结果汇总
上级单位制作汇总模板，填报完成后，自动汇总结果
分步说明—多维分析
上级单位针对汇总结果进行bi多维分析（买报表赠送bi），业务填报全流程到此结束
