Страницы: 1
RSS
Вопросы по материалу первой книги по Microsoft Power BI на русском
 
Доброго времени суток!
При освоении материала из этой Книги порой у меня возникают вопросы по материалу, непонимание.
Например сегодня 3 часа ломал голову над объяснением добавления гранулярности для таблицы медленных измерений, но так и не понял.
Уважаемые модераторы, можно ли здесь оставить эту тему для обсуждения материалов из книги?
Возможно вопросы и непонимание возникают не только у меня, и совместными усилиями будет легче грызть гранит DAX?!
Изменено: Lari - 18.06.2020 04:13:39
 
Не у всех же книжка под рукой. Лучше по старинке, выдержку из книги, потом файлик с примером, что хочется, что не получается/не понятно.
Вот горшок пустой, он предмет простой...
 
Цитата
PooHkrd написал:
Лучше по старинке, выдержку из книги, потом файлик с примером, что хочется, что не получается/не понятно.
Привет, Алексей.
Это же делать надо :)  Может ТС хочет, чтобы отвечали только те, кто прочитал книгу, а всякие левые пусть идут мимо :)
Изменено: Андрей VG - 18.06.2020 09:21:48
 
Доброго времени суток!
Андрей VG, PooHkrd, спасибо что откликнулись, я восхищаюсь вашими знаниями которые вы демонстрируете на форуме и надеюсь смогу когда-нибудь приблизиться к ним.
1. Прежде всего я хотел узнать можно ли обсуждать эту книгу, поэтому я обратился к модераторам с таким вопросом.
2. Какого размера выдержку из книги можно тут опубликовать чтобы не нарушить правил?
у меня вопрос по главе «Исправление гранулярности в измерении» которая занимает 2 страницы.
3.для меня вся глава бессмысленна, т.к в ней изначальная таблица группируется, потом выводится максимум по коду, но все это не имеет смысла, т.к.количество строк остается прежним и гранулярность никак не меняется.(рисунки 5.18, 5.19, 5.20)
 
Здравствуйте. Я переводчик этой книги и отвечу на вопрос.
На рисунках 5.18-5.20 неудачно выбран показанный фрагмент таблицы, поскольку он захватывает только Австралию, по которой менеджер менялся каждый год: 2007: Пол, 2008: Марк, 2009: Луиза. Для этого случая значения в столбцах CustomerKey с рис. 5.18 и NewCustomerKey с рис. 5.20 будут одинаковыми.
Но если взять Канаду, то там менеджер в 2007 году была Луиза, а в 2008 и 2009 – Рауль. В этом случае в таблице, показанной на рис. 5.18, для каждого покупателя будет 3 строки: две из них с повторяющимся менеджером Раулем, что нам не нужно. И при переходе к рис. 5.19 мы избавляемся от этих дублей, оставляя только максимальный год для Рауля. Таким образом, из трех строк станет две. Посмотрите на рис. 5.21 вверху: там по покупателю с кодом 143 осталось две строки с CustomerKey 1432007 и 1432009. Заметили, что 1432008 нет? Она как раз и убралась на шаге от рис. 5.18 к рис. 5.19, и теперь поле CustomerKey может быть полноценным первичным ключом, что нам и нужно было.
Ключевая фраза здесь:
Скрытый текст
Надеюсь, ответил на Ваш вопрос. Если что, спрашивайте.
Изменено: Александр Гинько - 18.06.2020 13:55:51
 
Добавлю картинки, если кому-то еще будет интересно:

Картинки удалены - превышен допустимый размер вложения [МОДЕРАТОР]
 
Цитата
Андрей VG написал:
всякие левые пусть идут мимо
Присоединился к правым. :)  
Владимир
 
