IDZ DO

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

Relacyjne bazy danych

dla praktykw
Autor: C.J. Date
Tumaczenie: Marek Ptlicki
ISBN: 83-246-0101-5
Tytu oryginau: Database in Depth
Format: B5, stron: 280
Wszystkie tajniki relacyjnego modelu danych
Dowiedz si, czym s krotki i relacje
Poznaj algebr relacji i zasady normalizacji danych
Zaprojektuj efektywne schematy relacji i zaimplementuj je w bazie
Relacyjne bazy danych spotykamy niemal w kadej aplikacji komputerowej, czsto
nawet nie zdajc sobie z tego sprawy. Wiemy, e w oparciu o nie buduje si aplikacje
korporacyjne, witryny internetowe i inne rozbudowane systemy informatyczne. Jednak
to nie wszystko bazy danych s wszdzie nawet cyfrowy aparat fotograficzny
posiada baz danych, ktr wykorzystuje przy doborze parametrw ekspozycji.
Wszystkie nowoczesne systemy zarzdzania bazami opieraj si na modelu relacyjnym,
sformuowanym w 1969 roku przez E.F. Codda. Znajomo teorii relacji okazuje si
przydatna nie tylko twrcom takich systemw. Programici korzystajcy z baz danych
i administratorzy takich baz rwnie powinni posiada tak wiedz, aby w peni
wykorzysta moliwoci, jakie oferuje im model relacyjny.
Ksika Relacyjne bazy danych dla praktykw to szczegowe omwienie modelu
relacyjnego przeznaczone dla uytkownikw takich systemw. Nie opisuje konkretnych
produktw przedstawia wszystkie tajniki teorii relacyjnej i wskazuje moliwoci
wykorzystania tej wiedzy w codziennych zadaniach. Autor ksiki Chris Date, znany
autorytet z dziedziny baz danych, przedstawi Ci koncepcje relacyjne, teori zbiorw,
rnice pomidzy modelem a implementacj, algebr relacyjn oraz zagadnienia
normalizacji danych.
Podstawy modelu relacyjnego
Skalarne i nieskalarne typy danych
Krotki i relacje pomidzy nimi
Zmienne relacyjne i predykaty
Podstawy algebry relacji
Ograniczenia w bazach danych
Postaci normalne
Teoria projektowania baz danych
Implementacja modelu relacyjnego
Dziki wiadomociom zawartym w tej ksice sprawniej i efektywniej wykorzystasz
moliwoci wspczesnych systemw zarzdzania bazami danych.

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

2. Relacje i typy ................................................................................................................ 39

Porwnania wartoci oparte na dziedzinie danych
Atomowo wartoci danych
Czym jest typ?
Typy skalarne i nieskalarne
Podsumowanie
wiczenia

40
44
47
49
51
52

3. Krotki i relacje .............................................................................................................. 55

Czym jest krotka?
Kilka wanych konsekwencji
Czym jest relacja?
Dalsze konsekwencje
Dlaczego relacja nie moe zawiera zduplikowanych krotek
Dlaczego nie naley stosowa NULL-i
TABLE_DUM i TABLE_DEE
Podsumowanie
wiczenia

55
57
59
60
61
66
69
70
70

4. Zmienne relacyjne ....................................................................................................... 73

Operacje modyfikujce
Klucze kandydujce
Klucze obce
Perspektywy
Zmienne relacyjne i predykaty
Dalsze uwagi na temat relacji i typw
Podsumowanie
wiczenia

73
75
77
78
83
86
88
89

5. Algebra relacyjna .........................................................................................................91

Wasno domknicia
Operatory oryginalne
Wyliczanie wyrae SQL
Rozszerzenie i podsumowanie
Grupowanie i rozgrupowanie
Przeksztacanie wyrae
Porwnania relacyjne
Przypisanie relacyjne
Operator ORDER BY
Podsumowanie
wiczenia

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

7. Teoria projektowania baz danych ............................................................................ 143

Rola teorii projektowej
Zalenoci funkcyjne i posta normalna Boycea i Codda
Zalenoci zczeniowe i pita posta normalna
Dwie zalety normalizacji
Ortogonalno
Kilka uwag o projekcie fizycznym
Podsumowanie
wiczenia
6

