Сценарий концептуального моделирования

Правилен ли мой подход к использованию стольких обобщений? Есть ли другой способ?

Наверняка есть и другие способы. В обобщениях нет ничего плохого, хотя редко можно увидеть их так много в одной модели. Это не означает, что это неправильно, правильно или неправильно, в данном случае зависит от того, насколько хорошо ваша модель представляет бизнес-требования.

В приведенном выше описании первое предложение, выделенное курсивом и полужирным шрифтом, говорит о том, что существует определенный «необязательный набор возможностей». Должны ли эти атрибуты быть добавлены к объекту «Отель», «Хостел» и «B&B» или к обобщенному объекту «Размещение»?

Звучит как общее требование, я бы связал его с проживанием.

Обратите внимание, что в данном сценарии есть два варианта использования «Объекта» — для мест, которые можно посетить/просмотреть, и для характеристик комнат. Я бы рекомендовал переименовать один из терминов, чтобы избежать путаницы.

Во втором предложении, которое выделено, следует ли добавить стоимость отеля, общежития и пансиона, как это сделал я? В противном случае, как я должен действовать в моделировании этого?

Вы можете сделать это так же, как вы это сделали, или добавить атрибут стоимости (и индикатор на человека/комнату) в Размещение.

Вы должны стараться избегать смешивания доменов в атрибуте. Под этим я подразумеваю, что все возможные значения должны быть одного типа и логически взаимозаменяемыми. Распространенной ситуацией является смешивание значений разных валют в одном атрибуте или столбце значений в таблицах EAV. Такие конструкции имеют тенденцию к увеличению сложности.

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

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

Не вижу смысла перечислять его отдельно для каждой забегаловки. Атрибуты, отношения и ограничения, общие для всех подтипов, должны быть связаны с супертипом.

Для сравнения вот моя модель. Я сделал это до того, как посмотрел на вас, поэтому здесь нужен совсем другой подход.

Некоторые примечания:

• Я переименовал удобства в комнатах в особенности
• Размещение и столовая являются необязательными непересекающимися подтипами Facility. Это означает, что у нас могут быть объекты, не принадлежащие ни к одному из подтипов, что позволяет мне обрабатывать обзоры других видов достопримечательностей, используя ту же структуру.
• Посещение — это троичная связь, определяемая Пользователем, Поездкой и Объектом. Таким образом, каждое Посещение должно относиться к Поездке, даже если это Поездка с одним посещением. Положительным моментом является то, что несколько Пользователей могут участвовать в одной и той же Поездке.
• Пользователи могут Посетить Объект более одного раза в разных Поездках, но не более одного раза за Поездку. Мы могли бы преобразовать Visit из отношения в сущность с суррогатным ключом, чтобы преодолеть это.

Я надеюсь, что это поможет, дайте мне знать, если я должен что-то уточнить.