Отношение has a: C++. Типы отношений между классами: is-a, has-a, uses. Примеры. Наследование. Основные понятия

ооп — Агрегация и композиция

Существует несколько видов взаимодействия объектов, объединенных под общим понятием «Has-A Relationship» или «Part Of Relationship». Это отношение означает, что один объект является составной частью другого объекта.

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

Давайте рассмотрим пример из .NET Framework, чтобы увидеть, какие ограничения/последствия несут эти отношения: StringWriter + StringBuilder.

Класс StringWriter — это специализированная версия класса TextWriter, которые активно используются при сериализации и для получения текстового представления объектов.

Конкретно StringWriter создает строковое представление объекта или графа объектов и опирается на экземпляр

StringBuilder в своей работе. Т.е. мы можем сказать, что ‘StringWriter HAS A StringBuilder’ или ‘StringBuilder is part of StringWriter’. Теперь давайте посмотрим, как решить, должен ли StringWriter получать экземпляр StringBuilder-а извне или создавать его?

С одной стороны, нам, как клиенту класса StringWriter часто бывает все равно, что именно используется внутри этого класса для получения строкового представления. Это значит, что с точки зрения простоты использования лучше, чтобы StringWriter создавал экземпляр StringBuilder-а самостоятельно.

Но, с другой стороны, конкретный объект StringWriter-а может отвечать лишь за получения части строкового представления, а другая часть строки может вычисляться другим способом. С этой точки зрения, лучше, чтобы StringWriter принимал экземлпяр StringBuilder-а в конструкторе. Это же справедливо и для высоконагруженных систем, в которых разумно использование пула объектов.

Поскольку StringWriter — это библиотечный класс, который должен поддерживать оба сценария, то у него есть перегруженные версии конструктора: один из них создает StringBuilder внутри, а другой — принимает его снаружи.

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

Композиция: объект A управляет временем жизни объекта B

Плюсы:

• Композиция позволяет скрыть отношение использования объектов от глаз клиента.

• Делает API использования класса более простым и позволяет перейти от использования одного класса, к другому (например, StringWriter мог бы поменять реализацию и начать использовать другой тип, например

  CustomStringBuilder).

Минусы:

• Отношение достаточно жесткое, поскольку один объект должен уметь создавать другой: он должен знать конкретный тип и иметь доступ к функции создания. Композиция не позволяет использовать интерфейсы (без привлечения фабрик) и требует, чтобы класс имел доступ к конструктору другого класса: представьте, что конструктор StringBuilder-а является внутренним или же это интерфейс IStringBuilder и только клиенский код знает, какой экземпляр должен использоваться здесь и сейчас.

Агрегация: объект А получает ссылку на объект B

Плюсы:

• Более слабая связанность между объектом и его клиентом. Теперь мы можем использовать интерфейсы и одному объекту не нужно знать, как именно создавать другой объект.

• Большая гибкость. Вытекает из первого пункта

Минусы:

• Выставление наружу деталей реализации. Поскольку клиент класса должен предоставить зависимость в момент создания объекта (передать экземпляр StringBuilder-а в момент создания StringWriter-а, то сам факт этого отношения становится известен клиенту.

• Из первого пункта вытекает увеличение сложности в работе клиентов, а также большая «жесткость» решения в долгосрочной перспективе. Теперь автор класса TextWriter уже не может принять решение самостоятельно и перейти от StringBuilder-а к чему-то другому. Да, можно «добавить еще один уровень абстракции» и выделить интерфейс IStringBuilder, но разорвать это отношение совсем будет невозможно без поломки всех существующих клиентов.

В заключении: дизайн — это поиск компромисса между различными факторами. Композиция проще с точки зрения клиентов класса, но налагает определенные ограничения: «целое» должно уметь создавать «составную часть». Агрегация гибче, но налагает другие ограничения: теперь «целое» не скрывает о существовании «составной части», а значит и не сможет заменить ее на другую «составную часть» в будущем.

P.S. Если очень хочется использовать пример из реального мира, то для объяснения композиции и агрегации может подойти … отвертка. Если отвертка цельная, т.е. ручка и насадка намертво связаны друг с другом, то мы имеем отношение композиции. Если же насадка съемная и может существовать без ручки или же использоваться с другой ручкой, то мы имеем отношение агрегации.

НОУ ИНТУИТ | Лекция | Отношения между классами. Клиенты и наследники

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

Ключевые слова: класс, тип данных, отношение, объект, ПО, отношение вложенности, встраивания, наследование, отношение наследования, определение, прямой, word, приложение, слово, библиотека FCL, длина цепочки, число классов, командная кнопка, class diagram, экземплярный метод, динамический метод, статическое поле, статический объект, сокрытие информации, VIP, динамическая структура данных, двусвязный, собственный метод, переопределение метода, главная кнопочная форма, скрытое поле, родительский объект, перегруженный метод, перегрузка метода, контроль типов, формальный аргумент, сигнатура метода, класс сущностей, статическое связывание, связывание объектов, полиморфный метод, абстрактный метод, объектно-ориентированное проектирование, списковая структура, ArrayList, FCL

intuit.ru/2010/edi»>Проект к данной лекции Вы можете скачать здесь.

Отношения между классами

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

Классы программной системы находятся в определенных отношениях друг с другом. Два основных типа отношений между классами определены в ОО-системах. Первое отношение, «клиенты и поставщики», называется часто клиентским отношением или отношением вложенности (встраивания). Второе отношение, «родители и наследники», называется отношением наследования.

intuit.ru/2010/edi»>Определение 1. Классы A и В находятся в отношении «клиент — поставщик», если одним из полей класса В является объект класса А. Класс А называется поставщиком класса В, класс В называется клиентом класса А.

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

Определение 2. Классы А и В находятся в отношении «родитель — наследник», если при объявлении класса В класс А указан в качестве родительского класса. Класс А называется клиентом класса В, класс В называется наследником класса А.

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

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

Рис. 4.1. Графическое отображение отношений между классами

Оба отношения, наследования и вложенности, являются транзитивными. Если В — клиент А и С — клиент В, то отсюда следует, что С — клиент А. Если В — наследник А и С — наследник В, то отсюда следует, что С — наследник А.

Определения 1 и 2 задают прямых или непосредственных клиентов и поставщиков, прямых родителей и наследников. Вследствие транзитивности необходимо ввести понятие уровня. Прямые клиенты и поставщики, прямые родители и наследники относятся к соответствующему уровню 1 (клиенты уровня 1, поставщики уровня 1 и так далее).

Затем следует рекурсивное определение: прямой клиент клиента уровня k относится к уровню k+1.

Для отношения наследования используется терминология, заимствованная из естественного языка. Прямые классы-наследники часто называются сыновними или дочерними классами. Непрямые родители называются предками, а их непрямые наследники — потомками.

Замечу, что цепочки вложенности и наследования могут быть достаточно длинными. На практике вполне могут встречаться цепочки длины 10. Например, библиотечные классы, составляющие систему Microsoft Office, полностью построены на отношении вложенности. При программной работе с объектами Word можно начать с объекта, задающего приложение Word, и добраться до объекта, задающего отдельный символ в некотором слове некоторого предложения одного из открытых документов Word. Для выбора нужного объекта можно задать такую цепочку: приложение Word — коллекция документов — документ — область документа — коллекция абзацев — абзац — коллекция предложений — предложение — коллекция слов — слово — коллекция символов — символ.

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

Классы библиотеки FCL связаны как отношением вложенности, так и отношением наследования. Длинные цепочки наследования достаточно характерны для классов этой библиотеки.

Отношения «является» и «имеет»

При проектировании классов часто возникает вопрос, какое же отношение между классами нужно построить. Рассмотрим совсем простой пример двух классов — Square и Rectangle, описывающих квадраты и прямоугольники. Наверное, понятно, что эти классы следует связать скорее отношением наследования, чем вложенности; менее понятным остается вопрос, а какой из этих двух классов следует сделать родительским. Еще один пример двух классов — Car и Person, описывающих автомобиль и персону. Какими отношениями с этими классами должен быть связан класс Person_of_Car, описывающий владельца машины? Может ли он быть наследником обоих классов? Найти правильные ответы на эти вопросы проектирования классов помогает понимание того, что отношение «клиент — поставщик» задает

отношение «имеет» («has»), а отношение наследования задает отношение «является» («is a»). В случае классов Square и Rectangle понятно, что каждый объект квадрат «является» прямоугольником, поэтому между этими классами существует отношение наследования и родительским классом является класс Rectangle, а класс Square является его потомком.

В случае автомобилей, персон и владельцев авто также понятно, что владелец «имеет» автомобиль и «является» персоной. Поэтому класс Person_of_Car является клиентом класса Car и наследником класса Person.

Диаграмма классов

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

intuit.ru/2010/edi»>Рассмотрим начальный этап проектирования гипотетической программной системы, реализуемой в виде Windows-проекта. На этом этапе классы создаются, но без содержательной начинки. Но уже на этом этапе можно определить, какими отношениями классы связаны между собой.

В момент создания нового Windows-проекта автоматически строятся классы, отражающие специфику проектов такого типа. Так автоматически создается класс Program с точкой входа в проект — процедурой Main. Автоматически создается и класс Form1, являющийся прямым наследником класса Form из библиотеки FCL.

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

В процедуре Main автоматически создается объект класса MyForm, так что класс Program становится клиентом класса MyForm. При проектировании интерфейса формы и размещения в ней элементов управления соответствующий инструментарий — дизайнер форм — добавляет программный код в класс MyForm. Для каждого элемента управления в класс добавляется поле, представляющее объект класса, определяющего этот элемент управления. Так, класс MyForm становится клиентом многих классов, характеризующих элементы управления, расположенные на форме. Для простоты примера на форме размещена только одна командная кнопка «Пуск», так что в нашем примере класс MyForm является клиентом класса Button из библиотеки FCL.

Добавим теперь в проект собственные классы. Создадим класс Testing и сделаем объект этого класса полем класса MyForm. Класс Testing станет поставщиком для класса MyForm, а последний будет клиентом класса Testing. Объект класса Testing будет создаваться в обработчике события Click командной кнопки «Пуск». Добавим в класс Testing три поля — три объекта классов Student, OwnerOfCar и Square, что делает класс Testing клиентом этих трех классов, которые также добавим в наш проект. Классы Student и OwnerOfCar сделаем прямыми наследниками класса Person, а класс OwnerOfCar — клиентом класса Car. Свяжем отношением наследования три класса, задающие геометрические фигуры — Square, Rectangle и Figure. Квадрат «является» прямоугольником, а прямоугольник «является» геометрической фигурой. Класс Figure имеет поле center класса Point, что делает его клиентом класса Point.

Хотя текстовое описание классов проекта я старался сделать информативным, но графическое представление более наглядно. В Visual Studio 2008 есть инструментарий, позволяющий строить диаграмму классов проекта. Для построения диаграммы в окне Solution Explorer достаточно выбрать имя проекта, нажать правую кнопку мыши и из выпадающего контекстного меню выбрать пункт View Class Diagram. Диаграмма классов проекта, названного Architecture, показана на рис. 4.2.

увеличить изображение
Рис. 4. 2. Диаграмма классов проекта Architecture

На диаграмме отображаются все классы проекта. Помимо описанных классов, на диаграмме показаны два класса, автоматически строящиеся для проектов — Resources и Settings, задающие ресурсы и установки проекта.

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

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

На рис. 4.3 показана такая диаграмма.

Рис. 4.3. Отношения встраивания и наследования для классов проекта Architecture

Среди классов, изображенных на рис. 4.3 , показан и класс object — прародитель всех классов. Фактически от всех классов системы ведет путь наследования к классу object, так что при рисовании полной картины наследования (отображая не только прямых родителей) из каждого класса выходит стрелка наследования, непосредственно или транзитивно ведущая к классу object. Класс object — это единственный класс, в который ведут несколько стрелок, но ни одна из стрелок не выходит. Этот класс не имеет ни родителей, ни клиентов. Особую роль играет и класс Program. Из него могут выходить несколько стрелок, но ни одна стрелка не входит. У этого класса нет потомков, нет клиентов. Никто не может создать объекты этого класса. Единственный объект этого класса создается автоматически в момент запуска программной системы на исполнение, и создается он вне программной системы высшими силами.

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

База данных

— может ли отношение иметь отношение с другим отношением

спросил 9 лет, 1 месяц назад

Изменено 9 лет, 1 месяц назад

Просмотрено 340 раз

мы можем что-то вроде следования ER?

Это техническая неисправность или нет?

• база данных
• дизайн базы данных
• сущность-связь
• связь

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

В вашем случае, если вы хотите использовать 2 отношения, между ними должен быть 1 объект.

Пример из реальной жизни

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

Но вы можете сказать, что я учитель Xyz и студент азбуки.

Тип связи

Связь «один ко многим»

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

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

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

В большинстве случаев нет необходимости в отношении «один к одному», так как содержимое двух таблиц может быть объединено в одну таблицу.

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

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

Зарегистрируйтесь или войдите в систему

Зарегистрируйтесь с помощью Google

Зарегистрироваться через Facebook

Зарегистрируйтесь, используя электронную почту и пароль

Опубликовать как гость

Электронная почта

Требуется, но никогда не отображается

Опубликовать как гость

Электронная почта

Требуется, но не отображается

Связи моделей в Power BI Desktop — Power BI

• Статья
• 16. 11.2022
• 18 минут на чтение

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

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

Цель связи

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

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

Важно

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

Вот как отношения распространяют фильтры на анимированном примере.

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

Запрос, возможно сгенерированный визуальным элементом карты Power BI, запрашивает общий объем продаж для заказов на продажу, сделанных для одной категории, Cat-A , и за один год, CY2018 . Вот почему вы можете увидеть фильтры, примененные к таблицам категории и года . Фильтр таблицы Категория распространяется на таблицу Продукт , чтобы изолировать два продукта, которым присвоена категория Cat-A . Затем Продукт 9Фильтры таблицы 0028 распространяются на таблицу Sales , чтобы изолировать только две строки продаж для этих продуктов. Эти две строки продаж представляют продажи продуктов, отнесенных к категории Cat-A . Их общее количество составляет 14 единиц. В то же время фильтр таблицы Year распространяется на дальнейшую фильтрацию таблицы Sales , в результате чего получается только одна строка продаж, относящаяся к категории Cat-A и заказанная в году CY2018 9.0028 . Значение количества, возвращаемое запросом, равно 11 единицам. Обратите внимание, что когда к таблице применяется несколько фильтров (например, таблица Sales в этом примере), это всегда операция И, требующая, чтобы все условия были истинными.

Применение принципов проектирования по схеме «звезда»

Мы рекомендуем применять принципы проектирования по схеме «звезда» для создания модели, включающей таблицы измерений и таблицы фактов. Обычно Power BI настраивают для применения правил фильтрации таблиц измерений, позволяя отношениям модели эффективно распространять эти фильтры на таблицы фактов.

На следующем изображении показана схема модели данных анализа продаж Adventure Works. На нем показана схема «звезда», содержащая одну таблицу фактов с именем Sales . Остальные четыре таблицы представляют собой таблицы измерений, поддерживающие анализ показателей продаж по дате, штату, региону и продукту. Обратите внимание на отношения модели, соединяющие все таблицы. Эти отношения распространяют фильтры (напрямую или косвенно) на таблицу Sales .

Разъединенные столы

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

Параметр «что, если» Power BI Desktop — это функция, которая создает отключенную таблицу. Дополнительные сведения см. в статье Создание и использование параметра «что если» для визуализации переменных в Power BI Desktop.

Свойства отношения

Связь модели связывает один столбец в таблице с одним столбцом в другой таблице. (Есть один особый случай, когда это требование не соответствует действительности, и оно применяется только к отношениям с несколькими столбцами в моделях DirectQuery. Дополнительные сведения см. в статье о функции COMBINEVALUES DAX.)

Примечание

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

Мощность

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

Примечание

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

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

• Один ко многим (1:*)
• Многие к одному (*:1)
• Один к одному (1:1)
• Многие ко многим (*:*)

При создании связи в Power BI Desktop конструктор автоматически определяет и устанавливает тип кардинальности. Power BI Desktop запрашивает модель, чтобы узнать, какие столбцы содержат уникальные значения. Для моделей импорта используется статистика внутренней памяти; для моделей DirectQuery он отправляет профилирующие запросы к источнику данных. Однако иногда Power BI Desktop может ошибаться. Это может быть ошибкой, когда таблицы еще не загружены данными или потому что столбцы, которые, как вы ожидаете, будут содержать повторяющиеся значения, в настоящее время содержат уникальные значения. В любом случае вы можете обновить тип кардинальности, если какие-либо «один» боковые столбцы содержат уникальные значения (или таблица еще не загружена строками данных).

Мощность «один ко многим» (и «многие к одному»)

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

При настройке связи «один ко многим» или «многие к одному» вы выберете ту, которая соответствует порядку, в котором вы связали столбцы. Подумайте, как бы вы настроили связь между таблицей Product и таблицей Sales с помощью Столбец ProductID найден в каждой таблице. Тип кардинальности будет один-ко-многим , поскольку столбец ProductID в таблице Product содержит уникальные значения. Если вы свяжете таблицы в обратном направлении, Продажи к Продукт , тогда количество элементов будет многие-к-одному .

Количество элементов «один к одному»

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

Дополнительные сведения об использовании этого типа кардинальности см. в руководстве по отношениям «один к одному».

Количество элементов «многие ко многим»

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

Инструкции по использованию этого типа кардинальности см. в разделе Руководство по связям «многие ко многим».

Примечание

Тип кардинальности «многие ко многим» в настоящее время не поддерживается для моделей, разработанных для сервера отчетов Power BI.

Совет

В представлении модели Power BI Desktop тип кардинальности связи можно интерпретировать, глядя на индикаторы (1 или *) по обе стороны от линии связи. Чтобы определить, какие столбцы связаны, вам нужно выбрать или навести курсор на линию связи, чтобы выделить столбцы.

Направление кросс-фильтра

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

Тип мощности	Опции кросс-фильтра
Один ко многим (или Многие к одному)	Одинарный Оба
Один к одному	Оба
Многие ко многим	Одиночный (от Таблицы 1 до Таблицы 2) Одиночный (от Таблицы 2 до Таблицы 1) Оба

Single cross filter direction означает «одно направление», а Both означает «оба направления». Связь, которая фильтрует в обоих направлениях, обычно описывается как двунаправленная .

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

Если для направления перекрестного фильтра задано значение Оба , становится доступным другое свойство. Он может применять двунаправленную фильтрацию, когда Power BI применяет правила безопасности на уровне строк (RLS). Дополнительные сведения о RLS см. в разделе Безопасность на уровне строк (RLS) с Power BI Desktop.

Можно изменить направление взаимосвязи между фильтрами, включая отключение распространения фильтра, с помощью расчета модели. Это достигается с помощью функции CROSSFILTER DAX.

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

Мы рекомендуем использовать двунаправленную фильтрацию только при необходимости. Дополнительные сведения см. в разделе Руководство по двунаправленным отношениям.

Совет

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

Сделать это отношение активным

Между двумя таблицами моделей может быть только один активный путь распространения фильтра. Однако можно ввести дополнительные пути отношений, хотя вы должны установить эти отношения как неактивные . Неактивные отношения можно сделать активными только во время оценки расчета модели. Это достигается с помощью функции USERELATIONSHIP DAX.

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

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

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

Дополнительные сведения см. в разделе Руководство по активным и неактивным связям.

Совет

В представлении модели Power BI Desktop вы можете интерпретировать активное и неактивное состояние связи. Активные отношения представлены сплошной линией; неактивная связь представлена ​​пунктирной линией.

Предполагать ссылочную целостность

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

Если этот параметр включен, собственные запросы, отправляемые к источнику данных, будут соединять две таблицы вместе с помощью INNER JOIN , а не OUTER JOIN . Как правило, включение этого свойства повышает производительность запросов, хотя это зависит от специфики источника данных.

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

Важно

Если целостность данных будет нарушена, внутреннее соединение удалит несовпадающие строки между таблицами. Например, рассмотрим таблицу модели Sales со значением столбца ProductID , которого не было в связанной таблице Product . Распространение фильтра из таблицы Product в таблицу Sales удалит строки продаж для неизвестных продуктов. Это приведет к занижению результатов продаж.

Дополнительные сведения см. в разделе Предполагаемые параметры ссылочной целостности в Power BI Desktop.

Соответствующие функции DAX

Существует несколько функций DAX, относящихся к отношениям модели. Каждая функция кратко описана в следующем маркированном списке:

• СВЯЗАННЫЕ: извлекает значение из «одной» стороны отношения. Это полезно при использовании вычислений из разных таблиц, которые оцениваются в контексте строки.
• RELATEDTABLE: получить таблицу строк со стороны отношения «многие».
• USERELATIONSHIP: позволяет вычислению использовать неактивное отношение. (Технически эта функция изменяет вес определенного неактивного отношения модели, помогая влиять на его использование.) Это полезно, когда ваша модель включает таблицу ролевых измерений, и вы решили создать неактивные отношения из этой таблицы. Вы также можете использовать эту функцию для устранения неоднозначности в путях фильтрации.
• CROSSFILTER: изменяет направление перекрестного фильтра отношений (на одно или на оба) или отключает распространение фильтра (нет). Это полезно, когда вам нужно изменить или проигнорировать отношения модели во время оценки конкретного расчета.
• COMBINEVALUES: объединяет две или более текстовых строк в одну текстовую строку. Эта функция предназначена для поддержки многостолбцовых отношений в моделях DirectQuery, когда таблицы принадлежат одной исходной группе.
• TREATAS: Применяет результат табличного выражения в качестве фильтров к столбцам из несвязанной таблицы. Это полезно в сложных сценариях, когда вы хотите создать виртуальную связь во время оценки определенного вычисления.
• Родительские и дочерние функции: семейство связанных функций, которые можно использовать для создания вычисляемых столбцов для натурализации иерархии родитель-потомок. Затем вы можете использовать эти столбцы для создания иерархии фиксированного уровня.

Оценка отношений

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

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

Модель импорта или DirectQuery получает все данные либо из кэша Vertipaq, либо из исходной базы данных. В обоих случаях Power BI может определить, что существует «одна» сторона отношения.

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

Вот пример составной модели.

В этом примере составная модель состоит из двух групп источников: группы источников Vertipaq и группы источников DirectQuery. Исходная группа Vertipaq содержит три таблицы, а исходная группа DirectQuery — две таблицы. Существует одна связь между группами источников, чтобы связать таблицу в группе источников Vertipaq с таблицей в группе источников DirectQuery.

Обычные отношения

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

В следующем примере есть два обычных отношения, оба отмечены как R . Отношения включают отношение «один ко многим», содержащееся в исходной группе Vertipaq, и отношение «один ко многим», содержащееся в источнике DirectQuery.

Для моделей импорта, в которых все данные хранятся в кэше Vertipaq, Power BI создает структуру данных для каждой регулярной связи во время обновления данных. Структуры данных состоят из индексированных сопоставлений всех значений столбцов, и их цель — ускорить объединение таблиц во время запроса.

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

Примечание

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

Для отношений «один ко многим» расширение таблицы происходит от сторон «многие» к сторонам «один» с помощью ЛЕВОЕ ВНЕШНЕЕ СОЕДИНЕНИЕ семантика. Когда совпадающее значение из «многих» в «один» не существует, пустая виртуальная строка добавляется в боковую таблицу «один». Это поведение применимо только к обычным отношениям, а не к ограниченным отношениям.

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

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

Вот как работает расширение таблицы на анимированном примере.

В этом примере модель состоит из трех таблиц: Категория , Продукт и Продажи . Категория 9Таблица 0028 относится к таблице Product с отношением «один ко многим», а таблица Product относится к таблице Sales с отношением «один ко многим». Таблица Category содержит две строки, таблица Product содержит три строки, а таблица Sales содержит пять строк. С обеих сторон всех отношений есть совпадающие значения, что означает отсутствие нарушений ссылочной целостности. Откроется таблица, расширенная во время запроса. Таблица состоит из столбцов из всех трех таблиц. Фактически это денормализованная перспектива данных, содержащихся в трех таблицах. Новая строка добавляется к Sales , и у него есть значение идентификатора производства (9), которое не имеет соответствующего значения в таблице Product . Это нарушение ссылочной целостности. В расширенной таблице новая строка содержит значения (пусто) для столбцов таблицы «Категория » и « Продукт ».

Ограниченные отношения

Модель отношений ограничена , когда нет гарантированной «одной» стороны. Ограниченная связь может возникнуть по двум причинам:

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

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

Для моделей импорта структуры данных никогда не создаются для ограниченных отношений. В этом случае Power BI разрешает соединения таблиц во время запроса.

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

Существуют и другие ограничения, связанные с ограниченными отношениями:

• Функцию RELATED DAX нельзя использовать для извлечения значений столбца «one» стороны.
• Применение RLS имеет ограничения по топологии.

Совет

В представлении модели Power BI Desktop связь можно интерпретировать как ограниченную. Ограниченная связь представлена ​​метками в виде скобок ( ) после показателей кардинальности.

Устранение неоднозначности пути связи

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

Приоритет

Уровни приоритета определяют последовательность правил, которые Power BI использует для устранения неоднозначности путей отношений. Первое совпадение с правилом определяет путь, по которому будет следовать Power BI. Каждое правило ниже описывает, как фильтры перемещаются из исходной таблицы в целевую.

1. Путь, состоящий из отношений «один ко многим».
2. Путь, состоящий из отношений «один ко многим» или «многие ко многим».
3. Путь, состоящий из отношений «многие к одному».
4. Путь, состоящий из связей «один ко многим» из исходной таблицы в промежуточную таблицу, за которыми следуют связи «многие ко многим» из промежуточной таблицы в целевую таблицу.
5. Путь, состоящий из отношений «один ко многим» или «многие ко многим» от исходной таблицы к промежуточной таблице, за которыми следуют отношения «многие к одному» или «многие ко многим» из промежуточной таблицы к целевой таблице.
6. Любой другой путь.

Когда связь включена во все доступные пути, она исключается из рассмотрения во всех путях.

Вес

Каждое отношение в пути имеет вес. По умолчанию все веса отношений равны, если только не используется функция USERELATIONSHIP. вес пути — это максимальный вес всех отношений на пути. Power BI использует веса путей для устранения неоднозначности между несколькими путями на одном уровне приоритета. Он не выберет путь с более низким приоритетом, но выберет путь с более высоким весом. Количество отношений в пути не влияет на вес.

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

Рассмотрим следующий пример. Мера Product Sales присваивает больший вес связи между Sales[ProductID] и Product[ProductID] , за которой следует связь между Inventory[ProductID] и Product[ProductID] .

 Продажи продукта =
ВЫЧИСЛИТЬ(
    ВЫЧИСЛИТЬ(
        СУММ(Продажи[ОбъемПродаж]),
        ОТНОШЕНИЕ ПОЛЬЗОВАТЕЛЯ(Продажи[ProductID], Продукт[ProductID])
    ),
    ОТНОШЕНИЕ ПОЛЬЗОВАТЕЛЯ(Inventory[ProductID], Product[ProductID])
)
 

Примечание

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