ER в реляционную модель: что происходит, когда у подкласса есть собственный ПК?

Во-первых, как указал Джим Л., Employee является подтипом Person, а не наоборот!

Концептуально, если тип объекта B является подтипом/подклассом A, он наследует его свойства, методы и ограничения, включая его уникальные идентификаторы/ключи, но не обязательно его стандартный идентификатор ("PK"), поскольку PK является произвольным выбором обязательный ключ, так что это не чисто концептуальная/логическая функция, а скорее пользовательская декларация/соглашение.

Ключи, как и ограничения, наследуются, но не ПК!

Следовательно, даже если подтип Employee наследует обязательный ключ person_id, вам не нужно выбирать его в качестве своего PK. Поскольку у Employee есть еще один обязательный ключ, employee_id, вы можете выбрать его в качестве PK (и, как указано reaanb, в этом примере нет необходимости в каком-либо составном PK).

Составной PK — плохая идея, поскольку он позволяет записывать несколько строк с одним и тем же employee_id и разными person_id (или с одним и тем же person_id и разными employee_id). Вместо этого сделайте employee_id PK и person_id отдельным уникальным ключом.

Концептуально, когда подтип имеет свою собственную идентичность, его можно рассматривать как отдельный набор сущностей, имеющий отношение к родительскому набору сущностей, а не как подтип. Я бы не стал использовать нотацию подтипа в диаграмме EER для представления этих ситуаций.

Наконец, избегайте использования терминологии ООП (подклассы, наследование) при обсуждении моделирования данных. ООП предназначено для декомпозиции систем с точки зрения взаимодействующих конечных автоматов, и его не следует смешивать с иерархическими, сетевыми, объектно-связными или реляционными моделями данных.