Интеграция результатов углубленного анализа данных InfoSphere Warehouse с отчетами IBM Cognos: Часть 2. Обнаружение отклонений с помощью InfoSphere Warehouse и Cognos

Эффективное распространение результатов углубленного анализа данных

В первой части этой серии статей мы рассмотрели, как визуализировать простые результаты углубленного анализа данных в IBM® Cognos®. Настоящая статья знакомит с некоторыми более сложными методами, такими как детализация и извлечение структурированной информации из моделей углубленного анализа данных с помощью Cognos. Используя приведенный здесь бизнес-сценарий и пример, мы разберем задачу углубленного анализа данных по обнаружению отклонений, то есть задачу выявления необычных записей. Мы покажем, как находить такие записи с помощью системы углубленного анализа данных IBM InfoSphere Warehouse и научимся создавать отчеты, допускающие интерактивное изучение.

Михаэль Й. Вюрст, старший инженер-программист, IBM  

Михаэль Вюрст (Michael Wurst), Ph.D., работает старшим инженером-программистом в лаборатории IBM Research & Development Lab в Беблингене (Германия). Он имеет степень д-ра философии по вычислительной технике и отвечает за алгоритмы и инструментарий углубленного анализа данных в InfoSphere Warehouse. До прихода в IBM Михаэль был соразработчиком, архитектором и консультантом по программному обеспечению углубленного анализа данных RapidMiner.



18.12.2009

Введение

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

Записи данных, которые отклоняются от общего распределения, называют "выбросами". Обработка выбросов, как правило, не является полностью автоматизированной задачей. Вместо этого с помощью углубленного анализа данных выделяют записи, заслуживающие пристального изучения аналитиком или экспертом, который должен решить, следует ли принимать меры. Необходимым условием успешной обработки выбросов является развитые интерфейс пользователя и модель взаимодействия. Для решения этой задачи прекрасно подходит Cognos. Действительно, для визуализации выбросов можно использовать отчет, аналогичный тому, который был создан в первой статье настоящей серии. Однако чтобы мобилизовать все возможности Cognos для отображения выбросов, необходимо использовать некоторые более сложные функции. Сначала посмотрим, как применять детализацию (drill-through) для создания интерактивных отчетов Cognos и как связывать отчеты между собой. Это поможет обобщить информацию и обеспечит быстрый доступ к соответствующим записям-выбросам. Затем мы научимся извлекать из моделей углубленного анализа данных дополнительную информацию, которая поможет специалистам понять природу выброса.

В качестве примера к этой статье приводится приложение, которое помогает сотрудникам банка выявлять клиентов, демонстрирующих необычное поведение. Это можно использовать для предотвращения мошенничества или для выделения клиентов, заслуживающих особого внимания. В следующем разделе приведен обзор способов обнаружения отклонений и показано, как можно использовать InfoSphere Warehouse для поиска выбросов в крупных массивах данных. Последующие разделы посвящены основам детализации и извлечения информации из модели углубленного анализа данных, а также тому, как обе эти методики можно использовать для упрощения результатов обнаружения отклонений с целью их изучения и практического применения.


Обнаружение отклонений с помощью InfoSphere Warehouse

Что такое обнаружение отклонений?

Обнаружение отклонений определяется как задача нахождения необычных записей в крупных массивах данных. Такие записи называют выбросами. Определение "необычности" заслуживает отдельной академической дискуссии и может зависеть от области применения метода обнаружения отклонений. В общем случае обнаружение отклонений нацелено на то, чтобы найти записи данных со свойствами, которые не совпадают с общим статистическим распределением для большинства записей. В зависимости от области применения в качестве отклонений могут выступать:

  1. Некорректные данные (например, если возраст человека 300 лет, вероятно, это ошибка, допущенная при вводе записи в базу данных).
  2. Необычное поведение наблюдаемых процессов (например, операции с кредитными картами, которые не укладываются в обычные модели).

