Здравствуйте, помогите, пожалуйста, разобраться, на других форумах не могут помочь, неужели настолько сложные вещи описываю, непонятно:
Составляю базу данных для пиццерии (пользователи могут на сайте оформлять заказы), составил первую концептуальную модель (ER диаграмма),
1) по заданию должно быть хотя-бы 5 основных сущностей не учитывая "слабые" и ассоциации (судя по всему "сильных") и хотя-бы одна "слабая" сущность, в интернете прочитал,
слабая считается сущность которая логически зависит от другой сущности
Но ведь всё от чего-то зависит, заказы зависят от клиентов (оформили или нет), если не будет заказов, то и не будет пицц/других продуктов, работников, транспортных средств, значит все сущности кроме "клиент" слабые?. Или имеется в виду, что работники, то есть люди, будут жить даже если не будет заказов? (найдут другую работу, например)

2) Должно быть хотя-бы 2 ассоциации, я правильно понимаю, это значит две связи многие-ко-многим?
Может ли быть в моём примере Ассоциативная сущность "использует" между "пицца"/"не пицца" и "ингредиенты"? ведь в одной пицце/не пицце(например, пирожное, а если в той же таблице будет бутылка "Кока-колы"? меняется ли тип связи?) может использоваться много ингредиентов и каждый из ингредиентов может использоваться во многих пиццах?
*Может ли быть ассоциация "готовка" между "заказы" и "работники" с атрибутом "статус заказа"?

3) Требуется использовать как минимум одну конструкцию наследования, я так понимаю, в моём случае, "не-пицца" может наследоваться от "пиццы" и можно добавить атрибут "срок годности"?

И в принципе, если можно, проверьте пожалуйста, правильно я расставил связи?
1. клиенты заказы, 1:M (один клиент может сделать много заказов)
2. сотрудники заказы, 1:M (один сотрудник может делать много заказов +, возможно, один заказ могут делать несколько сотрудников (натирать сыр, раскатывать тесто, добавлять начинку?))
3. заказы пицца/не пицца, 1:М (в одном заказе может быть много пицц, одна пицца может быть в нескольких заказах?)
4. Сотрудники транспорт, 1:M (один сотрудник может пользоваться разным транспортом (самокат, скутер, автомобиль) и одним транспортом могут пользоваться много сотрудников?)
5. Пицца/не пицца ингредиенты, M:M (в одной пицце может использоваться много ингредиентов, один ингредиент может использоваться во многих пиццах)

vaban4, Добавляю ER-диаграмму, но почему-то файл не появляется....

@PizzaPizza,
Лабораторная работа.
Я выбрал тему "пиццерия"
В концептуальной модели (ERD) должно быть 5 основных сущностей, минимум 1 слабая сущность, связи (1 : 1 , 1 : N, N : M, унарная), минимум две ассоциации, вот я и думаю, есть ли у меня на схеме 5 основных ("сильных") сущностей и какие могут быть ассоциации, уже 3 недели потратил, тяжёлая работа и никто объяснить/помочь не может....

White Owl, А какие могут быть ассоциации между моими сущностями?
Может ли быть сущность "готовка" между "заказы" и "работники" с атрибутом "статус заказа"? (0,n - 0,n)
И
"Использование" между "работники" и "транспорт" с атрибутами "начало","конец" (формат у обоих дата) (1-1, 1-1)?

У учителя есть пример,
между сущностями "студент" и "учебная программа" ассоциация "оценки" с атрибутами "оценка" и "дата" (0, n - 0,n)

White Owl,

А как заполнять "mandatory" (связь между Заказы и Продукты)?
Заказ -> продукты связь должна быть обязательной? так как каждый заказ обязательно содержит один или больше продуктов (иначе пустой заказ) и каждый продукт может содержаться или не содержаться в заказе?

White Owl,
С добавками не совсем понял.
Есть сущность "продукты" с атрибутами {ИД, Название, Количество(остаток), цена, номер добавки} и сущность "добавки" с атрибутами {ИД, Название, Количество} нужна ещё промежуточная таблица?
Допустим есть 6 видов добавок: {пицца с сыром, пицца с грибами, кола обычная, кола без сахара, кофе с молоком, кофе со сливками}
Для чего нужна ещё таблица групп? ведь если не нужна добавка (например в продуктах есть ещё готовые эклеры) можно написать 0 в значении атрибута "номер добавки"?

Может лучше сделать так?
Три таблицы
блюда 1 -> M состав блюда M -> 1 Ингредиенты
И отдельную таблицу "добавки" где будет кола, кофе, пирожные (например), то есть готовые блюда. И в заказе могут содержаться добавки (необязательно) и блюда (обязательно).

White Owl,
"можно будет заказывать пиццу с молоком, а кофе с грибами"

А следить за тем, чтобы таких ситуаций не возникало, разве не будет сайт/графический интерфейс, база данных ведь просто хранилище данных?

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

"разбиваешь добавки на группы: добавлять туда или сюда"

Не понимаю, как будет выглядеть сущность и какие будут атрибуты? какая связь будет с сущностью "продукты"?

