MICHAEL J. HERNANDEZ

BAZY DANYCH DLA ZWYKŁYCH ŚMIERTELNIKÓW

Mojej matce, Esteli R. Pund. Może nie jest to jeszcze symfonia, ale przynajmniej opus.
Pamięci mojego teścia, LeRoya W. Bonnicksen, który zawsze we mnie wierzył. Każdemu, kto bezskutecznie próbował stworzyć relacyjną bazę danych.

Przekład z języka angielskiego: Piotr Nowakowski
MIKOM
Projekt okładki: Michał Rosiński
Redakcja: Irena Pielińska
Skład komputerowy: Dorota Świstak

Książka prezentuje podejście do projektowania baz danych niezależne od stosowanego oprogramowania. Dobry projekt bazy danych pozwala zaoszczędzić wiele cennego czasu podczas pisania gotowego programu w dowolnym języku. Autor opierając się na swych wieloletnich doświadczeniach przygotował prosty podręcznik prezentujący podstawowe zasady projektowania relacyjnych baz danych.
Autor wprowadza podstawowe pojęcia projektowania baz danych bez używania technicznego żargonu. Zaletą książki jest bezpośrednie podejście do zagadnień i bogactwo praktycznych przykładów. Każdy projektant baz danych znajdzie tu odpowiednią dla siebie metodologię projektowania takich baz danych, które będą naprawdę efektywnie działać.
Książka może posłużyć wszystkim, którzy rozpoczynają pracę nad bazą danych przy wykorzystaniu takich narzędzi jak Access, FoxPro, Visual Basic, Turbo Pascal, C++, Power Builder.
Zastrzeżonych nazw firm i produktów użyto w książce wyłącznie w celu identyfikacji.

Copyright � EDU-MIKOM Wszystkie prawa zastrzeżone. Reprodukcja bez zezwolenia zabroniona.
Wydawca:
EDU-MIKOM s.c., ul. Andrzejowska 3, 02-312 Warszawa, tel. [phone]
Druk:
ZWP "HEL", Ul. Grenadierów 77, Warszawa, tel. [phone]
ISBN 83-87102-52-0 Warszawa, sierpień 1998
#5

Spis treści

Słowo wstępne 11
Przedmowa i podziękowania 13
Wprowadzenie 17
Kto powinien przeczytać tę książkę? 18
Cel niniejszej książki 19
Jak czytać tę książkę? 21
Organizacja książki 21
Słowo o przykładach i technikach opisywanych w tej książce 23

CZĘŚĆ I. Projektowanie relacyjnej bazy danych 27

1. Czym jest relacyjna baza danych? 29
Typy baz danych 29
Wczesne modele baz danych 29
Hierarchiczny model logiczny 30
Sieciowy model logiczny 32
Relacyjny model logiczny: krótka historia 34
Systemy zarządzania relacyjnymi bazami danych 38
Podsumowanie 40

2. Cele projektowania 41
Dlaczego należy przykładać wagę do projektowania? 41
Rola teorii 42
Korzyści płynące z opanowania poprawnej metodologii tworzenia projektów 44
Rola zrozumienia metod projektowania baz danych 44
Cele dobrego projektu 44
Zalety dobrego projektu 45
Metody projektowania baz danych 45
Metody projektowania prezentowane w tej książce 47
Podsumowanie 48

3. Terminologia 49
Dlaczego terminologia jest ważna? 49
Pojęcia związane z wartościami 50
#6
Dane 50
Informacje 50
Null (wartość zerowa) 51
Pojęcia związane ze strukturami 53
Tabele 53
Pola 55
Rekordy 55
Perspektywy 56
Klucze 57
Indeksy 58
Pojęcia związane z relacjami 58
Relacje 58
Typy relacji 59
Typy uczestnictwa 62
Stopień uczestnictwa 63
Pojęcia związane z integralnością 63
Atrybuty pól 63
Integralność danych 64
Podsumowanie 65

CZĘŚĆ II. Proces projektowania 67

4. Opis koncepcyjny 69
Dlaczego należy przejść przez całość procesu projektowania 69
Formułowanie definicji celu i założeń wstępnych 70
Analiza istniejącej bazy danych 71
Tworzenie struktur danych 72
Definiowanie relacji 72
Wprowadzanie reguł integralności 73
Definiowanie perspektyw 74
Kontrola integralności danych 74
Podsumowanie 75

5. Na początek 77
Prowadzenie wywiadów 77
Studium przypadku: Kraina Rowerów Mike'a 82
Formułowanie definicji celu 83
Poprawnie sformułowana definicja celu 83
Kompozycja definicji celu 84
Studium przypadku 86
Formułowanie założeń wstępnych 87
Dobrze sformułowane założenia wstępne 87
Kompozycja założeń wstępnych 88
#7
Studium przypadku 91
Podsumowanie 91

6. Analiza istniejącej bazy danych 93
Poznawanie istniejącej bazy danych 93
Papierkowe bazy danych 94
Spadkowe bazy danych 95
Prowadzenie analizy 96
Analiza sposobu gromadzenia danych 96
Analiza sposobu prezentowania informacji .98
Prowadzenie wywiadów 100
Prowadzenie wywiadów z pracownikami 105
Przegląd rodzajów i sposobów wykorzystania danych 106
Przegląd próbek 107
Przegląd wymagań informacyjnych 110
Prowadzenie wywiadów z kierownictwem 116
Przegląd aktualnych wymagań informacyjnych 117
Przegląd dodatkowych wymagań informacyjnych 117
Przegląd przyszłych wymagań informacyjnych 118
Przegląd ogólnych wymagań informacyjnych 118
Sporządzanie listy pól 119
Wstępna lista pól 119
Lista pól wyliczonych 123
Skonsultowanie obu list z pracownikami i kierownictwem 124
Studium przypadku 124
Podsumowanie 129