Соответственно, обнаружение отклонений может использоваться для разных задач. Если предположить, что массив данных может содержать некорректные данные, то обнаружение отклонений можно применить для очистки данных, то есть для поиска некорректных записей в базе данных. Во втором случае данные корректны, но указывают, что некоторые процессы, отраженные в этих данных, демонстрируют необычное поведение. Это можно использовать для выявления случаев мошенничества, что наряду с очисткой данных является важной областью применения методов обнаружения отклонений. Как упоминалось выше, необычное поведение не обязательно связано с мошенничеством. Например, оно может также указывать на возникающие новые шаблоны поведения, скажем, интенсивное использование онлайновых аукционов людьми преклонного возраста. Выявление таких новых тенденций на раннем этапе позволяет компаниям рано предлагать новые продукты или услуги, что дает им существенное преимущество перед конкурентами. Аналогичное применение можно найти в финансовом секторе. Обнаружение отклонений используется для поиска перспективных инвестиций, которые не соответствуют обычным моделям и потому остаются непризнанными. Во всех этих случаях аналитик должен изучить выбросы, чтобы посмотреть, имеют ли место некорректные данные, или же следует принять меры против мошенничества или использовать какие-то новые, до сих пор не осознанные возможности. В следующем разделе мы рассмотрим, как InfoSphere Warehouse обнаруживает выбросы и как обнаружение отклонений можно применить к вашим данным. Во второй части этой статьи рассказано о возможностях интерактивной визуализации выбросов в Cognos.

Обнаружение отклонений в InfoSphere Warehouse

В последние годы было предложено много различных методов выявления отклонений. InfoSphere Warehouse использует особенно мощный метод, основанный на кластеризации данных (data clustering). Кластеризация — это способ анализа данных, при котором записи группируются в "кластеры" записей, аналогичных по своим свойствам. Взгляните на рисунок 1. Каждая точка на диаграмме соответствует одному клиенту. В этом простом случае клиенты описаны только возрастом и средним остатком на банковском счете. InfoSphere Warehouse использует статистический алгоритм кластеризации для группирования тех клиентов, которые схожи по этим двум параметрам. Как видно, некоторые кластеры больше и ближе к центру, чем другие (Кластер 1 в отличие от Кластера 3). InfoSphere Warehouse комбинирует несколько свойств, присваивая каждому кластеру степень отклонения. Чем этот уровень выше, тем больше вероятность того, что записи в кластере можно рассматривать как выбросы.

Рисунок 1. Обнаружение отклонений методом кластеризации
Обнаружение отклонений методом кластеризации

Таким образом, резкого различия между выбросом и не-выбросом нет. Порог выбросов должен указать пользователь. Все кластеры с уровнем выброса выше этого порога помечаются как выбросы, и все их члены считаются выбросами. Этот порог можно установить двумя способами. Во-первых, если у вас ограниченное число экспертов, которые могут проверять выбросы, можно просто использовать записи данных, которые относятся к кластерам с самым высоким уровнем отклонения. Если же вы ищете перспективные компании, в которые следует вкладывать средства, вероятно, стоит начать с кластеров с самой высокой степенью отклонения, а затем переходить к кластерам с меньшей степенью отклонения, насколько у вас хватит ресурсов. Во-вторых, порог может быть фиксированным. Это случай сценария оповещения, когда требуется принимать меры, если любая новая запись данных относится к кластеру со степенью отклонения выше установленного порога. InfoSphere Warehouse позволяет делать то и другое, просто присваивая каждой записи данных идентификатор кластера и соответствующую степень отклонения. Вы можете применять функции фильтрации и сортировки, чтобы выявить выбросы, которые следовало бы проанализировать. В следующем разделе на практическом примере подробно описано, как найти выбросы с помощью InfoSphere Warehouse и как присвоить степень отклонения отдельным записям.

Практический пример

В следующем примере выявление отклонений применяется к записям о клиентах банка. Выборка данных из соответствующей таблицы приведена на рисунке 2. Таблица BANK.BANKCUSTOMERS содержится в примерах, входящих в комплект поставки InfoSphere Warehouse.

Рисунок 2. Пример данных из таблицы BANK.BANKCUSTOMERS
Пример данных из таблицы BANK.BANKCUSTOMERS

