Prawidłowo zaprojektowana baza danych zapewnia dostęp do aktualnych i dokładnych informacji. Ponieważ poprawny projekt jest niezbędny do osiągnięcia założonych celów podczas pracy z bazą danych, warto poświęcić czas na poznanie zasad dobrego projektowania. W ostatecznym rozrachunku istnieje znacznie większe prawdopodobieństwo, że otrzymasz bazę danych, która spełni Twoje potrzeby i będzie w stanie łatwo dostosować się do zmian.
Ten artykuł zawiera wskazówki dotyczące planowania bazy danych dla komputerów stacjonarnych. Dowiesz się, jak zdecydować, jakich informacji potrzebujesz, jak podzielić te informacje na odpowiednie tabele i kolumny oraz jakie relacje między nimi są ze sobą. Przeczytaj ten artykuł przed utworzeniem pierwszej bazy danych dla komputerów stacjonarnych.
W tym artykule
- Niektóre terminy związane z bazami danych, które warto znać
- Czym cechuje się dobry projekt bazy danych?
- Proces projektowania
- Określanie przeznaczenia bazy danych
- Znajdowanie i organizowanie potrzebnych informacji
- Dzielenie informacji na tabele
- Przekształcanie elementów informacji w kolumny
- Określanie kluczy podstawowych
- Tworzenie relacji pomiędzy tabelami
- Dopracowywanie projektu
- Stosowanie reguł normalizacji
Niektóre terminy związane z bazami danych, które warto znać
Program Access organizuje informacje w tabelach. Są to listy wierszy i kolumn przypominające arkusz kalkulacyjny. W prostej bazie danych może istnieć tylko jedna tabela. W przypadku większości baz danych będzie potrzebna więcej niż jedna. Na przykład można utworzyć tabelę przechowującą informacje o produktach, inną tabelę przechowującą informacje o zamówieniach i jeszcze inną tabelę zawierającą informacje o klientach.
Każdy wiersz jest poprawniej nazywany rekordem, a każda kolumna polem. Rekord to znaczący i spójny sposób łączenia informacji na określony temat. Pole to pojedynczy element informacji — typ elementu, który występuje w każdym rekordzie. Na przykład w tabeli Produkty każdy wiersz, czyli rekord, zawiera informacje dotyczące jednego produktu. Każda kolumna, czyli pole, zawiera określony rodzaj informacji na temat tego produktu, na przykład jego nazwę lub cenę.
Czym cechuje się dobry projekt bazy danych?
Przy projektowaniu bazy danych obowiązują pewne zasady. Pierwsza zasada jest taka, że zduplikowane informacje (nazywane również nadmiarowymi danymi) są złe, ponieważ marnują miejsce i zwiększają prawdopodobieństwo wystąpienia błędów i niespójności. Drugą zasadą jest to, że ważna jest poprawność i kompletność informacji. Jeśli baza danych zawiera niepoprawne informacje, wszelkie raporty pobierające informacje z bazy danych również będą zawierały niepoprawne informacje. W rezultacie wszelkie podejmowane decyzje oparte na tych raportach będą wprowadzane w błąd.
Dlatego dobry projekt bazy danych to taki, który:
- Dzieli informacje na tabele tematyczne, aby ograniczyć nadmiar danych.
- Zapewnia programowi Access informacje wymagane do połączenia informacji w tabelach stosownie do potrzeb.
- Pomaga wspierać oraz zapewniać dokładność oraz integralność Twoich informacji.
- Dostosowuje się do Twoich potrzeb w zakresie przetwarzania danych i raportowania.
Proces projektowania
Proces projektowania składa się z następujących kroków:
-
Określanie przeznaczenia bazy danych
Ułatwi to przygotowanie pozostałych kroków. -
Wyszukiwanie i organizowanie potrzebnych informacji
Zgromadź wszystkie rodzaje informacji, które możesz chcieć zarejestrować w bazie danych, takie jak nazwa produktu i numer zamówienia. -
Podziel informacje na tabele
Podziel informacje na główne jednostki lub tematy, takie jak Produkty lub Zamówienia. Każdy temat staje się tabelą. -
Przekształcanie elementów informacji w kolumny
Zdecyduj, jakie informacje mają być przechowywane w każdej tabeli. Każdy element staje się polem i jest wyświetlany jako kolumna w tabeli. Na przykład tabela Pracownicy może zawierać pola, takie jak Nazwisko i Data zatrudnienia. -
Określanie kluczy podstawowych
Wybierz klucz podstawowy dla każdej tabeli. Klucz podstawowy to kolumna służąca do unikatowego identyfikowania każdego wiersza. Przykładami mogą być identyfikator produktu lub identyfikator zamówienia. -
Konfigurowanie relacji pomiędzy tabelami
Przyjrzyj się każdej tabeli i zdecyduj, jakie relacje mają dane w jednej tabeli z danymi w innych tabelach. W razie potrzeby można dodawać pola do tabel lub tworzyć nowe tabele, aby objaśnić relacje. -
Dopracowywanie projektu
Przeanalizuj projekt pod kątem błędów. Utwórz tabele i dodaj kilka rekordów danych przykładowych. Sprawdź, czy możesz uzyskać żądane wyniki z tabel. W razie potrzeby wprowadź poprawki do projektu. -
Stosowanie reguł normalizacji
Zastosuj reguły normalizacji danych, aby sprawdzić, czy struktura tabel jest poprawna. W razie potrzeby dostosuj tabele.
Określanie przeznaczenia bazy danych
Dobrym pomysłem jest zapisanie przeznaczenia bazy danych na papierze — jej przeznaczenia, przewidywanego sposobu używania i osoby, które będą z niej korzystać. Na przykład w przypadku małej bazy danych dla firmy domowej możesz napisać coś prostego, takiego jak "Baza danych klientów firmy zawierająca listę informacji o klientach na potrzeby wysyłania korespondencji i raportowania". Jeśli baza danych jest bardziej złożona lub jest używana przez wiele osób (co często ma miejsce w środowisku korporacyjnym), celem może być akapit lub więcej oraz powinien zawierać informacje o tym, kiedy i jak każda osoba będzie z niej korzystać. Chodzi o to, aby mieć dobrze rozwiniętą misję, do której można się odwoływać w całym procesie projektowania. Posiadanie takiego stwierdzenia pomaga skupić się na swoich celach podczas podejmowania decyzji.
Znajdowanie i organizowanie potrzebnych informacji
Aby znaleźć i uporządkować potrzebne informacje, zacznij od istniejących informacji. Można na przykład zapisywać zamówienia zakupu w księdze głównej bądź przechowywać informacje o klientach na papierowych formularzach w segregatorze. Zbierz te dokumenty i wypisz każdy typ wyświetlanych informacji (na przykład każde pole wypełniane w formularzu). Jeśli nie masz żadnych istniejących formularzy, zamiast tego wyobraź sobie, że musisz zaprojektować formularz rejestrujący informacje o klientach. Jakie informacje umieściłbyś w formularzu? Jakie pola wypełniania utworzyłbyś? Zidentyfikuj i wyświetl listę wszystkich tych elementów. Załóżmy na przykład, że obecnie lista klientów jest przechowywana na kartach indeksu. Analiza tych kart może okazać się, że każda z nich zawiera imię i nazwisko, adres, miasto, województwo, kod pocztowy i numer telefonu klienta. Każdy z tych elementów reprezentuje potencjalną kolumnę w tabeli.
Przygotowując tę listę, nie martw się, że na początku będzie idealna. Zamiast tego wypisz każdy element, który przychodzi Ci do głowy. Jeśli ktoś inny będzie korzystał z tej bazy danych, także poproś go o podzielenie się własnymi pomysłami. Tę listę możesz dostosować później.
Następnie zastanów się, jakiego rodzaju raporty i korespondencję możesz generować na podstawie bazy danych. Na przykład możesz chcieć, aby raport sprzedaży produktów przedstawiał sprzedaż według regionów lub raport podsumowania zapasów pokazujący poziomy zapasów produktów. Możesz także wygenerować listy seryjne do wysłania do klientów, które informują o wyprzedaży lub oferują premię. Zaprojektuj raport i wyobraź sobie, jak będzie wyglądał raport. Jakie informacje umieściłbyś w raporcie? Wymień poszczególne elementy. Zrób to samo w przypadku listu seryjnego i każdego innego raportu, który zamierzasz utworzyć.
Zastanowienie się nad tym, jakie raporty i korespondencję można utworzyć, ułatwia zidentyfikowanie elementów, które będą potrzebne w bazie danych. Załóżmy na przykład, że klienci mają możliwość skorzystania (bądź rezygnacji) z okresowych aktualizacji pocztą e-mail i chcesz wydrukować listę osób, które wyraziły chęć ich otrzymywania. Aby zarejestrować te informacje, należy dodać kolumnę "Wyślij wiadomość e-mail" do tabeli klientów. Dla każdego klienta można ustawić pole o wartości Tak lub Nie.
Wymóg wysyłania wiadomości e-mail do klientów sugeruje jeszcze jeden element do zarejestrowania. Gdy wiesz, że klient chce otrzymywać wiadomości e-mail, musisz również znać adres e-mail, na który te wiadomości będą wysyłane. Dlatego dla każdego klienta należy zapisać adres e-mail.
Sensowne jest skonstruowanie prototypu każdego raportu lub listy wyjściowej i zastanowienie się, jakie elementy będą potrzebne do utworzenia raportu. Na przykład podczas badania listu seryjnego może przyjść Ci do głowy kilka rzeczy. Jeśli chcesz dodać odpowiedni zwrot grzecznościowy — na przykład ciąg "Pan", "Pani" lub "Pani", który rozpoczyna powitanie, musisz utworzyć element zwrotu grzecznościowego. List można też zazwyczaj zaczynać od słów "Szanowny Panie Kowalski" zamiast "Szanowny Panie. Pan Sylwester Smith". Sugeruje to, że zazwyczaj należy przechowywać nazwisko oddzielnie od imienia.
Kluczową kwestią do zapamiętania jest to, że każdą informację należy podzielić na najmniejsze przydatne części. Aby nazwisko było łatwo dostępne, należy podzielić je na dwie części — Imię i Nazwisko. Aby na przykład posortować raport według nazwiska, warto osobno przechowywać nazwisko klienta. Ogólnie rzecz biorąc, aby sortować i wyszukiwać konkretny element informacji, wykonywać obliczenia lub raportować na jego podstawie, należy umieścić ten element w osobnym polu.
Zastanów się, na jakie pytania możesz uzyskać odpowiedź w bazie danych. Na przykład, ile transakcji sprzedaży polecanego produktu zamknięto w zeszłym miesiącu? Gdzie mieszkają Twoi najlepsi klienci ? Kto jest dostawcą Twojego najlepiej sprzedającego się produktu? Odświeżenie tych pytań pomoże Ci skupić się na dodatkowych elementach do nagrania.
Po zebraniu tych informacji możesz przejść do następnego kroku.
Dzielenie informacji na tabele
Aby podzielić informacje na tabele, wybierz główne encje, czyli tematy. Na przykład, po znalezieniu i uporządkowaniu informacji do bazy danych sprzedaży produktów, wstępna lista może wyglądać następująco:
Pokazane tutaj główne jednostki to produkty, dostawcy, klienci i zamówienia. Dlatego warto zacząć od tych czterech tabel: jednej zawierającej informacje o produktach, jednej z informacjami o dostawcach, jednej z informacjami o klientach i jednej z informacjami o zamówieniach. Chociaż nie kończy to listy, jest to dobry punkt wyjścia. Możesz uściślać tę listę, aż uzyskasz odpowiedni projekt.
Podczas pierwszego przeglądania wstępnej listy elementów może pojawić się pokusa, aby umieścić je wszystkie w jednej tabeli, zamiast czterech przedstawionych na powyższej ilustracji. Tutaj dowiesz się, dlaczego to zły pomysł. Zastanówmy się przez chwilę nad poniższą tabelą:
W takim przypadku każdy wiersz zawiera informacje dotyczące zarówno produktu, jak i jego dostawcy. Od tego samego dostawcy może pochodzić wiele produktów, dlatego nazwę i dane adresowe dostawcy trzeba powtórzyć wiele razy. To marnotrawstwo miejsca na dysku. Dużo lepszym rozwiązaniem jest zarejestrowanie informacji o dostawcy tylko raz w osobnej tabeli Dostawcy, a następnie połączenie tej tabeli z tabelą Produkty.
Kolejny problem z tak zaprojektowaną bazą pojawia się, gdy potrzebujemy zmodyfikować informacje o dostawcy. Załóżmy na przykład, że należy zmienić adres dostawcy. Występuje on w wielu miejscach, dlatego możesz przypadkowo zmienić adres w jednym miejscu, ale zapomnieć to zrobić w pozostałych. Zapisanie adresu dostawcy tylko w jednym miejscu rozwiązuje problem.
Podczas projektowania bazy danych zawsze staraj się zarejestrować każdy fakt tylko raz. Jeśli okaże się, że te same informacje powtarzają się w więcej niż jednym miejscu, na przykład w przypadku adresu określonego dostawcy, należy umieścić te informacje w osobnej tabeli.
Na koniec załóżmy, że od dostawcy Coho Winery pochodzi tylko jeden produkt i chcesz go usunąć, zachowując jednak informacje o nazwie i adresie dostawcy. Jak usunąć rekord produktu bez utraty jednocześnie informacji o dostawcy? Byłoby to niemożliwe. Każdy rekord zawiera zarówno dane produktu, jak i dostawcy, dlatego nie można usunąć jednego bez kasowania drugiego. Aby rozdzielić te dane, należy podzielić jedną tabelę na dwie: jedną tabelę zawierającą informacje o produkcie, a drugą zawierającą informacje o dostawcy. Skasowanie rekordu produktu powinno spowodować usunięcie tylko danych na temat produktu, a nie danych dostawcy.
Po wybraniu tematu reprezentowanego przez tabelę kolumny w tej tabeli powinny zawierać wyłącznie dane dotyczące tego tematu. Na przykład w tabeli Produkty powinny być przechowywane dane wyłącznie na temat produktów. Adres dostawcy zawiera informację o dostawcy, a nie informację o produkcie, dlatego powinien zostać umieszczony w tabeli Dostawcy.
Przekształcanie elementów informacji w kolumny
Aby określić kolumny w tabeli, zdecyduj, jakie informacje na temat zarejestrowany w tabeli chcesz śledzić. Na przykład tabela Klienci zawiera kolumny Nazwa, Adres, Miasto-Stan-Kod pocztowy, Wyślij wiadomość e-mail, Zwrot grzecznościowy i Adres e-mail. Każdy rekord w tabeli zawiera ten sam zestaw kolumn, dzięki czemu dla każdego rekordu można przechowywać informacje z pól Nazwa, Adres, Miasto-Stan-Kod pocztowy, Przesyłanie wiadomości e-mail, Zwrot grzecznościowy i Adres e-mail. Na przykład kolumna adresu zawiera adresy klientów. Każdy rekord zawiera dane dotyczące jednego klienta, a pole adresu zawiera adres tego klienta.
Po ustaleniu początkowego zestawu kolumn dla każdej tabeli można doprecyzować kolumny. Na przykład warto przechowywać nazwę klienta w dwóch osobnych kolumnach: Imię i Nazwisko, dzięki czemu będzie można sortować, wyszukiwać i indeksować tylko te kolumny. Podobnie adres składa się z pięciu oddzielnych składników: adresu, miasta, stanu, kodu pocztowego i kraju/regionu, i sensowne jest przechowywanie ich w osobnych kolumnach. Jeśli na przykład chcesz przeprowadzić wyszukiwanie, filtrowanie lub sortowanie według województwa, musisz przechowywać informacje o województwie w osobnej kolumnie.
Należy również rozważyć, czy w bazie danych będą przechowywane informacje pochodzące wyłącznie z kraju, czy również z zagranicy. Jeśli na przykład planujesz przechowywać adresy międzynarodowe, lepiej użyć kolumny Region zamiast Województwo, ponieważ taka kolumna może pomieścić zarówno krajowe województwa, jak i regiony innych krajów/regionów. Podobnie, Kod pocztowy ma więcej sensu niż Kod pocztowy, jeśli zamierzasz przechowywać adresy międzynarodowe.
Poniższa lista zawiera kilka porad dotyczących określania kolumn.
-
Nie uwzględniaj obliczonych danych
W większości przypadków nie należy przechowywać wyników obliczeń w tabelach. Zamiast tego możesz zlecić wykonanie obliczeń w programie Access, gdy zechcesz wyświetlić wyniki. Załóżmy na przykład, że istnieje raport Produkty na zamówienie, który wyświetla sumy częściowe jednostek zamówienia dla każdej kategorii produktów w bazie danych. W żadnej z tabel nie ma jednak kolumny sumy częściowej jednostek zamówienia. Zamiast tego tabela Produkty zawiera kolumnę Jednostki na zamówienie, w której są przechowywane jednostki zamówione 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 tabeli. -
Przechowywanie informacji w najmniejszych logicznych częściach
Może wydawać się kuszące, aby mieć jedno pole na pełne imiona i nazwiska lub na nazwy produktów wraz z opisami produktów. Jeśli w polu połączysz więcej niż jeden rodzaj informacji, trudno będzie później odtworzyć poszczególne fakty. Spróbuj podzielić informacje na części logiczne; Na przykład utwórz osobne pola dla imienia i nazwiska lub dla nazwy produktu, kategorii i opisu.
Po dopracowaniu kolumn danych we wszystkich tabelach można wybrać klucz podstawowy każdej tabeli.
Określanie kluczy podstawowych
Każda tabela powinna zawierać kolumnę lub zestaw kolumn, które jednoznacznie identyfikują każdy wiersz przechowywany w tabeli. Często jest to unikatowy numer identyfikacyjny, taki jak numer identyfikacyjny pracownika lub numer seryjny. W terminologii baz danych ta informacja jest nazywana kluczem podstawowym tabeli. Program Access używa pól kluczy podstawowych do szybkiego kojarzenia danych z wielu tabel i ich zbiorczego zestawiania.
Jeśli masz już unikatowy identyfikator tabeli, na przykład numer produktu, który jednoznacznie identyfikuje każdy produkt w katalogu, możesz użyć tego identyfikatora jako klucza podstawowego tabeli — ale tylko pod warunkiem, że wartości w tej kolumnie będą zawsze różne dla każdego rekordu. W kluczu podstawowym nie mogą występować zduplikowane wartości. Na przykład nie używaj imion i nazwisk jako kluczy podstawowych, ponieważ nazwy nie są unikatowe. Łatwo możesz mieć dwie osoby o tym samym imieniu i nazwisku w tej samej tabeli.
Klucz podstawowy musi zawsze mieć wartość. Jeśli wartość kolumny stanie się nieprzypisana lub nieznana (brak wartości) w pewnym momencie, nie będzie można jej użyć jako składnika w kluczu podstawowym.
Należy zawsze wybierać klucz podstawowy, którego wartość nie ulegnie zmianie. W bazie danych, która korzysta z więcej niż jednej tabeli, klucz podstawowy tabeli może służyć jako odwołanie w innych tabelach. Jeśli klucz podstawowy ulegnie zmianie, musi ona zostać zastosowana wszędzie tam, gdzie występują odwołania do klucza. Używanie klucza podstawowego, który się nie zmienia, zmniejsza ryzyko, że nie będzie on zsynchronizowany z innymi tabelami, które się do niego odwołują.
Często jako klucz podstawowy jest używany dowolny unikatowy numer. Na przykład możesz przypisać poszczególnym zamówieniom unikatowy numer zamówienia. Jedynym celem numeru zamówienia jest identyfikacja zamówienia. Po przypisaniu nic się nie zmienia.
Jeśli nie myślisz o kolumnie lub zestawie kolumn, które mogłyby być dobrym kluczem podstawowym, rozważ użycie kolumny o typie danych Autonumerowanie. W przypadku korzystania z typu danych Autonumerowanie program Access automatycznie przypisuje wartość. Taki identyfikator nie jest zgodny z faktami; Nie zawiera żadnych rzeczywistych informacji opisujących wiersz, który reprezentuje. Identyfikatory pozbawione faktów idealnie nadają się do użycia jako klucz podstawowy, ponieważ nie ulegają zmianie. Jest bardziej prawdopodobne, że klucz podstawowy zawierający fakty dotyczące wiersza — na przykład numer telefonu lub nazwa klienta — ulegnie zmianie, ponieważ same informacje źródłowe mogą ulec zmianie.
1. Kolumna o typie danych Autonumerowanie często stanowi odpowiedni klucz podstawowy. Nie ma dwóch takich samych identyfikatorów produktów.
W niektórych przypadkach może być konieczne użycie dwóch lub większej liczby pól, które razem tworzą klucz podstawowy tabeli. Na przykład tabela Szczegóły zamówienia przechowująca elementy wierszy zamówień używa jako klucza podstawowego dwóch pól: Identyfikator zamówienia i Identyfikator produktu. Klucz podstawowy składający się z więcej niż jednej kolumny nazywany jest również kluczem złożonym.
Na potrzeby bazy danych sprzedaży produktów można utworzyć kolumnę Autonumerowanie dla każdej tabeli, która będzie pełnić rolę klucza podstawowego: ProductID dla tabeli Products, OrderID dla tabeli Orders, CustomerID dla tabeli Customers i SupplierID dla tabeli Suppliers.
Tworzenie relacji pomiędzy tabelami
Po podzieleniu informacji na tabele potrzebny jest sposób ponownego zestawienia tych informacji w uporządkowany sposób. Na przykład poniższy formularz zawiera informacje z kilku tabel.
1. Informacje w tym formularzu pochodzą z tabeli Klienci...
2. ... tabeli Pracownicy...
3. ... tabeli Zamówienia...
4. ... Tabela Produkty...
5. ... i tabeli Szczegóły zamówień.
Access to system zarządzania relacyjnymi bazami danych. W relacyjnej bazie danych informacje dzieli się na osobne tabele tematyczne. Następnie przy użyciu relacji pomiędzy tabelami możesz zestawić informacje w odpowiednie miejsce.
Tworzenie relacji jeden-do-wielu
Rozważmy ten przykład: tabele Dostawcy i Produkty w bazie danych zamówień produktów. Dostawca może dostarczyć dowolną liczbę produktów. W związku z tym każdemu dostawcy reprezentowanemu w tabeli Dostawcy może odpowiadać wiele produktów reprezentowanych w tabeli Produkty. Dlatego relacja pomiędzy tabelą Dostawcy a tabelą Produkty to relacja jeden-do-wielu.
Aby w projekcie bazy danych utworzyć relację jeden-do-wielu, należy klucz podstawowy znajdujący się po stronie "jeden" relacji dodać jako dodatkową kolumnę lub kolumny do tabeli po stronie "wiele" tej relacji. W tym przykładzie należy dodać kolumnę Identyfikator dostawcy z tabeli Dostawcy do tabeli Produkty. Dzięki temu program Access będzie mógł za pomocą numeru identyfikacyjnego dostawcy z tabeli Produkty zlokalizować właściwego dostawcę dla każdego produktu.
Kolumna Identyfikator dostawcy w tabeli Produkty jest nazywana kluczem obcym. Klucz obcy jest kluczem podstawowym innej tabeli. Kolumna Identyfikator dostawcy w tabeli Produkty jest kluczem obcym, ponieważ jest jednocześnie kluczem podstawowym w tabeli Dostawcy.
Podstawą sprzęgania tabel pokrewnych jest utworzenie par kluczy podstawowych i kluczy obcych. Jeśli nie masz pewności, które tabele powinny mieć wspólną kolumnę, zidentyfikowanie relacji jeden-do-wielu gwarantuje, że dwie tabele, których to dotyczy, rzeczywiście będą wymagały kolumny współużytkowanej.
Tworzenie relacji wiele-do-wielu
Rozważmy przykład relacji 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. Każdemu rekordowi z tabeli Produkty może odpowiadać wiele rekordów z tabeli Zamówienia. Ten typ relacji jest nazywany relacją wiele-do-wielu, ponieważ dla każdego produktu może istnieć wiele zamówień; A na każde zamówienie może być wiele produktów. Należy zauważyć, że aby wykryć relacje wiele-do-wielu pomiędzy tabelami, trzeba się przyjrzeć obu stronom relacji.
Podmioty obu tabel — zamówienia i produkty — są połączone relacją wiele-do-wielu. To stanowi problem. Aby zrozumieć problem, wyobraź sobie, co by się stało, gdybyś spróbował utworzyć relację między dwiema tabelami przez dodanie pola Identyfikator produktu do tabeli Zamówienia. Aby mieć więcej niż jeden produkt w jednym zamówieniu, należy utworzyć więcej niż jeden rekord w tabeli Zamówienia na zamówienie. Informacje o zamówieniach będą się powtarzać w przypadku każdego wiersza odnoszącego się do jednego zamówienia, co spowoduje, że projekt będzie nieefektywny, co może prowadzić do nieprawidłowych danych. Ten sam problem wystąpi, jeśli umieścisz pole Identyfikator zamówienia w tabeli Produkty — będziesz mieć więcej niż jeden rekord w tabeli Produkty dla każdego produktu. Jak rozwiązać ten problem?
Odpowiedzią jest utworzenie trzeciej tabeli, często nazywanej tabelą skrzyżowań, która rozbija relację wiele-do-wielu na dwie relacje jeden-do-wielu. Do tej trzeciej tabeli wstawia się klucze podstawowe z obu pierwotnych tabel. Skutkiem tego trzecia tabela rejestruje każde wystąpienie relacji.
Każdy rekord w tabeli Szczegóły zamówienia odpowiada jednej pozycji zamówienia. Klucz podstawowy tabeli Szczegóły zamówień składa się z dwóch pól — kluczy obcych z tabel Zamówienia i Produkty. Samo pole Identyfikator zamówienia nie sprawdza się jako klucz podstawowy w tej tabeli, ponieważ jedno zamówienie może zawierać wiele pozycji. Pole Identyfikator zamówienia jest powtarzane dla każdej pozycji zamówienia, więc pole nie zawiera unikatowych wartości. Nie wystarczy też użyć samego pola Identyfikator produktu, ponieważ jeden produkt może się znaleźć w wielu różnych zamówieniach. Razem te dwa pola zawsze generują unikatową wartość dla każdego rekordu.
W bazie danych sprzedaży produktów tabele Zamówienia i Produkty nie są ze sobą bezpośrednio powiązane. Są one powiązane pośrednio za pośrednictwem tabeli Szczegóły zamówień. Relacja wiele-do-wielu między zamówieniami i produktami jest reprezentowana w bazie danych przy użyciu dwóch relacji jeden-do-wielu:
- Tabele Zamówienia i Szczegóły zamówień są powiązane relacją jeden-do-wielu. Każde zamówienie może mieć więcej niż jedną pozycję, ale każda pozycja jest połączona tylko z jednym zamówieniem.
- Tabele Produkty i Szczegóły zamówień mają relację jeden-do-wielu. Z każdym produktem może być powiązanych wiele pozycji, ale każda pozycja odwołuje się tylko do jednego produktu.
W tabeli Szczegóły zamówień można określić wszystkie produkty w danym zamówieniu. Możesz także określić wszystkie zamówienia na określony produkt.
Po uwzględnieniu tabeli Szczegóły zamówień lista tabel i pól może wyglądać mniej więcej tak:
Tworzenie relacji jeden-do-jednego
Innym typem relacji jest relacja jeden-do-jednego. Załóżmy na przykład, że musisz zarejestrować jakieś specjalne informacje uzupełniające o produktach, które będą rzadko potrzebne lub które dotyczą tylko kilku produktów. Ponieważ te informacje nie są często potrzebne, a przechowywanie ich w tabeli Produkty spowodowałoby powstanie pustego miejsca dla każdego produktu, którego nie dotyczą, należy umieścić je w osobnej tabeli. Podobnie jak w przypadku tabeli Produkty jako klucza podstawowego należy użyć pola IDProduktu. Relacja pomiędzy tą tabelą uzupełniającą a tabelą Produkty to relacja jeden-do-jednego. Dla każdego rekordu w tabeli Product (Produkt) istnieje jeden pasujący rekord w tabeli uzupełniającej. Określenie takiej relacji wymaga, aby w obu tabelach było używane wspólne pole.
Gdy w bazie danych zajdzie potrzeba utworzenia relacji jeden-do-jednego, należy rozważyć, czy informacje pochodzące z dwóch tabel nie mogą zostać umieszczone razem w jednej tabeli. Jeśli z jakiejś przyczyny tego nie chcesz tego robić, na przykład dlatego, że spowodowałoby to dużą ilość pustego miejsca, na poniższej liście przedstawiono sposób przedstawienia relacji w projekcie:
- Jeśli obie tabele mają ten sam temat, prawdopodobnie możesz skonfigurować relację, używając tego samego klucza podstawowego w obu tabelach.
- Jeśli obie tabele mają różne podmioty z różnymi kluczami podstawowymi, wybierz jedną z tabel (jedną z nich) i wstaw jej klucz podstawowy w drugiej tabeli jako klucz obcy.
Określenie relacji między tabelami pomaga upewnić się, że tabele i kolumny są właściwe. Jeśli istnieje relacja jeden-do-jednego lub jeden-do-wielu, używane tabele muszą mieć wspólną kolumnę lub kolumny. Jeśli istnieje relacja wiele-do-wielu, potrzebna jest trzecia tabela reprezentująca relację.
Dopracowywanie projektu
Po przygotowaniu potrzebnych tabel, pól i relacji należy utworzyć tabele i wypełnić je danymi przykładowymi, a następnie spróbować pracować z tymi informacjami: tworzyć zapytania, dodawać nowe rekordy itd. W ten sposób można na przykład zwrócić uwagę na potencjalne problemy — może się na przykład okazać, że trzeba dodać kolumnę, którą zapomniano wstawić na etapie projektowania, albo że wystąpi tabela, którą należy podzielić na dwie tabele w celu wyeliminowania duplikatów.
Sprawdź, czy możesz użyć bazy danych do uzyskania żądanych odpowiedzi. Utwórz wstępne wersje robocze formularzy i raportów i sprawdź, czy zawierają oczekiwane dane. Szukaj niepotrzebnych duplikatów danych, a jeśli je znajdziesz, zmień projekt, aby je wyeliminować.
Wypróbowując początkową bazę danych, prawdopodobnie zauważysz, że jest miejsce na ulepszenia. Oto kilka rzeczy, które należy sprawdzić:
- Czy nie zapomnieliście o jakichś kolumnach? Jeśli tak, to czy informacje powinny znajdować się w istniejących tabelach? Jeśli treść zawiera informacje na temat innego elementu, może być konieczne utworzenie kolejnej tabeli. Utwórz kolumnę dla wszystkich informacji, które chcesz śledzić. Jeśli informacji nie można obliczyć na podstawie innych kolumn, prawdopodobnie będzie potrzebna nowa kolumna.
- Czy jakieś kolumny są niepotrzebne, ponieważ można je obliczać na podstawie istniejących pól? Jeśli element informacji można obliczyć na podstawie innych istniejących kolumn — na przykład jest to cena z rabatem obliczona na podstawie ceny detalicznej — zwykle lepiej jest to zrobić i uniknąć tworzenia nowej kolumny.
- Czy wielokrotnie wprowadzasz zduplikowane informacje w jednej z tabel? Jeśli tak, prawdopodobnie trzeba będzie podzielić tabelę na dwie tabele mające relację jeden-do-wielu.
- Czy masz tabele z wieloma polami, ograniczoną liczbą rekordów i wieloma pustymi polami w poszczególnych rekordach? Jeśli tak, zastanów się, czy nie chcesz przeprojektować tabeli, tak aby zawierała mniej pól, a więcej rekordów.
- Czy każda informacja została podzielona na najmniejsze użyteczne części? Jeśli chcesz raportować, sortować, wyszukiwać lub obliczać dotyczące elementu informacji, umieść go w osobnej kolumnie.
- Czy każda kolumna zawiera fakty dotyczące tematu tabeli? Jeśli kolumna nie zawiera informacji o temacie tabeli, należy do innej tabeli.
- Czy wszystkie relacje między tabelami są reprezentowane przez pola wspólne, czy przez trzecią tabelę? Relacje jeden-do-jednego i jeden-do-wielu wymagają wspólnych kolumn. Relacje wiele-do-wielu wymagają trzeciej tabeli.
Uściślanie tabeli Produkty
Załóżmy, że każdy produkt w bazie danych sprzedaży produktów należy do kategorii ogólnej, takiej jak napoje, przyprawy lub owoce morza. Tabela Produkty może zawierać pole pokazujące kategorię każdego produktu.
Załóżmy, że po sprawdzeniu i dopracowaniu projektu bazy danych postanawiasz przechowywać opis kategorii wraz z jej nazwą. Jeśli dodasz pole Opis kategorii do tabeli Produkty, musisz powtórzyć każdy opis kategorii dla każdego produktu należącego do tej kategorii — nie jest to dobre rozwiązanie.
Lepszym rozwiązaniem jest nadanie kategorii osobnego tematu do śledzenia w bazie danych, z własną tabelą i kluczem podstawowym. Następnie możesz dodać klucz podstawowy z tabeli Kategorie do tabeli Produkty jako klucz obcy.
Tabele Kategorie i Produkty mają relację jeden-do-wielu: kategoria może zawierać więcej niż jeden produkt, ale produkt może należeć tylko do jednej kategorii.
Podczas przeglądania struktury tabel zwracaj uwagę na powtarzające się grupy. Rozważmy na przykład tabelę zawierającą następujące kolumny:
- Identyfikator produktu
- Name (Nazwa)
- ID produktu1
- Nazwa1
- ID produktu2
- Nazwa2
- ID produktu3
- Nazwa3
Tutaj każdy produkt jest powtarzającą się grupą kolumn, która różni się od pozostałych tylko dodaniem liczby na końcu nazwy kolumny. Gdy kolumny będą ponumerowane w ten sposób, warto wrócić do projektu.
Taki projekt ma kilka wad. Po pierwsze, zmusza do nałożenia górnego limitu na liczbę produktów. Po przekroczeniu tego limitu należy dodać nową grupę kolumn do struktury tabeli, co jest dużym zadaniem administracyjnym.
Innym problemem jest to, że ci dostawcy, którzy mają mniej niż maksymalną liczbę produktów, zmarnują trochę miejsca, ponieważ dodatkowe kolumny będą puste. Najpoważniejszą wadą takiego projektu jest to, że utrudnia on wykonanie wielu zadań, takich jak sortowanie lub indeksowanie tabeli według identyfikatora produktu lub nazwy.
Ilekroć zobaczysz powtarzające się grupy, przejrzyj uważnie projekt, mając na uwadze możliwość podzielenia tabeli na dwie części. W powyższym przykładzie lepiej użyć dwóch tabel, jednej dla dostawców, a drugiej dla produktów, połączonych identyfikatorem dostawcy.
Stosowanie reguł normalizacji
Reguły normalizacji danych (czasami nazywane po prostu regułami normalizacji) możesz zastosować jako następny krok w projektowaniu. Te reguły umożliwiają sprawdzenie, czy tabele mają poprawną strukturę. Proces stosowania reguł do projektu bazy danych nosi nazwę normalizowania bazy danych lub po prostu normalizowania.
Normalizacja jest najbardziej przydatna po przedstawieniu wszystkich elementów informacji i uzyskaniu wstępnego projektu. Chodzi o to, aby pomóc Ci upewnić się, że elementy informacji zostały podzielone na odpowiednie tabele. To, czego normalizacja nie może zrobić, to upewnić się, że masz wszystkie poprawne elementy danych.
Reguły stosuje się kolejno, na każdym etapie, upewniając się, że projekt osiąga jedną z tak zwanych "postaci normalnych". Pięć postaci normalnych jest powszechnie akceptowanych — od pierwszej postaci normalnej do piątej postaci normalnej. W tym artykule omówiono pierwsze trzy, ponieważ to wszystko, czego wymaga większość projektów baz danych.
Pierwsza postać normalna
Pierwsza postać normalna stwierdza, że na każdym przecięciu wierszy i kolumn w tabeli istnieje pojedyncza wartość, a nie lista wartości. Na przykład nie można mieć pola o nazwie Cena, w którym umieścisz więcej niż jedną wartość Cena. Każde przecięcie wierszy i kolumn można traktować jako komórkę, ale każda komórka może zawierać tylko jedną wartość.
Druga postać normalna
Druga postać normalna wymaga, aby każda kolumna niebędąca kluczem była w pełni zależna od całego klucza podstawowego, a nie tylko od jego części. Ta reguła ma zastosowanie, gdy masz klucz podstawowy składający się z więcej niż jednej kolumny. Załóżmy na przykład, że istnieje tabela zawierająca następujące kolumny, w których identyfikator zamówienia i identyfikator produktu tworzą klucz podstawowy:
- Identyfikator zamówienia (klucz podstawowy)
- Identyfikator produktu (klucz podstawowy)
- Nazwa produktu
Ten projekt narusza drugą postać normalną, ponieważ nazwa produktu jest zależna od identyfikatora produktu, ale nie od identyfikatora zamówienia, więc nie jest zależna od całego klucza podstawowego. Należy usunąć nazwę produktu z tej tabeli. Należy on do innej tabeli (Produkty).
Trzecia postać normalna
Trzecia postać normalna wymaga, aby nie tylko każda kolumna niebędąca kluczem była zależna od całego klucza podstawowego, ale także aby kolumny niebędące kluczem były od siebie niezależne.
Innymi słowy, każda kolumna niebędąca kluczem musi być zależna od klucza podstawowego i tylko od niego musi być kluczem podstawowym. Załóżmy na przykład, że istnieje tabela zawierająca następujące kolumny:
- ProductID (klucz podstawowy)
- Name (Nazwa)
- SRP (Sugerowana cena detal
- Rabat
Załóżmy, że rabat zależy od sugerowanej ceny detalicznej (SRP). Ta tabela narusza trzecią postać normalną, ponieważ kolumna niebędąca kluczem (Discount) jest zależna od innej kolumny niebędącej kluczem (SRP). Niezależność kolumn oznacza, że powinna być możliwość zmiany dowolnej kolumny niebędącej kluczem bez wpływu na inne kolumny. Zmiana wartości w polu SRP spowoduje odpowiednie zmiany rabatu, naruszając tym samym tę regułę. W takim przypadku pole Discount powinno zostać przeniesione do innej tabeli z kluczem SRP.