Корпоративные сети
развивающимися направлениями языков программирования с абстрактными типами
данных и объектно-ориентированных языков программирования.
Что касается связи с предыдущими работами в области баз данных, то наиболее
сильное влияние на работы в области ООБД оказали проработки реляционных
СУБД и следующего хронологически за ними семейства БД, в которых
поддерживалось управление сложными объектами. Эти работы обеспечили
структурную основу организации OOБД.
Среди языков и систем программирования наибольшее первичное влияние на ООБД
оказал Smalltalk. Этот язык сам по себе не являлся полностью пионерским,
хотя в нем была введена новая терминология, являющаяся теперь наиболее
распространенной в объектно-ориентированном программировании. На самом
деле, Smalltalk основан на ряде ранее выдвинутых концепций.
В наиболее общей и классической постановке объектно-ориентированный подход
базируется на следующих концепциях:
1. объекта и идентификатора объекта;
2. атрибутов и методов;
3. классов;
4. иерархии и наследования классов.
Любая сущность реального мира в объектно-ориентированных языках и системах
моделируется в виде объекта. Любой объект при своем создании получает
генерируемый системой уникальный идентификатор, который связан с объектом
во все время его существования и не меняется при изменении состояния
объекта.
Каждый объект имеет состояние и поведение. Состояние объекта - набор
значений его атрибутов. Поведение объекта - набор методов (программный
код), оперирующих над состоянием объекта. Значение атрибута объекта - это
тоже некоторый объект или множество объектов. Состояние и поведение объекта
инкапсулированы в объекте; взаимодействие объектов производится на основе
передачи сообщений и выполнении соответствующих методов.
Множество объектов с одним и тем же набором атрибутов и методов образует
класс объектов. Объект должен принадлежать только одному классу (если не
учитывать возможности наследования). Допускается наличие примитивных
предопределенных классов, объекты-экземпляры которых не имеют атрибутов:
целые, строки и т.д. Класс, объекты которого могут служить значениями
атрибута объектов другого класса, называется доменом этого атрибута.
Допускается порождение нового класса на основе уже существующего класса -
наследование. В этом случае новый класс, называемый подклассом
существующего класса (суперкласса) наследует все атрибуты и методы
суперкласса. В подклассе, кроме того, могут быть определены дополнительные
атрибуты и методы. Различаются случаи простого и множественного
наследования. В первом случае подкласс может определяться только на основе
одного суперкласса, во втором случае суперклассов может быть несколько.
Если в языке или системе поддерживается единичное наследование классов,
набор классов образует древовидную иерархию. При поддержании множественного
наследования классы связаны в ориентированный граф с корнем, называемый
решеткой классов. Объект подкласса считается принадлежащим любому
суперклассу этого класса.
Одной из более поздних идей объектно-ориентированного подхода является идея
возможного переопределения атрибутов и методов суперкласса в подклассе
(перегрузки методов). Эта возможность увеличивает гибкость, но порождает
дополнительную проблему: при компиляции объектно-ориентированной программы
могут быть неизвестны структура и программный код методов объекта, хотя его
класс (в общем случае - суперкласс) известен. Для разрешения этой проблемы
применяется, так называемый, метод позднего связывания, означающий, по сути
дела, интерпретационный режим выполнения программы с распознаванием деталей
реализации объекта во время выполнения посылки сообщения к нему. Введение
некоторых ограничений на способ определения подклассов позволяет добиться
эффективной реализации без потребностей в интерпретации.
Видимо, наиболее важным новым качеством ООБД, которое позволяет достичь
объектно-ориентированный подход, является поведенческий аспект объектов. В
прикладных информационных системах, основывавшихся на БД с традиционной
организацией (вплоть до тех, которые базировались на семантических моделях
данных), существовал принципиальный разрыв между структурной и
поведенческой частями. Структурная часть системы поддерживалась всем
аппаратом БД, ее можно было моделировать, верифицировать и т.д., а
поведенческая часть создавалась изолированно. В частности, отсутствовали
формальный аппарат и системная поддержка совместного моделирования и
гарантирования согласованности этих структурной (статической) и
поведенческой (динамической) частей. В среде ООБД проектирование,
разработка и сопровождение прикладной системы становится процессом, в
котором интегрируются структурный и поведенческий аспекты. Конечно, для
этого нужны специальные языки, позволяющие определять объекты и создавать
на их основе прикладную систему.
С точки зрения разработчиков информационных систем подход 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. Ортогональность языков программирован
| |  скачать работу |
Корпоративные сети |
