Системы обработки транзакций OLTP и OLAP - технологий. Практика реализации сложных OLTP-систем

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

Основные характеристики хранилищ данных.

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

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

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

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

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

OLAP и OLTP. Характеристики и основные отличия

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

Правила Кодда для OLAP систем

В 1993 году Кодд опубликовал труд под названием " OLAP для пользователей-аналитиков: каким он должен быть". В нем он изложил основные концепции оперативной аналитической обработки и определил 12 правил, которым должны удовлетворять продукты, предоставляющие возможность выполнения оперативной аналитической обработки.

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

Оперативная обработка транзакций (OnLine Transaction Processing - OLTP) - важнейшее средство взаимодействия с информацией, находящейся в внутри «умных» железяк. Между тем, построение сложных, высокопроизводительных OLTP-систем - непростая задача. Многообразие технологий, модные веяния зачастую ставят разработчика в тупик при выборе конкретного решения или заставляют «натягивать» известные технологии на поставленную задачу, что порой ведет к непредсказуемым результатам. Когда в одном проекте фигурирует несколько платформ, задача становится на порядок сложнее.

С точки зрения прикладных задач любая интерактивная система имеет три основных уровня: хранение данных; прикладная логика; представление (интерфейс с конечным пользователем). Соответственно, с точки зрения реализации, система может включать сервер данных, сервер прикладной логики (сервер приложения) и набор интерфейсов для представления информации конечному пользователю. В качестве основы для сервера данных, как правило, используют СУБД SQL-типа, файловые структуры или специальные источники данных. С интерфейсными формами тоже все понятно: можно реализовывать графические интерфейсы, текстовые «зеленые экраны», Web-интерфейсы и т.п. А вот вопрос реализации сервера приложения не так прост, как может показаться на первый взгляд. Если посмотреть на существующие отечественные реализации систем, можно выделить две тенденции:

логика размещается вместе с интерфейсами («толстый» клиент);
логика размещается на стороне сервера данных (встречается гораздо чаще).

В последнем случае, как правило, используются СУБД SQL-типа, которые наделены некоторыми функциями поддержки сервера приложения в виде механизма хранимых процедур. Трехзвенная схема при реализации трансформируется в двухзвенную клиент-серверную архитектуру. Для небольших систем это вполне приемлемое решение, однако такой архитектуре присущ ряд недостатков, в том числе ограниченная масштабируемость. Ее реализация, даже на мощных платформах класса S/390, позволяет достичь пиковой производительности не более 200 транзакций в секунду .

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

Мозаика технологий

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

Опробовав различные технологии и инструменты, мы остановили свой выбор на технологиях IBM, предоставляющей широкий спектр открытых аппаратно-программных решений. Учитывая, что мы реализуем OLTP-проекты для заказчиков, которые часто уже применяют технологии Microsoft, Oracle и других компании, возможность совместного использования решений IBM и альтернативных поставщиков была весьма кстати (рис. 1).

Для реализации особо тонких системных моментов мы прибегаем также к программированию на языках С++ или Кобол, однако это занимает не более 1-2% от общего объема работ.

Монитор транзакций IBM CICS

Монитор транзакций CICS (Custom Information Control System), имеющий богатую историю, более чем за 30 лет своего существования стал в своей области лидером. Именно программное обеспечение промежуточного слоя является надежным хребтом для построения OLTP-систем.

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

Будучи реализован практически для всех основных платформ, CICS позволяет построить сложную распределенную гетерогенную транзакционную среду. CICS использует интерфейс X/Open XA для взаимодействия с различными менеджерами ресурсов и организации интерфейсов с продуктами основных производителей СУБД. Применение монитора транзакций делает систему более масштабируемой по сравнению решениями, «в центр» которых помещена СУБД. Так, на базе стандартных редакций CICS можно строить системы с пиковой производительностью 500 транзакций в секунду, а при помощи специальных версий (например, ПО Transaction Processing Facility, применяемое в системах оперативного резервирования авиабилетов) и с более высокими пиковыми нагрузками.