Чтобы обнаружить выбросы в этой таблице:

  1. Создайте новый поток анализа, как показано в предыдущей статье.
  2. Кроме того, как показано там же, нужно перетащить оператор таблицы исходных данных в окно редактора.
  3. Дважды щелкните на операторе, чтобы открыть его, укажите BANK.BANKCUSTOMERS в качестве исходной таблицы базы данных и для подтверждения нажмите OK.
  4. Теперь перетащите оператор Find Deviations (найти отклонения) в поле рядом с исходной таблицей и соедините выходной (output) порт исходной таблицы со входным (input) портом оператора Find Deviations. Измените имя кластерной модели, сгенерированное оператором Find Deviations, на IDMMX.OUTLIERMODEL. Дважды щелкните на операторе, чтобы открыть окно свойств, и измените имя модели на второй странице мастера.
  5. Наконец, создайте подходящую целевую таблицу, выбрав Create Suitable Table... (создать подходящую таблицу) из открывающегося правой кнопкой мыши контекстного меню выходного порта оператора Find Deviations. На первой странице мастера выберите схему BANK и введите имя таблицы CUSTOMERS_OL. Щелкните на кнопке Finish. Оператор Table Target (целевая таблица) будет связан с потоком. Если нужно запустить поток несколько раз, имеет смысл установить флажок Delete Previous Content (удалить предыдущее содержание) в свойствах оператора Table Target.

Этот поток просто загружает таблицу клиентов, передает ее потоку обнаружения отклонений и записывает результаты в новую таблицу (см. рисунок 3). Фрагмент полученных результатов представлен на рисунке 4.

Рисунок 3. Поток анализа для выявления отклонений.
Поток анализа для выявления отклонений

Как видно, появились два дополнительных столбца, а именно, DEV_DEGREE и CLUSTER_ID. Первый указывает, с какой степенью уверенности запись считается выбросом. Идентификатор кластера – это идентификатор кластера-"выброса", к которому принадлежит запись. Дополнительную информацию об этих кластерах можно извлечь из анализа кластерной модели, созданной оператором поиска отклонений. (Это обсуждается ниже в настоящей статье).

Рисунок 4. Пример данных из таблицы результатов BANK.CUSTOMER_OL
Пример данных из таблицы результатов BANK.CUSTOMER_OL

Создание интерактивного отчета Cognos для обнаружения отклонений

В этом разделе мы покажем, как создать отчет Cognos, позволяющий интерактивно исследовать выбросы. За отправную точку можно взять отчет, аналогичный отчету из первой статьи этой серии. Вместо таблицы пациентов с указанием того, кому из них следует порекомендовать медицинское обследование, теперь у нас есть список клиентов, указывающий, чей счет следует проверить на предмет вероятного мошенничества или коммерческого потенциала. Этот подход хорошо работает для небольшого числа клиентов, тогда как список из нескольких тысяч записей не очень удобен. Кроме того, аналитик может захотеть увидеть, что именно делает конкретного клиента "выбросом". Для такого уточнения понадобится дополнительная информация. Поэтому давайте расширим простой подход по двум направлениям:

  • Сгруппируем клиентов по профессии и посмотрим, сколько выбросов относится к каждой профессиональной категории. Такого рода группирование — хороший способ работы с большими объемами информации. Например, можно представить, что каждая категория рассматривается и анализируется по конкретным обязанностям работников данной категории. Вместо профессии, можно выбрать другие аспекты (например, местожительство).
  • Обогатим каждую запись-выброс информацией о том, почему данная запись считается выбросом. Как упоминалось выше, каждая запись присваивается кластеру, и все члены кластера имеют одну и ту же степень отклонения. Для описания выбросов можно использовать свойства кластера. Например, если кластер содержит в основном очень молодых людей с высоким средним балансом, вероятно, это хорошо объясняет, почему данный кластер был опознан как выброс.

В следующем разделе сначала показано, как обогатить выбросы дополнительной информацией. Затем мы создадим интерактивный отчет, который группирует клиентов по профессии и позволяет интерактивно выбирать выбросы определенной категории с помощью функции Cognos Drill-Through.

Извлечение дополнительной информации из моделей углубленного анализа данных

Таблица CUSTOMER_OL содержит сведения, относящиеся к выбросам. Как упоминалось выше, каждая запись относится к некоторому кластеру. Оператор Find Deviations создает в фоновом режиме кластерную модель, в которой хранится подробная информация об этих кластерах. Эта информация содержится в базе данных в формате PMML (Predictive Model Markup Language). Она включает следующие сведения:

  • Распределение значений в кластере
  • Число записей в кластере
  • Значимость переменных для каждого кластера
  • Однородность кластеров
  • и др.

С помощью хранимых процедур, включенных в InfoSphere Warehouse, эту информацию можно получать в виде результирующих наборов для ввода в Cognos. Такие наборы можно рассматривать как "представления", но не явно созданные в базе данных, а динамически формируемые хранимой процедурой.

Если нужно извлечь текстовую информацию о кластерах, можно использовать следующую команду:

SELECT ID, DESCRIPTION FROM TABLE(IDMMX.DM_GETCLUSTERS((SELECT MODEL FROM IDMMX.CLUSTERMODELS WHERE MODELNAME='IDMMX.OUTLIERMODEL'))) AS CT

Она создаст таблицу, содержащую перечисленные ниже столбцы:

  • ID: идентификатор кластера (соответствует ID в таблице CUSTOMER_OL)
  • ОПИСАНИЕ: текстовое описание кластера

Такие результирующие наборы можно передавать в Cognos как обычные представления или таблицы. Только имейте в виду, что эти хранимые процедуры не входят в состав DB2, они добавлены пакетом InfoSphere Warehouse. Вернемся к этому чуть позже. Рисунок 5 суммирует два способа передачи информации из InfoSphere в Cognos: в виде простых представлений баз данных/таблиц или в виде выдержек из аналитической модели с использованием хранимых процедур. Такие хранимые процедуры существуют не только для кластерных моделей, но и для многих других моделей анализа данных. Полный список доступных функций для получения выдержек из модели приведен в документации InfoSphere Warehouse (см. Ресурсы). Ниже мы покажем, как можно использовать Cognos Framework Manager для совмещения информации обоих видов.

Рисунок 5. Два способа доступа к аналитической информации в Cognos
Два способа доступа к аналитической информации в Cognos

Импорт и объединение результатов анализа в Cognos Framework Manager

Для нашего отчета нам понадобятся два объекта запроса (query subject) в проекте Cognos, которые мы затем соединим, чтобы получить текстовое описание каждого выброса:

  • Простой объект запроса, который обращается к таблице выбросов BANK.CUSTOMER_OL, созданной в первом разделе. Этот объект запроса содержит записи о клиентах вместе со степенью отклонения и идентификатором кластера.
  • Объект запроса, который использует хранимую процедуру для доступа к информации о кластере по модели кластеризации, созданной в результате работы потока анализа. Как описано выше, информация о кластере содержит, в частности, краткое текстовое описание кластера (которое в данном случае является описанием всех записей-выбросов в этом кластере).

Во-первых, нужно создать проект Cognos Framework Manager, имеющий подключение к примеру базы данных DWESAMP InfoSphere Warehouse и содержащий созданную ранее таблицу BANK.CUSTOMERS_OL. Подробные инструкции о том, как это сделать, приводятся в первой статье настоящей серии. Чтобы иметь уровень абстракции поверх объектов запроса, создаваемых операторами SQL, лучше всего создать объект запроса в пространстве имен PresentationView, который будет содержать необходимую вам информацию из базы данных. Это позволит также заменить имена столбцов на более содержательные, а также добавить дополнительные столбцы. Нам понадобится элемент запроса outlier-flag (флаг выброса), который будет указывать, считается ли данная запись выбросом. Вычислим его на основе элемента степени отклонения DEV_DEGREE.

Чтобы создать объект запроса для таблицы выбросов, используемый в отчете:

  1. Создайте новый объект запроса OutlierTable в пространстве имен PresentationView из модели (Existing query subjects and query items [существующие объекты запроса и элементы запроса]).
  2. Добавьте все элементы запроса из объекта запроса CUSTOMER_OL и замените имена на более содержательные.
  3. Добавьте новый элемент запроса со следующим определяющим выражением:
IF ([PresentationView].[OutlierTable].[Deviation factor] > 1000) then (1) else (0)

Этот элемент запроса будет равен "1", если отклонение превышает 1000; иначе он будет равен "0". Фактор отклонения 1000 выбран в качестве разумного порога для нашего набора данных. Возможно, будет полезно сделать эту чувствительность к отклонению параметризованной, чтобы возвращать в качестве выбросов больше или меньше записей.

