#301
CZĘŚĆ III
Pozostałe zagadnienia projektowe

#303
14. Złe projekty - czego nie robić?

Zawsze zaczyna się od błędów
Cesare Pavese
=========================

Być może zdziwi Cię fakt, iż rozdział ten pojawia się na końcu książki, zamiast na początku. Powód jest prosty: teraz, kiedy wiesz już jak poprawnie zaprojektować bazę danych, możesz zdać sobie sprawę z niebezpieczeństw związanych ze złymi metodami projektowania. Co więcej, sam już jesteś w stanie określić, dlaczego dany projekt jest niepoprawny i jakie niesie ze sobą problemy. Dysponujesz również wiedzą umożliwiającą radzenie sobie z tymi problemami.
W tym rozdziale poznasz trzy najbardziej rozpowszechnione podejścia, które prowadzą do złego konstruowania baz danych. Ich opisy będą zwięzłe, ponieważ naszym celem jest jedynie unaocznienie metod, których powinieneś unikać. Aby naprawić nieefektywną bazę danych, należy przejść przez cały proces projektowania, który właśnie poznałeś.

Projekt plikowy

Ten rodzaj projektu jest często spotykany w przypadku baz danych, które nie zostały stworzone z myślą o implementacji za pomocą programów SZRBD. Z projektem plikowym wiąże się wiele problemów, co widać na rysunku 14.1.
Diagram ten przedstawia strukturę pojedynczej tabeli. (Spróbuj sobie wyobrazić struktury pozostałych!) Jak widzisz, struktura ta cierpi z powodu niespójnych i nadmiarowych danych. Oto pełna lista problemów związanych z tak zaprojektowaną tabelą:
• Pola segmentowe. "ImiÄ™ i nazwisko pracownika" można podzielić na dwie części; podobnie "ImiÄ™ i nazwisko klienta". Z kolei pole "Adres klienta" skÅ‚ada siÄ™ aż z czterech części: adresu miejskiego, miasta, stanu oraz kodu pocztowego.
#304
Struktury tabel

Zamówienia

Numer zamówienia Telefon klienta Produkt 3 (zapłata)
Data złożenia zamówienia Produkt 1 Produkt 2
Data realizacji zamówienia Ilość 1 Ilość 2
Ilość zamówionych produktów Cena 1 Cena 2
Imię i nazwisko pracownika Produkt 1 (zaplata) Produkt 2 (zapłata)
Numer klienta Produkt 3
Imię i nazwisko klienta Ilość 3
Adres klienta Cena 3

Rysunek 14.1. Przykład struktury plikowej

• Pola wyliczone. Pole "Ilość zamówionych produktów" zawiera wartość bÄ™dÄ…cÄ… najprawdopodobniej wynikiem rÄ™cznego obliczenia, zwÅ‚aszcza gdy dany klient zamawia wiÄ™cej niż trzy produkty. Pola "Produkt # (zapÅ‚ata)" opierajÄ… siÄ™ na wyrażeniu wymnażajÄ…cym wartoÅ›ci pól "Ilość #" i "Cena #".
• ZbÄ™dne duplikaty pól. Wszystkie pola odnoszÄ…ce siÄ™ do konkretnych produktów (jak na przykÅ‚ad "Produkt 1", "Produkt 2" i "Produkt 3") sÄ… niepotrzebnie powielone.
• Brak klucza podstawowego. W tabeli tej nie istnieje żadne pole ani grupa pól, które mogÅ‚yby jednoznacznie identyfikować każdy rekord. Pole "Numer zamówienia" nie może stanowić klucza podstawowego; jeÅ›li klient zamówi wiÄ™cej niż trzy produkty, wówczas użytkownik bÄ™dzie musiaÅ‚ wprowadzić do tabeli kolejny rekord z tym samym numerem zamówienia.
• Tabela reprezentuje wiÄ™cej niż jeden temat. ÅšciÅ›lej - trzy odrÄ™bne tematy: klienci, zamówienia i produkty. (Można również uznać, że reprezentuje ona pracowników).
Znając cechy poprawnego projektu bazy danych, zdajesz sobie sprawę, że tak skonstruowanych tabel należy unikać.

Projekt w arkuszu kalkulacyjnym

