Проект куба приводится к стандартной задаче анализа "издательство" -> "авторы", чтобы
тема была знакома многим.

Существует база данных, в которой есть таблицы "время" (выносится как dimension),
"издательство" (выносится как dimension). В обоих Dimension присутствует уровень All.
Существует таблица "авторы", которые сотрудничают с издательствами. Каждый автор может
сотрудничать с несколькими издательствами одновременно, при этом он может сотрудничать
с одним и тем-же "издательством" по нескольким "контрактам". При этом автор может
приостанавливать свое сотрудничество с издательством, в этом случае его
статус устанавливается как "пассивный" (при возобновлении сотрудничества статус выставляется
в "активный"). При расторжении контракта с издательством автор вычеркивается из связей с
данным издательством.

Задача: 1. Посчитать количество "авторов".
2. Посчитать количество "активных" авторов.

Для решения первой задачи мы готовим таблицу фактов типа

auth_id time publ
0000001 xxxx xxxx

при создании Measure "кол-во" ставим Distinct Count по auth_id - и все дела. Получаем
именно нужное количество в любом разрезе. Недурно было бы, чтобы кто-то подсказал,
как бы тут налепить "нарастающий" итог, а при просмотре куба получается

Time...
2000
All 250
1 квартал
All 100
Январь
All 30
01 2
02 3

а хотелось бы иметь запасной вариант

....
Январь
All 30
01 2
02 5 (2+3)

Для второй задачи данная схема не подходит. Для этого мы изменяем принцип подсчета количества
авторов. В таблицу фактов вываливаем следующую схему:

auth_id time publ activity
0000001 xxxx xxxx 1 -> в момент подписания контракта
0000001 xxxx xxxx -1 -> в момент приостановки/разрыва контракта

При создании измерения "кол-во активных" делаем SUM по activity. Имменно SUM, а не Count,
так как Count никогда не даст "уменьшения" числа. Все бы хорошо, но если у автора контракты
с двумя издательствами? В этом случае в разрезе издательства все будет GOOD, а вот в
суммировании будут проблемы. Но тут же условие "автор может иметь два-три контракта с одним
издательством" говорит, что и в случае каждого издательства может быть неверный результат.
Например

auth_id time publ activity
0000001 xxxx 01 1 -> в момент подписания контракта 01
0000001 xxxx 01 1 -> в момент подписания контракта 02

Получается, что количество "выскочит" в +1 от необходимого. Но и этот случай можно обойти "подтасовкой" фактов:
при первом факте подписания в Activity писать 1, а при втором факте - просто 0, и он не
увеличит число авторов. Когда же автор приостановит контракт, то ситуация будет такая

auth_id time publ activity contr_id
0000001 xxxx 01 1 01 -> в момент подписания контракта 01
0000001 xxxx 01 0 02 -> в момент подписания контракта 02
0000001 xxxx 01 0 02 -> в момент приостановки контракта 02
мы тоже не уменьшаем количество, имея в виду, что он все-же "активен".
0000001 xxxx 01 -1 01 -> в момент приостановки контракта 01

В этом случае, если специальным образом готовить таблицу фактов, то получится верный
результат "количество активных" в общем, но никак не в разрезах по contract_id. И видится
мне единственный выход - оставить только "время" как размерность. В этом случае можно не
фиксировать "по-издательскую" активность... но нехорошо это.

Как вариант мне видится еще такое:
создается дополнительное Dimension "автор". К примеру, туда закачиваются ID авторов, и
в кубе оно скрывается. В нем создается Property("Status"). Но и тут что-то не получается,
так как статус постоянно меняется (в реальном случае), и мы получаем дополнительно
необходимость применения технологии "слабо меняющихся измерений", которые на самом деле
будут "часто меняющиеся", что приведет к удвоению-утроению Dimension, и при 5-10 миллионах
"авторов" будет сложно. Зато появляется какая-то определенность в поиске "активных"
авторов - можно как-то так попробовать

