Alla I\'m in trouble with your English. Moreover sometimes I can\'t understand your Russian too. So let\'s stick to Analysis Services terms regardless of spoken language. \r
\r
Q1. Are base1 and base2 (leafs?) the only childs of their respective parents? Or maybe their siblings are 0. Then of course par1 and par2 equal 1, otherwise this behavior is abnormal. \r
\r
Q2. Strange. Given the same solve order (0) and calc pass (1) for both you should get result of meas1 aggregation function in par1 and par2. Let\'s take Foodmart 2000, Sales cube. Let cc1 subcube be {Measures.[Store Sales]}, {Store.Seattle}, {Time.[1997].[Q4].[12]}, cc2 - {Measures.[Store Sales]}. You see that Store.WA (parent of Seattle) contains 1.6 (1 for Seattle and 0.1 for the rest 6 towns in Washington), Q4 contains 1.2 (1 for December and 0.1 for November and October) and so on.\r
\r
Q2. (Another one. Sorry but you have 2 different second questions :))\r
To my mind the most reliable way is to create 3rd calculation for them with certainly higher calc pass number.\r
\r
PS. For additional info pls refer to content of the recently held sql.ru seminar (/topic/17779&pg=2), ppt called "Пользовательские вычисления в кубах Analysis Services"\r
\r
PPS. You miss \'d\' in my name.

По поводу Q1 разногласий нет, это радует.
По поводу Q2.1.
Ира, я вначале так и рассуждал, потому что это логично. Но потом проверил на Foodmarte (посмотри пример, который я приводил в своем ответе) - нет, по Time и Store (т.е. тем измерениям, к-е присутствуют в определении подкуба cc1) все равно агрегирует несмотря на наличие "живого" cc2. Почему так?

Зы. С презентацией, я думаю, вопрос будет решен не позже завтра.

Ира и Алла. Я тут немного поэкспериментировал и пришел к мысли, что на с.д. почему мир так устроен - это вопрос философский. Главное - что кое-где он все-таки подчиняется некоторым закономерностям. Применительно к нашему случаю закономерность, по-видимому, состоит в том, что агрегируются измерения, участвующие в определении subcube в сс c наивысшим Pass Number.

Пример 1.
сс1. Подкуб = {Measures.[Store Sales]}, {Store.[Store State].[WA].[Seattle]}, {Time.[1997].[Q4].[12]}, формула = 1, Pass Number = 3;
сс2. Подкуб = {Measures.[Store Sales]}, формула = 0.1, Pass Number = 2;
сс3. Подкуб = {Measures.[Store Sales]}, {Product.[Product Family].[Drink].[Alcoholic Beverages]}, формула = -0.1, Pass Number = 1

Действительно, если в контекстном меню ячейки {Store.Seattle, Time.[1997].[Q4].[12], Product.[Alcoholic Beverages], Measures.[Store Sales]} посмотреть Cell Evaluation List, то приоритеты применения вычислений будут cc1, cc2, cc3. Сс1 идет с наивысшим приоритетом, поэтому эта ячейка имеет значение 1. Скажем, у {Store.Seattle, Time.[1997].[Q4].[11], Product.[Alcoholic Beverages], Measures.[Store Sales]} Cell Evaluation List = сс2, сс3. Поэтому здесь последнее слово остается за сс2 и ячейка получает значение 0.1. На самом деле -0.1 нигде в кубе не встретится, п.ч. сс2 (у к-го Pass Number больше, чем у сс3) имеет область определения (subcube), покрывающий сс3. Поэтому, по-видимому, имеет смысл назначать сс с самым охватывающим сабкубом самый низкий приоритет и наоборот.

Но это к слову. Ключевой момент состоит в том, что агрегирование происходит по Store (напр., {Store.WA, Time.[1997].[Q4].[12], Measures.[Store Sales]} = 1.6, т.е. 1 в Seattle и 0.1 в 6 др.городах штата WA) и Time (напр., {Store.Seattle, Time.[1997].[Q4], Measures.[Store Sales]} = 1.2, т.е. 1 в декабре и 0.1 в ост.месяцах квартала). Агрегируются измерения, входящие в определение subcube для сс1. Теперь перетащим на одну из осей измерение Product и убедимся, что по нему агрегирования нет. Вдоль всего измерения Products Store Sales = 1 для {Store.Seattle, Time.[1997].[Q4].[12]} = 0.1 для {Store.Seattle, Time.[1997].[Q4].[11]} и т.д.

Пример 2.
Поменяем Pass Number у сс1 и сс3: пусть теперь cc1.PassNumber = 1, сс2.PassNumber = 2, cc3.PassNumber = 3. Понятно, что теперь последнее слово остается за cc3. Можно покрутить куб и убедиться, что агрегирование, соответственно, происходит только по измерению Products - Drink = 0.1 (-0.1 + 0.1 + 0.1), All Products = 0.3 (0.1 за Drink + 0.1 за Food + 0.1 за Промтовары). Вдоль Store и вдоль Time теперь стоят константы.

Пример 3.
Наконец, если сделать сс2.PassNumber > cc1.PassNumber, сс2.PassNumber > cc3.PassNumber, то везде будет стоять 0.1 и ни по каким измерениям агрегирование вестись не будет, т.к. в состав сабкуба сс2 ограничения по измерениям не входят.

Если все выч.области ячеек имеют одинаковые Pass Numbers, то в дело вступает порядок, в к-м они перечислены в кубе. Напр., если у них у всех Pass Number = 1, а идут они в порядке сс1, сс2, сс3, то можно считать, что cc1.PassNumber = 1.2, сс2.PassNumber = 1.1, cc3.PassNumber = 1.0, и эффект в этом случае будет, как в примере 1. Перетащим в Cube Editor, напр., сс2 вверх, переобработаем куб и получим картину, как в примере 3.

Порядок измерений в кубе оказывается также существенным.
Пример 4.
Слегка изменим сабкуб cc3: {Measures.[Store Sales]}, {Time.[1997].[Q4].[12]}. Пусть cc1.PassNumber = 3, cc2.PassNumber = 1, cc3.PassNumber = 2.
Из-за довеска по измерению Time в виде cc2 симметрия нарушается и теперь суммирование сначала по Time, потом по Store и сначала по Store, потом по Time будут давать разные рез-ты. У меня измерение Time в кубе стояло раньше, чем Store, поэтому в спорных ячейках суммирование шло именно по Time. Так, в {Store.WA, Time.[1997].[Q4], Measures.[Store Sales]} = 0.6, т.е. 0.4 + 0.1 + 0.1 (по месяцам), а не 1.2 + 6* 0.1 (по городам).
Если, не изменяя Pass Numbers, просто перетащить в Cube Editor измерение Store выше над Time (и не забыть переобработать куб), то суммирование будет идти по Store и {Store.WA, Time.[1997].[Q4], Measures.[Store Sales]} примет значение 1.8.