You are on page 1of 3

Pogledi u MySQL-u

Sintaksa:
CREATE
[OR REPLACE]
[ALGORITHM = {UNDEFINED | MERGE | TEMPTABLE}]
[DEFINER = { user | CURRENT_USER }]
[SQL SECURITY { DEFINER | INVOKER }]
VIEW view_name [(column_list)]
AS select_statement
[WITH [CASCADED | LOCAL] CHECK OPTION]

CREATE VIEW iskaz kreira novi pogled, a ako je navedena klauzula OR REPLACE onda se
zamjenjuje postojeći pogled. Ako pogled ne postoji onda je iskaz CREATE OR REPLACE VIEW
isti kao CREATE VIEW. Ako pogled postoji tada iskaz CREATE OR REPLACE VIEW
zamjenjuje taj pogled.
Opciona ALGORITHM klauzula je MySQL ekstenzija standardong SQL-a. Ona utiče na način na
koji MySQL procesira pogled. ALGORITHM uzima tri vrijednosti: MERGE, TEMPTABLE ili
UNDEFINED.
Za MERGE, tekst iskaza koji se odnosi na pogled i definicija pogleda su spojeni tako da dijelovi
definicije pogleda zamjenjuju korespondirajuće dijelove iskaza.
Za TEMPTABLE, rezultati iz pogleda se smještaju u privremenu tabelu koja se onda koristi za
izvršavanje iskaza.
Za UNDEFINED, MySQL bira koji će algoritam koristiti. On preferira MERGE prije
TEMPTABLE ukoliko je to moguće, jer MERGE je obično efikasniji i zato što pogled ne može
biti ažuriran ukoliko se koristi privremena tabela.
Razlog za eksplicitno specificiranje TEMPTABLE algoritma je to što lock-ovi na osnovne tabele
mogu biti oslobođeni nakon kreiranja privremene tabele, a prije njenog korištenja za završetak
procesiranja iskaza. Ovo može rezultovati u bržem oslobađanju lock-a u odnosu na MERGE
algoritam, tako da drugi klijenti koji koriste pogled ne moraju tako dugo da čekaju.
Algoritam za procesiranje pogleda može biti UNDEFINED iz tri razloga:
 ALGORITHM klauzula nije specifikovana u CREATE VIEW iskazu
 CREATE VIEW iskaz ima eksplicitnu ALGORITHM = UNDEFINED klauzulu
 ALGORITHM = MERGE je specifikovano za pogled koji može biti procesuiran samo
pomoću privremene tabele. U ovom slučajnu MySQL generiše upozorenje i postavlja
algoritam na UNDEFINED
Definicija pogleda je „zamrznuta“ u trenutku kreiranja i naknadne promjere osnovnih tabela neće
uticati na tu definiciju. Na primjer, ukoliko je pogled definisan sa SELECT * na tabeli, ako se
nakon toga dodaju nove kolone u tabelu onda one neće biti dio pogleda. Takođe, ukoliko se vrši
selekcija iz pogleda nad kolonama koje su u međuvremenu obrisane, javiće se greška.
Pogled mora imati jedinstvene nazive kolona, baš kao i osnovne tabele. Podrazumijevano, nazivi
kolona dobijeni SELECT iskazom se koriste kao nazivi kolona pogleda. Za eksplicitnu
specifikaciju naziva kolona koristi se column_list opciona klauzula. Broj naziva u column_list
mora odgovarati broju kolona dobijenih SELECT iskazom.
DEFINER i SQL SECURITY klauzule određuju koji MySQL nalog će biti korišten prilikom
provjere prava pristupa kada se izvršava iskaz koji referencira pogled. Validne SQL SECURITY
karakteristične vrijednosti su DEFINER (podrazumijevano) i INVOKER.
Ako je user vrijednost dodijeljena u DEFINER klauzuli, to treba da bude MySQL nalog
specifikovan kao 'user_name'@'host_name', CURRENT_USER ili CURRENT_USER().
Podrazumijevana DEFINER vrijednost je korisnik koji izvršava CREATE VIEW iskaz. Ovo je
isto kao kada se eksplicitno specifikuje DEFINER = CURRENT_USER.
Ako je DEFINER klauzula prezentovana, sljedeća pravila određuju validne DEFINER vrijednosti:
 Ako korisnik nema SET_USER_ID ili SUPER privilegije onda je jedina validna user
vrijednost nalog korisnika, bilo da je specifikovan doslovno ili koristeći
CURRENT_USER. Korisnik u tom slučaju ne može postaviti neki drugi nalog kao
DEFINER vrijednost
 Ako korisnik ima SET_USER_ID ili SUPER privilegije onda on može specifikovati bilo
koje sintaksički ispravno ime naloga. Ukoliko nalog ne postoji pojaviće se upozorenje.
 Iako je moguće kreirati pogled sa nepostojećim DEFINER nalogom, pojaviće se greška
ukoliko se pogled referencira, a da je pritom vrijednost klauzule SQL SECURITY
postavljena na DEFINER.
Ukoliko je vrijednost SQL SECURITY klauzule DEFINER, tada se za provjeru prava pristupa
prilikom referenciranja pogleda koristi nalog koji je definisao pogled. Na primjer, ukoliko korisnik
koji referencira pogled nema SELECT privilegiju na nekoj osnovnoj tabeli, a DEFINER ima
privilegiju SELECT na toj osnovnoj tabeli, tada će korisniku koji referencira pogled biti
omogućeno izvršavanje SELECT iskaza, jer se provjerava da li DEFINER ima određene
privilegije. S druge strane, ukoliko je vrijednost SQL SECURITY klauzule INVOKER, tada se za
provjeru prava pristupa prilikom referenciranja pogleda koristi nalog korisnika koji referencira
pogled. Ukoliko taj korisnik nema određene privilegije za pristup osnovnoj tabeli onda će tom
korisniku biti onemogućen pristup.
Kroz poglede je moguće izvršiti ažuriranje osnovnih tabela. Na primjer, neka imamo definisan
sljedeći pogled:
create view predmeti_6_ECTS as select * from predmet where ECTS = 6.
Tabelu predmet je moguće ažurirati kroz pogled predmeti_6_ECTS. Prema tome validan je sljedeći
iskaz:
insert into predmeti_6_ECTS values (2277, „Interkacija čovjek-računar“, „O“, 7).
Ovim iskazom se kroz pogled predmeti_6_ECTS dodaje predmet „Interakcija čovjek-računar“,
koji je obavezan i ima 7 ECTS bodova. Ako bi se izvršio sljedeći upit:
select * from predmeti_6_ECTS,
onda se u rezultatu ne bi pojavio predmet „Interakcija čovjek-računar“. Kako bi se spriječilo
dodavanje redova kroz pogled, a da se pritom ti redovi kroz taj pogled ne mogu vidjeti, koristi se
opcija with check option. Ova opcija omogućava provjeru uslova iz definicije pogleda, pa prema
tome bi kroz pogled predmeti_6_ECTS bilo moguće dodati samo predmete koji imaju 6 ECTS
bodova. Uz with check option se mogu dodati ključne riječi cascade ili local. Local omogućava
provjeru uslova iz definicije samo onog pogleda koji se referencira, dok cascade opcija omogućava
kaskadnu provjeru uslova iz definicija onih pogleda nad kojim je definisan referencirani pogled.
Podrazumijevana opcija je cascade.

You might also like