Заметим, что TPC, отраслевые тесты на пиковую производительность СУБД (www.tpc.org ), проводятся с применением мониторов транзакций, что позволяет получить наилучшие показатели. Почему? Монитор транзакций играет роль «турбонаддува» для СУБД, помимо прочего, ускоряя выполнение SQL-запросов из-за особенностей конструкции как своего ядра, так и интерфейса с СУБД (интерфейс в двухзвенной клиент-серверной архитектуре очень ограничен по производительности). Это позволяет минимизировать время на диспетчеризацию запроса перед его обработкой ядром СУБД. Кроме того, в мониторах транзакций лучше, чем в СУБД, решен вопрос с балансировкой нагрузки .

CICS поддерживает пять типов высокоуровневого взаимодействия между серверами, которые могут быть организованы поверх любых сетевых протоколов (TCP/IP, SNA, NetBIOS и др.).

Function Shipping (FS). Изменение источников данных (файлов), которые являются удаленными по отношению к локальному серверу CICS. При обращении из транзакции на локальном сервере CICS к такому источнику, он автоматически перенаправляет запрос к тому серверу, который владеет этим источником данных. Обеспечивается целостность данных в случае каких-либо сбоев.
Transaction Routing (TR). Перенаправление вызова транзакции между серверами CICS. Можно «переселять» транзакцию с сервера на сервер, при этом требуется лишь переопределить ссылку на сервере CICS без изменения кода программы.
Asynchronous Processing (AP). Асинхронный запуск транзакции на другом сервере CICS. Новая транзакция начинает «жить» самостоятельно, а управление немедленно возвращается в вызвавшую транзакцию.
Distributed Program Link (DPL). Вызов удаленной транзакции с возвратом управления после окончания работы вызванной транзакции. Этот тип взаимодействия в прикладных системах используется наиболее часто.
Distributed Transaction Processing (DTP). Диалог в оперативном режиме двух транзакций, работающих на разных серверах CICS. С точки зрения разработки и отладки это наиболее экзотический и сложный тип взаимодействия.

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

Транзакционный сервер очередей MQSeries

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

MQSeries может быть подключен к монитору транзакций CICS наравне с СУБД. В этом случае CICS выступает как внешний координатор транзакций (External Transaction Coordinator - ETC), что исключает ситуации, когда при каком-либо сбое данные в СУБД были изменены, а сообщение не отправлено или наоборот - данные не изменились, а сообщение об изменении было отправлено. Это, в конечном счете, приводит к ситуации рассогласования данных на распределенных узлах OLTP-системы. Использование монитора транзакций позволяет избежать таких ситуаций.

Возглавляя рынок MOM (более 70%), MQSeries дополняет CICS возможностью построения сложной гетерогенной распределенной транзакционной среды с асинхронным типом взаимодействия.

DB2 Universal Database

DB2 - флагманская СУБД корпорации IBM. Ее применение в качестве основы сервера данных OLTP-систем позволяет реализовать сложную обработку данных и хранение больших массивов. Эти функции перекладываются на сервер данных, разгружая сервер приложения. Но если необходимо сделать систему, где хранение и обработка данных не очень сложны, а требования к производительности и минимизации ресурсов выходят на первый план (код ядра СУБД требует значительных ресурсов), то можно использовать файловые структуры, подключенные к транзакционному серверу CICS. Например, многие известные крупные западные OLTP-системы для мэйнфреймов S/390 построены на базе CICS и VSAM.

WebSphere Application Server

Семейство программных продуктов, обозначаемых маркой WebSphere Application Server, включает три версии - Standard, Advanced и Enterprise. Если говорить о поддержке транзакционности, то версия Standard этой службы не имеет, версия Advanced поддерживает службу Java Transaction Service (JTS), равно как и спецификации Enterprise JavaBeans, а версия Enterprise содержит специальные коннекторы для взаимодействия с «полноприводными» транзакционными системами наподобие CICS.

Говоря о WebSphere, часто имеют в виду только Internet-составляющую этого продукта - Application Server , мощный кросс-платформный сервер приложений, поддерживающий практически все известные спецификации и протоколы.

В реальных проектах мы избегаем программирования бизнес-логики средствами языка Java, поскольку реализация сервера приложения, например, в формате Enterprise JavaBeans, приводит к значительному снижению производительности приложения и заставляет вести разработку на языке третьего поколения, что менее эффективно по сравнению с инструментарием VisualAge Generator. Однако применение Web-браузеров на рабочих местах дает определенные преимущества для интерактивных систем: не надо платить за дополнительные лицензии для клиентских машин; имеется возможность отображать графическую информацию; нет необходимости копировать приложение по клиентским местам.

