• SELECT - запрос на выборку;

• Insert - запрос на добавление;

• UPDATE - запрос на обновление;

• DELETE - запрос на удаление.

Наиболее важной и часто используемой инструкцией является SELECT. Изучению особенностей ее применения будет посвящен следующий раздел.

Инструкция select

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

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

Синтаксис select

Код SELECT - это наиболее сложное и мощное средство SQL. Обобщенный синтаксис этого оператора имеет вид (в квадратных скобках указаны необязательные параметры; символом «|» разде­лены фрагменты команды, из которых выбирается только один):

SELECT selectionjist

FROM table_name [table_alias] [,...n]

[WHERE condition [,...n]]

[GROUP BY groupjist]

[HAVING condition [,...n]]

[ORDER BY sortingjist [ASC | DESC]]

[WITH OWNERACCESS OPTION]; где: selectionjist - список выбора, в котором могут быть указаны выбираемые имена столбцов или выражения;

column alias - псевдоним столбца, отображаемый в результи­рующей таблице;

table name - имя одной либо нескольких таблиц, участвую­щих в операции выборки данных;

table alias - псевдоним таблицы, который можно использо­вать при указании условий выборки;

condition - условие выборки данных, налагающее ограничение на извлекаемые данные;

groupjist - список группировки извлекаемых данных;

HAVING condition - условие, налагаемое на группируемые дан­ные;

sortingjist - список для выполнения сортировки выбранных данных;

WITH OWNERACCESS OPTION - используется при многопользо­вательском доступе к базе данных для предоставления дополни­тельных прав.

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

Расширения инструкции select в access

По сравнению со стандартом SQL3, в Access реализованы следующие расширения синтаксиса инструкции SELECT:

• предложение IN - позволяет указать имена полей перекрест­ного запроса (или установить связь с удаленной БД);

• ключевое слово DISTINCTROW - используется для создания выборки строк с уникальными значениями первичных ключей в таблицах-источниках;

• инструкция TRANSFORM - служит для создания перекрестного запроса;

• инструкция INTO - предназначена для создания новых эле­ментов БД из результатов запроса;

• ключевое слово ТОР - используется для вывода нескольких первых элементов, результатов запроса;

• операция UNION - служит для объединения результатов не­скольких запросов или таблиц.

Порядок выполнения выборки

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

Выполнение оператора SELECT условно подразделяется на не­сколько шагов.

Шаг 1 выполняется на уровне предложения FROM. Вычисляет­ся прямое декартово произведение всех таблиц, указанных в обя­зательном разделе FROM. В результате получается обобщающая таблица ТаЫе_1.

Шаг 2 задается условиями, которые определены в предложе­нии WHERE. Если в операторе SELECT присутствует раздел WHERE, то сканируется таблица ТаЫе_1, полученная при выпол­нении первого шага. При этом для каждой строки из этой табли­цы вычисляется условное выражение, указанное в предложении WHERE. Строка включается в результат, если для нее условное выражение возвращает значение ИСТИНА. Если в условном выра­жении участвуют вложенные подзапросы, то они вычисляются в соответствии с такой же концептуальной схемой. В результате шага 2 получаем таблицу ТаЫе_2. Если предложение WHERE от­сутствует, то осуществляется переход к шагу 3 (принимается, что ТаЫе_1 -> ТаЫе_2 без изменений).

Шаг 3 определяется предложением GROUP BY. Если присутст­вует раздел GROUP BY, то строки таблицы ТаЫе_2, полученной на втором шаге, группируются в соответствии со списком группи­ровки раздела GROUP BY. В результате выполнения третьего шага получаем таблицу ТаЫе_3. Если же данный раздел опущен, то

5-8301

выполняется переход к шагу 4 (принимается, что ТаЫе_2 -> ТаЫе_3 без изменений).

Шаг 4 выполняется на уровне раздела HAVING. Если этот раз­дел присутствует, то группы, не удовлетворяющие заданному в нем условному выражению, исключаются. В результате шага 4 образуется таблица ТаЫе_4. Если раздел HAVING опущен, то идет переход к следующему шагу (принимается, что ТаЫе_3 -> ТаЫе_4 без изменений).

Шаг 5 определяется на уровне оператора SELECT. Каждая груп­па, полученная на четвертом шаге, генерирует одну строку ре­зультата следующим образом. Вычисляются все скалярные вы­ражения, указанные в разделе SELECT, причем они должны быть одинаковыми для всех строк внутри каждой группы. Для каждой группы вычисляются значения агрегатных функций, приведен­ных в разделе SELECT. Если раздел GROUP BY отсутствует, но в SELECT есть агрегатные функции, то считается, что имеется всего одна группа. Если нет ни раздела GROUP BY, ни агрегатных функ­ций, то считается, что имеется столько групп, сколько строк ото­брано к данному моменту.

В результате пятого шага образуется таблица ТаЫе_5, содер­жащая столько столбцов, сколько элементов приведено в списке выбора SELECT, и столько строк, сколько отобрано групп.

Шаг 6 выполняется на уровне раздела ORDER BY. Если в опе­раторе SELECT присутствует этот раздел, то строки таблицы ТаЫе_5, полученной на предыдущих шагах, упорядочиваются в соответствии со списком, приведенным в данном разделе.

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

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

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

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

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

4. Выполнение плана запроса. На этом шаге план, выбранный на предыдущем шаге, передается на реальное выполнение.

Качество конкретной СУБД во многом определяется качест­вом ее оптимизатора. Хороший оптимизатор может повысить скорость выполнения запроса на несколько порядков. Качество оптимизатора определяется тем, какие методы преобразований он может использовать, какой статистической и иной информацией

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