День добрый,
В 2010 появилась штука поз названием срез(slicer). Является неким подобием фильтра, выведенном на кнопки. Создаётся на базе 1 измерения(поля/столбца/критерия).
Вопрос заключается в следующем - как подключить срез к нескольким формально разным измерениям, содержащим одни и те же значения, из разных источников данных?
В идеале хотелось бы полное сохранение функционала, т е в частности возможность автоматического обновления списка уникальных элементов исходя из данных всех источников, возможность использования сводных таблиц по кажому источнику в отдельности при подключённых срезах и так далее.
(Сразу предупрежу, что "проблема" известна и изначально такое использование вроде бы не предполагалось создателями. Сюда выкладываю в надежде на наличие решения на подобии создания сводной таблицы на базе несколькиз диапазонов.)
На примере:
Имеется 2 базы данных разной структуры, содержащие разные данные. В обоих базах есть измерение под названием "месяц". Хотелось бы иметь 1 срез, при использовании которого "фильтровались"(Или уже можно вводить термин "срезались"? :) ) бы значения в обоих базах.
Варианты решения, которые я вижу на данный момент(пишу, т к может пригодиться кому-нибудь или помочь в качестве отправной точки при поиске решения):
1) Использование функций куба, добавляя туда критерии исходя из среза, подключённому к другому источнику данных.
То есть создаётся срез на один из источников данных.
Все остальные источники данных фильтруются путём использования критерия фильтрации, получаемые из среза, созданного для первого источника.
Тут практически одни минусы. По факту полный функционал сохраняется лишь при работе с первым источником данных. В остальных возможно лишь использование путём получения данных формулами куба(и, соответственно, теряется возможность использования сводных таблиц со всеми вытекающими), теряется производительность, список уникальных элементов получается лишь исходя из данных первого источника и не всегда является корректным.
2) Создание отдельных срезов для каждого источника данных и использование макросов по дублированию действий(фильтрации?) для всех срезов при произведению действий по одному из срезов.
Собственно, более-менее рабочий вариант для локальной работы, возможно кого-то устроит.
Появляется возможность работать со сводными таблицами.
Остаются проблемы(решаемые) по разным спискам элементов, однако становится невозможной нормальная работа с sharepoint(пол беды) и появляется целый ворох проблем с макросами: некорретное использование/боязнь/политики безопастности и т. д.
Собственно, в моём случае не подходит.
3) Создание консолидированной базы данных на основе нескольких баз данных с объединением "общих" измерений и созданием кучи новых, которые используются(имеют значения) лишь в части консолидированных данных.
Из плюсов: не требует макросов и сохраняется полный функционал.
Из минусов:
-выглядит некрасиво(что важно :( )
-громоздкость и невозможность нормального использования
-присутствия множества заплаток(в том числе видимых конечным пользователям, в частности в списках элементов в измерениях) и, соответственно, наличие кучи оговорок по использованию, которые необходимо доносить до конечных пользователей.
-сильно падающая производитеьность
-крайне трудоёмкий процесс настройки консолидации данных из разных источников, включающий множество танцов с бубном.
Этот вариант допустим для местечковой задачи, но для развивающейся "системы" неприемлим, т к "оказываемые негативный эффект" минусов увеличивается в геометрической прогрессии.
Вот, собственно, и всё. Вгоняет в тоску...
Буду рад выслушать и обсудить как варианты решения, так и просто советы.
Заранее спасибо.
