А чем не подходит Power BI Desktop?

Да как бы возникла лингвистически-понятийное рассогласование.Для меня "идеальный" - единственный в своём роде, остальные "всё равно что плотник супротив столяра". То есть как-бы с помощью Power BI можно что-то делать, но идеально подходит qlikview.
Вот я в максиме и выразился
В том смысле, коль вы хорошо знаете и qlikview и DAX, то чем решения на Power BI хуже решений на qlikview?

как сказать... Пока решения на PBI более прозрачны и доступны для простых смертных, хотя визуально и на этапе работы с готовым датасетом Клик симпатичнее.

Скрытый текст

Шеф тут попросил помочь с решением на QlikView, мол, "я ему пихаю данные, а он не жрет". Причина была очень простая - шеф пытался засунуть в Qlik отчет из 1С "как есть". В рамках небольших/средних компаний 1С зачастую единственный источник данных, единственная БД. Отсутствие внятного ETL-решения у Qlik - для меня большой недостаток. Условно, чтобы заставить Qlik работать, мне надо сесть скорее всего за SQL, в то время как в PBI можно первичный ETL сделать при помощи интерфейса, в 99% случаев - даже не вникая в М-код. Если знать SQL заранее - то тогда, конечно, вполне подходит и Qlik. Цитата R Dmitry написал: В подробности ценообразования Power BI не вникал POWER BI PRO: $9.99 за пользователя в месяц, 10Гб на одного пользователя/группу, глобально на клиента - 10Гб*число Pro-лицензий. Это про облако. А в клиенте да, 1 Гб импортируемых данных.

R Dmitry написал:вот именно это самая большая проблема, имхо... за последние 20 лет мне с этим не повезло ни разу, хотя слышал о компаниях, где поднят SQL-сервер, где внедрен SAP и прочее ))) а, нет, в одной конторе удалось уговорить админа 1С дать доступ к консоли запросов  

Ой, что-то я ни разу не согласен. DAX прозрачен.... Ну, ещё к PBI можно частично сказать. Хотя эти странные ограничения по сравнению с Power Query. А вот про DAX 2010-2013 - сплошное... Я ещё помню времена, когда говорили, что SQL был разработан так, чтобы им мог пользоваться каждый менеджер. Так вот с DAX до внятности SQL ох как ещё далеко.

перенесено из темы в Работе.
Предложите название темы, поменяю.

Спасибо!  
+1
О Qlik Sense

10 уроков по бизнес-анализу c Qlik Sense

Доступны на сайте 10 уроков по бизнес-анализу c Qlik Sense: (получила такой перечень на mail) в рамках курса вы получите серию обучающих писем с видео и пошаговыми презентациями, из которых вы узнаете: Как работает Qlik Sense - знакомство с готовым приложением; Как загрузить данные и сделать приложение; Создание первых визуализаций – Линейная и точечная диаграмма; Линейные графики и Карта дерева; Как рассчитать ключевые показатели эффективности – KPI; Дополнительные возможности редактора загрузки данных, подготовка данных для карты; Как разместить показатели на Карте и получить данные из Qlik Data Market; Создание повторно используемых элементов; Как создавать истории в Qlik Sense и готовить презентации, связанные с аналитикой; Как расширить стандартные возможности Qlik Sense – «Использование расширений». и странно, что при запросе на Знакомство с софтом - получила битый линк - спросила в чём дело - получила mail с извинениями (исправленный линк не проверяла) - и какой-то спам от другого имени (вообще не в тему, но при попытке переместить его в папку спам получен вопрос на сайте почтовика "желаю ли я и дальше помещать mail'ы от отправителя 4analitics в спам?")... задумалась   спам не связан с функциями сайта, или это их персонал так распоряжается адресной базой клиентов?.. или это глюк почтовика?.. хотя спам с др. адреса, но вопрос напряг (закрался вопрос - может по IP идентифицировали его)... вобщем осадок  ... думаю, если придётся, то лучше найти хорошего спеца по BI (даже тут в ветке уже двое достойных и проверенных точно есть - respect)... и всё-таки предпочесть старый добрый Microsoft... как минимум обслуживание будет хоть и не организацией (которая должна обеспечить качество обслуживания клиентов), но людьми, умеющими отвечать за свои слова (т.е. которые, действительно, могут! обеспечить качество)... имхо (подумалось мне)

