#309
15. Naginanie i łamanie zasad

Przyroda nigdy nie łamie własnych praw
Leonardo da Vinci
===========================

Zawsze staram się promować właściwe techniki projektowania baz danych. Jak już wiesz, stoi za tym wiele powodów. Przede wszystkim tylko w ten sposób jesteś w stanie zapewnić integralność tworzonej bazy. Wagi tego spostrzeżenia nie można przecenić. Znasz już konsekwencje, jakie niesie ze sobą naruszenie integralności danych, wiesz wiec, że zawsze należy "trzymać się zasad".

Kiedy można nagiąć lub złamać zasady?

Istnieją tylko dwie sytuacje usprawiedliwiające pewne odstępstwo od zasad poprawnego projektowania. Jeśli któraś z tych sytuacji nie jest nieunikniona, powinieneś zawsze stosować metody opisane w poprzednich rozdziałach.

Projektowanie analitycznej bazy danych

Jak pamiętasz z rozdziału 1, Analityczna baza danych przechowuje dane historyczne i zależne od czasu. Tabele w takiej bazie mogą niekiedy zawierać pola wyliczone. Wyrażenia wykorzystywane przez niektóre z tych pól mają za zadanie opisanie pewnego zbioru danych w określonym momencie; inne, to rozmaite funkcje agregujące.
Zgodnie z metodologią poznaną przez Ciebie w trakcie lektury niniejszej książki, taki projekt bazy danych nie jest poprawny, ponieważ przewiduje umieszczenie w tabelach pól wyliczonych. (Zajrzyj do rozdziału 7). Jednak w tym konkretnym przypadku jest to dopuszczalne, ze względu na sposób korzystania z omawianej bazy. W takich sytuacjach zalecam najpierw sporządzenie poprawnego projektu, a dopiero potem - po starannym przemyśleniu - złamanie określonych zasad, zachowując przy tym pełną świadomość ryzyka, na jakie się narażasz.
#310
Poprawianie wydajności bazy

Jest to zdecydowanie najczęstsza przyczyna łamania zasad poprawnego projektowania przez twórców baz danych. Kiedy tylko wygenerowanie złożonych raportów lub skomplikowanych zapytań zabiera zbyt wiele czasu, ludzie ci myślą, że rozwiązanie leży w zmodyfikowaniu odpowiednich tabel tak, aby zawierały wszystkie pola wymagane przez dany raport, czy zapytanie. Pomimo iż zmiany takie faktycznie poprawiają wydajność bazy danych, wprowadzają jednocześnie szereg problemów, jak niepotrzebnie zwielokrotnione pola czy nadmiarowe dane. To, rzecz jasna, narusza kryteria poprawnego projektu.
Niestety, praktyka często nie jest tak idealna, jak teoria. Czasem wiec będziesz musiał dokonać wyboru między poprawą wydajności bazy a trzymaniem się poznanych zasad projektowania.

Czy warto?

Aby podjąć tę decyzję, zadaj sobie następujące pytanie: "Czy zwiększenie szybkości zrekompensuje utratę jakości?" Jak fale powstające w kałuży po wrzuceniu doń kamienia, tak i skutki odejścia od reguł poprawnego projektowania mogą się rozprzestrzenić na całą strukturę bazy danych. Oto kilka efektów ubocznych, z którymi będziesz musiał się uporać:
� Niespójne dane. Powoduje je zwielokrotnienie niektórych pól. Na Ciebie spadnie odpowiedzialność za synchronizowanie odpowiadających sobie pól - jeśli zmodyfikujemy wartość któregoś z nich, wówczas wszystkie inne będą również musiały odzwierciedlać tę zmianę.
� Nadmiarowe dane. Tu również winowajcą są zwielokrotnione pola. Każda zmiana wartości w jednym z takich pól musi również być wprowadzona do wszystkich pozostałych.
� Zaburzona integralność danych. Naginanie lub łamanie zasad często prowadzi do naruszenia jednego ze składników integralności danych. Twoim zadaniem będzie skompensowanie tej luki - jakkolwiek by się ona nie objawiała - w najlepszy znany sobie sposób.

Inne metody poprawy wydajności

Jeżeli zastanawiasz się, czy warto naruszyć zasady poprawnego projektowania celem poprawienia wydajności bazy, traktuj to wyjście wyłącznie jako ostatnią deskę ratunku. Zacznij od usprawniania systemu innymi metodami, na przykład:
� wymianą lub unowocześnieniem wykorzystywanego sprzętu. Pomimo kosztów, jest to najprostszy sposób na zwiększenie wydajności. Szybszy procesor, więcej pamięci czy lepsza drukarka walnie przyczyni się do skrócenia czasu przetwarzania skomplikowanego zapytania czy raportu. Zakup większego dysku pomoże

