OLAP + 1С #223594

Всем привет! Поиском смотрел, есть темы про OLAP, но ответа не нашел. Вопрос, к практикам, какое решение набилее эффективно? Чей продукт? Каков функционал и цена соответственно. У ПиБи есть OLAP и там все просто и наглядно, НО там свой сервер/клиент и Проклэрити уже не прекрутишь :) У Контура - тоже свои изобретения на этот счет... Руки тянутся к Microsoftу дабы Ексель и вообще прочих клиентов полно. Но есть вопрос с переносом данных 1С в базу OLAP. Чем это делать и как? Кустарить запросы непосредственно к базе - специалистов нет и желания. Единственное, что нашел - это Adelit:ETL которая снимает эту рутину вроде... Что можно ещё порекомендовать? Спасибо!

Может быть проще. Если 1СV7 уже живет под MS SQL форматом то и остановиться на уже имеющемся решении OLAP MSSQL и воспользоваться аналитическим менеджером для создания базы данных OLAP.

Руки в правильном направлении тянутся. А вообще тут почитай: Много полезной инфы.

to rsv: дело в том, что для этого нужно занать структуру таблиц и грамотно их использовать. Т.е. пользоваться недокументированными фишками, что черевато во первых, а во вторых неудобна... to fisher: почитаю счаз, спасиб

Конечно надо знать. И эти знания не лишние. С учетом того что SQL сервер под 1С кой стоит как правило нелицензионный и за 200 рублей ентерпрайз :) грех не воспользоваться функционалом OLAP.

так канешна им и нужно воспользоваться - я тоже за MS AS! Но сделать куб как при этом? Кустарить запросы к этим жутким таблицам 1С? В наш век, когда космические корабли бороздят... Грустна :(

2 В Киеве Доцент вроде внедрением OLAP-систем под ключ занимался (в своё время прошел тренинг у Иванова). У него и инструментарий наработанный был, позволяющий моделировать кубы непосредственно из 1С, не задумываясь о структуре баз. Если требуются относительно несложные решения, то не проблема это и самому потянуть (1С++ здорово облегчает написание запросов "к этим жутким таблицам 1С"). Если лень - то можно купить/заказать готовое решение (как правило, они продаются вместе с внедрением и стоят недёшево). Фишка в том, что нет ни одного полностью законченного решения, средствами которого можно в будущем настраивать связку 1С+OLAP, как захочется - только относительно простые варианты (это чтобы не питать иллюзий, что купил коробку и дело в шляпе). Так что все-таки нужно иметь либо своего спеца, который в теме, либо приглашать спеца на доработки (что предпочтительней, если спец хороший, но дороже). Тема вообще очень интересная и стратегий связи с 1С довольно много со своими плюсами/минусами. Тонкостей много. Именно поэтому в основном на этом рынке продаются скорее внедрения, чем коробки.

ну вот я посмотрел Adelite:ETL Вроде как раз то, что дохтор прописал. Делается Нормальная база и затем уже вперед MS AS... В 1С данные, которые нам нужны для ОЛАПа будем собирать в новые регистры если не хватает типовых или по документам геморойно. Какие тут подводные камни могут быть? Никаких "брать данные из разных источников" у нас нет... Максимум несколько баз и то в качестве пофантазировать...

+ Простейший рецепт 1С+OLAP от Иванова: в качестве входных таблиц для OLAP используются вьюшки на таблицы 1С. И полный репроцессинг кубов с нужной периодичностью (скажем, ночью). Даже для весьма больших объемов данных репроцессинг делается относительно быстро и это решение подходит довольно часто. Главный плюс - простота. Никаких выгрузок/загрузок данных, отслеживания изменений, триггеров и т.п. 2 Подводные камни есть, поищи по архивам форумов...

а вьюшки это что такое?

2 view - механизм MS SQL, позволяющий представлять запрос в виде отдельной таблицы, к которой можно обращаться из других запросов и т.д. Т.е. можно создать таблицу "Продажи" (на самом деле - view), в которой будут человеческие поля - "Дата, Клиент, Товар, Количество, Сумма" и подсунуть её в качестве таблицы фактов OLAPу. А на самом деле данные будут браться из "этих жутких таблиц 1С"

спасибо, я так и думал... короче это определенный view на Жуткие таблицы под определенным углом. При этом я так понял они динамические т.е. при изменении данных Жути, меняются они и в Отображении...

2 Почти так. По сути, при обращении к Отображению идет переадресация на данные Жути.

Спасибо! Будем думать дальше... пока Adelite:ETL причем за 250$ вне конкуренции. Альтерантивы пока не вижу, но ещё грядут демонстрации... Посмотрим :) Спасибо!

