Управление транзакциями, сериализация транзакций (синхронизационные захваты, метод временных меток), изолированность пользовате­лей.

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

Изолированность пользователей

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

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

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

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

Третий уровень - отсутствие неповторяющихся чтений. Рассмотрим следующий сценарий. Транзакция 1 читает объект базы данных A. До завершения транзакции 1 транзакция 2 изменяет объект A и успешно завершается оператором COMMIT. Транзакция 1 повторно читает объект A и видит его измененное состояние. Чтобы избежать неповторяющихся чтений, до завершения транзакции 1 никакая другая транзакция не должна изменять объект A. В большинстве систем это является максимальным требованием к синхронизации транзакций, хотя, как мы увидим немного позже, отсутствие неповторяющихся чтений еще не гарантирует реальной изолированности пользователей.

К более тонким проблемам изолированности транзакций относится проблема кортежей-"фантомов", вызывающая ситуации, которые также противоречат изолированности пользователей. Рассмотрим следующий сценарий. Транзакция 1 выполняет оператор A выборки кортежей отношения R с условием выборки S (т.е. выбирается часть кортежей отношения R, удовлетворяющих условию S). До завершения транзакции 1 транзакция 2 вставляет в отношение R новый кортеж r, удовлетворяющий условию S, и успешно завершается. Транзакция 1 повторно выполняет оператор A, и в результате появляется кортеж, который отсутствовал при первом выполнении оператора. Конечно, такая ситуация противоречит идее изолированности транзакций и может возникнуть даже на третьем уровне изолированности транзакций. Чтобы избежать появления кортежей-фантомов, требуется более высокий "логический" уровень синхронизации транзакций.

Сериализация транзакций

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

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

Сериализация транзакций - это механизм их выполнения по некоторому сериальному плану.

Между транзакциями могут существовать следующие виды конфликтов:

W-W - транзакция 2 пытается изменять объект, измененный не закончившейся транзакцией 1;

R-W - транзакция 2 пытается изменять объект, прочитанный не закончившейся транзакцией 1;

W-R - транзакция 2 пытается читать объект, измененный не закончившейся транзакцией 1.

Практические методы сериализации транзакций основывается на учете этих конфликтов.

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

Синхронизационных захватов объектов БД

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

Основными режимами синхронизационных захватов являются:

совместный режим - S (Shared), означающий разделяемый захват объекта и требуемый для выполнения операции чтения объекта;

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

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

Объектами синхронизационных захватов могут быть:

файл - физический объект, область хранения нескольких отношений и, возможно, индексов;

отношение - логический объект, соответствующий множеству кортежей данного отношения;

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

кортеж - элементарный физический объект базы данных.

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

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

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

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

Метод временных меток

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

Для этого каждой транзакции T предписывается временная метка t, соответствующая времени начала T. При выполнении операции над объектом r транзакция T помечает его своей временной меткой и типом операции (чтение или изменение).

Перед выполнением операции над объектом r транзакция T1 выполняет следующие действия:

Проверяет, не закончилась ли транзакция T, пометившая этот объект. Если T закончилась, T1 помечает объект r и выполняет свою операцию.

Если транзакция T не завершилась, то T1 проверяет конфликтность операций. Если операции неконфликтны, при объекте r остается или проставляется временная метка с меньшим значением, и транзакция T1 выполняет свою операцию.

Если операции T1 и T конфликтуют, то если t(T) > t(T1) (т.е. транзакция T является более "молодой", чем T), производится откат T и T1 продолжает работу.

Если же t(T) < t(T1) (T "старше" T1), то T1 получает новую временную метку и начинается заново.

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

«+»: не нужно распознавать тупики.

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

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

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

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

Основой поддержания целостности состояния БД является механизм транзакций. Общие принципы восстановления: 1) результаты зафиксированных транзакций должны быть сохранены в восстановленном состоянии базы данных; 2) результаты незафиксированных транзакций должны отсутствовать в восстановленном состоянии базы данных.

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

Возможно 2 варианта ведения журн. информации: 1) для каждой транзакции поддерживается отдельный локальный журнал изменений БД этой транзакцией. Они используются для индивид. откатов и могут поддерживаться в ОЗУ. Кроме того, поддерживается общий журнал, используемый для восстановления после мягких и жестких сбоев. Происходит дублирование информации в обоих журналах; 2) поддержание только общего журнала изменений БД, который используется для 3-х ситуаций.

Журнализация и буферизация.

