ullman147 (2)

ullman147 (2)



300 5. JĘZYK BAZ DANYCH SOL

krotkowych. Dla każdego przypisania jest określana wartość warunku z klauzuli WHERE. Wartości z krotek wszystkich tych przypisań, przy któ-rych klauzula WHERE przybiera wartość TRUE, są dołączane do wyniku, tzn. z wartości atrybutów występujących w klauzuli SELECT są tworzone krotki wyniku.

Interpretacja w języku SQL i w Datalogu

Warto zauważyć podobieństwo między drugą z podanych interpretacji zapytań selcct-from-where a interpretacją reguł Datalogu, która została opisana w p. 4.2.4. W przypadku Datalogu rozważaliśmy wszystkie możliwe przypisania krotek z relacji do odpowiednich zmiennych w po-dzadaniach w tekście reguły. Z kolei w $QL rozważa się wszystkie możliwe przypisania krotek do zmiennych krotkowych. W obu przypadkach o dołączeniu powstających nowych krotek rozstrzyga spełnienie warunku określonego w podzadaniu arytmetycznym (części klauzuli WHERE w SQL). Postać krotki jest określona w nagłówku reguły (w klauzuli SELECT w SQL).


Przejście do postaci algebry relacji

Trzeci sposób polega na znalezieniu wyrażenia algebry relacji równoważnego danemu zapytaniu w $QL. Tutaj rozpoczynamy od utworzenia iloczynu kartezjańskiego relacji z klauzuli FRGM. Jeśli w klauzuli FROM dwie zmienne krotkowe oznaczają tę samą relację, to w iloczynie kartezjańskim ta relacja wystąpi dwa razy, a jej atrybuty trzeba przemianować w ten sposób, aby można je było odróżniać. Atrybuty z różnych relacji, które mają takie same nazwy, również trzeba przemianować po to. by uniknąć niejednoznaczności.

Po utworzeniu iloczynu kartezjańskiego przekształcamy klauzulę WHERE w warunek wyboru i stosujemy operator selekcji z tak określonym warunkiem. Każdy atrybut, który występuje w klauzuli WHERE, zostaje zastąpiony odpowiednim atrybutem z iloczynu kartezjańskiego. W końcu na podstawie klauzuli SELECT zostaje określona lista atrybutów dla operatora rzutowania. Sposób określenia tych atrybutów jest taki sam jak w przypadku atrybutów określanych dla operatora selekcji: każdy atrybut z klauzuli SELECT zostaje zastąpiony odpow iednim atrybutem z iloczynu kartezjańskiego*.

PRZYKŁAD 5.13

Zapiszmy zapytanie z przykładu 5.12 w postaci wyrażenia algebraicznego. Najpierw określimy iloczyn kartezjański relacji, których zmienne krotkowe

‘ W algebrze relacji nic jest dopuszczalne wyrażenie arytmetyczne, które może wystąpić w klauzuli SELECT w SQL (porównaj przykład 5.4). Jednakże wiadomo, w jaki sposób można rozszerzyć operator rzutu w algebrze relacji, i tylko ze względu na tradycje utrzymuje się ograniczoną definicję lego operatora.

występują w klauzuli B ROM, obie wskazujące relację Gwiazda. Nasze wyrażenie zaczyna się zatem od następującej frazy:

Gwiazda * Gwiazda

W relacji wynikowej jest osiem atrybutów, pierwsze cztery to atry buty pierwszej kopii relacji Gwiazda, tj. nazwisko, adres, płeć oraz dataurodze-nia, pozostałe cztery to takie same atrybuty, które pochodzą z drugiej kopii tej relacji. Nazwy atrybutów w nowej relacji mogłyby zostać utworzone zgodnie ze znaną konwencją poprzedzenia nazwy atry butu synonimem nazwy relacji i kropką, ale będziemy je w tym przypadku skrótowo oznaczać A\, A2l .... A$. A więc A] odpowiada atrybutowi Gwiazdal.nazwisko, A5 atrybutowi Gwiazda2. nazwisko itd.


Niezgodne z intuicją konsekwencje semantyki języka SQL

Załóżmy, że R, S i T oznaczają relacje unarne (z jednym atrybutem), każda z nich ma jeden atrybut zl, a zadanie polega na określeniu tych krotek, które są zarówno w R, jak i w S lub T (lub w obu na raz). A zatem zadanie polega na określeniu wartości wyrażenia R n (S kj T). Można by pomyśleć, żc wynik tego wyrażenia jest dobrze opisany następującym zapytaniem w SQL:

SELECT R.A

FROM R, S, T

WHERE R.A = S.A OR R.A = T.A

Co się jednak stanie, gdy relacja T będzie zbiorem pustym? Ponieważ w arunek R.A - T.A nigdy nic będzie spełniony, więc można by zgodnie z intuicją dotyczącą operatora OR oczekiwać, że w wyniku zapytania powstanie zbiór R n S. A jednak, bez względu na to, który sposób interpretowania wyrażenia w SQL wybierzemy spośród sposobów opisanych wp. 5.2.4, to okaże się żc wynikowa relacja będzie zbiorem pusty m, niezależnie od tego, jak dużo wspólnych elementów występuje w relacjach i S. Jeśli zastosujemy semantykę opisaną na rys. 5.2, to okaże się, że pętla ze zmienną relacji T wykonuje się 0 razy, ponieważ w T nie ma żadnej krotki, a więc zakres zmiennej kontrolowanej jest pusty. A zatem warunek w instrukcji if nigdy nic zostanie sprawdzony i żadna krotka nie zostanie utworzona. Podobnie dzieje się, gdy chcemy określić przypisania krotek do zmiennych krotkowych. Ponieważ nie ma co przypisać do zmiennej T, więc nie ma możliwości określić jakiegokolwiek przypisania. Na koniec, jeśli stosujemy semantykę iloczynu kartezjańskiego, to zaczynamy od policzenia iloczynu kartezjańskiego R x S x 1. a ten iloczy n jest pusty, ponieważ zbiór Tjest pusty-.



Wyszukiwarka

Podobne podstrony:
ullman166 (2) 338 1 5. JĘZYK BAZ DANYCH SOL Ponieważ para (tytuł, rok) jest kluczem, więc mamy
ullman156 (2) J 18 5. JEŻYK BAZ DANYCH SOL Zauważmy, że w tym zapytaniu wcale nie ma klauzuli WHERE,
ullman145 (2) 296 5. JĘZYK BAZ DANYCH SOL W wyniku tego zapytania zostają przeszukane pary krotek, p
64863 ullman149 (2) 304 S JEŻYK BAZ DANYCH SOL GwiazdyW, ale filmu, który tam wymieniono, nie ma w r
ullman165 (2) 5. JEŻYK BAZ DANYCH SOL Teraz deklarując schemat relacji Film, możemy /.definiować atr
ullman141 (2) 288 5 JĘZYK BAZ DANYCH SQI. W przykładzie 5.1 występuje porównanie: nazwaStudia = Dis

więcej podobnych podstron