#41
2. Cele projektowania

Każdy fakt odzwierciedla w pewnym sensie teorię. Błękitny kolor nieba stanowi dowód słuszności praw optyki. Nie ma sensu doszukiwanie się ukrytych przyczyn zjawisk; przyczyny te wynikają z teorii
J. W. Goethe
=================================

Dlaczego należy przykładać wagę do projektowania?

Wiele osób pracujących z programami SZRBD wątpi w celowość uczenia się metod projektowania. W końcu nowoczesne pakiety SZRBD zawierają przykładowe bazy danych, które można kopiować i dostosowywać do indywidualnych potrzeb, a zawarte w nich tabele przenosić do nowych baz. Niektóre aplikacje zawierają nawet "kreatory", prowadzące użytkownika za rękę przez cały proces definiowania i tworzenia tabel. Te narzędzia nie pomagają jednak w projektowaniu bazy danych, a jedynie ułatwiają wprowadzenie w życie gotowego projektu.
Spora liczba użytkowników wydaje się nie rozumieć, że opisane wyżej narzędzia należy wykorzystywać dopiero po określeniu logicznych podstaw bazy danych. Zarówno "kreatory", jak i przykładowe bazy danych mają za zadanie jedynie skrócić czas fizycznej implementacji projektu. Chodzi o to, aby po szybkim i bezbolesnym wprowadzeniu logicznych podstaw bazy danych do programu SZRBD użytkownik miał więcej czasu na stworzenie i dopracowanie aplikacji służących do komunikowania się z tą bazą.
Powodem, dla którego warto poświęcić czas na stworzenie projektu logicznego bazy danych przed przystąpieniem do implementacji, jest to, iż projekt ten ma kluczowe znaczenie dla spójności, integralności i dokładności danych przechowywanych w bazie. Jeśli baza zostanie zaprojektowana w sposób nie przemyślany, wówczas jej użytkownicy będą mieli kłopoty z odczytywaniem zeń informacji; zachodzi również niebezpieczeństwo, że informacje te będą niezupełne lub nawet błędne. Niedokładność
#42
informacji jest najpoważniejszą konsekwencją złego projektu bazy danych i może ona w drastyczny sposób wpłynąć na funkcjonowanie organizacji wykorzystujących tę bazę. Jeśli informacje zawarte w bazie danych decydują o codziennym funkcjonowaniu jakiejś instytucji bądź też wpływają na jej planowanie, projekt tej bazy musi być dokładny.

Spójrzmy na problem z innej perspektywy. Załóżmy, że nasza baza danych to dom, który ma zostać dla nas zbudowany na zamówienie. Od czego zaczniemy? Rzecz jasna, nie od zadzwonienia po wykonawcę. Nie pozwolimy nikomu budować naszego domu według jego własnych upodobań. Zatrudnimy więc najpierw architekta, który wykona dla nas odpowiedni projekt, a dopiero potem wynajmiemy firmę budowlaną, która wcieli go w życie. Architekt ujmie nasze potrzeby w szereg rysunków, spisów, informacji o kształtach i rozmiarach poszczególnych części oraz wymagań dotyczących różnych instalacji. Następnie wykonawca dostarczy materiały i siłę roboczą, która zbuduje dom zgodnie z dostarczonym projektem.
Wróćmy teraz do naszej bazy danych i potraktujmy jej projekt logiczny jako rysunki projektanta, a fizyczną implementację jako gotowy dom. Projekt bazy zawiera informacje o wszystkich elementach, z jakich ma się ona składać, uwzględnia informacyjne i operacyjne wymagania instytucji, której baza ta ma służyć. Dopiero po sporządzeniu projektu logicznego możemy go urealnić za pomocą programu SZRBD. Wreszcie, zdefiniowawszy wszystkie wymagane tabele, relacje i zapewniwszy integralność danych, możemy uznać bazę za gotową. Teraz, konstruując aplikacje, które umożliwią nam interakcję z przechowywanymi w niej danymi, możemy być pewni, że udostępnią one użytkownikom precyzyjne i poprawne informacje.
Można oczywiście wykorzystać SZRBD do implementacji kiepskiego projektu, ale dobrze przemyślana baza oznacza bardziej efektywne i oszczędne przechowywanie danych, łatwiejszą obsługę i zarządzanie oraz większą dokładność odczytywanych z niej informacji.

Rola teorii