Журнализация связана с буферизацией страниц БД в ОЗУ, кот. используется для достижения эффективности СУБД. Записи в журнал тоже буферизуются: при нормальной работе очередная страница выталкивается во внешнюю память журнала только при полном заполнении записями.

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

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

Простое решение: выталкивание буфера журнала, за которым следует выталкивание буферов страниц ОЗУ, но это вызывает накладные расходы при фиксации транзакции. Минимальное требование (для восстановления БД) – при фиксации транзакции выталкивание всех записей журнала об изменениях этой транзакцией.

Индивидуальный откат транзакции.

Примеры: откат транзакции – RollBack, откат, инициируемый системой (деление на 0).

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

Индивид. откат выполняется следующим образом: 1) выбирается очередная запись из списка; 2) выполняется противоположная по смыслу операция (Insert->Delete); 3) любая из обратных операций журнализуется. Для индивид. отката это не нужно, может понадобиться в случае мягкого сбоя при индивид. откате; 4) при успешном завершении отката в журнал заносится запись о конце транзакции. С точки зрения журнала такая транзакция является зафиксированной.

Восстановление после мягкого сбоя.

К числу основных проблем восстановление после мягкого сбоя относится то, что одна логическая операция изменения БД может изменять несколько физических блоков БД, например, страницу данных и несколько страниц индексов. Страницы БД буферизуются в ОЗУ и выталкиваются независимо. Несмотря на применение протокола WAL после мягкого сбоя, часть страниц во внешней памяти соответствует объекту до изменения, а часть – после.

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

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

К моменту мягкого сбоя возможны ситуации:

1) Для Т1 делать ничего не надо, т.к. она зафиксирована во внешней памяти. 2) Для Т2 нужно выполнить повторно часть операций (redo). 3) Для транзакции T3 нужно выполнить в обратном направлении первую часть операций (undo). Обратная интерпретация операций T3 корректна и приведет к согласованному состоянию БД. 4) Для транзакции T4, которая успела начаться после момента tpс и закончиться до момента мягкого сбоя, нужно выполнить полную повторную прямую интерпретацию операций (redo).5) Для T5 никаких действий предпринимать не требуется. Результаты операций этой транзакции полностью отсутствуют во внешней памяти базы данных.

Физическая согласованность БД.

Для восстановления состояния БД в момент tpc используются 2 основных подхода: 1) теневой механизм; 2) журнализация постраничных изменений БД.

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

Восстановление к tpc происходит мгновенно: текущая таблица заменяется на теневую. Но может потребоваться много внешней памяти для этого механизма. Обеспечивается согласованное состояние внешней памяти в один общий для всех объектов момент времени.

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

В этой ситуации может поддерживаться 1 из журналов: 1) общий журнал логических и страничных операций. Наличие 2-х видов записей усложняет его структуру. Постраничные изменения могут носить локальный характер и увеличивать размеры журнала; 2) отдельный короткий журнал постраничных изменений.

Восстановление после жесткого сбоя.

В этом случае для восстановления согласованного состояния необходим журнал и архивная копия. Архивная копия – полная копия БД к моменту начала заполнения журнала.

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

Если потерян журнал, то для восстановления используется только архивная копия. Архивация БД выполняется: 1) при переполнении журнала. В журнале вводится так называемая "желтая зона", при достижении которой образование новых транзакций временно блокируется. После этого архивируется БД и журнал заполняется снова; 2) архивацию БД можно выполнять реже, чем переполнится журнал. А при переполнении журнала архивировать сам журнал. Журнальная информация может быть существенно сжата

24. Язык SQL: функции и основные возможности, SEQUEL/SQL СУБД System R, типы данных, средства определения схемы, структура запросов, табличное выражение, агрегатные функции и ре­зультаты запросов, язык модулей, встроенный SQL, набор операторов манипулирования данными, динамический SQL в Oracle V.6.

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

Функции и основные возможности SEQUEL/SQL СУБД System R.

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

Типы данных.

В языке SQL/89 выделяется 3 класса типов данных:

1. Символьные типы. CHAR(n), CHARACTER(n), где n до 255. Размерность n байтов даже, если строка короче. CHARACTER – 1 символ. Символьный тип данных переменной длины: VARCHAR(n) – по 1 байту на каждый символ в соответствии с фактической длиной строки.

2. Точные числа. NUMERIC, DECIMAL (или DEC) – упакованное десятичное; INTEGER (или INT); SMALLINT; TYNIINT .

