#213 Częć III Zarzšdzanie bazš danych #215 Rozdział 10. Widoki Podczas użytkowania bazy danych często zachodzi koniecznoć wielokrotnego korzystania z tych samych zapytań. Widok pozwala zapisać kryteria tworzšce okrelone zapytanie, a następnie odwoływać się do tego zapytania w dowolnej chwili, bez koniecznoci ponownego wpisywania całej instrukcji. Widoki sš tak naprawdę wirtualnymi tabelami, które traktujš dane generowane przez zapytanie SELECT, tak jakby była to faktycznie tabela bazy danych. W standardzie ANSI SQL widoki okrelane sš mianem tabel widokowych (ang. viewed tables), natomiast prawdziwe tabele, stanowišce podstawę do tworzenia widoków, noszš miano tabel bazowych (ang. base tables). Tabele widokowe (lub widoki) umożliwiajš zmianę sposobu prezentowania danych w zależnoci od użytkownika, a także zapamiętywanie często stosowanych zapytań, dzięki czemu nie trzeba tworzyć ich od nowa za każdym razem, kiedy zachodzi potrzeba ich użycia. Stanowiš one również użytecznš warstwę abstrakcji pomiędzy zawartociš tabeli bazowej, a tym co widzi użytkownik. Najważniejszš rzeczš, jakš należy zrozumieć w odniesieniu do widoków, jest to, iż nie sš one chwilowymi zbiorami danych zwracanymi przez zapytanie, lecz raczej kopiš samego wyrażenia SELECT. Za każdym razem, kiedy odwołujemy się do widoku, uruchamiane jest zwišzane z nim zapytanie, po czym zwracane sš aktualne dane z tabel bazowych. Tworzenie widoków Podczas stosowania widoków można korzystać z operacji relacyjnych, takich jak projekcja, restrykcja i złšczenie, do tworzenia pseudotabel zawierajšcych jedynie dane ograniczone do zbioru najbardziej użytecznego z punktu widzenia użytkownika zadajšcego pytania do bazy danych. Przeanalizujmy wyrażenie SQL z listingu 10.1. #216 ----------------------------- Listing 10.1. Standardowe wyrażenie SELECT SELECT movie_title, director_id FROM Movies MOVIE_TITLE DIRECTOR_ID ----------------------------- Minerał House 1 Prince Kong 10 The Code Warrior 2 Bili Durham 9 Codependence Day 1 The Linux Files 2 SQL Strikes Back 9 The Programmer 1 Hard Code 10 The Rear Windows 1 10 rows selected. ----------------------------- Rezultatem w listingu 10.1 jest zwykła projekcja tabeli Movies. Projekcję takš można zachować do przyszłego użytku - w tym celu zamiast zwykłego zapytania należy stworzyć widok, co demonstruje listing 10.2. ----------------------------- Listing 10.2. Wyrażenie CREATE VIEW CREATE VIEW Movie_Director AS SELECT movie_title, dlrector_id FROM Movies View created. ----------------------------- Po utworzeniu widoku można używać go jako ródła danych w miejsce tabeli - przykład takiej operacji pokazuje listing 10.3. ----------------------------- Listing 10.3. Zapytanie wydobywajšce dane z widoku SELECT * FROM Movie_Director MOVIE_TITLE DIRECTOR_ID ----------------------------- Minerał House 1 Prince Kong 10 The Code Warrior 2 Bili Durham 9 Codependence Day 1 The Linux Files 2 SQL Strikes Back 9 The Programmer 1 Hard Code 10 The Rear Windows 1 10 rows selected. ----------------------------- Najistotniejszš cechš widoków jest to, że nie przechowujš one zbioru danych zwróconego przez wyrażenie SELECT, lecz tworzš swego rodzaju pseudotabelę bazujšcš na wynikach zapytania SELECT zapisanego w danym widoku. #217 Innymi słowy, jeli zmodyfikujemy dane w tabeli stanowišcej ródło widoku, a następnie pobierzemy z niego dane, to otrzymamy wynik z odpowiednio odzwierciedlonymi zmianami. Przykład takiego działania przedstawia listing 10.4. ----------------------------- Listing 10.4. Widoki odzwierciedlajš zmiany -wprowadzane do tabel bazowych UPDATE Movies SET movie_title = 'Vegetable House' WHERE movie_title = 'Mineral House' 1 row updated. SELECT * FROM Movie_Director WHERE movie_title = 'Vegetable House' MOVIE_TITLE DIRECTOR_ID ----------------------------- Vegetable House 1 ----------------------------- Wyniki zapytania z listingu 10.4 odzwierciedlajš zmianę wprowadzonš do tabeli Movies. Przy odpytywaniu widoków następuje zawsze odwołanie do ich tabel bazowych, dzięki czemu zapytanie wydobywa dane aktualne. W niektórych przypadkach istnieje również możliwoć uaktualnienia tabel bazowych poprzez widok (zagadnienie to będzie omawiane w dalszej częci tego rozdziału). Innš istotnš cechš widoków, którš można wywnioskować na podstawie listingu 10.4, jest możliwoć stosowania klauzuli WHERE w wyrażeniach SELECT wykonywanych na widokach. W pierwszej kolejnoci wykonana zostaje klauzula WHERE widoku, w wyniku której generowana jest pewna wirtualna tabela wyników. Na tabeli tej wykonywana jest następnie klauzula WHERE samego zapytania. Korzyci płynšce ze stosowania widoków Kilka korzyci, płynšcych ze stosowania widoków, zostało przedstawionych we wstępie do niniejszego rozdziału. Użytkowanie widoków ma charakter całkowicie dobrowolny - jednak w kilku przypadkach ich zastosowanie może ułatwić realizację okrelonych zadań. Poniższe sekcje opisujš niektóre z zalet zastosowania widoków we własnej bazy danych. Wygoda Największš zaletš, wynikajšcš ze stosowania widoków, jest wygoda. Widoki umożliwiajš prezentowanie danych w sposób najbardziej wygodny dla użytkowników, niezależnie od struktury tabel fizycznych. Użytkownikom o wiele łatwiej wpisać polecenie SELECT * dla widoku zawierajšcego wyłšcznie kolumny najczęciej przez nich używane, niż wypisywać poszczególne nazwy kolumn przy korzystaniu #218 z tabeli bazowej (oczywicie, istnieje również możliwoć wybierania konkretnych kolumn z widoku). Jeżeli w trakcie pracy bazy danych okazuje się, że bardzo często wykonywany jest pewien typ złšczenia lub podzapytania, zapytania tego typu można utrwalić w postaci widoków, które ułatwiš pracę użytkownikom bazy. Ukrywanie efektów normalizacji Zgodnie z tym, o czym mówilimy w rozdziale drugim, zachowanie integralnoci danych podczas operacji uaktualniania, usuwania i wstawiania jest możliwe tylko w przypadku ich znormalizowania. Na ogół wymaga to rozbicia dużych tabel na mniejsze, bazujšc na zależnoci funkcjonalnej. Niestety, po znormalizowaniu danych i rozbiciu ich na kilka tabel, ponowne ich połšczenie wymaga użycia operacji złšczenia w zapytaniu. Używajšc widoków można zapamiętać takie zapytania, dzięki czemu dane w postaci pierwotnej stanš się dostępne bez potrzeby pisania zapytania łšczšcego tabele. Widok sam w sobie zawiera pytanie złšczajšce, natomiast pisane przez użytkowników zapytania operujš na wynikach tego złšczenia. Widoki używajšce złšczeń zostanš omówione w dalszej częci rozdziału - teraz ograniczymy się jedynie do przedstawienia przykładu demonstrujšcego takie rozwišzanie. W wyniku procesu normalizacji informacje zwišzane ze studiami filmowymi znajdujš się w tabeli studios, natomiast dane dotyczšce filmów pozostajš w tabeli Movies. Używajšc widoku można stworzyć wirtualnš tabelę, która zawierać będzie listę filmów z faktycznymi nazwami studiów filmowych, zamiast ich identyfikatorów - listing 10.5. ----------------------------- Listing 10.5. Widok łšczšcy tabele Moyies i Studios CREATE VIEW Movie_With_Studio AS SELECT movie_title, budget, gross, studio_name, studio_city, studio_state FROM Movies, Studios WHERE Movies.studio_id = Studios.studio_id SELECT movie_title, studio_name FROM Movie_With_Studio MOVIE_TITLE STUDIO_NAME ----------------------------- Vegetable House Giant Prince Kong MPM The Code Warrior MPM Bili Durham Delighted Artists Codependence Day Giant The Linux Files MPM SQL Strikes Back Delighted Artists The Programmer Delighted Artists Hard Code FKG The Rear Windows Giant 10 rows selected ----------------------------- #219 Ograniczanie danych dostępnych dla użytkowników W praktyce zdarzajš się sytuacje, kiedy okrelonej grupie użytkowników trzeba udostępnić dane zapisane w okrelonej tabeli, ale bez możliwoci przeglšdania zawartoci tej tabeli w całoci. W naszym przypadku nie chcielibymy na przykład, aby pewni użytkownicy mieli dostęp do kolumn przechowujšcych budżety i dochody filmów. Jeżeli będš oni mieli prawo do przeglšdania tabeli Movies, informacje te będš dla nich dostępne. Tworzšc i udostępniajšc użytkownikom jedynie widok tabeli Movies pozbawiony pól z danymi o budżecie i dochodach, zapobiegamy możliwoci zobaczenia przez nich danych, do których nie majš prawa. Rozwišzanie takie demonstruje listing 10.6. ----------------------------- Listing 10.6. Widok prezentujšcy okrojonš wersję tabeli Movies CREATE VIEW Movies_Minus_Financials AS SELECT movie_id, movie_title, studio_id, release_date, director_id FROM Movies SELECT* FROM Movies_Minus_Financials MOVIE_ID MCWTE_TITLE STUDIO_ID RELEASE_D DIRECTOR_ID ----------------------------- 1 Vegetable House 1 01-JAN-75 1 2 Prince Kong 2 01-MAY-79 10 3 The Code Warrior 2 01-SEP-91 2 4 Bili Durham 3 15-JUL-88 9 5 Codependence Day 1 01-JUL-97 1 6 The Linux Files 1 22-AUG-93 2 7 SQL Strikes Back 2 01-NOY-98 9 8 The Prograiraner 3 17-APR-93 1 9 Hard Code 4 18-APR-95 10 10 The Rear Windows 1 11-JUL-87 1 10 rows selected. ----------------------------- Oczywicie, do tej pory nie mówilimy jeszcze, w jaki sposób okrela się dostęp użytkowników do okrelonych zasobów, takich jak tabele lub widoki. Prawa dostępu do bazy danych kontrolowane sš przez wyrażanie GRANT i REVOKE, które zostanš omówione w rozdziale 11. Model bezpieczeństwa SQL". Tworzenie warstwy abstrakcji Według podstawowych zasad projektowania, istnienie warstwy abstrakcji uznaje się za rzecz wskazanš. Zaimplementowanie jej w systemie umożliwia ukrycie przed użytkownikiem korzystajšcym z danych ich faktycznej struktury. Motor bazy danych (ang. database engine) udostępnia ...
sliwak