Базы данных

Представление специализации в виде отдельных таблиц для суперкласса и для каждого подкласса


В этой стратегии подкласс трактуется как слабый класс сущностей, а в роли его определяющего типа связи служит его специализация, как для таблиц HourlyEmployee и SalariedEmployee на 4.13. Атрибут ssn является внешним ключом класса Employee и образует ключ для каждого из этих подклассов. Поскольку специализация всегда имеет тип “один к одному”, для образования ключей подклассов не требуется дискриминатора. База данных BigHit Video содержит таблицы как для почасовиков, так и для штатных служащих.

Вторая стратегия, как показано на 4.14, создает единый класс со всеми атрибутами, включая определяющий атрибут. Для доступа ко всем атрибутам одного объекта требуется доступ к строке из таблицы, при этом не относящиеся к делу атрибуты игнорируются.

Employee; (ssn, lastName, firstName, address, balance, wageType, hourlyRate, weeklyPayRate, vacationLeaveHours, sickLeaveHours)

Атрибут объекта имеет значение non-null (не пусто) только в том случае, когда это атрибут действительного типа объекта. Атрибут почасовика (hourlyRate) будет иметь значение non-null только в том случае, если атрибут wageType имеет значение “hourly”. Атрибуты штатного сотрудника (weeklyPayRate, vacationLeaveHours, sickLeaveHours) будут иметь значение non-null только тогда, когда атрибут wageType имеет значение “salaried”.

Эта стратегия привносит некоторые проблемы, в основном потому, что она в значительной мере полагается на значения null и делает членство в подклассе несколько неопределенным. В примере на 4.14 для установления факта членства сущности в подклассе используется атрибут wageType. Предположим, что этот атрибут пропущен. Известно, что сотрудник оплачивается на почасовой основе, если значение атрибута hourlyRate не пусто (non-null), но что означает ситуация, при которой значение атрибута hourlyRate пусто (null)? Может быть, размер почасовой оплаты не был введен или он по каким-либо причинам неизвестен? Оказывается, что не всегда можно определить членство сущности в том или ином подклассе, основываясь лишь на значениях null (non-null).

Третья стратегия представления специализации в виде таблиц во многом похсйка на способ представления наследования в объектно-ориентированных языках. Как видно из 4.15, отсутствует таблица для суперкласса. Вместо этого, атрибуты суперкласса присутствуют в таблицах каждого из подклассов. Каждый объект принадлежит единственному подклассу и содержит все свои атрибуты в одной таблице. Для доступа ко всем объектам суперкласса (Employee) требуется доступ к атрибутам служащих в обеих таблицах.

HourlyEmployee: (ssn, lastName, firstName, address, balance, wageType, hourlyRate)

SalariedEmployee: (ssn, lastName, firstName, address, balance, wageType, weeklyPayRate, vacationLeaveHours, sickLeaveHours)

Комментарии закрыты