Ваше определение объекта запроса должно выглядеть как на рисунке 6.

Рисунок 6. Определение объекта запроса для таблицы выбросов
Определение объекта запроса для таблицы выбросов

Второй элемент запроса — это таблица с информацией о тех кластерах модели кластеризации, которые созданы в процессе поиска отклонений. Это табличное описание модели кластеризации можно извлечь в InfoSphere Data Mining с помощью определяемой пользователем функции IDMMX.DM_GETCLUSTERS, которая возвращает таблицу кластеров в модель вместе с кратким текстовым описанием распределения полей этого кластера. Модели кластеризации сохраняются как объекты CLOBS в таблице IDMMX.CLUSTERMODELS вместе со столбцом MODELNAME, который можно использовать для выбора подходящей модели. Чтобы использовать определяемую пользователем функцию в Cognos, ее нужно упаковать в оператор SELECT. Поскольку табличные функции InfoSphere Warehouse Mining не являются стандартными функциями DB2, для создания этого объекта запроса нужно изменить некоторые параметры Cognos.

Чтобы создать объект запроса описания кластера из табличной функции DB2:

  1. Выберите базу данных DWESAMP в папке Data Sources Project Viewer и измените свойство Query Processing в представлении свойств на Limited Locale. Это разрешает использовать не известные Cognos объекты запроса из SQL.
  2. Создайте новый объект запроса OutlierClusters в пространстве имен PresentationView и выберите вариант моделирования объекта запроса из источника данных. Его моделирование из хранимой процедуры будет поддерживать только хранимые процедуры, известные Cognos.
  3. На странице Select a data source (выбор источника данных) выберите DWESAMP и снимите флажок Run database query subject wizard (использовать мастер создания объектов запроса базы данных). Мастер создания объектов запроса работает только со стандартным SQL. Щелкните на кнопке Finish.
  4. После того, как объект запроса создан, открывается окно мастера Query Subject Definition. Введите код SQL, возвращающий кластеры из модели, где IDMMX.OUTLIERMODEL — имя модели кластеризации, сгенерированной в процессе поиска отклонений.
    SELECT * FROM TABLE(IDMMX.DM_GETCLUSTERS((SELECT MODEL 
    FROM IDMMX.CLUSTERMODELS WHERE MODELNAME='IDMMX.OUTLIERMODEL'))) AS CT
  5. Поскольку это не признанный Cognos SQL, нужно установить тип SQL-запроса Native, чтобы Cognos не интерпретировал запросы SQL, а передал их в базу данных. Чтобы изменить эту настройку, откройте вкладку Query Information свойств объектов запроса. Выберите Options и замените SQL type в разделе SQL settings на Native.
  6. A Выполнение тестового примера (Test Sample) должно возвратить таблицу с кластерами модели, как показано на рисунке 7.
    Рисунок 7. Результаты тестирования объекта запроса кластера-выброса
    Результаты тестирования объекта запроса кластеров-выбросов

Использование хранимой процедуры в качестве входа для объекта запроса имеет то преимущество, что в базе данных не создаются никакие дополнительные таблицы или представления. Что еще важнее, хранимая процедура будет выполняться в процессе создания отчета. Это делает возможным динамическое выполнение аналитических вычислений на стадии генерации отчета. Эта тема подробнее рассматривается в последующих статьях настоящей серии.

Для создания отчетов, объединяющих таблицы OutlierTable с объектами запроса OutlierClusters, нужно создать связь между оценочным идентификатором кластера записей-выбросов и идентификатором кластера из таблицы кластеров.

Чтобы создать связь между OutlierTable и объектами запроса OutlierClusters (рисунок 8):

  1. Выберите Create Relationship из контекстного меню OutlierTable.
  2. Для левого объекта запроса выберите идентификатор кластера OutlierTable и установите мощность связи равной 1 .. N, поскольку к одному и тому же кластеру принадлежит множество записей.
  3. Для правого объекта запроса добавьте объект запроса OutlierClusters, выберите столбец ID и установите мощность связи равной 1 .. 1, поскольку для каждого кластера существует только одна строка.
  4. Выберите OK.
    Рисунок 8. Создание связи между OutlierTable и объектами запроса OutlierClusters
    Создание связи между OutlierTable и объектами запроса OutlierClusters

