Просмотр (SQL)

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

Представления могут иметь преимущества перед таблицами:

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

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

Точно так же, как строки в базовой таблице не имеют определенного порядка, строки, доступные через представление, не отображаются с какой-либо сортировкой по умолчанию. Представление — это реляционная таблица, а реляционная модель определяет таблицу как набор строк. Поскольку множества не упорядочены (по определению), то и строки представления не упорядочены. Следовательно, предложение ORDER BY в определении представления бессмысленно; стандарт SQL ( SQL:2003 ) не допускает использование предложения ORDER BY в подзапросе команды CREATE VIEW, так же как оно запрещено в операторе CREATE TABLE. Однако отсортированные данные можно получить из представления так же, как и из любой другой таблицы — как часть оператора запроса к этому представлению. Тем не менее, некоторые СУБД (например, Oracle Database ) не соблюдают это ограничение стандарта SQL.

Представления только для чтения и обновляемые представления

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

Некоторые системы поддерживают определение триггеров INSTEAD OF в представлениях. Этот метод позволяет определять другую логику для выполнения вместо операций вставки, обновления или удаления в представлениях. Таким образом, системы баз данных могут реализовывать модификации данных на основе представлений, доступных только для чтения. Однако триггер INSTEAD OF не меняет свойство «только для чтения» или «обновляемое» самого представления.

Материализованные представления

Дополнительная информация: Материализованный вид.

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

Материализованные представления были представлены Oracle Database , а IBM Db2 предоставляет для той же цели так называемые «материализованные таблицы запросов» (MQT). Microsoft SQL Server представил в своей версии 2000 индексированные представления, которые хранят только отдельный индекс таблицы, но не все данные. PostgreSQL реализовал материализованные представления в своей версии 9.3.

Эквивалентность

Представление эквивалентно исходному запросу. Когда запросы выполняются к представлениям, запрос изменяется. Например, если существует представление с именем account_view со следующим содержимым:

-- accounts_view:
-------------
SELECT name,
       money_received,
       money_sent,
       (money_received - money_sent) AS balance,
       address,
	   ...
  FROM table_customers c 
  JOIN accounts_table a 
    ON a.customer_id = c.customer_id

тогда приложение может выполнить простой запрос, например:

-- Simple query
------------
SELECT name,
       balance
  FROM accounts_view

следующее Затем СУБД принимает простой запрос, заменяет эквивалентное представление, а затем отправляет оптимизатору запросов :

-- Preprocessed query:
------------------
SELECT name,
       balance
  FROM (SELECT name,
               money_received,
               money_sent,
               (money_received - money_sent) AS balance,
               address,
			    ...
          FROM table_customers c JOIN accounts_table a
               ON a.customer_id = c.customer_id        )

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

См. также

• Двунаправленность