Меню
ГлавнаяБиос

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

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

OLTP (Online Transaction Processing) - обработка транзакций в реальном времени. Способ организации БД, при котором система работает с небольшими по размерам транзакциями, но идущими большим потоком, и при этом клиенту требуется от системы максимально быстрое время ответа.

В современных СУБД сериализация транзакций организуется через механизм блокировки, т.е. на время выполнения транзакции СУБД блокирует БД или ее часть, к которым обращается транзакция, блокировка сохраняется до момента фиксации транзакции. Если в процессе параллельной обработки другой транзакцией делается попытка обратиться к блокированным данным, то обработка транзакции приостанавливается и возобновляется только после завершения транзакции, заблокировавшей данные и снятия блокировки. Чем меньше блокируемый объект, тем больше оперативность БД. Транзакция, обновляющая данные на нескольких узлах сети, называется РАСПРЕДЕЛЕННОЙ. Если транзакция работает с БД, расположенной на одном узле, то она называется ЛОКАЛЬНОЙ. С точки зрения пользователя локальная и распределенная транзакция должны обрабатываться одинаково, т.е. СУБД должна организовывать процесс выполнения распределения транзакции так чтобы все входящие в нее локальные транзакции синхронно фиксировались на всех затрагиваемых ими узлах распределенной системы. При этом распределенная транзакция должна фиксироваться лишь в том случае, когда зафиксированы все составляющие ее локальной транзакции, а если прерывается хотя бы одна из локальных транзакций – должна быть прервана и вся распределенная транзакция. Для реализации этих требований на практике СУБД используется механизм двухстадийной фиксации транзакций.

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

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

OLAP (англ. online analytical processing, аналитическая обработка в реальном времени) - технология обработки информации, включающая составление и динамическую публикацию отчётов и документов. Используется аналитиками для быстрой обработки сложных запросов к базе данных. Служит для подготовки бизнес-отчётов по продажам, маркетингу, в целях управления, т. н. data mining - добыча данных (способ анализа информации в базе данных с целью отыскания аномалий и трендов без выяснения смыслового значения записей).

OLAP делает мгновенный снимок реляционной БД и структурирует её в пространственную модель для запросов. Заявленное время обработки запросов в OLAP составляет около 0,1 % от аналогичных запросов в реляционную БД.

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

Например, все клиенты могут быть сгруппированы по городам или по регионам страны (Запад, Восток, Север и т. д.), таким образом, 50 городов, 8 регионов и 2 страны составят 3 уровня иерархии с 60 членами. Также клиенты могут быть объединены по отношению к продукции; если существуют 250 продуктов по 2 категориям, 3 группы продукции и 3 производственных подразделения, то количество агрегатов составит 16560. При добавлении измерений в схему, количество возможных вариантов быстро достигает десятков миллионов и более.

OLAP-куб содержит в себе базовые данные и информацию об измерениях (агрегатах). Куб потенциально содержит всю информацию, которая может потребоваться для ответов на любые запросы. Из-за громадного количества агрегатов, зачастую полный расчёт происходит только для некоторых измерений, для остальных же производится «по требованию».

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

Первым продуктом, выполняющим OLAP-запросы, был Express (компания IRI). Однако, сам термин OLAP был предложен Эдгаром Коддом, «отцом реляционных БД». А работа Кодда финансировалась Arbor, компанией, выпустившей свой собственный OLAP-продукт - Essbase (позже купленный Hyperion, которая в 2007 г. была поглощена компанией Oracle) - годом ранее.

Другие хорошо известные OLAP-продукты включают Microsoft Analysis Services (ранее называвшиеся OLAP Services, часть SQL Server), Oracle OLAP Option, DB2 OLAP Server от IBM (фактически, EssBase с дополнениями от IBM), SAP BW, SAS OLAP Server, продукты Brio, BusinessObjects, Cognos, MicroStrategy и других производителей.

Наибольшее применение OLAP находит в продуктах для бизнес-планирования и хранилищах данных.

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

  • многомерное представление данных;
  • поддержка сложных расчетов;
  • правильный учет фактора времени.

Преимущества OLAP:

  • повышение производительности производственного персонала, разработчиков прикладных программ. Своевременный доступ к стратегической информации.
  • предоставление пользователям достаточных возможностей для внесения собственных изменений в схему.
  • приложения OLAP опираются на хранилища данных и системы OLTP, получая от них актуальные данные, что дает сохранение контроля целостности корпоративных данных.
  • уменьшение нагрузки на системы OLTP и хранилища данных.
