Prawidłowo zaprojektowana baza danych zapewnia dostęp do aktualnych i dokładnych informacji. Ponieważ prawidłowy projekt jest niezbędny do osiągnięcia celów w pracy z bazą danych, inwestowanie czasu wymaganego do poznania zasad dobrego projektowania ma sens. W końcu znacznie bardziej prawdopodobne jest, że będziesz mieć bazę danych, która spełnia Twoje potrzeby i może ł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 jak te tabele są ze sobą powiązane. Przed utworzeniem pierwszej bazy danych dla komputerów stacjonarnych należy przeczytać ten artykuł.
W tym artykule
Niektóre terminy bazy danych do poznania
Access organizuje informacje w tabelach: listy wierszy i kolumn przypominające klawiaturę księgowego lub arkusz kalkulacyjny. W prostej bazie danych może być tylko jedna tabela. W przypadku większości baz danych będziesz potrzebować więcej niż jednej bazy danych. Na przykład możesz mieć tabelę przechowującą informacje o produktach, inną tabelę przechowującą informacje o zamówieniach i inną tabelę z informacjami o klientach.
Każdy wiersz jest bardziej poprawnie nazywany rekordem, a każda kolumna — polem. Rekord to zrozumiały i spójny sposób łączenia informacji o czymś. Pole to pojedynczy element informacji — typ elementu, który pojawia się 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?
Niektóre zasady kierują procesem projektowania bazy danych. Pierwszą zasadą jest to, że zduplikowane informacje (nazywane także nadmiarowymi danymi) są złe, ponieważ marnują miejsce i zwiększają prawdopodobieństwo wystąpienia błędów i niespójności. Druga zasada polega na tym, że poprawność i kompletność informacji są ważne. Jeśli baza danych zawiera nieprawidłowe informacje, raporty pobierane z bazy danych również będą zawierać nieprawidłowe informacje. W wyniku tego wszelkie podejmowane przez Ciebie decyzje oparte na tych raportach zostaną wówczas źle poinformowanye.
Dobrym projektem bazy danych jest zatem taki, który:
-
Dzieli informacje na tabele tematyczne, aby ograniczyć nadmiarowe dane.
-
Zapewnia programowi Access informacje wymagane do połączenia informacji zawartych w tabelach w razie potrzeby.
-
Ułatwia obsługę i zapewnianie dokładności i integralności informacji.
-
Spełnia Twoje potrzeby związane z przetwarzaniem i raportowaniem danych.
Proces projektowania
Proces projektowania składa się z następujących kroków:
-
Określanie przeznaczenia bazy danych
Pomoże to przygotować Cię do wykonania pozostałych kroków.
-
Wyszukiwanie i organizowanie potrzebnych informacji
Zbierz wszystkie typy informacji, które możesz chcieć zarejestrować w bazie danych, takie jak nazwa produktu i numer zamówienia.
-
Dzielenie informacji na tabele
Podziel elementy informacji na główne jednostki lub tematy, takie jak Produkty lub Zamówienia. Każdy temat stanie 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 używana do unikatowej identyfikacji każdego wiersza. Przykładem może być Identyfikator produktu lub Identyfikator zamówienia.
-
Konfigurowanie relacji pomiędzy tabelami
Przyjrzyj się poszczególnym tabelom i zdecyduj, jak dane w jednej tabeli są powiązane z danymi w innych tabelach. Dodaj pola do tabel lub utwórz nowe tabele, aby w razie potrzeby wyjaśnić relacje.
-
Uściślanie projektu
Analizowanie projektu pod kątem błędów. Utwórz tabele i dodaj kilka rekordów przykładowych danych. Sprawdź, czy możesz uzyskać żądane wyniki z tabel. W razie potrzeby dostosuj projekt.
-
Stosowanie reguł normalizacji
Zastosuj reguły normalizacji danych, aby sprawdzić, czy tabele mają poprawną strukturę. W razie potrzeby dostosuj tabele.
Określanie przeznaczenia bazy danych
Warto zanotować przeznaczenie bazy danych na papierze — jej przeznaczenie, sposób, w jaki będziesz jej używać i kto będzie z niej korzystać. W przypadku małej bazy danych dla firm domowych można na przykład napisać coś prostego, na przykład "Baza danych klientów przechowuje listę informacji o klientach na potrzeby tworzenia korespondencji i raportów". Jeśli baza danych jest bardziej złożona lub jest używana przez wiele osób, tak jak to często bywa w przypadku ustawienia firmowego, celem może być łatwo akapit lub więcej i powinna zawierać informacje o tym, kiedy i jak każda osoba będzie korzystać z bazy danych. Chodzi o to, aby mieć dobrze rozwiniętą deklarację misji, o której można się odwoływać w całym procesie projektowania. Posiadanie takiego oświadczenia ułatwia skupienie się na celach podczas podejmowania decyzji.
Znajdowanie i organizowanie wymaganych informacji
Aby znaleźć i uporządkować wymagane informacje, zacznij od istniejących informacji. Możesz na przykład zarejestrować zamówienia zakupu w księdze głównej lub przechowywać informacje o klientach na papierowych formularzach w segregatonie. Zbierz te dokumenty i wyświetl listę poszczególnych typów informacji (na przykład każdego pola, które wypełniasz w formularzu). Jeśli nie masz żadnych istniejących formularzy, załóżmy, że musisz zaprojektować formularz w celu zarejestrowania informacji o klientach. Jakie informacje należy umieścić w formularzu? Jakie pola wypełniania zostałyby utworzone? Zidentyfikuj i wyświetl listę każdego z tych elementów. Załóżmy na przykład, że obecnie lista klientów jest zachowywana na kartach indeksu. Z analizy tych kart wynika, że każda karta zawiera imię i nazwisko, adres, miasto, województwo, kod pocztowy i numer telefonu. Każdy z tych elementów reprezentuje potencjalną kolumnę w tabeli.
Podczas przygotowywania tej listy nie martw się o to, aby na początku była idealna. Zamiast tego wylicz każdy element, który przychodzi ci do głowy. Jeśli inna osoba będzie korzystać z bazy danych, poproś o jej pomysły. Później możesz precyzyjnie dostosować listę.
Następnie rozważ typy raportów lub korespondencji, które możesz chcieć utworzyć z bazy danych. Na przykład możesz chcieć, aby raport sprzedaży produktu pokazywał sprzedaż według regionów lub raport podsumowania zapasów przedstawiający poziomy zapasów produktów. Możesz również wygenerować listy seryjne do wysłania do klientów, którzy ogłaszają wydarzenie sprzedaży lub oferują premię. Zaprojektuj raport i wyobraź sobie, jak będzie wyglądać. Jakie informacje umieścisz w raporcie? Wyświetl listę poszczególnych elementów. Wykonaj tę samą czynność dla listu seryjnego i każdego innego raportu, który przewidujesz.
Analizowanie raportów i korespondencji, które warto utworzyć, ułatwia identyfikowanie elementów, które będą potrzebne w bazie danych. Załóżmy na przykład, że dajesz klientom możliwość otrzymywania (lub wyłączania) okresowych aktualizacji poczty e-mail i chcesz wydrukować listę osób, które uczestniczą w programie. Aby zarejestrować te informacje, dodaj do tabeli klienta kolumnę "Wyślij wiadomość e-mail". Dla każdego klienta możesz ustawić dla tego pola wartość Tak lub Nie.
Wymóg wysyłania wiadomości e-mail do klientów sugeruje inny element do zarejestrowania. Gdy wiesz, że klient chce otrzymywać wiadomości e-mail, musisz również znać adres e-mail, na który ma zostać wysłany. Dlatego musisz zarejestrować adres e-mail dla każdego klienta.
Sensowne jest skonstruowanie prototypu każdego raportu lub pozycji wyjściowych i rozważenie, jakie elementy będą potrzebne do utworzenia raportu. Na przykład podczas sprawdzania listu seryjnego może się przydać kilka rzeczy. Jeśli chcesz dołączyć właściwe pozdrowienie — na przykład ciąg "Pan", "Pani" lub "Pani", który rozpoczyna pozdrowienie, musisz utworzyć zwrot grzecznościowy. Ponadto zazwyczaj możesz zacząć list od słów "Szanowny Panie Kowalskim", a nie "Drogi. Pan Sylvester Smith". Sugeruje to, że zazwyczaj chcesz przechowywać nazwisko oddzielone od imienia.
Najważniejsze jest, aby pamiętać, że należy podzielić poszczególne informacje na jego najmniejsze przydatne części. Aby w przypadku imienia i nazwiska było łatwo dostępne, podzielisz je na dwie części — Imię i Nazwisko. Na przykład aby posortować raport według nazwiska, warto oddzielnie przechowywać nazwisko klienta. Ogólnie rzecz biorąc, jeśli chcesz sortować, wyszukiwać, obliczać lub raportować na podstawie elementu informacji, należy umieścić ten element we własnym polu.
Zastanów się nad pytaniami, na które baza danych może udzielić odpowiedzi. Na przykład ile sprzedaży polecanego produktu zamkniesz w zeszłym miesiącu? Gdzie mieszkają Twoi najlepsi klienci ? Kto jest dostawcą Twojego najlepiej sprzedającego się produktu? Przewidywanie tych pytań ułatwia wprowadzanie dodatkowych elementów do zarejestrowania.
Po zebraniu tych informacji możesz przejść do następnego kroku.
Dzielenie informacji na tabele
Aby podzielić informacje na tabele, wybierz główne jednostki lub tematy. Na przykład po znalezieniu i zorganizowaniu informacji dotyczących bazy danych sprzedaży produktów wstępna lista może wyglądać następująco:
Główne jednostki pokazane tutaj to produkty, dostawcy, klienci i zamówienia. Dlatego warto zacząć od tych czterech tabel: jednej dla faktów o produktach, jednej dla faktów o dostawcach, jednej dla faktów o klientach i jednej dla faktów dotyczących zamówień. Mimo że lista nie została ukończona, jest to dobry punkt wyjścia. Możesz kontynuować uściślanie tej listy, dopóki nie uzyskasz projektu, który dobrze się sprawdzi.
Podczas pierwszego przeglądania wstępnej listy elementów może być kuszące umieszczenie ich wszystkich w jednej tabeli zamiast czterech przedstawionych na powyższej ilustracji. Dowiesz się tutaj, dlaczego jest to zły pomysł. Rozważmy na chwilę tabelę przedstawioną tutaj:
W tym przypadku każdy wiersz zawiera informacje zarówno o produkcie, jak i jego dostawcy. Ponieważ możesz mieć wiele produktów tego samego dostawcy, informacje o nazwie i adresie dostawcy muszą być powtarzane wiele razy. To marnotrawstwo miejsca na dysku. Znacznie lepszym rozwiązaniem jest zarejestrowanie informacji o dostawcy tylko raz w osobnej tabeli Dostawcy, a następnie połączenie tej tabeli z tabelą Produkty.
Drugi problem z tym projektem występuje, gdy trzeba 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 spróbuj zarejestrować każdy fakt tylko raz. Jeśli okaże się, że te same informacje są powtarzane w więcej niż jednym miejscu, na przykład w adresie określonego dostawcy, umieść te informacje w osobnej tabeli.
Na koniec załóżmy, że jest tylko jeden produkt dostarczony przez firmę Coho Winery i chcesz usunąć ten produkt, zachowując jednak informacje o nazwie i adresie dostawcy. Jak można usunąć rekord produktu bez utraty informacji o dostawcy? Byłoby to niemożliwe. Ponieważ każdy rekord zawiera fakty dotyczące produktu, a także fakty dotyczące dostawcy, nie można go usunąć bez usunięcia drugiego. Aby oddzielić te fakty, należy podzielić jedną tabelę na dwie: jedną tabelę zawierającą informacje o produkcie, a drugą tabelę zawierającą informacje o dostawcy. Usunięcie rekordu produktu powinno spowodować usunięcie tylko faktów dotyczących produktu, a nie faktów o dostawcy.
Po wybraniu tematu reprezentowanego przez tabelę kolumny w tej tabeli powinny zawierać tylko informacje dotyczące tematu. Na przykład w tabeli produktów powinny być przechowywane tylko informacje o produktach. Ponieważ adres dostawcy jest faktem o dostawcy, a nie faktem o produkcie, należy do tabeli dostawcy.
Przekształcanie elementów informacji w kolumny
Aby określić kolumny w tabeli, zdecyduj, jakie informacje należy śledzić na temat tematu zarejestrowanego w tabeli. Na przykład tabela Klienci, Nazwa, Adres, Miasto-Województwo-Zip, Wyślij wiadomość e-mail, Zwrot grzecznościowy i Adres e-mail zawierają dobrą listę początkowych kolumn. Każdy rekord w tabeli zawiera ten sam zestaw kolumn, dzięki czemu dla każdego rekordu można przechowywać informacje o nazwach, adresach, kodach miasto-województwo, wiadomości e-mail, zwrotach grzecznościowych i adresach 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 dodatkowo uściślić kolumny. Na przykład warto zapisać nazwę klienta jako dwie oddzielne kolumny: imię i nazwisko, aby można było sortować, wyszukiwać i indeksować tylko te kolumny. Podobnie adres w rzeczywistości składa się z pięciu osobnych elementów, adresu, miasta, województwa, kodu pocztowego oraz kraju/regionu, a także ma sens przechowywanie ich w osobnych kolumnach. Jeśli na przykład chcesz przeprowadzić wyszukiwanie, przefiltrować lub posortować dane według województwo, potrzebujesz informacji o stanie przechowywanych w osobnej kolumnie.
Należy również rozważyć, czy baza danych będzie zawierać informacje, które są pochodzenia krajowego, lub międzynarodowych, jak również. Jeśli na przykład planujesz przechowywanie adresów międzynarodowych, lepiej mieć kolumnę Region zamiast Województwo, ponieważ taka kolumna może pomieścić zarówno stany krajowe, jak i regiony innych krajów/regionów. Podobnie kod pocztowy ma większy sens niż kod pocztowy, jeśli zamierzasz przechowywać adresy międzynarodowe.
Na poniższej liście przedstawiono 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 program Access może wykonywać obliczenia, gdy chcesz wyświetlić wynik. Załóżmy na przykład, że istnieje raport Produkty w zamówieniu, który wyświetla sumę częściową jednostek zamówienia dla każdej kategorii produktu w bazie danych. W żadnej tabeli nie ma jednak kolumny Suma częściowa Jednostki przy zamówieniu. Zamiast tego tabela Produkty zawiera kolumnę Jednostki zamówienia, w których są przechowywane jednostki zamówienia dla każdego produktu. Korzystając z 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 być kuszące, aby mieć pojedyncze pole dla imion i nazwisk lub nazw produktów wraz z opisami produktów. Jeśli w polu zostaną połączone więcej niż jeden rodzaj informacji, późniejsze pobranie poszczególnych faktów będzie trudne. Spróbuj podzielić informacje na części logiczne; na przykład utwórz osobne pola dla imienia i nazwiska lub nazwy produktu, kategorii i opisu.
Po dopracowaniu kolumn danych w każdej tabeli możesz 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 bazy danych te informacje są nazywane kluczem podstawowym tabeli. Program Access używa pól klucza podstawowego do szybkiego kojarzenia danych z wielu tabel i ich 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 wtedy, gdy wartości w tej kolumnie zawsze będą inne dla każdego rekordu. W kluczu podstawowym nie można mieć zduplikowanych wartości. Na przykład nie używaj imion i nazwisk osób jako klucza podstawowego, ponieważ imiona i nazwiska nie są unikatowe. Możesz łatwo mieć dwie osoby o tej samej nazwie w tej samej tabeli.
Klucz podstawowy musi zawsze mieć wartość. Jeśli w pewnym momencie wartość kolumny może stać się nieprzypisane lub nieznane (brakujące wartości), nie można jej użyć jako składnika klucza podstawowego.
Zawsze należy wybrać klucz podstawowy, którego wartość się nie zmieni. W bazie danych używającej więcej niż jednej tabeli klucz podstawowy tabeli może być używany jako odwołanie w innych tabelach. Jeśli klucz podstawowy ulegnie zmianie, zmiana musi zostać również zastosowana wszędzie, gdzie znajduje się odwołanie do klucza. Użycie klucza podstawowego, który nie ulegnie zmianie, zmniejsza prawdopodobieństwo, że klucz podstawowy nie zostanie zsynchronizowany z innymi tabelami, które do niego odwołują się.
Często jako klucz podstawowy jest używany dowolny unikatowy numer. Na przykład możesz przypisać każdemu zamówieniu unikatowy numer zamówienia. Jedynym celem numeru zamówienia jest identyfikacja zamówienia. Po przypisaniu nigdy się nie zmienia.
Jeśli nie pamiętasz o kolumnie ani zestawie kolumn, które mogą stanowić dobry klucz podstawowy, rozważ użycie kolumny z typem danych Autonumerowanie. Gdy używasz typu danych Autonumerowanie, program Access automatycznie przypisuje ci wartość. Taki identyfikator jest bez faktów; nie zawiera żadnych rzeczywistych informacji opisujących reprezentowany wiersz. Identyfikatory bez faktów idealnie nadają się do użycia jako klucz podstawowy, ponieważ nie ulegają one zmianie. Klucz podstawowy zawierający fakty dotyczące wiersza — na przykład numer telefonu lub nazwisko klienta — może ulec zmianie, ponieważ informacje faktyczne mogą ulec zmianie.
1. Kolumna ustawiona na typ danych Autonumerowanie często tworzy dobry klucz podstawowy. Dwa identyfikatory produktów nie są takie same.
W niektórych przypadkach może być konieczne użycie dwóch lub większej liczby pól, które razem zapewniają klucz podstawowy tabeli. Na przykład w tabeli Szczegóły zamówień przechowującej elementy wierszy zamówień w kluczu podstawowym użyto dwóch kolumn: 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.
W przypadku bazy danych sprzedaży produktów możesz utworzyć kolumnę Autonumerowanie dla każdej z tabel, aby służyła jako klucz podstawowy: IdentyfikatorProduktu dla tabeli Produkty, IdentyfikatorZamówień dla tabeli Zamówienia, IdentyfikatorKlienta dla tabeli Klienci i ID_dostawcy dla tabeli Dostawcy.
Tworzenie relacji pomiędzy tabelami
Po podzieleniu informacji na tabele potrzebny jest sposób na ponowne zestawienie informacji w zrozumiały sposób. Na przykład poniższy formularz zawiera informacje z kilku tabel.
1. Informacje w tym formularzu pochodzą z tabeli Klienci...
2. ... tabela Pracownicy...
3. ... tabela Zamówienia...
4. ... tabela Produkty...
5. ... oraz tabelę Szczegóły zamówień.
Program Access to relacyjny system zarządzania bazami danych. W relacyjnej bazie danych informacje są podzielone na osobne tabele tematyczne. Następnie możesz użyć relacji pomiędzy tabelami, aby zebrać informacje w razie potrzeby.
Tworzenie relacji jeden-do-wielu
Rozważmy ten przykład: tabele Dostawcy i Produkty w bazie danych zamówień produktów. Dostawca może dostarczać dowolną liczbę produktów. Wynika z tego, że dla każdego dostawcy reprezentowanego w tabeli Dostawcy może istnieć wiele produktów reprezentowanych w tabeli Produkty. Dlatego relacja między tabelą Dostawcy a tabelą Produkty jest relacją jeden-do-wielu.
Aby przedstawić relację jeden-do-wielu w projekcie bazy danych, weź klucz podstawowy po stronie "jeden" relacji i dodaj go jako dodatkową kolumnę lub kolumny do tabeli po stronie "wiele" relacji. W takim przypadku można na przykład dodać kolumnę Identyfikator dostawcy z tabeli Dostawcy do tabeli Produkty. Następnie program Access może użyć numeru identyfikacyjnego dostawcy w tabeli Produkty, aby znaleźć odpowiedniego dostawcę dla każdego produktu.
Kolumna Identyfikator dostawcy w tabeli Produkty jest nazywana kluczem obcym. Klucz obcy to klucz podstawowy innej tabeli. Kolumna Identyfikator dostawcy w tabeli Produkty jest kluczem obcym, ponieważ jest również kluczem podstawowym w tabeli Dostawcy.
Podstawę łączenia tabel pokrewnych zapewnia się przez ustanowienie par kluczy podstawowych i kluczy obcych. Jeśli nie masz pewności, które tabele powinny współużytkować wspólną kolumnę, zidentyfikowanie relacji jeden-do-wielu gwarantuje, że te dwie tabele rzeczywiście będą wymagały udostępnionej kolumny.
Tworzenie relacji wiele-do-wielu
Rozważ relację mię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 dla każdego rekordu w tabeli Produkty może istnieć wiele rekordów w tabeli Zamówienia. Ten typ relacji jest nazywany relacją wiele-do-wielu, ponieważ dla każdego produktu może istnieć wiele zamówień. a w przypadku każdego zamówienia może istnieć wiele produktów. Należy pamiętać, że aby wykryć relacje wiele-do-wielu między tabelami, należy wziąć pod uwagę obie strony relacji.
Tematy z obu tabel — zamówień i produktów — mają relację wiele-do-wielu. Stanowi to problem. Aby zrozumieć ten problem, załóżmy, co by się stało, gdyby próbowano utworzyć relację między obiema tabelami, dodając pole Identyfikator produktu do tabeli Zamówienia. Aby mieć więcej niż jeden produkt na zamówienie, potrzebujesz więcej niż jednego rekordu w tabeli Zamówienia na zamówienie. Dla każdego wiersza, który odnosi się do pojedynczej kolejności, będą powtarzane informacje o kolejności, co skutkuje nieefektywnym projektem, który może prowadzić do niedokładnych danych. Ten sam problem występuje w przypadku umieszczenia pola Identyfikator zamówienia w tabeli Produkty — dla każdego produktu będziesz mieć więcej niż jeden rekord w tabeli Produkty. Jak rozwiązać ten problem?
Odpowiedzią jest utworzenie trzeciej tabeli, często nazywanej tabelą skrzyżowań, która dzieli relację wiele-do-wielu 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 lub wystąpienie relacji.
Każdy rekord w tabeli Szczegóły zamówień reprezentuje jeden element wiersza 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 użycie pola Identyfikator zamówienia nie działa jako klucz podstawowy tej tabeli, ponieważ jedno zamówienie może zawierać wiele elementów wierszy. Identyfikator zamówienia jest powtarzany dla każdego elementu wiersza zamówienia, więc pole nie zawiera unikatowych wartości. Używanie samego pola Identyfikator produktu również nie działa, ponieważ jeden produkt może być wyświetlany w wielu różnych zamówieniach. Jednak 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ą bezpośrednio ze sobą powiązane. Zamiast tego są one powiązane pośrednio za pośrednictwem tabeli Szczegóły zamówień. Relacja wiele-do-wielu między zamówieniami a produktami jest reprezentowana w bazie danych przy użyciu dwóch relacji jeden-do-wielu:
-
Tabele Zamówienia i Szczegóły zamówień mają relację jeden-do-wielu. Każde zamówienie może zawierać więcej niż jeden element wiersza, ale każdy element wiersza jest połączony tylko z jednym zamówieniem.
-
Tabela Produkty i tabela Szczegóły zamówień mają relację jeden-do-wielu. Z każdym produktem może być skojarzonych wiele pozycji, ale każdy element wiersza dotyczy tylko jednego produktu.
Na podstawie tabeli Szczegóły zamówień możesz określić wszystkie produkty z określonego zamówienia. Możesz również określić wszystkie zamówienia dla określonego produktu.
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 konieczne jest zarejestrowanie niektórych specjalnych informacji o produkcie dodatkowym, które będą potrzebne rzadko lub dotyczą tylko kilku produktów. Ponieważ często nie potrzebujesz tych informacji, a przechowywanie informacji w tabeli Produkty spowodowałoby puste miejsce dla każdego produktu, do którego nie mają zastosowania, należy umieścić je w osobnej tabeli. Podobnie jak w tabeli Produkty, jako klucza podstawowego używasz identyfikatora produktu. Relacja między tą tabelą uzupełniającą a tabelą Produkt jest relacją jeden-do-jednego. Dla każdego rekordu w tabeli Product istnieje jeden zgodny rekord w tabeli uzupełniającej. Określenie takiej relacji wymaga, aby w obu tabelach było używane wspólne pole.
Po wykryciu potrzeby relacji jeden-do-jednego w bazie danych zastanów się, czy można umieścić informacje z obu tabel w jednej tabeli. Jeśli nie chcesz tego robić z jakiegoś powodu, na przykład dlatego, że spowodowałoby to dużo pustego miejsca, na poniższej liście przedstawiono sposób reprezentowania relacji w projekcie:
-
Jeśli obie tabele mają ten sam temat, prawdopodobnie można skonfigurować relację, używając tego samego klucza podstawowego w obu tabelach.
-
Jeśli obie tabele mają różne tematy z różnymi kluczami podstawowymi, wybierz jedną z tabel (jedną) i wstaw klucz podstawowy do drugiej tabeli jako klucz obcy.
Określenie relacji między tabelami ułatwia upewnienie się, że są odpowiednie tabele i kolumny. Jeśli istnieje relacja jeden-do-jednego lub jeden-do-wielu, tabele muszą współużytkować wspólną kolumnę lub kolumny. Gdy istnieje relacja wiele-do-wielu, do reprezentowania relacji jest potrzebna trzecia tabela.
Uściślanie projektu
Po utworzeniu potrzebnych tabel, pól i relacji należy utworzyć i wypełnić tabele przykładowymi danymi, a następnie spróbować pracować z informacjami: tworzenie zapytań, dodawanie nowych rekordów itd. W ten sposób można wyróżnić potencjalne problemy — na przykład może być konieczne dodanie kolumny, której wstawianie zapomniano wstawić w fazie projektowania, lub tabelę, którą należy podzielić na dwie tabele, aby usunąć duplikaty.
Sprawdź, czy możesz skorzystać z bazy danych, aby uzyskać żądane odpowiedzi. Twórz przybliżone wersje robocze formularzy i raportów i sprawdzaj, czy zawierają oczekiwane dane. Poszukaj niepotrzebnego powielania danych i po znalezieniu jakichkolwiek danych zmień projekt, aby je wyeliminować.
Podczas wypróbowania początkowej bazy danych prawdopodobnie znajdziesz miejsce na ulepszenia. Oto kilka rzeczy, które należy sprawdzić:
-
Nie pamiętasz żadnych kolumn? Jeśli tak, czy informacje należą do istniejących tabel? Jeśli są to informacje o czymś innym, może być konieczne utworzenie kolejnej tabeli. Utwórz kolumnę dla każdego elementu informacji, który chcesz śledzić. Jeśli nie można obliczyć informacji z innych kolumn, prawdopodobnie będzie potrzebna nowa kolumna.
-
Czy kolumny są niepotrzebne, ponieważ można je obliczać na podstawie istniejących pól? Jeśli element informacyjny można obliczyć na podstawie innych istniejących kolumn — na przykład ceny z rabatem obliczonej 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 musisz podzielić tabelę na dwie tabele, które mają 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, rozważ przeprojektowanie tabeli, aby jej liczba była mniejsza i większa liczba rekordów.
-
Czy każdy element informacyjny został podzielony na najmniejsze przydatne części? Jeśli chcesz zgłosić, posortować, wyszukać lub obliczyć element informacji, umieść ten element we własnej kolumnie.
-
Czy każda kolumna zawiera informacje o temacie 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 zawierające kategorię każdego produktu.
Załóżmy, że po zbadaniu i uściślaniu projektu bazy danych należy zapisać opis kategorii wraz z jej nazwą. Jeśli dodasz pole Opis kategorii do tabeli Produkty, musisz powtórzyć opis każdej kategorii dla każdego produktu należącego do tej kategorii — nie jest to dobre rozwiązanie.
Lepszym rozwiązaniem jest nadanie kategoriom nowego tematu do śledzenia bazy danych z własną tabelą i własnym kluczem podstawowym. Klucz podstawowy można następnie dodać 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 struktur tabel należy zwracać uwagę na grupy powtarzające się. Rozważmy na przykład tabelę zawierającą następujące kolumny:
-
Identyfikator produktu
-
Name (Nazwa)
-
Identyfikator produktu1
-
Nazwa1
-
Identyfikator produktu2
-
Nazwa2
-
Identyfikator produktu3
-
Nazwa3
Tutaj każdy produkt jest powtarzającą się grupą kolumn, która różni się od pozostałych tylko przez dodanie liczby na końcu nazwy kolumny. Po wyświetleniu kolumn ponumerowanych w ten sposób należy ponownie wyświetlić projekt.
Taki projekt ma kilka wad. Na początek wymusza umieszczenie górnej granicy liczby produktów. Gdy tylko przekroczysz ten limit, musisz dodać nową grupę kolumn do struktury tabeli, co jest głównym zadaniem administracyjnym.
Innym problemem jest to, że dostawcy, którzy mają mniej niż maksymalna liczba produktów, zmarnują trochę miejsca, ponieważ dodatkowe kolumny będą puste. Najpoważniejszą wadą takiego projektu jest to, że utrudnia wykonywanie wielu zadań, takich jak sortowanie lub indeksowanie tabeli według identyfikatora produktu lub nazwy.
Za każdym razem, gdy zobaczysz grupy powtarzające się, dokładnie przeglądaj projekt, patrząc na podzielenie tabeli na dwie części. W powyższym przykładzie lepiej jest użyć dwóch tabel, jednej dla dostawców i jednej dla produktów, połączonej identyfikatorem dostawcy.
Stosowanie reguł normalizacji
W następnym kroku projektu możesz zastosować reguły normalizacji danych (czasami nazywane regułami normalizacji). Za pomocą tych reguł można sprawdzić, czy tabele mają poprawną strukturę. Proces stosowania reguł do projektu bazy danych jest nazywany normalizowaniem bazy danych lub po prostu normalizacją.
Normalizacja jest najbardziej przydatna po przedstawieniu wszystkich elementów informacji i opracowaniu wstępnego projektu. Chodzi o to, aby upewnić się, że elementy informacji zostały podzielone na odpowiednie tabele. Nie można wykonać normalizacji, aby upewnić się, że masz wszystkie prawidłowe elementy danych na początek.
Reguły stosuje się kolejno na każdym etapie, zapewniając, że projekt dotrze do jednego z tak zwanych "normalnych formularzy". Pięć normalnych form są powszechnie akceptowane - pierwsza normalna forma przez piątą normalną formę. Ten artykuł został rozszerzony o trzy pierwsze elementy, ponieważ są one wymagane w przypadku większości projektów baz danych.
Pierwsza normalna forma
Pierwsza normalna forma stanowi, że na każdym przecięciu wierszy i kolumn w tabeli istnieje jedna wartość i nigdy nie ma listy wartości. Nie można na przykład utworzyć pola o nazwie Cena, w którym jest umieszczana więcej niż jedna cena. Jeśli uważasz, że każde przecięcie wierszy i kolumn jest komórką, każda komórka może zawierać tylko jedną wartość.
Druga normalna forma
Druga normalna forma wymaga, aby każda kolumna nieklawiszowa była w pełni zależna od całego klucza podstawowego, a nie tylko od części klucza. Ta reguła ma zastosowanie, gdy klucz podstawowy składa się z więcej niż jednej kolumny. Załóżmy na przykład, że masz tabelę zawierającą następujące kolumny, w której kluczem podstawowym są identyfikator zamówienia i identyfikator produktu:
-
Identyfikator zamówienia (klucz podstawowy)
-
Identyfikator produktu (klucz podstawowy)
-
Nazwa produktu
Ten projekt narusza drugą normalną formę, ponieważ nazwa produktu zależy od identyfikatora produktu, ale nie od identyfikatora zamówienia, więc nie zależy od całego klucza podstawowego. Musisz usunąć nazwę produktu z tabeli. Należy ona do innej tabeli (Produkty).
Trzecia normalna forma
Trzecia normalna forma wymaga, aby nie tylko każda kolumna niekluczowa była zależna od całego klucza podstawowego, ale kolumny nieklawiszowe były niezależne od siebie.
Innym sposobem na powiedzenie tego jest to, że każda kolumna niekluczowa musi być zależna od klucza podstawowego i tylko od klucza podstawowego. Załóżmy na przykład, że masz tabelę zawierającą następujące kolumny:
-
ProductID (klucz podstawowy)
-
Name (Nazwa)
-
SRP
-
Rabat
Załóżmy, że rabat zależy od sugerowanej ceny detalicznej (SRP). Ta tabela narusza trzecią normalną formę, ponieważ kolumna niekluczowa Discount zależy od innej kolumny niekluczowej , SRP. Niezależność kolumn oznacza, że powinna być możliwość zmiany dowolnej kolumny innej niż kolumna klucza bez wpływu na inną kolumnę. Jeśli zmienisz wartość w polu SRP, rabat odpowiednio się zmieni, naruszając tę regułę. W tym przypadku discount należy przenieść do innej tabeli, która jest kluczem SRP.
