Hibernate - jak sprawdzić kto jest właścicielem głęboko zagnieżdżonej encji?

Cześć,
W mojej aplikacji pisanej w Spring Boot używam Hibernate. Schemat bazy danych jest dość skomplikowany, oznacza to że od tabeli przechowującej id właściciela danych, do samych danych mogą być nawet 4 inne tabele po drodze. W jaki sposób mam sprawdzać czy użytkownik próbujący dostać się do encji jest jej właścicielem? Nie uśmiecha mi się pobierać za każdym razem kilku encji w górę, tylko aby sprawdzić czy id właściciela i użytkownika się zgadza. Na pewno istnieje jakiś sposób na eleganckie rozwiązanie tego problemu, tylko nie potrafię go znaleźć. Czy ktoś wskaże mi najlepszą drogę?

Ja bym po prostu zrobił selecta bazodanowego. Da się, nie trzeba adnotacji do tego nawet :)

W czym jest konkretnie problem? Jeśli taki jest schemat bazy, to nie widzę innego wyjścia jak napisanie SQL query (żeby nie ładować encji do pamięci). Innym rozwiązaniem byłaby denormalizacja, czyli trzymanie tego idka w pierwszej tabeli, jeśli JPA ani czysty SQL nie będą Ok. To jednak wymaga większej koordynacji na poziomie aplikacji.

1. Wyrzucamy Hibernate i JPA
2. Piszemy query które zwraca to co nam potrzebne
3. Wrzucamy tam jeszcze sprytnie caffeine i robimy sobie cache jeśli wiemy że ta informacja się często nie zmienia a jest odczytywana często
4. Profit!

Uwielbiam jak ludzie lubią sobie utrudniać życie, ładują do projektu te wszystkie magiczne frameworki a potem dzielnie walczą z problemami, które wynikają właśnie z technologii której używają.

Joinowanie 4 tabel będzie niezbyt wydajne zarówno z ładowaniem tych encji przez Hibernate jak i bez ;)

Jak dokładnie wygląda schemat tej bazy (a przynajmniej te 4 tabele), o ile to nie tajemnica? Może da się przenieść ten ID bliżej danych, a jeśli nie to dać sobie spokój z restrykcyjną denormalizacją i trzymać go w dwóch miejscach - tam, gdzie jest potrzebny. Nie musisz od razu rozmontowywać wszystkiego.

A może po prostu te dane, które trzymasz nie pasują do modelu relacyjnego, i zamiast SQLowych tabelek potrzebujesz czegoś zupełnie innego - bazy dokumentowej, grafowej?

@Shalom jeśli dane nie zmieniają się to pewnie nawet materialized view dałoby radę, przeliczysz raz po stronie bazy i nie potrzebujesz dokładać kolejnego klocka w postaci Caffeine ;)

Warto sprecyzować co to znaczy właściciel encji - jeśli to np user który stworzył dany wiersz bazodanowy, to zapewne w tej tabeli masz kolumnę createdBy i viola. Jeżeli z kolei chodzi o to, że pewni użytkownicy mają dostęp ogólnie do tabeli X (a nie że do poszczególnych wierszy), to wtedy możliwe że chodzi o coś nazywane multi-tenancy, albo po prostu kolejna kolumna w każdej tabelce tenantId.