Информационные технологии в профессиональной деятельности экономиста: Обзор ИТ, предназначенных для оперативной и аналитической обработки данных. OLAP и OLTP системы OLTP – оперативная транзакционная обработка данных OLAP – оперативная аналитическая обр

Принимая во внимание все перечисленное, сравнение между различными 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-системами

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

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

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

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

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

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

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

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

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

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

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

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

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

Таблица 10

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Система оперативной обработки данных (ON LINE TRANSACTION PROCESSING) OLTP рассчитаны на быстрое обслуживание относительно простых запросов большого числа пользователей. Эти системы требуют защиты от несанкционированного доступа, от нарушения целостности данных, аппаратных и программированных сбоев.

Их характеризует малое время ожидания выполнения запросов.

Сфера применения √ это сфера платежей, учета, резервирования мест, банки и биржевые операции

Транзакция - это некоторое законченное с точки зрения пользователя действие над БД.

Системы аналитической обработки данных (ON LINE ANALIZIS PROCESSING) OLAP- это системы поддержки принятия решений, ориентированны на выполнение более сложных запросов, требующих статистической обработки исторических данных, накопленных за определенный промежуток времени. Аналитические системы включают:

1. средства обработки информации на основе методов искусственного интеллекта

2. средства графического представления данных.

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

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

Приведенные классы систем (OLAP и OLTP), они основаны на использовании СУБД, но типы запросов сильно отличаются.

Обработка транзакций в OLTP системах

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

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

Транзакция должна обладать 4 основными свойствами:

1. атомарность, транзакция должна выполнятся как единая операция доступа к БД, она должна быть выполнена полностью или не выполнена вообще.

2. согласованность , гарантирует взаимную целостность данных.

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

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

Результатом выполнения транзакции может быть ее фиксация и откат.

Фиксация - это действие, обеспечивающее запись в БД всех изменений.

Откат - если нормальное завершение транзакции невозможно, БД возвращается в исходное состояние, все изменения аннулируются.

При откате и фиксации транзакции используется журнал транзакций, в котором сохраняются все изменения.

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

При откате СУБД по журналу транзакций восстанавливает те строки, которые были модифицированы.

Границы транзакции - это первая и последняя, входящая в неё операции. Предполагается, что транзакция начинается с 1-го SQL оператора, следующие операторы составляют тело транзакции и тело может разветвляется:

1. SQL оператором commit work

SQL оператором rollback

2. простым завершением оператора, вызвавшего транзакцию.

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

Применение транзакции - это эффективный механизм организации многопользовательского доступа к БД.

Проблемы:

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

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

Для устранения этого используют сериализацию (совместная отработка):

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

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

В современном СУБД сериализация транзакций реализуется через механизм блокировок: на время выполнения транзакции 1 СУБД блокирует часть базы данных к которой транзакция 1 обращается. Блокировка сохраняется до момента фиксации транзакции 1, если в этот момент другая транзакции 2 обращается к блокированным данным, то транзакции 2 приостанавливается до момента завершения транзакции 1

Взаимоблокировка транзакций

Пусть транзакция т1 обновляет отношение - о1. Далее эта транзакция т1 пытается модифицировать отношение о2 , которая была ранее заблокирована транзакцией т2. Транзакция т1 переводится в состояния ожидания пока не снята блокировка с отношения о2; в тот же момент транзакция т2 пытается изменить данные отношения о1, ранее заблокирована транзакцией т1. СУБД вынуждена перевести в состояния ожидания и транзакцию т2 следовательно возникает ситуация взаимоблокировки транзакций.

СУБД периодически проверяет блокировку и если есть взаимоблокировки, то одна из транзакции насильственно прерывается.

Средства восстановления после сбоев

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

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

Недостатки
OLTP-системы оптимизированы для небольших дискретных транзакций. А вот запросы на некую комплексную информацию (к примеру поквартальная динамика объемов продаж по определённой модели товара в определённом филиале), характерные для аналитических приложений (OLAP), породят сложные соединения таблиц и просмотр таблиц целиком. На один такой запрос уйдет масса времени и компьютерных ресурсов, что затормозит обработку текущих транзакций.

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

