Asp технология обработки транзакций


Содержание

Системы обработки транзакций

Читайте также:

  1. A14 — СДВОЕННЫЙ ПРЕСС С ПРОГРАММНЫМ УПРАВЛЕНИЕМ ДЛЯ ОБРАБОТКИ ПОЛОЧЕК ПИДЖАКА
  2. CRM системы
  3. II. История развития налогов и налогообложения в СССР. Становление налоговой системы современной России
  4. II. Понятие агроэкосистемы
  5. II. Структура Системы сертификации ГОСТ Р и функции ее участников
  6. III. Впишите пропущенные названия структурных компо­нентов в системы воспитательного процесса, выделен­ные по различным критериям.
  7. III. Городские экосистемы
  8. ISO 14004:2004 «Системы экологического менеджмента. Руководящие указания по принципам, системам и методам обеспечения функционирования».
  9. IV. ГОРОДСКИЕ СИСТЕМЫ ЭНЕРГОБЕСПЕЧЕНИЯ
  10. IX. ОРГАНЫ КРОВЕТВОРЕНИЯ И ИММУННОЙ СИСТЕМЫ
  11. MRP, MRPII, ERP -системы. Определения. Общее и различия в применении.
  12. T Команды арифметической и логической обработки

Шесть основных типов информационных систем

На рис. 2.2 показаны основные типы информационных систем, которые предназ­начены для конкретных организационных уровней. Организация использует си­стемы поддержки принятия решений (СППР) на стратегическом уровне, управ­ленческие системы (УИС) и системы поддержки принятия стратегических решений (СППСР) на управленческом уровне; системы работы с данными(СРСЗ) и офис­ные системы на уровне знаний; системы обработки транзакций (СОТ) на опе­рационном уровне. На каждом уровне информационные системы обслуживают определенную функциональную область. Таким образом, типичные системы, ра­ботающие в организациях, предназначены для помощи рабочим и менеджерам на каждом уровне в выполнении маркетинговых, производственных, финансовых и других функций.

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

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

Таблица 2.1
Характеристики систем обработки информации
Тип системы Ввод информации Обработка информации Вывод информации Пользователи
СППСР Агрегированные данные: внешние, внутренние Графика; моделирование; интерактивность Проекции; отклики на запросы Старшие менеджеры
СППР Небольшие объемы данных или массивные базы данных, опти-мизированные с целью выполнения анализа данных; аналитические модели и инструменты анализа данных Интерактивность;моделирование;анализ Специальныеотчеты; анализ решений; отклики на запросы Профессионалы;менеджеры службы персонала
УИС Данные суммарных транзакций; большие объемы данных; простые модели Процедурные отчеты; простые модели; низкоуровневый анализ Сводные отчеты, а также отчеты по исключениям Менеджеры среднего звена
СРСЗ Спецификации проекта; база знаний Моделирование; имитации Модели; графика Профессионалы; технический персонал
Офисные системы Документы; кален- дарные планы Управление документами; календарное планирование; коммуникация Документы; календарные планы; почта Клерки
СОТ Транзакции; события Сортировка; вывод списка; слияние. обновление Детализиро-ванные отчеты; списки; сводки Операционный персонал; администраторы

Transaction processing systems (TPS) (системы обработки транзакций)

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

На операционном уровне все цели, задачи и ресурсы предопределены заранее и четко структурированы. Например, решение о предоставлении заказчику кре­дита, принимаемое инспектором, основывается на заранее установленных крите­риях. Сотрудник просто проводит проверку соответствия условиям всех указан­ных критериев.

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

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

Другие типичные системы обработки транзакций представлены на рис. 2.4 (реализованы в виде популярных приложений). На иллюстрации видно, что та­кие системы подразделяются на пять функциональных категорий: торговля/мар­кетинг, производство, финансы/бухгалтерия, трудовые ресурсы и другие типы систем, предназначенные для использования в специфических случаях/условиях. Система отслеживания движения посылок, которая используется службой и опи­сана в гл. 1, представляет собой типичный пример производственной системы обработки транзакций. Служба UPS отправляет посылки службам доставки, а си­стема следит за всеми происходящими при этом транзакциями.

Системы обработки транзакций зачастую являются стержневыми структура­ми компаний, поскольку малейший сбой в их работе может привести к серьезным нарушениям в деятельности организации (и связанных с ней фирм). Только пред­ставьте себе, что произойдет, если система отслеживания посылок службы UPS перестанет работать! Как смогут функционировать авиакомпании без систем ре­зервирования мест в самолетах?

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

Дата добавления: 2015-04-29 ; Просмотров: 2701 ; Нарушение авторских прав? ;

Нам важно ваше мнение! Был ли полезен опубликованный материал? Да | Нет

OLTP — системы оперативной обработки транзакций

Режим оперативной обработки транзакций OLTP

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Технология оперативной обработки транзакции

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

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

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

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

Имеется три основных типа транзакций: транзакции извлечения, транзакции обновления и смешанные транзакции.

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

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

Смешанные транзакции включают в себя как операции извлечения, так и операции обновления данных. Примером смешанной транзакции является поиск и отображение подробных сведений об объекте недвижимости (по заданному номеру объекта) с последующим изменением месячной арендной платы.

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

Любая транзакция всегда должна переводить базу данных из одного согласованного состояния в другое, хотя допускается, что согласованность состояния базы будет нарушаться в ходе выполнения транзакции. Любая транзакция завершается одним из двух возможных способов. В случае успешного завершения результаты транзакции фиксируются (commit) в базе данных, последняя переходит в новое согласованное состояние. Если выполнение транзакции не увенчалось успехом, она отменяется. В этом случае в базе данных должно быть восстановлено то согласованное состояние, в котором она находилась до начала данной транзакции. Этот процесс называется откатом (roll back) транзакции. Зафиксированная транзакция не может быть отменена. Если оказывается, что зафиксированная транзакция была ошибочной, потребуется выполнить другую транзакцию, отменяющую действия, выполненные первой транзакцией. Эту транзакцию называют компенсирующей. Следует отметить, что отмененная транзакция может быть еще раз запущена позже и в зависимости от причин предыдущего отказа вполне успешно завершена и зафиксирована в базе данных.

Никакая СУБД не обладает внутренней возможностью установить, какие именно изменения должны быть восприняты как единое целое, образующее одну логическую транзакцию. Следовательно, должен существовать метод, позволяющий указывать границы каждой из транзакций извне, со стороны пользователя. В большинстве языков манипулирования данными для указания границ отдельных транзакций используются операторы BEGIN TRANSACTION, COMMIT и ROLLBACK (или их эквиваленты). Если эти ограничители не были использованы, вся выполняемая программа расценивается как единая транзакция. СУБД автоматически выполнит команду COMMIT при нормальном завершении этой программы. Аналогично в случае ее аварийного завершения в базе данных автоматически будет выполнена команда ROLLBACK.

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

  • * Атомарность. Это свойство типа “все или ничего”. Любая транзакция представляет собой неделимую единицу работы, которая может быть либо выполнена вся целиком, либо не выполнена вовсе.
  • * Согласованность. Каждая транзакция должна переводить базу данных из одного согласованного состояния в другое согласованное состояние.
  • * Изолированность. Все транзакции выполняются независимо одна от другой. Другими словами, промежуточные результаты незавершенной транзакции не должны быть доступны другим транзакциям.
  • * Продолжительность. Результаты успешно завершенной (зафиксированной) транзакции должны сохраняться в базе данных постоянно и не должны быть утеряны в результате последующих сбоев.

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

Глава 20. Обработка транзакций

Замечание для руководителя отдела ИС

Многие идеи относительно обработки транзакций, возникшие еще в начале 80-х годов, в особенности представления о более развитых моделях, чем простые «плоские» транзакции, только сейчас начинают находить применение в коммерческих системах. Архитектура ваших приложений, как находящихся в стадии разработки, так и планируемых на будущее, будет существенно зависеть от используемых моделей обработки транзакций. Многозвенные (chained) и вложенные (nested) транзакции, например, позволят создавать распределенные приложения существенно иной структуры и, можно надеяться, значительно более эффективные, чем при наличии лишь рудиментарных моделей. Материал этой главы (в которой вопросы информационного управления рассматриваются под углом зрения структуры прикладных систем) представляет исключительную важность.

20.1. Введение

На протяжении всей этой книги мы обсуждали концепции обработки транзакций (TP — transaction processing) и связанные с этим тенденции. Мы рассмотрели роль обработки транзакций в управлении распределенными базами данных и информационными системами, а также требования к ТР в объектно-ориентированных базах данных.

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

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

20.2. Основы обработки транзакций

Мы можем рассматривать обработку транзакций в самом общем виде, включая множество парадигм — от пакетной и простой терминально-интерактивной обработки (на самом деле концептуальными источниками компьютерной обработки транзакций можно считать шумерские глиняные таблички с записями торговых операций, сделанными за многие тысячелетия до зарождения идеи вычислительной машины) 1) . Более конкретно, дисциплина ТР включает в себя различные функции для поддержки компьютерных приложений, основанных на коммуникациях. В самом общем смысле системы обработки транзакций могут охватывать все, что может присутствовать в компьютерной системе, — базы данных, репозитории, а также сети и операционные системы 2) .

Мы сосредоточим свое внимание на базовых сервисах, присущих разным поколениям систем обработки транзакций, подобно тому, как выделяем поколения языков программирования (говоря об языках 3GL, 4GL, 5GL) или поколения баз данных (например, в гл. 1 мы обсуждали «Манифест баз данных третьего поколения», а в гл. 23 рассмотрим системы баз данных четвертого поколения). В области обработки транзакций имеет место следующая классификация (рис. 20-1) 3) .

