Константин ЛисянскийЕщё один

Пожалуйста, ознакомпьтесь с правилами форума на предмет оформления сообщений.

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

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

JuriiНо не все OLAP-сервера умеют делать кубы на основе более чем одной таблицы фактов... Например, Cognos PowerPlay позволяет это сделать, MS Analysis Services - не позволяет.

Смотря что называть кубом. Если рассматривать виртуальный куб AS2K, то за ним может стоять несколько таблиц фактов.

А начиная с AS2K5 и физический куб можеи базироваться на нескольких таблицах фактов. Кстати в AS2K5 уже нет деления на виртуальные и физические кубы.

Константин Лисянский JuriiТакую вьюху невозможно написать, поскольку у таблиц фактов - разная гранулярность, и в реляционной таблице невозможно разнести агрегированные значения плана по детальным записям факта. Подобная разноска возможна только при многомерном OLAp-моделировании.

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

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

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

Андрей Прохоров backfireПравильно ли я представляю, что в случае соединения 2 таблиц с разной гранулярностью одна из них должна быть аггрегрована для приведения гранулярности. Какие еще возможности еще есть? Где про это можно почитать? Кимбал?
Я встречался с такими ситуациями:
1) Действительно агрегация данных из таблицы с бОльшей гранулярностью до уровня таблицы с меньшей гранулярностью
2) Дублирование данных из таблицы с большей гранулярностью до уровня таблицы с меньшей гранулярностью. Например, цены заданы на уровне месяца и просто дублируются до уровня отдельных продаж за этот месяц.
3) Преобразование показателя с большей гранулярностью до меньшего уровня. Например, есть затраты на доставку на уровне заказа, нужно распределить их до уровня отдельных товаров. Затраты можно распределить пропорционально весу или количеству единиц товара. Вариантов может быть много.

Читал я об этом в документации по MicroStrategy, там использование фактов с разной гранулярностью называется fact extension.

Да видно что то с утра был сонный и не сообразил.
Однако юзал я уже все эти 3 вида :-), и давно все это было, что сходу у меня даже ассоциации на эту тему не возникли.

JuriiЯ на 99.9% уверен, что с помощью SQL-запроса (вьюшки) такую задачу решить нельзя (это не просто очень сложно - а скорее - невозможно).

Если запросы строить, елозя мышем по столу, то вы скорее всего правы - невозможно, а если головой думать и руками писать, то все возможно.

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


Юра, всегда есть люди, кто готов и стоит даже в очереди чтобы платить за езду на Mазерати ручной сборки, хотя большинство ездит на Меринах конвейрных.

Обычно спецы экстракласса уходят сами.... Работодатель в таком случае само виноват, что не смог удержать.