Вопрос моделирования ER

Question

У меня следующий вопрос:

Используя только двоичные отношения, создайте диаграмму отношений сущностей для следующего описания. Включите метки сущностей, поля первичных ключей, метки отношений и кратности отношений.

"Компания управляет несколькими автосервисами по ремонту и обслуживанию автомобилей, каждый из которых имеет свой уникальный номер (gargNo). Когда владелец автомобиля связывается с гаражом, его данные записываются, и им назначается владелец No. Их автомобиль также регистрируется в этом гараже и присваивается идентификационный номер (carNo). Владелец может владеть одним или несколькими автомобилями, но автомобиль может быть зарегистрирован только в одном гараже. Когда автомобиль забронирован в гараж, для него составляется план обслуживания. быть уникальным для конкретного автомобиля (например, вылечить скрип от стеклоочистителей), или он может быть использован для многих автомобилей (например, стандартное обслуживание 60000 миль). Любой план обслуживания может состоять из одной или нескольких операций (замена масла, демонтаж электродвигатель стеклоочистителя и т. д.) Каждый тип операции в плане обслуживания имеет уникальный номер (операция №).

Это мой ответ:

Для всех ветеранов баз данных это выглядит нормально?

Также были бы оценены любые другие комментарии обратной связи...

НЕ РАБОТАЕТ

РЕДАКТИРОВАТЬ - Почему люди продолжают редактировать сообщения, но не вносят изменений?

Answer 1

Основываясь исключительно на данных требованиях, не обращая внимания на все возможные сложности в реальном мире (например, что происходит, когда владелец переводит свой автосервис из одного гаража в другой):

Я бы покинул компанию. Там только одна когда-либо упоминалась, и нет никаких признаков того, что мы записываем данные для нескольких компаний.

Отношения между владельцем автомобиля и гаражом - через автомобиль. Нет прямой связи между владельцем автомобиля и гаражом. (Учитывая наличие нескольких гаражей, обеспечение того, чтобы один и тот же владелец нескольких автомобилей появлялся в системе один раз, будет сложно реализовать.)

Отношения между машиной и гаражом, возможно, должны быть "зарегистрированы в". Строгое чтение подразумевает, что автомобиль связывается с гаражом при контакте с владельцем, а не при доставке для обслуживания.

Вам нужен объект ServicePlanType [SPT]. Большинство SPT предопределено, и несколько автомобилей будут использовать данный SPT (60000 миль). Дополнительные SPT будут добавлены, если, когда и по мере необходимости. Можно было бы привести аргумент в пользу подтипа "стандартный" или "специальный", но я думаю, что они будут настолько похожи (на основе операций), что этого не требуется. Затем:

• План обслуживания относится к одному автомобилю и к одному типу плана обслуживания
• План обслуживания относится к одному типу плана обслуживания
• Тип плана обслуживания относится к нулю или большему количеству планов обслуживания (список стандартных планов)
• Тип тарифного плана относится к одной или нескольким операциям (все операции должны быть определены)

Операция может относиться к нулю или большему количеству типов тарифных планов. Учитывая потребность в специальных тарифных планах, может возникнуть необходимость в операциях, которые изначально не принадлежат какому-либо заданному набору сервисных планов. (Это или они добавляются по мере необходимости, что может быть приемлемо. Песчанки моей сестры однажды сбежали по дороге домой из школы, и им пришлось разобрать часть машины, чтобы вытащить ее. Никаких обвинений, возможно, у них не было "Извлекай песчанку" в своей базе данных.) (Я так не придумываю.)

Я бы не связывал тип плана обслуживания или работы с гаражом. Предположительно, если один гараж компании может сделать это, они все должны быть в состоянии сделать это, даже специальные.

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

Answer 2

Основываясь на постановке задачи, я пришел к следующему:

Я использовал общие поля, такие как Address, OwnerDetails и т. Д. Для простоты.

Изменить: Многие ко многим между Планом обслуживания и Операцией объяснил:

Операция "Замените масло", входит в планы обслуживания "Техническое обслуживание 30К", "Техническое обслуживание 60К" и "Замена масла".

Конечно, в плане обслуживания "Техническое обслуживание 30K" и "Техническое обслуживание 60K" предусмотрено несколько операций (замена масла, заправка тормозной жидкости, проверка давления в шинах, балансировка и поворот шин).

Следовательно, связь между Планом обслуживания и Операцией является отношением "многие ко многим".

Эта структура является шаблоном, который затем может быть применен к экземпляру VehicleService.