Klip wideo: wprowadzenie do baz danych

Aby projekt był konkretny, streść przeznaczenie bazy danych i często odwołuj się do tego streszczenia. Jeśli chcesz opracować małą bazę danych dla firmy domowej, możesz opisać ją w prosty sposób, na przykład: „Baza danych klientów firmy zawierająca listę informacji o klientach na potrzeby wysyłania korespondencji i raportowania”. W przypadku bazy danych dla przedsiębiorstwa opis przypadków i sposobów użycia bazy danych oraz przechowywanych w niej informacji przez osoby pełniące różne funkcje może zająć kilka akapitów. Opracuj konkretne, szczegółowe informacje o misji, do których będziesz się odwoływać w trakcie procesu projektowania.

Rozpocznij przy użyciu istniejących informacji i metod śledzenia. Na przykład być może zapisujesz obecnie zamówienia zakupu w księdze głównej bądź przechowujesz informacje o klientach za pomocą papierowych formularzy. Na podstawie tych źródeł sporządź listę obecnie rejestrowanych informacji (na przykład ze wszystkich pól formularzy). W przypadku gdy obecnie nie rejestrujesz ważnych informacji, pomyśl o tym, jakie konkretne informacje będą potrzebne. Każdy poszczególny typ danych będzie osobnym polem w bazie danych.

Nie martw się, jeśli Twoja lista nie będzie perfekcyjna za pierwszym razem — możesz ją dopracować z czasem. Weź jednak pod uwagę wszystkie osoby korzystające z tych informacji i poproś je o podzielenie się własnymi pomysłami.

Następnie zastanów się nad tym, co chcesz uzyskać przy użyciu bazy danych, i nad rodzajami raportów bądź korespondencji, które chcesz generować. W dalszej kolejności upewnij się, że zapisujesz odpowiednie informacje do spełnienia tych celów. Na przykład jeśli chcesz, aby raport przedstawiał sprzedaż według regionów, musisz przechwycić dane sprzedaży na poziomie regionalnym. Spróbuj naszkicować pożądany raport zawierający rzeczywiste informacje. Następnie sporządź listę danych potrzebnych do utworzenia tego raportu. Wykonaj te same kroki w przypadku korespondencji i innych wyjściowych form informacji, jakie chcesz uzyskać na podstawie bazy danych.

Przykład

Załóżmy, że klienci mają możliwość skorzystania (bądź rezygnacji) z okresowych wiadomości e-mail o aktualizacjach i chcesz uzyskać listę osób, które wyraziły chęć ich otrzymywania. W tabeli Klienci będziesz potrzebować kolumny Przesyłanie wiadomości e-mail z dopuszczalnymi wartościami Tak i Nie.

Osoby chcące otrzymywać wiadomości e-mail potrzebują adresu e-mail, który również wymaga pola. Jeśli chcesz dołączyć właściwy zwrot grzecznościowy (na przykład Pan, Pani lub Pani), uwzględnij pole Zwrot grzecznościowy. Jeśli chcesz zwrócić się do klientów przy użyciu ich imion w wiadomościach e-mail, dodaj pole Imię.

Po utworzeniu listy wymaganych informacji określ główne jednostki (tematy) potrzebne do uporządkowania danych. Unikaj zduplikowanych danych w różnych jednostkach. Na przykład wstępna lista na potrzeby bazy danych sprzedaży produktów może wyglądać następująco:

Główne jednostki to: klienci, dostawcy, produkty i zamówienia. Rozpocznij zatem od tych czterech tabel: jednej zawierające informacje o klientach, jednej z informacjami o dostawcach itd. Możliwe, że ostateczny projekt bazy będzie się różnił, ale jest to dobry punkt wyjścia.

Aby zrozumieć, dlaczego lepiej jest mieć więcej tabel niż mniej, przyjrzyj się poniższej tabeli:

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. Zamiast tego zarejestruj informacje o dostawcy tylko raz w osobnej tabeli Dostawcy, a następnie połącz tę tabelę z tabelą Produkty.

Kolejny problem z tak zaprojektowaną bazą wychodzi na jaw wtedy, gdy potrzebujemy zmodyfikować informacje o dostawcy. Załóżmy, że musisz 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 ten problem.

