MS SQL Server 6.5 - Zarządzanie i tworzenie "widoków"









Widoki są statycznie zdefiniowane aby tworzyć dynamicznie tabele konstruowane
na jednym lub większej ilości wierszy stosownie od pierwotnie zdefiniowanego
kryterium wyboru.
Widoki mogą być używane aby definiować liczne kombinacje wierszy
i kolumn z jednej lub większej ilości tabel. Definiowany widok oparty na
kombinacji wierszy i kolumn używa prostej konstrukcji SELECT
wyszczególnić wiersze i kolumny włączone w widoku.Zrozumienie
widoku
W widoku jest przechowywana definicja wybranego zapisu wierszy i kolumn,
która jest odniesieniem do niego.
Można zdefiniować do 250 kolumn w jednej lub w większej ilości tabel w
widoku.
Liczba wierszy które można zdefiniować w widoku jest ograniczona tylko liczbą
wierszy w tabeli odniesienia. Widok może być tak zdefiniowany że będziemy się do
niego odnosić jak do tabeli. Chociaż widok można uważać jako trwały zestaw
wierszy i kolumn zapamiętanych w bazie danych na dysku to tak nie jest.
Widok nie tworzy trwałych kopii wybranych wierszy i kolumn bazy danych.
Tymczasowa tabela jest tworzona i zwracana na monitor bez możliwości
dostępu do momentu kiedy jej wiersze będą kompletne.
Widok pozwala wykonać konstrukcje SELECT kiedy odnosimy się do widoku
jak do tabeli.
Bardzo łatwo pomylić widok z tabelą.
Raz widok jest definiowany w ten sposób że mamy dostęp do danych jak do
tabeli. Trzeba pamiętać że dane odniesione do widoku pochodzą od tabeli
głównej.
Poza tym jak dodamy kolumnę do tabeli głównej to tą kolumnę zobaczymy w
widoku po ponownym zdefiniowaniu go lub po przedefiniowaniu widoku.
Widok może być używany do dostępu do wszystkich tabel, części tabel,
kombinacji tabel. Ponieważ część tabeli do której mamy dostęp jest definiowana w
granicach widoku i nie trzeba powtarzać konstrukcji SELECTION.
Widoków można używać po to aby uprościć dostęp do bazy danych. Jeżeli
tworzymy nawet skomplikowane widoki, które wykorzystują wielorakie klauzule,
możemy użyć konstrukcji SELECT tak prosto jak widok zawiera prosty system
wyboru.
Widoków można używać dla polepszenia bezpieczeństwa baz danych.
Można przyznawać dostęp do widoków w ten sposób że będzie on inny niż dostęp
do tabel na których bazuje widok.
Można nadać dostęp tylko tym wierszom i kolumnom odniesionym do widoku a
nie wszystkim wierszom i kolumnom bezpośrednio przez tabelę.

 

Widoki można tworzyć korzystając z wiersza poleceń isql, z sesji ISQL/w lub
korzystając z ENTERPRISE MANAGER. Widok jest przechowywany jako oddzielny obiekt
w bazie danych. Trzeba pamiętać że widoki tworzymy tylko w aktualnej bazie
danych.
Składnia wiersza poleceń isql oraz ISQL/w przedstawiona jest poniżej:




CREATE VIEW view_name [WITH ENCRYPTION] ASSELECT
statement...FROM table_name |
view_name [WHERE clause] [WITH CHECK
OPTION]
Można też tworzyć okna korzystając z SQL ENTERPRISE MANAGER postępując w
następujący sposób:
W bieżącej bazie danych wybieramy folder widoków.
Wybieramy nowy widok.
Wpisujemy nazwę nowego widoku lub edytujemy istniejący.
Zapamiętujemy nowy widok. Przy tej operacji komputer sprawdza czy
nowopowstały widok nie zawiera żadnych błędów oraz sprawdza czy już nie
istnieje widok i takiej samej nazwie.  SELECTIVE
COLUMNS / selektywne kolumny
Widoki można definiować na podstawie kolumn tabeli. W poniższym przykładzie
widok jest definiowany jako pseudo-tabela posiadająca 2 z 3 kolumn tabeli
głównej.




create view twocolumns asselect name, badgefrom
employees
Po zdefiniowaniu widoku możemy używać konstrukcji SELECT do dostępu do
danych. Np. dwu kolumnowy widok może być używany do wyświetlania wszystkich
imion i nazwisk wszystkich wierszy.SELECTIWE ROWS
/ selektywne wiersze
Widoki można definiować na podstawie wierszy tabeli. W poniższym przykładzie
widok zawiera tylko wiersze widoku sales1 które są równe wierszom
SALES z tabeli Employees:




create view twocolumns asselect name, badgefrom
employees
Po zdefiniowaniu widoku możemy używać konstrukcji SELECT do dostępu do
danych. Np. dwu kolumnowy widok może być używany do wyświetlania wszystkich
imion i nazwisk wszystkich wierszy.
Możemy używać jednego lub większej ilości operatorów logicznych przy
konstrukcji WHERE w konstrukcji SELECT tak aby wyszczególniać
interesujące nas wiersze.
W poniższym przykładzie widok zawiera tylko te wiersze tabeli
Employees, których wartość department jest równa wartości pól
SALES




