Closed RomanovskiyIlya closed 1 year ago
Не придумал пока, как на схеме показать человека, который будет администрировать каталог.
Покупатель может оставить несколько заявок, каждая из которых включает в себя конкретную модель или вообще комплектацию одного из брендов автомобилей.
Появилась пара идей. Можно сделать сущность не "покупатели" а "пользователи" с атрибутом тип пользователя(клиент/админ) и отнести его в сущности не "заявки" к какой-нибудь средней между заявками и карточками машин. можно назвать "примеры автомобилей". Или второй вариант создать сущность "администраторы" и отнести его к брендам например. Только у меня в описании предметной область нет упоминаний про администраторов
вряд ли покупатель хочет оставить заявку на тойоту. У тебя на схеме именно так
чтобы тебе было легче определиться с сущностями и атрибутами, попробуй привести примеры. Покупатели: например Иванов И.И., телефон 2323-2342, адрес овлджаопв, логин авпвыап, пароль **, емейл 34234. Бренды (производители?), например, Тойота и так далее
Покупатель может оставить несколько заявок, каждая из которых включает в себя конкретную модель или вообще комплектацию одного из брендов автомобилей.
это в описание предметной области или требований к системе
человека, который будет администрировать каталог.
не уверен, что это должен быть один человек. А, если на него кирпич упадет? А как узнать, что конкретный менеджер накосил в каталоге (цену неправильно указал, например)
Только у меня в описании предметной область нет упоминаний про администраторов
их там и не должно быть. А в требованиях к системе - вполне
Можно сделать сущность не "покупатели" а "пользователи"
не лучший вариант - у них слишком разные атрибуты и связи кмк
Сущность "примеры" это что-то на подобии карточек товара. Место где собирается вся информация про модель.
Разве у комплектации есть собственное название. Еще раз предлагаю - приведи примеры - что может заказывать человек
Разве у комплектации может быть несколько наборов характеристик? Три клиренса, например? И, если да, то что заказывает человек? Пример в студию!
Название сущности "примеры" никуда не годится.
Обращаю внимание, что все сущности, связи и атрибуты должны быть определены и описаны в описании предметной области и требованиях к системе. У тебя это не так
Выглядит уже правдоподобнее, согласись!
Ты считаешь "Заказ: из Кореи" это атрибут производителя?
Список опций комплектации - это полный набор атрибутов?
А, у автомобилей совсем-совсем атрибутов нет?
А, где атрибуты с ценой и предполагаемым временем доставки?
Список опций комплектации - это полный набор атрибутов?
Пока нет. Буду дополнять.
Еще пока думаю в какой сущность должен быть атрибут "Страна покупки". От того из какой страны привозят автомобиль зависят и сроки доставки и некоторые характеристики.
Правильно поставленный вопрос уже содержит ответ. ты сам себе ответил -
От того из какой страны привозят автомобиль зависят и сроки доставки и некоторые характеристики.
Страна покупки, это, очевидно, не атрибут, а сущность
а если я хочу еще фото добавить? не будет слишком много?
а если я хочу еще фото добавить? не будет слишком много?
не будет. Особенно, если фото одно на авто или комплектацию и хранится на диске. Тогда это просто атрибут-ссылка. Да и как сущность это революции не сделает
Вопрос - как связаны администраторы и автомобили? Не помню в описании предметной области
Вопрос - как связаны администраторы и автомобили? Не помню в описании предметной области
Я понял. Это как в случае с врачами и пациентами. Администратор может добавлять и изменять много автомобилей, но и один автомобиль могут изменять несколько администраторов. Получается многие ко многим
Я еще подумал, что можно объединить сущности производителей и моделей (перенести название производителя и страну производителя в модели), тк я не знаю о моделях, которые выпускают разные производители с одним названием.
Я еще подумал, что можно объединить сущности производителей и моделей (перенести название производителя и страну производителя в модели), тк я не знаю о моделях, которые выпускают разные производители с одним названием.
не уверен, что это хороший вариант, так как появляется возможность записать фольксваген, как фольксваген, VW или volkswagen, не говоря, уж, о китайских транскрипциях
Логическая схема
несколько странно, что изменения не содержат атрибутов, ну да ладно
Более странно, что комплектация и автомобиль связаны отношением 1:1. Почему бы тогда им не стать одной сущностью?
Я сильно сомневаюсь, что идентичные комплектации отличающиеся только наличием парктроников будут обладать разным набором фотографий
неплохо. я бы к фото опциональные подписи добавил а к заявке что-то вроде статуса, чтобы бедные манагеры, не пересматривали прошлогодние заявки, которые уже давно выполнены или отвергнуты
А что значит опциональные подписи? Как дополнительная информация?
необязательные, сорри за жаргон
Физическая Create Table Brands( Brand_name varchar(30) PRIMARY KEY, Brand_country varchar(30) )
CREATE TABLE Сountry_of_purchase( Сountry varchar(30) PRIMARY KEY )
CREATE TABLE Models( Model_name varchar(30) PRIMARY KEY, Release_year INT, Brand_name varchar(30), Сountry varchar(30), FOREIGN KEY (Brand_name) REFERENCES Brands (Brand_name), FOREIGN KEY (Сountry) REFERENCES Сountry_of_purchase (Сountry) )
CREATE TABLE Users( Phone_number varchar(11) PRIMARY KEY, Firstname varchar(30), Lastname varchar(30), Patronymic varchar(30), User_pasword varchar(64) )
CREATE TABLE Admins( Login varchar(30) PRIMARY KEY, Firstname varchar(30), Lastname varchar(30), Patronymic varchar(30), Admin_pasword varchar(64) )
CREATE TABLE Сonfigurations( Сonfiguration_ID INT PRIMARY KEY, Model_name varchar(30), Сonfiguration_name varchar(30), Engine_volume DECIMAL(2, 1), Engine_type varchar(30), Engien_Power INT, Transmission varchar(30), Drive_type varchar(30), Suspension_type varchar(60), Clearance INT, Car_length INT, Car_width INT, Car_height INT, Weight INT, Luke BOOLEAN, Panoramic_view BOOLEAN, Wheel_heating BOOLEAN, Seat_heating BOOLEAN, Cruise_control BOOLEAN, Climate_control BOOLEAN, Headlight_type varchar(30), Interior_lighting BOOLEAN, Parktronics BOOLEAN, Camera_type varchar(30), Price INT,
FOREIGN KEY (Model_name) REFERENCES models (Model_name)
)
CREATE TABLE Applications( Application_ID INT PRIMARY KEY, Brand_name varchar(30), Model_name varchar(30), Сonfiguration_ID INT, Phone_number varchar(11), Сountry varchar(30), Applications_Status varchar(30), FOREIGN KEY (Сonfiguration_ID) REFERENCES Сonfigurations (Сonfiguration_ID), FOREIGN KEY (Phone_number) REFERENCES Users (Phone_number), FOREIGN KEY (Сountry) REFERENCES Сountry_of_purchase (Сountry), FOREIGN KEY (Brand_name) REFERENCES Brands (Brand_name), FOREIGN KEY (Model_name) REFERENCES Models (Model_name) )
CREATE TABLE Сhanges( Сhange_ID INT PRIMARY KEY, Сonfiguration_ID INT, Login varchar(30), FOREIGN KEY (Сonfiguration_ID) REFERENCES Сonfigurations (Сonfiguration_ID), FOREIGN KEY (Login) REFERENCES Admins (Login) )
CREATE TABLE Photos( Photo_ID INT PRIMARY KEY, Model_name varchar(30), Path varchar(255), FOREIGN KEY (Model_name) REFERENCES Models (Model_name) )
все это очень мило, но лучше завести отдельные issues для логической и физической схем и перенести все неужное здесь туда