Perspektywy

170
Bazy danych
Perspektywy
Bazy danych
Przegląd zagadnień
Podstawowe wiadomosci o perspektywach i ich
wlasnosciach
Tworzenie i uzytkowanie perspektyw
Podsumowanie
Pytania sprawdzajace
Laboratorium
171
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
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
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
Bazy danych
Tworzenie perspektyw
Modyfikacja danych z pomoca perspektyw
Indeksowanie perspektyw
175
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
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.
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
wykorzystujemy polecenie UPDATE według schematu:
przez
UPDATE <nazwa_perspektywy>
SET <nazwa_kolumny> = '<wartość_zmieniana>'
WHERE <nazwa_kolumny> = '<nowa_wartość>'
perspektywę
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)
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.
Bazy danych
181
Laboratorium
Przećwiczmy teraz zdobytą wiedzę. Dokonamy teraz operacji stworzenia
perspektywy oraz wyświetlenia i modyfikacji danych za jej pomocą.
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
GO
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
GO
SELECT * FROM widok_ksiazki_wydawnictwa
GO
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 2000. Vademecum Administratora
2001
Windows Server 2003. Vademecum Administratora
2003
UML w kropelce
2002
MS Access wersja 2002 dla ekspertów
2003
XML na powaŜnie
2002
MS Press
MS Press
LTP
MS Press
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'
GO
SELECT * FROM Wydawnictwa
GO
Bazy danych
183
Wynikiem wykonania powyŜszego kodu jest wyświetlenie zawartości
tabeli Wydawnictwa.
ID_wydawnictwa wydawnictwo
-------------- ----------1
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')
GO
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
GO
SELECT * FROM widok_ksiazki_wydawnictwa_2
GO
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 2000. Vademecum Administratora
2001
1
Promise
Windows Server 2003. Vademecum Administratora
2003
1
Promise
UML w kropelce
2002
2
LTP
MS Access wersja 2002 dla ekspertów
2003
1
Promise
XML na powaŜnie
2002
3
Helion
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)
GO
SELECT * FROM widok_ksiazki_wydawnictwa_2
GO
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 2000. Vademecum Administratora
2001
1
Promise
Windows Server 2003. Vademecum Administratora
2003
1
Promise
UML w kropelce
2002
2
LTP
MS Access wersja 2002 dla ekspertów
2003
1
Promise
XML na powaŜnie
2002
3
Helion
SQL Server
2000
1
Promise