Spis treci

144
146
151
158
161
164
165
167

8. Co to jest model relacyjny? ........................................................................................ 171

Model relacyjny zdefiniowany
Podstawowe cele modelu relacyjnego
Wybrane reguy zwizane z bazami danych
Model relacyjny a inne modele danych
Co zostao do zrobienia
Podsumowanie
wiczenia

172
175
176
177
180
184
185

A Nieco logiki ................................................................................................................ 189

Propozycje
Predykaty
Kwantyfikacja
Zmienne wolne i zwizane
Wicej o kwantyfikacji
Ograniczenia baz danych
Zapytania
Rwnowanoci
Podsumowanie

189
191
192
194
195
199
201
202
203

B .................................................................................................................................... 205
Algebra relacyjna i operatory modyfikujce
Baza danych dostawcw i czci zamiennych

206

C Rozwizania wicze ............................................................................................... 207

Rozdzia 1. Wprowadzenie
Rozdzia 2. Relacje i typy
Rozdzia 3. Krotki i relacje
Rozdzia 4. Zmienne relacyjne
Rozdzia 5. Algebra relacyjna
Rozdzia 6. Ograniczenia
Rozdzia 7. Teoria projektowania baz danych
Rozdzia 8. Co to jest model relacyjny?

207
212
218
225
230
244
251
259

Skorowidz .................................................................................................................. 267

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');

Powysze zapytanie oczywicie modyfikuje zbir zoony z dwch krotek.

UWAGA

Dla zainteresowanych: odpowiednie wyraenie w jzyku Tutorial D ma nastpujc

posta (do podobn):
UPDATE S WHERE SNO = SNO('S1') OR SNO = SNO('S4')
(CITY := 'Gdask');

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

Rozdzia 4. Zmienne relacyjne

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

Nieredukowalno: aden podzbir K nie ma cechy unikalnoci.

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.

Wasno unikalnoci jest zrozumiaa i oczywista, naley jednak powiedzie kilka sw

o wasnoci nieredukowalnoci. Wemy pod uwag zmienn relacyjn S i zbir atrybutw
{SNO, CITY} (nazwijmy go SK). Ten zbir atrybutw jest podzbiorem nagwka zmiennej S
z pewnoci posiadajcym cech unikalnoci (adna moliwa warto S nie moe mie
dwch krotek o tej samej wartoci SK). SK jednak nie ma cechy nieredukowalnoci, poniewa
moemy odrzuci atrybut CITY i to, co zostanie, czyli podzbir {SNO} rwnie posiada cech
unikalnoci. Nie mona wic uzna SK za klucz, poniewa jest za duy. Natomiast {SNO}
ma cech nieredukowalnoci i jest poprawnym kluczem.
Dlaczego klucze musz by nieredukowalne? Jednym z powodw jest poprawna obsuga
klauzuli unikalnoci przez DBMS. Zamy, e okamalimy DBMS, wymuszajc klucz
{SNO, CITY}. System DBMS nie moe w takim przypadku wymusi unikalnoci identyfikatora dostawcy, moe jedynie wymusi unikalno klucza, czyli identyfikatorw dostawcw
w danym miecie. To jeden z powodw (oczywicie nie jedyny), dlaczego klucze nie mog
zawiera atrybutw niepotrzebnych do unikalnej identyfikacji krotek.
Wszystkie zmienne relacyjne analizowane do tej pory posiadaj tylko jeden klucz. Przedstawi dla odmiany kilka relacji zawierajcych wiksz liczb kluczy (te przykady s z zaoenia intuicyjne). Zwracam uwag na czciowe pokrywanie si kluczy w drugim i trzecim
przykadzie.
VAR TAX_BRACKET BASE RELATION
{LOW MONEY, HIGH MONEY, PERCENTAGE INTEGER}
KEY {LOW}
KEY {HIGH}
KEY {PERCENTAGE};
VAR ROSTER BASE RELATION
{DAY DAY_OF_WEEK, TIME TIME_OF_DAY, GATE GATE, PILOT NAME}
KEY {DAY, TIME, GATE}
KEY {DAY, TIME, PILOT};

