БД_1-20

9. Назначение и составные части реляционной модели данных. Понятия домена, атрибута, схемы отношения, кортежа, отношения. Свойства отношений. Реляционная база данных (РБД) на концептуальном уровне ANSI/SPARC выглядит как совокупность взаимосвязанных простых таблиц. РБД управляется реляционной СУБД (РСУБД). Принципы реляционной модели были сформулированы в 1969–1970 годах Э. Ф. Коддом (E. F. Codd). Идеи Кодда были впервые подробно изложены в статье «A Relational Model of Data for Large Shared Data Banks», ставшей классической. Наиболее известными альтернативами реляционной модели являются иерархическая модель, и сетевая модель. Некоторые системы, использующие эти старые архитектуры, используются до сих пор. Кроме того, можно упомянуть об объектно-ориентированной модели, на которой строятся так называемые объектные СУБД, хотя однозначного и общепринятого определения такой модели нет. Реляционная модель данных – логическая модель данных, прикладная теория, описывающая структурный аспект, аспект целостности и аспект обработки данных в реляционных базах данных. РМД представляет собой набор понятий и языковых конструкций, предназначенных для описания структур данных, ограничений целостности данных и операций манипулирования данными на логическом уровне. Модели присущи следующие аспекты (составляющие): 1. Структурный аспект – данные в БД представляют собой набор отношений (таблиц). 2. Аспект целостности – эти отношения отвечают определенным условиям целостности. РМД поддерживает декларативные ограничения целостности уровня домена (типа данных), уровня отношения и уровня БД. 3. Аспект обработки – РМД поддерживает операторы манипулирования данными (реляционная алгебра и реляционное исчисление), которые генерируют новые отношения на основании уже имеющихся и среди которых есть, по крайней мере, операторы сокращения, проекции и объединения. Основные понятия Тип данных – множество значений, не имеющих внутренней структуры. Это определение совпадает с определением типа данных. С любым конкретным типом связано множество операторов. Домен – допустимое потенциальное ограниченное подмножество значений данного типа. Например, домен ИМЕНА определен на базовом типе символьных строк, но в число его значений могут входить только те строки, которые могут представлять имена (в частности, для возможности представления русских имен такие строки не могут начинаться с мягкого или твердого знака и не могут быть длиннее, например, 20 символов). Атрибут – имя, сопоставленное в соответствие домену. Атрибут принимает значения на домене и наследует его свойства. Говорят, что атрибут определен на домене. По сути, это элемент данных в кортеже. Отношение на интуитивном уровне можно понимать как таблицу, заголовком которой является строка атрибутов, а значимыми строками — строки их значений, однако это неточное представление. Множество кортежей SR, соответствующих одной и той же схеме R, называется отношением. Отношение характеризуется: – арностью (степенью) — числом пар <домен, атрибут> в схеме; – мощностью — числом кортежей, составляющих тело отношения. Свойства отношений Атомарность значений атрибутов. Схема отношения не может включать атрибуты, имеющие внутреннюю структуру. Это следует из определения атрибута – он определяется на домене, а домен – подмножество значений простого типа данных. Отношения, обладающие данным свойством, нормализованы, то есть находятся в первой нормальной форме (1НФ). Уникальность атрибутов. Одноименные атрибуты недопустимы. Только за счет уникальности атрибутов можно отнести значение из кортежа к определенному домену. Неупорядоченность атрибутов. Определяя схему отношения, мы выписываем атрибуты в каком-то порядке, но этот порядок несущественен, что следует из определения схемы отношения как множества пар (домен, атрибут). Уникальность кортежей. Так как отношение есть множество кортежей, в нем не должно быть дубликатов. Из этого следует то, что схема любого отношения содержит подмножество атрибутов, значения которых уникально идентифицируют кортеж. Подобные подмножества являются возможными ключами отношения. Неупорядоченность кортежей. Как и в случае атрибутов, порядок кортежей в памяти несущественен. Существенна уникальность кортежей. Каждый кортеж может быть найден по его возможному ключу. Изменяемость отношений. Тело отношения может меняться во времени. Кортежи могут модифицироваться (при изменении значений атрибутов), удаляться или добавляться.	10. Организация данных SQL-системы. Объекты, схема, каталог, кластер. SQL (Structured Query Language) – универсальный компьютерный язык, применяемый для создания, модификации и управления данными в реляционных базах данных. SQL не является языком программирования и не содержит никаких процедурных средств. Первый официальный стандарт языка SQL - SQL86, несколько уточнён в 1989 году. После были SQL92 и SQL99. В настоящее время действует стандарт, принятый в 2003 с небольшими модификациями, внесёнными позже. Стандарт трактует объект как нечто, имеющее уникальное имя и определение, постоянно сохраняемые в системном каталоге СУБД. Например, объектами являются схемы, явно определенные таблицы, домены, правила (утверждения). Объект создается пользователем, имеющим соответствующую привилегию CREATE. Этот пользователь является владельцем объекта и может распоряжаться им по своему усмотрению. В частности, он может передавать привилегии другим пользователям. Объект может быть уничтожен только его владельцем. Исполняя оператор уничтожения объекта, система удалит из своего каталога его имя и определение. Основные типы объектов: - assertion (утверждение) – объект, содержащий проверку ограничения, записанного в виде предиката, ссылающегося на столбцы таблиц; - character set (набор символов) определяет допустимые в строке символы; - collation (сравнение) определяет порядок сортировки символьных строк; - domain (домен) – объект, который может использоваться как альтернатива типу данных для столбцов. Домен определяет тип данных и может также задавать некоторые другие элементы, например, значение по умолчанию, одно или несколько ограничений; - schema (схема) – поименованная группа связанных объектов, управляемых единым идентификатором авторизации; - table (таблица) – объект, являющийся набором значений, которые могут разделяться на строки и столбцы, так что на пересечении строки и столбца располагается только одно значение. Все значения в столбце принадлежат одному типу данных (домену). Столбцы имеют имена, уникальные в пределах таблицы; - translation (трансляция) определяет преобразование строки одного набора символов в строку другого набора; - view (представление) – объект, содержащий именованный запрос, на который можно ссылаться в операторах манипулирования данными. Система записывает определения объектов (метаданные) в своей внутренней БД, состоящей из специальных таблиц. Полный набор этих таблиц называется системным каталогом. Владельцем системного каталога является СУБД. Пользователь может получить данные из системных таблиц средствами SQL, но никакой ID не имеет права их обновления посредством операторов манипулирования данными. Таблицы системного каталога обновляются системой. Системный каталог есть принадлежащий SQL-системе набор таблиц, содержащий определения объектов. Конкретный пользователь может получать из таблиц системного каталога сведения об объектах, доступных ему в силу имеющихся привилегий. Стандарт предлагает обеспечивать ограничение доступа к системному каталогу путем определения для каждого ID так называемой информационной схемы – набора виртуальных таблиц (представлений), отображающих в момент обращения к ним текущее состояние того фрагмента системного каталога, который соответствует привилегиям ID. Стандарт определяет состав и структуру этих таблиц. Информационная схема есть стандартизованный набор представлений таблиц системного каталога, создаваемый для конкретного ID. В стандарте нет определения понятия «база данных». Вместо него используются понятия «схема», «каталог», «кластер». Схема состоит из определений объектов и может содержать домены, различные виды таблиц, правил и т.п. Она создается пользователем, имеющим привилегию создания объектов. Схема может быть определена явно или неявно, но в любом случае имеет уникальное имя, связанное в системном каталоге с ID автора объектов. Схемой - поименованная группа связанных объектов, управляемых единым идентификатором авторизации. Схема является минимальной базой данных, доступной конкретному пользователю в конкретном сеансе. Однако пользователь может создать несколько автономных схем, он может иметь привилегии на объекты других пользователей, и все эти источники данных могут потребоваться ему в одном сеансе. Поэтому стандарт предусматривает и более сложную организацию данных. Схемы могут быть сгруппированы в каталоги, а каталоги – в кластеры. Каталог – именованная группа схем, обрабатывающаяся как единый объект. Каждый каталог содержит информационную схему, описывающую содержимое схем каталога. Владельцу каталога автоматически предоставляется привилегия просмотра информационной схемы, но не внесения изменений в неё непосредственно. Кластер – набор каталогов, максимальная база данных конкретного ID, содержит все объекты, доступные ему в конкретном сеансе.	8. Реляционные исчисления (РИ). Правильно построенные формулы РИ с переменными-кортежами.---Манипуляционная часть РМД описывает два эквивалентных способа манипулирования реляционными данными - реляционную алгебру и реляционное исчисление. В выражениях реляционной алгебры указывается, как следует выбрать из отношений, а в реляционном исчислении – что. ---Базисными понятиями исчисления являются понятие переменной с определенной для нее областью допустимых значений и понятие правильно построенной формулы, опирающейся на переменные, предикаты и кванторы. Существует теория реляционного исчисления кортежей и реляционного исчисления доменов. В исчислении кортежей допустимым значением каждой переменной является кортеж некоторого отношения.---Для определения кортежной переменной используется оператор RANGE. Например, для того, чтобы определить переменную S, областью определения которой является отношение СОТРУДНИКИ, нужно употребить конструкцию---RANGE S IS СОТРУДНИКИ.---Ссылка на значение атрибута Num переменной S: S.Num.---Правильно построенные формулы (WFF) служат для выражения условий, накладываемых на кортежные переменные. Основой WFF являются простые сравнения, представляющие собой операции сравнения скалярных значений: =, NOT, AND, OR и IF ... THEN. Правильно построенная формула может содержать кванторы EXISTS (существует) и FORALL (для всякого).---Переменные, входящие в WFF, могут быть свободными или связанными. Все переменные, входящие в WFF, при построении которой не использовались кванторы, являются свободными. Например, (S.Num, S.Fam) WHERE Ci = ‘Томск’. Если же имя переменной использовано сразу после квантора при построении WFF вида EXISTS var (form) или FORALL var (form), то в этой WFF и во всех WFF, построенных с ее участием, var - это связанная переменная. Это означает, что такая переменная не видна за пределами минимальной WFF, связавшей эту переменную. Связанная переменная подобна локальной переменной в языках программирования. Формула, в которой все переменные связаны, называется закрытой. Например, FORALL x (EXISTS y (f(x, y))) – закрытая формула. Формула, содержащая по крайней мере одну свободную переменную, называется открытой. ТАБЛИЦА ДЛЯ БИЛЕТА №7
		5. Модель "сущность - связь". Назначение модели. Понятия сущности, связи, атрибута. Типы связей. Модель «сущность-связь» (ER-модель) опубликована американским исследователем в области баз данных Питером Ченом в 1976 году. С тех пор она расширялась и модифицировалась как самим Ченом, так и многими другими исследователями. В различных вариантах она вошла в состав многих CASE-средств поддержки проектирования информационных систем. Модель представляет собой графическую нотацию, основанную на блоках и соединяющих их линиях, с помощью которых можно описывать объекты и отношения между ними. Спецификации требований пользователя представляются в виде диаграммы, показывающей объекты предметной области, их связи и свойства – ER-диаграммы. Существует множество различных графических нотаций, используемых для построения ER-диаграмм. Какие бы нотации ни использовались, ER-диаграмма наглядно и точно отражает представления автора о требованиях пользователя к данным. Поэтому она является хорошим источником информации для проектировщика логической модели данных. С другой стороны, диаграммы выразительны, наглядны и легко интерпретируются конечными пользователями. Поэтому их очень удобно использовать при обсуждении требований к данным с конечными пользователями. Базовые понятия Сущность (entity) – некоторый объект, уникально выделяемый пользователем в предметной области. Сущности одного и того же типа образуют классы сущностей. К примеру, Студент – это класс сущностей, имеющих одинаковые наборы характеристик, значения которых представляют интерес для пользователя. Пользователь заинтересован в сведениях об экземплярах класса. Термин «сущность» используется как в смысле «класс сущностей», так и в смысле «экземпляр класса сущностей», если это не вызывает недопонимания. Итак, класс сущностей — это абстракция, понятие, выделяемое пользователем. В сознании пользователя понятию сопоставляется символ — имя сущности. В естественном языке это всегда имя существительное в единственном числе. Имя сущности имеет для пользователя единственный вполне конкретный смысл, однако неискушѐнный человек не всегда может передать его с помощью других слов. Связь (relationship) – ассоциация, объединяющая несколько сущностей. Под экземпляром связи понимают связь экземпляров одного или более классов сущностей. Класс связей – осмысленная с точки зрения пользователя ассоциация классов сущностей. Смысл ассоциации передается глагольным оборотом, связывающим имена сущностей. Экземпляр класса связей – выражение вида: «Петров преподает ―Вычислительную математику‖». Атрибут – характеристика сущности или связи, значимая с точки зрения пользователя. Атрибут имеет имя и принимает значения. Именем атрибута всегда является имя существительное. Атрибут может быть: – простым или составным (имеющим сложную внутреннюю структуру) – однозначным или многозначным (принимает более одного значения для экземпляра сущности) – первичным или производным (значение атрибута может быть вычислено при помощи других атрибутов) Свойства связей 1. Степень связи Число классов сущностей, формирующих связь, называются степенью (арностью) связи 2. Мощность связи Под мощностью понимается число экземпляров связи, в которых может участвовать один экземпляр сущности. Пусть Е1, Е2,…, Еn – сущности, образующие n-арную связь R. Мощностью связи R со стороны сущности Еi называется число экземпляров связи, в которых может участвовать один экземпляр сущности Еi. Значение мощности зависит от бизнес-правил. Например, численность группы: 1:M – неограниченная, 1:(10,20) – от 10 до 20, 1:20 – ровно 20 человек. В реальной жизни последние 2 ограничения встречаются крайне редко. 3. Степень участия сущности в связи Мощность характеризует максимальное число экземпляров связи с участием одного экземпляра сущности. Однако бизнес-правила могут ограничивать и минимальное. Этому ограничению в ER-модели соответствует понятие степени участия сущности в связи. Степень участия – это характеристика обязательности/необязательности участия экземпляра сущности в связи. Пусть Е1, Е2,…, Еn – сущности, образующие n-арную связь R. Связь R является обязательной со стороны сущности Еi, если каждый экземпляр Еi должен участвовать хотя бы в одном экземпляре связи. В противном случае связь является необязательной со стороны Еi. Типы бинарных связей Наиболее распространенными являются бинарные связи (связи степени 2). Они играют очень важную роль в концептуальном моделировании. Принято выделять три типа бинарных связей. Их обозначают 1:1, 1:N и M:N. 1:1 – один экземпляр Е1 может участвовать не более чем в одном экземпляре связи и один экземпляр Е2 может участвовать не более чем в одном экземпляре связи. 1:N – экземпляр Е1 может участвовать в N экземплярах связи, а экземпляр Е2 – не более чем в одном. M:N – экземпляр Е1 может участвовать в N экземплярах связи, а экземпляр Е2 – в M экземплярах.

