170 Bazy danych. Perspektywy

Transkrypt

1 170 Bazy danych Perspektywy

2 Bazy danych 171 Przegląd zagadnień Podstawowe wiadomosci o perspektywach i ich wlasnosciach Tworzenie i uzytkowanie perspektyw Podsumowanie Pytania sprawdzajace Laboratorium

3 172 Bazy danych Podstawowe wiadomości o perspektywach i ich własnościach Co to jest perspektywa W jakim celu stosujemy perspektywy Rodzaje perspektyw W najprostszym rozumieniu perspektywa (ang. view) jest wirtualną tabelą. Przyjrzyjmy się jednak perspektywom dokładniej. W szerokim znaczeniu perspektywa (zwane teŝ często widokiem) jest odwzorowaniem globalnego schematu bazy danych na schemat "zewnętrzny" przystosowany do potrzeb i przyzwyczajeń konkretnego uŝytkownika. Takie ujęcie perspektywy ilustruje następujący rysunek Rys. 8.1 Schemat funkcjonowania perspektywy

4 Bazy danych 173 W jakim celu stosujemy perspektywy? Generalnie po to, aby uprościć (sobie lub uŝytkownikowi) Ŝycie. Powodów stosowania perspektyw jest wiele: uproszczenie z punktu widzenia uŝytkownika modeli pojęciowych - dzięki temu moŝemy znacznie uprościć schemat bazy, a tym samym ułatwić uŝytkownikowi dostęp do danych, dostosowanie się do punktu widzenia i terminologii dziedziny zastosowań BD - zmiana schematu wprowadzana przez perspektywę moŝe być wykorzystana na przykład do dostosowania nazw tabel i kolumn do języka, którym posługuje się uŝytkownik, ograniczenie dostępu do obiektów - perspektywy powodują ukrycie przez uŝytkownikiem końcowym prawdziwego schematu bazy danych; moŝe to mieć równieŝ pozytywny wpływ na poprawę bezpieczeństwa danych, gdyŝ uŝytkownik nie ma bezpośredniego dostępu do schematu rzeczywistego, współdziałanie systemów heterogenicznych (wspólny schemat) w wypadku systemów rozproszonych, zbudowanych z róŝnych systemów baz danych perspektywa moŝe pomóc w ukryciu róŝnic, przystosowanie starszych systemów do nowszych technologii i wymagań. Z punktu widzenia uŝytkownika (i innych procesów) perspektywa powinna być dla niego przezroczysta, to znaczy, Ŝe moŝna na niej wykonywać takie same operacje jak na "prawdziwych" tabelach. Warunek przezroczystości perspektyw jest bardzo trudny do spełnienia, gdyŝ dla pewnych odwzorowań danych zapamiętanych w wirtualne przyjęte środki definicji perspektyw (np. SQL) mogą okazać się niewystarczające, a takŝe dlatego, Ŝe problem aktualizacji perspektyw pozostaje nierozwiązany. Rys. 8.2 Schemat funkcjonowania perspektywy

5 174 Bazy danych Rodzaje perspektyw Perspektywy dzielimy na dwie grupy: perspektywy wirtualne, perspektywy zmaterializowane. Perspektywy wirtualne Perspektywa wirtualna istnieje wyłącznie w postaci definicji. Wyliczenie (czyli wyznaczenie zbioru krotek danej perspektywy zwane teŝ materializacją perspektywy) następuje w momencie odwołania się do perspektywy. Wynik ten nie jest później nigdzie przechowywany. Oznacza to, Ŝe kaŝde wywołanie perspektywy wirtualnej powoduje jej ponowne wyliczenie (materializację), co obciąŝa zasoby systemu. Wadą perspektyw wirtualnych jest obciąŝanie systemu za kaŝdym odwołaniem do procedury wirtualnej, a tym samym czas (czasem znaczny) oczekiwania na materializację perspektywy. Perspektywy wirtualne mają teŝ szereg zalet. W sytuacji stosowania perspektyw wirtualnych nie ma dublowania danych oraz problemów z aktualizacją danych i problemów z przetwarzaniem transakcji. Procedury zmaterializowane Perspektywa zmaterializowana jest wyliczana (materializowana) w czasie pierwszego uŝycia. Następnie wynik tego wyliczenia (dane) są przechowywane, aby móc ich uŝyć przy ponownym wywołaniu perspektywy. Dzięki temu kolejne wywołanie perspektywy nie obciąŝa systemu, a czas dostępu do danych znacznie się zmniejsza. Niestety perspektywy zmaterializowane niosą ze sobą równieŝ problemy związane przede wszystkim z aktualizacją danych, zwiększeniem zapotrzebowania na miejsce w pamięci i dodatkowe obciąŝenia przy realizacji transakcji. Tworzenie i uŝytkowanie perspektyw