Цитата
Lari написал:
для меня вся глава бессмысленна, т.к в ней изначальная таблица группируется, потом выводится максимум по коду, но все это не имеет смысла, т.к.количество строк остается прежним и гранулярность никак не меняется.(рисунки 5.18, 5.19, 5.20)
смотрел по английской версии книги.
Судя по всему, авторы (может, и переводчики - не могу судить, ибо читал только английский вариант) зажевали немного объяснение...
У нас изначально была табличка CountryManagers (рисунок 5-12), которая содержала CountryRegion, Manager, FromYear, ToYear. Из нее создали таблицу "Historical Country Managers", которая содержит все сочетания "регион - менеджер - год" (рисунок 5-14). Она содержит избыточную гранулярность:
Цитата
This table now contains the worst-case granularity for the country or region, with one version for each year. Many rows will show the same value for the same country, differing only in the year. However, this table is still useful, because you will use it as a lookup when changing the granularity of the fact table. Because the table contains the historical country or region sales manager, save it under the name Historical Country Managers.
Мы ее сохраняем в таком виде, а затем на ее основе создаем вторую таблицу "Actual Country Managers", которая содержит только действующих менеджеров по региону (рисунок 5-16). Но это уже другая таблица, и теперь у нас их две.


Далее мы джойним обе эти таблицы к таблице Customers из базы по полю CountryRegion.
Первой джойним Actual Country Managers, разворачивая столбец Actual Manager. И она действительно не создает новые строки, так как на один регион в ней приходится одна строка.
Второй джойним Historical Country Managers. Она уже дает нам на каждый регион по 3 строки (потому что даже если менеджер был один, у нас в ней по 1 строке на регион-год). После разворота у нас как раз увеличивается количество строк в таблице Customers.
Вот этот момент немного зажеван и, похоже, объяснен с ошибкой в оригинале:
Цитата
If you join the Customer table with the Historical Country Managers table based on the CountryRegion, the result will contain more rows, one for each different manager for a given customer. It will not contain a new version of the customer for each year, which would be the worst-case granularity. Instead, because of the grouping operation that is performed on the Historical Country Managers table, it will contain the right number of versions for each customer.
Выделенный красным кусок должен отсылать нас к начальной таблице "CountryManagers" а не "Historical Country Managers".
А вот синий курсив тяжел для понимания даже на английском :) мы, на самом деле, не создавали группировку в таблице "Historical Country Managers", мы создавали ее для таблицы Actual Country Managers. А в таблице Historical Country Managers мы делали обратную операцию размножения строк по годам.
В официальном списке ошибок и опечаток этот момент отсутствует, увы.

Дальше мы создаем новый ключ = Original Customer Key * 10000 + Year, чтобы уже получить уникальный ключ для каждой строки. Сохраняем эту таблицу как CustomerBase (запоминаем, что она содержит в себе избыточную гранулярность "клиент - менеджер - год", даже если менеджер не менялся)

