10. Część III. Zarządzanie bazą danych - Widoki, IT - różne, Podstawy SQL
[ Pobierz całość w formacie PDF ]
#213Częć IIIZarzšdzanie bazš danych#215Rozdział 10.WidokiPodczas 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ówPodczas 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 SELECTSELECT movie_title, director_idFROM MoviesMOVIE_TITLE DIRECTOR_ID-----------------------------Minerał House 1Prince Kong 10The Code Warrior 2Bili Durham 9Codependence Day 1The Linux Files 2SQL Strikes Back 9The Programmer 1Hard Code 10The Rear Windows 110 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 VIEWCREATE VIEW Movie_DirectorASSELECT movie_title, dlrector_idFROM MoviesView 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 widokuSELECT *FROM Movie_DirectorMOVIE_TITLE DIRECTOR_ID-----------------------------Minerał House 1Prince Kong 10The Code Warrior 2Bili Durham 9Codependence Day 1The Linux Files 2SQL Strikes Back 9The Programmer 1Hard Code 10The Rear Windows 110 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.#217Innymi 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 bazowychUPDATE MoviesSET movie_title = 'Vegetable House'WHERE movie_title = 'Mineral House'1 row updated.SELECT *FROM Movie_DirectorWHERE 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ówKilka 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.WygodaNajwię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#218z 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 normalizacjiZgodnie 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 StudiosCREATE VIEW Movie_With_StudioASSELECT movie_title, budget, gross, studio_name,studio_city, studio_stateFROM Movies, StudiosWHERE Movies.studio_id = Studios.studio_idSELECT movie_title, studio_nameFROM Movie_With_StudioMOVIE_TITLE STUDIO_NAME-----------------------------Vegetable House GiantPrince Kong MPMThe Code Warrior MPMBili Durham Delighted ArtistsCodependence Day GiantThe Linux Files MPMSQL Strikes Back Delighted ArtistsThe Programmer Delighted ArtistsHard Code FKGThe Rear Windows Giant10 rows selected-----------------------------#219Ograniczanie danych dostępnych dla użytkownikówW 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 MoviesCREATE VIEW Movies_Minus_FinancialsASSELECT movie_id, movie_title, studio_id, release_date, director_idFROM MoviesSELECT*FROM Movies_Minus_FinancialsMOVIE_ID MCWTE_TITLE STUDIO_ID RELEASE_D DIRECTOR_ID-----------------------------1 Vegetable House 1 01-JAN-75 12 Prince Kong 2 01-MAY-79 103 The Code Warrior 2 01-SEP-91 24 Bili Durham 3 15-JUL-88 95 Codependence Day 1 01-JUL-97 16 The Linux Files 1 22-AUG-93 27 SQL Strikes Back 2 01-NOY-98 98 The Prograiraner 3 17-APR-93 19 Hard Code 4 18-APR-95 1010 The Rear Windows 1 11-JUL-87 110 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 abstrakcjiWedł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 ...
[ Pobierz całość w formacie PDF ]