6 Bazy danych 175 Tworzenie perspektyw Modyfikacja danych z pomoca perspektyw Indeksowanie perspektyw

7 176 Bazy danych Metody tworzenia perspektyw Metody tworzenia i zastosowania perspektyw pokaŝemy na przykładzie. ZałóŜmy, Ŝe w bazie danych jest przechowywana następująca tabela: Pracownicy (Id_pracownika, Imię, Nazwisko, Stanowisko, Kierownik, Data_zatrudnienia, Zarobki, Premia, Id_działu) Zbudujemy teraz perspektywę, która będzie zawierała tylko urzędników zatrudnionych w tej firmie, a dodatkowo zrezygnujemy z części nieistotnych dla nas atrybutów (uproszczenie schematu) CREATE VIEW Urzednicy( Id_pracownika, Imię, Nazwisko, Zarobki) AS SELECT Id_pracownika, Imię, Nazwisko, Zarobki FROM Pracownicy WHERE Stanowisko = urzednik Jeśli teraz chcielibyśmy sprawdzić zarobki urzędnika na przykład o nazwisku Nowak, to moŝemy wykorzystać do tego celu zdefiniowaną perspektywę w sposób następujący: SELECT Zarobki FROM Urzednicy WHERE Nazwisko = Nowak Jak widać, odwołanie do perspektywy następuje tutaj tak, jak byśmy odwoływali się do "prawdziwej" tabeli. Co więcej, na samej tylko podstawie instrukcji SELECT nie jesteśmy w stanie określić, czy tabela Urzędnicy, do której się odwołujemy, jest tabelą zapisaną w bazie, czy teŝ jest tabelą wirtualną (perspektywą). Inny przykład definicji perspektywy pokazuje rysunek poniŝej. Rys. 8.3 Definicja prostego widoku

8 Bazy danych 177 Perspektywa moŝe teŝ być definiowana na podstawie innej perspektywy lub kilku tabel. Przykład perspektywy zdefiniowanej na podstawie dwu tabel pokazano na rysunku. Rys. 8.4 Widok stworzony z kilku tabel Podczas przetwarzania perspektywy przez SZBD moŝe wystąpić jedna z niŝej przedstawionych metod. Metoda materializacji perspektywy Metoda materializacji polega na tym, Ŝe w momencie gdy sterowanie programu dotrze do miejsca kodu, w którym występuje odwołanie do definicji perspektywy, następuje jej wyliczenie. KaŜde odwołanie do perspektywy powoduje jej ponowne wyliczenie (w celu uniknięcia sytuacji, w której dane rzeczywiste nie pokrywają się z danymi w perspektywie). Optymalizacja czasu wykonania tą metodą moŝe polegać na wykorzystaniu perspektyw zmaterializowanych. Metoda modyfikacji zapytań W metodzie tej system analizuje tekst całego zapytania przed jego wykonaniem. W czasie analizy w miejsce wywołania perspektywy wstawiana jest jego definicja i ewentualnie wykonywana optymalizacja zapytania. Strategia modyfikacji zapytań daje (choć nie zawsze) lepsze rezultaty niŝ strategia materializacji perspektyw. Strategia modyfikacji jest stosowana przez prawie wszystkie relacyjne SZBD. Wykorzystanie strategii modyfikacji zapytań do optymalizacji zapytania pokazano poniŝej.

