Зачем аналитикам облегчать доступ к данным?

Технология обработки и интеграции информации, полученной из различных источников, включает в себя три уровня:

- уровень оперативной обработки запросов;

- уровень оперативной аналитической обработки данных;

- уровень поддержки принятия решений об управлении технологическим процессом и ремонтом оборудования.

На первом уровне реализуется функция хранилищ данных, позволяющих сформировать качественную предметно-ориентированную информацию, обеспечить целостность и надежную сохранность информации, ее доступность всем существующим и будущим приложениям. Структура базы данных (БД) и документов хранилищ должна быть инвариантна по отношениям к различным приложениям.

На втором уровне обеспечивается аналитическая переработка данных и осуществляется формирование проблемных (многомерных) БД, служащих основой для проблемно-ориентированных аналитических приложений.

На третьем уровне осуществляется анализ и экспертная оценка информации, ее визуализация, когнитивное и мультимедийное представление в виде, удобном для восприятия специалистами, принимающими решения.

ОчОчевидно, что простой вывод всех контролируемых параметров не позволяет до конца решить основную задачу – своевременное обеспечение оперативного персонала достоверной информацией о процессе. Высокий уровень сложности процесса и технологии и существенно нелинейные характеристики объектов не позволяют даже достаточно квалифицированному персоналу произвести интуитивную оценку сложившейся ситуации. Таким образом, одновременно с детальной и структурированной информацией по отдельным объектам необходимы общие показатели, отражающие текущее состояние 3 Диагностическая информационная поддержка ЛПР, существующая в современных АСУТП, основана на событийно-ориентированном подходе и требует больших трудозатрат при своем проектировании и отладке. Те неисправности, которые не были учтены при проектировании, или возникают одновременно, или развиваются не так, как предполагалось, не могут быть адекватно распознаны, либо могут быть распознаны неверно, что недопустимо для производства в целом и отдельно взятых технологических переделов и агрегатов. Существует три реальных взаимно дополняемых подхода: пороговый, ресурсный и логический. В данном случае мы здесь не рассматриваем защиты, которые сигнализируют об уже наступившей аварийной ситуации. Задача предупреждения аварийной ситуации заключается в том, чтобы исключить срабатывание этих аварийных защит, т.к. аварийные защиты полностью не исключают возникновение масштабной аварии. Да и само срабатывание аварийных защит приводит к внеплановым остановкам, что, естественно, экономически невыгодно.   Рис. 4.1. Структура хранилища данных Осями многомерной системы координат служат основные атрибуты анализируемого бизнес-процесса.     Итак, пороговый метод, который есть на всех атомных электростанциях – это самый элементарный и фактически самый неэффективный. Пороговая диагностика обеспечивает сигнализацию при выходе аналоговых сигналов за верхнюю уставку, т.е. превышение давления или температуры от номинала. Ресурсный метод обеспечивает двойственный контроль степени износа оборудования и совокупности значений аналоговых параметров на данном оборудовании. Здесь используется простой принцип, что чем труба имеет меньший износ, тем она выдержит большее значение давления и температуры. Поэтому при большем износе конкретного оборудования и конкретного участка трубы должны быть им предписаны меньшие предельные значения контролируемых параметров. Логический метод обеспечивает контроль действий эксплуатационного персонала по управлению электростанцией. Любой ввод в работу оборудования, как и его вывод из работы, проходит строго регламентированные этапы изменения значения соответствующих дискретных сигналов: включил или отключил. Поэтому при изменении значения очередного включателя проверяются состояния смежных включателей и, при необходимости, значения аналоговых параметров. Если логическое условие выполняется, то управление осуществляется, в противном же случае выдаётся сообщение о некорректных действиях с правильной подсказкой. Качественные методы анализа опасностей включают: —предварительный анализ опасностей; — анализ видов и последствий отказов; — анализ опасности и работоспособности; — анализ ошибок персонала; —причинно-следственный анализ; — анализ " дерева отказов" (" дерева причин" ); — анализ " дерева событий" (" дерева последствий" ); — количественный анализ риска. 4 Причинно-следственный анализ выявляет причины происшедшей аварии. Он завершается прогнозом новых аварий и составлением плана мероприятий по их предупреждению. Метод включает этапы составления перечня реальных событий, предшествовавших аварии; построения ориентированного графа в виде " дерева причин", начиная с последней стадии развития событий; выявления логических связей " дерева причин"; формулирования предупредительных мер с целью исключения повторения аварии или для избежания аналогичных аварий. Анализ опасностей с помощью " дерева причин" потенциальной аварии или идентичного ему " дерева отказов" позволяет выявить комбинации отказов (неполадок) оборудования, ошибок персонала и внешних (техногенных, природных) воздействий, приводящих к основному

 

