#67
CZĘŚĆ II
Proces projektowania

#69
4. Opis koncepcyjny

Nie udaję, że rozumiem wszechświat -jest on o wiele większy ode mnie
Thomas Carlyle
======================================

Zrozumienie sposobu funkcjonowania relacyjnej bazy danych nie tylko nie jest tak trudne, jak zrozumienie wszechświata; ale jest nawet o wiele łatwiejsze. Należy jednak przykładać wagę do całościowego ogarnięcia procesu projektowania oraz etapów, z których się on składa. Celem tego rozdziału jest prezentacja podstaw tego procesu.
Na potrzeby niniejszego opisu podzieliliśmy wszystkie techniki związane z projektowaniem baz danych na siedem faz, z których każda będzie omawiana osobno. Prezentacja ta powinna dać dobre wyobrażenie o całości procesu projektowania i sądzę, że przyczyni się również do lepszego zrozumienia każdej z technik opisywanych w rozdziałach 5-13.
Uwaga: Baza danych może być projektowana przez pojedynczą osobę lub przez całą grupę. Od tego momentu terminem "twórca bazy danych" będziemy określać każdą osobę zaangażowaną w projektowanie bazy.

Dlaczego należy przejść przez całość procesu projektowania

Przede wszystkim chciałbym mocno podkreślić wagę przechodzenia przez wszystkie etapy procesu projektowania. Wielu ludzi pyta mnie, czy rzeczywiście trzeba angażować się po kolei we wszystkie jego fazy. Moją odpowiedzią jest zawsze zdecydowane "tak!". Wówczas zadają mi pytanie, czy jest to konieczne nawet dla osoby projektującej "prostą" bazę danych. ("Prosty" jest jednym z najniebezpieczniejszych słów w słowniku twórcy bazy danych. Mc nigdy nie jest "proste"). Ponownie
#70
odpowiadam: "Tak! Jest to konieczne!". Typ, wielkość czy funkcja bazy danych jest bez znaczenia dla procesu projektowania, który zawsze powinien być przeprowadzony od początku do końca.
Jak już pokazaliśmy - a pokażemy to jeszcze nieraz - bez ścisłego trzymania się reguł dobrego projektowania tworzenie bazy danych jest bardzo złym pomysłem. Wiele problemów związanych z istniejącymi bazami danych jest bezpośrednią konsekwencją złego projektu logicznego. Częściowe zastosowanie właściwych zasad jest warte tyle samo, co niestosowanie ich w ogóle. Niekompletny projekt to zły projekt. Tylko spełnienie wszystkich wymagań związanych z tworzeniem poprawnego projektu bazy gwarantuje jej sprawną strukturę i dokładność przechowywanych w niej danych.
Należy zdać sobie sprawę z tego, iż stopień strukturalnej integralności bazy danych oraz integralności samych danych w niej przechowywanych jest prostą pochodną stopnia zaangażowania w tworzenie projektu. Im mniej czasu spędzisz na projektowaniu struktury bazy, tym większe ryzyko wystąpienia problemów w trakcie jej eksploatacji. Ścisłe trzymanie się reguł projektowania nie wyeliminuje wszystkich trudności, z jakimi możesz się zetknąć; z pewnością jednak znacznie ograniczy ich ilość. Co więcej, zaimplementowanie dobrze obmyślonej bazy danych w programie SZRBD jest prostsze niż implementacja złego projektu.
Bazy danych nie są trudne w tworzeniu; trzeba im po prostu poświęcić nieco czasu. Nawet jeśli wydaje Ci się, że dany etap trwa zbyt długo, nie idź na skróty - bądź cierpliwy i pamiętaj, co powiedział kiedyś pewien mądry człowiek: "Nigdy nie ma czasu na zrobienie czegoś porządnie, ale zawsze jest czas na zrobienie tego od nowa".

Formułowanie definicji celu i założeń wstępnych