А вот потом мы на ее базе создаем новую таблицу Customer, в которой сначала понижаем гранулярность за счет группировки и определения максимального года, в который менеджер был закреплен за клиентом (то есть из трех строк Код-2007, Код-2008, Код-2009 мы оставляем одну - Код-2009, (рисунок 5-20) а затем подтаскиваем (опять же из CustomerBase) атрибуты, которые убрали в процессе понижения гранулярности (манагеров и т.п. инфо о клиенте. (рисунок 5-21).

Надеюсь, вам стало понятнее
F1 творит чудеса
 
По ссылке из предыдущего поста можно скачать файлы, в которых все эти операции повторены (по одному файлу на каждый рисунок, если что, поэтому размер архива там более 600 Мб)

Александр Гинько, о, здорово, хотел вас из ТГ высвистеть в эту тему. Как мне кажется, ключ к непониманию всё же раньше, в первом абзаце раздела "Fixing granularity in the dimension" - то, о чем написал выше
F1 творит чудеса
 
Итак, буду отвечать по порядку:
1. Александр Гинько,спасибо за ответ, у меня возник вопрос одинаковые ли у нас примеры, т.к.
Цитата
Но если взять Канаду, то там менеджер в 2007 году была Луиза, а в 2008 и 2009 – Рауль. В этом случае в таблице, показанной на рис. 5.18, для каждого покупателя будет 3 строки: две из них с повторяющимся менеджером Раулем, что нам не нужно.
У меня в примере 5.18 дубля по Раулю в Канаде за 2008 год нет.
2. Немного анализа
2а. В изначальной таблице Customer 5.01 у нас 18 869 строк в Historical Country Managers после группировки на рис 5.15(т.е. остается последний год менеджера) 34 строки
2б. Следующим шагом делается merge Customer и Historical Country Managers по полю Country Region и мы получаем таблицу 5.17 в которой 43 882 строки.
я проверил этот шаг вручную в PowerPivot и получил такой же результат. Все, на этом можно заканчивать, мы получаем конечную таблицу.
3. Остальные шаги в этой главе бессмысленны3а. В таблице 5.18 когда создается новый ключ клиент/год у нас 60 138 строк. Откуда это вообще взялось-не понятно.
3б. В таблице 5.19 у нас опять 43 882 строки
3в. В таблице 5.21 у нас по прежнему 43 882 строки.
Максим Зеленский, Огромное спасибо за подробное разъяснение, стало понятнее и я убедился что неразбериха произошла в материале.
Изменено: Lari - 19.06.2020 10:03:53 (испраивл тип код на цитирование)
 
 Lari, не уверен, что понимаю ваши пояснения тут, не проверял по количеству строк, любопытное наблюдение - проверю. Как по мне, так логика действий в книге вполне себе, но есть пару мест, где надо вчитываться и искать блох
F1 творит чудеса
 
Цитата
Максим Зеленский написал:
Выделенный красным кусок должен отсылать нас к начальной таблице "CountryManagers" а не "Historical Country Managers".
Это зачем? В "CountryManagers" у нас содержатся FromYear и ToYear, еще до перевода в Year. Зачем джойнить с ней кастомеров?
Цитата
Максим Зеленский написал:
А вот синий курсив тяжел для понимания даже на английском  мы, на самом деле, не создавали группировку в таблице "Historical Country Managers", мы создавали ее для таблицы Actual Country Managers.
Здесь они просто забежали вперед и объяснили, чем будут отличаться таблицы на рис. 5.18 и 5.21. Фактически мы выполнили группировку по историческому и актуальному менеджерам (именно это они немного кривовато имели в виду в синем фрагменте), что позволило нам выйти на правильную гранулярность.

Lari, таблицы на рис. 5.18 и 5.21 не идентичны. На рис. 5.18 для клиента указаны ВСЕ годы с менеджерами по этим годам, а на рис. 5.21 строк по клиенту столько, сколько раз у него менялся менеджер, вот и всё. Никакой неразберихи в материале нет. :)
 
Доброго времени суток!
Александр Гинько,  
1. Хотел бы уточнить, что когда я пишу про рис., то имею ввиду файл пример соответствующий этому рисунку.
файлы примеры скачаны по ссылке указанной на странице книги дмкпресс
http://dl.dmkpress.com/978-5-97060-858-6.rar
2.как я уже писал выше
Цитата
2б. Следующим шагом делается merge Customer и Historical Country Managers по полю Country Region и мы получаем таблицу 5.17 в которой 43 882 строки.
я проверил этот шаг вручную в PowerPivot и получил такой же результат. Все, на этом можно заканчивать, мы получаем конечную таблицу.
на этом шаге уже правильная гранулярнось и менеджеры не повторяются для каждого года.
таблица 5.18 в принципе непонятно как получена, она не вытекает из таблицы 5.17
Цитата
рис. 5.21 строк по клиенту столько, сколько раз у него менялся менеджер, вот и всё. Никакой неразберихи в материале нет.
точно такая же гранулярность в таблице 5.17
шаги между таблицами 5.17 и 5.21 бессмысленны, количество строк у них одинаковое, количество уникальных CustomerKey тоже идентичное.
причем я повторил получение таблицы 5.17 из описания книги и все получилось так же как в примере 5.17, т.е. это не может быть ошибочно приведенная таблица. Зачем шаги после 5.17 я вообще не понимаю.
Причем в книге тоже так написано про 5.17, что там не будет дублей, фото во вложении.  
Изменено: Lari - 19.06.2020 09:32:56
 
Я не качал файлы. А сколько и какие строки есть в табл, соответствующей рисунку 5.17, для Patterson, Eduardo?
 
Александр Гинько, скрин во вложении
 
А в табл из рис. 5.18 для него уже 3 строки? с 2008 годом?
 
Мне кажется, они ошиблись с этой табличкой в архиве для рис. 5.17, потому что там уже есть поле CustomerKey, собранное из OriginalCustomerKey и Year. На рис. 5.17 в книге его еще нет и они его создают на следующем шаге.
Но общего смысла изначально заданного вопроса это не меняет. Действия с 5.18 до 5.21 НЕ бесполезны, они нужны для этого Эдуардо сделать две строки из трех, убрав 2008 год. Просто в архиве они запутались, видимо.
Изменено: Александр Гинько - 19.06.2020 12:18:58
 
Цитата
Lari написал:
мы получаем таблицу 5.17 в которой 43 882 строки.
Вот, смотри, 43 882 это должно быть уже ПОСЛЕ того как для Эдуардо станет две строки вместо трех
Цитата
Lari написал:
В таблице 5.18 когда создается новый ключ клиент/год у нас 60 138 строк. Откуда это вообще взялось-не понятно.
Как раз понятно – здесь для Эдуардо 3 строки, а не 2. А дальше мы сокращаем таблицу и получаем нужные нам 43 882 строки.
Просто в табл, соответствующей рисунку 5.17, должно было быть 60 138 строк – они не тот файл для 5.17 вложили.
 
Александр Гинько, снимок 5.18 прилагаю, там тоже 2 строки для Эдуардо.
Цитата
Александр Гинько написал:
Вот, смотри, 43 882 это должно быть уже ПОСЛЕ того как для Эдуардо станет две строки вместо трех
у Эдуардо никогда и не было 3-х строк. когда мы делаем merge таблиц Customer( 5.01 состоящий из 18 869 строк) и таблицы  Historical Country Managers(для которой на шаге 5.15 мы оставляем последний год для менеджера и получаем 34 строки ) мы получаем таблицу 5.17, в которой у Эдуардо 2 строки.
Различие между 5.17 и 5.18 должно быть не в количестве строк, а в наличие столбца , где объединены код клиента и год.
Цитата
Александр Гинько написал:
должно было быть 60 138 строк – они не тот файл для 5.17 вложили
5.17 не может быть ошибкой, потому что я повторил шаги его получения и все совпало.
Даже если таблицу Customer объединять с не сгруппированной таблицей Historical Country Managers(87 строк),  то все равно получается 56 607 строк. (вот тут и будет 3 строки для Эдуардо), а не 60 138 как в табл 5.18, т.е. таблица 5.18 левая.
Вообще как я понял объединение Customer с не сгруппированной таблицей Historical Country Managers(87 строк) нужно на следующем шаге, для добавления новой гранулярности в таблицу Sales. Так что думаю авторы немного запутались в этих двух главах.
 
Александр Гинько,
все-таки не соглашусь.
Написал вопрос итальянцам по поводу выделенного ниже, пусть рассудят. Я считаю, что желтое - неправильно, красное - неправильно, синее - запутывает. И самое главное, запутывает следующий абзац, в котором говорится вот это: "После выполнения этих двух действий (каких?) вы получите датасет на рисунке 5-17"
 
F1 творит чудеса
 
Вопрос по паттернам итальянцев
в самой статье приведен такой код
Код
1 [Absolute Recovered Customers] :=
2 COUNTROWS (
3     FILTER (
4         ADDCOLUMNS (
5             FILTER (
6                 FILTER (
7                     ADDCOLUMNS (
8                         VALUES ( <customer_key_column> ),
9                         "CustomerLostDate", CALCULATE (
10                            MAX ( <fact_date_column> ),
11                            ALL ( <product_table> ),
12                            FILTER (
13                                ALL ( <fact_date_column> ),
14                                <fact_date_column> < MIN ( <fact_date_column> )
15                            )
16                        )
17                    ),
18                    NOT ( ISBLANK ( [CustomerLostDate] ) )
19                ),
20                ( [CustomerLostDate] + [LostDaysLimit] ) < MAX ( <fact_date_column> )
21            ),
22            "FirstBuyInPeriod", CALCULATE ( MIN ( <fact_date_column> ) )
23        ),
24        [FirstBuyInPeriod] > ( [CustomerLostDate] + [LostDaysLimit] )
25    )
26)
и у меня эта мера оказывалась пустой, а в примерах эта же мера выглядит уже так
Код
1 [Absolute Recovered Customers] :=
2 COUNTROWS (
3     FILTER (
4         ADDCOLUMNS (
5             FILTER ( 
6                 FILTER ( 
7                     ADDCOLUMNS (
8                         VALUES ( Sales[CustomerKey] );
9                         "CustomerLostDate"; CALCULATE ( 
10                            MAX ( Sales[OrderDate] );
11                            ALL ( Product ); 
12                            FILTER (
13                                ALL ( 'Date' );
14                                'Date'[FullDate] < MIN ( Sales[OrderDate] )
15                            )
16                        )
17                    );
18                    NOT ( ISBLANK ( [CustomerLostDate] ) )
19                );
20                ( [CustomerLostDate] + [LostDaysLimit] ) < MAX ( Sales[OrderDate] )
21            );
22            "FirstBuyInPeriod"; CALCULATE ( MIN ( Sales[OrderDate] ) )
23        );
24        [FirstBuyInPeriod] > ( [CustomerLostDate] + [LostDaysLimit] )
25    )
26)
Строки 13 и 14 в обоих кодах.
Я так понимаю что это опечатка.
Цитата
<fact_date_column> is a column in the fact table that identifies the date of the sales transaction; its data type has to be datetime. If an external date table uses a different data type to establish the relationship with the fact table, the corresponding date has to be denormalized in the fact table to simplify this calculation.
Изменено: Lari - 01.08.2020 07:38:14
 
Lari, да, я думаю, это опечатка в шаблоне, так как разница между обычной Recovered Customers и Absolute Recovered Customers только в добавлении фильтра ALL(Product) в CALCULATE. Об этом написано перед
Код
[Recovered Customers] :=
COUNTROWS (
    FILTER (
        ADDCOLUMNS (
            FILTER (
                FILTER (
                    ADDCOLUMNS (
                        VALUES ( <customer_key_column> ),
                        "CustomerLostDate", CALCULATE (
                            MAX ( <fact_date_column> ),
                            FILTER (
                                ALL ( <date_table> ),
                                <date_column> < MIN ( <fact_date_column> )
                            )
                        )
                    ),
                    NOT ( ISBLANK ( [CustomerLostDate] ) )
                ),
                ( [CustomerLostDate] + [LostDaysLimit] ) < MAX ( <fact_date_column> )
            ),
            "FirstBuyInPeriod", CALCULATE ( MIN ( <fact_date_column> ) )
        ),
        [FirstBuyInPeriod] > ( [CustomerLostDate] + [LostDaysLimit] )
    )
)

Цитата
Note that the only difference between measures of new customers and absolute new customers is an additional filter argument, which is highlighted in the formula.
Цитата
Finally, you can count the number of absolute recovered customers (using the Absolute Recovered Customers measure) by adding ALL conditions (for tables/attributes to ignore in past transactions) in the filter argument of the only CALCULATE function included in the original Recovered Customers measure.
F1 творит чудеса
 
Максим Зеленский, спасибо.
 
Несоответствие оригиналу в переводе книги по DAX.
Александр Гинько, кажется вы пропустили целый абзац из оригинала, и написали на работающую формулу, что она работать не будет.
примеры во вложении.
Уточню, вы пишете что формула
Sales[UnitPriceVariance] = Sales[Unit Price] - RELATED ( 'Product'[Unit Price] ) - работать не будет, тогда как , как раз она и будет работать.
(стр. 130)
Изменено: Lari - 17.10.2020 11:21:04
 
Спасибо, мне уже написали про эту мою оплошность. В новой версии PDF и в новом тираже будет исправлено, а пока просто размещу пропущенный абзац:
 
Страницы: 1
Наверх