9 178 Bazy danych Rys. 8.5 Strategia modyfikacji zapytań Modyfikacja danych za pomocą perspektyw Utworzenie perspektywy (inaczej widoku) nie powoduje utworzenia kopii danych. Widok jest "szablonem", za pomocą którego wyświetlamy dane. Modyfikacja danych widoku polega więc w rzeczywistości na modyfikacji danych w tabelach będących źródłem danych dla widoku. Istnieje kilka ograniczeń co do modyfikacji danych przy uŝyciu widoków: widok uŝywany do modyfikacji danych nie moŝe zawierać funkcji grupujących, jednym poleceniem moŝna modyfikować w widoku tylko kolumny pochodzące z jednej tabeli (lub dodawać dane do jednej tabeli), modyfikowane dane nie mogą być wartościami obliczonymi na podstawie wartości innych kolumn, wstawienie nie moŝe naruszać warunków narzuconych w tabelach źródłowych (dotyczy to takŝe, a moŝe w szczególności, pól tabeli, które nie wchodzą w skład widoku - jeśli mają one ustawione opcję NOT NULL, to przy pomocy widoku nie moŝna do tej tabeli wstawić nowych danych), wstawiane dane muszą być zgodne z warunkiem WITH CHECK OPTION w definicji widoku. W celu modyfikacji danych przedstawianych przez perspektywę wykorzystujemy polecenie UPDATE według schematu: UPDATE <nazwa_perspektywy> SET <nazwa_kolumny> = '<wartość_zmieniana>' WHERE <nazwa_kolumny> = '<nowa_wartość>'

10 Bazy danych 179 Indeksowanie Perspektyw Perspektywa indeksowana to perspektywa, na której zdefiniowano indeks grupowany (jako Ŝe pierwszym indeksem na perspektywie musi być indeks grupowany, zaś następnie moŝemy tworzyć indeksy niegrupowane). W takim przypadku zbiór danych generowany przez widok jest materializowany i przechowywany w najniŝszym poziomie stron naleŝących do indeksu, tak jak to ma miejsce w przypadku indeksu grupowanego zdefiniowanego na tabeli. RównieŜ operacje modyfikacji danych w indeksowanym widoku odbywają się w podobny sposób, jak w tabelach z indeksami (następuje przebudowanie indeksu). Gdy tworzymy indeks na perspektywie, pojęcie wirtualnej tabeli przestaje być aktualne w odniesieniu do perspektywy, poniewaŝ teraz perspektywa jest materialnym zbiorem danych przechowywanym w bazie danych. Widok musi spełniać następujące wymagania, by moŝna było określić na nim indeks grupowany: 1. w trakcie tworzenia perspektywy muszą być włączone opcje ANSI_NULLS i QUOTED_IDENTIFIER, 2. - w trakcie tworzenia tabel bazowych widoku musi być włączona opcja ANSI_NULLS, 3. podczas tworzenia widoku (CREATE VIEW) musi zostać uŝyta opcja SCHEMABINDING, 4. tylko dwie części nazw (właściciel.obiekt - w normalnej sytuacji nazwy mogą mieć więcej członów) mogą zostać uŝyte w definicji widoku do odwoływania się do obiektów bazy danych (tabel lub funkcji uŝytkownika), 5. jeśli uŝywamy funkcji w definicji widoku, to muszą być to funkcje deterministyczne, 6. wszystkie nazwy kolumn muszą być jawnie (i tylko raz) określone w widoku (niedopuszczalny jest symbol gwiazdki), 7. widok nie moŝe zawierać kolumn typów: text, ntext oraz image, 8. widok nie moŝe zawierać danych z tabel zagnieŝdŝanych, funkcji zwracających zestawy rekordów, złączeń typu UNION, złączeń zewnętrznych (OUTER JOIN) oraz złączeń tabeli z samą sobą (ang. self join), 9. polecenie SELECT w definicji widoku nie moŝe zawierać klauzul TOP, ORDER BY, DISTINCT, COMPUTE, COMPUTE BY, HAVING, CUBE oraz ROLLUP, 10. w poleceniu SELECT w definicji funkcje agregujące mogą wystąpić tylko wtedy, gdy uŝyta jest klauzula GROUP BY; nie mogą zostać uŝyte złoŝone funkcje agregujące, czyli: AVG, MIN, MAX, STDEV, STDEVP, VAR oraz VARP, 11. nie moŝna uŝyć funkcji COUNT(*) (ale moŝna COUNT_BIG(*)). Tworzenie indeksu na perspektywie odbywa się tak samo, jak to ma miejsce w przypadku tabel, przykład: CREATE UNIQUE CLUSTERED INDEX high_sales_uci ON High_Sales_View (orderid, customerid, productid)

