#43 Rozdział 2. Projektowanie bazy danych Projektowanie bazy danych musimy podzielić na kilka etapów. Na poczštku należy okrelić, w jakim celu tworzymy naszš bazę danych. Pozwoli to odpowiedzieć na pytanie, jakie dane majš być w bazie przechowywane. Następnie należy okrelić powišzania zachodzšce pomiędzy naszymi danymi i sposób ich organizacji. Kolejny krok to stworzenie bazy danych przy pomocy instrukcji SQL, według uprzednio przygotowanego projektu - o tym będzie rozdział 3. W tym rozdziale zajmiemy się elementami projektu, które muszš być ustalone przed pisaniem kodu programu. Sš tu do rozwišzania ważne problemy, które decydujš w przyszłoci o tym, że baza danych spełni nasze oczekiwania, będzie wydajna i integralna. Przed przystšpieniem do pracy chciałbym jeszcze uprzedzić poczštkujšcych projektantów, że projektowanie bazy danych nie jest ani szybkie, ani łatwe. W pracy tej - poza sztywnymi regułami - pojawia się miejsce dla inicjatywy z pogranicza magii i sztuki. Jest też pewne, że pierwsza baza danych nie będzie doskonała. Nawet starzy wyjadacze cišgle się uczš i stwierdzajš, że można zawsze co ulepszyć. Dysponujemy jednak pewnš metodykš przydatnš podczas tworzenia baz danych. Modelowanie zwišzków encji to proces, podczas którego wyznaczany jest podział danych na tabele lub encje oraz okrelane sš relacje między nimi. Normalizacja to metoda organizacji danych w tabelach, tak aby spełnić reguły postaci normalnych. Postacie normalne wyznaczajš sprawdzone standardy organizacji danych zapewniajšce eliminację problemów z integralnociš danych. ============== RADA Reguły wspomagajšce projektowanie bazy danych sš podobne bardziej do zasad gramatycznych, niż do cisłych, sformalizowanych praw matematycznych. Innymi słowy, należy je traktować bardziej jako wskazówki, niż niezmienne prawa. Wcale nie powinny więc dziwić przypadki, kiedy w projekcie postępujemy wbrew tym zasadom, kierujšc się intuicjš czy zdrowym rozsšdkiem. Cały kunszt dowiadczonego projektanta polega na tym, że wie on, kiedy te zasady mogš być złamane. =============== Zanim omówię metody projektowania baz danych, przypomnę pojęcia wprowadzone w poprzednim rozdziale. #44 Struktura bazy danych Najistotniejszym postulatem, wynikajšcym z rozdziału pierwszego, było pokazanie, że istota relacyjnych baz danych opiera się na gromadzeniu danych w tabelach. Stanowiš one ródło danych dla zapytań, te z kolei zwracajš wyniki jako tabele. Poniżej zebrano podstawowe zasady modelu relacyjnego: * Dane prezentowane sš użytkownikom w formie tabel. * Komórki tabel zawierajš wartoci niepodzielne na mniejsze porcje informacji (ang. atomic values). * Każdy wiersz tabeli posiada wartoć (lub grupę wartoci), która go jednoznacznie identyfikuje (klucz główny). * W przypadku okrelenia relacji między tabelami dane z kolumny połšczonej relacjš muszš mieć swoje odpowiedniki w kolumnie w drugiej tabeli. Trzecia i czwarta zasada jest często w bazie danych opcjonalna. To znaczy, że nie wszystkie wiersze w tabeli muszš być unikalne oraz nie ma koniecznoci okrelania relacji między tabelami. Jednak na dłuższš metę stosowanie tych reguł jest zalecane, gdyż zapewnia zachowanie spójnoci danych. Wartoć lub grupa wartoci jednoznacznie identyfikujšca każdy wiersz nazywana jest kluczem głównym (ang. primary key). Odpowiadajšca mu kolumna lub grupa kolumn w drugiej tabeli nazywana jest kluczem obcym (ang. foreign key), a takie powišzanie kolumn z dwóch tabel nazywamy relacjš. Kolejnym pojęciem zwišzanym z projektem bazy danych jest schemat. Schemat okrela strukturę danych, w tym listę tabel wraz z charakterystykš poszczególnych kolumn i kluczy. Opis schematu bazy danych zawiera nazwę tabeli z następujšcš dalej listš kolumn wypisanš w nawiasach, jak w przykładzie: jaka_tabela (klucz_glówny, kolumna1, kolumna2, kolumna3) Dobre i złe bazy danych Opis metod projektowania chciałbym rozpoczšć od wskazania kilku cech, które powodujš, że jedna baza jest uważana za dobrš, inna za złš. Mam nadzieję, że w trakcie pracy nauczysz się rozpoznawać te dobre i złe właciwoci, aby w twoich bazach zawsze przeważały te dobre. Charakterystyka dobrej bazy danych Trudno nie rozpoznać dobrej bazy danych. Praca z nišjest szybka i niezawodna, łatwo znajdujemy potrzebne nam dane, które zachowujš spójnoć, mimo cišgłej aktualizacji. #45 Oczywicie, chociaż dobra baza spełnia wszystkie te kryteria jednoczenie, to przede wszystkim zachowuje między nimi równowagę. Na przykład przechowywanie danych w jednej tabeli zapewnia łatwy dostęp do nich, jednak za cenę słabej wydajnoci i słabej integralnoci - powoduje to bowiem duplikowanie się wielu informacji. Z kolei zbytnie rozdzielenie danych pomiędzy wiele tabel zapewnia zachowanie spójnoci, ale utrudnia dostęp do danych, zmuszajšc do pisania bardziej rozbudowanych i skomplikowanych zapytań, może też mieć negatywny wpływ na szybkoć pracy. Tak samo projektowanie bazy tylko pod kštem wydajnoci, kosztem jej spójnoci i dobrej struktury organizacyjnej, też nie prowadzi do satysfakcjonujšcych rezultatów. Do projektanta należy znalezienie właciwej recepty na dobrš bazę danych. Musi on mieć na względzie wszystkie trzy ważne przymioty: organizację, spójnoć i wydajnoć bazy danych oraz wyważyć je odpowiednio do tworzonej aplikacji. Ostatecznš ocenš bazy danych jest to, czy zdobywa pozytywnš ocenę użytkowników, ich zaufanie i satysfakcję. Jak poznać złš bazę danych Często łatwiej powiedzieć, co zostało zrobione le, niż wskazać, co zrobić, żeby było dobrze. Mało odkrywcze, ale prawdziwe jest stwierdzenie, że złe cechy bazy danych sš przeciwieństwem tych dobrych. Niestety, łatwo zaprojektować marnš bazę, w której wydajnoć i integralnoć danych nie będzie zadowalajšca. Przestrzeganie poniższych wskazówek pomoże nam to zagrożenie oddalić od naszego projektu. Oto cechy złej bazy danych: * Tabele i kolumny majš niejasne nazwy. * Ta sama informacja musi być wprowadzona do bazy wielokrotnie, a w przypadku modyfikacji, musi być zmieniana w kilku miejscach. * Zapytania wyszukujšce tę samš informację zwracajš różny wynik. * Działanie bazy danych jest powolne. Niepoprawnie zaprojektowana baza danych zwraca wyniki zapytań zbyt wolno, co znacznie utrudnia korzystanie z niej. W rozdziale 12. omówiłem zagadnienia wydajnoci baz danych. * Trudno okrelić relacje pomiędzy danymi. * W tabelach występujš duplikujšce się wiersze. Projektowanie Chcšc pokazać, jak odbywa się projektowanie bazy danych, przeledzimy krok po kroku projekt pewnej bazy danych, gromadzšcej informacje o produkcji filmowej. Baza ta będzie używana we wszystkich przykładach w tej ksišżce. #46 Projektowanie możemy podzielić na kilka etapów. 1. Zbieranie danych. Musimy okrelić wymagania wobec tworzonej bazy i na tej podstawie odpowiedzieć na pytanie, jakie dane będziemy w naszej bazie danych przechowywać. 2. Sporzšdzenie listy danych. Po okreleniu, jakie informacje będš gromadzone w bazie, należy okrelić typy danych oraz ich atrybuty. 3. Modelowanie danych na przykład metodš diagramów zwišzków encji. Należy pogrupować dane w encje, okrelić atrybuty encji i zwišzki encji. 4. Przeprowadzenie normalizacji. 5. Napisanie kodu SQL tworzšcego bazę i stworzenie bazy w konkretnym systemie relacyjnych baz danych. 6. Zdefiniowanie użytkowników bazy danych i nadanie im okrelonych praw dostępu. 7. Wypełnienie bazy danych informacjami. Tak wyglšdajš, ogólnie, najważniejsze etapy projektowania bazy danych. Nie jest to, oczywicie, jedyna prawidłowa metoda tworzenia bazy danych, a każda inna, która prowadzi do celu i daje pożšdane rezultaty, jest równie dobra. Zanim przystšpisz do projektu ====================== Rada Przed przystšpieniem do pisania kodu i projektowania architektury bazy danych należy okrelić przeznaczenie gromadzonych w niej informacji. Większoć baz danych jest projektowana w celu zastšpienia istniejšcych systemów przechowywania informacji lub jako składnica danych konkretnej aplikacji. ======================= Bardzo ważne w pierwszej fazie projektu sš rozmowy z przyszłymi użytkownikami systemu. Przed rozpoczęciem projektowania należy jasno okrelić, jakie dane powinny być przechowywane w bazie danych i w jaki sposób będš udostępniane. Najlepiej informacje te zdobyć włanie od osób, które będš używały aplikacji i dokładnie wiedzš, jakie sš ich wymagania i oczekiwania wobec projektowanej bazy. Wróćmy do naszego przykładu bazy danych o filmach. Chcemy przechowywać informacje na temat filmów, które co roku wchodzš na ekrany. Informacji zwišzanych z każdym filmem jest znacznie więcej, niż można by się spodziewać. To, które dane sš istotne, a które możemy pominšć, zależy od wielu czynników. W przypadku, gdy nowa baza danych zastępuje stary system, decydujšce jest zapewnienie zgodnoci z poprzednim systemem. W przypadku nowego produktu bardzo istotne sš wymagania projektanta aplikacji wykorzystujšcej bazę danych oraz przyszłych użytkowników. #47 ======================= Rada Nie mniej ważne od tego, co przechowujemy w bazie danych, jest to, co możemy z niej wydobyć przy pomocy zapytań i raportów. Użytkownicy włanie pod tym kštem oceniš nasz produkt. ========================== Baza danych, majšca być składnicš informacji o przemyle filmowym, powinna gromadzić dane o studiach filmowych, filmach, obsadzie, ekipie filmowej, plenerach filmowych, efektach finansowych i jeszcze wielu innych, nie wymienionych tutaj szczegółach. Już na tym etapie projektu widać, jak ogromny zasięg tematyczny ma nasza baza danych. W przykładzie omawianym w tej ksišżce zasięg tematyczny zostanie zawężony tylko do niektórych tematów. Postanowiłem, że nasza baza będzie gromadzić dane dotyczšce filmów, studiów filmowych, reżyserów, członków obsady i ich ról w fi...
sliwak