Добрый день, прошу помощи.
Данные в таблице фактов, на основе которой строится куб, хранятся в разрере: Менеджер-Адрес-Товар.
В кубе уже есть вычисляемая мера по расчету количества сработанных клиентов:


Теперь необходимо создать меру, которая бы считала количество сработанных клиентов без привязки к товару.
Т.е. не важно, какой товар выбирается, количество клиентов должно в каждой строке выходить одно и то же.

Спасибо, помогло.

Но теперь я столкнулась со следующей проблемой:
Куб, который я создаю имеет три независимых измерения на товар: Товар, Подгруппа и Группа. Связи между Товаром и Подгруппой и Подгруппой и Группой один ко многим (одному товару соответствует одна подгруппа, и каждой подгруппе одна группа).
Данная формула прекрасно работает в рамках измерения Товар, но не работает в рамках измерений Подгруппа и Группа.
А заказчик хочет, что бы независимо от любого из трех измерений считалось количество клиентов, сработавших в этом месяце.

Попробовала сделать в лоб:



Данная формула прекрасно работает на одном из трех измерений, но если вывести в отчет два и более, уже показывает не ту цифру.

Ситуация еще усложняется тем, что в кубе две таблицы фактов. Первая имеет детализацию Менеджер-Адрес-Товар, а вторая Менеджер-Подгруппа. И соответственно измерения Товар там вообще не предполагается. Более того измерение Товар вообще нужно только для данной формулы и мне для тестирования. Пользователь в конечном кубе его вообще не увидит.

Огромная просьба о помощи. До этого все кубы, с которыми я работала, были более стандартной конфигурации.

Небольшое пояснение по предыдущей картинке: в колонке Test в каждой строчке должно быть 20.

ShIgor, ОГРОМНОЕ СПАСИБО. Все получилось.

Разделены они по двум причинам:
1) Товар пользователям не нужен совсем. Он нужен только для вычисления пары мер.
2) Группа и Подгруппа хотя и имеют классическую связь один ко многим, но по факту данная связь не постоянно и подгруппы могут перекидываться из одной группы в другую. В 1С это хранится в регистре сведений. А я уже через запрос собираю срез последних.

Andy_OLAP,

В данном конкретном случае измерение [Адрес].[Адрес] это измерение с свойством key - id из 1С и свойством name - наименованием оттуда же. Две точки, даже имеющие один адрес - это все равно заведомо две разные точки в базе, имеющие разные id. Соответственно считается все корректно.

Если же структура БД заказчика позволяет к разным клиентам привязывать одну и ту же точку, то в таких случаях будет считаться как одна точка, т.к id один и тот же. Что будет соответствовать структуре БД.

ShIgor,

В основном я их разделила, потому что в таком случае нужно все таблицы фактов цеплять через ТоварИД, а в одной из таблиц фактов этого поля просто нет. И чтобы ничего не усложнять в исходных данных, сделала их отдельно.
Возможно просто не хватило опыта и это можно было сделать более оптимально. Но когда заказчику нужно срочно иногда времени на подумать просто нет, нужно брать лопату и начинать копать. И не важно, что в метре почва более мягкая.
+ нельзя исключать ситуации, когда через год заказчик вдруг захочет видеть историю изменений в связке Группа-Подгруппа и тогда, в случае единого измерения, это будет сделать намного сложнее.

Andy_OLAP,

В данном случае есть вполне конкретный термин: Активная Клиентская База. И этот термин исходит именно от заказчика. Так что путаницы точно не будет.