Различают последовательные (обычные), параллельные и распределённые транзакции. Распределённые транзакции подразумевают использование больше чем одной транзакционной системы и требуют намного более сложной логики (например, two-phase commit - двухфазный протокол фиксации транзакции). Также, в некоторых системах реализованы автономные транзакции, или под-транзакции, которые являются автономной частью родительской транзакции.

Пример: Необходимо перевести с банковского счёта номер 5 на счёт номер 7 сумму в 10 денежных единиц. Этого можно достичь, к примеру, приведённой последовательностью действий:
Начать транзакцию
прочесть баланс на счету номер 5
уменьшить баланс на 10 денежных единиц
сохранить новый баланс счёта номер 5
прочесть баланс на счету номер 7
увеличить баланс на 10 денежных единиц
сохранить новый баланс счёта номер 7

Окончить транзакцию
Эти действия представляют собой логическую единицу работы «перевод суммы между счетами», и таким образом, являются транзакцией. Если прервать данную транзакцию, к примеру, в середине, и не аннулировать все изменения, легко оставить владельца счёта номер 5 без 10 единиц, тогда как владелец счета номер 7 их не получит.

Режим оперативной обработки транзакций OLTP

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

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

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

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

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

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

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

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

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

OLTP-технологии

В практике общения с представителями информационных служб предприятий нередко приходится сталкиваться с серьезным недопониманием различий в возможностях, назначении и роли технологий, предназначенных для сбора информации, - OLTP-систем (On-Line Transaction Processing) и технологий анализа информации. Между тем они существенно различны по функциональности, и каждая из них отвечает за свою область в информационной системе.
Задачи OLTP-системы – это быстрый сбор и наиболее оптимальное размещение информации в базе данных, а также обеспечение ее полноты, актуальности и согласованности. Однако такие системы не предназначены для максимально эффективного, быстрого и многоаспектного анализа.
Разумеется, по собранным данным можно строить отчеты, но это требует от бизнес-аналитика или постоянного взаимодействия с IT-специалистом, или специальной подготовки в области программирования и вычислительной техники.
Как выглядит традиционный процесс принятия решений в российской компании, использующей информационную систему, построенную на OLTP-технологии?
Менеджер дает задание специалисту информационного отдела в соответствии со своим пониманием вопроса. Специалист информационного отдела, по-своему осознав задачу, строит запрос оперативной системе, получает электронный отчет и доводит его до сведения руководителя. Такая схема принятия критически важных решений обладает следующими существенными недостатками:
-используется ничтожное количество данных;
-процесс занимает длительное время, поскольку составление запросов и интерпретация электронного отчета – операции довольно канительные, тогда как руководителю, может быть, необходимо принять решение незамедлительно;
-требуется повторение цикла в случае необходимости уточнения данных или рассмотрения данных в другом разрезе, а также при возникновении дополнительных вопросов. Причем этот медленный цикл приходится повторять и, как правило, неоднократно, при этом времени на анализ данных тратится ещё больше;
негативным образом сказывается различие в профессиональной подготовке и областях деятельности специалиста по информационным технологиям и руководителя. Зачастую они мыслят разными категориями и, как следствие, не понимать друг друга;
неблагоприятное действие оказывает такой фактор, как сложность электронных отчетов для восприятия. У руководителя нет времени выбирать интересующие цифры из отчёта, тем более что их может оказаться слишком много. Понятно, что работа по подготовке данных чаще всего ложится на специалистов информационных отделов. В результате грамотный специалист отвлекается на рутинную и малоэффективную работу по составлению таблиц, диаграмм и т. д., что, естественно, не способствует повышению его квалификации.
Выход из этой ситуации один, и сформулирован он Биллом Гейтсом в виде выражения: "Информация на кончиках пальцев". Исходная информация должна быть доступна ее непосредственному потребителю – аналитику. Именно непосредственно доступна (!). А задачей сотрудников информационного отдела является создание системы сбора, накопления, хранения, защиты информации и обеспечения ее доступности аналитикам.

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

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

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

