Уровни изоляции.

194

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

Синтаксис операторов SQL, определяющих уровни изоляции

Уровень изоляции транзакции задается следующим оператором:

SET TRANSACTION {ISOLATION LEVEL {READ UNCOMMITTED | READ COMMITTED

| REPEATABLE READ

| SERIALIZAABLE}

| {READ ONLY | READ WRITE}}, ...

Этот оператор определяет режим выполнения следующей транзакции, т. е. этот оператор не влияет на изменение режима той транзакции, в которой он подается. Обычно, выполнение оператора SET TRANSACTION выделяется как отдельная транзакция:

…(предыдущая транзакция выполняется со своим уровнем изоляции)

COMMIT;

SET TRANSACTION LEVEL REPEATABLE READ; COMMIT;

…(следующая транзакция выполняется с уровнем изоляции REPEATABLE READ)

Если задано предложение ISOLATION LEVEL, то за ним должно следовать один из параметров, определяющих уровень изоляции.

Кроме того, можно задать признаки READ ONLY или READ WRITE. Если указан признак READ ONLY, то предполагается, что транзакция будет только читать данные. При попытке записи для такой транзакции будет сгенерирована ошибка. Признак READ ONLY введен для того, чтобы дать производителям

195

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

Оператор SET TRANSACTION должен удовлетворять следующим условиям:

1)Если предложение ISOLATION LEVEL отсутствует, то по умолчанию принимается уровень SERIALIZABLE.

2)Если задан признак READ WRITE, то параметр ISOLATION LEVEL не может принимать значение READ UNCOMMITTED.

3)Если параметр ISOLATION LEVEL определен как READ UNCOMMITTED,

то транзакция становится по умолчанию READ ONLY. В противном случае по умолчанию транзакция считается как READ WRITE.

197

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

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

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

Архитектура с файловым сервером

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

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

198

Рис. 15.2. Архитектура с файловым сервером

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

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

•функции по обработке и интерпретации данных в соответствии с решаемой прикладной задачей (бизнес-логика);

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

•а также мета-данные базы данных (информация о ее схеме, правилах обеспечения целостности данных и т.д., иными словами – «данные о

данных»); реализуются в данном случае соответствующим программным обеспечением,

располагающимся на компьютере (компьютерах) клиентской стороны. Достоинством такой системы по сравнению с мэйнфреймовой является

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

Представителями такого рода файл-серверных систем баз данных являются широко распространенные вплоть до настоящего времени программные комплексы: Dbase, FoxPro, Clipper, Clarion, Paradox и др.

199

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

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

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

202

Трехзвенная архитектура с сервером приложений

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

Рис. 15.5. Архитектура с сервером приложений

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

Что дает такое перераспределение функций?

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

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

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

203

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

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

204

Рекомендуемая литература

1.К.Дейт. Введение в системы баз данных. 7-е издание: Пер. с англ. – К.; М.; СПб.: Издательский дом «Вильямс», 2001. – 1072 с., ил.

2.Г.Буч. Объектно-ориентированный анализ и проектирование с примерами приложений на С++./Пер. с англ. - М.: «Издательство Бином», СПб.: «Невский диалект», 2001. – 558 с., ил.

3.Ульман Д. Основы реляционных баз данных / Джеффри Д. Ульман, Дженнифер Уидом; Пер. с англ.– М.: Лори, 2006 .— 374 с.

4.Т.С.Карпова. Базы данных: модели, разработка, реализация: учебник. –

СПб.: Питер, 2002. – 303 с.: ил.

5.С.М.Диго. Базы данных : проектирование и использование: учебник.– М.: Финансы и статистика, 2005 .— 590 с.: ил.

6.А.В.Кузин. Базы данных: учебное пособие.–М.: Academia, 2005.– 314 с.: ил.

7.А.Ю.Пушников. Введение в системы управления базами данных. Часть 1. Реляционная модель данных: Учебное пособие/ Изд-е Башкирского ун-та. –

Уфа. 1999. – 108 с.

8.А.Ю.Пушников. Введение в системы управления базами данных. Часть 2. Нормальные формы отношений и транзакции: Учебное пособие/ Изд-е Башкирского ун-та. – Уфа. 1999. – 105 с.

9.И.Ф.Астахова, А.П.Толстобров, В.М.Мельников. SQL в примерах и задачах: Учебное пособие: Мн.: Новое знание, 2002. – 176 с.

10.М.Грабер. Введение в SQL. Пер. с англ. – М.: «ЛОРИ», 1996. – 380 с., ил.

11.С.Д.Кузнецов. SQL: Язык реляционных баз данных.– М.: Майор: Осипенко, 2001 .– 191 с.: ил.

12.В.А.РезниченкоH ,H Ф.И.АндонH .H Язык запросов SQL: учебный курс.— СПб:

Питер, 2006 .— 416 стр.