Letyshops

Комплексы аналитических приложений

Стивен Майер
Продолжение.
Как выбрать? | Необходимая/допустимая степень настройки | Чудес не бывает

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

Гибкость важная характеристика любого приложения. Можно ожидать, что потребуется настройка в трех сферах: база данных, ETL и отчеты.

При проектировании базы данных главное изучить схему данных с точки зрения двух критических факторов.

  • Одинаковы ли уровни детализации схемы и источника данных? Как ни банально, нужная степень детализации гарантия либо успеха, либо провала приложения для хранения данных. То же верно и для РАА.

Если вы работаете в сфере финансовых услуг и нуждаетесь в данных на уровне счетов, а РАА может выдавать сводки только на уровне клиента, значит у вас возникнут трудности, справиться с которыми нелегко. Если программа предлагает только итоги дня, а вам они нужны каждый час, то как быть с этим?

Возможно, мы несколько сгустили краски, но приведенные примеры дают представление о проблеме детализации, которую стоит знать, прежде чем покупать РАА.

  • Легко ли встроить в проект изменения, связанные, например, с добавлением ссылок на существующие координаты хранилища данных или на пользовательские поля, не включенные в стандартную схему РАА? Предусматривает ли комплекс особые поля, которые можно использовать для улучшения приложения, не боясь, что очередной апгрейд отменит модификацию?

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

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

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

<<предыдущая [1][2][3] следующая>>
[вид для печати]
© DM Review

 

 

Реклама: