IDZ DO
IDZ DO
PRZYKŁADOWY ROZDZIAŁ
PRZYKŁADOWY ROZDZIAŁ
Relacyjne bazy danych
SPIS TRE CI
SPIS TRE CI
Autorzy: Mark Whitehorn, Bill Marklyn
KATALOG KSIĄŻEK
KATALOG KSIĄŻEK
Tłumaczenie: Marek Pętlicki
ISBN: 83-7361-095-2
KATALOG ONLINE
KATALOG ONLINE
Tytuł oryginału: Inside Relational Databases 2nd Edition
Format: B5, stron: 338
ZAMÓW DRUKOWANY KATALOG
ZAMÓW DRUKOWANY KATALOG
Relacyjne bazy danych stanowią podstawę większo ci współczesnych systemów
TWÓJ KOSZYK
TWÓJ KOSZYK
informatycznych. Choć poszczególne systemy zarządzania bazami danych różnią się
między sobą w wielu aspektach, są jednak oparte na wspólnych podstawach
DODAJ DO KOSZYKA
DODAJ DO KOSZYKA
teoretycznych. Je li zrozumiesz ten wspólny fundament, będziesz mógł z łatwo cią
budować na nim własne aplikacje, niezależnie od tego, czy jako systemu bazodanowego
użyjesz komercyjnego Oracle'a lub MS SQL-a, czy też bezpłatnego PostgreSQL.
CENNIK I INFORMACJE
CENNIK I INFORMACJE
Książka Relacyjne bazy danych została napisana w celu jak najbardziej przystępnego
obja nienia zagadnień relacyjnego modelu danych oraz jego znaczenia dla projektantów
ZAMÓW INFORMACJE
ZAMÓW INFORMACJE
i twórców baz danych. Obja nienia tych, często skomplikowanych zagadnień, przybliżają
O NOWO CIACH
O NOWO CIACH
tajniki relacyjnego modelu danych wykorzystując przykłady, a nie wzory matematyczne.
Dzięki ich zrozumieniu będziesz mógł projektować bazy danych szybsze, bardziej
ZAMÓW CENNIK
ZAMÓW CENNIK
elastyczne i lepiej dopasowane do zadań, jakie mają realizować.
Poznasz:
CZYTELNIA
CZYTELNIA
" Podstawowe pojęcia związane z bazami danych: tabele, rekordy, pola
" Sposoby pobierania danych za pomocą zapytań
FRAGMENTY KSIĄŻEK ONLINE
FRAGMENTY KSIĄŻEK ONLINE
" Tworzenie raportów z wyselekcjonowanych danych
" Projektowanie baz z uwzględnieniem związków między danymi, klucze i indeksy
" Sposoby przestrzegania reguł integralno ci danych
" Tworzenie zaawansowanych wielowarstwowych aplikacji opartych o bazy danych
" Programowanie wyzwalaczy, procedur zapisanych, użycie perspektyw
" Zastosowania transakcji
" Teorię baz danych: reguły Codda, normalizację
" Język SQL
Dr Mark Whitehorn dysponuje ogromną wiedzą w dziedzinie teorii relacyjnych baz
danych. Dzięki cyklowi artykułów w brytyjskim magazynie Personal Computer World
udało mu się przybliżyć ją tysiącom użytkowników. Po prostu doskonała. Wyja niając
Wydawnictwo Helion
tajniki zagadnień związanych z relacyjnymi bazami danych, Mark Whitehorn oraz Bill
ul. Chopina 6
Marklyn osiągnęli o wiele więcej niż inni autorzy. Uczynili ten temat ciekawym, a nawet
44-100 Gliwice
wręcz zabawnym, co stawia ich poza zasięgiem jakiejkolwiek konkurencji .
tel. (32)230-98-63
Neil Fawcett, Edytor techniczny, VNU Business Publications
e-mail: helion@helion.pl
Spis treści
Przedmowa do drugiego wydania........................................................9
Rozdział 1. Wstęp .............................................................................................11
Czym jest baza danych? ....................................................................................................11
Bazy danych a systemy zarządzania nimi.........................................................................12
Systemy obsługi relacyjnych baz danych..........................................................................12
Cel powstania książki........................................................................................................13
Kto powinien przeczytać tą książką ? ................................................................................15
Struktura książki................................................................................................................16
Dodatkowe uwagi..............................................................................................................17
Podzią kowania ..................................................................................................................18
Część I Prosta baza danych........................................................19
Rozdział 2. Wstęp do części pierwszej ...............................................................21
Tabele................................................................................................................................21
Formularze ........................................................................................................................22
Zapytania...........................................................................................................................22
Raporty..............................................................................................................................23
Rozdział 3. Tabele.............................................................................................25
Wiersze i kolumny rekordy i pola................................................................................26
Tworzenie tabeli................................................................................................................28
Typy danych................................................................................................................29
Rozmiar pola...............................................................................................................34
Ogólne porady dotyczące projektowania tabel ...........................................................35
Tabele podstawowe...........................................................................................................39
Rozdział 4. Formularze.......................................................................................41
Wykorzystanie kilku formularzy obsługujących pojedynczą tabelą .................................44
Pola tekstowe udostą pniane tylko do odczytu...................................................................44
Pola tekstowe zawierające połączone dane z kilku pól.....................................................45
Nie wszystkie pola tabeli muszą wystą pować w formularzu............................................46
Kontrola wprowadzanych danych.....................................................................................47
Wykorzystanie formularzy może być kontrolowane ........................................................47
Formularze mogą być stronami WWW ............................................................................47
Podsumowanie ..................................................................................................................48
Rozdział 5. Zapytania........................................................................................51
Pobieranie danych za pomocą zapytań..............................................................................51
Zapytania, tabele wynikowe oraz tabele podstawowe ......................................................52
4 Relacyjne bazy danych
Wyliczanie danych ............................................................................................................56
Inne rodzaje zapytań..........................................................................................................57
Graficzne narzą dzia służące do tworzenia zapytań...........................................................57
SQL i perspektywy............................................................................................................58
Rozdział 6. Raporty ...........................................................................................59
Rozdział 7. Podsumowanie części pierwszej .......................................................61
Część II Jednoużytkownikowa baza danych,
zbudowana z wielu tabel.................................................65
Rozdział 8. Wstęp do części drugiej...................................................................67
Rozdział 9. Problemy z pojedynczymi tabelami....................................................69
Nadmiarowość danych ......................................................................................................70
Błą dy typograficzne ..........................................................................................................70
Aktualizacja danych ..........................................................................................................71
Modyfikacja danych..........................................................................................................72
Podsumowanie ..................................................................................................................72
Rozdział 10. Zastosowanie kilku tabel.................................................................75
Nadmiarowość danych ......................................................................................................77
Błą dy typograficzne ..........................................................................................................79
Aktualizacja danych ..........................................................................................................79
Modyfikacja danych..........................................................................................................80
Rozdział 11. Współdziałanie wielu tabel ...............................................................81
Bazy danych są zaprojektowane w celu modelowania świata rzeczywistego ..................82
Rozdział 12. Prawidłowy projekt tabel..................................................................83
Kilka słów na temat normalizacji i modelowania związków encji ...................................85
Identyfikacja klas obiektów ..............................................................................................85
Rozdział 13. Związki w świecie rzeczywistym.......................................................89
Związki typu jeden do wielu .............................................................................................89
Związki typu jeden do jednego .........................................................................................90
Związki typu wiele do wielu .............................................................................................90
Brak związku.....................................................................................................................90
Rozdział 14. Modelowanie związków....................................................................91
Klucze główne...................................................................................................................93
Wykorzystanie kilku kolumn w charakterze klucza głównego ..................................95
Wybór właściwego klucza głównego .........................................................................96
Definiowanie klucza głównego...................................................................................97
Klucze obce.......................................................................................................................97
Definiowanie klucza obcego.......................................................................................98
Czą ściowe podsumowanie ................................................................................................98
Klucz główny ..............................................................................................................99
Klucz obcy ..................................................................................................................99
Złączenia ...........................................................................................................................99
Związki typu jeden do wielu ...................................................................................99
Związki typu jeden do jednego .............................................................................102
Związki typu wiele do wielu .................................................................................104
Ogólne informacje na temat złączeń.........................................................................111
Spis treści 5
Rozdział 15. Ponowna analiza czterech elementów baz danych...........................117
Tabele..............................................................................................................................120
Zapytania.........................................................................................................................121
Formularze ......................................................................................................................127
Raporty............................................................................................................................128
Rozdział 16. Integralność danych.......................................................................131
Integrowanie danych opłacalny wysiłek....................................................................131
Błą dy integralności danych i ich przyczyny ...................................................................132
Błą dy w unikalnych danych w ramach pojedynczego rekordu ................................133
Błą dy w standardowych danych w ramach pojedynczego rekordu ..........................133
Błą dy pomią dzy danymi w różnych polach..............................................................135
Błą dy pomią dzy kluczami w różnych tabelach ........................................................136
Inne zagadnienia dotyczące integralności .......................................................................142
Definiowanie zasad integralności danych w systemie ....................................................143
Deklarowana i proceduralna integralność odwołań ........................................................144
Rozdział 17. Budowanie aplikacji wykorzystującej bazę danych...........................147
Wykorzystanie narzą dzi graficznych, makr oraz ją zyków skryptowych........................149
Tworzenie prostego interfejsu...................................................................................149
Wykorzystanie narzą dzi graficznych........................................................................150
Wykorzystanie makra ...............................................................................................151
Wykorzystanie ją zyka programowania.....................................................................152
Które z rozwiązań jest najlepsze? .............................................................................154
Inne ją zyki SQL .........................................................................................................156
Rozdział 18. Podsumowanie części drugiej.........................................................157
Część III Bazy danych w środowisku wieloużytkownikowym.........159
Rozdział 19. Architektura baz danych ................................................................161
Siedem elementów architektury......................................................................................161
Element pierwszy......................................................................................................162
Element drugi............................................................................................................162
Element trzeci ...........................................................................................................162
Element czwarty........................................................................................................162
Element piąty ............................................................................................................163
Element szósty ..........................................................................................................163
Element siódmy ........................................................................................................163
Interfejs aplikacji na komputerze klienta, baza danych na serwerze ..............................164
Architektura klient-serwer (dwuwarstwowa)..................................................................167
Architektura trójwarstwowa (wielowarstwowa) .............................................................169
Aplikacje internetowe .....................................................................................................170
Wybór odpowiedniej architektury...................................................................................172
Podsumowanie ................................................................................................................173
Rozdział 20. Bardziej skomplikowane projekty baz danych..................................175
Model użytkownika.........................................................................................................177
Model logiczny................................................................................................................177
Model fizyczny................................................................................................................178
Model logiczny i fizyczny w praktyce ............................................................................179
Podsumowanie czą ściowe...............................................................................................182
Kolejna wielka zaleta narzą dzi CASE ............................................................................183
Różnice pomią dzy modelem logicznym a fizycznym.....................................................184
Normalizacja ...................................................................................................................186
6 Relacyjne bazy danych
Inżynieria odwrotna.........................................................................................................187
Różne metodologie..........................................................................................................187
Rozdział 21. Wyzwalacze, zapisane procedury oraz perspektywy .........................189
Wyzwalacze ....................................................................................................................189
Terminologia wyzwalaczy ........................................................................................190
Typowe zastosowanie wyzwalaczy, wywoływanych przed i po zdarzeniu .............190
Wią cej informacji na temat wyzwalaczy ..................................................................191
Zapisane procedury .........................................................................................................191
Wyzwalacze i zapisane procedury podsumowanie ....................................................192
Perspektywy ....................................................................................................................193
Rozdział 22. Transakcje, dzienniki, kopie zapasowe, blokowanie i współbieżność ..197
Transakcje .......................................................................................................................197
Wycofanie .......................................................................................................................198
Dzienniki...................................................................................................................198
Przywrócenie transakcji ..................................................................................................201
Archiwizowanie dzienników ....................................................................................201
Lokalizacja ......................................................................................................................202
Strategie wykonywania kopii zapasowych .....................................................................202
Zalecenia ...................................................................................................................203
Inne możliwości ........................................................................................................204
Blokowanie......................................................................................................................204
Zakleszczenia............................................................................................................205
Współbieżność ................................................................................................................206
Blokowanie wierszy i stron.............................................................................................207
Co czeka nas w kolejnych rozdziałach............................................................................207
Rozwiązanie testu............................................................................................................207
Część IV Tematy związane z bazami danych ................................209
Rozdział 23. Relacyjne i nierelacyjne bazy danych ..............................................211
Wiele tabel a relacyjność baz danych .............................................................................211
Nazewnictwo...................................................................................................................212
Rozdział 24. Reguły Codda ................................................................................215
Do czego potrzebna jest znajomość reguł Codda............................................................215
Zwią złość a czytelność....................................................................................................216
Krótkie wprowadzenie ....................................................................................................216
Reguły .............................................................................................................................216
Podsumowanie ................................................................................................................226
Rozdział 25. Normalizacja..................................................................................229
Normalizacja ...................................................................................................................229
Zależność funkcyjna........................................................................................................231
Definicja wymagań ...................................................................................................232
Pierwsza forma normalna................................................................................................234
Druga forma normalna ....................................................................................................236
Odpowiedzi ...............................................................................................................239
Trzecia forma normalna ..................................................................................................240
Podsumowanie czą ściowe...............................................................................................242
Pierwsza forma normalna (1NF lub pierwszy poziom normalizacji) .......................242
Druga forma normalna (2NF lub drugi poziom normalizacji)..................................242
Trzecia forma normalna (3NF lub trzeci poziom normalizacji) ...............................242
Spis treści 7
Dalsze postą powanie.......................................................................................................242
Przykład praktyczny..................................................................................................243
Normalizacja a usuwanie wszelkiej nadmiarowości.......................................................245
Podsumowanie ................................................................................................................251
Rozdział 26. Katalog systemowy........................................................................253
Katalog systemowy .........................................................................................................253
Rozdział 27. Operacje na danych .......................................................................255
Operatory relacyjne.........................................................................................................255
Selekcja .....................................................................................................................257
Projekcja ...................................................................................................................257
Suma .........................................................................................................................258
Różnica .....................................................................................................................259
Przecią cie ..................................................................................................................260
Iloczyn.......................................................................................................................260
Złączenie ...................................................................................................................262
Podział.......................................................................................................................262
Podsumowanie ................................................................................................................264
Rozdział 28. SQL...............................................................................................267
SELECT oraz FROM......................................................................................................270
DISTINCT ................................................................................................................270
WHERE ....................................................................................................................271
Warunki.....................................................................................................................272
ORDER BY ..............................................................................................................275
Wzorce dopasowań ...................................................................................................277
Podzapytania .............................................................................................................278
Funkcje wbudowane .................................................................................................279
GROUP BY ..............................................................................................................282
GROUP BY...HAVING............................................................................................287
Praca z wieloma tabelami .........................................................................................289
Złączenia wewną trzne...............................................................................................293
Złączenia zewną trzne................................................................................................293
Suma tabel.................................................................................................................295
Podsumowanie instrukcji SELECT ..........................................................................298
INSERT...........................................................................................................................299
UPDATE .........................................................................................................................301
DELETE..........................................................................................................................303
Analiza przypadku...........................................................................................................304
DISTINCTROW .............................................................................................................306
Podsumowanie ................................................................................................................310
8 Relacyjne bazy danych
Rozdział 29. Dziedziny .......................................................................................311
Rozdział 30. Indeksy przyśpieszanie działania bazy danych.............................313
Rozdział 31. Znaczenie wartości NULL...............................................................319
Rozdział 32. Klucze główne ...............................................................................323
Dodatki .......................................................................................327
Dodatek A Słowniczek ....................................................................................329
Skorowidz......................................................................................331
Rozdział 14.
Modelowanie związków
Udało nam sią umieścić klasy obiektów w tabelach bazy danych. Znamy również sieć
zależności, istniejących pomią dzy obiektami. Kolejnym zadaniem bą dzie odwzorowa-
nie tych związków w bazie.
Do realizacji tego zadania bą dą nam potrzebne pewne narzą dzia:
klucze główne oraz obce;
złączenia.
Te dwa poją cia określają dwa różne typy narzą dzi, udostą pnianych przez relacyjne bazy
danych, lecz najczą ściej oba są wykorzystywane jednocześnie. Na przykład: przed zde-
finiowaniem złączenia należy utworzyć jeden lub kilka kluczy głównych, zaś dopiero
zbudowanie złączenia nadaje sens istnieniu klucza głównego. Nie należy przejmować
sią tym, że nazwy tych mechanizmów brzmią dla nas niezrozumiale; w rzeczywistości
są to dość proste poją cia. Zrozumienie ich jest jednak bardzo ważnym krokiem, bowiem
dzią ki nim wiele zagadnień relacyjnych baz danych nabiera głą bszego sensu. Trudno
byłoby wyobrazić sobie istnienie relacyjnych baz danych bez kluczy i złączeń.
Zagadnienia dotyczące kluczy i złączeń najprościej omawiać na podstawie przykładu.
Jednym z najczą ściej stosowanych związków są związki typu jeden do wielu , omó-
wione w poprzednim rozdziale. Przedstawiliśmy tam związek pomią dzy klientami
oraz zamówieniami. Wykorzystamy ten przykład także i tutaj.
Pamiętajmy o stosowanej konwencji nazewnictwa: określają nazwy
tabel, natomiast określają nazwy kolumn. Odwołania do kolumn
w tabeli są zapisywane jako nazwa tabeli, po której widnieje kropka, a następnie
nazwa kolumny. Dlatego zapis określa kolumnę
tabeli .
Jedna z zaprezentowanych tu tabel przedstawia uproszczoną wersją tabeli ,
zawierającą odnośniki do tabeli oraz :
92 Część II f& Jednoużytkownikowa baza danych, zbudowana z wielu tabel
z
z z
Tabele te odnalezć można w pliku R14.MDB. W celu zwią kszenia ich czytelności klucze
główne zostały zapisane wytłuszczoną czcionką, natomiast klucze obce kursywą.
Zdaję sobie sprawę z tego, że tabela jest daleka od doskonałości, po-
nieważ nadal zawiera informacje nadmiarowe (dotyczące towarów). Zamiast tego
należałoby zastosować osobną tabelę . Jest to jednak zabieg celowy chcia-
łem uniknąć nadmiernej komplikacji. Udoskonaleniem tabeli zajmiemy
się w dalszej części niniejszego rozdziału.
Po bliższym zapoznaniu sią z tabelami oraz możemy zauważyć, że
dane łączące te tabele, znajdują sią w dwóch kolumnach (po jednej w każdej z tabel)
o tej samej nazwie ( ). Bez trudu można domyślić sią , że liczba w kolumnie
, w pierwszym wierszu tabeli , oznacza, że pani Alicja Kwiat-
kowska zakupiła biurko. Liczba w tym miejscu jest wykorzystana w charakterze
wskaznika rekordu w tabeli , zawierającego dane pani Alicji. Analogicznie, na
podstawie innych danych możemy dowiedzieć sią , że zamówienie zrealizował pracow-
nik Jan Kowalski.
92 (03-07-17) C:\Andrzej\PDF\Relacyjne bazy danych\r14-07.doc
Rozdział 14. f& Modelowanie związków 93
W celu wyjaśnienia mechanizmu modelowania związków możemy posłużyć sią za-
równo przykładowymi związkami pomią dzy tabelą a tabelą , jak
i związkami pomią dzy tabelą a tabelą , ponieważ w obydwu
przypadkach związki te są tworzone i obsługiwane na identycznych zasadach. Na razie
zajmiemy sią związkami pomią dzy tabelą a tabelą , lecz w odpo-
wiednim czasie wrócimy jeszcze do tabeli .
Aby wykorzystać kolumny w charakterze mechanizmu definiującego związki
pomią dzy dwiema tabelami, każda z kolumn w o nazwie musi spełniać
określone założenia. W skrócie można powiedzieć, że kolumna w tabeli
musi być kluczem głównym, natomiast kolumna w tabeli
musi być kluczem obcym.
W celu utworzenia związku jeden do wielu pomią dzy dwiema tabelami należy utwo-
rzyć w jednej z nich klucz główny, w drugiej natomiast klucz obcy. Klucz główny określa
stroną związku określaną przez jeden , natomiast klucz obcy definiuje stroną związku
określaną przez wiele . Wartości kluczy są przez nas wykorzystywane do modelo-
wania związków pomią dzy klientami i zamówieniami w świecie rzeczywistym.
Poją cia kluczy głównych i obcych są bardzo istotne. Poświą ćmy im wią c nieco uwagi.
Klucze główne
Wymagania dotyczące klucza głównego są dosyć jasne. Moglibyśmy wymienić je teraz po
kolei, lecz wydaje sią , że wydedukowanie ich przyniesie nieco wią cej satysfakcji, a przede
wszystkim bą dzie miało lepszy skutek pedagogiczny. Wiele zagadnień w relacyjnej teorii
baz danych można dość łatwo wywieść za pomocą logicznego rozumowania.
Pamią tamy o tym, że kolumna w tabeli zawiera klucze główne tej
tabeli. Zawartość pól w tej kolumnie identyfikuje poszczególnych klientów. Klucz o war-
tości identyfikuje Edwarda Dzikiego, klucz o wartości Alicją Kwiatkowską, itd.
Co stałoby sią , gdyby klucz, identyfikujący Alicją Kwiatkowską, został zmieniony na
wartość ? Tabele oraz (patrz nastą pna strona) wyglądałyby w tej
sytuacji nastą pująco:
z
Poprzez zamianą wartości jednego pola w tabeli nie można określić tego, komu
należy przesłać rachunek za zamówienia numer nie wiemy, czy krzesło kupiła
Alicja, czy Edward. (Dodatkowy problem wystą puje z zamówieniami o numerach ,
94 Część II f& Jednoużytkownikowa baza danych, zbudowana z wielu tabel
oraz , lecz to zagadnienie omówimy w podrozdziale, w którym zajmować sią bą dziemy
kluczami obcymi.) Pierwszą zasadą dotyczącą kluczy głównych, którą udało nam sią
wydedukować, jest wią c konieczność zachowania unikalności wszystkich kluczy
głównych w tabeli, bowiem jakiekolwiek duplikaty nie bą dą tolerowane.
Kolejną sytuacją, którą warto rozpatrzyć, jest brak wartości klucza głównego w tabeli.
z
W kolumnie brakuje wartości dla klienta o nazwisku Henryk Bez-
bożny. Czy w takim razie nie bą dzie on musiał płacić za zamówienia nr ? Niewiele
lepsza bą dzie sytuacja, gdy tabele bą dą wyglądać tak:
z
94 (03-07-17) C:\Andrzej\PDF\Relacyjne bazy danych\r14-07.doc
Rozdział 14. f& Modelowanie związków 95
W tym przypadku odpowiedz nadal nie jest oczywista. Najlepszym sposobem na unik-
nią cie takich niejasności jest zadbanie o to, by wszystkie pola w kluczu głównym posia-
dały określoną wartość. Brak wartości w bazie danych określa sią wartością NULL
(zwaną również wartością pustą lub wartością zerową). Jest to dość specyficzna
wartość, a jej obsługa w bazach danych wiąże sią z dość ciekawymi kwestiami. Roz-
dział 31., umieszczony w czą ści IV, jest poświą cony w całości właśnie zagadnieniom
związanym z wartością .
W ten sposób udało nam sią określić drugą zasadą dotyczącą kluczy głównych. Klucze
główne nie mogą sią powtarzać oraz nie mogą zawierać pustych wartości.
Systemy zarządzania bazami danych, takie jak MS Access, obsługują klucze główne
z uwzglą dnieniem tych zasad. Należy tylko wskazać systemowi, które z kolumn zawie-
rają klucze główne, a zastosuje on zabezpieczenia przed złamaniem tych reguł. Można
sią zastanawiać, czy rzeczywiście system jest w stanie sprawdzić, czy wartość pola
bą dącego kluczem głównym, nie wystą puje już w tabeli, szczególnie w przypadku tabel
zawierających setki tysią cy wierszy danych? W rzeczywistości mechanizmy obsługi
kluczy głównych w porządnych relacyjnych systemach zarządzania bazą danych są
w stanie dokonać takiego sprawdzenia w sposób tak szybki, że nie bą dzie to miało
widocznego wpływu na czas, jaki zajmuje dopisanie wiersza do tabeli.
Wykorzystanie kilku kolumn
w charakterze klucza głównego
Przedstawione jak dotąd w tym podrozdziale wymagania (unikalność oraz konieczność
określenia wartości) dotyczące kluczy głównych, nie ograniczają ich konstrukcji tylko
do jednej kolumny. Możemy na przykład wykorzystać kolumny oraz .
Naruszenie zasady unikalności danych nastąpi wyłącznie w sytuacji, gdy pola obydwu
kolumn bą dą identyczne w rozpatrywanym rekordzie danych. Możemy wią c posiadać
w naszej tabeli osoby o nazwisku Jan Kowalski oraz Jan Kowal, lecz nie możemy za-
pisać dwóch osób o nazwisku Jan Kowalski. Wykorzystanie wią cej niż jednej kolumny
w charakterze klucza głównego jest wią c jak najbardziej dopuszczalne, lecz z reguły
nie jest zalecane. Bywają jednak przypadki, w których takie rozwiązanie ma pierw-
szorzą dne znaczenie. Jedno z takich zastosowań omówimy w podrozdziale, w którym
zajmiemy sią związkami typu wiele do wielu .
96 Część II f& Jednoużytkownikowa baza danych, zbudowana z wielu tabel
Wybór właściwego klucza głównego
Wybór klucza głównego dla tabeli może być trudny, dodatkowo sprawą tą komplikuje
możliwość zastosowania do tego kilku kolumn tabeli.
Jak już wspomnieliśmy, istnieją sytuacje, w których wykorzystanie kilku kolumn w cha-
rakterze klucza głównego stanowi jedyne rozsądne rozwiązanie. Jeśli jednak nie można
znalezć bezpośredniego powodu, dla którego mielibyśmy zdecydować sią na klucz
główny złożony z kilku kolumn, należy wybrać rozwiązanie na bazie pojedynczej
kolumny. Nie jest to zasada niepodważalna to tylko dobra rada. Klucze główne zbu-
dowane na podstawie pojedynczej kolumny są łatwiejsze w obsłudze i z reguły działają
szybciej. Oznacza to, że w przypadku zastosowania klucza głównego zbudowanego na
podstawie pojedynczej kolumny, zapytania w bazie danych bą dą wykonywane szybciej.
Kolejny problem stanowi właściwy wybór kolumny. Podstawowym kryterium wyboru
jest tutaj zapewnienie unikalności wartości w kolumnie. W przypadku tabeli pracow-
ników wybór kolumny jest oczywiście dość kiepski, ponieważ istnieją wielkie
szanse na to, że ich imiona bą dą sią powtarzać.
Jedna z anegdot na temat Billa Gatesa, założyciela i wieloletniego prezesa firmy
Microsoft głosi, że jest to człowiek o skłonnościach paranoidalnych. Jednym z obja-
wów choroby miałby być zakaz zatrudniania w firmie osób o takim samym imieniu,
jakie nosi Prezes. W jednej z wersji tej anegdoty utrzymuje się, że zanim zatrudniono
kolejnego Billa, liczba pracowników Microsoftu wynosiła powyżej pięciuset osób.
Historia ta jest bardzo interesująca, lecz, niestety, nieprawdziwa. Bill Marklyn,
współautor tej książki, został zatrudniony w firmie Microsoft na długo przed osią-
gnięciem przez nią wspomnianej liczby pracowników. Można z tego wysnuć wnio-
sek, że w Microsofcie nie stosuje się klucza głównego w tabeli , zbudo-
wanego na podstawie kolumny .
Najprostszym i powszechnie stosowanym sposobem zapewnienia unikalności klucza
głównego jest wykorzystanie do tego celu samego systemu bazy danych. Wią kszość
relacyjnych systemów zarządzania bazą danych posiada mechanizmy umożliwiające
automatyczne generowanie unikalnych identyfikatorów dla każdego dopisywanego
wiersza. Access na przykład udostą pnia w tym celu specjalny typ danych o nazwie
. Jest to doskonałe rozwiązanie w przypadku identyfikacji obiektów,
takich jak zamówienia, pracownicy, itd. Warto jednak zorientować sią , czy w tabeli
nie jest już zapisana informacja, zapewniająca unikalność danych dzią ki swojej spe-
cyficznej charakterystyce. Taką informacją w przypadku pracowników może być na
przykład numer PESEL. Jest to z założenia unikalny i niezmienny identyfikator każ-
dego obywatela Rzeczpospolitej Polskiej, wią c jest idealny w celu zdefiniowania klu-
cza głównego tabeli (w każdym razie w firmie zatrudniającej wyłącznie obywateli na-
szego kraju)1.
1
Należy oczywiście wziąć pod uwagą realia. Jeśli zatrudnienie w firmie obcokrajowców wchodzi w rachubą ,
zastosowanie numeru PESEL nie jest uzasadnione przyp. tłum.
96 (03-07-17) C:\Andrzej\PDF\Relacyjne bazy danych\r14-07.doc
Rozdział 14. f& Modelowanie związków 97
Generowanie naprawdę unikalnych identyfikatorów nie jest zadaniem tak prostym, ja-
kim się może wydawać. Więcej informacji na ten temat można znalezć w rozdziale 32.
Definiowanie klucza głównego
Definiowanie klucza głównego tabeli jest bardzo ważnym elementem w procesie jej
konstruowania. Pomimo, że nie jest to książka na temat programu MS Access, sposób
zdefiniowania klucza głównego zademonstrujemy na przykładzie tego programu. Ważne
jest również spostrzeżenie różnicy pomią dzy kluczami głównymi a obcymi. Klucz główny
należy zdefiniować na etapie definiowania struktury tabeli. Tworzenie klucza obcego
nie musi natomiast być dokonywane w sposób jawny. Wykorzystanie wartości określo-
nej kolumny w charakterze klucza obcego może zostać dokonane dopiero podczas two-
rzenia złączenia tabel.
W jaki sposób możemy zatem zdefiniować klucz główny w programie MS Access?
Na etapie tworzenia struktury tabeli zaznaczamy odpowiedni wiersz. Nastą pnie klikamy
przycisk z ikoną klucza na pasku narzą dzi. Najczą ściej kolumna definiująca klucz
główny jest umieszczana jako pierwsza w tabeli, nie jest to jednak konieczne. Jeśli
wystąpi potrzeba zdefiniowania klucza głównego na wią kszej ilości kolumn, zazna-
czamy odpowiednie kolumny i klikamy przycisk z ikoną klucza. Warto zwrócić uwagą
na to, że w nomenklaturze zastosowanej w polskiej wersji programu MS Access, klucze
główne noszą nazwą kluczy podstawowych.
Klucze obce
Pozostaniemy przy naszym przykładzie, wykorzystującym tabele oraz
. Przejdzmy teraz do omówienia kluczy obcych w modelowaniu związków typu
jeden do wielu . Klucz obcy jest po prostu referencją pewnego klucza głównego.
W naszym przypadku kluczem obcym jest kolumna .
Ponownie zastosujemy regułą intuicyjnego wyodrą bniania zasad regulujących istnienie
kluczy obcych. Wezmy pod uwagą wartości z poniższych tabel.
z
Zwróćmy uwagą na ostatni wiersz tabeli . Zawiera on wartość w kolumnie
. Jest to nieco dziwne, ponieważ w tabeli nie istnieje wiersz o takiej
wartości w kolumnie . W tym przypadku nie jesteśmy w stanie określić
98 Część II f& Jednoużytkownikowa baza danych, zbudowana z wielu tabel
adresata rachunku za zamówienie numer . Można sią zatem domyślić, że tego typu
sytuacja jest nie do przyją cia w bazie danych. Stąd właśnie wynika pierwsza zasada,
dotycząca kluczy obcych. Zasada ta wymusza stosowanie w kluczach obcych wyłącz-
nie takich wartości, jakie wystą pują w odpowiednim dla nich kluczu głównym.
Definiowanie klucza obcego
Klucze obce są definiowane w ramach procesu definicji złączenia tabel. Proces ten
zostanie omówiony w dalszej czą ści niniejszego rozdziału.
Częściowe podsumowanie
Zanim przejdziemy do kolejnych zagadnień, podsumujmy informacje, z którymi zapo-
znaliśmy sią do tej pory. Ponownie prezentujemy znane nam już tabele:
z
98 (03-07-17) C:\Andrzej\PDF\Relacyjne bazy danych\r14-07.doc
Rozdział 14. f& Modelowanie związków 99
Klucz główny
Każda tabela w relacyjnej bazie danych musi posiadać klucz główny. Klucz taki składa
sią z co najmniej jednego pola (kolumny). Żadna z wartości klucza głównego nie może
być pusta. Każdy z wierszy w tabeli musi posiadać unikalną wartość klucza głównego.
Klucz główny jest definiowany na etapie definicji tabeli.
Klucz obcy
Klucze obce nie są wymaganym elementem tabel. Innymi słowy, każda tabela musi
posiadać zdefiniowany klucz główny, lecz nie wszystkie muszą definiować klucze obce.
Jeśli istnieje związek pomią dzy dwiema tabelami, jedna z nich musi posiadać klucz
obcy, na podstawie którego pobierane są odpowiednie dane z drugiej tabeli. W prak-
tyce bywa tak, że wią kszość tabel posiada klucze obce i zupełnie dopuszczalne jest
wystą powanie wią cej niż jednego klucza obcego w tabeli. Jeśli tak jest w istocie, tabela
musi posiadać związki z kilkoma innymi tabelami. Definicja klucza obcego nastą puje
podczas definicji złączenia.
Złączenia
Jak wspomnieliśmy na początku niniejszego rozdziału, narzą dziami, służącymi do okre-
ślania związków w ramach baz danych, są:
klucze (główne i obce),
złączenia.
Nadszedł czas na omówienie drugiego z wymienionych narzą dzi. W poprzednim roz-
dziale zostały wymienione trzy możliwe typy związków, jakie można modelować
w bazie danych:
jeden do wielu ,
wiele do wielu ,
jeden do jednego .
Nasze rozważania dotyczące złączeń rozpoczniemy od najczą ściej spotykanych związ-
ków typu jeden do wielu .
Związki typu jeden do wielu
Załóżmy, że posiadamy dwie tabele:
100 Część II f& Jednoużytkownikowa baza danych, zbudowana z wielu tabel
z
Czy można określić typ związku pomią dzy tymi tabelami na podstawie ich zawartości?
Odpowiedz brzmi: tak i nie. Nie możemy być absolutnie pewni co do typu związku,
lecz możemy dokonać pewnych, bardzo prawdopodobnych założeń.
Możemy założyć, że jest kluczem głównym. Pierwszą wska-
zówką, pozwalającą nam na takie założenie, jest nazwa kolumny; drugą stanowią uni-
kalne wartości w ramach tej kolumny. Podobne założenie możemy przyjąć na temat
kolumny .
Można zaobserwować, że wartości w kolumnie odpowiadają
wartościom w kolumnie , dlatego bardzo prawdopodobne jest, że
kolumna jest kluczem obcym.
Czemu mają służyć powyższe dociekania? Nie namawiam czytelnika do tego, aby
oglądał zawartość tabel w celu odgadnią cia typów związków pomią dzy nimi. Celem
powyższego ćwiczenia jest uświadomienie czytelnikowi szczególnych własności, które
pomagają w procesie definiowania związków pomią dzy tabelami i zarządzania nimi.
Możemy wią c zająć sią procesem modelowania złączenia typu jeden do wielu . Proces
ten składa sią z nastą pujących kroków:
Podejmujemy decyzją umieszczenia w bazie danych dwóch tabel,
reprezentujących klasy obiektów zamówień oraz klientów.
Związek pomią dzy tymi klasami obiektów jest typu jeden do wielu ,
co oznacza, że klient może mieć związek z wieloma zamówieniami.
Tworzymy tabele, reprezentujące wspomniane klasy obiektów, nadając
im nazwy oraz .
Każda z wymienionych tabel bą dzie miała klucz główny, przede wszystkim
dlatego, że taki jest wymóg w stosunku do tabel w relacyjnych bazach danych.
Klucze główne nazwiemy oraz .
100 (03-07-17) C:\Andrzej\PDF\Relacyjne bazy danych\r14-07.doc
Rozdział 14. f& Modelowanie związków 101
Ponieważ nasze tabele mają za zadanie odzwierciedlać obiekty ze świata
rzeczywistego, mamy zamiar modelować również związki pomią dzy
reprezentowanymi klasami obiektów. W naszym przypadku bą dzie to związek
typu jeden do wielu .
W celu umożliwienia realizacji związku w bazie danych musimy utworzyć
odpowiedni klucz obcy w tabeli reprezentującej stroną określaną przez
wiele . W naszym przypadku bą dzie to tabela .
Kolumna klucza obcego może mieć dowolną nazwą , jednak powszechną
praktyką jest nadawanie kolumnom tego typu takich samych nazw, jakie
posiadają kolumny klucza głównego, do którego sią odnoszą.
Do tabeli dodajemy nową kolumną o nazwie .
Wskazujemy systemowi bazy danych istnienie związku typu jeden do wielu
pomią dzy rozpatrywanymi tabelami.
W przypadku aplikacji MS Access zdefiniowanie złączenia pomią dzy tabelami polega
na otwarciu Edytora relacji (ponieważ związki w polskiej wersji MS Access noszą na-
zwą relacji, co jest w pewnym konflikcie z przyją tą terminologią dotyczącą relacyj-
nych baz danych), dodaniu do relacji dwóch tabel, a nastą pnie przeciągnią ciu nazwy
kolumny na . Po otworzeniu sią okna zatytu-
łowanego Edytowanie relacji należy zaznaczyć opcją Wymuszaj więzy integralności.
Utworzenie związku zatwierdzamy przez kliknią cie przycisku OK. Osoby zaintereso-
wane znaczeniem wspomnianych wią zów integralności odsyłam do rozdziału 16., zatytu-
łowanego Integralność danych .
Rysunek 14.1.
W operacji przedstawionej na rysunku 14.1 zdefiniowano złączenie tabel w bazie danych.
Efektem dodatkowym było nadanie kolumnie roli klucza obcego.
W konsekwencji tej zmiany system odmówi wprowadzenia do kolumny
jakiejkolwiek wartości nie wystą pującej w kluczu głównym, do którego odnosi
sią klucz obcy, reprezentowany przez tą kolumną .
102 Część II f& Jednoużytkownikowa baza danych, zbudowana z wielu tabel
Przedstawiony przez nas proces definiowania złączenia w systemie Access unaocznił,
w jaki sposób złączenia oraz klucze są wzajemnie ze sobą powiązane. W celu zdefi-
niowania złączenia, podobnego do omówionego powyżej, należy wcześniej zdefiniować
klucz główny, a także utworzyć kolumną , która ma realizować funkcją klucza obcego.
Dopiero jednak utworzenie złączenia tabel nada kolumnie rolą klucza obcego.
Należy zdawać sobie sprawą z kilku faktów, dotyczących definiowania złączeń tabel.
Złączenie (z wymuszeniem wią zów integralności) nie zostanie utworzone w przypad-
ku, gdy:
kolumna wskazana po stronie jeden związku nie jest kluczem głównym,
typy danych w łączonych kolumnach nie są identyczne,
w polach klucza obcego (strona wiele ) istnieją wartości, które nie wystą pują
w polach klucza głównego (strona jeden ).
Wspomnieliśmy wcześniej o istnieniu możliwości wykorzystania w Accessie kolumn
typu w charakterze kluczy głównych tabel. Kolumny tego typu nie
możemy zastosować w charakterze klucza obcego. Typem odpowiadającym typowi
, który może zostać zastosowany w charakterze odpowiedniego klucza obcego,
jest typ , podtyp . Nie jest to, jak mo-
głoby sią wydawać, złamanie wymogu identyczności typów danych w kluczach głów-
nych i wskazujących na nie kluczach obcych. Typ jest specjalnym przy-
padkiem typu , z tą różnicą, że wartości
w kolumnach tego typu podlegają automatycznemu zwią kszaniu podczas dopisywania
nowej kolumny.
Związki typu jeden do jednego
Związki typu jeden do jednego stosowane są raczej dość rzadko. Tworzenie ich jest
jednak bardzo proste, ponieważ proces definicji złączeń tabel w takich związkach jest
bardzo podobny do definicji złączenia tabel w związkach typu jeden do wielu . Podobnie
jak miało to miejsce w przypadku związków typu jeden do wielu , należy przeciągnąć
nazwą kolumny z klucza głównego na nazwą kolumny klucza obcego. Jedyna różnica
polega na tym, że klucz obcy w tym przypadku nie może zawierać zduplikowanych
wartości. Istnieją dwie metody zapewnienia unikalności wartości w ramach kolumn
kluczy obcych.
Pierwsza metoda polega na utworzeniu klucza obcego tabeli na podstawie jej klucza
głównego. Innymi słowy, złączenie nastąpi pomią dzy kluczami głównymi dwóch tabel,
z których jeden bą dzie również pełnił rolą klucza obcego.
Drugi sposób polega na utworzeniu indeksu bez powtórzeń na kolumnie klucza obcego.
Taka operacja spowoduje, że jako wartości pól w tej kolumnie nie zostaną przyją te
wartości już wystą pujące. Ten właśnie sposób na zapewnienie unikalności danych
w kolumnie omówimy nieco szerzej.
102 (03-07-17) C:\Andrzej\PDF\Relacyjne bazy danych\r14-07.doc
Rozdział 14. f& Modelowanie związków 103
W przykładowej bazie danych każdemu pracownikowi musi zostać przyznany pokój do
wyłącznego wykorzystania, lecz ze wzglą du na koszty żaden pracownik nie może mieć
do dyspozycji wią cej niż jeden pokój.
z z
Kolumna jest kluczem głównym, wią c w jej przypadku nie są
dopuszczalne powtórzenia. Na kolumnie w trakcie projektowania
tabeli został założony unikalny indeks, wią c również w tym przypadku nie są dopuszczal-
ne powtórzenia. Dodatkowo kolumna jest kluczem obcym, wią c
wartości pól tej kolumny muszą odpowiadać istniejącym wartościom pól kolumny
odpowiedniego klucza głównego, to znaczy kolumny .
Z tego powodu poniższa tabela zawiera nieprawidłową zawartość w kolumnie klucza ob-
cego, ponieważ wartość nie wystą puje w kolumnie klucza głównego tabeli :
Także zawartość tabeli zaprezentowanej poniżej jest niedopuszczalna, ponieważ war-
tość wystą puje dwukrotnie w kolumnie :
104 Część II f& Jednoużytkownikowa baza danych, zbudowana z wielu tabel
Utworzenie związku typu jeden do jednego wymaga wykorzystania Edytora relacji.
Dodajemy do relacji tabele oraz (poprzez wykorzystanie przycisku
Pokaż tabele z paska narzą dzi). Przeciągamy nazwą kolumny
na nazwą kolumny . Po pojawieniu sią okna zatytułowanego Edy-
towanie relacji zaznaczamy opcją Wymuszaj więzy integralności. Zwróćmy uwagą na to,
że w tym przypadku domyślnym typem złączenia jest jeden do jednego . Zatwierdzamy
utworzenie złączenia, klikając przycisk OK (rysunek 14.2).
Rysunek 14.2.
Ważne jest ustanowienie unikalnego indeksu na kolumnie przed
zdefiniowaniem złączenia.
Należy również zdawać sobie sprawą z tego, że pomimo istnienia związku pomią dzy
dwoma kluczami głównymi, związek ten nie jest symetryczny. W tabeli zawierającej
klucz główny złączenia (na przykład ), mogą istnieć elementy, które nie
bą dą wystą pować w tabeli definiującej klucz obcy (na przykład ). Niedopusz-
czalna jest jednak sytuacja odwrotna (istnienie wartości klucza obcego, nie wystą pu-
jących w kluczu głównym złączenia).
Związki typu wiele do wielu
Związki typu wiele do wielu są stosunkowo powszechne. Ich reprezentacja w bazie
danych może początkowo wydać sią skomplikowana, lecz z chwilą, gdy opanujemy
zasady, tworzenie tego typu związków okaże sią bardzo łatwe.
Rozważmy związki pomią dzy klientami a pracownikami. Każdy klient może być obsłu-
giwany przez różnych pracowników, każdy z pracowników natomiast ma do czynienia
z wieloma klientami. Dlatego właśnie związki pomią dzy pracownikami a klientami są typu
wiele do wielu . Kolejnym pytaniem, na które należy sobie odpowiedzieć, jest: przez co
warunkowane są powiązania pomią dzy klientami a pracownikami? . Możliwe jest nawią-
zywanie kontaktów klientów z pracownikami bez dokonywania jakichkolwiek zakupów,
lecz najprawdopodobniej tego typu kontakty nie mają znaczenia, przynajmniej z punktu
104 (03-07-17) C:\Andrzej\PDF\Relacyjne bazy danych\r14-07.doc
Rozdział 14. f& Modelowanie związków 105
widzenia naszej bazy danych. Jedynym ważnym rodzajem kontaktów klientów z naszymi
pracownikami jest kontakt związany z realizacją zamówień. Za każdym razem, gdy kupo-
wany jest towar, zostaje złożone zamówienie. Zatem możemy stwierdzić, że powiązania
pomią dzy klientami a pracownikami warunkowane są przez te zamówienia.
Zastanówmy sią teraz nad powiązaniami pomią dzy klientami a zamówieniami. Są to
związki typu jeden do wielu . Tego samego typu związki istnieją pomią dzy pracow-
nikami a zamówieniami.
z
z z
Być może wyda sią to nieprawdopodobne, lecz dla utworzenia pary związków typu jeden
do wielu w taki sposób, jaki opisaliśmy powyżej, wystarczy, aby powstał związek
typu wiele do wielu . W naszym przypadku, niejako samoistnie, powstał związek typu
wiele do wielu pomią dzy tabelami oraz . Tak naprawdą nie ist-
nieje w systemach relacyjnych baz danych żaden dodatkowy mechanizm, definiujący
związki wiele do wielu . Zawsze w przypadku konieczności utworzenia takiego związku
posługujemy sią dwoma związkami typu jeden do wielu .
Istnieje jednak wymóg utworzenia tych powiązań w taki sposób, jak zostało to przed-
stawione na rysunku 14.3.
106 Część II f& Jednoużytkownikowa baza danych, zbudowana z wielu tabel
Rysunek 14.3.
Dowolne dwa związki typu jeden do wielu , obejmujące trzy tabele, nie oznaczają
jeszcze związku wiele do wielu , czego przykładem może być sytuacja przedstawiona
na rysunku 14.4.
Rysunek 14.4.
Z mojego doświadczenia wynika, że dość czą sto można znalezć tabelą , która bą dzie
pomocna w celu utworzenia związku typu wiele do wielu . W naszym przykładzie
stała sią nią tabela . Bywają jednak sytuacje, gdy taka tabela nie istnieje.
Warto o tym wspomnieć, aby przybliżyć czytelnikowi problemy, które dość czą sto
mogą wystąpić w pracach nad rzeczywistymi bazami danych. W celu ilustracji posłu-
żymy sią ponownie naszą bazą danych. Dokonamy na niej kolejnych modyfikacji,
zwią kszając nieco poziom jej realizmu. Nasz przykład wyjaśni również, w jakich sytu-
acjach niezbą dny może okazać sią klucz główny zbudowany na dwóch kolumnach.
Konieczność zastosowania kluczy głównych
zbudowanych na kilku kolumnach
Rozpatrzmy nasz przykład z rozdziału 12. Zidentyfikowaliśmy w nim sześć klas
obiektów:
klienci,
towary,
zamówienia,
pracownicy,
budynki,
pokoje.
Skoncentrowaliśmy sią wówczas na trzech tabelach:
106 (03-07-17) C:\Andrzej\PDF\Relacyjne bazy danych\r14-07.doc
Rozdział 14. f& Modelowanie związków 107
Początkowo struktura tabeli była stosunkowo prosta, ponieważ wykorzy-
stywaliśmy ją w celach demonstracyjnych. Teraz musimy przyjrzeć sią bliżej struk-
turze tej tabeli, aby dostosować ją do naszych potrzeb. Przez chwilą bą dziemy po-
sługiwać sią przykładami z pliku R14B.MDB, nastą pnie wykorzystamy zawartość
pliku R14C.MDB.
z z
z
108 Część II f& Jednoużytkownikowa baza danych, zbudowana z wielu tabel
Jak widać, tabela składa sią z kolumny , która
stanowi klucz główny, oraz trzech kluczy obcych, odwołujących sią do innych tabel.
Po przeanalizowaniu tej struktury można dojść do wniosku, że pozwala ona na realizo-
wanie zamówień jednej tylko sztuki towaru. Na przykład zamówienie nr 3 zostało zło-
żone przez Henryka Bezbożnyego i dotyczy zakupu stołu. Co moglibyśmy zrobić, gdyby
pan Henryk zażyczył sobie do kompletu na przykład czterech krzeseł? W obecnej
strukturze tabel nie ma możliwości zapisania kilku pozycji w ramach jednego zamó-
wienia; nie ma nawet możliwości zapisania kilku sztuk jednego towaru. Z tego powodu
każda sztuka towaru musi być zapisywana na osobnym zamówieniu, zatem zakup stołu
i czterech krzeseł wymaga wpisania do bazy pią ciu osobnych zamówień.
Istnieje kilka rozwiązań tego problemu. Dwa z nich wydają sią logiczne i proste w im-
plementacji, lecz mogą spowodować poważne problemy w bazie danych. Najlepszym
rozwiązaniem bą dzie wią c omówienie obu niebezpiecznych rozwiązań, aby zapobiec
ich nieopatrznemu zastosowaniu.
Pierwsze, łatwe ale błą dne rozwiązanie wygląda nastą pująco:
Wygląda niezle, nieprawdaż? Zamiast pojedynczej kolumny przechowującej odwołania
do towarów, mamy ich pią ć. Henryk ma swoje cztery krzesła i stół, pozostali klienci
mogą również kupować wią ksze ilości sztuk poszczególnych towarów.
Mogłoby sią wydawać, że to rozwiązanie jest całkiem dobre, lecz w praktyce jest zu-
pełnie bezużyteczne. Po pierwsze, co stanie sią , gdy liczba pozycji na zamówieniu bą dzie
wią ksza niż pią ć? Możemy oczywiście dodać odpowiednią liczbą kolumn.
Załóżmy, że w ramach pojedynczego zamówienia maksymalna ilość sztuk wszystkich
towarów bą dzie równa 30. W tym celu potrzebujemy 30 kolumn w tabeli. Problem polega
na tym, że przecią tnie na zamówieniu wystą pują trzy pozycje, wią c średnio w każdym
wierszu danych w tabeli marnujemy około 27 kolumn. To jest rzeczywiste marno-
trawstwo miejsca na dysku i może znacznie spowolnić działanie bazy danych.
Dodatkowy problem może polegać na rozproszeniu informacji w ramach rekordu danych.
Nie wiemy, która z kolumn zawiera informacje o krzesłach, wią c w celu odnalezienia
liczby krzeseł na zamówieniu musimy przeszukać zawartość całego wiersza danych.
To jest stanowczo złe rozwiązanie.
108 (03-07-17) C:\Andrzej\PDF\Relacyjne bazy danych\r14-07.doc
Rozdział 14. f& Modelowanie związków 109
Nieco lepszym, choć również niewystarczająco dobrym pomysłem, jest utworzenie na-
stą pującej struktury:
L z
W tym podejściu każdy typ towaru jest reprezentowany przez jedną kolumną w tabeli,
a liczba, zapisana w polu kolumny określa ilość sztuk danego towaru, znajdującą sią
na zamówieniu. Henryk może kupić cztery krzesła i stół, a my wiemy dokładnie, gdzie
szukać informacji na temat krzeseł. Nie musimy również martwić sią o najwią kszą ilość
sztuk towarów na zamówieniu, ponieważ w kolumnach odpowiadających danemu typowi
towaru, możemy wpisać dowolną liczbą naturalną. Doskonale. Co jednak stanie sią ,
gdy dodamy nowy typ towaru do naszego asortymentu? Bą dziemy musieli dodać nową
kolumną do tabeli . Wiele z firm posiada asortyment znacznie przekraczający
dopuszczalną liczbą kolumn w wią kszości systemów baz danych (najczą ściej 255).
Z tego wzglą du takie rozwiązanie stanowczo nie nadaje sią do zastosowania.
Nadszedł w końcu czas na zademonstrowanie właściwego rozwiązania. Wszystkie umie-
szczone poniżej tabele (aż do końca rozdziału) pochodzą z pliku R14C.MDB.
Najlepsze rozwiązanie naszego problemu okaże sią bardzo proste, szczególnie dla osób
przywykłych już do wykorzystywania wielu tabel. W przypadku zamówień i towarów
mamy ponownie do czynienia ze związkiem typu wiele do wielu . Skonstruujmy
zatem związek wiele do wielu za pomocą dwóch związków jeden do wielu po-
mią dzy tabelami , a dodatkową, trzecią tabelą. Tabela ta powinna
znalezć sią w strukturze związku pomią dzy tabelami oraz . Rozsądną
dla niej nazwą może być . Odpowiednie tabele bą dą wyglądały
nastą pująco:
110 Część II f& Jednoużytkownikowa baza danych, zbudowana z wielu tabel
L z z
Tabele te zawierają wszystkie informacje, które próbowaliśmy przechować za pomocą
innych dwóch kiepskich rozwiązań. Oprócz tego ostatnie rozwiązanie nie jest obciążone
problemami, które stanowiły integralny element w przypadku rozwiązań wcześniejszych.
Nie marnujemy miejsca w bazie danych, ponieważ wszystkie pola we wszystkich ko-
lumnach są wypełnione.
Nie istnieje jakiekolwiek ograniczenie dotyczące liczby pozycji na zamówieniu czy też
liczby różnych typów towarów w asortymencie. Dodanie nowej pozycji do zamówienia
polega na dodaniu wiersza w tabeli .
Jeśli wystąpi potrzeba dodania nowego typu towarów do bazy danych, wystarczy do-
pisać wiersz w tabeli . Nie ma żadnej potrzeby ingerencji w struktury tabel.
Udało nam sią w końcu udoskonalić strukturą naszej bazy danych. Jaki jednak ma to
związek z wielokolumnowymi kluczami głównymi?
Kluczem głównym tabeli zamówień jest . Podobnie
jest kluczem głównym tabeli towarów. Jednakże ani kolumna ,
ani też nie może być kluczem głównym tabeli , ponie-
waż w każdej z nich zupełnie poprawne bą dą wielokrotne wystąpienia tych samych
wartości. Klucz główny można natomiast zbudować w oparciu o obie te kolumny.
Dzią ki temu nie ma problemu z powtarzaniem sią wartości w polach każdej z tych
kolumn z osobna.
110 (03-07-17) C:\Andrzej\PDF\Relacyjne bazy danych\r14-07.doc
Rozdział 14. f& Modelowanie związków 111
L z z
Niedopuszczalne jest jednak powtórzenie sią par wartości w obydwu kolumnach, ponie-
waż stanowi to naruszenie zasady funkcjonowania klucza głównego.
L z z
Taka sytuacja stanowi dość dobre odzwierciedlenie rzeczywistości, ponieważ z reguły
na zamówieniu nie powinien pojawiać sią kilka razy ten sam typ towaru. Do zapisu
liczby sztuk jednego typu towaru w ramach zamówienia służy kolumna
w tabeli .
Ogólne informacje na temat złączeń
Omówienie złączeń w związkach typu wiele do wielu zawierało dość sporo dodat-
kowych informacji. Warto wią c zrobić małą przerwą i podsumować informacje, które
pojawiły sią do tej pory.
Wykorzystywanie wierszy zamiast kolumn zwiększa elastyczność
Omówione powyżej rozwiązanie problemu umieszczania kilku pozycji na zamówieniu
jest bardzo elastyczne. Możemy swobodnie dodawać do zamówień pozycje, obejmu-
jące dowolną liczbą sztuk danego towaru. Możemy również dodawać nowe towary do
bazy danych. Obie te możliwości są dostą pne bez konieczności wprowadzania jakich-
kolwiek dalszych modyfikacji w samej strukturze bazy danych.
Kilkakrotnie wspominałem już, że nowoczesne systemy zarządzania bazami danych
(do których należy także MS Access) umożliwiają modyfikacją struktury baz danych
w sposób dość swobodny i nieskomplikowany. Możliwość taka jest bardzo ważna w pro-
cesie definicji struktury bazy danych, lecz w okresie wykorzystania bazy do codziennej
pracy zmiany jej struktury powinny być ograniczone do naprawdą wyjątkowych sytuacji.
Pamią tajmy, że w oparciu o tabele zbudowaliśmy formularze, zapytania i raporty.
Każda zmiana struktury tabel wymaga sprawdzenia poprawności działania pozostałych
112 Część II f& Jednoużytkownikowa baza danych, zbudowana z wielu tabel
elementów bazy. Sytuacja, w której zmiana w strukturze tabel pociąga za sobą ko-
nieczność wprowadzenia zmian w którymś z pozostałych elementów bazy, jest bardzo
prawdopodobna. Można wią c wysnuć wniosek, że każda konstrukcja bazy danych, która
wymusza czą ste dokonywanie zmian w strukturze tabel, jest bardzo mało funkcjonalna.
Problem nie tylko w tym, że aplikacja taka jest dość kłopotliwa w utrzymaniu, lecz
nasuwa bardzo prawdopodobne przypuszczenie, że popełniono jakiś błąd lub prze-
oczenie w trakcie definicji struktury bazy danych.
Wykorzystanie interfejsu graficznego
Złączenia wykorzystują liczby, zarówno w kluczach głównych, jak i w kluczach obcych.
Liczby są wykorzystywane głównie z powodów praktycznych (bo tak jest po prostu
najwygodniej), lecz bez problemu można wykorzystywać w tym celu napisy, czyli dane
typu tekstowego. Należy jednak zdawać sobie sprawą z tego, że nie powinno mieć
miejsca rą czne wypełnianie kolumn kluczy obcych w tabelach.
Wezmy ponownie naszą tabelą . W celu wypełnienia zamówień
wykorzystamy wygodny i estetyczny GUI Graphic User Interface (Graficzny interfejs
użytkownika). Dzią ki temu bą dziemy mieli możliwość wyboru klienta z jednej listy
rozwijalnej, pracownika z drugiej, natomiast towaru z trzeciej listy (rysunek 14.5).
Rysunek 14.5.
W ramach formularza użytkownik wprowadza wyłącznie niezbą dne informacje. Cała
praca związana z uzupełnianiem kluczy obcych, wykonywana jest przez system zarzą-
dzania bazą danych.
Omówienie sposobów tworzenia takich aplikacji lub wrą cz serwisów WWW, wyko-
rzystywanych w charakterze formularzy, obsługujących bazy danych, wykracza znacznie
poza zakres tej książki. Książka niniejsza omawia bowiem zagadnienia relacyjnych
baz danych, nie zaś sposoby wykorzystania aplikacji MS Access do tworzenia aplikacji
wykorzystujących bazy danych. Osoby zainteresowane pewnymi standardowymi me-
chanizmami, dostą pnymi w programie MS Access, mogą spróbować przeanalizować
112 (03-07-17) C:\Andrzej\PDF\Relacyjne bazy danych\r14-07.doc
Rozdział 14. f& Modelowanie związków 113
przykładowy formularz o nazwie w pliku R14C.MDB. Formularz ten demon-
struje podstawowy sposób tworzenia interfejsu użytkownika, zbudowanego w oparciu
o kilka tabel, powiązanych pomią dzy sobą za pomocą różnych złączeń.
Nastą pny rozdział zawiera jednak kilka ogólnych porad dotyczących tworzenia takich
interfejsów, których głównym zadaniem jest odseparowanie użytkownika końcowego
od abstrakcji relacyjnego modelu danych.
Mniej oczywiste klasy obiektów
Zasada projektowania tabel, przedstawiona przez nas we wcześniejszych rozdziałach,
polegała na identyfikacji klas obiektów świata rzeczywistego. W tym rozdziale zde-
cydowałem sią jednak na wprowadzenie tabeli , którą raczej trudno
wydedukować na podstawie analizy świata rzeczywistego. Na swoją obroną mam to,
że uprzedzałem, iż jest to zaledwie ogólna zasada, od której mogą istnieć wyjątki. Listą
tych wyjątków da sią jednak przedstawić w sposób opisowy: otóż wyjątek mogą sta-
nowić sytuacje wystą powania związków typu wiele do wielu . W przypadku istnienia
takiego związku przy jednoczesnym braku tabeli, która nadawałaby sią do wykorzy-
stania w charakterze łącznika tworzącego związek typu wiele do wielu , najpraw-
dopodobniej zaistnieje konieczność utworzenia mniej intuicyjnej tabeli, takiej, jaką są
właśnie .
Terminologia
Jak mieliśmy okazją sią przekonać, złączenia i klucze są proste w użyciu oraz niezwykle
użyteczne. Udało sią nam zatem postawić kolejny krok w stroną świata specjalistów
baz danych. W tym świecie bardzo ważna jest umieją tność posługiwania sią skompli-
kowaną terminologią, akceptowaną przez innych specjalistów baz danych. Jeśli nie
zastosujemy sią do tych zasad, zamiast należnego nam szacunku napotkamy mur niechą ci
jako intruzi. Dlatego ważna jest znajomość nastą pujących poją ć: rodzic, potomek, po-
siadanie, nadrzędny, podrzędny, zależność czy też klucz obcy.
Na przykład tabela jest w posiadaniu tabela , dlatego jest jej po-
tomkiem. Tabela jest podrzędna wobec tabeli , która jest jej rodzi-
cem i również posiada tabelą , wią c jest nadrzędna w stosunku do niej.
Wszystkie tabele potomne posiadają przynajmniej jeden klucz obcy. Ponieważ tabela
posiada dwie tabele rodziców, zawiera dwa klucze obce
oraz . Klucze obce ustalają zależność pomią dzy rodzicem a potomkiem.
W tym przypadku mamy do czynienia z dwoma kluczami obcymi, wią c istnieją dwie
zależności.
Zwróćmy uwagą na to, że klucze obce tabeli tworzą związki z kluczami
głównymi swoich rodziców. Jest to ważny wymóg, ponieważ tabele rodziców zawsze
znajdują sią po stronie jeden związku typu jeden do wielu .
Rysunek 14.6 prezentuje związki pomią dzy tabelami z bieżącej wersji omawianej przez
nas bazy danych.
114 Część II f& Jednoużytkownikowa baza danych, zbudowana z wielu tabel
Rysunek 14.6.
A oto zawartość wszystkich sześciu tabel bazy danych:
z z
z
114 (03-07-17) C:\Andrzej\PDF\Relacyjne bazy danych\r14-07.doc
Rozdział 14. f& Modelowanie związków 115
L z z
Czytelnikowi należy sią małe wyjaśnienie. Nie powinienem robić sobie żartów z termi-
nologii stosowanej przez specjalistów baz danych. W wią kszości dziedzin życia ko-
nieczna jest jakaś forma werbalnego skrótu myślowego, używanego w celu usprawnienia
komunikacji. Należy jednak zdawać sobie sprawą z tego, że terminologia taka powin-
na być stosowana wyłącznie w celu usprawnienia komunikacji, nie zaś w celu zabawy
(z nowicjuszami) w kotka i myszką , polegającej na niepotrzebnej komplikacji pod-
stawowych zagadnień, które w gruncie rzeczy są proste i zrozumiałe. Zrozumienie
podstaw jest tutaj kluczowe; po pokonaniu tego etapu cała skomplikowana terminolo-
gia jest wchłaniana przez nowego adepta w sposób nieomalże naturalny.
Zademonstrowane powyżej tabele nadal nie stanowią idealnego rozwiązania proble-
mu, ponieważ tabela wciąż zawiera nadmiarowe, powtarzające się dane
(na przykład dotyczące dostawców). Jest to zabieg celowy, ponieważ te niedosko-
nałości posłużą jako ilustracja zabiegu usuwania nadmiarowych danych, którym
zajmiemy się w rozdziale 15.
Wyszukiwarka
Podobne podstrony:
01 Projektowanie relacyjnej bazy danych Czym jest relacyjUML a relacyjne bazy danych2004 11 Porównanie serwerów relacyjnych baz danych Open Source [Bazy Danych]Bazy Danych relacyjne czy obiektowe2009 02 Relacyjna baza danych HSQLDB [Bazy Danych][03] Bazy Danych Relacyjny Model DanychBAZY DANYCH Streszczenie z wykładówStrona polecenia do bazy danychMySQL Mechanizmy wewnętrzne bazy danychBazy danych w CADPostać normalna (bazy danych) – Wikipedia, wolna encyklopediawięcej podobnych podstron