книги / Проектирование систем управления технологическими процессами и производствами

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. Компания продолжает совер­ шенствовать свою СУБД для лучшего удовлетворения потребностей хранилищ данных (например, введена побитная индексация).

Решения на основе работы OLAP + SQL-база

OLAP-системы, разрабатываемые для среды “клиент-сервер”, как правило, состояли, с одной стороны, из OLAP-серверов, реализующих хранение и обработку многомерных массивов данных с использова­ нием так называемой OLAP-ьлгшты (MOLAP), а с другой из OLAP- клиентов, которые позволяют пользователям выполнять нужный им анализ на основе результатов запросов к OLAP-серверу. Стоимость одного рабочего места OZ^P-системы измерялась тысячами, а то и десятками тысяч долларов. Только крупные западные корпорации могли позволить себе такие расходы.

Однако, в последнее время ситуация изменилась: в области OLAP-технологии происходит технологический перелом. Во-первых, OLAP-серверы интегрируются в основные реляционные клиент-сер­ верные СУБД, становясь или бесплатными, или почти бесплатными дополнениями. Во-вторых, быстрое развитие рынка ОХЛР-клиентов со встроенной OZyiP-машиной позволяет эффективно реализовать ROLAP, что в конечном итоге ведет к полному отказу от OLAP- серверов.

6.8. Стратегия тестирования программного обеспечения

Отладка программного обеспечения заключается в проверке работоспособности программ в соответствии со спецификацией. До момента проведения отладки программного обеспечения разра­ батывается стратегия тестирования, которая включает:

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

-определение объема тестирования;

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

-проведение нисходящего тестирования;

-проведение восходящего тестирования;

-проведение комплексной отладки программы;

-локализацию и исправление ошибок.

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

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

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

Определение объема тестирования

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

Контрольный лист тестирования

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

-производится описание проверок всех логических конструк­ ций, представленных в спецификации;

-в конструкциях IF - THEN - ELSE проверяются как истинные, так и ложные условия;