Pierwszą fazą tworzenia projektu bazy danych jest sformułowanie definicji celu oraz założeń wstępnych. Definicja celu mówi, po co projektujemy bazę danych, oraz stanowi punkt odniesienia dla jej twórcy.
Każda baza danych jest konstruowana w jakimś celu - czy to do rozwiązania konkretnego problemu, czy do codziennej obsługi jakiejś organizacji lub firmy, czy też jako część systemu informacyjnego. Określając cel, jakiemu ma służyć Twoja baza, ułatwisz sobie stworzenie właściwego projektu i umożliwisz przechowywanie w gotowej bazie właściwych danych.
Oprócz definicji celu na tym etapie należy również sformułować założenia wstępne. Są to wymagania, jakie powinny spełniać dane przechowywane w bazie. Warunki te powinny uzupełniać definicję celu i pomagać w tworzeniu poszczególnych elementów bazy danych.
#71
Istnieją dwie oddzielne grupy ludzi, którzy mają wpływ na definicje celu i założeń wstępnych. Pierwsza z nich, składająca się z twórcy bazy danych, właściciela lub dyrektora organizacji, której baza ta ma służyć, oraz członków kierownictwa tejże organizacji, jest odpowiedzialna za definicje celu. Druga, złożona z twórcy bazy, kierownictwa organizacji oraz przyszłych użytkowników bazy, powinna zająć się sformułowaniem założeń wstępnych.

Analiza istniejącej bazy danych
Drugą fazą procesu projektowania jest analiza istniejącej bazy danych, jeśli takowa istnieje. W zależności od organizacji, będzie to zazwyczaj baza spadkowa lub baza tradycyjna. Stara baza danych, użytkowana od wielu lat, to baza spadkowa (czasem nazywana bazą odziedziczoną). Z kolei baza tradycyjna to luźny zbiór formularzy, teczek, notatek i tym podobnych. Niezależnie od typu i stanu istniejącej bazy danych, dokładne przyjrzenie się jej strukturze udzieli cennych informacji na temat sposobu wykorzystywania danych przez organizację. Co więcej, analiza ta pozwoli na zrozumienie sposobu, w jaki dane są gromadzone i prezentowane użytkownikom. Jako twórca nowej bazy danych powinieneś przyjrzeć się roli pełnionej przez papier w gromadzeniu danych (formularze) oraz ich prezentacji (raporty). Analogicznie, jeśli organizacja wykorzystuje już jakieś oprogramowanie komputerowe, należy przestudiować jego działanie oraz metody przetwarzania przez nie danych.
Kolejnym elementem analizy jest przeprowadzenie wywiadów z użytkownikami i kierownictwem w celu ustalenia sposobu, w jaki istniejąca baza jest wykorzystywana w codziennym funkcjonowaniu danej organizacji. Jako projektant powinieneś spytać użytkowników o sposoby korzystania z obecnej bazy oraz o ich aktualne wymagania informacyjne. Następnie powinieneś przeprowadzić dyskusję z członkami kierownictwa i określić, do jakich informacji mają obecnie dostęp oraz jakie są ogólne potrzeby informacyjne ich organizacji.
Teraz jesteś już gotowy do utworzenia listy pól i usług, jakie będą musiały być udostępniane przez bazę danych. Lista ta powinna zawierać podstawowe wymagania informacyjne analizowanej organizacji i stanowić punkt wyjścia do stworzenia projektu logicznego bazy. Można oczekiwać, że jej zawartość będzie się stopniowo powiększać w miarę konstruowania tego projektu.
Po sporządzeniu listy usług, należy ją przedstawić użytkownikom i kierownictwu do ewentualnej korekty. Pamiętaj o uważnym rozpatrywaniu wszelkich sugestii dotyczących jej modyfikacji. Jeśli uważasz daną propozycję za rozsądną i dobrze umotywowaną, wówczas wprowadzasz odpowiednie poprawki, uaktualniasz swoją listę i przechodzisz do następnego etapu.
#72
Tworzenie struktur danych

