Проблема с OBIEE 11G. Записи учитываются дважды

Моя команда разработчиков работает с 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???

Пожалуйста помоги!!


oracle business-intelligence oracle11g obiee
person alois.wirkes    schedule 18.07.2014    source источник
comment
Не могли бы вы просто создать свой отчет (или информационную панель) и установить фильтр, чтобы показывать только там, где Оповещение = 1? Вы сказали, что вам все равно, сколько строк (ключей) имеет PolicyHolder, важно, чтобы одна из этих строк была в состоянии тревоги. Итак, если вы создаете отчет, чтобы показать вам только те строки, где Оповещение = 1, вы можете отфильтровать строки, где Оповещение = 0? Также я полагаю, что вы могли бы использовать подотчет, чтобы отфильтровать, где Alert = 0, чтобы у вас остались только страхователи, о которых вы заботитесь. Будет ли это работать? Кроме того, зачем иметь два столбца с флагами? Почему бы не иметь только Alert = 1 для оповещения и Alert = 0 для отсутствия оповещения? Зачем вообще иметь nonAlert?   -  person Mark P.    schedule 21.07.2014

Ответы (2)


arrow_upward
0
arrow_downward

Я думаю, что это проблема пространственного моделирования, а не проблема OBIEE: чтобы помочь, я сделаю несколько предположений:

  1. PolicyHolder и Key – это отдельные параметры: хотя параметр "key" содержит некоторые атрибуты держателя полиса, такие как тип клиента и возрастная группа; он также сочетает в себе другие сущности, такие как патология, и для меня этого достаточно, чтобы рассматривать его как минимум в мини-измерении.

  2. Флажок «Находится в состоянии тревоги» может быть смоделирован как таблица фактов без фактов: Похоже, вам нужно только знать, находится ли конкретный держатель полиса в состоянии тревоги, с событием не связан никакой показатель, и вы нужен флаг, равный 0 или 1. Это можно решить с помощью простой таблицы, которая включает как минимум 3 столбца: FK_POLICYHOLDER, FK_DATE и флаг. У вас уже есть флаг, но он включен в таблицу требований как вычисляемый столбец. Если вы смоделируете этот флаг в виде отдельной таблицы, вы сможете управлять размерностью и детализацией предупреждения. См. Какая модель dw подходит, когда нет меры ?.

  3. Метрика "количество требований" имеет другую размерность, чем флаг оповещения. Я думаю, что суть проблемы в том, что флаги рассчитываются на ключевом уровне, но для целей отчетности необходимы только на уровне страхователя. . Если вы хотите, чтобы оповещения назначались для PolicyHolder «как единое целое», вам нужна таблица фактов, которая связана с измерением PolicyHolder и НЕ СВЯЗАНА с ключевым измерением.

Конкретно:

  • Создайте отдельную таблицу измерений для вашего объекта «Ключ» (тип клиента, патология и т. д.)
  • Создайте новую таблицу фактов без фактов, содержащую предупреждения для держателя полиса. Эта таблица не должна быть связана с ключевым измерением.
  • Измените столбец «Предупреждение» в своем отчете, вы должны получить это значение из счетчика флагов вашей новой таблицы фактов без фактов.
person Victor HDC    schedule 22.07.2014

arrow_upward
0
arrow_downward

Во-первых, столбцы ALERT кажутся избыточными. Это невероятно простой расчет, который лучше выполнять с помощью OBI в динамическом режиме. Таким образом, вы можете проверить держателей полисов в предупреждении (по совокупности их ключей) или для каждого ключа.

Если бы я хотел исправить этот расчет в OBI, я бы сделал это с вычисляемым логическим столбцом в BMM (на основе других логических столбцов), просто оценивая ПРЕТЕНЗИИ относительно ПОРОГА:

CASE WHEN CLAIMS >= THRESHOLD THEN 1 ELSE 0 END

Таким образом, флаг может работать на нескольких уровнях (либо для POLICYHOLDER, либо для KEY). Но это кажется очень простым расчетом, который можно просто сделать в Анализе в качестве фильтра (или шага выбора).

Еще проще (при условии, что у вас есть CLAIMS и THRESHOLD в качестве столбцов показателей с агрегацией SUM, а также POLICYHOLDER и KEY в качестве столбца измерения) было бы полностью игнорировать любой столбец предупреждений. Если вы не внесете КЛЮЧ в анализ, OBI предоставит вам каждого держателя полиса, их общее количество требований и общий порог. Затем вы можете использовать шаги выбора или фильтр в критериях, чтобы удалить те, которые не превышают пороговое значение.

person jackohug    schedule 04.08.2014