Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Измерения в BO
|
|||
|---|---|---|---|
|
#18+
Hello! Оптовая компания продает овощи. Совокупные затраты компании делятся на 10 статей: себестоимость товара, транспортные затраты, налоги и т.д. Затраты разнесены аналитиками между всеми товарами (каждый товар "оттягивает" на себя различную величину затрат по каждой статье) В БД есть две таблицы: 1) ПРОДАЖИ: Овощ, Выручка 2) ЗАТРАТЫ: Овощ, СтатьяЗатрат, ВеличинаЗатрат 1) Помидоры 10000 Картофель 20000 Морковь 9000 ... и т.д. 2) Помидоры Налоги 100 Помидоры Транспорт 200 Помидоры Зарплата 130 Морквоь Налоги 100 Морковь Транспорт 200 ... и т.д. В юниверсе на основе таблиц создано 2 класса: ПРОДАЖИ, ЗАТРАТЫ. Таблицы "Продажи" и "Затраты" связаны по полю "Овощ". Фактически, "Продажи" являются мастером по отношению к "Затраты" ПРОДАЖИ включают переменные "Овощ" (измерение) и "Выручка" (значение) ЗАТРАТЫ включают "Овощ" (измерение), СтатьяЗатрат (измерение) и ВеличинаЗатрат (значение) Репорт, созданный на основе юниверса, содержит переменные "Овощ", "Выручка", "СтатьяЗатрат", "ВеличинаЗатрат". Теперь, собственно, проблема: При вырезании измерения "СтатьяЗатрат" идет повторное суммирование по переменной "Выручка". Каким образом реорганизовать юниверс и/или отчет, чтобы при вырезании СтатьяЗатрат Выручка оставалась бы неизменной для каждого значения "Овощ" ? Спасибо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.10.2003, 10:17 |
|
||
|
Измерения в BO
|
|||
|---|---|---|---|
|
#18+
На мой взгляд, для таких задач нужно пользоваться OLAP-продуктами (консолидировать продажи и затраты в одном кубе), а не продуктами для репортинга (Query & Reporting). SQL-запросы на такой анализ не заточены... Если будете выбирать OLAP-продукт - пишите мне запрос через сайт http://cognos.narod.ru , и я расскажу об отраслевых OLAP-решениях для оптовой торговли на примере реального опыта внедрения в Липецке. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.10.2003, 10:43 |
|
||
|
Измерения в BO
|
|||
|---|---|---|---|
|
#18+
Э-э-э... А разве BusinessObjects - не OLAP-продукт ? ;-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.10.2003, 10:47 |
|
||
|
Измерения в BO
|
|||
|---|---|---|---|
|
#18+
Э-э-э... А разве BusinessObjects - не OLAP-продукт ? ;-) По большому счету, BusinessObjects - это хороший (и соответственно недешевый) генератор отчетов корпоративного уровня. Он может выступать как OLAP-клиент для кубов, созданных в СТОРОННИХ OLAP-ПРОДУКТАХ. Ну а полноценные кубы в BusinessObjects создать нельзя (для Вашей задачи в частности нужно уметь инкрементально обновлять кубы, чтобы консолидировать данные по продажам и затратам - а этого BusinessObjects не умеет). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.10.2003, 11:04 |
|
||
|
Измерения в BO
|
|||
|---|---|---|---|
|
#18+
Ясно, однако выбора нет - есть только BO. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.10.2003, 11:11 |
|
||
|
Измерения в BO
|
|||
|---|---|---|---|
|
#18+
Ясно, однако выбора нет - есть только BO. Это серьезный аргумент... :) Хотя я знаю компании, которые закупали несколько аналитических продуктов. Так что в Вашей ситуации я бы прикупил OLAP-сервер, благо сейчас существуют очень дешевые OLAP-сервера. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.10.2003, 11:19 |
|
||
|
|

start [/forum/topic.php?fid=49&msg=32308390&tid=1873047]: |
0ms |
get settings: |
5ms |
get forum list: |
11ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
129ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
28ms |
get tp. blocked users: |
1ms |
| others: | 244ms |
| total: | 432ms |

| 0 / 0 |