p.s.
и всё-таки остаётся вопрос, а что значит "правильно хранить данные для использования в BI "?
(насколько это "правильно" отличается от обычных плоских таблиц для обычной БД)?

JeyCi, если кратко то "ноги" у BI растут из одной технологии OLAP. Поэтому, если верить гуру этого дела, для BI характерна наоборот денормализация таблиц (хотя хотелось бы знать, что вы подразумеваете под нормализованной таблицей , так как зачастую нормализованными здесь называют таблицы далёкие от этого длеа) и некоторое дополнительное обобщение базы к схеме звезда или снежинка. Центр анализируемая таблица фактов, лучи измерения, по крайней мере к Microsoft DAX это применимо в полной мере - выход из этой схемы ведёт к танцам с бубном, и даже появление двунаправленных связей в Power BI Desktop решает лишь часть проблем). Можете почитать в рамках про Power Pivot в книжке Microsoft Excel 2013 Building Data Models with PowerPivot (если дорого покупать, то можно найти в тырнете).
Максим, увы, на мой взгляд при таком подходе, что вы описали - это чуть лучше чем аналитика обычными сводными. А чуть по серьёзнее начинается такая головоломка... Подъём по измерениям вверх я освоил, многие-ко-многим разгрыз (хотя при увязанных данных в Power BI Desktop это не так актуально). Но дальше почти тупик. Вроде в 2016 и Power BI добавили функций в стиле SQL - можно было бы решать спокойно задачу в SQL стиле, так нет.
Для примера NATURALLINNERJOIN не работает, пытаемся соединить SUMMARIZE,сделанное по фактам со следующим измерением.

