Open Library - открытая библиотека учебной информации. Средства OLTP-технологии


Характеристики OLTP системы Большой объем информации Часто различные БД для разных подразделений Нормализованная схема, отсутствие дублирования информации Интенсивное изменение данных Транзакционный режим работы Транзакции затрагивают небольшой объем данных Обработка текущих данных – мгновенный снимок Много клиентов Малое время отклика – несколько секунд Характеристики OLAP системы Большой объем информации Синхронизированная информация из различных БД с использованием общих классификаторов Ненормализованная схема БД с дубликатами Данные меняются редко, Изменение происходит через пакетную загрузку Выполняются сложные нерегламентированные запросы над большим объемом данных с широким применением группировок и агрегатных функций. Анализ временных зависимостей Небольшое количество работающих пользователей – аналитики и менеджеры Большее время отклика (но все равно приемлемое) – несколько минут






Правила Кодда для реляционных БД 1. Правило информации. 2. Правило гарантированного доступа. 3. Правило поддержки недействительных значений. 4. Правило динамического каталога, основанного на реляционной модели. 5.Правило исчерпывающего подъязыка данных. 6. Правило обновления представлений. 7. Правило добавления, обновления и удаления. 8. Правило независимости физических данных. 9. Правило независимости логических данных. 10. Правило независимости условий целостности. 11. Правило независимости распространения. 12. Правило единственности.


Правила Кодда для OLAP 1. Концептуальное многомерное представление. 2. Прозрачность. 3. Доступность. 4. Постоянная производительность при разработке отчетов. 5. Клиент-серверная архитектура. 6. Общая многомерность. 7. Динамическое управление разреженными матрицами. 8. Многопользовательская поддержка. 9. Неограниченные перекрестные операции. 10. Интуитивная манипуляция данными. 11. Гибкие возможности получения отчетов. 12. Неограниченная размерность и число уровней агрегации.


Реализация OLAP Типы OLAP - серверов MOLAP (Multidimensional OLAP) - и детальные данные, и агрегаты хранятся в многомерной БД. ROLAP (Relational OLAP) - детальные данные храняться в реляционной БД; агрегаты хранятся в той же БД в специально созданных служебных таблицах. HOLAP (Hybrid OLAP) - детальные данные храняться в реляционной БД, а агрегаты хранятся в многомерной БД.








Особенности ROLAP – схемы типа звезда 1.Одна таблица фактов, которая сильно денормализована 2.Несколько таблиц измерений, которые также денормализованы 3.Первичный ключ таблицы фактов является составным и имеет по одному столбцу на каждое измерение 4.Агрегированные данные храняться совместно с исходными Недостатки Если агрегаты храняться совместно с исходными данными, то в измерениях необходимо использовать дополнительный параметр – уровень иерархии











Структура хранилища в ORACLE СУБД SQL клиентMOLAP клиент Java API JDBC OCI ODBC OLE DB CWM или CWM2 Хранилище OLAP (BLOB в реляционной таблице) Схема звезда Регистрация метаданных Многомерное ядро (процесс в ядре ORACLE) OLAP DML SQL интерфейс к OLAP (DBMS_AW, OLAP_TABLE, …) Многомерные метаданные

Принимая во внимание все перечисленное, сравнение между различными MDDпродуктами можно проводить только по самым обобщенным категориям. В более дешевом секторе рынка присутствуют лишь однопользовательские и предназначенные для небольших локальных сетей средства просмотра многомерных данных. Хотя они обладают довольно высоким уровнем функциональных возможностей и удобны в использовании, эти системы ограниченны по своему масштабу. и им недостает средств, необходимых для реализации OLAPобработки в широком смысле. В данную категорию попадают такие продукты, как PowerPlay корпорации Cognos, PaBlo фирмы Andyne и Mercury компании Business Objects. Дорогой же сектор рынка представлен системами Acumate ES фирмы Kenan Technologies, Express корпорации Oracle, Gentium компании Planning Sciences и Holos фирмы

Holistic Systems. Они настолько разнятся по своим возможностям, что любую из них можно смело выделять в отдельную категорию. И наконец, MDD-системы в чистом виде: Essbase корпорации Arbor Software, LightShip Server фирмы Pilot Software и TM/1 компании Sinper .

