Zależności między tabelami w bazie danych

4.1 Wprowadzenie

Konwertując tabele bazy danych na zwykłe tabele, można teraz analizować relacje między nimi. Liczba elementów wchodzących w interakcję między dwiema powiązanymi tabelami nazywana jest kardynalnością. Kardynalność pomaga kontrolować, jak wydajnie partycjonujesz dane w tabelach.

Teoretycznie wszystkie podmioty mogą utrzymywać ze sobą relacje, ale w praktyce istnieją trzy typy relacji między podmiotami:

• Jeden na jednego
• Jeden za dużo
• wielu do wielu

4.2 Komunikacja jeden do jednego

Jeśli istnieje tylko jedna instancja encji A dla każdej instancji encji B, mówi się, że mają one relację jeden do jednego (często oznaczaną jako „1:1”). Na diagramach ER taka zależność jest wskazywana przez linię z małym paskiem na każdym końcu:

Relacja 1:1 ogólnie wskazuje, że jeśli nie ma dobrego powodu, aby trzymać je oddzielnie, najlepiej połączyć dane z dwóch tabel w jedną.

Jednak w niektórych okolicznościach uzasadnione jest użycie tabel z relacjami 1:1. Jeśli Twoje tabele posiadają pola z opcjonalnymi danymi, takimi jak opisy, a w wielu przypadkach są one puste, sensowne jest przeniesienie wszystkich opisów do osobnej tabeli, co pozwoli Ci pozbyć się częstych luk i zwiększyć wydajność Twojej bazy danych .

Następnie, aby poprawnie zmapować dane, będziesz musiał umieścić w każdej tabeli co najmniej jedną identyczną kolumnę (najlepiej wybrać do tego klucz główny).

4.3 Relacja jeden do wielu

Ten typ relacji występuje, gdy rekord w jednej tabeli jest powiązany z wieloma jednostkami w innej. Na przykład ten sam klient może złożyć wiele zamówień, a odwiedzający bibliotekę może wypożyczyć wiele książek podczas jednej wizyty. Relacje jeden-do-wielu (lub w skrócie 1:M) są wyrażone na diagramie przy użyciu notacji kurzych łapek, jak pokazano w poniższym przykładzie:

Aby zastosować relację 1:M podczas planowania bazy danych, po prostu dodaj klucz podstawowy z tabeli „jeden” jako atrybut do tabeli „wiele”. Jeśli klucz podstawowy znajduje się w innej tabeli, nazywa się go „kluczem obcym”. Tabela „jeden” jest uważana za tabelę nadrzędną, podczas gdy tabela „wiele” jest uważana za tabelę podrzędną.

4.4 Relacja wiele do wielu

Gdy wiele jednostek w jednej tabeli może być połączonych z wieloma jednostkami w innej, uważa się, że mają one relację wiele-do-wielu (lub M:M). Na przykład taki związek istnieje między uczniami a klasami, ponieważ każdy uczeń może uczęszczać na kilka różnych zajęć, a co za tym idzie, wielu uczniów może przyjść na każde zajęcia.

Na diagramie ER ten typ relacji jest przedstawiony w następujący sposób:

Niestety nie da się bezpośrednio zaimplementować takiej relacji w bazie danych. Dlatego będzie musiał zostać podzielony na dwie relacje jeden-do-wielu.

Aby to zrobić, musisz utworzyć nową jednostkę między dwiema tabelami. Jeśli zostanie ustanowiona relacja M:M między sprzedażą a produktami, nową jednostkę można nazwać „sprzedanymi produktami”, ponieważ będzie ona reprezentować zawartość każdej sprzedaży.

Z "towary sprzedane" i tabela "sprzedaż" oraz tabela "towary" zostaną połączone typem 1:M. W różnych modelach takie encje pośrednie nazywane są inaczej – „tabelami łączącymi”, „obiektami asocjacyjnymi” czy „tabelami węzłów”.

