Какое отношение имеют паттерны Фаулера для иерархии объектов к отображению СУБД и стратегиям наследования Hibernate?

Question

Я прочитал шаблоны Фаулера, которые позволяют решить, как отобразить иерархию объектов в СУБД, и нашел 3 варианта.

Допустим, у нас есть следующая иерархия

absract class Parent{...}

class Child extends Parent{....}

class GrandChild extends Child {....}

1. Наследование таблиц классов - у нас будет 3 таблицы: fot Parent и Child и GrandChild
2. Наследование отдельных таблиц - у нас будет одна таблица со всеми полямив иерархии (для Parent и Child и GrandChild в этом случае)
3. Наследование бетонной таблицы - у нас будут таблицы только для конкретных классов - для Child и GrandChild в этом случае

Но в соответствии со статьями, которые я прочитал (например, https://www.baeldung.com/hibernate-inheritance) есть 4 варианта:

1. MappedSuperclass - родительские классы, не могут быть сущностями
2. Single Table - сущности из разных классов с общим предком помещаются в одну таблицу
3. Joined Table - у каждого класса есть своя таблица, и запрос сущности подкласса требует объединения таблиц
4. Table-Per-Class - все свойствакласса, находятся в его таблице, поэтому соединение не требуется

Очевидно, что Flowler Наследование одной таблицы соответствует Single Table из Hibernate

Похож на Flowler's Наследование бетонной таблицы соответствует Table-Per-Class и MappedSuperclass от Hibernate

И теперь у нас есть Flowler's Наследование таблицы классов с одной стороны и Joined Table с другой (Hibernate)side.

Как вы можете видеть, у нас есть 2 режима гибернации, соответствующих наследованию бетонных таблиц только Flowler . Не могли бы вы объяснить разницу между этими стратегиями?