Корпоративные сети

применяется, так называемый, метод позднего связывания, означающий, по сути

дела, интерпретационный режим выполнения программы с распознаванием деталей

реализации объекта во время выполнения посылки сообщения к нему. Введение

некоторых ограничений на способ определения подклассов позволяет добиться

эффективной реализации без потребностей в интерпретации.

Видимо, наиболее важным новым качеством ООБД, которое позволяет достичь

объектно-ориентированный подход, является поведенческий аспект объектов. В

прикладных информационных системах, основывавшихся на БД с традиционной

организацией (вплоть до тех, которые базировались на семантических моделях

данных), существовал принципиальный разрыв между структурной и

поведенческой частями. Структурная часть системы поддерживалась всем

аппаратом БД, ее можно было моделировать, верифицировать и т.д., а

поведенческая часть создавалась изолированно. В частности, отсутствовали

формальный аппарат и системная поддержка совместного моделирования и

гарантирования согласованности этих структурной (статической) и

поведенческой (динамической) частей. В среде ООБД проектирование,

разработка и сопровождение прикладной системы становится процессом, в

котором интегрируются структурный и поведенческий аспекты. Конечно, для

этого нужны специальные языки, позволяющие определять объекты и создавать

на их основе прикладную систему.

С точки зрения разработчиков информационных систем подход OOБД кажется

очень заманчивым. Более того, на рынке программных продуктов управления

базами данных сегодня существует около двух десятков коммерческих систем,

которые более или менее успешно продаются (примерами таких систем являются

O2 компании O2 Technology (www.o2tech.com), ObjectStore компании

ObjectDesignInc., (www.odi.com), Objectivity/DB компании Objectivity, Inc.,

Versant компании VersantObjectTechnology (www.versant.com), ONTOSDB

компании ONTOS, Inc., (www.ontos.com) и т.д.). Во всех этих системах

поддерживается возможность распределенного хранения баз данных; имеется

возможность написания приложений и/или методов объектов на одном или

нескольких языках объектно-ориентированного программирования (как правило,

в минимальный набор языков входят Си++ и Java); обеспечиваются удобные

средства доступа к базам данных в среде Internet и т.д. Тем не менее,

объектно-ориентированные системы оказались не в состоянии конкурировать с

реляционными системами, поставляемыми ведущей шестеркой поставщиков

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

Прежде чем перейти к краткому обзору современных продуктов ведущих

компаний, попробуем понять, почему же большинство заказчиков предпочитает

использовать именно эти продукты, а не объектно-ориентированные СУБД. Мы

можем привести несколько соображений, некоторые из которых являются в

большей степени эмоциональными, а другие - чисто техническими. Во-первых,

компьютерное сообщество уже пережило техническую революцию при переходе от

дореляционных СУБД к реляционным. Как и любая революция, эта техническая

революция была пережита непросто. Хотя и очень простые, идеи реляционного

подхода воспринимались широкими массами пользователей и разработчиков

информационных систем на протяжении нескольких лет. Переход к новым

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

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

результате, конечно, были получены более качественные продукты, но

одновременно с этим обострилась известная проблема "унаследованных"

("legacy") систем, которые являются морально устаревшими, плохо

сопровождаемыми, но необходимыми для успешного функционирования

предприятия. Переход к объектно-ориентированной технологии баз данных

означал бы новую революцию. Потребовалась бы качественная, основанная на

иных понятиях переделка прикладного программного обеспечения. Естественно,

это отпугнуло пользователей и разработчиков от объектно-ориентированных баз

данных.

Во-вторых, любая развитая система управления базами данных является

предельно сложным программным продуктом, для эффективной реализации

которого требуется привлечение правильным образом разработанного или

выбранного из числа готовых набора методов, алгоритмов, протоколов и

структур данных. Кроме того, для достижения должного уровня эффективности

СУБД должна пройти длительный процесс отладки, обкатки и настройки. Ведущие

производители реляционных СУБД в той или иной степени успешно решили эти

проблемы за счет больших денежных и временных затрат. Конечно, сегодня

невозможно говорить о какой-либо объектно-ориентированной СУБД, которая

была бы настолько же хорошо отлажена и настроена, которая могла настолько

же эффективно обрабатывать большие объемы данных, как продукты ведущей

шестерки.

В-третьих, одним из основных преимуществ реляционного подхода по отношению

к дореляционным системам является наличие ненавигационного интерфейса

