Создание отношений 1: n (один-ко-многим) или n:1 (многие-к-одному)

Создание и изменение отношений 1:N между сущностями

Откройте обозреватель решений.

В разделе Компоненты раскройте узел Сущности, затем раскройте сущность, с которой требуется работать.

Выберите Отношения 1:N.

Чтобы изменить отношение или просмотреть сведения для отношения, выберите отношение и нажмите на панели инструментов «Действия» кнопку Другие действия, затем выберите Изменить.
— ИЛИ —
Чтобы добавить новое отношение, выберите Создать отношение «один ко многим».

Важно!
Если кнопка Создать отношение «один ко многим» не отображается на панели инструментов «Действия», то создать отношение 1:N для этой сущности невозможно.

Для нового отношения в разделе Определение отношения выберите в списке Связанная сущность сущность для связывания.

Примечание
При указании связанной сущности задается значение по умолчанию в поле Имя. Если изменить связанную сущность перед ее сохранением, соответственно изменится и значение поля Имя.

Выберите, будет ли это поле доступно для поиска или нет.

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

Важно!
При указании значения Отображаемое имя задается значение по умолчанию в поле Имя

Если изменить Отображаемое имя поля поиска перед сохранением данных, значение в поле Имя не изменится. Поэтому необходимо ввести в поле Имя информативное значение перед сохранением данных.

В списке Требование поля выберите вариант, чтобы указать требования к данным для поля перед сохранением записи.

В разделе Элемент области переходов для основной сущности в списке Параметры отображения выберите вариант отображения связанных представлений для пользовательской метки.

В разделе Поведение отношений выберите в списке Тип отношений один из следующих вариантов.

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

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

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

Настраиваемое каскадное. В настраиваемом каскадном отношении между двумя сущностями выбирается поведение, связанное с каждым из наборов возможных действий.

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

Дополнительные сведения:

1. Выберите Сохранить и закрыть, чтобы закрыть форму Отношение.

2. Выполнив настройки, опубликуйте их:

   • Чтобы опубликовать настройки только для компонента, изменяемого в данный момент, на панели инструментов «Действия» выберите Опубликовать.

   • Чтобы опубликовать настройки для всех неопубликованных компонентов одновременно, на панели навигации или в области переходов выберите Сущности, затем на панели инструментов «Действия» выберите Опубликовать все настройки.

Примечание

• Настраиваемая сущность не может быть основной в каскадном отношении со связанной системной сущностью. Это означает, что между основной настраиваемой сущностью и связанной системной сущностью не может быть отношений с каким-либо из действий, установленным в «Передавать всем», «Передавать активным» или «Передавать владельцу».
• У новых отношений действие не может иметь значение Передавать всем, Передавать активным или Передавать владельцу, если связанная сущность в этом отношении уже является связанной сущностью в любом другом отношении, действие которого имеет значение Передавать всем, Передавать активным или Передавать владельцу. Это позволяет избежать создания отношений с несколькими родительскими сущностями.
• После каждого изменения элементов пользовательского интерфейса или внедрения скриптов формы для сущности необходима публикация изменений. Все изменения в схеме данных приложения, таких как настраиваемые сущности, связи или поля, применяются сразу.
• Если отношение является частью управляемого решения, разработчик решения может ограничить настройку отношения пользователями.
• Установка решения или публикация настроек может помешать нормальной работе системы. Рекомендуется запланировать импорт решения в оптимальный для пользователей период.

Отношение «один-к-одному»

Отношение или связь «один-к-одному» связывает одну запись таблицы с одной или не связывает ни с одной записью другой таблицы. Иногда этот тип отношения применяется для разбиения таблицы с большим количеством полей на две или несколько меньших таблиц.

Таблица Products (изделия) может содержать подробную информацию, описывающую изделие и его цену, и дополнительные сведения об особенностях его производства.

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

В другой ситуации можно разбить таблицу на две, просто потому что она слишком велика. (Программа Access не разрешает таблице иметь более 255 полей.)