W poniższych rozważaniach słowo "teoria" jest wykorzystywane w jego pierwotnym znaczeniu - jako "zbiór propozycji uważanych za ogólne zasady", nie zaś jako kolokwialne określenie "sugestii" czy "zalecenia".
Wiele dziedzin nauki (razem ze skojarzonymi z nimi metodologiami projektowania) ma korzenie w jakiejś teorii. Inżynierowie-architekci mogą obmyślać praktycznie nieograniczoną ilość rodzajów budynków, wykorzystując podstawowe prawa fizyki. Kompozytorzy tworzą piękne symfonie, stosując się do zasad teorii muzyki. Przemysł samochodowy wykorzystuje zasady aerodynamiki do budowania coraz szybszych i ekonomiczniejszych samochodów. Konstruktorzy samolotów wykorzystują te same prawa do projektowania skrzydeł o zmniejszonym oporze.
#43
Powyższe przykłady pokazują, jak ważna jest teoria. Główną korzyścią płynącą ze stosowania teorii jest uczynienie zjawisk przewidywalnymi; możemy wówczas stwierdzić co nastąpi, jeśli wykonamy pewną czynność lub cały ich ciąg. Wiemy, że jeśli upuścimy kamień, spadnie on na ziemie. Jeśli mamy refleks, możemy usunąć naszą stopę z równania opisującego prawo powszechnego ciążenia. Tak samo jest za każdym razem. Jeśli gładko oszlifujemy kamień i położymy go na innym płaskim kamieniu, możemy przewidzieć, że pozostanie on w tym samym miejscu, nawet jeśli go puścimy. Ta sama teoria pozwala nam na budowanie piramid, katedr czy przystanków autobusowych. Rozważmy teraz bazę danych. Wiemy, że jeśli między dwoma tabelami istnieje relacja, możemy odczytywać dane z obu tych tabel jednocześnie; wynika to z budowy relacyjnego modelu logicznego. Dane odczytywane z obu tabel będą powiązane przez wartość pewnego pola, definiującego relację między nimi. Także tutaj wykonywane przez nas czynności będą miały przewidywalne skutki.
Relacyjny model logiczny jest oparty na gałęziach matematyki, znanych jako teoria mnogości oraz rachunek predykatów pierwszego rzędu. Fakt zbudowania modelu relacyjnego na podstawach matematycznych czyni go wyjątkowo elastycznym strukturalnie, a nam umożliwia dostęp do poprawnych i dokładnych informacji. Jednocześnie wspomniane dziedziny wiedzy dają nam narzędzia niezbędne do budowy poprawnych struktur baz danych oraz pozwalają na sformułowanie dobrych metodologii projektowania.
Istnieje zrozumiała niechęć do zagłębiania się w skomplikowane teorie matematyczne, jeśli czynność, którą chcemy wykonać, jest w miarę prosta. Dlatego też czasem słyszy się poglądy głoszące, iż podstawy, na których oparty jest RMBD oraz skojarzone z nim metodologie projektowania, nie mają żadnych powiązań ze "światem rzeczywistym" albo że są w jakiejś mierze "niepraktyczne". To nieprawda - matematyka jest kluczem do zrozumienia relacyjnego modelu logicznego. Nie martw się jednak - w praktyce znajomość teorii mnogości czy rachunku predykatów pierwszego rzędu wcale nie jest potrzebna w użytkowaniu relacyjnych baz danych! To jak uczenie się praw aerodynamiki tylko po to, aby móc jeździć samochodem. Aerodynamika może okazać się pomocna w zrozumieniu, jak konstruktorzy samochodów osiągają niższe spalanie w tworzonych przez siebie pojazdach, lecz zwykły kierowca nie musi się nią w ogóle przejmować.

Teorie matematyczne stanowią podstawę relacyjnego modelu logicznego i tym samym czynią go bardziej przewidywalnym, bezpiecznym i efektywnym. Teorie te definiują podstawowe elementy składowe relacyjnej bazy danych oraz umożliwiają formułowanie wytycznych mówiących, w jaki sposób elementy te należy ze sobą łączyć. Łączenie ze sobą części składowych w celu osiągnięcia pożądanego rezultatu określa się mianem "projektowania".
#44
Korzyści płynące z opanowania poprawnej metodologii tworzenia projektów