Рисунок 20-1.
Поколения систем обработки транзакций.

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

    Хотя понятие «обработка транзакций» применимо практически к любой компьютерной среде, в особенности в мире бизнеса, однако традиционно использование мониторов обработки транзакций ограничивалось окружениями крупномасштабных центров обработки данных, функционирующих на базе мэйнфреймов, в таких прикладных областях, как резервирование авиабилетов или международные банковские операции 4) . За последние годы, отчасти за счет того, что корпоративные информационные системы все более приобретают черты распределенности и неоднородности, мониторы обработки транзакций стали применяться и во многих других вертикальных приложениях (здравоохранение, страхование, торговля). По оценкам Gartner Group, к 1995 г. в 50% вновь создаваемых приложениях на основе реляционных СУБД будут применяться средства обработки транзакций 5) .

    Обратимся теперь к фундаментальным принципам и основным моделям транзакций, которые определяют пути применения ТР в информационных системах.

    20.3. Принципы и модели обработки транзакций

    Ко всем типам транзакций предъявляется набор требований, известный под названием ACID (atomocity, consistency, isolation, durability). Смысл этих требований заключается в следующем 6) .

  • Атомарность. Транзакция представляет собой некоторый набор действий. Система обеспечивает их выполнение по принципу «все или ничего» — либо выполняются все действия, т. е. транзакция фиксируется, либо не выполняется ни одно, т. е. транзакция прерывается.
  • Согласованность. Предполагается, что в результате транзакции система переходит из одного абстрактного корректного состояния в другое. Понятие транзакции позволяет программисту декларировать условия таких согласованных состояний данных, а системе — подтверждать согласованность, производя описанные в приложении проверки.

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

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

    20.3.1. Плоские транзакции

    Модели плоских транзакций соответствует один управляющий слой, которому подчинено произвольное число элементарных действий. В современных информационных системах — это, как правило, единственная поддерживаемая на прикладном уровне модель транзакций, хотя внутренние компоненты системы (например, SQL) могут включать более изощренные средства обработки транзакций; однако они не доступны на уровне прикладного программирования. В разд 20.3.4 мы рассмотрим псевдовложение SQL 7) .

    Плоские транзакции — это основные строительные блоки для реализации принципа атомарности; иначе говоря, выделение некоторой последовательности действий в виде плоской транзакции обеспечивает принцип «все или ничего».

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

    По мере того как данные и вычисления становятся все более распределенными, атомарность плоских транзакций становится значительным неудобством. Рассмотрим пример на рис. 20-2. Согласно правилам обработки плоских транзакций, либо должны успешно завершиться все компоненты глобальной транзакции, либо не должна завершиться ни одна из них. Например, если неудачей завершилось только изменение одной удаленной базы данных под управлением некоторого менеджера ресурсов, то и все остальные компоненты должны быть возвращены в состояние, предшествовавшее началу транзакции. Учитывая количество информации, обрабатываемой в крупной или даже средней организации со множеством серверов LAN на ПК и, возможно, с мобильными базами данных (см. разд 22.2 в гл. 22, где обсуждается обработка транзакций в среде мобильных вычислений), можно предположить, что вероятность отказа хотя бы одного узла весьма высока. Если применяется модель плоских транзакций, то придется заново выполнять все составные части транзакции, что существенно повышает требования к вычислительным ресурсам и отнимает значительную долю пропускной способности системы.

    Рисунок 20-2.
    Выполнение плоской транзакции в среде крупной организации.

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

    20.3.2. Контрольные точки

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

    По достижении очередной контрольной точки в транзакции создается новое атомарное действие, которое запускается на выполнение. Только последнее атомарное действие всей последовательности может выполнить фиксацию (COMMIT WORK) транзакции; оператор COMMIT WORK передается всем предыдущим атомарным действиям, пока все они не будут зафиксированы 9) . В отличие от модели многозвенных транзакций, которые мы рассмотрим в следующем разделе, контрольная точка не приводит к необратимой фиксации, выполненной до этого момента работы.

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

    Проводились исследовательские работы по изучению применимости так называемых устойчивых (persistent) контрольных точек, которые фиксируются в дисковой или другой долговременной памяти, для того чтобы результаты выполнения были доступны после системных крахов. Однако Грей и Реутер отмечают, что «здесь не видно пока никакого решения, которое можно было бы принять безоговорочно» 11) . Это вряд ли следует считать большой проблемой, поскольку две новые модели транзакций — вложенные и многозвенные транзакции — предоставляют схожие возможности при том, что формальные определения этих парадигм значительно лучше проработаны и общеприняты. Рассмотрим вначале многозвенные транзакции.

    20.3.3. Многозвенные транзакции

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

    Рисунок 20-3.
    Концептуальное представление многозвенных транзакций.

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

    Модель многозвенных транзакций включает оператор CHAIN WORK — неделимую комбинацию операторов COMMIT WORK и BEGIN WORK, — которая неравноценна последовательному выполнению операторов COMMIT WORK и BEGIN WORK по отдельности. При выполнении этих операторов по отдельности контекст пропадает; некоторая другая транзакция может «вклиниться» и изменить значения в базе данных, которые нужны для выполнения следующего «звена» многозвенной транзакции, прежде чем это звено начнет выполняться 14) . Таким образом, многозвенные транзакции концептуально эквивалентны транзакциям с контрольными точками с той разницей, что откат может производиться только до последней зафиксированной точки, а не до любой предыдущей контрольной точки 15) .

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

    20.3.4. Вложенные транзакции

    Модель вложенных транзакций включает понятие головной транзакции, которая управляет выполнением всей иерархии. В рамках иерархии могут присутствовать транзакции разных уровней вложенности (рис. 20-4). Концевые узлы иерархии представляют собой плоские транзакции. Отдельные ветви иерархии могут иметь разную длину, т. е. концевые транзакции могут находиться на разном «расстоянии» от головной транзакции (корня дерева транзакций) 16) .

    Рисунок 20-4.
    Структура вложенных транзакций.

    Правила и модели вложенных транзакций были впервые разработаны Эллиотом Моссом в 1981 г. В модели Мосса реальные действия могли производиться только концевыми субтранзакциями, но Грей и Реутер отмечают, что это правило ограничивает функции вложения транзакций и что его отмена дает дополнительные возможности распараллеливания действий над разделяемыми объектами при введении абстракции многоуровневых объектов 17) .

    Мосс сформулировал три правила для управления вложенными транзакциями 18) .

  • Правило фиксации. Выполнение оператора COMMIT WORK в некоторой субтранзакции делает ее результаты видимыми только для родительской транзакции. Фактическая фиксация субтранзакции происходит только после фиксации всех ее предков вплоть до головной транзакции.
  • Правило прерывания (отката). Если субтранзакция некоторого уровня, включая головную, откатывается, то же самое должно быть сделано для всех ее потомков, независимо от статуса фиксации любой из них на локальном уровне.
  • Правило видимости. Все действия, выполненные в рамках субтранзакции, при ее фиксации становятся видимыми родительской транзакции. Все объекты, захваченные некоторой транзакцией, доступны ее потомкам. Соседние транзакции (относящиеся к одному уровню и имеющие общего родителя) «не видны» друг другу ни в том, ни в другом смысле, что позволяет выполнять их параллельно.

    Из свойств ACID для субтранзакций выполняются свойства атомарности, согласованности и изолированности. Но поскольку COMMIT WORK для субтранзакции на самом деле не означает ее фиксации до фиксации всей транзакции, то свойство долговечности не выполняется, поэтому субтранзакции не эквивалентны плоским транзакциям 19) .

    Как и другие модели, вложенные транзакции имеют вариации, в том числе модель многоуровневых (multilevel) транзакций, где субтранзакция ST1 «предварительно фиксирует» свои результаты. При этом для нее предусмотрена компенсирующая субтранзакция, которая может отменить выполненные ST1 действия, если происходит прерывание всей транзакции в целом. Компенсирующие транзакции позволяют отменять результаты почти в реальном времени; в их отсутствие приходится применять сценарии восстановления с анализом времени произведенных изменений, для чего используются дорогостоящие оперативные ресурсы, обеспечивающие возврат базы данных в согласованное состояние (например, с применением журналов или путем «сопоставления фрагментов» головоломки-мозаики, для того чтобы определить, каким должно быть согласованное состояние базы данных) 20) .

    Хотя можно представить себе приложения и системы, в которых многозвенные и вложенные транзакции были бы полезны, однако лишь в начале 90-х годов в коммерческих приложениях на смену плоским транзакциям начали приходить другие модели (в разд. 20.4 мы обсудим монитор обработки транзакций Encina). Интересно, впрочем, отметить, что при изучении транзакций SQL можно обнаружить некоторые признаки «псевдовложенности», по крайней мере в способах обработки операторов (это в настоящее время недоступно разработчикам приложений; однако принятый в настоящее время стандарт SQL3 содержит контрольные точки и, вероятно, в него войдут операторы управления многозвенными транзакциями).

    На рис. 20-5 показано выполнение транзакции SQL. Каждый оператор внутри транзакции, которая представляет собой, например, последовательность операторов UPDATE и DELETE, может завершиться успешно или неуспешно. Даже если один или несколько операторов завершаются неудачей, транзакция в целом может продолжаться, если в ее логике для этих случаев явно не предусмотрено прерывание с откатом в начальное состояние. Все успешно завершившиеся до прерывания операторы (которые в этой модели можно представлять как субтранзакции) будут отменены, если происходит откат всей транзакции.

    Рисунок 20-5.
    SQL как модель псевдовложенных транзакций.

    Разработчикам приложений приходилось как-то компенсировать недоступность имеющихся в SQL свойств псевдовложенности, применяя различные ухищрения для построения архитектур транзакций, более соответствующих их потребностям, чем простейшие плоские транзакции. Когда на рынке утвердится стандарт SQL3, что произойдет в середине 90-х, и начнут появляться совместимые с ним продукты (вспомним наши рассуждения в гл. 12 о том, что многие черты появляются в коммерческих продуктах еще до включения их в официальные стандарты), разработчики приложений на основе SQL СУБД смогут непосредственно пользоваться преимуществами новых моделей транзакций.

    20.4. Encina и DCE

    Монитор обработки транзакций Encina корпорации Transarc можно рассматривать как коммерческий продукт второго поколения, однако более развитый, отражающий новейшие достижения в этой области 21) . Encina включает модель вложенных транзакций и расширяет возможности cреды DCE (Distributed Computing Environment), предложенной организакцией OSF (Open Software Foundation).

    Прообразом Encina был прототип системы обработки транзакций Camelot, разработанный в университете Карнеги-Меллон в Питтсбурге. Технология, лежащая в основе Camelot, и применяемый в этой системе язык программирования Avalon описаны в работе Camelot and Avalon: A Distributed Transaction Processing Facility 23) . Camelot считается «первой реализацией вложенных транзакций в системе обработки транзакций» 24) (в отличие от псевдовложенности, которую мы обсуждали в предыдущем разделе, или от внутрисистемной вложенности, недоступной для разработчиков приложений).

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

    Рисунок 20-6.
    Открытая прикладная среда распределенной обработки транзакций 22) .

    На рис. 20-7 изображен типичный многоуровневый подход к распределенной обработке транзакций, применяемый, в частности, в DCE. Монитор Encina использует предоставляемые DCE абстрактные уровни управления ресурсами и коммуникационных менеджеров и сам обеспечивает прямое подключение к ресурсам и коммуникационным менеджерам, не подчиненным DCE. Модульность и многоуровневость — черты, характерные для современных открытых систем и корпоративных вычислительных архитектур 26) , — находят отражение и в обработке транзакций. Можно с уверенностью предположить, что концепции открытых систем в дальнейшем будут еще более активно применяться в сфере обработки транзакций.

    Рисунок 20-7.
    Многоуровневая архитектура обработки транзакций в Encina 28) .

    Одна из задач, решаемых монитором Encina, — это поддержка свойств ACID в среде баз данных клиент-сервер при условии, что клиенты и серверы независимо хранят записи о состоянии транзакций 27) .

    В Encina код, обеспечивающий соблюдение свойств ACID, заключен в менеджерах ресурсов (см. рис. 20-7); приложения и другие программы верхнего уровня выдают запросы на фиксацию или прерывание транзакций, которые менеджеры транзакций реализуют на соответствующих ресурсах нижнего уровня 29) .

    Encina включает язык разработки приложений Transactional C, содержащий набор макросов и библиотек для определения транзакций и управления ими. Ключевое слово TRANSACTION служит для определения транзакций верхнего уровня или вложенных. Функции, задаваемые при помощи ключевых слов ONABORT и ONCOMMIT, описывают действия, выполнямые при откате или, соответственно, фиксации транзакции любого уровня. Программа может вызвать ENCINA_ABORT_ALL, чтобы вызвать прерывание всей транзакции 30) .

    Интересно было бы понаблюдать, как пойдет развитие не только конкретного продукта Encina, но и всей области «открытой обработки транзакций» в целом. Тенденции усиления распределенности и неоднородности, о которых говорилось в гл. 1 и которые направляют развитие технологий баз данных и информационного управления, требуют определенной степени открытости всех компонентов информационных систем (в том числе сервисов операционных систем, безопасности, баз данных и репозиториев, мониторов транзакций). Хотя старые «закрытые» продукты и аппаратные платформы, поддерживаемые ими, просуществуют еще довольно долго, но тенденции, которые иллюстрирует рис. 20-8, неизбежно будут оказывать все более значительное влияние на развитие систем обработки транзакций.

    Рисунок 20-8.
    Факторы, влияющие на развитие коммерческих мониторов обработки транзакций.

    20.5. X/Open DTP

    Еще один определяющий фактор развития коммерческих систем обработки транзакций — это стандартизация. Международный комитет по стандартам (ISO) выработал состоящий из двух частей протокол для поддержки медоперабельности систем обработки транзакций. Две составные части этого стандарта 31) :

    • OSI-TP для сервисов обработки транзакций, 1992 г.;
    • OSI-CCR для фиксации, управления и восстановления, 1990 г.

    Стандарты OSI определяют форматы и протоколы, но не прикладные программные интерфейсы для стандартного протокола двухфазовой обработки транзакций (2PC), спроектированного как надстройка над стеком коммуникационных протоколов OSI.

    Стандарт API разработан комитетом X/Open и получил название X/Open Distributed Transaction Processing (DTP) API. X/Open DTP позволяет менеджерам транзакций использовать комбинацию закрытых и OSI-TP-протоколов для внутренних и межоперабельных окружений соответственно. X/Open DTP — стандарт, находящийся в стадии начального развития и имеющий определенные противоречия. В частности, не очень хорошо согласуются две его цели: (1) определение среды монитора TP как стандартизированного окружения и (2) поддержка удаленных вызовов процедур транзакций (TRPC — Transactional Remote Procedure Calls) наряду с «равноправными» (peer-to-peer) моделями коммуникаций (по крайней мере в настоящее время модель X/Open DTP содержит оба подхода) 32) .

    X/Open DTP поддерживает не только плоские транзакции, но также многозвенные и вложенные (в последней из этих моделей при прерывании одной из ветвей происходит прерывание всей транзакции в целом, в отличие от рассмотренной в разд. 20.3.4 более устойчивой модели) 33) .

    В стандартизированной распределенной среде TP для описания взаимодействий между компонентами применяется комбинация стандартных протоколов. Некоторые из них, например ROSE (Remote Operations Service), относятся к общему стеку протоколов OSI; другие являются специфическими для окружения X/Open DTP или OSI-TP. На рис. 20-9 показаны интерфейсы компонентов в стандартизированной распределенной среде TP и соответствующие протоколы и API.

    Рисунок 20-9.
    Стандартизированная среда обработки транзакций 34) .

    20.6. Классификация систем обработки транзакций

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

    M — множество машин;

    P — множество процессов;

    H — степень неоднородности машин и программного обеспечения;

    D — множество логических данных;

    S — множество узлов.

    Эта классификация характеризует любую систему обработки транзакций, от простейших (P1, M1, H1, D1, S1) до более сложных многоузловых неоднородных окружений с поддержкой разнотипных наборов данных (Pn, Mn, Hn, Dn, Sn). В статье, написанной в 1991 г., эти авторы представили трехмерную классификацию, которую они применили для оценки различных исследовательских и коммерческих систем 36) .

    20.7. Языки транзакций

    В разд. 20.4 мы рассмотрели Encina — монитор TP корпорации Transarc — который включает множество библиотек и макросов, составляющих среду разработки Transactional C. Альтернативный способ задания директив обработки транзакций состоит в применении специального языка. В качестве примера рассмотрим язык InterBase Parallel Language (IPL), входящий в состав неоднородной распределенной cреды баз данных InterBase, которую мы обсуждали в гл. 6. IPL разработан с учетом поддержки высокой степени параллелизма и взаимодействия между субтранзакциями, принадлежащими общей глобальной транзакции 37) . IPL предназначался для поддержки транзакций разных типов (т. е. смешанных транзакций), а также как системно-независимый декларативный язык, обеспечивающий прозрачность управления транзакциями.

    Ниже приведена общая структура субтранзакции IPL 38) .

    Программа на IPL представляет собой блок, обрамленный ключевыми словами program — endprogram, и включает декларации записей и описания субтранзакций. Поскольку IPL постоянно развивается и в настоящее время в стадии исследований находится графический интерфейс, а также объектно-ориентированная версия этого языка, то за более полной информацией мы отсылаем читателя к материалам проекта InterBase, который ведется в Университете Пурдью.

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

    Значение этих средств определяется отчасти тем, что они способствуют интеграции концептуального моделирования процессов и данных. Классические процедуры интеграции 1970-х годов ориентировались, например, на отображение диаграмм потоков данных (DFD — Data Flow Diagram), на сущности и атрибуты диаграмм сущность-связь (ERD — Entity-Relation Diagram) 40) . Объектно-ориентированное моделирование обеспечивает определение объектов вместе с присущими им операциями, но ни тот ни другой вид моделирования не содержит средств для описания семантики транзакций. Выработка языков описания транзакций по отношению к некоторой модели данных с последующим переносом языковых средств в среду, обеспечивающую графическое представление вложенных, многозвенных и других развитых моделей транзакций, даст в будущем значительное увеличение продуктивности и надежности проектирования систем обработки транзакций.

    20.8. Еще раз о мониторах обработки транзакций третьего поколения

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

  • Моделирование бизнес-процессов и управление ими. В предыдущем разделе мы рассмотрели основные направления развития языков описания транзакций. Философия обработки транзакций в настоящее время, даже для окружений, совместимых с OSI-TP и X/Open DTP, ориентирована на встраивание спецификаций транзакций и логики управления непосредственно в приложения. Крайне желательны были бы независимые декларативные средства для описания семантики транзакций в терминах бизнес-операций, точнее, их моделирование вместе с логикой бизнес-операций, для поддержки которых они предназначены.
  • Интеграция с дисциплиной потоков работ. Независимые средства моделирования и спецификации транзакций, отмеченные в предыдущем пункте, необходимо соединить с формирующейся в настоящее время дисциплиной потоков работ (упоминавшейся в гл. 1 в связи с обсуждением тенденции к сближению компьютерных систем с представляемыми ими системами реального мира). Для описания потоков информации, которой обмениваются между собой пользователи, процессы, приложения, может применяться некоторый высокоуровневый язык или графическая система. При этом семантику транзакций можно было бы описывать непосредственно над спецификациями потоков работ, подобно тому как ее можно было бы задавать относительно некоторой семантической модели данных. Имея среду разработки, снабженную инструментами генерации систем, можно было бы генерировать окружения управления транзакциями (совместимые, по всей вероятности, с X/Open DTP) вместе с процедурами и представлениями данных, необходимыми для реализации комбинированной модели «потоки работ — транзакции — данные».
  • Продолжительные транзакции. В гл. 11 мы отмечали необходимость долговременных транзакций для объектно-ориентированных баз данных. Хотя сама по себе эта потребность уже осознана, но для выражения свойств и реализации механизмов таких транзакций необходимы новые абстракции. Мониторы обработки транзакций третьего поколения должны поддерживать длительные транзакции наряду с (или лучше совместно с) традиционными кратковременными транзакциями.
  • Расширяемость. Мониторы TP третьего поколения должны обладать свойством динамической расширяемости новыми моделями транзакций (например, расширение модели вложенных транзакций за счет дополнения ее компенсирующими транзакциями или оперативное изменение правил обработки вложенных транзакций).
  • Безопасность. В гл. 21 мы обсудим многие аспекты безопасности баз данных и информационных систем. Обеспечение безопасности невозможно без охвата всех ресурсов среды (сеть, операционная система, СУБД). Мониторы TP следующего поколения должны включать расширенные средства безопасности, в частности поддержку многоуровневой защиты данных, хранимых в единой среде.
  • Масштабируемость. Архитектура обработки транзакций, оптимальная для 100 узлов, может оказаться неэффективной для среды из 1000 или 10 000 узлов. Мониторы TP следующего поколения должны обладать свойством масштабируемости с учетом переменного числа и объема различных ресурсов (возможно, за счет упоминавшихся выше средств поддержки расширяемости).

    20.9. Заключение

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

    Развитие сферы обработки транзакций неизбежно будет определяться такими факторами, как распределенность вычислительных ресурсов и потребность в межоперабельности. По этой причине, а также в силу того, что организации все активнее ищут средства для объединения и обеспечения управляемости своих информационных ресурсов, будет возрастать значение усилий, направленных на поддержку стандартизации, в частности на реализацию продуктов TP, интегрированных со средой DCE, совместимых со спецификациями OSI-TP, X/Open DTP.

    Перспективы


    Краткосрочные



    Долгосрочные


    Практические выводы

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

    Ключевым свойством сложных моделей транзакций является возможность разбивать транзакцию на компоненты (субтранзакции). Субтранзакции, в зависимости от конкретной модели обработки, могут быть: (1) перезапущены при рестарте системы без необходимости заново выполнять всю транзакцию с самого начала; (2) обработаны синхронно или асинхронно относительно других субтранзакций; (3) подчинены некоторой «верховной (master) транзакции», которая имеет право прервать любую из своих субтранзакций, даже если та сама по себе нормально завершила свою часть обработки.

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

    Что дает эта технология

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

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

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

    Литература

    1. U. Dayal et al. Third Generation TP Monitors: A Database Challenge. — Proceedings of the 1993 ACM SIGMOD.

    2. J. L. Epinger, L.B. Mummert, A.Z. Spector, eds. Camelot and Avalon: A distributed Transaction Processing Facility. — San Francisco: Morgan Kaufmann Publishers, 1991.

    3. J. Gray and A. Reuter. Transaction Processing: Concepts and Techniques. — San Francisco: Morgan Kaufmann Publishers, 1993.

    4. A. D. Wolfe, Jr. Transarc Encina, Distributed Computing Monitor. — Patricia Seybold Group, November 1992.

    Ссылки

    1. J. Gray and A. Reuter. Transaction Processing: Concepts and Techniques. — San Francisco: Morgan Kaufmann Publishers, 1993, 3.

    2. J. Gray and A. Reuter. Transaction Processing. 5.

    3. U. Dayal et al. Third Generation TP Monitors: A Database Challenge. — Proceedings of the 1993 ACM SIGMOD, 394.

    4. S. Dietzen. Distributed Transaction Processing with Encina and OSF DCE, Draft. — Transarc Corporation, September 1992. Provided courtesy of Transarc Corporation, Pittsburg, PA.

    5. S. Dietzen. Distributed Tra nsaction Processing.

    6. J. Gray. A Transaction Model. RJ2895. San Jose, CA: IBM Research Division, August 1980. Свойства ACID в контексте SQL и баз данных обсуждаются также в работе J. Melton and A. Simon. Understanding the New SQL: A Complete Guide. — San Francisco: Morgan Kaufmann Publishers, 1992, 39-40.

    7. J. Gray and A. Reuter. Transaction Processing. 167.

    8. J. Gray and A. Reuter. Transaction Processing. 171.

    9. J. Gray and A. Reuter. Transaction Processing. 189.

    10. J. Gray и A. Reuter обсуждают правила откатов до контрольных точек и различные вариации на эту тему с учетом правил, приведенных в J. Gray and A. Reuter. Transaction Processing. 189-190.

    11. J. Gray and A. Reuter. Transaction Processing. 190.

    12. J. Gray and A. Reuter. Transaction Processing. 192.

    13. J. Gray and A. Reuter. Transaction Processing.

    14. J. Gray and A. Reuter. Transaction Processing.

    15. J. Gray and A. Reuter. Transaction Processing. 193.

    16. J. Gray and A. Reuter. Transaction Processing. 195.

    17. J.E.B. Moss. Nested Transactions: An Approach to Reliable Computing. — LCS-TR-260, Massachusetts Institute of Technology, Cambridg, MA, 1981, цитируется в J. Gray and A. Reuter. Transaction Processing. 195.

    18. J.E.B. Moss. Nested Transactions. 196-197.

    19. J.E.B. Moss. Nested Transactions. 197.

    20. Gray и Reuter рассматривают многоуровневые, вложенные и другие виды транзакций в деталях и подробностях, которые выходят за рамки предмета данной книги. Заинтересованного читателя мы отошлем к материалам J. Gray and A. Reuter. Transaction Processing. 203-210.

    21. U. Dayal et al. Third Generation TP Monitors. 394.

    22. Dietzen. Distributed Transaction Processing. 7.

    23. J.L. Epinger, L.B. Mummert, A.Z. Spector, eds. Camelot and Avalon: A distributed Transaction Processing Facility. — San Francisco: Morgan Kaufmann Publishers, 1991.

    24. J. Gray and A. Reuter. Transaction Processing. 223.

    25. Dietzen. Distributed Transaction Processing. 7-8.

    26. A. Simon. Enterprise Computing. — New York: Bantam Books/ Intertext, 1992, а также A. Simon. Implementing the Enterprise. — New York: Bantam Books/Intertext, 1992, где можно найти множество примеров многоуровневых и модульных подходов в этой области.

    27. A.D. Wolfe, Jr. Transarc Encina, Distributed Computing Monitor. — Patricia Seybold Group, November 1992, 5.

    28. Encina: Enterprise Computing in a New Age. Product Overview, 8.

    29. A.D. Wolfe, Jr. Transarc Encina.

    30. Пример программы на языке Transactional C из A.D. Wolfe, Jr. Transarc Encina. 9.

    31. J. Gray and A. Reuter. Transaction Processing. 260.

    32. J. Gray and A. Reuter. Transaction Processing. 961.

    33. J. Gray and A. Reuter. Transaction Processing.

    34. J. Gray and A. Reuter. Transaction Processing. 84.

    35. A. Left and C. Pu. A Classification of Transaction Processing Systems. — IEEE Computer, June 1991, 63-65.

    36. A. Left and C. Pu. Transaction Processing Systems. 73.

    37. J. Chen, A Elmagarmid, and O. Bukhres. The Interbase Parallel Language: Supporting Distributed Transaction Applications. — SERC-TR-119-P, Purdue University, West Lafayette, IN, July 1992.

    38. J. Chen, A Elmagarmid, and O. Bukhres. The Interbase Parallel Language. 5.

    39. S.B. Navathe and A. Balaraman. A Transaction Architecture for a General Purpose Semantic Data Model. В сборнике Proceedings of the Tenth International Conference on Entity-Relationship Approach: Bridging the Gap. ed. T.D. Teorey. — Ann Arbor, MI: University of Michigan, 1991.

    40. Подробнее см. A. Simon. The Integrated CASE Tools Handbook. — Van Nostrand Reinhold/Intertext, 1993, Chap. 6.

    41. На основе U. Dayal et al. Third Generation TP Monitors. 394-396 с комментариями автора настоящей книги.

    Поделитесь материалом с коллегами и друзьями

    Обработка транзакций с UnitOfWork и EF

    Я использую Entity Framework 5.0 и MVC4. У меня есть несколько доменов. Каждый из них имеет свой DbContext (который использует соответствующие таблицы), репозиторий и сервис. Я также реализовал UnitOfWork.

    Обработка определенного потока в транзакции внутри одной службы для определенного домена проста. Я выполняю некоторые операции над таблицами и в конце вызываю UnitOfWork.Сохранить, который ведет себя как транзакция.Совершать.

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

    1. Я должен иметь UnitOfWork в контроллере и вызвать метод сохранения в конце (мне не нравится эта идея).
    2. Создайте сервис, в котором у меня будет UnitOfWork и доступ к обоим сервисам (на самом деле это то же самое решение, что и выше, но я перемещаю логику в отдельный класс)
    3. Я должен создать дополнительный TransactionScope внутри контроллера и зафиксировать его в конце

    Пожалуйста, дайте мне знать, какой вариант вы считаете лучшим. Если у вас есть какие-либо другие, кроме трех выше, дайте мне знать. Или, может быть, что-то не так с моей концепцией? Я имею в виду домены и их контексты БД?

    1 ответ

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

    Технология оперативной обработки транзакции (ОLТР–технология). Технология аналитической обработки в реальном времени (ОLАР-технология) (стр. 1 )

    Из за большого объема этот материал размещен на нескольких страницах:
    1 2 3 4

    21. Технология оперативной обработки транзакции (ОLТР–технология). Технология аналитической обработки в реальном времени (ОLАР-технология).

    OLTP – системы оперативной обработки транзакций. Для таких систем более подходят сильно нормализованные модели данных.

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

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

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

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

    Такие системы предназначены для нахождения зависимостей между данными, проведения анализа (что, если?).

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

    OLAP приложения характеризуются следующими признаками:

    1.добавление в систему новых данных происходит относительно редко и крупными блоками;

    2.данные, добавленные в систему, как правило, никогда не удаляются;

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

    4.запросы на выборку являются не регламентированными и как правило, достаточно сложными. Очень часто новые запросы формируются для уточнения результата, полученного в предыдущем запросе. Скорость выполнения важна, но не критична.

    22. Основные функции операционной системы, классификация ОС

    ОС – комплекс программных средств, выполняющих две основные задачи:

    1)обеспечение интерфейса между человеком и аппаратным комплексом вычислительной машины;

    2)управление ресурсами вычислительной машины.


    Функции операционной системы

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

    1.Тестирование аппаратуры и начальная загрузка самой себя в вычислительную систему.

    2.Контроль за вычислениями (управление процессами и их взаимодействием).

    3.Контроль за распределением ресурсов.

    4.Поддержка различного уровня интерфейсов, в том числе и пользовательского.

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

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

    Управление памятью (распределение памяти; работа с долговременной памятью; файловая система; встроенные функции для работы с СУБД — в некоторых ОС).

    Поддержка операций ввода-вывода и работы с устройствами ввода-вывода.

    Унификация доступа к периферийным устройствам (терминалы, модемы, печатающие устройства, устройства управления в специализированных системах).

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

    Поддержка параллельного или псевдопараллельного исполнения нескольких задач (распределение ресурсов между задачами и организация взаимодействия между ними; защита одной задачи от другой).

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

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

    I. Особенности алгоритмов управления ресурсами

    1.Многозадачные ОС – ОС, которые позволяют выполнять одновременно несколько задач (Windows, Unix).

    2.Однозадачные ОС – это ОС, в которой в каждый момент времени может выполняться только одна задача (MSDOS).

    3.Многопользовательские ОС – это такие ОС, которые обеспечивают возможность изоляции некоторой информации пользователей друг от друга (Windows NT,2000).

    4.Однопользовательские ОС – ОС, в которых нет поддержки изоляции некоторой информации пользователей друг с другом (MSDOS, Windows 3.1).

    5.Многопроцессорные ОС – это ОС, обеспечивающие параллельную обработку данных на нескольких процессорах.

    6.ОС с не вытесняющей многозадачностью – это такие ОС, в которых каждый процесс выполняется до тех пор, пока он сам не закончит или не приостановит свою деятельность (Windows3.1).

    7.ОС с вытесняющей многозадачностью – это такие ОС, в которых приостановка процесса или прекращение деятельности процесса может производиться как самим процессом, так и ОС (Windows NT, Unix).

    8.Многонитиевые ОС – это ОС, обеспечивающие параллельное выполнение нескольких нитей. Нить – это отдельный процесс какой-либо задачи, которая может одновременно выполняться с другими процессами этой же задачи.

    II. Особенности аппаратных платформ

    1.ОС ПК. Данные ОС предназначены в основном для обеспечения удобного интерфейса между человеком и компьютером. Критерием эффективности является удобство ее интерфейса.

    2.ОС мини — и микро-компьютеров. Эти ОС в основном предназначены для решения научных и вычислительных задач и основным критерием эффективности таких ОС является максимальное быстродействие.

    3.ОС сетевые – это ОС, обеспечивающие эффективный механизм обмена информацией между узлами сети. (Windows NT, 2000, Unix).

    III. Особенности областей использования

    1.ОС пакетной обработки (ЕС) – это ОС, которые предназначены для решения задач в основном вычислительного характера. Главным критерием эффективности такой ОС является решение максимального количества задач за какой-то промежуток времени, т. е. пропускная способность.

    2.Системы разделения времени (Windows) – это такие ОС, которые обеспечивают возможность одновременной работы нескольких пользователей. Для этого вводится такое понятие как квант. Квант – промежуток времени, отводимый каждому пользователю, по истечении которого ОС переключается с выполнения задач одного пользователя на задачи другого пользователя.

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

    23. Управление процессором, памятью, устройствами ввода-вывода

    При управлении памятью ОС выполняет следующие задачи:

    1)отслеживание свободной и занятой памяти;

    2)выделение памяти процессам;

    3)освобождение памяти в случае завершения процесса;

    4)вытеснение процессов из памяти при необходимости;

    5)возвращение процессов в оперативную память после вытеснения;

    6)настройка адресов процесса на физические адреса оперативной памяти.

    Виды памяти вычислительной машины.

    Внешняя память – память, распределенная по уровню (по классу) ниже оперативной и которая не может напрямую быть использована для выполнения процессов.

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

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

    Регистр процессора – память, расположенная непосредственно в процессоре.

    Внешняя память и оперативная память управляют ОС.

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

    Виртуальные имена (виртуальные адреса). Это условные адреса, которые вырабатываются транслятором (компилятором) из символьных имен. Обычно оно начинается с ячейки «0» и размер его определяется, во-первых, размером программ, а во-вторых разрядностью используемого кода.

    Физические адреса. Это адреса ячеек физической памяти.

    Преобразование виртуальных адресов в физические происходит 2мя способами:

    1)статическое преобразование и использование перемещающего загрузчика (в момент загрузки процессора в физическую оперативную память перемещающий загрузчик определяет начальную свободную ячейку оперативной памяти и на основе этой информации преобразовывает виртуальные адреса в физические; «+» простота реализации и высокая скорость работы; «-» невозможность перемещения процесса в другой участок оперативной памяти (ОП)

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

    МЕТОДЫ РАСПРЕДЕЛЕНИЯ ПАМЯТИ

    1)Распределение без использования внешней памяти:

    2) С использованием внешней памяти

    УПРАВЛЕНИЕ ПРОЦЕССАМИ

    Заключается в следующем: 1)выделение памяти процессу;

    2)освобождение памяти от процесса; 3)перевод процессов из одного состояния в другое.

    1)Выполнение – активное состояние процессов, во время которого процесс обладает всеми необходимыми ресурсами и непосредственно выполняется процессором.

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

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

    Алгоритм управления процессами.

    1.При запуске какого-либо процесса на выполнение, процесс переводится в состояние готовность и ставится в очередь на выполнение.

    2.При подходе очереди данного процесса, в случае, если все необходимые ресурсы свободны, процесс переводится в состояние выполнения.

    3.В ходе выполнения могут возникнуть следующие ситуации:

    3.1процесс выполнил свою программу, завершился и был выгружен из памяти;

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

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

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

    ОРГАНИЗАЦИЯ ВВОДА-ВЫВОДА

    Основные функции ОС при управлении вводом-выводом.

    1)Передача устройствам ввода-вывода команд.

    2)Обработка прерываний и ошибок.

    3)Обеспечение интерфейса между непосредственно устройствами ввода-вывода и верхним слоем ОС.

    Физическая организация устройств ввода-вывода.

    Устройства ввода-вывода делятся на два типа:

    1)блок-ориентированные устройства — хранят и обрабатывают информацию блоками определенного размера, каждый из которых имеет свой адрес.;

    2)байт-ориентированные устройства — принимают и обрабатывают информацию в виде потока байтов. Эти устройства являются не адресными и не позволяют осуществлять произвольный доступ к информации..

    Устройства ввода-вывода в общем виде состоят из двух компонент – электронного и механического. Электронная компонента называется контроллером или адаптером.

    Основные функции контроллера.

    1.Преобразование команд ОС непосредственно в управляющие сигналы для механической части устройства ввода-вывода.

    3.Преобразование информации из формата устройств ввода-вывода в формат, используемый ОС и наоборот.

    Основные принципы управления вводом-выводом.

    1.Независимость от устройств.

    2.Разделение управлением вводом-выводом на несколько уровней.


    3.Обработка ошибок ввода-вывода максимально близко к аппаратной или механической части устройств ввода-вывода.

    4.Использование блокирующих и не блокирующих передач информации.

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

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

    Система управления вводом-выводом делится на три уровня.

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

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

    3.Пользовательский уровень систем ввода-вывода также состоит из двух блоков – библиотечных функций и приложений. Библиотечные функции содержат в себе набор стандартных процедур для работы с устройствами ввода-вывода и обеспечивают при обращении к каким-либо библиотечным функциям необходимые системные вызовы.

    24. Файловые системы современных ОС.

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

    Файловая система включает в себя:

    1)совокупность всех файлов на диске;

    2)наборы структур данных, используемых для управления файлами;

    3)комплекс ПС, реализующих управление файлами.

    Интерфейс файловой системы.

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

    Общая модель файловой системы

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

    Общая модель файловой системы

    Запрос к файлу (операция, имя файла, логическая запись)—1,2,3,4,5—К подсистеме ввода-ввывода

    1.Задачей символьного уровня является определение по символьному имени файла его уникального имени. В файловых системах, в которых каждый файл может иметь только одно символьное имя (например, MS-DOS), этот уровень отсутствует, так как символьное имя, присвоенное файлу пользователем, является одновременно уникальным и может быть использовано операционной системой. В других файловых системах, в которых один и тот же файл может иметь несколько символьных имен, на данном уровне просматривается цепочка каталогов для определения уникального имени файла.

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

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

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

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

    Надежность файловой системы.

    Меры для сохранения структуры файловой системы на диске:

    -своевременное дублирование информации (backup);

    -файловые системы современных ОС содержат специальные средства для поддержки собственной совместимости.

    Целостность файловой системы.

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

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

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

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

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

    25. Архитектура ОС семейства Windows 9x.

    ОС – комплекс программных средств, выполняющих две основные задачи:

    1)обеспечение интерфейса между человеком и аппаратным комплексом вычислительной машины;

    2) управление ресурсами вычислительной машины.

    Адресное пространство – раздел в памяти с собственным набором адресов, причем прямое отображение информации из одного адресного пространства в другое невозможно.

    Кольцо защиты – раздел в памяти, предназначенный для изоляции и защиты процессов, находящихся в нем. Взаимодействие между различными кольцами защиты происходит через специальные средства ОС.

    Виртуальная машина – это раздел в памяти, изолированный от других разделов, в которых ОС иммулирует работу отдельной вычислительной машины. АРХИТЕКТУРА ОС WINDOWS 3.11

    КЗ 1.Системная виртуальная машина обеспечивает работу 16 разрядных приложений в ОС Windows 3.11. А также содержит в себе основные сервисные функции ОС. Приложения Win16 работают в едином адресном пространстве в режиме не вытесняющей многозадачности. Сервисные функции системы так же 16 разрядные и так же выполняются в том же адресном пространстве в пределах системной виртуальной машины. Приложения DOS. Каждое из них выполняется в отдельной виртуальной DOS машине, которая работает в режиме вытесняющей многозадачности.

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

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

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

    Windows 95 – многозадачная ОС явл развитием версии 3х. Обладает улучш граф интерфейсом, имеющая файловую сист Visual FAT. Имеет 32 разрядное ядро. Режим plug-and-play (опред новое устройство и предназнач установить драйвер)

    Располагаются основные сервисные функции ОС. Приложения Win32 выполняются каждое в отдельном адресном пространстве в режиме вытесняющей многозадачности.

    Все приложения Win16 выполняются в одном адресном пространстве в режиме не вытесняющей многозадачности. Однако, адресное пространство с 16-разрядными приложениями выполняются в режиме вытесняющей многозадачности.

    Сервисные функции системы выполнены в виде приложений Win32 и выполняются в своем отдельном адресном пространстве.

    Однако, часть сервисных функций ОС выполнена в виде приложений Win16 и выполняется в том же адресном пространстве, что и приложения Win32.

    КЗ 0 состоит из 2х подсистем.

    Подсистема управления файлами содержит в себе диспетчер устройств ФС.

    Подсистема управления файлами Windows 95 работает в нулевом кольце защиты и обрабатывает все вызовы, связанные с вводом-выводом. Большинство вызовов обрабатывается в защищенном режиме, но некоторые по-прежнему приводят к переключению в режим Virtual 86, и обрабатываются в реальном режиме DOS. Диспетчер устанавливаемых файловых систем IFS передает вызовы файлового ввода-вывода драйверу соответствующей файловой системы. Драйвер файловой системы VFAT реализует собственную VFAT-систему Windows 95, которая похожа на файловую систему FAT с добавленными средствами обработки длинных имен файлов. Драйвер CDFS заменяет MSCDEX и управляет операциями по вводу данных с накопителей CD ROM. Редиректор, выполненный в виде драйвера файловой системы, обеспечивает обращение к сетевым накопителям. Можно устанавливать дополнительные драйверы файловых систем. Подсистема блочного ввода-вывода выполняет соответствующие операции на физическом уровне в ответ на запросы драйверов файловых систем.

    Подсистема управления виртуальными машинами (VMM) предоставляет низкоуровневые сервисные функции, например, планирование нитей и управление памятью. Сюда также относятся драйверы виртуальных устройств (VxD) для аппаратуры.

    Windows 98 – изменен польз интерфейс, унифицирован доступ ко всем видам ресурсов от жест дисков до WEB-сайт. Оптимизация, возможность настройки параметров дисплея. Возможность изменить цвет, шрифт не перегружаясь (раб стол). Поддержка работы нескольких дисплеев, графич ускорителей AGP (для 3мерной графики). Эф защита от сбоев, благодаря файловой системе. Есть менеджер задач вызываемый Ctrl+Alt+Del (перезагружать).Файл сист FAT32, что позволило сохр место на диске.

    26. Структура и функции сетевых ОС

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

    ОБЩАЯ СТРУКТУРА СЕТЕВОЙ ОС
    ФУНКЦИИ

    Локальная ОС служит для управления локальными ресурсами компьютера, например, распределение памяти, управление процессами, распределение процессорного времени, управление внешними устройствами и т. д.

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

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

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

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

    27. Характеристика основных сервисов сети Internet

    Internet — система, направленная на пользователя и предоставляющая ему те или иные виды услуг.

    Основными сервисами Internet на сегодняшний день являются следующие:

    1. Всемирная паутина (www)

    Всемирная паутина (world wide web) — это система документов, включающих текстовую и графическую информацию, размещенных на узлах Internet и связанных между собой гиперссылками.

    Архитектура www построена по принципу клиент-сервер.

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

    Для передачи информации между программами используется протокол HTTP (Протокол передачи гипертекст).

    2. Электронная почта (E-Mail) Электронная почта (e-mail) — один из наиболее широко используемых видов сервиса в Internet, это система почтовых серверов, также организованная на всех узлах Internet и позволяющая передавать от одного пользователя другому электронное письмо, в которое может быть включен текст, рисунки и вообще любая информация.

    В качестве стандартного метода передачи почты в Internet используется протокол SMTP (простой протокол передачи почты). SMTP применяется во многих локальных и глобальных сетях, хотя для локальных сетей существует и множество других почтовых протоколов.

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

    3. Файловые архивы FTP Сервис FTP (Протокол передачи файлов) используется для доступа к файловым архивам Internet. FTP — это протокол, позволяющий легко пересылать файлы и документы. Его обычно рассматривают как один из методов работы с удаленными сетями. Существуют FTP-серверы, которые содержат большое количество информации в виде файлов. К данным этих файлов нельзя обратиться напрямую, — только переписав их целиком с FTP-сервера на локальный сервер. Он позволяет работать с любыми типами файлов. Как и многие другие виды сервиса, FTP работает по принципу системы с архитектурой клиент-сервер. Поэтому для работы с FTP обычно требуются специальные программы — FTP-клиенты. В качестве серверов при этом выступают FTP-серверы, расположенные где-то в сети и предоставляющие доступ к обслуживаемым ими файловым архивам. В архивах FTP на своих серверах почти все крупные производители аппаратного обеспечения размещают драйверы для своих устройств, которые могут «скачать» себе владельцы этих устройств.

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

    Используя систему меню, Gopher позволяет Вам не только просмотреть списки ресурсов, но и перешлет нужный материал, причем знать, где он расположен, вовсе не обязательно. Gopher — это одна из наиболее всеобъемлющих систем просмотра, интегрированная с другими программами, такими, как FTP или Telnet. В Internet она широко распространена. Компьютеры Gopher — с помощью распределенных индексов — связаны в единую поисковую систему, называемую Gopher-пространство. Доступ в Gopher-пространства осуществляется через предлагаемые ими меню, а поиск — с помощью нескольких разновидностей поисковых систем. Наиболее известны среди них система Veronica, и индексная поисковая система глобального информационного сервера (wAIS).

    5. Телеконференции Система телеконференций появилась как средство общения групп людей со сходными интересами. Этот вид сервиса напоминает списки рассылки Internet, за тем исключением, что сообщения не отправляются всем подписчикам данной телеконференции, а помещаются на специальные компьютеры, называемые серверами телеконференций или news-серверами. После этого подписчики телеконференции могут прочитать поступившее сообщение и, при желании, ответить на него.

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

    6. Telnet По существу, Telnet – это программа telnet, работающая по протоколу TELNET. Telnet позволяет работать с удаленными компьютерами в режиме текстового терминала. Таким образом, вы набираете команды и видите на своем экране результаты их выполнения, но фактически все команды выполняются на том компьютере, с которым вы установили соединение. По сети передается лишь та информация, которую вы вводите с клавиатуры и, которая отображается у вас на экране. При этом создается впечатление, что вы работаете только с собственным компьютером. Для того чтобы воспользоваться Telnet, необходимы права доступа на компьютер, с которым вы хотите работать. В большинстве случаев это означает, что вы должны знать соответствующее имя пользователя и его пароль. Другим вариантом может быть то, что вы лично зарегистрированы на этом компьютере в качестве пользователя.

    7. Основы общения в Internet IrC (Всемирная болталка). Эта услуга позволяет различным пользователям в режиме реального времени общаться между собой обменом текстовыми сообщениями. Скорее всего, IrC будет постепенно оттесняться Internet-телефонией.

    Q (Я ищу Вас) Эта услуга позволяет обнаруживать, кто присутствует в данный момент в Internet, Вы можете общаться с ними. С помощью ICQ, Вы можете побеседовать, посылать сообщения и файлы, играть и т. п.

    IrC и ICQ практически не защищены от просмотра учетных записей. Internet-телефония (ИТ). Это самая молодая услуга Internet. Два пользователя, подключившись к одному ИТ-серверу, могут разговаривать между собой. Низкое качество связи окупается самым главным — стоимостью разговора по ИТ равна стоимости доступа в Internet, то есть по сравнению с международными телефонными переговорами Internet-телефон — практически бесплатное средство связи.


    28. Классификация информационных объектов с точки зрения безопасности. Категории информационной безопасности

    Системы обработки транзакций

    Читайте также:

    1. A14 — СДВОЕННЫЙ ПРЕСС С ПРОГРАММНЫМ УПРАВЛЕНИЕМ ДЛЯ ОБРАБОТКИ ПОЛОЧЕК ПИДЖАКА
    2. CRM системы
    3. II. История развития налогов и налогообложения в СССР. Становление налоговой системы современной России
    4. II. Понятие агроэкосистемы
    5. II. Структура Системы сертификации ГОСТ Р и функции ее участников
    6. III. Впишите пропущенные названия структурных компо­нентов в системы воспитательного процесса, выделен­ные по различным критериям.
    7. III. Городские экосистемы
    8. ISO 14004:2004 «Системы экологического менеджмента. Руководящие указания по принципам, системам и методам обеспечения функционирования».
    9. IV. ГОРОДСКИЕ СИСТЕМЫ ЭНЕРГОБЕСПЕЧЕНИЯ
    10. IX. ОРГАНЫ КРОВЕТВОРЕНИЯ И ИММУННОЙ СИСТЕМЫ
    11. MRP, MRPII, ERP -системы. Определения. Общее и различия в применении.
    12. T Команды арифметической и логической обработки

    Шесть основных типов информационных систем

    На рис. 2.2 показаны основные типы информационных систем, которые предназ­начены для конкретных организационных уровней. Организация использует си­стемы поддержки принятия решений (СППР) на стратегическом уровне, управ­ленческие системы (УИС) и системы поддержки принятия стратегических решений (СППСР) на управленческом уровне; системы работы с данными(СРСЗ) и офис­ные системы на уровне знаний; системы обработки транзакций (СОТ) на опе­рационном уровне. На каждом уровне информационные системы обслуживают определенную функциональную область. Таким образом, типичные системы, ра­ботающие в организациях, предназначены для помощи рабочим и менеджерам на каждом уровне в выполнении маркетинговых, производственных, финансовых и других функций.

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

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

    Таблица 2.1
    Характеристики систем обработки информации
    Тип системы Ввод информации Обработка информации Вывод информации Пользователи
    СППСР Агрегированные данные: внешние, внутренние Графика; моделирование; интерактивность Проекции; отклики на запросы Старшие менеджеры
    СППР Небольшие объемы данных или массивные базы данных, опти-мизированные с целью выполнения анализа данных; аналитические модели и инструменты анализа данных Интерактивность;моделирование;анализ Специальныеотчеты; анализ решений; отклики на запросы Профессионалы;менеджеры службы персонала
    УИС Данные суммарных транзакций; большие объемы данных; простые модели Процедурные отчеты; простые модели; низкоуровневый анализ Сводные отчеты, а также отчеты по исключениям Менеджеры среднего звена
    СРСЗ Спецификации проекта; база знаний Моделирование; имитации Модели; графика Профессионалы; технический персонал
    Офисные системы Документы; кален- дарные планы Управление документами; календарное планирование; коммуникация Документы; календарные планы; почта Клерки
    СОТ Транзакции; события Сортировка; вывод списка; слияние. обновление Детализиро-ванные отчеты; списки; сводки Операционный персонал; администраторы

    Transaction processing systems (TPS) (системы обработки транзакций)

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

    На операционном уровне все цели, задачи и ресурсы предопределены заранее и четко структурированы. Например, решение о предоставлении заказчику кре­дита, принимаемое инспектором, основывается на заранее установленных крите­риях. Сотрудник просто проводит проверку соответствия условиям всех указан­ных критериев.

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

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

    Другие типичные системы обработки транзакций представлены на рис. 2.4 (реализованы в виде популярных приложений). На иллюстрации видно, что та­кие системы подразделяются на пять функциональных категорий: торговля/мар­кетинг, производство, финансы/бухгалтерия, трудовые ресурсы и другие типы систем, предназначенные для использования в специфических случаях/условиях. Система отслеживания движения посылок, которая используется службой и опи­сана в гл. 1, представляет собой типичный пример производственной системы обработки транзакций. Служба UPS отправляет посылки службам доставки, а си­стема следит за всеми происходящими при этом транзакциями.

    Системы обработки транзакций зачастую являются стержневыми структура­ми компаний, поскольку малейший сбой в их работе может привести к серьезным нарушениям в деятельности организации (и связанных с ней фирм). Только пред­ставьте себе, что произойдет, если система отслеживания посылок службы UPS перестанет работать! Как смогут функционировать авиакомпании без систем ре­зервирования мест в самолетах?

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

    Дата добавления: 2015-04-29 ; Просмотров: 2702 ; Нарушение авторских прав? ;

    Нам важно ваше мнение! Был ли полезен опубликованный материал? Да | Нет

    Советы по методам обработки транзакций T-SQL (ADO)?

    Мы говорим здесь об уровне изоляции, а именно о параллелизме в отношении локального сервера Express MSSQL.

    Я пытаюсь найти способ начать блокировку данных, когда пользователь решает редактировать строку в GridView -> держать данные заблокированными, пока он / она не перестанет редактировать (IE нажал «Обновить»).

    Как список событий это выглядит так:

    1. Пользователь 1 нажимает Редактировать в строке с идентификатором 1.
    2. DataSet (строка) заблокирован, пока пользователь 1 вводит новые данные.
    3. В случае, если пользователь 2 пытается изменить одну и ту же строку, этого пользователя следует заметить еще до того, как он войдет в режим редактирования этой строки.
    4. Пользователь 1 обновляет строку, и режим редактирования останавливается, поэтому данные должны быть зафиксированы, а транзакция закрыта.

    Я начал делать несколько методов.

    До методов мой сервисный метод всегда держит соединение в закрытой / локальной переменной:

    Тогда есть методы.

    Мой большой вопрос: возможно ли это правильно использовать?

    3 ответа

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

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

    Моя предпочтительная модель для этого сценария — использовать метку времени «последней модификации».

    1. Обновите данные на экране, удерживая last_modified_time для каждой строки
    2. Пользователь нажимает на строку
    3. Приложение проверяет, изменилось ли last_modified_time этой строки
    4. Если изменено, обновите строку из БД и проинформируйте пользователя о текущем состоянии.
    5. Разрешить пользователю изменять строку на экране
    6. Пользователь нажимает «совершить»
    7. Еще одна проверка, чтобы увидеть, изменилось ли last_modified_time
    8. Если это так, покажите разные значения и спросите пользователя, хотят ли они по-прежнему вносить свои изменения.

    В SQL вы хотите:

    Пользователь вносит правки здесь .

    Вы можете легко обернуть это с помощью методов c # в LockRecord / UnlockRecord.

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

    Не держите транзакцию для этого. Это потребует от вас:

    • Открытое соединение
    • Начать транзакцию
    • Выберите запись для редактирования (= заблокировать запись)
    • Подождите, пока пользователь завершит редактирование
    • Зафиксируйте изменения
    • Закрыть соединение

    Как долго пользователь может редактировать запись? Что произойдет, если пользователь заблокирует записи и отправится на обед? Соединение не должно удерживаться пользователем, а транзакция должна быть максимально короткой. Вся отдельная часть состоит в том, что мы говорим об ASP.NET, где вам придется хранить соединение в сеансе, и если пользователь не фиксирует изменения, соединение будет утечку — у вас скоро закончится соединение.

    Это целое может быть расценено как совершенно плохой дизайн и то, что вы никогда не должны делать!

    Добавьте новый столбец в вашу таблицу: LockedBy (вы также можете добавить LockedAt ). Изменяйте эти столбцы в транзакции только тогда, когда пользователь хочет редактировать запись. Другие пользователи не смогут переключать записи в режим редактирования, когда эти столбцы заполнены. Как только пользователь внесёт изменения, очистите эти столбцы.

    У вас будет одна проблема — вы должны разблокировать записи, если пользователь отменяет изменения, но что если пользователь просто закроет свой браузер? Это потребует некоторой работы, которая будет регулярно запускать и разблокировать записи, заблокированные в течение длительного времени (причина для второго столбца). Вы можете запустить такое задание в агенте SQL.

    Сравнение сущности транзакционных и аналитических процессов в базах данных

    технические науки

    • Маковейчук Кристина Александровна , кандидат наук, доцент, заведующий кафедрой
    • Гуманитарно-педагогическая академия (филиал), Крымский федеральный университет им. В. И. Вернадского, в г. Ялта
    • ПАРАЛЛЕЛЬНЫЕ ВЫЧИСЛЕНИЯ
    • ДАННЫЕ В ПАМЯТИ
    • АРХИТЕКТУРА СТОЛБЦОВ
    • ТРАНЗАКЦИИ
    • АНАЛИТИКА

    Похожие материалы

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

    • данные из различных источников должны быть объединены в единую базу данных;
    • данные должны иметь возможность быть проанализированными в реальном времени, поддерживать интерактивные принятия решений [1, 4].

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

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

    MapReduce — это модель распределённых вычислений, представленная компанией Google, используемая для параллельных вычислений над очень большими, несколько петабайт, наборами данных в компьютерных кластерах.

    Технология MapReduce представляет собой комбинацию двух функций, улучшающих обработку данных. Сначала map-функция разделяет данные на несколько групп, которые затем обрабатываются параллельно. Затем reduce-функция объединяет результаты расчетов в варианты ответов.

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

    Компания Google использовала технологию MapReduce для индексирования сети Интернет и получила патент на свою MapReduce-платформу. Однако постепенно эта методика начинает использоваться все шире и шире.

    Наибольшую известность получила ее реализация в проекте Apache Hadoop на основе открытого кода.

    Платформа Hadoop на основе открытого кода была разработана с помощью технологии MapReduce для параллельной обработки больших объемов информации на множестве узлов стандартного недорогого оборудования.

    Информация разделяется на блоки и загружается в файловое хранилище данных, например Hadoop Distributed File System (HDFS), организованное как несколько избыточных узлов на недорогом запоминающем устройстве. Узел name протоколирует размещение данных на конкретных узлах. Данные реплицируются более чем на одном узле, что обеспечивает их сохранность в случае выхода какого-либо узла из строя.

    Затем данные можно анализировать с помощью технологии MapReduce, которая определяет местонахождение необходимых для расчета сведений из узла name. После этого обработка на узлах идет параллельно. Результаты расчетов обобщаются для составления ответа на запрос и затем загружаются на узел, который впоследствии доступен для анализа с помощью других инструментов. В качестве альтернативы возможна загрузка полученных сведений в традиционные хранилища для обработки с помощью транзакций [5].

    Сегодня многие компании стараются увязать свою собственную технологию в области БД с технологией Hadoop и предложить результат в качестве собственной стратегии по решению задач, связанных со скоростью обновления. Немецкая компания SAP в качестве основной стратегии в области больших данных предлагает представленное в 2011 г. хранилище данных на платформе высокопроизводительного аналитического программно-аппаратного комплекса (high-performance analytic appliance — HANA). В этом комплексе реализована прогрессивная технология вычислений in-memory, обеспечивающая обработку в реальном времени больших объемов данных в оперативной памяти сервера для получения результатов, касающихся аналитики и транзакций. В начале 2012-го появился продукт Oracle Exalytics, также реализующий данную технологию.

    Размещение на платформе HANA бизнес-приложений, таких как SAP Business Objects, обеспечивает серьезный выигрыш в их производительности.

    SAP состыковала систему HANA с Hadoop, позволив покупателям обмениваться данными между Hive, Hadoop Distributed File System и SAP HANA или SAP Sybase IQ server.

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

    Проблема 1: разнообразие приложений, создающих данные

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

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

    Рисунок 1. Источники данных в современных системах [1]

    Проблема 2: системы, реализующие OLTP и/или OLAP – альтернатива или объединение?

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

    Тем не менее, исследования в современных корпоративных системах показали, что это утверждение не соответствует действительности [1]. Основное различие между системами, которые обрабатывают эти типы запросов, в том, что OLTP системы обрабатывают больше запросов с одним объектом выборки или запросов, которые из большого объема данных возвращают всего несколько объектов, в то время как системы OLAP агрегируют лишь несколько столбцов таблицы, но для большого количества объектов.

    Для синхронизации аналитической системы с транзакционной системой (системами), необходим многотиражный ETL (Extract-Transform-Load) процесс.

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

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

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

    При обработке транзакций часто принимают, что доли чтения и записи равны, в то время как на самом деле в аналитической обработке доминируют больше чтение и различные запросы. Тем не менее, анализ рабочей нагрузки нескольких систем реальных предприятий показывает, что OLTP и OLAP системы не так и отличаются, как ожидалось в классических корпоративных системах. Как показано на рисунке 2, OLTP процессы в системе имеют более 80% запросов на чтение. Менее 10% от фактического объема — запросы на изменение существующих данных, например, обновление и удаление. Системы OLAP обрабатывают еще большее количество запросов на чтение, которые составляют около 95% рабочей нагрузки.

    Рисунок 2. Анализ рабочей нагрузки нескольких систем по OLTP и OLAP запросам [1]

    Обновления в транзакционной нагрузке представляют особый интерес. Анализ обновлений в различных сферах промышленности показывает их отличие [1, 2, 3, 6].

    Отличие состоит в том, что количество обновлений в OLTP системах является достаточно низким и варьируется по отраслям. В проанализированных высокотехнологичных компаниях, пики «частота обновления» около 12%, это означает, что около 88% из всех сохраненных в базе данных транзакций никогда не обновляются. В других секторах исследование показало, что возможны даже более низкие проценты обновления, например, менее 1% в банковском и дискретном производстве.

    Список литературы

    1. Plattner, Hasso. In-Memory Data Management. The Inner Mechanics of In-Memory Databases / Hasso Plattner ; Hasso Plattner Institute, Potsdam, Brandenburg Germany // Springer. – 2013. – 298 р. ISBN 978-3-642-36523-2
    2. Маковейчук, К.А., Галлини, Н.И. Визуализация результатов и формирование отчетности учреждения высшего образования с помощью комплексной информационно-справочной системы анализа и мониторинга показателей контингента абитуриентов, обучающихся и преподавателей [Электронный ресурс] / К. А. Маковейчук, Н. И. Галлини. — Журнал «Постулат». — 2020. — № 3. — Режим доступа: e-postulat.ru/index.php/Postulat/article/view/61/64. — 17.01.2020.
    3. Маковейчук, К.А., Колодин, В. Р. Построение алгоритма формирования базы данных информационного и контрольно-аналитического обеспечения финансовой стратегии предприятия / К.А. Маковейчук, В.Р. Колодин // В сборнике: Информационные системы в моделировании и управлении: сборник материалов Всероссийской научно-практической конференции. Гуманитарно-педагогическая академия (филиал) ФГАОУ ВО «КФУ им. В.И. Вернадского» в г. Ялте; Санкт-Петербургский государственный электротехнический университет «ЛЭТИ». — Симферополь: ИТ «АРИАЛ», 2020. — 290 с. — С. 214 — 219.
    4. Паклин, Н. Б. Бизнес-аналитика: от данных к знаниям: учебное пособие / Н. Б. Паклин, В. И. Орешков. – 2-е изд., испр. – СПб: Питер, 2013. – 704 с.: ил. ISBN 978-5-459-00717-6
    5. Спирли, Э. Корпоративные хранилища данных. Планирование, разработка, реализация [Текст] = Enterprise data warehouse. Planning, building, and implementation / Э. Спирли; [Пер. с англ. и ред. В.М. Неумоина]. – М. : Вильямс, 2001. –Т. 1. – Парал. тит. л.: англ. – 396 с.: ил., табл. – Библиогр.: с. 383-386. ISBN 5-8459-0191-X
    6. Сухобоков, А. А. Влияние инструментария Big Data на развитие научных дисциплин, связанных с моделированием / А. А. Сухобоков, Д. С. Лахвич // Наука и образование: научное издание МГТУ им. Н.Э. Баумана. – 2015. – № 3. – С. 207–240.

    Электронное периодическое издание зарегистрировано в Федеральной службе по надзору в сфере связи, информационных технологий и массовых коммуникаций (Роскомнадзор), свидетельство о регистрации СМИ — ЭЛ № ФС77-41429 от 23.07.2010 г.

    Соучредители СМИ: Долганов А.А., Майоров Е.В.

    Обработка транзакций Обработка исключений ASP.NET MVC

    Я использую S # arp Architecture в проекте, который поставляется с атрибутом [Transaction] для методов контроллера. При этом Transaction Commit вызывается как фильтр OnActionExecuted, то есть он появляется после выхода из области метода Controller. Моя проблема с этим — это то, что происходит, когда во время коммита происходит исключение?

    Из исходного кода S # arp вы можете увидеть следующий код в TransactionAttribute.cs

    В качестве примера, если пользователь попытался зафиксировать сохранение, в котором было ограничение внешнего ключа (и были неверные данные), Commit создаст исключение базы данных, которое не обрабатывается. Вместо того, чтобы сбрасывать пользователя на общую страницу ошибок (a la [HandleError]), я бы скорее вернул их прямо туда, где они были, чтобы они могли исправить проблему. Я мог бы сделать это, если я делаю транзакцию явно в рамках метода Controller. Я не могу с тех пор, как пост-фильтр, он выходит за рамки.

    Я хотел бы посмотреть, что другие будут делать в этой ситуации.

    Илон Маск рекомендует:  CSS-трансформации. Изменение размера
  • Понравилась статья? Поделиться с друзьями:
    Кодинг, CSS и SQL