Второй класс OLAP-средств -реляционные OLAP-системы (ROLAP). Здесь для хранения данных используются старые реляционные СУБД, а между БД и клиентским интерфейсом организуется определяемый администратором системы слой метаданных. Через этот промежуточный слой клиентский компонент может взаимодействовать с реляционной БД как с многомерной. Подобно средствам первого класса, ROLAP-системы хорошо приспособлены для работы с крупными информационными хранилищами, требуют значительных затрат обслуживания специалистами информационных подразделений и предусматривают работу в многопользовательском режиме. Среди продуктов этого типа - IQ/Vision корпорации IQ Software, DSS/Server и DSS/Agent фирмы MicroStrategy и DecisionSuite компании Information Advantage.

ROLAP-средства реализуют функции поддержки принятия решений в надстройке над реляционным процессором БД.

Такие программные продукты должны отвечать ряду требований,

в частности:

- иметь мощный оптимизированный для OLAP генератор SQLвыражений, позволяющий применять многопроходные SQL-операторы SELECT и/или коррелированные подзапросы;

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

Генерирвать SQL-выражения, оптимизированные для целевой реляционной СУБД, включая поддержку доступных в ней расширений этого языка;

- предоставлять механизмы описания модели данных с помощью метаданных и давать возможность использовать эти метаданные для построения запросов в реальном масштабе времени;

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

Третий, сравнительно новый тип OLAP-средств -инструменты генерации запросов и отчетов для настольных ПК , дополненные

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

компания Brio Technology со своей системой Brio Query Enterprise, Business Objects с одноименным продуктом и Cognos с PowerPlay.

В настоящее время увеличивается число Web-совместимых продуктов OLAP.

Важным является вопрос приспосабливания OLAP к остальному ПО. Хотя поставщики OLAP начинают предлагать некоторые способы взаимодействия с SQL-СУБД и другими инструментами, но однако, пользователи и аналитики предупреждают, что уровень интеграции может быть различным и, вероятно, потребует значительного объема кодирования, включая написание запросов на языке SQL. Более того, для интеграции OLAP с остальным программным обеспечением предприятия не существует промышленного стандарта.

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

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

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

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

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

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

Круг задач, эффективно решаемых каждой из систем, определим на основе сравнительных характеристик OLTP- и OLAP-систем (табл. 8).

Таблица 8

Круг задач решаемых OLTP- и OLAP-системами

Характеристика

Частота обновления

Высокая частота,

Малая частота, большие "порции"

небольшие "порции"

Источники данных

В основном, внутренние

По отношению к аналитической

системе, в основном,

Возраст данных

Текущие (несколько

Исторически (за годы) и

прогнозируемые

Уровень агрегации

Детализированные данные

В основном

агрегированные данные

Возможности

Регламентированные

Последовательность

аналитических

интерактивных очетов,

операций

динамическое изменение уровней

агрегаций и срезов данных

Назначение

Фиксация, оперативный

Работа с историческими

поиск и обработка данных,

данными, аналитическая

регламентированная

обработка, прогнозирование,

аналитическая обработка

моделирование

Таблица 9

Сравнение OLTP и OLAP

характеристика

Преобладающие

Ввод данных, поиск

Анализ данных

операции

Характер запросов

Сложные транзакции

транзакций

Хранимые данные

Оперативные,

охватывающие

детализированные

агрегированные

Вид деятельности

Оперативная,

Аналитическая,

тактическая

стратегическая

Тип данных

Структурированные

Разнотипные

3.7. Подходы к выбору экономических информационных систем

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

1. Насколько технологии бизнеса в фирме отличаются от традиционных.

Если отличия весьма серьезны и пути изменения этих технологий в направлении стандартизации видятся неприемлемыми или чрезмерно затратными, покупка и адаптация готовой ЭИС российского производства либо неприменима вовсе, либо может оказаться

неэффективной - часть модулей системы будут неприменимы или неработоспособны в поставленных условиях.

2. Как часто потребуется вносить значительные изменения во внедряемую информационную систему.

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

3. Какие суммы готова вложить фирма в автоматизацию.

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

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

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

Разработка ЭИС своими средствами и заказ разработки ЭИС сторонней организации-разработчику наиболее привлекательны для редкого или нетипичного ведения "делового хозяйства". При этом конкретный выбор стоит делать на основании информации о финансовом состоянии фирмы, наличии надежной фирмы разработчика или интегратора и возможности установить с ней длительные партнерские отношения и других факторов.

Более подробный анализ достоинств и недостатков методов автоматизации представлен в таблице.

Таблица 10

Достоинства и недостатки методов автоматизации

Достоинства подхода

Недостатки подхода

Ориентация

российские

Проблема

инвестиций

адаптация

законы, "особенности" бизнеса,

первоначальные

готовой ЭИС

бухгалтерского учета

абсолютные

величины

российского

оказаться

невелики,

дальнейшие

производства

Доступность

разработчиков

обучение,

поддержки

обслуживание

развитие

сопровождения, что в варианте

информационной

с зарубежным продуктом либо

быть весьма значительными). В