Klucze kandydujce

75

VAR MARRIAGE BASE RELATION

{SPOUSE_A NAME, SPOUSE_B NAME, DATE_OF_MARRIAGE DATE}
/* wykluczamy poligami */
/* i moliwo dwukrotnego zawarcia maestwa przez t sam par */
KEY {SPOUSE_A, DATE_OF_MARRIAGE}
KEY {DATE_OF_MARRIAGE, SPOUSE_B}
KEY {SPOUSE_B, SPOUSE_A};

Ten podrozdzia zakocz kilkoma uwagami. Po pierwsze, naley pamita, e koncepcja

kluczy odnosi si do zmiennych relacyjnych, nie do relacji. Dlaczego? Poniewa stwierdzenie,
e podzbir nagwka jest kluczem, jest rwnoznaczne zdefiniowaniu ograniczenia integralnociowego, a dokadniej ograniczenia wymuszajcego unikalno. Ograniczenie integralnociowe stosuje si do zmiennych, nie do wartoci ograniczenia stanowi mechanizm kontrolny operacji modyfikujcych, a jak wiadomo wartoci nie s modyfikowalne. Wicej
informacji na ten temat mona znale w rozdziale 6.
Po drugie, jeli R jest zmienn relacyjn, musi zawiera przynajmniej jeden klucz. Powodem
tego wymogu jest to, e wartociami R s relacje, ktre z definicji nie mog zawiera duplikatw. W najgorszym przypadku wic wymg unikalnoci spenia kombinacja wszystkich
atrybutw R1. Z tego powodu albo kombinacja wszystkich atrybutw relacji spenia wymg
nieredukowalnoci, albo udaje si wyodrbni podzbir atrybutw speniajcy ten wymg.
W kadym wypadku zawsze udaje si znale odpowiedni klucz.
Po trzecie, naley pamita, e wartociami klucza s krotki. W przypadku zmiennej relacyjnej S zawierajcej jedyny klucz {SNO} warto tego klucza dla okrelonej krotki (np. dla dostawcy S1) wynosi:
TUPLE {SNO SNO('S1')}

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

Rozdzia 4. Zmienne relacyjne

kich wartoci atrybutw od kluczy relacji. Zjawisko to przeanalizuj bardziej szczegowo

w rozdziale 7.

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;

Atrybut MNO okrela identyfikator menedera pracownika identyfikowanego przez ENO.

Odwoujca si zmienna relacyjna (w definicji R2) i zmienna odwoywana (w definicji R1) to
w tym przypadku ta sama zmienna. Na przykad krotka zmiennej relacyjnej EMP dla pracownika E3 moe zawiera w atrybucie MNO warto E3, co stanowi odwoanie do krotki
w tej samej relacji o wartoci E2 w atrybucie EMP. Wartoci kluczy obcych (podobnie jak
wartoci kluczy kandydujcych) s wartociami krotkowymi, zatem aby zachodzia rwno
krotek, musimy zmieni nazw atrybutu MNO w specyfikacji klucza obcego. O jak rwno
krotek chodzi? O porwnanie wartoci klucza obcego z kluczem kandydujcym, a jak pamitamy, aby dwie krotki mogy by rwne, musz by tego samego typu, a ten sam typ
oznacza, e musz mie takie same nazwy i typy atrybutw.
Na marginesie naley wspomnie, e model relacyjny w swojej oryginalnej postaci wymaga,
aby klucze obce byy dopasowane nie do dowolnego klucza kandydujcego, lecz wycznie
do klucza gwnego relacji. Jak jednak stwierdziem w rozdziale 1., nie uwaam, eby zawsze
bya konieczno wyboru klucza gwnego spord kluczy kandydujcych, a co si z tym
wie, nie mona wymaga, aby klucz obcy by dopasowywany wycznie do klucza gwnego (akurat pod tym wzgldem zgadzam si z ustaleniami standardu SQL).
SQL obsuguje nie tylko same klucze obce, lecz rwnie pewne dziaania zwizane z ich obsug zgodnie z zasadami integralnoci odwoa. Jednym z takich dziaa jest dyrektywa CASCADE (ktra ma zastosowanie przy operacjach usuwania i modyfikacji klucza i definiuje si
j odpowiednio w klauzulach ON DELETE i ON UPDATE). Na przykad instrukcja CREATE
TABLE tworzca tabel dostaw moe zawiera nastpujcy fragment tworzcy klucz obcy:
FOREIGN KEY (SNO) REFERENCES S (SNO) ON DELETE CASCADE