Обеспечение соединения браузеров с мощными системами «заднего плана» (back-end) требует применения Internet-серверов. WebSphere Application Server можно рассматривать как своего рода адаптер, который позволяет коду из браузера через вызов сервлета (servlet) обратиться к транзакции в CICS и, получив результат, возвратить его в браузер, создав на ходу интерфейсную HTML-страницу.

Заметим, что для OS/390 поддерживается интерфейс CICS Web Support, посредством которого браузер может напрямую подсоединиться к серверу CICS. Но для унификации архитектуры между платформами и, учитывая, что средство разработки приложений VisualAge Generator строит системы с использованием WebSphere Application Server, мы применяем этот продукт и на S/390. Это помогает решить проблемы переноса кода таких приложений между платформами.

Разработка на VisualAge Generator

VisualAge Generator - средство быстрой разработки приложений. Именно этот продукт является тем «клеем», который позволяет достаточно просто соединить все перечисленные выше технологии в единую картину.

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

Цикл разработки приложения средствами VisualAge Generator выглядит несколько иначе (рис. 3). В основе этой среды разработки лежит универсальная виртуальная машина Universal Virtual Machine (UVM), которая является базой для таких сред разработки, как VisualAge for Smalltalk и VisualAge for Java, поверх которых устанавливается VisualAge Generator.

Для запуска и отладки приложения нет необходимости производить компиляцию и сборку приложения. Для отладки работы логики и интерфейсных форм пользуются «малым» циклом (операции 1 и 2), что сокращает время разработки и не требует наличия целевой платформы. В этом цикле производится 80-90% работ и можно обойтись компьютером с Windows NT или OS/2, на котором может быть установлен VisualAge Generator Developer.

После того, как приложение отлажено, можно перейти к созданию кода времени выполнения (runtime) как для серверных, так и для клиентских платформ. При этом целевая платформа нужна только на момент выполнения операции 3. Замечу, что хотя в VisualAge Generator можно создавать приложения любой архитектуры, основное его предназначение - это разработка многоуровневых систем с четким разделением сервера данных, сервера приложения и уровня представления. В качестве клиентских интерфейсов поддерживаются графические, текстовые и Web-ориентированные интерфейсы. Цикл генерации исполняемого кода клиента значительно короче, чем для серверных компонентов. Фактически эта генерация производится в один этап, в результате которого создаются все необходимые компоненты для запуска приложения на клиентской стороне.

В качестве целевой платформы для сервера приложения поддерживаются более 20 платформ, включая CICS и MQSeries. После создания серверного кода времени исполнения его можно отлаживать из среды VisualAge Generator, т.е. проверить работоспособность окончательного кода (большой цикл из операций 3, 4, 5, 6).

В составе VisualAge Generator отсутствуют инструменты для разработки и программирования серверов данных, например, СУБД. Но, имея готовую структуру базы данных, можно автоматически создать всю структуру приложения, включая серверные и клиентские компоненты при помощи средства VisualAge Generator Templates (VAGT), которое входит в поставку. Предопределив некоторые условия, можно автоматически создать практически полную инфраструктуру приложения, что составляет до 80% работ по программированию. Это избавляет разработчика от «ручного» создания таких элементов, как серверные программы, процессы, бизнес-объекты, элементы форм, обработчики исключительных ситуаций и т.д. Учитывая, что в реальных проектах такие элементы исчисляются сотнями и тысячами, VAGT значительно сокращают время создания кода приложения. Далее необходимо лишь наполнить приложения соответствующей бизнес-логикой, которая пишется на языке 4GL.

«Обобщающее обобщение»

На рис. 4 показана общая архитектура распределенной OLTP-системы, которая базируется на описанных технологиях.

Основой системы является CICS (CICS A, например, на платформе Windows NT, CICS B - на платформе S/390). Два этих транзакционных сервера могут взаимодействовать как синхронно (TR, AC, FS, DPL, DTP), так и асинхронно, через MQSeries (менеджеры MQ1 и MQ2 для соответствующих платформ). Менеджеры очередей подсоединены к соответствующим серверам CICS через интерфейс XA. Также к серверам CICS подсоединены различные источники данных (на Windows NT - DB2 и/или СУБД Oracle и Microsoft SQL Server, на S/390 - DB2 и файловые структуры VSAM, которые определены в CICS через Resource Definition Online).

