Modelowanie danych: Projektowanie struktury danych
Jeśli dane zostaną zaprzechowywane lub wyświetlone wraz z Twoją aplikacją, jego ważną częścią jest struktura danych. Zastanów się nie tylko, w jaki sposób dane będą wykorzystywane w jednej konkretnej aplikacji lub ekranie, ale w jaki sposób inni będą z nich korzystać. Odwołanie się do twoich osobowości, zadań, procesów biznesowych i celów pomoże ci określić, jakie dane przechowywać i jak je uporządkować.
Porada
Mimo że został napisany dla bazy danych Access, w tym artykule o podstawach projektowania danych dobrze omówiono zasady modelowania danych: podstawowe informacje o projektowaniu bazy danych.
Jako przykład weźmy następujący raport z wydatków.
Jest widoczna główna część raportu o wydatkach zawierająca informacje o nazwisku pracownika i dziale. Poniżej głównej części znajduje się wiele wierszy opisów dla każdego zakupionego przedmiotu. Nazwijmy te elementy zamówienia. Elementy zamówienia mają inną strukturę niż główna część raportu z wydatków. Możemy więc powiedzieć, że dla każdego raportu wydatków istnieje kilka pozycji.
Aby umieścić ten rodzaj danych w bazie danych, musimy modelować strukturę danych w projekcie bazy danych.
Struktura danych typu jeden-do-wielu (1:N)
Jest to typ struktury danych opisany w poprzednim przykładzie. Główna część raportu z wydatków jest powiązana z kilkoma elementami zamówienia. (Relację można również zobaczyć z perspektywy elementów zamówienia: wiele elementów zamówienia do jednego raportu z wydatków (N:1)).
Struktura danych typu wiele-do-wielu (N:N)
Struktura danych od wielu do wielu jest szczególnym typem. W tym przypadku wiele rekordów może być skojarzonych z wieloma zestawami innych rekordów. Dobrym przykładem jest sieć partnerów biznesowych. Użytkownik korzysta z wielu partnerów biznesowych (klientów i dostawców), z którymi pracuje użytkownik, oraz tych partnerów biznesowych mogą również współpracować z wieloma współpracownikami.
Przykłady modelowania danych
Istnieje szereg typów modelowania, które mogą nastąpić w systemie. Rozważmy kilka przykładów.
Przykład 1: żądanie zatwierdzenia czasu wolnego
W prostym przykładzie przedstawiono dwa zestawy danych. Jeden to pracownik, drugi jest żądaniem czasu wolnego. Ponieważ każdy pracownik prześle wiele wniosków, relacja jest tutaj jeden do wielu, gdzie „jeden” to pracownik, a „wielu” to żądania. Dane pracownika i dane żądania przerwy są powiązane ze sobą, ponieważ numer pracownika jest wspólnym polem (nazywanym również kluczem).
Przykład 2: zatwierdzenie zakupu
Tutaj struktura danych wygląda na dość skomplikowaną, ale jest bardzo podobna do przykładu raportu z wydatków omówionego na początku tego artykułu. Każdy sprzedawca lub dostawca jest powiązany z wieloma zamówieniami zakupu. Każdy pracownik odpowiada za wiele zamówień zakupu. Dlatego oba te zestawy danych mają strukturę danych jeden do wielu.
Ponieważ pracownicy nie zawsze używają tego samego dostawcy lub dostawcy, dostawcy są wykorzystywani przez wielu pracowników, a każdy pracownik współpracuje z wieloma dostawcami. Z tego powodu relacje między pracownikami i dostawcami to wiele-do-wielu.
Przykład 3: raportowanie wydatków
Uwaga
Czy możesz poinformować nas o preferencjach dotyczących języka dokumentacji? Wypełnij krótką ankietę. (zauważ, że ta ankieta jest po angielsku)
Ankieta zajmie około siedmiu minut. Nie są zbierane żadne dane osobowe (oświadczenie o ochronie prywatności).