Увязать 1С и ОЛАП #6996

subj собственно. Где и что можно почитать по этому поводу? Может кто уже занимался? Что одскажет о граблях?

Ни у кого ничего нормального еще не получилось. Вместо кубиков - только прямоугольники.

Но можем прям здесь придумать высокоэффективную Olap-подобную систему. Вот у тебя какие мысли насчет реализации? Как ты это себе представляешь?

Ну ни как еще не представляю. Вижу всю эту ерунду только 2 неделю. В голове - хаос. Единственное что понимаю - неэффективность многих вещей в 1С (типовых конфигурациях торговли). На есть много умных мыслей. Но как их привязать к моей ситуации - не понимаю. Тут пытаюсь изобразить куб для финотчетности (кто, сколько, когда, какого товара, каким из сотрудников) - ни фига не получается. Уперся в MDX для просроченного долга и дальше никуда. А представляю это себе примерно следующим образом - 1. Выгрузка данных/преобразование к нужным форматам  (думаю неэффективно использовать 36-ричное представление (строки долго обрабатывать)) 2. Фильтрация/устаовление значений по умолчанию 3. Собственно загрузка в куб/кубы (отражение финсостояния, склад, затраты)

3. Может в SQL создать большую многоуровневую таблицу (внешнюю по отношению к 1с), во время проведения доков - производить движения в этой внешней таблице. Потом, используя ее иеархичность, строить по ней всякие многоуровневые отчеты.

То ест использовать INSTEAD OF тригерры. Для 1c на SQL это смерть. Рычаги. И кроме этого надо помнить обовсем при написании проведения/перепроведения документа. А уж если рискнешь поменять структуру регистра - абзац Да и не в этом проблема если честно. Для меня сейчас более важно вообще понять что есть ОЛАП. Какая польза моему предприятию от использования этой технологии. Насколько мои данные готовы к data mining. Вот тут есть люди с гордым титулом  "Инженеры знаний". Оказывается есть и другое назначение у них, не только ветки сортировать

5. Ты не совсем правильно понял мою мысль. OLAP - предполагает получение любой аналитики в любых разрезах. Реализовать это на 1с достаточно сложно. Просто можно использовать внешнюю SQL таблицу, средствами ADO записывать в нее данные и извлекать. Универсальные процедуры и функции для одной единственной таблицы описать не сложно.

Мне кажется более просто делать выгрузку. Не заморачиваться с выяснением внутренних идов на ходу а ночью тихонечко пересчитать все как надо. Другой вопрос что не представляю что пересчитывать. Да и опять же вопрос совметимости выгрузки при изменении конфигурации. Короче куда ни кинь ...

7. То же самое тогда можно получить и сложными отчетами с каким-нибудь самоформирующимся составным запросом. В случае с SQL таблицей - возможно получение аналитик в реальном времени.

В случае 1С я сильно сомневаюсь вообще в возможностях работы в реальном времени. ROLAP убьет базу. MOLAP  - производительность. Опять же регистры эти убогие. Все же мне кажется что нужно просто как-то умудриться описать бизнес процесс предприятия не в термнах конфигурации 1С, а каким-то более общим образом. Вот по этому вопросу бы что-то найти почитать

9. Не обращаясь к таблицам 1с, а просто создай внешнюю таблицу (не в составе конфигурации) средствами SQL. Типа XBase, только для SQL.

Не обращаясь к 1С потеряю справочники/документы Стоимость запроса к серверу из ADO  все же ощутима, и использовать эту фишку при проведении/перепроведении/создании и т.д. не хочу. Но коль пошла такая пьянка, то вопрос по существу В таблице фактов есть поля 1. ДатаОперации (день когда прошла операция) 2. ОплатитьДо (день после котрого оплата считается просроченной) 3. Сумма (сумма денег) 4. ЭтоОплата (1 если оплата, 0 если закуп) В итоге надо получить 1. сумму просроченного/непросроченного долга на дату 2. Количество дней просрочки на дату Использую MS AS В качестве клиента - Excel Вопрос - как построить вычисляемый мембер, для 1 и 2 На самом деле даже немного проще - как сравнить даты? Когда пишу datediff("d",[ДатаОперации].currentMember,[Оплатитьдо].currentMember) для выснения сколько дней в прошло просрочке - выдает #ERR Почему?

