Просмотр (SQL)

редактировать

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

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

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

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

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

Содержание

  • 1 Только для чтения и обновляемые представления
  • 2 Материализованные представления
  • 3 Эквивалентность
  • 4 См. Также
  • 5 Внешние ссылки

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

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

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

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

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

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

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

Представление эквивалентно исходному запросу. Когда запросы выполняются для представлений, запрос изменяется. Например, если существует представление с именем accounts_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

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

Простой запрос ------------ ВЫБРАТЬ имя, баланс FROM accounts_view

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

Предварительно обработанный запрос: ------------ ------ ВЫБЕРИТЕ имя, баланс FROM (SELECT name, money_received, money_sent, (money_received - money_sent) AS баланс, адрес,... FROM table_customers c ПРИСОЕДИНЯЙТЕСЬ к таблицам счетов a ON a.customer_id = c.customer_id)

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

См. Также

Внешние ссылки

Последняя правка сделана 2021-06-18 13:12:04
Содержание доступно по лицензии CC BY-SA 3.0 (если не указано иное).
Обратная связь: support@alphapedia.ru
Соглашение
О проекте