Klucze obce

77

Po takim zdefiniowaniu klucza obcego prba usunicia dostawcy spowoduje usunicie

wszystkich jego dostaw. Wspominam o tym z nastpujcych powodw:
Tego typu mechanizmy mog mie bardzo praktyczne zastosowanie, lecz same w sobie

nie wchodz w skad modelu relacyjnego.

To jednak nie jest problem, poniewa model relacyjny jest fundamentem, na ktrym po-

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

Rozdzia 4. Zmienne relacyjne

Przeanalizujmy kilka przykadw: dostawcy z Warszawy oraz dostawcy spoza Warszawy

(definicja w Tutorial D po lewej, w SQL po prawej):
VAR LS VIRTUAL
(S WHERE CITY = 'Warszawa');

CREATE VIEW LS AS
(SELECT S.*
FROM S
WHERE S.CITY = 'Warszawa');

VAR NLS VIRTUAL

(S WHERE CITY 'Warszawa');

CREATE VIEW NLS AS

(SELECT S.*
FROM S
WHERE S.CITY <> 'Warszawa');

Nawiasy w powyszych przykadach s zbdne (ale poprawne), dopisaem je w celu zwikszenia czytelnoci.

Odczyt wartoci perspektyw

Powtrz wan wasno: perspektywy sprawiaj wraenie, jakby istniay w sposb niezaleny, innymi sowy, z punktu widzenia uytkownika maj wyglda i dziaa tak, jakby byy
zmiennymi relacyjnymi. W szczeglnoci uytkownik powinien mie moliwo wykonywania na perspektywach tych samych operacji, co na bazowych zmiennych relacyjnych, a DBMS
powinien przenosi te dziaania na odpowiednie bazowe zmienne relacyjne w sposb zgodny z ostateczn definicj perspektywy. Ostateczn, czyli rozwinit z definicji porednich, bo
perspektywa moe by skonstruowana w oparciu o inn perspektyw (skoro perspektywy
maj z definicji wyglda i zachowywa si dokadnie tak, jak bazowe zmienne relacyjne), na
przykad:
CREATE VIEW LS_STATUS
AS (SELECT LS.SNO, LS.STATUS
FROM LS);

Odwzorowanie operacji odczytu jest proste. Zamy na przykad nastpujce zapytanie SQL
(LS jest perspektyw):
SELECT LS.SNO
FROM
LS
WHERE LS.STATUS > 10

Po pierwsze, DBMS zastpuje odwoanie z klauzuli FROM odpowiednim podzapytaniem

(z definicji perspektywy):
SELECT LS.SNO
FROM (SELECT S.*
FROM
S
WHERE S.CITY = 'Warszawa') AS LS
WHERE LS.STATUS > 10

To wyraenie mona uproci w nastpujcy sposb:

SELECT
FROM
WHERE
AND

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.

Modyfikacja wartoci perspektyw

Przejdmy do operacji modyfikujcych wartoci. Zanim zajm si szczegami, przyjrzyjmy
si perspektywom dostawcw z Warszawy i spoza Warszawy (tym razem w Tutorial D):
VAR LS VIRTUAL (S WHERE CITY = 'Warszawa');
VAR NLS VIRTUAL (S WHERE CITY 'Warszawa');

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

Rozdzia 4. Zmienne relacyjne

 Perspektywy, podobnie jak bazowe zmienne relacyjne, musz uwzgldnia ograniczenia

integralnociowe. Ograniczenia integralnociowe z reguy postrzega si jako elementy

relacji bazowych, lecz regua wymiennoci demonstruje, e to nieprawda.
Perspektywy maj klucze kandydujce, z tego powodu powinienem by umieci defini-

