Typowe błędy w diagramie ER

Zapoznaj się ze schematem ER (ang. Entity Relationship), jego częściami i często występującymi problemami podczas jego tworzenia.

Czy kiedykolwiek stworzyłeś model relacyjnej bazy danych? A może próbujesz stworzyć swój pierwszy? Wiesz (lub wkrótce się dowiesz), że przełożenie rzeczywistych problemów na logikę bazy danych może być czasami dość trudne.

Jednym z narzędzi, które mogą Ci pomóc, jest diagram ER. Powszechna mądrość projektowania baz danych głosi, że im lepszy diagram ER, tym łatwiej będzie zbudować model bazy danych. Ten ważny element nadaje ton wszystkim przyszłym frustracjom lub sukcesom. Przy dobrym diagramie ER tworzenie relacyjnego modelu bazy danych jest dość proste. Oczywiście w każdej fazie modelowania bazy danych można popełnić błędy. Jednak posiadanie dobrego diagramu ER może pomóc w uniknięciu niektórych z tych błędów.

Zobaczmy więc, czym jest diagram ER i jak możemy uniknąć jego typowych błędów.

Co to jest diagram ER?

„Diagram ER” lub ERD jest skrótem od Diagramu relacji encji. Odwzorowuje problem do modelowania, ale w ustrukturyzowany sposób, który pokazuje relacje między podmiotami.

Bloki konstrukcyjne diagramu ER

Diagramy ER składają się z następujących elementów:

• Podmiot
• Związki
• Atrybuty encji lub relacji

Pierwszym elementem diagramu ER jest jednostka . Jednostka to obiekt lub zdarzenie, o którym chcemy przechowywać informacje. Zasadniczo jest to wszystko, o czym możemy zbierać dane. Na przykład możemy przechowywać dane dotyczące pracowników, uczniów, nauczycieli, kupujących, produktów, działów, płatności, lokalizacji itp.

Gdy już mamy podmioty, konieczne jest tworzenie relacji . Relacja pokazuje, w jaki sposób jedna jednostka jest połączona i skojarzona z jedną lub kilkoma innymi jednostkami.

Ostatnim elementem diagramu ER jest encja lub relacja atrybut . Atrybut to opis właściwości należącej do podmiotu lub relacji. Atrybuty mają wartości. Niektóre atrybuty podmiotów wymienionych powyżej mogą być:

• Pracownik, uczeń, nauczyciel, kupujący – dowód osobisty, imię, nazwisko, data urodzenia, adres itp.
• Produkt – ID, kategoria, opis, kolor, numer seryjny itp.
• Dział – ID, nazwa działu, kierownik działu, liczba pracowników itp.
• Płatności – ID, data i godzina, kwota.
• Lokalizacja – Miasto, kod pocztowy, region, kraj, kontynent.

Rodzaje relacji

Zanim przejdziemy do typowych błędów występujących na diagramach ER, ważne jest, aby zrozumieć możliwe typy relacji. Większość błędów ERD to zasadniczo błędnie zdefiniowane relacje między podmiotami.

Istnieją trzy rodzaje relacji między podmiotami:

• Jeden na jednego (1:1)
• Jeden do wielu (1:N)
• Wiele-do-wielu (M:N)

Relacje jeden-do-jednego (1:1)

Pierwszy typ relacji to jeden do jednego lub 1:1 . W tej relacji pojedyncza instancja jednej encji może być połączona tylko z pojedynczą instancją innej encji (i na odwrót, oczywiście).

Załóżmy, że mamy podmiot student z atrybutami nazwa i nazwisko . Mamy też podmiot id z jedynym atrybutem id . Relacja 1:1 oznaczałaby, że jeden uczeń może mieć tylko jeden numer identyfikacyjny. Oznacza to również, że jeden numer identyfikacyjny może należeć tylko do jednego ucznia.

Ta relacja jest bardzo rzadko spotykana w bazach danych. Jeśli tylko jeden identyfikator może być powiązany tylko z jednym uczniem, nie ma potrzeby rozdzielania ich na dwie różne jednostki.

Oto przykład tej relacji:

Relacje jeden-do-wielu (1:N)