3. Приблизительные числа. FLOAT (с точностью до 15 знаков), REAL(с точностью до 7 зноков) и DOUBLE PRECISION. Спецификатор типа FLOAT имеет вид FLOAT [(n)]. Специфицируются приблизительные числа с двоичной точностью, равной или большей значения n.

Также имеются следующие типы данных: денежный (Many; smallmany), дата и время (DataTime; smalldatatime), двоичные данные (binary(n), n до 255; varbinary(n)), длинный текст (text), рисунок (image), булево значение (bit – 0 или 1).

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

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

В соответствии с правилами SQL/89 каждая таблица данной БД имеет простое и квалифицированное имена. В качестве квалификатора имени выступает "идентификатор полномочий" таблицы, который обычно в реализациях совпадает с именем некоторого пользователя, и квалифицированное имя таблицы имеет вид: <идентификатор полномочий>.<простое имя>.

Оператор CREATE TABLE определяет базовую таблицу, т.е. реальное хранилище данных.

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

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

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

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

Структура запросов.

Язык допускает 3 типа синтакс.конструкций, начинающихся с ключевого слова SELECT: спецификация курсора, оператор выборки и подзапрос. Основой всех них является синтакс. конструкция "табличное выражение". Семантика табличного выражения состоит в том, что на основе последовательного применения разделов from, where, group by и having из заданных в разделе from таблиц строится некоторая новая результирующая таблица, порядок следования строк которой не определен и среди строк которой могут находиться дубликаты. На самом деле именно структура табличного выражения наибольшим образом характеризует структуру запросов языка SQL/89.

1. Курсор - это понятие языка SQL, позволяющее с помощью набора специальных операторов получить построчный доступ к результату запроса к БД. К табличным выражениям, участвующим в спецификации курсора, не предъявляются какие-либо ограничения. При определении спецификации курсора используются три дополнительных конструкции: спецификация запроса, выражение запросов и раздел ORDER BY. В спецификации запроса задается список выборки (список арифметических выражений над значениями столбцов результата табличного выражения и констант). Выражение запросов - это выражение, строящееся по указанным синтакс.правилам на основе спецификаций запросов. Единственной операцией, которую разрешается использовать в выражениях запросов, является операция UNION (объединение таблиц) с возможной разновидностью UNION ALL. К таблицам-операндам выражения запросов предъявляется то требование, что все они должны содержать одно и то же число столбцов, и соответствующие столбцы всех операндов должны быть одного и того же типа. Раздел ORDER BY позволяет установить желаемый порядок просмотра результата выражения запросов.

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

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

Табличное выражение.

Стандарт SQL/89 рекомендует рассматривать вычисление табличного выражения как последовательное применение разделов FROM, WHERE, GROUP BY и HAVING к таблицам, заданным в списке FROM. Результатом выполнения раздела FROM является расширенное декартово произведение таблиц, заданных списком таблиц раздела FROM. Раздел WHERE задает условия выборки, которые могут использовать: предикат сравнения, предикат between, предикат in, предикат like, предикат null, предикат с квантором и предикат exists. Условие поиска раздела HAVING строится по тем же синтаксическим правилам, что и условие поиска раздела WHERE, и может включать те же самые предикаты. Однако имеются специальные синтаксические ограничения по части использования в условии поиска спецификаций столбцов таблиц из раздела FROM данного табличного выражения. Эти ограничения следуют из того, что условие поиска раздела HAVING задает условие на целую группу, а не на индивидуальные строки.

Агрегатные функции и результаты запросов.

В стандарте SQL/89 определено 5 стандартных агрегатных функций: COUNT - число строк или значений, MAX - максимальное значение, MIN - минимальное значение, SUM - суммарное значение и AVG - среднее значение.

Агрегатные функции предназначены для того, чтобы вычислять некоторое значение для заданного множества строк. Таким множеством строк может быть группа строк, если агрегатная функция применяется к сгруппированной таблице, или вся таблица. Для всех агрегатных функций порядок вычислений следующий: на основании параметров агрегатной функции из заданного множества строк производится список значений. Затем по этому списку значений производится вычисление функции. Если список оказался пустым, то значение функции COUNT для него есть 0, а значение всех остальных функций - null.

Агрегатные функции можно использовать в спецификации курсора, операторе выборки и подзапросе после ключевого слова SELECT и в условии выборки раздела HAVING.

Язык модулей.

