Перевод UML-агрегации в реляционную базу данных

Question

Я делаю настольное приложение JavaFX. Это система точек продаж, которая отслеживает заказы в ресторане. Я очень новичок в этом, и некоторые вещи запутались после того, как я запустил свой phpmyadmin для создания своей базы данных.

Это соответствующая часть моего UML:

Некоторые примеры, поясняющие содержание таблиц:

• Ingredient таблица может содержать: Мука, ​​сахар, говядина, яйца ...
• ArticleMenu таблица может содержать: Пицца , Burger ...
• ArticleMenu состоит из множества ингредиентов, но эти ингредиенты все еще могут существовать сами по себе, поэтому я подумал, что это совокупность.

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

То, что я пробовал: в ArticleMenu, атрибут 'recette' - это FK, который ссылается на строку из таблицы Ingredient, атрибут 'recette' имеет тип ENUM , который может содержать много значений, которые пользователь определяет при создании строки в ArticleMenu.

Пример: ArticleMenu В таблице есть строка, представляющая, скажем, Pizza, один из ее атрибутов: рецепт типа ENUM и имеет значения «сыр, мука, дрожжи, лук, помидор, грибы, масло»

мой вопрос: это приемлемо способ представления агрегации и что было бы наиболее оптимальным способом?

Редактировать:

После прочтения ответа Кристофа становится ясно, что я не понял, что такое ENUM ,

Документ IBM, который он связал, очистил меня от путаницы, связанной с этой топи c.

Информация о запасах не должна быть частью таблицы ingredient, так как может быть много состояний ingredient, поэтому я удалил их.

Что касается количеств, используемых в каждом получателе ie, они будут представлены с использованием атрибута quantity из таблицы recipie.

Так что я переосмыслил свой подход и придумал этот дизайн:

Answer 1

Проблема с вашим подходом

Вы реализовали то, что Мартин Фаулер называет сопоставлением внешнего ключа , которое реализует отношение один ко (потенциально) многим:

• Здесь Recipe ('recette') будет реализовывать отношение «многие к одному» между ArticleMenu и Ingredients: в одной статье будет только один ингредиент, а во многих статьях может присутствовать один ингредиент.
• Более того, ENUM позволяет вам выбрать для одной строки только одно значение из нескольких. ENUM на самом деле просто удобная замена для использования числа вместо строки.

Так что нет, это неправильный подход.

Ассоциация «многие ко многим» и скрытая таблица

Вам нужно реализовать ассоциацию «многие ко многим»: каждый ArticleMenu может иметь множество Ingredients и наоборот каждый Ingredient может использоваться во многих ArticleMenu.

В СУБД это может быть реализовано с использованием таблицы ассоциации . Это таблица, которая не видна в вашей концептуальной модели. Эта таблица ассоциации может, например, называться Recipe и иметь два столбца: idArticleMenu и idIngredient. Затем вы можете найти:

• всех ингредиентов статьи, ища все строки рецептов, которые имеют соответствующий idArticleMenu.
• всех предметов, в которых используется ингредиент, путем поиска idIngredient

Завершение вашей модели

Теперь, если вы говорите о рецепте и муке, следующий вопрос в вашей заявке будет: сколько муки мне нужно для приготовления 1 пиццы?

К сожалению, это Quantity не является свойством ArticleMenu, поскольку каждый ингредиент одного и того же товара может иметь разное количество. Это также не свойство Ingredient, поскольку ингредиент используется в разных количествах, в зависимости от изделия, для которого он используется. Так где же это поставить?

Ответом является класс ассоциации

Дополнительные рекомендации

Вы можете использовать агрегацию для express отношения целой части. Однако агрегирование semanti c четко не определено в спецификации UML. Таким образом, нет никакой фундаментальной выгоды в его использовании. Поэтому вы можете использовать нормальную ассоциацию здесь.

В модели проектирования (концептуальной) не следует показывать в классе свойства, реализующие отношение. Вы могли бы показать имя таких свойств на другом конце ассоциации, которую это реализует. Если модель реализации, вы могли бы очень хорошо показать все столбцы таблицы. Обычной практикой является использование стереотипа «table» для каждого класса, который будет сопоставлен с таблицей.