Database
 sql >> Baza danych >  >> RDS >> Database

Wprowadzenie do modelu danych ER

Model danych relacji między jednostkami , zwany także ER , to jeden z różnych modeli danych, których możesz użyć do uzasadnienia swoich danych.

W szczególności jest to koncepcyjny model danych , ponieważ nie jest powiązany z żadną konkretną implementacją. To zadanie pozostawione logicznemu modelowi danych.

Model danych ER jest tak ogólny, tak wysoki, że może być zaimplementowany przez wiele różnych rodzajów baz danych.

To świetne, ponieważ nie myślisz o szczegółach implementacji, zamiast tego myślisz tylko o swoich danych i ich organizacji . A robiąc to, jesteś zmuszony do przeanalizowania problemu w sposób, o którym wcześniej nie myślałeś.

Uważam, że diagramy ER świetnie pomagają w analizie scenariusza, w którym zaangażowane są dane.

Model ER zapewnia narzędzia do reprezentowania, za pomocą notacji graficznej, wszystkich danych potrzebnych do modelowania, relacji między różnymi rodzajami danych oraz powiązanych z nimi informacji.

Istnieją 2 elementy, które składają się na model ER:

  • podmioty
  • relacje

Encje to typy danych, takie jak elementy lub osoby, które mają wspólne właściwości.

Relacje to relacje między podmiotami.

Podam przykład, porozmawiajmy o książkach i ich autorach. Mamy 2 podmioty :

  • książka
  • autor

Konkretna książka jest instancją encji książki.

Ponieważ mamy 2 podmioty, mamy 2 relacje między nimi. Jednym z nich jest relacja między pojedynczą książką a podmiotem autora. Jednym z nich jest relacja między pojedynczym autorem a całością książki. Jeśli się nad tym zastanowimy, mamy:

  • książka ma autora
  • autor może napisać wiele różnych książek

Zapis wizualny encji

Biorąc pod uwagę ten prosty przykład, możemy zacząć wprowadzać notację wizualną, która pomoże nam stworzyć model danych ER naszego scenariusza.

Uwaga:Istnieje wiele różnych sposobów rysowania diagramów ER. Użyję tego, który moim zdaniem , jest bardziej wizualny i ma więcej sensu.

Encje są reprezentowane jako prostokąty z tekstem do ich identyfikacji:

Zapis wizualny relacji

Relacja między bytami jest reprezentowana w swojej najbardziej podstawowej formie za pomocą linii łączącej dwie relacje oraz rombu z tekstem w celu zidentyfikowania typu relacji:

Zauważ, że nie stworzyłem 2 relacji „książka ma autora” i „autor napisał książkę”. Utworzyłem pojedynczą relację „autorską” między książką a autorem.

Kardynalności

Kiedy już mamy relację, musimy teraz wskazać zaangażowane liczby. W tej chwili mamy wiele pytań:

  • Ilu autorów może mieć książka?
  • Czy autor może napisać wiele książek?
  • Czy autor musi napisać przynajmniej jedną książkę, aby nazywać się autorem?
  • Czy książkę może napisać wielu autorów?
  • Czy książka może istnieć bez przynajmniej autora?

Wszystkie te pytania są dobre, aw tym przypadku wydaje mi się, że odpowiedzi są dość oczywiste. A gdy odpowiedź nie jest oczywista, możesz pomyśleć o problemie i dodać własne ograniczenia.

Istnieje wiele sposobów wizualnego wskazywania liczności na diagramie. Niektórzy wolą zmieniać kształt linii, gdy łączy się ona z bytem.

Wolę liczby, dzięki którym wszystko jest jaśniejsze:

Powyższe liczby oznaczają, że książka może być napisana przez jednego lub więcej autorów. n oznacza dowolną liczbę elementów.

A autor może być autorem od 0 książek (może właśnie pisze jedną) do nieskończonej liczby książek.

Pierwszy to relacja zero-do-wielu . Drugi to relacja jeden-do-wielu .

Możemy również mieć:

  • relacje jeden-do-jednego
  • relacje wiele-do-wielu
  • relacje zero-do-jednego

Atrybuty

Każda jednostka może mieć jeden lub więcej atrybutów.

Powiedzmy, że użyjemy powyższej relacji w księgarni. Każdy autor ma imię i nazwisko, biografię, adres URL witryny.

Każda książka ma tytuł, wydawcę, rok wydania, numer ISBN. Wydawcą może być również podmiot, jeśli chcemy. Ale możemy go również zdefiniować jako atrybut książki.

W ten sposób możemy przedstawić powyższe informacje:

Atrybuty identyfikatora

