OLTP - системы оперативной обработки транзакций. OLTP-системы (Системы оперативной обработки транзакций)

05.08.2019 Мобильный интернет

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

OLTP

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

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

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

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

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

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

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

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

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

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

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

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

Относительно недавно начала применяться новая, третья стратегия разработки информационных систем класса 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 секунд.

Вопросы к госэкзамену

    Жизненный цикл КИС. Этапы жизненного цикла КИС

    Модели жизненного цикла КИС (бизнес-приложений)

    Технологические процессы создания КИС

    CASE-средства поддержки жизненного цикла КИС

    Методы и средства структурного системного анализа и проектирования

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

    Корпоративные информационные системы. Их структура. Примеры КИС

    Информационная архитектура КИС. Назначение и состав. Методы и средства описания архитектуры данных

    Инструментарий для проектирования, разработки и сопровождения информационной архитектуры предприятия

    Архитектурные шаблоны (OLTP, OLAP – системы) в информационной архитектуре предприятия

OLAP-системы

OLAP (англ. online analytical processing, аналитическая обработка в реальном времени) - технология обработки данных, заключающаяся в подготовке суммарной (агрегированной) информации на основе больших массивов данных, структурированных по многомерному принципу. Реализации технологии OLAP являются компонентами программных решений класса Business Intelligence.

Основоположник термина OLAP - Эдгар Кодд, предложил в 1993 году «12 законов аналитической обработки в реальном времени».

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

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

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

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

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

Разработка каждого отчёта требует работы программиста.

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

Данные, получаемые от различных структурных элементов компании не унифицированы и часто противоречивы.

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

Создание OLAP-системы на предприятии позволит:

    Интегрировать данные различных информационных систем, создав единую версию правды

    Проектировать новые отчеты несколькими щелчками мыши без участия программистов.

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

Производить мониторинг и прогнозирование ключевых показателей бизнеса

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

Итоги внедрения OLAP-системы

Руководство получает полное ясное видение ситуации и единый механизм учёта, контроля и анализа.

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

Действие OLAP

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

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

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

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

Вместе с базовой концепцией существуют три типа OLAP:

OLAP со многими измерениями (Multidimensional OLAP - MOLAP);

реляционный OLAP (Relational OLAP - ROLAP);

гибридный OLAP (Hybrid OLAP - HOLAP).

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

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

HOLAP использует реляционные таблицы для хранения базовых данных и многомерные таблицы для агрегатов.

Особым случаем ROLAP является ROLAP реального времени (Real-time ROLAP - R-ROLAP). В отличие от ROLAP в R-ROLAP для хранения агрегатов не создаются дополнительные реляционные таблицы, а агрегаты рассчитываются в момент запроса. При этом многомерный запрос к OLAP-системе автоматически преобразуется в SQL-запрос к реляционным данным.

Каждый тип хранения имеет определённые преимущества, хотя есть разногласия в их оценке у разных производителей. MOLAP лучше всего подходит для небольших наборов данных, он быстро рассчитывает агрегаты и возвращает ответы, но при этом генерируются огромные объёмы данных. ROLAP оценивается как более масштабируемое решение, использующее к тому же наименьшее возможное пространство. При этом скорость обработки значительно снижается. HOLAP находится посреди этих двух подходов, он достаточно хорошо масштабируется и быстро обрабатывается. Архитектура R-ROLAP позволяет производить многомерный анализ OLTP-данных в режиме реального времени.

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

Реализации OLAP

Исторически первой многомерной системой управления базами данных, по существу являющейся OLAP-реализацией считается система Express, разработанная в 1970 году компанией IRI (позднее права на продукт были приобретены корпорацией Oracle и превращён в OLAP-опцию для Oracle Database). Термин OLAP ввёл Эдгар Кодд в публикации в журнале Computerworld в 1993 году, в которой он предложил 12 принципов аналитической обработки, по аналогии с 12 правилами для реляционных баз данных, сформулированными им же десятилетием ранее, в качестве референтного продукта, удовлетворяющего предложенным принципам, Кодд указал систему Essbase компании Arbor (поглощённой в 1997 году компанией Hyperion, которую, в свою очередь, в 2007 году купила Oracle). Примечательно, что впоследствии публикация была изъята из архивов Computerworld из-за возможного конфликта интересов, так как Кодд позднее оказывал консультационные услуги для Arbor.

