Суть вопроса.

Есть абстрактный ВУЗ.
В БД хранятся
Личные данные о сотрудниках
Данные оформления на работу каждого сотрудника.

Условия следующие:
1. Один сотрудник может оформляться произвольное количество раз (на практике 1-2-3 раза, но это сути не меняет).
2. Оформиться сотрудник может штатным, внутренним внешним совместителем и на почасовую оплату.
3. У одного сотрудника может быть только 1 основное место работы. Остальные таковыми не считаются.

Делаем схему:
http://lh3.ggpht.com/_Em0I3j8C1hE/SY_1W_WUwNI/AAAAAAAAAEg/P5lQrPte2es/test0003.jpg

CT_PERSON - личная информация о сотруднике.

TS_EMPLOYEE - информацио про оформление на работу.
Rate - ставка (1, 0.5, 1,25 и т.д. )
Main_work_place - признак того, что это основное мест оработы (да/нет)

TS_DICT_JOB - список должностей (асистент, доцент и т.д.)
TS_DICT_ENTER_TYPE - типы поступления на работу (штат, внештат, почасовка)
Эти таблицы вяжутся с TS_EMPLOYEE внешними ключами.

Мне очень не нравится неоднозначность, которая будет возникать при оформлении на работу почсовых сотрудников, т.к. они работают не на ставку, а определённое количество часов, что логически не очень сильно вкладывается в общую схему.

Немного подумав вспомнил про такую штуку, как подтипы сущностей.

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

Глядя сверху на ту схему которая есть сейчас - у Employee можно выделить 2 подтипа сущностей Условно говоря - Почасовики и Ставочники.
У почасовиков дополнительный атрибут - часы
У ставочников - ставка.
При этом из Employee ставка вообще изымается.

В принципе при этом неоднозначностей уже не будет, но коробит сложность выполнения запросов и операций DML. Вероятно придётся писать представление и триггеры DML над чем не очень хочется сохнуть.

Получается схема:
http://lh4.ggpht.com/_Em0I3j8C1hE/SY_1WtReEXI/AAAAAAAAAEY/U3J6yvt44uM/test0002.jpg

Потом, ещё немного подумав, прихожу к выводу, что в принципе то можно обойтись и первой схемой, потому как почасовиков можно оформлять просто, описывая в TS_DICT_ENTER_TYPE тип поступления на работу как почасовка и в ставку записывая количество часов.

Хочется простоты. Но ещё больше – правильности. Пока что продолжаю думать…

Какая их схем более предпочтительно с точки зрения быстродействия, а также удобства работы с ней?