7. Definiowanie tabel 131
Tworzenie wstępnej listy tabel 131
Określanie tematów tabel 131
Wykorzystanie listy tematów 133
Interpretacja założeń wstępnych 136
Ostateczna lista tabel 137
Poprawianie nazw tabel 138
Definiowanie typów tabel 140
Formułowanie opisów tabel 141
Przypisywanie pól tabelom 145
Poprawianie pól 147
Poprawianie nazw pól 147
Pole doskonałe 150
Poprawianie tabel 155
Słowo na temat zwielokrotnionych danych i pól 155
Tabela doskonała 156
Tabele-podzbiory 160
#8
Studium przypadku 162
Podsumowanie 168

8. Klucze 171
Dlaczego klucze są ważne 171
Definiowanie kluczy 172
Klucze kandydujące 172
Klucze podstawowe 177
Pole niekluczowe 182
Integralność na poziomie tabel 182
Przegląd wstępnych struktur tabel 182
Studium przypadku 183
Podsumowanie 187

9. Atrybuty pól 189
Dlaczego atrybuty pól są ważne 189
Integralność na poziomie pól 190
Przekrój przez pole 191
Atrybuty ogólne 193
Atrybuty fizyczne 196
Atrybuty logiczne 199
Specyfikacja 204
Definiowanie atrybutów pól 207
Studium przypadku 210
Podsumowanie 210

10. Relacje 213
M Typy relacji 214
Relacje jeden-do-jednego 215
Relacje jeden-do-wielu 215
Relacje wiele-do-wielu 216
Określanie istniejących relacji 220
Definiowanie relacji 223
Relacje jeden-do-jednego i jeden-do-wielu 223
Relacja wiele-do-wielu 226
Przegląd struktur tabel 230
Poprawianie kluczy obcych 230
Definiowanie cech relacji 233
Reguły usuwania 233
Typy uczestnictwa 235
Stopień uczestnictwa 236
Skonsultowanie relacji z użytkownikami 237
Integralność na poziomie relacji 238
#9
Studium przypadku 238
Podsumowanie 241

11. Reguły integralności 243
Czym są reguły integralności? 243
Typy reguł integralności 245
Kategorie reguł integralności 247
Formułowanie i wprowadzanie reguł integralności 249
Wywiady z pracownikami i kierownictwem 249
Definiowanie reguł dotyczących pól 250
Definiowanie reguł dotyczących relacji 255
Tabele walidacji 260
Czym są tabele walidacji? 262
Wykorzystanie tabel walidacji do wspomagania reguł integralności 262
Przegląd formularzy reguł integralności 266
Studium przypadku 267
Podsumowanie 272

12. Perspektywy 273
Czym są perspektywy? 273
Przekrój przez perspektywę 274
Perspektywy danych 274
Perspektywy agregujące 278
Perspektywy walidacji 279
Określanie i definiowanie perspektyw 281
Rozmowy z pracownikami i kierownictwem 281
Definiowanie perspektyw 282
Przegląd dokumentacji perspektyw 289
Studium przypadku 289
Podsumowanie 294

13. Kontrola integralności danych 295
Dlaczego warto skontrolować integralność danych 296
Poprawianie integralności danych . 296
Na poziomie tabel 296
Na poziomie pól 297
Na poziomie relacji 297
Na poziomie reguł integralności 297
Na poziomie perspektyw 297
Jak przygotować dokumentacje bazy 298
I wreszcie koniec! 299
Studium przypadku - zakończenie .299
Podsumowanie 299
#10
CZĘŚĆ III. Pozostałe zagadnienia projektowe 301

14. Złe projekty - czego nie robić? 303
Projekt plikowy 303
Projekt w arkuszu kalkulacyjnym 304
Jak zerwać z nawykami związanymi z wyświetlaniem danych w arkuszu
kalkulacyjnym 306
Projekty oparte na konkretnych systemach zarządzania 307
Ostatnie przemyślenie 308
Podsumowanie 308

15. Naginanie i łamanie zasad 309
Kiedy można nagiąć lub złamać zasady? 309
Projektowanie analitycznej bazy danych 309
Poprawianie wydajności bazy 310
Dokumentowanie swoich poczynań 311
Podsumowanie 312

Na zakończenie 313
Dodatek A. Przykładowe projekty 315
Dodatek B. Diagramy 319
Dodatek C. Formularze dokumentacyjne 321
Skorowidz 325

#11
Słowo wstępne

Być może zastanawiasz się, po co ludziom kolejna książka o projektowaniu baz danych. Kiedy Mike Hernandez omawiał ze mną założenia niniejszej pracy, sam zadawałem sobie to pytanie. A jednak - co mogłeś stwierdzić po wstępnym przekartkowaniu książki, którą trzymasz w ręku - pozycja taka jest potrzebna. Istnieje wiele książek opisujących teorię i pojęcia, na których opiera się nauka o projektowaniu baz danych, lecz prawdopodobnie niewiele z nich (a może żadna) nie jest napisana ze szczególnego punktu widzenia, jakim dysponuje Mike. Człowiek ten postawił sobie za cel stworzenie książki, która byłaby mocno osadzona na solidnych podstawach nauk matematycznych, wykorzystując jednak tę wiedzę do opisu praktycznych zastosowań, a nie teoretycznych możliwości. Niezależnie od używanego przez Ciebie pakietu oprogramowania bazodanowego, książka ta będzie Ci służyć pomocą w projektowaniu własnych aplikacji.
Jeśli chodzi o mnie, zrozumiałem, że książka ta jest przeznaczona dla ludzi takich jak ja po otwarciu jej na wstępie do rozdziału szóstego i przeczytaniu poniższej sugestii:
"Nie traktuj struktury istniejącej bazy danych jako podstawy dla struktury nowej bazy danych."
Gdybym ktoś mi to powiedział wiele lat wcześniej, kiedy rozpoczynałem swoją przygodę z bazami danych, zaoszczędziłbym mnóstwo czasu! To właśnie chcę zaznaczyć: Mikę spędził wiele lat na projektowaniu baz dla swoich klientów; na analizowaniu, czytaniu i uczeniu się właściwych sposobów tworzenia aplikacji bazodanowych i całą tę wiedzę przelał na papier w książce, którą właśnie trzymasz.
Pozycja ta jest pełna rzeczowych informacji, zilustrowanych łatwymi do zrozumienia przykładami. Nie oznacza to, że ignoruje podstawy teoretyczne, na których opiera się efektywne projektowanie baz danych; została jednak stworzona z myślą o praktykach, nie o teoretykach.
Spędziłem sporo czasu, rozmawiając z Mike'em o projektowaniu baz danych. Przy kawie, na posiedzeniach, przed komputerem zawsze stwierdzałem to samo: Mike jest zafascynowany tą dziedziną. Tak jak projektant systemów operacyjnych szuka idealnych, eleganckich algorytmów, tak Mike spędza czas na odkrywaniu nowych sposobów radzenia sobie z układanką, jaką jest projektowanie baz danych oraz - co
#12
zrozumiesz czytając tę książkę - nowych metod wyjaśniania tych sposobów innym ludziom. Wiele z tego, co sam wiem o bazach danych, dowiedziałem się od Mike'a przez lata mojej z nim współpracy, a jednak sądzę, że wciąż mogę czerpać użyteczną wiedzę z tej właśnie książki. Myślę też, że po zapoznaniu się ze zwięzłą, choć szczegółową prezentacją informacji, które będą Ci potrzebne do tworzenia profesjonalnych baz danych, będziesz miał podobne zdanie.

Ken Getz
MCW Technologies [e-mail]
#13

Przedmowa i podziękowania

Gdyby Pan Wszechmogący spytał mnie o radę przed stworzeniem świata, doradziłbym Mu coś prostszego
Alfonso X, król Kastylii i Leonu

Tworzenie bazy danych jest jak tworzenie wszechświata, tyle że bardziej skomplikowane. W każdym razie, kiedy tworzono wszechświat, nie było nikogo, kto mógłby narzekać
Michael J. Hernandez