#311
zapytaniach wymagających dużej liczby operacji dyskowych - duże dyski, mają na ogół krótsze czasy dostępu.
� odpowiednim skonfigurowaniem systemu operacyjnego. Upewnij się, że działanie systemu zostało zoptymalizowane. Jest to szczególnie ważne w przypadku komputerów sieciowych - szybkość przetwarzania można drastycznie zwiększyć, zmieniając konfigurację sieci. Rodzaje zmian, jakie powinno się wprowadzić do ustawień systemu operacyjnego, zależą w dużym stopniu od rodzaju tego systemu. Przeczytaj więc dokładnie jego dokumentację i spróbuj określić, w jaki sposób można poprawić jego wydajność.
� ponownym przeanalizowaniem struktury bazy. Upewnij się ponad wszelką wątpliwość, że jest ona poprawna. Źle zaprojektowane struktury przyczyniają się do spowalniania operacji.
� przeanalizowaniem sposobu implementacji bazy. Przyjrzyj się, w jaki sposób baza została zaimplementowana w programie SZRBD. Sprawdź, czy implementacja ta w pełni wykorzystuje możliwości danego systemu.
� przeanalizowaniu aplikacji obsługującej bazę. Oto kolejna możliwość poprawienia wydajności. Czy aplikacja została dobrze napisana? Czy korzysta z narzędzi udostępnianych przez SZRBD? Czy jej składniki są dobrze zdefiniowane? Przykładowo, niektóre raporty mogą się wolno drukować ze względu na sposób ich zaprojektowania przez programistę - być może istnieją bardziej efektywne sposoby wygenerowania tego samego raportu. Z kolei zapytania mogą działać powoli, jeżeli są źle zdefiniowane. Upewnij się, że każde zapytanie zostało zaprogramowane poprawnie i w możliwie najefektywniejszy sposób.
Jeśli sądzisz, że powinieneś odejść od przyjętych metod projektowania bazy danych, starannie przemyśl sytuację. Jak już wcześniej zauważyliśmy, czasami dopuszcza się odejście od tych metod w przypadku baz analitycznych. Upewnij się, że projekt bazy jest całkowicie poprawny, a zasady zostały rozluźnione tylko w tym jednym miejscu.

Dokumentowanie swoich poczynań

Jeśli po podjęciu wszystkich opisanych wyżej czynności zaradczych nadal uważasz, że złamanie zasad jest jedynym wyjściem, pamiętaj o starannym udokumentowaniu wprowadzanych modyfikacji! Jest to bardzo ważne, ponieważ zmusi Cię do przemyślenia skutków podjętych działań. Ponadto dokumentacja ta umożliwi Ci przywrócenie stanu wyjściowego w przypadku, gdy okaże się, że wprowadzone zmiany nie przynoszą pożądanego rezultatu.
#312
Należy spisać następujące informacje:
� Powód, dla którego łamiesz zasady. Zasady można naruszać z wielu przyczyn: czy to dla poprawienia szybkości systemu, czy dla skrócenia czasu wydruku któregoś z raportów. Wypisz je wszystkie.
� Naruszaną zasadę. Umożliwi Ci to cofnięcie zmian, jeśli ich skutki nie okażą się zadowalające. Możesz na przykład napisać, że zmieniasz strukturę którejś z tabel.
� Modyfikowany element bazy danych. Wskaż pole, tabelę, relację lub perspektywę, do której masz zamiar wprowadzić modyfikacje. Podobnie jak w poprzednim przypadku, informacje te pomogą w cofnięciu zmian.
� Sposób, w jaki wprowadzasz modyfikacje. Określiwszy elementy, które należy poddać zmianom, spisz szczegółowo wszystkie wprowadzane modyfikacje. Jeśli masz zamiar zmodyfikować którąś z relacji, zapisz, w jaki sposób zmienią się jej poszczególne cechy.
� Przewidywany wpływ zmian na bazę danych i obsługującą ją aplikację. Wszystkie modyfikacje wprowadzane do struktury bazy danych będą miały wpływ na obsługującą ją aplikację. Przykładowo, zmiana struktury którejś z tabel może wpłynąć na perspektywy, formularze oraz raporty oparte (w całości lub w części) na tej tabeli, a także na opisujące ją makrodefinicje lub kod programu. Wypisz wszystkie przewidywane skutki.
Dołącz powyższe notatki do dokumentacji bazy danych. Nawet jeśli proponowane zmiany okażą się zbędne, informacje o nich mogą zapobiec powtórzeniu tego samego błędu w przyszłości.

Podsumowanie

Rozpoczęliśmy rozdział opisem dwóch rodzajów okoliczności, w których można zastanowić się nad odejściem od zasad poprawnego projektowania. Jedną z nich jest projektowanie analitycznej bazy danych. Wiesz jednak, że najpierw należy sporządzić całkowicie poprawny projekt, a dopiero potem podjąć świadomą decyzję o złamaniu zasad. Drugą i częstszą okolicznością jest chęć poprawy wydajności projektowanej bazy. Pomimo iż nie jest to wystarczający powód do złamania zasad, w praktyce czasem zdarzają się sytuacje, w których wyjście to musi zostać rozważone.
Następnie przeszliśmy do opisu alternatywnych kroków, jakie możesz podjąć w celu poprawienia wydajności bazy danych, jak na przykład wymiana sprzętu lub analiza implementacji bazy. Dowiedziałeś się, że odejście od zasad poprawnego projektowania należy zawsze traktować jako ostateczność. Rozdział kończymy listą informacji, które powinieneś spisać, jeśli mimo wszystko zdecydujesz się złamać te zasady.