cje kluczy kandydujcych w powyszych definicjach perspektyw. Tutorial D pozwala na

to, lecz SQL nie. Perspektywy mog te mie zdefiniowane klucze obce, a klucze obce innych relacji mog wskazywa na perspektywy.
Nie wspomniaem o tym w rozdziale 1., ale regua integralnoci encji ma zastosowanie

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;

Ta operacja jest rwnowana nastpujcej:

DELETE
FROM
WHERE
AND

S
S.CITY = 'Wrocaw'
S.STATUS > 15;

By moe jest rwnie sprzeczna z zasad informacji (rozdzia 8.).

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

Rozdzia 4. Zmienne relacyjne

(przynajmniej koncepcyjnie) przez wasn kopi danych. Na przykad (ponownie wymylam

fikcyjn skadni):
VAR LSS SNAPSHOT (S WHERE CITY = 'Warszawa')
REFRESH EVERY DAY;

Definicja migawki jest podobna do definicji zapytania, z nastpujcymi rnicami:

Wynik zapytania jest zapisywany w bazie danych pod okrelon nazw (w przykadzie

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.

Zmienne relacyjne i predykaty

Dotarlimy do najwaniejszego (pod wieloma wzgldami) punktu rozdziau. Mona go podsumowa nastpujco: zmienne relacyjne mona postrzega na wiele sposobw. Wiele osb
postrzega je jako pliki w tradycyjnym znaczeniu informatycznym. By moe jako do abstrakcyjne pliki (ustrukturalizowane, to chyba jeszcze lepsze sowo), lecz koniec kocw: pliki.
Istnieje jednak inny sposb ich postrzegania, ktry jak mam nadziej, pomoe lepiej zrozumie, o co naprawd chodzi w modelu relacyjnym.
Wemy pod uwag zmienn relacyjn dostawcw S. Jak wszystkie zmienne relacyjne powinna ona reprezentowa okrelony fragment rzeczywistoci. A dokadniej: nagwek tej zmiennej relacyjnej reprezentuje pewien predykat, czyli ogln definicj reprezentacji okrelonego
Zmienne relacyjne i predykaty

83

fragmentu rzeczywistoci (ogln, bo sparametryzowan, o czym za chwil). Predykat ten ma

nastpujc posta:
Dostawca SNO ma podpisany kontrakt z nasz firm, ma nazwisko SNAME, status
STATUS, a jego siedziba znajduje si w miecie CITY.
Ten predykat to zaoona interpretacja, czyli inaczej znaczenie zmiennej relacyjnej S.
Predykaty mona postrzega jako funkcje o wartoci logicznej. Predykat jak wszystkie funkcje
posiada parametry, zwraca wynik, ktrym moe by warto logiczna TRUE lub FALSE.
W przypadku prezentowanego wyej predykatu parametrami s SNO, SNAME, STATUS
i CITY (odpowiadajce atrybutom zmiennej relacyjnej) i przyjmuj wartoci okrelonych typw (odpowiednio SNO, NAME, INTEGER i CHAR). Gdy ta funkcja jest wywoana (lub jak
mwi logicy: gdy tworzony jest egzemplarz predykatu), za parametry podstawiane s odpowiednie argumenty. Zamy, e podstawiamy odpowiednio argumenty S1, Kowalski, 20
i Warszawa. Otrzymamy nastpujc propozycj:
Dostawca S1 ma podpisany kontrakt z nasz firm, ma nazwisko Kowalski, status 20,
a jego siedziba znajduje si w miecie Warszawa.
Propozycja to instrukcja logiczna zwracajca bezwarunkowo warto TRUE lub FALSE. Oto
kilka przykadw:
Edward Abbey napisa The Monkey Wrench Gang.
William Szekspir napisa The Monkey Wrench Gang.
Pierwsze wyraenie ma warto TRUE, drugie ma warto FALSE. Nie wolno zakada, e
propozycje zawsze przyjmuj warto TRUE. Jednake propozycje rozpatrywane w kontekcie zmiennych relacyjnych powinny mie warto TRUE z nastpujcych powodw:
Kada zmienna relacyjna ma skojarzony predykat nazywany predykatem zmiennej relacyjnej.
Zamy, e zmienna relacyjna R ma skojarzony predykat P. Kada krotka t wystpujca

w R moe by uznana za reprezentacj propozycji p utworzonej przez wywoanie (utworzenie egzemplarza) predykatu P przez podstawienie wartoci atrybutw t jako argumentw P.

Zakadamy ponadto (wane!), e kada propozycja p uzyskana w ten sposb ma war-

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

Rozdzia 4. Zmienne relacyjne

TUPLE {SNO SNO('S6'), SNAME NAME('migy'), STATUS 30, CITY 'Szczecin'}

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

Wicej terminologii: Niech P bdzie predykatem zmiennej relacyjnej R, niech warto

R w danym punkcie czasu bdzie relacj r. Relacja r (jej zawarto) stanowi rozszerzenie (ang. extension) P w danym punkcie czasu. Rozszerzenie jest zmienne w czasie,
lecz predykat (ang. predicate lub intension) jest stay.

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}

