大家还记得上周四公司年会上豌豆BI的发布操作演示吗？产品经理通过失信人的敏捷分析展示豌豆BI，根据不同的年龄段、学历等去分析失信人数，若是大家在那么短的时间里记不住如何去使用豌豆BI，这次小编详细整理了如何轻松上手玩转豌豆BI。
亿信BI基于B/S架构开发，系统配置简单，用户无需安装任何额外的软件或者工具包，只需要一个浏览器即可，前台开发使用了最新的浏览器界面开发技术AJAX，AJAX技术可以给用户在浏览器上带来非常丰富的操作体验。
纯WEB报表设计界面，无需安装任何插件，界面操作简单，流程清晰，无论是报表还是统计图形，均所见即所得。
无需书写任何脚本，随处可见的操作向导让您仅需通过鼠标点击操作就能快速完成报表设计。
亿信BI提供了面向业务人员的零编程交互式分析，不同于定制分析报表，系统提供了自助式的数据分析功能，用户仅需简单的拖拉拽操作，就可快速得到分析结果。
支持异构数据库的平滑迁移，比如在Mysql数据库上搭建的BI平台，可一键恢复到oracle数据库上，且无需数据库工程师参与，保证BI项目的持续发展。
EsDataClean基于PDCA质量管理方法精心研发设计而成，科学、高效地帮助企业和组织进行全面的数据质量管理。PDCA循环又叫戴明环，是由美国著名的质量管理专家戴明博士提出，它是全面质量管理所应遵循的科学程序。PDCA是英语单词Plan（计划）、Do（执行）、Check（检查）和Act（行动）的第一个字母，PDCA循环就是按照这样的顺序进行质量管理，并且循环不止地进行下去的科学程序。
EsDataClean支持十三种领先业界的规则评价算法，满足业务系统运行、数据中心建设及数据治理过程中各类规则定义，并支持XML扩展，可完全适应未来三到五年的数据质量管理需求变化。
EsDataClean采用J2EE等开放型技术设计开发，可兼容所有支持JDK的操作系统，包括Windows、Linux以及多种采用UNIX内核的操作系统。支持所有符合JDBC2.0规范的数据库，如oracle、DB2、SQLserver、Mysql等。
EsDataClean支持在业务系统建设、数据仓库建设各重要阶段设置数据检查监控点，并可实现跨监控点数据源的比较分析，使得通过常规的规则定义便可实现ETL前后的数据一致性比对。
i@Report提供在离线人工填报、批量导入、数据库对接、网络传输、文件传输等多种采集方式。
i@Report提供丰富的数据接口，不仅可以将报表数据批量输出为Html、Excel、XML、TXT等格式，还可以从现有的Excel、DBF文件中批量导入数据。
另外还可以通过自定义脚本的方式导入任意复杂的二进制数据或文本数据，减轻了用户在录入数据时的工作量，提高数据质量。
i@Report不仅可以通过文件的方式进行数据的导入和导出，还可以通过报表脚本使用ADO的方式连接大型数据库，如SQL Server、DB2、Sybase、Oracle等进行数据的导入和导出操作。
i@Report参照工作流管理联盟（WFMC）标准设计，用户可通过图形化编辑器定义符合各种业务场景的采集审批流程，如多人会签、跨级审核等。
i@Report支持顺序、并行、同步、异步、分支、合并、循环、终止、回退、转交、通知、子流程、批处理等所有业务工作流模式；支持通过、退回、转办、会签、抄送、催办等操作；支持待办提醒、已参与的流程等。
i@Report是一体化的上下级之间报表软件，能满足多级次数据汇总的需要，而且各级用户能够根据自己需要新增报表和指标。
在很多情况下，上级数据粒度相对粗，而下级关注更加细粒度的数据，导致上级下发的报表格式无法满足下级的监管要求。
i@Report多级报表功能满足多级报表报送要求，允许下级单位在原有的报表格式上增加新的监管指标，下级单位在进行数据上报的过程中，系统会智能化的过滤所有下级增加的指标，保证报表指标体系的一致性和合理性。
系统采用纯J2EE架构，纯JAVA开发，开放全面的二次开发接口，能够根据需求方便地对系统进行灵活的定制修改和功能扩展，保证系统的可扩展性和灵活性。如Url接口、Webservice接口、单点登录、上报执行脚本、数据期显示脚本、计划任务执行前后脚本等。
i@Report支持各种类型的报表，如基本表、变长表、中国式复杂报表、套打、问卷调查等。
可灵活地设置各单元格风格，包括：文本、数字、图片、日历、附件、下拉框、下拉复选框、输入复选框、单选按钮等。
质量评价方法是数据质量管理系统的核心技术，优秀的数据质量管理产品应包含丰富的质量评价方法，并且易于扩展。 EsDataClean支持十三种领先业界的质量评价算法技术，满足业务系统运行、数据仓库建设、数据治理过程中各类规则的定义；支持通过XML扩展，可完全适应未来三到五年的数据质量管理需求变化。
EsPowerMeta提供了与平台无关的元数据管理和应用，支持跨管理工具和应用的（如：数据库管理工具、文档介质、可视化工具等）元数据管理和分析，提供企业级的元数据统一视图和端到端的元数据管理功能。
EsPowerMeta支持多种存储格式的元数据自动获取，如：BI源、I源、数据库源、文件源、日志源等，同时无法完成自动获取的元数据，提供了可自定义的元数据采集模版完成元数据的批量导入。
EsPowerMeta在底层框架选型上，采用了业界比较先进的架构体系：
【XUI】 是用于提供定义Web界面的标签语言以及相应的解释渲染引擎；
【VFS虚拟文件系统】 用于提供自定义配置文件的存储和编辑管理，对文件的修改可以在系统页面中进行，不必涉及到具体操作系统的物理存储；
【Lucene全文搜索引擎】 apache软件基金会所开放的主流全文搜索技术框架；
【表单引擎技术】 提供了一种由元模型自动生成元数据的展示和编辑表单的自动接口；
【Drools规则引擎】 提供了元数据和元模型之间属性映射的配置机制；
【Raphael图例库】 提供一套完整的图例定义语言以及相关的解释渲染引擎，用于完成血缘影响分析的图形展现和图例操作。
EsPowerMeta 元数据资料库存储于主流关系型数据库、能完成符合CWM国际规范的XMi文件的导入/导出、同时元数据管理平台也提供了开放的调用接口，与其它第三方系统或者平台做集成应用。
PetaBase是一个分布式、高性能、支持SQL的大数据并行查询引擎和数据仓库系统，提供对TB乃至PB级数据交互式查询，查询结果秒级响应。
PetaBase构建于Hadoop/HDFS之上，采用分布式集群架构，具有动态线性扩展能力，具有很高的容错性、稳定性和可用性。
PetaBase支持列式存储，查询时不读取无关的数据，提升I/O性能。同时列式存储能更好的进行数据压缩，压缩率最低能到30%以下，节省大量磁盘空间。同时也支持多种Hadoop数据格式，更可轻松将现有RDBMS系统的数据导入PetaBase。
PetaBase具有突出的高性能表现，10亿级数据规模以上，比传统RDBMS数据库快10倍以上，TB级数据规模下，比Hive快数倍甚至上百倍。PetaBase动态线性扩展能力，更可满足PB级以上大规模数据的处理。
PetaBase可配置为高可用的部署模式，即将单台主节点架设在两台主机上，一台处于活动状态，另一台处理待命状态。活动主节点响应正常操作，实时同步数据到备份主节点。活动主节点失效时，实时切换到备份主节点。
数据块多副本分布式存储，保证某个数据节点失效的情况下，其它数据节点上仍然有可用的数据块，保证数据不会丢失。
按照用户的使用习惯，我们人性化地提供了多种手势操作，比如滑动切换至上一张/下一张报表，下拉自动刷新分析报表，也可手动缩放来进行局部放大，以便更清楚地查看明细数据。
用户可将有问题或疑问的页面第一时间通过邮件的方式发送到相关人员，实现数据实时可追溯。
移动BI提供联系人功能，可以给联系人打电话和发站内信，让用户在移动工作的同时随时与同事保持密切的沟通。
管理员可以将重要事情使用公告的方式发布，让所有用户第一时间看到并执行。
移动平台提供论坛功能，让大家无障碍的沟通交流。
管理员可以对服务器菜单进行编辑和个性化定制修改，i@Report中提供了菜单编辑的入口，供管理员进行配置。
用管理员用户登录服务器–>服务器管理–>编辑菜单文件：
进入“编辑菜单文件”，可以看到其包括两个文件夹，conf文件夹和menu文件夹，如下图：
【conf】：conf文件夹中存放desc.xml（文件描述配置文件），menu.property（菜单配置文件）两个配置文件。
【menu】：menu文件夹下存放所有服务器菜单文件。菜单文件命名以.menu为后缀文件名。每个菜单文件都在menu.property中有相应配置，请不要随意修改菜单文件名称。
管理员用户也可以在资源管理器中查看菜单，登录服务器–>服务器管理–>资源管理器。点击进入资源管理器后，访问路径：/iroot/clientdown/server/skin/menu/，就可以看到系统自带全部菜单项。
登录服务器操作系统，访问服务器中间件中解压包中路径（..\i435\WEB-INF\classes\com\esen\i\resource\rootdir\clientdown\server\skin\menu），就可以看到全部菜单文件。
找到系统自带的全部菜单后，选择需要修改的菜单文件，可以通过两种方式进行修改：“文本编辑”和“可视化编辑”。
i@Report服务器菜单文件采用XML文件格式。XML文件主要包括：文件头、菜单根、菜单项及属性、分隔符等通用项。同时也可以在XML嵌入标准JS函数。
下表为XML文件中常见属性说明：
年报任务
格式：年+四个横杠，如2009---- 表示2009年
最佳报表期：以每年的9月1日为界，9月1日之前，最佳报表期为上年，从9月1日开始，最佳报表期为本年。
月报任务
格式：年月+两横杠，如200901-- 表示2009年1月
最佳报表期：以每个月的21号为界，每月21号之前最佳报表期为上月，从21号开始，最佳报表期为本月。
季报任务
格式：年+季度+两横杠，如200901-- 表示2009年一季度
Note：1,2,3三月是第一季度，4,5,6三月是第二季度，7,8,9三月是第三季度，10,11,12三月是第四季度。
最佳报表期：1.2两月的最佳报表期是上年第四季度，3,4,5三个月的最佳报表期是本年第一季度，6,7,8三个月的最佳报表期是本年第二季度，9,10,11的最佳报表期是本年第三季度，12月的最佳报表期是本年第四季度。
半年报任务
格式：年+01或02+两横杠，如200901--表示2009年上半年
Note：半年报把每年分为上半年和下半年。每年前六个月是上半年，后六个月是下半年。
最佳报表期：6月以前的最佳报表期是上年的下半年，六月开始到11月30日的最佳报表期是本年上半月，12月份的最佳报表期是本年下半年。
半月报任务
格式：年+月+01或02，如20090101表示2009年1月上半月
最佳报表期：以每月的16号为界，16号之前最佳报表期为上月的下半月，从16号开始，最佳报表期为本月的上半月。
旬报任务
格式：年+月+01或02或03，如20090101表示2009年1月上旬
Note：每月三旬。上旬：每月1-10日，中旬：11-20日，下旬：21日至月末。
最佳报表期：取当天所在旬的上一期为最佳报表期。1-10日取上月的下旬为最佳报表期，11-20日取本月的上旬为最佳报表期，21日-月末取本月的中旬为最佳报表期。
周报任务（月周报）
格式：年+月+周，如20090101表示2009年一月第一周
Note：每周第一天是星期天。第一个包含星期三的周是每月的第一周。每月最后几天若不含周三，它们与下个月第一周组成一周。
最佳报表期：取当天所在月周的上一周为最佳报表期。如2010 1月31日所在的周是2010年2月第一周，它的最佳报表期是2010年1月第四周。2010年1月有四周。
日报任务
格式：年+月+日，如20090101表示2009年1月1日
Note：一天有24个小时。
最佳报表期：每天的17:00之前，最佳报表期是上一天，从17:00开始，最佳报表期就为今天。
年周报任务
格式：年+年周+两横杠，如201001--表示2010年第一周，即2010年1月3日到2010年1月9日
Note：每周第一天是周日，年周的第一周是从第一个含周日的那个周开始。如2010年的第一周是从1月3日开始至1月9日。
最佳报表期：取当前日期所在年周的上一周为最佳报表期。
5日报任务
格式：年+月+01~06，如20100106表示2010年1月26日至月末
Note:一个月有恒有六期。第一期是从每月1日至5日，第二期是从每月6日至10日，第三期是每月11日至15日，第四期是每月16日至20日，第5期是每月21日至25日，第六期是从26日到月末，不管这个月有多少天。
最佳报表期：总是取当前日期所在期的上一期为最佳报表期。
13月报任务
格式：年+00~12+两横杠，如201000--表示2010年0月
Note：比一般的月报任务多了个 "零月"。
最佳报表期：与月报任务一样，填报0月需要设置可以填写最佳报表期以外的报表期，因为0月永远成不了最佳报表期。
任意时间报任务
格式：00000001~99999999，如00000002表示第2期
Note：任意报的期从00000001至99999999。
最佳报表期：根据用户填报的期生成其下一期为最佳报表期。
自定义报表期
格式：要求自定义的脚本是8位。
最佳报表期以自定义报表期中定义的为准。
附件给了一个自定义日报，该任务自定义报2.NRP.rar与日报类似，只不过系统的日报以17点为分隔点填写报表期，而此任务以上午9点为分隔点。
附件给了一个自定义5日报，该任务与系统中的t提供的5日报的所有规则都是一样的
可以通过创建物理主题，在数据库中创建出一个新的的数据库表（空表表样），可视化图形化的创建方式，方便快捷的通过BI创建数据库表。
通过BI界面，在数据库中创建表样。
类似于数据库中的视图表，他在数据库中以存储数据值集形式存在。作用相当于筛选，并且数据可以来自于一个或多个表。一般用于easyolap报表的制作，也可用于复杂的报表模板取数。
注意：虚拟主题的创建是以物理主题为基础的。
2、通过虚拟主题表可以定义较复杂、来自于多个物理主题的取数关系。报表模板直接取定义好的虚拟主题表指标：简化报表模板的制作和维护。
在本主题集下对其它主题集下主题表的引用，在BI@report中还不能跨主题集取数，因此引入了引用主题的概念，引用主题仅仅是对其它主题集下主题表的一个引用，没有自己的结构和数据，我们只是把它当做跨主题集取数的一个桥梁而已，最终取数还是来自于它所引用的主题表。
需要跨主题集取其他主题集下主题表数据。
I和BI需要使用相同表样，使用I从BI刷新取数，或者BI取得I中填报数据进行查询展示以及多维分析（olap）。
利用BI界面直接在数据库中建立一张表，表中字段设置与BI中设置相同。
管理员用户登录系统--->分析平台--->主题域--->主题集--->主题表—>右键菜单【新建主题表】
在上一步的图中界面，填写名称（ 名称只能是字母、数字、下划线组合并且只能以字母或下划线开头。*必填）、 标题，选择【物理主题】，点击【下一步】
创建完成之后，数据库中就会存在一张和所建主题表名称相同的数据库表。
想要分析数据库表中数据，新建一张和数据库表字段一一对应的主题表。
管理员用户登录系统--->分析平台--->主题域--->主题集--->主题表—>右键菜单【新建主题表】
在上一步的图中界面，填写名称（ 名称只能是字母、数字、下划线组合并且只能以字母或下划线开头。*必填）、 标题，选择【根据数据库表创建的物理主题】，点击【下一步】
在上图中选择BI中设置的【数据库连接池】方案，选择该连接池中对应的数据库表。
锁定数据库：指当（增、删、改）主题表字段时是否同步影响数据库内容，一般情况下勾选【锁定数据库】，点击完成。
点击完成后，会显示出下图所示界面，可以对字段进行修改，点击“红框”内菜单，保存主题表
别名：可以给数据库字段起别名，如果存在别名，分析表默认使用（表名.别名）
标题：对字段进行文字描述，在建分析表时能够通过标题的含义，很容易找到所需字段
是否维：如果否，则字段不对应任何维表；如果是，字段会对应一个和字段内容相符的维表（可以使用系统维表，也可以使用自己创建的维表）
虚拟主题是将来自于不同主题表的指标和维度整合到一张主题表中，使用虚拟主题表我们可以方便的进行easyolap的操作。将不同主题表的指标和维度整合到一张虚拟主题表后，如果要对该虚拟主题的指标进行分析，必须与原主题表建立表关联关系，不然系统会报错误。
注意：虚拟主题表的创建，是建立在物理主题表基础上的。所以在创建虚拟主题表之前，必须已经存在相应的物理主题表。
关于物理主题表如何创建，请参看《快速上手之物理主题创建》
有两个主题表【收入支出表】和【费用表】，表结构如下图所示，两张表的关联字段是bbq_和userid_。
要求：根据以上两张主题表，以及关联字段，创建一张虚拟主题表（包含字段，详见下面表格），再根据该虚拟主题表，做一个简单的拖拽式分析，分析内容为：行政区划（省份级别）分析各个省份的总收入/总支出/费用
|
easy _szfy 收支费用表 |
|
|
BBQ_ |
报表期 |
|
USERID_ |
机构id |
|
ZSR |
总收入 |
|
ZZC |
总支出 |
|
FY |
费用 |
|
USERNAME_ |
机构名称 |
|
XZQH |
行政区划 |
|
TJ_TYPE |
机构类别 |
在导航树的【主题表】节点上，点击鼠标右键，选择右键菜单中的"新建主题表"，就会在右侧工作区打开主题表创建向导，在向导的第一步设置虚拟主题表的名称和标题，并在下面主题的选项中选择"创建虚拟主题"。设置完成之后，点击"下一步"。
在刚生成的虚拟主题表中，选择树形显示，会默认存在一个空指标"newrow"，在该指标上右键菜单里面，选择"成批拾取"。系统会在工作区的下方加载所有主题表（该虚拟主题所在的主题集下面的所有主题表），同时，会弹出成批拾取的对话框。如下图所示：
拾取的方式非常简单，在主题表标签，切换到目标主题表，直接鼠标左键，选择需要的指标，所有选择的指标都会自动添加到成批拾取的对话框。如果指标来自不同的主题，可以看到成批拾取对话框里面，指标是按照所在的主题表进行分组展示的。拾取完成之后，点击确定即可。
拾取完成之后，所有的指标都会自动添加到虚拟主题表中，"newrow"空指标可通过右键菜单中的"删除节点"进行删除；
每个拾取过来的指标，都有对应的表达式，从下图中可以明显看到，FY字段是取自FACT_FY表，其他的字段都取自FACT_SRZC表；
所有设置和内容确认完成之后点击"保存"按钮，系统就会在左侧导航树中自动创建该虚拟主题表了。
如果虚拟主题表的指标取自多个主题表，此时就需要定义两个主题表之间的关联关系。在需求描述中已经明确指出这两张表需要根据bbq_和userid_这两个字段进行关联。那么如何添加主题表的关联关系呢？
选择主题集的右键菜单中的"属性"，在右侧工作区会打开所有主题集属性设置的内容，切换到"表关联关系"这个标签；
点击"添加关联关系"，就会弹出关联关系定义框，定义的方法，将需要关联的两个主题表打勾，定义关联表达式，并且自定义关联关系的名称，确定之后，"保存"主题集属性。至此，虚拟主题就创建完毕，具体操作流程如下图所示。
通过创建主题表，在数据库张同步建表，不过，该物理主题创建界面可以拥有表样，表样可以自己创建，也可以通过导入I的报表完成创建。
可以达到快速将I中任务做成BI报表的需求
管理员用户登录系统--->分析平台--->主题域--->主题集--->主题表—>右键菜单【新建主题表】
在上一步的图中界面，填写名称（ 名称只能是字母、数字、下划线组合并且只能以字母或下划线开头。*必填）、 标题，选择【创建带表样的物理主题】，点击【下一步】
表格中用户名、密码为文字描述，鼠标选中的空白单元格属性如图，可以设置（字段名、别名、描述信息、对应维表等内容），可以根据需求，建立表样。
也可以通过导入的方式导入表样（格式支持*.npf,*.fact：npf为I任务中的报表（..\【任务文件夹】\_Reports\）;.fact为已经建好的主题表），导入方式如下图
上图为导入完成后，点击红框内保存，完成创建。（导入后的主题表和导入的I的报表的表名相同）
也可以通过主题集–>主题表右键菜单中【导入npf文件】方式批量导入（.zip格式压缩包）
在BI@report中还不能跨主题集取数，因此引用了引用主题概念。引用主题仅仅是对其它主题集下主题表的一个引用，没有自己的结构和数据，我们只是把它当做跨主题集取数的一个桥梁而已，最终取数还是来自于它所引用的主题表。
管理员用户登录系统--->分析平台--->主题域--->主题集--->主题表—>右键菜单【新建主题表】
在上一步的图中界面，填写名称（ 名称只能是字母、数字、下划线组合并且只能以字母或下划线开头。*必填）、 标题，选择【引用主题】，点击【下一步】
如上图，可以BI引用平台中其他主题域中主题表，点击完成后，如图
目前部分项目用到了增强的身份证号码验证，要验证15位、18位、行政区划、日期合法性、校验位（仅对18位）等特点。
当前i产品仅提供一个函数idcheck可以用来验证身份证合法性，用法为：idcheck("PID", "421122199006137777")，返回值为字符串，为根据前17位求出的第18位校验位。
例如 如果(len(E1)=18)&(idcheck("PID", E1)=right(E1, 1))成立，通常地，我们认为该身份证E1合法。
但是这个对15位的没法校验，只验证长度的话，部分用户觉得不够。
2.解决方案一
目前暂时采用自定义函数实现，新增自定义函数
(1)validplace 判断行政区划是否满足。具体根据项目的不同，以及行政区划代码组的完备程度，可以校验前2位，或者4位、或者6位，如421122表示湖北省黄冈市红安县。
需要一个行政区划代码组。
(2)validmonth 判断生日串中的月份是否合法，即从第7（这里的7是从自然基序1开始算起的）或者9位开始的2位月份串是否为合法月份，对15位身份证，年份是2位，省略了前面两位"19"，对18位身份证，是4位全的年，所以起点不一样。
(3)validdate6 判断6位日期串是否为有效的日期，即从第7位开始的6位日期串是否为合法日期。
(4)validdate8 判断8位日期串是否为有效日期串，即从第7位开始的8位日期串是否为合法日期。
(5)ispid 增强的身份证号码校验函数，判断是否为合法的身份证号，
validplace(left(str,6))&(((len(str)=15)&validdate6(mid(str,6,6)))|((len(str)=18)&validdate8(mid(str,6,8))&(idcheck("PID",str)=right(str,1))))
具体见附件userFuncs.sys
使用方法：
(1) 把userFuncs.sys放到程序安装目录下，如果已经有该文件，并且该文件有内容了，就复制本userFuncs.sys内容到原userFuncs.sys后面
(2) userFuncs.sys中的自定义函数中使用的行政区划代码组名字改成所在任务中的行政区划代码组名字（保持一致）。
(3)之后就可以在设计任务表元公式或者审核公式时，使用函数ispid了，判断一个字符串是否合理身份证号。如ispid(D6)。
如果在设计系统中界面中修改了自定义函数，修改完后请任意修改任务（确保任务发生改变，需要保存），以将任务中使用自定义函数的公式重新生成后缀，确保客户端插件计算正确（此处有待增强）。
3.其他说明
说明：
(1)解决方法一并不是唯一方法，不是最佳的，也不是万能的， 可能需要根据具体项目不同需求进行相应调整。
解决方法一要求任务必须有一个行政区划代码组，至少在一级行政区划（省、直辖市、自治区）上代码要相对较为完备。
不同的客户，可能要求的登录界面行为、样式、风格都不一样。 本文描述如何在i@Report中控制登录页行为和样式。
适用版本：i@Report 4.2.1 , 4.2.2 , 4.3.1
默认登录页是main/login.jsp。可以传递一些参数来控制登录行为。
(1). 可以通过server.property参数来设置登录id输入框下方是否要弹出任务组下拉列表：
例如，设置登录类型为服务器用户登录。此时登录界面上不会显示任务组下拉列表供选择
logintype=user
logintype参数取值有：
· bbh: 登录框下方只显示任务组的下拉列表。
· user: 登录框下方不显示任务组下拉列表
· all: 不设置logintype时，默认为此种类型，显示完全的服务器及任务组下拉列表供选择。
(logintype参数只适用于4.2.2)
(b). 在login.jsp的url后传递参数，使登录后进入不同任务组或跳转至指定url
登录指定的任务组：
main/login.jsp?grpname=XXX&grpcaption=YYY
其中grpname参数后的XXX和grpcaption参数后的YYY分别代表默认要登录的任务组名和标题。访问此链接，登录界面上将自动选择此任务组，输入用户名密码登录后将直接进入此任务组。
登录后跳转到指定的URL：
main/login.jsp?forward=XXXXXXX
其中forward参数后的XXXXXXX是要跳转的url地址。可以是相对地址，也可以是http开头的绝对地址。
应用举例：
某系统只有1个任务组和任务，想登录后直接进入任务进行数据查看、填报等操作。
URL的写法是：
main/login.jsp?grpname=XXX&grpcaption=YYY&forward=main/listbbq.do%3FtaskId=GUID
然后将此url在服务器管理中设置为服务器的登录页即可。
i@Report的登录页面的基本构成元素如下图所示：
(1)信息提示区：用来显示登录过程中的提示信息或者登录失败后的异常信息．此元素可以是标准的DOM元素，如div,span或table等.但不能是表单元素．
(2)登录目标：显示要登录的目标任务组或服务器． 此元素可以是标准的DOM元素，如div,span或table等．但不能是表单元素．
(3)用户名输入框：用来输入登录帐号的输入框．必须是input元素．(5)登录按钮：用来点击进行登录用的．可以是button,或img等元素.
这些基本元素在页面上的位置可以任意设置。可以最大限度的满足美工要求。
要想在新设计的登录页面实现登录，必须在页面中嵌入如下脚本：
你只要将脚本中的界面元素的ID替换成新设计的登录页的界面元素的ID即可。
此段脚本要放在登录页的标签后面。
假设新设计的登录页放在i/oem/mycompany/login.jsp, 则，通过管理员登录，进入"服务器管理"-->"服务器首页"，在界面上的"登录页面"中输入"oem/mycompany/login.jsp"即可。保存后，点击注销，即可看到新设置的登录页面了。
采集流程
数据填报
基层单位录入任务报表、计算、审核、上报的过程叫做数据填报。
数据汇总
数据汇总是指各下级单位录入数据并上报后，上级单位把所有下级单位的数据汇总合并到一起。i@Report中支持2种汇总方式：汇总所有和选择汇总。
数据审核
用户在录入数据的过程中，难免会出现误差。数据审核是指：为了保证填报的数据质量，系统支持通过定义审核公式的方式，用以检查所填报的数据是否满足一定的勾稽关系。数据审核包括：逻辑性审核和合理性审核。
数据审批
审批是一个核准、批示的过程，是对报表户上报数据的一个控制。数据审批可以检验报表户上报数据的合理性。其目的是对报表户的数据进行检查，检查批准后数据方可正式上报。
任务发布
将设计好的任务发布到服务器的过程，叫做任务发布。系统支持对已经发布的任务进行修改，修改后通过再次发布，实现任务的更新。
任务设计
任务
报表任务，就是相关报表构成的集合。如某一会统月报中有21张表，这21张表就构成一个报表任务。直观地理解，报表任务就是日常所说的一套报表。
任务组
任务组是对任务进行分类管理的一种方式。例如：某一单位有多个部门，每个部门都有自己特有的报表任务。某部门的报表任务只允许该部门相应的下级才能访问。为此，我们可以为每个部门建立一个任务组，将某个部门的所有报表任务放入该任务组中。这样，用户只能访问自己部门的报表任务，而不能访问其他部门的报表任务。（一个任务组中任务使用同一报表户列表）
报表期
报表期指报表收集填报所属时期。例如月报任务，2010年9月是其中的一个报表期。
报表期类型
在设计报表任务时，必须要指定任务的报表期类型，常用的报表期类型有年报、半年报、季报、月报、半月报、旬报、周报、日报、五日报、年周报、任意报等。这些报表期的任务数据的报送间隔时期是系统设定的，用户不能更改。有时这些报表期类型并不能满足用户的需要，用户需要自己设定数据的报送间隔时期，比如：三日一报，或一日三报。这都需要由用户来自己定义报表期。
最佳报表期
填报户进入填报界面后默认显示的报表期为该填报户的最佳报表期。不同报表期类型的填报任务，系统默认的最佳报表期不同。
报表设计
基本表
基本表是指行列固定的采集表样。从数据库的角度理解，一张基本表对应数据库中一张数据库表，每个报表户填报的内容为该数据库表中的一条记录。
变长表
变长表是列数固定，行数变化的报表。用户在设计表样时，变长表只包含一行变量表元。用户录入数据时，可增加或减少变量表元行，但纵向上的指标保持不变。
嵌套表
嵌套表为组合类报表，是两张或两张以上报表，通过表元属性设置的方式，把其他做好的报表嵌入到另一个报表的表元中。
固定表元
固定表元是指在设计报表时，设计者已确定其表元内容（一般用来填写指标名称），且用户录入数据时不能对其进行更改的表元。
变量表元
变量表元用于给用户进行数据的录入。变量表元包括多种类型，不同类型的表元用于录入不同的类型的数据，如：整形、浮点型、字符型、逻辑型、日期型、备注型、图像、OLE文档、时间型、附件。
代码组
代码组相当于一个数据集合，可以在表元属性中进行设置使用，这样既可以限制非法的内容输入，也减轻了用户的操作负担。并且，代码组是系统级的，可实现一套代码可以多个任务使用。
用户类型
报表户
报表户就是报表所属的单位。报表户列表一般指需要上报报表到本单位的下级单位列表。
基层户
基层户是报表户列表中叶子节点所代表的填报单位，主要进行数据的填报，在数据库表中用BTYPE_字段表示（用0代表基层户）。
汇总户
汇总户是报表户列表中叶子节点以外的填报单位，可以对下级填报户填报内容进行汇总，在数据库表中用BTYPE_字段表示（用9代表汇总户）
服务器用户
服务器用户可以兼具填报查看数据和维护管理服务器的能力。 报表户常以机构或公司名称命名，而服务器用户多以具体的操作者姓名命名，将资源和权限灵活分配到个人，能高效有序的管理整个系统。
本文从BI生成 sql 的原理解析入手，结合实际项目中报表设计优化的典型案例，系统讲解了BI分析表设计中性能攸关的设计要素。
一张分析单主题表的典型sql语句如下：
SELECT id,avg(sal) avgsal
FROM table
WHERE id<>"0000"
GROUP BY id
Having avg(sal)>5000
ORDER BY avgsal
这段语句中的粗黑体是sql语句的保留关键字，他们是sql语句的主体骨架，蓝色部分是查询统计的具体数据库表、字段、过滤条件、分组和排序依据；将蓝色部分"翻译"成BI分析表中的设计元素后，sql语句如下：
SELECT 表元表达式
FROM 主题表
WHERE 过滤条件 （含表元、维表元、主题集过滤条件及数据期条件）
GROUPBY 维表元（带下钻级次）
HAVING 结果集过滤
ORDERBY 排序依据
可以很清楚地看到，报表工程师们在制作分析表，设计报表和表元的各种属性时，其实是在间接地编写着BI分析报表的sql；因此BI中sql语句性能的好坏，报表工程师有很大的决定权。
如果分析表的数据来源于多个主题，BI分析表的sql需要将多张主题表连接；典型的sql有两种：
......
(SELECT 表元表达式
FROM 主题表1
WHERE 过滤条件（含表元、维表元、主题集过滤条件及数据期条件）
GROUPBY 维表元 （带下钻级次）
) T1
JOIN （支持INNER JOIN、RIGHT JOIN、LEFT JOIN、UNION ALL）
(SELECT 表元表达式
FROM 主题表2
WHERE 过滤条件（含表元、维表元、主题集过滤条件及数据期条件）
GROUPBY 维表元（带下钻级次）
)T2
ON T1.维表元字段 = T2.维表元字段 ......
红色部分是相对单主题sql新增加的典型元素；其中join方式可以是内连接、左连接、右连接、全连接，具体是哪种取决于主题集属性中的OLAP连接计算规则，如图：
有些分析需要在两个主题的明细数据上进行运算和关联，此时不得不在sql中将两个主题表先连接再分组统计；其典型的sql如下：
......
SELECT主题表1. 表元表达式1 ，主题表1. 表元表达式2 ,主题表2. 表元表达式1
FROM 主题表1
JOIN（支持INNER JOIN、RIGHT JOIN、LEFT JOIN、UNION ALL）
主题表2
ON主题表1.关联字段1=主题表2.关联字段1...
WHERE 过滤条件（含表元、维表元、主题集过滤条件及数据期条件）
GROUPBY 维表元（带下钻级次） ......
从表面上看，此处的红色部分新增元素好像和【先分组后连接】差不多，是不是两种sql性能相当呢？
让我们一起考虑一下这样的场景，主题表A和B均有10w行明细数据，需要按行业大类（20行）统计来自A和B的某些指标；
【先连接后分组】需要首先将两个10w行规模的明细表join起来，之后再按行业分组；
【先分组后连接】会分别在主题A和主题B上分组后再按行业大类join，此时连接的仅仅只是两个20行的子表；性能相比，孰优孰劣，一目了然！
【先连接后分组】方式下，主题明细数据表连接的方式由报表设计中的什么元素决定呢？请看下图，是主题集属性中的表关联设置：
查看分析表的【详细信息】，有时我们会发现为了计算一张分析表，BI生成了多个子sql嵌套和连接，或者干脆是多个独立的sql，为什么会这样呢？
要弄清这个问题，咱们得先回头再看看之前提到的sql语句：
SELECT表元表达式
FROM 主题表
WHERE 过滤条件（含表元、维表元、主题集过滤条件及数据期条件）
GROUPBY 维表元（带下钻级次）
HAVING 结果集过滤
ORDERBY 排序依据
一个这样的Sql语句可以查询出满足where子句条件的一批指标，如果有指标虽然来自同一个主题，但过滤条件不一样，还能用这一个sql一并统计出来吗？
假设现在需要统计主题表1中的多个指标，对zb1，zb2zbm的统计sql如下：
SELECT zb1，zb2...zbm
FROM 主题表1
WHERE filter1
主题表1的【zbn】也需要统计分析，其过滤条件是filter2，和其他指标zb1，zb2都不一样，那么对zbn的统计能和zb1,zb2等指标一起放在一个sql中吗？
答案很显然，不能！否则算出来的zbn就是filter1过滤后的统计值，而不是分析需求filter2的。
因此，如果在BI分析表上我们为表元zbn设置了特殊的过滤条件，BI的sql一定需要单独为这个指标生成一个子sql，比如：
SELECT zbn
FROM 主题表1
WHERE filter2
在sql元素中，除了过滤条件之外，还有连接方式的不统一也会造成BI生成多个子sql。正常情况下，假设A和B主题表连接分析的sql如下：
SELECT主题表A.zb ...主题表B.zb1 ，主题表B.zb2
FROM 主题表A INNERJ OIN 主题表B
ON主题表A.关联字段1=主题表B.关联字段1
若将B的zb1，zb2设置为左连接，将B的zb3,设置成右连接，由于连接方式不同，无论是【先分组后连接】还是【先连接后分组】，这两张主题表的连接都必须按指标的连接方式拆分为两次join；如下：
（SELECT主题表A.zb ，主题表B.zb1 ，主题表B.zb2
FROM 主题表A LEFT JOIN 主题表B
ON 主题表A.关联字段1=主题表B.关联字段1 ）
和
（SELECT主题表A.zb，... 主题表B.zb3
FROM 主题表A
RIGHTJOIN 主题表B
ON 主题表A.关联字段1=主题表B.关联字段1 ）
如果在报表设计上设置了多个独立的分析区，BI会为每个分析区单独生成独立的sql语句。因此我们需要注意，多个分析区真有必要独立分开吗？如果可以合并到一起，BI会尽可能用一个sql提交数据库处理，在某些场景下，特别是对数据量巨大的主题表而言，两次查询统计变成一次，性能上将会有不小的提升。
|
2011-08-02 17:14:10执行查询耗时1秒203毫秒。（内存情况：FREE=134.9M TOTAL=213.9M MAX=910.2M） |
你一定很熟悉这个方框中的信息模式吧？这是BI中一张分析表的详细信息，但是==，为什么在一个分析报表的详细信息中会看到如此多不同报表的sql生成和计算日志？ 原来这张分析表使用了跨表取数，为了计算这张报表，系统先触发执行了其他报表的sql，具体详情请参考《tips201106》；这种情形下，虽然本表没有产生多个sql，但是间接地通过计算其他表，也执行了多个独立的sql，造成本表计算时间超长。
作为一个报表工程师，在设计报表的过程中，有哪些和sql性能相关的要素是我们可以调控，需要特别关注的呢？基于以上对BI分析表sql的理解，报表工程师们可着重关注如下要素： 1.过滤条件 2.连接模式 3.Sql个数 4.Sql数据量
下面将分别从这几个方面具体谈谈如何优化BI分析报表的设计。
BI分析表中的过滤条件在报表计算时都会转换成SQL语句中的WHERE条件，在大数据量的情况下，WHERE条件不够优化，会直接导致SQL语句运行效率低下，最直接的表现就是SQL语句执行时没用到索引或者用到的索引不够好。 我们都知道索引在rolap数据仓库中至关重要，好的索引对查询统计分析的性能提升具有不可替代的作用。因此，一个好的where条件会尽可能充分利用好的索引，决不会破坏数据查询走索引的可能。 BI报表的主题集、维表元、指标表元上都可以设置数据期条件和过滤条件，报表工程师们在这些过滤条件中编写的表达式都将直接决定报表sql语句中where子句的质量；什么样的过滤能构成一个质量上乘的where子句？什么样的过滤一定会造成where子句效率的损失？我们在编写BI报表过滤条件时又该注意哪些问题呢？
一般的统计图跟表格的展示是分开的，从布局上来说相对独立。那么有一种统计图，很小，可以嵌入到表格内部去显示。
如下图所示，分析历年的医疗指标（治愈、好转、），要求显示每一年四个指标人数的占比图。如果用一般的统计图，那么就有几个问题，首先，历年是不确定的数量，到底应该添加几个统计图呢？再是排版问题，如果年数很多，这么多统计图要如何排版？
如果用迷你图，嵌入到表格中，可以轻松化解上述两个问题，一起来实现以下吧！
在表格的最后增加一列，作为迷你图的展示列，为了让图形展示的比例更加协调，可以适当调整表格的行高和列宽。
此需求是要看各个医疗指标占比，环形饼图是最合适的，所以这里就选中组件迷你饼环图，拖拽的方式添加到表格的最后一列即可：
鼠标双击迷你饼图，就能打开图形的设计窗口。必须要定义的是数据区域，支持鼠标拾取。
浮动面板：在报表结果页面，悬浮在报表的右（上、下、左、右）侧的功能面板。浮动面板区域可以添加计算参数、按钮、文字、图片等功能组件；
就以上图报表为例，报表已经涉及完成，需要为该表添加两个浮动面板
· 浮动面板1：添加报表期计算参数和计算按钮；
· 浮动面板2：添加该表的文字说明；
在报表编辑界面，点击工具栏上的按钮"显示浮动编辑区"，在此状态下才能为报表添加浮动面板
浮动面板可视为一般的报表容器，可直接拖拽的方式给浮动面板添加参数组件，而且参数组件的编辑方式也保持不变。
· 参数面板拖入"日期"参数组件；参数名称和标题自定义为@bbq、报表期；设置参数类型为年（因为数据的时间颗粒是到年）；并设置报表的过滤条件bbq()=@bbq；
· 参数面板拖入"按钮"参数组件；参数名称和标题自定义为@js、计算；设置按钮事件为"计算"；
用同样的方式，再拖入一个浮动面板；再用拖拽的方式为浮动面板添加文本组件；编辑文本内容；
如果有需要，可以修改一下浮动面板的图标，修改图标的方式是选中该浮动面板，有属性"图标路径"，即可设置；
默认两个浮动面板都是收起的，只要点击图标，就能展开浮动面板啦！
BI@Report经常需要与第三方系统进行集成，集成方式多样。比较常见的一种方式，就是通过URL调用BI中的报表资源，集成在第三方系统中。
本章我们一起来了解一下BI41的URL接口
在BI4.1中，以.do作为请求URL的后缀。BI41支持调用多种报表资源，包括：分析表，主题表，easyolap，分析报告和结果表等。
|
.rpttpl |
报表模板 |
Showreport.do |
|
.rpt |
报表模板 |
Showreport.do |
|
.rptolap |
easyolap |
easyolap.do |
|
.doc |
分析报告 |
wordreport.do |
|
参数名 |
含义 |
值举例 |
说明 |
|
resid |
资源id |
|
在报表属性中可找到资源的唯一ID |
|
calcnow |
显示报表时立即计算一次 |
false|true |
根据URL中带上的报表参数，计算报表 |
|
calcwhenold |
结果表不是最新时才计算 |
false|true |
类似calcnow。区别时当没有结果表或者当前结果表对应的分析表比现有的分析表旧时（当前结果表对应的分析表被改动）才自动计算 |
|
waittime |
等待时间 |
1000 |
当calcnow为true或calcwhenold为true时waittime参数有效，表示showreport.do等待报表计算完成的最长时间，如果在该时间内报表计算完成，那么直接显示计算结果，如果在该时间之内报表还没有计算完成，那么URL将返回给客户端一个等待计算页面。 waittime以毫秒为单位，缺省值是1000，最大不能超过10000秒. |
|
showparams |
简洁模式 |
false|true |
为true表示以简洁模式显示 |
|
showtype |
简洁模式下参数面板的状态 |
hide|collapse|其他 |
1. 1.hide，表示参数面板区完全隐藏。 2.collapse，表示参数面板区默认收起，可以再展开。 3.不传递此参数或者其他值时则默认展开参数面板区。 |
|
showmenu |
显示菜单栏 |
true|false |
决定是否显示内置的菜单栏（显示计算信息、再次计算、计算结果处理等的菜单） |
|
dontshowblankrpt |
不显示空表样 |
false|true |
如果是没有计算的空表，那么此变量控制它是否需要显示，默认显示(true) |
|
dontshowrpt |
不显示表样 |
false|true |
不显示表样，只显示参数，只有当计算以后才显示表样 |
|
isprint |
打印预览 |
false|true |
是否需要打印预览功能，当为true时，弹出打印预览的设置框 |
|
saveid |
结果表ID |
32位资源ID串 |
为空时表示获取默认结果（报表参数和数据级次可以根据请求和登录信息给定） |
|
loadcalccache |
装入计算缓存 |
false|true |
为true且立即计算，且saveid为空时，从上下文以及请求参数获取默认结果表 |
当为calcnow时，一些常见的控制计算的参数举例
|
escape |
当参数中有中文字符时，链接中必须有escape=true参数，并且需要用encodeURIComponent方法将中文转码 |
|
encode |
|
|
holdtime |
|
以下示例所用的url，都是相对于服务器访问路径（如：http://127.0.0.1:8080/bi）的，且默认用户已经登录BI。
1. 显示某一张报表的最新结果表
showreport.do?resid=XXX$12$xxxxx
2. 使用calcnow参数使报表根据URL中的参数计算
showreport.do?resid=XXX$12$xxxx&calcnow=true&@bbq=201507&@xzqh=110000
3. 显示报表，并显示参数面板
showreport.do? resid =xxxxx$12$xxxxx&showparams=true
4. 显示报表，默认不显示菜单
showreport.do? resid =xxxxx$12$xxxxx&showmenu=true
其中，菜单指
直接调用BI41中的分析平台界面
在BI41中，我们还可以通过login.do的方式去调用BI中的各类报表资源，调用方式与showreport.do相似
如： http://127.0.0.1:8087/bi/esmain/login.do?id=admin&pw=admin&url=../showreport.do?resid=EBI$12$8I6BNNR4IKQ6UTDI1NF97E3Z6ZIWJK6A$1$5SMFL4U3SUXMJ1JS1WIC6X7VUISVUL4V.rpttpl
其中需要注意2个 地方 ：
在上下文根中，需要添加esmain
URL后面调用的showreport.do,需要写成: ../showreport.do
豌豆BI，人人都可以用起来的自助式分析工具。数据模型和数据处理是数据分析的基础，但是数据仓库、数据模型、维度、指标、关联关系等模型的设计和处理，存在一定的技术门槛。为了让业务人员可以自助完成数据分析，WonderBI自动识别指标维度和关联关系，形成数据模型。在数据处理层面，类Excel界面操作，通过点选式操作轻松完成去除重复行、空值替换、数据裁剪、数据脱敏、类型转换等操作。
本讲座选自华宇软件吕宾先生于2015年6月5日在RONG系列论坛之四——大数据与诚信社会研讨会上所做的题为《大数据在防范偷税漏税方面的作用》的演讲。
吕宾先生于1997年毕业于中科院软件所，获得硕士学位。1997年就职于北京九州计算机网络有限公司，担任副总经理职务，先后负责了公司多项产品的研究开发和推广工作，2001年获得北京电子政务推荐应用。2003年开始就职于北京华宇软件股份有限公司（原北京紫光华宇软件股份有限公司），现担任董事、副总经理职务，主持华宇集团大数据应用与服务相关的经营业务，涉及行业包括税务、金融、政法、食品药品监管、卫生等。
吕宾：尊敬的韩院长、各位专家、各位同仁，大家上午好，非常感谢组织者给我这么一个机会能向大家汇报一下我们正在做的大数据应用方面的具体工作。
05年我开始在集团主管与数据应用和服务相关的工作，包括现在非常热门的大数据应用。多年来，华宇参与了很多行业的数据应用信息化建设，比如在税务、银行、卫生、政法等，同时我们为越来越多的行业监管分析工作提供专业的数据应用服务。
这是我们公司从2001年11月上市以来的股票价格走势，我们公司奉行的是稳定发展的理念，发展还是比较平滑、向上的。人家说不对，这上面有两个断崖式的跳水，那是因为我们做了两次10送10的分配,因此总体来讲还是很连续的，从上市的发行价到现在，公司又成长了八倍多,也给股东带来了比较好的回报。围绕着大数据业务，整个集团在多个方向进行布局，有今天要给大家介绍的税务方向，也包括我们长期服务的司法领域、工商信用领域以及食品安全相关的互联网营销等方向。
具体汇报内容分三个部分：
第一，大数据在税务领域的实践介绍。
第二，防范偷税漏税的大数据应用。
第三，应用的挑战和展望分析。
税务的大数据应用可以从宏观和微观两个层面来展开。微观层面的主要目标是提高企业纳税遵从度，查处涉税的违法、犯罪行为，保证财政收入的稳定发展。宏观层面通过税收相关的指标分析，反应宏观经济的真实状况，对国家出台的政策进行后续的效果评估，对税收工作本身的开展进行成本效益的分析。
我们通过增值税发票的流向、流量分析支撑政策效应评估选题,选择增值税作为研究的主要依据有两个，第一个是它符合我们国家以流转税为核心的税制体系;第二，所有的增值税数据都源自实际发生的业务,纳税人对增值税的遵从度比较好。
分析的难点有两个：第一个难点是数据量非常大。目前增值税专用发票数据将近十亿条，每条数据不到1K，但是在新的改革方案上，增值税数据将涵盖商品交易的明细，数据量将扩大到每条200K到2兆的量级。增值税发票数据采集的力度增加使今后分析难度增大的同时将会给管理部门带来更好的应用价值。如果真正实现全社会的交易数据都在发票中体现，现在互联网上流行的比价软件就没有了实际的意义,当然，这是以数据公开为前提的；第二个难点是发票变化规律难以表现。基于这样的一些特点和难点，我们采用了大数据的处理方法和可视化的改进技术来研究这个课题。
先看一个动态分析图，这是我们系统中用可视化工具实现的增值税流量、流向分析图。圆点代表地区贸易总量，弧线的宽度和地区之间的贸易量成正比。从2007年到2013年的7年间，各地区的圆点越来越大，说明地区的贸易总量越来越大。反应地区之间贸易关系的弧线越来越粗，说明地区间的贸易量在快速增加。
弧线在2009相对2008年略有变细。反映2009年度贸易活动比2008年有所减弱，这跟经济危机的发生比较吻合。
我们进一步对出口退税数据进行分析，从图上看出，这段时间出口退税的增幅迅速下滑，经济危机对国内贸易活动的影响得到了印证。
为了应对金融危机，国家采取了四万亿拉动内需的行动，投资的流向从税收数据上可以非常明显的反应出来，流向了铁路公路等基础建设方面。分析图上不难看出，建筑行业快速增长，与之对应的整个行业的增长率则是比较明显的下滑。
从发票流向动态分析图中，我们可以看到，07年北京和广东的贸易往来是非常弱的，弧线非常不清晰。但是从07年之后到2013年，北京和广东之间的贸易关系增强了，特别是2013年之后贸易关系变得更强，这个阶段正好是京广线高铁全线开通的过程。参考相关数据指标，我们可以得出铁路的发展对实体经济有正向影响的结论。
从图上可以看出，弧线的热度形成了三个闭合的贸易区域即长三角经济区、珠三角经济区和京津冀经济圈，这正好和国家的宏观经济规划相吻合。
我们可以选定京津冀经济圈对税务大数据按行业往来进行进一步的分析，为国家宏观经济决策提供产业规划信息。
大数据在防范偷税漏税的应用讨论中，我们以纳税人画像技术为例。纳税人画像技术最早应用于电子商务的消费者行为画像，是互联网思路的体现。举个例子，如果一个消费者，经常在超市买红牛饮料和方便面，大家会有什么样的想法呢？这个人很可能是一个搞IT的程序员，或者是咨询师，如果同时他平均每天中南海香烟消费量超过一包，很可能是还没有女朋友的男程序员。纳税人也可以利用这个思路来进一步精细化的管理，把纳税人的行为特点和诉求进行分群，有针对性地调整风险评估的策略。
我们按照纳税人的“性格”、“行为”等特征对其分群，比如我们可以根据选定标签指标值的区间范围将纳税人划分为稳健守法型、激进冒险型等等。
对下图中的指标标签，大家可能有些疑问，比如大家可能认为交易用现金和刷信用卡没有太大的区别，或者在交易频率跟涉税有什么关系。举例来说，庆丰包子、海底捞和湘鄂情他们都是餐饮行业，他们在规模上可能也曾经都规模较大，但是从涉税管理的视角，他们的细分差异是非常大的，庆丰包子开发票的比例是非常低的，海底捞可能有一半人开发票，但是在湘鄂情因为公款消费比较多，几乎都是要开发票，他们的涉税特点是非常不一致的。
实际工作中我们将影响纳税人涉税行为的基本指标打上标签，选择单个或多个指标，根据其实际的值，完成纳税人画像。
纳税人画像和传统的底层数据挖掘分析相结合，使纳税人精细化管理更加有效。举个例子：我们根据绩效压力、信用等级、交易频率等基础指标的值将纳税人划分为稳健守法型和激进冒险型两类。针对稳健守法型企业，我们认为他不需要在纳税环节节省他的经费，他偷税漏税的风险相对比较低。于是我们选择激进冒险型的企业做进一步的监管，通过传统的数据挖掘分析，对风险指数在0.6以上的纳税人，采取现场纳税评估，确实是查到了很多的违法行为，也为国家查补了相应的税款。
大数据应用在加强税收监管的同时，也可以为纳税人提供纳税服务。针对不同的纳税人画像提供适合其业务现状的税收法规处理指导，比如，提供一年中获得奖惩的记录，推送给他重要的减免税的优惠信息，设定他在纳税方向的信用评级，这些都是现在正在进行的工作。
目前我们国家税收法律、法规繁多，对于一项税务处理可能会涉及到几个甚至十几个来自国务院、财政部、税务局等多部门的相关文件，对于非法律专业出身的纳税人税务处理人员难以准确理解政策内涵，造成不恰当的会计处理。另一方面国家在出台法律法规的时候由于没有纳税人的全面画像考虑，容易遗漏特殊情况的纳税人，举个例子，我们下属的一个子企业，09年成立，连续两年未盈利，没有享受到（财税《2008》1号）自盈利起两免三减半的政策；2011年，（国发《2011》4号）政策的出台没有明确我们这类企业如何处理，如果不享受4号文件的优惠政策，我们将面临几百万量级的所得税费用。经过多次政策的研究和相关部门的沟通，这个政策后来做了修正，修正对于众多的和我们有类似情况的企业意义很重大。如果有很好的基于纳税人画像的服务体系，把这个信息推送给企业，我们将节省很多资源。纳税人的政策解读及税务处理服务对于万众创新、创业会有很好的帮助。
大数据在防范偷税漏税方面的应用，面临的最大的问题是数据的采集和整合，税务大数据分析涉及到社保、海关、银行、财政、保险、交通等多部门、多行业数据。
政府数据整合面临着方方面面的困难，这张图只能是一个很理想的状态，我们所有相关的政府基础数据都能够按照统一的数据标准，将数据推送到统一的数据平台，并且在这过程中进行有效的数据清洗、转换，通过统一的平台发布给各个行业使用。
以个人所得税为例，基于数据整合平台，个人所得税的申报会更真实。目前国家层面正在进行个人所得税税制改革的研究，有可能推出综合和分类相结合的个人所得税的税制，我们应用前面在企业纳税人方面提到的基于纳税人画像的风险评估策略，去开展个人所得税风险防范方面的分析。
税务大数据应用面临巨大挑战，需要丰富的行业经验与很强的资源整合能力，需要掌握数据分析核心算法与模型，要在大数据可视化技术方面有很好的积累，需要整个团队有全面的技术和服务经验。
谢谢大家！
整理：祁德力
校对：祁德力
一键部署、丰富的数据接口、自动建模、一键数据探索……帮助企业和政府快速构建决策分析平台
灵活的分析看板、可视化数据处理、文本数据导入……面对突发的分析需求，无需技术人员支持，实时获得数据答案
敏捷计算引擎是自主研发的第三代计算引擎，从DW/BI理论出发，融合SQL技术，OLAP技术，并行&异步计算技术，使计算速度和用户体验达到极致
为了保证分析结果的准确性，在数据分析前需要进行垃圾数据的清洗转换。豌豆BI颠覆了以往需要依赖技术人员完成数据预处理的模式，较其它自助式BI更符合业务人员使用习惯，全部采用点选式操作，让会使用excel的用户就能轻松完成去除重复行、空值替换、数据裁剪、数据脱敏、类型转换等操作。
大家还记得上周四公司年会上豌豆BI的发布操作演示吗？产品经理通过失信人的敏捷分析展示豌豆BI，根据不同的年龄段、学历等去分析失信人数，若是大家在那么短的时间里记不住如何去使用豌豆BI，这次小编详细整理了如何轻松上手玩转豌豆BI。
在玩转豌豆BI之前，我们来回顾一下豌豆BI适用人群：
喜欢自己DIY完成数据分析的用户
有文本数据，不关心数据模型，希望直接分析的用户
有快速定义、高交互要求的用户
在了解了豌豆BI适用人群后，我们再来看怎么使用豌豆BI。
现我们用豌豆BI实现这样的需求：
第一步：导入数据源
用户登录后默认进入向导页。
点击向导页中的“添加看板”，进入导入数据源界面，数据源选择“EXCEL”。
选择上传文件，设置字段行和数据起始行。
点击下一步，进入数据预处理界面。
第二步：数据预处理
在数据预处理界面可以对数据做些简单处理，如增删行列、修改数据等。
修改数据源名称
修改列标题
弹出列设置对话框，在对话框中修改标题为“员工ID”，确定后，显示在数据表格的列头上。
修改数据类型
再在弹出的对话框中选择“确定”，完成类型修改。
查找替换
弹出查找替换对话框。
“查找内容”输入-，“替换为”不输入，点击“替换全部”，完成选中列的替换，也可多列替换或者不选中列进行整表替换。
关联维表
弹出关联维度对话框，勾选“人员”维前的单选框，“确定”，完成维表关联。
保存
数据处理完成后，点击“保存并分析”，可以选择保存到新建主题集，或者保存到已有主题集。
这里，选择保存到已有主题集“周报分析”下。确定后，进入看板编辑界面。
至此，数据源创建完成。可以在数据源模块中个人主题下找到刚才创建的数据源。
第三步：制作敏捷看板
拖入维度指标生成图表
在看板编辑界面，左侧维度指标面板中，在“员工id”上按住鼠标左键不放将其拖入到工作区，放开鼠标，生成图表。
同样的方法，拖入指标“自然工时”到工作区，也可以拖入到行列面板区。
自动生成图表。
目前统计的是全公司的自然工时，需要按中心统计自然工时该怎么办呢？这就需要修改维度的展示级次。
修改维度展示级次
在行列面板区，找到“员工id”，点击它旁边的三角下拉按钮，弹出菜单，选择展示级次中的“中心”，则统计图中变成按中心进行展示。
这样，就做出了一个单图表的看板，需要做一个多图表的看板，应该怎么做呢？
多个图表
继续拖入维度到工作区，这里，我们把维度“日期”鼠标左键按住拖入到工作区右侧，直到右侧出现图a所示感应区，放开鼠标左键，出现第二个图表，如图b。
（图a）
（图b）
拖入指标“自然工时”到第二个图表所在区域，或者拖入到第二个图表的行列面板区中。
这样，第二个图表就做完了。
接着我们做第三个图表，和第二个图表做法类似，这里我们只介绍如何正确感应的第三块区域。
如上图，将指标按住不放拖到工作区底部，即上图所示红框中区域，就能感应到图中所示第三块区域。
切换图形
接着我们看下如何把上图中第一个统计图换成饼图，第三个统计图变成表格。
先选中第一个统计图，然后点击工具栏上的智能面板按钮，在弹出的智能面板对话框中选择“饼图”即可切换成饼图。
同样的，选中第三个统计图，在智能面板上点击表格，就能将这个线图变成表格了。
或者使用图表组件自带的“图表切换”功能进行图表切换。
数据过滤
基于上面的表，我们只想统计出差的数据，该如何办呢？
方法一
将维度“是否出差”鼠标左键按住不放，拖动到左侧筛选区。
放开鼠标左键，生成筛选参数，点击输入框旁的三角下拉按钮，在弹出的对话框中选择“出差”。
这样，就完成只统计出差数据的过滤。
方法二
左侧面板切换到工具下，拖入筛选区到工作区。
然后左侧面板切回到维度指标，拖入维度“是否出差”到工作区的筛选区组件中，自动生成筛选参数。
“是否出差”参数选择“出差”，完成数据过滤。
两种方法的差别
方法一和方法二这两种方式默认都是对整个看板做过滤，他们有什么差别呢？
1、显示位置不一样，一个在左侧筛选区，一个在看板工作区；
2、在看板查看页面，一个筛选参数看不到，一个筛选参数看得到。
左侧筛选区的筛选参数在看板查看页面看不到：
看板工作区的筛选参数在看板查看页面可以看到，并且能切换值进行过滤。
保存看板
现在看板已经做完，我们只需要将它保存就可以了。
点击保存按钮，在弹出的对话框中设置保存地址、看板代号、看板标题，点击“确定”完成保存。
发布敏捷看板
上面创建的看板只能自己看到（保存在我的看板中），如何将这个看板共享给其他用户呢？首先我们需要将这个看板发布到公共看板中，这样，其他用户被分配查看权限后，就能查看、计算这个看板了。
首先，在我的看板下找到要发布的敏捷看板，然后，在该看板上右键。
在弹出的菜单中，点击“添加到公共看板”，弹出“添加到”对话框，
选择要添加到的分组，点击“确定”。
至此，发布完成。公共看板中多了一张看板。
注：有权限的用户才能将自己的看板发布到公共看板。有公共看板下哪个分组的发布权限才能将自己的看板发布到该分组下。
在系统中已内置流程帮助（入口在向导页中），点击会打开相应的文档帮助。
看了这么多，你是不是想练练手？文章中涉及到员工每天的工作日志excel表格可以找小编获取，学习过程中的任何问题都可以与小编交流，期待你的声音。
采用全导航交互式设计界面，技术门槛低。不管是规则定义还是流程管理都无需编写sql或代码，通过图形化界面进行简单配置即可，使得非技术用户也能对定义过程和定义结果一目了然。
亿信BI支持多种数据源，包括SQL数据源、OLAP数据源、OLTP数据源、CUBE等，可以操作经过抽取（ETL）融合后的数据，也能直连业务数据库，并且支持文本数据的导入。
亿信BI支持世界主流的关系型数据库和分布式数据库，包括：Oracle、SQL Server、DB2、Sybase IQ、PetaBase、Cloudwave、Greenplum、Vertica、Netezza。
亿信BI采用了多种先进技术，如单元格报表、多数据源支持、区域绑定、单元格计算、参数化报表、自动延展等技术，确保用户能方便定义任意一张报表。
支持多级表头、多重浮动、分组、表元合并、斜线、富文本表元等复杂报表的定义，直观方便，就如同在EXCEL中画制。
亿信BI采用纯WEB打印技术，无需安装插件即可快速完成打印，打印输出所见即所得，打印效果和屏幕效果完全一致，提供打印设置，并支持套打、自适应纸张、撑满版心等多种打印方式。
亿信BI除支持简体中文、繁体中文外，还支持英文。除此之外，产品完全资源化，可快速扩展支持新语言。
亿信BI支持报表订阅，系统在制定时间将订阅的报表自动发送到订阅者的邮箱内
亿信BI具有灵活的计划任务管理功能，通过配制可以让系统定期自动执行某个功能，例如，对于数据量非常大的报表，可以设定其他在夜晚（系统空闲时间）执行计算，这样第二天用户就可以看到前一天数据的统计分析结果。
市面上大多数的质量管理平台是通过调用代码文件来实现数据检查，这种方式对于管理人员就像黑屋，过程不透明，可维护型差。EsDataClean采用零编码方式完成规则定义，通过可视化界面，普通用户即可完成规则的增删改查，定义结果清晰易理解，需求变动和人员变动影响甚微。
EsDataClean采用导航式可交互界面设计思想，使用门槛低，引导性强，普通用户即可轻松完成用户权限、监控范围、订阅告警等配置。
EsDataClean采用全导航式可交互界面设计思想，使用门槛低，引导性强，即使复杂的规则定义、流程管理等都无需技术人员编写sql或程序代码，只需通过图形化界面进行简单配置即可。
基于EsDataClean界面设计思想，使得非技术用户也能对定义过程、定义结果一目了然，有效解决技术人员和业务人员理解不一致而产生的数据质量风险。
兼容SQL-99标准，支持大部分SQL-2003标准。对于DDL语句，除常规的建库、建表、建视图外，还支持表分区、表缓存等特性。DML方面，提供LOAD DATA批量加载数据，能支持非常复杂的多表JOIN和UNION。支持丰富的数学、字符串、日期时间、聚集、分析函数等，还支持用户自定义函数。SQL语法基本同Hive SQL兼容，语法上同其它数据库SQL语法基本一致。
PetaBase提供多种应用程序接口，包括JDBC、ODBC、CLI、Thrift等。JDBC/ODBC为第三方应用连接到PetaBase提供了便利性。CLI(命令行界面)可以让数据库管理人员、数据仓库工程师方便、灵活的进行数据库管理、数据查询、SQL脚本调优及诊断等。Thrift接口是跨语言的访问接口，可以让Java、C++、Python、PHP开发者采用一致的接口进行编程，灵活定制访问PetaBase的数据库应用。
PetaBase除内置可视化数据迁移工具之外，还提供JDBC/ODBC接口，能支持几乎所有第三方ETL工具产品。PetaBase能友好支持Sqoop，将外部数据源的数据抽取到PetaBase直接使用。也可以将PetaBase数据导出到外部数据源。采用PetaBase作为数据仓库，还可以简化ETL环节，在PetaBase内进行数据转换，节省大量时间。
数据是存储在HDFS之中，支持多种常见的Apache Hadoop文件格式和压缩编码。
PetaBase可以加载和查询由其他Hadoop组件，如Hive、HBase、Pig等生成的数据文件。
EsPowerMeta采用JAVA、J2EE模式构建，基于Web瘦客户端架构。 广泛采用AJAX技术，为用户提供了十分友好的交互式WEB操作界面。服务器应用部署完毕，在客户端无须安装任何插件，就能直接访问。
EsPowerMeta提供了类互联网方式的元数据检索功能，采用的是多级筛选，逐级过滤，由模糊到精确的过程。除了根据简单的名称、标题等方式的模糊匹配外，根据元数据本身的特征，定义了一批可供筛选的条件，让元数据的检索像上购物网站购物一样，非常的方便、快捷，满足用户对元数据各种查询场景的要求。
EsPowerMeta提供了多种粒度的可视化分析功能，来辅助用户已不同的视角来了解和使用元数据，如：
血缘分析，提供完整的数据从产生到加工最后到应用的完整数据流向关系，帮助用户了解数据的来龙去脉和加工逻辑关系；
影响分析，提供元数据之间影响范围展现，辅助IT人员了解企业范围系统变化所照成的影响。
EsPowerMeta提供了完善的元模型和元数据维护功能，支持元数据的自动获取和时间调度管理，支持元数据的手工创建，变更，并配合上版本管理，能完整的存储元数据的整个生命周期动态和变化，通过版本比较了解元数据各个版本之间的差异性所在。
EsPowerMeta是目前国内元数据管理产品中支持全中文内核的为数不多的产品，同时适用于企业业务用户、企业技术用户和运维管理用户。
i@Report支持通过不同的操作系统、浏览器对平台访问和交互。用户不需要安装插件，就可以通过IE、Chrome、FireFox、Safari等浏览器，完成填报、审核、审批及打印等日常工作，极大的减少了对普通用户的技术能力的要求，保障工作的顺利进行。
i@Report报表平台面向终端业务用户是产品的一大特色，通过随处可见的可视化定义向导和类似MS Office的操作界面使得用户容易上手使用，无需编程，业务用户即可自行完成，大大减少各级用户学习压力，方便推广应用。
i@Report报表软件采用基于单元格的报表模型，类似EXCEL的单元格设计思想和操作风格，与行列式的报表模型相比，对于复杂表样的实现能力更有优势，各种复杂的报表格式都能直接反映到计算机屏幕上。
系统一旦投入使用，能否便捷地维护和调整报表指标是极其重要的。如果每次调整都需要专业人员来完成一系列复杂的操作，那显然会大大降低软件的易操作性，甚至还可能导致新旧报表数据的混乱 i@Report智能化的对报表数据库进行创建和维护，大大的减少对各级的技术支持工作量，终端用户无需关心数据在数据库中的存储结构，真正实现了数据库维护的零管理。系统支持报表发布自动创建数据库表，支持报表升级后数据库表自动升级，支持新旧报表指标智能对应，数据自动升级，所有升级都在服务器端完成，无需终端用户干预。
i@Report通过可视化图表技术，为用户提供直观的上报审核情况统计功能，支持用户自由选择查询统计条件，也支持从宏观到微观层层钻取查看，帮助用户快速及时地了解分支机构的最新工作进展，以便做出合理的调整和安排。
对于未及时上报或审核未通过的用户，系统提供了多种催报方法：发送站内信息催报，催报信息将发送到站内信箱；发送短信催报（需短信网关支持），催报短信发送至填报人的手机；发送邮件催报，催报信息发送至填报人的邮箱。
对于下级填报单位上报的数据，上级汇总单位可将其进行汇总。i@Report提供一键汇总的功能，支持层层汇总、直接下级汇总、选择单位汇总、按条件汇总、按代码组汇总、按关键字汇总、自定义汇总等。
可集中统一管理多种应用，可快速集成各种已建成的异构企业业务系统，快速的实现企业业务移动化。
移动平台提供联系人功能，可以给联系人打电话和发站内信和邮件，让用户在移动工作的同时随时与同事保持密切的沟通。
按照用户的使用习惯，我们提供了多种手势操作，比如：
在屏幕上用左右滑动切换到上一张/下一张报表：进入到门户选择某张报表查看完毕后，如果想接着看下一张报，不需要返回到门户的报表选择页面，直接在本张报表上用食指从右至左的滑动即可切换到下一张报表。查看上一张报表也可以使用从左至右的滑动来实现。
滑动返回当前页面的上一级：用户登录到平台后，使用某一个功能时，用左手大姆指从左至右的滑动即可返回到上一级。
下拉自动刷新分析报表：在查看分析报表界面，使用手势向下拖动报有时，自动刷新分析报表。
手势缩放：当想更清晰地查看报表时，放将报表放大，移动BI支持手势放大缩小的功能，即用右手姆指与食指同时向外拉时，报表放大显示，返之缩小。
表元是报表元素中的最小单元，在excel中也称作单元格。
表元分为：固定表元(title)和变量表元，其中变量表元又可以细分为多种类型，包括：数值型表元，逻辑型表元，字符型表元，日期型表元，OLE文档型表元，图像表元以及附件表元。不同的表元类型具有的属性各不相同。
本文，我们以字符型表元为例，介绍一下变量表元的共同属性以及字符型表元的特殊属性。
1.变量表元共同属性
1.1 字段名
通过表元所在列和行的标题交叉得到，如C3、H2等。它也是表元在数据库中存储所用的字段名。可手动设置和更改。
1.2填报说明
对表元指标数据如何填报的说明性文字。用户填报数据时，可以显示提示信息。
1.3 数据类型
标志当前选中表元允许填报的数据类型，包括字符串、整数、浮点数、逻辑型、日期型、备注型、OLE文档。
1.4 默认值
用户填报数据时，系统默认自动给出的表元值。默认值可以设置为常量或公式，由系统计算得出，但用户可以修改。如要设置填表时间为当天日期，要设置默认值为："today()"。
1.5 前后缀
“前缀”和“后缀”是指显示表元内容时所加的前缀和后缀。例如：对于填写内容为人民币数量的表元，可以加上前缀“￥”：若表元的填报值为：13235.8，显示时则为：￥13235.8。
1.6 可编辑条件
当满足某个条件时，表元才可以被编辑
1.7 显示条件
当满足某个条件时，表元才会显示，否则，系统会将该表元隐藏。
2.字符串表元属性
字符串型表元是一种常见的填报数据类型。在i@Repot 中，字符串类型具有以下2个特性：
· 填报内容的长度不能超过255；
· 系统支持两种方式来规范表元的输入内容，可任选其一。
我们一起来看一下规范输入内容的2种方式。
2.1 使用代码组输入
即在报表任务中事先定义好的代码来输入表元内容。而使用代码输入的表元也称之为代码表元。
设置步骤：设置表元属性中的“使用代码”为“是”，则点击+ ，相关属性被激活，设置如下图：
设置后效果如下图：
2.2 枚举列表输入
指通过选择事先编辑好的选项来输入表元内容。用户填报时只需要在候选项中进行选择即可完成表元内容的输入。
设置步骤：设置表元属性中的“枚举列表输入”为“是”，则点击+ ，相关属性被激活，设置如下图：
设置效果：
亿信华辰元数据管理平台提供了丰富的元数据分析功能，包括血缘分析、影响分析、全链分析、关联度分析、属性值差异分析等，分析出元数据的来龙去脉，快速识别元数据的价值，掌握元数据变更可能造成的影响，以便更有效的评估变化带来的风险，从而帮助用户高效准确的对数据资产进行清理、维护与使用。
od函数是提供日期操作功能的函数，包括对年，半年，季度，月，旬，日的操作。
od函数返回的是字符串类型。
2. 函数格式：
函数形式为：
(1) od（源时间数据字符串，操作符） eg： od("2006","y=2005")
年 ：操作符为'y' ，标准格式为xxxx（四位），eg：2006 表示2006年
半年：操作符为'hy'，标准格式为x （一位），eg： 20061 表示2006年上半年
季度：操作符为'q'，标准格式为x（一位），eg：20061 表示2006年第1季度
月 ：操作符为'm' ，标准格式为xx（两位），eg：200601 表示2006年1月
旬 ：操作符为't'，标准格式为x（一位），eg：2006011 表示2006年1月上旬
日 ：操作符为'd'，标准格式为xx（两位） ，eg：20060101 表示2006年1月1日
返回结果为 年年年年月月日日 形式的字符串。
(2) od（源时间数据日期型，操作符） eg： od(#20060101#,'y=2005')
年：操作符为'y' ，标准格式为#xxxx-xx-xx#，eg：#2006-01-01# 表示2006年1月1日
月：操作符为'm'，标准格式为#xxxx-xx-xx#，eg：#2006-01-01# 表示2006年1月1日
日：操作符为'd'， 标准格式为#xxxx-xx-xx#，eg：#2006-01-01# 表示2006年1月1日
返回结果为 年年年年-月月-日日 形式的字符串。
以上都支持多操作符的运算，用'；'隔开即可
(3) 注意
对于不支持的操作符，将忽略不计。
如：#2006-01-01#会忽略hy=2；od(#2006-01-01#,"hy=2")返回的将是2006-01-01。
3.具体示例
|
操作类型 |
输入 |
输出 |
输入 |
输出 |
|
年 |
od("2006","y=2005") |
2005 |
od(#2006-01-01#,"y=2005") |
2005-01-01 |
|
od("200607","y+1") |
200707 |
od(#2006-01-01#,"y+1") |
2007-01-01 |
|
|
od("20060701","y-1") |
20050701 |
od(#2006-01-01#,"y-1") |
2005-01-01 |
|
|
半年 |
od("20061","hy=2") |
20062 |
|
|
|
od("20061","hy+2") |
20071 |
|
|
|
|
od("20061","hy-1") |
20052 |
|
|
|
|
季度 |
od("20061","q=2") |
20062 |
|
|
|
od("20061","q+5") |
20072 |
|
|
|
|
od("20061","q-3) |
20052 |
|
|
|
|
月 |
od("200601","m=5") |
200605 |
od(#2006-01-01#,"m=5") |
2006-05-01 |
|
od("20050131","m+1") |
20050228 |
od(#2006-01-01#,"m+1") |
2006-02-01 |
|
|
od("20070331","m-1") |
20070228 |
od(#2006-01-01#,"m-1") |
2005-12-01 |
|
|
旬 |
od("2006011","t=2") |
2006012 |
|
|
|
od("2006011","t+3") |
2006021 |
|
|
|
|
od("2006011","t-3") |
2005121 |
|
|
|
|
日 |
od("20060101","d=2") |
20060102 |
od(#2006-01-01#,"d=2") |
2006-01-02 |
|
od("20060131","d+1") |
20060201 |
od(#2006-01-31#,"d+1") |
2006-02-01 |
|
|
od("20060201","d-1") |
20060131 |
od(#2006-01-01#,"d-1") |
2005-12-31 |
|
|
od("20020201","d=lastday") |
20020228 |
od(#2006-02-01#,"d=lastday") |
2006-02-28 |
|
|
多操作符 |
od("20020201","m=1;d=lastday") |
20020131 |
od(#2006-01-01#,"m=2;d=lastday") |
2006-02-28 |
| 属性 | 说明 |
| 标题 | 可以在任务编辑界面属性中修改 |
| 类型 | 任务的填报类型（例如：年半、半年报、月报等） |
| 查看报表链接 | 直接查看报表的链接，参数说明：#id，#pw需要替换成登录用户的信息。 bbq参数如果不指定，默认显示任务的最佳报表期 |
| 任务类型 | 1、填报任务（用于给用户进行填报）2、展示任务（数据的展现）一般默认为填报任务 |
| 显示顺序 | 当前任务的显示顺序，以阿拉伯数字（0~9）和26个英文字母（a~z,A~Z）来设定。 |
| 信息表元 | 设定当前任务在查看上报情况时显示的信息表元。例如：C1,C2,C3 |
| 描述 | 当前任务的简要描述信息，在任务列表的界面上可以看到。 |
| 最佳报表期 | 设定当前任务的最佳报表期，需要指定计算公式。 |
| 最佳报表期脚本 | 设定当前任务的最佳报表期选择项。以脚本的形式生成最佳报表期选择项，点击帮助获得更多详细说明 |
| 显示条件 | 设定当前任务的显示和隐藏，需要指定计算公式。例如：logininf(0)="000000"表示当前登录的代码为000000时，任务可见。 |
| 此处仅支持变量@id和@btype,表示报表户id和报表户类型。 | |
| 报表户称谓脚本 | 设定当前任务的报表户里基层和汇总户的称谓。以脚本的形式生成报表户称谓，点击帮助获得更多详细说明。 |
| 报表期显示脚本 | 设定当前任务的报表期选择项。以脚本的形式生成报表期选择项，点击帮助获得更多详细说明。 |
| 上报数据后执行的脚本 | 设定任务上报后执行的操作，点击帮助获得更多详细说明。 |
| 审批通过后执行的脚本 | 设定数据审批后执行的操作，点击帮助获得更多详细说明。 |
| 报表户过滤条件 | 列举报表户列表的时候,查询报表户的Sql过滤条件。比如仅显示用户ID前二位为13的报表户，在oracle数据库环境中应为:SUBSTR(USERID,0,2)='13'; |
| 汇总户页面报表查看方式 | 1、嵌入式查看（在页面内部查看数据）2、弹出新窗口查看（弹出新的窗口进行数据查看） |
| 汇总户页面默认显示 | 1、列表（汇总户进入后下属填报单位显示为列表方式）2、树形（汇总户进入后下属填报单位显示为列表方式） |
| 汇总户页面树形显示格式 | 可以设置汇总户界面树型显示的格式，默认格式为四种：名称，代码，代码（名称），名称（代码） |
| 树形显示下级数量时 | 树型显示时，会在汇总户的名称后面显示下级的数量，如果不勾选包含汇总户，默认只统计全部下级基层户的数量 |
| 汇总户页面缓存数据最大页面 | 汇总户打开插件浏览数据时，如果设置了缓存数据下载该页所有户的数据，并缓存在本地，这样可以大大提高，在当前页切换数据的速度。 设置缓存最大页数时，不宜设置过大，建议设置在5-10页，设置过大，当用户机内存较少时，会影响用户的使用效果。设置为0表示不缓存 |
| 新增报表户来源 | 汇总户录入下级时，报表户ID和名称的数据来源。该数据源可以是数据库表的两个字段,也可以是数据库代码组。 |
| 报表户树形结构管理 | 定义树形节点依据以后,根汇总户可以以多种树形查看下级已报户的数据. |
| 设置成为非活动任务 | 任务处于非活动状态，所有填报户不可见 |
| 允许有下级未上报汇总户上报 | 如果没有进行勾选，如果汇总户下包含没有上报的基层户，则汇总户无法上报 |
| 上报后锁定 | 数据审核上报后，数据处于锁定状态，本单位无法编辑任务 |
| 允许产生差额表 | 该项在报表设置有舍位平衡时被激活 |
| 数据上报查看选项 | 汇总户登录后，默认显示的下级单位状态（已报、未报、填报中、等待审批、全部） |
| 批量取数缓存大小 | 用于计算、审核等跟批量计算有关的场合 |
| 报表自动继承上级审批流程 | 在有审批流程的情况下勾选，下级继承上级审批流程 |
在多系列的统计图中，系列之间的数据差距太大，导致数据显示不够直接，则需要通过设置多轴让统计图的数据显示的直接和美观。
以下面的实例给大家讲解多轴统计图的设置。
新建一个报表模板，样表设置如下：
计算预览效果：
双击统计图，点击左下角的高级选项，选择坐标轴，然后做坐标轴模板有4种形式。第一：左轴+底轴；第二：左右轴+底轴；第三：上下轴+底轴（纵轴标签在同一边）；第四：上下轴+底轴（纵轴标签在相反边）。
在此选择左右轴+底轴的形式。
将系列对应轴的标签颜色设置为系列的颜色（默认第一系列对应左轴，第二系列对应右轴）
具体设置步骤如下：
一张图，读懂BI系统结构
通过上图中，我们可清晰的了解到BI部署在中间件上，依托JDBC连接数据库，用户通过互联网访问平台资源，所以我们可以简单理解，可能会影响到BI服务器性能的因素有：
· 中间件
· 数据库
· 网络资源
他们分别对BI服务器有怎样的影响，应该如何设置，服务器性能会更优呢？我们一起来分解下。
中间件种类繁多，以TOMCAT为例。
TOMCAT默认内存最大内存为128M，在大用户量情况下容易出现内存不够的情况，所以需要进行调整。
修改内存大小一般在启动文件startup.bat或startup.sh中设置，设置例子如下：
Set JAVA_OPTS= -Xmx1024m -Xms256m -XX:MaxPermSize=256m（Windows）
JAVA_OPTS=-Xmx1024m -Xms256m -XX:MaxPermSize=256m（Linux）
内存调整需根据服务器内存大小、操作系统版本、WEB服务器版本、JDK版本和实际使用情况进行调整，一般建议在32bit环境下最大内存不要超过2G，在64bit环境下不要超过4G，且如果启动tomcat失败可以逐渐调下内存。
注意：某些JDK版本限制最大堆内存，不支持分配超过1.5G的内存，如果有充足的内存，可以多建立几个节点集群成员，逐一对每个成员做相应的修改。
BI分析表，会根据用户选择的计算条件转译成为SQL，并返回数据库中进行查询，最终将查询的结果重新构表，并返回到BI门户中。所以数据库的计算性能直接影响到查询的效率，再前端的感受，就是分析表计算时长。
影响的因素包括，但不限于：
· 内部参数；
· 最大连接数；
· 磁盘空间和转数；
· 表空间大小和使用情况；
因每个数据库参数设置各有不同，在此不一一列举具体配置方法。
网络的影响分为内部和外部。
内部主要是，中间件和数据库服务器交互的速度。通俗的讲，BI部署在中间件中，依托网络连接数据库，进行数据交互，中间件服务与数据库服务器交互的速度也会影响到BI服务器访问的速度；
同理，用户通过客户端访问BI服务器，也是依托网络环境，网络速度低，会直接影响到服务器的访问效果。通常我们建议客户端的网络传输速度不低于100KB/s；
(1) 线程数设置，当计算报表的时候提示正在计算，有多少用户在排队时
建议： CPU个数*4
(2) 数据库连接数，当数据库连接池已满或者连接超时
建议：修改JDBC中的maxactive值，设置为100
BI自带系统诊断功能，当系统设置在超出预警，系统会予以警示。
|
诊断项 |
检测内容（中文） |
|
时区设置 |
必须是Asia/Shanghai，否则提示错误 |
|
file.encoding设置 |
必须是"UTF-8","UTF8","GB18030","GBK",否则提示错误 |
|
sun.jnu.encoding设置 |
同上 |
|
操作系统字符集 |
检查文件名或文件内容是否支持GBK编码，不支持提示错误 |
|
java.awt.headless设置 |
windows不检查，linux检查或未设置提示错误 |
|
最大内存设置 |
32位要求大于1024M，64位要求大于2048M |
|
可用内存 |
<%5 系统已几乎无可用内存 |
|
可用字体 |
必须有宋体字体，否则不能通过 |
|
连接池参数检查 |
mysql连接池未找到characterEncoding，提示 |
|
连接池数据库驱动检查 |
DB2驱动低于9.5，提示 |
|
检查超级管理员密码 |
通过注释不能和用户名相同，设置的"123456"等； |
|
日志检查 |
超过10w行提示 |
|
线程池状态 |
等待线程>30，提示 |
|
注册码检查 |
>0 & <30，提示 |
|
工作目录检查 |
>2g，提示 |
|
默认备份计划任务 |
不存在，提示 |
很久很久以前，当BI还没有引入容器的概念，想要达到多表体报表的效果，是将表格线画成透明色来实现的，这种实现方法排版困难，绘制透明的表格线也很麻烦。
从bi4.1开始，我们可以对以前的老方法说拜拜了，因为bi4.1的容器，可以帮你实现任何布局的报表。
所谓多表体，就是一张报表上有多个分析表体，可以实现样式多元化，更加美观的报表。从功能上来说，借助容器组件将表体划分成多个区块，每个区块都是一个独立的分析表体，同时，多个表体之间是可以进行表间运算的。
容器，是BI报表设计的一种组件，这种组件可以将表体划分成多个独立的区块。
容器根据不同的布局，分为单容器、田字型容器、工字型容器、左右型容器、上下型容器；不同的容器是可以相互嵌套的，如此便可能实现任结构的多表体报表了，例如，先在表体中拖入一个上下型容器，在该容器的下半个容器中，再拖入一个左右型容器，结果就是一个类似于"T"字形的容器了。
实现以下布局的报表，保证四块内容的比例协调。
根据需求的描述，我们需要的是"田字型容器"组件，只需要将基础组件中的田字型容器拖入表体即可：
（接下来的操作步骤，就跟一般的报表设计一样，所以有些步骤会精简精简再精简）
田字型容器将表体分为四块区域，根据需求，分别在左侧的两块区域中拖入分析区表格和文本组件，分析区表格组件用来表体定义，文本组件用来定义标题文字
为报表添加统计图的方式也非常简单，之需要在组件区，将需要的统计图组件拖入表体相应位置即可。
统计图组件添加完成之后，就可以双击统计图，打开统计图的设置窗口，为统计图设置数据源、配色等。
计算得到预览的结果，从下面结果可以看到，表格与统计图之间的布局，是"田字型"的布局方式，一般不需要在排版上花费太多的时间和精力，就能出来比较协调的结果
要点1：立体感十足的标题
· 背景图片：在搜索栏搜索bg.gif，应用。如果有自己制作好的其他的更好看的背景，也可以上传进行应用哦；
· 大小自适应：设置为水平撑满，保证在表格的容器区域是被填满的；
· 平铺方式：设置为平铺；
要点2：容器最小宽度设置
本表需求的实现中，表格内容比较少，所占的宽度相对较少，系统默认给出的最小宽度是50%对该表来说并不合适，需要调整。根据实际的需要，将田字型的左侧区域调整最小宽度为33%
在一些项目或需求场景中，除了需要控制常规的资源权限（如分析表、主题表等查看权限），还需要控制每个用户对分析表的数据查看权限（即数据范围）。
例如粮食产量分析表中，石家庄和唐山用户都可以查看该表，但要求各用户只能查看本市的数据。
BI@Report对此类需求提供了此功能模块。数据权限控制与资源权限一样，可以对机构、用户、角色均可授予，以下以对用户授权为例。
由于数据权限是通过维度配置的，所以需要事先将需要数据权限控制的主题表与维度映射，如下图
（1）管理员登录点击菜单栏上的用户权限->机构用户，选择待授权的用户，并授予所需资源权限，如下图
（2）选中（不是勾选）待授数据权限的资源（可以分析表、分析表分组、主题集、主题域），右侧点击数据级次，打开编辑维过滤，如下图
（3）选择所需数据权限控制的维表，如下图
（4）勾选授权对应的数据权限（可以多选），并保存，如下图
（5）sjz用户登录验证数据，如下图
注：第（3）步中可以选择多个维表授权数据权限（多个维表数据权限之间是与的关系），如下图
数据权限在很多场景下都是和用户的某个属性有逻辑关系，如所属机构或单独的一个属性匹配。这种前提下可以通过变量的方式让用户的属性自动与数据权限匹配
数据模拟准备
扩展一个用户属性SJQX，如下图
设置SJQX（数据权限）属性字段值（还是刚才sjz用户为例，值为130100），如下图
具体配置如下：
（1）选中之前已设置数据权限的sjz用户，点击高级，找到参数非空的记录条，点击修改，如下图
（2）将参数表达式中的固定值改为从属性变量取值，,确认并保存权限，如下图
ps：login.USER_SJQX表示去登录用户的SJQX属性值；如果取登录用户的所属机构id，则为login.USER_ORGID
（3）sjz用户登录验证数据，如下图
I作为辅系统与第三方系统集成时，除了配置单点登录之外，将的用户库同步也是实现单点登录的必要工作。
由于I的单点登录只支持服务器用户，所以需要分别同步I的机构表和服务器用户表，并分配权限。对于服务器用户来说，若不给其分配权限，本身是没有任何权限的，所以需要对服务器用户分配数据填报的权限。若要给服务器用户分配数据填报的权限，则每个服务器用户都要对应到具体的报表户身上，因此，我们也要对I的报表户列表进行同步。
需要注意的是，存放主系统用户库的数据库用户必须与I所连接的用户库相同，同时该用户应该有查看和管理主系统用户库数据的权限（可通过授权或者同义词等方式分配），以便完成用户库同步的操作。
完成用户库的同步需要以下三个步骤：
数据库中存放I的机构信息的数据库表是IRPT_DEPARTMENTS，表结构如下图所示：
上表中，除了ID、CAPTION、PARENT、ISJC、ENABLED这几个字段是必须的以外，还需要有UPID0······UPID9这几个字段，所以需要在数据库中将用户库表中这几个字段中的数据抽取到IRPT_DEPARTMENTS这张表中。
此处需要注意的是，主系统的用户库中可能没有ISJC、ENABLED 以及UPID0······UPID9这几个字段，需要手动添加。其中，ISJC表示是否为基层机构，‘9’表示汇总单位，‘0’表示基层单位；ENABLED表示是否可用，‘1’表示可用，‘0’表示不可用；UPID0······UPID9是上级代码的冗余字段，UPIDI表示该机构在机构树形结构的第I级上级代码，例如，UPID0表示该机构在机构树形结构的顶级代码；UPID1表示该机构在机构树形结构的第1级上级代码········
数据库中存放I的服务器用户信息的数据库表是IRPT_USERS，表结构如下图所示：
上表中，前五个字段是必须的，需要在数据库中将用户库表中这几个字段的数据抽取到IRPT_USERS这张表中。此处需要注意的是，机构代码的字段名是DEPARMENT而不是DEPARTMENT，没有中间的T。
通过服务器用户的表结构可以看到，服务器用户本身并没有任何层级关系，需要通过所在的机构来划分服务器用户之间的层级关系，以实现服务器用户与报表户的一一对应。
数据库中存放I的报表户信息的数据库表是UL_任务组名首字母缩写，表结构如下图所示：
上表中，前五个字段和第11-20个字段是必须的。其中，btype表示报表户的类型，‘0’表示基层户，‘9’表示汇总户；upid0······upid9同机构代码。有两种方式可实现报表户列表的同步，分别是数据抽取的方式和建立视图的方式。
这里的数据抽取，同机构表和服务器用户表的数据同步过程一样，都是将主系统用户库表中的必须字段的数据抽取到存放报表户信息的数据库表中。
在i中，有自定义报表户列表的功能，报表户可来自于其它表或者视图。因此，可以在数据库中根据主系统的用户库表创建一个与报表户列表结构相同的视图，在i中直接引用这个视图，具体实现步骤如下：
首先，点击任务组的属性进入任务组属性界面，如下图所示：
然后，点击自定义报表户列表，进入自定义报表户列表界面：
在空白处找到刚才建的视图，然后点击自动匹配，就可以完成报表户的同步同样的，btype和upid可能在主系统的用户库中没有，需要手动添加。
首先，确定每一个报表户的权限；然后，通过定义角色实现服务器用户数据填报权限的批量分配。需要说明的是，由于顶级汇总户所属的机构为顶级机构，顶级机构的上级机构代码均为空，而其他服务器用户所属的机构均有上级机构代码，所以需要创建两个角色，分别进行匹配，具体操作步骤如下：
（1）为顶级汇总户创建一个角色，并设置相应的匹配公式，使得满足条件的服务器用户被自动授予该角色的权限，匹配公式如下图所示：
上图中的顶级机构代码即为顶级机构的机构号，如下图所示：
（2）为该角色分配相应任务的数据填报权限。首先，找到并选中需要填报的任务组；然后，点开“数据填报”窗口，选择“ ”定义匹配公式批量匹配报表户；最后，选中已经定义好的匹配公式，右侧会将该任务组下的所有任务列出来，选择“读写”这一列，即可完成该角色数据填报权限的分配，具体如下图所示：
（1）除了顶级汇总户之外的用户可以共用一个角色，首先，创建一个角色，并设置相应的匹配公式，使得满足条件的服务器用户被自动授予该角色的权限，匹配公式如下图所示：
上图中的顶级机构代码即为顶级机构的机构号。
（2）为该角色分配相应任务的数据填报权限，该操作步骤与顶级汇总户角色权限分配的步骤完全一致，此处不再赘述。
通过以上两个步骤就可以完成服务器用户数据填报权限的分配，使得服务器用户与报表户权限一一对应。
在i中，每次新增服务器用户，需要在角色管理中手动点击保存才能实现角色与用户的自动匹配，研发提供了Webservice接口，更新war包之后，通过Webservice地址：services/RoleMatchService?wsdl获取web服务，调用RoleMatchService接口的方式实现新增用户与角色的自动匹配，接口说明：
public interface RoleMatchService {
/**
* 对指定用户ID进行角色自动匹配计算。
* @param userId 要同步的用户id
* @param sync 是否同步, true 等待该方法执行完成返回，false 则新开一个线程独立运行匹配操作，调用处立即返回。
*/
public void matchUser(String userId, boolean sync);
/**
* 对系统中所有用户进行角色匹配计算
* @param sync 是否同步，同上
*/
public void matchAll(boolean sync);
}
门户是用户快速访问报表资源的主要通道。在BI@Report中，用户在使用门户时，除了需要查看报表资源外，同时也不可避免的需要添加一些方便使用的按钮来辅助报表的查看，比如：计算按钮，注销按钮，比如欢迎信息，比如文字提示。
那么如何为门户配置方便实用的按钮呢？让我们一探究竟。
这里我们以以下2个需求为例说明：
1. BI41中的门户模板普遍自带“注销”按钮，那么，如何添加一个“计算”按钮？
2. 如何在门户头部添加滚动字幕？
实现效果如下：
添加组件“链接”至目标位置，用于实现计算的功能；
修改显示文字，设置链接的“事件”，实现计算的功能；
系统默认提供常用的“脚本列表”供用户选择，同时支持用户通过编写脚本实现其他个性化的功能。
双击组件，可修改文字的样式，在右侧组件属性栏中可修改边框及背景等属性；
选择链接文字，在右键菜单中设置“计算按钮”的显示位置；
在BI41中，基础组件的位置通过“组件定位方式”来实现，设置组件定位方式之后，系统将根据组件在设计界面上的位置进行绝对定位，从而自动适应界面的大小。
在本案例中，我们需要实现的效果是，“计算”按钮在“注销”按钮的左侧，定位方式则为：水平右定位
通过CTRL+左键选中多个组件，右键菜单，则可以设置“对齐方式”；这里，我们选择“竖直中对齐”：
1. 将高级组件“滚动文本”拖至门户对应位置，双击组件，添加需要显示的滚动文字；滚动文本中支持添加多条文本，且可以对文本进行修改和删除；
2. 点击“滚动文本”，在右侧属性中设置：文本样式，边框样式，滚动方式（横向，纵向），滚动速度等多种属性。
3. 调整“滚动文本”的宽度和高度，并拖拽到“计算”按钮左侧，点击右键菜单，设置“定位方式”为“水平右定位”；
至此，就实现了滚动文本的功能设置！
1.知识储备
维是观察事物的角度，根据维的数据结构，将维分成三种类型：单级维，多级维和通用维。
维表可以分为主体域维表和主体集维表。主题域维表作用于整个主题域，在此主题域下的任何主题集都可以使用；而主体集维表，只能在此主题集下才可以使用。
下面我们就开始介绍单级维、多级维和通用维的创建方式。
（1）点击左侧维表，然后点击工作区内的添加，开始编辑维表结构。
具体编辑内容如下：
点击保存。
（2）编辑维表相应的内容，点击保存。
（3）查看最终效果
注：若维表对应的数据表已存在数据库当中，我们只需要在数据库表名那选择对应的数据库表，那么对应数据表中的字段以及数据就自动导出来，然后我们设置id和文字字段，点击保存即可。
（1）新建一张维表，编辑维表结构如下：
点击保存。
（2）编辑维表相应的内容，点击保存。
（3）查看最终效果
（1）新建一张维表，编辑维表结构如下：
点击保存。
（2）编辑维表相应的内容，点击保存。
（3）查看最终效果
随着云时代的来临，大数据也吸引了越来越多的关注。每个企业都会创造大量的结构化及非结构化数据，数据就是企业的直接财富及核心竞争力。
能否从各种各样类型的数据中，快速获得有价值信息，直接决定了企业在大数据时代能否立稳脚跟。企业竞争，将成为基于数据的竞争。那么，如何能让数据发挥应有的价值呢？亿信华辰公司在此领域做了众多的理论与实践研究。
作为长期专注于数据应用、数据仓库、商业智能、报表统计软件产品及咨询服务的提供商，亿信华辰结合多年的数据仓库建设经验，为用户提供全面的服务和解决方案，深度挖掘数据价值，为领导决策提供支持。
主要内容包括：网络化数据采集、审核、报送，提供便捷的数据收集方式；数据中心建设，对所有数据进行整合、清洗，提供适用于分析的数据；数据资产管理，制定数据标准、制度，对数据进行全面的治理和质量监控；数据全生命周期的运维服务，为数据的产生、流转、质量各个环节服务；数据应用服务，基于自主研发的商业智能产品，为用户提供全局型的数据应用服务。
经过多年的努力，亿信华辰成功为一大批重要客户提供了数据相关服务，包括多个国家部级单位、中国进出口银行、中国农业发展银行、中国船舶工业集团公司、华润、中粮等用户。目前，全国有近500个以上的服务器装机量，终端客户超过100万个，在业内处于领先地位。
对大数据的成功运用，将改变企业决策，促进企业核心竞争力的提升，带来惊人的经济和社会效益。哈佛大学定量社会学研究所主任盖瑞·金，以“一场革命”来形容大数据技术给学术、商业和政府管理带来的变化，认为“大数据技术将触及任何一个领域”。而类似亿信华辰公司这样能够深度挖掘大数据、运用大数据的推手们，必将推动中国数据管理、数据应用领域的发展和壮大。
豌豆BI的计算基于一定数据模型，用户在使用时无需关心建模细节，当用户选择数据源后，系统会在后台自动识别，并根据数据特征信息建立起数据的星型模型，然后再根据DW理论模型和OLAP技术进行数据运算，从而大大提高计算性能。自动建模技术满足了用户零建模知识就会玩数据的愿望。
豌豆BI内含智能图形引擎，图形引擎采用智能推荐算法，会根据用户选取的指标和维度进行运算，推荐出最适合数据展示的图形。比如当用户使用“地区”这样指标时会自动使用地图进行数据展现。
为了提高图形和表格数据可交互性，豌豆BI引入了数据自动关联技术，让图和表根据数据维度和数据特征信息自动关联起来。当图上的数据因为用户点击变化时，会自动分析出与图形相关的信息，然后再触发其他图形重新计算并展示，让用户随心所欲的感知数据的变化。
数据模型是数据分析的基础，但业务人员往往无法理解数据仓库、数据模型、维度、指标、关联关系等模型的设计。
豌豆BI让业务人员无需关心数据模型，系统自动识别指标维度和关联关系，形成数据模型，这个过程对于业务用户来说是完全透明、感知不到的；对于拥有一定技术的人员，也可以在系统中自行建立和修改模型。
雾霾笼罩我国近半国土，据统计104座城市重度“沦陷”。哪些城市“沦陷”了呢？有小编正在生活着的武汉吗？小编即将启程前往的厦门是否也被“沦陷”？
莫急，小编这里有一张“空气质量”主题表，将基于这张主题表用豌豆BI一探究竟。
在敏捷看板编辑界面，拖入“地区”和“AQI”到工作区，自动用地图展示各省份空气质量指数。
咦？为什么会没有数据？
原来主题表中是各城市的数据，没有省份数据，渲染地图展示不了，没关系，so easy！ 豌豆BI自有妙招，请看下文。
首先，在智能面板中将图形切换成标点地图：
自带的配色很是清新啊，看来我们的UI工程师吐了不少血~~
清新归清新，但小编想重灾区醒目显示，那种刺痛双眼的醒目。
简单！加个预警，AQI大于200的大红色显示。
别怪小编恶俗，配色我不擅长~~
什么？你还要AQI大于300的紫色显示？秒秒钟搞定！
那个紫色的气泡最大的地方就是雾霾最严重的地方。
好是好，可是别人看不懂小编做的图，不知道各颜色代表什么含义，咋办？
好办！加个预警区。
预警区中的文字提示来自上面的预警设置，眼尖心细的小伙伴们你们应该已经发现了吧？
小编将文字改成更易懂些：
还希望点击地图中区域在右边直观显示该地区的AQI、PM2.5以及天气情况等？
再露一手。将“地区”“AQI”“PM2.5”“天气”等字段拖入到工作区最右侧，生成第二个图表。
点击地图上武汉区域气泡，会自动联动刷新右边的表格，只显示武汉的数据。看来一连几天的雨水帮我们带来了好空气。
放心了，厦门天气也棒棒的，非常适合出行。
光小编说适合出行可不行，得找到官方依据。会不会太小题大做 ？
小编这里还有张“生活指南”主题表。从这里面能取到各生活指南级别对应的口罩指数、出行指数等（“空气质量”表中有生活指南级别）。
如何在上面的做好的看板中增加口罩指数、出行指数呢？
首先得先把这个主题表增加到这个看板中。
然后，然后，......，没有了 ，后续操作你们懂的~~
不懂？！欢迎私下Q我。
对于我们豌豆BI ，操作就是点点点、拖拖拖；能自动做的不让你手动做。总之就是方便、快速、简单。
对于雾霾这事，虽然武汉、厦门这几天空气质量良好，但我们生活在北方的广大兄弟姐妹还在水深火热中，也为了能一直有好空气，希望大家能坚持绿色出行，坐公交、挤地铁、少开车；遇到污染企业，电话举报。
亿信豌豆BI是一款企业级敏捷BI工具，让用户更快的获取数据全貌。WonderBI可以让用户一键探索数据，系统自动匹配最合适的图形展示数据库表数据，帮助用户初步了解数据规律，也可以在数字画像的基础上进行二次分析。
亿信数据质量管理平台（EsDataClean）提供从标准定义、质量监控、绩效评估、质量分析、质量报告、重大问题及时告警、流程整改发起、系统管理等数据质量管理全过程的功能。
即席分析方便用户进行猜想式、求证式的数据探索。只需简单的鼠标拖拽维度和指标，即可即时生成相应的分析结果，并提供多种数据处理方式，如指标间运算、预警、排序、统计图、数理统计等。
EsDataClean提供从标准定义、质量监控、绩效评估、质量分析、质量报告、系统管理全过程数据质量管理功能。
EsDataClean支持用户定义质量绩效评分依据和权重，可按照机构、字段、表、规则类别、关键字等不同粒度生成质量评分结果
EsDataClean提供了完备的服务器管理功能，管理员可通过浏览器完成系统日常管理及维护，包括机构用户管理、权限管理、日志管理、备份与恢复、集群管理、数据库管理、安全管理等。
PetaBase定位于管理大规模结构化数据(从TB到PB级)，是分布式的分析型数据库系统，适用于批量写操作，大规模随机查询的数据集市、数据仓库等。PetaBase是我公司大数据BI解决方案的组成部分。
相比开源软件，PetaBase具有集成化优势，内置Hadoop基础组件、支持多种策略的负载均衡、SQL语句和JDBC驱动双向优化、独有的可视化管理控制台、数据迁移工具、友好的安装脚本等，从整体上节省软件开销，降低使用和运维门槛，方便、有效的保证大数据系统的落地部署，工程化实施。
从软硬件采购到后期使用、维护成本低。
硬件只需要采用若干台普通PC Server甚至PC机即可胜任。
便捷的安装、维护和管理，节省TCO 30%以上。
PetaBase集群提供查询负载均衡功能，将查询请求分摊到不同的集群节点上执行，达到负载均衡的目的。
PetaBase集群各节点对应用是透明的，应用只需要连到一台主节点，而不用关心集群中的其它节点。
在某个集群节点失效情况下，应用仍然可以正常连接，负载均衡器会将请求转发到其它可用的节点上。
支持多种负载均衡策略，如轮询、权重、最少连接等。
ESPowerMeta提供了自定义元模型管理功能。元模型的结构遵循了UML规范，按照包类的树形层级结构管理。元模型在支持CWM（公共仓库元模型）国际标准的同时，提供了一套便捷的的自定义管理接口功能，支持根据用户管理需要，进行自定义元模型以及元模型之间关系的扩展。
ESPowerMeta提供了二次开发接口，可以根据需求方便地对系统灵活的定制修改和功能扩展，如API接口、URL接口、Web Service接口等第三方接口调用。
对于繁忙的生产系统而言，实时的热机部署和更新报表是非常必要的。i@Report报表平台的任务部署与发布无需开发人员介入，完全可以由业务人员在向导指引下进行。
i@Report提倡服务器自动维护概念，i@Report定期巡检数据库表结构、数据、属性配置等异常情况，对于可自动修复的问题系统将自动完成修复，以保证不影响用户的正常使用，对于需要人工确认检查的问题，提供服务器状态告警功能。
i@Report提供周全的数据库留痕技术，支持跟踪及查询单元格数据的修订变动情况，为管理者进行数据精细化管理和追溯提供重要保障。
针对大用户量的并发访问，i@Report进行了高度优化，在服务器端采用多线程技术同时处理数据，加快数据报送，同时根据服务器性能控制并发数量。
i@Report支持集群部署，可以构建多个i@Report服务器的集群环境，支持更多用户的并发使用。
i@Report提供100多种系统函数，通过函数能快速完成公式的定义，支持不同任务不同数据期之间的计算，还支持取去年同期、上期值，计算同比、环比、最大值、最小值、均值、标准方差等。
支持各种主流移动设备，包括手机端和PAD端，支持的操作系统包括ios7及以上，Android4.1X及以上。
支持在线和离线两种模式浏览门户，当用户网络环境好的情况下可以选择在线浏览报表，可以时实看到最新的数据。
当网络条件不允许的情况下我们可以看到缓存的历史数据。
有些任务的菜单在用户访问时需要不同于其他任务，存在一些特殊的功能，所以，系统为每个任务提供了任务菜单。
服务器管理员登录-->进入任务组-->进入任务全部报表期界面--查看–>任务【任务名称】详情：
进入任务详情界面–页面最下方可以可以看到任务对应的所有任务菜单，如下图：
根据上图可以看出，每个任务都有6个任务菜单。
任务菜单文件列表：
系统中可以存在新旧两种风格不一样的代码组。
【旧风格代码组】：
有固定的结构，比如1-2-1-1等，表示代码由五位数字固定构成，代码组中的代码根据结构存在上下级关系，且代码中的文字串不能为空。代码在代码组中的排列顺序是依据上下级关系根据代码的ASCII码顺序来排列。旧风格的代码可以有三种显示方式：分段显示、文本显示、树型显示。相应的变长表中的数据是根据代码在代码组的顺序来排列。
【新风格代码组】：
没有固定的结构，代码的上下级关系与代码取值无关，即111可以是100的上级；代码在代码组中的排序可以不按ASCII码顺序来排列。新风格的代码可以有两种显示方式：文本显示、树型显示。
某行政主管部门要对其管辖的企业做基本信息调查，调查的内容如下：
对以上调查的信息中，除了企业名称可以准确填写的，那么对于下面那么多基本信息的填写，相信很多企业都是无从下笔的，就算企业大概知道这些信息如何填写，也不能确保一字不差的填写准确。在这种情况下，就是代码组发挥作用的时候了。
以工商登记注册类型（旧风格方式）和出口退税方式（新风格实现）两个代码组为例进行实现过程的介绍
【工商登记注册类型代码表】（网上可以查到）：
【出口退税方式】：实行免抵退税办法的生产企业；实行免退办法的商贸企业；实行免税办法的小规模纳税人；
【工商登记注册类型实现过程】
工商登记注册类型是一个根据代码进行分段来实现上下级关系的，分析其代码的规则分段的规则应该是1-1-1，在明确分段规则之后，就可以来新建代码组了。
a：双击"代码组"节点，打开代码组管理窗口；
b：选择"增加/旧风格代码组"，弹出代码组创建窗口；
c：设置代码组名称和代码组结构；
步骤图解如下：
将代码组的显示方式切换到"文本显示"，把代码和对应的文字粘贴到文本中即可。
注意：代码和文本之间是TAB键，不是空格
代码组创建好之后，报表如何去应用呢？
只需要将相应的单元格，"右键/属性"，将"使用代码"选择"是"，并指定到对应的代码组名称，就能实现代码组的应用。
对于定义使用代码组的表元，就可以点击表元之后下拉框中选择内容，让填报的速度更快，而且避免了手动输入出现错误。
m的平方，写在固定表元中，要表达可以用：
输入~m^2，将自动转换为m2（m的平方的数学表达形式）
m2，下标，也称角标、脚标，写在固定表元中，要显示为下标形式，在设计系统中设置固定表元的内容为~m_2即可。
通过此登录接口可完成登录并直达指定功能界面的功能
适用版本：4.1.x-4.2.x, 具体参数对应的版本文档中有说明。
do?id=
其中serverurl是i@Report服务器的访问路径。例如：
服务器访问地址是：
http://192.168.1.199:8080/irpt/i/main.jsp
则接口地址为：
http://192.168.1.199:8080/irpt/oemlogin.do
本接口的参数如下表：
|
参数名 |
取值 |
说明 |
支持版本 |
|
id |
|
用户ＩＤ |
|
|
pwd或pw |
|
密码.采用MD5值的密文方式。(明文也行) |
|
|
target |
支持以下参数值 |
|
|
|
server |
表示登录服务器，转向"服务器管理"页面 |
|
|
|
logs |
表示登录后转向日志管理, |
|
|
|
users |
表示登录后转向服务器用户管理 |
|
|
|
msg |
表示登录后转向通知管理 |
|
|
|
taskgroups |
表示登录后转向任务组管理 |
|
|
|
taskgroup |
表示登录grp参数指定的任务组 |
|
|
|
task |
表示登录task参数指定的任务 |
|
|
|
rpts |
表示登录task参数指定的任务，并直接打开bbq参指定的报表期数据．要想打开数据不允许修改，传递readolny=true；打开指定的报表，传递参数rpts，例 如：rpts=XXB,B0表示只显示XXB和B0表 |
i4.2.2开始，该功能由target=task替代 |
|
|
bbs |
表示登录后跳转到在线交流页面 |
i4.2.x, build 17094开始支持 |
|
|
bullet |
表示登录后跳转到公告页面 |
i4.2.x, build 17094开始支持 |
|
|
bbhlist |
表示登录后跳转到报表户管理页面 |
I4.2.2BUILD30187及i4.3, build 20524开始支持 |
|
|
proc |
|
存储过程名，在登录后，跳转到相应页面前执行存储过程，为空不执行存储过程 |
I4.2.2BUILD_27270开始支持 |
|
grp |
|
任务组代码. 适用于有taskgroup参数时 |
|
|
task |
|
任务ID或GUID . 适用于有task参数时 |
|
|
bbq |
|
报表期。只有在task参数存在时才有效。 必须是合法的8位报表期字串。传递此参数时，会自动打开插件查看对应报表户的数据 |
|
|
curbbhid |
|
当前登录户的报表户id。只有在task参数存在时才有效。 如果无此参数，则取当前登录者代表的当前报表户。 |
|
|
curbbhtype |
|
当前登录户的报表户类型。只有在task参数存在时才有效。 如果无此参数，默认为0。 |
|
|
userid |
|
要查看的报表户id。只有在task参数存在时才有效。 如果无此参数，则取当前登录者代表的报表户。 |
I4.2.2BUILD27287 |
|
btype |
|
要查看的报表户类型。只有在task参数存在时才有效。 如果无此参数，则取当前登录者的报表户类型。 |
I4.2.2BUILD27287 |
|
upid |
|
只有在userid,btype存在时有效，当指定打开户不在报表户列表中时，且上级不是当前报表户时，需要指定该参数 |
I4.2.2BUILD27287 |
|
bbhlistname |
|
是任务组名或任务ID．只有在target=bbhlist时此参数才可用 |
I4.2.2BUILD30187-i4.3 |
|
listbbq |
true|false |
是否进入数据填报户界面。只对汇总户有效。 当指定了bbq参数，又想查看指定bbq下所有的填报户情况，可以使用此参数为true。 |
|
|
readonly |
true|false |
只有bbq参数存在且没有listbbh参数时才有效。 以只读方式打开插件查看数据 |
。 |
|
forcelogin |
true|false |
表示是否总是登录。 通常，通过oemlogin登录后，不会再重新登录，以提高响应速度。指定此参数后，则每次访问oemlogin都再重新登录一下 |
|
|
dataset |
数据集名 |
指定允许访问的数据集名，用逗号分隔，且当前数据集为指定的第一个数据集. 如果为空，则默认当前数据集为main，且有权限访问其它数据集。例如：dataset=main,GS表示有权限访问主数据集和国税数据集，且当前数据 集为main. |
i4.2.x, i4.3 |
|
showtab |
汇总户页面指定显示的TAB |
进入汇总户页面专用。showtab=1为列表显示，showtab=2为树型显示，如果不设置，按任务的属性设置来显示 |
i4.2.2_BUILD27975 |
|
jscmd |
汇总户树型页面调用的JS命令 |
如果任务未设置默认显示树型，需要配合参数showtab=2使用。暂时仅支持jscmd=locateBbh('xxx','x')，执行在树型上定位到某一户，并打开该户数据，如定位到汇总户110000,设置jscmd=locateBbh('110000','9') |
i4.2.2_BUILD27975 |
|
noframe |
true|false |
-禁用框架包裹界面。 (--本参数在build 26882以上版本作废)- |
|
* 没有注明支持版本的参数，默认支持的所有i版本．
* 对于BI为主I为辅的单点登录环境，id和pw可以不用传，但要forcelogin=false. 这样只需要在BI中登录就行了。
要登录后显示任务组列表界面，
http://192.168.1.199:8080/irpt/oemlogin.do?id=xx&pw=yy&target=taskgroups
要想登录后显示任务列表界面，
http://192.168.1.199:8080/irpt/oemlogin.do?id=xx&pw=yy&target=taskgroup&grp=ZDSY
要想登录后进入任务界面，
http://192.168.1.199:8080/irpt/oemlogin.do?id=xx&pw=yy&target=task&task={EE311463-E596-425E-9288-F14507A2B015}.dbfbdeb331c76d8233e78379af54dc22]
要想登录后打开指定报表期的数据，
http://192.168.1.199:8080/irpt/oemlogin.do?id=xx&pw=yy&target=task&task={EE311463-E596-425E-9288-F14507A2B015}.dbfbdeb331c76d8233e78379af54dc22&bbq=200802--
要想登录后直接进入插件页面查看数据，该链接与上一个链接的区别在于，该链接主要是用于查询数据的功能，设置readonly=true后，插件菜单不显示，即使不设置readonly参数，也只能执行插件修改数据、上报等基本功能。如果需要全面使用报表户对数据管理的功能，需要使用上面的链接（target=task）,bbq参数不指定时，默认显示任务的最佳报表期。showmenu=true表示默认展开插件菜单
http://192.168.1.199:8080/irpt/oemlogin.do?id=xx&pw=yy&target=rpts&task={EE311463-E596-425E-9288-F14507A2B015}.dbfbdeb331c76d8233e78379af54dc22&bbq=200802--
如果登录才是服务器用户或汇总户，要想登录后打开指定报表户指定报表期的数据，
http://192.168.1.199:8080/irpt/oemlogin.do?id=xx&pw=yy&target=task&task={EE311463-E596-425E-9288-F14507A2B015}.dbfbdeb331c76d8233e78379af54dc22&userid=2300043434&btype=0&bbq=200802--
要想登录后自动进入组织机构与用户权限管理界面，
http://192.168.1.199:8080/irpt/oemlogin.do?id=xx&pw=yy&target=users
要想登录后自动进入在线交流：
http://192.168.1.199:8080/irpt/oemlogin.do?id=xx&pw=yy&target=bbs
要想登录后自动进入公告：
http://192.168.1.199:8080/irpt/oemlogin.do?id=xx&pw=yy&target=bullet
要想登录后自动进入报表户管理界面：
http://192.168.1.199:8080/irpt/oemlogin.do?id=xx&pw=yy&target=bbhlist&bbhlistname=ZDSY
要想登录后自动进入汇总户界面树型显示并定位到某一户：
http://192.168.1.199:8080/irpt/oemlogin.do?id=xx&pw=yy&target=task&task={EE311463-E596-425E-9288-F14507A2B015}.dbfbdeb331c76d8233e78379af54dc22&bbq=201106--&listbbq=true&showtab=2&jscmd=locateBbh('410802X15028102','0')
2. 任务列表界面接口
采用此接口可直接进入任务组显示任务列表。
适用版本：4.2.2
注意：此URL接口使用前需要登录
url中
例如，要使用户登录后直接进入某任务组的任务列表界面，则在"服务器管理"下的"服务器首页"设置中，设置首页地址为：
main/index.jsp?curl=tras/tasklist.do%3FgrpName=ZDSYRWZ
其中，tasklist.do后面的?号要转义成%3F。当一个url作为另一个url地址的参数时，特殊字符要转义。
采用此url接口可直达填报界面。
适用版本：4.2.2
A[Y)I~](ZC9Z[3Y)IDK7LK.gif)
/listbbq.do?taskId=注意：此URL接口使用前需要登录
url中
例如，要使用户登录后直接进入某任务的填报界面，则在"服务器管理"下的"服务器首页"设置中，设置首页地址为：
main/index.jsp?curl=main/listbbq.do%3FtaskId={B18E3DC6-B494-4D0E-82FC-DDA3EF34AF8D}.d2381a21552a34159c262cb2a76263ad
其中，listrbbq.do后面的?号要转义成%3F。当一个url作为另一个url地址的参数时，特殊字符要转义。
资源权限相对来说是实体权限，就是在系统资源树上能看得见的节点。我们在分配资源权限的时候就是限制用户能看到哪些节点，不能看到哪些节点。
用户的资源权限有三个来源：用户自身所分配的资源权限；继承所在机构的资源权限；继承所拥有的角色的资源权限。
如果一个用户同时具备上述三种来源，最终体现在该用户上的资源权限是三者的并集，
即：用户资源权限=用户自身资源+所在机构的资源+拥有的角色的资源 （三者并集）
对于门户资源，同一般资源一样，权限是取并集，具有不同入口分配的所有门户的访问权限。由于现在的门户系统中只会显示单个门户，但是在权限系统中可以授权多个门户，这里有个优先级别的问题。
例如在机构中分配了门户a的权限，在角色中分配了门户b的权限，在用户自身分配了门户c的权限，那么最终用户登录的时候进入哪个门户呢？
某用户同时拥有的门户a、门户b、门户c，哪一个最后更新，用户就进入最近更新的那个门户。
这个规则是在没有在个人设置中设置门户的前提下，如果一个用户需要固定进入自己指定的一个门户，那么就到"个人设置/外观与主题/门户设置"中指定默认门户，该设置可以让一个门户的优先级提到最高。
约定：设置了数据级次，必须分配数据级次权限才能计算，否则无数据权限。下面所述情况是在没有数据级次情况下分配的规则。
报表模板权限分配：只要分配查看权限即可。不需要分配该报表涉及到的主题表和维表的查看权限；
easyolap权限分配：首先要分配easyolap保存结果的权限，然后还需要分配该拖着分析所用的虚拟主题（或者主题表）的"即席分析"权限。
如果在分配门户权限的时候勾选了"计算所有报表"，在这种情况下，资源数上没有分配任何报表资源权限，用户登录进来也能计算该门户所有报表，包括easyolap报表。
数据权限的分配有四层：主题域、主题集、分组、报表
数据权限的分配有三处：机构、角色、用户
数据权限的规则与资源权限的规则完全不同，我们以四个数据权限分配的步骤来了解规则：
第一步
首先来看第一层，主题域，分别在机构角色和用户上定义主题域节点的数据权限：机构定义110100、角色定义110000、自身定义110101那么最后在生成sql的时候：
select sum(a.ZZC) as ZZC0
from FACT_SRZC a
where ((a.XZQH) = '110101' or (a.XZQH) like '11%' or (a.XZQH) like '1101%')
即：机构角色用户的主题域节点都分配了数据权限，最终都起作用了，而且数据权限之间是交集，解析成sql就是"机构数据权限&角色数据权限&用户数据权限"
第二步
在保留主题域数据权限的基础上，再分别到机构角色和用户的主题集节点上分配数据权限：机构定义120000、角色定义120100、用户自身定义120101，那么最后生成的sql：
select sum(a.ZZC) as ZZC0
from FACT_SRZC a
where ((a.XZQH) = '120101' or (a.XZQH) like '1201%' or (a.XZQH) like '12%')
即：忽略了主题域节点上的数据权限，优先使用主题集上的数据权限，而且三者取交集
第三步
在保留主题域和主题集数据权限的基础上，再分别到机构角色和用户上对报表分组节点分配数据权限：机构定义130000、角色定义130100、用户自身定义130101，那么最后生成的sql：
select sum(a.ZSR) as A2
from FACT_SRZC a
where (a.XZQH = '130101' or a.XZQH like '1301%' or a.XZQH like '13%')
即：忽略了主题域和主题集节点上的数据权限，优先使用报表分组节点上的数据权限，而且三者取交集
第四步
在保留主题域、主题集、报表分组数据权限的基础上，再分别到机构角色和用户上对报表节点分配数据权限：机构定义310000、角色定义310100、用户自身定义310101，那么最后生成的sql：
select sum(a.ZSR) as A2
from FACT_SRZC a
where (a.XZQH = '310101' or a.XZQH like '3101%' or a.XZQH like '31%')
即：忽略了主题域、主题集、报表分组节点上的数据权限，优先使用报表节点上的数据权限，而且三者取交集
小结：数据权限采用就近原则
报表数据数据权限》报表分组数据权限》主题集数据权限》主题域数据权限
如果系统指定了数据级次维，那么规则跟一般的数据权限相同。也符合数据权限的优先规则，并且也是机构、角色和用户的数据级次同时生效并取交集（生成sql用and连接）。
那么数据级次维的数据权限跟普通维的数据权限有什么不同之处呢？
数据级次维权限：必须分配，如果不设置数据级次维的数据权限，则默认为false，就没有数据的访问权限；
普通维数据权限：可以不设置，且不设置则默认为true，能计算出全部数据
资源权限：机构、角色、用户取并集，即机构资源+角色资源+用户资源；
数据权限：
主题域、主题集、报表分组、报表，采用就近原则，即报表》报表分组》主题集》主题域；
机构、角色、用户取交集，即机构and角色and用户
· 参数的隐藏及显示
o 需求场景
o 添加参数
o 结果测试
· 参数值间的联动
o 需求场景
o 省参数设计
o 市县参数设计
o 清空市县所选值
参数联动，是改变报表参数值后，触发其他参数值的状态发生改变，这些改变可能是参数值的变化，也可能是参数的显示与隐藏，样式等。
参数联动至少是两个报表参数的组合使用。我们来看一下常见的参数联动示例。
用户先选择所要查看的报表类型：年报或月报，当选择年报时，显示年份参数，当选择月报时，显示月份参数。
在报表中分别添加3个参数，分别是
|
参数名称 |
参数类型 |
是否默认显示 |
备注 |
|
报表类型 |
枚举下拉框 |
显示 |
枚举值：年报:1;月报:2 |
|
参数名称 |
参数类型 |
是否默认显示 |
备注 |
|
年份 |
日期 |
不显示 |
可设置可选择区间 |
|
年月 |
日期 |
不显示 |
可设置可选择区间 |
在“报表类型”的高级设置中添加参数的行为，实现参数间的联动。设置入口：右侧属性—〉高级—〉参数行为
当报表类型为空时，年份和月份参数未显示：
当选择年报时，出现年份参数，月份参数依旧隐藏
当选择月报时，出现月份参数，年份隐藏
行政区划参数值过多，需要提供2个参数省和市县，供用户进行一层层的过滤筛选。效果如：
1. 选择天津市时，市县中只显示天津市下面的市县供选择；
2. 再切换选择其他省，如北京时，清空市县中已选择的值；
在报表中选择一个维下拉框，使用的维表是：行政区划。参数只显示全国下的各省。
维表结构：
|
参数名称 |
参数类型 |
使用的维 |
实现只显示省的节点 |
|
省(@ss) |
维下拉框 |
行政区划 |
通过设置：节点过滤属性 |
添加一个维下拉框，使用维表：行政区划。内容只显示参数省中选择的省下的各市县。
|
参数名称 |
参数类型 |
使用的维 |
只显示参数省中选择的省下的各市县 |
|
市县（@city） |
维下拉框 |
行政区划 |
通过设置：根节点显示 |
选择参数时，变更所选的省份(@ss)时，清空市县（@city）已有的值，在省份(@ss)的属性：“高级—〉参数行为”中进行设置。
按照以上步骤设置，就完成了参数值之间的联动，效果所下所示：
当主题表数据和对应数据库表数据没有同步，我们想要完成主体表和数据库表同步。
管理员用户登录---->主题域---->主题集---->主题表—>【与数据库同步】
如果主题表字段与对应数据库表结构不同，就会对比后列出差异字段，然后同步。
主题集右键菜单【属性】，对主题集属性进行设置，在【数据表映射】标签页中，选择【创建映射方案】，如下图
弹出下图所示对话框，在对话框中输入新映射方案的名称、标题：
点击确认后，选择对应数据库连接池，然后点击保存，如下图：
管理员用户登录--->主题域--->主题集--->主题表--->【与数据库表同步】，弹出如下窗口：
（1）在主题集属性中只有缺省映射方案时，不显示选择映射方案对话框，直接与缺省映射方案对比；还有其他映射方案可供选择的时候，才显示对话框。
（2）缺省映射方案在下拉框中显示为“缺省映射”，而不是显示为空，以免误导用户。
点击确定后，对主题表和数据表进行列比对，然后列出差异，最后进行同步。
BI中的主题表与实际的数据库表可能会不完全一致，如BI中表元的字符类型可以表示所有的数据库类型，所以在同步时，只要表元的类型是字符，那么无论字段是什么类型，都认为是一致的。下面是所有的类型兼容列表：
|
字段类型 |
bi表元类型 |
|
字符 |
字符 |
|
整数 |
字符,整数,浮点 |
|
浮点 |
字符,浮点 |
|
日期 |
字符,日期 |
|
布尔 |
字符,布尔 |
|
图像 |
字符,图像 |
|
备注(Clob) |
字符,备注 |
|
OLE(blob) |
字符,备注,OLE |
Hadoop大数据技术经过十来年的发展，从最初的分布式存储，解决海量数据储存的需求，到后来的Map/Reduce，满足大数据的多任务批处理，再到后来的SQL on Hadoop技术，将成熟的SQL技术应用在Hadoop上，实现海量数据交互式分析、查询，使传统数据仓库人员能轻松拥抱Hadoop大数据技术。
l 2004年左右，Google发表GFS文件系统和MapReduce技术论文
l 2005年初，Doug Cutting在Nutch项目代码中引入MapReduce技术，出现Hadoop雏形
l 2008年1月，Hadoop正式成为Apache软件基金会顶级项目
l 2009年3月，出现首个商业化Hadoop发行版，即CDH
l 2011年初，Facebook开源Hive项目，提供基于MapReduce技术的SQL数据仓库工具
l 2013年起，开始涌现一大批开源SQL on Hadoop技术，旨在替代或优化Hive，成为交互式即时查询引擎
大数据最大的魅力在于通过技术分析和挖掘手段带来新的商业价值。过去几年里，大数据技术得到长足的发展，许多企业已慢慢开始接受以Hadoop为基础的大数据生态系统，并将它用作其大数据分析堆栈的核心技术组件。尽管Hadoop生态系统的MapReduce组件是处理大数据的成功典范，但随着时间的推移，MapReduce技术自身并不是处理存储在Hadoop生态系统中的数据的最简单途径，企业需要一种更简单的方式来执行查询、分析、甚至要执行深度数据分析的数据，以便发掘存储在Hadoop中的所有数据的真正价值。SQL on Hadoop技术就是因应这种需求而得到发展。
SQL on Hadoop，即在Hadoop之上提供SQL方式分析数据的技术。由于传统SQL技术在帮助各类用户发掘数据的商业价值领域具有很长历史，所以SQL on Hadoop技术成为非常关键的大数据查询、分析的一个方向。SQL技术能将复杂的数据操作抽象成几个关键字（Select，Insert，Update，Delete等）类自然语言的脚本形式，易学易用，被大量现有业务系统的开发人员和DBA所掌握。因此Hadoop成为流行的大数据分析平台之后，SQL on Hadoop成为无法阻挡的趋势，现有开发人员或DBA无需太大学习门槛，即可过渡到Hadoop平台上，直接用SQL进行大数据查询和分析。
数据分析供应商和开源社区采取了各种方法实现SQL on Hadoop。在Hadoop的数据集上提供SQL支持一开始是Apache Hive，一种类似于SQL的查询引擎，它将有限的SQL方言编译到MapReduce中。Hive是目前很多企业中处理大数据、构建数据仓库最常用的解决方案，甚至在很多公司部署了Hadoop集群不是为了跑原生MapReduce程序，而是用来跑Hive SQL的查询任务。但是，由于Hive对MapReduce的过渡依赖，其每个SQL都会解析为多个MapReduce任务，而每个MapReduce任务的输出都会导致HDFS写操作，造成大量的磁盘IO，导致查询的很大延迟，其主要适用场景是数据批处理模式。
值得庆幸的是，近年来，为SQL on Hadoop提供更好的解决方案方面已取得长足进展，出现了一批数据实时交互式查询引擎。有些厂商选择从头构建分布式SQL on Hadoop引擎。另外一些厂商则采取优化Apache Hive来缩小Hive与传统SQL引擎之间的性能落差。比较典型的有Stringer/Tez、Presto、SparkSQL等。
Stinger是Hortonworks开源的一个实时类SQL即时查询系统，声称可以提升较Hive 100倍的速度。与Hive不同的是，Stinger采用Tez。所以，Hive是SQL on Map-Reduce，而Stinger是Hive on Tez。Tez的一个重要作用是优化Hive的应用场景，通过减少数据读写IO，优化查询流程使得其比Hive速度提高了很多倍。Tez与Hive主要区别是，将SQL语义抽象为Map/Reduce操作，在这两个操作的基础上提供了更丰富的接口，并减少中间结果输出到HDFS的环节。虽然Stinger对Hive进行了较多的优化与加强，Stinger总体性能还是依赖其子系统Tez的表现。
Presto是Facebook开源的一个分布式SQL查询引擎，它被设计为用来专门进行高速、实时的数据分析，并且支持标准的ANSI SQL子集。Presto的运行模型与Hive有着本质的区别。Presto引擎使用了一个定制的查询执行引擎和响应操作符来支持SQL的语法，其所有的数据处理都是在内存中进行的。Presto设计了一个简单的数据存储抽象层，来满足在不同数据存储系统之上都可以使用SQL进行查询。
Spark SQL是近两年发展较快的大数据处理引擎，起源于加州大学伯克利分校AMP实验室。Spark SQL是把SQL解析成RDD的transformation和action，而且通过catalyst可以自由、灵活的选择最优执行方案。但是Spark SQL是基于内存的，元数据放在内存里面，不适合作为数据仓库的一部分来使用，这也导致其在共享集群上无法高效地分配资源和调度任务。目前Spark社区把Spark SQL朝向DataFrame发展，目标是提供一个类似R的接口，把这个作为主要的发展方向。DataFrame这个功能使得Spark成为机器学习和数据科学领域不可或缺的一个组件，但是在数据仓库（ETL，交互式分析，BI查询）领域似乎不再作为其主要发展方向。
这些新兴的SQL引擎，基本上都是将SQL语句解析为有向无环图(DAG)结构，采用并行计算引擎(MPP)在Hadoop上进行大规模数据分析、查询。这类MPP架构的SQL on Hadoop查询引擎相较早期的Hive有很多优势：
l DAG vs. MapReduce：最主要的优势，查询的中间结果不写磁盘，一气呵成。
l 流水线计算：上游计算任务一出结果马上推送或者拉到下一个阶段处理，比如多表Join时前两个表有结果直接给第三个表，不像MapReduce要等两个表完全join完再给第三个表Join。
l 高效的IO：采用零拷贝、本地读技术，本地查询没有多余的消耗，充分利用磁盘。
l 线程级的并发：充分利用CPU多核多线程并发执行任务，相比之下MapReduce每个任务都要启动JVM，本身就有很大延迟，占用资源也多。
2013年我公司推出全新的SQL on Hadoop产品，PetaBase。PetaBase基于开源平台基础上开发的、具有软件著作权的国产分布式数据库系统产品。PetaBase被设计为全新的SQL on Hadoop解决方案，在开源SQL引擎之上进行了大量SQL功能增强和性能优化，性能提升数倍甚至上百倍，并且集成多项管理工具，使其更适合在Hadoop上进行大规模数据分析、检索、查询。
PetaBase是一个分布式、高性能、支持SQL的大数据并行查询引擎和数据仓库系统，提供对TB级数据交互式查询，查询结果秒级响应。
PetaBase构建于Hadoop/HDFS之上，采用分布式集群架构，具有动态线性扩展能力，具有很高的容错性、稳定性和可用性，可轻松支持PB级以上数据处理。
PetaBase支持列式存储，查询时不读取无关的数据，提升I/O性能。同时列式存储能更好的进行数据压缩，压缩率最低能到30%以下，节省大量磁盘空间。同时也支持多种Hadoop数据格式，更可轻松将现有RDBMS系统的数据导入PetaBase。
PetaBase定位于管理大规模结构化数据(从TB到PB级)，是分布式的分析型数据库系统，适用于批量写操作，大规模随机查询的数据集市、数据仓库等。PetaBase是我公司大数据BI的组成部分。PetaBase已于2014年成功申请并获得国家版权局计算机软件著作权登记证书，具有源代码级的安全可控制技术，工程化的开发和优化可保证PetaBase在生产环境的实施部署。
在web浏览器上浏览大量数据，数据不可能一次性显示在WEB界面上，然而频繁与服务器交互也会大大降低用户体验。豌豆BI独创的采用了虚拟滚动技术来解决这些难题，让用户操作和浏览数据时像使用excel一样快捷，简单，方便。轻松玩转百万级别数据。
豌豆BI中随心所欲的拖拽图形位置，大小，“所想即所得”的dashboard。这些操作都依赖于自由布局技术。自由布局技术是纯web拖拽技术，是经多年技术积累，自主研发的拖拽框架技术，此框架技术独到之处不仅在于方便图形拖拽，更在于方便图形的任意扩展而不影响功能稳定性。
豌豆BI看板是由一个个图形组合而成。而每个图形都是采用独创组件技术，每个图形组件都能够自适应大小，当屏幕分辨率有变化时，图形可之行调整大小。所以无论是大屏，PC屏幕都能够轻松自适应显示。
为了大数据量计算能到秒级响应，同时考虑用户体验减少计算等待时间，经过多方面研究，敏捷计算引擎采用了并行&异步计算技术。图形与图形之间采用并行计算技术，用户多次操作引起局部计算采用异步计算技术。并行&异步计算技术最大限度得到计算速度，同时也极大的提升了用户体验。
上周新产品豌豆BI发布，得到广泛的关注和积极的反馈，看到大家的热情持续高涨，小编心情美美哒 。
但有些同学提出，对豌豆BI和BI@Report的区别有些疑惑，今天小编就带大家一起梳理下。
BI@Report（构筑数据之美，服务知识发现）
适用于大数据、复杂报表的数据展示分析应用平台，具有强大的可视化效果。可以帮助企业构建大型的综合的数据分析平台，也可以作为小型的个性化的解决方案。
豌豆BI（“玩”起来的数据分析平台）
猜想式、探索式的数据分析平台，具有傻瓜式的交互页面和强大的可视化效果，无需长期的建模定义和复杂的表达式定义，使数据分析轻松快捷。
文字看得不太明白，小编用一张图来解释下：
豌豆BI 主要用于业务人员自行分析数据场景；产品设计更关注简单易用，需要具备良好的数据探索能力和交互能力。
BI@Report 主要用于灵活搭建各类统计分析系统场景；产品设计更关注功能全面强大，需要良好的适配能力和丰富的接口。
由于豌豆BI和BI@Report的定位和使用场景不同，她们的功能侧重点有一些差异：
| 功能 |
BI@Report |
豌豆BI |
|
表格类型 |
支持设计各种中国式复杂表格，包括合并表元、多级表头等 |
支持单级、多级浮动表格，不支持不规则表格，注重分析结果而非形式 |
|
统计图 |
支持20多种统计图，每种图支持多种样式，组合可搭配出上千种视觉效果 |
支持10多种最常用的统计图，web2.0风格，提供智能推荐图形，避免用户选择困难 |
|
大数据可视化 |
支持流向图、渲染地图、词云图、双线图，Gis、3D可视化等，可良好适应大屏展示 |
支持渲染地图、标点地图、热力地图 |
|
配色 |
支持设置边框、颜色、透明度等，可自由搭配任意配色方案 |
一键配色，对于视觉水平一窍不通的用户也能做出简洁大方的图表 |
|
制作dashboard |
自定义布局，支持任意拆分合并，可以定义任意布局样式 |
拖拽图表自动布局，不需要用户定义，支持常用布局样式 |
|
数据筛选 |
支持按钮、滑块、输入框等各种参数，用户定义过滤表达式，支持各类触发事件 |
拖曳参数自动过滤，不支持定义复杂表达式和触发事件 |
|
扩展组件 |
支持各种组件，包括绘图、滑块、图片轮播、tab页、按钮、各种脚本接口等 |
支持富文本、链接组件 |
|
自动建模 |
不支持
|
根据数据自动识别指标维度，业务人员无需关心数据模型 |
|
上传文本数据 |
不支持 |
支持上传csv、txt、excel，上传后可直接分析 |
|
数据预处理 |
不支持
|
支持类excel的数据清洗、包括筛选、追加、增加计算列、序列填充等，业务人员自己完成预处理 |
|
数字画像 |
不支持 |
一键数字画像，帮助用户初步了解数据规律 |
|
智能推荐 |
不支持 |
根据指标维度自动推荐生成图形，让普通用户像分析专家一样得到自己想要的结果 |
|
自动联动 |
不支持自动联动，支持自定义，支持脚本和表达式 |
支持点选、框选图表自动联动数据，不支持脚本和表达式。 |
|
查看明细数据 |
不支持 |
任意图表可以查看对应的明细数据，包括摘要和原始数据。 |
|
计算指标 |
不支持 |
支持边分析边定义计算指标 |
|
实时刷新 |
不支持 |
即时定义即时刷新得到数据结果 |
|
保存为数据集 |
不支持 |
支持将分析结果对应的原始数据保存为数据集进行二次分析 |
相信看完以上的内容，大家对豌豆BI和BI@Report这两“姐妹”更加熟识，不会再“老虎老鼠傻傻分不清楚”了吧。
豌豆BI的产品团队也正努力地让她茁壮成长，“豆丝”们要继续关注哦。
支持敏捷看板，即席报告，幻灯片等多种分析方式，可以满足用户多元化的数据分析场景。敏捷看板，灵活的布局，满足用户随心所欲的拖拽；即席报告，类word的操作方式，可满足用户数据长报告的需求；幻灯片，可以替代PowerPoint完美贴合用户汇报的场景，数据还支持钻取联动，真正地实现用数据说话。
智能数据质量检查调度；通过事先定义好的规则、调度时间、工作流程，自动完成数据的质量检查，极大的减少人力的投入和过程干预，提升效率，减少误差。
重大问题及时告警；对质量检查的结果提供多方式（界面、邮件、短信）告警，让用户及时了解到系统检查结果，避免重大问题的延误。
一键生成质量报告和评估结果；系统通过数理统计、数据分析等技术，根据事先定义好的模板，自动生成质量报告和绩效考评结果。
支持用户在线自定义函数、数据期、地图、脚本、对象……
自定义函数：系统内置了丰富的函数及公式，也支持用户自定义函数，满足业务上个性化运算逻辑。
自定义地图：支持用户通过DreamWeaver等工具自定义地图后上传使用。
自定义数据期：系统支持年、月、季、半年、半月、旬、周、日、任意、五日、年周，也支持用户自定义数据期，满足各类频率的数据分析。
自定义脚本：系统支持用户在线定义计算执行前脚本、计算执行后脚本、客户端脚本、全局对象等。
亿信BI提供了单点登录集成接口、第三方机构库集成接口、WebService集成接口、URL集成接口四类集成接口，方便与第三方APP、应用集成。
亿信BI自带强大的二次开发平台，可灵活进行各类二次开发。提供丰富完善的事件接口：用户的点击操作、系统的业务处理流程、每个时期都可以调用和通知外部程序等。
插件式开发:系统提供动态加载机制，灵活热部署，在不宕机的可发布新的功能。
客户资源化:对界面UI上的图片、页面、样式、脚本，可最大自由度的进行修改和定制。
亿信BI对数据模型具有良好的包容性，除了支持标准的星型、雪花型、星云型等数据模型以外，还支持OLTP数据源。BI@Report是一个博采众长的产品，同时支持ROLAP和MOLAP两种模型。
支持Safari、安卓原生浏览器访问；支持iPad、Android等多种移动设备APP应用及大屏展示；并支持离线浏览，用户可将自己权限下的门户读到移动设备中，在无网络的情况下仍可继续浏览。
EsDataClean支持在业务系统建设、数据仓库建设各重要阶段设置数据检查监控点，并能实现跨监控点、数据源的比较分析。这种方式使得用户通过常规的规则定义即可实现ETL前后的数据一致性比对。
提供丰富的接口供二次开发和集成，包括API接口、Webservice接口、URL访问接口、单点登录等。
EsDataClean拥有丰富的函数库并支持用户自定义函数，可满足各种复杂及个性化业务逻辑检查需求。
EsDataClean搭配公司其他同源产品可构建更多应用。
亿信华辰元数据管理平台提供了自定义元模型管理功能。元模型的结构遵循了UML规范，按照包类的树形层级结构管理。元模型在支持CWM（公共仓库元模型）国际标准的同时，提供了一套便捷的的自定义管理接口功能，支持根据用户管理需要，进行自定义元模型以及元模型之间关系的扩展。
系统支持示例查询，提供了强大的任意单元格模糊查询，支持多个条件的AND和OR操作，十分简便。
系统支持清单列表，能够将不同报表户的某些数据集中显示在一张表上，极大的方便了用户浏览对照和统计比较数据。
1. 变长表的基本特点
从表样上看，变长表是列数固定，行数变化的报表，在设计系统中变长表只含一行变量表元，含变量表元的行叫做变量表元行。到了在线设计插件中，用户录入数据可以使变量表元行数增加或减少，纵向上的指标保持不变。从数据库的角度理解，变长表中的一行对应数据库中的一条记录，一张变长表有多少行数据，就对应了多少条记录。它作为一种标准的行列表区别于每一页才为一条记录的普通报表，这是变长表与基本表的根本差别所在。
变量表元行中的任一表元，不能为固定表元、备注表元等；除变量表元行外的任何地方，不能含变量表元。变长表每页显示（打印）多少行数据是可以通过报表属性设置的。
2. 变长表需求
某税收调查月报任务，需要采集《工业企业主要产品与税收信息》，采集的内容如下：
要求根据表样提供表样实现变长表设计，最终汇总户进行数据汇总的时候，按照代码进行汇总。
3. 变长表实现
3.1 新建
新建变长表时，系统默认的变长表表样为3行10列，第一行中的表元默认为固定表元，用来输入指标项目；第二行默认为数据行；第三行默认为合计行，合计行也是固定表元。
如果第一行的指标项目行，行数不够，可以增加。但是，在新建变长表时，数据行只能是一行（在在线设计插件中录入数据时可增加到多行）。
选择菜单栏第三个按钮"添加报表/新建变长表"，添加一个3行13列的空白表样，并在第一行下面再插入一行，如下图所示
3.2 表样设计
按照excel需求中的表样要求，将标题、合计行内容设计好。
其中涉及到的设计：
初步设计完成之后，可以达到以下效果：
3.3 代码表元
首先需要添加代码组"行业代码"
变长表第一列使用代码组，指定到"行业代码"，并设置显示方式代码+文字
4. 变长表的汇总方式
在需求中提到，最终汇总户进行数据汇总的时候，按照代码进行汇总，所以还需要设置汇总方式。打开"报表属性/变长表/汇总方式"设置成"按整个代码汇总"，并指定代码表元为A3，如下图所示：
【变长表汇总方式有很多种，分别说明】
1.所有数据行合计：数据汇总后系统将各下级单位的的各张变长表中的数据累加，并以一个单位一行的形式出现在汇总表中；
2.列出所有数据行：系统将所有下级单位的变长表中的数据行全部罗列到汇总表中；
3.列出直接下级合计行：仅将直接下级单位的数据合计值罗列到汇总表中；
4.按顶级子代码汇总：将各下级单位的数据根据代码中的顶级代码汇总，以此方式汇总时必须设置代码表元；
5.按整个代码汇总：将各下级单位的数据根据代码中不同代码累加到一起，以此方式汇总时必须设置代码表元；如果设置的"自动多级合计"，则汇总后可产生多级合计数据；
6.按关键字汇总：自己定义关键字，根据关键字进行汇总；
5. 效果预览
通过BI平台查看数据分析结果时，客户希望看到的并不是一张杂乱无章仅仅将结果简单罗列出来的的excel表格，难以体现数据分析意义。
客户可能会对分析结果提出更多要求：
（1）查询结果有很多，是否可以添加一列序号，共查询出多少条数据更加一目了然？
（2）某个指标需要重点关注，可否可以增加一列排名，有的放矢的采取针对性措施？
（3）对于重点关注的指标，是否可以进行排序，或者更进一步，既可以按照单个指标固定排序，同时，排序依据以及升降序由我们任意选择？
（4）我们不需要查看所有的明细数据，只需要了解前几名或后几名就可以了..........
以上是我们在做实施时经常会遇到的需求，这也是数据分析必不可少的功能，如此常见的需求是否可以轻易实现呢？
接下来，我们一起来学习如何快速实现上述需求。
准备一张单级浮动报表，如下图所示：
在浮动表中有两种方式可以添加序号：
（1）“#”，直接在表元输入“#”即可，如下图所示：
注意：序号表元一定要在浮动区域之内，即包含在绿框之内。
（2）使用row()函数，如下图所示：
注意：序号表元一定要在浮动区域之内，即包含在绿框之内；序号表元数据类型设置为整型。
利用排名函数实现指标排名，同样有两种方式：
（1）rank函数：表元代号.rank，这里的表元代号是指排序依据指标所在的表元，如下图所示：
截图中，展现的是统计企业增加值的排名。
（2）_rk()函数：括号中的参数需要写指标名，而不是表元代号。如下图所示：
rank和_rk()的区别：rank函数仅仅返回排名；_rk()函数功能更加强大，不仅可以返回排名，还可以对指标进行排序，同时对于相同排名，可以选择不同的处理方式，具体用法可参考函数说明。
（1）固定排序
由于是对浮动出来的数据进行排序，故需要在浮动表元属性中进行设置。
首先，选择升序/降序；
然后，选择排序依据，输入排序依据指标所在的表元代号，如下图所示：
（2）列头排序（排序依据以及升降序由客户任意选择）
列头排序需要在指标名称所在的固定表元属性中进行设置，勾选“排序”选项即可，如下图所示：
由于是对浮动出来的数据进行处理，故top分析同样要在浮动表元属性中进行设置，且一定要和排序结合使用。
（1）设置排序，如下图所示：
（2）输入数字。
· 假设需要显示统计企业增加值前五名的省份，则在TOPN,TOP%属性中输入5即可，如下图所示：
· 假设需要显示统计企业增加值占全国累计值前20%的省份，则在TOPN,TOP%属性中输入20%即可，如下图所示：
i@Report提供底层源代码级的安全性保障。通过对后台JAVA代码客户端程序加壳加密编译混淆防止破解；前端页面设计优化防止SQL注入攻击；防Flood攻击设计防止机器人暴力攻击；插件经过微软数字签名认证防止病毒篡改。
i@Report采用工业标准的加密和安全通信技术，确保客户端与服务器的交互信息在传送途中不会被他人窃听，切实保障用户数据的安全性和完整性。系统也支持CA数据认证技术，为用户提供诸如防抵赖等更高的安全要求。
i@Report提供详细的日志记录，如：报表发布和修改，用户的登录，服务器维护，用户管理，数据的上报、查看数据、数据修改等。
系统日志记录详细，能清楚的追踪到系统正在执行和已经执行的操作；
用户日志记录详细，方便查看用户登录情况和用户的变更情况；
数据日志记录详细，能准确的获知用户数据上报情况和变更情况；
可以根据需求，灵活配置用户需要记录的操作。
i@Report系统支持理论界广泛讨论的基于三权分立的角色管理性措施提供了完整实现。系统预设三类角色SYSSSA SYSSSO SYSAUDITOR，禁止超级管理员帐号。
SSA是应用系统管理员，负责系统维护与管理方面的工作；SSO是安全保密管理员，负责访问控制和权限分配，日常的审计工作由安全保密管理员负责；Auditor是安全审计员，负责系统管理员和安全保密管理员相关行为的审计。这种管理体制真正做到三权分立，各行其责，相互制约，可靠地保证了应用系统的安全性。
i@Report提供多级别的备份机制，包括单套报表的备份、多套报表的备份、全部报表的备份、整个服务器的备份等。备份工作可以是人工触发也可以由系统通过定时任务自动完成。 对于备份完成的数据，i@Report支持异构数据库间的备份与恢复，如在Oracle中备份的数据可以直接在SQL Server数据库中进行恢复，这对于系统升级、迁移、快速故障恢复等具有特别重要的意义。
看板分析零学习成本，一分钟上手，具有拖拽式的操作，全程无需编写表达式；此外可自由布局，具备多维报表、智能统计图、图表钻取联动、模板制作引用、筛选过滤等功能，并支持一键选择统计方法，如最大值、最小值、排名、比重、同比、环比、上期、去年同期等，满足各类用户对业务数据综合分析需要。
常言道：“工欲善其事，必先利其器”。想要玩转豌豆BI，首先要做好数据的预处理。
现实工作中，大家遇到的数据通常存在着各种问题：数据不完整、不一致、重复、存在错误或异常值等等，这样的数据直接进行统计分析，很可能无法获得用户想要的结果，因此，在进行数据分析展现之前，需要用到数据预处理功能来清洗这些“脏数据”。
那么豌豆BI中可以对数据进行什么样的清洗呢？现在就让小编来给大家秀一秀豌豆BI数据预处理的“绝顶功夫”：
以上是简单的计算列，用户还可以根据计算的需要来使用函数。
系统自动识别字段类型，并针对不同类型提供不同的可更改类型。
并且每个字段都可以在这里手动进行列设置和关联维度。
字段可进行的筛选包括：
1、勾选项筛选
2、文本筛选
3、数值筛选
直接双击需要修改的内容就可以进行修改。
数值型字段的自动填充：
字符型字段的自动填充：
豌豆BI的数据预处理功能还可以同时打开多张excel的sheet表，数据预处理完毕后即可保存为多张主题表。
数据预处理完毕后即可保存为多张主题表。
还有很多数据预处理功能，需要大家在使用中慢慢去挖掘。有了如此简单易用的数据预处理功能，我们的豌豆BI才能更好的展示出它最优秀的效果。
豌豆BI欢迎大家来尝鲜！
WonderBI支持html5统计图，目前提供的统计图类型包括：单级浮动表、多级浮动表、交叉表、柱状图、线状图、条形图、面积图、饼图、雷达图、散点图、仪表盘、气泡图、渲染地图、标点地图、热力图。
亿信数据质量管理平台（EsDataClean）包含丰富的质量评价方法，并且易于扩展。系统支持数十种质量评价算法技术，满足业务系统运行、数据中心建设、数据治理过程中各类规则的定义，并可实现跨数据源的对比分析；支持通过XML扩展，可完全适应企业未来的数据质量管理需求的变化。
亿信BI采用JS、FLASH、HTML5三种技术自主开发统计图，丰富的统计图保证了其具有美观的图形展现能力，除了常用的柱状图、线状图、条形图、面积图、饼图、点图、仪表盘、走势图外，还支持和弦图、圈饼图、金字塔、漏斗图、K线图、关系图、网络图、玫瑰图、帕累托图、数学公式图、预测曲线图、正态分布图、迷你图等，样式包括2D、3D、EXCEL、AUTUMN、FLASH等；通过组合设计可以搭配处上千种视觉效果。
EsDataClean支持在业务系统建设、数据仓库建设各重要阶段设置数据检查监控点，并能实现跨监控点、数据源的比较分析。这种方式使得用户通过常规的规则定义即可实现ETL前后的数据一致性比对。
> 综合分析 > 占比分析
> 趋势分析 > 同比环比分析
> 排名分析
亿信华辰元数据管理平台提供了完善的元数据监控功能帮助用户一目了然的了解元数据的使用情况和分布情况，以统计图的方式来展现元数据数量，分布情况，近期变更情况，关联度情况等，可视化效果好并且支持按照用户需求来自定义监控界面。
支持对未上报户的催报功能，系统可以给未上报户发送邮件或短信进行催报。当有用户在规定的时间内没有上报报表数据是，上级用户可以通过WEB界面发出催报短信，并能查询短信的送达结果和送达时间，短信催报支持GSM Modem技术和互联网短信接口等多种技术。
移动BI与PC上的展现可以完美的无缝对接，即在BI服务器上做的报表可以直接在移动门户上展示，而不需要针对移动报表专门另外设计一套报表，在移动设备上的显示也可以自动调整至最佳的显示状态。
在i@Report中，基本表只有一种汇总方式，即将所有数据累加；而变长表，则提供了多种汇总方式供用户选择。
我们一起了解一下i@Report变长表的汇总方式及效果。
1.变长表汇总方式
2.设置入口
切换到变长表所在页面，在报表空白区域单击右键选择菜单【属性】，将弹出的“报表属性”对话框切换中到“变长表”，在“汇总方式”中可以选择所需要的汇总方式，如下图所示：
3.其他相关属性设置
当用户选择的汇总方式是“按顶级子代码汇总”，“按整个代码汇总”或“按关键字汇总”中的任意一种方式时，“多级合计/关键字”中的“代码表元”和“自动多级合计”属性被激活。
•代码表元：若选择“按顶级子代码汇总”和“按整个代码汇总”，用户需要在此处指定相应的代码表元。
•多级合计：如果变长表在使用了多级代码，汇总方式选择“按整个代码汇总”时，可选择是否勾选“多级合计”。勾选该选项，汇总后可产生多级合计数据。
•自定义关键字：此处可设置变长表的关键字，系统根据关键字表元来唯一区分变长表中的每一条记录。
在许多项目中，BI@Report往往是作为一个辅系统被集成到其他的平台或者系统中，为了统一管理机构用户及单点登录，BI@Report提供读取第三方机构用户功能。
在配置前，需要客户在数据库中准备两张表或视图，用户表和机构表，至少包含如下字段。
用户表表名：users
机构表表名：departments
注：顶级机构代码，上机机构代码默认为--
进入bi系统，点击菜单栏上的系统管理->数据库连接池，新建数据库连接池，进行相关配置，将其指向存放用户表和机构表的数据库。测试成功后，点击保存，连接池就创建成功。
（1）点击菜单栏上的用户权限->左侧库表配置，进行如下图的配置操作。
（2）配置完成后，点击下一步。进行用户信息对应字段与机构信息对应字段的配置，具体配置如下图所示：
注：三种加密方式的显示效果
例如密码：123
没有加密（即明文显示）：123
MD5：202cb962ac59075b964b07152d234b70
{MD5}:{202cb962ac59075b964b07152d234b70}
（3）配置完成后，点击测试，测试结果如下图所示。
（4）点击完成，重启bi系统。
点击菜单栏中的用户权限->左侧机构用户，对组织机构用户进行查看。
在介绍灵活数值分段报表之前，先简单了一下固定的数值分段报表。
下面这张报表，就是一张固定的数值分段报表，根据总收入的数据大小做分段分析，分析各个总收入区间范围内医疗机构的数量。例如：表格中的数字27代表的业务含义是2011年总收入小于1000的医疗机构中，有27家医院。
上图所述的数值分段报表，之所以成为固定的数值分段，因为该报表的数值的分段节点是固定的，来看下设计界面就清楚了，总收入的分段节点为1000，5000，10000，是固定死的，每一列的取值都设置了相应的数值过滤条件。
那么，问题就来了，假设有的用户希望查看的分段节点是1000，2000，3000，又有的用户希望查看的分段节点是5000，10000，20000，还有用户希望……对于千变万化的分段需求，我们不可能把所有的组合都设计一个报表，如此一来，就迫使我们去实现灵活的数值分段，分段的节点由用户自定义输入，报表输出相应的分段结果。
接下来就以上文所述的分析需求为基础，将固定分段，改成灵活分段。
在报表的参数面板区拖入参数类型为【输入框】的参数组件，并设置相关的属性
为了能按照总收入的值自动分段，首先需要将横向的浮动表元设置为总收入字段（B6.C2）
注意：1、取值B6.C2，设置为浮动表元，浮动方向为向右浮动
2、此表由固定分段修改而来，不要忘记删掉_n()这个表元的过滤条件哦
数值浮动的表元，需要设置相关的属性，关键是下面三项：
· 排序设置：为了让数值分段的现实顺序从小到大，将排序类型设置为升序；
· 分组类型：默认都是常规分组，需要将该值设置为数值型分段
· 数值分段：设置为"~~-<#=@szfd#>-~"
|
在上述三个属性设置中，前面两个都很好理解，最后的数值分段设置为"~~-<#=@szfd#>-~"再展开介绍一下： · "~~"：表示负无穷大； · "~"：表示无穷大； · "-"：减号作为每个分段的连接符； · "<#=@szfd#>":用宏取的参数@szfd的值； |
豌豆BI支持html5统计图，目前提供的统计图类型包括：单级浮动表、多级浮动表、交叉表、柱状图、线状图、条形图、面积图、饼图、雷达图、散点图、仪表盘、气泡图、渲染地图、标点地图、热力图。丰富的统计图类型和样式可以让用户定义出各种美观的看板和画像。
天下武功唯快不破！
我们通过几组测试数据来感受下豌豆BI的敏捷分析计算引擎。
（100w行数据，weblogic11g+win2003）
通过测试结果，我们可以看到敏捷看板的计算一般1s不到，高并发情况下3s左右。这样的计算速度给用户体验提供良好的保证,它的最大特点就是 快! 快! 快!
豌豆BI的计算速度是如何做到呢？
计算引擎是BI产品的核心部分，豌豆BI充分吸收数十年来BI产品的经验，倾心打造了新一代的敏捷分析计算引擎。
敏捷分析计算专注于计算性能的优化，它的表现将关系到豌豆BI服务器整体的性能和易用性，如下图，我们可以看到敏捷分析计算引擎在服务器的位置。
敏捷分析计算引擎作为核心，它主要有以下几个方面的表现：
我们先来看下一般报表计算引擎的计算执行流程，如下图。一般常见的计算引擎会将一个任务直接分配给一个线程来执行，直到计算完毕后获取结果，计算引擎的任务才算完成。在这个计算过程中，计算任务将独自占有线程，直到计算完毕为止，执行过程有多长时间，就需要等待多长时间。