Данные в OLTP-системах организованы главным образом для поддержки таких транзакций, как:

регистрация заказа, введенного с кассового терминала или через Web-узел;

размещение заказа на комплектующие изделия, когда их количество на складе становится меньше определенного числа;

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

регистрация сведений о работниках;

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

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

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

Современные задачи Хранилищ данных
Разделение данных с конкретными целями

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

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

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

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

Кроме того, аналитические операции, выполняемые в Хранилище, необходимо вновь передавать в OLTP-систему, откуда поступили данные. Таким образом происходит централизация аналитической обработки и гарантируется передача решений, принятых на агрегированных данных в Хранилище, в соответствующие OLTP-системы.

Эти тенденции реализуются следующим образом:
Интеграция данных в реальном времени для Хранилища данных. Получение и передача данных в реальном времени из операционных систем в Хранилище, что делает данные доступными для анализа.
Активное Хранилище данных. ХД в реальном времени, дополняемое инструментами Business Intelligence для обработки и выполнения бизнес-решений. Решения автоматически передаются в OLTP-системы. В результате формируется замкнутый цикл обработки.

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

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

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

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

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

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

EAI и TDM предназначены для передачи изменений и обновлений данных, а не целостных выборок данных. Ни то, ни другое не требует приостановки исходных систем, так как эти технологии поддерживают целостность операций языка манипулирования данными (data manipulation language - DML). За счет этого существенно сокращается объем необходимых перемещений данных. И если ETL-средства в основном предназначены для исходной загрузки и преобразования данных, то EAI и TDM больше подходят для постоянного сбора данных.

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

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

Интеграция Хранилища и OLTP-системы подразумевает получение и передачу транзакционных данных в Хранилище одновременно с передачей данных о принятых решениях на основе данных ХД в одну или нескольких оперативных систем. Такой замкнутый цикл работы также обеспечивается средствами TDM.
Основные характеристики и возможности средств интеграции

Инструменты интеграции TDM обладают рядом важных функциональных особенностей.

Сбор данных

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

Доставка данных

Все новые данные передаются в промежуточную область хранения ХД, при этом временная задержка составляет доли секунды. А значит, наиболее актуальные данные всегда доступны для самых передовых методов Business Intelligence, а также для отчетности и принятия решений. Поскольку в течение заданного промежутка времени передаются меньшие выборки данных (чем в случае пакетной передачи), то дополнительная нагрузка на OLTP-систему оказывается очень незначительной.

Гетерогенность

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

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

Выборочность данных

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

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

Преобразование данных

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

Гибкость

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

Динамическое определение таблиц

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

Обратная связь

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

В задаче интеграции DW и OLTP возможно комбинирование TDM и ETL-процессов. В том числе для обработки данных в реальном времени, постоянном захвате и извлечении данных на транзакционном уровне. Средства TDM могут передавать данные в реальном времени в промежуточный уровень хранения целевой БД, где ETL-сервер будет перехватывать данные и, применив к ним преобразования, загружать в Хранилище. У такого подхода есть недостатки (в частности, дополнительная задержка и необходимость поддерживать ETL-сервер), однако они обоснованы, в случае если требования к преобразованию данных слишком сложны.

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

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

Сильно нормализованные модели данных хорошо подходят для 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, использующих реляционную модель данных, данные целœесообразно хранить в виде слабо нормализованных отношений, содержащих заранее вычисленные основные итоговые данные. Избыточность данных и связанные с ней проблемы здесь не страшны, так как их обновление происходит достаточно редко и вместе с обновлением данных осуществляется пересчет итогов.

Для решения задач анализа данных и поиска решений необходимо накопление и хранение достаточно больших объемов данных. Этим целям служат базы данных (БД).

Чтобы сохранять данные согласно какой-либо модели предметной области, структура БД должна максимально соответствовать этой модели. Первой такой структурой, используемой в СУБД, была иерархическая структура, появившаяся в начале 60-х годов прошлого века.