Wynik zawiera wszystkie krotki relacji S postaci:

TUPLE {SNO s, SNAME n, STATUS t}

ktre wystpuj w relacji S i maj posta (dla dowolnej wartoci c atrybutu CITY):
TUPLE {SNO s, SNAME n, STATUS t, CITY c}

Innymi sowy, wynik reprezentuje biece rozszerzenie nastpujcego predykatu:

Istnieje takie miasto CITY, e dostawca SNO ma kontrakt z nasz firm, ma nazwisko
SNAME, status STATUS, a jego siedziba znajduje si w miecie CITY.
Naley zauway, e ten predykat posiada trzy parametry, a odpowiadajca mu relacja
(projekcja relacji dostawcw z pominiciem atrybutu CITY) ma trzy atrybuty CITY nie jest
parametrem, w logice tego typu element nazywa si zmienn zwizan (ang. bound variable).
Ten predykat nie wykorzystuje bowiem wartoci atrybutu CITY, zakada jedynie, e takowy
istnieje (dodatkowe informacje na temat zmiennych zwizanych oraz kwalifikatorw mona
znale w dodatku A). Innym sposobem wykazania, e ten predykat ma trzy parametry, jest
analiza nastpujcego predykatu, ktry jest logicznym odpowiednikiem powyszego:
Dostawca SNO ma kontrakt z nasz firm, ma nazwisko SNAME, status STATUS, a jego
siedziba znajduje si w jakim miecie (innymi sowy: w dowolnym miecie, nie wiemy gdzie
i nie jest to wane).
Z powyszych rozwaa wynika, e perspektywy s reprezentacj okrelonych predykatw.
Wemy za przykad perspektyw SST zdefiniowan nastpujco:
VAR SST VIRTUAL (S {SNO, SNAME, STATUS});

Zmienne relacyjne i predykaty

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.

Dalsze uwagi na temat relacji i typw

Rozdzia 2. ma tytu Relacje i typy. Niestety w tamtym rozdziale nie miaem moliwoci wyjanienia najwaniejszej rnicy pomidzy tymi dwoma koncepcjami. W tym miejscu ju mam
t moliwo.
Jak stwierdziem wyej, baza danych w dowolnym punkcie czasu moe by uznana za kolekcj propozycji o wartoci TRUE. Za przykad moe posuy propozycja Dostawca S1 ma
podpisany kontrakt z nasz firm, ma nazwisko Kowalski, status 20, a jego siedziba znajduje si
w miecie Warszawa. Co wicej, pokazaem, e wartoci atrybutw pojawiajce si w takich
propozycjach (w przykadzie: S1, Kowalski, 20 i Warszawa) s wartociami atrybutw krotki
odpowiadajcej danej propozycji i oczywicie kada warto atrybutu jest odpowiedniego
typu. Wynika z tego nastpujca wasno:
Typy s zbiorami elementw, o ktrych mona mwi,
relacje s prawdziwymi stwierdzeniami na temat tych elementw.

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

Rozdzia 4. Zmienne relacyjne

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.

Podrozdzia chciabym zakoczy nieco bardziej formalnym spojrzeniem na tematy w nim