OLAP OLTP
Хранилище данных должно включать как внутренние корпоративные данные, так и внешние данные основным источником информации, поступающей в оперативную БД, является деятельность корпорации, а для проведения анализа данных требуется привлечение внешних источников информации (например, статистических отчетов)
Объем аналитических БД как минимум на порядок больше объема оперативных. для проведения достоверных анализа и прогнозирования в хранилище данных нужно иметь информацию о деятельности корпорации и состоянии рынка на протяжении нескольких лет Для оперативной обработки требуются данные за несколько последних месяцев
Хранилище данных должно содержать единообразно представленную и согласованную информацию, максимально соответствующую содержанию оперативных БД. Необходима компонента для извлечения и "очистки" информации из разных источников. Во многих крупных корпорациях одновременно существуют несколько оперативных ИС с собственными БД (по историческим причинам). Оперативные БД могут содержать семантически эквивалентную информацию, представленную в разных форматах, с разным указанием времени ее поступления, иногда даже противоречивую
Набор запросов к аналитической базе данных предсказать невозможно. хранилища данных существуют, чтобы отвечать на нерегламентированные запросы аналитиков. Можно рассчитывать только на то, что запросы будут поступать не слишком часто и затрагивать большие объемы информации. Размеры аналитической БД стимулируют использование запросов с агрегатами (сумма, минимальное, максимальное, среднее значение и т.д.) Системы обработки данных создаются в расчете на решение конкретных задач. Информация из БД выбирается часто и небольшими порциями. Обычно набор запросов к оперативной БД известен уже при проектировании
При малой изменчивости аналитических БД (только при загрузке данных) оказываются разумными упорядоченность массивов, более быстрые методы индексации при массовой выборке, хранение заранее агрегированных данных Системы обработки данных по своей природе являются сильно изменчивыми, что учитывается в используемых СУБД (нормализованная структура БД, строки хранятся неупорядоченно, B-деревья для индексации, транзакционность)
Информация аналитических БД настолько критична для корпорации, что требуются большая грануляция защиты (индивидуальные права доступа к определенным строкам и/или столбцам таблицы) Для систем обработки данных обычно хватает защиты информации на уровне таблиц

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

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

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

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

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

Выход из этой ситуации один, и сформулирован он Биллом Гейтсом в виде выражения: "Информация на кончиках пальцев". Исходная информация должна быть доступна ее непосредственному потребителю – аналитику. Именно непосредственно доступна. А задачей сотрудников информационного отдела является создание системы сбора, накопления, хранения, защиты информации и обеспечения ее доступности аналитикам.

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

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

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

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

Чтобы сохранять данные согласно какой-либо модели предметной области, структура БД должна максимально соответствовать этой модели. Первой такой структурой, используемой в СУБД, была иерархическая структура, появившаяся в начале 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. Назовите пути повышения эффективности оперативно-аналитического и интеллектуального анализа в СППР.

Сравнение нормализованных и ненормализованных моделей

Анализ критериев для нормализованных и ненормализованных моделей данных

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

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

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

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

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

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

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

Данные OLAP-приложений обычно представлены в виде одного или нескольких гиперкубов, измерения которого представляют собой справочные данные, а в ячейках самого гиперкуба хранятся собственно данные. Например, можно построить гиперкуб, измерениями которого являются: время (в кварталах, годах), тип товара и отделения компании, а в ячейках хранятся объемы продаж. Такой гиперкуб будет содержать данных о продажах различных типов товаров по кварталам и подразделениям. Основываясь на этих данных, можно отвечать на вопросы вроде "у какого подразделения самые лучшие объемы продаж в текущем году?", или "каковы тенденции продаж отделений Юго-Западного региона в текущем году по сравнению с предыдущим годом?"

Физически гиперкуб может быть построен на основе специальной многомерной модели данных (MOLAP - Multidimensional OLAP ) или построен средствами реляционной модели данных (ROLAP - Relational OLAP ).

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

Система оперативной обработки данных (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 (обработка транзакций в режиме реального времени) участвует в работе конкретной системы. OLTP характеризуется большим количеством коротких онлайновых транзакций (INSERT, UPDATE, DELETE). Основной упор для OLTP-систем заключается в очень быстрой обработке запросов, обеспечении целостности данных в средах с множественным доступом и эффективности, измеряемой количеством транзакций в секунду. В базе данных OLTP есть подробные и текущие данные, а схема, используемая для хранения транзакционных баз данных, - это модель сущности (обычно 3NF). Он включает в себя Запросы, связанные с индивидуальной записью, например "Обновление электронной почты" в базе данных компании.

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

    Очень короткий ответ:

    Различные базы данных имеют разные виды использования. Я не эксперт по базам данных. Когда сомневаюсь, я просто использую SQL.

    Короткий ответ:

    Рассмотрим два примера сценариев:

    Сценарий 1:

    Вы строите интернет-магазин/веб-сайт, и хотите иметь возможность:

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

    Вы хотите найти данные для конкретного пользователя, изменить его имя... В основном выполнять операции INSERT, UPDATE, DELETE для пользовательских данных. То же самое с продуктами и т.д.

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

    Сценарий 2:

    У вас есть интернет-магазин/веб-сайт, и вы хотите вычислить такие вещи, как

    • "общие расходы на деньги для всех пользователей"
    • "какой самый продаваемый продукт"

    Это относится к области аналитики/бизнес-аналитики, поэтому OLAP, вероятно, более подходит.

    Если вы думаете в терминах "Было бы хорошо знать, как/что/сколько"... и включает весь "объект" одного или нескольких видов (например, всех пользователей и большинство продуктов чтобы узнать, сколько всего потрачено), тогда OLAP, вероятно, лучше подходит.

    Более длинный ответ:

    Конечно, все не так просто. Поэтому мы должны сначала поместить маленькие теги, такие как OLTP и OLAP . Каждая база данных должна оцениваться независимо в конце.

    Итак, каково может быть принципиальное различие между OLAP и OLTP?

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

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

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

    Из этого следует, что :

    • Базы данных

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

      С другой стороны, базы данных

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

    Это немного более активное участие, чем это, конечно, и что 20 000 футов обзор того, как базы данных отличаются, но это позволяет мне не заблудиться в море акронимов.

    Говоря об аббревиатурах:

    Разница довольно проста.

    OLTP (обработка транзакций в режиме on-line).

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

    OLAP (он-лайн аналитическая обработка)

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

    OLTP (O n- L ine T ransaction P обработка) vs OLAP ( O n- L ine A nalytical P ) p >

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

    В следующей таблице приведены основные различия между дизайном системы OLTP и OLAP.