eazyBI 账户
在eazBI插件里，我们可以创建一个或者多个账户。一一个eazyBI帐户包含一组导入的JIRA项目数据，这些数据可以由eazyBI帐户用户访问（对eazyBI帐户数据的访问是独立于JIRA安全方案管理的）
账户与账户的数据是物理隔离的；同一账户下针对用户需要进行数据账户，是需要使用Data Access role的功能
如果有很少的JIRA项目，也不需要限制对不同JILA用户组的eazyBI报告的访问，那么我们可以使用一个eazyBI帐户，可以利用这个帐户导入所有的JIRA项目。
如果有大量的JIRA项目和大量的JIRA问题（超过100000），那么建议设置多个eazyBI 帐户，并且每个eazyBI账户导入与它有关系的一组JIRA项目集。由于每个eazyBI 帐户将导入的JIRA数据存储在单独的数据库表中，因此它也可以有助于eazyBI的 报告性能优化。分账户一是达成数据隔离，二是减少数据计算与响应的时间。
数据立方（Data cube）
eazyBI 将导入的JIRA数据存储在多维数据立方（data cube）中。多维数据集（Cubes）包含按维度（dimensions ）划分的事实数据，每个详细的事实“单元格（cell）”包含关于该事实的度量（measure ）值。
右图是一个问题立方的示例（Issues cube），这个数据立方包含项目、优先级以及时间的维度，而时间维度又包括问题的创建、到期日及解决时间三个的度量（measure ）；每一个数据立方对于特定的项目、优先级及时间周期，又包含一组问题的创建、到期日、解决时间。
很容易用三个维度（dimensions ）来说明立方Data cube ），但是在真实的EasyBi问题数据立方（Data cube ）中，你将有更多的维度和更多的测量方法，这将在下面进行描述。
每个维度都只具有所有维度成员(dimension members)的详细级别，或者具有多个级别(levels )的层次结构(hierarchy)。例如，项目维度具有项目和组件级别。
在上层层次(hierarchy levels)中，所有的度量(measures )都会自动聚合(aggregated )（通常是详细级别值之和）。如果问题可以属于多个级别的成员( members )（例如，问题可以有多个组件），那么在上层层次上的测量值(measure value )将不作为详细级别测量值的总和。
通常每个维度(dimension )都有一个层次(level )，所有成员都聚集(aggregates )所有维度成员(dimension members.)
时间维度将有两个层次，一个是年、季度、月和日，另一个是年、周和日。您还可以在财政年度、财政季度、月份、日还增加财政时间等级，并定义会计年度的第一个月。
度量（Measures）
问题数据立方（issues data cube)包括以下度量：
| Issues created | 与选定维度成员（dimension members）匹配的已创建问题的总数。如果使用时间维度，则创建的问题按问题创建日期分组，并在相应的时间段中显示。 |
|---|---|
| Issues due | 未被解决的到期（或未解决）问题。在时间维度上，它们按问题到期日分组（如果问题没有到期日，那么这些问题的总数只在所有时间成员中计数）。 |
| Issues resolved | 解决问题的决议和决议日期。按问题解决日期分组的时间维度。 |
| Issues with due date | 所有指定的日期（到期和解决）。按时间到期日分组的时间维度 |
| Original estimated hours | 预估小时总计。按问题创建日期分组的时间维度。 |
| Remaining estimated hours | 当前剩余估计小时数的总和。在时间维度中，对于未解决的问题按到期日来进行分组，对于已经解决的问题按解决时间分组。 |
Hours spent | 与选定维度成员匹配的问题所花费的小时总数。由维度记录的日志可以用来查看单个用户所花费的小时数。 我们可以挖掘单元以来获得所有工作日志条目的列表，这些日志条目构成特定时间花费的总值，可以在上面增加额外的信息，如用户名、日期、问题编号、工作日志的备注，以及该条目的日志记录时间。该列表可以导出到文件 |
| Sub-tasks created Sub-tasks due Sub-tasks resolved | 与选定维度成员匹配的父问题的子任务总数。 |
非重复问题汇总（Distinct issues count）
| Issues created count Issues due count Issues resolved count | 在非重复问题汇总测量，会按非重复的问题进行计算（唯一性）。这些测量可以得出与先前描述的问题产生不同的结果，即当多个具有多个成员选择的多值维度被放置在页面上时（例如项目组件或版本或多值定制字段）。 例如，如果选择了多个组件，并且一个问题属于两个选定组件，那么“Issues created”值将为2，但是“Issues created count”值将是1。 |
|---|---|
| Issues with hours spent | 在选定时间周期内，只要在这些时间周期内有任何的工时登记 ，都会被唯一计数。 |
如果Issues closed measure被导入，那么Issues closed count 也将在这个组中进行。如果选择了 Import issue change history,那么Transitions to status issues count、 Transitions from 和status issues count 也会在该组中。
计算测量（Calculated measures）
以下标准的计算测量是可用的:
| Open issues | 在对应的时间维度周期内，计算未解决的问题的数量（是指，在选定的时间周期内，创建的问题减去解决的问题数）。 |
|---|---|
| Average resolution days | 计算解决的问题（即在计算平均解决天数）平均天数，并通过在时间维度问题的解决日期进行分组。 计划解决问题的平均时长（按天计，以被解决） |
Average resolution workdays | 类似 Average resolution days ，只不过只有工作日的时间包含在内 |
| Average age days | 计算未解决的问题的平时时长（按天讲，被用于到问题的到期日，以时间维度，通过问题的到期日进行分组） |
Average age workday | 类似于Average age days ，但根据时间维度的选项计算工作日； |
| Original estimated hours with sub-tasks Remaining estimated hours with sub-tasks Hours spent with sub-tasks | 类似 于Original estimated hours, Remaining estimated hours, Hours spent， 但只包含所选问题的预估和实际的子任务时间。 |
(属性)Properties
对于每个特定维度成员，他们特定的属性是可用于计算测量的。有些属性也可用作为维度（发布类型、状态）来分析数据或与度量相关（问题创建日期与创建的度量问题相关），而其中一些仅作为属性（项目Lead）可用。
为了在报告中显示特定的属性值，在报告的行中，我们需要使用对应维度的维度成员：如果问题属性需要显示，那么需要有问题维度的问题层级；如果版本属性需要显示，那么修复版本或影响版本版本，需要有版本层级成员。
属性名称通过以相关维度的名称开始，如issue,project,version等等
| Issue properties | |
|---|---|
| Issue created date Issue updated date Issue resolution date Issue due date Issue reporter Issue assignee Issue type Issue priority Issue status Issue resolution | 如果将问题维度放置在行上并扩展到详细问题，且这些度量被放置在列上，那么详细的创建、更新、解决和到期日，以及报告人、经办人、问题类型、优先级、状态和问题的解决方式会被显示。 |
| Issue parent key Issue sub-task keys Issue open sub-task keys | 问题维度的详情如被放在行中，这也是有效可用的。 |
| Other properties | |
| Project lead Component lead | 项目维度（项目或者组件层级）被放在行中，这些是可用的 |
| Version release date | 影响版本或者解决版本的维度被放在行中，这些是可用的 |
（维度）Dimensions
测量项及可计算的测量项，可以通过以下维度进行分析
| Project | 项目维度层级包含项目层级，它能够扩展到组件级别以查看一个项目所有的组件。 如果它被应用于多个组件，它在每一个组件中都是计数的；但如果应用于整个项目，它只计数为1； |
|---|---|
| Reporter | 报告此问题的人； |
| Assignee | 当前经办的人 |
| Issue Type | 当前问题类型 |
| Priority | 当前问题优先级 |
| Status | 当前状态 |
| Resolution | 如果有为当前的解决结果 |
| Affects Version | 以项目和状态层级来进行分组，则显示前的问题的影响版本。如果一个问题中包含多个影响版本，那么每个影响版本将被计1次；如果是针对项目，则记录一次。 |
| Fix Version | 以项目和状态层级来进行分组，则显示前的问题的修复版本。如果一个问题中包含多个修复版本，那么每个版本将被计1次；如果是针对项目，则记录一次。 |
| Issue | 按项目层次级别分组的所有单个问题列表。问题维度通常不用于summary报告，但可以用于在问题维度问题级别上挖掘报告选定的结果单元，以查看在某些总数中计数的所有个别问题。 |
| Logged by | 按登记工时的用户； 通过用于 Hours spent 计量 |
| Label | 当前问题的标签；如果一个问题有多个标签，它将为每一个标准计数； |
| Time | 标准时间维度是年、季度 、日；或者年、周、日这两种层级； 可以启用（添加）财政时间层次结构，如财政 年、财政季度、财政月、财政日，以及定义好的财政年的第一个月； |
Reporter Group | 以相应JIRA的用户组，经办人和报告人进行分组；如果一个用户属于多个JIRA用户组，那些在用户组维度中，那么相应的计量值将会包括在所有相应的用户组中 |
| Age interval Resolution interval | 相应的问题间隔维度从问题创建日期到现在，以及按解决方案天数解决的问题。报表用户可以根据其eazyBI用户角色更改此维度的时间间隔 |
基于子任务进行报告
如果我们需要计算一些问题并包含这些问题的子任务总计的预估和实际消耗时间，那么我们可以使用（XXXX） with sub-tasks 的可计算测量项。
例如，如果您将只从问题类型维度中选择Bug，那么创建的问题度量将只显示问题类型Bug的问题数。如果要查看为这些Bug创建的子任务总数，请选择“Sub-tasks created度量值”（或“Sub-tasks due度量值”以显示open sub-tasks数，或“Sub-tasks resolved”以显示这些Bug的已解决子任务数）。
如果您将选择“Original estimated hours”度量，那么它将仅显示所选Bug问题类型的估计工时，而不显示这些Bug的子任务的估计工时。如果要查看包括这些Bug的子任务在内的总估计时数，请使用“Original estimated hours with sub-tasks”和子任务计算度量（以及与子Remaining estimated hours with sub-tasks度量相对应的剩余估计时数和 Hours spent with sub-task的时数）。
如果在报表中使用问题（Issue ）维度来显示详细的父问题和子任务，则可以使用Issue parent key, Issue sub-task keys和 Issue open sub-task keys来显示所选问题维度成员的对应父问题和子任务。