Podstawowe informacje o projekcie bazy danych Wykorzystano artykuł http://office.microsoft.com/pl-pl Prawidłowo zaprojektowana baza danych umożliwia dostęp do aktualnych i dokładnych informacji. Ponieważ poprawny projekt jest bardzo istotny dla skutecznej pracy z bazą danych, warto poświęcić trochę czasu, aby opanować zasady dobrego projektowania. Dzięki temu łatwiej będzie tworzyć bazy danych odpowiadające określonym potrzebom oraz wprowadzać zmiany. W niniejszym artykule podano wskazówki dotyczące planowania bazy danych. Opisano tu, jak określać zakres potrzebnych informacji, dzielić informacje na właściwe tabele i kolumny oraz tworzyć relacje między tymi tabelami. Warto przeczytać ten artykuł przed utworzeniem pierwszej bazy danych. Kilka ważnych terminów dotyczących baz danych Co to jest dobry projekt bazy danych? Proces projektowania Określanie celu, jakiemu ma służyć baza danych Wyszukiwanie i organizowanie potrzebnych informacji Dzielenie informacji na tabele Przekształcanie elementów informacji w kolumny Określanie kluczy podstawowych Tworzenie relacji pomiędzy tabelami Udoskonalanie projektu Stosowanie reguł normalizacji Więcej informacji Kilka ważnych terminów dotyczących baz danych Program Microsoft Office Access 2007 umożliwia organizowanie informacji w tabelach: listach wierszy i kolumn przypominających księgę podatkową lub arkusz programu Microsoft Office Excel 2007. W prostej bazie danych może być tylko jedna tabela. Większość baz danych składa się jednak z większej liczby tabel. Może na przykład istnieć jedna tabela do przechowywania informacji o produktach, inna tabela do przechowywania informacji o zamówieniach i jeszcze inna do przechowywania informacji o klientach. Każdy wiersz jest również zwany rekordem, a każda kolumna polem. Rekord jest spójnym i znaczącym sposobem scalania informacji na dany temat. Pole stanowi jeden element informacji typ elementu występujący w każdym rekordzie. Na przykład w tabeli Produkty każdy wiersz, czyli rekord, zawiera informacje o jednym produkcie. Każda kolumna, czyli pole, zawiera dany typ informacji o danym produkcie, na przykład jego nazwę lub cenę. 1
Co to jest dobry projekt bazy danych? Procesem projektowania bazy danych kierują pewne zasady. Pierwsza zasada głosi, że zduplikowane informacje (zwane też danymi nadmiarowymi) są szkodliwe, ponieważ powodują utratę miejsca i zwiększają prawdopodobieństwo błędów oraz niekonsekwencji. Zgodnie z drugą zasadą ważna jest zarówno poprawność, jak i kompletność informacji. Jeśli baza danych zawiera nieprawidłowe informacje, wszystkie raporty utworzone na podstawie tej bazy danych także będą zawierać nieprawidłowe informacje. W związku z tym wszelkie decyzje podjęte na podstawie tych raportów będą oparte na błędnych przesłankach. Można więc powiedzieć, że dobry projekt bazy danych to taki, który: dzieli informacje na tabele tematyczne i redukuje dane nadmiarowe, udostępnia programowi Access informacje potrzebne do prawidłowego dołączania informacji do tabel, pomaga utrzymywać i zapewniać dokładność oraz integralność informacji, uwzględnia potrzeby w zakresie przetwarzania danych i raportowania. Proces projektowania Proces projektowania składa się z następujących kroków: Określanie celu, jakiemu ma służyć baza danych Określenie celu pomaga przygotować się do następnych kroków. Wyszukiwanie i organizowanie potrzebnych informacji Należy zebrać wszystkie typy informacji, które mają zostać zarejestrowane w bazie danych, takie jak nazwa produktu i numer zamówienia. Dzielenie informacji na tabele Informacje należy podzielić na główne jednostki lub tematy, takie jak Produkty czy Zamówienia. Następnie każdy temat stanie się tabelą. Przekształcanie elementów informacji w kolumny Należy zdecydować, jakie informacje mają być przechowywane w poszczególnych tabelach. Każdy element stanie się polem i będzie wyświetlany jako kolumna w tabeli. Tabela Pracownicy może na przykład zawierać pola Nazwisko i Data zatrudnienia. Określanie kluczy podstawowych Należy wybrać klucz podstawowy dla każdej tabeli. Klucz podstawowy to kolumna używana do unikatowej identyfikacji poszczególnych wierszy. Może nim być na przykład identyfikator produktu lub identyfikator zamówienia. Tworzenie relacji pomiędzy tabelami Należy przejrzeć wszystkie tabele i zdecydować, jaka jest relacja danych z jednej tabeli do danych w innych tabelach. W razie potrzeby trzeba dodać pola do tabel lub utworzyć nowe tabele, aby jasno określić relacje. Udoskonalanie projektu Należy sprawdzić projekt pod kątem błędów. Trzeba utworzyć tabele i dodać kilka rekordów przykładowych danych oraz sprawdzić, czy tabele umożliwiają otrzymywanie oczekiwanych wyników. W razie potrzeby należy skorygować projekt. 2
Stosowanie reguł normalizacji Należy zastosować reguły normalizacji danych, aby sprawdzić, czy tabele mają prawidłową strukturę. W razie potrzeby należy skorygować tabele. Określanie celu, jakiemu ma służyć baza danych Warto sobie zapisać cel, jakiemu ma służyć baza danych jakie będzie jej przeznaczenie, jacy jej użytkownicy i jaki oczekiwany sposób użycia. W przypadku małych baz danych dla potrzeb działalności gospodarczej prowadzonej w domu można na przykład zapisać cel typu Baza danych klientów przechowuje listę informacji o klientach do wykorzystania podczas tworzenia korespondencji i raportów. Jeśli baza danych jest bardziej złożona i używana przez wiele osób, co często ma miejsce w środowisku firmowym, określenie celu może zająć cały akapit lub więcej i powinno obejmować sposoby i okoliczności używania bazy danych przez poszczególne osoby. Ma to na celu określenie dopracowanej listy głównych celów, stanowiącej odnośnik w całym procesie projektowania. Takie zestawienie pozwala skupić się na priorytetach przy podejmowaniu decyzji. Wyszukiwanie i organizowanie potrzebnych informacji Wyszukiwanie i organizowanie potrzebnych informacji należy zacząć od istniejących informacji. Być może w firmie są przechowywane zamówienia lub informacje o klientach w segregatorach. Należy zebrać te dokumenty i utworzyć listę wszystkich typów zawartych w nich informacji (na przykład każde pole wypełniane w formularzu). Jeśli nie ma istniejących formularzy, należy sobie wyobrazić, jakie informacje zostałyby zawarte w formularzu do rejestracji informacji o klientach, gdyby taki formularz miał zostać zaprojektowany. Jakie pola do wypełniania zostałyby w nim utworzone? Należy zidentyfikować i wypisać wszystkie te elementy. Załóżmy, że użytkownik prowadzi listę klientów w postaci kart katalogowych. Analiza tych kart wykazuje, że każda karta zawiera imię i nazwisko klienta lub nazwę firmy, ulicę, miasto, województwo, kod pocztowy i numer telefonu. Każdy z tych elementów stanowi potencjalną kolumnę w tabeli. Na tym etapie przygotowywania listy typów informacji nie chodzi o dopracowanie szczegółów. Warto raczej umieścić na liście wszystkie elementy, które przyjdą użytkownikowi na myśl. Warto zasięgnąć opinii wszystkich innych osób, które będą używać bazy danych. Listę można później poprawić. Następnie należy przeanalizować typy raportów i korespondencji, które będą tworzone na podstawie bazy danych. Na przykład może to być raport ze sprzedaży produktów, pokazujący sprzedaż według regionów, albo raport podsumowujący wyniki inwentaryzacji, pokazujący stan zapasów produktów. Można też generować listy do klientów informujące o imprezach handlowych lub ofertach specjalnych. Raport można zaprojektować w myślach i wyobrazić sobie jego wygląd. Jakie informacje będą w nim umieszczane? Należy sporządzić listę wszystkich elementów. Ten sam proces trzeba powtórzyć w przypadku listów seryjnych i wszystkich innych przewidywanych raportów. Obmyślanie przyszłych raportów i korespondencji pomaga zidentyfikować elementy potrzebne w bazie danych. Załóżmy na przykład, że użytkownik umożliwia klientom zamawianie okresowych wiadomości e-mail (lub rezygnowanie z nich) i chce wydrukować listę klientów, którzy je zamówili. Aby zarejestrować te informacje, należy dodać do tabeli klientów kolumnę Wyślij wiadomość e-mail. Dla każdego klienta można przypisać do tego pola wartość Tak lub Nie. Wymóg wysyłania wiadomości e-mail wiąże się z koniecznością zarejestrowania także innego elementu. Skoro klient życzy sobie otrzymywać wiadomości e-mail, musi być znany adres e-mail, pod który wiadomości te będą wysyłane. Trzeba więc zarejestrować adres e-mail każdego klienta. Warto utworzyć prototyp każdego raportu lub listę danych wyjściowych i zastanowić się, jakie elementy będą potrzebne do każdego raportu. Podczas analizowania listu seryjnego może na przykład wyniknąć kilka spraw. Aby włączyć do listu odpowiedni zwrot grzecznościowy na przykład ciąg Pan lub Pani rozpoczynający powitanie, należy utworzyć element grzecznościowy. Jeśli ponadto użytkownik chce rozpoczynać listy od zwrotu typu Szanowny Pan Nowak, a nie Szanowny Pan Jan Nowak, nazwiska i imiona muszą być przechowywane osobno. Kluczową kwestią jest rozdzielanie informacji na najmniejsze użyteczne części. Aby na przykład mieć szybki dostęp do nazwiska klienta, należy rozbić element informacji na dwie części imię i nazwisko. Zapisanie nazwiska osobno ułatwia na 3
przykład sortowanie raportu według nazwisk. Ogólnie umieszczenie elementu w osobnym polu ułatwia sortowanie, wyszukiwanie, wykonywanie obliczeń i tworzenie raportów na podstawie tego elementu. Należy przemyśleć pytania, które będą zadawane w odniesieniu do bazy danych. Na przykład: ile operacji sprzedaży oferowanego produktu zostało dokonanych w zeszłym miesiącu? Gdzie mieszkają najlepsi klienci? Kto jest dostawcą najlepiej sprzedającego się produktu? Przewidziawszy te pytania, łatwiej określić dodatkowe elementy do rejestrowania. Po zebraniu tych informacji można przejść do następnego kroku. Dzielenie informacji na tabele W celu podzielenia informacji na tabele należy wybrać główne jednostki, czyli tematy. Na przykład po wyszukaniu i zorganizowaniu informacji do zawarcia w bazie danych sprzedaży produktów wstępna wersja listy może wyglądać tak: Widoczne tu główne jednostki to produkty, dostawcy, klienci i zamówienia. Rozsądek nakazuje, aby utworzyć cztery tabele: jedną zawierającą fakty dotyczące produktów, jedną zawierającą fakty dotyczące dostawców, jedną zawierającą fakty dotyczące klientów i jedną zawierającą fakty dotyczące zamówień. Chociaż taki zestaw nie wyczerpuje listy, stanowi dobry punkt wyjścia. Listę tę można doskonalić, aż do wypracowania satysfakcjonującego projektu. Po pierwszym przeglądzie wstępnej listy elementów może się wydawać dobrym pomysłem umieszczenie wszystkich elementów z listy w jednej tabeli, a nie w czterech widocznych na powyższej ilustracji. W tej części wyjaśniono, dlaczego lepiej tego robić. Zastanówmy się przez chwilę nad taką tabelą. Każdy wiersz zawiera informacje na temat produktu i jego dostawcy. Ponieważ wiele produktów może pochodzić od tego samego dostawcy, informacje na temat nazwy i adresu dostawcy muszą się wielokrotnie powtarzać. W ten sposób niepotrzebnie zajmuje się miejsce na dysku. Dużo lepszym rozwiązaniem jest jednorazowa rejestracja danych dostawcy w osobnej tabeli Dostawcy i połączenie tej tabeli z tabelą Produkty. Drugi problem tego projektu wychodzi na jaw w sytuacji, gdy trzeba zmodyfikować informacje o dostawcy. Załóżmy na przykład, że adres dostawcy się zmienił. Ponieważ adres występuje w tylu miejscach, może się zdarzyć, że zostanie przypadkiem zmieniony tylko w jednym miejscu, a w innych już nie. Zarejestrowanie adresu dostawcy tylko w jednym miejscu rozwiązuje ten problem. Projektując bazę danych, należy starać się rejestrować każdy fakt tylko jeden raz. Jeśli te same informacje pojawiają się w kilku miejscach, na przykład adres określonego dostawcy, należy je umieścić w osobnej tabeli. Na koniec załóżmy, że firma Coho Winery dostarcza tylko jeden produkt, a trzeba usunąć ten produkt, lecz zachować informacje na temat nazwy i adresu dostawcy. Jak usunąć rekord produktu bez utraty informacji o dostawcy? To niemożliwe. Ponieważ każdy rekord zawiera fakty dotyczące produktu oraz fakty dotyczące dostawcy, nie można usunąć tylko faktów dotyczących produktu. Aby zachować te fakty oddzielnie, należy rozdzielić tabelę na dwie: jedną z informacjami o produktach i jedną z informacjami o dostawcach. Wówczas usunięcie rekordu produktu spowoduje tylko usunięcie faktów dotyczących produktu, a nie faktów dotyczących dostawcy. 4
Gdy zostaną wybrane tematy reprezentowane przez tabelę, w kolumnach tej tabeli powinny być przechowywane wyłącznie fakty związane z tym tematem. Na przykład w tabeli produktów powinny być przechowywane wyłącznie fakty dotyczące produktów. Ponieważ adres dostawcy jest faktem dotyczącym dostawcy, a nie faktem dotyczącym produktu, powinien znajdować się w tabeli Dostawcy. Przekształcanie elementów informacji w kolumny W celu określenia kolumn w tabeli należy zdecydować, które informacje dotyczące tematu rejestrowanego w tabeli mają być śledzone. Na przykład w przypadku tabeli Klienci dobry punkt wyjścia do listy kolumn stanowi zestaw: Nazwisko, Adres, Miasto, województwo i kod, Wyślij wiadomość e-mail, Zwrot grzecznościowy oraz Adres e-mail. Każdy rekord w tabeli zawiera ten sam zestaw kolumn, tak więc dla każdego rekordu można zapisać informacje dotyczące nazwiska, adresu, miasta, województwa i kodu, wysyłania wiadomości e-mail, zwrotu grzecznościowego i adresu e-mail. Na przykład kolumna Adres zawiera adresy klientów. Każdy rekord zawiera dane o jednym kliencie, a pole adresu zawiera adres tego klienta. Po określeniu wstępnego zestawu kolumn w każdej tabeli kolumny można udoskonalać. Na przykład warto zachować imię i nazwisko klienta jako dwie osobne kolumny, aby można było sortować, wyszukiwać i indeksować informacje według nazwisk. Także adres składa się w rzeczywistości z pięciu osobnych składników, czyli ulicy, miasta, województwa, kodu pocztowego i kraju/regionu, a zatem warto je rozdzielić na pięć osobnych kolumn. Aby wykonać wyszukiwanie, filtrowanie lub sortowanie na przykład według województwa, informacje na temat województwa muszą być przechowywane w osobnej kolumnie. Należy się również zastanowić, czy w bazie danych będą przechowywane tylko informacje krajowe, czy także informacje międzynarodowe. Jeśli na przykład w bazie danych znajdą się także adresy zagraniczne, lepiej użyć kolumny Region zamiast Województwo, ponieważ można w niej wprowadzać zarówno krajowe województwa, jaki i regiony innych krajów. Podobnie kolumna Międzynarodowy kod pocztowy jest lepszym rozwiązaniem niż kolumna Lokalny kod pocztowy, jeśli w bazie danych będą przechowywane adresy zagraniczne. Na liście poniżej zamieszczono kilka porad na temat określania kolumn. Nie należy dodawać danych obliczonych Zazwyczaj w tabelach nie należy przechowywać wyników obliczeń. Można natomiast używać programu Access do wykonywania tych obliczeń, gdy ich wyniki okażą się potrzebne. Załóżmy na przykład, że istnieje raport Produkty zamówione, który wyświetla sumy częściowe jednostek zamówionych dla każdej kategorii produktów w bazie danych. Kolumny sum częściowych jednostek zamówionych nie ma jednak w żadnej tabeli. Za to tabela Produkty zawiera kolumnę Jednostki zamówione, w której są przechowywane informacje o jednostkach zamówionych dla każdego produktu. Na podstawie tych danych program Access oblicza sumę częściową przy każdym drukowaniu raportu. Sama suma częściowa nie powinna być przechowywana w żadnej tabeli. Informacje należy przechowywać w jak najmniejszych jednostkach logicznych Może się wydawać, że umieszczenie w jednym polu imion i nazwisk lub nazw produktów wraz opisami produktów to dobry pomysł. Jeśli jednak w jednym polu znajdzie się więcej niż jeden rodzaj informacji, później trudno będzie uzyskiwać pojedyncze fakty. Dlatego należy spróbować rozdzielić informacje na logiczne części i na przykład utworzyć osobne pola imion i nazwisk lub nazw produktów, kategorii i opisów. 5
Po udoskonaleniu kolumn danych w każdej tabeli można wybrać klucz podstawowy tabeli. Określanie kluczy podstawowych Każda tabela powinna zawierać kolumnę lub zestaw kolumn, które w sposób unikatowy identyfikują poszczególne wiersze zapisane w danej tabeli. Rolę tę często odgrywa unikatowy numer identyfikacyjny, taki jak numer identyfikacyjny pracownika czy numer seryjny. W terminologii baz danych te informacje określa się mianem klucza podstawowego tabeli. Program Access używa pól klucza podstawowego do szybkiego kojarzenia danych z wielu tabel i przedstawiania ich razem użytkownikowi. Jeśli już istnieje unikatowy identyfikator dla tabeli, na przykład numer produktu, który jednoznacznie identyfikuje każdy produkt w katalogu, można go użyć jako klucza podstawowego tabeli ale tylko wtedy, gdy wartość w tej kolumnie będzie inna dla każdego rekordu. Kluczem podstawowym nie mogą być duplikujące się wartości. Na przykład nie należy używać nazwisk osób jako klucza podstawowego, ponieważ nazwiska nie są unikatowe. W jednej tabeli bez problemu mogą się znaleźć dwie osoby o tym samym nazwisku. Klucz podstawowy musi zawsze zawierać wartość. Jeśli wartość kolumny może być w pewnym momencie nieprzypisana lub nieznana (brak wartości), to nie będzie stanowić składnika klucza podstawowego. Zawsze należy wybierać taki klucz podstawowy, którego wartość nie ulegnie zmianie. W bazie danych zawierającej więcej niż jedną tabelę klucz podstawowy tabeli może służyć jako odwołanie w innych tabelach. Jeśli klucz podstawowy zostanie zmieniony, zmianę należy wprowadzić wszędzie, gdzie znajduje się odwołanie do tego klucza. Zastosowanie niezmiennego klucza podstawowego zmniejsza ryzyko, że klucz podstawowy nie będzie zsynchronizowany z innymi tabelami, które odwołują się do niego. Często rolę klucza podstawowego odgrywa dowolny unikatowy numer. Do każdego zamówienia można na przykład przypisać unikatowy numer zamówienia. Numer zamówienia służy wyłącznie do identyfikowania zamówienia. Jest przypisywany tylko raz i nigdy się nie zmienia. Jeśli nie można znaleźć kolumny lub zestawu kolumn odpowiednich do utworzenia dobrego klucza podstawowego, warto rozważyć użycie kolumny o typie danych Autonumerowanie. Użycie typu danych Autonumerowanie sprawia, że program Access automatycznie przypisuje wartość. Taki identyfikator nie jest merytoryczny nie zawiera żadnych rzeczywistych informacji opisujących wiersz, któremu odpowiada. Identyfikatory niemerytoryczne są znakomitymi kluczami podstawowymi, ponieważ nigdy się nie zmieniają. Jest bardziej prawdopodobne, że klucz podstawowy zawierający fakty dotyczące wiersza na przykład numer telefonu lub nazwisko klienta zmieni się, ponieważ te informacje mogą ulec zmianie. Kolumna ustawiona na typ danych Autonumerowanie często stanowi dobry klucz podstawowy. Żaden identyfikator produktu nie powtórzy się więcej niż raz. W niektórych przypadkach może być wymagane użycie dwóch lub większej liczby pól, które razem będą stanowiły klucz podstawowy tabeli. Na przykład w tabeli Szczegóły zamówień, przechowującej pozycje zamówień w wierszach, jako klucz podstawowy są używane dwie kolumny. Są to Identyfikator zamówienia i Identyfikator produktu. Klucz podstawowy obejmujący więcej niż jedną kolumnę jest także nazywany kluczem złożonym. W bazie danych sprzedaży produktów można utworzyć kolumnę Autonumerowanie jako klucz podstawowy dla każdej tabeli: Identyfikator produktu dla tabeli Produkty, Identyfikator zamówienia dla tabeli Zamówienia, Identyfikator klienta dla tabeli Klienci i Identyfikator dostawcy dla tabeli Dostawcy. 6
Tworzenie relacji pomiędzy tabelami Gdy dzielenie informacji na tabele zostanie zakończone, trzeba opracować metodę ponownego zestawiania informacji w sensowny sposób. Na przykład następujący formularz zawiera informacje z kilku tabel. Informacje w tym formularzu pochodzą z tabeli Klienci......tabeli Pracownicy......tabeli Zamówienia......tabeli Produkty......oraz tabeli Szczegóły zamówień. Program Access jest systemem zarządzania relacyjnymi bazami danych. W relacyjnej bazie danych informacje są rozdzielane do osobnych, tematycznych tabel. Następnie zależnie od potrzeb informacje są na powrót zestawiane przy użyciu relacji pomiędzy tabelami. 7
TWORZENIE RELACJI JEDEN-DO-WIELU Rozważmy następujący przykład: tabele Dostawcy i Produkty w bazie danych zamówień na produkty. Każdy dostawca może dostarczać wiele produktów. W związku z tym każdemu sprzedawcy reprezentowanemu w tabeli Dostawcy może odpowiadać wiele produktów reprezentowanych w tabeli Produkty. Dlatego relacja pomiędzy tabelą Dostawcy a tabelą Produkty jest relacją jeden-do-wielu. Aby utworzyć w projekcie bazy danych relację jeden-do-wielu, należy klucz podstawowy z tabeli stanowiącej stronę jeden relacji dodać jako kolumnę lub kolumny do tabeli stanowiącej stronę wiele tej relacji. W analizowanym przykładzie należy dodać kolumnę Identyfikator dostawcy z tabeli Dostawcy do tabeli Produkty. Dzięki temu program Access będzie mógł używać numeru identyfikacyjnego dostawcy w celu wyszukiwania właściwego dostawcy każdego produktu w tabeli Produkty. W tabeli Produkty kolumna Identyfikator dostawcy jest kluczem obcym. Klucz obcy to klucz podstawowy innej tabeli. Kolumna Identyfikator dostawcy jest kluczem obcym w tabeli Produkty, ponieważ w tabeli Dostawcy jest kluczem podstawowym. Podstawy sprzęgania tabel pokrewnych są tworzone przez ustanawianie par kluczy podstawowych i kluczy obcych. Jeśli trudno ustalić, które tabele powinny współużytkować tę samą kolumnę, określenie relacji jeden-do-wielu gwarantuje, że dwie biorące w niej udział tabele rzeczywiście wymagają wspólnej kolumny. 8
TWORZENIE RELACJI WIELE-DO-WIELU Rozważmy relację pomiędzy tabelą Produkty a tabelą Zamówienia. Jedno zamówienie może obejmować wiele produktów. Z drugiej strony jeden produkt może się znaleźć w wielu zamówieniach. Dlatego każdemu rekordowi z tabeli Zamówienia może odpowiadać wiele rekordów z tabeli Produkty. A każdemu rekordowi z tabeli Produkty może odpowiadać wiele rekordów z tabeli Zamówienia. Ten typ relacji nazywa się relacją wiele-do-wielu, ponieważ każdemu produktowi może odpowiadać wiele zamówień, a każdemu zamówieniu może odpowiadać wiele produktów. Należy zauważyć, że aby wykryć relację wiele-do-wielu pomiędzy tabelami, trzeba się przyjrzeć obu stronom relacji. Między tematami dwóch tabel zamówieniami i produktami istnieje relacja wiele-do-wielu. Tak można krótko przedstawić ten problem. Aby go zrozumieć, należy sobie wyobrazić, co by się stało przy próbie utworzenia relacji między tymi tabelami przez dodanie pola Identyfikator produktu do tabeli Zamówienia. Aby można było umieścić więcej niż jeden produkt w jednym zamówieniu, w tabeli Zamówienia potrzebny jest więcej niż jeden rekord dla jednego zamówienia. To oznacza powtarzanie informacji zamówienia dla każdego wiersza odnoszącego się do jednego zamówienia w wyniku powstaje nieefektywny projekt prowadzący do błędów w danych. Taka sama sytuacja wystąpi w przypadku umieszczenia pola Identyfikator zamówienia w tabeli Produkty dla każdego produktu w tabeli Produkty pojawi się więcej niż jeden rekord. Jak można rozwiązać ten problem? Odpowiedź polega na utworzeniu trzeciej tabeli, często określanej jako tabela skrzyżowań, która rozbija relację wiele-dowielu na dwie relacje jeden-do-wielu. Do tej trzeciej tabeli wstawia się klucze podstawowe z obu pierwotnych tabel. W wyniku tego trzecia tabela rejestruje każde wystąpienie relacji. Każdy rekord w tabeli Szczegóły zamówień odpowiada jednej pozycji w zamówieniu. Klucz podstawowy tabeli Szczegóły zamówień składa się z dwóch pól kluczy obcych z tabel Zamówienia i Produkty. Użycie samego pola Identyfikator zamówienia jako klucza podstawowego tej tabeli nie sprawdza się, ponieważ jedno zamówienie może mieć wiele pozycji. Identyfikator zamówienia powtarza się w każdej pozycji zamówienia, więc to pole nie zawiera wartości unikatowych. Użycie samego pola Identyfikator produktu także się nie sprawdzi, ponieważ jeden produkt może występować w wielu zamówieniach. Ale razem oba te pola tworzą unikatową wartość dla każdego rekordu. W bazie danych sprzedaży produktów pomiędzy tabelami Zamówienia i Produkty nie istnieje relacja bezpośrednia. Istnieje pomiędzy nimi relacja za pośrednictwem tabeli Szczegóły zamówień. Relację wiele-do-wielu między zamówieniami a produktami reprezentują w bazie danych dwie relacje jeden-do-wielu: Istnieje relacja jeden-do-wielu pomiędzy tabelą Zamówienia a tabelą Szczegóły zamówień. Każde zamówienie może zawierać więcej niż jedną pozycję, ale każda pozycja jest powiązana tylko z jednym zamówieniem. Istnieje relacja jeden-do-wielu pomiędzy tabelą Produkty a tabelą Szczegóły zamówień. Z każdym produktem może być skojarzonych wiele pozycji, ale każda pozycja odwołuje się tylko do jednego produktu. Na podstawie tabeli Szczegóły zamówień można ustalić wszystkie produkty w danym zamówieniu. Można też ustalić wszystkie zamówienia dotyczące danego produktu. 9
Po wprowadzeniu tabeli Szczegóły zamówień lista tabel i pól może wyglądać podobnie do następującej: TWORZENIE RELACJI JEDEN-DO-JEDNEGO Jeszcze inny typ relacji to relacja jeden-do-jednego. Załóżmy na przykład, że chce się rejestrować szczególne informacje uzupełniające o produkcie, które będą rzadko potrzebne lub dotyczą tylko kilku produktów. Ponieważ informacje te nie będą często używane, a zapisanie ich w tabeli Produkty skutkowałoby pustymi miejscami w tabeli dla wszystkich produktów, których te informacje nie dotyczą, należy je umieścić w osobnej tabeli. Tak jak w tabeli Produkty kluczem podstawowym jest kolumna IDproduktu. Relacja pomiędzy tabelą uzupełniającą a tabelą Produkty to relacja jeden-do-jednego. Dla każdego rekordu w tabeli Produkty istnieje jeden pasujący rekord w tabeli uzupełniającej. Określenie takiej relacji wymaga, aby obie tabele używały wspólnego pola. Po wykryciu w bazie danych potrzeby utworzenia relacji jeden-do-jednego należy rozważyć, czy można umieścić informacje z dwóch tabel uczestniczących w tej relacji razem w jednej tabeli. Jeśli z jakiegoś powodu nie jest to wskazane, bo na przykład spowodowałoby powstanie wielu pustych miejsc, na poniższej liście pokazano, jak należy przedstawić tę relację w projekcie: Jeśli dwie tabele mają ten sam temat, to prawdopodobnie w obu tych tabelach można użyć tego samego klucza podstawowego. Jeśli tematy i klucze podstawowe obu tabel są różne, należy wybrać jedną z tabel (dowolną) i wstawić jej klucz podstawowy do drugiej tabeli jako klucz obcy. Określenie relacji pomiędzy tabelami pomaga zapewnić użycie właściwych tabel i kolumn. Jeśli istnieją relacje jeden-dojednego lub jeden-do-wielu, tabele uczestniczące w tych relacjach muszą używać co najmniej jednej wspólnej kolumny. Jeśli istnieje relacja wiele-do-wielu, relację tę przedstawia trzecia tabela. Udoskonalanie projektu Utworzywszy wymagane tabele, pola i relacje, należy utworzyć dane przykładowe i wprowadzić je do tabel, a następnie wykonać przy ich użyciu próbne operacje: tworzenie kwerend, dodawanie nowych rekordów i tak dalej. Dzięki temu można zlokalizować potencjalne problemy może się na przykład okazać, że trzeba dodać kolumnę, o której wstawieniu zapomniano w fazie projektowania, lub że istnieje tabela, którą należy rozdzielić na dwie tabele, aby usunąć zduplikowane dane. Należy sprawdzić, czy baza danych umożliwia uzyskiwanie potrzebnych odpowiedzi. Należy utworzyć robocze wersje formularzy i raportów oraz sprawdzić, czy przedstawiają one oczekiwane dane. Warto też poszukać zbędnych duplikacji danych, a gdy zostaną znalezione, zmienić projekt tak, aby je wyeliminować. 10
Podczas sprawdzania początkowej wersji bazy danych prawdopodobnie okaże się, że wiele jeszcze można udoskonalić. Warto przeanalizować bazę danych pod kątem następujących zagadnień: Czy nie zapomniano żadnych kolumn? Jeśli tak, to czy informacje z tych kolumn pasują do istniejących tabel? Jeśli informacje te dotyczą innego tematu, być może trzeba będzie utworzyć nową tabelę. Należy utworzyć kolumnę dla każdego elementu informacji, który ma być śledzony. Jeśli informacji nie da się obliczyć na podstawie innych kolumn, prawdopodobnie trzeba dodać nową kolumnę z tymi informacjami. Czy jakieś kolumny są zbędne, ponieważ zawarte w nich informacje można obliczyć na podstawie istniejących pól? Jeśli jakieś informacje można obliczyć na podstawie innych istniejących kolumn na przykład cenę z rabatem na podstawie ceny detalicznej zazwyczaj lepiej je obliczać niż tworzyć nową kolumnę. Czy w jakiejś tabeli trzeba wielokrotnie wprowadzać zduplikowane informacje? Jeśli tak, prawdopodobnie należy podzielić tę tabelę na dwie tabele połączone relacją jeden-do-wielu. Czy istnieją tabele z wieloma polami, ograniczoną liczbą rekordów i wieloma pustymi polami w poszczególnych rekordach? Jeśli tak, należy rozważyć taką zmianę projektu tabeli, aby zawierała ona mniej pól, a więcej rekordów. Czy wszystkie informacje rozbito na najmniejsze użyteczne części? Aby można było tworzyć raporty, sortować, wyszukiwać lub wykonywać obliczenia na podstawie jakiegoś elementu informacji, należy umieścić ten element w osobnej kolumnie. Czy we wszystkich kolumnach znajdują się fakty dotyczące tematu tabeli? Jeśli kolumna zawiera informacje niezwiązane z tematem tabeli, powinna się znaleźć w innej tabeli. Czy wszystkie relacje pomiędzy tabelami są reprezentowane przez wspólne pola lub trzecią tabelę? Relacje jedendo-jednego i jeden-do-wielu wymagają wspólnych kolumn. Relacje wiele-do-wielu wymagają trzeciej tabeli. UDOSKONALANIE TABELI PRODUKTY Załóżmy, że każdy produkt w bazie danych sprzedaży produktów jest przyporządkowany do kategorii ogólnej, takiej jak napoje, przyprawy czy owoce morza. Tabela Produkty może zawierać pole, w którym widać, do jakiej kategorii należy każdy produkt. Załóżmy, że po przeanalizowaniu i poprawieniu projektu bazy danych chce się przechowywać opis i nazwę kategorii. Dodanie pola Opis kategorii do tabeli Produkty sprawi, że każdy opis kategorii będzie powtarzany obok każdego produktu z tej kategorii nie jest to dobre rozwiązanie. Lepszym rozwiązaniem jest utworzenie w bazie danych nowego tematu Kategorie i odpowiedniej tabeli tematycznej z własnym kluczem podstawowym. Następnie klucz podstawowy z tabeli Kategorie można dodać do tabeli Produkty jako klucz obcy. Między tabelami Kategorie i Produkty powstanie relacja jeden-do-wielu: kategoria może obejmować wiele produktów, ale każdy produkt może należeć tylko do jednej kategorii. Przeglądając strukturę tabel, należy poświęcić szczególną uwagę ewentualnym powtarzającym się grupom. Rozważmy przykład tabeli zawierającej następujące kolumny: Identyfikator produktu Nazwa Identyfikator produktu 1 Nazwa 1 Identyfikator produktu 2 Nazwa 2 Identyfikator produktu 3 Nazwa 3 W tym przykładzie każdy produkt stanowi powtarzającą się grupę kolumn, które różnią się od siebie tylko liczbą dodaną na końcu nazwy kolumny. Widząc ponumerowane w ten sposób kolumny, należy powrócić do projektu. Taki projekt ma kilka wad. Po pierwsze zmusza użytkownika do określenia górnej granicy liczby produktów. Po przekroczeniu tej granicy trzeba dodać nową grupę kolumn do struktury tabeli, co jest poważnym zadaniem administracyjnym. Kolejny problem polega na tym, że dla dostawców mniejszej liczby produktów niż określona maksymalna liczba produktów dodatkowe kolumny będą puste, a więc część miejsca zostanie zmarnowana. Najpoważniejszą wadą tego projektu jest to, 11
że utrudnia on wykonywanie wielu zadań, na przykład sortowanie lub indeksowanie tabeli według nazwy bądź identyfikatora produktu. Po znalezieniu powtarzających się grup należy zawsze dokładnie przeanalizować projekt i rozważyć rozdzielenie tabeli na dwie. W powyższym przykładzie najlepiej utworzyć dwie tabele jedną dla dostawców i jedną dla produktów połączone identyfikatorem dostawcy. Stosowanie reguł normalizacji Następny krok w procesie projektowania to zastosowanie reguł normalizacji danych (czasami nazywanych po prostu regułami normalizacji). Reguł tych używa się po to, aby sprawdzić, czy tabele mają prawidłową strukturę. Proces stosowania tych reguł wobec projektu bazy danych nazywa się normalizowaniem bazy danych lub po prostu normalizacją. Normalizacja jest najskuteczniejsza wtedy, kiedy wszystkie elementy informacji są już reprezentowane i utworzono wstępny projekt. Normalizacja pomaga zapewnić, że informacje zostały podzielone na właściwe tabele. Nie może natomiast zapewnić, że w projekcie zawarto wszystkie prawidłowe dane. Reguły są stosowane po kolei, co gwarantuje, że po każdym etapie projekt spełnia założenia określane jako formy normalne. Powszechnie jest akceptowanych pięć form normalnych od pierwszej formy normalnej do piątej formy normalnej. W tym artykule omówiono pierwsze trzy z tych form, ponieważ są one wystarczające w przypadku większości projektów baz danych. PIERWSZA FORMA NORMALNA Pierwsza forma normalna określa, że w miejscu każdego przecięcia wiersza i kolumny w tabeli istnieje jedna wartość, a nigdy lista wartości. Nie może na przykład istnieć pole o nazwie Cena, w którym umieszcza się więcej niż jedną cenę. Jeśli można sobie wyobrazić każde przecięcie wiersza i kolumny jako komórkę, to w każdej komórce jest tylko jedna wartość. DRUGA FORMA NORMALNA Druga forma normalna wymaga, aby każda kolumna niebędąca kluczem była całkowicie zależna od całego klucza podstawowego, a nie tylko od części tego klucza. Reguła ta ma zastosowanie wtedy, gdy klucz podstawowy składa się z więcej niż jednej kolumny. Załóżmy na przykład, że istnieje tabela zawierająca następujące kolumny, w której klucz podstawowy tworzą Identyfikator zamówienia i Identyfikator produktu: Identyfikator zamówienia (klucz podstawowy) Identyfikator produktu (klucz podstawowy) Nazwa produktu Ten projekt narusza drugą formę normalną, ponieważ kolumna Nazwa produktu jest zależna od kolumny Identyfikator produktu, ale nie jest zależna od kolumny Identyfikator zamówienia, a więc nie jest zależna od całego klucza podstawowego. Należy usunąć z tej tabeli kolumnę Nazwa produktu. Powinna ona się znaleźć w innej tabeli (Produkty). TRZECIA FORMA NORMALNA Trzecia forma normalna wymaga nie tylko tego, by każda kolumna niebędąca kluczem była zależna od całego klucza podstawowego, lecz także tego, by wszystkie kolumny niebędące kluczem były niezależne od siebie nawzajem. Innymi słowy, każda kolumna niebędąca kluczem musi być zależna od klucza podstawowego i tylko od niego. Załóżmy, że istnieje tabela zawierająca następujące kolumny: IDproduktu (klucz podstawowy) Nazwa SCD Rabat 12
Załóżmy, że kolumna Rabat zależy od sugerowanej ceny detalicznej (SCD). Ta tabela narusza trzecią formę normalną, ponieważ kolumna niebędąca kluczem (Rabat) zależy od innej kolumny niebędącej kluczem (SCD). Niezależność kolumn oznacza, że można zmienić dowolną kolumnę niebędącą kluczem i nie ma to wpływu na żadną inną kolumnę. Zmiana wartości w polu SCD spowoduje odpowiednią zmianę w kolumnie Rabat, co jest naruszeniem reguły. W tym przypadku kolumnę Rabat należy przenieść do innej tabeli, której kluczem jest kolumna SCD. Więcej informacji Aby uzyskać więcej informacji na temat podstaw projektowania tabel, zobacz artykuł Tworzenie tabel w bazie danych. Więcej informacji o projektowaniu baz danych można znaleźć w następujących książkach: Michael J. Hernandez. Bazy danych dla zwykłych śmiertelników Mikom Warszawa listopad 2000, wydanie II Robert J. Muller, Bazy danych, język UML w modelowaniu danych, Mikom, Warszawa luty 2000 Candace C. Fleming, Barbara von Halle. Handbook of Relational Database Design. Addison-Wesley Professional. 1989. Rebecca M. Riordan. Designing Effective Database Systems. Addison-Wesley Professional. 2005. 13