create view sales1 asselect name, department,
badgefrom employeeswhere
department='SALES'
Można używać słowa kluczowego WHERE w konstrukcji SELECT tak
aby wyszczególnić wiersze odnoszące się do widoku. W poniższym przykładzie widok
zawiera wszystkie kolumny tabeli gdzie są składniki sales
i badge większe od jedności:




create view sales2 asselect name, department,
badgefrom employeeswhere
department='Sales'and badge >
1000
Można używać słowa kluczowego WHERE w konstrukcji SELECT tak
aby odnosić się do widoku jak do tabeli. SELECTIVE ROWS AND KOLUMNS /
selektywne kolumny i wiersze
Można też definiować widok będący kombinacją wierszy i kolumn tabeli.
Przykład pokazuje dwukolumnowy widok zdefiniowany na trzykolumnowej tabeli
zawierający wiersze sales departament:




create view twocolumnsales asselect
name,badgefrom employeeswhere
department='SALES'
Możemy kontynuować używając konstrukcji SELECT tak aby odnosić się do
widoku jak do tabeli z zestawem wierszy i kolumn zdefiniowanych jak w
widoku. Następny przykład pokazuje wszystkie wiersze i kolumny zdefiniowane
w trzech poprzednich widokach. Można używać trzech następujących konstrukcji
SELECT:




select *from twocolumns
        (dla dwukolumn)select
*from sales1
                
(dla sales1)select *from twocolumnsales  (dla
dwukolumnsales)
Można wyszczególniać tylko te kolumny zdefiniowane na widoku ze słowem
kluczowym SELECT w konstrukcji SELECT. Nie trzeba używać gwiazdki
(*) aby odnieść się do wszystkich kolumn zdefiniowanych w widoku.
Bardzo trudno jest odróżnić widok od tabeli. Do odróżnienia trzeba zobaczyć
definicję widoku, można stworzyć taki widok który będzie taką kombinacją wierszy
i kolumn że będzie do niego dostęp z tabel.
Wskazane jest aby używać nazw samo-opisowych do widoków i tabel np.
tabela_pracownicy, widok_sprzedawcy. Cechą widoku jest to że pracuje się z nim
tak jak z tabelą, co może stanowić dobre zabezpieczenie przed niepowołanymi
użytkownikami.
Widoki jakie by nie były mają pewne ograniczenia tzn:
Widoku nie można tworzyć na tymczasowej tabeli, które istnieją do momentu
zakończenia pewnego działania na tabeli głównej. Widok zdefiniowany na
tymczasowej tabeli zostanie skasowany w momencie kiedy tabela taka przestanie
istnieć.
W widoku nie można definiować tzw. TRIGGER, który może być
zdefiniowany tylko na głównej tabeli (będącej źródłem danych dla wszystkich
widoków). Mając np. prawo do tworzenia TRIGGER w widoku SQL serwer
nadal będzie miał odniesienie do głównej tabeli aby zlokalizować dane
wyszczególnione przez TRIGGER.
TRIGGER jest to obiekt automatycznie powstający kiedy do tabeli
jest dodawany, kasowany lub modyfikowany wiersz. TRIGGER utrzymuje
integralność tabeli.
W widoku nie można dołączać słowa kluczowego ORDER BY. Wiersze w
widoku jak i w tabeli nie są związane ze sobą. Jeżeli w widoku używaliśmy
konstrukcji SELECT z konstrukcją ORDER BY to mogłoby to
doprowadzić do związania wierszy a zatem do zmiany charakterystyki widoku w
stosunku do tabeli. Jeżeli projekt widoku zakładał używanie go jak tabeli to
musi mieć podobną do tabeli charakterystykę. Konstrukcji ORDER BY można
używać kiedy odzyskujemy wiersze z widoku tak jak byśmy odzyskiwali wiersze z
tabeli.
W widoku nie można używać konstrukcji COMPUTE, ponieważ tworzy ono
wirtualną kolumnę dla tabel i widoków.
W widoku nie można używać konstrukcji DISTINCT w konstrukcji
SELECT.
DISTINCT można używać w ten sposób że nie zwraca podwójnych
wierszy.
Można zapewnić że wiersze uzyskiwane w widoku będą posiadały unikatowy klucz
lub indeks głównej tablicy na której opiera się widok.
W poniższym przykładzie jest pokazana zasada używania funkcji
DISTINCT:




create view departments asselect distinct
departmentsfrom employeesFunkcja DISTINCT nie
jest zawarta w widoku.
W widoku nie można używać funkcji INTO jako części funkcji
SELECT. INTO kieruje wiersze do innej tablicy niż do monitora.
Poniższy przykład udowadnia że widok nie może być stworzony ponieważ zawiera
konstrukcję INTO w konstrukcji SELECT:




sp_help two




