[OLAP] - на основании чего строить кубы

[Андре]

Добрый день.

Вопрос к тем, кто использует Olap и Аксапту.

Есть два подхода к формированию кубов:

1) строить их на основании базы данных Аксапты
2) построить отдельную БД - хранилище данных, перегонять туда данные с помощью dts и уже на основании этого хранилища формировать кубы.

Насчет первого способа:
а) периодически не проходит процессинг кубов - выясняется что кто-то удалил запись в таблице измерений, хотя ссылка в таблице фактов осталась
б) структура таблиц аксапты все-таки не оптимальна для построения olap кубов. Хороший пример - хранение дат не в виде отдельного измерения, а прямо в таблице фактов.

В связи с этим рассматриваю второй вариант.

Что сразу бросается в глаза - кубы будут строиться не из Аксапты, а скажем, с помощью Analysis Services Processing Task в DTS. Не то, чтобы смертельно - кубы в Аксапте я подцеплю, но, например, label в enum-ах придется ручками прописывать в dts пакетах.

Вопроса 2:

1) Какие есть еще подводные камни во втором варианте ?
2) Каким способом пользуетесь Вы ?

[Vadik]

Zitat:

Изначально опубликовано Андре
а) периодически не проходит процессинг кубов - выясняется что кто-то удалил запись в таблице измерений, хотя ссылка в таблице фактов осталась

так это проблема не OLAP-а, а скорее организационно - программисткая

то, что элементы справочника удаляются без надлежащей проверки, где они уже успели поиспользоваться - это раз
то, что не все DeleteActions построены - это два

Zitat:

Изначально опубликовано Андре
б) структура таблиц аксапты все-таки не оптимальна для построения olap кубов. Хороший пример - хранение дат не в виде отдельного измерения, а прямо в таблице фактов.

вот это не понял - а как лучше?

[Андре]

Zitat:

так это проблема не OLAP-а, а скорее организационно - программисткая

Согласен. Но с учетом того, что это происходит в стандартном функционале, я сталкиваюсь с необходимостью поиска таких мест и их правкой.
А как говорит mazzy, "избегайте программирования".

Zitat:

вот это не понял - а как лучше?

Делать отдельную табличку - измерение. И связывать ее с таблицой фактов. Пример посмотреть стандартной базу FoodMart.
Избегая излишнего цитирования просто приведу одну из ссылок, в которых описываются преимущества альтернативного варианта:
http://www.sqljunkies.com/article/D1...D60951395.scuk

p.s. К сожалению эта ссылка не работает (надеюсь временно), а других у меня не осталось.

[LCh]

На нашем проекте все OLAP-кубы построены на Analysis Services.

Опыт показал, что не смотря на неудобство с фильтрацией компаний и самописных текстовых полях вместо enum, в AS и SQL Server гораздо больше возможностей. Начиная от самого Т-SQL и заканчивая репликацией.

[Андре]

Zitat:

На нашем проекте все OLAP-кубы построены на Analysis Services.......

Спасибо за ответ, но я так и нашел в нем ответа на свой вопрос:

Zitat:

Есть два подхода к формированию кубов:

1) строить их на основании базы данных Аксапты
2) построить отдельную БД - хранилище данных, перегонять туда данные с помощью dts и уже на основании этого хранилища формировать кубы.

.....

Каким способом пользуетесь Вы ?

Речь шла не о том, чем мы пользуемся AS или Аксаптой, которая опять же работает с AS. А о том, что является хранилищем данных для AS - база данных Аксапты или отдельная база данных.

[Vadik]

Zitat:

Изначально опубликовано Андре
Согласен. Но с учетом того, что это происходит в стандартном функционале, я сталкиваюсь с необходимостью поиска таких мест и их правкой.
А как говорит mazzy, "избегайте программирования".

Ага - в аксапте не программируем, зато программируем в DTS.. Причем в DTS программировать больше и лично мне - неудобнее. Хотя - дело привычки

И все равно это не проблема OLAP-а. Ну научимся мы при переносе DTS-ом менять название удаленного элемента справочника на "элемент удален". Станет лучше, если теперь куб обработается, но будет содержать обороты по счету "счет удален" или задолженность перед поставщиком "поставщик удален"?

Хочется программировать - пишите job-ы, которые такие ситуации быстро проверяют, не давайте всем удалять что ни попадя

Zitat:

Избегая излишнего цитирования просто приведу одну из ссылок, в которых описываются преимущества альтернативного варианта:http://www.sqljunkies.com/article/D1...D60951395.scuk
p.s. К сожалению эта ссылка не работает (надеюсь временно), а других у меня не осталось.

