Дизайн базы данных: множественные неидентифицирующие отношения между двумя таблицами

Question

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

Когда начинается производственное задание, задействованы два человека во все времена. Один отвечает за производство, а второй отвечает за обеспечение качества. Для любой задачи в базе данных должно быть возможно идентифицировать этих двух людей. Они оба существуют в таблице Person и имеют идентификаторы, поэтому я просто хочу, чтобы лучший способ связать их с производственной задачей. Существуют следующие правила:

• Любой человек может быть заменен другим человеком в любое время.
• Каждая задача всегда включает в себя обоих людей (ни один из них не является нулевым).
• В задаче, которую мы хотим записать, никогда не было других людей.
• Каждый человек может участвовать в нескольких задачах или вообще не участвовать.

Если бы у нас было целая взаимосвязь между заданием и людьми, я бы создал какую-то сложную структуру отношений, описывающую их отношения (как производитель, лицо, обеспечивающее контроль качества, надсмотрщик и т. Д.), Но здесь Мне кажется, что разумно просто вставлять идентификаторы двух людей в таблицу задач, в отдельных столбцах для Person Person и Quality Assurance Person. Неужели это плохо по какой-то причине, что я не вижу?

Что действительно вызвало мой вопрос, так это то, что я пытаюсь спроектировать именно это в DBDesigner 4, для которого я новичок, и ему это просто не нравится. Когда я пытаюсь настроить вторую не- идентифицируя отношения между Задачей и Лицом, это не даст мне второе поле. Это также, похоже, не позволит мне переименовать поля в Задаче, которые относятся к людям, поэтому было бы невозможно провести различие между этими двумя. Поскольку никто другой, похоже, не разделяет эту проблему, я начал задаваться вопросом, действительно ли это хорошая идея. Стандартно ли вводить дополнительные таблицы, как только есть две или более связей между двумя объектами? Как бы это выглядело, если бы я хотел использовать эти правила? Я не вижу, как бы я гарантировал, что таблица n: m всегда имеет записи для обоих людей, работающих над задачей.

Answer 1

Если вы уверены, ваши требования будут оставаться этот жесткий навсегда, то просто создать два NOT NULL FKs:

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

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

---

Я не знаком с DBDesigner, и, следовательно, с вашей конкретной проблемы, но при моделировании ER в целом, множественные отношения с одной и той же сущности отличаются своими «rolenames», которые определяют имена мигрировавших атрибутов (см. раздел «Ролевые имена» в главе 3 раздела ERwin Methods Guide). Попробуйте найти что-то по этим линиям в пользовательском интерфейсе вашего инструмента.

Answer 2

Если вы хотите узнать текущее состояние, а не кто занимал эту роль, то решение @Branko Dimitrijevic будет работать.

Но если заявление «Либо человек может быть выгружен для другого человека в любое время» означает, что вы должны знать, кто ранее занимал эту роль считают дизайнерской 3 табличному

Task; TaskID, <other details> 

Assignee; TaskID, PeopleID, role, start_date, end_date 

People; PeopleID, <other details> 

Тогда в таблице правопреемника вам нужны ограничения, чтобы гарантировать, что для каждого TaskID, комбинация ролей даты являются разумными, например даты не перекрываются или имеют пробелы. У вас есть только одна из каждой роли, активная для каждой задачи за раз. Для управления этим, вероятно, потребуется код либо в триггерах, либо в приложении.