Każdy wpis w tabeli łączy łączy dwie różne jednostki sąsiednich tabel (i może również zawierać dodatkowe informacje). Na przykład tabela połączeń między uczniami a klasami może wyglądać następująco:

4.5 Obowiązkowe czy nie?

Innym podejściem do analizy powiązań jest określenie, który z połączonych bytów jest warunkiem wstępnym obecności innego bytu. Opcjonalna strona łącza jest oznaczona kółkiem na pniu.

Na przykład, aby państwo miało swojego przedstawiciela w ONZ, musi istnieć na mapie świata, ale stwierdzenie przeciwne będzie fałszywe:

Dwa byty mogą być współzależne (to znaczy jeden nie może istnieć bez drugiego).

Linki rekurencyjne

Czasami tabela może odnosić się do samej siebie. Na przykład tabela pracowników może mieć atrybut „menedżer”, który odsyłałby nas do innego pracownika w tej samej tabeli. To jest relacja rekurencyjna.

Dodatkowe połączenia

Linki są uważane za zbędne, jeśli są wyrażone więcej niż jeden raz. Z reguły jeden z nich można usunąć bez utraty ważnych informacji. Na przykład, jeśli podmiot „studenci” jest powiązany z podmiotem „nauczyciele” nie tylko bezpośrednio, ale także pośrednio poprzez „klasy”, sensowne jest usunięcie relacji między podmiotami „uczniowie” i „nauczyciele”. Decyzja ta jest uzasadniona faktem, że przydział uczniów do nauczycieli jest możliwy tylko poprzez zajęcia.

4.6 Integralność referencyjna danych

Przy zmianie kluczy podstawowych i obcych należy zwrócić uwagę na taki aspekt jak integralność referencyjna danych . Jego główną ideą jest utrzymanie dwóch tabel w bazie danych, które przechowują te same dane w spójny sposób.

Integralność danych reprezentuje prawidłowo zbudowane relacje między tabelami z poprawnymi powiązaniami między nimi. W jakich przypadkach integralność danych może zostać naruszona:

• Anomalia usuwania . Występuje po usunięciu wiersza z tabeli głównej. W takim przypadku klucz obcy z tabeli zależnej nadal odnosi się do usuniętego wiersza z tabeli głównej.
• Anomalia wstawiania . Występuje po wstawieniu wiersza do tabeli zależnej. W tym przypadku klucz obcy z tabeli zależnej nie pasuje do klucza podstawowego żadnego z wierszy z tabeli głównej.
• Zaktualizuj anomalię. Przy takiej anomalii kilka wierszy jednej tabeli może zawierać dane należące do tego samego obiektu. Jeśli zmienisz dane w jednym wierszu, mogą one wejść w konflikt z danymi z innego wiersza.

Anomalia usuwania

Aby rozwiązać problem usuwania, klucz obcy powinien mieć jedno z dwóch ograniczeń:

Jeśli wiersz z tabeli zależnej koniecznie wymaga wiersza z tabeli głównej, wówczas klucz obcy jest ustawiany na usuwanie kaskadowe. Oznacza to, że gdy wiersz jest usuwany z tabeli głównej, powiązane wiersze są usuwane z tabeli zależnej.

Jeśli wiersz z tabeli zależnej nie dopuszcza żadnej relacji do wiersza z tabeli głównej (czyli taka relacja jest opcjonalna), to klucz obcy jest ustawiany na NULL, gdy powiązany wiersz jest usuwany z tabeli głównej. Kolumna klucza obcego musi dopuszczać wartość null.

Anomalia wstawiania

Aby rozwiązać problem wstawiania podczas dodawania do tabeli danych zależnych, kolumna reprezentująca klucz obcy musi dopuszczać wartość null. I tak, jeśli dodawany obiekt nie ma połączenia z główną tabelą, to kolumna klucza obcego będzie miała wartość NULL.

Zaktualizuj anomalie

Aby rozwiązać problem anomalii aktualizacji, stosowana jest normalizacja, która została omówiona wcześniej.