Применение связей «многие ко многим» в power bi desktop
Содержание:
- Тестирование связи «многие ко многим»
- Добавление необходимых таблиц к представлению источника данных
- Использовавшийся ранее обходной путь
- Как определить связи между таблицами
- Один-ко-многим или многие-к-одному
- Извлечение данных для связи «многие ко многим» (SELECT)
- Поведение отношений
- Создание и изменение отношений 1:N между сущностями
- Ассоциация ManyToOne / OneToMany.
- Что такое мощность отношений?
Тестирование связи «многие ко многим»
При задании в кубе связи «многие ко многим» тестирование результатов является обязательным. Необходимо тестировать куб с помощью клиентского приложения, которое будут использовать конечные пользователи. В следующей процедуре мы откроем куб в Excel, чтобы проверить результаты запросов.
Откройте куб в Excel
Разверните проект, затем откройте куб, чтобы подтвердить правильность выполнения агрегирований.
в Excel щелкните данные | из других источников | из Analysis Services. Введите имя сервера, выберите базу данных и куб.
Создайте сводную таблицу, которая использует следующее:
Sales Amount как значение
Sales Reason Name для столбцов
Sales Order Number для строк
Проанализируйте результаты. Мы используем примеры данных, поэтому на первый взгляд кажется, что все заказы на продажу имеют одинаковые значения. Но если выполнить прокрутку результатов вниз, то можно видеть разброс данных.
Немного ниже вы увидите сумму продаж и причины для заказа с номером SO5382
Общая сумма этого заказа — 539,99, а в качестве причин указаны Promotion, Other и Price.
Обратите внимание, что столбец Sales Amount для этого заказа вычислен правильно; здесь показано 539,99 за весь заказ
Хотя 539,99 указано для каждой причины, это значение не суммируется для всех трех причин, что привело бы к ошибке в общем итоге.
А зачем вообще помещать сумму продаж под каждой причиной продажи? Это позволяет идентифицировать объем продаж, который можно приписать каждой причине.
Выполните прокрутку до нижней части листа
Теперь хорошо видно, что Price (Цена) является самой важной причиной для покупок клиентов по сравнению с другими причинами и общей суммой.
Советы по обработке непредвиденных результатов запросов
-
Скрывайте в промежуточной группе мер такие меры, как подсчеты, которые не возвращают в запросе значимые результаты. Это не позволит пользователям использовать агрегирования, дающие на выходе бессмысленные данные. Чтобы спрятать меру, задайте атрибуту Видимость значение False в конструкторе измерения.
-
Создавайте перспективы, использующие подмножество мер, и измерения, обеспечивающие аналитический процесс, который вы желаете предоставить пользователям. Возможно, куб, который содержит много групп мер и измерений, не во всех случаях будет работать как надо. Изолируя измерения и группы мер, которые будут использоваться вместе, вы обеспечиваете более прогнозируемый результат.
-
Всегда помните, что нужно развернуть модель и снова подключиться к ней после ее изменения. В Excel нажмите кнопку «Обновить» на ленте «Анализ» сводной таблицы.
-
Избегайте использования связанных групп мер в нескольких связях типа «многие ко многим», особенно если эти связи находятся в разных кубах. Это может привести к формированию неоднозначных агрегатов. Дополнительные сведения см. в разделе Неверные суммы для связанных мер в кубе, содержащих связи «многие ко многим».
Добавление необходимых таблиц к представлению источника данных
Откройте конструктор представлений источника данных для представления источников данных Adventure Works DW 2012 .
Щелкните правой кнопкой мыши панель Организатор диаграмм , выберите команду Создать диаграмму и укажите Причина заказа через Интернет в качестве имени созданной диаграммы.
Перетащите таблицу InternetSales с панели Таблицы на панель Диаграмма .
Щелкните правой кнопкой мыши панель Диаграмма и выберите команду Добавить или удалить таблицы.
В диалоговом окне Добавление или удаление таблиц добавьте в список Включенные объекты таблицы DimSalesReason и FactInternetSalesReason , а затем нажмите кнопку ОК.
Обратите внимание, что связи «первичный-внешний ключ» между задействованными таблицами устанавливаются автоматически, поскольку эти связи определяются в базовой реляционной базе данных. Если эти связи не определены в базовой реляционной базе данных, их следует определить в представлении источника данных.
В меню Формат выберите команду Автоматический макет и щелкните значок Диаграмма.
В окне свойств измените свойство FriendlyName таблицы DimSalesReason на SalesReason, затем измените свойство FriendlyName таблицы FactInternetSalesReason на InternetSalesReason.
На панели Таблицы разверните узел InternetSalesReason (dbo.FactInternetSalesReason), щелкните столбец SalesOrderNumber и просмотрите в окне свойств свойство DataType для этого столбца данных.
Обратите внимание, что в качестве типа данных для столбца SalesOrderNumber указан тип данных string.
Просмотрите типы данных для других столбцов таблицы FactInternetSalesReason .
Обратите внимание, что для остальных двух столбцов этой таблицы указаны числовые типы данных.
На панели Таблицы щелкните правой кнопкой мыши таблицу InternetSalesReason (dbo.FactInternetSalesReason) и выберите пункт Просмотр данных.
Обратите внимание, что для каждого номера строки каждого заказа значение ключа указывает причину покупки данной позиции линии, как показано на следующем рисунке.
Использовавшийся ранее обходной путь
В версиях Power BI Desktop, предшествующих июльскому выпуску 2018 г., пользователи не могли создать прямую связь между такими таблицами. Обычным решением этой проблемы были следующие действия.
-
Создание третьей таблицы, содержащей только уникальные идентификаторы штатов. Это может быть следующее.
- Вычисляемая таблица (определяется на языке выражений анализа данных ).
- Таблица на основе запроса, который определен в редакторе запросов; он может отображать уникальные идентификаторы, извлеченные из одной из таблиц.
- Объединенный полный набор.
-
Затем с помощью обычных связей многие к одному выполняется связывание двух исходных таблиц с этой новой таблицей.
Можно оставить таблицу возможного решения видимой. Кроме того, можно скрыть таблицу возможного решения, чтобы она не отображалась в списке Поля. Если скрыть таблицу, обычно для связей многие к одному включается фильтрация в обоих направлениях, что дает возможность использовать поле «Штат» любой из таблиц. Дальнейшая перекрестная фильтрация распространится на другую таблицу. Этот подход показан на следующем рисунке:
Визуальный элемент с отображением поля State (из таблицы CityData) вместе с общей численностью населения (Population) и общим объемом продаж (Sales) будет выглядеть следующим образом.
Примечание
При заданном использовании штата из таблицы CityData в решении в этой таблице перечисляются только соответствующие штаты (таким образом, штат Техас исключается). Кроме того, в отличие от связей многие к одному, хотя итоговая строка содержит весь Объем продаж (включая штат Техас), в подробные сведения не включается пустая строка, отвечающая за такие несовпадающие строки. Аналогично, не будет пустой строки, соответствующей каким-либо продажам, которым соответствует значение NULL поля Штат.
Предположим, что вы также добавляете «Город» в этот визуальный элемент. Несмотря на то что население в расчете на значение «Город» известно, значение объема продаж, показанное для «Город», просто повторит значение объема продаж для соответствующего штата. Этот сценарий обычно происходит, когда группирование столбцов не связано с некоторой статистической мерой, как показано ниже.
Предположим, что вы определили новую таблицу «Продажи» как сочетание штатов здесь и сделали ее видимой в списке Поля. Тот же визуальный элемент будет отображать штат (в новой таблице), общее население и общий объем продаж.
Как вы видите, включен штат TX —с данными продаж, но неизвестными данными о населении —и —Нью-Йорк с известным населением, но неизвестными данными —о продажах. Этот способ не оптимален и вызывает множество проблем. Связи с кратностью «многие ко многим» позволяют решить эти проблемы, как описано в следующем разделе.
Как определить связи между таблицами
При создании связи между таблицами связанные поля не должны иметь одни и те же имена. Однако связанные поля должны иметь один и тот же тип данных, если только поле первичного ключа не является полем AutoNumber. Вы можете сопоставить поле AutoNumber с полем Number, только если свойство FieldSize обоих совпадающих полей совпадает. Например, можно сопоставить поле AutoNumber и поле Number, если свойство theFieldSizeproperty обоих полей имеет значение Long Integer. Даже если оба совпадающих поля являются числовыми полями, они должны иметь параметр sameFieldSizeproperty.
Как определить связи «один ко многим» или «один к одному»
Чтобы создать связь «один ко многим» или «один к одному», выполните следующие действия.
-
Закройте все таблицы. Нельзя создавать или изменять связи между открытыми таблицами.
-
В Access 2002 и Access 2003 выполните следующие действия.
- Нажмите F11, чтобы переключиться в окно базы данных.
- В меню Инструменты выберите Связи.
В Access 2007, Access 2010 или Access 2013 нажмите Связи в группе Показать/Скрыть на вкладке Инструменты базы данных.
-
Если вы еще не определили какие-либо связи в базе данных, автоматически отобразится диалоговое окно Показать таблицу. Если вы хотите добавить таблицы, которые нужно связать, но диалоговое окно Добавление таблицы не отображается, нажмите Добавить таблицу в меню Связи.
-
Дважды щелкните имена таблиц, которые необходимо связать, а затем закройте диалоговое окно Добавление таблицы. Чтобы создать связь между одной и той же таблицей, добавьте эту таблицу два раза.
-
Перетащите поле, которое вы хотите связать, из одной таблицы в связанное поле в другой таблице. Чтобы перетащить несколько полей, нажмите Ctrl, нажмите на каждое поле, а затем перетащите их.
В большинстве случаев вы перетаскиваете поле первичного ключа (это поле отображается жирным текстом) из одной таблицы в аналогичное поле (это поле часто имеет одно и то же имя), которое называется внешним ключом в другой таблице.
-
Откроется диалоговое окно Изменение связей. Убедитесь, что имена полей, отображаемые в двух столбцах, верны. Вы можете изменить имена, если это необходимо.
При необходимости установите параметры связей. Если вам нужна информация о конкретном элементе в диалоговом окне Изменение связей, нажмите кнопку со знаком вопроса, а затем щелкните элемент. (Эти параметры будут подробно описаны ниже в этой статье.)
-
Нажмите кнопку Создать, чтобы создать связь.
-
Повторите шаги с 4 по 7 для каждой пары таблиц, которые вы хотите связать.
При закрытии диалогового окна Изменение связей Access спрашивает, хотите ли вы сохранить макет. Сохраняете ли вы макет или не сохраняете макет, созданные вами связи сохраняются в базе данных.
Примечание
Можно создавать связи не только в таблицах, но и в запросах. Однако целостность данных связывания не обеспечивается с помощью запросов.
Как определить связь «многие ко многим»
Чтобы создать связь «многие ко многим», выполните следующие действия.
-
Создайте две таблицы, которые будут иметь связь «многие ко многим».
-
Создайте третью таблицу. Это стыковочная таблица. В таблице соединения добавьте новые поля, которые имеют те же определения, что и основные ключевые поля из каждой таблицы, созданной в шаге 1. В связующей таблице основные ключевые поля функционируют как внешние ключи. Вы можете добавить другие поля в связующую таблицу, так же, как и в любую другую таблицу.
-
В связующей таблице установите первичный ключ, чтобы включить основные ключевые поля из двух других таблиц. Например, в связующей таблице «TitleAuthors» первичный ключ будет состоять из полей OrderID и ProductID.
Примечание
Чтобы создать первичный ключ, выполните следующие действия:
-
Откройте таблицу в Конструкторе.
-
Выберите поле или поля, которые вы хотите определить в качестве первичного ключа. Чтобы выбрать одно поле, нажмите на селектор строки для нужного поля. Чтобы выбрать несколько полей, удерживайте клавишу Ctrl, а затем нажмите селектор строки для каждого поля.
-
В Access 2002 или в Access 2003 нажмите на Первичный ключ на панели инструментов.
В Access 2007 нажмите на Первичный ключ в группе Инструменты на вкладке Дизайн.
Примечание
Если вы хотите, чтобы порядок полей в первичном ключе с несколькими полями отличался от порядка этих полей в таблице, нажмите Индексы на панели инструментов для отображения диалогового окна Indexes, а затем заново упорядочите имена полей для индекса с именем PrimaryKey.
-
-
Определите связь один-ко-многим между каждой основной и связующей таблицами.
Один-ко-многим или многие-к-одному
Это наиболее распространенный тип мощности, используемый в моделях данных. Этот тип количества элементов означает, что одна из таблиц имеет уникальные значения в каждой строке для поля отношения, а другая имеет несколько значений. Пример, который вы видели ранее между таблицами Stores и Sales на основе stor_id, представляет собой отношение «многие-к-одному» или «один-ко-многим».
Есть два способа назвать эти отношения: один-ко-многим или многие-к-одному. Зависит от того, что является исходной и целевой таблицей.
Например, приведенная ниже конфигурация означает, что от таблицы Sales до таблицы Stores есть отношение «многие-к-одному».
А ниже показано отношение «один-ко-многим» от таблицы Stores к таблице Sales:
Эти две таблицы заканчиваются созданием таких отношений:
Это означает, что нет разницы в отношении «один-ко-многим» или «многие-к-одному», кроме порядка, в котором вы читаете это. Если вы посмотрите от таблицы Stores, у вас будет отношение «один ко многим». Если вы посмотрите на это с точки зрения таблицы Sales, у вас будет отношение «многие к одному». И оба они одинаковы, без какой-либо разницы. Так что теперь, в этой статье, всякий раз, когда вы читаете «многие к одному» или «один ко многим», вы знаете, что вы можете читать их и наоборот.
В остальной части статьи мы будем использовать термины таблиц FACT и DIMENSION, которые мы объясним отдельно в другой статье. А пока вот краткое объяснение терминов:
- Таблица фактов (FACT): таблица с числовыми значениями, которые нам нужны либо в агрегированном уровне, либо в подробном выводе. Поля из этой таблицы обычно используются в качестве раздела VALUE визуальных элементов в Power BI.
- Таблица измерений (DIMENSION): таблица, содержащая описательную информацию, которая используется для нарезки данных таблицы фактов. Поля из этой таблицы часто используются в качестве слайсеров, фильтров или осей визуалов в Power BI.
Отношение «многие к одному» между таблицами фактов и измерений
“Многие-к-одному” — это отношение, обычно используемое между таблицей фактов и таблицами измерений. Приведенный выше пример находится между таблицами Sales (таблица фактов) и Stores (таблица измерений). Если мы приведем еще одну таблицу в модель: Titles (на основе title_id в обеих таблицах: Sales и Titles), то вы увидите, что существует тот же шаблон отношений «многие-к-одному».
Этот тип отношений, хотя часто используется во многих моделях, всегда может быть предметом исследования для лучшего моделирования. В идеальной модели данных вы НЕ должны иметь отношения между двумя таблицами измерений напрямую. Давайте проверим это на примере.
Допустим, модель отличается от того, что вы видели в этом примере: таблица Sales, таблица Product и две таблицы для информации о категории и подкатегории продукта:
Как вы можете видеть на приведенной выше диаграмме отношений, все отношения — “многие-к-одному”. Что хорошо. Однако, если вы хотите нарезать данные таблицы фактов (например, SalesAmount) по полю из таблицы DimProductCategory (например, по имени ProductCategory), для обработки потребуется три отношения:
Лучшей моделью было бы объединение таблиц категорий и подкатегорий с продуктом и наличие единого отношения «многие к одному» из таблицы фактов в таблицу DimProduct. Подробнее — в ссылке выше.
Извлечение данных для связи «многие ко многим» (SELECT)
Возникает логичный вопрос — как же получать данные из базы, используя таблицу связи?
Есть разные варианты для разных ситуаций, которые мы сейчас рассмотрим, но прежде чем проиллюстрировать их, заполните созданные выше таблицы (чтобы вы тоже могли поэкспериментировать с запросами)
Рассмотрим задачу извлечения участников, связанных с данной номинацией — или короче «номинации, и всех, кто подал в неё заявки» (алгоритм извлечения данных в обратную сторону — т.е. «участик и все его номинации» абсолютно аналогичен).
На практике приходится сталкиваться с двумя базовыми ситуациями:
- Извлечение одной сущности номинации и связанных с ней участников
- Извлечение списка сущностей номинаций и связанных с каждой из номинаций участников (т.е. фактически список участников для каждого элемента из списка номинаций).
Извлечение связанных (многие-ко-многим) данных для одной сущности
Пусть у нас известен id () номинации и мы хотим получить сведения об этой номинации и всех участниках в ней.
Во-первых, сделать это можно двумя sql запросами:
- Сначала просто получим кортеж этой номинации:
mysql> SELECT * FROM Nominations WHERE nominationID=4; +--------------+-----------------------------+ | nominationID | title | +--------------+-----------------------------+ | 4 | Лучшее пособие | +--------------+-----------------------------+
- После, опять же зная 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, а минусом то, что с этим значением уже нельзя работать как с массивом, явно не преобразовав.
Поведение отношений
Можно настроить поведение отношения 1:N для поддержки бизнес-правил организации. Почему это может потребоваться? Рассмотрим пример.
Допустим, у вас новый продавец и требуется назначить ему несколько существующих возможных сделок, в данное время назначенных другому продавцу. Каждая запись возможной сделки может иметь несколько действий задач, связанных с ней. Можно легко найти активные возможные сделки, которые требуется переназначить, и назначить их новому продавцу. Но что произойдет с действиями задач, связанными с возможными сделками? Хотелось бы вам открывать каждую задачу и указывать, должна ли она также быть назначена новому продавцу? Скорее всего, нет. Вместо этого можно разрешить отношению применить некоторые стандартные правила автоматически. Эти правила применяются только к записям задач, связанным с возможными сделками, которые вы переназначаете. Это отношение сущностей называется Opportunity_Tasks. Можно выполнить следующие действия:
-
Переназначить все активные задачи.
-
Переназначить все задачи. Это поведение принимается по умолчанию.
-
Не переназначать задачи.
-
Переназначить все задачи, которые в данный момент назначены бывшему владельцу возможной сделки.
Отношение может управлять тем, как действия, выполняемые с записью для записи основной сущности, распространяются на все записи связанной сущности. Действия и возможное поведение приведены в следующей таблице.
| Действие | Описание | Возможное поведение |
|---|---|---|
| Назначение | Что должно произойти, когда меняется владелец записи основной сущности? | — Каскад для активных- Каскад для всех- Без каскадных- Каскад для ответств. |
| Общий доступ | Что должно произойти при совместном использовании записи основной сущности? | — Каскад для активных- Каскад для всех- Без каскадных- Каскад для ответств. |
| Отмена общего доступа | Что должно произойти при отмене совместного использования записи основной сущности? | — Каскад для активных- Каскад для всех- Без каскадных- Каскад для ответств. |
| Переподчинение | Что должно произойти, когда меняется значение поля поиска для отношения родительского типа в записи основной сущности? Отношение родительского типа — это отношение, использующее Каскад для всех для всех действий. — Каскад для активных- Каскад для всех- Без каскадных- Каскад для ответств. | |
| Удаление | Что должно произойти при удалении записи основной сущности? | — Каскад для всех- Удалить связь- Ограничить удаление |
| Слияние | Что должно произойти, когда запись основной сущности объединяется с другой записью? | — Каскад для всех- Без каскадных |
Каждое из этих действий можно настроить для управления тем, как действия будут распространяться на записи, связанные с записью основной сущности отношением сущностей 1:N. Параметры поведения представлены в следующей таблице.
| Поведение | Описание |
|---|---|
| Передавать активным | Выполнение действия для всех активных записей связанной сущности. |
| Передавать всем | Выполнение действия для всех записей связанной сущности. |
| Не передавать никому | Никакие действия не выполняются. |
| Удалить ссылку | Удаление значения поля поиска для всех записей связанной сущности. |
| Ограничить удаление | Блокировка возможности удаления записи основной сущности, если существуют связанные записи. |
| Передавать владельцу | Выполнение действия для всех записей связанной сущности тем же пользователем, что и пользователь записи основной сущности. |
Способ применения этих действий в отношении можно классифицировать и применить с помощью значений поля Тип поведения, описанных в следующей таблице.
| Значение поля | Описание |
|---|---|
| Родительский | Все действия используют поведение Передавать всем. |
| Ссылочный | Действия Назначить, Предоставить общий доступ, Отменить общий доступ и Переподчинение используют поведение Не передавать никому. Действие Удалить использует поведение Удалить ссылку. Действие Объединить использует поведение Передавать всем. |
| Ссылочный, ограничить удаление | Аналогично значению Ссылочный за исключением того, что действие Удалить использует поведение Ограничить удаление. |
| Настраиваемое каскадное | Отдельное поведение можно назначить для каждого действия. Если выбранные значения соответствуют любым другим категориям Тип поведения, значение изменится на значение Тип поведения. |
Создание и изменение отношений 1:N между сущностями
Откройте обозреватель решений.
В разделе Компоненты раскройте узел Сущности, затем раскройте сущность, с которой требуется работать.
Выберите Отношения 1:N.
Чтобы изменить отношение или просмотреть сведения для отношения, выберите отношение и нажмите на панели инструментов «Действия» кнопку Другие действия, затем выберите Изменить.
— ИЛИ —
Чтобы добавить новое отношение, выберите Создать отношение «один ко многим».
Важно!
Если кнопка Создать отношение «один ко многим» не отображается на панели инструментов «Действия», то создать отношение 1:N для этой сущности невозможно.
Для нового отношения в разделе Определение отношения выберите в списке Связанная сущность сущность для связывания.
Примечание
При указании связанной сущности задается значение по умолчанию в поле Имя. Если изменить связанную сущность перед ее сохранением, соответственно изменится и значение поля Имя.
Выберите, будет ли это поле доступно для поиска или нет.
В разделе Поле поиска укажите значение для поля в поле Отображаемое имя.
Важно!
При указании значения Отображаемое имя задается значение по умолчанию в поле Имя
Если изменить Отображаемое имя поля поиска перед сохранением данных, значение в поле Имя не изменится. Поэтому необходимо ввести в поле Имя информативное значение перед сохранением данных.
В списке Требование поля выберите вариант, чтобы указать требования к данным для поля перед сохранением записи.
В разделе Элемент области переходов для основной сущности в списке Параметры отображения выберите вариант отображения связанных представлений для пользовательской метки.
В разделе Поведение отношений выберите в списке Тип отношений один из следующих вариантов.
Родительское. В родительском отношении между двумя сущностями любое действие, выполняемое над записью основной (родительской) сущности, также выполняется над всеми связанными с ней записями дочерних сущностей.
Ссылочное. При ссылочном отношении между двумя сущностями можно переходить к любым связанным записям, но действия, выполняемые над одной записью, не применяются к другим.
Ссылочное с ограниченным удалением. В ссылоном отношении с ограничением удаления можно переходить к любым связанным записям. Действия, выполняемые над родительской записью, не будут выполняться над дочерней, но пока она существует, удалить родительскую запись будет невозможно. Учтите, что запись нельзя удалить, если имеются связанные с ней записи.
Настраиваемое каскадное. В настраиваемом каскадном отношении между двумя сущностями выбирается поведение, связанное с каждым из наборов возможных действий.
Важно!
Если выбрать поведения для действий, совпадающие с поведениями для действий, связанными с другим Типом поведения, то при сохранении отношения значение Тип поведения будет автоматически установлено равным такому совпадающему типу.
Дополнительные сведения:
-
Выберите Сохранить и закрыть, чтобы закрыть форму Отношение.
-
Выполнив настройки, опубликуйте их:
-
Чтобы опубликовать настройки только для компонента, изменяемого в данный момент, на панели инструментов «Действия» выберите Опубликовать.
-
Чтобы опубликовать настройки для всех неопубликованных компонентов одновременно, на панели навигации или в области переходов выберите Сущности, затем на панели инструментов «Действия» выберите Опубликовать все настройки.
-
Примечание
- Настраиваемая сущность не может быть основной в каскадном отношении со связанной системной сущностью. Это означает, что между основной настраиваемой сущностью и связанной системной сущностью не может быть отношений с каким-либо из действий, установленным в «Передавать всем», «Передавать активным» или «Передавать владельцу».
- У новых отношений действие не может иметь значение Передавать всем, Передавать активным или Передавать владельцу, если связанная сущность в этом отношении уже является связанной сущностью в любом другом отношении, действие которого имеет значение Передавать всем, Передавать активным или Передавать владельцу. Это позволяет избежать создания отношений с несколькими родительскими сущностями.
- После каждого изменения элементов пользовательского интерфейса или внедрения скриптов формы для сущности необходима публикация изменений. Все изменения в схеме данных приложения, таких как настраиваемые сущности, связи или поля, применяются сразу.
- Если отношение является частью управляемого решения, разработчик решения может ограничить настройку отношения пользователями.
- Установка решения или публикация настроек может помешать нормальной работе системы. Рекомендуется запланировать импорт решения в оптимальный для пользователей период.
Ассоциация ManyToOne / OneToMany.
Предположим, что каждый продукт в вашей заявке относится только к одной категории. В этом случае вам понадобится класс Category и способ связать объект Product объектом Category.
Начните с создания Category с полем name:
php bin/console make:entity Category New property name (press <return> to stop adding fields): > name Field type (enter ? to see all types) : > string Field length : > 255 Can this field be null in the database (nullable) (yes/no) : > no New property name (press <return> to stop adding fields): > (press enter again to finish)
Это сгенерирует ваш новый класс сущности:
// src/Entity/Category.php
// ...
class Category
{
/**
* @ORM\Id
* @ORM\GeneratedValue
* @ORM\Column(type="integer")
*/
private $id;
/**
* @ORM\Column(type="string")
*/
private $name;
// ... getters and setters
}
Что такое мощность отношений?
Когда вы создаете отношение между двумя таблицами, вы получаете два значения, которые могут быть 1 или * на двух концах отношения между двумя таблицами, называемые кардинальностью или мощностью отношений.
Два значения 1 или * говорят о том, что поле в этой взаимосвязи имеет определенное число значения на строку в этой таблице. Давайте проверим это на примере.
В таблице Stores у нас есть одно уникальное значение для stor_id на строку.
Таким образом, если это поле участвует в одной стороне отношения, то эта сторона примет 1 в качестве показателя кардинальности, который называется ОДНОЙ стороной отношения.
Однако stor_id в таблице Sales не уникален для каждой строки данных в этой таблице. У нас есть несколько строк для каждого stor_id. Или скажем так; в каждом магазине происходит несколько торговых транзакций (что, конечно, нормально):
Таким образом, если stor_id в таблице Sales является частью отношения, эта сторона отношения станет *, или то, что мы называем «МНОЖЕСТВЕННОЙ» стороной отношения.
Итак, основываясь на том, что мы знаем в данный момент, если мы создадим отношение на основе stor_id между двумя таблицами Sales и Stores, то получим вывод:
Эти отношения могут быть прочитаны двумя способами;
- Отношение “один-ко-многим” (1- *) из таблицы магазинов в таблицу продаж
- Отношение «многие-к-одному» (* -1) из таблицы продаж в таблицу магазинов
Они оба, конечно, одинаковы, и они будут выглядеть точно так же, как каждое из них в представлении схемы. Теперь, когда вы знаете, что такое мощность отношений, давайте изучим все виды мощности.