имеет куда меньше масштабы,

условиях

нестабильности

обходится

экономики

несовершенства

дороже (возможно в десятки и

законодательства,

сотни раз). Рабочий день одного

гарантии

стабильности

квалифицированного

производителя

программного

специалиста

настройке

обеспечения (ПО) на протяжении

адаптации систем такого класса

всего срока эксплуатации ПО.

западная фирма вполне может

оценить очень дорого.

1.2.Покупка и

Наибольшим

начальные

адаптация

подобного

является

готовой ЭИС

огромная

мощность

Весьма значительные

затраты на

зарубежного

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

внедрение

продукта,

обучение

производства

и комплексов автоматизации.

персонала и связанные с этим

Обычно они состоят из ряда

изменения

комплектуются

коснуться

аппаратного

зависимости

обеспечения фирмы.

потребителя (хотя существует и

В связи со многими чисто

целый ряд систем, которые по

российскими факторами (большая

причинам

динамичность

модульными

являются;

обстановки,

системам

свойственна

человеческого

большая закрытость и большая

другое) величина риска подобного

трудность

эксплуатации

рода вложений очень высока.

внедрении).

Основной

проблемой

является

необходимость

переориентации

технических

аспектов деятельности фирмы под

то, как это представляли себе

разработчики продукта, что в

наших условиях возможно очень

редко, даже если эти технологии

признаны

общепринятыми.

Отсутствие

некоторых

продуктах

типичных

российского

пользователя

компонент,

недостаточная

локализация

затруднить

значительно

эффективность его применения.

Стратегии

и критерии выбора

западной

информационной

достаточно

непросты,

главными из требований, которые

могут быть предъявлены системе

подобного

являются:

функциональная

открытость,

модульность,

масштабируемость, способность к

работе в распределенной среде,

настраиваемость

поставки в исходных текстах),

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

продукта и его представителей в

2.Разработка

Этот подход в большинстве

Большое (причем подчас трудно

случаев применим лишь в двух

прогнозируемое) время разработки

собственным

вариантах: для достаточно

и, во многих случаях, большая

крупной фирмы, способной

величина затрат.

квалифицированных

разработчиков ПО и в том

случае, если комплекс

автоматизации не очень велик и

может быть разработан

достаточно ограниченными

ресурсами.

Обычно этот вариант

автоматизации используется в

том случае, когда ни один из

существующих коммерческих

продуктов не удовлетворяет

руководство предприятия, либо

если бизнес настолько

динамичен, что перенастройка

готового продукта окажется

дороже или менее

эффективной, чем своего.

Достоинства:

ориентированный

конкретную фирму

комплекс

автоматизации,

покрывающий

требуемый

качество,

эффективность и оперативность

"поддержки" (никто не знает

всех особенностей бизнеса

фирме лучше

ее собственных

сотрудников).

3.Разработка

Этот вариант перекликается с

Однако тут возникают проблемы,

предыдущим, но отличается от

сходные первым вариантом

совместно с

него следующим: фирме не

автоматизации, но обычно этими

проблемами легче управлять из-за

разработчико

программистов с одной

более тесных контактов

стороны, и она получает

потребителя информационной

ориентированный чисто на нее

системы и фирмы-разработчика

продукт - с другой.

(или интегратора).