11 180 Bazy danych Podsumowanie Co to jest perspektywa Jak i gdzie uzywamy perspektywy Jakie sa korzysci z perspektyw Problemy w pracy z widokami Perspektywa jest odwzorowaniem jednego schematu bazy na inny schemat. O perspektywach moŝemy myśleć tak jak o wirtualnych tabelach, które w większości wypadków zachowują się tak samo jak tabele rzeczywiste. Do najwaŝniejszych korzyści wynikających ze stosowania perspektyw naleŝą: ułatwienie uŝytkownikom dostępu do danych, ograniczenie dostępu do danych chronionych, maskowanie złoŝoności bazy danych, uproszczenie złoŝonych zapytań, w tym zapytań rozproszone na heterogenicznych danych, uproszczenie zarządzania uprawnieniami uŝytkowników.

12 Bazy danych 181 Laboratorium Przećwiczmy teraz zdobytą wiedzę. Dokonamy teraz operacji stworzenia perspektywy oraz wyświetlenia i modyfikacji danych za jej pomocą.

13 182 Bazy danych Tworzenie perspektywy υ Zaloguj się do maszyny wirtualnej ZBD jako uŝytkownik Administrator z hasłem P@ssw0rd. υ Kliknij Start. Z grupy programów Microsoft SQL Server 2005 uruchom SQL Server Management Studio. υ W oknie logowania kliknij Connect. υ Kliknij w menu głównym programu Management Studio na File. υ Kliknij Open - File. υ Odszukaj plik C:\Labs\Lab08\mod8.sql i kliknij Open. υ Następnie klikamy przycisk New Query znajdujący się w prawymgórnym roku okna aplikacji. υ W części środkowej pojawiło nam się okno o nazwie nazwa_serwera SQLQuery.sql. W oknie tym będziemy wpisywać wszystkie polecenia języka T-SQL. υ Kolejnym krokiem jest wpisanie i wykonanie (przycisk Execute) następującego kodu: USE Biblioteka CREATE VIEW widok_ksiazki_wydawnictwa AS SELECT Ksiazki.tytul, Ksiazki.rok_wydania, Wydawnictwa.wydawnictwo FROM Ksiazki INNER JOIN Wydawnictwa ON Ksiazki.ID_wydawnictwa = Wydawnictwa.ID_wydawnictwa SELECT * FROM widok_ksiazki_wydawnictwa Wykonanie powyŝszego kodu spowoduje utworzenie w bazie danych Biblioteka widoku o nazwie widok_ksiazki_wydawnictwa, który będzie zawierał dwie kolumny z tabeli Ksiazki (kolumnę tytul oraz kolumnę rok_wydania) oraz jedną kolumnę z tabeli Wydawnictwa (kolumnę wydawnictwo). Polecenie SELECT wyświetla dane w widoku. tytul rok_wydania wydawnictwo SQL Server Vademecum Administratora 2001 MS Press Windows Server Vademecum Administratora 2003 MS Press UML w kropelce 2002 LTP MS Access wersja 2002 dla ekspertów 2003 MS Press XML na powaŝnie 2002 Helion Dokonajmy modyfikacji danych w kolumnie Wydawnictwo tak aby nazwa MS Press została zamieniona na Promise. W tym celu naleŝy: υ υ W Management Studio kliknąć przycisk New Query W znanym nam oknie wpisać i wykonać następujący kod UPDATE widok_ksiazki_wydawnictwa SET wydawnictwo = 'Promise' WHERE wydawnictwo = 'MS Press' SELECT * FROM Wydawnictwa