Najpopularniejszym typem relacji bazy danych jest jeden-do-wielu lub 1:N . Relacja jeden-do-wielu oznacza, że ​​każde pojedyncze wystąpienie jednej encji może być połączone z wieloma wystąpieniami innej encji. Oznacza to również, że każde wystąpienie drugiej encji może być powiązane tylko z jednym wystąpieniem pierwszej encji.

Na przykład istnieje podmiot kupujący z atrybutami id , imię i nazwisko . Chcemy nawiązać relację z podmiotem płatność który ma atrybuty id , data i wartość . Jest to relacja 1:N, ponieważ jeden kupujący może dokonać jednej lub wielu płatności. Jednak jednej płatności nie może dokonać kilku kupujących; może go dokonać tylko jeden nabywca.

Oto przykład:

Na tę zależność można też spojrzeć na odwrót. W tej sytuacji nazywa się to wiele do jednego lub N:1 . Oczywiście nie jest to nowy rodzaj relacji. To to samo co 1:N, ale patrzy się na niego z przeciwnego kierunku.

Jako przykład załóżmy, że mamy podmiot pracownik z atrybutami id , imię i nazwisko . Chcemy założyć pracownika relacje z podmiotem departament który ma atrybuty id i imię . Związek między tymi dwoma podmiotami to N:1. Oznacza to, że każdy pracownik może pracować tylko w jednym dziale, ale w tym samym dziale może pracować wielu pracowników.

Relacje wiele-do-wielu (M:N)

Wiele do wielu lub M:N relacja oznacza, że ​​każde wystąpienie pierwszej encji może być powiązane z więcej niż jednym wystąpieniem drugiej encji. Oznacza to również, że każde wystąpienie drugiej encji może być powiązane z wieloma wystąpieniami pierwszej encji.

Zobaczmy, jak to działa między podmiotami student i wykład . Załóżmy, że uczeń ma atrybuty id , imię i nazwisko . Podmiot wykład ma atrybuty id i imię . Relację wiele-do-wielu można interpretować w następujący sposób:jeden student może uczestniczyć w jednym lub kilku wykładach, podczas gdy w jednym wykładzie może uczestniczyć jeden lub więcej studentów.

Oto diagram dla tego przykładu:

W modelowaniu baz danych takie relacje są zwykle dzielone na dwie lub więcej relacji 1:N lub N:1 przez wprowadzenie nowych encji.

Typowe błędy popełniane podczas tworzenia diagramu ER

Wiele błędów w diagramach ER pasuje do jednej z tych czterech kategorii:

• Nieprawidłowe relacje między podmiotami
• Korzystanie z instancji encji zamiast encji
• Mylenie atrybutu z bytem
• Atrybuty złożone

Przyjrzyjmy się każdemu z osobna.

Nieprawidłowe relacje między podmiotami

Najczęstsze błędy występują podczas definiowania relacji między podmiotami . W relacji 1:1 zazwyczaj nie ma błędów. Jednak bardzo łatwo jest pomylić relację 1:N z relacją M:N. Wynika to zwykle z niezrozumienia wymagań stawianych przez użytkownika końcowego. Niezbędne jest bardzo jasno określone wymagania i głębokie zrozumienie, dlaczego baza danych jest potrzebna i jak będzie używana. Jeśli stworzymy diagram ER z niewystarczającymi danymi i niepełnym zrozumieniem, najprawdopodobniej spowoduje to, że relacje między podmiotami zostaną źle zdefiniowane.

Spójrzmy na przykład. Jeśli tworzysz bazę danych dla banku, najprawdopodobniej utworzysz diagram ER z encją klient posiadające atrybuty id , imię i nazwisko . Będziesz mieć również podmiot o nazwie konto z atrybutami id i wpisz . Jeśli nie masz doświadczenia w branży bankowej, prawdopodobnie pomyślisz, że między klientem zawsze istnieje relacja 1:N i konto podmioty, jak pokazano poniżej.

