Professional Documents
Culture Documents
Relacyjne Bazy Danych Dla Praktyków
Relacyjne Bazy Danych Dla Praktyków
PRZYKADOWY ROZDZIA
SPIS TRECI
KATALOG KSIEK
KATALOG ONLINE
ZAMW DRUKOWANY KATALOG
TWJ KOSZYK
DODAJ DO KOSZYKA
CENNIK I INFORMACJE
ZAMW INFORMACJE
O NOWOCIACH
ZAMW CENNIK
CZYTELNIA
FRAGMENTY KSIEK ONLINE
Wydawnictwo Helion
ul. Chopina 6
44-100 Gliwice
tel. (32)230-98-63
e-mail: helion@helion.pl
Spis treci
Sowo wstpne .............................................................................................................. 9
Przedmowa ................................................................................................................... 11
1. Wprowadzenie .............................................................................................................17
Uwaga na temat terminologii
Zasady, nie produkty
Podstawy oryginalnego modelu
Model a implementacja
Wasnoci relacji
Relacje i zmienne relacyjne
Wartoci i zmienne
Podsumowanie
wiczenia
18
19
20
27
29
32
33
34
35
40
44
47
49
51
52
55
57
59
60
61
66
69
70
70
73
75
77
78
83
86
88
89
93
95
102
103
107
109
111
114
115
117
117
6. Ograniczenia ..............................................................................................................123
Ograniczenia oparte na typach
Ograniczenia baz danych
Transakcje
Dlaczego kontrola ogranicze baz danych musi by natychmiastowa
Czy niektre kontrole nie powinny jednak by odoone?
Ograniczenia i predykaty
Rne uwagi
Podsumowanie
wiczenia
123
126
129
130
132
134
136
138
139
Spis treci
144
146
151
158
161
164
165
167
172
175
176
177
180
184
185
189
191
192
194
195
199
201
202
203
B .................................................................................................................................... 205
Algebra relacyjna i operatory modyfikujce
Baza danych dostawcw i czci zamiennych
206
207
212
218
225
230
244
251
259
Spis treci
ROZDZIA 4.
Zmienne relacyjne
W rozdziale 1. poznalimy pojcie zmiennej relacyjnej, ktrej wartoci s relacjami. To wanie zmienne relacyjne powstaj w wyniku dziaania operacji INSERT, DELETE czy UPDATE.
Dowiedzielimy si te, e INSERT, DELETE oraz UPDATE s odpowiednikami relacyjnych
operacji przypisania. Przypominam, e jeli R jest zmienn relacyjn, a r jest relacj, ktra ma
by przypisana R, wtedy R i r musz by zgodnego typu relacyjnego. Druga wana informacja to taka, e nagwki, zawarto, atrybuty, krotki, liczno i stopie zdefiniowane formalnie na
potrzeby relacji (rozdzia 3.) maj zastosowanie rwnie do zmiennych relacyjnych. Nadszed
czas, aby przyjrze si bliej tym zagadnieniom. Jako podstaw do rozwaa wykorzystam
nastpujce definicje relacji z bazy dostawcw i czci zamiennych napisane w jzyku
Tutorial D:
VAR S BASE RELATION
{SNO SNO, SNAME NAME, STATUS INTEGER, CITY CHAR}
KEY {SNO};
VAR P BASE RELATION
{PNO PNO, PNAME NAME, COLOR COLOR, WEIGHT WEIGHT, CITY CHAR }
KEY {PNO};
VAR SP BASE RELATION
{SNO SNO, PNO PNO, OTY OTY}
KEY {SNO, PNO}
FOREIGN KEY {SNO} REFERENCES S
FOREIGN KEY {PNO} REFERENCES P;
Operacje modyfikujce
Pierwsze wane spostrzeenie dotyczy przypisania. Niezalenie od zastosowanej skadni
przypisanie relacyjne jest operacj na poziomie zbiorw. W rzeczywistoci wszystkie operacje
zdefiniowane w modelu relacyjnym odbywaj si na poziomie zbiorw, do czego wrcimy
w rozdziale 5. Oznacza to, e INSERT dodaje do zmiennej relacyjnej zbir krotek, DELETE
usuwa ze zmiennej relacyjnej zbir krotek, natomiast UPDATE modyfikuje zbir krotek
zmiennej relacyjnej. Czsto co prawda mwi si, e modyfikuje si jak konkretn krotk,
naley jednak zawsze pamita o tym, e:
takie stwierdzenie oznacza, e modyfikowany zbir krotek ma liczno rwn jeden;
aktualizacja zbioru krotek o licznoci rwnej jeden czasem nie jest operacj wykonaln.
73
Zamy na przykad, e w zmiennej relacyjnej S jest zdefiniowane ograniczenie integralnociowe (rozdzia 6.) wymuszajce, aby S1 i S4 zawsze miay zdefiniowane to samo miasto.
W takim przypadku operacja modyfikacji, ktra ma zadziaa tylko w jednej krotce, po prostu nie zadziaa poprawnie. Naley wic zaktualizowa obydwie powizane krotki, na przykad wykorzystujc nastpujce zapytanie (SQL):
UPDATE S
SET
CITY = 'Gdask'
WHERE S.SNO = SNO('S1') OR S.SNO = SNO('S4');
Jedn z konsekwencji powyszych wasnoci jest brak w modelu relacyjnym obsugi pozycjonowanych modyfikacji, znanych z jzyka SQL (zapytania typu DELETE ... WHERE CURRENT
OF cursor), poniewa operacje tego typu z definicji odbywaj si na poziomie krotki, nie
zbioru. Tego typu techniki spotyka si do czsto we wspczesnych produktach, lecz dzieje
si tak gwnie dlatego, e produkty te nie s zwykle szczeglnie skuteczne w obsudze
ogranicze integralnociowych. Gdyby wspomniane produkty poprawiy swoj obsug ogranicze integralnociowych, mogoby si okaza, e modyfikacje pozycyjne nie bd dziaa.
Oznacza to, e aplikacje bardzo popularne dzi jutro straciyby swoich uytkownikw. Jest to
moim zdaniem sytuacja, ktrej producenci staraj si unika.
Musz si do czego przyzna. Stosowane przeze mnie okrelenie modyfikacji krotki, lub
raczej zbioru krotek, jest do nieprecyzyjne (eby nie powiedzie do niczego). Jeli obiekt
V jest podatny na modyfikacj, musi by zmienn, nie wartoci, nie zbiorem krotek ani relacj, poniewa jak wiemy z definicji, wartoci nie mog by modyfikowane. Mwic o modyfikacji krotki t1 na krotk t2 w ramach zmiennej relacyjnej R, mamy na myli zastpienie krotki
t1 w R na krotk t2. Ale ten rodzaj rozumowania nadal jest nieprecyzyjny! Tak naprawd to
caa oryginalna relacja r1 ulega wymianie na r2 w ramach zmiennej relacyjnej R. Czym jest
zatem r2? Zamy, e s1 i s2 s relacjami zawierajcymi odpowiednio krotki t1 i t2. Relacja
r2 powstaje w wyniku wyraenia (r1 MINUS s1) UNION s2. Innymi sowy, modyfikacj
krotki t1 na krotk t2 w ramach zmiennej relacyjnej R mona postrzega jako usunicie t1
i wstawienie w to miejsce t2. To nadal znaczne uproszczenie, poniewa zakada moliwo
usuwania i podstawiania pojedynczych krotek w zmiennych relacyjnych.
Analogicznie nie naley dosownie postrzega operacji typu modyfikacja atrybutu A w krotce t lub w relacji r, a nawet w zmiennej relacyjnej R. Oczywicie taka operacja (efektywnie)
ma miejsce i wygodnie jest okrela j w taki sposb (to znacznie upraszcza analiz), lecz podobnie jak w przypadku terminologii przyjaznej uytkownikowi skrytykowanej przeze
mnie w rozdziale 1. mona przyj stosowanie takich uproszcze jedynie w sytuacjach, gdy
nie spowoduje to nieporozumie i nie zagmatwa postrzegania rzeczywistego stanu rzeczy.
74
Klucze kandydujce
Podstawowe zaoenia dotyczce kluczy kandydujcych opisaem w rozdziale 1., lecz nadszed czas na doprecyzowanie tego pojcia. Oto definicja:
DEFINICJA
Niech K bdzie podzbiorem nagwka zmiennej relacyjnej R. K jest kluczem kandydujcym (lub po prostu kluczem) R wtedy i tylko wtedy, gdy posiada nastpujce cechy:
DEFINICJA
Unikalno: adna warto R nie moe zawiera dwch rnych krotek o tej samej
wartoci K.
DEFINICJA
UWAGA
Zgodnie z powszechnie stosowan praktyk w tej ksice stosuj powszechnie okrelenia typu B jest podzbiorem A oraz A jest nadzbiorem B z zaoeniem, e A i B
mog by rwne. Gdy pojawi si konieczno wykluczenia tej moliwoci, wyranie
to zaznacz.
Klucze kandydujce
75
Jak pamitamy z rozdziau 3., kady podzbir krotki jest rwnie krotk. Oczywicie w praktyce
mona powiedzie w uproszczeniu, e wartoci klucza w tym przykadzie jest S1 lub
SNO('S1'), lecz ponownie nie jest to stwierdzenie precyzyjne.
Powinno by ju oczywiste, e koncepcja kluczy opiera si (jak wikszo zagadnie modelu
relacyjnego) na koncepcji rwnoci krotek. Aby wic wymusi ograniczenie unikalnoci, musimy by w stanie stwierdzi, kiedy dwie wartoci klucza s rwne, i to wanie jest kwestia
rwnoci krotek. Nawet w przypadku zmiennej relacyjnej S, gdy krotki klucza wygldaj
jak zwyke wartoci skalarne.
W ramach ostatniej uwagi chciabym nawiza do zalenoci funkcyjnej. Nie bd w tym miejscu omawia szczegowo tej koncepcji (przyjdzie na to czas w rozdziale 7.), lecz Czytelnik
zapewne ju si z ni spotka. Chc zwrci uwag na jeden szczeg. Zamy, e K jest kluczem zmiennej relacyjnej R, a A jest atrybutem R. Wynika z tego, e R z pewnoci spenia
nastpujc zaleno funkcyjn:
KA
W skrcie: zaleno funkcyjna K A oznacza, e kade dwie krotki R zawierajce t sam
warto K bd rwnie zawieray t sam warto A. Lecz jeli dwie krotki zawieraj t sam warto K, a K jest kluczem, to z definicji jest to ta sama krotka, a w zwizku z tym oczywicie maj t sam warto A. Innymi sowy: zawsze zachodzi zaleno funkcyjna wszyst1
Nie mona tego oczywicie powiedzie o tabelach jzyka SQL jak pamitamy tabele SQL zezwalaj na
duplikacj wierszy i dlatego mog nie zawiera adnego klucza.
76
Klucze obce
W rozdziale 1. wyjaniem podstawowe zaoenia kluczy obcych, lecz dokadn definicj podam dopiero teraz (zwracam uwag na to, e i tutaj znajdziemy zwizek z koncepcj rwnoci krotek).
DEFINICJA
Zamy, e R1 i R2 s zmiennymi relacyjnymi (niekoniecznie rnymi), K jest kluczem R1. Zamy te, e FK jest podzbiorem nagwka R2, ktry zawiera dokadnie te
same atrybuty co K (dopuszczamy moliwo zmiany nazw niektrych atrybutw). FK
bdzie kluczem obcym wtedy i tylko wtedy, gdy w danym momencie dla wszystkich
krotek w R2 istnieje warto FK rwna (w sposb unikalny) wartoci K krotki w R1.
Jak wiemy, w bazie danych dostawcw i czci zamiennych w zmiennej relacyjnej SP wystpuj dwa klucze obce {SNO} i {PNO}, ktre odwouj si do kluczy kandydujcych (a w rzeczywistoci do kluczy gwnych) odpowiednio w relacjach S i P. Oto kolejny przykad:
VAR EMP BASE RELATION
{ENO ENO, ..., MNO ENO, ...}
KEY {ENO}
FOREIGN KEY {RENAME (MNO AS ENO)} REFERENCES EMP;
Klucze obce
77
winny by budowane bazy danych, lecz nadal to tylko fundament. Nie ma powodu, aby
w produktach DBMS nie byy dodawane funkcje, ktre w oparciu o fundament pozwol
lepiej obsugiwa model, lecz zarazem nie bd z nim kolidowa. Naley przy tym doda, e takie funkcje uzupeniajce powinny wspiera model i by uyteczne. A bardziej
konkretnie:
a) Teoria typw jest najbardziej oczywistym przykadem. W rozdziale 2. Czytelnicy dowiedzieli si, e typy s niezalene od tabel. Ale take, e prawidowa obsuga typw jest bardzo podana w systemie relacyjnym.
b) Drugim przykadem mog by mechanizmy odtwarzania danych i kontroli wspuytkowania, ktre nie s w ogle omawiane przez model relacyjny, co nie oznacza,
e systemy relacyjne nie powinny zawiera takich funkcji. Mona co prawda sprzecza si, czy model relacyjny nie wspomina o takich funkcjach porednio, poniewa
wymaga, aby system DBMS poprawnie implementowa modyfikacje danych i nie
gubi niczego po drodze. Model jednak nie daje adnych wskazwek co do sposobu, w jaki ma to by zrealizowane.
Uwaga na koniec podrozdziau: klucze obce omwiem z powodu ich wielkiego znaczenia
praktycznego, a take dlatego, e s czci modelu w jego oryginalnej definicji. Powinienem
jednak podkreli, e nie maj fundamentalnego znaczenia, s po prostu form abstrakcji,
uproszczonej obsugi ogranicze integralnociowych, ktre z kolei maj znaczenie fundamentalne2 (o czym przekonamy si w rozdziale 6.). To samo mona zreszt powiedzie i o kluczach
kandydujcych, lecz w tym przypadku praktyczne zalety opracowania takiej abstrakcji s nieporwnywalnie wiksze.
Perspektywy
Perspektywy (ang. view) s czasem okrelane mianem wirtualnych zmiennych relacyjnych.
Jest to taka zmienna relacyjna, ktra nie istnieje w kadym momencie, lecz sprawia takie
wraenie z punktu widzenia uytkownika. Oto definicja:
DEFINICJA
Perspektywa lub wirtualna zmienna relacyjna V jest zmienn relacyjn, ktrej warto
jest generowana w czasie t w wyniku okrelonego wyraenia relacyjnego. Wyraenie
generujce warto zmiennej relacyjnej jest okrelane wraz z definicj V i musi wykorzystywa przynajmniej jedn zmienn relacyjn.
Dokadnie z tego powodu Tutorial D nie obsuguje ich w sposb bezporedni. Jestem jednak pewny, e wersja tego jzyka przeznaczona na rynek bdzie je obsugiwaa i pozwol sobie przyj na potrzeby tej ksiki,
e taka obsuga istnieje.
78
CREATE VIEW LS AS
(SELECT S.*
FROM S
WHERE S.CITY = 'Warszawa');
Nawiasy w powyszych przykadach s zbdne (ale poprawne), dopisaem je w celu zwikszenia czytelnoci.
Odwzorowanie operacji odczytu jest proste. Zamy na przykad nastpujce zapytanie SQL
(LS jest perspektyw):
SELECT LS.SNO
FROM
LS
WHERE LS.STATUS > 10
S.SNO
S
S.CITY = 'Warszawa'
S.STATUS > 10
Opisany proces dziaa poprawnie dziki wasnoci domknitoci algebry relacyjnej. Wasno
domknitoci zakada midzy innymi, e wszdzie, gdzie moemy zastosowa nazw obiektu
Perspektywy
79
(na przykad w zapytaniu), istnieje bardziej oglne wyraenie generujce ten obiekt. W klauzuli FROM mona umieci nazw tabeli SQL, bardziej oglne bdzie wpisanie tam wyraenia SQL i dlatego nazw perspektywy LS moemy zastpi jej definicj.
Przy okazji warto wspomnie, e opisany proces nie dziaa w pierwszych wersjach SQL
(a dokadniej pojawi si dopiero w standardzie SQL z roku 1992), poniewa te wczesne wersje nie obsugiway domknicia w sposb poprawny. W wyniku tego niektre skomplikowane zapytania na niestandardowych tabelach (a dokadniej: na perspektywach) po prostu nie
dziaay, w dodatku czsto z przyczyn trudnych do wytumaczenia. Oto prosty przykad:
CREATE VIEW V
AS (SELECT S.CITY, SUM (S.STATUS) AS ST
FROM S
CROUP BY S.CITY);
SELECT V.CITY
FROM V
WHERE V.ST > 25
To zapytanie w jzyku SQL zgodnym ze standardem sprzed roku 1992 nie zadziaa. I cho
standard zosta poprawiony, nie oznacza to, e zostay poprawione wszystkie produkty!
I rzeczywicie, przynajmniej jeden liczcy si na rynku produkt nadal (pocztek roku 2005)
nie obsuguje poprawnie tego typu zapyta.
Wane spostrzeenie: sytuacj mona odwrci i utworzy relacje bazowe LS i NLS, a relacj
bazow S z powyszego przykadu skonstruowa jako perspektyw wykorzystujc te dwie relacje:
VAR LS BASE RELATION
{SNO SNO, SNAME NAME, STATUS INTEGER, CITY CHAR}
KEY { SNO };
VAR NLS BASE RELATION
{SNO SNO, SNAME NAME, STATUS INTEGER, CITY CHAR }
KEY {SNO };
VAR S VIRTUAL (LS UNION NLS);
UWAGA
Aby uzyska pen rwnowano tych dwch wersji bazy danych, naley zdefiniowa pewne ograniczenia. Przede wszystkim kada warto atrybutu CITY w LS musi
by rwna 'Warszawa', natomiast adna z wartoci CITY w NLS nie moe by rwna
'Warszawa'. Wicej tego typu informacji mona znale w rozdziale 6.
Przykad ten demonstruje, e dobr relacji bazowych i pochodnych jest w peni dowolny, z czego
wynika, e nie ma powodu, aby rozgranicza relacje bazowe i pochodne. Tak wasno nazywa si regu wymiennoci (bazowych i wirtualnych zmiennych relacyjnych). Oto kilka jej
konsekwencji:
80
do bazowych zmiennych relacyjnych, nie do perspektyw. Z tego powodu jest sprzeczna z regu wymiennoci. Oczywicie osobicie odrzucam regu integralnoci encji, poniewa dotyczy NULL-i.
Wiele produktw SQL i sam standard SQL udostpniaj funkcj identyfikatora wiersza
(ang. row ID). Jeli ta funkcja ma zastosowanie do tabel bazowych i nie ma zastosowania
do perspektyw (co jest raczej oczywiste), w prosty sposb stanowi sprzeczno z regu
wymiennoci3. Oczywicie identyfikatory wierszy nie wystpuj w modelu relacyjnym, lecz
nie oznacza to, e nie mog by obsugiwane w produktach. Obserwuj jednak, e identyfikatory wierszy su jako forma identyfikatorw obiektw (w znaczeniu obiektowym,
jak rwnie w standardzie SQL i w wikszoci liczcych si produktw SQL) i jako takie
s zabronione przez model relacyjny! Identyfikatory obiektw s efektywnie wskanikami,
a model relacyjny jawnie zabrania stosowania wskanikw.
Wracajc do podstawowego tematu rozwaa: perspektywy musz by modyfikowalne, poniewa w przeciwnym wypadku byaby to najbardziej bezporednia sprzeczno z regu
wymiennoci.
Jak wiadomo, obsuga tego wymogu w jzyku SQL jest do saba, zarwno w standardzie,
jak i w produktach. Najczciej istnieje jedynie moliwo modyfikacji perspektyw zdefiniowanych jako proste selekcje lub projekcje pojedynczych zmiennych relacyjnych (cho nawet
tu naley oczekiwa problemw). Zamy na przykad nastpujc perspektyw (identyczn z zaprezentowan w rozdziale 1.):
CREATE VIEW SST_WROCLAW
AS (SELECT S.SNO, S.STATUS
FROM
S
WHERE S.CITY = 'Wrocaw');
Ta perspektywa jest projekcj selekcji tabeli bazowej S i dlatego mona na przykad wykona
nastpujc operacj:
DELETE
FROM
WHERE
SST_WROCLAW
SST_WROCLAW.STATUS > 15;
S
S.CITY = 'Wrocaw'
S.STATUS > 15;
Perspektywy
81
Niewiele produktw obsuguje jednak moliwo modyfikacji wartoci perspektyw w przypadkach o wikszym ni przykadowy poziomie komplikacji.
Niestety bdz teraz w obszarze, ktry jest obiektem znacznych kontrowersji. Moja osobista
opinia jest taka, e problem modyfikacji perspektyw zosta w znacznym stopniu rozwizany
(w teorii), lecz nie wszyscy zgodz si ze mn, a gbsza dyskusja na ten temat wymaga analizy, ktra wybiega poza moliwoci tej ksiki. Z tego powodu mog jedynie poleci inn
ksik: Databases, Types, and the Relational Model: The Third Manifesto (Third Edition, AddisonWesley, 2006) autorstwa C.J. Date i Hugh Darwena. W tej ksice problematyka perspektyw
jest omwiona bardziej szczegowo.
Kilka uwag
Istnieje kilka zagadnie, ktre naley omwi przy okazji perspektyw. Po pierwsze, jak powszechnie wiadomo, ale i tak warto o tym wspomnie, perspektywy su dwm podstawowym celom:
Z perspektywy V korzysta uytkownik, ktry j zdefiniowa i jest oczywicie wiadomy
wyraenia X bdcego jej definicj. Uytkownik ten moe zastosowa V w kadym miejscu, gdzie pasuje X. W takim zastosowaniu V jest po prostu skrtem.
Z perspektywy V korzysta uytkownik, ktry jest po prostu poinformowany o tym, e V
istnieje i mona z niej korzysta, lecz z reguy nie zna wyraenia X (w kadym razie nie
powinien). Dla niego V jest w gruncie rzeczy zwyk zmienn relacyjn (bazow). I to wanie tego typu zastosowania perspektyw s szczeglnie wane i analiz perspektyw
przeprowadzaem wanie z myl o nich.
Gdy objaniaem podstawy perspektyw na pocztku tego podrozdziau, napisaem, e wyraenie relacyjne suce do definicji perspektywy powinno wykorzystywa przynajmniej jedn zmienn relacyjn. Dlaczego? Poniewa w przeciwnym razie wynikowa wirtualna
zmienna relacyjna nie bdzie zmienn relacyjn! A dokadniej: nie bdzie zmienn i z pewnoci nie bdzie mona modyfikowa jej zawartoci. Bdzie natomiast czym, co mona nazwa sta relacyjn. Na przykad (skadnia jest oczywicie fikcyjna):
CONST PERIODIC_TABLE
TUPLE {ELEMENT
TUPLE {ELEMENT
...
TUPLE {ELEMENT
});
(RELATION {
'Wodr', SYMBOL 'H', ATOMICNO 1},
'Hel', SYMBOL 'He', ATOMICNO 2},
'Uran', SYMBOL 'U', ATOMICNO 92}
Dostpno staych relacyjnych moe wyda si ciekawym pomysem, lecz z pewnoci nie
naley postrzega takich obiektw jako zmiennych relacyjnych. Nie sdz bowiem, e objaniajc zasady programowania, naley przyj, e stae s zmiennymi.
Przy okazji naszych analiz wystpio bardzo niefortunne zjawisko kolizji terminologicznej,
szczeglnie wrd Czytelnikw o podejciu akademickim, lecz zapewne rwnie wrd Czytelnikw o podejciu biznesowym. Jak pamitamy z rozdziau 1., perspektyw mona postrzega jako pochodn zmiennej relacyjnej. Istnieje jeszcze inna forma pochodnej zmiennej relacyjnej, zwana migawk (ang. snapshot). Jak sugeruje nazwa, migawka jest pochodn, jest
jednak te obiektem rzeczywistym, nie wirtualnym. Oznacza to, e jest reprezentowana nie
tylko za pomoc definicji pobierajcej wartoci z innych zmiennych relacyjnych, lecz take
82
jest to LSS) jako zmienna relacyjna tylko do odczytu (dla zwykych operacji, poniewa
moe zmienia swoj zawarto w wyniku odwieania, co omawia kolejny punkt).
Migawka jest odwieana okresowo (w przykadzie klauzula EVERY DAY powoduje od-
wieanie zrzutu raz dziennie) aktualna warto migawki jest porzucana, zapytanie
jest wywoywane ponownie i wynik tego wywoania jest ponownie zapisywany jako
nowa warto migawki.
Przykadowa migawka reprezentuje zatem dane, ktre byy aktualne co najwyej 24 godziny temu.
Migawki s wane w hurtowniach danych, systemach rozproszonych i wielu innych kontekstach. We wszystkich przypadkach ich stosowanie stanowi efekt kompromisu, ktry jest akceptowalny (lub nawet wymagany) i efektywnie oznacza obraz danych w okrelonym
punkcie czasu. Przykadem takiego przypadku s aplikacje raportujce i ksigowe: wymagaj
z reguy, aby dane byy zamroone w danym punkcie czasu (na przykad na koniec okresu
rozliczeniowego). Migawki pozwalaj na takie zamroenie bez koniecznoci blokowania innych aplikacji korzystajcych z bazy danych.
Problem polega jednak na tym, e migawki w niektrych krgach s znane nie pod wasn
nazw, lecz jako zmaterializowane perspektywy (ang. materialized views). Migawki nie s jednak
perspektywami! Podstawowa wasno perspektyw z punktu widzenia modelu relacyjnego
dotyczy wanie tego, e nie s zmaterializowane! Jak zaobserwowalimy, operacje dokonywane na perspektywach s tumaczone na bazowe zmienne relacyjne. Z tego powodu okrelenie zmaterializowana perspektywa jest po prostu wewntrzn sprzecznoci. Co gorsza,
pojcie perspektywa bywa stosowane jako skrt pojcia zmaterializowana perspektywa
(w niektrych krgach), wic problem si pogbia, co grozi w konsekwencji dewaluacj
prawidowego znaczenia terminu. W tej ksice termin perspektywa stosuj oczywicie w jego
oryginalnym znaczeniu, lecz naley pamita, e nie w kadym kontekcie oznacza dokadnie to samo.
83
w R moe by uznana za reprezentacj propozycji p utworzonej przez wywoanie (utworzenie egzemplarza) predykatu P przez podstawienie wartoci atrybutw t jako argumentw P.
to TRUE.
Z tego powodu, biorc przykadow warto zmiennej relacyjnej S, zakadamy, e nastpujce propozycje maj wartoci TRUE:
Dostawca S1 ma podpisany kontrakt z nasz firm, ma nazwisko Kowalski, status 20,
a jego siedziba znajduje si w miecie Warszawa.
Dostawca S2 ma podpisany kontrakt z nasz firm, ma nazwisko Nowak, status 10, a jego
siedziba znajduje si w miecie Wrocaw.
Dostawca S3 ma podpisany kontrakt z nasz firm, ma nazwisko Kwiatkowski, status 30,
a jego siedziba znajduje si w miecie Wrocaw.
I tak dalej. Co wicej, jeli jaka krotka moe teoretycznie wystpowa w zmiennej relacyjnej,
lecz w danym punkcie czasu si w niej nie znajduje, zakadamy, e wynik propozycji o wartociach z jej atrybutw jest rwny FALSE (czyli przyjmujemy zaoenie, e relacja jest skoczonym wiatem w danym punkcie czasu). Wemy na przykad nastpujc krotk:
84
Taka krotka jest cakowicie poprawna, lecz w danym punkcie czasu nie wystpuje w zmiennej relacyjnej S, wic zakadamy, e w tym punkcie czasu nastpujca propozycja ma warto
FALSE:
Dostawca S6 ma podpisany kontrakt z nasz firm, ma nazwisko migy, status 30, a jego
siedziba znajduje si w miecie Szczecin.
Innymi sowy, zmienna relacyjna zawiera w danym punkcie czasu wszystkie i tylko te krotki,
dla ktrych propozycje (egzemplarze predykatw) w tym punkcie czasu maj warto TRUE.
DEFINICJA
Wyraenia relacyjne
Omwione koncepcje maj bezporedni zwizek z wyraeniami relacyjnymi. Na przykad
wemy pod uwag nastpujce wyraenie, ktre reprezentuje projekcj relacji dostawcw
zawierajc wszystkie atrybuty, oprcz CITY:
S {SNO, SNAME, STATUS}
ktre wystpuj w relacji S i maj posta (dla dowolnej wartoci c atrybutu CITY):
TUPLE {SNO s, SNAME n, STATUS t, CITY c}
85
Predykat zmiennej relacyjnej dla tej perspektywy bdzie mia nastpujce brzmienie:
Dostawca SNO ma kontrakt z nasz firm, ma nazwisko SNAME, status STATUS, a jego
siedziba znajduje si w jakim miecie.
W tym miejscu warto przedstawi jeszcze jedn uwag dotyczc predykatw i propozycji.
Jak wspominaem, predykat jest zbiorem parametrw. Jak zwykle ten zbir moe by pusty.
Jeli jest, predykat staje si propozycj! Oczywicie przede wszystkim staje si stwierdzeniem, ktre bezwarunkowo przyjmuje warto TRUE lub FALSE. Innymi sowy, propozycja
jest zdegenerowanym predykatem, wszystkie propozycje s zatem predykatami, lecz nie wszystkie predykaty s propozycjami.
Innymi sowy, typy daj nam sowniki czyli elementy, o ktrych moemy mwi. Relacje
daj nam moliwo mwienia o tych elementach (ciekawa analogia pomagajca zrozumie
t wasno: typy s dla relacji tym, czym rzeczowniki s dla zda). Na przykad jeli ograniczymy nasze dociekania tylko do relacji dostawcw, zobaczymy, e:
Moemy mwi o identyfikatorach dostawcw, nazwiskach, liczbach i cigach znakw
i o niczym wicej.
Moemy stwierdzi fakty o nastpujcej treci: Dostawca o zadanym identyfikatorze ma
kontrakt z nasz firm, posiada nazwisko, status okrelony liczb cakowit, a jego siedziba mieci si w miecie okrelonym cigiem znakw i nic wicej. Nic wicej,
oprcz wnioskw wynikajcych z tych stwierdze. Moemy na przykad stwierdzi do
sporo na temat dostawcy S1, na przykad, e dostawca S1 ma kontrakt z nasz firm, ma nazwisko Kowalski, status 20, a jego siedziba mieci si w jakim miecie, ktrego nazwa nie jest
istotna. To ostatnie stwierdzenie moe bardzo przypomina projekcje relacji, i wanie
o to chodzio.
86
Ten stan rzeczy ma co najmniej trzy istotne konsekwencje. Baza danych ma za zadanie reprezentowa fragment rzeczywistoci. W zwizku z tym zachodz nastpujce wasnoci:
1. Typy i relacje s niezbdne bez typw nie mielibymy o czym mwi, bez relacji nie
mielibymy nic do powiedzenia.
2. Typy i relacje s wystarczajce z logicznego punktu widzenia nie potrzebujemy nic in-
nego. W szczeglnoci w celu zaprezentowania stanu wiata w danym punkcie czasu nie
potrzebujemy zmiennych relacyjnych, s one potrzebne jedynie do tego, aby rejestrowa
zmiany zachodzce w obserwowanym wiecie.
3. Typy i relacje to nie to samo. Naley unika tego typu skojarze! W rzeczywistoci niekt-
re produkty komercyjne usiuj wmwi wanie co takiego (cho niekoniecznie w sposb dosowny). Mam nadziej, e produkt opierajcy si na tak powanym bdzie logicznym jest skazany na niepowodzenie. Produkty, ktre mam na myli, nie s bowiem
produktami relacyjnymi, z reguy funkcjonuj w oparciu o ujcie zorientowane obiektowo lub usiuj poczy obiekty z tabelami SQL (jeden z produktw, ktre szczeglnie
mam na myli, w rzeczywistoci praktycznie znikn ju z rynku). Dalsze szczegy tej
analizy znacznie wykraczaj poza tematyk ksiki.
87
Oczywicie rozumie si samo przez si, e model relacyjny zawiera bardzo bezporednie odpowiedzi na te pytania. Jest to przy okazji powd, dla ktrego uwaam, e model ten jest
skoczony, pewny i poprawny i e z pewnoci przetrwa. Z tego powodu te uwaam, e
inne modele danych po prostu nie nale do tej samej ligi. Tak naprawd mam wtpliwoci, czy te inne modele zasuguj w ogle na miano modeli w takim samym sensie, w jakim
rozumiany jest model relacyjny. Z pewnoci wikszo tych modeli jest zdefiniowana ad
hoc, zamiast w oparciu o solidne fundamenty, jak ma to miejsce w przypadku modelu relacyjnego, ktry jest oparty na teorii zbiorw i logice predykatw. Szersze omwienie tego tematu zawiera rozdzia 8.
Podsumowanie
Najwaniejsza cz tego rozdziau to podrozdzia omawiajcy predykaty (wraz z poprzedzajcym go podrozdziaem na temat relacji i typw). Kada zmienna relacyjna R ma przypisany predykat P (predykat zmiennej relacyjnej dla R). Predykat P jest zaoon interpretacj dla
R i jest niezmienny w czasie. Jeli biec wartoci R jest relacja r, wtedy r jest biecym rozszerzeniem P. Rozszerzenie predykatu jest zmienne w czasie. Baza danych wraz z jej operatorami moe by zatem postrzegana jako system logiczny.
Z tego rozdziau wynikaj nastpujce wane wnioski:
Tylko wartoci relacyjne mog by modyfikowane, okrelenia modyfikacja krotki czy
Kada zmienna relacyjna posiada przynajmniej jeden klucz (kandydujcy). Klucze maj
zwizane z zachowaniem integralnoci, jak CASCADE, ktre cho bardzo uyteczne, nie
s elementem modelu relacyjnego. Co wicej, klucze obce te nie maj znaczenia fundamentalnego.
Operacje na perspektywach s zaimplementowane za pomoc odwzorowania na od-
88
wiczenia
wiczenie 4.1. Wyjani wasnymi sowami, dlaczego okrelenie typu ta operacja UPDATE
modyfikuje status dostawcw z Warszawy jest nieprecyzyjne. Zaproponowa poprawn form tego okrelenia.
wiczenie 4.2. Dlaczego pozycjonowane modyfikacje znane z jzyka SQL s przykadem
bdnej koncepcji?
wiczenie 4.3. Poda definicje w jzyku SQL zmiennych relacyjnych TAX_BRACKET, ROSTER oraz MARRIAGE z podrozdziau Klucze kandydujce.
wiczenie 4.4. Dlaczego okrelenie relacja ma klucz nie ma sensu?
wiczenie 4.5. W treci rozdziau pojawi si argument na to, e wasno nieredukowalnoci
kluczy ma znaczenie. Poda inne argumenty.
wiczenie 4.6. Wartoci kluczy nie s skalarami, lecz krotkami. Wyjani dlaczego.
wiczenie 4.7. Zamy, e zmienna relacyjna R jest stopnia n. Jak maksymaln liczb kluczy moe mie R?
wiczenie 4.8. Zmienna relacyjna EMP z podrozdziau Klucze obce jest przykadem samoodwoujcej si zmiennej relacyjnej. Wymyli przykadowe dane dla tej zmiennej relacyjnej.
Czy ten przykad stanowi uzasadnienie dla stosowania NULL-i? (Poprawna odpowied: nie, ale
jest doskona demonstracj tego, jak kuszca moe by idea stosowania NULL-i). Co mona
zrobi w tym przykadzie, jeli NULL-e s zabronione?
wiczenie 4.9. Jzyk SQL nie obsuguje dostpnej w Tutorial D funkcji modyfikacji nazwy
klucza obcego. Dlaczego?
wiczenie 4.10. Czy mona wymyli dwie zmienne relacyjne R1 i R2, ktre zawieraj klucze
obce odwoujce si wzajemnie do siebie?
wiczenie 4.11. Przeanalizowa wykorzystywany przez siebie produkt SQL. Jakie dziaania
zwizane z integralnoci odwoa obsuguje? Ktre z nich s rzeczywicie uyteczne? Czy
mona wymyli inne, nieobsugiwane przez produkt, lecz potencjalnie uyteczne?
wiczenie 4.12. Model relacyjny nie wspomina o procedurach wyzwalanych (ang. triggered procedures), czsto nazywanych wyzwalaczami (ang. triggers). Czy to pominicie stanowi problem?
Jeli tak, dlaczego? Czy procedury wyzwalane s konieczne? Czy s w ogle potrzebne?
wiczenie 4.13. Niech perspektywa LSSP bdzie zdefiniowana nastpujco (SQL):
CREATE VIEW LSSP
AS (SELECT S.SNO, S.SNAME, S.STATUS, SP.PNO, SP.OTY
FROM
S, SP
WHERE S.SNO = SP.SNO
AND
S.CITY = 'Warszawa');
wiczenia
89
W jaki sposb mogoby wyglda zapytanie wynikowe (rozwinicie zapytania z zastosowaniem definicji perspektywy) na odpowiedniej bazowej zmiennej relacyjnej?
wiczenie 4.14. Jakie klucze posiada perspektywa LSSP z powyszego wiczenia?
wiczenie 4.15. Przeanalizowa wykorzystywany przez siebie produkt SQL. Czy istniej teoretycznie poprawne zapytania, ktre nie dziaaj w tym produkcie? Jeli tak, okreli dokadnie, jakie warunki musz by spenione, aby zapytanie nie zadziaao. Jakie jest wytumaczenie producenta dotyczce braku penej obsugi tego typu zapyta? Uwaga: wiczenie dotyczy
tylko zapyta odczytujcych, nie modyfikujcych.
wiczenie 4.16. Przeanalizowa wykorzystywany przez siebie produkt SQL. Jakie obsuguje
operacje modyfikujce na perspektywach? Odpowiedzi udzieli w sposb jak najbardziej
precyzyjny.
wiczenie 4.17. Wykorzystujc baz danych dostawcw i czci zamiennych lub dowoln
inn baz danych, poda kilka przykadw ilustrujcych stwierdzenie, e podzia zmiennych
relacyjnych na bazowe i wirtualne jest czysto umowny.
wiczenie 4.18. Przeanalizowa wykorzystywany przez siebie produkt SQL. W jaki sposb
(na pewno znajdzie si kilka!) ten produkt narusza regu wymiennoci?
wiczenie 4.19. Przedstawi rnice pomidzy perspektywami a migawkami. Czy SQL obsuguje migawki? Czy ktrykolwiek z produktw znanych Czytelnikowi je obsuguje?
wiczenie 4.20. Co to jest zmaterializowana perspektywa? Dlaczego stosowanie tego terminu nie jest zalecane?
wiczenie 4.21. Zdefiniowa terminy propozycja i predykat. Przedstawi przykady.
wiczenie 4.22. Okreli predykaty dla zmiennych relacyjnych P i SP z bazy danych dostawcw i czci zamiennych.
wiczenie 4.23. Co naley rozumie przez pojcia predykat i rozszerzenie?
wiczenie 4.24. Niech DB bdzie dowoln baz danych znan Czytelnikowi, a R dowoln
zmienn relacyjn w DB. Jaki jest predykat dla R? Uwaga: celem tego wiczenia jest zastosowanie fundamentalnych koncepcji omwionych w treci rozdziau do wasnych danych i nauczenie Czytelnika mylenia o danych w takim oglnym zakresie. Oczywicie to wiczenie
nie ma uniwersalnego rozwizania.
wiczenie 4.25. Wemy pod uwag perspektywy LS i NLS z podrozdziau perspektywy.
Jakie s predykaty dla tych zmiennych relacyjnych? Czy gdyby te perspektywy byy bazowymi zmiennymi relacyjnymi, zmienioby si brzmienie predykatw?
wiczenie 4.26. Jaki jest predykat dla perspektywy LSSP z wiczenia 4.13?
wiczenie 4.27. Wytumaczy zaoenie zamknitego wiata.
wiczenie 4.28. Klucz jest zbiorem atrybutw, pusty zbir jest rwnie prawidowym zbiorem, z tego mona wywnioskowa, e pusty klucz jest kluczem o pustym zbiorze atrybutw.
Czy taki klucz ma jakiekolwiek praktyczne zastosowanie?
wiczenie 4.29. Jaki jest predykat dla zmiennej relacyjnej stopnia zerowego? Czy to pytanie
ma w ogle sens? Uzasadni odpowied.
wiczenie 4.30. Kada zmienna relacyjna posiada warto w postaci relacji. Czy twierdzenie odwrotne jest rwnie prawdziwe? To znaczy, czy kada relacja jest wartoci zmiennej relacyjnej?
90