Widok a aktualizacja danych

Widok pozwala aktualizować dane leżącej pod nim tabeli tylko przy spełnieniu określonych warunków.

Widok a aktualizacja danych – czym jest zależność między widokiem i tabelą

Widok w bazie danych można traktować jako zapisane zapytanie, które prezentuje wynik pochodzący z jednej tabeli albo z kilku połączonych tabel. Użytkownik pracujący z widokiem często widzi dane w podobnej formie jak w zwykłej tabeli, jednak sposób ich przechowywania i możliwość modyfikacji mogą być zupełnie inne. Widok nie musi zawierać własnych, niezależnych kopii rekordów. Zwykle pokazuje dane pobierane ze źródłowych tabel w chwili wykonania zapytania. Z tego powodu aktualizacja danych przez widok wpływa na tabelę leżącą pod nim tylko wtedy, gdy system bazodanowy potrafi jednoznacznie ustalić, które rekordy i kolumny powinny zostać zmienione.

Najprostszy widok oparty na jednej tabeli, bez grupowania, obliczeń i złożonych połączeń, może zachowywać się podobnie do tabeli podczas operacji UPDATE, INSERT albo DELETE. W takim przypadku każda kolumna widoczna w widoku ma czytelne powiązanie z konkretną kolumną tabeli źródłowej. Gdy zapytanie staje się bardziej rozbudowane, możliwość zapisu może zostać ograniczona. Sam fakt, że dane są widoczne w wyniku zapytania, nie oznacza jeszcze, że można je bezpośrednio edytować.

Przy ocenie widoku należy rozdzielić trzy kwestie: odczyt danych, modyfikację istniejących rekordów oraz dodawanie i usuwanie rekordów. Widok może pozwalać na odczyt i zmianę pewnych kolumn, ale nie przyjmować nowych wierszy. Może także umożliwiać aktualizację tylko wtedy, gdy zmiana nie narusza warunków określonych w definicji. Ograniczenia te wynikają zarówno z budowy zapytania, jak i z reguł konkretnego silnika bazodanowego.

Widok i aktualizacja danych w kontekście zapytań oraz porównań

Najłatwiej zrozumieć działanie widoku przez porównanie kilku typowych konstrukcji. Widok wybierający kolumny z jednej tabeli może być modyfikowalny, ponieważ relacja między wynikiem a źródłem pozostaje prosta. Jeżeli jednak w definicji użyto połączenia tabel, system musi rozstrzygnąć, do którego źródła należy zmieniana wartość. Przy dwóch tabelach połączonych relacją jeden do wielu pojedynczy wiersz wyniku może reprezentować kilka różnych sytuacji biznesowych. Zmiana takiego wiersza bez dodatkowych zasad mogłaby prowadzić do niejednoznaczności.

Jeszcze większe znaczenie mają operacje agregujące. Konstrukcje z GROUP BY, COUNT, SUM, AVG lub MAX pokazują dane podsumowane, a nie pojedyncze rekordy. Wartość wyświetlana jako suma nie jest przechowywana w jednej komórce tabeli źródłowej. Nie istnieje więc prosta odpowiedź na pytanie, który rekord powinien zostać zmieniony po edycji sumy. Z tego powodu taki widok zazwyczaj służy do odczytu, raportowania i kontroli, a aktualizacja danych odbywa się przez osobne instrukcje kierowane do tabel bazowych.

Podobne ograniczenia mogą dotyczyć użycia DISTINCT, podzapytań, funkcji okienkowych, wyrażeń obliczeniowych oraz konstrukcji łączących wiele wyników. Kolumna utworzona jako wynik działania, na przykład połączenie imienia i nazwiska albo przeliczenie wartości, nie zawsze może zostać zapisana z powrotem do tabeli. Zwykle trzeba wskazać osobno kolumny źródłowe i wykonać aktualizację bezpośrednio na nich.

Warto również odróżnić widok logiczny od widoku materializowanego. Widok logiczny wykonuje zapytanie w czasie odczytu, natomiast widok materializowany przechowuje wynik w dodatkowej strukturze i wymaga odświeżania. Aktualizacja tabeli źródłowej nie musi natychmiast zmienić danych widocznych w widoku materializowanym, jeśli nie wykonano odpowiedniego odświeżenia. To porównanie pokazuje, że nazwa widoku nie opisuje jednej, identycznej funkcji we wszystkich bazach danych.

Typowe problemy z widokiem i aktualizacją danych

Jednym z częstszych problemów jest próba zmiany kolumny, która nie pochodzi bezpośrednio z tabeli. Komunikat o braku możliwości aktualizacji może pojawić się wtedy, gdy wskazana wartość została wyliczona, złożona z kilku pól albo pobrana z tabeli dołączonej przez skomplikowane połączenie. W takiej sytuacji należy sprawdzić definicję widoku i ustalić, które kolumny są rzeczywiście zapisywalne.

Drugim problemem jest filtr zawarty w klauzuli WHERE. Widok może pokazywać wyłącznie rekordy spełniające określony warunek. Jeżeli zmiana wartości spowoduje, że rekord przestanie spełniać ten warunek, po zapisaniu może zniknąć z aktualnego wyniku. Nie oznacza to koniecznie, że aktualizacja danych się nie udała. Rekord mógł zostać poprawnie zmieniony w tabeli, lecz przestał być widoczny przez dany widok.

