Темы на экзамен по БД (стр. 3 )

ORDER nIndexNumber - Задает номер файла индекса или тега индекса, используемого для поиска ключа индекса. nIndexNumber указывает файлы индекса в том порядке, в котором они перечислены в команде USE или SET INDEX. Сначала нумеруются открытые файлы. IDX в том порядке, в котором они фигурируют в команде USE или SET INDEX. Затем нумеруются теги в файле структурного индекса. CDX (если он сущ-ет) в порядке их создания. Нумеруются теги во всех открытых независ. файлах. CDX в порядке их создания.

ORDER IDXIndexFileName - Задает файл. IDX, который используется при поиске ключа индекса.

ORDER [TAG] TagName [OF CDXFileName] - Задает тег файла. CDX, использ. для поиска ключа индекса. Имя тега может принадлежать файлу структурного индекса. CDX или любому откр. файлу независимого инд. CDX.

Если в открытых файлах независимых индексов. CDX существуют одинаковые имена тегов, задайте файл. CDX, содержащий нужный тег, с помощью предложения OF CDXFileName.

Команда SORT – Сорт. записи в выбранной в данный момент табл. и выводит отсорт. записи в новую таблицу.

Синтаксис

SORT TO TableName ON FieldName1 [/A | /D] [/C] [, FieldName2 [/A | /D] [/C] ...][ASCENDING | DESCENDING]

[Scope] [FOR lExpression1] [WHILE lExpression2][FIELDS FieldNameList | FIELDS LIKE Skeleton

| FIELDS EXCEPT Skeleton][NOOPTIMIZE]

Параметры

TableName - Задает имя новой таблицы, для отсортированных записей.

ON FieldName1- Задает поле в выбранной в данный момент таблице, будет производиться сортировка. Можно задать имена еще нескольких полей (FieldName2, FieldName3), чтобы дополнительно упорядочить новую таблицу. Первое поле FieldName1 является полем первичной сортировки, второе вторичной и т. д.

[/A | /D] [/C] - Для каждого поля, участвующего в сортировке, можно указать возрастающий или убывающий порядок,/A задает возрастающий, /D ѕ убывающий порядок. Если,/C, регистр будет игнорироваться.

ASCENDING - Задает возрастающий порядок для всех полей, для которых не указана опция /D.

DESCENDING - Задает убывающий порядок для всех полей, для которых не указана опция /A.

Если опустить ASCENDING и DESCENDING, порядок сортировки по умолчанию будет возрастающим.

Scope - Задает диапазон сортируемых записей. Диапазон задается следующими предложениями: ALL, NEXT nRecords, RECORD nRecordNumber и REST. По умолчанию являются все записи (предложение ALL).

FOR lExpression1 - Задает сортировку только тех записей текущей таблицы, для которых логическое условие lExpression1 имеет значение "истина" (.T)

WHILE lExpression2 - Задает условие, в соответствии с которым записи из текущей таблицы включаются в процесс сортировки, пока логическое выражение lExpression2 остается истинным (.T.).

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

FIELDS LIKE Skeleton - Указывает, что в новую таблицу, создаваемую командой SORT, следует включить те поля исходной таблицы, которые соответствуют шаблону имен Skeleton.

FIELDS EXCEPT Skeleton - Указывает, что в новую таблицу, следует включить все поля исходной таблицы, кроме тех, которые соответствуют шаблону имен Skeleton. В шаблоне имен полей Skeleton можно использовать символы подстановки.

NOOPTIMIZE - Блокирует оптимизацию операции SORT по технологии Рашмора.

16. SQL. Категории SQL, типы данных, целостность данных, описание данных, типы связывания, манипулирование данными.

Язык запросов SQL. Основные категории

Язык запросов SQL. Основан на реляционном исчислении с переменными-кортежами.

Язык имеет несколько стандартов

SQL1 – был принят в 1989; SQL2 – был принят в 1992; SQL3 – был принят в 1999