Рис. 5.15. Когда связываются два поля, в которых не допускаются дублирующиеся данные (и флажок Обеспечение целостности данных установлен), Access считает, что создается связь «один-к-одному».

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

В этом примере столбец ID в таблице Products и столбец ID в таблице ProductsEngineering — первичные ключи соответствующих таблиц, поэтому невозможно связать несколько записей таблицы ProductsEngineering с одной и той же записью таблицы Products

создается так же, как отношение «один-ко-многим» — перетаскиванием с помощью мыши полей на вкладке Схема данных (рис. 5.15). Единственная

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

Примечание

В поле запрещены совпадения, если оно является первичным ключом таблицы (см. разд. «Первичный ключ» главы 2) или если у поля есть индекс, препятствующий появлению дублирующейся информации (см. разд. «Предотвращение дублирования значений с помощью индексов» главы 4).

Применяйте связи «один-к-одному» с осторожностью

Отношения «один-к-одному» крайне редко применяются в программе Access. Обычно гораздо удобнее использовать скрытие столбцов (см. разд. «Скрытие столбцов» главы 3) и запросы (см. главу 6), если вы хотите видеть только отдельные поля таблицы.

•    Две части таблицы необходимо поместить в отдельные БД (см. разд. «Что такое разделенная БД» главы 18) для того, чтобы разные люди могли копировать их на разные компьютеры и редактировать независимо.

•    Вы хотите защитить от любопытных глаз уязвимые данные. Один из возможных способов — поместить информацию, которую нужно защитить, в отдельную таблицу и сохранить эту таблицу в другой, более защищенный файл БД.

•    У вас есть таблица с огромным объемом данных, таких как поля типа Вложение (см. разд. «Вложение» главы 2) с большими документами. В этом случае можно повысить производительность, если разделить таблицу. Вы даже можете решить, что лучше поместить половину таблицы в отдельную БД (см, разд. «Что такое разделенная БД» главы 18).

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

Если у вас нет таких ситуаций, вы больше выиграете от создания одной большой таблицы.

Отношение «многие-ко-многим»

Отношение или связь «многие-ко-многим»связывает одну или несколько записей одной таблицы с одной или несколькими записями в другой таблице. Рассмотрим БД, в которой в отдельных таблицах хранятся данные об авторах и книгах.

Авторы бестселлеров не останавливаются на одной книге (поэтому вы должны иметь возможность связать одного автора с несколькими книгами).

Однако иногда авторы объединяются в команду под одним заглавием (поэтому вы должны иметь возможность связать одну книгу с несколькими авторами).

Аналогичная ситуация возникает, если нужно распределить студентов по курсам, сотрудников по комитетам или ингредиенты по рецептам. Можно даже представить подобную ситуацию и в случае БД с куклами-болванчиками, если несколько изготовителей решат объединиться для изготовления одной куклы-болванчика.

Связи «многие-ко-многим» довольно распространены, и программа Access предоставляет два способа их обработки.

Вы можете следить за любыми ответами на эту запись через RSS 2.0 ленту. Вы можете оставить ответ, или trackback с вашего собственного сайта.

Поведение отношений

Можно настроить поведение отношения 1:N для поддержки бизнес-правил организации. Почему это может потребоваться? Рассмотрим пример.

Допустим, у вас новый продавец и требуется назначить ему несколько существующих возможных сделок, в данное время назначенных другому продавцу. Каждая запись возможной сделки может иметь несколько действий задач, связанных с ней. Можно легко найти активные возможные сделки, которые требуется переназначить, и назначить их новому продавцу. Но что произойдет с действиями задач, связанными с возможными сделками? Хотелось бы вам открывать каждую задачу и указывать, должна ли она также быть назначена новому продавцу? Скорее всего, нет. Вместо этого можно разрешить отношению применить некоторые стандартные правила автоматически. Эти правила применяются только к записям задач, связанным с возможными сделками, которые вы переназначаете. Это отношение сущностей называется Opportunity_Tasks. Можно выполнить следующие действия:

• Переназначить все активные задачи.

• Переназначить все задачи. Это поведение принимается по умолчанию.

• Не переназначать задачи.

• Переназначить все задачи, которые в данный момент назначены бывшему владельцу возможной сделки.

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

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

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

Использование связей с кратностью «многие ко многим» вместо временного решенияUse a relationship with a many-many cardinality instead of the workaround

Начиная июльской версии 2018 г., в Power BI Desktop можно напрямую связывать таблицы, например те, которые мы упоминали выше, не прибегая к использованию аналогичных временных решений.With the July 2018 version of Power BI Desktop, you can directly relate tables, such as the ones we described earlier, without having to resort to similar workarounds. Теперь можно задать кратность связи многие ко многим.It’s now possible to set the relationship cardinality to many-to-many. Этот параметр указывает, что ни одна из таблиц не содержит уникальные значения.This setting indicates that neither table contains unique values. Такие связи позволяют контролировать, какая таблица фильтрует другую таблицу.For such relationships, you may still control which table filters the other table. Либо можно применить двунаправленную фильтрацию, где каждая таблица фильтрует другую.Or you can apply bidirectional filtering, where each table filters the other.

В Power BI Desktop по умолчанию задается кратность многие ко многим, когда программа определяет, что ни одна из таблиц не содержит уникальные значения столбцов связи.In Power BI Desktop, the cardinality defaults to many-to-many when it determines neither table contains unique values for the relationship columns. В таких случаях отображается предупреждение с сообщением о том, что вы хотите установить связь, и изменение не является случайным результатом проблемы с данными.In such cases, a warning message confirms you want to set a relationship, and the change isn’t the unintended effect of a data issue.

Например, при создании связи непосредственно между CityData и Sales—, где фильтры должны применяться от CityData к Sales, в —Power BI Desktop отображается диалоговое окно Изменение связи.For example, when you create a relationship directly between CityData and Sales—where filters should flow from CityData to Sales—Power BI Desktop displays the Edit relationship dialog box:

Итоговое представление связей будет содержать прямую связь «многие ко многим» между двумя таблицами.The resulting Relationship view would then display the direct, many-to-many relationship between the two tables. Внешний вид таблиц в списке Поля и их последующее поведение при создании визуальных элементов аналогично ситуации, в которой мы применили обходной путь.The tables’ appearance in the Fields list, and their later behavior when the visuals are created, are similar to when we applied the workaround. Там мы создали дополнительную скрытую таблицу уникальных штатов.In the workaround, the extra table that displays the distinct State data isn’t made visible. Как было сказано выше, отображается визуальный элемент со сведениями о штате, населении и продажах.As described earlier, a visual that shows State, Population, and Sales data would be displayed:

Основные различия между связями с кратностью «многие ко многим» и более распространенными связями многие к одному заключается в следующем.The major differences between relationships with a many-many cardinality and the more typical Many-1 relationships are as follows:

• Значения, показываемые в них, не содержат пустую строку, отвечающую за несовпадающие строки в другой таблице.The values shown don’t include a blank row that accounts for mismatched rows in the other table. Кроме того, значения не отвечают за строки, в которых столбец, используемый для связи в другой таблице, имеет значение NULL.Also, the values don’t account for rows where the column used in the relationship in the other table is null.

• Использовать функцию (так как связанными могут быть несколько строк) не удастся.You can’t use the function, because more than one row could be related.

• При использовании функции в таблице не удаляются фильтры, примененные к другим таблицам, у которых с ней установлена связь «многие ко многим».Using the function on a table doesn’t remove filters that are applied to other, related tables by a many-to-many relationship. В предыдущем примере мера, определенная согласно данному скрипту, не удалит фильтры по столбцам связанной таблицы CityData.In the preceding example, a measure that’s defined as shown here wouldn’t remove filters on columns in the related CityData table:

  Визуальный элемент с отображением штата, объема продаж и общего объема продаж будет таким, как на рисунке ниже.A visual showing State, Sales, and Sales total data would result in this graphic:

Учитывая перечисленные различия, убедитесь, что вычисления, использующие , такие как % от общей суммы, возвращают желаемые результаты.With the preceding differences in mind, make sure the calculations that use , such as % of grand total, are returning the intended results.

Для чего все это нужно?

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

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

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

• < Назад
• Вперёд >

Новые статьи:

• Объединение таблиц – UNION

• Соединение таблиц – операция JOIN и ее виды

• Тест на знание основ SQL

Если материалы office-menu.ru Вам помогли, то поддержите, пожалуйста, проект, чтобы я мог развивать его дальше.

Проектируем базу для связи Многие-ко-Многим — sql для создания таблиц

Нам потребуется создать три таблицы:

1. Таблицу «Заявка»
2. Таблицу «Номинация»
3. и т.н. «таблицу связи»

Сделаем это (SQL):

CREATE TABLE `Tickets` (
    `ticketID` INT(11) NOT NULL AUTO_INCREMENT,
    `name` VARCHAR(255) NOT NULL
        DEFAULT '' COMMENT 'Имя участника/название организации',
    `info` VARCHAR(255) NULL
        DEFAULT '' COMMENT 'Информация о номинанте',
    PRIMARY KEY (`ticketID`)
)
COMMENT='Заявки учасников конкурса'
ENGINE=InnoDB
;
  
CREATE TABLE `Nominations` (
    `nominationID` INT(11) NOT NULL AUTO_INCREMENT,
    `title` VARCHAR(255) NULL
        DEFAULT NULL COMMENT 'Название номинации',
    PRIMARY KEY (`nominationID`)
)
COMMENT='Номинации конкурса'
ENGINE=InnoDB
;
  
CREATE TABLE `Tickets_Nominations` (
    `ticket_id` INT(11) NOT NULL,
    `nomination_id` INT(11) NOT NULL,
    PRIMARY KEY (`ticket_id`, `nomination_id`),
    INDEX `ticket_id` (`ticket_id`),
    INDEX `nomination_id` (`nomination_id`),
    CONSTRAINT `FK_Nominations` FOREIGN KEY (`nomination_id`) 
        REFERENCES `Nominations` (`nominationID`) ON DELETE CASCADE,
    CONSTRAINT `FK_Ticket` FOREIGN KEY (`ticket_id`) 
        REFERENCES `Tickets` (`ticketID`) ON DELETE CASCADE
)
COMMENT='Таблица связи заявок участников и номинаций конкурса'
ENGINE=InnoDB
;

Обратите внимание на:

1. Свойство «ON DELETE CASCADE» —
   это значит, что если будет удалена запись в другой таблице, на которую ссылается данный кортеж (из таблицы связи), то и этот кортеж будет удалён целиком. В данном случае связь удаляется из таблицы если удалено хотя быть что-то одно из двух:
   • или заявка, на которую он ссылается
   • или номинация, на которую он ссылается

   — таким образом мы переносим задачу удаления неактуальный связей с приложения на СУБД.

2. В этом примере использован составной первичный ключ PRIMARY KEY ,ведь там написано:

   PRIMARY KEY (`ticket_id`, `nomination_id`),
   

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

   CREATE TABLE `Tickets_Nominations` (
       `id` INT(11) NOT NULL AUTO_INCREMENT,
       `ticket_id` INT(11) NOT NULL,
       `nomination_id` INT(11) NOT NULL,
       INDEX `ticket_id` (`ticket_id`),
       INDEX `nomination_id` (`nomination_id`),
       CONSTRAINT `FK_Nominations` FOREIGN KEY (`nomination_id`) 
   		REFERENCES `Nominations` (`nominationID`) ON DELETE CASCADE,
       CONSTRAINT `FK_Ticket` FOREIGN KEY (`ticket_id`) 
   		REFERENCES `Tickets` (`ticketID`) ON DELETE CASCADE,
   	PRIMARY KEY (`id`),
   	UNIQUE KEY `relation_row_unique` (`ticket_id`,`nomination_id`)
   )
   COMMENT='Таблица связи заявок участников и номинаций конкурса'
   ENGINE=InnoDB
   ; 
   

   — но часто вполне .

