Может ли быть вложенным Foreign Key?

Question

[TRIG]

spoiler

Может ли быть вложенным Foreign Key и можно ли по нему извлечь информацию?

Допустим есть таблицы:
"Руководители", "Задачи", "Исполнители"

И специальная таблица:
"Расписание"

В таблице "Задачи" есть FK_Руководитель
В таблице "Исполнители" есть FK_Задача

Достаточно ли теперь будет указать в таблице "Расписание" только FK_Исполнитель, чтобы получить информацию о предыдущих объектах (задачи, руководители)? Или в ней нужно все равно указать все три FK (задача, исполнитель, руководитель)?

Вопрос НЕ о том, как лучше/как надо, а можно ли делать вложенность объектов при помощи Foreigh Key и таким образом полноценно извлекать нужную информацию?

Comments

[Akina]

Вот вообще не понимаю, о какой вложенности речь.

Есть таблица1, есть таблица2
Есть правило, что значение в поле поле1 из таблицы таблица1 должно существовать в поле поле2 таблицы таблица2. Всё.

Что тут вложено? куда?

Достаточно ли теперь будет указать в таблице "Расписание" только FK_Исполнитель, чтобы получить информацию о предыдущих объектах (задачи, руководители)?

Да.

[TRIG]

Akina, речь о ссылках через FK.

Т.е. можно ли теперь в таблице "Расписание" вывести информацию из таблицы "Руководители", если у них между собой нет никакой прямой связи, а лишь цепочка FK в разных таблицах?

БД имеет такие связи таблиц:
Руководители -> Задачи -> Исполнители -> Расписание

[alexalexes]

Пока не приведете свойства каждой сущности, то не понятно, какими связями должна обрасти сущность Расписание.
При анализе предметной области можно не доглядеть, допустим в сущности Задача - сущности Подзадача, у каждой из них могут быть отдельные исполнители. И не понятно, что хотите получить в расписании - фиксацию работы одного исполнителя, период времени работы над задачей?

[TRIG]

alexalexes, допустим, у исполнителя и руководителя есть имя, а у задачи название.
Можно ли теперь в таблице "Расписание" получить всю эту информацию за счет одного FK_Исполнитель?

Могу более схематически указать:
Руководители {id_руководителя(PK), имя} -> Задачи {id_задачи(PK), название, id_руководителя(FK)} -> Исполнители {id_исполнителя(PK), имя, id_задачи(FK)} -> Расписание {id_расписания(PK), id_исполнителя(FK)}

или

Руководители {id_руководителя(PK), имя} -> Задачи {id_задачи(PK), название, id_руководителя(FK)} -> Исполнители {id_исполнителя(PK), имя, id_задачи(FK)} -> Расписание {id_расписания(PK), id_исполнителя(FK), id_задачи(FK), id_руководителя(FK)}

Т.е. в таблице "Расписание" должна быть информация (поля) из ВСЕХ предыдущих таблиц, даже если это будут просто вложенные сущности со ссылками друг на друга. Или проще говоря, через эту таблицу нужно узнать, кто руководитель, какую задачу выдал и кто выполнил.

[alexalexes]

Для вашей схемы достаточно указать в Расписании внешний ключ исполнителя, так как у вас что-то не так с сущностями Исполнители - они у вас "одноразовые" подучаются. Вам под каждую новую задачу придется вписывать нового исполнителя. Между Задачами и Исполнителями напрашивается отдельная сущность "Исполнитель задачи", в которой будут внешний ключ к Задаче и внешний ключ к Исполнителю - тем самым с помощью этой промежуточной таблицы реализуется связь "многим-ко-многим".
Если расписание нужно для фиксации периодов работы над задачей без детализации по исполнителям, то в записи расписания нужен только внешний ключ задачи. А исполнители подтянуться из сущности Исполнитель задачи.
Если выполнение каждой задачи нужно детализировать по разному набору исполнителей одной задачи, то вам нужно разбить сущность Расписание на две - "Расписание", и "Исполнитель задачи по расписанию"
Записи Расписание будет содержать внешний ключ на задачу, а запись "Исполнитель задачи по расписанию" внешний ключ к Расписанию и внешний ключ к Исполнителю задач (или к Исполнителю - не принципиально).

[TRIG]

alexalexes, "Вам под каждую новую задачу придется вписывать нового исполнителя."
Таки да, т.к. это лишь абстрактный кусочек БД. Задачи - это весьма маленькие действия, на которые достаточно одного человека, иначе и правда не обойтись без связи "многие-ко-многим" и еще одной промежуточной таблицы.

А расписание нужно, чтобы пользователь мог реагировать на него через спикеров, и реакция записывалась не к самим задачам.

[Akina]

Т.е. можно ли теперь в таблице "Расписание" вывести информацию из таблицы "Руководители", если у них между собой нет никакой прямой связи, а лишь цепочка FK в разных таблицах?

Я ж вроде уже ответил - Да. Можно.

Причём поля ID руководителя и задачи в таблице расписаний - лишние, и должны быть удалены. При условии. что предметная область описана верно: каждая задача имеет единственного руководителя, каждый исполнитель работает только над одной задачей, каждое расписание описывает работу только одного исполнителя. А если нет - вполне возможно, что схема должна быть иной.

[SymphoGraph]