Projektowania bazy danych można nauczyć się metodą prób i błędów, zabrałoby to jednak mnóstwo czasu i po drodze trzeba by było wielokrotnie naprawiać skutki swoich pomyłek. Istnieją przynajmniej trzy główne korzyści płynące z nauki poprawnej metodologii projektowania. Przede wszystkim, da Ci ona wiedzę potrzebną do tworzenia efektywnych struktur baz danych. Po drugie, dobra metodologia projektowania to między innymi zbiór procedur, które przeprowadzą Cię za rękę przez cały proces tworzenia bazy. I wreszcie, opanowanie właściwej metodologii projektowania ograniczy ilość popełnianych po drodze błędów do minimum. Rzecz jasna, błędy zawsze będą się zdarzać, lecz umiejętność poprawnego projektowania baz danych umożliwi Ci ich wykrycie w momencie, kiedy ich naprawienie nie będzie jeszcze zbyt trudne.

Rola zrozumienia metod projektowania baz danych

Oprócz czynienia projektu łatwiejszym do skonstruowania, dobra metodologia wpływa również korzystnie na produkt końcowy - na samą bazę danych. Po pierwsze, poprawnie zaprojektowana baza umożliwi Ci odczytywanie informacji na praktycznie nieograniczoną liczbę sposobów. Po drugie, wraz z pełniejszym zrozumieniem metod projektowania, będziesz mógł bardziej efektywnie wykorzystywać swój SZRBD. Im więcej dowiesz się o sposobach tworzenia i użytkowania bazy danych, tym lepiej zrozumiesz, dlaczego dane narzędzie jest udostępniane przez SZRBD i jak należy je wykorzystać do zaimplementowania opracowanej przez siebie struktury. Wreszcie po trzecie, sporą liczbę problemów związanych z przetwarzaniem danych można przypisać ich redundancji, niepoprawności czy brakowi. Wszystkie te sytuacje są potencjalnymi źródłami błędów i utrudniają konstruowanie niektórych zapytań czy raportów. Na szczęście jednak większości z nich, jeżeli nie wszystkich, można łatwo uniknąć przez poprawne zaprojektowanie bazy.

Cele dobrego projektu

Istnieje kilka niezależnych od siebie celów, do których należy dążyć, tworząc poprawną, efektywną strukturę bazy danych. Jeśli będziesz o nich pamiętał i kierował się nimi podczas tworzenia swojej bazy, unikniesz wielu z omówionych wcześniej problemów. Aby zaprojektować dobrą bazę danych, należy upewnić się, że baza ta:
� obsługuje uprzednio zadeklarowane, jak również ad hoc tworzone metody czerpania danych. Podstawowe wymagania informacyjne oraz ewentualne nagłe, nie zapowiedziane żądania dostępu do danych powinny być uwzględnione podczas fazy projektowania i baza musi przechowywać dane, które umożliwią realizację tych żądań.
Cele projektowania
#45
� zawiera efektywnie skonstruowane struktury tabel. Każda z tabel w bazie danych poświecona jest jednemu, konkretnemu tematowi, składa się z w miarę niezależnych pól, zawiera tak mało, jak to możliwe, redundantnych danych i jest identyfikowana przez pole zawierające unikatową wartość.
� zapewnia integralność danych na poziomie pól, tabel i relacji. Jeśli zagwarantujesz integralność danych na wszystkich tych poziomach, wówczas informacje odczytywane z bazy będą zawsze poprawne i dokładne.
� odzwierciedla obsługiwaną strukturę. Dane przechowywane w bazie danych muszą spełniać wymagania informacyjne obsługiwanej organizacji.
� umożliwia przyszłą rozbudowę. Struktury bazy danych powinny być łatwe w modyfikacji i rozbudowie wraz ze zwiększającymi się wymaganiami informacyjnymi obsługiwanej organizacji.

Zalety dobrego projektu

Czas zainwestowany w stworzenie dobrej struktury bazy danych nie jest czasem straconym. Osiągnięcie celów wyznaczonych przez poprawne metodologie projektowania na dłuższą metę oznacza zaoszczędzenie czasu, ponieważ nie trzeba będzie stale poprawiać naprędce skleconej struktury. Poprawnie zbudowana baza danych zapewnia wiele korzyści; umożliwia m.in.:
� łatwą obsługę. Zmiany wprowadzane w pewnych kolumnach czy tabelach nie wpłyną znacząco na zachowanie się całej reszty bazy,
� proste modyfikowanie danych. Zmiany wprowadzane do wartości danego pola nie wpłyną znacząco na pozostałe pola w bazie danych. W dopracowanej strukturze zmiany wprowadzane do konkretnej wartości wymagają zmodyfikowania tylko jednego elementu bazy,
� szybkie odczytywanie informacji, jeżeli tabele są dobrze zaprojektowane, a wszystkie relacje między nimi poprawnie zdefiniowane,
� szybką budowę aplikacji użytkowych. Czas pracy programisty implementującego bazę można przeznaczyć np. na definiowanie odpowiednich technik obróbki danych, a nie tracić go na przezwyciężanie problemów, jakie nieuchronnie towarzyszą złemu projektowi.

