Доброго времени суток!
Уже разочаровался в поисках решения, поэтому обращаюсь к специалистам с таким вопросом:
в хранилище есть таблица остатков в разряженном виде (из-за количества записей около 100 миллионов записей в свернутом виде такой способ хранения является единственным воплотимым в хранилище). Столбцы таблицы
n_daily_rests :
Shop, Artikul, DateBegin, DateEnd, Amount
Как пример, если по одному магазину по определенному артикулу в течение трех месяцев не было продаж и остаток оставался одинаковым, то в этой таблице будет всего одна строчка (а не 92 штуки на каждый день):
1.
2.
Shop Artikul DateBegin DateEnd Amount
Магазин1 Телевизор 01 . 01 . 2006 01 . 03 . 2006 15
Итак, теперь у меня стоит задача предоставить доступ к этой таблице через Microstrategy. Как известно, перед добавлением такой таблицы в MSTR, необходимо ее
развернуть . Конечно, можно сделать простой
View , но тогда, по словам создателей хранилища, если количество желающих обратиться к такой
View по всем магазинам за весь период превысит одного пользователя, сервер зависнет.
Со стороны создателей хранилища были предложены два варианта решения, однако как реализовать из в Microstrategy, мне пока не понятно:
Вариант 1. Параметризованные View. В хранилище создается параметризованная View
V_MSTR_OST . Перед тем, как обратиться к
V_MSTR_OST , Microstrategy должна запустить строку инициализации этой
View по установленному пользователем фильтру.
Например, если пользователь выбрал в фильтре отчета или через Promt два магазина
Shop IN (43,44) , а так же выбрал фильтр по времени
с 02.10.2005 по 16.10.2005 , то перед обращением к
V_MSTR_OST должен выполниться следующий код:
1.
2.
exec mstr_ost_week.set_param(date_beg_in => TO_DATE('02.10.2005', 'dd.mm.yyyy'),
date_end_in => TO_DATE('16.10.2005', 'dd.mm.yyyy'),
type_calendar_in => 1 , shop_in => '43,44');
А потом уже смело можно обращаться к
V_MSTR_OST , там лежат уже только необходимые данные:
1.
2.
3.
4.
5.
6.
7.
8.
Shop Artikul Date Amount
43 Телевизор1 02 . 10 . 2005 15
43 Телевизор1 03 . 10 . 2005 8
...
44 Телевизор5 10 . 10 . 2005 84
44 Телевизор5 11 . 10 . 2005 83
44 Телевизор5 11 . 10 . 2005 82
...
Производим прямое обращение к таблице остатков, пересекая её с сгенерированным по фильтру пользователя календарем:
1.
2.
3.
4.
5.
6.
7.
8.
9.
SELECT c.date_, ost.art, ost.shop, ost.amount
FROM n_daily_rests ost,
-- создаем таблицу-календарь для ускорения выполнения запроса
-- и просто пересекаем таблицу остатков n_daily_rests c этим календарем
(SELECT date_ FROM
TABLE (tm_util.calendar (TO_DATE ('02.10.2005','dd.mm.yyyy'),
TO_DATE ('16.10.2005', 'dd.mm.yyyy'), 1 ) ) ) c
WHERE SIGN(ost.amount) = 1 -- отрезаем нулевые остатки
AND ost.shop IN ( 47 , 48 )
AND (c.date_ >= ost.datebegin AND c.date_ < ost.dateend)
В этом случае сложность состоит в передаче в этот запрос фильтра по времени для генерации таблицы-календаря.
Итак вопрос, сталкивался кто-нибудь из Вас с такой задачей, и какие здесь могут быть пути реализации доступа к остаткам? Принимаются любые идеи. Заранее большое спасибо.
P.S. Все решения по созданию такой сложной структуры в ИХ примались исходя из того, что в таблице N_DAILY_RESTS порядка 100 миллионов записей. Поэтому для оптимизации запросов были придуманы различные методы ускорения работы, такие как вспомогательные календари и прочее.
