#309 15. Naginanie i łamanie zasad Przyroda nigdy nie łamie własnych praw Leonardo da Vinci =========================== Zawsze staram się promować właciwe 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 integralnoci 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. Jeli 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 okrelonym 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 przemyleniu - złamanie okrelonych zasad, zachowujšc przy tym pełnš wiadomoć ryzyka, na jakie się narażasz. #310 Poprawianie wydajnoci 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 mylš, ż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š jednoczenie 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š wydajnoci bazy a trzymaniem się poznanych zasad projektowania. Czy warto? Aby podjšć tę decyzję, zadaj sobie następujšce pytanie: Czy zwiększenie szybkoci zrekompensuje utratę jakoci?" Jak fale powstajšce w kałuży po wrzuceniu doń kamienia, tak i skutki odejcia 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 - jeli 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 wartoci 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 integralnoci danych. Twoim zadaniem będzie skompensowanie tej luki - jakkolwiek by się ona nie objawiała - w najlepszy znany sobie sposób. Inne metody poprawy wydajnoci Jeżeli zastanawiasz się, czy warto naruszyć zasady poprawnego projektowania celem poprawienia wydajnoci bazy, traktuj to wyjcie wyłšcznie jako ostatniš deskę ratunku. Zacznij od usprawniania systemu innymi metodami, na przykład: wymianš lub unowoczenieniem wykorzystywanego sprzętu. Pomimo kosztów, jest to najprostszy sposób na zwiększenie wydajnoci. 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 okrelić, 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żliwoci danego systemu. przeanalizowaniu aplikacji obsługujšcej bazę. Oto kolejna możliwoć poprawienia wydajnoci. 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. Jeli sšdzisz, że powiniene odejć od przyjętych metod projektowania bazy danych, starannie przemyl sytuację. Jak już wczeniej zauważylimy, czasami dopuszcza się odejcie od tych metod w przypadku baz analitycznych. Upewnij się, że projekt bazy jest całkowicie poprawny, a zasady zostały rozlunione tylko w tym jednym miejscu. Dokumentowanie swoich poczynań Jeli po podjęciu wszystkich opisanych wyżej czynnoci zaradczych nadal uważasz, że złamanie zasad jest jedynym wyjciem, pamiętaj o starannym udokumentowaniu wprowadzanych modyfikacji! Jest to bardzo ważne, ponieważ zmusi Cię do przemylenia skutków podjętych działań. Ponadto dokumentacja ta umożliwi Ci przywrócenie stanu wyjciowego 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 szybkoci systemu, czy dla skrócenia czasu wydruku którego z raportów. Wypisz je wszystkie. Naruszanš zasadę. Umożliwi Ci to cofnięcie zmian, jeli 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. Okreliwszy elementy, które należy poddać zmianom, spisz szczegółowo wszystkie wprowadzane modyfikacje. Jeli 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łoci 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 jeli proponowane zmiany okażš się zbędne, informacje o nich mogš zapobiec powtórzeniu tego samego błędu w przyszłoci. Podsumowanie Rozpoczęlimy rozdział opisem dwóch rodzajów okolicznoci, w których można zastanowić się nad odejciem 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š okolicznociš jest chęć poprawy wydajnoci projektowanej bazy. Pomimo iż nie jest to wystarczajšcy powód do złamania zasad, w praktyce czasem zdarzajš się sytuacje, w których wyjcie to musi zostać rozważone. Następnie przeszlimy do opisu alternatywnych kroków, jakie możesz podjšć w celu poprawienia wydajnoci bazy danych, jak na przykład wymiana sprzętu lub analiza implementacji bazy. Dowiedziałe się, że odejcie od zasad poprawnego projektowania należy zawsze traktować jako ostatecznoć. Rozdział kończymy listš informacji, które powiniene spisać, jeli mimo wszystko zdecydujesz się złamać te zasady.
sliwak