OBIEE 11G的问题。记录被计算两次

时间:2014-07-18 19:24:01

标签: oracle oracle11g business-intelligence obiee

我的开发团队正在与OBIEE 11G合作进行如下分析:

了解哪些保单持有人处于警戒状态。警报定义为:当保单持有人的索赔数量超过某个阈值时。如果投保人在其中一个索赔中至少有一个警报,则保单持有人处于警戒状态。问题是这些阈值被定义为特定的密钥(客户类型,年龄范围,病理类型和其他东西的组合),并且保单持有人可以拥有许多密钥和每个密钥的阈值,因此索赔的数量不同。像这样:

Policyholder    Key #Claims Threshold
ABC123          XYZ  3       4
                WQE  3       2
EFG456          ABC  1       2

ABC123投保人共有6项索赔,其中3项为关键XYZ(阈值为4),3项为关键WQE(阈值为2)。另一方面,EFG456保单持有人有1个关键ABC的索赔,其阈值为2.因此,在这种情况下,ABC123保单持有人应处于警戒状态,因为关键WQE的索赔数量大于阈值。

因此,在OBIEE 11G中,我的团队添加了两列,一列用于标记警报中的记录,另一列用于标记未处于警报状态的记录。像这样:

Policyholder    Key #Claims Threshold   Alert   notAlert
ABC123          XYZ  3       4           0       1
                WQE  3       2           1       0
EFG456          ABC  1       2           0       1

你现在看到问题了吗? OBIEE 11G没有将保单持有人ABC123视为一个单位,并将其标记为处于警戒状态而非处于警报状态,这是错误的。正确的信息应该是:

Policyholder    Key #Claims Threshold   Alert   notAlert
ABC123          XYZ  3       4           0       0
                WQE  3       2           1       0
EFG456          ABC  1       2           0       1

因为,保单持有人未达到关键XYZ的警报并不重要。如果发现警报,则会检查保单持有人的完整文件以解决警报。

无论如何告诉OBIEE 11G ???

请帮助!!

2 个答案:

答案 0 :(得分:0)

我认为这是一个维度建模问题而不是OBIEE问题: 为了帮助我做一些假设:

  1. PolicyHolder和Key是单独的维度: 虽然“关键”维度包含保单持有人的一些属性, 例如客户类型和年龄组;它还结合了其他实体,如病理学和我 这足以将其视为至少一个迷你维度。

  2. “处于警告标志”可以建模为无事实的事实表: 看起来您只需要知道特定的保单持有人是否处于警戒状态, 没有与事件关联的度量标准,您只需要一个0或1的标志。这可以通过一个包含至少3列的简单表来解决:FK_POLICYHOLDER,FK_DATE和标志。您已经有一个标志,但它作为计算列包含在声明表中,如果您将此标志建模为单独的表,则可以控制警报的维度和粒度。请参阅What dw model is appropriate when there's no measure?

  3. 指标“声明数量”的维度与警报标记不同。 我认为问题的关键在于标志是在关键级别计算的,但仅出于报告目的需要在保单持有人级别进行。 如果您希望将警报“作为一个单元”分配给PolicyHolder,那么您需要一个链接到PolicyHolder维度但未链接到密钥维度的事实表

  4. 具体地:

    • 为“密钥”实体(客户端类型,病理等)创建单独的维度表
    • 创建一个包含保单持有人警报的新的无事实事实表,此表不应链接到Key维度。
    • 更改报告中的“提醒”列,您应该从新的无事实事实表的标志计数器中获取该值。

答案 1 :(得分:0)

首先,ALERT列似乎是多余的。这是一个非常简单的计算,OBI可以更好地动态完成。通过这种方式,您可以检查保单(在其密钥的集合上)或每个密钥的保单持有者。

如果我想在OBI中修复该计算,我会使用BMM中的计算逻辑列(基于其他逻辑列)来简单地针对THRESHOLD评估CLAIMS:

CASE WHEN CLAIMS >= THRESHOLD THEN 1 ELSE 0 END

这样,该标志可以在多个级别(POLICYHOLDER或KEY)工作。但这似乎是一个非常简单的计算,可以在分析中作为过滤器(或选择步骤)来完成。

虽然更简单(假设你有CLAIMS和THRESHOLD作为具有SUM聚合的度量列,POLICYHOLDER和KEY作为维度列)将完全忽略任何类型的警报列。如果您没有将KEY带入分析OBI,则会向您提供每个保单持有人,他们的总索赔额和总门槛。然后,您可以在条件中使用选择步骤或过滤器来删除那些未超过阈值的过滤器。