доступа к базам данных. Отсутствие явной навигации в базе данных позволяет

освободить прикладную программу от технических деталей ассемблерного уровня

(можно проводить аналогию между явным переходом по ссылке в структуре

внешних данных и безусловным переходом в языках уровня ассемблера), а также

дает возможность более эффективного по сравнению с ручным выполнения

операций доступа к данным (когда способ выполнения непроцедурно заданного

оператора выбирается в компиляторе соответствующего языка, то используется

гораздо больший объем знаний, чем тот, которым располагает отдельно взятый

человек). Отрицательным свойством ненавигационного, основанного на

манипуляциях с таблицами способа доступа к базам данных является так

называемая потеря соответствия (impedancemismatch) языков программирования

и языков баз данных. Классические, наиболее используемые на практике языки

программирования ориентированы на работу с атомарными значениями встроенных

типов данных. Даже если в языке содержатся средства определения массивных

типов данных (структур, массивов, множеств, списков и т.д.), то перед

выполнением любой обрабатывающей операции необходимо выбрать атомарный

элемент соответствующего массивного типа. Языки реляционных баз данных

ориентированы на работу с таблицами: операндами любой операции являются

таблицы, и в результате выполнения операции формируется новая таблица.

Фактически, языки программирования и языки реляционных баз данных

ортогональны:

[pic]

Рис. 8.1. Ортогональность языков программирования и языков баз данных

То, что предлагается в языке SQL относительно возможности встраивания его

конструкций в традиционный язык программирования - это попытка сгладить эту

ортогональность. (Имеются в виду средства встраиваемого SQL для

развертывания операций обработки результата запроса к базе данных в

последовательность или цикл обработки ее строк.)

[pic]

Рис. 8.2. Сглаживание ортогональности средствами языка SQL

Одной из задач, которую ставили перед собой разработчики подхода ООБД,

состояла в том, чтобы добиться отсутствия потери соответствия между языками

объектно-ориентированного программирования и языками объектно-

ориентированных баз данных. Идеалом представлялось то, чтобы один и тот же

язык использовался и для программирования приложений (и написания методов

объектов), и для обеспечения доступа к базе данных. Поскольку природа

объектно-ориентированных языков не изменилась по сравнению с их

предшественниками, средства доступа к базе данных естественно стали снова

навигационными. Конечно, это другой уровень навигации с использованием

логических ссылок, но навигация есть навигация - за одно обращение к базе

данных можно получить возможность работы с одним объектом. Естественно, и

это отпугнуло разработчиков и пользователей.

Заметим, что в последнее время ситуация изменилась. В результате

деятельности международного консорциума ObjectDatabaseManagementGroup

(ODMG) был выработан стандарт языка запросов (OQL - ObjectQueryLanguage) к

ООБД (в июле 1997 г. опубликована его вторая версия). Этот язык

ненавигационный и синтаксически близок к языку SQL. Но для текущего

поколения объектно-ориентированных СУБД язык OQL появился слишком поздно, и

с этим связана вторая причина неудачи объектно-ориентированных СУБД на

рынке.

До возникновения стандартов ODMG существовало столько же разных

представлений о природе ООБД, сколько разных соответствующих продуктов.

Если реляционные системы с самого начала основывались на одной и достаточно

точной модели, то для ООБД такой общей модели не было вообще. Все попытки

создать такую модель требовали привлечения весьма трудного математического

аппарата, обычно непонятного даже профессиональным математикам. Группа

ODMG, включающая всех основных поставщиков объектно-ориентированных СУБД,

смогла предложить общую объектную модель баз данных, но и эта модель

появилась слишком поздно, а кроме того, она слишком неточна и является

результатом многочисленных компромиссов. Естественно, необоснованные

теоретически объектно-ориентированные СУБД не могли вызвать слишком

большого доверия.

Повторим, что ситуация меняется. Если раньше между ODMG и сообществом

реляционных баз данных (в частности, комитетом по стандартизации языка SQL)

существовали принципиальные разногласия, то сегодня обе стороны стремятся к

сближению позиций. Тем не менее, на сегодняшний день рынок объектно-

ориентированных систем по крайней мере на порядок уже рынка реляционных

систем и, возможно, еще более сузится в связи с возникновением нового

сектора коммерческих объектно-реляционных систем, поставку которых начинают

ведущие компании.

