Как моделировать объекты 2х2 (реляционные таблицы), в которых 2 описывают «модель», а 2 - «конкретизацию»? - PullRequest
0 голосов
/ 12 марта 2020

Я ищу способ смоделировать 4 таблицы, чтобы они были согласованными. 2 таблицы являются своего рода типами enum ++: они описывают то, что возможно. Два других - это конкретизация таблиц типов. Пример, упрощенный :):

ActionType: описывает возможные типы «действий», например, нарезка овощей, готовка, ...

  • name

ActionTypeResult: описывает результат каждого Type действия

  • name
  • type (<- <code>Type.name)

Так, например, результатом cutting vegables будут как органические c отходы, так и готовые кусочки овощей (так 2 результата). boiling также будет иметь 2 результата: приготовленная пища и кипяток (обычно вы избавляетесь от кипящей воды, но это результат этого шага).

Теперь я хочу описать рецепт, что означает , он имеет несколько ActionType с, но Result из ActionType является входом следующего. Итак:

У меня может быть Recipe сущность, которая состоит из

CookingStep s, которая связана с ActionType - чтобы знать, что это за шаг, и какой вид Results шаг имеет. CookingFlow s, которые являются Results (продуктами), которые могут быть введением следующих CookingStep.

Итак, можно сделать следующее:

Recipe:

  • name

CookingStep:

  • recipe (<- <code>Recipe.name)
  • title (ну, вы можете дать названиям шагов, в зависимости от рецепта :))

CookingFlow:

  • step (<- <code>CookingStep.title, это источник потока)
  • recipe (<- <code>Recipe.name, не уверен, действительно ли нам это нужно, так как мы знаем это, потому что он уже связан step, я не включил в диаграмму ниже)
  • result (<- <code>ActionTypeResult.name, поэтому знайте, о каком из различных потоков мы говорим)
  • flows to (<- <code>CookingStep.title, поэтому мы знаем, куда это течет).

Теперь, делая это, я вижу избыточность в отношениях recipe, но также можно «обмануть»: a CookingStep типа cut vegables может иметь отношения с CookingFlow, который имеет result boiling water или boiled food. Я хочу, чтобы этот обман был запрещен.

Вопрос: как правильно смоделировать это?

Проблема в том, что это может привести к несоответствующим данным (обман). Основная проблема, с которой я столкнулся, заключается в следующем: имея определенный CookingStep, у меня есть ActionType и CookingFlow. Это хорошо. Однако ActionTypeResult, который у меня есть в CookingFlow, в этом случае должен быть тем, который разрешен ActionType, определенным в CookingStep. Я хочу, чтобы правильный ActionType был применен к CookingFlow того же CookingStep. Я могу использовать триггеры на БД, чтобы проверить, правильно ли это; В основном мне было интересно, можно ли смоделировать его без триггеров.

enter image description here

1 Ответ

0 голосов
/ 31 марта 2020

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

Добавьте к готовому шагу и результатам в типе шага - замените их соединением / соединением с oftype. Теперь участие / FKs по ассоциативному объекту (шаг, тип). Добавьте к готовящемуся потоку & результатам в типе потока - замените их на их соединение / соединение с ofresulttype Теперь участие / FKs по ассоциативной сущности (поток, тип). Add имеет ассоциативное участие / FK в результатах.

В новых версиях связей / таблиц, в которые мы добавили отношения / таблицы типов ANDed / объединены, данные этого типа «избыточны» - они уже находятся в таблицах типов. Но это допускает ограничение в SQL посредством его (жалкого выбора) декларативных ограничений, а не с помощью триггеров. Эти декларации не только надлежащим образом ограничивают проекции нового дизайна, которые дают старый дизайн, но и контролируют избыточность. Но теперь нам также нужно обновить несколько таблиц, где раньше мы могли обновлять только одну.

Как я могу применить отношения второй степени без составных ключей?
Как обеспечить соответствие значений из таблицы журналов объектам в других таблицах?
Хранение «избыточных» внешних ключей во избежание объединений
Зависимость группы SQL дизайн

PS Ваш дизайн не вводит пошаговые вводы - «Результатом ActionType является ввод следующего».

PS в соответствии с RM (реляционная модель) & ERM (сущность) Модель отношений) можно говорить в терминах таблиц или отношений (судно) / ассоциации, которые они представляют. Таблица FK БД соответствует участию группы ER в отношениях. Ограничение FK сохраняется, когда подстроки появляются в другом месте уникально, то есть когда / iff объекты, участвующие вместе, участвуют вместе в другом месте один раз.

PS Каждое FK / участие характеризует отношение подтипа - ссылки / участвующие значения / объекты против супертипа все, что может; мы просто не всегда называем этот подтип «подтипом». У вас явно есть явный подтип - у вас даже есть значения / сущности, действующие как теги «Тип». Вам просто нужно пометить сущности их тегами, чтобы данные о типах явным образом присутствовали с сущностью для проверки типов с помощью ограничений FK.

Как вы можете представить наследование [/ subtyping] в базе данных?
Как эффективно моделировать наследование [/ subtyping] в базе данных?

...