Arkusz kalkulacyjny jest pożytecznym narzędziem, jeżeli wykorzystuje się go do celów, dla których został stworzony. W przeciwieństwie do ogólnie przyjętego ste-
#305
reotypu, arkusze kalkulacyjne nie stanowią dobrego środowiska dla implementacji relacyjnych baz danych. Jeśli nasza organizacja musi przechowywać i obrabiać duże ilości danych, wówczas potrzebna jej jest baza danych z prawdziwego zdarzenia. Rozważmy przykład z rysunku 14.2.
A B(pod B sÄ… puste miejsca) C
1 Sklep 100 (344-0029) Sklep 103 (554-2993)
2 Kierownik: MikÄ™ Hernandez Kierownik: Diannia Piercy
3 Z-cy kierownika: Bob McNeal oraz Z-ca kierownika: Terri Sharpe
4 Suzi Thompson
5 Sklep 101 (445-3928) Sklep 104 (773-1837)
6 Kierownik: Abe Hernandez Kierownik: Gary Holcomb
7 Z-ca kierownika: Steve McMahn Z-cy kierownika: Barbara Cooper oraz
8 Jan Eckstadt
9 Sklep 102 (433-4872) Sklep 105 (344-2883)
10 Kierownik: Susan McLain Kierownik: Caroline Coie
11 Z-ca kierownika: Carol Schaeffer Z-ca kierownika: Leroy Bonnicksen

Rysunek 14.2. Przykład "bazy danych" w arkuszu kalkulacyjnym

Na rysunku tym widzimy fragment arkusza kalkulacyjnego, wykorzystywanego do przechowywania danych o sklepach należących do pewnej firmy. Od razu można zauważyć następujące problemy:
• Pola zwielokrotnione. Każde pole w tym arkuszu jest zwielokrotnione. PatrzÄ…c na przykÅ‚adowe dane, można wyodrÄ™bnić tylko trzy rodzaje pól: "Numer sklepu", "ImiÄ™ i nazwisko kierownika", oraz "ImiÄ™ i nazwisko z-cy kierownika".
• Pola segmentowe. Każde pole przechowuje dwie wartoÅ›ci. Pierwsze skÅ‚ada siÄ™ z numeru sklepu oraz numeru telefonu; pozostaÅ‚e dwa - z imienia i nazwiska.
• Pola wielowartoÅ›ciowe. Pole "ImiÄ™ i nazwisko z-cy kierownika" jest polem wie-lowartoÅ›ciowym, ponieważ dany kierownik może mieć wiÄ™cej niż jednego zastÄ™pcÄ™.
• Z tej bazy danych trudno jest korzystać. Operacje na danych, rutynowe w przypadku programów SZRBD, sprawiajÄ… wielkie problemy w bazach danych opartych na arkuszach kalkulacyjnych. PrzykÅ‚adowo, trudno byÅ‚oby zestawić listÄ™ zawierajÄ…cÄ… tylko nazwiska kierowników i telefony do poszczególnych sklepów.
Widząc, jakie problemy sprawia stosunkowo prosta "baza danych" zaimplemen-towana w arkuszu kalkulacyjnym, możesz sobie wyobrazić, co działoby się w przypadku bardziej złożonych baz. Jeśli korzystasz z takiej bazy, a chciałbyś zwiększyć jej
#306
efektywność, szybkość i użyteczność, zastosuj dla niej poznany proces projektowania, po czym zaimplementuj ją w programie SZRBD.
Jak zerwać z nawykami związanymi z wyświetlaniem danych w arkuszu kalkulacyjnym
Kiedy zaczynasz pracę z prawdziwą relacyjną bazą danych i prawdziwym programem SZRBD, musisz pożegnać się z pewnymi przyzwyczajeniami wyniesionymi z wcześniejszych doświadczeń z arkuszami kalkulacyjnymi. Innymi słowy, musisz się pogodzić z tym, że pewne sposoby wyświetlania danych nie są już dostępne - nie można stosować typowych dla arkuszy kalkulacyjnych postaci raportów. Rozważmy dla przykładu raport pochodzący z arkusza kalkulacyjnego, przedstawiony na rysunku 14.3.

Sklepy

Bellevue
Sklep 201 |Sklep 211 ||Sklep 118
Kierownik: MikÄ™ Hernandez |Kierownik: George Chavez ||Kierownik: Joyce Williams
Redmond
Sklep 322 |Sklep 27 ||Sklep 75
Kierownik: Jose Aguilar |Kierownik: Mark Rosales ||Kierownik: Chris Weber
Seattle
Sklep 105 |Sklep 187 ||Sklep 200

Kierownik: Frank Lerum |Kierownik: Susan McLain ||Kierownik: Linda Teller

Rysunek 14.3. Przykład raportu wygenerowanego przez arkusz kalkulacyjny