Нашёл такую диаграмму, как она вам? может её стоит использовать + я добавлю наследование (физ/юр. лицо к "клиенты), унарная связь работники -> работники.
Чтобы добавить напитки нужно создать сущность "напитки" и соединить с сущностью "заказы"? (и связь будет такая же, как у "заказы" - "заказанные пиццы" 1-M ?)

fkfka2,

В чём смысл вашего сообщения? я делаю это задание уже 3 недели (каждый день читая разные сайты и внося изменения в диаграмму), похвастаться, что вы такой умный? так почему не написали ничего по существу?

На картинке, которую я прикрепил, изображена концептуальная модель или логическая? а то имеются внешние ключи + ref таблицы (кстати зачем они нужны?)

White Owl,
PizzaPizza,
Правильно ли составил диаграмму?

White Owl,
PizzaPizza,
Правильно ли составил диаграмму?

White Owl,

?

PizzaPizza,

?

PizzaPizza, Ассоциации пока не придумал + хочу проверить правильность того, что на данный момент есть. (Может связь неправильная, может ещё какие-то грубые ошибки)
Извините, что часто пишу, делаю это 3 недели и осталось 2 дня, а нужно доделать концептуальную схему, потом перевести в логическую, и физическую и проверить их.

PizzaPizza,
Этот пример я сам не понял, взял из презентации учителя, в разделе "пример наследования"

White Owl,
Здравствуйте,
Добавил ассоциации и подправил атрибуты, можете, пожалуйста, проверить? а то если начну генерировать логическую и физическую модель ошибка может пойти дальше.

Также,
1) связь между Заказами и Напитками/Пиццами должна быть M-M?
ведь в каждом заказе может быть много пицц/напитков и одни и те же пиццы/напитки могут быть во многих заказах?
2) лучше между Начинки и Пиццы сделать связь M-M, так как в одной пицце можно использовать разные начинки и одна начинка может использоваться во многих пиццах?
3) Ассоциация Комбо может существовать для упрощения создания акций и быстрого изменения её же? То есть, название "комбо" и стоимость (например, пицца с грибами+пицца с сыром на 200 рублей дешевле, чем, если покупать по отдельности)
4) Аналогично с ассоциацией "эксплуатирует", позволяет быстро узнать, когда и какой сотрудник начал/закончил пользоваться определённым транспортом?

Ennor Tiegael,
Прежде всего, это первая лабораторная работа по предмету базы данных :)

2) Клиенты - адреса у меня M-M, логика такая: у 1 клиента может быть много адресов (много квартир, дача и т.д.) и один адрес может быть закреплён за несколькими людьми (семья, родственники)

3) Про payments честно сам не понял, почему сущность соединена с "Клиенты", а не с "Заказы" (за основу была взята вот эта диаграмма

Ennor TiegaelВ любом случае, вам потребуется ссылка на метод платежа из заказов - либо напрямую как 1:М, либо через таблицу-связку
Имеется в виду нужно соединить таблицу Способ оплаты с таблицей Заказы связью 1-M? (а удалить связь между Способы оплаты и Клиенты надо?)

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

6) Да, должна быть М:М.
В одной пицце может быть много начинок и одна начинка может использоваться во многих пиццах.
Когда будет окончательно готова концептуальная модель, она будет преобразована в логическую и там должна будет появиться промежуточная таблица, где будет храниться ID пицц и ID начинка, как я понимаю.

Такая связь должна быть?
Я думал одним методом оплаты (наличные, банковский перевод) могут воспользоваться многие клиенты и один клиент может воспользоваться разными способами оплаты(сделал два заказа подряд, но один оплатил электронно, а второй оплатит при получении)

После изменений.

Ennor Tiegael,

Тогда можно объединить напитки и пиццы в общую таблицу "блюда"?

Вот такая логическая модель получается.

А вот в физической модели появились ошибки.

1) Заказа оплачиваются способами оплаты, а не наоборот.
2) Сотрудники используют транспорт, а не наоборот.
3) Клиенты размещают заказы, а не наоборот.

Ennor Tiegael,

авторв чем причина разделения позиций заказа на 2 таблицы?
Я уже объединил пиццы и напитки, чуть выше посмотрите, пожалуйста.

Ennor Tiegael,

Вы хотели написать "инвертировать связь Clients - Orders"? Так как со связью Clients - Addresses всё нормально, клиенты находятся по какому-то адресу.
Или можно оставить так, ведь Заказы размещают клиенты или на схеме получается, что заказы размещают клиентов?

У меня получается Заказы ссылается Клиенты, который ссылается на Адреса, так нельзя делать?

Ennor Tiegael,

И это нормально, что стрелка от Заказы показывает на Клиенты в физической модели?

Также, если инвертировать Clients - Addresses то получится Addresses Located Clients в физ. модели?

Это не значит, что заказы принимают клиентов и адреса находятся в клиентах?

Ennor Tiegael,
Я составляю всё в powerDesigner, задание такое, после составления конц. модели сгенерировать лог. и физ. модель, в model options:
Концептуальная - E/R+Merise
Логическая Entity/Relationship
Физическая Relational

Payment methods Pay Pay - complete hogwash
pay это автоматически сгенерированная промежуточная таблица (связь M-M)
Я хотел написать, что Заказы оплачиваются Методами оплаты.

Delivery_statuses -> have -> orders
По идеи в другую сторону должна смотреть стрелка (orders сущность должна быть родителем)
Но если инвертировать связь получиться, что у каждого заказа может быть несколько статусов заказа.