Исходное название – SEQUEL – Structured English Query Language

SQL нужен для выполнения операций над таблицами и над данными таблицы.

Как правило, SQL погружен в среду встроенного языка программирования СУБД

Paradox, FoxPro

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

статический динамический

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

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

Основные категории:

DDL Data Definition Language (Язык определения данных)

Основные команды:

Создать таблицу Удалить таблицу Изменить таблицу Создать представление Изменить представление Удалить представление Создать индекс Удалить индекс

DML Data Manipulation Language (Язык манипулирования данными)

Основные команды:

Создать строку Вставить строку Обновить строку

DQL Data Query Language (Язык запросов к данным)

Основные команды:

1.  Select

DCL Data Control Language (Язык управления данными)

Основная команда:

Контроль над возможностью доступа к данным внутри базы данных.

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

Некоторые команды:

Изменить пароль Дать привилегию Отменить привилегию

DAC – Data Administration Commands (Команды Администрирования Данных)

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

TCC – Transaction Control Commands (Команды управления транзакциями)

Используются только с командами DML

Сохранить транзакцию Отменить транзакцию Создать точки внутри групп транзакций

Все данные в Visual FoxPro имеют тип, то есть описание допустимых значений, их диапазона и размера. Как только тип данных задан, Visual FoxPro может эффективно хранить данные и манипулировать ими.

Переменные и массивы составляют подмножество доступных типов данных Visual FoxPro. Дополнительные типы данных доступны только для полей в таблице. Чтобы добавить программным образом поля определенного типа в таблицу, укажите аббревиатуру типа поля. Подробнее см. описание FieldType в теме CREATE TABLE –

SQL.

Типы данных Visual FoxPro

Тип данных Описание

Character Произвольный текст.

Currency Денежная сумма.

Date Хронологическая дата, состоящая из месяца, года и числа.

DateTime Хронологическая дата, состоящая из месяца, года, числа и времени.

Logical Логическое значение истинности.

Numeric Целое или с дробной частью число.

Типы данных полей таблиц Visual FoxPro

Тип поля Описание

Double Число с плавающей запятой двойной точности.

Float Такое же, как Numeric.

General Ссылка на OLE-объект.

Integer Целочисленные значения

Memo Ссылка на блок данных

Character (Двоичный) Любые символьные данные, которые нужно сопровождать без изменения кодовых страниц

Memo (Двоичный) Любые memo-поля, которые нужно сопровождать без изменения кодовых страниц

Целостность данных

Для определения целостности данных используется построитель целостности данных Referential Integrity Builder (Построитель целостности данных), который содержит перечень всех установленных отношений между таблицами.

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

Язык запросов SQL. Тип связывания

Типы связывания:

Связывание по равенству EQUIT JOINS Естественное связывание NATURAL JOINS Связывание по неравенству NON – EQUI JOINS Внешнее связывание OUTER JOINS Рекурсивное связывание SELF JOINS

Связывание по равенству EQUIT JOINS

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

Естественное связывание NATURAL JOINS

Почти эквивалентно связыванию по равенству, но при естественном связывании повторение эквивалентных строк исключается. Условие связывания оказывается таким же.

Связывание по неравенству NON – EQUI JOINS

При связывании по неравенству 2 или несколько таблиц объединяются по условию неравенства значения столбца одной таблицы значению столбца другой таблицы.

Внешнее связывание OUTER JOINS

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

Рекурсивное связывание SELF JOINS

Рекурсивное связывание предполагает связывание таблицы с ней же самой, как будто бы это 2 таблицы, применяя временные переименования таблицы в операторе SQL.

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

17. SQL. Многотабличные запросы, индексы

Многотабличные запросы. Использование псевдонимов

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

Предполагается, что созданы следующие таблицы:

STUDENT (SNUM, SFAM, SIMA, STIP) USPEV (UNUM, OCENKA, UDATA, SNUM, PNUM) PREDMET (PNUM, PNAME, TNUM) TEACHER (TNUM, TFAM, TIMA, TDATE)

Вывод фамилии преподавателя и предмет, который он ведет

SELECT TEACHER. TFAM, PREDMET. PNAME; FROM TEACHER, PREDMET;

WHERE TEACHER. TNUM=PREDMET. TNUM

Эти таблицы уже были соединены через поле TNUM. Эта связь называется состоянием справочной целостности. Объединение многотабличных запросов, которые используют предикаты, основанные на равенствах – объединение по равенству. Этот же подход может использоваться для объединения вместе двух копий одиночной таблицы. Когда объединяется таблица сама с собой, все повторяемые имена столбца заполняются префиксами имени таблицы. Чтобы ссылаться к этим столбцам внутри запроса, необходимо иметь 2 различных имени для этой таблицы. Это можно сделать с помощью определения временных имен, называемых псевдонимами, которые определяются в предложении FROM запроса.

Вывод фамилий студентов, имеющих одинаковый размер стипендии

SELECT FIRST. SFAM, SECOND. SFAM, FIRST. STIP; FROM STUDENT FIRST, STUDENT SECOND; WHERE FIRST. STIP=SECOND.STIP

FIRST, SECOND - псевдонимы

В данном запросе SQL ведет себя так, как если бы он соединял 2 различные таблицы, называемые FIRST и SECOND. Псевдоним существует только тогда, команда выполняется, а после завершения запроса псевдоним больше не имеет никакого значения. Допускается использовать любое число псевдонимов для одной таблицы запросов.

Для назначения стипендии на следующий семестр, необходимо просмотреть все варианты комбинаций студентов с разными размерами стипендий 25%, 15%, 0%

SELECT FIRST. SFAM, SECOND. SFAM, THIRD. SFAM; FROM STUDENT FIRST, STUDENT SECOND, STUDENT THIRD;

WHERE FIRST. STIP=25 AND SECOND. STIP=15 AND THIRD. STIP=0

Этот запрос находит все комбинации студентов с 3-мя различными размерами стипендии. Такой запрос может быть выполнен с помощью GROUP BY и ORDER BY, поскольку они сравнивают значение только в одном столбце вывода.

В SQL предусматривается создание объединения, которое включает и различные таблицы и псевдонимы одной таблицы.

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

SELECT PREDMET. PNAME, FIRST. SNUM, SECOND. SNUM; FROM USP FIRST, USP SECOND, PREDMET; WHERE FIRST. PNUM=SECOND. PNUM; AND PREDMET. PNUM=FIRST. PNUM; AND FIRST. SNUM<SECOND. SNUM

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

Иногда необходимо использовать DISTINCT для того, чтобы в подзапросе получать одиночное значение.

5. Преподаватели могут вести занятия по разным дисциплинам. Написать запрос, выводящий дисциплины, которые ведет преподаватель Иванова.

SELECT * FROM PREDMET;

WHERE TNUM=(SELECT DISTINCT TNUM FROM TEACHER;

WHERE TFAM=’Иванова’)

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

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

SELECT * FROM USP;

WHERE OCENKA > (SELECT AVG(OCENKA) FROM USP);

Индекс – это указатель на данные в таблице.

Форма оператора:

CREATE INDEX имя_индекса

ON имя_таблицы

Типы индексов

Простой индекс -

индекс, создаваемый по данным одного столбца таблицы

Формат оператора:

CREATE INDEX имя_индекса ON имя_таблицы (имя_столбца)

Уникальный индекс -

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

Формат оператора:

CREATE UNIQUE INDEX имя_индекса ON имя_таблицы (имя_столбца)

Составной индекс -

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

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

Формат оператора:

CREATE INDEX имя_индекса ON имя_таблицы (имя_столбца1, имя_столбца2)

Эффективность использования индексов

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

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

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

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

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