Теперь у нас есть объекты запроса, необходимые для отчета Cognos, и мы можем развернуть пакет OutliersPackage, содержащий представление PresentationView проекта для Cognos Content Store (рисунок 9). Создание и развертывание пакета осуществляется точно так же, как описано в предыдущей статье этой серии.

Рисунок 9. Созданные ресурсы в Framework Manager
Созданные ресурсы в Framework Manager

Связывание отчетов Cognos с помощью функции Drill-Through

Первоначальная идея детализации (drill-through) относится к задаче перехода от анализа агрегатных значений к исследованию отдельных записей. В приложениях OLAP это обычная задача. В Cognos данное понятие используется в более широком смысле как любого рода "связывание" отчетов между собой. Таким образом, определения drill-through преследуют те же цели, что и гиперссылки в HTML. Связывание отчетов само по себе — не особо мощное средство. Мощным инструментом определения drill-through делает использование параметров. Каждый отчет в Cognos может содержать параметры, которые можно использовать, например, для создания настраиваемых запросов. Если эти параметры не заданы, пользователю предлагается выбрать их. В определении drill-through эти параметры можно определить как часть гиперссылки (так же, как в запросах HTTP GET). Значения этих параметров можно вывести из контекста связи. В следующем разделе эта концепция иллюстрируется с использованием двух связанных отчетов.

Создание отчета о выбросах с помощью Cognos Report Studio

В этом разделе мы создадим проект с двумя страницами отчетов на основе развернутого пакета OutliersPackage:

  • На главной странице содержится обзор записей клиентов, сгруппированных по профессиям, с соответствующим числом выбросов для каждой профессии.
  • Вторая страница отчета содержит фактические записи-отклонения для данной профессии.

Оба отчета связаны так, чтобы в записи отклонений можно было попасть со страницы общего обзора.

Так как обзорная страница содержит ссылки на страницу детальных сведений, давайте создадим сначала детальную страницу. Страница деталей выбросов содержит записи клиентов, которые помечены как выбросы и относятся к профессии, выбранной на главной странице отчета. Для создания такой взаимосвязи необходимо добавить к отчету параметр профессии и использовать его в фильтре записей. Необходимо также добавить к фильтру условие, чтобы он находил только записи со значением элемента запроса Outlier Flag "1" (все записи со степенью отклонения выше порога).

Чтобы создать страницу отчета Outlier Details, выполните следующие действия (рисунок 10):

  1. Создайте новый отчет в Cognos Report Studio с использованием пакета OutliersPackage.
  2. Добавьте к отчету объект типа «список» (list).
  3. Добавьте в список объект запроса OutlierTable, перетащив его из представления Insertable Objects.
  4. Добавьте в список элемент запроса DESCRIPTION из объекта запроса OutlierClusters.
  5. Добавьте в список фильтр, выбрав список и нажав значок Filters на панели инструментов или выбрав Data > Filters из меню.
  6. В окне мастера добавьте фильтр Details с помощью значка Add.
  7. На странице Detail Filter Expression добавьте в Expression Definition следующий код:
    ([PresentationView].[OutlierTable].[Outlier flag] = 1) 
    AND ([PresentationView].[OutlierTable].[Profession] = ?Profession?)

    Cognos автоматически определит ключевое слово Profession, окруженное знаками "?", в качестве параметра и добавит его в список параметров отчета.
  8. Подтвердите фильтр кнопкой OK.
    Рисунок 10. Фильтр для страницы деталей выбросов
    Фильтр для страницы деталей выбросов
  9. Измените текст заголовка отчета и заголовков столбцов по своему усмотрению и сохраните отчет как OutlierDetails (рисунок 11).
    Рисунок 11. Cognos Report Studio с отчетом Outlier Details
    Cognos Report Studio с отчетом Outlier Details

Обзорная страница содержит список всех профессий с указанием количества клиентов и количества выбросов для данной профессии. Число записей определяется с помощью агрегатных функций Cognos.

