Język SQL – transakcje, perspektywy, indeksy

BAZY DANYCH – wykład 6
Język SQL –
transakcje, perspektywy, indeksy
Dr hab. Sławomir Zadrożny, prof. PR
Do czego służą transakcje ?
Systemy zarządzania bazą danych (DBMS)
zazwyczaj zezwalają na jednoczesny dostęp
do danych wielu użytkowników.
Zapytania i modyfikacje.
DBMS musi zapobiec niepożądanym
interakcjom pomiędzy działaniami
użytkowników i zapewnić poprawne działanie
również w sytuacjach awaryjnych
Bazy danych – wykład 6
2
Przykład: niepożądanej interakcji
Dwie osoby jednocześnie podejmują 100 PLN
z tego samego konta (za pośrednictwem
dwóch bankomatów) – należy zapewnić
odpowiedni stan konta po tych operacjach
(zmniejszony o 200 PLN, a nie np. o 100 PLN)
Inny przykład: system realizuje przelew z
jednego konta na drugie i po zmniejszeniu
stanu pierwszego występuje awaria –
pieniądze nie mogą „zaginąć” !
Bazy danych – wykład 6
3
Transakcje
Transakcja = sekwencja operacji na
bazie danych (lub proces ją realizujący)
Zazwyczaj z jawnie określonymi
regułami interakcji z innymi
transakcjami
W języku SQL transakcje mogą być
wyróżniane domyślnie lub za pomocą
jawnie użytych instrukcji sterujących
Bazy danych – wykład 6
4
ACID – pożądane własności transakcji
Atomic : wykonać się może jedynie w całości lub w ogóle
(DBMS jest odpowiedzialny za zapewnienie)
Consistent : zachowują poprawność zawartości bazy danych
(DBMS może wymusić ograniczenia określone w bazie
danych, ale logika aplikacji musi być też prawidłowa)
Isolated : transakcje muszą być realizowane niezależnie:
częściowe efekty realizacji transakcji T1 nie powinny
wpływać na wynik działania transakcji T2 (nie powinny być
„widoczne” dla transakcji T2) - DBMS odpowiedzialny
Durable: mają trwały charakter i jeśli się zakończyły, to ich
wynik zostanie zachowany nawet w przypadku sytuacji
awaryjnych (DBMS)
Bazy danych – wykład 6
5
Zatwierdzenie transakcji - COMMIT
W języku SQL instrukcja COMMIT
sygnalizuje jawne zakończenie transakcji i
trwałe zapisanie jej efektów w bazie
danych
Bazy danych – wykład 6
6
Odwołanie transakcji - ROLLBACK
W języku SQL instrukcja ROLLBACK
sygnalizuje zakończenie transakcji i
odwołanie efektów jej działania – baza
danych powinna pozostać w stanie sprzed
rozpoczęcia realizacji transakcji
Pewne błędy takie, jak dzielenie przez zero
lub naruszenie ograniczeń (constraint) mogą
wywołać automatyczne zakończenie
transakcji i odwołanie efektów jej działania
Bazy danych – wykład 6
7
Przykład
Załóżmy, że w tabeli Sells(bar,beer,price)
zawarta jest informacja, że bar Joe’s Bar
sprzedaje wyłącznie piwo marki Bud za $2.50 i
piwo marki Miller za $3.00
Sally wyszukuje w tabeli Sells najwyższą i
najniższą cenę piwa sprzedawanego przez Joe’s
Bar
W tym czasie Joe’s Bar przestaje sprzedawać
Bud i Miller, a zamiast nich sprzedawać zaczyna
wyłącznie piwo marki Heineken za $3.50, i Joe
wprowadza tę informację do tabeli Sells
Bazy danych – wykład 6
8
Sekwencja instrukcji Sally
Sally wykonuje następujące dwie
instrukcje SQL oznaczone dalej jako
(min) i (max) :
(max)
SELECT MAX(price) FROM Sells
WHERE bar = ’Joe’’s Bar’;
(min)
SELECT MIN(price) FROM Sells
WHERE bar = ’Joe’’s Bar’;
Bazy danych – wykład 6
9
Sekwencja instrukcji Joe
W tym samym czasie Joe wykonuje
następujące dwie instrukcje, oznaczone
jako (del) i (ins).
(del) DELETE FROM Sells
WHERE bar = ’Joe’’s Bar’;
(ins) INSERT INTO Sells
VALUES(’Joe’’s Bar’, ’Heineken’, 3.50);
Bazy danych – wykład 6
10
Przeplatanie się instrukcji
Jeśli chodzi o kolejność wykonania
pokazanych czterech instrukcji, jedyne
czego można być pewnym to to, że:
(max) wykona się przed (min), i
(del) wykona się przed (ins)
Żeby uzyskać oczekiwany efekt ich
łącznego wykonania musimy pogrupować
instrukcje Sally i Joe w w transakcje
Bazy danych – wykład 6
11
Przykład: niepożądana kolejność
Załóżmy, że instrukcje zostaną wykonane
w tej kolejności: (max)(del)(ins)(min)
{3.50}
Ceny u Joe: {2.50,3.00} {2.50,3.00}
(max)
(del)
(ins)
(min)
Instrukcja:
3.00
3.50
Wynik:
Sally zobaczy, że MAX < MIN!
Bazy danych – wykład 6
12
Poziomy izolacji transakcji
W SQLu zdefiniowano cztery poziomy izolacji
transakcji (ang. isolation levels), określające
dopuszczalny stopień interakcji pomiędzy nimi
Im bardziej ograniczony zakres interakcji tym
lepsze własności (ACID!), ale mniejsza liczba
możliwych do wykonania równolegle instrukcji !
Najbardziej restrykcyjny poziom nosi nazwę
“serializable” – tylko takie transakcje posiadają
własności ACID.
Różny sposób implementacji transkacji przez
różne DBMS.
Bazy danych – wykład 6
13
Poziomy izolacji transakcji (2)
W niektórych implementacjach SQL
dostępna jest instrukcja:
SET TRANSACTION ISOLATION LEVEL X
gdzie X =
1.
2.
3.
4.
SERIALIZABLE
REPEATABLE READ
READ COMMITTED
READ UNCOMMITTED
Bazy danych – wykład 6
14
Transakcja typu „read uncommitted”
Wróćmy do transakcji Sally = (max) (min) i
Joe’go = (del)(ins)
Transakcja oznaczona jako READ
UNCOMMITTED „widzi” wszelkie zmiany
dokonywane przez inne transakcje, łącznie z
tymi niezatwierdzonymi.
Przykład: Jeśli transakcja Sally jest oznaczona
jako READ UNCOMMITTED, to może ona
zobaczyć cenę 3.50 nawet jeśli Joe odwoła
swoją transakcję (tzw. „dirty read”)
Bazy danych – wykład 6
15
Transakcje typu „read-commited”
Jeśli transakcja Sally oznaczona jest jako
READ COMMITTED, to widzi ona tylko
zatwierdzone dane, ale niekoniecznie
zawsze te same.
Przykład: przy tym poziomie izolacji
przeplatanie się instrukcji jest dozwolone,
np. (max)(del)(ins)(min); jeśli transakcja
Joe’go jest zatwierdzona (COMMIT), to
Sally zobaczy MAX < MIN.
Bazy danych – wykład 6
16
Transakcje typu „repeatable-read”
Transakcja widzi tylko zatwierdzone dane +
jeśli dane są odczytywane wielokrotnie, to są
one za każdym razem identyczne (w sensie
zawartości odczytanych krotek), ale przy
kolejnych odczytach można otrzymać więcej
krotek (ang. phantom tuples)
Bazy danych – wykład 6
17
Przykład: „repeatable read”
Załóżmy, że transakcja Sally jest
oznaczona jako REPEATABLE READ, i
kolejność wykonania instrukcji jest
następująca: (max)(del)(ins)(min)
(max) widzi ceny 2.50 i 3.00
(min) widzi cenę 3.50, ale musi również
widzieć ceny 2.50 i 3.00, ponieważ były
one wcześniej widoczne dla (max)
Bazy danych – wykład 6
18
Transakcje typu „serializable”
Jeśli Sally wykonuje swoją transakcję
(max)(min) z poziomem izolacji
SERIALIZABLE, to jej transakcja będzie
widziała zawartość bazy danych
sprzed lub po wykonaniu transakcji
Joe’go (del)(ins), ale nie pomiędzy.
Czyli transakcja Sally wykonuje się
tak, jakby jej instrukcje wykonywane
były kolejno i nieprzeplatane
instrukcjami żadnej innej transakcji
Bazy danych – wykład 6
19
Poziom izolacji transakcji (3)
Poziom izolacji dotyczy transakcji, która
go określa, a nie pozostałych.
Przykład: Jeśli transakcja Joe’go jest
oznaczona jako serializable, a transakcja
Sally nie, to Sally może odczytać
zawartość bazy danych w chwili, gdy nie
ma żadnych cen piwa dla baru Joe’s Bar.
Bazy danych – wykład 6
20
Perspektywy (views)
Perspektywa jest pseudotabelą zdefiniowaną z
odwołaniem do tabel (zwanych też tabelami
bazowymi) oraz do innych pseudotabel.
Dwa rodzaje:
1. „wirtualne”= nie są one zapisywane w bazie danych;
mają postać zapytania, które po uruchomieniu zwraca
tabelę.
2. materialized = wynik zapytania jest zapisywany w
bazie
Bazy danych – wykład 6
21
Deklarowanie perspektyw
CREATE [MATERIALIZED] VIEW
<name> AS <query>;
Domyślnie tworzona jest perspektywa
wirtualna
Bazy danych – wykład 6
22
Przykład: deklaracja perspektywy
CanDrink(drinker, beer) jest perspektywą
„zawierającą” pary klient-piwo, takie że dany
klient odwiedza przynajmniej jeden bar, w
którym sprzedawane jest dane piwo:
CREATE VIEW CanDrink AS
SELECT drinker, beer
FROM Frequents, Sells
WHERE Frequents.bar = Sells.bar;
Bazy danych – wykład 6
23
Przykład: używanie perspektywy
Perspektywę można przeszukiwać tak samo
jak tabelę bazową
W ograniczonym stopniu dopuszczalne jest
również modyfikowanie zawartości perspektyw, o
ile w rozsądny sposób tłumaczy się ono na
modyfikowanie jednej z tabel bazowych, do
których odwołuje się perspektywa.
Przykład zapytania względem perspektywy:
SELECT beer FROM CanDrink
WHERE drinker = ’Sally’;
Bazy danych – wykład 6
24
Materialized Views
Problem: za każdym razem kiedy
zmieniana jest tabela bazowa może to
wymagać zmiany w materialized view.
Zbyt kosztowne jest rekonstruowanie
zawartości takiej perspektywy przy
każdorazowej zmianie tabel bazowych.
Rozwiązanie: Regularne automatyczne
rekonstruowanie materialized view.
Bazy danych – wykład 6
25
Indeksy
Index = struktura danych używana do
przyspieszenia dostępu do danych na
podstawie zawartości ich jednej lub kilku
kolumn.
Różne typy (łącznie z np. tablicą haszującą),
ale w DBMS najpopularniejsze są
zrównoważone drzewa wyszukiwań, a w
szczególności B-drzewa.
Bazy danych – wykład 6
26
Tworzenie indeksów
Przykład typowej składni:
CREATE INDEX BeerInd ON
Beers(manf);
CREATE INDEX SellInd ON
Sells(bar, beer);
Bazy danych – wykład 6
27
Użycie indeksów
Dla zadanej wartości v kolumny a, na
podstawie indeksu możemy szybko
dotrzeć do wierszy tabeli, w których w
kolumnie a występuje wartość v.
Przykład: z użyciem indeksów BeerInd i
SellInd odnaleźć ceny marek piwa
produkowanych przez browar Pete’s i
sprzedawanych przez bar Joe’ego.
Bazy danych – wykład 6
28
Użycie indeksów --- (2)
SELECT price FROM Beers, Sells
WHERE manf = ’Pete’’s’ AND
Beers.name = Sells.beer AND
bar = ’Joe’’s Bar’;
1. Użyj indeksu BeerInd do znalezienia
wszystkich marek piwa produkowanych
przez browar Pete’s.
2. Następnie, użyj indeksu SellInd do
znalezienia cen tych marek piwa w barze
Joe’s Bar
Bazy danych – wykład 6
29
Dostrajanie bazy danych
Właściwy dobór indeksów ma istotne znaczenie
dla szybkości działań na bazie danych
Zalety: istnienie indeksu przyspiesza
wykonanie zapytań, które odnoszą się do
indeksowanych wartości
Wady: istnienie indeksu spowalnia dodawanie,
usuwanie i modyfikowanie wierszy w tabeli,
której dotyczy, gdyż indeks musi zostać
również zmodyfikowany
Bazy danych – wykład 6
30