Wszystko zaczęło się od prostego pytania: "Jak zaprojektować dobrą bazę danych?". Pytanie to stało się dla mnie początkiem wielkiej przygody: wyprawy w poszukiwaniu osoby lub książki, które mogłyby udzielić na nie odpowiedzi. Wyprawa ta zawiodła mnie do wielu księgarni i do domów wielu fascynujących ludzi. Przeczytałem sporo książek, od całkowicie niezrozumiałych do bardzo ubogich w treść, i miałem okazję rozmawiać z różnymi osobami - zarówno z ludźmi znajdującymi się w mojej sytuacji, jak i z prawdziwymi znawcami tematu. Miałem szczęście, że kilku przedstawicieli tej drugiej kategorii zgodziło się zostać moimi nauczycielami.
Inaczej jednak było z książkami. Przyszła chwila kiedy zrozumiałem, że popularne pozycje traktujące o projektowaniu baz danych po prostu nie zostały napisane dla ludzi takich jak ja. Jeśli masz solidne podstawy matematyczne, dyplom magistra informatyki i pracowałeś w przemyśle komputerowym przez pewien czas, wówczas kwalifikujesz się jako potencjalny odbiorca takich książek. W przeciwnym wypadku nie masz wielkiego wyboru. Kilka prób stworzenia "prostych" podręczników spaliło na panewce głównie dlatego, że ich autorzy zakładali, iż ich odbiorca nie jest osobą inteligentną.
Ja wierzyłem, że powinna istnieć książka dla ludzi nie mających zaawansowanej, specjalistycznej wiedzy; książka, która byłaby prosta i łatwa w odbiorze, szczegółowa, ale nie przytłaczająca; książka wykorzystująca łatwe do zrozumienia przykłady. Napisałem więc zwięzły raport na temat podstaw projektowania baz danych dla mojego lokalnego wydawcy; jego publikacja zakończyła się umiarkowanym sukcesem. Zachęcony
#14
tym powodzeniem zdecydowałem, że kiedyś napisze książkę w pełni opisującą proces tworzenia relacyjnych baz danych.
W trakcie kariery zdobyłem sobie pozycje uznanego projektanta i instruktora obsługi baz danych. Tworzyłem bazy danych dla wielu rozmaitych organizacji i firm i miałem przyjemność uczyć innych wykorzystywania różnych pakietów oprogramowania bazodanowego. Cały czas pamiętałem jednak o powziętym kiedyś postanowieniu.
W 1995 roku, podczas konferencji na temat baz danych w Seattle, poznałem Kathleen Tibbetts, redaktorkę w wydawnictwie Addison Wesley Longman. Był to punkt zwrotny w mojej karierze. Ona szukała ludzi, którzy mieliby coś do powiedzenia, a ja z pewnością byłem taką osobą. Kathleen cierpliwie wysłuchała opowieści o celu, jaki sobie postawiłem, po czym stwierdziła, że nadeszła dobra chwila na rozpoczęcie jego realizacji - przelanie na papier wszystkiego, czego nauczyłem się o projektowaniu baz danych.
Książka, którą trzymasz w ręku, stanowi kulminacje mojej przygody. Swoją wiedzę o bazach danych zawarłem w książce, którą uważam za prosty i przejrzysty podręcznik ich tworzenia. Starałem się, aby była ona zrozumiała dla wszystkich, niezależnie od ich doświadczenia. Szukałem sposobu prezentacji, który byłby łatwiejszy w przyswojeniu i zrozumieniu niż tradycyjne metody, a jednak prowadził do tych samych efektów.
Wierzę, że nauka o projektowaniu baz danych jest procesem ciągłym. Również ja cały czas poznaję zawiłości i niuanse tej dziedziny - tak będzie i w Twoim przypadku. Projektowanie baz jest bardziej sztuką niż nauką ścisłą; wymaga tyle samo intuicji, co wiedzy teoretycznej i praktycznej. Przydatne okazują się też zdolności nawiązywania kontaktów oraz umiejętność dostrzegania problemów w rozmaitych perspektywach. Projektowanie baz danych może okazać się fascynującym tematem, gdy tylko zrozumiesz jego podstawy.
Odkryłem, że pisanie książki jest w pewnym sensie wysiłkiem zbiorowym. Jestem wdzięczny wszystkim tym redaktorom, kolegom, przyjaciołom i członkom rodziny, którzy cały czas służyli mi swoją pomocą. To ci ludzie inspirowali i popychali mnie do skoncentrowania się na wykonywanej pracy. Bez nich mógłbym z łatwością "odłożyć ją do jutra".
Przede wszystkim pragnę podziękować Kathleen Tibbetts z Addison Wesley Longman za jej nieustającą pomoc i za stworzenie okazji do napisania tej książki. Podchodziła ona do mojego projektu z takim entuzjazmem jak i ja sam. Bardzo liczę na jej współpracę w przyszłych projektach.
Następnie składam wielkie podziękowania mojemu przyjacielowi i redaktorowi technicznemu, Jimowi Bootha. Mam wiele szacunku dla jego wiedzy o projektowaniu baz danych, a jego uwagi przy pisaniu niniejszej książki były dla mnie nieocenione. Czekając na ukazanie się tej pozycji w księgarniach, mamy zamiar udać się na gruby stek oraz na butelkę dobrego czerwonego wina.
#15
Winien jestem również wdzięczność mojemu koledze, Christopherowi R. Webe-rowi. Nie zważając na napięty program konsultacji i wykładów, Chris zrecenzował szereg rozdziałów i podzielił się ze mną swoimi cennymi uwagami. Gdybyśmy jeszcze mogli znaleźć chwilę czasu na porozmawianie o muzyce... (obaj jesteśmy muzykami).
Chciałbym ponadto wymienić z nazwiska kilka z wielu osób, które podzieliły się ze mną swoim doświadczeniem i wiedzą oraz miały pozytywny wpływ na moją karierę jako projektanta baz danych. Oto oni: Karen Watterson, Mikę Johnson, Karl Fischer, Paul Litwin, John Yiescas, Ken Getz i Gregory Piercy. Przyjmijcie moje podziękowania.
Mam również szczere i głębokie uznanie dla wspaniałego kolegi i nauczyciela, Alastaira Blacka. Nie dość że sumiennie przeczytał i ocenił każde słowo w niniejszej książce; on i jego żona, Julia otwarli przede mną swój dom i przyjęli mnie jak członka rodziny. Jego wielka i bezinteresowna pomoc w mojej pracy jest nie do przecenienia. Przez te kilka miesięcy nauczyłem się więcej o sztuce pisania niż przez całą resztę mojego życia.
I wreszcie bardzo wielkie podziękowania dla mojej żony, Kendry. Każdy autor, kończąc swoje dzieło, zdaje sobie sprawę, jak wiele zawdzięcza cierpliwości współmałżonka i chce wyrazić wdzięczność za tę bezcenną pomoc i opiekę. Nie będę jednak dalej rozwodził się nad tym tematem - Kendra jest stanowczo przeciwna publicznym wyznaniom uczucia (PWU, jak je nazywa), czy to ustnym, czy pisemnym. Powiem więc tylko tyle: dzięki, Ked. Teraz możemy wrócić do normalnego życia.
#17

Wprowadzenie

Prostego kucharzenia nie można powierzyć prostym kucharzom
Hrabina Morphy

