
- •Оглавление
- •14. Методология idef1 39
- •15. Методология idef3 41
- •1.Классификация экономической информации.
- •2.Классификаторы
- •3.Кодирование экономической информации
- •4.Штриховое кодирование экономической информации
- •5. Понятие и структура архитектуры предприятия
- •6. Контекст и основные элементы бизнес-архитектуры
- •7.Контекст и основные элементы архитектуры информации
- •8.Контекст и основные элементы архитектуры приложений
- •9.Контекст и основные элементы технологический архитектуры
- •10.Сервис-ориентированная архитектура (soa) как основа ссылочной модели архитектуры предприятия
- •11. Архитектура, управляемая моделями (mda)
- •12.Общая схема архитектурного процесса
- •13. Методология idef0
- •14. Методология idef1
- •15. Методология idef3
- •Функциональные модули uob (Unit Of Behavior). Имеют вид прямоугольника со специальными полями (рис.3.12)
- •2. Связи (Links).
- •3. Узлы или перекрестки (Junctions).
- •4. Ссылки (Referents). Ссылки имеют вид прямоугольника со специальными полями (рис.3.13)
- •16. Методология dfd.
- •17.Объектно-ориентированный подход к моделированию эис
- •18. Реинжиниринг бизнес-процессов
- •19. Уровневые архитектуры «клиент-сервер»
- •20. Технологии хранилищ и витрин данных
- •21. Технологии автоматизации операционных задач
- •22. Электронная цифровая подпись
- •23. Технологии систем электронного документооборота
- •2. Хранилище самих документов.
- •3. Компоненты, осуществляющие бизнес-логику системы
- •24. Технологии систем управления контентом
- •26. Планирование и управление всеми производственными ресурсами предприятия (mrp II)
- •27.Технологии автоматизации стратегического управления. Методология управления эффективностью бизнеса (врм)
- •28. Информационные потоки в управленческих структурах
- •29. Информационные технологии производственного предприятия
- •30. Виды и модели Интернет-бизнеса
21. Технологии автоматизации операционных задач
OLTP-приложения предназначены для ввода, структурированного хранения и обработки информации (операций, документов) в режиме реального времени. Ими охватывается широкий спектр задач во многих отраслях - банковские и биржевые операции, в промышленности -регистрация прохождения детали на конвейере, фиксация в статистике посещений очередного посетителя веб-сайта, автоматизация бухгалтерского, складского учета и учета документов и т. п.
Обработка транзакций в OLTP-системах
Транзакцией называют неделимую с позиции воздействия на БД последовательность операций манипулирования данными. Транзакция может состоять из операций чтения, удаления, вставки или модификации данных.
Чтобы использование механизмов обработки транзакций позволило обеспечить целостность данных и изолированность пользователей, транзакция должна обладать четырьмя основными свойствами:
атомарность (atomicity) - транзакция должна полностью выполняться или не выполняться как единая операция доступа к БД;
согласованность (consistency) - выполнение ограничений целостности БД после окончания обработки транзакции;
изолированность (isolation) - разделяемые данные транзакции не доступны другим транзакциям до окончания их изменения,
долговечность (darability) - если транзакция выполнена успешно, то произведенные ею изменения в данных не будут потеряны ни при каких обстоятельствах.
Транзакции, обладающие перечисленными свойствами, иногда называют ACID-транзакциями по первым буквам английских названий свойств.
Результатом выполнения транзакции может быть ее фиксация или откат.
Фиксация транзакции - это действие, обеспечивающее запись в БД всех изменений, которые были произведены в процессе ее выполнения. Если нормальное завершение транзакции невозможно, например, нарушены ограничения целостности БД или пользователь выдал специальную команду, происходит откат транзакции. При откате база данных возвращается в исходное состояние, все изменения аннулируются.
Механизмы синхронизации транзакций основаны на технике блокирования ресурсов. Они позволяют производить обновление данных при параллельной работе пользователей (два пользователя обновляют одну и ту же запись, но разные поля, или один пользователь блокирует строку для обновления, а другой может ее читать). Механизмы управления доступом обеспечивают конкретным пользователям операции над БД в рамках тех полномочий, которые им предоставлены. Полномочия заключаются в возможности либо просто считывать, либо еще и изменять, удалять, создавать объекты БД.
Восстановление данных требуется после аппаратных и программных сбоев. Обычно рассматриваются два возможных вида аппаратных сбоев:
мягкие сбои - внезапная остановка работы компьютера (например, аварийное выключение питания);
жесткие сбои - потеря информации на носителях внешней памяти.
Примерами программных сбоев могут быть:
аварийное завершение работы СУБД (по причине ошибки в программе или в результате некоторого аппаратного сбоя);
аварийное завершение пользовательской программы, в результате которого некоторая транзакция остается незавершенной.
В любом случае для восстановления БД нужно располагать некоторой дополнительной информацией. Наиболее распространенным методом поддержания такой избыточной информации является ведение журнала изменений БД.
Журнал – это особая часть БД, недоступная пользователям СУБД, в которую поступают записи обо всех изменениях основной части БД. При этом придерживаются стратегии "упреждающей" записи в журнал.
При мягком сбое во внешней памяти основной части БД могут находиться объекты, модифицированные транзакциями, не закончившимися к моменту сбоя, и могут отсутствовать объекты, модифицированные транзакциями, которые к моменту сбоя успешно завершились (по причине использования буферов оперативной памяти, содержимое которых при мягком сбое пропадает). Для восстановления сначала производят откат незавершенных транзакций, а потом повторно воспроизводят те операции завершенных транзакций, результаты которых не отображены во внешней памяти.
Для восстановления БД после жесткого сбоя используют журнал и архивную копию БД (полную копию БД к моменту начала заполнения журнала). Восстановление БД состоит в том, что, исходя из архивной копии, по журналу воспроизводится работа всех транзакций, которые закончились к моменту сбоя.
Если БД распределенная, то в распределенной транзакции могут модифицироваться отношения, физически хранящиеся на удаленных вычислительных системах. Логически распределенная транзакция состоит из нескольких локальных и должна фиксироваться только в случае, когда зафиксированы все локальные транзакции ее составляющие. Для практической реализации этих требований в СУБД используют механизм двухстадийной фиксации транзакций (two phase commit). На первой стадии сервер БД, фиксирующий распределенную транзакцию, посылает команду "приготовиться к фиксации" всем узлам сети (серверам БД), задействованным для выполнения локальных транзакций, инициированных распределенной транзакцией. Вторая стадия начинается, когда все локальные СУБД готовы к фиксации. Сервер, обрабатывающий распределенную транзакцию, заканчивает ее фиксацию, посылая команду "зафиксировать транзакцию" всем локальным серверам.
Альтернатива описанному механизму - технология тиражирования данных, предполагающая, что во всех узлах вычислительной системы должна находиться своя копия БД. Функции тиражирования данных выполняет специальный модуль СУБД - сервер тиражирования данных (репликатор). При любых изменениях в тиражируемых данных репликатор копирует их на все остальные узлы системы. Схема тиражирования может быть построена на полном обновлении содержимого таблицы на удаленных серверах