Пример. Вывести все оценки по дисциплине со значениями выше средней по этой же дисциплине.

CREATE VIEW AVGOC AS ;

SELECT * FROM USP FIRST ;

WHERE OCENKA > (SELECT AVG (OCENKA) ;

FROM USP SECOND ;

WHERE SECOND. PNUM=FIRST. PNUM)

19. SQL. Операции изменения, обновления

Изменение существующих данных

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

Дополнение базы INSERT INTO

INSERT INTO <имя файла>[(<поле1>[,<поле2>[,…]])]

VALUES (<выражение1>[,<выражение2>[,…]])

Добавление записей в конец существующего файла, используя <выражения>, перечисленные

после слова VALUES.

Если опущены имена полей, <выражения> будут записываться в последовательные поля базы данных в соответствии с ее структурой.

Другая форма этой команды:

INSERT INTO <имя> FROM ARRAY <имя>

Команда переносит данные, содержащиеся в указанном <массиве>.

20. SQL. Использование псевдонимов

См. 17 вопрос.

21. SQL. Использование UNION

Использование оператора UNION для объединения результатов инструкций SELECT

UNION объединяет информацию из 2-х и более отдельных запросов SELECT в один курсор или табл. При этом в команде SELECT можно использовать до 10 членов UNION, связывая каждую инструкцию SELECT с предыдущей. Результирующий набор, созданный первой командой SELECT, определяет требуемую структуру для остальных команд SELECT. Порядок, количество, размер и тип полей в первой команде SELECT определяет структуру для всех последующих команд SELECT.

Например, для получения списка всех студентов и преподавателей, фамилии которых заключены между буквами «К» и «С»:

SELECT SFAM, SIMIA FROM STUD; WHERE SFAM BETWEEN ‘K’ AND ‘C’; UNION; SELECT TFAM, TIMIA FROM TEACHER; WHERE TFAM BETWEEN ‘K’ AND ‘C’

Когда 2 или более запросов подвергаются объединению, их столбцы вывода должны быть совместимы для объединения. Это означает для каждого запроса необходимость включения одинакового числа столбцов в том же порядке, что и 1, 2, 3 и т. д. и при этом должна присутствовать совместимость типов.

Например: символьные поля должны иметь одинаковое число символов. Кроме того, нельзя использовать агрегатные функции в запросе SELECT при объединении. Агрегатные функции – MIN, MAX, AVG, SUM. Также UNION будет автоматически исключать дубликаты строк из вывода.

Пусть таблица STUD1 содержит поле, состоящее из 30 символов, которые включают Имя и Фамилию.

Таблица TEACHER содержит отдельные поля для имени и фамилии. Сумма длин этих полей также равна 30 символам.

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

SELECT STUD1.FAC FROM STUD;

UNION;

SELECT PADR (ALLTRIM(TEACHER. FIRSTNAME)+ALLTRIM(TEACHER. LASTNAME), 30);

AS NAME, SPACE (10) AS FAK;

FROM TEACHER

Член SPACE(10) играет роль «заглушки», которая относится к полю, содержащему имя факультета в файле TEACHER. Этот член заполняет поле с именем факультета в объединенные результирующие таблицы пробелами. Без подобной заглушки операция UNION корректно работать не будет. Подобную заглушку можно поставить в любой инструкции SELECT. Можно поместить заглушку в первую команду SELECT, чтобы зарезервировать строку пробелов для поля, которое существует только в последующих командах SELECT. Можно включить пробелы в одну из внутренних команд SELECT, чтобы обеспечить совпадение с первой командой SELECT.

Функция ALLTRIM удаляет пробелы слева и справа из соответствующего имени учителя.

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

Воздействие ключевого слова UNION аналогично действию DISTINCT. Это значит, что каждая добавленная в результирующий набор запись проверяется на уникальность. Члены UNION используются только для объединения запросов, но никак не влияют на подзапросы.