В стандарте SQL/89 определены 2 способа взаимодействия с БД из прикладной программы, написанной на традиционном языке программирования: 1) операторы SQL, с которыми может работать данная прикладная программа, собраны в один модуль и оформлены как процедуры этого модуля. Для этого SQL/89 содержит специальный подъязык - язык модулей. При использовании такого способа взаимодействия с БД прикладная программа содержит вызовы процедур модуля SQL с передачей им фактических параметров и получением ответных параметров; 2) использование встроенного SQL, когда в программу на традиционном языке программирования встраиваются операторы SQL. Во встроенных операторах SQL могут использоваться имена переменных основной программы, и за счет этого обеспечивается связь между прикладной программой и СУБД.

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

1) «+»: текст прикладной программы имеет меньший размер. Взаимодействие с СУБД локализовано за счет явных параметров вызовов процедур. «-»: для понимания смысла прикл.программы требуется чтение 2-х текстов.

2) «+»: прикладные программы более "самосодержащиеся". Простоту переноса такой программы в среду другой СУБД, поскольку стандарт встраивания более или менее соблюдается.

«-»:PL-подобный вид таких программ, независимо от выбранного основного языка.

Каждый модуль SQL ориентирован на использование в программах, написанных на конкретном языке программирования. Если в модуле присутствуют процедуры работы с курсорами, то все курсоры должны быть специфицированы в начале модуля. Имена всех процедур в одном модуле должны быть различны. Любое имя параметра, содержащегося в операторе SQL процедуры, должно быть специфицировано в разделе объявления параметров. Список формальных параметров каждой процедуры должен содержать ровно один параметр SQLCODE (код ответа процедуры; возможные значения кодов ответа стандартизованы, но некоторые из них определяются в реализации).

Встроенный SQL.

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

Набор операторов манипулирования данными.

Операторы SQL делятся на:

операторы определения данных (Data Definition Language, DDL)

CREATE создает объект БД (саму базу, таблицу, представление, пользователя и т. д.)

ALTER изменяет объект

DROP удаляет объект

операторы манипуляции данными (Data Manipulation Language, DML)

SELECT считывает данные, удовлетворяющие заданным условиям

INSERT добавляет новые данные

UPDATE изменяет существующие данные

DELETE удаляет данные

операторы определения доступа к данным (Data Control Language, DCL)

GRANT предоставляет пользователю (группе) разрешения на определенные операции с объектом

REVOKE отзывает ранее выданные разрешения

DENY задает запрет, имеющий приоритет над разрешением

операторы управления транзакциями (Transaction Control Language, TCL)

COMMIT применяет транзакцию.

ROLLBACK откатывает все изменения, сделанные в контексте текущей транзакции.

SAVEPOINT делит транзакцию на более мелкие участки.

В стандарте SQL/89 определено 3 группы операторов манипулирования данными.

1. Операторы, связанные с курсором.

1) объявление курсора Declare; 2) открытие курсора OPEN. Ему должен предшествовать оператор объявления; 3) чтение курсора FETCH; 4) позиционное удаление Delete. Если указанный в операторе курсор открыт и установлен на некоторую строку, и курсор определяет изменяемую таблицу, то текущая строка курсора удаляется, а он позиционируется перед следующей строкой; 5) позиционная модификация UPDATE. Позиция курсора не изменяется; 6) закрытие курсора Close.

2. Одиночные операторы манипулирования данными.

1) Оператор выборки (Select); 2) Оператор удаления с условием (Delete); 3) Оператор модификации с условием (Update).

3. Операторы завершения транзакции.

1) COMMIT WORK - текущая транзакция может быть завершена успешно с фиксацией в БД произведенных изменений.

2) ROLLBACK WORK – аварийно завершает транзакцию с удалением из БД изменений, произведенных текущей транзакцией.

При выполнении любого из этих операторов производится принудительное закрытие всех курсоров.

Динамический SQL в Oracle V.6.

1) Оператор подготовки PREPARE имя выр-ния From строка. Во время выполнения оператора строка передается компилятору SQL, который обрабатывает ее почти таким же образом, как если бы получил в статике. Построенный при выполнении оператора PREPARE код остается действующим до конца транзакции или до повторного выполнения данного оператора PREPARE в пределах этой же транзакции.

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

3) Оператор выполнения подготовленного оператора. Оператор EXECUTE служит для выполнения ранее подготовленного оператора SQL (не требующего применения курсора) или для совмещенной подготовки и выполнения такого оператора.

4) Работа с динамическими операторами SQL через курсоры (Prepare, declare,open,close и т.д.).