Name
Owner
Type


------------------
----------------
-----------


two
dbo
user table




Data_located_on_segment
When_created


------------------------------
---------------------------


default
Oct 2 1994 1:33PM




Column_name
Type
Length
Nulls
Default_name
Rule_name


-----------------
----------
-------
------
--------------
------------


name
char
25
0
(null)
(null)


badge
int
4
0
(null)
(null)


Obiekt nie zawiera
żadnego
indeksu





Nie  zdefiniowano
żadnych
kluczy
dla tego
obiektu.

Tworzenie widoku z select into jako:




select name,badgeinto twofrom
employeesINTO nie jest zawarte w widoku.




Proste widoki to te które są kombinacją wierszy i kolumn tablicy na
której oparte są widoki, natomiast złożone widoki to te które są kombinacją
wierszy i kolumn wielu tabel. Złożone widoki używają tej samej konstrukcji
SELECT co widoki proste, a pokazuje to poniższy przykład:




CREATE VIEW view_name ASSELECT
column_1,...column_nFROM table_1,...table_nWHERE
table_key_1=table_key_2,...AND
table_key_1=table_key_n
Konstrukcja WHERE jest wykorzystana do powiązania wierszy jednej
tabeli z drugą. Kolumna Badge jest używana w każdej tabeli do porównywania
wierszy w taki sam sposób jak odpowiednia kolumna może być używana do
dopasowania wierszy w konstrukcji SELECT używanej poza widokiem:




create view combo asselect
name,department,hours_workedfrom employees,payswhere
employees.badge=pays.badge
Dostęp do wierszy i kolumn w złożonym widoku jest podobny do dostępu w
widoku prostym. Np. można odnieść się do wierszy i kolumn zdefiniowanych w
widoku COMBO używając konstrukcji SELECT:




select *from combo

 

Kiedy tworzymy widok jego definicja przechowywana jest w specjalnej tablicy
systemowej nazywanej syscomments. Jedyną możliwością wyświetlenia
zawartości tej tablicy jest użycie procedury sp_helptext.
Sp_helptext może być używane również do wyświetlania TRIGGER'A,
ZAWARTOŚCI PROCEDURY, itp.. Używanie sp_help wyświetli nam
charakterystykę widoku lub innego obiektu. W przykładzie prosty widok jest tak
zdefiniowany że wyświetla wszystkie wiersze Sales department.
Wiersze tabeli Employees są zwracane w widoku sales. Użycie zapisu
"sp_helptext sales1" spowoduje wyświetlenie definicji widoku.:




sp_helptext sales1text-------------------create
view sale1s asselect * from employeeswhere
department='Sales'(1 row(s)
affected)
Definicja jest wyświetlana jako wiersze tablicy.
SQL SERWER posiada 12 tablic systemowych w których przechowuje dane.
Drugim sposobem wyświetlenia definicji widoku jest użycie SQL Enterprise
Manager postępując następująco:
Wybieramy folder widoku który chcemy obejrzeć.

Klikamy prawym klawiszem myszy aby przywołać menu Manage Views
i wybieramy Editor lub Views.


 

Należy używać SQL ENTERPRISE MANAGER do edycji istniejącego widoku. Nie można
edytować widoku z wiersza poleceń isql lub w sesji ISQL/w. Można by edytować
widoki zmieniając kolumny lub wiersze odniesione do widoku. Np. musimy nazwać
kolumnę którą zapomnieliśmy nazwać w momencie tworzenia widoku.
Aby edytować widok z SQL ENTERPRISE MANAGER należy postępować według
następujących kroków:
Wybieramy folder widoku OBJECT w bazie danych w której dany widok
jest tworzony.
Klikamy prawym klawiszem myszy aby wyświetliło się menu MANAGE
VIEWS, otwieramy to menu i wybieramy EDIT lub otwieramy
MANAGE MENU i wybieramy VIEWS (widok) albo dwukrotnie
klikamy lewym klawiszem myszy na wybranym widoku.
Wprowadzamy zmiany do słowa kluczowego CREATE VIEW <view
name> AS.
Klikamy przycisk wykonania (rysunek poniżej) w oknie MANAGE VIEWS.


Następny rysunek pokazuje widok po wprowadzonych zmianach.

Można zmieniać nazwę widoku w oknie MANAGE VIEWS.
Poprawność zapisu rozpoczyna się od słowa kluczowego IF, jest
sprawdzane to czy twój widok nie jest już gdzieś zdefiniowany jeżeli tak to
przedefiniowuje go tak aby powstał nowy widok.
Skasowanie widoku jest zgodne z założeniami SQL SERVER ponieważ nie ma on
prawa wprowadzać zmian w istniejącym widoku.
Okno dialogowe Manger View (menedżera widoków) automatycznie generuje
kod kasowania i kod tworzenia nowego widoku jeżeli tylko zostały
wprowadzone jakiekolwiek zmiany.
Efektywne edytowanie może odbywać się z isql lub ISQL/w tylko po skasowaniu
istniejącego widoku i stworzeniu nowego o tej samej nazwie co ten
skasowany. O wiele łatwiejsza jest zmiana widoków korzystając z SQL Enterprise
Manager.
Komenda GO jest używana aby SQL Serwer wykonał poprzedni zapis.
Można zablokować podgląd definicji widoku dla innych użytkowników poprzez
dodanie WITH ENCRYPTION w procesie tworzenia widoku CREATE VIEW.
Poniższy przykład pokazuje że definicja widoku nie może być wyświetlona przy
użyciu funkcji sp_helptext:




create view test_view_encryption with encryption asselect
* from company gosp_helptext test_view_encryption
go
Opis obiektu został utajniony. Nie można też podejrzeć definicji korzystając
z SQL Enterprise Manager. Rysunek poniżej pokazuje informację zwracaną kiedy
chcemy wyświetlić utajnioną definicję.

Wadą takiego szyfrowania jest to że widok nie może być zmieniany kiedy robimy
upgrade naszej bazy danych lub SQL Server'a. Podczas upgradu, definicja widoku
jest używana do ponownego tworzenia widoku pod warunkiem że definicja nie była
utajniona. Nie można przeprowadzić upgradu bazy danych gdy skasowana zostanie
definicja zawarta w wierszach tablic syscoments.
Można też utajniać procedury i triggers dla
bezpieczeństwa. Można zabezpieczyć się przed wyświetlaniem zawartości obiektów a
także nadzorować poziom zabezpieczeń.

 

Aby wyświetlić na jakich tabelach lub widokach jest zdefiniowany widok należy
użyć procedury systemowej sp_depends. Ta funkcja przydaje się przy
usuwaniu problemów powstałych podczas używania widoku.
W przykładzie sp_depends pokazuje że widok sales jest oparty na tabeli
Employees:




sp_depends salesThings the object references in the current
database.




object
type
updated
selected


-----------------
-----------
-------
--------


dbo.employees
user table
no
no


(1 row(s) affected)



Można też używać sp_depends do wyświetlania informacji
i zależności między tablicami i widokami złożonych z procedur.
Sp_depends odnosi się do obiektów aktualnej bazy danych.
Można wyświetlać zależności korzystając z SQL Enterprise Manager. Aby
wyświetlić zależności wystarczy kliknąć prawym klawiszem myszy i z menu
wybrać opcję zależności. Np. na rysunku zależności są wyświetlane w oknie
dialogowym Object Dependencies. Okno dialogowe Object Dependencies
pokazuje że widok jest oparty na czterech tabelach.


 

Można zdefiniować widok który będzie bazował na widoku lub kilku widokach lub
kombinacji widoków i tabel. W przykładzie pierwszy widok oparty jest na
tabeli, drugi oparty jest na pierwszym widoku. Nie zależnie od tego jak dużo
widoków jest zdefiniowanych każdy musi opierać się na głównej tabeli będącej
głównym źródłem danych:




create view salesonly asselect
name,department,badgefrom employeeswhere
department='Sales'go


(Ta komenda nie zwraca danych ani wierszy)




create view salespersons asselect namefrom
salesonly


(Ta komenda nie zwraca danych ani wierszy)
Kontynuując przykład procedura Sp_depends jest używana aby potwierdzić
że drugi widok jest zdefiniowany na pierwszym:




select * from
salespersonsname--------------------Jan
KowalskiMary JonesJohn Garr(3 row(s)
affected)sp_depends
salespersonsgo
Składniki obiektu odniesienia w bieżącej bazie danych:




object
type
updated
selected


----------------------
-------
---------
-----------


dbo.salesonly
view
no
no


(1 row(s) affected)



Sp_depends nie potwierdza wszystkich widoków opartych na innych
widokach. Jeżeli widok odnosi się do innego widoku to, sp_depends pokaże
powiązania innego widoku niż oryginalnej tabeli. Procedura Sp_depends
pokaże tylko ten widok lub tabelę na której bezpośrednio opiera się definicja
widoku.
Chociaż sp_help pokazuje kolumny włączone w wierszach, to nie pokazuje
włączonych wierszy. Definicje takie jak WHERE, nie są wyświetlane przez
sp_help. Trzeba sprawdzać definicję widoku przez użycie
sp_helptext.
Jeżeli chcemy zobaczyć kolumny włączone w wierszach w widoku lub w kilku
widokach musimy użyć sp_helptext aby wyświetlić wszystkie definicje
widoku. Jeżeli widok jest zdefiniowany tylko na tablicach to użycie
sp_helptext wyświetli wiersze i kolumny użyte w widoku, dlatego
znacznie lepiej jest formułować widok na tablicy niż na innym widoku.
Powinniśmy używać Object Dependencies w SQL Enterprise Manager aby wyświetlić
zależności obiektów. W przeciwieństwie do sp_depends, wyświetlanie listy
powiązań obiektów w Object Dependencies pokazuje wielopoziomowo widoki
i tabele na których dany widok został oparty. Przykładem jest rysunek,
gdzie okno dialogowe Object Dependencies pokazuje na jakich obiektach
jest zdefiniowany widok. Sekwencja numerów ilustruje poziomy obiektów na jakich
widok został zdefiniowany.


 