1. Восстановление состояния базы данных. Типы сбоев и их последствия. Роль системного журнала в процедурах восстановления. Протокол WAL. Одним из основных требований к развитым СУБД является надежность хранения. Одним из пунктов этого требования является возможность восстановления согласованного состояния базы данных после любого рода аппаратных и программных сбоев. Ситуации, при которых требуется производить восстановление состояния БД: Локальный сбой. Тривиальной ситуацией отката транзакции является ее явное завершение оператором ROLLBACK. Возможны также ситуации, когда откат транзакции инициируется системой. Примерами могут быть возникновение исключительной ситуации в прикладной программе (например, деление на ноль) или выбор транзакции в качестве жертвы при обнаружении синхронизационного тупика. Для восстановления согласованного состояния базы данных при индивидуальном откате транзакции нужно устранить последствия операторов модификации базы данных, которые выполнялись в этой транзакции. Восстановление после внезапной потери содержимого оперативной памяти (мягкий сбой). Такая ситуация может возникнуть при аварийном выключении электрического питания, при возникновении неустранимого сбоя процессора (например, срабатывании контроля оперативной памяти) и т.д. Ситуация характеризуется потерей той части БД, которая к моменту сбоя содержалась в буферах оперативной памяти. Восстановление после поломки основного внешнего носителя базы данных (жесткий сбой). Эта ситуация при достаточно высокой надежности современных устройств внешней памяти может возникать сравнительно редко, но тем не менее, СУБД должна быть в состоянии восстановить базу данных даже и в этом случае. Основой восстановления является архивная копия и журнал изменений базы данных (логи). Во всех трех случаях основой восстановления является избыточное хранение данных. Эти избыточные данные хранятся в журнале, содержащем последовательность записей об изменении базы данных. Журнализация изменений тесно связана не только с управлением транзакциями, но и с буферизацией страниц базы данных в оперативной памяти. По причинам объективно существующей разницы в скорости работы процессоров и оперативной памяти и устройств внешней памяти буферизация страниц базы данных в оперативной памяти – единственный способ достижения удовлетворительной эффективности СУБД. Немедленная запись при любых изменений в журнал во внешней памяти привела бы к существенному замедлению работы системы, поэтому записи в журнал тоже буферизуются: при нормальной работе очередная страница выталкивается во внешнюю память журнала только при полном заполнении записями. Имеются два вида буферов – буфер журнала и буфер страниц оперативной памяти, которые содержат связанную информацию. И те, и другие буфера могут выталкиваться во внешнюю память. Проблема состоит в выработке некоторой общей политики выталкивания, которая обеспечивала бы возможности восстановления состояния базы данных после сбоев. Проблема не возникает при индивидуальных откатах транзакций, поскольку в этих случаях содержимое оперативной памяти не утрачено и можно пользоваться содержимым как буфера журнала, так и буферов страниц базы данных. Но при мягком сбое (содержимое буферов утрачено) для восстановления базы данных необходимо иметь согласованное состояние журнала и БД во внешней памяти. Основным принципом согласованной политики выталкивания буфера журнала и буферов страниц базы данных является то, что запись об изменении объекта базы данных должна попадать во внешнюю память журнала раньше, чем измененный объект оказывается во внешней памяти базы данных. Соответствующий протокол журнализации (и управления буферизацией) называется Write Ahead Log (WAL) - "пиши сначала в журнал". Другими словами, если во внешней памяти находится объект БД, по отношению к которому выполнена операция модификации, то в журнале обязательно находится запись, соответствующая этой операции. Обратное неверно, т.е. в журнале есть запись об изменении объекта, но сам этот объект может отсутствовать во внешней памяти. Дополнительное условие на выталкивание буферов накладывается тем требованием, что каждая успешно завершившаяся транзакция должна быть реально зафиксирована во внешней памяти. Какой бы сбой не произошел, система должна быть в состоянии восстановить состояние базы данных, содержащее результаты всех зафиксированных к моменту сбоя транзакций. Простым решением было бы выталкивание буфера журнала, за которым следует массовое выталкивание буферов страниц базы данных, изменявшихся данной транзакцией. Довольно часто так и делают, но это вызывает существенные накладные расходы при выполнении операции фиксации транзакции. Оказывается, что минимальным требованием, гарантирующим возможность восстановления последнего согласованного состояния базы данных, является выталкивание при фиксации транзакции во внешнюю память журнала всех записей об изменении базы данных этой транзакцией. При этом последней записью в журнал, производимой от имени данной транзакции, является специальная запись о конце транзакции. Индивидуальный откат транзакции Индивидуальный откат транзакции производится либо по оператору ROLLBACK, либо вследствие локального сбоя. Для осуществления отката создаётся список записей журнала от данной транзакции. Элементы списка размещены в порядке, обратном хронологическому. Список последовательно просматривается и для каждой записи выполняется противоположная по смыслу операция, восстанавливающая предыдущее состояние объекта базы данных. Начальным состоянием для процедуры отката является состояние буферов БД в момент прекращения транзакции. С точки зрения системы процедура отката является транзакцией. Поэтому обратные операции также регистрируются в журнале. Это «перестраховка» на случай мягкого сбоя системы в процессе отката. Имея эти записи, система сможет «дооткатить» транзакцию, откат которой был прерван. Восстановление после мягкого сбоя Рабочие буферы базы данных, в отличие от буфера журнала, не выталкиваются во внешнюю память при каждом успешном завершении транзакции. Реально исполнение оператора COMMIT сводится к тому, что становится невозможной отмена проделанных транзакцией изменений. Сам же изменённый объект может ещё долго существовать только в рабочем буфере БД. Может случиться так, что в системе произойдёт сбой после успешного выполнения COMMIT, но до того, как обновлённый транзакцией объект попадёт во внешнюю память. В соответствии с принципом долговечности транзакции система должна при перезагрузке сохранить эти обновления в ФБД, несмотря на то, что их уже нет в буфере оперативной памяти. Кроме того, система может временно помещать во внешнюю память промежуточные результаты транзакций, если необходимо освободить место в буферах. При нормальной работе эти несогласованные изменения по завершении внесшей их транзакции отвергаются. Поскольку мягкий сбой прерывает все транзакции, промежуточные результаты оказываются «зафиксированными». При перезагрузке система должна откатить все прерванные транзакции и выполнить повторно все успешно завершившиеся, но не зафиксированные в ФБД. Текущее состояние ФБД в момент сбоя не может быть использовано как опорное для восстановления, поскольку неизвестно, к какому моменту времени оно относится. Для того чтобы иметь такое опорное состояние БД, система принимает контрольную точку. В некотором интервале времени она дожидается завершения очередных операций обновления во всех транзакциях и не допускает запуска новых операций. Исполнение действующих транзакций приостанавливается. В момент принятия контрольной точки, когда все транзакции приостановлены, в журнале создаётся специальная запись контрольной точки, содержащая список всех транзакций, существующих в системе. Затем во внешнюю память принудительно выталкивается содержимое буфера журнала и рабочих буферов СУБД. По завершении этого процесса исполнение приостановленных транзакций продолжается. Восстановление после жесткого сбоя При жёстком сбое физическая база данных оказывается разрушенной. Поэтому для восстановления необходимо иметь её резервную копию. Обычно резервное копирование ФБД выполняется по факту переполнения системного журнала. Для этого в файле журнала устанавливается так называемая «жёлтая зона», по достижении которой запуск новых транзакций не производится. Система дожидается окончания всех существующих транзакций. После этого рабочие буферы журнала и базы данных выталкиваются во внешнюю память. Созданное таким образом состояние ФБД копируется на резервный носитель, а файл журнала очищается. Может быть также создана резервная копия журнала. При восстановлении после жёсткого сбоя восстанавливается состояние ФБД на момент последнего копирования, а затем по текущему журналу регистрации повторно исполняются все транзакции, успешно завершившиеся до момента сбоя. Поскольку жёсткий сбой не сопровождается потерей буферов, после восстановления можно даже продолжить исполнение не завершившихся к моменту сбоя транзакций. Однако обычно все незавершённые транзакции откатываются.

