Как то забыл поделиться проблемами использования OLAP в компании с бизнесом дистрибуции. Одна из наиболее существенных (кроме большой номенклатуры и клиентов) - это необходимость "удовлетворять" как клиентов так и поставщиков. О поставщиках и поговорим.
Каждый из них, как известно, имеет свою классификацию номенклатур и клиентской базы. Допустим только 5 из 90 наших постащиков требуют предоставление отчетности в своей класификации номенклатур и клиентской базы (от 2-х до 5 уровневые иерархии). Вы скажете, что для этого OLAP не нужен, а нужны обычная система отчетности ? - тогда Вы не знаете, что эти поставщики имеют своих менеджеров, которые обитают где-то рядом и один раз заметив OLAP тут же требуют его, и боссы ведуться, потому что это обеспечивает хороший гуддвил.
На банальном уровне уровне остатков и продаж это означает создание 3*6 кубов (в один набор нереально вместить - это будет даже не взрыв данных, а разорванный на волоски хомячек).
Таким образом получаем 18 кубов одного и тогоже, но с разными классификациями. Поддерживать это нереально, я так думаю. По крайней мере в данный момент поддержка 1 лишнего куба раза в полтора увеличивает нагрузку. Проблемы сбора и хранения иерархий пока обойдем.

Что думаете ?

To Quark: чесно говоря, я не понял как ETL приложение может помочь.. Ведь исходные витрины теже самые, а как правильно подозревает backfire надо:
1) Смотреть через разные иерархии на нижнем уровне, которые имеют одинаковые ID
2) Делать срезы для отсечения данных одного производителя (это можно делать виртуальными кубами)

To Jurii: Может быть, но нам туда не до.

Я, естественно, пробовал сделать куб с 2 иерархиями (наша и P&G), увеличение процессинга куба в 3 раза (на 80%). Размер куба тоже примерно так увеличился. А я как то писал, что не могу делать это ночью, а значит не подходит так по времени. Причем, так как у поставщика кол-во номенклатур меньше, чем в витрине, то используется outer join а не inner, что тоже не добавляет производительности..

Вообщем пока 2 отдельных куба держу ..

to Bear_ : Идея интересная !. Правда решает проблему на половину. Действительно можно сделать въюху с UNION ALL и заранее ограниченным максимальным кол-вом уровней (в столбцах). Много иехархий (естественно не parent-child), ключь иерархии. На уровне схемы куба только одна въюха связана с табличкой факта ( сделать как inner join - все равно необходимо генерировать отсутсвующие уровни для иерархии чтобы циФры не пропадали).
В смысле чтобы ключ измерения брался из факта. А не продублируются ? ведь ProductID много раз повторяется !

Иерархии с фильтиром по своему ключу из въюхи лепим.
Попробую обязательно !. Вот только кол-во агрегатов не уменьшится ;-(
Спасибо !

Опция "Depends on Dimension" на мой взгляд сдесь не причем. Все иерархии независимы.

to Eldar: Насчет Excel наверно шутка ? - там 64 к записей масимум, а 11 млн слабо ?