Można zmieniać nazwy kolumn tabeli bazowej użytej w widoku przy użyciu słów
kluczowych tak jak przy definicji widoku. Używanie poniższej składni zmienia
nazwy kolumn opartych na widoku:




CREATE VIEW view_name [ (view_column_1,...view_column_n)
] ASSELECT statement...FROM table_name or
view_name[WHERE clause]
Następny przykład pokazuje zmienione nazwy kolumn w tabeli Employees
jako część definicji widoku. Pojedyncza litera (lista) jest używana jako
inna nazwa kolumny w widoku. Jedna lista zawiera nazwy kolumn zdefiniowanych w
widoku, alternatywne nazwy kolumn tworzą nową kolumnę nazw:




create view view8 (a,b,c)asselect
name,department,badge from employees(1 row(s)
affected)select * from view8




a
b
c


---------------------
-----------
--------


Mary Jones
Sales
5514


Dan Duryea
Shipping
3321


John Garr
Sales
3321


Mark Lenard
Sales
3331


Jan Kowalski
Sales
1


Minty Moore
Sales
7444


(6 row(s) affected)


Nie trzeba tworzyć widoku aby zmienić nazwę kolumny, można użyć konstrukcji
SELECT poza widokiem:




SELECT
column_name=renamed_name...

 

Można użyć sp_rename aby zmienić nazwę widoku, np.:




sp_rename old_name, new_name
Przykład pokazuje zmianę nazwy widoku sales na sales2.
Sp_depends pokazuje że widok ze zmienioną nazwą nadal bazuje na tabeli
podstawowej Employees:




sp_rename sales, sales2sp_depends
sales2
      (Nazwa została
zmieniona)
Składniki odniesienia w bieżącej bazie danych




object
type
updated
selected


----------------------
-------
---------
-----------


dbo.employees
user table
no
no


(1 row(s) affected)



Można zmieniać nazwę widoku używając SQL Enterprise Manager postępując
według następujących kroków:
Lewym przyciskiem myszy wybieramy widok.
Klikamy prawym przyciskiem myszy i wybieramy Rename.
Wprowadzamy nową nazwę w okienku dialogowym.
Klikamy OK.
Rysunek pokazuje okno dialogowe zmiany nazwy

Można używać sp_rename do zmiany nazwy innym obiektom bazy danych
włączając w to: tabele, kolumny, procedury,
triggery, indeksy, stałe, rules i zmienne
użytkownika.
Sp_rename nie zmieni nazwy tablicy lub widoku z zapisanymi definicjami
widoków.
Przykład pokazuje ostrzeżenie przed zmianą nazwy tablicy employees.
Użycie sp_helptext pokazuje że stara nazwa tablicy jest przechowywana w
definicji widoku na której widok bazuje:




sp_rename employees,newnameWarning - Procedures, views or
triggers reference this object (OSTRZEŻENIE)and will become
invalid.Object name has been changed.sp_helptext
salesonlygotext-----------------------------------------------------create
view salesonly asselect name,department,badgefrom
employeeswhere department='Sales'select *
from salesonlygo




name
department
badge


--------------------
--------------------
-----------


Fred Sanders
SALES
1051


Jan Kowalski
SALES
1834


Anna Nowak
Sales
9998


(3 row(s) affected)


Zarówno sp_depends jak i okno dialogowe Object
Dependencies wyświetlają zaktualizowane nazwy zmienionych tablic
i widoków.
Nie należy zmieniać nazw obiektom bez wyraźnej konieczności.

 

Można używać komendy DROP VIEW aby usunąć widok/i z bazy danych.
Usunięcie widoku/ów nie wpływa na tabelę główną. Definicja widoku/ów jest prosto
usuwana z bazy danych. Składnia DROP VIEW wygląda następująco:




DROP VIEW view_name_1, ...
view_name_n
Można też użyć SQL Enterprise Manager:
Lewym klawiszem myszy zaznaczamy interesujący nas widok.
Prawym klawiszem wybieramy opcję Drop.
Klikamy na przycisk Drop All.
Rysunek niżej pokazuje okno dialogowe wyświetlane przy kasowaniu widoku.

Można przed skasowaniem widoku obejrzeć jego zależności.
Jeżeli skasujemy widok na którym bazował inny widok to ten widok
zasygnalizuje błąd przy próbie odwołania do niego. Dlatego bezpieczniej jest
tworzyć widoki na tabelach, które rzadziej są kasowane.

 

Oprócz wstawiania wierszy do widoku, można użyć widoku aby wstawić wiersze do
tabeli macierzystej na której widok jest zdefiniowany. Przykład pokazuje dodanie
wiersza do tabeli Employees przy użyciu funkcji INSERT. Wiersze
dodane do widoku są również umieszczane w tablicy na której dany widok został
zdefiniowany:




