ШИРОКИЙ ВЗГЛЯД
Реляционные базы данных -один из тех элементов корпоративной инфраструктуры, которые пользуются наибольшим доверием. Однако, хотя им столько же лет, сколько самим вычислительным машинам, они все еще не дают возможности принимать на основе их данных быстрые и надежные решения.
Уже не слишком новая технология под названием OLAP (online analytical processing -оперативный анализ данных) позволяет прорываться сквозь груды информации и получать то, что необходимо. К сожалению, рынок столь быстро фрагментируется, что вам может потребоваться специальный инструмент поддержки принятия решений только для того, чтобы понять, какой инструмент вам необходим.
В настоящее время поставщики спорят о том, какой способ применения OLAP лучше: ROLAP (реляционный оперативный анализ данных) или MOLAP (многомерный оперативный анализ данных). Дайте мне слово! Все эти дебаты скучны. Не лучше ли назвать это скучным анализом данных?
Все это чересчур плохо, потому что каждая компания, стремящаяся остаться конкурентоспособной, нуждается в таком типе анализа информации, который предоставляет OLAP.
Технология OLAP позволяет быстро рассекать и группировать данные. Она также дает пользователю возможность видеть многомерные данные, что более удобно для анализа, чем ряды и колонки реляционных баз.
Откуда родом OLAP
Интерес к OLAP стал расти с реактивной скоростью с того момента, как эта технология впервые была представлена при довольно необычных обстоятельствах. Создавшая ее компания Arbor Software получила известность в 1993 г., когда заключила контракт с Э. Ф. Коддом, отцом реляционных СУБД, чтобы он санкционировал использование этой технологии. Однако, так же как никто из поставщиков реляционных СУБД не придерживается всех 12 реляционных правил Кодда, ни один из инструментов OLAP не отвечает всем 12 правилам OLAP того же Кодда. Есть вещи, которые не изменишь.
Так почему же вам не продолжать использовать для анализа вашу реляционную СУБД? Запросы реляционных систем лучше работают при небольшом числе рядов. Даже имеющиеся изощренные инструменты генерации графических отчетов и запросов основаны на языке структурированных запросов SQL, который сам недостаточно структурирован и чересчур абстрактен для надежного анализа.
На самом деле, анализ, основанный на реляционных запросах, не многим лучше того, что был до его появления.
Основная трудность, связанная с реляционными СУБД, состоит в том, что их поставщики чересчур много заботятся о скорости, с которой компании смогут пополнять свои базы данных, и относительно равнодушны к тому, как они будут получать эти данные обратно.
Все существующие инструменты OLAP хороши. Если вы используете СУБД определенного поставщика, то, возможно, захотите работать с его же OLAP-средствами.
Но если вы в этом плане не собираетесь себя ограничивать, советую испытать серию продуктов Essbase производства Arbor Software. Эта компания, несомненно, является лидером в развитии технологии OLAP. А продукты Essbase представляются наиболее практичными. Они позволяют создавать запросы из подключаемых модулей электронных таблиц и даже из Web-браузеров.
Система Express корпорации Oracle почти столь же дружественна, но обладает большей гибкостью при практически такой же мощности. Она отлично производит многомерный оперативный анализ, но и реляционный анализ тоже делает неплохо.
Архитектура MetaCube компании Informix также подает надежды благодаря ее тесной интеграции с сервером on-line той же компании.
А где же Microsoft? Она в конце прошлого года приобрела израильскую компанию Panorama Software, которая добавила в SQL Server несколько таких модных функций, как Cube и Rollup. Хотя для полнофункциональности этого не хватает. Поэтому, если вы работаете с системами Microsoft, вам следует либо подождать, либо попробовать Essbase.
Джон Ташек
Вы знаете кого-нибудь, кто использует реляционную СУБД для поддержки принятия решения и при этом доволен жизнью? Сообщите мне по адресу: john_tashchek@zd.com.
Подпись к рисунку 1.
Джон Ташек