Связь один-к-одному

Последнее обновление: 17.05.2019

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

Для создания подобной связи между моделями применяется метод hasOne(). Например, определим модели тренера и команды:

const Sequelize = require("sequelize");

const sequelize = new Sequelize("game", "root", "123456", {
    dialect: "mysql",
    host: "localhost",
    define: {
      timestamps: false
    }
});
const Coach = sequelize.define("coach", {
  id: {
    type: Sequelize.INTEGER,
    autoIncrement: true,
    primaryKey: true,
    allowNull: false
  },
  name: {
    type: Sequelize.STRING,
    allowNull: false
  }
});
const Team = sequelize.define("team", {
  id: {
    type: Sequelize.INTEGER,
    autoIncrement: true,
    primaryKey: true,
    allowNull: false
  },
  name: {
    type: Sequelize.STRING,
    allowNull: false
  }
});

Coach.hasOne(Team, { onDelete: "cascade"});

sequelize.sync({force:true}).then(()=>{

  console.log("Tables have been created");
}).catch(err=>console.log(err));

В данном случае модель тренера (Coach) условно считается главной, а модель команды (Team) зависимой (но в данном случае деление на главную и зависимую модель
достаточно условно). Поэтому метод вызывается у модели Coach, и в качестве первого параметра передается модель Team. Хотя в данном случае не имеет значения, какая именно модель является главной или зависимой.
Второй параметр метода задает конфигурацию связи, в частности, каскадное удаление.

В итоге при выполнении данного когда в MySQL будут созданы следующие таблицы:

CREATE TABLE `coaches` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `name` varchar(255) NOT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf-8 COLLATE=utf8mb4_0900_ai_ci;

CREATE TABLE `teams` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `name` varchar(255) NOT NULL,
  `coachId` int(11) DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `coachId` (`coachId`),
  CONSTRAINT `teams_ibfk_1` FOREIGN KEY (`coachId`) REFERENCES `coaches` (`id`) ON DELETE CASCADE ON UPDATE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf-8 COLLATE=utf8mb4_0900_ai_ci;

Как мы видим, в таблице teams создается дополнительный столбец coachId, через который данная таблица будет связана с таблицей coaches.

Добавление и получение связанных данных

Для установки связанных данных применяется метод setНАЗВАНИЕ_МОДЕЛИ(). Например, добавим тренера и его команду:

// добавляем тренера
Coach.create({ name: "Tom Smith"})
.then(coach=>{
	// Добавляем команду
	Team.create({name:"Real Madrid"}).then(team=>{
		// устанавливаем для тренера команду
		coach.setTeam(team).catch(err=>console.log(err));
	});
}).catch(err=>console.log(err));

По факту метод будет вызывать SQL-команду UPDATE. То есть к моменту вызова данного метода связываемые сущности уже должны быть в
базе данных.

Для получения связанных данных применяется метод getНАЗВАНИЕ_МОДЕЛИ(). Например, получим тренера и его команду:

// получаем тренера с id=1
Coach.findByPk(1).then(coach=>{
	if(!coach) return console.log("Coach not found");
    coach.getTeam().then(team=>{
        console.log(coach.name, "-", team.name);
    });
});

В данном случае на консоли мы получим:

Tom Smith - Real Madrid

Получение всех тренеров с включением связанных данных:

Coach.findAll({
    attributes: , // включаем столбец name из таблицы coaches
    include:   // включаем столбец name из таблицы teams
    }]
  }).then(coaches => {
      for(coach of coaches){
        console.log(coach.name, "-", coach.team.name);
      }
});

НазадВперед

Извлечение данных для связи «многие ко многим» (SELECT)

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