WebSphere Application Server (WSAS) играет роль конвертора вызовов от Web-клиентов к системе «заднего плана» (транзакции P1, P2, P3), написанной на VisualAge Generator.

VisualAge Generator Server (VAGen Srv) - платформнозависимый продукт, необходимый для запуска программ, разработанных на VisualAge Generator.

Возможны прямые соединения с CICS для клиентов с графическим или текстовым интерфейсом пользователя. При этом программы P1, P2 в CICS A могут быть определены как удаленные, тогда их вызовы в CICS A будут автоматически перенаправлены методом TR в CICS B и там запущены. P3 - локальная транзакция в CICS A, которая может посылать сообщения в CICS B через MQSeries.

Надо сказать, что экземпляры CICS, подобные CICS A и CICS B (в CICS их обозначают термином «регион») могут находиться не только на разных машинах, но и на одном сервере или в кластере. Работа регионов изолирована и «падение» одного из них не влияет на работу других. Это так же дает преимущества в масштабируемости, позволяя разделить задачи по регионам с точки зрения специализации. Такой подход наиболее часто практикуется на системах S/390, особенно в кластерах Sysplex. Реальные системы имеют несколько сотен регионов и десятки тысяч транзакций.

Однако сама по себе технология без соответствующих инструментов не дает ожидаемого «выхлопа». Скажем, CICS очень хорош, но если вы попробуете реализовать систему на С++ или Коболе, то это потребует от разработчика бизнес-логики хорошего знания как языка программирования, так и API-интерфейсов CICS, которые сродни API-интерфейсам операционных систем. Масса времени будет потрачена на создание инфраструктурных элементов (описание функций, переменных и т.д.) и отладку такого проекта. Но если взять VisualAge Generator, это избавит разработчика бизнес-логики от необходимости знать CICS, позволив ему сосредоточиться на своих прямых задачах. Конечно, для реализации сложных проектов требуется владение CICS, но это требование уже распространяется не на всех разработчиков, а на двух-трех специалистов, отвечающих за среду выполнения приложения.

«Сплав» технологий и инструментов как раз и дает оптимальный результат; рассмотрение же отдельных продуктов вне системного прикладного контекста для разработчиков сложных не «коробочных» решений не имеет большого смысла. Точно так же мало проку судить о СУБД вне рамок прикладной задачи. Скажем, вы большой поклонник Oracle. Но что делать, если заказчик требует приложение для целевой платформы AS/400? Или у вас большая любовь к DB2, а прикладная система заказчика на S/390 использует VSAM и заказчика полностью устраивает, и речь идет лишь о замене «зеленого» экрана на Web-браузер, чтобы, к примеру, показывать не только алфавитно-цифровые данные.

Реализация OLTP-системы для Внешторгбанка

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

В качестве центрального узла OLTP-системы используется S/390; возможно использование кластера Sysplex. В качестве «банковской машины» применяется пакет от Altel, реализованный на базе CICS TS, VSAM и имеющий «зеленый» интерфейс формата 3270. Кроме центрального узла банк имеет несколько десятков периферийных узлов, в которых используются серверы AS/400 и Windows NT (рис. 5).

Взаимодействие серверов осуществляется посредством MQSeries. Для того чтобы разработчики прикладной логики были изолированы от механизмов вызова транзакций из серверных процессов, написанных на 4GL в VisualAge Generator, была использована методика и набор программ («оборачивающие» транзакции), при помощи которых можно обращаться к функциям из 4GL. Стремясь унифицировать интерфейсы доступа к данным и снизить расходы на рабочие места, заказчик выдвинул требование использования Web-интерфейсов. При этом работа через Web-браузер должна вестись не по принципу «один к одному», как через терминалы 3270, а через HTML-страницу, создаваемую несколькими экранами 3270. При этом необходимо было обеспечить совместимость с системой безопасности. Все это порождало ряд проблем, которые пришлось решать в комплексе.