omwione. Jak stwierdziem, baz danych mona postrzega jako kolekcj prawdziwych
propozycji. W rzeczywistoci baza danych wraz z operatorami majcymi zastosowanie do
propozycji z tej bazy danych (a cilej: do zbiorw propozycji) jest systemem logicznym. Piszc
tu system logiczny, mam na myli system formalny jak na przykad geometria Euklidesa posiadajcy aksjomaty (prawdy zaoone) i reguy zwizkw, na podstawie ktrych mona za pomoc tych aksjomatw dowodzi twierdzenia (prawdy wynikajce). To byo niesamowicie przewidujce ze strony Codda, e gdy w 1969 roku wynalaz model relacyjny,
stwierdzi, i baza danych (pomimo nazwy) nie jest po prostu kolekcj danych, lecz zbiorem
prawdziwych stwierdze (propozycji). Te propozycje (podstawowe, to znaczy reprezentowane przez bazowe zmienne relacyjne) s aksjomatami w zadanym systemie logicznym. Reguy
zwizkw to te reguy, na podstawie ktrych jedne propozycje mona przeksztaci w inne,
innymi sowy, s to reguy zastosowania operatorw algebry relacyjnej. Gdy system generuje
wynik wyraenia relacyjnego (na przykad wynik zapytania), tak naprawd tworzy now
prawd w oparciu o dan, a w rezultacie: udowadnia twierdzenie!
Gdy kto zrozumie i zaakceptuje powysze spostrzeenie, zauway, e dziki temu na potrzeby problemu bazy danych dostpny staje si cay mechanizm formalnej logiki. Innymi
sowy, nastpujce pytania stan si zagadnieniami logicznymi (i jako takie mog by poddane analizie logicznej i mona na nie uzyska logiczne odpowiedzi):
W jaki sposb uytkownik powinien postrzega baz danych?
Jak powinny wyglda ograniczenia integralnociowe?
Jak powinien wyglda jzyk zapyta?
Jaki jest najlepszy sposb implementacji zapyta?
Bardziej oglnie: w jaki sposb wylicza wyraenia relacyjne?
W jaki sposb wyniki powinny by prezentowane uytkownikowi?
Przede wszystkim: w jaki sposb projektowa bazy danych?

Dalsze uwagi na temat relacji i typw

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

modyfikacja atrybutu s wygodne, lecz nieprecyzyjne. Modyfikacja odbywa si zawsze

na poziomie zbioru krotek (nie jednej krotki).

Kada zmienna relacyjna posiada przynajmniej jeden klucz (kandydujcy). Klucze maj

wasno unikalnoci i nieredukowalnoci. Wartociami kluczy s krotki.

Niektre zmienne relacyjne posiadaj klucze obce. SQL obsuguje okrelone dziaania

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-

powiednie bazowe zmienne relacyjne. Proces odwzorowania dziaa przede wszystkim

dziki wasnoci domknicia. Jest prosty dla operacji odczytu, lecz w przypadku modyfikacji jest znacznie bardziej skomplikowany. Regua wymiennoci przyjmuje, e nie ma potrzeby rozgraniczania pomidzy bazowymi a wirtualnymi zmiennymi relacyjnymi.
Typy s dla relacji tym, czym rzeczowniki s dla zda.
Typy i relacje s konieczne i wystarczajce, aby zaprezentowa dane. Oczywicie mwi-

my tu o poziomie logicznym. Jak doskonale wiemy, na poziomie fizycznym uyteczne s

inne konstrukcje. Ta rnica wynika z tego, e na obydwu poziomach abstrakcji najwaniejsze zadania nieco si rni. Midzy innymi dlatego poziom fizyczny jest celowo pozostawiony poza zakresem zainteresowania modelu relacyjnego.

88

Rozdzia 4. Zmienne relacyjne

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');

Na tak zdefiniowanej perspektywie wykonamy nastpujce zapytanie:

SELECT DISTINCT LSSP.STATUS, LSSP.OTY
FROM
LSSP
WHERE LSSP.PNO IN
(SELECT P.PNO
FROM
P
WHERE P.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

Rozdzia 4. Zmienne relacyjne