sp_helptext
salesgotext-------------------create view
sales asselect * from employeeswhere
department='Sales'goinsert into salesvalues
('Mark Lenard','Sales',3331)select * from
saleswhere badge=3331 go




name
department
badge


--------------------
--------------------
-----------


Mark Lenard
Sales
3331


(1 row(s) affected)






select * from employeeswhere
badge=3331




name
department
badge


--------------------
--------------------
-----------


Mark Lenard
Sales
3331


(1 row(s) affected)


Wiersz wstawiony w widok dopasował kryterium zawarte w konstrukcji
WHERE widoku; wstawiony wiersz zawierał department, Sales.

Kryteria dla wierszy zdefiniowane w konstrukcji WHERE zapobiegają
przed otrzymywaniem nowych wierszy które właśnie dołączyliśmy. Przykładem jest
poniższy zapis konstrukcji INSERT, wiersz jest wstawiany przez widok do
tablicy employees na której widok sales został zdefiniowany.
Użyjemy definicji widoku sales z poprzedniego przykładu, można zauważyć
że wiersze mogą mieć tylko Sales, department.
Późniejsza konstrukcja SELECT nie będzie mogła uzyskać nowo
wstawionych wierszy widoku, mimo że wiersz został dodany do tablicy głównej.
Konstrukcja SELECT odnosząca się do tablicy zwraca nowy wiersz który
został dodany w widoku. Oba przykłady są pokazane poniżej:




insert into salesvalues ('Fannie
Farmer','Logistics',6689)goselect * from
saleswhere badge=6689




name
department
badge


--------------------
--------------------
-----------


(0 row(s) affected)






select * from employeeswhere badge=6689
go




name
department
badge


--------------------
--------------------
-----------


Fannie Farmer
Logistics
6689


(1 row(s) affected)


Mylące jest to że dodawany wiersz do głównej tabeli poprzez widok nie zmienia
kryteriów dla dopasowywanego widoku. Wiersz może być dodany poprzez widok ale
nie może być wyświetlony poprzez tan sam widok. Można temu zapobiec używając
konstrukcji WITH CHECK OPTION.
Konstrukcja WITH CHECK OPTION, stosowana z konstrukcją SELECT
zdefiniowaną w widoku przestrzega wszystkich zmian wprowadzonych poprzez
wiersze. Przykładem jest widok zdefiniowany na tablicy employees,
zawierający konstrukcję WHERE która wyszczególnia tylko dział
Sales i tylko wiersze zawierające dział Sales, mogą być
dodane do tabeli employees poprzez widok. Konstrukcja WITH CHECK
OPTION jest ilustrowana przez poniższy przykład:




create view check_with_check asselect * from
companywhere department='Sales' with check optiongo
      (Ta komenda nic nie zwraca)insert into
check_with_checkvalues ('Bob Matilda','Field
Service',3325,2) goMsg 550, Level 16, State
2
Można dodać wiersz do widoku ale nie można go zobaczyć kiedy odnosimy się do
wiersza poprzez konstrukcję SELECT, wynika to z kryterium definicji
widoku.
Można także kasować wiersze w widoku, przez inny widok lub bezpośrednio z
tablicy głównej, ale można wyłączyć znikanie wierszy poprzez użycie konstrukcji
WITH CHECK OPTION w definicji widoku.
Jeżeli stworzymy widok który nie zawiera wszystkich kolumn tablicy bazowej to
brakujące kolumny należy w widoku zdefiniować jako puste lub o jakieś stałej
wartości w przeciwnym razie nie będzie można dodać wierszy do tabeli poprzez
widok, ilustruje to poniższy przykład.
Widok zawiera dwie kolumny z tablicy employees. Dodanie wiersza
poprzez widok nie będzie możliwe ponieważ kolumna Department jest
zdefiniowana z wartością NOT NULL.




create view namebadge asselect name,badgefrom
employees go insert into
namebadge(name,badge)values ('Russell
Stover',8000)Msg 233, Level 16, State
2
Poniższy przykład pokazuje wiersz wstawiony do głównej tabeli
employees poprzez widok namebadge, konstrukcja SELECT jest
użyta do zobaczenia / odzyskania nowego wiersza w widoku i w tablicy.




select * from namebadgewhere name='Russell
Stover' go




name
badge


--------------------
-----------


Russell Stover
8000


(1 row(s) affected)






select * from employeeswhere name='Russell
Stover' go




name
department
badge


--------------------
--------------------
-----------


Russell Stover
Sales
8000


(1 row(s) affected)



 

Można skasować wiersze w widoku nawet wtedy gdy nie wszystkie kolumny tabeli
są w widoku odniesione. W poniższym przykładzie wiersz najpierw został dodany do
tablicy Employees poprzez widok namebadge, a następnie został
skasowany przez ten widok. Konstrukcja SELECT demonstruje kasowanie
wiersza.




delete from namebadgewhere name='Russell
Stover'go(1 row(s) affected)select * from
namebadgewhere name='Russell
Stover'go




name
badge


--------------------
-----------


(0 row(s) affected)

Nie można skasować wiersza używając konstrukcji SELECT jeżeli ta
konstrukcja nie obejmuje tego wiersza. Nie jest konieczne dodanie konstrukcji
WITH CHECK OPTION do definicji widoku aby zapobiec skasowaniu wierszy
które nie są objęte kryterium WHERE w widoku. Poniższy przykład pokazuje
parę wierszy do skasowania z działu Shipping przez widok sales.
Nawet jeżeli wiersze tabeli zostały zapisane w tabeli bazowej Employees
na której bazuje widok sales, to nie można ich skasować poprzez
widok.




delete from saleswhere
department='Shipping'go(0 row(s)
affected)
Nie można też skasować wiersza z głównej tabeli na której bazuje widok jeżeli
kolumna którą określiliśmy w klauzuli WHERE konstrukcji DELETE
określa kolumnę nie zaznaczoną w widoku.
Przykład zwraca błąd ponieważ kolumna określona klauzulą WHERE nie
istnieje w widoku namebadge używającego zapisu DELETE.




delete from namebadgewhere
department='Shipping'goMsg 207, Level 16, State
2Invalid column name 'department'.
Można ponadto skasować wiersze z tabeli na której dany widok bazował.
Poniższy przykład pokazuje skasowanie wiersza za pomocą konstrukcji
DELETE w tabeli w której wiersz się znajdował:




delete from employeeswhere
department='Shipping'go(1 row(s)
affected)

 

Można użyć konstrukcji UPDATE aby zmienić wartość jednej lub większej
ilości kolumn lub wierszy w widoku. Wszystkie wprowadzone zmiany są
przeprowadzane na tabeli głównej na której bazuje dany widok. Poniższy przykład
pokazuje zaktualizowanie jednego wiersza w widoku sales:




select * from sales




go




name
department
badge


----------------------------------
---------------
--------


Jan Kowalski
Sales
1234


Mary Jones
Sales
5514


John Garr
Sales
2221


Mark Lenard
Sales
3331


(3 row(s) affected)




update salesset badge=0001where name='Jan
Kowalski'go(1 row(s) affected)select * from
sales




name
department
badge


---------------------------------
---------------
--------


Jan Kowalski
Sales
1234


(1 row(s) affected)


Poniższy przykład pokazuje zmianę wartości wiersza poprzez widok oraz zmianę
wartości kolumny tak że wiersz już nie oblicza kryterium zdefiniowanego na
widoku:




set department=Field Servicewhere name="Jan
Kowalski"(1 row(s) affected)select * from
saleswhere name="Jan Kowalski"




go




name
department
badge


----------------------------------
---------------
--------


(0 row(s) affected)


Można też aktualizować tablicę podstawową poprzez widok zdefiniowany na niej.
Poniższy przykład pokazuje aktualizację tabeli Employees poprzez widok
oparty na tabeli:




select * from
onlynamenamego-------------------------Jan
KowalskiFred Sanders(2 row(s) affected)update
onlynameset name='Bob Orieda'where name='Jan
Kowalski'go(1 row(s) affected)select * from
onlynamegoname-------------------------Fred
SandersBob Orieda(2 row(s) affected)select * from
employeeswhere name like
'Bob%'go




name
department
badge


--------------------------
---------------
--------


Bob Orieda
SALES
1834


(1 row(s) affected)


Aktualizacja wiersza odbyła się poprzez widok onlyname, który był
oparty na tabeli głównej.
Zaktualizowany wiersz jest wyświetlany w widoku sales:




select * from saleswhere name like
'Bob%'go




name
department
badge


--------------------------
---------------
--------


Bob Orieda
SALES
1834


(1 row(s) affected)


Jakiekolwiek zmiany w widoku mają swoje odbicie w tabeli głównej.
Użytkownicy starszych baz danych takich jak hierarchiczne lub sieciowe,
pamiętają że bazy danych mogły manipulować obiektami równoważnymi z widokami.
Odpowiednikiem widoków w sieciowych bazach danych były obiekty zwane
subschema.
Zawsze należało używać subschemy aby mieć dostęp do bazy danych.
Zazwyczaj standardowa subschema była tworzona razem z bazą danych
i pozwalała na dostęp w razie potrzeby.
Można aktualizować podstawową tabele używając wielo-tablicowych widoków,
jeżeli tylko aktualizowane kolumny są częścią tej samej tabeli.
Przykład pokazuje że można zaktualizować wiersz przy wykorzystaniu
wielo-tablicowych widoków (combo):




create view combo (a,b,c) asselect
name,employees.badge,pays.badgefrom
employees,payswhere
employees.badge=pays.badgego               
( Ta komenda nie zwraca żadnej wartości )update
comboset a='Jim Walker II'where
b=3211go(1 row(s) affected)select * from
combowhere b=3211go




a
b
c


--------------------------
---------------
--------


Jim Walker II
3221
3221


(1 row(s) affected)


Nie można aktualizować kolumn współpracujących z wierszami pomiędzy tabelami
ponieważ są one częścią tabel. Następny przykład pokazuje kolumnę b
i kolumnę c widoku, oparte na kolumnie Badge tabel Employees
i Pays oraz błąd jaki jest zwracany przy aktualizowaniu kolumn z
dwóch tabel.




update comboset c=1111, b=1111where
b=8005goMsg 4405, Level 16, State
2
Widok 'combo' nie uaktualnia tabel ponieważ definicja FROM
odwołuje się do wielu tabel.
Można zmienić wartość w pojedynczej kolumnie poprzez widok, a także używać
trigger aby aktualizować korespondujące wartości w powiązanych tabelach.
W poniższym przykładzie trigger został zdefiniowany tak aby automatycznie
aktualizować kolumnę Badge w tabeli Pays jeżeli tylko ta kolumna
zostanie zmieniona. Kiedy kolumna 'badge' zostanie zmieniona przez
kolumnę b w widoku 'combo' to funkcja trigger zostanie uaktywniona
i zmieni wartości w korespondującej tabeli Pays:




update comboset b=9999where
c=4411go(1 row(s) affected)select * from
combowhere b=9999go




a
b
c


--------------------------
---------------
--------


Sue Sommers
9999
9999


(1 row(s) affected)



 

Jeżeli stworzymy nową tabelę z tą samą nazwą co tabela odnosząca się do
widoku (wcześniej skasowana) będzie można otrzymać dane z nowej podstawowej
tabeli poprzez widok.
Poniższy przykład pokazuje skasowanie tabeli na której opierał się widok.
Funkcja sp_help potwierdza że widok odwołuje się do tabeli już
skasowanej. Kiedy widok używa konstrukcji SELECT, występuje błąd ponieważ
tabela nie istnieje. Stworzenie na nowo tabeli prowadzi do tego że widok odnosi
się do wierszy nowo-powstałej tabeli:




drop table employees3go
          (Ta komenda nie
zwraca żadnej wartości)sp_help
namebadge3go




Name
Owner
Type


----------------------
-------
---------


namebadge3
dbo
view


(1 row(s) affected)






Data_located_on_segment
When_created


------------------------------
---------------------------


not applicable
Oct 2 1994 11:45AM




Column_name
Type
Length
Nulls
Default_name
Rule_name


---------------
-------------
-------
------
--------------
------------


name
char
25
0
(null)
(null)


badge
int
4
0
(null)
(null)


No   defined
keys   for
this
object.





select * from namebadge3goMsg 208, Level 16,
State 1Invalid object name 'employees3'.Msg 4413, Level 16, State
1
Obiekty muszą być na nowo stworzone tak aby widok był użyteczny:




create table employees3(name
char(25),department char(20),badge int)go
           (Komenda nie
zwraca żadnej wartości)insert into employees3select
* from employeesgo(12 row(s) affected)select
* from namebadge3where name='Anna
Nowak'go




name
badge


-------------------------
-----------


Anna Nowak
9998


(1 row(s) affected)

Jeżeli użyjemy definicji SELECT razem z gwiazdką (*) aby
wyspecyfikować kolumny, to nowe kolumny dodane do tabeli z konstrukcją ALERT
TABLE nie będą widoczne w starym widoku. Nowe kolumny będą widoczne kiedy
widok zostanie zainicjowany jeszcze raz.
W poniższym przykładzie widok jest zdefiniowany z gwiazdką (*) w konstrukcji
SELECT tak że zwraca wszystkie kolumny tabeli Employees. Po
dodaniu kolumny do tabeli z wykorzystaniem konstrukcji ALERT TABLE, widok
nie będzie wyświetlał pustych wartości w nowo dodanej kolumnie. Nowa kolumna
nazwana Wageclass będzie dostępna w widoku dopiero po ponownym
zainicjowaniu tego widoku:




sp_helptext
sales3gotext-------------------create view
sales3asselect * from employees3where
department='SALES'go(1 row(s) affected)select *
from sales3go




name
department
badge


--------------------------
---------------
--------


Fred Sanders
SALES
1051


Bob Orieda
SALES
1834


(2 row(s) affected)






alter table employees3add wageclass int nullgo
            
(Komenda nie zwraca żadnej wartości)select * from
sales3go




name
department
badge


--------------------------
---------------
--------


Fred Sanders
SALES
1051


Bob Orieda
SALES
1834


(2 row(s) affected)






select * from employees3where
department='SALES'go




name
department
badge
wageclass


--------------------------
---------------
--------
--------


Fred Sanders
SALES
1051
(null)


Bob Orieda
SALES
1834
(null)


(2 row(s) affected)







drop view sales3go
           (Komenda nie
zwraca żadnej wartości)create view sales3 asselect *
from employees3where department='SALES'go
           (Komenda nie
zwraca żadnej wartości) select * from
sales3go




name
department
badge
wageclass


--------------------------
---------------
--------
--------


Fred Sanders
SALES
1051
(null)


Bob Orieda
SALES
1834
(null)


(2 row(s) affected)





Data ostatniej modyfikacji 6.II.2000.Wszelkie uwagi mile widziane