Это, конечно, всё интересно и занимательно, с удовольствием посмотрел, спасибо за видео, но SCD должен быть реализован в DWH, обновление размерностей делается в процессе ETL/ELT (Вы это знаете). Если в DWH нет данных из CRM (или еще откуда), то нужно не заниматься всем этим на клиентской стороне, а дать пинка архитектуру/разработчикам DWH и сделать всё так, как и должно быть. Иначе будет аналитика в стиле "кто в лес, кто по дрова".
@@ConstellationBI Перенося базовую обработку данных, в данном случае SCD, на уровень клиентского приложения Вы закладываете мину, точнее говоря, строите полноценное минное поле, по которому потом невозможно будет пройти, не подорвавшись. PBI не является базой данных, все, что касается импорта и его оркестрации (ETL-ELT) нужно оставлять специализированным инструментам типа SSIS. Сервер БД хранит структурированные и иногда не до конца структурированные данные (DWH). Все, что касается хранения и последующего извлечения данных: логика (ключи, в т.ч. построение суррогатных ключей на основе бизнес-ключей), оптимизация хранения и обработки (индексы кластерные и некластерные, фильтрованные, колоночные,…) и т.д. тоже дело сервера БД, ну просто потому, что он это умеет, и умеет хорошо. Выскажу непопулярную, наверное, в кругах PBI-ников мысль, что PBI это скорее инструмент визуализации и построения дашбордов (фронт-энд), а не модели данных. Модель (бэк-энд) нужно делать на аналитическом сервере поверх DWH. Будут там многомерные кубы или табличные - дело скорее вкуса, но ИМХО многомерные с языком MDX имеют существенные преимущества с точки зрения логики написания мер и запросов. Несмотря на разнобой в синтаксисе функций MDX’а он все же оперирует кортежами и сетами поверх иерархий, что для написания мер ИМХО понятнее и логичнее, чем DAX’овский контекст. Но это не главное. Главное в том, что если у вас уже есть табличный или многомерный куб, то в нем уже задана модель данных + он хранит агрегации, работать из PBI с таким кубом быстро и удобно. Просто подключаешь куб и получаешь готовую модель данных, осталось только сделать грамотную визуализацию. Пересчет очень быстро выполняется сервером, не нужно иметь на клиентской стороне суперкомпьютер, достаточно дохлого канала связи, даже мобильный интернет отлично пригоден для передачи DAX/MDX запросов серверу и получения от него ответов. А работы с DAX'ом - это как раз на аналитическом сервере в кубе, если он табличный. А вот если пытаться консолидировать именно в PBI данные из разных источников, часть из которых вообще экселовская (в экселе нет типизации и максимальное количество строк, если не ошибаюсь, ограничено 1 млн.), поручать PBI построение модели, обработку данных,… то тогда мы подорвемся на минах, связанных с целостностью данных и Data Quality, ограниченному объему хранимых данных, производительностью и вообще всем прочим, что делают БД и серверы аналитики. Плюс к тому, у юзеров/аналитиков будут отличающиеся друг от друга модели данных, что приведет к расхождениям в разных отчетах и, в конечном счете, к потере управляемости компании. Ну т.е. ложкой нужно есть суп, а вот заворачивать гайки нужно ключом, это немного разные инструменты. У Вас хороший материал и по визуализации, и по DAX’у, понятно, что он носит учебный характер и показывает логику и возможности языка. За это Вам огромный поклон. Но вот применять DAX в PBI так, как в этом вашем примере с SCD, я никому не посоветую)))
Все мои видео на примерах из жизни. Я не выдумываю задачи)) У меня был заказчик, для которого отчет PBI коннектился напрямую к CRM. И все хорошо работало до тех пор, пока заказчик не захотел проанализировать апдейты статусов. На этом шаге объяснить ему, что срочно нужен сервер (а это расходы на архитектора бд, на обслуживание сервера, на перестройку отчета в PBI) - невозможно. Может и возможно, но эти расходы нерациональны если заказчик не собирается масштабировать бизнес настолько, чтобы упереться в лимиты PBI. Так что проще это было решить на стороне PBI, тем более что в PBI есть все возможности это сделать и программа заточена на то, чтобы получать, преобразовывать и моделировать данные. Да, бывают случаи, когда сервер просто необходим, причем эти случаи разные и не связаны лишь с объемом данных. Но повторюсь, случаи бывают разные)) То, что вы описали хорошо ложится на условия большой или быстро растущей компании, в которой больше одного человека говорят на языках программирования 😉😉 всегда нужна поддержка единомышленников 👌
А как это сделать, если подключаешься к 1с зуп по одата. И у тебя отдельно справочники отделы, должности, сотрудники и отдельно документы прием, увольнение и перевод.Причем в документе увольнение нет данных по отделу и должности.
Можно денормализовать таблицу с приемом/увольнением, добавив должности и отделы. Можно только отредактировать таблицу прием/увольнение как показала в видео и загрузить в модель обе таблицы, настроив связи
Добрый день! Подскажите,пожалуйста,можно ли из Меры = на конец месяца сделать меру Нарастающего итога!? Необходима для дальнейшего вычисления мощности нараст.итогом..! Классическим путём возвращает те же значения..
Добрый день, Ольга! Не знаю, что вы имеете ввиду под "классическим путем" 🙂, но если "возвращает те же значения", может быть ваша мера на конец месяца уже отражает нарастающий итог? Можете посмотреть мое видео о нарастающем итоге (th-cam.com/video/8H_8x5PcKkc/w-d-xo.html), как сделать его быстрой мерой. Или напишите мне более подробно на почту😉
Спасибо, Ангелина! Книги Марко Руссо и Альберто Феррари. Банально, но это классика) Но на самом деле много книг не надо. Для начала достаточно одной книги, которая даст хорошее системное представление об основных принципах работы PBI и PQ. А дальше гуглеж по иностранным источникам по конкретным задачам. Потому что программа постоянно развивается, обновляется, и решение с какого-нибудь форума может быть более актуальным, чем алгоритм из книги.
![[UNCUT] “บอสณวัฒน์” ลากไส้!! ใครหนุนหลัง "แม่ตั๊ก ป๋าเบียร์" I คนดังนั่งเคลียร์ I 30 ก.ย. 67](http://i.ytimg.com/vi/QlD7mU2KKRk/mqdefault.jpg)
Это, конечно, всё интересно и занимательно, с удовольствием посмотрел, спасибо за видео, но SCD должен быть реализован в DWH, обновление размерностей делается в процессе ETL/ELT (Вы это знаете). Если в DWH нет данных из CRM (или еще откуда), то нужно не заниматься всем этим на клиентской стороне, а дать пинка архитектуру/разработчикам DWH и сделать всё так, как и должно быть. Иначе будет аналитика в стиле "кто в лес, кто по дрова".
Вы правы) но если бы все в этом мире делалось правильно и каждый выполнял бы свою работу идеально... 😁😁
@@ConstellationBI Перенося базовую обработку данных, в данном случае SCD, на уровень клиентского приложения Вы закладываете мину, точнее говоря, строите полноценное минное поле, по которому потом невозможно будет пройти, не подорвавшись. PBI не является базой данных, все, что касается импорта и его оркестрации (ETL-ELT) нужно оставлять специализированным инструментам типа SSIS. Сервер БД хранит структурированные и иногда не до конца структурированные данные (DWH). Все, что касается хранения и последующего извлечения данных: логика (ключи, в т.ч. построение суррогатных ключей на основе бизнес-ключей), оптимизация хранения и обработки (индексы кластерные и некластерные, фильтрованные, колоночные,…) и т.д. тоже дело сервера БД, ну просто потому, что он это умеет, и умеет хорошо.
Выскажу непопулярную, наверное, в кругах PBI-ников мысль, что PBI это скорее инструмент визуализации и построения дашбордов (фронт-энд), а не модели данных. Модель (бэк-энд) нужно делать на аналитическом сервере поверх DWH. Будут там многомерные кубы или табличные - дело скорее вкуса, но ИМХО многомерные с языком MDX имеют существенные преимущества с точки зрения логики написания мер и запросов. Несмотря на разнобой в синтаксисе функций MDX’а он все же оперирует кортежами и сетами поверх иерархий, что для написания мер ИМХО понятнее и логичнее, чем DAX’овский контекст. Но это не главное. Главное в том, что если у вас уже есть табличный или многомерный куб, то в нем уже задана модель данных + он хранит агрегации, работать из PBI с таким кубом быстро и удобно. Просто подключаешь куб и получаешь готовую модель данных, осталось только сделать грамотную визуализацию. Пересчет очень быстро выполняется сервером, не нужно иметь на клиентской стороне суперкомпьютер, достаточно дохлого канала связи, даже мобильный интернет отлично пригоден для передачи DAX/MDX запросов серверу и получения от него ответов. А работы с DAX'ом - это как раз на аналитическом сервере в кубе, если он табличный.
А вот если пытаться консолидировать именно в PBI данные из разных источников, часть из которых вообще экселовская (в экселе нет типизации и максимальное количество строк, если не ошибаюсь, ограничено 1 млн.), поручать PBI построение модели, обработку данных,… то тогда мы подорвемся на минах, связанных с целостностью данных и Data Quality, ограниченному объему хранимых данных, производительностью и вообще всем прочим, что делают БД и серверы аналитики. Плюс к тому, у юзеров/аналитиков будут отличающиеся друг от друга модели данных, что приведет к расхождениям в разных отчетах и, в конечном счете, к потере управляемости компании. Ну т.е. ложкой нужно есть суп, а вот заворачивать гайки нужно ключом, это немного разные инструменты.
У Вас хороший материал и по визуализации, и по DAX’у, понятно, что он носит учебный характер и показывает логику и возможности языка. За это Вам огромный поклон. Но вот применять DAX в PBI так, как в этом вашем примере с SCD, я никому не посоветую)))
Все мои видео на примерах из жизни. Я не выдумываю задачи)) У меня был заказчик, для которого отчет PBI коннектился напрямую к CRM. И все хорошо работало до тех пор, пока заказчик не захотел проанализировать апдейты статусов. На этом шаге объяснить ему, что срочно нужен сервер (а это расходы на архитектора бд, на обслуживание сервера, на перестройку отчета в PBI) - невозможно. Может и возможно, но эти расходы нерациональны если заказчик не собирается масштабировать бизнес настолько, чтобы упереться в лимиты PBI. Так что проще это было решить на стороне PBI, тем более что в PBI есть все возможности это сделать и программа заточена на то, чтобы получать, преобразовывать и моделировать данные. Да, бывают случаи, когда сервер просто необходим, причем эти случаи разные и не связаны лишь с объемом данных. Но повторюсь, случаи бывают разные)) То, что вы описали хорошо ложится на условия большой или быстро растущей компании, в которой больше одного человека говорят на языках программирования 😉😉 всегда нужна поддержка единомышленников 👌
А как это сделать, если подключаешься к 1с зуп по одата. И у тебя отдельно справочники отделы, должности, сотрудники и отдельно документы прием, увольнение и перевод.Причем в документе увольнение нет данных по отделу и должности.
Можно денормализовать таблицу с приемом/увольнением, добавив должности и отделы. Можно только отредактировать таблицу прием/увольнение как показала в видео и загрузить в модель обе таблицы, настроив связи
@@ConstellationBI Спасибо за ответ. Ничего не понял, пойду дальше дальше заниматься прокрастинацией😀
Напишите мне на почту, посмотрим)
Добрый день! Подскажите,пожалуйста,можно ли из Меры = на конец месяца сделать меру Нарастающего итога!?
Необходима для дальнейшего вычисления мощности нараст.итогом..! Классическим путём возвращает те же значения..
Добрый день, Ольга! Не знаю, что вы имеете ввиду под "классическим путем" 🙂, но если "возвращает те же значения", может быть ваша мера на конец месяца уже отражает нарастающий итог? Можете посмотреть мое видео о нарастающем итоге (th-cam.com/video/8H_8x5PcKkc/w-d-xo.html), как сделать его быстрой мерой. Или напишите мне более подробно на почту😉
Анна, огромное спасибо!! Очень выручили!
😉
Анна, вы прекрасно объясняете! Благодарю за мастер - класс.
Скажите, пожалуйста, есть ли у вас книги фавориты по изучению Power Query или языка DAX?
Спасибо, Ангелина! Книги Марко Руссо и Альберто Феррари. Банально, но это классика) Но на самом деле много книг не надо. Для начала достаточно одной книги, которая даст хорошее системное представление об основных принципах работы PBI и PQ. А дальше гуглеж по иностранным источникам по конкретным задачам. Потому что программа постоянно развивается, обновляется, и решение с какого-нибудь форума может быть более актуальным, чем алгоритм из книги.
@@ConstellationBI Полностью согласна, развитие проиходит регулярно .. нужно постоянно держать руку на пульсе с обновлениями :) Благодарю за ответ! 👍👍👍