правильно ли я сориентировалась? (тоже решила погрызть в выходные )
1) RELATED для создания иерархии и RELATEDTABLE или? /и далее использование parent-child hierarchy через  IF ( ISFILTERED ( или, например, EARLIER и т.д.

тогда иерархии ещё полистаю - на msdn как создаются Hierarchies in PowerPivot... и остальное - чтобы потом по ним ходить вверх... Спасибо!
P.S.
кажется поняла основную проблему - "задвоение связей", наверно, можно назвать - т.е. ключи перестают быть уникальными, когда идём вверх [например, обобщая от клиентов покупающих к магазинам продавшим, вопрос - какой товар?(или сколько)]... поэтому вверх идём, осторожно разруливая многие-ко-многим (чтобы не иметь ошибки базового свойства[способности] PP - xVelocity)... пример: unique SenderIDs (поскольку даже Сводная имеет горизонтальное расположение атрибутов [столбцов] - n:1 и вертикальное расположение кортежей [строк] 1:n), не имея n:n возможностей разруливания... а нам приходится иметь дело с n:n [условно: магазин - (товар) - клиент], если измерение товар расположено отдельным лучом  из таблицы-фактов... а магазины отдельным лучом (с ФИО, обслуженных клиентов, как пример)... вроде снежинка   - или похожа на неё (точнее, пример - очень условный - "похож")
P.P.S
и словарный запас немножко поправила - ETL (for Extract,Transform and Load) techniques ("sometimes also styled, ELT, extract load & transform [PowerPivot would fall into this catergory]" )

и, честно говоря, помнится мне одна фраза, заставившая задуматься когда-то надолго (при знакомстве с возможностями тянуть по связям) - "задавить фантомы"   ... периодически случается, что бывает нужно... (хотя сама не сталкивалась в своих задачах)... такой казус может иметь место при работе с реляционными структурами... бывает ли такое при работе с иерархической моделью многомерной бд (куба)? и есть ли какие-то общие рекомендации для Power Pivot?
p.s.
если кто-нибудь будет давить фантомы в Power Pivot   - выложите, пожалуйста, сюда, посмотреть... заранее спасибо
(для Power Query Андрей VG там по линку показал)

кстати, буквально сегодня натыкалась на подобного рода конструкцию (правда задача немного др) - тоже с участием EARLIER... правда по ранжированию, не по сумме, но выглядит, как =RANKX( FILTER( ALL(‘Internet Sales’), [CustomerKey] = EARLIER([CustomerKey])), эта была part2... всё очень может быть, что если EARLIER имеет место быть в формуле для ABC-анализа, то и FILTER их как-то надо (тех EARLIER)... чтобы отделить... имхо... но тоже пока только предполагаю (с учётом увиденного сегодня)
p.s. part1 -   Another Post about Calculating New and Returning Customers здесь
p.p.s  хотя сам ABC-анализ может быть и так  
**********
но, наверно, ведь должен быть способ НЕ использовать двунаправленную фильтрацию - а какой-нибудь альтернативный вариант взамен (или птица где - пока ещё по диагонали всё просматриваю) - когда она становится палкой, а не на пользу... вобщем, спасибо, буду знать и чуть что искать обходных путей    (если вдруг придётся)

вот кстати подумалось мне - наверно, для таких случаев и существует конструкция FILTER( CONTAINS( ... тогда и появляется возможность воспользоваться (люблю я это слово из др.области) Edge-ем   би-направленной фильтрации (или 2х-этапной?) - хотя в контексте "измерение-мост-измерение" - это 2 направления, - т.е. создали промежуточную таблицу для разруливания n:n со связями n:1 и 1:n - и если в контекст фильтра не попадает никто(ничто) из промежуточной таблицы - то фильтрация далее по связям и не происходит (не-производится)... факт экономии времении really memory-efficient подход... имхо (мне кажется би- в данном случае не в разных направлениях, а два друг за другом, именно через связку CONTAINS)... но честно говоря, тоже пока знакома по диагонали с новыми технологиями... (поэтому пытаюсь понять на пальцах больше, чем на словах)
p.s. а вообще, показалось мне, что правильная организация "таблиц" (измерений), чтобы удобно применять на них фильтрацию любую (не зависая в астрале   ) и по настроенным фильтрам (через синтаксис DAX) вытягивать нужное и/или агрегированное по максимально короткому пути, именно в плане времени применения фильтров к большим выборкам... это и есть залог   Здоровья Многомерных БД и простоты работы с ними... для этого видела советы:
а) минимизировать в принципе количество фильтраций
б) создавать отдельные измерения для интересующих моментов (так сказать, уменьшая выборку для работы изначально) - например NewClients выдвинуть отдельным измерением, если это важно для (зависит от)
и в таблице-фактов оформить это отдельным ключом....
только когда они перестают быть NewClients - надо продумать смену значения ключа... вобщем, ухаживать за БД, как обычно за сервером... только процедур, наверно, не написать   ... в принципе и понятно, PP всё-таки для аналитики, а бд-администрирование - это дело др рук... важно, чтобы и одни руки и другие всё-таки нашли оптимальную архитектуру для обоих (обеих) - одним, что строить, другим, что юзать - проблемы, если не будет достигнуто взаимопонимание, возникнут сразу же (когда построенным невозможно пользоваться)... ВЫВОД ВСЕМ: берегите память, создавая сложные системы, - в будущем сэкономите время на фильтрацию всего   всё-таки архитектуру должны создавать ювелиры...
(наконец я поняла, что главное в БД)  
я бы сказала:
чем меньше выборка (измерение) и чем реже фильтруем - тем меньше времени сидим за компьютером в ожидании нужных результатов

вот уже и наткнулась случайно...
в DAX  существуют три типа контекста: контекст фильтра, контекст строки   и  контекст запроса.
(коротко и ясно)