Мы не первые отмечаем эти потребности в переменах. В 1988 г. ведущие исследователи в области баз данных пришли к соглашению, что системы управления базами данных стали слишком сложными, и что стало важно обеспечить средства автоматического конфигурирования и администрирования (http://citforum.ru/database/digest/asil_01.shtml). Два года спустя Сураджит Чаудхари (Surajit Chaudhuri) и Герхард Вейкум (Gerhard Weikum) предложили радикальный пересмотр архитектуры систем управления базами данных. Они полагали, что системы управления базами данных должны делаться более модульными, и что нам нужно расширить свои представления об управлении данными для учета возможности использования упрощенных, компонентных строительных блоков. Позднее к этому хору присоединился Майкл Стоунбрейкер (Michael Stonebraker), утверждавший, что «один размер всем не годится», и приводивший примеры приложений, для которых не подходит традиционная архитектура РСУБД.
Как говорил Стоунбрейкер, поставщики реляционных систем поддерживают иллюзию того, что РСУБД является ответом на потребности любого приложения, связанного с управлением данными. Например, когда хранилища данных и системы поддержки принятия решений стали важными прикладными областями, поставщики адаптировали свои продукты к потребностям, возникшим в этих новых областях. Они обеспечивают новые возможности поверх не слишком пригодных для этого реализаций систем управления данных, которые ориентированы на поддержку знакомого всем языка SQL. Однако эта модель рушится, когда кто-нибудь начинает более глубоко анализировать возникающие потребности.
Ниже приводится список некоторых новых проблем, возникающих в области управления данными. При анализе этих примеров нашей целью является получение некоторых классов возникающих приложений, для которых применение традиционных подходов к управлению данными не является оптимальным.
Хранилища данных. В организациях розничной торговли теперь имеется возможность фиксировать каждую транзакцию клиента, производя гигантский источник данных, который можно «раскапывать» для извлечения информации о структурах покупок клиентов, тенденциях к повышению или понижению популярности продуктов, географических предпочтениях и бесчисленных других феноменах, которые можно использовать для увеличения объема продаж и сокращения расходов на поддержку бизнеса.