Правила объединения с помощью UNION:

Любое поле, включенное в первый список полей, должно быть представлено полем или заглушкой в последующих списках полей. Любое поле из последующих списков полей, которое не входит в первый список полей, должно быть представлено заглушкой в первом списке В первом списке не должно быть вычисляемых полей Члены ORDER BY и INTO могут входить в любую инструкцию SELECT, но только 1 раз и применяются ко всему результату. Член ORDER BY должен ссылаться на поля, по их позициям в списке, а не по имени. При отсутствии члена ORDER BY для сортировки используется порядок следования полей в списке. Члены GROUP BY и HAVING могут присутствовать в каждой инструкции SELECT, причем их влияние ограничено только результатами работы данной инструкции SELECT. С помощью членов UNION нельзя объединять результаты подзапросов, то есть члены UNION нельзя применить к инструкциям SELECT, используемым внутри члена WHERE других инструкций SELECT. При построении объединения можно использовать не более 10 членов UNION.

22. Логическая и физическая независимость данных

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

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

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

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

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

23. Основные функции СУБД

Более точно, к числу функций СУБД принято относить следующие:

Непосредственное управление данными во внешней памяти

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

Управление буферами оперативной памяти

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

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

Управление транзакциями

Транзакция - это последовательность операций над БД, рассматриваемых СУБД как единое целое. Либо транзакция успешно выполняется, и СУБД фиксирует (COMMIT) изменения БД, произведенные этой транзакцией, во внешней памяти, либо ни одно из этих изменений никак не отражается на состоянии БД. Понятие транзакции необходимо для поддержания логической целостности БД. Если вспомнить наш пример информационной системы с файлами СОТРУДНИКИ и ОТДЕЛЫ, то единственным способом не нарушить целостность БД при выполнении операции приема на работу нового сотрудника является объединение элементарных операций над файлами СОТРУДНИКИ и ОТДЕЛЫ в одну транзакцию. Таким образом, поддержание механизма транзакций является обязательным условием даже однопользовательских СУБД (если, конечно, такая система заслуживает названия СУБД). Но понятие транзакции гораздо более важно в многопользовательских СУБД.

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

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

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

Журнализация

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

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

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

Во всех случаях придерживаются стратегии "упреждающей" записи в журнал (так называемого протокола Write Ahead Log - WAL). Грубо говоря, эта стратегия заключается в том, что запись об изменении любого объекта БД должна попасть во внешнюю память журнала раньше, чем измененный объект попадет во внешнюю память основной части БД. Известно, что если в СУБД корректно соблюдается протокол WAL, то с помощью журнала можно решить все проблемы восстановления БД после любого сбоя.

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

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

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

Поддержка языков БД

Для работы с базами данных используются специальные языки, в целом называемые языками баз данных. В ранних СУБД поддерживалось несколько специализированных по своим функциям языков. Чаще всего выделялись два языка - язык определения схемы БД (SDL - Schema Definition Language) и язык манипулирования данными (DML - Data Manipulation Language). SDL служил главным образом для определения логической структуры БД, т. е. той структуры БД, какой она представляется пользователям. DML содержал набор операторов манипулирования данными, т. е. операторов, позволяющих заносить данные в БД, удалять, модифицировать или выбирать существующие данные. Мы рассмотрим более подробно языки ранних СУБД в следующей лекции.

В современных СУБД обычно поддерживается единый интегрированный язык, содержащий все необходимые средства для работы с БД, начиная от ее создания, и обеспечивающий базовый пользовательский интерфейс с базами данных. Стандартным языком наиболее распространенных в настоящее время реляционных СУБД является язык SQL (Structured Query Language). В нескольких лекциях этого курса язык SQL будет рассматриваться достаточно подробно, а пока мы перечислим основные функции реляционной СУБД, поддерживаемые на "языковом" уровне (т. е. функции, поддерживаемые при реализации интерфейса SQL).