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

6.6. Требования к разработке хранилищ данных

Основой любой системы управления являются хранилища дан­ ных (комплекс баз данных). Хранилища данных оказывают серьезное влияние на программирование СУ, так как в процессе програм­ мирования необходимо учитывать структуру хранилища данных, ее содержание, периодичность пополнения и алгоритмы обработки. При разработке хранилищ данных необходимо учитывать следующие основные моменты.

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

вцелом.

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

3.Хранилище данных содержит единообразно представленные данные из всех оперативных баз данных. Эта информация должна максимально полно соответствовать текущему содержанию оператив­ ных баз данных и быть согласованной.

4.Оперативные системы управления проектируются и разраба­ тываются в расчете на решение конкретных задач. Обычно набор запросов к оперативной базе данных становится известным уже на этапе проектирования системы. Информация из базы данных выби­

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

5. Оперативные базы данных по своей природе сильно измен­ чивы. Поэтому при выполнении операций массовой выборки необ­ ходимо использовать быстрые методы индексации, поддерживать упо­ рядоченность информационных массивов, сохранять заранее вычис­ ленные значения агрегатных функций и т.д.

Структурная схема хранилища данных и ее взаимодействие с про­ граммным обеспечением системы оперативной аналитической обработки данных представлена на рис. 6.10.

Рис. 6.10. Структурная схема хранилища данных и ее взаимодействие с программным обеспечением

системы оперативной аналитической обработки данных

К основным требованиям при разработке хранилищ данных систем управления, с точки зрения проектировщика относятся:

- многомерное концептуальное представление данных. Это требование возникает, когда пользователь представляет историю и деятельность своей организации многомерными. OZ/lP-модели должны поддерживать это представление, и, естественно, оно должно хотя бы в какой-то мере опираться на возможности аналитической базы данных;

- прозрачность. Для пользователя не важно, где конкретно расположены средства динамического анализа данных. При раз­ работке OLAP-систем следует придерживаться подхода открытых си­ стем, что позволяет размещать средства анализа на любом узле корпоративной сети;

- доступность. Логическая схема, с которой работает OLAP- система, должна отображаться в схемах разнородных физических хранилищ данных. При доступе к данным должно поддерживаться их единое и согласованное представление;

-согласованная эффективность производства отчетов, которая не должна деградировать при увеличении числа измерений;

-архитектура “клиент-сервер”. Серверная часть OLAP-систе­ мы должна быть достаточно развитой, что позволяет клиентам подключаться к ней с минимальными усилиями и затратами на дополнительное программирование;

-родовая многомерность. Структурные и операционные воз­ можности работы с каждым измерением данных должны быть экви­ валентны. Для всех измерений должна существовать только одна логическая структура. Любая функция, применимая к одному изме­ рению, должна быть применима к любому другому измерению;

-управление динамическими разреженными матрицами. Сервер OLAP-систшы должен эффективно хранить и обрабатывать разреженные матрицы. Физические методы доступа должны быть разнообразны, включая прямое вычисление, Л-деревья или комби­ нации этих методов;

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

-неограниченные операции между измерениями. При выпол­ нении многомерного анализа данных все измерения создаются и об­ рабатываются единообразно. OLAP-систша должна быть в состоянии выполнять соответствующие вычисления между измерениями;

-интуитивное манипулирование данными. Манипуляции должны выполняться с помощью прямого воздействия на элементы OLAP-модели без потребности использовать меню или другие вспомогательные средства;

- гибкая система отчетов. Пользователь должен иметь возмож­ ность манипулировать данными, анализировать и/или синтезировать.

6.7. Технология программирования OLAP для поддержки принятия решений в системах управления

Основные определения

O LAP- это Online Analytical Processing, т.е. оперативный анализ данных. Двенадцать определяющих принципов OLAP сформулировал в 1993 г. Е.Ф. Кодц - “изобретатель” реляционных БД. Позже его определение было переработано в так называемый тест FASMI, требующий, чтобы OZ^P-приложение предоставляло возможности быстрого анализа разделяемой многомерной информации.

Тест FASMI можно расшифровать следующим образом:

-Fast (быстрый), т.е. анализ должен производиться одинаково быстро по всем аспектам информации. Приемлемое время отклика

-5 с или менее;

-Analysis (анализ), т.е. должна быть возможность осущес­

твлять основные типы числового и статистического анализа, предоп­ ределенного разработчиком приложения или произвольно опре­ деляемого пользователем;

-Shared (разделяемой), т.е. множество пользователей должно иметь доступ к данным, при этом необходимо контролировать доступ

кконфиденциальной информации;

-Multidimensional (многомерной) - это основная, наиболее существенная характеристика OLAP\

-Information (информации), т.е. приложение должно иметь возможность обращаться к любой нужной информации, независимо от ее объема и места хранения.

