Не работает в таком виде, т.к. требует чтобы в OneToOne targetEntity была сущность. Если туда поставить DBObject, то работает, но промежуточный Subject не принимает.

Есть идеи как реализовать без создания дополнительной избыточной таблицы для Subject?

Kachalovpublexus,
а это "targetEntity = Subject.class" зачем?
Чтобы обозначить, что tenant - это Person или Organization.
Если установить подставить targetEntity = DBObject.class, то туда можно сохранить, например, Adress, что является логически неверным.

Petro123publexus,
Зачем вам наследование, если его в базе нету?
Зачем вам один к одному, если в базе в этом нет смысла?
Если у вас адрес Сущность важная по бизнесу, то делаете таблой.
Если нет, то это поле у класса юзверь.
Imho

1. Условное наследование есть и в базе в виде каскадных таблиц: DBObject - таблица с общими данными для всех типов объектов, таблица Person, связанная по основному ключу с DBObject с параметрами и т.д.
2. На самом деле там ManyToOne, просто с другой стороны не будет референса, поэтому сделано для упрощения.
3. Все неабстрактные сущности являются таблицами.

Petro123,

Причем тут "СУБД ничего не знает о наследовании"?

Я спрашивал о том, как это реализовать в Java.

А наследование в приведенном примере необходимо по модели данных и бизнес-логике. Потому что необходимо оперировать так называемыми суперсущностями (абстрактными классами сущностями являющихся суперклассами конечных сущностей), как например ВDObject или Subject.

Например, по адресу может находиться как физ.лицо так и организация. Провайдер данных на основе id и DiscriminantValue соберет сущность необходимого типа из нескольких таблиц. Если не вводить Subject, а указать тип резидента DBObject, то туда можно запихнуть любой объект, наследованный от DBObject (например тот же адрес), что неверно по логике, т.к. там должны быть только физ.лицо или организация. Поэтому и вводиться Subject.

Помимо, того при запросе суперсущности ВDObject провайдер Hibernate вместо того, чтобы сначала вытянуть из базы DiscriminantValue, а затем собственно данные из необходимых таблиц, вместо этого он просто джойнит все таблицы иерархии в одном громадном запросе (выполняя обращения к заведомо ненужным таблицам). А как результат введения Subject предполагается, что в запросе будут только таблицы данных физ.лица так и организации.

[quot Petro123]publexusзакон ОРМ одна сущность это таблица.

Ну не знаю, может быть это какой-то старославянский языческий закон...

У нас успешно используется Inheritance, ElementCollection и одна сущность, за исключением разве что самых простых, как правило, состоит из целого набора таблиц. В реляционных базах всегда примерно так и бывает. Может вы путаете с каким-то другим типом баз, например документоориентированной MongoDB.

[quot Petro123]publexusТ.е. идете от субд, орм, хибер, jpa. А не от того что хочет java.

И с этим не согласен.
Надо идти от требуемой бизнес модели к объектной Java модели, и лишь затем на основе требуемых для хранения данных к структуре БД. Это идеальный вариант, но, иногда, на этапе разработки Java модели требуется учитывать некоторые компромиссы, связанные с особенностью конкретной СУБД или производительностью доступа к данным.