Мы можем создавать отношения, соответствующие только подкатегориям или только суперкатегории. Для последнего варианта мы можем сформулировать правило, например: 'Если в интерпретационной модели данных идентифицированная когнитивная категория CI с ассоциацией специализации, такой, что когнитивная категория C2 является подтипом C I, то в проекте хранения данных будет существовать отношение R I вместе с некоторым атрибутом RI-id, который действует как первичный ключ для этого отношения, и RI должен иметь в качестве неключевого атрибута индикатор типа, причем "C2" является допустимым значением для этого индикатора типа". В соответствии с этим вариантом реляционный эквивалент рис. 2 будет иметь вид: EMPLOYE! {Employee-id, Employee-type, ~,_}.
В конкретных условиях это может быть вполне приемлемым преобразованием, но поскольку мы ничего не знаем о том, как будет использоваться схема в реальном мире, мы должны признать его неудовлетворительным. Она не содержит отношений, соответствующих подтипам, поэтому существование подтипов и их сущность скрыты в данных, а не явно выражены в структуре схемы. Мы можем зафиксировать, что конкретный сотрудник работает на полную ставку или по контракту, записав соответствующие значения в атрибут "тип сотрудника", но мы можем зафиксировать только текущий статус сотрудника; если сотрудник, работающий по контракту, станет работать на полную ставку, мы можем изменить индикатор типа, но при этом потеряем все записи о том, что он когда-либо работал по контракту. Если же для двух типов сотрудников необходимо записать различные факты, то мы будем вынуждены выделить место для их хранения в отношении 'employee', что может привести к появлению большого количества нулевых значений.
Вторая возможность заключается в следующем: "Если в интерпретационной модели данных существует идентифицированная когнитивная категория CI с ассоциацией специализации, такой, что когнитивная категория C2 является подтипом C I, то в проекте хранения данных будет присутствовать отношение R I вместе с некоторым атрибутом R l-id, который выступает в качестве первичного ключа для этого отношения, и отношение R2, имеющее в качестве первичного ключа ключ RI-id". Следуя этому правилу, реляционный эквивалент рис. 2 будет выглядеть следующим образом: EMPLOYEE {Employee-id, _, _ }, PERMANENHMPL.OYFE {Employee-id, _, -l, CONTRACT-EMPLOYE!- {Employee-id, _, _}
Это реляционное выражение иерархии обобщений (или отношений IS-A), рекомендуемое в стандартных текстах, таких как Kroenke (1992) или Batini et al (1992). Оно, безусловно, лучше, поскольку позволяет фиксировать различные факты о сотрудниках, работающих по контракту и на полную ставку, в отдельных отношениях, а общие данные хранить в отношении "сотрудник". Однако это все равно не позволяет фиксировать изменения в статусе занятости с течением времени. Это можно исправить, изменив правило следующим образом: "Если в интерпретационной модели данных существует идентифицированная когнитивная категория C I с ассоциацией специализации, такой, что когнитивная категория C2 является подтипом C I, то в проекте хранения данных будет присутствовать отношение RI вместе с некоторым атрибутом R I-id, который выступает в качестве первичного ключа для этого отношения, и отношение R2, имеющее в качестве первичного ключа составной ключ, состоящий из первичного ключаRI, соединенного с временным идентификатором присвоения". Это дает реляционный эквивалент:
EMPLOY!:! {Employee-id, _, _ }, PERMANENT-EMPLOYE! (Employee-id, Timedate-status -commences, _, _}, CONTRACT-EMPLOYFE {Employee-id, Timedate-status -commences, _,_}
Это позволяет вести дискретный учет даже при изменении трудового статуса сотрудника и хранить различные атрибуты для каждой подкатегории. Но даже в этом случае мы остаемся со сложными ключами для отношений, и на практике для доступа к данным нам потребуется установить ряд альтернативных ключей; например, мы не захотим указывать дату и время назначения сотрудника на полную ставку каждый раз, когда нам нужно получить сведения о нем. И, как это справедливо и для других альтернатив, такие ограничения, как возможность отчисления пенсионных взносов только для сотрудников, работающих полный рабочий день, должны быть наложены программно, а не структурой самих отношений.
ЗАКЛЮЧЕНИЕ