W przeszłości projektowanie baz danych leżało w kompetencjach osób obsługujących systemy informatyczne (SI) oraz profesjonalnych twórców takich baz. Ludzie ci dysponują zazwyczaj wiedzą w zakresie nauk matematycznych, informatyki lub projektowania systemów i trudnią się obsługą dużych baz danych w systemach typu mainframe. Wielu z nich to doświadczeni programiści, którzy napisali już wiele aplikacji bazodanowych, składających się z wielu tysięcy linijek kodu. (Ludzie ci są często przepracowani, ze względu na typ i wagę powierzanych im zadań).
Ponieważ większość systemów tworzonych przez te osoby jest zaprojektowana z myślą o pełnej obsłudze danej organizacji, muszą oni, jako projektanci, posiadać solidną wiedzę merytoryczną. Nawet przy tworzeniu baz danych dla pojedynczych wydziałów danej firmy, lub dla niewielkich przedsiębiorstw, inżynierowie wymagali dawniej gruntownego przeszkolenia, ze względu na złożoność wykorzystywanych wówczas języków programowania i aplikacji bazodanowych. Obecnie jednak sytuacja ulega zmianie.
Od połowy lat 80. producenci oprogramowania zaczęli wypuszczać na rynek aplikacje działające na zwykłych komputerach osobistych oraz umożliwiające łatwiejsze wprowadzanie, przechowywanie i obróbkę danych niż duże komputery typu mainframe. Stworzyli oni również oprogramowanie umożliwiające grupom ludzi dostęp do scentralizowanych danych w architekturze klient/serwer na komputerach połączonych siecią lokalną (LAN). Teraz nikt w firmie nie musi już powierzać swoich danych systemom mainframe, obsługiwanym przez scentralizowane wydziały SI. Z upływem lat producenci zaczęli dodawać do swoich aplikacji nowe możliwości i narzędzia, umożliwiając twórcom baz danych projektowanie coraz wydajniejszych i bardziej uniwersalnych systemów.
Łatwość obsługi współczesnego oprogramowania bazodanowego zainspirowała wielu ludzi do stworzenia własnych baz. Większość pakietów oprogramowania do projektowania baz danych ułatwia użytkownikom zarówno definiowanie pól i tabel, jak również zapytań, formularzy i raportów wykorzystywanych do obróbki danych.
#18
Obecnie do wielu programów dołączane są przykładowe struktury, które można kopiować i modyfikować, dostosowując je do potrzeb odbiorcy. Wiele osób postanowiło wypróbować swoje umiejętności, tworząc bazy danych dla własnych przedsiębiorstw lub wydziałów, z różnym zresztą skutkiem. Udostępniane przez współczesne aplikacje prefabrykaty i ułatwienia projektowe mogą zwieść ich użytkownika, czego wynikiem są często powierzchowne, niepełne projekty. Po pewnym czasie coś, co uważano za solidną bazę danych, zaczyna sprawiać problemy.
Większość z tych problemów można zaklasyfikować do którejś z dwóch kategorii: problemy związane z aplikacją i problemy związane z danymi. Problemy związane z aplikacją to na przykład: niepoprawnie działające formularze do wprowadzania edycji danych, mylące opcje, mylące okna dialogowe i uciążliwe sekwencje czynności. Powstają one najczęściej wówczas, gdy twórca bazy danych jest niedoświadczony, nie zna poprawnej metodologii projektowania aplikacji lub też wie zbyt mało o oprogramowaniu używanym do jej konstrukcji. Takie sytuacje są częste i należy je eliminować, wykracza to jednak poza zakres tej książki. Najlepszym sposobem na radzenie sobie z problemami związanymi z aplikacją jest zakup i przestudiowanie książek opisujących wykorzystywane oprogramowanie. Książki takie opisują metody projektowania aplikacji, zaawansowane techniki programowania oraz zawierają rady i wskazówki pozwalające na ulepszenie danego systemu. Uzbrojony w tę wiedzę, możesz przemyśleć i poprawić strukturę aplikacji bazodanowej tak, aby działała poprawnie, szybko i efektywnie. Druga kategoria problemów, czyli problemy związane z danymi, to sytuacje takie jak: brakujące, niepoprawne, niespójne czy nieprecyzyjne dane. Wiele z nich jest bezpośrednim skutkiem braków w projekcie danej bazy. Jeśli struktura bazy danych nie zostanie starannie przemyślana, wówczas baza ta nie będzie spełniać wymagań organizacji, której ma służyć. Zły projekt to częsta konsekwencja nieznajomości wytycznych tworzenia poprawnej bazy danych, nie musi on jednak świadczyć źle o swoim twórcy. Wielu ludzi - wliczając w to doświadczonych programistów i projektantów baz danych - nie miało nigdy styczności z żadną metodologią projektowania systemów baz danych. Wielu z nich nie wie nawet, że takie metodologie istnieją. Problemy związane z danymi oraz nie przemyślane projekty to tematy, którymi zajmiemy się w niniejszej książce.

Kto powinien przeczytać tę książkę?

Do przeczytania niniejszej książki nie jest potrzebna żadna wiedza z zakresu projektowania baz danych. Powodem, dla którego trzymasz ją w ręku, jest chęć nauczenia się metod tworzenia dobrych systemów bazodanowych. Jeśli wkraczasz dopiero w świat baz danych i myślisz o projektowaniu własnych, podręcznik ten będzie dla Ciebie bardzo pomocny. Lepiej jest bowiem poznać metody projektowania baz
#19
danych przed rozpoczęciem pisania, niż uczyć się ich metodą prób i błędów. Ten drugi sposób naprawdę zabiera znacznie więcej czasu.
Jeśli należysz do kategorii ludzi, którzy pracowali już wcześniej z bazami danych i chcesz rozpocząć projektowanie nowych baz dla własnej firmy lub organizacji, jesteś również potencjalnym odbiorcą tej książki. Prawdopodobnie masz już wyobrażenie o strukturze dobrej bazy danych, nie wiesz jednak, w jaki sposób twórcy takich baz wypracowują dobre projekty. Być może jesteś programistą, który zaimplementował szereg baz danych, trzymając się kilku prostych wytycznych, lecz aby zmusić swoje bazy do poprawnego działania musisz napisać mnóstwo dodatkowego kodu. Także w takim wypadku niniejsza książka jest przeznaczona dla Ciebie.

Nawet jeśli masz już doświadczenie w projektowaniu baz danych, powinieneś zajrzeć do tej książki. Możliwe, że podczas studiów uczestniczyłeś w zajęciach z metodologii projektowania lub też chodziłeś na wykłady z baz danych, na których omawiano ich tworzenie, lecz od tego czasu niektóre szczegóły wyleciały Ci z pamięci lub też są takie etapy projektowania, których nie rozumiesz w pełni. Kiedy zapoznasz się z procesem projektowania baz danych omawianym w mniejszej książce, wszystkie te wątpliwości znikną.
I wreszcie, książka ta będzie również pomocna dla tych, którzy są już doświadczonymi programistami i twórcami baz danych. Mimo iż znasz już większość omawianych tu aspektów projektowania, być może poznasz nowe metody i zagadnienia, o których wcześniej nie wiedziałeś lub których nie rozważałeś w szczegółach. Ponadto wiele znanych Ci procesów jest tu omówionych z innego punktu widzenia, więc ponowna lektura tych informacji może podpowiedzieć Ci nowe pomysły tworzenia własnych baz danych. W ostateczności możesz traktować materiał niniejszej książki jako świetną powtórkę z metod projektowania baz danych.