Na koniec załóżmy, że od dostawcy Coho Winery pochodzi tylko jeden produkt i chcesz go usunąć bez kasowania informacji o nazwie i adresie dostawcy. Jak można byłoby usunąć rekord produktu bez utraty danych dostawcy w tak zaprojektowanej bazie? Byłoby to niemożliwe. Każdy rekord oprócz informacji o produkcie zawiera również dane dostawcy — nie da się zatem usunąć jednej informacji bez kasowania drugiej. Aby rozdzielić te dane, podziel tę tabelę na dwie: pierwszą z informacjami o produkcie, a drugą z informacjami o dostawcy. Wówczas skasowanie rekordu produktu spowoduje jedynie usunięcie danych na temat tego produktu, a nie danych dotyczących dostawcy.

Po wybraniu tematu tabeli bazy danych kolumny w tej tabeli powinny zawierać jedynie informacje dotyczące tego jednego tematu. Na przykład w tabeli Produkty powinny być przechowywane dane wyłącznie na temat tych produktów, nie na temat ich dostawców.

Aby zdecydować, jakie informacje mają być śledzone w tabeli, użyj sporządzonej wcześniej listy. Na przykład tabela Klienci może zawierać następujące dane: Imię, Nazwisko, Adres, Przesyłanie wiadomości e-mail, Zwrot grzecznościowy i Adres e-mail. Każdy rekord (klient) w tabeli zawiera ten sam zestaw kolumn, zatem dla każdego klienta przechowywane są te same informacje.

Sporządź swoją pierwszą listę, a następnie przejrzyj ją i dopracuj. Pamiętaj, aby podzielić informacje na najmniejsze możliwe pola. Na przykład jeśli wstępna lista zawiera pole Adres, rozbij je na pola Ulica, Miasto, Województwo i Kod pocztowy — a nawet na więcej pól w przypadku klientów globalnych. Dzięki temu można przygotować korespondencję w odpowiednim formacie lub raportować informacje dotyczące zamówień według województwa.

Po dopracowaniu kolumn z danymi we wszystkich tabelach pora wybrać klucz podstawowy każdej tabeli.

Każdy wiersz w każdej tabeli musi być identyfikowany w jednoznaczny sposób. Pamiętasz wcześniejszy przykład, w którym dwóch klientów miało takie samo imię i nazwisko? Klienci nazywają się tak samo, dlatego potrzeba sposobu na identyfikację każdego z nich.

Każda tabela powinna zatem zawierać kolumnę (bądź zestaw kolumn), która jednoznacznie identyfikuje każdy wiersz. Jest to klucz podstawowy, często będący unikatowym numerem — na przykład numerem identyfikacyjnym pracownika lub liczbą kolejną. Program Access używa kluczy podstawowych do szybkiego skojarzenia danych z wielu tabel i ich zbiorczego przedstawienia.

Czasami klucz podstawowy składa się z dwóch lub większej liczby pól. 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.

Jeśli masz już unikatowy identyfikator dla informacji w tabeli, na przykład numery produktów, które jednoznacznie identyfikują każdy produkt w katalogu, użyj go, ale tylko jeśli jego wartości spełniają poniższe zasady dotyczące kluczy podstawowych:

• Identyfikator dla każdego rekordu zawsze będzie inny. W kluczu podstawowym nie są dozwolone zduplikowane wartości.

• Każdy element ma przypisaną wartość. Każdy rekord w tabeli musi mieć klucz podstawowy. Jeśli do utworzenia klucza używasz kilku kolumn (takich jak Kategoria części i Numer części), wszystkie wartości muszą zawsze istnieć.

• Klucz podstawowy to wartość, która się nie zmienia. Do kluczy odwołują się inne tabele, dlatego dowolna zmiana klucza podstawowego w jednej tabeli oznacza zmianę we wszystkich miejscach, w których występują do niego odwołania. Częste zmiany zwiększają ryzyko wystąpienia błędów.

Jeśli nie masz oczywistego identyfikatora, jako klucza podstawowego użyj dowolnego, unikatowego numeru. Na przykład możesz przypisać poszczególnym zamówieniom unikatowy numer zamówienia wyłącznie w celu identyfikacji zamówienia.