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

Сверхпроизводительные базы данных

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

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

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

Встроенные базы данных

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

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

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

Интеграция с объектно-ориентированными технологиями

в будущем развитии реляционных баз данных труднее всего спрогнозировать то, как будет вестись их интефация с объектно-ориентированными технологиями. Центр тяжести технологий разработки приложений со всей очевидностью сместился в сторону объектно-ориентированных инструментальных средств и методик. Растет популярность языков С++ и Java, которые применяются не только в клиентских приложениях, но и для реализации деловой логики на сервере. Но ведь базовые принципы табличной организации данных в реляционной модели уходят корнями в эру языка COBOL с его записями и полями и не имеют ничего общего с объектами.

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

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

Интерфейсы реляционных СУБД на основе языка Java, такие как JDBC и встроенный SQL для Java.

Внедрение Java в качестве стандартного языка хранимых процедур. Практически все ведущие поставщики СУБД объявили о своих планах поддержки Java в качестве альтернативы своим собственным языкам хранимых процедур.

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

71.Я

структурах, реализация механизмов хранения (вложенные таблицы, массивы, со

ставные столбцы) может сильно отличаться Итерфеисы, ориентированные на обработку сообщений, включая триггеры, гене

рирующие внешние сообщения для взаимодействия с другими приложениями

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