Проблема № 1. Для вызова транзакции CICS, которая работает с «зеленым экраном», используется протокол EPI (External Presentation Interface), работающий с потоком 3270. При активизации такой транзакции CICS использует терминальное устройство - структуру, которая идентифицирует соединение и является основным атрибутом для транзакции. Так, эта структура содержит четырехсимвольное поле TERMID (идентификатор терминала), которое используется транзакциями для собственной системы безопасности. Такой тип соединения в CICS называют терминальным.

Однако соединение, которое строится для работы Web-браузера, НЕ является терминальным, т. е. для этого соединения НЕ существует такой структуры (в понимании транзакции 3270), что сразу приведет к сбою выполнения транзакции.

Для вызова транзакций 3270 из нетерминальных соединений или из других транзакций CICS, которые были вызваны через протокол ECI (External Call Interface), в мониторе CICS для OS/390 был реализован механизм, называемый 3270 Bridge. Была добавлена новая команда EXEC CICS START BREXIT и при активизации транзакции 3270 через эту команду, CICS создает специальную структуру, называемую Bridge Facility, так называемый суррогатный терминал, который «предъявляется» транзакции 3270 в момент ее инициализации. Но при создании суррогатного терминала CICS самостоятельно генерирует идентификатор для поля TERMID по своей внутренней логике. Этот сгенерированный TERMID никак не связан с реальным идентификатором пользовательского соединения. Это и порождает проблему № 2.

Команда EXEC CICS START BREXIT не поддерживается и со стороны VisualAge Generator - нельзя установить такие параметры, чтобы он сгенерировал команду вызова, так как она появилась только в последних версиях CICS (начиная с версии 1.3). Для решения этой проблемы на Коболе была написана программа, принимающая необходимые параметры и активизирующая транзакцию через эту новую команду. Это пример использования Кобола как языка третьего поколения для реализации тонких системных функций. Программу на Коболе можно вызывать из прикладных транзакций, написанных на 4GL в VisualAge Generator.

