PetaBase可配置为高可用的部署模式，即将单台主节点架设在两台主机上，一台处于活动状态，另一台处理待命状态。活动主节点响应正常操作，实时同步数据到备份主节点。活动主节点失效时，实时切换到备份主节点。

数据块多副本分布式存储，保证某个数据节点失效的情况下，其它数据节点上仍然有可用的数据块，保证数据不会丢失。

移动BI提供联系人功能，可以给联系人打电话和发站内信，让用户在移动工作的同时随时与同事保持密切的沟通。

管理员可以将重要事情使用公告的方式发布，让所有用户第一时间看到并执行。

移动平台提供论坛功能，让大家无障碍的沟通交流。

年报任务

格式：年+四个横杠，如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日报的所有规则都是一样的

一、主题模型类型和区别

1. 物理主题

●  概念

可以通过创建物理主题，在数据库中创建出一个新的的数据库表（空表表样），可视化图形化的创建方式，方便快捷的通过BI创建数据库表。

● 应用场景

通过BI界面，在数据库中创建表样。

2. 虚拟主题

●  概念

类似于数据库中的视图表，他在数据库中以存储数据值集形式存在。作用相当于筛选，并且数据可以来自于一个或多个表。一般用于easyolap报表的制作，也可用于复杂的报表模板取数。

注意：虚拟主题的创建是以物理主题为基础的。

● 应用场景

1、可以制作美观的、指标来自于多个物理主题表的拖拽式OLAP（easyolap）

2、通过虚拟主题表可以定义较复杂、来自于多个物理主题的取数关系。报表模板直接取定义好的虚拟主题表指标：简化报表模板的制作和维护。

3. 根据数据表创建物理主题

●  概念

我们最常说的主题应该就指的是根据数据库表创建物理主题，每个物理主题都会对应一张数据库表，考虑数据映射方案的情况下可能对应多张数据库表，它的结构和对应数据库表的结构应该是一一对应的，每个字段都应该在数据库表中有相同的字段。

● 应用场景

一般用于报表模板、QBE（示例查询）、OLAP（多维分析）的取数。可以通过新建物理主题，根据数据库表新建物理主题来创建它。

4. 引用主题

●  概念

在本主题集下对其它主题集下主题表的引用，在BI@report中还不能跨主题集取数，因此引入了引用主题的概念，引用主题仅仅是对其它主题集下主题表的一个引用，没有自己的结构和数据，我们只是把它当做跨主题集取数的一个桥梁而已，最终取数还是来自于它所引用的主题表。

● 应用场景

需要跨主题集取其他主题集下主题表数据。

5. 带表样的物理主题

●  概念

和物理主题类似，不过创建出的主题表示带有表样的，看起来非常直观，也可以通过导入的方式，将已经有的表样导入，直接使用。

● 应用场景

I和BI需要使用相同表样，使用I从BI刷新取数，或者BI取得I中填报数据进行查询展示以及多维分析（olap）。

二、各主题模型应用方式

1. 物理主题

利用BI界面直接在数据库中建立一张表，表中字段设置与BI中设置相同。

STEP 1

管理员用户登录系统--->分析平台--->主题域--->主题集--->主题表—>右键菜单【新建主题表】

STEP 2

在上一步的图中界面，填写名称（ 名称只能是字母、数字、下划线组合并且只能以字母或下划线开头。*必填）、 标题，选择【物理主题】，点击【下一步】

创建完成之后，数据库中就会存在一张和所建主题表名称相同的数据库表。

2. 根据数据库表创建的物理主题

想要分析数据库表中数据，新建一张和数据库表字段一一对应的主题表。

STEP 1

管理员用户登录系统--->分析平台--->主题域--->主题集--->主题表—>右键菜单【新建主题表】

STEP 2

在上一步的图中界面，填写名称（ 名称只能是字母、数字、下划线组合并且只能以字母或下划线开头。*必填）、 标题，选择【根据数据库表创建的物理主题】，点击【下一步】

在上图中选择BI中设置的【数据库连接池】方案，选择该连接池中对应的数据库表。

