cherrex_DenТак на каком этапе производить трансформацию и кто этим должен заняться(OLTP или OLAP или кто-то еще)?

Ключевое слово - ETL

cherrex_DenА все аналитические системы работают в дискретном(пакетном) режиме?
вопрос когда данные должны быть там... как-можно-быстрей, завтра, по-требованию....

cherrex_Den
Так как OLTP у нас на ASE, я стараюсь рассматриваю только технологии Sybase(не хочеться допускать расслоение и зоопарк). Но это не категорично! Если нет другого выхода, то можно использовать другие технологии. Использование RepServer и IQ это чисто мой выбор(увы о другом не знаю)!
На сколько знаю, практически все ведущие производители баз данных неимели (или очень скромные поделки) своих аналогов ETL, Data Integration и т.д. и приобрили другие компании, у которых были готовые решения. Sybase не исключение. Так что "технологии Sybase" будет громко сказано ;)

cherrex_Den
Ситуация такая: Примерно 300-400 документов рождается каждый день.
8<---
Сейчас потребность такая, но в дальнейшем все может усложниться(и объемы могут вырости и усложниться трансформация). Поэтому если заложиться на самый худший расклад, что можете посоветовать?
Можно конечно сегодня начать "развозить пиццу камазами" в рассчете на то что, когда-то кто-то "закажет аж 10 тон"

Стоимость одних только лицензий на соответствующие продукты может легко начать исчисляться 5-ти значными цифрами, а еще не забываем надо кому-то все это дело поддерживать, разрабатывать и т.д. и т.д...
И еще, когда у вас будут "и объемы могут вырости и усложниться трансформация" может пройти не мало времени.

cherrex_Den
То есть это обычный селект с вычислением суммы, групперовкой по дате и еще по нескольким полям. Сам документ имеет полей 20-30, но нужно максимум 5-10.

... а может и вполне хватит perl скриптов и cron'а :))

herr
.... начать исчисляться 5-ти значными цифрами,...
6 -ти значными цифрами

cherrex_DenТ.е между OLTP и OLAP должна быть "ETL-прослойка"?
"должна" - не так категорично.
ETL это инструмент позволяющий вытащить данные [E]xtract, трансформировать/изменить их [T]ransform и загрузить в хранилище данных [L]oad.
Чем сложнее инфраструктура (источники,сложность трансформации данных, внутреняя политика и т.д. и .т.д) тем ближе обусловлен выбор соответствующего продукта.


cherrex_DenКакая прослойка максимально подходит для СУБД Sybase? Или это не та грань при которой надо руководствоваться при выборе ETL?
Как правило, все они независимые от источника данных, да и не это самое главное в них.
Хотя если очень хочется, то можно
+

и будут решения от Sybase ;)

cherrex_DenЯ считаю что информация должна ппопадать в OLAP как можно быстрей!
скорее бизнес должен знать когда им нужны данные

cherrex_DenИ можно примеры построения таких систем? Т.е на чем реализован OLAP, как данные поподают в него и какой ETL используеться?
// http://www.sybase.com/about_sybase/customer_success_stories


cherrex_Den
* 300-400 документов рождается каждый день.
* Анализ нужен в разрезе по дням. То есть это обычный селект с вычислением суммы, групперовкой по дате и еще по нескольким полям. Сам документ имеет полей 20-30, но нужно максимум 5-10.

Для вашей задачи не думаю что нужен Sybase IQ...да и вообще какой-либо полноцений OLAP сервер и также ETL при таких обьемах ;)

имхо, ROLAP будет хватать на ура (тем более вы еще до конца и не знаете, что нужно будет в итоге, а строит дом без чертежа...).
Все данные хранятся в ASE (хотя многих ROLAP функций и нет в ASE, вам они, как видно и ненужны),
а ROLAP клиент (Microstrategy, BusinessObjects и .т.д), уже будет генерить соответстующий(-ие) SQL и т.д. или на худой конец Excel хватит чтобы посмотреть на результат "обычный селект с вычислением суммы" ;)

Остается подумать стоит ли огораживать данные или нет, и на сколько трудно простыми деиствиями "почистить" данные.

MasterZiv
cherrex_Den wrote:

> Я считаю что информация должна ппопадать в OLAP как можно быстрей!

Если вы или ваши постановщики задачи так считают, то у вас что-то явно
не так. Все задачи OLAP должны быть не требовательны к "свежести" данных.

Очень спорное утверждение. Скажем так - традиционный взгляд ;)
Бизнес ставит задачи по доступности данных и если ему нужны данные сейчас (или near-realtime), то на все это не должно быть никакого удивления.
Кстати, о Real-Time Data Warehousing стали "говорить" достаточно давно, средств как этого достичь хватает.