Słaby podmiot
W relacyjnej bazie danych słaba jednostka to jednostka, której nie można jednoznacznie zidentyfikować na podstawie samych jej atrybutów; dlatego musi używać klucza obcego w połączeniu ze swoimi atrybutami, aby utworzyć klucz podstawowy . Klucz obcy jest zwykle kluczem podstawowym podmiotu, z którym jest powiązany.
Klucz obcy jest atrybutem zestawu jednostek identyfikujących (lub właściciela , nadrzędnego lub dominującego ) . Każdy element w zbiorze jednostek słabych musi mieć relację z dokładnie jednym elementem w zbiorze jednostek-właścicieli, a zatem relacja nie może być relacją wiele do wielu.
Na diagramach relacji encji (diagramach ER) słaby zestaw encji jest oznaczony pogrubionym (lub podwójnie wypisanym) prostokątem (jednostka) połączonym pogrubioną (lub podwójnie wykreśloną) strzałką z pogrubionym (lub podwójnie wypisanym) diament (związek). Ten typ relacji jest nazywany relacją identyfikującą iw notacji IDEF1X jest reprezentowany przez owalną jednostkę, a nie kwadratową jednostkę w przypadku tabel podstawowych. Relacja identyfikująca to taka, w której klucz podstawowy jest wypełniany dla słabej jednostki potomnej jako klucz podstawowy w tej jednostce.
Na ogół (choć niekoniecznie) słaba jednostka nie ma żadnych elementów w swoim kluczu podstawowym poza odziedziczonym kluczem podstawowym i numerem kolejnym. Istnieją dwa typy jednostek słabych: jednostki asocjacyjne i jednostki podtypu. Ten ostatni reprezentuje kluczowy typ normalizacji , w którym jednostka nadtypu dziedziczy swoje atrybuty po jednostkach podtypu na podstawie wartości dyskryminatora .
W IDEF1X , rządowym standardzie określania wymagań, możliwe relacje podtypów to:
- Pełna relacja podtypu , gdy znane są wszystkie kategorie.
- Niekompletna relacja podtypu , gdy wszystkie kategorie mogą nie być znane.
Klasycznym przykładem słabej jednostki bez relacji podtypu byłyby rekordy „nagłówek/szczegóły” w wielu rzeczywistych sytuacjach, takich jak roszczenia, zamówienia i faktury, gdzie nagłówek przechwytuje informacje wspólne dla wszystkich formularzy, a szczegóły przechwytują informacje specyficzne do poszczególnych przedmiotów.
Standardowym przykładem kompletnej relacji podtypu jest encja podmiotu . Biorąc pod uwagę dyskryminator TYP PARTY (który może być osobą fizyczną, spółką osobową, korporacją C, stowarzyszeniem podrozdziału S, stowarzyszeniem, jednostką rządową, agencją quasi-rządową), dwoma podmiotami podtypu są OSOBA, która zawiera informacje specyficzne dla danej osoby, takie jak imię i nazwisko i data urodzenia oraz ORGANIZACJA, która zawierałaby takie atrybuty, jak nazwa prawna oraz hierarchie organizacyjne, takie jak miejsca powstawania kosztów.
Gdy relacje podtypów są renderowane w bazie danych, nadtyp staje się tak zwaną tabelą podstawową. Podtypy są uważane za tabele pochodne, które odpowiadają słabym jednostkom. Integralność referencyjna jest wymuszana poprzez kaskadowe aktualizacje i usuwanie.
Przykład
Rozważmy bazę danych, która rejestruje zamówienia klientów, gdzie zamówienie dotyczy jednej lub więcej pozycji sprzedawanych przez przedsiębiorstwo. Baza danych zawierałaby tabelę identyfikującą klientów według numeru klienta ( klucz główny ); inny identyfikujący produkty, które mogą być sprzedawane przez numer produktu ( klucz podstawowy ); i zawierałby parę tabel opisujących zamówienia.
Jedna z tabel mogłaby się nazywać Zamówienia i zawierałaby numer zamówienia ( klucz podstawowy ) w celu jednoznacznego zidentyfikowania tego zamówienia oraz zawierałaby numer klienta ( klucz obcy ) w celu określenia, komu sprzedawane są produkty, a także inne informacje, takie jak data i godzina złożenia zamówienia, sposób zapłaty, miejsce wysyłki itd.
Druga tabela mogłaby się nazywać OrderItem; byłby identyfikowany za pomocą klucza złożonego składającego się zarówno z numeru zamówienia ( klucz obcy ), jak i numeru pozycji; z innymi atrybutami klucza innego niż klucz podstawowy, takimi jak zamówiony numer produktu ( klucz obcy ), ilość, cena, wszelkie rabaty, wszelkie specjalne opcje i tak dalej. Może istnieć zero, jeden lub wiele wpisów OrderItem odpowiadających wpisowi Order, ale żaden wpis OrderItem nie może istnieć, chyba że istnieje odpowiedni wpis Order. (Przypadek zerowej pozycji zamówienia zwykle ma zastosowanie tylko przejściowo, gdy zamówienie jest wprowadzane po raz pierwszy i zanim pierwsza zamówiona pozycja zostanie zarejestrowana).
Tabela OrderItem przechowuje słabe jednostki właśnie dlatego, że OrderItem nie ma znaczenia niezależnego od Order. Niektórzy mogą twierdzić, że element OrderItem sam w sobie ma pewne znaczenie; rejestruje, że w pewnym momencie niezidentyfikowany w zapisie ktoś niezidentyfikowany w zapisie zamówił określoną ilość określonego produktu. Te informacje mogą być przydatne same w sobie, ale mają ograniczone zastosowanie. Na przykład, gdy tylko chcesz znaleźć trendy sezonowe lub geograficzne w sprzedaży towaru, potrzebujesz informacji z powiązanego rekordu Zamówienie.
Zamówienie nie istniałoby bez produktu i osoby tworzącej zamówienie, więc można by argumentować, że zamówienie byłoby opisane jako byt słaby, a zamówione produkty byłyby wielowartościowym atrybutem zamówienia.