14 Bazy danych 183 Wynikiem wykonania powyŝszego kodu jest wyświetlenie zawartości tabeli Wydawnictwa. ID_wydawnictwa wydawnictwo Promise 2 LTP 3 Helion Jak widać na pozycji pierwszej w kolumnie wydawnictwo mamy wartość "Promise" zamiast dotychczasowej "MS Press". Czyli tak naprawdę modyfikacji nie ulegają dane w widoku, ale w jednej z tabel wykorzystywanych w definicji widoku. Dodawanie danych za pomocą perspektyw Umiemy juŝ modyfikować dane w naszej bazie za pomocą widoku. Spróbujmy teraz dodać nowe dane. W tym celu w nowym oknie SQLQuery wpisz i wykonaj następujący kod: INSERT INTO widok_ksiazki_wydawnictwa(tytul,rok_wydania,wydawnictwo) VALUES ('SQL Server','2000','Promise') Wynikiem próby wykonania powyŝszego kodu jest błąd mówiący o tym, Ŝe nie moŝemy zmodyfikować danych w widoku, poniewaŝ polecenie usiłuje modyfikować dane w więcej niŝ jednej tabeli bazowej widoku. Aby poradzić sobie z ta niedogodnością stwórzmy nieco zmodyfikowany widok. W nowym oknie SQLQuery wpisz i wykonaj następujący kod: CREATE VIEW widok_ksiazki_wydawnictwa_2 AS SELECT Ksiazki.tytul, Ksiazki.rok_wydania, Ksiazki.ID_wydawnictwa, Wydawnictwa.wydawnictwo FROM Ksiazki INNER JOIN Wydawnictwa ON Ksiazki.ID_wydawnictwa = Wydawnictwa.ID_wydawnictwa SELECT * FROM widok_ksiazki_wydawnictwa_2 Wynikiem wykonania powyŝszego kodu jest utworzenie widoku o nazwie widok_ksiazki_wydawnictwa_2 podobnego do poprzednio utworzonego widoku widok_ksiazki_wydawnictwa. Jedyną zmianą w budowie widoku jest włączenie do widoku kolumny ID_wydawnictwa z tabeli Ksiazki. Nowy widok prezentuje się następująco: tytul rok_wydania ID_wydawnictwa wydawnictwo SQL Server Vademecum Administratora Promise Windows Server Vademecum Administratora Promise UML w kropelce LTP MS Access wersja 2002 dla ekspertów Promise XML na powaŝnie Helion

15 184 Bazy danych Teraz moŝna dodać dane do bazy za pomocą naszego widoku. W oknie SQLQuery wpisz i wykonaj następujący kod: INSERT INTO widok_ksiazki_wydawnictwa_2(tytul,rok_wydania,id_wyd awnictwa) VALUES ('SQL Server','2000',1) SELECT * FROM widok_ksiazki_wydawnictwa_2 Wynikiem wykonania powyŝszego kodu jest wstawienie nowego wiersza do tabeli Ksiazki (mimo, Ŝe wstawiamy dane w widok). PowyŜszą operację moŝemy wykonać, poniewaŝ w tabeli Wydawnictwa istnieje wiersz mający w kolumnie ID_wydawnictwa wartość 1 (tabela Ksiazki korzysta z tej kolumny na potrzeby własnej kolumny - klucza obcego - ID_wydawnictwa). Gdybyśmy usiłowali jednocześnie wstawić nieistniejące wydawnictwo, polecenie INSERT zwróciłoby błąd. Tym razem wynikiem wykonania zapytania SELECT jest wyświetlenie danych z widoku widok_ksiazki_wydawnictwa_2 z nowo dodanym wierszem. tytul rok_wydania ID_wydawnictwa wydawnictwo SQL Server Vademecum Administratora Promise Windows Server Vademecum Administratora Promise UML w kropelce LTP MS Access wersja 2002 dla ekspertów Promise XML na powaŝnie Helion SQL Server Promise