- •1Федеральное агентство по образованию
- •1 Общие вопросы теории моделирования
- •1.1 Понятия объекта и его модели
- •Проблемная ситуация.
- •2) Периодическое обсуждение диаграмм, частей модели и модели в целом на техническом совете, решение которого (оформленное в виде протокола) позволяет автору продолжить работу над моделью.
- •1.2 Что собой представляет оригинал?
- •1.3 Проблемная ситуация, подлежащая разрешению Характеристика проблемной ситуации
- •1.4.2 Числовые модели
- •1.4 Классификация математических моделей
- •1.4.1 Классификационные модели
- •1.4.3 Классификация моделей аис по этапам жизненного цикла создания и сопровождения аис
- •1.4.5 Примеры статической и динамической моделей
- •1.4.6 Математическая модель измерительного устройства
- •1.4.7 Оценка погрешности рентгенофлуоресцентного контроля химического состава продукта
- •1.4.8 Общая структура подсистемы контроля и отображения информации
- •1.4.8 Глоссарий 1
- •2 Концептуальная модель автоматизируемого объекта
- •2.1 Содержательное описание объекта и характеристика проблемной ситуации
- •2.2 Морфологическая структура объекта автоматизации
- •2.2 Построение диаграмм потоков данных - dfd
- •2.3 Построение сети бизнес-процессов
- •2.4 Декомпозиция бизнес-процесса
- •2.5 Методика проведения обследования бизнес-процессов компании
- •2.5.1 Обследование общих закономерностей функционирования компании
- •2.5.2 Обследование деятельности каждого автоматизируемого подразделения
- •2.5.3 Детальное обследование бизнес-процессов
- •2.6 Функциональная модель проектируемой организационно-технической системы
- •2.7 Информационно- логическая модель проектируемой системы
- •2.8 Пользовательский интерфейс
- •2.9 Описание интерфейса.
- •2.10 Глоссарий 2
- •3 Моделирование бизнес-процессов
- •3.1 Структурное моделирование
- •3.2 Детальное моделирование бизнес-процессов
- •3.3 Форма запроса данных об общей деятельности организации
- •3.4 Форма запроса данных о выполнении бизнес-процессов подразделениями
- •3.5.4 Табель документооборота
- •3.5.7 Графическая схема документооборота
- •3.6 Состав документов Положения по управлению
- •3.4. Положение по организационной структуре
- •3.7 Состав документов Регламента бизнес-процессов
- •3.8 Классификация бизнес-процессов
- •Характеристики бизнес-процессов
- •3.8.1. Бизнес-процессы (общие сведения)
- •3.8.2. Качественные параметры бизнес-процесса
- •3. 8.3 Бизнес-процессы компании
- •2. Бизнес-процессы ведения основной деятельности.
- •3. Бизнес-процессы вспомогательные.
- •Бизнес-процессы развития и совершенствования
- •3.8. 2 Бизнес-процессы ведения основной деятельности
- •3.8.3. Бизнес-процессы вспомогательные
- •3.9 Бизнес-процесс контроля качества сырья и товарной продукции
- •3.10 Бизнес-процессы мониторинга компьютерной сети предприятия
- •3.11 Бизнес-процессы системы планово-предупредительных ремонтов
- •Глоссарий 3
- •4 Технология обработки и интеграции информации, полученной из различных источников
- •4.1 Зачем аналитикам облегчать доступ к данным?
- •Библиография
- •2. Дюк в. А., Самойленко а. П. Data Mining: учебный курс. - сПб.: Питер, 2001.
4 Технология обработки и интеграции информации, полученной из различных источников
4.1 Зачем аналитикам облегчать доступ к данным?
Технология обработки и интеграции информации, полученной из различных источников, включает в себя три уровня:
- уровень оперативной обработки запросов;
- уровень оперативной аналитической обработки данных;
- уровень поддержки принятия решений об управлении технологическим процессом и ремонтом оборудования.
На первом уровне реализуется функция хранилищ данных, позволяющих сформировать качественную предметно-ориентированную информацию, обеспечить целостность и надежную сохранность информации, ее доступность всем существующим и будущим приложениям. Структура базы данных (БД) и документов хранилищ должна быть инвариантна по отношениям к различным приложениям.
На втором уровне обеспечивается аналитическая переработка данных и осуществляется формирование проблемных (многомерных) БД, служащих основой для проблемно-ориентированных аналитических приложений.
На третьем уровне осуществляется анализ и экспертная оценка информации, ее визуализация, когнитивное и мультимедийное представление в виде, удобном для восприятия специалистами, принимающими решения.
ОчОчевидно, что простой вывод всех контролируемых параметров не позволяет до конца решить основную задачу – своевременное обеспечение оперативного персонала достоверной информацией о процессе. Высокий уровень сложности процесса и технологии и существенно нелинейные характеристики объектов не позволяют даже достаточно квалифицированному персоналу произвести интуитивную оценку сложившейся ситуации. Таким образом, одновременно с детальной и структурированной информацией по отдельным объектам необходимы общие показатели, отражающие текущее состояние
Существует три реальных взаимно дополняемых подхода: пороговый, ресурсный и логический. В данном случае мы здесь не рассматриваем защиты, которые сигнализируют об уже наступившей аварийной ситуации. Задача предупреждения аварийной ситуации заключается в том, чтобы исключить срабатывание этих аварийных защит, т.к. аварийные защиты полностью не исключают возникновение масштабной аварии. Да и само срабатывание аварийных защит приводит к внеплановым остановкам, что, естественно, экономически невыгодно.
Рис. 4.1. Структура хранилища данных Осями многомерной системы координат служат основные атрибуты анализируемого бизнес-процесса.
Итак, пороговый метод, который есть на всех атомных электростанциях – это самый элементарный и фактически самый неэффективный. Пороговая диагностика обеспечивает сигнализацию при выходе аналоговых сигналов за верхнюю уставку, т.е. превышение давления или температуры от номинала. Ресурсный метод обеспечивает двойственный контроль степени износа оборудования и совокупности значений аналоговых параметров на данном оборудовании. Здесь используется простой принцип, что чем труба имеет меньший износ, тем она выдержит большее значение давления и температуры. Поэтому при большем износе конкретного оборудования и конкретного участка трубы должны быть им предписаны меньшие предельные значения контролируемых параметров. Логический метод обеспечивает контроль действий эксплуатационного персонала по управлению электростанцией. Любой ввод в работу оборудования, как и его вывод из работы, проходит строго регламентированные этапы изменения значения соответствующих дискретных сигналов: включил или отключил. Поэтому при изменении значения очередного включателя проверяются состояния смежных включателей и, при необходимости, значения аналоговых параметров. Если логическое условие выполняется, то управление осуществляется, в противном же случае выдаётся сообщение о некорректных действиях с правильной подсказкой. Качественные методы анализа опасностей включают: —предварительный анализ опасностей; — анализ видов и последствий отказов; — анализ опасности и работоспособности; — анализ ошибок персонала; —причинно-следственный анализ; — анализ "дерева отказов" ("дерева причин"); — анализ "дерева событий" ("дерева последствий"); — количественный анализ риска.
|
Расширенное определение совокупности сведений M(D в виде концептов и их взаимосвязей, описывающих предметную область D, имеет следующий вид:
M(D)=(K, k, p, v, R), (4.1)
где К - Kласс – совокупность концептов k1,k2,…,kn которые имеют общие для них свойства. Он представляет собой шаблон при инициализации его концептов.
k - Концепт (атомарная информационная единица) – структурный (условно неделимый) информационный элемент M(D), в котором хранятся сведения об объекте, событии или явлении, относящиеся к предметной области D.
p - Свойство (метод) – идентифицируемая область памяти, ассоциированная с концептом, предназначенная для хранения данных, включённых в данный концепт.
v – Значение свойства – конкретная информация, размещённая в идентифицированной данным свойством области памяти.
R – Связь – представляет собой объект модели M(D), отражающий информационные взаимосвязи между концептами предметной области
Например, источниками исходных данных, используемых для управления сложным технологическим комплексом, являются:
- показания датчиков и результаты экспресс-анализов, содержащие данные о состоянии оборудования и технологического процесса;
- диспетчерские журналы, содержащие заданные значения технологических показателей, а также информацию о событиях,определяющих состояние процесса (аварии, обслуживание и ремонты оборудования, отсутствие используемых ресурсов;
- результаты наблюдений персонала за технологическим процессом.
К экспертным знаниям, уточняющим исходные данные, относятся:
- уравнения материального баланса, связывающие между собой расходы материальных потоков на исследуемом участке;
- характеристики погрешностей измерений материальных потоков;
- перечень материальных потоков, в которых производится непосредственный контроль расходов этих потоков и т.д.
Технология комплексного многомерного анализа данных получила название OLAP (On-Line Analytical Processing). OLAP — это ключевой компонент организации хранилищ данных. Концепция OLAP была описана в 1993 году Эдгаром Коддом, известным исследователем баз данных и автором реляционной модели данных (см. E.F. Codd, S.B. Codd, and C.T.Salley, Providing OLAP (on-line analytical processing) to user-analysts: An IT mandate. Technical report, 1993). В 1995 году на основе требований, изложенных Коддом, был сформулирован так называемый тест FASMI (Fast Analysis of Shared Multidimensional Information — быстрый анализ разделяемой многомерной информации), включающий следующие требования к приложениям для многомерного анализа: · Fast (Быстрый) - предоставление пользователю результатов анализа за приемлемое время (обычно не более 5 с), пусть даже ценой менее детального анализа; · Analysis (Анализ) - возможность осуществления любого логического и статистического анализа, характерного для данного приложения, и его сохранения в доступном для конечного пользователя виде; · Shared (Разделяемой) - многопользовательский доступ к данным с поддержкой соответствующих механизмов блокировок и средств авторизованного доступа; · Multidimensional (Многомерной) - многомерное концептуальное представление данных, включая полную поддержку для иерархий и множественных иерархий (это — ключевое требование OLAP); · Information (Информации) - приложение должно иметь возможность обращаться к любой нужной информации, независимо от ее объема и места хранения. Следует отметить, что OLAP-функциональность может быть реализована различными способами, начиная с простейших средств анализа данных в офисных приложениях и заканчивая распределенными аналитическими системами, основанными на серверных продуктах. OLAP - это не отдельно взятый программный продукт, не язык программирования и даже не конкретная технология. Если постараться охватить OLAP во всех его проявлениях, то это совокупность концепций, принципов и требований, лежащих в основе программных продуктов,
облегчающих
аналитикам доступ к данным.
Для
начала мы выясним, зачем аналитикам
надо как-то специально облегчать доступ
к данным. Дело в том, что аналитики - это
особые потребители корпоративной
информации. Задача
аналитика - находить закономерности в
больших массивах данных.
Поэтому аналитик не будет обращать
внимания на отдельно взятый факт, что
в четверг четвертого числа контрагенту
Чернову была продана партия черных
чернил - ему нужна информация о сотнях
и тысячах подобных событий. Одиночные
факты в базе данных могут заинтересовать,
к примеру, бухгалтера или начальника
отдела продаж, в компетенции которого
находится сделка. Аналитику одной
записи мало - ему, к примеру, могут
понадобиться все сделки данного филиала
или представительства за месяц, год.
Заодно аналитик отбрасывает ненужные
ему подробности вроде ИНН покупателя,
его точного адреса и номера телефона,
индекса контракта и тому подобного. В
то же время данные, которые требуются
аналитику для работы, обязательно
содержат числовые значения - это
обусловлено самой сущностью его
деятельности.
Централизация и удобное
структурирование - это далеко не все,
что нужно аналитику. Ему ведь еще
требуется инструмент для просмотра,
визуализации информации. Традиционные
отчеты, даже построенные на основе
единого хранилища, лишены одного -
гибкости. Их нельзя покрутить”,
“развернуть” или “свернуть”, чтобы
получить желаемое представление данных.
Конечно, можно вызвать программиста, и
он сделает новый отчет достаточно быстро
- скажем, в течение часа. Получается, что
аналитик может проверить за день не
более двух идей. А ему (если он хороший
аналитик) таких идей может приходить в
голову по нескольку в час. И чем больше
“срезов” и “разрезов” данных аналитик
видит, тем больше у него идей, которые,
в свою очередь, для проверки требуют
все новых и новых “срезов”. Вот бы
ему такой инструмент, который позволил
бы разворачивать и сворачивать данные
просто и удобно! В качестве такого
инструмента и выступает OLAP. Компоненты,
входящие в типичное хранилище, представлены
на рис. 4.1. Хотя
OLAP и не представляет собой необходимый
атрибут хранилища данных, он все чаще
и чаще применяется для анализа накопленных
в этом хранилище сведений.
С
труктура
хранилища данных.
Оперативные данные
собираются из различных источников,
очищаются, интегрируются и складываются
в реляционное хранилище. При этом они
уже доступны для анализа при помощи
различных средств построения отчетов.
Затем данные (полностью или частично)
подготавливаются для OLAP-анализа. Они
могут быть загружены в специальную БД
OLAP или оставлены в реляционном хранилище.
Важнейшим его элементом являются
метаданные, т. е. информация о структуре,
размещении и трансформации данных.
Благодаря ним обеспечивается эффективное
взаимодействие различных компонентов
хранилища.Подытоживая, можно определить
OLAP как совокупность средств многомерного
анализа данных, накопленных в хранилище.
Теоретически средства OLAP можно применять
и непосредственно к оперативным данным
или их точным копиям (чтобы не мешать
оперативным пользователям). Но мы тем
самым рискуем наступить на уже описанные
выше грабли, то есть начать анализировать
оперативные данные, которые напрямую
для анализа непригодны.
Таблица 4. 1 Определяющие принципы OLAP
1 |
Многомерное представление данных |
Средства должны поддерживать многомерный на концептуальном уровне взгляд на данные. |
2 |
Прозрачность |
Пользователь не должен знать о том, какие конкретные средства используются для хранения и обработки данных, как данные организованы и откуда они берутся. |
3 |
Доступность |
Средства должны сами выбирать и связываться с наилучшим для формирования ответа на данный запрос источником данных. Средства должны обеспечивать автоматическое отображение их собственной логической схемы в различные гетерогенные источники данных. |
4 |
Согласованная производительность |
Производительность практически не должна зависеть от количества Измерений в запросе. |
5 |
Поддержка архитектуры клиент-сервер |
Средства должны работать в архитектуре клиент-сервер. |
6 |
Равноправность всех измерений |
Ни одно из измерений не должно быть базовым, все они должны быть равноправными (симметричными). |
7 |
Динамическая обработка разреженных матриц |
Неопределенные значения должны храниться и обрабатываться наиболее эффективным способом. |
8 |
Поддержка многопользовательского режима работы с данными |
Средства должны обеспечивать возможность работать более чем одному пользователю. |
9 |
Поддержка операций на основе различных измерений |
Все многомерные операции (например, Агрегация) должны единообразно и согласованно применяться к любому числу любых измерений. |
10 |
Простота манипулирования данными |
Средства должны иметь максимально удобный, естественный и комфортный пользовательский интерфейс. |
11 |
Развитые средства представления данных |
Средства должны поддерживать различные способы визуализации (представления) данных. |
12 |
Неограниченное число измерений и уровней агрегации данных |
Не должно быть ограничений на число поддерживаемых Измерений. |
4.2 Что такое хранилище данных? Информационные системы масштаба предприятия, как правило, содержат приложения, предназначенные для комплексного многомерного анализа данных, их динамики, тенденций и т.п. Такой анализ в конечном итоге призван содействовать принятию решений. Нередко эти системы так и называются — системы поддержки принятия решений. Принять любое управленческое решение невозможно не обладая необходимой для этого информацией, обычно количественной. Для этого необходимо создание хранилищ данных (Data warehouses), то есть процесс сбора, отсеивания и предварительной обработки данных с целью предоставления результирующей информации пользователям для статистического анализа (а нередко и создания аналитических отчетов). Ральф Кимбалл (Ralph Kimball), один из авторов концепции хранилищ данных, описывал хранилище данных как "место, где люди могут получить доступ к своим данным" (см., например, Ralph Kimball, "The Data Warehouse Toolkit: Practical Techniques for Building Dimensional Data Warehouses", John Wiley & Sons, 1996 и "The Data Web house Toolkit: Building the Web-Enabled Data Warehouse", John Wiley & Sons, 2000). Он же сформулировал и основные требования к хранилищам данных: · поддержка высокой скорости получения данных из хранилища; · поддержка внутренней непротиворечивости данных; · возможность получения и сравнения так называемых срезов данных (slice and dice); · наличие удобных утилит просмотра данных в хранилище;
· полнота и достоверность хранимых данных; · поддержка качественного процесса пополнения данных. Удовлетворять всем перечисленным требованиям в рамках одного и того же продукта зачастую не удается. Поэтому для реализации хранилищ данных обычно используется несколько продуктов, одни их которых представляют собой собственно средства хранения данных, другие — средства их извлечения и просмотра, третьи — средства их пополнения и т.д. Типичное хранилище данных, как правило, отличается от обычной реляционной базы данных. Во-первых, обычные базы данных предназначены для того, чтобы помочь пользователям выполнять повседневную работу, тогда как хранилища данных предназначены для принятия решений. Например, продажа товара и выписка счета производятся с использованием базы данных, предназначенной для обработки транзакций, а анализ динамики продаж за несколько лет, позволяющий спланировать работу с поставщиками, — с помощью хранилища данных. Во-вторых, обычные базы данных подвержены постоянным изменениям в процессе работы пользователей, а хранилище данных относительно стабильно: данные в нем обычно обновляются согласно расписанию (например, еженедельно, ежедневно или ежечасно — в зависимости от потребностей). В идеале процесс пополнения представляет собой просто добавление новых данных за определенный период времени без изменения прежней информации, уже находящейся в хранилище. И, в-третьих, обычные базы данных чаще всего являются источником данных, попадающих в хранилище. Кроме того, хранилище может пополняться за счет внешних источников, например статистических отчетов.
Типичная структура хранилища данных существенно отличается от структуры обычной реляционной СУБД. Как правило, эта структура денормализована (это повышает скорость выполнения запросов) и может допускать избыточность данных. Типичная структура хранилища данных приведена на рис. 1. Основные составляющие этой структуры - таблица фактов (fact table) и таблицы измерений (dimension tables).
Таблица фактов (в примере на рис. 4.2 она называется Sales_Fact) - это основная таблица хранилища данных. Как правило, в нее входят сведения об объектах или событиях, совокупность которых будет в дальнейшем анализироваться. Обычно такая таблица содержит уникальный составной ключ, объединяющий первичные ключи таблиц измерений. Чаще всего это целочисленные значения либо значения типа "дата/время" - ведь таблица фактов может содержать сотни тысяч или даже миллионы записей, и хранить в ней повторяющиеся текстовые описания, как правило, невыгодно. Помимо этого таблица фактов содержит одно или несколько числовых полей, на основании которых в процессе выполнения аналитических запросов получаются агрегатные данные. Отметим, что в таблице фактов нет никаких сведений о том, как группировать записи при вычислении агрегатных данных. Эти сведения содержатся в таблицах измерений. Таблицы измерений содержат неизменяемые либо редко изменяемые данные. В них имеется как минимум одно описательное поле и, как правило, целочисленное ключевое поле (обычно это суррогатный ключ). Нередко (но не всегда) таблица измерений может содержать и поля, указывающие на дополнительные атрибуты, имевшиеся в исходной оперативной базе данных, или на атрибуты, ответственные за группировку ее собственных данных. Каждая таблица измерений должна находиться в отношении "один ко многим" с таблицей фактов. Отметим, что скорость роста таблиц измерений должна быть незначительной по сравнению со скоростью роста таблицы фактов; например, новая запись в таблицу измерений, характеризующую товары, добавляется только при появлении нового, не продававшегося ранее товара. В состав современных средств проектирования данных, таких, как CA AllFusion Modelling Suite, обычно входят шаблоны для проектирования хранилищ данных. Следует сказать, что для создания реляционных хранилищ данных иногда применяются специализированные СУБД, хранение данных в которых оптимизировано с точки зрения скорости выполнения запросов. Пример такого продукта - Sybase Adaptive Server IQ, реализующий нетрадиционный способ хранения данных в таблицах. Однако создавать хранилища можно и в обычных реляционных СУБД.
Многомерные хранилища данных составляют основу OLAP-средств (On-Line Analytical Processing), предназначенных для комплексного многомерного анализа данных. Концепция OLAP была описана в 1993 г. Э. Ф. Коддом, автором реляционной модели данных, и в настоящее время поддержка OLAP реализована во многих СУБД и средствах анализа данных. Многомерные хранилища обычно содержат агрегатные данные (например, суммы, средние значения, количество значений) для различных выборок. Чаще всего такие агрегатные функции образуют многомерный набор данных, называемый кубом, оси которого (называемые измерениями) содержат параметры, а ячейки - зависящие от них агрегатные данные (иногда их называют мерами). Вдоль каждой оси данные могут быть организованы в иерархии, отражающие различные уровни их детализации. Как правило, агрегатные данные получаются путем выполнения серии запросов на группировку данных типа:
Число осей куба обычно совпадает с количеством полей для группировки (рис. 4.3).
Отметим, что довольно часто в качестве источника данных для подобных запросов выступают реляционные хранилища данных. В этом случае таблицы измерений, как правило, содержат исходные данные для формирования измерений куба, а таблица фактов - исходные данные для вычисления мер куба. В многомерных хранилищах данных содержатся агрегатные данные различной степени подробности, например, объемы продаж по дням, месяцам, годам, по категориям товаров и т. п. Цель хранения агрегатных данных - сократить время выполнения запросов, поскольку в большинстве случаев для анализа и прогнозов интересны не детальные, а суммарные данные. Однако сохранение всех агрегатных данных не всегда оправданно - ведь при добавлении новых измерений объем данных, составляющих куб, растет экспоненциально (иногда говорят о "взрывном росте" объема данных). Для решения проблемы "взрывного роста" применяются разнообразные схемы, позволяющие при вычислении далеко не всех возможных агрегатных данных достичь приемлемой скорости выполнения запросов. Как исходные, так и агрегатные данные могут храниться либо в реляционных, либо в многомерных структурах. Поэтому в настоящее время применяются три способа хранения данных:
Некоторые OLAP-средства поддерживают хранение данных только в реляционных структурах, некоторые - только в многомерных. Однако большинство современных серверных OLAP-средств поддерживают все три способа хранения данных. Выбор способа хранения зависит от объема и структуры исходных данных, требований к скорости выполнения запросов и частоты обновления OLAP-кубов. Выпущенные в течение последних лет СУБД ведущих производителей - IBM, Microsoft, Oracle, содержат средства для создания многомерных хранилищ данных (эта традиция была начата несколько лет назад корпорацией Microsoft, включившей OLAP-сервер в состав SQL Server 7.0). Существуют и отдельные продукты для создания OLAP-хранилищ - их выпускают компании Hyperion, Sybase, Business Objects и некоторые другие. 4.4 Data Mining Термином Data Mining (mining в переводе с английского означает "добыча полезных ископаемых") обозначают процесс поиска корреляций, тенденций, взаимосвязей и закономерностей между данными посредством различных математических и статистических алгоритмов: кластеризации, создания субвыборок, регрессионного и корреляционного анализа. Примерами искомой информации могут служить сведения о том, какие категории покупателей чаще всего приобретают тот или иной товар, какая часть покупателей одного конкретного товара приобретает другой конкретный товар, какая категория клиентов чаще всего вовремя не выплачивает предоставленный кредит. Подобного рода информация обычно используется при прогнозировании, стратегическом планировании, анализе рисков, и ценность ее для предприятия очень высока. Отметим, что традиционная математическая статистика и OLAP-средства не всегда годятся для решения таких задач. Обычно статистические методы и OLAP используют для проверки заранее сформулированных гипотез, но нередко именно формулирование гипотезы оказывается самой сложной задачей при проведении бизнес-анализа для последующего принятия решений, поскольку далеко не все закономерности в данных очевидны с первого взгляда. В основу современной технологии Data Mining положена концепция шаблонов, отражающих закономерности, свойственные подвыборкам данных. Поиск шаблонов выполняется методами, не использующими никаких исходных предположений об этих подвыборках. Если при статистическом анализе или при применении OLAP обычно формулируются вопросы типа "Каково среднее число клиентов банка, не вернувших вовремя кредит, среди неженатых мужчин от 40 до 50 лет?", то применение Data Mining, как правило, подразумевает ответы на вопросы типа "Существует ли типичная категория клиентов, не возвращающих вовремя кредиты?". При этом именно ответ на второй вопрос нередко обеспечивает принятие успешного бизнес-решения. Важная особенность Data Mining - нестандартность и неочевидность разыскиваемых шаблонов. Иными словами, средства Data Mining отличаются от инструментов статистической обработки данных и средств OLAP тем, что вместо проверки заранее предполагаемых пользователями взаимозависимостей они на основании имеющихся данных способны находить такие взаимозависимости самостоятельно и строить гипотезы об их характере. Однако применение средств Data Mining не исключает использования статистических инструментов и OLAP-средств, поскольку результаты обработки данных с помощью последних, как правило, способствуют лучшему пониманию характера закономерностей, которые следует искать. Поэтому существуют средства Data Mining, способные выполнять поиск закономерностей, корреляций и тенденций и в реляционных, и в многомерных хранилищах данных. Обычно выделяют пять стандартных типов закономерностей, выявляемых методами Data Mining:
Сегодня существует довольно большое количество разнообразных методов исследования данных, среди которых можно выделить следующие. Регрессионный, дисперсионный и корреляционный анализ - реализован в большинстве современных статистических пакетов, в частности, в продуктах компаний SAS Institute, StatSoft и т. д. Методы анализа в конкретной предметной области, базирующиеся на эмпирических моделях. Часто применяются, например, в недорогих средствах финансового анализа. Нейросетевые алгоритмы, идея которых основана на аналогии с функционированием нервной ткани и заключается в том, что исходные параметры рассматриваются как сигналы, преобразующиеся в соответствии с имеющимися связями между "нейронами", а в качестве ответа (результата анализа) рассматривается отклик всей сети на исходные данные. Связи в этом случае создаются с помощью так называемого обучения сети посредством выборки большого объема, содержащей как исходные данные, так и правильные ответы. Метод "ближайшего соседа" - выбор близкого аналога исходных данных из уже имеющихся накопленных данных. Деревья решений - иерархическая структура, базирующаяся на наборе вопросов, подразумевающих ответ "да" или "нет"; хотя этот способ обработки данных далеко не всегда идеально находит существующие закономерности, он довольно часто используется в системах прогнозирования в силу наглядности получаемого ответа (рис. 4.4).
Кластерные модели (иногда также называемые моделями сегментации) применяются для объединения сходных событий в группы на основании сходных значений нескольких полей в наборе данных; также весьма популярны при создании систем прогнозирования (рис. 4.5).
Алгоритмы ограниченного перебора - вычисляют частоты комбинаций простых логических событий в подгруппах данных. Эволюционное программирование - поиск и генерация алгоритма, выражающего взаимозависимость данных, на основании изначально заданного алгоритма, модифицируемого в процессе поиска; иногда поиск взаимозависимостей проводится среди каких-либо определенных видов функций (например, полиномов). Средства Data Mining традиционно относятся к дорогостоящим программным инструментам - цена некоторых из них доходит до нескольких десятков тысяч долларов. Поэтому до недавнего времени основными потребителями этой технологии были банки, финансовые и страховые компании, крупные торговые предприятия, а основными задачами, требующими применения Data Mining, считались оценка кредитных и страховых рисков и выработка маркетинговой политики, тарифных планов и иных принципов работы с клиентами. В последние годы ситуация несколько изменилась: на рынке ПО появились относительно недорогие инструменты Data Mining от нескольких производителей (в том числе от Microsoft), что сделало эту технологию доступной для предприятий малого и среднего бизнеса, ранее о ней и не помышлявших. 4.5 Средства визуализации OLAP-данных и результатов Data Mining Универсальные средства визуализации OLAP-данных выпускают многие компании, такие, как Business Objects, Cognos, Panorama, ProClarity. Как правило, эти инструменты рассчитаны на пользователей, обладающих определенными познаниями в области баз данных и статистических методов анализа. Обычно подобные инструменты позволяют обращаться к хранилищам данных и OLAP-источникам различных производителей (например, к многомерным хранилищам на основе СУБД Oracle, Microsoft и IBM), получать срезы многомерных данных и строить на их основе диаграммы. Зачастую производители этих инструментов поставляют также middleware-серверы, предназначенные для выполнения анализа данных и предоставления результатов для отображения в клиентских приложениях, а также средства создания решений на основе клиентских инструментов и middleware-серверов (например, библиотеки классов или элементы управления ActiveX). Учитывая, что ситуация со стандартами в области бизнес-аналитики все еще далека от идеальной (в отличие от реляционных СУБД, для многомерных СУБД пока нет ни общепринятого стандарта языка запросов, аналогичного языку SQL, ни универсальных механизмов доступа к данным, аналогичных ODBC или OLEDB), применение подобных средств может в той или иной степени решить проблему создания аналитических приложений в компаниях, использующих СУБД и OLAP-средства от нескольких различных производителей. Производители OLAP-средств, в частности, Oracle и IBM, нередко сами выпускают рассчитанные на пользователей клиентские приложения для доступа к OLAP-хранилищам, созданным на основе их же серверных средств. Так, у корпорации Oracle имеется даже несколько таких продуктов, объединенных в пакет Oracle Business Intelligence. Кроме того, в последнее время получили широкое распространение дополнительные модули для электронных таблиц, предназначенные для визуализации OLAP-данных. Так, средства отображения данных аналитических служб Microsoft SQL Server доступны пользователям Microsoft Excel 2000 и более поздних версий, а компании Oracle и Hyperion выпускают встраиваемые в тот же Excel дополнительные модули доступа к собственным OLAP-хранилищам. Стоит отметить и расширение в последние годы спектра аналитических продуктов, ориентированных на обслуживание определенных отраслей (например, розничной или оптовой торговли, финансовых услуг). Их выпускают и перечисленные выше компании, и ряд других производителей, в частности, поставщики систем управления предприятиями и других отраслевых бизнес-приложений. 4.6 Средства генерации отчетов Отчет представляет собой документ, содержимое которого динамически формируется на основе информации, содержащейся в базе данных. На рынке ПО сейчас представлено немало средств создания отчетов: как отдельных продуктов, так и входящих в состав средств разработки приложений или СУБД, и реализованных в виде либо серверных служб, либо клиентских приложений. Как правило, средства создания отчетов поддерживают широкий спектр универсальных механизмов доступа к данным (ODBC, OLE DB, ADO.NET), нередко - средства прямого доступа к наиболее популярным СУБД с помощью их клиентских API, содержат средства деловой графики, интегрируются с офисными приложениями, позволяют публиковать отчеты в Интернете, включают классы или компоненты, предназначенные для создания приложений, реализующих (наряду с другими возможностями) генерацию отчетов. Безусловный лидер рынка средств создания отчетов - продукт Crystal Reports, принадлежащий компании Business Objects. Он поставляется как отдельно, так и в составе продуктов других производителей, начиная со средств разработки приложений и заканчивая геоинформационными системами. Существует и серверная версия этого продукта, предназначенная для обеспечения отчетами большого количества пользователей. Помимо Crystal Reports, существует несколько менее популярных продуктов подобного класса. В настоящем обзоре мы рассмотрели основные технологии, лежащие в основе современных аналитических приложений. Как видно, выбор и технологий, и реализующих их продуктов достаточно широк, особенно с учетом факта наличия подобных средств в составе современных серверных СУБД и широкого спектра клиентских средств для визуализации результатов анализа и создания аналитических отчетов. Тем не менее отсутствие общепринятых стандартов в области бизнес-аналитики пока что создает определенные проблемы при создании использующих ее решений. 4.7 Глоссарий 4 Технология обработки и интеграции информации, полученной из различных источников, включает в себя три уровня: - уровень оперативной обработки запросов; - уровень оперативной аналитической обработки данных; - уровень поддержки принятия решений об управлении технологическим процессом и ремонтом оборудования. Задача аналитика - находить закономерности в больших массивах данных OLAP- (Online Analytical Processing), т. е. оперативный анализ данных OLAP - это совокупность концепций, принципов и требований, лежащих в основе программных продуктов, облегчающих аналитикам доступ к данным. Fast (Быстрый) - анализ должен производиться одинаково быстро по всем аспектам информации. Приемлемое время отклика - 5 с или менее. Analysis (Анализ) - должна быть возможность осуществлять основные типы числового и статистического анализа, предопределенного разработчиком приложения или произвольно определяемого пользователем. Shared (Разделяемый) - множество пользователей должно иметь доступ к данным, при этом необходимо контролировать доступ к конфиденциальной информации. Multidimensional (Многомерный) - это основная, наиболее существенная характеристика OLAP. Хранилища данных должны обеспечивать высокую скорость получения данных, возможность получения и сравнения, так называемых срезов данных, а также непротиворечивость, полноту и достоверность данных. OLAP (On-Line Analytical Processing) является ключевым компонентом построения и применения хранилищ данных. Эта технология основана на построении многомерных наборов данных — OLAP-кубов, оси которого содержат параметры, а ячейки — зависящие от них агрегатные данные. Создание хранилищ данных (Data warehouses)- процесс сбора, отсеивания и предварительной обработки данных с целью предоставления результирующей информации пользователям для статистического анализа (а нередко и создания аналитических отчетов). Data Mining - процесс поиска корреляций, тенденций, взаимосвязей и закономерностей между данными посредством различных математических и статистических алгоритмов: кластеризации, создания субвыборок, регрессионного и корреляционного анализа. Концепт (атомарная информационная единица) – структурный (условно неделимый) информационный элемент M(D), в котором хранятся сведения об объекте, событии или явлении, относящиеся к предметной области D. |
