3. Возможности запросов:
4. Поддержка доступа из Internet:
IBM активно ведет работу по созданию собственного универсального сервера. С августа 1997 г. доступна бета-версия DB2 UniversalDatabase. Этот продукт относится к категории объектно-реляционных, и мы кратко обсудим его возможности позже.
8.1.1.6. Серверные продукты управления базами данных компании Microsoft
Первые работы компании Microsoft, относящиеся к области баз данных, проводились совместно с компанией Sybase, причем Microsoft поддерживала линию OS/2, а Sybase - UNIX. Так продолжалось до 1992 г., когда компания Microsoft приняла решение о переносе SQL-сервера на платформу WindowsNT. (Заметим, кстати, что недаром серверные продукты Sybase и Microsoft называются SybaseSQLServer и MicrosoftSQLServer соответственно; у этих продуктов общие корни.) Перенос SQL сервера в среду NT сопровождался существенными переделками ядра системы и в основном был выполнен специалистами Microsoft. Первая по-настоящему работоспособная версия сервера (MSSQLServer 4.21) вышла в свет в 1994 г. для использования в среде NT 3.5. Особое внимание обращалось на развитие средств администрирования, внедрение (в час- тности, и для собственного использования) механизма хранимых процедур и т.д. В 1995 г. была выпущена версия 6.0, в которой был внедрен ряд средств, обеспечивающих удобные взаимодействия с другими продуктами Microsoft. Наконец, в 1996 г. появилась наиболее современная версия 6.5.
Перечислим основные возможности MicrosoftSQLServer 6.5:
Microsoft не объявляет о планах перехода к использованию объектно-реляционного подхода. Пока развитие SQL-сервера происходит в рамках все большего внедрения в этот продукт компонентов, основанных на общей объектной архитектуре COM (ComponentObjectArchitecture - компонентная объектная архитектура). Основываясь на спецификациях OLE (ObjectLinkingandEmbedding - связывание и встраивание объектов), которые обеспечивают объектное представление различных сервисов операционной системы, а также развитие OLE - OLEDB, компания Microsoft пытается обеспечить пользователям общую объектную среду компонентов (включая данные, поддерживаемые SQL-сервером, которые могут разнообразным образом комбинироваться).
8.1.2. Насколько возможности серверов баз данных соответствуют потребностям приложений?
Как мы отмечали в вводной части этого раздела, реляционные базы данных обладают достоинствами и недостатками. Для некоторых приложений перевешивают достоинства, для других - недостатки. Можно сказать, что современные серверы реляционных баз данных (такие как Infor- mixOnLine версии 6 и выше, Oracle 7.x, SybaseV.11) обладают качествами, близкими к предельно возможным при использовании традиционной технологии. Еще возможны совершенствование оптимизации запросов, применение более эффективных методов распараллеливания, реализация более высоких уровней стандарта SQL и т.д., но принципиально при этом ничего не изменится. Реляционные СУБД могут управлять очень большими базами данных; эффективно используют возможности симметричных и массивно параллельных компьютеров; позволяют хранить в таблицах текстовую и графическую информацию произвольного размера; поддерживают достаточно развитое подмножество языка SQL; обеспечивают возможности частичного переноса логики приложений на сторону сервера за счет использования ограничений целостности, триггеров и хранимых процедур.
Существует масса приложений, для которых возможностей современных серверов баз данных хватает с запасом. Это традиционные банковские приложения, системы резервирования билетов и мест в гостиницах, системы управления предприятиями, библиотечные информационные системы и т.д. Основными претензиями со стороны разработчиков таких систем к поставщикам СУБД является не то, что СУБД не может что-то сделать, а то, что она может сделать слишком много, в том числе вещи, абсолютно ненужные данному приложению.
Например, очевидно, что библиотечная информационная система должна быть в состоянии обслуживать одновременно многих пользователей. Но эти пользователи почти всегда только читают информацию, а изменения данных происходят сравнительно редко и не обязательно на фоне продолжающегося оперативного доступа к данным. Конечно, требуется развитый механизм эффективно реализуемых запросов. Тем не менее, используемая СУБД будет включать общие средства управления транзакциями со всеми разновидностями блокировок. И это общая ситуация. Чем большими возможностями обладает СУБД, тем большему числу приложений не потребуется хотя бы часть этих возможностей. При этом сервер остается монолитом, стоит одних и тех же денег и требует для своего использования практически одни и те же ресурсы.
Существует много приложений, для которых средства, предоставляемые традиционными реляционными серверами баз данных, недостаточны. Основной характеристикой таких приложений является потребность в обработке сложноструктурированных объектов, для представления которых средствами реляционных систем требуется использование многочисленных таблиц, над которыми при выполнении приложения приходится выполнять операции соединения. Классическими примерами подобных приложений являются системы автоматизированного проектирования, системы поддержки принятия решений и т.д. Известно, что операция соединения является наиболее трудоемкой в реляционных системах. Время выполнения операции и количество требуемых операций возрастают нелинейно при увеличении размера и числа соединяемых таблиц. Кроме того, и для приложений этой категории часто не требуются все возможности, поддерживаемые сервером баз данных.
Таким образом, мы видим, что несмотря на наличие высокопроизводительных серверов реляционных баз данных, обладающих развитыми возможностями в соответствии с реляционным подходом, в мире информационных приложений существует определенная неудовлетворенность. Компании, производящие СУБД, ощущают эту неудовлетворенность, и чтобы не потерять рынок в будущем, пытаются придать своим продуктам новые качества.
8.1.3. Преобразование реляционного подхода к организации баз данных в объектно-реляционный подход