Партнер и Личный помощник являются подклассами, и согласно моей диаграмме существует обязательное отношение 1..1.Является ли «законным» иметь определенные отношения между подклассами?
Совершенно верно иметь отношения между подтипами и / или супертипами.
Я использовал опционально,или отношения для подклассов персонала, что, на мой взгляд, хорошо, так как сотрудник не может быть одновременно ни одной из ролей.Единственная пропущенная роль в качестве подкласса - это роль «аудитора».Если бы я включил это, было бы «необязательно» или «изменилось бы» на «обязательное» или «, поскольку показаны все возможные варианты, и сотрудник должен играть одну из этих четырех ролей?»
Это звучитправильный.Я предпочел бы использовать термин «дизъюнкт», чем «или».
Между Annual_audit и Staff у меня есть сущность отношений (я мог бы назвать это чем-то неправильным).Это правильный способ показать отношения?Я также пытался использовать троичные отношения, но в конечном итоге несколько раз возвращался назад и вперед.
В модели ER нет такого понятия, как «сущность отношения».Возможно, вы думаете об ассоциативных объектах, которые используются в сетевой модели данных для разложения отношений «многие ко многим».Модель ER поддерживает отношения «многие ко многим» напрямую и не нуждается в ассоциативных объектах для этой цели, хотя они по-прежнему имеют место в подчинении отношений другим отношениям.
Annual_audit в вашей диаграмме является слабымотношение сущности.Staff - это регулярное отношение сущности.Между ними Charges time, которое является отношением многих ко многим.Обозначение достаточно читабельно, если вы знаете понятия.Тем не менее, обозначения Чена будут представлять концепции более четко, в то время как диаграммы, похожие на схемы таблиц, лучше работают для физических моделей.
Одной из проблем в вашей диаграмме являются стрелки.Они не соответствуют показателям кардинальности.Индикаторы кардинальности выглядят правильно, но наконечники стрел в основном не указывают в значимых направлениях.Я бы удалил их все, кроме одного, указывающего из подтипов на Staff.
Наконец, я предлагаю вам не смешивать концепции и терминологию ООП и моделирования данных.Моделирование данных предназначено для представления знаний, ООП - для систем моделирования.Используйте «подтип» для подтипов / подмножеств наборов сущностей, «подклассы» для производных классов в контексте программирования.