Widok zamiast tabeli

Widok zamiast tabeli stosuje się, by ukryć złożoność struktury lub ograniczyć dostęp do danych źródłowych.

Widok jako logiczna warstwa nad tabelami

Widok zamiast tabeli to obiekt logiczny bazy danych, który przechowuje definicję zapytania, a nie niezależny zestaw wierszy. Przy odczycie system wykonuje zapytanie zapisane w definicji widoku i zwraca wynik tak, jakby użytkownik odczytywał tabelę. W typowym widoku można umieścić kolumny pochodzące z jednej lub kilku tabel, zastosować warunek WHERE, połączyć rekordy przez JOIN, obliczyć wartości oraz nadać kolumnom inne nazwy za pomocą aliasów.

Przykładowa definicja może wyglądać następująco: CREATE VIEW aktywne_zgloszenia AS SELECT id, klient_id, status FROM zgloszenia WHERE status = 'aktywne';. Później użytkownik odwołuje się do niej poleceniem SELECT * FROM aktywne_zgloszenia;, bez powtarzania warunku ograniczającego wynik. Widok upraszcza dostęp do złożonej struktury, ponieważ aplikacja może korzystać z ustalonego interfejsu kolumn, nawet gdy dane są fizycznie rozdzielone między wiele tabel.

Ograniczenie zakresu danych przez definicję widoku

Widok może ograniczać liczbę zwracanych kolumn i wierszy. Jeżeli tabela zawiera pola techniczne, pomocnicze albo przeznaczone wyłącznie dla procesów wewnętrznych, definicja widoku może ich nie udostępniać. Podobnie warunek WHERE może zwracać tylko rekordy spełniające określone kryterium, na przykład urządzenia o statusie sprawne albo zamówienia o stanie zrealizowane. Takie ograniczenie działa na poziomie zapytania korzystającego z widoku, ale nie zmienia zawartości tabel źródłowych.

Uprawnienia do widoku są niezależnym elementem kontroli dostępu. W systemach obsługujących uprawnienia obiektowe można przyznać użytkownikowi prawo odczytu widoku, nie przyznając mu bezpośredniego prawa odczytu tabel bazowych. Rzeczywisty zakres ochrony zależy jednak od konkretnego silnika, konfiguracji właścicieli obiektów i sposobu sprawdzania uprawnień. Samo utworzenie widoku nie szyfruje danych, nie usuwa ich z tabeli i nie gwarantuje, że wszystkie zapytania wykonane przez aplikację będą korzystały wyłącznie z tego ograniczonego interfejsu.

Zapytania, modyfikacje i koszty wykonania

Nie każdy widok może być używany do modyfikowania danych. Prosty widok oparty na jednej tabeli, bez agregacji, grupowania, operacji DISTINCT i części złożonych połączeń, może w niektórych silnikach pozwalać na wykonanie INSERT, UPDATE albo DELETE. Widok zawierający GROUP BY, funkcje agregujące, sumy lub wiele relacji często jest tylko do odczytu albo wymaga dodatkowego mechanizmu, takiego jak reguła, wyzwalacz lub specjalna składnia właściwa dla danego produktu. Zasady te nie są identyczne w PostgreSQL, SQL Server, MySQL i Oracle, dlatego przed modyfikacją trzeba sprawdzić dokumentację używanego silnika.

Zwykły widok nie jest automatycznie kopią danych. Jego zapytanie może być optymalizowane razem z zapytaniem nadrzędnym, a koszt wykonania zależy od indeksów, selektywności warunków, liczby łączonych tabel i planu zapytania. Jeżeli wielokrotnie wykonywane zapytanie wymaga zapisania wyniku, stosuje się materializowany widok, o ile dany silnik go obsługuje. Materializowany widok przechowuje wynik fizycznie, ale wymaga odświeżania, ponieważ po zmianie tabel źródłowych może zawierać dane nieaktualne. Nie należy więc traktować zwykłego widoku i materializowanego widoku jako zamiennych obiektów o takim samym zachowaniu.

Sprawdzanie definicji i użycia widoku

Przy analizie problemu należy najpierw ustalić, z jakiego silnika bazy danych pochodzi widok, a następnie odczytać jego dokładną definicję z katalogu systemowego lub narzędzia administracyjnego tego produktu. Warto sprawdzić listę kolumn, typy danych, użyte połączenia, warunki filtrujące oraz zależności od tabel i innych widoków. Trzeba także porównać wynik widoku z tabelami źródłowymi, ponieważ brak rekordu może wynikać z warunku WHERE, połączenia typu INNER JOIN, uprawnień albo opóźnienia odświeżenia materializowanego widoku.

W środowisku laptopa lub komputera PC diagnostyka problemu z aplikacją korzystającą z widoku obejmuje sprawdzenie konfiguracji połączenia, nazwy schematu, konta użytkownika i komunikatu błędu zwróconego przez sterownik bazy danych. Nie należy usuwać widoku ani zmieniać tabel źródłowych bez kopii definicji i ustalenia zależności aplikacji. Bezpieczniejsza kolejność to odczyt definicji, wykonanie kontrolnego zapytania z ograniczeniem liczby rekordów, analiza planu wykonania zgodnie z możliwościami konkretnego silnika oraz dopiero później zaplanowanie zmiany uprawnień, indeksów lub samego zapytania.