锁定数据库：指当（增、删、改）主题表字段时是否同步影响数据库内容，一般情况下勾选【锁定数据库】，点击完成。

STEP 3

点击完成后，会显示出下图所示界面，可以对字段进行修改，点击“红框”内菜单，保存主题表

别名：可以给数据库字段起别名，如果存在别名，分析表默认使用（表名.别名）

标题：对字段进行文字描述，在建分析表时能够通过标题的含义，很容易找到所需字段

是否维：如果否，则字段不对应任何维表；如果是，字段会对应一个和字段内容相符的维表（可以使用系统维表，也可以使用自己创建的维表）

3. 虚拟主题

虚拟主题是将来自于不同主题表的指标和维度整合到一张主题表中，使用虚拟主题表我们可以方便的进行easyolap的操作。将不同主题表的指标和维度整合到一张虚拟主题表后，如果要对该虚拟主题的指标进行分析，必须与原主题表建立表关联关系，不然系统会报错误。
注意：虚拟主题表的创建，是建立在物理主题表基础上的。所以在创建虚拟主题表之前，必须已经存在相应的物理主题表。
关于物理主题表如何创建，请参看《快速上手之物理主题创建》

Step 1：需求描述

有两个主题表【收入支出表】和【费用表】，表结构如下图所示，两张表的关联字段是bbq_和userid_。

要求：根据以上两张主题表，以及关联字段，创建一张虚拟主题表（包含字段，详见下面表格），再根据该虚拟主题表，做一个简单的拖拽式分析，分析内容为：行政区划（省份级别）分析各个省份的总收入/总支出/费用

Step 2：新建虚拟主题表

在导航树的【主题表】节点上，点击鼠标右键，选择右键菜单中的"新建主题表"，就会在右侧工作区打开主题表创建向导，在向导的第一步设置虚拟主题表的名称和标题，并在下面主题的选项中选择"创建虚拟主题"。设置完成之后，点击"下一步"。

Step 3：打开指标拾取界面

在刚生成的虚拟主题表中，选择树形显示，会默认存在一个空指标"newrow"，在该指标上右键菜单里面，选择"成批拾取"。系统会在工作区的下方加载所有主题表（该虚拟主题所在的主题集下面的所有主题表），同时，会弹出成批拾取的对话框。如下图所示：

Step 4：拾取指标

拾取的方式非常简单，在主题表标签，切换到目标主题表，直接鼠标左键，选择需要的指标，所有选择的指标都会自动添加到成批拾取的对话框。如果指标来自不同的主题，可以看到成批拾取对话框里面，指标是按照所在的主题表进行分组展示的。拾取完成之后，点击确定即可。

Step 5：保存

拾取完成之后，所有的指标都会自动添加到虚拟主题表中，"newrow"空指标可通过右键菜单中的"删除节点"进行删除；
每个拾取过来的指标，都有对应的表达式，从下图中可以明显看到，FY字段是取自FACT_FY表，其他的字段都取自FACT_SRZC表；
所有设置和内容确认完成之后点击"保存"按钮，系统就会在左侧导航树中自动创建该虚拟主题表了。

Step 6：设置关联关系

如果虚拟主题表的指标取自多个主题表，此时就需要定义两个主题表之间的关联关系。在需求描述中已经明确指出这两张表需要根据bbq_和userid_这两个字段进行关联。那么如何添加主题表的关联关系呢？
选择主题集的右键菜单中的"属性"，在右侧工作区会打开所有主题集属性设置的内容，切换到"表关联关系"这个标签；
点击"添加关联关系"，就会弹出关联关系定义框，定义的方法，将需要关联的两个主题表打勾，定义关联表达式，并且自定义关联关系的名称，确定之后，"保存"主题集属性。至此，虚拟主题就创建完毕，具体操作流程如下图所示。

4. 带表样的物理主题

通过创建主题表，在数据库张同步建表，不过，该物理主题创建界面可以拥有表样，表样可以自己创建，也可以通过导入I的报表完成创建。

可以达到快速将I中任务做成BI报表的需求

STEP 1