Чтобы создать страницу OutlierOverview:

  1. Создайте новый отчет в Cognos Cognos Report с помощью OutliersPackage.
  2. Добавьте к отчету объект типа «список» (list).
  3. Из объекта запроса OutlierTable в представлении Insertable Objects перетащите в список следующие элементы запроса: Profession, Customer ID и флаг Outlier.
  4. Столбец Customer ID используется для отображения числа записей клиентов каждой профессии. Для его расчета необходимо в свойствах столбца заменить агрегатную функцию столбца на Count.
  5. Столбец OutlierFlag используется для отображения количества выделяющихся записей клиентов каждой профессии. Поскольку этот столбец содержит "1" для каждой нестандартной записи и "0" для стандартной, нужно сложить эти значения. Замените агрегатную функцию данного столбца на Total.
  6. Замените свойства Data Item > Name и Data Item > Label столбцов Customer ID и Outlier flag на Number of customers (число клиентов) и Number of outliers (число выбросов).
  7. Чтобы включить функцию drill-through для OutlierDetails Report, выделите столбец Number of Outliers (не заголовок, а столбец под ним) и выберите пункт Drill-Through Definitions из контекстного меню, открывающегося правой кнопкой мыши.
  8. Добавьте новое определение drill-through.
  9. На вкладке свойств Target Report выберите OutlierDetails в качестве целевого отчета.
  10. Выберите действие Run the report.
  11. Установите флажок Open in new window (открывать в новом окне).
  12. Добавьте новый параметр связи, воспользовавшись кнопкой Edit под списком параметров.
  13. В диалоге Parameters выберите в качестве метода установления связи параметра со значением строки списка Pass data item value (передавать значение элемента данных).
  14. Выберите элемент запроса Profession в качестве источника данных и нажмите OK (рисунок 12).
    Рисунок 12. Определение параметров drill-through
    Определение параметров drill-through
  15. Нажмите OK, чтобы сохранить определение drill-through (рисунок 13).
    Рисунок 13. Страница определений drill-through
    Страница определений drill-through
  16. Измените текст заголовка и сохраните отчет как OutlierOverview.
  17. Теперь ваш отчет можно запускать из меню Run > Run HTML или из Cognos Connect.
  18. Нажмите ссылку из столбца с количеством выбросов, , чтобы увидеть подробные данные (рисунок 14).
    Рисунок 14. Страница обзора выбросов
    Страница обзора выбросов

Этот простой проект состоит всего из двух отчетов. Благодаря определению Drill-Through, которое содержит параметр определяемой контекстом ссылки, вам не нужно создавать ссылки для каждой профессии отдельно. В следующих статьях этой серии показано, как с помощью определений drill-through делать более сложные вещи, такие как динамическое выполнение углубленного анализа данных.


Заключение

Из этой статьи вы узнали об обнаружении отклонений и способах его реализации с помощью InfoSphere Warehouse. Обнаружение отклонений – это интерактивная задача, и чтобы определить, указывают ли они на мошенничество, ошибки ввода данных или какие-то интересные новые возможности, выбросы, как правило, должны проверяться вручную. Cognos очень хорошо подходит для решения задач интерактивного анализа выбросов. В дополнение к простым методам, используемым в первой статье этой серии, вы познакомились с двумя дополнительными методами. Во-первых, дополнительную информацию можно извлекать из моделей углубленного анализа, которые еще не вошли в оценочную таблицу, с помощью хранимых процедур. Во-вторых, отчеты Cognos можно связывать с использованием функции Drill-Through, которая позволяет создавать интерактивные отчеты. В следующих статьях этой серии мы расскажем, как пойти еще дальше, динамически вызывая из Cognos функции углубленного анализа данных.

Ресурсы

Научиться

Получить продукты и технологии

Обсудить

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Профиль создается, когда вы первый раз заходите в developerWorks. Информация в вашем профиле (имя, страна / регион, название компании) отображается для всех пользователей и будет сопровождать любой опубликованный вами контент пока вы специально не укажите скрыть название вашей компании. Вы можете обновить ваш IBM аккаунт в любое время.

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Information Management
ArticleID=457564
ArticleTitle=Интеграция результатов углубленного анализа данных InfoSphere Warehouse с отчетами IBM Cognos: Часть 2. Обнаружение отклонений с помощью InfoSphere Warehouse и Cognos
publish-date=12182009