Иерархическая структура предполагала хранение данных в виде структуры дерева.

Попыткой улучшить иерархическую структуру была сетевая структура БД, которая предполагает представление структуры данных в виде сети.

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

В соответствии с правилами Кодда СУБД должна обеспечивать выполнение операций над БД, предоставляя при этом возможность одновременной работы нескольким пользователям (с нескольких компьютеров) и гарантируя целостность данных. Для выполнения этих правил в СУБД используется механизм управления транзакциями.

Транзакция − это последовательность операций над БД, рассматриваемых СУБД как единое целое. Транзакция переводит БД из одного целостного состояния в другое.

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

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

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

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

История развития СУБД тесно связана с совершенствованием подходов к решению задач хранения данных и управления транзакциями. Развитый механизм управления транзакциями в современных СУБД сделал их основным средством построения ОLTP-систем, основной задачей которых является обеспечение выполнения операций с БД.

3.1.3. Использование OLTP-технологии
в системах поддержки принятия решений

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

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

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

Основными требованиями предъявляемыми к системам OLTP и СППР являются следующие:

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

2. Качество данных. OLTP-системы, как правило, хранят информацию, вводимую непосредственно пользователями систем (операторами ЭВМ). Присутствие "человеческого фактора" при вводе повышает вероятность ошибочных данных и может создать локальные проблемы в системе.

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

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

5. Управление данными. Основное требование к OLTP-системам − обеспечить выполнение операций модификации над БД. При этом предполагается, что они должны выполняться в реальном режиме, и часто очень интенсивно.

6. Количество хранимых данных. Как правило, системы анализа предназначены для анализа временных зависимостей, в то время как OLTP-системы обычно имеют дело с текущими значениями каких-либо параметров.

7. Характер запросов к данным. В OLTP-системах из-за нормализации БД составление запросов является достаточно сложной работой и требует необходимой квалификации.

8. Время обработки обращений к данным. OLTP-системы, как правило, работают в режиме реального времени, поэтому к ним предъявляются жесткие требования по обработке данных.

9. Характер вычислительной нагрузки на систему. Как уже отмечалось ранее, работа с OLTP-системами, как правило, выполняется в режиме реального времени.

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

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

Общая идея хранилищ данных заключается в разделении БД для − систем и БД для выполнения анализа и последующем их проектировании с учетом соответствующих требований.

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

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

Для упрощения разработки прикладных программ, использующих БД, создаются системы управления базами данных (СУБД) − программное обеспечение для управления данными, их хранения и безопасности данных.

В СУБД развит механизм управления транзакциями, что сделало их основным средством создания систем оперативной обработки транзакций (OLTP-систем). К таким системам относятся первые СППР, решающие задачи информационно-поискового анализа − ИСР.

OLTP-системы не могут эффективно использоваться для решения задач оперативно-аналитического и интеллектуального анализа информации. Основная причина заключается в противоречивости требований к OLTP-системе и к СППР.

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

Вопросы для самоконтроля

1. Перечислите основные задачи, которые решают системы поддержки принятия решений.

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

3. Укажите типы структур для организации хранилищ данных в СППР. В чем состоят преимущества и недостатки каждого из типов структур?

4. Обоснуйте целесообразность использования постреляционной модели подсистемы сбора и обработки информации в СППР.

5. Как интерпретируется понятие транзакции в системах обработки данных?

6. В чем проявляется основное свойство транзакции в системах обработки данных?

7. Кратко охарактеризуйте механизм управления транзакциями в OLTP-системах.

8. Укажите роль и место OLTP-систем для оперативной обработки транзакций. Почему OLTP-системы неэффективны для решения задач оперативно-аналитического и интеллектуального анализа?

9. Назовите основные требования к OLTP-системам. В чем состоит противоречивость требований к OLTP-системам?

10. Назовите пути повышения эффективности оперативно-аналитического и интеллектуального анализа в СППР.