Modyfikacja widoku

Modyfikacja widoku poleceniem ALTER VIEW zmienia definiujące go zapytanie bez usuwania obiektu.

Modyfikacja widoku w bazie danych

Modyfikacja widoku to operacja polegająca na zmianie definicji obiektu, który przedstawia dane na podstawie zapytania SQL. Widok nie przechowuje zazwyczaj własnej, niezależnej kopii rekordów, lecz działa jak nazwane zapytanie zapisane w strukturze bazy danych. Po odwołaniu się do jego nazwy system odczytuje aktualną definicję i wykorzystuje ją do pobrania lub przekształcenia danych. Dzięki temu można zmienić zakres kolumn, sposób filtrowania, połączenia między tabelami albo reguły prezentowania wyników bez konieczności usuwania samego widoku i tworzenia go od początku.

Najczęściej stosuje się do tego polecenie ALTER VIEW. Jego dokładna składnia zależy od używanego systemu zarządzania bazą danych, ponieważ poszczególne silniki różnią się możliwościami i ograniczeniami. W wielu środowiskach definicja widoku może zostać zastąpiona nowym zapytaniem, ale nazwa obiektu, uprawnienia oraz odwołania z innych zapytań pozostają zachowane. Ma to znaczenie w aplikacjach, raportach i procedurach, które korzystają z ustalonej nazwy widoku.

Przykładowo widok może początkowo prezentować identyfikator, nazwę oraz status zamówienia. W wyniku modyfikacji można dodać datę utworzenia, ograniczyć wyniki do aktywnych rekordów lub połączyć dane z tabelą klientów. Z punktu widzenia użytkownika aplikacji nadal używana jest ta sama nazwa widoku, jednak zwracany zestaw danych może zostać rozszerzony albo uporządkowany w inny sposób. Taka właściwość ułatwia rozwój schematu bazy, ale wymaga sprawdzenia, czy zmieniona struktura wyników nie wpłynie na kod aplikacji.

Modyfikacja widoku a tabela i zapytanie zapisane

Widok można porównać do warstwy pośredniej między tabelami a zapytaniami wykonywanymi przez użytkowników. Tabela przechowuje dane, natomiast widok opisuje sposób ich odczytu. Zwykłe zapytanie jednorazowe istnieje tylko w kodzie wykonującego je polecenia, a widok otrzymuje własną nazwę i może być wykorzystywany wielokrotnie przez różne moduły. Modyfikacja definicji widoku zmienia więc wspólny punkt dostępu do danych, podczas gdy korekta pojedynczego zapytania oddziałuje tylko na konkretny fragment kodu.

Warto odróżnić zmianę widoku od zmiany danych. Operacja ALTER VIEW nie służy do aktualizowania rekordów w tabelach. Nie zmienia wartości przechowywanych w kolumnach, nie dopisuje nowych wierszy i nie usuwa istniejących informacji. Zmianie podlega opis sposobu odczytu. Jeśli definicja zostanie rozszerzona o dodatkowy warunek WHERE, dane nadal pozostają w tabeli, lecz nie będą widoczne przez ten konkretny widok.

Istotna jest również różnica między modyfikacją widoku a jego usunięciem i ponownym utworzeniem. Ponowne tworzenie może spowodować konieczność odtworzenia uprawnień, zależności, komentarzy lub dodatkowych ustawień. Zmiana definicji w ramach dostępnej operacji modyfikacyjnej zwykle lepiej zachowuje tożsamość obiektu. Nie oznacza to jednak, że każda zmiana jest bezpieczna automatycznie. Jeżeli inne obiekty oczekują określonych nazw kolumn albo typów danych, modyfikacja może wywołać błędy w raportach i aplikacjach.

W niektórych systemach wymagane jest użycie pełnej definicji widoku, a nie tylko fragmentu zapytania, który ma zostać zmieniony. Oznacza to konieczność ponownego zapisania klauzul SELECT, FROM, JOIN, WHERE, a czasem także GROUP BY, HAVING lub ORDER BY. Przed wykonaniem operacji powinno się sprawdzić dokumentację konkretnego silnika oraz aktualną definicję obiektu.

Typowe problemy przy modyfikacji widoku

Jednym z częstych problemów jest próba zmiany widoku w sposób, który narusza jego zależności. Jeżeli definicja odwołuje się do nieistniejącej kolumny, zmienionej tabeli albo funkcji niedostępnej w danym środowisku, operacja może zostać odrzucona. W innych przypadkach sama modyfikacja zostanie przyjęta, ale błąd pojawi się dopiero przy odczycie danych. Z tego powodu warto wcześniej zweryfikować zapytanie jako niezależny SELECT, a dopiero potem zapisać je jako nową definicję widoku.

