Хотелось бы узнать: кто нибудь использует инструменты анализа данных и какие? Я прикрепляю голосование, но интересны обоснования. Под такими инструментами я понимаю :1) OLAP организация хранилища данных; 2) реализованные математические модели (классификации, прогнозирования); 3) срества визуализации.
Пользовался в своих приложениях OLAP Dyanamic Cube - в принципе не плохая вещь. Но сейчас плавно перешел на 1с, поэтому данные инструменты в силу ограниченности платформы, к сожалению стали не доступны.
Читатель снов, спасибо. а потребность есть? Ведь есть инструменты которые позволяют использовать данные 1с и стоить кубики на их основе и соответственно обрабатывать их. Bob, интересно. Есть решения вот и интересна потребность.
Интересно чем же это платформа то ограниченна так? Вроде как все выгружается без проблем. Крути сколь хошь. ЗЫ: BW-ей пользуемся. Только на как аналитикой нифига. А гольная отчетность.
GebeusRaider, потребность иногда возникает, в зависимости от того, что хочет заказчик. К сожалению не каждый финанасовый директор знаком с современными средствами аналитики, и иногда сам с трудом представаляет, что ему нужно. Выгрузка - это конечно хорошо. Но хотелось бы иметь некоторые инструменты, например тот же полноценный OLAP, в функционале самой платформы. Можно, конечно, использовать прямые запросы к базе из внешнего приложения, но это опять-таки потребует большее количество времени на разработку и соответственно отразится на себестоимости проекта.
Хм. Назовите мне технологию которая поддерживает ОЛАП над ОЛТП базой. Т.е. я вообще не понял о чем идет речь. Так или иначе перегружать нужно.
Назваю: OLAP добавлено через 3 минуты куда перегружать? хотя чисто теоретически источник данных для OLAP API может быть любым, но лучше всего адаптируровано к традиционным реляционным базам данных. Посмотри на семантику MDX, тебе сразу станет все понятно.
HorstWessel, Mix прав. OLAP и OLTP - разные способы организации данных. Поэтому у хранилищ данных есть как правило механизмы загрузки. А что такое MDX?
видимо, подразумевается, что ОЛАП требует подготовки данных, т.е. с сырыми данными он работать не может. Хотя в качестве источника может быть любая ОЛТП бд. добавлено через 47 секунд Язык запросов к ОЛАП
Многие просто не имеют представления о том что есть такие инструменты для анализа данных. Да, к сожалению, так обстоят дела в России. Хотя кое-где уже вовсю используют ОЛАП решения.
GebeusRaider, нет, OLTP - это процесс в который вовлечена одна запись (вставка, модификация), OLTP - оперирует над коллецией. И там и там может быть одна и таже реляционная база данных. Вообще можно и поверх "первичных" данных. Но может оказаться, что вычисления потребуют много времени. Тогда можно руками создать таблицы и саггрегировать туда (обычным SQL-ем) промежуточные данные. А в Microsoft со своим SQL не поставляет?
Поставляет ещё с 7й версии, в качестве бесплатного дополнения. добавлено через 1 минуту Тогда смысл теряется ОЛАП технологии. Есть вообще то фундаментальные требования к ОЛАП БД.
Нет смысл не теряется. Жизнь есть жизнь и скорость обработки пропорциональна кол-ву записей, ничего не поделаешь. Но. Человеку все равно не под силу анализировать большой объем данных, поэтому простые аггрегационные таблицы лучший выход. А подробнее? Довелось работать с Mondrian. Никаких фундаментальных требований не припоминаю. Некотрые сервера, типа оракла, могут создавать материализованные виды, которые можно использовать для реализации. Но это не фундаментальное, да и не требование вовсе. Есть пожелания к базам данных: главные ключи, индексы и т.д.
HorstWessel, согласен, процесс. про требования: я всегда думал, что для OLAP проектируется база данных в виде "звезда" или "звезда-снежинка" в тойже реляционной структуре данных. Это и есть ключевой момент при организации данных. Однако кубы это только решение задачи сбора и консолидации информации. Дальше идут методы очистки и трансформации данных и собственно модели. А для моделей нужно также хранить трансформированные данные. Кстати вот еще интересно что предлагает MS в SQL 2005 по части OLAP.
HorstWessel прав. Кодд, создатель реляционной модели данных, сформулирвал требования к OLAP, которые затем были переработаны в тест FASMI, определяющий требования к продуктам OLAP (т.е. если приложение говорит, что оно предоставляет функции OLAP, то оно обязательно должно удовлетворять этим условиям). FASMI - это аббревиатура от названия каждого пункта теста: Fast (Быстрый). Приложение OLAP должно обеспечивать минимальное время доступа к аналитическим данным - в среднем порядка 5 секунд; Analysis (Анализ). Приложение OLAP должно давать пользователю возможность осуществлять числовой и статистический анализ; Shared (Разделяемый доступ). Приложение OLAP должно предоставлять возможность работы с информацией многим пользователям одновременно; Multidimensional (Многомерность). См. выше; Information (Информация). Приложение OLAP должно давать пользователю возможность получать нужную информацию, в каком бы электронном хранилище данных она не находилась. и в этой "лакмусовой бумажке" нигде не говориться о том, как должны выглядеть исходные данные. а все современные изыски - это от недостатка производительности. косвенным пожтверждением этому может служить BusinessObjects, который в качестве источника данных может брать все, что угодно, а потом создает кубы на клиенте и данные в этих кубах можно вертеть как угодно. (кстати, основатели этой компании, по-моему, работали в Oracle и, когда там не поддержали эту идею - создание кубов на клиенте, выделились в отдельную маленькую фирмк, которая со временм сталда законодателем моды в мире OLAP b, вс вою очередь поглотии кучу других фирм). GebeusRaider, "... Это и есть ключевой момент при организации данных. ..," ничего подобного - никакой это не ключевой момент. " ... Дальше идут методы очистки и трансформации данных ..." за этими терминами очень часто скрываются маркетинговые штучки. GebeusRaider, а не используют их (специализирвоанные пакеты) просто потому, что очень дорого. наиболее известные можете посмореть вот здесь: http://forum.volgograd.ru/showthread.php?t=44370 , в последнем пункте опроса. добавлено через 2 минуты хотя, по крайней мере трое проголосовавших их используют, и, подозреваю, один из них Mix, использующий SAP.
AlTk Это все верно и правильно, однако есть еще и жизнь, где если данные не готовить, то как минимум пункту Fast (Быстрый) соответствовать не будет, ибо просто куб будет строиться/рефрешиться столько, что уже нужны будут свежие данные. Увы не знаком с BO, однако идея кубов на клиенте совсем не нова. Например такую возможность предоставляет простейший Excel. По поводу спора про 1С, не понимаю в чем проблема встроить стандартную MS-вскую ActiveX компоненту?
jek, "... идея кубов на клиенте совсем не нова. Например такую возможность предоставляет простейший Excel. ..." компания ВО была основана в 1990 году.