2 На самом деле, как я уже говорил, тема очень интересная. Если view будет содержать достаточно сложные запросы, то выборка данных может занимать значительное время. Но в MS SQL 2000 появились indexed view, которые фактически представляют то, что вы написали в - динамические таблицы, меняющиеся при изменении данных источника. Их использование позволяет значительно сократить время выборки в сложных случаях. Только прикрутить их к 1С еще надо постараться... С их использованием возможно построение систем Real-time OLAP с нулевым уровнем агрегации (это вообще отдельная тема). Т.е. вообще без выгрузок/загрузок и процессингов. В любую секунду видим актуальные данные. Плата - увеличение времени выборки (нивелирование основного преимущества OLAP). Но в конкретных случаях можно достичь оптимального баланса.

еще Ростерминал как-то показывал свою разработку OnVision. тут можно почитать:

Вы читали по вышеуказанной ссылке? Иванов, понятно, там рекламирует свое решение, но и об Adelite:ETL можно кое-какие данные почерпнуть.

+ Я имею в виду статью "Сравнительная таблица OLAP-решений для 1С:Предприятия"

fisher правильно говорит - нюансов много и коробочный продукт вряд-ли решит все проблемы. ИМХО лучше иметь под рукой специалиста (своего или приглашенного).

+Бояться "Жутких таблиц 1c" - в OLAP не ходить. пару OLAP-отчетов можно сделать на коленке типа как тут: Сделать запросы к базам 1cv7 более читаемыми можно при помощи метапарсера из 1С++

в Ростерминале нет никаких решений по превращению данных 1С в MS AS. OnVision есть OLAP клиент не более... to fisher: может в реалтайме и можно так сделать, но как же быть с процессиногм самого куба? На сколько я понимаю его нужно пересчитывать при каждом изменении данных всерно и реального онлайна для пользователей не получится всерно...

полезность real-time OLAP ИМХО сомнительная. Как-правило цель построения OLAP-отчетности это получить информацию для анализа. И отставание информации в кубе от оперативных данных скажем на сутки - некритично. В крайнем случае можно предусмотреть репроцессинг куба по запросу пользователя.

2 При технологии real-time OLAP процессинг куба отсутствует вообще (агрегаты не рассчитываются - нулевой уровень агрегации). Есть возможность в качестве агрегатов использовать indexed view для ускорения выборки. Но я про RT OLAP упомянул чисто для проформы (типа есть такая технология). Там есть свои сложности и использование её чисто для аналитических целей весьма сомнительно с точки зрения целесообразности. Но технология, тем не менее, имеет право на жизнь. Ведь в этом случае OLAP можно использовать не только как аналитический инструмент, но и как инструмент оперативной отчетности. Очень заманчивая штука. Но оправданная только в специальных случаях.

Роберт Вьейра SQL Server 2000. Том 2 глава 25 .Аналитические службы. Вполне доступно на русском(родном) языке и пошагово. И с картинками. :) Но только это не освобождает от знания структуры таблиц семерки.

Есть продукт компании cognos. С базами MS SQL нормально работает.

На самом деле для OLAP лучше держать отдельную базу, куда сливать данные. Всякие вьюшки прекращают жить при очередном обрезании базы и т.п. манипуляциях. Кроме того такой способ позволяет консолидировать данные из разных баз. Ты бы еще выложил тут стоимость этого добра. Чтобы у народа иллюзий не возникало :))