COUNT( FILTER([Autor].members, [Measure].[activity] = 1)), хотя это не есть верно,
скорее всего, так как получается, что для данного решения нужно будет ежедневно
вносить данные и подтверждать наличие статуса. И как же тогда считать общее количество при SCD2?
Насколько я еще могу что-то предложить - пробовать тогда CrossJoin?

Итого, есть ли какие мнения на этот счет?

Маленькая поправка:

******************
Для решения первой задачи мы готовим таблицу фактов типа

auth_id time publ
0000001 xxxx xxxx

при создании Measure "кол-во" ставим Distinct Count по auth_id - и все дела. Получаем
именно нужное количество в любом разрезе.
******************

Верно-то оно верно, но если "автор" разорвал отношения со всеми "издательствами", то этот вариант уже никак не отразишь в таком подсчете. Потому то и подвигла меня мысль на применение +1/-1.

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

>"При этом автор может приостанавливать свое сотрудничество с издательством, в этом случае его статус устанавливается как "пассивный" (при возобновлении сотрудничества статус выставляется в "активный"). При расторжении контракта с издательством автор вычеркивается из связей с данным издательством." Туманно и неясно. Что значит "автор может приостанавливать свое сотрудничество с издательством"?

Ну это значит, что есть отношения "многие ко многим", и как вам известно, они решаются путем создания дополнительной таблицы, в которую заносятся пары auth_id, pub_id, status. Если автор подписал контракт с издательством, то внеслась соотв. пара и поле status приняло значение 1. Если приостановил контракт, то в поле Status приняло значение 0. При этом сработал триггер и в "историю" попало, что с момента xxxx по момент yyyy такой то автор имел статус "активный".

> Что такое "сотрудничество"?
Это наличие связи 'автор' - 'издательство'.

> Это что, есть ещё какой-то вид связи между "издательствами" и "авторами",
нет, других связей нет.

> минуя "контракты"?
Контракт - это больше "признак", чем факт, объяснение повода для того, чтобы в таблицу фактов внести еще одну запись, не более того. Усложнение задачи, так сказать .

> В моём понимании, "издательства" вообще не должны даже знать о существовании "авторов", для них существуют только "контракты".

Возможно вы правы, если рассматривать задачу в чистом математическом плане. Но я просто посидел, подумал над своей системой и попытался создать аналогию, не более. Поймите меня правильно, не могу я в открытую выложить реальные вопросы и структуры данных "as is". Аналогию создал как мог.

> Далее, Вы пишите: "При расторжении контракта с издательством автор вычеркивается из связей с данным издательством. "Пардон, какого именно "контракта"? По крайней мере одного, двух или всех сразу?

Виноват. При расторжении всех конрактов. Удаляется напрочь запись из таблицы [auth_id, pub_id], связывающая издательство и автора. Там в примере я продемонстрировал это, когда дважды заплюсовал автора и дважды его заминусовал. Именно этого я и пытаюсь добиться. Проблема как раз в том, что если автор подписывает только один контракт с каждым издательством, то все еще "можно свести". А вот если два - уже не могу.

> Видя такую неопределенность, лично у меня пропадает желание углубляться в существо дела. Не хочется за Вас домысливать первичные факты. Всё равно получится комедия ошибок и недоразумений.

Да нет, я собственно понимаю, что все объяснить "лицу заинтересованному" в идеале правильно я смог бы лишь за столом , показывая на готовых кубах и рисуя схемы. Нет проблем решить этот вопрос через использование ROLAP и T-SQL. Вопрос в том, сколько такое вычисление будет длиться. И потому я стараюсь все сделать прямо в кубе.

> Почему бы Вам не сделать качественный перевод Вашего вопроса на английский и не кинуть его на www.sqlteam.com? Там, вроде как, их работа - отвечать на вопросы. Через 2-3 buisness days получите ответ на Ваш e-mail.

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

Тогда лучше не "контракт", а "тип контракта" - научная литература, художественная etc. Тогда понятно, для чего такое нужно.