Ни чего не понял, точнее понял что все удаляется и все свободны. :)

На самом деле what-if моделирование составная часть систем OLAP-планирования, которые обсуждается тут
http://www.sql.ru/forum/actualthread.aspx?tid=165207

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

А жаль.

2Беляев

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

2immutable
Ну импорт в реальной практике обычно оказывается бесполезен и не только в Cognos, но и в других OLAP-планировщиках.
Фактические операции как правило у людей уже в виде цивилизованных управленческих проводок, а посокольку это другая модель, чем в OLAP, то загрузить их и главное сопоставить с фактами практически невозможно.
Это не только мое мнение, вы без труда найдете обзоры систем планирования, где слабость интеграции подчеркивают различные эксперты.
Для примера случай из моей практики.
В корпорации DDB используется Hyperion Pillar. Так сотрудники DDB по всему миру ...вбивают факты руками.

Ну что за паника такая? :)
Picasso так некоторые спецы Microsoft называли проект OLAP-сервера в составе Юкона. Не знаю сменили ли они это рабочее название и насколько оно было официальным.

2immutable
Опишите если можно подробнее что за решение.
- Каков источник фактических данных?
- Какие бюджеты вы строите?
- Инструментарий?

Я охотно верю, что существуют частные решения, но с общим обычно проблемы. Иными словами при попытке перейти от частной к комлексной системе с планированием и план/фактам по всем аспектам деятельности можно получить неразрешимую ситуацию.
Решение DDB как раз комплексное и используется для формирования всех основных бюджетов БДДС, БДР и по листу. Тут они и обламались...

Я не настроен так же оптимистично как Владимир. В Юконе WB улучшен конечно во многих отношениях - и для concurrent writes, и для low-overlap writes, не говоря уже о том что алгоритмы weighted allocation работают используя NonEmptyCrossJoin алгоритм. Кстати даже в SP4, weighted allocation с весом по умолчанию тоже переделана точно так же. Но поскольку в предыдущих постах Владимир писал про equal allocation - то тут ожидать улучшений не следует.

Да? А как же насчет этой информации от Microsoft? Надеюсь это не просто маркетинг про десятикратный рост производительности. Нельзя ли привести примеры работы с десятикратным ростом, которые можно человеческим языком повторить клиентам, в целях убеждения перехода Юкон.

Enhancements to data writeback include a ten-fold performance improvement . The analytic application can write data back to an aggregate cell, and optionally perform allocation of the aggregate data to its underlying leaf data.
Business Intelligence and Data Warehousing in SQL Server Yukon

Насколько я понимаю optionally perform allocation и weighted allocation означает, что можно использовать WB для разноски данных ниже по листам не только равными долями, но и по весовым коэфициентам.
Некоторое упоминание о практическом использовании данного метода тут:
http://www.o2olap.com/o2olap_EnterData.htm

Кто либо может привести пример разноски ниже по листам с использованием весовых коэфициентов?

Вот пример для MSAS2k, можно ли пример с использование новинок Юкона?

От:John Desch [MS] (jdesch@msonline.microsoft.com)
Тема:Re: Writeback -> USE_WEIGHTED_ALLOCATION

Making the following assumptions:
1. The time dimension uses a Year, Quarter, Month, Day structure in a star
schema
2. The product dimension uses a Family, Group, Item structure in a star
schema

I was able to get the following UPDATE CUBE statement to successfully
execute.
UPDATE CUBE [Sales] SET
([Products].[All Products].Dryers, [Measures].[Sales Units]) = 3000
USE_WEIGHTED_ALLOCATION BY
IIF([Time].[Year].UniqueName="[Time].[All Time].[2001]",
([Time].[All Time].[2000],[Products].CurrentMember)/
([Time].[All Time].[1999],[Products].CurrentMember),
([Time].[All Time],[Products].[Dryers])/
([Time].[All Time],[Products].[Washers]))

However, based on your last posting, I suspect that's not exactly what
you're wanting to do.

One of the issues that you're going to encounter is that unless you're
writing back to the DataMember of a Parent-Child dimension, any writeback
occurs at the cell level and is going to impact aggregate values in both
the Time and Product Dimension.

If you're wanting to update at the Time.Year level and have the data
allocated to the Time.Quarter, Time.Month membersbased on actual costs, the
only possibility I can think of would be to build the Time Dimension as a
Parent-Child dimension and set the Members With Data property of the
dimension to either "Non-Leaf Data Hidden" or "Non-Leaf Data Visible" and
add a Custom Rollup something like:
IIF(IsLeaf(Time.CurrentMember),
CalculationPassValue(Time.Currentmember,0),
rollupchildren(Time.currentmember,"+"))

Likewise, if you're wanting to update at the Product.Family level and have
the data allocated to the Product.Group and Product.Item members, the same
approach described above should work.

Regards,

John Desch, MCDBA, MCSD
This posting is provided “AS IS” with no warranties, and confers no rights.

Поскольку этот пример пользуется weigthed allocation, то можно ожидать улучшения производительности, хотя в данном случае weight использует IIF со статической провекой, что не очень понятно. Гораздо более эффектовно делать такую провеку в коде программы, и потом использовать нужный allocation driver.

Хорошо, а нельзя ли чуть точнее. А как бы вы переделали MDX и что бы вы уже доделали в коде программы?

И тем не менее, расширения в WB в Юконе есть и не безинтересные.

Cell Annotations in AS2005

http://www.sqlserveranalysisservices.com/OLAPPapers/Cell%20Annotations%20in%20AS2005v1.htm

2backfire

А для каких целей вы используете WB?
Я сейчас не применяю WB в решениях по планированию, т.к. обычная система планирования состоит из взаимосвязанных бюджетов.
Иными словами, мало чтобы поменялся один куб, нужно чтобы изменились связанные кубы (бюджеты).
Это можно конечно делать оперируя с WB таблицей и формируя на ее основе другие DWH. Но мне показалось такое решение не самым эффективным.

2Моша.
Если Юкон будет терять таблицы с данными о WB, тогда в массе приложений по планированию возникнут серьезные проблемы. Разработчики завязываются на эту табличку.