Tworzenie struktur danych jest trzecim etapem procesu projektowania bazy. Należy zdefiniować tabele i pola, wskazać pola kluczowe oraz określić atrybuty każdego z pól.
Tabele są pierwszą strukturą, jaką powinieneś się zająć. Tematy, którym mają one być poświęcone, wynikają z założeń wstępnych, zdefiniowanych w pierwszej fazie procesu projektowania, oraz z wymagań informacyjnych, ustalonych w fazie drugiej. Po ustaleniu odpowiednich tematów, należy dla każdego z nich utworzyć tabele, a następnie przypisać wszystkie pola z listy sporządzonej pod koniec ostatniego etapu do odpowiednich tabel. Po zakończeniu tej czynności trzeba przeanalizować każdą tabele i upewnić się, że reprezentuje ona tylko jeden temat i nie zawiera powtarzających się pól.
Trzeba teraz przyjrzeć się każdemu polu z osobna. Jeśli stwierdzisz, że któreś z nich jest wielowartościowe lub segmentowe, trzeba je rozbić tak, aby wszystkie pola w tabeli zawierały pojedyncze wartości. Pole nie reprezentujące tematu danej tabeli powinno zostać przesunięte do innej, bardziej odpowiedniej tabeli lub zostać usunięte z bazy. Na koniec należy zdefiniować klucze podstawowe, które będą jednoznacznie identyfikować każdy rekord w poszczególnych tabelach.
Ostatnim krokiem tego etapu jest definiowanie atrybutów dla każdego pola w bazie danych. Należy powtórnie przeprowadzić rozmowy z pracownikami i kierownictwem organizacji w celu ustalenia odpowiednich atrybutów dla poszczególnych pól. Powinieneś też przedyskutować z użytkownikami wszystkie te cechy nowej bazy, które nie są im jeszcze znane. Po zakończeniu tej procedury trzeba zdefiniować i udokumentować atrybuty każdego pola. Następnie powinieneś zwrócić się do pracowników i kierownictwa z prośbą o zgłoszenie ewentualnych poprawek. Po ich wprowadzeniu baza będzie gotowa do następnej fazy.

Definiowanie relacji

W czwartej fazie procesu projektowania należy zdefiniować relacje między poszczególnymi tabelami. Znowu więc trzeba przeprowadzić rozmowy z użytkownikami bazy, określić istniejące relacje, ustalić ich cechy oraz zagwarantować integralność na poziomie relacji.
Współpraca użytkowników przy określaniu relacji jest niesłychanie pomocna, ponieważ najprawdopodobniej nie są Ci znane wszystkie aspekty funkcjonowania danej organizacji. Większość jej pracowników ma jednak dobre wyobrażenie o danych, na których operuje, i może z łatwością wskazać ewentualne relacje.
Kiedy relacje zostaną już ustalone, należy określić ich cechy. W zależności od typu danej relacji wchodzące w jej skład tabele trzeba połączyć, korzystając albo
#73
z klucza podstawowego, albo z tabeli łączącej. Następnie powinieneś zdefiniować typ i stopień uczestnictwa tabel w poszczególnych relacjach; w większości przypadków cechy te będą w prosty sposób wynikać z rodzaju danych przechowywanych w każdej z tych tabel, czasami jednak trzeba będzie odwołać się do reguł integralności.

Wprowadzanie reguł integralności

