Widok zdefiniowany przez użytkownika

Widok zdefiniowany przez użytkownika to obiekt utworzony poleceniem CREATE VIEW, w odróżnieniu od widoków systemowych.

Widok jako nazwany wynik zapytania

Widok zdefiniowany przez użytkownika jest obiektem bazy danych opisującym zapytanie zapisane pod własną nazwą. Jego utworzenie zwykle odbywa się za pomocą instrukcji CREATE VIEW, po której podaje się nazwę widoku oraz zapytanie, najczęściej rozpoczynające się od SELECT. Przykładowa definicja może mieć postać CREATE VIEW aktywne_zamowienia AS SELECT id, klient_id, status FROM zamowienia WHERE status = 'aktywne';. Sam widok nie jest w tym przypadku kolejną tabelą zawierającą niezależne kopie wszystkich wyników.

Po odwołaniu do widoku silnik bazy danych wykorzystuje zapisaną definicję jako element zapytania wykonywanego na tabelach źródłowych. Widok może wybierać określone kolumny, ograniczać wiersze przez WHERE, łączyć tabele za pomocą JOIN, a także stosować agregacje, takie jak COUNT lub SUM, o ile pozwala na to używany silnik i konstrukcja zapytania. Dzięki nazwie obiektu złożona logika odczytu może być używana wielokrotnie bez kopiowania całej instrukcji do każdego programu lub raportu.

Różnica między widokiem użytkownika a widokiem systemowym

Widok zdefiniowany przez użytkownika powstaje na podstawie decyzji administratora, programisty albo innego uprawnionego użytkownika bazy. Jego nazwa, lista kolumn i zapytanie wynikają z potrzeb konkretnej aplikacji, raportu lub procesu analitycznego. Może przedstawiać dane biznesowe, techniczne albo pochodzące z kilku tabel, zależnie od celu, dla którego został zaprojektowany.

Widok systemowy jest natomiast dostarczany przez silnik bazy danych i służy do prezentowania informacji o samej bazie lub jej środowisku działania. Może udostępniać metadane dotyczące tabel, kolumn, indeksów, uprawnień, sesji albo innych obiektów, lecz jego dokładna nazwa, zakres i sposób użycia zależą od konkretnego systemu zarządzania bazą danych. Nie należy utożsamiać widoku systemowego z widokiem utworzonym poleceniem CREATE VIEW w schemacie aplikacji, nawet jeśli oba obiekty są odczytywane podobną składnią SELECT.

Aktualność danych, wydajność i ograniczenia zapisu

W typowym widoku logicznym dane są pobierane z tabel źródłowych podczas wykonywania zapytania. Jeżeli w tabelach zmienią się wiersze spełniające warunek widoku, kolejne odczytanie widoku może zwrócić inny wynik. Z tego powodu widok nie powinien być traktowany jako niezależny magazyn danych ani jako automatycznie utworzony zrzut wyników. Oddzielnym mechanizmem jest widok materializowany, który przechowuje wynik zapytania i wymaga odświeżania; nie należy zakładać, że każda baza obsługuje go tak samo jak zwykły widok.

Wydajność odczytu widoku zależy między innymi od zapytania zapisanej definicji, liczby przetwarzanych wierszy, warunków łączenia tabel oraz indeksów dostępnych dla tabel źródłowych. Widok może uprościć kod aplikacji, ale nie usuwa kosztu wykonania złożonego zapytania. Możliwość wykonywania operacji INSERT, UPDATE lub DELETE przez widok zależy od jego struktury i reguł konkretnego silnika. Prosty widok oparty na jednej tabeli może być modyfikowalny, natomiast agregacje, DISTINCT, niektóre złączenia i wyrażenia obliczeniowe często ograniczają albo wykluczają bezpośredni zapis.

Projektowanie widoku i kontrola dostępu

Przy projektowaniu widoku należy jasno określić jego przeznaczenie, nazwy kolumn oraz zakres zwracanych danych. Warto unikać niepotrzebnego używania SELECT *, ponieważ dodanie lub usunięcie kolumny w tabeli źródłowej może zmienić strukturę wyniku albo wpłynąć na kod korzystający z widoku. Stabilniejszym rozwiązaniem jest wymienienie potrzebnych kolumn jawnie. Należy także sprawdzić zachowanie widoku po zmianach schematu, zmianach typów danych i modyfikacji tabel wykorzystywanych w zapytaniu.

Widok może pełnić funkcję warstwy pośredniej między tabelami a aplikacją. Uprawnienia można nadać do odczytu widoku, ograniczając bezpośredni dostęp do wybranych tabel, jednak rzeczywisty model bezpieczeństwa zależy od reguł konkretnego silnika, właścicieli obiektów i sposobu sprawdzania uprawnień. Sama nazwa widoku nie gwarantuje ochrony danych. Przed wdrożeniem trzeba zweryfikować, jakie kolumny i wiersze są dostępne, jakie role mogą wykonywać zapytania oraz czy definicja nie ujawnia informacji, które powinny pozostać poza zakresem danego użytkownika.