Представления и их обновление — различия между версиями
Cuciev (обсуждение | вклад) (Inital commit) |
м (rollbackEdits.php mass rollback) |
||
(не показано 19 промежуточных версий 2 участников) | |||
Строка 1: | Строка 1: | ||
{{В разработке}} | {{В разработке}} | ||
+ | |||
+ | = Представления = | ||
+ | {{Определение | ||
+ | |id=def1 | ||
+ | |neat = 1 | ||
+ | |definition='''Представление''' {{---}} механизм, представляющий из себя именованный запрос. В момент каждого обращения к представлению, исполняется соответствующий ему SQL-запрос. При этом, представления могут использоваться как таблицы, на пример, в <code>select ... from</code>. | ||
+ | }} | ||
+ | <br> | ||
+ | Наиболее распространенные случаи применения: | ||
+ | * Макросы {{---}} выделение общей части нескольких запросов; | ||
+ | * Независимость от данных {{---}} использование представлений вместо декомпозированной таблицы для сохранения механизма взаимодействия для чтения со стороны клиента; | ||
+ | * Сокрытие данных; | ||
+ | |||
+ | == Синтаксис == | ||
+ | Объявление представления с именем <code><font color = red>имя</font color = black></code> для представления запроса <code><font color = red>запрос</font color = black></code>: | ||
+ | <font color = blue>create view <font color = red>имя<font color = blue> as <font color = red>запрос<font color = black> | ||
+ | |||
+ | Удаление представления по имени <code><font color = red>имя</font color = black></code>: | ||
+ | <font color = blue>drop view <font color = red>имя<font color = black> | ||
+ | |||
+ | ==== Примеры ==== | ||
+ | Представление для подсчета текущих средних цен в магазинах: | ||
+ | <font color = blue>create view <font color = black>AveragePrice(ShopId, AvgPrice) <font color = blue>as select <font color = black>ShopId, avg(Price) <font color = blue>from <font color = black>Prices<font color = black> | ||
+ | |||
+ | Представление для получения названия магазина с текущими ценами, на каждом из товаров: | ||
+ | <font color = blue>create view <font color = black>ShopItem(SN, PN, P) <font color = blue>as select <font color = black>s.Name, i.Name, p.Price</font> | ||
+ | <font color = blue>from <font color = black>Shops s <font color = blue>natural join <font color = black>Prices p <font color = blue>natural join <font color = black>Items i<font color = black></font> | ||
+ | |||
+ | Данный пример, в частности, демонстрирует удобство использования представлений {{---}} без их использования указанное выше выражение с тремя <code>join</code> пришлось бы писать каждый раз. Также, если бы таблицы <tex>Shops, Prices</tex> и <tex>Items</tex> являлись бы результатом декомпозиции таблицы <tex>ShopItem</tex>, создание данного представления позволяет избежать необходимости изменять код взаимодействия с ней. | ||
+ | |||
+ | == Обновление представлений == | ||
+ | Рассмотрим пример: в результате декомпозиции имевшейся таблицы <tex>T</tex> получились таблицы <tex>T_1</tex> и <tex>T_2</tex>. Было создано представление <tex>T</tex>, объединяющее результаты запроса из двух таблиц в тот вид, в котором данные присутствовали в изначальной. | ||
+ | <br> | ||
+ | Так же существует необходимость использовать не только операции чтения, но и '''записи''', такие, чтобы: | ||
+ | * их результаты отражались <tex>T_1</tex> и <tex>T_2</tex>; | ||
+ | * '''вставка''' была '''взаимообратна удалению'''; | ||
+ | * делать запись как если бы '''представление было таблицей'''; | ||
+ | <br> | ||
+ | Будем рассматривать обновления, как предварительное удаление (без проверки целостности) и последующую вставку обновленных данных. | ||
+ | |||
+ | === Унарные операции === | ||
+ | ==== Фильтрация ==== | ||
+ | Вставка кортежа в результат <tex>R</tex> выполнения операции [[Реляционная алгебра: унарные операции | фильтрации]] <tex>\sigma_{P}(R)</tex> возможна только при выполнении им условия <tex>P</tex> фильтра. В противном случае такая строка не окажется в результате, так как будет отфильтрована: она будет вставлена в базовую таблицу, но не появится в представлении. | ||
+ | |||
+ | Если кортеж удовлетворяет условию, данные можно как вставить, так и удалить. | ||
+ | |||
+ | ==== Проекция ==== | ||
+ | В [[Реляционная алгебра: унарные операции | проекции]] при вставки кортежа имеется набор атрибутов, на который значение проецируется; его необходимо дополнить значениями атрибутов, которые при проекции были отброшены: для этого выбираются значения по умолчанию, с которыми кортеж вставляется. | ||
+ | |||
+ | При удалении данных из проекции, необходимо удалить все соответствующие кортежи из базового отношения: если удалить лишь один из нескольких, в проекции этот кортеж останется. | ||
+ | |||
+ | ==== Переименование ==== | ||
+ | Для выполнения вставки, происходит переименование атрибутов в исходном кортеже, после чего он вставляется. | ||
+ | |||
+ | При удалении соответствующий кортеж удаляется. | ||
+ | |||
+ | === Множественные операции === | ||
+ | ==== Пересечение ==== | ||
+ | Для [[Реляционная алгебра: операции над множествами | пересечения]] <tex>R_1 \cap R_2</tex> вставка кортежа выполняется как в <tex>R_1</tex>, так и в <tex>R_2</tex>. Так как [[Реляционная алгебра: унарные операции | предикатом]] пересечения является конъюнкция предикатов двух отношений, их проверка для кортежа не производится - в противном случае, кортеж не появится в ответе. | ||
+ | |||
+ | Аналогично, для удаления, кортеж должен быть удален из обоих отношений. | ||
+ | |||
+ | ==== Объединение ==== | ||
+ | Отсюда {{---}} алгоритм вставки для [[Реляционная алгебра: операции над множествами | объединения]] <tex>R_1 \cup R_2</tex>: для каждого из отношений проверить соответствие кортежа предикатам каждой из сторон; в случае удовлетворения, вставить в соответствующее отношение. Если кортеж удовлетворяет обоим предикатам, он должен появиться и слева, и справа | ||
+ | |||
+ | При удалении кортеж удаляется как из <tex>R_1</tex>, так и из <tex>R_2</tex>. | ||
+ | |||
+ | ==== Разность ==== | ||
+ | Для [[Реляционная алгебра: операции над множествами | разности]] <tex>R_1 \setminus R_2</tex> вставка производится в <tex>R_1</tex>. | ||
+ | |||
+ | Удаление также производится из <tex>R_1</tex>. | ||
+ | |||
+ | === Соединения === | ||
+ | При вставке кортежа в [[Реляционная алгебра: соединения, деление#.D0.95.D1.81.D1.82.D0.B5.D1.81.D1.82.D0.B2.D0.B5.D0.BD.D0.BD.D0.BE.D0.B5_.D1.81.D0.BE.D0.B5.D0.B4.D0.B8.D0.BD.D0.B5.D0.BD.D0.B8.D0.B5 | естественное соединение]] <tex>R_1 \Join R_2</tex> часть его атрибутов, соответствующих <tex>R_1</tex>, при удовлетворении предикату, вставляются в него, аналогично для <tex>R_2</tex>. | ||
+ | |||
+ | Таким же образом, при удалении, из каждой из частей удаляются соответствующие атрибуты кортежа. | ||
+ | |||
+ | Алгоритмы вставки и удаления базируются на ограничениях целостности: | ||
+ | * один-к-одному: вставка и удаление производятся как для левой, так и для правой части; | ||
+ | * один-ко-многим: кортеж вставляется в часть «многие», а в части «один» соответствующие данные уже могут присутствовать; | ||
+ | * многие-ко-многим: с точки зрения реальных баз данных, данное отношение [[Преобразование модели сущность-связь в физическую модель#.D0.A1.D0.B2.D1.8F.D0.B7.D0.B8_.D0.BC.D0.BD.D0.BE.D0.B3.D0.B8.D0.B5-.D0.BA.D0.BE-.D0.BC.D0.BD.D0.BE.D0.B3.D0.B8.D0.BC_2 | преобразуется]] в join-table, имеющую отношение «один-ко-многим» с обеих из своих сторон; | ||
+ | |||
+ | === Обновления и SQL === | ||
+ | С точки зрения SQL: | ||
+ | * Унарные операции: | ||
+ | ** обновляемые; | ||
+ | * Множественные операции: | ||
+ | ** необновляемые, несмотря на теоретическую возможность для обновления и пересечения и, с определенными ограничениями, для разности; | ||
+ | * Соединения | ||
+ | ** один-к-одному {{---}} обновляемые; | ||
+ | ** один-ко-многим {{---}} обновляемые только со стороны «многие»; | ||
+ | ** многие-ко-многим {{---}} необновляемые (там, где поддерживаются); | ||
+ | |||
+ | == Материализованные представления == | ||
+ | {{Определение | ||
+ | |id=def2 | ||
+ | |definition='''Материализованное представление''' {{---}} в отличие от [[#def1 | представления]], является «слепком» данных на определенный момент времени, который хранящимся физически в виде отдельной таблицы и не изменяется при изменении базовой версии. | ||
+ | }} | ||
+ | Преимущества: | ||
+ | * быстрота выборки: материализованное представление может быть сформировано на основе сложного подзапроса, и, из-за того, что данные будут сохранены, этот запрос не будет пересчитываться повторно; | ||
+ | * возможность «фиксации» данных; | ||
+ | |||
+ | Недостатки: | ||
+ | * для работы с актуальными данными, появляется необходимость обновления материализованное представление; | ||
+ | * физически хранимые данные могут занимать большие объемы памяти; | ||
+ | |||
+ | === Синтаксис === | ||
+ | <font color=blue>create materialized view <font color=red>имя</font> | ||
+ | <font color=red>[</font> | ||
+ | <font color=blue> refresh <font color=red>[{<font color=blue>fast<font color=grey>|<font color=blue>complete<font color=red>}] [<font color=blue>on <font color=red>{<font color=blue>commit<font color=grey>|<font color=blue>demand<font color=red>}]</font> | ||
+ | <font color=red> [<font color=blue>start with <font color=red>время] [<font color=blue>next <font color=red>время]</font> | ||
+ | <font color=red>]</font> | ||
+ | <font color=blue>as <font color=red>запрос<font color = black> | ||
+ | |||
+ | Некоторые БД поддерживают указание времени первого и последующих обновлений: | ||
+ | <font color=red>[<font color=blue>start with <font color=red>время] [<font color=blue>next <font color=red>время]<font color=black> | ||
+ | |||
+ | Режимы обновления: | ||
+ | * <code>fast</code>: инкрементальные обновления в зависимости того, какие фрагменты данных были изменены в базовых таблицах этого отношения. Не рекомендуется использовать в условиях частого обновления исходной таблицы, для некоторых запросов данный режим может не поддерживаться; | ||
+ | * <code>complete</code>: полный пересчет; | ||
+ | |||
+ | Частота обновлений: | ||
+ | * <code>commit</code>: при завершении любой операции; | ||
+ | * <code>demand</code>: при вызове команды <code>refresh materialized view</code>; | ||
+ | |||
+ | <font color=blue>refresh materialized view <font color=red>имя<font color = black> | ||
+ | |||
+ | ==== Пример ==== | ||
+ | Материализованное представление для подсчета текущих средних цен в магазинах, обновляемое раз в день: | ||
+ | <font color=blue>create materialized view <font color=black>AveragePrice</font> | ||
+ | <font color=blue>refresh next <font color=black>dateadd(day, now(), 1)</font> | ||
+ | <font color=blue>as select <font color=black>ShopId, avg(Price) <font color=blue>from <font color=black>Prices <font color=blue>group by <font color=black>ShopId<font color=black> | ||
+ | |||
+ | == См. также == | ||
+ | * [[Реляционная алгебра: унарные операции]] | ||
+ | * [[Реляционная алгебра: операции над множествами]] | ||
+ | * [[Реляционная алгебра: соединения, деление]] | ||
+ | * [[Преобразование модели сущность-связь в физическую модель]] | ||
+ | * [[Базы данных]] | ||
+ | |||
+ | == Литература == | ||
+ | # https://www.kgeorgiy.info/courses/dbms/ | ||
+ | # Введение в системы баз данных, 8-е издание.: Пер. с англ. — М.: Издательский дом "Вильяме", 2005. — 1328 с. | ||
+ | # Gulutzan P., Pelzer T.(1999) SQL-99 complete, really. Gilroy,CA:CMP Books | ||
+ | |||
+ | [[Категория: Базы данных]] |
Текущая версия на 19:13, 4 сентября 2022
Содержание
Представления
select ... from
.
Наиболее распространенные случаи применения:
- Макросы — выделение общей части нескольких запросов;
- Независимость от данных — использование представлений вместо декомпозированной таблицы для сохранения механизма взаимодействия для чтения со стороны клиента;
- Сокрытие данных;
Синтаксис
Объявление представления с именем имя
для представления запроса запрос
:
create view имя as запрос
Удаление представления по имени имя
:
drop view имя
Примеры
Представление для подсчета текущих средних цен в магазинах:
create view AveragePrice(ShopId, AvgPrice) as select ShopId, avg(Price) from Prices
Представление для получения названия магазина с текущими ценами, на каждом из товаров:
create view ShopItem(SN, PN, P) as select s.Name, i.Name, p.Price from Shops s natural join Prices p natural join Items i
Данный пример, в частности, демонстрирует удобство использования представлений — без их использования указанное выше выражение с тремя join
пришлось бы писать каждый раз. Также, если бы таблицы и являлись бы результатом декомпозиции таблицы , создание данного представления позволяет избежать необходимости изменять код взаимодействия с ней.
Обновление представлений
Рассмотрим пример: в результате декомпозиции имевшейся таблицы
Так же существует необходимость использовать не только операции чтения, но и записи, такие, чтобы:
- их результаты отражались и ;
- вставка была взаимообратна удалению;
- делать запись как если бы представление было таблицей;
Будем рассматривать обновления, как предварительное удаление (без проверки целостности) и последующую вставку обновленных данных.
Унарные операции
Фильтрация
Вставка кортежа в результат фильтрации возможна только при выполнении им условия фильтра. В противном случае такая строка не окажется в результате, так как будет отфильтрована: она будет вставлена в базовую таблицу, но не появится в представлении.
выполнения операцииЕсли кортеж удовлетворяет условию, данные можно как вставить, так и удалить.
Проекция
В проекции при вставки кортежа имеется набор атрибутов, на который значение проецируется; его необходимо дополнить значениями атрибутов, которые при проекции были отброшены: для этого выбираются значения по умолчанию, с которыми кортеж вставляется.
При удалении данных из проекции, необходимо удалить все соответствующие кортежи из базового отношения: если удалить лишь один из нескольких, в проекции этот кортеж останется.
Переименование
Для выполнения вставки, происходит переименование атрибутов в исходном кортеже, после чего он вставляется.
При удалении соответствующий кортеж удаляется.
Множественные операции
Пересечение
Для пересечения вставка кортежа выполняется как в , так и в . Так как предикатом пересечения является конъюнкция предикатов двух отношений, их проверка для кортежа не производится - в противном случае, кортеж не появится в ответе.
Аналогично, для удаления, кортеж должен быть удален из обоих отношений.
Объединение
Отсюда — алгоритм вставки для объединения : для каждого из отношений проверить соответствие кортежа предикатам каждой из сторон; в случае удовлетворения, вставить в соответствующее отношение. Если кортеж удовлетворяет обоим предикатам, он должен появиться и слева, и справа
При удалении кортеж удаляется как из
, так и из .Разность
Для разности вставка производится в .
Удаление также производится из
.Соединения
При вставке кортежа в естественное соединение часть его атрибутов, соответствующих , при удовлетворении предикату, вставляются в него, аналогично для .
Таким же образом, при удалении, из каждой из частей удаляются соответствующие атрибуты кортежа.
Алгоритмы вставки и удаления базируются на ограничениях целостности:
- один-к-одному: вставка и удаление производятся как для левой, так и для правой части;
- один-ко-многим: кортеж вставляется в часть «многие», а в части «один» соответствующие данные уже могут присутствовать;
- многие-ко-многим: с точки зрения реальных баз данных, данное отношение преобразуется в join-table, имеющую отношение «один-ко-многим» с обеих из своих сторон;
Обновления и SQL
С точки зрения SQL:
- Унарные операции:
- обновляемые;
- Множественные операции:
- необновляемые, несмотря на теоретическую возможность для обновления и пересечения и, с определенными ограничениями, для разности;
- Соединения
- один-к-одному — обновляемые;
- один-ко-многим — обновляемые только со стороны «многие»;
- многие-ко-многим — необновляемые (там, где поддерживаются);
Материализованные представления
Определение: |
Материализованное представление — в отличие от представления, является «слепком» данных на определенный момент времени, который хранящимся физически в виде отдельной таблицы и не изменяется при изменении базовой версии. |
Преимущества:
- быстрота выборки: материализованное представление может быть сформировано на основе сложного подзапроса, и, из-за того, что данные будут сохранены, этот запрос не будет пересчитываться повторно;
- возможность «фиксации» данных;
Недостатки:
- для работы с актуальными данными, появляется необходимость обновления материализованное представление;
- физически хранимые данные могут занимать большие объемы памяти;
Синтаксис
create materialized view имя [ refresh [{fast|complete}] [on {commit|demand}] [start with время] [next время] ] as запрос
Некоторые БД поддерживают указание времени первого и последующих обновлений:
[start with время] [next время]
Режимы обновления:
-
fast
: инкрементальные обновления в зависимости того, какие фрагменты данных были изменены в базовых таблицах этого отношения. Не рекомендуется использовать в условиях частого обновления исходной таблицы, для некоторых запросов данный режим может не поддерживаться; -
complete
: полный пересчет;
Частота обновлений:
-
commit
: при завершении любой операции; -
demand
: при вызове командыrefresh materialized view
;
refresh materialized view имя
Пример
Материализованное представление для подсчета текущих средних цен в магазинах, обновляемое раз в день:
create materialized view AveragePrice refresh next dateadd(day, now(), 1) as select ShopId, avg(Price) from Prices group by ShopId
См. также
- Реляционная алгебра: унарные операции
- Реляционная алгебра: операции над множествами
- Реляционная алгебра: соединения, деление
- Преобразование модели сущность-связь в физическую модель
- Базы данных
Литература
- https://www.kgeorgiy.info/courses/dbms/
- Введение в системы баз данных, 8-е издание.: Пер. с англ. — М.: Издательский дом "Вильяме", 2005. — 1328 с.
- Gulutzan P., Pelzer T.(1999) SQL-99 complete, really. Gilroy,CA:CMP Books