8.1.1. Обзор современного состояния рынка серверов баз данных

Естественно, мы не можем в этом подразделе достаточно детально представить

даже наиболее известных производителей серверных продуктов реляционных баз

данных и собственно эти продукты. Это связано и с тем, что по поводу каждой

компании можно сказать очень много, и с тем, что серверные продукты

управления базами данных являются, по всей видимости наиболее сложными

программными продуктами, присутствующими на рынке, и с тем, что компании-

производители серверных продуктов очень не любят открывать технические

детали реализации (это считается частью "know-how" компании). Мы

постараемся охарактеризовать деятельность и продукты ведущей шестерки

производителей (компаний Oracle (www.oracle.com), Informix

(www.informix.com), Sybase (www.sybase.com), ComputerAssociates

(www.cai.com), IBM (www.ibm.com) и Microsoft (www.microsoft.com)), касаясь

только особенностей серверов баз данных и не затрагивая возможности

громадного числа сопутствующих программных продуктов. Кроме того, мы не

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

обладают оригинальными и специфическими возможностями.

8.1.1.1. История и серверные продукты компании Oracle

Первая доступная заказчикам версия СУБД Oracle (OracleV.2) была выпущена

компанией RelationalSoftwareInc. в 1979 г. Эта версия была ориентирована на

использование в среде ОС RSX-11 для семейства миникомпьютеров PDP-11.

Система была написана большей частью на языке ассемблера PDP-11, но

включала также тексты на новом для того времени языке Си. СУБД могла

функционировать не только в среде ОС RSX-11, но и в других операционных

средах, поддерживаемых на PDP-11: IAS, RSTS и UNIX. Тогда же было принято

решение о переносе Oracle в 32-разрядную операционную среду VAXVMS, что на

долгие годы определило судьбу СУБД Oracle как ведущей системы управления

базами данных на миникомпьютерах.

Наиболее сильное впечатление на пользователей Oracle производила

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

реляционного языка SQL, для которого в то время существовал только

фирменный стандарт компании IBM. СУБД OracleV.2 обладала ограниченными

возможностями; в частности, в системе отсутствовали средства управления

транзакциями, что заставляло пользователей постоянно прибегать к

использованию утомительной процедуры резервного копирования.

СУБД OracleV.3 была выпущена в свет в 1983 г. Она была полностью переписана

на языке программирования Си, что в дальнейшем позволило решить проблему

переноса системы на большое число аппаратно-программных платформ. Функции,

доступные через SQL-интерфейс, были расширены. В обиход пользователей

системы было введено понятие транзакции. В это же время компания

RelationalSoftwareInc. была переименована в OracleCorp.

В 1985 г. на рынке появилась СУБД OracleV.5. В этой системе использовалась

архитектура "клиент-сервер" и впервые появилась (ограниченная) возможность

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

Шестая версия системы представляла из себя инструмент построения

корпоративных информационных приложений, выполняющихся в режиме OLTP. В

системе были реализованы система блокировок на уровне записей (заметим, что

хотя этот уровень блокировок кажется наиболее естественным, переход к его

использованию происходил и происходит непросто; в частности, в очень

развитых последних по времени продуктах компании Sybase до сих пор

используются блокировки на уровне страниц), а также механизм

непротиворечивых чтений из базы данных без потребности блокировок (это

легко реализуемое оригинальное изобретение Oracle пока не воспроизведено в

продуктах других компаний и, естественно, не стандартизовано). СУБД

OracleV.6 была перенесена на ряд новых платформ, в том числе, OS/2 и

Macintosh.

Важными нововведениями шестой версии было появление процедурного языка

программирования PL/SQL, который можно было использовать как для

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

приложений в составе языка четвертого поколения SQL*Forms. Кроме того, в

реализованном варианте языка SQL появились средства определения ссылочной

целостности (referenceintegrity), одного из наиболее фундаментальных

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

Седьмой выпуск СУБД 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 для каждой пользовательской транзакции образуется отдельный

серверный процесс, и эти процессы взаимодействуют только при доступе к

общим файлам базы данных. (Заметим, что это сильно напоминает организацию

систем управления базами данных для персональных компьютеров.) Клиент и

сервер могут располагаться в одном компьютере, но могут быть и разнесены на

разные компьютеры, связанные сетью. Естественно, что при наличии выделенной

аппаратуры, поддерживающей деятельность сервера, общая эффективность

Страницы: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29