Опишите способ преобразования связи многие ко многим

4.10.4. Преобразование связи «многие-ко-многим»

Как известно, связи M:M между таблицами баз данных в реляционной модели не поддерживаются. Если при создании связи M:M в логической модели в меню Model/Model Properties была отмечена позиция Many-to-Many Relationships with Association Table, топри переходе к физической модели вместо связи M:M будет создана связующая таблица, с которой таблицы, соответствующие сущностям, связанным отношением M:M, будут связаны обычной для реляционных моделей связью 1:M.
На рис. 4.83 изображен соответствующий фрагмент модели физического уровня, получившийся путем автоматического преобразования связи М:М (см. рис. 4.47) в связующую (ассоциативную) таблицу.

Рис. 4.83. Создание связующей таблицы при преобразовании связи М:М

Полученную таблицу можно переименовать, назвав ее, например, «Владение предметом».
Если при создании связи M:M в логической модели в меню Model/Model Properties позиция Many-to-Many Relationships with Association Table не была отмечена, то при переходе к физической модели связующая таблица создана не будет. Если все-таки надо, чтобы такая таблица была создана (а в подавляющем большинстве случаев это именно так), то можно воспользоваться возможностью трансформации модели. Для этого надо выделить связь и нажать на кнопку Many to Many Transform. И далее, следуя подсказкам системы, надо задать имя создаваемой связующей таблицы и имя трансформации.
В процессе создании ER-модели может возникнуть ситуация, что, уточняя и расширяя модель, в связующую таблицу будут введены дополнительные колонки (т.е. для связи будут заданы характеризующие ее свойства). Если не предпринять дополнительных действий, то в логической модели эти изменения не будут видны. Чтобы они стали видны и в логической модели, надо в «эксплоере» выбрать позицию Transform/Delete/Resolve Transform (рис. 4.84).

Рис. 4.84. Выбор позиции Resolve Transform/Reverse Transform

Несмотря на то, что в ERWin есть возможность использовать Many to Many Transform для каждой связи М:М, лучше задать признак автотрансформации в свойствах модели (см. рис. 4.46), так как обычно связь М:М в физической модели передается связующей таблицей. Если же связь М:М не отображается в физической модели, то скорее всего ее надо удалить из логической модели.

Источник

Трансформация связи «многие-ко-многим»

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

Сначала создадим новую сущность КУРС с атрибутами Номер курса и Название курса. С помощью кнопки свяжем отношения РЕБЕНОК и КУРС связью «многие-ко-многим». Результат показан на рис. 1.41

рис. 1.41.Связывание сущностей связью «многие-ко-многим»

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

Для преобразования связи «многие ко многим» принудительно необходимо щелкнуть по связи правой кнопкой мыши и выбрать пункт меню Create Association Table или щелкнут по кнопке на панели инструментов. В результате появится мастер преобразования связи «многие-ко-многим», окно которого приведено на рис. 1.42.

рис. 1.42. Мастер преобразования связи «многие-ко-многим»

Диалог Many-To-Many Relationship Transform Wizard предлагает 4 шага для преобразования связи. Для перехода к следующему шагу надо щелкнуть по кнопке Next (Далее). На втором и третьем шаге следует задать имя преобразования и имя вновь создаваемой таблицы (ЗАПИСЬ). Результат трансформации представлен на рис. 1.43. В результате появилась переходная сущность, в состав первичных атрибутов которой входят первичные атрибуты двух исходных сущностей.

рис. 1.43. Результат трансформации связи «многие-ко-многим»

Следует отметить, что из сущности РЕБЕНОК в сущность ЗАПИСЬ мигрировали два атрибута составного первичного ключа (Код ребенка и Табельный номер). Очевидно, что атрибут Табельный номер является лишним и не несет для данной сущности никакой информации. Следовательно, необходимо сделать так, чтобы в итоге в сущность ЗАПИСЬ из сущности РЕБЕНОК мигрировал только атрибут Код ребенка.