Jeśli korzystasz z aplikacji bazy danych, nie możesz wygenerować raportu o takiej strukturze, ze względu na sposób przechowywania danych w bazie. W arkuszu kalkulacyjnym dane są zapisane dokładnie tak, jak widać na raporcie. W programach SZRBD te same dane znajdowałyby się w czterech różnych polach pewnej tabeli. Rysunek 14.4 przedstawia analogiczny raport pochodzący z aplikacji bazodanowej.
#307
Sklepy

Bellevue |Seattle
Sklep 201 Kierownik: MikÄ™ Hernandez |Sklep 105 Kierownik: Frank Lerum
Sklep 211 Kierownik: George Chavez |Sklep 187 Kierownik: Susan McLain
Sklep 118 Kierownik: Joyce Williams |Sklep 200 Kierownik: Linda Teller
Redmond
Sklep 322 Kierownik: Jose Aguilar
Sklep 27 Kierownik: Mark Rosales
Sklep 7.5 Kierownik: Chris Weber

Rysunek 14.4. Przykład raportu bazodanowego

Raport ten nie jest identyczny z przedstawionym wcześniej dokumentem, jest jednak tak samo czytelny.
Powinieneś wiec zmienić nieco swój sposób patrzenia na bazę danych. Tak czy inaczej, wykorzystanie programu SZRBD jest o wiele efektywniejsze niż tworzenie "bazy danych" za pomocą arkusza kalkulacyjnego. Prawdziwa baza danych daje nieporównanie większą kontrole nad integralnością, spójnością i poprawnością danych, umożliwiając jednocześnie odczytywanie informacji na wiele różnych sposobów.

Projekty oparte na konkretnych systemach zarzÄ…dzania

Programy SZRDB nie dostarczają procedur czy nawet powodów do zaprojektowania bazy danych w jakiś konkretny sposób - zawierają jedynie narzędzia umożliwiające dokonanie implementacji. Tymczasem metodologia projektowania baz danych opisuje zarówno sposoby, jak i uzasadnienie dla tworzenia poprawnego i efektywnego projektu.
Wiele osób wpada w pułapkę tworzenia projektów dla konkretnego systemu zarządzania. Używając narzędzi dostarczanych przez taki system, możesz oczywiście skonstruować "działającą" bazę danych, lecz jej struktura będzie prawdopodobnie nieefektywna, a Ty nie będziesz o tym wiedział. Takie projektowanie prowadzi do nieprawidłowych struktur, słabej integralności danych oraz problemów związanych z niespójnymi lub błędnymi informacjami. Bez dogłębnego zrozumienia zasad dobrego projektowania prędzej czy później doprowadzisz do sytuacji, w której to program SZRBD - a nie twoja organizacja - zacznie dyktować strukturę tworzonej bazy.
#308
Ostatnie przemyślenie

Przez lata nauczania zasad tworzenia projektów i wykorzystania różnorodnych programów SZRBD, zaobserwowałem interesujące zjawisko: osoby, którym znane są podstawy metod projektowania, mają zazwyczaj lepsze zrozumienie programów SZRBD i oferowanych przez nie narzędzi, niż pozostali użytkownicy. Myślę, że bierze się to z faktu, iż ludzie ci wiedzą, do czego służą różne opcje udostępniane przez programy SZRBD i wiedzą też, jak z nich korzystać. Z tego powodu - jak również z wielu innych - warto jest poznawać właściwe metody projektowania. Droga opisywana przez tę książkę nie jest jedynym słusznym szlakiem, myślę jednak, że jest najprostsza, najbezpieczniejsza i najbardziej uczęszczana.

Podsumowanie

Rozdział ten porównuje projekt relacyjnej bazy danych z innymi, mniej efektywnymi formatami. Najpierw przyjrzeliśmy się projektowi plikowemu. Dowiedziałeś się, że związane jest z nim wiele poważnych problemów i że należy go za wszelką cenę unikać. Następnie przeanalizowaliśmy implementację bazy danych w arkuszu kalkulacyjnym, pokazując, że ma to zgubny wpływ na elastyczność i integralność danych. Na zakończenie opisaliśmy kłopoty wynikające z projektowania bazy dla konkretnego SZRBD. Dowiedziałeś się, że efektywność tego typu projektu w niebezpiecznie dużym stopniu zależy od znajomości danego pakietu oprogramowania. Projektowanie bazy z myślą o danym systemie zarządzania nie daje powodów do stworzenia poprawnej i skutecznej struktury. Powierzchownie, program wydaje się działać bez zarzutu, jednak na dłuższą metę ustępuje aplikacjom opartym na "neutralnym" projekcie, którego konstruowania uczy Cię niniejsza książka.