管理员用户登录系统--->分析平台--->主题域--->主题集--->主题表—>右键菜单【新建主题表】

STEP 2

在上一步的图中界面，填写名称（ 名称只能是字母、数字、下划线组合并且只能以字母或下划线开头。*必填）、 标题，选择【创建带表样的物理主题】，点击【下一步】

表格中用户名、密码为文字描述，鼠标选中的空白单元格属性如图，可以设置（字段名、别名、描述信息、对应维表等内容），可以根据需求，建立表样。

STEP 3

也可以通过导入的方式导入表样（格式支持*.npf,*.fact：npf为I任务中的报表（..\【任务文件夹】\_Reports\）;.fact为已经建好的主题表），导入方式如下图

步骤1

步骤2

步骤3

步骤4

上图为导入完成后，点击红框内保存，完成创建。（导入后的主题表和导入的I的报表的表名相同）

也可以通过主题集–>主题表右键菜单中【导入npf文件】方式批量导入（.zip格式压缩包）

5. 引用主题

在BI@report中还不能跨主题集取数，因此引用了引用主题概念。引用主题仅仅是对其它主题集下主题表的一个引用，没有自己的结构和数据，我们只是把它当做跨主题集取数的一个桥梁而已，最终取数还是来自于它所引用的主题表。

STEP 1

管理员用户登录系统--->分析平台--->主题域--->主题集--->主题表—>右键菜单【新建主题表】

STEP2

在上一步的图中界面，填写名称（ 名称只能是字母、数字、下划线组合并且只能以字母或下划线开头。*必填）、 标题，选择【引用主题】，点击【下一步】

STEP 3

如上图，可以BI引用平台中其他主题域中主题表，点击完成后，如图

不同的客户，可能要求的登录界面行为、样式、风格都不一样。 本文描述如何在i@Report中控制登录页行为和样式。

适用版本：i@Report 4.2.1 , 4.2.2 , 4.3.1

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在服务器管理中设置为服务器的登录页即可。

2. 登录页面的基本元素

i@Report的登录页面的基本构成元素如下图所示：

(1)信息提示区：用来显示登录过程中的提示信息或者登录失败后的异常信息．此元素可以是标准的DOM元素，如div,span或table等.但不能是表单元素．

(2)登录目标：显示要登录的目标任务组或服务器． 此元素可以是标准的DOM元素，如div,span或table等．但不能是表单元素．

(5)登录按钮：用来点击进行登录用的．可以是button,或img等元素.

这些基本元素在页面上的位置可以任意设置。可以最大限度的满足美工要求。

3. 登录页面脚本

要想在新设计的登录页面实现登录，必须在页面中嵌入如下脚本：

你只要将脚本中的界面元素的ID替换成新设计的登录页的界面元素的ID即可。

此段脚本要放在登录页的标签后面。

4. 使用新登录页

假设新设计的登录页放在i/oem/mycompany/login.jsp, 则，通过管理员登录，进入"服务器管理"-->"服务器首页"，在界面上的"登录页面"中输入"oem/mycompany/login.jsp"即可。保存后，点击注销，即可看到新设置的登录页面了。

灵巧的设计，让BI更轻快

本文从BI生成 sql 的原理解析入手，结合实际项目中报表设计优化的典型案例，系统讲解了BI分析表设计中性能攸关的设计要素。

1. 理解BI分析表的sql

1.1 单主题sql

一张分析单主题表的典型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语句性能的好坏，报表工程师有很大的决定权。

1.2 多主题sql

如果分析表的数据来源于多个主题，BI分析表的sql需要将多张主题表连接；典型的sql有两种：

1.2.1 先分组后连接

......