Cel niniejszej książki

Konstruowanie bazy danych i obsługującej ją aplikacji można opisać w trzech etapach:
� pierwszy etap polega na zaprojektowaniu bazy danych w aspekcie logicznym, czyli na zdefiniowaniu tabel oraz należących do nich pól, ustaleniu kluczy podstawowych i obcych, zdefiniowaniu relacji i wprowadzeniu integralności danych na różnych poziomach,
� etap drugi to implementacja projektu logicznego w konkretnym pakiecie oprogramowania bazodanowego. Wymaga to utworzenia tabel, określenia pól kluczowych i relacji oraz wykorzystania dostępnych narzędzi do zagwarantowania integralności danych,
#20
� trzeci etap polega na stworzeniu aplikacji, z którą będzie komunikował się użytkownik zewnętrzny. Aplikacja ta powinna umożliwić pojedynczym użytkownikom lub ich grupom interakcje z danymi przechowywanymi w bazie. Sam proces jej tworzenia można podzielić na mniejsze etapy, jak: określenie czynności, które ma wykonywać użytkownik, ustalenie sekwencji tych czynności, określenie, których danych wymagają generowane raporty, oraz utworzenie systemu menu, który ułatwi poruszanie się po aplikacji.

Niniejsza książka zajmuje się jedynie pierwszym z tych trzech etapów, czyli logicznym aspektem projektowania bazy danych. Na rynku można znaleźć wiele książek zawierających rozdziały poświęcone implementowaniu bazy w konkretnym pakiecie oprogramowania, językowi SQL (Structured Query Language - język zapytań strukturalnych) oraz innym tematom związanym z programowaniem. Niektóre książki stapiają proces projektowania i implementacji w jedną całość, z czym nie w pełni się zgadzam. Według mnie, głównym problemem wynikającym z korzystania z takich książek jest to, że jeśli czytelnik nie jest obeznany z opisywanym pakietem oprogramowania, wówczas trudno mu uzyskać jakieś przydatne informacje z rozdziałów poświęconych implementacji. Dlatego też w swojej pracy kładę nacisk na czysto logiczną stronę konstrukcji bazy danych.
Projekt logiczny powinien być utworzony i przemyślany przed rozpoczęciem programowania. Po opracowaniu poprawnej struktury będziesz mógł ją zaimplementować w dowolnym pakiecie oprogramowania bazodanowego. Po rozpoczęciu implementacji możesz jednak zauważyć konieczność wprowadzenia modyfikacji do projektu bazy ze względu na możliwości i ograniczenia wykorzystywanego przez Ciebie pakietu. Być może zdecydujesz się nawet na wprowadzenie strukturalnych zmian w utworzonym wcześniej projekcie logicznym w celu zwiększenia szybkości algorytmów przetwarzania danych. Rozpoczęcie pracy od konstrukcji projektu logicznego zmusi Cię do świadomego uwzględnienia pewnych założeń podczas fazy projektowania, przez co rzadsze będą późniejsze modyfikacje.
Celem tej książki jest opisanie procesu projektowania relacyjnych baz danych bez odwoływania się do ortodoksyjnych metodologii, które można znaleźć w większości pozycji opisujących ten proces. Pisząc tę pracę starałem się wyjaśniać zawiłości procesu projektowania, wykorzystując przejrzyste, zdroworozsądkowe podejście do problemu. Starałem się również przedstawić przejrzystą metodę modelowania danych jako uzupełnienie proponowanego przeze mnie podejścia. Cały proces jest opisany tak prosto, jak to możliwe, z minimalną ilością żargonu technicznego.
Książka ta powinna być łatwiejsza w zrozumieniu niż inne, z którymi się zetknąłeś. Większa część literatury poświęconej projektowaniu baz danych jest przeznaczona dla osób z wyższym wykształceniem technicznym i może okazać się zbyt trudna dla zwykłego śmiertelnika. Wydaje mi się, że większość tych pozycji może wyrządzić więcej złego niż dobrego, jeżeli nie jesteś magistrem informatyki,
#21
teoretykiem baz danych czy doświadczonym ich twórcą. Zawarte w niniejszej książce wytyczne projektowania są łatwe do zrozumienia i zapamiętania, a przykłady wystarczająco częste i przejrzyste, aby dało się je odnieść do różnorodnych sytuacji.
Większość ludzi, których spotkałem w podróżach po kraju, powtarzała to samo: chcieliby nauczyć się tworzenia poprawnych struktur baz danych w sposób naturalny, bez konieczności wchłaniania skomplikowanej wiedzy matematycznej. Ludzie ci nie boją się implementowania zadanego projektu w konkretnym pakiecie oprogramowania, podchodzą jednak nieufnie do nauki o optymalizacji struktur danych i ich integralności. Czytając tę książkę dowiesz się nie tylko, jak tworzyć wydajne struktury baz danych, lecz również, jak zapewnić kilka różnych poziomów integralności danych oraz jak łączyć ze sobą tabele, dając użytkownikowi możliwość uzyskania potrzebnych informacji na niemal nieograniczoną ilość sposobów. Wszystko to sprowadza się do zrozumienia pewnych kluczowych pojęć oraz poznania kilku jasno określonych metod działania. Ponadto dowiesz się, jak analizować i modyfikować istniejące bazy danych, ustalać wymagania informacyjne oraz implementować reguły integralności. Tematy te są ważne, ponieważ wielu z Was będzie niejednokrotnie miało do czynienia ze starymi bazami, wymagającymi usprawnienia przy użyciu wiedzy zawartej w tej książce. Nawet jeśli tworzysz nową bazę danych od zera, powinieneś pamiętać o tych kwestiach.
Po zakończeniu lektury niniejszej książki będziesz dysponował wiedzą o technikach potrzebnych do utworzenia sprawnej struktury relacyjnej bazy danych. Jestem pewien, że proponowane przeze mnie podejście będzie odpowiadało przeważającej większości twórców baz danych.

