Да, Вы правильно поняли.
Но, хотелось бы ещё отметить три разноплановых момента:
1. Ваша свобода комбинирования размерностей ограничивается производительностью системы. Ну и структурой данных, если пользователи не создают сами индексы/кубы и т.д. для своих задач.
2. Необходимо помнить, что описанный Вами отчет — промежуточный материал в работе аналитика над его задачами. Конечный отчет, который ляжет на стол менеджеру, будет содержать именно сгруппированные данные, которые этот аналитик будет досчитывать в Excel-е.
3. Система, которую я описал, идеальная абстракция. На практике приходится быть гибче, и поддерживать промежуточные варианты обращения к данным. Диалектика, так сказать, в ответ на Ваш тезис)
Смотря, что понимать под новым отчетом.
1. Если новый перечень объектов/агрегация (даты, подразделения, продукты...) — то они все они предсказуемы и предрасчитаны (даты — месяца, кварталы, годы; подразделения — более крупные подразделения и т.д.)
2. Если совсем новый показатель — то печалька: пользователь его сам не создаст. Но это не страшно при "вытягивающей" системе работы, если данных, которых пользователи не заказывали, в БД не появляется.
Утверждение про то, что нужно анализировать «сырые» данные, очень спорное. По мере расширения перечня задач, которые решает система, я, например, пришел к тому, что в конечные отчеты вообще не должны попадать непредрассчитанные и не сохраненные в БД агрегации. Кроме того, в случае изменения исходных данных и их перерасчета, предыдущую версию данных пользовательского отчета во многих случаях лучше сохранить. Соображений в пользу этого несколько. Основные: 1) не оставить пользователя без отчета, когда идет обновление «сырых» данных; 2) давать возможность получить предварительный отчет по неполным данным, а потом узнать какая составляющая изменилась.
Но, хотелось бы ещё отметить три разноплановых момента:
1. Ваша свобода комбинирования размерностей ограничивается производительностью системы. Ну и структурой данных, если пользователи не создают сами индексы/кубы и т.д. для своих задач.
2. Необходимо помнить, что описанный Вами отчет — промежуточный материал в работе аналитика над его задачами. Конечный отчет, который ляжет на стол менеджеру, будет содержать именно сгруппированные данные, которые этот аналитик будет досчитывать в Excel-е.
3. Система, которую я описал, идеальная абстракция. На практике приходится быть гибче, и поддерживать промежуточные варианты обращения к данным. Диалектика, так сказать, в ответ на Ваш тезис)
1. Если новый перечень объектов/агрегация (даты, подразделения, продукты...) — то они все они предсказуемы и предрасчитаны (даты — месяца, кварталы, годы; подразделения — более крупные подразделения и т.д.)
2. Если совсем новый показатель — то печалька: пользователь его сам не создаст. Но это не страшно при "вытягивающей" системе работы, если данных, которых пользователи не заказывали, в БД не появляется.