ERwin позволяет создавать связи, при которых в дочернюю сущность мигрируют атрибуты одного из альтернативных ключей. Для создания такой связи необходимо создать идентифицирующую или неидентифицирующую связь, шелкнуть по связи правой кнопкой мыши, выбрать пункт меню Relationship Properties и в списке выбора Migrated Key (диалог Relationships, вкладка Rolename) выбрать ключ, атрибуты которого будут мигрировать в дочернюю сущность. В нашем случае в качестве мигрирующего ключа выберем альтернативный ключ Код ребенка. Выполнения данных действий приведено на рис. 1.44.

рис. 1.44. Выбор мигрирующих атрибутов

В итоге, получим новую структуру сущности ЗАПИСЬ, представленную на рис. 1.45.

рис. 1.45. Результат изменения мигрирующих атрибутов

Добавим в сущность ЗАПИСЬ еще один атрибут Оплата (рис. 1.46).

рис. 1.46. Результат добавления нового атрибута

Результат построения логической и физической моделей всей предметной области в нотации IDEF1X приведен соответственно на рис. 1.47 и рис. 1.48.

рис. 1.47. Логическая модель предметной области

рис. 1.48. Физическая модель предметной области

Настроить внешний вид логической модели можно, вызвав контекстное меню из пустого места диаграммы и в пунктах Entity Display (для настройки внешнего вида сущности) и Relationship Display (для настройки внешнего вида связи) выбрать необходимые элементы для отображения. Настроить внешний вид физической модели можно, вызвав контекстное меню из пустого места диаграммы и в пункте Table Display также выбрать необходимые элементы для отображения.

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

1. Маклаков С. В. Создание информационных систем с AllFusion Modeling Suite. – 2-е изд., доп. – М.: Издательство Диалог-МИФИ, 2007 – 400 с.

2. Проектирование экономических информационных систем: Учебник/ Г. Н. Смирнова, А. А. Сорокин, Ю. Ф. Тельнов; под ред. Ю. Ф. Тельнова. – М.: Финансы и Статистика, 2003. – 512 с.

3. Хомоненко А. Д., Цыганков В. М., Мальцев М. Г. Базы данных: Учебник для высших учебных заведений / под. Ред. Проф. А. Д. Хомоненко. – 5-е изд., доп. – М.: Бином-Пресс; СПб.: КОРОНА принт, 2006. – 736 с.

Источник

Применение связей «многие ко многим» в Power BI Desktop

С помощью связей с кратностью «многие ко многим» в Power BI Desktop можно соединять таблицы, использующие кратность многие ко многим. Это позволяет более простым и интуитивно понятным образом создавать модели данных, которые содержат несколько источников данных. Связи с кратностью «многие ко многим» являются частью более широкого набора возможностей составных моделей в Power BI Desktop.

Создание связей с кратностью «многие ко многим» в Power BI Desktop реализовано в наборе из трех связанных функций.

Составные модели. Составные модели позволяют включить в отчет несколько подключений к данным в любом сочетании, в том числе подключения DirectQuery или импорт. Дополнительные сведения см. в статье Использование составных моделей в Power BI Desktop.

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

Режим хранения Он позволяет указать, в каких визуальных элементах будут использоваться запросы к источникам данных серверной части. Визуальные элементы, которым не нужны такие запросы, всегда импортируются, даже если они основаны на DirectQuery. Эта функция помогает повысить производительность и снизить нагрузку на серверную часть. Ранее даже простые визуальные элементы, например срезы, инициировали запросы к серверным источникам. Дополнительные сведения см. в статье Режим хранения в Power BI Desktop.

Проблемы, решаемые связями с кратностью «многие ко многим»

Прежде чем стали доступны связи с кратностью «многие ко многим» , связь между двумя таблицами определялась в Power BI. Хотя бы один из столбцов таблиц, участвующих в связи, должен был содержать уникальные значения. Часто столбцы не содержали уникальные значения.

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

Использование связей с кратностью «многие ко многим»

При определении связи между двумя таблицами в Power BI необходимо определить кратность связи. Например, связь между ProductSales и Product—с использованием столбцов ProductSales[ProductCode] и Product[ProductCode]— будет определена как многие к одному. Мы определяем связь таким образом, поскольку имеется много продаж каждого продукта и столбец (ProductCode) таблицы Product является уникальным. При определении кратности связи как многие к одному, один ко многим или один к одному Power BI проверяет ее, чтобы кратность соответствовала фактическим данным.

