4.4.4 Комбинированные запросы

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

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

Стандартом установлены следующие обозначения для операций:

Union [all]-объединение запросов

Intersect [all] –пересечение запросов

eCxept (Minus в Oracle) [all] – разность запросов

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

select name_st from students1

union all //всех однофамильцев, не удаляет дубликаты

select name_st from students2

//если нет all удалит всех однофамильцев!!

select name_st from students1

Intersect //выводит только однофамильцев

select name_st from students2

select name_st from students1

Minus //все students1 если ни один не входит в students2

select name_st from students2

4.5 Представления (view)

4.5.1 Понятие представления

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

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

Рис.4.2 Порядок обработки SQL-запроса SELECT ….

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

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

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

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

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

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

Использование представлений имеет глубокий смысл, который формулируется в правиле №7 Кодда для реляционных баз данных:

«База данных должна быть доступна конечным пользователям только через представления»

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

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

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