Руководство по отношениям "один к одному"

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

Примечание.

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

Важно также понимать схему звездочки. Дополнительные сведения см. в статье "Общие сведения о схеме звезды" и важности для Power BI.

Существует два сценария, которые связаны с отношениями "один к одному":

• вырождение измерений. Вы можете получить вырожденное измерение из таблицы фактов .

• Данные строк охватывают несколько таблиц: одна бизнес-сущность или субъект загружается как две (или более) таблицы моделей, возможно, потому что их данные поступают из разных хранилищ данных. Этот сценарий может быть распространён для таблиц измерений . Например, основные сведения о продукте хранятся в операционной системе продаж, а дополнительные сведения о продукте хранятся в другом источнике.

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

Вырожденные аналитики

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

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

Рассмотрим исходную таблицу с именем Sales, в которой хранятся сведения о строках заказов на продажу в двух столбцах.

Столбец OrderNumber хранит номер заказа, а столбец OrderLineNumber хранит последовательность строк в заказе.

На следующем рисунке обратите внимание, что столбцы номера заказа и номера строки заказа не были загружены в таблицу Sales. Их значения использовались для создания столбца с суррогатным ключом, именуемого OrderLineNumberID. (Значение ключа вычисляется путем умножения номера заказа на 1000, а затем добавления номера строки заказа.)

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

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

Диапазоны данных строк между таблицами

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

Ниже приведена частичная схема модели двух таблиц.

Первая таблица называется Product, и она содержит три столбца: Color, Productи SKU. Вторая таблица называется Product Category, и она содержит два столбца: Category и SKU. Связь "один к одному" соединяет два столбца SKU. Фильтры связей в обоих направлениях, которые всегда являются вариантом для связей "один к одному".

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

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

• В таблице Product есть три строки:
  • SKU CL-01, Productфутболка, Colorзеленый
  • SKU CL-02, ProductДжинсы, ColorСиний
  • SKU AC-01, ProductШляпа, ColorСиний
• В таблице Product Category есть две строки:
  • SKU CL-01, Categoryодежды
  • SKU AC-01, CategoryАксессуары

Обратите внимание, что таблица Product Category не содержит строку для номера SKU продукта CL-02. Далее в этой статье мы обсудим последствия этой недостающей строки.

В области данных авторы отчетов находят связанные с продуктом поля в двух таблицах: Product и Product Category. Давайте посмотрим, что происходит, когда поля из обеих таблиц добавляются в визуальный элемент таблицы. В этом примере столбец SKU создается из таблицы Product.

Обратите внимание, что значение Category номера SKU продукта CL-02 равно BLANK. Это связано с отсутствием соответствующей строки в таблице Product Category для этого продукта.

Рекомендации

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

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

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

Связь внутри исходной группы "один к одному"

Если между таблицами существует связь одно к одному внутри исходной группы , рекомендуется объединить данные в одну таблицу моделей. Это можно сделать, объединив запросы Power Query.

В следующих шагах представлена методология консолидации и моделирования данных с отношением один к одному.

1. Запросы слияния. При объединении двух запросов учитывайте полноту данных в каждом запросе. Если один запрос содержит полный набор строк (например, главный список), объедините другой запрос с ним. Задайте преобразование слияния для использования левого внешнего соединения, который является типом соединения по умолчанию. Этот тип соединения гарантирует, что все строки первого запроса будут храниться и дополнять их любыми соответствующими строками второго запроса. Разверните все необходимые столбцы второго запроса в первый запрос.

   

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

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

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

   На следующем рисунке обратите внимание, что категория продукта SKU CL-02 теперь отображается как [Undefined]. В запросе категории NULL были заменены этим текстовым значением маркера.

   

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

   В нашем примере авторы отчетов теперь могут использовать иерархию с двумя уровнями: Category и Product.

   

Если вы хотите, как отдельные таблицы помогают упорядочивать поля, мы по-прежнему рекомендуем объединить их в одну таблицу. Вы по-прежнему можете упорядочивать поля, но с помощью отображаемых папок .

В нашем примере авторы отчетов могут найти поле Category в папке отображения Marketing.

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

Перекрестная связь между исходной группой "один к одному"

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

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

Первый визуальный элемент таблицы, использующий связь между исходными группами, отображает только две строки. Номер SKU продукта CL-02 отсутствует, так как в таблице Product Category отсутствует соответствующая строка. Визуальный элемент второй таблицы, основанный на единой консолидированной таблице в модели, отображает три строки.

Связанный контент

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

• Связи модели в Power BI Desktop
• Общие сведения о схеме звезд и важности Power BI
• Руководство по устранению неполадок связи
• Вопросы? Попробуйте спросить сообщество Fabric
• Есть предложения? Вносите идеи для улучшения Fabric