Wprowadzanie reguł integralności jest piątym etapem procesu projektowania bazy danych. Jako twórca bazy powinieneś przeprowadzić rozmowy z jej przyszłymi użytkownikami, ustalić ograniczenia, jakim mają podlegać dane, zdefiniować reguły integralności oraz wprowadzić tabele walidacji.
Sposób, w jaki dana organizacja wykorzystuje swoje dane, dyktuje wiele ograniczeń, które będą musiały zostać uwzględnione podczas tworzenia bazy danych. Rozmowy z pracownikami i kierownictwem pomogą ustalić wymagania, które powinny być spełniane przez dane oraz ich struktury. Pełną listę tych wymagań będziesz mógł traktować jako zestaw reguł integralności.
Dzięki rozmowom z pracownikami uzyskasz informacje na temat konkretnych ograniczeń różnych aspektów bazy danych. Przykładowo, użytkownik bazy danych zamówień jest świadom faktu, że "Data realizacji zamówienia" musi być późniejsza niż "Data złożenia zamówienia" oraz że zawsze należy podać "Telefon odbiorcy" i "Sposób wysyłki". Z drugiej strony, rozmowy prowadzone z kierownictwem dadzą Ci wiedzę o ogólnych wymaganiach stawianych projektowanej bazie. I tak, kierownik agencji pośredniczącej powie Ci, że dany pośrednik nie może reprezentować więcej niż dwudziestu muzyków, a informacje o każdym muzyku należy uaktualniać przynajmniej raz w roku.
Następnie powinieneś zdefiniować i zaimplementować tabele walidacji, o ile tylko okażą się one przydatne we wprowadzaniu reguł integralności. Na przykład, jeśli ustalisz, że niektóre pola mogą przyjmować tylko kilka różnych wartości zdefiniowanych na podstawie wymagań użytkowników, tabele walidacji pomogą w zagwarantowaniu, że rzeczywiste wartości tych pól odpowiadają wartościom dozwolonym.
Ważne staje się tu wprowadzenie poziomu integralności danych, opartego na regułach integralności, ponieważ odnosi się on bezpośrednio do sposobu, w jaki dana organizacja wykorzystuje dane zawarte w bazie. Wraz z ekspansją tej organizacji jej wymagania informacyjne będą ulegać zmianie, a w ślad za nimi - również reguły integralności. Oznacza to, że ustalanie reguł integralności jest procesem ciągłym i utrzymanie integralności danych na tym poziomie wymaga stałej uwagi i przezorności.
#74
Definiowanie perspektyw

Definiowanie perspektyw to szósta faza procesu tworzenia bazy danych. Jeszcze raz będziesz musiał skonsultować się z pracownikami i kierownictwem organizacji i zdefiniować odpowiednie perspektywy w oparciu o przedstawione przez nich wymagania.
Powinieneś spytać o żądane metody prezentowania danych użytkownikom bazy. Niektórzy pracownicy będą wymagali specjalnych sposobów wizualizacji, w zależności od wykonywanych przez siebie zadań. Przykładowo, pewne osoby mogą chcieć odczytywać dane z kilku tabel jednocześnie; innym wystarczy odwoływanie się do pojedynczych tabel.
Kiedy już określisz wymagane sposoby prezentowania danych, należy je zdefiniować formalnie, jako perspektywy. Każda perspektywa składa się z pól należących do jednej lub większej liczby tabel. Po zdefiniowaniu wszystkich perspektyw będziesz musiał odpowiednio dobrać parametry każdej z nich tak, aby zwracały one tylko żądane rekordy.

Kontrola integralności danych

Siódmą i ostatnią fazą procesu projektowania bazy danych jest kontrola struktury bazy pod kątem integralności zawartych w niej danych. Przede wszystkim należy przyjrzeć się każdej tabeli z osobna i upewnić się, że spełnia ona odpowiednie kryteria poprawności; należy też sprawdzić w ten sposób każde z należących do niej pól. Wszelkie nieścisłości i problemy powinny być teraz rozstrzygnięte i usunięte. Po wprowadzeniu odpowiednich poprawek należy sprawdzić integralność na poziomie tabel.
Następnie trzeba przejrzeć atrybuty wszystkich pól w bazie, wprowadzając konieczne poprawki i sprawdzając integralność na poziomie pól. Upewnisz się przez to, że integralność wprowadzona na wcześniejszych etapach projektowania bazy została zachowana.
Po trzecie, powinieneś sprawdzić poprawność każdej z relacji oraz jej typ, jak również rodzaj i stopień uczestnictwa wszystkich tabel w relacjach, w których skład wchodzą. Należy przeanalizować integralność na poziomie relacji, upewniając się, że współdzielone pola zawierają odpowiednie wartości oraz że wprowadzanie, modyfikowanie i usuwanie danych z powiązanych tabel nie sprawia żadnych problemów.
Na koniec trzeba ponownie przejrzeć listę reguł integralności, potwierdzając zgodność ograniczeń nakładanych przez nie na bazę danych z ustalonymi wcześniej wymaganiami. Jeśli podczas późniejszych faz procesu projektowania zauważono by konieczność wprowadzenia dodatkowych ograniczeń, należy je uwzględnić jako dodatkowe reguły integralności i dopisać do istniejącej listy.
#75
Po zakończeniu procesu projektowania bazy danych struktura utworzonej bazy będzie gotowa do zaimplementowania w programie SZRBD. A jednak procesu tego nigdy nie można uznać za całkowicie zamknięty, ponieważ każda baza danych zmienia się wraz z organizacją, którą obsługuje.