Другие известные OLAP-продукты: Microsoft Analysis Services (ранее называвшиеся OLAP Services, часть SQL Server), SAS OLAP Server, TM1, PowerPlay, SAP BW, MicroStrategy Ingelligence Server, Mondrian, Аналитический комплекс ПРОГНОЗ.

C точки зрения реализации делятся на «физический OLAP» и «виртуальный» (реляционный, англ. Relational OLAP, ROLAP). «Физический», в свою очередь, в зависимости от реализации подразделяется на многомерный (англ. Multidimensional OLAP, MOLAP) и гибридный - (англ. Hybrid OLAP, HOLAP).

В первом случае наличествует программа, на этапе предварительной загрузки данных в OLAP из источников выполняющая предварительный расчёт агрегатов (вычислений по нескольким исходным значениям, например «Итог за месяц»), которые затем сохраняются в специальную многомерную базу данных, обеспечивающую быстрое извлечение и экономичное хранение. Примеры таких продуктов - Microsoft Analysis Services, Oracle OLAP Option, Essbase, SAS OLAP Server, TM1, PowerPlay.

Hybrid OLAP является комбинацией. Сами данные хранятся в реляционной базе данных, а агрегаты - в многомерной.

В ROLAP-реализациях все данные хранятся и обрабатываются реляционных системах управления базами данных, а агрегаты могут не существовать вообще или создаваться по первому запросу в СУБД или кэше аналитического ПО. Примеры таких продуктов - SAP BW, Microstrategy Intelligence Server, Mondrian.

С точки зрения пользователя все варианты выглядят похожими по возможностям. Наибольшее применение OLAP находит в продуктах для финансового планирования, хранилищах данных, решениях класса Business Intelligence.

OL T P-системы (Системы оперативной обработки транзакций)

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

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

Проблема целостности – в обеспечении правильности данных БД в любой момент времени. Она может быть нарушена в след случаях: 1. при вводе и обновлении, когда подаются неверные сведения. 2. когда данным пользуются одновременно несколько userов. 3. при сбоях АПС.

Решение проблем целостности надо рассматривать с программной и организационной точки зрения. Для ПОбл 1. надо ряд организац мероприятий (чтобы следили за вводом), user должен знать правила ввода и ограничения. Для проблем 2-3 – стандартные средства СУБД или спец программные модули. СУБД – 2 основных ограничения целостности: 1. структурные ограничения (задаются функциональными связями и проверяются путем проверки равенства значений БД) 2. ограничения реальных значений. Требуют, чтобы значения поля принадлежали некоторому диапазону, либо это зависимость между значениями некоторых полей. (типы данных и маски ввода). Ограничения могут задаваться АБД в любой момент, но СУБД может не принять ограничение (если много записей ему уже не удовлетворяют), если соответствие есть – записывается в словарь и используется. Ограничения различаются по уровню сложности:

2. ограничения на совокупность атрибутов строки. (должность – разрядные ставки, края – города).

3. ограничения одновременно на множество строк.

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

Должна обладать 4 свойствами: 1. Атомарность (неделимость): выполняется как одинарная операция доступа к БД, должна выполняться полностью или не выполняться совсем. 2. Согласованность – гарантирует взаимную целостность данных после окончания обработки транзакций. 3. Изолированность (каждая транзакция может изменять данное, которое временно находится в несогласованном состоянии). При этом доступ других транзакций к этим данным запрещен, пока транзакция не завершится. 4. долговечности – если транзакция выполнена успешно, то изменения не будут потеряны. Результатом выполнения транзакции может быть её фиксация (действие по фиксации изменений в БД) или откат (отмена транзакции и возврат БД в состояние до начала её). Механизм фиксации и откат основан на использовании журнала транзакций, где сохраняется состояние ДО (в нескольких итерациях) и ПОСЛЕ. Некоторые диалекты SQL включают операторы промежуточной фиксации (откат от точки к точке).

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

На современном рынке мониторов транзакций основными "действующими лицами" являются такие системы, как ACMS (DEC), CICS (IBM), TOP END (NCR), TUXEDO Sytem (Novell).

Совместное использование данных

