Należy unikać zależności kołowej

Question

Pracuję nad aplikacją do zarządzania podróżami. Omawiany projekt wygląda następująco:

Każda osoba w trasie jest wyznaczona jako Podróżniczka. Każdy podróżujący ma paszport. Teraz Podróżnikiem może być Członek Główny lub Podoficer, w zależności od tego, czy jest on głową rodziny. A MainMember decyduje się na takie rzeczy, jak pakiet TourPackage, łączna kwota dla jego rodziny podróżującej itp. Podmorski jest zależny od głównego użytkownika podczas podróży. Tak więc, jeśli MainMember zostanie usunięty, wszystkie jego SubMembers muszą zostać usunięte.

Tak, Podróżny ma paszport. (Relacja jeden do jednego) Podróżny jest albo członkiem zarządu, albo członkiem grupy. (jeden do zera/jeden między Traveler-MainMember i Traveler-SubMember) A MainMember może mieć kilka SubMembers. (jeden-do-wielu) Submember ma tylko jedną MainMembers. (wiele-do-jednego)

Moje obecne ERD jest coś w następujący sposób.

Jak widać, trzy stoliki - podróżników, MainMember i podelementu - utworzyli kołową zależność. Nie jestem pewien, czy to zrani moją aplikację. Jeśli usuwam Traveler, który jest elementem MainMember, wówczas 1. Rekord produktu Traveler został usunięty. 2. Odpowiedni rekord MainMember został usunięty. 3. Rekordy podrzędne zależne od członka głównego są usuwane. 4. Rekordy Traveler dla SubMembers zostaną usunięte.

Chociaż nie wydaje się to być problemem, ponieważ usuwanie Traveler-MainMember zawsze usunie tylko Traveler-SubMember (s). Mimo to mam złe przeczucia.

Czy każdy może mnie poprowadzić do lepszego projektu?

AKTUALIZACJA -

czekając na odpowiedzi, ja przyszedłem z innego projektu, na podstawie @ post Daveo użytkownika. Zasadniczo produkt Traveler zawiera samoodnoszący się klucz obcy. Byłby wykorzystywany przez rekordy Podmorskich do identyfikacji swoich rodziców.

Oto ERD do tego.

Teraz, jak nie było problemem uzależnienia od kołowego w moim poprzednim wzorem, jak wskazano przez @Branko, chciałbym wiedzieć, który projekt jest lepszy?

Ponadto, który projekt lepiej byłoby zaimplementować za pomocą Hibernacji? Myślę, że drugie podejście może doprowadzić do złożoności podczas implementacji przez Hibernate.

Chciałbym również docenić niektóre wskazówki dotyczące wzorów realizacji (dziedziczenie w obiektach hibernacji, itp.) Dla projektu, który wolisz.

Answer 1

Jak widać, trzy stoliki - podróżnik, MainMember i podelementu - utworzyli zależność cykliczną.

nie, to nie jest okrągły zależność - nie „węzeł” w tym wykresie można osiągnąć się stosując Graph „krawędzie” we właściwym kierunku . Byłoby to dokładniej opisane jako zależność "scalona" lub nawet (proto) "w kształcie rombu".

I nie, nie zaszkodzi to twojej aplikacji.

Jesteś skutecznego wdrożenia dziedziczenie podejście (aka kategorii, podklasy, podtypy, hierarchia generalizacji etc.), przy użyciu "każdą klasę w osobnej tabeli". To podejście jest czyste, ale nie może zagwarantować, że po wyjęciu z pudełka zostanie wykryta obecność i wyłączność. Istnieją sposoby na amend it, tak jest, i istnieją inne strategie wdrażania dziedziczenia, które mogą, ale mają one własne pros and cons.

Moim zdaniem, twój model jest w porządku, ponieważ to, co próbujesz osiągnąć, i egzekwowanie obecności/wyłączności na poziomie aplikacji jest prawdopodobnie mniejszym złem niż cierpienie za to, że próbuje wymusić na poziomie bazy danych.

---

"kierunek" jest od odwoływania się do wskazanej tabeli. Traveller nie odnosi się do MainMember ani SubMember i dlatego przerywa cykl.

ile jesteś w DBMS (takich jak MS SQL Server), że nie popiera działań referencyjnych na takie „połączone” zależnościami (w tym przypadku trzeba by wdrożyć ON DELETE CASCADE przez wyzwalacze).

Traveller nie może istnieć samodzielnie (nie może być "abstract"), to musi być MainMember lub SubMember.

Traveller nie może być zarówno MainMember i SubMember.

Answer 2

Mam tylko dwie tabele w bazie danych.

podróżników i hasło

podróżników będzie mieć pole parent_id która połączy z powrotem do stołu podróżników i przechowywania który podróżny Główna/Head. Przechowuj również pola wspólne dla członka głównego/podrzędnego w tej tabeli, np. Numer kontaktowy

Następnie przy użyciu dziedziczenia i ORM utwórz dwie różne klasy w rzeczywistej aplikacji. MainMember i podelementu MainMember byłyby wszystkie wiersze w Traveler gdzie parent_id jest null podelementu byłyby wszystkie wiersze w Traveler gdzie parent_id nie jest null