11. Не потеряешь - ведь можешь ввести сквозную кодировку всех нужных объектом метаданных - типа как в MOD, только попроще.

+12. Поиск 1с объектов попавших в выборку искать средствами 1с.

Дату лучше изначально записывать в числовом представлении: 20040814(можно добавить и время, тогда так 20040814015247)

Не понял, если честно. Можно на примере и поподробнее? Это как? А чем плох datetime у SQL?

15. 12. - у справочников - единый реквизит IDD, для доков не нужен - достаточно записывать числовое представление вида, номер и дату. То есть имея эти идентификаторы - всегда найдешь нужный 1с объект. 13. Допустим запрос OLAP вернул тебе выборку из ста элементов, где значения элементов - это IDD значения справочников + набор идентификаторов дока. Пройдясь по рекордсету - формируешь ТЗ, где стороковое представление элементов заменяешь на представление элементов 1с (типа Спр.НайтиПоРеквизту("IDD",ЗначениеРекордсета);

Т.е. В качестве клиента для ОЛАП использовать 1С? Есть ли в этом смысл?

17. Совершенно верно. Смысл наверное есть, поскольку не привязан к сторонним разработкам. ADO- в составе WIn, SQL сервер можно вязть и бесплатный (MySQL), а 1с- просто удобная среда для быстрого программирования.

Может по что подскажешь? Если честно, то при таких раскладах лучше 2С. Удобная (правда временами глючная) среда. Больше возможностей. Ни к чему не привязан. И бесплатно.

19. Посмотри ветку (насчет 11) "Посоветуйте структуру регистров". Что касается 2с - я юзаю в качестве эксперимента, но пока не могу уверенно судить о возможности практического применения.

Вопрос если честно не в реализации на 1С. Не буду менять конфу. Вопрос в MDX запросе. Где хотя бы про это написано?

21. Я не программист, термины многие не знаю. Что значит MDX? Если мне будет понятен термин - возможно помогу с решением.

MDX - язык запросов в ОЛАП. Позволяет формировать выходной рекордсет так, так тебе нужно (накладывать условия, пересечения, объединения, выбирать нужные множества) Не похож на SQL

23. Я лично вижу реализацию только на SQL, когда иеархичность (система координат куба) достигается за счет сквозного многоуровнего классификатора событий (каждое событие вдобавок имеет состав аналитик). Элемент классификатора - для каждой записи в таблицу данных.

Хочу уйти от SQL. Сильно зависит от конфигурации. А писать свои отчеты под каждого клиента - глупо. Кажется более реальным - нормальная структра кубов + человеческий клиент. Кстати, сейчас посмотрел подключение через DSO катит в 1С, так что твоя идея не лишена смысла. Еще бы бесплатный OLAP сервер где надыбать.

никто не в курсе, что такое PivotTable?

Компонет такой в офисе. Чаще всего используется для отображения сводных данных. А о MDX ты не в курсе? Скоро уже спать, а все никак победить не могу...

27. Это тебе NS подсказку решения дает, а не спрашивает.

А вот теперь эту подсказку мне бы еще понять. Задача ведь конкретна. Проникся твоей идеей, хочу запихать все в 1С. OWB ложить не хочу. with member [Measures].[ПросроченныйДолг] as 'что здесь надо написать?' with member [Measures].[НаСколькоДнейПросроченно] as 'что здесь надо написать?' Как найти множество от ДатаОперации до ОплатитьДо?

29. Переведи дату в числовой формат 2004.08.12 = 20040812 - универсальный формат. Where _Dat<=ЧисловоеПредставлениеДатыОперации and _Dat>ЧисловоеЗначениеОплатитьДо. Разница - просроченость - легко вычисляется арифметически и возвращает число дней.

Разница в днях/месяцах/годах считается datediff. Вопрос в получении множества дат лежащих в пределах от дата1 до дата2. В вычислении просроченного/непросроченного долга на заданную дату

31. Будешь смеяться, но структуру регистра я привел в ветке "Посоветуйте струтктуру регистра...", пост №4. Множество дат в том случае - список значений фильтра регистра, который вычисляется в цикле(прибавление 1 на число раз разницы) - поскольку значения даты - число - то очень быстро.

Да не спорю что быстро. Но вот беда - не катит такое объявление регистра. Конфа у клиента - типовая. ТиС 9.2 Объем базы большой вот и хочет быстро получать отчеты. Понимаю что могу хранить даты как заблагорассудиться. Числом, строкой, хоть varchar(4000). Запрос от этого не меняется очень уж сильно. Не будет datediff, будет просто разность. В 31 описано что нужно. И формат хранения даты здесь ни причем...

(Волшебник) Правильно, все в копилку знаний. Не важно что половина топиков - общие размышления. Другая половина общение ни о чем. Зато базу знаний за август можно будет качать целую ночь... (Алл) Ну неужто никто не сталкивался?

33. Множество дат можно сформировать запросом, затем where dat in (строка дат)

Вопрос стоит об MDX. SQL рулит всегда, знаю. Но сейчас нужен MDX. В MDX where - ограничитель на множетсва. По моему slicer называется.

36. Я не знаю MDX (жаль - не могу помочь), но почти ко всему можно обратиться через ADO... А Мультикуб от vtools не пробовал? Там не требуется изменение конфигурации.

Нет. На сайте об этой компненте написано "Обработка демонстрирует работу с базой, основанной на компоненте "Быстрые регистры", т.е. она не может работать с конфигурацией, на которой не установлена вышеуказанная компонента" Отпугнуло. Даже качать не стал. Стоит попробовать?

38. Эту компоненту можно легко удалить. Просто она инсталирует MySQL и все движения записывает там.  Сама же и строит запросы к mySQL. Я ее реально не использовал, могу сказать одно - разработки от vtools всегда были добротными.

Зачем все так сложно ? Если нет желания писать выгрузку или при этом "горе от ума" поисходит, не лучше готовыми наработками воспользоваться ? Например, Adelite ETL, в нем прям реализована выгрузка из типовой ТиС.

Насчет Adelite ETL - пробовал запустить его в течении 3 дней. Но видимо руки кривые. В прнципе ETL преобразования - не то что интересует. Вопрос изложен в

Бойтесь. Убогий, но рабочий вариант для В общем сделал так -  К измерению ДатаОперации добавил уровень - документ у которого есть 2 свойства "ДатаОперации" и "оплатитьДо". Просроченный долг вычисляется так - И чего в голову не придет после 3 бутылок пива...

Когда сделаю по человечески - положу сюда. Чтоб не стыдно было в базе знаний публиковать. Кстати, на - Addelite ETL оказывается запустилась только в одной организации, на базе в 10 Mb. У всех остальных - ругнулась на память. Вот так. Нафига она тогда нужна? При 4GB базе? Может конечно релиз какой старый... Жаль что их техподдержка на запросы не реагирует. А все процедуры оттуда реализуются очень просто и на встроенном языке. Городить огород на  MFC  - уже слишком

А почему не поставить "Олап" от ПиБи?

А поподробнее где об этом? Ссылки там, статьи... Я MS AS  то еще меньше месяца вижу....

- Это те самые ПиБи, которые создали МОД.

- так точнее будет

45. Это типа Мультикуб, но в другой упаковке.

Другими словами MS AS  только в левую руку. Еще за денюжку. 200 американских рублей. За набор шаблонов и etl. Да и если честно, самому интереснее поковыряться.

А ломаная OLAP 7.7 у кого нить есть? Интересно было бы посмотреть...

Нехорошо это - кряки и ломалки просить (так в правилах сказано) На самом деле (судя по описанию) - "OLAP 7.7" - набор запросов и etl процедур. Сам такое написать можешь.