При реализации транзакций возникает проблема: потеря обновлений (в БД фиксируется только изменения одного userа, остальные теряются). И 2 проблема – чтение незафиксированных данных. Для решения - спец механизмы обработки транзакций. Принципы: 1. транзакция не имеет доступа к незафиксированным данным. 2. результат совместного выполнения транзакций эквивалентен их последнему выполнению. Реализуется этот механизм через систему блокировок: СУБД блокирует часть БД, к которой обращается транзакция до момента её фиксации, т.е. 2-ю транзакцию надо поставить в очередь ожидания. Чем больше блокируемый элемент, тем медленнее обрабатывается транзакция. В системах OLTP обычно блокируется строка, при этом транзакции могут попадать в ситуацию взаимной блокировки. Для предотвращения СУБД периодически опрашивает блокировки и если такое есть, одна из транзакций прерывается. Для более удобной работы допускаются блокировки совместного использования данных: параллельно работающим userам запрещается изменять данные, но разрешается выборка их. Этот подход не единственный, можно, например использовать тиражирование данных в системах с распред доступом. Эта технология предполагает отказ от распределенности данных, и в каждом узле – своя копия БД. Средства, обеспечивающие это должны поддерживать согласованное состояние БД копированием изменений. Процесс переноса изменений исходной БД в БД отдельных узлов называется тиражированием данных. Эти функции выполняет определенный модуль (сервер тираж-я/ репликатор). Схема его работы – полное обновление содержимого БД на удаленных серверах (схема с полн обновлением) или обновление только изменяющихся данных (схема с быстрым обновлением) Если нет необходимости постоянно обновлять данные, то репликатор накапливает изменения и копир-т их в нужный момент.

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

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

    задачи оперативной обработки транзакций;

    задачи пакетной обработки;

    задачи принятия решений.

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

Системы OLTP характеризуются:

    поддержкой большого числа users;

    малым временем отклика на запрос;

    относительно короткими запросами;

    короткими транзакциями;

    участие в запросах небольшого числа таблиц.

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

Сервер оперативной обработки транзакций строится в предположении:

    OLTP- операции поддерживают большое число user;

    наиболее часто используются короткие простые транзакции;

    обычно транзакции не использую одинаковые данные;

    операторы обычно затрагивают небольшое число строк;

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

    только несколько таблиц имеют большие размеры или могут быть изменены.

Реализация такого сервера опирается на:

    физические методики сокращений операций с дисками;

    обработку небольших объемов данных в памяти;

    примитивный оптимизатор запросов;

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

    Хранилища данных и Data Mining

Data Mining переводится как "добыча" или "раскопка данных". Нередко рядом с Data Mining встречаются слова "обнаружение знаний в базах данных" (knowledge discovery in databases) и "интеллектуальный анализ данных". Их можно считать синонимами Data Mining. Возникновение всех указанных терминов связано с новым витком в развитии средств и методов обработки данных.

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

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

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

Специфика современных требований к такой переработке следующие:

    Данные имеют неограниченный объем

    Данные являются разнородными (количественными, качественными, текстовыми)

    Результаты должны быть конкретны и понятны

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

Традиционная математическая статистика, долгое время претендовавшая на роль основного инструмента анализа данных, откровенно спасовала перед лицом возникших проблем. Главная причина - концепция усреднения по выборке, приводящая к операциям над фиктивными величинами (типа средней температуры пациентов по больнице, средней высоты дома на улице, состоящей из дворцов и лачуг и т.п.). Методы математической статистики оказались полезными главным образом для проверки заранее сформулированных гипотез (verification-driven data mining) и для “грубого” разведочного анализа, составляющего основу оперативной аналитической обработки данных (online analytical processing, OLAP).

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

Важное положение Data Mining - нетривиальность разыскиваемых шаблонов. Это означает, что найденные шаблоны должны отражать неочевидные, неожиданные (unexpected) регулярности в данных, составляющие так называемые скрытые знания (hidden knowledge). К обществу пришло понимание, что сырые данные (raw data) содержат глубинный пласт знаний, при грамотной раскопке которого могут быть обнаружены настоящие самородки (рис.1).

Рисунок 1. Уровни знаний, извлекаемых из данных

В целом технологию Data Mining достаточно точно определяет Григорий Пиатецкий-Шапиро - один из основателей этого направления:

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

2. Кому это нужно?