В случае наличия у фирмы-

разработчика технологического

"конструктора" (ядра

информационной системы,

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

и адаптируемого под

меняющиеся условия) такой

вариант автоматизации может

оказаться дешевле и

эффективнее второго подхода и

динамичнее и технологичнее

Выбор автоматизированной системы для предприятия должен проводиться не по принципу, какая ЭИС лучше, а какая хуже. Здесь необходимо определить в какой степени определенная ЭИС подходит для работы в конкретном предприятии при заданных условиях. Разработка сравнительных критериев представленных на рынке ЭИС нецелесообразна без учета конкретных условий, таких как: экономическое состояние предприятия, уровень подготовки служащих, ранее сделанные инвестиции в программное и техническое обеспечение и т.д. В связи с этим возникает необходимость в определении рациональной с точки зрения технико-экономических показателей, структуры ЭИС, предполагающей возможность гибкой перенастройки техники и программного обеспечения в случае изменения структуры предприятия при реинжиниринге бизнес-процессов.

Внедрение качественной ЭИС является одним из важнейших элементов рыночного успеха предприятия и условием ее динамичного развития.

3.8. Критерии выбора ЭИС

При выборе ЭИС необходимо учитывать следующие критерии:

репутация фирмы, репутация системы, стаж пребывания фирмы на рынке, число продаж.

сколько работающих систем в России. Имеются ли внедрения на родственных предприятиях? Потребовалась ли помощь внешних консультантов?

терминология и качество русификации западной системы.

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

какая российская команда стоит за западной системой. Кто ее русифицировал, кто внедряет? Знают ли они производство? Какое у них образование? Какой опыт? Какая за ними “история успехов”? Какой их подход к внедрению?

разумная цена . Покупая систему, необходимо помнить, что на весь цикл - покупка, внедрение, сопровождение, развитие - придется затратить в 3 - 10 раз больше денег, чем стоимость программных средств. Чем сложнее и дороже система, тем больше коэффициент. Если придется привлекать западных консультантов, это будет стоить минимум в 1000 $ в день, причем заранее неясно, то ли они будут учить работать с их системой, то ли сотрудники предприятия за эти деньги будут их знакомить с волнующими особенностями российской экономики,

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

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

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

архитектура. Желательна трехзвенная - сервер базы данных, сервер приложений, клиент - клиент-серверная архитектура с возможностью использования “тупых терминалов”. Клиент может быть “толстым” или “тонким”,

техническая платформа. За время жизни системы сменится не одно поколение технических средств. Привязанность к определенной платформе опасна. Система должна уметь мигрировать с платформы на платформу,

Режим оперативной обработки транзакций OLTP (On-Line Transaction Processing) применяется в информационных системах организационного управления для отражения актуального состояния предметной области в любой момент времени, а пакетная обработка занимает весьма ограниченную нишу.

OLTP

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

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

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

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

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

Информационные системы класса OLTP характеризуются следующими особенностями.

Характеристики ИС - информационных систем - класса OLTP

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

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

Стратерия разработки систем

