Widok

Widok to zapisane zapytanie prezentowane jako wirtualna tabela, bez fizycznego przechowywania danych.

Widok jako logiczna tabela

Widok w relacyjnej bazie danych jest nazwanym zapytaniem, które można wykorzystywać podobnie jak tabelę. Nie przechowuje własnych kopii wszystkich wyników, lecz opisuje sposób ich wyznaczenia na podstawie tabel bazowych, innych widoków albo dozwolonych wyrażeń zapytania. Gdy aplikacja lub użytkownik odczytuje widok, silnik bazy danych analizuje jego definicję i pobiera dane zgodnie z zapisanymi warunkami. Wynik zapytania ma strukturę kolumn i wierszy, dlatego może być używany w kolejnych zapytaniach, raportach oraz instrukcjach łączących dane z innych obiektów.

Widok może ograniczać liczbę zwracanych kolumn, filtrować wiersze za pomocą warunku WHERE, łączyć informacje z kilku tabel operatorem JOIN oraz obliczać wartości na podstawie wyrażeń. Przykładowy widok może udostępniać wyłącznie identyfikator klienta, datę zgłoszenia i status naprawy, mimo że tabela źródłowa zawiera także pola techniczne używane wewnętrznie przez aplikację. Definicja widoku jest przechowywana w schemacie bazy, natomiast zwykły wynik jest obliczany podczas odczytu, chyba że konkretna platforma oferuje osobny mechanizm widoku materializowanego.

Definicja, składnia i użycie w zapytaniach

Widok tworzy się instrukcją właściwą dla danego silnika bazy danych, najczęściej w postaci CREATE VIEW nazwa AS SELECT .... Po utworzeniu obiekt otrzymuje nazwę, listę kolumn wynikowych oraz zapytanie definiujące. W wielu systemach można później zmienić definicję za pomocą instrukcji typu ALTER VIEW albo usunąć obiekt poleceniem DROP VIEW. Dokładna składnia, obsługiwane opcje i sposób przechowywania definicji zależą od używanego silnika, dlatego poleceń nie należy przenosić między systemami bez sprawdzenia dokumentacji.

Po utworzeniu widok odczytuje się podobnie jak tabelę, na przykład przez SELECT kolumna1, kolumna2 FROM nazwa_widoku. Można stosować dodatkowe filtrowanie, sortowanie, agregację albo łączenie z innymi obiektami, o ile nie narusza to reguł danego systemu. Widok nie jest jednak całkowicie niezależnym magazynem danych. Zmiana wartości w tabeli bazowej może zmienić wynik tego samego zapytania wykonanego przez widok, a zmiana struktury tabeli źródłowej może spowodować błąd lub niezgodność definicji.

Wydajność widoku zależy przede wszystkim od zapytania, na którym został oparty, rozmiaru tabel, dostępnych indeksów, warunków filtrowania oraz planu wykonania wybranego przez silnik. Sam fakt użycia widoku nie gwarantuje przyspieszenia operacji. Zagnieżdżanie wielu widoków, stosowanie funkcji na kolumnach używanych do filtrowania lub łączenie dużych zbiorów bez odpowiednich warunków może zwiększyć koszt odczytu. W praktyce analizuje się plan wykonania zapytania korzystającego z widoku, a nie tylko krótką definicję samego obiektu.

Modyfikowanie danych przez widok

Niektóre widoki pozwalają nie tylko czytać dane, lecz także wykonywać operacje INSERT, UPDATE lub DELETE. Zależy to od reguł konkretnego silnika i od konstrukcji zapytania. Widok oparty na jednej tabeli, bez agregacji, grupowania, eliminowania duplikatów i części złożonych wyrażeń, ma zwykle większą szansę na obsługę modyfikacji niż widok łączący wiele tabel. Ostateczna możliwość zapisu jest określana przez implementację bazy danych, a nie przez samą obecność słowa „widok”.

Widok zawierający GROUP BY, funkcje agregujące takie jak COUNT lub SUM, operator DISTINCT, połączenia wielu źródeł albo obliczenia może być przeznaczony wyłącznie do odczytu. W niektórych systemach można jednak zdefiniować dodatkowe reguły obsługi modyfikacji, na przykład procedurę wywoływaną zamiast operacji zapisu. Takie rozwiązanie wymaga sprawdzenia zachowania używanego silnika, ponieważ nazwy mechanizmów, ograniczenia i sposób walidacji różnią się między produktami.

Przy zapisie przez widok obowiązują ograniczenia tabel bazowych, w tym typy danych, klucze, więzy integralności i ograniczenia NOT NULL. Jeżeli widok ukrywa kolumnę wymagającą wartości, operacja może zakończyć się błędem. Filtr widoku nie zawsze oznacza, że każda zmiana pozostanie widoczna po jej wykonaniu: zmodyfikowany wiersz może przestać spełniać warunek definiujący widok. Z tego powodu widoki używane do zapisu trzeba testować osobno dla odczytu, aktualizacji, usuwania i wstawiania rekordów.

Uprawnienia, utrzymanie i diagnostyka

Widok może służyć do kontrolowania zakresu danych udostępnianych użytkownikom lub aplikacjom. Administrator nadaje uprawnienia do widoku, a użytkownik korzysta z przygotowanego interfejsu zamiast otrzymywać bezpośredni dostęp do wszystkich tabel. Taki model upraszcza użycie danych i może ograniczyć przypadkowe odczytywanie niepotrzebnych kolumn, ale jego szczegóły zależą od mechanizmu uprawnień oraz sposobu rozwiązywania odwołań przez konkretny silnik. Sama definicja widoku nie zastępuje prawidłowej konfiguracji kont i uprawnień.

Podczas diagnostyki problemu z widokiem należy sprawdzić jego aktualną definicję, zależności od tabel i innych widoków, typy kolumn oraz komunikat zwracany przez silnik. Częstą przyczyną awarii jest zmiana nazwy kolumny, usunięcie tabeli, zmiana typu danych albo dodanie niejednoznacznej nazwy w zapytaniu. Warto również uruchomić zapytanie bazowe niezależnie od widoku i porównać jego wynik z oczekiwanym rezultatem. Jeżeli odczyt jest powolny, pomocne jest sprawdzenie planu wykonania, liczby przetwarzanych wierszy i warunków użycia indeksów.

Widok zwykły należy odróżnić od widoku materializowanego. Widok materializowany przechowuje wcześniej wyliczony rezultat lub jego reprezentację i wymaga odświeżania, aby odzwierciedlać zmiany w źródłach. Może ograniczyć koszt powtarzanych obliczeń, ale wprowadza opóźnienie między zmianą danych a aktualizacją wyniku oraz dodatkowe wymagania dotyczące miejsca na dysku i harmonogramu odświeżania. Przy planowaniu naprawy problemu z widokiem trzeba więc ustalić, czy chodzi o zwykłe zapytanie logiczne, czy o konkretny mechanizm materializacji dostępny w używanym systemie.