Сфера применения Data Mining ничем не ограничена - она везде, где имеются какие-либо данные. Но в первую очередь методы Data Mining сегодня, мягко говоря, заинтриговали коммерческие предприятия, развертывающие проекты на основе информационных хранилищ данных (Data Warehousing). Опыт многих таких предприятий показывает, что отдача от использования Data Mining может достигать 1000%. Например, известны сообщения об экономическом эффекте, в 10–70 раз превысившем первоначальные затраты от 350 до 750 тыс. дол. . Известны сведения о проекте в 20 млн. дол., который окупился всего за 4 месяца. Другой пример - годовая экономия 700 тыс. дол. за счет внедрения Data Mining в сети универсамов в Великобритании.

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

ИЛИ

Что такое Data Mining

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

Подобного рода информация обычно используется при прогнозировании, стратегическом планировании, анализе рисков, и ценность ее для предприятия очень высока. Видимо, поэтому процесс ее поиска и получил название Data Mining (mining по-английски означает «добыча полезных ископаемых», а поиск закономерностей в огромном наборе фактических данных действительно сродни этому). Термин Data Mining обозначает не столько конкретную технологию, сколько сам процесс поиска корреляций, тенденций, взаимосвязей и закономерностей посредством различных математических и статистических алгоритмов: кластеризации, создания субвыборок, регрессионного и корреляционного анализа. Цель этого поиска - представить данные в виде, четко отражающем бизнес-процессы, а также построить модель, при помощи которой можно прогнозировать процессы, критичные для планирования бизнеса (например, динамику спроса на те или иные товары или услуги либо зависимость их приобретения от каких-то характеристик потребителя).

Отметим, что традиционная математическая статистика, долгое время остававшаяся основным инструментом анализа данных, равно как и средства оперативной аналитической обработки данных (online analytical processing, OLAP), о которых мы уже неоднократно писали (см. материалы на эту тему на нашем компакт-диске), не всегда могут успешно применяться для решения таких задач. Обычно статистические методы и 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. Назовите пути повышения эффективности оперативно-аналитического и интеллектуального анализа в СППР.

Обзор ИТ, предназначенных для оперативной и аналитической обработки данных

Успешно изучив материал, Вы будете знать :

    понятие и основное назначение OLTP-систем;

    понятие и основное назначение OLAP-систем;

    классы OLAP-систем;

    задачи, решаемые OLTP- и OLAP-системами.

После изучения данной темы Вы будете уметь :

    отличать задачи, решаемые OLTP- и OLAP-системами;

    ориентироваться в классах OLAP-систем.

После изучения материала Вы будете обладать навыками использования OLTP- и OLAP-системам в работе менеджера.

Основные понятия к теме 7

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

    технологии, ориентированные на анализ данных и принятие решений. Эти технологии лежат в основе КИСУ, предназначенных для анализа накопленных данных. Называются подобные системы - OLAP (online analytical processing ) системы .

OLAP-системы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

OLTP-системы

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

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

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

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

Задачи, решаемые OLTP- и OLAP-системами

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

Таблица 7.1.
Задачи, решаемые OLTP- и OLAP-системами

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

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

Высокая частота, небольшие «порции»

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

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

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

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

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

Текущие (несколько месяцев)

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

Уровень агрегации данных

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

В основном агрегированные данные

Возможности аналитических операций

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

Последовательность интерактивных отчетов, динамическое изменение уровней агрегаций и срезов данных

Назначение системы

Фиксация, оперативный поиск и обработка данных, регламентированная аналитическая обработка

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

Таблица 7.2.
Сравнение OLTP и OLAP

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

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

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

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

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

Много простых транзакций

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

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

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

охватывающие большой период времени, агрегированные

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

Оперативная, тактическая

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

Тип данных

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

Разнотипные

Основные выводы

    В области ИТ управления существуют два взаимно дополняющих друг друга направления:

    • технологии, ориентированные на оперативную (транзакционную) обработку данных - OLTP (online transaction processing) системы;

      технологии, ориентированные на анализ данных и принятие решений - OLAP (online analytical processing) системы.

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

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

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

    2 класс. Реляционные OLAP-системы (ROLAP). Здесь для хранения данных используются старые реляционные СУБД, а между БД и клиентским интерфейсом организуется определяемый администратором системы слой метаданных. Через этот промежуточный слой клиентский компонент может взаимодействовать с реляционной БД как с многомерной.

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

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

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

Контрольные вопросы

    Какие два взаимно дополняющих друг друга направления существуют в области ИТ управления?

    Сформулируйте основное назначение OLAP-систем

    Сформулируйте основное назначение OL T P-систем

    Что понимается под термином Data Warehousing?

Задания для самостоятельной работы