Podsumowanie

Rozpoczęliśmy ten rozdział dyskusją na temat roli ścisłego trzymania się reguł dobrego projektowania. Budowanie bazy danych przy braku wiedzy o poprawnych metodach tworzenia projektów prowadzi do złego produktu końcowego. Powiedzieliśmy też, że poziom strukturalnej i informacyjnej integralności bazy danych jest konsekwencją stopnia, w jakim jej twórca trzymał się zasad poprawnego projektowania. Niespójne dane i niedokładne informacje wynikają najczęściej ze złego projektu logicznego.
Następnie przyjrzeliśmy się ogólnemu opisowi całości procesu projektowania. W celu uproszczenia naszego opisu, podzieliliśmy ów proces na następujące fazy:
1. Formułowanie definicji celu oraz założeń wstępnych. Definicja celu mówi nam, po co projektujemy bazę danych, a założenia wstępne określają operacje, jakie użytkownicy będą przeprowadzać na danych przechowywanych w tej bazie.
2. Analiza istniejącej bazy danych. Należy rozpoznać wymagania informacyjne organizacji, analizując istniejące sposoby gromadzenia i przechowywania danych oraz prowadząc rozmowy z użytkownikami i kierownictwem na temat sposobów wykorzystywania tych danych.
3. Tworzenie struktur danych. Przede wszystkim trzeba zdefiniować tabele określając tematy, jakie będą obsługiwane przez projektowaną bazę. Następnie powinieneś przypisać każdej tabeli pola, które opisują jej temat, oraz określić klucz podstawowy. Na koniec powinieneś ustalić atrybuty każdego pola.
4. Definiowanie relacji. Należy określić relacje istniejące między tabelami w bazie, a następnie zdefiniować każdą z nich, wykorzystując klucze podstawowe i klucze obce, lub tworząc odpowiednie tabele łączące. Należy też opisać każdą relację, podając jej cechy.
5. Określanie reguł integralności. Powinieneś przeprowadzić rozmowy z przedstawicielami organizacji w celu określenia ograniczeń, jakie powinny być nałożone na dane przechowywane w projektowanej bazie. Ograniczenia te noszą nazwę reguł integralności i pomagają we wprowadzaniu różnych poziomów integralności danych.
6. Definiowanie i tworzenie perspektyw. Użytkowników bazy należy spytać o wymagane przez nich sposoby prezentacji danych. Po uzyskaniu odpowiednich informacji powinieneś utworzyć odpowiednie perspektywy. Perspektywę definiuje
#76
się, wskazując odpowiednie tabele, wybierając pola, które mają być w niej uwzględnione, oraz określając kryteria ograniczające liczbę zwracanych przez nią rekordów.
7. Kontrola integralności danych. Ta faza składa się z czterech etapów. Przede wszystkim trzeba przeanalizować każdą tabelę upewniając się, że spełnia ona kryteria poprawności. Następnie powinieneś przejrzeć i skontrolować atrybuty wszystkich pól. Później należy upewnić się co do poprawności wszystkich relacji. I wreszcie trzeba ponownie sprawdzić, czy uwzględniono wszystkie reguły integralności.