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

Необходимое условие

Загрузите набор данных Pubs.xlsx для примеров этой статьи здесь.

Прочтите первую часть серии о связях Power BI: Назад к основам: раскрытие отношений Power BI.

Отношения в Power BI

Отношения Power BI дают нам возможность получать поля из нескольких таблиц и возможность фильтрации по нескольким таблицам в модели данных. Отношения основаны на поле, которое соединит две таблицы и отфильтрует одну на основе другой (или наоборот, зависит от направления). Например, мы можем отфильтровать данные по количеству таблицы Sales по состоянию в таблице Store, если между таблицами Sales и Store существует связь на основе stor_id:

И отношения между таблицами будут следующими:

Что такое мощность отношений?

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

Два значения 1 или * говорят о том, что поле в этой взаимосвязи имеет определенное число значения на строку в этой таблице. Давайте проверим это на примере.

В таблице Stores у нас есть одно уникальное значение для stor_id на строку.

Таким образом, если это поле участвует в одной стороне отношения, то эта сторона примет 1 в качестве показателя кардинальности, который называется ОДНОЙ стороной отношения.

Однако stor_id в таблице Sales не уникален для каждой строки данных в этой таблице. У нас есть несколько строк для каждого stor_id. Или скажем так; в каждом магазине происходит несколько торговых транзакций (что, конечно, нормально):

Таким образом, если stor_id в таблице Sales является частью отношения, эта сторона отношения станет *, или то, что мы называем «МНОЖЕСТВЕННОЙ» стороной отношения.

Итак, основываясь на том, что мы знаем в данный момент, если мы создадим отношение на основе stor_id между двумя таблицами Sales и Stores, то получим вывод:

Эти отношения могут быть прочитаны двумя способами;

• Отношение “один-ко-многим” (1- *) из таблицы магазинов в таблицу продаж
• Отношение «многие-к-одному» (* -1) из таблицы продаж в таблицу магазинов

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

Типы мощности

Есть четыре типа кардинальности, как показано ниже:

• 1-1: “один-к одному”
• 1- *: “один-ко-многим”
• * -1: “многие-к-одному”
• * - *: “многие-ко-многим”

Давайте поочередно рассмотрим каждый из этих типов.

Один-ко-многим или многие-к-одному

Это наиболее распространенный тип мощности, используемый в моделях данных. Этот тип количества элементов означает, что одна из таблиц имеет уникальные значения в каждой строке для поля отношения, а другая имеет несколько значений. Пример, который вы видели ранее между таблицами 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. Подробнее - в ссылке выше.

Отношения “один-к-одному”

Отношение “один-к-одному” происходит только в одном сценарии, когда у вас есть уникальные значения в обеих таблицах на столбец. Примером такого сценария является случай, когда у вас есть таблицы Titles и Titles Details! У них обоих есть один ряд на заголовок. Так что, если мы создадим отношения, это будет выглядеть так:

Если между двумя таблицами существует взаимно-однозначное отношение, они являются хорошим кандидатом для объединения друг с другом с помощью слияния в Power Query. Поскольку обе таблицы в большинстве случаев имеют одинаковое количество строк, или даже если в одной из них меньше строк, все еще учитывающих метод сжатия механизма Power BI xVelocity, потребление памяти будет одинаковым, если вы поместите его в одну таблицу. Так что если у вас отношения “один-к-одному”, подумайте о том, чтобы серьезно объединить эти таблицы.

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

Отношения “многие ко многим”: слабые отношения

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

Что делать, если у вас есть более одной таблицы с этим сценарием?

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

Отношения «многие ко многим» вызывают массу проблем, и поэтому они также называются слабыми связями. В большинстве случаев ее можно решить путем создания общего измерения и создания отношений «один ко многим» из общего измерения с таблицами фактов. ИЗБЕГАЙТЕ такого типа отношений в вашей модели.

Лучшая модель для вышеупомянутого образца будет использовать общие размеры, как показано на этой диаграмме:

Резюме

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

No Comments