Jeden klient może mieć kilka rachunków w jednym banku. Konto może jednak należeć tylko do jednego klienta. Czy to rzeczywiście prawda? Może jest, a może nie. Sporo banków oferuje rachunki wspólne, z których może korzystać kilku klientów. Tworzysz schemat ER dla banku, który oferuje taką usługę? Jeśli bank nie oferuje rachunków wspólnych, to masz rację:relacja między klientem i konto wynosi 1:N. Jeśli jednak bank oferuje rachunki wspólne, to relacja to M:N.

Używanie instancji encji zamiast encji

Innym częstym błędem jest użycie instancji encji zamiast encji. Instancja encji to pojedyncze wystąpienie określonej encji – tj. encji, która w rzeczywistości może być atrybutem większej kategorii.

Załóżmy, że pracujemy w firmie, która przydziela telefony komórkowe i laptopy określonym pracownikom. Tak więc w naszej bazie danych mielibyśmy podmiot o nazwie laptop z atrybutami id i model oraz podmiot o nazwie pracownik z atrybutami id , imię i nazwisko , Prawidłowy?

Tu pojawia się problem:laptop tak naprawdę nie jest bytem – trzeba też rozliczać telefony komórkowe. Rozwiązaniem jest zastąpienie jednostki laptop z bardziej ogólnym bytem, ​​takim jak sprzęt . Ta jednostka może mieć atrybuty ID , wpisz i model , jak pokazano niżej. typ może składać się z wartości, takich jak telefon , komputer , tablet i laptop . W ten sposób nie ma potrzeby tworzenia oddzielnej jednostki dla każdego rodzaju sprzętu.

Przykład znajdziesz tutaj:

Mylenie atrybutu z bytem

Kolejnym częstym błędem jest pomylenie atrybutu z bytem. Załóżmy, że zdecydowaliśmy się utworzyć podmiot o nazwie pracownik który będzie składał się z atrybutów id , imię , nazwisko , data_urodzenia , wydział_identyfikacji , nazwa_działu i head_department . Ta encja sprawi nam kłopoty, gdy tworzymy model bazy danych, ponieważ składa się ze zbyt wielu atrybutów, które nie definiują jednoznacznie tej konkretnej encji .

Pamiętaj, że zdefiniowaliśmy podmioty jako wszystko, o czym możemy zbierać dane. Mając to na uwadze, widzimy, że obecny pracownik podmiot można podzielić na dwa podmioty:pracownik i wydział , jak pokazano niżej.

Atrybuty złożone

Ostatnim powszechnym błędem, o którym będziemy mówić, jest włączenie złożonego atrybutu do encji. Innymi słowy, mamy atrybut, który w rzeczywistości powinien być jego własną jednostką .

Załóżmy, że mamy podmiot o nazwie studenci który jest zdefiniowany przez następujące atrybuty:id , imię , nazwisko , data_urodzenia , adres i egzamin_zdany . Tutaj, egzamin_zdany to złożony atrybut, który składa się z więcej niż jednej informacji, tj. identyfikatora i daty egzaminu oraz wyniku studenta. Pozostawienie tego w ten sposób byłoby błędem. Zamiast tego powinniśmy utworzyć nowy podmiot z tego złożonego atrybutu . Nowa jednostka mogłaby nosić nazwę egzaminy i składa się z następujących atrybutów:id , data , identyfikator_studenta i wynik .

Przykład znajdziesz tutaj:

Czy otrzymałeś jakieś przydatne wskazówki dotyczące diagramów ER?

Te cztery typy błędów są najczęstsze w procesie tworzenia diagramu ER. Oczywiście nie ma pełnej listy typowych błędów lub rodzajów błędów. W prawdziwym życiu może się zdarzyć wiele rodzajów błędów. Brak planowania, niewystarczające wsparcie techniczne i pospieszny proces projektowania bazy danych przyczyniają się do własnych problemów. Jeśli kiedykolwiek tworzyłeś bazy danych lub brałeś w nich udział od strony biznesowej, prawdopodobnie doświadczyłeś niektórych z nich! Wszystkie te okoliczności prowadzą do różnych błędów, z których niektóre są dość wyjątkowe.

Czy masz własny przykład niezbyt dobrego diagramu ER? A może są inne błędy, które często znajdujesz? Daj mi znać w sekcji komentarzy.