Заработала. Занятная ссылка. Из вкусностей вижу только возможность навешивать member properties на даты. Все остальное - технологии, до которых никому кроме разработчика дела нет. А то, что среднестатистический клиент потеряет возможность самостоятельно куб настроить без программирования - это факт

[Ned]

Рискну вклиниться
1. Кубы обычно строятся на view, а не на таблицах.
2. Подготавливать промежуточные данные (с помощью снэпшотов Оракла или с помощью временных таблиц Майкрософтовского сиквела) имеет смысл для того, чтобы не блокировать пользователей при частом обновлении кубов. Вопрос в том, как часто нужно обновление. Если один раз в неделю и в выходные производится меньше операций в базе, то нет проблем. А если каждые десять минут по таблице InventTrans, то тут уже и инкрементный апдейт кубов не спасёт - надо подкачивать данные в промежуточную таблицу.

Не согласны?

[Ned]

Zitat:

А то, что среднестатистический клиент потеряет возможность самостоятельно куб настроить без программирования - это факт

Кто имеется в виду под клиентом? Конечный пользователь? Если "да", то зачем ему настраивать куб? Пусть выберет себе нужные поля и вперёд.

[Dubinski Serguei]

тоже рискну свои пять копеек вставить

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

Опять же, хранилище - это статистика. Там ВСЕ данные, когда либо появившиеся за время работы.

Еще один аргумент. Для быстроты работы ОЛАП-куба его лучше строить на денормализованных данных (содержащих избыточные сведения), тогда как в оперативной базе данные наоборот как можно больше нормализуются.

А если нужно каждые 15 минут куб обновлять - наверное куб это не очень верное решение для такой задачи. или используйте ROLAP.

[Vadik]

Zitat:

Кубы обычно строятся на view, а не на таблицах

Что значит "обычно"? Это какой-то best practice? Или имеется в виду то, что view строит аксапта? Так это издержки хранения в одной таблице данных нескольких компаний

Zitat:

Вопрос в том, как часто нужно обновление. Если один раз в неделю и в выходные производится меньше операций в базе, то нет проблем. А если каждые десять минут по таблице InventTrans, то тут уже и инкрементный апдейт кубов не спасёт - надо подкачивать данные в промежуточную таблицу.
Не согласны?

Cогласен с тем, что если в постановке задачи сказано, что каждые десять минут требуется перестраивать куб по InventTrans, задача поставлена неправильно

OLAP - он все-таки не для оперативного анализа, хоть Online в аббревиатуре присутствует

[Андре]

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

Прокомментирую некоторые замечания, хотя в общем я с ними согласен:

Zitat:

Ага - в аксапте не программируем, зато программируем в DTS. Причем в DTS программировать больше и лично мне - неудобнее. Хотя - дело привычки.

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

Zitat:

И все равно это не проблема OLAP-а.

Это не проблема OLAP. Это проблема Data Warehousing - одной из задач которого является валидация данных.

Кроме того, согласен с Сергеем:

Zitat:

я так понял, что преимущество стороннего хранилища данных в том, что туда данные можно переносить из любой базы

Очень удобно, когда данные нужно анализировать не только из Аксапты, но и из ряда программ, уже работающих на предприятии.

[Recoilme]

Hi

Zitat:

Изначально опубликовано Андре
Добрый день.

Насчет первого способа:
а) периодически не проходит процессинг кубов - выясняется что кто-то удалил запись в таблице измерений, хотя ссылка в таблице фактов осталась
б) структура таблиц аксапты все-таки не оптимальна для построения olap кубов. Хороший пример - хранение дат не в виде отдельного измерения, а прямо в таблице фактов.

Изначально использовали способ 2. Недостаток а) способа 1 в равной степени присущ способу 2. Недостаток б) легко устраняется построением денормализованных вьюх и темпов таблиц для корректного отображения Enumов

Zitat:

Вопроса 2:

1) Какие есть еще подводные камни во втором варианте ?
2) Каким способом пользуетесь Вы ?

1) на мой взгляд затрудняется поиск причины неотпроцешивания куба, т.к. добавлено промежуточное звено.
2) В конечном итоге начали плавный переход на способ 1 (HOLAP) постоянные гемморои с поиском багов в ДТС всех просто достали + Сваять вьюху и прикрутить к ней HOLAP - день, грамотно напрограммить ДТС с поледующей отладкой куба- дня 3
А вообще лучше попробавать самому оба и сравнить

Успехов

[Андре]

Сегодня случайно нашел обсуждение похожей темы, но уже без привязки к Аксапте:

http://www.sql.ru/forum/actualthread.aspx?tid=112945