Что происходит под капотом, когда между таблицами устанавливается связь? - PullRequest
0 голосов
/ 17 октября 2018

Этот вопрос не ограничивается Power BI, но он поможет мне объяснить мою проблему.

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

enter image description here

И вы можете редактировать это отношение, щелкнув по появившейся строке:

enter image description here

И, между прочим, вот структуры двух таблиц:

# Table1
A,B
1,abc
2,def
3,ghi
4,jkl

# Table2
A,C
1,abc
1,def
2,ghi
3,ghit

Это прекрасно работает, так как столбец A в Table1 состоит из уникальных значений и может работатьв качестве первичного ключа.И теперь вы можете перейти к Report tab, настроить две таблицы и нарезать кубиками по своему желанию, щелкнув непосредственно под буквой А в Таблице 1, или введя слайсер:

enter image description here

Но дело в том, что вы можете сделать это без , установив связь между таблицами.Удалите отношений в разделе Relationships и вернитесь к Report и выберите Home > Manage Relationships, чтобы понять, что я имею в виду:

enter image description here

как диалоговое окноговорит 'There are no relationships defined yet.' Но вы можете все же поднастроить одну таблицу, сделав выборки в другой, как и раньше ( РЕДАКТИРОВАТЬ: Это утверждение было ошибочно в ответе от RADO).Я делаю знаю, что вы можете выделить слайсер и выбрать Format > Edit Interactions и отменить выбор таблиц, связанных с слайсером.Но я все еще озадачен всем этим.

Так что же здесь происходит под капотом, о котором я не знаю?Или же связь между таблицами на самом деле определяется самим содержимым таблиц - в том смысле, что существование связанных значений по таблицам с наличием потенциального первичного ключа (будь то натуральный или синтетический) делает егоможно запрашивать их, используя SQL, глаголы dplyr или любую другую форму запросов.И что вам действительно не нужно явно определенное отношение?

Или, другими словами, имеет ли установление отношения таблицы Power BI SQL-эквивалент?Возможно, как следующее :

CREATE TABLE Persons (
    ID int NOT NULL,
    LastName varchar(255) NOT NULL,
    FirstName varchar(255),
    Age int,
    PRIMARY KEY (ID)
);

Извините, если я немного болтаю здесь, но я просто очень в замешательстве.И поиск в Google пока только добавил путаницы.Так что спасибо за любые идеи!

Ответы [ 3 ]

0 голосов
/ 05 мая 2019

В таблицах RM (реляционная модель) и ERM (модель сущности-отношения) представлены отношения (связь).Следовательно, реляционные в "RM" и отношения в "ERM".

FK (внешние ключи) ошибочно называют "отношениями" в псевдо-ERM-методах.Ограничение SQL FK говорит, что подстроки появляются в других местах как PK (первичный ключ) или UNIQUE.СУБД использует их для запрета недействительных обновлений и оптимизации запросов.

«Связи» Power BI не являются FK.Это инструкции о том, как создавать запросы.

Когда есть ФК, мы часто хотим присоединиться к нему.Поэтому нам часто нужны отношения Power BI при наличии FK.

Создание и управление отношениями в Power BI Desktop
(см. Также ссылку Скачать PDF для разработчика.)

PS Нам не нужны ограничения для хранения, объявления или запроса.Ограничения (включая PK, FK, UNIQUE и кардинальности) определяются значениями таблицы - (характеристика) предикаты - и какие бизнес-ситуации могут возникнуть.Если ограничения выполняются, то иногда мы получаем меньше строк, чем в противном случае, и некоторые пары запросов всегда возвращают одинаковые результаты, в противном случае они не будут.

Внешние ключи не нужны для объединения таблиц!
Есть ли эмпирическое правило для построения запроса SQL из понятного человеку описания?

PS Перекрестное соединение - это внутреннее соединение с условием ИСТИНА (или нет).состояние в некоторых СУБД), период.Существуют ли "отношения", или ФК, не имеет значения.Если условие FK = PK или что-либо еще, кроме TRUE, то это не перекрестное соединение;в противном случае это перекрестное соединение, независимо от того, существует ли FK между таблицами.Просто мы часто хотим, чтобы PK = FK в условии, и инструменты могут и действительно использовать присутствие FK для условия по умолчанию.

CROSS JOIN против INNER JOIN в SQL Server 2008

0 голосов
/ 06 мая 2019

Вы спросили "Что происходит под капотом?"Простой ответ: « Заявления об отношениях».

Многие благонамеренные люди рисуют диаграммы ER и, похоже, либо забывают, либо не подозревают о том факте, что их диаграммы ER на самом деле являются «картинками высказываний на языке».

Проблема заключается в двусмысленности.

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

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

Итак, что под одеялом - это язык!

Простая диаграмма ER Diagram 1

Утверждения, из которых составлена ​​диаграмма.The statements

Более сложная диаграмма

Student lives at Address

Утверждения, из которых получена диаграмма.

enter image description here

0 голосов
/ 17 октября 2018

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

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

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

Как работает вся система (упрощенно): PowerBI содержит язык под названием «DAX».Вы создадите меры в DAX, а PowerBI затем переведет их на свой внутренний язык, называемый xmSQL, который является особой разновидностью SQL.В xmSQL обычное соединение преобразуется в LEFT OUTER JOIN, например:

SELECT SUM(Sales.Amount)
FROM Sales
LEFT OUTER JOIN Customer
ON Sales.Customer_Key = Customer.Customer_Key

Отношения по направлению немного сложнее, но концептуально похожи.

В целом, когда вы создаете отношения между таблицами, вы сообщаете механизму PowerBI, как объединять таблицы.Затем движок также добавляет некоторые оптимизации для ускорения запросов.Каждый раз, когда вы выполняете меру DAX, щелкаете по слайсеру или визуалу, PowerBI генерирует несколько операторов xmSQL в фоновом режиме, выполняет их, а затем отображает их результаты в виде визуалов.Вы можете увидеть эти запросы SQL с помощью некоторых инструментов, таких как DAX Studio.

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

...