Началось все с одной истории, которая три года назад случилась в моей профессиональной карьере, когда я работал в Киргизии, в компании, которая представляла собой сеть розничных магазинов. Тогда у меня произошел разговор с моим директором по IT, который сказал: «Денис, у нас одна из важных, критичных операций - это проведение документа «Чек» на кассах. Как мы можем максимально ускорить этот процесс, распараллелить его, при этом получая оперативные остатки?»

Сразу скажу, что у нас на тот момент использовалась платформа 8.1 и автоматические блокировки. И я тогда ему ответил, что да, мы можем перейти на управляемые блокировки и распараллелить этот процесс на уровне номенклатуры. На что он мне задал естественный вопрос: «а что произойдет, если у нас на нескольких кассах одновременно будет проводиться одна и та же номенклатура?» Тогда я на этот вопрос какого-то внятного ответа дать не смог, но надеюсь, сейчас у меня это получится.

Тренды развития аппаратного обеспечения

Если мы посмотрим на развитие индустрии IT за последние несколько лет , мы увидим определенные тренды в аппаратном обеспечении :

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

Тренды развития бизнес-приложений

А что в это время происходит на уровне бизнеса ? Мы наблюдаем: все большее количество пользователей , которые используют все большее количество устройств , на которых выполняется все большее количество программ , и все это в свою очередь генерирует все большее количество данных .

При этом большинство из этих процессов поддерживаются облаками .

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

Облака и мобильность всегда были связаны между собой, и именно от взаимодействия этих двух сущностей мы в будущем сможем получать какие-то прорывы. Такое взаимодействие привело к появлению известной на Западе стратегии: Mobile-First - Cloud-First (изначально мобильное и изначально облачное).

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

Соответственно, возникает потребность в специальных технологиях . И, если касаться конкретно In-memory OLTP, то это - всего лишь одна из многих технологий, призванных на данный момент обеспечить дальнейшее развитие IT-индустрии.

Технология In-memory OLTP

Почему появилась технология In-memory OLTP? И почему она важна?

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

Соответственно, In- memory OLTP - это: высокопроизводительный механизм , который отвечает современному аппаратному обеспечению и максимально оптимизирован для работы с памятью .

И, что самое важное, In-memory OLTP - это не какой-то отдельный продукт (не какая-то отдельная лицензия, за которую нужно платить). Начиная с SQL Server 2014 In-memory OLTP - это часть ядра этого продукта, которая доступна в рамках редакции Enterprise .

Здесь вы видите три основных компонента, которые представляют собой технологию In- memory OLTP . Именно они позволяют ей осуществить такой прорывной эффект:

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

Сравнение инфраструктуры взаимодействия (традиционной схемы и In-Memory OLTP)

Если мы посмотрим традиционную схему взаимодействия клиента и СУБД , то тут все очевидно:

• У нас есть клиент со своими клиентскими вызовами ,
• Есть сервер 1С:Предприятие , который вмещает всю бизнес-логику .
• И есть сервер СУБД . Он в традиционной схеме используется в основном для манипуляции с данными (а конкретно - для четырех операций: выборка, накопление, изменение и удаление).

В случае применения схемы In- Memory OLTP в рамках платформы 1С, схема чуть-чуть меняется:

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

Яркий пример того, как физический слой «протек» на слой логический.

Основное преимущество In-Memory OLTP

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

Тестовый сценарий для проверки работы технологии In-Memory OLTP в рамках платформы 1С

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

• Я взял очень простую конфигурацию с одним регистром накопления , в котором учитывались остатки по номенклатуре в разрезе количества.
• Также в этой конфигурации было два документа - Приход и Расход , в которых была реализована следующая бизнес-логика:
  • Документ Приход обеспечивал поддержку минимального остатка.
  • А при проведении документа Расход контролировалось отсутствие нулевых остатков.
• Для того чтобы сымитировать конкурентную многопоточную нагрузку при проведении этих документов, я использовал стандартный подход с фоновыми процессами , которых для проведения документа Расход было подавляющее большинство.
• Также следует отметить, что я в своей демонстрационной сети использовал две виртуальные машины :
  • Одну - для сервера 1С:Предприятие ,
  • А другую - для SQL-сервера .

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

Первый замер - базовый показатель

После того, как эта схема была реализована, я провел контрольный замер базовых показателей для стандартного, традиционного проведения документов средствами 1С с использованием управляемых блокировок. Что я получил в результате первого замера?

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

SQL-сервера . - процессоры отдыхают, работают только управляемые блокировки .

Второй замер - миграция в In-Memory только таблиц

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

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

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

Третий замер - миграция в In-Memory и таблиц, и бизнес-логики

На третьем шаге помимо того, что была полностью реализована миграция структур данных в In- memory-таблицы, также была полностью смигрирована и та бизнес-логика , которая была нужна для проведения документов - все действия, необходимые для:

• Формирования документов и их табличных частей;
• Их записи;
• Формирования движений документов;
• И изменения текущих остатков.

В итоге был получен результат 250 документов в секунду . По сути, по отношению к базовому показателю 120 и 250 - это выигрыш чуть больше, чем в два раза.

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