6.7.1 Способы аналитической обработки данных в системах поддержки и принятия решений

Концепции хранения и анализа корпоративных данных

По критерию режима анализа данных информационно-аналити­ ческие системы (ИАС) подразделяются на две категории (табл. 6.1):

1) статические (включающие предопределенный набор сцена­ риев обработки данных и составления отчетов). В эту категорию средств поддержки принятия решений (СППР) входят так называемые информационные системы руководителя (ИСР);

2) динамические (поддерживают построение и выполнение нерегламентированных запросов, а также формирование отчетов произвольной формы).

Таблица 6.1

Сравнение характеристик статического (регламентированного) и динамического анализа

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

Динамические СППР, напротив, ориентированы на обработку нерегламентированных, неожиданных {ad hoc) запросов аналитиков к данным. Работа аналитиков с этими системами заключается в интерактивной последовательности формирования запросов и изучении их результатов, каждый из которых может породить потребность новой серии запросов.

В последние годы в мире оформился ряд новых концепций хранения и анализа корпоративных данных:

-хранилища данных {Data Warehouse);

-оперативная аналитическая обработка данных {On-Line Ana­ lytical Processing, ОLAP);

-интеллектуальный анализ данных - НАД {Data Mining).

Концепция хранилищ данных

Термин “OLAP” неразрывно связан с термином “хранилище данных”. Данные в хранилище попадают из оперативных систем, которые предназначены для автоматизации бизнес-процессов. Кроме того, хранилище может пополняться за счет внешних источников, например статистических отчетов.

Определение хранилищ данных сформулировал Билл Инмон: “Хранилище данныхэто предметно-ориентированное, привязанное ко времени и неизменяемое собрание данных для поддержки процесса принятия управляющих решений”.

Структура хранилища данных приведена на рис. 6.11. Анализировать данные оперативных систем напрямую невоз­

можно или очень затруднительно. Это объясняется различными причинами, в том числе разрозненностью данных, хранением их в

форматах различных СУБД и в разных “уголках” корпоративной сети. Но даже если на предприятии все данные хранятся на центральном сервере БД, что бывает крайне редко, аналитику трудно разобраться в сложных, подчас запутанных структурах БД. Таким образом, задача хранилища - предоставить “сырье” для анализа в одном месте и в простой, понятной структуре.

^Поток данных

Поток метаданных

Рис. 6.11. Структура хранилища данных

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

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

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

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

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

Рассмотренная концепция ориентирована исключительно на хра­ нение, а не на обработку корпоративных данных. Она не предоп­ ределяет архитектуру целевых аналитических систем, а только создает поле деятельности для их функционирования, концентрируясь на требованиях к данным.

Оперативная аналитическая обработка данных

В основе концепции оперативной аналитической обработки {OLAP) лежит многомерное представление данных. Е.Ф. Кодд обо­ значает термином OLAP многомерный способ представления данных исключительно на концептуальном уровне. По мнению Е.Ф. Кодца реляционные БД были, есть и будут наиболее подходящей техно­ логией для хранения корпоративных данных. Необходимость суще­ ствует не в новой технологии БД, а, скорее, в средствах анализа, допол­ няющих функции существующих СУБД и достаточно гибких, чтобы предусмотреть и автоматизировать разные виды интеллектуального анализа, присущие OLAP.

По Кодду, многомерное концептуальное представление {multi­ dimensional conceptual view) является наиболее естественным взгля­ дом управляющего персонала на объект управления. Оно представ­ ляет собой множественную перспективу, состоящую из нескольких независимых измерений, вдоль которых могут быть проанализи­ рованы определенные совокупности данных. Одновременный анализ по нескольким измерениям данных определяется как многомерный анализ.

Как детальные данные, так и агрегаты могут храниться либо в реляционных, либо в многомерных структурах. Многомерное хране­ ние позволяет обращаться с данными как с многомерным массивом, благодаря чему обеспечиваются одинаково быстрые вычисления суммарных показателей и различные многомерные преобразования по любому из измерений. Некоторое время назад OZ^P-продукты поддерживали либо реляционное, либо многомерное хранение. Сегодня, как правило, один и тот же продукт обеспечивает оба этих вида хранения, а также третий вид - смешанный. Применяются следующие термины:

MOLAP {Multidimensional OLAP) - и детальные данные, и агре­ гаты хранятся в многомерной БД. В этом случае получается наиболь­ шая избыточность, так как многомерные данные полностью содержат реляционные;

ROLAP {Relational OLAP) - детальные данные остаются там, где они “жили” изначально в реляционной БД; агрегаты хранятся в той же БД в специально созданных служебных таблицах;

HOLAP {Hybrid CLAP) - детальные данные остаются на месте (в реляционной БД), а агрегаты хранятся в многомерной БД.