Ważną rolę odgrywa także ograniczenie kontroli warunku. W niektórych bazach można zdefiniować widok tak, aby zmieniany rekord nadal musiał spełniać warunki jego zapytania. Bez takiej kontroli możliwe byłoby wprowadzenie wartości, po którym rekord zniknąłby z widoku i stał się trudniejszy do znalezienia w codziennej pracy. Przy projektowaniu reguł trzeba zdecydować, czy widok ma jedynie filtrować odczyt, czy również pilnować zakresu dopuszczalnych modyfikacji.

Kolejną przyczyną błędów są uprawnienia. Użytkownik może mieć prawo do odczytu widoku, ale nie mieć prawa do zmiany tabeli źródłowej. Może też mieć uprawnienie do aktualizacji tylko wybranych kolumn. Warto sprawdzać uprawnienia zarówno do samego widoku, jak i do obiektów, z których widok korzysta. Niekiedy sposób sprawdzania uprawnień zależy od konfiguracji bazy, właściciela obiektu oraz użytego mechanizmu bezpieczeństwa.

Nie należy pomijać kluczy głównych, ograniczeń integralności i relacji między tabelami. Aktualizacja danych przez widok może zostać odrzucona, gdy nowa wartość łamie unikalność, narusza relację z inną tabelą albo nie spełnia warunku typu NOT NULL. Jeżeli widok ukrywa część wymaganych kolumn, dodanie nowego rekordu może być niemożliwe, nawet gdy odczyt i modyfikacja istniejących wierszy działają prawidłowo.

Praktyczne wskazówki dla widoku oraz aktualizacji danych

Przed wykonaniem zmiany warto rozpocząć od odczytu definicji widoku i ustalenia jego źródła. Należy sprawdzić, czy każda modyfikowana kolumna wskazuje bezpośrednio na jedno pole tabeli, czy jest wynikiem obliczenia. Przydatne jest również wykonanie zapytania testowego z ograniczonym zestawem rekordów, aby potwierdzić, że filtr widoku obejmuje właściwe dane.

Aktualizację danych powinno się wykonywać w transakcji, zwłaszcza gdy zmiana dotyczy większej liczby rekordów albo kilku powiązanych tabel. Przed zatwierdzeniem można sprawdzić liczbę zmienionych wierszy oraz ponownie odczytać wynik widoku. Jeżeli liczba rekordów różni się od oczekiwanej, transakcję można wycofać i przeanalizować warunek. Takie postępowanie ogranicza ryzyko modyfikacji niewłaściwych danych.

Warto unikać aktualizacji bez precyzyjnego warunku WHERE. Dotyczy to zarówno pracy bezpośrednio na tabeli, jak i zapisu wykonywanego przez widok. Warunek powinien opierać się na stabilnym identyfikatorze albo na zestawie wartości jednoznacznie wskazującym rekord. Sam filtr użyty w widoku nie zawsze wystarcza, ponieważ może obejmować wiele wierszy.

Jeżeli widok ma służyć do edycji, jego definicja powinna być możliwie prosta i czytelna. Pomaga ograniczenie liczby tabel, unikanie zbędnych kolumn obliczeniowych oraz jasne opisanie reguł zapisu. Gdy wymagany jest bardziej złożony interfejs, można zastosować procedurę, funkcję lub wyzwalacz, który określi sposób rozdzielenia zmian na właściwe tabele. Takie rozwiązanie pozwala zachować wygodny widok dla użytkownika, a jednocześnie jawnie kontrolować aktualizację danych.

Przydatne jest także dokumentowanie tego, które kolumny można zmieniać, jakie warunki muszą zostać zachowane oraz co dzieje się z rekordem po zmianie wartości użytej w filtrze. W środowisku testowym należy sprawdzić przypadki brzegowe: zmianę wartości na pustą, próbę dodania duplikatu, modyfikację rekordu powiązanego z inną tabelą oraz zmianę powodującą wypadnięcie rekordu z wyniku.

Kiedy widok i aktualizacja danych wymagają zgłoszenia do serwisu

Do serwisu warto zgłosić się wtedy, gdy problem z widokiem i aktualizacją danych pojawia się razem z objawami wskazującymi na usterkę komputera, nośnika danych albo środowiska pracy. Należą do nich samoczynne zamykanie programu bazodanowego, zawieszanie systemu podczas zapisu, problemy z odczytem plików, błędy urządzenia magazynującego dane oraz niestabilne działanie po aktualizacji oprogramowania. W takich przypadkach sama analiza zapytania może nie wystarczyć, ponieważ przyczyna może leżeć poza definicją widoku.

Przed przekazaniem urządzenia dobrze jest przygotować opis czynności, po których pojawia się błąd, nazwę używanej aplikacji bazodanowej oraz informację, czy problem dotyczy jednego widoku, czy wszystkich operacji zapisu. Nie powinno się przekazywać niepotrzebnych kopii danych zawierających informacje poufne. Jeżeli to możliwe, należy wykonać kopię zapasową i zachować komunikat błędu w niezmienionej postaci.

W Warszawskim Pogotowiu Komputerowym 24/7 można zgłosić urządzenie do oceny problemów związanych z działaniem komputera, oprogramowania i zapisem danych. Przed rozpoczęciem prac warto opisać oczekiwany rezultat, wskazać, czy potrzebna jest jedynie diagnostyka, czy również pomoc w przygotowaniu bezpiecznego środowiska do dalszej pracy z bazą. Takie informacje ułatwiają rozdzielenie problemu z samą definicją widoku od problemu technicznego komputera.