Jednostki muszą być identyfikowane za pomocą unikalnego klucza. Obiekt książki można jednoznacznie zidentyfikować za pomocą atrybutu ISBN. Każda książka ma jeden numer ISBN (biorąc pod uwagę, że nie reprezentujemy jednej kopii książki, ale „tytuł”).

Identyfikujemy główne atrybuty klucza na podstawie ich podstaw:

Z drugiej strony autor nie ma obecnie unikalnego identyfikatora. Dwóch autorów może mieć to samo nazwisko.

Dlatego musimy dodać unikalny kluczowy atrybut. Na przykład id atrybut:

Atrybuty identyfikatora mogą obejmować wiele atrybutów.

Na przykład identyfikator paszportu i kraj autora jednoznacznie identyfikują osobę i mogą zastąpić id atrybut, który dodaliśmy:

Który wybrać? To kwestia tego, co ma więcej sensu w Twojej aplikacji. Jeśli modelujemy księgarnię, nie możemy oczekiwać, że będziemy mieć kraj i paszport wszystkich autorów książek. Dlatego użyjemy losowego id wybierzemy i powiążemy z każdym autorem.

Atrybuty relacji

Atrybuty nie są unikalne dla jednostek. Relacje również mogą mieć atrybuty.

Rozważmy, że musimy zamodelować bibliotekę. Oprócz encji książki i autora wprowadzamy teraz jednostkę czytelnik , osoba, która wypożycza książkę, aby ją przeczytać. Bierzemy jego imię i nazwisko oraz numer dowodu osobistego, kiedy go pożyczają:

Ale wciąż brakuje nam informacji. Musimy wiedzieć, kiedy osoba wypożyczyła książkę i kiedy ją zwróciła, abyśmy mogli przechowywać informacje o całej historii danej książki w naszej bibliotece. Te informacje nie należą ani do książki, ani do podmiotów czytających; należy do relacji:

Słabe jednostki

Omówiliśmy powyżej klucze podstawowe i sposób, w jaki pomoc jednoznacznie identyfikuje jednostkę.

Niektóre byty zależą od innych bytów i są nazywane słabymi bytami .

Załóżmy, że musimy modelować zamówienia w sklepie internetowym.

Dla każdego zamówienia przechowujemy identyfikator zamówienia, który zaczyna się od 1 i rośnie z czasem, datę i godzinę złożenia oraz informacje o kliencie, dzięki czemu wiemy, kogo rozliczyć i gdzie go wysłać.

Wtedy też musimy wiedzieć, co zamówili. Tworzymy słaby element „zamówiony przedmiot”, który reprezentuje każdy przedmiot w koszyku w momencie kasy.

Podmiot ten będzie przechowywać cenę towaru w momencie realizacji zamówienia (więc zmiana ceny produktów na wyprzedaży nie wpłynie na już złożone zamówienia), ilość zamówionych towarów oraz wybrane opcje. Załóżmy, że sprzedajemy koszulki, dlatego musimy przechowywać kolor i rozmiar zamówionej koszulki.

Jest to słaba encja, ponieważ zamówiona encja nie może istnieć bez encji zamówienia.

Relacje rekurencyjne

Jednostka może mieć ze sobą rekurencyjną relację. Załóżmy, że mamy osobę. Możemy modelować relację rodzic-dziecko w ten sposób:

Osoba może mieć od 0 do n dzieci, dziecko ma 2 rodziców (biorąc pod uwagę najprostszy scenariusz).

Relacje ISA

ISA oznacza IS-A i jest sposobem na modelowanie uogólnień w modelu ER.

Używamy go do grupowania podobnych podmiotów pod wspólnym parasolem. Na przykład autora i czytelnika, w przypadku książek i przykładu z biblioteki, można uogólnić za pomocą jednostki osobowej.

Obaj mają imię, więc wyodrębniamy nazwę do encji osoby i po prostu zarządzamy osobliwościami bycia autorem lub czytelnikiem w odpowiedniej encji:

Relacje niebinarne

Nie każda relacja jest ściśle binarna. Weźmy scenariusz lekcji.

Lekcja odbywa się w sali szkolnej dzisiaj o godzinie 10:00, z nauczycielem rozmawiającym z klasą o fizyce.

Tak więc lekcja odbywa się o określonej porze dnia, obejmuje przedmiot, nauczyciela, klasę i salę.

Możemy to zamodelować w ten sposób:


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Projektowanie bazy danych dla systemu rekrutacyjnego

  2. Wypełnianie luki dotyczącej platformy Azure:zarządzane instancje

  3. Instrukcja SQL SELECT INTO

  4. Jak zamienić część ciągu w SQL?

  5. Co to jest DBMS? – Kompleksowy przewodnik po systemach zarządzania bazami danych