Проблема № 2. Для вызова транзакции 3270 используется механизм 3270 Bridge, который создает суррогатный терминал. Но некоторые поля, включая TERMID, CICS инициализирует сам, никак не привязываясь к клиентскому соединению, из которого вызывается эта транзакция. CICS для каждого такого вызова ставит TERMID в значение из интервала с?{AAA? по?{999?, увеличивая его последовательно. Использует стратегию безопасности, которая пришла еще со времен до эпохи SQL - каждому клиенту присваивается для входа через VTAM (Virtual Telecommunication Access Method) восьмисимвольный идентификатор, называемый LU (Logical Unit), который проверяет VTAM. Четыре последних символа из LU берутся для генерации TERMID. Транзакция, отвечающая за идентификацию пользователя, принимает с клавиатуры имя пользователя и его пароль, берет TERMID и смотрит в свой внутренний файл, в котором ищет соответствие имени пользователя и TERMID. Это гарантирует, что данный пользователь может обращаться к системе только с определенного компьютера, так как при конфигурировании SNA-соединения на стороне сервера прописывается и MAC-адрес сетевой платы клиентского компьютера. Но web-соединения идут в обход VTAM и не имеют терминального устройства. Каким образом передавать TERMID или нечто, заменяющее его, чтобы минимизировать переделку транзакций?

Эта проблема была решена путем задействования пользовательской области терминала (Terminal Control Table User Area - TCTUA), нашей собственной транзакции 3270 первичной аутентификации пользователя и инициализации TCTUA, написанной на VisualAge Generator. Это привело к минимизации переделок в транзакции, которая свелась к замене слова?TERMID? на?TCTUA? в «кобольных» текстах.

Помимо этого, были проблемы с реализацией вызова последовательности 3270-транзакций в рамках одной 4GL-транзакции с промежуточной обработкой результатов: было необходимо обрабатывать и передавать параметры («экраны») для каждого вызова 3270.

Распределенная OLTP-система с интеграцией унаследованных программ

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

Компания Panasonic использует программу PSI для AS/400 и для Windows NT. При этом на AS/400 программа использовала в качестве структуры данных собственные таблицы и таблицы из ERP-системы J.D. Edwards, работающей на этом сервере. Сервер AS/400 находится в Хельсинки, а серверы NT - в Москве и Киеве, причем связаны между собой не очень надежными линиями. Между тем, логика работы программы PSI должна обеспечивать доставку информации к узлам через сервер AS/400. Существующая версия использовала механизм репликации баз данных, что в условиях плохих линий связи было неприемлемо.

Для решения этой проблемы была предложена модель транспортной системы между серверами на базе MQSeries. При этом не требовалось изменять код существующего приложения PSI, которое отвечало за взаимодействие с конечным пользователем, а предлагалось задействовать триггерные механизмы баз данных. Т. е., на необходимые таблицы «подсаживались» триггеры, которые для каждой операции (вставка, удаление, редактирование) посылали соответствующие сообщения в систему MQSeries. Эти сообщения, попав на AS/400, рассылались во все остальные узлы системы.

Это решение поддерживает использование нескольких баз данных (в среде NT) и библиотек (в среде AS/400) для возможности отладки или других целей. При этом при помощи специальных утилит можно назначить, откуда и куда будут передаваться данные для конкретной таблицы. Набор и структура таблиц в базе данных жестко заданы. Для реализации этого проекта были задействованы как MQSeries и VisualAge Generator, так и программирование на C++. На NT были реализованы триггерные мониторы MQSeries в виде служб NT, а на AS/400 - триггеры DB2.

В данном проекте, на первом этапе, каждая операция в базе порождала одно сообщение с соответствующим кодом операции (I - insert, D - delete, U - update), которое расшифровывалось на удаленных узлах. Но в реальности оказалось, что программа PSI изменяет ключевые поля, что вообще-то не рекомендуется. Это делает невозможным выполнение операции U («изменить») на удаленном узле, так как записи с измененным ключевым полем там еще не существует и СУБД не может ее найти. Вставить в структуру таблиц собственные ключевые поля было нельзя, так как использовались таблицы приложения J.D. Edwards, структуру которых менять нельзя. После анализа ситуации, с тем, чтобы решить проблему с минимальными переделками, было предложено вместо одного сообщения с кодом U соответствующий триггер стал посылать пару сообщений: первое - с кодом D («удалить») и старым значением ключа; второе - с кодом I («вставить») и новым значением ключа.

Эта система пропускает в сутки около 60 тыс. сообщений средней длины около 2 Кбайт. Проект был реализован за 8 недель силами 4 инженеров.

Литература

Masaharu Murozumi, A Challenge To A High Transaction Volume Client/Server DB2 Data Shared OLTP System. IBM, 2000

Г. Ладыженский, Технология «клиент-сервер» и мониторы транзакций. «Открытые системы», 1994, № 3

М. Рузинкевич, А. Цикоцки, Определение и выполнение потоков транзакций. «СУБД», 1995, № 2

E. Cobb, J. Hamilton, G. Sharman, Do I Need A Transaction Processing Monitor and a Database? IBM, 1996

Николай Игнатович, IBM MQSeries: архитектура системы очередей сообщений. «Открытые Системы», 1999, № 9-10

Николай Игнатович, Интеграция технологий управления данными в DB2. «Открытые системы», 2001, № 7-8

P. Wakelin, S. Day, S. Read, F. McKenna, CICS Transaction Gateway V3.1. The WebSphere Connector for CICS. SG24-6133-00, IBM, 2001

Илья Афанасьев ([email protected]) - генеральный директор компании «Диджитал Эмпайр», (Москва).

Основные типы программного обеспечения промежуточного слоя

Монитор распределенной обработки транзакций (distributed transaction processing monitor). Контроль выполнения интенсивного потока транзакций в системах оперативной обработки транзакций в многоплатформенной среде.
Удаленный вызов процедур (remote procedure call - RPC). Синхронизация взаимосвязи процессов, путем их удаленного вызова. Транзакционность не поддерживается.
Взаимосвязь баз данных (database connectivity). SQL-запрос, направленный через это программное обеспечение, может обработаться несколькими СУБД от разных производителей.
Обработчик объектных запросов (object request broker - ORB). Обмен программными объектами между различными платформами и по различным протоколам.

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

ПО промежуточного слоя, основанное на передаче сообщений (message oriented middleware - MOM). Асинхронный обмен сообщениями между приложениями, которые могут выполняться на различных платформах. Обмен производится с гарантированной доставкой; при потере соединения операция будет автоматически возобновлена после восстановления.

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

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

понятие и основное назначение 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?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Проблемы:

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

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

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

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

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

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

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

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

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

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

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

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

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