Jak czytać tę książkę?

Zalecam czytanie niniejszej książki od początku do końca, po kolei, niezależnie od tego, czy jesteś nowicjuszem, czy profesjonalistą. W ten sposób unikniesz zamieszania związanego z niezrozumieniem "całości tematu". Przed skoncentrowaniem się na którejś z części omawianego procesu dobrze jest poznać jego całość.
Jeśli czytasz tę książkę po to, by jedynie odświeżyć swoje zdolności projektanckie, możesz teoretycznie skupić się na rozdziałach, które Cię interesują. Tak bardzo, jak to możliwe, starałem się, aby każdy rozdział stanowił niezależną całość. Mimo wszystko radziłbym Ci jednak przejrzenie pozostałej części książki, aby upewnić się, że nie przeoczyłeś żadnych nowych pojęć czy metod projektowania, których wcześniej nie rozważałeś.

Organizacja książki

Na następnej stronie znajduje się krótki opis treści każdej części i każdego rozdziału.
#22
Część I. Projektowanie relacyjnej bazy danych

Ten dział stanowi wprowadzenie do baz danych oraz do ich projektowania. Opisuje niektóre z pojęć potrzebnych do opanowania i zrozumienia procesów omawianych w dalszej części książki.
Rozdział 1, Czym jest relacyjna baza danych?, opisuje rodzaje baz danych, z jakimi się zetkniesz, popularne modele logiczne oraz krótką historie modelu relacyjnego.
Rozdział 2, Cele projektowania, wyjaśnia, dlaczego należy zajmować się projektowaniem logicznym, opisuje cele i korzyści płynące z dobrze przemyślanego projektu oraz omawia pokrótce problem normalizacji i postaci normalnych.
Rozdział 3, Terminologia, opisuje pojęcia, których będziesz potrzebował, aby opanować i zrozumieć metodologię projektowania zawartą w dalszej części książki.

Część II. Proces projektowania

Część ta omawia wszystkie aspekty procesu projektowania bazy danych, jak na przykład określanie kluczy podstawowych, ustalanie atrybutów pól, definiowanie relacji między tabelami, tworzenie perspektyw oraz zapewnianie integralności danych na różnych poziomach.
Rozdział 4, Opis koncepcyjny, stanowi całościowe omówienie procesu projektowania i pokazuje, jak pasują do siebie różne jego elementy.
Rozdział 5, Na początek, opisuje formułowanie definicji celu oraz założeń wstępnych, dających Ci podstawy do rozpoczęcia projektowania bazy danych.
Rozdział 6, Analiza istniejącej bazy danych, omawia problemy związane z istniejącymi bazami danych. Omawiamy tu powody, dla których baza danych powinna być analizowana, po czym koncentrujemy się na badaniu istniejących metod wczytywania danych i udostępniania informacji, na sposobach prowadzenia wywiadów z użytkownikami i kierownictwem oraz na sporządzaniu wstępnej listy pól.
Rozdział 7, Definiowanie tabel, opisuje tabele - podstawę każdej relacyjnej bazy danych. Dowiesz się tu, jak ustalić i zdefiniować informacje, które będą gromadzone w tworzonej bazie, jak kojarzyć pola z tabelami oraz jak dopracowywać struktury tabel.
Rozdział 8, Klucze, wyjaśnia pojęcie kluczy oraz ich znaczenie w procesie projektowania bazy danych; omawia również sposoby wybierania kluczy kandydujących i klucza podstawowego w każdej tabeli.
Rozdział 9, Atrybuty pól, zajmuje się tematem, który jest zazwyczaj bagatelizowany przez większość twórców baz danych. Dowiesz się, że oprócz definiowania sposobu, w jaki dane pole jest tworzone, atrybuty decydują również o naturze danych, które mają być w nim przechowywane. Do omawianych zagadnień należą: rola atrybutów, ich typy oraz definiowanie atrybutów dla każdego pola w bazie danych.
#23
Rozdział 10, Relacje, opisuje role pełnioną przez relacje, ich typy, metody tworzenia oraz definiowanie ich cech.
Rozdział 11, Reguły integralności, omawia typy reguł integralności, ich formułowanie oraz wykorzystanie tabel walidacji. Reguły integralności są ważną częścią każdej bazy danych, ponieważ gwarantują spójność i logiczność danych przechowywanych w tej bazie.
Rozdział 12, Perspektywy, wyjaśnia pojęcie perspektyw, ich znaczenie, typy oraz sposoby tworzenia.
Rozdział 13, Kontrola integralności danych, podsumowuje każdy poziom integralności danych, omówiony we wcześniejszych rozdziałach. Dowiesz się tu, że dobrze jest na koniec ponownie przeanalizować ostateczny projekt pod kątem zapewnienia integralności danych.

Część III. Pozostałe zagadnienia projektowe

Ta część omawia tematy takie, jak unikanie złych projektów oraz naginanie zasad zdefiniowanych w poprzednich rozdziałach.
Rozdział 14, Złe projekty - czego nie robić, opisuje typy projektów, których powinieneś unikać, jak np. projekty plikowe czy wykorzystujące arkusz kalkulacyjny.
Rozdział 15, Naginanie i łamanie zasad, omawia rzadkie sytuacje, w których konieczne może okazać się odejście od technik i założeń procesu projektowania. Rozdział ten podpowie Ci, kiedy warto złamać zasady i jak należy to robić.

WAŻNE: PRZECZYTAJ TEN DZIAŁ!

Słowo o przykładach i technikach opisywanych w tej książce