Каждый из этих способов имеет свои преимущества и недостатки и должен применяться в зависимости от условий - объема данных, мощности реляционной СУБД и т. д.

Интеллектуальный анализ данных

Data Mining переводится как “добыча” или “раскопка данных” В основу современной технологии Data Mining {discovery-driven data mining) положена концепция шаблонов (паттернов), отражающих фрагменты многоаспектных взаимоотношений в данных. Data Min­ ing - это процесс обнаружения в сырых данных ранее неизвестных, нетривиальных, практически полезных и доступных интерпретации знаний, необходимых для принятия решений в различных сферах человеческой деятельности.

Системы Data Mining применяются по двум основным направ­ лениям:

-массовый продукт для бизнес-приложений;

-инструменты для проведения уникальных исследований (в генетике, химии, медицине и т.п.).

6.7.2 Современные подходы и имеющиеся решения для хранилищ данных

Решение компании IBM

Решение компании Z5Mназывается A Data Warehouse Plus. Целью компании является обеспечение интегрированного набора программных продуктов и сервисов, основанных на единой архи­ тектуре. Основой хранилищ данных является семейство СУБД DB2. Преимуществом IBM является то, что данные, которые нужно извлечь из оперативной базы данных и поместить в хранилище данных, находятся в системах IBM. Поэтому естественна тесная интеграция программных продуктов.

Предлагаются три решения для хранилищ данных:

1)изолированная витрина данных. Предназначена для решения отдельных задач вне связи с общим хранилищем корпорации;

2)зависимая витрина данных. Аналогична изолированной витрине данных, но источники данных находятся под централи­ зованным контролем;

3) глобальное хранилище данных. Корпоративное хранилище данных, которое полностью централизовано контролируется и управ­ ляется. Глобальное хранилище данных может быть централизовано или состоять из нескольких распределенных в сети рынков данных.

Решение компании Oracle

Воснове решения компании Oracle в области хранилищ данных

-два фактора: широкий ассортимент продуктов самой компании и деятельность партнеров в рамках программы Warehouse Technology Initiative. Возможности Oracle в области хранилищ данных обес­ печиваются:

-наличием реляционной СУБД Oracle 8i, которая постоянно совершенствуется для лучшего удовлетворения потребностей храни­ лищ данных;

-существованием набора готовых приложений, обеспечи­ вающих возможности разработки хранилища данных;

-высоким технологическим потенциалом компании в области анализа данных;

-доступностью ряда продуктов, производимых другими ком­ паниями.

Решение компании Hewlett Packard

В компании Hewlett Packard работы, связанные с хранилищами данных, выполняются в рамках программы OpenWarehouse. Выпол­ нение этой программы должно обеспечить возможность построения хранилищ данных на основе мощных компьютеров HP, аппаратуры других производителей и программных компонентов. Основой под­ хода HP являются LWjt-платформы и программный продукт Intelli­ gent Warehouse, который предназначен для управления хранилищами данных. Основа построения хранилищ данных, предлагаемая HP, оставляет свободу выбора реляционной СУБД, средств реинжини­ ринга и т.д.

Решение компании NCR

Стратегия компании NCR направлена на решение проблем корпораций, у которых одинаково сильны потребности и в системах поддержки принятия решений, и в системах оперативной аналити­ ческой обработки данных. Предлагаемая ею архитектура называется

Enterprise Information Factory и основывается на опыте использования системы управления базами данных Teradata и связанных с ней методах параллельной обработки.

Решение компании Informix Software

Стратегия компании в отношение хранилищ данных направлена на расширение рынка для ее продукта On-Line Dinamic Parallel Server. Предлагаемая ею архитектура хранилища данных базируется на реляционных базах данных, программном обеспечении для управ­ ления хранилищем данных, средствах доступа к данным и платформе открытых систем. Три последние компонента разрабатываются пар­ тнерами компании. После выхода Универсального Сервера, в основе которого объектно-реляционный подход, можно ожидать, что и он будет использоваться для построения хранилищ данных.

Решение компании SAS Institute

Компания SAS Institute считает себя поставщиком полного решения по организации хранилища данных. В основе такого подхода:

-обеспечение доступа к данным с возможностью их извле­ чения из самых разнообразных хранилищ данных (и реляционных, и нереляционных);

-преобразование данных и манипулирование ими с исполь­ зованием 4GL;

-наличие сервера многомерных баз данных;

-большой набор методов и средств для аналитической обработки и статистического анализа.

Решение компании Sybase

Стратегия компании Sybase в области хранилищ данных бази­ руется на разработанной ею архитектуре Warehouse WORKS. В основе подхода находится реляционная СУБД Sybase System 11, средство для подключения и доступа к базам данных OmniCONNECT и средство разработки приложений PowerBuilder. Компания продолжает совер­ шенствовать свою СУБД для лучшего удовлетворения потребностей хранилищ данных (например, введена побитная индексация).