Kiedy powinniśmy używać słabych jednostek podczas modelowania bazy danych?

12

To w zasadzie pytanie o to, czym są słabe byty? Kiedy powinniśmy ich używać? Jak powinny być modelowane?

Jaka jest główna różnica między normalnymi a słabymi istotami? Czy słabe byty odpowiadają obiektom wartości podczas projektowania opartego na domenach?

Aby pomóc zachować pytanie na ten temat, oto przykład wzięty z Wikipedii, z którego ludzie mogą skorzystać, aby odpowiedzieć na następujące pytanie: wprowadź opis zdjęcia tutaj

W tym przykładzie OrderItemzostał zamodelowany jako słaby byt, ale nie rozumiem, dlaczego nie można go wymodelować jako zwykły byt.
Innym pytaniem jest, co jeśli chcę śledzić historię zamówień (tj. Zmiany jej statusu), czy byłby to normalny lub słaby podmiot?

design database database-design entity Songo
źródło

Odpowiedzi:

10

Formalnie „słaby” byt ma następujące cechy.

1.  It is existence-dependent on another entity, i.e., 
    it cannot exist without the entity with which it has a relationship.

2.  It inherits at least part of it's primary key from the entity to which 
    it is related. 


    i.e. -> A weak entity's primary key must be a composite key that includes 
       the primary key of the entity on which it is existence-dependent.

Powiedziałbym, że w praktyce nie zdecydowałbyś się jawnie uczynić z czegoś czegoś „słabego”; zamiast tego ustrukturyzujesz dane, aby były reprezentatywne dla wszystkiego, co próbujesz modelować. Jeśli po wykonaniu tej czynności spojrzysz na konkretny byt, który ma cechy „słabego” bytu, możesz go odpowiednio udokumentować lub wykreślić, jeśli z jakiegoś powodu czujesz potrzebę wyraźnego wywołania tego lub ze względu na formalności.

Ed Hastings
źródło
hmmm, a co z moim przykładem? tutaj OrderItemjest zależne od tego, Orderże nie orderItemsmoże istnieć bez przynależności do order, ale nie rozumiem, dlaczego nie mogę użyć ItemLineNumberwyłącznie do identyfikacji przedmiotu ?! Właściwie może po prostu stworzę ItemLineNumberautomatycznie wygenerowane, intaby zapewnić unikalność i użyć klucza obcego, orderIDaby połączyć dwa podmioty ze sobą ?!
Songo,
2
Jeśli zdefiniujesz swój OrderItem tak, aby posiadał jednoznacznie identyfikujący sekwencyjny id, a OrderId nie jest częścią klucza, wówczas traktujesz OrderItem jako obywateli pierwszego rzędu i tak naprawdę nie ma słabego bytu. Możesz FK inne tabele do OrderItems indywidualnie, jeśli chcesz; nie trzeba już mieć OrderId, aby uzyskać w OrderItems. Z drugiej strony, jeśli wpiszesz OrderItem za pomocą OrderId i sekwencjęId (lub podobną) istotną dla Zamówienia, będziesz mieć słaby byt, a poszczególne elementy zamówienia będą się odnosić tylko przy użyciu OrderId i sekwencjaId. Wykorzystanie modelu zgodnie z przeznaczeniem.
Ed Hastings,
2
Ponadto, komentarz styczny, może być bardzo kuszące, aby po prostu nadać każdej tabeli swój własny sekwencyjny klucz podstawowy i utrzymać relacje tak proste, jak to możliwe, z relacjami pojedynczego pola PK-> FK. Jest to szczególnie przydatne w przypadku prostych baz danych i łatwe do uzasadnienia. Jednak podczas modelowania bardziej złożonych i / lub wyrafinowanych relacji złożone klucze stają się bardzo przydatne i dają więcej możliwości modelowania niuansów.
Ed Hastings,
1

Nie OrderItemmoże istnieć bez zamówienia lub produktu. Dlatego jest słaby, ponieważ kontrolują go zależności.

Jeśli na przykład usuniesz zamówienie, nie będziesz mógł wiedzieć, dokąd należy wysłać przedmiot. Lub jeśli usuniesz produkt, nie wiesz, co wysłać.

jgauffin
źródło
-1

Zgodnie z moim rozumieniem na powyższym diagramie, zamiast jednego, tj. Zamówienia i pozycji zamówienia, uwzględniły dwa byty / tabele, dzięki czemu dostęp do informacji staje się łatwy, gdy zaprojektowano dwa byty. A przedmiot zamówienia jest zależny od podmiotu zamówień, więc jest uważany za podmiot słaby. ponieważ cechą słabej istoty jest to, że zależy od innej istoty. Załóżmy, że jeśli nie podasz elementu zamówienia, skąd będziesz mógł poznać cenę przedmiotu zamówienia, rabat. i jak powiedział jgauffin. Jeśli na przykład usuniesz zamówienie, nie możesz wiedzieć, gdzie należy wysłać przedmiot. Lub jeśli usuniesz produkt, nie wiesz, co wysłać.

Schemat ER należy zaprojektować zgodnie z wymaganiami biznesowymi.

sam
źródło
-1

Zobacz, zamówienie ma wiele pozycji zamówienia (atrybut wielowartościowy). Zatem zgodnie z regułą tworzymy osobną tabelę.

Teraz załóżmy, że 2 klientów ma to samo zamówienie. Np. Kupują iPhone'a w tej samej cenie, z rabatem, w tym samym dniu itp. Idealnie więc powinny być dwie dokładne krotki dla zamówienia iPhone'a w relacji kolejności. Ale zgodnie z ograniczeniem relacji wszystkie krotki powinny być unikalne. Więc powiązajmy dwa zamówienia z tym samym problemem item_line_number.no do teraz. Teraz rozważ jedno z anulowań klienta. Jest zamówieniem na iPhone'a. Krotka numer_elementu zostanie usunięta. Teraz inni klienci, którzy kupili iPhone'a, również zostają usunięci z powodu korespondencji M: 1. Wreszcie baza danych jest niespójna. Dlatego używamy klucza deskryptora, który będzie uporządkowany. Usunięcie jednego zamówionego iPhone'a nie powoduje uszkodzenia bazy danych.

VIVEK baryopia
źródło