А почему руководители и исполнители в разных таблицах?
Те и другие люди. Или социальные лифты априори не предусмотрены?
При такой архитектуре ваша бд будет терять целостность данных при каждом событии в отделе кадров.

Answer 1

[Валентин Бируля]

Если я правильно понял вопрос вы пытаетесь сделать что то вот такое:

Такое возможно (это классика).

Comments

[TRIG]

Нет, не верно.

БД имеет такие связи таблиц:
Руководители -> Задачи -> Исполнители -> Расписание

В таблице "Расписание" нужна информация о предыдущих сущностях (их атрибуты) в виде FK.

[Валентин Бируля]

Можете привести ER?

[TRIG]

Валентин Бируля,

[TRIG]

TRIG, правильнее даже спросить, будет ли ЭТОТ вариант корректным схематически?
Или в последней таблице "Расписание" я могу указывать лишь FK id_исполнителя???

[Василий Банников]

TRIG, Такое реализовать можно, но смысла в этом нет. Информацию о руководителе и задаче в расписании можно вытащить из исполнителя простым джоином.

[TRIG]

Василий Банников, в чем тут проблема? В скорости работы?

[Валентин Бируля]

Вы можете сделать так:

[TRIG]

Валентин Бируля, вы видите иначе подобный вариант? таблицы, конечно, не настоящие и не имеют такое количество полей.

[Валентин Бируля]

TRIG, Проблема в бессмысленности, потому что в данном случае вы получите всю инфу и так по "Задаче". У вас появляется дублирование данных

[TRIG]

Валентин Бируля, но у меня есть условное расписание на много-много дней. И задач тоже много-много.
При этом само расписание может быть еще дополнено своими полями.

[alexalexes]

Руководитель и Исполнитель - это, по хорошему просто Человек.
А руководитель и исполнитель - это Роли (отдельная таблица). Осталось понять, если роль дается на задачу, то внешний ключ Роли идет на задачу, если Роль постоянна и не меняется от задачи к задаче - то на человека внешний ключ роли нужен.

[Василий Банников]

TRIG,
1. Лишние индексы
2. Лишнее дублирование данных
3. Лишняя работа по поддержанию этих колонок в актуальном состоянии. Нужно постоянно помнить, что если меняешь руководителя в задаче, то надо сразу поменять руководителя в расписании.
=> Снижение производительности, повышенное потребление ресурсов, и снижение надёжности из-за увеличения пространства для ошибок/багов.

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

[TRIG]

Василий Банников, каким тогда образом реализовать вывод расписания, если не иметь такой таблицы, что в себе аккумулирует данные из других таблиц? Эта таблица избыточна? Но что если у пользователя предусмотрена реакция на какие-то задачи в виде обратной связи (пометки там всякие), которые надо регистрировать?

[Валентин Бируля]

TRIG, Я вижу это вот так:

Это только если:
Задача рассчитана только на одного исполнителя
И задача многоразовая.

В реале я бы вообще отказался от таблицы Расписание добавив задаче время и место, ну и кнч добавил бы возможность чтоб несколько исполнителей было у одной задачи.
Вот так:

Опять же опускаем вариант что у руководителя тоже может быть задача и тд

[mayton2019]

Нормализации нет предела. Можно считать что руководители и исполнители - это суть персоны. И их персональность - это тоже реляция в данной модели.

Вобщем слушай автор. В Mongo и в Cassandra и в Couchdb данные лежат не в нормалях в агрегатах.
И это считается best practices. Я не хочу сказать что тебе нужны агрегаты. Просто существуют
в природе и такие задачи и они вполне себе живут. Особенно если данные исторические
и больше не меняются. Или меняются только как журнал (append only) или исторические
метаданные.

[Василий Банников]

TRIG,

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

Обычным джоином.

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

Об этом в вопросе не сказано. Для всяких реакций и пометок я бы отдельную таблицу завел.

[TRIG]

Василий Банников, ну вот отдельная таблица и есть как абстрактное "Расписание", чтобы по цепочке извлечь минимальную информацию, отобразить её в расписании и там получить реакцию от пользователя на пункт в расписании в виде задачи.
Джоин джоином, но от пользователя нужна обратная связь и её регистрирование.

В общем, не суть. Если в одной таблице есть несколько FK из других таблиц - можно ли в следующую таблицу их просто копировать из нее? Это основной вопрос, т.к. это учебный проект, общего с реальностью не имеющий
Как на картинке.

[Василий Банников]

TRIG, копировать то можно, но какую задачу ты этим решить пытаешься?
Повторюсь, что при такой схеме будет:

1. Лишние индексы
2. Лишнее дублирование данных
3. Лишняя работа по поддержанию этих колонок в актуальном состоянии. Нужно постоянно помнить, что если меняешь руководителя в задаче, то надо сразу поменять руководителя в расписании.
=> Снижение производительности, повышенное потребление ресурсов, и снижение надёжности из-за увеличения пространства для ошибок/багов.

Answer 2

[SymphoGraph]

Может, но это бессмысленно.
Ваш преподаватель, я думаю, учит вас бесполезному.
Попробуйте так:

Это избавит вас от потенциальных проблем с целостностью данных и позволит поручить контроль над задачей нескольким руководителям.

Answer 3

[Rsa97]

Может. Достаточно. JOIN.