Длительное время в качестве стратегии разработки подобных систем использовалось следующее:

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

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

 OLTP и OLAP системы В предыдущем подразделе отмечалось, что для адекватного представления предметной области, простоты разработки и поддержания базы данных отношения должны быть приведены к третьей нормальной форме (существуют формы нормализации и более высоких порядков, но на практике они используются достаточно редко), то есть быть сильно нормализованными. Однако слабо нормализованные отношения также имеют свои достоинства, основным из которых является то, что если к базе данных обращаться в основном только с запросами, а модификации и добавление данных проводить очень редко, то их выборка производится значительно быстрее. Это объясняется тем, что в слабо нормализованных отношениях уже как бы произведено их соединение и на это не тратится процессорное время. Выделяют два класса систем, для которых в большей степени подходят сильно и слабо нормализованные отношения. Сильно нормализованные модели данных хорошо подходят для OLTP-приложений - On-Line Transaction Processing (OLTP) - приложений оперативной обработки транзакций. Типичными примерами OLTP-приложений являются системы складского учета, заказов билетов, операционные банковские системы и другие. Основная функция подобных систем заключается в выполнении большого количества коротких транзакций. Сами транзакции являются достаточно простыми, но проблемы состоят в том, что таких транзакций очень много, выполняются они одновременно и при возникновении ошибок транзакция должна откатиться и вернуть систему в состояние, в котором та была до начала транзакции. Практически все запросы к базе данных в OLTP-приложениях состоят из команд вставки, обновления и удаления. Запросы на выборку, в основном, предназначены для предоставления пользователям выборки данных из различного рода справочников. Таким образом, большая часть запросов известна заранее ещё на этапе проектирования системы. Критическим для OLTP-приложений является скорость и надежность выполнения коротких операций обновления данных. Чем выше уровень нормализации данных в OLTP-приложениях, тем оно быстрее и надежней. Отступления от этого правила могут происходить тогда, когда уже на этапе разработки известны некоторые часто возникающие запросы, требующие соединения отношений и от скорости выполнения которых существенно зависит работа приложений. Другим типом приложений являются OLAP-приложения - On-Line Analitical Processing (OLAP) - приложения оперативной аналитической обработки данных. Это обобщенный термин, характеризующий принципы построения систем поддержки принятия решений - Decision Support System (DSS), хранилищ данных - Data Warehouse, систем интеллектуального анализа данных - Data Mining. Такие системы предназначены для нахождения зависимостей между данными, для проведения динамического анализа по принципу "что если..." и тому подобных задач. OLAP-приложения оперируют с большими массивами данных, накопленными на предприятии или взятыми из других источников. Такие системы характеризуются следующими признаками: * добавление в систему новых данных происходит относительно редко крупными блоками, например, один раз в месяц или квартал; * данные, добавленные в систему, как правило, никогда не удаляются; * перед загрузкой данные проходят различные подготовительные процедуры, связанные с приведением их к определенным форматам и тому подобное; * запросы к системе являются нерегламентированными и достаточно сложными; * скорость выполнения запросов важна, но не критична. Базы данных OLAP-приложений обычно представлены в виде одного или нескольких гиперкубов, измерения которого представляют собой справочные данные, а в ячейках самого гиперкуба хранятся значения этих данных. Физически гиперкуб может быть построен на основе специальной многомерной модели данных - Multidimensional OLAP (MOLAP) или представлен средствами реляционной модели данных - Relational OLAP (ROLAP). В системах OLAP, использующих реляционную модель данных, данные целесообразно хранить в виде слабо нормализованных отношений, содержащих заранее вычисленные основные итоговые данные. Избыточность данных и связанные с ней проблемы здесь не страшны, так как их обновление происходит достаточно редко и вместе с обновлением данных осуществляется пересчет итогов. Характеристики и круг задач, эффективно решаемых каждой технологией, поясняется следующей сравнительной таблицей: ХарактеристикаOLTPOLAPНазначение системыРегистрация, оперативный поиск и обработка транзакций, регламентированный анализРабота с историческими данными, аналитическая обработка, прогнозирование, моделирование Хранимые данныеОперативные, детализированныеОхватывающие большой период времени, агрегированныеТип данныхСтруктурированныеРазнотипные"Возраст" данныхТекущие (несколько месяцев)Исторические (за годы) и прогнозируемыеЧастота обновления данныхВысокая, небольшими "порциями"Малая, большими "порциями"Уровень агрегации данныхДетализированные данныеВ основном - агрегированные данныеПреобладающие операцииВвод данных, поиск, обновлениеАнализ данныхСпособ использования данныхПредсказуемыйНепредсказуемыйВзаимодействие с пользователем На уровне транзакции На уровне всей базы данных Вид деятельностиОперативная, тактическаяАналитическая, стратегическаяПриоритетыВысокая производительность Высокая доступностьГибкость Автономность пользователяКатегория пользователейБольшое количество работников исполнительного звенаОтносительно малое количество работников руководящего звена Сравнение OLTP и OLAP Характеристика OLTP OLAPХарактер запросовМного простых транзакцийСложные транзакцииХранимые данныеОперативные, детализи-рованныеОхватывающие большой период времени, агреги-рованныеВид деятельностиОперативная, тактическаяАналитическая, страте-гическаяТип данныхСтруктурированныеРазнотипныеСистемная характеристикаУчетная система (OLTP)OLAPВзаимодействие с пользователем На уровне транзакции На уровне всей базы данных Данные, используемые при обращении пользователя к системеОтдельные записиГруппы записейВремя откликаСекундыОт нескольких секунд до нескольких минутИспользование аппаратных ресурсовСтабильноеДинамическоеХарактер данных Главным образом первичные (самый низкий уровень детализации)В основном производные (сводные значения)Характер доступа к базе данныхПредопределенные или статические пути доступа и отношения данных Неопределенные или динамические пути доступа и отношения данных Изменчивость данныхВысокая (данные обновляются с каждой транзакцией)Низкая (во время запроса данные обновляются редко)Приоритеты Высокая производительность Высокая доступностьГибкость Автономность пользователя

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

