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

Question

Концептуальная модель| Я не смог найти ни одного примера подкласса с его собственным PK. Я понимаю, что первичный ключ person_id унаследован от суперкласса, но я не знаю, объединяется ли он с подклассом PK, employee_id, для создания составного PK в реляционной модели подкласса.

В принципе, что правильно?

Сотрудник (employee_id, person_id, имя, зарплата)

ИЛИ ЖЕ

Сотрудник (employee_id, person_id, имя, зарплата)

Предполагая, что иерархия не является обязательной.

Это всего лишь быстрый пример, чтобы помочь мне понять процесс, поэтому не беспокойтесь о достоинстве концептуальной модели.

Answer 1

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

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

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

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

Answer 2

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

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

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