Например, рассмотрим простую модель на изображении ниже.

Теперь представим, что в таблице Product отображаются лишь две строки, как показано:

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

Столбцы ProductName и Price (из таблицы Product), наряду с общим значением Qty (количество) для каждого продукта (из таблицы ProductSales), будут отображены, как показано на следующем изображении.

Как показано на предыдущем рисунке, есть пустая строка ProductName, которая связана с продажами продукта C. Она отвечает за следующее.

Все строки таблицы ProductSales, для которых не существует соответствующей строки в таблице Product. Существует проблема целостности данных, как показано в этом примере для продукта C.

Любые строки в таблице ProductSales, для которых столбец внешнего ключа имеет значение NULL.

По этим причинам в обоих случаях пустая строка отвечает за продажи, в которых ProductName и Price неизвестны.

Бывают случаи, когда таблицы соединены по двум столбцам и при этом ни один из столбцов не уникален. Например, рассмотрим следующие две таблицы.

Таблица Sales содержит данные о продажах по штатам (State), где в каждой строке указан объем продаж, соответствующий типу продаж в указанном штате (включая штаты CA, WA и TX).

Таблица CityData содержит данные по городам, в том числе сведения о населении и штате (такие как Калифорния, Вашингтон и Нью-Йорк).

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

Использовавшийся ранее обходной путь

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

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

Вычисляемая таблица (определяется на языке выражений анализа данных [DAX]).
Таблица на основе запроса, который определен в Редакторе Power Query; он может отображать уникальные идентификаторы, извлеченные из одной из таблиц.
Объединенный полный набор.

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

Можно оставить таблицу возможного решения видимой. Кроме того, можно скрыть таблицу возможного решения, чтобы она не отображалась в списке Поля. Если скрыть таблицу, обычно для связей многие к одному включается фильтрация в обоих направлениях, что дает возможность использовать поле «Штат» любой из таблиц. Дальнейшая перекрестная фильтрация распространится на другую таблицу. Этот подход показан на следующем рисунке:

Визуальный элемент с отображением поля State (из таблицы CityData) вместе с общей численностью населения (Population) и общим объемом продаж (Sales) будет выглядеть следующим образом.

При заданном использовании штата из таблицы CityData в решении в этой таблице перечисляются только соответствующие штаты (таким образом, штат Техас исключается). Кроме того, в отличие от связей многие к одному, хотя итоговая строка содержит весь Объем продаж (включая штат Техас), в подробные сведения не включается пустая строка, отвечающая за такие несовпадающие строки. Аналогично, не будет пустой строки, соответствующей каким-либо продажам, которым соответствует значение NULL поля Штат.

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

Предположим, что вы определили новую таблицу «Продажи» как сочетание штатов здесь и сделали ее видимой в списке Поля. Тот же визуальный элемент будет отображать штат (в новой таблице), общее население и общий объем продаж.

Как вы видите, включен штат TX —с данными продаж, но неизвестными данными о населении —и —Нью-Йорк с известным населением, но неизвестными данными —о продажах. Этот способ не оптимален и вызывает множество проблем. Связи с кратностью «многие ко многим» позволяют решить эти проблемы, как описано в следующем разделе.

Использование связей с кратностью «многие ко многим» вместо временного решения

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

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

Например, при создании связи непосредственно между CityData и Sales—, где фильтры должны применяться от CityData к Sales, в —Power BI Desktop отображается диалоговое окно Изменение связи.

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

Основные различия между связями с кратностью «многие ко многим» и более распространенными связями многие к одному заключается в следующем.

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

Использовать функцию RELATED() (так как связанными могут быть несколько строк) не удастся.

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

Визуальный элемент с отображением штата, объема продаж и общего объема продаж будет таким, как на рисунке ниже.

Учитывая перечисленные различия, убедитесь, что вычисления, использующие ALL(

) , такие как % от общей суммы, возвращают желаемые результаты.

Дальнейшие действия

Дополнительные сведения о составных моделях и DirectQuery см. в следующих статьях:

Источник

Опишите способ преобразования связи многие ко многим