Расширенное определение совокупности сведений M^(D в виде концептов и их взаимосвязей, описывающих предметную область D, имеет следующий вид:

M^(D)=(K, k, p, v, R), (4.1)

где К - Kласс – совокупность концептов k₁, k₂, …, k_n которые имеют общие для них свойства. Он представляет собой шаблон при инициализации его концептов.

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

	Многомерное представление данных	Средства должны поддерживать многомерный на концептуальном уровне взгляд на данные.
	Прозрачность	Пользователь не должен знать о том, какие конкретные средства используются для хранения и обработки данных, как данные организованы и откуда они берутся.
	Доступность	Средства должны сами выбирать и связываться с наилучшим для формирования ответа на данный запрос источником данных. Средства должны обеспечивать автоматическое отображение их собственной логической схемы в различные гетерогенные источники данных.
	Согласованная производительность	Производительность практически не должна зависеть от количества Измерений в запросе.
	Поддержка архитектуры клиент-сервер	Средства должны работать в архитектуре клиент-сервер.
	Равноправность всех измерений	Ни одно из измерений не должно быть базовым, все они должны быть равноправными (симметричными).
	Динамическая обработка разреженных матриц	Неопределенные значения должны храниться и обрабатываться наиболее эффективным способом.
	Поддержка многопользовательского режима работы с данными	Средства должны обеспечивать возможность работать более чем одному пользователю.
	Поддержка операций на основе различных измерений	Все многомерные операции (например, Агрегация) должны единообразно и согласованно применяться к любому числу любых измерений.
	Простота манипулирования данными	Средства должны иметь максимально удобный, естественный и комфортный пользовательский интерфейс.
	Развитые средства представления данных	Средства должны поддерживать различные способы визуализации (представления) данных.
	Неограниченное число измерений и уровней агрегации данных	Не должно быть ограничений на число поддерживаемых Измерений.

 

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. Пример структуры хранилища данных.   Таблица фактов (в примере на рис. 4.2 она называется Sales_Fact) - это основная таблица хранилища данных. Как правило, в нее входят сведения об объектах или событиях, совокупность которых будет в дальнейшем анализироваться. Обычно такая таблица содержит уникальный составной ключ, объединяющий первичные ключи таблиц измерений. Чаще всего это целочисленные значения либо значения типа " дата/время" - ведь таблица фактов может содержать сотни тысяч или даже миллионы записей, и хранить в ней повторяющиеся текстовые описания, как правило, невыгодно. Помимо этого таблица фактов содержит одно или несколько числовых полей, на основании которых в процессе выполнения аналитических запросов получаются агрегатные данные. Отметим, что в таблице фактов нет никаких сведений о том, как группировать записи при вычислении агрегатных данных. Эти сведения содержатся в таблицах измерений. Таблицы измерений содержат неизменяемые либо редко изменяемые данные. В них имеется как минимум одно описательное поле и, как правило, целочисленное ключевое поле (обычно это суррогатный ключ). Нередко (но не всегда) таблица измерений может содержать и поля, указывающие на дополнительные атрибуты, имевшиеся в исходной оперативной базе данных, или на атрибуты, ответственные за группировку ее собственных данных. Каждая таблица измерений должна находиться в отношении " один ко многим" с таблицей фактов. Отметим, что скорость роста таблиц измерений должна быть незначительной по сравнению со скоростью роста таблицы фактов; например, новая запись в таблицу измерений, характеризующую товары, добавляется только при появлении нового, не продававшегося ранее товара. В состав современных средств проектирования данных, таких, как CA AllFusion Modelling Suite, обычно входят шаблоны для проектирования хранилищ данных. Следует сказать, что для создания реляционных хранилищ данных иногда применяются специализированные СУБД, хранение данных в которых оптимизировано с точки зрения скорости выполнения запросов. Пример такого продукта - Sybase Adaptive Server IQ, реализующий нетрадиционный способ хранения данных в таблицах. Однако создавать хранилища можно и в обычных реляционных СУБД. ⇐ Предыдущая3456789101112Следующая ⇒ Поделиться:

Последнее изменение этой страницы: 2017-04-12; Просмотров: 412; Нарушение авторского права страницы