Альтернативные модели сущностей и их отражение в проекте
Рассмотренные соглашения по моделированию не исключают применение различных способов построения моделей. Рассмотрим три таких альтернативных способа с точки зрения их реализации в проекте.
Рисунок F-6. Альтернатива 1

Рисунок F-7. Альтернатива 2

Более предпочтительная модель, поскольку в ней ощутимо присутствие подтипов A1 и A2. Теперь при реализации внешних ключей нет необходимости думать о том, на какую "родительскую" сущность указывает связь.
Рисунок F-8. Альтернатива 3

Тоже более предпочтительна по сравнению с первой альтернативой, поскольку уникальный идентификатор D может использоваться как для B, так и для C. Разумеется, все это в том случае, если супертип D действительно существует.
Альтернативы 2 и 3 дают нам возможность проверки существования понятий, обозначаемых подтипами A1 и A2 (с учетом их атрибутов/связей и функций) и супертипом D (с учетом его атрибутов и т. п.).