28460 ullman183 (2)

Dl/. 5 JIjZYK BAZ DANYCH SQI.

Warunki te zapiszemy za pomocą instrukcji WITH, mimo że narusza ona w tym przypadku wymagania monotoniczności nakładane przez SQL3. Zapytanie przedstawione na rys. 5.26 służy do wyliczenia wartości relacji P.

1)	WITH
2)	RECURSIVE P(x) AS
3)	(SELECT *	FROM	R)
4)	UNION
5)	(SELECT *	EROM	Q>
6)	RECURSIVE Q(x) AS
7)	SELECT SUM{*)	FROM	P
8)	SELECT * EROM ?;

RYSUNEK 5.26

Niedozwolone zapylanie niewarsiwowe obejmujące agregację w $QL3

Załóżmy teraz, że relacja R składa się z krotek 12) i 34), a relacje P i Q na początku obliczeń są puste, ponieważ tak musi być zawsze na początku obliczeń punktu stałego. Na rysunku 5.27 zestawiono w tabeli wartości obliczone w pierwszych sześciu iteracjach. Przypomnijmy tu, że stosujemy zasadę, że wdanej iteracji korzysta się z wartości wyliczonych w iteracji poprzedniej. A zatem po pierwszej iteracji P staje się równe relacji R, a Q jest pusta, ponieważ do wyliczeń w wierszu 7) używa się starej wartości P, która jest pusta.

Iteracja	P	Q
1)	{(12), (34)}	0
2}	{(12), (34)}	{ (46) }
3)	{(12), (34), (46)}	{(46)}
4}	{(12), (34), (46)}	{(92)}
5)	{(12), (34), (92)}	{(92)}
6)	{(12), (34), (92)}	{(92)}

RYSUNEK 5.27

Obliczenie iteracyjne punktu stałego agregacji nicmonotonicznej

W drugiej iteracji suma określona w wierszach od 3) do 5) jest taka sama jak relacja R = {(12), (34)} i ona stanowi nową wartość relacji P. Stara wartość P była taka sama, a więc w drugiej iteracji Q - {(46)}, ponieważ 46 jest sumą wartości 12 i 34.

Z kolei w trzeciej iteracji otrzymujemy P= {(12), (34), (46)} z wyliczenia zgodnego z zapisem w wierszach od 2) do 5). A relacja Q, wyliczana w wierszach 6) i 7) na podstawie poprzedniej wartości P = {(12), (34)}, pozostaje bez zmian.

W czwrtej iteracji natomiast relacja P nic zmienia wartości, za to relacja O otrzymuje wartość {(92)}, ponieważ 12 + 34 - 46 - 92. Zauważmy, żc z relacji Q przy dołączenia krotki (92) została usunięta poprzednia krotka (46). Można zauważyć również, że dołączenie krotki (46) do relacji P spowodowało, że została usunięta krotka (przez przypadek ta sama krotka) z relacji Q. Uzewnętrznia się tutaj zatem brak monotoniczności, zabroniony w reku-rencyjnych definicjach w SQL3, co potwierdza, że zapytanie przedstawione na rysunku 5.26 jest niedozwolone. W tym przypadku w każdej iteracji o numerze 2i relacja P składa się z krotek (12), (34) oraz (46/ - 46), a relacja Q tylko z jednej krotki (46/).

□

Korzystanie z nowych wartości w trakcie obliczeń punktu stałego

Można by się zastanawiać dlaczego w przykładach 5.57 i 5.58 do wyliczenia wartości Q używa się raczej starych wartości relacji P, a nie nowych. Wynik byłby wówczas zależny od kolejności zapisania definicji w klauzuli with. W przykładzie 5.57 P i O byłyby zbieżne do jednego z dwóch punktów stałych, zależnie od kolejności przetwarzania. A w przykładzie 5.58 P i Q w dalszym ciągu nic byłyby zbieżne, a ich wartości zmieniałyby się w każdej iteracji, a nie w co drugiej.

5.10.6. Ćwiczenia do podrozdziału 5.10

Ćwiczenie 5.10.1. W przykładzie 4.36 była omawiana następująca relacja:

Kolejny(film, odcinek)

przeznaczona do zapisu kolejnych odcinków filmów. Zdefiniowaliśmy talcze relację Następny typu 1DB, zawierającą takie pary (x, y), w których y był albo kolejnym odcinkiem filmu x, albo następował po pewnym innym kolejnym odcinku x.

a)    Należy zapisać definicję relacji Następny, używając rekurencji SQL3.

b)    Należy utworzyć rekurencyjne zapytanie SQL3, w wyniku którego otrzymuje się pary (x,y) takie, że>- następuje po ale nie jest bezpośrednim kolejnym odcinkiem po x.

c)    Należ)' utworzyć rekurencyjne zapytanie SQL3, w wyniku którego otrzymuje się pary (x, >•) takie, że y następuje po .v, ale ani nie jest bezpośrednim kolejnym odcinkiem po x, ani nie jest bezpośrednio kolejnym po bezpośrednio kolejnym.

!d) Należ)’ utworzyć rekurencyjne zapytanie SQL3, w wyniku którego otrzymuje się te filmy x, które mają co najmniej dwa kolejne odcinki. Oba mają być kolejnymi odcinkami bezpośrednio po x, a nie kolejnymi kolejnych.

!e) Należy utworzyć rekurencyjne zapytanie SQL3, w wyniku którego otrzymuje się pary (x, y) takie, że y następuje po ale poy następuje co najwyżej jeden kolejny odcinek.