Рассмотрим задачу извлечения участников, связанных с данной номинацией — или короче «номинации, и всех, кто подал в неё заявки» (алгоритм извлечения данных в обратную сторону — т.е. «участик и все его номинации» абсолютно аналогичен).
На практике приходится сталкиваться с двумя базовыми ситуациями:

1. Извлечение одной сущности номинации и связанных с ней участников
2. Извлечение списка сущностей номинаций и связанных с каждой из номинаций участников (т.е. фактически список участников для каждого элемента из списка номинаций).

Извлечение связанных (многие-ко-многим) данных для одной сущности

Пусть у нас известен id () номинации и мы хотим получить сведения об этой номинации и всех участниках в ней.
Во-первых, сделать это можно двумя sql запросами:

1. Сначала просто получим кортеж этой номинации:

   mysql> SELECT * FROM Nominations WHERE nominationID=4;
   +--------------+-----------------------------+
   | nominationID | title                       |
   +--------------+-----------------------------+
   |            4 | Лучшее пособие              |
   +--------------+-----------------------------+
   
   

2. После, опять же зная id номинации (используем в WHERE), достаточно просто сделать LEFT JOIN между таблицей связи и таблицей участников:

   SELECT * FROM  Tickets_Nominations LEFT JOIN Tickets 
   	ON ticket_id = ticketID 
   	WHERE Tickets_Nominations.nomination_id = 4;

   Получим:

   +-----------+---------------+----------+-------------------------- +----------------------------------------------+
   | ticket_id | nomination_id | ticketID | name                      | info                                         |
   +-----------+---------------+----------+---------------------------+----------------------------------------------+
   |         3 |             4 |        3 | Программирование для всех | Некоммерческая образовательная организация  
   |         4 |             4 |        4 | Юный программист          | Кружок для детей в д. Простоквашино        
   |         5 |             4 |        5 | IT FOR FREE               | Русскоязычное IT-сообщество с уклоном в web  
   |         6 |             4 |        6 | Саша Петров               | Студент 2 курса, автор пособия по SQL   
   

   — как видим, тут мы получили вообще все колонки (т.к. в запросе указали звездочку *) двух соединённых таблиц (связи и заявок).
   Также видим что на номинации с id=4 номинировалось 4-ре участника, кроме их имен видны также и описания.
   Все эти данные можно использовать в приложении, после выполнения запроса к БД — например записать, то что нужно в поле, хранящее массив объекта конкретной номинации.

Если вам требуется от массива связанных сущностей только одно поле (напр. имена участников), то решить задачу можно вообще одним sql запросом, используя группировку (GROUP BY) и применимую к группируемым значения колонки функцию конкатенации GROUP_CONCAT():

SELECT 
    Nominations.*, 
	 GROUP_CONCAT(Tickets.name SEPARATOR ', ') as participants_names
 FROM  
   Nominations LEFT JOIN Tickets_Nominations 
	   ON Nominations.nominationID = Tickets_Nominations.nomination_id 
	LEFT JOIN Tickets  
	   ON Tickets.ticketID = Tickets_Nominations.ticket_id
 
WHERE Tickets_Nominations.nomination_id = 4
 	GROUP BY Nominations.nominationID;

Получим единственный кортеж:

+--------------+-----------------------------+-----------------------------------------------------------------------------------------------------------------------+
| nominationID | title                       | participants_names                                                                                                    |
+--------------+-----------------------------+-----------------------------------------------------------------------------------------------------------------------+
|            4 | Лучшее пособие              | Программирование для всех, Юный программист, IT FOR FREE, Саша Петров                                                 |
+--------------+-----------------------------+-----------------------------------------------------------------------------------------------------------------------+

— здесь мы:

• провели сразу тройной JOIN, как бы поставив таблицу связи между таблицами номинаций и заявок.
• нас интересовали имена участников для 4 номинации — поэтому использовали WHERE Tickets_Nominations.nomination_id = 4
• Группировка (чтобы в итоге получить только одну строку-кортеж) проходила по id номинации (Nominations.nominationID)
• Сконкатенированному полю мы назначили псевдоним (participants_names)

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