• Сервер 1С:Предприятия полностью загружен ;
• В то время как сервер SQL занят только на треть .

Мне удалось выяснить, что данная нагрузка на сервер 1С:Предприятие показывала, что он просто не успевал сгенерировать это количество документов на лету, а также не успевал их отдавать на проведение SQL-серверу, чтобы полностью его загрузить.

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

Четвертый замер - передача 15 документов для проведения за один вызов

Четвертый замер я сделал в надежде на то, что удастся все-таки за один сетевой вызов отдавать на SQL-сервер побольше работы. Для этого бизнес-логика была переписана таким образом, чтобы за один вызов отдавать на проведение сразу 15 документов . В результате скорость выросла до 550 документов в секунду .

При этом, как видно на графиках, сервер 1С:Предприятие был все так же полностью загружен, а SQL-сервер продолжал «отдыхать» .

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

Пятый замер - запуск подготовленной нагрузки на стороне SQL Server

Следующим шагом я решил сгенерировать всю нагрузку предварительно . Эта нагрузка выглядела в виде 64 сформированных файлов SQL-скриптов на 700 мегабайт . Я перенес их на SQL-сервер , и с помощью известной утилиты OStress, которой можно «скормить» эти файлы, чтобы запустить параллельную нагрузку, получил следующий результат.

• По загрузке процессора - получившееся время отработки поместилось в стандартное окошко диспетчера задач: есть начало нагрузки, потом полностью все процессоры почти
• В результате нагрузки было создано 112 тысяч документов, при этом полностью сохранялись все те процессы, которые были при проведении документов «Расход»: контролировались все остатки, выполнялись все действия.
• Нагрузка заняла 53 с лишним секунды .
• Если сделать определенные вычисления, получится, что среднее время проведения одного документа составило менее половины миллисекунды ,
• а средняя скорость проведения документов составила больше 2000 документов в секунду .

Когда я первый раз получил этот результат - не мог поверить. Просто представьте себе, какие объемы вам теперь доступны, вы теперь можете мыслить в совсем других категориях. И теперь я могу ответить своему бывшему директору по IT, как мы можем ускорить проведение документов «Чек» на кассах. И даже если при этом у нас будут какие-то конфликты, блокировки, сам процесс теперь пройдет очень быстро.

Методология миграции

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

• Например, если сравнить стеки выполнения (традиционный и In-Memory OLTP), то на уровне сетевого взаимодействия ничего не поменялось . Поэтому, если ваша программа (ваше приложение) очень «разговорчивое», обменивается с сервером СУБД очень большим количеством сообщений, то вам технология In-Memory совсем не поможет - здесь нет никаких улучшений.
• Также, если мы посмотрим на уровень журнала регистрации базы данных , то тут тоже особо ничего не поменялось . Хотя размер журнала регистрации при операциях In-memory OLTP сокращается, минимальная задержка транзакций при записи в этот журнал остается той же.
• Основную выгоду вы сможете получить только на уровне выполнения запросов и доступа к данным .

Преимущество технологии In- memory OLTP не в том , что данные располагаются в памяти. Хотя технология и называется In-memory, выигрыш происходит не от этого - ускорение происходит за счет того, что меняется инфраструктура самой базы данных :

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

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

Что можно сказать по поводу самого процесса миграции в In- memory ? Он в целом состоит из двух шагов , которые поочередно повторяются:

• Первый шаг - это миграция структур данных .
• И второй шаг - это миграция вашей критичной .

Решение проблемы записи в In-Memory из 1С

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

С чем связана такая ошибка? Стандартная схема выполнения поддерживает пять уровней изоляции, а механизм In-memory OLTP - только три уровня. При этом платформа 1С по умолчанию использует уровень изоляции ReadCommited, которому как раз нет соответствия в механизме In- Memory OLTP . Соответственно, возникает проблема согласованности между этими уровнями изоляции.

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

В самом SQL Server 2014, в котором как раз и появилась технология In-Memory, есть такое свойство базы данных , как is_ memory_ optimized_ elevate_ to_ snapshot_ on . По умолчанию, оно неактивно, выключено - это можно проверить запросом, который показан на слайде.

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

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

Общая схема миграции бизнес-логики на сторону СУБД

Что же можно сказать по поводу общей схемы миграции самой бизнес-логики на сторону СУБД ?

Она включает в себя два объекта :

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

Вот примерная схема реализация «обертки» . Здесь AddOutcome - это внешний StandardT-SQL-(обертка). Внутри цикла располагается процедура, уже непосредственно скомпилированная в машинные коды. Видно блок TRY (Retry). Соответственно, если возникает конфликт, то происходит исключение, в котором вы, как разработчик, закладываете какой-то период ожидания, чтобы конфликтующая транзакция успела выполниться, а затем, соответственно, выполнится ваша.

Заключение

Ну и в заключение можно сказать, что миграция в таблицы In- Memory OLTPприменительно к 1С потребует задействовать :

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

*****************

Приглашаем вас на новую конференцию .

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

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

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

Сравнение OLTP и OLAP

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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