Рис. 2. OLTP-система
К середине 80-х гг. XX в. практически полностью завершился первый этап оснащения бизнеса и государственных структур средствами вычислительной техники и начался период бурного развития информационных систем для организации сбора и хранения больших массивов различного рода деловой и служебной информации. В основном это были корпоративные системы, предназначенные для оперативной обработки информации, которые обслуживали бухгалтерию, информационные архивы, телефонные сети, регистрацию документов, банковские операции и т.д. С появлением персональных компьютеров такие системы стали доступными для множества мелких и средних фирм, предприятий и организаций. Системы оперативной обработки информации получили название OLTP (On-Line Transaction Processing — оперативная, то есть в режиме реального времени, обработка транзакций).
Определение
Транзакция — некоторый набор операций над базой данных, который рассматривается как единое завершенное, с точки зрения пользователя, действие над некоторой информацией, обычно связанное с обращением к базе данных.
Обобщенная структура системы OLTP представлена на рис. 2.
Рис. 2. OLTP-система
Пример
Типичным примером применения OLTP-систем является массовое обслуживание клиентов, например бронирование авиабилетов или оплата услуг телефонных компаний. Обе эти ситуации имеют два общих свойства: очень большое число клиентов и непрерывное поступление информации.
При бронировании авиабилетов из многочисленных пунктов продажи непрерывно стекается информация об уже проданных билетах, которую вводят со своих рабочих мест операторы-продавцы. В той же БД формируется информация о свободных местах. С точки зрения данной задачи транзакция включает в себя набор таких действий, как:
- запрос оператора о наличии свободных мест на тот или иной рейс;
- отклик БД с предоставлением соответствующей информации;
- ввод оператором информации о клиенте, номере заказанного места и оплаченной сумме (возможно, будет присутствовать еще какая-либо служебная вспомогательная информация);
- передача новой информации в базу данных и внесение в нее соответствующих изменений;
- передача оператору подтверждения о том, что операция выполнена успешно.
Такие транзакции выполняются тысячи раз в день в сотнях пунктов продаж. Очевидно, что основным приоритетом в данном случае является обеспечение минимального времени отклика при максимальной загрузке системы.
Рассмотрим характерные черты данного процесса, свойственные в той или иной мере всем OLTP-системам.
- Запросы и отчеты полностью регламентированы. Оператор не может сформировать собственный запрос, чтобы уточнить или проанализировать какую-либо информацию.
- Как только перелет завершился, информация об обслуживании данного клиента теряет смысл, становится неактуальной и подлежит удалению по прошествии определенного времени (то есть исторические данные не поддерживаются).
- Операции производятся над данными с максимальным уровнем детализации, то есть по каждому клиенту в отдельности.
Ситуация коренным образом меняется, когда руководство авиакомпании принимает решение об изучении пассажиропотоков с целью, например, их оптимизации. Такие исследования могут быть реакцией на информацию о том, что в последнее время во многих пунктах продаж участились случаи нехватки билетов на определенные маршруты, что позволяет сделать предположение о целесообразности организации дополнительных рейсов.
Однако для проведения таких исследований необходимы как минимум три вещи. Во-первых, нужны данные о продажах билетов за достаточно длительный период (несколько месяцев или лет). Во-вторых, данные не должны содержать противоречий, пропусков, аномальных значений и других факторов, которые не позволят выполнить корректный анализ. В-третьих, необходима дополнительная информация о бизнес-среде: о конкурентах, рыночных тенденциях, ценах на топливо и пр. Очевидно, что типичная OLTP-система не может обеспечить ничего из перечисленного. Именно с пониманием этих проблем приходит осознание необходимости использования более развитых систем хранения данных, ориентированных на анализ.
Главное требование к OLTP-системам — быстрое обслуживание относительно простых запросов большого числа пользователей, при этом время ожидания выполнения типового запроса не должно превышать несколько секунд. Со временем в таких системах начали аккумулироваться большие объемы данных — документы, сведения о банковских операциях, информация о клиентах, заключенных сделках, оказанных услугах и т.д.
Постепенно возникло понимание того, что сбор данных не самоцель. Собранная информация может оказаться весьма полезной в процессе управления организацией, поиска путей совершенствования деятельности и получения посредством этого конкурентных преимуществ. Но для этого нужны системы, которые позволяли бы выполнять не только простейшие действия над данными: подсчитывать суммы, средние, максимальные и минимальные значения. Появилась потребность в информационных системах, которые позволяли бы проводить глубокую аналитическую обработку, для чего необходимо решать такие задачи, как поиск скрытых структур и закономерностей в массивах данных, вывод из них правил, которым подчиняется данная предметная область, стратегическое и оперативное планирование, формирование нерегламентированных запросов, принятие решений и прогнозирование их последствий.
Понимание преимуществ, которые способен дать интеллектуальный анализ, привело к появлению нового класса систем — информационных систем поддержки принятия решений (информационных СППР), ориентированных на аналитическую обработку данных с целью получения знаний, необходимых для разработки решений в области управления. Дополнительным стимулом совершенствования этих систем стали такие факторы, как снижение стоимости высокопроизводительных компьютеров и расходов на хранение больших объемов информации, появление возможности обработки больших массивов данных и развитие соответствующих математических методов. Обобщенная структурная схема информационной СППР представлена на рис. 3.
Рис. 3. Структура информационной СППР
В основе работы с такой СППР лежат запросы, с которыми к ней обращается пользователь (лицо, принимающее решение (ЛПР) — менеджер, эксперт или аналитик). При этом запросы, допустимые в традиционных системах оперативной обработки данных, очень примитивны. Например, для банка это может быть запрос типа «Сколько денег на счету клиента?» или «Сколько денег клиент потратил за последний месяц?». Очевидно, что ценность информации, полученной с помощью подобного запроса, невелика. В то же время аналитическая система может ответить на гораздо более сложные запросы, например: «Определить среднее время между выставлением и оплатой счета для каждой категории клиентов».
В процессе разработки систем анализа информации и методологии их применения обнаружилось, что для эффективного функционирования такие системы должны быть организованы несколько иным способом, чем тот, который применяется в OLTP-системах. Это обусловлено следующими причинами.
В связи с этим можно выделить ряд принципиальных отличий СППР и OLTP-систем. Эти отличия представлены в табл. 1.
Таблица 1. Отличия СППР и OLTP-систем
|
Свойство |
OLTP-система |
СППР |
|
Цели использования данных |
Быстрый поиск, простейшие алгоритмы обработки |
Аналитическая обработка с целью поиска скрытых закономерностей, построения прогнозов и моделей и т.д. |
|
Уровень обобщения (детализации) данных |
Детализированные |
Как детализированные, так и обобщенные (агрегированные) |
|
Требования к качеству данных |
Возможны некорректные данные (ошибки регистрации, ввода и т.д.) |
Ошибки в данных не допускаются, поскольку могут привести к некорректной работе аналитических алгоритмов |
|
Формат хранения данных |
Данные могут храниться в различных форматах в зависимости от приложения, в котором они были созданы |
Данные хранятся и обрабатываются в едином формате |
|
Время хранения данных |
Как правило, не более года (в пределах отчетного периода) |
Годы, десятилетия |
|
Изменение данных |
Данные могут добавляться, изменяться и удаляться |
Допускается только пополнение; ранее добавленные данные изменяться не должны, что позволяет обеспечить их хронологию |
|
Периодичность обновления |
Часто, но в небольших объемах |
Редко, но в больших объемах |
|
Доступ к данным |
Должен быть обеспечен доступ ко всем текущим (оперативным) данным |
Должен быть обеспечен доступ к историческим (то есть накопленным за достаточно длительный период времени) данным с соблюдением их хронологии |
|
Характер выполняемых запросов |
Стандартные, настроенные заранее |
Нерегламентированные, формируемые аналитиком «на лету» в зависимости от требуемого анализа |
|
Время выполнения запроса |
Несколько секунд |
До нескольких минут |
Как видно из табл. 1, требования к СППР и OLTP-системам существенно отличаются. Поэтому в СППР используются специализированные базы данных, которые называются хранилищами данных (ХД). Хранилища данных ориентированы на аналитическую обработку и удовлетворяют требованиям, предъявляемым к системам поддержки принятия решений.
В настоящее время однозначного определения ХД не существует, из-за того что разработано большое количество различных архитектур и технологий ХД, а сами хранилища используются для решения самых разнообразных задач. Каждый автор вкладывает в это понятие свое видение вопроса. Обобщая требования, предъявляемые к СППР, можно дать следующее определение ХД, которое не претендует на полноту и однозначность, но позволяет понять основную идею.
Определение
Хранилище данных — разновидность систем хранения, ориентированная на поддержку процесса анализа данных, обеспечивающая целостность, непротиворечивость и хронологию данных, а также высокую скорость выполнения аналитических запросов.
Важнейшим элементом ХД является семантический слой — механизм, позволяющий аналитику оперировать данными посредством бизнес-терминов предметной области. Семантический слой дает пользователю возможность сосредоточиться на анализе и не задумываться о механизмах получения данных.
Типичное ХД существенно отличается от обычных систем хранения данных. Главным отличием являются цели использования. Например, регистрация продаж и выписка соответствующих документов — задача уровня OLTP-систем, использующих обычные реляционные СУБД. Анализ динамики продаж и спроса за несколько лет, позволяющий выработать стратегию развития фирмы и спланировать работу с поставщиками и клиентами, удобнее всего выполнять при поддержке ХД.
Другое важное отличие заключается в динамике изменения данных. Базы данных в OLTP-системах характеризуются очень высокой динамикой изменения записей из-за повседневной работы большого числа пользователей (откуда, кстати, велика вероятность появления противоречий, ошибок, нарушения целостности данных и т.д.). Что касается ХД, то данные из него не удаляются, а пополнение происходит в соответствии с определенным регламентом (раз в час, день, неделю, в определенное время).
Чтобы ХД выполняло функции, соответствующие его основной задаче — поддержке процесса анализа данных, — оно должно удовлетворять требованиям, сформулированным Р. Кимбаллом, одним из авторов концепции ХД:
Чтобы соблюсти все перечисленные требования, для построения и работы ХД, как правило, используется не одно приложение, а система, в которую входит несколько программных продуктов. Одни из них представляют собой собственно систему хранения данных, другие — средства их просмотра, извлечения, загрузки и т.д.
В последние десятилетия технология ХД стремительно развивается. Десятки компаний предлагают на рынке свои решения в области ХД, и тысячи организаций уже используют это мощное средство поддержки аналитических проектов.
|
|
 |
