Уважаемые читатели!
Мы предлагаем Вашему вниманию пересказ статьи Алана Саймона, опубликованной в октябрьском номере журнала Database Programming & Design. По моему мнению, даже если не принимать во внимание высокий авторитет автора как консультанта и писателя, актуальность темы этой статьи исключительна. Приближается новое тысячелетие, и всем хочется знать, что будет происходить в области технологии баз данных хотя бы в ближайшие несколько лет. Конечно, оценки и предсказания г. Саймона не являются бесспорными, но в основном им можно доверять, потому что по специфике своей деятельности автору приходится общаться с очень многими людьми из числа как производителей, так и пользователей СУБД, и у него имеется богатый материал для анализа.
Заметим, что Алан Саймон написал и издал более 20 книг, полный список которых Вы можете найти в книжном магазине www.amazon.com. Перевод одной из последних книг г. Саймона "Strategic Database Technology: Management for the Year 2000" (Morgan Kaufmann, 1995) должен скоро выйти в свет в издательстве "Финансы и статистика".
С уважением, Сергей Кузнецов
Alan Simon, a vice president of worldwide data warehousing
solutions at Cambridge Technology Partners
Оригинал статьи можно найти по адресу http://www.dbpd.com/9810smn.html
Забавные вещи происходят с приближением нового тысячелетия. Нет, речь идет не о Проблеме Двухтысячного Года. Отношение к этой проблеме определяется собственным чувством юмора и тем, насколько серьезной она действительно будет. В этой заметке говорится о технологии баз данных.
Ну и что, скажете вы. Сегодня ВСЕ используют базы данных. Автор с этим согласен. Заканчивается десятилетие, в котором мы видели становление Internet, переход технологии "клиент-сервер" в разряд mainstream, рождение новых подсегментов рынка компьютерных приложений (call-центры, пакеты автоматизации продаж, корпоративные информационные приложения в архитектуре "клиент-сервер"). Еще одно обстоятельство не перестает изумлять автора. Раньше в большинстве случаев СУБД использовались как продвинутые системы управления файлами. Сотня приложений, анализируемых автором в течение каждого года, составляет бесконечно малую часть сотен тысяч или даже миллионов приложений, существующих в мире бизнеса. Но определения схемы приложений всегда поражают, независимо от того, включают ли они десяток реляционных таблиц или несколько сотен. Почти всегда приходится видеть скелетные образующие языка определения данных (DDL - Data Definition Language), такие как операторы CREATE TABLE и CREATE INDEX со списками столбцов и указанием их типов данных и размеров, а также, возможно, с несколькими разделами NOT NULL.
Но где же разделы CHECK? Где ограничения для различных видов ссылочной целостности и резидентных в базе данных бизнес-правил? За пределами операторов DDL иногда встречается использование хранимых процедур, ну и что?
Прежде чем сообщать автору по электронной почте, что в некоторых приложениях баз данных используются все эти возможности и даже больше, вспомните, что автор руководствуется состоянием рынка, глядя в основном на крупные корпорации. Конечно, на рынке имеются приложения баз данных с развитым использованием управления бизнес-правил и логики на стороне сервера. Однако автор полагает, что при рассмотрении возможностей большинства лидирующих продуктов СУБД можно увидеть СУЩЕСТВЕННЫЙ разрыв между широтой их использования на рынке и их возможным потенциалом.
Имеется несколько причин этого ограниченного использования возможностей. Во-первых, поразительно большое число клиент-серверных приложений в действительности является портированными на распределенные платформы приложениями мейнфреймов (основанных на базах данных или файловых системах). И группы, производящие преобразования, выполняют только необходимые действия, такие как создание набора определений таблиц с соответствующими столбцами. Контролируемые базой данных диапазоны значений? Пардон, но преобразуемые данные не являются надежными, и использование этой возможности увеличило бы время загрузки базы данных и всего проекта. Ссылочная целостность? Определения первичных и вторичных ключей? Нет информации о качестве данных в столбцах, которые требуется использовать в качестве ключевых полей.
При использовании технологии складов данных (data warehousing) возникает потребность в частой загрузке (вернее, перезагрузке) содержимого баз данных в течение относительно умеренных промежутков времени, для чего требуется структуризация заново создаваемых баз данных (составляющих склад данных) с минимальным набором определений бизнес-правил. Было бы здорово иметь набор надежных объявлений для каждого столбца каждой таблицы склада данных, таких как допустимые диапазоны или списки значений и межтабличные ограничения целостности. Но большинство разработчиков складов данных находят, что вызываемые накладные расходы напрямую препятствуют использованию по причине слишком большого времени загрузки, а также потребностей перезапуска процесса загрузки при возникновении проблем. Кроме того, философия "это база данных только для чтения, а не система для фиксации этих данных", в течение долгого времени распространенная в мире складов данных, породила распространенное мнение о том, что в этой среде развитые возможности баз данных не требуются.
По поводу современного использования баз данных интересно заметить, что в начале этого десятилетия, как раз перед спадом активности бизнеса в Соединенных Штатах в 1990-м году, производители средств управления базами данных пытались выбросить на рынок результаты своих исследований и передовых разработок 80-х годов на мировой рынок. Предполагалось, что развитые средства управления информацией - распределенные базы данных, базы данных с "искусственным интеллектом" и первые гибридные объектно-реляционные базы данных - станут основой приложений во время приближения следующего тысячелетия.
Однако, как это часто бывает, рынок внес свои коррективы в эти лучшем образом задуманные планы. Во-первых, совершилась революция "клиент-сервер", заставившая производителей и пользователей вступить в борьбу за обеспечение кросс-платформенного доступа к базам данных и выживание в реальном мире приложений. Пренебрегаемый многими вначале подход ODBC стал тем средством, которое обеспечило доступ к базам данным в среде "клиент-сервер", и значительная часть разработок компаний-производителей стала расходоваться на переделку централизованных СУБД для работы в распределенных, многоплатформенных средах.
Феноменальный рост Internet от той точки, в которой можно было производить рекламные эксперименты с Web-страницами, до появления технологической среды разработки приложений следующего поколения снова вызвали борьбу в сообществе производителей. Усилия сосредоточились на новых поколениях корпоративных архитектур, поддерживающих взаимодействия между Web-серверами и серверами баз данных, равно как связью Java с базами данных.
Существенные усилия были потрачены на превращение в продукты экспериментальных параллельных архитектур баз данных; на приспособление оптимизаторов запросов к обработке сложных запросов с многочисленными соединениями, распространенных для сред складов данных; на обеспечение интерфейсов между частными структурами данных, присущих, например, многомерным базам данных, и структурами, поддерживаемыми основными серверами баз данных.
Оглядываясь назад, испытываешь ощущение, что совместные усилия сообществ деятелей рынка и разработчиков приложений, все еще ограниченные возможностям реляционной технологии, побудили мир бизнеса сделать нечто большее, чем первые шаги в направлении следующего поколения технологии баз данных.
Мы находимся на пороге нового тысячелетия. Что это означает для эволюции использования баз данных?
Опыт показывает, что максимальный период времени, для которого можно более или менее точно прогнозировать развитие большинства областей компьютерной технологии, составляет около пяти лет. Посмотрим на список тем книги автора Strategic Database Technology: Management for the Year 2000 (Morgan Kaufmann, 1995), в которой обсуждались пути развития систем управления базами данных и информационных систем в 90-е годы. Некоторые вещи, такие как гипертекст и гипермедиа уже стали общераспространенными. Отношение к другим предметам, таким как будущее развитие языка Xbase и стандарт, со временем изменилось.
Существенно то, что многие направления индустрии были на некоторое время законсервированы, поскольку в фокусе развития технологии баз данных находились улучшенная поддержка складов данных и Internet. По мнению автора, во многих из этих областей следует ожидать возрождения активности производителей и интереса разработчиков приложений.
Реляционная модель останется доминирующей формой баз данных. Время иерархических и сетевых продуктов прошло, если не считать унаследованных приложений, миграция которых не произведена. "Чистые" объектно-ориентированные базы данных нашли свою нишу в виде мультимедийных приложений. Модели баз данных специального назначения, такие как многомерные системы (вспомним, что не так давно считалось, что только эти продукты пригодны для использования в среде складов данных) используются для организации небольших лавок данных (data mart), иногда с привлечением реляционных баз данных, хранящих истинное содержимое склада данных.
Не делайте ошибки: реляционная модель является абсолютным победителем на рынке. (Анекдот для тех, кто работает с базами данных с начала 1980-х: Вспомните, что одним из основных источников разногласий в сообществе баз данных являлся аргумент некоторых ученых и консультантов, что ранние РСУБД были всего лишь "основанными на реляционной модели", и что их нельзя было называть "реляционными", поскольку в них не поддерживались все основные принципы, сформулированные в статьях про реляционную модель.)
SQL остается. Конечно, стандарт SQL-3 громоздок (и, как считают некоторые люди, нереализуем). Многие виды операций с базами данных в SQL сложны синтаксически (некоторые люди полагают, что чересчур сложны). Отклонения от стандарта SQL распространены среди поставщиков СУБД, и, действительно, трудно спорить с тем, что такие понятия как "неопределенные значения" (nulls) не поддерживаются в SQL достаточно четким и полным образом. Но в любом случае никуда не денутся десятки миллионов программ от полномасштабных приложений до средств запросов данных на основе основанных на SQL инструментальных средств генерации отчетов.
РСУБД будут продолжать "умнеть" в отношение подготовки и выполнения планов транзакций. Вспомним, что в период времени от первых экспериментов компаний-производителей с реализациями реляционных систем в середине 70-х до начала 90-х, когда реляционная технология стала общеупотребительной, огромный объем работы был выполнен в области подготовки и выполнения планов запросов и транзакций. В то время как в иерархических и сетевых продуктах использовались физические указатели, на основе которых программисты специфицировали жесткие и трудно модифицируемые пути доступа к содержимому базы данных, в реляционных реализациях требовалась гибкость, а ядро СУБД должно было вырабатывать планы доступа к данным на основе сложного набора критериев (сколько таблиц затрагиваются запросом, является ли запрос выборкой данных или приводит к изменению данных).
Нравится это или нет, но потребовалось почти 15 лет, чтобы добиться "интеллигентности" СУБД, достаточной для обеспечения приемлемой эффективности обработки реальных транзакций. А потом пришло время складов данных с многочисленными соединениями таблиц фактов и измерений. Потребовались сотни человеко-лет для доводки возможностей продуктов обрабатывать запросы в стиле складов данных.
В будущем будет продолжаться совершенствование оптимизаторов для более эффективной поддержки транзакционного кросс-платформенного доступа и сложных моделей распределенной обработки транзакций, таких как цепочные транзакции, включающие масштабные многоплатформенные изменения данных.
Как будут выглядеть базы данных в 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-е годы рынок направил использование технологии баз данных несколько по другому пути, чем тот, который планировали производители. В следующие пять лет в области технологии баз данных произойдет нечто, отсутствующее на горизонте сегодня. Можно смело держать пари.