Здравствуйте, помогите, пожалуйста, разобраться, на других форумах не могут помочь, неужели настолько сложные вещи описываю, непонятно:
Составляю базу данных для пиццерии (пользователи могут на сайте оформлять заказы), составил первую концептуальную модель (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 таблицы (кстати зачем они нужны?)