(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连接计算规则，如图：

1.2.2 先连接后分组

有些分析需要在两个主题的明细数据上进行运算和关联，此时不得不在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行的子表；性能相比，孰优孰劣，一目了然！

【先连接后分组】方式下，主题明细数据表连接的方式由报表设计中的什么元素决定呢？请看下图，是主题集属性中的表关联设置：

1.3 为什么会多sql？

查看分析表的【详细信息】，有时我们会发现为了计算一张分析表，BI生成了多个子sql嵌套和连接，或者干脆是多个独立的sql，为什么会这样呢？

要弄清这个问题，咱们得先回头再看看之前提到的sql语句：

SELECT表元表达式

FROM 主题表

WHERE 过滤条件（含表元、维表元、主题集过滤条件及数据期条件）

GROUPBY 维表元（带下钻级次）

HAVING 结果集过滤

ORDERBY 排序依据

一个这样的Sql语句可以查询出满足where子句条件的一批指标，如果有指标虽然来自同一个主题，但过滤条件不一样，还能用这一个sql一并统计出来吗？

1.3.1 过滤条件不统一

假设现在需要统计主题表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

1.3.2 连接方式不统一

在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 ）

1.3.3 多个独立的分析区

如果在报表设计上设置了多个独立的分析区，BI会为每个分析区单独生成独立的sql语句。因此我们需要注意，多个分析区真有必要独立分开吗？如果可以合并到一起，BI会尽可能用一个sql提交数据库处理，在某些场景下，特别是对数据量巨大的主题表而言，两次查询统计变成一次，性能上将会有不小的提升。

1.3.4 跨表取数

你一定很熟悉这个方框中的信息模式吧？这是BI中一张分析表的详细信息，但是==，为什么在一个分析报表的详细信息中会看到如此多不同报表的sql生成和计算日志？ 原来这张分析表使用了跨表取数，为了计算这张报表，系统先触发执行了其他报表的sql，具体详情请参考《tips201106》；这种情形下，虽然本表没有产生多个sql，但是间接地通过计算其他表，也执行了多个独立的sql，造成本表计算时间超长。

1.4 决定性能的sql要素

作为一个报表工程师，在设计报表的过程中，有哪些和sql性能相关的要素是我们可以调控，需要特别关注的呢？基于以上对BI分析表sql的理解，报表工程师们可着重关注如下要素： 1.过滤条件 2.连接模式 3.Sql个数 4.Sql数据量

下面将分别从这几个方面具体谈谈如何优化BI分析报表的设计。

2. 设计要素之1--过滤条件

BI分析表中的过滤条件在报表计算时都会转换成SQL语句中的WHERE条件，在大数据量的情况下，WHERE条件不够优化，会直接导致SQL语句运行效率低下，最直接的表现就是SQL语句执行时没用到索引或者用到的索引不够好。 我们都知道索引在rolap数据仓库中至关重要，好的索引对查询统计分析的性能提升具有不可替代的作用。因此，一个好的where条件会尽可能充分利用好的索引，决不会破坏数据查询走索引的可能。 BI报表的主题集、维表元、指标表元上都可以设置数据期条件和过滤条件，报表工程师们在这些过滤条件中编写的表达式都将直接决定报表sql语句中where子句的质量；什么样的过滤能构成一个质量上乘的where子句？什么样的过滤一定会造成where子句效率的损失？我们在编写BI报表过滤条件时又该注意哪些问题呢？

2.1 杜绝在指标列上使用函数

①、如何制作带浮动面板的报表

知识准备——浮动面板

浮动面板：在报表结果页面，悬浮在报表的右（上、下、左、右）侧的功能面板。浮动面板区域可以添加计算参数、按钮、文字、图片等功能组件；

就以上图报表为例，报表已经涉及完成，需要为该表添加两个浮动面板

· 浮动面板1：添加报表期计算参数和计算按钮；

· 浮动面板2：添加该表的文字说明；

Step 1 添加浮动面板

在报表编辑界面，点击工具栏上的按钮"显示浮动编辑区"，在此状态下才能为报表添加浮动面板

Step 2 编辑浮动面板1

浮动面板可视为一般的报表容器，可直接拖拽的方式给浮动面板添加参数组件，而且参数组件的编辑方式也保持不变。

· 参数面板拖入"日期"参数组件；参数名称和标题自定义为@bbq、报表期；设置参数类型为年（因为数据的时间颗粒是到年）；并设置报表的过滤条件bbq()=@bbq；

· 参数面板拖入"按钮"参数组件；参数名称和标题自定义为@js、计算；设置按钮事件为"计算"；

Step 3 编辑浮动面板2

用同样的方式，再拖入一个浮动面板；再用拖拽的方式为浮动面板添加文本组件；编辑文本内容；
如果有需要，可以修改一下浮动面板的图标，修改图标的方式是选中该浮动面板，有属性"图标路径"，即可设置；

Step 4 计算预览

默认两个浮动面板都是收起的，只要点击图标，就能展开浮动面板啦！

本讲座选自华宇软件吕宾先生于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号文件的优惠政策，我们将面临几百万量级的所得税费用。经过多次政策的研究和相关部门的沟通，这个政策后来做了修正，修正对于众多的和我们有类似情况的企业意义很重大。如果有很好的基于纳税人画像的服务体系，把这个信息推送给企业，我们将节省很多资源。纳税人的政策解读及税务处理服务对于万众创新、创业会有很好的帮助。

大数据在防范偷税漏税方面的应用，面临的最大的问题是数据的采集和整合，税务大数据分析涉及到社保、海关、银行、财政、保险、交通等多部门、多行业数据。

政府数据整合面临着方方面面的困难，这张图只能是一个很理想的状态，我们所有相关的政府基础数据都能够按照统一的数据标准，将数据推送到统一的数据平台，并且在这过程中进行有效的数据清洗、转换，通过统一的平台发布给各个行业使用。

以个人所得税为例，基于数据整合平台，个人所得税的申报会更真实。目前国家层面正在进行个人所得税税制改革的研究，有可能推出综合和分类相结合的个人所得税的税制，我们应用前面在企业纳税人方面提到的基于纳税人画像的风险评估策略，去开展个人所得税风险防范方面的分析。

税务大数据应用面临巨大挑战，需要丰富的行业经验与很强的资源整合能力，需要掌握数据分析核心算法与模型，要在大数据可视化技术方面有很好的积累，需要整个团队有全面的技术和服务经验。

谢谢大家！

整理：祁德力

校对：祁德力

01.杜绝冗长项目生命周期

一键部署、丰富的数据接口、自动建模、一键数据探索……帮助企业和政府快速构建决策分析平台

02.实时响应各种突发需求

灵活的分析看板、可视化数据处理、文本数据导入……面对突发的分析需求，无需技术人员支持，实时获得数据答案

03.敏捷计算引擎

敏捷计算引擎是自主研发的第三代计算引擎，从DW/BI理论出发，融合SQL技术，OLAP技术，并行&异步计算技术，使计算速度和用户体验达到极致

采用全导航交互式设计界面，技术门槛低。不管是规则定义还是流程管理都无需编写sql或代码，通过图形化界面进行简单配置即可，使得非技术用户也能对定义过程和定义结果一目了然。

亿信BI采用可视化建模，用户可直接在图形化的界面中直观地对主题表进行操作，主题表之间以及主题表与维表之间的关联一目了然。

亿信BI支持异构数据源模型，轻松进行多数据源的关联，同一张报表的数据可以来源于不同数据库的不同表

EsDataClean采用全导航式可交互界面设计思想，使用门槛低，引导性强，即使复杂的规则定义、流程管理等都无需技术人员编写sql或程序代码，只需通过图形化界面进行简单配置即可。

基于EsDataClean界面设计思想，使得非技术用户也能对定义过程、定义结果一目了然，有效解决技术人员和业务人员理解不一致而产生的数据质量风险。

数据是存储在HDFS之中，支持多种常见的Apache Hadoop文件格式和压缩编码。

PetaBase可以加载和查询由其他Hadoop组件，如Hive、HBase、Pig等生成的数据文件。

表元是报表元素中的最小单元，在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 枚举列表输入

指通过选择事先编辑好的选项来输入表元内容。用户填报时只需要在候选项中进行选择即可完成表元内容的输入。

设置步骤：设置表元属性中的“枚举列表输入”为“是”，则点击+ ，相关属性被激活，设置如下图：

设置效果：

1.功能：

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.具体示例

需求描述

在多系列的统计图中，系列之间的数据差距太大，导致数据显示不够直接，则需要通过设置多轴让统计图的数据显示的直接和美观。
以下面的实例给大家讲解多轴统计图的设置。

1.前提准备

新建一个报表模板，样表设置如下：

计算预览效果：

2.配置多轴属性

双击统计图，点击左下角的高级选项，选择坐标轴，然后做坐标轴模板有4种形式。第一：左轴+底轴；第二：左右轴+底轴；第三：上下轴+底轴（纵轴标签在同一边）；第四：上下轴+底轴（纵轴标签在相反边）。
在此选择左右轴+底轴的形式。

将系列对应轴的标签颜色设置为系列的颜色（默认第一系列对应左轴，第二系列对应右轴）
具体设置步骤如下：

3.计算预览

从bi4.1开始，我们可以对以前的老方法说拜拜了，因为bi4.1的容器，可以帮你实现任何布局的报表。

知识准备——多表体

所谓多表体，就是一张报表上有多个分析表体，可以实现样式多元化，更加美观的报表。从功能上来说，借助容器组件将表体划分成多个区块，每个区块都是一个独立的分析表体，同时，多个表体之间是可以进行表间运算的。

知识准备——容器

容器，是BI报表设计的一种组件，这种组件可以将表体划分成多个独立的区块。
容器根据不同的布局，分为单容器、田字型容器、工字型容器、左右型容器、上下型容器；不同的容器是可以相互嵌套的，如此便可能实现任结构的多表体报表了，例如，先在表体中拖入一个上下型容器，在该容器的下半个容器中，再拖入一个左右型容器，结果就是一个类似于"T"字形的容器了。

练练手——需求描述

实现以下布局的报表，保证四块内容的比例协调。

Step 1 新建报表，拖入容器

根据需求的描述，我们需要的是"田字型容器"组件，只需要将基础组件中的田字型容器拖入表体即可：

（接下来的操作步骤，就跟一般的报表设计一样，所以有些步骤会精简精简再精简）

Step 2 拖入表格，取数定义

田字型容器将表体分为四块区域，根据需求，分别在左侧的两块区域中拖入分析区表格和文本组件，分析区表格组件用来表体定义，文本组件用来定义标题文字

Step 3 拖入统计图，统计图数据定义

为报表添加统计图的方式也非常简单，之需要在组件区，将需要的统计图组件拖入表体相应位置即可。
统计图组件添加完成之后，就可以双击统计图，打开统计图的设置窗口，为统计图设置数据源、配色等。

Step 4 计算，预览

计算得到预览的结果，从下面结果可以看到，表格与统计图之间的布局，是"田字型"的布局方式，一般不需要在排版上花费太多的时间和精力，就能出来比较协调的结果

知识补充：本表其他设计要点

要点1：立体感十足的标题

· 背景图片：在搜索栏搜索bg.gif，应用。如果有自己制作好的其他的更好看的背景，也可以上传进行应用哦；

· 大小自适应：设置为水平撑满，保证在表格的容器区域是被填满的；

· 平铺方式：设置为平铺；

要点2：容器最小宽度设置
本表需求的实现中，表格内容比较少，所占的宽度相对较少，系统默认给出的最小宽度是50%对该表来说并不合适，需要调整。根据实际的需要，将田字型的左侧区域调整最小宽度为33%

I作为辅系统与第三方系统集成时，除了配置单点登录之外，将的用户库同步也是实现单点登录的必要工作。

1. 用户库同步

由于I的单点登录只支持服务器用户，所以需要分别同步I的机构表和服务器用户表，并分配权限。对于服务器用户来说，若不给其分配权限，本身是没有任何权限的，所以需要对服务器用户分配数据填报的权限。若要给服务器用户分配数据填报的权限，则每个服务器用户都要对应到具体的报表户身上，因此，我们也要对I的报表户列表进行同步。

需要注意的是，存放主系统用户库的数据库用户必须与I所连接的用户库相同，同时该用户应该有查看和管理主系统用户库数据的权限（可通过授权或者同义词等方式分配），以便完成用户库同步的操作。

完成用户库的同步需要以下三个步骤：

1.1 机构表的同步

数据库中存放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级上级代码········

1.2 服务器用户的同步

数据库中存放I的服务器用户信息的数据库表是IRPT_USERS，表结构如下图所示：

上表中，前五个字段是必须的，需要在数据库中将用户库表中这几个字段的数据抽取到IRPT_USERS这张表中。此处需要注意的是，机构代码的字段名是DEPARMENT而不是DEPARTMENT，没有中间的T。

通过服务器用户的表结构可以看到，服务器用户本身并没有任何层级关系，需要通过所在的机构来划分服务器用户之间的层级关系，以实现服务器用户与报表户的一一对应。

1.3 报表户列表的同步

数据库中存放I的报表户信息的数据库表是UL_任务组名首字母缩写，表结构如下图所示：

上表中，前五个字段和第11-20个字段是必须的。其中，btype表示报表户的类型，‘0’表示基层户，‘9’表示汇总户；upid0······upid9同机构代码。有两种方式可实现报表户列表的同步，分别是数据抽取的方式和建立视图的方式。

1.3.1数据抽取

这里的数据抽取，同机构表和服务器用户表的数据同步过程一样，都是将主系统用户库表中的必须字段的数据抽取到存放报表户信息的数据库表中。

1.3.2 建立视图

在i中，有自定义报表户列表的功能，报表户可来自于其它表或者视图。因此，可以在数据库中根据主系统的用户库表创建一个与报表户列表结构相同的视图，在i中直接引用这个视图，具体实现步骤如下：

首先，点击任务组的属性进入任务组属性界面，如下图所示：

然后，点击自定义报表户列表，进入自定义报表户列表界面：

在空白处找到刚才建的视图，然后点击自动匹配，就可以完成报表户的同步同样的，btype和upid可能在主系统的用户库中没有，需要手动添加。

2.权限分配

首先，确定每一个报表户的权限；然后，通过定义角色实现服务器用户数据填报权限的批量分配。需要说明的是，由于顶级汇总户所属的机构为顶级机构，顶级机构的上级机构代码均为空，而其他服务器用户所属的机构均有上级机构代码，所以需要创建两个角色，分别进行匹配，具体操作步骤如下：

2.1 顶级汇总户角色

（1）为顶级汇总户创建一个角色，并设置相应的匹配公式，使得满足条件的服务器用户被自动授予该角色的权限，匹配公式如下图所示：

上图中的顶级机构代码即为顶级机构的机构号，如下图所示：

（2）为该角色分配相应任务的数据填报权限。首先，找到并选中需要填报的任务组；然后，点开“数据填报”窗口，选择“ ”定义匹配公式批量匹配报表户；最后，选中已经定义好的匹配公式，右侧会将该任务组下的所有任务列出来，选择“读写”这一列，即可完成该角色数据填报权限的分配，具体如下图所示：

2.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);

}

维是观察事物的角度，根据维的数据结构，将维分成三种类型：单级维，多级维和通用维。
维表可以分为主体域维表和主体集维表。主题域维表作用于整个主题域，在此主题域下的任何主题集都可以使用；而主体集维表，只能在此主题集下才可以使用。

下面我们就开始介绍单级维、多级维和通用维的创建方式。

2.单级维

（1）点击左侧维表，然后点击工作区内的添加，开始编辑维表结构。

具体编辑内容如下：

点击保存。
（2）编辑维表相应的内容，点击保存。

（3）查看最终效果

注：若维表对应的数据表已存在数据库当中，我们只需要在数据库表名那选择对应的数据库表，那么对应数据表中的字段以及数据就自动导出来，然后我们设置id和文字字段，点击保存即可。

3.多级维

（1）新建一张维表，编辑维表结构如下：

点击保存。
（2）编辑维表相应的内容，点击保存。

（3）查看最终效果

4.通用维

（1）新建一张维表，编辑维表结构如下：


点击保存。
（2）编辑维表相应的内容，点击保存。

（3）查看最终效果