Технологии, ориентированные на оперативную (транзакционную) обработку данных. Эти технологии лежат в основе экономических информационных систем, предназначенных для оперативной обработки данных. Называются подобные системы - OLTP (online transaction processing) системы ;

Технологии, ориентированные на анализ данных и принятие решений. Эти технологии лежат в основе экономических информационных систем, предназначенных для анализа

накопленных данных. Называются подобные системы - OLAP

(online analytical processing) системы .

Основное назначение OLAP -систем - динамический многомерный

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

тенденций, моделирование и прогнозирование будущего. Такие

системы, как правило, ориентированы на обработку произвольных,

заранее не регламентированных запросов. В качестве основных

характеристик этих систем можно отметить следующие:

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

Прозрачность для пользователя структуры, способов хранения и обработки данных;

Автоматическое отображение логической структуры данных во внешние системы;

Динамическая обработка разряженных матриц эффективным способом.

Термин OLAP является сравнительно новым и в разных литературных источниках трактуется иногда по разному. Этот термин часто отождествляют с поддержкой принятия решений (DSS (Decision Support Systems)- системы поддержки принятия решения. А в качестве синонима для последнего термина используют Data Warehousing -хранилища (склады) данных, понимая под этим набор организационных решений, программных и аппаратных сре дств дл я обеспечения аналитиков информацией на основе данных из систем обработки транзакций нижнего уровня и других источников

“Склады данных” позволяют обрабатывать данные, накопленные за длительные периоды времени. Эти данные являются разнородными (и не обязательно структурированными). Для “складов данных” присущ многомерный характер запросов. Огромные объемы данных, сложность структуры как данных, так и запросов требует использования специальных методов доступа к информации.

В других источниках понятие Системы Поддержки Принятия Решений (СППР) считается более широким. Хранилища данных и средства оперативной аналитической обработки могут служить одними из компонентов архитектуры СППР.

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

Иногда различают " OLAP в узком смысле" - это системы которые обеспечивают только выборку данных в различных разрезах, и " OLAP в широком смысле", или просто OLAP , включающей в себя:

Поддержку нескольких пользователей, редактирующих БД.

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

Прогнозирование, выявление тенденций и статистический анализ.

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

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

OLAP - системы можно разбить на три класса.

Наиболее сложными и дорогими из них являются основанные на патентованных технологиях серверы многомерных БД . Эти системы обеспечивают полный цикл OLAP -обработки и либо включают в себя, помимо серверного компонента, собственный интегрированный клиентский интерфейс, либо используют для анализа данных внешние программы работы с электронными таблицами. Продукты этого класса в наибольшей степени соответствуют условиям применения в рамках крупных информационных хранилищ. Для их обслуживания требуется целый штат сотрудников, занимающихся как установкой и сопровождением системы, так и формированием представлений данных для конечных пользователей. Обычно подобные пакеты довольно дороги. В качестве примеров продуктов этого класса можно привести систему Essbase корпорации Arbor Software , Express фирмы IRI (входящей теперь в состав Oracle), Lightship производства компании Pilot Software и др.

Следует отметить, что одним из способов обеспечения быстрой обработки данных при их анализе является организация данных в виде многомерных БД (MDD). Информация в MDD хранится не в виде индексированных записей в таблицах, а в форме логически упорядоченных массивов. Единой общепризнанной многомерной модели хранения данных не существует. В MDD отсутствует стандартизованный метод доступа к данным, и они могут отвечать требованиям специфической аналитической обработки данных.

Принимая во внимание все перечисленное, сравнение между различными MDD - продуктами можно проводить только по самым обобщенным категориям. В более дешевом секторе рынка присутствуют лишь однопользовательские и предназначенные для небольших локальных сетей средства просмотра многомерных данных. Хотя они обладают довольно высоким уровнем функциональных возможностей и удобны в использовании, эти системы ограниченны по своему масштабу. и им недостает средств, необходимых для реализации OLAP - обработки в широком смысле. В данную категорию попадают такие продукты, как PowerPlay корпорации Cognos , PaBlo фирмы Andyne и Mercury компании Business Objects . Дорогой же сектор рынка представлен системами Acumate ES фирмы Kenan Technologies , Express корпорации Oracle , Gentium компании Planning Sciences и Holos фирмы Holistic Systems . Они настолько разнятся по своим возможностям, что любую из них можно смело выделять в отдельную категорию. И наконец, MDD -системы в чистом виде: Essbase корпорации Arbor Software , LightShip Server фирмы Pilot Software и TM /1 компании Sinper [ N . Raden (Рынок программных средств)].

Второй класс OLAP -средств - реляционные OLAP -системы (ROLAP). Здесь для хранения данных используются старые реляционные СУБД, а между БД и клиентским интерфейсом организуется определяемый администратором системы слой метаданных. Через этот промежуточный слой клиентский компонент может взаимодействовать с реляционной БД как с многомерной. Подобно средствам первого класса, ROLAP -системы хорошо приспособлены для работы с крупными информационными хранилищами, требуют значительных затрат обслуживания специалистами информационных подразделений и предусматривают работу в многопользовательском режиме. Среди продуктов этого типа - IQ / Vision корпорации IQ Software , DSS / Server и DSS / Agent фирмы MicroStrategy и DecisionSuite компании Information Advantage .

ROLAP - средства реализуют функции поддержки принятия решений в надстройке над реляционным процессором БД.

Такие программные продукты должны отвечать ряду требований, в частности:

Иметь мощный оптимизированный для OLAP генератор SQL -выражений, позволяющий применять многопроходные SQL -операторы SELECT и/или коррелированные подзапросы;

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

Генерирвать SQL -выражения, оптимизированные для целевой реляционной СУБД, включая поддержку доступных в ней расширений этого языка;

Предоставлять механизмы описания модели данных с помощью метаданных и давать возможность использовать эти метаданные для построения запросов в реальном масштабе времени;

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

Третий, сравнительно новый тип OLAP -средств - инструменты генерации запросов и отчетов для настольных ПК , дополненные OLAP -функциями или интегрированные с внешними средствами, выполняющими такие функции. Эти весьма развитые системы осуществляют выборку данных из исходных источников, преобразуют их и помещают в динамическую многомерную БД, функционирующую на ПК конечного пользователя. Указанный подход, позволяющий обойтись как без дорогостоящего сервера многомерной БД, так и без сложного промежуточного слоя метаданных, необходимого для ROLAP - средств, обеспечивает в то же время достаточную эффективность анализа. Эти средства для настольных ПК лучше всего подходят для работы с небольшими, просто организованными БД. Потребность в квалифицированном обслуживании для них ниже, чем для других OLAP -систем, и примерно соответствует уровню обычных сред обработки запросов. В числе основных участников этого сектора рынка -к омпания Brio Technology со своей системой Brio Query Enterprise , Business Objects с одноименным продуктом и Cognos с PowerPlay .

В настоящее время увеличивается число Web -совместимых продуктов OLAP .

Важным является вопрос приспосабливания OLAP к остальному ПО. Хотя поставщики OLAP начинают предлагать некоторые способы взаимодействия с SQL -СУБД и другими инструментами, но однако, пользователи и аналитики предупреждают, что уровень интеграции может быть различным и, вероятно, потребует значительного объема кодирования, включая написание запросов на языке SQL . Более того, для интеграции OLAP с остальным программным обеспечением предприятия не существует промышленного стандарта.

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

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

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

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

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

Круг задач, эффективно решаемых каждой из систем, определим на основе сравнительных характеристик OLTP - и OLAP -систем (табл. 8).