Студентам > Дипломные работы > Корпоративные сети
Корпоративные сетиСтраница: 12/12
Седьмой выпуск СУБД Oracle появился
на рынке в середине 1994 г. Это один из наиболее серьезных серверных продуктов,
предназначенных для управления реляционными базами данных. В OracleV.7
используется ряд новых архитектурных решений, направленных на повышение
эффективности сервера, в том числе буферизация откомпилированных SQL-операторов
на сервере баз данных, использование общего пула серверных процессов и нитей
для выполнения операторов SQL, поступающих от разных транзакций, использование
разнообразной статистической информации для оптимизации запросов и т.д.
Заметим, что именно в седьмой версии начался переход от использования
оптимизатора запросов, управляемого правилами, к применению более прогрессивной
техники оптимизации запросов на основе статистических оценок.
Существенно расширены возможности
использования языка PL/SQL. В OracleV.7 этот язык можно использовать для
определения триггеров, хранимых процедур, вызываемых сервером автоматически при
возникновении специфицированных событий (например, выполнении операций
модификации таблицы в целом или обновлении конкретной строки таблицы). Функции
PL/SQL могут вызываться как обычные встроенные функции в операторах SQL.
Заметим, что относительным, но существенным недостатком языка PL/SQL является
то, что он не входит в состав международного стандарта SQL, хотя многие его
свойства нашли отражение в вышедшем в этом году стандарте языка хранимых
модулей, являющемся частью будущего стандарта SQL-3.
В распределенном варианте OracleV.7
поддерживаются возможности репликации данных и имеется возможность асинхронного
вызова удаленных процедур.
Летом 1997 г. был объявлен выпуск
восьмой версии системы, которая должна обладать целым рядом новых возможностей:
встроенными средствами для использования в Internet/Intranet, поддержкой
хранения мультимедийной информации, приближением реализованного варианта языка
SQL к разрабатываемому стандарту языка SQL-3 и т.д. Поскольку эта версия
(Oracle 8.1) является переходной от реляционного к объектно-реляционному
подходу.
8.1.1.2. История и серверные
продукты компании Informix
24 сентября 1996 г. компания
Informix отметила десятилетие своей официальной деятельности. За эти годы
компания увеличила объем своих доходов в 33 раза и уверенно занимает второе
место на мировом рынке продуктов, связанных с управлением реляционными базами
данных. С самого начала своего существования компания ориентировалась на
создание серверов баз данных и сопутствующих программных продуктов,
функционирующих в среде ОС UNIX. В число основных стратегических партнеров
Informix входят компании Sequent, HewlettPaсkard, SunMicrosystems, IBM,
SiemensNixdorf, NCR, для продуктов которых в первую очередь обеспечиваются
новые работоспособные версии систем Informix. Помимо UNIX-платформ продукты
компании Informix могут работать в операционных средах DOS, NetWare, Windows и
WindowsNT.
Характерной особенностью компании
Informix является то, что она поддерживает, развивает и поставляет на рынок
целое семейство серверов, отличающихся возможностями, эффективностью и,
естественно, ценой. Все разновидности серверных продуктов Informix базируются
на архитектуре "клиент-сервер" (мы приведем краткий обзор наиболее
ярких представителей семейства).
Самым простым серверным продуктом
является сервер баз данных Informix-SE. Он предназначен для использования в
информационных системах со средним (или малым) объемом хранимой информации.
Хранение данных поддерживается на уровне файловой системы, и на этом же уровне
осуществляется синхронизация доступа со стороны параллельно выполняемых
транзакций. На самом деле, в Informix-SE для каждой пользовательской транзакции
образуется отдельный серверный процесс, и эти процессы взаимодействуют только
при доступе к общим файлам базы данных. (Заметим, что это сильно напоминает
организацию систем управления базами данных для персональных компьютеров.)
Клиент и сервер могут располагаться в одном компьютере, но могут быть и
разнесены на разные компьютеры, связанные сетью. Естественно, что при наличии
выделенной аппаратуры, поддерживающей деятельность сервера, общая эффективность
системы возрастает. Связь между клиентами и серверами поддерживается
специальным модулем Informix-NET.
Базовым продуктом компании Informix
является система Informix-OnLine, выпускаемая ныне в двух основных модификациях
- Informix-OnLineDynamicServer и Informix-OnLineExtendedParallelServer. Эти
серверы работают напрямую с дисковой памятью, обеспечивают выполнение
транзакций в распределенной среде баз данных, поддерживают возможности хранения
неструктурированных полей таблиц сверхбольшого размера (BLOBs -
BinaryLargeObjects) и т.д.
Informix-OnLineDynamicServer
ориентирован на применение симметричных мультипроцессорных компьютеров и
опирается на параллельное использование процессоров с общей основной памятью.
Поэтому в этом сервере широко используются приемы программирования, основанные
на использование параллельных потоков управления, или нитей.
Informix-OnLineExtendedParallelServer
может работать как в симметричных, так в несимметричных (sharingnothing)
компьютерных архитектурах. При использовании несимметричных архитектур
обещается наличие почти линейной масштабируемости.
В конце 1996 г. компания Informix
объявила о выпуске объектно-реляционного сервера InformixUniversalServer. Поскольку
этот продукт относится к новому поколению систем управления базами данных,
отложим его обсуждение до п.10.1.4.
Informix утверждает, что
особенностью стратегии компании является полное отсутствие конкуренции с любым
из своих потенциальных партнеров. В отличие от Oracle, Informix производит
только базовые продукты, не навязывая своей технологии разработки
информационных приложений (это мнение компании Informix, а не автора данного
раздела).
8.1.1.3. Серверные продукты
компании Sybase
Компания Sybase является
сравнительно новой на рынке конкурирующих производителей современных
реляционных СУБД. Это одновременно дает компании ряд преимуществ и усложняет ее
работу, хотя, несмотря на некоторые временные неудачи, продукты Sybase
находятся на третьем месте в мире по числу продаж. Преимущества компании
состоят в том, что она не настолько обремлена грузом предыдущих разработок и
необходимостью их постоянной поддержки. Преимуществом является и то, что Sybase
с меньшими потерями переходит к использованию новых архитектурных и
технологических решений. Усложняет же работу компании тот факт, что при выпуске
каждого очередного варианта сервера БД ей приходится решать множество новых
архитектурных и технологических проблем (никуда не денешься: если компания
провозглашает себя лидером в области архитектур и технологий серверов баз
данных, то она должна поддерживать марку).
До выпуска в 1994 г.
полномасштабного серверного продукта SybaseV.10 компания Sybase уверенно
зарекомендовала себя в качестве ведущего производителя современных СУБД для
применения в средних и малых информационных приложениях. Полностью основанная
на архитектуре "клиент-сервер" SybaseV.10 могла использоваться на
большинстве аппаратно-программных платформ: Sun, HP, IBMRS/6000, DigitalVAX/VMS,
DigitalAlphaOpenVMS и AlphaOSF, NCR, NEC, Sequent, SiliconGraphics, NetWare,
WindowsNT, OS/2, SCO и т.д. Архитектура SybaseV.10 обладала следующими
характерными чертами:
- компонентная
структура системы позволяла изменять отдельные компоненты, не нарушая
работу других компонентов;
- в
системе поддерживалось большинство принятых международных стандартов;
- поддерживалась
работа как с другими реляционными источниками данных, так и с источниками
данных унаследованных систем;
- обеспечивалась
простая переносимость системы;
- система
хорошо оптимизировалась для использования в данной предметной области,
поскольку отдельные функциональные компоненты могли настраиваться
независимо один от другого;
- гарантировалась
высокая надежность системы: изменения, вносимые в один компонент не влияли
на надежность других компонентов; были реализованы и расширены такие
средства стандарта языка SQL-92, как хранимые процедуры, триггеры,
средства поддержания ссылочной целостности, определяемые пользователем
типы данных и т.д.;
- поддерживалось
специфицированное X/Open управление распределенными транзакциями;
- были
реализованы возможности адаптации к национальному языку, включая
определения набора символов для выдачи сообщений, порядка сортировки и
т.д.; появилась возможность русскоязычной идентификации таблиц и их
столбцов.
В общем, по своим идеям система была
правильной. К сожалению, как это свойственно компаниям, имеющим серьезных
конкурентов, Sybase слишком поторопилась с выпуском на рынок SybaseV.10.
Система появилась на рынке не вполне отлаженной, и это привело к тому, что в
1995-1996 гг. многие потенциальные и реальные покупатели перестали иметь с ней
дело. Такого эффекта очень легко добиться, но его трудно устранить. В начале
1996 г. компания объявила о выпуске нового продукта, SybaseV.11.
В основной состав серверных
продуктов SybaseV.11 входит следующее:
- Базовый
сервер SybaseSQLServer - современная высокопроизводительная СУБД (более
подробно по поводу этого продукта см. ниже);
- SybaseMPP
- расширение архитектуры SybaseSQLServer, предназначенного для
эффективного использования в массивно параллельных компьютерных
архитектурах с поддержкой сверхбольших баз данных (VeryLargeDataBases -
VLDB);
- SybaseIQ
- серверное средство построения битовых индексов для высокоскоростного
выполнения запросов к большим источникам информации;
- SybaseSQLAnywhere
- полнофункциональная "облегченная" СУБД, приобретенная от
компании Watcom и предназначенная для производства индивидуальных и
групповых информационных систем на платформах Intel;
- SybaseReplicationServer
- серверный продукт, поддерживающий репликацию данных;
- SybaseOmniServer
- сервер, обеспечивающий "прозрачную" работу клиентов с
несколькими серверами баз данных, вообще говоря, различных производителей:
Sybase, Oracle, DB2 и т.д.
Имеется также ряд вспомогательных
серверных средств, поддерживающих динамическую (на фоне выполнения
производственных транзакций) загрузку и выгрузку данных, мониторинг действий
пользователей и т.д. Как видно, компания Sybase продолжает проводить свою линию
на компонентную организацию серверных средств. Далее мы обсудим только
возможности базового сервера SybaseSQLServer 11, не вдаваясь в детали
организации и возможностей дополнительных серверов (что было бы, кстати,
нечестно по отношению к конкурентам компании Sybase).
В соответствии с утверждениями
представителей компании Sybase, продукт SybaseSQLServer 11 обладает следующими
основными возможностями:
1. Масштабируемость и эффективность
SQLServer 11 основываются на тщательно проверенной технологии:
- сервер
может работать на большом числе платформ, начиная от персональных
компьютеров и заканчивая мощными мультипроцессорными серверами;
- на
каждой платформе обеспечивается очень высокая эффективность (без настройки
на конкретную платформу обойтись нельзя!) благодаря тесному взаимодействию
с производителями аппаратуры и базового программного обеспечения;
- в
ядре СУБД используется полностью симметричная многопотоковая архитектура,
позволяющая использовать возможности аппаратуры и поддерживающая большое
число пользователей.
2. SQLServer 11 обеспечивает
надежность хранения и целостность данных:
- поддерживаются
механизмы триггеров и хранимых процедур, декларативной ссылочной
целостности, управления транзакциями и т.д.;
- как
и полагается SQL-ориентированной СУБД, SQLServer 11 поддерживает уровень
безопасности данных C2 в соответствии с требованиями Оранжевой Книги
Министерства обороны США.
3. Обеспечивается повышенная
доступность данных:
- на
программном уровне поддерживаются зеркальные копии журнала и самой базы
данных;
- для
восстановления базы данных после сбоев применяются специально
разработанные механизмы высокоскоростной перезагрузки.
4. В SQLServer 11 обеспечивается
соответствие основным принятым формально или фактически стандартам:
- реализованный
в системе вариант языка SQL полностью соответствует стандарту SQL-89, а
также ядерному уровню (entrylevel) стандарта SQL-92;
- поддерживается
выполнение приложений, выполненных в стандартах ODBC и X/OpenXA;
- применяются
различные сетевые протоколы, что позволяет соединить клиента и сервера практически
на любой платформе.
5. Гарантируется простота управления
системой и ее поддержки:
- продуманная
многопотоковая архитектура системы обеспечивает то, что на
однопроцессорном компьютере запускается только один процесс сервера;
- при
использовании симметричной мультипроцессорной аппаратной организации можно
указывать количество процессоров, которые должны использоваться для целей
СУБД;
- можно
управлять распределением областей внешней памяти, контролировать доступ
пользователей к БД и т.д. в масштабах индивидуальной системы, масштабах
ограниченного предприятия или масштабах реальной корпоративной сети.
В целом, набор серверных продуктов
одиннадцатого выпуска компании Sybase представляет собой основательный, хорошо
продуманный комплект инструментов, которые можно с пользой применять в
разнообразных приложениях. По отзывам, которые успели поступить с момента
выпуска SybaseV.11, серверные средства работают достаточно надежно.
В сентябре 1997 г. компания Sybase
выпустила на рынок продукт под новым названием - SybaseAdaptiveServer, который
на самом деле является пятым выпуском версии 11. В этом продукте еще более
развита компонентная организация, улучшены возможности организации
распределенных баз данных, внедрены более развитые средства интеграции с
технологией Internet и т. д. Пока неизвестны какие-либо планы компании по
переходу к объектно-реля- ционным архитектурам.
8.1.1.4. Линия серверных
продуктов CA-OpenIngres компании ComputerAssociates
Проект и экспериментальный вариант
СУБД Ingres были разработаны в университете Беркли под руководством одного из
наиболее известных в мире ученых и специалистов в области баз данных Майкла
Стоунбрейкера (MichaelStonebraker). С самого начала СУБД Ingres разрабатывалась
как мобильная система, функционирующая в среде ОС UNIX. Первая версия Ingres
была рассчитана на 16-разрядные компьютеры и работала главным образом на
машинах серии PDP. Это была первая СУБД, распространяемая бесплатно для
использования в университетах. Впоследствии группа Стоунбрейкера перенесла
Ingres в среду ОС UNIXBSD, которая также была разработана в университете
Беркли. Семейство СУБД Ingres из университета Беркли принято называть
"университетской Ingres" (соответствующие программные продукты вместе
с исходными текстами и документацией до сих пор доступны в секторе
publicdomainInternet).
В начале 80-х была образована
компания RTI (RelationalTechnologyInc.) для сведения университетских прототипов
до уровня коммерческих продуктов. С этого момента стали различать
университетскую и коммерческую СУБД Ingres. В настоящее время коммерческая
Ingres поддерживается, развивается и продается компанией ComputerAssociates.
Сейчас это одна из наиболее развитых коммерческих реляционных СУБД.
Мы коснемся главным образом
особенностей базового серверного продукта компании ComputerAssociates линии
CA-OpenIngres - CA-OpenIngres/Server. Сервер базируется на следующих пяти
ключевых архитектурных принципах компании ComputerAssociates:
- использование
многопоточной и мультипроцессорной организации сервера для систем
оперативной обработки транзакций (OLTP - OnLineTransactionProcessing);
- применение
более развитых методов обработки данных для систем уровня OLAP
(OnLineAnalyticalProcessing);
- безопасное
и надежное управление данными информационных приложений;
- обеспечение
расширенных инструментальных средств администрирования серверной части
системы (это вообще конек компании; у них больше всего внимания обращается
на администрирование и управление систем);
- возможность
гибкой настройки сервера в соответствии с конкретными потребностями
корпорации.
Архитектура CA-OpenIngresServer
поддерживает совместное использование многочисленных серверов баз данных на
основе поддержки совместного буферного кэша, в котором хранятся данные,
объекты, откомпилированные запросы, хранимые процедуры и информация,
характеризующая состояние транзакций. Средства администрирования и управления
позволяют выделить некоторые серверы для целей оперативного управления
транзакциями, в то время как другие будут использоваться для генерации отчетов
с более низким приоритетом.
В соответствии с начальным подходом
Стоунбрейкера, в сервере поддерживается широкий набор допустимых способов
хранения данных: куча (heap), B-деревья, таблицы хеширования и т.д. Допускается
поддержание индексов с избыточными столбцами данных для эффективного выполнения
особо критичных запросов. Применяются способы сжатия таблиц и индексов.
При оптимизации запросов учитываются
разнообразные допустимые формы хранения. Используются истинные распределения
данных за счет динамического построения гистограмм распределения значений. Для
особо критических запросов поддерживаются административные способы оптимизации.
В соответствии с традициями Ingres в
CA-OpenIngres поддерживается встроенная система правил (расширенный вариант
более или менее известного механизма триггеров). Расширенные языковые
возможности определения правил позволяют решать на основе этого механизма не
только задачи поддержания целостности баз данных, но и полностью разрешать
производственные задачи.
В CA-OpenIngres поддерживаются стандарты
SQL-89 и ядерный уровень языка SQL-92. (Обратите внимание, что никто из ведущих
производителей не гарантирует полной совместимости с SQL-92. Это очень плохо,
поскольку уже на протяжении более чем 4 лет, ни одна компания не может или не
хочет произвести продукт, полностью соответствующий требованиям хорошего
международного стандарта. Правда, и стандарт несколько сложноват.)
Очень интересным направлением
развития линии CA-OpenIngres явилось приобретение японской
объектно-ориентированной СУБД Jasmin. Это оригинальная объектно-ориентированная
система, модель данных которой основывается одновременно на идеях Smalltalk и
Си++. Компания ComputerAssociates считает, что в принципе невозможно сочетать в
одной системе объектно-ориентированный и реляционный подходы (в частности,
отметим по-прежнему существующую проблему потери соответствия объектных и
реляционных операций, присущую объектно-реляционным системам).
Поэтому в ближайших планах компании
содержатся намерения одновременного поддержания объектно-ориентированного и
реляционного интерфейсов доступа к базам данных, среда хранения которых будет
поддерживаться OpenIngres. Сама же СУБД OpenIngres поддерживает возможности
шлюзования для доступа к унаследованным системам баз данных (в частности,
IDMS), что обеспечивает полную преемственность по отношению к ранее
разработанным и накопленным хранилищам данных. К сожалению, в текстах,
распространяемых компанией CA, содержится слишком мало технической информации
относительно Jasmin. Однако достоверно известно, что объектно-ориентированные
возможности управления данными широко используются в новом продукте компании,
предназначенном для управления и администрирования глобально распределенных
корпоративных приложений и называемом TNG (TheNextGenerationofUniCenter).
В июне 1997 г. компания CA объявила
о выпуске новой версии OpenIngres 2.0. Кроме улучшенных возможностей репликации
и наличия развитых средств интеграции с Internet, в OpenIngres появились
следующие новые возможности:
- использование
блокировок на уровне записи с возможностью выбора вида блокировок для
указанных таблиц или для указанных пользователей;
- поддержка
правил (триггеров) уровня оператора со срабатыванием правила для данного
оператора один раз независимо от числа затрагиваемых им строк;
- реализация
всех четырех уровней изоляции транзакций, специфицированных в стандарте
языка SQL (READCOMMITTED, REPEATABLEREAD, SERIALIZABLE и READUNCOMMITTED);
- наличие
средств параллельного копирования базы данных, хранимых на дисковых
накопителях с разными контроллерами;
- улучшенные
средства управления пространственными данными, включая индексацию на
основе R-деревьев;
- возможность
выбора размера страницы для хранения индивидуальной таблицы;
- более
строгая оптимизация на основе развитой статистической информации,
позволяющей, в частности, оценить размер результата соединения таблиц.
Кроме того, в версии 2.0 улучшены
средства визуального администрирования базы данных.
О конкретных работах, связанных с
интеграцией с объектно-ориентированной СУБД Jasmine, пока не сообщается.
8.1.1.5. Серверные продукты линии
DB2 компании IBM
Серьезные практические исследования
в области систем управления реляционными базами данных компания IBM начала с
проекта экспериментальной системы SystemR, которая разрабатывалась в
исследовательской лаборатории фирмы IBM в 1975-1979 г.г. Эта работа оказала
революционизирующее влияние на развитие теории и практики реляционных систем во
всем мире. Именно SystemR практически доказала жизнеспособность реляционного
подхода к управлению базами данных.
После успешного завершения работ по
созданию этой системы и получения экспериментальных результатов ее
использования был разработан целый ряд коммерчески доступных реляционных
систем, в том числе и на основе непосредственного развития SystemR (возможности
одной из коммерчески доступных реляционных систем - DB2 описываются в
переведенной на русский язык книге К. Дейта "Руководство по реляционной
СУБД DB2", хотя книга существенно отстала от практики; ее прекрасный
перевод на русский язык вышел в свет в 1988 г.). Исключительно важен опыт,
приобретенный при разработке этой системы. Практически во всех более поздних
реляционных СУБД в той или иной степени используются методы, примененные в
SystemR.
На наш взгляд, компания IBM много
потеряла, ориентируя DB2 только на использование своих аппаратно-программных
платформ. Первый вариант DB2 работал на IBM/370 в операционной среде OS/370. В
связи с развитием аппаратуры и программного обеспечения мейнфреймов система
была перенесена в операционную среду MVS. Программное обеспечение
специализированного аппаратно-программного комплекса AS/400 также во многом
основано на DB2. После разработки операционной системы OS/2 появился вариант
DB2, пригодный для использования на персональных компьютерах. СУБД DB2 всегда
представляла собой развитый программный продукт управления реляционными базами
данных. В ней всегда присутствовали, в частности, такие возможности как
управление транзакциями, журнализация изменений и восстановление согласованного
состояния базы данных после сбоев программного обеспечения и/или аппаратуры.
Заметим, что именно IBM выпустила первый корпоративный стандарт языка SQL.
Развитие системы и сферы ее
применений ограничивало то, что отсутствовал мобильный текст системы.
Ориентируясь на использование DB2 на своих аппаратных платформах, компания IBM
исторически использовала для программирования DB2 смесь языка ассемблера и
языка PL/1. Прорывом как для DB2, так и для IBM в целом стало появление
Unix-ориентированной серии серверов и рабочих станций RS/6000. Именно при создании
варианта системы DB2/6000 компания была вынуждена переписать систему на языке
Си. После этого появилась очевидная возможность простого переноса СУБД на
другие аппаратные платформы. В последнее время IBM объявила выпуск DB2 для
аппаратно-программных платформ Sun и HP. По мнению автора курса, этот шаг
означает появление на рынке независимых серверных продуктов управления
реляционными базами данных очень серьезного и достойного конкурента. Коротко
охарактеризуем основные возможности наиболее распространенной в настоящее время
версии DB2 Version 2:
1. Возможности, соответствующие
требованиям реляционной модели данных:
- Поддерживаются
почти соответствующие полному стандарту SQL-92 средства обеспечения
ссылочной целостности. Для таблицы-предка можно объявить правила удаления
строк Restrict, NoAction, Cascade или SetNulls, в соответствии с которыми
будут обрабатываться соответствующие строки таблицы-потомка. (При
применении правила Restrict будет запрещено удаление строки
таблицы-предка, если на эту строку ссылается хотя бы одна строка
таблицы-потомка; задание правила Cascade приводит к автоматическому
удалению ссылающихся строк таблицы-потомка; при указании правила SetNulls
в поле ссылки ссылающихся строк автоматически устанавливаются
неопределенные значения; правило NoAction, которое действует подобно
правилу Restricted, но с другим диагностическим сообщением,
устанавливается при определении ограничений ссылочной целостности по
умолчанию).
- Возможно
определение пользователем значений полей таблицы по умолчанию. Вообще-то
эта возможность определена в SQL-92, и ее реализация не доставляет особого
труда, но тем не менее в большинстве систем такая возможность отсутствует.
- Наконец-то
реализовано средство, задаваемое фразой WITHCHECKOPTION при определении
представления. При указании такого требования становится невозможным
занести строку в представляемую таблицу или изменить существующую строку
таким образом, чтобы полученная строка не была видима через представление.
2. Объекты базы данных:
- Помимо
стандартных типов данных DB2 допускает хранение BLOBs размером до 2 Гб.
Соответствующие поля предназначены для сохранения мультимедийной
информации, структура которой известна только приложению.
- Поддерживается
развитый механизм триггеров с возможностью указания степени гранулированности
триггера, например, должно ли срабатывать заданное действие один раз при
выполнении операции строки из заданной таблицы, или его следует выполнять
для каждой удаляемой строки.
- Обеспечивается
механизм хранимых процедур, которые программируются на смеси языков SQL и
одного из процедурных языков третьего поколения.
3. Возможности запросов:
- Реализованная
версия языка SQL является расширенным множеством ядерного уровня языка
SQL-92 и включает ряд конструкций, наличие которых предполагается в SQL-3.
- Поддерживаются
все разновидности соединений, определенные в SQL-92, но синтаксис
соответствующих конструкций отличается от стандартного.
4. Поддержка доступа из Internet:
- Специальный
шлюз, встроенный в сервер, обеспечивает доступ к данным DB2, транслируя
команды HTML в операторы языка SQL.
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:
- в
ядре сервера может выполняться несколько нитей, что позволяет эффективно
использовать симметричные мультипроцессорные компьютеры (SMP -
SymmetricMultiprocessorProcessors);
- поддерживается
асинхронное выполнение обменов с несколькими дисковыми устройствами;
- обеспечивается
параллельное выполнение пользовательских транзакций, операций построения
индексов и загрузки данных, а также резервного копирования;
- при
оптимизации запросов используется статистическая информация;
- для
синхронизации параллельного доступа применяется механизм блокировок на
уровне записи с автоматическим распознаванием и разрешением тупиковых
ситуаций;
- поддерживается
автоматическая репликация данных на основе журнальной информации или
мгновенных снимков, включая доступность репликации в базы данных,
доступные через интерфейс ODBC, и репликации "массивных" данных
(типов TEXT и IMAGE);
- обеспечивается
двухфазная фиксация распределенных транзакций;
- реализованы
операции CUBE и ROLLUP для работы с многомерными данными в системах
оперативной аналитической обработки (OnLineAnalyticalProcessing - OLAP);
- доступны
средства интеграции с системами электронной почты, в частности, с
MicrosoftExchangeServer;
- имеются
средства, обеспечивающие доступ к SQL-серверу из Web-серверов и
формирование результатов запросов в формате HTML (WebConnector и WebAssistant);
- развиты
возможности администрирования баз данных: SQLEnterpriseManager позволяет с
одного терминала управлять произвольным числом SQL-серверов;
дополнительные административные процедуры могут разрабатываться на
VisualBasic со встроенным SQL;
- реализован
входной уровень стандарта SQL-92 и важные компоненты промежуточного
уровня;
- можно
использовать национальные символы, в том числе символы русского языка.
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. Преобразование
реляционного подхода к организации баз данных в объектно-реляционный подход
Мы уже отмечали в начале этого
раздела, что радикальным решением всех проблем, свойственных реляционным
системам, был бы революционный переход к объектно-ориентирован- ной организации
как баз данных, так и систем управления ими. Мы перечислили ряд причин, по
которым массовых потребителей баз данных не устроила эта возможная революция.
Но дело не только в этом. В конце 1989 г. группа ведущих специалистов в области
объектно-ори- ентированных баз данных опубликовала "Манифест
объектно-ориентированных баз данных" (перевод на русский язык опубликован
в журнале "СУБД", N 4, 1995 г.).
В этом манифесте утверждается, что
современная ситуация с ООБД напоминает ситуацию с реляционными системами
середины 1970-х гг. При наличии большого количества экспериментальных проектов
(и коммерческих систем) отсутствует общепринятая объектно-ориенти- рованная
модель данных, и не потому, что нет ни одной разработанной полной модели, а по
причине отсутствия общего согласия о принятии какой-либо модели. На самом деле,
имеются и более конкретные проблемы, связанные с разработкой декларативных
языков запросов, выполнением и оптимизацией запросов, формулированием и
поддержанием ограничений целостности, синхронизацией доступа и управлением
транзакциями и т.д.
Объектно-реляционный подход возник
как эволюционная альтернатива революционному объектно-ориентированному подходу.
Заметим, что термин "объектно-реляционные СУБД" вошел в обиход далеко
не сразу, и даже сейчас системы соответствующего класса часто характеризуются
другими терминами. Точкой отсчета можно считать опубликование в 1990 г.
"Манифеста систем баз данных третьего поколения" (перевод на русский
язык опубликован в журнале "СУБД", N 2, 1995 г.). В этом манифесте
выдвигалась идея и обосновывались преимущества эволюционного развития
возможностей СУБД без коренной ломки предыдущих подходов и с сохранением
преемственности с системами предыдущего поколения. Частично требования к системам
следующего поколения включали просто необходимость реализации давно известных
свойств, которые отсутствовали в большинстве текущих реляционных СУБД
(ограничения целостности общего вида, триггеры, модификация БД через
представления и т.д.). В число новых требований входили полнота системы типов,
поддерживаемых в СУБД; поддержка иерархии и наследования типов; возможность
управления сложными объектами и т.д.
Другим термином, используемым по
отношению к СУБД третьего поколения является термин "расширяемые
СУБД". Под этим словосочетанием понимается то, что компания-производи-
тель поставляет некоторый базовый остов системы, функции которой в дальнейшем
могут на- ращиваться сторонними компаниями или даже пользователями.
Термин "объектно-реляционная
СУБД" был внедрен в обиход Майклом Стоунбрейкером, идейным руководителем
проектов свободно распространяемых систем Ingres и Postgres и основателем
компании Illustra, выпустившей одноименный коммерческий продукт. (На самом
деле, система Illustra является хорошо отлаженным и документированным вариантом
Postgres). В Postgres были реализованы многие интересные средства, свойственные
системам третьего поколения: поддерживалась темпоральная модель хранения и
доступа к данным и в связи с этим был абсолютно пересмотрен механизм
журнализации изменений, откатов транзакций и восстановления БД после сбоев;
обеспечивался мощный механизм ограничений целостности; имелась возможность
хранения в столбцах таблицы вложенных таблиц. Допускалось хранение в полях
таблицы данных абстрактных, определяемых пользователями типов, что обеспечивало
возможность внедрения в базу данных поведенческого аспекта.
Наконец, ведущие
компании-производители СУБД стали использовать для идентификации своих
серверных продуктов нового поколения термин "универсальный сервер",
имея в виду, что в этих продуктах используется объектно-реляционный подход, а
также обеспечиваются возможности расширяемости, интеграции с Internet и т.д.
8.1.4. Первые серверные продукты,
поддерживающие объектно-реляционный подход
С конца 1996 г. три компании
объявили о выпуске серверных продуктов, соответствующих названию
"универсальный сервер": Oracle с продуктом Oracle 8, Informix с
продуктом InformixUniversalServer и IBM с продуктом DB2 UniversalDatabase.
Далее мы приведем краткие характеристики этих систем.
8.1.4.1. Oracle 8
Компания Oracle заявляла, что Oracle
8 будет уметь делать с объектами все, что умеет делать InformixUniversalServer,
и даже больше. Однако это не так в первом выпуске Oracle 8 (этот выпуск был
официально объявлен 24 июня 1997 г.). В фокусе Oracle 8 находятся расширенная
система типов и поддержка бизнес-объектов; появление других возможностей
расширяемости ожидается в версии 8.1. Oracle концентрируется на реализации
своей сетевой вычислительной архитектуры (NCA - NetworkComputingArchitecture),
и в Oracle 8 вносятся улучшенные возможности производительности,
масштабируемости, доступности, репликации, разделения дан- ных и т.д.
NCA - это трехзвенная архитектурная
структура, основанная на CORBA (CommonObjectRequestBrokerArchitecture - Общая
архитектура брокера объектных заявок). В NCA используются расширяющие
компоненты, называемые "картриджами", которые могут разрабатываться
Oracle или сторонними поставщиками. Впервые использование картриджей приложений
и картриджей баз данных потребовалось в OracleWebApplicationServer для
организации связи на основе CORBA. В контексте расширяемой среды данных Oracle
обеспечивает компоненты на уровне промежуточного программного обеспечения
приложений (например, компонент управления транзакциями в WebApplicationServer)
и на уровне универсального сервера (Oracle 8). На объектном уровне Oracle 8
поддерживает объектные представления данных с использованием новых объектных
типов и существующих реляционных данных. Кроме того, Oracle 8 поддерживает
объектный кэш на стороне клиентов и навигацию между объектами по ссылкам.
Транслятор объектных типов отображает объекты базы данных в соответствующие
конструкции языка Си.
Далее приводится сводка свойств,
имеющихся в Oracle 8 и ожидаемых в версии 8.1:
- Расширяемая
система типов. Поддерживаются объектные типы, типы коллекций (массивы
переменного размера и вложенные таблицы) и ссылочные типы. Объектный тип
может применяться либо к столбцу, либо к строке и может быть семантически
эквивалентен именованному строчному типу SQL-3. Кроме того, Oracle 8 явно
связывает с объектными типами методы. Пока поддерживается только один
уровень вложенности таблиц (в 8.0) и не реализована полная инкапсуляция
определяемых пользователями типов данных. В версии 8.1 будет поддерживаться
одиночное наследование. Не предполагается возможность репликации
расширенных данных.
- Определяемые
пользователями функции. Скалярные функции, перегрузка и разрешение имени
на основе типов параметров, параллельное выполнение функций с определенными
пользователями агрегатами (функции столбцов) находятся в стадии
обсуждения.
- Расширяемая
система индексации. Поддержка определяемых пользователями индексных
структур и индексов на выражениях появится вместе с компонентом
DatabaseExtensibilityServices.
- Расширяемый
оптимизатор. Возможность указывать стоимость выполнения определенных
пользователями функций и обеспечивать статистику об использовании
определенных пользователями данных ожидается с появлением компонента
DatabaseExtensibilityServices. К расширенным типам пока не применяются
параллельные операции.
- Большие
объекты и внешние данные. LOB могут храниться внутри базы данных или во
внешних файлах. Oracle 8 не поддерживает доступа по записи к внешним
данным и не гарантирует их целостность. Большие объекты могут быть
реплицированы, но таблицы с LOB реплицировать нельзя.
- Расширяемая
языковая поддержка. Определяемые пользователями типы данных и хранимые
процедуры пишутся на PL/SQL или Си/Си++, причем подпрограммы на Си/Си++
выполняются вне адресного пространства сервера. Поддержка Java в сервере
будет обеспечиваться в DatabaseExtensibilityServices (версия 8.1).
- Предопределенные
расширения. Сервер Oracle 8 поддерживает хранение текстовых,
пространственных и видео данных; ожидается появление нового типа данных
для хранения графической информации. Компания работает также с несколькими
партнерами для тестирования и формализации API для
DatabaseExtensibilityServices и разработки картриджей данных.
Как видно, в Oracle 8 компания
главным образом сосредоточилась на реализации собственных расширений, которых
может оказаться достаточно для начала моделирования бизнес-объектов.
Возможности реализации расширений сторонними компаниями менее развиты, чем в
продуктах Informix и IBM. Это означает, что пользователи Oracle будут вынуждены
более долго ожидать наличия полных наборов строительных блоков для построения
новых или улучшения существующих приложений. С другой стороны, развитие
продуктов Oracle происходит на основе единой архитектуры NCA, которая
закладывает базу расширяемости.
8.1.4.2. InformixUniversalServer
Компания InformixSoftware приобрела
реальные шансы стать лидером сектора объектно-реляционных систем после
приобретения компании Illustra в начале 1996 г. (Заметим, что сотрудниками
компании стали все основные разработчики СУБД Illustra, включая
М.Стоунбрейкера.) Многие авторитетные специалисты компьютерной индустрии
скептически относились к решению компании произвести слияние продуктов
Informix-OnLine 7.2 и IllustraServer к концу того же года. Однако компания
Informix действительно смогла выпустить в конце декабря устойчивую версию
InformixUniversalServer, работающую на трех платформах. К лету 1997 г.
UniversalServer был доступен на 10 платформах.
Компания сконцентрировалась прежде
всего на общей архитектуре универсального сервера. Внимание обращается на
средства, обеспечивающие интеграцию с технологией Internet/Web (с применением
продукта WebConnect). Затрагиваются вопросы поддержки сложных данных в
средствах разработки и приложениях с использованием недавно объявленного
продукта DataDirector (приобретенного вместе с компанией CenterViewSoftware в
начале этого года). Этот продукт обеспечивает возможность использования
развитых сред разработки (Java, PowerBuilder, VisualBasic и др.), доступ к
расширениям в духе SQL-3 и, кроме того, доступ к новым типам данных и функциям
UniversalServer.
В своем первом выпуске
UniversalServer объединяет средства сервера InformixOnLine 7.2 с расширениями,
обеспечиваемыми механизмом DataBlade сервера, и языковыми расширениями, основанными
на идеях SQL-3. Новые возможности включают следующее:
- Расширяемую
систему типов для интеграции определяемых пользователями типов данных,
уточненных типов, абстрактных типов данных, строчных типов и типов
коллекций, включая возможность неограниченной вложенности таблиц.
Поддерживается простое наследование в иерархии именованных строчных типов.
Каждая таблица, основанная на строчном типе, становится типизированной
таблицей и может использоваться в этой иерархии. В будущем ожидается
появление ссылочных типов и абстрактных типов данных в стиле SQL-3, а
также средств репликации данных определяемых пользователями типов.
- Определяемые
пользователями функции - полный диапазон типов функций с поддержкой
перегрузки, распознавания нужного тела функции на основе типов параметров
и параллельного выполнения функций, когда это оправдано. (Параллельные
возможности UniversalServer применимы на симметричных мультипроцессорных
платформах; при использовании расширенной параллельной версии
InformixOnLine эти возможности распространяются на кластерные архитектуры;
на массивно-параллельных платформах объектные расширения пока недоступны.)
- Расширяемую
систему индексирования - R-деревья, применение индексов на основе
B-деревьев к определяемым пользователями типам данных, определяемые
пользователями индексные структуры.
- Расширяемый
оптимизатор - таблично-управляемый оптимизатор, позволяющий интегрировать
определяемые пользователями типы данных, новые индексные структуры и новые
методы доступа. Разработчик может указать стоимость выполнения функций
определяемого им типа и зарегистрировать новый тип индекса, что включает
определение функций, которые используют индекс, интерфейсных подпрограмм
для доступа к индексу и стоимости использования индекса. Индексы хранятся
под управлением СУБД с соответствующим транзакционным управлением;
сторонние поставщики должны сами следить за целостностью внешних индексов.
Кроме того, оптимизатор применяет параллельные операции к разделенным
данным и индексам.
- Возможность
хранения больших объектов (LOB - LargeObjects) внутри базы данных или во
внешних файлах. Пока UniversalServer не гарантирует целостность данных,
хранимых во внешних файлах, но Informix имеет на этот счет планы.
Интерфейс виртуальной таблицы позволяет регистрировать внешние данные в
каталогах базы данных и обращаться к ним таким же образом как если бы они
были таблицами, непосредственно поддерживаемыми универсальным сервером.
- Наличие
предопределенных расширений: Informix подрядил много сторонних поставщиков
для написания DataBlades - упакованных наборов расширений, относящихся к
некоторым прикладным областям (текстовому поиску, управлению графической
информацией, финансовому анализу и т.д.). DataBlade интегрируется с ядром
IUS на основе специального интерфейса уровня вызовов (DataBladeAPI). К
июню 1997 г. планировалось иметь в поставке 20 DataBlade, еще 10 находятся
в стадии бета-тестирования, к концу года ожидается иметь около 50 готовых
к поставке DataBlade. В настоящее время имеется два режима выполнения
DataBlade - в адресном пространстве ядра (это дает наибольшую
эффективность) и в отдельном виртуальном процессоре (более безопасный
режим).
- Расширенный
набор языков приложений - в дополнение к поддержке разработки
пользовательских типов данных на основе собственной среды NewEraInformix
теперь обеспечивает новое средство разработки клиентских приложений
DataDirector, которое дает возможность связи между данными,
контролируемыми приложением, и данными, хранимыми в среде UniversalServer.
В этом средстве используются собственные интерфейсы с универсальным
сервером (JavaAPI и Си++ API), а не ODBC. Кроме того, DataDirector
поддерживает языковые расширения в духе SQL-3.
Одной из проблем компании Informix,
связанной с форсированным внедрением объектно-реляционных средств, является
сохранение позиции на бизнес-рынке, которую компании удалось занять на основе
InformixOnLine 7.x. До слияния с Illustra основное внимание уделялось
производительности и масштабируемости на основе разных видов параллелизма, и
именно это определяло лицо Informix на рынке. С появлением UniversalServer эти
важные качества продуктов отошли на второй план. Кроме того, компания должна
принимать во внимание наличие трех разных серверов баз данных -
UniversalServer, OnLine и ExtendedParallelServer.
Однако компании первой удалось
продемонстрировать возможность эволюционного перехода к объектно-реляционной
технологии с сохранением надежного и высокоэффективного управления базами
данных. UniversalServer является развитием OnLine, и именно так следует
представлять его на рынке.
8.1.4.3. IBMDB2 UniversalDatabase
Компания IBM ведет исследования в
области инфраструктуры расширяемых реляционных баз данных в течение более чем
десяти лет. Компания была первой из основных поставщиков, выпустившим на рынок
реляционный сервер баз данных с объектными расширениями: DB2 CommonServer 2 (в
июле 1995 г.). Теперь IBM готова начать поставки обновленного продукта с новым
названием - DB2 UniversalDatabase, представляющего собой слияние начальных
объектно-реляционных свойств DB2 CommonServer 2.1 с возможностями параллельной
обработки DB2 ParallelEdition 1.2 и доступного на разнообразных
мультипроцессорных платформах (симметричных, кластерных и
массивно-параллельных). Ключевым моментом является то, что продукты IBM
основаны на едином исходном тексте сервера. Это обеспечивает основу новых
разработок, тем более что расширения с самого начала базируются на полностью
параллельных средах.
Стратегия IBM в области
объектно-реляционных баз данных включает четыре основных компонента. Во-первых,
универсальная база данных DB2 (UniversalDatabase) находится в стадии
бета-тестирования и должна начать поставляться в третьем квартале 1997 г.
Во-вторых, разновидность определяемых пользователями типов данных - сильные
связи с файлами (robustfilelinks) позволяет DB2 UniversalDatabase активно
управлять внешне хранимыми данными с соблюдением требований безопасности и
целостности. Реализация этой возможности ожидается к концу 1997 г. Третий
компонент стратегии компании - DataJoiner - промежуточное программное обеспечение
для доступа к неоднородным базам данных. Этот компонент включает все
функциональные возможности сервера DB2, глобальный оптимизатор с расширяемыми
знаниями о поддерживаемых источниках данных, возможность компенсировать
функциональные различия между этими источниками. В планы компании входит
расширение возможностей DataJoiner для работы с объектно-реляционными
расширениями. Наконец, IBM разрабатывает компонент объектного слоя, называемый
ClientObjectSupport, который обеспечит единое логическое представление всех
доступных данных, а также их транзакционную согласованность, управление кэшами
клиентов и интеграцию с объектно-ориентированными языками.
Вот сводка расширенных возможностей
DB2 UniversalDatabase и средств, которые планируется включить в будущие выпуски:
|
Главная
Документация
Файлы
Информация