Metody projektowania baz danych

Ogólnie rzecz biorąc, tradycyjny proces projektowania baz danych składa się z trzech faz: analizy wymagań, modelowania danych i normalizacji.
Faza analizy wymagań zakłada wgłębienie się w sposób funkcjonowania obsługiwanej organizacji, przeprowadzenie rozmów z jej pracownikami i kierownictwem,
#46
w celu dokonania oceny aktualnie wykorzystywanego systemu i poczynienia prognoz na przyszłość, oraz dokonanie całościowej oceny wymagań informacyjnych organizacji. Ten proces jest w miarę przejrzysty i stanowi podstawę metod przedstawionych w tej książce.

Faza modelowania danych polega na tworzeniu zrębów struktury nowej bazy danych. Pomocne stają się tu takie metody modelowania danych, jak tworzenie tzw. diagramów związków encji (ang. entity relationship diagramming; nazywa się je również diagramami ER), analiza zależności semantycznych czy analiza obiektowa. Każda z tych metod stanowi sposób wizualnej reprezentacji różnych aspektów projektowanej struktury, jak tabel czy relacji, oraz ich cech i atrybutów. Wykorzystana w tej książce technika modelowania jest uproszczoną wersją diagramowania ER; rysunek 2.1 pokazuje przykładowy diagram ER.
=========================================
Uwaga: Opisywane przez nas metody modelowania danych zostają włączone w proces tworzenia projektu i nie są omawiane oddzielnie. Każda metoda modelowania będzie wyjaśniona w powiązaniu z towarzyszącą jej techniką projektowania.
==========================================

[pośrednicy]-|----{ 1:N }----o-[klenci]

Pośrednik-Klient

Rysunek 2.1. Przykład prostego diagramu ER