Ryzyko występuje także przy zmianie nazw kolumn. Aplikacja może odwoływać się do nich po nazwie, nawet jeśli użytkownik widzi tylko końcowy raport. Usunięcie kolumny, zmiana jej aliasu albo zastąpienie wyrażenia innym typem wyniku może spowodować niezgodność z kodem. Bezpieczniejszym podejściem jest utrzymanie dotychczasowych nazw tam, gdzie są już używane, oraz dodawanie nowych elementów w sposób zgodny z oczekiwaniami odbiorców.

Problematyczne bywają również widoki z agregacją. Dodanie pola do listy SELECT może wymagać uzupełnienia klauzuli GROUP BY. Z kolei zmiana warunku filtrowania przed agregacją i po agregacji może prowadzić do innych wyników, mimo że zapytanie nadal jest poprawne składniowo. Przy widokach korzystających z wielu połączeń tabel należy zwrócić uwagę na możliwość zwielokrotnienia wierszy. Nowe połączenie może zmienić liczność wyników i wpłynąć na sumy, średnie lub liczbę rekordów.

Osobną kwestią są uprawnienia. To, że użytkownik może odczytać widok, nie zawsze oznacza możliwość jego modyfikowania. Potrzebne mogą być odpowiednie prawa do samego obiektu, schematu albo elementów używanych w nowej definicji. W środowisku wieloosobowym powinno się także ustalić, kto zatwierdza zmianę i w jaki sposób można wrócić do poprzedniej wersji.

Praktyczne wskazówki dla modyfikacji widoku

• Przed zmianą należy odczytać bieżącą definicję widoku i zapisać ją w dokumentacji albo systemie kontroli wersji.
• Nowe zapytanie powinno zostać uruchomione testowo z ograniczonym zakresem danych, aby sprawdzić składnię, nazwy kolumn i oczekiwany rezultat.
• Należy porównać poprzedni i nowy zestaw kolumn, typy danych, możliwość występowania wartości pustych oraz kolejność wyników, jeśli ma znaczenie dla odbiorcy.
• Warto sprawdzić obiekty zależne, takie jak procedury, raporty, zapytania aplikacyjne i inne widoki korzystające z modyfikowanego obiektu.
• Przy zmianach wykonywanych na środowisku roboczym powinno się przygotować plan cofnięcia, obejmujący poprzednią definicję oraz sposób jej ponownego zapisania.
• Jeśli widok jest używany często, należy porównać czas wykonania zapytań przed zmianą i po niej, zwłaszcza gdy dodawane są połączenia, sortowanie albo agregacje.
• Nie powinno się umieszczać w widoku logiki, której działanie nie zostało opisane. Czytelne aliasy i komentarze ułatwiają późniejsze utrzymanie obiektu.

Przykładowy schemat pracy może wyglądać następująco: najpierw identyfikuje się obiekt i jego użytkowników, następnie pobiera aktualną definicję, testuje nową wersję jako zapytanie, porównuje wyniki, wykonuje modyfikację i ponownie sprawdza działanie zależnych elementów. W przypadku większej zmiany przydatne jest przygotowanie kilku zestawów testowych: danych typowych, pustych, niepełnych oraz takich, które występują w relacjach jeden do wielu.

Kiedy zgłosić modyfikację widoku do serwisu

Doświadczone wsparcie techniczne może być potrzebne wtedy, gdy widok przestał zwracać dane, jego definicja uległa uszkodzeniu, aplikacja zgłasza niezgodność kolumn albo po zmianie tabel wyniki stały się niepoprawne. Pomoc bywa również wskazana przy przenoszeniu bazy między środowiskami, porządkowaniu wielu zależności oraz analizie zapytań, których działanie pogorszyło się po rozbudowie struktury. W takiej sytuacji przydatne jest przekazanie informacji o używanym silniku bazy, treści błędu, oczekiwanym wyniku oraz momencie, w którym problem się pojawił.

Warszawskie Pogotowie Komputerowe 24/7 może stanowić punkt kontaktu przy problemach z oprogramowaniem, konfiguracją i działaniem komputera związanym z pracą z bazą danych. Przed rozpoczęciem czynności warto ustalić zakres ingerencji, dostępne kopie zapasowe oraz to, czy modyfikacja ma dotyczyć wyłącznie odczytu danych, czy także współpracy z aplikacją. Takie przygotowanie ogranicza ryzyko przypadkowego naruszenia zależności i ułatwia bezpieczne przywrócenie wcześniejszego działania.

Najważniejsza zasada polega na traktowaniu widoku jako elementu używanego przez inne części systemu. Nawet pozornie mała korekta może zmienić wynik raportu, liczbę zwracanych wierszy lub sposób interpretacji danych. Dlatego każda modyfikacja powinna być poprzedzona analizą zależności, testem nowej definicji i sprawdzeniem działania po zapisaniu zmian.