to backfire --
Поддерживаю SQL это рульная штука! Я даже могу нарастающий итог посчитать на диалекте Oracle. --


Юрий дайте пример.
У меня есть опыт реализации декомпазиции планов по дням с учетом их доли в прошом периоде. Это прогноз между прочем!!!
И работает этот запрос пулей..


Ответ на топик....

Я бы посоветовал сделать один куб, так проше работат и это не так сложно как кажеться и проше в обслужевании. Один куб не два...

P.S.
OLAP всеволишь измерительный инструмент, это только благодоря всяким оптимистам типа Константина и Юрия он стал нечно таким уж запредельным, а в целом он просто может промерить вам факт с учетом ваших размеров!

select p.year, f.tovar, f.city, sum(p.plan*(t.f/c.f)*(f.weight/t.w)) new_plan
from

(select year, plan from plan) p, -- План

(select to_number(to_char(data,'YYYY')) year,sum(fact) f
from fact
--
where to_number(to_char(data,'YYYY')) = 2004
--
group by to_number(to_char(data,'YYYY'))) c, Итого!!! за 2004 год


(select to_number(to_char(data,'YYYY')) year,city, sum(fact) f,sum(weight) w
from fact
--
where to_number(to_char(data,'YYYY')) = 2004
--
group by to_number(to_char(data,'YYYY')), city) t, Выручка по годам за год



(select to_number(to_char(data,'YYYY')) year,tovar,city, weight, fact
from fact) f и сам факт по дням!!

where f.year=p.year and
f.year=c.year and
f.year=t.year and
f.city=t.city

group by p.year, f.tovar, f.city

Ну что добавить могу, Birkhoff это хороший запрос. Правда план наверно сказал тебе MERGE JOIN CARTESIAN?? НУ ВООБЩЕМ ДОБАВИТЬ НИЧЕГО НЕ МОГУ ЕСТЬ ТАКОЙЖЕ ЗАПРОС ТОЛЬКО СБОКУ НАПИСАНЫЙ.
И ЮРА КАКТО ЗАДАЧУ ПОСТАВИЛ СКОЛЬСКО. МОЕ ВИДИНИЕ ТАК:

SELECT FACT_ALL.YEAR,
FACT_ALL.ITEM,
FACT_ALL.CITY,
PLAN.PLAN * (ITEM_WEIGHT / WEIGHT_YEAR) * (CITY_VAL / VAL_YEAR) NEW VAL

(SELECT YEAR, PLAN FROM PLAN) PLAN,

(SELECT YEAR, CITY, SUM(VAL), FROM FACT
GROUP BY YEAR, CITY) CITY_VAL,

(SELECT YEAR, ITEM, SUM(WEIGHT) FROM FACT
GROUP BY YEAR, ITEM) ITEM_WEIGHT,

(SELECT YEAR , SUM(WEIGHT) FROM FACT
GROUP BY YEAR) WEIGHT_YEAR,

(SELECT YEAR, SUM(VAL) FROM FACT
GROUP BY YEAR) VAL_YEAR ,

(SELECT UNIQUE YEAR, CITY, ITEM FROM FACT) FACT_ALL

WHERE PLAN.YEAR = CITY_VAL.YEAR,
AND ITEM_WEIGHT.YEAR = CITY_VAL.YEAR,
AND WEIGHT_YEAR.YEAR = ITEM_WEIGHT.YEAR;,
AND VAL_YEAR.YEAR = WEIGHT_YEAR.YEAR,
AND FACT_ALL.YEAR = VAL_YEAR.YEAR -- НУ ВРОДЕ ВСЕ ГОДА
СОЕДИНИЛ
AND FACT_ALL.CITY = CITY_VAL.CITY
AND FACT_ALL.ITEM = ITEM_WEIGHT.ITEM

Я ТАК ТОЧНО НЕ ПОНЯЛ ЧТО ХОТЕЛ ЮРИЙ ЛИБО ТАК ЛИБО КАК ЭТО СДЕЛАЛ Birkhoff.

BirkhoffOLAPMASTER

Спасибо за замечание, но я ведь говорил что запрос можно усовершенствовать.

Ну а если использовать оракловые фенечки, то переписать (мой) запрос можно например так:
Результат выдает тот же.
На Юриных данных ему даже GROUP BY не нужен :)
Классный запрос, over (partition by city) такой связкой я считал нарастающий итог.
Юрий, ну даже если мы с помошью over (partition by) не можем написать этот чудо запрос, то мы может прибегнуть к PL/SQL и тогда Ваша задача решаеться очень просто. Если Вы не знаете что это такое, то это язык программирования где можно пошагово разобрать каждую запись и понять что и сней делать, так что я думаю в этом проблем не будет.

Birkhoff
??? Спасибо за замечание ???

Это не замечание, просто интересно как оптимизатор будет это выполнят.
Так он декартовым произведением пошел?

Константин Лисянский OLAPMASTERмы может прибегнуть к PL/SQL

Ну, это будет не совсем правильно. Речь идёт о решении задачи одним запросом.

С уважением,
Константин Лисянский
http://lissianski.narod.ru

Константин я конечно понимаю FAIR PLAY. Но Юрий непонятно ставит задачу и всетаки важно достежения результата и если Юрию потребуеться постоить аж целый куб что бы ее решит, то я думаю анонимный блок PL/SQL который вставит записи в табличку это вполне честно. Примеры которые были приведены выше решали задачу Юрия. Если он с этим не согласен, пусть точнее поставить задачу.

P.S. на войне все средства хороши.

Birkhoff OLAPMASTERBirkhoff
??? Спасибо за замечание ???

Это не замечание, просто интересно как оптимизатор будет это выполнят.
Так он декартовым произведением пошел?А я понял комментарий как замечание :)
И действительно присмотрелся и нашел как можно обойтись без внешнего Group by. Хотя cost запроса остался такой же. Но видимо это зависит еще и от объемов.
Да, был декартов джойн.

Поправь меня если я не прав но over (partition by) он понимает как Group by да?? Или как то по другому работает??

Angel132 OLAPMASTER
Поддерживаю SQL это рульная штука! Я даже могу нарастающий итог посчитать на диалекте Oracle

Классный запрос, over (partition by city) такой связкой я считал нарастающий итог.

А что используя ANSI SQL посчитать нарастающий итог нельзя?

Я поправлю Birkhoff, дело в том что нарастающий итог на ANSI SQL только по первичному ключу с подзапросом. Тоесть вы в нутри запроса двигаясь по записям, находите меньшие значения первичного ключа и делаете sum от текушего к меньшему.
Это очень медленно если на большой таблице но это возможно, но а если у вас не первичного ключа то я незнаю как возможно посчитать нарастающий итог. Даже немогу предположить. Может Birkhoff у тебя уже есть опыт написания подобного запроса, я бы с удовольствием посмотрел на него.