Jak już prawdopodobnie spostrzegłeś, niniejsza książka zawiera wiele różnorodnych przykładów. Starałem się, aby były one tak typowe i czytelne, jak tylko to możliwe. Zauważysz jednak, że wiele z nich jest uproszczonych, niekompletnych, czy - w rzadkich przypadkach - błędnych. Uwierz jednak, że zrobiłem to nie bez powodu.
Niektóre sporządzone przeze mnie przykłady zawierają błędy umożliwiające zilustrowanie pewnych pojęć i metod. Bez nich nie wiedziałbyś, jak wykorzystywać poznane metody i jakich skutków należy się po nich spodziewać. Wiele przykładów jest uproszczonych, ponieważ starałem się kłaść nacisk na technikę, a nie na sam przykład. Weźmy omawianą w jednym z dalszych rozdziałów bazę danych obsługi zamówień. Istnieje wiele sposobów na utworzenie takiej bazy, lecz omawiana przeze mnie przykładowa struktura jest bardzo uproszczona dlatego, że chcę w tym przypadku
#24
objaśnić konkretną metodę projektowania, a nie stworzyć zaawansowaną bazę danych obsługi zamówień.
Chciałbym więc jeszcze raz podkreślić: skoncentruj się na objaśnianej technice i jej spodziewanych efektach, a nie na ilustrującym ją przykładzie.

Nowe podejście do nauki

Oto podejście do uczenia się procesu projektowania (i właściwie czegokolwiek innego), które z powodzeniem wykorzystywałem wiele razy na prowadzonych przez siebie zajęciach z baz danych.
Traktuj wszystkie techniki wykorzystywane w procesie projektowania jako zestaw narzędzi; każde narzędzie (czy technika) zostało stworzone w konkretnym celu. Kiedy już zrozumiesz, w jaki sposób działa dane narzędzie, będziesz mógł je wykorzystywać w każdej sytuacji. Dzieje się tak dlatego, że wykorzystywane przez Ciebie narzędzie zawsze działa tak samo.
Weźmy dla przykładu klucz francuski. Służy on do odkręcania i przykręcania nakrętek na śruby. Aby dostosować rozmiar klucza do danej nakrętki, zmieniasz rozwartość jego szczęk za pomocą pokrętła. Teraz, kiedy znasz już zasadę działania klucza, możesz go wypróbować na kilku różnych śrubach - na oparciu fotela, na którym siedzisz, na pokrywie silnika samochodu, na zewnętrznej klapie klimatyzatora czy na mocowaniach zawiasów bramy wjazdowej. Zauważysz, że każdą z tych śrub możesz odkręcić przy użyciu klucza francuskiego.
Narzędzia wykorzystywane do konstrukcji baz danych działają dokładnie w ten sam sposób. Kiedy zrozumiesz działanie jakiegoś narzędzia, otworzą się przed Tobą niezliczone możliwości jego wykorzystania. Przykładowo rozważmy technikę określania relacji jeden-do-wielu. Załóżmy, że dysponujesz parą tabel o nazwach TABELA A oraz TABELA B. Mówimy, że między TABELĄ A i TABELĄ B istnieje relacja jeden-do-wielu, jeśli pojedynczemu rekordowi z TABELI_A można przypisać jeden lub więcej rekordów z TABELI_B (rysunek 0.1), lecz pojedynczy rekord z TABELI_B odnosi się tylko do jednego rekordu z TABELI_A (rysunek 0.2). Wykorzystując tę definicję możesz oceniać, czy między danymi dwoma tabelami istnieje relacja jeden-do-wielu.

TABELA A
TABELA B

Rysunek 0.1. Relacja jeden-do-wielu z punktu widzenia TABELI A
#25
TABELA A
TABELA B

Rysunek 0.2. Relacja jeden-do-wielu z punktu widzenia TABELI B

Uwaga: Relacje jeden-do-wielu często określa się skrótem 1:N.

Przypomnienie: Relacje są omawiane w szczegółach w rozdziale 10 -Relacje.

Teraz, kiedy poznałeś już dane narzędzie (czy technikę), zauważysz, że odnosi się ona do każdej pary tabel. Rysunek 0.3 pokazuje pary tabel z kilku różnych baz danych. Jak widzisz, ocenianie, czy między tymi tabelami istnieje relacja jeden-do-wielu, odbywa się w ten sam sposób, niezależnie od rodzaju analizowanej bazy.

Typ bazy danych; Tabele; Czy istnieje relacja?; Powód

Zamówienia; Klienci Zamówienia; Tak; Pojedynczy klient może złożyć dowolną liczbę zamówień, ale każde zamówienie jest składane przez jednego klienta.
Spedycja; Pojazdy Kierowcy; Tak; Pojedynczy pojazd może mieć do trzech kierowców, ale każdy kierowca jest przypisany do pojedynczego pojazdu.
Rozkład zajęć; Przedmioty Studenci; Nie (jest to relacja wiele-do-wielu); Na zajęcia z danego przedmiotu może uczęszczać do 100 studentów, ale każdy student uczestniczy w zajęciach z ośmiu różnych przedmiotów.
Nadzór nad projektami; Kierownicy Projekty; Tak; Pojedynczy kierownik może nadzorować wiele projektów, ale każdy projekt ma jednego kierownika.

Rysunek 0.3. Określanie relacji jeden-do-wielu
#26
Wszystkie techniki (narzędzia) biorące udział w procesie projektowania mogą być wykorzystywane w analogiczny sposób. Używając ich, zawsze będziesz w stanie stworzyć poprawną strukturę bazy danych, niezależnie od typu danych, jakie baza ta ma przechowywać. Pamiętaj: skoncentruj się na wykorzystywanej technice i jej spodziewanych efektach, nie na ilustrującym ją przykładzie.