Diagram na rysunku 2.1 przedstawia kilka aspektów bazy danych. Po pierwsze, zawiera informacje o dwóch tabelach, z których jedna nazywa się "Pośrednicy", a druga - "Klienci". Każda tabela jest reprezentowana przez prostokąt. Znajdujący się pomiędzy nimi romb wskazuje, że miedzy tabelą pośredników a tabelą klientów istnieje relacja, a napis "1:N" mówi, że jest to relacja jeden-do-wielu. Diagram pokazuje też, że do każdego klienta musi być przypisany pewien pośrednik (świadczy o tym pionowa linia przy tabeli pośredników), lecz dany agent może nie być skojarzony z żadnym klientem (małe kółko przy tabeli klientów).
Definiowanie pól i przypisywanie ich odpowiednim tabelom również wchodzi w skład modelowania danych, podobnie jak przypisanie tabelom kluczy podstawowych, wprowadzenie kolejnych poziomów integralności danych oraz zdefiniowanie poszczególnych relacji za pomocą odpowiednich kluczy obcych. Kiedy podstawowe struktury tabel są już gotowe, a relacje zostały zdefiniowane zgodnie z przyjętym modelem danych, baza danych jest gotowa do przejścia przez fazę normalizacji.
Normalizacja jest procesem, w którym następuje rozkład dużych tabel na mniejsze, w celu wyeliminowania redundantnych i powtarzających się danych oraz uniknięcia
#47
problemów związanych z wstawianiem, modyfikowaniem i usuwaniem rekordów. Podczas fazy normalizacji sprawdza się zgodność struktur bazy danych z postaciami normalnymi oraz poddaje się je poprawkom, jeśli zgodność ta nie jest zachowana. Postać normalna to zestaw kryteriów, które musi spełniać dana tabela, aby mogła być uznana za poprawną i nie przyczyniała się do powstawania błędów. Istnieje kilka różnych postaci normalnych; każda z nich związana jest z eliminowaniem pewnego typu problemów. Obecnie stosowane postacie normalne to: pierwsza postać normalna, druga postać normalna, trzecia postać normalna, czwarta postać normalna, piąta postać normalna, postać normalna Boyce'a-Codda oraz postać normalna klucza/domeny.
Metody projektowania prezentowane w tej książce
Przedstawiona przeze mnie metoda projektowania zakłada przeprowadzenie analizy wymagań i zastosowanie uproszczonej techniki diagramowania ERD do opisania struktur tworzonej bazy; nie korzysta jednak z tradycyjnego procesu normalizacji, wykorzystującego postacie normalne. Powód jest prosty - postacie normalne mogą być mylące dla osób, które nigdy nie uczyły się formalnej teorii relacyjnych baz danych. Za przykład niech posłuży definicja trzeciej postaci normalnej, która brzmi:
Mówimy, że tabela jest w trzeciej postaci normalnej wtedy i tylko wtedy, gdy każda krotka składa się z klucza podstawowego, identyfikującego dany obiekt, oraz zbioru zawierającego zero lub więcej wzajemnie niezależnych atrybutów opisujących tenże obiekt[Wprowadzenie do systemów bazodanowych, wyd. 6, C. J. Datę, 1995, s. 296; wyszczególnienia dodane.].
Jeśli czytelnik nie rozumie znaczeń słów "krotka", "klucz podstawowy" czy "atrybut", wówczas definicja ta jest stosunkowo mętna.
Proces tworzenia bazy danych nie jest i nie powinien być trudny do przyswojenia. Jeśli zostanie on przedstawiony w prosty i czytelny sposób, razem z wyjaśnieniem wszystkich pojęć i technik, wówczas każdy będzie w stanie poprawnie zaprojektować bazę danych. Przykładowo, większość czytelników powinna zrozumieć następującą definicję:
Tabela powinna zawierać pole, które jednoznacznie identyfikuje każdy z jej rekordów, a każde pole w tabeli powinno w jakiś sposób wiązać się z jej tematem.
Definicja ta jest oparta na wyniku zastosowania zasad trzeciej postaci normalnej dla pewnej tabeli. Omawiany w tej książce proces projektowania wykorzystuje takie samo podejście do przełożenia tradycyjnego procesu normalizacji na zestaw łatwych w zrozumieniu pojęć i reguł, które pomogą ci opanować zasady poprawnego projektowania.
#48
Podsumowanie

Na początku tego rozdziału omówiliśmy role, jaką pełni projektowanie baz danych. Rozumiesz teraz, że proces ten ma kluczowe znaczenie dla zapewnienia integralności i poprawności danych. Stwierdziliśmy, że największym problemem wynikającym z niewłaściwego czy nie przemyślanego projektu jest niedokładność informacji. Zbudowanie poprawnego projektu powinno więc być głównym celem twórcy bazy, ponieważ zły projekt może mieć zgubny wpływ na funkcjonowanie organizacji, której baza ta ma
Następnie powiedzieliśmy kilka słów na temat roli teorii w relacyjnym modelu logicznym. Dowiedziałeś się, że fakt oparcia tego modelu na podstawach matematycznych czyni z niego stabilną i efektywną strukturę.
Omówiliśmy również korzyści płynące z opanowania poprawnej metodologii projektowania. Wykorzystanie tych reguł daje w efekcie wydajną i bezpieczną strukturę bazy danych. Naszym celem, zamiast "uwzględnienia", stało się "zrozumienie" - dowiedziałeś się więc, że całościowe ogarnięcie projektu daje Ci możliwość uniknięcia wielu problemów typowych dla niedoświadczonych twórców baz danych.
Później opisaliśmy cele dobrego projektu. Osiągnięcie tych celów jest szczególnie ważne dla odniesienia ostatecznego sukcesu, ponieważ gwarantują one poprawność strukturalną tworzonej bazy. Wymieniliśmy również zalety dobrego projektu i dowiedziałeś się, że czas włożony w stworzenie takiego projektu zaprocentuje w przyszłości.
Na zakończenie zaprezentowaliśmy krótki opis tradycyjnych metod projektowania baz danych oraz przybliżyliśmy metody prezentowane w tej książce. Powinieneś teraz rozumieć, że podejście tradycyjne jest złożone i opanowanie go wymaga sporo czasu. Jednak, pomimo że opisywany przeze mnie proces projektowania jest oparty na takim właśnie podejściu, jest on jednocześnie przedstawiony w sposób prosty i przejrzysty.