Podmiot można zdefiniować jako rzecz zdolną do niezależnego istnienia, którą można jednoznacznie zidentyfikować. Podmiot jest abstrakcją od złożoności domeny. Kiedy mówimy o podmiocie, zwykle mówimy o jakimś aspekcie świata rzeczywistego, który może być odróżniony od innych aspektów świata rzeczywistego.
Podmiot to rzecz, która istnieje fizycznie lub logicznie. Podmiot może być obiektem fizycznym, takim jak dom lub samochód (istnieją fizycznie), wydarzenie, takie jak sprzedaż domu lub serwis samochodowy, lub pojęcie, takie jak transakcja klienta lub zamówienie (istnieją logicznie – jako pojęcie). Chociaż termin encja jest najczęściej używany, za Chenem powinniśmy naprawdę rozróżnić między encją a typem encji. Typ encji jest kategorią. Encja, ściśle mówiąc, jest instancją danego typu encji. Zwykle istnieje wiele instancji typu encji. Ponieważ termin entity-type jest nieco kłopotliwy, większość ludzi ma tendencję do używania terminu entity jako synonimu tego terminu
Entities mogą być traktowane jak rzeczowniki. Przykłady: komputer, pracownik, piosenka, twierdzenie matematyczne, itp.
Relacja określa, w jaki sposób encje są powiązane ze sobą. Relacje mogą być postrzegane jako czasowniki, łączące dwa lub więcej rzeczowników. Przykłady: relacja właściciel między firmą a komputerem, relacja nadzoruje między pracownikiem a działem, relacja wykonuje między artystą a piosenką, relacja dowodzi między matematykiem a twierdzeniem, itp.
Opisany powyżej aspekt lingwistyczny modelu jest wykorzystany w deklaratywnym języku zapytań do bazy danych ERROL, który naśladuje konstrukcje języka naturalnego. Semantyka i implementacja ERROL’a opiera się na przekształconej algebrze relacyjnej (RRA), algebrze relacyjnej, która jest dostosowana do modelu encja-relacja i oddaje jego aspekt lingwistyczny.
Elementy i relacje mogą posiadać atrybuty. Przykłady: encja pracownik może mieć atrybut numer ubezpieczenia społecznego (SSN), podczas gdy udowodniona relacja może mieć atrybut data.
Wszystkie encje z wyjątkiem słabych encji muszą mieć minimalny zestaw atrybutów jednoznacznie identyfikujących, które mogą być użyte jako klucz unikalny/pierwotny.
Diagramy encji-relacji nie pokazują pojedynczych encji lub pojedynczych instancji relacji. Pokazują raczej zbiory encji (wszystkie encje tego samego typu) i zbiory relacji (wszystkie relacje tego samego typu). Przykłady: określona piosenka jest encją; zbiór wszystkich piosenek w bazie danych jest zbiorem encji; zjedzona relacja pomiędzy dzieckiem a jego obiadem jest pojedynczą relacją; zbiór wszystkich takich relacji dziecko-lunch w bazie danych jest zbiorem relacji.Innymi słowy, zbiór relacji odpowiada relacji w matematyce, podczas gdy relacja odpowiada członkowi relacji.
Można również wskazać pewne ograniczenia kardynalności na zbiory relacji.
Mapowanie języka naturalnegoEdit
Chen zaproponował następujące „zasady kciuka” mapowania opisów w języku naturalnym na diagramy ER: „Angielski, chiński i diagramy ER” autorstwa Petera Chena.
| Struktura gramatyki angielskiej | Struktura ER |
|---|---|
| Common noun | Entity type |
| Proper noun | Entity |
| Transitive verb | Relationship type |
| Czasownik przechodni | Typ atrybutu |
| Przymiotnik | Atrybut dla podmiotu |
| Przysłówek | Atrybut dla relacji |
Widok fizyczny pokazuje, jak dane są faktycznie przechowywane.
Relacje, role i kardynalnościEdit
W oryginalnym artykule Chen podaje przykład relacji i jej ról. Opisuje on relację „małżeństwo” i jej dwie role „mąż” i „żona”.
Jedna osoba odgrywa rolę męża w małżeństwie (związku), a inna osoba odgrywa rolę żony w (tym samym) małżeństwie. Te słowa są rzeczownikami. Nie jest to niespodzianką; nazywanie rzeczy wymaga rzeczownika.
Terminologia Chena została również zastosowana do wcześniejszych idei. Linie, strzałki i kurze łapki w niektórych diagramach zawdzięczają więcej wcześniejszym diagramom Bachmana niż diagramom relacji Chena.
Innym powszechnym rozszerzeniem modelu Chena jest „nazywanie” relacji i ról czasownikami lub frazami.
Nazewnictwo rólEdit
Powszechne stało się również nazywanie ról frazami takimi jak is the owner of i is owned by. Poprawnymi rzeczownikami w tym przypadku są właściciel i posiadanie. Tak więc osoba odgrywa rolę właściciela, a samochód odgrywa rolę posiadania, a nie osoba odgrywa rolę osoby, jest właścicielem itd.
Używanie rzeczowników ma bezpośrednie korzyści przy generowaniu fizycznych implementacji z modeli semantycznych. Kiedy osoba ma dwie relacje z samochodem, możliwe jest wygenerowanie nazw takich jak owner_person i driver_person, które są natychmiast znaczące.
CardinalitiesEdit
Modyfikacje oryginalnej specyfikacji mogą być korzystne. Chen opisał kardynalności typu look-across. Na marginesie, notacja Barker-Ellis, używana w Oracle Designer, używa same-side dla minimalnej kardynalności (analogicznej do opcjonalności) i roli, ale look-across dla maksymalnej kardynalności (the crows foot).
W Merise, Elmasri & Navathe i innych istnieje preferencja dla same-side dla ról i zarówno minimalnej, jak i maksymalnej kardynalności. Ostatni badacze (Feinerer, Dullea et al.) wykazali, że jest to bardziej spójne, gdy stosuje się to do n-arnych relacji rzędu większego niż 2.
W Dullea et al. czytamy „A 'look across' notation such as used in the UML does not effectively represent the semantics of participation constraints imposed on relationships where the degree is higher than binary.”
W Feinerer mówi „Problemy pojawiają się, jeśli działamy w oparciu o look-across semantics as used for UML associations. Hartmann bada tę sytuację i pokazuje, jak i dlaczego różne transformacje zawodzą.” (Chociaż wspomniana „redukcja” jest złudna, ponieważ dwa diagramy 3.4 i 3.5 są w rzeczywistości takie same), a także „Jak zobaczymy na następnych kilku stronach, interpretacja look-across wprowadza kilka trudności, które uniemożliwiają rozszerzenie prostych mechanizmów z asocjacji binarnych na n-ary.”
Notacja Chena dla modelowania relacji encji używa prostokątów do reprezentowania zbiorów encji, a rombów do reprezentowania relacji właściwych dla obiektów pierwszej klasy: mogą one mieć własne atrybuty i relacje. Jeśli zbiór encji uczestniczy w zbiorze relacji, są one połączone linią.
Atrybuty są rysowane jako owale i są połączone linią z dokładnie jednym zbiorem encji lub relacji.
Kardynalne ograniczenia są wyrażone w następujący sposób:
- podwójna linia wskazuje na ograniczenie uczestnictwa, totalności lub suriektywności: wszystkie encje w zbiorze encji muszą uczestniczyć w co najmniej jednej relacji w zbiorze relacji;
- strzałka od zbioru encji do zbioru relacji wskazuje na ograniczenie kluczowe, tj.injectivity: każda encja ze zbioru encji może uczestniczyć w co najwyżej jednej relacji w zbiorze relacji;
- gruba linia wskazuje na oba ograniczenia, tj. bijectivity: każda encja ze zbioru encji uczestniczy w dokładnie jednej relacji.
- podkreślona nazwa atrybutu wskazuje, że jest on kluczem: dwie różne encje lub relacje z tym atrybutem zawsze mają różne wartości tego atrybutu.
Atrybuty są często pomijane, ponieważ mogą zagracać diagram; inne techniki diagramów często wymieniają atrybuty encji wewnątrz prostokątów rysowanych dla zbiorów encji.
Powiązane techniki konwencji diagramowych:
- Notacja Bachmana
- Notacja Barkera
- EXPRESS
- IDEF1X
- Notacja stopy Crow’a (także notacja Martina)
- (min, max)-notacja Jeana-Raymonda Abriala z 1974 roku
- Diagramy klasUML
- Merise
- Modelowanie obiektowo-rolowe
Wronia stopkaEdit
Wronia stopka, której początki sięgają artykułu Gordona Everesta (1976), jest stosowana w notacji Barkera, metodzie analizy i projektowania systemów strukturalnych (SSADM) oraz inżynierii informatycznej. Diagramy Crow’s foot reprezentują encje jako pudełka, a relacje jako linie pomiędzy pudełkami. Różne kształty na końcach tych linii reprezentują względną kardynalność relacji.
Notacja Crow’s foot była używana w praktyce konsultingowej CACI. Wielu konsultantów z CACI (w tym Richard Barker) przeniosło się następnie do Oracle UK, gdzie opracowali wczesne wersje narzędzi CASE firmy Oracle, wprowadzając notację do szerszego grona odbiorców.
W przypadku tej notacji relacje nie mogą mieć atrybutów. Tam, gdzie jest to konieczne, relacje są promowane jako samodzielne byty: na przykład, jeśli konieczne jest uchwycenie, gdzie i kiedy artysta wykonał piosenkę, wprowadzany jest nowy byt „wykonanie” (z atrybutami odzwierciedlającymi czas i miejsce), a związek artysty z piosenką staje się pośrednim związkiem poprzez wykonanie (artysta-wykonuje-wykonanie, wykonanie-posiada-piosenkę).
Trzy symbole są używane do reprezentowania kardynalności:
- Pierścień reprezentuje „zero”
- Kreska reprezentuje „jeden”
- Królik reprezentuje „wiele” lub „nieskończoność”
Symbole te są używane w parach, aby reprezentować cztery rodzaje kardynalności, które podmiot może mieć w relacji. Wewnętrzny składnik notacji reprezentuje minimum, a zewnętrzny składnik reprezentuje maksimum.
- pierścień i kreska → minimum zero, maksimum jeden (opcjonalnie)
- kreska i myślnik → minimum jeden, maksimum jeden (obowiązkowo)
- pierścień i kurza stopka → minimum zero, maksymalnie wiele (opcjonalnie)
- dash i crow’s foot → minimum jeden, maksimum wiele (obowiązkowo)
Problemy z użytecznością modeluEdit
W korzystaniu z modelowanej bazy danych użytkownicy mogą napotkać dwa dobrze znane problemy, w których zwracane wyniki oznaczają coś innego niż wyniki założone przez autora zapytania.
Pierwszym z nich jest „pułapka na fanów”. Występuje ona w przypadku tabeli głównej (master), która łączy się z wieloma tabelami w relacji jeden do wielu (one-to-many). Problem ten bierze swoją nazwę od sposobu, w jaki model ten wygląda, gdy jest rysowany na diagramie relacji encji: połączone tabele „rozchodzą się” od tabeli nadrzędnej. Ten typ modelu wygląda podobnie do schematu gwiaździstego, typu modelu używanego w hurtowniach danych. Podczas próby obliczenia sum nad agregatami przy użyciu standardowego SQL nad tabelą główną, mogą pojawić się nieoczekiwane (i niepoprawne) wyniki. Rozwiązaniem jest albo dostosowanie modelu, albo kodu SQL. Problem ten występuje głównie w bazach danych dla systemów wspomagania decyzji, a oprogramowanie, które odpytuje takie systemy, czasami zawiera specjalne metody obsługi tego problemu.
Drugim problemem jest „pułapka przepaści”. Pułapka przepaści występuje, gdy model sugeruje istnienie relacji pomiędzy typami encji, ale ścieżka nie istnieje pomiędzy niektórymi wystąpieniami encji. Na przykład, budynek posiada jeden lub więcej pokoi, w których znajduje się zero lub więcej komputerów. Można by oczekiwać, że zapytanie do modelu pozwoli zobaczyć wszystkie komputery w budynku. Jednak komputery, które nie są aktualnie przypisane do pokoju (ponieważ są w naprawie lub w innym miejscu) nie są wyświetlane na liście. Potrzebna jest kolejna relacja między budynkiem a komputerami, aby uchwycić wszystkie komputery w budynku. Ten ostatni problem związany z modelowaniem jest wynikiem braku uchwycenia w modelu wszystkich relacji, które istnieją w świecie rzeczywistym. Zobacz Modelowanie Relacji Między Podmiotami 2, aby uzyskać więcej szczegółów.