Widok zależny od innych widoków

Widok zależny od innych widoków tworzy łańcuch odwołań, wpływający na wydajność i czytelność schematu.

Jak powstaje zależność między widokami

Widok zależny od innych widoków to zapytanie zapisane w bazie danych, którego źródłem nie są wyłącznie tabele, lecz także jeden lub kilka wcześniej zdefiniowanych widoków. Taki obiekt działa jak kolejna warstwa logiczna nad schematem danych. Przykładowo widok aktywni_klienci może wybierać rekordy z tabeli klienci, a widok zamowienia_aktywnych_klientow może korzystać z pierwszego widoku oraz z tabeli zamowienia. Drugi obiekt nie przechowuje zwykle osobnej kopii wyniku, lecz podczas odczytu odwołuje się do definicji zależnego widoku i obiektów znajdujących się niżej w łańcuchu.

Zależności tworzą graf obiektów. Tabela może być źródłem dla widoku podstawowego, ten widok może zasilać następny widok, a kolejny może być używany przez raport lub aplikację. Przepływ powinien być jednokierunkowy: widok wyższego poziomu może korzystać z widoku niższego poziomu, ale nie może powstać cykl, w którym definicja pierwszego widoku pośrednio odwołuje się do samej siebie. W praktyce istotne jest także rozróżnienie zależności bezpośrednich i pośrednich. Zmiana kolumny w tabeli może wpłynąć na wiele widoków, nawet jeśli tylko pierwszy z nich odwołuje się do tej tabeli wprost.

Łańcuch definicji a wykonanie zapytania

Podczas wykonywania zapytania odwołującego się do widoku zależnego silnik bazy danych musi uwzględnić jego definicję, a następnie rozwinąć zależności prowadzące do tabel lub innych obiektów źródłowych. Dokładny sposób optymalizacji zależy od konkretnego silnika i rodzaju widoku, ale sama nazwa widoku nie oznacza automatycznie materializowanego, wcześniej obliczonego wyniku. Zwykły widok jest przede wszystkim zapisanym zapytaniem. Jeżeli jego definicja zawiera filtrowanie, łączenia tabel, sortowanie, agregacje albo kolejne zagnieżdżone widoki, plan wykonania może stać się trudniejszy do analizy.

Największe znaczenie ma treść wszystkich warstw, a nie sama liczba widoków. Widok pośredni ograniczający zbiór kolumn i wierszy może poprawiać czytelność oraz ułatwiać ponowne użycie logiki. Z drugiej strony nieprzemyślany łańcuch może powodować wielokrotne wykonywanie podobnych operacji. Przykładem jest kilka widoków, z których każdy wykonuje szerokie złączenie, a dopiero ostatnia warstwa nakłada filtr ograniczający wynik. W takim przypadku warto sprawdzić plan wykonania i ustalić, czy predykat jest przesuwany do wcześniejszego etapu, czy też duży zbiór danych jest przetwarzany przed odfiltrowaniem rekordów.

Nie należy zakładać, że dodanie indeksu na nazwie widoku rozwiąże problem. W wielu bazach zwykły widok nie ma własnego magazynu danych ani niezależnego indeksu. Analizuje się więc indeksy tabel bazowych, warunki złączeń, selektywność filtrów oraz liczbę odczytywanych kolumn. Jeżeli konkretny silnik obsługuje widoki materializowane lub indeksowane, jest to odrębny mechanizm o własnych ograniczeniach dotyczących odświeżania, modyfikacji danych i obsługiwanych konstrukcji zapytań.

Skutki zmian w schemacie i uprawnieniach

Widok zależny może przestać działać po zmianie struktury obiektu źródłowego. Usunięcie kolumny używanej w klauzuli SELECT, WHERE lub warunku złączenia może spowodować błąd przy odwołaniu do widoku. Szczególnej uwagi wymaga stosowanie SELECT *. Taki zapis wiąże wynik z aktualnym zestawem kolumn i utrudnia kontrolę kontraktu, który widok oferuje aplikacji. Jawne wymienienie kolumn ułatwia wykrycie zmian oraz ogranicza ryzyko nieoczekiwanej modyfikacji struktury wyniku.

Zmiana typu danych, nazwy kolumny, klucza albo relacji między tabelami również może wpłynąć na kolejne warstwy. Widok może formalnie istnieć, ale zwracać inne dane niż wcześniej, jeśli zmieniono warunek filtrowania, sposób łączenia rekordów lub znaczenie wartości w tabeli. Dlatego przed wdrożeniem zmiany trzeba przejrzeć zależności obiektu i sprawdzić wszystkie zapytania, procedury, raporty oraz fragmenty aplikacji korzystające z jego kolumn.

Osobną kwestią są uprawnienia. Użytkownik wykonujący zapytanie do widoku musi mieć możliwość skorzystania z tego obiektu, a reguły zależności uprawnień między widokiem i jego źródłami są zależne od silnika oraz konfiguracji właścicieli obiektów. Błędnie ustawione prawa mogą powodować sytuację, w której definicja jest poprawna, lecz aplikacja otrzymuje odmowę dostępu. Diagnostyka powinna więc obejmować zarówno treść definicji, jak i konto używane przez aplikację, schemat właściciela oraz pełną ścieżkę zależności.

Porządkowanie i diagnozowanie warstw widoków

Przy przeglądzie takiej konstrukcji warto zacząć od zapisania grafu zależności: dla każdego widoku należy wskazać obiekty źródłowe, kolumny wykorzystywane w filtrach i złączeniach oraz obiekty korzystające z wyniku. Następnie można oznaczyć warstwy odpowiedzialne za różne zadania, na przykład filtrowanie danych aktywnych, łączenie encji, agregowanie wyników i przygotowanie formatu dla aplikacji. Jeżeli jedna definicja wykonuje wszystkie te operacje jednocześnie albo pośredni widok jest używany do wielu niepowiązanych celów, utrzymanie schematu staje się trudniejsze.

Podczas diagnostyki należy porównać wynik widoku z wynikiem zapytania bezpośrednio skierowanego do tabel źródłowych. Trzeba sprawdzić liczbę rekordów, wartości kluczy, występowanie duplikatów, wartości NULL oraz działanie filtrów na danych granicznych. Warto również uruchomić plan wykonania dla typowych i dużych zakresów danych, ponieważ zapytanie szybkie dla kilku rekordów może zachowywać się inaczej po wzroście tabel. Każdy widok używany jako interfejs dla programu powinien mieć jasno określony zestaw kolumn, stabilne znaczenie wartości i test sprawdzający zachowanie po zmianie obiektów niższej warstwy.

W serwisowym środowisku komputerowym problem może ujawnić się jako wolne działanie programu, przekroczenie limitu czasu zapytania, brak danych w ekranie raportu albo komunikat o niedostępnej kolumnie. Diagnostyka obejmuje wtedy log aplikacji, treść wykonywanego zapytania, definicje kolejnych widoków, plan wykonania oraz stan tabel bazowych. Warszawskie Pogotowie Komputerowe zajmuje się profesjonalną naprawą laptopów, komputerów PC i podzespołów, a w przypadku problemów programowych analiza powinna prowadzić od objawu w aplikacji do konkretnej zależności w schemacie danych.