3. Модель транзакции в SQL. Пользователь может выполнить транзакцию всегда. Транзакция начинается автоматически с первым оператором SQL или непосредственно по окончании предыдущей транзакции. Транзакция может завершиться одним из 4 способов: фиксацией внесенных изменений; отменой проделанных изменений (откатом); успешным завершением прикладной программы с фиксацией изменений, внесѐнных последней исполнявшейся транзакцией; аварийным завершением прикладной программы с откатом последней исполнявшейся транзакции. Стандарт допускает неполную изолированность транзакций, поскольку обеспечение полной изолированности требует, как правило, очень больших затрат на блокировки. Система может существенно уменьшить эти затраты, если будет заранее знать, какой уровень изолированности требуется реально. Для каждой транзакции может быть установлен индивидуальный уровень изолированности. «Грязные» чтения возникают, если изменения, внесенные незавершенной транзакцией, будут видны другим транзакциям. Проблема возникает в случае отката незавершенной транзакции, так как данные перестают иметь смысл. Неповторяющиеся чтения неприемлемы, когда транзакция извлекает некоторые данные с целью их частичного изменения и последующей записью в базу. Проблема возникает, если другая транзакция после первой выборки изменит некоторые из значений, требуемых исходной транзакции для модификации. Фантомная вставка является частным случаем неповторяющихся чтений. Проблема проявляется при вставке некоторых данных конкурирующей транзакцией во время работы основной транзакции. По умолчанию для любой транзакции установлен высший уровень изолированности – SERIALIZABLE. Параллельно исполняющиеся транзакции никак не влияют на данные, которые она использует. На уровне REPEATABLE READ чтение всех изменений своей транзакции, любые изменения, внесѐнные конкурирующими транзакциями после начала своей недоступны, нечистые и неповторяемые чтения невозможны, возможны фантомы. На уровне READ COMMITED возможны неповторяющиеся чтения. Он является вполне удовлетворительным, если транзакции не потребуется дважды считывать одну и ту же строку, накапливать итоги или выполнять вычисления, для которых необходимы непротиворечивые данные. В режимах REPEATABLE READ и READ COMMITED на транзакцию могут повлиять только окончательные (зафиксированные) результаты параллельно исполняющихся транзакций. В режиме READ UNCOMMITED ей доступны и промежуточные результаты. Этот режим можно использовать лишь в том случае, когда допустимы «грязные» данные в результатах запросов. Какой бы уровень изолированности ни был установлен для транзакции, система гарантирует сохранение внесѐнных ею изменений в случае успешного завершения.Операторы для работы с транзакциями Оператор SET TRANSACTION определяет уровень изолированности транзакции и режим изменения данных во время еѐ исполнения. Оператор может быть исполнен только в момент, когда в сеансе нет активной транзакции. Спецификации принимаются для следующей транзакции. SET TRANSACTION { { ISOLATION LEVEL {READ UNCOMMITED | READ COMMITED | REPEATABLE READ | SERIALIZABLE} } | { READ ONLY | READ WRITE } | { DIAGNOSTICS SIZE число_сообщений} }.,..; Предложение DIAGNOSTICS SIZE определяет количество элементов, используемых для хранения сообщений об ошибках. Параметр число_сообщений должен быть положительным целым числом. COMMIT [ ]; сообщает системе, что транзакция завершена успешно и следует попытаться зафиксировать внесѐнные изменения в ФБД. Эта попытка может оказаться неуспешной, поскольку перед фиксацией выполняются все отложенные проверки ограничений. Если какое-либо из них нарушено, произойдет автоматический откат транзакции и будет выдано сообщение об ошибке. Изменения могут быть не зафиксированы также из-за системного сбоя. ROLLBACK [ ]; прекращает исполнение текущей транзакции и отменяет все внесѐнные изменения. Этот оператор никогда не может завершиться аварийно или остаться невыполненным.