04bc80b4

Следующее поколение


Как будут выглядеть базы данных в 2003 г.? Следующие идеи не являются революционными; фактически, все они происходят из исследований и передовых разработок середины и конца 80-х. Многие возможности присутствуют в коммерчески доступных продуктах.

Снова появятся распределенные СУБД. Во многих своих публикациях и выступлениях автор обращал внимание на то, что технологии складов данных появилась по причине провала технологии распределенных СУБД и необходимости каким-то образом решать "проблему островков данных". Распределенные и неоднородные системы баз данных начинают возвращаться с наличием множества продуктов установившихся и начинающих поставщиков. Эти продукты позволяют получить доступ с содержимому баз данных, располагаемых на различных платформах, в рамках одной информационной или аналитической операции без потребности предварительного копирования всей этой информации в одну базу данных как это делается при классической организации складов данных.

Разрешены многие проблемы, подрывавшие возможность создания распределенных СУБД. Уже не существенны такие вещи, как низкая эффективность процессоров и сетей, попытки создания распределенных сред с возможностью чтения и записи, непонимание производителями потребностей заказчиков. Следует ожидать появления более надежного набора продуктов, которые могут помочь получать синтезированную информацию, рассредоточенную по разным платформам, без потребности выполнения предварительных действий, свойственных сегодняшним складам данных.

Будут становиться общераспространенными "самоизвлекающие" (self-mining) базы данных. Многие помнят системы управления базами знаний (СУБЗ) и базы данных, основанные на методах искусственного интеллекта. Первые коммерчески значимые шаги в направлении активных баз данных были связаны с принятием и использованием хранимых процедур. Извлечение данных (data mining) интересует большинство организаций; это направление получило популярность взамен теряющих приверженцев экспертных систем и систем искусственного интеллекта.
Следует ожидать появления встраиваемых в СУБД средств извлечения данных, как статистических, так и связанных с методами искусственного интеллекта.

Будут лучше поддерживаться мобильные базы данных (mobile databases). Мобильным базам данных, которые находятся несколько вне основного направления СУБД, присущ целый ряд сложностей. Прежде всего, требуется синхронизация мобильных баз данных с содержимым сервера. В сложных мобильных приложениях требуются двунаправленные потоки данных между мобильными платформами и серверами, часто с применением обеих моделей "push" и "pull". Более простые обмены данными на основе "docking" могут оказаться недостаточными для потребностей мобильных приложений.

Следует ожидать, будет продолжаться развитие подсистем СУБД обработки запросов и транзакций для поддержки нестандартных распределенных приложений, скорее тех, которые основываются на мобильных компьютерах, чем базирующихся на проводных сетях.

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

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


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

Будет происходить широкий переход от специализированных структур к реляционным базам данных. Мы находимся только в начале "эры drill-through" - сред, в которых содержимое баз данных разного типа будет связываться с помощью возможностей, исконно присущих продуктам и средам их поддержки, а не посредством самодельного и трудно сопровождаемого кода заказчиков. И в средах единственного поставщика, и в основанных на стандартах системах от нескольких поставщиков можно увидеть значительно больше приложений, в которых для выполнения общих операций используются специализированные и высоко эффективные структуры (но достаточно жесткие). Гибкость реляционной модели может обеспечить непредсказуемые потребности управления данными большого объема.

Будут усиливаться возможности безопасности баз данных. По иронии судьбы многие исследования и эксперименты в области безопасных баз данных в течение 80-х перекочевали в область военных приложений. Не желая занижать важность и потребность в безопасности баз данных для этих сред, автор полагает, что наиболее серьезные проблемы безопасности сегодня связаны с коммерческими приложениями, включая среды электронной коммерции на основе Internet. Упрощенная дискреционная модель контроля доступа, используемая в большинстве СУБД (реализуемая на основе операторов SQL GRANT-REVOKE), обеспечивает только частичное решение проблемы межкорпоративной безопасности с элементом финансового риска.

Следует ожидать более сильного связывания традиционных средств безопасности баз данных со средствами безопасности операционных систем и сетей.

Станут общераспространенными темпоральные базы данных. Хотя возможности поддержки темпоральных (ориентированных на время) данных уже присутствуют во многих продуктах, они редко используются в основном потоке приложений. Обычно для поддержки времени создаются отдельные таблицы (например, END-OF-LAST-MONTH-INVENTORY), и разработчики обрабатывают темпоральные операции с использованием SQL и клиентских средств запросов.


В отличие от этого, в темпоральной базе данных время является родовой частью инфраструктуры, и имеется темпоральный вариант SQL (например, операция WHEN позволяет произвести доступ к различным состояниям данных в определяемые моменты времени в прошлом).

Глядя на то, как много интеллектуальных бизнес-приложений, построенных на основе складов данных, является по своей природе темпоральными, можно оценить распространенность этих возможностей сегодня. Одной из причин того, что не применяются темпоральные базы данных, состоит в том, что потребности работы со временем обслуживаются многомерными базами данных, в которых время является одним или несколькими поддерживаемыми измерениями. Временное измерение хорошо работает при регулярных, контролируемых изменениях, таких как ежемесячное обновление склада данных или получение статистики за два года по информации, поддерживаемой в складе данных. Однако, в таких средах, как операционные хранилища данных, получающие данные в реальном времени из многих производственных источников, требуется поддерживать ограниченную историю при наличии непредсказуемых изменений. Эти потребности нелегко удовлетворить за счет временного измерения. Здесь более пригодны темпоральные базы данных.

Будут возрастать возможности VLDB (сверхбольших баз данных). Следует ожидать, каждый лидирующий продукт СУБД сможет легко управлять многотерабайтными базами данных.

Будет выполнена по меньшей мере одна непредвиденная существенная разработка. Как уже отмечалось, в 1990-е годы рынок направил использование технологии баз данных несколько по другому пути, чем тот, который планировали производители. В следующие пять лет в области технологии баз данных произойдет нечто, отсутствующее на горизонте сегодня. Можно смело держать пари.


Содержание раздела