#301 CZﾊ姑 III Pozostaｳe zagadnienia projektowe #303 14. Zｳe projekty - czego nie robi・ Zawsze zaczyna si・od bｳ鹽 Cesare Pavese ========================= By・moｿe zdziwi Ci・fakt, iｿ rozdziaｳ ten pojawia si・na kou ksiｹｿki, zamiast na poczｹtku. Pow jest prosty: teraz, kiedy wiesz juｿ jak poprawnie zaprojektowa・baz・danych, moｿesz zda・sobie spraw・z niebezpieczetw zwiｹzanych ze zｳymi metodami projektowania. Co wi鹹ej, sam juｿ jeste・w stanie okre徑i・ dlaczego dany projekt jest niepoprawny i jakie niesie ze sobｹ problemy. Dysponujesz rnieｿ wiedzｹ umoｿliwiajｹcｹ radzenie sobie z tymi problemami. W tym rozdziale poznasz trzy najbardziej rozpowszechnione podej彡ia, kte prowadzｹ do zｳego konstruowania baz danych. Ich opisy b鹽ｹ zwi黝ｳe, poniewaｿ naszym celem jest jedynie unaocznienie metod, ktych powiniene・unika・ Aby naprawi・nieefektywnｹ baz・danych, naleｿy przej懈 przez caｳy proces projektowania, kty wｳa從ie poznaｳe・ Projekt plikowy Ten rodzaj projektu jest cz黌to spotykany w przypadku baz danych, kte nie zostaｳy stworzone z my徑ｹ o implementacji za pomocｹ program SZRBD. Z projektem plikowym wiｹｿe si・wiele problem, co wida・na rysunku 14.1. Diagram ten przedstawia struktur・pojedynczej tabeli. (Spruj sobie wyobrazi・struktury pozostaｳych!) Jak widzisz, struktura ta cierpi z powodu niespnych i nadmiarowych danych. Oto peｳna lista problem zwiｹzanych z tak zaprojektowanｹ tabelｹ: ・Pola segmentowe. Иmi・i nazwisko pracownika" moｿna podzieli・na dwie cz龕ci; podobnie Иmi・i nazwisko klienta". Z kolei pole Бdres klienta" skｳada si・aｿ z czterech cz龕ci: adresu miejskiego, miasta, stanu oraz kodu pocztowego. #304 Struktury tabel Zamienia Numer zamienia Telefon klienta Produkt 3 (zapｳata) Data zｳoｿenia zamienia Produkt 1 Produkt 2 Data realizacji zamienia Ilo懈 1 Ilo懈 2 Ilo懈 zamionych produkt 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 Иlo懈 zamionych produkt" zawiera warto懈 b鹽ｹcｹ najprawdopodobniej wynikiem r鹹znego obliczenia, zwｳaszcza gdy dany klient zamawia wi鹹ej niｿ trzy produkty. Pola Пrodukt # (zapｳata)" opierajｹ si・na wyraｿeniu wymnaｿajｹcym warto彡i p Иlo懈 #" i Гena #". ・ Zb鹽ne duplikaty p. Wszystkie pola odnoszｹce si・do konkretnych produkt (jak na przykｳad Пrodukt 1", Пrodukt 2" i Пrodukt 3") sｹ niepotrzebnie powielone. ・ Brak klucza podstawowego. W tabeli tej nie istnieje ｿadne pole ani grupa p, kte mogｳyby jednoznacznie identyfikowa・kaｿdy rekord. Pole Нumer zamienia" nie moｿe stanowi・klucza podstawowego; je徑i klient zami wi鹹ej niｿ trzy produkty, wczas uｿytkownik b鹽zie musiaｳ wprowadzi・do tabeli kolejny rekord z tym samym numerem zamienia. ・ Tabela reprezentuje wi鹹ej niｿ jeden temat. 慶i徑ej - trzy odr鹵ne tematy: klienci, zamienia i produkty. (Moｿna rnieｿ uzna・ ｿe reprezentuje ona pracownik). 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鹽ziem, jeｿeli wykorzystuje si・go do cel, dla ktych zostaｳ stworzony. W przeciwietwie do ognie przyj黎ego ste- #305 reotypu, arkusze kalkulacyjne nie stanowiｹ dobrego 徨odowiska dla implementacji relacyjnych baz danych. Je徑i nasza organizacja musi przechowywa・i obrabia・duｿe ilo彡i danych, 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 ・azy 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麪ujｹce problemy: ・ Pola zwielokrotnione. Kaｿde pole w tym arkuszu jest zwielokrotnione. Patrzｹc na przykｳadowe dane, moｿna wyodr鹵ni・tylko trzy rodzaje p: Нumer sklepu", Иmi・i nazwisko kierownika", oraz Иmi・i nazwisko z-cy kierownika". ・ Pola segmentowe. Kaｿde pole przechowuje dwie warto彡i. Pierwsze skｳada si・z numeru sklepu oraz numeru telefonu; pozostaｳe dwa - z imienia i nazwiska. ・ Pola wielowarto彡iowe. Pole Иmi・i nazwisko z-cy kierownika" jest polem wie-lowarto彡iowym, poniewaｿ dany kierownik moｿe mie・wi鹹ej niｿ jednego zast麪c・ ・ Z tej bazy danych trudno jest korzysta・ Operacje na danych, rutynowe w przypadku program SZRBD, sprawiajｹ wielkie problemy w bazach danych opartych na arkuszach kalkulacyjnych. Przykｳadowo, trudno byｳoby zestawi・list・zawierajｹcｹ tylko nazwiska kierownik i telefony do poszczegnych sklep. Widzｹc, jakie problemy sprawia stosunkowo prosta ・aza danych" zaimplemen-towana w arkuszu kalkulacyjnym, moｿesz sobie wyobrazi・ co dziaｳoby si・w przypadku bardziej zｳoｿonych baz. Je徑i korzystasz z takiej bazy, a chciaｳby・zwi麑szy・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忤ietlaniem 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從iejszych do忤iadcze・z arkuszami kalkulacyjnymi. Innymi sｳowy, musisz si・pogodzi・z tym, ｿe pewne sposoby wy忤ietlania danych nie sｹ juｿ dost麪ne - nie moｿna stosowa・typowych dla arkuszy kalkulacyjnych postaci raport. 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徑i korzystasz z aplikacji bazy danych, nie moｿesz wygenerowa・raportu o takiej strukturze, ze wzgl鹽u na spos 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 rnych 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從iej dokumentem, jest jednak tak samo czytelny. Powiniene・wiec zmieni・nieco sw spos patrzenia na baz・danych. Tak czy inaczej, wykorzystanie programu SZRBD jest o wiele efektywniejsze niｿ tworzenie ・azy danych" za pomocｹ arkusza kalkulacyjnego. Prawdziwa baza danych daje niepornanie wi麑szｹ kontrole nad integralno彡iｹ, spno彡iｹ i poprawno彡iｹ danych, umoｿliwiajｹc jednocze從ie odczytywanie informacji na wiele rnych sposob. Projekty oparte na konkretnych systemach zarzｹdzania Programy SZRDB nie dostarczajｹ procedur czy nawet powod do zaprojektowania bazy danych w jaki・konkretny spos - zawierajｹ jedynie narz鹽zia umoｿliwiajｹce dokonanie implementacji. Tymczasem metodologia projektowania baz danych opisuje zarno sposoby, jak i uzasadnienie dla tworzenia poprawnego i efektywnego projektu. Wiele os wpada w puｳapk・tworzenia projekt dla konkretnego systemu zarzｹdzania. Uｿywajｹc narz鹽zi dostarczanych przez taki system, moｿesz oczywi彡ie skonstruowa・・ziaｳajｹcｹ" baz・danych, lecz jej struktura b鹽zie prawdopodobnie nieefektywna, a Ty nie b鹽ziesz o tym wiedziaｳ. Takie projektowanie prowadzi do nieprawidｳowych struktur, sｳabej integralno彡i danych oraz problem zwiｹzanych z niespnymi lub bｳ鹽nymi informacjami. Bez dogｳ鹵nego zrozumienia zasad dobrego projektowania pr鹽zej czy pniej doprowadzisz do sytuacji, w ktej to program SZRBD - a nie twoja organizacja - zacznie dyktowa・struktur・tworzonej bazy. #308 Ostatnie przemy徑enie Przez lata nauczania zasad tworzenia projekt i wykorzystania rnorodnych program SZRBD, zaobserwowaｳem interesujｹce zjawisko: osoby, ktym znane sｹ podstawy metod projektowania, majｹ zazwyczaj lepsze zrozumienie program SZRBD i oferowanych przez nie narz鹽zi, niｿ pozostali uｿytkownicy. My徑・ ｿe bierze si・to z faktu, iｿ ludzie ci wiedzｹ, do czego sｳuｿｹ rne opcje udost麪niane przez programy SZRBD i wiedzｹ teｿ, jak z nich korzysta・ Z tego powodu - jak rnieｿ z wielu innych - warto jest poznawa・wｳa彡iwe metody projektowania. Droga opisywana przez t・ksiｹｿk・nie jest jedynym sｳusznym szlakiem, my徑・jednak, ｿe jest najprostsza, najbezpieczniejsza i najbardziej ucz黌zczana. Podsumowanie Rozdziaｳ ten pornuje projekt relacyjnej bazy danych z innymi, mniej efektywnymi formatami. Najpierw przyjrzeli徇y si・projektowi plikowemu. Dowiedziaｳe・si・ ｿe zwiｹzane jest z nim wiele powaｿnych problem i ｿe naleｿy go za wszelkｹ cen・unika・ Nast麪nie przea...
sliwak