Angel13 OLAPMASTERЯ поправлю Birkhoff, дело в том что нарастающий итог на ANSI SQL только по первичному ключу с подзапросом. Тоесть вы в нутри запроса двигаясь по записям, находите меньшие значения первичного ключа и делаете sum от текушего к меньшему

Зачем же вложенный подзапрос? можно и просто JOIN'ом.

select T1.USERNAME, T1.USER_ID, sum(T2.USER_ID)
from DBA_USERS T1
join DBA_USERS T2 on T1.USERNAME >= T2.USERNAME
group by T1.USERNAME, T1.USER_ID
order by 1

-- выполнять на Oracle.
Но согласен, что аналитические функции будут работать быстрее. Сам Кайт об этом писал :)
И что оптимизатор сказал на этот запрос какой у него план???
join DBA_USERS T2 on T1.USERNAME >= T2.USERNAME с таким соединением наверно хороший план выполнения.
Я вот выполнил для DBA_USERS и план был вообще нереальный.

Jurii2 олапист & backfire:

и опять Вы как всегда неправы на счет медленной работы запросов

Вы хотите сказать, что прямые SQL-запросы всегда работают быстро?
Недавно я анализировал данные объемом около 30 тысяч записей - делал аналитические запросы, создавал вычисляемые показатели на основе статистических функций - выполнялись SQL-запросы очень небыстро...

к Вашему сведению в современных СУБД есть такой модуль как оптимизатор запросов, который не будет без крайней надобности вытягивать по 10 миллиардов строк
это тоже стоит обьяснить Вам подробнее?

Это было небольшой провокацией с моей стороны, когда я озвучил цифру 10 миллиардов. Такой объем является привычным для телекомовских компаний, и многие участиники форума работали с этими объемами. Но если мы в моем кубике сделаем не 5, а 6 измерений - тогда объем данных будет не 10 миллиардов, а 1000 миллиардов (триллион). Если в кубе будет 10 измерений, и в каждом не по 100, а побольше мемберов, то плоское представление такого куба не поместится ни на одно средство хранения данных - или если поместится, то будет стоить очень дорого. При этом если кубик лежит в среде MOLAP, он не требует серьезного железа.
Таким образом, Ваши рассуждения про оптимизаторы современных СУБД - это в данном случае - научные мысли вслух, не имеющие ничего общего с реальной жизнью.

Можно хранить их отдельно, и соединять в запросах. Можно сделать несколько таблиц, которые будут хранить измерения и одну таблицу фактов и через join и union можно получить похожую информацию что и в кубе. Конечно это будет медленее чем куб (там как он хранит ответы) но это реально и не так уж ресурсоемко. Весь вопрос в оптимальном хранении информации, не в одну таблицу а разряженно.

Jurii2 Константин Лисянский:

насколько я понимаю, дискуссия уже идёт не на тему "возможно ли реализовать сложный алгоритм разнесения с помощью SQL". Выяснили, что возможно. Теперь идёт вопрос о скорости.

Вы не правы. Если провести параллель, то планировать ресурсы предприятия можно без ERP-системы, достаточно лишь иметь карандаш и бумагу. Расчеты на бумаге провести будет конечно очень трудоемко, но это другой вопрос - главное что можно все точно посчитать :)
Я не считаю жизнеспособным решение этой задачи на SQL. Или Вы готовы при добавлении каждого нового аналитического разреза, при увеличении количества записей на порядки (10 миллиардов -> триллион -> сто триллионов...) расширять вычислительную мощность и дисковое пространство сервера? Таких серверов то не бывает...
К тому же, решение на SQL требует добавления нового показателя при появлении каждого нового разреза (базы распределения), что мягко говоря не очень удобно.

Таким образом, поскольку вопрос о возможностях SQL решён в положительную сторону

Вы хотите притянуть за уши неработающее решение...

Своими рассуждениями по поводу SQL Вы очень сильно смешите публику.

Видимо Вы слишком много начитались классики по хранилищам данных, и немного отстали от жизни. А такие скромные специалисты как я - вовсю создают хранилища и витрины данных, которые реально работают :)

Еще раз повторю что для каждого аналитического разреза не надо увеличивать кол-во записей, хранить данные можно разряженно, и если есть задача то можно и ответы хранить в СУБД и использовать все фитчи для быстрого извлечения их оттуда. То что данные лежат в файлах txt или еще лучше Excel это вообще немыслемо, какой это промышленный стандарт??? Где оптимазация поиска по txt может кто то знает как построить индекс по txt файлу????
Что за бред я вообще не понимаю, что Cognos это решение для владельца палатки на Митинском рынке где в день не более 1000 покупок??? А если сеть где покупки могут достига 1 000 000 и какой Excel вместит в себя столько записей??? И txt вы устанете читать который содержет столько инфо.

И что хранилище данных у вас в txt файлах??? и источники данных для кубов тоже файлы??? вообще приплыли......

Jurii
В проекте для одной из серьезных гос. структур в качестве ХД/источника данных для кубов выступал текстовый файл размером около 5 гигабайт.

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

Мда... и вот пришел когнос и текстовые файлы начили приносить пользу аналитикам. Мда....
Без коментариев.....